آرک
آرک (به انگلیسی: Ark): یک پروتکل کوین‌سواپ لایه دوم بیت‌کوین است که با هدف بهبود مقیاس‌پذیری، حریم خصوصی بدون اضافه کردن ریسک امانی طراحی شده است. آذر پولش را به سرور می‌دهد به شرطی که سرور تضمین کند به بابک پرداخت می‌کند. چون تمام تاخت زدن‌ها با استفاده از سرور است و قفل زمانی به نفع کاربران نهایتا باز خواهد شد، تعداد زیادی برون‌داد خرج نشده می‌تواند در یک برون‌داد بر روی زنجیره گنجانده شود (که کاربران هنوز می‌توانند دارایی خود را از آن پس بگیرند). این مسئله به این قیمت است که نمی‌توانند درجا به دارایی خود دسترسی داشته باشند یعنی سرور می‌تواند تا مدتی مقدار قابل توجهی را قفل کند.[۱] هم اکنون نسخه‌ی آزمایشی آرک بر روی زنجیره‌ی جانبی لیکویید پیاده شده است.
سازوکار[۲][ویرایش | ویرایش مبدأ]
نگه‌داری سکه‌ها[ویرایش | ویرایش مبدأ]
آذر (A) سکه‌ها را پیش سرور (S) نگه‌داری می‌کند و همیشه می‌تواند بدون نیاز به اعتماد آن‌ها را پس بگیرد.
برون‌داد خرج نشده‌ی شماره 1 روی زنجیره به این شکل است:
( || : به معنی «یا» است، + به این معنی است که هر دو شرط برقرار باشد مثلا در مثال زیر هم آذر امضا کند و هم سرور)
A+S || S in 1 month
آذر+سرور || سرور در یک ماه
A آذر یک تراکنش بازپس‌گیری REDEEM_TX (امضا شده توسط S) خارج از زنجیره دارد که از برون‌داد 1 با این برون‌داد خرج می‌کند:
UTXO_1:
A+S || A in 1 month
آذر+سرور || آذر در یک ماه
آمادگی برای فرستادن سکه[ویرایش | ویرایش مبدأ]
آذر (A) می‌خواهد سکه‌هایش را به بابک (B) بفرستد.
S قول می‌دهد برون‌داد خرج نشده‌ی 2 را بسازد که به شرح زیر است:
UTXO_2:
B+S || S in 1 month
بابک+سرور || سرور در 1 ماه
B تراکنش بازپس‌گیری REDEEM_TX (امضا شده با S) برون‌زنجیره را دریافت می‌کند که از برون‌داد خرج نشده‌ی 2 با برون‌داد زیر خرج می‌کند:
B+S || B in 1 month
بابک+سرور || بابک در 1 ماه
اگر UTXO_2 روی زنجیره بیاید، پول به بابک B پرداخت شده.
تاخت زدن (بخش مهم!)[ویرایش | ویرایش مبدأ]
آذر می‌خواهد به شرطی که برون‌داد خرج نشده‌ی 2 (پرداخت S سرور به B بابک) روی زنجیره ظاهر شود ، از ادعایش روی برون‌داد خرج نشده‌ی 1 (پرداخت Sسرور به A آذر) بگذرد.
برای دست‌یابی به این، آذر A تراکنش واگذاری FORFEIT_TX زیر را امضا می‌کند که تراکنش بازپس‌گیری‌اش REDEEM_TX را خرج می‌کند:
S if UTXO_2 exists* || A in 1 month
سرور اگر برون‌داد خرج نشده‌ی 2 وجود داشته باشد* || آذر در یک ماه
* این نوع اسکریپت در حال حاضر ممکن نیست اما توضیحش ساده‌تر از روش بدون نیاز به نرم‌شاخه‌ی جدید است.
در نتیجه S می‌تواند پول برون‌داد خرج نشده‌ی 1 را بردارد اگر برون‌داد خرج نشده‌ی 2 روی زنجیره آمده باشد.
پیشامد‌ها[ویرایش | ویرایش مبدأ]
پیشامد مورد انتظار/ایدئال[ویرایش | ویرایش مبدأ]
- S سرور برون‌داد خرج نشده UTXO_2 را روی زنجیره می‌فرستد یعنی B بابک پولش را گرفته.
- A آذر تراکنش بازپس‌گیری‌اش REDEEM_TX را روی زنجیره نمی‌فرستد.
- قفل زمانی UTXO_1 باز می‌شود و S دارایی را برمیدارد (اگر A آذر کلید خودویژه‌اش را بدهد، قفل زمانی قابل دور زدن است).
پیشامد A آذر متخاصم[ویرایش | ویرایش مبدأ]
- S سرور برون‌داد خرج نشده UTXO_2 را روی زنجیره می‌فرستد یعنی B بابک پولش را گرفته.
- A آذر تراکنش بازپس‌گیری‌اش REDEEM_TX را روی زنجیره می‌فرستد.
- S سرور تراکنش واگذاری FORFEIT_TX مربوطه را روی زنجیره می‌فرستد و دارایی را برمیدارد.(از آذر پس می‌گیرد.)
پیشامد S سرور متخاصم[ویرایش | ویرایش مبدأ]
- S سرور برون‌داد خرج نشده UTXO_2 را روی زنجیره نمی‌فرستد یعنی B بابک پولش را نمی‌گیرد.
- A آذر تراکنش بازپس‌گیری‌اش REDEEM_TX را روی زنجیره می‌فرستد.
- S سرور تراکنش واگذاری مربوطه FORFEIT_TX را روی زنجیره می‌فرستد.
- قفل زمانی FORFEIT_TX باز می‌شود و A آذر دارایی را برمیدارد.
پیشامد A آذر آفلاین[ویرایش | ویرایش مبدأ]
- A آذر نمی‌تواند از S سرور بخواهد پول را به B بابک بفرستد.
- A آذر نمی‌تواند در زمان مناسب تراکنش بازپس‌گیری‌اش را روی زنجیره بفرستد.
- قفل زمانی برون‌داد خرج نشده UTXO_1 باز می‌شود و سرور پول آذر را برمیدارد.
بهینگی روی زنجیره[ویرایش | ویرایش مبدأ]
روال طی شده به خودی خود بهینه‌تر از این نیست که A آذر مستقیم در تراکنشی برزنجیره به B بابک پول بفرستد. کاربرد اصلی در این است که دارایی چندین کاربر می‌تواند در یک برون‌داد خرج نشده‌ی یکسان گنجانده شود.
برای مثال فرض کنید آنطور که در نمودار مقابل نشان داده شده، A آذر و B بابک هر دو در یک گردآورد، کوین دارند. برون‌داد خرج نشده UTXO_1، اینطور خواهد بود:
A+B+S || S in 1 month
آذر + بابک + سرور یا سرور در یک ماه
این در یک ساختار درختی در دوشاخه دو تراکنش برون‌زنجیره‌ی A+S || S in 1 month ( آدر+سرور یا سرور در یک ماه) و B+S || S in 1 month ( بابک+سرور یا سرور در یک ماه) را به همراه خواهد داشت. اگر هم A آذر و هم B بابک طبق انتظار از ادعایشان روی دارایی بگذرند، (پیشامد مورد انتظار)، تراکنش برون‌زنجیره هرگز بر زنجیره نخواهد رفت. این کار برای هر تعداد کاربر شدنی است و همین هم باعث بهینگی نهایی پروتکل است.
ساخت این ساختارِ تراکنش در حال حاضر نیاز دارد که A+B+S از پیش امضا کنند یعنی هر دفعه یک برون‌داد خرج نشده در حال ایجاد بود همه باید با هم سروکار داشته باشند. نرم‌شاخه‌ی OP_CTV این نیاز را از بین می‌برد.
بدترین پیشامد بازپس‌گیری[ویرایش | ویرایش مبدأ]
یک کاربر به تنهایی ممکن است تراکنش بازپس‌گیری‌اش REDEEM_TX را روی زنجیره بفرستد. این کاربر باید کارمزد گستردن درخت تراکنش‌های برون‌زنجیره و رسیدن به برون‌داد خود را پرداخت کند. این هزینه گزافی برای کاربر است و حد اقتصادی‌ای کمترین میزان دارایی کاربردی درون آرک می‌گذارد.
به علاوه، چون درخت گسترده شده، S سرور برای برداشتن برون‌داد بجای 1 برون‌داد باید log(n) برون‌داد را خرج کند.
همکاری در خروج برزنجیره[ویرایش | ویرایش مبدأ]
بجای تاخت زدن با یک تراکنش برون‌زنجیره‌ی بازپس‌گیری REDEEM_TX جدید با S سرور، این هم شدنی است که خیلی ساده با یک برون‌داد برزنجیره که قفل زمانی ندارد تاخت زده شود، که بهینه‌ترین خروج از سیستم را نتیجه می‌دهد.
«اگر برون‌داد خرج نشده‌ی UTXO_2 وجود داشته باشد» بدون نرم‌شاخه[ویرایش | ویرایش مبدأ]
تراکنشی که برون‌داد خرج نشده‌ی UTXO_2 را دارد می‌تواند برون‌داد لنگر ANCHOR_OUTPUT کوچکی نیز به همراه داشته باشد که فقط S سرور می‌تواند آن را خرج کند. سپس A آذر می‌تواند آن را در درون‌داد تراکنش واگذاری FORFEIT_TX که به S می‌دهد قرار دهد. حالا تراکنش واگذاری FORFEIT_TX نمی‌تواند روی زنجیره ارسال شود مگر اینکه تراکنشی که شامل برون‌داد خرج نشده‌ی UTXO_2 و برون‌داد لنگر ANCHOR_OUTPUT است اول روی زنجیره ظاهر شود، و اینگونه شرط «اگر برون‌داد خرج نشده‌ی UTXO_2 وجود داشته باشد» برقرار می‌شود.
برون‌داد لنگر را می‌توان با قراردادن در یک درخت برون‌زنجیره از تراکنش بیرون از زنجیره نگه داشت البته این به این معنی است که اگر S سرور به لنگر نیاز داشت باید درخت را بگستراند.
زمان مورد نیاز برای پذیرفته شدن[ویرایش | ویرایش مبدأ]
یک پرداخت تا زمانی که برون‌داد خرج نشده‌ی مربوطه‌اش روی زنجیره ظاهر نشده، کامل نیست. مگر اینکه دریافت‌کننده حاضر باشد اعتماد کند که S سرور هرگز تراکنش‌هایی که در انتظار پذیرش روی زنجیره‌اند را تغییر نخواهد داد، با این پیشفرض پرداخت‌ها را می‌توان آنی در نظر گرفت.
مقایسه با پروتکل‌های دیگر[ویرایش | ویرایش مبدأ]
گردآورد پرداخت[ویرایش | ویرایش مبدأ]
مهمترین مزیت آرک در برابر گردآورد این است که برای خرج کردن فقط با S سرور سروکار خواهید داشت، نه تمام افراد درون گردآورد.
ایراد اصلی در برابر گردآورد پرداخت کم بودن نقدینگی است - سکه‌هایی که S سرور دوباره دریافت می‌کند درجا در دسترسش نیستند، پس هرچه سریع‌تر سکه‌ها دست به دست شوند، دارایی بیشتری از S سرور قفل می‌شود. اگر فرض بگیریم قفل زمانی 30 روزه است و هر 10 دقیقه، 1 بیت‌کوین دست به دست می‌شود، S سرور 6 * 24 ساعت* 30 روز= 4320 بیت‌کوین قفل شده خواهد داشت.