--- tags: tezos-taiwan --- # Tezos Jakarta 升級重點整理 :::success ![](https://i.imgur.com/1BclaY7.png) 本篇文章由 [Marigold.dev](https://www.marigold.dev/) 提供技術支援。更多關於 Marigold 以及 Tezoz 的消息在 [Twitter](https://twitter.com/Marigold_Dev) 和 [Reddit](https://www.reddit.com/user/Marigold_dev) 上都可以找到! ::: **+ 主要重點：Transaction Optimistic Rollups (TORU)** ORU 是一種 layer-2 解決方案。其設計概念是藉由「將大量複雜的計算外包給第三方」，來增加整體交易與運算的吞吐量。ORU 在理想上可以將任何區塊鍊上面可進行的運算都打包處理。但是對於一個去中心化的系統來說，如何確保計算結果之正確性以及系統安全性就是個很大的挑戰。另一方面，相較於執行合約這種複雜的運算，單純的 「token 交易」則是一種計算量少，卻非常常見的需求。 因此，Tezos 這次推出僅針對交易的 **Transaction Optimistic Rollups** (TORU)。 與現在還在開發中的超級強力怪物：一般性合約 ORU (SCORU) 略為不同。TORU 無法處理複雜的合約結算，相對地，TORU 提供了非常便宜且快速的各種 token 交換。其相對簡易上手的流程也可以當作是一個「如何使用 Tezos ORU 機制」的練兵場。 同時，與一般常見的以合約為結算邏輯主體的 ORU 不同，TORU 是直接由 Tezos 核心協定定義。所以我們不需要擔心這個 ORU 是否是有可信賴的單位開發，畢竟它已經是協定的一部分，已經由很多專門的工程師審查過。另一方面，直接由協定定義可以減少執行期的摩擦成本，進而使得使用 TORU 來做交易所需要的手續費又更加地便宜。 特別值得注意的是，這裡說的 "*token*" 是只一般性的名詞。技術上來說，TORU 是基於 Tezos 票券 (ticket) 而實作的，因此所有可以用票券包的東西都可以使用 TORU 來交易。 更多細節詳閱[公開手冊](http://tezos.gitlab.io/jakarta/transaction_rollups.html)。 **+ 次要要點：強化票券檢查** 票券 (ticket) 是 Tezos 提供的原生資料結構，可以被用來儲存並傳遞各種代幣或是資料。Jakarta 將完成在 Ithaca 中已經鋪好基礎的票券強化 - 在合約執行期間檢查所有票券的生成、轉移以及更新。藉此保護各種票券的使用以及確保其帳務平衡。 **+ 次要要點：投票流程** 投票流程中的投票力將不再以卷 (rolls) 來表示。現在起會直接以 mutez 來表示。 **+ 次要重點：Michelson** - 因應 TORU 的出現，Michelson 將加入新的資料型別: `tx_rollup_l2_address` 用以作為辨識和表示 TORU 上面的帳號。一個 `tx_rollup_l2_address` 是一個基於 BLS 且 20-bytes 長的 hash，並且以 `tz4` 作為前贅詞。 - 禁止在 views 中直接使用指令： `CREATE_CONTRACT`, `SET_DELEGATE` 和 `TRANSFER_TOKENS` 。只能先包入 lambda 中，然後再放入 view 裡面。 - 舊有的資料型態 `sapling_transaction` 將被改名為 `sapling_transaction_deprecated` 並被棄用。（現有的合約會自動被更新） - 新增一個資料型態 `sapling_transaction` 來作為新的 spaling 使用。 以上，就是這次超級濃縮版本的「Tezos Jakarta 升級重點整理」，更多細節請參考[這份文件](http://tezos.gitlab.io/protocols/013_jakarta.html#michelson)。