آموزش معماری Uniswap V2؛ آشنایی کامل با ساختار و عملکرد این پروتکل دیفای

0 دیدگاه

Uniswap یک اپلیکیشن دیفای (DeFi) است. این اپلیکیشن به معامله گران امکان می دهد بدون واسطه، یک توکن را با توکن دیگری مبادله کنند. معماری Uniswap V2 این فرآیند را به شکلی کاملا خودکار و کارآمد مدیریت می کند. Uniswap یکی از اولین نمونه های بازارسازهای خودکار (AMM) در حوزه معاملات است، هرچند نخستین نمونه به حساب نمی آید.

بازارسازهای خودکار جایگزینی برای دفتر سفارشات (Order Book) هستند. فرض می شود خواننده با دفتر سفارشات آشنایی دارد.

عملکرد AMM ها چگونه است؟

یک بازارساز خودکار درون یک استخر (Pool) که یک قرارداد هوشمند است، دو نوع توکن (توکن X و توکن Y) نگهداری می کند. کاربران می توانند توکن X را از این استخر برداشت کنند. در عوض، باید مقداری از توکن Y به استخر واریز کنند. این سازوکار به گونه ای طراحی شده است که “کل ارزش دارایی های استخر” کاهش پیدا نکند. منظور از “کل ارزش”، حاصلضرب مقدار این دو دارایی است.

در اینجا، x’ و y’ نشان دهنده موجودی توکن های استخر پس از انجام معامله هستند. همچنین، x و y موجودی توکن های استخر پیش از انجام معامله را نشان می دهند.

این مکانیزم تضمین می کند که ارزش دارایی های موجود در استخر یا ثابت می ماند یا افزایش پیدا می کند. اغلب استخرها برای انجام معاملات کارمزدی در نظر می گیرند. بنابراین، حاصلضرب موجودی توکن ها نه تنها باید افزایش یابد، بلکه باید به اندازه مشخصی (متناسب با کارمزد تعیین شده) رشد کند.

دارایی های موجود در استخر توسط تامین کنندگان نقدینگی (Liquidity Providers) تامین می شوند. این تامین کنندگان در ازای سهم خود از استخر، توکن هایی به نام توکن های LP دریافت می کنند. نحوه مدیریت این سهم ها مشابه روشی است که در استاندارد ERC 4626 پیاده سازی شده است. با این تفاوت که استاندارد ERC 4626 تنها از یک نوع دارایی پشتیبانی می کند. در حالی که یک بازارساز خودکار (AMM) همزمان با دو نوع توکن کار می کند.

درست مانند یک خزانه (Vault)، سهم تامین کنندگان نقدینگی از استخر ثابت باقی می ماند. اما با بزرگتر شدن حاصلضرب xy، ارزش سهم آن ها نیز افزایش می یابد.

مزایای بازارسازهای خودکار (AMM)

بازارسازهای خودکار (AMM) فاقد اختلاف قیمت خرید و فروش (Bid-Ask Spread) هستند.

در یک AMM، فرآیند کشف قیمت به صورت خودکار انجام می شود. این قیمت براساس نسبت دارایی های موجود در استخر تعیین می گردد. به طور دقیق تر، اگر دو توکن x و y در استخر داشته باشیم، قیمت به این صورت محاسبه می شود:

قیمت توکن x = میزان توکن y در استخر / میزان توکن x در استخر

برای توکن y نیز همین قاعده به صورت معکوس اعمال می شود. هرچه مقدار بیشتری از توکن x به استخر اضافه شود، این توکن “فراوان تر” خواهد شد و در نتیجه قیمت آن کاهش پیدا می کند.

در این مکانیزم نیازی نیست که منتظر بمانیم تا یک سفارش خرید یا فروش مناسب (Bid یا Ask) در بازار ظاهر شود. این امکان همیشه وجود دارد. اگر بین قیمت یک AMM و قیمت صرافی دیگری اختلاف وجود داشته باشد، معامله گران با انجام آربیتراژ این اختلاف را از بین می برند و قیمت ها را به تعادل می رسانند.

