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

📜 [專欄新文章] [ZKP 讀書會] Tornado Cash

✍️ Jerry Ho

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Disclaimer: 本人與Tornade Cash專案及其員工無任何利益往來。

Tornado Cash是一個Ethereum上的原生隱私轉帳解決方案，使用zk-SNARK+Merkle Tree的路徑證明作為其核心隱私保護機制。

你知我知，Ethereum上的交易記錄是公開的，這使得任何一個人只要知道你的address，便可以在https://etherscan.io/ 之類的網站上查出有多少人和這個位置進行過交易，你做過什麼消費行為或是交易行為等。

或許這聽來不像是個問題，而想要隱藏自己的交易記錄甚至聽起來反而像是不法分子的銷贓行為。

但試想下開情境：因為我曾經使用ethereum捐款給一個政治不正確的專案/組織，而我在接受dd/kyc/reference check的時候因為我的ethereum address就寫在自己的blog上而被查了個底朝天，因而被拒絕入職/拒絕開戶/拒絕服務。

這並不是一個很遙遠的情境…

Tl;dr

解決交易隱私問題分為兩個層次，Assuming你的目的是讓自己的金錢流向無法被追蹤。

層次一：我的錢「丟進了」Tornado Cash的contract，我要如何在不使用與轉入時同一個address的情況下— 若是同一個address就沒有隱私可言了 — 取出我的錢？contract如何知道我存過錢，餘額還夠，所以現在我來領錢了他讓我領？

層次二：就算層次一成立，我的隱私如何達成？到底有多隱私？到底有多不隱私？

技術上來說（細節下文詳談），層次一使用zero-knowledge的set-membership proof來證明，透過預先在Merkle Tree中「登記」一個自己的entry/leaf，tornado cash稱為note，爾後在提款時提出該leaf之zk proof，來解決這個提款時的認證問題。

層次二則是所謂的藏樹於林。既然轉出和轉入無法被連結在一起，那麼只要使用Tornado Cash的人數夠多，總轉出和總轉入的交易總筆數就會太多，以致無法輕易重新關聯轉入與轉出地址背後的真人。

使用界面

https://tornado.cash/

當然你也可以直接和合約地址互動啦

上圖左方紅框為存入幣種與金額大小，右方紅框為該額度對應之帳戶內有多少顆「樹」。

記得藏樹於林嗎？右方的 Anonymity set 就是告訴你現在森林的規模有多大。數量一大，跑資料分析試圖重新關聯某筆特定存款到某筆特定提款就變得更為困難。

提款界面如上。

值得注意的是，提款時的以上兩個選項(Wallet/Relayer)，是在目前Account Abstraction尚未實現時的一個折衷方案。

這裡有個死循環：既然我提款的時候需要支付gas，那麼我的gas從哪裡來？是不是勢必得從交易所或是其他帳號來？簡言之，若是無法直接新建立一個地址然後直接將其作為Tornado Cash提款用，達到的隱私強度就大打折扣。

Relayer就是針對這個問題所設計的。透過付出一些手續費來提供社群架設relayer node的誘因，提款時該筆轉帳的gas費用，便可以讓relayer node來負責先出。relayer node收到使用者的zk proof後將其轉交給tornado cash的合約，合約就會會將應有的relayer手續費與扣除手續費+gas後的款項分別轉給relayer與使用者。

社群治理

Tornado Cash天生是一個比較沒有銅臭味的專案 — 社群治理和funded的味道相當強烈。

透過預先設計好的proxy contract與staking/locking機制，任何一個Tornado Cash的使用者都能夠提出對合約實行的改動建議，並交由社群來投票決定是否要執行該改動。

技術細節可以參照此篇，同時Tornado Cash的第一輪社群治理提案也剛投票過關，回顧可參考此處之討論。

誘因設計

本文作者比較任性不在意錢，請移駕此處閱讀官方如何設計Anonymity Mining來確保以下兩點：

機制能讓使用者願意加入存錢，提供流動性同時也讓樹林變大，增加隱私程度。

