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

قمت بإنشاء إطار اختبار مخصص لـ dApp يُسمى kiwa 🥝 أداة تتيح لك كتابة المواصفات من البداية حتى الاختبار بشكل متكامل. بالإضافة إلى الوثائق، تقوم بتحميل الكود الموجود مسبقًا و generatting وثائق اختبار، ثم توليد اختبارات على أربع مستويات: العقد، dApp E2E، وحدوي، وتكامل API. https://t.co/FCNjrLbVSV

📚 تصميم مُعدّل للـ Mempool يمنع العمليات المُتسلّسة داخل الكتلة ✅ ملخص يهدف هذا الاقتراح إلى تشفير Mempool (المكان الذي تُخزّن فيه المعاملات غير المؤكدة) في إيثريوم، بحيث لا يُمكن رؤية محتواها إلا بعد دخولها الكتلة. بهذا الشكل، يُمكن تقليل بشكل كبير من السلوكيات التي تستغل معرفة محتوى المعاملات مسبقًا مثل التلاعب بالترتيب أو التلاعب بالأسعار (MEV - الربح الإضافي الذي يحصل عليه المُدقّق أو المُنشئ). على الرغم من أن المعاملات تُنشر في النهاية، فإن "عدم رؤية محتواها حتى اللحظة الأخيرة" هو المفتاح هنا. ✅ لماذا تحتاج إيثريوم إلى Mempool مشفرة؟ في الوقت الحالي، يمكن لأي شخص رؤية محتوى المعاملات في Mempool. وهذا يسمح بعمليات مثل "Front-running" (التلاعب بالمعاملات من خلال تنفيذ معاملات مماثلة قبل الآخرين) و"Sandwich attacks" (التلاعب بالسعر من خلال تنفيذ معاملات قبل وبعد معاملة معينة). وهذا يؤدي إلى خسائر على المستخدمين وزيادة التركز في سلطة المُنشئين (Block Builders) في أيدي عدد قليل من الجهات. التشفير يُغيّر هذا الوضع، بحيث يُمكن معرفة الترتيب فقط، دون معرفة محتوى المعاملة، مما يجعل هذه الهجمات صعبة. ✅ كيف تُشفّر المعاملات؟ تُقسّم المعاملة إلى "حقيبة" و"محتوى مشفر". تحتوي الحقيبة على معلومات أساسية مثل كمية الغاز، الرسوم، والجهة التي تُقدّم المفتاح لفك التشفير. أما المحتوى، فيحتوي على التفاصيل الحقيقية مثل الوجهة، المبلغ، بيانات الدعوة للعقود الذكية، وغيرها، ويتم تشفيرها. بعد دخول المعاملة الكتلة، تُنشر المفاتيح المُقابلة، ويُمكن تنفيذ المحتوى المشفر. ✅ من هو "مُقدّم المفتاح" (Key Provider)؟ مُقدّم المفتاح هو الجهة المسؤولة عن إدارة مفتاح فك التشفير. التصميم يسمح باستخدام أنواع مختلفة من أنظمة إدارة المفاتيح، مثل: - التشفير بالحد الأدنى (Threshold Cryptography) حيث يُوزّع المفتاح بين عدة أشخاص. - MPC (التشفير متعدد الأطراف) حيث يُوزّع السرّ بين عدة أطراف. - TEE (البيئة الآمنة في الأجهزة). - التشفير بالوقت المُتأخر (Time-Lock Cryptography). تُقدّم إيثريوم نفسها فقط "البنية الأساسية" التي تدعم أي نظام تشفير. ✅ ترتيب المعاملات في الكتلة وسلامتها في الكتلة، تُنفذ أولًا المعاملات العادية غير المشفرة، ثم تُعالج الحقيبة الخاصة بالمعاملات المشفرة، وأخيرًا تُنفذ المحتويات بعد فك التشفير. بهذا الترتيب، تُحافظ على: - دفع الرسوم مسبقًا. - عدم تنفيذ المحتوى إلا بعد فك التشفير. حتى في حالة عدم توفر المفتاح، تُبقى معالجة الحقيبة فقط، ولا تتأثر السلسلة بأكملها. ✅ تأثير التشفير على MEV ومقاومة الرقابة عندما لا يُمكن رؤية محتوى المعاملات، يُصبح من الصعب على منشئي الكتل معرفة "أي معاملة تؤثر على أي سعر"، مما يجعل من الصعب استغلال الترتيب لتحقيق الربح، وبالتالي يُضعف MEV بشكل هيكلية. كما أن إخفاء محتوى المعاملات يجعل من الصعب استهداف عناوين معينة أو عمليات DeFi، مما يعزز من "المقاومة ضد الرقابة في الوقت الفعلي".

