fa.md

name	goal	objectives
مقدمه نظری به شبکه رعد و برق	کشف شبکه Lightning از یک دیدگاه فنی	کارکرد کانال های شبکه را درک کنید. با اصطلاحات HTLC، LNURL و UTXO آشنا شوید. همسو سازی مدیریت سیالیت و هزینه های LNN. شبکه Lightning را به عنوان یک شبکه بشناسید. درک کاربردهای نظری شبکه ی رعد و برق.

سفری به لایه دوم بیت کوین

به قلب شبکه Lightning بپرید، یک سیستم ضروری برای آینده معاملات بیت کوین. LNP201 یک دوره نظری در مورد کارکردهای فنی Lightning است. این دوره بنیاد و مکانیزم های این شبکه ثانویه را که برای سرعت بخشیدن، اقتصادی کردن و مقیاس پذیری پرداخت های بیت کوین طراحی شده است، فاش می کند.

با تشکر از شبکه کانال‌های پرداخت خود، لایتنینگ تراکنش‌های سریع و امن را بدون ثبت هر تبادل در بلاکچین بیت کوین فراهم می‌کند. در طول فصل‌ها، شما یاد خواهید گرفت که چگونه افتتاح، مدیریت و بستن کانال‌ها کار می‌کند، چگونه پرداخت‌ها از طریق گره‌های واسطه به صورت امن مسیریابی می‌شوند در حالی که نیاز به اعتماد را به حداقل می‌رساند، و چگونه مایعات را مدیریت کنید. شما کشف خواهید کرد که تراکنش‌های تعهد، HTLC ها، کلیدهای ابطال، مکانیزم‌های تنبیه، مسیریابی پیازی و فاکتورها چیست.

چه شما یک مبتدی بیت کوین باشید یا کاربر با تجربه تر، این دوره اطلاعات ارزشمندی را برای درک و استفاده از شبکه Lightning ارائه می دهد. با اینکه ما در قسمت های اولیه برخی از مبانی عملکرد بیت کوین را پوشش خواهیم داد، اما برای ورود به LNP201 ضروری است که ابتدا مبانی اختراع Satoshi را به خوبی مسلط شوید.

از کشف خود لذت ببرید!

+++

مبانی

32647d62-102b-509f-a3ba-ad1d6a4345f1

درک شبکه لایتنینگ

df6230ae-ff35-56ea-8651-8e65580730a8

به دوره LNP201 خوش آمدید، که هدف آن توضیح عملکرد فنی شبکه Lightning است.

شبکه Lightning یک شبکه از کانال‌های پرداخت است که بر روی پروتکل بیت کوین ساخته شده است، با هدف فراهم کردن تراکنش‌های سریع و کم هزینه. این امکان را می‌دهد تا کانال‌های پرداخت بین شرکت‌کنندگان ایجاد شود، که در آن تراکنش‌ها تقریباً به طور فوری و با هزینه‌های کمی انجام می‌شود، بدون نیاز به ثبت هر تراکنش به طور جداگانه بر روی بلاکچین. بنابراین، شبکه Lightning سعی دارد تا قابلیت مقیاس‌پذیری بیت کوین را بهبود بخشد و آن را برای پرداخت‌های کم ارزش قابل استفاده کند.

قبل از بررسی جنبه "شبکه"، مهم است که مفهوم کانال پرداخت در Lightning را درک کنیم، چگونه کار می کند و جزئیات خاص آن. این موضوع اولین فصل است.

مفهوم کانال پرداخت

یک کانال پرداخت اجازه می دهد دو طرف، در اینجا آلیس و باب، وجوه را در شبکه Lightning مبادله کنند. هر پروتاگونیست یک گره دارد، که با یک دایره نماد شده است، و کانال بین آنها با یک بخش خط نمایش داده شده است.

در مثال ما، آلیس 100،000 ساتوشی در سمت خود از کانال دارد و باب 30،000 ساتوشی، برای مجموع 130،000 ساتوشی، که ظرفیت کانال را تشکیل می‌دهد.

اما ساتوشی چیست؟

ساتوشی (یا "sat") یک واحد حساب در بیت کوین است. مشابه سنت برای یورو، ساتوشی فقط یک قسمت از بیت کوین است. یک ساتوشی برابر است با 0.00000001 بیت کوین، یا یک صدم میلیونم بیت کوین. استفاده از ساتوشی با افزایش ارزش بیت کوین، به طور فزاینده ای عملی می شود.

تخصیص وجوه در کانال

بیایید به کانال پرداخت برگردیم. مفهوم کلیدی در اینجا " سمت کانال " است. هر شرکت کننده اموالی را در سمت خود از کانال دارد: آلیس 100،000 ساتوشی و باب 30،000. همانطور که دیدیم، مجموع این اموال، ظرفیت کلی کانال را نشان می‌دهد، یک شماره که هنگام باز کردن آن تعیین می‌شود.

بیایید یک مثال از یک معامله Lightning بگیریم. اگر Alice می خواهد 40,000 ساتوشی به Bob بفرستد، این امکان پذیر است زیرا او دارای سرمایه کافی (100,000 ساتوشی) است. پس از این معامله، Alice 60,000 ساتوشی در سمت خود خواهد داشت و Bob 70,000.

ظرفیت کانال، در 130,000 ساتوشی، ثابت می‌ماند. چیزی که تغییر می‌کند تخصیص وجوه است. این سیستم اجازه نمی‌دهد که بیشتر از مقداری که دارید پول ارسال کنید. به عنوان مثال، اگر باب می‌خواست 80,000 ساتوشی به آلیس برگرداند، نمی‌توانست، زیرا فقط 70,000 دارد.

روش دیگری برای تصور تخصیص وجوه این است که به یک اسلایدر فکر کنید که نشان می‌دهد وجوه در کدام قسمت کانال قرار دارند. در ابتدا، با 100,000 ساتوشی برای آلیس و 30,000 ساتوشی برای باب، اسلایدر به طور منطقی در سمت آلیس قرار دارد. پس از معامله 40,000 ساتوشی، اسلایدر کمی به سمت باب حرکت می‌کند، که اکنون 70,000 ساتوشی دارد.

این نمایش می‌تواند برای تصور تعادل وجوه در یک کانال مفید باشد.

قواعد اساسی یک کانال پرداخت

نکته اولی که باید به یاد داشته باشید این است که ظرفیت کانال ثابت است. این کمی شبیه به قطر یک لوله است: این مقدار حداکثری از وجوهی را که می‌توان به یکباره از طریق کانال ارسال کرد، تعیین می‌کند.

بیایید یک مثال بزنیم: اگر الیس در سمت خود 130،000 ساتوشی داشته باشد، او فقط می تواند حداکثر 130،000 ساتوشی را در یک معامله به باب ارسال کند. با این حال، باب سپس می تواند این وجوه را به الیس برگرداند، چه به صورت جزئی یا کامل.

مهم است که بفهمیم ظرفیت ثابت کانال، حداکثر مقدار یک تراکنش را محدود می کند، اما تعداد کل تراکنش های ممکن و حجم کلی وجوه مبادله شده در کانال را محدود نمی کند.

از این فصل چه چیزی باید برداشت کنید؟

• ظرفیت یک کانال ثابت است و حداکثر مقداری را که می توان در یک معامله ارسال کرد، تعیین می کند.
• وجوه موجود در یک کانال بین دو شرکت کننده توزیع می‌شود و هر کدام فقط می‌توانند وجوهی را که در سمت خود دارند به دیگری ارسال کنند.
• شبکه Lightning بنابراین امکان تبادل سریع و کارآمد وجوه را فراهم می کند، در حالی که محدودیت های اعمال شده توسط ظرفیت کانال ها را رعایت می کند.

این پایان فصل اول است، جایی که ما بنیان‌های شبکه Lightning را می‌گذاریم. در فصل‌های آینده، ما خواهیم دید چگونه یک کانال را باز کنیم و عمیق‌تر در مفاهیم مورد بحث در اینجا شرکت کنیم.

بیتکوین، آدرس ها، UTXO، و تراکنش ها

0cfb7e6b-96f0-508b-9210-90bc1e28649d

این فصل کمی خاص است زیرا مستقیماً به Lightning اختصاص نمی یابد، بلکه به Bitcoin است. در واقع، شبکه Lightning یک لایه بر روی Bitcoin است. بنابراین برای درک درست کارکرد Lightning در فصل های بعدی، حیاتی است که مفاهیم اساسی Bitcoin را درک کنیم. در این فصل، ما مروری بر مبانی آدرس های دریافت Bitcoin، UTXOs، و همچنین کارکرد معاملات Bitcoin خواهیم داشت.

آدرس‌های بیت‌کوین، کلید‌های خصوصی، و کلید‌های عمومی

آدرس بیت کوین مجموعه ای از کاراکترها است که از یک کلید عمومی مشتق شده است، که خود از یک کلید خصوصی محاسبه می شود. همانطور که شما قطعاً می دانید، برای قفل کردن بیت کوین ها استفاده می شود، که معادل دریافت آنها در کیف پول ما است.

کلید خصوصی یک عنصر مخفی است که هرگز نباید به اشتراک گذاشته شود، در حالی که کلید عمومی و آدرس بدون خطر امنیتی قابل به اشتراک گذاشتن هستند (افشای آنها فقط یک خطر برای حریم خصوصی شما است). در اینجا یک نمایش متداول است که ما در طول این آموزش اتخاذ خواهیم کرد:

• کلیدهای خصوصی به صورت عمودی نمایش داده خواهند شد.
• کلیدهای عمومی به صورت افقی نمایش داده خواهند شد.
• رنگ آنها نشان می‌دهد که آنها را در اختیار دارد (الیس به رنگ نارنجی و باب به رنگ سیاه...).

معاملات بیت کوین: ارسال وجوه و اسکریپت ها

در بیت کوین، یک تراکنش شامل ارسال وجوه از یک آدرس به آدرس دیگر است. بیایید مثال ارسال 0.002 بیت کوین توسط آلیس به باب را بررسی کنیم. آلیس با استفاده از کلید خصوصی مرتبط با آدرس خود امضا می کند تراکنش را، بدین ترتیب ثابت می کند که واقعا قادر به خرج کردن این وجوه است. اما دقیقا چه اتفاقی در پشت این تراکنش می افتد؟ وجوه روی یک آدرس بیت کوین توسط یک اسکریپت قفل می شوند، نوعی برنامه کوچک که شرایط خاصی را برای خرج کردن وجوه تحمیل می کند.

متداول ترین اسکریپت نیاز به امضایی با کلید خصوصی مرتبط با آدرس دارد. وقتی آلیس یک تراکنش را با کلید خصوصی خود امضا می کند، او اسکریپت را باز می کند که موجب مسدود شدن وجوه می شود، و سپس می توان آنها را منتقل کرد. انتقال وجوه شامل افزودن یک اسکریپت جدید به این وجوه است، که مقرر می کند برای خرج کردن آنها این بار، امضای کلید خصوصی باب لازم خواهد بود.

UTXOs: خروجی‌های تراکنش‌های خرج نشده

در بیت کوین، آنچه ما واقعاً مبادله می کنیم بیت کوین ها به طور مستقیم نیستند، بلکه UTXOs (خروجی های تراکنش های خرج نشده)، به معنی "خروجی های تراکنش های خرج نشده".

یک UTXO قطعه ای از بیت کوین است که می تواند هر ارزشی داشته باشد، به عنوان مثال، 2,000 بیت کوین، 8 بیت کوین، یا حتی 8,000 ساتوشی. هر UTXO توسط یک اسکریپت قفل می شود و برای خرج کردن آن، باید شرایط اسکریپت را برآورده کنید، که اغلب یک امضا با کلید خصوصی متناظر با آدرس دریافت داده شده است.

UTXO ها قابل تقسیم نیستند. هر زمان که از آنها برای خرج کردن مقدار بیت کوینی که نماینده آن هستند استفاده می شود، باید به طور کامل انجام شود. این کمی شبیه به یک اسکناس بانک است: اگر شما یک اسکناس 10 یورو داشته باشید و باید به نانوایی 5 یورو بدهید، نمی توانید فقط اسکناس را نصف کنید. شما باید اسکناس 10 یورویی را به او بدهید و او 5 یورو عوضی به شما می دهد. این دقیقا همان اصلی است که برای UTXO ها در بیت کوین است! به عنوان مثال، وقتی الیس با کلید خصوصی خود یک اسکریپت را باز می کند، کل UTXO را باز می کند. اگر او بخواهد فقط بخشی از وجوه نماینده شده توسط این UTXO را به باب ارسال کند، می تواند آن را به چندین قسمت کوچکتر "تکه تکه" کند. سپس او 0.0015 BTC را به باب می فرستد و باقیمانده، 0.0005 BTC، را به یک آدرس تغییر می فرستد.

در اینجا یک مثال از یک معامله با 2 خروجی وجود دارد:

• یک UTXO به ارزش 0.0015 BTC برای باب، که توسط یک اسکریپت قفل شده است که نیاز به امضای کلید خصوصی باب دارد.
• یک UTXO به ارزش 0.0005 BTC برای آلیس، که توسط یک اسکریپت که نیاز به امضای خود او دارد، قفل شده است.

آدرس‌های چند امضا

علاوه بر آدرس‌های ساده‌ای که از یک کلید عمومی تولید می‌شوند، امکان ایجاد آدرس‌های چند امضا از چندین کلید عمومی وجود دارد. موردی که برای شبکه Lightning بسیار جالب است، آدرس چند امضای 2/2 است که از دو کلید عمومی تولید می‌شود:

برای خرج کردن وجوه قفل شده با این آدرس امضای چندگانه 2/2، لازم است با دو کلید خصوصی مرتبط با کلیدهای عمومی امضا کنید.

این نوع آدرس دقیقاً نمایشی از کانال های پرداخت در شبکه Lightning روی بلاکچین Bitcoin است.

از این فصل چه چیزی باید برداشت کنید؟

• یک آدرس بیت کوین از یک کلید عمومی به دست می آید، که خود از یک کلید خصوصی مشتق شده است.
• وجوه روی بیت کوین توسط اسکریپت ها قفل می شوند، و برای خرج کردن این وجوه، باید اسکریپت را رضایت دهید، که معمولاً شامل ارائه یک امضا با کلید خصوصی متناظر است.
• UTXOها** قطعاتی از بیت کوین هستند که توسط اسکریپت ها قفل شده اند، و هر تراکنش در بیت کوین شامل باز کردن یک UTXO و سپس ایجاد یک یا چند مورد جدید به عنوان بازگشت است.
• آدرس‌های 2/2 با امضای چندگانه** نیاز به امضای دو کلید خصوصی برای خرج کردن وجوه دارند. این آدرس‌های خاص در زمینه Lightning برای ایجاد کانال‌های پرداخت استفاده می‌شوند.

این فصل در مورد بیت کوین به ما اجازه داده است تا برخی از مفاهیم ضروری برای آنچه در پیش است را مرور کنیم. در فصل بعدی، ما به طور خاص کشف خواهیم کرد که چگونه افتتاح کانال ها در شبکه Lightning کار می کند.

باز و بسته کردن کانال‌ها

900b5b6b-ccd0-5b2f-9424-4b191d0e935d

افتتاح کانال

96243eb0-f6b5-5b68-af1f-fffa0cc16bfe

در این فصل، ما به طور دقیق تر خواهیم دید که چگونه یک کانال پرداخت را در شبکه Lightning باز کنیم و ارتباط این عملیات با سیستم بیت کوین زیربنایی را درک کنیم.

کانال‌های رعد و برق

همانطور که در فصل اول دیدیم، یک کانال پرداخت در Lightning می تواند به یک "لوله" برای تبادل وجوه بین دو شرکت کننده (آلیس و باب در مثال های ما) مقایسه شود. ظرفیت این کانال متناسب با مجموع وجوه موجود در هر طرف است. در مثال ما، آلیس 100,000 ساتوشی و باب 30,000 ساتوشی دارد، که می دهد یک ظرفیت کلی از 130,000 ساتوشی.

سطوح تبادل اطلاعات

بسیار حیاتی است که سطوح مختلف مبادله در شبکه Lightning را به طور واضح تشخیص دهیم:

• ارتباطات نقطه به نقطه (پروتکل Lightning)**: این پیام‌هایی هستند که گره‌های Lightning برای ارتباط با یکدیگر ارسال می‌کنند. ما این پیام‌ها را با خطوط مشکی خط خطی در نمودارهایمان نشان خواهیم داد.
• کانال‌های پرداخت (پروتکل Lightning)**: این مسیرهایی برای تبادل وجوه در Lightning هستند، که ما آنها را با خطوط سیاه ثابت نشان خواهیم داد.
• معاملات بیت کوین (پروتکل بیت کوین)**: این معاملاتی هستند که در زنجیره انجام می‌شوند، که ما آنها را با خطوط نارنجی نشان خواهیم داد.

لازم به ذکر است که یک نود Lightning می‌تواند بدون باز کردن یک کانال از طریق پروتکل P2P ارتباط برقرار کند، اما برای تبادل وجوه، نیاز به یک کانال است.

مراحل باز کردن یک کانال رعد و برق

1. تبادل پیام: آلیس می‌خواهد یک کانال با باب ایجاد کند. او یک پیام حاوی مقداری که می‌خواهد در کانال سپرده کند (130،000 سات) و کلید عمومی خود را به او می‌فرستد. باب با اشتراک‌گذاری کلید عمومی خود پاسخ می‌دهد.

2. ایجاد آدرس چند امضا: با این دو کلید عمومی، آلیس یک آدرس چند امضای 2/2 ایجاد می کند، به این معنی که وجوهی که بعداً در این آدرس سپرده می شوند، نیاز به هر دو امضا (آلیس و باب) برای خرج شدن دارند.

3. تراکنش سپرده: آلیس یک تراکنش بیت کوین برای سپردن وجوه در این آدرس چند امضا آماده می کند. به عنوان مثال، او ممکن است تصمیم بگیرد 130,000 ساتوشی را به این آدرس چند امضا ارسال کند. این تراکنش ساخته شده اما هنوز در بلاکچین منتشر نشده است.

4. تراکنش برداشت: قبل از انتشار تراکنش واریز، آلیس یک تراکنش برداشت می‌سازد تا در صورت بروز مشکل با باب، بتواند سرمایه خود را بازیابی کند. در واقع، هنگامی که آلیس تراکنش واریز را منتشر می‌کند، ساتوشی‌های او در یک آدرس چند امضایی 2/2 قفل می‌شود که برای باز کردن آن نیاز به امضای هر دو آلیس و باب دارد. آلیس با ساخت تراکنش برداشت، خود را در برابر این ریسک از دست دادن محافظت می‌کند که اجازه می‌دهد سرمایه خود را بازیابی کند.

5. امضای باب: آلیس تراکنش سپرده را به عنوان مدرک برای باب ارسال می کند و از او می خواهد که تراکنش برداشت را امضا کند. هنگامی که امضای باب روی تراکنش برداشت به دست می آید، آلیس مطمئن می شود که در هر زمانی می تواند سرمایه خود را بازیابی کند، زیرا حالا فقط امضای خود او لازم است تا قفل چند امضا را باز کند.

6. انتشار تراکنش سپرده: پس از دریافت امضای باب، الیس می‌تواند تراکنش سپرده را در بلاکچین بیتکوین منتشر کند، بدین ترتیب رسماً کانال لایتنینگ بین دو کاربر را باز می‌کند.

کانال کی باز است؟

کانال زمانی به حساب می‌آید که معامله سپرده در یک بلوک بیت کوین قرار گرفته و به عمق معینی از تاییدیه‌ها (تعداد بلوک‌های بعدی) رسیده باشد.

از این فصل چه چیزی باید به یاد داشته باشید؟

• باز کردن یک کانال با تبادل پیام ها بین دو طرف شروع می شود (تبادل مقادیر و کلیدهای عمومی).
• یک کانال با ایجاد یک آدرس چند امضای 2/2 و واریز وجوه به آن از طریق یک معامله بیت کوین شکل می گیرد.
• شخصی که کانال را باز می کند، اطمینان حاصل می کند که می تواند سرمایه خود را بازیابی کند از طریق معامله برداشت امضاء شده توسط طرف دیگر قبل از انتشار معامله سپرده.

در فصل بعدی، ما به بررسی کارکرد فنی یک معامله Lightning در یک کانال خواهیم پرداخت.

تراکنش تعهدی

7d3fd135-129d-5c5a-b306-d5f2f1e63340

در این فصل، ما عملکرد فنی یک معامله در یک کانال در شبکه Lightning را کشف خواهیم کرد، یعنی زمانی که وجوه از یک طرف کانال به طرف دیگر منتقل می شوند.

یادآوری از چرخه عمر کانال

همانطور که قبلاً دیده شده است، یک کانال Lightning با یک معامله Bitcoin باز می شود. کانال می تواند در هر زمانی بسته شود، همچنین از طریق یک معامله Bitcoin. بین این دو لحظه، تعداد تقریباً بی نهایتی از معاملات می تواند در کانال انجام شود، بدون اینکه از طریق بلاکچین Bitcoin برود. بیایید ببینیم در طول یک معامله در کانال چه اتفاقی می افتد.

وضعیت اولیه کانال

در زمان باز کردن کانال، آلیس 130,000 ساتوشی را در آدرس چند امضای کانال سپرده کرد. بنابراین، در حالت اولیه، تمام سرمایه ها در سمت آلیس است. قبل از باز کردن کانال، آلیس همچنین از باب امضای یک معامله برداشت گرفت، که او را قادر می سازد در صورت تمایل به بستن کانال، سرمایه خود را بازیابی کند.

معاملات منتشر نشده: معاملات تعهد

وقتی آلیس یک معامله در کانال برای ارسال وجوه به باب ایجاد می کند، یک معامله بیت کوین جدید برای بازتاب این تغییر در توزیع وجوه ایجاد می شود. این معامله، که معامله تعهد نامیده می شود، در بلاکچین منتشر نمی شود اما نمایانگر وضعیت جدید کانال پس از معامله رعد و برق است.

بیایید یک مثال بگیریم که الیس 30،000 ساتوشی به باب می‌فرستد:

• اولاً**: آلیس 130,000 ساتوشی دارد.
• پس از معامله**: آلیس 100,000 ساتوشی دارد، و باب 30,000 ساتوشی.

برای تأیید این انتقال، آلیس و باب یک معامله بیت کوین منتشر نشده جدید ایجاد می کنند که 100,000 ساتوشی به آلیس و 30,000 ساتوشی به باب از آدرس چند امضا ارسال می کند. هر دو طرف به طور مستقل این معامله را می سازند، اما با داده های یکسان (مقادیر و آدرس ها). پس از ساخت، هر کدام معامله را امضا می کنند و امضای خود را با دیگری مبادله می کنند. این امکان را به هر طرف می دهد که در صورت لزوم معامله را در هر زمان منتشر کند تا سهم خود را از کانال در بلاکچین بیت کوین اصلی بازیابی کند.

روند انتقال: فاکتور

وقتی باب می‌خواهد پول دریافت کند، او یک صورتحساب به مبلغ 30,000 ساتوشی به آلیس می‌فرستد. سپس آلیس با شروع انتقال درون کانال، این صورتحساب را پرداخت می‌کند. همانطور که دیدیم، این فرآیند بر ایجاد و امضای یک معامله تعهد جدید تکیه دارد.

هر تراکنش تعهدی نمایانگر توزیع جدید وجوه در کانال پس از انتقال است. در این مثال، پس از تراکنش، باب 30،000 ساتوشی دارد و الیس 100،000 ساتوشی دارد. اگر یکی از دو شرکت کننده تصمیم بگیرد این تراکنش تعهدی را در بلاکچین منتشر کند، منجر به بسته شدن کانال خواهد شد و وجوه بر اساس این توزیع آخر توزیع خواهد شد.

وضعیت جدید پس از معامله دوم

بیایید یک مثال دیگر برداریم: پس از اولین معامله که الیس 30,000 ساتوشی به باب ارسال کرد، باب تصمیم می‌گیرد 10,000 ساتوشی را به الیس برگرداند. این یک وضعیت جدید برای کانال ایجاد می‌کند. معامله تعهد جدید این توزیع به‌روز شده را نشان خواهد داد:

• آلیس ** اکنون ** 110,000 ساتوشی ** دارد.
• باب** دارای 20,000 ساتوشی است.

دوباره، این تراکنش در بلاکچین منتشر نمی‌شود اما در هر زمانی که کانال بسته شود می‌تواند منتشر شود.

به طور خلاصه، هنگامی که وجوه در یک کانال Lightning منتقل می‌شوند:

• آلیس و باب یک معامله تعهدی جدید ایجاد می کنند، که توزیع جدید وجوه را نشان می دهد.
• این معامله بیت کوین توسط هر دو طرف امضا شده است، اما تا زمانی که کانال باز است، منتشر نمی شود در بلاکچین بیت کوین.
• تراکنش‌های تعهد اطمینان می‌دهند که هر شرکت‌کننده می‌تواند در هر زمانی از زنجیره بلوک بیت کوین، با انتشار آخرین تراکنش امضا شده، سرمایه خود را بازیابی کند.

با این حال، این سیستم یک نقص بالقوه دارد که ما در فصل بعدی به آن می‌پردازیم. ما خواهیم دید که چگونه هر شرکت‌کننده می‌تواند خود را در برابر تلاش برای تقلب توسط طرف دیگر محافظت کند.

کلید ابطال

f2f61e5b-badb-5947-9a81-7aa530b44e59

