ETHSystem：公鏈透明，為何擋住機構進場？

0:00開場：ETHSystem 從以太坊基金會獨立，談機構隱私

0:00大家好。我叫 Oskar。這場我會用英文講。所以，大家好。我叫 Oskar。今天要講的是給機構用的以太坊機密系統。我們最近從以太坊基金會獨立出來，先前在那邊做了很多機構隱私，現在有一個新的實體叫 ETHSystem，這就是我今天要講的。一點背景：機構在以太坊上在找什麼、我們做過的驗證，以及你們可以怎麼用這些工作。去年我講過一場比較偏哲學的。Hi everyone. My name is Oskar. I will give the talk in English. So, hi everyone. My name is Oskar. I'm going to talk to you about confidential systems for institutional Ethereum. So, we recently spun out of the Ethereum Foundation, where we worked a lot on institutional privacy, and have a new entity, ETHSystem, and that's what I will be talking about today. A little bit of context when it comes to what institutions are looking for on Ethereum, some proof of work we've done, and how you can use the work we've been working on. So last year, I gave a slightly more philosophical talk.

0:45我那時在看加密貨幣圈裡不同的運動，像 cypherpunk、d/acc、lunarpunk、solarpunk，他們看事情的角度不同，在意的東西也不同。但他們關心的問題常常有很窄的交集，多半跟信任有關。你要怎麼在規模上信任？怎麼在沒有由上而下的中心設計裡，處理真實性、隱私與問責？過去這一年我把問題收窄、講得更實務：機構要怎麼在以太坊上建設，怎麼想信任問題，怎麼做信任最小化的設計。I was looking at different sort of movements in the crypto space, whether it's, like, the cypherpunk movement, d/acc, lunarpunk, solarpunk, and so on, and how they kind of look at things from different angles, and they care about different things. But oftentimes there's, like, a very narrow intersection as well in terms of the problems they care about. And this is usually related to trust. So how do you trust at scale? How do you deal with things like authenticity, privacy, and accountability without having this kind of central, top-down design? The last year I've been focusing on part of that problem, but sort of a bit more narrow and practical when it comes to how institutions can build on Ethereum and how to think about trust problems and sort of building these trust-minimized designs.

1:35這幾年監理變清楚很多。這以前是大規模採用的大阻礙，尤其是受監理的機構。這幾年我們看到美國的 GENIUS Act、歐盟的 MiCA，台灣、新加坡、香港、日本也有各種努力。法規與法律明確性還有很多要做，但比幾年前好很多。過去一年我們跟上百家機構談過，隱私現在才是主阻礙，尤其是要搬上以太坊這種公鏈，因為他們本來就有一套能跑的系統。So one thing that's been happening over the last few years is that there's been a lot more regulatory clarity. So that used to be a big blocker in terms of mass adoption, especially when it comes to sort of more regulated institutions. The last few years, we have seen things like the GENIUS Act, we have MiCA in the EU, and there's various other efforts in Taiwan and Singapore and Hong Kong, Japan, and so on. So while there's still a lot more work to be done on the sort of regulation side and sort of legal clarity, we're in a much better spot now compared to a few years ago. And from our conversations with hundreds of institutions over the last year, privacy is really the main blocker now, especially when it comes to moving onto public blockchains like Ethereum, because they have a system that already works.

2:21他們一要建在公共基礎建設上，很多假設就得被挑戰，而且要用嚴謹的方式去做，這很難。以太坊的好處就是我們喜歡的那些：去中心化。它像機構的謝林點。沒有人控制整個生態系，有流動性、有結算最終性。以太坊最大的問題顯然是它是公開的，帳本公開，部位與關係很容易被看見，你可以從中推很多東西。在機構裡這很麻煩：競爭對手看到的，跟稽核看到的，沒有差別。And when they want to build on public infrastructure, all of a sudden there's, like, a lot of assumptions that have to be challenged, and how to do that in, like, a rigorous way is, like, a big challenge. And obviously, Ethereum is good for all the reasons we like it: the decentralization. So it's kind of like a Schelling point for a lot of institutions. There's no one who controls the entire ecosystem, access to liquidity, settlement finality, and all that good stuff. The big problem with Ethereum is obviously that it's public, so the ledger is public and it's very easy to see positions and relationships, and you can infer a lot of things from that. And it's a big problem in an institution where sort of you can't really—there's no difference between what a competitor sees and what an auditor sees.

