關於 github api教學 ，我們在網路上蒐集到這些相關的討論、資訊與評價

📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Trust Token API 是一個正在標準化的瀏覽器 API，主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能，以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制，而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。

會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私，這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。

問題

大家應該都有點了一個產品的網頁後，很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面，他怎麼會知道我看了這個產品的頁面？

通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。

當使用者登入 Facebook 之後，Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面，當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時，瀏覽器在載入 SDK 時會再度夾帶這個識別碼，此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式，Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡，從你的瀏覽紀錄推敲喜好，餵給你 Facebook 最想給你看的廣告了。

不過跨站追蹤也不是只能用在廣告這樣的應用上，像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。

雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務，但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢？

這就是今天要講的新 API: Trust Token。

Trust Token API - The Chromium Projects

Trust Token / Privacy Pass 簡介

Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制，可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass，所以兩個運作機制類似，但是實作方式稍有不同。

先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春，不過大致上還是可以了解整個概念。

以 hCaptcha 跟 Cloudflare 的應用為例，使用者第一次進到由 Cloudflare 提供服務的網站時，網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。

當使用者答對問題後，Cloudflare 會回傳若干組 blind token，這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token，這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token，在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token，這個步驟稱為 redeem token。

但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起，也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token，但是在後續瀏覽不同網站時把 token 兌換掉時，Clouldflare 並無法區分哪個 token 是來自 Bob，哪個 token 是來自 Alice，但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。

但這樣的機制要怎麼完成呢？以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。

零知識證明 (Zero-knowledge proof)

零知識證明是一種方法在不揭露某個祕密的狀態下，證明他自己知道那個秘密。

Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的，下面簡單的翻譯一下：

假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉，如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力？我們可以設計一個流程來證明這件事情。

Alice 先把眼睛閉起來，請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候，告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到，但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。

而零知識證明的原理大致上就是這樣，你可以用一個流程來證明你知道某個秘密，即使你不真的揭露這個秘密到底是什麼，以上面的例子來說，這個秘密就是超能力運作的方式。

以上就是零知識證明的概念，不過要完成零知識證明有很多各式各樣的方式，今天我們要介紹的是 Trust Token 所使用的零知識證明：DLEQ。

DLEQ (Discrete Logarithm Equivalence Proof)

說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar)，如果是大寫如 G, H則是橢圓曲線上面的點 (Point)，如果是 vG 則一樣是點，計算方式則是 G 連續相加 v 次，這跟一般的乘法不同，有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。

DLEQ 有一個前提，在系統中的所有人都知道公開的 G 跟 H 兩個點，此時以下等式會成立：

假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何，並且在這個過程中不揭露 s 真正的數值，此時 Victor 可以產生一個隨機數 c 傳送給 Peggy，而 Peggy 則會再產生一個隨機數 v 並且產生 r，並且附上 vG, vH, sG, sH：

r = v - cs

所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值：

vG = rG + c(sG)vH = rH + c(sH)

我們舉第二個等式作為例子化簡：

vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH

這樣只有 Peggy 知道 s 的狀況下才能給出 r，所以這樣就可以證明 Peggy 確實知道 s。

從簡易到實際的情境

Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境，不過前面的例子就會相對比較天真一點，就請大家一步步的往下看。

基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的，以下參與的角色分為 Client 與 Server，並且都會有兩個階段 issue 與 redeem token。

Scenario 1

如果我們要設計一個這樣可以兌換 token 來確認身分的系統，其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server，Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client，這個產生 sT 的過程稱為 Sign Point，不過實際上運作的原理就是橢圓曲線上的連續加法運算。

SignPoint(T, s) => sT

等到 Client 需要兌換時只要把 T 跟 sT 給 Server，Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。

Issue

以下的範例，左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server，反之亦然。

// Client 發送 T 給 Server, 然後得到 sT

T -> <- sT

Redeem

// Client 要 redeem token 時，傳出 T 與 sT

T, sT ->

問題：Linkability

因為 Server 在 issue 的時候已經知道了 T，所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。

Scenario 2

