چرا Solana پر از Prop AMM است اما در EVM جای خالی آن حس می‌شود؟

عنوان اصلی مقاله: dAppهایی که پس از راه‌اندازی شبکه اصلی Monad باید زیر نظر داشت

نویسنده اصلی: @0xOptimus

ترجمه مقاله: Dingdang, Odaily Planet Daily

بازارگردان‌های خودکار اختصاصی (Prop AMM) به سرعت ۴۰٪ از کل حجم معاملات Solana را به خود اختصاص داده‌اند. چرا هنوز شاهد حضور آن‌ها در EVM نیستیم؟

بازارگردان‌های خودکار اختصاصی (Prop AMM) به سرعت در حال تبدیل شدن به نیروی غالب در اکوسیستم دیفای Solana هستند و در حال حاضر بیش از ۴۰٪ از حجم معاملات در جفت‌ارزهای اصلی را تأمین می‌کنند. این بسترهای نقدینگی که توسط بازارگردان‌های حرفه‌ای اداره می‌شوند، می‌توانند نقدینگی عمیق و قیمت‌گذاری رقابتی‌تری ارائه دهند. دلیل اصلی این امر آن است که آن‌ها ریسک سوءاستفاده از «قیمت‌های قدیمی» (stale quotes) برای انجام آربیتراژ پیش‌دستانه (front-running) را به شدت کاهش می‌دهند.

منبع تصویر: dune.com

با این حال، موفقیت آن‌ها تقریباً به طور کامل محدود به Solana بوده است. حتی در شبکه‌های لایه ۲ سریع و کم‌هزینه مانند Base یا Optimism، حضور Prop AMM در اکوسیستم EVM نادر است. چرا آن‌ها در EVM ریشه ندوانده‌اند؟

این مقاله عمدتاً به سه موضوع می‌پردازد: Prop AMM چیست، موانع فنی و اقتصادی آن‌ها در زنجیره EVM، و معماری‌های جدید و امیدوارکننده‌ای که ممکن است در نهایت آن‌ها را به خط مقدم دیفای در EVM بیاورد.

Prop AMM چیست؟

Prop AMM نوعی بازارگردان خودکار است که در آن یک بازارگردان حرفه‌ای به جای تأمین غیرفعال وجوه توسط عموم (مانند AMMهای سنتی)، به طور فعال نقدینگی و قیمت‌گذاری را مدیریت می‌کند.

AMMهای سنتی (مانند Uniswap v2) معمولاً از فرمول x * y = k برای تعیین قیمت استفاده می‌کنند، که در آن x و y نشان‌دهنده مقادیر دو دارایی در استخر و k یک مقدار ثابت است. در Prop AMM، فرمول قیمت‌گذاری ثابت نیست و به طور مکرر (اغلب چندین بار در ثانیه) به‌روزرسانی می‌شود. از آنجایی که مکانیسم‌های داخلی اکثر Prop AMMها به عنوان یک «جعبه سیاه» در نظر گرفته می‌شوند، دنیای خارج از الگوریتم دقیق آن‌ها اطلاعی ندارد. با این حال، کد قرارداد هوشمند Prop AMM در زنجیره Sui از Obric عمومی است (به لطف کشف @markoggwp)، که در آن مقدار ثابت k به متغیرهای داخلی mult_x، mult_y و concentration بستگی دارد. تصویر زیر نشان می‌دهد که چگونه بازارگردان به طور مداوم این متغیرها را به‌روز می‌کند.

یک نکته که نیاز به شفاف‌سازی دارد این است که فرمول سمت چپ منحنی قیمت‌گذاری Obric پیچیده‌تر از یک x*y ساده است. با این حال، کلید درک Prop AMM این است که همیشه برابر با یک مقدار ثابت متغیر k است و تأمین‌کنندگان نقدینگی به طور مداوم این k را به‌روز می‌کنند تا منحنی قیمت را تنظیم کنند.

مرور: AMM چگونه قیمت‌ها را تعیین می‌کند؟

