BEYUL Whitepaper — Pre-Testnet Edition: البنية ونموذج الإفصاح

هذه ترجمة. النسخة الإنجليزية هي النسخة المرجعية (canonical) الوحيدة وتسود عند أي تعارض. المعرّفات التقنية (BEYUL، BYL، privacychain، TDC، ADC، nullifier، commitment، viewing key، shielded pool، Groth16، إلخ) تبقى بالإنجليزية دون ترجمة. هذه الترجمة مُولَّدة آليًا ويُوصى بمراجعتها من متحدث أصلي قبل النشر (machine-translated; native review recommended).

المشروع: BEYUL　النوع: نموذج بحثي أولي لسلسلة عامة موجّهة للخصوصية (pre-testnet). يجري حاليًا تطوير عمل بروتوكول BEYUL في مستودع privacychain. حالة الوثيقة: whitepaper الخاص بـ BEYUL، إصدار pre-testnet (بحثي) — يصف بنية البروتوكول ونموذج الإفصاح والحدود الحالية قبل الشبكة التجريبية العامة. هذه الوثيقة ليست مواصفة بروتوكول إنتاجية، ولا وثيقة استثمار، ولا رأي امتثال، ولا تدقيق أمني، ولا مادة إصدار رموز، ولا إعلان شبكة رئيسية. تتبع ادعاءات القدرات انضباط الأدلة في §3.1؛ ولا شيء هنا موصوف بما يتجاوز نضجه الفعلي. حالة الرمز: لم تُحسم Tokenomics. BYL هو مجرد اختصار / رمز تداول للمشروع؛ وهو ليس فئة (denomination) مجمّدة — تبقى الفئة ومعاملات السلسلة قيد الانتظار وتتطلب موافقة صريحة من Owner. لا تحدد هذه الوثيقة توزيع الرموز أو تصميم المنفعة. الرموز على الشبكة التجريبية، إن استُخدمت، لا تحمل قيمة نقدية ولا تَعِد بأي تحويل إلى الشبكة الرئيسية. اللغة المرجعية: النسخة الإنجليزية هي النسخة المرجعية الوحيدة. النسخة الصينية (beyul-whitepaper-pretestnet.zh.md) نص عمل مرافق؛ وعند التعارض تسود النسخة الإنجليزية.

إطار حدود الادعاءات (يُرجى قراءته أولًا)

هذه الوثيقة لا تقدّم أيًا من الادعاءات التالية:

• لا ادعاء بإخفاء الهوية أو عدم القابلية للتتبع أو "الأمان المطلق"؛
• لا ادعاء بأمان zero-knowledge بمستوى إنتاجي (يستخدم التنفيذ الحالي مادة development-key)؛
• لا ادعاء بخصوصية بمستوى إنتاجي (مبالغ الإيداع والسحب معلنة حاليًا on-chain)؛
• لا ادعاء بموافقة تنظيمية أو "compliance by design"؛
• لا يتضمن التصميم الحالي viewing key عالميًا يتحكم به المشروع؛ ويجب التحقق من هذه الخاصية عبر التنفيذ المفتوح والاختبار والتدقيق الخارجي؛
• لا توجد شبكة تجريبية عامة ولا شبكة رئيسية؛ جاهزية الشبكة التجريبية قيد التنفيذ — لم يكتمل بعد runbook متعدد العقد والبوابات (gate) ذات الصلة؛
• لا وعود بقيمة رمز أو airdrop أو عائد أو ربح أو إدراج في منصات تداول؛ ولا تتناول هذه الوثيقة منتجات المحفظة أو DeFi؛
• إن 16-character disclosure code ليس بيانًا أمنيًا تشفيريًا أساسيًا (القسم 7).

التسمية والمعرّفات التقنية. BEYUL هو اسم المشروع/المنتج؛ ويجري حاليًا تطوير عمل بروتوكول BEYUL في مستودع privacychain. يبقى privacychain المعرّف التقني الحالي — المستودع، وحزمة البروتوكول/الوحدة/proto، والملف الثنائي، وchain-id — ويُحتفظ به دون تغيير. BYL اختصار / رمز تداول؛ وتتطلب الفئة ومعاملات السلسلة موافقة صريحة من Owner، لذا فإن BYL ليس فئة مجمّدة. ينطبق انضباط التسمية هذا إلى الأمام فقط: لا يُعاد تسمية الوثائق التاريخية بأثر رجعي.

