مقدمه

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

جزئیات قرارداد

عملکردهای کلیدی

• read: یک قیمت غیر صفر را بدست می‌آورد یا اینکه با شکست مواجه می‌شود
• peek: قیمت و اعتبار را دریافت می‌کند
• poke: قیمت را از ارائه‌دهندگان مجاز به روزرسانی می‌کند
• lift: یک آدرس را به لیست معتبر اضافه می‌کند
• drop: یک آدرس را از لیست معتبر حذف می‌کند
• setBar: نوار را تنظیم می‌کند
• kiss: یک آدرس را به لیست معتبر اضافه می‌کند
• diss: یک آدرس را از لیست معتبر حذف می‌کند

توجه: تابع read مقدار را برمی‌گرداند یا در صورت عدم معتبر بودن با شکست مواجه می‌شود و peek مقدار value را برمی‌گرداند.

• wards: مکانیزم‌های مجوزدهی
• orcl: لیست معتبر val / امضاکنندگان قیمت‌ها
• bud: لیست معتبر val
• val: قیمت (به صورت خصوصی) باید با read یا peek خوانده شود
• age: زمان بلوک آخرین به‌روزرسانی قیمت val
• wat: نوع تغذیه‌ قیمت (برای مثال: ETHUSD) یا اینکه می‌گوید که دارایی از چه نوع است
• bar: حداقل تعداد خوانش‌³های poke یا اینکه کمترین تعداد پیام معتبر که برای به‌روزرسانی قیمت نیاز دارید

مکانیسم‌ها و مفاهیم کلیدی

همانطور که اشاره شد این قرارداد قیمت مرجع و معتبر زربان را تهیه میکند. داشتن مجوز یکی از اجزای کلیدی در مکانیزم این قرارداد و تعاملات آن است. به عنوان مثال، قیمت (val) عمدتاً به صورت عمومی نیست چرا که هدف این است که فقط از طریق دو تابع read و peek که وارسی شده‌اند، خوانده شود. برای این منظور نیاز به مجوز دسترسی دارید که از طریق bud ممکن می‌شود. عملکرد bud برای دریافت مجوز خوانش افرادی معتبر روی بلاکچین اجرا می‌شود، در حالی که همه فعالیت‌های آن در خارج از بلاکچین عمومی است.

روش poke تحت هیچ گونه مجوزی نیست. این به این معناست که هر کسی می‌تواند آن را فراخوانی کند. با هدف تشویق حافظان به فراخوانی این تابع و ارتباط با حراجی ها طراحی شده است. تنها راه برای تغییر حالت آن این است که آن را فراخوانی کنید و داده‌های معتبری را ارسال کنید. به عنوان مثال، فرض کنید این اوراکل به 15 منبع مختلف نیاز دارد. بنابراین نیاز دارید 15 امضاء مختلف ارسال کنید. سپس به ترتیب هرکدام را بررسی میکند و هر کسی که این داده‌ها را به صورت معتبر ارسال کرده مجاز به انجام کارش است. در صورتی که اوراکلی مجاز باشد، بررسی می‌کند که آیا پیام را با زمانی که بیشتر از زمان آخرین پیام است، امضا شده است. این کار برای اطمینان از این است که یک پیام نامعتبر نباشد. مرحله بعدی بررسی مقادیر دستور است که برای این منظور به ارسال همه چیز در یک آرایه نیاز است که به ترتیب صعودی قرار داده شده است. اگر به درستی ارسال نشود (یعنی صعودی نباشد)، میانه به درستی محاسبه نمی‌شود. اگر قیمت‌ها مرتب شده‌ باشند، به سادگی مقدار میانه محاسبه می‌شود. برای بررسی یکتا بودن آن، از یک فیلتر بنام bloom استفاده می‌شود. به طور خلاصه، فیلتر bloom یک ساختار داده‌ است که طراحی شده است تا به سرعت و با زمان کارآیی برای حافظه، به ما بگوید که آیا یک عنصر در مجموعه وجود دارد یا خیر. استفاده از فیلتر bloom به بهینه‌سازی کمک می‌کند. برای وارد کردن امضاکنندگان به لیست معتبر، اولین دو حرف از آدرس آنها (اولین بایت) باید یکتا باشد. به عنوان مثال، فرض کنید 15 امضا کننده با قیمت مختلف دارید، هیچکدام از دو حرف اول آدرس آنها نمی‌تواند یکسان باشد. این کار کمک می‌کند که تمام 15 امضاکننده متفاوت باشند.

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

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

val = uint128(val_[val_.length >> 1]);