در این مقاله، ما چندین بار به مفهوم «منحنی قیمت» اشاره خواهیم کرد. منحنی قیمت تعیین می‌کند که کاربران هنگام معامله با استفاده از AMM چه قیمتی باید بپردازند و بخشی است که تأمین‌کنندگان نقدینگی به طور مداوم در Prop AMM به‌روز می‌کنند. برای درک بهتر این موضوع، می‌توانیم ابتدا مکانیسم قیمت‌گذاری یک AMM سنتی را مرور کنیم.

با مثال استخر WETH-USDC در Uniswap v2 (با فرض عدم وجود کارمزد). قیمت به طور غیرفعال توسط فرمول x * y = k تعیین می‌شود. با فرض وجود ۱۰۰ WETH و ۴۰۰,۰۰۰ USDC در استخر، نقطه فعلی منحنی x = 100 و y = 400,000 است که مربوط به قیمت اولیه ۴۰۰,۰۰۰ / ۱۰۰ = ۴,۰۰۰ USDC/WETH است. این یک مقدار ثابت k = 100 * 400,000 = 40,000,000 می‌دهد.

اگر معامله‌گری بخواهد ۱ WETH بخرد، باید USDC به استخر اضافه کند و WETH موجود در استخر را به ۹۹ کاهش دهد. برای حفظ مقدار ثابت k، نقطه جدید (x, y) همچنان باید روی منحنی باشد، بنابراین y باید ۴۰,۰۰۰,۰۰۰ / ۹۹ ≈ ۴۰۴,۰۴۰.۴۰ شود. این بدان معناست که معامله‌گر حدود ۴,۰۴۰.۴۰ USDC برای ۱ WETH پرداخت کرده است که کمی بالاتر از قیمت اولیه است. این پدیده به عنوان «لغزش قیمت» (price slippage) شناخته می‌شود. به همین دلیل است که x*y=k یک «منحنی قیمت» نامیده می‌شود: هر قیمت قابل معامله‌ای باید روی این منحنی قرار گیرد.

چرا تأمین‌کنندگان نقدینگی طراحی AMM را به دفتر سفارشات متمرکز (CLOB) ترجیح می‌دهند؟

بیایید توضیح دهیم که چرا تأمین‌کنندگان نقدینگی می‌خواهند از طراحی AMM برای تأمین نقدینگی استفاده کنند. تصور کنید شما یک بازارگردان هستید که در یک دفتر سفارشات محدود (CLOB) درون‌زنجیره‌ای قیمت‌گذاری می‌کنید. اگر بخواهید قیمت خود را به‌روز کنید، باید هزاران سفارش محدود را لغو و جایگزین کنید. اگر N سفارش داشته باشید، هزینه به‌روزرسانی یک عملیات O(N) است که در زنجیره کند و گران است.

اما اگر بتوانید تمام قیمت‌ها را با یک منحنی ریاضی نشان دهید چه؟ با به‌روزرسانی ساده چند پارامتر کلیدی که این منحنی را تعریف می‌کنند، می‌توانید یک عملیات O(N) را به یک پیچیدگی ثابت O(1) تبدیل کنید.

برای نمایش بصری اینکه چگونه «منحنی قیمت» با محدوده‌های قیمتی مؤثر مختلف مطابقت دارد، می‌توانیم به SolFi ایجاد شده توسط Ellipsis Labs اشاره کنیم—یک Prop AMM مبتنی بر Solana. اگرچه منحنی قیمت خاص آن ناشناخته و پنهان است، Ghostlabs نموداری ایجاد کرده است که قیمت مؤثر هنگام مبادله مقادیر مختلف SOL با USDC در یک اسلات Solana (دوره زمانی بلاک) را نشان می‌دهد. هر خط نشان‌دهنده یک استخر WSOL/USDC متفاوت است که نشان می‌دهد چندین سطح قیمت می‌توانند همزیستی داشته باشند. همانطور که تأمین‌کننده نقدینگی منحنی قیمت را به‌روز می‌کند، این نمودار قیمت مؤثر نیز بین اسلات‌های مختلف تغییر خواهد کرد.

