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

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

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

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

پیدایش پرداخت‌های چندمسیره یا چندبخشی (MPP)

مفهوم پرداخت MPP یا Multi-Path Payments یک راهکار کلی برای تقسیم یک پرداخت بزرگ به قطعات کوچک‌تر و مسیریابی هر قطعه از طریق یک مسیر جداگانه است. این قطعات کوچک‌تر به صورت همزمان ارسال می‌شوند. البته لزومی ندارد تمام قطعات از مسیرهای مختلف عبور کنند به همین دلیل به پرداخت چندبخشی یا Multi-Part Payments هم شناخته می‌شود.

اصطلاح MPP اغلب به اولین پیاده‌سازی کاربردی این مفهوم، که به عنوان پرداخت‌های چندمسیره ساده (SMP) یا “Base AMP” نیز شناخته می‌شود، اشاره دارد. در این پیاده‌سازی‌ها، تمام قطعات یک پرداخت، از یک هش پرداخت مشترک (payment_hash) و یک پیش‌تصویر (preimage) مشترک استفاده می‌کنند. هنگامی که گیرنده اولین قطعه را دریافت می‌کند، HTLC را می‌پذیرد و آن را نگه می‌دارد، بدون اینکه بلافاصله آن را تسویه کند. دلیل این امر این است که تسویه زودهنگام می‌تواند مدرک پرداخت را به فرستنده بازگرداند، در حالی که ممکن است کل مبلغ هرگز به دست او نرسد. به همین دلیل، گیرنده منتظر می‌ماند تا تمام قطعات دیگر نیز برسند و تنها پس از آن پیش‌تصویر را آشکار می‌کند. این روش، به دلیل نیاز به تغییرات کمتر در پروتکل موجود، اولین راهکاری بود که به صورت گسترده در شبکه به کار گرفته شد.

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

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

پرداخت‌های چندمسیره اتمی (AMP) تکامل اتمی بودن و حریم خصوصی

AMP یا Atomic Multi-Path Payments نسخه پیشرفته‌تر و بهبود یافته MPP است که مشکلات آن را برطرف می‌کند. AMP نیز پرداخت‌ها را به بخش‌های کوچکتر تقسیم می‌کند، اما با یک تفاوت مهم، اتمی بودن. هر بخش از پرداخت دارای هش منحصربه‌فرد خود است. دریافت‌کننده تنها زمانی می‌تواند کل پرداخت را دریافت کند که همه بخش‌ها با موفقیت به او رسیده باشند. اگر حتی یک بخش از پرداخت شکست بخورد، کل تراکنش لغو شده و هیچ پرداختی انجام نمی‌شود.

در AMP، پیش‌تصویر یا preimage به گونه‌ای مدیریت می‌شود که اتمی بودن پرداخت را تضمین کند. برخلاف MPP که از یک preimage مشترک استفاده می‌کند، در AMP هر بخش از پرداخت، یک preimage منحصربه‌فرد دارد. فرستنده پرداخت، یک «رازپایه» یا base secret تولید می‌کند. سپس با استفاده از یک تابع رمزنگاری، برای هر بخش از پرداخت، یک preimage و به دنبال آن یک هش (payment hash) منحصربه‌فرد ایجاد می‌کند. این کار به شکلی انجام می‌شود که دریافت‌کننده تنها زمانی قادر به بازسازی رازپایه خواهد بود که همه بخش‌های پرداخت را دریافت کرده باشد.

هر بخش از پرداخت در قالب یک قرارداد HTLC (Hash Time-Locked Contract) از طریق مسیرهای مختلف به سمت مقصد حرکت می‌کند. هر HTLC با هش منحصربه‌فرد مربوط به همان بخش قفل شده است.

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

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

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

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

AMP امکان استفاده از فاکتورهای ثابت و قابل استفاده مجدد را فراهم می‌کند. برخلاف فاکتورهای سنتی BOLT 11 که یکبارمصرف هستند، یک فاکتور AMP می‌تواند بارها و بارها پرداخت شود.

