حمید رضا عسگری | 2017.07.27

فواید سگویت

سافت فورک سگویت گستره وسیعی از امکانات دارد که بعضی از آن ها کاملا فنی است. در این مقاله به بعضی از فواید سگویت این امکانات پرداخته می­شود.

رفع مشکل قابلیت انعطاف پذیری

تراکنش های بیتکوین توسط یک هش (hash) 64 رقمی از کاراکتر های با فرمت هگزا دسیمال (Hex) با علامت اختصاری txid شناخته می­شوند که این رشته شامل آدرس فرستنده و آدرس گیرنده تراکنش (بیتکوین) است.

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

برای مثال فرض کنید تراکنشی با txid بصورت ef74…c309 به شبکه ارسال می­کنید، حالا فرض کنید که طرف سومی (شخص ثالث) مثلا یک نود در شبکه که این تراکنش را رله می­کند (به نود دیگر ارسال می­کند) و یا یک استخراج کننده که تراکنش شما را به یک بلاک اضافه می­کند می­تواند بدون سرو صدا تغییراتی در تراکنش انجام دهد اما همچنان آدرس فرستنده و گیرنده ثابت باشند و در نهایت، تایید این تراکنش با یک txid کاملا متفاوت شبیه  ۶۸۳f…۸bfaانجام خواهد شد.

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

کاری که سگویت می­کند جلوگیری از دستکاری توسط طرف سوم و scriptSig است. برای این کار، کاربران بیتکوین قادر هستند که اجزای انعطاف پذیر تراکنش را به شاهد تراکنش (transaction witness) منتقل و آن را  جدا کنند. نتیجه اینکه تغییرات اعمال شده در witness تاثیری بر محاسبه txid نخواهد داشت.

منفعت این کار به چه کسی می­رسد؟

  • نویسندگان (توسعه دهندگان) کیف پول می­توانند نحوه خرج کردن بیتکوین را دنبال کنند:

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

  • هر کسی که تراکنش تایید نشده را خرج می­کند:

اگر Alice  در تراکنش شماره ۱ به Bob پرداخت داشته باشد، Bob از آن برای پرداخت به Charlie در تراکنش ۲ استفاده می­کند و سپس پرداخت Alice با مشکل انعطاف پذیری مواجه و با یک txid متفاوت تایید می­شود، پس تراکنش ۲ اکنون نامعتبر است و بنابراین به Charlie پرداختی صورت نمی­پذیرد. حال اگر Bob قابل اعتماد باشد، او مجددا پرداخت به Charlie را به جریان می­اندازد. اما اگر قابل اعتماد نباشد، می­تواند آن مقدار بیتکوین را برای خود نگه دارد.

  • شبکه Lightening

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

  • هر کسی که از بلاکچین استفاده می­کند:

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

توجه: تراکنش های سگویت درصورتی از این انعطاف پذیری دوری می­کنند که تمامی ورودی ها از پروپوزال سگویت طبعیت نمایند (چه بصورت مستقیم یا از طریق سازگاری عقبگرد آدرس سگویت P2SH (Pay to Script Hash)).

مقیاس پذیری خطی عملیات sighash

یک معضل بزرگ برای راه کار های ساده افزایش اندازه بلاک بیتکوین، عبارت است از اینکه برای تراکنش های خاص، نمودار Signature-hashing (زمان تاییدیه) بجای حالت خطی، بصورت نمایی افزایش می­یابد.

فواید سگمنت

در واقع دوبرابر شدن اندازه بلاک منجر به دوبرابر شدن تعداد عملیات امضا و حجم دیتایی که برای هر کدام از امضاها باید هش شود تا مورد تایید واقع شوند می شود. نتیجه این وضعیت ترسناک است زیرا برای یک بلاک مشخص که ۲۵ ثانیه تایید آن زمان می­برد این طراحی مخرب زمان تایید را به ۳ دقیقه خواهد رساند.

سگویت این مشکل را با تغییر نحوه محاسبه hash تراکنش انجام می­دهد؛ بدین صورت که هر بایت تراکنش حداکثر دو بار hash خواهد شد. این امر عملکرد فعلی را بهبود بخشیده و بنابراین هنوز هم امکان ایجاد تراکنش های بزرگ بدون وارد شدن به معضل هش کردن امضا وجود خواهد داشت، حتی اگر آن ها بلاک های مخرب یا خیلی بزرگ را تولید کنند (تراکنش های بزرگ) نیز پشتیبانی می­شوند.

منفعت این کار به چه کسی می­رسد؟

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

هشِ اصلاح شده تنها به عملیات امضایی اعمال می شود که از دیتای شاهد نشات می گیرد، بنابراین عملیات امضا از بلاک اولیه با محدودیت های خود ادامه خواهد داشت.

امضای مقادیر ورودی

وقتی که یک کیف پول سخت افزاری یک تراکنش را امضا می­کند می­تواند به سادگی کل موجودی در حال خرج شدن را تایید کند؛ اما هنگامی می­تواند با اطمینان مقدار کارمزد را تشخیص دهد که یک کپی کامل از تمام تراکنش های ورودی که در حال خرج شدن هستند (چندین تراکنش ورودی که جمع شده اند و تراکنش اصلی که در حال ارسال است را تشکیل می دهند) را داشته باشد و باید همه آن ها را برای اطمینان از عدم ورود دیتای غلط، hash کند. از آنجایی که اندازه هر تراکنش تا ۱MB می تواند باشد، این کار لزوما یک عملیات ارزان نخواهد بود حتی اگر  تراکنشی که امضا می­شود، خیلی کوچک باشد (مقدارش کم باشد).

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

فایده این کار چیست؟

کارخانه های سازنده کیف های سخت افزاری و کاربران آن به طور پیش فرض از این کار سود می­برند. هر چند که استفاده از بیتکوین در دستگاه های کوچک IOT (اینترنت اشیاء) با اطمینان بسیار بیشتری استفاده خواهد شد. این فایده نیز تنها وقتی امکان پذیر است که تراکنش های پرداختی به آدرس های فعال شده روی سگویت ارسال شوند (Segwit P2SH).

افزایش امنیت برای قابلیت چند امضایی (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 نمی باشد و نباید به آن نسبت داده شود.

 



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



Source : bitcoincore