1. الملخص

BEYUL مشروع سلسلة عامة موجّهة للخصوصية في مرحلة النموذج البحثي الأولي (pre-testnet) يستكشف بنية دفع تحتية ذات خصوصية افتراضيًا (هدف تصميمي) وإفصاح يتحكم به المستخدم. في التصميم المستهدف، لا تظهر تفاصيل المعاملة افتراضيًا للعموم، لكن يمكن لمالك الأصل أن يُفصح طوعًا، ضمن نطاق محدود، لطرف مختار — يشرح Transaction Disclosure Code (TDC) معاملة واحدة؛ ويكشف Asset Disclosure Code (ADC) لقطة أصول مختارة. تصف عبارة "خصوصية افتراضيًا" هدفًا تصميميًا، لا النموذج الأولي الحالي (انظر §5).

ما هو موجود اليوم هو فقط نموذج أولي لاشتقاق disclosure-code من جهة العميل (مُختبَر محليًا؛ حزمة الأدلة العامة بانتظار التوحيد) ونموذج أولي لـ chain-application مبني على Cosmos SDK. أما grant من جهة الخادم من طرف إلى طرف، والتحقق on-chain، وZK balance proof فلم تُنفَّذ؛ لا trusted setup، ولا تدقيق خارجي، ولا شبكة تجريبية عامة أو شبكة رئيسية؛ ومبالغ الإيداع والسحب معلنة حاليًا on-chain. الغرض من هذا الـ whitepaper (إصدار pre-testnet) هو التسجيل الدقيق للاتجاه المعماري ونموذج الإفصاح والحدود الحالية قبل إطلاق الشبكة التجريبية العامة — وأن يُستبدل بإصدار إنتاجي فقط حين تتوفر الأدلة وعمليات التدقيق المقابلة.

2. التموضع والمشكلة

تكشف السجلات العامة علاقات الدفع والأرصدة وتدفقات الأموال لأي مراقب؛ وفي المقابل تجعل معظم أنظمة الخصوصية القوية الإفصاح الانتقائي صعبًا عمليًا — إذ كثيرًا ما يعني شرح معاملة واحدة لطرف ما تسليمَ القدرة على رؤية كل شيء. الفجوة التي يستكشفها BEYUL هي: جعل "الإفصاح" بدائيًا (primitive) من الدرجة الأولى على قدم المساواة مع "الإخفاء"، مع كون كل إفصاح مبادرًا به من المستخدم.

لا ينافس BEYUL — ولا يستهدف — سردية "مجهول تمامًا، غير قابل للتتبع".

الرؤية. الخصوصية المالية على السجلات العامة مقلوبة: عارية افتراضيًا، بينما يبدو الإخفاء نفسه مريبًا. هدف BEYUL هو قلب هذا الافتراضي — الخصوصية حالة افتراضية، والإفصاح اختيار مقصود ودقيق من المستخدم: أي معاملة، أي حقول، لمن، ولأي مدة.

مبادئ التصميم. يخضع كل جزء من البروتوكول لما يلي:

1. الإفصاح مواطن من الدرجة الأولى — تُصمَّم بدائيات الإفصاح وتُنمذَج على المستوى نفسه لبدائيات الإخفاء.
2. أقل الصلاحيات — يحمل كل مفتاح وبيان اعتماد أقل صلاحية يحتاجها غرضه فقط.
3. spend authority مقدّسة — لا يجوز لأي تدفق إفصاح أن يمس spend authority؛ ولا تدخل الـ mnemonic أي خطوة إفصاح إطلاقًا.
4. لا امتياز عالمي — البروتوكول مُصمَّم بحيث لا يوفّر أي قناة عرض عالمية للمشروع أو لطرف ثالث؛ وكون أي فرع كهذا غير موجود هو خاصية تصميمية يجب التحقق منها عبر التنفيذ المفتوح والاختبار والتدقيق الخارجي (§6)، وليست ضمانًا بعد.
5. صدق الحدود — تُعلن كل قدرة ما لا تفعله؛ ويبقى نموذج التهديد والقيود علنيًا.
6. الأدلة أولًا — لا تُرفَّع ادعاءات القدرات إلا بعد وجود الأدلة (كود، اختبارات، تدقيق) — مبنية على البوابات (gate)، دون وعود بتواريخ.