產生TORN(ERC20 token)與領取TORN的機制，透過在原本的tornado cash上面再加一層，來避免TORN激勵層錯誤的設計導致下一層之隱私洩漏（激勵層出事不影響核心隱私之意）。

技術細節

首先本文不打算解釋何為zero-knowledge proof，請接受以下描述：

若有一NP statement分類上是satisfiability problem(例：merkle tree中的hash chaining H(H(H(a,b),c),d) )，則我們可以設計出一個arithmetic circuit來確保能夠有效率的產生proof, 有效率的驗證, 無法產生假的且能說服人的proof…且其電路驗證的statement是我們想要的，像是此例中的merkle tree opening.

存款

存款者透過送出C = H(k, r) 以及存入之數額給tornado cash的合約來進行存款的動作。其中k在之後會成為存款者領錢的憑證，稱為nullifier，r則是增加randomness而已，此二值需要記下。此時合約端會將這個C(commitment)丟入Merkle Tree上其中一個空的leaf，並更新root hash。存款者還需要記下自己的C對應之leaf index。

產生proof，用此proof作為提款憑證

用一段話來概括，若是我

知道Merkle Tree上某個leaf的commitment的preimage, 代表我能在電路中證明我知道H(k, r) 中的 k, r, 同時不洩漏k, r到底是多少（zk特性, magic）。

我知道該leaf至root的路徑上會經過哪些點，我也提供了一個可以讓電路驗證root hash的hash chaining過程，代表我知道他是從哪個leaf開始走的。因而，這證明了我提出的1.中的commitment確實屬於某顆公開的、大家都知道的merkle tree中的特定leaf（就是我之前存款對應到的leaf）。

就可以在不需要提供像是原本存款地址的簽章之類的驗證機制情況下，透過zk proof，亦能正確做permission control讓unlinkable的提款能夠成真。

另，讀者可以看到在proof中已然預設了relayer的存在。這使得上開所提到之「使用者提款, 拜託relayer執行=>relayer預付gas發起transaction，將內容送給tornado cash合約=>合約處理proof並將款項拆成兩份給relayer與使用者」這個行為得以成立，且relayer無法得知或假造proof內容。

提款流程

基本上在上方的產生證明都講過一次了，這邊就是pseudo code順過一次提款流程而已，大家自己看啊。

值得一提的是，使用者除了需要提出上一部分提到的證明之外，還需要將k的部分額外拿出來再做一次H(k)，將值一併傳給contract。

這裡的設計哲學，簡單來講是這樣的：zero-knowledge太強了，強到就算證明了我知道H(k, r)的k跟r, 收到的驗證者並沒有辦法知道H(k)是什麼東西。為了讓同一筆款項不會被提領兩次，在提款流程中合約會將「每一筆成功提款中的H(k)」記錄下來，另外開個表存著。爾後若是其他提款交易中的H(k)與表中的重複了，這就代表有人試圖想要騙合約重複提款，自然該提款嘗試就不會成立。

洗錢失敗例

工程師都知道使用者從來不看說明書，看了可能也不會懂。

Koh Wei Jie分析了Kucoin的駭客事件。Kucoin的駭客使用Tornado Cash來洗錢，但忽略了Tornado Cash官方一直三令五申的使用需知，因而讓款項在進入Tornado Cash跑了一輪之後還是能夠被追蹤，哈哈UCCU。

簡單來說，hacker為了節省多次使用relayer的手續費，而將大多數的提領過程都變成直接提領到wallet。雖然該wallet的位置是全新產生的沒有gas，但是透過只讓第一次的提款使用relayer，hacker便能從第一次提款中取得手續費並分發給其他全新產生的wallet address。

那問題在哪？還要問？

要達到隱私需要保持藏樹於林原則，同時使用者不應自己破壞tornado cash幫你達成的address unlinkability。這位hacker因為愛省手續費，所以違背了後者；同時他因為太心急又愛省手續費，太快、分太少次提領、每次提領的數額又太大了，所以side-channel去給他做簡單的traffic analysis就能夠用虛無假設推出：「綜觀歷史上所有的存款位置與數額，扣掉駭客存錢的那些位址之後，我們還需要14個unique address/user共謀，才能有能力一次提這麼多錢。」

