📜 [專欄新文章] 區塊鏈管線化的效能增進與瓶頸
✍️ Ping Chen
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
使用管線化(Pipeline)技術可以提升區塊鏈的處理效能,但也可能會產生相應的代價。
Photo by tian kuan on Unsplash
區塊鏈的擴容方案
說到區塊鏈的效能問題,目前討論度最高的應該是分片(sharding)技術,藉由將驗證者分成多組的方式,可以同時分別處理鏈上的交易需求,即使單分片效能不變,總交易量可以隨著分片/驗證者集的數量線性增加。
除了分片,另一個常用來提升程式效能的方案是將計算步驟拆解,以流水線的方式將複雜的運算攤平,降低系統的閒置時間,並大幅提升工作效率。為了達到管線化預期的目的,會需要先知道系統的瓶頸在哪。
區塊鏈的效能瓶頸
熟悉工作量證明設計哲學的人應該會知道,區塊鏈之所以需要挖礦,並不是為了驗證交易的正確性,而是要決定交易的先後順序,從而避免雙花和帳本分裂的發生。可以說,區塊鏈使用低效率的單線程設計,並付給礦工高額的成本,都只為了一件事,就是對交易的全局排序產生共識。
在這樣的基礎之上,區塊鏈在一段時間內可以處理的交易數量是有限的,這之中包含許多方面的限制,包括 CPU 效能、硬碟空間、網路速度等。其中,關於 TPS(每秒交易數) 提升和對硬體的要求大致上是線性增加的,但在設計共識演算法時,通訊複雜度常是平方甚至三次方的關係。
以現在的目標 TPS 來說,處理交易和生成一個合法的區塊並不困難,只是因為區塊鏈的特性,新區塊需要透過洪水法的方式擴散到全網路,每個節點在收到更新請求的時候都要先執行/驗證過區塊內的交易,等於整個廣播的延時會是「驗證區塊時間×經過的 hop 數量」這麼多。似乎網路越分散、節點越多,我們反而會需要降低計算量,以免讓共識不穩定。
管線化的共識機制
使用權益證明取代工作量證明算是行業發展的趨勢,除了環保或安全這些比較顯然的好處之外,權益證明對產生共識的穩定性也很有幫助。首先,權益證明在同一時間參與共識的節點數是已知的,比較容易控制數量級的邊界;其次,權益證明的出塊時間相較工作量證明固定很多,可以降低計算資源不足或閒置的機率。
相較於工作量證明是單一節點出塊,其餘節點驗證,權益證明的出塊本身就需要很多節點共同參與,瓶頸很像是從驗證轉移到通訊上。
以 PBFT 為例,每次產新區塊都需要經過 pre-prepare, prepare, commit 三個階段,你要對同意驗證的區塊簽名,還要對「你有收到某人的簽名」這件事簽名,再對「你有收到 A 說他有收到 B 的簽名」這件事簽名,過程中會有很多簽名飛來飛去,最後才能把一個區塊敲定。
為了降低每兩個區塊間都需要三輪簽名造成的延遲,後來的共識演算法包括 HotStuff 和 Casper FFG 採用了管線化的區塊驗證過程。也就是對區塊 T 的 pre-prepare 同時是對 T-1 的 prepare 和對 T-2 的 commit。再加上簽名聚合技術,出塊的開銷在複雜度等級和係數等級都降低許多。
然而,要保持管線化的區塊生產順利,需要驗證者集合固定不變,且網路通訊狀況良好。如果會經常更動驗證者集合或變換出塊的領導者,前後區塊間的相依性會是個大問題,也就是 T 的驗證者集合取決於 T-1 裡有沒有會導致刪除或新增驗證者的交易,T-1 的合法性又相依於 T-2,以此類推。
當激烈的分叉出現的時候,出塊跟共識的流水線式耦合就從優雅變成災難了。為了避免這種災難,更新的共識演算法會限制驗證者變更的時機,有些叫 epoch 有些叫 checkpoint,每隔一段時間會把前面的區塊徹底敲定,才統一讓驗證者加入或退出。到這些檢查點的時候,出塊的作業流程就會退化成原本的三階段驗證,但在大部分時候還是有加速的效果。
管線化的狀態更新
另一個可以用管線化加速的是區塊鏈的狀態更新。如前所述,現在公鏈的瓶頸在於提高 TPS 會讓區塊廣播變慢,進而導致共識不穩定,這點在區塊時間短的以太坊上尤其明顯。可是如果單看執行一個區塊內的交易所花的時間的話,實際上是遠遠低於區塊間隔的。
只有在收到新區塊的時候,節點才會執行狀態轉移函數,並根據執行結果是否合法來決定要不要把區塊資訊再廣播出去。不過其實只要給定了交易集合,新的狀態 s’ = STF(s, tx) 應該是確定性的。
於是我們有了一個大膽的想法:何不乾脆將交易執行結果移出共識外呢?反正只要大家有對這個區塊要打包哪些交易有共識,計算的結果完全可以當作業留給大家自己算吧。如果真的不放心,我們也可以晚點再一起對個答案,也就是把這個區塊執行後的新狀態根包在下個區塊頭裡面。
這就是對狀態更新的管線化,在區塊 T 中敲定交易順序但暫不執行,區塊 T+1 的時候才更新狀態(以及下一批交易)。這麼做的好處十分顯而易見,就是將原本最緊繃的狀態計算時間攤平了,從原本毫秒必爭的廣播期移出來,變成只要在下個塊出來之前算完就好,有好幾秒的時間可以慢慢來。新區塊在廣播的每個 hop 之間只要驗證交易格式合法(簽名正確,有足夠的錢付手續費)就可以放行了,甚至有些更激進的方案連驗簽名都省略了,如果真的有不合法交易混進去就在下個區塊處罰礦工/提案者便是。
把負擔最重的交易執行移出共識,光用想的就覺得效能要飛天,那代價呢?代價是區塊的使用程度會變得不穩定。因為我們省略了執行,所以對於一筆交易實際用掉多少 gas 是未知的。本來礦工會完整的執行所有交易,並盡可能的塞滿區塊空間,然而在沒有執行的情況下,只能以使用者設定的 gas limit 當作它的用量,能打包的交易會比實際的上限少。
緊接著,下一個問題是退費困難。如果我們仍然將沒用完的手續費退還給使用者,惡意的攻擊者可以透過發送 gas limit 超大,實際用量很小的交易,以接近零的成本「霸佔」區塊空間。所以像已故區塊鏈 DEXON 就直接取消 gas refund,杜絕濫用的可能。但顯然這在使用者體驗和區塊空間效率上都是次優的。
而最近推出的 smartBCH 嘗試擬了一套複雜的退款規則:交易執行後剩餘的 gas 如果小於 gas limit 的一半(代表不是故意的)就退款;如果剩餘量介於 50%-75% 可以退一半;超過 75% 推斷為惡意,不退款。乍看是個合理的方案,仔細一想會發現製造的問題似乎比解決的還多。無論如何,沒用掉的空間終究是浪費了,而根據殘氣比例決定是否退款也不會是個好政策,對於有條件判斷的程式,可能要實際執行才知道走哪條路,gas limit 一定是以高的情況去設定,萬一進到 gas 用量少的分支,反而會噴更多錢,怎麼想都不太合理。
安全考量,退費大概是沒希望了。不過呢,最近以太坊剛上線的 EIP1559 似乎給了一點方向,如果區塊的使用程度能以某種回授控制的方式調節,即使偶爾挖出比較空的區塊似乎也無傷大雅,也許能研究看怎麼把兩者融合吧。
管線化方案的發展性
考慮到以太坊已經堅定地選擇了分片的路線,比較激進的單鏈高 TPS 管線化改造方案應該不太有機會出線,不過管線化畢竟是種歷史悠久的軟體最佳化技巧,還是很有機會被使用在其他地方的,也許是 VDF 之於信標鏈,也許是 rollup 的狀態轉換證明,可以坐等開發者們表演。
倒是那些比較中心化的 EVM fork/sidechain,尤其是專門只 for DeFi 的鏈,管線化加速可以在不破壞交易原子性的前提下擴容,確實是有一些比分片優秀的地方可以說嘴,值得研究研究,但這就要看那些機房鏈們有沒有上進心,願不願意在分叉之餘也投資發展自己的新技術了。
給我錢
ping.eth
區塊鏈管線化的效能增進與瓶頸 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
tps效能 在 Taipei Ethereum Meetup Facebook 的精選貼文
📜 [專欄新文章] 給忙碌人的 EIP1559 簡史
✍️ Ping Chen
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
以太坊倫敦升級將大幅改變交易手續費的收取方式
1. 要解決的問題
交易手續費競爭
目前包括比特幣、以太坊在內的區塊鏈都有效能的限制,比特幣的 TPS(每秒交易數)是 7,以太坊大約是 15,而一旦待處理的交易數量超過區塊鏈的處理上限,負責產出區塊的驗證者(礦工)就會從中選擇手續費高的交易打包,讓「誰的交易先被處理」的問題交由市場機制解決。
這樣的設計乍看之下合理,卻會對日常使用者造成額外的認知負擔。
礦池直接告訴你目前待處理交易的手續費分佈,加深使用者的焦慮
一般來說,當我們送交易的時候都是希望越快被處理越好,但是付的錢要越少越好,所以這時候出價的策略就會變成「先看看別人都出多少」,再用略高一點點的價格贏過別人。這件事會要求使用者去「預測」區塊鏈的擁擠程度,才能用最少的錢擠進下一個區塊,徒增困擾。而且當很多人都急著發交易的時候,手續費會被無情的推高,直到多數人付不起為止,而這些爆高的手續費進到礦工口袋,在利益分配上也不是最佳的。
區塊資源缺乏彈性
另一個 EIP1559 想要解決的問題是區塊鏈資源的尖離峰調度。
手續費有明顯的尖峰時段
目前,每一個區塊能夠塞的交易量是固定的,但使用的需求卻會有高低起伏,通常是週間比週末多,亞洲時間的晚上到深夜又比白天多。偶爾也會出現像 ICO 或 NFT 發售之類的突發需求,短時間內大幅推高手續費到非常誇張的境界,對於不願意出那麼高價的使用者而言,相當於區塊鏈暫時癱瘓。
2. 解決方案的演進
第二價格拍賣
原本的交易手續費是你出多少就會被收多少(第一價格拍賣),所以導致大家要處心積慮的選出一個不高不低的數字。如果換成第二價格拍賣法,也就是「不論原始出價多少,同一個區塊內的交易,統一收取相同的費用」,手續費由這批交易中的最低價者決定。這樣一來,使用者不用多想,只要出自己真正願意付的最高價就好,反正超過最低價的部分會被退回。
燒毀手續費
然而,第二價格拍賣有個明顯的漏洞,那就是會被礦工操縱。當礦工由高到低排好了要打包的交易之後,他可以把出價最低的幾筆交易換掉,故意自己製造一些高手續費的無用交易,反正手續費最後都會回到礦工身上,而且墊高最低手續費後,排在前面的交易也要付更多錢給礦工,礦工賺。
https://vitalik.ca/files/misc_files/EIP_1559_Fee_Structure.pdf
為了解決礦工操縱手續費的問題,最乾脆的解法就是這筆錢誰也不要拿了,交易手續費通通燒掉!礦工用自己的錢去墊高手續費只會虧更多。
系統手續費 + 小費
EIP1559 最後定了一個有趣的方案:系統根據需求自動調整手續費。
首先把原本的區塊大小上限變成目標的兩倍,如果希望一個區塊用掉 15,000,000 gas,就把上限設成 30,000,000 gas。礦工還是可以盡情塞滿區塊,但是這個區塊的滿溢程度會決定下一個區塊的系統手續費,每個區塊可以有正負 12.5% 的手續費調整。
舉例來說,如果系統手續費原本是 20 Gwei,區塊剛好裝到半滿的 15M gas,下個區塊的系統手續費就保持 20 Gwei;如果這個區塊是空的,下次的手續費降到 17.5 Gwei;如果這個區塊塞滿 30M gas,下個區塊的手續費提升到 22.5 Gwei。
新系統的設計立意和第二價格拍賣的市場供需決定論類似,但是很大程度的降低了礦工操弄的空間,而且讓整個區塊鏈對突發的高需求有更多彈性去應付,系統可以暫時以兩倍速處理交易,雖然會快速墊高手續費,但是等到離峰時段自然會慢慢降下來,等於是跟未來「借」了一些容量來用。
不過如果遇到像是 NFT 開賣這種瞬間壅塞的情況,兩倍的空間可能還是不夠用,而且每個區塊 12.5% 的手續費漲幅也許不足以熄滅買家的熱情,所以 EIP1559 還是保留了「小費」,也就是給礦工塞錢的機制,讓你在極端狀況時還是可以靠買通礦工來加速交易。
3. 社群反應
礦工好生氣好生氣
這搞不好是開發者們意料之外的發展也說不定。
以太坊核心開發者和礦工起爭議也不是第一次,包括之前降低區塊獎勵,以及取消 ProgPoW 升級都曾讓礦工揚言搞事。而且在可見的未來,PoS 也會讓礦工徹底失業。相較之下,這次只是拔掉手續費收入,礦工理論上應該已經習慣逆來順受了才對。
但恰好 2020 年適逢 DeFi 流動性挖礦起飛,交易需求飆高,經常有破百甚至好幾百的手續費持續很久,讓礦工的收入結構的手續費佔比從本來的 5–10% 忽然升高到幾乎跟區塊獎勵 1:1,甚至超過,這時後說要燒掉手續費收入,礦工當然就非常有感覺了。
崩潰的礦工開始在社群上各種哭鬧,一下說開發者搶錢,一下說這樣會破壞區塊鏈的安全性(實際上相反,高手續費佔比會導致區塊重組),與礦池友好的區塊鏈專欄作家也在此事上無情批判提出 EIP1559 的人的經濟學應該要當掉重修云云,最後大礦池們甚至再度連署號召硬分叉頑抗到底。
不過勒,現在以太坊上有超防叉的 DeFi,信標鏈又已經在跑,PoS 也是隨時準備上線的狀態…
礦工想搞分叉? ¯\_(ツ)_/¯
通縮迷因
另一個有趣的戰場在以太坊的 Twitter 意見領袖群。
過去,當比特幣和以太坊社群互酸互嘴的時候,以太幣沒有發行量上限這件事常常被比特幣擁護者調侃,說你有智慧合約有 DeFi 又怎樣,這種亂印鈔通膨的幣根本比不上有總量限制的數位黃金比特幣。
但現在情況不同了,EIP1559 看起來似乎能改變以太幣的發行趨勢,如果每次交易都會燒幣,那豈不是要比總量固定更讚,直接變成會通縮的超稀缺資源嗎?如果比特幣是 sound money(健全的貨幣),那改版後的以太幣根本就是 ultra sound money(超音波…貨幣?)了呀。
於是這些以太坊的網紅公知,像是 Bankless 的兩個創辦人和 EthHub 的兩個創辦人,你可以簡單理解為區塊鏈世界的朱學恆或周玉蔻吧,便開始帶起這個吹捧通縮迷因的風潮,在名字旁邊放上蝙蝠和聲音的 emoji(🦇🔊),說以太幣這下肯定要起飛啦,又 DeFi 又 2.0 又通縮,市值遲早超越比特幣。
不過呢,EIP1559 實際上並沒有保證通縮,交易手續費是會被銷毀沒錯,但區塊獎勵還是會印出新的幣,有可能多也有可能少。長期而言,最穩定的情況應該是在通膨和通縮間擺盪才對。
有些腦袋清醒的人選擇不隨通縮迷因起舞,比方說 MyCrypto 的創辦人就跳出來力戰群雄,勸那些網紅收斂一點,以太坊本來就很好,不需要用誤導性的說詞。另一邊,開發者社群倒是沒什麼聲音,可能幣價和跟比特幣輸贏本來就不是關心的重點,有 EIP 狂粉幫忙在氣勢上壓制礦工也不錯,他們更在乎測試鏈運作的狀況,以及專心為主鏈升級做好準備。
4. EIP1559 實際影響
以太幣會不會漲
不知道。
0 gas 交易死去
原本在 Flashbot 和 ArcherDAO 的研究之下,有幾個用 MEV searcher 發免手續費交易的方案出現,概念上就是你發交易的時候 gas 欄位填 0,但是在合約執行期間直接送錢到礦工地址(block.coinbase),藉此讓沒有以太幣但是有 ERC20 token 的錢包也能發交易。
這個做法升級後將變得不可行,因為 0 gas 會違反系統強制收手續費燒掉的限制,只能暫時退回比較原始的 meta transaction relayer,也許等未來帳號抽象的方案做出來再看有沒有機會了。
手續費設置自動化
這應該才是 EIP1559 的本意,升級後,使用者發送交易不太需要再觀察區塊鏈 mempool 的狀況,只要參考上個區塊的手續費再多加一點,就有很高的機率會在下幾個區塊被執行。不過對於那些想要設得比目前市價更低、願意慢慢等來省錢的人來說,交易打包的時間還是要看運氣就是了。
給忙碌人的 EIP1559 簡史 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
tps效能 在 Taipei Ethereum Meetup Facebook 的精選貼文
📜 [專欄新文章] [zkp 讀書會] Cairo 語言介紹
✍️ NIC Lin
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Cairo 是 STARK 證明系統的其中一個編程語言,讓開發者能透過 Cairo 來使用 STARK,撰寫效能更高的 Dapp
Photo by Simon Berger on Unsplash
Warning:本篇會保持在 high level 的介紹,實際深入的部分請見文內附上的文檔或是官方開發者文件
背景介紹
建構於密碼學的零知識證明能提供計算的隱私性,但同時在區塊鏈生態系也被用來提升 Scalability — 我可以用 10 秒的運算資源來驗證原本耗費 1000 秒運算資源的計算過程
如同更多人熟悉的 SNARK,STARK 也是一個零知識證明的證明系統,但當前的 STARK 著重的是在 Scalability ,而非大家比較習以為常零知識證明提供的隱私性特質
其實目前基於 SNARK 的 Rollup 項目,例如 zkSync、Loopring、Aztec、zkopru,除了 Aztec 外,其他都是利用 SNARK 來增加 Scalability — 這些 Rollup 上資料都還是公開、沒有隱私性的
StarkWare 是目前唯一基於 STARK 的開發團隊
STARK 要加上隱私保護不會太難,只是 StarkWare 還沒有把這項功能放在未來規劃中
Cairo 簡介
標榜為圖靈完備的零知識證明系統語言,Cairo 對原本熟悉 Solidity 的開發者來說還是會感到比較難上手和陌生的。再加上套件庫還不夠充足,目前支援的雜湊函式是 Pedersen,數位簽章演算法是 ECDSA(相對於 SNARK,EdDSA 的效能反而比較差所以沒有支援)。
但 Cairo 還在早期開發的階段,相信開發體驗會越來越好的。
另外需要注意的是作為一個證明系統,會有 Prover 和 Verifier 的角色。而 STARK 的 Verifier 是公開的,但 Prover 軟體預計會有 License 保護。Prover 一般情況下不得用於商業用途,除非將 proof 上傳至官方的 Verifier。
最後要提及的是,第一版的 Cairo 是設計來方便開發者將 Dapp 的運算遷移至鏈下。不同於 Rollup,這個鏈下只會有它自己一個 Dapp。這個 Dapp 的項目方自己維護自己 Dapp 的 state。( Rollup 則是 operator 維護所有 Dapp 的 state,Dapp 開發者不需自己操煩)
這可能有點難懂。如果你有在寫 Solidity,想像一下今天你在合約要用到合約裡宣告的 storage 變數時,你要自己提供 merkle proof 上來,證明這個storage 變數真的是這個值。這個就是開發者要自己維護 state 的意思。
而第二版的 Cairo 則是 StarkNet 裡使用的 Cairo(第一和第二版是不同編譯器),這版的 Cairo 就是作為 Dapp 在 Rollup 開發所使用 — 開發者可以在合約裡宣告變數,變數的值不需開發者維護,可以直接假設存在。
註1:StarkWare 不喜歡 Rollup 這個詞,他們覺得 Data Availability 的需求是一段光譜:不一定得要把 data 全都送上 L1,中間有其他方式可以做不同層級的 Data Availability。
註2:第一版和第二版實際上在官方版本裡是 0.0.1 及 0.0.2,在撰文當前最新版即是 0.0.2
官方網站:https://www.cairo-lang.org
開發者文件:https://www.cairo-lang.org/docs/
開發環境
Cairo 有提供像是 Remix 的瀏覽器 IDE:playground。裡面提供各種範例練習和挑戰,除了可以編譯,還可以直接生成並上傳 proof。
註:但有些功能還是沒辦法在 playground 裡使用,例如要給你的程式 custom input 時。這時候只能在本地端開發才能使用這個功能。
開發 Cairo 要先安裝python,我將開發者文件整理出來的資料統整在這個 hackmd 文檔裡:https://hackmd.io/w690dpAQTsKeKZv3oikzTQ
裡面包含簡介、設置本地開發環境以及 Cairo 基礎(因為篇幅原因,所以不將內容複製到這裡)
註:我把開發者文件裡的代碼整理到這裡:https://github.com/NIC619/cairo_practice/tree/master/practices
如果不想在研究開發者文件過程中,還要自己手動拼湊裡面例子的話,可以直接用整理好的代碼來執行。同時 repo 裡還有包含一些額外自己測試 Cairo 功能的範例。
深入 Cairo
在那份 hackmd 文檔裡的開頭,可以連結到第二部分 — 深入 Cairo 的部分。裡面也是從開發者文件裡擷取出來我覺得比較重要的部分。如果你要讀開發者文件的話,我建議從 Hello Cairo 開始,它會從例子切入,會比較好知道 Cairo 怎麼使用。接著如果要更深入了解,再去讀 How Cairo Works。
StarkNet Cairo
第二版的 Cairo 其實功能和第一版的 Cairo 是差不多的,所以不必擔心在開發者文件裡學到的 Cairo 在 StarkNet 版本會不能用或差很多。在讀完 Hello Cairo/How Cairo works 後,就可以接著看 Hello StarkNet。會很順利的切換到 StarkNet 版本的 Cairo。
註1:我整理的文檔裡是按照第一版 Cairo 所寫的
註2:如果你從開發者文件一路看下來,體驗過非 StarkNet 版的 Cairo,那你在體驗 StarkNet 版的 Cairo 時一定會發現這更像一般智能合約的使用方式 — 你可以用 view 函式查詢 storage 變數,可以用 external 函式去執行合約(非 StarkNet 版本不是這樣操作 Dapp 的,這邊因為篇幅原因沒有詳細介紹)。
非常建議嘗試兩種版本的 Cairo,你會知道 1. 操作一個單獨在 L2 的 Dapp 和2. 操作與其他 Dapp 共存在 Rollup 上的 Dapp 的不同。這對了解 L2 怎麼運行、需要哪些資料、為什麼需要這些資料非常有幫助。
0.0.2 版的 StarkNet Cairo 目前還缺少一些功能:
函式還沒辦法宣告陣列或 struct 型態的參數
合約和合約之間還沒辦法互動
L1 沒有辦法讀取到 L2 的資料,L2 也沒辦法讀取到 L1 的資料。如果要建立跨 L2 Bridge,這個功能非常重要。
補充及個人心得
STARK 的 proof size 相比於 SNARK 系列的 proof size 大很多,又其證明所包含的交易數量對 proof size 和驗證時間的影響不大,所以把很多筆交易一併做一個 proof 會是對 STARK 非常有利、節省成本的方式(SNARK、STARK 比較表)。但這同時也是一個缺點,如果你的 Dapp 或 Rollup 的 TPS 不高,那就只能等更久時間搜集多一點的交易,要不然就只能提高成本來維持驗證 proof 的頻率。
StarkWare和 zkSync 一樣都有 Rollup 宇宙的概念( Rollup 宇宙的用詞並不精確,因為在他們的宇宙中不會所有子鏈都是 Rollup,而是會有依照 Data Availability 程度不同所區分的子鏈,像是 Validium、zk Porter 的設計),個人覺得能夠有(針對 Data Availability 程度的)選擇是會比只有一個選擇(完全 Data Available) 還好的方式,但實際上的可行性就要等其團隊釋出更多的資訊。
在 Rollup 越趨成熟的情況下,能夠提供快速跨 Rollup 服務的流動性提供者的角色會越來越重要。zk Rollup(StarkNet、zkSync、etc…)比 Optimistic Rollup (Optimism、Arbitrum、etc…)有著短上許多的 finalize 時間,這對降低流動性提供者的風險有很大的幫助,但目前 zk Rollup 支援合約功能甚至 L1 <-> L2 互動的完成度都比 Optimistic Rollup 還低上許多。短期內快速跨 Rollup 的服務應該還是侷限在 Optimitic Rollup 之間。
abbrev
[zkp 讀書會] Cairo 語言介紹 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
tps效能 在 如何量測系統的容量?(壓測) - Complete Think 的推薦與評價
淺談效能測試整理了關於Capacity、Reliabilty、Stability 的概念與定義。 ... 一台c5.xlarge,然後找到輸入的基礎值Baseline ,像是TPS / RPS / QPS ... ... <看更多>
tps效能 在 快拉親朋好友一起來分享集讚 - Facebook 的推薦與評價
開站活動第二波x TPS 最愛】ROG開站活動(http://goo.gl/y3lxb5) TPS最愛配備大公開! ... 另外,華碩獨家GPU Tweak調校程式則讓使用者更直覺調整顯示卡各元件與效能 ... ... <看更多>