غسيل الكلى الأمني المضلع المحارب المضلع: كيفية ضمان الأمن والاستقرار عبر السلسلة؟

المؤلف: تشنغدو ليانان
الأصل: “بحث حول أمن الجسور عبر السلاسل (3)” | غسيل الكلى الآمن للمحارب المضلع ، وكيفية منع فتح “صندوق باندورا”؟

مرحبا بكم في سلسلة المقالات حول “أبحاث أمان الجسر عبر السلسلة” التي تنتجها Chengdu Chain Security ، في المقالة السابقة (أبحاث أمان جسر عبر السلسلة (2) | ماذا تجلب لنا أول عملية سطو لامركزية لجسر البدو؟) ، نجري تحليلا فنيا احترافيا لبروتوكول جسر البدوي بالتفصيل.

اليوم ، سيقوم فريق أبحاث أمن سلسلة تشنغدو بإجراء غسيل كلوي آمن ل Polygon ، وهو محارب مضلع ، لذا استمر في القراءة.

من هو 1_Polygon؟

Polygon هو حل تحجيم الطبقة 2 من Ethereum ، مع رؤية لبناء إنترنت blockchain الخاص ب Ethereum. يوفر Polygon إطارا مشتركا يسمح للمطورين بالاستفادة من أمان Ethereum لإنشاء سلاسل مخصصة تركز على التطبيقات وتوفير شبكة قابلة للتشغيل البيني تجمع بين مجموعة متنوعة من مخططات التوسع المختلفة مثل: zk-rollup و PoS وما إلى ذلك. من بينها ، يعد Polygon PoS حاليا حل التحجيم الأكثر نضجا وشهرة على Polygon. يستخدم السلسلة الجانبية لمعالجة المعاملات لتحقيق الغرض من تحسين سرعة المعاملات وتوفير استهلاك الغاز ، ويتضمن هيكل الشبكة بشكل أساسي الطبقات الثلاث التالية:

طبقة الإيثريوم:

سلسلة من العقود على شبكة Ethereum الرئيسية ، بما في ذلك بشكل أساسي: عقود Staking و Checkpoint و Reward ، مسؤولة عن وظائف إدارة Staking المتعلقة بحصص PoS ، بما في ذلك: توفير وظيفة Staking لرمز MATIC الأصلي ، بحيث يمكن لأي شخص يخزن الرمز المميز الانضمام إلى النظام كمدقق ، والتحقق من تحويل شبكة Polygon للحصول على مكافآت Staking ، ومعاقبة المدققين على التوقيعات المزدوجة ، ووقت تعطل المدقق والسلوكيات غير القانونية الأخرى ، وحفظ نقاط التفتيش.

طبقة هايمدال:

طبقة مدقق إثبات الحصة ، والتي تتكون من مجموعة من عقد PoS Heimdall ، مسؤولة عن إرسال نقاط التفتيش الخاصة بشبكة Polygon إلى شبكة Ethereum الرئيسية أثناء الاستماع إلى مجموعة من عقود التخزين المنشورة على Ethereum. العملية الرئيسية هي كما يلي: أولا ، حدد مجموعة فرعية من المدققين النشطين في تجمع المدققين كمنتجي كتلة ، والذين سيكونون مسؤولين عن إنشاء كتل في طبقة بور وبثها ، ثم التحقق من صحة تجزئة جذر Merkle وإلحاق التوقيعات بناء على نقاط التفتيش المقدمة من بور ، وأخيرا ، سيكون مقدم العرض مسؤولا عن جمع جميع توقيعات المدقق لنقطة التفتيش المحددة ، وإذا وصل عدد التوقيعات إلى أكثر من 2/3 ، تقديم نقطة التفتيش على Ethereum.

طبقة بور:

طبقة منتج الكتلة ، التي تتكون من مجموعة من منتجي البلوك يتم اختيارهم بانتظام من قبل لجنة من المدققين على طبقة Heimdall ، هي مجموعة فرعية من المدققين المسؤولين عن تجميع المعاملات على السلسلة الجانبية Polygon وتوليد الكتل. تنشر هذه الطبقة بشكل دوري نقاط التفتيش إلى طبقة Heimdall ، حيث تمثل نقطة التفتيش لقطة لسلسلة بور ، كما هو موضح في الصورة أدناه.

