Vitalik 的 EIP-8288：隱私交易能變便宜嗎？

0:00抗量子簽章太貴

0:00很好。希望大家午餐吃得愉快。有誰午餐吃得不愉快？好。早上我簡短提過 EIP-8288，以及以太坊要怎麼把很多進階密碼學、尤其是零知識證明整合進去，變得更可擴容、也更有隱私。所以今天、在這裡，我想談的是……Great. So, hope everyone had a good lunch. Who here did not have a good lunch? Okay, good. So, I mentioned briefly this morning about EIP-8288 and some of the connection between how Ethereum is going to be integrating a lot of advanced cryptography and especially zero-knowledge proofs to become much more scalable and much more private. So today I wanted, or here I wanted to talk about...

0:46我希望這件事發生的其中一種具體方式。8288 是一份 EIP，已經寫好了。你可以自己去 eips.ethereum.org/EIPS/eip-8288 看。它做的是記憶體池內的遞迴 STARK 聚合。我會講它怎麼運作，以及這對擴容、對隱私、對抗量子安全，還有以太坊能不能三件事同時擁有，分別代表什麼。先談一些問題。第一，抗量子簽章又大又貴。one of the specific ways in which I hope that this will happen. So 8288, this is an EIP. It's written. You can check it out yourself at eips.ethereum.org/EIPS/eip-8288. And what it does is in-mempool recursive STARK aggregation, and so I'll go through both how this works and, in particular, what it means for scalability, for privacy, for post-quantum security, and for Ethereum's ability to have all three of those at the same time. So let's talk about some problems. So first of all, quantum-safe signatures are big and expensive.

1:39現場有誰知道，在以太坊上獨立驗證一筆 ECDSA 簽章要多少 gas？知道數字的喊出來。precompile 的 gas 成本是 3,000。你還要付 calldata。一筆 ECDSA 簽章的 calldata 是 65 bytes。到 Glamsterdam，我覺得每 byte 的 gas 會再提高。所以資料本身大概還要再 4,000，也許一共 7,000。那抗量子簽章呢？我們最近非常積極在把雜湊型簽章的 gas 降下來，所以有 SPHINCS-minus，基本上是把雜湊型簽章理論裡很多想法改寫過來，並試著選一組最佳參數。So, who here knows how much gas it costs to independently verify one ECDSA signature on Ethereum? If anyone knows the number, shout it out. So the gas cost in the precompile is 3,000. Also, you have to pay calldata costs. Calldata for an ECDSA signature is 65 bytes. And in Glamsterdam, I think the gas cost per byte is going to be increased. And so actually, the data itself will cost another 4,000, so maybe 7,000. Now, what about a quantum-safe signature? Now, we have recently been working very aggressively to reduce the gas cost of hash-based signatures, and so we have SPHINCS-minus, which is basically an adaptation of a lot of ideas from hash-based signature theory, and to try to choose some optimal parameters.

2:40要讓它真的適合以太坊、又盡量有效率，gas 成本大概在 15 萬左右。看取捨，低可以到 10 萬，高可以到 20 萬或 30 萬。權衡基本上是：你比較在意鏈上驗證便宜，還是比較在意簽章能做，例如在硬體錢包裡做。15 萬 gas 很多。以太坊上一筆基本的 ETH 轉帳是 21,000 gas。我們不希望基本操作從 21,000 漲到 17 萬。這是第一個問題。To make it really work for the Ethereum context and be maximally efficient, the gas cost is somewhere around 150,000. Now it depends, like it can go as low as 100,000, it can go as high as like 200,000 or 300,000. The trade-off is basically how much do you care about cheap on-chain verification versus how much do you care about signing being possible to do, like for example in a hardware wallet. Now, 150,000 gas is a lot of gas. So a basic ETH send on Ethereum costs 21,000 gas. We do not want basic operations on Ethereum to go up from being 21,000 gas to being 170,000 gas. So this is the first problem.

3:27隱私證明同樣太貴

