ViaBTC_official
عضو دیجیبیت
پسزمینه
RGB، پروتکلی که برای مقیاس پذیرتر و خصوصی تر کردن بیت کوین ایجاد شده است
عملکرد بیت کوین از زمان راه اندازی این رمزارز در سال 2009 همواره به دقت تحت بررسی قرار داشته است. از آنجایی که بیتکوین تنها می تواند هفت تراکنش در ثانیه را پردازش کند، شبکه اجازه قراردادهای هوشمند مقیاس پذیر را نمی دهد. ارتقای SegWit محدودیت اندازه بلوک بیت کوین را به 4 مگابایت افزایش داد (1 مگابایت برای داده های تراکنش و 3 مگابایت برای داده های شاهد). با این حال، محدودیت هنوز پابرجاست. در همین حال، با افزایش نفوذ بیت کوین، چالش مقیاس پذیری حادتر شده است. مقیاس پذیری همچنان یک چالش اساسی پیش روی اکوسیستم بیت کوین است. امروزه، متخصصان در حال بررسی راهحلهایی با رویکردهای مختلف هستند که در درجه اول عبارتند از:
تکامل RGB
پیدایش RGB را می توان به سال 2016 نسبت داد، زمانی که پیتر تاد مفهوم مهر و موم یکبار مصرف و اعتبار سنجی سمت مشتری را معرفی کرد. بر اساس این مفاهیم مهم، RGB در سال 2018 پیشنهاد شد.
در سال 2019، Orlovsky، یک توسعهدهنده اصلی RGB، که از پیشگامان توسعهی RGB بود، اجزای بسیاری را ایجاد کرد که در نهایت پروتکل RGB را تشکیل میدهند. علاوه بر این، تأسیس انجمن LNP/BP در سوئیس به ارائه استانداردهای مربوطه کمک کرد.
پس از تلاشهای توسعه گسترده، RGB نسخه 0.10 خود را در آوریل 2023 معرفی کرد.
درباره طراحی RGB
RGB به این صورت به مقیاس پذیری و محرمانگی دست می یابد:
اعتبار سنجی سمت مشتری
اکثر بلاک چینهای عمومی موجود تحت یک مدل اجماع جهانی عمل میکنند، که در آن همهی نادها همهی تراکنشها را تأیید میکنند، اطلاعات تراکنشها را با یکدیگر به اشتراک میگذارند و یک وضعیت جهانی یکپارچه را حفظ میکنند.
با این حال، این مدل چندین چالش را به همراه دارد، از جمله:
ویژگی های کلیدی CSV:
از سوی دیگر، RGB برای ایجاد معادلی از مجموعه بیت کوین UTXO به پخش شبکه جهانی همه تراکنش ها متکی نیست. این بدان معناست که در حین دریافت یک پرداخت از نوع دریافتی، یک مشتری RGB نه تنها باید تأیید کند که آخرین انتقال وضعیت معتبر است، بلکه باید اعتبار یکسانی را برای همه انتقالهای حالت قبلی تا حالت پیدایش در قرارداد صدور انجام دهد. این اعتبارسنجی از پایین به بالا تاریخچه تراکنش ها در RGB همچنین از حملات پرداخت دوباره محافظت می کند.
RGB مقیاس پذیری را تنها با اعتبارسنجی تراکنش های مرتبط بهبود می بخشد. با این حال، این رویکرد ممکن است منجر به مشکلات مرتبط با در دسترس بودن داده ضعیف شود، که ممکن است به اشتراک گذاری داده ها برای بهینه سازی اعتبار سنجی پرداخت نیاز داشته باشد.
مهر و موم های یکبار مصرف مبتنی بر بیت کوین
مهر و موم های فیزیکی یک بار مصرف، اتصالات پلاستیکی با شماره منحصر به فرد هستند که معمولاً برای تشخیص دستکاری شدن استفاده می شوند. در حین ذخیره سازی و حمل و نقل به عنوان مثال، به ما اطلاع می دهد که آیا درب کانتینر در حین حمل و نقل باز شده است یا خیر. مهر و موم دیجیتال یکبار مصرف مهر دیجیتال را روی یک پیام می بندد تا مطمئن شود که فقط یک بار می توان از آن استفاده کرد، که فروش دوبار یک ملک را برای فروشندگان غیرممکن می کند.
به جای استفاده از یک نهاد مورد اعتماد برای تأیید باز و بسته شدن مهرهای دیجیتال، می توان از خروجی های تراکنش خرج نشده بیت کوین (UTXO) به عنوان مهر و موم استفاده کرد. UTXO را میتوان بهعنوان مهر و مومی دید که هنگام ایجاد بسته میشود و پس از مصرف باز میشود. با توجه به قوانین اجماع بیت کوین، یک خروجی فقط یک بار می تواند خرج شود. بنابراین، مهر و موم فقط یک بار می تواند باز شود. به این ترتیب، مهر و موم های یکبار مصرف برای مرتبط کردن UTXO های بیت کوین با حالت های قرارداد خارج از زنجیره استفاده می شود و امکان اجرای انتقال حالت بعدی از طریق تراکنش های RGB خارج از زنجیره (بستن مهر) را فراهم می کند. مشابه مهر و موم های فیزیکی یک بار مصرف که برای ایمن سازی ظروف حمل و نقل استفاده می شود، مهر و موم یکبار مصرف دیجیتال یک چیز منحصر به فرد است که به طور دقیق بخشی از اطلاعات را برای جلوگیری از هزینه اضافه مهر و موم می کند.
در اینجا یک تشبیه ساده وجود دارد: ما می توانیم UTXO ها را به عنوان یک سری چک در نظر بگیریم که هر کدام با مقدار متفاوتی همراه است. هنگام پرداخت، اساساً با یک چک نقد نشده به شخصی پرداخت می کنید. علاوه بر این، باقی مانده چک در قالب چک جدید به شما باز می گردد. در این سناریو، مهرهای یکبار مصرف سوابق انتقال خاصی را به جعبه اطلاعات اضافی چک اضافه می کنند. از آنجایی که چک فقط یک بار قابل وصول است، این رویکرد از هزینههای اضافی جلوگیری می کند.
بیایید ببینیم این فرآیند در بین آلیس، باب و دیو چگونه کار می کند:
1. در ابتدا، آلیس یک دارایی RGB (به عنوان مثال USDT Tether یا USDT) با مجموع عرضه 100 میلیون صادر کرده است و اطلاعات تعهد را به یک چک معتبر (چک A) در کادر اطلاعات اضافی اضافه کرده است. چاپگر چک مجبور نیست این اطلاعات اضافی را در نظر بگیرد و چک A تا زمانی که متعلق به آلیس باشد و نقد نشده باقی بماند، میتواند ارزش اسمی داشته باشد.
2. وقتی آلیس می خواهد 10 میلیون USDT به باب منتقل کند، باید چک A را نقد کند و در کادر اطلاعات اضافی مشخص کند که 10 میلیون USDT به چک جدید (چک B) متعلق به باب و 90 میلیون USDT به چک جدید می رود. چک جدید دیگری (چک C) متعلق به آلیس که شامل 90 میلیون USDT باقی مانده است.
3. اگر باب بخواهد 10 میلیون USDT به دیو منتقل کند، باید چک B را نقد کند و در کادر اطلاعات اضافی یادداشت کند که 10 میلیون USDT به چک جدید (چک D) متعلق به دیو خواهد رفت.
4. همین روند برای هر انتقال بعدی تکرار می شود. به طور خاص، دارنده قبلی بخشی از مبلغ را برای گیرنده جدید تأیید می کند و گیرنده سپس کل تاریخچه انتقال دارایی را تأیید می کند. مشابه چک های در گردش، هر انتقال یک چک جدید ایجاد می کند و هر چک فقط یک بار (UTXO) قابل نقد کردن است. در همین حال، چکهای قدیمی (UTXO) نامعتبر میشوند و مطمئن میشوند که این حالت فقط میتواند به جلو حرکت کند و نه به عقب، که از خرج مضاعف نیز جلوگیری میکند. به این ترتیب، سوابق روی بلاکچین به طور قابل اعتمادی تغییرات وضعیت یک دارایی رمزنگاری را منعکس می کنند.
RGB، پروتکلی که برای مقیاس پذیرتر و خصوصی تر کردن بیت کوین ایجاد شده است
عملکرد بیت کوین از زمان راه اندازی این رمزارز در سال 2009 همواره به دقت تحت بررسی قرار داشته است. از آنجایی که بیتکوین تنها می تواند هفت تراکنش در ثانیه را پردازش کند، شبکه اجازه قراردادهای هوشمند مقیاس پذیر را نمی دهد. ارتقای SegWit محدودیت اندازه بلوک بیت کوین را به 4 مگابایت افزایش داد (1 مگابایت برای داده های تراکنش و 3 مگابایت برای داده های شاهد). با این حال، محدودیت هنوز پابرجاست. در همین حال، با افزایش نفوذ بیت کوین، چالش مقیاس پذیری حادتر شده است. مقیاس پذیری همچنان یک چالش اساسی پیش روی اکوسیستم بیت کوین است. امروزه، متخصصان در حال بررسی راهحلهایی با رویکردهای مختلف هستند که در درجه اول عبارتند از:
- زنجیره های جانبی شامل Liquid، Stacks، Rootstock و غیره؛
- وضعیت کانال هایی مانند شبکه لایتنینگ که برخی از تراکنش های بسیار پرتکرار را خارج از زنجیره پردازش می کنند.
- راه حل های مقیاس پذیر غیرقابل ارتقا مانند RGB و بیت کوین اسکریپت که کد بیت کوین را تغییر نمی دهند.
- راهحلهای مقیاسپذیری مبتنی بر ارتقا، از جمله Drivechain (BIP300/301) که به پشتیبانی قوی ماینرها نیاز دارند و از طریق هارد فورک به مقیاسپذیری میرسند.
تکامل RGB
پیدایش RGB را می توان به سال 2016 نسبت داد، زمانی که پیتر تاد مفهوم مهر و موم یکبار مصرف و اعتبار سنجی سمت مشتری را معرفی کرد. بر اساس این مفاهیم مهم، RGB در سال 2018 پیشنهاد شد.
در سال 2019، Orlovsky، یک توسعهدهنده اصلی RGB، که از پیشگامان توسعهی RGB بود، اجزای بسیاری را ایجاد کرد که در نهایت پروتکل RGB را تشکیل میدهند. علاوه بر این، تأسیس انجمن LNP/BP در سوئیس به ارائه استانداردهای مربوطه کمک کرد.
پس از تلاشهای توسعه گسترده، RGB نسخه 0.10 خود را در آوریل 2023 معرفی کرد.
درباره طراحی RGB
RGB به این صورت به مقیاس پذیری و محرمانگی دست می یابد:
برای مشاهده تصاویر، باید ابتدا وارد سایت شوید، یا در سایت ثبت نام رایگان کنید.
اعتبار سنجی سمت مشتری
اکثر بلاک چینهای عمومی موجود تحت یک مدل اجماع جهانی عمل میکنند، که در آن همهی نادها همهی تراکنشها را تأیید میکنند، اطلاعات تراکنشها را با یکدیگر به اشتراک میگذارند و یک وضعیت جهانی یکپارچه را حفظ میکنند.
با این حال، این مدل چندین چالش را به همراه دارد، از جمله:
- محدودیتهای مقیاسپذیری که اعتبارسنجی تمام تعاملات قرارداد را گران میکند.
- هزینه های بالا که منجر به عملیات متمرکز ناد می شود.
- عدم حفظ حریم خصوصی به دلیل اطلاعات باز تراکنشها.
ویژگی های کلیدی CSV:
- اطلاعات دقیق تراکنش خارج از زنجیره ذخیره می شود و فقط بر روی مشتری تایید می شود.
- فقط تعهدات به داده های تراکنش در زنجیره ذخیره می شود.
- اعتبار سنجی فقط برای تراکنش هایی اعمال می شود که کاربران باید از آن آگاه باشند.
از سوی دیگر، RGB برای ایجاد معادلی از مجموعه بیت کوین UTXO به پخش شبکه جهانی همه تراکنش ها متکی نیست. این بدان معناست که در حین دریافت یک پرداخت از نوع دریافتی، یک مشتری RGB نه تنها باید تأیید کند که آخرین انتقال وضعیت معتبر است، بلکه باید اعتبار یکسانی را برای همه انتقالهای حالت قبلی تا حالت پیدایش در قرارداد صدور انجام دهد. این اعتبارسنجی از پایین به بالا تاریخچه تراکنش ها در RGB همچنین از حملات پرداخت دوباره محافظت می کند.
RGB مقیاس پذیری را تنها با اعتبارسنجی تراکنش های مرتبط بهبود می بخشد. با این حال، این رویکرد ممکن است منجر به مشکلات مرتبط با در دسترس بودن داده ضعیف شود، که ممکن است به اشتراک گذاری داده ها برای بهینه سازی اعتبار سنجی پرداخت نیاز داشته باشد.
برای مشاهده تصاویر، باید ابتدا وارد سایت شوید، یا در سایت ثبت نام رایگان کنید.
مهر و موم های یکبار مصرف مبتنی بر بیت کوین
مهر و موم های فیزیکی یک بار مصرف، اتصالات پلاستیکی با شماره منحصر به فرد هستند که معمولاً برای تشخیص دستکاری شدن استفاده می شوند. در حین ذخیره سازی و حمل و نقل به عنوان مثال، به ما اطلاع می دهد که آیا درب کانتینر در حین حمل و نقل باز شده است یا خیر. مهر و موم دیجیتال یکبار مصرف مهر دیجیتال را روی یک پیام می بندد تا مطمئن شود که فقط یک بار می توان از آن استفاده کرد، که فروش دوبار یک ملک را برای فروشندگان غیرممکن می کند.
به جای استفاده از یک نهاد مورد اعتماد برای تأیید باز و بسته شدن مهرهای دیجیتال، می توان از خروجی های تراکنش خرج نشده بیت کوین (UTXO) به عنوان مهر و موم استفاده کرد. UTXO را میتوان بهعنوان مهر و مومی دید که هنگام ایجاد بسته میشود و پس از مصرف باز میشود. با توجه به قوانین اجماع بیت کوین، یک خروجی فقط یک بار می تواند خرج شود. بنابراین، مهر و موم فقط یک بار می تواند باز شود. به این ترتیب، مهر و موم های یکبار مصرف برای مرتبط کردن UTXO های بیت کوین با حالت های قرارداد خارج از زنجیره استفاده می شود و امکان اجرای انتقال حالت بعدی از طریق تراکنش های RGB خارج از زنجیره (بستن مهر) را فراهم می کند. مشابه مهر و موم های فیزیکی یک بار مصرف که برای ایمن سازی ظروف حمل و نقل استفاده می شود، مهر و موم یکبار مصرف دیجیتال یک چیز منحصر به فرد است که به طور دقیق بخشی از اطلاعات را برای جلوگیری از هزینه اضافه مهر و موم می کند.
در اینجا یک تشبیه ساده وجود دارد: ما می توانیم UTXO ها را به عنوان یک سری چک در نظر بگیریم که هر کدام با مقدار متفاوتی همراه است. هنگام پرداخت، اساساً با یک چک نقد نشده به شخصی پرداخت می کنید. علاوه بر این، باقی مانده چک در قالب چک جدید به شما باز می گردد. در این سناریو، مهرهای یکبار مصرف سوابق انتقال خاصی را به جعبه اطلاعات اضافی چک اضافه می کنند. از آنجایی که چک فقط یک بار قابل وصول است، این رویکرد از هزینههای اضافی جلوگیری می کند.
بیایید ببینیم این فرآیند در بین آلیس، باب و دیو چگونه کار می کند:
1. در ابتدا، آلیس یک دارایی RGB (به عنوان مثال USDT Tether یا USDT) با مجموع عرضه 100 میلیون صادر کرده است و اطلاعات تعهد را به یک چک معتبر (چک A) در کادر اطلاعات اضافی اضافه کرده است. چاپگر چک مجبور نیست این اطلاعات اضافی را در نظر بگیرد و چک A تا زمانی که متعلق به آلیس باشد و نقد نشده باقی بماند، میتواند ارزش اسمی داشته باشد.
2. وقتی آلیس می خواهد 10 میلیون USDT به باب منتقل کند، باید چک A را نقد کند و در کادر اطلاعات اضافی مشخص کند که 10 میلیون USDT به چک جدید (چک B) متعلق به باب و 90 میلیون USDT به چک جدید می رود. چک جدید دیگری (چک C) متعلق به آلیس که شامل 90 میلیون USDT باقی مانده است.
3. اگر باب بخواهد 10 میلیون USDT به دیو منتقل کند، باید چک B را نقد کند و در کادر اطلاعات اضافی یادداشت کند که 10 میلیون USDT به چک جدید (چک D) متعلق به دیو خواهد رفت.
4. همین روند برای هر انتقال بعدی تکرار می شود. به طور خاص، دارنده قبلی بخشی از مبلغ را برای گیرنده جدید تأیید می کند و گیرنده سپس کل تاریخچه انتقال دارایی را تأیید می کند. مشابه چک های در گردش، هر انتقال یک چک جدید ایجاد می کند و هر چک فقط یک بار (UTXO) قابل نقد کردن است. در همین حال، چکهای قدیمی (UTXO) نامعتبر میشوند و مطمئن میشوند که این حالت فقط میتواند به جلو حرکت کند و نه به عقب، که از خرج مضاعف نیز جلوگیری میکند. به این ترتیب، سوابق روی بلاکچین به طور قابل اعتمادی تغییرات وضعیت یک دارایی رمزنگاری را منعکس می کنند.
برای مشاهده تصاویر، باید ابتدا وارد سایت شوید، یا در سایت ثبت نام رایگان کنید.
