原文：Builtins and Dynamic Layouts
翻譯及校對：「StarkNet 中文社區」
摘要
內置函數優化證明進程。然而，每條證明都是根據佈局計算的。而對特定證明工作，如果佈局效率低下，內置函數的優勢就會大打折扣。目前，有個佈局小型靜態列表，每個證明都是根據該列表中最合適的佈局計算的。這種佈局靜態列表的方式不足之處有二。首先，佈局種類有限。這對於大多數證明工作來說效率低下，會造成複雜的收費機制，讓用戶承擔不必要的成本。其次，手動維護列表困難。一旦內置函數數量過多，手動維護就會變得很困難，實際上會阻礙證明進程中支持大量細微之處高效的內置函數。為解決這些問題，StarkWare 團隊正在開發一個動態佈局系統，其中的佈局都是為每個證明工作量身定制的。
Cairo 堆棧通過將Cairo 代碼編譯成適用於STARK 友好型CPU 架構的指令來促進可證明的通用計算：Cairo VM（以下稱為CVM）。通用CPU 的許多優勢是以固有成本作為代價的，CVM 並未針對一些常用運算進行優化。 Keccak、Pedersen、Poseidon 哈希函數是這類常見運算，還有橢圓曲線操作、範圍檢查（即檢查特定數字是否位於特定值範圍內）等其它運算。
為解決CVM 相對低效的問題，Cairo 堆棧引入了關鍵運算的內置函數概念：即優化此類運算證明復雜性的插件。內置函數可以類比ASIC：ASIC 是專用集成電路，而內置函數是應用程序專用代數約束（AIR）。如果不知道或者不記得什麼是AIR，文章稍後會簡要介紹；更多詳細信息請閱讀這篇文章。
簡而言之，證明復雜性與稱為軌跡單元的資源相關（大致呈線性關係），內置函數通過使用比Cairo VM 少得多的軌跡單元來簡化特定運算的證明。
解釋過內置函數的好處後，就知道為什麼要為許多常用運算開發內置函數了。這說起來容易做起來難。目前把新內置函數引入Starknet 的過程包含以下幾個步驟：
1. 編寫AIR
2. 通過創建新佈局（如下所述）與證明器集成
3. 集成到Starknet，即修改其代碼庫和開發者工具以使用新的內置函數
除了編寫AIR 的挑戰之外，在其餘兩個階段還有很大的改進空間。這篇進階級文章將更詳細地介紹作為應用程序專用AIR 的內置函數、上述問題以及未來計劃。
內置函數：應用程序專用AIR
AIR 是代數中間表達式（Algebraic Intermediate Representation）的縮寫。在本文及StarkWare 其它文章中，AIR 是表示虛擬機的多項式系統。例如，Cairo 的名稱來源於CPU AIR：表示特定CPU 架構的多項式系統。此多項式系統的解代表有效的狀態轉移，稱為有效代數執行軌跡（AET）。
STARK 通過證明給定的AIR 對應的執行軌蹟有效，來證明虛擬機的運算正確。大致上來說，執行軌跡是一組數字表，而STARK 協議證明這些數字共同解決一個多項式系統。
同樣的運算可以有多種計算方式，其中一些計算要更為高效。在本文中，證明復雜性基本上取決於軌跡大小，即表格中軌跡單元的數量。由於軌跡是針對AIR 生成的，因此專為應用程序設計的AIR 可以大幅減少特定計算的執行軌跡。內置函數是專為應用程序優化的專用AIR。
下表展示了特定內置函數的效率改進（都已投入生產）。
軌跡佈局：現在和未來
之前說到AET 大致上是一個數字表，表示編碼虛擬機的步驟排序（即程序的執行）。為計算證明，證明器在相關AIR 的執行軌跡上運行STARK 協議。
在上文中，我們介紹了內置函數作為應用程序專用的AIR，旨在通過減少對計算進行編碼所需的軌跡單元數量，來最大限度降低證明的複雜性。然而，如果在Starknet 隨意集成內置函數，可能會導致浪費許多軌跡單元，預期的好處也會減少。下面來詳細說明。
簡而言之，軌跡佈局是將軌跡單元分配給不同的「組件」。在本文中，這些組件是CVM 和內置函數。具體來說，佈局指定每個組件獲得的軌跡單元的相對數量。 （佈局構造始終是用來簡化驗證的。如需了解更多，請閱讀這篇文章中的「簡潔性」部分）。
關鍵點在於，證明復雜性取決於佈局分配的軌跡單元總數，而軌跡單元分配有可能大於實際需要。例如，為證明CVM 的步驟排序，僅將軌跡單元分配給CVM 組件的佈局，與把一半的軌跡單元分配給Poseidon 內置函數的佈局相比，效率大致翻倍。總之，合適的佈局可以大大降低證明特定計算的複雜性。
目前有一份手動維護的佈局列表，主要由於兩個原因逐漸增長：
1. 內置函數只能用於為它們分配軌跡單元的佈局。因此，添加內置函數至少需要一個新佈局。
2. 為執行Cairo 代碼定制的佈局可以優化單元分配。因此，單元里用例的優化通常需要新佈局。
證明器和驗證器（Solidity 和Cairo 驗證器）的代碼是根據佈局列表配置的。
隨著添加Keccak 和Poseidon 內置函數，發現越來越難以保證佈局列表小巧，同時容納眾多內置函數，保持大多數Starknet 區塊高效執行。此外，隨著引入額外的內置函數，效率預計會大幅下降，因為佈局必須考慮內置函數之間許多可能的組合與比例。
StarkWare 團隊目前正在努力改進系統，放棄預先制定的佈局列表，支持「動態佈局」，即為每次執行Cairo 代碼即時定制。動態佈局將始終針對手頭的驗證工作進行最佳比例的分配。從工程學的角度來看，支持動態輸入需要對代碼庫進行相當大的更改。然而，StarkWare 團隊希望利用動態佈局，提高軌跡單元利用率，更好地利用證明器，來簡化Starknet 的證明層。
有了動態佈局，手動維護許多內置函數的麻煩就不復存在，從而簡化Starknet 集成更多新內置函數的過程。
動態佈局和費用
交易費用的一個目的是向用戶收取交易產生的協議邊際成本。由於交易費用的單位是貨幣，費用機制涉及從資源（例如虛擬機步驟、內置函數、calldata、以太坊gas）到代幣（例如STRK、ETH）的轉換。
目前，因為證明器根據總軌跡而非利用比率來收取費用，所以浪費的資源是由用戶來承擔的。動態佈局將提高軌跡單元利用率，從而減少收取「不必要」的交易費用（包括並非由用戶交易直接產生的資源消耗）。
Starknet 內置函數集成
至此，集成內置函數就差最後一步，即修改Starknet 代碼庫來實現實際運用。代碼修改幅度與佈局應用相關，確保Starknet 操作系統在可能的情況下調用內置函數就必須要修改代碼。例如，Starknet 操作系統執行Cairo 代碼期間調用Poseidon 哈希函數，同時要調用Poseidon 內置函數。
與佈局類似，現在可以手動支持Starknet 內置函數。然而，與佈局情況不同的是，這種手動支持即使有許多內置函數，也並不會對集成造成障礙。換句話說，Starknet 內置函數支持並不是集成的障礙，動態佈局將真正為創建和集成額外內置函數鋪平道路。
總結
在本文中解釋了什麼是內置函數、它們的好處、涉及的挑戰以及StarkWare 的計劃。目前重點關注動態佈局，它不僅會提高證明過程的效率，還會便於新內置函數集成。
