CatVM چیست؟

Taproot Wizards روز گذشته یک کارتون به نام CatVM منتشر کرد. من به آن به عنوان یک مقاله سفید اشاره نمی کنم، این اسناد علمی واقعی برای بزرگسالان هستند. در این کارتون که در میان روایت‌های پوچ کودکانه آمیخته شده بود، چند بینش فنی ارزشمند در مورد پیشنهادهای مقیاس‌بندی مختلف در اکوسیستم بیت‌کوین وجود داشت. البته، در مد واقعی کارتونی، مدفون بین اغراق وحشیانه و آراستگی.

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

بلوک های ساختمانی

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

توضیح مکانیک کامل نحوه انجام این کار اساساً یک مقاله است، بنابراین من کاری را انجام می‌دهم که معمولاً انجام نمی‌دهم و به عنوان «جادو» از آن چشم‌پوشی می‌کنم. (در اینجا توسط Andrew Poelstra توضیح داده شده است) آنچه که این “جادو” به شما امکان می دهد با ایجاد امضاهای غیر استاندارد Schnorr و با کمک OP_CAT انجام دهید، ساخت تراکنشی است که بررسی امضا در پشته اسکریپت است. این به شما امکان می دهد تا بتوانید قسمت های خاصی از تراکنش را دقیقاً همان طور که از قبل تعریف شده است، اعمال کنید. همچنین به شما این امکان را می دهد که خروجی تراکنش قبلی را در پشته قرار دهید، به این معنی که می توانید خروجی های تراکنش مخارج را با خروجی های تراکنش قبلی مقایسه کنید. این به شما امکان می دهد با مقایسه آنها تضمین کنید که بخش های خاصی از خروجی های تراکنش قبلی با بخش های خاصی از خروجی های جدید مطابقت دارند. یعنی فیلمنامه، یا یک مقدار. بنابراین می‌توانید بخش‌هایی از خروجی‌های قدیمی را به خروجی‌های جدید «به جلو ببرید» و آن را اجرا کنید.

کار دیگری که می‌توانید با OP_CAT انجام دهید، که برای اثبات نیازی به دستکاری و آزمایش Rijndael نداشت، تأیید شاخه‌های درخت مرکل است. از آنجا که می‌توانید اقلام را CAT روی هم قرار دهید، و بیت‌کوین از قبل از هش کردن داده‌ها در پشته پشتیبانی می‌کند، می‌توانید به آرامی یک ریشه درخت مرکل را از یک گره برگ با گره‌های داخلی بسازید. دو قطعه را با هم هش کنید تا یک هش به دست آید، آن را با جفت هش هش کنید و غیره. در نهایت شما ریشه هش را روی پشته دریافت می کنید. سپس می‌توانید آن را با OP_EQUAL با هش ریشه از پیش تعریف‌شده در اسکریپت قفل مقایسه کنید.

برداشت یک طرفه

این دو بلوک سازنده برای تسهیل مکانیسم خروج یکطرفه از یک گروه UTXO مشترک کافی است. یک ریشه merkle را می توان با استفاده از OP_RETURN یا مکانیزم دیگری که به یک گره برگ برای هر کاربر متعهد می شود، در یک تراکنش جاسازی کرد. اسکریپت UTXO را می توان به گونه ای ساختار داد که هر کاربری با تعادل می تواند تلاش کند آن را پس بگیرد. برای انجام این کار، آن‌ها به شعبه مرکل تعهد می‌دهند که مبلغی را که به آن تعلق می‌گیرد، گواهی مجوز مانند یک کلید عمومی برای بررسی امضا، و ساخت تراکنش روی پشته برای تأیید شرایط مناسب.

مشابه خزانه OP_CAT Rijndael، این تراکنش برداشت می تواند به عنوان یک نقطه مرحله عمل کند. وجوه کاربران با یک قفل زمانی محدود می‌شود و تا زمانی که منقضی نشده باشد، نمی‌توانند برداشت را تکمیل کنند. در هر زمانی قبل از انقضای قفل زمانی، هر کاربر دیگری می تواند یک اثبات تقلب ایجاد کند تا برداشت را متوقف کند و وجوه را به اسکریپت UTXO گروه بازگرداند. آنها می توانند این کار را به دلیل توانایی OP_CAT برای تأیید درختان مرکل انجام دهند. اگر قبلاً شخصی از یک شعبه merkle خاص برای برداشت وجوه از UTXO استفاده کرده باشد، آنگاه در یک بلوک در جایی گنجانده شده است. با ساختن یک تراکنش حاوی اثبات SPV آن تراکنش در داخل یک بلوک واقعی، که می تواند از OP_LESSTHANOREQUAL برای تأیید اینکه هدر بلوک با حداقل مشکل مواجه است، استفاده کند، می توانند ثابت کنند روی پشته که قبلاً از شاخه مرکل استفاده می شد. این اجازه می دهد تا از برداشت های تکراری جلوگیری شود.

