تجزیه و تحلیل جامع از اتریوم

  • 2021-04-19

An Analysis of Ethereum Front-Running and its Defense Solutions

$ GCR جامعه ای از محققان و سرمایه گذاران در فضای رمزنگاری است. امروز به جامعه ما بپیوندید تا به بهترین ایده های سرمایه گذاری و جریان معاملات ، کارگاه های آموزشی و دسترسی مستقیم به بنیانگذاران و بازیکنان کلیدی در فضا دسترسی پیدا کنید.

برای پیوستن به کانال های فقط اعضای Discord به 100 دلار GCR نیاز دارید. می توانید توکن را در Uniswap از اینجا خریداری کنید. از جامعه اختلاف نظر در اینجا احساس کنید.

این مقاله با هدف ارائه تجزیه و تحلیل جامع از حمله مشترک به blockchain اتریوم: جلو. ما ویژگی های آن را برای یافتن مؤثرترین راه حل و در نهایت به کاربران Degate کمک خواهیم کرد تا از این حمله جدی آسیب برساند.

جلو و مملو

به بیان ساده تر ، جلو حمله حمله ای است که در آن یک ربات یک معامله عادی را در حالی که منتظر بسته بندی با تعیین هزینه گاز بالاتر برای تکمیل معامله با نرخ ترجیحی قبل از انجام معامله حمله شده است ، پیش از بسته بندی می کند.

Mempool مجموعه ای از معاملات اتریوم است که به شبکه پخش شده و منتظر بسته بندی در بلوک ها هستند. این فرضیه اجرای جلوی آن است.

روبات جلویی ، اهداف را تجزیه و تحلیل می کند و اهداف را می توان با اسکن مداوم معاملات در Mempool مورد حمله قرار داد. تصویر زیر یک مرورگر Mempool را نشان می دهد که به شما امکان می دهد در معاملات در Mempool مشترک شوید و با تنظیم فیلترهای مختلف ، تمام جزئیات آن معاملات را مشاهده کنید.

در میان همه حملات مقدماتی ، معمولی ترین و خطرناک ترین "حملات ساندویچ" علیه معاملات AMM است. علاوه بر این ، حملات مقدماتی علیه داوری ، ترخیص معاملات ، وام های فلش و غیره نیز وجود دارد که از آسیب پذیری های سیستم برای سود بهره برداری می کنند. تعداد زیادی از مهاجمان وجود دارند که توسط اسکریپت های خودکار کنترل می شوند. آنها در اصل اتوماتیک و غیرقابل توصیف هستند ، بنابراین هرگونه معامله سودآور در معرض حملات اشباع آنها قرار دارد و به ظاهر کمی برای فرار است.

بیایید نگاهی دقیق تر به حملات ساندویچ بیندازیم.

حملات ساندویچ

یک مورد حمله واقعی

بیایید با یک مورد حمله ساندویچ شروع کنیم.

در تصویر بالا ، سه معاملات در همان بلوک بسته بندی شده اند ، با یک معامله عادی بین دو معاملات حمله (که توسط هکرها مشخص شده است) ساندویچ شده است. روند خاص به شرح زیر است:

  1. کاربر برای اولین بار یک معامله عادی را آغاز کرد و DG را با 23،700. 705 USDC خریداری کرد و قیمت گاز را به 40. 5 GWEI تنظیم کرد.
  2. پس از تشخیص معامله پرسود ، BOT سپس با شروع معامله خرید و تعیین قیمت گاز در 49. 9 GWEI به کاربر حمله کرد. با موفقیت از معامله عادی کاربر تحت مکانیسم رقابت گاز پرش کرد.
  3. در همین زمان ، این ربات تجارت دیگری را با فروش دیگر آغاز کرد و قیمت گاز را دوباره 40. 5 GWEI تنظیم کرد که بلافاصله پس از تجارت عادی کاربر به دلیل ترتیب زمانی تکمیل شد.

