Fluidkey：每次換個收款地址，花錢時還能保密？
Privacy on Chain: What Stealth Addresses Solve, and What's Still Ahead
- Antonio Seveso Fluidkey
影片
影片與逐字稿來源：ETHTaipei
場次摘要
Fluidkey 的 Antonio Seveso 介紹隱身地址：收款人公布一組可供推導的資訊，付款人每次產生不同地址，使外部觀察者較難把多筆收款連到同一人。Fluidkey 已將這個流程接上 ENS，但金鑰輪替、多簽與支出時的隱私仍待解決。他提出 keystore 作為改進方向，尚非已全面部署的功能。
值得記下的 5 件事
- 隱身地址讓外部觀察者難以判斷兩個收款地址是否屬於同一個人；它定義隱私結果，不限定單一實作。
- 隱身地址把 viewing 與 spending 金鑰分開，前者用來推導與索引地址，後者控制資金。
- Fluidkey 經由 ENS 每次回傳新收款地址，付款人可自行付款，不必等待收款人上線。
- keystore 構想讓多個地址參照共用權限登記，再用 ZK 隱藏地址間的關聯；這部分仍屬待實作方向。
- 支出隱私目前可用 Privacy Pools 或 Railgun，但手動操作慢、成本高，也難替一般使用者自動化。
逐字稿
開場：付款不該把淨值攤在鏈上
謝謝大家來。我調一下這個。好。今天想聚焦我認為鏈上隱私目前的樣貌，尤其是隱身地址。我覺得未來幾年，多數協議錢包都會整合這項技術。不必只信我講。這場會用我的經驗、以及我在市場上看到的，把這件事證給你們看。我不想講得太技術。內容會兩邊都有。Thank you, thank you, everyone. Thanks for coming. Let me adjust this. Okay. So, my talk of today would like to focus on what I think is the current aspect of privacy on-chain, especially around stealth addresses. Stealth addresses are the technology that I think most of the protocol wallets will integrate in the coming years. And you don't have to trust me on this. This talk will be exactly proving you this through my experience and what I see with the market out there. I didn't want to make it too technical. The talk will be a mix of both.
也會帶你們看我從哪裡來、我們現在在哪、以及我認為這項技術接下來會往哪走。背景：我是 Fluidkey 的共同創辦人兼 CTO。Fluidkey 是自我保管錢包，讓任何人投資、並接到傳統銀行軌道做國際支付，資產全程放在鏈上。我把這段定義念出來，不是為了介紹 Fluidkey 是什麼，而是要強調一件事：在我們做什麼的描述裡，我從來沒提過隱私，也沒提過隱身地址。即使 Fluidkey 百分之百由隱身地址驅動。這是什麼意思？And especially will be a path to show you where also I was coming from, where we are now, and where I see the space is going in this specific technology. So, my background: I'm CTO of Fluidkey, which I co-founded, and Fluidkey is a self-custodial wallet that lets anyone invest and connect with traditional banking rails for international payments while holding all their assets on-chain. Now, I read you this definition not because I wanted to tell you exactly what Fluidkey is, but just to stress one thing. I have never mentioned the word privacy and the word stealth addresses in what we do. Even though Fluidkey is entirely 100% powered by stealth addresses, what does it mean?
每次付款，錢都進一個新地址。別人付錢給你時，不知道你有多少、過去做過什麼、資產在哪、總額多少、投資了什麼。這很重要，原因是：區塊鏈應該改善使用體驗，不是倒退。你跟一般人聊，他們通常用卡付款，幾秒結算，付款很快完成，登入 App 看到全部餘額。最重要、圈內常當理所當然的是：他們付款時不會把淨值曝光。你到外面遇到不是區塊鏈圈的人，跟他說區塊鏈很棒，可是你一付款，別人就能看到你全部有什麼。Every time you do a payment, that payment goes to a new address. So when people pay you, they don't know how much you have, what you did in the past, where your assets are, what's the total, what did you invest, and so on. And this is important for this reason. The reason is that blockchain needs to be an improvement in user experience, not a regression. If you speak with a person, what they usually do, they pay by card, and the payment settles in seconds. They complete payments very fast. They log in in an app and see the full balance. But most important, and it's something given for granted in the space, they pay without exposing their net worth. Now, if you go outside, you meet a person that's not in the blockchain space, and you explain them that blockchain is great, but as soon as you make a payment, someone is able to see all you have.
對圈外人這幾乎是免談，因為我去銀行付款，沒有人會因此看到我帳戶有多少。這是很大的差異，應該被當成重要的一環來處理。首先，隱身地址是概念，不是食譜。什麼意思？概念定義結果，不規定單一實作。實作有很多種。我們會看最常見的、未來的，以及我們從哪裡來。隱身地址的意思是：給兩筆交易、兩個地址，外部觀察者不能說這兩個地址屬於同一個人。This is like a no-go for someone that is not in the space, because it's something that, you know, I go with my bank, and no one sees how much I have in the bank when I do a payment. And this is a big difference, and this should be addressed as, like, an important part. First of all, stealth addresses are a concept, not a recipe. What do we mean by that? The concept defines the outcome. It doesn't prescribe one implementation. So there are many implementations. We will see through what is the most common one, what is the future one, and where we come from, okay? So a stealth address means that, given two transactions and two addresses, an external observer cannot say that the two addresses are owned by the same user.
隱身地址是概念，不是單一食譜
左邊是今天常見的傳統做法：一個地址、多筆交易，全部連在一起。右邊才是隱身地址。兩個分開的地址、兩筆進來的交易。只看鏈上，這兩個地址連不起來。可能是兩個人，也可能是同一個人。先把這點講清楚。隱身地址是概念，這對後面很重要。我用披薩來比喻。我來自義大利。一個概念允許很多有效食譜。披薩是概念，食譜是不同做法。So on the left, this is the traditional thing that today happens. One address, multiple transactions, everything linked. On the right, this is what a stealth address is. Okay, so you have two separate addresses, two incoming transactions. Both addresses cannot be linked together just by looking at them on-chain. They can be two different people, as they can be the same person. Now, just to understand this. Stealth address is a concept that's important for the rest of the talk. I'll make a parallel to explain that, okay? I come from Italy, and the parallel we'll make with a pizza, okay? So, a concept that allows many valid recipes. So pizza is a concept; recipes are the different ways of doing that, okay?
這是概念，裡面有不同食譜。你可以做拿坡里、羅馬，上面加不同配料，也可以做深盤。這些都是披薩，做法不同。概念也帶來邊界。邊界是必須守住的東西，否則概念本身就破了。披薩加鳳梨就破了概念。不行。隱私是隱身地址的概念邊界，這不能談。使用體驗則是我想給的產品邊界。So this is the concept, and then we have different recipes inside. You can make a Neapolitan, you can make a Roman, and you can even add different toppings on top. You can make deep dish. All of these are pizza. They are made differently. A concept brings also boundaries. Boundaries means things that must be respected, that otherwise break the concept itself. Pineapple on pizza breaks the concept. Okay, so it doesn't work. Okay. Now, privacy is the concept boundary in stealth addresses. Okay, so that's not negotiable. UX is the product boundary that I want to give.
這是什麼意思。隱身地址我要有很好的使用體驗：若我要付錢給你，不必先打電話，只要知道你的使用者名稱。你也不必在線。對方完全離線我也能付，之後再告訴他，因為傳統金融就是這樣，使用體驗必須守住。付款的人，當然也不能因此花掉收款人的錢。意思是：我不能自己產一個帶私鑰的地址，再把私鑰寄過去，或說錢付給那裡。那行不通，那會是很容易的漏洞。來看怎麼把隱身地址組起來。Let me explain you what it means. It means that with stealth addresses, I want to have a great UX, meaning that if I want to pay you, I don't need to call you before, just knowing your username. That's it. You don't need to be online, okay? I can do the payment even with the other person completely offline and tell him later, because this is how traditional finance works, and UX must be respected. Okay, and the sender, so I do the payment. Of course, I cannot then spend the money of the user. So what does it mean? I cannot generate an address with a private key and then send the private key, or I pay you there. That doesn't work. That would be an easy hack for that. Okay, so. Let's see how we can get to a setup of stealth addresses.
前兩個例子很直觀，不是我們平常在做的，但這套你一定熟。第一種：我是收款人。每次要收款，就產一把新私鑰。一把私鑰就是一個新地址。每次收款都進新地址，概念大致符合，每筆交易都進新地址。問題是使用體驗對不上，而且我得管理這些私鑰。再進一步，有人發明了助記詞。我們都用過裡面有助記詞的錢包。助記詞是一串 12 個字。The first two examples are two obvious examples, and this is not what we normally do. But I'm sure you're familiar with this setup. So the first one, I am the receiver. Every time I want to receive a payment, I generate a new private key. A private key is a new address. If every time they pay me on a new address, oh, the concept kind of matches. Every transaction goes to a new address. The problem is that it doesn't match the user experience. And also, it has a problem: I have to manage all these private keys. One step more, they invented seed phrases. We all had wallets with seed phrases inside. The seed phrase is a list of 12 words, there.
電話簿、檢視金鑰與花費金鑰
我剛剛講到後面去了。好，裡面是 12 個字，從那串可以產出從外面看起來連不起來的地址，除非你自己控制它們、在它們之間轉錢等等。體驗比較好，因為只需一把助記詞，但還是不行。使用體驗仍不夠，因為我每次都要把新地址寄給要付錢的人。這行不通。現在才進到隱身地址目前的狀態。這張投影片會說明目前的配置怎麼運作。What I did, I went behind. Okay, it's a list of 12 words inside, that from that you can generate addresses that, looked from outside, they cannot be linked to each other, unless, you know, you control them, you move money between them, and so on and so forth. This is a better experience because I have only one seed phrase, but still. There is no UX, because I always have to send a new address to who pays me. This doesn't work. So now we start getting to what is the current state of stealth addresses. And in this slide, I'm going to show you how the current setup of stealth addresses works. So...
有一個付款人。他想付錢給我。第一件事是去公開名冊、電話簿查。這是舊式電話簿的例子，每個人上面有名字與電話。現在會是名字，加上所謂的 viewing 與 spending keys，兩把金鑰。對我來說是兩個地址。一個叫 viewing，請記住這個詞。另一個叫 spending，也請記住。這些是公開的，誰都看得到。打開簿子，讀我的名字，找到那些。這本簿子代表什麼？代表我這個把We have a sender. The sender wants to send me a payment. The first thing it does is look on a public listing, a phone book, okay? It's an example of a phone book, the old-style phone book where everyone had a name and a phone number on it. Okay, now it will be the name and what's called viewing and spending keys, so two keys. Two addresses for me, okay? One is called viewing, and keep this term in mind. The other one is called spending, and keep also this term in mind. But that's public, so no one can—everyone can see them, okay? So, open the book, read my name, find that. What does this book mean? It means that I, as a person that wrote my...
公開資訊寫進這本簿子的人，可以有無限多個信箱收付款。信箱就是地址。我可以有無限多個地址讓付款送進去。為什麼好？因為無限，沒人猜得到哪個是我的、哪個不是。付款人看著電話簿上的資訊，再從這些信箱裡隨機挑一個。他知道我的信箱有無限個，隨機挑一個。這個隨機挑出的，會放進一則 announcement，一張票。information, public information, on this book, I can have an infinite amount of mailboxes where to send a payment. A mailbox is an address. I can have an infinite amount of addresses where that payment can be sent. Why this is great? Because if it's infinite, no one can guess which is mine and which is not. But the sender, looking at this information in the phone book, plus basically picks one of these mailboxes randomly. Okay, so he knows which are my mailboxes, an infinite number of mailboxes, and he picks one randomly. This randomly picked is put inside an announcement. A ticket. Okay?
這則 announcement，連同其他人用隱身地址送出的 announcement，會發佈到區塊鏈上。當然是加密的。另一邊是收款人。收款人跟其他收款人一樣，收到所有這些票，憑這套密碼學能分辨哪張是自己的、哪張不是。收款人一旦解出這則 announcement、知道自己收到付款，就能看到錢被送到哪一個特定信箱。否則他得把所有信箱都解一遍，數學上不可能，至少在收款人有生之年做不到。This announcement, along with the other announcements sent by other people using stealth addresses, are published on the blockchain. Of course, they are encrypted. Okay? On the other side, there is the receiver. The receiver, like any other receiver, receives all these tickets and is able to understand which is theirs and which is not, thanks to how cryptography works in this sense. So the receiver, once he understands, oh, I got a payment, decrypting this announcement is able to see where the payment was sent in one specific mailbox. Otherwise, he would have to decrypt all the mailboxes, and it would be mathematically impossible, at least not in the lifetime of the receiver.
註冊一次 meta-address，之後都能收款
再用他的 spending 私鑰打開信箱、把錢拿出來。概念就是這樣。講完概念，看引擎蓋下的技術流程：收款人註冊所謂的 meta-address。spending 公鑰、viewing 公鑰。為什麼要兩把？因為 viewing 公鑰用來產生地址，spending 用來控制地址。這為什麼重要？如果我想請人幫我索引這些地址，或請人審計、記帳，我可以分享 viewing key。And using his spending private key, he is able to open the mailbox and get the money. This is basically the concept. So I told you; now more into the technical flow under the hood: the receiver registers what they call a meta-address. Spending public key, viewing public key. Why two? Because the viewing public key is used to generate the address, and the spending is used to control the address. Why this is important? Because if I want someone to index these addresses for me, or if I want someone to audit or, like, you know, do, like, accounting for me, I can share the viewing key.
他能看到我所有地址，但不能花錢。所以兩把地址要分開。我可以每年輪替 viewing，產一把新的 viewing key，更新電話簿，但底層 spending key 維持同一把。付款人推導出稍早看到的那個地址，送出 announcement。這整段在鏈上完成，是鏈上 event。收款人用 viewing key 偵測到付款，再用 spending key 取得控制權。點就這樣連起來。這套配置還多三個好處。首先，公開金鑰、也就是 spending 與 viewing 公鑰，你發佈一次，就能一直收款。He's able to see all my addresses, but he's not able to spend money. This is why it's important to keep the two addresses separated. I can rotate the viewing every year, generate a new viewing key, and update the phone book. But I keep the same spending key under the hood. So the sender derives the address we saw before. The sender sends the announcement. This is done entirely on-chain. It's an event on-chain. The receiver detects the payment with the viewing key and takes control of that payment with the spending key. This is how dots are connected. And this setup gives three kind of more benefits. First of all, you publish once your public key, the spending and the viewing public key, and you receive forever.
兩個人付錢給我、剛好付到我同一個地址的機率，比你我在整個宇宙隨機各挑一個原子、卻挑到同一個還低。只是讓你感覺數字與數學幫了多少忙。零互動。付款人自己就能做，不必我在線。付款流也無法連結，錢每次都進新地址。可是收款人現在有問題。我們解了付款端的使用體驗。例如 Fluidkey 接到公開的 ENS，每次回傳新地址。付款人只要有相容 ENS 的錢包，今天任何錢包都是，就能用。The chance that two people paying me pay on the same address of me is less than the chance that me and you, picking two random atoms in the whole universe, pick the same atom. Okay? Just to give you the idea how the number and the math helps in this way. There's zero interaction. The sender can do that by himself. Doesn't need me to be online. And there is an unlinkable payment flow. So money goes every time to a new address. The receiver, though, now has a problem. So we solved the user experience on the sender. For example, we in Fluidkey, we connect to a publicly available ENS that every time returns a new address. So the sender just needs to have an ENS-compatible wallet, that's any wallet as of today, and it works.
收款人呢？因為錢進了很多不同地址，有時有人跟我說：「我可以把錢都轉到一個地址。」不行。那會把全部連起來。鏈上什麼都看得到，錢若都匯進同一個地址，問題沒解，因為你把地址都連上了。地址在區塊鏈上無限又免費，去用它們。正確做法是錢留在鏈上，若我想轉出其中 3.5 ETH，再把地址組合起來。這有點像 UTXO 問題。But now the receiver, why? Because the receiver has received money in a lot of different addresses, and sometimes they tell me, "Oh, I can do this. I move all my money into one address." No, no. This links everything. On-chain, everything is visible, so if all the money then goes to one address, well, you have not solved the problem because you link all the addresses. Addresses are infinite and are free on the blockchain. Use them. So the right solution, okay, is having the money on-chain, and if I want to send 3.5 ETH out of those, combine the addresses. It's kind of a UTXO problem.
付款時盡量少連地址，可批次成一筆
最終付款時，把要連起來的地址降到最少。這仍不是完美隱私，後面會看未來怎麼改善。但絕對比現狀好。這個例子裡，0.8 加 2.8，我連起來的兩個地址，合計 3.6。會剩一點粉塵留在其中一個地址，其餘拿去付我想付的那筆，因為你收款，遲早是為了把錢付出去。分開的地址要怎麼一起動？我們在很多地址收到錢。若要付給別人，我不想送一堆小交易，湊到我要付的金額。Link the least amount of them for the final payment. It's still not the perfect privacy. We will see how we can improve in the future. But that's definitely better than the status quo, okay? So what does it mean in this case? That the sum of 0.8 plus 2.8, the two addresses I connected, gives me 3.6. So I have a little bit of dust that will stay in one of these addresses, and the rest is going to the new payment that I want to do, because if I receive money, it's because sooner or later I want those to pay out. Now, how can separate addresses act together? We said we receive money in a lot of these addresses. Now, if I want to pay someone else, I don't want to send them a lot of small transactions until I reach the amount of money I want to send them.
我想送一筆交易。對方要收的是 3.5 ETH，不是 2.8 加 0.7 再自己算。自動化有兩條路。第一是用 EIP-7702，讓 EOA 當智能帳戶。第二條路：地址、也就是信箱，我們產生的地址不是直接的 owner。這個地址是某個智能帳戶的控制器。我稱之為智能隱身地址。它仍是由一對一 EOA 控制的地址，而控制它的那個 EOA 是隱身地址。沒變。第二套彈性更大，後面會說明為什麼。I want to send one transaction. The other user wants to receive 3.5 ETH, not 2.8 plus 0.7 and needs to do the math. So there are two ways to automate that. First of all, using EIP-7702, so using the EOAs as smart accounts. The other way is the address, the mailbox, okay? The address we generate is not the direct owner. The address is the controller of a smart account. So basically, it's what I call a smart stealth address, okay? So again, it's an address that is controlled by a one-out-of-one EOA, and that EOA controlling the address is a stealth address. Nothing changed. The second setup gives more flexibility, and we will see why in the future.
這些配置本質是帳戶抽象。多個 EOA 轉錢的交易，可以批次成一筆送出。對付款人是好的使用體驗：一次操作處理全部的錢。錢可以在有 gas 贊助的情況下，用一筆批次交易送出。這是另一個大優點。多個隱身地址可以一起批次。但還剩兩個問題，未來要解的就在這裡。第一個是金鑰輪替與多簽。即使這些地址不是智能帳戶，產生出來的地址裡，控制它們的金鑰是寫死的。But the idea is that these setups are account abstraction. So all these transactions, multiple EOAs moving money, can be batched into one transaction and be sent. And this is a good user experience for the payer that has to do one single operation for all of the money. And the money can go in one batch transaction with gas sponsorship. That's another big advantage. And multiple stealth addresses can be batched together. But there are still two problems left, and this is where the future comes. The first problem is the key rotation and multisig. So, we said that all these addresses are generated, even if they are not smart accounts, there is a hard-coded key controlling them.
對不在區塊鏈圈的人來說，去銀行說「我想加另一個人一起操作這個帳戶」，或「我想輪替金鑰、改憑證」，很正常。你打客服，做完識別，他們就改憑證。若金鑰寫死在所有這些地址裡，就麻煩了。第二個問題是地址可追蹤。你們大概已經想到：你付錢給我，我再付給別人，你這個付過錢的人，即使只佔我後來付出的一小部分，仍能追我拿那些錢做什麼。另一邊，若我收到薪水，假設薪水是幾千美元。It's normal for a person that's not in the blockchain space to go to the bank account and say, "Oh, I want to add another person able to operate with me in this bank account," or, "I want, you know, or I want to rotate the key, change the credential to operate through it." Okay, you call the call center and, through, like, an identification, they change the credential. Now, if the key is hard-coded in all of these addresses, that's a problem. The second problem is address traceability. You probably already figured it out yourself: if you pay me and I pay someone else, you, who paid me, even for only a small portion of the money you sent me, are still able to track what I do with that money. On the other side, if I receive my salary, okay, let's say I get, like, a few thousand dollars as a salary.
金鑰輪替與支出追蹤，keystore 是候選解法
我去酒吧買咖啡。我不想從整筆薪水裡付 1 美元、2 美元、3 美元。否則對方能看到我賺多少，或至少看到我手上有一大塊錢。這就是可追蹤性，也跟 Vitalik 稍早講 Privacy Pools 時有關。我們有解法，兩個問題都可以靠一個新東西來控制隱身地址。先從金鑰輪替開始，兩個裡面比較容易懂，提案解法也比較好懂。這是目前最好的候選之一。到目前為止講的，都已經做得到，都已經上線。And I go to pay the coffee at the bar. I don't want to pay one dollar, two dollars, three dollars out of my full salary. Otherwise, the person is able to see how much I'm making, or at least see, like, a large chunk of money that I have. And this is the other one, the traceability, that's kind of also related to what Vitalik spoke about before when he was mentioning the privacy pools, for example. We have a solution, and both can be addressed with a new thing that we should add to control stealth addresses. Let's start from the key rotation problem, because out of the two, it's the simplest to understand, and also the simplest to understand the proposed solution. That's one of the best candidates that we have as of now. So, until what I said now, it's everything possible. It's everything live.
這就是 Fluidkey 的做法；其他協議也這樣，例如 Umbra Cash。從現在起，是我們仍有的問題，以及這個領域打算怎麼解。已有一個帳戶。這個帳戶已經在不同地址收到不同交易，就是稍早講的。現在使用者說：「我想要新配置。」我想要新的 owner 金鑰。我想變成多簽。很正常。這會很亂，因為每個地址的配置都要改。你可以說 gas 很多，但技術上做得到，技術上沒有擋住你的東西。It's how Fluidkey works, by the way; it's how other protocols work, like Umbra Cash, and so on and so forth. From now on, this is the problem we still have and how the space is aiming to solve them. We have an existing account. The existing account has already received different transactions on different addresses. That's how we said before. But now the user says, "Hey, I want a new configuration." I want a new owner key. I want to transform into multi-sig. Normal. This is going to be a mess, because each of these addresses needs to be updated in its configuration. And you can say, "Yeah, it's a lot of gas, but technically you can do it." There's nothing that blocks you technically.
但理論是一回事，實務是另一回事。實務上還會發生：有人把地址印在發票上，發票兩個月後才付款。發票上的地址也許沒人記得；或對方要付給你，你產了地址，他一個月、兩個月後才付。你把一切輪替、改了配置，舊金鑰、舊配置的那個新地址又冒出錢來。這是問題。還有：我在以太坊付給你這個地址，以後在另一條鏈付給同一個地址，而那條鏈上的同一個地址沒輪替過，因為從沒被用過，智能帳戶仍是原始配置。But remember that theoretical is one thing, practical is another thing, because in practice also this happens: there are people that share the address on an invoice, and the invoice gets paid two months after. And the invoice contains an address that maybe no one remembers, or maybe the recipient needs to pay you, you generate the address, and then he pays you after a month or two. And then you rotate everything, you change the configuration, and the new address with the old key, with the old configuration, pops up with money on it. This is a problem. Or other problems are like, oh, I pay you on this address on Ethereum, then in the future I pay on the same address on another chain, and the same address on the other chain was not rotated because it was never used, so still has the original configuration of the smart account.
一團亂。解法概念很單純，叫做 keystore。其實是 Vitalik 大約三年前提出的。最後我會留 QR code，我做了一頁文件與相關檔案。這些地址裡面，不再放控制它們的配置。全部指向一份登記。一份智能合約，我們說在那份合約的第 10 號位置，寫著誰是 owner。我們有 keystore。這就是 keystore。這就是登記。A mess. So the solution is a very simple concept, okay? It's called a keystore. Actually, it was proposed by Vitalik, I think, three years ago. And at the end, I will leave you a QR code. I created a page with some documentation and files around that. Addresses. So all these addresses around, they don't have inside the configuration controlling them. All of them point to a registry. Okay, so one smart contract, and we say that at position 10 of that smart contract, it's written who is the owner. Okay, so. We have a keystore. This is the keystore. This is the registry.
Keystore 一次改配置，尚未部署的地址也跟著改
你看，登記裡有很多配置。每個槽位是不同配置。Mario 一份、Fede 一份、Jen 一份、Mo 一份，以此類推。keystore 本身，這是技術部分，會把這些配置雜湊到一個 root hash。這基本上被當成證明：雜湊底下的內容就是它該是的那樣。這叫 keystore root configuration。我們大概會在主網上有一份合約，放所有配置。我在位置 10 有一個 1-of-2 的 Safe，也有一個 1-of-3 的 Safe。You see, in the registry we have a lot of configurations. Each slot is a different configuration. One configuration for Mario, for Fede, for Jen, for Mo, and so on and so forth. The keystore then itself, this is the technical part, hashes all this configuration up to a root hash. Okay, this is basically seen as a proof that the content of the hash under it is what it is meant to be. This is called the keystore root configuration. So we have one contract on mainnet, probably, that has all the configuration. Okay, so. I have a one-out-of-two Safe in position 10. I have a one-out-of-three Safe.
位置 12 有一個 1-of-1，以此類推。另一邊，Mario 的地址裡面不會寫「這把特定金鑰控制這個地址」。它們說：要看金鑰，去它們引用的集中儲存看。當然，若用普通引用，就不再是隱身地址，因為地址裡寫了誰是控制器，你可以把這些地址蒐集起來。但用 ZK，可以讓這層連結在鏈上完全藏在雜湊後面。於是所有地址都指向由某個位置控制的 keystore，但明文看不出來。I have a one-out-of-one in position 12, and so on and so forth. Now, on the other side, the addresses of Mario don't contain inside that this specific key is controlling this address. They say, to see the key, go and look on the centralized store they reference. Of course, if they reference with a normal reference, there are no more stealth addresses, because in the addresses it's written who is the controller, and you can collect all these addresses. But with ZK, you can make this connection completely hidden on-chain through a hash. So in this way, you have all the addresses pointing to a keystore controlled by one position, but in a way that is not plainly visible.
這有點像 ZK 的黑魔法。也不是黑魔法。想深挖可以自己看。好處是：我一更新 Mario 的配置，所有這些配置立刻自動更新，因為不必進每個地址去改。地址引用的是 keystore。引用的意思是：下一筆交易時，它們會看到新配置。還有另一個好處。這對尚未部署的地址也有效，因為只要這些地址繼續引用 keystore 裡同一個槽位、同一個位置，控制地址的配置就會被更新。Okay, this is kind of the black magic of ZK. It's not black magic, okay? If you want to deep dive, you can do it on that. So the advantage is that the moment I update Mario's configuration, automatically, instantly, all of this configuration gets updated because they don't need to go into each address to update it. The address references the keystore. The reference means that at the next transaction, they will see the new configuration. But this is another advantage. This works also for the addresses not yet deployed because all these addresses keep, as long as they keep referencing the same slot in the keystore, the position, the configuration, who controls the address is updated.
當然還要證明什麼？接著才是要做的交易。我們要做一筆交易。交易裡怎麼做？這些地址裡都有錢，我們需要證明這筆交易。這些地址裡面通常不會。你建立智能帳戶時，通常會說「這個智能帳戶由這個地址控制」，把地址寫進去。有了 keystore，變成：「這個智能帳戶由這組 stealth account init bytes 控制。」32 bytes。就這樣。那個配置雜湊，是 keystore 位置（例如 Mario 的位置 12）與共享秘密之間的雜湊。What do we have to prove, of course? Then comes the transaction to do. We have to do a transaction. What do we do in this transaction? We have all these addresses with money in it, and we need to prove the transaction. So. Each of these addresses inside doesn't. Usually, when you create a smart account, you say, “Oh, this smart account is controlled by this address,” and you put the address. With the keystore, it works: “Oh, this smart account is controlled by this stealth account init bytes,” okay? 32 bytes. Simple as that. That configuration hash is a hash that's the hash between the keystore position, position 12 of Mario, for example, and the shared secret.
ZK 要證三件事；支出追蹤還要 Privacy Pools
共享秘密就是稍早電話簿那裡看到的同一份隨機秘密。概念沒變。我們產生一個秘密，必須用 announcement 告訴收款人。流程一樣，沒變。只是我把共享秘密跟位置一起用，定義隨機性，每次產新地址。現在要做交易時，ZK 證明需要證三件事。收款人是該配置的 owner，所以能用私鑰做出有效簽名。The shared secret is the same randomness secret we saw before when we were looking at the phone book. So the concept doesn't change. We generate a secret that I have to communicate with the announcement to the receiver. It's the same flow, it doesn't change. It's just that I use the shared secret together with the position to define a randomness to create every time a new address. And now the ZK proof needs to prove three things when we want to do the transaction. That the receiver is the owner of the configuration, so has access to a private key and can make a valid signature.
地址連到正確的隱藏位置，以及秘密加位置雜湊到那個秘密位置。這三件事放進 ZK 證明，就得到能證明交易的電路。若你偏技術，最後我也會留連結。我們 2024 年在 ETHDam 做過概念驗證，GitHub 上有開源 repo，想看電路怎麼寫可以去看。Vitalik 稍早說他們在做 EIP-8288，我們當時電路寫的，大概不會是未來實作，因為他們想讓系統裡的 ZK 驗證更有效率。That the address is connected to the right hidden location, and that the secret plus the position hashes to the secret location. Now, if these three things are put in a ZK proof, you get a circuit that can prove transaction. If you are technical, I will also leave a link at the end. We did a PoC over that at ETHDam in 2024, and it's an open-source repo on GitHub, so if you want to look at how this circuit was written. As Vitalik said before, with the EIP-8288 they're working on, for example, what we wrote in that circuit is not exactly what would be probably the future implementation, because they are trying to make ZK verification more efficient in the system.
這些東西還沒出來，就是因為鏈上要用哪種最有效率的方式，仍有很多辯論。結束前還有第二條線：花費。即使有了 keystore，這些地址仍可追蹤。我們解了金鑰輪替，沒解的是：你付錢給我之後，仍能看到錢去哪，或我為了下一筆付款連上另一個地址時，你能看到我有多少。那需要另一套配置，相關技術其實已經不少。假設你用隱身地址，在三個不同地址收到這三筆交易。This is why these things are not out yet, because there's still a lot of debate around which is the most efficient way to put them on chain. Before finishing, also the second link is the spend, because even with a keystore, now we still have all these addresses traceable. We have changed, we have solved the problem of key rotation, not the fact that if you pay me. Then you can see where my money goes, or how much I have if I connect another address for the future payment, and so on and so forth. For that, we need a different setup, and there's already, like, a good amount of technology around that. So let's say you have received all these three transactions in three different addresses on stealth addresses.
目前最好的解法是走 Privacy Pools 或 Railgun。它們真的是 ZK 原生，內部有電路與 ZK 技術，很貴，就像 Vitalik 稍早說的，但它們存在。目前限制是：手動、慢、非常慢、很耗時，對一般使用者不容易自動化。技術上今天就做得到。沒人做，因為要搬 12 美元，花費可能超過 12 美元，還要花很多時間。想法是這樣：左邊隱身地址上有錢。The best solution we have now is going through. Privacy Pools or Railgun, okay. They really are ZK-native, so internally they have circuits and ZK technology, very expensive, like Vitalik was saying before, but they exist. But they have a limitation at the moment. They are manual. They are slow. They are very slow. They are time-consuming. They cannot be automated super easily for the end user. So technically, you can do already this today. No one does, because to move, like, $12, it's going to take you more than $12 probably that you are going to spend and a lot of time. But the idea is this one: you have money on the left in stealth addresses.
用 keystore 自動走 Privacy Pools，切斷連結
把它們放到右邊、換成不同金額、仍由你控制的另一些隱身地址。從外面連不起輸入與輸出。你不知道輸出是別人在用資金池把錢轉出，還是你在清理、把總額拆開。我們需要自動化，現在有了 keystore 就能做。流程完全一樣：隱身地址走進 Privacy Pools，出來是全新的隱身地址。但我們的地址由 keystore 控制，兩個地址是否屬於 keystore 裡同一個位置，可以用 ZK 證明。And you put them on the right in different amounts on another stealth addresses you control. From outside, you cannot connect the input and the output. You don't know if the output is someone else using the pool, moving out money, or you using, cleaning or, like, dividing the total amount. But we need automation, and now we can do that with the keystore. So the flow is exactly the same, okay? The flow is we have stealth addresses, go through Privacy Pools, and we get to fresh stealth addresses. But since our addresses are controlled by a keystore, and the fact that two addresses are owned by the same position in the keystore can be proven through a ZK proof.
我們可以自動化：錢可以憑 ZK 證明從一個地址走到另一個，確保資金池是在同一個 owner 的地址之間移動，不是把錢送給別人，而觸發自動化的人不必是資金的 owner。對最終使用者就能自動化。使用者收到錢，錢立刻被移到他控制的一個或多個地址，連 App 都不必打開，而且全程自我保管。你可以拿來拆大額付款、回收錢包裡剩下的粉塵、打斷多個錢包之間的可連結性。We can automate saying that money can go from one address to the other through a ZK proof, making sure that the pool is moving money from the same owner addresses, so not sending money to someone else, without who triggers the automation being the owner of the money. So that could be automated for the end user. So the user ends up receiving money and instantly having money moved to one or more addresses he controls without even him opening the app and always keeping everything self-custodial. And this, you know, you can use that for split large payments, recycle the dust left in a wallet, break linkability among multiple wallets.
還缺什麼？我認為好的原語，我們剛講過，基礎設施要接到好的原語，也就是 Vitalik 在講的那些，我不再深挖；以及標準化的 keystore。這塊我們大概走得比較前面，但這一切也取決於 ZK 的信心與成本往前走。驅動它的標準，我列在那裡。下一張就是稍早答應的 QR code。你可以看到，隱身地址與智能帳戶相關的都是綠的，已經定案。還沒綠的，是 ZK 與 keystore 附近的東西。What is still missing? Well, I think that good primitives, we just said, the infra is connected to good primitives, what we just said that Vitalik was speaking about, so I don't deep dive that more, and a standardized keystore. This is something where probably we are more advanced into, but also all of this depends on an advancement on confidence and cost around ZK. The standards driving it, I will just list there. Next slide will be the QR code I was promising you before. As you can see, like, for what concerns stealth addresses and smart accounts, all are green. They're final. What is not green yet is something around ZK and the keystore.
現在多數工作就在那裡。謝謝。不確定還有沒有時間提問，我會待在附近。也留了聯絡方式，email 與 Signal。謝謝大家來。謝謝 Antonio。我們還有幾分鐘。對，還有幾分鐘可以問。有人嗎？抱歉。好，謝謝。可以回到披薩那張嗎？披薩，好。披薩。再往回一點。對，快一點。抱歉，動畫很多。是莫札瑞拉，還有很多四種起司披薩。再說一次，抱歉。This is where most of the work is done now. So. Thank you. I'm not sure if we have time for questions, but I will be here around. I left also my contacts, both my email and my Signal. And yeah, thanks for coming. Thank you, Antonio. I think we do have a few minutes. Yeah, we do have a few minutes for the questions. So, anyone? I think... sorry. Okay, thank you. Could you go back to the slide for pizza? For pizza, okay. For pizza. So, go back a little bit. Yeah, faster. Sorry, yeah, it was a lot of animation. It was mozzarella cheese and the many, many four-kind-of-cheese pizza. Now say it again, sorry.
問答：披薩、Safe 智能帳戶與尚未部署的合約
對，我們都愛吃披薩，尤其很多起司的。抱歉，還很後面。我快轉。你是在問他喜歡哪種起司嗎？好，謝謝。對，繼續。好，可以了。我想……Fluidkey 是瑞士公司。對，但我們在 Lugano 一帶，瑞士南部，我住在 Como 湖一帶，義大利，所以我是義大利人。很高興認識你。我想跟你說抱歉。因為在台灣，我們喜歡夏威夷披薩，鳳梨加火腿。我知道、我知道。Jennifer 也在團隊裡，她常拿這件事跟我開玩笑。所以我才放進投影片。Yeah, we all like to eat pizza, especially with many cheese. And sorry, it's pretty behind. Let me fast-forward. Are you asking what kind of cheese he likes? Okay, thank you. Yeah, go, go. Okay, perfect. Yeah, I think, I think, you... I think Fluidkey is a Swiss company. Yes, but we are in the Lugano area, so south of Switzerland, and I live in the Lake Como area, so Italy, so I'm Italian. Nice to meet you, yeah. I want to say sorry to you. Because here in Taiwan, we enjoy pizza with pineapple and ham. I know, I know, I know, I know, I know. Jennifer here, that's part of the team. She always jokes with me about that. That's why I put it in the slide.
我想說我很喜歡你的演講。把這些資料協議講得很清楚。非常感謝。謝謝。我們也會把珍珠奶茶放披薩上。珍珠奶茶，好。那邊還有一個問題。好，來個真正的問題。披薩？不，不是披薩。原本的隱身地址，想法是你直接送到 EOA，然後我自己推導金鑰去花。你是說有了可升級 keystore 之後，我是把它送到智能合約嗎？還是送到……因為原本隱身地址很漂亮的一點，是它混進一般網路流量，你只是在轉錢。And I want to tell you that I very like your speech. Your speech is very clear about the data protocols. Thank you so much. Appreciate it. Thank you so much. We also put boba tea on the pizza. Boba tea, okay. We have one question from there. Yeah, let's have a real question. Pizza? No, no, not pizza. So, with the original stealth addresses, the idea was that you would just send it to an EOA, and then I could derive my own key to spend it. Are you saying with the upgradeable keystore that I'm sending it to— a smart contract? Or am I sending it, like... Because one of the beautiful things of the original stealth addresses was, like, it just mixes with the normal network traffic, that you're just sending money.
有了可升級 keystore，我是送到合約嗎？送到哪？你還是送到另一個隱身地址，但那個隱身地址是智能帳戶，一個 Safe 智能帳戶，外面幾百萬個 Safe 智能帳戶之一，而且是尚未部署的智能帳戶。你預先計算地址。預先計算，例如 Fluidkey 就是這樣做，否則 gas 會不可能。然後送 announcement。你身為收款人拿到 announcement，說「錢進了這個地址」。再部署智能帳戶，你就有了。超厲害。謝謝。對。所以你仍像普通 ETH 轉帳那樣送，只是推導的不是隱身地址，而是已部署程式碼。對。這整段可以靠 ENS 的 CCIP 鏈下 resolver 自動化，Fluidkey 就是這樣做。But with the upgradeable keystore, am I sending it to a contract? Where am I sending it? You are sending to another stealth address always, but that stealth address is a smart account, a Safe smart account, one of the millions of smart accounts of Safe out there, and it's a not-yet-deployed smart account. You pre-compute the address. Pre-compute—that's, like, for example, how Fluidkey works. Otherwise the gas would be impossible. And then send the announcement. So you, as the receiver, get the announcement, say, "Oh, I got money to this address." Let me deploy the smart account, and then you have that. And then— Super dope. Thank you. Yeah, yeah. So you're still sending just like a normal ETH transfer, but instead of deriving the stealth address, I'm deriving the deployed code. Exactly. And this can be all automated through an ENS CCIP off-chain resolver, like Fluidkey does.
對了，我們會開源。我們跟 ENS 有一個專案，未來幾個月會開源。這也是為了讓錢包能整合，因為我認為未來錢包會這樣用。太厲害了。謝謝。謝謝。時間到了。謝謝 Antonio。謝謝。By the way, we are open sourcing that. We have a project with ENS; it will be open sourced in the next coming months, around that. And this is also, like, to make sure that even wallets can integrate that, because I think this is how wallets are going to use them in the future. Incredible. Thank you. Thank you. All right, that's all the time we have. Thank you, Antonio. Thank you.