علاوه بر این، از آنجایی که می‌توانید از ترفند «CAT on the stack» استفاده کنید تا اطمینان حاصل کنید که قطعات خاصی از تراکنش قبلی باید در تراکنش بعدی گنجانده شوند، می‌توانید تضمین کنید که ریشه مرکل فعلی پس از یک تراکنش موفق به تراکنش بعدی منتقل می‌شود. برداشت از حساب. همچنین می‌توانید تضمین کنید که تغییر ناشی از برداشت به اسکریپت اشتراک‌گذاری گروهی بازمی‌گردد. این تضمین می کند که پس از برداشت یک کاربر وجوه خود، تغییر UTXO با اسکریپتی قفل می شود که به هر کاربر باقی مانده امکان برداشت و غیره را می دهد. هر کاربر می تواند در هر زمان و به هر ترتیبی به صورت یک طرفه وجوه خود را برداشت کند، با این ضمانت که باقی مانده وجوه همچنان در دسترس بقیه کاربران است.

قسمت VM

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

لازمه استفاده از تراکنش‌های از پیش امضا شده به این صورت است که در پویایی چالش/پاسخ، می‌توانید تضمین کنید که سکه‌ها در درخت ریشه بزرگ که آن را رمزگذاری می‌کند، خرج می‌شوند، مگر اینکه شرایط خروج از یک طرف به دست آید. OP_CAT و توانایی “انتقال” داده‌های تراکنش‌های قبلی به شما این امکان را می‌دهد که بدون نیاز به تراکنش‌های از پیش امضا شده، تضمین کنید.

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

قطعه گم شده

یکی از مواردی که OP_CAT فعال نمی‌کند، به‌روزرسانی ریشه درخت مرکل است که تعادل کاربر را به‌طور قابل تأیید نشان می‌دهد. می‌تواند یک دولت متعهد را فعال کند تا برداشت‌های یک‌طرفه را تسهیل کند، اما این به این دلیل است که یک بخش کامل از درخت در واقع روی زنجیره قرار گرفته و تأیید می‌شود. به روز رسانی آن روت خارج از زنجیره طبق تعریف به این معنی است که داده ها را روی زنجیره قرار نمی دهید. این نشان دهنده یک مشکل است. تنها با CAT هیچ راهی وجود ندارد که به طور موثر تأیید کند که همه تغییرات در درخت مرکل به درستی توسط کاربران مربوطه مجاز شده است.

باید به کسی اعتماد کرد، و به دلیل ماهیت چیزهایی که می‌توانند UTXO را در هر کجا و در هر کجا که می‌خواهند خرج کنند، به طور موثر یک ریشه حالت قدیمی را با یک جدید جایگزین کند تا همه تغییرات تعادل خارج از زنجیره را نشان دهد. برای انجام این کار به روشی غیرقابل اعتماد، علاوه بر OP_CAT، یک کد عملیاتی جدید مانند OP_ZKVERIFY لازم است.

اگر چه این پایان جهان بدون OP_ZKVERIFY نخواهد بود. نهادی که ریشه merkle را برای انتقال‌های خارج از زنجیره به‌روزرسانی می‌کند، می‌تواند یک n-از-n چند علامتی باشد، که 100٪ از شرکت‌کنندگان باید هر گونه تغییر ریشه را امضا کنند. این به همان مدل اعتماد مبتنی بر میخ های BitVM خلاصه می شود، جایی که تا زمانی که یک شرکت کننده صادق وجود داشته باشد، سرمایه هیچ کس نمی تواند دزدیده شود. با این حال، این یک پیشرفت قابل توجه نسبت به طرح های موجود BitVM است، اما در مورد فرآیند برداشت.

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

بسته بندی

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

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

من در آینده نزدیک انتظار هیچ دموی مشخصی را ندارم، اما قطعاً به نظر من ایده خوبی است و چیزی ارزش بررسی دارد. همچنین نشان می دهد که جادوگران کمی بیشتر از پمپاژ jpeg های احمقانه انجام می دهند.