2_Polygon قابلية التشغيل البيني

2.1 نقطة تفتيش

آلية نقطة التفتيش هي آلية لمزامنة بيانات طبقة بور مع Ethereum ، حيث تكون البيانات المتزامنة نقطة تفتيش ، أي لقطة لبيانات الكتلة لطبقة Bor الموجودة في فاصل نقطة تفتيش ، الكود المصدري كما يلي:

مقدم العرض: مقدم العرض ، الذي يتم اختياره أيضا من قبل المدققين ، ومنتجي الكتل ومقدمي العروض هم مجموعة فرعية من المدققين ، ويتم تحديد مسؤولياتهم من خلال حصتهم في المجموعة الإجمالية

RootHash: عبارة عن تجزئة Merkle تم إنشاؤها من كتلة Bor بين StartBlock و EndBlock

فيما يلي رمز زائف لكتلة Bor المرقمة من 1 إلى n لإنشاء قيمة RootHash:

باختصار ، هذه القيمة هي قيمة تجزئة الجذر لشجرة Merkel ، والتي تتكون من رقم الكتلة في رأس كتلة Bor ، والطابع الزمني للكتلة ، وقيمة تجزئة جذر شجرة المعاملة tx hash ، وقيمة تجزئة keccak256 المحسوبة من تجزئة جذر شجرة الإيصالات.

AccountRootHash: تجزئة Merkle لمعلومات الحساب المتعلقة بالمدقق والتي يجب إرسالها إلى كل نقطة تفتيش على Ethereum ، ويتم حساب قيمة التجزئة لمعلومات الحساب الفردي على النحو التالي:

يتم إنشاء AccountRootHash من تجزئة جذر شجرة Merkle للحساب بنفس طريقة قيمة RootHash.

2.2 StateSync

يشير StateSync إلى مزامنة بيانات Ethereum مع سلسلة Polygon Matic ، والتي تنقسم بشكل أساسي إلى الخطوات التالية:

1. أولا ، سيؤدي العقد الموجود على Ethereum إلى تشغيل وظيفة syncState () في StateSender.sol لمزامنة الحالة

2. ستصدر وظيفة syncState () حدثا على النحو التالي:

3. سيتلقى جميع المدققين في طبقة Heimdall الحدث ، وسيقوم أحد المدققين بحزم المعاملة في كتلة heimdall وإضافتها إلى قائمة مزامنة الحالة المعلقة ؛

4. ستحصل عقدة طبقة bor على القائمة أعلاه لمزامنتها من خلال واجهة برمجة التطبيقات ، وتسليمها إلى عقد طبقة bor لمزيد من معالجة منطق الأعمال.

2.3 جسر مضلع

يتيح Polygon Bridge قناة عبر السلسلة ثنائية الاتجاه بين Polygon و Ethereum ، مما يسهل على المستخدمين نقل الرموز المميزة بين منصتين مختلفتين للسلسلة دون تهديدات الطرف الثالث وقيود سيولة السوق. هناك نوعان من جسر المضلع ، PoS و Plasma ، وكلاهما لهما أوجه التشابه التالية في نقل الأصول بين Polygon و Ethereum:

1. تحتاج أولا إلى تعيين الرمز المميز على Ethereum إلى Polygon ، كما هو موضح في الصورة أدناه:

2. يتم استخدام تقنية التثبيت ثنائية الاتجاه (Peg ثنائي الاتجاه) أيضا ، أي

ج: سيتم قفل جميع أصول الرمز المميز المنقولة من Ethereum على Ethereum أولا ، وسيتم سك نفس العدد من الرموز المميزة المعينة على Polygon ؛

ب: من أجل سحب أصول الرمز المميز إلى Ethereum ، تحتاج أولا إلى نسخ هذه الرموز المميزة المعينة على Polygon ، ثم إلغاء قفل الأصول المقفلة على Ethereum ؛

يوضح الشكل التالي المقارنة بين جسر PoS وجسر البلازما:

كما يتضح من الشكل أعلاه ، من حيث الأمان ، يعتمد PoS Bridge على أمان مجموعة المدقق الخارجي ، بينما تعتمد البلازما على أمان سلسلة Ethereum الرئيسية. في الوقت نفسه ، عندما يقوم المستخدمون بإجراء عمليات نقل الأصول عبر السلسلة (مثل نقل الرموز المميزة من Polygon إلى Ethereum) ، لا تتطلب PoS سوى فاصل زمني لنقطة التفتيش ، حوالي 20 دقيقة إلى 3 ساعات ، بينما تتطلب Plasma فترة تحدي نزاع مدتها 7 أيام. في الوقت نفسه ، تدعم PoS المزيد من الرموز القياسية ، بينما تدعم Plasma ثلاثة أنواع فقط ، بما في ذلك: ETH و ERC20 و ERC721.

3 \ _Cross سلسلة الرسائل - جسر نقاط البيع

يتكون جسر PoS بشكل أساسي من وظيفتين: يشير الإيداع إلى نقل أصول المستخدمين على Ethereum إلى Polygon ، وتشير عمليات السحب إلى سحب الأصول من Polygon إلى Ethereum.

الإيداع

فيما يلي مثال على استخدام المستخدم أليس لجسر نقاط البيع لإرسال أصول رمزية من حساب Ethereum الخاص بها إلى حساب Polygon الخاص بها:

1. إذا كانت أصول الرمز المميز التي تريد نقلها هي ERC20 أو ERC721 أو ERC1155 ، فأنت بحاجة إلى تفويض الرمز المميز الذي تريد نقله من خلال وظيفة approtect . كما هو موضح أدناه ، فإن العدد المقابل من الرموز المميزة مصرح به لعقد erc20Prefer عن طريق استدعاء طريقة approtect في عقد الرمز المميز على Ethereum.

تحتوي وظيفة approtect على معلمتين:

• المنفق: عنوان الوجهة حيث يأذن المستخدم بإنفاق الرموز المميزة

• المبلغ: عدد الرموز التي يمكن إنفاقها

2. بعد تأكيد معاملة التفويض المذكورة أعلاه ، يقوم المستخدم بعد ذلك بتأمين الرمز المميز في عقد erc20Initial على Ethereum عن طريق استدعاء طريقة depositFor() لعقد RootChainManager. هنا ، إذا كان نوع الأصل المراد نقله هو ETH ، استدعاء depositEtherFor() . وفيما يلي التفاصيل:

تحتوي الدالة depositFor على ثلاث معلمات:

• user: عنوان المستخدم الذي تلقى رموز الإيداع على Polygon

• rootToken: عنوان الرمز المميز على سلسلة Ethereum الرئيسية

• بيانات الإيداع: عدد الرموز المشفرة بواسطة ABI

فيما يلي رمز محدد للدالة depositFor في عقد RootChainManager:

عند تحليل الكود المصدري ، يمكن ملاحظة أن الوظيفة تحصل أولا على عنوان العقد الأصلي المقابل للرمز المميز ، ثم تستدعي وظيفة lockTokens() الخاصة بها لقفل الرمز المميز في العقد. أخيرا ، سيتم استدعاء syncState() لمزامنة الحالة بواسطة _stateSender ، والتي لا يمكن استدعاؤها إلا بواسطة مرسل الحالة الذي حدده المسؤول.

3. سترسل وظيفة syncState () في StateSender.sol الحدث StateSynced ، على وجه التحديد:

المعلمة الأولى هي فهرس رقم التسلسل للسجل ، ويتم استخدام المعلمة الثانية للتحقق مما إذا كان المتصل هو عنوان عقد شرعي مسجل ، والمعلمة الثالثة هي البيانات التي يجب مزامنتها مع الحالة. تتم إضافة المعاملة إلى كتلة Heimdall وتتم إضافتها إلى قائمة مزامنة الحالة المعلقة.

4. بعد ذلك ، بعد أن تحصل عقدة bor على سلسلة Polygon Matic على حدث StateSynced في قائمة مزامنة الحالة من خلال واجهة برمجة التطبيقات ، سيقوم عقد ChildChainManager على السلسلة باستدعاء وظيفة onStateReceive() ، والتي يتم استخدامها لتلقي بيانات المزامنة التي تم تحميلها من Ethereum ، والمتابعة إلى الخطوة التالية وفقا لنوع منطق الأعمال لمزامنة الحالة:

البيانات: bytes32 syncType وبايت syncData. عندما يقوم syncType بتعيين ، يكون syncData هو عنوان rootToken المشفر وعنوان childToken و bytes32 tokenType ، وعندما يكون syncType هو الإيداع ، يكون syncData هو عنوان المستخدم المشفر. عنوان rootToken وبيانات الإيداع من نوع البايت. depositData هي الكمية الموجودة في REC20 و tokenId في ERC721.

5. نظرا لأن هذا عمل إيداع ، استدعاء الدالة _syncDeposit(). ستقوم هذه الوظيفة أولا بفك تشفير syncData بالتنسيق المقابل للحصول على rootToken المقابل وعنوان المستخدم و depositData. ثم تحقق مما إذا كان rootToken يحتوي على رمز تعيين مطابق على المضلع ، واتصل بوظيفة deposit() الخاصة ب childToken إذا كان هناك.

6. هنا نأخذ عقد الرمز المميز ERC20 كمثال لتقديم كيفية إيداع عقد رمز التعيين. تنقل هذه الوظيفة العدد المقابل من الرموز المميزة إلى حساب المستخدم.

تحتوي الوظيفة على معلمتين:

• المستخدم: عنوان المستخدم الذي يقوم بالإيداع

• بيانات الإيداع: المبلغ المشفر في ABI

عمليات السحب

فيما يلي مثال على استخدام المستخدم Alice ل PoS Bridge لسحب الأموال المودعة في حساب Polygon الخاص بها إلى حساب Ethereum الخاص بها:

1. عندما ينسحب المستخدم ، فإنه يحتاج إلى نسخ العدد المقابل من الرموز المميزة المعينة عن طريق استدعاء وظيفة السحب () لعقد رمز التعيين على سلسلة Polygon.

يحتوي السحب على معلمة واحدة فقط: عدد الرموز المميزة التي سيتم حرقها. الدالة withdrawal() في عقد الرمز المميز المقابل هي كما يلي:

2. سيتم تضمين المعاملات المذكورة أعلاه في نقطة التفتيش بعد حوالي 20 دقيقة إلى 3 ساعات ، وسيقوم المدقق بإرسالها إلى Ethereum.

3. بمجرد إضافة المعاملة إلى نقطة التفتيش وتقديمها إلى Ethereum ، سيتم استدعاء وظيفة exit () لعقد RootChainManager على Ethereum ، والتي ستؤكد صحة معاملة السحب على Polygon من خلال التحقق من محتوى نقطة التفتيش المقدمة ، وتشغيل عقد Preindiate المقابل لفتح الرموز المميزة المودعة للمستخدم.

يتضمن إدخال إثبات البيانات التي تم تمريرها إلى الوظيفة البيانات التالية:

• headerNumber: يحتوي على رأس كتلة نقطة التفتيش لمعاملة السحب

• blockProof: إثبات أن رأس الكتلة في السلسلة الفرعية هو العقدة الورقية لجذر merkle الذي ارتكب

• blockNumber: رقم الكتلة على السلسلة الفرعية التي تحتوي على معاملة السحب

• blockTime: الطابع الزمني للكتلة لمعاملة السحب

• txRoot: القيمة الجذرية لشجرة معاملات الكتلة

• receiptRoot: القيمة الجذرية لشجرة إيصال الكتلة

• الإيصال: إيصال لمعاملة السحب

• إيصالProof: إثبات ميرك لإيصال معاملة السحب

branchMask: المسار إلى الإيصال الذي يمثله 32 بت في شجرة الإيصالات

• receiptLogIndex: فهرس السجل الذي تتم قراءته من شجرة الإيصالات

فيما يلي المنطق الأساسي للوظيفة ، والذي يتضمن بشكل أساسي ثلاثة أجزاء: الجزء الأول هو التحقق من صحة إيصال معاملة السحب ، والجزء الثاني هو التحقق مما إذا كانت نقطة التفتيش تحتوي على كتلة المعاملة ، والجزء الثالث هو استدعاء وظيفة exitTokens() في العقد الأصلي لإرسال الرموز المقفلة إلى المستخدم.