با یک حمله کامل انجام شده ، این روبات پس از حسابداری هزینه ها ، 1،6448. 012-16،310. 3-15. 2-10. 61 = 111. 9 دلار درآمد کسب می کند. این حمله ، که در آن دو معاملات حمله با یک معامله عادی مخلوط می شوند ، به عنوان حمله ساندویچ شناخته می شود.

اصول اساسی در پشت حمله

برای درک بهتر اصل اصلی حمله ، اجازه دهید دانش پیش زمینه ای ارائه دهیم.

همانطور که می دانیم ، مبادلات غیر متمرکز جریان اصلی (DEX) مانند UNISWAP ، مکانیسم سازنده بازار (AMM) را اتخاذ می کند و قیمت آن از فرمول محصول ثابت پیروی می کند.

به عنوان مثال ، اگر یک استخر نقدینگی از یک نشانه و ETH در UNISWAP ایجاد شود ، با 1000 A و 100 ETH ، محصول این دو مقدار 100000 و قیمت فعلی A 0. 1 ETH است. هنگامی که آلیس سعی می کند از استخر با 10 ETH خریداری کند ، مقدار A ، با مشخص شده توسط X ، می تواند توسط فرمول زیر حاصل شود (توجه: برای ساده سازی ، هزینه معامله در زیر در نظر گرفته نمی شود):

؟ 1000-x؟*؟ 100+10؟ = 100000؟ x = 90. 9

در این معامله ، قیمت A 10/90. 9 = 0. 11 ETH است. در مقایسه با قیمت اصلی A ، کاهش قیمت:

یک معامله واحد باعث شده است که قیمت ارز 10 ٪ کاهش یابد. مشاهده می شود که برای استخرهای دارای نقدینگی کم ، یک اسلاید بزرگ در قیمت معاملات بزرگ وجود دارد. با این حال ، اگر می توانید قبل از یک معامله بزرگ عادی (که انتظار می رود باعث ایجاد لغزش بزرگ شود) بخرید ، و سپس A را که پس از معامله عادی خریداری کرده اید بفروشید ، می توانید از آن سود قابل توجهی کسب کنید. با استفاده از مثال از قبل ، فرض کنید باب 5 ETH را برای خرید قبل از معامله آلیس خرج می کند و پس از اتمام معامله آلیس ، A را به فروش می رساند. بیایید ببینیم چه اتفاقی خواهد افتاد.

اول ، تجارت پیشگیرانه باب:

(1000-X)*(100+5) = 100000 ، x = 47. 62

یعنی باب 47. 62 A را برای 5th خریداری می کند

بعدی معامله عادی آلیس خواهد بود. توجه کنید که تعداد A در استخر جریان 952. 38 و تعداد ETH 105 می شود:

(952. 38-X)*(105+10) = 100000 ، x = 82. 81

در نهایت، باب 47. 62 A می فروشد. در این زمان، تعداد A در تحرک 869. 57 و تعداد ETH 115 است:

? 869. 57+47. 62)*115-Y?= 100000? Y = 5. 97

با این حمله پیشرو، باب سود خالص 5. 97 - 5 = 0. 97 ETH را به دست می آورد، در حالی که آلیس ضرر خالص 90. 9-82. 81 = 8. 09 A را از دست می دهد. باب با ایجاد ضرر بیشتر آلیس به دست می آورد!

البته، حمله واقعی از پیش پیچیده‌تر است و برای دستیابی به دو هدف به محاسبات پیچیده‌تری نیاز دارد:

  • برای اینکه نتیجه معاملاتی کاربر تا حد امکان به حداکثر لغزش تنظیم شده توسط کاربر نزدیک شود، تا حداکثر فضای آربیتراژ نظری به دست آید.
  • بین رقابت در هزینه و درآمد تعادل برقرار کنید و سعی کنید تا حد امکان در مقابل ربات های دیگر پیروز شوید