3:13隱私靠政策還是靠數學

3:13所以這是個大問題。怎麼想這件事，大概有兩類做法。一個是靠政策做隱私，一個是靠數學做隱私。靠政策大家比較熟，就是資料孤島，相信第三方，靠法治與善意。有些情境有用，我們也不完全排除。但這套技術有趣的地方，是讓我們可以相信自己蓋出來的系統，相信數學。例如用 SNARK 證明去驗證某些事，只揭露一部分資訊。我會說，如果你要搬上區塊鏈，更合理、也更有意思的方向是靠數學做隱私，才真的用到公鏈能給的東西。當然不是這麼黑白。So that's, like, kind of a big problem. In terms of how to think about this, there's, like, two classes or approaches you can think about. Like, one is privacy by policy, and the other is privacy by math. Privacy by policy is maybe what most people are more familiar with. So it's kind of like these data silos, kind of just trusting a third party and relying on sort of rule of law and goodwill and so on. And while that can be useful in some cases, and we don't want to rule it out completely, some of the things that are interesting about this technology is that it enables us to trust these systems we build up, sort of trusting the math instead. So, for example, using SNARK proofs to verify certain things while only revealing a subset of information. And I would argue that if you're going to move onto blockchains, it makes more sense and it's more interesting to go in the direction of, like, privacy by math, to actually take advantage of everything that public blockchains allow. Obviously, it's not as black and white as this.

4:09中間地帶很多，但就偏向來說，靠數學做隱私比較有意思，也是我們比較專注的。過去一年我們一直在畫這個版圖、搞懂它長什麼樣子。跟機構談時，我常想搞懂具體問題是什麼、商業問題是什麼，用他們自己的語言聽，不管是商業現實、法律限制還是其他限制，再歸成使用情境。這些不是我們自己想出來寫部落格的使用情境，是跟上百家機構談過之後來的。這是開源資源，你們可以去看這些使用情境。There's, like, a lot of middle ground, but in terms of bias, I think the privacy by math is more interesting and what we are more focused on. So one thing we've been doing a lot the last year is trying to map the space and understand what it looks like. And when we talk to institutions, often I try to understand, like, what are the specific problems? What are the business problems? I try to understand how they think about it in their own terms, whether it's, like, business reality or legal constraints or other types of constraints, and basically try to categorize that in terms of use cases. So these are not just use cases we sort of dreamt up and wrote a blog post about. This is based off conversations with hundreds of institutions. So this is an open-source resource that we have that you can look into and sort of see these use cases.

4:54然後我們還有模式。就是以太坊生態裡已經存在、用來解某類問題的協定或做法，以及思路，也就是你該怎麼想這些問題。不一定是用這個標準、用這個函式庫。也可能是用帶 SLA 的供應商這類東西。這份 Privacy Market Map 可以去看，裡面有很多使用情境的資訊。講具體一點，我們跟一個使用情境：隱私穩定幣支付。一聽到隱私穩定幣支付，可能覺得就一件事。但其實差很多，看你在講什麼。Then what we have is also, like, patterns. So these are protocols or ways of solving certain problems that exist in the Ethereum ecosystem, as well as approaches, so, like, how to think about solving these problems. And that might not just be, use this standard or use this library. It might also involve using certain vendors that come with, for example, SLAs and these types of things. So this Privacy Market Map, you can check it out, has a lot of information about various types of use cases and so on. To make it a little bit more concrete, we'll follow one sort of use case when it comes to private stablecoin payments. So first of all, when we hear private stablecoin payments, we might think, well, that's just simple. That's one thing. But actually, it's very different depending on what are we talking about.

