پل ارتباطی Reasonable: تبدیل مدل‌های TLA+ به اثبات‌های ماشین‌خوان در Rust

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

به گزارش Reasonable، یک خط لوله عامل‌محور (Agentic) جدید اکنون قادر است بیش از ۱۶,۰۰۰ جفت مشخصات TLA+ را به ۳,۰۰۰ اثبات ماشین‌خوان تبدیل کند. این پیشرفت در زمانی رخ می‌دهد که صنعت نرم‌افزار برای تضمین رفتار پیش‌بینی‌پذیر عامل‌های هوش مصنوعی و سیستم‌های توزیع‌شده با چالش‌های جدی روبروست.

تأیید رسمی (Formal Verification) سال‌هاست که استاندارد طلایی برای نرم‌افزارهای حیاتی است، اما فرآیندی به‌شدت دشوار و زمان‌بر است. ابزارهایی مثل TLA+ (منطق زمانی اقدامات) به مهندسان اجازه می‌دهند رفتار سیستم را مدل‌سازی کنند، اما همواره یک «شکاف میان مدل و اجرا» وجود داشته است؛ یعنی کدی که در نهایت نوشته می‌شود، لزوماً از مدل تأییدشده پیروی نمی‌کند و با گذشت زمان از آن فاصله می‌گیرد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر تست‌های تجربی برای سیستم‌های پیچیده کافی نیست. در ۲۷ سپتامبر ۲۰۲۶، Reasonable جزئیات متصل کردن مدل‌های TLA+ به Verus را منتشر کرد. Verus ابزاری است که اجازه می‌دهد مشخصات و اثبات‌ها مستقیماً درون کد Rust قرار بگیرند. با این رویکرد، صحت سیستم دیگر یک مدل تئوریک نیست، بلکه ویژگی‌ای است که توسط ماشین در حین اجرای نرم‌افزار چک می‌شود.

این موج توجه پس از آن شدت گرفت که Boris Cherny از مدل Opus 5.5 برای مدل‌سازی بخش‌هایی از Claude Agent SDK در TLA+ و Lean استفاده کرد. پست او با حدود یک میلیون بازدید و هزاران ذخیره (Bookmark)، نشان داد که استفاده از TLA+ در کدنویسی عامل‌محور کاملاً ارزشمند است؛ دیدگاهی که شرکت Datadog نیز در یادداشت خود درباره‌ی عامل‌های «ابتدا-تست» (harness-first) تأیید کرده است.

زیربنای TLA+ و مفاهیم کلیدی

زبان TLA+ برای توصیف دو شیء اصلی به کار می‌رود: سیستم‌های انتقال و ویژگی‌های زمانی. سیستم انتقال تعریف می‌کند که یک سیستم از طریق حالت‌ها و اقدامات چه کارهایی می‌تواند انجام دهد. حالت‌ها مانند عکس‌هایی از وضعیت سیستم هستند؛ برای مثال، در یک سیستم انتخابات، حالت شامل این است که چه کسی نامزد است، چه کسی به چه کسی رای داده و چه کسی رهبر است. اقدامات، گام‌های تک‌مرحله‌ای هستند که حالت را تغییر می‌دهند، مانند اینکه «کامپیوتر a یک انتخابات را شروع می‌کند» یا «کامپیوتر b به a رای می‌دهد».

در یک سناریوی انتخاب رهبر بین سه کامپیوتر (a، b و c)، TLA+ حالت‌های قانونی و انتقال‌های مجاز را اعلام می‌کند. برای مثال، هر کامپیوتر می‌تواند از حالت اولیه با رای دادن به خودش، انتخابات را شروع کند و دیگران ممکن است به a یا c رای دهند. TLA+ هیچ ترتیبی برای این انتقال‌ها تحمیل نمی‌کند و توزیع‌های احتمالی را مدل نمی‌سازد. این دقیقاً انتزاع درستی برای سیستم‌های توزیع‌شده است، جایی که پیام‌ها، زمان‌های انتظار (timeouts) و اقدامات کاربران در ترتیب‌های پیش‌بینی‌ناپذیری رخ می‌دهند.

ویژگی‌های زمانی تعریف می‌کنند که چه چیزی باید «همیشه» درست باشد (ایمنی یا Safety) یا چه چیزی باید «در نهایت» رخ دهد (زنده بودن یا Liveness). این‌ها با عملگرهای ریاضی روی اجراها تعریف می‌شوند:

• □ P (همیشه P): ویژگی P در تمام حالت‌های بازدید شده برقرار است.
• ◇ P (در نهایت P): ویژگی P در برخی حالت‌های آینده برقرار می‌شود.
• P ⇝ Q (P منجر به Q می‌شود): هرگاه P برقرار شود، در نهایت Q نیز پس از آن رخ می‌دهد.

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

