其實越研究最近對於區塊鏈效率的額外改進方案，越會覺得中本聰的區塊鏈真的是神解
對於全球性金流系統而言，最重要的是可用性和共識安全性。
比特幣將可用性的優點體現在不分時間地點、都可以和任何人有比特幣錢包進行交易
在共識安全性上，因為有全網共識，避免了雙花和撤銷交易的可能性，甚至比信用卡安全。
而依照CAP理論，所有的效率的改進方案幾乎都會損害到區塊鏈貨幣的可用性和安全性。
什麼是CAP理論呢？它是對於分散式資料系統的一種限制，你無法同時滿足以下三點特性：
Consistency: 一致性 (所有節點在同一時間具有相同的數據)
區塊鏈系統當然要有同樣的數據資料，並且用PoW或PoS得到唯一有效的共識。
這是對於交易系統的安全性基本需求。
Availability: 可用性 (保證所有類型請求都可以在時限內獲得回應)
對於全球金流系統可用性當然是最重要，
任何使用者可以跟使用網際網路一樣，在任何時間、將所擁有的資金、轉到任一地址。
Partition tolerance: 分隔容忍 (切割成子系統不會影響系統的繼續運作)
中本聰的區塊鏈系統基本上已經把一致性和可用性推到極限。
所以你今天要用比特幣就一定要聯網和區塊鏈同步，大家共識必須一致。沒有子系統。
實際上區塊鏈系統在不擁塞的狀態下根本完美得不得了，一般交易零確認快如閃電。
不信的可以去用零錢玩SatoshiDice，送出交易三秒內就會被偵測到完成一局。
有贏錢三秒內自己的錢包就會收到，根本是real-time的體驗。
連博弈網站都敢這樣搞，bitpay和coinbase也這樣玩很久，代表小額零確認交易非常安全。
所以我一直認為增進區塊鏈容量和效率的技術，才是全球金流系統真正該發展的方向。
那再來看看對於區塊鏈效率的額外改進方案，是否真的是萬靈丹，
可以在不影響一致性和可用性下改進金流系統的效率。
先以已經可以用的Payment channel來看，
它的原理就是Alice和Bob先把自己一部分的資金鎖到通道內，然後互相只交換未確認交易
只有最後要結束通道的時候，才把最後一次的結算交易丟給礦工做確認和結算。
那這樣就大幅減低了礦工負擔了，增加擴容可能性。因為資金先被鎖住也不會被雙花。
但問題是這極大幅度削弱了區塊鏈貨幣的可用性，你的資金被鎖住了。
本來比特幣可以隨時隨地可以轉給任何人，但現在被鎖住只能轉給特定人。
為了解決這個問題，所以後來又搞了一個極端複雜的金流網路，光白皮書就嚇死人。
https://lightning.network/lightning-network-paper.pdf
BTC的閃電網路，在ETH也有一個差不多一樣的實作叫做Raiden雷電網路。
把on-chain fee推高，讓Core一直狂推，把大家都趕到這個網路內，全部都連在一起。
那這樣可用性不就變高了嗎？？
好像很合理。但問題是它的可用性和本來的區塊鏈系統相比脆弱非常多。
首先你要發交易當然還是要鎖錢，重點是和你連線的Payment Hub不能離線，連自己也是。
實際上只要金流的路徑中任何一個節點突然離線了，你的交易就會失敗。
因此這些Payment Hub必定會是非常專業化的，才會閒著沒事24小時開著永不斷線。
但區塊鏈系統大家都可以隨時上線和離線，但你仍然是永遠可以使用。
更不要說路由問題，要去中化作routing一直是資訊科學裡難解的問題。
現在的Internet實際上是用非常中心化的方式去做routing，
就幾個骨幹ISP在網路交換中心做路由，甚至很多部分還是要靠人工設定的。
之前就有發生台灣網路交換中心隔壁機房失火，台灣就大斷網的事件。
而目前閃電網路仍然是靠直接全網廣播所有節點路由資訊，來尋找最佳的金流路徑。
然後說這種方式可以解決本來區塊鏈系統的擴容問題，這我真的笑了。
區塊鍊的擴容瓶頸在於通訊瓶寬，你每發一筆交易就要全網廣播到所有礦工節點。
結果現在變成更新路由資訊也要全網廣播，一個hop廣播一次。
可以預見的是，閃電網路系統的頻寬擴容問題甚至會比本來區塊鏈系統更為嚴重。
再來是閃電網路和一般stateless routing不一樣，可不像一般通訊封包丟了就算了。
每個路徑都還有收支平衡、金流寬度、交易狀態等問題，挖靠，根本大爆炸。
更不要說收款也必須在線這極大幅度影響可用性的問題。
要轉大額款項更是不可能的任務。
可以想見的是閃電網路它的可用性必定遠遠不如於原本的區塊鏈金流系統。
那麼假如我們把區塊鏈系統切割成一個一個的子系統，是否就可以擴容了呢??
那這其實就是sharding和plasma的目標。
https://blockgeeks.com/guides/what-are-ethereum-nodes-and-sharding/
shard可以把會互相交易的同一個DApp丟到同一個shard內。
shard內的交易只讓該shard的隨機validator去確認有效性，
然後寫state root和tx group root到main chain上。
plasma則使用子區塊鏈，同樣把同樣會互相交易的DApp丟到這個子區塊鏈。
但其實這兩個方案適合的是DApp的應用，一個DApp本來就只需要服務部分人，
而不是全部人，所以把DApp丟到shard內，或是plasma的子區塊鏈內，非常適合
因此這兩個方案只有ETH在研發，BTC根本沒在推這兩個方案。
但是全球金流網路這個應用是要服務所有人，要分割子系統就必定會導致延遲。
譬如每一國都有自己自己的shard或是plasma子區塊鍊。
但是比特幣相比於法幣最大的優點就是無國界金流，結果變成所有跨國金流都有高延遲。
以shard來說就需要cross-shard communication，仍然是影響到原本金流系統的可用性。
當然也不排除後來有個比中本聰更神的人來解決這個問題XD。
所以有些系統乾脆對於去中心化的一致性妥協，譬如IOTA，他必須靠COO來維持共識。
結果變成瓶僅卡在COO，拿掉COO理論上可以很快，但如何維持安全性共識仍然有挑戰。
既然中本聰已經發明這麼好的東西，我認為金流系統把區塊鏈推到極限才是主要目標。
譬如Graphene可以把區塊鏈系統的通訊瓶寬效率搞到逼近於IOTA。
而weak-block可大幅強化零確認交易的安全性，本來就跟閃電網路一樣快。
off-chain或是第二層的方案當然也可以同步研發，對於高頻交易或特定應用很有用。
但直接把區塊鏈系統直接蓋掉反而弊大於利。
--
simpleledger:qryeahexpqszdt9ffech6jhxu6wsfp0fnyhgd44ahf
Bitcoin: 1GxtyprMfcxE366BDUsg1skQyuAnxktZjc
https://www.blockchain.com/zh/btc/address/1GxtyprMfcxE366BDUsg1skQyuAnxktZjc
Bitcoin Cash: bitcoincash:qp928h4q4xasa5wh2x88xhsxgc4vwj6g95uzq0ak97
https://goo.gl/2qNr43
Ethereum: 0x4A2B1e35eb64141bbad4C58cB7D79692bC5Dbbc2
https://etherscan.io/address/0x4A2B1e35eb64141bbad4C58cB7D79692bC5Dbbc2
--
對於全球性金流系統而言，最重要的是可用性和共識安全性。
比特幣將可用性的優點體現在不分時間地點、都可以和任何人有比特幣錢包進行交易
在共識安全性上，因為有全網共識，避免了雙花和撤銷交易的可能性，甚至比信用卡安全。
而依照CAP理論，所有的效率的改進方案幾乎都會損害到區塊鏈貨幣的可用性和安全性。
什麼是CAP理論呢？它是對於分散式資料系統的一種限制，你無法同時滿足以下三點特性：
Consistency: 一致性 (所有節點在同一時間具有相同的數據)
區塊鏈系統當然要有同樣的數據資料，並且用PoW或PoS得到唯一有效的共識。
這是對於交易系統的安全性基本需求。
Availability: 可用性 (保證所有類型請求都可以在時限內獲得回應)
對於全球金流系統可用性當然是最重要，
任何使用者可以跟使用網際網路一樣，在任何時間、將所擁有的資金、轉到任一地址。
Partition tolerance: 分隔容忍 (切割成子系統不會影響系統的繼續運作)
中本聰的區塊鏈系統基本上已經把一致性和可用性推到極限。
所以你今天要用比特幣就一定要聯網和區塊鏈同步，大家共識必須一致。沒有子系統。
實際上區塊鏈系統在不擁塞的狀態下根本完美得不得了，一般交易零確認快如閃電。
不信的可以去用零錢玩SatoshiDice，送出交易三秒內就會被偵測到完成一局。
有贏錢三秒內自己的錢包就會收到，根本是real-time的體驗。
連博弈網站都敢這樣搞，bitpay和coinbase也這樣玩很久，代表小額零確認交易非常安全。
所以我一直認為增進區塊鏈容量和效率的技術，才是全球金流系統真正該發展的方向。
那再來看看對於區塊鏈效率的額外改進方案，是否真的是萬靈丹，
可以在不影響一致性和可用性下改進金流系統的效率。
先以已經可以用的Payment channel來看，
它的原理就是Alice和Bob先把自己一部分的資金鎖到通道內，然後互相只交換未確認交易
只有最後要結束通道的時候，才把最後一次的結算交易丟給礦工做確認和結算。
那這樣就大幅減低了礦工負擔了，增加擴容可能性。因為資金先被鎖住也不會被雙花。
但問題是這極大幅度削弱了區塊鏈貨幣的可用性，你的資金被鎖住了。
本來比特幣可以隨時隨地可以轉給任何人，但現在被鎖住只能轉給特定人。
為了解決這個問題，所以後來又搞了一個極端複雜的金流網路，光白皮書就嚇死人。
https://lightning.network/lightning-network-paper.pdf
BTC的閃電網路，在ETH也有一個差不多一樣的實作叫做Raiden雷電網路。
把on-chain fee推高，讓Core一直狂推，把大家都趕到這個網路內，全部都連在一起。
那這樣可用性不就變高了嗎？？
好像很合理。但問題是它的可用性和本來的區塊鏈系統相比脆弱非常多。
首先你要發交易當然還是要鎖錢，重點是和你連線的Payment Hub不能離線，連自己也是。
實際上只要金流的路徑中任何一個節點突然離線了，你的交易就會失敗。
因此這些Payment Hub必定會是非常專業化的，才會閒著沒事24小時開著永不斷線。
但區塊鏈系統大家都可以隨時上線和離線，但你仍然是永遠可以使用。
更不要說路由問題，要去中化作routing一直是資訊科學裡難解的問題。
現在的Internet實際上是用非常中心化的方式去做routing，
就幾個骨幹ISP在網路交換中心做路由，甚至很多部分還是要靠人工設定的。
之前就有發生台灣網路交換中心隔壁機房失火，台灣就大斷網的事件。
而目前閃電網路仍然是靠直接全網廣播所有節點路由資訊，來尋找最佳的金流路徑。
然後說這種方式可以解決本來區塊鏈系統的擴容問題，這我真的笑了。
區塊鍊的擴容瓶頸在於通訊瓶寬，你每發一筆交易就要全網廣播到所有礦工節點。
結果現在變成更新路由資訊也要全網廣播，一個hop廣播一次。
可以預見的是，閃電網路系統的頻寬擴容問題甚至會比本來區塊鏈系統更為嚴重。
再來是閃電網路和一般stateless routing不一樣，可不像一般通訊封包丟了就算了。
每個路徑都還有收支平衡、金流寬度、交易狀態等問題，挖靠，根本大爆炸。
更不要說收款也必須在線這極大幅度影響可用性的問題。
要轉大額款項更是不可能的任務。
可以想見的是閃電網路它的可用性必定遠遠不如於原本的區塊鏈金流系統。
那麼假如我們把區塊鏈系統切割成一個一個的子系統，是否就可以擴容了呢??
那這其實就是sharding和plasma的目標。
https://blockgeeks.com/guides/what-are-ethereum-nodes-and-sharding/
shard可以把會互相交易的同一個DApp丟到同一個shard內。
shard內的交易只讓該shard的隨機validator去確認有效性，
然後寫state root和tx group root到main chain上。
plasma則使用子區塊鏈，同樣把同樣會互相交易的DApp丟到這個子區塊鏈。
但其實這兩個方案適合的是DApp的應用，一個DApp本來就只需要服務部分人，
而不是全部人，所以把DApp丟到shard內，或是plasma的子區塊鏈內，非常適合
因此這兩個方案只有ETH在研發，BTC根本沒在推這兩個方案。
但是全球金流網路這個應用是要服務所有人，要分割子系統就必定會導致延遲。
譬如每一國都有自己自己的shard或是plasma子區塊鍊。
但是比特幣相比於法幣最大的優點就是無國界金流，結果變成所有跨國金流都有高延遲。
以shard來說就需要cross-shard communication，仍然是影響到原本金流系統的可用性。
當然也不排除後來有個比中本聰更神的人來解決這個問題XD。
所以有些系統乾脆對於去中心化的一致性妥協，譬如IOTA，他必須靠COO來維持共識。
結果變成瓶僅卡在COO，拿掉COO理論上可以很快，但如何維持安全性共識仍然有挑戰。
既然中本聰已經發明這麼好的東西，我認為金流系統把區塊鏈推到極限才是主要目標。
譬如Graphene可以把區塊鏈系統的通訊瓶寬效率搞到逼近於IOTA。
而weak-block可大幅強化零確認交易的安全性，本來就跟閃電網路一樣快。
off-chain或是第二層的方案當然也可以同步研發，對於高頻交易或特定應用很有用。
但直接把區塊鏈系統直接蓋掉反而弊大於利。
--
simpleledger:qryeahexpqszdt9ffech6jhxu6wsfp0fnyhgd44ahf
Bitcoin: 1GxtyprMfcxE366BDUsg1skQyuAnxktZjc
https://www.blockchain.com/zh/btc/address/1GxtyprMfcxE366BDUsg1skQyuAnxktZjc
Bitcoin Cash: bitcoincash:qp928h4q4xasa5wh2x88xhsxgc4vwj6g95uzq0ak97
https://goo.gl/2qNr43
Ethereum: 0x4A2B1e35eb64141bbad4C58cB7D79692bC5Dbbc2
https://etherscan.io/address/0x4A2B1e35eb64141bbad4C58cB7D79692bC5Dbbc2
--
All Comments