交易若改用抗量子簽章，ZK 證明怎麼辦？

0:00開場：底層簽了抗量子，應用層證明仍可能被偽造

0:00大家好，謝謝。我是 Alex，在 Ethereum Foundation 的 client-side proving 團隊，研究怎麼讓零知識證明在客戶端裝置上可行。今天想講另一場抗量子遷移：我們若要繼續在以太坊上用隱私應用，這場遷移是必要的。既然講到零知識證明，先快速複習。這是一套密碼學協定，讓一方、也就是 prover，說服另一方、也就是 verifier，某個陳述為真，卻不必揭露進入證明的所有資料。Hello everyone, and thank you. My name is Alex. I work at Ethereum Foundation in the client-side proving team, where we do some research about how to make zero-knowledge proofs feasible on client-side devices, and today I want to talk about the other post-quantum migration that is necessary for us to keep enjoying privacy applications on Ethereum. So, since we're talking about zero-knowledge proofs, it's a quick refresher what that is. It's a cryptographic protocol that allows one party, that's called the prover, to convince the other party, that's called the verifier, that some statement is true without revealing all the data that went into the proof.

1:00基本上，你可以對私密資料證明某件事，卻不揭露那份私密資料。現在講抗量子遷移。今天在以太坊，以執行層為例，我們用 ECDSA 簽名來識別自己是協定的使用者。送交易時，用密鑰對交易簽名，公鑰就是以太坊地址。這能用，是因為還沒有夠強的量子電腦能破解 ECDSA。密碼學被量子對手破解時，那個對手可以偽造看起來完全像使用者送出的交易，使用者其實沒授權，對手就能花掉使用者的資金。So basically, you can prove something about private data without disclosing that private data. So now let's talk about the post-quantum migration. Today on Ethereum, if we take the example of the execution layer, we are using ECDSA signatures to identify ourselves as users of the protocol. So when we're sending a transaction, we are signing that transaction using our secret key, and our public key is our Ethereum address. So it works because there is not yet a sufficiently capable quantum computer that can potentially break the ECDSA cryptography. So what happens when that cryptography is broken by a quantum adversary is that that quantum adversary can actually forge transactions that look absolutely like they were sent by the user, but the user didn't authorize that, so that quantum adversary can spend the user's funds.

2:08這非常不理想。所以我們要把交易簽名遷到抗量子簽名方案，然後使用者就安全了，對吧？但想想交易的 payload。就算協定升級了密碼學、保護了交易，也不表示交易 payload、以及以太坊上應用的密碼學會自動升級。這個例子裡，如果 payload 是一個零知識證明，也許你正從屏蔽池提領資金。And this is really undesirable, right? So what we need to do is that we need to migrate the signature of the transaction to a post-quantum signature scheme, and then we are safe as users, right? But let's think about the payload of the transaction. So even if the protocol has upgraded its cryptography and secured its transactions, it doesn't mean that the payload of the transaction and, let's say, the cryptography of the applications on Ethereum is upgraded automatically. So in this example, you can see that if the payload of the transaction is, for example, a zero-knowledge proof, so maybe you're withdrawing your funds from a shielded pool.

3:01抗量子 ZK 三條路，以太坊目前在探雜湊路線

3:01如果那個零知識證明也在用前量子的古典密碼學，量子對手就可以偽造那個證明，若花費是由零知識證明授權，就又能花掉你的資金。這場遷移誰負責？兩邊都要做。首先當然是應用自己要把用的密碼學升到抗量子。我們也可以要求以太坊為這些應用做點事，因為歷史上它已經為古典密碼學做過。If that zero-knowledge proof is also using pre-quantum classical cryptography, then a quantum adversary can just forge that zero-knowledge proof and again spend your funds, if the spending is authorized by a zero-knowledge proof. So who is responsible for this kind of migration? Here, the work should be done on both ends. So first of all, of course, the applications themselves need to upgrade the cryptography that they are using to post-quantum cryptography. And of course, we can also ask Ethereum to do something for those applications, because historically it has been doing it before for the classical cryptography.

