قرارداد حاکمیتی در سالیدیتی چیست؟ بررسی ساختار و مراحل رای گیری

بیشتر برنامه های DeFi از الگویی پیروی می‌کنند که از پیاده سازی پلتفرم Compound Finance الهام گرفته شده است. با اینکه هنوز هیچ طرح رسمی ارتقاء اتریوم (EIP) برای تعریف یک رابط استاندارد حاکمیتی وجود ندارد، اکثر پروژه های DeFi اصول مشابهی را در پیاده سازی حاکمیت دنبال می‌کنند.

این قراردادها معمولاً مانند کیف پول های چند امضایی عمل می‌کنند. تفاوت آن‌ ها در این است که وزن هر رای بر اساس میزان توکن های در اختیار رای دهنده تعیین می‌شود.

هر پیشنهاد در واقع یک تراکنش اتریومی است. این تراکنش شامل یک یا چند آدرس به همراه داده(های) تابع (calldata) است. دارندگان توکن هایی که حق رای دارند، این تراکنش ها را به‌عنوان پیشنهاد ثبت می‌کنند. در ادامه، رای گیری انجام می‌شود. اگر رای لازم کسب شود، تراکنش در بلاکچین اجرا می‌شود، در غیر این صورت، پیشنهاد رد خواهد شد.

در موارد خارج از زنجیره (مثل تغییر مجوز حقوقی یک نرم‌افزار)، نیازی به اجرای تراکنش نیست. در این شرایط، فقط یک پیام امضا می‌شود تا اختیار انجام آن اقدام رسمی شود.

اصطلاحات کاربردی

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

پیشنهاد (Proposal)

هر فرآیند رای گیری با یک پیشنهاد آغاز می‌شود؛ مفهومی که پیش‌تر نیز معرفی شد. پیشنهاد در واقع یک تراکنش اتریومی قابل امضا است؛ یعنی دارای یک یا چند آدرس مقصد و مجموعه‌ای از داده های تابع (calldata) می‌باشد.

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

در سطح کدنویسی، پیشنهاد معمولاً به‌صورت یک ساختار (struct) در زبان سالیدیتی تعریف می‌شود. این ساختار شامل وضعیت فعلی پیشنهاد، رای های ثبت‌شده برای آن و فهرستی از تراکنش هایی است که در صورت تأیید شدن پیشنهاد اجرا خواهند شد.

رای (Vote)

رای‌ دادن نیز همان‌طور که انتظار می‌رود، یک تراکنش اتریومی است که طی آن، رای دهنده نظر خود را نسبت به یک پیشنهاد (موافق یا مخالف) ثبت می‌کند. وزن رای معمولاً بر اساس تعداد توکن هایی محاسبه می‌شود که آدرس رای دهنده در زمان ثبت اسنپ شات (snapshot) مربوطه در اختیار داشته است.

حد نصاب قانونی (Quorum)

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

به همین دلیل، برای اینکه سرنوشت یک پیشنهاد مشخص شود، باید در بازه زمانی رای گیری، حداقل تعداد مشخصی از آرا (بر اساس درصدی از کل آرا ممکن) ثبت شود. این حداقل آرا را «حد نصاب» یا quorum می‌نامند.

دوره رای گیری (Voting Period)

پیشنهادها منتظر نمی‌مانند تا به صورت نامحدود حد نصاب رای را کسب کنند. در غیر این‌صورت، ممکن است یک پیشنهاد در زمانی اجرا شود که شرایطی که باعث ایجاد آن شده بودند، تغییر کرده باشند. به همین دلیل، از لحظه‌ای که یک پیشنهاد ثبت می‌شود، شمارش معکوس آغاز می‌گردد. اگر تا پایان این بازه زمانی، حد نصاب رأی لازم به دست نیاید، پیشنهاد به‌طور خودکار رد می‌شود و امکان اجرا نخواهد داشت.

در صف قرار گرفتن و اجرا (Queued and Execution)

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

قفل زمانی (Timelock)