که در آن با گرفتن آرایه‌ای از مقادیر (تمام قیمت‌هایی که هر یک از امضاکنندگان قیمت گذاری کرده‌اند، از 200 تا 215) و سپس انتخاب یکی از آنها است. این کار با گرفتن طول آرایه (15) و جابه‌جایی آن به سمت راست در یک گام(که همانند تقسیم بر 2 است) انجام می‌شود. در نهایت این مقدار 7.5 می‌شود و سپس EVM آن را به 7 تبدیل می‌کند. اگر قرار باشد اعداد زوج قابل قبول باشد، بهینگی پیاده‌سازی آن کمتر خواهد شد. این مسئله را نیز به وجود می‌آورد که باید تعادلی بین تعداد مورد نیاز و تعداد امضاکنندگان واقعی وجود داشته باشد. به عنوان مثال، فرض کنید اوراکل به 15 امضا نیاز دارد، باید حداقل 17-18 امضا کننده داشته باشید چرا که اگر 15 نفر مورد نیاز داشتید و فقط 15 نفر تایید کنند و یکی از آنها دچار مشکل شود، نمی‌توانید قیمت را تغییر دهید، بنابراین همیشه باید تعداد مناسبی بیشتر داشته باشید. با این حال، نباید از حد زیادی استفاده شود، زیرا ممکن است این تعداد زیاد عملکرد را به خطر بیندازد.

نکات پیاده‌سازی و امنیتی

اوراکل‌های اضطراری

این اوراکل‌ها می‌توانند تغذیه قیمت را خاموش کنند. اما نمی‌توانند آن را دوباره فعال کنند. برای فعال کردن دوباره آن، سیستم باید دخالت کند.

فریزشدن قیمت

اگر ماژول اوراکل‌ها را از بین ببرید، نمی‌توانید با هیچ یک از صندوق‌هایی که به آن ilk وابسته هستند، تعامل کنید. به عنوان مثال با خاموش کردن ETH/USD (می‌توانید هنوز سرمایه اضافه کنید و بدهی پرداخت کنید ) اما نمی‌توانید هیچ کاری دیگری انجام دهید که ریسک را افزایش دهد( حذف سرمایه، تولید زر و غیره) زیرا سیستم نمی‌تواند تشخیص دهد که آیا اکنون وثیقه کافی دارید یا خیر.

اوراکل‌ها نیاز به اصلاح و نگهداری زیادی دارند

اوراکل‌ها باید همه relayer ها را در حالت فعال نگه دارند. در این فضا که غیرمتمرکز است، اگر نیاز به جایگزینی باشد، همه باید خودشان نظارت کنند (با توجه به هر امضاکننده قیمت و غیره). باید مطمئن شوند که هر ساعت یکبار و به موقع فراخوانی می‌شود (برای هر ساعت، یک تراکنش به OSM ارسال می‌شود)، بنابراین چندین تراکنش قبلاً به این قرارداد ارسال شده است تا به‌روزرسانی شود، علاوه بر این، نیاز به ارسال یک تراکنش به spotter وجود دارد، زیرا سیستم زربان به روشی با نام از نوع استخراج⁴ اداره می‌شود (به عبارتی سیستم را به روز نمی‌کند، شما به آن می‌گویید که از OSM بخواند). چیزی وجود ندارد که از استفاده کردن دو امضاکننده قیمت با آدرس یکسان جلوگیری کند. تنها چیزی که باعث می‌شود این اتفاق بیفتد این است که نمی‌توانید بیش از 256 اوراکل داشته باشید. اما در عمل هرگز انتظار نداریم که این تعداد زیاد را داشته باشیم، بنابراین این یک محدودیت ناکارآمد است.

در طراحی حال حاضر، هیچ روشی برای خاموش کردن اوراکل (شکست یا برگشت به مقدار اشتباه) وجود ندارد. اگر تمام اوراکل‌ها با هم تبانی کنند و قیمت صفر را امضا کنند، باعث می‌شود قیمت نامعتبر شود و در peek ، مقداری را به ما می‌دهد که به این مقدار اعتماد نکنیم. در حال حاضر (ماژول اوراکل‌ها) برای لغو قیمت در حال بررسی است. اما هیچ راهی برای انجام این کار در این قرارداد وجود ندارد. در واقع به دلیل جداسازی مسئولیت‌ها است که سیستم توکن زر مستقیماً از این قرارداد نمی‌خواند، بلکه از OSM می‌خواند، اما این ممکن است در آینده تغییر کند.

¹ Whitelist

² Authorization

³ Reads

⁴ Pool-type