5:40地區就不同，美國、歐洲、台灣、日本，機構面對的限制不太一樣。支付類型也非常不同。是十家銀行每天互相結算數百萬，還是要給一億個零售使用者、讓終端使用者買杯咖啡？使用情境的細節會大幅改變設計。但一般需求可能是要藏金額或對手方，做法也不同。你可以在 Layer 1 做隱私池，可以有某種隱私 L2，或用 Plasma 設計。我們會拿這些做法去做原型，因為你常聽到一個新專案聽起來超厲害，有史以來最好，結果程式跑起來編譯不過，或他們宣稱的吞吐量根本不是現實。It's different in terms of the region, if it's U.S., if it's Europe, if it's Taiwan, if it's Japan, or whatnot. Like, the constraints that these institutions operate under are slightly different. And it's also very different in terms of what type of payments are we talking about. Is it, like, 10 banks that are settling millions among each other every day, or is it a retail payment for 100 million users where you want to enable end users to buy a cup of coffee? So depending on the specifics of the use case, that has dramatic implications for the design. But generally, requirements might be something you want to hide the amounts or the counterparties, and then there's different types of approaches how you do that. So you might do a privacy pool on Layer 1, you might have some kind of privacy L2, or use a Plasma design, and so on. And then what we try to do is we try to take these approaches and do, like, prototype work with them, because oftentimes what you see is maybe you hear about a new project and it sounds amazing, the best thing since sliced bread, but then you try to run the code and it doesn't even compile, or their, like, throughput requirement, what they claim to be able to provide, is not at all what reality looks like.

6:44沒有萬靈丹，先對使用情境做概念驗證

6:44所以真的要把東西跑起來，搞懂真實世界怎麼運作，這很重要。我們畫這個版圖時注意到一件大事：沒有銀彈。你常碰到產品說，用我們的就好，你的問題都會解決。然後你再問另外十個人，他們講同一句，只是方案全不一樣。這告訴我，這裡真的沒有銀彈。你得想自己使用情境的細節，取決於很多事，例如執行要怎麼做、延遲與吞吐量的功能需求、揭露需求、誰來營運、復原要怎麼想。一進到機構真正要的細節，要考慮的很多，不是一個設計就能套所有人。So it's very important to actually run this stuff and understand how it works in the real world. And one big thing that we've noticed as we've been mapping this space is that there's really no silver bullet. And oftentimes you come across products and they might say, just use our thing, it will solve all your problems. And then you talk to 10 other people and they say the exact same thing, except that all of the solutions are different. So what that tells me is that there's really no sort of silver bullet here. You really have to think about, like, what are the specifics about your use case, and it depends on a lot of things, like, for example, how you want to do execution, what your functional requirements are when it comes to sort of latency and throughput, what sort of disclosure requirements you have, who's going to sort of operate it, how do you want to think about recovery, and so on. So once you get into the details of what these institutions actually need, there's, like, a lot of things to consider, and it's not just one design that fits everything.

7:36我們也會想兩類問題。如果你自己是終端使用者，看新聞或加密貨幣 Twitter，可能會以為多數是機構對終端使用者，也就是零售穩定幣這類。這確實存在，也很重要。但我們在對話裡注意到，比較有意思的問題多半在機構對機構。那是這個世界的管線，很多支付基礎建設，銀行互相講話，或結算基礎建設，很底層，除非你懂他們的商業問題，否則碰不到。我也會說，跟這些機構談時，某種程度上，他們對隱私、抗審查這類 cypherpunk 價值的在意，甚至高過很多 Web3 原生圈的人，正因為這對他們的損益影響非常大。Also, one thing we think about is, like, two different kind of classes of problems, if you will. And if you sort of, as an end user myself, if you look at news or crypto Twitter or whatever, you might think that most of it is, like, institution to end users. So that's kind of like your retail stablecoins and so on. And while that's definitely a thing, and it's important, I would argue that in our conversations, we notice that most of the sort of interesting problems and so on is more on the institution-to-institution side. So that's kind of the plumbing of the world, like a lot of payment infrastructure and so on, which is, you know, banks talking to each other or some kind of settlement infrastructure that's very much, like, in the nitty-gritty and not something that you would get exposed to unless you actually understand their business problem. And I would also argue that when we talk to these institutions, to some extent, they even care more about sort of some cypherpunk values like privacy and censorship resistance than, like, a lot of people in sort of the Web3-native space, precisely because it has a very massive impact on their bottom line.

