قبل از اینکه باحال بودند: عهد و پیمان در تولید Nn Liquid

قبل از اینکه باحال بودند: عهد و پیمان در تولید Nn Liquid

از زمانی که جامعه بیت‌کوین بحث‌های پیرامون بهینه‌سازی میثاق‌ها را آغاز کرد، علاقه فزاینده‌ای برای کسب اطلاعات بیشتر در مورد معاوضه‌های آن‌ها و میثاق‌هایی که قبلاً در شبکه Liquid مستقر شده‌اند، وجود داشته است.

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

تاریخچه میثاق های روی مایع

Covenants on Liquid را می توان به استقرار اولین زنجیره جانبی Elements، Alpha ردیابی کرد. این زنجیره جانبی کدهای عملیاتی OP_CHECKSIGFROMSTACK (CSFS) و OP_DETERMINISTICRANDOM را همراه با تعدادی دیگر به عناصر معرفی کرد. آلفا همچنین نسخه‌های ثابتی از کدهای فعال غیرفعال‌شده در بیت‌کوین اولیه را فعال کرد، مانند OP_CAT – کدی که بسیاری از آنها در گفتگوهای رو به رشد در رسانه‌های اجتماعی دوباره آن را انتخاب می‌کنند. این اپکدهای جدید بیانگر نسخه بیت کوین اسکریپت موجود در Elements را بیشتر بهبود بخشیدند و یک خزانه اثبات مفهوم Möser-Eyal-Sirer با استفاده از CSFS برای نشان دادن امکانات جدید توسعه یافت.

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

برای ساده سازی ساخت پیمان، بیش از 30 کد عملیات جدید به نام کدهای درون نگری در ارتقاء Taproot Liquid برای یک رویکرد ماژولارتر معرفی شد. برای مثال، کدهای درون نگری با CSFS، با قرار دادن آن در پشته، بازرسی بخش‌های دانه‌دار تر تراکنش را در طول یک خرج فعال می‌کنند. این امر مسئولیت جمع آوری داده های جزئی تراکنش از طریق شاهد و در نتیجه هش امضا در پشته را کاهش می دهد.

پیشنهادات میثاق پیشرو

در حال حاضر، جامعه بیت کوین در حال بحث در مورد لیستی از پیشنهادات میثاق بالقوه است، از جمله SIGHASH_ANYPREVOUT (APO)، OP_TXHASH، CSFS، OP_CAT، OP_TLUV، کد اپکد MATT OP_CHECKCONTRACTVERIFY (CCV)، OP_VACHVERTECIFTE، و OP_VAULTECIFTEMPTVLACTV. Simplicity، یک زبان اسکریپت نویسی نسل بعدی که می تواند عملکردی مشابه بسیاری از میثاق ها را در سطح پایین تر اجرا کند، همچنین یک مسیر بالقوه برای بیت کوین است (ما بعداً به این موضوع خواهیم پرداخت).

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

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

به غیر از کدهای عملیاتی، پیشنهاداتی برای سیگش ها برای فعال کردن میثاق ها وجود داشته است. دو پیشنهاد محبوب برای این منظور APO و SIGHASH_GROUP هستند. APO تکاملی از اپکد SIGHASH_NOINPUT است که به طور گسترده به عنوان یک پیش نیاز برای پیاده سازی eltoo شناخته شده است. یکی از بسیاری از پیشرفت‌هایی که با eltoo امکان‌پذیر شد، حذف مکانیسم جریمه است که طرف مقابل را مجبور می‌کند هنگام پخش یک وضعیت کانال قدیمی، وجوه خود را از دست بدهد. این امکان ایجاد یک شبکه لایتنینگ کاربرپسندتر و کارآمدتر را فراهم می کند.

دستیابی به عملکرد مشابه با Opcodes مایع

در حالی که Liquid کدهای عملیاتی CTV و VAULT را ندارد، دارای CSFS و CAT برای میثاق‌ها است. با استفاده از این کدهای عملیاتی با تعریف محدودتر با کدهای درون نگری فوق الذکر، توسعه دهندگان امکانات مالی جدیدی را با عملکردی مشابه CTV و VAULT برای تقویت زنجیره جانبی باز کرده اند.

برای مثال، Burak، یک توسعه‌دهنده با تجربه Liquid و خالق پروتکل لایه ۲ Ark، شبیه‌سازی VAULT را با استفاده از کدهای عملیاتی Liquid Covenant در یک بحث با جیمز اوبیرن نشان داده است. ایکس.

به طور مشابه، راهی برای دستیابی به عملکرد APO با CSFS امکان پذیر شد. این نسخه آزمایشی از کدهای عملیاتی مختلفی استفاده می‌کند که پروتکل‌های لایه ۲ مانند eltoo را در Liquid امروزی فعال می‌کنند، اما از پیچیدگی بیشتر و اندازه تراکنش بزرگ‌تر در مقایسه با استفاده پیشنهادی از APO-type covenant رنج می‌برد. علاوه بر این، ساخت و ساز برای تراکنش‌های Taproot اعمال نمی‌شود، که شکل پیچیدگی خود را معرفی می‌کند.

