کلید تحول اتریوم: آینده اثبات‌های بازگشتی STARK در دهه آینده

در دهه آینده، اتریوم باید به سه نیاز اصلی امنیت پساکوانتومی، حفظ حریم خصوصی و مقیاس‌پذیری پاسخ دهد.

نویسنده: _deanstef

اتریوم به یک نقطه عطف نزدیک می‌شود.

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

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

با تبدیل شدن اتریوم به زیرساخت کلیدی، باید برای سال‌های آینده تقویت شود و به یک سیستم محاسباتی قوی، ایمن و کارآمد تبدیل شود که در مقیاس (غیرمتمرکز) عمل کند. به‌طور خاص، اتریوم باید:

• در برابر تهدیدهایی که هنوز وجود ندارند، به‌ویژه کامپیوترهای کوانتومی مرتبط با رمزنگاری (CRQCs) مقاوم باشد.
• حریم خصوصی کافی داشته باشد تا نیازهای فعالیت‌های اقتصادی واقعی به محرمانگی را برآورده کند.
• مقیاس‌پذیری را بدون از دست دادن بی‌طرفی، باز بودن و مقاومت در برابر سانسور که باعث موفقیت اولیه آن شده است، محقق کند.

ماموریت بنیاد اتریوم اخیراً از طریق CROPS این چشم‌انداز را مشخص کرده است.

اتریوم باید «مهم‌تر از همه، مقاومت در برابر سانسور، متن باز، حریم خصوصی و امنیت را حفظ کند».

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

نقشه راه strawmap اتریوم یک مسیر تکاملی تدریجی و چندساله را به سمت Lean Ethereum ترسیم می‌کند - نوعی که به اثبات‌های رمزنگاری ساده وابسته است، شبکه را به 10K TPS گسترش می‌دهد و به اصول پساکوانتومی ارتقا می‌دهد، در حالی که پروتکل را بدون از دست دادن غیرمتمرکز بودن دوباره طراحی می‌کند. این فناوری عمدتاً حول STARKs (اثبات‌های شفاف مقیاس‌پذیر) ساخته شده است. STARK نوعی اثبات مبتنی بر هش است که به تنظیمات قابل اعتماد نیاز ندارد؛ قابل توجه است که می‌تواند تجمیع شود و به این ترتیب محاسبات مختلف را به یک اثبات واحد جمع کند.

در این مسیر، من سه پایه تحقیقاتی را می‌بینم:

• امنیت پساکوانتومی، در همه جا: قبل از فشار مهاجرت، برای هر لایه آسیب‌پذیر در برابر حملات کوانتومی در پروتکل آماده باشید.
• حریم خصوصی قابل برنامه‌ریزی: ارائه حریم خصوصی که با قابلیت تأیید و انطباق همزیستی دارد و آن را در زیرساخت خود تعبیه کنید.
• مقیاس‌پذیری: حفظ اجماع، نهایی‌سازی و تأیید به اندازه کافی کارآمد تا دو مورد اول بتوانند بدون کاهش عملکرد شبکه مستقر شوند.

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

امنیت پساکوانتومی

انتقال به اتریوم پساکوانتومی (PQ) باید هر مؤلفه آسیب‌پذیر در برابر حملات کوانتومی در پروتکل موجود را پوشش دهد. همان‌طور که نقشه‌راه Vitalik و مقاله اخیر Nethermind در مورد خطرات کوانتومی خلاصه کرده‌اند، این مؤلفه‌ها شامل امضای ECDSA، اثبات اجماع BLS، تعهد KZG برای blob و SNARK مبتنی بر جفت برای تسویه در L1 هستند. نقطه مشترک آن‌ها دشواری مسئله لگاریتم گسسته بیضوی است، در حالی که الگوریتم شُر می‌تواند این مسئله را در CRQC در زمان چندجمله‌ای حل کند.

گزینه‌های جایگزین در یک طیف توزیع شده‌اند:

• طرح‌های امضای مبتنی بر شبکه (Lattice) (مانند ML-DSA، Falcon) امضاها را نسبتاً کوچک نگه می‌دارند، اما هزینه‌های تأیید در زنجیره بالاست و بیش از یک میلیون Gas است و نظریه تجمیع آن‌ها هنوز ناپخته است.
• طرح‌های امضای مبتنی بر هش تنها به امنیت تابع هش زیرین وابسته‌اند، اما به قیمت حجم: اندازه امضا به چند کیلوبایت می‌رسد و هزینه تأیید امروزه ممکن است به صدها هزار Gas برسد. آن‌ها به دو نوع تقسیم می‌شوند: انواع دارای حالت، مانند XMSS، که حجم کمتری دارند اما از امضاکننده می‌خواهند که وضعیت کلید را پیگیری کند؛ و انواع بدون حالت، مانند SPHINCS+، که حجم بیشتری دارند و تأیید آن‌ها گران‌تر است، اما نیازی به مدیریت وضعیت ندارند.
• سیستم‌های اثبات STARK مبتنی بر تابع هش در مدل پیشگوی تصادفی هستند. آن‌ها شفاف، به‌طور ذاتی پساکوانتومی و نیازی به تنظیمات قابل اعتماد ندارند. هزینه آن‌ها حجم و هزینه تأیید است. یک STARK شامل هزاران هش مسیر مرکل است، بنابراین اندازه هر اثبات به ده‌ها تا صدها کیلوبایت می‌رسد؛ در حالی که با استفاده از اثبات‌کنندگان امروزی، هزینه تأیید در زنجیره می‌تواند به میلیون‌ها واحد Gas برسد که یک مرتبه بیشتر از هزینه Gas مبتنی بر جفت SNARK است.

به‌طور کلی، در لایه‌های مختلف پروتکل اتریوم پذیرش اصول PQ، چالش‌های اصلی ناشی از امضاها و اثبات‌های بزرگ‌تر، تأیید گران‌تر و پروتکل‌های پیچیده‌تر است:

اجماع

مقیاس مجموعه تأییدکنندگان اتریوم پویا است و در هر slot حدود 1/32 تأییدکننده‌ها در حال اثبات (attest) هستند. تجمیع BLS رأی آن‌ها را در زنجیره به حداقل 8 امضای 96 بایتی فشرده می‌کند و همین تجمیع است که مقیاس چنین مجموعه تأییدکنندگانی را ممکن می‌سازد. با این حال، در برابر CRQC، کلید خصوصی تأییدکننده می‌تواند از کلید عمومی آن استنتاج شود، بنابراین، دشمنی که کلید عمومی تأییدکننده را در اختیار دارد می‌تواند اثبات‌های آن‌ها را جعل کند و در نهایت یک زنجیره نامعتبر را نهایی کند. یک جایگزین طبیعی پساکوانتومی، طرح‌های هش دارای حالت، مانند XMSS است، زیرا تأییدکنندگان می‌توانند در حین امضای اجماع به‌طور ایمن وضعیت کلید خود را مدیریت کنند. با این حال، XMSS نمی‌تواند مانند BLS تجمیع شود؛ در شرایطی که حدود یک میلیون تأییدکننده وجود دارد، هر slot به‌طور جداگانه به حدود 31,000 امضای PQ نیاز دارد. با محاسبه هر امضا به‌طور تقریبی 3 کیلوبایت، حجم داده هر slot حدود 90 مگابایت خواهد بود که چندین مرتبه بیشتر از سطحی است که تجمیع امروزی می‌تواند به آن برسد. در سناریوهای نهایی‌سازی در یک slot، وضعیت بدتر خواهد بود. برای نهایی‌سازی هر بلوک در slot‌های مربوطه، نیاز است که کل مجموعه تأییدکنندگان در هر slot اثبات کنند و حجم داده‌های امضا به GB می‌رسد.

حساب‌ها