8:35他們不想讓競爭對手看到支付流，也很在意抗審查，因為這些往往是比較大的決策，他們想得比終端使用者深。我們兩邊都做，動態不太一樣，但機構對機構這邊我們著墨很多。有些公開、開源的工作可以看我們做了什麼。過去一年我們做了總共 12 個公開的概念驗證。開原始碼、寬鬆授權。都有規格書跟嚴謹的威脅模型。也都有寫作說明。沒時間每個細講，我會帶幾個、給個概觀，有興趣可以上官網看。They don't want competitors to see their sort of payment flows, and they care a lot about censorship resistance because oftentimes these are bigger decisions, and they put more thought into it compared to what an end user might do, might want to do. So we deal with both, and they have slightly different dynamics, but we focus a lot also on the institution-to-institution side of things. So some things that we've been working on that are sort of public and open source, just to see some work we've done. So over the last year, we've done 12 total POCs that are public. So these are open-source code, permissive licensing. They all come with, like, a specification and rigorous threat model. We also have write-ups for all of these. I won't have time to go into all of them in detail, but I'll touch on some of them a little bit, give an overview, and if you're interested, you can go to our website and read more.

9:25第一個是私募債，我們試了三種做法。私募債有意思，是因為需求不算少。基本上是讓機構發行私募債時可以更單純，可以有單一登記，不必處理一串保管人，也能接到流動性與對手方。做法有幾種。一種是私有票據模型，寫電路、跑在 L1。另一種是用隱私 L2，這裡是 Aztec。第三種是 FHE 加 Zama。還有更多做法，但這三個相當有代表性，都成立，但非常看細節。So the first thing is private bonds, where we tried three different approaches. And private bonds is kind of interesting because we see a reasonable amount of demand for it. And basically, it's a way to simplify things for institutions where they want to issue a private bond, and they can have a single register, and they don't have to deal with, like, a chain of custodians. And it also gives them access to liquidity and counterparties and so on. There's a few different ways we approached it. So one was kind of a private note model. So this is writing circuits, running on L1. Another one was using a privacy L2, Aztec in this case, and a third one was with FHE and Zama. And all of these, there are more approaches, by the way, but these are three fairly representative approaches, and they all sort of are valid, but it depends a lot on the specifics.

10:16私募債與隱私支付的取捨

10:16所以你得想取捨。例如自訂 UTXO 模型，好處是你有完整控制，但顯然電路得自己寫，對很多機構是重活。Aztec 好在預設就有私有狀態，反過來說你得依賴他們的網路模型與吞吐量。FHE 好在可以加密餘額，但實際運算與解密也有問題。很多取決於時程，以及你精確的需求。我們也注意到，機構能力差很多。So you have to think about the trade-offs. So, for example, when it comes to the custom UTXO model, it's good because you get full control, but obviously you have to write the circuits yourself, which is a heavy lift for a lot of institutions. Aztec is nice because it gives you a private state by default, but on the flip side, you kind of are relying on their network model and the throughput they can have and so on. So FHE is good because you can encrypt balances and so on, but you also have some issues when it comes to actual operations and decryption and so on. So a lot of it depends on the timeline and exactly the kind of requirements you have. And this is something we notice as well, that institutions, they differ a lot in terms of their capabilities.