منبع تصویر: GitHub

نکته کلیدی در اینجا این است که با به‌روزرسانی تنها چند پارامتر منحنی قیمت، تأمین‌کنندگان نقدینگی می‌توانند توزیع قیمت مؤثر را در هر زمان به صورت پویا تغییر دهند بدون اینکه مجبور باشند هر یک از N سفارش را به صورت جداگانه اصلاح کنند. این دقیقاً ارزش پیشنهادی اصلی Prop AMM است—این به تأمین‌کنندگان نقدینگی اجازه می‌دهد تا نقدینگی پویا و عمیق را با کارایی سرمایه و محاسباتی بالاتر ارائه دهند.

چرا معماری Solana برای Prop AMM ایده‌آل است؟

Prop AMM یک سیستم «مدیریت فعال» است، به این معنی که به دو شرط کلیدی نیاز دارد:

۱. هزینه‌های به‌روزرسانی پایین

۲. اجرای اولویت‌دار

در Solana، این دو جنبه با هم درهم تنیده‌اند: به‌روزرسانی‌های کم‌هزینه اغلب به این معنی است که به‌روزرسانی‌ها می‌توانند اجرای اولویت‌دار داشته باشند.

اما چرا تأمین‌کنندگان نقدینگی به این دو نکته نیاز دارند؟ اول، آن‌ها به طور مداوم منحنی قیمت را بر اساس تغییرات موجودی یا نوسانات قیمت شاخص دارایی (مثلاً قیمت‌های صرافی‌های متمرکز) با سرعت بلاک‌چین به‌روز می‌کنند. در یک زنجیره با فرکانس بالا مانند Solana، اگر هزینه‌های به‌روزرسانی خیلی بالا باشد، دستیابی به تنظیمات با فرکانس بالا چالش‌برانگیز خواهد بود.

ثانیاً، اگر یک تأمین‌کننده نقدینگی نتواند به‌روزرسانی خود را در بالای یک بلاک قرار دهد، قیمت قدیمی او توسط آربیتراژورها «پیش‌دستی» (front-run) می‌شود که منجر به ضرر اجتناب‌ناپذیر می‌شود. بدون این دو ویژگی، تأمین‌کنندگان نقدینگی نمی‌توانند به طور کارآمد عمل کنند و کاربران قیمت‌های معاملاتی بدتری دریافت خواهند کرد.

با استفاده از مثال Prop AMM HumidiFi در Solana، طبق داده‌های @SliceAnalytics، تأمین‌کننده نقدینگی قیمت خود را تا ۷۴ بار در ثانیه به‌روز می‌کند.

بازیکنانی که از EVM می‌آیند ممکن است بپرسند: «اسلات Solana تقریباً ۴۰۰ میلی‌ثانیه است، چگونه Prop AMM می‌تواند قیمت را چندین بار در یک اسلات به‌روز کند؟»

پاسخ در معماری پیوسته Solana نهفته است که اساساً با مدل بلاک گسسته EVM متفاوت است.

· EVM: تراکنش‌ها معمولاً پس از پیشنهاد و تأیید نهایی یک بلاک کامل، به صورت متوالی اجرا می‌شوند. این بدان معناست که به‌روزرسانی‌های ارسال شده در میانه راه، در بلاک بعدی اعمال می‌شوند.

· Solana: گره‌های اعتبارسنج پیشرو منتظر یک بلاک کامل نمی‌مانند؛ در عوض، تراکنش‌ها را به بسته‌های داده کوچک (به نام «shreds») تقسیم کرده و به طور مداوم آن‌ها را در شبکه پخش می‌کنند. در یک اسلات، ممکن است چندین مبادله وجود داشته باشد، اما به‌روزرسانی قیمت در shred #1 بر swap #1 تأثیر می‌گذارد و به‌روزرسانی قیمت در shred #2 بر swap #2 تأثیر می‌گذارد.