2.1 مقارنة إفصاح BEYUL

يقارن الجدول التصميم المستهدف لـ BEYUL بـ القدرات المُسلَّمة حاليًا لأنظمة أخرى. إن العناصر المميِّزة لـ BEYUL أدناه (انتهاء الصلاحية، الإلغاء، الرؤية المفروضة بالإجماع، النطاق لكل معاملة/لكل لقطة مع تحقق من جهة الخادم وon-chain) هي في معظمها قيد التخطيط أو نموذج أولي من جهة العميل (انظر §3، §7)، ولم تُسلَّم بعد. تُذكر حقائق المنافسين بتحفظ؛ وتُوسَم بـ 【to verify】 البنودُ التي لم يُعَد التحقق منها بشكل مستقل لهذا الـ whitepaper.

العنصر المميِّز المقصود ليس "إخفاءً أقوى" بل إفصاحًا أدق وموقوتًا ويصدره المستخدم: فبينما يكون viewing key في Zcash/Monero إذنَ قراءة على مستوى الحساب، الكل أو لا شيء وغير محدد المدة، يكون بيان اعتماد الإفصاح في BEYUL محدودًا بمعاملة واحدة (TDC) أو لقطة أصول واحدة (ADC)، يحمل انتهاء صلاحية ومصمَّمًا ليكون قابلًا للإلغاء — مع فرض مجموعة الحقول المرئية بالإجماع بدل عُرف المحفظة. هذه الخصائص أهداف تصميمية؛ وتُتتبَّع حالة تنفيذها بصدق في §3 و§7.

المصادر. Zcash/Monero: تقرير البحث المعمّق ZEC/XMR لهذا المشروع (مصادر أولية — Zcash Protocol Specification؛ توثيق Monero؛ حتى 2026-06-12). تصف صفوف Penumbra / Aztec / Namada التوثيق الرسمي لكل مشروع حتى 2026-06 (Penumbra: protocol.penumbra.zone — viewing keys، FMD؛ Aztec: docs.aztec.network — keys، note discovery؛ Namada: docs.namada.net — shielded accounts). أما بنود 【to verify】 المتبقية — انتهاء/إلغاء ودلالة transaction-perspective لدى Penumbra، والانتهاء/الإلغاء الأصلي لدى Aztec، ودلالة الإلغاء الدقيقة لدى Namada — فبانتظار التأكيد. تذكر هذه الصفوف ما يصفه توثيق كل مشروع، لا ادعاءً بأن أنظمة أخرى "لا تستطيع".

3. الحالة الراهنة

3.1 سلسلة الأدلة

كل صف "نموذج أولي منفَّذ" أعلاه مرتبط بسجل دليل — لا مدّعى بالنثر. تُحفظ سلسلة الأدلة (commit hash، سجل CI، أمر الاختبار ومخرجاته بدقة، تعليمات تشغيل قابلة لإعادة الإنتاج) في Evidence Appendix، وتُصنَّف كل قدرة على مقياس النضج البحثي L0–L5 (تصميم → نموذج أولي → قابل لإعادة الإنتاج → مُراجَع → دليل شبكي → إنتاج). يشير هذا الـ whitepaper إلى ذلك السجل بدل تكرار الأدلة الخام.

التقييم الذاتي الحالي: معظم المواد عند L1–L2، ولا شيء عند L5. وإلى أن تُملأ بنود Evidence Appendix (commit/CI)، تقول المواد العامة "تم التحقق محليًا؛ حزمة الأدلة العامة بانتظار التوحيد"، لا "منفَّذ بأدلة عامة". لا يمكن وصف قدرة بلا سجل دليل مسجَّل بما يتجاوز مستوى نضجها. يقع Evidence Appendix في docs/evidence-appendix.md (داخلي؛ سيُنشر مع حزمة الأدلة العامة)؛ وقد أُعيد إنتاج E1/E3/E4 للقراءة فقط في 2026-06-19، وربط CI لا يزال معلَّقًا.