要解決上面的問題，其中一個方法是透過 Blind Signature 達成。Client 不送出 T，而是先透過 BlindPoint 的方式產生 bT 跟 b，接下來再送給 Server bT。Server 收到 bT 之後，同樣的透過 Sign Point 的方式產生結果，不一樣的地方是情境 1 是用 T，而這邊則用 bT 來作 Sign Point，所以得出來的結果是 s(bT)。

Client:BlindPoint(T) => (bT, b)

Server:SignPoint(bT, s) => sbT

而 Blind Signature 跟 Sign Point 具備了交換律的特性，所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind：

UnblindPoint(sbT, b) => sT

這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了，而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點，同時因為 T 從來都沒有送到 Server 過，所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。

Issue

bT -> <- s(bT)

Redeem

T, sT ->

問題：Malleability

以上的流程其實也有另外一個大問題，因為有交換律的關係，當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT)：

BlindPoint(sT) => a(sT), a// a(sT) === s(aT)

此時如果將 aT 跟 s(aT) 送給 Server Redeem，此時因為

SignPoint(aT, s) => s(aT)

所以就可以兌換了，這樣造成 Client 可以無限地用任意數值兌換 token。

Scenario 3

這次我們讓 Client 先選擇一個純數 t，並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T，並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。

因為 redeem 要送出的是 t，上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了，因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到，所以就沒辦法無限兌換了。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, sT ->

問題：Redemption hijacking

在這個例子裏面，Client 其實是沒有必要傳送 sT 的，因為 Server 僅需要 t 就可以計算出 sT，額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題，如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。

不過在網站上沒講出實際上要怎麼利用這個問題，但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好，而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。

Scenario 4

步驟跟前面都一樣，唯一不一樣的地方是 redeem 的時候原本是傳 t, sT，現在則改傳 t, M, HMAC(sT, M)，如果再介紹 HMAC 篇幅會太大，這邊就不解釋了，但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。

這樣的特性在這個情境用很適合，因為 Server 透過 t 就可以計算出 sT，透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, M, HMAC(sT, M) ->

問題：Tagging

這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’，這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。

要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。

Scenario 5

前面的 DLEQ 講解有提到，如果有 Peggy 有一個 s 秘密純量，我們可以透過 DLEQ 來證明 Peggy 知道 s，但是又不透漏 s 真正的數值，而在 Privacy Pass 的機制裡面，Server 需要證明自己每次都用 s，但是卻又不用揭露真正的數值。

在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端，但 Server 端的回應就不一樣了，這次 Server 會回傳 sbT 與一個 DLEQ 證明，證明自己正在用同一個 s。

首先根據 DLEQ 的假設，Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client，而 H 則改用 bT 代替。

回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token，所以附上了一個 DLEQ 的證明 r = v - cs，Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替，此時 client 也有 sbT 也就是 sH)：

vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT

這樣就可以證明 Server 依然用同一個 s。

Issue

T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)

Redeem

t, M, HMAC(sT, M) ->

問題：only one redemption per issuance

到這邊基本上 Privacy Pass 的原理已經解釋得差不多了，不過這邊有個問題是一次只發一個 token 太少，應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。

Scenario 7

由於一次僅產生一個 redeem token 太沒效率了，如果同時發很多次，每次都產生一個 proof 也不是非常有效率，而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法，這樣就可以大大的降低頻寬需求。

不過這邊我們就不贅述 Batch DLEQ 的原理了，文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。

Issue

T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)

Redeem

t1, M, HMAC(sT1, M) ->

結論

Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式，期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。

不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去，而協議制定的過程中其實廣告龍頭 Google 也參與其中，希望這份協議還是可以保持中立，盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。

參考資料

IETF Privacy Pass docs

Privacy Pass: The Protocol

Privacy Pass: Architectural Framework

Privacy Pass: HTTP API

Cloudflare

Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)

Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化

Other

Privacy Pass official website

Getting started with Trust Tokens (web.dev)

WICG Trust Token API Explainer

Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用，列了很多零知識證明的源碼參考，但可惜的是 DLEQ 這個演算法講解有錯，讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心，源碼應該是可以參考的，解釋的話需要斟酌一下。

