ساخت هلیوس: دسترسی کاملاً بدون اعتماد به اتریوم

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

با این حال، امتیازاتی وجود دارد که ما به خاطر سهولت انجام داده ایم. یکی از این زمینه ها استفاده ما از سرورهای متمرکز RPC (تماس فرآیند از راه دور) است. کاربران معمولاً از طریق ارائه دهندگان متمرکز مانند Alchemy به اتریوم دسترسی دارند. این شرکت ها گره های با کارایی بالا را روی سرورهای ابری اجرا می کنند تا دیگران بتوانند به راحتی به داده های زنجیره ای دسترسی داشته باشند. هنگامی که یک کیف پول موجودی توکن خود را جستجو می کند یا بررسی می کند که آیا تراکنش معلق در یک بلوک گنجانده شده است، تقریباً همیشه این کار را از طریق یکی از این ارائه دهندگان متمرکز انجام می دهد. 

مشکل سیستم موجود این است که کاربران باید به ارائه دهندگان اعتماد کنند و هیچ راهی برای تأیید صحت درخواست های آنها وجود ندارد.

وارد هلیوسیک کلاینت لایت اتریوم مبتنی بر Rust که ما ایجاد کردیم که دسترسی کاملاً بدون اعتماد به اتریوم را فراهم می کند. Helios – که از پروتکل کلاینت نور اتریوم استفاده می کند که توسط این امکان پذیر شده است سوئیچ اخیر به اثبات سهام - داده‌های یک ارائه‌دهنده RPC متمرکز غیرقابل اعتماد را به یک RPC محلی ایمن و قابل تأیید تبدیل می‌کند. Helios با RPC های متمرکز کار می کند تا صحت آنها را بدون اجرای یک گره کامل تأیید کند. 

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

مشکلات زیرساخت متمرکز: موجودات نظری در "جنگل تاریک" اتریوم

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

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

تا زمانی که این حداقل پارامتر خروجی نزدیک به ارزش منصفانه تنظیم شود، از حملات ساندویچی در امان هستید. اما اگر ارائه‌دهنده RPC شما قیمت دقیقی از قرارداد هوشمند مبادله غیرمتمرکز ارائه نکند، چه؟ سپس می‌توان کاربر را فریب داد تا یک تراکنش مبادله را با حداقل پارامتر خروجی پایین‌تر امضا کند و برای بدتر شدن اوضاع، تراکنش را مستقیماً به ارائه‌دهنده RPC مخرب ارسال کند. به جای پخش این تراکنش در ممپول عمومی، جایی که ده‌ها ربات برای انجام حمله ساندویچی با هم رقابت می‌کنند، ارائه‌دهنده می‌تواند آن را متوقف کند و بسته تراکنش حمله را مستقیماً به Flashbots ارسال کند و سود را برای خود تضمین کند.

علت اصلی این حمله اعتماد به شخص دیگری برای واکشی وضعیت بلاک چین است. کاربران با تجربه به طور سنتی این مشکل را با اجرای گره‌های اتریوم خود حل کرده‌اند - تلاشی زمان‌بر و منابع فشرده که حداقل به یک ماشین دائما آنلاین، صدها گیگابایت فضای ذخیره‌سازی و حدود یک روز برای همگام‌سازی از ابتدا نیاز دارد. این فرآیند مطمئناً ساده تر از گذشته است. گروه هایی مانند اتریوم در ARM به‌طور خستگی‌ناپذیری کار کرده‌اند تا امکان اجرای گره‌ها بر روی سخت‌افزار کم‌هزینه (مانند Raspberry Pi با هارد دیسک خارجی متصل به آن) را فراهم کنند. اما حتی با این الزامات نسبتاً حداقلی، اجرای یک گره هنوز برای اکثر کاربران دشوار است، به ویژه برای کسانی که از دستگاه های تلفن همراه استفاده می کنند.

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

معرفی Helios: دسترسی کاملاً بدون اعتماد به اتریوم

