صفر تا صد BitVM؛ همه چیز را با بیت کوین پردازش کنید!

BitVM یک مدل پردازشی است که می‌تواند تورینگ کامل (Turing-complete) را به قراردادهای بیت کوین بیاورد. این تکنولوژی جدید به هیچگونه تغییری در قوانین شبکه نیاز ندارد. به جای اجرای فرآیند پردازشی در خود شبکه بیت کوین، در واقع پردازش‌ها به شکلی همانند کارکرد رول‌آپ‌های آپتیمیستیک (Optimistic rollup) در شبکه تأیید می‌شوند. در این فرآیند یک اثبات کننده (Prover) ادعا می‌کند که یک تابع بخصوص برای ورودی‌های خاص، خروجی‌های خاصی هم دارند! اگر این ادعا تکذیب شود، تأیید کننده (Verifier) می‌تواند اثبات فریب مختصر را اجرا کرده و اثبات کننده را جریمه کند. با استفاده از این مکانیزم، هر تابع قابل پردازشی در شبکه بیت کوین قابل تأیید خواهد شد.

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

 

BitVM چیست؟

طراحی قراردادهای هوشمند بیت کوین به گونه‌ایست که به عملکردهای اساسی مثل امضاها، تایم‌لاک (timelock) و هش‌‌لاک (Hashlock) محدود شده است. BitVM فضای طراحی بدیعی برای قراردادهای جامع‌تر و صد البته پردازش آفچین را خلق می‌کند. از جمله کاربردهای بالقوه این تکنولوژی می‌توان به بازی‌هایی مثل شطرنج، Go و پوکر و همچنین تأیید اثبات اعتبار (Validity Proof) در قراردادهای هوشمند اشاره کرد. علاوه بر این، پل سازی (Bridge) BTC به بلاکچین‌های، ایجاد بازار پیشبینی یا رقابت با کدهای عملیاتی (Opcode) هم ممکن می‌شود.

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

 

ساختار مدل BitVM

مشابه با رول‌آپ‌های آپتیمیستیک و پروپوزال MATT (Merkelize All The Things)، سیستم BitVM بر پایه اثبات فریب و پروتکل چالش-پاسخ پایه‌گذاری شده است. لازم به ذکر است که BitVM به هیچگونه تغییری در قوانین اجماع بیت کوین نیاز نداشته و پایه و اساس ساده‌ای هم دارد؛ به شکلی که عمدتاً بر پایه هش‌لاک‌ها، تایم‌لاک‌ها و درخت‌های تپروت بزرگ توسعه یافته است.

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

این مدل به شکلی طراحی شده که نشان دهد امکان اجرای پردازش‌های عظیم با بیت کوین وجود دارد. برای کاربردهای عملی‌تر، بهتر است که به سراغ مدل‌های کارآمدتری برویم.

 

عملکرد پروتکل بسیار ساده است: در ابتدا اثبات کننده و تأیید کننده، برنامه را در یک مدار دودویی (Binary) بزرگ گردآوری می‌کنند. اثبات کننده در یک آدرس تپروت که برای هر گِیت منطقی (Logic Gate) مدار، یک لیف اسکریپت (Leaf Script) دارد، به آن مدار متعهد می‌شود. علاوه بر این، هر دو طرف یک سری تراکنش‌ها را پیش-امضا می‌کنند تا روند چالش-امضا بین اثبات کننده و تأیید کننده قابل اجرا شود. حالا که داده‌های مورد نیاز بین دو طرف رد و بدل شد، می‌توانند سپرده‌های آنچین خود را وارد آدرس تپروت خروجی کنند.

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

 

تعهد مقدار بیت (Bit Value Commitment)

تعهد مقدار بیت، ابتدایی‌ترین رکن این سیستم است. اثبات کننده با این رکن می‌تواند مقدار یک بیت بخصوص را «0» یا «1» کند. علاوه بر این، امکان تعیین مقدار یک متغیر در اسکریپت‌ها و UTXO های مختلف را هم به اثبات کننده می‌دهد. این کار اهمیت بالایی دارد، زیرا به وسیله تقسیم پردازش در تراکنش‌های مختلف، اجرای ران‌تایم (Runtime) ماشین مجازی بیت کوین را به مراتب بالاتر می‌برد.

این پروسه شامل دو هش می‌شود: hash0 و hash1. در مراحل بعدی، اثبات کننده یا مقدار بیت را با افشای preimage0 (پیش تصویر hash0) «0» تعیین می‌کند، یا با افشای preimage1 (پیش تصویر hash1) مقدار بیت را «1» می‌کند. اگر یک زمان اثبات کننده هر دو پیش تصویر preimage0 و preimage1 را افشا کند، تأیید کننده از آن به عنوان اثبات فریب استفاده کرده و سپرده او را تصاحب می‌کند. به این کار اِکوئِوِکِیشن (Equivocation) – در فارسی به معنای ابهام و طفره – می گویند. همین جریمه کردن ابهام و طفره اثبات کننده، چیزی است که تعهد را حفظ می‌کند؛ در واقع این یک «تعهد مبتنی بر انگیزه» است.

ترکیب تعهد مقدار بیت با تایم‌لاک‌ها به تأیید کننده امکان می‌دهد تا اثبات کننده را مجبور کند که مقدار یک بیت بخصوص را در یک بازه زمانی مشخص، تعیین کند.

 

