Tezos Ithaca 升級重點整理

本篇文章由 Marigold.dev 提供技術支援。更多關於 Marigold 以及 Tezoz 的消息在 Twitter 和 Reddit 上都可以找到!

+ 主要重點：Tenderbake

從使用者觀點，Tenderbake 的關鍵是實現了 Tezos 上的決定式最終確認性 (deterministic finality)。換句話說，一個區塊 (block) 只要其上面(後面)再有接上兩個區塊的話，該區塊就被視為已經達到最終確認狀態 – 也就是被網路承認並接納，且不可再被更改。

讓我們更白話一點：藉由 Tenderbake ，Tezos 的「區塊最終確認性」由原本的「機率式 (probabilistic)」改為「決定式 (deterministic)」。兩者之間的差異在於：前者更傾向於「不管各種情況，網路就是要順利產生新的區塊。如果未來發現有衝突，那就未來網路都同步以後再解決」因此也被視為是一種「生存優先」的共識演算法類型；相比之下，後者比較傾向於「一旦區塊被產生並且被確認，那他就是絕對合法的。如果無法產生或是確認，那就暫停產生區塊直到狀況恢復」所以被當作是一種「安全優先」的共識演算法類型。

講半天，到底有什麼好的？其實對於使用者來說，最直接的好處就是：Tezos 產生區塊的速度被大大地提昇。原本在杭州協定中的共識演算法 (被稱為 Emmy*) 所設定的「一個區塊最少需要6 分鐘才能確保達到最終狀態」，在這次更新中會被改進成「一個區塊最多需要兩個區塊的時間 (大約是 1 分鐘) ^[1] 就能確保達到最終狀態」。

當然，天下沒有白吃的午餐。事實上，Tenderbake 必須要整個網路有 2/3 的節點都是正常運作的情況下，才能持續正確地產生區塊。這看起來好像對於 Tezos 的穩定性是一種挑戰，不過我們也換個角度來看。Tezos 發展至今已經在全球累計了足夠且積極的參與者，網路與系統都發展的相當健全，確實是可以從「生存優先」推進到「安全優先」。所以對速度以及安全性來說，這種前進的發展方向也是合理且必然的。

+ 次要要點：預先檢查

預先檢查 (precheck) 是針對 Tezos 操作 (operation) 檢查的進一步強化。藉由在「嘗試執行一個操作」前，先行檢查該操作的格式以及所需費用等等客觀條件是否滿足，來達到「減少花費時間在嘗試執行不合法的操作」的目的。而這改進的效果在執行合約的情況下會更明顯。

+ 次要要點：票券強化 [持續進行中]

票券 (ticket) 是 Tezos 提供的原生資料結構，可以被用來儲存並傳遞各種代幣或是資料。Ithaca 本次也進行強化票券結餘狀態 (ticket balance) 的安全性以及可視性。此更新可以大大地增加未來代幣交易的安全性，也開啟了各種與 layer 2 方案的可能整合方向。

注意，這個更新並未完全完成，此功能更新的後半將於下一次核心協定提案中提出。

---

1. 藏在細節裡：注意這邊並不是直接說「最多一分鐘」而是「最多兩個區塊」。Tenderbake 這次更新了一個新的共識演算法，這個演算法只是個框架，真正重點的關鍵在於，他提供了未來更多微調的可能性。唯一被演算法綁定寫死的是「兩個區塊」，而所謂「一分鐘」是因為現在的參數設定使得兩個區塊需要的時間大約是一分鐘。而到底兩個區塊大約需要多少時間，則是未來可以再做調整的。這也是為何會說 Tezos 未來上看交易速度可以上到 15 秒甚至更短的關鍵！ ↩︎