如果我們希望eth2鏈瞭解eth2狀態（允許ETH從eth2返回到eth2的前提），有兩種方法可以做到這一點。一種是使PoW鏈包含PoS鏈的輕客戶端， 另一個是要使PoS 的敲定裡包含PoW 的敲定(finality)。後者可以透過新增一種機制來實現，在這種機制中，如果 PoS 塊 BS 透過 eth2資料投票包含對 PoW 塊 BW 的引用，並且 BS 最終完成，那麼 BW 也被視為最終完成。但是，這意味著PoW礦工（和客戶端）還需要執行eth2實現，以便他們瞭解 eth2 鏈的敲定情況.
前者需要在eth2內部實現的eth2客戶端, 這將需要Webassembly或BLS-12-381驗證的本機支援，目前預計不會很快發生。另外，它僅提供輕客戶端級別的安全性。
後者更有趣，因為它為eth2提供了一種本地形式的反轉限制(通常稱為finality gadget建議)。注意，這個建議與第一個不同，因為它雖然讓eth2 fork選項知道eth2，但並沒有立即讓eth2知道eth2的狀態。例如，請注意，兩個相互競爭的eth2鏈在理論上有可能完成相同的eth2塊(這意味著eth2已經破壞，但在理論上仍然有可能)。
更常見的情況是，可能有兩個eth2 最終區塊，其中一個是另一個的子代，兩者都支援相同的eth2塊，並且一些礦工可能知道這兩個eth2塊中的較新者，而另一些礦工則不知道。對於“ eth2作為敲定性小工具”來說，這不是問題，但這確實意味著我們需要更多基礎設施，以允許eth2明確瞭解eth2 區塊狀態，以便允許從存款合約中提取款項。
一種可能是在eth2內部簡單地建立一個eth2_data投票機制；本質上，複製一份讓eth2瞭解eth2的機制。這可以與上述內容結合起來，以確保一致性， eth2 曠工僅在下述兩種情況下會為為 eth2 資料區塊投票：eth2 曠工正在構建的eth2資料塊(i)已經完成，並且(ii)在它們的eth2資料塊中引用了它們的eth2資料塊(它們是曠工正在構建的eth2資料塊的祖先)
挑戰
這兩項提議都需要對eth2進行修改。目前，eth2路線圖在the final transition 4
之前沒有任何eth2方面的更改。這兩項建議都要求在eth2側發生損壞時，對eth2側採取緊急補救行動。後一個建議要求所有的eth2 曠工也執行一個eth2節點。因此，雖然這兩項建議都是絕對可行的，但不應迅速執行。
然而，當 eth2繼續執行並證明了它的適應性，那麼在某個時刻實現這樣一個橋樑肯定是有意義的。為了降低風險，可以做以下幾件事:
· 在eth2上執行eth2投票，投票期為一週，以便在出現問題時為人工干預留出時間
· Eth2鏈透過輕客戶瞭解到 eth2定稿塊，也可能由於類似原因推遲一個星期才退出
· 只有當抵押足夠高時(例如大於500萬)才開啟橋樑
· 把投票的門檻設得高於50%(例如。80%);系統傾向於不包含任何eth2塊，除非它們之間有很強的一致性。