關鍵源碼

這邊我貼幾段覺得很有用的源碼。

privacy pass 提供的伺服器端產生 Proof 的源碼

privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼

github dedis/kyber 產生 Proof 的源碼

[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] A Secure State Channels Framework for Ethereum by Liam Horne 解析以太坊上的安全狀態通道
✍️ 田少谷 Shao
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Crosslink 第二天早上由 Liam Horne，狀態通道的主要開發團隊 L4 共同創辦人開場。本以為這場會提到筆者前一天晚上還看得霧煞煞的 Counterfactual ，沒想到這次的演講較為科普、以分享開發近況為主，也被以太坊基金會研究員 Chih-Cheng Liang 稱為最接地氣的一場！

何謂狀態通道？

比特幣的支付通道

若熟悉閃電網路，比特幣的支付通道是一個記錄支付行為的通道，只有開關通道時會接觸到區塊鏈。

假設A公司與B公司有頻繁的交易需求，兩方各自把 10 元放入支付通道中：

19:00 交易開始，兩方所擁有的錢: (10,10)

19:15 A->B 3元: (7,13)

20:10 B->A 7元: (14,6)

20:30 A->B 13元: (1,19)

21:45 B->A 4元: (5,15)

到了 21:45 時，交易結束，此時可以將交易結果 (5,15) 寫到區塊鏈上並分配結餘，而區塊鏈上有的紀錄就只有以下兩筆。

19:00 交易開始，兩方所擁有的錢: (10,10)

21:45 交易結束，兩方所擁有的錢: (5,15)

這代表著交易的結果能被記錄到區塊鏈上，卻大幅減少了要和區塊鏈互動的次數，不只可以降低交易雙方等待區塊鏈回應的次數與時間，也讓區塊鏈要處理的交易數量減少 。

以上只是提供一個很粗淺的例子，可以參考以下連結，精美圖示有助理解：

【動區專題】五分鐘看懂：圖說閃電網路 Ligntning Network

狀態通道 State Channel

由於狀態通道是在以太坊上，和比特幣的環境不同，所以實作方法不盡相同 (提示：UTXO)，但本質上是相同的概念：只要牽涉到「狀態轉換 state-altering」，我們就能開一個通道讓交易參與者在通道中任意次數改變「狀態的值」，而最終將結果寫回區塊鏈上就好。

這邊我引用 Pelith 創辦人 Ping Chen 對於狀態通道精闢的解釋：

狀態通道通常是有別種邏輯疊在上面的通道 — 陳品

也就是說，相對於支付通道的邏輯就只是參與者虛擬貨幣的數量，狀態通道通常指的是該應用場景有自身的邏輯/規則。

舉例來說，在一遊戲中，玩家所擁有的虛寶就可以被視為是許多種狀態：遊戲中金幣及等級的是數值、但同時也是狀態；而 (0,1) 可以用來代表道具的擁有狀態 (沒有，有)。

假設一玩家 A 在遊戲中的起始狀態為 (電卷, 金牌, 鞍切, 金幣, 經驗值) = (0, 0, 0, 300, 1)，隨著遊戲進行，虛寶/狀態的改變：

A 花費 100 金購買了金牌: (0, 1, 0, 200, 1)

A 首殺獲得 200 金、升兩等: (0, 1, 0, 400, 3)

A 花費 300 金用金牌合成了鞍切: (0, 0, 1, 100, 3) # 其實好像還要妖刀?xD

A 擊殺了 B 玩家，升一等: (0, 0, 1, 100, 4)

當玩家要登出、暫停遊戲時，最後的 (0, 0, 1, 100, 4) 就可以被更新到區塊鏈上，而下次登入時就會讀取這個區塊鏈上的狀態讓玩家繼續遊玩。

若了解了此例，就不難想像為什麼狀態通道被提出之時，遊戲以及虛擬貨幣的支付被視為最適合運用的兩個場景：給定參與者=玩家，在限定的場域中=遊戲，進行狀態的更新。

更多細節可以參考此一概念的提出人 Jeff Coleman 的解釋：點我

決策者 Mover

