آرک

آرک (به انگلیسی: 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 باز می‌شود و سرور پول آذر را برمیدارد.

بهینگی روی زنجیره

خروجی خرج نشده‌ی UTXO_1 اینجا برای دو کاربر مشترک است و در نهایت کامل توسط S قابل برداشت است.

روال طی شده به خودی خود بهینه‌تر از این نیست که 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 بیت‌کوین قفل شده خواهد داشت.