3:51所以今天才有橢圓曲線運算的預編譯，讓我們能方便地在鏈上用零知識證明。先講協定。密碼學現況如何？能不能有抗量子安全的零知識證明？答案是可以，因為抗量子密碼學研究夠多。主要三個方向：isogeny、格、雜湊型密碼學。成熟度不一樣。isogeny 比較新，雜湊型是舊東西、研究得很深，它所依賴的假設被認為是最保守的一批。That's why we have for example, precompiles for elliptic curve operations in Ethereum that allow us to conveniently use zero-knowledge proofs on-chain today. So first, let's talk about the protocols. What's the current situation with the cryptography? Can we have post-quantum secure zero-knowledge proofs? And the answer is yes, because there is enough research going on in post-quantum cryptography. So there are three main directions: isogenies, lattices, and hash-based cryptography. They're not all equally mature, so isogenies is a more, like, newer thing, and hash-based cryptography is an old thing that's very well studied, and the assumptions it relies on are considered to be one of the most conservative.

4:52格密碼學也研究得很深，但假設比較新，所以今天剩下的時間我們會看雜湊型。這也是以太坊目前的選擇。我是說這還不是百分之百的最終決定，但目前以太坊在用雜湊型密碼學探索抗量子升級。術語上，雜湊型 SNARK 有點含糊。口語裡我們常把 STARK 拿來泛指所有抗量子的雜湊型密碼學。And lattice-based cryptography is also well studied, but the assumptions are a bit newer, and that's why we are going to explore the hash-based cryptography in the rest of today's talk. And also, this is the current choice of Ethereum. Like, I mean, it's not the 100% final decision, but currently Ethereum is exploring the post-quantum upgrade with hash-based cryptography. So there is some ambiguity in the terminology about hash-based SNARKs. So colloquially, we are very often using a term STARK to just designate, like, all post-quantum hash-based cryptography.

5:42這不完全成立。STARK 是某個特定零知識協定的名字，有自己的論文，2018 年出來，此後這個領域變很多。較新的雜湊型、抗量子構造，長得不完全像那個 STARK，雖然有共通處，但不是同一件事。為了簡單，接下來我可能互換著叫它們雜湊型系統或 STARK，因為 STARK 比較短。來講這些 STARK 的效能。它們夠好嗎？能不能直接用，確定不會比我們熟悉的前一代零知識系統差？This is not exactly valid, I would say, because STARK was a name for a particular zero-knowledge protocol that has its own paper. It came out in 2018, and since then the field has evolved dramatically, and the newer constructions that are hash-based and post-quantum, they don't quite resemble. They share something in common with that STARK, but it's not the same thing. But for simplicity, in the rest of my talk, I may interchangeably just call those things hash-based systems or STARKs, just— because STARK is short. So let's talk about the performance of those STARKs. Are they good enough? Like, can we just use them and be sure that they are not worse than those previous zero-knowledge systems that we are familiar with?

6:37STARK 證明夠快，但鏈上驗證可能逼近四百萬 gas

6:37我們團隊做客戶端證明基準測試已經一陣子了，大概超過一年，在一個方便的儀表板追蹤各種 SNARK。有興趣可以自己去那個網址看儀表板。就原始速度來看，情況不錯，STARK 甚至常佔圖表前段。至少速度上，我們可以確定 STARK 是好的。但對我們這些隱私協定使用者來說，還有別的事要緊。那些是這些系統的 RAM 佔用，還有頻寬。So our team has been running the client-side proving benchmarks for quite a while already, for maybe more than a year, where we are tracking various SNARKs in a convenient dashboard. So if you're curious, you can go to that address and explore the dashboard yourself. But as you can see, the situation looks quite good in terms of raw speed for the STARKs, and they even tend to occupy the top of the charts here. So at least speed-wise, we can be sure that STARKs are good. But for us as users of privacy protocols, some other things matter as well. And those things are the RAM footprint of those systems and also the bandwidth.

7:27頻寬之所以重要，是因為有些零知識證明系統，你要先下載相當大的檔案才能開始證明。熟悉 Groth16 或 Circom 語言的人知道那些惡名昭彰的 zkey，可能要下載到數百 MB。但這裡 STARK 表現也不錯。很多不需要太多 RAM，連行動裝置的預算都放得進去。很多也不需要那麼大的預處理產物，所以你甚至可能用有流量上限的行動連線，把零知識 app 發出去。And bandwidth here is important because, for some of those zero-knowledge proving systems, you need to download quite sizable files to just simply start proving. Maybe some of you who are familiar with protocols like Groth16 or Circom language, you know that it has those infamous zkeys that you need to download, and they can be, like, hundreds of megabytes. But again, here we can see that STARKs are doing quite well. Many of them do not require too much RAM and fit perfectly within even a mobile device budget. And also, many of them do not need that large preprocessing artifacts, so you can just distribute your zero-knowledge app even maybe over a metered mobile connection.

8:23可惜 STARK 有缺點：證明大小，以及驗證那個證明的複雜度。這就是你用抗量子的雜湊型密碼學要付的成本：證明有時大到數百 KB，verifier 也不總是適合放上鏈。我們做過很具體的實驗，想更仔細看，驗證一個最現代的 STARK 在鏈上要花多少。我們拿了一個叫 WHIR 的構造協定。But unfortunately, there is a downside to the STARKs, and that downside is the proof size and the complexity of verifying that proof. So, as it turns out, this is the cost you are paying when you are using that hash-based cryptography that is post-quantum secure: you're paying the cost of having proofs in the range of sometimes up to hundreds of kilobytes, and also the verifier is not always particularly friendly to putting it on-chain. So we did a very concrete experiment with that. We wanted to see what is the cost of verifying maybe one of the most modern STARKs on-chain in a little bit more detail. So we took a construction protocol that is called WHIR.

9:20這是大約兩年前相對新的論文。我們在小質數體上實例化，量 gas 成本。結果相當高，將近四百萬 gas。而且這只是整個 SNARK 的多項式承諾部分，不是整個 SNARK 成本。驗證完整證明時，還有 SNARK 的另一塊，叫做 interactive oracle proof，會在 Solidity 程式碼裡多加邏輯，你還要再付一筆。那我們能做什麼？It's a relatively recent paper from, like, two years ago, and we instantiated it over a small prime field and measured the gas cost. It turned out to be quite high, like three, almost four million gas. And this is only the polynomial commitment part of the whole SNARK. This is not the whole SNARK cost, like, because when you're verifying the whole proof, there is also another part of the SNARK that's called the interactive oracle proof part that would add more logic in your Solidity code, and you would have to pay for that some extra. So can we do anything about that?

10:07遞迴聚合可攤平成本，根證明驗證超過一千萬 gas

10:07如果單次驗證成本很高，也許可以攤提。把更多動作放進一次驗證，只付一次，再把成本分給那些送出待驗證動作的使用者。一種做法是所謂遞迴聚合，或遞迴。先看驗證單一 SNARK 證明時發生什麼。我們有一個電路，定義某種關係或計算。我們把輸入提供給那個電路，prover 產出證明。So if the cost of a single verification is high, maybe somehow we can try to amortize that cost. So we kind of put more actions into one verification and pay only once, but divide the cost among those users who are, like, sending those actions that we want to verify. So one way to do that is so-called recursive aggregation, or recursion. So first, let's take a look at what's going on when we are verifying an individual proof of a SNARK. We have a circuit that defines some kind of relation or computation that we're proving. We're just providing an input to that circuit, and the prover is producing the proof.

10:57然後 verifier 可以驗證那個證明。但 verifier 是什麼？Verifier 也是一支程式，也是計算。注意右邊：我們可以直接把 verifier 的計算放進電路。電路現在不是在證某個陳述，而是在證我們知道某個證明，叫它 child proof，它滿足這個 SNARK 的 verifier 陳述。這裡得到的 parent proof，保證 child proof 有效。And then the verifier can verify that proof. But if we think, what is a verifier? A verifier is also a program. It's a computation. So what we can do now, pay attention to the right side, we can simply put that verifier computation inside the circuit. So our circuit now is not proving some kind of statement, but it's actually proving that we know some proof, let's call it a child proof, that satisfies the statement of the verifier of this particular SNARK. So the parent proof that we obtain here guarantees the validity of the child proof.

11:44再往前一步，我們其實可以在一個電路裡驗證多個證明。這個例子是一個電路驗證兩個證明，當然沒人限制我們，可以驗證更多。這樣我們走到根。驗證根證明時，可以確定左邊葉層進來的所有 child proof 也都有效。如果有 n 個證明，每個證明的成本就是最終驗證成本除以 n，比單獨為一個動作或一筆交易付那筆成本好很多。我們也想看具體數字。做不做得到？成本是多少？This way, we can go one step further, and we actually verify multiple proofs inside one circuit. So here in this example, we're verifying two proofs in one circuit, but of course no one is limiting us, and we can verify even more. So what's going on here is that, in this way, we're reaching the root. We can be sure that when we're verifying the root proof, we have proved also the validity of all the incoming child proofs that were there on the left, on the leaf level. So if we have n of those proofs, the cost per proof will be just that final verification cost divided by n, which is much better than just paying that cost alone for a single action or transaction. So we also wanted to see the concrete numbers. Can we do that successfully? Like, what does it cost?

13:01我們拿客戶端 SNARK，Spartan-WHIR，再用 LeanVM 試著把那個 child proof 遞迴進根。LeanVM 是同事做的，本來就是為了以太坊真正的抗量子升級，但它跟我們的 SNARK 有很共通的建構塊，所以很自然。結果是：這個情況下，根證明驗證要超過一千萬 gas。拿來跟典型隱私協定比，如果模擬像 Privacy Pools 這種隱私協定的提領，通常大約五十萬 gas。So we took our client-side SNARK, the Spartan-WHIR, and we used LeanVM to try to do this recursion of that child proof into the root. LeanVM is developed by our colleagues, and it was meant for that actual post-quantum upgrade of Ethereum, but it has some very, like, common building blocks with our SNARK, so it was a natural fit. So what we discovered is that the root proof, in this case, costs more than 10 million gas to verify. And if we try to compare that to a typical, let's say, privacy protocol, maybe if we're emulating a withdrawal from a privacy protocol like Privacy Pools, that would typically cost around 500,000 gas.

14:00預編譯省不多，EIP-8288 想把驗證移出 EVM

14:00所以要把每個動作、每筆交易的成本拉到同一個水準，這個例子裡大約要批次或聚合 21 筆交易，看起來還可以。但前提是你的應用架構允許這種聚合，因為你必須等著聚合，應用裡的動作也必須允許聚合。而且那個聚合不該發生在鏈上，也不該發生在客戶端。So to get to the same cost per action in this case, or per transaction, we need to batch or aggregate around 21 of those transactions, which looks okay. But the caveat here is that you can do it easily only if your application architecture allows for that aggregation, because you need to wait to aggregate, and the actions in your application should be such that they permit aggregation. And of course, that aggregation should happen somewhere not on-chain and not on the client.

14:51這意味著中間會有一層 aggregator，也是架構上的取捨。從應用端看，可能的選項大概走完了。再看以太坊能為這場抗量子遷移做什麼。既然有橢圓曲線運算的預編譯，能不能為雜湊型 SNARK 做預編譯？我們也做了實驗，延續前面 WHIR PCS 那次，想看 verifier 裡有沒有重複運算可以抽成新的以太坊預編譯，能省多少 gas。So it means that there is some intermediate layer of aggregators, which is also an architectural trade-off. So, can we... So now we can see that, yeah, from the application side, we are probably done with all possible options. So let's see what Ethereum can do for us to facilitate this post-quantum migration. Since there are precompiles for elliptic curve operations, then maybe what if we can make some precompile for the hash-based SNARKs? And we also did an experiment, the continuation of the previous one with the WHIR PCS, where we wanted to see, okay, is there some repeating operation in that verifier that we can extract as a new precompile in Ethereum, and how much gas could it save?

15:54結果省下的非常非常少。嗯，其實也沒那麼少，但結果成本還是相當高。問題還有：就算你提出某個預編譯，也不表示除了你的應用以外，對所有人都有用。有標準化的疑慮，也有更廣用途的疑慮。協定最終能為我們做的，是把驗證整段移出 EVM。有一個提案叫 EIP-8288，建在 frame transaction 之上，定義一種新的 frame transaction，可以攜帶 STARK 證明。So it turned out that the saving is very, very small, and, well, not actually not that small, but the resulting cost is still quite high. But the problem here also is that even if you come up with some precompile, It doesn't necessarily mean that it will be useful for everyone besides your application. So there are some standardization concerns and, like, broader usefulness concerns. So what the protocol ultimately can do for us is to move the verification entirely outside of the EVM. And there is a proposal for that that's called EIP-8288 that is built on top of frame transactions, and it defines a new type of a frame transaction that can carry STARK proofs.

16:57看一下用這個 EIP 的應用架構。從使用者看，沒什麼變。我們還是要在客戶端用私密資料產出零知識證明。送出帶證明的交易時，交易先進入記憶體池，處理記憶體池的節點把我們的證明聚合成遞迴 STARK。它們在一段時間內能聚合多少筆交易，就產出單一證明；驗證者把區塊放進區塊鏈時，只要驗證最終證明。重活是記憶體池節點在聚合。Let's take a look at what the architecture of an application will be using this EIP. So from user perspective, nothing changes. We still need to produce our zero-knowledge proof with our private data on the client side. Then when we are sending the transaction with this proof, the transaction first gets into the mempool, and the nodes that are processing mempool aggregate our proofs into a recursive STARK. So they produce a single proof of whatever number of transactions they could aggregate during a certain time, and when the validator is including a block on the blockchain, the validator should only verify the final proof, so the heavy lifting here is done by the mempool nodes that are aggregating.

17:52合約只核對驗證金鑰與公開輸入，區塊裡裝不下每筆 ZK

17:52智能合約知道：交易到它手上時，已經有效。證明在合約外面就被驗證了。再看合約近一點。這種新的 frame 會有依賴。合約要讀那些依賴，再檢查：首先，這個 frame 含有 STARK 證明。接著用驗證金鑰確認這個 STARK 證明對應的是我們的 STARK、我們的應用。最後確認進入證明的輸入，就是這筆交易正在處理的資料，因為 frame 裡的 data hash 欄位會是進入證明的公開輸入的雜湊。And the smart contract knows that when the transaction has reached it, it is already valid. So the proof was verified outside of the contract. We can take a closer look at the contract. So that new type of frame will have dependencies. So the contract needs to read those dependencies and then check that, first of all, okay, this frame contains a STARK proof. Then the STARK proof is actually corresponding to our STARK, to our application, by checking the verification key. And finally, just make sure that the inputs that went into that proof are the data that we are now working with in this particular transaction, because the data hash field in the frame will be the hash of the public inputs that went into the proof.

18:49幫建造者總結今天的選項。如果你的應用必須在協定層變更到來之前部署，就要選：應用能不能忍受那些聚合取捨。可以的話，就做遞迴 STARK 聚合，在 EVM 裡驗證。不行的話，可以考慮直接驗證單個證明，成本會高很多。如果你等得及協定變更，也許某個時間點，協定內會有方便的遞迴 STARK 聚合。So, if we summarize the options today for the builders, so if your application needs deployment before those protocol-level changes arrive, then you need to choose whether your application can actually tolerate those aggregation trade-offs, and if yes, then you can do the recursive STARK aggregation and verify in EVM. If no, you can consider verifying individual proofs directly, although for a much higher cost. And if you can actually wait for the protocol changes, then maybe, like, at some point, we will have the convenient recursive STARK aggregation inside the protocol.

