شناخت بیت کوین – بخش ششم: قراردادهای دیجیتال
پیش از اینکه ششمین قسمت از سلسله مقالات «شناخت بیت کوین»، نوشته گیاکومو زوکو را بخوانید، باید یادآوری کنیم که پیش نیاز درک درستی از مفاهیمی که در ادامه به تشریح آنها خواهیم پرداخت، خواندن قسمتهای قبلی این سلسله مقالات است.
در بخش زمان به تشریح لزوم تخصص پرداختیم، در قسمت دوم نقش جامعه در نظام اقتصادی را بررسی کردیم. سپس در قسمت سوم شاهد ظهور پول بودیم. پس از آن در قسمت چهارم فهمیدیم که به نقشهای تازه نیاز داریم. در نهایت هم مفهوم کمیابی دیجیتال را توضیح دادیم و حالا نوبت به ششمین قسمت، یعنی «قراردادهای دیجیتال» رسیده است.
در ادامه با استفاده از مفاهیم پازلهای دیجیتال، به عنوان راهی برای تولید دوباره کمیابی، اهمیت مکانیزم عرضه کنترلشده، به عنوان راهی برای ایجاد سختی برای پول دیجیتال، به تشریح مفاهیمی نظیر «اثبات مالکیت» با استفاده از امضاها و اسکریپتها و تکنیک «کوین جوین» (CoinJoin) خواهیم پرداخت.
اثبات مالکیت با استفاده امضاها
در این مطلب برای بار دوم به نقشه ب یا نقشه بیت کوین میرسیم. محوریت مطلبی که برای شما آماده کردیم بر پایه سوال «چه کسی؟» است.
شما شرایطی را مهیا کردید که بتوان در آن ساتوشی ایجاد کرد، اما انتقالشان چه میشود؟ چه کسی این اجازه را دارد که در ترازنامههایی که در اختیار همه است، تغییر ایجاد و مالکیت آنها را عوض نماید؟
اگر پای یک قدرت مرکزی در خصوص تغییر مالکیت ساتوشیها وجود داشته باشد و دستورالعملهای مشخصی توسط مالک فعلی پیروی شود (مانند طلای دیجیتال قبلی شما که در آن ورود به سیستم با استفاده از یک نامکاربری و رمز عبور انجام میشود)، پس یک نقطه آسیبپذیر نیز در میان است که بتوان از طریق آن به سیستم نفوذ کرد: پس حالا چه لزومی دارد از طلای فیزیکی به یک کالای کمیاب دیجیتالیِ مبتنی بر اثبات انجام کار برسیم؟ در طرف دیگر، اگر همه کاربران این امکان را داشته باشند که مالکیت را تغییر دهند پس سیستم به هیچ عنوان کارایی نخواهد داشت: هر کسی تشویق میشد تا ساتوشیهای دیگران را به نام خودش بزند. در این حالت باید یک پروتکل تشخیص مالکیت پایدار ایجاد کنید که هر کسی به شکل مستقل توانایی آزمایش و تایید آن را داشته باشد.
راه حل این مشکل تکنیکی در رمزنگاری با نام «امضای دیجیتال» است. نحوه عملکرد این امضای دیجیتال به این شکل است که آلیس یک عبارت تصادفی با نام «کلید خصوصی» ایجاد میکند و آن را در جای امنی نگه میدارد. سپس این عدد را به یک تابع خاص ریاضی میدهد؛ نکته اینجاست که این تابع به شکل یک طرفه کار میکند. خروجی تابع عبارتی دیگر است که «کلید عمومی» نام دارد؛ آلیس این عبارت را در جای امنی نگه نمیدارد، بلکه مطمئن میشود که باب هم عدد را میداند. در نهایت، آلیس کلید خصوصی و پیام را وارد تابع دوم میکند که آن هم یک طرفه است و در نهایت عبارت بسیار بزرگی به دست میآید که «امضا» نام دارد.
سومین و آخرین تابع ریاضی، توسط باب و بر روی پیام، کلید عمومی آلیس و امضا انجام میگیرد که منجر به تاییدی موفق یا ناموفق میشود. او میتواند مطمئن شود که آلیس آن پیام (احراز هویت) را تایید کرده کرده و پیام مورد نظر در طی انتقال تغییر جایگزین نشده باشد (درستی). به یاد داشته باشید وقتی که آلیس پیام مورد نظر را تایید کرده باشد، بعدها نمیتواند آن را انکار کند (غیر قابل انکار).
به نوعی این امضاها شبیه به امضاهای عادی هستند که فرد نام خود را با دست خط خودش مینویسد. در چنین امضاهایی نیز هر فردی میتواند با مقایسه دست خط فرد با نمونههای موجود، اصالت آن را تایید کند، اما تولید دوباره امضای مشابه، کار مشکلی است. یا مهر و موم را در نظر بگیرید. تطابق این مهر و نمونههای موجود کار سختی نیست، اما تولید دوباره الگوی روی مهر کار سختی است.
پس شما به منظور استفاده دوباره و مستقل از اثبات کار با استفاده از امضاهای دیجیتال، پروتکل خود را تغییر دادید. اولین مدل مورد استفاده ساده است: هر کاربر به شکل مستقل، یک کلید خصوصی دارد و با استفاده از آن یک حساب عمومی ایجاد میکند که با کلیدعمومی مرتبطی نشانهگذاری شده است. وقتی که کاربران بخواهند مالکیت را تغییر دهند، پیامی شامل حساب کاربری، حساب کاربری مقصد و مقدار ساتوشیهایی که منتقل میشوند، ایجاد میکنند. سپس این پیام را به شکل دیجیتالی امضا و مخابره میکنند، به نوعی که همه افراد حاضر بتوانند آن را تایید نمایند.
جالب اینجاست که توسعهدهندگان مختلف (خواه شناس یا ناشناس) میتوانند به منظور ایجاد نسخههای مختلف از نرمافزار شما، از طرحی مشابه استفاده کنند. پس یعنی توسعهدهندگان میتوانند طرح شما را آزادانه تغییر داده، آن را بهبود بخشند، به روز رسانی کنند یا آن را مورد بررسی قرار دهند و اشکالاتش را رفع کنند. در عین حال هر کاربر نهاییِ سیستم شما میتواند به شکل مستقل، پیش از اجرای نسخه مورد نظر، امضاهای نام برده را تایید کند. بدین ترتیب اعتماد در شبکه به حداقل میرسد و این کار بدون نیاز به مقام مشخص یا نرمافزاری متمرکز صورت میگیرد. بدین وسیله امکان تمرکز زدایی کامل کدها فراهم میشود.
اسکریپت و قراردادهای هوشمند
شما نمیخواهید پیش از قبول هر گونه تغییری در این ترازنامهها که در اختیار همه قرار دارد، محدودیتی ایجاد کنید که بر اساس آن تک تک همتاها (Peer) ملزم به تایید اعتبار چنین تغییراتی تنها با یک امضای دیجیتال باشند.
اینجاست که تصمیم میگیرید هر پیام شامل یک اسکریپت هم باشد. حالا اسکریپت چیست؟ اسکریپت فهرستی از دستورالعملهاست که شرایطی اضافی را تعریف میکند که حساب دریافت کننده یا دریافت کنندگان، به منظور انجام تراکنش دوباره، مستلزم داشتن آنها بودند. مثلا، فرستنده ملزم به داشتن ترکیبی از چندین کلید خصوصی است (با هم یا بدون هم)، یا هم مجبور است پیش از خرج کردن سرمایههای دریافتی مدت زمان مشخصی صبر کند. با استفاده از این اصول ابتدایی و بسیار ساده، میتوان به قراردادهای هوشمند رسید که پیچیدگیهای بسیار دارند. در نهایت و با بهرهگیری از این قراردادها نیز به پولی کارآمد و با قابلیت برنامهنویسی رسید، آن هم در غیاب اشخاص ثالث غیرمتمرکز.
مشکلات مرتبط با تاریکی و مقیاس پذیری
بر خلاف یک سیستم پیامرسان رمزنگاری شده، سیستمی که شما ساختید، جنبه تاریکیاش چندان قوی نیست. در یک سیستم رمزنگاری شده اگر آلیس پیامی برای باب بفرستید، تنها باب میتواند پیام مورد نظر را بخواند. در سمت دیگر، در سیستم شما اگر آلیس مقداری ساتوشی برای باب بفرستید، پیام ارسال ساتوشیها فقط برای باب قابل خواندن نخواهد بود بلکه برای آخرین نفری هم که بعد از باب این ساتوشیها دریافت کرده، پیدا کردن سوابق تراکنشها بسیار راحت و در حد آب خوردن است.
پول همیشه در چرخش است. حتی اگر یک انتقال خوب دارای امضاها معتبری هم باشد، باز هم دریافت کننده نمیتواند هر انتقالی را معتبر به حساب بیاورد. اگر دریافت کننده نتواند تایید کند که ساتوشیهای منتقل شده، عملا خودشان را به پرداختکننده مشخص رسانده باشد و همینطور این پیگیری را تا سرچشمه ساتوشیها انجام دهد، باز هم امکان اطمینان صد در صدی وجود نخواهد شد. با وجود چرخش کافی ساتوشیها، همتاهای فعال به شناخت کاملی از تعداد بسیار زیادی از تراکنشهای گذشته میرسند. حالا با تکنیکآماری فورسنیک (Forensic) میتوان میان مقادیر، زمانبندیها، دادهنماها و حسابهای کاربری همبستگی ایجاد و به تبع آن هویت بسیاری از کاربران را مشخص کرد و ناشناس بودن آنها را از میان برد.
اما مشکل کجاست: همانطور که در قسمت دوم صحبت کردیم، تاریکی یکی از اساسیترین ویژگیهای پول است و اساسی بودن آن هم از دلایل اقتصادی و جامعهشناختی ناشی میشود.
قراردادهای هوشمند این مشکل را وخیمتر هم میکنند؛ چرا که برخی از خرج کردنها ممکن است برای تشخیص کاربردِ نرمافزار خاص یا سیاستهای یک نهاد منحصر، مورد استفاده قرار گیرد.
نبود تاریکی در این مورد، بسیار حادتر از طلای دیجیتال شماست است که پیشتر اقدام به ایجادش کرده بودید. آن زمان شما بیشتر دادهنماهای تراکنشهای خود را در سرورهای متمرکز نگهداری میکردید و نکته مثبت اینجا بود که حداقل فقط شما به این اطلاعات دسترسی داشتید؛ در نقطه مقابل مالوری و کارکنانش هستند که همگی به اطلاعات دیگران در سرورهای خود دسترسی دارند. به علاوه شما میتوانید با بکارگیری برخی از تکنیکهای خاص رمزنگاری، چشم خود را در مورد بخشی از اتفاقاتی که در مورد کاربرانتان میافتد، ببندید.
یک مشکل کوچک هم در مورد مقیاس پذیری سیستم شما وجود دارد: امضاهای دیجیتال بسیار بزرگاند و زنجیره تبادلاتی که یک دریافت کننده باید آنها را به منظور تایید اعتبار همه اجزای تراکنش دریافت نماید، شامل امضاهای بسیاری خواهد بود و این مسئله باعث میشود روند تایید اعتبار بسیار گران تمام شود. به علاوه تایید تغییرات در حسابهای کاربری نیز بسیار سخت است.
الگویی جدید: کوین جوین
برای فائق آمدن بر چنین مشکلاتی، تصمیم میگیرید که هویتها در مدل حسابهای کاربری بانک شکل خود را به «خروجی تراکنش خرج نشده» (UTXO) یا Unspent Transaction Outputs تغییر دهید.
به جای اینکه دستورالعملها، ساتوشیها را از یک حساب به حساب دیگر منتقل کنند، هر پیام حالا شامل فهرستی از UTXOهای قدیمیتر نیز هست که شامل تمام تراکنشهای قبلی است که به شکل یک ماده اولیه «مصرف» میشود. همچنین یک فهرست از UTXOهای جدید که به عنوان محصولات «ایجاد» میشود و برای استفاده از تراکنشهای آینده آماده است. به جای ایجاد یک کلید عمومی ثابت و مشخص، مانند نمونههایی که در شماره حسابهای بانکی وجود دارد، باب باید یک کلید عمومی یکبار مصرف و جدید برای هر تراکنش دریافتی ایجاد کند. وقتی که آلیس به او ساتوشی ارسال میکند، در واقع پیامی با مضمون «آزاد سازی» مقداری ساتوشی را امضا میکند که به واسطه یک UTXO ایجاد شده است. بدین ترتیب او ساتوشیها را در یک UTXO جدید «قفل» میکند تا در تراکنش بعدی «آزاد» شوند.
درست مانند پول نقد و فیزیکی، اسکناسهایی که قابلیت خرج کردن را دارند، همیشه با ملزومات پرداخت همخوانی ندارد و معمولا نیاز به خرد کردن یا تغییر در اسکناس وجود دارد. مثلا، اگر آلیس بخواهد ۱,۰۰۰ ساتوشی به باب بفرستد، اما تنها کنترل UTXOهایی را داشته باشد که چندین ۷۰۰ ساتوشی را «قفل» کردهاند، او باید تراکنشی را امضا کند که چندین عدد از آن UTXOهای ۷۰۰ ساتوشی را آزاد نماید، در این صورت او مجبور است دو UTXO با ۷۰۰ ساتوشی را آزاد کند که در نهایت ۱,۴۰۰ ساتوشی میشود؛ حالا او دو UTXO جدید ایجاد میکند: یکی مرتبط با کلیدهای عمومی باب که باعث قفل شدن ۱,۰۰۰ ساتوشی میشود و دیگری کلیدهای عمومی آلیس که باقیمانده (۴۰۰) ساتوشی را در حساب آلیس قفل میکند.
همانطور که پیشتر گفتیم، افراد از کلیدهای عمومی را دوباره مورد استفاده قرار نمیدهند و همین مسئله به خودی خود باعث افزایش تاریکی میشود. این تاریکی زمانی بیشتر میشود که افراد میفهمند، UTXOهای مصرف شده و ایجاد شده، تنها از دو هویت نمیآیند! آلیس میتواند پیامی را ایجاد کند که باعث مصرف UTXOهای قدیمی شود که کنترل آنها را در اختیار دارد و UTXOهای جدیدی (در ارتباط با باب) ایجاد کند، سپس میتواند پیامی مشابه را برای کارول تایید کند، کارول هم میتواند به راحتی UTXOهای قدیمی خود را که میخواهد در یک UTXO جدید (در ارتباط با دنیل) مصرف کند را ایجاد نماید. در نهایت آلیس و کارول هر دو پیامهایی مرکب را امضا و در شبکه مخابره میکنند و پرداختی به باب و دنیل انجام میدهند.
این استفاده خاص از مدل UTXO، «کوین جوین» نام دارد. نکته حائز اهمیتی که در این میان وجود دارد اینجاست که در تاریخ حقیقی بیت کوین، چنین استفادهای در خصوص اصول طراحی مدل UTXO ساتوشی وجود نداشت؛ اما چندین سال بعد از عرضه بیت کوین، به عنوان یک پیچیدگی بالقوه، توسط دیگر توسعهدهندگان بیت کوین کشف شد. این مسئله باعث شکستن ارتباط آماری میان خروجیهاست و در عین حال باعث حفظ مفهومی میشود که «ظرفیت اتمی» نام دارد. در توضیح این مفهوم باید گفت: در واقع تراکنشها یا قابل قبولاند یا غیر قابل قبول و از همین رو آلیس و کارول نیازی به اعتماد متقابل یه یکدیگر را ندارند. به عبارت دیگر اگر یکی از آنها بخواهد پیش از اضافه کردن امضای خود، نسخهای دیگر از پیام (که توسط دیگران امضا شده است) را ایجاد کند، موجودیت امضا زیر سوال میرود و غیر قابل قبول تلقی خواهد داشت.
در این میان میتوان یک تغییر احتمالی در سیستم را متصور شد که در حقیقت باعث بهبود اوضاع میشود: یک طرح امضای دیجیتال متفاوت، اضافه بر نمونهای که از آن استفاده میکنید. باید توجه کرد که ارتباط طرح جدید و امضاها خطی است. این یعنی در دریافت دو کلید خصوصی (که تنها دو رقماند)، امضای پیام مشخص با یکدیگر و اضافه کردن همزمان نتیجه امضاها (که باز هم چیزی جز یک رقم بسیار بزرگ نیست)، این نتیجه همان امضای قابل قبول است که نمایانگر مجموع دو کلید عمومی است که به کلید خصوصیِ اولیه مرتبطاند.
روی کاغذ این مسائل پیچیده به نظر میرسند اما در عمل سادهاند. آلیس و کارول وقتی کوین جوین انجام میدهند، میتوانند امضاهای مخصوص خود را اضافه کرده و نتیجه مجموع امضاها را در شبکه مخابره کنند، از طرف دیگر همه افراد میتوانند این «مجموع» را با «مجموع کلیدهای عمومی» آنها تطابق دهند و در نهایت مجموع کلیدهای خصوصی را تایید کنند. از آنجایی که امضاها سنگینترین بخش یک تراکنشاند، این امکان هست که به جای مخابره همه آنها، تنها یک رقم مخابره شود و بدین ترتیب در استفاده از منابع شبکه صرفهجویی شود. به این دلیل که کاربران زیادی به دنبال بهرهوری هستند، پس ممکن است یک ناظر خارجی به این فکر بیافتد که شاید تمام تراکنشهای کوین جوین شدهاند! این فرض میتواند بیشتر دستاوردهایی که با استفاده از آمار فورنسیک بدست آمده را بشکند.
حتی بدون بهبودهای بیشتر، مدل UTXO، به نوعی همچنان باعث افزایش مقیاس پذیری میشود: بر خلاف تغییر حالت مدل حسابها، این امکان برای روند تایید اعتبار به وجود میآید که به شکلی کارآمد یکدست و همسو باشد.
تا به اینجا یاد گرفتیم که:
- میتوانید با استفاده از امضاهای دیجیتال برای انجام انتقال، مالکیت را غیرمتمرکز کنید.
- میتوانید تراکنشها را با سیستم اسکریپت، به قراردادهای هوشمند قابل برنامهریزی بدل کنید.
- الگوی پیچیدهتر به نام کوین جوین میتواند باعث افزایش تاریکی و مقیاسپذیری شود.
اما حالا که کاربران شما میتوانند ساتوشی ایجاد کنند و آنها را به صورت کاملا غیرمتمرکز انتقال دهند، چطور این امکان برایشان وجود دارد که مطمئن شوند از یک توالی زمانی مشخص پیروی شده است؟ چطور میتوانند مطمئن شوند که دوبار خرج کردن یا حملاتی نظیر دستکاری زمانبندی تورم رخ نمیدهد؟ در بخش هفتم و پایانی به این سوالات پاسخ خواهیم داد.
یه استخر ایرانی داشتیم اسمش چی بود وصل شیم بهش