حساب‌های کاربری از ECDSA برای تأیید هویت استفاده می‌کنند. به محض اینکه یک حساب معامله‌ای را آغاز کند، کلید عمومی آن افشا می‌شود، بنابراین CRQC می‌تواند کلید خصوصی را بازیابی کند و به‌نام مالک معامله را امضا کند و به‌طور دلخواه وجوه را تخلیه کند. جایگزینی آن اجتناب‌ناپذیر است، اما حساب‌های خارجی (EOA) نمی‌توانند مانند تأییدکنندگان وضعیت امضا را مدیریت کنند، بنابراین به طرح‌های بدون حالت نیاز دارند که هزینه تأیید امضا را به لایه اجرایی منتقل می‌کند. در حال حاضر برنده مشخصی وجود ندارد. کار بنیاد EF بر روی طرح هش بدون حالت SPHINCS+ متمرکز است، اگرچه طرح‌های مبتنی بر شبکه هنوز در حال بررسی هستند که به‌طور عمده به هزینه تأیید بستگی دارد. هزینه تأیید SPHINCS+ در EVM بسیار بالاست و به همین دلیل برخی از کارها به‌دنبال ارزان‌تر کردن خود طرح‌های بدون حالت هستند: SPHINCS-minus یک تأییدکننده بومی keccak است؛ در حالی که کارهای دیگر آن را دور می‌زنند و از انتزاع حساب برای چرخش کلیدهای یک‌بار مصرف استفاده می‌کنند تا هر امضا بتواند از طرح‌های یک‌بار مصرف ارزان‌تری استفاده کند.

Rollups

Rollup با انتشار اثبات‌های اعتبارسنجی در L1 تسویه می‌شود. ارزان‌ترین روش تأیید امروزی مبتنی بر SNARK‌های جفت است: اثبات‌ها تنها چند صد بایت هستند و هزینه تأیید حدود 200--500k Gas است. CRQC فرضیات جفتی را که به آن‌ها وابسته‌اند، خراب می‌کند، بنابراین مهاجم می‌تواند اثبات‌های اعتبارسنجی از تغییر وضعیت‌هایی که هرگز اتفاق نیفتاده‌اند را جعل کند و L1 آن را بپذیرد و وضعیت تقلبی rollup و برداشت‌های آن را نهایی کند. این همچنین بسیاری از تکنیک‌هایی را که rollup برای حفظ هزینه‌های پایین به آن‌ها وابسته است، بی‌اثر می‌کند، مانند بسته‌بندی بزرگ STARK در یک SNARK نهایی کوچک برای تسویه، زیرا آن بسته‌بندی بیرونی نیز مبتنی بر جفت است. بدون آن، rollup باید به‌طور مستقیم در L1 STARK را تأیید کند، که هزینه آن به میلیون‌ها واحد Gas می‌رسد و بیش از یک مرتبه بیشتر از SNARK است. حفظ هزینه تأیید STARK در حال حاضر یک مسئله تحقیقاتی باز است.

قابلیت دسترسی به داده‌ها

blob اتریوم از تعهد KZG استفاده می‌کند که یک طرح تعهد چندجمله‌ای است و برای هر blob 128 کیلوبایتی یک تعهد 48 بایتی تولید می‌کند. KZG برای نمونه‌برداری از قابلیت دسترسی به داده‌ها آسان است، زیرا (i) اندازه ثابت ورودی را فراهم می‌کند، بنابراین هزینه تأیید هر نمونه پایین است، (ii) خطی است و از نمونه‌برداری 2D پشتیبانی می‌کند و (iii) قابل تعمیر است، زیرا کدهای آسیب‌دیده می‌توانند بر اساس همان تعهد تعمیر شوند. متأسفانه، KZG نیز مبتنی بر جفت است، بنابراین CRQC می‌تواند ورودی‌ها را جعل کند و داده‌های غیرقابل دسترسی را به‌عنوان داده‌های قابل دسترسی معرفی کند. جایگزینی ایمن در برابر کوانتوم باید از تعهدات مبتنی بر هش ناشی شود، اما مسئله این است که چه مقدار از تضمین‌های KZG می‌تواند حفظ شود. گزینه‌های موجود پساکوانتومی با چالش‌های مختلفی در زمینه کارایی محاسباتی و شبکه مواجه هستند و دارای اندازه‌های تعهد بزرگ‌تر و هزینه‌های تأیید و اثبات در حال افزایش هستند. FRIDA یک طرح DAS شفاف مبتنی بر FRI است که بر روی کدهای Reed-Solomon یک بعدی ساخته شده است و نمونه‌بردار آن نزدیکی به کد را آزمایش می‌کند. هزینه آن پهنای باند است: نمونه‌های KZG تنها به یک ورودی با اندازه ثابت نیاز دارند، در حالی که هر نمونه FRIDA شامل یک اثبات کامل نزدیکی است و بنابراین هر نمونه بزرگ‌تر است. ZODA یک گزینه دیگر برای کدگذاری 2D است که به هر ردیف و ستونی که نمونه‌برداری می‌شود، خودگواهی می‌دهد و پیوند دقیقی با داده‌های تعهد شده ایجاد می‌کند، اما این تضمین محلی و نمونه‌ای است (فقط مکان‌هایی را که گره‌ها پرس‌وجو کرده‌اند پوشش می‌دهد) و نمونه‌برداری نیاز به دانلود کل ردیف و ستون کدگذاری شده دارد. روش سوم بسته‌بندی کد در STARK است. ایده این است که در zkVM اثبات شود که داده‌های تعهد شده یک کد معتبر Reed-Solomon است. بنابراین یک اثبات می‌تواند کل کدگذاری را به‌طور دقیق تأیید کند - نه نزدیکی و نه نمونه به نمونه - و نیازی به تنظیمات قابل اعتماد ندارد. هزینه آن از نظر توان اثبات است. طراحی leanDA بنیاد EF و تحقیقات مربوط به آن این روش را اندازه‌گیری کرده‌اند: در حال حاضر بر روی یک CPU پیشرفته، توان اثبات حدود 0.9 MiB/s است و گاهی به حدود 1 MiB/s می‌رسد. تحقیقات فعلی در حال تلاش است تا آن را به اندازه کافی سریع کند.