کاربران نباید قفل زمانی را با دوره رای گیری اشتباه بگیرند؛ این دو مفهوم کاملاً متفاوت هستند. این مفهوم به فاصله‌ای زمانی اشاره دارد که پس از تأیید یک پیشنهاد آغاز می‌شود و تا زمان اجرای واقعی آن ادامه دارد.

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

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

مراحل حاکمیت (Phases of Governance)

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

نمودار زیر، وضعیت‌های احتمالی یک پیشنهاد را در مسیر حاکمیت Compound Finance نمایش می‌دهد:

https://docs.compound.finance/v2/governance

• Pending (در انتظار): سیستم پیشنهاد را ثبت کرده، اما هنوز فرآیند رای گیری برای آن آغاز نشده است.

• Active (فعال): کاربران در حال ثبت آرای خود هستند.

• Defeated (رد شده): کاربران به پیشنهاد رای مخالف دادند یا رای کافی برای تأیید آن ندادند.

• Canceled (لغو شده): پروتکل این پیشنهاد را پیش از پایان رای گیری لغو کرده است.

• Succeeded (تأیید شده): کاربران با رای مثبت کافی، پیشنهاد را تأیید کردند و حالا آماده اجرای آن هستند.

• Queued (در صف اجرا): سیستم این پیشنهاد تأییدشده را وارد صف اجرا کرد و قفل زمانی فعال شد.

• Executed (اجرا شده): قرارداد حاکمیتی، پیشنهاد را طبق زمان‌بندی اجرا کرد.

• Expired (منقضی شده): سیستم به‌دلیل پایان مهلت، امکان اجرای این پیشنهاد را غیرفعال کرد.

و این هم نمودار وضعیت های حاکمیتی در پلتفرم Uniswap است:

https://docs.uniswap.org/contracts/v2/reference/Governance/governance-reference

اینکه چه کسی اجازه دارد یک پیشنهاد را ایجاد کند و آن را به وضعیت «در انتظار» (Pending) منتقل کند، کاملاً به طراحی هر پروتکل بستگی دارد. در بسیاری از سیستم ها، کیف پول هایی که مقدار مشخصی از توکن حاکمیتی را در اختیار دارند، می‌توانند پیشنهاد ثبت کنند.

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

اگر نمی‌دانید یک پیشنهاد دقیقاً چه زمانی یا چگونه تغییر وضعیت می‌دهد، کافی است کد قرارداد سالیدیتی را باز کرده و آن را مستقیماً بررسی کنید. مطالعه مستقیم کد، شفاف‌ترین و دقیق‌ترین اطلاعات را در اختیار شما قرار می‌دهد.

Governor Alpha و Governor Bravo

پلتفرم Compound تأثیر چشم‌گیری بر نحوه پیاده سازی حاکمیت در پروژه های DeFi داشته است. در سال ۲۰۲۱، این پلتفرم ویژگی‌های جدیدی را به نسخه اولیه قرارداد حاکمیتی خود اضافه کرد. طراحی به‌روزشده‌ای که با این تغییرات همراه بود، با نام Governor Bravo معرفی شد و بسیاری از پروتکل‌های DeFi نیز تغییرات مشابهی را در ساختار حاکمیتی خود اعمال کردند.

ویژگی‌های جدید Governor Bravo:

• رای دهندگان می‌توانند به‌جای انتخاب صرف «موافق» یا «مخالف»، به‌طور صریح گزینه «امتناع» (Abstain) را نیز انتخاب کنند.

• توسعه دهندگان این قرارداد حاکمیتی را با الگوی پراکسی پیاده سازی کرده‌اند تا امکان ارتقاء بدون نیاز به بازنویسی کامل فراهم باشد.

• رای دهندگان می‌توانند همراه با رای خود، متن دلیل رای (reason string) را نیز ارائه دهند.

• اگر به نسخه Governor Bravo در OpenZeppelin نگاه کنیم، می‌بینیم که vote struct حالا یک فیلد جدید برای رأی «امتناع» دارد.