نکته مهم این است که قیمتی که محاسبه می شود، در واقع “قیمت لحظه ای” یا “قیمت نهایی در مرز معامله” (Spot یا Marginal Price) است. اگر شما مقدار مشخصی از توکن x را خریداری کنید، قیمت واقعی که پرداخت می کنید معمولا کمی بالاتر از قیمت محاسبه شده خواهد بود.

بازارسازهای خودکار (AMM) به عنوان اوراکل قیمتی

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

بازارسازهای خودکار از نظر مصرف گس بسیار بهینه تر از دفتر سفارشات هستند

دفتر سفارشات (Order Book) برای پردازش و مدیریت سفارش ها، نیاز به ذخیره و به روزرسانی مداوم داده ها دارد. در مقابل، AMM تنها دو نوع توکن را نگهداری می کند و آن ها را طبق قوانین ساده بین کاربران جابه جا می کند. این ساختار ساده باعث می شود پیاده سازی AMM از نظر مصرف گس، بسیار بهینه تر از دفتر سفارشات باشد.

معایب بازارسازهای خودکار (AMM)

دو ایراد اصلی در AMM ها وجود دارد:
اول، هر معامله باعث تغییر قیمت می شود.
دوم، تامین کنندگان نقدینگی با پدیده “زیان ناپایدار” (Impermanent Loss) روبرو می شوند.

حتی سفارش های کوچک قیمت را تغییر می دهند

اگر در یک بازار سنتی، سفارش خرید 100 سهم از سهام اپل ثبت کنید، این سفارش قیمت را تغییر نمی دهد. چون هزاران سهم با همان قیمت برای فروش در دسترس است. اما در AMM، هر معامله (حتی معامله های کوچک) نسبت دارایی ها در استخر را تغییر می دهد و همین تغییر باعث نوسان قیمت می شود.

این موضوع دو پیامد دارد:
نخست، سفارش های خرید یا فروش در AMM معمولا با لغزش قیمت (Slippage) بیشتری نسبت به دفتر سفارشات روبرو می شوند.
دوم، همین سازوکار مبادله زمینه را برای حملات ساندویچی (Sandwich Attacks) فراهم می کند.

حملات ساندویچی در AMM ها تقریبا اجتناب ناپذیر هستند

در AMM، هر سفارش باعث تغییر قیمت می شود. به همین دلیل، معامله گران MEV (Maximal Extractable Value) از این فرصت سوء استفاده می کنند.
این معامله گران منتظر یک سفارش خرید بزرگ می مانند. درست پیش از ثبت این سفارش، یک سفارش خرید خود ثبت می کنند. بلافاصله پس از انجام سفارش اصلی، یک سفارش فروش قرار می دهند.
این استراتژی باعث می شود قیمت برای معامله گر اصلی بالاتر برود و اجرای معامله او با کیفیت بدتری انجام شود.
این نوع حمله را “حمله ساندویچی” (Sandwich Attack) می نامند. چون معامله قربانی بین دو سفارش مهاجم قرار می گیرد.

مراحل حمله به این صورت است:

خرید اولیه مهاجم (Front Run): قیمت را برای معامله قربانی افزایش می دهد.
خرید قربانی: قیمت را باز هم بالاتر می برد.
فروش مهاجم: دارایی خریداری شده را با سود می فروشد.

تامین کنندگان نقدینگی کنترلی روی قیمت فروش دارایی های خود ندارند

به دلایلی که در ادامه بررسی خواهیم کرد، تامین کنندگان نقدینگی باید دارایی ها را براساس نسبت فعلی توکن های موجود در استخر تامین کنند.
برای مثال، اگر در استخر 100 توکن x و 200 توکن y وجود داشته باشد، تامین کننده جدید باید به ازای هر توکن x، دو برابر توکن y وارد استخر کند.

در دفتر سفارشات سنتی، بازارساز می تواند سفارش های محدود (Limit Order) ثبت کند. یعنی می تواند سفارش خرید در قیمتی پایین تر از قیمت فعلی یا سفارش فروش در قیمتی بالاتر از بازار ثبت کند.
اما در AMM این امکان وجود ندارد. بازارساز خودکار قیمت را با استفاده از یک فرمول بر اساس نسبت دارایی ها در استخر محاسبه می کند.
در نتیجه، بازارسازها نمی توانند قیمت مشخصی برای فروش دارایی های خود تعیین کنند.

