Tezos Kathmandu 升級重點整理

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

這次換不同的編排呈現方式，希望可以減少閱讀障礙。另外也新增一個新的段落來分享一下可以期待的更新內容。

• Tezos Kathmandu 升級重點整理
  • + 主要更新
    • Contract Event Logging
    • Operation receipts
    • SCORU (發展中)
    • Data Availability Layer (發展中)
  • + 次要更新：
    • Randomness generation
    • Increase_paid_storage
    • RPC
• 引頸期盼：
  • 更強大的合約
  • Baker 權限管理
  • 快還要更快
  • 參考資料

+ 主要更新

Contract Event Logging

此次更新新增了一個 Michelson 指令： EMIT 。藉由這個指令，現在合約可以在執行期送出一筆可以作為紀錄的資訊。這筆資訊被稱為「合約事件」 (contract event) 並且會被儲存於該合約呼叫之操作明細 (operation receipt) 中。合約事件的角色類似合約執行時可以被附加在操作結果的額外資訊。

因為不佔用額外合約空間，因此需要的資源成本低非常多。不過要注意的是，因為是儲存在明細之上，因此合約事件無法被其他合約所感知或讀取。因此合約事件是一個適合用來實踐「鍊上至練下通知」使用情境的機制。除此之外，合約開發者也可以進一步將這些資訊進行標記並分類。這使得 DApp 應用端可以客製化適用於自己應用的 indexer 來專門針對自己有興趣的主題進行監聽，進而舒緩 DApp 常常需要倚靠大型且中心化的 indexer 的情況。

更多說明與使用範例請參考 Marigold 的 blog: How to send events from contract (fast)。

Operation receipts

SCORU (發展中)

Smart contract rollups are targeted for later this year. The chosen approach is inspired by proven designs for rollups, but tailored to Tezos. They are designed with a generic structure that is not limited to Michelson smart contracts, but can be adapted to support environments like WebAssembly or EVM, the Ethereum Virtual Machine.

---

The end state for Tezos scaling is enshrined optimistic rollups such as Smart Contract Optimistic Rollups (SCORUs). The enshrined optimistic rollups will support any virtual machine, thus vastly expanding Tezos’s capabilities. Testing for SCORUs is slated to begin with the Kathmandu upgrade.

The final element to horizontally scaling Tezos through rollups is a data-availability layer to increase total bandwidth and capacity and improve throughput for rollups. While rollups move computation from Layer-1 to Layer-2, the data availability layer moves data from Layer-1 to Layer-2 which is projected to increase throughput by 1,000-10,000x.

Data Availability Layer (發展中)

In blockchains, a data availability layer is a system that stores and provides consensus on the availability of blockchain data. The ‘data availability layer’ refers to the location where transaction data is stored.

There are two types of data availability layers:

1. On-chain data availability layer‍

This is the standard approach among many blockchains, in which data is stored on-chain by the nodes who execute transactions. While this ensures high data availability, it limits decentralization and scalability.
2. Off-chain data availability layer‍

This approach requires storing transaction data outside the original blockchain network. An off-chain data availability layer may be another blockchain or any data storage system chosen by developers. In this case, the data availability layer focuses on storing data, not execution.

---

Next-level scaling
While optimistic rollups are a good scaling solution for Tezos, they do currently have limitations.

One issue is that all transaction data for the rollup inbox must be included in blocks on the main chain, but there is a limit to how much data can be stored in each block.

Therefore, avenues for further scaling are being researched and developed.

While sharding all main chain functionality isn’t an approach we’re currently pursuing for Tezos, sharding can be used to increase the size of the inbox for rollups.

The approach is called data-availability sharding, and has the major benefit of further increasing rollup throughput as more bakers join the network. Horizontal scaling at work.

Instead of having every main chain node download and store all incoming rollup transaction data, the data is spread among the network nodes, and among bakers in proportion to their stake. Essentially making bakers data providers for rollup nodes.

This increases the total bandwidth and capacity, which improves throughput for rollups significantly. If rollups alone offer a 10-100x increase in throughput, the increase is 1,000-10,000x when combined with data-availability sharding.

+ 次要更新：

Randomness generation

VDF-based; for selection in protocol only

Increase_paid_storage

RPC

引頸期盼：

更強大的合約

Tickets UX improvement
Michelson bytes instrcution
Big map cache

Baker 權限管理

Consensus Key

快還要更快

ZKORU
SCORU
WASM
Data Availability Layer

• https://gitlab.com/tezos/tezos/-/milestones/82#tab-merge-requests
• https://hackmd.io/yTDkFUGVSuuSrHWNJqMU3A
• https://nomadic-labs.gitlab.io/das-design/

參考資料

• https://www.marigold.dev/post/how-to-send-events-from-contract-fast
• https://www.marigold.dev/post/scaling-tezos-with-layer-2-solutions
• https://www.marigold.dev/post/running-rollup-node-to-test-toru-on-jakartanet
• https://research-development.nomadic-labs.com/tezos-is-scaling.html