4. النموذج التقني

يتمحور النموذج الأولي حول آلة حالة (state machine) لـ shielded-pool. لغير المختص بالتشفير، تمضي دورة حياة الرصيد الخاص هكذا:

1. Note. الرصيد القابل للإنفاق هو note — سجل مكوَّن من (المالك، المبلغ، العشوائية). ولا تظهر الـ note نفسها on-chain أبدًا.
2. Commitment. تخزّن السلسلة فقط commitment للـ note (تجزئة ملزِمة باتجاه واحد)، يُلحق بـ Merkle commitment tree للإضافة فقط. ومن الـ commitment وحده لا يعرف المراقب المالك ولا المبلغ.
3. Spend ← nullifier. لإنفاق note، ينشر المالك nullifier مشتقًا منها. لا يستطيع المراقبون الخارجيون ربط الـ nullifier بالـ commitment، لكنه حتمي لتلك الـ note — لذا لا تُبطَل الـ note نفسها إلا مرة واحدة.
4. رفض double-spend. تحفظ السلسلة مجموعة من الـ nullifier؛ ويُرفض أي nullifier مكرر. وهذا يمنع double-spend دون كشف أي note أُنفقت.
5. برهان الصلاحية. يحمل كل spend برهان zero-knowledge بأن "أملك note يقع commitment الخاص بها في الشجرة، وقد اشتققت nullifier الخاص بها بشكل صحيح"، دون كشف أي من تلك القيم. ويمر التحقق عبر مسار Groth16.

يستخدم المُحقِّق الحالي مادة verifying-key من نوع development/skeleton دون trusted setup، ولا يُرسي soundness أو خصوصية بمستوى إنتاجي. الصياغة الخارجية المعيارية: "يتضمن النموذج الأولي مسار تحقق Groth16 بـ development-key. وهو لا يوفّر بعد أمان zero-knowledge بمستوى إنتاجي." للتعريفات الصورية لصيغة الـ note ومخطط الـ commitment واشتقاق الـ nullifier ودلالة الشجرة، انظر yellow paper §§5–7 و§10.

4.1 لماذا سلسلة مستقلة، ولماذا Cosmos

يحتاج نموذج الإفصاح إلى تحكّم في أمور لا يمنحها نشرُ عقد ذكي على L1 مشتركة، أو rollup عام، بشكل نظيف:

• رؤية الإفصاح المفروضة بالإجماع (§6) وقواعد سلامة المعروض لـ shielded pool يجب أن تكونا في طبقة انتقال الحالة/الإجماع، لا داخل عقد يقع مدققو سلسلته المضيفة وسوق رسومها خارج تحكم المشروع.
• حالة shielded أصلية (commitment tree، مجموعة nullifier، محاسبة value-balance) أرخص وأقبل للتدقيق كحالة سلسلة من الدرجة الأولى منها كتخزين عقد، وتتجنّب أن يُسرّب mempool العام ونموذج البيانات الوصفية للسلسلة المضيفة أكثر مما هو مقصود.
• مجموعة مدققين بـ bonded-PoS تتيح لكل full node إعادة حساب سلامة المعروض، وتمنح نهائية فورية ملائمة للدفع.

اختير Cosmos SDK + CometBFT من أجل مكدّس BFT-PoS ناضج بوحدات staking/slashing، وحوكمة ترقية سيادية، ونهائية فورية — لا كتأييد لأي نموذج رمز (لم يُحسم أي منها). هذا تبرير لاختيار البنية، لا ادعاء بأن سلسلة مستقلة قد نُشرت؛ والحالة الفعلية انظر §3 و§8.

4.2 خصائص الأداء

يُفصل بين نوعين من الأرقام. جوهرية (على مستوى المخطط، قابلة للاقتباس): يمتلك Groth16 على منحنى BN254 براهين بحجم ثابت (ثلاثة عناصر زمرة — بضع مئات بايت تقريبًا على BN254) وتحققًا بزمن ثابت (عدد ثابت وصغير من فحوص pairing، مستقل عن حجم الدائرة). وهذا ينبع من نظام البرهان نفسه، لا من تنفيذ BEYUL. على مستوى النظام (لم يُقَس بعد): يعتمد زمن البرهان وإنتاجية المعاملات (TPS) وحجم الدائرة (عدد القيود) على الدائرة الإنتاجية، والدائرة الإنتاجية لم تُبنَ — يستخدم المسار الحالي verifying key من نوع dev/skeleton (§4). لذا فإن أي رقم كهذا هو target / 【to be supplied】، يُقاس مرجعيًا حين تتوفر الدائرة الإنتاجية ومسار trusted-setup-أو-برهان-شفاف (Roadmap §10، Phase 6). وفوق هذا الخط لا يُدَّعى أي رقم أداء على مستوى النظام.

5. نموذج الخصوصية والقيود الحالية

النموذج الأولي الحالي ليس خصوصية بمستوى إنتاجي.

يُحفظ إطار صوري لـ anonymity-set (كيف يُعرَّف ويُحدَّد anonymity-set لـ shielded pool) في yellow paper (§15)؛ ويذكر هذا القسم أهداف الخصوصية والقيود الحالية، لا ذلك النموذج الصوري.

6. نموذج المفاتيح والإفصاح

من الأعلى صلاحية إلى الأدنى: Spend Key (صلاحية الإنفاق الوحيدة؛ لا يغادر جهاز المستخدم أبدًا؛ ولا يشارك في تدفقات الإفصاح أبدًا) → Full View Key (للقراءة فقط؛ يُخطَّط لفصل الوارد/الصادر) → Audit Key (قيد التخطيط: يصدره المستخدم طوعًا؛ محدود زمنيًا، محدود النطاق، قابل للإلغاء؛ ليس قناة يفرضها البروتوكول) → Disclosure Credential (أصغر وحدة إفصاح، مربوطة بمعاملة واحدة أو لقطة أصول واحدة) → 16-character disclosure code (رمز مدخل قصير؛ ليس مفتاحًا).

حد صلاحية عرض المشروع: لا يتضمن التصميم الحالي master viewing key يتحكم به المشروع. يجب التحقق من هذه الخاصية عبر التنفيذ المفتوح والاختبار والتدقيق الخارجي بدل الاعتماد على الثقة بالفريق — تُسلَّم مسارات اشتقاق المفاتيح كمصدر مفتوح، ويستطيع أي طرف ثالث تدقيق رسم الاشتقاق للتأكد من عدم وجود أي فرع يقود إلى المشروع. وإلى أن يكتمل التدقيق الخارجي، هذه "خاصية تصميمية يجب التحقق منها"، لا "ضمان".

سياسة الـ mnemonic (تخطيط معماري، لا منتج مُسلَّم): يستخدم المفتاح الجذري للمحفظة افتراضيًا mnemonic من 24 كلمة (BIP39)، وتُشتق المفاتيح اللاحقة عبر فصل النطاقات (HKDF + domain tags). يجب ألا تظهر الـ mnemonic في أي تدفق إفصاح إطلاقًا؛ ولا يجوز اشتقاق disclosure code ولا link_secret من الـ mnemonic وحدها — تُولَّد منح TDC/ADC لحظةَ الإفصاح الطوعي باستخدام CSPRNG وتفويض محلي.

حد رؤية الإفصاح (متطلب تصميمي): يُخطَّط لضمان النطاق المرئي لبيان اعتماد الإفصاح — بما في ذلك رؤية الاتجاه الصادر — بقواعد على طبقة الإجماع بدل عُرف تنفيذ المحفظة (درس صناعي من Zcash حيث تعتمد رؤية الصادر على عُرف المحفظة)؛ ويأتي هذا المتطلب مع مكدّس التحقق on-chain (roadmap Phase 5) وهو غير منفَّذ اليوم.

7. النموذج الأولي للإفصاح TDC / ADC