جهت‌گیری‌های تحقیقاتی

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

کارایی پروتکل، در دو جنبه:

• تجمیع امضای PQ. هدف این است که تعداد زیادی از امضای بزرگ PQ را به یک اثبات واحد ادغام کنیم تا هزینه‌ها در مسیر کلیدی پروتکل (به ویژه در اجماع) پایین بماند. leanVM EF توانسته است امضای XMSS را با سرعت تقریبی 1480 امضا در ثانیه به اثباتی کمتر از 200 KiB تجمیع کند و این اثبات‌ها می‌توانند به‌طور بازگشتی دوباره ترکیب شوند، بنابراین امضاها می‌توانند به‌طور موازی تجمیع شده و سپس به هم ادغام شوند. سوال باز این است: آیا می‌توان پروتکلی طراحی کرد که در مسیر رسیدن به نهایی‌سازی یک اسلات (یعنی کل مجموعه تأییدکنندگان در هر اسلات اثبات انجام دهند) و همچنین در کوتاه‌ترین زمان ممکن برای اسلات، همچنان عملی باشد؛ علاوه بر این، چه کسی این اثبات‌ها را تولید می‌کند و انگیزه‌های مربوطه چیست؟
• تأیید هویت تراکنش. Frames (EIP-8141) به حساب‌ها اجازه می‌دهد تا کد خود را برای مجوز تراکنش‌ها حمل کنند و تأیید امضا را از لایه پروتکل خارج کرده و به منطق سفارشی حساب‌ها منتقل کنند. تأیید دیگر به امضای ثابت ECDSA وابسته نیست و هر حساب می‌تواند طرح خود را انتخاب کند. جهت‌گیری‌هایی که باید بررسی شوند این است که این تأیید چگونه کار می‌کند: آیا از طریق پیش‌کامپایل‌های تنظیم‌شده برای هر طرح در زنجیره انجام می‌شود یا از طریق اثبات‌های پساکوانتومی و قابل تجمیع. دومی توسط EIP-8288 بررسی می‌شود که امضای بسیاری از تراکنش‌ها را به یک امضا ادغام می‌کند و حتی با افزایش تعداد تراکنش‌های PQ، اندازه اثبات هر بلوک و پهنای باند mempool را ثابت نگه می‌دارد.

کارایی رمزنگاری. کاهش اندازه و هزینه تأیید امضای PQ؛ به عنوان مثال، هزینه تأیید SPHINCS-minus در EVM حدود 94k Gas است. به طور ایده‌آل، جامعه تحقیقاتی باید امضایی طراحی کند که با zk سازگار باشد تا بتوان آن را به‌طور مؤثر در zkVM اثبات کرد (EF در کار بر روی leanSPHINCS به این سمت پیش می‌رود).