3:27第二個問題：隱私協議的證明又大又貴。過去一年，現場有誰從 Tornado Cash、Railgun 或 Privacy Pools 提領過？不錯。有誰至少用過其中兩個？三個都用過？好。你大概記得花了多少 gas。不記得 gas 數字，也會記得手續費。我上次從隱私協議提領，手續費大概 10 美元。它會上下波動，有時大概 50 美分，有時大概 10 美元。Second problem, privacy protocol proofs are big and expensive. Who here in the last year has made a withdrawal from either Tornado Cash or Railgun or Privacy Pools? Nice. Who here has used at least two of those? All three? Okay, so. You probably remember how much gas it cost you. Or if you don't remember the gas number, you'll remember the transaction fee. Last time I withdrew from a privacy protocol, the transaction fee was about $10. It actually goes up and down. Sometimes it takes about 50 cents, sometimes it's about $10.

4:162021 年用量很高的時候，我做過最貴的一筆隱私提領是 800 美元。為什麼？因為就算你很用力最佳化，隱私協議提領最有效率大概也要 35 萬 gas。你們今天在用的隱私協議沒有那麼用力最佳化，所以常常要 100 萬 gas。這是第二個問題。第三個問題：抗量子的隱私協議證明大到、貴到幾乎做不了。一個 STARK 大概 100 到 300 KB。如果讓客戶端多做一點工，就算 100 KB。Back in 2021, when there was a high volume of usage, the highest fee I ever paid to do a private withdrawal was $800. Why? Because the most efficient privacy protocol withdrawal you can possibly get, if you optimize very hard, is about 350,000 gas. The privacy protocols you use today do not optimize very hard, and so it often costs one million gas. So that's the second problem. The third problem: quantum-safe privacy protocol proofs are prohibitively big and expensive. So a STARK is between 100 and 300 kilobytes. Let's call it 100 kilobytes if you make the client do more work.

5:02如果是 100 KB，乘上每 byte 64 gas，鏈上成本就是 640 萬 gas。所以基本上，如果每個人都變成有隱私又抗量子，今天的以太坊大概連 0.5 TPS 都做不到。這是問題。還有另一個問題。大家都愛去 All Core Devs，說服以太坊採用自己最愛的簽章方案。有時是 passkeys，有時是 EdDSA、Curve25519，有時是一條新的 BLS 曲線，有時是另一條 BLS 曲線，有時是 ML-KEM，有時 ML-DSA，有時是 Falcon。If it's 100 kilobytes, then multiply by 64 gas per byte, the cost is going to be 6.4 million gas on-chain. So basically, if everyone becomes private and quantum-safe, Ethereum as it exists today will be able to do like less than one half of a TPS. So this is a problem. Now, another problem. Everyone loves trying to go on ACD and convince Ethereum to adopt their favorite signature scheme, right? Sometimes it's passkeys, sometimes it's EdDSA, Curve25519, sometimes it's a new BLS curve, sometimes it's a different BLS curve, sometimes it's ML-KEM, sometimes ML-DSA, sometimes it's Falcon.

5:51問題是，如果你想全部支援，協議會膨脹到不行。如果你不支援，這些東西用裸 EVM 實作，gas 會非常高，也是數百萬 gas。這是四個問題，我會主張 EIP-8288 四個都能解。解法是這樣。不要把這些複雜簽章跟證明都放上鏈，我們改在鏈下把它們全部聚合，用單一證明取代使用者送出的所有物件。每個區塊會有一個證明，這一個證明會取代每一個簽章、每一個做成 EIP-8288 相容的 STARK，全部收成一個物件，證明被收進來的所有陳述都為真。The problem is that, like, if you try to support all of this, then the protocol will just become extremely bloated, right? If you don't, then all of these things would, if you try to implement them with raw EVM, they will cost a huge amount of gas, also millions of gas. So these are four problems, and I will argue that EIP-8288 can solve all four of them. So here is the solution. Instead of putting all of these complicated signatures and proofs on-chain, what we're going to do is we're going to aggregate all of them off-chain and replace all of the objects that users send with a single proof. So every block will have one single proof, and the one single proof will replace every signature, every STARK made to be EIP-8288-compatible, and replace them all with one single object that attests that all of the statements that are being included are true.