7.1 المصطلحات والترميز

المصطلح الرسمي هو "16-character Crockford Base32 disclosure code" (تستبعد الأبجدية الأحرف المربكة I/L/O/U؛ إنتروبيا الرمز القصير ~80 بت)، ويُختصر إلى "16-character disclosure code". لا تُستخدم صياغات مثل "16-digit code" أو "16-digit security code" — رُفض المخطط الرقمي البحت (~53 بت) لعدم كفاية ميزانية الإنتروبيا.

"إن 16-character disclosure code ليس بيانًا أمنيًا تشفيريًا أساسيًا. إنه مدخل وصول سهل للمستخدم؛ ويجب أن يُحمى التفويض الفعلي معًا بـ disclosure credential عالي الإنتروبيا، وتواقيع، وتقييد نطاق، وانتهاء صلاحية، ومنطق تحقق."

7.2 الحالة الفعلية الراهنة (قراءة إلزامية)

ما يملكه BEYUL هو نموذج أولي لاشتقاق TDC/ADC من جهة العميل، مُختبَر محليًا. أما grant الخادم من طرف إلى طرف، والتحقق من حالة السلسلة، وZK balance proof فهي قيد التخطيط وغير منفَّذة. لذا لا يجوز القول إن: الإفصاح القابل للتحقق منفَّذ؛ أو إن الأموال يمكن إثباتها فعلًا؛ أو إن ADC يستطيع إثبات أرصدة دقيقة؛ أو إن disclosure code يمكن التحقق منه on-chain.

يغطي النموذج الأولي للعميل (مُختبَر محليًا): KEK ثنائي العامل (link_secret + رمز من 16 محرفًا، كلاهما إلزامي)؛ ترميزًا قانونيًا (canonical)؛ ربط دوري المرسِل/المتلقي في TDC؛ فصل نطاقات TDC/ADC (لا يفتح أحدهما الآخر)؛ AEAD envelope بحماية ضد العبث عبر AAD؛ مُحقِّق رمز بـ slow-hash (المجموعة المستهدفة Argon2id؛ محوّل الإنتاج غير موصول بعد)؛ crypto-shredding لـ erasure-key؛ متجهات مجمّدة عبر اللغات.

7.3 دلالة TDC وADC

معضلة الإفصاح الثلاثية: لا يستطيع نظام يخفي الملكية أن يَعِد في آن واحد باكتمال الرصيد، وعدم تسريب التاريخ، وعدم تسليم viewing key — يستطيع المستخدم إثبات ملكية notes مختارة، لكن بلا مصدر اكتمال إضافي لا يستطيع إثبات عدم إغفال أي شيء. لذا فإن ADC متدرّج، وADC يكشف بالضبط رصيد مجموعة الأصول المختارة عند الارتفاع المختار — ولا يجوز وصفه بأنه "لا يكشف الرصيد".

مخاطر ADC (تبقى علنية): اللقطات المتكررة للطرف نفسه تكشف تغيّر الرصيد عبر الزمن؛ وكشف صافي الثروة خطر على السلامة الجسدية وخطر إكراه (ADC مُطفأ افتراضيًا ويتطلب تأكيدًا صريحًا)؛ والتدوير لا يسترجع ما رآه المراقب فعلًا.

7.4 الأسئلة الشائعة عن disclosure code

8. خطة الشبكة التجريبية (التركيز الحالي)

8.1 نموذج المدقِّق

تستخدم الشبكة التجريبية نموذج مدقِّق BFT بأسلوب PoS: Cosmos SDK + CometBFT، مجموعة validator أولية، وتدفقات اختبار وحدة staking. وهو ليس PoW، وليس أمانًا اقتصاديًا لـ PoS بمستوى الشبكة الرئيسية — فالنموذج الاقتصادي للشبكة الرئيسية بحث طويل الأمد خارج نطاق هذا الـ whitepaper.

8.2 جاهزية الشبكة التجريبية (بصراحة)

