彩色幣通常在特殊錢包中創建，轉移和查看，這些幣可以解釋附加到比特幣交易的彩色幣協議元數據。必須特別注意避免在常規比特幣錢包中使用與彩色幣相關的密鑰，因為常規錢包可能會破壞元數據。同樣，不應將彩色幣發送到由常規錢包管理的地址，只能發送給由可識別彩色幣的錢包管理的地址。Colu和Open Assets系統都使用特殊的彩色幣地址來降低這種風險，並確保彩色硬幣不會發送給未知的錢包。

對於大多數通用區塊鏈瀏覽器來說，彩色幣也是不可見的。相反，你必須使用彩色幣資源管理器來解析彩色幣交易的元數據。

可以在 coinprism 找到與 Open Assets 兼容的錢包應用程式和區塊鏈瀏覽器。

Colu彩色幣兼容的錢包應用程式和區塊鏈瀏覽器可以在這裡找到： Blockchain Explorer.

Colored Coins Copay Addon 是一個 Copay 錢包插件。

每個彩色幣的實現都有不同的創建彩色幣的方式，但它們都提供了類似的功能。創建彩色幣資產的過程稱為 發行 issuance。初始交易，issuance transaction 將資產註冊在比特幣區塊鏈中，並創建一個用於引用資產的 asset ID。一旦發佈，可以使用 transfer transactions 在地址之間轉移資產。

作為彩色幣發行的資產可以有多個屬性。它們可以是 divisible 或 indivisible，意味著傳輸中資產的數量可以是整數（例如5）或小數（例如4.321）。資產也可以有 fixed issuance，也就是說一定金額只發行一次，或者 reissued，意味著資產的新單位可以在初始發行後由原發行人發行。

最後，一些彩色幣支持dividends，允許將比特幣付款按所有權比例分配給著色貨幣資產的所有者。

給彩色幣交易賦予意義的元數據通常使用 OP_RETURN 操作碼儲存在其中一個輸出中。不同的彩色幣協議對 OP_RETURN 數據的內容使用不同的編碼。包含 OP_RETURN 的輸出稱為 標記輸出 marker output。

輸出的順序和標記輸出的位置在彩色硬幣協議中可能有特殊含義。例如，在 Open Assets 中，標記輸出之前的任何輸出均表示資產發放，之後的任何輸出都代表資產轉移。標記輸出通過引用交易中的順序來為其他輸出分配特定的值和顏色。

作為對比，在 Colu 中, 標記輸出對決定元數據解釋方式的操作碼進行編碼。操作碼0x01至0x0F指示發行交易。發行操作碼通常後面跟著一個資產ID或其他標識符，可用於從外部來源（例如，bittorrent）檢索資產訊息。操作碼0x10到0x1F表示轉移交易。轉移交易元數據包含簡單的腳本，通過參考其索引，將特定數量的資產從輸入轉移到輸出。輸入和輸出的排序對於腳本的解釋非常重要。

如果元數據太長以至於無法放入 OP_RETURN，彩色幣協議可能會使用其他＂技巧＂在交易中儲存元數據。示例包括將元數據放入贖回腳本中，然後加上 OP_DROP 操作碼以確保腳本忽略元數據。另一種使用的機制是1-of-N 多重簽名腳本，其中只有第一個公鑰是真正的公鑰，可以花費輸出，隨後的＂密鑰＂被編碼的元數據替代。

為了正確解釋彩色硬幣交易中的元數據，你必須使用兼容的錢包或區塊瀏覽器。否則，交易看起來像是一個帶有 OP_RETURN 輸出的＂普通＂比特幣交易。

作為一個例子，我使用彩色幣創建併發布了MasterBTC資產。 MasterBTC資產代表本書免費副本的代金券。這些優惠券可以使用彩色幣兼容的錢包進行轉讓，交易和兌換。

對於這個特定的例子，我使用了 https://coinprism.info 上的錢包和瀏覽器，它使用Open Assets彩色幣協議。

The issuance transaction as viewed on coinprism.info 使用Coinprism區塊瀏覽器展示了發行交易：

https://www.coinprism.info/tx/10d7c4e022f35288779be6713471151ede967caaa39eecd35296aa36d9c109ec)

如你所見，coinprism展示了20個＂Mastering Bitcoin比特幣的免費副本＂MasterBTC資產發佈到一個特殊的彩色幣地址：

發行交易的交易ID是＂正常＂的比特幣交易ID。The issuance transaction on a block explorer that doesn’t decode colored coins 在不能解析彩色幣的區塊瀏覽器中顯示相同的交易。我們將使用blockchain.info：