這看起來可能嗎？自然是不可能的。

所以這位駭客就是錯誤的沒有遵守藏樹於林的原則，才導致自己的金流重新被和帳號聯繫在一起。

提供一些延伸閱讀，圈子內的”名人”對這種不看說明書的使用者的看法：

tornado * Gavin Andresen

如何避免洗錢失敗

我自己的投影片，我自己翻譯：

打開你的VPN 打開你的TOR 打開你的無痕瀏覽器分頁 用上你全新的VM PC VPS instance 最好連data-link layer安全都顧到 產生全新的地址不要懶惰 自己跑一個fullnode 乖乖用relayer付手續費提款 領錢之後記得把C(k,r)的記錄刪掉 不要急一次存或提領大額 時間拉長數目減少…..

簡而言之：要設計相對安全但又讓使用者可以直覺上手的安全系統真的很他媽難 - 使用者永遠會想辦法抄近路，然後系統的security assumption就爆炸了。

結論上來講，你想要多安全取決於你在臺大水源校區的腳踏車平常都上幾個大鎖=想付出多少成本。只要不要學Kucoin Hacker那樣連鎖都不鎖車還是新的，大部分時間都沒啥問題 lol。

參考資料與文中出現過的連結，不按先後順序：

https://tornado.cash/Tornado.cash_whitepaper_v1.4.pdf

https://tornado.cash/audits/TornadoCash_cryptographic_review_ABDK.pdf

https://tornado.cash/audits/TornadoCash_circuit_audit_ABDK.pdf

https://torn.community/t/whats-next-for-tornado-cash-governance/250

https://weijiek.medium.com/deanonymising-the-kucoin-hacker-418fa5e9911d

https://tornado-cash.medium.com/tornado-cash-governance-proposal-a55c5c7d0703#2084

https://eips.ethereum.org/EIPS/eip-2938

http://gavinandresen.ninja/private-thoughts

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

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] Reason Why You Should Use EIP1167 Proxy Contract. (With Tutorial)
✍️ Ping Chen
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

EIP1167 minimal proxy contract is a standardized, gas-efficient way to deploy a bunch of contract clones from a factory.

1. Who may consider using EIP1167

For some DApp that are creating clones of a contract for its users, a “factory pattern” is usually introduced. Users simply interact with the factory to get a copy. For example, Gnosis Multisig Wallet has a factory. So, instead of copy-and-paste the source code to Remix, compile, key in some parameters, and deploy it by yourself, you can just ask the factory to create a wallet for you since the contract code has already been on-chain.

The problem is: we need standalone contract instances for each user, but then we’ll have many copies of the same bytecode on the blockchain, which seems redundant. Take multisig wallet as an example, different multisig wallet instances have separate addresses to receive assets and store the wallet’s owners’ addresses, but they can share the same program logic by referring to the same library. We call them ‘proxy contracts’.

One of the most famous proxy contract users is Uniswap. It also has a factory pattern to create exchanges for each ERC20 tokens. Different from Gnosis Multisig, Uniswap only has one exchange instance that contains full bytecode as the program logic, and the remainders are all proxies. So, when you go to Etherscan to check out the code, you’ll see a short bytecode, which is unlikely an implementation of an exchange.

0x3660006000376110006000366000732157a7894439191e520825fe9399ab8655e0f7085af41558576110006000f3

What it does is blindly relay every incoming transaction to the reference contract 0x2157a7894439191e520825fe9399ab8655e0f708by delegatecall.
Every proxy is a 100% replica of that contract but serving for different tokens.

The length of the creation code of Uniswap exchange implementation is 12468 bytes. A proxy contract, however, has only 46 bytes, which is much more gas efficient. So, if your DApp is in a scenario of creating copies of a contract, no matter for each user, each token, or what else, you may consider using proxy contracts to save gas.

2. Why use EIP1167

According to the proposal, EIP is a “minimal proxy contract”. It is currently the known shortest(in bytecode) and lowest gas consumption overhead implementation of proxy contract. Though most ERCs are protocols or interfaces, EIP1167 is the “best practice” of a proxy contract. It uses some EVM black magic to optimize performance.