انتقال AMP از مدل هش مشترک به مدل راز مشترک، یک ارتقاء حیاتی در زمینه امنیت و حریم خصوصی است. پیاده‌سازی‌های اولیه MPP (SMP) مشکل نقدینگی را حل کردند اما یک آسیب‌پذیری آشکار در حریم خصوصی داشتند. این امر نتیجه منطقی مدل HTLC بود که در آن یک پیش‌تصویر واحد، مدرک پرداخت برای همه قطعات است. نوآوری AMP در ایجاد یک مکانیزم رمزنگاری جدید برای پرداخت‌های چندبخشی بدون اتکا به یک راز واحد بود. AMP با استفاده از یک راز اصلی و استخراج هَش‌های منحصربه‌فرد برای هر قطعه، نیاز به اتمی بودن را از آسیب‌پذیری حریم خصوصی جدا می‌کند. این تغییر معماری، شبکه لایتنینگ را از یک لایه پرداخت کاربردی به یک پروتکل مالی پیچیده‌تر و با آگاهی از حریم خصوصی تبدیل کرد.

پیاده‌سازی و پذیرش در عمل

• اجراگر LND

LND در سال ۲۰۱۹ یکی از اولین پذیرندگان MPP بود که پشتیبانی از دریافت آن را در نسخه v0.9.0-beta معرفی کرد. LND در ادامه، AMP را در نسخه v0.13.0-beta به عنوان جانشین پروتکل محبوب Keysend پیاده‌سازی کرد که پرداخت‌های خودبه‌خودی را امکان‌پذیر می‌ساخت.

_ مطمئن شوید از نسخه ۰.۱۳.۰ بتا یا بالاتر LND را اجرا می‌کنید، زیرا پشتیبانی از AMP در این نسخه به طور قابل توجهی بهبود یافته است.

برای فعال سازی ویژگی‌های AMP در فایل lnd.conf، تنظیمات زیر را اضافه کنید:

[protocol]
amp=1

برای ارسال پرداخت AMP با استفاده از lncli، از دستور sendpayment با فلگ –amp استفاده کنید

lncli sendpayment —pay_req=<invoice> —amp

برای دریافت و تولید فاکتور AMP، از دستور addinvoice با فلگ –amp استفاده کنید

lncli addinvoice —memo=“Payment for services” —value=1000 —amp

• اجراگر CLN

CLN پشتیبانی یکپارچه از AMP را ارائه می‌دهد و انعطاف‌پذیری و قابلیت پیکربندی را برای کاربران پیشرفته فراهم می‌کند. این پیاده‌سازی با استفاده از یک معماری ماژولار، از پلاگین‌ها برای ویژگی‌های پیشرفته استفاده می‌کند. مسیریابی چندبخشی مدرن آن توسط پلاگین xpay مدیریت می‌شود، که به عنوان «ساده‌تر و پیچیده‌تر از پلاگین قدیمی pay» توصیف شده و برای بهینه‌سازی پرداخت‌های چندبخشی طراحی شده است.

_ اطمینان حاصل کنید که از نسخه ۰.۱۰.۱ یا بالاتر Core Lightning استفاده می‌کنید. در این نسخه‌ها، CLN به‌صورت خودکار پرداخت‌های چندبخشی اتمی (AMP) را انجام می‌دهد و فاکتورهای ایجادشده به‌طور پیش‌فرض از این نوع پرداخت پشتیبانی می‌کنند.

برای انجام پرداخت، کافیست دستور زیر را وارد کنید

lightning–cli pay <invoice>

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

lightning–cli invoice <amount_msat> <label> <description>

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

• کیف پول‌ها

کیف پول‌های لایتنینگ مختلفی از جمله Electrum، اکنون از Atomic Multi-path Payments (AMP) پشتیبانی می‌کنند که بهره‌مندی از مزایای آن را برای کاربران عادی آسان‌تر می‌سازد. علاوه بر این، ابزارهای مدیریت نود مانند Thunderhub و Ride the Lightning (RTL) نیز از این ویژگی پشتیبانی می‌کنند.

چشم‌انداز آینده

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

منابع:

• Multipath Payments (MPP):
• Atomic Multi-path Payments (AMP):
• Multipart Payments – AMP/MMP – Voltage (22 Jun 2023):
• Multipath payments – Bitcoin Optech:
• Atomic Multipath Payments – Lightning Network Plus:
• Ali2k: Persian Lightning Telegram group, (18 Mar 2025)