زیرساخت اثبات. هزینه اثبات‌های PQ عمدتاً توسط عملیات هاش زیرساخت تعیین می‌شود. تابع‌های هاش استاندارد اثبات (مانند Keccak، SHA) عملیات غیر بومی هستند و باید به صورت عددی انجام شوند که این امر هزینه محاسباتی را به همراه دارد. دو مسیر در حال بررسی است: هاش‌های سازگار با SNARK، مانند Poseidon (سریع است، اما آزمایش‌های میدانی کمتری را تحمل کرده است) و سیستم‌های اثباتی که به‌طور مستقیم عملیات غیر بومی را پردازش می‌کنند، به طوری که رمزنگاری استاندارد می‌تواند بدون شبیه‌سازی میدان‌های پرهزینه اثبات شود. برای دومی، پیشرفت‌های تحقیقاتی سریع است و کارهای اخیر مانند Zinc+ و تعهدات مدول بر روی اعداد صحیح وجود دارد.

زیرساخت‌های پساکوانتومی وجود دارند، اما حجم داده‌های آن‌ها بیشتر و هزینه تأیید آن‌ها بالاتر است. هدف تحقیقاتی این است که آن‌ها را در سطح پروتکل فعلی عملی کند. به عنوان مثال، امضای بسیار بزرگ در mempool عمومی باعث می‌شود که هر کلاینت باید حجم داده‌های ذخیره و تأیید شده را به‌طور انفجاری افزایش دهد و تأیید این امضاها هزینه بیشتری Gas خواهد داشت و بار مالی را بر دوش کاربران و تأییدکنندگان می‌گذارد. فناوری کلیدی بر روی اثبات STARK متمرکز است که می‌تواند به‌طور مؤثر تجمیع شود و هزینه داده و پیچیدگی تأیید را از O(n) به O(1) کاهش دهد. کلاینت دیگر n امضای مختلف PQ را پردازش و تأیید نمی‌کند، بلکه فقط یک اثبات تجمیع شده را پردازش می‌کند. و همین ویژگی است که مقیاس‌پذیری را آزاد می‌کند، که موضوع بعدی ما خواهد بود.

حریم خصوصی قابل برنامه‌ریزی

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

استخرهای حریم خصوصی برای مصرف‌کنندگان، مانند RAILGUN و Privacy Pools، حریم خصوصی را به کیف پول‌های عادی می‌آورند؛ در حالی که پلتفرم‌های سازمانی، مانند Paladin، حریم خصوصی قابل برنامه‌ریزی و آماده انطباق را برای سازمان‌ها فراهم می‌کنند. اما در حال حاضر هیچ راه‌حلی وجود ندارد که همزمان هم سطح سازمانی و هم به آسانی کیف پول‌های عادی باشد؛ و همچنین، استفاده از هر یک از آن‌ها به معنای پردازش وضعیت‌های خارج از زنجیره (مانند درخت مرکل، غیرمعتبرکننده‌ها و کلیدهای رمزنگاری) و تولید اثبات‌های دانش صفر برای هر عمل است. نقشه‌راه حریم خصوصی Vitalik و نقشه‌راه حریم خصوصی pcaversaccio به خوبی جهت‌گیری‌های تحقیقاتی موجود در اتریوم را خلاصه می‌کند. این جهت‌گیری‌ها را می‌توان به چهار بعد بالاتر تقسیم کرد:

قابلیت استفاده

در اینجا دو سوال وجود دارد. اول، ساخت یک تراکنش حریم خصوصی باید مانند ارسال یک تراکنش عادی احساس شود، اما امروز نیاز به تراکنش‌های به‌طور خاص ساخته شده، وضعیت‌های خارج از زنجیره که باید پیگیری شوند و اثبات‌های دانش صفر که باید تولید شوند دارد. دوم، باید هزینه کمی داشته باشد، اما یک انتقال حریم خصوصی یک SNARK را بسته‌بندی می‌کند، بنابراین نسبت به انتقال‌های عمومی داده بیشتری و هزینه تأیید بالاتری را به همراه دارد و به محض اینکه امضای پساکوانتومی و اثبات‌ها اضافه شوند، این فاصله فقط بیشتر خواهد شد. چارچوب‌های استانداردسازی مانند Kohaku و Paladin که می‌توانند این پیچیدگی را پنهان کنند، در حال شروع به حل سوال اول هستند، هرچند که هر دو هنوز در مراحل اولیه هستند و به‌طور فعال در حال توسعه هستند. سوال دوم به تجمیع اثبات‌ها بستگی دارد (پیشنهاد برای EIP-8288)، که یک روش اقتصادی برای ادغام بسیاری از اثبات‌های تراکنش به یک اثبات و تقسیم هزینه تأیید است.