اتریوم با معرفی پروتکل کلاینت سبک خود (که با تغییر اخیر به Proof of Stake امکان پذیر شد)، امکانات جدید هیجان انگیزی را برای تعامل سریع با بلاک چین و تأیید نقاط پایانی RPC با حداقل نیازهای سخت افزاری باز کرد. در یک ماه از آن زمان ادغام، ما شاهد ظهور یک محصول جدید از مشتریان سبک مستقل از یکدیگر بوده ایم (لودستار, نیمبوسو مبتنی بر جاوا اسکریپت کولار) که رویکردهای مختلفی را در خدمت یک هدف اتخاذ کرده اند: دسترسی کارآمد و بدون اعتماد، بدون استفاده از گره کامل.

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

پس چگونه کار می کند؟ لایه اجماع Helios از یک بلاک هش زنجیره بیکن شناخته شده و یک اتصال به یک RPC نامعتبر برای همگام سازی قابل تایید با بلوک فعلی استفاده می کند. لایه اجرای Helios از این بلوک‌های زنجیره بیکن تأیید شده در پشت سر هم با یک لایه اجرایی غیرقابل اعتماد RPC برای اثبات اطلاعات دلخواه در مورد وضعیت زنجیره مانند مانده حساب، ذخیره قرارداد، رسید تراکنش‌ها و نتایج تماس قرارداد هوشمند استفاده می‌کند. این مؤلفه ها با هم کار می کنند تا بدون نیاز به اجرای یک گره کامل، یک RPC کاملاً بدون اعتماد را به کاربران ارائه دهند.

... در لایه اجماع

کلاینت لایت لایه اجماع با مشتری نور زنجیره ای بیکن مطابقت دارد مشخصاتو از کمیته های همگام سازی زنجیره بیکن (که قبل از ادغام در هارد فورک Altair معرفی شد) استفاده می کند. کمیته همگام سازی یک زیرمجموعه تصادفی از 512 اعتبارسنجی است که برای دوره های 27 ساعته خدمت می کنند. 

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

با تشکر از BLS امضا تجمیع، تنها یک بررسی لازم است تا هدر جدید تأیید شود. اگر امضا معتبر باشد و توسط بیش از دو سوم اعضای کمیته امضا شده باشد، می توان فرض کرد که بلوک در زنجیره گنجانده شده است (البته می توان آن را مجدداً خارج از زنجیره سازماندهی کرد، اما نهایی شدن بلوک ردیابی می تواند فراهم شود. تضمین های سخت گیرانه تر).

با این حال، یک قطعه گمشده آشکار در این استراتژی وجود دارد: چگونه می توان کمیته همگام سازی فعلی را پیدا کرد. این با به دست آوردن یک ریشه اعتماد به نام the شروع می شود نقطه بازرسی ذهنیت ضعیف. اجازه ندهید این نام شما را بترساند - این فقط به این معنی است که یک بلاک هش قدیمی که می توانیم تضمین کنیم در گذشته در این زنجیره گنجانده شده است. ریاضیات جالبی در پشت این که ایست بازرسی دقیقاً چند ساله باشد وجود دارد. تجزیه و تحلیل بدترین حالت حدود دو هفته را نشان می دهد، در حالی که تخمین های عملی تر، چندین ماه را نشان می دهد. 

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

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

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

1. از کمیته همگام سازی بعدی بعد از ایست بازرسی ما برای واکشی و تأیید بلوکی که منشا یک کمیته همگام سازی در آینده است استفاده کنید.
2. از این بلوک جدید برای واکشی کمیته همگام سازی بعدی جدید استفاده کنید.
3. اگر هنوز عقب هستید، به مرحله 1 بازگردید.

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

... در لایه اجرا

هدف کلاینت لایت لایه اجرا این است که هدرهای بلوک بیکن را که توسط لایه اجماع تأیید شده اند، بگیرد و از آنها به همراه یک لایه اجرایی نامعتبر RPC برای ارائه داده های لایه اجرای تأیید شده استفاده کند. سپس می توان از طریق سرور RPC که به صورت محلی توسط Helios میزبانی می شود، به این داده ها دسترسی داشت.