11:03有些機構自己有三十人的研發部門，裡面有密碼學博士。他們追這個領域十年了，很清楚什麼做得到、什麼做不到。另一邊，有些機構也許去年才開始看，只有一個人，想要比較像白牌的東西。他們只要一個能信任、願意代做的供應商。他們願意跑的基礎建設類型差很多。隱私支付是另一個我提過的例子。很多這類想法源自 Zcash 與遮蔽池這個抽象，後來到以太坊有 Tornado Cash，還有 Railgun、Privacy Pools、Bermuda。So some of these institutions, they have their own R&D department with 30 people and cryptography PhDs. So they know, they've been following this space for a decade. They know very well what's going on and what's possible and what's not. But on the flip side, you also have people or institutions that maybe just started looking at this last year, and they have one person, and they want something that's more like a white-label thing. They just want a vendor they can trust who does things for them. So these differ a lot as well in terms of the type of infrastructure they're willing to run. Private payments is another example that I mentioned. And a lot of this sort of stems from sort of Zcash and the shielded pool abstraction, which later on came to Ethereum with things like Tornado Cash and also Railgun, Privacy Pools, Bermuda, and so on.

11:51所以你有一個基礎遮蔽池，給你一些隱私保證。這也是合規版本，進入時有證明。然後我們做了兩個延伸。一個是用私有資訊檢索把錢包讀取藏起來，以及效能改善，處理 nullifier 成長的問題。我們也做了合規延伸，讓池子裡的私有票據在整個週期維持合規，不只進場出場。然後我們也用 Plasma 和 INTMAX 做了一版原型，那是另一種解法。重點是：受監理機構跟 Web3 加密貨幣原生、完全無需許可的行動者很不一樣，他們在不同限制下營運。So you have a base shielded pool, sort of give you some privacy guarantees there. This is also like a compliant version, so it's attested in terms of entry. And then we did two different extensions. So one was how you can hide sort of wallet reads using private information retrieval, and also how you can do some performance optimization to solve one of the problems when it comes to nullifier growth. We also did a compliance extension where basically you can ensure that private notes that are inside the pool stay compliant throughout the cycle, so not just on entry and exit. And then we also prototyped a version when it comes to Plasma and INTMAX, which is like a different way of solving this problem. So one big thing here is institutions, regulated institutions, they are very different from sort of your Web3 crypto-native, sort of fully permissionless actors, in that they are operating under different constraints.

12:45作為受監理金融機構，你確實有法律要遵守，這不一定是道德問題，就是他們所在的監理框架。這也因所在地差很多。跟機構談，他們有時會做法規套利，找比較有利、能做比較多事的法域。但一般要在意的是：誰能進這個遮蔽池。你會想做某種 KYC。你可能要有一個滾動總額，有個不能超過的門檻。出事要警示。你可能要有稽核軌跡。所以這不是無需許可的池。As a regulated financial institution, you do have certain sort of laws and so on you need to abide by, and it's not necessarily a moral thing. It's just a matter of the regulatory framework that they operate under. And this varies a lot as well depending on where they are situated. And if you talk to institutions, they often sometimes do, like, regulatory arbitrage and these types of things to find a more favorable jurisdiction where they can do more things. But in general, often something to care about is who is able to take part in this kind of shielded pool. So you want to do some kind of KYC or something like that. You might want to have a running total where you have a certain threshold that can't be exceeded. You want to alert things if something happens there. You might want to have some audit trail and so on. So this is not sort of your permissionless pool.

13:32原子交割、自己做 Validium

13:32它是疊在上面、給這些受監理金融機構用的。細節不多講，基本上類似 ZK 池的模型，你可以在 L1 把交易藏起來。在遮蔽池裡做事，產生證明，再在以太坊上驗證。另一個概念驗證是原子結算，特別是款券對付。款券對付某種程度上是法律用語：你有一項資產，資產交付與付款必須在同一時間發生。嚴格來說這比 ERC-20 代幣之間的交換更麻煩，因為常常發生在不同網路上。It's something that's, like, on top that works for these regulated financial institutions. I won't go too much into detail here, but basically it's a similar kind of model to ZK pools where you are able to sort of hide the transaction on L1. And so just do things inside a shielded pool, and you generate a proof, and then that's verified on Ethereum. Another POC that we did was when it comes to atomic settlement, and specifically delivery versus payment. So delivery versus payment is a kind of legal term, if you will, where if you have some asset, the delivery of the asset and the payment of the asset has to happen at exactly the same time. And this is, strictly speaking, a bit more involved than, like, a swap between ERC-20 tokens, because oftentimes this can happen on different networks.

