پرش به مطلب اصلی

قرارداد الحاق

دامنه این صفحه

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

⁠⁠⁠⁠⁠⁠⁠

مقدمه

الحاق1 از سه قرارداد هوشمند زیر تشکیل شده است:

  • GemJoin: می‌گذارد توکن‌های استاندارد ERC20 را برای استفاده در سیستم واریز کنید.
  • ETHJoin: می‌گذارد از اتر در سیستم استفاده کنید.
  • ZarJoin: امکان برداشتن زر از سیستم به‌صورت یک توکن استاندارد ERC20 را فراهم می‌کند.

هر قرارداد الحاق را برای همان توکنی ساخته‌ایم که باید به قرارداد مدیریت صندوق‌ها بپیوندد. به همین دلیل، همه این قراردادها با منطقی تقریباً یکسان، انواع گوناگون توکن را در سیستم پوشش می‌دهند.

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

  • vat - ذخیره آدرس Vat
  • ilk - شناسه Ilk که یک GemJoin برای آن ایجاد می‌شود
  • gem - آدرس ilk برای انتقال
  • zar - آدرس توکن زر
  • one - یک مقدار ثابت از نوع uint و برابر مقدار 10^27 که برای انجام محاسبات در ZarJoin استفاده می‌شود
  • live - یک پرچم دسترسی برای اداپتور الحاق
  • dec - رقم اعشار استفاده‌شده برای آن Gem‍

هر قرارداد الحاق دارای ۴ تابع عمومی است: یک سازنده، join، exit و cage. سازنده در زمان مقداردهی اولیه قرارداد استفاده می‌شود و متغیرهای اصلی آن را تنظیم می‌کند. همان‌طور که از نامشان مشخص است، توابع Join و exit برای اضافه شدن و خروج استفاده می‌شوند. الحاق سازوکاری در اختیار کاربران می‌گذارد تا نوع توکن موردنظرشان را به قرارداد مدیریت صندوق‌ها بیفزایند. منطق هر نسخه کمی متفاوت است، اما به‌طور کلی به انتقال و فراخوانی تابع در قرارداد مدیریت صندوق‌ها منجر می‌شود. تابع Exit با منطق مشابه عمل می‌کند، اما به جای اضافه شدن، به کاربر این اجازه را می‌دهد توکن مورد نظر خود را از قرارداد مدیریت صندوق‌ها حذف کند. تابع Cage اجازه می‌دهد تا اداپتور خالی شود (اجازه می‌دهد تا توکن‌ها از صندوق خارج شوند اما نمی‌توانند اضافه شوند).

سازوکار‌ها و مفاهیم کلیدی

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

موجودی کیف پول کاربر برای توکن‌های وثیقه که از طریق الحاق به سیستم اضافه شده‌اند، در ‍vat به‌عنوان Gem (بر اساس نوع وثیقه Ilk ) در نظر گرفته می‌شود تا زمانی که به توکن‌های وثیقه قفل‌شده (ink) تبدیل شوند که در این صورت کاربر می‌تواند زر را از حساب خود خارج کند.

قرارداد ZarJoin نیز هدف مشابهی دارد. وظیفه آن مدیریت مبادله های زر و Zar ERC-20 است که به ترتیب در ‍قرارداد مدیریت صندوق‌ها و Zar.sol پیگیری می‌شوند. پس از این که یک کاربر زر را در عوض وثیقه‌اش از حساب خارج کند، یک موجودی در Vat.dai‍ خواهد داشت. از آنجایی که ZarJoin موجودی Vat.dai را دارد و می‌تواند Zar ERC-20 را mint کند، این موجودی زر را می‌توان با استفاده از قرارداد ZarJoin‍ از Vat.dai خارج کرد. هنگامی که یک کاربر می‌خواهد زر خود را به سیستم حسابداری ‍Vat بازگرداند (برای پرداخت بدهی، شرکت در حراج‌ها، باگ‌های متد End و غیره)، باید ZarJoin.join را فراخوانی کند. با فراخوانی ZarJoin.join ، تابع burn به‌صورت مؤثری بر روی Zar ERC-20 انجام می‌شود و موجودی Vat.zar از موجودی ZarJoin به حساب کاربر (در قرارداد مدیریت صندوق‌ها) منتقل می‌شود. در حالت معمولی سیستم، موجودی کل زر باید معادل موجودی Vat.zar(ZarJoin) باشد. همین که یک آدرس مجاز برای ZarJoin مقدار cage را تعیین کند، این قرارداد می‌تواند زر را به Vat‍ بازگرداند، اما دیگر نمی‌تواند زر را از قرارداد مدیریت صندوق‌ها بیرون ببرد.

نکات مهم ( خطاهای احتمالی کاربر)

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

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

حالت‌های منجر به خطا (محدودیت‌ها عملیاتی و عوامل ریسک خارجی)

ممکن است یک ارتقاء vat وجود داشته باشد که نیازمند ایجاد قراردادهای الحاق جدید باشد. اگر یک قرارداد gem در پروسه یک ارتقاء توکن قرار گیرد یا توکن‌ها در حالی که ضمانت یک کاربر در سیستم است، فریز شوند، یک سناریوی احتمالی می‌تواند این باشد که کاربران پس از اتمام فریزشدن یا ارتقاء، قادر به بازیابی وثیقه خود نباشند. احتمالاً این سناریو کمترین ریسک را دارد زیرا توکنی که این ارتقاء را تجربه می‌کند، می‌خواهد کنار جامعه زربان کار کند تا اطمینان حاصل شود که این یک مشکل نیست.

Footnotes

  1. Join

  2. Well-executed Phishing Attack