شکل 1: یک کاربرد واقعی برای تعهد 1 بیتی. برای بازگشایی این اسکریپت، اثبات کننده باید پیش تصویر hash0 یا hash1 را افشا کند. در این نمونه، اثبات کننده hash1 را افشا کرده و مقدار بیت را «1» تعیین کرده است. حالا می‌توانیم نسخه‌هایی از این تعهد را برای تعیین مقادیر بخصوص در اسکریپت‌های مختلف بکار بگیریم.

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

 

تعهد گیت منطقی (Logic Gate Commitment)

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

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

 

شکل 2: تعهد گیت منطقی برای یک عملیات NAND. اجرای این اسکریپت نیاز به افشای مقادیر تعهد بیت‌های A، B و C دارد: مثل A NAND B = C.

(در اینجا به منظور ساده سازی مطلب، فرض می‌کنیم که کد عملیاتی OP_NAND وجود دارد. با اینکه این کد وجود ندارد ولی به سادگی می‌تواند با استفاده از دستور OP_BOOLAND و OP_NOT فراخوانده شود)

 

تعهد مدار دودویی (Binary Circuit Commitment)

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

البته ممکن است که تَپ‌تری (Taptree) بسیار بزرگ شود و میلیاردها اسکریپت تپ‌لیف (Tapleaf Script) داشته باشد، ولی تاثیر آن روی شبکه بسیار اندک خواهد بود.

 

شکل 3: یک مدار نمونه که 8 گیت NAND متفاوت و 4 ورودی A, B, C و D دارد. با استفاده از میلیاردها گیت می‌توانیم هر تابعی را تعریف کنیم.

 

شکل 4: برای هر گیت، آدرس تپروت اثبات کننده حاوی یک لیف اسکریپت با یک تعهد گیت مرتبط با آن است. این به اثبات کننده اجازه می‌دهد که هر زمانی که بخواهد، مقادیر ورودی‌های مدار (در اینجا A, B, C و D) را تغییر دهد.

 

چالش‌ها و پاسخ‌ها

تعهد به یک مدار کافی نیست. برای تکذیب یک ادعای اشتباه، تأیید کننده باید بتواند ادعای اثبات کننده را به چالش بکشد. این اتفاق با پیش-امضای یک سری تراکنش‌ها توسط دو طرف ممکن می‌شود. تراکنش‌ها به این شکل بهم متصل شده‌اند: چالش => پاسخ => چالش => پاسخ =>… اگر هر یک از طرفین به تعهد عمل نکند، بعد از گذشت مدتی بخصوص، طرف دیگر برنده چالش شده و می‌تواند سپرده‌ها را بردارد. تا زمانی که طرفین همکاری می‌کنند، در کنار هم می‌توانند هر قراردادی را با امضای 2 از 2 اجرا کنند. مکانیزم زیر تنها در زمان فریب هر طرف اجرا می‌شود.

 

شکل 5: یک مجموعه تراکنش پیش-امضا شده برای اجرای چندین دور چالش-پاسخ. این سری در طول راه‌اندازی ایجاد می‌شود. ویکی با باز کردن یکی از هش‌لاک‌ها در تپ‌اسکریپت خود، یک چالش انتخاب می‌کند. این کار یک تپ‌اسکریپت بخصوص را برای پائول باز می‌کند و او را مجبور به اجرای می‌کند. اسکپریپت پائول را مجبور می‌کند تا تعهد گیت مطرح شده توسط ویکی را افشا کند. هرگونه ادعای اشتباه می‌تواند با تکرار این دستورالعمل برای چند دور، تکذیب شود.

اگر اثبات کننده همکاری بیرون از بلاکچین با تأیید کننده را متوقف کند، تأیید کننده به راهی درون شبکه نیاز دارد تا طرف مقابل را مجبور به عمل کند. تأیید کننده این کار را با بازگشایی یک هش‌لاک می‌کند: هر یک تپ‌لیف‌های NAND در UTXO اثبات کننده، تنها زمانی قابل خرج کردن است که اثبات کننده پیش تصویر نزد تأیید کننده را بداند. از این رو، اثبات کننده می‌تواند به وسیله افشای ورودی و خروجی خود ثابت کند که یک تپ‌لیف (Tapleaf) به درستی اجرا می‌شود، ولی فقط زمانی که تأیید کننده با افشای پیش تصویر برای هشی که از آن تپ‌لیف محافظت می‌کند، آن را برایش «باز کند». حالا تأیید کننده با بکارگیری جستجوی دودویی، به سرعت می‌تواند اشتباه اثبات کننده را بعد از چند دور چالش-پاسخ تشخیص دهد.

 

شکل 6: بعد از هر پاسخ، ویکی می‌تواند اکوئوکیشن را جریمه کند. اگر پائول دو مقدار متناقض را برای یک متغیر افشا کند، ویکی فوراً برنده چالش شده و می‌تواند سپرده پائول را بردارد. در واقع ویکی با افشای هر یک از تعهد بیت پائول، اکوئوکیشن او را ثابت می‌کند.

 

ورودی‌ها و خروجی‌های اثبات کننده تعهد ها

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

این امکان وجود دارد که مقادیر زیاد داده هم با تبادل پیش از موعد، ولی به صورت رمزنگاری شده، پردازش شود. با این روش، اثبات کننده می‌تواند در مراحل بعدی کلید بازگشایی رمز را افشا کند. ورودی‌های چند طرفی (Multi-party Input) هم ممکن است؛ این یعنی گیت‌ها می‌توانند تعهد بیت را از هر دو طرف بپذیرند.

 

محدودیت‌ها و چشم‌انداز آینده

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

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

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

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

 

جمع بندی نهایی

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

 

منبع : BitVM.org