Opcodes مایع در عمل

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

Fuji Money’s Fuji USD (FUSD)، یک استیبل کوین الگوریتمی که توسط Vulpem Ventures توسعه یافته است، نمونه قابل توجه دیگری است. برای حفظ میخ خود صرفاً به اطلاعات اوراکل متکی است و می تواند به صورت غیرمتمرکز صادر شود. برای انجام این کار از ترکیبی از تأیید امضا و کدهای درون نگری استفاده می کند، و مهم ترین بخش این است که همه آن ها روی زنجیره قابل ممیزی هستند.

از دیگر کاربردهای میثاق ها در Liquid می توان به قراردادهای اختیار معامله و وام های محرمانه مبتنی بر دارایی اشاره کرد. تیم تحقیقاتی Blockstream سال گذشته وایت پیپری درباره اولی منتشر کرد (به پست وبلاگ همراه مراجعه کنید) که توضیح می‌داد چگونه می‌توان چنین قرارداد اختیاری را با استفاده از مجموعه جدیدی از کدهای عملیات درون‌نگر ایجاد کرد. این کدهای عملیاتی جدید به کاربران اجازه می‌دهند تا به‌طور غیرقابل اعتماد توکن‌هایی ایجاد کنند که هر دو طرف یک را نشان می‌دهند. قرارداد اختیار خرید تحت پوشش و موقعیت مخالفی را که می‌خواهند بفروشند. قراردادهایی که به این روش انجام می‌شوند از پر کردن جزئی نیز پشتیبانی می‌کنند، به این معنی که کاربری که قرارداد را ایجاد کرده است می‌تواند موقعیت‌هایی را بفروشد که نشان‌دهنده مضرب حداقل مقدار مشخص شده توسط کاربر از دارایی وثیقه است که «اندازه قرارداد» نامیده می‌شود.

چرا اول Liquid نه؟

از آنجایی که اکوسیستم بیت کوین به بحث های سالم در مورد کدهای عملیاتی میثاق ادامه می دهد، Liquid مجموعه ای از ابزارهای خاص خود را ارائه می دهد که اهداف مشابه اما با پیاده سازی های متمایز را تامین می کند. همانطور که گفت و گو در حال تکامل است، مشاهده تعامل بین پیشنهادات بومی بیت کوین و ویژگی های مرتبط با میثاق واقعی و زنده Liquid و شبیه سازی پیشنهادات میثاق بیت کوین که با استفاده از Elements Script پیاده سازی شده اند، جذاب خواهد بود.

یکی دیگر از فناوری های جدید در افق Simplicity است، یک زبان برنامه نویسی قابل تایید برای بلاک چین. زبان Simplicity با عملیاتی با معنایی بسیار محدود تعریف می شود که می تواند برنامه های گویا را در صورت ترکیب با هم بسازد. این زبان همچنین قابل تأیید است، به این معنی که می توان روش هایی را برای اثبات ریاضی ادعاهای مطرح شده در برنامه های Simplicity ایجاد کرد.

ماهیت بیانی Simplicity اجازه می دهد تا کدهای عملیاتی پیمان از اسکریپت به طور یکپارچه منتقل شوند و اطمینان بیشتر و رفتارهای غیرمنتظره کمتری را تضمین کنند. محقق بیت کوین سانکت کنجالکار قبلاً این کار را برای CTV انجام داده است. با استفاده از s-lang، یک زبان برنامه نویسی مبتنی بر بیت کوین خواناتر که به Simplicity کامپایل می شود، او توانست معناشناسی را در یک اثبات مفهومی قابل اجرا تکرار کند که امروزه برای هرکسی در دسترس است.

توسعه دهندگان بیت کوین به زودی فرصت استفاده از s-lang را در یک محیط واقعی به لطف ادغام Liquid از Simplicity خواهند داشت که برای سه ماهه دوم 2024 هدف گذاری شده است. پیش نویس روابط عمومی برای بررسی در لینک زیر موجود است.

با یک تاریخ طولانی از Liquid به‌عنوان اولین پذیرنده ایده‌هایی که بعداً به بیت‌کوین منتقل شده‌اند، یک پیشنهاد برای کسانی که می‌خواهند قابلیت اجرای طرح‌های خود را به نمایش بگذارند این است که آن را به‌طور زنده در Liquid امتحان کنند تا ابتدا ایده‌ها را اعتبار سنجی کنند – زیرا چندین کد عملیات مرتبط با میثاق نشان داده شده است. قابل تقلید با استفاده از کدهای عملیاتی پیمان مایع و درون نگری موجود باشد.

بنابراین، دفعه بعد که کسی یک پیمان جدید را پیشنهاد کرد، ارزش این را دارد که بپرسیم: چرا ابتدا آن را روی Liquid امتحان نکنید؟

این یک پست مهمان توسط رندی نار. نظرات بیان شده کاملاً متعلق به خود آنها است و لزوماً نظرات BTC Inc یا مجله Bitcoin را منعکس نمی کند.