توجه: Flashblocks مشابه shreds در Solana هستند. طبق گفته @Ashwinningg از Anza Labs در کنفرانس CBER، محدودیت ۳۲,۰۰۰ shred در هر ۴۰۰ میلی‌ثانیه در اسلات، معادل ۸۰ shred در هر میلی‌ثانیه است. اینکه آیا Flashblocksهای ۲۰۰ میلی‌ثانیه‌ای برای برآورده کردن نیازهای تأمین‌کننده نقدینگی در مقایسه با معماری پیوسته Solana به اندازه کافی سریع هستند یا خیر، یک سوال باز باقی می‌ماند.

پس چرا به‌روزرسانی‌ها در Solana بسیار ارزان هستند؟ و چه چیزی منجر به اجرای اولویت‌دار آن‌ها می‌شود؟

اولاً، اگرچه پیاده‌سازی Prop AMM در Solana یک جعبه سیاه است، کتابخانه‌ای مانند Pinocchio وجود دارد که نحوه نوشتن CUها در برنامه‌های Solana را بهینه می‌کند. وبلاگ Helius توضیح فوق‌العاده‌ای ارائه می‌دهد. با این کتابخانه، مصرف CU برنامه‌های Solana می‌تواند از حدود ۴۰۰۰ CU به تقریباً ۱۰۰ CU کاهش یابد.

منبع تصویر: github

حالا بیایید به بخش دوم نگاه کنیم. در سطح بالاتر، Solana تراکنش‌ها را با انتخاب آن‌هایی که بالاترین نسبت کارمزد / واحدهای محاسباتی (CU) را دارند (واحدهای محاسباتی مشابه Gas در EVM هستند)، مشابه EVM اولویت‌بندی می‌کند.

· به طور خاص، اگر از Jito استفاده شود، فرمول Jito Tip / Compute Units است

· در غیر این صورت: اولویت = (Tip + Base Fee) / (1 + CU Limit + Signature CU + Write Lock CU)

با مقایسه واحدهای محاسباتی یک به‌روزرسانی Prop AMM با Jupiter Swap، مشخص است که به‌روزرسانی بسیار ارزان است، با نسبت ۱:۱۰۰۰.

به‌روزرسانی Prop AMM: به‌روزرسانی ساده منحنی بسیار ارزان است. به‌روزرسانی Wintermute به اندازه ۱۰۹ CU پایین است، با هزینه کل تنها ۰.۰۰۰۰۰۷۵۰۶ SOL

Jupiter Swap: یک مبادله از طریق مسیر Jupiter می‌تواند به ~۱۰۰,۰۰۰ CU برسد، با هزینه کل ۰.۰۰۰۰۰۵ SOL

به دلیل این تفاوت قابل توجه، تأمین‌کنندگان نقدینگی فقط باید کارمزد حداقلی برای تراکنش‌های به‌روزرسانی بپردازند و به نسبت کارمزد/CU بسیار بالاتری نسبت به صرافی‌ها دست یابند، که تضمین می‌کند به‌روزرسانی‌ها در بالای بلاک اجرا می‌شوند و از خود در برابر حملات آربیتراژ محافظت می‌کنند.

چرا Prop AMM هنوز در EVM پیاده‌سازی نشده است؟

با فرض اینکه یک به‌روزرسانی Prop AMM شامل نوشتن در متغیری است که منحنی قیمت جفت دارایی را تعیین می‌کند. اگرچه کد Prop AMM در Solana یک «جعبه سیاه» است، با تأمین‌کنندگان نقدینگی که می‌خواهند استراتژی‌های خود را محرمانه نگه دارند، می‌توانیم از این فرض استفاده کنیم تا بفهمیم Obric چگونه Prop AMM را در Sui پیاده‌سازی کرده است: متغیر تعیین‌کننده قیمت جفت دارایی از طریق یک تابع به‌روزرسانی در قرارداد هوشمند نوشته می‌شود.

با تشکر از @markoggwp برای این کشف!

با این فرض، ما مانع قابل توجهی در معماری EVM یافتیم که مدل Prop AMM در Solana را در EVM غیرممکن می‌کند.

