نظریه استفاده از زیرساخت و کاربرد آن در مفاهیم دیگر تاریخچه ای طولانی دارد. در سال نیک زابو با معرفی مفهوم جدیدی تحت عنوان " عناوین ملک امن با اختیار مالک" ( secure property titles with owner authority ) ظاهر شد. این مفهوم سندی است که توضیح میدهد چگونه" پیشرفت های جدید در فناوری پایگاه داده تکراری" شرایطی را برای ایجاد سیستمی مبتنی بر بلاکچین فراهم کرده است. این سیستم به منظور ثبت اطلاعات اینکه چه زمینی متعلق به چه کسی است و همچنین ایجاد یک چارچوب دقیق برای مفاهیمی مانند خانه داری، تصرف ملک و مالیات زمین اهالی گرجستان، ایجاد شده است. در آن زمان هیچ سیستم پایگاه داده ی کارآمدی وجود نداشت پس عملا این پروتکل هیچ وقت به مرحله اجرا نرسید. بعد از سال ، با توسعه اجماع غیر متمرکز، تعدادی اپلیکیشن جایگزین به سرعت شروع به ظهور کردند. که یک پایگاه ثبت داده غیر متمرکز است در سال ساخته شد. در پروتکل های غیر متمرکز مثل Tor ، Bitcoin و Bitmessege باید راهی برای شناسایی حساب های کاربری باشد تا افراد بتوانند با یکدیگر تعامل داشته باشند. اما در همه این راهکارها تنها شناسه موجود، یک شبه تصادفی مانند LWwpZBqaHWjLTCiBCrhQYtHagUWy است. اما اگر کسی بخواهد اسم آن را مثلا " جورج" بگذارد هیچ اشکالی ندارد، فقط مشکل اینجاست که اگر یک نفر بتواند حسابی به نام ' george ' ایجاد کند، شخص دیگری هم می تواند از همان فرآیند برای ثبت ' george ' برای خود و جعل هویت استفاده کند. تنها گزینه برای حل این مشکل استفاده از الگوی است که طبق آن وقنی نفر اول ثبت نام خود را انجام میدهد، دیگر نفر دوم قادر به نام نویسی نخواهد بود. Namecoin از قدیمی ترین و موفق ترین سیستم های نام نویسی است که از چنین ایده ای بهره برده است: پروتکلی است که افراد با استفاده از آن میتوانند ارز دلخواه یا توکن دیجیتال دلخواه خود را بر روی بلاکچین بیتکوین بسازند. در این پروتکل فردی ارز جدیدی را منتشر میکند و در مل عام رنگی را برای بیتکوین انتخاب میکند. پروتکل رنگ بقیه UTXO ها را دقیقا همرنگ ورودی هایی که در یک تراکنش خرج میشوند تعریف میکند (به ورودی های رنگی قوانین خاصی اعمال می شود) این ویژگی به کاربران اجازه میدهد در کیف پولشان فقط UTXO های تک رنگ داشته باشند، آنها را مثل بیت کوین های معمولی انتقال دهند و از طریق بلاکچین به عقب برگردند و رنگ هر UTXO دریافتی را بررسی کنند. ایده ساخت متاکوین از داشتن پروتکلی شروع شد که بر روی بلاکچین بیت کوین قرار بگیرد و از تراکنش های آن برای ذخیره سازی تراکنش های خودش استفاده کند اما تابع انتقال وضعیت متفاوتی داشته باشد. از آنجایی که پروتکل متاکوین قادر نیست از ظهور تراکنش های متاکوینی نا معتبر در بلاکچین بیتکوین جلوگیری کند، قانونی به تابع اضافه شده که به شرح زیر است: در شرایطی که ( APPLY '( S , TX خطا داد، پروتکل در حالت پیش فرض APPLY '( S , TX ) = S قرار میگیرد. این ویژگی مکانیزم ساده اما با قابلیت های پیشرفته ای را در اختیار کاربران قرار میدهد که در شبکه بیتکوین قابل اجرا نیست. کاربران با استفاده از این مکانیزم میتوانند رمزارز دلخواه خودشان را بسازند و از آنجایی که پیچیدگی های استخراج و شبکه بندی از قبل توسط خود بیتکوین اعمال و اجرا شده هزینه توسعه آن بسیار اندک خواهد بود. پس در کل دو رویکرد برای ساخت یک وجود دارد: ساخت یک شبکه مستقل و ساخت یک پروتکل بر روی بلاکچین بیتکوین. در حالی که رویکرد اول در اپلیکیشن هایی مثل موفق بوده اما اجرای آن زحمات زیادی به همراه داشته است چرا که در هر اجرای فردی، به راه اندازی یک بلاکچین مستقل و ساخت و تست همه توابع انتقال وضعیت و کدهای شبکه بندی نیاز داریم. به علاوه، احتمالا همه اپلیکیشن های فناوری اجماع غیر متمرکز از قانون توزیع قدرت پیروی خواهند کرد که اکثریت قریب به اتفاق این برنامه ها بسیار کوچکتر از این هستند که بتوانند ضامن بلاکچین خود باشند. باید توجه داشته باشیم که تعداد اپلیکیشن های غیر متمرکز بسیار زیاد است، مخصوصا سازمانهای مستقل غیر متمرکزی که به تعامل باهم نیاز دارند. از طرف دیگر، رویکرد مبتنی بر بیتکوین، ویژگی های ت ییدیه پرداخت ساده بیت کوین را به ارث نبرده است، که این واقعا نقطه ضعف این رویکردهاست. SPV برای بیت کوین کار میکند چون از عمق بلاکچین به عنوان یک پروکسی اعتبار سنجی استفاده میکند. زمانی که سوابق یک تراکنش در بلاک های قدیمی تر قرار میگیرند و دور میشوند، اگر بگوییم که آنها جزیی از وضعیت هستند زیاد هم بی راه نگفته ایم. از طرفی پروتکل های متای مبتنی بر بلاکچین نمیتوانند بلاکچین را مجبور به حذف تراکنش های نامعتبر در حوزه پروتکل خودشان کنند. بنابراین، اجرای پروتکل کاملا امن SPV احتمالا وارسی دوباره بلاکچین بیتکوین را به جهت تشخیص اعتبار برخی تراکنش های خاص، ضروری میکند. در حال حاضر، همه اجراهای" لایت" پروتکل های متای مبتنی بر بیتکوین برای تولید داده به یک سرور قابل اعتماد متکی هستند، که مسلما نتیجه آنقدرها هم مطلوب نیست چرا که هدف اصلی سیستم های رمزارز حذف نیاز به اعتماد است. در اصل پروتکل بیت کوین نمونه ساده شده "قرار داد هوشمند "میباشد. در سیستم بیتکوین UTXO نه تنها میتواند تحت مالکیت یک کلید عمومی بلکه تحت مالکیت یک اسکریپت پیچیده به زبان برنامه نویسی" مبتنی بر پشته" ( stack - based ) هم باشد. در این الگو، تراکنشی که UTXO را خرج میکند باید داده ای فراهم کند که با آن اسکریپت مطابقت داشته باشد. در واقع حتی ساده ترین مکانیزم مالکیت کلید عمومی از طریق اسکریپت اجرا میشود. این اسکریپت یک امضای منحنی بیضوی را به عنوان داده ورودی در نظر میگیرد، اگر این اطلاعات با اطلاعات تراکنش و آدرس صاحب UTXO مطابقت داشت، پاسخ میشود در غیر این صورت عدد خروجی خواهد بود. موارد استفاده اسکریپت ها متفاوت است. برای مثال، میتوان اسکریپتی ساخت که برای اعتبار سنجی، از کلید خصوصی که به آن داده میشود به امضا نیاز داشته باشد. از طریق ترکیب چندین امضای منحصر به فرد تولید می شود. این قسمت تنظیمات میتواند برای ایمن کردن حسابهای شرکتی، پس اندازی و برخی از شرایط فروش توافقی بسیار مفید باشد. اسکریپت ها گاهی برای حل مشکلات محاسباتی هم به کار میروند. حتی میتوان اسکریپتی ساخت که مثلا " اگر بتوانید یک گواه اثبات SPV ارایه دهید که یک Dogecoin با این عنوان برای من فرستاده اید، این بیت کوین خرج نشده متعلق به شماست". در اصل امکان مبادله غیر متمرکز رمزارزها را هم فراهم میکند. البته زبان اسکریپت قابل اجرا در بیتکوین محدودیت هایی هم دارد: یعنی در شرایطی که تعداد زیادی زیر مجموعه محاسباتی وجود دارد که توسط زبان اسکریپت بیتکوین پشتیبانی میشوند، این اسکریپت از همه موارد پشتیبانی نمیکند. اولین گروهی که نبودشان احساس میشود حلقه ها هستند. این ویژگی به منظور جلوگیری از ایجاد حلقه های نا محدودی که در زمان ت یید یک تراکنش به وجود می آیند، در نظر گرفته شده است. از لحاظ علمی، برنامه نویسان قادرند که این محدودیت را بر طرف کنند چرا که هر حلقه را میتوان با چندین بار تکرار کد زیر بنا و با یک جمله if شبیه سازی کرد. اما این کار فقط منجر به ایجاد اسکریپتهای نا کار آمد در فضا میشود. برای مثال، احتمالا اجرای الگوریتم امضای منحنی بیضوی جایگزین به دور ضرب تکراری احتیاج دارد که همگی جداگانه در کد وجود دارند: اسکریپت تراکنش خرج نشده نمیتواند کنترلی روی مبلغ برداشتی داشته باشد. برای مثال، یک مورد بسیار کاربردی از قرارداد اوراکل، قرارداد پوشش ریسک ( hedging ) است که طی آن شخص A وشخص B ، دلار در بیت کوین سرمایه گذاری میکنند و بعد از گذشت روز، اسکریپت دلار بیتکوین را برای شخص A و بقیه را برای B میفرستد. این پروسه مطمینا به یک قرارداد اوراکل احتیاج دارد تا ارزش یک بیت کوین را به دلار مشخص کند. زمانی که راهکارهای غیرمتمرکز فعلی را در نظر میگیریم، متوجه میشویم که این اسکریپت در زمان خودش از نظر اعتماد و نیازهای زیر ساختی بسیار پیشرفت عظیمی بوده است. از آنجایی که UTXO ها یا همه چیزند و یا هیچ چیز، تنها راه دستیابی به هدف از طریق هک تعداد زیادی UTXO از طبقه مندی های مختلف و داشتن قرارداد اوراکل میباشد که مشخص میکند کدام UTXO برای شخص A وکدام برای B فرستاده شود: UTXO هم میتواند خرج شود و هم خرج نشود. این امر ایجاد قراردادهای چند مرحله ای، پیشنهادات مبادله غیرمتمرکز یا پروتکل های تعهد رمزنگاری دو مرحله ای را دشوار می کند (برای هزینه های محاسباتی ایمن لازم است) این بدین معناست که UTXO فقط می تواند برای ساخت قراردادهای ساده، یکبار مصرف و نه قراردادهای پیچیده تر مملو از "وضعیت" مانند سازمانهای غیرمتمرکز استفاده شود چرا که UTXO اجرای پروتکل های متا را دشوار می کند. با ترکیب وضعیت دوگانه و مقادیر blindness دیگر محدودیت های برداشتی وجود نخواهند داشت. UTXO داده های بلاکچین، اعم از عدد نانس و هش بلاک قبلی را نادیده میگیرد. این ویژگی با سلب اختیار از زبان اسکریپت از یک منبع ارزشمند تصادفی، برنامه های کاربردی در شرط بندی و چندین دسته دیگر از برنامه ها را به شدت محدود میکند. منبع: