BTC老白
861 منشورات
BTC老白
إبلاغ
حظر المُستخدم
03｜4年交易实践｜《猎流日内交易》主理人｜每日更新BTC关键位与流动性｜不预测K线，只确认交易条件｜AI Workflow · Research · Automation｜用系统，而不是情绪做交易
فتح تداول
مُتداول مُتكرر
3.3 سنوات
160 تتابع
12.7K+ المتابعون
2.5K+ إعجاب
منشورات
الحافظة الاستثمارية
الكل
اقتباسات
Live
·
--
صاعد
تحليل سوق BTC: $BTC ｜9.24
لا يزال إطار 4 ساعات ضمن بنية هبوط؛ وقد ظهرت قمة مزدوجة قرب أعلى القمة السابقة. وفي غضون ساعة واحدة عاد السعر إلى أسفل نطاق الصندوق. يقع مستوى 84,000 تقريبًا ضمن منطقة دفاع للشراء القصير. سيتابع لَاو باي مؤقتًا توقع الارتداد وفق نطاق الصندوق، وإذا تم كسر 83,500 فسيتم إلغاء هذا الحكم.
استراتيجية التداول:
لدى 84,000: توجد صفقات شراء بالفعل: الاستمرار في الاحتفاظ بها، مع وقف خسارة عند 83,458. في حال الارتداد، راقب سلوك السعر قرب الحد العلوي لنطاق الصندوق؛ ولا تعتبر أي تعافٍ قصير المدى انعكاسًا لاتجاه صاعد.
الصفقات البيع من الجهة اليمنى: إذا كسر السعر خلال ساعة واحدة مستوى 83,500 ثم لم يعد للاختراق/لم يتمكن من العودة للأعلى عند الارتداد، عندها يتم البيع.
وقف الخسارة: 84,500
الهدف: قرب 82,200
الصفقات شراء من الجهة اليسرى: بعد النزول إلى 81,500—82,200، راقب إشارات توقف النزول ثم أعد الدخول.
وقف الخسارة: 80,788
الهدف: 83,000—83,500
لم يتحول اتجاه إطار 4 ساعات إلى قوة بعد. خاصة عند شراء قرب 82,200، فإن نسبة العائد/الخسارة إلى الهدف الأول تكون منخفضة، كما أن المكان غير مناسب؛ فإذا لم يكن جيدًا فالأفضل التخلي. $BTC
{future}(BTCUSDT)
تحليل سوق BTC: $BTC ｜9.24
لا يزال إطار 4 ساعات ضمن بنية هبوط؛ وقد ظهرت قمة مزدوجة قرب أعلى القمة السابقة. وفي غضون ساعة واحدة عاد السعر إلى أسفل نطاق الصندوق. يقع مستوى 84,000 تقريبًا ضمن منطقة دفاع للشراء القصير. سيتابع لَاو باي مؤقتًا توقع الارتداد وفق نطاق الصندوق، وإذا تم كسر 83,500 فسيتم إلغاء هذا الحكم.
استراتيجية التداول:
لدى 84,000: توجد صفقات شراء بالفعل: الاستمرار في الاحتفاظ بها، مع وقف خسارة عند 83,458. في حال الارتداد، راقب سلوك السعر قرب الحد العلوي لنطاق الصندوق؛ ولا تعتبر أي تعافٍ قصير المدى انعكاسًا لاتجاه صاعد.
الصفقات البيع من الجهة اليمنى: إذا كسر السعر خلال ساعة واحدة مستوى 83,500 ثم لم يعد للاختراق/لم يتمكن من العودة للأعلى عند الارتداد، عندها يتم البيع.
وقف الخسارة: 84,500
الهدف: قرب 82,200
الصفقات شراء من الجهة اليسرى: بعد النزول إلى 81,500—82,200، راقب إشارات توقف النزول ثم أعد الدخول.
وقف الخسارة: 80,788
الهدف: 83,000—83,500
لم يتحول اتجاه إطار 4 ساعات إلى قوة بعد. خاصة عند شراء قرب 82,200، فإن نسبة العائد/الخسارة إلى الهدف الأول تكون منخفضة، كما أن المكان غير مناسب؛ فإذا لم يكن جيدًا فالأفضل التخلي. $BTC
لا يزال إطار 4 ساعات ضمن بنية هبوط؛ وقد ظهرت قمة مزدوجة قرب أعلى القمة السابقة. وفي غضون ساعة واحدة عاد السعر إلى أسفل نطاق الصندوق. يقع مستوى 84,000 تقريبًا ضمن منطقة دفاع للشراء القصير. سيتابع لَاو باي مؤقتًا توقع الارتداد وفق نطاق الصندوق، وإذا تم كسر 83,500 فسيتم إلغاء هذا الحكم.
استراتيجية التداول:
لدى 84,000: توجد صفقات شراء بالفعل: الاستمرار في الاحتفاظ بها، مع وقف خسارة عند 83,458. في حال الارتداد، راقب سلوك السعر قرب الحد العلوي لنطاق الصندوق؛ ولا تعتبر أي تعافٍ قصير المدى انعكاسًا لاتجاه صاعد.
الصفقات البيع من الجهة اليمنى: إذا كسر السعر خلال ساعة واحدة مستوى 83,500 ثم لم يعد للاختراق/لم يتمكن من العودة للأعلى عند الارتداد، عندها يتم البيع.
وقف الخسارة: 84,500
الهدف: قرب 82,200
الصفقات شراء من الجهة اليسرى: بعد النزول إلى 81,500—82,200، راقب إشارات توقف النزول ثم أعد الدخول.
وقف الخسارة: 80,788
الهدف: 83,000—83,500
لم يتحول اتجاه إطار 4 ساعات إلى قوة بعد. خاصة عند شراء قرب 82,200، فإن نسبة العائد/الخسارة إلى الهدف الأول تكون منخفضة، كما أن المكان غير مناسب؛ فإذا لم يكن جيدًا فالأفضل التخلي. $BTC
218
·
--
يتحدث الكثيرون عن PolyFlow ويركزون على كيفية تصميم PID وPLP؛ لكن ما يثير فضولي أكثر هو: هل يمكن للائتمان على السلسلة ألا يعتمد على ضمانات أصول مُشفّرة، بل يتم تسعيره من خلال فعل الدفع نفسه؟ هذه برأيي هي أكثر نقطة تميّزًا في PolyFlow.
حلّه ليس “نَسخة مُحسّنة من الضمان الزائد”، بل إنه يستخدم مجموعة مختلفة من بدائيات الائتمان: كل دفعة تُنجَز عبر PID تُولّد تلقائيًا سندات قابلة للتحقق وتُثبَّت على السلسلة. لا يحتاج المقترض إلى تقديم ضمانات زائدة؛ بل يمكن للمُقرِض مباشرة استدعاء تقييم الائتمان على السلسلة. على Pelago، حصل مزوّدان على قرض على السلسلة بقيمة 1,000,000 USDC عبر تحويل ذمم القبض إلى رموز، وكل شيء تم عبر تسوية Stellar. الأهم ليس مجرد “الإقراض على السلسلة”، بل أن مصدر الائتمان انتقل من الضمانات إلى مدفوعات التجارة الفعلية.
تُظهر حالة ROAM الفرق بشكل أوضح. بعد أن يكمل المستخدم عملية KYC، يقوم PID تلقائيًا بتوليد سندات على السلسلة، ثم تقوم ROAM بالتحقق مباشرة وتفعيل eSIM، دون الحاجة إلى مراجعة هوية ثانية. في هذا السياق، يتم ضغط التحقق من الهوية وسلوك الدفع إلى فعل واحد: لم تعد KYC مجرد مدخل امتثال، بل نقطة بداية قابلة لإعادة الاستخدام لبيانات الائتمان.
كان Raymond Qu يعمل في Geoswift لسنوات طويلة في المدفوعات عبر الحدود، وفريقه يفهم بعمق نقاط الألم في أنظمة التسوية التقليدية. جوهر PID هو تحويل كل دفعة إلى أصل ائتماني قابل لإعادة الاستخدام. كلما ارتفعت أحجام تسوية العملات المستقرة، أصبح هذا الاتجاه أقل شبهاً بأداة دفع وأكثر شبيهاً بالمنافسة على سلطة تسعير الائتمان—ولعل مساحة التخيل أكبر من مجرد الدفع نفسه.
@Square-Creator-cf6856467 #polyflow @PolyFlow对接
يتحدث الكثيرون عن PolyFlow ويركزون على كيفية تصميم PID وPLP؛ لكن ما يثير فضولي أكثر هو: هل يمكن للائتمان على السلسلة ألا يعتمد على ضمانات أصول مُشفّرة، بل يتم تسعيره من خلال فعل الدفع نفسه؟ هذه برأيي هي أكثر نقطة تميّزًا في PolyFlow.
حلّه ليس “نَسخة مُحسّنة من الضمان الزائد”، بل إنه يستخدم مجموعة مختلفة من بدائيات الائتمان: كل دفعة تُنجَز عبر PID تُولّد تلقائيًا سندات قابلة للتحقق وتُثبَّت على السلسلة. لا يحتاج المقترض إلى تقديم ضمانات زائدة؛ بل يمكن للمُقرِض مباشرة استدعاء تقييم الائتمان على السلسلة. على Pelago، حصل مزوّدان على قرض على السلسلة بقيمة 1,000,000 USDC عبر تحويل ذمم القبض إلى رموز، وكل شيء تم عبر تسوية Stellar. الأهم ليس مجرد “الإقراض على السلسلة”، بل أن مصدر الائتمان انتقل من الضمانات إلى مدفوعات التجارة الفعلية.
تُظهر حالة ROAM الفرق بشكل أوضح. بعد أن يكمل المستخدم عملية KYC، يقوم PID تلقائيًا بتوليد سندات على السلسلة، ثم تقوم ROAM بالتحقق مباشرة وتفعيل eSIM، دون الحاجة إلى مراجعة هوية ثانية. في هذا السياق، يتم ضغط التحقق من الهوية وسلوك الدفع إلى فعل واحد: لم تعد KYC مجرد مدخل امتثال، بل نقطة بداية قابلة لإعادة الاستخدام لبيانات الائتمان.
كان Raymond Qu يعمل في Geoswift لسنوات طويلة في المدفوعات عبر الحدود، وفريقه يفهم بعمق نقاط الألم في أنظمة التسوية التقليدية. جوهر PID هو تحويل كل دفعة إلى أصل ائتماني قابل لإعادة الاستخدام. كلما ارتفعت أحجام تسوية العملات المستقرة، أصبح هذا الاتجاه أقل شبهاً بأداة دفع وأكثر شبيهاً بالمنافسة على سلطة تسعير الائتمان—ولعل مساحة التخيل أكبر من مجرد الدفع نفسه.
@polyflow_PayFi #polyflow @PolyFlow对接
حلّه ليس “نَسخة مُحسّنة من الضمان الزائد”، بل إنه يستخدم مجموعة مختلفة من بدائيات الائتمان: كل دفعة تُنجَز عبر PID تُولّد تلقائيًا سندات قابلة للتحقق وتُثبَّت على السلسلة. لا يحتاج المقترض إلى تقديم ضمانات زائدة؛ بل يمكن للمُقرِض مباشرة استدعاء تقييم الائتمان على السلسلة. على Pelago، حصل مزوّدان على قرض على السلسلة بقيمة 1,000,000 USDC عبر تحويل ذمم القبض إلى رموز، وكل شيء تم عبر تسوية Stellar. الأهم ليس مجرد “الإقراض على السلسلة”، بل أن مصدر الائتمان انتقل من الضمانات إلى مدفوعات التجارة الفعلية.
تُظهر حالة ROAM الفرق بشكل أوضح. بعد أن يكمل المستخدم عملية KYC، يقوم PID تلقائيًا بتوليد سندات على السلسلة، ثم تقوم ROAM بالتحقق مباشرة وتفعيل eSIM، دون الحاجة إلى مراجعة هوية ثانية. في هذا السياق، يتم ضغط التحقق من الهوية وسلوك الدفع إلى فعل واحد: لم تعد KYC مجرد مدخل امتثال، بل نقطة بداية قابلة لإعادة الاستخدام لبيانات الائتمان.
كان Raymond Qu يعمل في Geoswift لسنوات طويلة في المدفوعات عبر الحدود، وفريقه يفهم بعمق نقاط الألم في أنظمة التسوية التقليدية. جوهر PID هو تحويل كل دفعة إلى أصل ائتماني قابل لإعادة الاستخدام. كلما ارتفعت أحجام تسوية العملات المستقرة، أصبح هذا الاتجاه أقل شبهاً بأداة دفع وأكثر شبيهاً بالمنافسة على سلطة تسعير الائتمان—ولعل مساحة التخيل أكبر من مجرد الدفع نفسه.
@polyflow_PayFi #polyflow @PolyFlow对接
215
·
--
$DUSK عملة منصة بينانس - قائمة المبدعين في الساحة. بدون أي دفع/ترويج للأعمال
مرة أخرى، حصلت عليها بالمركز 45.
$DUSK عملة منصة بينانس - قائمة المبدعين في الساحة. بدون أي دفع/ترويج للأعمال
مرة أخرى، حصلت عليها بالمركز 45.
مرة أخرى، حصلت عليها بالمركز 45.
380
·
--
عندما كنت أضبط مؤشر Dusk، وقعت في حفرة: جعلت transaction ID وcontract ID يشتركان في دالة تجزئة واحدة. يتم استخدام SHA3-256 لـ block hash وMerkle root؛ وBLAKE3 لـ contract bytecode وevent bloom filter؛ وBLAKE2b لكلٍّ من contract ID وtransaction ID؛ وSHA2-256 لـ سلامة المحفظة وتوليد اشتقاق المفاتيح.
يشبه ذلك أختامًا لأرشيف من أربع قطع. ختم الإيداع وختم العقد وختم استلام الوثائق يمكنها جميعًا ضغط أرقام، لكن نظام التسجيل لا يتعرف إلا على ذلك الختم المحدد. إذا أخطأت اختيار الخوارزمية، فسيبدو الناتج كأنه تجزئة طبيعية، لكن العقد لن تجد الكائن الموافق. أما الحفرة الأخرى فهي إعادة تجزئة سلسلة العرض بالصيغة السداسية عشرية مرة أخرى؛ غالبًا ما تتوقع واجهات البروتوكول bytes الخام؛ إن الالتفاف عبر الترميز خطوة إضافية يغيّر كل شيء.
لذلك عند التكامل سأحتفظ بالبايتات الأصلية، وأولّد المعرفات باستخدام SDK الرسمي أو Rusk، ثم أختبر بمجموعات اختبار باستخدام block وtransaction وcontract المعروفة. وثائق Dusk أيضًا (@Dusk_Foundation Dusk) توصي بتقليل تكرار تنفيذ ترميز البروتوكول. فصل المهام عبر خوارزميات متعددة يفرّق المسؤوليات كذلك، ويحوّل الأمور مثل الإصدارات وترتيب endianness وصيغة الإدخال إلى عناصر تحقق. مجرد توليد سلسلة بحجم/طول صحيح من الأحرف لا يعني إلا أن الدالة اكتملت؛ أما هوية السلسلة على الشبكة فلا بد من الرجوع والتأكد منها#dusk $DUSK
عندما كنت أضبط مؤشر Dusk، وقعت في حفرة: جعلت transaction ID وcontract ID يشتركان في دالة تجزئة واحدة. يتم استخدام SHA3-256 لـ block hash وMerkle root؛ وBLAKE3 لـ contract bytecode وevent bloom filter؛ وBLAKE2b لكلٍّ من contract ID وtransaction ID؛ وSHA2-256 لـ سلامة المحفظة وتوليد اشتقاق المفاتيح.
يشبه ذلك أختامًا لأرشيف من أربع قطع. ختم الإيداع وختم العقد وختم استلام الوثائق يمكنها جميعًا ضغط أرقام، لكن نظام التسجيل لا يتعرف إلا على ذلك الختم المحدد. إذا أخطأت اختيار الخوارزمية، فسيبدو الناتج كأنه تجزئة طبيعية، لكن العقد لن تجد الكائن الموافق. أما الحفرة الأخرى فهي إعادة تجزئة سلسلة العرض بالصيغة السداسية عشرية مرة أخرى؛ غالبًا ما تتوقع واجهات البروتوكول bytes الخام؛ إن الالتفاف عبر الترميز خطوة إضافية يغيّر كل شيء.
لذلك عند التكامل سأحتفظ بالبايتات الأصلية، وأولّد المعرفات باستخدام SDK الرسمي أو Rusk، ثم أختبر بمجموعات اختبار باستخدام block وtransaction وcontract المعروفة. وثائق Dusk أيضًا (@Dusk Dusk) توصي بتقليل تكرار تنفيذ ترميز البروتوكول. فصل المهام عبر خوارزميات متعددة يفرّق المسؤوليات كذلك، ويحوّل الأمور مثل الإصدارات وترتيب endianness وصيغة الإدخال إلى عناصر تحقق. مجرد توليد سلسلة بحجم/طول صحيح من الأحرف لا يعني إلا أن الدالة اكتملت؛ أما هوية السلسلة على الشبكة فلا بد من الرجوع والتأكد منها#dusk $DUSK
يشبه ذلك أختامًا لأرشيف من أربع قطع. ختم الإيداع وختم العقد وختم استلام الوثائق يمكنها جميعًا ضغط أرقام، لكن نظام التسجيل لا يتعرف إلا على ذلك الختم المحدد. إذا أخطأت اختيار الخوارزمية، فسيبدو الناتج كأنه تجزئة طبيعية، لكن العقد لن تجد الكائن الموافق. أما الحفرة الأخرى فهي إعادة تجزئة سلسلة العرض بالصيغة السداسية عشرية مرة أخرى؛ غالبًا ما تتوقع واجهات البروتوكول bytes الخام؛ إن الالتفاف عبر الترميز خطوة إضافية يغيّر كل شيء.
لذلك عند التكامل سأحتفظ بالبايتات الأصلية، وأولّد المعرفات باستخدام SDK الرسمي أو Rusk، ثم أختبر بمجموعات اختبار باستخدام block وtransaction وcontract المعروفة. وثائق Dusk أيضًا (@Dusk Dusk) توصي بتقليل تكرار تنفيذ ترميز البروتوكول. فصل المهام عبر خوارزميات متعددة يفرّق المسؤوليات كذلك، ويحوّل الأمور مثل الإصدارات وترتيب endianness وصيغة الإدخال إلى عناصر تحقق. مجرد توليد سلسلة بحجم/طول صحيح من الأحرف لا يعني إلا أن الدالة اكتملت؛ أما هوية السلسلة على الشبكة فلا بد من الرجوع والتأكد منها#dusk $DUSK
162
·
--
عندما كنت أقرأ وثائق W3sper الخاصة بـ Dusk @Dusk_Foundation Dusk، كنت قد اعتبرت DuskVM استعلامًا عن واجهة JSON عادية. يقوم تجميع عقد Forge بإنتاج data-driver WASM أيضًا؛ يقوم التطبيق بالتسجيل لدى W3sper اعتمادًا على معرّف العقد. يقوم الـ driver بترميز الإدخال إلى بايتات ABI، ثم يفك ترميز قيمة الإرجاع التي يعيدها العقد بعد ذلك.
لقد عاملته مثل ترجمان في مكتب خدمة أرضية بالمطار. يقول المسافر JSON، لكن ساحة الإقلاع لا تتعرف إلا على تنسيق تحميل ثابت؛ يقوم مكتب الترجمة بتغليف الطلب وفقًا لـ schema، ثم عند رحلة العودة يفكّ التغلّيف ليستخرج المخرجات والأحداث. عند إرسال raw bytes عبر HTTP، يتم تسليمها مباشرة إلى العقد؛ وعند إرسال JSON، يتم تحويلها تلقائيًا فقط عندما يكون الـ driver متاحًا. يمكن استخدام get_version للتحقق من الإصدار.
من فضلك أخفِ ذلك خلف الترقية. قد يُرجع الـ driver القديم نجاحًا، لكنه قد يفسر البيانات وفقًا لـ ABI غير محدث. في البيانات الوصفية، فإن driver_available و driver_signature لا يساعدانني إلا في التأكد من هوية الدرايفر. سأثبت تجزئة الملف، وفي testnet سأقارن نفس المدخلات بين raw bytes والنتيجة بعد فك الترميز. كون الصفحة قابلة للقراءة لا يثبت سوى أن سلسلة الترجمة تعمل؛ ما تزال حالة الأصول تتطلب تحققًا مستقلًا.
#dusk $DUSK
عندما كنت أقرأ وثائق W3sper الخاصة بـ Dusk @Dusk Dusk، كنت قد اعتبرت DuskVM استعلامًا عن واجهة JSON عادية. يقوم تجميع عقد Forge بإنتاج data-driver WASM أيضًا؛ يقوم التطبيق بالتسجيل لدى W3sper اعتمادًا على معرّف العقد. يقوم الـ driver بترميز الإدخال إلى بايتات ABI، ثم يفك ترميز قيمة الإرجاع التي يعيدها العقد بعد ذلك.
لقد عاملته مثل ترجمان في مكتب خدمة أرضية بالمطار. يقول المسافر JSON، لكن ساحة الإقلاع لا تتعرف إلا على تنسيق تحميل ثابت؛ يقوم مكتب الترجمة بتغليف الطلب وفقًا لـ schema، ثم عند رحلة العودة يفكّ التغلّيف ليستخرج المخرجات والأحداث. عند إرسال raw bytes عبر HTTP، يتم تسليمها مباشرة إلى العقد؛ وعند إرسال JSON، يتم تحويلها تلقائيًا فقط عندما يكون الـ driver متاحًا. يمكن استخدام get_version للتحقق من الإصدار.
من فضلك أخفِ ذلك خلف الترقية. قد يُرجع الـ driver القديم نجاحًا، لكنه قد يفسر البيانات وفقًا لـ ABI غير محدث. في البيانات الوصفية، فإن driver_available و driver_signature لا يساعدانني إلا في التأكد من هوية الدرايفر. سأثبت تجزئة الملف، وفي testnet سأقارن نفس المدخلات بين raw bytes والنتيجة بعد فك الترميز. كون الصفحة قابلة للقراءة لا يثبت سوى أن سلسلة الترجمة تعمل؛ ما تزال حالة الأصول تتطلب تحققًا مستقلًا.
#dusk $DUSK
لقد عاملته مثل ترجمان في مكتب خدمة أرضية بالمطار. يقول المسافر JSON، لكن ساحة الإقلاع لا تتعرف إلا على تنسيق تحميل ثابت؛ يقوم مكتب الترجمة بتغليف الطلب وفقًا لـ schema، ثم عند رحلة العودة يفكّ التغلّيف ليستخرج المخرجات والأحداث. عند إرسال raw bytes عبر HTTP، يتم تسليمها مباشرة إلى العقد؛ وعند إرسال JSON، يتم تحويلها تلقائيًا فقط عندما يكون الـ driver متاحًا. يمكن استخدام get_version للتحقق من الإصدار.
من فضلك أخفِ ذلك خلف الترقية. قد يُرجع الـ driver القديم نجاحًا، لكنه قد يفسر البيانات وفقًا لـ ABI غير محدث. في البيانات الوصفية، فإن driver_available و driver_signature لا يساعدانني إلا في التأكد من هوية الدرايفر. سأثبت تجزئة الملف، وفي testnet سأقارن نفس المدخلات بين raw bytes والنتيجة بعد فك الترميز. كون الصفحة قابلة للقراءة لا يثبت سوى أن سلسلة الترجمة تعمل؛ ما تزال حالة الأصول تتطلب تحققًا مستقلًا.
#dusk $DUSK
221
·
--
عندما رأيت Boreas، ظننت في البداية أنه مجرد ترقية عادية للإصدار. فعّلت الشبكة الرئيسية Dusk @Dusk_Foundation Rusk 1.7.0 في 10 يونيو 2026 ابتداءً من الكتلة 4,414,095، والتعديل كان في القواعد التي تُستخدم عندما تدخل وحدات بايت المعاملة إلى الشبكة، وتُوضَع داخل الكتل، وتُعاد معالجة السجل القديم. ما يزال بإمكان العميل إرسال تغليف Aegis المدعوم، ويقوم Rusk بالتوحيد القياسي عند نقطة الدخول، ثم يكتب البيانات داخل الكتلة بصيغة دفتر الحسابات الحالية.
أشبّه هذه المعالجة بخزانة إيصالات في غرفة مقاصة. يمكن أن تأتي الإيصالات الخارجية من قالب قديم، لكن قبل دخولها الخزانة يجب أن تُترجم إلى صيغة داخلية موحّدة؛ أما الإيصالات التاريخية فتحافظ على محللاتها القديمة كي يمكن مراجعتها كما هي أثناء التدقيق. يربط Boreas بين تفسير البيانات في mempool، ومُنتِج الكتل، والتحقق في الإجماع، وإعادة تشغيل السجل التاريخي، بحيث لا تؤدي السلسلة نفسها من البايتات إلى حالتين مختلفتين في مراحل مختلفة.
كما رسم التحديث حدودًا واضحة: تتوقف الشبكة الرئيسية عند نقطة إعادة التشغيل عن استقبال معاملات Phoenix الجديدة، وتصبح Moonlight نموذج المعاملة المدعوم حاليًا، بينما تظل كتل Phoenix القديمة قابلة للفك وإعادة التشغيل. تُحفظ أحداث reverted في الأرشيف مع وسم خاص، ولا ينبغي أن يحتسبها المفهرسون ضمن الحالة الصالحة. عندما أوصل Dusk، أتحقق من ارتفاع الشبكة، وإصدار Rusk، ونموذج المعاملة، ثم أراجع ما إذا كان المفهرس يقرأ وسم reverted؛ فإمكانية البحث في السجلات القديمة لا تعني أن المعاملات القديمة ما تزال قابلة للإرسال.
#dusk $DUSK
عندما رأيت Boreas، ظننت في البداية أنه مجرد ترقية عادية للإصدار. فعّلت الشبكة الرئيسية Dusk @Dusk Rusk 1.7.0 في 10 يونيو 2026 ابتداءً من الكتلة 4,414,095، والتعديل كان في القواعد التي تُستخدم عندما تدخل وحدات بايت المعاملة إلى الشبكة، وتُوضَع داخل الكتل، وتُعاد معالجة السجل القديم. ما يزال بإمكان العميل إرسال تغليف Aegis المدعوم، ويقوم Rusk بالتوحيد القياسي عند نقطة الدخول، ثم يكتب البيانات داخل الكتلة بصيغة دفتر الحسابات الحالية.
أشبّه هذه المعالجة بخزانة إيصالات في غرفة مقاصة. يمكن أن تأتي الإيصالات الخارجية من قالب قديم، لكن قبل دخولها الخزانة يجب أن تُترجم إلى صيغة داخلية موحّدة؛ أما الإيصالات التاريخية فتحافظ على محللاتها القديمة كي يمكن مراجعتها كما هي أثناء التدقيق. يربط Boreas بين تفسير البيانات في mempool، ومُنتِج الكتل، والتحقق في الإجماع، وإعادة تشغيل السجل التاريخي، بحيث لا تؤدي السلسلة نفسها من البايتات إلى حالتين مختلفتين في مراحل مختلفة.
كما رسم التحديث حدودًا واضحة: تتوقف الشبكة الرئيسية عند نقطة إعادة التشغيل عن استقبال معاملات Phoenix الجديدة، وتصبح Moonlight نموذج المعاملة المدعوم حاليًا، بينما تظل كتل Phoenix القديمة قابلة للفك وإعادة التشغيل. تُحفظ أحداث reverted في الأرشيف مع وسم خاص، ولا ينبغي أن يحتسبها المفهرسون ضمن الحالة الصالحة. عندما أوصل Dusk، أتحقق من ارتفاع الشبكة، وإصدار Rusk، ونموذج المعاملة، ثم أراجع ما إذا كان المفهرس يقرأ وسم reverted؛ فإمكانية البحث في السجلات القديمة لا تعني أن المعاملات القديمة ما تزال قابلة للإرسال.
#dusk $DUSK
أشبّه هذه المعالجة بخزانة إيصالات في غرفة مقاصة. يمكن أن تأتي الإيصالات الخارجية من قالب قديم، لكن قبل دخولها الخزانة يجب أن تُترجم إلى صيغة داخلية موحّدة؛ أما الإيصالات التاريخية فتحافظ على محللاتها القديمة كي يمكن مراجعتها كما هي أثناء التدقيق. يربط Boreas بين تفسير البيانات في mempool، ومُنتِج الكتل، والتحقق في الإجماع، وإعادة تشغيل السجل التاريخي، بحيث لا تؤدي السلسلة نفسها من البايتات إلى حالتين مختلفتين في مراحل مختلفة.
كما رسم التحديث حدودًا واضحة: تتوقف الشبكة الرئيسية عند نقطة إعادة التشغيل عن استقبال معاملات Phoenix الجديدة، وتصبح Moonlight نموذج المعاملة المدعوم حاليًا، بينما تظل كتل Phoenix القديمة قابلة للفك وإعادة التشغيل. تُحفظ أحداث reverted في الأرشيف مع وسم خاص، ولا ينبغي أن يحتسبها المفهرسون ضمن الحالة الصالحة. عندما أوصل Dusk، أتحقق من ارتفاع الشبكة، وإصدار Rusk، ونموذج المعاملة، ثم أراجع ما إذا كان المفهرس يقرأ وسم reverted؛ فإمكانية البحث في السجلات القديمة لا تعني أن المعاملات القديمة ما تزال قابلة للإرسال.
#dusk $DUSK
162
·
--
عندما كنت أترجم/أراجع مستند دورة حياة المعاملة لـ @Dusk_Foundation Dusk، صححت خطأً واحدًا: تُرجع الواجهة 202 Accepted فقط لتوضّح أن العقدة استلمت الطلب. بعد تقديم توقيع Dusk L1، تقوم العقدة أولًا بعملية admission؛ وعند اجتيازها ينتقل الطلب إلى real mempool ويتم بثّه إلى peers. مُنشئ الكتل ينفّذ العمليات وفق ترتيب gasPrice.
لقد اعتبرتها خط معالجة/تصفية. 202 هو سجل الاستلام في الواجهة الأمامية، وincluded هو الدخول إلى منطقة الانتظار، أما executed فيتطلب أيضًا التحقق من أن err ليس null. حتى بعد قبول الكتلة (accepted)، قد تحدث عملية reverted، إلى أن تقوم blocks/statechange بإعلان finalized، عندها فقط يتم إغلاق/تثبيت السجل. Moonlight يعتمد على تضارب الحساب وnonce، وPhoenix ينظر إلى nullifier؛ والمعاملة المُستبدَلة يجب أن ترفع gasPrice.
سلسلة الأحداث هذه تنطبق فقط على Dusk L1، بينما لدى DuskEVM نموذج sequencer ونموذج finality مختلف. كتبت مستمعًا (listener) سيخزن tx hash وإحداثيات الكتلة، ثم يستخدم onlyFinalized:true للتحقق. أنا لا أتابع إلا included؛ لكن عند حدوث استبدال من العقدة، أو انتهاء الصلاحية، أو الإقصاء بسبب السعة، من السهل اعتبار الحالة المحلية أنها وصلت/تمت. إشعار الاستلام (receipt) هو مجرد سجل الاستلام، أما تأكيد الأموال فيجب أن ينتظر الحالة النهائية.
#dusk $DUSK
عندما كنت أترجم/أراجع مستند دورة حياة المعاملة لـ @Dusk Dusk، صححت خطأً واحدًا: تُرجع الواجهة 202 Accepted فقط لتوضّح أن العقدة استلمت الطلب. بعد تقديم توقيع Dusk L1، تقوم العقدة أولًا بعملية admission؛ وعند اجتيازها ينتقل الطلب إلى real mempool ويتم بثّه إلى peers. مُنشئ الكتل ينفّذ العمليات وفق ترتيب gasPrice.
لقد اعتبرتها خط معالجة/تصفية. 202 هو سجل الاستلام في الواجهة الأمامية، وincluded هو الدخول إلى منطقة الانتظار، أما executed فيتطلب أيضًا التحقق من أن err ليس null. حتى بعد قبول الكتلة (accepted)، قد تحدث عملية reverted، إلى أن تقوم blocks/statechange بإعلان finalized، عندها فقط يتم إغلاق/تثبيت السجل. Moonlight يعتمد على تضارب الحساب وnonce، وPhoenix ينظر إلى nullifier؛ والمعاملة المُستبدَلة يجب أن ترفع gasPrice.
سلسلة الأحداث هذه تنطبق فقط على Dusk L1، بينما لدى DuskEVM نموذج sequencer ونموذج finality مختلف. كتبت مستمعًا (listener) سيخزن tx hash وإحداثيات الكتلة، ثم يستخدم onlyFinalized:true للتحقق. أنا لا أتابع إلا included؛ لكن عند حدوث استبدال من العقدة، أو انتهاء الصلاحية، أو الإقصاء بسبب السعة، من السهل اعتبار الحالة المحلية أنها وصلت/تمت. إشعار الاستلام (receipt) هو مجرد سجل الاستلام، أما تأكيد الأموال فيجب أن ينتظر الحالة النهائية.
#dusk $DUSK
لقد اعتبرتها خط معالجة/تصفية. 202 هو سجل الاستلام في الواجهة الأمامية، وincluded هو الدخول إلى منطقة الانتظار، أما executed فيتطلب أيضًا التحقق من أن err ليس null. حتى بعد قبول الكتلة (accepted)، قد تحدث عملية reverted، إلى أن تقوم blocks/statechange بإعلان finalized، عندها فقط يتم إغلاق/تثبيت السجل. Moonlight يعتمد على تضارب الحساب وnonce، وPhoenix ينظر إلى nullifier؛ والمعاملة المُستبدَلة يجب أن ترفع gasPrice.
سلسلة الأحداث هذه تنطبق فقط على Dusk L1، بينما لدى DuskEVM نموذج sequencer ونموذج finality مختلف. كتبت مستمعًا (listener) سيخزن tx hash وإحداثيات الكتلة، ثم يستخدم onlyFinalized:true للتحقق. أنا لا أتابع إلا included؛ لكن عند حدوث استبدال من العقدة، أو انتهاء الصلاحية، أو الإقصاء بسبب السعة، من السهل اعتبار الحالة المحلية أنها وصلت/تمت. إشعار الاستلام (receipt) هو مجرد سجل الاستلام، أما تأكيد الأموال فيجب أن ينتظر الحالة النهائية.
#dusk $DUSK
184
·
--
كنت أرى سابقًا أن مشكلة أمان @Dusk_Foundation Dusk مجرد ثغرة نقطة واحدة، لكن بعد قراءة تحليل AEGIS اتضح لي أن المخاطر تمتد عبر أربع طبقات حدود. تم الإفصاح عن Dusk في مارس 2026، وقام AEGIS بإصلاح 39 مشكلة في التدقيق الداخلي، منها 7 مسائل بتصنيف Critical؛ أما الأسباب الجذرية فكانت موزعة بين أسماء مستعارة لآلة Piecrust الافتراضية، وإلغاء تسلسل على جانب المضيف، كما شملت ربط استرداد رسوم Phoenix وبناء توقيع BLS، مما أثر على حتمية التنفيذ وذاكرة العقد وسلامة سلسلة الإمداد ومصادقة الإجماع.
قسمتها إلى أربع بوابات تحكم في المخاطر تخص جهة المعاملات: عزل الحالة أثناء وقت التشغيل، والتحقق من البيانات الخارجية قبل التحليل، وربط استرداد الرسوم بالمستندات الأصلية، واعتماد توقيعات الإجماع مع تعيين منحنيات موثوق. أعاد AEGIS تصميم إدارة الجلسات وملكية المثيلات، كما تم فحص اتساق الرسوم في mempool وفي فحص VM معًا، وتم تغيير المسار الآمن لـ BLS إلى نمط RFC 9380 الخاص بـ hash-to-curve مع فصل المجالات.
توضح إصلاحات الـ39 مسألة فقط أن ساحة الهجوم المعروفة تم التعامل معها. وتذكر الجهة الرسمية أنه لم يتم بعد اكتشاف وجود مشكلات حرجة تم استغلالها قبل الترقية، مع إضافة 31 إجراء تعزيز آخر، تغطي وقت التشغيل والشبكة، وتمتد أيضًا إلى التشفير والمحافظ. لاحقًا سأتابع نسبة تغطية ترقية العقد، واختبارات الانحدار، وبيانات الشذوذ على الشبكة الرئيسية؛ ويعرض التصحيح إحداثيات الفحص، لكن السجلات التشغيلية الطويلة فقط هي التي يمكنها التحقق من صلابة خط الدفاع.
#dusk $DUSK
كنت أرى سابقًا أن مشكلة أمان @Dusk Dusk مجرد ثغرة نقطة واحدة، لكن بعد قراءة تحليل AEGIS اتضح لي أن المخاطر تمتد عبر أربع طبقات حدود. تم الإفصاح عن Dusk في مارس 2026، وقام AEGIS بإصلاح 39 مشكلة في التدقيق الداخلي، منها 7 مسائل بتصنيف Critical؛ أما الأسباب الجذرية فكانت موزعة بين أسماء مستعارة لآلة Piecrust الافتراضية، وإلغاء تسلسل على جانب المضيف، كما شملت ربط استرداد رسوم Phoenix وبناء توقيع BLS، مما أثر على حتمية التنفيذ وذاكرة العقد وسلامة سلسلة الإمداد ومصادقة الإجماع.
قسمتها إلى أربع بوابات تحكم في المخاطر تخص جهة المعاملات: عزل الحالة أثناء وقت التشغيل، والتحقق من البيانات الخارجية قبل التحليل، وربط استرداد الرسوم بالمستندات الأصلية، واعتماد توقيعات الإجماع مع تعيين منحنيات موثوق. أعاد AEGIS تصميم إدارة الجلسات وملكية المثيلات، كما تم فحص اتساق الرسوم في mempool وفي فحص VM معًا، وتم تغيير المسار الآمن لـ BLS إلى نمط RFC 9380 الخاص بـ hash-to-curve مع فصل المجالات.
توضح إصلاحات الـ39 مسألة فقط أن ساحة الهجوم المعروفة تم التعامل معها. وتذكر الجهة الرسمية أنه لم يتم بعد اكتشاف وجود مشكلات حرجة تم استغلالها قبل الترقية، مع إضافة 31 إجراء تعزيز آخر، تغطي وقت التشغيل والشبكة، وتمتد أيضًا إلى التشفير والمحافظ. لاحقًا سأتابع نسبة تغطية ترقية العقد، واختبارات الانحدار، وبيانات الشذوذ على الشبكة الرئيسية؛ ويعرض التصحيح إحداثيات الفحص، لكن السجلات التشغيلية الطويلة فقط هي التي يمكنها التحقق من صلابة خط الدفاع.
#dusk $DUSK
قسمتها إلى أربع بوابات تحكم في المخاطر تخص جهة المعاملات: عزل الحالة أثناء وقت التشغيل، والتحقق من البيانات الخارجية قبل التحليل، وربط استرداد الرسوم بالمستندات الأصلية، واعتماد توقيعات الإجماع مع تعيين منحنيات موثوق. أعاد AEGIS تصميم إدارة الجلسات وملكية المثيلات، كما تم فحص اتساق الرسوم في mempool وفي فحص VM معًا، وتم تغيير المسار الآمن لـ BLS إلى نمط RFC 9380 الخاص بـ hash-to-curve مع فصل المجالات.
توضح إصلاحات الـ39 مسألة فقط أن ساحة الهجوم المعروفة تم التعامل معها. وتذكر الجهة الرسمية أنه لم يتم بعد اكتشاف وجود مشكلات حرجة تم استغلالها قبل الترقية، مع إضافة 31 إجراء تعزيز آخر، تغطي وقت التشغيل والشبكة، وتمتد أيضًا إلى التشفير والمحافظ. لاحقًا سأتابع نسبة تغطية ترقية العقد، واختبارات الانحدار، وبيانات الشذوذ على الشبكة الرئيسية؛ ويعرض التصحيح إحداثيات الفحص، لكن السجلات التشغيلية الطويلة فقط هي التي يمكنها التحقق من صلابة خط الدفاع.
#dusk $DUSK
192
·
--
في الليلة الماضية، عندما كنت أتصفح مستندات TermMax الأمنية، اكتشفت أن تغيير الإعدادات الأساسية لا يسري فورًا. إعدادات Vault في TermMax تتضمن ثلاث خطوات: Submit → Wait → Accept: يقوم CURATOR بتقديم التغييرات، ويستطيع GUARDIAN خلال فترة الانتظار مراجعتها أو إلغاؤها، ويحتفظ Vault Owner بسلطة الإشراف. فترة الانتظار الافتراضية هي يوم واحد، ويمكن ضبطها ضمن النطاق من 1 إلى 30 يومًا.
أعتبرها أشبه بتذكرة تغيير لإحدى جهات التداول: يتم إغلاق المقترح، ثم يقوم فريق مراقبة المخاطر المناوب بمراجعته، ولا يُسمح بتحميله إلى قاعدة البيانات إلا بعد انتهاء العدّاد. التغييرات الخاصة بمصدر الـ Oracle لا يمكن تقديمها واستلامها إلا بواسطة DEFAULT_ADMIN_ROLE، ويتم تحديثها بشكل منفصل لكل أصل؛ وعند تعطل المصدر الأساسي يمكن التبديل فورًا إلى مصدر احتياطي. هذا التصميم يضيف نافذة مراقبة كما ويُدخل توزيع الصلاحيات الثلاث إلى فحوصات الأمان.
القفل الزمني يؤخر فقط تفعيل الإعدادات أو تغيير مصادر البيانات، لكنه لا يمكنه إثبات أن السعر الحالي دقيق، ولا يمكنه أن يحل محل المراقبة على السلسلة. ترتيب فحوصاتي هو: أولًا أراجع قائمة التنفيذ والوقت المتبقي، ثم أتحقق من سجلات الإلغاء وعناوين الأدوار، وأخيرًا أقارن الانحرافات بين المصدر الأساسي والاحتياطي وحالة التبديل. إذا لم يقم GUARDIAN بالمراجعة لفترة طويلة، وكانت مفاتيح الإدارة مركزة، فانتظار يوم إضافي يعني فقط تأجيل تجسيد المخاطر ليوم لاحق. الهيكل يضع كوابحًا، لكن من يراقب لوحة القياس عليه أن يجيب بما تسمح به سجلات التشغيل.@termmax
#termmax
في الليلة الماضية، عندما كنت أتصفح مستندات TermMax الأمنية، اكتشفت أن تغيير الإعدادات الأساسية لا يسري فورًا. إعدادات Vault في TermMax تتضمن ثلاث خطوات: Submit → Wait → Accept: يقوم CURATOR بتقديم التغييرات، ويستطيع GUARDIAN خلال فترة الانتظار مراجعتها أو إلغاؤها، ويحتفظ Vault Owner بسلطة الإشراف. فترة الانتظار الافتراضية هي يوم واحد، ويمكن ضبطها ضمن النطاق من 1 إلى 30 يومًا.
أعتبرها أشبه بتذكرة تغيير لإحدى جهات التداول: يتم إغلاق المقترح، ثم يقوم فريق مراقبة المخاطر المناوب بمراجعته، ولا يُسمح بتحميله إلى قاعدة البيانات إلا بعد انتهاء العدّاد. التغييرات الخاصة بمصدر الـ Oracle لا يمكن تقديمها واستلامها إلا بواسطة DEFAULT_ADMIN_ROLE، ويتم تحديثها بشكل منفصل لكل أصل؛ وعند تعطل المصدر الأساسي يمكن التبديل فورًا إلى مصدر احتياطي. هذا التصميم يضيف نافذة مراقبة كما ويُدخل توزيع الصلاحيات الثلاث إلى فحوصات الأمان.
القفل الزمني يؤخر فقط تفعيل الإعدادات أو تغيير مصادر البيانات، لكنه لا يمكنه إثبات أن السعر الحالي دقيق، ولا يمكنه أن يحل محل المراقبة على السلسلة. ترتيب فحوصاتي هو: أولًا أراجع قائمة التنفيذ والوقت المتبقي، ثم أتحقق من سجلات الإلغاء وعناوين الأدوار، وأخيرًا أقارن الانحرافات بين المصدر الأساسي والاحتياطي وحالة التبديل. إذا لم يقم GUARDIAN بالمراجعة لفترة طويلة، وكانت مفاتيح الإدارة مركزة، فانتظار يوم إضافي يعني فقط تأجيل تجسيد المخاطر ليوم لاحق. الهيكل يضع كوابحًا، لكن من يراقب لوحة القياس عليه أن يجيب بما تسمح به سجلات التشغيل.@TermMax
#termmax
أعتبرها أشبه بتذكرة تغيير لإحدى جهات التداول: يتم إغلاق المقترح، ثم يقوم فريق مراقبة المخاطر المناوب بمراجعته، ولا يُسمح بتحميله إلى قاعدة البيانات إلا بعد انتهاء العدّاد. التغييرات الخاصة بمصدر الـ Oracle لا يمكن تقديمها واستلامها إلا بواسطة DEFAULT_ADMIN_ROLE، ويتم تحديثها بشكل منفصل لكل أصل؛ وعند تعطل المصدر الأساسي يمكن التبديل فورًا إلى مصدر احتياطي. هذا التصميم يضيف نافذة مراقبة كما ويُدخل توزيع الصلاحيات الثلاث إلى فحوصات الأمان.
القفل الزمني يؤخر فقط تفعيل الإعدادات أو تغيير مصادر البيانات، لكنه لا يمكنه إثبات أن السعر الحالي دقيق، ولا يمكنه أن يحل محل المراقبة على السلسلة. ترتيب فحوصاتي هو: أولًا أراجع قائمة التنفيذ والوقت المتبقي، ثم أتحقق من سجلات الإلغاء وعناوين الأدوار، وأخيرًا أقارن الانحرافات بين المصدر الأساسي والاحتياطي وحالة التبديل. إذا لم يقم GUARDIAN بالمراجعة لفترة طويلة، وكانت مفاتيح الإدارة مركزة، فانتظار يوم إضافي يعني فقط تأجيل تجسيد المخاطر ليوم لاحق. الهيكل يضع كوابحًا، لكن من يراقب لوحة القياس عليه أن يجيب بما تسمح به سجلات التشغيل.@TermMax
#termmax
183
·
--
كنت أرى في السابق مشكلة أمان Dusk على أنها ثغرة أحادية، لكن بعد قراءة تحليل AEGIS أدركت أن المخاطر تمتد عبر أربع حدود. تم الإفصاح عن @Dusk_Foundation Dusk في مارس 2026، وأصلحت AEGIS 39 مشكلة ضمن التدقيق الداخلي، منها 7 مشكلات مُصنّفة كـ Critical. وترتكز أربعة أسباب جذرية على أسماء مستعارة لآلة Piecrust الافتراضية، وإلغاء تسلسل (deserialization) من جانب المضيف، وربط ردّ رسوم Phoenix بالإيصالات الأصلية، وبناء توقيعات BLS؛ وقد أثّر ذلك على التنفيذ الحتمي، وذاكرة العقد داخلية، وسلامة سلسلة التوريد، والتحقق من الاعتماد/التوافق (consensus).
قمت بتقسيمها إلى أربع بوابات ضبط مخاطر في البورصة: حالة عزل الطرف النهائي، والتحقق قبل إدخال البيانات الخارجية إلى مركز البيانات، ومطابقة رد الرسوم مع الإيصال/المستند الأصلي، وتأكيد توقيع التوافق (consensus) لضمان أن ختم التوقيع لا يمكن تزويره. أعادت AEGIS تصميم الجلسات وملكية المثيلات بالكامل، وأصبح استعلام المضيف يتضمن التحقق قبل إلغاء التسلسل. كما تم فحص اتساق الرسوم في mempool وفي VM في الوقت نفسه، وتم تعديل مسار أمان BLS ليعتمد أسلوب RFC 9380 بصيغة hash-to-curve مع فصل المجال (domain separation).
لا يمكن أن توضح 39 عملية إصلاح سوى أن سطح الهجوم المعروف تم التعامل معه. وتقول الجهة الرسمية إنه لم يتم اكتشاف مشكلات حرجة تم استغلالها قبل الترقية حتى الآن، مع إضافة 31 عملية تقوية أثناء التشغيل، وربط/شبكات، وتشفير، ومحفظة. سأتولى لاحقًا متابعة مدى تغطية ترقية العقد، واختبارات الانحدار (regression)، والمراجعة الخارجية، وبيانات غير طبيعية على الشبكة الرئيسية؛ فالإصلاحات المنشورة وفّرت إحداثيات للفحص، لكن سجلات التشغيل المستمرة هي التي ستحدد ما إذا كانت هذه الخطوط الدفاعية موثوقة.#dusk $DUSK
كنت أرى في السابق مشكلة أمان Dusk على أنها ثغرة أحادية، لكن بعد قراءة تحليل AEGIS أدركت أن المخاطر تمتد عبر أربع حدود. تم الإفصاح عن @Dusk Dusk في مارس 2026، وأصلحت AEGIS 39 مشكلة ضمن التدقيق الداخلي، منها 7 مشكلات مُصنّفة كـ Critical. وترتكز أربعة أسباب جذرية على أسماء مستعارة لآلة Piecrust الافتراضية، وإلغاء تسلسل (deserialization) من جانب المضيف، وربط ردّ رسوم Phoenix بالإيصالات الأصلية، وبناء توقيعات BLS؛ وقد أثّر ذلك على التنفيذ الحتمي، وذاكرة العقد داخلية، وسلامة سلسلة التوريد، والتحقق من الاعتماد/التوافق (consensus).
قمت بتقسيمها إلى أربع بوابات ضبط مخاطر في البورصة: حالة عزل الطرف النهائي، والتحقق قبل إدخال البيانات الخارجية إلى مركز البيانات، ومطابقة رد الرسوم مع الإيصال/المستند الأصلي، وتأكيد توقيع التوافق (consensus) لضمان أن ختم التوقيع لا يمكن تزويره. أعادت AEGIS تصميم الجلسات وملكية المثيلات بالكامل، وأصبح استعلام المضيف يتضمن التحقق قبل إلغاء التسلسل. كما تم فحص اتساق الرسوم في mempool وفي VM في الوقت نفسه، وتم تعديل مسار أمان BLS ليعتمد أسلوب RFC 9380 بصيغة hash-to-curve مع فصل المجال (domain separation).
لا يمكن أن توضح 39 عملية إصلاح سوى أن سطح الهجوم المعروف تم التعامل معه. وتقول الجهة الرسمية إنه لم يتم اكتشاف مشكلات حرجة تم استغلالها قبل الترقية حتى الآن، مع إضافة 31 عملية تقوية أثناء التشغيل، وربط/شبكات، وتشفير، ومحفظة. سأتولى لاحقًا متابعة مدى تغطية ترقية العقد، واختبارات الانحدار (regression)، والمراجعة الخارجية، وبيانات غير طبيعية على الشبكة الرئيسية؛ فالإصلاحات المنشورة وفّرت إحداثيات للفحص، لكن سجلات التشغيل المستمرة هي التي ستحدد ما إذا كانت هذه الخطوط الدفاعية موثوقة.#dusk $DUSK
قمت بتقسيمها إلى أربع بوابات ضبط مخاطر في البورصة: حالة عزل الطرف النهائي، والتحقق قبل إدخال البيانات الخارجية إلى مركز البيانات، ومطابقة رد الرسوم مع الإيصال/المستند الأصلي، وتأكيد توقيع التوافق (consensus) لضمان أن ختم التوقيع لا يمكن تزويره. أعادت AEGIS تصميم الجلسات وملكية المثيلات بالكامل، وأصبح استعلام المضيف يتضمن التحقق قبل إلغاء التسلسل. كما تم فحص اتساق الرسوم في mempool وفي VM في الوقت نفسه، وتم تعديل مسار أمان BLS ليعتمد أسلوب RFC 9380 بصيغة hash-to-curve مع فصل المجال (domain separation).
لا يمكن أن توضح 39 عملية إصلاح سوى أن سطح الهجوم المعروف تم التعامل معه. وتقول الجهة الرسمية إنه لم يتم اكتشاف مشكلات حرجة تم استغلالها قبل الترقية حتى الآن، مع إضافة 31 عملية تقوية أثناء التشغيل، وربط/شبكات، وتشفير، ومحفظة. سأتولى لاحقًا متابعة مدى تغطية ترقية العقد، واختبارات الانحدار (regression)، والمراجعة الخارجية، وبيانات غير طبيعية على الشبكة الرئيسية؛ فالإصلاحات المنشورة وفّرت إحداثيات للفحص، لكن سجلات التشغيل المستمرة هي التي ستحدد ما إذا كانت هذه الخطوط الدفاعية موثوقة.#dusk $DUSK
211
·
--
لقد واجهت سابقًا تخلفًا عن سداد قروض ذات أجل محدد، وكنت دائمًا أظن أنه بعد انتهاء التصفية سيحصل المقرضون فقط على أصولهم الأصلية. إن معالجة @termmax TermMax تشبه أكثر عملية تصفية/بيع ضمانٍ مشروطٍ بوقت: عندما يصل LTV الخاص بالقرض إلى LLTV، أو عندما لا يسدد المقترض عند الاستحقاق، تتفعّل التصفية. وبعد التخلف عند الاستحقاق، فإن نافذة التصفية المفتوحة التي تقدمها الوثائق الرسمية هي ساعتان.
تحسب عقوبة التصفية بنسبة 10% من قيمة الديون التي تمت معالجتها: 5% منها تُمنح لمن يقوم بالتصفية، و5% أخرى تُودَع في احتياطي البروتوكول. إذا لم تتجاوز الديون غير المسددة 10,000 دولار أمريكي، فيمكن لمن يقوم بالتصفية معالجة ما يصل إلى نصفها مرة واحدة فقط. والهدف هو خفض LTV حتى تعود المراكز إلى حالة صحية، وليس نقل/تفريغ الضمانات بالكامل فورًا. لقد فهمتها كتجزئة في المزاد: تُباع الأصول أولًا حتى ينخفض المستوى تحت خط المخاطر، ثم يُنظر في كيفية التعامل مع الجزء المتبقي.
إذا انتهت النافذة وما زالت توجد ديون لم تُصفَّ، ستقوم TermMax بإطلاق التسليم المادي (Physical Delivery). في هذه المرحلة قد يكون تجمع الاسترداد (赎回池) محمّلًا في الوقت نفسه بالأصول الأساسية والأصول الضمانية، ويحصل حاملو FT على الاثنين بنسبة الحصص، دون ضمان استرجاع كامل الأموال بنفس العملة الأصلية. وإذا أعطت الأوراكل الخارجية سعرًا غير صحيح، فقد يؤدي ذلك إلى تصفية خاطئة أو نقص في قيمة الضمان. لن أركز فقط على سعر الفائدة الثابت؛ بل سأتحقق أيضًا من LLTV وسيولة الضمانات، وسأعيد التحقق من مصدر الأسعار. لقد حددوا موعد الاستحقاق بالضبط، لكنهم لم يزيلوا تكلفة التخلف عن السداد نيابةً عن أي شخص. #termmax
لقد واجهت سابقًا تخلفًا عن سداد قروض ذات أجل محدد، وكنت دائمًا أظن أنه بعد انتهاء التصفية سيحصل المقرضون فقط على أصولهم الأصلية. إن معالجة @TermMax TermMax تشبه أكثر عملية تصفية/بيع ضمانٍ مشروطٍ بوقت: عندما يصل LTV الخاص بالقرض إلى LLTV، أو عندما لا يسدد المقترض عند الاستحقاق، تتفعّل التصفية. وبعد التخلف عند الاستحقاق، فإن نافذة التصفية المفتوحة التي تقدمها الوثائق الرسمية هي ساعتان.
تحسب عقوبة التصفية بنسبة 10% من قيمة الديون التي تمت معالجتها: 5% منها تُمنح لمن يقوم بالتصفية، و5% أخرى تُودَع في احتياطي البروتوكول. إذا لم تتجاوز الديون غير المسددة 10,000 دولار أمريكي، فيمكن لمن يقوم بالتصفية معالجة ما يصل إلى نصفها مرة واحدة فقط. والهدف هو خفض LTV حتى تعود المراكز إلى حالة صحية، وليس نقل/تفريغ الضمانات بالكامل فورًا. لقد فهمتها كتجزئة في المزاد: تُباع الأصول أولًا حتى ينخفض المستوى تحت خط المخاطر، ثم يُنظر في كيفية التعامل مع الجزء المتبقي.
إذا انتهت النافذة وما زالت توجد ديون لم تُصفَّ، ستقوم TermMax بإطلاق التسليم المادي (Physical Delivery). في هذه المرحلة قد يكون تجمع الاسترداد (赎回池) محمّلًا في الوقت نفسه بالأصول الأساسية والأصول الضمانية، ويحصل حاملو FT على الاثنين بنسبة الحصص، دون ضمان استرجاع كامل الأموال بنفس العملة الأصلية. وإذا أعطت الأوراكل الخارجية سعرًا غير صحيح، فقد يؤدي ذلك إلى تصفية خاطئة أو نقص في قيمة الضمان. لن أركز فقط على سعر الفائدة الثابت؛ بل سأتحقق أيضًا من LLTV وسيولة الضمانات، وسأعيد التحقق من مصدر الأسعار. لقد حددوا موعد الاستحقاق بالضبط، لكنهم لم يزيلوا تكلفة التخلف عن السداد نيابةً عن أي شخص. #termmax
تحسب عقوبة التصفية بنسبة 10% من قيمة الديون التي تمت معالجتها: 5% منها تُمنح لمن يقوم بالتصفية، و5% أخرى تُودَع في احتياطي البروتوكول. إذا لم تتجاوز الديون غير المسددة 10,000 دولار أمريكي، فيمكن لمن يقوم بالتصفية معالجة ما يصل إلى نصفها مرة واحدة فقط. والهدف هو خفض LTV حتى تعود المراكز إلى حالة صحية، وليس نقل/تفريغ الضمانات بالكامل فورًا. لقد فهمتها كتجزئة في المزاد: تُباع الأصول أولًا حتى ينخفض المستوى تحت خط المخاطر، ثم يُنظر في كيفية التعامل مع الجزء المتبقي.
إذا انتهت النافذة وما زالت توجد ديون لم تُصفَّ، ستقوم TermMax بإطلاق التسليم المادي (Physical Delivery). في هذه المرحلة قد يكون تجمع الاسترداد (赎回池) محمّلًا في الوقت نفسه بالأصول الأساسية والأصول الضمانية، ويحصل حاملو FT على الاثنين بنسبة الحصص، دون ضمان استرجاع كامل الأموال بنفس العملة الأصلية. وإذا أعطت الأوراكل الخارجية سعرًا غير صحيح، فقد يؤدي ذلك إلى تصفية خاطئة أو نقص في قيمة الضمان. لن أركز فقط على سعر الفائدة الثابت؛ بل سأتحقق أيضًا من LLTV وسيولة الضمانات، وسأعيد التحقق من مصدر الأسعار. لقد حددوا موعد الاستحقاق بالضبط، لكنهم لم يزيلوا تكلفة التخلف عن السداد نيابةً عن أي شخص. #termmax
239
·
--
في الليلة الماضية كنت ألاحق عملية تحويل على متصفح للبلوكات، وظللت أراقب لساعات دون أن أجد تركيبة مألوفة من العنوان والمبلغ. أعاد Dusk إلى ذهني فهم “قابلية التتبع على السلسلة”: معاملات Phoenix لا تُظهر للعموم المرسلَ والمستلم ومبلغ التحويل؛ يمكن فقط للمشاركين في المعاملة ولمن يملك view key الاطلاع على هذه التفاصيل. أما Moonlight فموجه لعرض الأرصدة بشكل عام والتحويلات بشفافية.
تخيّلتها كغرفة مَسْحَة مزودة بزجاج أحادي الاتجاه. يستطيع من بالخارج التأكد أن الغرفة تعمل، ويمكن للمتصفح الاستمرار في عرض نوع المعاملة، وكذلك—بحسب نموذج المعاملة والعقد—بيانات payload الوصفية وأتعاب المعاملة وgas. أما تفاصيل السجل داخل الغرفة فلا تُفتح إلا لمن يحصل على الصلاحية. خصوصية @Dusk_Foundation Dusk لا تُطفئ السلسلة بأكملها، بل تفكك سؤال “من يستطيع رؤية ماذا” إلى مستويات صلاحيات مختلفة.
والحدود مخبأة هنا أيضاً. إذا اختار المطورون نموذجاً عاماً، أو أدرج العقد محتوى حساساً ضمن بيانات وصفية مرئية، فلن يقوم Dusk بحجب ما يظهر تلقائياً نيابةً عن التطبيق. وإذا فلتت إدارة view key والتفويضات، فقد تفشل الخصوصية أيضاً. عندما أبحث عن معاملة Dusk، لا أسأل فقط إن كانت مُشفّرة، بل أتأكد أيضاً هل تمر عبر Phoenix أم Moonlight، وما الذي كشفه العقد. الخصوصية الاحترافية ليست أن لا يراها أحد، بل أن لا يراها إلا من يجب أن يراها.
#dusk $DUSK
في الليلة الماضية كنت ألاحق عملية تحويل على متصفح للبلوكات، وظللت أراقب لساعات دون أن أجد تركيبة مألوفة من العنوان والمبلغ. أعاد Dusk إلى ذهني فهم “قابلية التتبع على السلسلة”: معاملات Phoenix لا تُظهر للعموم المرسلَ والمستلم ومبلغ التحويل؛ يمكن فقط للمشاركين في المعاملة ولمن يملك view key الاطلاع على هذه التفاصيل. أما Moonlight فموجه لعرض الأرصدة بشكل عام والتحويلات بشفافية.
تخيّلتها كغرفة مَسْحَة مزودة بزجاج أحادي الاتجاه. يستطيع من بالخارج التأكد أن الغرفة تعمل، ويمكن للمتصفح الاستمرار في عرض نوع المعاملة، وكذلك—بحسب نموذج المعاملة والعقد—بيانات payload الوصفية وأتعاب المعاملة وgas. أما تفاصيل السجل داخل الغرفة فلا تُفتح إلا لمن يحصل على الصلاحية. خصوصية @Dusk Dusk لا تُطفئ السلسلة بأكملها، بل تفكك سؤال “من يستطيع رؤية ماذا” إلى مستويات صلاحيات مختلفة.
والحدود مخبأة هنا أيضاً. إذا اختار المطورون نموذجاً عاماً، أو أدرج العقد محتوى حساساً ضمن بيانات وصفية مرئية، فلن يقوم Dusk بحجب ما يظهر تلقائياً نيابةً عن التطبيق. وإذا فلتت إدارة view key والتفويضات، فقد تفشل الخصوصية أيضاً. عندما أبحث عن معاملة Dusk، لا أسأل فقط إن كانت مُشفّرة، بل أتأكد أيضاً هل تمر عبر Phoenix أم Moonlight، وما الذي كشفه العقد. الخصوصية الاحترافية ليست أن لا يراها أحد، بل أن لا يراها إلا من يجب أن يراها.
#dusk $DUSK
تخيّلتها كغرفة مَسْحَة مزودة بزجاج أحادي الاتجاه. يستطيع من بالخارج التأكد أن الغرفة تعمل، ويمكن للمتصفح الاستمرار في عرض نوع المعاملة، وكذلك—بحسب نموذج المعاملة والعقد—بيانات payload الوصفية وأتعاب المعاملة وgas. أما تفاصيل السجل داخل الغرفة فلا تُفتح إلا لمن يحصل على الصلاحية. خصوصية @Dusk Dusk لا تُطفئ السلسلة بأكملها، بل تفكك سؤال “من يستطيع رؤية ماذا” إلى مستويات صلاحيات مختلفة.
والحدود مخبأة هنا أيضاً. إذا اختار المطورون نموذجاً عاماً، أو أدرج العقد محتوى حساساً ضمن بيانات وصفية مرئية، فلن يقوم Dusk بحجب ما يظهر تلقائياً نيابةً عن التطبيق. وإذا فلتت إدارة view key والتفويضات، فقد تفشل الخصوصية أيضاً. عندما أبحث عن معاملة Dusk، لا أسأل فقط إن كانت مُشفّرة، بل أتأكد أيضاً هل تمر عبر Phoenix أم Moonlight، وما الذي كشفه العقد. الخصوصية الاحترافية ليست أن لا يراها أحد، بل أن لا يراها إلا من يجب أن يراها.
#dusk $DUSK
199
·
--
我以前挂单只填价格和数量，觉得利率市场也就那回事。TermMax 的 Range Order 改了我的看法：做市者不是报出一个固定 APR，而是把不同资金区间写成连续定价曲线。成交量沿曲线移动，每段都能设置利率边界与数量阈值，同一市场也可以同时放入多张 Range Order，让资金选择愿意接受的报价。
我把它理解成分段计价的批发柜台。小单先吃靠前的价格，大单继续向后扫，最终拿到的平均利率自然不同。TermMax 可以只做出借曲线，也可以只做借款曲线；双向 Range Order 会同时管理借入与贷出两侧，做市者靠两条曲线之间的价差获取收入。利率在成交时锁定，却不代表每个人都成交在同一个点。
难处其实是曲线怎么画。官方风险文档提醒，报价偏离市场可能遭遇逆向选择；订单没人接，资金会闲置；大额成交消耗深度，滑点还会放大；期限设置不当也会造成现金流错配。我不会只看页面上最显眼的 APR，而会检查曲线形状与可成交深度，再看两侧价差和到期日。TermMax 把定价权交给做市者，也把定价错误的成本一并交了过去。
@termmax #termmax
我以前挂单只填价格和数量，觉得利率市场也就那回事。TermMax 的 Range Order 改了我的看法：做市者不是报出一个固定 APR，而是把不同资金区间写成连续定价曲线。成交量沿曲线移动，每段都能设置利率边界与数量阈值，同一市场也可以同时放入多张 Range Order，让资金选择愿意接受的报价。
我把它理解成分段计价的批发柜台。小单先吃靠前的价格，大单继续向后扫，最终拿到的平均利率自然不同。TermMax 可以只做出借曲线，也可以只做借款曲线；双向 Range Order 会同时管理借入与贷出两侧，做市者靠两条曲线之间的价差获取收入。利率在成交时锁定，却不代表每个人都成交在同一个点。
难处其实是曲线怎么画。官方风险文档提醒，报价偏离市场可能遭遇逆向选择；订单没人接，资金会闲置；大额成交消耗深度，滑点还会放大；期限设置不当也会造成现金流错配。我不会只看页面上最显眼的 APR，而会检查曲线形状与可成交深度，再看两侧价差和到期日。TermMax 把定价权交给做市者，也把定价错误的成本一并交了过去。
@TermMax #termmax
我把它理解成分段计价的批发柜台。小单先吃靠前的价格，大单继续向后扫，最终拿到的平均利率自然不同。TermMax 可以只做出借曲线，也可以只做借款曲线；双向 Range Order 会同时管理借入与贷出两侧，做市者靠两条曲线之间的价差获取收入。利率在成交时锁定，却不代表每个人都成交在同一个点。
难处其实是曲线怎么画。官方风险文档提醒，报价偏离市场可能遭遇逆向选择；订单没人接，资金会闲置；大额成交消耗深度，滑点还会放大；期限设置不当也会造成现金流错配。我不会只看页面上最显眼的 APR，而会检查曲线形状与可成交深度，再看两侧价差和到期日。TermMax 把定价权交给做市者，也把定价错误的成本一并交了过去。
@TermMax #termmax
258
·
--
عندما كنت أتصفح مستندات Dusk الليلة الماضية، اكتشفت أنني طوال الوقت فهمت عبارة “دعم EVM” بطريقة مبسطة للغاية. لم تقم Dusk بحشر كل شيء داخل آلة افتراضية واحدة: يمكن للتطبيقات المألوفة لدى مطوري Solidity وFoundry أن تسلك طريق DuskEVM، مع الدفع مقابل الغاز باستخدام @Dusk_Foundation DUSK، ثم تُحال بيانات الدفعات والالتزامات الخاصة بالحالة إلى DuskDS ليتم التسوية؛ أما إذا كنت تحتاج خصوصية أصلية وقدرات على المعرفة الصفرية، أو عقودًا تتحكم بأصول على مستوى البروتوكول، فيمكن تشغيلها مباشرة على DuskVM باستخدام Rust/WASM.
فهمته على أنه جهازي تحكم لنفس جهة تنفيذ المعاملات. واحد يحتفظ بأزرار مألوفة، ما يسرّع عملية الانتقال؛ والآخر قريب من الخزنة على المستوى الأساسي، ويمكنه استدعاء قواعد أكثر أصالة، وفي النهاية يعود الجميع إلى نفس قاعدة التسوية لتأكيد دفتر الحسابات. هذا الاختيار أهم من مجرد عبارة “التوافق مع EVM”، لأنه يفصل كفاءة التطوير عن القدرات الأصلية.
لكن المسارين معًا يضيفان أيضًا تعقيدًا في الربط والتفاعل عبر الطبقات، كما يتطلب حُكمًا دقيقًا على الحالة. يوضح المستند الرسمي بوضوح أن التغليف السريع لـ DuskEVM لا يعني أنه قد تمّت التسوية بالفعل على DuskDS؛ لن أكتفي بالنظر إلى عرض الصفحة على أنه “نجح” ثم اعتباره اكتمل نهائيًا. لاحقًا، يجب التأكد مما إذا كانت تجربة ما عبر الطبقات سلسة، وما إذا كانت الأدوات ناضجة، وهل يتزايد حجم العقود الحقيقية. البنية تمنح خيارًا؛ واختيارك هو الذي يعطي الإجابة.
#dusk $DUSK
عندما كنت أتصفح مستندات Dusk الليلة الماضية، اكتشفت أنني طوال الوقت فهمت عبارة “دعم EVM” بطريقة مبسطة للغاية. لم تقم Dusk بحشر كل شيء داخل آلة افتراضية واحدة: يمكن للتطبيقات المألوفة لدى مطوري Solidity وFoundry أن تسلك طريق DuskEVM، مع الدفع مقابل الغاز باستخدام @Dusk DUSK، ثم تُحال بيانات الدفعات والالتزامات الخاصة بالحالة إلى DuskDS ليتم التسوية؛ أما إذا كنت تحتاج خصوصية أصلية وقدرات على المعرفة الصفرية، أو عقودًا تتحكم بأصول على مستوى البروتوكول، فيمكن تشغيلها مباشرة على DuskVM باستخدام Rust/WASM.
فهمته على أنه جهازي تحكم لنفس جهة تنفيذ المعاملات. واحد يحتفظ بأزرار مألوفة، ما يسرّع عملية الانتقال؛ والآخر قريب من الخزنة على المستوى الأساسي، ويمكنه استدعاء قواعد أكثر أصالة، وفي النهاية يعود الجميع إلى نفس قاعدة التسوية لتأكيد دفتر الحسابات. هذا الاختيار أهم من مجرد عبارة “التوافق مع EVM”، لأنه يفصل كفاءة التطوير عن القدرات الأصلية.
لكن المسارين معًا يضيفان أيضًا تعقيدًا في الربط والتفاعل عبر الطبقات، كما يتطلب حُكمًا دقيقًا على الحالة. يوضح المستند الرسمي بوضوح أن التغليف السريع لـ DuskEVM لا يعني أنه قد تمّت التسوية بالفعل على DuskDS؛ لن أكتفي بالنظر إلى عرض الصفحة على أنه “نجح” ثم اعتباره اكتمل نهائيًا. لاحقًا، يجب التأكد مما إذا كانت تجربة ما عبر الطبقات سلسة، وما إذا كانت الأدوات ناضجة، وهل يتزايد حجم العقود الحقيقية. البنية تمنح خيارًا؛ واختيارك هو الذي يعطي الإجابة.
#dusk $DUSK
فهمته على أنه جهازي تحكم لنفس جهة تنفيذ المعاملات. واحد يحتفظ بأزرار مألوفة، ما يسرّع عملية الانتقال؛ والآخر قريب من الخزنة على المستوى الأساسي، ويمكنه استدعاء قواعد أكثر أصالة، وفي النهاية يعود الجميع إلى نفس قاعدة التسوية لتأكيد دفتر الحسابات. هذا الاختيار أهم من مجرد عبارة “التوافق مع EVM”، لأنه يفصل كفاءة التطوير عن القدرات الأصلية.
لكن المسارين معًا يضيفان أيضًا تعقيدًا في الربط والتفاعل عبر الطبقات، كما يتطلب حُكمًا دقيقًا على الحالة. يوضح المستند الرسمي بوضوح أن التغليف السريع لـ DuskEVM لا يعني أنه قد تمّت التسوية بالفعل على DuskDS؛ لن أكتفي بالنظر إلى عرض الصفحة على أنه “نجح” ثم اعتباره اكتمل نهائيًا. لاحقًا، يجب التأكد مما إذا كانت تجربة ما عبر الطبقات سلسة، وما إذا كانت الأدوات ناضجة، وهل يتزايد حجم العقود الحقيقية. البنية تمنح خيارًا؛ واختيارك هو الذي يعطي الإجابة.
#dusk $DUSK
204
·
--
في عام 2021 لعبت بعملة خصوصية، وكانت عمليات التحويل مُخفية بإحكام لدرجة أنني أنا نفسي واجهت صعوبة في تتبع الحسابات. لاحقًا أزالتها إحدى منصات التداول من الخدمة، لأنها لم تستطع اجتياز التدقيق. ثم جرّبت سلسلة أخرى تكون فيها كل المعاملات شفافة تمامًا؛ فكانت سجلات التداول مكشوفة على متصفح البلوكتشين ويمكن لأي شخص الاطلاع عليها. في تلك الفترة ظللت أفكر: لماذا يجب أن نختار بين «إخفاء كامل» و«كشف كامل»؟
كانت الإجابة التي قدمها <c-1/>@Dusk_Foundation Dusk هي: لا داعي للاختيار. فهي ليست بحاجة إلى إخفاء كل شيء، ولا تجعل كل شيء علنًا؛ بل تحوّل الخصوصية إلى قرص يمكن ضبطه. في الطبقة الأساسية، تُستخدم إثباتات المعرفة الصفرية PLONK والتشفير المتماثل لإخفاء مبلغ المعاملة وعناوينها بالكامل عن الجميع، لكن عقدة الرقابة المحددة يمكنها التحقق فورًا من حالة الامتثال. عند الحاجة إلى التدقيق تكون الرقابة شفافة، وعند عدم الحاجة يتم الحفاظ على الخصوصية أمام الجمهور.
بعد إطلاق الشبكة الرئيسية في يناير، يدعم DuskEVM انتقالًا سلسًا عبر Solidity، لتصبح بيئة تطوير المطورين مماثلة لبيئة Ethereum. في مايو، تعاونت NPEX مع Quantoz لإطلاق EURQ، عملة يورو مستقرة قابلة للبرمجة على Dusk، ومع وجود أكثر من 300 مليون يورو من الأوراق المالية المُرمّزة قيد التشغيل بالفعل، فهذا يثبت أن النموذج الكامل يتم التحقق منه عمليًا على أرض الواقع. حلّ إثباتات المعرفة الصفرية لا يتمثل في «هل يمكن الإخفاء أم لا»، بل في «من الذي يجب أن يرى، وبقدر ما يجب أن يرى».
إذا كانت معاملات السلسلة يمكن «إظهارها بشكل انتقائي»، لمن ترغب أكثر في إخفاء نشاطك على السلسلة؟ شاركنا في قسم التعليقات.
#dusk $DUSK
في عام 2021 لعبت بعملة خصوصية، وكانت عمليات التحويل مُخفية بإحكام لدرجة أنني أنا نفسي واجهت صعوبة في تتبع الحسابات. لاحقًا أزالتها إحدى منصات التداول من الخدمة، لأنها لم تستطع اجتياز التدقيق. ثم جرّبت سلسلة أخرى تكون فيها كل المعاملات شفافة تمامًا؛ فكانت سجلات التداول مكشوفة على متصفح البلوكتشين ويمكن لأي شخص الاطلاع عليها. في تلك الفترة ظللت أفكر: لماذا يجب أن نختار بين «إخفاء كامل» و«كشف كامل»؟
كانت الإجابة التي قدمها <c-1/>@Dusk Dusk هي: لا داعي للاختيار. فهي ليست بحاجة إلى إخفاء كل شيء، ولا تجعل كل شيء علنًا؛ بل تحوّل الخصوصية إلى قرص يمكن ضبطه. في الطبقة الأساسية، تُستخدم إثباتات المعرفة الصفرية PLONK والتشفير المتماثل لإخفاء مبلغ المعاملة وعناوينها بالكامل عن الجميع، لكن عقدة الرقابة المحددة يمكنها التحقق فورًا من حالة الامتثال. عند الحاجة إلى التدقيق تكون الرقابة شفافة، وعند عدم الحاجة يتم الحفاظ على الخصوصية أمام الجمهور.
بعد إطلاق الشبكة الرئيسية في يناير، يدعم DuskEVM انتقالًا سلسًا عبر Solidity، لتصبح بيئة تطوير المطورين مماثلة لبيئة Ethereum. في مايو، تعاونت NPEX مع Quantoz لإطلاق EURQ، عملة يورو مستقرة قابلة للبرمجة على Dusk، ومع وجود أكثر من 300 مليون يورو من الأوراق المالية المُرمّزة قيد التشغيل بالفعل، فهذا يثبت أن النموذج الكامل يتم التحقق منه عمليًا على أرض الواقع. حلّ إثباتات المعرفة الصفرية لا يتمثل في «هل يمكن الإخفاء أم لا»، بل في «من الذي يجب أن يرى، وبقدر ما يجب أن يرى».
إذا كانت معاملات السلسلة يمكن «إظهارها بشكل انتقائي»، لمن ترغب أكثر في إخفاء نشاطك على السلسلة؟ شاركنا في قسم التعليقات.
#dusk $DUSK
كانت الإجابة التي قدمها <c-1/>@Dusk Dusk هي: لا داعي للاختيار. فهي ليست بحاجة إلى إخفاء كل شيء، ولا تجعل كل شيء علنًا؛ بل تحوّل الخصوصية إلى قرص يمكن ضبطه. في الطبقة الأساسية، تُستخدم إثباتات المعرفة الصفرية PLONK والتشفير المتماثل لإخفاء مبلغ المعاملة وعناوينها بالكامل عن الجميع، لكن عقدة الرقابة المحددة يمكنها التحقق فورًا من حالة الامتثال. عند الحاجة إلى التدقيق تكون الرقابة شفافة، وعند عدم الحاجة يتم الحفاظ على الخصوصية أمام الجمهور.
بعد إطلاق الشبكة الرئيسية في يناير، يدعم DuskEVM انتقالًا سلسًا عبر Solidity، لتصبح بيئة تطوير المطورين مماثلة لبيئة Ethereum. في مايو، تعاونت NPEX مع Quantoz لإطلاق EURQ، عملة يورو مستقرة قابلة للبرمجة على Dusk، ومع وجود أكثر من 300 مليون يورو من الأوراق المالية المُرمّزة قيد التشغيل بالفعل، فهذا يثبت أن النموذج الكامل يتم التحقق منه عمليًا على أرض الواقع. حلّ إثباتات المعرفة الصفرية لا يتمثل في «هل يمكن الإخفاء أم لا»، بل في «من الذي يجب أن يرى، وبقدر ما يجب أن يرى».
إذا كانت معاملات السلسلة يمكن «إظهارها بشكل انتقائي»، لمن ترغب أكثر في إخفاء نشاطك على السلسلة؟ شاركنا في قسم التعليقات.
#dusk $DUSK
158
·
--
في الأسبوع الماضي أعدت النظر في معدل فائدة الاقتراض على Aave: 4.3%، أعلى من الأسبوع الماضي بنسبة 1.2%. إذا أودعت USDC، فإن الخوارزمية تعيد حساب الفائدة كل ثانية بناءً على علاقة العرض والطلب. الفائدة السنوية التي تراها اليوم قد تتغير غدًا.
@termmax TermMax يعالج مشكلة النقص في الحتمية. عندما تقترض مبلغًا عبر TermMax، فإن سعر الفائدة لمدة 30 يومًا أو 90 يومًا يُقفل عند لحظة فتح الصفقة—ليس “تقدير APY” ولا “أعلى ما يمكن الوصول إليه”، بل معدل ثابت مضمون عند الاستحقاق. كم تقترض، وكم ستكون التكلفة، وماذا ستحصل عليه عند حلول الأجل—كل شيء مكتوب بوضوح مسبقًا.
فكم تساوي هذه الحتمية؟ بالنسبة للمؤسسات، الفرق بين اقتراض مرة واحدة بسعر فائدة ثابت 4.7% وبين اقتراض بسعر فائدة متغير قد يكون الفرق بين تمرير سلسلة كاملة من إجراءات إدارة المخاطر عبر التدقيق أم لا. تعمل TermMax بالفعل على دعم أسهم مُرمّزة (tokenized) من Ondo كضمانات، بحيث يمكن للمستخدمين الحصول على التمويل دون بيع أصولهم. كما أن مثال SteakhouseFi نموذجي كذلك—حيث يودع المستخدمون الأموال في EURC Vault لكسب 6.6% APY، وفي الوقت نفسه يقترضون USDC من TermMax بسعر فائدة ثابت 4.7%، ويكسب الطرفان معًا.
منذ إطلاق الشبكة الرئيسية في أبريل 2025، تجاوزت TVL 71 مليون دولار أمريكي، وتحتل عناوين المستخدمين النشطين يوميًا المرتبة الثانية بين بروتوكولات الإقراض والاقتراض في DeFi. فكم تساوي الحتمية نفسها؟ بالنسبة لتلك المؤسسات التي تحتاج إلى تخطيط أموال ضمن إطار امتثال، قد تكون الإجابة: “بأي مبلغ كان يستحق”. TermMax تجيب عن أكثر سؤال في DeFi كان مُهمَّش التقدير: كم أنت مستعد أن تدفع مقابل “أن تعرف أن الغد لن يتغير”.
إذا كان بإمكانك قفل معدل الفائدة على الاقتراض لمدة 30 يومًا دون تغيير مسبقًا، هل كنت ستوافق على دفع فائدة أعلى قليلًا مقابل هذه الحتمية؟ تحدثوا في قسم التعليقات.
#termmax
في الأسبوع الماضي أعدت النظر في معدل فائدة الاقتراض على Aave: 4.3%، أعلى من الأسبوع الماضي بنسبة 1.2%. إذا أودعت USDC، فإن الخوارزمية تعيد حساب الفائدة كل ثانية بناءً على علاقة العرض والطلب. الفائدة السنوية التي تراها اليوم قد تتغير غدًا.
@TermMax TermMax يعالج مشكلة النقص في الحتمية. عندما تقترض مبلغًا عبر TermMax، فإن سعر الفائدة لمدة 30 يومًا أو 90 يومًا يُقفل عند لحظة فتح الصفقة—ليس “تقدير APY” ولا “أعلى ما يمكن الوصول إليه”، بل معدل ثابت مضمون عند الاستحقاق. كم تقترض، وكم ستكون التكلفة، وماذا ستحصل عليه عند حلول الأجل—كل شيء مكتوب بوضوح مسبقًا.
فكم تساوي هذه الحتمية؟ بالنسبة للمؤسسات، الفرق بين اقتراض مرة واحدة بسعر فائدة ثابت 4.7% وبين اقتراض بسعر فائدة متغير قد يكون الفرق بين تمرير سلسلة كاملة من إجراءات إدارة المخاطر عبر التدقيق أم لا. تعمل TermMax بالفعل على دعم أسهم مُرمّزة (tokenized) من Ondo كضمانات، بحيث يمكن للمستخدمين الحصول على التمويل دون بيع أصولهم. كما أن مثال SteakhouseFi نموذجي كذلك—حيث يودع المستخدمون الأموال في EURC Vault لكسب 6.6% APY، وفي الوقت نفسه يقترضون USDC من TermMax بسعر فائدة ثابت 4.7%، ويكسب الطرفان معًا.
منذ إطلاق الشبكة الرئيسية في أبريل 2025، تجاوزت TVL 71 مليون دولار أمريكي، وتحتل عناوين المستخدمين النشطين يوميًا المرتبة الثانية بين بروتوكولات الإقراض والاقتراض في DeFi. فكم تساوي الحتمية نفسها؟ بالنسبة لتلك المؤسسات التي تحتاج إلى تخطيط أموال ضمن إطار امتثال، قد تكون الإجابة: “بأي مبلغ كان يستحق”. TermMax تجيب عن أكثر سؤال في DeFi كان مُهمَّش التقدير: كم أنت مستعد أن تدفع مقابل “أن تعرف أن الغد لن يتغير”.
إذا كان بإمكانك قفل معدل الفائدة على الاقتراض لمدة 30 يومًا دون تغيير مسبقًا، هل كنت ستوافق على دفع فائدة أعلى قليلًا مقابل هذه الحتمية؟ تحدثوا في قسم التعليقات.
#termmax
@TermMax TermMax يعالج مشكلة النقص في الحتمية. عندما تقترض مبلغًا عبر TermMax، فإن سعر الفائدة لمدة 30 يومًا أو 90 يومًا يُقفل عند لحظة فتح الصفقة—ليس “تقدير APY” ولا “أعلى ما يمكن الوصول إليه”، بل معدل ثابت مضمون عند الاستحقاق. كم تقترض، وكم ستكون التكلفة، وماذا ستحصل عليه عند حلول الأجل—كل شيء مكتوب بوضوح مسبقًا.
فكم تساوي هذه الحتمية؟ بالنسبة للمؤسسات، الفرق بين اقتراض مرة واحدة بسعر فائدة ثابت 4.7% وبين اقتراض بسعر فائدة متغير قد يكون الفرق بين تمرير سلسلة كاملة من إجراءات إدارة المخاطر عبر التدقيق أم لا. تعمل TermMax بالفعل على دعم أسهم مُرمّزة (tokenized) من Ondo كضمانات، بحيث يمكن للمستخدمين الحصول على التمويل دون بيع أصولهم. كما أن مثال SteakhouseFi نموذجي كذلك—حيث يودع المستخدمون الأموال في EURC Vault لكسب 6.6% APY، وفي الوقت نفسه يقترضون USDC من TermMax بسعر فائدة ثابت 4.7%، ويكسب الطرفان معًا.
منذ إطلاق الشبكة الرئيسية في أبريل 2025، تجاوزت TVL 71 مليون دولار أمريكي، وتحتل عناوين المستخدمين النشطين يوميًا المرتبة الثانية بين بروتوكولات الإقراض والاقتراض في DeFi. فكم تساوي الحتمية نفسها؟ بالنسبة لتلك المؤسسات التي تحتاج إلى تخطيط أموال ضمن إطار امتثال، قد تكون الإجابة: “بأي مبلغ كان يستحق”. TermMax تجيب عن أكثر سؤال في DeFi كان مُهمَّش التقدير: كم أنت مستعد أن تدفع مقابل “أن تعرف أن الغد لن يتغير”.
إذا كان بإمكانك قفل معدل الفائدة على الاقتراض لمدة 30 يومًا دون تغيير مسبقًا، هل كنت ستوافق على دفع فائدة أعلى قليلًا مقابل هذه الحتمية؟ تحدثوا في قسم التعليقات.
#termmax
160
·
--
كنتُ أرى “الفائدة الثابتة” من قبل، وكانت أول ردة فعل لي أن البروتوكول سيُثبت لي عائدًا سنويًا ثابتًا (APY). TermMax ليس مجرد قفلٍ شفهي لعائدٍ محدد؛ بل يقوم بتقسيم وحدة من أصول الدين إلى FT وXT: قبل تاريخ الاستحقاق، يمكن دمج 1 FT و1 XT لإعادة تكوين وحدة واحدة من أصل الدين؛ عند الاستحقاق، يتم استبدال FT بالقيمة الاسمية، بينما تصبح قيمة XT صفرًا.
فهمتُه على أنه سند وديعة لأجل مع سند ملكية متبقٍ. يشتري المقرض FT بخصم، ويشكّل فرق السعر عائدًا ثابتًا؛ وتستوعب XT التغيّر في القيمة المتبقية خلال مدة القرض. يقوم المقترض بقفل الضمان في Gearing Token، ثم يُصدر FT ويبيعه؛ ويتم تحديد تكلفة الاقتراض لحظة إتمام الصفقة. وبذلك تحوّل TermMax السؤال من “هل يمكن أن تقفز الفائدة فجأة؟” إلى “هل المدة وسعر الصفقة مناسبان؟”.
لكن الفائدة الثابتة لا تعني أمانًا ثابتًا. تذكّر وثائق المخاطر الرسمية بأن الصفقات الكبيرة قد تُستهلك سيولة Range Order وتؤدي إلى انزلاق أعلى؛ وإذا لم يسدد المقترض عند الاستحقاق، ستدخل المراكز في التصفية، ولن تضمن التسوية الفعلية قدرة المقرض على استلام عملته الأصلية كما هي؛ إذ يمكنه فقط استلام الضمان بنسبةٍ من إجمالي الأصول. سأنظر إلى خصم FT وإلى وقت الاستحقاق على التوالي، ثم أتحقق من عمق الطلب وجودة الضمان، لتقييم ما إذا كان ذلك العائد المؤكد يستحق المخاطرة. ما يكون “مقفلاً حقًا” هو الفائدة، لا المخاطر.
@termmax #TermMax #termmax
كنتُ أرى “الفائدة الثابتة” من قبل، وكانت أول ردة فعل لي أن البروتوكول سيُثبت لي عائدًا سنويًا ثابتًا (APY). TermMax ليس مجرد قفلٍ شفهي لعائدٍ محدد؛ بل يقوم بتقسيم وحدة من أصول الدين إلى FT وXT: قبل تاريخ الاستحقاق، يمكن دمج 1 FT و1 XT لإعادة تكوين وحدة واحدة من أصل الدين؛ عند الاستحقاق، يتم استبدال FT بالقيمة الاسمية، بينما تصبح قيمة XT صفرًا.
فهمتُه على أنه سند وديعة لأجل مع سند ملكية متبقٍ. يشتري المقرض FT بخصم، ويشكّل فرق السعر عائدًا ثابتًا؛ وتستوعب XT التغيّر في القيمة المتبقية خلال مدة القرض. يقوم المقترض بقفل الضمان في Gearing Token، ثم يُصدر FT ويبيعه؛ ويتم تحديد تكلفة الاقتراض لحظة إتمام الصفقة. وبذلك تحوّل TermMax السؤال من “هل يمكن أن تقفز الفائدة فجأة؟” إلى “هل المدة وسعر الصفقة مناسبان؟”.
لكن الفائدة الثابتة لا تعني أمانًا ثابتًا. تذكّر وثائق المخاطر الرسمية بأن الصفقات الكبيرة قد تُستهلك سيولة Range Order وتؤدي إلى انزلاق أعلى؛ وإذا لم يسدد المقترض عند الاستحقاق، ستدخل المراكز في التصفية، ولن تضمن التسوية الفعلية قدرة المقرض على استلام عملته الأصلية كما هي؛ إذ يمكنه فقط استلام الضمان بنسبةٍ من إجمالي الأصول. سأنظر إلى خصم FT وإلى وقت الاستحقاق على التوالي، ثم أتحقق من عمق الطلب وجودة الضمان، لتقييم ما إذا كان ذلك العائد المؤكد يستحق المخاطرة. ما يكون “مقفلاً حقًا” هو الفائدة، لا المخاطر.
@TermMax #TermMax #termmax
فهمتُه على أنه سند وديعة لأجل مع سند ملكية متبقٍ. يشتري المقرض FT بخصم، ويشكّل فرق السعر عائدًا ثابتًا؛ وتستوعب XT التغيّر في القيمة المتبقية خلال مدة القرض. يقوم المقترض بقفل الضمان في Gearing Token، ثم يُصدر FT ويبيعه؛ ويتم تحديد تكلفة الاقتراض لحظة إتمام الصفقة. وبذلك تحوّل TermMax السؤال من “هل يمكن أن تقفز الفائدة فجأة؟” إلى “هل المدة وسعر الصفقة مناسبان؟”.
لكن الفائدة الثابتة لا تعني أمانًا ثابتًا. تذكّر وثائق المخاطر الرسمية بأن الصفقات الكبيرة قد تُستهلك سيولة Range Order وتؤدي إلى انزلاق أعلى؛ وإذا لم يسدد المقترض عند الاستحقاق، ستدخل المراكز في التصفية، ولن تضمن التسوية الفعلية قدرة المقرض على استلام عملته الأصلية كما هي؛ إذ يمكنه فقط استلام الضمان بنسبةٍ من إجمالي الأصول. سأنظر إلى خصم FT وإلى وقت الاستحقاق على التوالي، ثم أتحقق من عمق الطلب وجودة الضمان، لتقييم ما إذا كان ذلك العائد المؤكد يستحق المخاطرة. ما يكون “مقفلاً حقًا” هو الفائدة، لا المخاطر.
@TermMax #TermMax #termmax
189
·
--
كنت أعتقد من قبل أن انتشار البلوك تشين يعني فقط وضع الرسالة نفسها في جميع الجيران، وأن من ينقل أسرع يفوز. لم تتبع Kadcast في Dusk مسار Gossip العشوائي؛ بل أنشأت على UDP شبكة تغطية مُهيكلة: يحصل كل عقدة على معرّف 128 بت، وتدخل ضمن شجرة توجيه ثنائية وفقًا لمسافة XOR في Kademlia مع k-bucket. عندما تمتلئ الأُسُر (البُكيت)، يتم أولًا استخدام PING/PONG للتحقق من العقد القديمة، ثم يتم التحديث بحسب LRU.
فهمته كأنه مركز توزيع شحنات مُرقّم. تدخل الطرود ضمن مستويات ثابتة حسب المسافة، ولا يُسمح لكل نقاط الشبكة أن تنتقل عشوائيًا في كل الاتجاهات؛ كما أن البث يتجاهل التكرارات الخاصة بـ CHUNK، ويعالج فقد الحزم باستخدام RaptorQ FEC. تُظهر المعايير في المستودع الرسمي أن معدل فقد الحزم 12%، ومع β=3 و f=0.15 ما زالت العملية قادرة على تغطية الشبكة بأكملها، لكن هذا اختبار على مستوى المكتبة وليس وعدًا بزمن تأخير الشبكة على mainnet.
قيمة @Dusk_Foundation Dusk هنا تتمثل في تقليل حركة المرور غير المفيدة، وجعل زمن الانتشار أكثر قابلية للتنبؤ، وما يخشاه التسوية المالية حقًا هو حدود الوقت غير الواضحة. ومع ذلك، فإن التوجيه المُهيكل لا يلغي المخاطر تلقائيًا؛ فمدى توازن توزيع العقد، وتذبذب الشبكة وضغوط الهجوم ما زالت بحاجة إلى مراقبة مستمرة للتحقق. لن أستخدم اختبارًا معياريًا واحدًا لأثبت أن الشبكة أصبحت بالقدر الكافي من السرعة. Kadcast يعالج ترتيب الانتشار، وما يثبت الاستقرار هو التشغيل الحقيقي.
#dusk $DUSK
كنت أعتقد من قبل أن انتشار البلوك تشين يعني فقط وضع الرسالة نفسها في جميع الجيران، وأن من ينقل أسرع يفوز. لم تتبع Kadcast في Dusk مسار Gossip العشوائي؛ بل أنشأت على UDP شبكة تغطية مُهيكلة: يحصل كل عقدة على معرّف 128 بت، وتدخل ضمن شجرة توجيه ثنائية وفقًا لمسافة XOR في Kademlia مع k-bucket. عندما تمتلئ الأُسُر (البُكيت)، يتم أولًا استخدام PING/PONG للتحقق من العقد القديمة، ثم يتم التحديث بحسب LRU.
فهمته كأنه مركز توزيع شحنات مُرقّم. تدخل الطرود ضمن مستويات ثابتة حسب المسافة، ولا يُسمح لكل نقاط الشبكة أن تنتقل عشوائيًا في كل الاتجاهات؛ كما أن البث يتجاهل التكرارات الخاصة بـ CHUNK، ويعالج فقد الحزم باستخدام RaptorQ FEC. تُظهر المعايير في المستودع الرسمي أن معدل فقد الحزم 12%، ومع β=3 و f=0.15 ما زالت العملية قادرة على تغطية الشبكة بأكملها، لكن هذا اختبار على مستوى المكتبة وليس وعدًا بزمن تأخير الشبكة على mainnet.
قيمة @Dusk Dusk هنا تتمثل في تقليل حركة المرور غير المفيدة، وجعل زمن الانتشار أكثر قابلية للتنبؤ، وما يخشاه التسوية المالية حقًا هو حدود الوقت غير الواضحة. ومع ذلك، فإن التوجيه المُهيكل لا يلغي المخاطر تلقائيًا؛ فمدى توازن توزيع العقد، وتذبذب الشبكة وضغوط الهجوم ما زالت بحاجة إلى مراقبة مستمرة للتحقق. لن أستخدم اختبارًا معياريًا واحدًا لأثبت أن الشبكة أصبحت بالقدر الكافي من السرعة. Kadcast يعالج ترتيب الانتشار، وما يثبت الاستقرار هو التشغيل الحقيقي.
#dusk $DUSK
فهمته كأنه مركز توزيع شحنات مُرقّم. تدخل الطرود ضمن مستويات ثابتة حسب المسافة، ولا يُسمح لكل نقاط الشبكة أن تنتقل عشوائيًا في كل الاتجاهات؛ كما أن البث يتجاهل التكرارات الخاصة بـ CHUNK، ويعالج فقد الحزم باستخدام RaptorQ FEC. تُظهر المعايير في المستودع الرسمي أن معدل فقد الحزم 12%، ومع β=3 و f=0.15 ما زالت العملية قادرة على تغطية الشبكة بأكملها، لكن هذا اختبار على مستوى المكتبة وليس وعدًا بزمن تأخير الشبكة على mainnet.
قيمة @Dusk Dusk هنا تتمثل في تقليل حركة المرور غير المفيدة، وجعل زمن الانتشار أكثر قابلية للتنبؤ، وما يخشاه التسوية المالية حقًا هو حدود الوقت غير الواضحة. ومع ذلك، فإن التوجيه المُهيكل لا يلغي المخاطر تلقائيًا؛ فمدى توازن توزيع العقد، وتذبذب الشبكة وضغوط الهجوم ما زالت بحاجة إلى مراقبة مستمرة للتحقق. لن أستخدم اختبارًا معياريًا واحدًا لأثبت أن الشبكة أصبحت بالقدر الكافي من السرعة. Kadcast يعالج ترتيب الانتشار، وما يثبت الاستقرار هو التشغيل الحقيقي.
#dusk $DUSK
194
·
--
لقد كتبتُ الاستراتيجية في عطلة نهاية الأسبوع الماضية، وهي الآن تُنفَّذ خطوة بخطوة وفقًا للخطة.
لقد عادت عملة BTC من حوالي 62,508 إلى فوق 64,000 مرة أخرى، وبلغت أعلى مستوى لها 64,200، وهي الآن ضمن منطقة اختبار 64,000—64,500 التي حددتها مسبقًا.
كان تقديري وقتها كالتالي:
الأسبوع القادم سنمضي في نطاق تذبذب أولاً، وقد يختبر السعر صعودًا 64,000—64,500 مجددًا، لجذب المشترين (اللاعبين على المراكز الطويلة) من جديد، ثم البحث عن فرصة للهبوط لاحقًا؛ أما الهبوط المتسارع الحقيقي فسيتم تأجيله إلى سبتمبر.
لذلك، فإن هذه الموجة الصاعدة لم تُغيّر رؤيتي المتوسطة المدى، بل هي جزء من المسار الذي كنت أتوقعه.
بعد ذلك، لن ألاحق شراءًا فوق 64,000، بل سأراقب ما إذا كانت هذه المنطقة ستشهد ارتدادًا هابطًا بعد الصعود (اصطدامًا ثم تراجعًا)، أو حدوث تذبذب مع زيادة في أحجام التداول دون تحسن (تسطّح/تلكؤ مع حجم)، أو ضعفًا في البنية على إطار أصغر. فقط إذا ظهرت هذه الشروط، سأبدأ في البحث عن نقاط دخول لصفقات البيع باتجاه الاتجاه.
إذا تمكنت BTC من الوقوف بحجم تداول كبير فوق 64,500، واستمرَّت في استعادة 65,150، فهذا يعني أن الدعم/الالتزام في الأعلى أقوى من المتوقع، وأن مسار خداع الصعود ثم التحول إلى هبوط يجب تأجيله، وبالتالي تُلغى خطة الهبوط مؤقتًا.
أما إذا عادت 64,000—64,500 إلى كبح السعر مرة أخرى، ثم حدث لاحقًا كسرٌ جديد دون 61,500 مع ارتدادٍ لا يستطيع الاستعادة، عندها سنؤكد أن الهبوط دخل مرحلة التسارع. في ذلك الوقت، سننظر في سبتمبر إلى 54,000 أولاً ثم 48,000.
الآن نحن نسير في مرحلة الاختبار الصعودي ضمن تذبذبات أغسطس؛ أما الهبوط المتسارع فراقبوه في الشهر القادم، ولا تخلطوا بين المرحلتين.
لقد كتبتُ الاستراتيجية في عطلة نهاية الأسبوع الماضية، وهي الآن تُنفَّذ خطوة بخطوة وفقًا للخطة.
لقد عادت عملة BTC من حوالي 62,508 إلى فوق 64,000 مرة أخرى، وبلغت أعلى مستوى لها 64,200، وهي الآن ضمن منطقة اختبار 64,000—64,500 التي حددتها مسبقًا.
كان تقديري وقتها كالتالي:
الأسبوع القادم سنمضي في نطاق تذبذب أولاً، وقد يختبر السعر صعودًا 64,000—64,500 مجددًا، لجذب المشترين (اللاعبين على المراكز الطويلة) من جديد، ثم البحث عن فرصة للهبوط لاحقًا؛ أما الهبوط المتسارع الحقيقي فسيتم تأجيله إلى سبتمبر.
لذلك، فإن هذه الموجة الصاعدة لم تُغيّر رؤيتي المتوسطة المدى، بل هي جزء من المسار الذي كنت أتوقعه.
بعد ذلك، لن ألاحق شراءًا فوق 64,000، بل سأراقب ما إذا كانت هذه المنطقة ستشهد ارتدادًا هابطًا بعد الصعود (اصطدامًا ثم تراجعًا)، أو حدوث تذبذب مع زيادة في أحجام التداول دون تحسن (تسطّح/تلكؤ مع حجم)، أو ضعفًا في البنية على إطار أصغر. فقط إذا ظهرت هذه الشروط، سأبدأ في البحث عن نقاط دخول لصفقات البيع باتجاه الاتجاه.
إذا تمكنت BTC من الوقوف بحجم تداول كبير فوق 64,500، واستمرَّت في استعادة 65,150، فهذا يعني أن الدعم/الالتزام في الأعلى أقوى من المتوقع، وأن مسار خداع الصعود ثم التحول إلى هبوط يجب تأجيله، وبالتالي تُلغى خطة الهبوط مؤقتًا.
أما إذا عادت 64,000—64,500 إلى كبح السعر مرة أخرى، ثم حدث لاحقًا كسرٌ جديد دون 61,500 مع ارتدادٍ لا يستطيع الاستعادة، عندها سنؤكد أن الهبوط دخل مرحلة التسارع. في ذلك الوقت، سننظر في سبتمبر إلى 54,000 أولاً ثم 48,000.
الآن نحن نسير في مرحلة الاختبار الصعودي ضمن تذبذبات أغسطس؛ أما الهبوط المتسارع فراقبوه في الشهر القادم، ولا تخلطوا بين المرحلتين.
لقد عادت عملة BTC من حوالي 62,508 إلى فوق 64,000 مرة أخرى، وبلغت أعلى مستوى لها 64,200، وهي الآن ضمن منطقة اختبار 64,000—64,500 التي حددتها مسبقًا.
كان تقديري وقتها كالتالي:
الأسبوع القادم سنمضي في نطاق تذبذب أولاً، وقد يختبر السعر صعودًا 64,000—64,500 مجددًا، لجذب المشترين (اللاعبين على المراكز الطويلة) من جديد، ثم البحث عن فرصة للهبوط لاحقًا؛ أما الهبوط المتسارع الحقيقي فسيتم تأجيله إلى سبتمبر.
لذلك، فإن هذه الموجة الصاعدة لم تُغيّر رؤيتي المتوسطة المدى، بل هي جزء من المسار الذي كنت أتوقعه.
بعد ذلك، لن ألاحق شراءًا فوق 64,000، بل سأراقب ما إذا كانت هذه المنطقة ستشهد ارتدادًا هابطًا بعد الصعود (اصطدامًا ثم تراجعًا)، أو حدوث تذبذب مع زيادة في أحجام التداول دون تحسن (تسطّح/تلكؤ مع حجم)، أو ضعفًا في البنية على إطار أصغر. فقط إذا ظهرت هذه الشروط، سأبدأ في البحث عن نقاط دخول لصفقات البيع باتجاه الاتجاه.
إذا تمكنت BTC من الوقوف بحجم تداول كبير فوق 64,500، واستمرَّت في استعادة 65,150، فهذا يعني أن الدعم/الالتزام في الأعلى أقوى من المتوقع، وأن مسار خداع الصعود ثم التحول إلى هبوط يجب تأجيله، وبالتالي تُلغى خطة الهبوط مؤقتًا.
أما إذا عادت 64,000—64,500 إلى كبح السعر مرة أخرى، ثم حدث لاحقًا كسرٌ جديد دون 61,500 مع ارتدادٍ لا يستطيع الاستعادة، عندها سنؤكد أن الهبوط دخل مرحلة التسارع. في ذلك الوقت، سننظر في سبتمبر إلى 54,000 أولاً ثم 48,000.
الآن نحن نسير في مرحلة الاختبار الصعودي ضمن تذبذبات أغسطس؛ أما الهبوط المتسارع فراقبوه في الشهر القادم، ولا تخلطوا بين المرحلتين.
BTC老白
·
--
إدارة المراكز خلال عطلة نهاية الأسبوع وتحويل استراتيجية الأسبوع القادم｜صيد داخل اليوم｜مراجعة حقيقية + خطة تداول｜حكم احترافي
البارحة انخفضت عملة BTC بوخز هبوطي، ولم يصل أدنى نقطة إلى وقف الخسارة المحدد عند 61,988، وما زال مركز الشراء (المُضاربة الطويلة) قيد الاحتفاظ به.
لكن النجاة من وقف الخسارة لا تعني أنه يمكن الاستمرار في الجشع.
【المركز الحالي】
تم دفع مركز الشراء هذا إلى التعادل (بدون خسارة)، والسعر وصل إلى نطاق 63,400—63,500 تقريبًا، وسأقوم بأخذ الربح مباشرة ولن أراهن على استمرار الزخم خلال عطلة نهاية الأسبوع.
【خطة عطلة نهاية الأسبوع】
في يومي عطلة نهاية الأسبوع توقّف عن فتح صفقات داخل اليوم جديدة. بعد ذلك، إذا عاد السعر لاختبار 62,000—62,500 وظهرت إشارة لتأكيد التوقف عن الهبوط (止跌确认)، فسأفكر في الدخول بصفقة شراء بحجم خفيف، مع وضع وقف الخسارة قرب 61,500، والهدف عند 64,000، أي الحد العلوي لقناة الهبوط الحالية.
إذا لم يحدث تأكيد، لن أدخل مبكرًا.
【استراتيجية الأسبوع القادم】
على الإطار اليومي ما زال السعر يسير داخل وتد تضييقي (收敛楔形)، وعلى إطار 4 ساعات فهو ضمن قناة هبوط. وتوقّعي ما زال: في أغسطس أولًا التعامل على أنه تذبذب، وفي الأسبوع القادم قد نرى اختبارًا صعوديًا أولًا باتجاه 64,000—64,500، ثم إعادة جذب المشترين، وبعدها قد يختار الاتجاه للأسفل.
لذلك من الأسبوع القادم سأبدّل الاستراتيجية تدريجيًا:
ستصبح عملية البيع على المكشوف (做空) هي الاتجاه الرئيسي، وسيتم خفض حجم صفقات الشراء إلى نصف ما يكون عليه عادةً، ولن أشارك إلا في الارتداد؛ وإذا حدث ضمن 64,000—64,500 قمة ثم ارتداد للأسفل (冲高回落)، أو تراجع مع أحجام تداول كبيرة دون ارتفاع مستمر (放量滞涨)، أو ضعف في البنية على مستوى زمني أصغر، سأبدأ في التخطيط لصفقات بيع وفق اتجاه (趋势空单).
فقط في حال حدوث كسر إضافي تحت 61,500، سيتأكد أن الهبوط بدأ بالتسارع. عندها في سبتمبر أولًا سأراقب 54,000، ثم 48,000، وخلال الطريق سيكون أي ارتداد بالنسبة لي فرصة لمواصلة البحث عن أماكن لصفقات البيع وفق الاتجاه. $BTC #交易员下调2027年中前美联储加息押注
【شروط الإبطال】
إذا حشدت BTC أحجام تداول ووقفت بثبات عند 64,500، واستمرت في استعادة مستوى قريب من 65,150، فسيتأخر مسار تحويل الإغراء نحو الهبوط (诱多转跌)، وسيُلغى مخطط الهبوط مؤقتًا.
أنا لا أجزم الآن بأن سبتمبر سيكون سقوطًا مفاجئًا (瀑布) حتميًا، بل كتبت السيناريو مسبقًا فقط، وسأنتظر أن يمنح السعر تأكيدًا.
في عطلة نهاية الأسبوع سأقفل الأرباح أولًا. يمكن لل行情 أن تنتظر، لكن لا يمكن للصفقات أن تراهن.
البارحة انخفضت عملة BTC بوخز هبوطي، ولم يصل أدنى نقطة إلى وقف الخسارة المحدد عند 61,988، وما زال مركز الشراء (المُضاربة الطويلة) قيد الاحتفاظ به.
لكن النجاة من وقف الخسارة لا تعني أنه يمكن الاستمرار في الجشع.
【المركز الحالي】
تم دفع مركز الشراء هذا إلى التعادل (بدون خسارة)، والسعر وصل إلى نطاق 63,400—63,500 تقريبًا، وسأقوم بأخذ الربح مباشرة ولن أراهن على استمرار الزخم خلال عطلة نهاية الأسبوع.
【خطة عطلة نهاية الأسبوع】
في يومي عطلة نهاية الأسبوع توقّف عن فتح صفقات داخل اليوم جديدة. بعد ذلك، إذا عاد السعر لاختبار 62,000—62,500 وظهرت إشارة لتأكيد التوقف عن الهبوط (止跌确认)، فسأفكر في الدخول بصفقة شراء بحجم خفيف، مع وضع وقف الخسارة قرب 61,500، والهدف عند 64,000، أي الحد العلوي لقناة الهبوط الحالية.
إذا لم يحدث تأكيد، لن أدخل مبكرًا.
【استراتيجية الأسبوع القادم】
على الإطار اليومي ما زال السعر يسير داخل وتد تضييقي (收敛楔形)، وعلى إطار 4 ساعات فهو ضمن قناة هبوط. وتوقّعي ما زال: في أغسطس أولًا التعامل على أنه تذبذب، وفي الأسبوع القادم قد نرى اختبارًا صعوديًا أولًا باتجاه 64,000—64,500، ثم إعادة جذب المشترين، وبعدها قد يختار الاتجاه للأسفل.
لذلك من الأسبوع القادم سأبدّل الاستراتيجية تدريجيًا:
ستصبح عملية البيع على المكشوف (做空) هي الاتجاه الرئيسي، وسيتم خفض حجم صفقات الشراء إلى نصف ما يكون عليه عادةً، ولن أشارك إلا في الارتداد؛ وإذا حدث ضمن 64,000—64,500 قمة ثم ارتداد للأسفل (冲高回落)، أو تراجع مع أحجام تداول كبيرة دون ارتفاع مستمر (放量滞涨)، أو ضعف في البنية على مستوى زمني أصغر، سأبدأ في التخطيط لصفقات بيع وفق اتجاه (趋势空单).
فقط في حال حدوث كسر إضافي تحت 61,500، سيتأكد أن الهبوط بدأ بالتسارع. عندها في سبتمبر أولًا سأراقب 54,000، ثم 48,000، وخلال الطريق سيكون أي ارتداد بالنسبة لي فرصة لمواصلة البحث عن أماكن لصفقات البيع وفق الاتجاه. $BTC #交易员下调2027年中前美联储加息押注
【شروط الإبطال】
إذا حشدت BTC أحجام تداول ووقفت بثبات عند 64,500، واستمرت في استعادة مستوى قريب من 65,150، فسيتأخر مسار تحويل الإغراء نحو الهبوط (诱多转跌)، وسيُلغى مخطط الهبوط مؤقتًا.
أنا لا أجزم الآن بأن سبتمبر سيكون سقوطًا مفاجئًا (瀑布) حتميًا، بل كتبت السيناريو مسبقًا فقط، وسأنتظر أن يمنح السعر تأكيدًا.
في عطلة نهاية الأسبوع سأقفل الأرباح أولًا. يمكن لل行情 أن تنتظر، لكن لا يمكن للصفقات أن تراهن.
160
·
--
أنا في التطبيقات على السلسلة أقل ما عندي من صبر في المكان الذي يبدأ عند النقر على "ربط المحفظة" ثم يلزم التمييز أي إضافة يجب استخدامها، وأي حساب، وأي شبكة. إن Dusk Connect يعالج هذا المدخل السهل فقدانه للمستخدمين. فهو ليس محفظة، ولا يمس المفاتيح الخاصة؛ بل يكتشف الإضافات المتوافقة، ويتيح للمستخدم اختيار جهة التقديم ومنح الموافقة على Profile، ثم يراقب حالة المحفظة، ويتتبع تغيّرات الأذونات والشبكة، وبعد ذلك يحيل طلبات التوقيع أو المعاملات إلى المحفظة المختارة لتأكيدها.
أنا أفهمه كأنه مكتب الاستقبال الرئيسي في صالة المعاملات. مكتب الاستقبال لا يحتفظ بمفاتيح العملاء، بل يجد النافذة الصحيحة وينقل الطلب. توضح وثائق Dusk الرسمية أن Dusk Wallet Extension مجرد أحد مزودي الخدمة القابلين للاكتشاف، وأن Dusk Connect يستخدم بروتوكول الاكتشاف ولا يقيّد التطبيق بإضافة محددة.
في تطبيقات الأصول الخاضعة للرقابة، إذا كان مدخل التفويض غير مستقر، فسيصعب أن تسير بسلاسة عناوين الخصوصية واستدعاءات العقود في الخطوة التالية. لكن تقليل الاحتكاك لا يعني إبقاء المستخدم. يجب التحقق مما إذا كانت المحافظ المتوافقة كثيرة بما يكفي، وما إذا كانت التجربة على الهاتف المحمول سلسة، وما إذا كان يمكن الاستعادة بعد رفض التوقيع. رأيي أن ربط المحفظة، رغم أنه يبدو كميزة صغيرة، يحدد ما إذا كان المستخدم يستطيع الوصول إلى خطوة المعاملة.
@Dusk_Foundation $DUSK #dusk
أنا في التطبيقات على السلسلة أقل ما عندي من صبر في المكان الذي يبدأ عند النقر على "ربط المحفظة" ثم يلزم التمييز أي إضافة يجب استخدامها، وأي حساب، وأي شبكة. إن Dusk Connect يعالج هذا المدخل السهل فقدانه للمستخدمين. فهو ليس محفظة، ولا يمس المفاتيح الخاصة؛ بل يكتشف الإضافات المتوافقة، ويتيح للمستخدم اختيار جهة التقديم ومنح الموافقة على Profile، ثم يراقب حالة المحفظة، ويتتبع تغيّرات الأذونات والشبكة، وبعد ذلك يحيل طلبات التوقيع أو المعاملات إلى المحفظة المختارة لتأكيدها.
أنا أفهمه كأنه مكتب الاستقبال الرئيسي في صالة المعاملات. مكتب الاستقبال لا يحتفظ بمفاتيح العملاء، بل يجد النافذة الصحيحة وينقل الطلب. توضح وثائق Dusk الرسمية أن Dusk Wallet Extension مجرد أحد مزودي الخدمة القابلين للاكتشاف، وأن Dusk Connect يستخدم بروتوكول الاكتشاف ولا يقيّد التطبيق بإضافة محددة.
في تطبيقات الأصول الخاضعة للرقابة، إذا كان مدخل التفويض غير مستقر، فسيصعب أن تسير بسلاسة عناوين الخصوصية واستدعاءات العقود في الخطوة التالية. لكن تقليل الاحتكاك لا يعني إبقاء المستخدم. يجب التحقق مما إذا كانت المحافظ المتوافقة كثيرة بما يكفي، وما إذا كانت التجربة على الهاتف المحمول سلسة، وما إذا كان يمكن الاستعادة بعد رفض التوقيع. رأيي أن ربط المحفظة، رغم أنه يبدو كميزة صغيرة، يحدد ما إذا كان المستخدم يستطيع الوصول إلى خطوة المعاملة.
@Dusk $DUSK #dusk
أنا أفهمه كأنه مكتب الاستقبال الرئيسي في صالة المعاملات. مكتب الاستقبال لا يحتفظ بمفاتيح العملاء، بل يجد النافذة الصحيحة وينقل الطلب. توضح وثائق Dusk الرسمية أن Dusk Wallet Extension مجرد أحد مزودي الخدمة القابلين للاكتشاف، وأن Dusk Connect يستخدم بروتوكول الاكتشاف ولا يقيّد التطبيق بإضافة محددة.
في تطبيقات الأصول الخاضعة للرقابة، إذا كان مدخل التفويض غير مستقر، فسيصعب أن تسير بسلاسة عناوين الخصوصية واستدعاءات العقود في الخطوة التالية. لكن تقليل الاحتكاك لا يعني إبقاء المستخدم. يجب التحقق مما إذا كانت المحافظ المتوافقة كثيرة بما يكفي، وما إذا كانت التجربة على الهاتف المحمول سلسة، وما إذا كان يمكن الاستعادة بعد رفض التوقيع. رأيي أن ربط المحفظة، رغم أنه يبدو كميزة صغيرة، يحدد ما إذا كان المستخدم يستطيع الوصول إلى خطوة المعاملة.
@Dusk $DUSK #dusk
197
سجّل الدخول لاستكشاف المزيد من المُحتوى
انضم إلى مُستخدمي العملات الرقمية حول العالم على Binance Square
⚡️ احصل على أحدث المعلومات المفيدة عن العملات الرقمية.
💬 موثوقة من قبل أكبر منصّة لتداول العملات الرقمية في العالم.
👍 اكتشف الرؤى الحقيقية من صنّاع المُحتوى الموثوقين.
البريد الإلكتروني / رقم الهاتف
المواضيع الرائجة
SolanaPlansToCutBlockTimesTo200ms
1,601 مشاهدات
178 يقومون بالنقاش
#SolanaPlansToCutBlockTimesTo200ms
⚡️ عاجل: سولانا أصبحت أسرع للتو
#SolanaPlansToCutBlockTimesTo200ms متاح الآن على الشبكة الرئيسية التجريبية — 9 أكتوبر، 15:00 بالتوقيت العالمي المنسق | الحقبة 1053
الرحلة:
400ms → 350ms → 300ms → 250ms → *200ms* ✅
النتيجة:
→ 5 كتل في الثانية
→ أسرع بنسبة 50% من الإصدار الأصلي
→ أسرع بنسبة 20% من الأمس
هذه هي الخطوة الأخيرة من SIMD-0525 من Anza. زمن استجابة أقل للمتداولين، والأوراكل، ووكلاء الذكاء الاصطناعي، بالإضافة إلى دفعات USDC جديدة مجمّعة عبر x402.
لم تعد سولانا تنافس. بل تتقدم بفارق كبير.$SOL
هل أنت متفائل؟ 👇
متابعة من فضلكم
Shamika Metting
·1 إعجاب
·21 مشاهدات
ReusedBitcoinAddressesHold4.33MBTC
16,666 مشاهدات
345 يقومون بالنقاش
BitcoinDipsBelow$81K
54,263 مشاهدات
102 يقومون بالنقاش