每一個狀態都有一位決策者，由通道中所有參與者輪流擔任。決策者透過對一狀態進行「簽署」來表達是否同意此狀態，也就是說狀態的正當性取決於當前的簽署是否來自正確的決策者。

狀態確認 Valid Transaction

狀態的先後順序是驗證狀態是否有效的方法。取決於應用的場景，有不同的實作方式。若簡單以一個計數器 counter 來實作，只要要求新狀態的計數值為舊狀態 +1，即可驗證。

state(N).counter + 1 == state(N+1).counter

關閉通道與終結性 Finality

當沒有更多交易或有參與者決定要結束交易時，只要全部參與者皆同意就可以關閉通道，ex: 給一 boolean 變數 isFinal，全部人都把自己的 isFinal 皆設為 true 就可以將通道關閉。

萬一有參與者半途消失了？Finality 終結性指的就是「每一個狀態都可以是最終的狀態」。假設部分參與者消失，只要有搭配的機制，例如：計時器，就一定會輪替到仍在線的人；即使參與者全部消失，當前的狀態因具備終結性，所以也能被提交為最終的狀態。

狀態通道實作的規劃與開發進程

Liam 將實作狀態通道的規劃劃分成上圖的六層：

Protocol & Contracts:

- State Progression Protocol

這邊就是上方的「決策者、狀態確認、關閉通道與終結性」。

除了以上所提及的內容，目前團隊也正在開發更方便的協議 Protocol Hardening：有別於交易的結束需要所有參與者的同意，目標是想做到「在特定時間內，任一參與者都能自行決定交易的推進或結束而不受其他參與者影響」。

- Channel Funding Protocol

此處是系統設計的另一個協議 Nitro Protocol，也就是如何開「子通道」，可以參考以下連結：

Nitro Protocol

Client & Hub:

- Client & Protocol Engine

這部分是講 Client 端彼此之間會傳送什麼訊息來進行溝通。

https://specs.counterfactual.com/en/latest/protocols/install-virtual-app.html#the-installvirtualappparams-type

- Client API & Wire Protocol

以下的 Github 專案就是將上方三部分的協議內容實作到網頁端：

counterfactual/monorepo

目前第一版的狀態通道已正在運行了，詳見下方額外學習資源的 Connext。Liam 列出了一些實作第二版時必須納入考量的點：

Robustly store states (i.e., guarantee no accidental money loss)

Automatic detection and responding to challenges

Ability to launch challenges directly with in-browser hooks

Go-to production quality hub software for apps and businesses to use

Browser Wallet UX:

- Wallet Integrations

這些是將狀態通道實作於現存的各種 Wallet 時，需要新增的內容：

https://github.com/counterfactual/monorepo/blob/d3b06b42710c0b7dd93839033cb43da9ac6e0a28/packages/types/src/node.ts

- Wallet UI

最後則是區塊鏈、也是所有新技術能否被廣泛使用的大哉問：該如何設計才能讓使用者有良好的體驗？

在此 Liam 提出實作 Wallet 時可以考慮的要點：

How should a user interact with a state channel?

What are the best patterns for acquiring user consent?

How much does the user have to trust the app?

To what extent can your channel wallet protect you?

What policies should a channel wallet be able to enforce?

額外學習資源

Liam 在本場演講及 Panel Discussion 中，都很鼓勵大家一起跳進來當開發者。他的大致建議如下：看懂相關文章、開發的要求 specs，就可以試著做做看。卡住的時候就到以下連結的討論區詢問他們，包含 Liam 在內的開發人員都會在上面回答問題：

State Channels - A community of state channels researchers from bitcoin, ethereum, and other blockchains

狀態通道的 Github：

State Channels

已成功實作第一版狀態通道的 Connext 專案：

Where will I be able to use v2.0 of Connext?

讓筆者看得霧煞煞的 Counterfactual ，可以進一步提升狀態通道的效率：

Counterfactual: Generalized State Channels on Ethereum

結語

本次演講實為筆者綜觀 Liam 在 Youtube 上的影片後，他對狀態通道最簡單、親民的一次演講，主要著重於介紹開發的進程、應注意的要點，也提供了初探此議題的新手很多學習資源、推坑大家加入開發的建議！