تامین کنندگان نقدینگی در AMM ممکن است با زیان ناپایدار مواجه شوند

فرض کنیم در یک سناریوی فرضی، قیمت اتریوم (Ether) در ابتدا 10 دلار باشد و بعدا به 1000 دلار برسد.

اگر فردی یک پورتفوی شامل 1 واحد اتریوم و 10 دلار داشته باشد، ارزش اولیه پورتفوی او 20 دلار خواهد بود. پس از رشد قیمت، این پورتفوی به 1010 دلار (1 ETH + 10 دلار) می رسد.
در این حالت، سود خالص این فرد 990 دلار خواهد بود.

اما اگر همان دارایی ها را در یک AMM قرار می داد، بیشتر این سود از دست می رفت.
بعد از افزایش قیمت، استخر به جای 1 ETH، حدود 0.1 ETH و 100 دلار موجودی خواهد داشت. این نسبت قیمت اتریوم را به درستی روی 1000 دلار تنظیم می کند. اما ارزش خالص دارایی ها در استخر کمتر از 990 دلار خواهد بود.

ساختار موجودی های استخر پیش و پس از تغییر قیمت به این صورت خواهد بود:

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

در ادامه، یک جدول آورده شده است که عملکرد نسبی نگهداری ETH و USD در یک استخر AMM را با حالت نگهداری جداگانه مقایسه می کند:

	موجودی اتریوم در استخر	موجودی استیبل کوین در استخر	حاصلضرب ETH × استیبل کوین	ارزش هر 1 ETH (دلار)	ارزش دارایی ها در حالت تامین نقدینگی	ارزش دارایی ها در حالت نگهداری جداگانه
قبل از تغییر قیمت	1	10	10	10	$20 ($010 ETH + 10 USD)	$120 ($210 * 1 ETH + 10 USD)
بعد از تغییر قیمت	0.1	100	10	1000	$3200 ($4100 ETH + 100 USD)	$51010 ($61000 * 1 ETH + 10 USD)
سود (Gain)					$7180	$8990

سودی که از دست می رود، “زیان ناپایدار” نام دارد.
در مثال بالا، میزان زیان ناپایدار برابر است با: $9810 = ($0990 – $1180)

معماری Uniswap V2

معماری Uniswap V2 به شکل شگفت آوری ساده است. در هسته این سیستم، قرارداد UniswapV2Pair قرار دارد. این قرارداد دو توکن ERC-20 را در خود نگهداری می کند. معامله گران می توانند این توکن ها را با یکدیگر مبادله کنند و تامین کنندگان نقدینگی نیز می توانند برای آن نقدینگی فراهم کنند.

برای هر جفت توکن متفاوت، یک قرارداد UniswapV2Pair مجزا وجود دارد که مدیریت همان جفت را بر عهده دارد.
اگر قراردادی برای جفت توکن مورد نظر وجود نداشته باشد، هر کاربری می تواند بدون نیاز به مجوز (Permissionless)، یک قرارداد جدید از طریق UniswapV2Factory ایجاد کند.

همچنین، قراردادهای UniswapV2Pair خود یک توکن ERC-20 هستند (از ERC-20 به ارث می برند). این توکن برای ردیابی سپرده ها استفاده می شود، مشابه روشی که استاندارد ERC-4626 به کار می گیرد.

اگرچه معامله گران پیشرفته یا قراردادهای هوشمند می توانند به طور مستقیم با قرارداد Pair تعامل داشته باشند، اما بیشتر کاربران از طریق قرارداد Router این کار را انجام می دهند.
Router دارای توابع کمکی متعددی است، از جمله امکان انجام معاملات بین چند Pair در یک تراکنش. این ویژگی حتی می تواند یک Pair “مصنوعی” (Synthetic Pair) ایجاد کند اگر Pair مستقیم وجود نداشته باشد.