https://blockchain.info/tx/10d7c4e022f35288779be6713471151ede967caaa39eecd35296aa36d9c109ec

如你所見，blockchain.info不會將其識別為彩色幣交易。實際上，它用紅色字母標記第二個輸出為＂無法解碼輸出地址＂。

如果你選擇 "Show scripts & coinbase" , 你會看到交易的更多訊息 (The scripts in the issuance transaction).

blockchain.info 還是不理解第二個輸出。它用紅色字母中的＂Strange＂標記。但是，我們可以看到標記輸出中的一些元數據是人類可讀的

讓我們使用 bitcoin-cli 檢索交易：

剔除交易的其他部分，第二個輸出如下所示：

前綴 4F41 表示字母 "OA"，表示 "Open Assets"，幫我們通過Open Assets協議識別接下來的元數據。下面的ASCII編碼字串是資產定義的鏈接：

如果我們檢索這個URL，我們得到一個JSON編碼的資產定義，如下所示：

通過在區塊鏈上鎖定共享狀態的交易，雙方建立狀態通道。這被稱為 存款交易 funding transaction 或 錨點交易 anchor transaction。這筆交易必須傳輸到網路並開採以建立通道。在支付通道的示例中，鎖定狀態是通道的初始餘額（以貨幣計）。

然後雙方交換簽名的交易，稱為 承諾交易 commitment transactions，它改變了初始狀態。這些交易是有效的交易，因為它們可以提交給任何一方進行結算，但是在通道關閉之前，它們會被各方關閉。狀態更新可以創建得儘可能快，因為每個參與方都可以創建，簽署和傳輸交易給另一方。實際上，這意味著每秒可以交換數千筆交易。

在交換承諾交易時，雙方也會使以前的狀態無效，以便最新的承諾交易永遠是唯一可以兌換的承諾交易。這樣可以防止任何一方通過單方面關閉通道並以過期的先前狀態作為對當前狀態更有利的通道進行作弊。我們將研究在本章其餘部分中可用於使先前狀態無效的各種機制。

在通道的整個生命週期內，只有兩筆交易需要提交區塊鏈進行挖礦：存款和結算交易。在這兩個狀態之間，雙方可以交換任何其他人從未見過的承諾交易，也不會提交區塊鏈。

A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions 說明了Bob和Alice之間的支付通道，顯示了存款、承諾和結算交易。

為了解釋狀態通道，我們從一個非常簡單的例子開始。我們展示了一個單向通道，意味著價值只在一個方向流動。我們也將從天真的假設開始，即沒有人試圖欺騙，保持簡單。一旦我們解釋了基本的通道想法，我們就會看看如何讓它變得去信任的，使得任何一方都不會作弊，即使他們想要作弊。

對於這個例子，我們將假設兩個參與者：Emma和Fabian。 Fabian提供了一個影片流媒體服務，使用微型支付通道按秒收費。 Fabian每秒影片收費0.01毫比特幣（0.00001 BTC），相當於每小時影片36毫比特幣（0.036 BTC）。 Emma是從Fabian購買此流影片服務的用戶。 Emma purchases streaming video from Fabian with a payment channel, paying for each second of video 顯示了Emma使用支付通道從Fabian購買影片流媒體服務。

在這個例子中，Fabian和Emma正在使用特殊的軟體來處理支付通道和影片流。 Emma在瀏覽器中運行該軟體，Fabian在伺服器上運行該軟體。該軟體包括基本的比特幣錢包功能，並可以創建和簽署比特幣交易。這個概念和術語＂支付通道＂對用戶來說都是完全隱藏的。他們看到的是按秒付費的影片。

為了建立支付通道，Emma和Fabian建立了一個2-of-2多重簽名地址，每個地址都有一個密鑰。從Emma的角度來看，她瀏覽器中的軟體提供了一個帶有P2SH地址的QR碼（以＂3＂開頭），並要求她提交長達1小時影片的＂存款＂，地址由Emma進行存款。支付給多重簽名地址的Emma的交易是支付通道的存款或錨定交易。

對於這個例子，假設Emma建立了36毫比特幣（0.036 BTC）的通道。這將允許Emma使用流式影片最多1小時。在這種情況下，存款交易可通過channel capacity 設置在此通道中傳輸的最大金額。

資金交易消耗Emma錢包的一個或多個輸入，來創建存款。它為Emma和Fabian之間聯合控制的多重簽名2地址創建了一個36毫比特幣的輸出。可能會有找零的輸出返回Emma的錢包。