به یاد داشته باشید که در بلاک‌چین‌های لایه ۲ OP-Stack (مانند Base و Unichain)، تراکنش‌ها بر اساس کارمزد به ازای Gas (مشابه مرتب‌سازی Fee/CU در Solana) اولویت‌بندی می‌شوند.

در EVM، هزینه Gas عملیات نوشتن بسیار بالا است. در مقایسه با به‌روزرسانی‌های Solana، هزینه نوشتن یک مقدار در EVM از طریق opcode SSTORE حیرت‌انگیز است:

· SSTORE (0 → non-0): ~۲۲,۱۰۰ gas

· SSTORE (non-0 → non-0): ~۵,۰۰۰ gas

· مبادله AMM معمولی: ~۲۰۰,۰۰۰–۳۰۰,۰۰۰ gas

توجه: Gas در EVM مشابه واحدهای محاسباتی (CUs) در Solana است. اعداد Gas مربوط به SSTORE در بالا فرض می‌کنند که هر تراکنش فقط یک نوشتن (cold write) دارد، که منطقی است زیرا چندین به‌روزرسانی معمولاً در یک تراکنش ارسال نمی‌شوند.

در حالی که به‌روزرسانی‌ها هنوز ارزان‌تر از مبادلات هستند، کارایی Gas تنها حدود ۱۰ برابر است (به‌روزرسانی‌ها ممکن است شامل چندین SSTORE باشند)، در حالی که در Solana، این نسبت حدود ۱۰۰۰ برابر است.

این منجر به دو نتیجه‌گیری می‌شود که مدل Prop AMM مشابه Solana را در EVM پرخطرتر می‌کند:

۱. هزینه‌های بالای Gas، تضمین اولویت به‌روزرسانی را دشوار می‌کند: کارمزدهای Gas پایین‌تر نمی‌توانند نسبت کارمزد/Gas بالایی را تضمین کنند. برای اطمینان از اینکه به‌روزرسانی‌ها پیش‌دستی نمی‌شوند و در بالای یک بلاک قرار می‌گیرند، به کارمزدهای Gas بالاتری نیاز است که هزینه‌ها را افزایش می‌دهد.

۲. ریسک آربیتراژ بالاتر در EVM: نسبت Gas به‌روزرسانی به Gas مبادله در EVM تنها ۱:۱۰ است، در حالی که در Solana، ۱:۱۰۰۰ است. این بدان معناست که آربیتراژورها فقط باید کارمزدها را ۱۰ برابر افزایش دهند تا به‌روزرسانی یک تأمین‌کننده نقدینگی را پیش‌دستی کنند، در مقایسه با ۱۰۰۰ برابر در Solana. در این سناریوی نسبت پایین‌تر، آربیتراژورها به دلیل هزینه پایین، احتمال بیشتری دارد که به‌روزرسانی‌های قیمت را پیش‌دستی کنند تا قیمت‌های قدیمی را شکار کنند.

برخی نوآوری‌ها (مانند TSTORE در EIP-1153 برای ذخیره‌سازی موقت) هزینه نوشتن حدود ۱۰۰ gas را ارائه می‌دهند، اما این ذخیره‌سازی زودگذر است، فقط در یک تراکنش معتبر است و نمی‌توان از آن برای حفظ به‌روزرسانی‌های قیمت برای استفاده بعدی در معاملات مشتقه (مثلاً در کل دوره بلاک) استفاده کرد.

چگونه Prop AMM را به EVM معرفی کنیم؟

قبل از پاسخ، بیایید به «چرا این کار را انجام دهیم» بپردازیم: کاربران همیشه قیمت‌های معاملاتی بهتری می‌خواهند، به این معنی که ارزش بیشتری برای پول خود دریافت کنند. Prop AMM در اتریوم و لایه ۲ می‌تواند قیمت‌های رقابتی را به کاربران ارائه دهد که قبلاً فقط در Solana یا صرافی‌های متمرکز در دسترس بود.