این تغییرات باعث افزایش شفافیت، انعطاف پذیری و مشارکت بیشتر در فرآیند حاکمیتی شده‌اند و به کاربران امکان می‌دهند تا دیدگاه خود را دقیق‌تر و حرفه‌ای‌تر بیان کنند.

نمونه‌ای از روند اجرای یک پیشنهاد حاکمیتی

وب‌سایت tally.xyz یک رابط کاربری بسیار مناسب برای نمایش فرآیند پیشنهادهای حاکمیتی ارائه می‌دهد. این پلتفرم به‌خوبی مراحل مختلف یک پیشنهاد از زمان ثبت تا رای گیری و اجرا را نمایش می‌دهد.

بیایید نگاهی به پیشنهاد شماره ۹ در Uniswap بیندازیم؛ این پیشنهاد موفق شد و هدف آن افزودن یک سطح کارمزد جدید با نرخ ۰.۰۱ درصد (1 basis point) به استخرهای نقدینگی بود.

اگر با Uniswap آشنایی ندارید: در این پلتفرم، ارائه دهندگان نقدینگی (Liquidity Providers) زمانی کارمزد دریافت می‌کنند که کاربری اقدام به مبادله (swap) توکن ها از طریق استخری کند که آن‌ها ایجاد کرده‌اند. نرخ این کارمزد هنگام ایجاد استخر تعیین می‌شود و فقط می‌تواند یکی از مقادیر مشخص‌شده از پیش باشد.

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

در تصویر زیر، Tally تصویری دقیق از رای گیری و روند اجرای این پیشنهاد ارائه می‌دهد:

https://www.tally.xyz/gov/uniswap/proposal/9

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

این صفحه فعالیت‌هایی را نمایش می‌دهد که به‌صورت درون‌زنجیره‌ای (on-chain) انجام شده‌اند و مستقیماً در بلاکچین ثبت و اجرا می‌شوند. کاربر می‌تواند با کلیک روی آیکون سه نقطه کنار هر مرحله، به تراکنش مربوطه در وب‌سایت Etherscan دسترسی پیدا کند.

به‌عنوان نمونه، لینک زیر تراکنشی را نشان می‌دهد که در آن پیشنهاد مورد نظر واقعاً اجرا شده است:
نمایش تراکنش در Etherscan

با بررسی لاگ‌های این تراکنش، مشخص است که رویداد FeeAmountEnabled توسط قراردادی با آدرس 0x1f98431c8ad98523631ae4a59f267346ea31f984 صادر شده است. این آدرس متعلق به قرارداد کارخانه (factory) پلتفرم Uniswap است که مسئول ایجاد استخرهای نقدینگی جدید می‌باشد.

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

حملات حاکمیتی (Governance Attacks)

در برخی موارد، مهاجمان توانسته‌اند با سوءاستفاده از ضعف‌های طراحی در سازوکارهای حاکمیتی، حملاتی موفق اجرا کنند. در ادامه، یکی از این نمونه‌ها را بررسی می‌کنیم.

حمله با استفاده از وام لحظه‌ای (Flash Loan Attack)

پروتکل BeanStalk قابلیتی به نام emergencyCommit داشت. این ویژگی اجازه می‌داد در شرایط اضطراری، اگر تعداد کافی از رای دهندگان از یک پیشنهاد پشتیبانی می‌کردند، آن پیشنهاد بدون نیاز به گذشت زمان قفل (Timelock) بلافاصله اجرا شود. هدف از این قابلیت، اجرای سریع تصمیماتی بود که در شرایط بحرانی ضروری به‌نظر می‌رسیدند.

مهاجم از این قابلیت سوءاستفاده کرد. او با دریافت یک وام لحظه‌ای (Flash Loan) مقدار زیادی از توکن های دارای حق رای را به‌صورت موقت به دست آورد. سپس با استفاده از این قدرت رای گیری مصنوعی، فوراً از قابلیت emergencyCommit استفاده کرد و توانست قفل زمانی را دور بزند. در نهایت، پیشنهادی را اجرا کرد که باعث خروج کل سرمایه موجود در پروتکل و انتقال آن به کیف پول مهاجم شد.