همین! معماری Uniswap V2 واقعا تنها شامل سه قرارداد هوشمند اصلی است:

Factory: github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Factory.sol
Pair (که از ERC-20 ارث می برد): github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Pair.sol
Router: github.com/Uniswap/v2-periphery/tree/master/contracts

الگوی Core – Periphery (هسته – پیرامون)

اگر دقت کنید، قرارداد Router در ریپازیتوری‌ به نام “v2-periphery” قرار دارد و قرارداد Pair در ریپازیتوری “v2-core” نگهداری می شود.
Uniswap V2 از الگوی طراحی “Core / Periphery” پیروی می کند. در این الگو، منطق اصلی و حیاتی در بخش Core قرار می گیرد. در مقابل، منطق اختیاری و امکانات جانبی در بخش Periphery پیاده سازی می شوند.

هدف از این طراحی آن است که حجم کدهای موجود در Core تا حد امکان کاهش پیدا کند. این کار احتمال بروز باگ در منطق اصلی سیستم را به میزان زیادی کم می کند.

چگونه آدرس یک Pool را با داشتن دو آدرس توکن پیدا کنیم؟

در Uniswap V2، قراردادهای هوشمند برای یافتن آدرس یک Pool از یک mapping استفاده نمی کنند. در عوض، آن ها با محاسبه آدرس Create2 و با استفاده از تکنیک های برنامه نویسی سطح پایین، آدرس Pool را بر اساس آدرس دو توکن و آدرس Factory پیش بینی می کنند. از آنجا که این روش نیازی به دسترسی به حافظه (Storage) ندارد، مصرف گس آن بسیار بهینه است.

در زیر نمونه تابع کمکی موجود در UniswapV2Library برای محاسبه آدرس قرارداد Pair آورده شده است:

// calculates the CREATE2 address for a pair without making any external calls
function pairFor(address factory, address tokenA, address tokenB) internal pure returns (address pair) {
    (address token0, address token1) = sortTokens(tokenA, tokenB);
    pair = address(uint(keccak256(abi.encodePacked(
            hex'ff',
            factory,
            keccak256(abi.encodePacked(token0, token1)),
            hex'96e8ac4277198f8fbbf785487aa39f430f63b76db002cb326e37da348845f' // init code hash
    ))));
}

// calculates the CREATE2 address for a pair without making any external calls

function pairFor(address factory, address tokenA, address tokenB) internal pure returns (address pair) {

(address token0, address token1) = sortTokens(tokenA, tokenB);

pair = address(uint(keccak256(abi.encodePacked(

hex'ff',

factory,

keccak256(abi.encodePacked(token0, token1)),

hex'96e8ac4277198f8fbbf785487aa39f430f63b76db002cb326e37da348845f' // init code hash

))));

}

چرا از الگوی Clone استفاده نمی شود؟

ممکن است این سوال پیش بیاید که چرا در اینجا از الگوی Clone که در EIP-1167 معرفی شده، استفاده نشده است. این الگو معمولا برای ایجاد مجموعه ای از قراردادهای مشابه کاربرد دارد. در حالی که استفاده از Clone هزینه استقرار اولیه قرارداد را کاهش می دهد، اما به ازای هر تراکنش، حدود 2600 گس اضافی به دلیل استفاده از delegatecall ایجاد می کند.
از آنجا که Pool ها به طور مکرر مورد استفاده قرار می گیرند، این هزینه اضافی به مرور زمان از مزیت کاهش هزینه استقرار پیشی می گیرد. به همین دلیل، ارزش آن را دارد که برای هر Pool یک قرارداد جدید به صورت کامل مستقر (Deploy) شود.

5/5 - (1 امتیاز)

راستی! برای دریافت مطالب جدید در کانال تلگرام یا پیج اینستاگرام سورس باران عضو شوید.

نظرات

برچسب ها: آموزش برنامه نویسی, آموزش سالیدیتی

پکیج آموزش صفر تا صد فتوشاپ به زبان فارسی – حرفه ای شوید

انتشار: ۱۳ خرداد ۱۴۰۴