در این فصل، ما عمیق‌تر درباره چگونگی کار کردن تراکنش‌ها در شبکه Lightning بحث خواهیم کرد با بررسی مکانیزم‌هایی که برای محافظت در برابر تقلب در جریان است، تضمین می‌کنیم که هر طرف به قوانین درون یک کانال پایبند است.

یادآوری: معاملات تعهدی

همانطور که قبلاً دیده شده است، معاملات در Lightning بر مبنای معاملات تعهدی ناشر شده استناد می‌کنند. این معاملات توزیع فعلی وجوه در کانال را نشان می‌دهند. هنگامی که یک معامله Lightning جدید انجام می‌شود، یک معامله تعهدی جدید ایجاد و توسط هر دو طرف امضا می‌شود تا وضعیت جدید کانال را نشان دهد.

بیایید یک مثال ساده را در نظر بگیریم:

• وضعیت اولیه**: آلیس 100,000 ساتوشی دارد، باب 30,000 ساتوشی.
• پس از معامله ای که آلیس 40,000 ساتوشی را به باب می فرستد، معامله تعهد جدید به شرح زیر وجوه را توزیع می کند:
  • آلیس: 60،000 ساتوشی
  • باب: ۷۰،۰۰۰ ساتوشی

در هر زمان، هر دو طرف می توانند آخرین تراکنش تعهدی را که برای بستن کانال امضا شده است منتشر کنند و سرمایه خود را بازیابی کنند.

عیب: تقلب با انتشار یک معامله قدیمی

مشکل بالقوه ای پیش می آید اگر یکی از طرفین تصمیم بگیرد با انتشار یک تراکنش تعهد قدیمی تقلب کند. برای مثال، الیس می تواند یک تراکنش تعهد قدیمی را که در آن 100,000 ساتوشی داشته، منتشر کند، حتی اگرچه اکنون در واقع فقط 60,000 دارد. این امکان را به او می دهد تا 40,000 ساتوشی را از باب دزدیده کند.

بدتر از این، آلیس می تواند اولین معامله برداشت را منتشر کند، معامله ای قبل از اینکه کانال باز شود، جایی که او 130,000 ساتوشی داشت، و بنابراین تمام وجوه کانال را سرقت کند.

راه حل: کلید ابطال و قفل زمانی

برای جلوگیری از این نوع تقلب توسط آلیس، در شبکه Lightning، مکانیزم های امنیتی به تراکنش های تعهد اضافه می شوند:

1. قفل زمانی: هر تراکنش تعهد شامل یک قفل زمانی برای وجوه آلیس است. قفل زمانی یک ابزار اولیه قرارداد هوشمند است که شرط زمانی را تعیین می کند که باید برای افزودن یک تراکنش به بلوک برآورده شود. این به این معنی است که آلیس نمی تواند وجوه خود را تا زمانی که تعداد معینی از بلوک ها گذشته باشد، در صورت انتشار یکی از تراکنش های تعهد، بازیابی کند. این قفل زمانی از تأیید تراکنش تعهد شروع به اعمال می شود. مدت زمان آن معمولاً متناسب با اندازه کانال است، اما می توان آن را به صورت دستی نیز تنظیم کرد.

2. کلید لغو: وجوه آلیس همچنین می تواند فوراً توسط باب اگر او کلید لغو را در اختیار داشته باشد، خرج شود. این کلید شامل یک رازی است که توسط آلیس نگه داشته می شود و یک رازی که توسط باب نگه داشته می شود. توجه داشته باشید که این راز برای هر تراکنش تعهد متفاوت است.

به لطف این دو مکانیزم ترکیبی، باب فرصت می‌یابد تلاش آلیس برای تقلب را تشخیص دهد و با بازیابی خروجی خود با کلید لغو، که برای باب به معنای بازیابی تمام وجوه کانال است، او را مجازات کند. معامله تعهد جدید ما حالا به این شکل خواهد بود:

بیایید کارکرد این مکانیزم را با هم به تفصیل بررسی کنیم.

روند به روزرسانی تراکنش

وقتی آلیس و باب وضعیت کانال را با یک معامله جدید Lightning به روز می کنند، آنها به طور پیش از موعد رازهای مربوط به خود را برای معامله تعهد قبلی (که منسوخ خواهد شد و ممکن است به یکی از آنها اجازه دهد تقلب کند) مبادله می کنند. این بدان معناست که، در وضعیت جدید کانال:

• آلیس و باب یک تراکنش تعهد جدید دارند که توزیع فعلی وجوه پس از تراکنش رعد و برق را نشان می‌دهد.
• هر کدام از آنها رمز دیگری را برای معامله قبلی دارند، که این امکان را به آنها می‌دهد تا فقط در صورتی کلید لغو را استفاده کنند که یکی از آنها سعی در تقلب کند با انتشار یک معامله با وضعیت قدیمی در mempools نودهای بیت کوین. در واقع، برای تنبیه طرف دیگر، لازم است هر دو رمز و معامله تعهدی طرف دیگر را نگه دارید، که شامل ورودی امضا شده است. بدون این معامله، کلید لغو به تنهایی بی‌فایده است. تنها راه برای به دست آوردن این معامله این است که آن را از mempools (در معاملاتی که در انتظار تأیید هستند) یا در معاملات تأیید شده در بلاکچین در طول timelock بازیابی کنید، که این نشان می‌دهد طرف دیگر سعی در تقلب دارد، خواه عمدی باشد یا ناخواسته.

بیایید یک مثال برداریم تا این فرآیند را به خوبی درک کنیم:

1. وضعیت اولیه: آلیس 100,000 ساتوشی دارد، باب 30,000 ساتوشی.

2. باب می‌خواهد 40,000 ساتوشی را از آلیس از طریق کانال رعد و برق آنها دریافت کند. برای این کار:

   • او فاکتور را همراه با رمز مخفی خود برای کلید ابطال تراکنش تعهد قبلی خود به او می‌فرستد.
   • در پاسخ، الیس امضای خود را برای معامله جدید باب ارائه می دهد، همچنین رمز مخصوص کلید لغو معامله قبلی خود را.
   • در نهایت، باب امضای خود را برای تراکنش تعهد جدید آلیس ارسال می کند.
   • این مبادلات به آلیس اجازه می‌دهد تا 40,000 ساتوشی را از طریق کانال خود به باب در لایتنینگ ارسال کند، و تراکنش‌های تعهد جدید حالا این توزیع جدید وجوه را نشان می‌دهد.

3. اگر آلیس تلاش کند تراکنش تعهد قدیمی را که هنوز 100,000 ساتوشی متعلق به او بود منتشر کند، باب که کلید لغو را به دست آورده است، می تواند فوراً با استفاده از این کلید وجوه را بازیابی کند، در حالی که آلیس توسط قفل زمانی مسدود می شود.

حتی اگر، در این مورد، باب هیچ منفعت اقتصادی در تقلب کردن نداشته باشد، اگر او به هر حال این کار را انجام دهد، آلیس همچنین از حفاظت متقارن بهره می برد که به او همان ضمانت ها را می دهد.

از این فصل چه چیزی باید برداشت کنید؟

تراکنش‌های تعهد در شبکه Lightning شامل مکانیزم‌های امنیتی هستند که هم خطر تقلب را کاهش می‌دهند و هم انگیزه‌های انجام آن را. قبل از امضای یک تراکنش تعهد جدید، آلیس و باب رمزهای خود را برای تراکنش‌های تعهد قبلی با هم تبادل می‌کنند. اگر آلیس سعی کند یک تراکنش تعهد قدیمی را منتشر کند، باب می‌تواند با استفاده از کلید ابطال تمام وجوه را قبل از آلیس بازیابی کند (زیرا او توسط قفل زمانی مسدود شده است)، که این کار او را برای تلاش برای تقلب مجازات می‌کند.

این سیستم امنیتی اطمینان می‌دهد که شرکت‌کنندگان به قوانین شبکه Lightning پایبند هستند و نمی‌توانند از انتشار معاملات تعهد قدیمی سود ببرند.

در این نقطه از آموزش، شما اکنون می‌دانید که چگونه کانال‌های Lightning باز می‌شوند و چگونه معاملات در این کانال‌ها کار می‌کنند. در فصل بعدی، ما روش‌های مختلف برای بستن یک کانال و بازیابی بیت‌کوین‌های شما در بلاکچین اصلی را کشف خواهیم کرد.

بسته شدن کانال

29a72223-2249-5400-96f0-3756b1629bc2

در این فصل، ما در مورد بستن یک کانال در شبکه Lightning صحبت خواهیم کرد، که این کار از طریق یک معامله بیت کوین انجام می شود، دقیقاً مانند باز کردن یک کانال. پس از دیدن چگونگی کار معاملات درون یک کانال، حالا وقت آن رسیده است که ببینیم چگونه یک کانال را ببندیم و سرمایه ها را در بلاکچین بیت کوین بازیابی کنیم.

یادآوری از چرخه عمر کانال

چرخه حیات یک کانال با باز کردن آن از طریق یک معامله بیت کوین شروع می شود، سپس معاملات رعد و برق در آن انجام می شوند، و در نهایت، وقتی طرفین می خواهند سرمایه خود را بازیابی کنند، کانال از طریق یک معامله بیت کوین دوم بسته می شود. معاملات میانی انجام شده در رعد و برق توسط معاملات تعهد ناشر نشده نمایش داده می شوند.

سه نوع بسته شدن کانال

سه راه اصلی برای بستن این کانال وجود دارد که می توان آنها را خوب، وحشی و غایب نامید (الهام گرفته از اندریاس آنتونوپولوس در تسلط بر شبکه رعد و برق):

1. خوب: بستن همکارانه، جایی که آلیس و باب موافقت می کنند کانال را ببندند.

2. بد: بستن اجباری، جایی که یکی از طرف‌ها تصمیم می‌گیرد کانال را به صورت صادقانه ببندد، اما بدون رضایت طرف دیگر.

3. زشت: بستن با تقلب، که در آن یکی از طرف‌ها سعی می‌کند با انتشار یک معامله تعهد قدیمی (هر کدام به جز آخرین، که توزیع واقعی و عادلانه وجوه را نشان می‌دهد) وجوه را سرقت کند.

بیایید یک مثال بزنیم:

• آلیس 100,000 ساتوشی دارد و باب 30,000 ساتوشی.
• این توزیع در 2 معامله تعهد (یکی برای هر کاربر) منعکس می‌شود که منتشر نمی‌شوند، اما در صورت بسته شدن کانال می‌توانند منتشر شوند.

خوب: بستن همکاری

در بستن همکارانه، آلیس و باب موافقت می کنند که کانال را ببندند. اینجا چگونگی انجام آن است:

1. آلیس پیامی را از طریق پروتکل ارتباطی Lightning برای پیشنهاد بستن کانال به باب می‌فرستد.

2. باب موافقت می کند و دو طرف هیچ معامله دیگری در کانال انجام نمی دهند.

3. آلیس و باب هزینه های معامله بسته شدن را با هم مذاکره می کنند. این هزینه ها معمولا بر اساس بازار هزینه بیت کوین در زمان بسته شدن محاسبه می شوند. مهم است توجه داشته باشید که همیشه فردی که کانال را باز کرده است (در مثال ما آلیس) هزینه های بسته شدن را می پردازد.

4. آنها یک معامله بستن جدید می سازند. این معامله شبیه به معامله تعهد است، اما بدون قفل های زمانی یا مکانیزم های ابطال، زیرا هر دو طرف همکاری می کنند و هیچ خطری از تقلب وجود ندارد. بنابراین، این معامله بستن همکاری متفاوت از معاملات تعهد است.

برای مثال، اگر آلیس 100،000 ساتوشی داشته باشد و باب 30،000 ساتوشی، تراکنش نهایی 100،000 ساتوشی را به آدرس آلیس و 30،000 ساتوشی را به آدرس باب می‌فرستد، بدون محدودیت زمانی. هنگامی که این تراکنش توسط هر دو طرف امضا می‌شود، توسط آلیس منتشر می‌شود. هنگامی که تراکنش در بلاکچین بیت کوین تأیید می‌شود، کانال رعد و برق رسماً بسته خواهد شد.

بستن همکارانه روش ترجیحی برای بستن است زیرا سریع است (بدون قفل زمانی) و هزینه های تراکنش بر اساس شرایط فعلی بازار بیت کوین تنظیم می شوند. این از پرداخت کمتر از حد جلوگیری می کند، که می تواند معامله را در mempools مسدود کند، یا پرداخت بیش از حد لازم، که منجر به از دست دادن مالی غیر ضروری برای شرکت کنندگان می شود.

بد: تعطیلی اجباری

وقتی گره آلیس پیامی به گره باب می فرستد و درخواست بستن همکارانه می کند، اگر او پاسخی ندهد (برای مثال، به دلیل قطع اینترنت یا مشکل فنی)، آلیس می تواند با انتشار آخرین تراکنش تعهد امضا شده، بستن اجباری را ادامه دهد.