عدم نیاز به اعتماد و مقاومت در برابر سانسور

امروز بسیاری از پروتکل‌های حریم خصوصی به واسطه‌ها (relayers) وابسته هستند تا به نمایندگی از کاربران تراکنش‌ها را ارسال کنند، که این یک واسطه قابل اعتماد است که می‌تواند سانسور، تأخیر یا ناشناس‌سازی کند. حذف این وابستگی هدف است. تراکنش‌های Frame (EIP-8141) سنگ‌بنای این امر هستند: آن‌ها «چه کسی تراکنش را مجاز می‌کند» را از «چه کسی هزینه Gas را پرداخت می‌کند و چگونه اجرا می‌شود» جدا می‌کنند، بنابراین پرداخت‌کننده می‌تواند با امضاکننده متفاوت باشد و هزینه‌های پنهان دیگر نیازی به یک حساب با اعتبار مالی و مرتبط با هویت برای ورود به زنجیره ندارد. دو بخش مکمل این شکاف را پر می‌کنند. EIP-8250 با کلیدهای تصادفی، دامنه تصادفی مستقل را فراهم می‌کند، بنابراین عملیات پنهان یک فرستنده واحد با یکدیگر تداخل نمی‌کند؛ ریشه‌های اخیر (EIP-8272) به تراکنش‌ها اجازه می‌دهد تا ریشه مرکل را که اثبات آن‌ها بر اساس آن است، اعلام کنند، بنابراین با پیشرفت درخت، اثبات همچنان معتبر است. آن‌ها به‌طور مشترک یک مرجع تأیید پایدار و درون پروتکلی برای تراکنش‌های پنهان فراهم می‌کنند، بنابراین اعتبار آن‌ها به وضعیت‌های سریع‌التحول وابسته نیست و هر کسی می‌تواند به‌طور غیرهمزمان بررسی کند. در مورد لیست‌های اجباری شامل FOCIL (EIP-7805)، شامل‌کنندگان می‌توانند اعتبار این تراکنش را به‌طور مستقل تأیید کنند و درخواست کنند که آن‌ها شامل شوند و بنابراین تضمین‌های مقاومت در برابر سانسور را ارائه دهند که روش‌های مبتنی بر واسطه نمی‌توانند ارائه دهند.

بازیابی داده‌ها

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

حریم خصوصی درون پروتکلی

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

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

چالش‌ها و ستون سوم

این دو ستون یک ویژگی مشترک دشوار دارند: آن‌ها از نظر رمزنگاری هزینه‌بر هستند.

1. امضای PQ بزرگتر و گران‌تر از طرح‌های منحنی بیضوی هستند که جایگزین آن‌ها می‌شوند.
2. پروتکل‌های حریم خصوصی به‌طور کامل به اثبات‌های سنگین وابسته هستند که پیچیدگی و هزینه را برای کاربران افزایش می‌دهد.

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

همیشه یک پاسخ تکراری وجود دارد. امضای پساکوانتومی در STARK‌های بازگشتی ادغام می‌شود، قابلیت دسترسی داده‌های ایمن در برابر کوانتوم آن را در یک STARK کدگذاری می‌کند، انتقال‌های حریم خصوصی اثبات‌های خود را در یک STARK دیگر بسته‌بندی می‌کنند، در حالی که rollup‌ها در حال حاضر به این روش تسویه می‌شوند. سوال مکرر این است: چگونه می‌توانیم رمزنگاری قوی‌تری را با هزینه‌ای قابل قبول تأمین کنیم؟ این سوال هر بار به یک سوال متمرکزتر برمی‌گردد:

ما چگونه می‌توانیم STARK را با کمترین هزینه و بالاترین کارایی تجمیع و تأیید کنیم؟

گسترش لایه پایه

نقشه‌راه مبتنی بر rollup، اجرا را از L1 خارج کرده و به اتریوم اجازه می‌دهد تا بر اجماع، تسویه و قابلیت دسترسی داده‌ها تمرکز کند. اما گسترش نمی‌تواند در لایه 2 متوقف شود. هر rollup همه چیز را از لایه پایه به ارث می‌برد: اجماع، نهایی‌سازی، تأیید و قابلیت دسترسی داده‌ها، بنابراین بهبود لایه پایه به معنای بهبود همه چیزهایی است که بر اساس آن ساخته شده است.

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

اجرا

اجرا، یعنی پردازش تعداد بیشتری از تراکنش‌ها در زمان کمتر. تجمیع اثبات‌ها به کلاینت‌های اجرایی اجازه می‌دهد تا تأیید تعداد زیادی از تراکنش‌ها را به یک STARK واحد فشرده کنند، در حالی که این تراکنش‌ها نیازی به یک نوع خاص ندارند. تأیید امضای پساکوانتومی، انتقال‌های حریم خصوصی و تسویه rollup می‌توانند به یک تجمیع واحد ادغام شوند. به همین دلیل است که تراکنش‌های Frame - که به حساب‌ها اجازه می‌دهد منطق تأیید تراکنش خود را تعریف کنند، به جای اینکه امضاهای سخت‌افزاری را کدگذاری کنند - در ترکیب با تجمیع اثبات‌ها برای لایه اجرایی بسیار مهم است. هر تراکنش از طریق Frame الزامات بررسی مورد نیاز را به‌عنوان یک الزام اعلام می‌کند و سازنده در یک STARK بازگشتی کل دسته را پردازش می‌کند، به جای اینکه هر گره به‌طور داخلی هر بررسی را تأیید کند. نوع Frame پیشنهادی برای تجمیع امضای PQ و STARK (EIP-8288) این را مشخص می‌کند، هزینه «فقط توسط سازنده و mempool پرداخت می‌شود، نه توسط همه گره‌های تأیید»؛ همان ایده همچنین در زمان افزایش حجم اثبات‌ها، پهنای باند mempool را ثابت نگه می‌دارد.

اجماع

اجماع خود شامل چندین مسئله است و STARK به هر یک از آن‌ها کمک می‌کند.

توان عملیاتی

تولید بلوک‌های بزرگ‌تر بدون افزایش هزینه‌های تأیید. هنگامی که تأییدکنندگان صحت اثبات را بررسی می‌کنند، به جای اجرای مجدد بلوک، سازندگان می‌توانند در حالی که داده‌های زیرین را نگه می‌دارند، اثبات‌های معتبر را منتشر کنند، بنابراین باید به‌طور صریح اطمینان حاصل شود که داده‌ها در دسترس هستند. جهت blocks-in-blobs معاملات را در blob بسته‌بندی می‌کند و تأییدکنندگان به نمونه‌برداری از قابلیت دسترسی می‌پردازند، نه اینکه بار کامل را دانلود کنند؛ STARK پیشنهاددهنده به‌منظور اثبات این است که بلوک به‌درستی اجرا شده و به‌طور صحیح کدگذاری شده است. به این ترتیب، هزینه تأیید با گسترش اثبات افزایش می‌یابد، نه با افزایش اندازه بلوک.

زمان Slot

با جداسازی زنجیره‌های قابل دسترس از مکانیزم نهایی، فاصله بین بلوک‌ها را کاهش دهید. یک کمیته کوچک که به‌طور تصادفی انتخاب شده است، به‌طور مداوم بلوک‌ها را در مسیر کلیدی تولید می‌کند، مانند لایه سریع LMD-GHOST با چند صد تأییدکننده و طراحی اجماع جداسازی شده؛ در حالی که مجموعه کامل تأییدکنندگان به‌طور موازی در خارج از مسیر کلیدی نهایی‌سازی را انجام می‌دهند. هر مرحله شامل تأییدکنندگان کمتری است، به این معنی که تجمیع STARK در مسیر داغ کمتر و زمان slot کوتاه‌تر است.