19:43我們其實在做基準測試，結果顯示聚合做得到，但以目前技術，你沒辦法讓想放進區塊的每一筆交易都帶 ZK 證明。今天一個區塊大概能放幾百筆交易，如果那些證明同時到達，你只有 12 秒組區塊，大概沒辦法全部放進去，也許幾十筆。但技術進展很快。有新的 SNARK，LeanVM 也持續改善，我覺得最後效能會更好。We are actually conducting some benchmarks, and our benchmarks show that, yeah, it is possible to aggregate, but at the current technology, you cannot really have a ZK proof inside every transaction that you want to include into the block, because, like, today you can have a couple of hundred transactions inside one block, and if you assume that all those proofs arrive at the same time, you only have 12 seconds to build the block, so probably you will not be able to include all of them in there, but maybe a few dozen. But the technology evolves quickly. There are new SNARKs, and LeanVM keeps improving, so eventually I think we will have better performance.

20:32這是基準測試目前的進行中工作。有興趣可以追。再過幾週會有更新的資料。我的演講到這裡，歡迎提問。你提到預編譯可以幫忙降低驗證證明的 gas，我想問你們還有沒有想到其他現在就能降低 gas 的做法。Yeah, this is the current work in progress on the benchmark. You can track that space if you're curious. In a couple of weeks, there will be fresher data. And this concludes my talk, and I welcome your questions. You mentioned the precompile can help reduce the gas to verify the proof, and I was just wondering if there are other approaches that you guys had in mind that can help as well to reduce the gas costs at the moment.

21:25提問：記憶體池只有一個，區塊證明會去重

21:25算術最佳化以外，其實沒有了。因為我們實驗裡的程式碼，已經針對 STARK 裡那些特定運算做了很重的最佳化。你若用減少 Solidity 智能合約程式碼量就把天花板碰到了，就得往別處看，往那塊外面看。了解。另一個問題。你提到有幾個記憶體池在聚合交易。記憶體池會不會聚合同一筆交易？Besides the arithmetic optimizations, not really, because, like, that code in our experiment was already heavily optimized for those specific operations that happen in STARKs. So if you reach that ceiling by just optimizing... by reducing the amount of the Solidity smart contract code, then, like, you just need to look elsewhere, like outside of that. Yeah, I see. Another question. So you mentioned there are several mempools that aggregate transactions, and... Would the mempools aggregate the same transaction?

22:12所以證明裡，兩個證明可能含同一筆交易之類。那會不會是問題？首先我要更正。記憶體池只有一個，但很多節點從記憶體池組區塊。最終那個單一 STARK 證明會跟區塊一起被收進。所以每個區塊會有一個遞迴 STARK 證明。在區塊裡這件事已經解掉了。我們今天沒有這個問題，因為區塊裡每筆交易當然是唯一的。區塊建造者不能把同一筆交易放進區塊兩次。So probably the proof contains, like, two proofs might contain the same transaction or something. Would that be a problem? So, yeah. So first of all, I need to correct you. There is only one mempool, but many nodes that are building blocks from the mempool, right? So eventually, that single STARK proof will be included with the block. So every block will have a recursive STARK proof, right? So in the block, we already solved that. Like, we don't have that problem today because, like, every transaction in a block is unique, of course. Like, your block builder cannot include, like, the same transaction twice into the block.

22:59附在交易上的那些證明也一樣。不是每筆交易都該附證明，但最終區塊證明、收進區塊的那個遞迴 STARK 證明，只會有去重後、對應特定交易的證明。了解，謝謝。我有一個問題：你們在做客戶端證明基準測試，但感覺整場講的其實也可以用伺服器端證明來做，對嗎？So the same applies to those proofs that are attached to transactions. Yeah, not every transaction should have that proof attached, but ultimately the block proof, the recursive STARK proof that's included in the block, will only have, like, deduplicated proofs in it that correspond to certain transactions. Okay, I see. Thank you. I had a question regarding the, you guys are doing the client-side proving benchmarks, but it feels like these, like the whole presentation you guys talked about, could actually be done by server-side proving. Is that correct?