6:52依賴框架與記憶體池聚合

6:52從使用者這邊，他們會送出一筆交易，交易帶著簽章跟 STARK，進記憶體池。記憶體池裡節點做聚合，證明這些簽章跟 STARK 存在，全部收成一個由區塊建造者做出、放進區塊的證明。實作方式是新增一種給依賴用的 frame 類型。這建立在 EIP-8141 之上，8141 很可能進 H-star。這種 frame 每一個預期是 96 bytes。So users, from the user side, they will send a transaction, and that transaction will come with a signature and a STARK. That goes into the mempool. In the mempool, nodes aggregate, so they prove that there exist these signatures and STARKs, and it all gets aggregated down to one proof that gets created by the block builder that goes into a block. So the way that this is implemented is there is a new frame type for dependencies. So this builds on top of EIP-8141, which is likely to go into H-star. And the way that it works is that, in each frame of this type, it expects 96 bytes.

7:43其實可以是 96 乘 k bytes。一個依賴 frame 裡可以放多個依賴，每 96 bytes 裝三個物件。有一個 scheme，現在只有兩種：要嘛是 LeanSPHINCS 簽章，要嘛是 LeanSTARK。然後是訊息雜湊或資料雜湊。再來是 SPHINCS 公鑰雜湊或 STARK 驗證雜湊。這可以代表兩種不同的事。如果 scheme 是 10，基本上是說存在一個對 M、也就是對訊息雜湊、能對上公鑰雜湊的簽章。如果 scheme 是 11，則是存在一個能對上公開輸入的證明，而陳述由雜湊等於驗證雜湊的驗證金鑰定義。Actually, it can be 96 times k bytes. You can have multiple dependencies in one dependency frame, and each 96 bytes contains three objects. There is a scheme, and right now there's just two schemes. Basically, either it's a LeanSPHINCS signature, or it's a LeanSTARK. Then you have a message hash or a data hash. And then you have a SPHINCS public key hash or a STARK verification hash. And there's two different things that this could represent. If the scheme is 10, then basically it says there exists a signature of M that verifies, so of the message hash, that verifies against the public key hash. If the scheme is 11, then there exists a proof that verifies against the public input, with a statement that's defined by a verification key whose hash is the verification hash.

8:42所以依賴 frame 基本上只是說：這是我主張的陳述，證明在別的地方。有一個區塊層級的單一 STARK，證明這些陳述都有有效簽章、有效證明存在。這是一種不太一樣的開發方式。因為你不是在 EVM 裡直接做驗證，也不是把所有東西 inline 進去。你做的是把計算切開：這邊是計算的一部分，它假設簽章有效、證明有效、一切都沒問題。So a dependency frame basically just says, here is a statement that I am asserting, and somewhere else there is a proof of it. There is a single block-wide STARK that is attesting to the existence of valid signatures and valid proofs for all of these statements. Now, this is a somewhat different way of doing development, right? Because you're not doing verification directly inside of the EVM. You're not kind of inlining everything. What you're just saying is you're splitting up the computation, and you're saying here is one part of a computation that assumes the signature is valid, it assumes the proof is valid, it assumes everything is fine.

9:28然後另有一部分計算，真正去檢查簽章跟證明存在。我們把第二部分整段換成一個大證明。在記憶體池裡，基本上每個節點跑同一套演算法。節點在看、在接收進來的物件。我們叫它們 envelope。記憶體池裡每個節點等待、收下進來的 envelope，然後每個 tick、大約每半秒，輸出一個 envelope。它輸出的 envelope 裝著它看到的每一筆交易，加上一個單一證明，證明每一筆交易都有對應證明。And then there is a separate part of the computation which actually checks that the signatures and the proofs exist. And we're taking the second part and we're just replacing it with one big proof. So, the way that this works in the mempool is basically every node in the mempool is running the same algorithm. So a node is watching and it's accepting incoming objects. Well, we call them envelopes. So every node in the mempool, it waits, it accepts some incoming envelopes. And then every tick, about every half second, it outputs an envelope. And the envelope that it outputs contains every transaction that it saw, plus one single proof that verifies that every transaction has a proof of it.

10:19遞迴證明與 RISC-V

10:19所以有證明遞迴在發生。證明進來，再輸出一個涵蓋所有證明的證明。你把這條路徑追完，問開銷是什麼？會發現交易跟現在一樣。開銷是 STARK，每個節點每個 tick 輸出一個 STARK。這種情況大概每半秒 100 到 300 KB。以現在的網路連線完全做得到。所以開銷其實很好管，也不會隨量上升。主要成本是節點得做很多聚合，而這件事已經在 Lean Ethereum 的工作裡被很用力地最佳化。So there is proof recursion going on. You have proofs that are coming in, and then you have a proof of all of the proofs coming out. And so, if you trace this through and you ask the question, well, what is the overhead of all of this? You will notice that you have the transactions, the same as we have now. The overhead is the STARKs, and every node is outputting one single STARK every tick. So in this case, 100 to 300 kilobytes maybe every half second. This is completely viable with modern internet connections, right? So the overhead is actually very manageable, and it does not go up with the amount of volume. The main cost here is basically that nodes have to do a lot of aggregation, and this is something that is already being heavily optimized as part of the Lean Ethereum effort.

11:13因為我們需要同一套技術，才能有有效率、抗量子的共識層。所以記憶體池裡每個節點都這樣做：收交易、收 envelope、輸出 envelope。那些 envelope 帶證明。因為有這些證明，每個節點在每一步都有把握交易裡的依賴都正確，而且手上有證明。但原始簽章、原始證明，連第一個節點都過不去。我們怎麼想這件事？EIP-8288 在做的事，我覺得有幾種看法。其中一種：這是計算的超擴容。Because we need the exact same technology to have an efficient quantum-secure consensus layer. So basically every single node in the mempool does this. It accepts transactions, it accepts envelopes, it outputs envelopes. Those envelopes have proofs. And so, because of those proofs, every node at every step is confident that all of the dependencies in the transactions are correct, and it has a proof that they're correct. But the original signatures, the original proofs, they don't even make it past the first node. So how do we think about this? I think there are a few different ways to think about what EIP-8288 is doing. So. One of the ways to think about it is this is hyperscaling computation.

12:01它也是資料的超擴容，所以有點像分片，但是特化的分片。針對的是這種情況：你的計算跟以太坊其餘部分的互動，只是在驗證一個主張。你有一個大 blob。這個 blob 驗證起來通常要 100 萬 gas，而它存在的唯一目的就是證明某件事。如果是這種情況，就把它換成證明。然後記憶體池再把每個人的證明收成一個證明。另一件有意思的是，搭配 STARK 證明系統，這也像是把新的 VM 引進以太坊的一大步。It's also hyperscaling data, so it is like sharding, but it's a specialized kind of sharding. It's sharding for the specific case where you have a computation that's only interacting with the rest of Ethereum by verifying a claim. So you have one big blob. The blob would normally cost a million gas to verify, and all that that big blob is there to do is to prove something. If that's what you have, then you replace it with a proof. And then the mempool replaces everybody's proofs with one single proof. One other interesting thing that this is doing is with the STARK proof system, this is also like a big step of introducing a new VM to Ethereum, right?

12:47到目前為止，以太坊承認的唯一 VM 是 EVM。這裡等於直接把這些證明寫成的某種語言寫進以太坊。目前領先的候選是 RISC-V。就這個意義來說，對以太坊也是一大步。我談加入 RISC-V 或類似的東西，大概至少兩年了。這很可能是它第一次發生的方式。另外，我們開始更明確地把計算分成兩種。一種我稱為業務邏輯，基本上就是如果這樣，就那樣。So, so far, the only VM that Ethereum recognizes is the EVM, and here this is saying this is actually directly enshrining some kind of language that these proofs are written in into Ethereum. And currently the leading contender is RISC-V. So it's a big step for Ethereum in this sense as well. You know, I've been talking about adding RISC-V or adding something similar for at least, I think, the past two years now. This is likely to be the first way in which it happens. Also, this is—we're starting to do some much more explicit separation of computation into two kinds of computation, right? So you have what I call business logic, which is basically, you know, if this, then that.

13:37業務邏輯與依賴分開

13:37例如在多簽錢包裡，你有兩個有效簽章，就可以把錢送出去。然後你有依賴，真正在驗證那些簽章。現在從以太坊協議的角度看，這些全是一團。這裡我們說：不行，使用者必須宣告：這是業務邏輯，這是依賴。好處是依賴可以被超擴容，剩下的業務邏輯變輕、變乾淨。連分散式區塊建造裡依賴排序的那部分也會變容易。這些是思考這裡在發生什麼的幾種方式。If you, like, in a multisig wallet, you know, if you have two valid signatures, you're allowed to send the money. And then you have dependencies, which are actually verifying the signatures. So right now, from the Ethereum protocol's point of view, all of those things are just one big blob. Here we're saying, well, no, users have to declare: this is business logic, this is dependencies. And the benefit that you get is basically that dependencies become hyper-scaled, and then the remaining business logic becomes lighter, it becomes cleaner. And so it actually even allows the ordering-dependent parts of distributed block building to become easier. So these are kind of some of the ways to think about what's happening, what is happening here, right?

14:26但高一層看，真正在發生的是什麼？這是一種特定形式的以太坊超擴容：讓我們很在意、但今天極貴的事變得便宜得多。今天大家都在意要抗量子。問題是，抗量子會讓所有東西貴十倍。有了 EIP-8288，抗量子會變得比今天還便宜。為什麼？因為簽章不會上鏈。簽章過不了第一個記憶體池節點。But, like, what is really going on at a high level, right? What's going on is basically that this is a particular form of hyper-scaling Ethereum, of making it much, much cheaper to do the things that we care about a lot that are at the same time extremely expensive today, right? So today, everybody cares about becoming quantum-safe. The problem today is that becoming quantum-safe makes everything ten times more expensive. With EIP-8288, becoming quantum-safe becomes even cheaper than today. Why? Because the signatures are not going on-chain. The signatures do not make it anywhere later than the first mempool node.

15:12簽章一進記憶體池，記憶體池就把它們聚合，全部換成一個大證明。今天我們在意隱私。問題是有隱私很貴。有了 8288，有隱私會變便宜。有隱私甚至可能比今天沒隱私還便宜。為什麼？因為 ZK-SNARK 不必上鏈。ZK-SNARK 只到第一個記憶體池節點，從那之後就被聚合。所以今天 gas 極貴的任何事，都會有辦法變便宜得多。做法基本上是：不要試圖同時擴容整個以太坊，先找出最需要擴容、又有特殊性質所以比較好擴的那些部分。As soon as the signatures make it into the mempool, the mempool aggregates them, and it replaces all of them with one big proof. Today, we care about privacy. The problem is being private is expensive. With 8288, being private will be cheap. Being private may be cheaper than not being private is today. Again, why? Because the ZK-SNARKs do not have to go on-chain. Instead, the ZK-SNARK only makes it to the first mempool node, and then from that point forward, it gets aggregated. So anything that you want to do that's extremely gas-expensive today, there will be ways to make it much cheaper, right? So, and the way that this is happening is basically, we're saying—instead of trying to just scale all of Ethereum at the same time, we're going to figure out the parts of Ethereum that both need scaling the most and that have special properties that make them easier to scale.

16:16最好擴的其實是簽章跟證明。把驗證分片、把資料分片，正是 EIP-8288 在做的。另一件你會注意到的是，開發體驗在變。我的一種想法是：以太坊有一點變得更像比特幣。看一筆比特幣交易在做什麼，它裝著一堆輸入。每個輸入都在說這必須為真、這必須存在、這必須未花費、你需要這種簽章。所以在比特幣裡，每筆交易都是依賴。And the easiest thing to scale is actually signatures and proofs. And sharding the verification, sharding the data, is exactly what EIP-8288 is doing. Another thing you notice is that the developer experience here is changing, right? And here, one way that I think about this is that Ethereum is sort of becoming a little bit more like Bitcoin, right? So if you look at what a Bitcoin transaction does, a Bitcoin transaction, it contains a bunch of inputs, right? And every input is saying this has to be true, this has to exist, this has to be unspent, this, like, you need this kind of signature. And so in Bitcoin, every transaction is a dependency.

17:02開發體驗與問答：安全位元

17:02一切都有點非常靜態型別。沒有那種動態物件，讓你可以算出一個位址再在那個位址改東西。就計算能力來說很受限，但對擴容很好。我們開始在做的是：讓以太坊更靜態型別一點。讓以太坊更像一個你必須宣告「這段計算是哪一類計算」的環境。好處是，如果那類計算好擴，你就得到多得多的擴容。會變得非常便宜。你可以省很多 gas。等這件事進來時，以太坊應該能處理數百筆隱私 TPS，幾乎跟處理數百筆非隱私 TPS 同時做得到。Everything is kind of very statically typed. Like, you don't have any dynamic object where there is some address that you can compute and then modify at the address. And this is very restrictive in terms of computational power, but it's also good for scalability. And so what we're starting to do here is we're starting to say, well, let's make Ethereum a little bit more statically typed. Let's make Ethereum a little bit more of an environment where you have to declare what type of computation your computation is. And then the benefit that you get is, if it's a type of computation that's easy to scale, then you get much more scaling. It becomes extremely cheap. You can save a lot of gas, and Ethereum should be able to process, by the time this comes in, hundreds of private TPS almost at the same time as it would be able to process hundreds of non-private TPS.

17:59處理數百筆非隱私 TPS。我希望我們能看到更多實作工作。證明遞迴已經開始有測試，也有很多研究，希望這是我們能繼續做、而且真的做下去的方向。希望在以太坊有帳戶抽象之後很快上線，希望是明年。謝謝。謝謝。再次謝謝。我們有幾分鐘問答。to process hundreds of non-private TPS. So this is something that I hope that we can see more work on implementing. There are already starting to be tests on proof recursion, a lot of research on proof recursion, and hopefully, yeah, this is a direction that we can continue building and, like, actually, yeah. Hopefully get live, like, very soon after we have account abstraction in Ethereum, hopefully next year. So thank you. Thank you. Thanks again. So we have a few minutes for the Q&A.

18:45有問題嗎？哪一位？你可以決定。好。我想問的是，我對現有生產級 STARK 系統的理解是它們還沒到 128 位元安全。我好奇你怎麼看這類證明的安全性。真的需要 128 嗎？另外我的理解是，它們現在不只還沒到 128，就連用的假設，要用我們需要的速度走到 128，可能都很難。對，我覺得這些在一年前完全成立，但已經改善很多，尤其最近幾個月。Any questions? Which one? Can you decide? Okay. I was wondering if my understanding of all the production STARK systems is that they are not 128-bit security yet. So I'm curious, like, how you think about, like, security for these kinds of proofs. Like, do you actually need 128? And also, my understanding is that even they're not 128 now, and even the assumptions that they use, it's, like, very maybe unlikely that we would get to 128 with the speeds that we need. Yeah, I think a lot of that was completely true a year ago, but it's improved a lot, especially in the last few months.

19:37Justin Drake 一直很堅持把這件事釘死，基本上是說：去年是讓證明成為可能的一年，今年是清理的一年。所以我相信我們已經把目標改成至少 120 位元安全。有時從 120 再走到 128 可能太費工，因為永遠都是雜湊寬度的一半，再除以 n 或根號 n，120 大概就夠了。不過，其中一個大缺口一直是猜想對上可證明這件事，最近有一些工作在把這個缺口縮小。I mean, Justin Drake has been, like, very insistent on kind of putting down the hammer and basically saying, you know, last year was the year of making proofs possible. This year is the year of kind of cleaning up. And so I believe, like, we've already moved to a goal of having at least 120 bits of security. And, like, it's probably too much effort to try to go, sometimes, from 120 to 128 because, you know, it's always kind of half the width of the hash and then, like, divided by n or square root of n, and kind of 120 is enough, right? And, but then. There, one of the big gaps has been this whole kind of conjecture versus provable thing, and there has been some work on narrowing that gap recently.

20:24隱私協議怎麼改寫合約

20:24其實這就是我稍早講的其中一場 AI 競賽在做的。Justin 也堅持：現在要被接納的東西，必須可證明。這是對的。至於原始效率，Lean VM 最近正式改成以 BLAKE 為基礎。過去兩三個月我們從 Poseidon 切到 BLAKE，還有正在進行的形式化證明工作。遞迴步驟也在最佳化。遞迴步驟在 CPU 上已經能跑到幾百毫秒。而且是帶著 120 位元以上安全、可證明、所有好參數的那種。Actually, that's what one of the AI contests that I talked about earlier is. And also, Justin has been insistent that anything that's admissible right now, it has to be provable. So that's true. And then, in terms of kind of raw efficiency, so. Lean VM recently kind of officially moved over to being based on BLAKE, right? So we switched over from Poseidon to BLAKE over the last kind of two or three months, and there is ongoing work on formally proving it. There is work on optimizing the recursion step. The recursion step can run already in hundreds of milliseconds on a CPU. And so that's with, you know, 120-plus-bit security, with, you know, provable, all of the good parameters.

21:12所以我想，這整塊最近幾個月真的有非常大的改善。謝謝。我們還可以再一個問題。我想問，你提到開發體驗會不一樣，我在想像如果放到我的一些合約裡會怎樣。我在合約裡放過 SNARK，以我的理解，你還是得把全部 calldata 放進去，然後你還得。好，這裡。我們走一個例子。假設你在寫一個隱私協議。So it's, so I think it's, it's like there has been a really huge amount of improvements on all of that, especially over the last couple of months. Yeah, I think. Thank you. So we can have one more question. Oh, I just wanted to, you touched on that the developer experience would be different, and I'm just imagining what it would be like as putting it in some of my contracts. So I've put, like, SNARKs in my contracts, and from what I understand, it's, you're putting, you would. You still have to put all the calldata in that, and you would have to. Yeah, okay, here. So let's, like, go through an example, right? So let's say, for example, you're writing a privacy protocol, right?

22:00像 Railgun 那種。今天，使用者的交易是，我們暫時假設已經有 frames，先忘掉抽象包裝那些。今天……你會有 SNARK，現在大概 500 到 1,000 bytes，抗量子之後大概 300 KB。那是 calldata 的一部分。然後你有 EVM 程式碼，跑在以太坊主迴圈裡。在 frames 裡，它會是驗證階段的一部分。所以會是 verify frame 的 calldata，基本上就當成主執行的一部分來跑。這大概是今天、或很快會是的樣子。有了 8288，會變成兩個 frame。Like, you know, you have something like Railgun. Today, the user's transaction is—and let's, like, temporarily, you know, like, assume we have frames, so, like, forget about, like, abstraction wrapping and so on, right? So today... You would have the SNARK, so which is, you know, today about, like, 500 to 1,000 bytes, and then post-quantum it's like 300 kilobytes. That's part of calldata. And then you have EVM code that is running as part of, you know, like Ethereum's main loop. In frames, it would be part of the verification phase. And so, like, it would be calldata of the verify frame, and—it would basically just, you know, like, be run as part of main execution, right? So that's kind of like today, or very soon. With 8288, what would happen is you would have two frames.