نهایی‌سازی

زمان نهایی‌سازی که امروزه حدود شانزده دقیقه است، کاهش می‌یابد، به‌عنوان مثال از طریق نهایی‌سازی یک دور، یک دور رأی‌گیری را از مسیر کلیدی حذف می‌کند.

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

STARK دوباره به‌عنوان راه‌حل ظاهر می‌شود: فشرده‌سازی و تجمیع کل مجموعه تأییدکنندگان در زمان هدف slot. طراحی زنجیره حداقلی همان فناوری را به وضعیت اجماع منتقل می‌کند: اجازه دادن به هر تأییدکننده برای اثبات موجودی و وضعیت خود، کاهش وضعیت هر تأییدکننده به چند بایت، که راهی به سوی میلیون‌ها تأییدکننده است.

این دقیقاً جایی است که STARK بازگشتی به‌عنوان پایه زیرساخت پروتکل تبدیل می‌شود. ترکیب این اجزا------تجمیع اجرایی، اثبات blocks-in-blobs و اثبات‌های پساکوانتومی تجمیع شده------جهت‌گیری تحقیقاتی است که باید در مرحله بعدی پیش برود.

* محور سوم لایه داده‌های مقیاس‌پذیری است، اما این به‌طور دقیق با کار تحقیقاتی PQ DA مرتبط است.

چشم‌انداز آینده

نقشه راه نامشخص است، تحقیقات هرگز خطی نیستند. اما برخی از وابستگی‌ها به‌نظر محکم می‌رسند.

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

آیا تجمیع STARK می‌تواند اتریوم را تحمل کند، بستگی به چندین سؤال خاص و هنوز باز دارد:

• تجمیع امضاهای ناهمگن. اثبات و ترکیب امضاهای مختلف PQ در یک تجمیع، به‌عنوان مثال، تجمیع امضاهای مبتنی بر هش و امضاهای مبتنی بر شبکه در یک STARK. لایه حساب‌ها یک طرح واحد را انتخاب نمی‌کند، بنابراین تجمیع باید مستقل از طرح خاص باشد.
• اثبات هش به‌طور کارآمد. هزینه اثبات تحت تأثیر هش زیرین است و نیاز به توان عملیاتی هنوز به‌دور از نیازهاست. این تعادل در این است: اثبات هش‌های آزمایش‌شده در عمل (مانند Keccak و SHA) در دامنه‌های غیر بومی هزینه‌های محاسباتی را به همراه دارد؛ در حالی که هش‌های دوستانه zk (مانند Poseidon2) هزینه اثبات کمتری دارند، اما تحلیل رمزنگاری کمتری را تحمل می‌کنند.
• تجمیع بین دامنه‌ای. ترکیب انواع مختلف STARK در یک اثبات بازگشتی------از تأیید امضای PQ، انتقال‌های خصوصی تا تغییر وضعیت rollup------به کل پشته اجازه می‌دهد که همان بار تأیید را به اشتراک بگذارد.
• سازگاری تجمیع با اجماع. به‌طور مستقیم با الزامات زمانی اجماع مواجه شوید: در شرایطی که در یک slot واحد و زمان slot به‌طور مداوم کاهش می‌یابد، مجموعه کامل تأییدکنندگان را تجمیع کنید و بهترین تعادل را بین اندازه کمیته، طول slot و نهایی‌سازی پیدا کنید.
• آمادگی پروتکل. اطمینان حاصل کنید که زیرساختی که این تجمیع‌ها را حمل می‌کند، همزمان در سطح mempool (به‌عنوان مثال با استفاده از Frame و EIP-8288) و در سطح اجماع وجود دارد: در مقیاس میلیون‌ها تأییدکننده، اثبات STARK امضای PQ هر تأییدکننده نیز باید تجمیع شود، درست مانند امضاهای BLS امروز.
• انگیزه‌ها را درست کنید. تجمیع فقط هزینه‌ها را منتقل می‌کند و آن‌ها را حذف نمی‌کند: کار اثبات به سازندگان بلوک متمرکز می‌شود، که مسائل واقعی درباره انگیزه‌ها و تمرکز را به وجود می‌آورد.

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