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

مستقر مقالات

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

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

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

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

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

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

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

قبل از پرداختن به جزئیات بیشتر، اجازه دهید نگاهی به نحوه عملکرد تراکنش ها در صرافی های غیرمتمرکز بیندازیم. هنگامی که کاربران یک تراکنش مبادله را ارسال می کنند، قرارداد هوشمند را با پارامترهای مختلفی ارائه می کنند - کدام توکن ها برای مبادله، میزان مبادله، و مهمتر از همه، حداقل تعداد توکن هایی که کاربر باید دریافت کند تا تراکنش انجام شود. آخرین پارامتر مشخص می کند که مبادله باید "حداقل خروج" را برآورده کند، یا معکوس شود. این تنظیم اغلب به عنوان "لغزش مجاز" شناخته می شود زیرا در واقع حداکثر تغییر قیمت را که می تواند بین لحظه ارسال تراکنش به 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 برای تایید یک بلوک جدید فقط به یک چک نیاز دارد. اگر امضا معتبر باشد و توسط بیش از دو سوم اعضای کمیته امضا شده باشد، می توان بلوک را در زنجیره در نظر گرفت (البته می توان آن را دوباره از زنجیره تشکیل داد، اما پیگیری تکمیل بلوک می تواند تضمین های قوی تری ارائه دهد).

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

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

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

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

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

2. با استفاده از این بلوک جدید، یک کمیته همگام بعدی جدید دریافت کنید.

3. اگر هنوز عقب هستید، به مرحله 1 برگردید.

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

… در سطح اجرا

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

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

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

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

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

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

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

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

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

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

ارتباط با تیم: توییتر, تلگرام یا فارکستر @a16zcrypto.

نویسنده ترجمه harecrypta

VC | تلگرام | توییتر | یوتیوب | VK | سایت اینترنتی