📚 نظام إثبات هوية وكفاءة الوكيل باستخدام NFT ✅ المقدمة إن ERC8004 v1.0 هو مجموعة قواعد مشتركة تسمح للبرامج الذكية (الوكلاء) بالعمل معًا بشكل آمن عبر المنظمات المختلفة. يستخدم Ethereum كـ"أساس للتنسيق"، ويُسجل هوية الوكيل، وسمعته، ونتائج التحقق من عمله بشكل لا يمكن تغييره. لقد تغير التصميم بشكل كبير من v0.4، وتطور النظام ليصبح مناسبًا للاستخدام العملي. ✅ إدارة هوية الوكيل (سجل الهوية) نظام إثبات "من هو الوكيل" قد انتقل من الشكل المخصص إلى معيار ERC721 (معيار NFT). يتم تسجيل كل وكيل كـNFT واحد، ويحتوي tokenURI الخاص به على معلومات التسجيل بصيغة JSON. تتضمن هذه المعلومات طريقة الاتصال (مثل الأهداف التي تستخدم بروتوكولات A2A أو MCP)، المفتاح العام، ونموذج الثقة المقابل. بفضل ذلك، يمكن إدارة هوية الوكيل عبر المحفظة، ويمكن لأي شخص التحقق من "من هو الوكيل في هذه العنوان" بطريقة متوافقة مع البنية التحتية لـNFT. ✅ نظام السمعة (سجل السمعة) تُخزن تقييمات عمل الوكيل مباشرة كنقاط على السلسلة. قبل إرسال التقييم، يحصل العميل على بيانات التفويض الموقعة من الوكيل. تُحقق هذه البيانات عبر EIP191 (طريقة التوقيع المعتادة للمحفظة) أو ERC1271 (طريقة التوقيع الخاصة للمحفظة الذكية)، مما يمنع التزوير والهجمات المُعاد توجيهها. بما أن النقاط والعلامات (التصنيفات) يمكن الوصول إليها مباشرة من العقد الذكية، يمكن استخدامها كمصدر تلقائي لتحديد "هل هذا الوكيل موثوق به" من قبل التطبيقات الأخرى (dApps). ✅ التحقق من العمل (سجل التحقق) نظام يسمح لأطراف ثالثة بالتحقق من صحة النتائج التي ينتجها الوكيل. في v1.0، يتم تقديم الأدلة عبر URI (مرجع لبيانات خارجية) بدلًا من هاش واحد، ويمكن تسجيل نتائج التحقق متعددة المراحل لنفس الطلب. على سبيل المثال، يمكن بناء درجة ثقة تدريجية عبر مراحل مثل الفحص الأولي، الفحص التفصيلي، والتدقيق الخارجي. في الوقت الحالي، نحن في مرحلة التفاوض على المواصفات مع مجتمع TEE (البيئة التنفيذية الموثوقة). ✅ الأمان وتكاليف الغاز للتغلب على الأساليب الهجومية التي تم اكتشافها أثناء استخدام الشبكة التجريبية، تم تعزيز نظام التحقق من التوقيع وتصميم التخزين. ومع ذلك، زادت تكاليف الغاز لكتابة التقييمات والتحقق، لكن الميزة تكمن في أن البيانات الموثوقة يمكن استخدامها مباشرة على السلسلة. تقل تكاليف الغاز بشكل كبير على الشبكات من المستوى الثاني (L2). ✅ الانتقال من v0.4 v1.0 غير متوافق مع الإصدارات السابقة، وقد تغير هيكل التخزين بشكل كامل. لذلك، يتم إعادة تعيين جميع المعلومات المسجلة السابقة والسمعة، ويجب على الوكيل إعادة التسجيل كـNFT، ويجب أن يتوافق نظام التقييم مع الطريقة الجديدة للتوقيع. في المستقبل، سيتم استخدام "طريقة الترقية بمساحة الأسماء" لتعزيز المواصفات دون حذف البيانات، وبالتالي لن تحدث عمليات إعادة تعيين كبيرة كهذه مرة أخرى.