14:22一邊可能是加密貨幣網路，另一邊可能是完全在 Web3 與加密貨幣之外的系統。核心是必須原子：資產交付必須跟付款同時發生。我們用債券與現金做，用 TEE 當協調者，確保這個不變量。結算。另一件很常見的是私有商業邏輯。我們叫它自己做的 validium。比較靠近 ZKsync 風格的構造。基本上你有私有狀態，然後有任意商業邏輯。也許你要做保險，或有一組必須滿足的條件，而你不想寫成電路。So one might be a crypto network and the other might be a completely different system that's, like, outside of the Web3 and crypto space completely. But the core idea is that you need to make sure it's atomic, so the delivery of an asset has to happen at the same time as the payment. So we did this with bonds and cash and using a TEE as a coordinator to make sure you keep this kind of invariant. So, settlement. Another thing that's quite common is having some kind of private business logic. This is, we call it, like, a do-it-yourself validium. So this is more towards, like, ZKsync-style constructions. Where basically you have some private state, and then you have some arbitrary business logic. So maybe you want to do insurance, or you have some specific set of conditions that have to be met, and you don't want to write this in a circuit.

15:12你只想寫普通的商業邏輯程式碼，然後用 zkVM 做出證明，在 L1 驗證，狀態仍保持私有。我們的概念驗證裡還有一個想法：使用者可以強制提款，所以營運者作惡時，你永遠有路回到 L1。這些就是我們做過的一些概念驗證例子。它們示範怎麼解這些使用情境。有興趣一定要上官網看完整寫作、程式碼與規格。再講一點你們可以怎麼用。我想回到一開始提的那張地圖。對我們來說地圖是很強的工具，它像回饋迴路，因為我們從機構使用情境出發，那些是真實需求。You just want to write normal business logic code, and then you use sort of a zkVM here to create a proof that then gets verified on L1 while still keeping state private. And in our POC, we also had this idea where users can force withdrawal, so if the operator goes rogue, you always have a way to go back to the L1. So those are, like, some examples of some POCs that we have done. This sort of shows how to solve some of these use cases. And if you're interested, definitely check out our website where you can read a write-up with full details, also with the code and the specification. A little bit about how you can sort of use this. So I want to go back to the map I mentioned in the very beginning. The map for us is a very powerful tool, and it acts as a kind of feedback loop, because we start off with institutional use cases, so these are real requirements.

16:00常常是好幾家機構都講過的，然後我們匿名化放進地圖。再從最急、比較有意思的去做概念驗證與規格。過程中也做更多研究，把地圖補完整，追到技術前沿，再寫出來。分享給生態系，讓生態系去建設、去找缺口。可能是協定開發者去想哪個新的 EIP 有用，怎麼用 MPC 解這個保管問題，或供應商看到這其實是大問題。這個回饋迴路的結果是：機構拿到更能用到以太坊生態能耐的設計，生態系也拿到實地真相，因為傳統上很多生態團隊很難接觸到機構、搞懂他們到底要什麼。Often that we've heard from several institutions, and then we're able to anonymize them and put them into the map. And then basically, of the most pressing ones or more interesting ones, we do POCs and specification work. And then as part of that, we also do more research to sort of fill up and make the map more complete, so sort of catching up to the state of the art and doing a write-up as well. And sharing that with the ecosystem so the ecosystem can sort of build and find the gaps that exist. So that can either be for protocol developers to understand what is sort of a new EIP that would be useful, what is, like, how can we use MPC for this custody problem, or maybe a vendor sees that actually this is a big problem and so on. And the result of this feedback loop is that institutions get better design that actually takes advantage of all of these affordances we have in the Ethereum ecosystem, and the ecosystem also gets ground truth, because traditionally it's quite difficult for a lot of these ecosystem teams to get access to institutions and understand what they actually need.