4. خذ عقد ERC20Predicate كمثال ، أي بعد فك تشفير المستلم والمرسل وعدد الرموز المميزة المرسلة من السجل ، سيتم إرسال عدد معين من الرموز المميزة إلى المستخدم.

وفقا لتحليل التعليمات البرمجية المصدر لعملية المراسلة عبر سلسلة PoS Bridge ، لا يمكن استدعاء استدعاءات الوظائف للعملية بأكملها إلا من خلال الدور المحدد من قبل المدقق ، وبالتالي فإن أمان السلسلة المتقاطعة مضمون فقط من قبل PoS (كاتب العدل).

4 \ _Cross سلسلة الرسائل - جسر البلازما

يتضمن جسر البلازما أيضا وظيفتين: الإيداع والسحب ، كما هو موضح في الشكل التالي:

يختلف Polygon Plasma قليلا عن تطبيق Bitcoin Plasma MVP الذي تم تقديمه في المقالة الأولى من سلسلة الجسور عبر السلسلة ، والتي تستخدم بشكل أساسي نموذج Plasma MoreVP المستند إلى الحساب. بالمقارنة مع البلازما ، تم تحسين الخوارزمية جزئيا في جزء السحب.

نظرا لأن نقل الرمز المميز ل ERC20 و ERC721 يتحقق من خلال سجل أحداث مشابه ل Bitcoin UXXO ، فلنقدم الحدث أولا:

• input1: رصيد حساب المرسل قبل التحويل

• input2: رصيد حساب المستلم قبل التحويل

• المخرج 1: رصيد حساب المرسل بعد التحويل

• الإخراج 2: رصيد حساب المستلم بعد التحويل

ثانيا ، نظرا لأن Plasma MVP الأصلي يتم إنشاؤه بواسطة مشغل واحد أو عدد صغير من منتجي الكتل ، فهناك سيناريوهان للهجوم على Polygon:

** مشغل الشر: **

المقال السابق (بحث حول أمن الجسور عبر السلسلة (2) | Nomad cross-chain) أنه عندما يتم حزم معاملة المستخدم في كتلة بلازما من قبل المشغل ، يكون هناك عدم توفر للبيانات خارج السلسلة. لذلك ، عندما يقوم المستخدم بإجراء معاملة خروج ، إذا بدأ في الانسحاب من معاملة قديمة ، يمكن للمشغل تحديها بإحدى أحدث معاملاته ، وسيكون التحدي ناجحا. في الوقت نفسه ، نظرا لآلية التحقق PoS المستخدمة في البلازما ، إذا تواطأ المشغل مع المدققين لفعل الشر ، فيمكنهم حتى صياغة بعض انتقالات الحالة وإرسالها إلى Ethereum.

** مستخدم الشر: **

يستمر المستخدمون في إنفاق الرموز المميزة على Polygon بعد بدء معاملة خروج ، على غرار الإنفاق المزدوج عبر السلسلة.

باختصار ، تستخدم خوارزمية Plasma MoreVp من Polygon خوارزمية أخرى لحساب أولوية الخروج ، وهي الخروج من أحدث معاملة. نظرا لأن هذه الطريقة تستخدم حدث LogTransfer مشابها ل UTXO، طالما أن المعاملة المشروعة للمستخدم تستخدم الإدخال الصحيح1 والإدخال2، حتى إذا تم حزم بعض المعاملات الضارة قبل معاملة المستخدم، يمكن معالجة معاملة المستخدم بشكل صحيح لأن معاملة المستخدم تأتي فقط من إدخال صالح. الكود الكاذب ذي الصلة هو كما يلي:

الإيداع

لنأخذ مثال المستخدم أليس باستخدام Plasma Bridge لإرسال أصول رمزية من حساب Ethereum الخاص بها إلى حساب Polygon الخاص بها:

1. بادئ ذي بدء ، يحتاج المستخدمون أيضا إلى تفويض الأصول الرمزية التي يحتاجون إلى نقلها إلى مدير الإيداع لعقد Polygon على السلسلة الرئيسية (Ethereum) من خلال وظيفة approtect .