其實陳昶吾博士也曾於 Taipei Ethereum Meetup 詳細介紹過此議題(閃電網路為主)，有興趣者可以看以下影片來得到更完整的認識：

最後，如果我的文章有幫助到你/妳，可以看看我的其他文章，歡迎大家一起交流 :)

田少谷 Shao - Medium

一如往常，感謝 Yahsin Huang 及 Chih-Cheng Liang 幫忙審稿，辛苦了！也特別感謝 Ping Chen 耐心回答素未蒙面的我的問題！！

A Secure State Channels Framework for Ethereum by Liam Horne 解析以太坊上的安全狀態通道 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

[好站分享] GitHub 上的瘋狂 C++ 相關資源清單：Awesome-C++

逛國外網站這麼久，很少碰到有資源齊全到讓我倒抽一口涼氣的...這個作者對 C++ 很有愛啊～～

Awesome-C++，是掛在 GitHub 上的一個 C++ 資源清單。收集了 C++ 相關的函式庫、軟體、書籍、文章...還推薦作者覺得也不錯的其它清單。連結如下：

https://github.com/fffaraz/awesome-cpp

一旦點進去，你會被裡面滿滿的超鏈結，把你的腎上腺素濃度打到最高... XD。如果您平常工作與 C++ 相關，您絕對不能錯過這份清單。我簡單列出一下這份清單有什麼：

