مناظره پروتکل: پنج چشم‌انداز برای OrcaRail کاملاً غیرامانی
۲۰ آوریل ۲۰۲۶ — نقشه راه غیرامانی که هفته گذشته منتشر کردیم یک مسیر را توصیف می‌کند: قرارداد هوشمند روی هر زنجیره، keeper تحت اداره OrcaRail، ایندکسر تحت اداره OrcaRail و API تحت اداره OrcaRail. این مسیر امانت‌داری را حذف می‌کند، اما ما را در میانه تقریباً همه چیزهای دیگر نگه می‌دارد.
چند نفر از خوانندگان به‌درستی پرسیدند: اگر هدف تبدیل شدن به یک پروتکل است، چرا فقط به حذف امانت‌داری بسنده کنیم؟ اگر OrcaRail فردا خاموش شود و پرداخت‌ها همچنان جریان داشته باشند، زیرساخت چه شکلی خواهد داشت؟
این مطلب یک مناظره است. پنج موضع از پنج معماری متفاوت دفاع می‌کنند. یک گرداننده هر کدام را به چالش می‌کشد. هیچ‌کس به‌طور کامل برنده نمی‌شود، اما در پایان روشن‌تر می‌دانیم واقعاً چه بده‌بستان‌هایی را انتخاب می‌کنیم.
«پروتکل کاملاً غیرامانی» دقیقاً یعنی چه
پیش از شروع مناظره به یک تعریف مشترک نیاز داریم. یک سیستم وقتی پروتکل کاملاً غیرامانی است که همه این شرایط برقرار باشند:
- امانت‌داری: هیچ طرفی وجوه کاربران را در حال انتقال نگه نمی‌دارد، حتی برای یک بلاک.
- زنده‌بودن: برای انجام یک پرداخت یا برداشت مشروع اشتراک، به هیچ طرف واحدی نیاز نیست.
- مقاومت در برابر سانسور: هیچ طرف واحدی نمی‌تواند تراکنش درست‌ساخت و پرداخت‌شده را رد کند.
- کنترل ارتقا / تغییر: ارتقاها به رضایت چند طرف نیاز دارند، نه استقرار یک شرکت.
- شفافیت: قواعدی که کاربر به آن‌ها اعتماد می‌کند به‌طور کامل روی زنجیره یا زیر یک هش قابل تأیید خواندنی‌اند.
برنامه فعلی شرط (۱) را برآورده می‌کند. شرط‌های (۳)، (۴) و (۵) را تا حدی برآورده می‌کند. شرط (۲) را برآورده نمی‌کند؛ keeper و API اورکاریل هنوز برای اجرای قابل‌اعتماد مسیر عادی لازم‌اند. مناظره زیر درباره این است که آیا چهار معیار باقی‌مانده را تا انتها پیش ببریم و با چه هزینه‌ای.
مواضع
پنج معمار وارد می‌شوند. بیایید حرفشان را بشنویم.
- عمل‌گرا — قرارداد هوشمند + API اورکاریل (نقشه راه فعلی).
- حداکثرگرا — پروتکل کاملاً روی زنجیره + فرانت‌اند غیرمتمرکز («مدل Uniswap»).
- مستقل — OrcaRail به‌عنوان یک لایه ۳ / appchain با پیش‌کامپایل‌های مخصوص پرداخت.
- باورمند به intent — پرداخت‌کنندگان intent بیان می‌کنند؛ یک شبکه solver بدون نیاز به مجوز آن‌ها را تسویه می‌کند.
- مدافع استاندارد — یک EIP باز برای لینک پرداخت و اشتراک؛ هر کسی پیاده‌سازی می‌کند.
دور ۱: بیانیه‌های آغازین
عمل‌گرا: «چیز واقعی منتشر کن، بعد بخش‌های دردناک را غیرمتمرکز کن.»
نقشه راه همین حالا مسئله سخت (امانت‌داری) را حذف می‌کند. keeper می‌تواند هر کسی باشد؛ زمان‌بند NestJS ما یکی از چند فراخواننده است و Chainlink و Gelato را می‌توان فردا ثبت کرد. ایندکسر عمومی است: هر کسی می‌تواند مشترک همان رویدادهای Paid و Charged شود و وضعیت را بازسازی کند. «API اورکاریل» لایه تسویه نیست؛ یک لایه راحتی روی قراردادهای عمومی است. فروشندگانی که مسیر کاملاً پروتکلی را می‌خواهند، همین حالا هم می‌توانند ما را دور بزنند و مستقیم کارخانه را فراخوانی کنند.
ادعا: ما ۸۰٪ پروتکل هستیم. ۲۰٪ باقی‌مانده ابزار است (کیف پول، داشبورد، ایمیل)، نه اعتماد. ابزارها باید قابل تکرار و بهبود بمانند.
حداکثرگرا: «بدون API. رویداد، قرارداد، subgraph. همین.»
Uniswap وجود دارد. 1inch وجود دارد. از طریق فرانت‌اندهایی که شرکت‌هایشان میزبانی می‌کنند به آن‌ها دسترسی دارید، اما هر کدام از این فرانت‌اندها می‌تواند خاموش شود و پروتکل همچنان کار کند. «پروتکل» یعنی همین.
برای OrcaRail، این یعنی:
- کارخانه‌ها، هاب‌ها و تقسیم‌کننده‌ها روی همه زنجیره‌های EVM/سولانا.
- یک subgraph مرجع (یا ایندکسر سولانا) که هر کسی بتواند پرس‌وجو کند.
- یک فرانت‌اند غیرمتمرکز سنجاق‌شده روی IPFS/Arweave که از طریق ENS (
orcarail.eth) بازیابی می‌شود. داشبورد فروشنده و اپ پرداخت بسته‌های ایستا هستند؛ هر انتشار مبتنی بر محتوا آدرس‌دهی می‌شود. - هیچ REST API اورکاریلی در مسیر حیاتی نیست. SDK مستقیم subgraph را صدا می‌زند. وب‌هوک‌ها توسط ایندکسر به‌عنوان سرویس (Alchemy، QuickNode، روی سرور خود) از رویدادهای روی زنجیره مشتق می‌شوند.
ادعا: هر چیزی که برای کار کردن پرداخت به api.orcarail.com نیاز داشته باشد، پروتکلی ناقص است.
مستقل: «پرداخت را به یک پیش‌کامپایل روی زنجیره خودمان تبدیل کن.»
پرداخت‌ها به تأخیر حساس و تکراری‌اند. هر بار برای همان تقسیم همان گس را می‌پردازیم. چرا امنیت L1/L2 را برای کاربردی اجاره کنیم که می‌شود تخصصی‌اش کرد؟
زنجیره OrcaRail را به‌صورت یک رول‌آپ OP Stack (یا appchain کازماس، یا زنجیره Arbitrum Orbit) راه بیندازیم. آن‌وقت:
- معنای لینک پرداخت یک پیش‌کامپایل است، نه یک قرارداد ۸۰ خطی Solidity. کارمزدها از چند سنت به تقریباً صفر می‌رسند.
- منطق keeper در تولید بلاک گنجانده می‌شود: sequencer فراخوانی‌های
charge()را به‌عنوان بخشی از بلاک اجرا می‌کند و با امنیت خود زنجیره قابل جریمه است. - پل به زنجیره‌های «واقعی» (اتریوم، Arbitrum، سولانا) از پل مرجع موجود + Relay استفاده می‌کند؛ زنجیره OrcaRail لایه هماهنگی است، نه لایه ارزش.
- اشتراک‌ها به شهروند درجه یک تبدیل می‌شوند؛ «اشتراک» یک نوع تراکنش است، مثل «انتقال» در بیت‌کوین.
ادعا: ارزان‌ترین راه برای اینکه یک پروتکل در مقیاس بالا قابل‌اعتماد کار کند، این است که فضای بلاک را با mintهای تصادفی NFT شریک نشود.
باورمند به intent: «پرداخت‌کنندگان قصدشان را بیان می‌کنند. solverها برای تسویه رقابت می‌کنند.»
پرداخت‌کننده می‌گوید: «می‌خواهم ۵۰ دلار USDC از هر کدام از کیف پول‌هایم، ظرف ساعت آینده و با کمترین کارمزد، به فروشنده X بپردازم.» این یک intent است؛ امضاشده اما هنوز تراکنش نیست.
یک شبکه solver بدون نیاز به مجوز (به سبک CoW، SUAVE، Anoma، relayerهای شبیه Across) intent را می‌بیند، ارزان‌ترین مسیر را پیدا می‌کند (شامل پل‌زدن و بین‌زنجیره‌ای، از هر توکنی که پرداخت‌کننده دارد) و آن را تسویه می‌کند. به solverها پاداشی پرداخت می‌شود که در intent گنجانده شده است.
برای اشتراک‌ها: پرداخت‌کننده یک intent دوره‌ای امضا می‌کند («ماهانه ۲۰ دلار USDC از کیف پولم به PDA این فروشنده برداشت کن، به مدت ۱۲ ماه، قابل لغو در هر زمان»). solverها رقابت می‌کنند تا هنگام سررسید charge() را فراخوانی کنند و کارمزد کوچکی بگیرند. اگر کمی دقیق شوید، «AVS برای keeper» در مرحله ۶ به همین تبدیل می‌شود؛ اما با یک بازار واقعی به‌جای طرح جریمه.
ادعا: keeperها واقعاً مسئله قابلیت اطمینان نیستند؛ مسئله طراحی بازارند. بازار را بسازیم.
مدافع استاندارد: «یک EIP بنویس. همه برنده‌اند، از جمله ما.»
لینک‌های پرداخت و اشتراک‌های OrcaRail یک جزء پایه عمومی‌اند. Shopify، Coinbase Commerce، دیگر پشته‌های پرداخت کریپتوی میزبانی‌شده و دو دوجین استارتاپ همین را می‌سازند. باید یک EIP برای لینک‌های پرداخت غیرامانی و یک EIP همراه برای اشتراک مبتنی بر allowance با پیاده‌سازی مرجع بنویسیم.
آن‌وقت:
- هر کیف پولی می‌تواند URL لینک پرداخت را با رابط استاندارد نمایش دهد («در حال پرداخت به فروشنده X هستید، ۵۰ دلار، USDC، غیرامانی»).
- هر ایندکسری (The Graph، Goldsky، Envio) از همان ابتدا از رویدادهای استاندارد پشتیبانی می‌کند.
- هر پردازشگری، حتی رقیب آینده OrcaRail، می‌تواند همان پروتکل را میزبانی کند.
- محصول OrcaRail به بهترین پیاده‌سازی یک استاندارد باز تبدیل می‌شود، نه پشته‌ای بسته.
ادعا: بزرگ‌ترین مزیت رقابتی در پرداخت، اعتماد به جزء پایه است، نه به پشته یک شرکت. جزء پایه را عمومی کنیم.
دور ۲: گرداننده به پرسش می‌کشد
از عمل‌گرا: «صادق باش؛ اگر OrcaRail قبض paymaster را نپردازد، اشتراک Alice همچنان برداشت می‌شود؟»
عمل‌گرا: در نقشه راه فعلی، پس از مرحله ۳، بله؛ Chainlink Automation همچنان charge() را اجرا می‌کند. قبض paymaster برای گس keeper است و Chainlink برای همان کار از LINK استفاده می‌کند. اما فروشندگانی که برای تطبیق حساب به داشبورد OrcaRail نیاز دارند آسیب می‌بینند: ایمیل‌ها، تلاش‌های مجدد و کدهای خطای خوانا همه در API ما هستند. قراردادها کار می‌کنند؛ محصول نه.
گرداننده: آیا «قراردادها کار می‌کنند اما آدم‌ها متوجه نمی‌شوند» واقعاً زنده‌بودن است؟
عمل‌گرا: زنده‌بودن تسویه است بدون زنده‌بودن تجربه کاربری. این تمایز واقعی است و باید آن را بپذیریم، نه پنهانش کنیم. رفع آن هم به‌مرور ارزان است: قالب‌های ایمیلمان را منتشر کنیم، ایندکسر را متن‌باز کنیم، بگذاریم کس دیگری داشبورد را میزبانی کند. لازم نیست همه این‌ها را در مرحله ۱ انجام دهیم.
از حداکثرگرا: «داشبوردهای IPFS با ENS عالی‌اند تا وقتی یک نهاد ناظر درباره یک فروشنده برایمان نامه بفرستد.»
حداکثرگرا: آن‌وقت OrcaRail میزبانی آن فروشنده را در داشبورد خودش متوقف می‌کند. پروتکل از طریق فرانت‌اند دیگری، یا فرانت‌اند خود فروشنده، همچنان به او خدمت می‌دهد. این ویژگی است، نه باگ؛ مقایسه کنید با مالی سنتی که «پردازشگر حسابم را مسدود کرد» درامی تکراری است و هیچ راه‌حلی در سطح پروتکل ندارد.
گرداننده: فروشندگانی که پردازشگر کارت اخراجشان می‌کند معمولاً از شبکه Visa هم اخراج می‌شوند. در پرداخت، زیرساخت و پردازشگر اغلب همان سانسورگرند.
حداکثرگرا: درست است، و این دقیقاً مسئله‌ای است که پروتکل حل می‌کند. Visa نمی‌تواند اتریوم را سانسور کند. OrcaRail با معماری پروتکلی نمی‌تواند فروشندگان را در سطح زیرساخت سانسور کند؛ فقط در سطح فرانت‌اند. فرانت‌اندها قابل جایگزینی‌اند؛ زیرساخت نه.
از مستقل: «اگر تسویه روی زنجیره OrcaRail باشد، فروشندگان چطور به USDC روی اتریوم برداشت می‌کنند؟»
مستقل: همان‌طور که هر کسی از هر L2 خارج می‌شود: با پل مرجع. Relay را به‌صورت بومی یکپارچه می‌کنیم تا خروج استیبل‌کوین‌ها فوری باشد. حجم روزانه برداشت در مقایسه با حجم درون زنجیره ناچیز است.
گرداننده: از ما می‌خواهی یک زنجیره اداره کنیم. هر زنجیره مهمی حالت‌های خرابی دارد: توقف sequencer، تأخیر در انتشار state root، خروج از پل. این خرابی‌ها عمومی و آشکارند. «sequencer اورکاریل ۳ ساعت از کار افتاد، پرداخت‌ها در سراسر جهان متوقف شد» تیتر بدتری است از «API اورکاریل ۳ ساعت قطع بود».
مستقل: فقط تا وقتی sequencer را غیرمتمرکز کنی تیتر بدتری است. اثبات خطا در OP Stack و توالی‌دهی مشترک (Espresso، Astria) این را به‌تدریج کمتر به ریسک یک طرف واحد تبدیل می‌کنند. درست می‌گویی که از آنجا شروع نمی‌کنیم. اما این هم درست است که نباید به‌تنهایی زنجیره اداره کنیم؛ از طریق یک شریک rollup-as-a-service با مسیری معتبر به توالی‌دهی مشترک راه‌اندازی می‌کنیم.
گرداننده: این وابستگی‌های زیادی است.
مستقل: هست. بده‌بستان این است: برای همیشه پرداخت گس را کنار می‌گذاریم، دیگر برای فضای بلاک mainnet نمی‌جنگیم و می‌توانیم اجزای پایه سفارشی منتشر کنیم. اگر حجم پرداخت آن‌قدر بزرگ باشد که هر کدام از این‌ها را توجیه کند، توجیه دارد. اگر نه، من اشتباه می‌کنم.
از باورمند به intent: «بازارهای solver مسئله MEV دارند. چه کسی از پرداخت‌کننده در برابر solverی که سهمی برمی‌دارد محافظت می‌کند؟»
باورمند به intent: intent با محدودیت‌های سخت امضا می‌شود. مبلغ پرداختی نمی‌تواند از آنچه پرداخت‌کننده مجاز کرده بیشتر شود. آنچه می‌تواند تغییر کند مسیر است (کدام پل، کدام DEX اگر swap لازم باشد) و زمان‌بندی. solver مخرب نمی‌تواند وجوه را به جای دیگری بفرستد؛ در بدترین حالت کند است. رقابت این را از بین می‌برد.
گرداننده: رقابت کارمزد را در مسیرهای پرحجم پایین می‌آورد. پرداخت خرد ۵ دلاری USDC به USDC بین‌زنجیره‌ای که به هیچ‌کس برای حلش پول کافی نمی‌رسد چه؟
باورمند به intent: این شکاف واقعی است. پاسخ solverهای پشتیبان است؛ OrcaRail یکی را به قیمت تمام‌شده اجرا می‌کند. بازار ۹۵٪ بالایی را پوشش می‌دهد و ما دنباله بلند را. به‌مرور، زنجیره‌های ارزان‌تر و پل‌های بهتر این شکاف را می‌بندند.
گرداننده: یعنی تو هم keeper اجرا می‌کنی، فقط اسمش را solver گذاشته‌ای.
باورمند به intent: keeperی که یکی از چند است، روی یک intent عمومی رقابت می‌کند و پشتیبان دارد؛ بله. این همان تفاوت بین «بک‌اند OrcaRail همان keeper است» و «OrcaRail یک مشارکت‌کننده در بازاری باز است» است.
از مدافع استاندارد: «EIPها سال‌ها طول می‌کشند. تا آن موقع چه کنیم؟»
مدافع استاندارد: اول پیاده‌سازی مرجع را طبق برنامه فعلی منتشر می‌کنی. بعد EIP را حول آنچه منتشر کرده‌ای می‌نویسی، نه از قبل. ERC-4337، ERC-721 و ERC-20 همین‌طور نوشته شدند. نقشه راه فعلی با این سازگار است؛ سطح SubscriptionHub با چند تغییر نام جزئی می‌تواند همان سطح ERC باشد.
گرداننده: انتشار «مزیت رقابتی» به شکل استاندارد ریسکی ندارد؟
مدافع استاندارد: مزیت رقابتی قرارداد نیست. مزیت رقابتی یکپارچه‌سازی‌ها، SLAها، کار انطباق، داشبوردها، تحویل‌پذیری ایمیل و اعتماد فروشندگان است. هیچ‌کدام را رقیب با خواندن یک EIP نمی‌تواند کپی کند. متن‌باز کردن سطح قرارداد رقابت را به جاهایی می‌برد که ما در آن قوی هستیم.
دور ۳: هر موضع واقعاً کجا برنده است
پس از پرسش‌وپاسخ، هر موضع در ابعاد مشخصی قوی‌تر است. کارنامه صادقانه:
| بُعد | عمل‌گرا | حداکثرگرا | مستقل | intent | استاندارد |
|---|---|---|---|---|---|
| زمان انتشار مرحله ۱ | سریع | کند | بسیار کند | کند | سریع |
| حذف امانت‌داری | بله | بله | بله | بله | بله |
| زنده‌بودن بدون OrcaRail | جزئی | قوی | متوسط | قوی | قوی |
| مقاومت در برابر سانسور | جزئی | قوی | متوسط | قوی | قوی |
| تجربه بین‌زنجیره‌ای | خوب | خوب | ضعیف | بهترین | خوب |
| شفافیت مقرراتی | متوسط | متوسط | ضعیف | ضعیف | بالا |
| وابستگی به زیرساخت OrcaRail | بالا | کم | بسیار بالا (زنجیره) | کم | کم |
| تمایز OrcaRail | بالا | کم | بالا | متوسط | بالا |
| ثبت‌نام فروشندگان غیرآشنا با کریپتو | بهترین | سخت‌ترین | متوسط | متوسط | متوسط |
| هزینه مهندسی | کم | متوسط | بسیار بالا | بالا | متوسط |
| خرابی قابل مشاهده برای کاربران فعلی | هیچ | قابل توجه | جدی | متوسط | کم |
هیچ ردیفی غالب نیست. برای همین این یک مناظره است و نه برنامه استقرار.
دور ۴: جمع‌بندی گرداننده
این‌طور مناظره را می‌خوانم، به‌عنوان کسی که باید انتخاب کند.
عمل‌گرا امروز برنده است چون محصول باید به انتشار ادامه دهد و ما توان توقف ۱۸ ماهه برای بازنویسی معماری را نداریم. نقشه راه فعلی نسخه‌ای اکیداً بهتر از نسخه امانی است که امروز اجرا می‌کنیم، با بهبودهای تدریجی سازگار.
حداکثرگرا از نظر اصول برنده است و یک محدودیت واقعی را نشان می‌دهد: روزی که API ما دلیل دریافت نکردن پول یک فروشنده باشد، روزی است که دیگر پروتکل نیستیم. این همان فشاری است که باید هر تصمیم مهندسی مراحل ۱ تا ۷ را هدایت کند: ایندکسر را منتشر کن، subgraph را منتشر کن، داشبورد را زیر ENS روی IPFS سنجاق کن، نحوه نصب روی سرور خود را مستند کن. نقشه راه عمل‌گرا این را ممکن می‌کند، اما اجبارش نمی‌کند. باید اجبارش کنیم.
مستقل برنده است اگر مقیاس توجیهش کند. زیر یک آستانه حجم، اداره زنجیره سربار است. بالای آن، اجاره فضای بلاک اتریوم برای تقسیم ۳ دلار بین شش نفر در هر بار بی‌معناست. وقتی بخش غالب حجم ما مسیرهای پرداخت‌کننده به فروشنده روی یک زنجیره باشد و بهینه‌سازی گس صرفه‌جویی قابل اندازه‌گیری در صورت مالی ایجاد کند، می‌فهمیم از آن آستانه گذشته‌ایم. هنوز نه.
باورمند به intent در بین‌زنجیره‌ای برنده است. پرداخت‌ها ذاتاً چنددارایی و چندزنجیره‌ای‌اند. جریان پرداخت‌کننده مبتنی بر intent («به فروشنده X بپرداز، برایم مهم نیست چطور») بهترین تجربه ممکن برای پرداخت‌کننده کریپتو است. باید intentها را در لایه SDK پرداخت‌کننده بپذیریم، پیش از اینکه در لایه تسویه بپذیریم. این کار solverهای موجود (Across، deBridge، Relay) را بدون نیاز به ساختن بازاری جدید به گزینه‌ای طبیعی تبدیل می‌کند.
مدافع استاندارد هر جا حداکثرگرا برنده است برنده است، با ریسک کمتر. نوشتن یک EIP حول آنچه در مراحل ۱ و ۲ منتشر می‌کنیم رایگان است، برای اکوسیستم مفید است و ما را کند نمی‌کند. همچنین برای فروشندگانی که برای اولین بار زیرساخت‌های کریپتو را ارزیابی می‌کنند، روایت معتبری از «ما زیرساخت می‌سازیم، نه تله» به ما می‌دهد.
پاسخ ترکیبی
جمع‌بندی کسل‌کننده اما درست: مسیر عمل‌گرا را منتشر کن، فشار حداکثرگرا را اعمال کن، intentها را برای تجربه پرداخت‌کننده بپذیر، در طول راه EIP بنویس و مستقل را به‌عنوان گزینه مرحله ۸ به بعد، مشروط به مقیاس، نگه دار.
به‌طور مشخص، این‌ها تعهدات تدریجی روی نقشه راه موجود است:
- M1: subgraph عمومی از مرحله ۱. همه رویدادهای
PaidوChargedدر یک subgraph مرجع که هر کسی بتواند پرس‌وجو کند. بدون مسدود کردن API. - M2: اپ پرداخت سنجاق‌شده روی IPFS از مرحله ۲. هر انتشار مبتنی بر محتوا آدرس‌دهی می‌شود و
pay.orcarail.ethاز طریق ENS قابل بازیابی است. - M3: کیت نصب روی سرور خود از مرحله ۳. Docker Compose + مستنداتی که به هر کسی اجازه می‌دهد داشبوردی سازگار با OrcaRail را از روی همان قراردادها اجرا کند.
- M4: SDK مبتنی بر intent از مرحله ۳.
orcarail.pay(intent)در کلاینت پرداخت‌های بین‌زنجیره‌ای را از طریق شبکه‌های solver موجود (Across/Relay) مسیریابی می‌کند. solver پشتیبان تحت اداره OrcaRail برای دنباله بلند. - M5: پیش‌نویس EIP از مرحله ۲. هم‌نویسی EIP لینک پرداخت با یک پردازشگر دیگر یا یک تیم کیف پول، بر پایه
SubscriptionHubما. - M6: ارزیابی فصلی گزینه مستقل در کنار ارزیابی EigenLayer. محرک‌ها: حجم پرداخت بر حسب زنجیره، هزینه گس هر پرداخت به‌عنوان درصدی از ارزش پرداخت، و تقاضای فروشندگان برای تسویه زیر یک سنت.
این پنج افزوده نقشه راه موجود را از «غیرامانی» به «غیرامانی، پروتکل‌محور و بی‌طرف به‌طور معتبر» می‌برند. مراحل ۱ تا ۷ را کند نمی‌کنند. به‌عنوان جریان‌های کاری زنده و جداگانه پیگیری می‌شوند.
این موارد به‌عنوان مسیر P در وایت‌پیپر پروتکل رسمی شده‌اند؛ وایت‌پیپری که M1 تا M5 را به مراحل P1 تا P5 تبدیل می‌کند و M6 (زنجیره اختصاصی) را به‌عنوان P6 اختیاری نگه می‌دارد.
آنچه صراحتاً هنوز انجام نمی‌دهیم
- زنجیره اختصاصی. نه در ۱۸ ماه آینده. هر فصل دوباره ارزیابی می‌شود.
- توکن OrcaRail هنگام راه‌اندازی. اکنون توکنی نیست. توکن حاکمیتی آینده برای پس از غیرمتمرکزسازی به‌عنوان گزینه رزرو شده است (برای موضع کامل وایت‌پیپر پروتکل را ببینید). بدون پیش‌فروش، بدون تخصیص، بدون امتیاز.
- مسیر کاملاً روی زنجیره حداکثرگرا بدون هیچ API. محصول به سطوح خوانا برای انسان نیاز دارد و فروشندگان وقتی مشکلی پیش می‌آید به کسی نیاز دارند که با او تماس بگیرند. استفاده بدون API را ممکن می‌کنیم، نه الزامی.
- شبکه solver اختصاصی خودمان. از شبکه‌های موجود استفاده می‌کنیم. ممکن است برای مسیرهای دنباله بلندی که solverهای موجود نادیده می‌گیرند یک solver پشتیبان به قیمت تمام‌شده اجرا کنیم، اما شبکه رقیب جدیدی راه نمی‌اندازیم.
به کجا می‌رسیم
این مطلب همراه نقشه راه غیرامانی است، نه جایگزین آن. نقشه راه همچنان مراحل ۰ تا ۷ را پیگیری می‌کند. این مناظره یک محور ششم اضافه می‌کند، یعنی پروتکل‌محوری، که هر مرحله باید بر اساس آن هم ارزیابی شود.
اگر در این مناظره بودید، موضع خودتان را برایمان بفرستید. استدلال‌های مخالف قوی را منتشر می‌کنیم.
مطالب مرتبط
- نقشه راه غیرامانی OrcaRail — نقشه راه مرجع
- چرا برداشت مبتنی بر allowance از اسکرو و session key بهتر است — مناظره مدل اشتراک، با همین قالب
- ارزیابی EigenLayer — گزارش تصمیم همراه برای keeperهای غیرمتمرکز
- معماری — آنچه مسیر عمل‌گرا واقعاً می‌سازد