EIP1167 not only minimizes length, but it is also literally a “minimal” proxy that does nothing but proxying. It minimizes trust. Unlike other upgradable proxy contracts that rely on the honesty of their administrator (who can change the implementation), address in EIP1167 is hardcoded in bytecode and remain unchangeable.

That brings convenience to the community.

Etherscan automatically displays code for EIP1167 proxies.

When you see an EIP1167 proxy, you can definitely regard it as the contract that it points to. For instance, if Etherscan finds a contract meets the format of EIP1167, and the reference implementation’s code has been published, it will automatically use that code for the proxy contract. Unfortunately, non-standard EIP1167 proxies like Uniswap will not benefit from this kind of network effect.

3. How to upgrade a contract to EIP1167 compatible

*Please read all the steps before use, otherwise there might have problems.

A. Build a clone factory

For Vyper, there’s a function create_with_code_of(address)that creates a proxy and returns its address. For Solidity, you may find a reference implementation here.

function createClone(address target) internal returns (address result){ bytes20 targetBytes = bytes20(target); assembly { let clone := mload(0x40) mstore(clone, 0x3d602d80600a3d3981f3363d3d373d3d3d363d73000000000000000000000000) mstore(add(clone, 0x14), targetBytes) mstore(add(clone, 0x28), 0x5af43d82803e903d91602b57fd5bf30000000000000000000000000000000000) result := create(0, clone, 0x37) }}

You can either deploy the implementation contract first or deploy it with the factory’s constructor. I’ll suggest the former, so you can optimize it with higher runs.

contract WalletFactory is CloneFactory { address Template = "0xc0ffee"; function createWallet() external returns (address newWallet) { newWallet = createClone(Template); }}

B. Replace constructor with initializer

When it comes to a contract, there are two kinds of code: creation code and runtime code. Runtime code is the actual business logic stored in the contract’s code slot. Creation code, on the other hand, is runtime code plus an initialization process. When you compile a solidity source code, the output bytecode you get is creation code. And the permanent bytecode you can find on the blockchain is runtime code.

For EIP1167 proxies, we say it ‘clones’ a contract. It actually clones a contract’s runtime code. But if the contract that it is cloning has a constructor, the clone is not 100% precise. So, we need to slightly modify our implementation contract. Replace the constructor with an ‘initializer’, which is part of the permanent code but can only be called once.

// constructorconstructor(address _owner) external { owner = _owner;}// initializerfunction set(address _owner) external { require(owner == address(0)); owner = _owner;}

Mind that initializer is not a constructor, so theoretically it can be called multiple times. You need to maintain the edge case by yourself. Take the code above as an example, when the contract is initialized, the owner must never be set to 0, or anyone can modify it.

C. Don’t assign value outside a function

As mentioned, a creation code contains runtime code and initialization process. A so-called “initialization process” is not only a constructor but also all the variable assignments outside a function. If an EIP1167 proxy points to a contract that assigns value outside a function, it will again have different behavior. We need to remove them.

There are two approaches to solve this problem. The first one is to turn all the variables that need to be assigned to constant. By doing so, they are no longer a variable written in the contract’s storage, but a constant value that hardcoded everywhere it is used.

bytes32 public constant symbol = "4441490000000000000000000000000000000000000000000000000000000000";uint256 public constant decimals = 18;

Second, if you really want to assign a non-constant variable while initializing, then just add it to the initializer.

mapping(address => bool) public isOwner;uint public dailyWithdrawLimit;uint public signaturesRequired;