در اینجا یک مثال ساده از واکشی موجودی حساب آورده شده است که با یک آغازگر سریع در مورد نحوه ذخیره وضعیت در اتریوم شروع می شود. هر حساب شامل چند فیلد مانند هش کد قرارداد، nonce، هش ذخیره سازی و موجودی است. این حساب ها در یک بزرگ و تغییر یافته ذخیره می شوند درخت مرکل-پاتریشیا درخت دولت نامیده می شود. اگر ریشه درخت حالت را بدانیم، می توانیم اعتبار سنجی کنیم شواهد merkle برای اثبات وجود (یا حذف) هر حساب در درخت. جعل این شواهد عملاً غیرممکن است.

Helios دارای یک ریشه حالت تایید شده از لایه توافق است. با استفاده از این ریشه و درخواست‌های اثبات merkle به لایه اجرایی غیرقابل اعتماد RPC، Helios می‌تواند به صورت محلی تمام داده‌های ذخیره شده در اتریوم را تأیید کند.

ما تکنیک های مختلفی را برای تأیید انواع داده های مورد استفاده در لایه اجرا اعمال می کنیم. استفاده از آنها با هم، به ما اجازه می دهد تا تمام داده های بازیابی شده از RPC نامعتبر را تأیید اعتبار کنیم. در حالی که یک RPC نامعتبر می تواند دسترسی به داده ها را رد کند، دیگر نمی تواند نتایج نادرست را به ما ارائه دهد.

استفاده از هلیوس در طبیعت

معاوضه بین قابلیت حمل و غیرمتمرکز شدن یک نقطه درد رایج است – اما از آنجایی که Helios بسیار سبک وزن است، کاربران می توانند به داده های زنجیره ای امن از هر دستگاهی (از جمله تلفن های همراه و افزونه های مرورگر) دسترسی داشته باشند. توانایی اجرای Helios در هر مکانی این امکان را برای افراد بیشتری فراهم می‌کند که بدون در نظر گرفتن سخت‌افزار به داده‌های Ethereum غیرقابل اعتماد دسترسی داشته باشند. این بدان معناست که کاربران می‌توانند از Helios به عنوان ارائه‌دهنده RPC خود در MetaMask استفاده کنند و بدون هیچ تغییر دیگری به‌صورت مطمئن به dapp‌ها دسترسی داشته باشند. 

علاوه بر این، پشتیبانی Rust از WebAssembly این امکان را برای توسعه دهندگان برنامه به راحتی فراهم می کند تا Helios را در برنامه های جاوا اسکریپت (مانند کیف پول ها و dapps) جاسازی کنند. این ادغام ها اتریوم را ایمن تر می کند و نیاز ما به اعتماد به زیرساخت های متمرکز را کاهش می دهد.

ما نمی توانیم منتظر بمانیم تا ببینیم جامعه چه چیزی را ارائه می دهد. اما در این میان، راه‌های زیادی برای کمک به Helios وجود دارد – اگر علاقه‌ای به مشارکت در پایگاه کد ندارید، می‌توانید نرم‌افزاری بسازید که Helios را ادغام کرده و از مزایای آن بهره ببرید. اینها تنها تعدادی از ایده هایی هستند که ما در مورد آنها هیجان زده ایم:

• پشتیبانی از واکشی داده های کلاینت نور مستقیماً از شبکه P2P و نه از طریق RPC
• برخی از روش های RPC گم شده را پیاده سازی کنید
• یک نسخه از Helios بسازید که در WebAssembly کامپایل شود
• Helios را مستقیماً در نرم افزار کیف پول ادغام کنید
• یک داشبورد وب بسازید تا موجودی توکن خود را مشاهده کنید که داده ها را از Helios تعبیه شده در وب سایت با WebAssembly واکشی می کند.
• API موتور را پیاده سازی کنید تا لایه اجماع هلیوس بتواند به یک گره کامل لایه اجرایی موجود متصل شود.