برای امکان‌پذیر کردن Prop AMM در EVM، بیایید یکی از دلایل موفقیت آن در Solana را مرور کنیم:

· محافظت از به‌روزرسانی در بالای بلاک: در Solana، به‌روزرسانی‌های Prop AMM در بالای بلاک قرار می‌گیرند تا تأمین‌کنندگان نقدینگی را از پیش‌دستی محافظت کنند. به‌روزرسانی‌های بالا امکان‌پذیر هستند زیرا هزینه واحد محاسباتی حداقل است و به کارمزدهای پایین اجازه می‌دهد تا نسبت کارمزد/CU بالایی را به دست آورند، به ویژه در مقایسه با معاملات مشتقه.

بنابراین، چگونه می‌توانیم به‌روزرسانی‌های Prop AMM در بالای بلاک را به یک بلاک‌چین لایه ۲ EVM معرفی کنیم؟ دو رویکرد وجود دارد: یا هزینه نوشتن را کاهش دهید یا یک کانال اولویت برای به‌روزرسانی‌های Prop AMM ایجاد کنید.

به دلیل مسئله رشد وضعیت EVM، رویکرد کاهش هزینه نوشتن کمتر قابل اجرا است، زیرا SSTOREهای ارزان منجر به حملات تورم وضعیت می‌شوند.

ما ایجاد یک کانال اولویت برای به‌روزرسانی‌های Prop AMM را پیشنهاد می‌کنیم. این یک راه‌حل قابل اجرا و تمرکز این مقاله است.

@MarkToda از Uniswap رویکرد جدیدی را پیشنهاد کرده است که از قرارداد هوشمند ذخیره‌سازی جهانی + استراتژی سازنده بلاک اختصاصی استفاده می‌کند:

نحوه کار آن به این صورت است:

· قرارداد ذخیره‌سازی جهانی: یک قرارداد هوشمند ساده را به عنوان یک فروشگاه کلید-مقدار عمومی مستقر کنید. تأمین‌کنندگان نقدینگی پارامترهای منحنی قیمت را در این قرارداد می‌نویسند (مثلاً set(ETH-USDC_CONCENTRATION, 4000)).

· استراتژی سازنده: این یک مؤلفه کلیدی خارج از زنجیره است. سازنده بلاک تراکنش‌های ارسال شده به قرارداد ذخیره‌سازی جهانی را شناسایی می‌کند، ۵–۱۰٪ از Gas بلاک را به این تراکنش‌های به‌روزرسانی اختصاص می‌دهد، آن‌ها را بر اساس کارمزد اولویت‌بندی می‌کند و آن‌ها را مرتب می‌کند تا از تراکنش‌های اسپم جلوگیری شود.

لطفاً توجه داشته باشید: تراکنش‌ها باید مستقیماً به آدرس ذخیره‌سازی جهانی ارسال شوند تا قرارگیری در بالای بلاک تضمین شود.

نمونه‌های الگوریتم ساخت بلاک سفارشی را می‌توان در rblib یافت.

یکپارچه‌سازی Prop AMM: قرارداد Prop AMM تأمین‌کنندگان نقدینگی، داده‌های منحنی قیمت را از قرارداد ذخیره‌سازی جهانی در طول مبادلات می‌خواند تا قیمت ارائه دهد.

این معماری به طرز ماهرانه‌ای دو مسئله را حل می‌کند:

۱. محافظت: استراتژی سازنده یک «مسیر سریع» ایجاد می‌کند تا اطمینان حاصل شود که تمام به‌روزرسانی‌های قیمت در بلاک قبل از تراکنش‌ها اجرا می‌شوند و ریسک پیش‌دستی را از بین می‌برد.

۲. کارایی هزینه: تأمین‌کنندگان نقدینگی دیگر برای کارمزدهای بالای Gas با تمام کاربران دیفای رقابت نمی‌کنند تا به بالای بلاک برسند؛ در عوض، آن‌ها فقط باید برای بالای بلاک رزرو شده برای تراکنش‌های به‌روزرسانی در بازار کارمزد محلی رقابت کنند که هزینه‌ها را به میزان قابل توجهی کاهش می‌دهد.

تراکنش‌های کاربر بر اساس منحنی قیمت تعیین‌شده توسط تأمین‌کننده نقدینگی در شروع همان بلاک اجرا می‌شوند که تازگی و امنیت قیمت‌ها را تضمین می‌کند. این مدل محیط به‌روزرسانی کم‌هزینه و با اولویت بالا در Solana را در EVM تکرار می‌کند و راه را برای Prop AMM در EVM هموار می‌کند.

با این حال، این مدل دارای برخی معایب نیز هست که من آن‌ها را در پایین این مقاله برای بحث باقی می‌گذارم.

نتیجه‌گیری

امکان‌پذیری Prop AMM به حل یک مسئله اقتصادی اصلی بستگی دارد: اجرای ارزان و اولویت‌دار برای جلوگیری از پیش‌دستی.

در حالی که معماری استاندارد EVM چنین عملیاتی را پرهزینه و پرخطر می‌کند، طراحی‌های جدید رویکردهای متفاوتی را برای حل این مشکل ارائه می‌دهند. با ترکیب قراردادهای هوشمند ذخیره‌سازی جهانی درون‌زنجیره‌ای و استراتژی سازنده خارج از زنجیره در طراحی جدید، می‌توان یک «مسیر سریع» اختصاصی ایجاد کرد تا اجرای به‌روزرسانی‌ها در بالای بلاک تضمین شود، در حالی که یک بازار کارمزد محلی و کنترل‌شده ایجاد می‌شود. این نه تنها Prop AMM را در EVM قابل اجرا می‌کند، بلکه ممکن است تمام دیفای EVM که به به‌روزرسانی‌های اوراکل در بالای بلاک متکی است را متحول کند.

سوالات باز

· آیا سرعت ۲۰۰ میلی‌ثانیه‌ای Flashblock در Prop AMM در EVM برای رقابت با معماری پیوسته Solana کافی است؟

· در Solana، بیشتر ترافیک AMM از یک تجمیع‌کننده واحد به نام Jupiter می‌آید که یک SDK برای یکپارچه‌سازی آسان AMM ارائه می‌دهد. با این حال، در لایه ۲ EVM، ترافیک در چندین تجمیع‌کننده بدون SDK عمومی پراکنده است. آیا این چالشی برای Prop AMM ایجاد می‌کند؟

· در Solana، به‌روزرسانی‌های Prop AMM تنها حدود ۱۰۰ CU مصرف می‌کنند. مکانیسم پیاده‌سازی پشت این کارایی چیست؟

· مدل مسیر سریع فقط به‌روزرسانی‌ها را در بالای یک بلاک تضمین می‌کند. اگر چندین مبادله در یک Flashblock وجود داشته باشد، تأمین‌کنندگان نقدینگی چگونه قیمت‌ها را بین این مبادلات به‌روز می‌کنند؟

· آیا می‌توان برنامه‌های EVM بهینه‌شده را با استفاده از زبان‌هایی مانند Yul یا Huff نوشت، مشابه رویکرد بهینه‌سازی Pinocchio در Solana؟

· Prop AMM در مقایسه با RFQ چگونه است؟

· چگونه می‌توانیم از ارائه قیمت‌های رقابتی توسط تأمین‌کنندگان نقدینگی در بلاک N برای جذب کاربران و سپس به‌روزرسانی به قیمت‌های غیررقابتی در بلاک N+1 جلوگیری کنیم؟ Jupiter چگونه این ریسک را کاهش می‌دهد؟

· ویژگی Ultra Signaling در Jupiter Ultra V3 به Prop AMM اجازه می‌دهد بین ترافیک مضر و خوش‌خیم تمایز قائل شود و قیمت‌های دقیق‌تری ارائه دهد. این ویژگی‌های تجمیع‌کننده برای Prop AMM در EVM چقدر حیاتی هستند؟

لینک پست اصلی