جاهزية الشبكة التجريبية قيد التنفيذ: لم يكتمل بعد runbook متعدد العقد والبوابات ذات الصلة (لم تُدمج كل طلبات السحب ذات الصلة ولم تنجح الفحوص). وإلى أن تُغلق هذه البوابات وتُسجَّل الأدلة، لا يستخدم هذا المشروع صياغة "testnet-ready".

قائمة تحقق ما قبل الإطلاق: إغلاق حزمة الأدلة؛ chain-id وgenesis للشبكة التجريبية؛ دليل إلحاق المدققين؛ runbook متعدد العقد بـ 3+ عقد؛ سياسة faucet وتحديد معدّل؛ سياسة RPC/API عامة؛ لوحة مراقبة؛ عملية استجابة للحوادث؛ قائمة قيود معروفة؛ تدفق أوامر المشارك؛ إشعار بانعدام قيمة رمز الشبكة التجريبية.

8.3 ما يمكن للشبكة التجريبية التحقق منه / ما لا تستطيع إثباته

يمكن التحقق منه: تشغيل العقد وإنتاج الكتل، تدفقات وحدة staking، faucet، RPC، المراقبة والاستجابة للحوادث، تدفق عرض disclosure-code، تدفق النموذج الأولي لـ shielded module. لا يمكن إثباته: الخصوصية الإنتاجية، الأمان الاقتصادي لـ PoS بمستوى الشبكة الرئيسية، قيمة الرمز، القبول التنظيمي، ZK soundness إنتاجي. لا يجوز تسويق إطلاق الشبكة التجريبية بوصفه "تحققًا إنتاجيًا".

8.4 إرشادات للمشارك

رموز الشبكة التجريبية لا تحمل قيمة نقدية ولا تَعِد بتحويل إلى الشبكة الرئيسية؛ لا توجد محفظة رسمية — شارك فقط بأدوات سطر الأوامر والوثائق المنشورة رسميًا؛ لا يطلب أي تدفق إطلاقًا أن تدخل الـ mnemonic الخاصة بك خطوةَ إفصاح — وأي "رسمي" يطلب الـ mnemonic الخاصة بك محتال؛ ولا يوجد حاليًا أي بيع رموز أو جولة خاصة أو whitelist أو تسجيل airdrop.

8.5 الحوكمة والترقيات والحد الاقتصادي

في مرحلة pre-testnet هذه، لا توجد لدى BEYUL حوكمة لامركزية. تُتحكَّم ترقيات البروتوكول والـ pin الحرجة أمنيًا — معاملات genesis وverifying key المثبَّت (pinned) — بواسطة مجموعة المدققين الأولية مع Owner معًا. هذا نموذج ثقة مركزي مذكور بصراحة؛ ولن يُلامرَك إلا تدريجيًا مع نضج الشبكة وحوكمتها (لا DAO، ولا وعد بجدول زمني للامركزية). تشغيل مدقِّق وحده لا يمنح صلاحية الترقية؛ ولا يتغير pinned VK وgenesis إلا عبر مسار ترقية "مجموعة المدققين + Owner".

الحد الاقتصادي. الفئة والمعروض والمعاملات الاقتصادية هي قرارات Owner — مبوَّبة (gated)، وغير معرَّفة في هذا الـ whitepaper (انظر حالة الرمز أعلاه). ولا شيء هنا يثبّت فئة أو معروضًا أو نموذجًا اقتصاديًا للرمز.

9. نموذج التهديد (علني حتى التخفيف)

منظَّم حسب فئات الخصم، متوائم مع نموذج الخصم في yellow paper (A1–A4). هذا ملخص؛ وyellow paper هو المرجع الموثوق لنموذج التهديد، ويجب ألا تنحرف الوثيقتان — وعند الاختلاف يسود yellow paper.