22:47你在鏈上證明的任何陳述，永遠會有一個驗證金鑰，再加上公開參數的雜湊。你會把驗證金鑰跟公開參數放進這個依賴 frame。然後你還會有一個 verify frame。verify frame 不再做驗證本身，它只用一種跨 frame 內省的 opcode，像 TXPARAM 或 FRAMEPARAM，去檢查依賴 frame 是否存在。所以 verify frame 做的事，就是驗證依賴 frame 存在。使用者送出交易時，交易會被包進記憶體池層一個叫 envelope 的物件：裡面有交易，另外還有驗證依賴 frame 裡那個陳述的 STARK。So you would take the—so any statement that you're proving, right, on-chain, there's always like a verification key, and then you have the hash of the public params, right? And what you would do is you would take the verification key and the public params, and you would put that into this dependency frame. And then you would also have a verify frame. And then the verify frame, instead of doing the verification, all that it would do is it would use a kind of cross-frame introspection opcode like TXPARAM or FRAMEPARAM, and it would basically check for the existence of the dependency frame. So the verify frame, all it does is it verifies that the dependency frame exists. Now, when you send, when a user sends a transaction, the transaction would be wrapped in a mempool-layer object that's called an envelope, where you have the transaction, and then separately you would have the STARK that verifies, like, basically the statement that's in the dependency frame.

23:50信封、聚合與鏈上看到的東西

23:50節點要收下它：記憶體池裡的節點不會收含有依賴 frame 的裸交易。含依賴 frame 的交易，只有包在 envelope 裡才會被收。所以記憶體池節點會在 envelope 裡看到你的交易，envelope 裡交易大概幾百 bytes，STARK 大概 200 KB，然後它們驗證這個 STARK，再把它換成聚合證明。你的交易會完整上鏈，但 STARK 被遞迴 STARK 取代。所以你基本上把「你在證明的陳述」跟「證明邏輯」完全切開，證明邏輯走另一條通道被驗證、被聚合。For a node to accept it, like, nodes in a mempool, they will not accept raw transactions that contain dependency frames. They accept transactions that contain dependency frames only inside of an envelope. And so a node in a mempool, they would see your transaction in an envelope, and then in the envelope the transaction would be like a few hundred bytes, and then the STARK would be, yeah, like 200 kilobytes, and then they would verify this STARK, and then they would, like, replace it with an aggregated proof. And then your transaction fully makes it on-chain, but then the STARK gets replaced with a recursive STARK. So you're basically fully separating out kind of the statement that you're proving from the proving logic, and then the proving logic gets verified and aggregated through a completely separate channel.

24:38我懂了。好。我覺得從 RPC 角度看，不會差太多。基本上，要生成證明，你需要一些私密資訊，然後你還得去抓存款根、Merkle 樹、以及已經發生過的那些事。要生成這種交易，你需要的資料基本上跟今天生成一筆交易需要的一樣。然後你廣播，廣播進記憶體池。或者也可能廣播給一個 RPC 節點。RPC 節點會是這個記憶體池的一部分。I see. Okay. I think from an RPC perspective, it's not going to be that different. Basically, yeah, like, to generate a proof, right, you need some private information, you know, you need, and then the— There is, like, information you have to grab about, like, the deposit root and the Merkle tree and all of the things that happened already, right? And then from—and then to generate one of these transactions, like, the data that you need to generate a transaction is basically the same as the data that you need to generate a transaction today. And then you broadcast, and you broadcast into the mempool. And/or potentially you could broadcast to an RPC node. An RPC node would be part of this mempool.

25:28從那之後你就不用管了。它會被聚合。等它被收進鏈上，你看到的最大差異大概是：上鏈的東西不會包含你的 envelope。上鏈的只是裸交易。所以你看不到自己的證明，只能看到所有人證明的那個證明。好，時間差不多了。謝謝 Vitalik 分享 EIP-8288 的見解。And then from there, you don't care. It would be aggregated. And then when it gets included on-chain, probably the biggest difference that you see is that, like, the thing included on-chain is not going to include your envelope. The thing included on-chain is just the raw transaction. And so you're not going to be able to see your own proof. You're just going to be able to see the proof of everyone's proof. All right, so we are running out of time. So thank you, Vitalik, for sharing the insights on EIP-8288.