برای مطالعه قسمت اول مقاله زیر به این لینک مراجعه بفرمایید.
افزایش امنیت برای قابلیت چند امضایی (multisig) از طریق P2SH (Pay to Script Hash)
در حال حاضر پرداخت های چند امضایی از P2SH استفاده می­کنند که یک الگوریتم هش ۱۶۰ بیتی امن بنام HASH160 است (نوعی رمزنگاری بر مبنای SHA256). اگر یکی از امضا کنندگان قصد سرقت همه موجودی ها را داشته باشد بقیه امضا کنندگان متوجه یک برخورد (اختلال) بین آدرس معتبر به عنوان بخشی از اسکریپت چند امضایی، و یک اسکریپت دیگر می­شوند که این اسکریپت تنها با انجام نیمی از محاسبه (۸۰ بیت) تمامی موجودی را به آن ها پرداخت می کند. در این حیطه این وضعیت به عنوان یک حمله قاطع شناخته شده است. (برای مقایسه با فرض یک اگزا هش در ثانیه یعنی ۱۰^۱۸، شبکه بینکوین ارزش کار ۸۰ بیتی را هر دو هفته انجام می­دهد).
برای رفع این معضل، سگویت از HASH160 استفاده می­کند آن هم فقط برای پراخت های مستقیم به یک آدرس عمومی (جایی که این حمله بی فایده است) برای این کار از هش ۲۵۶ بیتی SHA256 برای پرداخت ها استفاده می­کند.
فایده آن برای چه کسی است؟
هرکسی که از طریق سگویت پرداخت هایی به قراداد های هوشمند یا چند امضایی دارد، برای داشتن امنیت بالاتر از آن سود می­برد.
نسخه بندی اسکریپت (کد برنامه)
تغییرات روی اسکریپت بیتکوین برای بهبود امنیت و عملکرد است. به هر جهت طراحی اسکریپت تنها اجازه می­دهد که نوعی سافت فورک (سازگاری عقبگرد با ورژن های قبلی) پیاده سازی گردد. این کار با جایگزینی یکی از ۱۰ فضای کد (آپکد) به نام OP_NOP با کد جدید صورت گیرد، که بصورت مشروط یا باعث عدم اجرا (شکست) اسکریپت شده و یا اینکه کاری انجام نمی­دهد. این وضعیت برای تعداد زیادی از تغییرات، از قبیل معرفی یک روش جدید امضا و یا امکانی مثل OP_CLTV کفایت می­کند اما هردو اینها تقریبا شبیه هک هستند (مثلا همیشه بعد از OP_CLTV یک OP_DROP نیز می­آید) و نمی­تواند برای فعال کردن امکانات ساده مثل ادغام دو رشته کاراکتر استفاده شود.
برای حل این مشکل، سگویت به اسکریپت ها یک شماره ورژن (نسخه) اضافه می­کند، بنابراین کدهای اجرایی (آپکد) اضافی که برای استفاده از تراکنش های غیر سگویتی نیازمند یک هارد فورک هستند، به سادگی با افزایش شماره نسخه اسکریپت، پشتیبانی می­شوند.
سود این کار برای کیست؟
سهولت تغییرات در اسکریپت های اجرایی، انجام اسکریپت های پیشرفته در بیتکوین را به سادگی امکان پذیر می­کند. این شامل تغییراتی مانند معرفی مواردی همچون الگوریتم امضای Schnorr، استفاده از کلید بازیابی برای کاهش اندازه امضا، پشتیبانی از زنجیره های بیرون از بلاکچین (sidechain) ایجاد قرارداد های هوشمند تر توسط مکانیزم MAST (Merklized Abstract Syntax Trees) و سایر ایده های در مرحله تحقیقات است.
کاهش رشد UTXO
دیتابیس خروجی تراکنش خرج نشده” (UTXO) توسط هریک از نودهای شبکه بیتکوین برای تشخیص معتبر و یا جعلی بودن تراکنش های جدید، به کار گرفته می­شود. برای کارایی عملکرد شبکه این دیتابیس باید خیلی سریع باشد تا بتوان هر نوع تغییری را به سرعت در آن جستجو کرد. حالت ایده آل برای این کار این است که این دیتابیس در حافظه سیستم (RAM) قراربگیرد. بنابر این با توجه به محدویت حافظه، کوچک نگه داشتن اندازه این دیتابیس یک فاکتور ارزشمند محسوب می­شود.
با رشد بیتکوین این موضوع سخت تر می شود، چرا که هر کاربر جدید باید حداقل یک ورودی UTXO برای خود داشته باشد و ترجیح می دهد که که چندین ورودی داشته باشند تا امنیت و انعطاف پذیری خود را افزایش دهند و یا بعنوان پشتیبان برای کانال های پرداخت یا سایر قراردادهای هوشمند خدمت رسانی کند.
کاری که سگویت در این مورد انجام می­دهد این است که باعث می­شود اطلاعات امضایی که تاثیر منفی روی اندازه UTXO ندارد را تا ۷۵ درصد کاهش دهد. انتظار می رود این کار موجب تشویق کاربران جهت استفاده از تراکنش هایی باشد که تاثیر روی UTXO را به حداقل می رساند تا درنتیجه کارمزدها کم شود و موجب تشویق توسعه دهندگان برای طراحی قراردادهای هوشمند و امکانات جدید بصورتی که کمترین تاثیر را در UTXO داشته باشد خواهد شد.
به واسطه اینکه سگویت خود یک سافت فورک است و اندازه بلاک را افزایش نخواهد داد لذا نرخ رشد اندازه UXTO دیگر از این بدتر نخواهد شد.
چه کسی نفع می­برد؟
کاهش رشد UTXO به نفع استخراج کنندگان، کسب و کارها و کاربرانی که فول نود (نود کامل) را اجرا می­کنند خواهد بود که امنیت فعلی شبکه بیتکوین را با ورود کاربران جدید به آن در دست دارند. کاربران و توسعه دهندگانی که رشد UTXO را به حداقل رسانده اند از کاهش کارمزد در مقایسه با کسانی که این امکان را در تراکنش ها نادیده گرفته اند، منتفع خواهند شد.
موقعی که تایید امضا صورت نگیرد کارایی به صورت قابل توجهی بالا می­رود
امضای تراکنش های انجام شده قبلی ممکن است جذابیت کمتری نسبت به امضای تراکنش های آینده داشته باشد. برای مثال جامعه Bitcoin Core بصورت پیش فرض امضای تراکنش های ماقبل تراکنش فعلی را انجام نمی­دهند و بعضی از کلاینت های SPV (Simplified Payment Verification) با اعتماد به اینکه این تراکنش ها قبلا بوسیله استخراج کنندگان یا نود های دیگر چک شده، خودشان به هیچ وجه امضا ها را چک نمی­کنند. به هر جهت در وضعیت فعلی اطلاعات امضا، خود بخشی از تراکنش بوده و می­بایست برای محاسبه هش تراکنش موجود باشد.
جداسازس اطلاعات امضا، به نود هایی که علاقه ای به این اطلاعات ندارند اجازه می­دهد که این اطلاعات را از دیسک پاکسازی (حذف) کرده یا از دانلود کردن آن اجتناب نمایند که منجر به صرفه جویی در منابع خواهد شد.
به نفع کیست؟
با استفاده بیشتر تراکنش ها از آدرس های سگویت، کسانی که نود های SPV و یا پاکسازی شده را اجرا می­کنند قادرند با پهنای باند و ظرفیت دیسک کمتری کار کنند.
افزایش اندازه بلاک
تا زمانی که نود های قدیمی تنها قادر به دانلود بلاک های بدون شاهد هستند فقط آن ها به قانون ۱MB برای اندازه بلاک پافشاری می­کنند. نود های جدید، که بلاک کامل به همراه دیتای شاهد (witness) برایشان مفهوم است، برای تغییر این محدودیت اندازه مشکلی نداشته و بلاک های با اندازه بزرگ را نیز پردازش می­کنند. بنابراین سگویت با بهره برداری از این فرصت می­تواند اندازه بلاک را به ۴MB افزایش داده و محدودیت هزینه­ی جدیدی، برای اطمینان از تراز ماندن بلاک ها برای استفاده از منابع شان اضافه خواهد کرد (که به طور موثری منجر به نزدیک شدن محدودیت به ۱٫۶ تا ۲MB خواهد شد).
این امکان به نفع کیست؟
کسانی که از کیف پول های ارتقا یافته استفاده می کنند قادر خواهند بود با استفاده از مزیت افزایش اندازه بلاک، امضا ها را به بخش شاهد در تراکنش منتقل کنند.
حرکت به طرف یک محدودیت تجمیع شده برای یک بلاک
در حال حاضر دو اجماع بر روی کاهش اندازه بلاک وجود دارد: بلاک هایی که بیشتر از ۱MB نمی­شوند و مستقلا آن هایی که حداکثر ۲۰۰۰۰ چک کردن امضا در تراکنش های آن بلاک دارند.
پیدا کردن بهترین حالت از چیدمان مجموعه ای از تراکنش ها در یک بلاک، فقط با یک محدودیت، منجر به کوله باری از مشکلات خواهد شد که به سادگی توسط یک الگوریتم آزمندانه (بهترین انتخاب با توجه به شرایط مسئله) کاملا قابل حل است. به هر صورت برای محدودیت دوم گاهی دستیابی به یک راه حل، بسیار سخت خواهد بود و این مشکل مسبوق به سابقه در عمل منجر به استخراج اجباری بلاک هایی با اندازه کمتر شده است.
دستیابی به راه حل این مشکل با هارد فورک یا کاهش ضروری اندازه بلاک امکان پذیر نیست. تا زمانی که سگویت نتواند این مشکل را حل کند، مشکل به همین صورت بلاتکلیف مانده و بدتر از این نخواهد شد؛ در عمل بجای ارائه محدودیتی مستقل برای دیتای سگویت، اگر فقط یک محدودیت به کل دیتای UXTO و دیتای شاهد (جمعا) اعمال شود، اجازه می­دهد هردو مورد به طور هم زمان در قالب یک ماهیت، محدود شوند.
نفع این کار برای کیست؟
استخراج کنندگان برتر در شرایط اعمال یک هاردفورک در آینده، می­توانند تغییرات محدودیت اندازه بلاک را در قالب پارامترهای وزنی تجمیع نماید.
۵۰*sigops + 4*basedata + 1*witnessdata < 10M
در این وضعیت استخراج کنندگان با افزایش درآمد کارمزد به سادگی و با دقت بلاک ها را پر می­کنند و کاربران نیز اجازه خواهند داشت تا محاسبات کارمزد های مورد نیاز خود را در تراکنش های استخراجی با دقت بیشتری انجام دهند.


دیدگاه هایی که در این مقاله ارائه شده اند، متعلق به نویسنده می باشند و لزوماً مربوط به Coiniran نمی باشد و نباید به آن نسبت داده شود.


https://coiniran.com/%d9%81%d9%88%d8...f%d9%88%d9%85/