لتعزيز ضمانات الأمان والوصاية للعملاء الذين يتداولون ERC-20 وغيرها من الأصول القائمة على العقود الذكية ، قام فريق Coinbase Blockchain Security بالتحقيق في الطبقة البرمجية التي تحدد سلوك هذه الأصول: جهاز Ethereum Virtual Machine (EVM). عند تقييم المشاريع التي تعدل EVM لشبكتها الخاصة ، يقوم فريق أمان blockchain في Coinbase بمراجعة التغييرات الرئيسية في EVM لتحديد ما إذا كان يمكن لـ EVM المعدل توفير نفس ضمانات الأمان والحضانة مثل تنفيذ EVM الأصلي.
حالة الشوكة EVM
اعتبارًا من مايو 2023 ، فازت Ethereum Virtual Machine (EVM) بلقب "Big Brother" لمنصة تنفيذ العقود الذكية الأكثر شهرة. وفقًا لـ DefiLlama ، تدعم 9 من أفضل 10 سلاسل بواسطة Total Value Locked (TVL) العقود الذكية EVM. لذلك ، يعد الفهم العميق لـ EVM أمرًا بالغ الأهمية لدعم العقود الذكية في نظام blockchain البيئي بأكمله.
EVM هي آلة افتراضية للتنفيذ اللامركزي للعقود الذكية على شبكة Ethereum. تستفيد العديد من سلاسل الكتل المتوافقة مع EVM من التطبيقات القياسية لعملاء تنفيذ Ethereum المشهورين بلغات مختلفة مثل go-ethereum (Golang) و besu (Java) مباشرةً في برنامج البروتوكول الخاص بهم.
ومع ذلك ، فإن تشكيل وتعديل EVM أمر شائع في الواقع في نظام blockchain البيئي ، حتى ضمن البروتوكولات الرئيسية. على سبيل المثال ، يستخدم Optimism Bedrock Stack الذي "يدعم" بلوكشين Base L2 الخاص بـ Coinbase شوكة من عميل تنفيذ go-ethereum يسمى op-geth ، والذي يدير نفس EVM مثل عميل تنفيذ ethereum الشهير. متوافق. ومع ذلك ، هذا لا يعني أن EVM على Ethereum يتصرف تمامًا مثل EVM على التفاؤل: يتصرف op-geth EVM بشكل مختلف قليلاً في بعض الحالات (على سبيل المثال ، يتم تحديد القيم العشوائية المرتجعة بواسطة جهاز التسلسل).
في حين أن هذا يبدو مخيفًا ، إلا أنه مفيد بشكل عام لاعتماد EVM. بينما يتم تحسين تنفيذ معيار EVM بدرجة عالية لبروتوكول Ethereum الأساسي ، غالبًا ما تقوم أجهزة EVM المتشعبة بتمديدها لبروتوكولات جديدة خاصة بها. نتيجة لذلك ، قد يتم تنفيذ العقود بشكل مختلف على بعض السلاسل المتوافقة مع EVM عن تلك التي يتم تنفيذها على Ethereum ، وقد تختلف الافتراضات الأمنية لسلوك عقد EVM الذكي بشكل كبير بين البروتوكولات المختلفة.
تفرع إطار أمان EVM
تحقيقا لهذه الغاية ، طورت Coinbase إطار عمل أمان Web3 لتقييم التأثير الأمني لبعض تطبيقات EVM المتشعبة. نسميها إطار عمل EVM المتشعب من Coinbase ، والذي سيتم شرحه بالتفصيل أدناه.
من خلال إطار عمل أمان EVM المتشعب هذا ، تستطيع Coinbase القيام بما يلي بفاعلية:
يتيح لنا فهم عدم صلاحية افتراضات الأمان الخاصة بإطار عمل رمز Ethereum الخاص بنا تمكين سلاسل الكتل المتوافقة مع EVM بأمان لدعم الرموز المميزة ERC-20 / ERC-721 في بورصاتنا اللامركزية ؛
تزويد مدققي العقود الأذكياء بتحليل لحالة ضعف العقد الذكي لجهاز EVM المتشعب ، لا سيما الاختلافات الصغيرة في الشبكات المتقاطعة ؛
ضمان الاستخدام الآمن والتنفيذ الآمن لعقود EVM الذكية على blockchain Base L2 الخاص بـ Coinbase.
معيار الأمان لسلاسل الكتل المتوافقة مع EVM
من أجل فهم كيفية وجود مخاطر الأمان في الجهاز الظاهري لـ Ethereum ، يجب علينا أولاً معرفة الضمانات التي يوفرها لنا تنفيذ EVM القياسي. نحن نعرّف EVM القياسي على أنه EVM الذي يستخدمه عملاء تنفيذ المدقق في Ethereum كما هو موضح في مواصفات تنفيذ Ethereum. إلى حد بعيد العميل الأكثر استخدامًا هو go ethereum (أي geth).
نلخص الأمان في معيارين للأمان يمثلان الحد الأدنى من المتطلبات لأي تطبيق EVM متشعب ليكون مؤهلاً للحصول على دعم Coinbase.
كيف نقوم بتدقيق المخاطر الأمنية لتطبيق EVM؟
يركز إطار عمل EVM المتشعب الخاص بنا على متطلبات التدقيق التالية عند تقييم الامتثال لمعايير الأمان العامة (أي ثبات العقد وبيئة تنفيذ آمنة). وتجدر الإشارة إلى أن عناصر المخاطر التالية ليست هي النطاق الكامل لتدقيق نموذج التقييم الإلكتروني للشوكة.
يمكن أن يؤدي تعديل تعريف وتشفير أكواد تشغيل EVM إلى اختلافات كبيرة في كيفية تنفيذ العقود. على سبيل المثال ، افترض أن بعض تنفيذ EVM المتشعب (EVM ') يغير كود التشغيل ADD الحسابي لتحديد المنطق (x1 + x2) لطرح قيمتين (x1 - x2).
نتيجة لذلك ، فإن EVM المنحرف غير متكافئ وغير متوافق في التنفيذ مع معيار EVM. يمكن أن تكون عواقب تعديل أكواد التشغيل سلوكًا مفيدًا ، مثل منع تجاوز عدد صحيح وتدفق في أكواد العمليات الحسابية ، أو سلوك أكثر خطورة ، مثل سلوك التدمير الذاتي الذي يتسبب في سك النقود اللانهائية للأصول المحلية.
يستخدم EVM العقود المجمعة مسبقًا لتحديد الوظائف المعقدة (مثل وظائف التشفير) ، باستخدام لغة أكثر ملاءمة وأداءً مثل Golang ، بدلاً من استخدام رمز EVM الثانوي الذي يصعب الوصول إليه.
في الأساس ، هذه وظائف مبرمجة يتم الوصول إليها من خلال عناوين سلسلة محددة مسبقًا ممثلة في برنامج العقدة. هناك 9 برامج ترجمة مسبقة محددة في ورقة Ethereum Yellow Paper (اعتبارًا من مايو 2023) ، وأي تغييرات تطرأ على هذه المجمعات التسعة المسبقة أو إدخال المترجمات الجديدة يجب أن يتم تدقيقها.
لنأخذ مثالًا ملموسًا آخر - ثغرة BNB Smart Chain. تستخدم سلسلة BNB الذكية تطبيقًا منحرفًا لـ go-ethereum لتشغيل العقد. تحقيقًا لهذه الغاية ، تم تقديم عقدين جديدين مُجمَّعين مسبقًا (tmHeaderValidate ، iavlMerkleProofValidate) لاستخدام برامج الجهات الخارجية (مثل Cosmos SDK) لإجراء التحقق من صحة كتلة العميل الخفيف والتحقق من صحة دليل Merkle. تكمن المشكلة في أن برنامج Cosmos SDK به خطأ في التنفيذ في تمثيل شجرة IAWL الخاص به والذي يسمح للبراهين غير الصالحة من الناحية المشفرة بتمرير التحقق. بعبارة أخرى ، يمكن لأي شخص أن يدر الأموال من فراغ. كان المهاجمون قادرين على استغلال هذا الخلل في التنفيذ المتداخل في iavlMerkleProofValidate preompiler لسحب مئات الملايين من الدولارات من جسر سلسلة متقاطعة Binance.
يهدف مثال استغلال هذا إلى توضيح الحاجة إلى أمان ما قبل المترجم والمخاطر المحتملة لتقديم عقود جديدة مجمعة مسبقًا لانحراف تطبيقات EVM.
تتضمن المخاطر القاتلة المحتملة لإدخال المترجمات الإضافية ما يلي:
السماح لطرف واحد بتعديل حالة أي عقد تم نشره من جانب واحد ؛
يشمل ذلك جميع تعديلات التخزين (الإدخالات والتحديثات والحذف) ؛
استخدام تبعيات طرف ثالث غير موثوق بها أو غير مؤكدة أو غير مدققة ؛
يوفر الوصول إلى القيمة داخل العقدة غير المحددة.
على الرغم من معاملة المترجم و EVM ككيانات منفصلة تمامًا ، تجدر الإشارة إلى أن مترجم Solidity يضع افتراضات صارمة حول سلوك العقود الثلاثة الأولى المجمعة مسبقًا (ecrecover و sha256 و & ripemd) التي يتم تمريرها من خلال Solidity وظيفة الكلمات الرئيسية للغة الأصلية التمثيل في اللغة. خلف الكواليس ، يقوم مترجم Solidity بالفعل بمعالجة هذه الكلمات الرئيسية في رمز ثانوي ، والذي ينفذ مكالمات ثابتة بين العقود. يوضح الرسم البياني أدناه هذه الطريقة للتواصل بين العقود.
تشمل المخاطر الأمنية التي يتم تقديمها من خلال تعديل المترجم المسبق القياسي ما يلي:
السماح للأطراف المقابلة المركزية بتعديل حالة أي عقد يتم نشره من جانب واحد ؛
يشمل ذلك جميع تعديلات التخزين (الإدخالات والتحديثات والحذف) ؛
افتراض موقف التجميع المسبق لمترجم Solidity غير متسق ؛
يوفر الوصول إلى القيم داخل العقد غير المحددة ؛
استخدام تبعيات جهات خارجية غير موثوقة أو غير مؤكدة أو غير مدققة.
تشمل المخاطر الرئيسية التي يشكلها تعديل المكونات الأساسية لآلية التقييم الإلكترونية ما يلي:
لا يقيد حجم مكدس المترجم الشفهي ليكون كبيرًا بشكل لا نهائي ؛
تغيير حجم نموذج الذاكرة أو تغييره قد يؤدي إلى تنفيذ غير حتمي ؛
تجاوز التحكم في الوصول ، مما يسمح لأي طرف مقابل بالوصول من جانب واحد إلى جميع حالات السلسلة ؛
استخدام تبعيات جهات خارجية غير موثوقة أو غير مؤكدة أو غير مدققة.
لماذا يجب الانتباه لأمن EVM؟
هدفنا هو بناء نظام مالي مفتوح يعتمد على تقنية blockchain ، وتحقيقا لهذه الغاية ، نشجع على تطوير تطبيقات EVM المختلفة. ومع ذلك ، لكي يتم دعم blockchain المتوافق مع EVM بشكل كامل بواسطة Coinbase ، يجب أن يفي بالمتطلبات الأساسية لتطبيق EVM القياسي. تأمل هذه الورقة في زيادة الوعي بالمخاطر المرتبطة بالانحراف عن آلية EVM ، وتشجيع مصدري الأصول على إعطاء الأولوية لتطوير المكونات الآمنة عند الانحراف عن EVM ، وزيادة الوعي الأمني عبر النظام البيئي Web3 بأكمله.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
كيف يتم تقييم المخاطر الأمنية لـ "EVM المتشعب"؟
** العنوان الأصلي: "**** How to uate Forked EVMs for Security Risks ****" **
** 撰文 ： إيثان بوساسك ، إريك مينج ، نادر أختار ، غابرييلا ميلينديز كوان ، توم ريان **
** المترجم: كاتي كو **
لتعزيز ضمانات الأمان والوصاية للعملاء الذين يتداولون ERC-20 وغيرها من الأصول القائمة على العقود الذكية ، قام فريق Coinbase Blockchain Security بالتحقيق في الطبقة البرمجية التي تحدد سلوك هذه الأصول: جهاز Ethereum Virtual Machine (EVM). عند تقييم المشاريع التي تعدل EVM لشبكتها الخاصة ، يقوم فريق أمان blockchain في Coinbase بمراجعة التغييرات الرئيسية في EVM لتحديد ما إذا كان يمكن لـ EVM المعدل توفير نفس ضمانات الأمان والحضانة مثل تنفيذ EVM الأصلي.
حالة الشوكة EVM
اعتبارًا من مايو 2023 ، فازت Ethereum Virtual Machine (EVM) بلقب "Big Brother" لمنصة تنفيذ العقود الذكية الأكثر شهرة. وفقًا لـ DefiLlama ، تدعم 9 من أفضل 10 سلاسل بواسطة Total Value Locked (TVL) العقود الذكية EVM. لذلك ، يعد الفهم العميق لـ EVM أمرًا بالغ الأهمية لدعم العقود الذكية في نظام blockchain البيئي بأكمله.
EVM هي آلة افتراضية للتنفيذ اللامركزي للعقود الذكية على شبكة Ethereum. تستفيد العديد من سلاسل الكتل المتوافقة مع EVM من التطبيقات القياسية لعملاء تنفيذ Ethereum المشهورين بلغات مختلفة مثل go-ethereum (Golang) و besu (Java) مباشرةً في برنامج البروتوكول الخاص بهم.
ومع ذلك ، فإن تشكيل وتعديل EVM أمر شائع في الواقع في نظام blockchain البيئي ، حتى ضمن البروتوكولات الرئيسية. على سبيل المثال ، يستخدم Optimism Bedrock Stack الذي "يدعم" بلوكشين Base L2 الخاص بـ Coinbase شوكة من عميل تنفيذ go-ethereum يسمى op-geth ، والذي يدير نفس EVM مثل عميل تنفيذ ethereum الشهير. متوافق. ومع ذلك ، هذا لا يعني أن EVM على Ethereum يتصرف تمامًا مثل EVM على التفاؤل: يتصرف op-geth EVM بشكل مختلف قليلاً في بعض الحالات (على سبيل المثال ، يتم تحديد القيم العشوائية المرتجعة بواسطة جهاز التسلسل).
في حين أن هذا يبدو مخيفًا ، إلا أنه مفيد بشكل عام لاعتماد EVM. بينما يتم تحسين تنفيذ معيار EVM بدرجة عالية لبروتوكول Ethereum الأساسي ، غالبًا ما تقوم أجهزة EVM المتشعبة بتمديدها لبروتوكولات جديدة خاصة بها. نتيجة لذلك ، قد يتم تنفيذ العقود بشكل مختلف على بعض السلاسل المتوافقة مع EVM عن تلك التي يتم تنفيذها على Ethereum ، وقد تختلف الافتراضات الأمنية لسلوك عقد EVM الذكي بشكل كبير بين البروتوكولات المختلفة.
تفرع إطار أمان EVM
تحقيقا لهذه الغاية ، طورت Coinbase إطار عمل أمان Web3 لتقييم التأثير الأمني لبعض تطبيقات EVM المتشعبة. نسميها إطار عمل EVM المتشعب من Coinbase ، والذي سيتم شرحه بالتفصيل أدناه.
من خلال إطار عمل أمان EVM المتشعب هذا ، تستطيع Coinbase القيام بما يلي بفاعلية:
معيار الأمان لسلاسل الكتل المتوافقة مع EVM
من أجل فهم كيفية وجود مخاطر الأمان في الجهاز الظاهري لـ Ethereum ، يجب علينا أولاً معرفة الضمانات التي يوفرها لنا تنفيذ EVM القياسي. نحن نعرّف EVM القياسي على أنه EVM الذي يستخدمه عملاء تنفيذ المدقق في Ethereum كما هو موضح في مواصفات تنفيذ Ethereum. إلى حد بعيد العميل الأكثر استخدامًا هو go ethereum (أي geth).
نلخص الأمان في معيارين للأمان يمثلان الحد الأدنى من المتطلبات لأي تطبيق EVM متشعب ليكون مؤهلاً للحصول على دعم Coinbase.
كيف نقوم بتدقيق المخاطر الأمنية لتطبيق EVM؟
يركز إطار عمل EVM المتشعب الخاص بنا على متطلبات التدقيق التالية عند تقييم الامتثال لمعايير الأمان العامة (أي ثبات العقد وبيئة تنفيذ آمنة). وتجدر الإشارة إلى أن عناصر المخاطر التالية ليست هي النطاق الكامل لتدقيق نموذج التقييم الإلكتروني للشوكة.
يمكن أن يؤدي تعديل تعريف وتشفير أكواد تشغيل EVM إلى اختلافات كبيرة في كيفية تنفيذ العقود. على سبيل المثال ، افترض أن بعض تنفيذ EVM المتشعب (EVM ') يغير كود التشغيل ADD الحسابي لتحديد المنطق (x1 + x2) لطرح قيمتين (x1 - x2).
نتيجة لذلك ، فإن EVM المنحرف غير متكافئ وغير متوافق في التنفيذ مع معيار EVM. يمكن أن تكون عواقب تعديل أكواد التشغيل سلوكًا مفيدًا ، مثل منع تجاوز عدد صحيح وتدفق في أكواد العمليات الحسابية ، أو سلوك أكثر خطورة ، مثل سلوك التدمير الذاتي الذي يتسبب في سك النقود اللانهائية للأصول المحلية.
يستخدم EVM العقود المجمعة مسبقًا لتحديد الوظائف المعقدة (مثل وظائف التشفير) ، باستخدام لغة أكثر ملاءمة وأداءً مثل Golang ، بدلاً من استخدام رمز EVM الثانوي الذي يصعب الوصول إليه.
في الأساس ، هذه وظائف مبرمجة يتم الوصول إليها من خلال عناوين سلسلة محددة مسبقًا ممثلة في برنامج العقدة. هناك 9 برامج ترجمة مسبقة محددة في ورقة Ethereum Yellow Paper (اعتبارًا من مايو 2023) ، وأي تغييرات تطرأ على هذه المجمعات التسعة المسبقة أو إدخال المترجمات الجديدة يجب أن يتم تدقيقها.
لنأخذ مثالًا ملموسًا آخر - ثغرة BNB Smart Chain. تستخدم سلسلة BNB الذكية تطبيقًا منحرفًا لـ go-ethereum لتشغيل العقد. تحقيقًا لهذه الغاية ، تم تقديم عقدين جديدين مُجمَّعين مسبقًا (tmHeaderValidate ، iavlMerkleProofValidate) لاستخدام برامج الجهات الخارجية (مثل Cosmos SDK) لإجراء التحقق من صحة كتلة العميل الخفيف والتحقق من صحة دليل Merkle. تكمن المشكلة في أن برنامج Cosmos SDK به خطأ في التنفيذ في تمثيل شجرة IAWL الخاص به والذي يسمح للبراهين غير الصالحة من الناحية المشفرة بتمرير التحقق. بعبارة أخرى ، يمكن لأي شخص أن يدر الأموال من فراغ. كان المهاجمون قادرين على استغلال هذا الخلل في التنفيذ المتداخل في iavlMerkleProofValidate preompiler لسحب مئات الملايين من الدولارات من جسر سلسلة متقاطعة Binance.
يهدف مثال استغلال هذا إلى توضيح الحاجة إلى أمان ما قبل المترجم والمخاطر المحتملة لتقديم عقود جديدة مجمعة مسبقًا لانحراف تطبيقات EVM.
تتضمن المخاطر القاتلة المحتملة لإدخال المترجمات الإضافية ما يلي:
على الرغم من معاملة المترجم و EVM ككيانات منفصلة تمامًا ، تجدر الإشارة إلى أن مترجم Solidity يضع افتراضات صارمة حول سلوك العقود الثلاثة الأولى المجمعة مسبقًا (ecrecover و sha256 و & ripemd) التي يتم تمريرها من خلال Solidity وظيفة الكلمات الرئيسية للغة الأصلية التمثيل في اللغة. خلف الكواليس ، يقوم مترجم Solidity بالفعل بمعالجة هذه الكلمات الرئيسية في رمز ثانوي ، والذي ينفذ مكالمات ثابتة بين العقود. يوضح الرسم البياني أدناه هذه الطريقة للتواصل بين العقود.
تشمل المخاطر الأمنية التي يتم تقديمها من خلال تعديل المترجم المسبق القياسي ما يلي:
تشمل المخاطر الرئيسية التي يشكلها تعديل المكونات الأساسية لآلية التقييم الإلكترونية ما يلي:
لماذا يجب الانتباه لأمن EVM؟
هدفنا هو بناء نظام مالي مفتوح يعتمد على تقنية blockchain ، وتحقيقا لهذه الغاية ، نشجع على تطوير تطبيقات EVM المختلفة. ومع ذلك ، لكي يتم دعم blockchain المتوافق مع EVM بشكل كامل بواسطة Coinbase ، يجب أن يفي بالمتطلبات الأساسية لتطبيق EVM القياسي. تأمل هذه الورقة في زيادة الوعي بالمخاطر المرتبطة بالانحراف عن آلية EVM ، وتشجيع مصدري الأصول على إعطاء الأولوية لتطوير المكونات الآمنة عند الانحراف عن EVM ، وزيادة الوعي الأمني عبر النظام البيئي Web3 بأكمله.