鏈下交易

1. 淺談閃電網路/微支付通道
Taipei Ethereum Meetup
2016/07/29
1

2. 自我介紹
• 區塊鏈工程師(世紀快網科技股份有限公司)
• 敝公司目前有在徵人喔
• changwu@cepave.com
• 興趣：網路安全、隱私
2

3. 比特幣擴容問題
• 新區塊的產生 (約10分鐘)
• 小額交易要被確認 (時間長)
– 除非支付高額手續費
3

4. 區塊大小快被佔滿
4

5. Q:有沒有方式能夠在不增加
區塊大小下增加效能？
5

6. 微支付通道
(Micropayment Channel)
6

7. 重新思考交易的行為
一定每一筆資料都需要寫到鏈上嘛？
7

8. 交易移到鏈下？
8

9. 例子
• Bob 想要從 Alice 那下載 10 GB 的檔案, 願意付頻寬費
給 Alice, 但 Bob 不相信 Alice 而不願一次付清, 怕
Alice 中途跑走. 如果資料每 GB 價值 1 mBTC
1. 建立 10 次交易，付 10 次交易費
2. 每一次交易的完成必須等待區塊鏈確認
9

10. 有詐欺及手續費過高的問題
10

11. 建立單向微支付通道
(One Way Micropayment Channel)
11

12. 鏈下多筆交易
12

13. 小結
• 付款方發起 2-of-2 的多簽名合約，並存入略高
於支付金額的訂金
– Alice：無法在 nLockTime(100 blocks) 前取回訂金
– Bob：只要簽名即可收款
• 在雙方同意後，傳送這筆多簽名合約到區塊鏈 (鏈上)
• 確認後，雙方可進行多筆鏈下交易 (鏈下)
• 最後再將結算後的交易寫回區塊鏈 (鏈上)
13

14. 雙向微支付通道
(Bidirec7onal Micropayment Channel)
IntroducCon to Micropayment Channels 14

15. 閃電網路
• 比特幣中被廣泛接受的創新
– 提供一層 Payment layer
– 由 Joseph Poon 和 Tadge Dryja 在 2014 年提出
– 目標是支援更多鏈下交易伴隨較低的手續費
• 公司
– Lightning
– Blockstream
– Blockchain
15

16. mul7signature (mul7sig) addresses
(P2SH-addresses)
16

17. Time-Locks
1. Absolute type, CheckLockTimeVerify (CLTV)
2. RelaCve type, CheckSequenceVerify (CSV)
17

18. Hash Values and Secrets
18

19. Poon Dryja
19

20. • 各自存入 5 BTC 到一個 2-of-2 多簽名地址
• Alice 與 Bob 彼此交換 Secrets
建立通道
(Opening the Channel)
20

21. 承諾交易 (commitment
transacCon)
假設 Alice 要支付給 Bob 1 BTC
è Alice (4 BTC); Bob (6 BTC)
21

22. è 對 Bob 而言，需要簽名並等待 1000 個
區塊時間後才能領取
è 對 Alice 而言，需要 Bob 的 Secert
22

23. 誰廣播，對方立馬可以拿到錢
而廣播方必須等待 Time-Locks
23

24. • 假設 Bob 要支付給 Alice 1 BTC
– 交易回到原始狀態：Alice(5 BTC); Bob(5 BTC)
• 有兩件事情要做
– 雙方同時簽署一份新的承諾交易，交換新的 Hash
– 雙方交換之前彼此擁有的 Secrets
更新通道
(Update the Channel)
24

25. • 上一個交易 Alice( 4 BTC); Bob(6 BTC)
• 如果 Bob 在結算時，送出過去對他有利的交易
• 回想之前，誰廣播，誰必須等 Time-Locks
• 加上更新通道的第二步，雙方互相交換上次交易的 Secrets
• 如果 Bob 廣播對他有利的舊交易，他要等待 1000 個區塊
• 對於 Alice 來說，
防止 Bob 送出舊的交易
25

26. Bob 廣播舊交易後
1. Alice 馬上可領錢
2. Alice 知道 Secret，將 6 BTC 領走
(破壞交易順序的人，會損失所有錢)
26

27. RSMC
(Revocable Sequence Maturity Contract)
27

28. • 先前，Alice 和 Bob 建立了雙向通道
• 如果 Alice 想支付 1 BTC 給 Carol (第三者)
• 可以的作法
1. Alice 與 Carol 再建一條雙向通道 (建立通道要成本)
2. 或是，如果 Bob 與 Carol 之間已經有通道了
那麼 Alice à Bob à Carol
• 對 Alice 而言，她的疑慮
– 怕 Bob 沒把錢給 Carol
– 怕 Carol 否認她收到錢
網路
28

29. • 消除 Alice 的疑慮
– 確認 Bob 將錢給 Carol 後，才將錢給 Bob
– 知會 Carol， Bob 會轉交錢給她
• Alice 要求 Carol 產生一個 Secret，將 Hash(secret) 的結果給
Alice；並告知 Carol，只有 Bob 將錢給她後，才能將這個
secret 給 Bob
• 同時，Alice 把這個 hash 值給 Bob，只有 Bob 錢給 Carol 後，
才能拿到 secret，之後交給 Alice 確認後，Alice 才給 Carol
錢
Carol
29

30. 30

31. • 他需要相信他把錢給 Carol 後會拿到 secret
• 他還需要相信 Alice 真的會給他錢
對於 Bob
HTLC（Hashed Timelock Contract）
31

32. Alice 建立 1 BTC 的多簽名合約
• Case 1
對於 Bob，若合約中有他的簽名以及正確的
secret 值，即可解鎖
• Case 2
對於 Alice，使用 CLTV-Cmelock，當合約過期
後，自己簽名即可解鎖
CLTV-7melock
32

33. Ethereum
• Serenity
– Ethereum 2.0
– Switch to PoS consensus
– Introduce scaling soluCons including sharding and
state channels
33

34. 總結
• 無需所有交易都記在鏈上 (隱私較佳)
• 對通道中的雙方隱私性差 (同一地址)
• 通道建立必須存入訂金 (錢有段時間被鎖)
• 較少手續費有待驗證
– 找到一條路由，較少手續費，較少 hop
– Flare: An Approach to RouCng in Lightning Network (白皮書)
34

35. 參考文獻
• Universal Payment Channels (pdf)
• The Bitcoin Lightning Network: Scalable Off-
Chain Instant Payments (pdf)
• A Protocol for MicrotransacCons (pdf)
35

36. 參考文章
• 微支付通道
– IntroducCon to Micropayment Channels storj (link)
– Payment channels, Lightning FAQ (link)
• 閃電網路
– Understanding the Lightning Network, Part 1: Building
a BidirecConal Bitcoin Payment Channel (link)
– Understanding the Lightning Network, Part 2: CreaCng
the Network (link)
– Understanding the Lightning Network, Part 3:
CompleCng the Puzzle and Closing the Channel (link)
36