一旦存款交易得到確認，Emma可以開始觀看流式影片了。Emma的軟體創建並簽署了一項承諾交易，該交易將通道餘額改為給Fabian地址0.01mBTC，並退還給Emma 35.99mBTC。 Emma簽署的交易消耗了資金交易產生的36mBTC輸出，併產生兩個輸出：一個用於她的退款，另一個用於Fabian的付款。交易只是部分簽署 - 它需要兩個簽名（2個2），但只有艾瑪的簽名。當Fabian的伺服器接收到這個交易時，它會添加第二個簽名（用於2的2輸入）並將其返回給Emma以及1秒的影片。現在雙方都有完全簽署的承諾交易，可以兌換，代表通道正確的最新餘額。任何一方都不會將此交易廣播到網路。

在下一輪中，Emma的軟體創建並簽署了另一個承諾交易（承諾＃2），該交易消耗了資金交易中的2-of-2輸出。第二個承諾交易為Fabian的地址分配一個0.02毫比的輸出和一個35.98毫比的輸出返回Emma的地址。這項新的交易是影片累計秒數的付款。Fabian的軟體簽署並返回第二個承諾交易，再加上另一秒影片。

通過這種方式，Emma的軟體繼續將承諾交易發送給Fabian的伺服器以換取流式影片。隨著Emma消費更多的影片，通道的餘額逐漸積累，以支付Fabian。假設Emma觀看影片600秒（10分鐘），創建和簽署了600個承諾交易。最後一次承諾交易（＃600）將有兩個輸出，將通道的餘額，6 mBTC分給Fabian，30 mBTC 給Emma。

最後，Emma點擊＂Stop＂停止影片流。 Fabian或Emma現在可以傳輸最終狀態交易以進行結算。最後一筆交易是結算交易，並向Fabian支付所有Emma消費的影片費用，將剩餘的資金交易退還給Emma。

Emma’s payment channel with Fabian, showing the commitment transactions that update the balance of the channel 顯示Emma和Fabian之間的通道以及更新通道餘額的承諾交易。

最終，在區塊鏈上只記錄兩筆交易：建立通道的存款交易和在兩個參與者之間正確分配最終餘額的結算交易。

我們剛才描述的通道是有效的，但只有雙方合作，沒有任何失敗或欺騙企圖。我們來看看一些破壞這個通道的情景，看看需要什麼來解決這些問題：

這兩個問題都可以通過timelocks來解決，我們來看看如何使用交易級時間鎖（nLocktime）。

除非有退款保障，否則Emma不能冒險支付2-of-2的多重簽名交易。為了解決這個問題，Emma同時構建存款和退款交易。她簽署了存款交易，但並未將其轉交給任何人。 Emma只將退款交易轉交給Fabian並獲得他的簽名。

退款交易作為第一筆承諾交易，其時間鎖確定了通道的生命上限。在這種情況下，Emma可以將 nLocktime 設置為未來30天或4320個區塊。所有後續承諾交易的時間鎖必須更短，以便在退款交易前兌換。

現在Emma已經完全簽署了退款交易，她可以自信地傳輸已簽署的資金交易，因為她知道她可以最終在時限到期後即使Fabian消失也可以贖回退款交易。

在通道生命週期中，各方交換的每一筆承諾交易將被鎖定在未來。但是對於每個承諾來說，延遲時間會略短，所以最近的承諾可以在其無效的先前承諾前贖回。由於 nLockTime，雙方都無法成功傳播任何承諾交易，直到其時間鎖到期。如果一切順利，他們將通過結算交易優雅地合作和關閉通道，從而不必傳輸中間承諾交易。否則，可以傳播最近的承諾交易以結算賬戶並使所有之前的承諾交易無效。

例如，如果承諾交易＃1被時間鎖定到將來的第4320個區塊，承諾交易＃2時間鎖定到將來的4319個區塊。在承諾交易＃1有效之前的600個區塊時，承諾交易＃600可以花費。

Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid 展示了每個承諾交易設置一個更短的時間段，允許它在先前的承諾變得有效之前花費。

每個後續承諾交易都必須具有較短的時間鎖，以便可以在其前任和退款交易之前進行廣播。先前廣播承諾的能力確保它能夠花費資金輸出並阻止任何其他承諾交易通過花費輸出。比特幣區塊鏈提供的擔保，防止雙重支付和強制執行時間鎖，有效地允許每筆承諾交易使其前任者失效。