2. بعد تأكيد المعاملة المصرح بها ، يستدعي المستخدم وظيفة erc20token.deposit() لتشغيل وظيفة depositERC20ForUser() لعقد depositManager وإيداع أصول الرمز المميز ERC20 الخاصة بالمستخدم.

3. عندما تؤكد شبكة Ethereum الرئيسية معاملة الإيداع ، ستقوم بإنشاء كتلة تحتوي على هذه المعاملة فقط ، وإرسالها إلى عقد childChain على شبكة Polygon باستخدام آلية مزامنة الحالة ، وسك نفس الكمية من العملات المعدنية المعينة وإيداعها في حساب المستخدم على Polygon.

ملاحظة: وفقا لتحليل الكود المصدري لعقد childChain ، تدعم البلازما ثلاثة أنواع فقط ، بما في ذلك: ETH و ERC20 و ERC721.

سحب

عندما يريد المستخدم استخدام جسر البلازما لسحب الأصول من Polygon إلى Ethereum ، فسوف يمر بالخطوات التالية:

1. يقوم المستخدم بنسخ أصول الرمز المميز المعينة على سلسلة Polygon عن طريق استدعاء وظيفة السحب () للعملة المعينة على Polygon:

يمكنك أيضا استدعاء تطبيق واجهة withdrawStart () لعميل البلازما على مضلع.

2. يمكن للمستخدم استدعاء وظيفة startExitWithBurntTokens() في عقد ERC20Predicate ، والتي ستستدعي أولا WithdrawManager.verifyInclusion() للتحقق مما إذا كانت نقطة التفتيش تحتوي على معاملة السحب والإيصال المقابل ، يكون الرمز كما يلي:

بعد اجتياز التحقق ، سيتم استدعاء WithdrawManager.addExitToQueue() لإدراجه في قائمة انتظار الرسائل بترتيب الأولوية:

أخيرا ، يستدعي addExitToQueue() _addExitToQueue() لسك NFT كقسيمة استرداد:

3. ينتظر المستخدم فترة تحدي مدتها 7 أيام

4. بعد اكتمال فترة التحدي ، يمكنك استدعاء وظيفة WithdrawManager.processExits() لإرسال الرموز المميزة إلى المستخدم.

تنقسم الوظيفة إلى خطوتين: أولا ، تأكد مما إذا كانت معاملة السحب في قائمة انتظار الرسائل قد اجتازت فترة التحدي البالغة 7 أيام ، وإذا مرت فترة التحدي ، فقم بإزالة المعاملة من قائمة الانتظار:

بعد ذلك ، حدد ما إذا كان قد تم حذف قسيمة استرداد NFT خلال فترة التحدي ، وإذا لم يكن الأمر كذلك ، إتلاف NFT وسيتم إرجاع الأصول المقابلة إلى المستخدم:

5_Polygon ثغرة الإنفاق المزدوج لجسر البلازما

في 5 أكتوبر 2021 ، قدم White Hat Gerhard Wagner ثغرة Polygon يمكن أن تؤدي إلى هجوم إنفاق مزدوج يتضمن 850 مليون دولار ، حيث تلقت White Hat مكافأة رسمية بقيمة 2,000,000 دولار من Polygon.

في مقدمة جسر البلازما أعلاه ، نعلم أن عملية سحب المعاملة الكاملة هي كما يلي:

- يبدأ المستخدم معاملة سحب على Polygon ، والتي تحرق الرموز المميزة للمستخدم على Polygon ؛

- بعد فاصل زمني لنقطة التفتيش (حوالي 30 دقيقة) ، انتظر حتى يتم تضمين معاملة السحب في نقطة التفتيش ؛

- يقوم أكثر من 2/3 من المدققين بالتوقيع عليه وإرساله إلى Ethereum ، وعند هذه النقطة يستدعي المستخدم startExitWithBurntTokens() في عقد ERC20PredicateBurnOnly للتحقق مما إذا كانت نقطة التفتيش تحتوي على معاملات حرق ؛

- إذا تم اجتياز التحقق ، سك قسيمة استرداد NFT وإرسالها إلى المستخدم

- ينتظر المستخدمون فترة تحدي مدتها 7 أيام