بیایید این فرآیند را با نمودار زیر بهتر توصیف کنیم:

  1. کاربر در نقطه A، قصد دارد برای خرید ETH در_amount(user) USDT سرمایه‌گذاری کند، که معمولاً وضعیت فعلی را به B فشار می‌دهد و کاربر حداکثر لغزش را روی B (max_slippage) تنظیم می‌کند.
  2. ربات تراکنش را نظارت می کند و قبل از معامله کاربران، یک تراکنش خرید به مبلغ in_amount (ربات) USDT انجام می دهد و وضعیت فعلی را به A می رساند.
  3. سپس تراکنش کاربر اجرا می‌شود و به حداکثر لغزش B (MAX_SLIPPAGE) می‌رسد که توسط کاربر تعیین شده است.
  4. ربات ETH خریداری شده در مرحله 2 را می فروشد، به C می رسد و out_amount(ربات) USDT دریافت می کند.
  5. ربات out_amount (ربات) - in_amount (ربات) - هزینه دریافت می کند.

راه حل

اکنون که دیدیم پیشروی چقدر می تواند مرگبار باشد، پس برای جلوگیری از حمله پیشگیرانه چه کنیم؟

به عنوان یک کاربر عمومی، چندین راه برای مقابله با پیشروی وجود دارد:

  • برای تنظیم لغزش کم در معاملات، مانند 0. 1٪، که باعث می شود ربات پیشرو جایی برای کسب سود نداشته باشد. عیب: لغزش کم باعث می شود معاملات بزرگ شکست بخورند و همچنان کارمزدهای بالایی برای معاملات ناموفق دارد.
  • هزینه گاز را افزایش دهید که هزینه حمله ربات ها را افزایش می دهد. نقطه ضعف: این امر باعث افزایش هزینه های تراکنش نیز می شود.

مشاهده می شود که راه حل های فوق دارای اشکال هستند. خوشبختانه، بسیاری از تیم ها خطرات پیشروی را تشخیص می دهند و چندین راه حل سازنده ارائه کرده اند. اول از همه، با تجزیه و تحلیل کل فرآیند، می‌توان نتیجه گرفت که چندین عنصر برای پیاده‌سازی پیشروی مورد نیاز است:

  • عمومی بودن تراکنش: جزئیات معاملات را می توان در ممپول به دست آورد
  • مکانیسم اجرای تجارت اتریوم: از طریق رقابت گازی، تراکنش‌ها را از پیش تعیین کنید
  • مکانیسم منحنی تراکنش AMM: مکانیسم ثابت محصول می تواند نقاط لغزش بزرگی ایجاد کند

اقدامات متقابل به نوبه خود روی هر یک از این عناصر کار می کنند.

باز بودن

از آنجا که ربات ها معاملات را در Mempool تجزیه و تحلیل می کنند تا تصمیم بگیرند که حمله کنند ، آیا بهتر نیست اطلاعات معامله را رمزگذاری کنید تا ربات ها نتوانند آن را ببینند یا درک کنند؟

در جامعه پیشنهادهایی برای استفاده از ZK-SNARKS ، یک تکنیک ضد دانش صفر ، برای دستیابی به این هدف وجود دارد. به عبارت دیگر ، ZK-SNARKS برای رمزگذاری و پنهان کردن اطلاعات هر معامله استفاده می شود ، به طوری که ربات نمی تواند کاری در مورد آن انجام دهد.

با این حال ، این رویکرد در حال حاضر به اندازه کافی بالغ نیست و دارای اشکالاتی از قبیل هزینه های بالاتر گاز و این احتمال است که می توان از آن برای انجام حملات مسدود کننده استفاده کرد که منجر به کاهش اراده کلی می شود.

مکانیسم اجرای معامله اتریوم

مکانیسم فعلی اجرای معامله اتریوم از طریق رقابت گاز انجام می شود ، که در آن معدنچیان در اولویت تأیید معاملات کسانی که بالاترین صورتحساب گاز را پرداخت می کنند ، اولویت بندی می کنند. بنابراین اگر ما این مکانیسم را دور بزنیم و معاملات را مستقیماً برای بسته بندی به معدنچیان ارسال کنیم ، می توانیم احتمال حمله ربات جلویی در وسط فرآیند را از بین ببریم.