زنده بودن نیازمند «فرض‌های انصاف» (Fairness Assumptions) است تا اجراهایی که در آن‌ها یک اقدام برای همیشه ممکن است اما هرگز انجام نمی‌شود، حذف شوند. انصاف ضعیف WF(A) به این معناست که اقدامی که فعال می‌ماند، باید در نهایت رخ دهد. انصاف قوی SF(A) اقداماتی را پوشش می‌دهد که به طور نامحدود دفعات فعال می‌شوند.

برای بررسی این ویژگی‌ها، ابزارهایی مثل TLC تمام حالت‌های ممکن را می‌شمارند. در یک انتخابات سه کامپیوتری، TLC تمام ۳۸ حالت را بررسی می‌کند تا ویژگی‌ها را تأیید کند. اما این روش فقط برای نمونه‌های متناهی کار می‌کند؛ با افزایش اندازه سیستم، تعداد حالت‌ها به‌شدت زیاد می‌شود (انفجار حالت). برای مثال، تبدیل ۳ کامپیوتر به ۹ کامپیوتر، تعداد حالت‌ها را از ۳۸ به بیش از یک میلیون می‌رساند و بررسی جامع را بدون یک اثبات رسمی غیرممکن می‌کند.

محدودیت‌های TLA+ و نیاز به راهکار جدید

با وجود استفاده گسترده در AWS، MongoDB و Kafka، ابزار TLA+ به تنهایی کافی نیست زیرا:

• محدودیت مدل‌های متناهی: TLC فقط نمونه‌های کوچک را چک می‌کند و برای اثبات ویژگی‌ها در اندازه‌های دلخواه، به اثبات ریاضی نیاز است. اثبات‌گر داخلی TLA+ یعنی TLAPS، اتوماسیون محدودی دارد، به‌ویژه در مورد ویژگی‌های زنده بودن.
• شکاف پیاده‌سازی: TLA+ یک مدل مجزا است. هیچ تضمین خودکاری وجود ندارد که نرم‌افزار واقعی دقیقاً مشابه مدل رفتار کند. این هسته‌ی اصلی شکاف کلاسیک میان مشخصات و اجرا است.
• محدودیت‌های منطقی: TLA+ بر اساس منطق زمانی خطی (LTL) است که اجراهای فردی را توصیف می‌کند. این منطق نمی‌تواند ویژگی‌های مربوط به آینده‌های جایگزین یا استراتژی‌های مختلف را بیان کند.

مسیر رسیدن به کد تأییدشده

رویکرد Reasonable با ادغام سیستم‌های اثبات مدرن، از مدل‌سازی ساده فراتر می‌رود:

• Lean: یک اثبات‌گر تعاملی که در آن اثبات‌ها گام‌به‌گام نوشته می‌شوند. این ابزار کلی است، در ریاضیات کاربرد وسیعی دارد و همان اثبات‌گری است که Boris Cherny از آن استفاده کرد.
• Verus: یک اثبات‌گر خودکار-فعال (auto-active) برای Rust. کاربران مشخصات و ساختار اثبات را ارائه می‌دهند و یک حل‌کننده (solver) خودکار، استدلال‌های سطح پایین را مدیریت می‌کند.
• Veil: ابزاری مبتنی بر Lean برای مدل‌های ماشین-حالت که توسط Leo de Moura توصیه شده است. این ابزار اخیراً برای تأیید یک موتور همگام‌سازی استفاده شد و ۱۷ باگ را شناسایی و رفع کرد، هرچند زنده بودن در مراحل آینده است و مدل تأییدشده همچنان از پیاده‌سازی جداست.

با استفاده از Verus، توسعه‌دهندگان می‌توانند ثابت کنند که پیاده‌سازی Rust، مدل TLA+ را «تصفیه» (Refine) می‌کند. این یعنی کد از نظر ریاضی تضمین شده است که از مشخصات مدل پیروی کند. این کار بر پایه دستاوردهای سیستمی مثل Anvil بنا شده است که این سبک تأیید را به صورت دستی نمایش داده بود و Reasonable مستقیماً بر روی کارهای Anvil توسعه یافته است.

سازوکار خط لوله هوش مصنوعی

اثبات‌های رسمی اغلب تکراری هستند. اثبات‌های ایمنی معمولاً استقرایی‌اند؛ یعنی نشان می‌دهند ویژگی در ابتدا برقرار است و هر اقدام آن را حفظ می‌کند. بخش زیادی از کار شامل تقسیم‌بندی روی اقدامات مختلف و ردیابی ناورداهای (invariants) مربوطه است. اثبات‌های زنده بودن پیشرفت سیستم را ثابت می‌کنند، معمولاً با نشان دادن اینکه مقداری با پیشرفت سیستم کاهش می‌یابد، در ترکیب با فرض‌های انصاف. قوانینی مانند WF1، WF2، SF1 و SF2 این استدلال‌ها را بسته‌بندی می‌کنند؛ کتابخانه زمانی Reasonable این‌ها را به عنوان لم‌های (lemmas) اثبات‌شده در Verus پیاده کرده است.