- استدعاء WithdrawalManager.processExits() لتدمير NFT واسترداد المستخدم

ملاحظة: من أجل منع إعادة تشغيل المعاملة (هجمات الإنفاق المزدوج) ، يستخدم Polygon NFTs كدليل على استرداد الأموال لتحديد معاملة السحب بشكل فريد. ومع ذلك ، نظرا لعيب إنشاء معرف NFT ، يمكن للمهاجمين إنشاء معلمات لإنشاء NFTs متعددة بمعرفات مختلفة باستخدام نفس معاملة السحب الصالحة ، ثم استخدام NFTs هذه لمعاملات استرداد الأموال ، وبالتالي تحقيق “هجوم الإنفاق المزدوج”.

فيما يلي نظرة فاحصة على كيفية إنشاء NFTs:

1. من تحليل الكود المصدري أعلاه ، يمكن ملاحظة أن addExitToQueue() سيستدعي _addExitToQueue() لسك NFT:

وفقا لتحليل المعلمة ، exitid = priority ، ثم يتم إنشاء معرف NFT بواسطة التحول الأيسر لأولوية العمر في Plasma Bridge.

2. كما يتضح من تحليل شفرة المصدر أعلاه ، فإن العمر هو قيمة إرجاع وظيفة WithdrawManager.verifyInclusion() ، والتي ستتحقق أولا من صحة معاملة السحب ، ثم تنشئ العمر المقابل إذا تم اجتياز التحقق. في منطق التحقق من الصحة، القيمة التي تم فك تشفيرها بواسطة بيانات المعلمة التي يمكن التحكم فيها هي branchMaskBytes:

تستخدم هذه القيمة أيضا عند توليد العمر:

3. تتبع الدالة MerklePatriciaProof.verify() المسماة في منطق التحقق من المعاملات ، وتجد أن الدالة تستدعي _getNibbleArray() لتحويل الفرعMaskBytes:

4. استمر في تتبع وظيفة فك التشفير ، التي تتجاهل جزءا من القيمة عند تحويل ترميز branchMaskBytes ، وهذه الطريقة لفقدان القيمة ستؤدي إلى تحويل قيم مختلفة للحصول على نفس القيمة التي تم فك تشفيرها. على وجه التحديد ، إذا كان البت السداسي العشري الأول (نصف بايت) من القيمة المشفرة hp الواردة b هو 1 أو 3 ، يتم تحليل البت السداسي عشري الثاني. خلاف ذلك ، يتم تجاهل البايت الأول ببساطة.

إذا قام أحد المهاجمين بإنشاء معلمة branchMaskBytes بحيث لا يساوي البت السداسي العشري الأول 1 و 3 ، فهناك 14 \ * 16 = 224 طريقة للحصول على نفس القيمة المحولة.

عملية الهجوم المحددة هي كما يلي:

- إيداع كمية كبيرة من ETH / الرموز إلى Polygon عبر Polygon Plasma

- ابدأ صفقة سحب على Polygon وانتظر فترة تحدي مدتها 7 أيام

- قم بتعديل البايت الأول من معلمة branchMaskBytes في معاملة السحب (يمكن إعادة إرسال نفس المعاملة الصالحة حتى 223 مرة) وبدء معاملة السحب بشكل متكرر

باختصار ، ترجع هذه الثغرة الأمنية بشكل أساسي إلى مشكلة في تصميم خوارزمية المعرف ل NFT التي تنشئ قسيمة استرداد لمنع إعادة التشغيل ، مما يؤدي إلى نفس معاملة الاسترداد يمكن أن تولد NFTs مختلفة ، مما يؤدي إلى هجوم الإنفاق المزدوج. اتضح أن البايت الأول من قناع الفرع المشفر يجب أن يكون دائما 0x00. الإصلاح هو التحقق مما إذا كان البايت الأول من قناع الفرع المشفر 0x00 ولا تعامله على أنه قناع غير صحيح.

حسنا ، انتهت مشاركة اليوم ، في العدد التالي ، سيقدم فريق أبحاث أمان سلسلة تشنغدو البحث الأمني لمشروع آخر عبر السلسلة ، يرجى التطلع إليه.