狀態通道使用時間鎖來實施跨時間維度的智慧合約。在這個例子中，我們看到時間維度如何保證最近的承諾交易在任何先前的承諾之前變得有效。因此，可以傳輸最近的承諾交易，花費輸入並使先前的承諾交易無效。具有絕對時間鎖保護的智慧合約的執行可防止一方當事人作弊。這個實現只需要絕對的交易級時間鎖（ nLocktime）。接下來，我們將看到如何使用腳本級時間鎖 CHECKLOCKTIMEVERIFY 和 CHECKSEQUENCEVERIFY 來構建更靈活，更實用，更復雜的狀態通道。

單向支付通道的第一種形式在2015年由阿根廷開發團隊演示為影片流應用原型。你可以在 streamium.io. 看到。

時間鎖不是使先前承諾交易無效的唯一方法。在接下來的部分中，我們將看到如何使用撤銷密鑰來實現相同的結果。時間鎖是有效的，但它們有兩個明顯的缺點。通過首次打開通道時建立最大時間鎖，它們會限制通道的使用壽命。更糟糕的是，他們強迫通道的實現在允許長期通道和迫使其中一個參與者在過早關閉的情況下等待很長的退款時間之間取得餘額。例如，如果你允許通道保持開放30天，通過將退款時間鎖定為30天，如果其中一方立即消失，另一方必須等待30天才能退款。終點越遠，退款越遠。

第二個問題是，由於每個後續承諾交易都必須減少時間間隔，因此對雙方之間可以交換的承諾交易數量有明確的限制。例如，一個30天的通道，在未來設置一個4320區塊的時間段，在它必須關閉之前，只能容納4320箇中間承諾交易。將時間鎖承諾交易的間隔設置為1個區塊存在危險。通過將承諾交易之間的時間間隔設置為1個區塊，開發人員為通道參與者創造了非常高的負擔，這些參與者必須保持警惕，保持在線和觀看，並隨時準備好傳輸正確的承諾交易。

現在我們理解了如何使用時間鎖定來使先前的承諾失效，我們可以看到通過合作關閉通道和通過廣播承諾交易單方面關閉通道的區別。所有承諾交易都是時間鎖定的，因此廣播承諾交易總是需要等待，直到時間鎖已過。但是，如果雙方就最終餘額達成一致並知道它們都持有承諾交易並最終實現這一餘額，那麼它們可以在沒有時間鎖表示同樣餘額的情況下構建結算交易。在合作關係中，任何一方都採取最近的承諾交易，並建立一個結算交易，除了省略時間鎖之外，交易在每個方面都是相同的。雙方都可以簽署這筆結算交易，因為他們知道沒有辦法作弊並獲得更有利的餘額。通過合作簽署和轉交結算交易，他們可以關閉通道並立即贖回餘額。最差的情況下，其中一方可能會小心謹慎，拒絕合作，並強迫對方單方面使用最近的承諾交易關閉。但如果他們這樣做，他們也必須等待他們的資金。

處理先前承諾狀態的更好方法是明確撤銷它們。但這並不容易實現。比特幣的一個關鍵特徵是，一旦交易有效，它保持有效狀態且不會過期。取消交易的唯一方法是在交易被挖出之前將其輸入與其他交易雙重支付。這就是為什麼我們在上面的簡單支付通道示例中使用時間鎖的原因，確保在較早的承諾有效之前可以花費最近的承諾。但是，按時間排列承諾產生了一些限制，使支付通道難以使用。

即使交易無法取消，也能以不希望使用它的方式構建交易。方法是給每一方一個 撤銷密鑰 revocation key ，如果他們試圖欺騙，可以用來懲罰對方。這種撤銷先前承諾交易的機制最初是作為閃電網路（Lightning Network）的一部分提出的。

為了解釋撤銷鑰匙，我們將在Hitesh和Irene運營的兩個交易所之間構建一個更復雜的支付通道。Hitesh和Irene分別在印度和美國經營比特幣交易所。 Hitesh印度交易所的客戶經常向Irene的美國交易所的客戶支付款項，反之亦然。目前，這些交易發生在比特幣區塊鏈上，但這意味著要支付費用並等待幾個區塊進行確認。在交易所之間建立支付通道將顯著降低成本並加快交易流程。

Hitesh和Irene通過合作構建存款交易來啟動通道，每一方都向通道支付5比特幣資金。 最初的餘額是Hitesh的5比特幣和Irene的5比特幣。資金交易將通道狀態鎖定為2-of-2的多重簽名，就像簡單通道的例子一樣。

存款交易可能有來自Hitesh的一個或多個輸入（加起來5比特幣或更多），以及來自Irene的一個或多個輸入（加起來5比特幣或更多）。輸入必須略高於通道容量才能支付交易費用。該交易有一個輸出，將10比特幣鎖定為由Hitesh和Irene控制的2-of-2多重簽名地址。交易也可能有一個或多個產出，如果他們的輸入超過了他們預期的通道貢獻，則會向Hitesh和Irene返回零錢。這是由雙方提供並簽署輸入的單一交易。它必須由各方合作建立並由各方簽名，然後才能傳送。