در این مورد، آلیس به سادگی آخرین معامله تعهد را منتشر می کند، که وضعیت کانال را در زمانی که آخرین معامله Lightning با توزیع صحیح وجوه انجام شد، نشان می دهد.

این معامله شامل یک قفل زمانی برای وجوه آلیس است، که باعث کند شدن بستن می شود.

همچنین، هزینه‌های معامله تعهد ممکن است در زمان بسته شدن نامناسب باشند، زیرا زمانی که معامله ایجاد شد، گاهی اوقات چند ماه قبل، تعیین شده بودند. به طور کلی، مشتریان Lightning هزینه‌ها را برای جلوگیری از مشکلات آینده بیش‌برآورد می‌کنند، اما این می‌تواند منجر به هزینه‌های بیش از حد، یا برعکس خیلی کم شود.

به طور خلاصه، بستن اجباری گزینه‌ای است که در آخرین لحظات زمانی که همتا دیگر پاسخ نمی‌دهد، استفاده می‌شود. این روش کندتر و کم اقتصادی‌تر از بستن همکارانه است. بنابراین، باید تا حد امکان از آن خودداری شود.

تقلب: تقلب کردن

سرانجام، بستن با تقلب زمانی رخ می‌دهد که یکی از طرف‌ها سعی می‌کند تراکنش تعهد قدیمی را منتشر کند، اغلب جایی که بیشتر از آنچه باید داشته است. به عنوان مثال، الیس ممکن است تراکنش قدیمی را منتشر کند که در آن 120,000 ساتوشی متعلق به او بود، در حالی که در حقیقت فقط 100,000 ساتوشی الان متعلق به او است.

باب، برای جلوگیری از این تقلب، بلاکچین بیت کوین و mempool آن را نظارت می کند تا مطمئن شود الیس معامله قدیمی را منتشر نکرده است. اگر باب تلاشی برای تقلب را تشخیص دهد، می تواند از کلید ابطال استفاده کند تا موجودی الیس را بازیابی کند و او را با گرفتن کل موجودی کانال مجازات کند. از آنجا که الیس توسط قفل زمانی در خروجی خود مسدود شده است، باب وقت دارد تا بدون قفل زمانی در سمت خود، کل مبلغ را در آدرسی که متعلق به اوست بازیابی کند.

بدیهی است که تقلب می تواند در صورت عدم اقدام باب در زمان تعیین شده توسط قفل زمانی بر خروجی آلیس موفق شود. در این حالت، خروجی آلیس باز می شود، امکان مصرف آن را برای ایجاد یک خروجی جدید به آدرسی که او کنترل می کند، فراهم می کند.

از این فصل چه چیزی باید برداشت کنید؟

سه راه برای بستن یک کانال وجود دارد:

1. بستن همکاری: سریع و کم هزینه، جایی که هر دو طرف موافقت می کنند کانال را ببندند و یک معامله بستن خاص را منتشر کنند.

2. بسته شدن اجباری: کمتر مطلوب است، زیرا بر انتشار یک تراکنش تعهدی استوار است، با هزینه های احتمالاً نامناسب و یک قفل زمانی، که بسته شدن را کند می کند.

3. تقلب: اگر یکی از طرف‌ها سعی کند با انتشار یک معامله قدیمی، پول را بدزدد، طرف دیگر می‌تواند از کلید لغو برای مجازات این تقلب استفاده کند.

در فصل های آینده، ما از یک دیدگاه گسترده تر شبکه Lightning را بررسی خواهیم کرد، با تمرکز بر چگونگی عملکرد شبکه آن.

یک شبکه نقدینگی

a873f1cb-751f-5f4a-9ed7-25092bfdef11

شبکه رعد و برق

45a7252c-fa4f-554b-b8bb-47449532918e

در این فصل، ما بررسی خواهیم کرد که چگونه پرداخت ها در شبکه Lightning می توانند به گیرنده برسند حتی اگر آنها مستقیماً توسط یک کانال پرداخت متصل نشوند. Lightning در واقع یک شبکه از کانال های پرداخت است، که اجازه می دهد تا وجوه از طریق کانال های سایر شرکت کنندگان به یک گره دور دست ارسال شود. ما کشف خواهیم کرد که چگونه پرداخت ها در سراسر شبکه مسیریابی می شوند، چگونه سیالیت بین کانال ها حرکت می کند و چگونه هزینه های معامله محاسبه می شوند.

شبکه کانال‌های پرداخت

در شبکه Lightning، یک تراکنش متناظر با انتقال وجوه بین دو نود است. همانطور که در فصل های قبلی دیده شد، برای انجام تراکنش های Lightning، لازم است که یک کانال با شخصی باز کنید. این کانال امکان انجام تعداد تقریبا بی نهایتی از تراکنش های off-chain را قبل از بستن آن برای بازیابی موجودی on-chain فراهم می کند. با این حال، این روش این معایب را دارد که نیاز به یک کانال مستقیم با شخص دیگری برای دریافت یا ارسال وجوه دارد، که این بدان معناست که یک تراکنش افتتاحیه و یک تراکنش بسته شدن برای هر کانال لازم است. اگر من قصد داشته باشم تعداد زیادی پرداخت با این شخص انجام دهم، باز کردن و بستن یک کانال مقرون به صرفه می شود. در مقابل، اگر من فقط نیاز به انجام چند تراکنش Lightning داشته باشم، باز کردن یک کانال مستقیم مزیتی ندارد، زیرا این به من هزینه 2 تراکنش on-chain را برای تعداد محدودی از تراکنش های off-chain می آورد. این مورد ممکن است به عنوان مثال زمانی رخ دهد که بخواهم بدون برنامه ریزی برای بازگشت، با Lightning در یک فروشگاه پرداخت کنم.

برای حل این مشکل، شبکه Lightning اجازه می دهد تا یک پرداخت را از طریق چندین کانال و گره های واسطه انتقال دهد، بنابراین معامله بدون یک کانال مستقیم با فرد دیگر را فعال می کند.

برای مثال، تصور کنید که:

• آلیس (به رنگ نارنجی) یک کانال با سوزی (به رنگ خاکستری) دارد که 100,000 ساتوشی از طرف او و 30,000 ساتوشی از طرف سوزی در آن قرار دارد.
• سوزی یک کانال با باب دارد که در آن او 250,000 ساتوشی دارد و باب هیچ ساتوشی ندارد.

اگر آلیس بخواهد بدون ایجاد یک کانال مستقیم با باب، وجوه را به او ارسال کند، او باید از طریق سوزی برود و هر کانال باید مایعیت هر طرف را تنظیم کند. ساتوشی های ارسال شده در کانال های مربوط به خود باقی می مانند؛ آنها واقعاً "کانال ها را عبور" نمی کنند، اما انتقال از طریق تنظیم مایعیت داخلی در هر کانال انجام می شود.

فرض کنید آلیس می‌خواهد 50,000 ساتوشی به باب ارسال کند:

1. آلیس 50,000 ساتوشی را در کانال مشترکشان به سوزی می‌فرستد.

2. سوزی این انتقال را با ارسال 50,000 ساتوشی به باب در کانال خود تکرار می کند.

بنابراین، پرداخت از طریق حرکت سیالیت در هر کانال به باب هدایت می شود. در پایان عملیات، الیس با 50،000 ساتوشی به پایان می رسد. او واقعاً 50،000 ساتوشی منتقل کرده است زیرا در ابتدا، او 100،000 داشت. باب، از سوی خود، با 50،000 ساتوشی اضافی به پایان می رسد. برای سوزی (گره میانی)، این عملیات بی تأثیر است: در ابتدا، او 30،000 ساتوشی در کانال خود با الیس و 250،000 ساتوشی در کانال خود با باب، مجموعاً 280،000 ساتوشی داشت. پس از عملیات، او 80،000 ساتوشی در کانال خود با الیس و 200،000 ساتوشی در کانال خود با باب نگه می دارد، که همان مجموعه ای است که در ابتدا داشت.

این انتقال بنابراین توسط سیالیت موجود در جهت انتقال محدود می‌شود.

محاسبه مسیر و محدودیت های نقدینگی

بیایید یک مثال نظری از شبکه دیگری را در نظر بگیریم با:

• 130,000 ساتوشی** در سمت آلیس (به رنگ نارنجی) در کانال او با سوزی (به رنگ خاکستری).
• 90,000 ساتوشی** در سمت سوزی و 200,000 ساتوشی در سمت کارول (به رنگ صورتی).
• 150,000 ساتوشی** در سمت کارول و 100,000 ساتوشی در سمت باب.

حداکثر مقداری که آلیس می تواند در این پیکربندی به باب ارسال کند 90,000 ساتوشی است، زیرا او توسط کمترین سیالیت در کانال از سوزی به کارول محدود شده است. در جهت مخالف (از باب به آلیس)، هیچ پرداختی امکان پذیر نیست زیرا سمت سوزی در کانال با آلیس هیچ ساتوشی ندارد. بنابراین، هیچ مسیری برای انتقال در این جهت قابل استفاده نیست.

آلیس 40,000 ساتوشی را از طریق کانال‌ها به باب می‌فرستد:

1. آلیس 40,000 ساتوشی را به کانال خود با سوزی منتقل می کند.

2. سوزی 40,000 ساتوشی را به کارول در کانال مشترکشان منتقل می کند.

3. کارول سرانجام 40,000 ساتوشی را به باب منتقل می کند.

ساتوشی های ارسال شده در هر کانال در کانال باقی می ماند، بنابراین ساتوشی هایی که کارول به باب ارسال کرده است همانند آنهایی نیست که آلیس به سوزی ارسال کرده است. انتقال فقط با تنظیم مایعیت درون هر کانال انجام می شود. علاوه بر این، ظرفیت کلی کانال ها بدون تغییر باقی می ماند.

مانند مثال قبلی، پس از تراکنش، گره منبع (آلیس) 40،000 ساتوشی کمتر دارد. گره های میانی (سوزی و کارول) مقدار کلی خود را حفظ می کنند، که باعث می شود عملیات برای آنها بی تاثیر باشد. در نهایت، گره مقصد (باب) 40،000 ساتوشی اضافی دریافت می کند.

نقش گره‌های میانی بنابراین در عملکرد شبکه Lightning بسیار مهم است. آن‌ها با ارائه مسیرهای متعدد برای پرداخت‌ها، انتقالات را تسهیل می‌کنند. برای تشویق این گره‌ها به ارائه نقدینگی خود و مشارکت در مسیریابی پرداخت‌ها، هزینه‌های مسیریابی به آن‌ها پرداخت می‌شود.

هزینه های مسیریابی

گره‌های میانی برای اجازه دادن به پرداخت‌ها برای عبور از کانال‌های خود، هزینه‌هایی را اعمال می‌کنند. این هزینه‌ها توسط هر گره برای هر کانال تعیین می‌شوند. این هزینه‌ها از 2 عنصر تشکیل شده‌اند:

1. "هزینه پایه": مقدار ثابتی برای هر کانال، اغلب به طور پیش فرض 1 sat، اما قابل سفارشی سازی.

2. "هزینه متغیر": درصدی از مبلغ انتقال داده شده، محاسبه شده در قسمت های در میلیون (ppm). به طور پیش فرض، آن 1 ppm است (1 ساتوشی برای هر میلیون ساتوشی انتقال داده شده)، اما همچنین می توان آن را تنظیم کرد.

هزینه ها نیز بسته به جهت انتقال متفاوت است. به عنوان مثال، برای انتقال از آلیس به سوزی، هزینه های آلیس اعمال می شود. در مقابل، از سوزی به آلیس، هزینه های سوزی استفاده می شود.

برای مثال، برای یک کانال بین آلیس و سوزی، ما می توانیم داشته باشیم:

• Alice**: هزینه پایه 1 sat و 1 ppm برای هزینه های متغیر.
• سوزی**: هزینه پایه 0.5 ساتوشی و 10 پی‌پی‌ام برای هزینه‌های متغیر.

برای درک بهتر نحوه کار کردن هزینه ها، بیایید همان شبکه Lightning را مطالعه کنیم، اما حالا با هزینه های مسیریابی زیر:

• کانال Alice - Suzie: هزینه پایه 1 ساتوشی و 1 ppm برای Alice.
• کانال سوزی - کارول: هزینه پایه 0 ساتوشی و 200 ppm برای سوزی.
• کارول - باب ** کانال: هزینه پایه 1 ساتوشی و 1 ppm برای سوزی 2.

برای همان پرداخت 40,000 ساتوشی به باب، آلیس باید کمی بیشتر بفرستد، زیرا هر گره واسطه از آن کسر هزینه خود را کسر خواهد کرد:

• کارول ** 1.04 ساتوشی را در کانال با باب کسر می کند:

$$ f*{\text{کارول-باب}} = \text{هزینه پایه} + \left(\frac{\text{ppm} \times \text{مقدار}}{10^6}\right) $$

