imToken Labs：跨鏈先給錢，怎麼防假成交？
Assets First, Proofs Later: Building Verifiable Cross-Chain Intents with OIF
- Alfred Lu imToken Labs
影片
影片與逐字稿來源：ETHTaipei
場次摘要
imToken Labs 的 Alfred Lu 以跨鏈換幣為例，說明意圖式交易如何由 solver 先在目標鏈墊付資產，再憑履約證明到原鏈領款。他提醒，跨鏈訊息能證明某段訊息確實傳來，卻不保證它來自正確合約、對應真實付款，或不會因鏈重組而失效。這些條件都必須由應用另外驗證。
值得記下的 5 件事
- 意圖式跨鏈由 solver 先在輸出鏈交付使用者要的資產，使用者不必先橋接再兌換，但 solver 先承擔墊款風險。
- OIF 把 input settler、output settler 與 oracle 拆開，元件可選不同安全模型，改一個元件不必重寫其他元件。
- OIF 降低整合成本，但不會增加流動性或利潤，庫存、路由、定價與再平衡仍由 solver 負責。
- 跨鏈訊息簽名有效仍不足以保護資金，必須核對 payload 是否來自指定鏈上的真正 output settler。
- 輸出鏈重組可能讓已交付資產消失，應用需設挑戰視窗，或等輸出鏈最終確定後才簽署證明。
逐字稿
開場：跨鏈時真正過去的是證明
大家好，我是 Alfred，在 imToken Labs 當區塊鏈開發者，今天要講 Open Intents Framework。這是 imToken Labs 最近在貢獻的東西，OIF 是一個很大的框架。先謝謝隊友：Changwu、Jiahui、Cyan、Alex CT、Aurora。我們想分享在測試產品裡實作 OIF 的經驗，先用一個問題開場。Hello everyone, I'm Alfred, and I am a blockchain developer at imToken Labs, and today I will give a talk about Open Intents Framework. And this is what imToken Labs is contributing to recently, and OIF is a huge framework. So I want to shout out to my teammates, shout out to Changwu, Jiahui, Cyan, Alex CT, and Aurora. And we want to share our experience with you when we implement the OIF in our testing product, and I want to use a question to start today's talk.
你把資產跨鏈時，真正過去的是什麼？多數人會說是資產。但在意圖式橋裡，這不一定百分之百成立，因為真正過去的是一筆主張：你要證明另一條鏈上已經發生某件事。所以也可以把這筆主張叫做證明或 attestation。另一個問題是：如果我們傳的是證明而不是資產，怎麼讓這則訊息安全到可以信？這就是後面會講的主張問題。When you move assets across chains, what actually crosses? And most of you may answer the asset, but in the intent-based bridge, it may not be 100% true because what actually crosses is a claim, and claim means you want to prove something has already happened on another chain. So we can call the claim a proof or attestation too. So another question is how to make the message safe to trust if we want to transfer the proofs instead of the asset. And this is a claim issue we will mention after.
整場用這個例子。很簡單。使用者想把 Tron 上的 1,000 USDT 轉過去，在 HyperEVM 拿到 900 USDC。傳統橋要先橋再換，交易兩步，也就有兩件可能出錯。但在 OIF 裡，你可以讓 solver 用自己的流動性，直接在 HyperEVM 交出 900 USDC。從使用者看，旅程已經圓滿結束。從 solver 看，他在 HyperEVM 先墊了錢，因為使用者的資產還沒動。And here is the example for the whole talk. It is a simple example. A user wants to transfer 1,000 USDT on Tron and wants to get 900 USDC on HyperEVM. When you are using the traditional bridge, you need to bridge first and swap. There are two steps to the transaction. It means there are two things that can go wrong. But in the OIF, you can directly let the solver deliver 900 USDC on HyperEVM from its own liquidity, and from the user's view, your journey has a happy end. But from the view of the solver, he is out of pocket on HyperEVM because none of the user's assets have moved.
資產還鎖在 Tron。solver 已經承擔風險，必須有東西讓這筆風險能收尾。這就是我說的主張問題。這張是快速名詞對照。如果你看的是錢、看的是現金流：輸入鏈 Tron 是使用者資金被鎖住的地方，他們要的是 HyperEVM 上的資產，那是輸出鏈。從現金流看，Tron 是來源鏈，HyperEVM 是目的鏈。It's still locked on Tron. So the solver has taken on risk and something has to make that risk resolvable. So this is what I mentioned of the claim issue. And this is a quick slide of intro. We want to define the naming convention. If you focus on the money, you focus on the cash flow, you can see the input chain, Tron, is where the user's funds are locked, and what they want is to get the asset on HyperEVM; it is the output chain. So from the view of the cash flow, you can see Tron is the source chain and HyperEVM is the destination chain.
輸入鏈與輸出鏈，不要再說來源目的
但如果你是 solver 或 oracle，證明系統或 attestation 是從 HyperEVM 走向 Tron，因為你要證明使用者的意圖已在目的鏈成交。證明從 HyperEVM 出發，那是 solver 證明自己已經成交的地方，然後 solver 再到 Tron 領回使用者鎖住的資金。所以證明流是從 HyperEVM 到 Tron。於是 Tron 可以是來源鏈也可以是目的鏈，HyperEVM 也可以兩邊都是。所以我們避開這套講法。But when you are a solver or oracle, you can see the proof system or attestation is going from HyperEVM to Tron because you want to prove the user's intent is filled on the destination chain. So you can see the proof starts from HyperEVM; it is where the solver proves it has filled, and then the solver claims the user's locked fund on Tron. So the proof system, the proof flow, is going through from HyperEVM to Tron. So you can see that Tron can be the source chain and destination chain. And HyperEVM can be source chain and destination chain too. So let's avoid it.
我們只說輸入鏈、輸出鏈。輸入鏈是端到端 OIF 流程的起點：使用者在 Tron 呼叫 open 跟 quote，他們要的是 HyperEVM 上的資產，所以 HyperEVM 是輸出鏈。介紹完，接下來三章：機制、誰受益、真正會把 OIF 系統搞壞的是什麼。OIF 架構上，Open Intents Framework 給三件事：分層、標準化、模組化。協定裡看得到幾層。第一層是訂單流發源。We just say input chain and output chain. The input chain means the end-to-end OIF workflow starts from users calling the open and quote on Tron, and what they want to do is get the asset on HyperEVM. So HyperEVM is the output chain. And after the intro, I will introduce three chapters: the mechanism, who benefits, and what actually breaks your OIF system. For the OIF architecture, the Open Intents Framework gives three parts: layered, standardized, and modular. You can see some layers in the OIF protocol. The first one is order flow origination.
意思是你要給開源使用者介面或鏈抽象錢包，讓使用者進得多鏈生態。意圖表達則是你要決定鎖定機制。例如可以選 ERC-7683，或 The Compact，也就是 resource lock，把使用者資產鎖在輸入鏈。訂單流拍賣是你可以決定先到先贏，或其他拍賣機制，讓 solver 選優先順序。意圖履約則是你要自己實作 solver。It means you need to give the open-source user interface or chain abstraction wallet for the user to let them join the multi-chain ecosystem, and the intent expression means you need to decide the lock mechanism. For example, you can choose ERC-7683 or The Compact, also known as the resource lock, to lock users' assets on the input chain. And order flow auction means you can decide the first come, first serve or other auction mechanism for your solver to choose the auction priority, and intent fulfillment means you need to implement your own solver.
OIF 鼓勵大家實作開源 solver。跨鏈驗證就是主張問題。這是你要證明輸出鏈上某件事已經完成，solver 才能領回使用者資金。再來是再平衡：solver 在輸出鏈直接把使用者要的東西交出去，卻在輸入鏈領回款項，中間會碰到流動性問題，你得處理，並且標準化。And OIF encourages people to implement the open-source solver. But yeah, and cross-chain validation is the claim issue. So this is the proof you need to prove something has been completed on the output chain. So this is how solver claims back the user's funds. And rebalancing: there may be some liquidity problem you may meet because the solver directly gives the users what they want on the output chain, but they claim back the payment on the input chain, so you need to solve the liquidity problem and standardize.
OIF 的標準與三件模組：輸入、oracle、輸出
OIF 文件裡給了一些標準。我很快回顧他們提到的 ERC。第一個是 7785：可以用 ENS 取代 GitHub 上的 JSON 檔來當鏈識別碼。以前我們要用一個檔案記鏈識別碼，管理依賴 GitHub。這個 ERC 可以用 ENS 取代。7930 跟 7828 統一多鏈地址格式，地址裡能帶更多資訊，尤其是多鏈地址，也可以用標準裡的 checksum。OIF gives some standards in their documentation. I will quickly recap the ERC they mentioned. The first one is 7785. It means you can use ENS to replace the JSON file on GitHub for chain identifier. So in the past, we need to use a file to record the chain identifier, so the management depends on GitHub. But in this ERC, you can use ENS to replace it. And 7930 and 7828 unifies the multi-chain address format, so you can get more information, especially multi-chain addresses, in these addresses, and you can use the checksum in the standard.
7811 讓 dApp 一次 RPC 就能發現使用者的多鏈資產，它只是定義一呼叫。7786 則給多種跨鏈訊息協定一個介面，產品可以用這套標準接很多跨鏈訊息協定。模組化才是最重要的一塊。OIF 把橋平常綁在一起做的三件事拆開。整段流程裡，開源 solver 跟這三個元件互動。第一個是 input settler，在輸入鏈上的合約，使用者呼叫 open 表達意圖，把資金鎖進 input settler 合約。And 7811 means it lets the dApp discover the multi-chain assets of a user with one RPC call. So it just defines an RPC call. And 7786 means it provides an interface for multiple cross-chain message protocols, so you can use this standard for your product to integrate many cross-chain message protocols. And the modular part is the most important part. OIF splits three jobs that bridges normally do together. In the whole workflow, the open-source solver interacts with these three components. The first one is input settler. It is a contract on the input chain, and users call open to express intent and lock their funds on the input settler contract.
證明從輸出鏈過來之後，input settler 才能把輸入放給 solver。Oracle 是一項服務，在 OIF 協定裡還有 adapter 合約。Oracle 把主張從輸出鏈帶到輸入鏈並驗證。output settler 也是合約：它從 solver 收資金，在輸出鏈把使用者要的東西交出去，再記錄成交已發生。這就是 OIF 總覽。元件很多：input settler 合約、output settler 合約、solver 服務。Hyperlane Oracle 則是 oracle 這塊。And after the proof comes from the output chain, the input settler could release the input to the solver. And Oracle is a service, and, yeah, with the adapter contract in the OIF protocol. Oracle carries and verifies the claim from the output chain to the input chain, and output settler is also a contract. It gets the funds from the solver and gives what user wants on the output chain, then records that the fill happened. So this is the overview of OIF. You can see there are so many components here: input settler contract, output settler contract, solver service. And Hyperlane Oracle is the oracle part.
拆開有用，是因為它們可以選不同安全模型、不同實作、由不同人來做。改其中一個，不必重寫其他，也不會牽連其他，這就是模組化。接著把 OIF 流程走細。第一步：鎖定輸入。使用者，也就是 OIF 協定裡的 sender，從 solver 拿到報價，再在 input settler 合約呼叫 open。So why splitting them matters is because they can choose different security models and different implementations and be built by different people. So when you change one of them, you don't need to rewrite the others. You will not affect others, and this is modular, too. And let's go through the OIF workflow in detail. The step one is locking the input. The user, aka the sender in the OIF protocol, gets quotes from the solver and calls the open function on the input settler contract.
Solver 先墊資產，再靠證明領回
如果你在實作 input settler 合約，要選託管機制。例如 escrow 或 resource lock，這會影響意圖怎麼表達。也要選安全模型：怎麼授權、input settler 合約要用什麼到期機制。下一步是 OIF 流程裡最簡單的一步：solver 直接在輸出鏈成交使用者意圖。這一步走完，使用者旅程結束。可以看到好的使用體驗。So if you are implementing the input settler contract, you need to choose the custody mechanism. For example, you can choose escrow or resource lock, and it affects your intent expression. And you also need to choose the security model. How to authorize and what expiry mechanism you want to use in the input settler contract. And next, the simplest step in the OIF workflow: the solver directly fills the user's intent on the output chain. So in this step, the user's journey is over. We can see the good user experience.
這就是我們在賣的東西。成交之後可以看到：使用者開心了，但 solver 在輸出鏈花掉流動性，所以還要解這個問題。第三步：solver 想把輸出鏈花掉的領回來，就要提交證明。這裡他們要證明已在輸出鏈履約使用者意圖，所以要跟 Hyperlane Oracle 互動。我們拿 Hyperlane Oracle 當例子，因為也可以選其他跨鏈訊息協定，例如 Wormhole、Polymer、Across。This is what we're selling. And after the fill, you can see. User is happy, but the solver spends their liquidity on the output chain, so we need to solve this problem. So, step three: the solver wants to claim back what they spent on the output chain, so they need to submit the proof. Firstly, here, they want to prove they have fulfilled the user's intent on the output chain, so they need to interact with the Hyperlane Oracle. Here, we take Hyperlane Oracle as an example here because we can choose other cross-chain messaging protocols like Wormhole, Polymer, Across, for example.
所以 Hyperlane Oracle 只是例子。solver 在 Hyperlane Oracle 的 adapter 合約呼叫 submit proof，然後 Hyperlane Oracle 把證明從輸出鏈送到輸入鏈。最後 solver 可以在輸入鏈證明已經履約，領回使用者鎖住的資金。誰受益？從錢包看，產品可以不再走路由導向，因為以前使用者要自己選路由、決定跨鏈 gas 付款，還要先橋資產再換。So Hyperlane Oracle is just an example. So you can see the solver calls submit proof on the Hyperlane Oracle adapter contract. Then the Hyperlane Oracle sends the proof from the output chain to the input chain. And in the end, the solver could prove they have fulfilled the user's intent on the input chain and claim back the user's locked funds. So, who benefits? From the view of wallet, it lets the product stop being route-based, because in the past, the user needed to choose the routes and decide the inter-chain gas payment, and the user asks for bridge asset, then swap.
但在意圖式橋、尤其是 OIF，他們只要表達想花什麼、想收到什麼、在什麼時間之前，路由交給 solver 選。從錢包看，使用體驗很好，這也是我們加入意圖式 DeFi 生態的一次新嘗試。從 solver 看，OIF 的好處不是更多利潤、也不是更多流動性，因為它不是營利模型。它只是傳輸層跟意圖模型，不是利潤模型。But in the intent-based bridge, especially the OIF, they just need to express what they want to spend, what they want to receive, and before what time, and just let the solver pick the route. So from the view of wallet, the user experience is very good, and this is a new try for us to join the intent-based DeFi ecosystem. And from the view of solver, the OIF benefit is not more profit and not more liquidity, because it is not a for-profit model. It's just a transport layer and intent-based model, not a profit model.
有效證明不夠，還要確認是對的 output settler
它只是降低整合成本。一次整合可以吃很多訂單來源，也可以重用自己的報價、模擬、風險、結算。但庫存、路由、定價、再平衡還是要自己控。我們不敢承諾太多，因為還有問題要面對：OIF 不會多給你流動性，也不會多給你利潤。oracle：OIF 把 oracle 做成協定裡的一個槽位。oracle 只是傳輸層，對跨鏈訊息協定來說，這是加入意圖生態的新機會。So it just lowers integration cost. So you can use one integration for many sources of orders, and you can reuse your own quoting, simulation, risk, and settlement. But you need to keep control of inventory, routing, pricing, and rebalancing. So we don't promise too much because there are still something you need to face, some problems you need to face, because the OIF doesn't give you more liquidity and doesn't give you more profit. And oracle: OIF makes the oracle a slot in the OIF protocol. The oracle is just a transport layer, so it is a new opportunity for the cross-chain messenger protocol to join the intent-based ecosystem.
Oracle 不是 solver 的競爭對手。他們不搶同一批目標使用者。這是跨鏈訊息協定加入跨鏈 DeFi 生態的新獲利方式。真正會壞掉的是什麼？這章想跟各位分享，因為我們在測試產品實作 OIF 時碰到過。實作進產品時，可能碰到安全問題、費用問題，元件也可能停機。Oracle is not a competitor of solver. They don't compete for the same target user. It's a new profit way for the cross-chain messenger protocol to join the cross-chain DeFi ecosystem. And what actually breaks? This is a chapter we want to share with you because when we implement the OIF in our testing product, we met some problems and yeah. So what actually breaks your OIF system? When you want to implement OIF in your product, you may meet the security issue, fee issue, and your component may be shut down.
所以要處理。第一個是安全。oracle 對所有人來說都是傳輸層，它是公開的，任何人都能在上面提交證明。這裡的 Hyperlane Oracle 是合約、adapter 合約，所以公開。來看攻擊例子。如果我是攻擊者，我可以在輸出鏈部署自己的合約。我可以在輸出鏈部署自己的 Hyperlane Oracle 或其他 adapter 合約，然後送一則訊息：42 號訂單成交了，但沒付錢。Hyperlane oracle 的驗證者可以簽名，再由 oracle adapter 檢查。So we need to solve it. And the first issue is security issue. Because the oracle is a transport layer for everyone. It is public, so anyone can submit proof on the oracle. Hyperlane Oracle here is a contract, adapter contract, so it is public. So we can see an attack example. If I'm an attacker, I can deploy my own contract on the output chain. So I can deploy my Hyperlane Oracle or other adapter contract on the output chain, and then I send a message: order number 42 was filled but paid nothing. So the Hyperlane oracle validator can sign it, and then it is checked by the oracle adapter.
再把證明從輸出鏈送到輸入鏈。如果你沒核對 payload 是誰送的，就可以領走 solver 的利潤，或領走使用者鎖住的資金。攻擊例子裡沒有東西是假的。跨鏈訊息協定只回答「這則訊息是不是真的」，沒有人問「是不是真正的 output settler 說的」。所以實作 oracle 或 input settler 時，要問的是：這個 payload 是不是那條鏈上那個 output settler 來的，而不是只問：有沒有 P 的 attestation。And send the proof from the output chain to the input chain. So you can claim the solver's profit, or you can claim the user's locked fund, if you don't check the payload with the person who sent it. Because in the attack example, nothing here was fake. The cross-chain message protocol just answers, is this message real, but nobody asked, did a real output settler say it or not. So when you implement the oracle or when you implement the input settler, you need to make sure it has asked, is this payload from that output settler on that chain, instead of just asking, is there an attestation for P.
跨鏈 gas、重組，誰先付錢誰承擔
P 的 attestation，因為簽名跟跨鏈訊息常常都是對的。再來是費用問題。到底誰付錢？看 solver：solver 在輸出鏈把使用者要的東西交出去，再在輸入鏈領回使用者資金。從 oracle 看，他們在輸出鏈向 solver 收費，再在輸入鏈呼叫函式。所以當 solver 或 oracle 時，可能碰到跨鏈 gas 付款問題。到底誰付錢？Attestation for P, because the signature and the cross-chain message is always right. And next, the fee issues. So who actually pays? You can see when we take a look on solver, the solver gives the user what they want on the output chain. And claims back the user's fund on the input chain, and from the view of the oracle, they charge the solver on the output chain and call the function on the input chain. So you may meet the interchain gas payment issue when you are solver or oracle. So who actually pays?
如果你是使用者，OIF 裡的客戶在另一條鏈不需要 gas。這是對的，因為你不必考慮輸出鏈 gas 費。你只要考慮想要什麼、願意付什麼、solver 的報價行不行。使用者不必在輸出鏈付 gas。但如果你是 solver 或 oracle，就要把跨鏈 gas 付款，也就是 IGP，顧好。IGP 要對得上你的經濟模型，因為你付錢跟領錢在不同鏈，可能碰到報價、收款、備資、追回這些分開的問題。If you are user, the customer in OIF doesn't need gas on the other chain. It's true because you don't need to consider the output-chain gas fee. You just need to consider what you want, what you want to pay, and the quote of solver is okay or not. So. The user doesn't need to pay on the output chain for the gas. But if you are a solver or oracle, you need to make sure the interchain gas payment, aka IGP. You need to make sure the IGP is good for your economic model, because you pay and claim in different chains, so. You may meet the separate problems like quoting, collecting, funding, and recovery.
費用問題不會把證明弄壞。如果你沒把跨鏈 gas 付款想細，它只會弄壞你的經濟。下一個問題是重組。用四步講。第一步，solver 在 HyperEVM 付 900 USDC，使用者在輸出鏈拿到要的東西。接著 oracle 簽署者看到事件、證明、簽名，把證明從輸出鏈送到輸入鏈。然後 Tron 作為輸入鏈，把使用者鎖住的 1,000 USDT 放給 solver。So the fee issue is not a proof-breaking issue. It just breaks your economics if you don't consider in detail for your interchain gas payment. And next issue is. Reorg issue. So we can just go through the four steps to introduce this issue. The step one is the solver pays 900 USDC on HyperEVM, so the user can get what they want on the output chain, and then the oracle signer sees the event, proves it, and signs it, and transfers the proof from the output chain to the input chain. Then Tron, Tron is the input chain, releases 1,000 USDT, which is locked by the user, to the solver.
每項檢查都過了。最後一步，HyperEVM 重組，那個區塊沒了。結果 solver 手上有 1,000 USDT。使用者在 Tron 失去 1,000 USDT，而 900 USDC 其實從來沒發生。這是 solver 的信任問題：如果你是 solver 提供者，錢沒虧，但輸掉使用者對你的信任。在乎這件事，就要實作樂觀結算的挑戰視窗。如果你能設計或選擇 oracle，就要確保它在輸出鏈最終確定之後才簽證明。So every check passed, and in the final step, HyperEVM reorgs; the block is gone. So you can see in the end, the solver has 1,000 USDT. User loses their 1,000 USDT on Tron, and 900 USDC never happened. So this is a trust issue of the solver, because if you are a solver provider, you don't lose your money, but you lose your trust of the user. So if you care about this, you need to make sure you implement the challenge window of optimistic settlement. And if you can design the oracle or choose the oracle, you need to make sure it signs the proof after the output chain's finality.
元件壞掉時，誰付錢、誰承擔
這張表告訴你：有些元件壞掉時，誰付錢、誰承擔。第一列是 solver 始終沒成交。使用者把資金鎖在輸入鏈，期待 solver 在輸出鏈交出要的東西。solver 始終沒成交，使用者什麼都沒拿到，但訂單截止後可以退款。第二列是成交發生在到期之後。使用者還是什麼都沒拿到，但可以退款。從 solver 看，他想成交賺錢，卻可能發現成交被 revert。And this is a table for you to know if there are some components break down, and who pays and bears. The first row is solver never fills. You can see the user locks their fund on the input chain and expects the solver give what they want on the output chain. But if the solver never fills, the user got nothing, but it can get a refund after the order deadline. And the second row is fill arrives after expiry. The user still got nothing, but can get a refund. And from the view of the solver, it wants to fill to make a profit, but it may find the fill reverts.
鏈上 revert 時，你虧的是 gas。第三列是成交了，但 attestation 始終沒到。使用者在輸出鏈拿到要的東西，錢付了；solver 想領回輸入鏈上鎖住的資產。但碰到 oracle relayer 停機或沒 gas，solver 的利潤就沒了。我們特別提沒 gas，因為營運 solver 時，要確保選的 oracle 正常運作。So when you make a revert on the blockchain, you lose your gas. And third row is filled, but attestation never arrives. So the user can get what they want on the output chain, it is paid, and the solver wants to claim back the user's locked asset on the input chain. But when you meet the problem that the oracle relayer is down or has no gas, the solver profit will lose. We mentioned has no gas. Because we meet the problem that if you are operating a solver, you need to make sure your chosen oracle is operating normally.
如果你選的是不太有名的 oracle relayer 或不太有名的鏈，官方 relayer 可能忘了幫 relayer EOA 補 gas，你的利潤就沒了。成本不會消失。跑 OIF 協定時，報價要顧好，因為報價就是你的利潤模型；營運上還要監看很多東西。報價、備資、轉送、重試都會找麻煩。要採用 OIF 時，開源 solver 會把利潤模型攤開，所以你可能不想開源。Because if you are choosing a not very famous oracle relayer or not very famous chain, the official relayer may forget to refill the relayer EOA, and your profit may be gone. So the costs do not go away. When you run the OIF protocol, you need to make sure you have a good quote, because the quote is your profit model, and the operations problem is you need to monitor lots of things. Because the quoting, funding, relaying, and retrying will bring trouble to you, and when you want to adopt the OIF, the open-source solver reveals the profit model, so you may not want to open-source it.
我的看法是，這個框架太大，不好被採用。想加入 OIF 生態，要確保每個元件你都能控，因為別的元件可能把你的服務弄壞。OIF 的流程是：使用者在輸入鏈 open，solver 先付錢，attestation 再傳回來。跟傳統橋不同，這是資產先走、證明後補。我想再講一次：OIF 不會讓跨鏈複雜度消失。一定有人要扛這些問題。謝謝。And in my opinion, the framework is too big to be adopted. So if you want to join the OIF ecosystem, you need to make sure you can control each component, because the other component may break down your service. And in OIF, the workflow is the user opens on input chain, the solver pays first, and attestation travels back. So different from the traditional bridge, this is assets first, proofs later, and I want to reiterate again, because the OIF doesn't make cross-chain complexity go away. Someone must bear the problems. Thanks for listening.
提問：選 oracle 看鏈覆蓋與能否自營 relayer
謝謝 Alfred。還有幾分鐘提問。有人要問嗎？這裡有一位。Alan？嘿，我很喜歡這場。我喜歡意圖。第一個問題是：實務上你覺得大家最常用哪一種 oracle，它特別在哪、為什麼會變成那樣？我們的實作選 Hyperlane，因為現有產品、也就是錢包，想支援很多鏈。我們做錢包，所以想支援 HyperEVM、Tron，還有各種鏈。Thank you, Alfred. So we have a few minutes for questions. Anyone has any questions? Oh, here's one. Alan? Hey, I really like this talk. I like intents. My first question is— In practice, what do you think will be the most common oracle people use, and, like, what's special about that oracle that would make it like that? In our implementation, we choose Hyperlane because we want to support lots of chains in our existing product, like wallet. We make wallet, so we want to support, like, HyperEVM, Tron, and blah blah blah chain.
所以選 oracle 模型、選 oracle 提供者時，我們要確定它能支援大多數鏈。如果有另一家 oracle 提供者，鏈支援完全一樣，你會看什麼來區分？如果另一個 oracle 支援的鏈跟 Hyperlane 完全一樣，你會看哪些條件來分辨？實務上，我們其實自己營運 oracle 的 relayer，不依賴官方 relayer。So when we choose the oracle model, when we choose the oracle provider, we want to make sure it can support most of chains. Yeah. What if there was, like, another oracle provider that had the exact same chain support? What would you want to look for between them? If there was another oracle that supported the exact same chains as Hyperlane, what types of things would you look for to distinguish between them? I want to... In the practical implementation, we actually, we implement our, we operate our own relayer of the oracle, so we don't depend, we don't rely on the official relayer.
所以選 oracle relayer 跟 oracle 模型時，我們要確定程式碼有審計，或功能夠我們要用。我們要確定 oracle 的程式碼實作夠好，因為 relayer 想自己跑，而不是靠官方 relayer。了解。那如果你是錢包、要給使用者跨鏈，怎麼決定要開哪些鏈？就算 oracle 支援，你也可能不想開，因為某些鏈之間橋接的風險跟其他不一樣，對吧？So when we want to choose the oracle relayer and oracle model, we want to make sure the codebase is audited, or the codebase has enough features for what we want. And so, I want to, I want to, we want to make sure the oracle has a good implementation of codebase, because we want to operate the relay by our own instead of relying on the official relayer. Yeah, I see. And then if you're a wallet and you're using this, like offering cross-chain for people, how do you decide which chains you want to offer? Because even if the oracle supports it, you might not want, like, the risk of bridging between certain chains is different than, like, others, right?
有些鏈本質上就比其他危險。你們怎麼想？從錢包產品看，我們要確保使用者的報價跟意圖能成交成功。我們靠手續費賺錢、向使用者收費，所以要自己建 solver 跟 oracle，讓整套利潤模型可控。對使用者，我們想支援更多鏈、更好的報價、更高的服務可用性。Like some chains are just inherently more dangerous than others. How do you think about that? From the user, from the wallet product, we want to make sure the user's quote and user's intent is executed successfully, and we want to make sure that, because we profit from the fee and charge users when we operate a wallet, we want to build our solver and oracle to make sure the whole profit model is under control. So, for the user, we want to support more chains and the great quotes and the high availability of service.
提問：一小時成交、一天退款，證明可以是多簽
對。我也很好奇你們怎麼想兌換的使用體驗。例子裡成交期限一小時，退款卻要一天。為什麼差這麼大？為什麼不能說期限一小時，沒成交就六十一分鐘退款？這些時間怎麼定？時間上我們要顧兩件事。為了利潤模型，要確保 solver 不會虧錢，因為這張表看得到：solver 已經成交使用者意圖，卻可能因為過了訂單期限或成交期限而拿不回錢。Yeah. Okay. I'm also curious on, like, how you think about the UX of the swappers because— I saw in your example you had, like, a deadline of one hour and then, like, a refund of one day. Why would there need to be such a big difference? Like, why can't I say the deadline is one hour and then if it doesn't fill, I can refund it in, like, 61 minutes or something? How do you think about those timings? For the time, we want to make sure two things because— For the profit model, we need to make sure the solver won't lose their money, because in this table you can see if the solver has filled the user's intent, it may not be repaid because it's after the order deadline or fill deadline.
所以時間怎麼定，取決於我們不想讓 solver 輸掉利潤。另一個考量是使用體驗。如果成交期限或訂單期限太長，使用者會覺得自己可能被騙。所以這裡的時間還在考慮。我只能給兩個理由：solver 利潤與可用性，以及使用體驗。好。So. The time decision depends on—we don't want our solvers to lose their profit. And another consideration is the user experience. So if the fill deadline or order deadline is too long, the user will consider that I may be cheated. So, it is still in consideration to decide the time here. Yeah. So I just can give you two reasons for the time decision. First one is the solver profit and solver availability, and the user experience. Okay.
還有時間嗎？我想問你們的證明實際長什麼樣子。提交給 oracle 的證明，是智能合約在驗證，還是鏈下做？證明具體是什麼？證明可以是樂觀視窗、ZK 證明、單簽或多簽，你可以選自己的證明系統。我們的實作選多簽，多簽在 Hyperlane oracle 驗證，它是 adapter 合約。Do I still have time? Okay, I'm wondering what your proofs actually look like. Like when you submit this proof to the oracle, is this something like from a smart contract doing a verification, or do you do stuff off-chain? Like, what is tangibly the proof? Okay. The proof can be the optimistic window, or ZK proof, or single signature, or multi-signature, so you can choose your own proof system. In our implementation, we choose the multi-signature here, and the multi-signature is verified in the Hyperlane oracle. It is an adapter contract.
所以 oracle 要確認意圖已在輸出鏈履約，oracle relayer 簽好多簽再送到輸入鏈。以後我們可能用更複雜的簽名或密碼學演算法，換更高的安全模型。好。謝謝。謝謝。謝謝 Alfred。再給他一次掌聲。So the oracle needs to make sure the intent has fulfilled on the output chain, and the oracle relayer signs the multi-signature and sends to the input chain. But in the future, we may use more complex signature or complex cryptography algorithms here for the higher security model. Yeah. Okay. Thank you. Thank you. Thank you, Alfred. Let's give him another round of applause.