現在，Hitesh和Irene不創建雙方簽署的單一承諾交易，而是創建兩個 不對等 asymmetric 的承諾交易

Hitesh有兩項輸出的承諾交易。第一個輸出 立即 支付Irene她5比特幣。第二個輸出向Hitesh支付5比特幣，但是在1000區塊的時間鎖之後。交易輸出如下所示：

Irene有兩個輸出的不同承諾交易。第一個輸出立即向Hitesh支付他5比特幣。第二個輸出支付Irene她5比特幣，但是在1000區塊的時間段之後。 Irene持有的承諾交易（由Hitesh簽名）如下所示：

通過這種方式，每一方都有承諾交易，花費2-of-2的存款交易的輸出。該輸入由 另一方 簽名。在任何時候擁有交易的一方也可以簽署（完成2-of-2）和廣播。但是，如果他們廣播承諾交易，會立即付款給對方，而他們不得不等待一個短的時間鎖。通過延遲其中一項輸出的贖回，我們使各方在選擇單方面廣播承諾交易時處於輕微劣勢。但僅有延時的話就不足以鼓勵公平行為。

Two asymmetric commitment transactions with delayed payment for the party holding the transaction 展示了兩個不對稱承諾交易，其中支付給承諾持有人的輸出被延遲。

現在我們介紹這個方案的最後一個元素：一個可以防止作弊者廣播過期承諾的撤銷密鑰。撤銷密鑰允許受騙方通過佔用整個通道的餘額來懲罰作弊者。

撤銷密鑰由兩個密鑰組成，每個密鑰由每個通道參與者獨立生成。它類似於一個2-of-2多重簽名，但是使用橢圓曲線演算法構造，雙方都知道撤銷公鑰，但是每一方只知道撤銷私鑰的一半。

在每一輪中，雙方向對方公開其一半的撤銷密鑰，從而如果此次撤銷的交易被廣播，可以給予另一方（現在擁有兩半）用於要求罰款輸出的手段。

每個承諾交易都有一個＂延遲的＂輸出。該輸出的兌換腳本允許一方在1000個區塊之後兌換它，或者如果擁有撤銷密鑰，另一方可以贖回它，從而懲罰已撤銷承諾的傳輸。

因此，當Hitesh創建一筆讓Irene簽署的承諾交易時，他將第二個輸出在第1000個區塊之後支付給自己，或者支付給撤銷公鑰（其中他只知道一半的密鑰）。 Hitesh構造了這個交易。只有當他準備轉移到新的通道狀態並想要撤銷這一承諾時，他才會向Irene展示他這一半的撤銷密鑰。

第二個支出的腳本如下:

Irene可以自信地簽署這筆交易，因為如果這筆交易被傳送，它會立即向她支付她應得的東西。 Hitesh持有該交易，但如果他通過單方面通道關閉傳輸，他將不得不等待1000個區塊才能獲得報酬。

當通道進入下一個狀態時，Hitesh必須在Irene同意簽署下一個承諾交易前撤銷此承諾交易。要做到這一點，他所要做的就是將他的一半 revocation key 發給Irene。一旦Irene擁有將這項承諾的兩半密鑰，她就可以自信地簽署下一個承諾。因為她知道如果Hitesh試圖通過公佈先前的承諾來作弊，她可以使用撤銷鑰匙來贖回Hitesh的延遲輸出。如果Hitesh作弊，Irene會得到兩個輸出。同時，Hitesh只有該撤銷公鑰的一半撤銷密鑰，在後續1000區塊之前無法贖回輸出。 Irene將能夠在1000個區塊到達之前贖回輸出懲罰Hitesh。

撤銷協議是雙邊的，這意味著在每一輪中，隨著通道狀態的前進，雙方交換新的承諾，為以前的承諾交換撤銷密鑰，並簽署對方的新的承諾交易。當他們接受一個新的狀態時，他們通過給予對方必要的撤銷密鑰來懲罰任何作弊行為，使先前的狀態無法使用。

我們來看一個它如何工作的例子。Irene的一位客戶希望將2比特幣發送給Hitesh的客戶之一。為了在通道中傳輸2比特幣，Hitesh和Irene必須推進通道狀態以反映新的餘額。他們將承諾一個新的狀態（狀態2號），其中10個比特幣被分割，7個比特幣給Hitesh，3個比特幣給Irene。為了推進通道狀況，他們將各自創建新的承諾交易，體現新的通道餘額。

