以下是使用彩虹橋技術執行的輕型客戶端簡圖。
請注意，除了執行輕型客戶端的智慧合約外，我們還有兩項叫做轉播（relay）的服務，該服務會定期將區塊頭髮送至輕型客戶端。Eth2NearRelay將每個單一區塊頭髮送至EthOnNearClient合約，同時Near2EthRelay每隔四個小時就會將一個區塊頭髮送至NearOnEthClient合約。每一對EthOnNearClient和NearOnEthClient合約，都可能會有若干對Eth2NearRelay和Near2EthRelay服務。 每個彩虹橋維護者可以執行一對服務。這些服務可能和彼此競爭——他們會試圖同時提交同樣的區塊，每次只會有一對服務成功。他們也會為彼此提供支援——一些服務只會在其他服務對沒有按時提交區塊的情況下提交區塊。我們目前的服務執行以第一種模式執行。
EthOnNearClient
正如我們之前說過的那樣，EthOnNearClient是採用Rust語言編寫的以太坊輕型客戶端的一種執行，也是一個NEAR合約。它接受以太坊區塊頭並對正統鏈（canonical chain）進行維護。它假設擁有finalized_gc_threshold次確認的區塊不能離開正統鏈，它會記住正統鏈的hashes_gc_threshold個區塊。在該正統鏈上，hashes_gc_threshold>=finalized_gc_threshold。預設狀態下，finalized_gc_threshold=46,000，這與累積7天的區塊頭數量大致吻合。這樣做可以保證EthOnNearClient的狀態不會無限制地增長。請記住在NEAR平臺，使用者需要有一定量的被鎖定的通證才能使用狀態(更多資訊)，如果我們對單一合約內的每一個以太坊正統區塊頭進行儲存，使用狀態就需要大量的且處於不斷增長狀態的鎖定通證。因此，我們只會儲存一定量的以太坊區塊頭的雜湊值。所以彩虹橋只能被用來證明在這一時間範圍內發生的活動。所以如果您在進行ERC20通證轉賬（以太坊至NEAR）時，程序發生了中斷，請確保在7天之內完成轉賬流程。
有關EthOnNearClient另外一個重要的差異是它驗證以太坊區塊頭的方式。直接在合約內部驗證以太坊PoW是不可以的，因為這麼做需要儲存以太坊的DAG檔案，而這一操作會佔用大量記憶體，價格不菲。幸運的是，每個以太坊區塊都僅僅使用DAG檔案元素的一個子集，且每個以太坊週期都只有一個DAG檔案。此外，DAG檔案可以提前進行預計算，以備未來的週期使用。我們會提前4年對DAG檔案進行預計算並將每個檔案進行默克爾化（merelize）。初始化之後，EthOnNearClient合約會在未來四年記住DAG檔案的默克爾根。之後，EthOnNearClient僅需要收到以太坊區塊頭、DAG元素和這些元素的默克爾證明，這將允許它無需擁有記憶體中的全部DAG檔案就可以對PoW進行驗證。我們借用的是文章《Kyber網路使用的EOS橋技術》中的方法，而且我們甚至可以複用他們的一些程式碼。幸運的是，以太坊區塊頭的驗證工作僅使用交易gas費上限的三分之一和區塊gas費上限的十分之一。
NearOnEthClient
NearOnEthClient採用Solidity語言編寫，是NEAR輕型客戶端的一種實現，也是一個以太坊合約。和EthOnNearClient不同的是，它並不需要對每個單一的NEAR區塊頭進行驗證，且可以跳過大多數區塊頭，前提是它驗證了每個週期中的至少一個區塊頭。每個週期大概有43,000個區塊，大概持續半天時間。 最終，NearOnEthClient可以記住歷史上所有已提交的NEAR區塊頭的雜湊值。如果您正在進行由NEAR至以太坊的轉賬並且該過程被中斷了，對此您無需擔心，您可以在任何時候恢復這一程序，即使是幾個月之後也可以。 NEAR輕型客戶端另一個有用的特點是，每一個NEAR區塊頭包含一個默克爾樹根，該默克爾樹根是從該區塊頭前面的區塊頭計算得來的。如果您有一個NEAR區塊頭，您可以高效地驗證任何發生在該區塊頭前面的區塊頭中的任一事件。
NEAR輕型客戶端另一個有用的特點是該客戶端只接受最終區塊，而在NEAR平臺，最終區塊不能離開正統鏈。這就意味著，NearOnEthClient無需擔心分叉。
然而，不幸的是，NEAR 使用 Ed25519對負責審批區塊的驗證節點的訊息進行簽名，而該簽名不會以EVM預編譯的形式可用。這就使得對NEAR單一區塊頭的全部簽名進行驗證變得十分昂貴。 所以技術上看，我們不能只透過對NearOnEthClient進行一次合約呼叫就完成NEAR區塊頭的驗證工作。因此，我們採用了 optimistic approach。按照該方法，NearOnEthClient會對區塊頭中除簽名之外的全部資訊進行驗證。之後，任何人都可以在一個已提交的區塊頭中對簽名提出質疑，質疑視窗為4小時。質疑需要對單一的Ed25519簽名進行驗證，這項工作將花費大約500,000的以太坊gas費（很昂貴，但是是可以做到的）。 提交NEAR區塊頭的使用者需要使用以太坊通證釋出一個債券，一個成功的質疑將消耗一半的債券通證，剩下的一半會歸還給質疑者。即使gas費在這4個小時期間呈指數增長，債券規模也必須足夠支付gas費。比如，一個價值20枚以太坊的債券能夠承擔的gas費為20,000Gwei。這一optimistic approach需要有一個監督(watchdog)服務，負責對已提交的NEAR區塊頭進行監督，並對任何包含無效簽名的區塊頭提出質疑。為了獲得更多的安全性，獨立使用者可以執行若干個監督服務。
一旦EIP665被接受，以太坊將擁有Ed25519簽名，可作為EVM預編譯使用。這將讓監督服務和4小時的質疑視窗變得不再必要。
彩虹橋最少會包含EthOnNearClient和NearOnEthClient合約以及3項服務：Eth2NearRelay、Near2EthRelay和Watchdog。我們可能會認為這已經是一個橋工具了，因為我們在兩條鏈之間建立了一個加密連結。但是若要使用這種模式的橋，應用開發者們可能需要額外編寫大量程式碼，這顯然是不實際的。
證明工具（Provers）
能夠證明某一事件在某條鏈上發生過會讓客戶端變得更有用。為此，我們用Rust語言執行NEAR合約——EthOnNearProver，並用Solidity語言執行以太坊合約——NearOnEthProver。 EthOnNearProver可以驗證以太坊事件，NearOnEthProver合約可以驗證NEAR合約執行結果。EthOnNearProver和NearOnEthProver的實現，與EthOnNearClient和NearOnEthClient的實現是分開的，理由如下：
· 關注分離（Separation of concerns ）：客戶端負責追蹤最新的區塊頭，證明工具則負責驗證具體的加密資訊
· 可拓展性（Scalability）——因為NEAR是一條分片鏈，如果橋的某一例項變得非常流行，使用者可以透過部署某一證明工具的多個副本來提升負載能力
· 特異性（Specificity）——除了上文描述的證明工具，使用者還可以執行其他種類的證明工具。使用者可以驗證合約狀態區塊頭的具體內容，或是交易的收錄情況。此外，證明工具的不同實現方式可能會使用不同的最佳化方法。
目前，我們僅提供了驗證以太坊事件（events）和NEAR合約執行結果的實現，這對在不同鏈之間轉移通證來說已經足夠了。不過我們仍然歡迎大家為證明工具執行貢獻自己的力量。
說明：對一個EthOnNearClient而言，可能有多個證明工具與其溝通並將資訊複製到多個分片上；對一個NearOnEthClient而言，只有每類證明工具的一個與其溝通。
ERC20用例
使用證明工具可以幫助我們開發一套具備資產轉賬或跨鏈通訊功能的合約。然而，由於我們想要透過彩虹橋實現互操作的物件的不同，這些合約也大不相同。比如，ERC20要求一套完全獨立於ERC721或原生通證轉賬的合約。目前，彩虹橋為通用的ERC20通證轉賬提供了開箱即用支援，未來我們會增加更多的用例。在本篇部落格中，我們僅關注ERC20用例。
假設以太坊有一套ERC20通證，比如說穩定幣DAI。我們要想透過彩虹橋轉移這類通證，就需要部署2套額外的合約：
使用Solidity語言執行的以太坊合約——通證鎖定器
使用Rust語言執行的NEAR合約——可鑄造的同質化通證（Mintable Fungible Token）
某使用者想從以太坊轉移X枚DAI至NEAR，他們首先會在通證鎖定器合約鎖定X枚DAI，然後在NEAR合約可鑄造的同質化通證鑄造X枚nearDAI。如果他們想從NEAR轉移一些通證至以太坊，他們首先會在可鑄造的同質化通證銷燬Y枚nearDAI，然後在通證鎖定器解鎖Y枚DAI。
目前，ERC20通證的每個例項都要求部署一對獨立的通證鎖定器/可鑄造的同質化通證。不過，我們未來會解除這一限制，為多種ERC20通證使用同樣的通證鎖定器。 需要注意的是，如果某人想要增加ERC721的支援或另外一種資產轉賬，他們需要執行類似的鎖定器/資產對，且有一個不同的外部介面和內部實現，不過高層（high-level）設計將維持原狀——鎖定器會鎖定/解鎖資產，Asset會鑄造/銷燬NEAR版的這一資產。
Usage flow
使用者未來將能夠使用RainbowCLI或任意一種整合RainbowLib的應用，如NEAR錢包。在極少數情況下，使用者可能會選擇以手動方式與彩虹橋互動，即使用低階別（low-level）的合約呼叫指令，從他們的shell呼叫以太坊和NEAR合約。目前，我們僅支援RainbowCLI，不過我們也在籌備RainbowLib和錢包整合。
從使用者角度看，通證轉賬應該直白易懂：他們提供憑證，選擇受益人和數量，透過RainbowCLI、錢包或其他應用啟動轉賬。一段時間後，轉賬成功，使用者收到可視的驗證資訊。然而，轉賬成功的背後，RainbowLib會執行下列複雜的操作：
1. 假設Alice想給Bob在NEAR鏈上轉賬X枚DAI，她使用RainbowCLI/RainbowLib啟動了轉賬流程
2. RainbowLib首先會為由Alice至通證鎖定器的轉賬設定一筆費用
3. 之後RainbowLib會呼叫通證鎖定器，捕獲那些導致通證鎖定器釋放“Alice為Bob鎖定X枚通證”事件的通證
4. 然後，RainbowLib會等待一段時間，直到EthOnNearClient收到包含上述事件的以太坊區塊頭，以及25個區塊來確認（具體可參見開篇一章中有關以太坊最終性的註釋）
5. 然後，RainbowLib會計算這一事件的證據，並將其提交給可鑄造的同質化通證合約
6. 可鑄造的同質化通證合約會呼叫EthOnNearProver來驗證這一證據是正確的
· EthOnNearProver驗證該證據的區塊頭位於EthOnNearClient的正統鏈上，且該工具擁有規定數量的驗證次數。該工具也會對證據本身進行驗證；
· 可鑄造的同質化通證拆解這一以太坊事件，併為Bob鑄造X 枚nearDAI，轉賬至此結束。
類似地，RainbowLib將能夠執行ERC20之外的通證轉賬及合約呼叫等任務。
硬分叉
我們希望NEAR或以太坊協議發生變化時，現有的彩虹橋不會崩潰。我們也希望當重要的效能升級可用的時候（如EIP665被接受），我們能夠對彩虹橋合約進行升級。然而，我們不想以中心化的方式啟動升級，從而削弱其無需信任或去中心化的程度。
目前以太坊社羣已開發出很多種允許合約升級的代理模式。不過，我們認為最安全的升級模式應該是將升級決策委託給使用者。與這一使用者控制的彩虹橋升級模式類似的方法應滿足以下條件：
假設使用者正在使用彩虹橋在以太坊和NEAR之間轉賬。他們有X枚DAI鎖在通證鎖定器（TokenLocker），有X枚nearDAI在NEAR這一端可用；
假設有一天他們收到一份宣告，該宣告稱NEAR或以太坊正在進行協議變更，他們需要在一週之內轉移至V2版本的彩虹橋
他們使用舊有的橋工具將nearDAI重新轉回至DAI，然後使用V2版本的彩虹橋將DAI轉移至 V2版本的nearDAI
不過這一方法存在一定缺陷：
· 和普通的合約不同，該橋是一套更復雜的且需要維護的系統——某些人需要持續地執行轉播服務，否則輕型客戶端就要和區塊鏈失去同步，變得毫無用處。這就意味著，我們不能要求使用者在他們方便的時候以手動方式從V1版本的彩虹橋轉移至V2版本的彩虹橋。 如果我們在全部使用者將資產轉出之前關閉V1版本彩虹橋的轉播服務，他們的資產可能會永遠處於鎖定狀態，且無法轉移至V2版本的彩虹橋。如果我們執行中繼的時間過長，並等到所有人都完成轉移，我們每天都會在費用上消耗gas，每天大概會花費40美元（40gwei）。
· 整合彩虹橋的應用需要對彩虹橋遷移這一情況有所瞭解，因為它們需要從舊的可鑄造的同質化通證合約切換至新的可鑄造的同質化通證合約。他們中的某些成員需要自行完成這一任務，或透過UI指導他們的使用者完成這一任務。
鑑於上述缺陷，我們已決定為彩虹橋技術整合下面的可升級性選項。我們會使用代理模式的一種來允許EthOnNearClient, EthOnNearProver，NearOnEthClient和NearOnEthProver收到能夠證明三分之二的NEAR質押已經投票透過新一套的合約版本的證據後，自動切換至新的合約版本。 大多數情況下，通證鎖定器和可鑄造的同質化通證不用做出改變，因此該升級對使用者和應用開發者是透明的。因為無論如何我們都需要相信三分之二的NEAR質押，所以這不會影響彩虹橋的信任模型。我們會使用和其他的NEAR平臺上治理機制同樣的投票合約。我們也會盡量減少該機制被用作後門（backdoor）的機率。 為此，我們會製造7天的升級延遲，使用者可以在此期間對其進行觀察、驗證。如果他們不喜歡它，可以清算他們的通證或將通證手動轉移至不同的橋。然而，我們會為NEAR驗證節點預留許可權，讓他們可以對某一緊急升級活動進行投票，不過我們並不希望他們有一天會用到這一許可權。
激勵措施
當下的彩虹橋並不為轉播區塊頭支付gas費的維護人員執行激勵。彩虹橋的主要使用者需要執行他們自己的轉播服務，至少有一對轉播服務會由NEAR團隊執行。彩虹橋的未來版本會提供向使用者收費的選項，執行轉賬的使用者需要以gas、原生通證或其他方式支付使用費。然而，設計一套可靠的激勵機制是很複雜的。最簡單的方法是向彩虹橋使用者徵稅，並將其分發給提供轉播服務的維護者們。 不幸的是，這樣的系統並不能阻止死亡螺旋的情況，即彩虹橋可能會發生故障，導致使用者在一段時間內停用該服務，並最終導致維護者對支付gas費失去興趣。我們的組織正循序漸進地開發一套完善的彩虹橋激勵機制。與此同時，我們會對其進行維護並自行墊付相應的成本。
