منظور از MAST برای بیتکوین چیست؟
Merklized Abstract Syntax Tree یا MAST یک پیشنهاد برای بیتکوین است که امکان تراکنش هایی با اندازه کمتر، حریم خصوصی بیشتر و قراردادهای هوشمند بزرگ تر را فراهم می کند. این مقاله به بررسی نکات پایه ای MAST و مزایای بالقوه آن می پردازد و خلاصه ای از پروپوزال های موجود ارائه شده برای اضافه کردن به پروتکل بیتکوین را ارائه خواهد کرد.
مشکل: داده هایی از اسکریپت که استفاده نمی شوند
ساتوشی ناکاموتو (سازنده بیتکوین) ویژگی جالبی به بیتکوین اختصاص داده که در وایت پیپر اصلی توضیح داده نشده است. به جای نیاز به یک کلید عمومی (public key) برای دریافت بیتکوین و خرج کردن آن از طریق یک امضای دیجیتالی، ناکاموتو به کاربران امکان نوشتن برنامه (که به آن اسکریپت گفته می شود) را داده که می توانند بعنوان امضاها و کلیدهای پویا (دینامیک) عمل کنند.
زمانی که چنین اسکریپتی تعریف می کنید -که بصورت پیشفرض در همه کیف پول ها وجود دارد- پروتکل اجماعِ بیتکوین به هیچ فردی اجازه برداشت بیتکوین های شما را نمی دهد، مگر اینکه اسکریپت یاد شده، مقدار True (صحیح) برگرداند. این امر به شما اجازه تعریف کردن محدودیت های لازم و مورد نظرتان را می دهد که به این موضوع قیود یا encumbrances گفته می شود؛ محدودیت هایی نظیر اینکه تراکنش مربوط به خرج کردن برای اینکه اجرا شود، به امضا شدن توسط کلید خصوصی شما نیاز داشته باشد.
موانع و محدودیت های بیشتری همانند مثالی که در ادامه استفاده خواهیم کرد نیز قابل اعمال است.
مثال: آلیس (Alice) می خواهد امکان فروش بیتکوین هایش را در هر زمانی که می خواهد داشته باشد، اما او می خواهد که اگر بیتکوین هایش طی سه ماه خرج نشد (شاید چون مرده باشد و یا توان فروختن آن ها را نداشته باشد)، اعضای خانواده او یعنی باب (Bob) و چارلی (Charlie) بتوانند بیتکوین های او را داشته باشند؛ البته تا زمانی که هر دو بتوانند روی اینکه این بیتکوین ها کجا خرج شود توافق کنند.
“اسکریپت قید” (یا encumbrance script) زیر که سیاست بالا را نیز اعمال می کند نه تنها شامل کلید عمومی آلیس می شود (کلیدی که برای تایید امضایی از کلید خصوصی او لازم است)، بلکه شامل چند منطق شرطی، شرط زمانی و کلید عمومی برای باب و چارلی نیز می شود.
در پروتکل فعلی بیتکوین، زمانی که بیتکوین های آلیس خرج می شود، تمام داده های بالا باید به بلاکچین اضافه شود. این موضوع شامل بخش هایی از اسکریپت که در مراقع خاص استفاده نمی شوند هم می شود؛ مثلا بخش مربوط به کلیدهای عمومی باب و چارلی در زمانی که آلیس بیتکوین های خود را خرج می کند.
داده هایی اینچنینی از اسکریپت که استفاده نمی شوند باعث افزایش سایز تراکنش ها، کاهش حریم خصوصی با در اختیار قرار دادن اطلاعاتی اضافه بر حد نیاز و مهم تر از همه محدود کردن قراردادهای هوشمند می شود؛ در این حالت محدود شدن قراردادهای هوشمند به جای آنکه بخاطر هزینه های اعتبارسنجی آن ها باشد، بخاطر اندازه آنها است. MAST بدنبال بهبود این وضعیت از طریق حذف لزوم قرار دادن چنین قسمت های بلااستفاده ای از اسکریپت در بلاکچین است.
خاستگاه MAST
ایده پشت MAST از دو مفهوم درخت نحو انتزاعی (abstract syntax tree) و درخت مرکل (merkle tree) می آید. درخت های نحو انتزاعی یا AST روشی برای توضیح یک برنامه از طریق تقسیم آن به قسمت های کوچکتر است که باعث آسان تر شدن آنالیز و بیهنه سازی آن برنامه می شود. برای ایجاد یک AST، تمام توابع را به وابستگی هایشان متصل می کنید تا زمانی که تمام وابستگی ها مشخص شوند. درخت زیر یک AST از مثال بالا است:
از طرف دیگر، درخت های مرکل این امکان را فراهم می کنند که بدون آنکه نیازی به معرفی کل مجموعه باشد، عضویت یک عنصر خاص در آن مجموعه را تایید کنید. برای مثال کیف پول های SPV بیتکوین برای صرفه جویی در پهنای باند از درخت های مرکل استفاده می کنند؛ این کیف پول ها بدین صورت عمل می کنند که عضویت تراکنش های دریافتی در یک بلاک را بدون دانلود کردن کل بلاک تایید می کنند.
در شکل زیر می توانید نمونه ای از یک درخت مرکل را ببینید:
ایجاد درخت مرکل بدین صورت است که هر عضو بصورت جداگانه هش می شود و یک شناسه یکتای کوتاه برای آن عضو ساخته می شود. سپس هر کدام از آن شناسه ها با یک شناسه دیگر جفت می شوند و دوباره هش می شوند که باعث بوجود آمدن یک شناسه یکتا برای آن جفت از شناسه ها می شود. این مراحل آنقدر ادامه پیدا می کند تا تنها یک شناسه باقی بماند که به آن شناسه “ریشه مرکل” یا “merkle root” گفته می شود. ریشه مرکل تنها در چند بایت داده می تواند کل مجموعه را شناسایی کند.
برای تایید اینکه یک عضو خاص، عضو مجموعه هست یا نه، کسی که تمام مجموعه را دارد شناسه های مورد نیاز را در اختیار ما قرار می دهد تا از این طریق، آن عضو خاص را به ریشه مرکلِ کل مجموعه وصل کنیم. این امر ثابت می کند که آن عضو به مجموعه مورد نظر تعلق دارد؛ به این کار merkle proof با اثبات مرکل گفته می شود.
بطور خلاصه تکنیک پشت AST به شما امکان تقسیم برنامه به اجزا جداگانه را می دهد و درخت مرکل به شما امکان تایید اجزای مختلف متعلق به یک برنامه کامل بدون نیاز به معرفی کل برنامه را می دهد. این ها مبنای MAST است که به خرج کنندگان اجازه می دهد که قسمت های استفاده نشده از قیود (encumbrances) را با “اثبات مرکل” جایگزین کنند که باعث کاهش اندازه تراکنش، افزایش حریم خصوصی و قابلیت ایجاد قراردادهای هوشمند بزرگتر را می دهد.
مثالی از MAST
بیایید مثال قیدی بالا را به زیر-اسکریپت های جداگانه (sub-script) تقسیم کنیم که دو خروجی ممکن را برای ما فراهم می کند:
- آلیس می تواند بیتکوین های خود را در هر زمانی خرج کند (پایین، سمت چپ)
- یا: بعد از سه ماه که بیتکوین های آلیس خرج نشده باقی ماند، باب و چارلی می توانند بر سر اینکه بیتکوین های آلیس را کجا خرج کنند توافق کنند (پایین، سمت راست)
حالا یک درخت مرکل بر پایه این دو زیراسکریپت مستقل می سازیم:
ریشه مرکل در این درخت بصورت منحصربفرد اعتبار آلیس را تنها در ۳۲بایت از داده مشخص می کند. سپس آلیس از یک قید جایگزین استفاده می کند که می گوید فرد خرج کننده باید یک “اثبات مرکل” ارائه کند که ریشه مرکل را به یکی از زیر-اسکریپت ها متصل کند و آن زیر-اسکریپت نیز باید مقدار True برگرداند.
اثبات مرکل به همراه زیر-اسکریپت را می توان به یکی از دو صورت زیر نمایش داد. نمونه های زیر به اینکه می خواهیم چه زیراسکریپتی استفاده کنیم بستگی دارد.
مزیت شماره ۱: تراکنش های کوچکتر
بررسی مزایای MAST را با نگاهی به نوع عملکرد آن در امکان ایجاد تراکنش های کوچکتر برای کاربرانِ قیود پیچیده بررسی می کنیم.
در مثال قسمت بالا، از قیدی با دو زیر-اسکریپت استفاده کردیم: یا آلیس خودش دارایی هایش را خرج کند و یا باب و چارلی پس از سه ماه انتظار دارایی آلیس را خرج کنند. بیایید وضعیتی نامتناهی را بررسی کنیم؛ وضعیتی که یک زیر-اسکریپت دیگر در آن داشته باشیم و آن زیر-اسکریپت بگوید که بعد از سه ماه و یک روز، دَن (Dan) و ادیت (Edith) می توانند سرمایه را خرج کنند. و یا یک زیر-اسکریپت چهارم که می گوید بعد از سه ماه و دو روز، فرد (Fred) و جورج (Georg) می توانند دارایی را خرج کنند و الی آخر.
این امر امکان ساخت طرح زیر را برای ما فراهم می کند. این طرح تعداد زیر-اسکریپت ها و میزان داده های قیدیِ مورد نیاز برای اضافه کردن به بلاکچین “با MAST” (with MAST) و “بدون MAST” (without MAST) جهت ممکن ساختن این کار را نشان می دهد.
هزینه اسکریپت های بدون MAST بصورت خطی افزایش می یابد در صورتی که با MAST تنها لگاریتمی افزایش پیدا می کند.
اگر صرفه جویی در استفاده از بایت ها اولین هدف باشد، این موضوع را می توان بهینه تر هم کرد. در بسیاری از قیود، افرادی که خرج می کنند بیشتر از یک شرط استفاده می کنند؛ برای مثال، آلیس امیدوار است که زندگی طولانی داشته باشد، در نتیجه درخت مرکل مختص به خود را می سازد تا شرایط مربوط به خرج کردن او همیشه نزدیک به بالای درخت باشد و تمام شرایط دیگر زیر آن قرار بگیرند.
اینجا دو اندازه مختلف برای اثبات مرکلِ MAST وجود دارد؛ یکی بهترین حالت (Best Case در شکل) است که در آن آلیس زنده باشد و خودش بیتکوین ها را خرج کند، و موارد دیگر اینکه آلیس مرده باشد و ذینفعان او بیتکوین ها را خرج کنند. این اندازه ها را در طرح قبلی قرار می دهیم:
همانطور که می بینیم، حالا آلیس تعداد بایت هایی که استفاده می کند همیشه هم اندازه با تعداد بایت های بهترین شرایط (best case) است و اهمیتی هم ندارد که او چه مقدار ذینفع بالقوه به قیود خود اضافه کند.
میتوانیم ببینیم که مهم نیست آلیس چه انتخابی داشته باشد، MAST می تواند قیودِ با چندین زیر-اسکریپت را کوچکتر کند و اندازه تراکنش ها را کاهش دهد تا کاربران بتوانند کارمزدهای کمتری پرداخت کنند و بلاک ها نیز بتوانند تعداد بیشتری از تراکنش های پیشرفته را در خود جای دهند.
مزیت شماره ۲: حریم خصوصی بیشتر
از آنجایی که در این مقاله به بررسی مثال آلیس پرداختیم، پس با تمام جزئیات قیود آشنایی دارید؛ اما فرض کنید که تمام چیزی که می توانید ببینید داده ای ست که در زمان خرج شدن بیتکوین ها توسط آلیس به بلاکچین اضاقه می شود (تصویر زیر، مثال سمت چپ):
با این اطلاعات نمی توانید بفهمید که آیا فرد دیگری غیر از آلیس هم می تواند به دارایی ها دسترسی داشته باشد یا نه، و یا اینکه چه شرایطی آن ها را در خرج کردن این سرمایه محدود می کند. بخاطر اینکه از MAST استفاده شده، می توانید حدس بزنید که احتمالا یک سری شرایط وجود دارد، اما این تنها یک حدس است؛ ممکن است آلیس تنها در حال تظاهر به این موضوع باشد که قسمت های قابل خرج دیگری از درخت مرکل او وجود دارد.
اگر تمام آنچه که می دیدید شاخه ی دیگر بود (شکل بالا، مثال سمت راست) نمی توانستید بفهمید که آیا این سرمایه، پیش از زمان انقضا (سه ماه) قابل خرج کردن بوده یا نه و یا اینکه آیا یک نفر دیگر (آلیس) می توانسته آن را خرج کند یا نه. باز هم ممکن بود حدس بزنید که شرایط دیگری نیز در کار است، اما تنها با نگاه به بلاکچین نمی توانستید از این موضوع مطمئن باشید.
برای برخی از کاربران، امکان مخفی نگه داشتن قیود شرطی می تواند بسیار مهم باشد؛ مثلا برای کسب و کارهایی که می خواهند توافقات قرارداد هوشمند آن ها بصورت محرمانه و خارج از دید رقبای احتمالی باشد. این موضوع با برخی از آلتکوین هایی که ادعا می شود برای قراردادهای هوشمند طراحی شده اند در تناقض است، چرا که برای هیچ قسمتی از قراردادهایشان حریم خصوصی ارائه نمی کنند.
حریم خصوصی می تواند مزیت دیگری نیز برای تمام کاربران بیتکوین داشته باشد، حتی آن دسته از کاربرانی که نسبت به خصوصی بودن قیود بی تفاوت هستند. فرض کنید آلیس تنها شخصی ست که از قالب قیدی که در قسمت اول مقاله مطرح شد استفاده می کند (همان قالبی که از MAST استفاده نمی کند). از آنجایی که تمام قیود عمومی هستند، هر کسی با نگاه به مواردی که در آن از این قالب استفاده شده، می تواند تمام وضعیت های مربوط به خرج کردن بیتکوین از طرف آلیس را مشاهده کند؛ این موضوع حریم خصوصی آلیس را بطور کامل خدشه دار می کند.
فرض کنید فردی درباره چگونگی قیود آلیس اطلاع داشته باشد، در اینصورت می تواند به استخراج کنندگان رشوه دهد و یا آن ها را مجبور کند که تراکنش های آلیس را استخراج (تایید) نکنند تا از این طریق آلیس را از خرج کردن بیتکوین هایش باز دارد.
MAST به تنهایی نمی تواند این مشکل را حل کند چرا که آلیس (یا باب یا چارلی) همچنان باید قسمتی از قید را هنگامی که بیتکوین ها خرج می شود، فاش کنند؛ اما این امکان وجود دارد که بسیاری از قیود پیچیده و مختلف، به چند قید ساده مبتنی بر MAST تجزیه و ساده سازی گردد.
برای مثال، هزینه کردن (خرج کردن) آلیس بصورت پیشفرض مانند حالت پیشفرض در هر تراکنش دیگری ست که برای انجام تنها به یک امضا نیاز دارد؛ پس تراکنش های مبتنی بر MAST مربوط به آلیس با سایر تراکنش های یک امضاییِ مبتنی بر MAST ترکیب می شود. این کار حریم خصوصی آلیس را فراهم می کند و همچنین fungibility او و هر فرد دیگری که از قیود مبتنی بر MAST -که تنها با یک امضا کار می کنند- را افزایش می دهد.
(fungibility: در اقتصاد، قابلیت تبادل پذیری (fungibility) به این ویژگی از یک کالا گفته می شود که واحدهای آن کالا تبادل پذیر باشند. برای مثال یک کیلوگرم از طلا با یک کیلوگرم از هر چیز دیگری که از طلا باشد برابری می کند، خواه سکه های طلا باشد خواه شمش، و این موضوع در تمام کشورها صحت دارد؛ در نتیجه طلا تبادل پذیر (fungible) است)
این ویژگیِ بخصوص از MAST احتملا به خوبی با سایر ویژگی های پیشنهادی جهت افزایش تبادل پذیری و حریم خصوصی کاربران بیتکوین قابل ترکیب باشد؛ برای مثال درخت های آستانه Gregory Maxwell و Pieter Wullie (توسعه دهنده بیتکوین)، اسکریپت های Andrew Poelstra و گزارش جداگانه قراردادها از Thaddeus Dryja.
اما اگر هیچ کدام از این موارد هم بر روی بیتکوین امکان پذیر نباشد، MAST به تنهایی می تواند حریم خصوصی بالاتری را برای قیود پیچیده، نسبت به هر آلتکوینی که قرارداد هوشمند (از طریق قیود مشخص شده توسط کاربر) دارد فراهم کند.
مزیت شماره ۳: قراردادهای هوشمند بزرگتر
بیتکوین سه محدوده مختلف برای اندازه بایت دارد که با توجه به نحوه ساخت قیود، روی اسکریپت ها اعمال می شود:
حد ۱۰هزار بایتی برای اسکریپت های ساده-خالی (bare) که در جولای ۲۰۱۰ اضافه شد، حد ۵۲۰بایتی برای P2SH و حد ۱۰هزار بایتی برای سگویت (segwit). اعداد این آستانه ها را در نمودار اندازه که قبلا استفاده کردیم می آوریم:
می بینید که حتی برای مثال ساده ای که زدیم که تا بی نهایت قابل گسترش بود، MAST امکان داشتن تعداد بیشتری شاخه های شرطی را فراهم کرد که این تعداد از شاخه ها در مقابل استفاده از مکانیزم های فعلی بسیار بیشتر است.
در واقع MAST به قدری منعطف و مقیاس پذیر است که حتی اگر تمام انرژی های موجود در جهان را دسترس داشتید، می توانستید یک درخت مرکل متعادل درست کنید که اندازه “اثبات مرکل” آن تنها ۸.۴۴۸ بایت باشد. یک اثبات مرکل با چنین سایزی می تواند توسط یک فول نود (گره کامل) در کمتر از یک میلی ثانیه تایید شود.
محدودیت های دیگری برای اسکریپت های بیتکوین وجود دارد که MAST از طریق عدم نیاز به پردازش شدن زیر-اسکریپت های استفاده نشده توسط فول نودها، آن ها را کنار می زند. در این زمینه، MAST یک هدف بلند مدت و قوی برای طراحی قراردادهای هوشمند بیتکوین دارد که طی آن تا جایی که می شود بار قرارداد بر روی مشارکت کنندگان آن قرارداد خواهد بود و نودهای شبکه که استفاده جبران ناپذیری از پهنای باند، حافظه و قدرت پردازش دارند کمترین بار را تحمل خواهند کرد.
پس موفقیت اصلی MAST تنها در این نیست که به کاربران امکان ساخت قراردادهای هوشمند پیشرفته تر را می دهد، بلکه علاوه بر این کمترین مقدار فشار بر روی نودهای بیتکوین خواهد بود.
ممکن ساختن MAST: روش های پیشنهادی
تا به حال در بین توسعه دهندگان بیتکوین دو روش برای ایجاد امکان استفاده از MAST در پروتکل بیتکوین پیشنهاد شده است که هر دو در حال بررسی هستند.
اولین پروپوزال، BIP114 است که توسط Johnson Lau معرفی شد. این روش از ویژگی یک افزونه مبتنی بر سگویت استفاده می کند که به آدرس های سگویتی (bech32) اجازه می دهد تا به ریشه ی مرکلِ قید MAST متعهد (متصل) شود. افرادی که بیتکوین های خود را خرج می کنند می توانند یک زیر-اسکریپت از درخت را انتخاب کنند.
پروپوزال دوم هنوز معلوم نیست که عدد BIP متعلق به آن چند باشد و از طرف Mark Friedenbach معرفی شده است. این روش انعطاف پذیری زبان اسکریپت را افزایش می دهد به طوری که به برنامه نویسان اجازه نوشتن اسکریپت هایی را می دهد که خود آن اسکریپت ها می توانند قیود مبتنی بر MAST را تایید کنند. اگر همانطور که Friedenbach می خواهد اجرا شود، باعث می شود که بتوان از “اثبات مرکل” در تمام سه مدل اسکریپتی که در حال حاضر توسط بیتکوین پشتیبانی می شود استفاده کرد (bare، P2SH و Segwit).
هر دو رویکرد در مقایسه با یکدیگر مزایای خاص خود را دارند اما هر دوی آن ها مزایایی که قبل تر به آن ها اشاره شد را دارند. هر کدام از این رویکردها می تواند بعنوان یک سافت فورک (انشعاب نرم) فعال شود.
جمع بندی: کی از MAST استفاده خواهیم کرد؟
بعد از توصیف مزایای MAST و مختصری که درباره دو پروپوزال ارائه شده گفتیم، شاید این سوال پیش بیاید که چه زمانی می توانیم از آن استفاده کنیم. جواب این سوال هنوز مشخص نیست.
مسیری که از ایده پردازی، تا معرفی پروپوزال، تا پیاده سازی، تا پیشنهاد سافت فورک و تا فعالسازی سافت فورک وجود دارد آسان و هموار نیست. قبلا شاهد یک بازه زمانی دو ساله برای سگویت بوده ایم و همین موضوع می تواند عمق ماجرا را روشن سازد.
اما بنظر می رسد ایده پشت MAST از طرف جامعه فنی بیتکوین پشتیبانی خوبی شود و توسعه دهندگانی که به MAST علاقه دارند نیز به کار خود ادامه دهند. زمانی که توسعه دهندگان به مرحله پیشنهاد فورک برسند، دیگر تصمیم با کاربران بیتکوین است که آیا MAST را بعنوان قسمتی از پروتکل بیتکوین بپذیرند یا خیر.
دیدگاه هایی که در این مقاله ارائه شده اند، متعلق به نویسنده می باشند و لزوماً مربوط به Coiniran نمی باشد و نباید به آن نسبت داده شود.