وایت پیپر اتریوم- قسمت هفتم

در ادامه قسمت ششم وایت پیپر اتریوم:

- Advertisement -

Miscellanea And Concerns

اجرای GHOST اصلاح شده در شبکه اتریوم

“Greedy Heaviest Observed Subtree” (GHOST) پروتکل نوینی است که اولین بار در دسامبر سال 2013 توسط یوناتان سمپولینسکی و اویو زوهر معرفی شد. بسیاری از بلاک هایی که خیلی سریع حل میشوند بیات (stale )میشوند و امنیت کمی دارند. مثلا اگر ماینر A بلاکی را حل کند و ماینر B قبل از اینکه بلاک شخص A به شبکه ارسال شود بلاک دیگری را حل کند ، بلاک ماینر B، هدر میرود و به امنیت شبکه کمک نمی کند .

- Advertisement -

علاوه بر این ، مورد “تمرکز” هم وجود دارد: اگر ماینر A استخری با 30 درصد قدرت هش باشد و ماینر B تنها 10 درصد قدرت داشته باشد، 70 درصد امکان دارد که تولیدکننده این بلاک بیات شده ماینر A باشد و فقط 10 درصد این احتمال داده میشود که ماینر B آن را ایجاد کند.

پروتکل GHOST

پروتکل GHOST اشکال امنیتی شبکه را از طریق درج بلاک های بیات در طولانی ترین زنجیر ،حل میکند. به عبارت دیگر ، نه تنها والدین و اجداد بعدی یک بلاک ، بلکه فرزندان بیات اجداد بلاک (در اصطلاحات اتریوم ، “عموها”) به محاسبه اینکه کدام بلاک با بیشترین گواه اثبات کار پشتیبانی میشود ،اضافه میشوند.

برای حل مشکل دوم، ما از پروتکل توصیف شده توسط Sompolinsky و Zohar فراتر می رویم ، و همچنین اجازه می دهیم که بلاک های بیات در زنجیره اصلی ثبت شوند تا پاداش بلاک را دریافت کنند: یک بلاک بیات 93.75٪ پاداش پایه خود را دریافت می کند ، و برادرزاده که شامل بلاک بیات می شود ، باقی مانده 6.25% را دریافت می کند. و اما کارمزدهای تراکنش(اترها) به عموها تعلق نمی گیرد.

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

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

کارمزد اتریوم( Fees )

از آنجا که هر تراکنشی که در بلاکچین منتشر می شود، برای بارگیری و تأیید، هزینه ای به شبکه وارد میکند، به منظور برخی مکانیزم های نظارتی و جلوگیری از سوءاستفاده ، وجود کارمزد برای تراکنش ها الزامی است. پیش فرض شبکه بیتکوین کارمزد داوطلبانه است. به گونه ای که ماینرها مانند نگهبانی هستند که حداقل هایی برای این کارمزد ها تعیین میکنند.

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

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

شرایطی را در نظر بگیرید که:

1. وقتی یک تراکنش انجام میشود، پاداش kR به هر ماینری که این تراکنش را به شبکه اضافه کند، داده میشود.این پاداش توسط فرستنده مشخص شده ، همچنین kوR برای ماینر قبلی هم نمایش داده میشود.
2. انجام عملیات برای هر نود هزینه ای در بر دارد.( همه نودها کارایی برابری دارند)
3. N تعداد نود ماینر وجود دارد که قدرت پردازش همه آنها با هم برابر است.
4. به غیر از نود ماینر هیچ نود دیگری موجود نیست.

یک ماینر زمانی برای حل تراکنش اشتیاق پیدا میکند که پاداشش از هزینه بیشتر باشد. بنابراین تا زمانی که ماینر شانس1/N پردازش بلاک بعدی را داشته باشد، انتظار دارد پاداشش KR/N و هزینه پردازش KC باشد. بنابراین ماینر زمانی یک تراکنش را حل میکند که kR/N > kC, or R > NC باشد.

توجه داشته باشید که R کارمزد هر عملیات است و توسط فرستنده مشخص میشود و NC هزینه کل عملیات پردازش در شبکه است.

پس ماینرها فقط تراکنش هایی را انجام میدهند که سود آنها بیشتر از هزینه باشد.

چندین برداشت مهم و اشتباه از این فرضیات:

1. ماینر نسبت به نودهای تأیید کننده هزینه خیلی بیشتری را برای حل یک تراکنش متحمل میشود. چرا که زمان تأیید اضافی، انتشار بلوک را به تأخیر می اندازد و در نهایت احتمال بیات شدن بلاک را افزایش می دهد.
2. در آنجا نودهایی غیر از نود ماینر هم وجود دارند.
3. عملاً قدرت بین ماینرها به طور مساوی تقسیم نشده است.
4. انسانهای دیوانه و دشمنانی هستند که عمداً کارمزدهای پایین تری نسبت به کارمزد نودهای تأیید کننده انتخاب میکنند تا از این طریق به شبکه آسیب برسانند.

نکته اولی که در بالا ذکر شد تمایل ماینر را به حل تراکنش ها کاهش و در مقابل NC را افزایش میدهد،اما این دو حداقل تا حدودی همدیگر را کنسل میکنند. مهمترین موارد 3و4 هستند که ما برای حل این مشکل قیمت شناور را ایجاد کردیم : هیچ بلاکی نمیتواند عملیاتی بیشتر از BLK_LIMIT_FACTOR داشته باشد . خصوصاً:

blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR – 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

BLK_LIMIT_FACTOR و EMA_FACTORمقادیر ثابتی معادل 65536 و1.5 هستند اما پس ازتجزیه و تحلیل های بیشتر احتمالا تغییر پیدا میکنند.

شمارش و تورینگ کامل اتریوم ( Computation And Turing-Completeness )

نکته حائز اهمیت این است که ماشین مجازی اتریوم تورینگ کامل است. این بدین معناست که کد EVM قادر است هر محاسبه ای از جمله شمردن حلقه های نامحدود را هم انجام دهد. کد EVM به دو روش امکان شمردن حلقه ها را فراهم می کند. اولاً ، یک دستورالعمل JUMP وجود دارد که به برنامه اجازه می دهد تا به نقطه قبلی کد بازگردد ، دستورالعمل دیگری به نام JUMPI برای انجام پرش مشروط و انجام دستورهایی مثل : اگر x < 27 باشد x = x * 2 به کار میرود.

دوماً ، قراردادها میتوانند همدیگر را صدا بزنند. یا به اصطلاح فراخوانی بکنند و به طور بالقوه امکان حلقه سازی از طریق برگشت را فراهم کنند. که این امر منجر به مشکلاتی میشود. مثلاً آیا کاربران تقلبکار میتوانند نودها و ماینر ها را به حلقه های نامحدود وارد کنند و از این طریق سیستم های آنها را خاموش کنند؟ دلیل پیش آمدن چنین مشکلی ،مسئله ای به نام “مسئله توقف” در علم کامپیوتر است. به طور کلی راهی وجود ندارد که بگوید آیا این برنامه خاص اصلاً متوقف خواهد شد یا نه.

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

برای اینکه از انگیزه ما برای ارائه این راه حل با خبر شوید ، به مثال های زیر توجه کنید:

• یک مهاجم  قراردادی به منظور اجرای حلقه های نامحدود تنظیم میکند و برای ماینری میفرستد. این ماینر تراکنش را پردازش ، حلقه ها را اجرا و منتظر میماند تا سوخت آن تمام شود. حتی اگر سوخت اجرا تمام شود ، معامله همچنان معتبر میماند و ماینر در انتظار پرداخت کارمزد میماند.
•  مهاجم به هدف اینکه ماینر را مجبور کند زمان زیادی را صرف پردازش و اجرای یک تراکنش کند ، تعداد زیادی حلقه ایجاد میکند. پس ماینر آنقدر درگیر میشود و کارش طول میکشد که دیگر نمیتواند مدعی کارمزدش شود. به هر حال مهاجم ملزم به ارائه وجهی برای STARTGAS خواهد بود چرا که تعداد مراحل محاسباتی قابل اجرا را محدود کرده است، بنابراین ماینر پیش از موعد متوجه خواهد شد که اجرای این عملیات مستلزم اقدامات زیادی است.
•  مهاجم قراردادی را با کدی شبیه به : send(A,contract.storage[A]); contract.storage[A] = 0 ، با مقدار سوختی که فقط برای عملیات اول کافی باشد،مینویسد. (یعنی این تراکنش عملیات برداشت را انجام میدهد .اما مبلغ را از مانده حساب کم نمیکند). پس لزومی ندارد که برنامه نویس نگران چنین مهاجمانی باشد، به این علت که اگر اجرا وسط راه متوقف شود همه تغییرات به حالت اول بازگردانده میشود.

• یک قرارداد مالی به منظور کاهش احتمال خطر از 9 پایگاه داده اختصاصی میانگین میگیرد. مهاجم یکی از پایگاه های داده که قابل طراحی در مکانیزم تماس متغیر باشد را تصاحب میکند و آن را برای عملیات حلقه سازی نامحدود آماده و به این ترتیب تلاش میکند تا از طریق قرارداد مالی مدعی کارمزد شود.

جایگزین تورینگ کامل اتریوم

جایگزین تورینگ کامل، تورینگ ناقص است. که در آن JUMP و JUMPI وجود ندارد. فقط یک کپی از قرارداد در پشته فراخوان وجود دارد. تورینگ ناقص محدودیت زیادی ندارد، از بین تمام نمونه های قراردادی که به صورت داخلی بسته شده  تاکنون فقط یکی از آنها حلقه نیاز داشته و حتی می توان با 26 بار تکرار قسمتی از یک کد، این حلقه را حذف کرد. با وجود پیامدهای جدی و مزایای محدود تورینگ کامل پس چرا کلاً به سراغ زبان تورینگ ناقص نرویم؟ در اصل تورینگ ناقص به دلایل زیر نمیتواند راه حل مناسبی باشد:

C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3); …

C49: call(C50); call(C50);

 : C50

یک مرحله از برنامه را انجام بده و تغییرات را ذخیره کن ،حالا تراکنش را برای A بفرست. پس در 51 تراکنش، ما قراردادی داریم که 2 به توان 50 بار عملیات محاسباتی انجام میدهد.ماینرها قادرندبا تعیین مقادیری در قراردادها که حداکثر تعداد عملیات محاسباتی را مشخص میکند و محاسبه این عدد برای زمانی که قراردادها یکدیگر را فرامیخوانند، پیش از موعد این بمب ها را شناسایی کنند. اما برای انجام چنین عملیاتی ماینرها باید قراردادهایی که قراردادهای جدید میسازند راحذف کنند.

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