پایگاه کد را بررسی کنید برای شروع - ما از گزارش های اشکال، درخواست های ویژگی و کد شما استقبال می کنیم. و اگر چیزی بیشتر ساختید، آن را با ما در میان بگذارید توییتر, تلگرام، یا Farcaster @a16zcrypto.

***
نظرات بیان شده در اینجا نظرات پرسنل AH Capital Management, LLC ("a16z") نقل شده است و نظرات a16z یا شرکت های وابسته به آن نیست. برخی از اطلاعات موجود در اینجا از منابع شخص ثالث، از جمله از شرکت‌های سبد سرمایه‌ای که توسط a16z مدیریت می‌شوند، به‌دست آمده است. در حالی که a16z از منابعی گرفته شده است که قابل اعتماد هستند، اما a16z به طور مستقل چنین اطلاعاتی را تأیید نکرده است و هیچ گونه نمایشی در مورد صحت فعلی یا پایدار اطلاعات یا مناسب بودن آن برای یک موقعیت خاص ارائه نمی کند. علاوه بر این، این محتوا ممکن است شامل تبلیغات شخص ثالث باشد. aXNUMXz چنین تبلیغاتی را بررسی نکرده و محتوای تبلیغاتی موجود در آن را تایید نمی کند.

این محتوا فقط برای مقاصد اطلاعاتی ارائه شده است و نباید به عنوان مشاوره حقوقی، تجاری، سرمایه گذاری یا مالیاتی به آن اعتماد کرد. شما باید در مورد این موارد با مشاوران خود مشورت کنید. ارجاع به هر گونه اوراق بهادار یا دارایی دیجیتال فقط برای مقاصد توضیحی است و به منزله توصیه یا پیشنهاد سرمایه گذاری برای ارائه خدمات مشاوره سرمایه گذاری نیست. علاوه بر این، این محتوا برای هیچ سرمایه‌گذار یا سرمایه‌گذار بالقوه‌ای هدایت نشده و برای استفاده از آن در نظر گرفته نشده است، و تحت هیچ شرایطی نمی‌توان هنگام تصمیم‌گیری برای سرمایه‌گذاری در هر صندوقی که توسط a16z مدیریت می‌شود، به آن اعتماد کرد. (پیشنهاد سرمایه گذاری در یک صندوق a16z فقط توسط یادداشت قرار دادن خصوصی، قرارداد اشتراک و سایر اسناد مربوط به هر صندوق انجام می شود و باید به طور کامل خوانده شود.) هر گونه سرمایه گذاری یا شرکت پرتفوی ذکر شده، ارجاع شده، یا شرح داده شده نشان دهنده همه سرمایه گذاری ها در وسایل نقلیه تحت مدیریت a16z نیست، و نمی توان اطمینان داشت که سرمایه گذاری ها سودآور هستند یا سایر سرمایه گذاری های انجام شده در آینده ویژگی ها یا نتایج مشابهی خواهند داشت. فهرستی از سرمایه‌گذاری‌های انجام‌شده توسط صندوق‌های تحت مدیریت آندریسن هوروویتز (به استثنای سرمایه‌گذاری‌هایی که ناشر مجوز افشای عمومی a16z و همچنین سرمایه‌گذاری‌های اعلام‌نشده در دارایی‌های دیجیتالی عمومی را ارائه نکرده است) در https://a16z.com/investments موجود است. /.

نمودارها و نمودارهای ارائه شده در داخل صرفاً برای مقاصد اطلاعاتی هستند و هنگام تصمیم گیری برای سرمایه گذاری نباید به آنها اعتماد کرد. عملکرد گذشته نشان دهنده نتایج آینده نیست. محتوا فقط از تاریخ مشخص شده صحبت می کند. هر گونه پیش بینی، تخمین، پیش بینی، هدف، چشم انداز، و/یا نظرات بیان شده در این مطالب بدون اطلاع قبلی ممکن است تغییر کند و ممکن است متفاوت یا مغایر با نظرات بیان شده توسط دیگران باشد. لطفاً برای اطلاعات مهم بیشتر به https://a16z.com/disclosures مراجعه کنید