function set(address[] _owner, uint limit, uint required) external { require(dailyWithdrawLimit == 0 && signaturesRequired == 0); dailyWithdrawLimit = limit; signaturesRequired = required; //DO SOMETHING ELSE}

Our ultimate goal is to eliminate the difference between runtime code and creation code, so EIP1167 proxy can 100% imitate its implementation.

D. Put them all together

A proxy contract pattern splits the deployment process into two. But the factory can combine two steps into one, so users won’t feel different.

contract multisigWallet { //wallet interfaces function set(address[] owners, uint required, uint limit) external;}contract walletFactory is cloneFactory { address constant template = "0xdeadbeef"; function create(address[] owners, uint required, uint limit) external returns (address) { address wallet = createClone(template); multisigWallet(wallet).set(owners, required, limit); return wallet; }}

Since both the factory and the clone/proxy has exactly the same interface, no modification is required for all the existing DApp, webpage, and tools, just enjoy the benefit of proxy contracts!

4. Drawbacks

Though proxy contract can lower the storage fee of deploying multiple clones, it will slightly increase the gas cost of each operation in the future due to the usage of delegatecall. So, if the contract is not so long(in bytes), and you expect it’ll be called millions of times, it’ll eventually be more efficient to not use EIP1167 proxies.

In addition, proxy pattern also introduces a different attack vector to the system. For EIP1167 proxies, trust is minimized since the address they point to is hardcoded in bytecode. But, if the reference contract is not permanent, some problems may happen.

You might ever hear of parity multisig wallet hack. There are multiple proxies(not EIP1167) that refer to the same implementation. However, the wallet has a self-destruct function, which empties both the storage and the code of a contract. Unfortunately, there was a bug in Parity wallet’s access control and someone accidentally gained the ownership of the original implementation. That did not directly steal assets from other parity wallets, but then the hacker deleted the original implementation, making all the remaining wallets a shell without functionality, and lock assets in it forever.

https://cointelegraph.com/news/parity-multisig-wallet-hacked-or-how-come

Conclusion

In brief, the proxy factory pattern helps you to deploy a bunch of contract clones with a considerably lower gas cost. EIP1167 defines a bytecode format standard for minimal proxy and it is supported by Etherscan.

To upgrade a contract to EIP1167 compatible, you have to remove both constructor and variable assignment outside a function. So that runtime code will contain all business logic that proxies may need.

Here’s a use case of EIP1167 proxy contract: create adapters for ERC1155 tokens to support ERC20 interface.

pelith/erc-1155-adapter

References

https://eips.ethereum.org/EIPS/eip-1167
https://blog.openzeppelin.com/on-the-parity-wallet-multisig-hack-405a8c12e8f7/

Donation:
pingchen.eth
0xc1F9BB72216E5ecDc97e248F65E14df1fE46600a

Reason Why You Should Use EIP1167 Proxy Contract. (With Tutorial) 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.

👏 歡迎轉載分享鼓掌

眼見比特幣價值猶如火箭般升空，很多人都心動想加入分一杯羹，當然現在是否仍是入貨時機，就要留待直播時留言問施傅或皇叔。不過要入貨，都要知道用甚至工具，今集施傅教學，會分享 3 個買比特幣以及其他虛擬貨幣的方法，以及它們的比較，清楚了解後，入場時才能揀選適合自己的工具。

════════════════════

?財務自由不是夢！把握機會免費體驗?

施傅【10年財務自由】1小時簡介+工作坊
立即試看：https://www.gregorysy.com/

════════════════════

❓有效 極速 儲存千萬❓

【零至千萬加速器】1小時簡介+工作坊
免費試看：https://edu.money-tab.com/pages/accelerator

════════════════════

茶敘50 《ALL or NOTHING》
立即購票：https://edu.money-tab.com/pages/teatalk-50-online

所有課程/活動一覽: https://money-tab.info/activity

施傅新書「量化交易」手冊
網上即買： https://www.money-tab.info/2020-book-purchase


✓ APP下載: http://onelink.to/mtapp
✓ 升級版: https://money-tab.com/membership

❖訂閱【富翁電視MTTV】頻道:
https://bit.ly/35dJW4Y
❖訂閱【我要做富翁】頻道:
https://bit.ly/35LOy2J
❖讚好Facebook專頁:
https://facebook.com/203349819681082
❖追蹤Instagram專頁:
https://www.instagram.com/money_tab/

#虛擬貨幣 #即日可用 #Bitcoin #施傅教學 #理財 #比特币 #美股