📚 نظام يمنع MEV من خلال توزيع محتوى الكتلة ✅ لمحة عامة في هذه الاقتراح، يتم توضيح سبب حدوث MEV في Ethereum من الناحية الهيكلية، ثم يُقدَّم فكرة تقليل MEV إلى الصفر تقريبًا من خلال اتخاذ قرارات توزيعية حول "محتوى" الكتلة. الاقتراح يركز على اختيار المعاملات وترتيبها، وليس على هيكل الكتلة نفسها، ويقترح إضافة طبقة اتفاق جديدة في هذا الجانب. ✅ سبب واقع MEV الحقيقي يحدث MEV لأن المُعد أو المُحقق يمكنه اختيار أي معاملات يرغب في إدخالها في الكتلة وترتيبها كيفما يشاء. على الرغم من أن هيكل الكتلة في Ethereum متفق عليه بشكل توزيعي، إلا أن محتوى الكتلة يتم تحديده من قبل مُعد واحد فقط في فترة زمنية قصيرة. الحالة التي يُحدِّد فيها شخص واحد محتوى الكتلة هي السبب الجذري لحدوث MEV مثل التلاعب بالمعاملات أو الهجمات من نوع "السندويش". ✅ اتفاق الهيكل واتفاق المحتوى هما قضيتان منفصلتان تُحقق سلاسل الكتل بشكل جيد في اتفاق الهيكل، أي من يُعتبر صاحب الكتلة الصحيح. ومع ذلك، فإن قرار ما المعاملات التي يجب تضمينها وكيفية ترتيبها لم يُوزَّع بعد. يُوضِّح الاقتراح أن هذا الشكل مشابه لمشكلة الدفع المزدوج في الماضي. كما أن تركز سلطة على جهاز كمبيوتر واحد يؤدي إلى سوء استخدام، فإن محتوى الكتلة يجب أن يُقرَّر أيضًا عبر اتفاق. ✅ فكرة طبقة المحتوى يُقترح إضافة "طبقة محتوى" فوق هيكل الكتلة، وهي طبقة اتفاق مخصصة لتحديد محتوى المعاملات. في هذه الطبقة، يقوم عدة عقد بمشاركة الأدوار في اتخاذ قرارات حول ما المعاملات التي يجب تضمينها وكيفية ترتيبها. الهدف هو منع أي مُحقق أو مُعد من ترتيب المعاملات وفقًا لمصلحته الشخصية. ✅ آلية بروتوكول Alex الأساسية في مثال Alex، تُقسَّم المهام إلى: جمع المعاملات، ترتيبها بشكل عشوائي، وإدارة الكتلة وتطبيقها. كل جزء يعمل بشكل مستقل، وإذا حاول أحد المشاركين ارتكاب خدعة، فإن المشاركين الآخرين سيقومون بالتحقق والتصحيح. بفضل هذا التصميم، تصبح مراجعة المعاملات أو ترتيبها بشكل تعسفي صعبة للغاية. ✅ العلاقة مع Ethereum الحالي هذا النظام لا يُهدِّد اتفاق Ethereum نفسه. يُحتفظ بهيكل الكتلة كما هو، ويُضاف فقط طبقة جديدة لتحديد محتوى الكتلة. يمكن تطبيق نفس الفكرة على المحققين في eth2، أو المُعدين في rollup، أو المُعدين الموزعين في المستقبل، لذا يُشيد بالطبيعة المُناسبة للتطبيق الواسع لهذا النظام. ✅ تأثير العدالة والكشف عن الأسعار في هذا التصميم، لا يتم استبعاد الأنشطة الضرورية في السوق مثل التوازن بين الأسعار. ومع ذلك، يُركز فقط على MEV الذي يُعتبر ابتزازًا غير قابل للوقاية من قبل المستخدمين. نتيجة لذلك، يهدف النظام إلى تحقيق عدالة داخل الشبكة نفسها، دون الحاجة إلى اتخاذ إجراءات معقدة من جانب التطبيقات.

