什麼是原子多路徑支付 (AMP)，為什麼/如何在閃電網路中實施？
關於 AMP 的實施將如何使閃電網路的路由功能受益，已經有很多討論和文章。AMP 正在解決的目前閃電網路實施中的確切問題是什麼？AMP 究竟是如何工作的？以及如何實施？
目前的問題
目前路由機制的主要挑戰是在節點的一側找到具有足夠餘額的通道來轉發收款。為了更具描述性，廣播
channel_announcement的channel_update消息包含short_channel_id閃電節點可以通過它在比特幣區塊鏈中查找交易並找出該通道中鎖定了多少比特幣。但是，人們不知道通道的每個節點擁有多少。這會在路由支付方面產生問題，因為通道的一側可能沒有足夠的餘額來轉發交易，從而導致路由失敗，並且源節點必須使用不同的路由重試支付。第二個問題是原始節點通道餘額。假設我從星巴克買了一杯咖啡，花了我 20,000 聰。現在我在閃電網路中有三個開放通道，每個通道的餘額等於 9,000 聰。暫時不考慮渠道準備金餘額和交易費用，每個渠道我只能支付 9,000 satoshis，這使我無法一次支付購買那杯咖啡。解決辦法是在星巴克通過所有三個渠道購買那杯咖啡時提供給我的同一張付款發票上進行三筆付款。但這會帶來安全問題，來自雜湊重用。具有跨路徑通道的節點可以使用它從一條路徑中學習到的原像來完成沿另一條路徑的支付。還，
第三個問題是，目前（雖然是暫時的）我們對單一支付規模的限制為 2 32毫聰（~0.0429 BTC）。超過此限額的付款需要通過多次付款完成。但這又帶來了一次付款通過而後續付款無法到達收款人的風險。然後，您需要要求收款人處理退款給您。
解決方案
Conner Fromknecht 和 Olaoluwa Osuntokun提出了原子多路徑(AMP) 支付，以便通過將較大的支付分解為較小的支付來解決上述兩個問題，同時不在所有較小的支付流中重複使用任何支付雜湊，並添加強有力的保證，直到所有部分支付流程完成（原子性），接收方根本不會被支付。
s_i他們的提議要求發送方在每次較小的付款 i 中向接收方發送一些秘密。當接收方收到所有付款後，它將通過對發送方發送的所有部分秘密進行異或運算來構造基本支付（BP）秘密，例如BP = s_1 ^ s_2 ^ ... ^ s_n. 現在每個付款原像都是SHA256(BP || i). 這樣做的好處是接收方在收到所有部分付款之前無法創建原像，從而解決了部分付款以及雜湊重用問題。如果在朋友之間完成，這種形式的付款建議確實很有幫助，但是，對於商業用途，這種建議有一個弱點。我們將收到原像視為已成功付款的加密證明。如果發件人知道並且可以提前計算前映像，這會破壞您將從付款接收人那裡獲得的加密收據的整個原則。由於該提案要求發送者創建共享秘密和
payment_hash，因此發送者提前知道了前映像。為了解決這個問題，提出了基本 MPP（多路徑支付）。基本 MPP
payment_hash對所有支付路徑都使用相同的方法。然而，在接收到所有成功的支付之前，接收方不會釋放支付原像，以阻止中間節點使用來自支付的一個分支的原像並滿足另一分支的可能性。由於付款證明很有價值，因此在所有部分付款到達之前，任何理性的收款人都不會接受部分付款，因此不會發布原像。但是，如果它沿一條路徑釋放原像，則沿所有路徑釋放原像符合收款人的經濟利益。執行
與早期版本中的固定長度字節流相比，閃電網路協議現在遵循一種新的類型-長度-值 (TLV) 格式。使用 TLV 可以節省空間，可能會為網路上的應用程序數據或洋蔥負載中的應用程序數據留出更多空間。支持這種可變負載路由洋蔥的節點通過設置
global_features標誌位 8/9 (var_onion_optin) 來指示它。而且，生成的閃電發票需要設置basic_mpp特徵。基本 AMP
payment_hash對所有付款路徑都使用相同的方法。如果最終節點收到一個包含basic_mpp欄位的洋蔥包，則支付可能是“基礎”AMP。設置basic_mpp標誌是發件人的承諾，其餘的付款將在後續的 HTLC 中進行。將收到的所有支付具有相同支付原像的支付的 HTLC 稱為“htlcset”。收到帶有 的洋蔥後
basic_mpp，收款人應等待至少 60 秒，以便所有其他付款都通過。如果在足夠長的時間內沒有收到付款，則最終節點必須使 htlcset 中的所有 htlc 失敗。但是，如果它滿足 htlset 中的任何 HTLC，它必須滿足所有這些。此子集限制可防止在所有部分付款到達之前釋放原像：這將允許任何中間節點立即要求任何未完成的部分付款。未來版本
目前正在對高 AMP 進行工作。它結合了 AMP 的原始提案和目前的 Base MPP，保留了支付證明（被原始提案所犧牲）並確保等待所有部分的加密安全（而不是 Base AMP 的單純經濟激勵） .
然而，這要求我們切換到點和標量而不是散列和原像。發票現在將包含一個支付點，該支付點基本上是通過將標量（相當於私鑰）與標準生成點相乘生成的
secp256k1。支付證明不需要顯示標量，但使用公鑰背後的標量的簽名足以提供支付證明。這也允許支持支付去相關（在每一跳添加額外的標量，並將總標量告訴收款人），同時不需要支付證明或自發支付（它可以與任何一個一起使用）。這基本上是 Lightning 上的無腳本腳本用法。我們有無腳本腳本點鎖定時間鎖定契約 (PTLC)，而不是 HTLC。然而，實現這一點需要在比特幣主鏈上實施 Schnorr，這可能需要幾年時間。