和以前一樣，這些承諾交易是不對稱的，因此每一方的承諾交易都會迫使他們在兌換時等待。至關重要的是，在簽署新的承諾交易之前，他們必須首先交換撤銷密鑰以使先前的承諾失效。在這種特殊情況下，Hitesh的興趣與通道的真實狀態保持一致，因此他沒有理由廣播先前的狀態。然而，對於Irene來說，狀態1給她的餘額高於狀態2.當Irene將她的先前承諾交易（狀態1）的撤銷密鑰給Hitesh時，她也撤銷了她通過倒退通道獲利的能力。因為有了撤銷鑰匙，Hitesh可以毫不拖延地贖回先前承諾交易的兩個輸出。這意味著，如果Irene廣播先前的狀態，Hitesh可以行使他的權利拿走所有輸出。

重要的是，撤銷不會自動發生。雖然Hitesh有能力懲罰Irene的作弊行為，但他必須認真觀察區塊鏈是否存在作弊跡象。如果他看到先前的承諾交易被廣播，他有1000個區塊時間採取行動，使用撤銷密鑰來阻止Irene的作弊行為，並通過取得全部10個比特幣來懲罰她。

具有相對時間鎖的不對稱可撤銷承諾（ CSV ） 是實施支付通道的更好方式，也是該技術非常重要的一項創新。通過這種構造，通道可以無限期地保持開放，並且可以擁有數十億的中間承諾交易。在Lightning Network的原型實現中，承諾狀態由48位索引標識，允許任何單個通道有超過281萬億次（2.8×10¹⁴）狀態轉換！

支付通道可以通過特殊類型的智慧合約進一步擴展，允許參與者將資金送到可贖回的密鑰上，並有過期時間。此功能稱為 Hash Time Lock Contract 或 HTLC ，並用於雙向支付通道和路由支付通道。

我們先來解釋HTLC的＂雜湊＂部分。要創建HTLC，付款的預期接收人將首先創建一個密鑰 R。然後他們計算這個密鑰的的雜湊值 H：

產生的雜湊值 H 可以包含在輸出的鎖定腳本中。知道這個密鑰的人可以用它來贖回輸出。密鑰 R 也被稱為雜湊函數的 原象 preimage 。原象只是用作雜湊函數輸入的數據。

HTLC的第二部分是＂時間鎖定＂。如果密鑰未透露，HTLC的付款人可以在一段時間後獲得＂退款＂。這是通過使用 CHECKLOCKTIMEVERIFY 進行絕對時間鎖定實現的。

實現了 HTLC 的腳本看起來是這樣的：

任何知道密鑰 R 的人，當雜湊值等於 H 時，可以通過行使 IF 流的第一個子句來贖回該輸出。

如果密鑰未透露，HTLC聲稱，在一定數量的區塊之後，付款人可以使用 IF 流程中的第二個條款要求退款。

這是HTLC的基本實現。這種類型的HTLC可以由具有密鑰 R 的 任何人 兌換。對腳本稍作修改，HTLC可以採取許多不同的形式。例如，在第一個子句中添加一個 CHECKSIG 運算符和一個公鑰，將雜湊的兌換限制為一個指定的收款人，該收款人還必須知道密鑰 R。

讓我們看下它如何工作。

在這個例子中，有五個參與者：Alice、Bob、Carol、Diana和Eric。這五位參與者相互開設了支付通道，兩兩相連。 Alice 與 Bob，Bob 與 Carol，Carol 與 Diana，Diana 與 Eric。為了簡單起見，我們假設每個參與者為每個通道提供2比特幣，每個通道的總容量為4比特幣。

A series of bidirectional payment channels linked to form a Lightning Network that can route a payment from Alice to Eric 展示了閃電網路中的五位參與者，通過雙向支付通道進行關聯，這些通道可以連接起來以支持 Alice 支付到 Eric (路由支付通道（閃電網路）).

Alice 想要支付 Eric 1比特幣。但是，Alice 沒有通過支付通道與 Eric 連接。創建一個支付通道需要一筆資金交易，這筆交易必須交給比特幣區塊鏈。Alice 不想開設新的支付通道並承諾更多的資金。有沒有間接支付Eric的方法？

Step-by-step payment routing through a Lightning Network 展示了通過連接參與者的支付通道上的一系列 HTLC 承諾，從 Alice 支付到 Eric 的分步過程。