📚 آلية جديدة لإضافة الخصوصية للرموز القائمة ✅ لمحة عامة يُقترح في هذا المحتوى مواصفة ERC جديدة تهدف إلى إضافة خصوصية للرموز الموجودة على منصة Ethereum دون تغيير استخدامها أو خصائصها. وتشمل هذه الرموز التي تُستخدم على نطاق واسع مثل ERC20 وERC721 وERC1155، وتهدف إلى توفير آلية تجعل تتبع المعاملات أكثر صعوبة. ✅ ما الذي يُحله هذا الاقتراح؟ في الوقت الحالي، يمكن رؤية كل معاملات الرموز على منصة Ethereum على السلسلة، أي من الذي أرسل إلى من. وإذا كانت هذه الشفافية ميزة، إلا أنها تُسبب مشكلة في تتبع الرصيد والتحويلات من قبل الطرف الثالث بسهولة. وتحاول هذه المواصفة ERC معالجة هذا الضعف دون إعادة بناء الرموز نفسها. ✅ فكرة رابط الرموز باستخدام معرفات صفرية يُعرف رابط الرموز باستخدام معرفات صفرية بأنه نظام يُستخدم فيه الرمز القائم كوديعة أولية، ويُستبدل بـ"رمز مُغلف". يمكن إرسال هذا الرمز المُغلف أو تداوله بنفس طريقة الرمز الأصلي، لكنه يخفي ملكيته داخليًا باستخدام التزامات (تعهدات تُثبت صحتها لاحقًا بشكل تشفيري). ✅ قطع السجلات عبر عمليات الحرق وإعادة الطباعة النقطة المميزة هنا هي تطبيق تدفق يجمع بين حرق الرموز (جعلها غير صالحة) وإعادة إصدارها (طباعة جديدة). عند تقديم إثبات صفر معرف (تقنية تشفيرية تُثبت صحة شيء دون كشف محتواه) الذي يفي بشرط معين، تُصدر رموز جديدة غير مرتبطة بالرموز المحروقة سابقًا. بهذا، تصبح عملية تتبع المعاملات على السلسلة أكثر صعوبة. ✅ في حالة الرموز القابلة للتبادل مثل ERC20 في حالة الرموز القابلة للتبادل مثل ERC20، يمكن لهذا النظام فصل تدفق الأموال بشكل عملي. من الصعب معرفة من يمتلك كم رصيدًا من الخارج حتى يتم السحب النهائي. ✅ ما يمكن القيام به في حالة الرموز غير القابلة للتبادل (NFT) بما أن الرموز غير القابلة للتبادل مثل ERC721 فريدة من نوعها، لا يمكن مزجها بشكل كامل. مع ذلك، يمكن إخفاء من يمتلك هذه الرموز في الوقت الحالي حتى يتم تنفيذ عملية السحب. ✅ استخدام سلس دون وعي من المستخدم يُتوقع أن يستخدم المستخدم هذا النظام دون أن يدرك وجود الرموز المغلفة. من خلال معالجة المحفظة أو التطبيق داخليًا، يمكن الاستفادة من الخصوصية مع الحفاظ على تجربة المستخدم المعتادة. ✅ التوافق مع النظام البيئي الحالي بما أن هذا النظام لا يصدر رموزًا جديدة مخصصة، بل يغلف الرموز القائمة، فإن إمكانية دمجها مع النظام البيئي الحالي لـEthereum مثل منصات التداول اللامركزي (DEX) والخدمات اللامركزية (DeFi) تُعتبر ميزة كبيرة. يمكن إضافة الخصوصية دون التأثير على سيولة الرموز أو نطاق استخدامها.

📚ERC7694 لقد قمنا بملخص حول "ERC7694" وهو اقتراح لآلية تتيح لعقود Ethereum الذكية معالجة Solana كتخزين خارجي وإجراء عمليات الكتابة والقراءة بشكل آمن عبر السلاسل! https://t.co/hYzUup7dBO