📜 [專欄新文章] Merkle Tree in JavaScript
✍️ Johnson
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
這篇文章會說明 Merkle Tree 的運作原理,以及解釋 Merkle Proofs 的用意,並以 JavaScript / TypeScript 簡單實作出來。
本文為 Tornado Cash 研究系列的 Part 1,本系列以 tornado-core 為教材,學習開發 ZKP 的應用,另兩篇為:
Part 2:ZKP 與智能合約的開發入門
Part 3:Tornado Cash 實例解析
Special thanks to C.C. Liang for review and enlightenment.
本文中實作的 Merkle Tree 是以 TypeScript 重寫的版本,原始版本為 tornado-core 以 JavaScript 實作而成,基本上大同小異。
Merkle Tree 的原理
在理解 Merkle Tree 之前,最基本的先備知識是 hash function,利用 hash 我們可以對資料進行雜湊,而雜湊後的值是不可逆的,假設我們要對 x 值做雜湊,就以 H(x) 來表示,更多內容可參考:
一次搞懂密碼學中的三兄弟 — Encode、Encrypt 跟 Hash
SHA256 Online
而所謂的 Merkle Tree 就是利用特定的 hash function,將一大批資料兩兩進行雜湊,最後產生一個最頂層的雜湊值 root。
當有一筆資料假設是const leaves = [A, B, C, D],我們就用function Hash(left, right),開始製作這顆樹,產生H(H(A) + H(B))與H(H(C) + H(D)),再將這兩個值再做一次 Hash 變成 H(H(H(A) + H(B)) + H(H(C) + H(D))),就會得到這批資料的唯一值,也就是 root。
本文中使用的命名如下:
root:Merkle Tree 最頂端的值,特色是只要底下的資料一有變動,root 值就會改變。
leaf:指單一個資料,如 H(A)。
levels:指樹的高度 (height),以上述 4 個資料的假設,製作出來的 levels 是 2,levels 通常會作為遞迴的次數。
leaves:指 Merkle Tree 上的所有資料,如上述例子中的 H(A), H(B), H(C), H(D)。leaves 的數量會決定樹的 levels,公式是 leaves.length == 2**levels,這段建議先想清楚!
node:指的是非 leaves 也非 root 的節點,或稱作 branch,如上述例子中的H(H(A) + H(B)) 和 H(H(C) + H(D))。
index:指某個 leaf 所在的位置,leaf = leaves[index],index 如果是偶數,leaf 一定在左邊,如果是奇數 leaf 一定在右邊。
Merkle Proofs
Merkle Proofs 的重點就是要證明資料有沒有在樹上。
如何證明?就是提供要證明的 leaf 以及其相對應的路徑 (path) ,經過計算後一旦能夠產生所需要的 root,就能證明這個 leaf 在這顆樹上。
因此這類要判斷資料有無在樹上的證明,類似的說法有:proving inclusion, proving existence, or proving membership。
這個 proof 的特點在於,我們只提供 leaf 和 path 就可以算出 root,而不需要提供所有的資料 (leaves) 去重新計算整顆 Merkle Tree。這讓我們在驗證資料有沒有在樹上時,不需要花費大量的計算時間,更棒的是,這讓我們只需要儲存 root 就好,而不需要儲存所有的資料。
在區塊鏈上,儲存資料的成本通常很高,也因此 Merkle Tree 的設計往往成為擴容上的重點。
我們知道 n 層的 Merkle Tree 可以存放 2**n 個葉子,以 Tornado Cash 的設計來說,他們設定 Merkle Tree 有 20 層,也就是一顆樹上會有 2**20 = 1048576 個葉子,而我們用一個 root 就代表了這 1048576 筆資料。
接續上段的例子,這顆 20 層的 Merkle Tree 所產生的 Proof ,其路徑 (path) 要從最底下的葉子 hash 幾次才能到達頂端的 root 呢?答案就是跟一棵樹的 levels 一樣,我們要驗證 Proof 所要遞迴的次數就會是 20 次。
在實作之前,我們先來看 MerkleTree 在 client 端是怎麼調用的,這有助於我們理解 Merkle Proofs 在做什麼。
基本上一個 proof 的場景會有兩個人:prover 與 verifier。
在給定一筆 leaves 的樹,必定產生一特定 root。prover 標示他的 leaf 在樹上的 index 等於 2,也就是 leaves[2] == 30,以此來產生一個 proof,這個 proof 的內容大致上會是這個樣子:
對 verifier 來說,他要驗證這個 proof,就是用裡面的 leaf 去一個一個與 pathElements 的值做 hash,上述就是 H('30', 40) 後得出 node,再 hash 一次 H('19786...', node) 於是就能得出這棵樹的 root。
重點來了,這麼做有什麼意義?它的巧思在於對 verifier 來說,他只需要儲存一個 root,由 prover 提交證明給他,經過計算後產生的 root 如果跟 verifier 儲存的 root 一樣,那就證明了 prover 所提供的資料確實存在於這個樹上。
而 verifier 若不透過 proof ,要驗證某個 leaf 是否存在於樹上,也可以把 leaves = [10, 20 ,leaf ,40]整筆資料拿去做 MerkleTree 的演算法跑一趟也能產生特定的 root。
但由 prover 先行計算後所提交的 proof,讓 verifier 不必儲存整批資料,也省去了大量的計算時間,即可做出某資料有無在 Merkle Tree 上的判斷。
Sparse Merkle Tree
上述能夠證明資料有無在樹上的 Merkle Proofs 是屬於標準的 Merkle Tree 的功能。但接下來我們要實作的是稍微不一樣的樹,叫做 Sparse Merkle Tree。
Sparse Merkle Tree 的特色在於除了 proving inclusion 之外,還可以 proving non-inclusion。也就是能夠證明某筆資料不在某個 index,例如 H(A) 不在 index 2 ,這是一般 Merkle Tree 沒辦法做到的。
而要做到 non-membership 的功能其實也不難,就是我們要在沒有資料的葉子裡補上 zero value,或是說 null 值。更多內容請參考:What’s a Sparse Merkle Tree。
實作細節
本節將完整的程式碼分成三個片段來解釋。
首先,這裡使用的 Hash Function 是 MiMC,主要是為了之後在 ZKP 專案上的效率考量,你可以替換成其他較常見的 hash function 例如 node.js 內建 crypto 的 sha256:
crypto.createHash("sha256").update(data.toString()).digest("hex");
這裡定義簡單的 Merkle Tree 介面有 root, proof, and insert。
首先我們必須先給定這顆樹的 levels,也就是樹的高度先決定好,樹所能容納的資料量也因此固定為 2**levels 筆資料,至於要不要有 defaultLeaves 則看創建 Merkle Tree 的 client 自行決定,如果有 defaultLeaves 的話,constructor 就會跑下方一大段計算,對 default 資料開始作 hash 去建立 Merkle Tree。
如果沒有 defaultLeaves,我們的樹也不會是空白的,因為這是顆 Sparse Merkle Tree,這裡使用 zeroValue 作為沒有填上資料的值,zeros 陣列會儲存不同 level 所應該使用的 zero value。假設我們已經填上第 0 筆與第 1 筆資料,要填上第 2 筆資料時,第 2 筆資料就要跟 zeros[0] 做 hash,第 2 筆放左邊, zero value 放右邊。
我們將所有的點不論是 leaf, node, root 都用標籤 (index) 標示,並以 key-value 的形式儲存在 storage 裡面。例如第 0 筆資料會是 0–0,第 1 筆會是 0–1,這兩個 hash 後的節點 (node) 會是 1–0。假設 levels 是 2,1–0 節點就要跟 1–1 節點做 hash,即可產出 root (2–0)。
後半部份的重點在於 proof,先把 proof 和 traverse 看懂,基本上就算是打通任督二脈了,之後有興趣再看 insert 和 update。
sibling 是指要和 current 一起 hashLeftRight 的值…也就是相鄰在兩旁的 leaf (or node)。
到這裡程式碼的部分就結束了。
最後,讓我們回到一開始 client 調用 merkleTree 的例子:
以及 proof 的內容:
前面略過了 proof 裡頭的 pathIndices,pathIndices 告訴你的是當前的 leaf (or node) 是要放在左邊,還是放在右邊,大概是這個樣子:
if (indices == 0) hash(A, B);if (indices == 1) hash(B, A);
有興趣的讀者可以實作 verify function 看看就會知道了!
原始碼
TypeScript from gist
JavaScript from tornado-core
參考
Merkle Proofs Explained
What’s a Sparse Merkle Tree?
延伸:Verkle Tree
Merkle Tree in JavaScript was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
「update a 欄 位 到b 欄 位」的推薦目錄:
- 關於update a 欄 位 到b 欄 位 在 Taipei Ethereum Meetup Facebook 的精選貼文
- 關於update a 欄 位 到b 欄 位 在 Taipei Ethereum Meetup Facebook 的最讚貼文
- 關於update a 欄 位 到b 欄 位 在 周慧敏 Vivian Chow Facebook 的最佳貼文
- 關於update a 欄 位 到b 欄 位 在 [情報] 台中銀股利0.25 股票0.5 - 看板Stock - 批踢踢實業坊 的評價
- 關於update a 欄 位 到b 欄 位 在 Re: [SQL ] trigger 如何判斷欄位值- 看板Database - PTT數位 ... 的評價
- 關於update a 欄 位 到b 欄 位 在 [已解決] 請教在MySQL 資料庫批次更新欄位的SQL 語法 的評價
update a 欄 位 到b 欄 位 在 Taipei Ethereum Meetup Facebook 的最讚貼文
📜 [專欄新文章] Crosslink 2019 Taiwan|以太坊 2.0 的未來藍圖及挑戰
✍️ Frank Lee
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Danny Ryan(source: Crosslink 2019 Taiwan)
十月底於台北矽谷會議中心舉行的 Crosslink 2019 Taiwan,吸引了來自世界各地的區塊鏈愛好者們齊聚一堂。第一天的議程,邀請到了以太坊基金會 (Etherium Foundation, EF) 的核心研究員 Danny Ryan,會中分享了以太坊 2.0 (Ethereum 2.0)目前的研究方向以及遇到的挑戰,演講的內容主要包含了以太坊 2.0 的架構,新的分片提案,執行環境 (Execution Environments, EE)以及雙向橋接 (Two-Way Bridge)等議題。
一、以太坊 2.0 的架構
以太坊 2.0 架構(source: Crosslink 2019 Taiwan)
第零階段(Phase 0)
在 以太坊 1.0 (Ethereum 1.0) 中,使用 工作證明(Proof of Work, PoW) 作為 共識機制 (Consensus),並藉此產生新的區塊。為了要減少工作證明產生新區塊時,所需要的大量算力,以及所花時間過長的問題,以太坊 2.0 將改為 權益證明 (Proof of Stake, PoS) 作為產生新區塊的共識機制,以太坊 2.0 PoS 創世區塊 (Genesis Block) 預計會在 2020 年 1 月 3 日產生。
第零階段會建立信標鏈(Beacon Chain),信標鏈就是以太坊 2.0 系統層級的鏈,當從以太坊 1.0 移轉到以太坊 2.0 時,信標鏈扮演著非常重要的角色,它是整個系統的基礎。
一旦第零階段完成,將會有兩個使用中的以太坊鏈。以太坊 1.0 鏈(目前所使用的 PoW 主鏈)以及以太坊 2.0 鏈(新的信標鏈)。在這個階段,使用者在 1.0 鏈把以太幣鎖到合約裡以註冊公鑰, 2.0 鏈會承認合約內註冊的公鑰。但是,他們無法將該以太幣遷移回去以太坊 1.0 鏈上面,為了要執行信標鏈,你會需要一個信標鏈的客戶端。目前,許多團隊正在開發這些客戶端。
第一階段(Phase 1)
第一階段會加入分片鏈(Shard Chains),在這個階段主要專注於分片鏈的資料結構,以及其有效性(Validity)和共識性(Consensus),分片鏈在這階段只當作資料鏈,並不會指定分片鏈狀態執行(State Execution) 或帳戶餘額(Account Balances)。這比較像是對分片結構進行測試,而不是嘗試利用分片來對信標鏈進行擴展。在這階段,信標鏈會把分片鏈的區塊(Block), 當作沒有結構或意義的位元集合(Collections Of Bits)。以太坊 1.0 和以太坊 2.0 仍將同時存在,並且在以太坊 2.0 鏈上進行測試和遷移。
這個階段分片鏈會與信標鏈交聯(Crosslinks) ,每個分片的當前狀態 — “結合資料根(Combined Data Root)”,會定期記錄在“信標鏈”區塊中,作為交聯。信標鏈區塊完成後,相應的分片區塊(Shard Block)將被視為已完成,其他分片知道它們可以依靠這些區塊進行跨分片交易。
交聯是委員會(Committee)的一組簽名(Signatures),證明了分片鏈中的某個區塊,可以包含在信標鏈中。交聯是信標鏈”理解”分片鏈更新狀態的主要方式。交聯還用作異步跨分片通信的基礎結構。
信標鏈在每個時段(Slot)中的每個分片,隨機選擇分片驗證者(Shard Validators) ,分片驗證者只是用來在每個區塊的內容上達成一致,他們通過交聯證明分片的內容和狀態,分片中包含什麼內容都沒有關係,只要所有委員會都達成共識,並定期更新分片上的信標鏈即可。
第二階段(Phase 2)
第二階段會將所有功能開始結合在一起,在第二階段,會完成分片化,分片鏈從簡單的數據容器過渡到結構化鏈狀態,並將重新引入智能合約。每個分片將管理基於 eWASM(Ethereum flavored WebAssembly) 的虛擬機。它會支援帳戶(Accounts)、合約(Contracts)、狀態(State),以及 Solidity 中我們熟悉的其他抽象化,預計在第二階段之前或第二階段開發時,大家熟悉的工具(例如 Truffle, Solc, Ganache)需要轉換成支持 eWASM 的版本,以太坊 1.0 及以太坊 2.0 可藉由雙向橋接來互通,會有可擴展的 Layer 1 執行,藉由無狀態執行,來提高執行速度。
二、新的分片提案
新的分片提案(source: Crosslink 2019 Taiwan)
以太坊 2.0 原提案所運作的機制,是以每個時期 (Epoch) 為單位,來進行交聯的動作,每個鏈上有1024 個片 (Shards),當需要跨分鏈交易(Tx)時,由於是每個時期進行交聯,會有較大的延遲時間;新提案更新為每個時段都進行交聯的動作,並減少片(Shards)的數量為 64個,來降低跨分片(Cross-Shard)交易時的延遲時間,每個時段都進行跨分片交易。
新提案的優點
對於以太坊 2.0 新提案的優點,首先新提案的片 (Shards)數量由 1024 個降至 64 個,降低了運算的複雜度,因為跨鏈時間從一個 epoch 降到一個 slot ,時間縮短第一個好處是給 DApp 開發者及使用者更好的體驗。第二個好處是以往需要手續費市場(Complex Fee Market) 及樂觀狀態(Optimistic State)這兩種複雜的跨鏈交易解決方案,現在不需要了。
新提案的交易
新提案只需要比之前的提案更少的片 (Shards),就可以啟動交易,可能會有更長的分片時段(12s),更大的分片區塊(Shard Block),目前更新到第零階段 ,第零階段測試網(Testnets)的測試,可能會有所延遲 ,新提案減少了第零階段發布所需的時間。
目前的想法
希望能給開發者及使用者更好的體驗,使用較大的分片區塊(Shard Block),來改進資料可用性,以及要降低開發延遲和第零階段發布所需花費的時間。
三、執行環境
以太坊 1.0 簡易架構圖(source: Crosslink 2019 Taiwan)
在之前設計的以太坊 2.0 和以太坊 1.0 中,狀態在共識機制裡,扮演著非常重要的角色,共識機制會隨時去讀寫所有的狀態,不管是執行的概念、交易的概念、帳戶的概念、樹狀結構的概念、以及所有在資料結構中的概念,都深深地融入共識中。
上圖是以太坊 1.0 的簡易架構圖,在圖中我們可以看到共識機制及一條鏈,共識機制裡包含了狀態及一個執行引擎,狀態裡包含了狀態樹,在這裡的執行引擎使用硬編碼規則,裡面包含了執行交易、帳戶模型和帳戶結構,我們可以看到圖的右邊有一條鏈,鏈上面有交易資料,在以太坊 1.0 中,我們會在交易資料上執行共識機制,去修改和更新狀態。
執行環境是一個單獨的虛擬機器,在以太坊 1.0 中,會有一個特定的帳戶模型(Account Model),以及事先定義好的操作碼 (Opcodes),礦工機制 (Gas Mechanisms)和狀態根(State Root),以太坊虛擬機 (Ethereum Virtual Machine, EVM) 就是一種特定的執行環境。
如果遵循 EIP(Ethereum Improvement Proposals) 的建議,開發者總是在要求新的操作碼,或著是更改礦工成本(Gas Cost)來支援他們的應用,像是 Plasma 和 Zkrollup 這樣的例子有很多,這樣就會需要修改 EVM 1.0 的執行環境 ,才能支援到他們的應用程式(DApp)。
但是在以太坊 2.0 的第二階段中,我們可以支持多個執行環境。 也可以有多個狀態根,不同的帳戶模型等。舉個例子,你可以定義一個臉書幣執行環境 (Libra EE),以便在以太坊 2.0 上運行 Libra。 或者,您可以定義一個比特幣執行環境 (BitCoin EE),這樣就可以在以太坊 2.0 上運行比特幣。
以太坊 2.0 簡易架構圖(source: Crosslink 2019 Taiwan)
在以太坊 2.0 簡易架構圖中我們可以看到狀態根, 它可能是 32 Bytes 的 Blob,上面有 WASM 的執行碼 (Execution Code),可以在使用者層級中去做細部設定。圖片右邊有一個鏈,鏈上有一般的交易資料以及見證(Witnesses),見證實際上顯示在資料庫的區塊中,你需要針對該狀態而不是資料庫執行該筆交易,而且還需要證明資料對於當前狀態根是有效的。舉個例子,如果我們要在帳戶 A 和帳戶 B 之間傳遞數值,假設從帳戶 A 移動 5 以太幣 到帳戶 B ,我們不能直接說帳戶和餘額 (Balance) 是確實可用的,在過程中,我們需要加入見證資料(Witness Data),來證明兩個帳戶當前的狀態,當執行碼正在執行交易資料時, 狀態根可以修改和更新狀態樹。
執行環境並不是共識機制預先定義好的,他可以在使用者層級上去做新增,我們也可以把以太坊 1.0 複製一份到以太坊 2.0 的執行環境中,將現有的狀態根放入EVM 直譯器,用梅克爾見證驗證器(Merkle Witness Verifier)來當作他的執行碼。
在原先的提案中,狀態和共識息息相關,且執行帳戶和共識中包含了狀態樹結構;而在新的提案中,執行環境為無狀態模型(Stateless Model),高度抽象化的,並且它的可擴展性,相較原先的提案高出非常多。
執行環境的優點
執行環境有許多優點,相較於舊系統,它也許可以更快地將產品推向市場,因為我們不必等到核心共識推出之後,才研究並發展這個概念,在 Layer 1 會有更少的阻礙,它可以在各種應用上,使用具高擴展性及資料可用性的執行引擎,所以未來會長期使用這個核心基礎層。
執行環境的設計完成,讓以太坊 1.0 到以太坊 2.0 的遷移,有了更清楚的方向,使用執行環境比較不會有技術隨時間遷移而過時的問題產生。
執行環境交易
對於執行環境交易,開發者及使用者可能會覺得太抽象,對什麼是執行環境感到困惑,像是這一層加了什麼?應該在這一層做什麼?誰應該寫執行環境?而且相關的開發規範會趨向更嚴格的形式。
虛擬機可能會有潛在的碎片化問題,進而影響到交易速度。
目前的想法
目前所有的研究都是正向發展的,還有充裕的時間,嘗試並更好地了解設計空間,未來會多花一些時間,在建立更好的執行環境通訊機制上面。整體來說,現階段的進度,對於未來是重要的里程碑。
四、雙向橋接
最後一個主題,主要討論開發雙向橋接是否是值得的?團隊可能可以在什麼時間點,來去做雙向橋接?
單向橋接示意圖(source: Crosslink 2019 Taiwan)
講者先前提過的提案中,以太坊 2.0 最初有一個單向橋接,所以你可以從以太坊 1.0 轉換到 以太坊 2.0,但是最初的架構不允許回傳,這主要是出於幾個原因,這需要我們將以太坊 1.0 的發展 與 以太坊 1.0 和以太坊 2.0 的硬分叉緊密結合,並把兩個系統置於互相影響的風險之中,因此團隊認為以太坊 2.0 在發布且穩定之前,將兩邊緊密耦合是不明智的。
單向橋接的問題
月初在日本大阪舉行的 Devcon 5 上,橋接的問題受到了廣泛的討論,原提案的單向橋接(One-Way Bridge)模式,會有驗證者流動性的問題,而且更重要的是,它可能會引發以太坊 1.0 和以太坊 2.0 之間的可替代性問題,如果我們允許以太坊 2.0上的流動性,那麼某種形式的轉移機制,就會在將以太坊 1.0 分叉到以太坊 2.0 之前,或著是在雙向橋接之前產生,交易所中很可能會同時有兩個幣,團隊和整個驗證者社區都很擔心這個問題,目前正在找尋減輕這個問題的方法。
另外也希望鼓勵大家,在這些早期階段進行驗證,但是在早期階段進行驗證,肯定會有很高的風險,因為存在未知的鎖定期,因此也希望找到方法減輕這種風險。
雙向橋接
雙向橋接示意圖(source: Crosslink 2019 Taiwan)
雙向橋接目前可能的路線有兩條,一種是在以太坊 1.0 上面,建立以太坊 2.0 的輕節點;另一種是在以太坊 1.0 上運作以太坊 2.0 的全節點。
路線A: 在以太坊 1.0 上,建立以太坊 2.0 輕節點
路徑A示意圖(source: Crosslink 2019 Taiwan)
這個路線需要在實際的 EVM 中支援 BLS-12–381,會花費很多開發時間,而且它只提供輕量客戶端 (Light-Client) 層級的安全性。當驗證者在 2.0 鏈上產生提款交易的收據時,我們會拿到以太坊 2.0 的輕量客戶端證明,一但收收據的區塊在以太坊 2.0 上敲定了,你就可以在以太坊 1.0 的合約上提款。不過,這可能不是團隊最終選擇的路線。
路線B:在以太坊 1.0 上,運行以太坊 2.0 的全節點
路徑B示意圖(source: Crosslink 2019 Taiwan)
第二種路線,會在以太坊 1.0 的節點上,運行以太坊 2.0 的全節點,這個路線允許我們使用敲定性機制,因此,我們不僅可以使用這種機制,來促進以太坊 1.0 和以太坊 2.0 之間的轉移,我們也可以利用驗證者的安全性,來保護以太坊 1.0 鏈,我認為大家對此感到非常興奮,這通常被稱為“敲定性小工具提案(Finality Gadget Proposal)”。
但是還是需要一種機制,去輸出以太坊 2.0 狀態根在以太坊 1.0 上,所以有一些以太坊 2.0 社群的討論,在研究如何實作它,可能會包含礦工機制。
輸出以太坊 2.0 狀態根的另一個優勢,是以太坊 1.0 有穩固的機制可以實現它,以及同時擁有以太坊 2.0 的高擴展性及資料可用性,可以做一些有趣的應用,像是 ZK Rollup 和 Optimistic Rollup。
雙向橋接的優點
如果你在交易所中,列出以太坊 1.0 以太幣和以太坊 2.0 以太幣,它們的價格應該一樣。 如果不一樣,你可以用較低的價格買一個以太幣,把他發送到橋上,然後以較高的價格獲得另一種以太幣,並把它出售。 這種套利會使它們的價格保持不變,這樣會讓用戶,驗證者和開發人員感到困惑,雙向橋接可以防止兩邊的貨幣藉由套利的形式,來互相轉換。
雙向橋接的交易
但是還是有一些權衡在這裏,儘管對以太坊 2.0 的設計非常有信心,團隊還是希望在影響到以太坊 1.0 的安全性和風險狀況之前,先在生產環境中得到驗證。
雙向橋接是一種緊密耦合的共識機制,對於兩邊鏈的攻擊及產生的問題,都會影響到另一邊的鏈,協定的開發勢必會非常煩瑣,我們需要考慮到每個協定的安全性,如果我們越早開發協議,那麼我們實際上的進度就越少,當每個障礙隨著時間發展,它們就會相互阻礙,這讓以太坊 1.0 在這一點上的開發速度比以太坊 2.0 慢得多,因為實際用戶群存在很多擔憂,並且需要大量的協調,才能在我們的生產網絡上獲得硬分叉。
所以,如果我們越早將這些東西連在一起,就可能會減慢以太坊 2.0 的開發和分叉週期,並且這增加了一些額外的開銷,換句話說,驗證我們可以鏈接客戶端的開銷是相對的。
目前的想法
我們應該會在加入驗證人流動性之前啟用橋樑,但是會等到第一階段的產品穩定之後再開放;同樣的,有很多相關的研究都在同時進行,這可能會影響到,何時完成這個操作。
名詞解釋:
EIP(Ethereum Improvement Proposals):EIP 是以太坊平台的標準,其內容包含了核心協議的規範,客戶端 API 以及合約標準。
epoch :在以太坊 2.0 中,epoch 指的是時長 6.4 分鐘的時間單位,每個epoch 包含64個 slots。
Slot(時段):每個時段為 6 秒,不一定每個時段都能產生區塊,而epoch 中最後一個 slot 稱為邊界時段 (Boundary Slot) ,或稱為檢查點 (Checkpoint)。
Solidity:Solidity 是一種合約導向的語言,主要用來開發智慧合約。
Consensus (共識機制):共識機制是區塊鏈為了在各節點間達成共識,所開發的演算法。
Validator 驗證者:驗證區塊的節點,由信標鏈在每個時段(Slot)為每個 片 (Shards)隨機產生。
Gas:交易所需的費用,當 Gas 消耗完時,智慧合約會終止並進行 Rollback。
EVM(Ethereum Virtual Machine):EVM 中文為以太坊虛擬機,是一種輕量級的虛擬機環境,Eth 1.0 中智能合約的運行環境為 EVM。
Dapp(Decentralized App):在以太坊中,基於智能合約的應用都稱為去中心化的應用程序,即 Dapp(Decentralized App)。
ether(以太幣):以太坊的貨幣名稱。
Finality(敲定性):「敲定性」是 Casper 中的概念,是一種透過驗證者投票,在鏈上產生不可回朔(Rollback)的檢查點的機制。
Libra:臉書提出的加密貨幣,預計於 2020 年發行。
Merkle Tree:Merkle Tree 由計算機科學家 Ralph Merkle 所提出,中譯為雜湊樹,因為是由雜湊函式形成的樹。
Reference: [Ethereum Improvement Proposals](https://eips.ethereum.org/)
Reference: [Two-way bridges between eth1 and eth2](https://ethresear.ch/t/two-way-bridges-between-eth1-and-eth2/6286)
Reference: [Ethereum 2.0 (Serenity) Phases](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/#phase-2-state-execution)
Reference: [ethfans](http://ethfans.org/)
Reference: [eth2 quick update](https://blog.ethereum.org/2019/10/23/eth2-quick-update/)
Thanks to Danny Ryan, Chih Cheng Liang, Juin Chiu, Yahsin Huang, and Jerry Ho
Crosslink 2019 Taiwan|以太坊 2.0 的未來藍圖及挑戰 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
update a 欄 位 到b 欄 位 在 周慧敏 Vivian Chow Facebook 的最佳貼文
第二期《香港動物報》雜誌實體版七月初上架啦!
update ! 第二期《香港動物報》實體版有得取閱了!
大家可以到SPCA及NPV免費取閱。大家不妨share下。
本報網站為:http://www.hkanimalpost.com/
fb: https://www.facebook.com/hkanimalpost/
ig:香港動物報 / hkanimalnews
歡迎贊助/捐款支持本報營運:
香港動物報的戶口號碼為: HSBC 165-755828-838
Hong Kong Animal Post Company Limited
可領取地點: (Update at 30/6/ 18:50pm )
【港島】
SPCA港島總部 (灣仔運盛街5號)
Pets Central (北角渣華道66號地下)
森記書局 (北角英皇道193號英皇中心地庫19號)
跑馬地獸醫診所 (跑馬地地昌明街6號)
Puff n Fluff (跑馬地源遠街9號)
Dogotel & Spa Boutique (跑馬地奕蔭街21號地下)
Dogger (堅尼地城吉席街98號地下)
栢雅動物診所 (堅尼地城吉席街9-15號吉利樓地下)
雅各動物醫院 (西營盤第二街68-80號地下)
研康獸醫診所 (西營盤第三街192號福安樓地下1號鋪)
方舟動物醫院 (西營盤水街25-35號樂新大廈地下及1樓1號鋪)
Dog Cheers (柴灣祥利街7號萬峰工業大廈4C)
香港獸醫診所 (灣仔) 灣仔堅彌地街12A
銅鑼灣動物醫院 (銅鑼灣威菲路道29號 )
Chris & Nicola’s Animal Hospital夏利維動物醫院 (天后永興街37號地下)
東區動物醫院(筲箕灣道256號地下)
【九龍】
~旺角及太子
NPV獸醫診所 (太子基隆街24號)
NPV獸醫診所 (太子基隆街29號)
NPV獸醫診所 (太子基隆街77號)
NPV獸醫診所 (太子基隆街79號)
毛國界動物醫院 (旺角鐵樹街21號)
香港兔友協會 (旺角塘尾道60-62號福康工業大廈502室)
麥花臣動物診所 (旺角洗衣街26號興業樓地下)
九龍貓醫院 (旺角砵蘭街430號利聯大廈地下)
~何文田
自由道獸醫診所 (何文田自由道1號C鋪)
仁安獸醫診所 (何文田自由道9號地下)
何文田動物診所 (何文田梭椏道27號地下)
加多利動物醫院 (何文田梭椏道23號B地下)
港九寵物醫院 (何文田梭椏道13號地下)
~紅磡及土瓜灣
紅磡獸醫診所 (紅磡民泰街30號地下)
澳洲獸醫醫院 (紅磡民泰街29號A地下)
Fantastic dogs(土瓜灣美善同道8號)
~九龍城
九龍動物醫院 (九龍城啟德道50號地下)
~深水埗
亞太動物醫院 (深水埗大南街 79 號地下)
楓樹獸醫診所 (深水埗楓樹街9-13號華楓樓地下)
~美孚
美孚獸醫醫院 (美孚新村第五期蘭秀街7號B地下N4鋪 )
~觀塘
Ro-La小小動物民宿 (觀塘駿業里10號業運工業大廈6樓E1室)
東九龍動物醫院 (觀塘通明街50號康寧大廈地下)
觀塘動物醫院 (觀塘聯安街35號地下)
Three Little Meow (觀塘興業街16-18號美興工業大廈A座9樓9B室)
香港兩棲及爬蟲協會 (觀塘鴻圖道33號王氏大廈216室)
【新界】
~大埔
仁德動物醫院 (寶鄉街42號地下)
寶湖動物醫院 (廣福道149-155號地下)
日本動物醫院 (廣福道114號廣福樓2A舖)
~西貢
亞洲獸醫診所 (西貢萬年街28號地下)
好朋友動物醫院 (新界西貢海傍街6號地下)
Pets Central 西貢診所 (新界西貢宜春街66號4號鋪)
西貢動物醫院 (西貢萬年街30號地下)
黎昌生獸醫診所 (將軍澳唐俊街11號寶盈花園地下S4和S4E鋪)
坑口獸醫診所 (將軍澳坑口村第4座)
~荃灣及葵涌
香港拯救貓狗協會 (葵涌健康街4-6號飛亞工業中心907室)
活泉動物醫療中心 (荃灣荃樂街1號荃樂大廈地下)
荃灣獸醫寵物醫院 (荃灣沙咀道168號地下)
享和動物醫療中心 (荃灣沙咀道136-138號地下 )
享和珍禽異獸醫療中心 (新界荃灣享和街84號安豐大厦地下)
賓紛會 (荃灣沙咀道29-35號科技中心505室)
~沙田區
綠十字寵物診所 (沙田正街希爾頓中心5B地下)
沙田圍獸醫診所 (沙田崗背街9-11號全輝中心A座地下10號舖)
大圍珍禽異獸及寵物醫院 (大圍積信街69-75號地下C-D舖)
聯邦動物診所 (大圍積存街46號)
俊康動物醫療中心 (大圍積存街54號)
沙田動物診所 (大圍積存街74-76號)
西沙路動物醫院 (馬鞍山新港城廣場地下6-7號舖)
動物醫療中心 (馬鞍山福安花園2&17號地舖)
~上水
北區動物診所 (上水新成路111號地鋪)
上水寵物診所 (上水新成路6號)
~屯門
康和動物醫療中心 (屯門置樂青海圍8號屯景大廈地下E1舖)
Dogville (屯門彩華花園地下6號鋪)
Pet Honey (屯門彩華花園地下5號鋪)
犬の樂園 (屯門置樂嘉喜利大廈4號)
狗寶寶寵物用品店 (屯門置樂花園地下127號舖)
東方獸醫診所 (屯門良田村107-8號地下)
狗狗鎮寵物美容屋 (屯門青山公路91號地段竹苑6號舖)
彩虹獸醫診所 (屯門良田村58號地下)
昕霞專業寵物美容中心(屯門湖秀街2號悅湖商場地舖73 102-103號)
Pat’s Pet Grooming (屯門藍地豫豐花園福亨村路8號地舖)
景峰動物醫療中心 (屯門新墟新墟井財街21號協邦大廈地下6-7號舖)
~元朗
新太陽動物醫務所(元朗鳳攸北街9A昌威大廈2號舖)
寶寶寵物美食屋(元朗鳳攸北街32號順豐大廈地下)
PetShopBoys(元朗鳳攸北街昌威大廈9號9A地舖)
東方獸醫診所(元朗鳳攸北街昌威大廈26-27號地下)
錦田動物醫院 (元朗錦田錦田市108號地下 )
優活動物診所 (元朗鳳攸東街9號好順意大廈A座地下36及37號)
專一動物診所 (元朗鳳翔路69號建輝大廈19號地下 )
錦綉動物診所 (元朗馬田村201號 )
仁愛獸醫診所 (安寧路110-136A號好景樓地下12號 )
博愛動物醫院 (元朗炮仗坊)
卡拿素動物醫院 (元朗教育路87-99號鴻發大廈地下G-H鋪)
元朗獸醫動物及珍禽異獸醫院 (元朗屏會街25號福順樓地下2號鋪)
~馬灣
I Care Pet Shop (馬灣鋪田寮新村72號地下)
Dog.com (馬灣大街村中241號地下)
----------------------------------------------------------------------------
第二期《香港動物報》面世啦!
各位讀者:
感謝大家一直支持!在資源緊拙、人力有限情況下,幾經辛苦,《香港動物報》第二期實體雜誌終於能夠再次出刊!這期內容一如以往,十分豐富,我們有幸邀請一向愛動物的周慧敏小姐接受訪問,分享如何與動物相處,更首次分享她的救動物經歷。
今期我們探討許多貓狗主人常遇的問題,包括狗狗居住權、毛小孩抑鬱如何處理等。除此,我們的皇牌欄目#kakato x《情常在》今期會報道一位72歲小伯司機每天穿梭公路救狗的感人故事。內容豐富,數之不盡。
在此感激 #lush #kakato #不願透露姓名的捐款者默默支持,還有一眾《動物名人說》作者的撰文,令我們得以繼續出刊!
第二期《香港動物報》將於七月初於多個地點免費供讀者取閱。有關領取地點,本報即將公佈,請大家密切留意。
感謝各位讀者一直為動物權益發聲,正因為有您們同行,我們更有動力繼續走下去,繼續為爭取動物權益努力。我們亦正計劃眾籌下期經費,期望獲得大家支持。
請大家幫忙廣傳開去及密切留意我們專頁!
#香港動物報第二期 #內容精彩 #周慧敏 #麥志豪 #愛護動物協會 #毛孟靜 #鄺俊宇 #楊雪盈 #動物界 #支持領養 #狗狗住屋權
周慧敏 Vivian Chow Chi Ho Mak NPV 非牟利獸醫服務協會 (Non-Profit Making veterinary services society Ltd) Npv流浪動物醫療基金 SPCA (HK) 香港愛護動物協會 鄺俊宇 Roy Kwong Claudia Mo/毛孟靜 楊雪盈 Clarisse Yeung Chan Ka Ming Cheung Yuen Man LUSH Hong Kong Kakato Wendy Wong Choi Yiu
update a 欄 位 到b 欄 位 在 Re: [SQL ] trigger 如何判斷欄位值- 看板Database - PTT數位 ... 的美食出口停車場
01/05 21:23 · 1 · 感謝D大~想問一下這句後面插入的值update是什麼意思? ; 01/05 21:41 · 2 · ('UPDATE ''' + @strOldData + ''' TO ''' ; 01/05 23:45 · 3 · 那個只是寫個字串到 ... ... <看更多>
update a 欄 位 到b 欄 位 在 [已解決] 請教在MySQL 資料庫批次更新欄位的SQL 語法 的美食出口停車場
現在希望透過SQL 語法,將資料表B「alias」欄位資料, ... 自己沒有資料庫相關知識,上網查詢語法知道可以透過UPDATE 做更新,但是看到更新單筆資料的 ... ... <看更多>
update a 欄 位 到b 欄 位 在 [情報] 台中銀股利0.25 股票0.5 - 看板Stock - 批踢踢實業坊 的美食出口停車場
-
1.請符合以下文章格式,違者4-1刪除
2.本分類提供以下幾種文章搬運
a. 每日交易數據相關:每日法人買買超、融資券、交易量...
b. 公司重要訊息相關:營收、股利、股東會懶人包、法說會內容整理...
c. 現有資訊整理相關:殖利率排名、金融股獲利分布、
3.請詳閱板規參考相關規定
-—按ctrl+y可刪除以上內容。—
1. 標題:台中銀110年度盈餘分派案
2. 來源:goodinfo (公司名、網站名)
3. 網址:https://goodinfo.tw/tw/StockAnnounceDetail.asp?STOCK_ID=2812&CLAIM_TIME=
2022%2F02%2F24+16%3A05%3A48 (請善用縮網址工具)
4. 內文:
1. 董事會擬議日期:111/02/24
2. 股利所屬年(季)度:110年 年度
3. 股利所屬期間:110/01/01 至 110/12/31
4. 股東配發內容:
(1)盈餘分配之現金股利(元/股):0.25000000
(2)法定盈餘公積發放之現金(元/股):0
(3)資本公積發放之現金(元/股):0
(4)股東配發之現金(股利)總金額(元):1,134,630,140
(5)盈餘轉增資配股(元/股):0.50000000
(6)法定盈餘公積轉增資配股(元/股):0
(7)資本公積轉增資配股(元/股):0
(8)股東配股總股數(股):226,926,028
5. 其他應敘明事項:
無
6. 普通股每股面額欄位:新台幣10.0000元
買20送1 真香 世界奇觀快蓋好了
伐伐伐伐伐木工
(手機排版 有歪掉回家用電腦調 傷眼抱歉)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.9.203.248 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Stock/M.1645692727.A.A18.html
... <看更多>