بنابراین ، یک راه حل شبیه به لایه 0 نیز برخی از برنامه ها ، مانند سرویس Taichi از Sparkpool را پیدا کرده است ، که در آن کاربر می تواند به طور مستقیم گره اتریوم Taichi را در Metamask تنظیم کند تا معامله به طور مستقیم بدون ظاهر در Mempool بسته بندی شود. اما نقطه ضعف این است که در مورد محدودیت زمانی بسته بندی ، عدم اطمینان وجود دارد.

علاوه بر این ، راه حلی شبیه به مفهوم Archerswap ، پلی بین معامله گران و معدنچیان ایجاد می کند ، جایی که معامله گران می توانند از معدنچیان بخواهند که معاملات خود را مستقیماً به صورت پاداش بسته بندی کنند ، که از احتمال ابتلا به جلو جلوگیری می کند. اگرچه برای جلوگیری از حمله ، هزینه حمایت از هزینه را پرداخت می کند ، اما هزینه های معامله گر را کاهش می دهد و این مزیت را دارد که هزینه ای برای معاملات ناموفق دریافت نمی کند.

بهینه سازی الگوریتم AMM

براساس مکانیسم AMM ، معاملات بزرگ باعث کاهش قیمت بیش از حد (که می توان آن را به عنوان یک قیمت اشتباه موقتی درک کرد) ، حاشیه سود برای حملات مقدماتی است. اگر مکانیسم AMM وجود داشته باشد که می تواند تأثیر معاملات بزرگ را بر قیمت معاملات بعدی کاهش دهد ، می تواند به طور موثری از حملات جلو جلوگیری کند.

در سال 2018 ، ویتالیک راه حلی را در جامعه تحقیقاتی اتریوم ارائه داد که وقتی معامله مبادله ای رخ می دهد ، قیمت استخر بلافاصله با قیمت واقعی تنظیم نمی شود ، بلکه در عوض به آرامی طی چند دقیقه به سمت قیمت واقعی حرکت می کند. به نظر می رسد که استخر نقدینگی زیادی را از هوای نازک به دست آورده است ، از این رو ما این تکنیک را "تعادل مجازی" می نامیم. این مکانیسم جدید می تواند سود داوران را تا حد زیادی کاهش دهد ، به طور موثری در برابر حملات مقدماتی دفاع می کند و در عین حال بازده سازندگان بازار تحرک را افزایش می دهد. می توان گفت که 1 اینچ Mooniswap نسخه اجرای این طرح است.

افزایش تحرک

همچنین ایده ای برای به حداکثر رساندن نقدینگی دامنه قیمت خاص در یک استخر معاملاتی وجود دارد. هرچه نقدینگی بیشتر باشد ، لغزش کوچکتر خواهد بود و وقتی تحرک به یک نقطه خاص برسد. رباتها سودآوری خود را از دست می دهند ، و ماهیت نقدینگی نسخه V3 Uniswap تلاش برای انجام این کار است.

چشم انداز آینده

ما هر دلیلی داریم که اعتقاد داشته باشیم که با تلاش مداوم تیم های ما ، به زودی قادر خواهیم بود یک محیط تجارت عادلانه تر و ایمن تر برای کاربران خود فراهم کنیم ، زیرا راه حل های مختلف همچنان در حال تکامل و فناوری هایی مانند نسل بعدی AMM است. و اتریوم لایه 2 یکی پس از دیگری اجرا می شود.

  • نویسنده : آقای جبرئیل شمس الدين
  • منبع : mafaldamillies.space
  • بدون دیدگاه

ثبت دیدگاه

مجموع دیدگاهها : 0در انتظار بررسی : 0انتشار یافته : ۰
قوانین ارسال دیدگاه
  • دیدگاه های ارسال شده توسط شما، پس از تایید توسط تیم مدیریت در وب منتشر خواهد شد.
  • پیام هایی که حاوی تهمت یا افترا باشد منتشر نخواهد شد.
  • پیام هایی که به غیر از زبان فارسی یا غیر مرتبط باشد منتشر نخواهد شد.