23:55還是假設是人們在客戶端證明，再把證明送出去？好問題。想想今天的以太坊，我們甚至可以做在家質押。在家質押的人跑的是相當普通的硬體。以太坊驗證自己並不需要 GPU 農場。就這個意義，記憶體池裡的遞迴聚合，我們希望盡量少要求，才不會最後組以太坊區塊也需要 GPU 農場。Or is the assumption that people would be proving on their clients and then sending the proof? Yeah, this is a great question. So if you think about Ethereum today, we can even do things like home staking, right? So, and people who are home staking, they're running pretty average hardware, I would say. Ethereum doesn't require GPU farms to just validate itself, right? So in this sense, for that recursive aggregation in the mempool, we... we would like to keep it as, how to say, as little demanding as possible, so that you wouldn't end up needing a GPU farm just to build Ethereum blocks.

24:45提問：客戶端基準測雜湊與 ECDSA，也已經在測 VM

24:45所以這仍然跟客戶端有關。客戶端當然是寬的詞，但通常我們假設某種普通人能取得的普通硬體。還有一個問題。我知道你們做的客戶端證明基準測試，主要在測簽名跟雜湊，就這些，對吧？就是雜湊。對，就是雜湊，然後 ECDSA。你覺得客戶端證明主要需要的就是雜湊跟簽名嗎？很多其他 prover 想做完整 VM，你覺得客戶端真正必要的其實只是雜湊跟簽名嗎？So that's why this is still relevant to the client side, because client side, of course, is a broad term, but usually we assume some kind of hardware that is like average hardware that a normal person may access. Yeah. I—oh, one more question. So I know the client-side proving that you guys are, like the benchmarks you guys are doing are mainly, you guys are benchmarking, like, signatures and hashes and— I think that's it, right? It's just, like, the hashes. Yeah, just hashes and then ECDSA. Is that, like, what primarily you think would be necessary for client-side proving? Because, like, a lot of other provers are trying to do, like, full VMs, but do you think that, like, what's only necessary from the client side is actually just hashes and signatures?

25:39我們要把工作負載跟系統分開。工作負載上你是對的。我們主要在測雜湊，以及像 ECDSA 這種簽名方案，這有歷史原因。ECDSA 是因為客戶端證明的一個大應用是 ZK ID，零知識身分。你有某種數位身分，也許是政府發的，或其他識別，但你想用零知識向另一方證明：對，那是你、那是你的身分。那些應用裡，這類傳統簽名用得很廣。雜湊方面我們在測很多常見雜湊，下一個實例也會測 BLAKE，它在以太坊也越來越常見。所以我們其實已經在測 VM。Well, we need to separate the workloads and the systems. So, in terms of workloads, you are right. We are mostly benchmarking hashes and signature schemes like ECDSA, and there is a historical reason for that. ECDSA is because a big application of client-side proving is ZK ID, like zero-knowledge identity. When you have some kind of digital ID, maybe even government-issued or another kind of identifier, but you want to prove to another party in zero knowledge that, yeah, that is you, that's your identity. And there, in those applications, those conventional signatures are widely used. But in terms of hashes, we are testing many popular hashes, and in the next instantiation, we will also test BLAKE, which uh, is getting even more popular also for Ethereum. So we are already testing VMs in here.

26:42你可以看到，那些系統很多其實就是 VM。它們沒有被特別標出來，因為最後都在做零知識證明。使用者不該在意它是 VM 還是 SNARK。好，非常感謝。抱歉，提問時間到了。還有問題的話，稍後可以再找 Alex。我們必須繼續後面的演講。非常感謝 Alex，這場很好。You can see that many of those systems are actually VMs. They are not, like, marked in a special way because they are all, like, eventually doing the zero-knowledge proving. So a user should be agnostic of whether it is a VM or a SNARK. All right, thank you very much. I'm sorry, this is all the time we have for Q&A. If you have further questions, please feel free to talk to Alex later on. But we do have to move forward with our presentations. Thank you very much, Alex. That was a wonderful presentation.