很多鏈爲了兼容性搞擴張，結果常會遇到問題：越想兼容，結構就越亂。EVM有自己的節奏，Cosmos有模塊化的體系，硬把它們縫一起，性能、狀態一致性、開發體驗、治理等方面，都會互相影響。
但 @Injective 厲害的地方在於，它既能跑 EVM 合約，又能跑 Cosmos 原生模塊，而且架構還很穩，不像打補丁一樣。它不是簡單加個 EVM 層，而是底層結構做得好，兩套體系互不干擾，運行效率也不會下降。
1. 核心邏輯被放置在 Cosmos 當中，擴展邏輯則被交由 EVM 去完成
Injective 所採取的做法，並不是把 EVM 當作其核心來運用，而是把它給放置到了一個“擴展層”的位置上。像是鏈級別的執行、撮合、清算、治理以及狀態推進等這些關鍵性的動作，全部都被留在了 Cosmos 的模塊體系裏頭，由原生模塊來負責去處理“系統行爲”；與此同時，E-V-M 則是被當作一種“應用接口”來使用的，它讓開發者能夠像是通常在以太坊上那樣去編寫邏輯，卻又不會去觸碰到系統級的狀態。
Injective 並沒有讓這兩套系統去爭奪同一個心臟，而是選擇讓 Cosmos 來控制整體的節奏，EVM 則負責去提供表達力方面的支持。如此一來，它便避免掉了許多兼容鏈都會出現的那種結構衝突方面的問題。
2. 狀態空間是被分隔開來的，但是數據路徑卻是統一的
Injective 並非是把 EVM 和 Cosmos 給混雜到同一個狀態樹裏面去，而是讓二者的數據路徑在鏈的級別上被加以統一的協調，與此同時又保持了存儲層面的隔離。這種結構上的設計，使得鏈不需要爲了 EVM 去單獨維護一套共識方面的邏輯，也不會把 EVM 在執行期間出現的錯誤給帶到系統狀態裏頭去。
狀態隔離所帶來的好處是很明顯的：即使一個 EVM 合約被寫得再怎麼複雜，它也不會去弄亂鏈的核心模塊；而 Cosmos 模塊在推進狀態的時候，也不需要去等待 EVM 層來完成同步的動作。最終呈現出來的結果是，系統既擁有了擴展性方面的特性，又沒有產生那種“兩個世界互相拖後腿”的不穩定感覺。
3. 以 Cosmos 的模塊化特性作爲骨架，讓擴展不會演變成一種負擔
Injective 所具備的穩定性，在很大程度上是來自於 Cosmos 本身所擁有的那種模塊化特性。每一個模塊都擁有其明確的職責，其執行路徑也是以分軌的方式來運行的。要是在這個框架下面去加入 EVM，並非是把 EVM 當作主角來看待，而是把它給變成了一個“可以掛載的擴展模塊”。這樣的設計讓 EVM 得以成爲一種能力，而不是某種外來的系統。最重要的一點在於，模塊化的特性讓 Injective 能夠去嚴格地控制哪些邏輯可以進入到系統級的路徑、哪些邏輯又只能停留在應用層，從而便避免了 EVM 去改寫關鍵行爲，也避免了應用層的邏輯去擠壓系統資源的情況。
4. 跨環境的調用由鏈級中間層加以過濾，以保證節奏的乾淨
Injective 並不是讓 EVM 合約能夠直接和鏈的核心模塊去進行對話，而是通過藉助一個鏈級的中間層來對其進行“翻譯”的動作。這個中間層允許應用去讀取必要的鏈級數據，但是並不會讓它們能夠去修改系統的推進方式。任何跨環境的調用都會被加以過濾、規範和校對，如此一來便能使系統不會因爲一個外部接口就去改變自身的運行節奏。這種中間層機制正是 Injective 能夠保持其結構不亂的關鍵所在，因爲它讓 Cosmos 的執行節拍得以保持絕對的主導地位，而 EVM 則只是一個被附加的表達空間罷了。
結尾
Injective 在兼容性方面的做法，並不是那種“把兩個系統拼起來”的粗糙實踐，而是把 Cosmos 當成了一個骨架，與此同時又把 EVM 當成了一種擴展。系統級的邏輯全部都由 Cosmos 的模塊來加以控制，擴展層方面的能力則由 EVM 來承擔，二者之間的狀態與調用路徑都被進行了嚴格的隔離與校準。
因此，它不像一般的兼容鏈那樣往往會出現結構上的衝突，也不會因爲去擴展了 EVM 就讓底層的邏輯失去其穩定性方面的特性。對開發者來說吧，這是一個“更容易去進入的生態”；而對金融類的應用來說呢，則是一個“不會因爲擴展性而犧牲掉可靠性”的運行環境。