• A1 — مراقب سلسلة سلبي (يقرأ بيانات السلسلة العامة فقط): ارتباط المبالغ عند الإيداع/السحب العلني، ارتباط التوقيت، قنوات جانبية للرسوم/gas — غير مُخفَّف. commitments وnullifiers وanchors وحساب صافي تدفق المجمّع علنية بحكم التصميم.
• A2 — خصم شبكي/بنية تحتية (mempool، RPC، ترتيب المدققين، IP): مراقبة mempool، ترتيب المدققين والرقابة، بيانات وصفية لطبقة الشبكة — غير مُخفَّف (الترتيب/الرقابة جزئيًا خارج نطاق البروتوكول)؛ بيانات وصفية لمنصات التداول/الجسور خارج البروتوكول — خارج النطاق.
• A3 — خصم من جهة الإفصاح (متلقي إفصاح أو حامل رمز): إعادة توجيه المتلقي للإفصاح غير قابلة للتحكم تشفيريًا؛ والإلغاء غير منفَّذ؛ وكشف السلسلة الزمنية وصافي الثروة لـ ADC عند اللقطات المتكررة؛ والإصدار تحت الإكراه — مذكور بصراحة، غير مُخفَّف.
• A4 — خصم نقطة طرفية/هندسة اجتماعية (جهاز المستخدم، تصيّد): تصيّد وهندسة اجتماعية لانتزاع mnemonic أو رموز، محافظ مزيفة وقنوات رسمية مزيفة — غير مُخفَّف؛ يُعالَج بتثقيف المستخدم وقائمة القنوات الرسمية.

عرضية، غير محلولة: عيوب الدائرة، trusted setup، تدقيق خارجي — غير محقَّقة / غير محلولة / غير مكتملة. الخلط حول قيمة رمز الشبكة التجريبية والمكافآت غير مسموح — رموز الاختبار بلا قيمة، وأي محاسبة مكافآت محاكاة.

10. Roadmap (مبني على البوابات، بلا وعود بتواريخ)

يجب أن تكون كل قدرة في حالة واحدة بالضبط: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. ولا يمكن كتابة أي ادعاء بأنه "منفَّذ" دون commit وسجل CI وأمر اختبار ومخرجات.

الترتيب غير قابل للعكس: testnet → TDC MVP → ADC_L1 → root-bound verification → production ZK → ADC_L2 → audit → pre-mainnet.

11. حد الامتثال

BEYUL ليس حلَّ امتثال: فهو لا ينفّذ سير عمل AML أو KYC أو travel-rule أو التجميد أو فحص العقوبات أو الإبلاغ، ولا يدّعي "compliant by design". كل إفصاح مبادر به من المستخدم؛ ولا توجد في البروتوكول قناة إفصاح قسري؛ ولا يتضمن التصميم الحالي viewing key عالميًا يتحكم به المشروع (سيُتحقَّق منه عبر التنفيذ المفتوح والتدقيق). على المؤسسات والأفراد أن يقيّموا باستقلالية الموقف التنظيمي لولايتهم القضائية تجاه الأصول الموجَّهة للخصوصية.

12. بيان المخاطر وإخلاء المسؤولية

هذه الوثيقة لأغراض إعلامية فقط، ولا تشكّل، ولا ينبغي تأويلها على أنها: عرض أو بيع لورقة مالية أو سلعة أو أداة مالية؛ أو مشورة استثمارية أو قانونية أو ضريبية أو مالية؛ أو بيان امتثال في أي ولاية قضائية. وتتضمن بيانات تطلعية (أهداف تصميمية، خطط شبكة تجريبية، roadmap) خاضعة لعدم يقين جوهري؛ وقد تختلف النتائج الفعلية اختلافًا جوهريًا.

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

13. الخاتمة

اتجاه BEYUL هو خصوصية افتراضيًا مع إفصاح يتحكم به المستخدم. أصوله الجديرة بالثقة اليوم: نموذج أولي لـ chain-application، ونموذج أولي لاشتقاق TDC/ADC من جهة العميل مُختبَر محليًا، وجدول حالة ونموذج تهديد مُبقيان متوائمين بدقة مع التنفيذ. والتركيز الوحيد حاليًا هو الشروط المسبقة لإطلاق الشبكة التجريبية العامة: إغلاق الأدلة، وrunbook متعدد العقد، وfaucet والمراقبة، ووثائق المشارك. وإلى أن تتوفر الأدلة المقابلة، لا يقدّم هذا المشروع ادعاءات عن شبكة رئيسية أو رمز أو خصوصية إنتاجية أو امتثال.