(以下文長，是寫給英文苦手的讀者看的。英文沒啥問題的朋友，建議直接看原文即可）

一、函式庫與框架

* 標準函式庫（Standard Libraries）：
C++ 原生函式庫、POSIX、ISO、GNU 各家出品的標準函式庫都有。

* 程式框架（Frameworks）
「框架」比「函式庫」規格大一點。一般來說，「函式庫」幫你把常用的程式寫好，你只要叫用就好了，是一種幫助你加速完工、但並沒帶來任何新功能的一堆程式碼。「框架」則是替原始 C++ 帶來一些令人驚艷的新功能。不過這種分法，並非絕對的。

* 人工智慧（Artificial Intelligence, AI）相關框架與函式庫
想要催得動這一坨東西，得有點 AI 背景。否則你可能不知道函式庫提供給你「深先搜尋（Depth-first Search）」與「廣先搜尋（Width-first Search）」這些函數怎麼讓那堆冷冰冰的硬體多一點智慧。

* 非同步呼叫所使用的事件佇列（Asynchronous Event Loop）
一般來說，一個程式呼叫另一個程式，「叫人的」得等「被叫的」把事情做完，才能繼續進行下一步。就像一個經理眼睛盯著新手做事、沒辦法回到辦公桌做自己的事一樣，這種模式叫「同步呼叫（Synchronous Call）」。比較好的作法，是你交代完新手該做什麼，就離開回去做自己的事，等新手做完了，再來報告說「我做完了」，這種模式叫「非同步呼叫（Asynchronous Call）」。不過要能做到「非同步」，「叫人者」與「被叫者」之間，得有「事件（Event）」這個機制，讓兩者互相溝通該做的事，以及是否完工。此處提供的，都是讓 C++ 能達成「非同步」機制的函式庫或框架。

* 音效（Audio）相關框架或函式庫
這裡放的，都是讓你的 C++ 能做到讀取音效檔（如：mp3），並用程式碼對該檔進行剪輯、混音...等動作的函式庫或框架。

* 生物（Biology）相關框架或函式庫
這邊的函式庫，可以讓您用 C++ 比對兩條 DNA 序列相似度有多高，或者從一大堆不同樣本的 DNA 中，找出哪條 DNA 與哪條可能有親緣關係...等。

* 命令列（Command Line Interface, CLI）相關框架或函式庫
用這邊的函式庫，可以讓您在命令列跑出一些令人驚艷的效果。如 NCurses 就是一套能在命令列之下，用文字盡量模擬出下拉式選單、按鈕...圖形界面的感覺。

* 壓縮（Compression）相關函式庫
讓您不必瞭解檔案壓縮原理，會叫用相關函數就能做到檔案壓縮。

* 平行處理（Concurrency）相關函式庫
讓 C++ 也能輕易做到同時處理多件事情的函式庫。

* 資料結構相關函式庫（Containers）
提供資料結構內的 B-Tree 與 Hashmaps 等架構，讓 C++ 輕鬆取用。

* 加密（Cryptography）相關函式庫
提供加密解密相關函數。

* 資料庫（Database）相關函式庫
讓 C++ 可以用幾道命令，輕鬆接取 MySQL、MongoDB...等知名資料庫內的資料。

* 除錯、測試、效能（Debug）相關函式庫
雖然原文只用了「Debug」這樣的簡單字眼，但這一區的函式庫包含「單元測試（Unit Test）」、「效能測試（Benchmark）」、「記憶體用量追蹤（Memory Tracking）」等功能的函數。讓您的程式在還沒跑之前，就接受嚴格檢驗，降低發生錯誤的機會。

* 遊戲引擎（Game Engine）
提供一些函數，讓您輕鬆讀入 3D 建模軟體（如：Maya, 3D Studio...）做出來的模型與動畫。並在程式內特定事件（如：碰撞）發生時播放。也提供打光（Shading）、物理函數（如：彈跳、碰撞）...等方便的程式供您取用。這些東西讓您在寫遊戲時，能以更快的效率產出結果。

* 圖形界面（Graphical User Interface, GUI）
讓您用 C++ 建立漂亮的視窗、對話框、核取框、下拉式功能表...等圖形界面。

* 圖形（Graphics）相關函式庫
這部分多與遊戲引擎搭配，提供 2D 圖形處理或 3D 光跡追蹤（Rendering）等「外觀美化」的函數。讓您的遊戲角色或場景，看起來更栩栩如生。

* 影像處理（Image Processing）相關函式庫
包含讀入/繪出各式圖檔（PNG、JPG、GIF...）、光學字元辨識、電腦視覺、讀入/播放各式影片（MP4...）等函數。

* 國際化（Internationalization）相關函式庫
讓您用 C++ 寫出來的程式，可以輕易支援各國語言（當然，各國語言要事先請翻譯社先翻好，這邊只是提供語系切換的機制）。

* 行程間通訊（Inter-Process Communication, IPC）相關函式庫
兩個跑起來的獨立程式（如：兩個執行檔）想在執行過程中交換資料，稱為「行程間通訊」，簡稱 IPC。IPC 雖然不至於難如登天，不過要做到，手續還是很瑣碎的。這邊的函式庫提供好用函數，讓兩個行程交換資料時，變得比較容易。

* JSON 支援相關函式庫
JSON 原文是 JavaScript Object Notation。是一種用「純文字」來表示「資料」的方法。如一筆「李大華、35 歲、手機 0937555666」的資料，用 JSON 表示是這樣的：
[
Name: "李大華",
Age: 35,
Mobile: "0937555666"
]
之後可以讓這樣的資料，流通於瀏覽器與伺服器之間。而 JSON 函式庫，可以快速幫您分析 JSON 表示的資料，將它還原成您要的格式。

* 日誌（Logging）支援函式庫
日誌在「系統稽核」中，是很重要的功能。系統得把「什麼人、等級多高、做了什麼事、何時做的、對哪部分做的、從哪個 IP 過來...」忠實記錄下來。萬一系統出事了，我們就能追查可能是誰搞的。類似「監視器」的功能。這部分的函式庫，可以讓 C++ 輕易做到「日誌」功能，您不用傷腦筋日誌功能該怎麼寫，它已經幫您寫好了。您只要會用就行。

* 機器學習（Machine Learning）相關函式庫
提供如「類神經網路」、「電腦視覺」等進階函式庫，讓您的 C++ 程式有少量人類視覺與思考能力（真的很少量，請不用有太高期待）。

* 數學（Math）相關函式庫
一些線性代數、矩陣運算...等相關數學函數。

* 多媒體（Multimedia）相關函式庫
如：影音串流...等相關函數。

* 網路（Networking）相關函數
提供各種低階網路協定相關函數。如：TCP/IP、HTTP、點對點傳輸、非同步通訊、以及一些與 Facebook 橋接的相關函數。

* 物理模擬（Physics）相關函數
這部分也可以大量用於遊戲程式設計。主要提供一些函數，用來模擬自然界各種物理現象。如水流、風吹、碰撞、彈跳...等。

* 機器人控制（Robotics）相關函數
一堆方便你控制或模擬機器人行為的函數。

* 科學運算（Scientific Computing）
一些在科學上比較用得著的數學運算。如工程數學、傅立葉分析...等。

* 腳本語言控制（Scripting）
包含一些能讓 C++ 與各種腳本語言（JavaScript、PHP、Perl...）橋接的函數。

* 序列化控制（Serialization）
首先解釋一下何謂序列化。序列化可以把程式執行到一半的樣子，如數保存於硬碟中，甚至於可以關機。之後可以把序列化的資料「反序列化」，將它「解凍」還原至記憶體繼續跑，就像當初跑到一半被「冷凍」當下再往下執行一樣。這邊提供許多 C++ 序列化的函式庫。

* 影片處理（Video）
可以讀入/播放各種影片檔的函式庫。

* 虛擬機（Virtual Machines）
這邊提供一些用 C++ 寫出來的「輕量級」虛擬機。所謂虛擬機，是用軟體模擬出硬碟、處理器、記憶體、螢幕，工程師可以在虛擬機內安裝另一個作業系統，就好像安裝作業系統至真實機器一樣。

* 網頁應用軟體框架（Web Application Framework）
集合了一些用 C++ 寫出來的 WWW 伺服器、或開發網頁時用得上的函式庫等。

* XML
如果你希望教會你的 C++ 程式「讀懂」一個 XML 檔在講什麼，這邊提供了一堆 XML 解析器（XML Parser），方便您分析從遠方伺服器傳來的 XML 檔到底想表達什麼樣的資料。

* 其它（Miscellaneous）
一些無法分類的東西，通通塞在這裡。大部分是一些小型的函式庫或 C++ 與其它語言的橋接軟體。

二、C++ 相關軟體

* 編譯器（Compiler）
各類把 C++ 原始碼編成 0 與 1 機械碼的軟體。

* 線上編譯器（Online Compiler）
懶得安裝編譯器的話，現在有一堆線上的編譯器。你上傳原始碼，它會編成機械碼後，丟還個執行檔給你下載。

* 除錯器（Debugger）
一些有名的 C++ 除錯器。當你的程式無法執行時，可以靠它找出到底錯在哪裡。

* 整合式開發環境（Integrated Development Environment, IDE）
IDE 就是把文字編輯器（Editor）、編譯器（Compiler）、除錯器（Debugger）...等軟體整合成一體的軟體。您可以不離開該環境，就能寫碼、編譯、除錯、執行...。

* 軟體建構系統（Build Systems）
簡單說，就是把一些瑣碎動作事先安排好、可以在程式碼修改後，下達一條指令（如：「建構！」），就可全自動一條鞭地從編譯、測試、備份、安裝...一口氣完成的系統。

* 原始碼靜態分析軟體（Static Code Analysis）
丟入原始碼，可以幫你找出哪段程式可能發生錯誤，或者可能造成效能低下。也能找出完全沒被叫用到的原始碼，提醒您刪除。甚至於可以把您的程式碼重排成符合特定格式，統一多人寫碼風格時很有用。

三、其它資源

* API Design 文件
* 有用文章（Articles）
* 推薦書籍（Books）
* 寫碼風格（Coding Style）
* 演講（Talks）
* 影片教學（Videos）
* 有用網站（Web Sites）
* 有用部落格（Weblogs）
* 其它 Awesome C++ 姊妹作（Other Awesome Projects）

四、其它也很棒的清單（Other Awesome Lists）

能看到這行字的，給您拍拍手！辛苦了！希望今天分享的內容您會喜歡！也請您不吝按讚鼓勵，或分享給您 Facebook 的親朋好友！