Alice 正在運行一個閃電網路（LN）節點，該節點跟蹤她和Bob的支付通道，並且能夠發現支付通道之間的路線。Alice 的 LN 節點還可以通過網路連接到 Eric 的 LN 節點。 Eric 的 LN 節點使用隨機數生成器創建一個密鑰 R。Eric 的節點並沒有向任何人透露這個密鑰。Eric 的節點計算密鑰 R 的雜湊 H 並將該雜湊傳送給 Alice 的節點（參見 Step-by-step payment routing through a Lightning Network 步驟1）。

現在，Alice 的 LN 節點構造了 Alice 的 LN 節點和 Eric 的 LN 節點之間的路線。所使用的路由演算法將在後面更詳細地討論，但現在讓我們假設 Alice 的節點可以找到有效的路由。

然後，Alice 的節點構建一個HTLC，支付給雜湊值 H，並有10個區塊的超時退款（當前區塊 + 10），金額為1.003比特幣（參見 Step-by-step payment routing through a Lightning Network 步驟2）。額外的0.003將用於補償參與此支付路線的中間節點。Alice 向 Bob 提供這個 HTLC ，從 Bob 的通道餘額中扣除 1.003 比特幣並將其交給 HTLC。 HTLC具有以下含義：＂如果 Bob 知道密鑰，則 Alice 將1.003的通道餘額付給Bob，或者如果經過10個區塊，則退還到 Alice 的餘額。＂ Alice 和 Bob 之間的通道餘額現在是由三項輸出的承諾交易表示：Bob的2比特幣，Alice的0.997比特幣，Alice的HTLC的1.003比特幣。Alice向HTLC承諾的金額減少了Alice的餘額。

Bob現在有一個承諾，如果他能夠在接下來的10個區塊內獲得密鑰 R，他可以獲得被Alice鎖定的1.003。有了這個承諾，Bob的節點在Carol的支付通道上構建了一個HTLC。 Bob的HTLC承諾了9個區塊超時的1.002比特幣給 H，如果有密鑰 R，Carol可以贖回（參見 Step-by-step payment routing through a Lightning Network 步驟3）。Bob知道，如果Carol可以獲得他的HTLC，她必須有 R。如果Bob在9個區塊時間內得到 R，他可以用它來向Alice索要Alice的HTLC。他還通過在9個區塊時間內貢獻他的通道餘額獲得了0.001比特幣。如果Carol不能索要他的HTLC，他不能索要Alice的HTLC，那麼一切都會恢復到之前的通道餘額，沒有人會不知所措。Bob和Carol之間的通道餘額現在是：Carol的2，Bob的0.998，Bob到HTLC的1.002。

Carol現在有一個承諾，如果她在接下來的9個區塊時間內獲得 R，她可以索要由Bob鎖定的1.002比特幣。現在，她可以在她與Diana的通道上做HTLC承諾。她將一個1.001比特幣的HTLC提交給雜湊 H，8個區塊過期時間，如果有密鑰 R，Diana可以贖回（參見 Step-by-step payment routing through a Lightning Network 步驟4）。從Carol的角度來看，如果這樣做的話，她能獲得0.001比特幣更好，如果沒有，她什麼都不會丟失。她到Diana的HTLC只有在 R 被揭示時才是可行的，在這一點上，她可以向Bob索取HTLC。Carol和Diana之間的通道餘額現在是：Diana的2，Carol的0.99，Carol對HTLC承諾的1.001。

最後，Diana可以向Eric提供一個HTLC，將7個區塊超時時間內支付1比特幣給雜湊 H（參見 Step-by-step payment routing through a Lightning Network 步驟5）。Diana和Eric之間的通道餘額現在是：Eric的2，Diana的1，Diana到HTLC的1。

但是，在這條路線上，Eric 擁有 密鑰 R。因此，他可以索要Diana提供的HTLC。他將 R 發送給 Diana 並索要1比特幣，將其添加到他的通道餘額中（參見 Step-by-step payment routing through a Lightning Network 步驟6）。通道餘額現在是：Diana的1，Eric的3。

現在，Diana有密鑰 R。因此，她現在可以從Carol那獲得HTLC。 Diana將 R 發送給Carol，並將1.001比特幣添加到她的通道餘額中（參見 Step-by-step payment routing through a Lightning Network 步驟7）。現在，Carol和Diana之間的通道餘額是：Carol的0.999，Diana的3.001。Diana參與這條支付路線＂贏得＂了0.001。

沿著路線返回，密鑰 R 允許每個參與者索要HTLC。 Carol向Bob索要1.002，將他們的通道中的餘額設置為：Bob的0.998，Carol的3.002（參見 Step-by-step payment routing through a Lightning Network 步驟8）。最後，Bob索要來自Alice的HTLC（參見 Step-by-step payment routing through a Lightning Network 步驟9）。他們的通道餘額更新為：Alice的0.997，Bob的3.003。

