گث وضعیت تاریخی اتریوم را به منبعی قابل‌پیکربندی برای اثبات تبدیل می‌کند

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

این تغییر در طراحی آرشیو گث نسخه ۱.۱۷ دیده می‌شود و در انتشار v1.17.2 نیز بازتاب یافته است. مستندات گث می‌گویند آرشیوهای مبتنی بر مسیر نسبت به روش قدیمی مبتنی بر هش، مصرف فضای کمتر و قابلیت تنظیم بیشتری دارند. همین مستندات توضیح می‌دهند که از نسخه ۱.۱۷ به بعد، eth_getProof برای بلوک‌های تاریخی پشتیبانی می‌شود؛ مشروط بر آن‌که اپراتور گزینه history.trienode را برای نگهداری گره‌های تاریخی تری تنظیم کند.

اهمیت این موضوع از آن‌جاست که eth_getProof فقط یک RPC راحت نیست. پیشنهاد EIP-1186 راهی برای دریافت مقدار حساب و فضای ذخیره‌سازی همراه با اثبات مرکل تعریف می‌کند. اعتبارسنج می‌تواند این اثبات‌ها را با ریشه وضعیت یک بلوک مورداعتماد ترکیب کند تا بررسی کند مقداری مشخص در یک نقطه تاریخی وجود داشته است یا نه؛ بدون آن‌که به پاسخ متنی و تأییدنشده ارائه‌دهنده RPC اعتماد کند. این قابلیت برای کلاینت‌های سبک، بریج‌ها، سامانه‌های حسابرسی و برنامه‌های ZK که پیش از ساخت شاهد مدار به ورودی‌های احراز‌شده نیاز دارند، مفید است.

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

گث v1.17.2 همچنین برای eth_getProof محدودیت تعداد اسلات‌های ذخیره‌سازی اعمال می‌کند. این یک حفاظت عملیاتی کوچک اما معنادار است: درخواست‌های اثبات می‌توانند پرهزینه باشند و RPCای که فهرست‌های نامحدود کلیدهای ذخیره‌سازی را می‌پذیرد، ممکن است هدف مصرف بیش‌ازحد منابع قرار گیرد. این انتشار عمدتاً یک نسخه نگهداری است، نه یک قاعده اجماع جدید در اتریوم؛ بااین‌حال ترکیب محدودیت اثبات و نگهداری تاریخی قابل‌تنظیم، مرز تولید را برای توسعه‌دهندگان روشن‌تر می‌کند.

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

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

نکته احتیاطی: انتشار Geth v1.17.2 در ۳۰ مارس ۲۰۲۶ انجام شده است؛ این مقاله پشتیبانی از اثبات تاریخی را یک تحول جاری در پیاده‌سازی می‌داند، نه استانداردی جدید که در پروتکل اتریوم پذیرفته شده باشد. همچنین اثبات‌های تاریخی به نگهداری صریح گره‌های تری نیاز دارند و داده هرس‌شده قابل‌بازیابی نیست؛ بنابراین این قابلیت به پیکربندی اپراتور وابسته است.