17:01規格與開源函式庫：RotoTree、SealRing

17:01我們另一件做很多的是規格。我會說加密貨幣那種 YOLO 階段已經過了，你不能隨便丟一個 DeFi 協定、隔天就被駭。這些是大型機構，他們已經有產品市場適配，有數十億美元想搬上鏈，他們要確定能跑而且安全。技術規格對這很有用。我覺得以太坊生態在基礎層協定上很會寫規格，應用層就沒那麼好。我們想把這塊再拉高一點，很嚴謹地講假設是什麼、威脅模型是什麼、實際安全保證是什麼，把這些保證講清楚。Another big thing that we work a lot on is specifications, and I would say that we're kind of past this YOLO phase of crypto, where you can just put out some DeFi protocol and it gets hacked the next day. You have these massive institutions, and they already have product-market fit. They have billions of dollars that they want to move on-chain, and they want to make sure it works and it's secure. So having technical specifications is very useful for this. I think the Ethereum ecosystem is very good at it when it comes to the base-layer protocol, but it's not as good when it comes to the more application layer. So we want to sort of try to elevate the space a little bit there, and being very rigorous about, like, what are sort of the assumptions, what are the threat models, what are the actual security guarantees, and being very sort of clear about those guarantees.

17:49這也是我們在推的，想把它做硬、當生態系有用的資源。另一件是這些積木與開源函式庫。做概念驗證時我們注意到有共同問題，於是抽出模組化函式庫，任何人都能用，不管你是跟機構合作，還是只是在以太坊上做隱私。這些是很單純、很小的原語函式庫，寬鬆授權。做硬，但也很精簡，所以也能用在 zkVM 情境。幾週前釋出的一個例子是 RotoTree，一種 Merkle tree 構造，用 Rust 寫，對上 TypeScript 基線，快了約 450 倍。So that's something we're pushing out as well, and sort of trying to harden it and act as a useful resource for the ecosystem. Another thing is kind of these building blocks and open-source libraries. So as we do these POCs, we notice that there are, like, common problems, and based on that, we sort of extract these modular libraries that can be used by anyone, whether you're working with institutions or just working on some kind of privacy thing on top of Ethereum. And these are very simple, small primitive libraries with permissive licensing. And sort of hardened, but also, like, very bare-bones, so you can use them in a zkVM context as well. One example that we released a few weeks ago is RotoTree, which is kind of a Merkle tree construction, and it's written in Rust, and we were able to sort of compare to the TypeScript baseline and make it, like, 450 times faster.

18:40當然 Rust 對 TypeScript 不是蘋果對蘋果。但對這種很常見、系統一放大就會碰到的操作，仍有用。另一個最近釋出的函式庫是 SealRing，讓加密票據這種常見原語更模組、也更穩。因為你常常想用它，也許想換曲線，這樣比較好換。還有幾樣會出來，全部寬鬆授權，你愛怎麼用就怎麼用。我講了很多概念驗證，顯然概念驗證到不了生產系統。整條流程還有很多要處理，錢包、營運怎麼做、復原。Obviously, comparing Rust to TypeScript, it's not apples to apples. But it's still, like, a useful thing for a very common operation, especially as you scale these systems up. Another library we recently released is SealRing, which is a way to make sort of these encrypted notes, which is a common primitive, more modular and also more robust. Because oftentimes you want to use it, and maybe you want to change the curve you're using or whatnot, and this makes it easier to do so. And we have a few more things coming out, and it's all under permissive licensing, so you can use it for whatever you want. So I mentioned a lot about, like, POCs and so on, and one thing is obviously a POC doesn't take you all the way to a production system. There's, like, a lot of other things you have to take care of when it comes to the whole flow, when it comes to wallets or how you do operations, recovery.