Reasonable این فرآیند را با یک معماری چندعاملی خودکار کرده است:

• ترجمه‌گر (Transpiler): یک ابزار الگوریتمی (و یک جایگزین مبتنی بر LLM) که مشخصات TLA+ را به اثبات‌های Verus تبدیل می‌کند. تیم سازنده نسخه الگوریتمی را با یک نسخه عامل‌محور مقایسه کرد که در آن یک LLM ترجمه را تولید و LLM دوم آن را بازبینی می‌کند.
• حلقه اثبات‌گر-بازبین: یک عامل اثبات را می‌نویسد و عامل دوم آن را برای یافتن خطاها بررسی می‌کند.
• دروازه‌بان (Gatekeeper): بررسی نهایی برای اطمینان از اینکه عامل‌ها با تغییر غیرمجاز در مشخصات یا استفاده از میان‌برهای منطقی مانند assume(false)، تقلب نکرده‌اند.

این خط لوله ۱۶,۴۵۹ جفت مشخصات و ویژگی واقعی TLA+ را پردازش کرد و منجر به بیش از ۳,۰۰۰ اثبات ماشین‌خوان برای ایمنی و زنده بودن شد. همچنین یک مجموعه ارزیابی ۴۰ تسکی برای تست مدل‌های وزن‌باز و بسته روی توانایی تکمیل این اثبات‌های زمانی و شناسایی حالت‌های شکست طراحی شده است.

فراتر از منطق خطی و آینده جست‌وجوی پروتکل

سیستم‌های چندعاملی اغلب به منطق‌های غنی‌تری برای توصیف عامل‌های رقیب یا همکار نیاز دارند. در حالی که TLA+ از LTL استفاده می‌کند، Reasonable به موارد زیر اشاره می‌کند:

• CTL (منطق زمان شاخه‌ای): می‌تواند بیان کند که «از هر حالتی، هنوز می‌توان یک انتخابات جدید را شروع کرد».
• ATL (منطق استراتژیک): می‌تواند بیان کند که «این کامپیوتر استراتژی‌ای دارد تا هر چه دیگران کنند، رهبر شود».

کارهای Benjamin Brast-McKie این جنبه از مسئله را بررسی می‌کند، در حالی که Reasonable در حال حاضر بر اثبات ویژگی‌های زمانی و متصل کردن آن‌ها به برنامه‌ها تمرکز دارد.

وقتی هزینه تأیید رسمی کاهش یابد، می‌توان از «جست‌وجوی پروتکل» (Protocol Search) استفاده کرد. در این حالت، verifier به یک تابع هدف (objective function) تبدیل می‌شود. هوش مصنوعی نسخه‌های مختلف یک پروتکل را تولید می‌کند و فقط آن‌هایی را نگه می‌دارد که به‌صورت رسمی تأیید شده‌اند. این رویکرد مشابه سیستم‌هایی مثل AlphaEvolve است، اما نتایج تخمینی تست را با صحت مطلق رسمی جایگزین می‌کند. این امر مهندسی نرم‌افزار را از چرخه «تست و اصلاح» به چرخه «تعریف و سنتز» تبدیل می‌کند.

سایر احتمالات عبارتند از:

• اثبات‌های تصفیه (Refinement Proofs): خودکارسازی اثبات اینکه پیاده‌سازی Rust از مدل TLA+ پیروی می‌کند تا شکاف بین مدل و نرم‌افزار کاهش یابد.
• سنتز برنامه (Program Synthesis): شروع از مدل برای تولید پیاده‌سازی و اثباتی که نشان دهد کد مدل را تصفیه می‌کند، و استفاده از مشخصات رسمی برای محدود کردن تولید کد و تأیید آن.

برای توسعه‌دهنده، این یعنی پایان عصر «در مدل کار می‌کرد اما در محیط عملیاتی شکست خورد». Reasonable با خودکارسازی پل بین TLA+ و Rust، نرم‌افزارهای با اطمینان بالا را برای تیم‌هایی که دکتری روش‌های رسمی ندارند، در دسترس می‌کند.

منتظر گزارش‌های تفصیلی Reasonable درباره مقایسه مدل‌های وزن‌باز و بسته در تکمیل اثبات‌های زمانی باشید.

گام بعدی شما

• اگر روی سیستم‌های توزیع‌شده کار می‌کنید، یادگیری مفاهیم پایه TLA+ را برای مدل‌سازی منطق سیستم آغاز کنید.
• ابزار Verus را برای پیاده‌سازی‌های Rust بررسی کنید تا متوجه شوید چگونه می‌توان اثبات‌ها را در کنار کد قرار داد.
• منتظر گزارش‌های تفصیلی Reasonable درباره مقایسه مدل‌های وزن‌باز و بسته در تکمیل اثبات‌های زمانی باشید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.