本篇是 Rollup Bridge 介绍系列的第六篇。
Orbiter Finance 和這系列介紹過的 Hop Protocol 很相似，兩者都透過 Rollup 本身和 L1 之間資訊傳遞的功能來達到跨 L2 轉帳的安全性：只要 Rollup 本身及其 L1<->L2 訊息傳遞的功能正常，就能確保使用者轉帳的安全性，而不需要去相信 validator（例如 Celer 的 PoS 鏈節點） 不會作惡。
而 Hop Protocol 和 Orbiter Finance 主要的差異在於，Hop 仰賴合約送出的訊息能夠正確的被 relay 到 L1 及目標 L2，Orbiter 則仰賴 L2 的交易能夠正確在 L1 被讀取。而他們的共同點則是有 challenge 機制：平常預期交易都是合法的，但當有人造假交易（Hop）或是拒絕完成交易（Orbiter）時，一定能夠拿出證據證明，並懲罰造假的人。
概念來源
Hop 和 Orbiter 的概念其實都來自於 Vitalik 在 ethresearch 的一篇文章，這篇文章介紹的是如何在只有 Rollup B 支援智能合約功能時能夠完成從 Rollup A轉帳到 Rollup B 的操作（但從 B 轉到 A 會比較麻煩）。大致上的運作方式是：使用者在 Rollup A 轉帳給流動性提供者（下文中均稱為 Maker），Maker 在 Rollup B 上轉帳給使用者。如果 Maker 裝死，則使用者可以在 Rollup B 上的合約申請 challenge，並提交自己在 Rollup A 轉帳給 Maker 的交易證明，證明自己在 Rollup A 的確有轉帳給 Maker。
註：這會需要 Rollup B 能夠讀取到 Rollup A 的區塊或交易紀錄 。
而 Orbiter 和當初概念不一樣的地方就在於當 Maker 裝死、使用者要 challenge 的時候，實際接受 challenge 並驗證交易的合約不是在 Rollup B 上，而是在 L1。因為要能在 Rollup B 上驗證交易，表示 Rollup B 一定要支援智能合約。但如果思考一下就會發現，如果 Rollup 的資訊都會寫到 L1，而 L1 又有支援智能合約的話，那就乾脆直接統一在 L1 驗證交易就好了！
所以 Orbiter 實際上不需要 Rollup 支援智能合約，這也讓 Orbiter 能夠支援比 Hop 還多的 Rollup（雖然現在大部分 Rollup 都支援智能合約）。
註：Hop 支援的 Rollup 都必須要能支援智能合約。
架構
如同上面講到的，Orbiter 在 Rollup 上不需要有合約，但在 L1 上它需要針對每個 Rollup 去寫相對應的 SPV 合約，SPV 合約的功能就是證明一筆交易存在在該 Rollup 的區塊或交易紀錄裡。
另外在 L1 上的合約還會包含 Maker Deposit 合約（MDC）及 Event Binding 合約（EBC）
- Maker Deposit 合約負責管理 Maker 的押金，如果使用者 challenge 成功，會從 Maker 的押金中補償給使用者。
- Event Binding 合約負責驗證使用者在 Rollup A 送出的交易（Source Tx），包含驗證交易格式是否正確，並且它會算出 Maker 在 Rollup B 「應該」要送出的交易（Target Tx）的格式內容。
註：會說「應該」是因為 Maker 有可能會裝死。如果今天 Maker 被 challenge 了，他就要提出證據證明他在 Rollup B 上真的有轉錢給使用者，而這筆轉錢給使用者的交易的交易內容就必須要和 EBC 算出的 Target Tx 的內容一樣。
底下是官方提供的流程圖，Source Network 是 Rollup A、Target Network 是 Rollup B，Chain X 則是 L1。圖中左邊虛線包起來的部分會是正常的交易流程：Maker 在 Rollup B 上如實轉錢給使用者，皆大歡喜；右邊虛線包起來的部分則是 challenge 的過程，步驟比較繁瑣。
流程
正常情況
- 使用者到 MDC 合約確認 Maker 資訊，包含押金數量、收取的手續費高低，及透過過往歷史看到的 Maker 的表現
- 使用者在 Rollup A 轉錢給 Maker（Source Tx）
- Maker 偵測到 Rollup A 有人成功轉錢給他
- Maker 把 Source Tx 餵進去 EBC 合約，算出 Target Tx 的內容，例如 Target Tx 轉給使用者的金額會是扣掉保留給自己的手續費的金額
不正常情況
接續自使用者在 Rollup A 轉錢給 Maker 之後，Maker 沒有在時限內在 Rollup B 轉錢給使用者
- 使用者首先先到 Rollup A 的 SPV 合約證明 Source Tx 的存在，這個 proof 會存在 SPV 合約的 storage，等待 MDC 合約來查詢（圖例中的步驟 ⓵）
- 使用者接著到 MDC 合約申請仲裁（圖例中的步驟 ⓶）
- MDC 合約收到仲裁申請後會去 SPV 合約拿 Source Tx 的 proof，並請 EBC 合約驗證 Source Tx 的有效性，都確認沒問題後就開始倒數，等 Maker 來回應（圖例中的步驟 ⓷ 和 ⓸）
- 如果 Maker 過了一段時間都沒有來回應，則使用者可以觸發 MDC 合約作出仲裁，在 L1 上完成 Target Tx，從 Maker 的押金轉給使用者，其中會包含補償金（圖例中的步驟 ⓹、⓺ 和 ⓻）
手續費
Maker 在存押金到 MDC 合約時，要指定他會收取的手續費比例（之後可以再來更改），所以 Target Tx 轉的金額會以 MDC 合約裡紀錄的手續費為準，例如假設 Maker 手續費指定為 1%，使用者在 Rollup A 送 1 Ether 到 Maker 地址，則 Maker 應該要在 Rollup B 送 0.99 Ether 給使用者。
如果被 challenge，Maker 要提供 Target Tx 到 Rollup B 的 SPV 合約。如果 Maker 轉錯轉成 0.98 Ether，則 Maker 要自己認賠，因為 EBC 合約算出來 Target Tx 裡轉的金額就一定要是 0.99 Ether。
Maker 押金
為了避免出現多個使用者同時轉錢給 Maker，導致 Maker 因為其押金小於總共收到的金額所以選擇裝死的情況，Orbiter 有針對不同 Rollup 訂出不同押金規則：
1. 針對支援合約功能的 Rollup，我們可以把一個 Rollup 區塊拆成更小的單位 slot。
- 假設可以拆成 5 個 slot，那 Maker 抵押的押金就是 5 倍的 limit。
- limit 是協議訂的最高的轉帳金額上限。
2. 針對不支援合約功能的 Rollup，則要看那個 Rollup 一個區塊最高可容納多少筆交易（TPB，Transaction Per Block）。
- 例如 zkSync 1.0 的 TPB 約是 100（block size 390，tx size 4），那 Maker 抵押的押金就是 100 倍的 limit。
這兩個規則都可以看出，Orbiter 為了防止 Maker 收到大於其押金金額的轉帳而有動機選擇裝死的情況，它參考的依據是一個區塊最多可以塞多少筆交易，並假設最差的情況就是剛好一個區塊塞滿的交易都是轉帳給同一個 Maker 的交易，這種情況 Maker 的押金剛好能夠 cover 所有的轉帳請求。
Maker APY
這個連結裡有 Orbiter 團隊利用過去一個月的數據來估算 Maker 的 APY：
可以看到，如果將這段時間的平均轉帳金額（0.17 Ether） 當作 limit 的話，在不同 Rollup 的 TPB 對應到的不同押金數量。再搭配上這段時間的流動性總額（90 Ether）及日均手續費獲利（0.4085 Ether），可以算出預期的 APY。
可能的問題
不支援指定接收地址
Orbiter 目前還不支援指定 Rollup B 的接收地址，如果要支援指定接收地址，會需要挪用 Rollup 交易裡其他欄位。像是目前 Orbiter 就挪用轉帳金額的最小的幾個位元來當作不同 Rollup 的識別碼。
經濟激勵機制尚不完整
使用者要 challenge Maker 是不需要放押金的（相比於 Hop 的 challenger 要放押金），表示使用者 challenge 的成本很小，這是否會讓使用者有動機每次都去 challenge Maker，只要 Maker 忘記回應 challenge 或是 Maker 轉帳完就離線，那使用者就有機會獲得額外的報酬。
但引入 challenger 押金的機制也會有一些問題，像是
- 使用者必須要在 L1 有錢才可以 challenge
- 而且 Orbiter 的補償金是固定的，不像 Hop 的 challenge 機制裡獎金和金額成比例
- 另外 Hop 裡會有第三方有經濟動機成為 challenger，但在 Orbiter 裡只有使用者自己才有動機去 challenge，因為那筆轉帳會影響的只有使用者自己而已，不像 Hop 裡造假影響的會是其他 Bonder
押金機制針對極端情況的處理還不完整
押金的參考依據是一個區塊最多能塞下幾筆交易，再假設最糟情況是一個區塊都是轉帳給同一個 Maker，所以 Maker 的押金是 TPB*limit。
但這只要有交易還在 pending 中、沒被完成（使用者轉帳給 Maker，但 Maker 還沒轉帳給使用者），就能繞過這個押金機制的防護，因為 pending 中的交易是在之前的區塊，如果在有 pending 交易的情況下出現最糟情況 — 區塊裡大家同時轉帳給該 Maker，則這時候 Maker 收到的總金額就會超過他的押金，他就有動機裝死了。
我們可以反過來請使用者在看到一個 Maker 有 pending 交易時，先不要動作，等到 pending 交易都完成後再轉帳給 Maker。但第一個問題是如果有很多人同時要透過同一個 Maker，使用者會不知道要等多久。第二個問題是如果使用者都等待其他人的交易處理完才轉帳，那表示基本上一個區塊就只會有一個轉帳，那這樣設置 TPB*limit 的押金機制就沒有意義了。
不過這其中當然還有可以更細緻的調整可以嘗試，例如依照使用者的風險承擔程度，去決定當前 pending 金額佔 Maker 押金多少百分比的情況下，使用者願意送出交易。就看未來 Orbiter 團隊會怎麼設計。
如果要接上的 Rollup 可以接受 Invalid Tx，且要支援 native asset 以外（例如 ERC20）的轉帳，會有挑戰性
針對會收入 Invalid Tx 的 Rollup，而且要轉帳的不是 native asset 而是 ERC tokens 時，會有點棘手，因為這種情況下協議不只要能證明交易存在，還要能證明執行成功（協議要去比對交易前後的 state 變化，確認 Maker 餘額有增加），因為交易存在不等於交易執行成功，就像當前在區塊鏈你可以看到失敗的交易還是會被收入到區塊裡面。
如果不證明交易執行成功會發生什麼事？攻擊者可以做一筆 Invalid Tx 夾帶在其他使用者的 Valid Tx 後，然後去 challenge Maker。
註：Invalid Tx 和 Valid Tx 的轉帳內容一樣，只是攻擊者餘額不夠所以交易會失敗
考慮以下三種驗證機制
1. 如果協議像當前的設計，只驗證交易存在、發生過。那攻擊者只要證明 Invalid Tx 被收入在 Rollup 的區塊裡就好，challenge 一定可以成功，表示Maker 要平白無故賠錢給攻擊者。
所以我們除了驗證交易存在，還要驗證 state 的變化，確保 Maker 的餘額有增加。
2. 協議除了驗證交易存在，還驗證區塊前後的 state 變化，確認 Maker 的餘額是否真的增加了。但攻擊者這時候只需要將 Invalid Tx 和使用者的 Valid Tx 夾帶在同一個區塊就可以，因為協議單靠區塊前後 state 變化，分不出 Maker 餘額增加是因為使用者的 Valid Tx 還是攻擊者的 Invalid Tx
3. 協議除了驗證交易存在之外，還要能驗證交易前後的 state 變化。如此協議才能確認交易真的有導致 Maker 的餘額增加
加入 3. 這樣的驗證機制除了會更複雜之外，這會需要 Rollup 本身有 commit 每一筆交易的 post-state root。如果沒有的話，就只能退而求其次，在那個 Rollup 上只開放 native asset 的轉帳，因為 native asset 的轉帳失敗不會被收入到區塊裡（就像你做單純 Ether 轉帳，只要你 Ether 不夠，交易是一定不會被收進區塊，否則這就會是一個 DoS 風險：攻擊者只要一直送出會失敗的 Ether 轉帳就好）。
Hop 和 Orbiter 比較
- Orbiter 能夠支援沒有智能合約功能的 Rollup
- Orbiter 架構會比 Hop 簡單，合約也比 Hop 少很多
- Orbiter 主要只會 focus 在 native asset 的轉帳（受限於交易證明難度），Hop 則是除了 native asset 外，也能支援 ERC token 轉帳
- Hop 需要仰賴 AMM 有足夠的流動性，否則除了 Bonder 向使用者收的手續費外，AMM 的價格太差還會導致使用者換不到或損失更多錢
- 極端情況下，Orbiter 使用者可能因為 Maker 裝死、押金也不夠付，所以拿不到錢，但 Hop 只要 Rollup 運作正常，使用者就一定能拿到該拿的錢
- Orbiter 的 Maker 的在 L1 的押金是沒辦法挪作他用的，而且會是一筆不小的金額，而 Hop 對 Bonder 則沒有這個要求，除非真的發生 challenge