Alice在沒有與Eric開通通道的情況下就向Eric支付了1比特幣。支付路徑中的任何中間人都不需要互相信任。將他們的資金在通道中用於短期承諾，他們可以賺取一小筆費用，唯一的風險是如果通道關閉或路由支付失敗，退款會有小幅延遲。

LN節點之間的所有通信都是點對點加密的。另外，節點有一個長期的公鑰，http://bit.ly/2r5TACm[用來向彼此授權].

每當一個節點希望將支付發送給另一個節點時，它必須首先通過連接具有足夠容量的支付通道來通過網路構建 路徑 path。節點公佈路由訊息，包括他們已經打開了哪些通道，每個通道有多少容量，以及他們收取的路由支付費用。路由訊息可以以各種方式共享，隨著閃電網路技術的發展，可能會出現不同的路由協議。一些閃電網路實現使用IRC協議作為節點公佈路由訊息的便利機制。路由發現的另一個實現使用P2P模型，其中節點將通道公告傳播給他們的同伴，採用＂泛洪＂模式，類似於比特幣傳播交易的機制。未來的計劃包括名為 Flare 的提案，這是一種具有本地節點＂鄰居＂和更遠距離信標節點的混合路由模型。

在我們前面的例子中，Alice的節點使用這些路由發現機制之一來查找將她的節點連接到Eric節點的一條或多條路徑。一旦Alice的節點構建了一條路徑，她將通過網路傳播一系列加密和嵌套指令，連接每個相鄰的支付通道，初始化該路徑。

重要的是，這條路只有Alice的節點才知道。支付路線中的所有其他參與者只能看到相鄰的節點。從Carol的角度來看，這看起來像是Bob到Diana的付款。Carol並不知道Bob實際上是在轉發Alice支付的一筆款項。她也不知道Diana會向Eric轉賬。

這是閃電網路的一個重要特徵，因為它確保了付款隱私，並且使得應用監視，審查或黑名單非常困難。但是，Alice如何建立這種支付路徑，而不向中間節點透露任何東西？

閃電網路根據稱為 Sphinx 的方案實施洋蔥路由（onion-routed）協議。此路由協議可確保付款發起人可以通過 Lightning Network 構建和傳遞路徑，以便：

使用這種洋蔥路由協議，Alice將路徑中的每個元素都封裝在一個加密層中，從結尾開始並向後工作。她用Eric的公鑰將一條訊息加密給Eric。此訊息包裹在一封加密給Diana的訊息中，將Eric標識為下一個收件人。發給Diana的訊息包裹在一封加密給Carol公鑰的訊息中，並將Diana確定為下一個收件人。給Carol的訊息被加密到Bob的密鑰。因此，Alice已經構建了這種加密的多層＂洋蔥＂訊息。她將此發送給Bob，他只能解密和解包外層。在裡面，Bob發現一封給Carol的信，他可以轉發給Carol，但不能自己破譯。沿著路徑，訊息被轉發，解密，轉發等，一直到Eric。每個參與者只知道每跳中的前一個和下一個節點。

路徑的每個元素都包含有關必須擴展到下一跳的HTLC訊息，正在發送的金額，要包含的費用以及使HTLC過期的CLTV鎖定時間（以區塊為單位）。隨著路由訊息的傳播，這些節點將HTLC承諾轉發到下一跳。

此時，你可能想知道節點為何不知道路徑的長度及其在該路徑中的位置？畢竟，他們收到一條訊息並將其轉發到下一跳。根據它是否變短了，他們能夠推斷出路徑大小和位置？為了防止這種情況，路徑總是固定為20跳，並填充隨機數據。每個節點都會看到下一跳和一個固定長度的加密訊息來轉發。只有最終收件人看到沒有下一跳。對於其他人來說，總是還有20跳。

閃電網路是次層路由技術。它可以應用於任何支持一些基本功能的區塊鏈，例如多重簽名交易，時間鎖定和基本智慧合約。

如果閃電網路位於比特幣網路之上，那麼比特幣網路可以在不犧牲無中介無信任運轉原則的情況下，大幅提升容量、隱私、粒度和速度：

當然，如前所述，閃電網路協議並不是實現路由支付通道的唯一方式。其他提議的系統包括Tumblebit和Teechan。但是，目前閃電網路已經部署在測試網路上。幾個不同的團隊開發了競爭性的LN實現，並正在朝著一個通用的互操作性標準（稱為BOLT）努力。 Lightning Network很可能將成為第一個在生產環境中部署的路由式支付通道網路。