$$ f*{\text{کارول-باب}} = 1 + \frac{1 \times 40000}{10^6} = 1 + 0.04 = 1.04 \text{ سات} $$

• سوزی** 8 ساتوشی از کانال با کارول کسر می‌کند:

$$ f*{\text{سوزی-کارول}} = \text{هزینه پایه} + \left(\frac{\text{ppm} \times \text{مقدار}}{10^6}\right) $$

$$ f*{\text{سوزی-کارول}} = 0 + \frac{200 \times 40001.04}{10^6} = 0 + 8.0002 \approx 8 \text{ سات} $$

کل هزینه ها برای این پرداخت در این مسیر بنابراین 9.04 ساتوشی است. بنابراین، آلیس باید 40,009.04 ساتوشی برای اینکه باب دقیقا 40,000 ساتوشی دریافت کند، ارسال کند.

بنابراین نقدینگی به روز شده است:

مسیریابی پیازی

برای مسیریابی پرداخت از فرستنده به گیرنده، شبکه Lightning از روشی به نام "مسیریابی پیازی" استفاده می کند. بر خلاف مسیریابی داده های کلاسیکی، که در آن هر روتر بر اساس مقصد داده ها، جهت آنها را تصمیم می گیرد، مسیریابی پیازی به شکل متفاوتی کار می کند:

• گره ارسال کننده کل مسیر را محاسبه می کند**: به عنوان مثال، آلیس تعیین می کند که پرداخت او باید از طریق سوزی و کارول قبل از رسیدن به باب عبور کند.
• هر گره واسط فقط همسایه نزدیک خود را می‌شناسد **: سوزی فقط می‌داند که او اموال را از آلیس دریافت کرده و باید آنها را به کارول منتقل کند. با این حال، سوزی نمی‌داند که آلیس گره منبع است یا گره واسط، و همچنین او نمی‌داند که کارول گره گیرنده است یا فقط یک گره واسط دیگر. این اصل همچنین برای کارول و تمام گره‌های دیگر در مسیر برقرار است. مسیریابی پیازی بنابراین محرمانگی معاملات را با پنهان کردن هویت فرستنده و گیرنده نهایی حفظ می‌کند.

برای اطمینان از اینکه گره ارسال کننده می تواند مسیر کاملی را تا گیرنده در مسیریابی پیازی محاسبه کند، باید یک نمودار شبکه را حفظ کند تا توپولوژی خود را بشناسد و مسیرهای ممکن را تعیین کند.

از این فصل چه چیزی باید برداشت کنید؟

1. در Lightning، پرداخت‌ها می‌توانند از طریق کانال‌های واسطه بین نودهای غیرمستقیم مسیریابی شوند. هر یک از این نودهای واسطه، انتقال سرمایه را تسهیل می‌کند.

2. گره‌های واسطه برای خدماتشان کمیسیون دریافت می‌کنند، که شامل هزینه‌های ثابت و متغیر است.

3. مسیریابی پیازی به گره ارسال کننده اجازه می‌دهد تا مسیر کامل را بدون اینکه گره‌های واسطه منبع یا مقصد نهایی را بدانند، محاسبه کند.

در این فصل، ما مسیریابی پرداخت در شبکه Lightning را بررسی کردیم. اما سوالی پیش می آید: چه چیزی از گره های واسط جلوگیری می کند که یک پرداخت ورودی را بدون ارسال آن به مقصد بعدی بپذیرند، با هدف رهگیری تراکنش؟ دقیقاً این نقش HTLC ها است که ما در فصل بعدی مطالعه خواهیم کرد.

HTLC - قرارداد زمانی قفل شده با هش

4369b85a-1365-55d8-99e1-509088210116

در این فصل، ما کشف خواهیم کرد که چگونه Lightning اجازه می دهد پرداخت ها از طریق گره های واسطه بدون نیاز به اعتماد به آنها انتقال یابد، با تشکر از HTLC (قراردادهای قفل شده با هش زمانی). این قراردادهای هوشمند اطمینان می دهند که هر گره واسطه فقط در صورتی که پرداخت را به گیرنده نهایی ارسال کند، از کانال خود پول دریافت کند، در غیر این صورت، پرداخت تایید نخواهد شد.

مسئله ای که برای مسیریابی پرداخت بوجود می آید بنابراین اعتماد لازم به گره های واسطه است، و بین گره های واسطه خود. برای توضیح این موضوع، بیایید مثال شبکه Lightning ساده شده ما را با 3 گره و 2 کانال دوباره مرور کنیم:

• آلیس یک کانال با سوزی دارد.
• سوزی یک کانال با باب دارد.

آلیس می‌خواهد 40,000 ساتوشی به باب ارسال کند اما کانال مستقیمی با او ندارد و نمی‌خواهد یکی باز کند. او به دنبال یک مسیر می‌گردد و تصمیم می‌گیرد از طریق نود سوزی برود.

اگر آلیس به سادگی 40،000 ساتوشی را به سوزی ارسال کند در امید اینکه سوزی این مبلغ را به باب منتقل کند، سوزی می تواند این وجوه را برای خود نگه دارد و چیزی به باب منتقل نکند.

برای جلوگیری از این وضعیت، در Lightning، ما از HTLCs (قراردادهای زمانی قفل شده با هش) استفاده می کنیم، که پرداخت به گره واسط را مشروط می کند، به این معنی که Suzie باید شرایط خاصی را برآورده کند تا بتواند به وجوه Alice دسترسی پیدا کند و آنها را به Bob منتقل کند.

چگونه HTLC ها کار می کنند

یک HTLC یک قرارداد ویژه است که بر اساس دو اصل است:

• شرایط دسترسی**: گیرنده باید یک راز را فاش کند تا بتواند پرداختی مربوط به خود را باز کند.
• تاریخ انقضا: اگر پرداخت کاملاً در یک دوره مشخص انجام نشود، آن لغو می شود و وجوه به فرستنده برمی گردد.

این چگونگی کارکرد این فرآیند در مثال ما با آلیس، سوزی، و باب است:

ایجاد رمز: باب یک رمز تصادفی با نام s (پیش تصویر) تولید می کند و با استفاده از تابع هش با نام h، هش آن را که با r نشان داده شده است، محاسبه می کند. ما داریم:

$$ r = h(s) $$

استفاده از یک تابع هش باعث می شود که پیدا کردن s با فقط h(s) غیرممکن شود، اما اگر s فراهم شود، به راحتی می توان تایید کرد که به h(s) متناظر است.

ارسال درخواست پرداخت: باب یک فاکتور به آلیس ارسال می کند و از او درخواست پرداخت می کند. این فاکتور به طور قابل توجهی شامل هش r است.

ارسال پرداخت مشروط: آلیس 40,000 ساتوشی را به صورت HTLC برای سوزی ارسال می کند. شرط دریافت این وجوه برای سوزی این است که او یک رمز s' را که معادله زیر را برآورده می کند، به آلیس ارائه دهد:

$$ h(s') = r $$

انتقال HTLC به گیرنده نهایی: سوزی، برای دریافت 40,000 ساتوشی از آلیس، باید یک HTLC مشابه به ارزش 40,000 ساتوشی را به باب انتقال دهد، که شرط مشابهی دارد، یعنی او باید یک رمز s' را به سوزی بدهد که معادله را برآورده کند:

$$ h(s') = r $$

تأیید توسط رمز s: باب رمز s را برای سوزی ارائه می‌دهد تا 40,000 ساتوشی که در HTLC وعده داده شده بود را دریافت کند. با این رمز، سوزی سپس می‌تواند HTLC آلیس را باز کند و 40,000 ساتوشی را از آلیس بگیرد. سپس پرداخت به درستی به باب هدایت می‌شود.

این فرآیند جلوی نگه داشتن وجوه آلیس توسط سوزی را بدون انجام دادن انتقال به باب می‌گیرد، زیرا او باید پرداخت را به باب ارسال کند تا رمز s را بدست آورد و بنابراین قفل HTLC آلیس را باز کند. عملیات حتی اگر مسیر شامل چندین گره واسطه باشد، همچنان همان است: فقط مسئله تکرار گام‌های سوزی برای هر گره واسطه است. هر گره توسط شرایط HTLC ها محافظت می‌شود، زیرا باز کردن آخرین HTLC توسط گیرنده به طور خودکار باز کردن تمام HTLC های دیگر را در یک زنجیره ایجاد می‌کند.

انقضا و مدیریت HTLC ها در صورت بروز مشکلات

اگر در طی فرآیند پرداخت، یکی از گره‌های واسطه، یا گره گیرنده، پاسخ ندهد، به خصوص در مواقع قطع اینترنت یا برق، پرداخت نمی‌تواند کامل شود، زیرا رمز مورد نیاز برای باز کردن HTLC ها منتقل نمی‌شود. با گرفتن مثال ما با آلیس، سوزی، و باب، این مشکل به عنوان مثال رخ می‌دهد، اگر باب رمز s را به سوزی منتقل نکند. در این حالت، تمام HTLC های بالادستی از مسیر مسدود می‌شوند، و همچنین وجوهی که آن‌ها را تأمین می‌کنند.

برای جلوگیری از این، HTLC ها در Lightning یک تاریخ انقضا دارند که اگر پس از مدت معینی کامل نشوند، امکان حذف HTLC را فراهم می کند. تاریخ انقضا از یک ترتیب خاص پیروی می کند زیرا ابتدا با HTLC نزدیک ترین به گیرنده شروع می شود و سپس به تدریج به صادر کننده تراکنش می رسد. در مثال ما، اگر باب هرگز رمز s را به سوزی ندهد، این ابتدا باعث می شود HTLC سوزی نسبت به باب منقضی شود.

سپس HTLC از آلیس به سوزی.

اگر ترتیب انقضا معکوس می‌شد، آلیس می‌توانست پرداخت خود را قبل از اینکه سوزی بتواند خود را از تقلب احتمالی محافظت کند، بازیابی کند. در واقع، اگر باب برگردد تا HTLC خود را ادعا کند در حالی که آلیس از آن خود را حذف کرده است، سوزی در معرض ضرر قرار خواهد گرفت. این ترتیب آبشاری از انقضای HTLC بنابراین اطمینان می‌دهد که هیچ گره واسطی از زیان‌های ناعادلانه رنج نمی‌برد.

نمایش HTLC ها در معاملات تعهدی

معاملات تعهد، HTLC ها را به گونه ای نمایش می دهند که شرایطی که آنها بر روی Lightning اعمال می کنند، در صورت بسته شدن اجباری کانال در طول عمر یک HTLC، به بیت کوین منتقل شوند. به عنوان یادآوری، معاملات تعهد وضعیت فعلی کانال بین دو کاربر را نمایش می دهد و اجازه بسته شدن اجباری یک طرفه را در صورت وجود مشکلات می دهد. با هر وضعیت جدید کانال، 2 معامله تعهد ایجاد می شود: یکی برای هر طرف. بیایید مثال ما با آلیس، سوزی، و باب را مرور کنیم، اما به طور دقیق تری نگاه کنیم به آنچه در سطح کانال بین آلیس و سوزی رخ می دهد وقتی HTLC ایجاد می شود.

قبل از شروع پرداخت 40،000 سات بین آلیس و باب، آلیس 100،000 سات در کانال خود با سوزی دارد، در حالی که سوزی 30،000 دارد. تراکنش های تعهد آنها به شرح زیر است:

آلیس به تازگی فاکتور باب را دریافت کرده است که به طور قابل توجهی r، هش راز را در بر دارد. بنابراین او می تواند یک HTLC از 40,000 ساتوشی با سوزی بسازد. این HTLC در آخرین معاملات تعهد به عنوان خروجی که "HTLC Out" نامیده می شود در سمت آلیس نمایش داده می شود، زیرا وجوه خروجی هستند، و "HTLC In" در سمت سوزی، زیرا وجوه ورودی هستند.

این خروجی‌های مرتبط با HTLC دقیقاً شرایط یکسانی را دارند، یعنی:

• اگر سوزی بتواند رمز s را فراهم کند، او می تواند فوراً این خروجی را باز کند و آن را به آدرسی که کنترل می کند منتقل کند.
• اگر سوزی s راز را در اختیار نداشته باشد، نمی تواند این خروجی را باز کند و الیس می تواند پس از قفل زمانی آن را باز کند تا آن را به آدرسی که کنترل می کند ارسال کند. قفل زمانی بنابراین به سوزی مدتی را برای واکنش اگر s را بدست آورد می دهد.

این شرایط فقط در صورتی اعمال می شوند که کانال بسته شده باشد (یعنی یک تراکنش تعهدی در زنجیره بلاک منتشر شده است) در حالی که HTLC هنوز در Lightning فعال است، به این معنی که پرداخت بین Alice و Bob هنوز نهایی نشده است و HTLC ها هنوز منقضی نشده اند. با تشکر از این شرایط، Suzie می تواند 40,000 ساتوشی از HTLC که به او بدهکار است را با ارائه s بازیابی کند. در غیر این صورت، Alice پس از انقضای timelock، وجوه را بازیابی می کند، زیرا اگر Suzie s را نداند، به این معنی است که او 40,000 ساتوشی را به Bob منتقل نکرده است و بنابراین، وجوه Alice به او بدهکار نیست.

علاوه بر این، اگر کانال در حالی که چندین HTLC در انتظار است بسته شود، به اندازه HTLC های در حال اجرا خروجی اضافی وجود خواهد داشت.

اگر کانال بسته نشده باشد، پس از انقضا یا موفقیت پرداخت Lightning، تراکنش‌های تعهد جدیدی ایجاد می‌شوند تا وضعیت جدید و حالا پایدار کانال را نشان دهند، یعنی بدون هیچ HTLC در انتظار. بنابراین خروجی‌های مرتبط با HTLC ها می‌توانند از تراکنش‌های تعهد حذف شوند.

در نهایت، در صورت بسته شدن کانال همکاری در حالی که یک HTLC فعال است، آلیس و سوزی پذیرش پرداخت های جدید را متوقف می کنند و منتظر حل یا انقضای HTLC های در حال اجرا می مانند. این امر به آنها امکان می دهد تا یک معامله بسته شدن سبک تر را منتشر کنند، بدون خروجی های مرتبط با HTLC ها، بدین ترتیب کاهش هزینه ها و جلوگیری از انتظار برای یک تایملاک احتمالی.

از این فصل چه چیزی باید برداشت کنید؟

HTLC ها امکان مسیریابی پرداخت های Lightning را از طریق چندین گره بدون نیاز به اعتماد به آنها فراهم می کند. در اینجا نکات کلیدی را باید به یاد داشت:

1. HTLC ها با استفاده از یک رمز (پیش تصویر) و زمان انقضا، امنیت پرداخت ها را تضمین می کنند.

2. رفع یا انقضای HTLC ها به ترتیب خاصی پیروی می کند: سپس از مقصد به سمت منبع، به منظور حفاظت از هر گره.

3. تا زمانی که یک HTLC نه حل شده و نه منقضی شده است، آن به عنوان خروجی در آخرین معاملات تعهدی حفظ می شود.

در فصل بعد، ما خواهیم کشف کنیم که چگونه یک گره که یک تراکنش رعد و برق را صادر می کند، مسیرها را برای پرداخت خود پیدا و انتخاب می کند تا به گره گیرنده برسد.

یافتن راه خود

7e2ae959-c2a1-512e-b5d6-8fd962e819da

در فصل‌های قبلی، ما دیدیم چگونه از کانال‌های گره‌های دیگر برای مسیریابی پرداخت‌ها و دستیابی به یک گره بدون اتصال مستقیم به آن از طریق یک کانال استفاده کنیم. ما همچنین بحث کردیم چگونه امنیت انتقال را بدون اعتماد به گره‌های واسطه تضمین کنیم. در این فصل، ما تمرکز خود را بر روی پیدا کردن بهترین مسیر ممکن برای رسیدن به یک گره هدف خواهیم گذاشت.

مشکل مسیریابی در رعد و برق

همانطور که دیدیم، در Lightning، نود ارسال کننده پرداخت باید مسیر کامل را تا گیرنده محاسبه کند، زیرا ما از یک سیستم مسیریابی پیازی استفاده می کنیم. نودهای واسطه نه نقطه شروع و نه مقصد نهایی را نمی دانند. آنها فقط می دانند که پرداخت از کجا می آید و به کدام نود باید آن را بعدی منتقل کنند. این بدان معناست که نود ارسال کننده باید یک توپولوژی محلی پویا از شبکه را حفظ کند، با نودهای Lightning موجود و کانال های بین هر کدام، با توجه به افتتاحیات، بسته شدن ها، و بروزرسانی های وضعیت.

حتی با این توپولوژی شبکه Lightning، اطلاعات ضروری برای مسیریابی وجود دارد که برای گره ارسال کننده در دسترس نیست، که این توزیع دقیق سرمایه در کانال ها در هر لحظه خاص است. در واقع، هر کانال فقط ظرفیت کلی خود را نمایش می دهد، اما توزیع داخلی وجوه فقط به دو گره شرکت کننده شناخته شده است. این مسائل چالش هایی برای مسیریابی کارآمد ایجاد می کند، زیرا موفقیت پرداخت به طور قابل توجهی به این بستگی دارد که آیا مقدار آن کمتر از کمترین سرمایه در مسیر انتخاب شده است یا خیر. با این حال، سرمایه ها همه برای گره ارسال کننده قابل مشاهده نیستند.

به‌روزرسانی نقشه شبکه

برای به روز نگه داشتن نقشه شبکه خود، گره ها به طور منظم پیام ها را از طریق الگوریتمی به نام "گوسیپ" با یکدیگر تبادل می کنند. این یک الگوریتم توزیع شده است که برای انتشار اطلاعات به صورت وبایی به تمام گره های شبکه استفاده می شود، که این امکان را برای تبادل و همزمان سازی وضعیت جهانی کانال ها در چند چرخه ارتباطی فراهم می کند. هر گره اطلاعات را به یک یا چند همسایه که به صورت تصادفی یا غیر تصادفی انتخاب شده اند، منتشر می کند، این همسایه ها به نوبه خود اطلاعات را به سایر همسایه ها منتشر می کنند و این فرایند ادامه می یابد تا یک وضعیت همزمان سازی شده در سطح جهانی به دست آید.

2 پیام اصلی که بین گره های Lightning مبادله می شوند به شرح زیر است:

• "اعلانات کانال": پیام‌هایی که افتتاح یک کانال جدید را اعلام می‌کنند.
• "بروزرسانی کانال": پیام های بروزرسانی در مورد وضعیت یک کانال، به خصوص در مورد تکامل هزینه ها (اما نه در مورد توزیع سرمایه).

گره‌های برق نیز برای تشخیص معاملات بسته شدن کانال، بلاکچین بیت کوین را نظارت می‌کنند. سپس کانال بسته شده از نقشه حذف می‌شود زیرا دیگر نمی‌توان از آن برای مسیریابی پرداخت‌های ما استفاده کرد.

مسیریابی پرداخت

بیایید مثالی از یک شبکه کوچک Lightning با 7 گره را در نظر بگیریم: Alice، Bob، 1، 2، 3، 4 و 5. تصور کنید که Alice می خواهد یک پرداخت را به Bob ارسال کند اما باید از طریق گره های واسطه برود.

در این کانال ها توزیع واقعی اموال به شرح زیر است:

• کانال بین آلیس و 1**: 250،000 ساتوشی در سمت آلیس، 80،000 در سمت 1 (ظرفیت کلی 330،000 ساتوشی).
• کانال بین 1 و 2**: 300،000 سات بر روی سمت 1، 200،000 بر روی سمت 2 (ظرفیت کلی 500،000 سات).
• کانال بین 2 و 3**: 50,000 ساتوشی در سمت 2، 60,000 در سمت 3 (ظرفیت کلی 110,000 ساتوشی).
• کانال بین 2 و 5**: 90,000 سات بر روی طرف 2، 160,000 بر روی طرف 5 (ظرفیت کلی 250,000 سات).
• کانال بین 2 و 4**: 180,000 سات بر روی طرف 2، 110,000 بر روی طرف 4 (ظرفیت کلی 290,000 سات).
• کانال بین 4 و 5 **: 200،000 سات بر روی سمت 4، 10،000 بر روی سمت 5 (ظرفیت کلی 210،000 سات).
• کانال بین 3 و باب**: 50,000 سات بر روی سمت 3، 250,000 سات بر روی سمت باب (ظرفیت کلی 300,000 سات).
• کانال بین 5 و Bob**: 260،000 sats در سمت 5، 100،000 در سمت Bob (ظرفیت کلی 360،000 sats).

برای انجام پرداخت 100،000 ساتوشی از آلیس به باب، گزینه‌های مسیریابی محدود به میزان نقدینگی موجود در هر کانال است. مسیر بهینه برای آلیس، بر اساس توزیع نقدینگی شناخته شده، می‌تواند توالی آلیس → 1 → 2 → 4 → 5 → باب باشد:

اما از آنجا که الیس دقیقاً توزیع وجوه در هر کانال را نمی‌داند، او باید به صورت احتمالی مسیر بهینه را تخمین بزند، با توجه به معیارهای زیر:

• احتمال موفقیت**: یک کانال با ظرفیت کل بیشتر احتمالاً دارای سیالیت کافی است. به عنوان مثال، کانال بین گره 2 و گره 3 دارای ظرفیت کل 110,000 سات است، بنابراین احتمال پیدا کردن 100,000 سات یا بیشتر در سمت گره 2 کم است، اگرچه همچنان ممکن است.
• هزینه های تراکنش**: در انتخاب بهترین مسیر، گره ارسال کننده همچنین هزینه های اعمال شده توسط هر گره میانی را در نظر می گیرد و سعی می کند کل هزینه های مسیریابی را به حداقل برساند.
• انقضای HTLC ها**: برای جلوگیری از پرداخت های مسدود، زمان انقضای HTLC ها نیز یک پارامتر است که باید در نظر گرفت.
• تعداد گره‌های میانی**: در نهایت، به طور کلی، گره ارسال کننده سعی خواهد کرد مسیری با کمترین تعداد ممکن گره‌ها پیدا کند تا خطر شکست را کاهش دهد و هزینه‌های معامله Lightning را محدود کند.

با تجزیه و تحلیل این معیارها، گره ارسال کننده می تواند مسیرهای احتمالی را آزمایش کند و تلاش کند آنها را بهینه سازی کند. در مثال ما، الیس می تواند بهترین مسیرها را به شرح زیر رتبه بندی کند:

1. Alice → 1 → 2 → 5 → Bob، زیرا کوتاهترین مسیر با بیشترین ظرفیت است.

2. آلیس → 1 → 2 → 4 → 5 → باب، زیرا این مسیر ظرفیت خوبی ارائه می دهد، با اینکه از اولی بلندتر است.

3. Alice → 1 → 2 → 3 → Bob، زیرا این مسیر شامل کانال 2 → 3 است که ظرفیت بسیار محدودی دارد، اما همچنان قابل استفاده است.

اجرای پرداخت

آلیس تصمیم می‌گیرد مسیر اول خود را آزمایش کند («آلیس → 1 → 2 → 5 → باب»). بنابراین او یک HTLC به ارزش 100,000 ساتوشی را به نود 1 می‌فرستد. این نود بررسی می‌کند که آیا با نود 2 به اندازه کافی سرمایه دارد و انتقال را ادامه می‌دهد. سپس نود 2 HTLC را از نود 1 دریافت می‌کند، اما متوجه می‌شود که در کانال خود با نود 5 به اندازه کافی سرمایه برای انتقال پرداخت 100,000 ساتوشی ندارد. سپس پیام خطا را به نود 1 می‌فرستد، که آن را به آلیس منتقل می‌کند. این مسیر شکست خورده است.

سپس آلیس تلاش می کند پرداخت خود را از طریق مسیر دوم خود (آلیس → 1 → 2 → 4 → 5 → باب) مسیریابی کند. او یک HTLC به ارزش 100,000 sats را به نود 1 می فرستد، که آن را به نود 2 منتقل می کند، سپس به نود 4، به نود 5 و در نهایت به باب. این بار، سیالیت کافی است و مسیر کار می کند. هر نود HTLC خود را با استفاده از preimage ارائه شده توسط باب (رمز s) باز می کند، که این امکان را فراهم می کند تا پرداخت آلیس به باب با موفقیت نهایی شود.

جستجو برای یک مسیر به شرح زیر انجام می‌شود: گره ارسال کننده با شناسایی بهترین مسیرهای ممکن شروع می‌کند، سپس تلاش می‌کند تا پرداخت‌ها را به ترتیب انجام دهد تا یک مسیر کاربردی پیدا شود.

شایان ذکر است که باب می‌تواند به آلیس اطلاعاتی را در فاکتور ارائه دهد تا مسیریابی را آسان‌تر کند. به عنوان مثال، او می‌تواند کانال‌های نزدیک با ظرفیت کافی را نشان دهد یا وجود کانال‌های خصوصی را فاش کند. این نشانه‌ها به آلیس اجازه می‌دهند تا از مسیرهایی با احتمال کم موفقیت جلوگیری کند و ابتدا مسیرهایی را که باب توصیه کرده است، امتحان کند.

از این فصل چه چیزی باید برداشت کنید؟

1. گره‌ها با استفاده از اعلامیه‌ها و نظارت بر بسته شدن کانال‌ها در بلاکچین بیتکوین، نقشه توپولوژی شبکه را حفظ می‌کنند.

۲. جستجو برای یک مسیر بهینه برای پرداخت همچنان احتمالی است و بستگی به بسیاری از معیارها دارد.

3. باب می‌تواند نشانه‌هایی در فاکتور ارائه دهد تا مسیریابی آلیس را هدایت کند و او را از آزمایش مسیرهای نامطمئن نجات دهد.

در فصل زیر، ما به طور خاص عملکرد فاکتورها را مطالعه خواهیم کرد، علاوه بر برخی از ابزارهای دیگری که در شبکه Lightning استفاده می شوند.

ابزارهای شبکه ی رعد و برق

74d6c334-ec5d-55d9-8598-f05694703bf6

فاکتور، LNURL، و Keysend

e34c7ecd-2327-52e3-b61e-c837d9e5e8b0

در این فصل، ما به عملکرد صورتحساب های Lightning نگاه عمیق تری خواهیم انداخت، یعنی درخواست های پرداختی که توسط گره گیرنده به گره فرستنده ارسال می شوند. هدف درک چگونگی پرداخت و دریافت پرداختی ها در Lightning است. ما همچنین در مورد 2 جایگزین برای صورتحساب های کلاسیک یعنی LNURL و Keysend بحث خواهیم کرد.

ساختار فاکتورهای رعد و برق

همانطور که در فصل مربوط به HTLC ها توضیح داده شده است، هر پرداخت با تولید یک فاکتور توسط گیرنده شروع می شود. این فاکتور سپس برای شروع پرداخت به پرداخت کننده منتقل می شود (از طریق یک کد QR یا با کپی-چسباندن). یک فاکتور شامل دو بخش اصلی است:

1. بخش قابل خواندن توسط انسان: این بخش شامل متادیتای قابل مشاهده واضح برای بهبود تجربه کاربر است.

2. بار مفید: این بخش شامل اطلاعاتی است که برای ماشین‌ها در پردازش پرداخت قصد شده است.

ساختار معمول یک فاکتور با شناسه ln برای "Lightning" شروع می شود، سپس bc برای Bitcoin، سپس مقدار فاکتور. جداکننده 1 بخش قابل خواندن توسط انسان را از بخش داده (بار) تشخیص می دهد.

بیایید فاکتور زیر را به عنوان مثال در نظر بگیریم:

lnbc100u1p0x7x7dpp5l7r9y50wrzz0lwnsqgxdks50lxtwkl0mhd9lslr4rcgdtt2n6lssp5l3pkhdx0cmc9gfsqvw5xjhph84my2frzjqxqyz5vq9qsp5k4mkzv5jd8u5n89d2yc50x7ptkl0zprx0dfjh3km7g0x98g70hsqq7sqqqgqqyqqqqlgqqvnv2k5ehwnylq3rhpd9g2y0sq9ujyxsqqypjqqyqqqqqqqqqqqsqqqqq9qsq3vql5f6e45xztgj7y6xw6ghrcz3vmh8msrz8myvhsarxg42ce9yyn53lgnryx0m6qqld8fql

ما می‌توانیم همین حالا آن را به 2 بخش تقسیم کنیم. اول، بخش قابل خواندن برای انسان وجود دارد:

lnbc100u

سپس قسمتی که برای بار مفید در نظر گرفته شده است:

p0x7x7dpp5l7r9y50wrzz0lwnsqgxdks50lxtwkl0mhd9lslr4rcgdtt2n6lssp5l3pkhdx0cmc9gfsqvw5xjhph84my2frzjqxqyz5vq9qsp5k4mkzv5jd8u5n89d2yc50x7ptkl0zprx0dfjh3km7g0x98g70hsqq7sqqqgqqyqqqqlgqqvnv2k5ehwnylq3rhpd9g2y0sq9ujyxsqqypjqqyqqqqqqqqqqqsqqqqq9qsq3vql5f6e45xztgj7y6xw6ghrcz3vmh8msrz8myvhsarxg42ce9yyn53lgnryx0m6qqld8fql

دو بخش توسط 1 از هم جدا شده‌اند. این جداکننده به جای یک کاراکتر خاص انتخاب شده تا امکان کپی-چسباندن آسان کل فاکتور را با دوبار کلیک کردن فراهم کند.

در بخش اول، می‌توانیم ببینیم که:

• ln نشان می‌دهد که این یک تراکنش Lightning است.
• bc نشان می‌دهد که شبکه Lightning روی بلاکچین بیتکوین است (و نه روی تست‌نت یا لایتکوین).
• 100u مقدار فاکتور را نشان می‌دهد، که به میکروساتوشی بیان می‌شود (u به معنی "میکرو")، که در اینجا برابر با 10,000 سات است.

برای تعیین مقدار پرداخت، آن به زیر واحدهای بیت کوین بیان می شود. در اینجا واحدهای استفاده شده عبارتند از:

• میلی‌بیتکوین (که با m نشان داده می‌شود):** نمایانگر یک هزارم بیتکوین است.

$$ 1 , \text{mBTC} = 10^{-3} , \text{BTC} = 10^5 , \text{satoshis} $$

• میکروبیتکوین (که با u نمایش داده می‌شود):** گاهی اوقات به آن "بیت" هم می‌گویند، نمایانگر یک میلیونم بیتکوین است.

$$ 1 , \mu\text{BTC} = 10^{-6} , \text{BTC} = 100 , \text{satoshis} $$

• نانوبیتکوین (که با n نمایش داده می‌شود):** یک میلیاردم یک بیتکوین را نمایش می‌دهد.

$$ 1 , \text{nBTC} = 10^{-9} , \text{BTC} = 0.1 , \text{satoshis} $$

• پیکوبیتکوین (که با p نشان داده می‌شود):** نمایانگر یک تریلیونم یک بیتکوین است.

$$ 1 , \text{pBTC} = 10^{-12} , \text{BTC} = 0.0001 , \text{satoshis} $$

بار مفید یک فاکتور

بار مفید یک فاکتور شامل چندین قطعه اطلاعات ضروری برای پردازش پرداخت است:

• برچسب زمان: ** لحظه ایجاد فاکتور، بیان شده در برچسب زمان یونیکس (تعداد ثانیه هایی که از 1 ژانویه 1970 گذشته است).
• هش کردن رمز**: همانطور که در بخش HTLC ها دیدیم، نود دریافت کننده باید نود ارسال کننده را با هش پیش تصویر مجهز کند. این در HTLC ها برای امن کردن معامله استفاده می شود. ما به آن به عنوان "r" اشاره کردیم.
• رمز پرداخت**: رمز دیگری توسط گیرنده تولید می‌شود، اما این بار به گره ارسال کننده منتقل می‌شود. این در مسیریابی پیازی برای جلوگیری از حدس زدن گره‌های میانی که آیا گره بعدی گیرنده نهایی است یا خیر، استفاده می‌شود. این بنابراین یک نوع محرمانگی برای گیرنده در مقابل گره میانی آخر در مسیر را حفظ می‌کند.
• کلید عمومی گیرنده**: به پرداخت کننده نشان می‌دهد که شناسه فردی که باید به او پرداخت شود.
• مدت زمان انقضا**: حداکثر زمان برای پرداخت فاکتور (به طور پیش فرض 1 ساعت).
• راهنمایی های مسیریابی: اطلاعات اضافی ارائه شده توسط گیرنده برای کمک به فرستنده در بهینه سازی مسیر پرداخت.
• امضا**: تضمین کننده یکپارچگی فاکتور با تأیید همه اطلاعات است.

فاکتورها سپس به فرمت bech32 کدگذاری می‌شوند، همان فرمتی که برای آدرس‌های بیتکوین SegWit استفاده می‌شود (فرمتی که با bc1 شروع می‌شود).

برداشت LNURL

در یک معامله سنتی، مانند خرید از فروشگاه، فاکتور برای مجموع مبلغ پرداختی تولید می شود. هنگامی که فاکتور ارائه می شود (به صورت یک کد QR یا رشته ای از کاراکترها)، مشتری می تواند آن را اسکن کند و معامله را نهایی کند. سپس پرداخت، به فرآیند سنتی که در بخش قبلی مطالعه کردیم، می پیوندد. با این حال، این فرآیند گاهی اوقات می تواند برای تجربه کاربر بسیار سنگین باشد، زیرا این نیازمند ارسال اطلاعات از گیرنده به فرستنده از طریق فاکتور است.

برای موقعیت های خاصی، مانند برداشت بیت کوین از یک سرویس آنلاین، فرآیند سنتی بسیار دشوار است. در چنین مواردی، راه حل برداشت LNURL این فرآیند را با نمایش یک کد QR که کیف پول گیرنده آن را اسکن می کند تا به طور خودکار فاکتور را ایجاد کند، ساده می کند. سپس سرویس فاکتور را پرداخت می کند و کاربر فقط یک برداشت فوری را می بیند.

LNURL یک پروتکل ارتباطی است که مجموعه ای از قابلیت ها را مشخص می کند که برای ساده سازی تعاملات بین گره های Lightning و مشتریان، همچنین برنامه های کاربردی ثالث طراحی شده است. بنابراین، LNURL برداشت، همانطور که ما به تازگی دیدیم، فقط یک نمونه از سایر قابلیت ها است.

این پروتکل بر اساس HTTP است و اجازه ایجاد پیوندهایی برای عملیات های مختلف مانند درخواست پرداخت، درخواست برداشت یا سایر قابلیت هایی که تجربه کاربر را ارتقا می دهد، را می دهد. هر LNURL یک URL کدگذاری شده bech32 با پیشوند lnurl است که پس از اسکن شدن، مجموعه ای از عملیات های خودکار را در کیف پول Lightning فعال می کند.

برای مثال، ویژگی LNURL-withdraw (LUD-03) امکان برداشت وجوه از یک سرویس را با اسکن کردن یک کد QR، بدون نیاز به تولید دستی مانویس فاکتور، فراهم می کند. به طور مشابه، LNURL-auth (LUD-04) امکان ورود به سرویس های آنلاین را با استفاده از یک کلید خصوصی در کیف پول Lightning خود به جای یک رمز عبور فراهم می کند.

ارسال یک پرداخت Lightning بدون فاکتور: Keysend

یک مورد جالب دیگر انتقال وجه بدون دریافت فاکتور قبلی است که به "Keysend" شناخته می شود. این پروتکل اجازه می دهد تا با افزودن یک پیش تصویر در داده های پرداخت رمزگذاری شده، وجه را ارسال کنید، که فقط توسط گیرنده قابل دسترسی است. این پیش تصویر به گیرنده اجازه می دهد تا HTLC را باز کند، بنابراین وجه را بدون تولید فاکتور قبلی بازیابی می کند.

برای ساده سازی، در این پروتکل، فرستنده است که رمز مورد استفاده در HTLC ها را تولید می کند، بجای گیرنده. عملاً، این امکان را به فرستنده می دهد تا پرداختی را انجام دهد بدون اینکه نیاز باشد قبلاً با گیرنده تعامل داشته باشد.

از این فصل چه چیزی باید برداشت کنید؟

1. یک فاکتور رعد و برق درخواست پرداختی است که از بخش قابل خواندن برای انسان و بخش داده ماشین تشکیل شده است.

2. فاکتور با bech32 رمزگذاری شده است، با یک جداکننده 1 برای تسهیل در کپی کردن و یک بخش داده که شامل تمام اطلاعات لازم برای پردازش پرداخت است.

3. روندهای پرداخت دیگری در Lightning وجود دارد، به خصوص LNURL-Withdraw برای تسهیل برداشت ها، و Keysend برای انتقالات مستقیم بدون فاکتور.

در فصل زیر، ما خواهیم دید که چگونه یک عامل گره می تواند سیالیت در کانال های خود را مدیریت کند، تا هرگز مسدود نشود و همیشه بتواند پرداخت ها را در شبکه Lightning ارسال و دریافت کند.

مدیریت سیالیت خود

cc76d0c4-d958-57f5-84bf-177e21393f48

در این فصل، ما استراتژی های موثر برای مدیریت بهینه سیالیت در شبکه Lightning را بررسی خواهیم کرد. مدیریت سیالیت بسته به نوع کاربر و زمینه متفاوت است. ما به اصول اصلی و تکنیک های موجود نگاه خواهیم کرد تا بهتر بفهمیم چگونه این مدیریت را بهینه کنیم.

نیازهای نقدینگی

سه پروفایل کاربری اصلی در Lightning وجود دارد، هر کدام با نیازهای خاصی به نقدینگی:

1. پرداخت کننده: این فردی است که پرداخت ها را انجام می دهد. اونها برای انتقال وجوه به کاربران دیگر به نقدینگی خروجی نیاز دارند. به عنوان مثال، این می تواند یک مصرف کننده باشد.

2. فروشنده (یا دریافت کننده پرداخت): این فردی است که پرداخت ها را دریافت می کند. او نیاز به نقدینگی ورودی دارد تا بتواند پرداخت ها را به نود خود بپذیرد. به عنوان مثال، این می تواند یک کسب و کار یا یک فروشگاه آنلاین باشد.

3. روتر: یک گره واسطه، که اغلب در مسیریابی پرداخت ها تخصص دارد، باید سیالیت خود را در هر کانال بهینه کند تا بتواند بیشترین پرداخت ها را مسیریابی کند و کارمزد بگیرد.

این پروفایل ها آشکارا ثابت نیستند؛ کاربر می تواند بسته به معاملات بین پرداخت کننده و دریافت کننده تغییر کند. به عنوان مثال، باب می تواند حقوق خود را از کارفرمای خود در Lightning دریافت کند، که او را در موقعیت "فروشنده" قرار می دهد که به سرمایه ورودی نیاز دارد. در نتیجه، اگر او بخواهد حقوق خود را برای خرید غذا استفاده کند، او "پرداخت کننده" می شود و سپس باید سرمایه خروجی داشته باشد.

برای درک بهتر، بیایید مثالی از یک شبکه ساده شامل سه گره بگیریم: خریدار (آلیس)، روتر (سوزی)، و فروشنده (باب).

تصور کنید که خریدار می خواهد 30،000 ساتوشی را به فروشنده ارسال کند و این پرداخت از طریق گره روتر انجام می شود. هر طرف سپس باید حداقل مقداری از نقدینگی را در جهت پرداخت داشته باشد:

• پرداخت کننده باید حداقل 30،000 ساتوشی در سمت خود از کانال با روتر داشته باشد.
• فروشنده باید یک کانال داشته باشد که 30,000 ساتوشی در طرف مقابل قرار دارد تا بتواند آنها را دریافت کند.
• راوتر باید 30,000 ساتوشی در سمت پرداخت کننده در کانال خود داشته باشد، و همچنین 30,000 ساتوشی در سمت خود در کانال با فروشنده، تا بتواند پرداخت را مسیریابی کند.

استراتژی‌های مدیریت نقدینگی

پرداخت کنندگان باید اطمینان حاصل کنند که به اندازه کافی نقدینگی در سمت خود از کانال ها حفظ می کنند تا نقدینگی خروجی را تضمین کنند. این کار نسبتاً ساده است، زیرا کافی است کانال های جدید Lightning را باز کنید تا این نقدینگی را داشته باشید. در واقع، سرمایه اولیه ای که در multisig on-chain قفل شده است، کاملاً در سمت پرداخت کننده در کانال Lightning در ابتدا است. بنابراین ظرفیت پرداخت تا زمانی که کانال ها با سرمایه کافی باز شوند، تضمین شده است. وقتی نقدینگی خروجی از بین می رود، کافی است کانال های جدیدی باز کنید.

از طرف دیگر، برای فروشنده، کار پیچیده تر است. برای اینکه بتوانند پرداخت ها را دریافت کنند، باید در طرف مقابل کانال های خود نقدینگی داشته باشند. بنابراین، باز کردن یک کانال کافی نیست: آنها همچنین باید یک پرداخت را در این کانال انجام دهند تا نقدینگی را به طرف دیگر حرکت دهند قبل از اینکه خود بتوانند پرداخت ها را دریافت کنند. برای برخی از پروفایل های کاربری Lightning مانند تجار، ناسازگاری واضحی بین آنچه نود آنها می فرستد و آنچه دریافت می کند وجود دارد، زیرا هدف اصلی یک کسب و کار در اولویت، جمع آوری بیشتر از هزینه ها است، تا سودی را ایجاد کند. خوشبختانه، برای این کاربران با نیازهای خاص نقدینگی ورودی، چندین راه حل وجود دارد:

• کانال های جذاب**: بازرگان از یک مزیت به دلیل حجم پرداخت های ورودی مورد انتظار در نود خود بهره می برد. با توجه به این موضوع، آنها می توانند سعی کنند نودهای مسیریابی را که به دنبال درآمد از هزینه های معامله هستند و ممکن است کانال هایی را به سمت آنها باز کنند، در امید به مسیریابی پرداخت های خود و جمع آوری هزینه های مرتبط، جذب کنند.
• حرکت نقدینگی**: فروشنده همچنین می‌تواند یک کانال باز کند و با انجام پرداخت‌های خیالی به گره دیگر، بخشی از وجوه را به طرف مقابل منتقل کند، که این پول را به روش دیگری برمی‌گرداند. در بخش بعدی خواهیم دید چگونه این عملیات را انجام دهیم.
• درو باز شکل مثلثی: برای گره هایی که می خواهند به صورت همکاری کانال ها را باز کنند، پلتفرم هایی وجود دارد، که به هر یک اجازه می دهد از سیالیت ورودی و خروجی فوری بهره مند شوند. به عنوان مثال، LightningNetwork+ این سرویس را ارائه می دهد. اگر Alice، Bob و Suzie می خواهند یک کانال با 100،000 sats باز کنند، آنها می توانند در این پلتفرم توافق کنند که Alice یک کانال به سمت Bob باز کند، Bob به سمت Suzie و Suzie به سمت Alice. به این ترتیب، هر یک 100،000 sats از سیالیت خروجی و 100،000 sats از سیالیت ورودی دارند، در حالی که فقط 100،000 sats را قفل کرده اند.

• کانال های خرید**: خدمات اجاره کانال های Lightning نیز وجود دارد تا بتوانید سرمایه ورودی را دریافت کنید، مانند Bitrefill Thor یا Lightning Labs Pool. به عنوان مثال، آلیس می تواند یک کانال یک میلیون ساتوشی را به سمت نود خود بخرد تا بتواند پرداخت ها را دریافت کند.

در نهایت، برای روترها، که هدف آنها بیشینه کردن تعداد پرداخت های پردازش شده و کسب حقوق است، باید:

• کانال‌های خوب تامین مالی شده با گره‌های استراتژیک را باز کنید.
• به طور منظم توزیع وجوه را در کانال‌ها بر اساس نیازهای شبکه تنظیم کنید.

خدمات حلقه خروج

سرویس Loop Out، که توسط Lightning Labs ارائه می‌شود، امکان انتقال سرمایه به طرف مقابل کانال را در حالی که وجوه را در بلاکچین بیت کوین بازیابی می‌کند، فراهم می‌کند. به عنوان مثال، آلیس 1 میلیون ساتوشی را از طریق Lightning به یک نود حلقه ارسال می‌کند، که سپس این وجوه را به او در بیت کوین‌های on-chain برمی‌گرداند. این کار باعث می‌شود کانال او با 1 میلیون ساتوشی در هر طرف متعادل شود، بهینه‌سازی ظرفیت او برای دریافت پرداخت‌ها.

بنابراین، این سرویس امکان ورود سرمایه را فراهم می‌کند در حالی که بیت کوین‌های فرد را در زنجیره برمی‌گرداند، که به محدود کردن ایستادگی نقدی که برای پذیرش پرداخت‌ها با Lightning لازم است، کمک می‌کند.

از این فصل چه چیزی باید برداشت کنید؟

• برای ارسال پرداخت ها در Lightning، باید به اندازه کافی نقدینگی در کانال های خود داشته باشید. برای افزایش این ظرفیت ارسال، کافی است کانال های جدیدی را باز کنید.
• برای دریافت پرداخت ها، شما باید در طرف مقابل کانال های خود، نقدینگی داشته باشید. افزایش این ظرفیت دریافتی پیچیده تر است، زیرا نیازمند این است که دیگران کانال ها را به سمت شما باز کنند، یا پرداخت های (واقعی یا خیالی) انجام دهند تا نقدینگی را به طرف دیگر حرکت دهند.
• حفظ سیالیت در جایی که مورد نیاز است، بسته به استفاده از کانال‌ها، ممکن است چالش بیشتری ایجاد کند. به همین دلیل ابزارها و خدمات وجود دارند تا به تعادل بخشیدن به کانال‌ها به شکل مورد نظر کمک کنند.

در فصل بعدی، پیشنهاد می‌کنم که مفاهیم مهم‌ترین این آموزش را مرور کنم.

برو جلوتر

6bbf107d-a224-5916-9f0c-2b4d30dd0b17

نتیجه آموزش

a65a571c-561b-5e1c-87bf-494644653c22

در این فصل نهایی که نشان‌دهنده پایان دوره آموزشی LNP201 است، پیشنهاد می‌کنم مفاهیم مهمی که با هم بررسی کرده‌ایم را مرور کنیم.

هدف از این آموزش ارائه یک درک جامع و فنی از شبکه Lightning بود. ما کشف کردیم که چگونه شبکه Lightning برای انجام معاملات خارج از زنجیره بر بلاکچین بیت کوین تکیه می کند، در حالی که ویژگی های اساسی بیت کوین، به خصوص عدم نیاز به اعتماد به گره های دیگر را حفظ می کند.

کانال های پرداخت

در فصل‌های اولیه، ما بررسی کردیم که چگونه دو طرف، با باز کردن یک کانال پرداخت، می‌توانند معاملات خود را خارج از بلاکچین بیت کوین انجام دهند. در اینجا مراحل مورد بررسی عبارتند از:

1. افتتاح کانال: ایجاد کانال از طریق یک معامله بیت کوین انجام می شود که وجوه را در یک آدرس چند امضایی 2/2 قفل می کند. این سپرده نمایانگر کانال رعد و برق در بلاکچین است.

2. Transactions in the Channel: In this channel, it is then possible to carry out numerous transactions without having to publish them on the blockchain. Each Lightning transaction creates a new state of the channel reflected in a commitment transaction.

3. تأمین و بستن: شرکت کنندگان با تبادل کلیدهای لغو، به وضعیت جدید کانال تعهد می‌کنند تا دارایی‌ها را امن کنند و از هر گونه تقلب جلوگیری کنند. هر دو طرف می‌توانند با ایجاد یک معامله جدید در بلاکچین بیتکوین، کانال را به صورت همکاری ببندند، یا به عنوان یک راه آخر از طریق بستن اجباری. این گزینه آخر، با وجود اینکه کمتر کارآمد است زیرا طولانی‌تر است و گاهی اوقات در مورد هزینه‌ها بد ارزیابی می‌شود، هنوز هم امکان بازیابی دارایی‌ها را فراهم می‌کند. در صورت تقلب، قربانی می‌تواند تقلبگر را با بازیابی تمام دارایی‌ها از کانال در بلاکچین مجازات کند.

شبکه کانال ها

پس از مطالعه کردن کانال‌های جداگانه، تحلیل ما را به شبکه کانال‌ها گسترش دادیم:

• مسیریابی: وقتی دو طرف مستقیماً از طریق یک کانال به هم متصل نیستند، شبکه اجازه می دهد تا از طریق گره های واسطه مسیریابی شود. سپس پرداخت ها از یک گره به گره دیگر منتقل می شوند.

• HTLC ها: پرداخت هایی که از طریق گره های واسطه انتقال می یابند، توسط "قراردادهای قفل زمانی هش" (HTLC) ایمن شده اند، که اجازه می دهد تا وجوه تا زمانی که پرداخت از ابتدا تا انتها انجام شود، قفل شوند.

• مسیریابی پیازی: برای اطمینان از محرمانگی پرداخت، مسیریابی پیازی مقصد نهایی را برای گره‌های واسطه مخفی می‌کند. بنابراین گره فرستنده باید تمام مسیر را محاسبه کند، اما در عدم وجود اطلاعات کامل درباره ذخیره کانال‌ها، از طریق آزمایش‌های متوالی برای مسیریابی پرداخت اقدام می‌کند.

مدیریت نقدینگی

ما دیده ایم که مدیریت نقدینگی در Lightning یک چالش است تا جریان روان پرداخت ها را تضمین کند. ارسال پرداخت ها نسبتاً ساده است: فقط نیاز به باز کردن یک کانال است. با این حال، دریافت پرداخت ها نیاز به داشتن نقدینگی در طرف مقابل کانال های فرد دارد. در اینجا برخی از استراتژی های مورد بحث قرار گرفته اند:

• کانال‌های جذب**: با تشویق سایر گره‌ها برای باز کردن کانال‌ها به سمت خود، یک کاربر مایعیت ورودی را به دست می‌آورد.
• انتقال نقدینگی**: با ارسال پرداخت ها به کانال های دیگر، نقدینگی به طرف مقابل منتقل می شود.

• استفاده از خدمات مانند Loop و Pool**: این خدمات امکان بازتعادل یا خرید کانال‌ها با سیالیت در طرف مقابل را فراهم می‌کنند.

• افتتاحیات همکاری**: بسترهایی نیز برای اتصال و انجام افتتاحیات مثلثی و داشتن سیولیت ورودی موجود است.

نتیجه‌گیری

b8715c1c-7ae2-49b7-94c7-35bf85346ad3

نقد و امتیازات

38814c99-eb7b-5772-af49-4386ee2ce9b0

درست است

امتحان نهایی

7ed33400-aef7-5f3e-bfb1-7867e445d708

صحیح

نتیجه‌گیری

afc0d72b-4fbc-5893-90b2-e27fb519ad02

صحیح