introduction to lightning networks

淺談閃電網路/微支付通道

TaipeiEthereumMeetup2016/07/29

1

自我介紹

•  區塊鏈工程師(世紀快網科技股份有限公司)•  敝公司目前有在徵人喔•  changwu@cepave.com

•  興趣：網路安全、隱私

2

比特幣擴容問題

•  新區塊的產生 (約10分鐘)

•  小額交易要被確認 (時間長)

– 除非支付高額手續費

3

區塊大小快被佔滿

4

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

5

微支付通道 (MicropaymentChannel)

6

重新思考交易的行為

一定每一筆資料都需要寫到鏈上嘛？

7

交易移到鏈下？

8

例子 •  Bob 想要從 Alice 那下載 10 GB 的檔案, 願意付頻寬費

給 Alice, 但 Bob 不相信 Alice 而不願一次付清, 怕 Alice 中途跑走. 如果資料每 GB 價值 1 mBTC

1.  建立 10 次交易，付 10 次交易費

2.  每一次交易的完成必須等待區塊鏈確認

9

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

10

建立單向微支付通道 (OneWayMicropaymentChannel)

11

鏈下多筆交易

12

小結

•  付款方發起 2-of-2 的多簽名合約，並存入略高於支付金額的訂金

–  Alice：無法在 nLockTime(100 blocks) 前取回訂金

–  Bob：只要簽名即可收款

•  在雙方同意後，傳送這筆多簽名合約到區塊鏈 (鏈上)

•  確認後，雙方可進行多筆鏈下交易 (鏈下)

•  最後再將結算後的交易寫回區塊鏈 (鏈上)

13

雙向微支付通道(Bidirec7onalMicropaymentChannel)

IntroducContoMicropaymentChannels 14

閃電網路

•  比特幣中被廣泛接受的創新– 提供一層Paymentlayer– 由JosephPoon 和 TadgeDryja 在 2014 年提出

– 目標是支援更多鏈下交易伴隨較低的手續費

•  公司 –  Lightning–  Blockstream–  Blockchain

15

mul7signature(mul7sig)addresses(P2SH-addresses)

16

Time-Locks1.  Absolutetype,CheckLockTimeVerify(CLTV)2.  RelaCvetype,CheckSequenceVerify(CSV)

17

HashValuesandSecrets

18

Poon Dryja

19

•  各自存入 5BTC 到一個 2-of-2 多簽名地址

•  Alice 與 Bob 彼此交換 Secrets

建立通道(OpeningtheChannel)

20

承諾交易(commitmenttransacCon)假設 Alice 要支付給 Bob1BTCè Alice(4BTC);Bob(6BTC)

21

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

è  對 Alice 而言，需要 Bob 的 Secert

22

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

23

•  假設 Bob 要支付給 Alice1BTC – 交易回到原始狀態：Alice(5BTC);Bob(5BTC)

•  有兩件事情要做– 雙方同時簽署一份新的承諾交易，交換新的Hash– 雙方交換之前彼此擁有的Secrets

更新通道(UpdatetheChannel)

24

•  上一個交易Alice(4BTC);Bob(6BTC)•  如果Bob在結算時，送出過去對他有利的交易

•  回想之前，誰廣播，誰必須等Time-Locks•  加上更新通道的第二步，雙方互相交換上次交易的Secrets•  如果Bob廣播對他有利的舊交易，他要等待1000個區塊•  對於Alice來說，

防止 Bob送出舊的交易

25

Bob 廣播舊交易後

1.Alice 馬上可領錢

2.Alice知道Secret，將 6BTC 領走 (破壞交易順序的人，會損失所有錢)

26

RSMC(RevocableSequenceMaturityContract)

27

•  先前，Alice和Bob建立了雙向通道•  如果Alice想支付1BTC給Carol(第三者)

•  可以的作法1.  Alice與 Carol再建一條雙向通道(建立通道要成本)2.  或是，如果Bob與Carol之間已經有通道了

那麼AliceàBobàCarol

•  對Alice而言，她的疑慮–  怕Bob沒把錢給Carol–  怕Carol否認她收到錢

網路

28

•  消除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

•  他需要相信他把錢給Carol後會拿到secret•  他還需要相信Alice真的會給他錢

對於Bob

HTLC（HashedTimelockContract）

31

Alice建立 1BTC的多簽名合約 •  Case1對於 Bob，若合約中有他的簽名以及正確的 secret值，即可解鎖

•  Case2對於 Alice，使用 CLTV-Cmelock，當合約過期後，自己簽名即可解鎖

CLTV-7melock

32

Ethereum

•  Serenity– Ethereum2.0– SwitchtoPoSconsensus–  IntroducescalingsoluConsincludingshardingandstatechannels

33

總結

•  無需所有交易都記在鏈上 (隱私較佳)

•  對通道中的雙方隱私性差 (同一地址)

•  通道建立必須存入訂金 (錢有段時間被鎖)

•  較少手續費有待驗證 – 找到一條路由，較少手續費，較少 hop

–  Flare:AnApproachtoRouCnginLightningNetwork(白皮書)

34

參考文獻

•  UniversalPaymentChannels(pdf)•  TheBitcoinLightningNetwork:ScalableOff-ChainInstantPayments(pdf)

•  AProtocolforMicrotransacCons(pdf)

35

參考文章

•  微支付通道–  IntroducContoMicropaymentChannelsstorj(link)–  Paymentchannels,LightningFAQ(link)

•  閃電網路– UnderstandingtheLightningNetwork,Part1:BuildingaBidirecConalBitcoinPaymentChannel(link)

– UnderstandingtheLightningNetwork,Part2:CreaCngtheNetwork(link)

– UnderstandingtheLightningNetwork,Part3:CompleCngthePuzzleandClosingtheChannel(link)

36