این حمله یکی از نمونه‌های شناخته‌شده‌ای است که به خوبی نشان می‌دهد که بی‌توجهی به سناریوهای سوءاستفاده در طراحی مکانیزم‌های حاکمیتی، می‌تواند زمینه‌ساز آسیب‌های جدی مالی شود.

حمله از طریق کاهش قیمت توکن (Low Price Attack)

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

پروتکل‌هایی که دارایی‌های قفل‌شده (TVL) زیادی دارند، اما ارزش بازار توکن حاکمیتی آن‌ها پایین است، بیش از همه در معرض این نوع حمله قرار دارند. در چنین شرایطی، حمله‌کننده می‌تواند با خرید مقدار زیادی توکن، حق رای کافی برای تصویب اقدامات مخرب به‌دست آورد.

یکی از نمونه‌های واقعی این حمله در پروژه True Seniorage Dollar رخ داد. در این حمله، مهاجم با در اختیار گرفتن اکثریت آرا، پیشنهادی را تصویب کرد که به او اجازه می‌داد میلیاردها استیبل کوین جدید ضرب (mint) کند. سپس این توکن ها را در یک صرافی غیرمتمرکز دیگر فروخت و از سیستم خارج شد.

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

حملات اجتماعی یا سیاسی (Social or Political Attacks)

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

فرصتی برای بهبود (Room for Improvement)

تاکنون شواهد قابل استنادی ارائه نشده که اثبات کند الگوی مرسوم حاکمیت در پروژه‌های DeFi، که در این مقاله به آن پرداخته‌ایم، از نظر فنی بهینه‌ترین مدل ممکن باشد. در واقع، ویتالیک بوترین (خالق اتریوم) بارها از ساختار فعلی انتقاد کرده و آن را نظامی ناعادلانه برای رای دهندگان کوچک دانسته است.

وی در یکی از مقالات وبلاگ خود چند راه‌حل برای بهبود این وضعیت پیشنهاد کرده است. یکی از ایده‌هایی که مورد توجه قرار گرفت، استفاده از رای گیری رادیکالی (Quadratic Voting) بود؛ یعنی وزن هر رای بر اساس ریشه دوم تعداد توکن های در اختیار هر فرد محاسبه شود. این مدل باعث می‌شود تأثیر رای دهندگان بزرگ کاهش یابد و کاربران کوچک‌تر هم بتوانند نقش معناداری ایفا کنند.

با این حال، حتی این روش نیز مشکل خاص خود را دارد. مهاجمان می‌توانند دارایی خود را بین چند آدرس تقسیم کنند تا از تأثیر کاهش وزن رای (ناشی از تابع ریشه دوم) فرار کنند. این ضعف همچنان یکی از چالش‌های حل‌نشده در مسیر عادلانه‌سازی حاکمیت در DeFi است.

ابزارهایی برای راه اندازی سیستم حاکمیتی

اگر قصد دارید یک DAO با حاکمیت درون زنجیره ای (On-Chain Governance) راه‌اندازی کنید، نیازی به نوشتن قراردادهای هوشمند از صفر نیست. ابزارها و منابعی وجود دارند که این فرایند را سریع‌تر و مطمئن‌تر می‌کنند:

• OpenZeppelin Wizard: ابزاری تعاملی برای تولید خودکار کد قراردادهای حاکمیتی با استفاده از الگوهای استاندارد و امن.

• Tally for Developers: پلتفرمی قدرتمند برای مدیریت فرآیند رای گیری، ساخت رابط کاربری و تعامل با قراردادهای حاکمیتی.

• Alchemy Docs – How to Create a DAO Governance Token: راهنمای گام‌به‌گام برای ایجاد توکن حاکمیتی و راه‌اندازی یک DAO با ابزارهای توسعه مدرن.

جمع بندی

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

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

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

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