19:31怎麼跟其餘業務互動等等。那比較不在開源這一側，比較是我們跟機構的私下合作。但這點也要講。我們怎麼想自己的角色：一邊是有商業問題、已有需求的機構。我們試著把那些需求翻譯、正規化，帶進以太坊生態。以太坊生態提供協定、研究、工具與產品，我們試著記錄下來，讓機構知道怎麼用，當我前面說的回饋迴路。顯然做這件事的行動者很多，但因為我們既能做技術執行，也能跟機構談，可以在兩個世界之間翻譯，尤其傳統上他們不互相講話，語言也不一樣。How you interact with the rest of the business and so on. That's less on the open-source side and more something that we do in private engagements with institutions. But it's important to point out as well. One way we think about sort of our role is that you have these institutions with business problems and sort of existing demand. And we try to sort of translate and take those requirements and normalize them, bring them into the Ethereum ecosystem. And the Ethereum ecosystem provides all of these protocols and research and tools and products and so on, and we try to document them and show institutions how they can use them and act as this feedback loop that I mentioned before. And obviously we're just one of many actors doing this, but because we are able to both focus on the sort of technical execution side, but also talking to the institutions, we can help translate between these two worlds, especially because traditionally speaking, they don't speak to each other and they don't really speak the same language as well.

20:29務實又講原則：今天蓋的會變成往後預設

20:29所以有很多翻譯工作，要把商業需求或法律限制對到技術需求與技術能力。我們怎麼看自己：務實，也講原則。我們認為機構反正會蓋這些系統。未來幾十年，很多金融與其他機構會上鏈，有沒有我們都會發生。今天蓋出來的東西，會變成往後幾十年的預設，我們寧可參與，而不是假裝沒看到。我覺得在以太坊裡在意這些保證的人，應該幫忙設計，讓採用發生。我們要對限制務實，但對能提供的保證很講原則，在規格裡把取捨與實際性質講嚴謹、講誠實。So there's, like, a lot of translation work in terms of, like, business requirements or legal constraints that has to be mapped to technical requirements and technical capabilities. The way we think about ourselves is, like, being pragmatic and principled. So we think that institutions will build these systems anyway. A lot of financial and other institutions are moving on-chain over the next few decades, and it will happen with or without us. And basically, what gets built today will set the defaults for decades to come, and we would rather be part of that as opposed to ignoring it. And I think those of us in Ethereum who care about these guarantees should help design them and sort of get this adoption. We want to be pragmatic about the constraints, but also be very principled about the guarantees that we can provide, and being rigorous and honest about sort of the trade-offs in terms of specifications and what properties they actually have.

21:22幾個行動呼籲。如果你是機構，一定可以看我們的地圖，也可以來找我們談，看能不能幫上忙。如果你是建設者或供應商，一定要讀我們的概念驗證、函式庫與寫作。隱私地圖裡也許也有你的位置。這工具滿有用，因為很多這些使用者真的會去看。有興趣的話，這是曝光的好方法。如果你比較是 cypherpunk、偏個人這一側，一定要讀我們的規格與威脅模型，挑戰我們的假設與安全問題，幫我們保持誠實。我講完了，剛剛分享的全部公開、開源：寫作、規格、程式碼，全部都有。Some calls to action. If you're an institution, definitely. You can check out our map, and maybe you can also come talk to us, and we can see if we can help you out somehow. If you're a builder or vendor, definitely read our POCs and check out our libraries and write-ups. Maybe there's also room for you in the privacy map. It's quite a useful tool because a lot of these users actually look there. So if that's something you're interested in, that's a good way to get exposure. And if you're more on the cypherpunk sort of individual side, definitely read our specifications and threat models, and challenge sort of assumptions and security problems we have, and help keep us honest. That's it for me, and everything I just shared is public, open source: write-up, specification, code, everything.

22:07謝謝。有問題嗎？謝謝 Oskar 的分享。Thank you. Any questions? Thank you, Oskar, for the sharing.