From 603f4df1a08a2ad4526fb805a02b722ac4e57a2a Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:15:42 +0000 Subject: [PATCH 1/2] i18n(zh-tw): translation import part 06 of 13 (23 files) --- .../docs/scaling/sidechains/index.md | 36 +- .../docs/scaling/state-channels/index.md | 261 ++++++++++++ .../developers/docs/scaling/validium/index.md | 93 +++-- .../docs/scaling/zk-rollups/index.md | 144 +++---- .../docs/smart-contracts/anatomy/index.md | 395 +++++++++--------- .../docs/smart-contracts/compiling/index.md | 28 +- .../smart-contracts/composability/index.md | 46 +- .../docs/smart-contracts/deploying/index.md | 60 +-- .../formal-verification/index.md | 149 +++---- .../developers/docs/smart-contracts/index.md | 70 ++-- .../docs/smart-contracts/languages/index.md | 191 +++++---- .../docs/smart-contracts/libraries/index.md | 60 +-- .../docs/smart-contracts/naming/index.md | 101 +++++ .../docs/smart-contracts/security/index.md | 236 +++++------ .../docs/smart-contracts/testing/index.md | 186 +++++---- .../docs/smart-contracts/upgrading/index.md | 66 +-- .../docs/smart-contracts/verifying/index.md | 58 +-- .../zh-tw/developers/docs/standards/index.md | 59 +++ .../docs/standards/tokens/erc-1155/index.md | 146 +++++++ .../docs/standards/tokens/erc-1363/index.md | 204 +++++++++ .../docs/standards/tokens/erc-20/index.md | 187 +++++++++ .../docs/standards/tokens/erc-223/index.md | 197 +++++++++ .../docs/standards/tokens/erc-4626/index.md | 227 ++++++++++ 23 files changed, 2308 insertions(+), 892 deletions(-) create mode 100644 public/content/translations/zh-tw/developers/docs/scaling/state-channels/index.md create mode 100644 public/content/translations/zh-tw/developers/docs/smart-contracts/naming/index.md create mode 100644 public/content/translations/zh-tw/developers/docs/standards/index.md create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1155/index.md create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1363/index.md create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/erc-20/index.md create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/erc-4626/index.md diff --git a/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md b/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md index 711afd99424..b3071b911fa 100644 --- a/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md +++ b/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md @@ -1,13 +1,13 @@ --- -title: 側鏈 -description: 介紹目前作為擴張解決方案供以太坊社群使用的側鏈。 +title: "側鏈" +description: "介紹目前作為擴張解決方案供以太坊社群使用的側鏈。" lang: zh-tw sidebarDepth: 3 --- -側鏈是獨立於以太坊運行的獨立區塊鏈，並透過雙向跨鏈橋連線到以太坊主網。 側鏈可以有單獨的區塊參數和[共識演算法](/developers/docs/consensus-mechanisms/)，通常是為了高效處理交易而設計。 然而，使用側鏈需要權衡，因為它們不會繼承以太坊的安全屬性。 與[二層網路擴張解決方案](/layer-2/)不同，側鏈不會將狀態變更和交易數據發佈回以太坊主網。 +側鏈是獨立於以太坊運行的獨立區塊鏈，並透過雙向跨鏈橋連線到以太坊主網。 側鏈可以有獨立的區塊參數與 [共識演算法](/developers/docs/consensus-mechanisms/)，這些通常是為了高效處理交易而設計。 然而，使用側鏈需要權衡，因為它們不會繼承以太坊的安全屬性。 與 [layer 2 擴容解決方案](/layer-2/) 不同，側鏈不會將狀態變更和交易資料發佈回以太坊主網。 -側鏈也犧牲了一些去中心化或安全性措施來實現高吞吐量（[可擴展性三難困境](https://vitalik.eth.limo/general/2021/05/23/scaling.html)）。 然而，正如其升級[願景聲明](/roadmap/vision/)中所述，以太坊致力於在不影響去中心化和安全性的情況下擴張。 +側鏈也犧牲了一定程度的去中心化或安全性，以實現高吞吐量 ([可擴展性三難困境](https://vitalik.eth.limo/general/2021/05/23/scaling.html))。 然而，以太坊致力於在不犧牲去中心化與安全性的前提下進行擴容。 ## 側鏈的工作原理 {#how-do-sidechains-work} @@ -18,36 +18,36 @@ sidebarDepth: 3 讓側鏈獨一無二（即不同於以太坊）的特質之一是所使用的共識演算法。 側鏈不依賴以太坊達成共識，並可以選擇適合其需求的替代共識協議。 側鏈上使用的共識演算法的一些範例包括： - [權威證明](/developers/docs/consensus-mechanisms/poa/) -- [委託權益證明](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) +- [委任權益證明](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) - [拜占庭容錯](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained)。 跟以太坊一樣，側鏈也有驗證節點去驗證和處理交易、產生區塊並儲存區塊鏈狀態。 驗證者也負責維護整個網路的共識，並確保它不受惡意攻擊。 #### 區塊參數 {#block-parameters} -以太坊對[出塊時間](/developers/docs/blocks/#block-time)（即產生新區塊所需時間）和[區塊大小](/developers/docs/blocks/#block-size)（即以燃料為計量單位，每個區塊包含的資料量）設定了限制。 相反地，側鏈通常會採用不同的參數，例如更快的出塊時間和更高的燃料限制，以達到高吞吐量、快速交易和低費用。 +以太坊對 [區塊時間](/developers/docs/blocks/#block-time) (即產生新區塊所需的時間) 和 [區塊大小](/developers/docs/blocks/#block-size) (即每個區塊以 gas 計量的資料量) 設定了限制。 相反地，側鏈通常會採用不同的參數，例如更快的出塊時間和更高的燃料限制，以達到高吞吐量、快速交易和低費用。 雖然這樣做有一些好處，但對網路去中心化和安全性卻有重大影響。 高速的出塊時間和大的區塊大小這些區塊參數，增加了運行全節點的難度，讓一些「超級節點」負責保護區塊鏈的安全。 在這種情況下，驗證者串通或惡意接管鏈的可能性就會增加。 -若要在不損害去中心化的情況下擴大區塊鏈的規模，就必須讓人人都能運行節點，而不一定是擁有專門硬體的人。 這就是我們一直在努力確保每個人都能在以太坊網路上[運行全節點](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node)的原因。 +若要在不損害去中心化的情況下擴大區塊鏈的規模，就必須讓人人都能運行節點，而不一定是擁有專門硬體的人。 這就是為什麼我們正在努力確保每個人都可以在以太坊網路上 [執行一個完整節點](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node)。 -### 以太坊虛擬機 (EVM) 相容性 {#evm-compatibility} +### EVM 相容性 {#evm-compatibility} -一些側鏈與以太坊虛擬機相容，並且能夠執行為[以太坊虛擬機 (EVM)](/developers/docs/evm/) 開發的合約。 相容於以太坊虛擬機的側鏈支援以 [Solidity 編寫](/developers/docs/smart-contracts/languages/)的智慧型合約，也支援其他以太坊虛擬機智慧型合約語言，這意味著為以太坊主網編寫的智慧型合約也將在相容於以太坊虛擬機的側鏈上有效。 +有些側鏈與 EVM 相容，並且能夠執行為 [以太坊虛擬機 (EVM)](/developers/docs/evm/) 開發的合約。 與 EVM 相容的側鏈支援 [以 Solidity 編寫](/developers/docs/smart-contracts/languages/) 的智能合約，以及其他 EVM 智能合約語言，這意味著為以太坊主網編寫的智能合約也適用於與 EVM 相容的側鏈。 -這意味著若你想在側鏈上使用你的[去中心化應用程式](/developers/docs/dapps/)，只需將你的[智慧型合約](/developers/docs/smart-contracts/)部署到該側鏈即可。 側鏈的外觀、給人的感覺和行為與主鏈相似 — 你可以用 Solidity 編寫合約，並透過側鏈遠端程序呼叫與側鏈互動。 +這意味著若您想在側鏈上使用您的 [去中心化應用程式](/developers/docs/dapps/)，只需要將您的 [智能合約](/developers/docs/smart-contracts/) 部署到此側鏈即可。 側鏈的外觀、給人的感覺和行為與主鏈相似 — 你可以用 Solidity 編寫合約，並透過側鏈遠端程序呼叫與側鏈互動。 -由於側鏈和以太坊虛擬機相容，因而被視為對以太坊原生去中心化應用程式有效的[擴張解決方案](/developers/docs/scaling/)。 去中心化應用程式部署到側鏈後，使用者可以盡享更低的燃料費用和更快的交易速度，尤其是在主網擁塞的情況下。 +由於側鏈與 EVM 相容，因此它們被視為適用於以太坊原生去中心化應用程式的實用 [擴容解決方案](/developers/docs/scaling/)。 去中心化應用程式部署到側鏈後，使用者可以盡享更低的燃料費用和更快的交易速度，尤其是在主網擁塞的情況下。 不過，如前所述，使用側鏈涉及重大取捨。 每條側鏈負責其安全性，不會繼承以太坊的安全屬性。 這會增加惡意行為的可能性，影響你的使用者或讓他們的資金面臨風險。 ### 資產轉移 {#asset-movement} -爲了使一條獨立區塊鏈成爲以太坊主網的側鏈，區塊鏈需要支持在它與以太坊主網之間傳送資產。 這種與以太坊的互操作性是使用區塊鏈跨鏈橋實現的。 [跨鏈橋](/bridges/)使用部署在以太坊主網和側鏈上的智慧型合約控制兩者之間的資金橋接。 +爲了使一條獨立區塊鏈成爲以太坊主網的側鏈，區塊鏈需要支持在它與以太坊主網之間傳送資產。 這種與以太坊的互操作性是使用區塊鏈跨鏈橋實現的。 [跨鏈橋](/bridges/) 使用部署在以太坊主網和側鏈上的智能合約，來控制兩者之間的資金橋接。 -儘管跨鏈橋可以幫助使用者在以太坊和側鏈之間傳送資金，但實體資產不會在兩條鏈之間移動。 相反，通常采用與鑄造和銷毀相關的機制跨鏈傳送價值。 更多關於[跨鏈橋如何運作](/developers/docs/bridges/#how-do-bridges-work)的資訊。 +儘管跨鏈橋可以幫助使用者在以太坊和側鏈之間傳送資金，但實體資產不會在兩條鏈之間移動。 相反，通常采用與鑄造和銷毀相關的機制跨鏈傳送價值。 更多關於 [跨鏈橋的運作方式](/developers/docs/bridges/#how-do-bridges-work)。 -## 側鏈的優勢和劣勢 {#pros-and-cons-of-sidechains} +## 側鏈的優缺點 {#pros-and-cons-of-sidechains} | 優勢 | 劣勢 | | ------------------------------------------ | ------------------------------------ | @@ -62,12 +62,12 @@ sidebarDepth: 3 - [Polygon PoS](https://polygon.technology/solutions/polygon-pos) - [Skale](https://skale.network/) -- [Gnosis Chain（前身為 xDai）](https://www.gnosischain.com/) +- [Gnosis Chain (前身為 xDai)](https://www.gnosischain.com/) - [Loom Network](https://loomx.io/) - [Metis Andromeda](https://www.metis.io/) -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} -- [透過側鏈擴張以太坊去中心化應用程式](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _2018 年 2 月 8 日 - Georgios Konstantopoulos_ +- [透過側鏈擴容以太坊去中心化應用程式](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _2018 年 2 月 8 日 - Georgios Konstantopoulos_ -_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_ +_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容！_ diff --git a/public/content/translations/zh-tw/developers/docs/scaling/state-channels/index.md b/public/content/translations/zh-tw/developers/docs/scaling/state-channels/index.md new file mode 100644 index 00000000000..631b0eace70 --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/scaling/state-channels/index.md @@ -0,0 +1,261 @@ +--- +title: "狀態通道" +description: "介紹狀態通道和支付通道，作為以太坊社群目前使用的擴展解決方案。" +lang: zh-tw +sidebarDepth: 3 +--- + +狀態通道允許參與者安全地進行鏈下交易，同時將與以太坊主網的互動保持在最低水平。 通道對等方可進行任意數量的鏈下交易，同時只需提交兩個鏈上交易來開啟和關閉通道。 這允許極高的交易吞吐量並降低使用者的成本。 + +## 先決條件 {#prerequisites} + +你應該已經閱讀並理解我們的[以太坊擴張](/developers/docs/scaling/)和[二層網路](/layer-2/)頁面。 + +## 什麼是通道？ {#what-are-channels} + +以太坊等公共區塊鏈因其分散式架構，即鏈上交易必須由所有節點執行，而面臨可擴展性挑戰。 節點必須能夠使用普通硬體來處理區塊中的交易量，為了保持網路去中心化而限制了交易吞吐量。 區塊鏈通道透過讓使用者在鏈下互動，同時仍然依賴主鏈的安全性進行最終結算，解決了這個問題。 + +通道是簡單的點對點協定，它讓雙方可以在彼此之間進行多筆交易，然後只將最終結果發佈到區塊鏈。 通道使用密碼學證明產生的摘要資料確實是一組有效中間交易的結果。 [「多簽」](/developers/docs/smart-contracts/#multisig) 智能合約確保交易由正確的各方簽署。 + +透過通道，狀態變更由相關各方執行和驗證，最大限度地減少了以太坊執行層上的計算。 這減少了以太坊的擁堵並提高了使用者的交易處理速度。 + +每個通道都由運行在以太坊上的[多重簽名智能合約](/developers/docs/smart-contracts/#multisig)管理。 要開啟通道，參與者在鏈上部署通道合約並向其中存入資金。 雙方共同簽署狀態更新來初始化通道的狀態，之後他們可以快速及自由地進行鏈下交易。 + +若要關閉通道，參與者會在鏈上提交最後商定的通道狀態。 之後，智慧型合約會根據每位參與者在通道最終狀態的餘額來分配鎖定的資金。 + +對於一些預先定義的參與者希望以高頻率進行交易而不產生可見開銷的情況，點對點通道特別適用。 區塊鏈通道分為兩類：**支付通道**和**狀態通道**。 + +## 支付通道 {#payment-channels} + +將支付通道描述成由兩個使用者共同維護的「雙向帳本」最為恰當。 帳本的初始餘額是通道開放階段鎖定到鏈上合約的存款總和。 支付通道轉帳可以立刻執行，除了最初建立一次性鏈上通道以及通道的最終關閉外，其餘部分無需區塊鏈實際參與。 + +帳本餘額的更新（即支付通道的狀態）需要通道中所有方批准。 通道更新在所有通道參與者簽署后被視爲最終確定，這和以太坊上的交易非常相似。 + +支付通道是最早的擴容解決方案之一，用於最大限度減少因簡單使用者互動所產生的高成本鏈上活動（例如，ETH 傳送、原子交換、小額支付）。 通道參與者彼此之間可以進行不限數額的即時、無費用交易，只要他們傳送的净總和不超過存入的代幣。 + +## 狀態通道 {#state-channels} + +除了支援鏈下支付以外，支付通道尚未被證明可用於處理通用狀態轉換邏輯。 建立狀態通道是爲了解決該問題，並使通道可用於擴張通用計算。 + +狀態通道與支付通道仍有許多共同點。 例如，當使用者透過交換加密簽名的訊息（交易）進行互動時，其他通道參與者也必須簽署訊息。 如果提議的狀態更新沒有獲得所有參與者的簽名，則被認爲無效。 + +但是，除了保存使用者的餘額之外，通道還會追蹤合約存儲的目前狀態（即合約變數的值）。 + +這使得兩個使用者之間可以在鏈下執行智能合約。 在這種情況下，智慧型合約内部狀態的更新只需由建立通道的對等方進行批准。 + +儘管這解決了先前描述的可擴展性問題，但它會影響安全性。 在以太坊上，狀態轉換的有效性由網路的共識協定强制執行。 因此，不可能對智慧型合約的狀態提議無效的更新，或修改智慧型合約的執行。 + +狀態通道沒有同樣的安全保證。 在某種程度上，狀態通道是主網的縮小版。 由於執行規則的參與者有限，發生惡意行爲（例如，提議無效狀態更新）的可能性就會增加。 狀態通道的安全性來自基於[詐欺證明](/glossary/#fraud-proof)的爭議仲裁系統。 + +## 狀態通道如何運作 {#how-state-channels-work} + +狀態通道中的活動基本上都是一系列涉及使用者和區塊鏈系統的互動。 使用者大多數情況下在鏈下相互交流，只在開啟通道、關閉通道或解決參與者之間的潛在爭議時才與底層區塊鏈互動。 + +以下部分概述了狀態通道的基本工作流程： + +### 開啓通道 {#opening-the-channel} + +開啟通道需要參與者將資金存入主網上的智慧型合約。 存款還可以用作虛擬標簽，因此參與者可以自由交易，而無需立即結算付款。 只有當通道在鏈上最終確定時，各方才會相互結算並提取標簽的餘額。 + +該存款還可以作爲一種保證金，保證每個參與者誠實行事。 如果在爭議解決階段判定存款者有惡意行爲，合約將罰沒其存款。 + +通道對等方必須簽署一個他們一致同意的初始狀態。 初始狀態充當通道的創世塊，之後使用者可以開始交易。 + +### 使用通道 {#using-the-channel} + +在初始化通道的狀態后，對等方進行互動，他們簽署交易並互相發送交易進行批准。 參與者使用這些交易發起狀態更新，並簽署來自其他人的狀態更新。 每筆交易都包含以下内容： + +- 一個 **nonce**，充當交易的獨特 ID 並防止回放攻擊。 它還標識狀態更新發生的順序（這對於爭議解決很重要） + +- 通道的原有狀態 + +- 通道的新狀態 + +- 觸發狀態轉換的交易（例如，Alice 向 Bob 發送 5 枚以太幣） + +通道中的狀態更新不會像使用者在主網上互動時那樣廣播到鏈上，這與狀態通道最大限度減少鏈上足跡的目標相符。 只要參與者一致同意狀態更新，它們就與以太坊交易一樣被最終確定。 如果出現爭議，參與者只需要依賴主網的共識。 + +### 關閉通道 {#closing-the-channel} + +關閉狀態通道需要將通道的各方一致同意的最終狀態提交到鏈上智能合約。 狀態更新中引用的詳情包括每個參與者的移動次數和批准交易的清單。 + +在驗證狀態更新有效（即由各方簽署）之後，智慧型合約最終確定通道狀態並根據通道的結果分發鎖定的資金。 鏈下支付套用至以太坊狀態，每個參與者都會收到其剩餘的鎖定資金部分。 + +上述場景表示了成功用例下的情況。 有時，使用者可能無法達成一致並最終確定通道狀態（失敗用例）。 以下任何一種情況都可能導致失敗： + +- 參與者離綫且未能提議狀態轉換 + +- 參與者拒絕共同簽署有效的狀態更新 + +- 參與者試圖透過向鏈上合約提議舊狀態更新來最終確定通道 + +- 參與者提議無效的狀態轉換供其他人簽署 + +每當通道中的參與者之間無法達成共識時，最後的選擇都是依靠主網的共識來執行通道的最終有效狀態。 在這情況下，關閉狀態通道就需要在鏈上解決爭議。 + +### 解決爭議 {#settling-disputes} + +通常，通道中的各方事先同意關閉通道並共同簽署最新的狀態轉換，然後將其提交到智慧型合約。 一旦更新在鏈上獲得批准，鏈下智能合約的執行就會結束，參與者會帶著他們的錢退出通道。 + +然而，一方可以提交鏈上請求以結束智能合約的執行，並最終確定通道 - 而無需等待對方的批准。 如果出現上述任何破壞共識的情況，任何一方都可以觸發鏈上合約以關閉通道並分發資金。 這樣就實現了**去信任性**，確保誠實的參與者可以隨時退出他們的存款，不論另一方的行為如何。 + +要處理通道退出，使用者必須將應用程式的最後有效狀態更新提交給鏈上合約。 如果狀態更新得到證實（即帶有所有各方的簽名），那麼資金就會按照有利於他們的方式重新分發。 + +但是，執行單一使用者退出請求時會有延遲。 如果關閉通道的請求獲得一致批准，則立即執行鏈上退出交易。 + +由於存在詐欺行為的可能性，延遲會在單一使用者退出中發揮作用。 例如，通道參與者可能嘗試透過在鏈上提交較早的狀態更新來最終確定以太坊上的通道。 + +作爲一種對策，狀態通道讓誠實的使用者可以透過在鏈上提交最新的有效通道狀態，來挑戰無效的狀態更新。 狀態通道的設計讓一致同意的較新狀態更新優先於較早的狀態更新。 + +一旦一個對等方觸發了鏈上的爭議解決系統，另一方需要在一段限制時間（稱爲挑戰窗口）内做出響應。 這樣使用者就可以挑戰退出交易，尤其是在另一方套用過時更新的情況下。 + +無論是哪種情況，通道使用者總是擁有可靠的最終性保證：如果他們擁有的狀態轉換由所有成員簽署，並且為最近的更新，它就與常規鏈上交易具有相同的最終性。 他們仍必須在鏈上挑戰另一方，但唯一可能的結果是最終確定他們擁有的最後一個有效狀態。 + +### 狀態通道如何與以太坊互動？ {#how-do-state-channels-interact-with-ethereum} + +儘管狀態通道作爲鏈外協定存在，但其具有一個鏈上部分：開啟通道時部署在以太坊上的智慧型合約。 該合約控制存入通道的資產，驗證狀態更新，及仲裁參與者之間的爭議。 + +跟[二層網路](/layer-2/)擴張解決方案不同，狀態通道不會向主網發佈交易資料或狀態承諾。 但是，它們與主網的連接比[側鏈](/developers/docs/scaling/sidechains/)更緊密，這讓它們更安全。 + +狀態通道仰賴主要以太坊協定來實現以下功能： + +#### 1. 活躍性 {#liveness} + +開啟通道時部署的鏈上合約負責通道的功能。 如果合約在以太坊上運行，則該通道始終可供使用。 相反地，即使主網正常運作，側鏈也可能隨時失效，讓使用者的資金面臨風險。 + +#### 2. 安全性 {#security} + +某程度上，狀態通道依賴以太坊來提供安全性，並保護使用者不受惡意對等方的侵害。 如後面部分所討論的，通道使用詐欺證明機制，允許使用者挑戰使用無效或過時更新最終確定通道狀態的嘗試。 + +在此情況下，誠實參與者將通道的最新有效狀態作為詐欺證明，提供給鏈上合約進行驗證。 詐欺證明使相互不信任的各方能夠進行鏈外交易，而不會讓他們的資金在此過程中面臨風險。 + +#### 3 最終性 {#finality} + +由通道使用者集體簽署的狀態更新被認為與鏈上交易一樣的好。 不過，所有通道內的活動只有在以太坊上的通道關閉時，才能達到真正的最終性。 + +在樂觀情況下，雙方可以合作、簽署最終狀態更新並在鏈上提交以關閉通道，然後根據通道的最終狀態分發資金。 在悲觀情況下，有人試圖透過在鏈上發佈不正確的狀態更新來進行欺騙，他們的交易在挑戰窗口結束之前不會最終確定。 + +## 虛擬狀態通道 {#virtual-state-channels} + +狀態通道的簡單實作是，在兩個使用者希望於鏈外執行應用程式時部署新合約。 這不僅不可行，而且還否定了狀態通道的成本效益（鏈上交易成本會迅速增加）。 + +為了解決此問題，「虛擬通道」應運而生。 與需要鏈上交易才能開啟和終止的常規通道不同，虛擬通道可以在不與主鏈互動的情況下開啟、執行並最終確定。 甚至可以使用這種方法在鏈外解決爭端。 + +此系統依賴已在鏈上獲得資金的所謂「帳本通道」的存在。 雙方之間的虛擬通道可以建立在現有的帳本通道之上，並由帳本通道的所有者充當中間人。 + +每條虛擬通道的使用者透過新的合約執行個體交互，帳本通道能夠支援多個合約執行個體。 帳本通道的狀態還包含多個合約存儲狀態，允許在鏈外不同使用者之間平行執行應用程式。 + +就像常規通道一樣，使用者交換狀態更新以推進狀態機器。 除非出現爭議，只需在開啟或終止通道時聯繫中介機構。 + +### 虛擬支付通道 {#virtual-payment-channels} + +虛擬支付通道的運作原理與狀態通道相同：連線到同一網路的參與者可以傳送訊息，而無需在鏈上開啟新通道。 在虛擬支付通道中，價值傳送透過一個或多個中間人執行，並保證只有預期的接收者能夠接收傳送的資金。 + +## 狀態通道的應用 {#applications-of-state-channels} + +### 支付 {#payments} + +早期的區塊鏈通道是簡單的協定，允許兩個參與者在鏈外進行快速、低費用的傳送，而無需在主網上支付高額交易費。 如今，支付通道對於為以太幣和代幣的交換和存款而設計的應用程式仍然有用。 + +基於通道的支付具有以下優點： + +1. **吞吐量**：每條通道的鏈下交易數量與以太坊的吞吐量無關，而是受各種因素所影響，尤其是區塊大小和出塊時間。 透過在鏈下執行交易，區塊鏈通道可以達到更高吞吐量。 + +2. “”隱私“”：因爲通道存在於鏈下，參與者之間的互動細節不會記錄在以太坊的公共區塊鏈上。 通道使用者只需在向通道中存入資金和關閉通道或解決爭議時才作鏈上交互。 因此，通道適用於希望進行更多私密交易的個人。 + +3. **延遲**：如果雙方合作，通道參與者之間進行的鏈下交易可以即時結算，這減少了延遲。 相反，在主網上發送交易需要等待節點進行處理，產生一個包含該交易的新區塊，並達成共識。 使用者也可能需要等待更多的區塊確認，交易才能視為最終確定。 + +4. **成本**：當一組參與者需要長時間交換大量狀態更新時，狀態通道尤其有用。 唯一出現的費用是開啟和關閉狀態通道智慧型合約；在通道開啟和關閉之間的每個狀態變更的成本都比上一個更低，因爲結算成本是相應分配的。 + +在二層網路解決方案（例如[卷軸](/developers/docs/scaling/#rollups)）上實作狀態通道，可能會讓它們在支付方面更具吸引力。 儘管通道可以提供便宜的支付，但在通道開啟階段在主網上建立鏈上合約的成本可能會非常昂貴 - 尤其是當燃料費用飆升時。 基於以太坊的卷軸提供[較低的交易費](https://l2fees.info/) ，並且可以透過降低設定費用來減少通道參與者的開銷。 + +### 微交易 {#microtransactions} + +微交易是指低價值的付款（例如遠低於一美元），企業無法在不造成損失的情況下處理這些交易。 這些實體必須向支付服務提供者付款，但若客戶付款的利潤太低而無法獲利，支付服務提供者就無法處理付款。 + +支付通道透過減少與微交易相關的開銷來解決這個問題。 例如，網際網路提供者 (ISP) 可以為客戶開啟支付通道，允許他們在每次使用該服務時逐一進行小額支付。 + +除了開啟和關閉通道的成本外，參與者不會在微交易上產生進一步的成本（無燃料費用）。 這是一種雙贏局面，因爲客戶在爲服務支付多少費用方面擁有更多靈活性，並且企業也不會失去有利可圖的小額交易。 + +### 去中心化應用程式 {#decentralized-applications} + +跟支付通道一樣，狀態通道可以按狀態機器的最終狀態進行有條件支付。 狀態通道還可以支援任意狀態轉換邏輯，使其可用於執行鏈下通用應用程式。 + +狀態通道通常僅限於簡單的回合制應用程式，因爲這樣可以更簡單地管理提交到鏈上合約的資金。 此外，由於定期更新鏈下應用程式狀態的參與方數量有限，對不誠實行爲進行懲處相對簡單。 + +狀態通道應用程式的效率也取決於其設計。 例如，開發者或許可以在鏈上部署一次應用程式通道合約，並允許其他玩家重複使用該應用程式而無需到鏈上。 在這種情況下，初始應用程式通道充當支援多條虛擬通道的帳本通道，每條虛擬通道在鏈下運行應用程式智慧型合約的一個新執行個體。 + +狀態通道應用程式的一個潛在用例是簡單的雙人遊戲，根據遊戲結果分配資金。 這樣做的好處是，玩家不必互相信任（去信任），鏈上合約而不是玩家控制資金分配和爭議解決（去中心化）。 + +狀態通道應用程式的其他可能用例包括以太坊名稱服務的名稱所有權、非同質化代幣帳本等等。 + +### 原子傳送 {#atomic-transfers} + +早期的支付通道僅限於兩方之間的轉賬，限制了其實用性。 然而，虛擬通道的引入允許個人透過中間人（即多條對等通道）進行傳送，而無需在鏈上開啟新通道。 + +這種路由支付通常被描述爲「多跳傳送」，屬於原子傳送（即交易的所有部分只能全部成功或者全部失敗）。 原子傳送使用[哈希時間鎖定合約 (HTLC)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts)來確保只有在滿足特定條件時才釋放付款，這降低了另一交易方的風險。 + +## 使用狀態通道的缺點 {#drawbacks-of-state-channels} + +### 活躍性假設 {#liveness-assumptions} + +為確保效率，狀態通道對通道參與者響應爭議的能力設定了時限。 此規則假設對等方將始終在線，以監控通道活動並在必要時應對挑戰。 + +事實上，使用者可能會因為無法控制的原因而離線（例如網路連線不良、機械故障等）。 如果誠實使用者下線，惡意對等方就可以利用這種情況，將舊的中間狀態提供給裁決者合約並竊取提交的資金。 + +有些通道會使用「瞭望臺」，這類實體負責代表他人監控鏈上爭議事件並採取必要行動，例如提醒相關方。 然而，這可能會增加使用狀態通道的成本。 + +### 資料不可用性 {#data-unavailability} + +如前述，挑戰無效爭議需要提供狀態通道的最新有效狀態。 這是另一種基於假設的規則，即使用者可以存取通道的最新狀態。 + +雖然期望通道使用者儲存鏈下應用程式狀態的副本是合理的，但這些資料可能會因錯誤或機械故障而遺失。 如果使用者沒有備份資料，就只能希望另一方不要使用其擁有的舊狀態轉換，最終確定無效的退出請求。 + +以太坊使用者不必處理這個問題，因為網路會強制執行資料可用性規則。 交易資料會由所有節點儲存和傳播，並在必要時供使用者下載。 + +### 流動性問題 {#liquidity-issues} + +要建立區塊鏈通道，參與者需要在通道的整個生命週期將資金鎖定在鏈上智能合約中。 這降低了通道使用者的流動性，也限制通道只能由那些有財力將資金一直鎖定在主網上的人使用。 + +然而，鏈下服務提供者 (OSP) 營運的帳本通道可以減少使用者的流動性問題。 連線到帳本通道的兩個對等方可以建立一條虛擬通道，他們可以隨時在鏈下完全開啟和最終確定該通道。 + +鏈下服務提供者還可以開啟包含多個對等方的通道，讓通道可用於路由支付。 當然，使用者必須向鏈外服務提供者支付服務費用，這對某些人來說可能不可取。 + +### 悲傷攻擊 {#griefing-attacks} + +悲傷攻擊是基於詐欺證明的系統的常見特徵。 悲傷攻擊不會讓攻擊者直接獲益，但會讓受害者悲傷（即傷害），因而得名。 + +詐欺證明容易受到悲傷攻擊，因為即使是無效的爭議，誠實的一方必須對每一爭議作出回應，否則會面臨失去資金的風險。 惡意參與者可以決定在鏈上重複發布過時的狀態轉換，迫使誠實方以有效狀態回應。 這類鏈上交易的成本會迅速增加，導致誠實方在過程中受損。 + +### 預定義的參與者集合 {#predefined-participant-sets} + +根據設計，組成狀態通道的參與者數量在通道整個生命週期中固定不變。 這是因為更新參與者集會使通道的運作複雜化，尤其是在向通道存入資金或解決爭議時。 新增或移除參與者還需要進行額外的鏈上活動，這會增加使用者的開銷。 + +雖然這讓狀態通道更容易推斷，但它將通道設計的實用性局限於應用程式開發者。 這在一定程度上解釋了為何狀態通道已被其他擴張解決方案，例如卷軸所取代。 + +### 平行交易處理 {#parallel-transaction-processing} + +狀態通道中的參與者輪流發送狀態更新，這就是為什麼狀態通道最適合「回合制應用程式」（例如兩人棋類遊戲）的原因。 這樣就無需處理同時出現的狀態更新，並減少了鏈上合約為懲罰提出過時更新的發布者而必須完成的工作。 然而，這種設計的副作用是交易相互依賴，增加了延遲並減弱了整體的使用者體驗。 + +一些狀態通道透過採用「全雙工」設計來解決這個問題，該設計將鏈下狀態分成兩個單向「單工」狀態，允許並發狀態更新。 這種設計提高了鏈下吞吐量並減少了交易延遲。 + +## 使用狀態通道 {#use-state-channels} + +有多項專案提供狀態通道實作，歡迎整合到你的去中心化應用程式： + +- [Connext](https://connext.network/) +- [Kchannels](https://www.kchannels.io/) +- [Perun](https://perun.network/) +- [Raiden](https://raiden.network/) +- [Statechannels.org](https://statechannels.org/) + +## 延伸閱讀 {#further-reading} + +**狀態通道** + +- [理解以太坊的 Layer 2 擴容解決方案：狀態通道、Plasma 和 Truebit](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark，2018 年 2 月 12 日_ +- [狀態通道 - 釋義](https://www.jeffcoleman.ca/state-channels/) _2015 年 11 月 6 日 - Jeff Coleman_ +- [狀態通道基本概念](https://education.district0x.io/general-topics/understanding-ethereum/basics-state-channels/) _District0x_ +- [區塊鏈狀態通道:前沿技術概覽](https://ieeexplore.ieee.org/document/9627997) + +_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容！_ diff --git a/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md b/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md index 5fedd7d604c..f1982553064 100644 --- a/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md +++ b/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md @@ -1,45 +1,45 @@ --- title: Validium -description: 介紹目前作為擴張解決方案供以太坊社群使用的 Validium。 +description: "介紹目前作為擴張解決方案供以太坊社群使用的 Validium。" lang: zh-tw sidebarDepth: 3 --- -Validium 是一種[擴張解決方案](/developers/docs/scaling/)，使用如[零知識卷軸](/developers/docs/scaling/zk-rollups/)之類的有效性證明來強制執行交易的完整性，但它不在以太坊主網上儲存交易資料。 雖然鏈外資料可用性會帶來取捨，但卻能大幅提升可擴展性（Validium [每秒](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)可處理 [~9,000 個交易，甚至更多](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)）。 +Validium 是一種[擴張解決方案](/developers/docs/scaling/)，它採用類似 [ZK-rollups](/developers/docs/scaling/zk-rollups/) 的有效性證明來強制執行交易完整性，但不會將交易資料儲存在以太坊主網上。 雖然鏈外資料可用性會帶來一些權衡，但能大幅提升可擴展性 (validium 每秒可處理[約 9,000 筆或更多的交易](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263))。 -## 前置要求 {#prerequisites} +## 先決條件 {#prerequisites} -你應該已經在我們的頁面上閲讀並理解有關[以太坊擴張](/developers/docs/scaling/)和[二層網路](/layer-2)的内容。 +你應該已經閱讀並理解我們關於[以太坊擴張](/developers/docs/scaling/)和[第 2 層](/layer-2)的頁面。 ## 什麼是 Validium？ {#what-is-validium} -Validium 是使用鏈外資料可用性和計算的擴張解決方案，旨在透過在以太坊主網外處理交易來提高吞吐量。 與零知識卷軸 (ZK-rollup) 一樣，Validium 發佈[零知識證明](/glossary/#zk-proof)以在以太坊上驗證鏈外交易。 這能夠防止無效的狀態轉換並增强 Validium 鏈的安全保證。 +Validium 是使用鏈下資料可用性和計算的擴張解決方案，旨在透過在以太坊主網外處理交易來提高吞吐量。 如同零知識卷軸 (ZK-rollups)，validium 會發布[零知識證明](/glossary/#zk-proof) 來驗證以太坊上的鏈外交易。 這能夠防止無效的狀態轉換並增强 Validium 鏈的安全保證。 -這些「有效性證明」可以是 ZK-SNARK（零知識簡潔非互動式知識論證）或 ZK-STARK（零知識可擴展透明知識論證）兩種形式。 更多有關[零知識證明](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)的資訊。 +這些「有效性證明」可以是 ZK-SNARK（零知識簡潔非互動式知識論證）或 ZK-STARK（零知識可擴展透明知識論證）兩種形式。 更多關於[零知識證明](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)的資訊。 -屬於 Validium 使用者的資金由以太坊上的智慧型合約控制。 Validium 與零知識卷軸很像，能夠提供幾乎即時的提款；在主網上驗證提款請求的有效性證明后，使用者可以透過提供[默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)來提取資金。 默克爾證明驗證使用者的提款交易是否包含在經過驗證的交易批次中，這讓鏈上合約可以處理提款。 +屬於 Validium 使用者的資金由以太坊上的智慧型合約控制。 Validium 和 ZK-rollups 非常相似，可提供近乎即時的提款；只要提款請求的有效性證明在主網上通過驗證，使用者就能提供[默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)來提領資金。 默克爾證明驗證使用者的提款交易是否包含在經過驗證的交易批次中，這讓鏈上合約可以處理提款。 -然而，Validium 使用者的資金可能會被凍結，並受到提款限制。 如果 Validium 鏈上資料可用性管理器拒絕向使用者提供鏈外狀態資料，就會發生這種情況。 如果無法存取交易資料，使用者將無法計算證明資金所有權和執行提款所需的默克爾證明。 +然而，Validium 使用者的資金可能會被凍結，並受到提款限制。 如果 Validium 鏈上資料可用性管理器拒絕向使用者提供鏈下狀態資料，就會發生這種情況。 如果無法存取交易資料，使用者將無法計算證明資金所有權和執行提款所需的默克爾證明。 這是 Validium 和零知識卷軸之間的主要區別，即它們在資料可用性範圍上的位置不同。 兩種解決方案處理資料存儲的方式不同，這會影響安全性和去信任。 ## Validium 如何與以太坊互動？ {#how-do-validiums-interact-with-ethereum} -Validium 是建置在現有以太坊鏈上的擴張協定。 儘管它在鏈外執行交易，但 Validium 鏈由部署在主網上的一系列智慧型合約管理，包括： +Validium 是建置在現有以太坊鏈上的擴張協定。 儘管它在鏈下執行交易，但 Validium 鏈由部署在主網上的一系列智能合約管理，包括： -1. **驗證者合約**：驗證者合約驗證 Validium 營運者在進行狀態更新時所提交證明的有效性。 該合約需要證明鏈外交易正確性的有效性證明，和驗證鏈外交易資料存在的資料可用性證明。 +1. **驗證者合約**：驗證者合約會驗證 validium 營運商在進行狀態更新時，所提交證明的有效性。 該合約需要證明鏈下交易正確性的有效性證明，和驗證鏈下交易資料存在的資料可用性證明。 -2. **主合約**：主合約儲存區塊生產者提交的狀態承諾（默克爾根），並在有效性證明完成鏈上驗證后更新 Validium 的狀態。 該合約還處理 Validium 鏈上的存款和提款。 +2. **主合約**：主合約儲存區塊生產者提交的狀態承諾 (默克爾根)，並在有效性證明完成鏈上驗證後更新 validium 的狀態。 該合約還處理 Validium 鏈上的存款和提款。 Validium 還依賴於以太坊主鏈來獲得： ### 結算 {#settlement} -在 Validium 上執行的交易無法完全確認，直至父母鏈驗證其有效性。 所有在 Validium 上進行的業務最終都必須在主網上結算。 以太坊區塊鏈還為 Validium 使用者提供了「結算保證」，這意味鏈外交易一旦提交到鏈上，就無法逆轉或改變。 +在 Validium 上執行的交易無法完全確認，直至父母鏈驗證其有效性。 所有在 Validium 上進行的業務最終都必須在主網上結算。 以太坊區塊鏈還為 Validium 使用者提供了「結算保證」，這意味鏈下交易一旦提交到鏈上，就無法逆轉或改變。 ### 安全性 {#security} -充當結算層的以太坊也保證 Validium 上狀態轉換的有效性。 在 Validium 鏈上執行的鏈外交易透過以太坊基礎層上的智慧型合約進行驗證。 +充當結算層的以太坊也保證 Validium 上狀態轉換的有效性。 在 Validium 鏈上執行的鏈下交易透過以太坊基礎層上的智能合約進行驗證。 如果鏈上驗證者合約認爲證明無效，交易就會被拒絕。 這意味著營運者在更新 Validium 的狀態之前，必須滿足以太坊協定強制執行的有效性條件。 @@ -47,7 +47,7 @@ Validium 還依賴於以太坊主鏈來獲得： ### 交易 {#transactions} -使用者向營運者提交交易 - 營運者是負責在 Validium 鏈上執行交易的節點。 一些 Validium 可能使用單個營運者來執行鏈，或依賴[權益證明 (PoS)](/developers/docs/consensus-mechanisms/pos/) 機制來輪換營運者。 +使用者向營運者提交交易 - 營運者是負責在 Validium 鏈上執行交易的節點。 有些 validium 可能會使用單一營運商來執行鏈，或依賴[權益證明 (PoS)](/developers/docs/consensus-mechanisms/pos/) 機制來輪換營運商。 營運者將交易彙總到一個批次中，並將其發送到證明電路進行證明。 證明電路接受交易批次（以及其他有關資料）作爲輸入，並輸出驗證作業正確執行的有效性證明。 @@ -59,7 +59,7 @@ Validium 的狀態被雜處理湊為默克爾樹，其根儲存在以太坊的 ### 存款和提款 {#deposits-and-withdrawals} -使用者透過在鏈上合約中存入以太幣（或任何與 ERC 兼容的代幣），將資金從以太坊轉移到 Validium。 該合約將存款事件轉發到鏈外 Validium，並向使用者在 Validium 上的地址存入與其存款相同的金額。 營運者還會將該存款交易包含在新批次中。 +使用者透過在鏈上合約中存入以太幣（或任何與 ERC 兼容的代幣），將資金從以太坊轉移到 Validium。 該合約將存款事件轉發到鏈下 Validium，並向使用者在 Validium 上的地址存入與其存款相同的金額。 營運者還會將該存款交易包含在新批次中。 爲了將資金轉移回主網，Validium 使用者需要發起提款交易並提交到營運者，營運者將驗證提款請求並將其包含在批次中。 使用者在 Validium 鏈上的資產也會被銷毀，才能退出系統。 一旦與該批次相關的有效性證明得到驗證，使用者就可以呼叫主合約來提取剩餘的初始存款。 @@ -69,61 +69,61 @@ Validium 的狀態被雜處理湊為默克爾樹，其根儲存在以太坊的 在執行一批交易后，營運者向驗證者合約提交相關的有效性證明，並向主合約提議新的狀態根。 如果證明有效，主合約就會更新 Validium 的狀態並最終確定批次中交易的結果。 -與零知識卷軸不同，Validium 上的區塊生產者不需要發佈交易批次的交易資料（僅發佈區塊頭）。 這使 Validium 成爲一個純鏈外擴張協定，而不是在以太坊主鏈上發佈狀態資料（如 `calldata`）的「混合」擴張協定（即[二層網路](/layer-2/)）。 +與零知識卷軸不同，Validium 上的區塊生產者不需要發佈交易批次的交易資料（僅發佈區塊頭）。 這使得 validium 成為一個純粹的鏈外擴張協定，與「混合型」擴張協定 (即[第 2 層](/layer-2/)) 相對，後者會使用 blob 資料、`calldata` 或兩者的組合將狀態資料發布到以太坊主鏈上。 ### 資料可用性 {#data-availability} -如前所述，Validium 利用一個鏈外資料可用性模型，營運者會將所有交易資料儲存在其中，而不是以太坊主網。 Validium 的鏈上資料足跡較低，這提升了可擴展性（吞吐量不受以太坊的資料處理能力限制），並降低了使用者費用（發佈 `calldata` 的成本降低）。 +如前所述，Validium 利用一個鏈下資料可用性模型，營運者會將所有交易資料儲存在其中，而不是以太坊主網。 Validium 的鏈上資料足跡較低，這提升了可擴展性（吞吐量不受以太坊的資料處理能力限制），並降低了使用者費用（在鏈上發佈資料的成本降低）。 -然而，鏈外資料可用性導致了一個問題：建立或驗證默克爾證明所需的資料可能不可用。 這意味著，如果營運者采取惡意行爲，使用者就可能無法從鏈上合約中提取資金。 +然而，鏈下資料可用性導致了一個問題：建立或驗證默克爾證明所需的資料可能不可用。 這意味著，如果營運者采取惡意行爲，使用者就可能無法從鏈上合約中提取資金。 -各種 Validium 解決方案試圖透過將狀態資料的儲存去中心化來解決此問題。 這涉及迫使區塊生產者將底層資料發送至「資料可用性管理者」，由他們負責儲存鏈外資料並在使用者請求時提供給使用者。 +各種 Validium 解決方案試圖透過將狀態資料的儲存去中心化來解決此問題。 這涉及迫使區塊生產者將底層資料發送至「資料可用性管理者」，由他們負責儲存鏈下資料並在使用者請求時提供給使用者。 -Validium 中的資料可用性管理者透過簽署每個 Validium 批次，來證明鏈外交易資料的可用性。 這些簽名構成了一種「可用性證明」，鏈上驗證者合約會在批准狀態更新之前進行檢查。 +Validium 中的資料可用性管理者透過簽署每個 Validium 批次，來證明鏈下交易資料的可用性。 這些簽名構成了一種「可用性證明」，鏈上驗證者合約會在批准狀態更新之前進行檢查。 Validium 的資料可用性管理方法不同。 一些依賴可信方儲存狀態資料，另一些則使用隨機指定的驗證者完成此工作。 #### 資料可用性委員會 (DAC) {#data-availability-committee} -爲了保證鏈外資料的可用性，一些 Validium 解決方案指定了一組可信實體（統稱爲資料可用性委員會 (DAC)）來儲存狀態複本並提供資料可用性證明。 由於成員較少，資料可用性委員會更容易實作，並且需要的協調更少。 +爲了保證鏈下資料的可用性，一些 Validium 解決方案指定了一組可信實體（統稱爲資料可用性委員會 (DAC)）來儲存狀態複本並提供資料可用性證明。 由於成員較少，資料可用性委員會更容易實作，並且需要的協調更少。 -然而，使用者必須信任資料可用性委員會，以便在需要時獲得資料（例如，用於產生默克爾證明）。 資料可用性委員會的成員有可能[被惡意行爲者損害](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view)，然後後者會扣留鏈外資料。 +然而，使用者必須信任資料可用性委員會，以便在需要時獲得資料（例如，用於產生默克爾證明）。 資料可用性委員會的成員有可能[遭到惡意行為者入侵](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view)，惡意行為者接著就可能扣留鏈外資料。 -[更多有關 Validium 中資料可用性委員會的資訊](https://medium.com/starkware/data-availability-e5564c416424)。 +[更多關於 validium 的資料可用性委員會](https://medium.com/starkware/data-availability-e5564c416424)。 -#### 有保證金的資料可用性 {#bonded-data-availability} +#### 質押資料可用性 {#bonded-data-availability} 其他 Validium 需要負責儲存離綫資料的參與者，在承擔其角色之前在智慧型合約中質押（即鎖定）代幣。 該質押充當一種「保證金」，保證資料可用性管理者之間誠實行事並減少信任假設。 如果這些參與者未能證明資料可用性，該保證金就會被罰沒。 -在有保證金的資料可用性方案中，任何人在提供需要的質押后，都可以被指定保存鏈外資料。 這擴展了合格資料可用性管理者池，減少了影響資料可用性委員會 (DAC) 的中心化。 更重要的是，這種方法依賴於加密經濟激勵措施來防止惡意活動，這相比指定可信方在 Validium 中保護離綫資料要安全很多。 +在有保證金的資料可用性方案中，任何人在提供需要的質押后，都可以被指定保存鏈下資料。 這擴展了合格資料可用性管理者池，減少了影響資料可用性委員會 (DAC) 的中心化。 更重要的是，這種方法依賴於加密經濟激勵措施來防止惡意活動，這相比指定可信方在 Validium 中保護離綫資料要安全很多。 -[更多有關 Validium 中有保證金的資料可用性的資訊](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)。 +[更多關於 validium 的質押資料可用性](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)。 -## Volition 和 Validium {#volitions-and-validium} +## Volition 和 validium {#volitions-and-validium} Validium 提供許多好處，但也會有取捨（最明顯的就是資料可用性）。 但是，與許多擴張解決方案一樣，Validium 適合特定的用例 - 這就是為何建立 Volition 的原因。 -Volition 結合了零知識卷軸和 Validium 鏈，它允許使用者在兩種擴張解決方案之間切換。 使用 Volition，使用者能夠利用 Validium 的鏈外資料可用性進行某些交易，同時可以在需要時自由地切換到鏈上資料可用性解決方案（零知識卷軸）。 這本質上讓使用者能夠根據其獨特情況自由地進行權衡。 +Volition 結合了零知識卷軸和 Validium 鏈，它允許使用者在兩種擴張解決方案之間切換。 使用 Volition，使用者能夠利用 Validium 的鏈下資料可用性進行某些交易，同時可以在需要時自由地切換到鏈上資料可用性解決方案（零知識卷軸）。 這本質上讓使用者能夠根據其獨特情況自由地進行權衡。 去中心化交易所 (DEX) 可能偏好使用 Validium 的可擴展和隱私基礎設施進行高價值交易。 它還可以為需要零知識卷軸的更高安全性保證和去信任的使用者使用零知識卷軸。 -## Validium 和以太坊虛擬機的相容性 {#validiums-and-evm-compatibility} +## Validium 與 EVM 相容性 {#validiums-and-evm-compatibility} -與零知識卷軸一樣，Validium 最適合簡單的應用程式，例如代幣交換和支付。 由於在零知識證明電路中證明[以太坊虛擬機](/developers/docs/evm/)指示的開銷很大，因此很難實作在 Validium 之間為通用計算和智慧型合約執行提供支援。 +與零知識卷軸一樣，Validium 最適合簡單的應用程式，例如代幣交換和支付。 有鑑於在零知識證明電路中，證明 [EVM](/developers/docs/evm/) 指令的成本相當高，因此要在 validium 之間支援一般運算和智能合約的執行，是很難實作的。 一些 Validium 專案嘗試透過編譯與以太坊虛擬機兼容的語言（例如 Solidity、Viper），來建立為高效證明而最佳化的自訂位元組碼，從而回避這個問題。 這種方法的一個缺點是，零知識證明友好的新虛擬機可能不支援重要的以太坊虛擬機作業碼，並且開發者必須直接使用高階語言進行編寫才能獲得最佳體驗。 這導致了更多問題：它迫使開發者使用全新的開發堆棧構建去中心化應用程式，並破壞了與目前以太坊基礎設施的相容性。 -然而，一些團隊正在嘗試針對零知識證明電路最佳化現有的以太坊虛擬機作業碼。 這包括對零知識以太坊虛擬機 (zkEVM) 的開發，這是一種與以太坊虛擬機兼容的虛擬機，可以生成驗證程式是否正確執行的證明。 使用零知識以太坊虛擬機，Validium 鏈可以在鏈外執行智慧型合約並提交有效性證明，以在以太坊上驗證鏈外計算（無需重新執行合約）。 +然而，一些團隊正在嘗試針對零知識證明電路最佳化現有的以太坊虛擬機作業碼。 這包括對零知識以太坊虛擬機 (zkEVM) 的開發，這是一種與以太坊虛擬機兼容的虛擬機，可以生成驗證程式是否正確執行的證明。 使用零知識以太坊虛擬機，Validium 鏈可以在鏈下執行智慧型合約並提交有效性證明，以在以太坊上驗證鏈下計算（無需重新執行合約）。 -[更多有關零知識以太坊虛擬機的資訊](https://www.alchemy.com/overviews/zkevm)。 +[更多關於 zkEVM 的資訊](https://www.alchemy.com/overviews/zkevm)。 ## Validium 如何擴張以太坊？ {#scaling-ethereum-with-validiums} -### 1. 鏈外資料存儲 {#off-chain-data-storage} +### 1. 鏈外資料儲存 {#offchain-data-storage} -二層網路擴張項目，例如樂觀卷軸和零知識卷軸，透過將部分交易資料發佈到一層網路，犧牲了純鏈外擴容協定（如 [Plasma](/developers/docs/scaling/plasma/)）的無限可擴展性來換取安全性。 然而，這意味著卷軸的可擴展性屬性受到以太坊主網上資料帶寬的限制（因此提出[資料分片](/roadmap/danksharding/)以提高以太坊的資料存儲容量）。 +第 2 層擴張專案 (例如樂觀卷軸和 ZK-rollups) 會在第 1 層上發布一些交易資料來換取安全性，但代價是犧牲純鏈外擴張協定 (例如 [Plasma](/developers/docs/scaling/plasma/)) 的無限可擴展性。 但這意味著 rollup 的可擴展性會受以太坊主網的資料頻寬所限制 (為此，[資料分片](/roadmap/danksharding/) 提案旨在提升以太坊的資料儲存容量)。 -Validium 透過將所有交易資料保存在鏈外，並在轉送狀態更新到以太坊主鏈時僅發佈狀態承諾（及有效性證明），實現了可擴展性。 然而，有效性證明的存在為 Validium 提供了比其他純鏈外擴張解決方案（包括 Plasma 和[側鏈](/developers/docs/scaling/sidechains/)）更高的安全保證。 透過減少以太坊在驗證鏈外交易之前必須處理的資料量，Validium 設計極大地提升了主網上的吞吐量。 +Validium 透過將所有交易資料保存在鏈下，並在轉送狀態更新到以太坊主鏈時僅發佈狀態承諾（及有效性證明），實現了可擴展性。 然而，有效性證明的存在，讓 validium 比其他純鏈外擴張解決方案 (包括 Plasma 和[側鏈](/developers/docs/scaling/sidechains/)) 具有更高的安全保證。 透過減少以太坊在驗證鏈下交易之前必須處理的資料量，Validium 設計極大地提升了主網上的吞吐量。 ### 2. 遞迴證明 {#recursive-proofs} @@ -131,35 +131,36 @@ Validium 透過將所有交易資料保存在鏈外，並在轉送狀態更新 通常，Validium 營運者提交到以太坊來驗證的每個有效性證明都會驗證單個區塊的完整性。 而一個遞迴證明可用於同時確認幾個 Validium 區塊的有效性 - 這是有可能的，因爲證明電路能夠以遞迴方式將幾個區塊證明彙總為一個最終證明。 如果鏈上驗證者合約接受遞迴證明，則所有底層區塊都會立即被最終確定。 -## Validium 的優勢和劣勢 {#pros-and-cons-of-validium} +## Validium 的優缺點 {#pros-and-cons-of-validium} | 優勢 | 劣勢 | | ------------------------------------ | ------------------------------------------------------- | -| 有效性證明强制驗證鏈外交易的完整性，並防止營運者最終確定無效的狀態更新。 | 生成有效性證明需要使用特定硬體，這會導致中心化風險。 | +| 有效性證明强制驗證鏈下交易的完整性，並防止營運者最終確定無效的狀態更新。 | 生成有效性證明需要使用特定硬體，這會導致中心化風險。 | | 提高使用者的資本效率（將資金提取回以太坊時不會出現延遲） | 對通用計算/智慧型合約的支持有限；開發需要使用專業化語言。 | | 對高價值應用程式中的詐欺證明型系統所面臨的某些經濟攻擊有高抵抗性。 | 生成零知識證明需要强大的算力；對於低吞吐量的應用程式不具有成本效益。 | | 透過不將回呼資料發佈到以太坊主網來降低使用者的燃料費用。 | 較慢的主觀最終性時間（生成零知識證明需要 10 - 30 分鐘），但完全最終性會快一些，因爲沒有爭議時間延遲。 | -| 這適用於特定用例，例如優先考慮交易隱私和可擴展性的交易或區塊鏈游戲。 | 可能會阻止使用者提取資金，因爲生成所有權的默克爾證明需要鏈外資料始終可用。 | -| 鏈外資料可用性提升了吞吐量並增加了可擴展性。 | 安全模型依賴於信任假設和加密經濟激勵措施，與完全依賴加密安全機制的零知識卷軸不同。 | +| 這適用於特定用例，例如優先考慮交易隱私和可擴展性的交易或區塊鏈游戲。 | 可能會阻止使用者提取資金，因爲生成所有權的默克爾證明需要鏈下資料始終可用。 | +| 鏈下資料可用性提升了吞吐量並增加了可擴展性。 | 安全模型依賴於信任假設和加密經濟激勵措施，與完全依賴加密安全機制的零知識卷軸不同。 | ### 使用 Validium/Volition {#use-validium-and-volitions} 有多項專案提供 Validium 和 Volition 實作，歡迎整合到你的去中心化應用程式： -**StarkWare StarkEx** - _StarkEx 是基於有效性證明的以太坊二層網路 (L2) 可擴展性解決方案。 它能夠在零知識卷軸或 Validium 資料可用性模式下運作。_ +**StarkWare StarkEx** - _StarkEx 是一種以太坊第 2 層 (L2) 擴張解決方案，以有效性證明為基礎。 它可以在 ZK-Rollup 或 Validium 資料可用性模式下運作。_ - [文件](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) - [網站](https://starkware.co/starkex/) -**Matter Labs zkPorter**- _zkPorter 是一個二層網路擴張協定，它使用一種結合了零知識卷軸與分片理念的混合方法來處理資料可用性。 它可支援任意數量的分片，每個分片都有自己的資料可用性原則。_ +**Matter Labs zkPorter**- _zkPorter 是一種第 2 層擴張協定，它採用混合方法來處理資料可用性，結合了 zkRollup 和分片的想法。 它可支援任意數量的分片，每個分片都有自己的資料可用性策略。_ - [部落格](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) - [文件](https://docs.zksync.io/zksync-protocol/rollup/data-availability) - [網站](https://zksync.io/) -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} -- [Validium 及二層網路二合一 — 第 99 期](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) -- [零知識卷軸與 Validium 的比較](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) -- [Volition 和新興資料可用性範圍](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) -- [卷軸、Validium 和 Volition：瞭解最熱門的以太坊擴張解決方案](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [Validium 和 Layer 2 的 2x2 比較 — 第 99 期](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) +- [ZK-rollup 與 Validium 的比較](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) +- [Volition 和新興的資料可用性光譜](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) +- [Rollup、Validium 和 Volition：了解最熱門的以太坊擴張解決方案](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [以太坊卷軸實用指南](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) diff --git a/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md index bec5f900cd9..03d9cf14737 100644 --- a/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md @@ -1,42 +1,42 @@ --- -title: 零知識證明卷軸 -description: 零知識證明卷軸介紹 — 一個以太坊社群所使用的擴張解決方案。 +title: "零知識證明卷軸" +description: "零知識證明卷軸介紹 — 一個以太坊社群所使用的擴張解決方案。" lang: zh-tw --- -零知識證明卷軸 (ZK-rollup) 是二層網路的[擴張解決方案](/developers/docs/scaling/)，透過將計算和狀態儲存遷移至鏈外來提高以太坊主網上的吞吐量。 零知識證明卷軸可以一次批量處理數千個交易，然後僅將一些最低限度的摘要資料發佈到主網。 此摘要資料定義了以太坊狀態應進行的變更以及一些確保這些更變正確的密碼學證明。 +零知識卷軸 (ZK-rollups) 是第 2 層[擴張解決方案](/developers/docs/scaling/)，透過將運算和狀態儲存移至鏈下，來提高以太坊主網的吞吐量。 零知識證明卷軸可以一次批量處理數千個交易，然後僅將一些最低限度的摘要資料發佈到主網。 此摘要資料定義了以太坊狀態應進行的變更以及一些確保這些更變正確的密碼學證明。 -## 前置要求 {#prerequisites} +## 先決條件 {#prerequisites} -你應該已經在我們的頁面上閲讀並理解有關[以太坊擴張](/developers/docs/scaling/)和[二層網路](/layer-2)的内容。 +你應該已經閱讀並理解我們關於[以太坊擴張](/developers/docs/scaling/)和[第 2 層](/layer-2)的頁面。 ## 什麼是零知識證明卷軸？ {#what-are-zk-rollups} -**零知識證明卷軸 (ZK-rollup)** 將交易批量打包（或「捲起來」），然後在鏈外執行。 鏈外計算減少了必須發佈到區塊鏈的資料量。 零知識證明卷軸提交代表批次中所有交易所需變更的匯總，而不是單獨發送每一筆交易。 它們還產生[有效性證明](/glossary/#validity-proof)來證明其變更的正確性。 +**零知識卷軸 (ZK-rollups)** 將交易批量打包 (或「卷起」)，然後在鏈下執行。 鏈下計算減少了必須發佈到區塊鏈的資料量。 零知識證明卷軸提交代表批次中所有交易所需變更的匯總，而不是單獨發送每一筆交易。 它們還會產生[有效性證明](/glossary/#validity-proof)來證明其變更的正確性。 -零知識證明卷軸的狀態由部署在以太坊網路上的智慧型合約維護。 爲了更新該狀態，零知識證明卷軸必須提交有效性證明來進行驗證。 如上所述，有效性證明是一種加密保證，證明卷軸提交的狀態變更確實是執行給定批量交易的結果。 這意味著零知識證明卷軸只需要提供有效性證明就可以在以太坊上最終確定交易，而無需像[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)一樣將所有交易資料發佈到鏈上。 +零知識證明卷軸的狀態由部署在以太坊網路上的智慧型合約維護。 爲了更新該狀態，零知識證明卷軸必須提交有效性證明來進行驗證。 如上所述，有效性證明是一種加密保證，證明卷軸提交的狀態變更確實是執行給定批量交易的結果。 這意味著 ZK-rollups 只需要提供有效性證明，就可以在以太坊上完成交易，而無需像[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)那樣，將所有交易資料都發佈到鏈上。 -將資金從零知識證明卷軸轉移到以太坊沒有延遲，因爲一旦零知識證明卷軸合約驗證有效性證明，退出交易就會被執行。 相反，從樂觀卷軸提取資金則可能會有延遲，以便任何人都可以使用[詐欺證明](/glossary/#fraud-proof)來挑戰退出交易。 +將資金從零知識證明卷軸轉移到以太坊沒有延遲，因爲一旦零知識證明卷軸合約驗證有效性證明，退出交易就會被執行。 相反地，從樂觀卷軸提款會有一段延遲，以便任何人都能用[詐欺證明](/glossary/#fraud-proof)來挑戰這筆提款交易。 -零知識證明卷軸將交易作爲 `calldata` 寫入以太坊。 對智慧型合約函式的外部調用中包含的資料就存儲在 `calldata` 中。 `calldata` 中的資訊被發佈到區塊鏈上，讓任何人都能夠獨立重建卷軸的狀態。 零知識證明卷軸使用壓縮技術來減少交易資料 — 例如，由索引而非地址來代表帳戶，這將節省 28 個位元組的資料。 鏈上資料發佈是卷軸的一大成本，因此資料壓縮能夠降低使用者的費用。 +ZK-rollups 將交易以 `calldata` 的形式寫入以太坊。 `calldata` 是儲存外部呼叫智慧合約函式時所包含資料的地方。 `calldata` 中的資訊會發佈在區塊鏈上，讓任何人都能獨立地重建卷軸的狀態。 零知識證明卷軸使用壓縮技術來減少交易資料 — 例如，由索引而非地址來代表帳戶，這將節省 28 個位元組的資料。 鏈上資料發佈是卷軸的一大成本，因此資料壓縮能夠降低使用者的費用。 ## 零知識證明卷軸如何與以太坊互動？ {#zk-rollups-and-ethereum} -零知識證明卷軸鏈是一種在以太坊區塊鏈之上運作的鏈外協定，並由鏈上的以太坊智慧型合約管理。 零知識證明卷軸在主網之外執行交易，但定期將鏈外交易批次提交到鏈上卷軸合約。 這種交易記錄是不可變的（與以太坊非常像），並且形成了零知識證明卷軸鏈， +零知識證明卷軸鏈是一種在以太坊區塊鏈之上運作的鏈下協定，並由鏈上的以太坊智能合約管理。 零知識證明卷軸在主網之外執行交易，但定期將鏈下交易批次提交到鏈上卷軸合約。 這種交易記錄是不可變的（與以太坊非常像），並且形成了零知識證明卷軸鏈， 零知識證明卷軸的核心架構由以下部分構成： -1. **鏈上合約**：如前所述，零知識證明卷軸協定由在以太坊上執行的智慧型合約控制。 這包括存儲卷軸區塊、追蹤存款，以及監控狀態更新的主要合約。 另一個鏈上合約（驗證者合約）驗證區塊生產者提交的零知識證明。 因此，以太坊充當零知識證明卷軸的基礎層或「一層網路」。 +1. **鏈上合約**：如前所述，ZK-rollup 協議是由在以太坊上執行的智慧合約所控制。 這包括存儲卷軸區塊、追蹤存款，以及監控狀態更新的主要合約。 另一個鏈上合約（驗證者合約）驗證區塊生產者提交的零知識證明。 因此，以太坊充當零知識證明卷軸的基礎層或「一層網路」。 -2. **鏈外虛擬機 (VM)**：儘管零知識證明卷軸活躍於以太坊上，但交易執行和狀態存儲發生在獨立於[以太坊虛擬機](/developers/docs/evm/)的單獨虛擬機。 這種鏈外虛擬機是零知識證明卷軸交易的執行環境，並充當零知識證明卷軸協定的次層或「二層網路」。 在以太坊主網上驗證的有效性證明可保證鏈外虛擬機中狀態轉換的正確性。 +2. **鏈下虛擬機 (VM)**：雖然 ZK-rollup 協議存在於以太坊上，但交易執行和狀態儲存是在一個獨立於 [EVM](/developers/docs/evm/) 的虛擬機上進行。 這種鏈下虛擬機是零知識證明卷軸交易的執行環境，並充當零知識證明卷軸協定的次層或「二層網路」。 在以太坊主網上驗證的有效性證明可保證鏈下虛擬機中狀態轉換的正確性。 -零知識證明卷軸是「混合擴張解決方案」— 獨立運作但從以太坊獲得安全性的鏈外協定。 具體來講，以太坊網路在零知識證明卷軸上執行狀態有效性更新，並保證每次更新卷軸狀態時的背景資料可用性。 因此，零知識證明卷軸比純鏈外擴張解決方案安全很多，例如自行負責安全屬性的[側鏈](/developers/docs/scaling/sidechains/)，或同樣使用有效性證明在以太坊上驗證交易，但將交易資料存儲在其他地方的 [Validium](/developers/docs/scaling/validium/)。 +零知識證明卷軸是「混合擴張解決方案」— 獨立運作但從以太坊獲得安全性的鏈下協定。 具體來講，以太坊網路在零知識證明卷軸上執行狀態有效性更新，並保證每次更新卷軸狀態時的背景資料可用性。 因此，ZK-rollups 比純鏈下擴張解決方案安全許多，例如自行負責安全屬性的[側鏈](/developers/docs/scaling/sidechains/)，或是同樣用有效性證明在以太坊上驗證交易、但將交易資料儲存在他處的 [validiums](/developers/docs/scaling/validium/)。 零知識證明卷軸依賴以太坊協定來獲得： ### 資料可用性 {#data-availability} -零知識證明卷軸將鏈外處理的每筆交易的狀態資料發佈到以太坊。 透過這些資料，個人或企業能夠復現卷軸的狀態並自行驗證鏈。 以太坊將這些資料作爲 `calldata` 提供給所有網路參與者。 +零知識證明卷軸將鏈下處理的每筆交易的狀態資料發佈到以太坊。 透過這些資料，個人或企業能夠復現卷軸的狀態並自行驗證鏈。 以太坊會將此資料以 `calldata` 的形式提供給網路的所有參與者。 零知識證明卷軸不需要在鏈上發佈很多交易資料，因爲有效性證明已經驗證了狀態轉換的真實性。 盡管如此，在鏈上儲存資料仍然重要，因爲這樣便可以對二層網路鏈的狀態進行無需許可的獨立驗證，從而使任何人都能提交批次交易，防止惡意營運者審查或凍結鏈。 @@ -46,7 +46,7 @@ lang: zh-tw 以太坊充當零知識證明卷軸的結算層：只有當一層網路合約接受有效性證明時，二層網路交易才會最終確定。 這消除了惡意營運者破壞鏈的風險（例如，竊取卷軸資金），因爲每筆交易都必須在主網上得到批准。 此外，以太坊還保證使用者作業一旦在一層網路上最終確定，就無法被撤銷。 -### 審查阻力 {#censorship-resistance} +### 抗審查性 {#censorship-resistance} 大多數零知識證明卷軸使用「超級節點」（營運者）來執行交易、生產批次，以及提交區塊到一層網路。 儘管這確保了效率，但也增加了審查風險：惡意零知識證明卷軸營運者可以透過拒絕將使用者的交易添加到批次交易來審查使用者。 @@ -58,21 +58,21 @@ lang: zh-tw 零知識證明卷軸中的使用者簽署交易，提交給二層網路營運者進行處理並添加到下一個批次中。 在某些情況下，營運者是一個被稱爲排序者的中心化實體，它會執行交易，將交易彙總到批次中，然後提交到一層網路。 該系統中的排序者是唯一被允許產生二層網路區塊並將卷軸交易新增到零知識證明卷軸合約的實體。 -其他零知識證明卷軸可以透過使用一組[權益證明](/developers/docs/consensus-mechanisms/pos/)驗證者來輪換營運者的角色。 潛在的營運者將資金存入卷軸合約，每份質押的大小會影響質押者被選中產生下一批次卷軸的機會。 如果營運者實施惡意行爲，其質押會被罰沒，這會激勵其發佈有效的區塊。 +其他 ZK-rollups 可能會透過使用[權益證明](/developers/docs/consensus-mechanisms/pos/)驗證者集來輪換營運者的角色。 潛在的營運者將資金存入卷軸合約，每份質押的大小會影響質押者被選中產生下一批次卷軸的機會。 如果營運者實施惡意行爲，其質押會被罰沒，這會激勵其發佈有效的區塊。 -#### 零知識證明卷軸如何在以太坊上發佈交易資料 {#how-zk-rollups-publish-transaction-data-on-ethereum} +#### ZK-rollups 如何在以太坊上發佈交易資料 {#how-zk-rollups-publish-transaction-data-on-ethereum} -如前所述，交易資料作爲 `calldata` 被發佈到以太坊上。 `calldata` 是智慧型合約中的資料區域，用於將引數傳送給函式，其行爲類似於[記憶體](/developers/docs/smart-contracts/anatomy/#memory)。 儘管 `calldata` 不會存儲到以太坊的狀態中，但其作爲以太坊鏈[歷史日志](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)的一部分一直存在於鏈上。 `calldata` 不會影響以太坊的狀態，這使其成爲一種在鏈上存儲資料的便宜方法。 +如前所述，交易資料會以 `calldata` 的形式發佈在以太坊上。 `calldata` 是智慧合約中的一個資料區域，用於將引數傳遞給函式，其行為類似於[記憶體](/developers/docs/smart-contracts/anatomy/#memory)。 雖然 `calldata` 不會作為以太坊狀態的一部分儲存，但它會以以太坊鏈的[歷史日誌](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)的一部分，持續存在於鏈上。 `calldata` 不會影響以太坊的狀態，使其成為一種在鏈上儲存資料的廉價方式。 -`calldata` 關鍵字通常標識交易所呼叫的智慧型合約方法，並以任意位元組序列的形式保存對方法的輸入。 零知識證明卷軸使用 `calldata` 將壓縮的交易資料發佈到鏈上；卷軸營運者只需要透過呼叫卷軸合約中所需的函式來添加一個新批次，並將壓縮資料作爲函式引數進行傳送。 這有助於降低使用者的成本，因爲卷軸費用的很大一部分用於在鏈上儲存交易資料。 +`calldata` 關鍵字通常用來識別交易正在呼叫的智慧合約方法，並以任意位元組序列的形式保存對該方法的輸入。 ZK-rollups 使用 `calldata` 將壓縮後的交易資料發佈到鏈上；rollup 營運者只需呼叫 rollup 合約中必要的函式來新增一個批次，並將壓縮後的資料作為函式引數傳遞。 這有助於降低使用者的成本，因爲卷軸費用的很大一部分用於在鏈上儲存交易資料。 ### 狀態承諾 {#state-commitments} -零知識證明卷軸的狀態包括二層網路帳戶和餘額，用[默克爾樹](/whitepaper/#merkle-trees)表示。 默克爾樹根（默克爾根）的加密雜湊儲存在鏈上合約中，這使卷軸協定能夠追蹤零知識證明卷軸狀態的變化。 +ZK-rollup 的狀態 (包含第 2 層帳戶和餘額) 是以[默克爾樹](/whitepaper/#merkle-trees)表示。 默克爾樹根（默克爾根）的加密雜湊儲存在鏈上合約中，這使卷軸協定能夠追蹤零知識證明卷軸狀態的變化。 在執行一組新交易后，卷軸轉換到新狀態。 發起狀態轉換的營運者需要計算新的狀態根並提交到鏈上合約。 如果與批次相關的有效性證明經過驗證者合約的驗證，新的默克爾根將成爲零知識證明卷軸的規範狀態根。 -除了計算狀態根以外，零知識證明卷軸營運者還會建立一個批次根 — 包含批次中所有交易的默克爾樹根。 當提交新批次時，卷軸合約會儲存批次根，讓使用者能夠證明交易（如提款請求）包含在批次中。 使用者必須提供交易詳情、批次根和顯示包含路徑的[默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)。 +除了計算狀態根以外，零知識證明卷軸營運者還會建立一個批次根 — 包含批次中所有交易的默克爾樹根。 當提交新批次時，卷軸合約會儲存批次根，讓使用者能夠證明交易（如提款請求）包含在批次中。 用戶必須提供交易詳情、批次根，以及一個顯示包含路徑的[默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)。 ### 有效性證明 {#validity-proofs} @@ -80,27 +80,27 @@ lang: zh-tw 但是，在營運者證明新默克爾根是由卷軸狀態的正確更新產生之前，卷軸合約不會自動接受提議的狀態承諾。 零知識證明卷軸營運者透過生成有效性證明來做到這一點，有效性證明是一種簡潔的加密承諾，用於驗證批次交易的正確性。 -有效性證明允許各方在不揭露聲明本身的情況下證明聲明的正確性，因此又被稱爲零知識證明。 零知識證明卷軸使用有效性證明確認鏈外狀態轉換的正確性，而無需在以太坊上重新執行交易。 這些證明可以是 [ZK-SNARK](https://arxiv.org/abs/2202.06877)（零知識簡潔非互動式知識論證）或 [ZK-STARK](https://eprint.iacr.org/2018/046)（零知識可擴展透明知識論證）兩種形式。 +有效性證明允許各方在不揭露聲明本身的情況下證明聲明的正確性，因此又被稱爲零知識證明。 零知識證明卷軸使用有效性證明確認鏈下狀態轉換的正確性，而無需在以太坊上重新執行交易。 這些證明可以採用 [ZK-SNARK](https://arxiv.org/abs/2202.06877) (零知識簡潔非互動知識論證) 或 [ZK-STARK](https://eprint.iacr.org/2018/046) (零知識可擴展透明知識論證) 的形式。 -SNARK（簡潔非互動式知識論證）和 STARK（可擴展透明知識論證）都有助於證明零知識證明卷軸中鏈外計算的完整性，儘管每種證明類型都有不同的功能。 +SNARK（簡潔非互動式知識論證）和 STARK（可擴展透明知識論證）都有助於證明零知識證明卷軸中鏈下計算的完整性，儘管每種證明類型都有不同的功能。 -**ZK-SNARK（零知識簡潔非互動式知識論證）** +**ZK-SNARKs** 爲了使 ZK-SNARK 協定正常運作，需要建立公共參考串 (CRS)：公共參考串提供公共參數來證明和驗證有效性證明。 證明系統的安全性取決於公共參考串設定；如果用於建立公共參數的資訊落入惡意行爲者手中，他們或許能夠產生虛假的有效性證明。 -一些零知識證明卷軸嘗試透過采用[多方計算儀式 (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) 來解決該問題，即由可信的個人為 ZK-SNARK 電路產生公共參數。 每一方都貢獻一些隨機性（稱為「有毒廢棄物」）來構建公共參考串，而且必須立即將其銷毀。 +有些 ZK-rollups 會嘗試透過 [多方運算儀式 (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) 來解決此問題，其中會涉及受信任的個人，來為 ZK-SNARK 電路產生公開參數。 每一方都貢獻一些隨機性（稱為「有毒廢棄物」）來構建公共參考串，而且必須立即將其銷毀。 使用可信的設定，因爲這會提高公共參考串設定的安全性。 只要誠實的參與者銷毀其輸入，ZK-SNARK 系統的安全性就會得到保證。 這種方法仍然需要信任相關人員刪除他們采樣的隨機性，並且不會破壞系統的安全保證。 抛開信任假設不談，ZK-SNARK 因其更小的證明大小和恆定時間驗證而受到歡迎。 由於執行零知識證明卷軸的大部分成本用於一層網路上的證明驗證，因此二層網路使用 ZK-SNARK 來產生可在主網上快速、便宜地進行驗證的證明。 -**ZK-STARK** +**ZK-STARKs** -與 ZK-SNARK 相似，ZK-STARK 在不揭露輸入的情況下證明鏈外計算的有效性。 然而，ZK-STARK 因其具有可擴展性和透明性，被認爲是對 ZK-SNARK 的改進。 +與 ZK-SNARK 相似，ZK-STARK 在不揭露輸入的情況下證明鏈下計算的有效性。 然而，ZK-STARK 因其具有可擴展性和透明性，被認爲是對 ZK-SNARK 的改進。 ZK-STARK 是「透明的」，因爲它能夠在沒有可信的公共參考串 (CRS) 設定的情況下正常運作。 相反，ZK-STARK 則依賴可公開驗證的隨機性來設定用於產生和驗證證明的參數。 -ZK-STARK 還提供了更多可擴展性，因爲證明和驗證有效性證明所需的時間相對於底層計算的複雜性呈_准綫性_增長。 對於 ZK-SNARK，證明和驗證時間相對於底層計算的規模呈_綫性_擴張。 這意味著當涉及大資料集時，ZK-STARK 相比 ZK-SNARK 需要的證明和驗證時間更少，因而適用於大批量應用程式。 +ZK-STARKs 也提供更高的可擴展性，因為證明和驗證有效性證明所需的時間，會隨著底層運算的複雜度呈 _準線性_ 增加。 使用 ZK-SNARKs，證明和驗證時間會隨著底層運算的規模呈 _線性_ 增加。 這意味著當涉及大資料集時，ZK-STARK 相比 ZK-SNARK 需要的證明和驗證時間更少，因而適用於大批量應用程式。 ZK-STARK 對於量子電腦也是安全的，而 ZK-SNARK 中使用的橢圓曲綫密碼學 (ECC) 則被廣范認爲容易受到量子電腦攻擊。 ZK-STARK 的缺點是其產生的證明大小更大，在以太坊上進行驗證時更加昂貴。 @@ -136,17 +136,17 @@ ZK-STARK 對於量子電腦也是安全的，而 ZK-SNARK 中使用的橢圓曲 在證明電路驗證狀態更新的正確性后，二層網路營運者將計算后的有效性證明提交給一層網路上的驗證者合約。 合約的驗證電路驗證證明的有效性，並檢查證明中包含的公開輸入： -- **前狀態根**：零知識證明卷軸的舊狀態根（即在交易批次被執行之前），反映二層網路鏈的上一個已知有效狀態。 +- **前狀態根**：ZK-rollup 的舊狀態根 (也就是在執行批次交易前)，反映第 2 層鏈的最後一個已知有效狀態。 -- **后狀態根**：零知識證明卷軸的新狀態根（即交易批次執行之後），反映二層網路鏈的最新狀態。 后狀態根是在證明電路中應用狀態更新后產生的最終根。 +- **後狀態根**：ZK-rollup 的新狀態根 (也就是在執行批次交易後)，反映第 2 層鏈的最新狀態。 后狀態根是在證明電路中應用狀態更新后產生的最終根。 -- **批次根**：批次的默克爾根，透過對批次中的交易進行_默克爾化_和對樹根進行雜湊處理得到。 +- **批次根**：批次的默克爾根，是透過 _默克爾化_ 批次中的交易並對樹根進行哈希運算而得來。 -- **交易輸入**：與在已提交批次中執行的交易相關的資料。 +- **交易輸入**：與作為提交批次一部分執行的交易相關的資料。 如果證明滿足電路條件（即證明有效），則意味著存在一系列有效交易，這些交易將卷軸從先前狀態（由前狀態根提供加密指紋）轉換為新狀態（由后狀態根提供加密指紋）。 如果前狀態根與儲存在卷軸合約中的根相符，並且證明是有效的，则卷軸合約就會從證明中獲取后狀態根並更新其狀態樹以反映卷軸的狀態變化。 -### 進入與退出 {#entries-and-exits} +### 進出 {#entries-and-exits} 使用者透過向部署在一層網路鏈上的卷軸合約中存入代幣，來進入零知識證明卷軸。 該交易已排隊，因爲只有營運者能夠將交易提交到卷軸合約。 @@ -164,11 +164,11 @@ ZK-STARK 對於量子電腦也是安全的，而 ZK-SNARK 中使用的橢圓曲 卷軸合約對交易資料進行杂凑處理，檢查批次根是否存在，並使用默克爾證明檢查交易杂凑是否為批次根的一部分。 之後，合約會執行退出交易並將資金發送到使用者選擇的一層網路上的地址。 -## 零知識證明卷軸和以太坊虛擬機的相容性 {#zk-rollups-and-evm-compatibility} +## ZK-rollups 與 EVM 的相容性 {#zk-rollups-and-evm-compatibility} -與樂觀卷軸不同，零知識證明卷軸不直接與[以太坊虛擬機 (EVM)](/developers/docs/evm/) 相容。 在電路中證明通用以太坊虛擬機計算比證明簡單計算（如先前描述的代幣傳送）更加困難，且更消耗資源。 +不同於樂觀卷軸，ZK-rollups 並不容易與[以太坊虛擬機 (EVM)](/developers/docs/evm/) 相容。 在電路中證明通用以太坊虛擬機計算比證明簡單計算（如先前描述的代幣傳送）更加困難，且更消耗資源。 -然而，[零知識技術的進步](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now)重新點燃了將以太坊虛擬機計算包裝在零知識證明中的興趣。 這些努力旨在建立一個零知識以太坊虛擬機 (zkEVM) 實作，能夠高效地驗證程式執行的正確性。 零知識以太坊虛擬機重新建立在電路中進行證明/驗證的現有以太坊虛擬機作業碼，使其能夠執行智慧型合約。 +然而，[零知識技術的進步](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now)正重新點燃人們將 EVM 運算包裝在零知識證明中的興趣。 這些努力旨在建立一個零知識以太坊虛擬機 (zkEVM) 實作，能夠高效地驗證程式執行的正確性。 零知識以太坊虛擬機重新建立在電路中進行證明/驗證的現有以太坊虛擬機作業碼，使其能夠執行智慧型合約。 與以太坊虛擬機相似，零知識以太坊虛擬機在對某些輸入執行計算之後，會在狀態之間轉換。 區別在於，零知識以太坊虛擬機還會建立零知識證明，以驗證程式執行中每一步的正確性。 有效性證明可以驗證涉及虛擬機狀態（記憶體、堆棧、存儲）和計算本身的作業的正確性（即作業是否調用了正確的作業碼並正確地執行它們？）。 @@ -178,21 +178,21 @@ ZK-STARK 對於量子電腦也是安全的，而 ZK-SNARK 中使用的橢圓曲 使用者為零知識證明卷軸上的交易支付多少費用取決於燃料費，就像在以太坊主網上一樣。 然而，燃料費在二層網路上的運作方式不同，並且受以下費用影響： -1. **狀態寫入**：寫入以太坊狀態（即，在以太坊區塊鏈上提交交易）有固定費用。 零知識證明卷軸透過進行批次交易並將固定費用分攤給多名使用者，降低了該費用。 +1. **狀態寫入**：寫入以太坊狀態 (即在以太坊區塊鏈上提交一筆交易) 有固定的成本。 零知識證明卷軸透過進行批次交易並將固定費用分攤給多名使用者，降低了該費用。 -2. **資料發佈**：零知識證明卷軸將每筆交易的狀態資料作爲 `calldata` 發佈到以太坊。 `calldata` 費用目前由 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 管控，它規定 `calldata` 的非零位元組和零位元組的費用分別爲 16 燃料和 4 燃料。 每筆交易支付的費用受到需要在鏈上爲其發佈的 `calldata` 數量所影響。 +2. **資料發佈**：ZK-rollups 會將每筆交易的狀態資料以 `calldata` 的形式發佈到以太坊。 `calldata` 的成本目前由 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 管理，其中規定 `calldata` 的非零位元組成本為 16 gas，零位元組成本為 4 gas。 每筆交易支付的成本取決於需要為其在鏈上發佈多少 `calldata`。 -3. **二層網路營運者費用**：這是支付給卷軸營運者的金額，作爲處理交易所產生的計算費用的補償，很像以太坊主網上的[交易「優先費」（小費）](/developers/docs/gas/#how-are-gas-fees-calculated)。 +3. **第 2 層營運者費用**：這是支付給 rollup 營運者的金額，作為處理交易產生的運算成本的補償，很像以太坊主網上的[交易「優先費 (小費)」](/developers/docs/gas/#how-are-gas-fees-calculated)。 -4. **證明產生和驗證**：零知識證明卷軸營運者必須為交易批次生成有效性證明，這會消耗大量資源。 在主網上驗證零知識證明也會花費燃料（約 500,000 燃料）。 +4. **證明產生與驗證**：ZK-rollup 營運者必須為交易批次產生有效性證明，這個過程非常耗費資源。 在主網上驗證零知識證明也會花費燃料（約 500,000 燃料）。 -除了進行批次交易之外，零知識證明卷軸還透過壓縮交易資料來降低使用者的費用。 你可以[查看即時概覽](https://l2fees.info/)來瞭解使用以太坊零知識證明卷軸的費用。 +除了進行批次交易之外，零知識證明卷軸還透過壓縮交易資料來降低使用者的費用。 你可以[即時查看](https://l2fees.info/)使用以太坊 ZK-rollups 的成本概覽。 ## 零知識證明卷軸如何擴張以太坊？ {#scaling-ethereum-with-zk-rollups} ### 交易資料壓縮 {#transaction-data-compression} -零知識證明卷軸透過在鏈外計算來提高以太坊基礎層的吞吐量，但真正提升擴展的手段是壓縮交易資料。 以太坊的[區塊大小](/developers/docs/blocks/#block-size)限制了每個區塊能夠保存的資料，進而限制了每個區塊處理的交易數量。 透過壓縮交易相關的資料，零知識證明卷軸顯著增加了每個區塊處理的交易數量。 +零知識證明卷軸透過在鏈下計算來提高以太坊基礎層的吞吐量，但真正提升擴展的手段是壓縮交易資料。 以太坊的[區塊大小](/developers/docs/blocks/#block-size)限制了每個區塊能容納的資料量，從而也限制了每個區塊能處理的交易數量。 透過壓縮交易相關的資料，零知識證明卷軸顯著增加了每個區塊處理的交易數量。 零知識證明卷軸能夠比樂觀卷軸更好地壓縮交易資料，因爲它不必發佈驗證每筆交易所需的所有資料。 它只需要發佈在卷軸上重建帳戶最新狀態和餘額所需的最少資料。 @@ -204,19 +204,19 @@ ZK-STARK 對於量子電腦也是安全的，而 ZK-SNARK 中使用的橢圓曲 然而，遞迴證明可以使用一個有效性證明最終確定多個區塊。 這是因爲證明電路會遞迴彙總多個區塊證明，直到建立一個最終證明。 二層網路營運者提交該遞迴證明，如果合約接受它，所有相關的區塊將會立即最終確定。 使用遞迴證明，可以定期在以太坊上最終確定的零知識證明卷軸交易的數量將會增加。 -### 零知識證明卷軸的優勢和劣勢 {#zk-rollups-pros-and-cons} +### ZK-rollups 的優缺點 {#zk-rollups-pros-and-cons} -| 優勢 | 劣勢 | -| -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | -| 有效性證明確保鏈外交易的正確性，並防止營運者執行無效的狀態轉換。 | 與計算和驗證有效性證明相關的成本很高，並且可能會增加卷軸使用者的費用。 | -| 一旦在一層網路上驗證了有效性證明，當狀態更新獲得批准後，交易會更快地最終確定。 | 由於零知識技術的複雜性，構建與以太坊虛擬機相容的零知識證明卷軸很困難。 | -| 依賴去信任加密機制來保證安全，而不是像[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons)一樣依賴受激勵行爲者的誠實。 | 生成有效性證明需要專業化硬體，這可能會鼓勵一些參與方對鏈進行集中化控制。 | -| 將恢復鏈外狀態所需的資料儲存在一層網路上，這保證了安全性、抗審查性和去中心化。 | 中心化營運者（排序者）可以影響交易的順序。 | -| 使用者從更高的資本效率中受益，並且可以立即從二層網路提取資金。 | 硬體要求可能會減少能夠强制推進鏈的參與者數量，這增加了惡意營運者凍結卷軸狀態和審查使用者的風險。 | -| 不依賴於活躍性假設，使用者不必驗證鏈也能保護其資金。 | 一些證明系統（如 ZK-SNARK）需要可信的設定，如果處理不當，可能會損害零知識證明卷軸的安全模型。 | -| 更好的資料壓縮有助於降低在以太坊上發佈 `calldata` 的成本，並將使用者的卷軸費用降到最低。 | | +| 優勢 | 劣勢 | +| ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | +| 有效性證明確保鏈下交易的正確性，並防止營運者執行無效的狀態轉換。 | 與計算和驗證有效性證明相關的成本很高，並且可能會增加卷軸使用者的費用。 | +| 一旦在一層網路上驗證了有效性證明，當狀態更新獲得批准後，交易會更快地最終確定。 | 由於零知識技術的複雜性，構建與以太坊虛擬機相容的零知識證明卷軸很困難。 | +| 依賴無需信任的密碼學機制來確保安全性，而非像[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons)一樣依賴受激勵行動者的誠實。 | 生成有效性證明需要專業化硬體，這可能會鼓勵一些參與方對鏈進行集中化控制。 | +| 將恢復鏈下狀態所需的資料儲存在一層網路上，這保證了安全性、抗審查性和去中心化。 | 中心化營運者（排序者）可以影響交易的順序。 | +| 使用者從更高的資本效率中受益，並且可以立即從二層網路提取資金。 | 硬體要求可能會減少能夠强制推進鏈的參與者數量，這增加了惡意營運者凍結卷軸狀態和審查使用者的風險。 | +| 不依賴於活躍性假設，使用者不必驗證鏈也能保護其資金。 | 一些證明系統（如 ZK-SNARK）需要可信的設定，如果處理不當，可能會損害零知識證明卷軸的安全模型。 | +| 更好的資料壓縮有助於降低在以太坊上發佈 `calldata` 的成本，並將用戶的 rollup 費用降到最低。 | | -### 零知識證明卷軸之視覺解釋 {#zk-video} +### ZK-rollups 的視覺化解釋 {#zk-video} 觀看 Finematics 的零知識證明卷軸影片： @@ -226,28 +226,32 @@ ZK-STARK 對於量子電腦也是安全的，而 ZK-SNARK 中使用的橢圓曲 零知識以太坊虛擬機上運作的專案包括： -- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM 是由以太坊基金會資助的專案，旨在開發與以太坊虛擬機相容的零知識證明卷軸，以及為以太坊區塊產生有效性證明的機制。_ +- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM 是一個由以太坊基金會資助的專案，旨在開發一個與 EVM 相容的 ZK-rollup，以及一個為以太坊區塊產生有效性證明的機制。_ -- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _是以太坊主網上的一個去中心化零知識證明卷軸，它在零知識以太坊虛擬機 (zkEVM) 上運作，以透明的方式執行以太坊交易，包括具有零知識證明驗證的智慧型合約。_ +- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _是一個在以太坊主網上的去中心化 ZK Rollup，它在零知識以太坊虛擬機 (zkEVM) 上運作，以透明的方式執行以太坊交易，包含具有零知識證明驗證的智慧合約。_ -- **[Scroll](https://scroll.io/blog/zkEVM)** - _是一家技術驅動型公司，致力於為以太坊構建原生零知識以太坊虛擬機二層網路解決方案。_ +- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll 是一家技術導向的公司，致力於為以太坊打造一個原生的 zkEVM 第 2 層解決方案。_ -- **[Taiko](https://taiko.xyz)** - _Taiko 是等同於以太坊的去中心化零知識證明卷軸（[第一類零知識以太坊虛擬機](https://vitalik.eth.limo/general/2022/08/04/zkevm.html)）。_ +- **[Taiko](https://taiko.xyz)** - _Taiko 是一個去中心化、等效於以太坊的 ZK-rollup (一個[第 1 類 ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))。_ -- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era 是與以太坊個虛擬機相容的零知識證明卷軸，由 Matter Labs 構建，並由其自己的零知識以太坊虛擬機提供支援。_ +- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era 是一個由 Matter Labs 打造、與 EVM 相容的 ZK Rollup，由其自己的 zkEVM 提供支援。_ -- **[Starknet](https://starkware.co/starknet/)** - _StarkNet 是一個與以太坊虛擬機相容的二層網路擴張解決方案，由 StarkWare 構建。_ +- **[Starknet](https://starkware.co/starknet/)** - _StarkNet 是一個由 StarkWare 打造、與 EVM 相容的第 2 層擴張解決方案。_ -- **[Morph](https://www.morphl2.io/)** - _Morph 是一個利用零知識證明來解決二層網路狀態挑戰問題的混合卷軸擴張解決方案。_ +- **[Morph](https://www.morphl2.io/)** - _Morph 是一個混合式 rollup 擴張解決方案，它利用 zk-proof 來應對第 2 層狀態挑戰問題。_ -## 深入閲讀零知識證明卷軸的相關内容 {#further-reading-on-zk-rollups} +- **[Linea](https://linea.build)** - _Linea 是由 Consensys 打造、等效於以太坊的 zkEVM 第 2 層，與以太坊生態系統完全一致。_ -- [什麼是零知識證明卷軸？](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) -- [什麼是零知識證明卷軸？](https://alchemy.com/blog/zero-knowledge-rollups) -- [STARK 和 SNARK 的比較](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) -- [什麽是零知識以太坊虛擬機？](https://www.alchemy.com/overviews/zkevm) -- [零知識以太坊虛擬機類型：等同於以太坊、等同於以太坊虛擬機、第 1 類、第 4 類，以及其他難以理解的拗口詞](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) -- [介紹零知識以太坊虛擬機](https://hackmd.io/@yezhang/S1_KMMbGt) -- [超贊的零知識以太坊虛擬機資源](https://github.com/LuozhuZhang/awesome-zkevm) -- [深入瞭解 ZK-SNARK](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) -- [如何實現 SNARK？](https://vitalik.eth.limo/general/2021/01/26/snarks.html) +## 關於 ZK-rollups 的延伸閱讀 {#further-reading-on-zk-rollups} + +- [什麼是零知識卷軸？](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) +- [什麼是零知識卷軸？](https://alchemy.com/blog/zero-knowledge-rollups) +- [以太坊卷軸實用指南](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [STARKs 與 SNARKs 的比較](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) +- [什麼是 zkEVM？](https://www.alchemy.com/overviews/zkevm) +- [ZK-EVM 類型：等效於以太坊、等效於 EVM、第 1 類、第 4 類以及其他神秘的流行語](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) +- [zkEVM 簡介](https://hackmd.io/@yezhang/S1_KMMbGt) +- [什麼是 ZK-EVM L2s？](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M) +- [Awesome-zkEVM 資源](https://github.com/LuozhuZhang/awesome-zkevm) +- [ZK-SNARKS 深入解析](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) +- [SNARKs 如何成為可能？](https://vitalik.eth.limo/general/2021/01/26/snarks.html) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/anatomy/index.md index d460361047e..b5cbde94da3 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/anatomy/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/anatomy/index.md @@ -1,6 +1,6 @@ --- -title: 智慧型合約結構 -description: 智慧型合約深入解析：功能、資料、變數。 +title: "智慧型合約結構" +description: "智慧型合約深入解析：功能、資料、變數。" lang: zh-tw --- @@ -8,20 +8,20 @@ lang: zh-tw ## 先決條件 {#prerequisites} -務必先瞭解[智慧型合約](/developers/docs/smart-contracts/)。 此文件假設你已熟悉 JavaScript 或 Python 等程式語言。 +請務必先閱讀關於 [智能合約](/developers/docs/smart-contracts/) 的內容。 此文件假設你已熟悉 JavaScript 或 Python 等程式語言。 ## 資料 {#data} -任何合約資料都須指定至 `storage` 或 `memory` 這兩個位置。 修改智慧型合約的存儲很麻煩，所以必須謹慎思考要將資料儲存至何處。 +任何合約資料都必須指派到一個位置：`storage` 或 `memory`。 修改智慧型合約的存儲很麻煩，所以必須謹慎思考要將資料儲存至何處。 -### 儲存 {#storage} +### Storage {#storage} 永久資料也稱為存儲，並由狀態變數表示。 這些值會永久儲存於區塊鏈上。 你需要聲明一個類型，以便於合約在編譯時可以追蹤在區塊鏈上需要多少存儲空間。 ```solidity // Solidity 範例 contract SimpleStorage { - uint storedData; //狀態變量 + uint storedData; // 狀態變數 // ... } ``` @@ -31,9 +31,9 @@ contract SimpleStorage { storedData: int128 ``` -如果已編寫過物件導向程式語言，應該會熟悉大多數類型。 但如果剛接觸以太坊開發，則會不熟悉 `address` 類型。 +如果已編寫過物件導向程式語言，應該會熟悉大多數類型。 但是，如果你是剛接觸以太坊開發的新手，應該會對 `address` 感到陌生。 -一個 `address` 類型可以容納一個以太坊地址，相當於 20 個位元組或 160 個位元。 它會以十六進制的形式傳回，前綴是 0x。 +`address` 類型可以儲存一個以太坊地址，相當於 20 個位元組或 160 位元。 它會以十六進制的形式傳回，前綴是 0x。 其他類型包含： @@ -41,22 +41,22 @@ storedData: int128 - 整數 - 定點數 - 固定規模的位元組陣列 -- 動態規模的位元組陣列 -- 有理數和整數常值 +- 動態大小的位元組陣列 +- 有理數與整數常值 - 字串常值 - 十六進位常值 - 列舉 如需更多說明，請參閱文件： -- [查看 Vyper 類型](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types) -- [查看 Solidity 類型](https://solidity.readthedocs.io/en/latest/types.html#value-types) +- [查看 Vyper 類型](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types) +- [查看 Solidity 類型](https://docs.soliditylang.org/en/latest/types.html#value-types) ### 記憶體 {#memory} 僅在合約函數的執行生命週期儲存的值稱為記憶體變數。 由於這些變數不是永久儲存在區塊鏈上，所以使用成本要低得多。 -在 [Solidity 文件](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack)中深入瞭解以太坊虛擬機如何儲存資料（存儲、記憶體和堆疊）。 +在 [Solidity 文件](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack)中，深入了解 EVM 如何儲存資料 (儲存體、記憶體與堆疊)。 ### 環境變數 {#environment-variables} @@ -69,21 +69,21 @@ storedData: int128 | `block.timestamp` | uint256 | 目前區塊時期的時間戳 | | `msg.sender` | address | 訊息發送者（目前調用） | -## 函式 {#functions} +## 函數 {#functions} 用最簡單的術語來說，函數可以取得資訊或者設定資訊來回應傳入的交易。 有兩種函數調用方式： -- `Internal` – 不會建立以太坊虛擬機調用 - - 內部函數和狀態變數只能在內部存取（如在目前合約內部或從其衍生的合約存取） -- `External` – 會建立以太坊虛擬機調用 - - 外部函數是合約介面的一部分，這表示可以從其他合約與透過交易調用。 一個外部函數 `f` 不可以被內部調用（即 `f()` 無法工作，但 `this.f()` 可以）。 +- `internal` – 這些不會建立 EVM 呼叫 + - 內部函數和狀態變數只能在內部存取 (即從目前合約或衍生自它的合約中存取) +- `external` – 這些會建立 EVM 呼叫 + - 外部函數是合約介面的一部分，這表示可以從其他合約與透過交易調用。 外部函數 `f` 無法在內部呼叫 (即 `f()` 無法運作，但 `this.f()` 可以)。 -它們還可以是 `Public` 或 `Private` +它們也可以是 `public` 或 `private` -- `public` 函數可以在合約內部調用或者透過訊息在合約外部調用 -- `Private` 函數僅定義它們的合約內部可見，而不會出現在衍生合約中 +- `public` 函數可以從合約內部或透過訊息從外部呼叫 +- `private` 函數只有在定義它們的合約中才可見，在衍生合約中則不可見 函數和狀態變數都可以被定義為 Public 或 Private @@ -96,11 +96,11 @@ function update_name(string value) public { } ``` -- `String` 類型的參數 `Value` 傳入函數 `update_name` -- 該函數聲明為 `public`，表示任何人都能存取 -- 該函數未聲明為 `view`，因此可以修改合約狀態 +- 類型為 `string` 的參數 `value` 會傳遞至函數：`update_name` +- 它被宣告為 `public`，代表任何人都可以存取 +- 它未被宣告為 `view`，因此可以修改合約狀態 -### 檢視函式 {#view-functions} +### 檢視函數 {#view-functions} 這些函數保證不會修改合約資料的狀態。 常見範例為「getter」函數，例如，你可能用此接收使用者的餘額。 @@ -123,26 +123,27 @@ def readName() -> string: 以下情況被視為修改狀態： 1. 寫入狀態變數。 -2. [釋出事件](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events)。 -3. [建立其他合約](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts)。 -4. 使用 `selfdestruct` 。 +2. [發出事件](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events)。 +3. [建立其他合約](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts)。 +4. 使用 `selfdestruct`。 5. 透過調用傳送以太幣。 -6. 調用任何未標記為 `view` 或 `pure` 的函數。 +6. 呼叫任何未標示為 `view` 或 `pure` 的函數。 7. 使用低階調用。 8. 使用包含特定作業碼的行內組譯。 -### Constructor 函式 {#constructor-functions} +### 建構函數 {#constructor-functions} -`constructor` 函數只在首次部署時執行一次。 與許多基於類型之程式語言的 `constructor` 函數類似，這些函數常將狀態變數初始化為指定值。 +`constructor` 函數只會在合約首次部署時執行一次。 與許多以類別為基礎的程式語言中的 `constructor` 類似，這些函數通常會將狀態變數初始化為其指定值。 ```solidity -// Solidity 示例 -// 初始化合約數據, 設置 `owner`為合約的創建者。 +// Solidity 範例 +// 初始化合約的資料，將 `owner` +// 設定為合約建立者的地址。 constructor() public { - // 所有智慧型合約依賴外部交易來觸發其函數。 - // `msg` 是一個全局變量，包含了給定交易的相關數據， - // 例如發送者的地址和交易中包含的ETH數量。 - // 了解更多: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + // 所有智能合約都依賴外部交易來觸發其函數。 + // `msg` 是一個全域變數，其中包含關於特定交易的相關資料， + // 例如傳送者的地址以及交易中包含的 ETH 值。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties owner = msg.sender; } ``` @@ -157,7 +158,7 @@ def __init__(_beneficiary: address, _bidding_time: uint256): self.auctionEnd = self.auctionStart + _bidding_time ``` -### 內建函式 {#built-in-functions} +### 內建函數 {#built-in-functions} 除了自己合約上定義的變數與函數外，還有一些特殊的內建函數。 最明顯的例子： @@ -166,7 +167,7 @@ def __init__(_beneficiary: address, _bidding_time: uint256): 這讓合約可以給其他帳戶傳送以太幣。 -## 編寫函式 {#writing-functions} +## 撰寫函數 {#writing-functions} 你的函數需要： @@ -179,65 +180,66 @@ def __init__(_beneficiary: address, _bidding_time: uint256): pragma solidity >=0.4.0 <=0.6.0; contract ExampleDapp { - string dapp_name; //state variable + string dapp_name; // 狀態變數 - /*在合約部署時調用以初始化數據*/ - constructor() public{ + // 在合約部署時呼叫，並初始化數值 + constructor() public { dapp_name = "My Example dapp"; } // Get 函數 - function read_name() public view returns(string){ - return dapp_name; - } + function read_name() public view returns(string) { + return dapp_name; + } // Set 函數 function update_name(string value) public { dapp_name = value; - } + } } ``` -完整的合約看起來可能如上所示。 這裡的 `constructor` 函數為 `dapp_name` 變數提供初始值。 +完整的合約看起來可能如上所示。 此處的 `constructor` 函數為 `dapp_name` 變數提供了一個初始值。 -## 事件與記錄 {#events-and-logs} +## 事件與日誌 {#events-and-logs} 事件讓你的智慧型合約能夠與你的前端或其他訂閱應用程式進行通訊。 一旦交易被驗證並新增到區塊中，智慧型合約就可以發出事件和記錄訊息，然後前端就能夠處理和利用這些資訊。 ## 附註範例 {#annotated-examples} -以下是一些用 Solidity 編寫的範例。 若你想試著編寫程式碼，可以在 [Remix](http://remix.ethereum.org) 中與這些範例互動。 +以下是一些用 Solidity 編寫的範例。 如果你想試用這些程式碼，可以在 [Remix](http://remix.ethereum.org) 中與其互動。 ### Hello world {#hello-world} ```solidity -// 確定Solidity版本，使用語義化版本。 -// 了解更多：https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// 指定 Solidity 的版本，使用語意化版本控制。 +// 深入了解：https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity ^0.5.10; -// 定義合約名稱 `HelloWorld`. -// 一個合約是函數和數據 (其狀態) 的集合。 -// 一旦部署，合約就會留在以太坊區塊鏈的一個特定地址上。 -// 了解更多： https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// 定義一個名為 `HelloWorld` 的合約。 +// 合約是函數和資料 (其狀態) 的集合。 +// 部署之後，合約會存放在以太坊區塊鏈的特定地址上。 +// 深入了解：https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html contract HelloWorld { - // 定義`string`類型變量 `message` - // 狀態變量是其值永久存儲在合約存儲中的變量。 - // 關鍵字 `public` 使得可以從合約外部訪問。 - // 並創建了一個其它合約或客戶可以調用訪問該值的函數。 + // 宣告一個類型為 `string` 的狀態變數 `message`。 + // 狀態變數的值會永久儲存在合約儲存體中。 + // `public` 關鍵字讓變數可以從合約外部存取， + // 並建立一個可供其他合約或用戶端呼叫以存取其值的函數。 string public message; - // 類似於很多基於類的面向對象語言， - // 構造函數是僅在合約創建時執行的特殊函數。 - // 構造器用於初始化合約的數據。 - // 了解更多：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // 與許多以類別為基礎的物件導向語言相似，建構函式是 + // 一個只在合約建立時執行的特殊函數。 + // 建構函式是用來初始化合約的資料。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors constructor(string memory initMessage) public { - // 接受一個字符變量 `initMessage` - // 並為合約的存儲變量`message` 賦值 + // 接受一個字串引數 `initMessage` 並將值設定 + // 到合約的 `message` 儲存變數中)。 message = initMessage; } - // 一個public函數接受字符參數並更新存儲變量 `message` + // 一個公開函數，它接受一個字串引數 + // 並更新 `message` 儲存變數。 function update(string memory newMessage) public { message = newMessage; } @@ -250,57 +252,58 @@ contract HelloWorld { pragma solidity ^0.5.10; contract Token { - // 一個 `address` 類比於郵件地址 - 它用來識別以太坊的一個帳戶. - // 地址可以代表一個智慧型合約或一個外部（用戶）帳戶。 - // 了解更多: https://solidity.readthedocs.io/en/v0.5.10/types.html#address + // `address` 類似於電子郵件地址，用來識別以太坊上的帳戶。 + // 地址可以代表一個智能合約或一個外部 (使用者) 帳戶。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/types.html#address address public owner; - // `mapping` 是一個哈希表（hash table）數據結構 - // 此 `mapping` 將一個無符號整數 (代幣餘額) 分配給地址 (代幣持有者)。 - // 了解更多： https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types + // `mapping` 本質上是一種雜湊表資料結構。 + // 這個 `mapping` 會將一個無正負號整數 (代幣餘額) 指派給一個地址 (代幣持有者)。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types mapping (address => uint) public balances; -// 事件（Events）允許在區塊鏈上記錄活動。 - // 以太坊客戶端可以監聽事件，以便對合約狀態更改作出反應。 - // 了解更多： https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events + // 事件允許在區塊鏈上紀錄活動。 + // 以太坊用戶端可以監聽事件，以便對合約狀態變更做出反應。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events event Transfer(address from, address to, uint amount); - // 初始化合約數據，設置 `owner`為合約創建者的地址。 + // 初始化合約的資料，將 `owner` + // 設定為合約建立者的地址。 constructor() public { - // 所有智慧型合約依賴外部交易來觸發其函數。 - // `msg` 是一個全局變量，包含了給定交易的相關數據， - // 例如發送者的地址和交易中包含的ETH數量。 - // 了解更多: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + // 所有智能合約都依賴外部交易來觸發其函數。 + // `msg` 是一個全域變數，其中包含關於特定交易的相關資料， + // 例如傳送者的地址以及交易中包含的 ETH 值。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties owner = msg.sender; } - // 創建一些新代幣並發送給一個地址 + // 建立一定數量的新代幣並將其傳送到一個地址。 function mint(address receiver, uint amount) public { - // `require` 是一個用於強制執行某些條件的控制結構。 - // 如果 `require` 的條件為 `false`, 則異常被觸發, - // 所有在當前調用中對狀態的更改將被還原。 - // 了解更多： https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + // `require` 是一種控制結構，用於強制執行某些條件。 + // 如果 `require` 陳述式求值為 `false`，則會觸發例外， + // 它會還原在目前呼叫期間對狀態所做的所有變更。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - // 只有合約的擁有者可以調用這個函數 - require(msg.sender == owner, "You are not the owner."); + // 只有合約擁有者可以呼叫此函數 + require(msg.sender == owner, "您不是擁有者。"); - // 保證代幣的最大數量 - require(amount < 1e60, "Maximum issuance succeeded"); + // 強制執行代幣的最大數量 + require(amount < 1e60, "已超過最大發行量"); - // 將 `receiver` 持有的代幣數量數量增加 `amount` + // 將 `receiver` 的餘額增加 `amount` balances[receiver] += amount; } - // 發送一定數量調用者的代幣給一個地址 + // 從任何呼叫者傳送一定數量的現有代幣到一個地址。 function transfer(address receiver, uint amount) public { - // 發送者必須有足夠數量的代幣用於發送 - require(amount <= balances[msg.sender], "Insufficient balance."); + // 傳送者必須有足夠的代幣才能傳送 + require(amount <= balances[msg.sender], "餘額不足。"); - // 調整兩個帳戶的餘額 + // 調整兩個地址的代幣餘額 balances[msg.sender] -= amount; balances[receiver] += amount; - // 觸發之前定義的事件。 + // 發出先前定義的事件 emit Transfer(msg.sender, receiver, amount); } } @@ -311,74 +314,74 @@ contract Token { ```solidity pragma solidity ^0.5.10; -// 從其它文件向當前合約中導入符號 -// 本例使用一系列來自OpenZeppelin的輔助合約. -// 了解更多： https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files +// 從其他檔案將符號匯入到目前合約中。 +// 在此案例中，是來自 OpenZeppelin 的一系列輔助合約。 +// 深入了解：https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol"; import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol"; import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol"; -// `is` 關鍵字用於從其它外部合約繼承函數和關鍵字。 -// 本例中, `CryptoPizza` 繼承 `IERC721` 和 `ERC165` 合約. -// 了解更多： https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance +// `is` 關鍵字用於從外部合約繼承函數和關鍵字。 +// 在此案例中，`CryptoPizza` 繼承自 `IERC721` 和 `ERC165` 合約。 +// 深入了解：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance contract CryptoPizza is IERC721, ERC165 { - // 使用 OpenZeppelin's SafeMath 庫來安全執行算數操作。 - // 了解更多： https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath + // 使用 OpenZeppelin 的 SafeMath 程式庫來安全地執行算術運算。 + // 深入了解：https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath using SafeMath for uint256; - //Solidity語言中的常量（Constant）狀態變量與其他語言類似。 - // 但是必須用一個表達式為常量賦值，而這個表達式本身必須在編譯時是一個常量。 - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables + // Solidity 中的常數狀態變數與其他語言相似， + // 但您必須從一個在編譯時期為常數的運算式指派。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables uint256 constant dnaDigits = 10; uint256 constant dnaModulus = 10 ** dnaDigits; bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; - // Struct types let you define your own type - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs + // Struct 類型讓您可以定義自己的類型 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/types.html#structs struct Pizza { string name; uint256 dna; } - // Creates an empty array of Pizza structs + // 建立一個 Pizza 結構的空陣列 Pizza[] public pizzas; - // Mapping from pizza ID to its owner's address + // 從 pizza ID 到其擁有者地址的對應 mapping(uint256 => address) public pizzaToOwner; - // Mapping from owner's address to number of owned token + // 從擁有者地址到所擁有代幣數量的對應 mapping(address => uint256) public ownerPizzaCount; - // Mapping from token ID to approved address + // 從代幣 ID 到已核准地址的對應 mapping(uint256 => address) pizzaApprovals; - // You can nest mappings, this example maps owner to operator approvals + // 您可以巢狀化對應，此範例將擁有者對應到操作員核准 mapping(address => mapping(address => bool)) private operatorApprovals; - // Internal function to create a random Pizza from string (name) and DNA + // 從字串 (名稱) 和 DNA 建立隨機 Pizza 的內部函數 function _createPizza(string memory _name, uint256 _dna) - // The `internal` keyword means this function is only visible - // within this contract and contracts that derive this contract - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters + // `internal` 關鍵字表示此函數僅在此合約 + // 和衍生自此合約的合約中可見 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters internal - // `isUnique` is a function modifier that checks if the pizza already exists - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers + // `isUnique` 是一個函數修飾詞，用於檢查 pizza 是否已存在 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers isUnique(_name, _dna) { - // Adds Pizza to array of Pizzas and get id + // 將 Pizza 加入 Pizzas 陣列並取得 id uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1); - // Checks that Pizza owner is the same as current user - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + // 檢查 Pizza 擁有者是否與目前使用者相同 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - // note that address(0) is the zero address, - // indicating that pizza[id] is not yet allocated to a particular user. + // 請注意 address(0) 是零地址， + // 表示 pizza[id] 尚未分配給特定使用者。 assert(pizzaToOwner[id] == address(0)); - // Maps the Pizza to the owner + // 將 Pizza 對應到擁有者 pizzaToOwner[id] = msg.sender; ownerPizzaCount[msg.sender] = SafeMath.add( ownerPizzaCount[msg.sender], @@ -386,38 +389,38 @@ contract CryptoPizza is IERC721, ERC165 { ); } - // Creates a random Pizza from string (name) + // 從字串 (名稱) 建立隨機 Pizza function createRandomPizza(string memory _name) public { uint256 randDna = generateRandomDna(_name, msg.sender); _createPizza(_name, randDna); } - // Generates random DNA from string (name) and address of the owner (creator) + // 從字串 (名稱) 和擁有者 (建立者) 的地址產生隨機 DNA function generateRandomDna(string memory _str, address _owner) public - // Functions marked as `pure` promise not to read from or modify the state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions + // 標示為 `pure` 的函數保證不會讀取或修改狀態 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions pure returns (uint256) { - // Generates random uint from string (name) + address (owner) + // 從字串 (名稱) + 地址 (擁有者) 產生隨機 uint uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + uint256(_owner); rand = rand % dnaModulus; return rand; } - // Returns array of Pizzas found by owner + // 傳回由擁有者找到的 Pizzas 陣列 function getPizzasByOwner(address _owner) public - // Functions marked as `view` promise not to modify state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions + // 標示為 `view` 的函數保證不會修改狀態 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions view returns (uint256[] memory) { - // Uses the `memory` storage location to store values only for the - // lifecycle of this function call. - // 了解更多: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack + // 使用 `memory` 儲存位置來儲存僅在此函數呼叫 + // 的生命週期內有效的值。 + // 深入了解：https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack uint256[] memory result = new uint256[](ownerPizzaCount[_owner]); uint256 counter = 0; for (uint256 i = 0; i < pizzas.length; i++) { @@ -429,28 +432,28 @@ contract CryptoPizza is IERC721, ERC165 { return result; } - // 轉移 Pizza 和歸屬關係到其它地址 + // 將 Pizza 和所有權轉移到其他地址 function transferFrom(address _from, address _to, uint256 _pizzaId) public { - require(_from != address(0) && _to != address(0), "Invalid address."); - require(_exists(_pizzaId), "Pizza does not exist."); - require(_from != _to, "Cannot transfer to the same address."); - require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + require(_from != address(0) && _to != address(0), "無效地址。"); + require(_exists(_pizzaId), "Pizza 不存在。"); + require(_from != _to, "無法轉移到相同地址。"); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "地址未經核准。"); ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1); ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1); pizzaToOwner[_pizzaId] = _to; - // 觸發繼承自 IERC721 合約中定義的事件。 + // 發出匯入的 IERC721 合約中定義的事件 emit Transfer(_from, _to, _pizzaId); _clearApproval(_to, _pizzaId); } /** - * 安全轉帳給定代幣 ID 的所有權到其它地址 - * 如果目標地址是一個合約，則該合約必須實現 `onERC721Received`函數, - * 該函數調用了安全轉帳並且返回一個magic value。 - * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * 否則, 轉帳被回退. + * 安全地將指定代幣 ID 的所有權轉移到另一個地址 + * 如果目標地址是合約，則必須實作 `onERC721Received`， + * 它會在安全轉移時呼叫，並傳回魔術值 + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`； + * 否則，轉移將被還原。 */ function safeTransferFrom(address from, address to, uint256 pizzaId) public @@ -460,11 +463,11 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * 安全轉帳給定代幣ID所有權到其它地址 - * 如果目標地址是一個合約，則該合約必須實現`onERC721Received`函數, - * 該函數調用安全轉帳並返回一個magic value - * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * 否則，轉帳被回退. + * 安全地將指定代幣 ID 的所有權轉移到另一個地址 + * 如果目標地址是合約，則必須實作 `onERC721Received`， + * 它會在安全轉移時呼叫，並傳回魔術值 + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`； + * 否則，轉移將被還原。 */ function safeTransferFrom( address from, @@ -473,12 +476,12 @@ contract CryptoPizza is IERC721, ERC165 { bytes memory _data ) public { this.transferFrom(from, to, pizzaId); - require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received."); + require(_checkOnERC721Received(from, to, pizzaId, _data), "必須實作 onERC721Received。"); } /** - * Internal function to invoke `onERC721Received` on a target address - * The call is not executed if the target address is not a contract + * 在目標地址上叫用 `onERC721Received` 的內部函數 + * 如果目標地址不是合約，則不會執行此呼叫 */ function _checkOnERC721Received( address from, @@ -499,13 +502,13 @@ contract CryptoPizza is IERC721, ERC165 { return (retval == _ERC721_RECEIVED); } - // Burns a Pizza - destroys Token completely - // The `external` function modifier means this function is - // part of the contract interface and other contracts can call it + // 銷毀 Pizza - 完全摧毀代幣 + // `external` 函數修飾詞表示此函數是 + // 合約介面的一部分，其他合約可以呼叫它 function burn(uint256 _pizzaId) external { - require(msg.sender != address(0), "Invalid address."); - require(_exists(_pizzaId), "Pizza does not exist."); - require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + require(msg.sender != address(0), "無效地址。"); + require(_exists(_pizzaId), "Pizza 不存在。"); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "地址未經核准。"); ownerPizzaCount[msg.sender] = SafeMath.sub( ownerPizzaCount[msg.sender], @@ -514,58 +517,58 @@ contract CryptoPizza is IERC721, ERC165 { pizzaToOwner[_pizzaId] = address(0); } - // Returns count of Pizzas by address + // 依地址傳回 Pizzas 的計數 function balanceOf(address _owner) public view returns (uint256 _balance) { return ownerPizzaCount[_owner]; } - // Returns owner of the Pizza found by id + // 依 id 傳回找到的 Pizza 的擁有者 function ownerOf(uint256 _pizzaId) public view returns (address _owner) { address owner = pizzaToOwner[_pizzaId]; - require(owner != address(0), "Invalid Pizza ID."); + require(owner != address(0), "無效的 Pizza ID。"); return owner; } - // Approves other address to transfer ownership of Pizza + // 核准其他地址轉移 Pizza 的所有權 function approve(address _to, uint256 _pizzaId) public { - require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); + require(msg.sender == pizzaToOwner[_pizzaId], "必須是 Pizza 擁有者。"); pizzaApprovals[_pizzaId] = _to; emit Approval(msg.sender, _to, _pizzaId); } - // Returns approved address for specific Pizza + // 傳回特定 Pizza 的已核准地址 function getApproved(uint256 _pizzaId) public view returns (address operator) { - require(_exists(_pizzaId), "Pizza does not exist."); + require(_exists(_pizzaId), "Pizza 不存在。"); return pizzaApprovals[_pizzaId]; } /** - * Private function to clear current approval of a given token ID - * Reverts if the given address is not indeed the owner of the token + * 清除指定代幣 ID 目前核准的私有函數 + * 如果指定地址確實不是代幣的擁有者，則還原 */ function _clearApproval(address owner, uint256 _pizzaId) private { - require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); - require(_exists(_pizzaId), "Pizza does not exist."); + require(pizzaToOwner[_pizzaId] == owner, "必須是 pizza 擁有者。"); + require(_exists(_pizzaId), "Pizza 不存在。"); if (pizzaApprovals[_pizzaId] != address(0)) { pizzaApprovals[_pizzaId] = address(0); } } /* - * Sets or unsets the approval of a given operator - * An operator is allowed to transfer all tokens of the sender on their behalf + * 設定或取消設定指定操作員的核准 + * 操作員被允許代表傳送者轉移其所有代幣 */ function setApprovalForAll(address to, bool approved) public { - require(to != msg.sender, "Cannot approve own address"); + require(to != msg.sender, "無法核准自己的地址"); operatorApprovals[msg.sender][to] = approved; emit ApprovalForAll(msg.sender, to, approved); } - // Tells whether an operator is approved by a given owner + // 告知操作員是否已由指定擁有者核准 function isApprovedForAll(address owner, address operator) public view @@ -574,27 +577,27 @@ contract CryptoPizza is IERC721, ERC165 { return operatorApprovals[owner][operator]; } - // Takes ownership of Pizza - only for approved users + // 取得 Pizza 的所有權 - 僅限已核准的使用者 function takeOwnership(uint256 _pizzaId) public { - require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "地址未經核准。"); address owner = this.ownerOf(_pizzaId); this.transferFrom(owner, msg.sender, _pizzaId); } - // Checks if Pizza exists + // 檢查 Pizza 是否存在 function _exists(uint256 pizzaId) internal view returns (bool) { address owner = pizzaToOwner[pizzaId]; return owner != address(0); } - // Checks if address is owner or is approved to transfer Pizza + // 檢查地址是否為擁有者或已獲准轉移 Pizza function _isApprovedOrOwner(address spender, uint256 pizzaId) internal view returns (bool) { address owner = pizzaToOwner[pizzaId]; - // Disable solium check because of + // 因下列問題停用 solium 檢查 // https://github.com/duaraghav8/Solium/issues/175 // solium-disable-next-line operator-whitespace return (spender == owner || @@ -602,7 +605,7 @@ contract CryptoPizza is IERC721, ERC165 { this.isApprovedForAll(owner, spender)); } - // Check if Pizza is unique and doesn't exist yet + // 檢查 Pizza 是否獨一無二且尚不存在 modifier isUnique(string memory _name, uint256 _dna) { bool result = true; for (uint256 i = 0; i < pizzas.length; i++) { @@ -614,19 +617,17 @@ contract CryptoPizza is IERC721, ERC165 { result = false; } } - require(result, "Pizza with such name already exists."); + require(result, "具有此名稱的 Pizza 已存在。"); _; } - // Returns whether the target address is a contract + // 傳回目標地址是否為合約 function isContract(address account) internal view returns (bool) { uint256 size; - // Currently there is no better way to check if there is a contract in an address - // than to check the size of the code at that address. - // 參閱 https://ethereum.stackexchange.com/a/14016/36603 - // 了解更多信息. - // TODO： 在Serenity發布前再次檢查這裡, - // 否則到時所有地址都將判斷為合約. + // 目前沒有比檢查該地址的程式碼大小更好的方法來檢查地址中是否有合約。 + // 如需有關其運作方式的更多詳細資訊，請參閱 https://ethereum.stackexchange.com/a/14016/36603。 + // TODO 在 Serenity 發布前再次檢查，因為屆時所有地址都將是 + // 合約。 // solium-disable-next-line security/no-inline-assembly assembly { size := extcodesize(account) @@ -636,20 +637,20 @@ contract CryptoPizza is IERC721, ERC165 { } ``` -## 了解更多 {#further-reading} +## 延伸閱讀 {#further-reading} 請參閱 Solidity 和 Vyper 文件，獲得智慧型合約更完整的概觀： -- [Solidity](https://solidity.readthedocs.io/) -- [Vyper](https://vyper.readthedocs.io/) +- [Solidity](https://docs.soliditylang.org/) +- [Vyper](https://docs.vyperlang.org/en/stable/) ## 相關主題 {#related-topics} -- [智慧型合約](/developers/docs/smart-contracts/) +- [智能合約](/developers/docs/smart-contracts/) - [以太坊虛擬機](/developers/docs/evm/) ## 相關教學 {#related-tutorials} -- [縮減合約大小應對合約大小限制](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– 減少智慧型合約大小的實用秘訣。_ -- [用事件記錄智慧型合約資料](/developers/tutorials/logging-events-smart-contracts/) _ – 對智慧型合約事件進行介紹，以及如何使用事件來記錄資料。_ -- [與其他 Solidity 合約互動](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 如何從現有合約部署智慧型合約並與之互動。_ +- [縮減合約以克服合約大小限制](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– 一些縮減智能合約大小的實用技巧。_ +- [使用事件記錄智能合約的資料](/developers/tutorials/logging-events-smart-contracts/) _– 智能合約事件簡介，以及如何使用它們來記錄資料。_ +- [從 Solidity 與其他合約互動](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 如何從現有合約部署智能合約並與其互動。_ diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/compiling/index.md index 80e78208605..2048afbd166 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/compiling/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/compiling/index.md @@ -1,26 +1,26 @@ --- -title: 編譯智慧型合約 -description: 說明為什麼需要編譯智慧型合約以及編譯的實際作用。 +title: "編譯智慧型合約" +description: "說明為什麼需要編譯智慧型合約以及編譯的實際作用。" lang: zh-tw incomplete: true --- 你需要以網頁應用程式和以太坊虛擬機 (EVM) 能夠理解的方式編譯合約。 -## 基本資訊 {#prerequisites} +## 先決條件 {#prerequisites} -在閱讀關於編譯的文章前，先閱讀[智慧型合約](/developers/docs/smart-contracts/)及[以太坊虛擬機](/developers/docs/evm/)簡介可能對你有幫助。 +在閱讀關於編譯的內容之前，先閱讀我們的 [智能合約](/developers/docs/smart-contracts/) 和 [以太坊虛擬機](/developers/docs/evm/) 簡介可能會對您有幫助。 -## 以太坊虛擬機 {#the-evm} +## EVM {#the-evm} -若要讓[以太坊虛擬機](/developers/docs/evm/)能執行你的合約，合約需要以**位元組碼**格式編譯。 編譯會將以下程式碼： +為了讓 [EVM](/developers/docs/evm/) 能夠執行您的合約，合約必須是 **位元組碼**。 編譯會將以下程式碼： ```solidity pragma solidity 0.4.24; contract Greeter { - function greet() public constant returns (string) { + function greet() public view returns (string memory) { return "Hello"; } @@ -33,17 +33,17 @@ contract Greeter { PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900 ``` -這些稱為**操作碼**。 EVM 操作碼是以太坊虛擬機器 (EVM) 可以執行的低階指令。 每個操作碼代表一種特定的操作，例如算術運算、邏輯運算、資料操作、控制流程等。 +這些稱為 **操作碼**。 EVM 操作碼是以太坊虛擬機器 (EVM) 可以執行的低階指令。 每個操作碼代表一種特定的操作，例如算術運算、邏輯運算、資料操作、控制流程等。 -[有關操作碼的更多資訊](/developers/docs/evm/opcodes/) +[更多關於操作碼的資訊](/developers/docs/evm/opcodes/) ## Web 應用程式 {#web-applications} -編譯器還會生成**應用程式二進制介面 (ABI)**，你需要藉此讓應用程式理解你的合約，並調用合約函數。 +編譯器還會產生 **應用程式二進位介面 (ABI)**，您的應用程式需要此介面來了解合約並呼叫合約的函式。 ABI 是一個 JSON 格式檔案，描述了被部署的合約及其智慧型合約函數。 這有助於彌合 Web2 和 Web3 之間的差距 -[JavaScript 用戶端庫](/developers/docs/apis/javascript/)會讀取**應用程式二進制介面**，以便你在你的 Web 應用程式介面中調用智慧型合約。 +[JavaScript 用戶端程式庫](/developers/docs/apis/javascript/)將會讀取 **ABI**，以便您在 Web 應用程式介面中呼叫您的智能合約。 以下是 ERC-20 代幣合約的應用程式二進制介面。 ERC-20 是你可以在以太坊上交易的一種代幣。 @@ -272,11 +272,11 @@ ABI 是一個 JSON 格式檔案，描述了被部署的合約及其智慧型合 ] ``` -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} -- [應用程式二進制介面規範](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ +- [ABI 規格](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ ## 相關主題 {#related-topics} -- [JavaScript 用戶端庫](/developers/docs/apis/javascript/) +- [JavaScript 用戶端程式庫](/developers/docs/apis/javascript/) - [以太坊虛擬機](/developers/docs/evm/) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md index fd1cb8787fd..2a53ed9b4ef 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md @@ -1,13 +1,13 @@ --- -title: 智慧型合約的可組合性 -description: +title: "智慧型合約的可組合性" +description: "了解智能合約如何像樂高積木一樣組合，透過重複使用現有元件來建構複雜的去中心化應用程式。" lang: zh-tw incomplete: true --- ## 簡介 {#a-brief-introduction} -智慧型合約在以太坊上公開，類似於傳統網路世界中的 Open API。 你不一定需要編寫自己的智慧型合約才能成為一名去中心化應用程式的開發者，你只需要知道要怎樣與它們互動即可。 例如，你可以使用已存在的 [Uniswap](https://uniswap.exchange/swap)（一個去中心化的交易所）智慧型合約，來處理應用程式中的所有代幣交換邏輯 – 不需要從新開發一個。 歡迎查看其部分 [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) 及 [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts) 合約。 +智慧型合約在以太坊上公開，類似於傳統網路世界中的 Open API。 你不一定需要編寫自己的智慧型合約才能成為一名去中心化應用程式的開發者，你只需要知道要怎樣與它們互動即可。 例如，您可以使用去中心化交易所 [Uniswap](https://uniswap.exchange/swap) 現有的智能合約，來處理您應用程式中的所有代幣交換邏輯 — 您不需要從頭開始。 查看他們的一些 [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) 和 [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts) 合約。 ## 甚麼是可組合性？ {#what-is-composability} @@ -19,37 +19,37 @@ incomplete: true 以太坊上的智慧型合約就如同公開的應用程式介面 (API)，所有人都可以與合約互動，或把它整合到去中心化應用程式獲得新增的功能。 智慧型合約的可組合性通常遵循三個原則：模塊化、自主性和可發現性。 -**1. 模塊化**：這是指個別元件執行特定任務的能力。 在以太坊，每個智慧型合約都有特定的使用案例（如 Uniswap 範例所顯示）。 +\*\*1. **模組化**：這是指個別元件執行特定任務的能力。 在以太坊，每個智慧型合約都有特定的使用案例（如 Uniswap 範例所顯示）。 -**2. 自主性**：可組合的元件必需要有獨立運作的能力。 以太坊上的每一個智慧型合約都能自我執行，且可以在不依賴系統其他部分的情況下運作。 +\*\*2. **自主性**：可組合的元件必須能夠獨立運作。 以太坊上的每一個智慧型合約都能自我執行，且可以在不依賴系統其他部分的情況下運作。 -**3. 可發現性**：如果外部合約和軟體程式庫不是公開可用的，開發者就無法調用它們或將其整合到應用程式中。 智慧型合約被設計成開放原始碼，任何人都可以調用智慧型合約或分叉一個程式碼庫。 +\*\*3. **可發現性**：如果外部合約或軟體程式庫不是公開可用的，開發人員就無法呼叫它們或將其整合到應用程式中。 智慧型合約被設計成開放原始碼，任何人都可以調用智慧型合約或分叉一個程式碼庫。 -## 可組合性的好處 {#benefits-of-composability} +## 可組合性的優點 {#benefits-of-composability} ### 更短的開發週期 {#shorter-development-cycle} -可組合性減少了開發者在建立[去中心化應用程式 (dapp) ](/apps/#what-are-dapps)時需要做的工作。 [正如 Naval Ravikant 所說的：](https://twitter.com/naval/status/1444366754650656770)「開放原始碼意指所有問題都只需要解決一遍。」 +可組合性減少了開發人員在建立[去中心化應用程式](/apps/#what-are-dapps)時所需的工作量。 [正如 Naval Ravikant 所說：](https://twitter.com/naval/status/1444366754650656770) "開放原始碼意味著每個問題只需要解決一次。" 如果有一個智慧型合約解決了某個問題，其他開發者便可以重複使用它，所以他們便不必再解決同一個問題。 這樣，開發者可以使用現有的軟體程式庫並增加額外的功能，以建立新的去中心化應用程式 (dapp)。 -### 更大的創新 {#greater-innovation} +### 更強的創新能力 {#greater-innovation} 可組合性鼓勵創新和實驗，因為開發者可以自由地重複使用、修改、複製或整合開放原始程式碼以達到所需的效果。 因此，開發團隊可以花費更少時間在基本功能上，且可以分配更多的時間進行新功能的實驗。 -### 更好的使用者體驗 {#better-user-experience} +### 更佳的使用者體驗 {#better-user-experience} 以太坊生態系統元件之間的互通性提高了使用者體驗。 當去中心化應用程式 (dapp) 整合外部智慧型合約時，使用者可以獲得更多功能，而在一個分散的生態系統中，應用程式無法通訊，功能就會受限。 我們將使用套利交易的一個範例來說明互通性的好處： -如果一個代幣在 `exchange A` 的交易價格高於 `exchange B`，你可以利用價格差異來獲利。 但是，若要這麼做，你必須有足夠的資本完成交易（如：在 `exchange B` 買入代幣並在 `exchange A` 賣出）。 +如果一個代幣在 `exchange A` 的交易價格高於 `exchange B`，您可以利用價差獲利。 然而，只有在您有足夠的資本為交易提供資金時，才能這麼做 (亦即，從 `exchange B` 購買代幣，然後在 `exchange A` 賣出)。 -在你沒有足夠資金來完成這筆交易的情境下，閃電貸可能是一個理想的選擇。 [閃電貸](/defi/#flash-loans)技術性很高，但它的基本概念是你可以借用資產（不需抵押）並在_一_筆交易內把它歸還。 +在你沒有足夠資金來完成這筆交易的情境下，閃電貸可能是一個理想的選擇。 [閃電貸](/defi/#flash-loans) 的技術性很強，但基本概念是您可以在 _單一_ 筆交易中借入資產 (無須抵押品) 並歸還。 -回到我們一開始的範例，一個套利交易者可以借一筆大額的閃電貸，於同一筆交易中從 `exchange B` 買入代幣，然後在 `exchange A` 賣出，把資本和利息歸返，並把利潤留下。 這個複雜的邏輯需要組合多個智慧型合約的調用，而如果智慧型合約缺乏互通性，這將是不可能的。 +回到我們最初的例子，套利交易者可以在同一筆交易中，借入大額閃電貸，從 `exchange B` 購買代幣，在 `exchange A` 賣出，償還本金和利息，並保留利潤。 這個複雜的邏輯需要組合多個智慧型合約的調用，而如果智慧型合約缺乏互通性，這將是不可能的。 -## 以太坊裡可組合性的範例 {#composability-in-ethereum} +## 以太坊中可組合性的範例 {#composability-in-ethereum} ### 代幣交換 {#token-swaps} @@ -57,20 +57,20 @@ incomplete: true ### 管理體系 {#governance} -為[去中心化自治組織 (DAO) ](/dao/)建置定制的管理體系可能既昂貴又耗時。 相反，你可以使用開放原始碼的管理體系工具包，例如 [Aragon Client](https://client.aragon.org/)，來快速為你的去中心化自治組織 (DAO) 建立一個管理體系框架。 +為 [DAO](/dao/) 建立客製化的管理體系可能既昂貴又耗時。 或者，您也可以使用開放原始碼的管理體系工具組，例如 [Aragon Client](https://client.aragon.org/)，來啟動您的 DAO，以快速建立一個管理體系框架。 ### 身分管理 {#identity-management} -你可以整合去中心化身分 ( DID) 工具來管理使用者的認證，而不是建置一個自訂的驗證系統或依賴中心化的服務提供商。 一個範例是 [SpruceID](https://www.spruceid.com/)，這是一個提供「使用以太坊登入」功能的開放原始碼工具包，讓使用者能使用以太坊錢包進行身分驗證。 +你可以整合去中心化身分 ( DID) 工具來管理使用者的認證，而不是建置一個自訂的驗證系統或依賴中心化的服務提供商。 其中一個範例是 [SpruceID](https://www.spruceid.com/)，它是一個開放原始碼的工具組，提供"使用以太坊登入"功能，讓使用者能使用以太坊錢包驗證身分。 -## 相關教程 {#related-tutorials} +## 相關教學 {#related-tutorials} -- [使用 creat-eth-app 開始去中心化應用程式 (dapp) 前端開發](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/)_ – 關於如何使用 creat-eth-app，透過立即可用的熱門智慧型合約建立應用程式的概覽_。 +- [使用 create-eth-app 快速啟動您的去中心化應用程式前端開發](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _— 概述如何使用 create-eth-app，透過現成即用的熱門智能合約來建立應用程式。_ -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} -_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_ +_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容！_ -- [可組合性是創新](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/) -- [為甚麼可組合性對 Web3 很重要](https://hackernoon.com/why-composability-matters-for-web3) -- [甚麼是可組合性？](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) +- [可組合性即創新](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/) +- [為何可組合性對 Web3 至關重要](https://hackernoon.com/why-composability-matters-for-web3) +- [什麼是可組合性？](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/deploying/index.md index 3538cca8356..bbc49d4ea6a 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/deploying/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/deploying/index.md @@ -1,6 +1,6 @@ --- -title: 部署智慧型合約 -description: +title: "部署智慧型合約" +description: "了解如何將智能合約部署至以太坊網路，包括先決條件、工具和部署步驟。" lang: zh-tw --- @@ -8,74 +8,74 @@ lang: zh-tw 要部署智慧型合約，只需要傳送一個包含編譯後智慧型合約程式碼的以太坊交易，而無須指定任何接收者。 -## 基本資訊 {#prerequisites} +## 先決條件 {#prerequisites} -在部署智慧型合約前，你需要理解[以太坊網路](/developers/docs/networks/)、[交易](/developers/docs/transactions/)與[智慧型合約結構](/developers/docs/smart-contracts/anatomy/)。 +在部署智能合約之前，您應先了解 [以太坊網路](/developers/docs/networks/)、[交易](/developers/docs/transactions/) 和 [智能合約的結構](/developers/docs/smart-contracts/anatomy/)。 -部署合約同樣需要花費以太幣 (ETH)，因為合約會儲存在區塊鏈上，所以你應該熟悉以太坊的[燃料與手續費](/developers/docs/gas/)。 +部署合約也需要花費以太幣 (ETH)，因為它們會儲存在區塊鏈上，所以您應該熟悉以太坊上的 [gas 和費用](/developers/docs/gas/)。 -最後，你需要在部署前編譯合約，所以請確保你已閱讀[編譯智慧型合約](/developers/docs/smart-contracts/compiling/)。 +最後，在部署合約之前，您需要先編譯合約，所以請確定您已閱讀有關 [編譯智能合約](/developers/docs/smart-contracts/compiling/) 的內容。 -## 如何部署智慧型合約 {#how-to-deploy-a-smart-contract} +## 如何部署智能合約 {#how-to-deploy-a-smart-contract} -### 需要準備: {#what-youll-need} +### 您需要準備什麼 {#what-youll-need} -- 合約的位元組碼 – 這是透過[編譯](/developers/docs/smart-contracts/compiling/)產生的 +- 您的合約位元組碼 – 這是透過 [編譯](/developers/docs/smart-contracts/compiling/) 產生的 - 可作為燃料的以太幣 – 像其他交易一樣，你需要設定燃料限制，所以請注意合約部署需要比簡單的以太幣傳送花費更多燃料 - 一個部署腳本或外掛程式 -- 存取[以太坊節點](/developers/docs/nodes-and-clients/)，你可以透過執行自己的節點、連結公共節點，或透過應用程式介面金鑰使用[節點服務](/developers/docs/nodes-and-clients/nodes-as-a-service/)來存取。 +- 存取 [以太坊節點](/developers/docs/nodes-and-clients/) 的權限，可以透過執行自己的節點、連線到公用節點，或透過使用 [節點服務](/developers/docs/nodes-and-clients/nodes-as-a-service/) 的 API 金鑰來達成 -### 部署智慧型合約的步驟 {#steps-to-deploy} +### 部署智能合約的步驟 {#steps-to-deploy} -所涉具體步驟仰賴所用的開發框架。 例如，你可以查看 [Hardhat 有關部署合約的文件](https://hardhat.org/docs/tutorial/deploying)或 [Foundry 有關部署和驗證智慧型合約的文件](https://book.getfoundry.sh/forge/deploying)。 部署後，你的合約會跟其他[帳戶](/developers/docs/accounts/)一樣擁有以太坊地址，並且可以使用[原始程式碼驗證工具](/developers/docs/smart-contracts/verifying/#source-code-verification-tools)進行驗證。 +所涉具體步驟仰賴所用的開發框架。 例如，您可以查看 [Hardhat 有關部署您的合約的文件](https://hardhat.org/docs/tutorial/deploying) 或 [Foundry 有關部署和驗證智能合約的文件](https://book.getfoundry.sh/forge/deploying)。 部署之後，您的合約將會有一個像其他 [帳戶](/developers/docs/accounts/) 一樣的以太坊地址，並可使用 [原始碼驗證工具](/developers/docs/smart-contracts/verifying/#source-code-verification-tools) 進行驗證。 ## 相關工具 {#related-tools} -**Remix - _Remix 整合開發環境允許開發、部署和管理類似區塊鏈的以太坊智慧型合約_** +**Remix - _Remix IDE 允許為以太坊之類的區塊鏈開發、部署和管理智能合約_** - [Remix](https://remix.ethereum.org) -**Tenderly - _Web3 開發平台，提供了開發、測試、監控和營運智慧型合約所需的偵錯、可觀察性和基礎架構組件_** +**Tenderly - _Web3 開發平台，提供了開發、測試、監控和營運智能合約所需的偵錯、可觀察性和基礎架構組件_** - [tenderly.co](https://tenderly.co/) - [文件](https://docs.tenderly.co/) -- [Github](https://github.com/Tenderly) +- [GitHub](https://github.com/Tenderly) - [Discord](https://discord.gg/eCWjuvt) -**Hardhat - _用於編譯、部署、測試和偵錯以太坊軟體的開發環境_** +**Hardhat - _一個用於編譯、部署、測試和偵錯您的以太坊軟體的開發環境_** - [hardhat.org](https://hardhat.org/getting-started/) -- [合約部署文件](https://hardhat.org/docs/tutorial/deploying) -- [Github](https://github.com/nomiclabs/hardhat) +- [有關部署您的合約的文件](https://hardhat.org/docs/tutorial/deploying) +- [GitHub](https://github.com/nomiclabs/hardhat) - [Discord](https://discord.com/invite/TETZs2KK4k) -**Web3 - _使用一條指令輕鬆部署任何合約至任何與以太坊虛擬機相容的區塊鏈_** +**thirdweb - _使用單一指令，輕鬆將任何合約部署至任何 EVM 相容鏈_** - [文件](https://portal.thirdweb.com/deploy/) -**Crossmint - _企業級 web3 開發平台，用於部署智慧型合約，支援信用卡和跨鏈支付，並使用應用程式介面來建立、分發、銷售、儲存和編輯非同質化代幣。_** +**Crossmint - _企業級 Web3 開發平台，可用於部署智能合約、啟用信用卡和跨鏈支付，並使用 API 建立、分發、銷售、儲存和編輯 NFT。_** - [crossmint.com](https://www.crossmint.com) - [文件](https://docs.crossmint.com) - [Discord](https://discord.com/invite/crossmint) - [部落格](https://blog.crossmint.com) -## 相關教程 {#related-tutorials} +## 相關教學 {#related-tutorials} -- [部署你的第一個智慧型合約](/developers/tutorials/deploying-your-first-smart-contract/)_ – 如何在以太坊測試網部署你的第一個智慧型合約。_ -- [Hello World | 智慧型合約使用教學](/developers/tutorials/hello-world-smart-contract/) _ – 在以太坊建立與部署基本智慧型合約的簡單使用教學。_ -- [與其他 Solidity 合約互動](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 如何從現有合約部署智慧型合約並與之互動。_ -- [如何壓縮智慧型合約大小](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/)_ - 如何壓縮智慧型合約大小至限制以下來降低燃料費_ +- [部署您的第一個智能合約](/developers/tutorials/deploying-your-first-smart-contract/) _– 在以太坊測試網路上部署您的第一個智能合約的簡介。_ +- [Hello World | 智能合約教學](/developers/tutorials/hello-world-smart-contract/) _– 一個在以太坊上建立和部署基本智能合約的簡易教學。_ +- [從 Solidity 與其他合約互動](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 如何從現有合約部署智能合約並與其互動。_ +- [如何縮減您的合約大小](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- 如何縮減您的合約大小，以使其保持在限制之下並節省 gas_ -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} - [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_ -- [利用 Hardhat 來部署合約](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ +- [使用 Hardhat 部署您的合約](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ -_知道對你有幫助的社群資源嗎？ 請編輯此頁面並新增資源！_ +_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容！_ ## 相關主題 {#related-topics} -- [開發架構](/developers/docs/frameworks/) -- [運行以太坊節點](/developers/docs/nodes-and-clients/run-a-node/) +- [開發框架](/developers/docs/frameworks/) +- [執行以太坊節點](/developers/docs/nodes-and-clients/run-a-node/) - [節點即服務](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md index 8ccf8da3971..751d462cd3f 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md @@ -1,12 +1,12 @@ --- -title: 智慧型合約的形式化驗證 -description: 以太坊智慧型合約形式化驗證概覽 +title: "智慧型合約的形式化驗證" +description: "以太坊智慧型合約形式化驗證概覽" lang: zh-tw --- -[智慧型合約](/developers/docs/smart-contracts/)讓建立去中心化、去信任且穩健的應用程式，來引進新的應用案例並解放使用者的價值變得更加可行。 因為智慧型合約掌握了大量的價值，所以對開發者來說，安全是最關鍵的考量。 +[智能合約](/developers/docs/smart-contracts/) 讓建立去中心化、去信任且穩健的應用程式成為可能，不僅帶來新的使用案例，也為使用者釋放價值。 因為智慧型合約掌握了大量的價值，所以對開發者來說，安全是最關鍵的考量。 -形式化驗證是增進[智慧型合約安全](/developers/docs/smart-contracts/security/)的其中一種推薦方法。 形式化驗證是一種使用多年的方法，採用[形式化方法](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/)來規範、設計和驗證程式，目的是要確保關鍵硬體與軟體系統的正確性。 +形式化驗證是提升 [智能合約安全](/developers/docs/smart-contracts/security/) 的推薦技術之一。 形式化驗證採用 [形式化方法](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) 來指定、設計和驗證程式，多年來一直用來確保關鍵硬體和軟體系統的正確性。 當在智慧型合約中實作形式化驗證時，可以證明合約的商業邏輯符合預先定義的規範。 相較於其他評估合約程式碼正確性的方法，形式化驗證更能保證智慧型合約功能性上的正確。 @@ -18,81 +18,81 @@ lang: zh-tw ### 形式化模型是什麼？ {#what-is-a-formal-model} -在電腦科學中，[形式化模型](https://en.wikipedia.org/wiki/Model_of_computation)是指對計算過程的數學描述。 程式被抽象成數學函式（方程），模型則描述了給定輸入時如何計算函式的輸出。 +在電腦科學中，[形式化模型](https://en.wikipedia.org/wiki/Model_of_computation) 是計算過程的數學描述。 程式被抽象成數學函式（方程），模型則描述了給定輸入時如何計算函式的輸出。 -形式化模型提供了一個抽象層次，可以在該抽象層次上對程式行為的分析進行評估。 有了形式化模型，_形式化規範_得以建立，用來描述所涉模型所需要的屬性。 +形式化模型提供了一個抽象層次，可以在該抽象層次上對程式行為的分析進行評估。 形式化模型的存在，讓人得以建立_形式化規範_，用來描述相關模型所需的屬性。 採用不同的技術來建立智慧型合約模型，以便進行形式化驗證。 例如，有些模型用來推理智慧型合約的高階行為。 這些模型建立技術對智慧型合約套用黑盒檢視，把智慧型合約視為可以接受輸入並按照那些輸入執行計算的系統。 高階模型專注在智慧型合約與外部代理，例如外部帳戶 (EOA)、合約帳戶和區塊鏈環境，之間的關係。 這些模型有助於定義屬性，規定合約該如何回應某些使用者互動的行為。 -相反地，其他形式化模型專注於智慧型合約的低階行為。 雖然高階模型有助於推理合約的功能，它們可能無法擷取實作內部運作的細節。 低階模型對程式分析應用白盒檢視，並仰賴智慧型合約應用程式的較低階表示，例如程式追蹤和[控制流圖](https://en.wikipedia.org/wiki/Control-flow_graph)，來推理與合約執行相關的屬性。 +相反地，其他形式化模型專注於智慧型合約的低階行為。 雖然高階模型有助於推理合約的功能，它們可能無法擷取實作內部運作的細節。 低階模型將白箱觀點應用於程式分析，並依賴智能合約應用程式的較低階表示法 (例如程式追蹤和 [控制流程圖](https://en.wikipedia.org/wiki/Control-flow_graph))，來推斷與合約執行相關的屬性。 -低階模型被認爲是理想的，因爲它們代表了智慧型合約在以太坊執行環境（即[以太坊虛擬機](/developers/docs/evm/)）中的實際執行。 低階模型建立技術對於在智慧型合約中建立關鍵的安全屬性和偵測潛在漏洞尤其有用。 +低階模型被認為是理想的，因為它們代表了智能合約在以太坊執行環境 (即 [EVM](/developers/docs/evm/)) 中的實際執行。 低階模型建立技術對於在智慧型合約中建立關鍵的安全屬性和偵測潛在漏洞尤其有用。 ### 什麽是形式化規範？ {#what-is-a-formal-specification} 規範不過是特定系統必須滿足的技術要求。 在編程中，規範代表程式執行的總體思路（即程式應該做什麽）。 -在智慧型合約的背景下，形式化規範指的是_屬性_—合約必須滿足的要求的形式化描述。 這樣的屬性被描述爲「不變量」，並代表了關於合約執行的邏輯斷言，該斷言在任何情況下都必須為 true，沒有例外。 +在智能合約的脈絡中，形式化規範指的是「屬性」—也就是合約必須滿足之條件的形式化描述。 這樣的屬性被描述爲「不變量」，並代表了關於合約執行的邏輯斷言，該斷言在任何情況下都必須為 true，沒有例外。 因此，我們可以將形式化規範想做是用形式化語言編寫的陳述式集合，描述了智慧型合約的預期執行。 規範涵蓋了合約的屬性，並定義了合約在各種情況下應該如何運作。 形式化驗證的目的是確定智慧型合約是否具備這些屬性（不變量）以及在執行過程中不會違反這些屬性。 形式化規範對於開發智慧型合約的安全實作至關重要。 無法實作不變量或在執行期間違反其屬性的合約容易出現漏洞，可能會損害合約功能或導致合約遭到惡意利用。 -## 智慧型合約形式化規範的類型 {#formal-specifications-for-smart-contracts} +## 智能合約的形式化規範類型 {#formal-specifications-for-smart-contracts} 形式化規範使程式執行的正確性可以用數學方法進行推理。 與形式化模型一樣，形式化規範可以擷取合約實作的高階屬性或低階行爲。 -形式化規範是由[程式邏輯](https://en.wikipedia.org/wiki/Logic_programming)的元素推導出，透過這些元素可以對程式的屬性做形式化推理。 程式邏輯採用形式化規則來（用數學語言）表達程序的預期行為。 形式化規範可以使用各種程式邏輯來建立，包括[可達性邏輯](https://en.wikipedia.org/wiki/Reachability_problem)、[時間邏輯](https://en.wikipedia.org/wiki/Temporal_logic)以及[霍爾邏輯](https://en.wikipedia.org/wiki/Hoare_logic)。 +形式化規範是利用 [程式邏輯](https://en.wikipedia.org/wiki/Logic_programming) 的元素推導而來，程式邏輯可讓人對程式的屬性進行形式化推理。 程式邏輯採用形式化規則來（用數學語言）表達程序的預期行為。 建立形式化規範時，會用到各種程式邏輯，包括 [可達性邏輯](https://en.wikipedia.org/wiki/Reachability_problem)、[時序邏輯](https://en.wikipedia.org/wiki/Temporal_logic) 及 [霍爾邏輯](https://en.wikipedia.org/wiki/Hoare_logic)。 -智慧型合約的形式規範大致上可分成**高階**或**低階**規範。 無論規範屬於什麽類別，都必須充分且明確地描述所分析之系統的屬性。 +智能合約的形式化規範可大致分為**高階**或**低階**規範。 無論規範屬於什麽類別，都必須充分且明確地描述所分析之系統的屬性。 ### 高階規範 {#high-level-specifications} -顧名思義，高階規範（也被稱爲「模型導向規範」）描述程式的高階行爲。 高階規範將智慧型合約建模為[有限狀態機器](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM)，它能夠透過執行操作來轉換狀態，並使用時間邏輯來為有限狀態機器模型定義形式化屬性。 +顧名思義，高階規範（也被稱爲「模型導向規範」）描述程式的高階行爲。 高階規範將智能合約模型化為 [有限狀態機](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM)，此狀態機可藉由執行運算在不同狀態之間轉換，並以時序邏輯定義 FSM 模型的形式化屬性。 -[時間邏輯](https://en.wikipedia.org/wiki/Temporal_logic)是「時間限定命題的推理規則（例如，「我 _總是_很餓」，或「我_最終_會餓」）」。 當應用於形式化驗證時，時間邏輯被用來聲明關於建模為狀態機器的正確系統行為的斷言。 具體來說，時間邏輯描述智慧型合約可以進入的未來狀態，以及它如何在狀態之間轉換。 +[時序邏輯](https://en.wikipedia.org/wiki/Temporal_logic) 是「針對以時間限定之命題進行推理的規則 (例如：「我『總是』很餓」或「我『最終』會餓」)」。 當應用於形式化驗證時，時間邏輯被用來聲明關於建模為狀態機器的正確系統行為的斷言。 具體來說，時間邏輯描述智慧型合約可以進入的未來狀態，以及它如何在狀態之間轉換。 -高階規範通常擷取智慧型合約的兩個關鍵時間屬性：**安全**和**活躍性**。 安全屬性代表「任何壞事都不會發生」的想法，且通常表達不變量。 安全屬性可以定義一般軟體要求，例如免於[死鎖](https://www.techtarget.com/whatis/definition/deadlock)或表達合約的領域特有屬性（如函式存取控制的不變量、狀態變數的容許值或代幣轉賬的條件）。 +高階規範通常會捕捉智能合約的兩個關鍵時序屬性：**安全**和**活躍性**。 安全屬性代表「任何壞事都不會發生」的想法，且通常表達不變量。 安全屬性可定義一般軟體需求，例如不受 [死結](https://www.techtarget.com/whatis/definition/deadlock) 影響，或表達合約的領域特定屬性 (例如：函數存取控制的不變量、狀態變數的容許值，或代幣傳送的條件)。 -以下方安全要求為例，其描述了在 ERC-20 代幣合約中使用 `transfer()` 或 `transferFrom()` 的條件：_「發送者的餘額決不可少於要求發送的代幣金額」_。 這種合約不變量的自然語言描述可以轉化為形式化（數學）規範，以進行嚴格的有效性檢查。 +以這項涵蓋 ERC-20 代幣合約中 `transfer()` 或 `transferFrom()` 使用條件的安全需求為例：_「傳送者的餘額絕不低於要求傳送的代幣數量。」_。 這種合約不變量的自然語言描述可以轉化為形式化（數學）規範，以進行嚴格的有效性檢查。 -活躍性屬性斷言「好事終將發生」，並涉及合約逐步通過不同狀態的能力。 活躍性屬性的一個例子是「流動性」，代表一個合約在收到要求時將其餘額轉帳給使用者的能力。 如果違反該屬性，使用者就無法提取存儲在合約中的資產，就像 [Parity 錢包事件](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html)中發生的那樣。 +活躍性屬性斷言「好事終將發生」，並涉及合約逐步通過不同狀態的能力。 活躍性屬性的一個例子是「流動性」，代表一個合約在收到要求時將其餘額轉帳給使用者的能力。 如果違反此屬性，使用者將無法提領儲存在合約中的資產，就像 [Parity 錢包事件](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) 一樣。 ### 低階規範 {#low-level-specifications} 高階規範以合約的有限狀態模型作為起點，並定義該模型所需的屬性。 相較之下，低階規範（也稱為「屬性導向規範」）通常將程式（智慧型合約）建模成由數學函式集合組成的系統，並描述這類系統的正確行為。 -簡單來説，低階規範分析_程式追蹤_並試圖透過這些追蹤定義智慧型合約的屬性。 追蹤是指改變智慧型合約狀態的函式執行序列；因此，低階規範幫助指定合約内部執行的要求。 +簡單來說，低階規範會分析_程式追蹤_，並試圖透過這些追蹤來定義智能合約的屬性。 追蹤是指改變智慧型合約狀態的函式執行序列；因此，低階規範幫助指定合約内部執行的要求。 低階形式化規範可以出具為霍爾式屬性或執行路徑中的不變量。 ### 霍爾式屬性 {#hoare-style-properties} -[霍爾邏輯](https://en.wikipedia.org/wiki/Hoare_logic)提供了一套形式化規則，用於推理包括智慧型合約等程式的正確性。 A Hoare-style property is represented by a Hoare triple \{_P_}_c_\{_Q_}, where _c_ is a program and _P_ and _Q_ are predicates on the state of the _c_ (i.e., the program), formally described as _preconditions_ and _postconditions_, respectively. +[霍爾邏輯](https://en.wikipedia.org/wiki/Hoare_logic) 提供了一套形式化規則，用以推斷包括智能合約在內之程式的正確性。 霍爾式屬性由霍爾三元組 `{P}c{Q}` 表示，其中 `c` 是程式，`P` 和 `Q` 是 `c` (即程式) 的狀態述詞，分別被正式描述為_前置條件_和_後置條件_。 -前置條件是描述正確執行函式所需條件的述詞；叫用合約的使用者必須滿足該要求。 後置條件是描述函式正確執行時所建立之條件的述詞；使用者在叫用函式後可以預計該條件為 true。 在霍爾邏輯中，_不變量_是指透過執行函式保留的述詞（即，它不會改變）。 +前置條件是描述正確執行函式所需條件的述詞；叫用合約的使用者必須滿足該要求。 後置條件是描述函式正確執行時所建立之條件的述詞；使用者在叫用函式後可以預計該條件為 true。 在霍爾邏輯中，_不變量_是執行函數時會保留下來的述詞 (即，它不會改變)。 -霍爾式規範可以保證_部分正確性_或_完全正確性_。 如果前置條件在函式執行之前為 true，並且如果執行終止，後置條件也爲 true，則合約函式的實作為「部分正確」。 如果前置條件在函式執行之前為 true，執行被保證終止且實際終止時，後置條件為 true，則會獲得完全正確性證明。 +霍爾式規範可保證_部分正確性_或_完全正確性_。 如果前置條件在函式執行之前為 true，並且如果執行終止，後置條件也爲 true，則合約函式的實作為「部分正確」。 如果前置條件在函式執行之前為 true，執行被保證終止且實際終止時，後置條件為 true，則會獲得完全正確性證明。 獲得完全正確性證明很難，因為一些執行在終止前可能會延遲，或根本不會終止。 也就是説，由於以太坊的燃料機制會防止無限程式迴圈（執行要麼成功終止，要麼因為「燃料耗盡」錯誤而終止），執行是否會終止可以説是一個有爭議的問題。 使用霍爾邏輯建立的智慧型合約規範會具有前置條件、後置條件以及為執行合約中的函式和迴圈而定義的不變量。 前置條件通常包括函式輸入錯誤的可能性，後置條件則描述對此類輸入的預期回應（例如，抛出一個特定例外狀況）。 用這種方式，霍爾式屬性可以很有效地確保合約實作的正確性。 -許多形式化驗證框架使用霍爾式規範來證明函式的語義正確性。 也可以透過使用 Solidity 中的 `require` 和 `assert` 陳述式，直接向合約程式碼新增霍爾式屬性（做為斷言）。 +許多形式化驗證框架使用霍爾式規範來證明函式的語義正確性。 也可以在 Solidity 中使用 `require` 和 `assert` 陳述式，將霍爾式屬性 (作為斷言) 直接新增至合約程式碼中。 -`require` 陳述式表達前置條件或不變量，並且通常用於驗證使用者輸入，而 `assert` 則會擷取一個安全必要的後置條件。 例如，可以使用 `require` 做為前置條件檢查呼叫帳戶的身分，來實現正確的函式存取控制（安全屬性的一個範例）。 相似地，透過在函式執行后使用 `assert` 確認合約的狀態，可以防止違反合約中狀態變數許可值的不變量（例如，流通中的代幣總數）。 +`require` 陳述式表達了前置條件或不變量，通常用來驗證使用者輸入，而 `assert` 則捕捉了確保安全所需的後置條件。 舉例來說，可以使用 `require` 作為呼叫帳戶身分的前置條件檢查，來達成適當的函數存取控制 (安全屬性的一例)。 同樣地，可藉由在函數執行後使用 `assert` 確認合約狀態，保護合約中狀態變數的容許值 (例如，流通中的代幣總數) 的不變量免遭違反。 ### 追蹤層級屬性 {#trace-level-properties} 基於追蹤的規範描述了在不同狀態之間轉換合約的操作以及這些操作之間的關係。 如前所述，追蹤是以特定方式改變合約狀態的操作序列。 -該方法依賴於智慧型合約模型做為狀態轉換系統，該系統具有一些預定義屬性（由狀態變數描述）以及一組預定義轉換（由合約函式描述）。 此外，[控制流程圖](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG)，即程式執行流程的圖形化表示，常常用於描述合約的操作語義。 在這裡，每個追蹤代表控制流程圖上的一條路徑。 +該方法依賴於智慧型合約模型做為狀態轉換系統，該系統具有一些預定義屬性（由狀態變數描述）以及一組預定義轉換（由合約函式描述）。 此外，[控制流程圖 (CFG)](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) 是程式執行流程的圖形化表示，常用來描述合約的操作語義。 在這裡，每個追蹤代表控制流程圖上的一條路徑。 追蹤層級規範主要用來推理智慧型合約中的內部執行模式。 透過建立追蹤層級規範，我們斷言一個智慧型合約的容許執行路徑（即，狀態轉換）。 使用類似於符號執行的技術，我們可以從形式上驗證執行永遠不會追隨未在形式化模型中定義的路徑。 -我們使用一個已具有一些公開可存取函式的[去中心化自治組織 (DAO)](/dao/) 合約做為範例，介紹追蹤層級屬性。 在這裡，我們假設去中心化自治組織 (DAO) 合約允許使用者執行以下操作： +讓我們以一個具有一些公開可存取函數的 [DAO](/dao/) 合約為例，來描述追蹤層級的屬性。 在這裡，我們假設去中心化自治組織 (DAO) 合約允許使用者執行以下操作： - 存入資金 @@ -100,19 +100,19 @@ lang: zh-tw - 在沒有對提案投票的情況下申請退款 -追蹤層級屬性的範例可以是_「沒有存入資金的使用者無法對提案進行投票」_或_「沒有對提案進行投票的使用者應該一律能夠申請退款」_。 這兩個屬性斷言均優先執行順序（存入資金_之前_不能進行投票，以及對提案進行投票_之後_不能申請退款）。 +追蹤層級屬性的範例可以是_「未存入資金的使用者無法對提案投票」_或_「未對提案投票的使用者應一律能申請退款」_。 這兩種屬性都斷言了偏好的執行順序 (投票不能在存入資金_之前_發生，申請退款不能在對提案投票_之後_發生)。 -## 智慧型合約的形式化驗證技術 {#formal-verification-techniques} +## 智能合約的形式化驗證技術 {#formal-verification-techniques} ### 模型檢查 {#model-checking} 模型檢查是一種形式化驗證技術，使用演算法對照規範檢查智慧型合約的形式化模型。 在模型檢查中，智慧型合約通常表示爲狀態轉換系統，同時使用時間邏輯來定義許可合約狀態屬性。 -模型檢查需要建立系統的抽象數學表示（即合約），並使用根植於[命題邏輯](https://www.baeldung.com/cs/propositional-logic)的公式來表示該系統的屬性。 這樣簡化了模型檢查演算法的工作，也就是說證明數學模型符合給定的邏輯公式。 +模型檢查需要建立系統 (即合約) 的抽象數學表示，並使用以 [命題邏輯](https://www.baeldung.com/cs/propositional-logic) 為基礎的公式來表達此系統的屬性。 這樣簡化了模型檢查演算法的工作，也就是說證明數學模型符合給定的邏輯公式。 -形式化驗證裡的模型檢查主要用來評價時間屬性，該屬性描述了合約行為與時間的關係。 智慧型合約的時間屬性包括我們之前說明的_安全_和_活躍性_。 +形式化驗證裡的模型檢查主要用來評價時間屬性，該屬性描述了合約行為與時間的關係。 智能合約的時序屬性包括我們稍早解釋過的_安全性_和_活躍性_。 -例如，與存取控制相關的安全屬性（例如，_只有合約的擁有者能夠呼叫 `selfdestruct` _）可以使用形式化邏輯來編寫。 之後，模型檢查演算法可以驗證合約是否符合此形式化規範。 +舉例來說，與存取控制相關的安全屬性 (例如，_只有合約擁有者可以呼叫 `selfdestruct`_) 可以用形式化邏輯來編寫。 之後，模型檢查演算法可以驗證合約是否符合此形式化規範。 模型檢查使用狀態空間探索，其中涉及構造智慧型合約的所有可能狀態，並試圖找出導致違反屬性的可達狀態。 然而，這可能會導致無限的狀態數量（稱爲「狀態爆炸問題」‌），因此，模型檢查器需仰賴抽象技術來實現高效分析智慧型合約。 @@ -120,7 +120,7 @@ lang: zh-tw 定理證明是以數學方式推論程式（包括智慧型合約）之正確性的方法。 這需要將合約系統的模型和規範轉換成數學公式（邏輯陳述式）。 -定理證明的目的是驗證這些陳述式之間的邏輯等價性。 「邏輯等價性」（也被稱爲「邏輯雙向蘊含」）是兩個陳述式之間的一種關係，例如，第一個陳述式_當且僅當_第二個陳述式為 true 時才為 true。 +定理證明的目的是驗證這些陳述式之間的邏輯等價性。 「邏輯等價性」(也稱為「邏輯雙向蘊含」) 是兩個陳述句之間的一種關係，亦即第一個陳述句為 true _若且唯若_ 第二個陳述句為 true。 關於合約模型及其屬性的陳述式之間的這種必要關係（邏輯等價性），被公式化為可證明的陳述式（又稱定理）。 使用形式化推理系統，自動定理證明器可以驗證定理的有效性。 換言之，自動定理證明器可以結論性地證明智慧型合約模型確切符合其規範。 @@ -130,13 +130,13 @@ lang: zh-tw ### 符號執行 {#symbolic-execution} -符號執行是一種透過使用_符號值_（如 `x > 5`）而不是_具體值_（如 `x == 5`）執行函式來分析智慧型合約的方法。 作爲一種形式化驗證技術，符號執行用於對智慧型合約程式碼中的追蹤層級屬性進行形式化推理。 +符號執行是分析智能合約的一種方法，藉由使用_符號值_ (例如：`x > 5`) 而非_具體值_ (例如：`x == 5`) 來執行函數。 作爲一種形式化驗證技術，符號執行用於對智慧型合約程式碼中的追蹤層級屬性進行形式化推理。 -符號執行將執行追蹤表示爲針對符號輸入值的數學公式，也稱爲_路徑斷言_。 [SMT 求解器](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories)用於檢查路徑述詞是否爲「可滿足」（即存在能夠滿足該公式的值）。 假如某脆弱路徑是可滿足的，SMT 求解器會產生一個具體值來觸發針對該路徑的引導執行。 +符號執行將執行追蹤表示為作用於符號輸入值的數學公式，也稱為_路徑述詞_。 [SMT 求解器](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) 會用來檢查路徑述詞是否「可滿足」(即可否找到滿足該公式的值)。 假如某脆弱路徑是可滿足的，SMT 求解器會產生一個具體值來觸發針對該路徑的引導執行。 -假設一個智慧型合約函式接受輸入的 `uint` 值 (`x`)，並在 `x` 大於 `5` 且小於 `10` 時回退呼叫。 使用正常測試程序尋找觸發錯誤的 `x` 值需要運行數十個測試用例（甚至更多），並且不保證真正找到觸發錯誤的輸入。 +假設某個智能合約的函數接受 `uint` 值 (`x`) 作為輸入，並在 `x` 大於 `5` 且小於 `10` 時還原。 若使用一般的測試程序來尋找會觸發錯誤的 `x` 值，將需要執行數十個 (或更多) 測試案例，而且不保證能真正找到觸發錯誤的輸入。 -相反，符號執行工具會使用符號值來執行函式：`X > 5 ∧ X < 10`（即，`x` 大於 5 且 `x` 小於 10）。 之後，相關的路徑述詞 `x = X > 5 ∧ X < 10` 會提供給 SMT 求解器進行求解。 如果一個特定值滿足公式 `x = X > 5 ∧ X < 10`，SMT 求解器將會計算它 - 例如，求解器可能會產生 `7` 作爲 `x` 的值。 +反之，符號執行工具會使用符號值 `X > 5 ∧ X < 10` 來執行函數 (即，`x` 大於 5 且 `x` 小於 10)。 相關的路徑述詞 `x = X > 5 ∧ X < 10` 接著會被交給 SMT 求解器求解。 如果有特定值滿足公式 `x = X > 5 ∧ X < 10`，SMT 求解器就會計算出該值—例如，求解器可能會產生 `7` 作為 `x` 的值。 因爲符號執行仰賴程式的輸入，而探索所有可達狀態的一系列輸入可能是無限的，所以這仍然是一種測試形式。 不過，如範例所示，符號執行在尋找觸發違反屬性的輸入方面比常規測試更有效率。 @@ -152,25 +152,26 @@ function safe_add(uint x, uint y) returns(uint z){ require(z>=y); return z; +} ``` -導致整數溢位的執行追蹤需要滿足以下公式：`z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)`。這種公式不太可能有解，因此它提供了函式 `safe_add` 永不溢出的數學證明。 +會造成整數溢位的執行追蹤必須滿足公式：`z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)`。這樣的公式不太可能被解出，因此可作為函數 `safe_add` 絕不會溢位的數學證明。 ### 為什麼要對智慧型合約使用形式化驗證？ {#benefits-of-formal-verification} -#### 可靠性的需求 {#need-for-reliability} +#### 對可靠性的需求 {#need-for-reliability} -形式化驗證被用於評估安全關鍵系統的正確性，這些系統的失敗會產生災難性後果，例如死亡、受傷或金融崩潰。 智慧型合約是控制巨額價值的高價值應用程式，設計中的簡單錯誤可能會導致[使用者遭受無法挽回的損失](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/)。 然而，在合約部署之前進行形式化驗證，則可以增加其在區塊鏈上如期運行的保證。 +形式化驗證被用於評估安全關鍵系統的正確性，這些系統的失敗會產生災難性後果，例如死亡、受傷或金融崩潰。 智能合約是控制鉅額價值的高價值應用程式，設計上的小錯誤就可能導致 [使用者無法挽回的損失](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/)。 然而，在合約部署之前進行形式化驗證，則可以增加其在區塊鏈上如期運行的保證。 可靠性是任何智慧型合約都渴求的一種品質，尤其是因爲在以太坊虛擬機 (EVM) 上部署的程式碼通常是不可變的。 合約推出後的升級並不是輕易能夠達成的，形式化驗證成為確保合約可靠性的需求下不可缺少的必需品。 形式化驗證能夠檢測棘手的問題，比如整數下溢和上溢、可重入性和糟糕的燃料最佳化，審核者和測試者可能會漏掉這些問題。 -#### 証明功能正確性 {#prove-functional-correctness} +#### 證明功能正確性 {#prove-functional-correctness} 程式測試是證明智慧型合約符合某些要求的最常見方法。 這包括用預期合約會處理到的樣本資料來執行合約，並且分析合約的行為。 假如對樣本資料合約傳回預期的結果，則開發者對合約的正確性做了客觀性的證明。 -然而，這種方法無法證明樣本資料之外的輸入值也能正確執行。 因此，測試合約可以幫助檢測漏洞（例如，如果程式碼路徑在執行期間未能返回期望的結果），但**它無法結論性地證明沒有漏洞**。 +然而，這種方法無法證明樣本資料之外的輸入值也能正確執行。 因此，測試合約可能有助於偵測程式錯誤 (即某些程式碼路徑在執行期間未能傳回預期結果)，但**無法斷定沒有程式錯誤**。 -相反，形式化驗證可以從形式上證明智慧型合約能在無限執行範圍内滿足要求，而_無需_運行該合約。 這需要建立一個形式化規範來準確描述正確的合約行爲，並開發合約系統的形式化（數學）模型。 之後我們可以透過形式化證明程序來檢查合約模型與其規範之間的一致性。 +反之，形式化驗證可以正式證明智能合約在無限的執行範圍內都滿足需求，_完全無須_執行合約。 這需要建立一個形式化規範來準確描述正確的合約行爲，並開發合約系統的形式化（數學）模型。 之後我們可以透過形式化證明程序來檢查合約模型與其規範之間的一致性。 透過形式化驗證，驗證合約商業邏輯是否滿足要求的問題就成爲一個能夠被證明或反駁的數學命題。 透過命題的形式化證明，我們可以在有限的步驟內驗證無限數量的測試用例。 這種方式的形式化驗證在證明合約相較於規範的功能正確性方面具有更好的前景。 @@ -180,9 +181,9 @@ function safe_add(uint x, uint y) returns(uint z){ 智慧型合約至少在某種程度上滿足這兩個要求。 例如，以太坊合約的規模較小，這使它們適合進行形式化驗證。 此外，以太坊虛擬機遵循簡單的規則，這使得為以太坊虛擬機中所運行的程式驗證語義屬性變得更加容易。 -### 更短的開發周期 {#faster-development-cycle} +### 更快的開發週期 {#faster-development-cycle} -形式化驗證技術，例如模型檢查和符號執行，通常比常規的智慧型合約程式碼分析更有效率（在測試和審核期間的表現）。 這是因為形式化驗證仰賴符號值來測試斷言（「如果使用者嘗試提取 _n_ 個以太幣會怎樣？」）， 而目前常用的測試則使用具體值（「如果使用者嘗試提取 5 個以太幣會怎樣？」）。 +形式化驗證技術，例如模型檢查和符號執行，通常比常規的智慧型合約程式碼分析更有效率（在測試和審核期間的表現）。 這是因為形式化驗證依賴符號值來測試斷言 (「如果使用者嘗試提領 _n_ 以太幣會怎麼樣？」) 而目前常用的測試則使用具體值（「如果使用者嘗試提取 5 個以太幣會怎樣？」）。 符號輸入變數可以涵蓋多個類別的具體值，因此形式化驗證能夠確保在更短時間内覆蓋更多程式碼。 在有效率的使用下，形式化驗證可以加速開發者的開發流程。 @@ -196,7 +197,7 @@ function safe_add(uint x, uint y) returns(uint z){ 這些因素（人力與技能）使形式化驗證相比評估合約正確性的常規方法（例如測試和審核），要求更高且更加昂貴。 然而，鑑於智慧型合約實作中的錯誤代價，完整驗證審核的成本仍然是可以接受的。 -### 漏報 {#false-negatives} +### 偽陰性 {#false-negatives} 形式化驗證只能檢查智慧型合約的執行是否與形式化規範相符， 因此，確保規範正確描述智慧型合約的預期行為非常重要。 @@ -206,78 +207,78 @@ function safe_add(uint x, uint y) returns(uint z){ 形式化驗證會遇到一些效能問題。 例如，在模型檢查和符號檢查期間分別遇到狀態和路徑爆炸問題，就可能會影響驗證程序。 另外，形式化驗證經常在其底層使用 SMT 求解器和其他約束求解器，而這些求解器仰賴計算密集型流程。 -此外，程式驗證器并不總是能夠確認屬性（由邏輯公式描述）是否可以被滿足（「[可判定性問題](https://en.wikipedia.org/wiki/Decision_problem)」），因爲程式可能永遠不會終止。 因此，即使規範良好，有些合約屬性也可能無法被證明。 +此外，程式驗證器不一定總能判斷一個屬性 (以邏輯公式描述) 是否能被滿足 (「[可判定性問題](https://en.wikipedia.org/wiki/Decision_problem)」)，因為程式可能永不終止。 因此，即使規範良好，有些合約屬性也可能無法被證明。 -## 以太坊智慧型合約的形式化驗證工具 {#formal-verification-tools} +## 用於以太坊智能合約的形式化驗證工具 {#formal-verification-tools} ### 用於建立形式化規範的規範語言 {#specification-languages} -**Act** - _Act 允許指定存儲更新、前置/後置條件以及合約不變量。 其工具套件還具有證明後端，可透過 Coq、SMT 求解器或 hevm 來證明許多屬性。_ +**Act**：__Act 允許指定儲存更新、前/後置條件和合約不變量。 其工具套件也有證明後端，能夠透過 Coq、SMT 求解器或 hevm 證明許多屬性。__ - [GitHub](https://github.com/ethereum/act) -- [文檔](https://ethereum.github.io/act/) +- [文件](https://github.com/argotorg/act) -**Scribble** - _Scribble 將以 Scribble 規範語言編寫的程式碼注解轉換爲用於檢查規範的具體斷言。_ +**Scribble** - __Scribble 可將 Scribble 規範語言中的程式碼註解轉換為檢查規範的具體斷言。__ - [文件](https://docs.scribble.codes/) -**Dafny** — _Dafny 是一種驗證就緒的程式設計語言，仰賴高階註釋來推理和證明程式碼的正確性。_ +**Dafny** - __Dafny 是已可進行驗證的程式語言，依賴高階註解來推斷和證明程式碼的正確性。__ - [GitHub](https://github.com/dafny-lang/dafny) ### 用於檢查正確性的程式驗證器 {#program-verifiers} -**Certora Prover** - _Certora Prover 是一種自動形式化驗證工具，用於檢查智慧型合約程式碼的正確性。 規範採用 CVL（Certora 驗證語言）編寫，結合使用靜態分析和約束求解來偵測屬性違反。_ +**Certora Prover** - _Certora Prover 是一種自動形式化驗證工具，用於檢查智能合約中程式碼的正確性。 規範是以 CVL (Certora 驗證語言) 編寫，會結合靜態分析與約束求解來偵測屬性違規。_ - [網站](https://www.certora.com/) -- [文檔](https://docs.certora.com/en/latest/index.html) +- [文件](https://docs.certora.com/en/latest/index.html) -**Solidity SMTChecker** - _Solidity 的 SMTChecker 是一個基於 SMT（可滿足性模數理論）和 Horn 求解的内置模型檢查器。 它在編譯期間確認合約的源程式碼是否符合規範，並以靜態方式檢查安全屬性的違反情況。_ +**Solidity SMTChecker** - __Solidity 的 SMTChecker 是一種內建模型檢查器，以 SMT (可滿足性模數理論) 和 Horn 求解為基礎。 它會在編譯期間確認合約的原始碼是否符合規範，並靜態檢查是否有違反安全屬性的情況。__ - [GitHub](https://github.com/ethereum/solidity) -**solc-verify** - _solc-verify 是 Solidity 編譯器的一個延伸版本，可以使用注解和模組化程式驗證在 Solidity 程式碼上執行自動形式化驗證。_ +**solc-verify** - __solc-verify 是 Solidity 編譯器的擴充版本，可使用註解和模組化程式驗證，對 Solidity 程式碼執行自動化形式驗證。__ - [GitHub](https://github.com/SRI-CSL/solidity) -**KEVM** - _KEVM 是用 K 框架編寫的以太坊虛擬機 (EVM) 的形式化語義。 KEVM 是可執行的，並且可以用可達性邏輯來證明某些與屬性相關的斷言。_ +**KEVM** - __KEVM 是以 K 框架編寫的以太坊虛擬機 (EVM) 的形式化語義。 KEVM 為可執行檔，能使用可達性邏輯證明某些與屬性相關的斷言。__ - [GitHub](https://github.com/runtimeverification/evm-semantics) -- [文檔](https://jellopaper.org/) +- [文件](https://jellopaper.org/) -### 定理證明的邏輯框架 {#theorem-provers} +### 用於定理證明的邏輯框架 {#theorem-provers} -**Isabelle** - _Isabelle/HOL 是一個證明助手，允許使用形式化語言來表示數學公式，並提供驗證明這些公式的工具。 主要應用於數學證明的形式化，特別是形式化驗證，它涉及證明電腦硬體或軟體的正確性以及證明電腦語言和協定的屬性。_ +**Isabelle** - _Isabelle/HOL 是一種證明輔助工具，能以形式化語言表達數學公式，並提供用來證明這些公式的工具。 主要應用為數學證明的形式化，特別是形式化驗證，其中包括證明電腦硬體或軟體的正確性，以及證明電腦語言和協定的屬性。_ - [GitHub](https://github.com/isabelle-prover) -- [文檔](https://isabelle.in.tum.de/documentation.html) +- [文件](https://isabelle.in.tum.de/documentation.html) -**Coq** - _Coq 是一個互動式定理證明器，允許你使用定理來定義程式並以互動方式產生經機器檢查的正確性證明。_ +**Rocq** - _Rocq 是一種互動式定理證明器，能讓你用定理來定義程式，並以互動方式產生經機器檢查的正確性證明。_ -- [GitHub](https://github.com/coq/coq) -- [文檔](https://coq.github.io/doc/v8.13/refman/index.html) +- [GitHub](https://github.com/rocq-prover/rocq) +- [文件](https://rocq-prover.org/docs) -### 用於偵測智慧型合約中易受攻擊模式的基於符號執行的工具 {#symbolic-execution-tools} +### 以符號執行為基礎、用以偵測智能合約中易受攻擊模式的工具 {#symbolic-execution-tools} -**Manticore** – _一種基於符號執行的以太坊虛擬機位元組碼分析工具。_ +**Manticore** - __一種以符號執行為基礎、用以分析 EVM 位元組碼的工具。__ - [GitHub](https://github.com/trailofbits/manticore) -- [文檔](https://github.com/trailofbits/manticore/wiki) +- [文件](https://github.com/trailofbits/manticore/wiki) -**hevm** - _hevm 是用於以太坊虛擬機位元組碼的符號執行引擎和等價性檢查器。_ +**hevm** - __hevm 是 EVM 位元組碼的符號執行引擎和等效性檢查器。__ - [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm) -**Mythril** - _用於檢測以太坊智慧型合約漏洞的符號執行工具。_ +**Mythril** - _一種用以偵測以太坊智能合約中漏洞的符號執行工具_ - [GitHub](https://github.com/ConsenSys/mythril-classic) -- [文檔](https://mythril-classic.readthedocs.io/en/develop/) +- [文件](https://mythril-classic.readthedocs.io/en/develop/) ## 延伸閱讀 {#further-reading} -- [智慧型合約形式化驗證的運作方式](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) -- [形式化驗證如何確保智慧型合約完美無瑕](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) -- [以太坊生態系統中的形式化驗證專案概覽](https://github.com/leonardoalt/ethereum_formal_verification_overview) -- [以太坊 2.0 存款智慧型合約的端到端形式化驗證](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) -- [全球最受歡迎之智慧型合約的形式化驗證](https://www.zellic.io/blog/formal-verification-weth) -- [SMTChecker 與形式化驗證](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) +- [智能合約的形式化驗證如何運作](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) +- [形式化驗證如何確保智能合約完美無瑕](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) +- [以太坊生態系統中形式化驗證專案概觀](https://github.com/leonardoalt/ethereum_formal_verification_overview) +- [以太坊 2.0 存款智能合約的端對端形式化驗證](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) +- [形式化驗證全世界最受歡迎的智能合約](https://www.zellic.io/blog/formal-verification-weth) +- [SMTChecker 和形式化驗證](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/index.md index 75594177756..12fdc1ff68c 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/index.md @@ -1,24 +1,24 @@ --- -title: 智慧型合約簡介 -description: 智慧型合約概觀，重點介紹其特點及限制。 +title: "智慧型合約簡介" +description: "智慧型合約概觀，重點介紹其特點及限制。" lang: zh-tw --- -## 智慧型合約是什麼？ {#what-is-a-smart-contract} +## 智慧型合約是什麼？ 什麼是智能合約？ {#what-is-a-smart-contract} 「智慧型合約」就是在以太坊區塊鏈上執行的程式。 這是一系列存在於以太坊區塊鏈特定地址的程式碼（函數）及資料（狀態）。 -智慧型合約是一種[以太坊帳戶](/developers/docs/accounts/)。 這表示智慧型合約有餘額且能作為交易目標。 然而，智慧型合約不受使用者控制，而是部署至網路，並按程式編寫方式執行。 使用者帳戶能藉由傳送交易，執行智慧型合約定義的函數，來與智慧型合約互動。 智慧型合約能定義規則，就像一般合約一樣，且完全透過程式碼自動執行。 預設情況下，智慧型合約無法刪除，且與其互動的結果無法逆轉。 +智能合約是[以太坊帳戶](/developers/docs/accounts/)的一種類型。 這表示智慧型合約有餘額且能作為交易目標。 然而，智慧型合約不受使用者控制，而是部署至網路，並按程式編寫方式執行。 使用者帳戶能藉由傳送交易，執行智慧型合約定義的函數，來與智慧型合約互動。 智慧型合約能定義規則，就像一般合約一樣，且完全透過程式碼自動執行。 預設情況下，智慧型合約無法刪除，且與其互動的結果無法逆轉。 -## 基本資訊 {#prerequisites} +## 先決條件 {#prerequisites} -如果你是初學者，或是想找不技術性不太強的說明，推薦你參閱[智慧型合約簡介](/smart-contracts/)。 +如果你剛入門，或是在尋找技術性較低的介紹，我們推薦你閱讀我們的[智能合約簡介](/smart-contracts/)。 -務必先詳閱[帳戶](/developers/docs/accounts/)、[交易](/developers/docs/transactions/)及[以太坊虛擬機](/developers/docs/evm/)後再踏入智慧型合約的世界。 +在進入智能合約的世界前，請確保你已閱讀過[帳戶](/developers/docs/accounts/)、[交易](/developers/docs/transactions/)和[以太坊虛擬機](/developers/docs/evm/)的相關說明。 -## 數位販賣機 {#a-digital-vending-machine} +## 數位自動販賣機 {#a-digital-vending-machine} -或許最適合智慧型合約的比喻是 [Nick Szabo](https://unenumerated.blogspot.com/) 所說的「販賣機」。 只要輸入正確，就保證能得到特定的輸出結果。 +智能合約最好的比喻或許是自動販賣機，這個概念由 [Nick Szabo](https://unenumerated.blogspot.com/) 提出。 只要輸入正確，就保證能得到特定的輸出結果。 要從販賣機取得一包點心： @@ -35,28 +35,28 @@ pragma solidity 0.8.7; contract VendingMachine { - // Declare state variables of the contract + // 宣告合約的狀態變數 address public owner; mapping (address => uint) public cupcakeBalances; - // When 'VendingMachine' contract is deployed: - // 1. set the deploying address as the owner of the contract - // 2. set the deployed smart contract's cupcake balance to 100 + // 部署「VendingMachine」合約時： + // 1. 將部署地址設為合約擁有者 + // 2. 將部署的智能合約的杯子蛋糕餘額設為 100 constructor() { owner = msg.sender; cupcakeBalances[address(this)] = 100; } - // Allow the owner to increase the smart contract's cupcake balance + // 允許擁有者增加智能合約的杯子蛋糕餘額 function refill(uint amount) public { - require(msg.sender == owner, "Only the owner can refill."); + require(msg.sender == owner, "只有擁有者能補充。"); cupcakeBalances[address(this)] += amount; } - // Allow anyone to purchase cupcakes + // 允許任何人購買杯子蛋糕 function purchase(uint amount) public payable { - require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); - require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); + require(msg.value >= amount * 1 ether, "每個杯子蛋糕至少需支付 1 ETH"); + require(cupcakeBalances[address(this)] >= amount, "庫存杯子蛋糕不足，無法完成此次購買"); cupcakeBalances[address(this)] -= amount; cupcakeBalances[msg.sender] += amount; } @@ -67,46 +67,46 @@ contract VendingMachine { ## 無需許可 {#permissionless} -任何人都能編寫智慧型合約並部署於區塊鏈網路。 你只需要學習如何使用[智慧型合約語言](/developers/docs/smart-contracts/languages/)編碼，並取得足夠的以太幣，即可部署合約。 部署合約基本上是一種交易，因此你需要支付[燃料](/developers/docs/gas/)費用，如同進行簡單的以太幣轉帳一樣。 然而，部署合約的燃料成本卻遠高於此。 +任何人都能編寫智慧型合約並部署於區塊鏈網路。 你只需要學習如何使用[智能合約語言](/developers/docs/smart-contracts/languages/)撰寫程式碼，並擁有足夠的 ETH 來部署你的合約。 部署智能合約基本上是一種交易，所以你需要支付 [Gas](/developers/docs/gas/)，就像支付簡單的 ETH 轉帳一樣。 然而，部署合約的燃料成本卻遠高於此。 以太坊具備方便開發者編寫智慧型合約的程式語言： - Solidity - Vyper -[深入瞭解程式語言](/developers/docs/smart-contracts/languages/) +[更多關於語言的資訊](/developers/docs/smart-contracts/languages/) -然而，在部署合約前需要先編譯，讓以太坊的虛擬機可以解譯並儲存合約。 [深入瞭解編譯](/developers/docs/smart-contracts/compiling/) +然而，在部署合約前需要先編譯，讓以太坊的虛擬機可以解譯並儲存合約。 [更多關於編譯的資訊](/developers/docs/smart-contracts/compiling/) ## 可組合性 {#composability} -智慧型合約公開於以太坊, 類似一API於網路. 這表示你可以在自己的智慧型合約中，調用其他智慧型合約，以大幅拓展可能性。 合約甚至能部署其他合約。 +智慧型合約在以太坊上公開，類似於傳統網路世界中的 Open API。 這表示你可以在自己的智慧型合約中，調用其他智慧型合約，以大幅拓展可能性。 合約甚至能部署其他合約。 -深入瞭解[智慧型合約的可組合性](/developers/docs/smart-contracts/composability/)。 +進一步了解[智能合約可組合性](/developers/docs/smart-contracts/composability/)。 ## 限制 {#limitations} -智慧型合約本身無法取得「真實世界」事件的資訊，因為這些合約無法擷取鏈外來源中的資料。 這表示智慧型合約不會針對真實世界的事件做出反應。 這是刻意設計。 過度依賴外部資訊可能會破壞共識機制，而共識對安全性與去中心化至關重要。 +智能合約本身無法取得「真實世界」事件的資訊，因為這些合約無法擷取鏈下來源中的資料。 這表示智慧型合約不會針對真實世界的事件做出反應。 這是刻意設計。 過度依賴外部資訊可能會破壞共識機制，而共識對安全性與去中心化至關重要。 -然而，區塊鏈應用程式最好能使用鏈外資料。 解決方法是使用[預言機](/developers/docs/oracles/)，這種工具可以取得鏈外資料並提供給智慧型合約使用。 +然而，區塊鏈應用程式最好能使用鏈下資料。 解決方案是使用[預言機](/developers/docs/oracles/)，這是一種可以擷取鏈外資料並提供給智能合約使用的工具。 -智慧型合約的另一個限制為合約大小的上限。 智慧型合約必須小於 24KB，不然燃料不足。 可以透過[鑽石模式](https://eips.ethereum.org/EIPS/eip-2535)迴避此問題。 +智慧型合約的另一個限制為合約大小的上限。 智慧型合約必須小於 24KB，不然燃料不足。 這個問題可以透過使用[鑽石模式 (The Diamond Pattern)](https://eips.ethereum.org/EIPS/eip-2535) 來解決。 ## 多簽合約 {#multisig} -多簽（多重簽章）合約是需要多個有效簽章，才能執行交易的智慧型合約帳戶。 這能有效預防持有大量以太幣或代幣的合約發生單點失效。 多簽合約也能將執行合約與金鑰管理的責任分散給多方，避免遺失單一私密金鑰造成資金無法回復的損失。 基於上述理由，多簽合約可用於簡單的去中心化組織管理體系。 多簽需要在 M 個可接受的簽章中取得 N 個簽章才能執行（其中，N ≤ M 且 M > 1）。 通常是`N = 3, M = 5` 以及 `N = 4, M = 7`。 4/7 的多簽需要在七個可能的有效簽章中取得四個簽章。 這表示即便遺失三個簽章，仍可取回資金。 在這種情況下，這也表示大多數金鑰持有者必須同意並簽署，才能執行合約。 +多簽（多重簽章）合約是需要多個有效簽章，才能執行交易的智慧型合約帳戶。 這能有效預防持有大量以太幣或代幣的合約發生單點失效。 多簽合約也能將執行合約與金鑰管理的責任分散給多方，避免遺失單一私密金鑰造成資金無法回復的損失。 基於上述理由，多簽合約可用於簡單的去中心化組織管理體系。 多簽需要從 M 個可接受的簽章中取得 N 個簽章（其中 N ≤ M，且 M > 1）才能執行。 常用的組合是 `N = 3, M = 5` 和 `N = 4, M = 7`。 4/7 的多簽需要在七個可能的有效簽章中取得四個簽章。 這表示即便遺失三個簽章，仍可取回資金。 在這種情況下，這也表示大多數金鑰持有者必須同意並簽署，才能執行合約。 -## 智慧型合約資源 {#smart-contract-resources} +## 智能合約資源 {#smart-contract-resources} -**OpenZeppelin Contracts -** **_開發安全智慧型合約的資料庫。_** +**OpenZeppelin Contracts -** **_用於安全智能合約開發的函式庫。_** - [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/) -- [Github](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) - [社群論壇](https://forum.openzeppelin.com/c/general/16) -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} -- [Coinbase：什麼是智慧型合約？](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) -- [Chainlink：什麼是智慧型合約？](https://chain.link/education/smart-contracts) -- [影片：智慧型合約簡介](https://youtu.be/ZE2HxTmxfrI) -- [Cyfrin Updraft：Web3 學習與審計平台](https://updraft.cyfrin.io) +- [Coinbase：什麼是智能合約？](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) +- [Chainlink：什麼是智能合約？](https://chain.link/education/smart-contracts) +- [影片：簡單解釋 - 智能合約](https://youtu.be/ZE2HxTmxfrI) +- [Cyfrin Updraft：Web3 學習與稽核平台](https://updraft.cyfrin.io) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md index 032b0c755d4..ceed3eb684a 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md @@ -1,25 +1,25 @@ --- -title: 智慧型合約語言 -description: Solidity 及 Vyper：兩種智慧型合約常用語言的概觀與比較。 +title: "智慧型合約的程式語言" +description: "Solidity 及 Vyper：兩種智慧型合約常用語言的概觀與比較。" lang: zh-tw --- -以太坊一大好處是，對開發者而言，編寫智慧型合約的語言相對簡單。 如你熟悉 Python 或任何[大括號語言](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages)，會發現其實他們的語法非常相似。 +以太坊一大好處是，對開發者而言，編寫智慧型合約的語言相對簡單。 若您有 Python 或任何[花括號語言](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages)的使用經驗，您就能找到語法熟悉的語言。 兩種最熱門、最受管理的語言為： - Solidity - Vyper -Remix 整合開發環境提供一個全面的開發環境，用於透過 Solidity 和 Vyper 語言建立和測試合約。 [嘗試使用瀏覽器內的 Remix IDE](https://remix.ethereum.org) 開始編碼。 +Remix 整合開發環境提供一個全面的開發環境，用於透過 Solidity 和 Vyper 語言建立和測試合約。 [試用瀏覽器內的 Remix IDE](https://remix.ethereum.org) 開始編寫程式。 -經驗更豐富的開發者可能也會想使用 Yul，這是[以太坊虛擬機](/developers/docs/evm/)的中階語言，或是使用 Yul 的延伸語言 Yul+。 +經驗更豐富的開發者可能也會想使用 Yul (一種 [Ethereum Virtual Machine](/developers/docs/evm/) 的中介語言)，或 Yul+ (Yul 的擴充)。 若你有興趣，且想協助測試還處於大力開發階段的新語言，可以實驗仍在發展初期的新興智慧型合約語言 Fe。 -## 基本資訊 {#prerequisites} +## 先決條件 {#prerequisites} -如果已經有編程語言的知識，特別是 JavaScript 或 Python，可以幫助你瞭解智慧型合約語言的差異。 同時，我們建議你在深入理解語言差異之前，先理解智慧型合約的概念。 [智慧型合約簡介](/developers/docs/smart-contracts/)。 +如果已經有編程語言的知識，特別是 JavaScript 或 Python，可以幫助你瞭解智慧型合約語言的差異。 同時，我們建議你在深入理解語言差異之前，先理解智慧型合約的概念。 [智能合約簡介](/developers/docs/smart-contracts/)。 ## Solidity {#solidity} @@ -35,10 +35,10 @@ Remix 整合開發環境提供一個全面的開發環境，用於透過 Solidit - [文件](https://docs.soliditylang.org/en/latest/) - [Solidity 語言入口網站](https://soliditylang.org/) -- [Solidity by Example](https://docs.soliditylang.org/en/latest/solidity-by-example.html) -- [Github](https://github.com/ethereum/solidity/) -- [Solidity Gitter Chatroom](https://gitter.im/ethereum/solidity) 橋接至 [Solidity Matrix Chatroom](https://matrix.to/#/#ethereum_solidity:gitter.im) -- [懶人包](https://reference.auditless.com/cheatsheet) +- [Solidity 範例](https://docs.soliditylang.org/en/latest/solidity-by-example.html) +- [GitHub](https://github.com/ethereum/solidity/) +- [Solidity Gitter 聊天室](https://gitter.im/ethereum/solidity)橋接到 [Solidity Matrix 聊天室](https://matrix.to/#/#ethereum_solidity:gitter.im) +- [快捷手冊](https://reference.auditless.com/cheatsheet) - [Solidity 部落格](https://blog.soliditylang.org/) - [Solidity Twitter](https://twitter.com/solidity_lang) @@ -49,30 +49,33 @@ Remix 整合開發環境提供一個全面的開發環境，用於透過 Solidit pragma solidity >= 0.7.0; contract Coin { - // 關鍵字 "public" 使變量可以被其它合約訪問 + // 「public」關鍵字使變數 + // 可從其他合約存取 address public minter; mapping (address => uint) public balances; - // 事件Events允許客戶讀取你聲明的特定合約變更。 + // 事件讓用戶端對您宣告的 + // 特定合約變更做出反應 event Sent(address from, address to, uint amount); - // Constructor構造代碼僅在合約創建時執行一次。 + // 建構函式程式碼只會在合約 + // 建立時執行 constructor() { minter = msg.sender; } - // 發送一定數量新創建的代幣到某個地址。 - // 只有合約創建者可以調用。 + // 傳送一定數量的新代幣到某個地址 + // 只能由合約建立者呼叫 function mint(address receiver, uint amount) public { require(msg.sender == minter); require(amount < 1e60); balances[receiver] += amount; } - // 發送一定量已經存在的代幣 - // 從調用者到任意地址 + // 從任何呼叫者傳送一定數量的現有代幣 + // 到某個地址 function send(address receiver, uint amount) public { - require(amount <= balances[msg.sender], "Insufficient balance."); + require(amount <= balances[msg.sender], "餘額不足。"); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); @@ -80,7 +83,7 @@ contract Coin { } ``` -這個範例應該能讓你瞭解 Solidity 的合約語法。 關於函數和變數的詳細描述，[請參閱文件](https://docs.soliditylang.org/en/latest/contracts.html)。 +這個範例應該能讓你瞭解 Solidity 的合約語法。 關於函式和變數的詳細說明，[請參閱文件](https://docs.soliditylang.org/en/latest/contracts.html)。 ## Vyper {#vyper} @@ -98,110 +101,125 @@ contract Coin { - 無限長度迴圈 - 二進制定點 -如需更多資訊，[請參閱 Vyper 原理](https://vyper.readthedocs.io/en/latest/index.html)。 +更多資訊，[請閱讀 Vyper 設計理念](https://vyper.readthedocs.io/en/latest/index.html)。 -### 重要鏈結 {#important-links-1} +### 重要連結 {#important-links-1} - [文件](https://vyper.readthedocs.io) -- [Vyper by Example](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) -- [更多 Vyper by Example](https://vyper-by-example.org/) -- [Github](https://github.com/vyperlang/vyper) -- [Vyper 社群 Discord 聊天](https://discord.gg/SdvKC79cJk) -- [懶人包](https://reference.auditless.com/cheatsheet) -- [Vyper 的智慧型合約開發框架與工具](/developers/docs/programming-languages/python/) -- [VyperPunk：瞭解如何保障與駭客攻擊 Vyper 智慧型合約](https://github.com/SupremacyTeam/VyperPunk) -- [支援開發的 Vyper Hub](https://github.com/zcor/vyper-dev) -- [Vyper 最熱門的智慧型合約範例](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) -- [出色的 Vyper 精選資源](https://github.com/spadebuilders/awesome-vyper) +- [Vyper 範例](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) +- [更多 Vyper 範例](https://vyper-by-example.org/) +- [GitHub](https://github.com/vyperlang/vyper) +- [Vyper 社群 Discord 聊天室](https://discord.gg/SdvKC79cJk) +- [快捷手冊](https://reference.auditless.com/cheatsheet) +- [Vyper 智能合約開發框架與工具](/developers/docs/programming-languages/python/) +- [VyperPunk - 學習如何保護與攻擊 Vyper 智能合約](https://github.com/SupremacyTeam/VyperPunk) +- [Vyper 開發中心](https://github.com/zcor/vyper-dev) +- [Vyper 精選智能合約範例](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) +- [Awesome Vyper 精選資源](https://github.com/spadebuilders/awesome-vyper) ### 範例 {#example} ```python -# Open Auction +# 公開拍賣 + +# 拍賣參數 + +# 受益人從最高出價者收到款項 -# Auction params -# Beneficiary receives money from the highest bidder beneficiary: public(address) auctionStart: public(uint256) auctionEnd: public(uint256) -# Current state of auction +# 目前拍賣狀態 + highestBidder: public(address) highestBid: public(uint256) -# Set to true at the end, disallows any change +# 結束時設為 true，不允許任何變更 + ended: public(bool) -# Keep track of refunded bids so we can follow the withdraw pattern +# 追蹤已退款的出價，以便遵循提款模式 + pendingReturns: public(HashMap[address, uint256]) -# Create a simple auction with `_bidding_time` -# seconds bidding time on behalf of the -# beneficiary address `_beneficiary`. +# 建立一個簡單的拍賣，競標時間為 `_bidding_time` + +# 秒，代表受益人地址 `_beneficiary`。 + @external def __init__(_beneficiary: address, _bidding_time: uint256): self.beneficiary = _beneficiary self.auctionStart = block.timestamp self.auctionEnd = self.auctionStart + _bidding_time -# Bid on the auction with the value sent -# together with this transaction. -# The value will only be refunded if the -# auction is not won. +# 以與此交易一起傳送的價值 + +# 參與競標。 + +# 只有在未贏得拍賣時， + +# 價值才會被退還。 + @external @payable def bid(): - # Check if bidding period is over. + # 檢查競標期是否結束。 assert block.timestamp < self.auctionEnd - # Check if bid is high enough + # 檢查出價是否夠高 assert msg.value > self.highestBid - # Track the refund for the previous high bidder + # 追蹤前一個最高出價者的退款 self.pendingReturns[self.highestBidder] += self.highestBid - # Track new high bid + # 追蹤新的最高出價 self.highestBidder = msg.sender self.highestBid = msg.value -# Withdraw a previously refunded bid. The withdraw pattern is -# used here to avoid a security issue. If refunds were directly -# sent as part of bid(), a malicious bidding contract could block -# those refunds and thus block new higher bids from coming in. +# 提領先前已退款的出價。這裡使用提款模式 + +# 以避免安全問題。如果退款是直接 + +# 作為 bid() 的一部分傳送，惡意的競標合約可能會阻止 + +# 這些退款，從而阻止新的更高出價進入。 + @external def withdraw(): pending_amount: uint256 = self.pendingReturns[msg.sender] self.pendingReturns[msg.sender] = 0 send(msg.sender, pending_amount) -# End the auction and send the highest bid -# to the beneficiary. +# 結束拍賣並將最高出價 + +# 傳送給受益人。 + @external def endAuction(): - # It is a good guideline to structure functions that interact - # with other contracts (i.e., they call functions or send ether) - # into three phases: - # 1. checking conditions - # 2. performing actions (potentially changing conditions) - # 3. interacting with other contracts - # If these phases are mixed up, the other contract could call - # back into the current contract and modify the state or cause - # effects (ether payout) to be performed multiple times. - # If functions called internally include interaction with external - # contracts, they also have to be considered interaction with - # external contracts. - - # 1. Conditions - # Check if auction endtime has been reached + # 將與其他合約互動的函式 (即呼叫函式或傳送以太幣) + # 分為三個階段是一個好的指導方針： + # 1. 檢查條件 + # 2. 執行動作 (可能改變條件) + # 3. 與其他合約互動 + # 如果這些階段混雜在一起，其他合約可能會 + # 回呼目前的合約，並修改狀態或導致 + # 效果 (以太幣支付) 被多次執行。 + # 如果內部呼叫的函式包含與外部 + # 合約的互動，它們也必須被視為與 + # 外部合約的互動。 + + # 1. 條件 + # 檢查拍賣結束時間是否已到 assert block.timestamp >= self.auctionEnd - # Check if this function has already been called + # 檢查此函式是否已被呼叫過 assert not self.ended - # 2. Effects + # 2. 效果 self.ended = True - # 3. Interaction + # 3. 互動 send(self.beneficiary, self.highestBid) ``` -此範例應該能讓你瞭解 Solidity 的合約語法。 關於函數和變數的詳細描述，[請參閱文件](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction)。 +此範例應該能讓你瞭解 Solidity 的合約語法。 關於函式和變數的詳細說明，[請參閱文件](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction)。 ## Yul 和 Yul+ {#yul} @@ -210,16 +228,16 @@ def endAuction(): **Yul** - 以太坊的中階語言。 -- 支援[以太坊虛擬機](/developers/docs/evm)和 [eWASM](https://github.com/ewasm)，一種以太坊風格的 WebAssembly，目的在於成為兩個平台均可使用的通用工具。 +- 支援 [EVM](/developers/docs/evm) 和 [Ewasm](https://github.com/ewasm) (一種以太坊風格的 WebAssembly)，其設計目標是成為這兩個平台可用的共同基準。 - 高級最佳化階段的優良目標，能使以太坊虛擬機和 eWASM 平台均等受益。 **Yul+** - Yul 的低階高效延伸語言。 -- 最初設計用於[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)合約。 +- 最初是為[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)合約所設計。 - Yul+ 可以被視為 Yul 的實驗性升級建議，為其添加新功能。 -### 重要鏈結 {#important-links-2} +### 重要連結 {#important-links-2} - [Yul 文件](https://docs.soliditylang.org/en/latest/yul.html) - [Yul+ 文件](https://github.com/fuellabs/yulp) @@ -227,7 +245,8 @@ def endAuction(): ### 合約範例 {#example-contract-2} -以下簡單範例採用冪函數。 它可以使用 `solc --strict-assembly --bin input.yul` 編譯。 這個範例應該 儲存在 input.yul 檔案中。 +以下簡單範例採用冪函數。 可以使用 `solc --strict-assembly --bin input.yul` 進行編譯。 這個範例應該 +儲存在 input.yul 檔案中。 ``` { @@ -248,7 +267,7 @@ def endAuction(): } ``` -如果你已經熟悉智慧型合約，可以在[此處](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example)找到 Yul 言語的完整 ERC20 實作。 +如果您對智能合約已有豐富經驗，可以在[這裡](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example)找到 Yul 的完整 ERC20 實作。 ## Fe {#fe} @@ -257,10 +276,10 @@ def endAuction(): - 目標是讓以太坊生態系統的新手開發者，都能輕鬆學習這門語言。 - Fe 還處於早期開發階段，其 Alpha 版本於 2021 年 1 月推出。 -### 重要鏈結 {#important-links-3} +### 重要連結 {#important-links-3} -- [Github](https://github.com/ethereum/fe) -- [Fe 發布聲明](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) +- [GitHub](https://github.com/ethereum/fe) +- [Fe 公告](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) - [Fe 2021 開發藍圖](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) - [Fe Discord 聊天室](https://discord.com/invite/ywpkAXFjZH) - [Fe Twitter](https://twitter.com/official_fe) @@ -296,7 +315,7 @@ contract GuestBook: ### Solidity 的優點是什麼？ {#solidity-advantages} -- 如果你是初學者，有不少使用教學和學習工具。 在[透過編碼學習](/developers/learning-tools/)部分瞭解更多相關資訊。 +- 如果你是初學者，有不少使用教學和學習工具。 更多相關資訊，請參閱[透過編碼學習](/developers/learning-tools/)一節。 - 提供優良的開發者工具。 - Solidity 擁有龐大的開發者社群，這表示你很可能會很快找到問題的答案。 @@ -313,9 +332,9 @@ contract GuestBook: ## 語言比較 {#language-comparisons} -如需瞭解基本語法比較、合約生命週期、介面、運算子、數據結構、功能、控制流程等資訊，請參閱[由 Auditless 編寫的懶人包](https://reference.auditless.com/cheatsheet/) +若要比較基本語法、合約生命週期、介面、運算子、資料結構、函式、控制流程等，請參閱這份 [Auditless 快捷手冊](https://reference.auditless.com/cheatsheet/) -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} -- [OpenZeppelin 的 Solidity 合約資料庫](https://docs.openzeppelin.com/contracts/5.x/) +- [OpenZeppelin 的 Solidity 合約庫](https://docs.openzeppelin.com/contracts/5.x/) - [Solidity 範例](https://solidity-by-example.org) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/libraries/index.md index f729e5d06e7..c9e772bdc87 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/libraries/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/libraries/index.md @@ -1,26 +1,26 @@ --- -title: 智慧型合約庫 -description: +title: "智慧型合約庫" +description: "探索可重複使用的智能合約函式庫與建構模塊，以加速您的以太坊開發專案。" lang: zh-tw --- 你無需從頭開始編寫專案中的每一個智慧型合約。 因為我們有許多開放原始碼智慧型合約庫可為你的專案提供可重複利用的組件，因此你不必從零開始。 -## 基本資訊 {#prerequisites} +## 先決條件 {#prerequisites} -在使用智慧型合約庫之前，最好先清楚瞭解智慧型合約的結構。 如果尚未完成，請前往[智慧型合約結構](/developers/docs/smart-contracts/anatomy/)。 +在使用智慧型合約庫之前，最好先清楚瞭解智慧型合約的結構。 如果您還沒看過[智能合約剖析](/developers/docs/smart-contracts/anatomy/)，請前往該頁面。 -## 庫的內容 {#whats-in-a-library} +## 函式庫中有什麼 {#whats-in-a-library} 你通常可以在智慧型合約庫中找到兩種組件：可以添加到合約的可重複使用行為，與採納的各種標準。 ### 行為 {#behaviors} -編寫智慧型合約時，你很可能會發現自己在重複編寫類似代碼。比如說在合約中指派一個_管理員_地址執行受保護的操作；或添加一個緊急_暫停_按鈕以應對預料之外的問題。 +撰寫智能合約時，您很可能會發現自己需要一再撰寫類似的模式，例如指派_管理員_地址來執行合約中的受保護操作，或是在發生非預期問題時新增緊急_暫停_按鈕。 -智慧型合約庫通常透過[庫](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries)或在Solidity 中[繼承](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance)，讓這些行為可以重複使用。 +智能合約函式庫通常會以 Solidity 的 [函式庫](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) 或 [繼承](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) 形式，提供這些行為的可重複使用實作。 -例如，以下是[OpenZepelin Contracts 資料庫](https://github.com/OpenZeppelin/openzeppelin-contracts)的 [`Ownable` 合約](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol)簡化版，此合約指定了合約擁有者的地址，並提供將存取方法限制為只有擁有者可存取的修飾符。 +舉例來說，下方是 [OpenZeppelin Contracts 函式庫](https://github.com/OpenZeppelin/openzeppelin-contracts) 中 [`Ownable` 合約](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) 的簡化版本，它會指定一個地址作為合約的擁有者，並提供修飾符，將方法的存取權限僅限於該擁有者。 ```solidity contract Ownable { @@ -37,7 +37,7 @@ contract Ownable { } ``` -若要在你的合約中使用這種組件，首先要匯入，再於自己的合約中擴充。 這會允許你使用基礎 `Ownable` 合約提供的修飾符來保護函數 +若要在你的合約中使用這種組件，首先要匯入，再於自己的合約中擴充。 這可讓您使用基礎 `Ownable` 合約提供的修飾符，來保護您自己的函式。 ```solidity import ".../Ownable.sol"; // Path to the imported library @@ -50,19 +50,19 @@ contract MyContract is Ownable { } ``` -另一個比較受歡迎的例子是 [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) 或 [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html)。 這些庫（與基礎合約不同）提供了語言本身不具備的溢出檢查算術函數。 使用這些庫而非原生算術運算可以防止合約出現溢出，這類錯誤可能導致災難性後果！ +另一個常見的例子是 [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) 或 [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html)。 這些庫（與基礎合約不同）提供了語言本身不具備的溢出檢查算術函數。 使用這些庫而非原生算術運算可以防止合約出現溢出，這類錯誤可能導致災難性後果！ ### 標準 {#standards} -為了促進[可組合性和互通性](/developers/docs/smart-contracts/composability/)，以太坊社群已使用**以太坊意見徵求**的形式定義了幾個標準。 你可以在[標準](/developers/docs/standards/)部分閱讀更多相關資訊。 +為了促進[可組合性與互通性](/developers/docs/smart-contracts/composability/)，以太坊社群以 **ERC** 的形式定義了多項標準。 您可以在[標準](/developers/docs/standards/)一節中閱讀更多相關資訊。 -將以太坊意見徵求納入合約時，更好的做法是尋找標準實作，而非嘗試推出自己的方式。 許多智慧型合約庫包含採用最熱門 ERC 標準的做法。 例如，[ERC20 可互換代幣標準](/developers/tutorials/understand-the-erc-20-token-smart-contract/)可在 [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md)、[DappSys](https://github.com/dapphub/ds-token/) 和 [OpenZepelin](https://docs.openzeppelin.com/contracts/3.x/erc20) 中找到。 此外，一些以太坊意見徵求也提供作為以太坊意見徵求本身一部分的規範實作。 +將以太坊意見徵求納入合約時，更好的做法是尋找標準實作，而非嘗試推出自己的方式。 許多智慧型合約庫包含採用最熱門 ERC 標準的做法。 例如，在 [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md)、[DappSys](https://github.com/dapphub/ds-token/) 和 [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20) 中，都可以找到無所不在的[ERC20 可替代代幣標準](/developers/tutorials/understand-the-erc-20-token-smart-contract/)。 此外，一些以太坊意見徵求也提供作為以太坊意見徵求本身一部分的規範實作。 -值得一提的是，一些以太坊意見徵求並非獨立的，而是對其他以太坊意見徵求的補充。 例如，[ERC2612](https://eips.ethereum.org/EIPS/eip-2612) 拓展了 ERC20，提高其可用性。 +值得一提的是，一些以太坊意見徵求並非獨立的，而是對其他以太坊意見徵求的補充。 例如，[ERC2612](https://eips.ethereum.org/EIPS/eip-2612) 為 ERC20 新增了擴充功能，以改善其可用性。 -## 如何新增庫 {#how-to} +## 如何新增函式庫 {#how-to} -務必參考你要納入的庫文件，以掌握如何將其納入專案的具體說明。 有些 Solidity 合約庫使用 `npm` 來封裝，所以你可以直接透過 `npm install`。 大多數[編譯](/developers/docs/smart-contracts/compiling/)合約的工具會在你的 `node_modules` 中尋找智慧型合約庫，所以你可以執行： +務必參考你要納入的庫文件，以掌握如何將其納入專案的具體說明。 有數個 Solidity 合約函式庫是使用 `npm` 封裝，所以您只要 `npm install` 即可安裝。 大多數[編譯](/developers/docs/smart-contracts/compiling/)合約的工具都會在您的 `node_modules` 中尋找智能合約函式庫，因此您可以執行下列操作： ```solidity // This will load the @openzeppelin/contracts library from your node_modules @@ -73,13 +73,13 @@ contract MyNFT is ERC721 { } ``` -無論使用哪種方法，納入庫時，務必留意[程式語言](/developers/docs/smart-contracts/languages/)的版本。 例如，如果你使用 Solidity 0.5 編寫合約，就不能使用 Solidity 0.6 庫。 +無論使用哪種方法，在加入函式庫時，都務必留意[語言](/developers/docs/smart-contracts/languages/)版本。 例如，如果你使用 Solidity 0.5 編寫合約，就不能使用 Solidity 0.6 庫。 ## 使用時機 {#when-to-use} 在你的專案使用智慧型合約庫有幾個好處。 首先，這提供了現成的組件，可以納入你的系統，而不必自己編寫程式碼，從而節省時間。 -安全性也是一個重要的優點。 開放原始碼智慧型合約庫也經常接受嚴格審查。 鑑於許多專案都依賴它們，社群有強烈動機加以持續審查。 在應用程式代碼中比起可重複使用的合約庫更容易發現錯誤。 有些庫甚至接受[外部審核](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits)，以提高安全性。 +安全性也是一個重要的優點。 開放原始碼智慧型合約庫也經常接受嚴格審查。 鑑於許多專案都依賴它們，社群有強烈動機加以持續審查。 在應用程式代碼中比起可重複使用的合約庫更容易發現錯誤。 有些函式庫也會經過[外部稽核](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits)，以增加安全性。 然而，使用智慧型合約庫可能將你不熟悉的程式碼納入專案。 我們會想匯入合約，並將其直接納入專案，但若未充分理解該合約的作用，可能會由於意外行為，而無意中在系統中引入問題。 務必參閱要匯入的程式碼文件，然後在納入專案前審查程式碼！ @@ -87,31 +87,31 @@ contract MyNFT is ERC721 { ## 相關工具 {#related-tools} -**OpenZeppelin Contracts：** **_最熱門的智慧型合約開發資料庫。 _** +**OpenZeppelin Contracts -** **_最受歡迎的安全智能合約開發函式庫。_** - [文件](https://docs.openzeppelin.com/contracts/) -- [Github](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) - [社群論壇](https://forum.openzeppelin.com/c/general/16) -**DappSys：****_安全、簡單、靈活的智慧型合約建置組件。_** +**DappSys -** **_安全、簡單、靈活的智能合約建置組件。_** -- [文件檔案](https://dappsys.readthedocs.io/) -- [Github](https://github.com/dapphub/dappsys) +- [文件](https://dappsys.readthedocs.io/) +- [GitHub](https://github.com/dapphub/dappsys) -**HQ20：** **_提供合約、資料庫與範例的 Solidity 專案，幫助你建立現實世界可用、功能齊全的分散式應用程式。 _** +**HQ20 -** **_一個包含合約、函式庫和範例的 Solidity 專案，可協助您建置適用於真實世界、功能齊全的分散式應用程式。_** -- [Github](https://github.com/HQ20/contracts) +- [GitHub](https://github.com/HQ20/contracts) -**Web3 Solidity SDK：** **_提供有效率建立自訂智慧型合約所需的工具_** +**thirdweb Solidity SDK -** **_提供有效率地建置自訂智能合約所需的工具_** - [文件](https://portal.thirdweb.com/contracts/build/overview) - [GitHub](https://github.com/thirdweb-dev/contracts) -## 相關教程 {#related-tutorials} +## 相關教學 {#related-tutorials} -- [以太坊開發者的安全考量](/developers/docs/smart-contracts/security/) _– 構建智慧型合約時的安全考量使用教學，包括庫的使用。_ -- [瞭解 ERC-20 代幣智慧型合約](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _：關於 ERC20 標準的教學，由多個資料庫提供。_ +- [以太坊開發人員的安全性考量](/developers/docs/smart-contracts/security/) _– 關於建置智能合約時安全性考量的教學，包含函式庫的使用。_ +- [了解 ERC-20 代幣智能合約](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- 關於 ERC20 標準的教學，由多個函式庫提供。_ -## 衍生閱讀 {#further-reading} +## 延伸閱讀 {#further-reading} -_知道對你有幫助的社群資源嗎？ 請編輯此頁面並新增資源！_ +_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容！_ diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/naming/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/naming/index.md new file mode 100644 index 00000000000..7551f2c2095 --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/naming/index.md @@ -0,0 +1,101 @@ +--- +title: "智能合約命名" +description: "使用 ENS 為以太坊智能合約命名的最佳實踐" +lang: zh-tw +--- + +智能合約是以太坊去中心化基礎設施的基石，可實現自主應用程式和協議。 但即使合約功能不斷演進，使用者和開發者仍然依賴原始的十六進制地址來識別和引用這些合約。 + +使用 [Ethereum 名稱服務 (ENS)](https://ens.domains/) 為智能合約命名，可消除十六進制合約地址，改善使用者體驗，並降低地址投毒和欺騙攻擊等攻擊的風險。 本指南解釋了為智能合約命名的重要性、實施方法，以及可用於簡化流程並幫助開發者採用這種做法的工具，例如 [Enscribe](https://www.enscribe.xyz)。 + +## 為何要為智能合約命名？ {#why-name-contracts} + +### 人類可讀的識別碼 {#human-readable-identifiers} + +開發者和使用者可以使用人類可讀的名稱，如 `v2.myapp.eth`，而不用與像 `0x8f8e...f9e3` 這樣不透明的合約地址互動。 這簡化了智能合約的互動。 + +這是透過 [Ethereum 名稱服務](https://ens.domains/) 實現的，它為以太坊地址提供了去中心化的命名服務。 這與域名服務 (DNS) 讓網路使用者能夠使用像 ethereum.org 這樣的名稱來存取網路地址，而不是透過像 `104.18.176.152` 這樣的 IP 地址，是類似的道理。 + +### 提高安全性與信任度 {#improved-security-and-trust} + +命名的合約有助於減少意外交易到錯誤地址的情況。 它們還能幫助使用者識別與特定應用程式或品牌相關的合約。 這增加了一層聲譽信任，特別是當名稱附加到像 `uniswap.eth` 這樣知名的父網域時。 + +由於以太坊地址長達 42 個字元，使用者很難識別地址中的微小變化，例如幾個字元被修改。 例如，像 `0x58068646C148E313CB414E85d2Fe89dDc3426870` 這樣的地址，通常會被錢包等面向使用者的應用程式截斷為 `0x580...870`。 使用者不太可能注意到幾個字元被竄改的惡意地址。 + +這種技術被用於地址欺騙和投毒攻擊，讓使用者誤以為他們正在與正確的地址互動或向其發送資金，但實際上該地址只是看起來像正確的地址，並非完全相同。 + +錢包和合約的 ENS 名稱可以防範這類攻擊。 就像 DNS 欺騙攻擊一樣，ENS 欺騙攻擊也可能存在，但使用者更容易注意到 ENS 名稱中的拼寫錯誤，而不是十六進制地址中的微小修改。 + +### 為錢包和瀏覽器提供更好的使用者體驗 {#better-ux} + +當智能合約設定了 ENS 名稱後，錢包和區塊鏈瀏覽器等應用程式就可以顯示智能合約的 ENS 名稱，而不是十六進制地址。 這為使用者提供了顯著的使用者體驗 (UX) 提升。 + +例如，當與像 Uniswap 這樣的應用程式互動時，使用者通常會看到他們互動的應用程式託管在 `uniswap.org` 網站上，但如果 Uniswap 沒有用 ENS 為其智能合約命名，他們會看到一個十六進制合約地址。 如果合約被命名，他們可能會看到 `v4.contracts.uniswap.eth`，這更有用。 + +## 部署時命名 vs. 部署後命名 {#when-to-name} + +智能合約可以在兩個時間點命名： + +- **部署時**：在部署合約時為其分配一個 ENS 名稱。 +- **部署後**：將現有的合約地址對應到一個新的 ENS 名稱。 + +這兩種方法都依賴於對 ENS 網域擁有擁有者或管理者權限，以便他們能夠建立和設定 ENS 記錄。 + +## ENS 合約命名如何運作 {#how-ens-naming-works} + +ENS 名稱儲存在鏈上，並透過 ENS 解析器解析為以太坊地址。 為智能合約命名： + +1. 註冊或控制一個父 ENS 網域（例如 `myapp.eth`） +2. 建立一個子網域（例如 `v1.myapp.eth`） +3. 將子網域的 `address` 記錄設定為合約地址 +4. 將合約的反向記錄設定為 ENS，以允許透過其地址找到名稱 + +ENS 名稱是分層的，並支援無限的子名稱。 設定這些記錄通常需要與 ENS 註冊表和公共解析器合約進行互動。 + +## 合約命名工具 {#tools} + +有兩種方法可以為智能合約命名。 可以使用 [ENS 應用程式](https://app.ens.domains) 進行一些手動步驟，或者使用 [Enscribe](https://www.enscribe.xyz)。 以下將概述這些方法。 + +### 手動設定 ENS {#manual-ens-setup} + +使用 [ENS 應用程式](https://app.ens.domains/)，開發者可以手動建立子名稱並設定正向地址記錄。 但是，他們無法透過 ENS 應用程式為名稱設定反向記錄，從而為智能合約設定主名稱。 必須採取手動步驟，這些步驟在 [ENS 文件](https://docs.ens.domains/web/naming-contracts/) 中有詳細說明。 + +### Enscribe {#enscribe} + +[Enscribe](https://www.enscribe.xyz) 簡化了使用 ENS 的智能合約命名，並增強了使用者對智能合約的信任。 它提供： + +- **原子化部署與命名**：在部署新合約時分配一個 ENS 名稱 +- **部署後命名**：將名稱附加到已部署的合約 +- **多鏈支援**：在支援 ENS 的以太坊和 L2 網路上運作 +- **合約驗證資料**：包含從多個來源提取的合約驗證資料，以增加使用者的信任度 + +如果使用者沒有 ENS 名稱，Enscribe 支援使用者提供的 ENS 名稱或其自己的網域。 + +您可以存取 [Enscribe 應用程式](https://app.enscribe.xyz) 開始命名和查看智能合約。 + +## 最佳實踐 {#best-practices} + +- **使用清晰、有版本的名稱**，例如 `v1.myapp.eth`，使合約升級透明化 +- **設定反向記錄**，將合約連結到 ENS 名稱，以便在錢包和區塊鏈瀏覽器等應用程式中可見。 +- **密切監控到期時間**，以防止所有權意外變更 +- **驗證合約來源**，以便使用者可以信任命名的合約行為符合預期 + +## 風險 {#risks} + +為智能合約命名為以太坊使用者帶來了顯著的好處，但是，ENS 網域的擁有者必須對其管理保持警惕。 值得注意的風險包括： + +- **到期**：與 DNS 名稱一樣，ENS 名稱的註冊期限是有限的。 因此，擁有者必須監控其網域的到期日期，並在到期前及時續訂。 ENS 應用程式和 Enscribe 都會在網域即將到期時為網域擁有者提供視覺指示。 +- **所有權變更**：ENS 記錄在以太坊上以 NFT 的形式表示，特定 `.eth` 網域的擁有者擁有相關的 NFT。 因此，如果不同的帳戶取得了這個 NFT 的所有權，新擁有者可以隨意修改任何 ENS 記錄。 + +為了減輕此類風險，`.eth` 第二層網域 (2LD) 的擁有者帳戶應透過多重簽名錢包進行保護，並建立子網域來管理合約命名。 這樣，萬一在子網域層級發生任何意外或惡意的所有權變更，2LD 擁有者可以覆蓋這些變更。 + +## 合約命名的未來 {#future} + +合約命名正成為去中心化應用程式開發的最佳實踐，就像網域名稱取代了網路上的 IP 地址一樣。 隨著錢包、瀏覽器和儀表板等更多基礎設施整合合約的 ENS 解析，命名的合約將提高整個生態系統的安全性並減少錯誤。 + +透過使智能合約更容易識別和理解，命名有助於彌合以太坊上使用者和應用程式之間的差距，從而提高使用者的安全性和使用者體驗。 + +## 延伸閱讀 {#further-reading} + +- [使用 ENS 為智能合約命名](https://docs.ens.domains/web/naming-contracts/) +- [使用 Enscribe 為智能合約命名](https://www.enscribe.xyz/docs)。 diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/security/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/security/index.md index b9260c4c7bc..406c86936c8 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/security/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/security/index.md @@ -1,24 +1,24 @@ --- -title: 智慧型合約安全 -description: 建立安全的以太坊智慧型合約指南之概觀 +title: "智慧型合約安全" +description: "建立安全的以太坊智慧型合約指南之概觀" lang: zh-tw --- 智慧型合約極度靈活，且能夠控制大量值和資料，同時基於部署在區塊鏈上的程式碼執行不可變的邏輯。 這建立了活躍的去信任和去中心化的應用程式生態系統，它與傳統系統相比有許多優點。 這也為謀求透過智慧型合約漏洞獲利的攻擊者提供機會。 -公共區塊鏈，例如以太坊，使智慧型合約的安全議題更加複雜。 已部署的合約程式碼_通常_無法變更，以修補安全缺陷；而要追蹤從智慧型合約竊取的資產也十分困難，且因為物件的不可變性，大多無法挽回。 +公共區塊鏈，例如以太坊，使智慧型合約的安全議題更加複雜。 已部署的合約程式碼通常無法變更，以修補安全缺陷；而要追蹤從智慧型合約竊取的資產也十分困難，且因為物件的不可變性，大多無法挽回。 -雖然數字有差異，但因智慧型合約安全缺陷而遭竊取或損失的總額，估計超過 10 億美元。 備受關注的事件如 [DAO 駭客攻擊](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)（駭客竊取 360 萬以太幣，現價超過 10 億美元）；[Parity 多重簽章錢包駭客攻擊](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach)（駭客竊取 3 千萬美元）；以及 [Parity 凍結錢包問題](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether)（超過 3 億美元的以太幣遭到永久凍結）。 +雖然數字有差異，但因智慧型合約安全缺陷而遭竊取或損失的總額，估計超過 10 億美元。 這包括備受矚目的事件，例如 [DAO 駭客攻擊](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)（360 萬 ETH 被盜，以今日價格計算價值超過 10 億美元）、[Parity 多重簽章錢包駭客攻擊](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach)（駭客造成 3000 萬美元損失），以及 [Parity 錢包凍結問題](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether)（超過 3 億美元的 ETH 被永久鎖定）。 前面提到的問題，促使開發者將努力打造安全、健全且有韌性的智慧型合約視為當務之急。 我們必須嚴肅看待智慧型合約的安全性，每個開發者都需要好好加以瞭解。 此指南將涵蓋以太坊開發者應有的資安考量，並探索提升智慧型合約安全性的資源。 -## 基本資訊 {#prerequisites} +## 先決條件 {#prerequisites} -請務必熟悉[開發智慧型合約的基本知識](/developers/docs/smart-contracts/)，再來瞭解安全性。 +請務必熟悉開發智慧型合約的基本知識，再來瞭解安全性。 ## 建立安全的以太坊智慧型合約指南 {#smart-contract-security-guidelines} -### 1. 設計正確的存取控制 {#design-proper-access-controls} +### 1. 設計適當的存取控制 {#design-proper-access-controls} 在智慧型合約中，任何外部帳戶 (EOA) 或合約帳戶都可以調用標記為 `public` 或 `external` 的函數。 如果你想要其他人與你的智慧型合約互動，務必指定函數的公共可見性。 標記為 `private` 的函數只能被智慧型合約內部的函數調用，外部帳戶無法調用這種函數。 讓每個網路參與者存取智慧型合約函數可能造成一些問題，尤其是這表示人人都能執行須謹慎以對的操作（例如鑄造新代幣）。 @@ -28,7 +28,7 @@ lang: zh-tw 在可擁有模式下，會在建立合約的過程中，將一個地址設為合約的「擁有者」。 受保護的函數會配置一個 `OnlyOwner` 修飾符，確保執行函數前，先驗證調用地址的身分。 為防止不受歡迎的存取，合約擁有者以外的地址對受保護函數的調用都會遭到撤銷。 -#### 以角色為基礎的控制 {#role-based-access-control} +#### 以角色為基礎的存取控制 {#role-based-access-control} 在一個智慧型合約中，將一個地址註冊為 `Owner` 會導致集中風險及單點失效。 假如合約擁有者的帳戶金鑰遭竊，攻擊者就可以攻擊合約擁有者的智慧型合約。 這就是為什麼使用以角色為基礎的控制模式和多重管理帳戶可能是更好的方法。 @@ -58,8 +58,8 @@ contract VendingMachine { error Unauthorized(); function buy(uint amount) public payable { if (amount > msg.value / 2 ether) - revert("Not enough Ether provided."); - // Perform the purchase. + revert("提供的以太幣不足。"); + // 執行購買。 } function withdraw() public { if (msg.sender != owner) @@ -70,9 +70,9 @@ contract VendingMachine { } ``` -### 3. 測試智慧型合約和驗證程式碼的正確性 {#test-smart-contracts-and-verify-code-correctness} +### 3 測試智慧型合約並驗證程式碼的正確性 {#test-smart-contracts-and-verify-code-correctness} -在[以太坊虛擬機](/developers/docs/evm/)上執行的程式碼具備不可變性，代表智慧型合約在開發階段需要接受更高階的品質評估。 全面測試你的合約並注意任何超出預期的結果，將大大提升合約的安全性，且長期來看可保護使用者。 +在以太坊虛擬機上執行的程式碼具備不可變性，代表智慧型合約在開發階段需要接受更高階的品質評估。 全面測試你的合約並注意任何超出預期的結果，將大大提升合約的安全性，且長期來看可保護使用者。 常用方法是使用預期合約會接受的使用者模擬資料，來編寫小型單元測試。 [單元測試](/developers/docs/smart-contracts/testing/#unit-testing)適合測試特定函數的功能，並確保智慧型合約如預期運作。 @@ -80,9 +80,9 @@ contract VendingMachine { 更好的做法是結合單元測試與屬性測試，並運用[靜態和動態分析](/developers/docs/smart-contracts/testing/#static-dynamic-analysis)執行。 靜態分析依賴低階表示法，像是[控制流程圖](https://en.wikipedia.org/wiki/Control-flow_graph)和[抽象語法樹](https://deepsource.io/glossary/ast/)，來分析可觸及的程式狀態和執行路徑。 同時，動態分析技術（如[智慧型合約模糊測試](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)）則使用隨機輸入值執行合約程式碼，以偵測違反安全屬性的操作。 -[形式驗證](/developers/docs/smart-contracts/)是另一項驗證智慧型合約安全屬性的技術。 不同於一般測試，形式驗證可以确凿地證明智慧型合約不存在任何錯誤。 這種做法會建立描述預期安全屬性的形式規范，並證明合約的形式模型遵守此規范。 +[形式驗證](/developers/docs/smart-contracts/formal-verification)是另一項驗證智慧型合約安全屬性的技術。 不同於一般測試，形式驗證可以确凿地證明智慧型合約不存在任何錯誤。 這種做法會建立描述預期安全屬性的形式規范，並證明合約的形式模型遵守此規范。 -### 4 邀請獨立審查程式碼 {#get-independent-code-reviews} +### 4 要求對您的程式碼進行獨立審查 {#get-independent-code-reviews} 測試完合約後，最好請其他人來確認原始程式碼是否有任何安全性問題。 測試沒辦法涵蓋智慧型合約內的每一處瑕疵，但進行獨立審查可增加發現漏洞的可能性。 @@ -92,18 +92,18 @@ contract VendingMachine { 但是，你應該避免把審核當成一勞永逸地的解決方案。 智慧型合約審核不可能發現每一個錯誤，其主要目的是再次進行審查，幫助開發者偵測在開發初期和測試階段沒有發現的問題。 你也應該遵循與審核者合作的最佳案例，例如製作完整的程式碼記錄以及新增內嵌注釋，才能從智慧型合約審核中獲得最大效益。 -- [智慧型合約審核提示和技巧](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_ -- [充分利用你的審核](https://inference.ag/blog/2023-08-14-tips/) - _推理_ +- [智慧型合約審計技巧](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_ +- [充分利用您的審計](https://inference.ag/blog/2023-08-14-tips/) - _Inference_ -#### 漏洞懸賞 {#bug-bounties} +#### 漏洞賞金 {#bug-bounties} 設立漏洞懸賞賞計畫是另一個實現外部程式碼審查的方法。 漏洞懸賞會發放經濟性獎勵給發現應用程式漏洞的個人（通常是白帽駭客）。 -若正確運用，漏洞懸賞可以給予駭客社群檢查你程式碼重大缺陷的動機。 一個實際案例是「無限貨幣錯誤」，讓攻擊者可以在以太坊的[二層](/layer-2/)協定 [Optimism](https://www.optimism.io/) 上建立無限數量的以太幣。 幸好有位白帽駭客[發現了這個缺陷](https://www.saurik.com/optimism.html)，並通知了相關團隊[，因此獲得了一大筆獎金](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/)。 +若正確運用，漏洞懸賞可以給予駭客社群檢查你程式碼重大缺陷的動機。 一個實際案例是「無限貨幣錯誤」，讓攻擊者可以在以太坊的[第 2 層](/layer-2/)協定 [Optimism](https://www.optimism.io/) 上建立無限數量的以太幣。 幸運的是，一位白帽駭客[發現了這個漏洞](https://www.saurik.com/optimism.html)並通知了團隊，[在此過程中獲得了巨額獎金](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/)。 -有效的漏洞懸賞獎金機制，應與面臨風險的資金成比例。 就像「[Scaling Bug Bounty（擴大漏洞懸賞）](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)」一文所說，這種方法讓人在財務上有動機盡責揭露，而非利用漏洞。 +有效的漏洞懸賞獎金機制，應與面臨風險的資金成比例。 就像「[擴展性漏洞賞金](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)」一文所說，這種方法讓人在財務上有動機盡責揭露，而非利用漏洞。 -### 5 開發智慧型合約時遵循最佳案例 {#follow-smart-contract-development-best-practices} +### 5 在智慧型合約開發過程中遵循最佳實踐 {#follow-smart-contract-development-best-practices} 不能因為有審核和漏洞懸賞就不盡責編寫高品質程式碼。 優良的智慧型合約安全性始於遵循正確的設計和開發流程： @@ -121,7 +121,7 @@ contract VendingMachine { - 正確記錄程式碼（使用 [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)），並運用簡單易懂的語言詳細描述合約架構。 這樣才容易讓其他人審核和審查你的程式碼。 -### 6. 採行健全的災害復原計畫 {#implement-disaster-recovery-plans} +### 6. 實施健全的災難復原計畫 {#implement-disaster-recovery-plans} 設計安全的存取控制、採用函數修飾符和其他上述提議，可改善智慧型合約安全，但不能排除惡意入侵的可能性。 建立安全的智慧型合約需要做好「防範錯誤的準備」，以及對攻擊作出有效反應的備援計畫。 正確的災害復原計畫包含下列部分或全部要素： @@ -129,13 +129,13 @@ contract VendingMachine { 雖然以太坊智慧型合約是預設不得變更，但可以透過升級模式來達成某程度的變更。 當重大缺陷迫使舊合約無法使用，而部署新邏輯是最可行的選擇時，就必須升級合約。 -合約升級機制的運作方式不同，「代理人模式」是升級智慧型合約最常見的方法。 [代理人模式](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern)會將應用程式的狀態和邏輯拆分成_兩個_合約。 第一個合約（稱為「代理人合約」）儲存狀態變數（例如使用者餘額）；第二個合約（稱為「邏輯合約」）保存執行合約函數的程式碼。 +合約升級機制的運作方式不同，「代理人模式」是升級智慧型合約最常見的方法。 [代理模式](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern)將應用程式的狀態和邏輯拆分到_兩個_合約之間。 第一個合約（稱為「代理人合約」）儲存狀態變數（例如使用者餘額）；第二個合約（稱為「邏輯合約」）保存執行合約函數的程式碼。 -帳戶只和代理人合約互動，代理人合約再用低階調用 [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) 發送所有函數調用至邏輯合約。 和一般的訊息調用不同，`delegatecall()` 會確保在邏輯合約地址上執行的程式碼是在調用合約的情境下執行。 這表示邏輯合約將永遠把資料寫入代理人的存儲空間（而不是自己的存儲空間），且會保留 `msg.sender` 與 `msg.value` 的原始值。 +帳戶與代理合約互動，代理合約使用 [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) 低層級呼叫將所有函數呼叫分派給邏輯合約。 和一般的訊息調用不同，`delegatecall()` 會確保在邏輯合約地址上執行的程式碼是在調用合約的情境下執行。 這表示邏輯合約將永遠寫入代理合約的儲存空間（而非自己的儲存空間），並且 `msg.sender` 和 `msg.value` 的原始值會被保留。 委託邏輯合約的調用必須將其地址儲存在代理人合約的存儲空間。 因此，升級合約的邏輯只是部署另一個邏輯合約，並將新地址儲存至代理人合約。 之後，代理人合約的調用都會自動傳送至新的邏輯合約，讓你在未實際修改程式碼的情況下「升級」合約。 -[更多升級合約相關資訊](/developers/docs/smart-contracts/upgrading/)。 +[更多關於升級合約的資訊](/developers/docs/smart-contracts/upgrading/)。 #### 緊急停止 {#emergency-stops} @@ -149,10 +149,10 @@ contract VendingMachine { 3. 可以存取緊急停止函數的實體，可將布林變數設定為 `true`。 為防止惡意行動，可以限制只有受信任地址（例如，合約持有人）才可調用此函數。 -一旦合約啟動緊急停止，將無法調用特定函數。 藉由將指定函數包裹在參照全域變數的修飾符中來達成此目的。 以下是說明如何在合約中採用此模式的[範例](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol)： +一旦合約啟動緊急停止，將無法調用特定函數。 藉由將指定函數包裹在參照全域變數的修飾符中來達成此目的。 以下是描述在合約中實作此模式的[一個範例](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol)： ```solidity -// This code has not been professionally audited and makes no promises about safety or correctness. Use at your own risk. +// 此程式碼未經專業審核，不保證其安全性或正確性。使用風險自負。 contract EmergencyStop { @@ -169,7 +169,7 @@ contract EmergencyStop { } modifier onlyAuthorized { - // Check for authorization of msg.sender here + // 在此檢查 msg.sender 的授權 _; } @@ -182,11 +182,11 @@ contract EmergencyStop { } function deposit() public payable stoppedInEmergency { - // Deposit logic happening here + // 存款邏輯在此發生 } function emergencyWithdraw() public onlyWhenStopped { - // Emergency withdraw happening here + // 緊急提款在此發生 } } ``` @@ -205,21 +205,21 @@ contract EmergencyStop { [事件](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events)可以追蹤智慧型合約函數調用狀況和監控狀態變數的變化。 理想做法是當某一方執行攸關安全的行動（例如，提領資金）時，讓智慧型合約釋出事件。 -記錄事件和鏈外監控事件，可以掌握合約運作狀況並有助及早發現惡意行動。 這表示你的團隊可以快速對駭客攻擊做出反應，並採取行動減輕對使用者的衝擊，例如：暫停函數或執行升級。 +記錄事件和鏈下監控事件，可以掌握合約運作狀況並有助及早發現惡意行動。 這表示你的團隊可以快速對駭客攻擊做出反應，並採取行動減輕對使用者的衝擊，例如：暫停函數或執行升級。 你也可以選擇現成的監控工具，在有人和你的合約互動時，這些工具會自動傳送警告通知。 這些工具可讓你基於不同的觸發器，例如：交易量、函數調用頻率或涉及特定函數時，建立自訂警告通知。 例如：你可以編寫在單筆交易提款金額超過特定閾值時傳送警告。 -### 7. 設計安全治理體系 {#design-secure-governance-systems} +### 7. 設計安全的管理體系 {#design-secure-governance-systems} -你可能想要藉由移交重要智慧型合約的控制權給社群成員，來分散管理（去中心化）應用程式。 這種情況下，智慧型合約系統將包含一個治理模組，也就是允許社群成員透過鏈上治理體系核准管理行動的機制。 例如，採納升級代理人合約的提案，可由代幣持有人投票決定。 +你可能想要藉由移交重要智慧型合約的控制權給社群成員，來分散管理（去中心化）應用程式。 這種情況下，智能合約系統將包含一個治理模組，也就是允許社群成員透過鏈上治理體系核准管理行動的機制。 例如，採納升級代理人合約的提案，可由代幣持有人投票決定。 去中心化治理的好處在於讓開發者和終端使用者的利益一致。 儘管如此，若未正確落實智慧型合約治理機制，仍可能產生新的風險。 可能出現的情況是，一位攻擊者透過[閃電貸](/defi/#flash-loans)取得大量投票權（以持有代幣數量決定），推動通過惡意提案。 -預防鏈上治理相關問題的方法之一是[使用時間鎖定](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/)。 時間鎖定是直到特定時間過後，才讓智慧型合約執行某些動作。 其他策略包括：根據每一個代幣被鎖定的時間賦予「投票加權」，或以歷史期間（例如：過去的 2-3 個區塊）而不是目前區塊，來衡量一個地址的投票權。 這兩種方法都能降低快速累積投票權，進而影響鏈上投票結果的情況。 +防止與鏈上管理體系相關問題的一種方法是[使用時間鎖](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/)。 時間鎖定是直到特定時間過後，才讓智慧型合約執行某些動作。 其他策略包括：根據每一個代幣被鎖定的時間賦予「投票加權」，或以歷史期間（例如：過去的 2-3 個區塊）而不是目前區塊，來衡量一個地址的投票權。 這兩種方法都能降低快速累積投票權，進而影響鏈上投票結果的情況。 -藉由共享連結，了解關於[設計安全管理體系](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)、[去中心化自治組織的不同投票機制](https://hackernoon.com/governance-is-the-holy-grail-for-daos)，以及[利用去中心化金融的常見去中心化自治組織攻擊媒介](https://dacian.me/dao-governance-defi-attacks)的更多資訊。 +共享連結中有更多關於[設計安全管理體系](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)、[DAO 中不同的投票機制](https://hackernoon.com/governance-is-the-holy-grail-for-daos)以及[利用 DeFi 的常見 DAO 攻擊途徑](https://dacian.me/dao-governance-defi-attacks)的資訊。 -### 8. 將程式碼的複雜性降到最低 {#reduce-code-complexity} +### 8. 將程式碼的複雜性降至最低 {#reduce-code-complexity} 傳統的軟體開發者都熟悉 KISS (「保持簡約」)，也就是不要在軟體中引進不必要複雜設計的原則。 這是因為長期以來，人們都認為「複雜系統會發生複雜的故障」，且更容易造成代價高昂的錯誤。 @@ -227,9 +227,9 @@ contract EmergencyStop { 另一個建議是編寫小型函數，並將商業邏輯拆分成多個合約，確立模組化合約。 編寫較簡單的程式碼不只能縮小智慧型合約中的受攻擊面，也使判斷整個系統的正確性更簡單，亦能提早偵測可能的設計錯誤。 -### 9. 防範一般的智慧型合約漏洞 {#mitigate-common-smart-contract-vulnerabilities} +### 9. 防禦常見的智慧型合約漏洞 {#mitigate-common-smart-contract-vulnerabilities} -#### 重入攻擊 {#reentrancy} +#### 重入 {#reentrancy} 以太坊虛擬機不允許並行執行，也就是無法同時執行牽涉同一訊息調用的兩個合約。 一個外部調用會終止調用合約的執行和記憶體，直到這個調用返回結果，這時才會繼續正常執行。 這個過程可被正式稱為將[控制流程](https://www.computerhope.com/jargon/c/contflow.htm)轉移到另一個合約。 @@ -238,7 +238,7 @@ contract EmergencyStop { 試想有個簡單的智慧型合約（稱為「Victim」），可以讓任何人存入與提領以太幣： ```solidity -// This contract is vulnerable. Do not use in production +// 此合約有漏洞。請勿在生產環境中使用 contract Victim { mapping (address => uint256) public balances; @@ -256,15 +256,15 @@ contract Victim { } ``` -此合約公布了一個 `withdraw()` 函數，允許使用者提領先前存入合約內的以太幣。 處理提款時，合約執行以下操作： +此合約公布了一個 `withdraw()` 函數，允許使用者提領先前存入合約內的 ETH。 處理提款時，合約執行以下操作： 1. 檢查使用者的以太幣餘額 2. 匯出資金至調用地址 3. 將餘額重置為 0，避免使用者進一步提領 -`Victim` 合約中的 `withdraw()` 函數遵循「檢查-互動-效果」模式。 若滿足必要的執行條件，就會進行_檢查_（即使用者的以太幣餘額是正數)，接著再傳送以太幣至調用者的地址，進行_互動_，最後套用交易_效果_（即減少使用者的餘額）。 +`Victim` 合約中的 `withdraw()` 函數遵循「檢查-互動-效果」模式。 它會_檢查_執行所需的條件是否滿足（例如，使用者有正的 ETH 餘額），然後執行_互動_，將 ETH 發送給呼叫者地址，最後才應用交易的_效果_（例如，減少使用者的餘額）。 -假如是外部帳戶 (EOA) 調用 `withdraw()`，函數將如預期執行：`msg.sender.call.value()` 傳送以太幣給調用者。 然而，如果調用 `withdraw()` 的 `msg.sender` 是智慧型合約帳戶，使用`msg.sender.call.value()` 傳送資金，也會觸發儲存在該帳戶地址的程式碼執行。 +假如是外部帳戶 (EOA) 調用 `withdraw()`，函數將如預期執行：`msg.sender.call.value()` 傳送 ETH 給調用者。 然而，如果調用 `withdraw()` 的 `msg.sender` 是智慧型合約帳戶，使用 `msg.sender.call.value()` 傳送資金，也會觸發儲存在該帳戶地址的程式碼執行。 試想這是部署在合約地址的程式碼： @@ -289,26 +289,26 @@ contract Victim { 2. 存入 1 以太幣至 Victim 合約 3. 提領存儲在智慧型合約中的 1 以太幣 -這裡沒有任何問題，除了傳入 `msg.sender.call.value` 剩餘的燃料超過 40,000 時，`Attacker` 中的另一個函數會再次調用 `Victim` 內的 `withdraw()`。 這讓 `Attacker` 在第一次調用 `withdraw` 結束_之前_，可以一再進入 `Victim` 提領更多資金。 這個循環看起來像這樣： +這裡沒有任何問題，除了傳入 `msg.sender.call.value` 剩餘的 gas 超過 40,000 時，`Attacker` 中的另一個函數會再次調用 `Victim` 內的 `withdraw()`。 這讓 `Attacker` 在第一次調用 `withdraw` 結束之前，可以一再進入 `Victim` 提領更多資金。 這個循環看起來像這樣： ```solidity -- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH -- `Attacker.beginAttack()` deposits 1 ETH into `Victim` -- `Attacker` calls `withdraw() in `Victim` -- `Victim` checks `Attacker`’s balance (1 ETH) -- `Victim` sends 1 ETH to `Attacker` (which triggers the default function) -- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal) -- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call) -- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function) -- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals -- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0 +- 攻擊者的 EOA 以 1 ETH 呼叫 `Attacker.beginAttack()` +- `Attacker.beginAttack()` 將 1 ETH 存入 `Victim` +- `Attacker` 呼叫 `Victim` 中的 `withdraw() +- `Victim` 檢查 `Attacker` 的餘額 (1 ETH) +- `Victim` 發送 1 ETH 給 `Attacker` (這會觸發預設函數) +- `Attacker` 再次呼叫 `Victim.withdraw()` (注意，`Victim` 尚未減少 `Attacker` 第一次提款後的餘額) +- `Victim` 檢查 `Attacker` 的餘額 (仍然是 1 ETH，因為它還沒有應用第一次呼叫的效果) +- `Victim` 發送 1 ETH 給 `Attacker` (這會觸發預設函數並允許 `Attacker` 重新進入 `withdraw` 函數) +- 這個過程會重複直到 `Attacker` 的 gas 耗盡，此時 `msg.sender.call.value` 會返回，而不會觸發額外的提款 +- `Victim` 最後將第一次交易（及後續交易）的結果應用到其狀態，因此 `Attacker` 的餘額被設為 0 ``` -總起來說，因為調用者的餘額並非 0，直到函數執行結束前，後續的調用都能成功執行，並允許調用者多次提領餘額。 這類攻擊可以被用於將智慧型合約內的所有資金提領一空，如同 [2016 年的 DAO 駭客攻擊](https://www.coindesk.com/learn/understanding-the-dao-attack)。 就像[重入入侵公開清單](https://github.com/pcaversaccio/reentrancy-attacks)所示，如今重入攻擊仍是智慧型合約面臨的嚴重問題。 +總起來說，因為調用者的餘額並非 0，直到函數執行結束前，後續的調用都能成功執行，並允許調用者多次提領餘額。 這類攻擊可以被用於將智慧型合約內的所有資金提領一空，如同 [2016 年的 DAO 駭客攻擊](https://www.coindesk.com/learn/understanding-the-dao-attack)。 正如[重入攻擊的公開列表](https://github.com/pcaversaccio/reentrancy-attacks)所示，重入攻擊至今仍然是智慧型合約的一個關鍵問題。 ##### 如何預防重入攻擊 -處理重入攻擊的方法是遵循[檢查 - 效果 - 互動模式](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern)。 這個模式指示函數如以下次序執行，在繼續執行下一個動作前，必須先執行進行必要檢查的程式碼，然後是執行操縱合約狀態的程式碼，最後才執行與其他合約或外部帳戶互動的程式碼。 +處理重入問題的一種方法是遵循[檢查-效果-互動模式](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern)。 這個模式指示函數如以下次序執行，在繼續執行下一個動作前，必須先執行進行必要檢查的程式碼，然後是執行操縱合約狀態的程式碼，最後才執行與其他合約或外部帳戶互動的程式碼。 依照檢查 - 效果 - 互動模式改寫 `Victim` 合約如下： @@ -323,7 +323,7 @@ contract NoLongerAVictim { } ``` -這個合約如下執行：_檢查_使用者餘額、套用 `withdraw()` 函數的_效果_（將使用者的餘額重置為 0），再繼續執行_互動_（傳送以太幣至使用者地址）。 這能確保合約在外部調用前更新存儲空間，排除會引發第一次攻擊的重入條件。 `Attacker` 合約仍然可能回呼 `NoLongerAVictim`，但因為 `balances[msg.sender]` 已設定為 0，所以再次提領時會出現錯誤。 +此合約會對使用者的餘額執行_檢查_，套用 `withdraw()` 函數的_效果_（透過將使用者餘額重設為 0），然後繼續執行_互動_（將 ETH 發送至使用者地址）。 這能確保合約在外部調用前更新存儲空間，排除會引發第一次攻擊的重入條件。 `Attacker` 合約仍然可能回呼 `NoLongerAVictim`，但因為 `balances[msg.sender]` 已設定為 0，所以再次提領時會出現錯誤。 另一個方法是使用相斥鎖定（一般稱為「Mutex」），鎖定合約的部分狀態，直到完成函數調用。 這個方法是在函數執行前，將一個布林變數設定為 `true`，調用完成後再把布林變數回復為 `false`。 如以下範例所示，使用 Mutex 可保護函數在初始調用尚未完成前，不被重複調用，並有效阻止重入。 @@ -335,18 +335,18 @@ contract MutexPattern { mapping(address => uint256) public balances; modifier noReentrancy() { - require(!locked, "Blocked from reentrancy."); + require(!locked, "已阻擋重入攻擊。"); locked = true; _; locked = false; } - // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again. - // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier + // 此函數受到互斥鎖保護，因此來自 `msg.sender.call` 內部的重入呼叫無法再次呼叫 `withdraw`。 + // `return` 陳述式求值為 `true`，但仍會對修飾符中的 `locked = false` 陳述式求值 function withdraw(uint _amount) public payable noReentrancy returns(bool) { - require(balances[msg.sender] >= _amount, "No balance to withdraw."); + require(balances[msg.sender] >= _amount, "沒有足夠的餘額可供提領。"); balances[msg.sender] -= _amount; - bool (success, ) = msg.sender.call{value: _amount}(""); + (bool success, ) = msg.sender.call{value: _amount}(""); require(success); return true; @@ -360,26 +360,26 @@ contract MutexPattern { 算術運算結果超出可接受數值範圍，必須「退位」至最低代表值時，就是整數上溢。 例如：`uint8` 最多只能儲存相當於 2^8-1=255 的值。 若算術運算結果導致大於 `255` 的值，就屬於上溢，並會將 `uint` 重置為 `0`，類似汽車里程表達到里程數上限 (999999) 時，將重置為 0。 -整數下溢的發生原因也是如此：算術運算結果小於可接受範圍。 例如你嘗試要對 `uint8` 的 `0` 進行遞減，結果就會是進位至最高代表值 (`255`)。 +整數下溢的發生原因也是如此：算術運算結果小於可接受範圍。 比方說，您試圖在 `uint8` 中對 `0` 進行遞減，結果將會直接循環到最大可表示值 (`255`)。 整數上溢和下溢都可能對合約狀態變數產生非預期的變更，導致預料外的執行。 以下範例顯示攻擊者可以利用智慧型合約內的算術上溢執行無效操作： ``` pragma solidity ^0.7.6; -// This contract is designed to act as a time vault. -// User can deposit into this contract but cannot withdraw for at least a week. -// User can also extend the wait time beyond the 1 week waiting period. +// 這個合約被設計為一個時間金庫。 +// 使用者可以存入此合約，但至少一週內不能提款。 +// 使用者也可以將等待時間延長超過一週。 /* -1. Deploy TimeLock -2. Deploy Attack with address of TimeLock -3. Call Attack.attack sending 1 ether. You will immediately be able to - withdraw your ether. - -What happened? -Attack caused the TimeLock.lockTime to overflow and was able to withdraw -before the 1 week waiting period. +1. 部署 TimeLock +2. 部署帶有 TimeLock 地址的 Attack +3. 呼叫 Attack.attack 並發送 1 ether。您將能夠立即 + 提領您的 ether。 + +發生了什麼事？ +Attack 導致 TimeLock.lockTime 發生上溢，並能夠在 +一週的等待期結束前提領。 */ contract TimeLock { @@ -396,14 +396,14 @@ contract TimeLock { } function withdraw() public { - require(balances[msg.sender] > 0, "Insufficient funds"); - require(block.timestamp > lockTime[msg.sender], "Lock time not expired"); + require(balances[msg.sender] > 0, "資金不足"); + require(block.timestamp > lockTime[msg.sender], "鎖定時間尚未到期"); uint amount = balances[msg.sender]; balances[msg.sender] = 0; (bool sent, ) = msg.sender.call{value: amount}(""); - require(sent, "Failed to send Ether"); + require(sent, "發送 Ether 失敗"); } } @@ -419,11 +419,11 @@ contract Attack { function attack() public payable { timeLock.deposit{value: msg.value}(); /* - if t = current lock time then we need to find x such that + 如果 t = 目前的鎖定時間，那麼我們需要找到 x 使得 x + t = 2**256 = 0 - so x = -t + 所以 x = -t 2**256 = type(uint).max + 1 - so x = type(uint).max + 1 - t + 所以 x = type(uint).max + 1 - t */ timeLock.increaseLockTime( type(uint).max + 1 - timeLock.lockTime(address(this)) @@ -435,13 +435,13 @@ contract Attack { ##### 如何預防整數下溢和上溢 -自 0.8.0 版本起，Solidity 編譯器拒絕使用會導致整數下溢和上溢的程式碼。 然而，使用較低版本編譯器編譯的合約應該檢查涉及算術運算的函數，或使用庫（例如 [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)）來檢查下溢/上溢。 +自 0.8.0 版本起，Solidity 編譯器拒絕使用會導致整數下溢和上溢的程式碼。 然而，使用較低版本編譯器編譯的合約應該檢查涉及算術運算的函數，或使用庫（例如，[SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)）來檢查下溢/上溢。 -#### 操縱預言機 {#oracle-manipulation} +#### 預言機操縱 {#oracle-manipulation} -[預言機](/developers/docs/oracles/)會取得鏈外資訊，並把這些資訊傳到鏈上供智慧型合約使用。 使用預言機，可以設計與鏈外系統（例如資本市場）互通的智慧型合約，大幅拓展應用範圍。 +[預言機](/developers/docs/oracles/)會取得鏈下資訊，並把這些資訊傳到鏈上供智慧型合約使用。 使用預言機，可以設計與鏈下系統（例如資本市場）互通的智慧型合約，大幅拓展應用範圍。 -然而，若預言機遭到破壞，將不正確的資訊傳到鏈上，智慧型合約將會根據不正確輸入資料執行，可能引起問題。 這是「預言機問題」的基礎，也就是要確保來自區塊鏈預言機的是正確、及時的最新資訊。 +然而，若預言機遭到破壞，將不正確的資訊傳到鏈上，智能合約將會根據不正確輸入資料執行，可能引起問題。 這是「預言機問題」的基礎，也就是要確保來自區塊鏈預言機的是正確、及時的最新資訊。 可能產生的相關安全性疑慮，就是使用如去中心化交易所等鏈上預言機，取得資產的現貨價格。 [去中心化金融 (DeFi)](/defi/) 產業的借貸平台通常都藉此判斷使用者抵押品的價值，再決定借貸額度。 @@ -455,37 +455,37 @@ contract Attack { 若你打算在鏈上預言機查詢資產價格，可考慮使用採用時間加權平均價格 (TWAP) 機制的預言機。 [時間加權平均價格預言機](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles)會查詢兩個不同時間點（你可以更改時間點）的資產價格，再根據得到數據的平均值計算現貨價值。 選擇時間較長的價格可保護協定免於價格操縱，因為近期大量的交易下單不會對資產價格造成影響。 -## 開發者的智慧型合約安全性資源 {#smart-contract-security-resources-for-developers} +## 開發人員的智慧型合約安全性資源 {#smart-contract-security-resources-for-developers} -### 分析智慧型合約和驗證程式碼正確性的工具 {#code-analysis-tools} +### 用於分析智慧型合約和驗證程式碼正確性的工具 {#code-analysis-tools} -- **[測試工具和庫](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _一系列執行智慧型合約單元測試、靜態分析和動態分析的產業標準工具和庫。_ +- **[測試工具和函式庫](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _一系列執行智慧型合約單元測試、靜態分析和動態分析的產業標準工具和庫。_ -- **[形式驗證工具](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools) - **_驗證智慧型合約功能正確性和檢查不變性的工具。_ +- **[形式驗證工具](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _用於驗證智慧型合約中的功能正確性和檢查不變量的工具。_ -- **[智慧型合約審核服務](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)**：_提供以太坊開發專案智慧型合約審核服務的組織清單。_ +- **[智慧型合約審核服務](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _提供以太坊開發專案智慧型合約審核服務的組織清單。_ -- **[漏洞懸賞平台](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _協調漏洞懸賞計畫和發放獎金給揭發智慧型合約重大漏洞者的平台。_ +- **[漏洞賞金平台](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _協調漏洞懸賞計畫和發放獎金給揭發智慧型合約重大漏洞者的平台。_ - **[分叉檢查工具](https://forkchecker.hashex.org/)** - _檢查分叉合約所有可用資訊的線上免費工具。_ -- **[應用程式二進制介面編碼器](https://abi.hashex.org/)** - _對 Solidity 合約的函數和建構函數引數進行編碼的線上免費服務。_ +- **[ABI 編碼器](https://abi.hashex.org/)** - _對 Solidity 合約的函數和建構函數引數進行編碼的線上免費服務。_ - **[Aderyn](https://github.com/Cyfrin/aderyn)** - _Solidity 靜態分析器，透過周遊抽象語法樹 (AST) 找出可疑漏洞，並以易於使用的 Markdown 格式列印問題。_ -### 監視智慧型合約的工具 {#smart-contract-monitoring-tools} +### 監控智慧型合約的工具 {#smart-contract-monitoring-tools} -- **[Tenderly Real-Time Alerting](https://tenderly.co/alerting/)**：_當智慧型合約或錢包出現不尋常的和意外事件時，可以獲得即時通知的工具。_ +- **[Tenderly Real-Time Alerting](https://tenderly.co/monitoring)** - _當智慧型合約或錢包出現不尋常的和意外事件時，可以獲得即時通知的工具。_ -### 智慧型合約的安全管理工具 {#smart-contract-administration-tools} +### 安全管理智慧型合約的工具 {#smart-contract-administration-tools} -- **[Safe](https://safe.global/)** - _在以太坊上執行、需要達到最低核准人數（N 人中的M 人），才能執行交易的智慧型合約數位錢包。_ +- **[Safe](https://safe.global/)** - _在以太坊上執行、需要達到最低核准人數（N 人中的M 人），才能執行交易的智慧型合約錢包。_ -- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _執行合約所有權、升級、存取控制、治理、暫停等管理功能的合約庫。_ +- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _執行合約所有權、升級、存取控制、管理體系、暫停等管理功能的合約庫。_ ### 智慧型合約審核服務 {#smart-contract-auditing-services} -- **[ConsenSys Diligence](https://consensys.net/diligence/)** - _協助區塊鏈生態系系統中的專案，確保其協定處於可發布狀態，且用於保護使用者的智慧型合約審核服務。_ +- **[ConsenSys Diligence](https://diligence.consensys.io/)** - _協助區塊鏈生態系系統中的專案，確保其協定處於可發布狀態，且用於保護使用者的智慧型合約審核服務。_ - **[CertiK](https://www.certik.com/)** - _率先致力於智慧型合約和區塊鏈網路上使用最新形式驗證技術的區塊鏈安全公司。_ @@ -505,7 +505,7 @@ contract Attack { - **[HashEx](https://hashex.org/)** - _HashEx 專注於區塊鏈和智慧型合約審核，以確保加密貨幣的安全性，提供智慧型合約開發、滲透測試、區塊鏈諮詢等服務。_ -- **[Code4rena](https://code4rena.com/)** - _鼓勵智慧型合約安全性專家找出漏洞，並協助提升 Web3 安全性，富競爭力的審核平台。_ +- **[Code4rena](https://code4rena.com/)** - _鼓勵智慧型合約安全性專家找出漏洞，並協助提升 web3 安全性，富競爭力的審核平台。_ - **[CodeHawks](https://codehawks.com/)** - _舉辦面向安全研究人員的智慧型合約審核比賽的競爭性審核平台。_ @@ -513,23 +513,23 @@ contract Attack { - **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _Web3 安全公司，透過經驗豐富的審核者團隊和一流工具，為區塊鏈系統提供安全審核。_ -- **[Oxorio](https://oxor.io/)** - _智慧型合約審核和區塊鏈安全服務，在以太坊虛擬機、Solidity、零知識、加密公司和去中心化金融專案的跨鏈技術方面擁有深厚的專業知識。_ +- **[Oxorio](https://oxor.io/)** - _智慧型合約審核和區塊鏈安全服務，在 EVM、Solidity、零知識、加密公司和 DeFi 專案的跨鏈技術方面擁有深厚的專業知識。_ -- **[Inference](https://inference.ag/)** - _安全審核公司，專注基於以太坊虛擬機區塊鏈的智慧型合約審核。 透過專家審核者的幫助，他們能發現潛在問題並提出可行的解決方案，以便在部署前解決這些問題。_ +- **[Inference](https://inference.ag/)** - _安全審核公司，專注基於 EVM 區塊鏈的智慧型合約審核。 透過專家審核者的幫助，他們能發現潛在問題並提出可行的解決方案，以便在部署前解決這些問題。_ -### 漏洞懸賞平台 {#bug-bounty-platforms} +### 漏洞賞金平台 {#bug-bounty-platforms} -- **[Immunefi](https://immunefi.com/)** - _這是智慧型合約和去中心化金融專案漏洞懸賞平台。安全研究員在此審核程式碼、找出漏洞、獲得報酬、使加密貨幣更安全。_ +- **[Immunefi](https://immunefi.com/)** - _這是智慧型合約和 DeFi 專案漏洞懸賞平台。安全研究員在此審核程式碼、找出漏洞、獲得報酬、使加密貨幣更安全。_ -- **[HackerOne](https://www.hackerone.com/)** - _連結商業和滲透測試者及安全研究者的漏洞協調和漏洞懸賞平台。_ +- **[HackerOne](https://www.hackerone.com/)** - _連結商業和滲透測試者及安全研究者的漏洞協調和漏洞賞金平台。_ -- **[HackenProof](https://hackenproof.com/)** - _專業的加密貨幣專案（去中心化金融、智慧型合約、錢包、中心化交易所等）漏洞懸賞平台。安全專業人士在此提供分類服務，而研究者可以在提出重要、經過驗證的錯誤報告時獲得報酬。_ +- **[HackenProof](https://hackenproof.com/)** - _專業的加密貨幣專案（DeFi、智慧型合約、錢包、中心化交易所等）漏洞賞金平台。安全專業人士在此提供分類服務，而研究者可以在提出重要、經過驗證的錯誤報告時獲得報酬。_ -- **[Sherlock](https://www.sherlock.xyz/)** - _Web3 中的智慧型合約安全承銷商，透過智慧型合約管理對審核者的支出，以確保相關漏洞得到公平償付。_ +- **[Sherlock](https://www.sherlock.xyz/)** - _Web3 中的智慧型合約安全承銷商，透過智慧型合約管理對審核者的支出，以確保相關漏洞得到公平償付。_ -- **[CodeHawks](https://www.codehawks.com/)** - _競爭性漏洞懸賞平台，審核者可以在其中參與安全競賽和挑戰，以及自己的私人審核（即將推出）。_ +- **[CodeHawks](https://www.codehawks.com/)** - _競爭性漏洞賞金平台，審核者可以在其中參與安全競賽和挑戰，以及自己的私人審核（即將推出）。_ -### 已知的智慧型合約漏洞和弱點出版品 {#common-smart-contract-vulnerabilities-and-exploits} +### 已知的智慧型合約漏洞與攻擊手法出版物 {#common-smart-contract-vulnerabilities-and-exploits} - **[ConsenSys：已知的智慧型合約攻擊](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _以適合初學者的方式解說最重大的合約漏洞，大部分案例會附上範例程式碼。_ @@ -539,38 +539,38 @@ contract Attack { ### 學習智慧型合約安全性的挑戰 {#challenges-for-learning-smart-contract-security} -- **[優質的 BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _區塊鏈安全性的實戰演習、挑戰、和[奪旗](https://www.webopedia.com/definitions/ctf-event/amp/)競賽和解決方案評論精選清單。_ +- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _區塊鏈安全戰爭遊戲、挑戰、[奪旗賽](https://www.webopedia.com/definitions/ctf-event/amp/)以及解決方案說明的精選清單。_ -- **[脆弱不堪的去中心化金融](https://www.damnvulnerabledefi.xyz/)** - _學習去中心化金融智慧型合約攻撃性安全防衛的實戰演習，以及培養找出錯誤和審核安全性的技能。_ +- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _學習 DeFi 智慧型合約攻撃性安全防衛的實戰演習，以及培養找出錯誤和審核安全性的技能。_ - **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _以 Web3/Solidity 為中心的實戰演習，每一個等級都是一個必須被「駭客破解」的智慧型合約。_ -- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _智慧型合約駭客挑戰，以奇幻冒險為背景。 成功完成挑戰還可以入圍非公開的漏洞懸賞計劃。_ +- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _以奇幻冒險為背景的智慧型合約駭客挑戰。 成功完成挑戰還可以入圍非公開的漏洞賞金計劃。_ -### 保護智慧型合約的最佳案例 {#smart-contract-security-best-practices} +### 保護智慧型合約的最佳做法 {#smart-contract-security-best-practices} -- **[ConsesSys：以太坊智慧型合約安全性最佳案例](https://consensys.github.io/smart-contract-best-practices/)** - _保護以太坊智慧型合約安全性之準則的完整清單。_ +- **[ConsenSys：以太坊智慧型合約安全性最佳案例](https://consensys.github.io/smart-contract-best-practices/)** - _保護以太坊智慧型合約安全性之準則的完整清單。_ - **[Nascent：簡單的安全性工具組](https://github.com/nascentxyz/simple-security-toolkit)** - _安全導向的實用智慧型合約開發指南與檢核清單。_ - **[Solidity 模式](https://fravoll.github.io/solidity-patterns/)** - _關於智慧型合約程式語言 Solidity 的安全性模型和最佳案例的實用彙總。_ -- **[Solidity 文件：安全性考量](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _使用 Solidity 編寫安全智慧型合約的指南。_ +- **[Solidity 文件：安全考量](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _使用 Solidity 撰寫安全智慧型合約的指南。_ - **[智慧型合約安全性驗證標準](https://github.com/securing/SCSVS)** - _適用於開發者、架構師、安全性審查者和廠商的標準化智慧型合約安全性 14 點檢查清單。_ -- **[學習智慧型合約安全與審核](https://updraft.cyfrin.io/courses/security) - _出色的智慧型合約安全與審核課程，為希望提升安全最佳做法並成為安全研究人員的智慧型合約開發人員而設。_ +- **[學習智慧型合約安全與審核](https://updraft.cyfrin.io/courses/security)** - _出色的智慧型合約安全與審核課程，為希望提升安全最佳做法並成為安全研究人員的智慧型合約開發人員而設。_ -### 關於智慧型合約安全性的使用教學 {#tutorials-on-smart-contract-security} +### 智慧型合約安全性教學 {#tutorials-on-smart-contract-security} -- [如何編寫安全的智慧型合約](/developers/tutorials/secure-development-workflow/) +- [如何撰寫安全的智慧型合約](/developers/tutorials/secure-development-workflow/) -- [如何使用 Slither 來搜尋智慧型合約漏洞](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [如何使用 Slither 尋找智慧型合約錯誤](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) -- [如何使用 Manticore 搜索智慧型合約bug.](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [如何使用 Manticore 尋找智慧型合約錯誤](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) -- [智慧型合約安全指南](/developers/tutorials/smart-contract-security-guidelines/) +- [智慧型合約安全性指南](/developers/tutorials/smart-contract-security-guidelines/) -- [如何安全整合包含任意代幣的代幣合約](/developers/tutorials/token-integration-checklist/) +- [如何安全地將您的代幣合約與任意代幣整合](/developers/tutorials/token-integration-checklist/) - [Cyfrin Updraft - 智慧型合約安全與審核完整課程](https://updraft.cyfrin.io/courses/security) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md index 093615beabf..e140005feef 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md @@ -1,38 +1,38 @@ --- -title: 測試智慧型合約 -description: 測試以太坊智慧型合約之技術與考量概觀。 +title: "測試智慧型合約" +description: "測試以太坊智慧型合約之技術與考量概觀。" lang: zh-tw --- -公共區塊鏈如以太坊具不可篡改性，讓已經部署的智慧型合約程式碼難以更改。 確實存在一些可以進行「虛擬升級」的[合約升級模式](/developers/docs/smart-contracts/upgrading/)，但這些模式的實作難度較高，並會涉及社交共識。 而且，升級只能在一個錯誤被發現_後_進行修正。如果攻擊者先發現了該漏洞，智慧型合約就有遭到利用的可能。 +公共區塊鏈如以太坊具不可篡改性，讓已經部署的智慧型合約程式碼難以更改。 用於執行「虛擬升級」的[合約升級模式](/developers/docs/smart-contracts/upgrading/)確實存在，但這些模式難以實作且需要社會共識。 此外，升級只能在錯誤被發現_之後_才能修復——如果攻擊者先發現漏洞，你的智能合約就有被利用的風險。 -基於這些原因，在智慧型合約被[部署](/developers/docs/smart-contracts/deploying/)到主網前進行測試，是保障[安全性](/developers/docs/smart-contracts/security/)的最基本要求。 有許多不同的測試合約和評估程式碼正確性的技術，你的選擇決於你的需求。 不過，一個由不同工具和方法組成的測試套件，會是找出合約程式碼中從輕微到重大安全性漏洞的理想選擇。 +因此，在將智能合約[部署](/developers/docs/smart-contracts/deploying/)到主網之前進行測試，是確保[安全](/developers/docs/smart-contracts/security/)的最低要求。 有許多不同的測試合約和評估程式碼正確性的技術，你的選擇決於你的需求。 不過，一個由不同工具和方法組成的測試套件，會是找出合約程式碼中從輕微到重大安全性漏洞的理想選擇。 ## 先決條件 {#prerequisites} -本頁會解釋如何在部署到以太坊網路前進行智慧型合約的測試， 前提是你已經熟悉[智慧型合約](/developers/docs/smart-contracts/)。 +本頁會解釋如何在部署到以太坊網路前進行智慧型合約的測試， 本文假設你已熟悉[智能合約](/developers/docs/smart-contracts/)。 -## 何謂智慧型合約測試？ {#what-is-smart-contract-testing} +## 何謂智慧型合約測試？ 何謂智能合約測試？ {#what-is-smart-contract-testing} 智慧型合約測試測試是指確認智慧型合約的程式碼會如預期般執行的測試過程。 測試有助於檢查特定的智慧型合約是否滿足可靠性、可用性及安全性要求。 -雖然測試方法各異，但大多數都是使用智慧型合約預計處理的資料中的一小部分樣本，來執行該智慧型合約。 如果合約對採樣資料產出正確的結果，那我們就認定它運作正常。 多數的測試工具都會提供資源來幫助撰寫與執行[測試用例](https://en.m.wikipedia.org/wiki/Test_case)，以檢查合約的執行是否符合預期的結果。 +雖然測試方法各異，但大多數都是使用智慧型合約預計處理的資料中的一小部分樣本，來執行該智慧型合約。 如果合約對採樣資料產出正確的結果，那我們就認定它運作正常。 大多數測試工具都提供資源，用於編寫和執行[測試案例](https://en.m.wikipedia.org/wiki/Test_case)，以檢查合約的執行是否符合預期結果。 -### 測試智慧型合約的重要性 {#importance-of-testing-smart-contracts} +### 測試智慧型合約的重要性 測試智能合約的重要性 {#importance-of-testing-smart-contracts} -由於智慧型合約通常掌控高財物價值的金融資產，即使是微小的程式設計錯誤往往也可以造成[使用者的巨大損失](https://rekt.news/leaderboard/)。 嚴密的測試則可以幫助你及早發現智慧型合約程式碼裡的缺陷與問題，並在它們發佈到主網前進行修復。 +由於智能合約通常管理高價值的金融資產，微小的程式設計錯誤可能會，且經常會導致[使用者蒙受巨大損失](https://rekt.news/leaderboard/)。 嚴密的測試則可以幫助你及早發現智慧型合約程式碼裡的缺陷與問題，並在它們發佈到主網前進行修復。 -雖然在發現漏洞後進行合約升級是可行的，但合約升級相當複雜，如果處理不當，還會[產生錯誤](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)。 不僅如此，合約升級打破了區塊鏈的不可篡改性原則，也讓使用者需要接受額外的信任假設。 相反地，我們應制定完整的合約測試計畫，來降低智慧型合約的安全性風險，避免在合約部署後需要進行複雜的邏輯升級。 +雖然在發現漏洞時可以升級合約，但升級過程很複雜，如果處理不當，可能會[導致錯誤](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)。 不僅如此，合約升級打破了區塊鏈的不可篡改性原則，也讓使用者需要接受額外的信任假設。 相反地，我們應制定完整的合約測試計畫，來降低智慧型合約的安全性風險，避免在合約部署後需要進行複雜的邏輯升級。 -## 智慧型合約的測試方法 {#methods-for-testing-smart-contracts} +## 測試智能合約的方法 {#methods-for-testing-smart-contracts} -測試以太坊智慧型合約的方法分為兩大類：**自動化測試**及**手動測試**。 自動化測試與手動測試各有優缺，兩者可以併用以建立穩健的合約分析計畫。 +測試以太坊智能合約的方法分為兩大類：**自動化測試**和**手動測試**。 自動化測試與手動測試各有優缺，兩者可以併用以建立穩健的合約分析計畫。 ### 自動化測試 {#automated-testing} -自動化測試使用工具來自動偵測智慧型合約程式碼在執行時的錯誤， 其好處在於使用[指令碼](https://www.techtarget.com/whatis/definition/script?amp=1)來指導合約功能的評估。 寫成指令碼的測試可以被安排重複執行來減少人力介入，這讓自動化測試比手動測試方式更有效率。 +自動化測試使用工具來自動偵測智慧型合約程式碼在執行時的錯誤， 自動化測試的好處在於使用[腳本](https://www.techtarget.com/whatis/definition/script?amp=1)來引導對合約功能的評估。 寫成指令碼的測試可以被安排重複執行來減少人力介入，這讓自動化測試比手動測試方式更有效率。 -自動化測試在以下情境特別有用：測試的重複性高且費時、難以採用手動方式進行、容易出現人為錯誤，或牽涉到評估關鍵的合約函式。 但自動化測試工具的缺點是，可能會遺漏一些漏洞，並可能產生許多[誤報結果](https://www.contrastsecurity.com/glossary/false-positive)。 因此，將自動化測試與手動測試並用於智慧型合約較為理想。 +自動化測試在以下情境特別有用：測試的重複性高且費時、難以採用手動方式進行、容易出現人為錯誤，或牽涉到評估關鍵的合約函式。 但自動化測試工具有其缺點——它們可能會遺漏某些錯誤，並產生許多[誤報](https://www.contrastsecurity.com/glossary/false-positive)。 因此，將自動化測試與手動測試並用於智慧型合約較為理想。 ### 手動測試 {#manual-testing} @@ -42,7 +42,7 @@ lang: zh-tw 有效的手動測試需要大量的資源（技術、時間、金錢與人力），而且有可能在執行測試時因為人為錯誤而遺漏一些錯誤。 但手動測試仍然是有益的，舉例來說，一個真人測試者（如審計員）或許可以用直覺來找出一些可能被自動化測試工具遺漏的邊緣案例。 -## 智慧型合約的自動化測試 {#automated-testing-for-smart-contracts} +## 智能合約的自動化測試 {#automated-testing-for-smart-contracts} ### 單元測試 {#unit-testing-for-smart-contracts} @@ -50,13 +50,13 @@ lang: zh-tw 單元測試在確認函式回傳預計的值以及函式執行後正確更新合約存儲方面很有用。 此外，在更改合約的程式碼庫之後運行單元測試，可以確保新增的新邏輯並沒有造成新錯誤。 以下是一些如何運行有效單元測試的指南： -#### 智慧型合約單元測試指南 {#unit-testing-guidelines} +#### 智能合約單元測試指南 {#unit-testing-guidelines} -##### 1. 了解你的合約的商務邏輯及工作流程 +##### 1. 了解你的合約的商務邏輯及工作流程 -在撰寫單元測試之前，知道智慧型合約提供哪些函式以及使用者要如何存取並使用這些函式很有幫助。 這在進行[快樂路徑 (happy path) 測試](https://en.m.wikipedia.org/wiki/Happy_path)時特別有用，這個測試是為了確定合約中的函式是否對有效的使用者輸入回傳正確的輸出。 我們會用這個（簡略的）[拍賣合約](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)作為例子來解釋這個概念。 +在撰寫單元測試之前，知道智慧型合約提供哪些函式以及使用者要如何存取並使用這些函式很有幫助。 這對於執行[快樂路徑測試](https://en.m.wikipedia.org/wiki/Happy_path)特別有用，這種測試會確定合約中的函式是否為有效的使用者輸入回傳正確的輸出。 我們將用這個[拍賣合約](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)的（簡化）範例來解釋這個概念 -``` +```solidity constructor( uint biddingTime, address payable beneficiaryAddress @@ -108,11 +108,11 @@ function auctionEnd() external { } ``` -這是一個設計用於在可出價期間接收出價的簡單拍賣合約。 當 `highestBid` 增加時，上一個最高出價者收回他們的錢；一旦可出價期間結束，`beneficiary` 呼叫合約以取得他們的錢。 +這是一個設計用於在可出價期間接收出價的簡單拍賣合約。 如果 `highestBid` 增加，前一個最高出價者會收到他們的錢；一旦出價期結束，`beneficiary` 就會呼叫合約來取回他們的錢。 -對於這樣的合約，單元測試會覆蓋使用者在與合約互動時會呼叫的各種函式。 舉個例子，單元測試可能測試使用者是否能在出價期間進行出價（也就是成功呼叫 `bid()`），或者是測試使用者是否可以出一個比現在的 `highestBid` 更高的價格。 +對於這樣的合約，單元測試會覆蓋使用者在與合約互動時會呼叫的各種函式。 例如，一個單元測試會檢查使用者是否能在拍賣進行時出價（即對 `bid()` 的呼叫成功），或檢查使用者是否能出比當前 `highestBid` 更高的價格。 -了解合約的工作流程也能幫助撰寫單元測試，確認執行結果是否符合要求。 舉例來說，這個拍賣合約指明使用者不能在拍賣結束後（也就是當 `auctionEndTime` 小於 `block.timestamp` 的時候）出價。 因此，開發者可能會執行一個單元測試，確認在拍賣結束後（`auctionEndTime` > `block.timestamp` 時）呼叫 `bid()` 函式是否能成功。 +了解合約的工作流程也能幫助撰寫單元測試，確認執行結果是否符合要求。 例如，拍賣合約規定，拍賣結束後使用者不能出價（即當 `auctionEndTime` 小於 `block.timestamp` 時）。 因此，開發者可能會執行一個單元測試，檢查當拍賣結束時（即 `auctionEndTime` > `block.timestamp`），對 `bid()` 函式的呼叫是成功還是失敗。 ##### 2. 評估所有關於合約執行的假設 @@ -126,11 +126,11 @@ function auctionEnd() external { - 未能贏得競標的使用者將獲得其資金的退款 -**注**：測試假設的另一種方式是編寫測試以觸發合約中的[修飾函式](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers)，特別是 `require`、`assert` 和 `if…else` 陳述式。 +**注意**：測試假設的另一種方法是編寫測試來觸發合約中的[函式修飾詞](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers)，特別是 `require`、`assert` 和 `if…else` 陳述式。 ##### 3 計算程式碼覆蓋率 -[程式碼覆蓋率](https://en.m.wikipedia.org/wiki/Code_coverage)是一種測試指標，用於追蹤在測試過程中執行的程式碼分支、行和陳述式的數量。 測試應該具有良好的程式碼覆蓋率，以最大程度地減少未經測試漏洞的風險。 如果沒有充足的程式碼覆蓋率，你可能會因爲所有測試都通過了而誤認爲你的合約是安全的，而未經測試的程式碼路徑中仍存在漏洞。 但是，透過覆蓋足夠多的程式碼，就可以確保智慧型合約中的所有陳述式/函式都經過充分的正確性測試。 +[程式碼覆蓋率](https://en.m.wikipedia.org/wiki/Code_coverage)是一種測試指標，用於追蹤測試期間執行的程式碼中的分支、行和陳述式數量。 測試應該具有良好的程式碼覆蓋率，以最大程度地減少未經測試漏洞的風險。 如果沒有充足的程式碼覆蓋率，你可能會因爲所有測試都通過了而誤認爲你的合約是安全的，而未經測試的程式碼路徑中仍存在漏洞。 但是，透過覆蓋足夠多的程式碼，就可以確保智慧型合約中的所有陳述式/函式都經過充分的正確性測試。 ##### 4 使用精心開發的測試框架 @@ -138,171 +138,173 @@ function auctionEnd() external { Solidity 智慧型合約的單元測試框架有不同的語言（大多數為 JavaScript、Python 和 Rust）。 請參閱下方指南，了解如何使用不同的測試框架開始運行單元測試： -- **[使用 Brownie 運行單元測試](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** -- **[使用 Foundry 運行單元測試](https://book.getfoundry.sh/forge/writing-tests)** -- **[使用 Waffle 運行單元測試](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** -- **[使用 Remix 運行單元測試](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** -- **[使用 Ape 運行單元測試](https://docs.apeworx.io/ape/stable/userguides/testing.html)** -- **[使用 Hardhat 運行單元測試](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** -- **[使用 Wake 運行單元測試](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** +- **[使用 Brownie 執行單元測試](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** +- **[使用 Foundry 執行單元測試](https://book.getfoundry.sh/forge/writing-tests)** +- **[使用 Waffle 執行單元測試](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** +- **[使用 Remix 執行單元測試](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** +- **[使用 Ape 執行單元測試](https://docs.apeworx.io/ape/stable/userguides/testing.html)** +- **[使用 Hardhat 執行單元測試](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** +- **[使用 Wake 執行單元測試](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** ### 整合測試 {#integration-testing-for-smart-contracts} -單元測試對合約函式進行單獨除錯，而整合測試將智慧型合約的組件作爲一個整體進行評估。 整合測試可以偵測源自跨合約呼叫或同一個智慧型合約中不同函式閒互動的問題。 例如，整合測試能夠幫助檢查諸如[繼承](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance)和相依性注入之類的功能是否正常運作。 +單元測試對合約函式進行單獨除錯，而整合測試將智慧型合約的組件作爲一個整體進行評估。 整合測試可以偵測源自跨合約呼叫或同一個智慧型合約中不同函式閒互動的問題。 例如，整合測試可以幫助檢查[繼承](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance)和依賴注入等是否正常運作。 -如果你的合約採用模組化架構或在執行期間與其他鏈上合約互動，整合測試就很實用。 運行整合測試的一個方法是在一個特定高度[分叉區塊鏈](/glossary/#fork)（使用類似 [Forge](https://book.getfoundry.sh/forge/fork-testing) 或 [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) 的工具），並模擬在你的合約與已部署合約之間的互動。 +如果你的合約採用模組化架構或在執行期間與其他鏈上合約互動，整合測試就很實用。 執行整合測試的一種方法是在特定高度[分叉區塊鏈](/glossary/#fork)（使用 [Forge](https://book.getfoundry.sh/forge/fork-testing) 或 [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) 等工具），並模擬你的合約與已部署合約之間的互動。 分叉的區塊鏈將與主網的行為類似，其帳戶具有關聯的狀態和餘額。 但它只作爲一個沙盒在本機開發環境運行，例如，這意味著你不需要用真實的以太幣來交易，你的更改也不會影響真實的以太坊協議。 -### 基於屬性的測試 {#property-based-testing-for-smart-contracts} +### 屬性測試 {#property-based-testing-for-smart-contracts} 基於屬性的測試是一種檢查智慧型合約是否滿足一些已定義屬性的過程。 屬性是關於合約行為的事實斷言，預期其行為在不同的場景中始終保持為真。智慧型合約屬性的一個例子可以是「合約中的算術運算永不溢出或下溢」。 -**靜態分析**和**動態分析**是執行基於屬性的測試的兩種常見技術，並且兩者都可以驗證程式（在這裏為智慧型合約）的程式碼是否滿足某些預定義屬性。 一些基於屬性的測試工具自帶一些關於預期合約屬性的預定義規則，並根據這些規則檢查程式碼，而其他工具則允許你為智慧型合約建立自訂屬性。 +**靜態分析**和**動態分析**是執行屬性測試的兩種常用技術，兩者都可以驗證程式（此處指智能合約）的程式碼是否滿足某些預定義的屬性。 一些基於屬性的測試工具自帶一些關於預期合約屬性的預定義規則，並根據這些規則檢查程式碼，而其他工具則允許你為智慧型合約建立自訂屬性。 #### 靜態分析 {#static-analysis} 靜態分析器將智慧型合約的原始程式碼作爲輸入，並輸出聲明合約是否滿足屬性的結果。 與動態分析不同，靜態分析不涉及執行合約來分析其正確性。 相反，靜態分析會推理智慧型合約在執行期間可能選擇的所有路徑（例如，透過檢視原始程式碼的結構來確定合約運作在運行時間的意義）。 -[Linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) 和[靜態測試](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis)是對合約執行靜態分析的常見方法。 兩者都需要對合約執行的低階表示進行分析，例如由編譯器輸出的[抽象語法樹](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree)和[控制流程圖](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/)。 +[Linting](https://www.perforce.com/blog/qac/what-is-linting) 和[靜態測試](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis)是在合約上執行靜態分析的常用方法。 兩者都需要分析由編譯器輸出的合約執行的低階表示，例如[抽象語法樹](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree)和[控制流程圖](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/)。 在多數情況下，靜態分析對偵測安全問題很有用，例如使用不安全構造、語法錯誤或違反合約程式碼中的編碼標準。 然而，靜態分析器通常被認爲在偵測更深層漏洞方面不太健全，並可能會產生過多的誤報。 #### 動態分析 {#dynamic-analysis} -動態分析為智慧型合約函式產生符號輸入（例如，在[符號執行](https://en.m.wikipedia.org/wiki/Symbolic_execution)中）或具體輸入（例如，在[模糊測試](https://owasp.org/www-community/Fuzzing)中），來查看是否有任何執行軌跡違反特定屬性。 此類基於屬性的測試與單元測試不同，其測試用例覆蓋了多種場景，並且有一個程式處理測試用例的生成。 +動態分析會對智能合約的函式產生符號輸入（例如，在[符號執行](https://en.m.wikipedia.org/wiki/Symbolic_execution)中）或具體輸入（例如，在[模糊測試](https://owasp.org/www-community/Fuzzing)中），以查看是否有任何執行追蹤違反了特定屬性。 此類基於屬性的測試與單元測試不同，其測試用例覆蓋了多種場景，並且有一個程式處理測試用例的生成。 -[模糊測試](https://halborn.com/what-is-fuzz-testing-fuzzing/)是一種用於驗證智慧型合約中任意屬性的動態分析技術範例。 模糊測試工具使用定義的輸入值的隨機或畸形變化來叫用目標合約中的函式。 如果智慧型合約進入錯誤狀態（例如，當斷言失敗時），該問題就會被標記，並在報告中產生將執行推向脆弱路徑的輸入。 +[模糊測試](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing)是用於驗證智能合約中任意屬性的動態分析技術範例。 模糊測試工具使用定義的輸入值的隨機或畸形變化來叫用目標合約中的函式。 如果智慧型合約進入錯誤狀態（例如，當斷言失敗時），該問題就會被標記，並在報告中產生將執行推向脆弱路徑的輸入。 模糊測試對於評估智慧型合約輸入驗證機制很有用，因爲對意外輸入的不正確處理可能會導致意外執行並產生危險的影響。 這種基於屬性的測試形式可能非常理想，原因有多種： -1. **編寫覆蓋許多場景的測試用例非常困難。**屬性測試只需要定義一個行爲以及用於測試該行爲的一系列資料 - 程式會根據定義的屬性自動生成測試用例。 +1. \*\*編寫涵蓋多種情境的測試案例很困難。\*\*屬性測試只需要你定義一個行為和一個用於測試該行為的資料範圍——程式會根據定義的屬性自動產生測試案例。 -2. **你的測試套件或許無法充分覆蓋程式中所有可能的路徑。**即便有 100% 的覆蓋率，也可能會錯過邊緣案例。 +2. \*\*你的測試套件可能無法充分涵蓋程式中的所有可能路徑。\*\*即使有 100% 的覆蓋率，也可能錯過邊緣案例。 -3. **單元測試證明合約正確執行採樣資料，但採樣以外的輸入是否正確執行仍然未知。**屬性測試使用給定輸入值的多個變體來執行目標合約，以此找出導致斷言失敗的執行軌跡。 因此，屬性測試為合約在廣泛的輸入資料類別下正確執行提供了更多的保證。 +3. \*\*單元測試證明合約對樣本資料能正確執行，但合約對樣本外的輸入是否能正確執行仍是未知數。\*\*屬性測試會使用給定輸入值的多種變體來執行目標合約，以找出導致斷言失敗的執行追蹤。 因此，屬性測試為合約在廣泛的輸入資料類別下正確執行提供了更多的保證。 -### 對智慧型合約運行基於屬性的測試的準則 {#running-property-based-tests} +### 執行智能合約屬性測試的指南 {#running-property-based-tests} -運行基於屬性的測試通常從定義一個屬性（例如，[整數溢位](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)的缺乏）或者你希望在智慧型合約中驗證的屬性集合開始。 在編寫屬性測試時，你可能還需要定義一個數值範圍，使程式能夠在該範圍内為交易輸入生成資料。 +執行屬性測試通常從定義一個你想要在智能合約中驗證的屬性（例如，沒有[整數溢位](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)）或屬性集合開始。 在編寫屬性測試時，你可能還需要定義一個數值範圍，使程式能夠在該範圍内為交易輸入生成資料。 設定正確後，屬性測試工具會使用隨機產生的輸入來執行你的智慧型合約函式。 如果有任何斷言違規情況，你應該會獲得一份報告，其中包含違反正在評估的屬性的具體輸入資料。 請參閱下面的指南，了解如何使用不同的工具開始執行基於屬性的測試： -- **[使用 Slither 的智慧型合約靜態分析](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)** -- **[使用 Wake 的智慧型合約靜態分析](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** -- **[使用 Brownie 進行基於屬性的測試](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** -- **[使用 Foundry 進行合約模糊測試](https://book.getfoundry.sh/forge/fuzz-testing)** -- **[使用 Echidna 進行合約模糊測試](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** -- **[使用 Wake 進行合約模糊測試](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** -- **[使用 Manticore 的智能合約符號執行](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** -- **[使用 Mythril 的智能合約符號執行](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** +- **[使用 Slither 進行智能合約的靜態分析](https://github.com/crytic/slither)** +- **[使用 Wake 進行智能合約的靜態分析](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** +- **[使用 Brownie 進行屬性測試](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** +- **[使用 Foundry 對合約進行模糊測試](https://book.getfoundry.sh/forge/fuzz-testing)** +- **[使用 Echidna 對合約進行模糊測試](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** +- **[使用 Wake 對合約進行模糊測試](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** +- **[使用 Manticore 進行智能合約的符號執行](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** +- **[使用 Mythril 進行智能合約的符號執行](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** -## 手動測試智慧型合約 {#manual-testing-for-smart-contracts} +## 智能合約的手動測試 {#manual-testing-for-smart-contracts} 手動測試通常是在智慧型合約開發後期運行自動化測試之後進行的。 這種測試形式將智慧型合約作爲完全整合的產品進行評估，以此檢查其是否符合技術要求中的規範。 -### 在本機區塊鏈測試合約 {#testing-on-local-blockchain} +### 在本機區塊鏈上測試合約 {#testing-on-local-blockchain} 儘管在本機開發環境中執行的自動化測試能夠提供有用的偵錯資訊，你仍然會想知道你的合約在生产環境中的執行情況。 然而，部署到以太坊主鏈需要燃料費 - 更不用説如果你的智慧型合約仍有漏洞，你或你的使用者可能會損失真金白銀。 -在本機區塊鏈（也被稱爲[開發者網路](/developers/docs/development-networks/)）上測試你的合約，是在主網上進行測試的建議替代方案。 本機區塊鏈是在你的電腦上本機運行的以太坊區塊鏈的副本，它能模擬以太坊執行層的行爲。 這樣，你就可以設定交易與合約進行交互，而不會產生大量開銷。 +在本機區塊鏈（也稱為[開發網路](/developers/docs/development-networks/)）上測試你的合約，是在主網上測試的建議替代方案。 本機區塊鏈是在你的電腦上本機運行的以太坊區塊鏈的副本，它能模擬以太坊執行層的行爲。 這樣，你就可以設定交易與合約進行交互，而不會產生大量開銷。 -在本機區塊鏈上運行合約可以有助於完成手動整合測試。 [智慧型合約具有高度可組合性](/developers/docs/smart-contracts/composability/)，允許你整合現有的協定 - 但你仍然需要確保這種複雜的鏈上整合會產生正確的結果。 +在本機區塊鏈上運行合約可以有助於完成手動整合測試。 [智能合約具有高度可組合性](/developers/docs/smart-contracts/composability/)，可讓你與現有協定整合——但你仍需確保這種複雜的鏈上互動能產生正確的結果。 -[有關開發網路的更多資訊。](/developers/docs/development-networks/) +[關於開發網路的更多資訊。](/developers/docs/development-networks/) ### 在測試網上測試合約 {#testing-contracts-on-testnets} -測試網路或測試網的運作方式與以太坊主網完全相同，唯一的區別在於它使用沒有現實價值的以太幣 (ETH)。 在[測試網](/developers/docs/networks/#ethereum-testnets)上部署你的合約意味著任何人都可以與之互動（例如，透過去中心化應用程式 (dapp) 的前端），而無需承擔資金風險。 +測試網路或測試網的運作方式與以太坊主網完全相同，唯一的區別在於它使用沒有現實價值的以太幣 (ETH)。 在[測試網](/developers/docs/networks/#ethereum-testnets)上部署你的合約，意味著任何人都可以與它互動（例如，透過去中心化應用程式的前端），而無需承擔資金風險。 這種手動測試形式對於從使用者角度評估應用程式的端到端流程非常有用。 在這裡，測試人員還可以進行試運行，並報告與合約的業務邏輯和整體功能有關的任何問題。 在本機區塊鏈上進行測試後，部署到測試網是理想的選擇，因為測試網更接近以太坊虛擬機的行為。 因此，許多以太坊原生專案通常會將去中心化應用程式 (dapp) 部署到測試網上，以在現實條件下評估智慧型合約的運作。 -[更多以太坊測試網相關資訊。](/developers/docs/development-networks/#public-beacon-testchains) +[關於以太坊測試網的更多資訊。](/developers/docs/development-networks/#public-beacon-testchains) ## 測試與形式化驗證 {#testing-vs-formal-verification} -儘管測試有助確認合約對特定資料輸入回傳預期結果，但對於測試期間未使用的輸入，它無法完全證明相同的結果。 因此，測試智慧型合約無法保證「函式正確性」（即無法確保程式對於_所有_輸入值集都按照要求運作）。 +儘管測試有助確認合約對特定資料輸入回傳預期結果，但對於測試期間未使用的輸入，它無法完全證明相同的結果。 因此，測試智能合約不能保證「功能正確性」（即它無法證明程式對_所有_輸入值組合都按要求執行）。 形式化驗證是一種透過檢查程式的形式化模型是否符合形式化規範來評估軟體正確性的方法。 形式化模型是程式的抽象數學表示，而形式化規範定義程式的屬性（即關於程式執行的邏輯斷言）。 因爲屬性由數學術語編寫，它能夠使用邏輯推理規則來驗證系統的形式化（數學）模型是否滿足規範。 所以形式化驗證工具被認為能夠提供系統正確性的「數學證明」。 -與測試不同，形式化驗證可用於驗證智慧型合約執行是否滿足_所有_執行的形式化規範（即沒有漏洞），而無需使用採樣資料執行它。 這不僅減少了運行數十個單元測試所花費的時間，而且在發現隱藏漏洞方面也更有效。 話雖如此，形式化驗證技術在實作難度和實用性上存在一定的變化程度。 +與測試不同，形式化驗證可用於驗證智能合約的執行滿足_所有_執行的形式化規範（即沒有錯誤），而無需使用樣本資料來執行它。 這不僅減少了運行數十個單元測試所花費的時間，而且在發現隱藏漏洞方面也更有效。 話雖如此，形式化驗證技術在實作難度和實用性上存在一定的變化程度。 -[更多關於智慧型合約形式化驗證的資訊。](/developers/docs/smart-contracts/formal-verification) +[關於智能合約形式化驗證的更多資訊。](/developers/docs/smart-contracts/formal-verification) -## 測試與審核以及漏洞懸賞 {#testing-vs-audits-bug-bounties} +## 測試、稽核與漏洞賞金 {#testing-vs-audits-bug-bounties} 如上所述，嚴格的測試很難保證合約中沒有錯誤；形式化驗證方法可以提供更有力的正確性保證，但目前仍難以使用並且需要大量成本。 -儘管如此，你仍可透過獨立的程式碼檢閱來進一步增加捕捉合約漏洞的可能性。 [智慧型合約審核](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/)和[漏洞懸賞](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)是讓他人分析你的合約的兩種方式。 +儘管如此，你仍可透過獨立的程式碼檢閱來進一步增加捕捉合約漏洞的可能性。 [智能合約稽核](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/)和[漏洞賞金](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)是讓他人分析你合約的兩種方式。 審查由具有在智慧型合約中發現安全缺陷和不良開發實踐案例經驗的審查人員進行。 審核通常包括對整個程式碼基底進行測試（可能包括形式化驗證）以及手動檢閱。 -相反，漏洞懸賞計劃通常包括向在智慧型合約中發現漏洞並向開發者報告的個人（通常被描述爲[白帽駭客](https://en.wikipedia.org/wiki/White_hat_(computer_security))）提供經濟獎勵。 漏洞懸賞類似於審查，因為它涉及要求其他人幫助發現智慧型合約中的缺陷。 +相反，漏洞賞金計畫通常會向發現智能合約漏洞並向開發者揭露的個人（通常稱為[白帽駭客](https://en.wikipedia.org/wiki/White_hat_\(computer_security\))）提供金錢獎勵。 漏洞懸賞類似於審查，因為它涉及要求其他人幫助發現智慧型合約中的缺陷。 主要的區別是漏洞懸賞計劃對更廣泛的開發者/駭客開放，並吸引了廣泛的擁有獨特技能與經驗的道德駭客和獨立安全專家。 與智慧型合約審查主要依賴可能擁有有限或狹窄專業知識的團隊相比，這可能是一個優勢。 -## 測試工具與程式庫 {#testing-tools-and-libraries} +## 測試工具和程式庫 {#testing-tools-and-libraries} ### 單元測試工具 {#unit-testing-tools} -- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _以 Solidity 編寫的智慧型合約程式碼覆蓋率工具_ +- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _用 Solidity 編寫的智能合約的程式碼覆蓋率工具。_ -- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _用於進階智慧型合約開發和測試的框架（以 ethers.js 為基礎）_。 +- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _用於進階智能合約開發和測試的框架（基於 ethers.js）。_ -- **[Remix 測試](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _用來測試 Solidity 智慧型合約的工具。 在 Remix IDE 的「Solidity 單元測試」外掛程式下工作，該外掛程式用於編寫和運行合約的測試用例。 _ +- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _用於測試 Solidity 智能合約的工具。 在 Remix IDE「Solidity 單元測試」外掛程式下運作，用於編寫和執行合約的測試案例。_ -- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _用於以太坊智慧型合約測試的斷言程式庫。 確保你的合約運作自如！_ +- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _用於以太坊智能合約測試的斷言程式庫。 讓您的合約運作自如正常!_ -- **[Brownie 單元測試框架](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie 利用 Pytest，一個功能豐富的測試框架，使你能夠用最少的程式碼編寫小型測試，並且對於大型項目擴展良好，具有高度可延伸性。_ +- **[Brownie 單元測試框架](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie 使用 Pytest，這是一個功能豐富的測試框架，可讓你用最少的程式碼編寫小型測試，能很好地擴展到大型專案，且高度可擴充。_ -- **[Foundry 測試](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry 提供了 Forge，一個快速且靈活的以太坊測試框架，能夠執行簡單的單元測試、燃料優化檢查，以及合約模糊測試。_ +- **[Foundry 測試](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry 提供 Forge，這是一個快速而靈活的以太坊測試框架，能夠執行簡單的單元測試、gas 優化檢查和合約模糊測試。_ -- **[Hardhat 測試](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _基於 ethers.js、Mocha 和Chai 的智慧型合約測試框架。_ +- **[Hardhat 測試](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _基於 ethers.js、Mocha 和 Chai 的智能合約測試框架。_ -- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _基於 Python 的開發與測試框架，適用於針對以太坊虛擬機的智慧型合約。_ +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _基於 Python 的開發和測試框架，適用於以太坊虛擬機的智能合約。_ -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _基於 Python 的框架，為單元測試和模糊測試提供了强大的偵錯功能和跨鏈測試支援，並利用 pytest 和 Anvil 實現最佳的使用者體驗和效能。_ +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _基於 Python 的單元測試和模糊測試框架，具有強大的偵錯功能和跨鏈測試支援，利用 pytest 和 Anvil 以獲得最佳的使用者體驗和效能。_ -### 基於屬性的測試工具 {#property-based-testing-tools} +### 屬性測試工具 {#property-based-testing-tools} #### 靜態分析工具 {#static-analysis-tools} -- **[Slither](https://github.com/crytic/slither)** - _基於 Python 的 Solidity 靜態分析框架，能夠為智慧型合約尋找漏洞、增强程式碼理解，以及編寫自訂分析。_ +- **[Slither](https://github.com/crytic/slither)** - _基於 Python 的 Solidity 靜態分析框架，用於尋找漏洞、增強程式碼理解以及為智能合約編寫自訂分析。_ + +- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _用於為 Solidity 智能合約程式語言強制執行風格和安全最佳實踐的 Linter。_ -- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _用於執行 Solidity 智慧型合約程式設計語言風格和安全最佳實踐的 Linter。_ +- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _基於 Rust 的靜態分析器，專為 Web3 智能合約安全和開發而設計。_ -- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _基於 Rust 的靜態分析器，專為 Web3 智慧型合約安全和開發而設計。_ +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _基於 Python 的靜態分析框架，具有漏洞和程式碼品質偵測器、用於從程式碼中提取有用資訊的印表機，並支援編寫自訂子模組。_ -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _基於 Python 的靜態分析框架，具有漏洞和程式碼品質偵測器、從程式碼擷取有用資訊的印表機，並且支援編寫自訂子模組。_ +- **[Slippy](https://github.com/fvictorio/slippy)** - _一個簡單而強大的 Solidity linter。_ #### 動態分析工具 {#dynamic-analysis-tools} -- **[Echidna](https://github.com/crytic/echidna/)** - _快速合約模糊測試工具，用於透過基於屬性的測試來偵測智慧型合約漏洞。_ +- **[Echidna](https://github.com/crytic/echidna/)** - _透過屬性測試偵測智能合約漏洞的快速合約模糊測試器。_ -- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _自動化模糊測試工具，適用於偵測智慧型合約程式碼中的屬性違規行為。 _ +- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _自動化模糊測試工具，可用於偵測智能合約程式碼中的屬性違規。_ -- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _用於分析以太坊虛擬機位元組碼的動態符號執行框架。 _ +- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _用於分析 EVM 位元組碼的動態符號執行框架。_ -- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _以太坊虛擬機位元組碼評定工具，能夠使用污染源分析、一致性分析和控制流檢查來偵測合約漏洞。_ +- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _EVM 位元組碼評估工具，使用污點分析、混合執行分析和控制流程檢查來偵測合約漏洞。_ -- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble 是一種規範語言和運行時檢查工具，允許你為智慧型合約註解屬性，從而使你能夠使用 Diligence Fuzzing 或 MythX 這類工具來自動測試合約。_ +- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble 是一種規範語言和執行期驗證工具，可讓你用屬性來註解智能合約，以便使用 Diligence Fuzzing 或 MythX 等工具自動測試合約。_ ## 相關教學 {#related-tutorials} -- [不同測試產品的概覽和比較](/developers/tutorials/guide-to-smart-contract-security-tools/) -- [如何使用 Echidna 測試智慧型合約](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) +- [不同測試產品的總覽與比較](/developers/tutorials/guide-to-smart-contract-security-tools/) \_ +- [如何使用 Echidna 測試智能合約](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) - [如何使用 Manticore 尋找智慧型合約錯誤](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) -- [如何使用 Slither 來搜尋智慧型合約漏洞](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [如何使用 Slither 尋找智慧型合約錯誤](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) - [如何模擬 Solidity 合約進行測試](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) - [如何使用 Foundry 在 Solidity 中執行單元測試](https://www.rareskills.io/post/foundry-testing-solidity) -## 了解更多 {#further-reading} +## 延伸閱讀 {#further-reading} -- [測試以太坊智慧型合約的深入指南](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) -- [如何測試以太坊智慧型合約](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) -- [MolochDAO 的開發者單元測試指南](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) -- [如何像明星專家一樣測試智慧型合約](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) +- [以太坊智能合約深度測試指南](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) +- [如何測試以太坊智能合約](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) +- [MolochDAO 為開發者提供的單元測試指南](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) +- [如何像搖滾巨星一樣測試智能合約](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/upgrading/index.md index f34d8cf2c1d..b00f1cbaf4a 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/upgrading/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/upgrading/index.md @@ -1,6 +1,6 @@ --- -title: 升級智慧型合約 -description: 以太坊智慧型合約升級模式概述 +title: "升級智慧型合約" +description: "以太坊智慧型合約升級模式概述" lang: zh-tw --- @@ -12,9 +12,9 @@ lang: zh-tw ## 先決條件 {#prerequisites} -你需要對[智慧型合約](/developers/docs/smart-contracts/)、[智慧型合約結構](/developers/docs/smart-contracts/anatomy/)和[以太坊虛擬機 (EVM)](/developers/docs/evm/) 有一定程度的了解。 本指南還假設讀者了解智慧型合約的程式設計。 +你應充分了解[智能合約](/developers/docs/smart-contracts/)、[智能合約剖析](/developers/docs/smart-contracts/anatomy/)以及[以太坊虛擬機 (EVM)](/developers/docs/evm/) 本指南還假設讀者了解智慧型合約的程式設計。 -## 什麼是智慧型合約升級？ {#what-is-a-smart-contract-upgrade} +## 什麼是智慧型合約升級？ 什麼是智能合約升級？ {#what-is-a-smart-contract-upgrade} 智慧型合約升級需要在變更智慧型合約商業邏輯的同時保留合約的狀態。 分清楚可升級性與可變性是兩回事，這點很重要，尤其在智慧型合約背景下。 @@ -42,7 +42,7 @@ lang: zh-tw 合約遷徙是一個相對簡單且安全的智慧型合約升級方式，不會影響到使用者的互動。 但是，手動遷徙使用者的存儲和餘額到新合約非常花時間而且需要高燃料費用。 -[關於合約遷徙的更多資訊。](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) +[更多關於合約遷移的資訊。](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) ### 升級機制 #2：資料分離 {#data-separation} @@ -66,17 +66,17 @@ lang: zh-tw 1. 使用者與儲存資料的代理合約互動，但這個合約上沒有保有商業邏輯。 -2. 代理合約儲存邏輯合約的地址，並使用 `delegatecall` 函式將所有函式呼叫委派到邏輯合約（該合約擁有商業邏輯）。 +2. 代理合約儲存邏輯合約的地址，並使用 `delegatecall` 函式將所有函式呼叫委派到邏輯合約（該合約擁有業務邏輯）。 3. 在呼叫轉送到邏輯合約後，從邏輯合約回傳的資料會被擷取並回傳給使用者。 -使用代理模式需要了解 **delegatecall** 函式。 簡單來講，`delegatecall` 是允許合約呼叫另一個合約的操作碼，而實際的程式碼執行發生在呼叫合約的背景下。 在代理模式中使用 `delegatecall` 的含義是，代理合約讀取儲存在邏輯合約中的邏輯，寫入其存儲並執行，就像呼叫一個内部函式一樣。 +使用代理模式需要了解 **delegatecall** 函式。 基本上，`delegatecall` 是一種操作碼，允許一個合約呼叫另一個合約，而實際的程式碼執行發生在呼叫合約的上下文中。 在代理模式中使用 `delegatecall` 的一個影響是，代理合約會讀寫其儲存空間，並執行儲存在邏輯合約的邏輯，如同呼叫內部函式一樣。 -根據 [Solidity 文件](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)： +出自 [Solidity 文件](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)： -> _存在一個訊息呼叫的特殊變體，稱爲 **delegatecall**，除了目標地址中的程式碼是在呼叫合約的背景下執行，並且 `msg.sende` 和 `msg.value` 不會改變它們的值之外，該變體與訊息呼叫相同。__這意味著合約可以在運行時從另一個地址動態載入程式碼。 存儲、目前的地址和餘額仍然是指呼叫合約，只有程式碼來自被呼叫的地址。_ +> _訊息呼叫有一個名為 **delegatecall** 的特殊變體，它與訊息呼叫完全相同，但有以下例外：目標位址的程式碼是在呼叫合約的上下文（即位址）中執行，且 `msg.sender` 和 `msg.value` 的值不會改變。_ _這表示合約可以在執行期間從不同位址動態載入程式碼。_ _儲存空間、目前地址和餘額仍引用呼叫合約，只有程式碼取自被呼叫的地址。_ -代理合約知道在使用者一呼叫函式時就叫用 `delegatecall`，因為它有一個內建的 `fallback` 函式。 在 Solidity 編程中，當函式呼叫與合約中指定的函式不相符時，便會執行[遞補函式](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function)。 +代理合約之所以知道在使用者呼叫函式時要叫用 `delegatecall`，是因為它內建了一個 `fallback` 函式。 在 Solidity 程式設計中，當函式呼叫與合約中指定的函式不相符時，就會執行[遞補函式](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function)。 要使代理模式正常運作，需要編寫一個自訂遞補函式，指定代理合約應該如何處理其不支援的函式呼叫。 在這種情況下，代理的遞補函式編寫為啟動 delegatecall 並將使用者的要求重新路由到目前的邏輯合約實作。 @@ -84,17 +84,17 @@ lang: zh-tw 透過將代理合約指向新的邏輯合約，使用者呼叫代理合約函式時執行的程式碼發生了改變。 這樣我們在升級合約邏輯時，就不用要求使用者與新的合約互動。 -代理模式是一種升級智慧型合約的熱門方法，因爲其消除了與合約遷移相關的難題。 然而，代理合約使用起來更加複雜，使用不當時可能帶來重大缺陷，如[函式選擇器崩潰](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)。 +代理模式是一種升級智慧型合約的熱門方法，因爲其消除了與合約遷移相關的難題。 然而，代理模式使用起來更為複雜，如果使用不當，可能會引入嚴重缺陷，例如[函數選擇器衝突](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)。 -[關於代理模式的更多資訊](https://blog.openzeppelin.com/proxy-patterns/) +[更多關於代理模式的資訊](https://blog.openzeppelin.com/proxy-patterns/)。 ### 升級機制 #4：策略模式 {#strategy-pattern} -該技術受到[策略模式](https://en.wikipedia.org/wiki/Strategy_pattern)的影響，這種模式鼓勵建立與其他程式介接的軟體程式以實作特定功能。 在以太坊開發中套用策略模式是指，建立一個智慧型合約來呼叫其他合約的函式。 +這項技術受到[策略模式](https://en.wikipedia.org/wiki/Strategy_pattern)的影響，該模式鼓勵建立與其他程式介接的軟體程式，以實作特定功能。 在以太坊開發中套用策略模式是指，建立一個智慧型合約來呼叫其他合約的函式。 在這種情況下，主要合約包含核心商業邏輯，但會與其他智慧型合約（「衛星合約」）介接以執行特定函式。 此主要合約也儲存了各衛星合約的地址，可以在不同的衛星合約實作之間切換。 -你可以建立一個新的衛星合約並在主要合約上設定新的地址， 讓你可以更換智慧型合約的_策略_（即，實作新的邏輯）。 +你可以建立一個新的衛星合約並在主要合約上設定新的地址， 這讓你可以更換智能合約的_策略_（即實作新邏輯）。 儘管與先前討論的代理模式類似，但策略模式有所不同，因為與使用者互動的主要合約保有商業邏輯。 使用這個模式可為你提供一個對智慧型合約引入有限變更而不影響核心基礎設施的機會。 @@ -104,9 +104,9 @@ lang: zh-tw 鑽石模式可視為改良版的代理模式。 鑽石模式與代理模式不同的是，鑽石代理合約可以委派函式呼叫到不只一個邏輯合約。 -在鑽石模式中，邏輯合約被稱為_切面_。 為了使鑽石模式發揮作用，需要在代理合約中建立對應，將[函式選擇器](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector)對應到不同切面的地址。 +在鑽石模式中，邏輯合約被稱為_切面_。 為了讓鑽石模式運作，你需要在代理合約中建立一個對應，將[函式選擇器](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector)對應到不同的切面地址。 -當使用者進行函式呼叫時，代理合約會檢查該對應，找到負責執行該函式的切面。 之後，它會叫用 `delegatecall`（使用遞補函式），並將呼叫重新導向至適合的邏輯合約。 +當使用者進行函式呼叫時，代理合約會檢查該對應，找到負責執行該函式的切面。 之後，它會叫用 `delegatecall`（使用遞補函式），並將呼叫重新導向至適當的邏輯合約。 鑽石升級模式有幾個優於傳統代理升級模式的好處： @@ -114,11 +114,11 @@ lang: zh-tw 2. 所有智慧型合約（包括代理模式中使用的邏輯合約）都有 24KB 的大小限制，尤其對於需要更多函式的複雜合約而言，可能成為一個限制。 鑽石模式藉由拆分函式到多個邏輯合約，輕易解決了這個問題。 -3. 代理模式採用了包羅萬象的存取控制方法。 有升級函式存取權限的實體可以更改_整個_合約。 但鑽石模式啟用了模組化權限方法，可以限制實體僅升級智慧型合約中的特定函式。 +3. 代理模式採用了包羅萬象的存取控制方法。 有權存取升級函式的實體可以變更_整個_合約。 但鑽石模式啟用了模組化權限方法，可以限制實體僅升級智慧型合約中的特定函式。 -[關於鑽石模式的更多資訊](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w) +[更多關於鑽石模式的資訊](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w)。 -## 升級智慧型合約的利弊 {#pros-and-cons-of-upgrading-smart-contracts} +## 升級智能合約的優缺點 {#pros-and-cons-of-upgrading-smart-contracts} | 優勢 | 劣勢 | | ------------------------------------- | --------------------------------------- | @@ -128,38 +128,38 @@ lang: zh-tw | 合約升級給了開發者更多的空間去試驗不同的功能並持續地改進去中心化應用程式。 | 升級智慧型合約的機會可能會鼓勵開發者在開發階段未經充分檢查研究就快速發佈專案。 | | | 智慧型合約的不安全存取控制和中心化可能導致惡意行爲者更容易執行未經授權的升級。 | -## 升級智慧型合約的注意事項 {#considerations-for-upgrading-smart-contracts} +## 升級智能合約的注意事項 {#considerations-for-upgrading-smart-contracts} 1. 使用安全的存取控制/授權機制來避免未經授權的智慧型合約升級，尤其是在使用代理模式、策略模式或資料分離時。 例如，限制對升級函式的存取，使得只有合約的所有者可以呼叫升級函式。 2. 升級智慧型合約是一個複雜的活動，需要高度的謹慎，避免引入漏洞。 -3. 透過升級實作流程的去中心化，減少信任假設。 可能的策略包括使用[多重簽名錢包合約](/developers/docs/smart-contracts/#multisig)來控制升級，或要求[去中心化自治組織 (DAO) 的成員](/dao/)投票批准升級。 +3. 透過升級實作流程的去中心化，減少信任假設。 可能的策略包括使用[多重簽名錢包合約](/developers/docs/smart-contracts/#multisig)來控制升級，或要求 [DAO 的成員](/dao/)投票批准升級。 4. 注意升級合約的相關花費。 例如，在合約遷移期間從原有合約複製狀態（如使用者餘額）到新合約可能會需要不止一筆交易，這意味著需要更多燃料費。 -5. 考慮實作**時間鎖**來保護使用者。 時間鎖是指延遲執行對系統的變更。 時間鎖可以與多重簽名管理體系相結合來控制升級：如果提議的行動達到了所需的批准門檻，它還需要等到預定義的延遲期過後才會執行。 +5. 考慮實作**時間鎖**以保護使用者。 時間鎖是指延遲執行對系統的變更。 時間鎖可以與多重簽名管理體系相結合來控制升級：如果提議的行動達到了所需的批准門檻，它還需要等到預定義的延遲期過後才會執行。 如果使用者不同意提議的變更（例如，邏輯升級或新的費用方案），時間鎖讓使用者有時間可以退出系統。 沒有時間鎖，使用者必須信任開發者不會未提前通知，便在智慧型合約上實作隨意變更。 缺點是，時間鎖限制了快速修補漏洞的能力。 ## 資源 {#resources} -**OpenZeppelin 升級外掛程式 - _一系列用於部署和保護可升級智慧型合約的工具。_** +**OpenZeppelin 升級外掛程式 - _一系列用於部署和保護可升級智能合約的工具。_** - [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades) - [文件](https://docs.openzeppelin.com/upgrades) ## 教學 {#tutorials} -- [升級你的智慧型合約 | YouTube 使用教學](https://www.youtube.com/watch?v=bdXJmWajZRY) - 作者：Patrick Collins -- [以太坊智慧型合約遷移使用教學](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) - 作者：Austin Griffith -- [使用通用可升級代理標準 (UUPS) 代理模式升級智慧型合約](https://blog.logrocket.com/author/praneshas/) - 作者：Pranesh A.S -- [Web3 使用教學：使用 OpenZeppelin 編寫可升級的智慧型合約（代理）](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916)- 作者：fangjun.eth +- [升級你的智能合約 | YouTube 教學](https://www.youtube.com/watch?v=bdXJmWajZRY) - Patrick Collins +- [以太坊智能合約遷移教學](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) - Austin Griffith +- [使用 UUPS 代理模式升級智能合約](https://blog.logrocket.com/author/praneshas/) - Pranesh A.S +- [Web3 教學：使用 OpenZeppelin 編寫可升級智能合約 (代理)](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) - fangjun.eth -## 了解更多 {#further-reading} +## 延伸閱讀 {#further-reading} -- [智慧型合約升級的狀態](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) - 作者：Santiago Palladino -- [多種升級 Solidity 智慧型合約的方法](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Pool 部落格 -- [學習：升級智慧型合約](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin 文件 -- [適合 Solidity 合約升級能力的代理模式：透明與通用可升級代理標準 (UUPS) 代理](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) - 作者：Naveen Sahu -- [鑽石升級運作原理](https://dev.to/mudgen/how-diamond-upgrades-work-417j) - 作者：Nick Mudge +- [智能合約升級的現狀](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) - Santiago Palladino +- [升級 Solidity 智能合約的多種方法](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Pool 部落格 +- [學習：升級智能合約](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin 文件 +- [Solidity 合約可升級性的代理模式：透明代理與 UUPS 代理之比較](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) - Naveen Sahu +- [鑽石升級的運作原理](https://dev.to/mudgen/how-diamond-upgrades-work-417j) - Nick Mudge diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/verifying/index.md index ba50185864c..b81e5655164 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/verifying/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/verifying/index.md @@ -1,16 +1,16 @@ --- -title: 驗證智慧型合約 -description: 以太坊智慧型合約原始程式碼驗證概覽 +title: "驗證智慧型合約" +description: "以太坊智慧型合約原始程式碼驗證概覽" lang: zh-tw --- -[智慧型合約](/developers/docs/smart-contracts/)被設計為「去信任」，意味著使用者在與合約互動前不需要信任第三方（如開發者和公司）。 作為實現去信任化的必要條件，使用者和其他開發者必須能夠驗證智慧型合約的原始程式碼。 原始程式碼驗證可確保使用者和開發者所發佈的合約程式碼，與在以太坊區塊鏈上的合約地址執行的程式碼相同。 +[智能合約](/developers/docs/smart-contracts/) 的設計是「去信任」，這表示使用者在與合約互動前不需要信任第三方（例如，開發者和公司）。 作為實現去信任化的必要條件，使用者和其他開發者必須能夠驗證智慧型合約的原始程式碼。 原始程式碼驗證可確保使用者和開發者所發佈的合約程式碼，與在以太坊區塊鏈上的合約地址執行的程式碼相同。 -區分「原始程式碼驗證」和「[形式化驗證](/developers/docs/smart-contracts/formal-verification/)」很重要。 原始程式碼驗證（將在下面詳細解釋）指的是驗證以高階語言（例如 Solidity）編寫的智慧型合約之給定原始程式碼，是否被編譯為在合約地址執行的相同位元組碼。 而形式驗證描述的是驗證智慧型合約的正確性，亦即合約是否按預期執行。 雖然需要依情境而定，但合約驗證通常指原始程式碼驗證。 +區分「原始程式碼驗證」和「[形式化驗證](/developers/docs/smart-contracts/formal-verification/)」是很重要的。 原始程式碼驗證（將在下面詳細解釋）指的是驗證以高階語言（例如 Solidity）編寫的智能合約之給定原始程式碼，是否被編譯為在合約地址執行的相同位元組碼。 而形式驗證描述的是驗證智慧型合約的正確性，亦即合約是否按預期執行。 雖然需要依情境而定，但合約驗證通常指原始程式碼驗證。 ## 甚麼是原始程式碼驗證？ {#what-is-source-code-verification} -在[以太坊虛擬機 (EVM)](/developers/docs/evm/) 中部署智慧型合約前，開發者會將合約的原始程式碼（用 [Solidity](/developers/docs/smart-contracts/languages/) 或其他高階編程語言編寫的指令）[編譯](/developers/docs/smart-contracts/compiling/)為位元組碼。 由於以太坊虛擬機無法解釋高階指令，把原始程式碼編譯為位元組碼（即低階機器指令）是在以太坊虛擬機中執行合約邏輯的必需步驟。 +在 [以太坊虛擬機 (EVM)](/developers/docs/evm/) 中部署智能合約之前，開發者會將合約的原始程式碼（以 [Solidity](/developers/docs/smart-contracts/languages/) 或其他高階程式語言撰寫的指令）[編譯](/developers/docs/smart-contracts/compiling/)為位元組碼。 由於以太坊虛擬機無法解釋高階指令，把原始程式碼編譯為位元組碼（即低階機器指令）是在以太坊虛擬機中執行合約邏輯的必需步驟。 原始程式碼驗證會將智慧型合約的原始程式碼與合約建立時使用的編譯位元組碼進行比較，以偵測任何差異。 驗證智慧型合約很重要，因為宣傳的合約程式碼可能與在區塊鏈上執行的程式碼有所不同。 @@ -20,17 +20,17 @@ lang: zh-tw 原始程式碼中有部分內容不會影響到編譯後的位元組碼，例如註解和變數名稱。 這意味著，即使兩份原始程式碼使用不同的變數名稱和註解，也能驗證相同的合約。 這樣一來，惡意行為者可以在原始程式碼中新增欺騙性的註解或給予誤導性的變數名稱，並使用與最初的原始程式碼不同的原始程式碼來驗證合約。 -可以透過在位元組碼中附加額外資料來避免這種情況，這些資料會用作原始程式碼準確性的_加密保證_，以及編譯資訊的_指紋_。 所需的資訊可以在 [Solidity 的合約中繼資料](https://docs.soliditylang.org/en/v0.8.15/metadata.html)中找到，並將該檔案的雜湊值附加到合約的位元組碼。 你可以在[中繼資料訓練場](https://playground.sourcify.dev)中看到它的實際應用。 +可以透過在位元組碼中附加額外資料來避免這種情況，這些資料會用作原始程式碼準確性的_加密保證_，以及編譯資訊的_指紋_。 必要的資訊可以在 [Solidity 的合約中繼資料](https://docs.soliditylang.org/en/v0.8.15/metadata.html) 中找到，該檔案的哈希會附加到合約的位元組碼中。 您可以在 [中繼資料遊樂場](https://playground.sourcify.dev) 看到實際運作 中繼資料檔案包含了合約編譯的相關資訊，包括原始碼檔案及其雜湊值。 也就是說，如果任何一個編譯設定，甚至其中一個原始碼檔案中的一個位元組發生變化，中繼資料檔案就會改變。 因此，附加到位元組碼的中繼資料檔案之雜湊值也就隨之改變了。 這表示，如果某合約的位元組碼 + 附加的中繼資料雜湊值與給定的原始程式碼及編譯設定相符，則我們可以確定這與原始編譯中所用的原始程式碼完全相同，連一個位元組都不差。 -這種使用中繼資料的驗證方式稱為 **「[完整驗證](https://docs.sourcify.dev/docs/full-vs-partial-match/)」**（又稱「完美驗證」）。 如果中繼資料雜湊值不符，或者在驗證過程中未考慮該部分，則這種驗證會是「部分相符」，這是目前較常見的合約驗證方式。 如果不是使用完整驗證，則[植入惡意程式碼](https://samczsun.com/hiding-in-plain-sight/)是可行的，且不會反映在驗證過的原始程式碼中。 大多數開發者不了解完整驗證，在編譯時沒有保留中繼資料檔案，因此部分驗證也就成為了大家迄今習以為常的智慧型合約驗證方式。 +這種利用中繼資料哈希的驗證類型被稱為 **「[完整驗證](https://docs.sourcify.dev/docs/full-vs-partial-match/)」**（也稱為「完美驗證」）。 如果中繼資料雜湊值不符，或者在驗證過程中未考慮該部分，則這種驗證會是「部分相符」，這是目前較常見的合約驗證方式。 若沒有完整驗證，就有可能[插入惡意程式碼](https://samczsun.com/hiding-in-plain-sight/)，而這些惡意程式碼不會反映在已驗證的原始程式碼中。 大多數開發者不了解完整驗證，在編譯時沒有保留中繼資料檔案，因此部分驗證也就成為了大家迄今習以為常的智慧型合約驗證方式。 ## 為何原始程式碼驗證很重要？ {#importance-of-source-code-verification} -### 去信任化 {#trustlessness} +### 去信任 {#trustlessness} -去信任化可以說是智慧型合約和[去中心化應用程式 (dapp)](/developers/docs/dapps/) 中最關鍵的部分。 智慧型合約是「不可變」的，且無法修改；合約只會執行部署時在程式碼中定義好的商業邏輯。 這表示開發者和企業在以太坊上部署合約後，無法篡改其程式碼。 +去信任可以說是智能合約和[去中心化應用程式 (dapp)](/developers/docs/dapps/) 的最大前提。 智慧型合約是「不可變」的，且無法修改；合約只會執行部署時在程式碼中定義好的商業邏輯。 這表示開發者和企業在以太坊上部署合約後，無法篡改其程式碼。 要成為去信任化的智慧型合約，合約的程式碼應可供獨立驗證。 雖然每個智慧型合約編譯過的位元組碼都公開在區塊鏈上，但低階語言很難理解，對開發者和使用者來說皆是如此。 @@ -40,15 +40,15 @@ lang: zh-tw ### 使用者安全 {#user-safety} -智能合約中通常會質押大量資金。 這就需要更高的安全保證，並在使用智慧型合約之前驗證其邏輯。 問題在於，不擇手段的開發者可以透過在智慧型合約中植入惡意程式碼來欺騙使用者。 在未經驗證的情況下，惡意智慧型合約可能具有[後門](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)、有爭議的存取控制機制、可利用的漏洞以及其他可能危害使用者安全但未被偵測到的事物。 +智能合約中通常會質押大量資金。 這就需要更高的安全保證，並在使用智慧型合約之前驗證其邏輯。 問題在於，不擇手段的開發者可以透過在智慧型合約中植入惡意程式碼來欺騙使用者。 若未經驗證，惡意智能合約可能會藏有[後門](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)、具爭議性的存取控制機制、可被利用的漏洞，以及其他會危及使用者安全卻未被偵測到的事物。 公開發佈智慧型合約原始程式碼可以讓有興趣的人（比如智慧型合約的審核者）更容易評估該合約的潛在攻擊媒介。 透過多方獨立驗證，智慧型合約的安全性對使用者來說更有保障。 -## 如何驗證以太坊智慧型合約的原始程式碼 {#source-code-verification-for-ethereum-smart-contracts} +## 如何驗證以太坊智能合約的原始程式碼 {#source-code-verification-for-ethereum-smart-contracts} -[在以太坊上部署智慧型合約](/developers/docs/smart-contracts/deploying/)時，需要發送一筆具有資料承載（經編譯的位元組碼）的交易至一個特別的地址。 透過編譯原始程式碼產生資料承載，再將合約執行個體的[建構函式引數](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor)附加到交易中的資料承載。 編譯是確定性的，也就是說，只要使用相同的原始碼檔案及編譯設定（如編譯器版本、最佳化工具），每次都能產生相同的輸出（即合約位元組碼）。 +[在以太坊上部署智能合約](/developers/docs/smart-contracts/deploying/) 需要傳送一筆帶有資料酬載（已編譯的位元組碼）的交易到一個特殊地址。 資料酬載是透過編譯原始程式碼產生，再加上合約實例的 [建構函式參數](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) 附加到交易的資料酬載中。 編譯是確定性的，也就是說，只要使用相同的原始碼檔案及編譯設定（如編譯器版本、最佳化工具），每次都能產生相同的輸出（即合約位元組碼）。 -![展示智慧型合約原始程式碼驗證的流程圖](./source-code-verification.png) +![顯示智能合約原始程式碼驗證的圖表](./source-code-verification.png) 驗證智慧型合約主要包含以下步驟： @@ -62,7 +62,7 @@ lang: zh-tw 5. 此外，如果位元組碼尾端的中繼資料雜湊值相符，則屬於完全相符。 -請注意，這是對驗證的大致描述，有很多例外不適用以上情況，如具有[不可變的變數](https://docs.sourcify.dev/docs/immutables/)。 +請注意，這只是對驗證的簡化描述，有很多例外情況不適用，例如有[不可變的變數](https://docs.sourcify.dev/docs/immutables/)。 ## 原始程式碼驗證工具 {#source-code-verification-tools} @@ -70,38 +70,44 @@ lang: zh-tw ### Etherscan {#etherscan} -Etherscan 通常被稱為[以太坊區塊鏈瀏覽器](/developers/docs/data-and-analytics/block-explorers/)，它還為智慧型合約開發者和使用者提供了[原始程式碼驗證服務](https://etherscan.io/verifyContract)。 +雖然 Etherscan 主要為人所知的是 [以太坊區塊鏈瀏覽器](/developers/docs/data-and-analytics/block-explorers/)，但它也為智能合約開發者和使用者提供[原始程式碼驗證服務](https://etherscan.io/verifyContract)。 -Etherscan 讓你可以從原始資料承載（原始程式碼、程式庫地址、編譯器設定、合約地址等）重新編譯合約位元組碼。 如果重新編譯的位元組碼與鏈上合約的位元組碼（及建構函式參數）關聯，則表示[該合約通過驗證](https://info.etherscan.com/types-of-contract-verification/)。 +Etherscan 讓你可以從原始資料承載（原始程式碼、程式庫地址、編譯器設定、合約地址等）重新編譯合約位元組碼。 如果重新編譯的位元組碼與鏈上合約的位元組碼（及建構函式參數）相關，那麼 [該合約就已驗證](https://info.etherscan.com/types-of-contract-verification/)。 -一經驗證，合約的原始程式碼會收到一個「已驗證」標籤，並會發佈到 Etherscan 供其他人審核。 該合約也會新增到[已驗證合約](https://etherscan.io/contractsVerified/)區段 — 這是智慧型合約儲存經驗證之原始程式碼的儲存庫。 +一經驗證，合約的原始程式碼會收到一個「已驗證」標籤，並會發佈到 Etherscan 供其他人審核。 它也會被新增到 [Verified Contracts](https://etherscan.io/contractsVerified/) 區塊——一個存放具有已驗證原始程式碼的智能合約的儲存庫。 -Etherscan 是最常用的合約驗證工具。 不過，Etherscan 的合約驗證流程有個缺點：無法比較鏈上位元組碼和重新編譯的位元組碼的**中繼資料雜湊值**。 因此，Etherscan 中的符合屬於部分符合。 +Etherscan 是最常用的合約驗證工具。 然而，Etherscan 的合約驗證有一個缺點：它無法比較鏈上位元組碼和重新編譯的位元組碼的 **中繼資料哈希**。 因此，Etherscan 中的符合屬於部分符合。 -[有關在 Etherscan 上驗證合約的更多資訊](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327)。 +[更多關於在 Etherscan 上驗證合約的資訊](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327)。 + +### Blockscout {#blockscout} + +[Blockscout](https://blockscout.com/) 是一個開源的區塊鏈瀏覽器，也為智能合約開發者和使用者提供[合約驗證服務](https://eth.blockscout.com/contract-verification)。 作為一個開源的替代方案，Blockscout 提供了驗證執行方式的透明度，並讓社群能夠貢獻以改善驗證過程。 + +與其他驗證服務類似，Blockscout 允許您透過重新編譯位元組碼，並將其與已部署的合約進行比較，來驗證您合約的原始程式碼。 一旦驗證完成，您的合約就會收到驗證狀態，其原始程式碼也會公開，以供審計和互動。 已驗證的合約也會列在 Blockscout 的[已驗證合約儲存庫](https://eth.blockscout.com/verified-contracts)中，以便輕鬆瀏覽和發現。 ### Sourcify {#sourcify} -[Sourcify](https://sourcify.dev/#/verifier) 是另一個用於驗證開放原始碼和去中心化合約的工具。 它不是區塊瀏覽器，並且僅驗證[以以太坊虛擬機為基礎的不同網路](https://docs.sourcify.dev/docs/chains)上的合約。 它充當其他工具在其上建置的公共基礎設施，旨在使用中繼資料檔案中找到的[應用程式二進位介面 (ABI)](/developers/docs/smart-contracts/compiling/#web-applications) 和 [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) 註解來實現更人性化的合約互動。 +[Sourcify](https://sourcify.dev/#/verifier) 是另一個用於驗證合約的工具，它本身是開源且去中心化的。 它不是區塊鏈瀏覽器，只驗證[不同基於 EVM 的網路](https://docs.sourcify.dev/docs/chains)上的合約。 它作為一個公共基礎設施，供其他工具在此之上建構，並旨在利用中繼資料檔案中的 [ABI](/developers/docs/smart-contracts/compiling/#web-applications) 和 [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) 註解，來實現更人性化的合約互動。 -跟 Etherscan 不同，Sourcify 支援與中繼資料雜​​湊值的完全符合。 經驗證的合約會在其[公開儲存庫](https://docs.sourcify.dev/docs/repository/)中，以超文字傳輸通訊協定 (HTTP) 和[星際檔案系統 (IPFS)](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs)（一種去中心化、[內容尋址](https://web3.storage/docs/concepts/content-addressing/)的儲存服務）的形式提供。 這樣可以透過星際檔案系統取得合約的中繼資料檔案，因為附加的中繼資料雜湊值就是星際檔案系統雜湊值。 +跟 Etherscan 不同，Sourcify 支援與中繼資料雜​​湊值的完全符合。 已驗證的合約透過 HTTP 和 [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) 在其[公共儲存庫](https://docs.sourcify.dev/docs/repository/)中提供，IPFS 是一種去中心化的[內容定址](https://docs.storacha.network/concepts/content-addressing/)儲存方式。 這樣可以透過星際檔案系統取得合約的中繼資料檔案，因為附加的中繼資料雜湊值就是星際檔案系統雜湊值。 -此外，也可以透過星際檔案系統取得原始程式碼檔案，因為這些檔案的星際檔案系統雜湊值也可以在中繼資料中找到。 可以透過應用程式介面或[使用者介面](https://sourcify.dev/#/verifier)提供中繼資料檔案和原始碼檔案，或使用外掛程式來驗證合約。 Sourcify 的監控工具也會監聽新區塊中的合約建立，並在該合約的中繼資料及原始碼檔案發佈到星際檔案系統的情況下嘗試驗證該合約。 +此外，也可以透過星際檔案系統取得原始程式碼檔案，因為這些檔案的星際檔案系統雜湊值也可以在中繼資料中找到。 合約可以透過其 API 或 [UI](https://sourcify.dev/#/verifier) 提供中繼資料檔案和原始碼檔案，或使用外掛程式進行驗證。 Sourcify 的監控工具也會監聽新區塊中的合約建立，並在該合約的中繼資料及原始碼檔案發佈到星際檔案系統的情況下嘗試驗證該合約。 -[有關在 Sourcify 上驗證合約的更多資訊](https://blog.soliditylang.org/2020/06/25/sourcify-faq/)。 +[更多關於在 Sourcify 上驗證合約的資訊](https://soliditylang.org/blog/2020/06/25/sourcify-faq/)。 ### Tenderly {#tenderly} -[Tenderly 平台](https://tenderly.co/)讓 Web3 開發者可以建置、測試、監控及運行智慧型合約。 透過將偵錯工具與可觀測性及基礎設施建置區塊相結合，Tenderly 協助開發者加速開發智慧型合約。 要完整啟用 Tenderly 的功能，開發者需要使用多種方法[執行原始程式碼驗證](https://docs.tenderly.co/monitoring/contract-verification)。 +[Tenderly 平台](https://tenderly.co/) 讓 Web3 開發者能夠建立、測試、監控和操作智能合約。 透過將偵錯工具與可觀測性及基礎設施建置區塊相結合，Tenderly 協助開發者加速開發智慧型合約。 要完全啟用 Tenderly 的功能，開發者需要使用多種方法來[執行原始程式碼驗證](https://docs.tenderly.co/monitoring/contract-verification)。 私下或公開地驗證合約皆可行。 如果私下驗證，則智慧型合約僅對你（以及專案中的其他成員）可見。 公開驗證合約會讓合約對使用 Tenderly 平台的每個人都可見。 -你可以透過[儀表板](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract)、[Tenderly Hardhat 外掛程式](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin)或 [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) 驗證合約。 +您可以使用 [儀表板](https://docs.tenderly.co/contract-verification)、[Tenderly Hardhat 外掛](https://docs.tenderly.co/contract-verification/hardhat) 或 [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) 來驗證您的合約。 透過儀表板驗證合約時，需要匯入原始碼檔案或 Solidity 編譯器產生的中繼資料檔案、地址/網路及編譯器設定。 使用 Tenderly Hardhat 外掛程式可以更輕鬆、更全面地控制驗證流程，在自動化（無程式碼）和手動（基於程式碼）這兩種驗證方式之間選擇。 -## 了解更多 {#further-reading} +## 延伸閱讀 {#further-reading} - [驗證合約原始程式碼](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/zh-tw/developers/docs/standards/index.md b/public/content/translations/zh-tw/developers/docs/standards/index.md new file mode 100644 index 00000000000..b22ca2daec1 --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/standards/index.md @@ -0,0 +1,59 @@ +--- +title: "以太坊開發標準" +description: "了解以太坊標準，包括 EIPs、ERC-20 和 ERC-721 等代幣標準，以及開發慣例。" +lang: zh-tw +incomplete: true +--- + +## 標準概覽 {#standards-overview} + +以太坊社群已採用多項標準，以利於專案（例如[以太坊用戶端](/developers/docs/nodes-and-clients/)與錢包）在不同實作之間保持互通性，並確保智慧合約與去中心化應用程式維持可組合性。 + +標準通常以[以太坊改進提案](/eips/) (EIP) 的形式提出，並由社群成員透過[標準程序](https://eips.ethereum.org/EIPS/eip-1)進行討論。 + +- [EIP 簡介](/eips/) +- [EIP 列表](https://eips.ethereum.org/) +- [EIP GitHub 儲存庫](https://github.com/ethereum/EIPs) +- [EIP 討論區](https://ethereum-magicians.org/c/eips) +- [以太坊管理體系簡介](/governance/) +- [以太坊管理體系概覽](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019 年 3 月 31 日 - Boris Mann_ +- [以太坊協議開發管理體系與網路升級協調](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020 年 3 月 23 日 - Hudson Jameson_ +- [所有以太坊核心開發者會議的播放清單](https://www.youtube.com/@EthereumProtocol) _(YouTube 播放清單)_ + +## 標準類型 {#types-of-standards} + +EIP 有三種類別： + +- 標準類別：任何影響多數或全部以太坊實作的改變 +- [元類別](https://eips.ethereum.org/meta)：描述與以太坊相關的程序，或提議對程序進行變更 +- [資訊類別](https://eips.ethereum.org/informational)：描述以太坊的設計問題，或向以太坊社群提供一般性的指導方針或資訊 + +此外，標準類別還能被細分為四個子類別： + +- [核心](https://eips.ethereum.org/core)：需要共識分叉的改進 +- [網路](https://eips.ethereum.org/networking)：關於 devp2p 和輕量級以太坊子協議的改進，以及對 whisper 和 swarm 網路協議規範的建議改進。 +- [介面](https://eips.ethereum.org/interface)：關於用戶端 API/RPC 規範和標準的改進，以及某些語言層級的標準，例如方法名稱和合約 ABI。 +- [ERC](https://eips.ethereum.org/erc)：應用程式層級的標準與慣例 + +關於這些不同類型和類別的更多詳細資訊，可在 [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) 中找到 + +### 代幣標準 {#token-standards} + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 一種適用於同質化（可互換）代幣的標準介面，例如投票代幣、質押代幣或虛擬貨幣。 + - [ERC-223](/developers/docs/standards/tokens/erc-223/) - 一種同質化代幣標準，讓代幣的行為與以太幣相同，並支援接收端處理代幣轉帳。 + - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - ERC-20 代幣的擴充介面，支援在單一交易中對接收方合約執行回呼。 +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - 一種非同質化代幣的標準介面，例如藝術品或歌曲的契約。 + - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - 一種標準化事件，在使用連續的代幣識別碼建立/轉移一個或多個非同質化代幣時發出。 + - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721 消費者角色的介面擴充。 + - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - 為 ERC-721 代幣新增具備受限權限且有時限的角色。 +- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(不建議使用)** 一種改進 ERC-20 的代幣標準。 +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - 一種可同時包含同質化與非同質化資產的代幣標準。 +- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - 一種代幣化金庫標準，旨在最佳化和統一具收益金庫的技術參數。 + +深入了解[代幣標準](/developers/docs/standards/tokens/)。 + +## 延伸閱讀 {#further-reading} + +- [以太坊改進提案 (EIP)](/eips/) + +_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容！_ diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1155/index.md new file mode 100644 index 00000000000..2e2a4b04b41 --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1155/index.md @@ -0,0 +1,146 @@ +--- +title: "ERC-1155 多代幣標準" +description: "了解 ERC-1155，這是一種多代幣標準，可在單一合約中結合同質化代幣和非同質化代幣。" +lang: zh-tw +--- + +## 介紹 {#introduction} + +用於多種代幣管理的合約標準介面 單一部署的合約可以包括同質化代幣、非同質化代幣或其他配置（例如半同質化代幣）的任意組合。 + +**多代幣標準是什麼意思？** + +這個想法很簡單，旨在創建一個智慧型合約介面，可以表示和控制任意數量的同質化和非同質化代幣類型。 如此一來，ERC-1155 代幣可以執行與 [ERC-20](/developers/docs/standards/tokens/erc-20/) 和 [ERC-721](/developers/docs/standards/tokens/erc-721/) 代幣相同的功能，甚至可以同時執行兩者的功能。 它改進了 ERC-20 和 ERC-721 標準的功能，使其更有效率並修正了明顯的實作錯誤。 + +[EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) 中對 ERC-1155 代幣有完整說明。 + +## 先決條件 {#prerequisites} + +為了更了解此頁面，建議您先閱讀有關[代幣標準](/developers/docs/standards/tokens/)、[ERC-20](/developers/docs/standards/tokens/erc-20/) 和 [ERC-721](/developers/docs/standards/tokens/erc-721/) 的內容。 + +## ERC-1155 函式和功能： {#body} + +- [批次轉帳](#batch_transfers)：在單次呼叫中轉帳多個資產。 +- [批次餘額](#batch_balance)：在單次呼叫中取得多個資產的餘額。 +- [批次授權](#batch_approval)：將所有代幣授權給一個地址。 +- [掛鉤](#receive_hook)：接收代幣掛鉤。 +- [支援 NFT](#nft_support)：若供應量只有 1，則視為 NFT。 +- [安全轉帳規則](#safe_transfer_rule)：一組用於安全轉帳的規則。 + +### 批次轉帳 {#batch-transfers} + +批量傳送的工作原理與常規 ERC-20 傳送非常相似。 我們來看看標準的 ERC-20 `transferFrom` 函式： + +```solidity +// ERC-20 +function transferFrom(address from, address to, uint256 value) external returns (bool); + +// ERC-1155 +function safeBatchTransferFrom( + address _from, + address _to, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external; +``` + +ERC-1155 中唯一的區別是我們將值作爲陣列傳輸，同時也傳輸了 ids 陣列。 例如，給定 `ids=[3, 6, 13]` 和 `values=[100, 200, 5]`，轉帳結果將是 + +1. 從 `_from` 將 100 個 ID 為 3 的代幣轉帳到 `_to`。 +2. 從 `_from` 將 200 個 ID 為 6 的代幣轉帳到 `_to`。 +3. 從 `_from` 將 5 個 ID 為 13 的代幣轉帳到 `_to`。 + +在 ERC-1155 中，我們只有 `transferFrom`，沒有 `transfer`。 若要像一般的 `transfer` 那樣使用，只需將來源地址設為呼叫此函式的地址。 + +### 批次餘額 {#batch-balance} + +對應的 ERC-20 `balanceOf` 呼叫，同樣也具有支援批次處理的對應函式。 作爲對比，這是 ERC-20 的版本: + +```solidity +// ERC-20 +function balanceOf(address owner) external view returns (uint256); + +// ERC-1155 +function balanceOfBatch( + address[] calldata _owners, + uint256[] calldata _ids +) external view returns (uint256[] memory); +``` + +對於餘額調用來說更簡單，我們可以在一次調用中取得多個餘額。 我們傳輸所有者的陣列，然後是代幣 ids 的陣列。 + +例如，給定 `_ids=[3, 6, 13]` 和 `_owners=[0xbeef..., 0x1337..., 0x1111...]`，傳回值會是 + +```solidity +[ + balanceOf(0xbeef...), + balanceOf(0x1337...), + balanceOf(0x1111...) +] +``` + +### 批次授權 {#batch-approval} + +```solidity +// ERC-1155 +function setApprovalForAll( + address _operator, + bool _approved +) external; + +function isApprovedForAll( + address _owner, + address _operator +) external view returns (bool); +``` + +批准與 ERC-20 略有不同。 您可以透過 `setApprovalForAll` 將操作者設為已授權或未授權，而不是授權特定數量。 + +可以透過 `isApprovedForAll` 讀取目前的授權狀態。 如你所見，要么全部批准，要么不批准。 不能定義要批准代幣的數量，甚至代幣類型。 + +這是考慮到簡潔性而故意設計的。 你只能批准一個地址的所有代幣。 + +### 接收掛鉤 {#receive-hook} + +```solidity +function onERC1155BatchReceived( + address _operator, + address _from, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external returns(bytes4); +``` + +因為支援 [EIP-165](https://eips.ethereum.org/EIPS/eip-165)，ERC-1155 僅支援智能合約的接收掛鉤。 鉤子函數必須傳回一個事先預先定義的 4 位元組值，這個值被指定為： + +```solidity +bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) +``` + +當接收合約傳回此值時，表示合約知道如何處理 ERC-1155 代幣並接受轉帳。 太好了，代幣不會再卡在合約中了！ + +### 支援 NFT {#nft-support} + +當供應量只有 1 時，該代幣本質上是非同質化代幣 (NFT)。 依照 ERC-721 標準，你可以定義一個元數據網址。 用戶端可以讀取和修改該 URL，請參閱[此處](https://eips.ethereum.org/EIPS/eip-1155#metadata)。 + +### 安全轉帳規則 {#safe-transfer-rule} + +在前面的解釋中，我們已經提到過一些安全轉帳規則。 現在我們來看看最重要的規則： + +1. 呼叫者必須已獲授權，可代表 `_from` 地址花費代幣，或者呼叫者必須等於 `_from`。 +2. 在以下情況下，轉帳呼叫將回退 + 1. `_to` 地址為 0。 + 2. `_ids` 的長度與 `_values` 的長度不同。 + 3. `_ids` 中任何代幣持有者的餘額，低於 `_values` 中發送給接收者的對應數量。 + 4. 出現任何其他錯誤。 + +_注意_：所有批次函式 (包含掛鉤) 也都存在非批次版本。 這樣做是為了提高燃料效率，考慮到只轉移一種資產可能仍然是最常用的方式。 簡潔起見，我們在這裡沒有介紹這些非批次的版本，包括安全轉帳規則。 名稱是相同的，只需移除 'Batch'。 + +## 延伸閱讀 {#further-reading} + +- [EIP-1155：多代幣標準](https://eips.ethereum.org/EIPS/eip-1155) +- [ERC-1155：OpenZeppelin 文件](https://docs.openzeppelin.com/contracts/5.x/erc1155) +- [ERC-1155：GitHub 儲存庫](https://github.com/enjin/erc-1155) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1363/index.md new file mode 100644 index 00000000000..75c2197f77e --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-1363/index.md @@ -0,0 +1,204 @@ +--- +title: "ERC-1363 可支付代幣標準" +description: "ERC-1363 是 ERC-20 代幣的擴充介面，支援在單一交易內，於轉帳後在接收方合約上執行自訂邏輯，或在核准後於支出方合約上執行自訂邏輯。" +lang: zh-tw +--- + +## 介紹 {#introduction} + +### 什麼是 ERC-1363？ {#what-is-erc1363} + +ERC-1363 是 ERC-20 代幣的擴充介面，支援在單一交易內，於轉帳後在接收方合約上執行自訂邏輯，或在核准後於支出方合約上執行自訂邏輯。 + +### 與 ERC-20 的區別 {#erc20-differences} + +`transfer`、`transferFrom` 和 `approve` 等標準 ERC-20 操作，若沒有另一筆交易，就不允許在接收方或支出方合約上執行程式碼。 +這在 UI 開發上增加了複雜性，也為採用帶來阻力，因為使用者必須等待第一筆交易執行完畢後，才能提交第二筆交易。 +他們還必須支付兩次 GAS。 + +ERC-1363 讓同質化代幣能更容易執行動作，且無須使用任何鏈下監聽器即可運作。 +它允許在單一交易中，於轉帳或核准後，對接收方或支出方合約進行回呼。 + +## 先決條件 {#prerequisites} + +為更佳地理解本頁面，我們建議您先閱讀關於： + +- [代幣標準](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## 主旨 {#body} + +ERC-1363 為 ERC-20 代幣引入了標準 API，以便在 `transfer`、`transferFrom` 或 `approve` 之後與智能合約互動。 + +此標準提供轉帳代幣的基本功能，也允許代幣被核准，以便由另一個鏈上第三方花用，然後對接收方或支出方合約進行回呼。 + +有許多智能合約的提案用途可以接受 ERC-20 回呼。 + +範例如下： + +- **群眾募資**：送出的代幣會觸發即時獎勵分配。 +- **服務**：付款一步驟即可啟用服務存取權限。 +- **發票**：代幣會自動結清發票。 +- **訂閱**：在支付第一個月款項的交易中核准年費率，即可啟用訂閱。 + +基於這些原因，它最初被命名為 **「Payable Token」(可支付代幣)**。 + +回呼行為進一步擴展了它的功用，實現了無縫互動，例如： + +- **質押**：轉帳的代幣會觸發在質押合約中的自動鎖定。 +- **投票**：收到的代幣會在管理體系中註冊為投票。 +- **交換**：代幣核准一步驟即可啟用交換邏輯。 + +在所有需要在收到轉帳或核准後執行回呼的情況下，都可以使用 ERC-1363 代幣來實現特定的功用。 +ERC-1363 也能夠透過驗證接收方處理代幣的能力，來避免智能合約中的代幣遺失或代幣鎖定。 + +與其他 ERC-20 擴充提案不同，ERC-1363 不會覆寫 ERC-20 的 `transfer` 和 `transferFrom` 方法，而是定義要實作的介面 ID，以維持與 ERC-20 的向後相容性。 + +來自 [EIP-1363](https://eips.ethereum.org/EIPS/eip-1363): + +### 方法 {#methods} + +實作 ERC-1363 標準的智能合約**必須**實作 `ERC1363` 介面中的所有函式，以及 `ERC20` 和 `ERC165` 介面。 + +```solidity +pragma solidity ^0.8.0; + +/** + * @title ERC1363 + * @dev ERC-20 代幣的擴充介面，支援在單一交易內，於 `transfer` 或 `transferFrom` 後在接收方合約上執行程式碼，或在 `approve` 後於支出方合約上執行程式碼。 + */ +interface ERC1363 is ERC20, ERC165 { + /* + * 注意：此介面的 ERC-165 識別碼為 0xb0202a11。 + * 0xb0202a11 === + * bytes4(keccak256('transferAndCall(address,uint256)')) ^ + * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) + */ + + /** + * @dev 將 `value` 數量的代幣從呼叫者的帳戶移至 `to`，然後在 `to` 上呼叫 `ERC1363Receiver::onTransferReceived`。 + * @param to 代幣要轉入的地址。 + * @param value 要轉帳的代幣數量。 + * @return 一個布林值，表示操作成功，除非擲回錯誤。 + */ + function transferAndCall(address to, uint256 value) external returns (bool); + + /** + * @dev 將 `value` 數量的代幣從呼叫者的帳戶移至 `to`，然後在 `to` 上呼叫 `ERC1363Receiver::onTransferReceived`。 + * @param to 代幣要轉入的地址。 + * @param value 要轉帳的代幣數量。 + * @param data 額外資料，無特定格式，在呼叫 `to` 時傳送。 + * @return 一個布林值，表示操作成功，除非擲回錯誤。 + */ + function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev 使用額度機制，將 `value` 數量的代幣從 `from` 移至 `to`，然後在 `to` 上呼叫 `ERC1363Receiver::onTransferReceived`。 + * @param from 代幣要轉出的地址。 + * @param to 代幣要轉入的地址。 + * @param value 要轉帳的代幣數量。 + * @return 一個布林值，表示操作成功，除非擲回錯誤。 + */ + function transferFromAndCall(address from, address to, uint256 value) external returns (bool); + + /** + * @dev 使用額度機制，將 `value` 數量的代幣從 `from` 移至 `to`，然後在 `to` 上呼叫 `ERC1363Receiver::onTransferReceived`。 + * @param from 代幣要轉出的地址。 + * @param to 代幣要轉入的地址。 + * @param value 要轉帳的代幣數量。 + * @param data 額外資料，無特定格式，在呼叫 `to` 時傳送。 + * @return 一個布林值，表示操作成功，除非擲回錯誤。 + */ + function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev 將呼叫者代幣中的 `value` 數量設定為 `spender` 的額度，然後在 `spender` 上呼叫 `ERC1363Spender::onApprovalReceived`。 + * @param spender 將花用資金的地址。 + * @param value 要花用的代幣數量。 + * @return 一個布林值，表示操作成功，除非擲回錯誤。 + */ + function approveAndCall(address spender, uint256 value) external returns (bool); + + /** + * @dev 將呼叫者代幣中的 `value` 數量設定為 `spender` 的額度，然後在 `spender` 上呼叫 `ERC1363Spender::onApprovalReceived`。 + * @param spender 將花用資金的地址。 + * @param value 要花用的代幣數量。 + * @param data 額外資料，無特定格式，在呼叫 `spender` 時傳送。 + * @return 一個布林值，表示操作成功，除非擲回錯誤。 + */ + function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); +} + +interface ERC20 { + event Transfer(address indexed from, address indexed to, uint256 value); + event Approval(address indexed owner, address indexed spender, uint256 value); + function transfer(address to, uint256 value) external returns (bool); + function transferFrom(address from, address to, uint256 value) external returns (bool); + function approve(address spender, uint256 value) external returns (bool); + function totalSupply() external view returns (uint256); + function balanceOf(address account) external view returns (uint256); + function allowance(address owner, address spender) external view returns (uint256); +} + +interface ERC165 { + function supportsInterface(bytes4 interfaceId) external view returns (bool); +} +``` + +想要透過 `transferAndCall` 或 `transferFromAndCall` 接受 ERC-1363 代幣的智能合約**必須**實作 `ERC1363Receiver` 介面： + +```solidity +/** + * @title ERC1363Receiver + * @dev 任何想要支援來自 ERC-1363 代幣合約的 `transferAndCall` 或 `transferFromAndCall` 的合約介面。 + */ +interface ERC1363Receiver { + /** + * @dev 每當 `operator` 從 `from` 透過 `ERC1363::transferAndCall` 或 `ERC1363::transferFromAndCall` 將 ERC-1363 代幣轉帳到此合約時，此函式就會被呼叫。 + * + * 注意：為接受轉帳，此函式必須回傳 + * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` + * (即 0x88a7ca5c，或其自身的函式選擇器)。 + * + * @param operator 呼叫 `transferAndCall` 或 `transferFromAndCall` 函式的地址。 + * @param from 代幣轉出的來源地址。 + * @param value 轉帳的代幣數量。 + * @param data 額外資料，無特定格式。 + * @return 如果允許轉帳，則回傳 `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))`，除非擲回錯誤。 + */ + function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +想要透過 `approveAndCall` 接受 ERC-1363 代幣的智能合約**必須**實作 `ERC1363Spender` 介面： + +```solidity +/** + * @title ERC1363Spender + * @dev 任何想要支援來自 ERC-1363 代幣合約的 `approveAndCall` 的合約介面。 + */ +interface ERC1363Spender { + /** + * @dev 每當 ERC-1363 代幣的 `owner` 透過 `ERC1363::approveAndCall` 核准此合約花用其代幣時，此函式就會被呼叫。 + * + * 注意：為接受核准，此函式必須回傳 + * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` + * (即 0x7b04a2d0，或其自身的函式選擇器)。 + * + * @param owner 呼叫 `approveAndCall` 函式且先前擁有代幣的地址。 + * @param value 要花用的代幣數量。 + * @param data 額外資料，無特定格式。 + * @return 如果允許核准，則回傳 `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))`，除非擲回錯誤。 + */ + function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +## 延伸閱讀 {#further-reading} + +- [ERC-1363：可支付代幣標準](https://eips.ethereum.org/EIPS/eip-1363) +- [ERC-1363：GitHub 儲存庫](https://github.com/vittominacori/erc1363-payable-token) diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-20/index.md new file mode 100644 index 00000000000..16f7fae44e4 --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-20/index.md @@ -0,0 +1,187 @@ +--- +title: "ERC-20 代幣標準" +description: "了解 ERC-20——以太坊上的同質化代幣標準，可實現互通的代幣應用程式。" +lang: zh-tw +--- + +## 介紹 {#introduction} + +**什麼是代幣？** + +代幣幾乎可以代表以太坊中的任何東西： + +- 線上平台信譽積分 +- 遊戲中角色的技能 +- 金融資產，如公司股份 +- 法定貨幣，如美元 +- 一盎司黃金 +- 以及更多... + +以太坊這麼強大的功能當然要由一個穩健的標準來處理，對吧？ 這正是 +ERC-20 發揮作用的地方！ 這個標準允許開發者構建與其他產品和服務相互操作的代幣應用程式。 ERC-20 標準也用於為[以太幣](/glossary/#ether)提供額外功能。 + +**什麼是 ERC-20？** + +ERC-20 引入了同質化代幣的標準，換句話說，這些代幣具有一種屬性，使得每個代幣在類型和值上都與其他代幣完全相同。 例如，ERC-20 代幣就像以太幣一樣，意味著一個代幣會及永遠與其他代幣一樣。 + +## 先決條件 {#prerequisites} + +- [賬戶](/developers/docs/accounts) +- [智能合約](/developers/docs/smart-contracts/) +- [代幣標準](/developers/docs/standards/tokens/) + +## 主旨 {#body} + +ERC-20（以太坊意見請求 20）由 Fabian Vogelsteller 於 2015 年 11 月提出，是一種在智慧型合約中實作代幣應用程式介面的代幣標準。 + +ERC-20 的功能範例： + +- 將代幣從一個帳戶轉移到另一個帳戶 +- 取得帳戶當前代幣餘額 +- 取得網路上可用代幣的總供應量 +- 批准第三方帳戶是否可以使用帳戶中的一定數量代幣 + +如果智慧型合約實作以下方法和事件，則可以將其稱為 ERC-20 代幣合約。一旦部署，它將負責追蹤以太坊上創建的代幣。 + +來自 [EIP-20](https://eips.ethereum.org/EIPS/eip-20): + +### 方法 {#methods} + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) +function approve(address _spender, uint256 _value) public returns (bool success) +function allowance(address _owner, address _spender) public view returns (uint256 remaining) +``` + +### Events {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value) +event Approval(address indexed _owner, address indexed _spender, uint256 _value) +``` + +### 範例 {#web3py-example} + +讓我們看看為何標準如此重要，去讓我們檢查以太坊上的任何 ERC-20 代幣合約變得簡單。 +我們只需要合約應用程式二進位介面 (ABI) 來創建任何 ERC-20 代幣的介面。 如下所示，我們將使用簡化的 ABI，使其成為一個低門檻的範例。 + +#### Web3.py 範例 {#web3py-example} + +首先，請確認您已安裝 [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python 函式庫： + +``` +pip install web3 +``` + +```python +from web3 import Web3 + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI +weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # 包裝以太幣 (WETH) + +acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2：DAI 2 + +# 這是 ERC-20 代幣合約的簡化版合約應用程式二進位介面 (ABI)。 +# 它只會公開以下方法：balanceOf(address)、decimals()、symbol() 和 totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'decimals', + 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) +symbol = dai_contract.functions.symbol().call() +decimals = dai_contract.functions.decimals().call() +totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals +addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# DAI +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) + +weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) +symbol = weth_contract.functions.symbol().call() +decimals = weth_contract.functions.decimals().call() +totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals +addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# WETH +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) +``` + +## 已知問題 {#erc20-issues} + +### ERC-20 代幣接收問題 {#reception-issue} + +**截至 2024 年 6 月 20 日，已有至少價值 83,656,418 美元的 ERC-20 代幣因此問題而遺失。** **請注意，除非您在標準之上額外實作下列的一系列限制，否則純粹的 ERC-20 實作很容易發生此問題。** + +當 ERC-20 代幣被發送到並非用於處理 ERC-20 代幣而設計的智慧型合約時，這些代幣可能會永久丟失。 發生這種情況是因為接收合約不具有識別或回應傳入代幣的功能，且 ERC-20 標準中沒有機制來通知接收合約有關傳入代幣的資訊。 這個問題形成的主要方式是： + +1. 代幣傳送機制 + +- ERC-20 代幣使用了 transfer 或 transferFrom 函數傳送 + - 當用戶使用這些函數將代幣發送到合約地址時，無論接收合約是否為處理代幣而設，代幣都會被傳送 + +2. 缺乏通知 + - 接收的合約沒有收到代幣已發送給它的通知或回調 + - 如果接收合約缺乏處理代幣的機制（例如，遞補函數或管理代幣接收的專用函數），則代幣實際上會卡在合約的地址中 +3. 沒有內建處理 + - ERC-20 標準沒有包括強制要求接收合約實作接收代幣的函數，這導致許多合約無法正確管理收到的代幣 + +**可能的解決方案** + +雖然無法完全透過 ERC-20 避免此問題，但有一些方法可以顯著降低最終用戶代幣損失的可能性： + +- 最常見的問題是，當使用者將代幣傳送到代幣合約地址本身時 (例如，將 USDT 存入 USDT 代幣合約的地址)。 建議限制 `transfer(..)` 函式，以還原此類轉帳嘗試。 可考慮在 `transfer(..)` 函式的實作中加入 `require(_to != address(this));` 檢查。 +- 一般而言，`transfer(..)` 函式並非為將代幣存入合約而設計。 `approve(..) 而是改用 `transferFrom(..)`模式將 ERC-20 代幣存入合約。 雖然可以限制`transfer(..)`函式，以禁止將代幣存入任何合約，但這可能會破壞與某些合約的相容性，因為這些合約假定代幣能以`transfer(..)` 函式存入合約 (例如 Uniswap 流動性資金池)。 +- 請始終假設 ERC-20 代幣會意外地轉入你的合約，即便該合約本不該接收任何代幣。 接收者無法防止或拒絕意外的存款。 建議實現一個功能，允許提取出那些被意外轉入的 ERC-20 代幣。 +- 考慮使用替代的代幣標準。 + +為了解決此問題，出現了一些替代標準，例如 [ERC-223](/developers/docs/standards/tokens/erc-223) 或 [ERC-1363](/developers/docs/standards/tokens/erc-1363)。 + +## 延伸閱讀 {#further-reading} + +- [EIP-20: ERC-20 代幣標準](https://eips.ethereum.org/EIPS/eip-20) +- [OpenZeppelin - 代幣](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) +- [OpenZeppelin - ERC-20 實作](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) +- [Alchemy - Solidity ERC20 代幣指南](https://www.alchemy.com/overviews/erc20-solidity) + +## 其他同質化代幣標準 {#fungible-token-standards} + +- [ERC-223](/developers/docs/standards/tokens/erc-223) +- [ERC-1363](/developers/docs/standards/tokens/erc-1363) +- [ERC-777](/developers/docs/standards/tokens/erc-777) +- [ERC-4626 - 代幣化金庫](/developers/docs/standards/tokens/erc-4626) diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md new file mode 100644 index 00000000000..1d175b234df --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md @@ -0,0 +1,197 @@ +--- +title: "ERC-223 代幣標準" +description: "關於 ERC-223 同質性代筆標準的概述，包含它的運作方式以及與 ERC-20 的對代幣" +lang: zh-tw +--- + +## 介紹 {#introduction} + +### 什麼是 ERC-223？ {#what-is-erc223} + +ERC-223 是一種同質性代筆標準，與 ERC-20 標準類似。 主要的區別在於 ERC-223 不但定義了代幣應用程式介面，還定義了從發送者向接收者傳送代幣的邏輯。 它引入了一個交流模型，使代幣傳送能夠在接收者處進行處理。 + +### 與 ERC-20 的區別 {#erc20-differences} + +ERC-223 解決了 ERC-20 的一些限制，並在代幣合約與可能接受代幣的合約之間引入了一種新的互動方法。 有幾件事情是 ERC-223 可以做到但 ERC-20 不能做到的: + +- 在接收者處處理代幣傳送: 接收者可以檢測 ERC-223 代幣的存入。 +- 拒絕不正確發送的代幣: 如果使用者向不應該接收代幣的合約傳送 ERC-223 代幣，合約可以拒絕該交易，以避免損失代幣。 +- 傳送中的元數據: ERC-223 代幣可以包含元數據，允許在代幣交易上附加任意資訊。 + +## 先決條件 {#prerequisites} + +- [賬戶](/developers/docs/accounts) +- [智能合約](/developers/docs/smart-contracts/) +- [代幣標準](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## 主旨 {#body} + +ERC-223 是一種在智能合約中實現代幣應用程式介面的代幣標準。 它也爲應該接收 ERC-223 代幣的合約聲明了一個應用程式介面。 不支持 ERC-223 接收者應用程式介面的合約無法接收 ERC-223 代幣，這防止了使用者出錯。 + +實現了以下方法和事件的智能合約可以被稱爲 ERC-223 兼容代幣合約。 一旦被部署，它將負責追蹤在以太坊上創建的代幣。 + +合約能夠擁有的函數不只有這些，並且可以將各種代幣標準的任意其他功能添加到該合約。 例如，`approve` 和 `transferFrom` 函數不是 ERC-223 標準的一部分，但如果有必要，這些函數可以被實現。 + +來自 [EIP-223](https://eips.ethereum.org/EIPS/eip-223): + +### 方法 {#methods} + +ERC-223 代幣必須實現一下方法: + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success) +``` + +應該接收 ERC-223 代幣的合約必須實現以下方法: + +```solidity +function tokenReceived(address _from, uint _value, bytes calldata _data) +``` + +如果 ERC-223 代筆被發送到沒有實現 `tokenReceived(..)` 函數的合約，該傳送則必定會失效，並且代幣不會從發送者的餘額中移動。 + +### Events {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data) +``` + +### 範例 {#examples} + +ERC-223 代幣的應用程式介面與 ERC-20 的相似，因此從使用者介面開發的角度上看沒有區別。 唯一的區別是 ERC-223 代幣可能沒有 `approve` + `transferFrom` 函數，因爲這些函數對於該標準是可以選擇的。 + +#### Solidity 範例 {#solidity-example} + +以下範例説明了基礎的 ERC-223 代幣是如何運作的: + +```solidity +pragma solidity ^0.8.19; +abstract contract IERC223Recipient { + function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; +} +contract VeryBasicERC223Token { + event Transfer(address indexed from, address indexed to, uint value, bytes data); + string private _name; + string private _symbol; + uint8 private _decimals; + uint256 private _totalSupply; + mapping(address => uint256) private balances; + function name() public view returns (string memory) { return _name; } + function symbol() public view returns (string memory) { return _symbol; } + function decimals() public view returns (uint8) { return _decimals; } + function totalSupply() public view returns (uint256) { return _totalSupply; } + function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } + function isContract(address account) internal view returns (bool) { + uint256 size; + assembly { size := extcodesize(account) } + return size > 0; + } + function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){ + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); + } + emit Transfer(msg.sender, _to, _value, _data); + return true; + } + function transfer(address _to, uint _value) public returns (bool success){ + bytes memory _empty = hex"00000000"; + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); + } + emit Transfer(msg.sender, _to, _value, _empty); + return true; + } +} +``` + +現在我們希望另一個合約接受 `tokenA` 存款 (假設該 tokenA 是 ERC-223 代幣)。 該合約必須只接受 tokenA 並拒絕其他代幣。 當合約接收 tokenA 時，它必須釋出一個 `Deposit()` 事件並增加 `deposits` 變數的值。 + +程式碼如下: + +```solidity +contract RecipientContract is IERC223Recipient { + event Deposit(address whoSentTheTokens); + uint256 deposits = 0; + address tokenA; // The only token that we want to accept. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + // 在該函數中理解這一點很重要 + // msg.sender 是正在被接收的代幣地址， + // 由於代幣合約在大多數情況下不擁有或發送以太幣，msg.value 始終為 0， + // _from 是代幣傳送的發送者， + // _value 是存入的代幣數量。 + require(msg.sender == tokenA); + deposits += _value; + emit Deposit(_from); + } +} +``` + +## 常見問題 {#faq} + +### 如果我們將一些 tokenB 發送到合約會發生什麽？ {#sending-tokens} + +交易會失敗，並且不會發生代幣傳送。 代幣將返回至發送者的地址。 + +### 我們要如何向該合約存款？ {#contract-deposits} + +調用 ERC-223 代幣的 `transfer(address,uint256)` 或 `transfer(address,uint256,bytes)` 函數，指定 `RecipientContract` 的地址。 + +### 如果我們將 ERC-20 代币傳送到該合約會發生什麽？ {#erc-20-transfers} + +如果 ERC-20 代幣被發送到 `RecipientContract`，這些代幣將被傳送，但該傳送不會被識別 (不會釋出 `Deposit()` 事件，存款值不會發生改變)。 無法過濾或防止不必要的 ERC-20 存款。 + +### 如果我們希望在代幣存款完成後執行一些函數呢？ {#function-execution} + +有多種方法可以做到這一點。 在該範例中我們將繼續使用讓 ERC-223 傳送與以太幣傳送相同的方法: + +```solidity +contract RecipientContract is IERC223Recipient { + event Foo(); + event Bar(uint256 someNumber); + address tokenA; // The only token that we want to accept. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + require(msg.sender == tokenA); + address(this).call(_data); // Handle incoming transaction and perform a subsequent function call. + } + function foo() public + { + emit Foo(); + } + function bar(uint256 _someNumber) public + { + emit Bar(_someNumber); + } +} +``` + +當 `RecipientContract` 接收 ERC-223 代幣時，合約會執行一個編碼為 `_data` 代幣交易參數的函數，與以太坊交易編碼函數調用交易 `data` 相同。 閲讀 [數據欄位](/developers/docs/transactions/#the-data-field) 以獲取更多資訊。 + +在上述範例中，ERC-223 必須被傳送到具有 `transfer(address,uin256,bytes calldata _data)` 函數的 `RecipientContract` 地址。 如果數據參數為 `0xc2985578` (`foo()` 函數的簽名)，則在代幣存款被接收之後，foo() 函數將被調用，並且 Foo() 事件將會釋出。 + +參數也可以編碼在代幣傳送的「data」中，例如我們可以使用「_someNumber」的 12345 值來呼叫 bar() 函數。 在這種情況下，`data` 必須為`0x0423a13200000000000000000000000000000000000000000000000000000000000004d2`，其中 `0x0423a132` 是 `bar(uint256)` 函數的簽名，`00000000000000000000000000000000000000000000000000000000000004d2` 是 12345 作爲 uint256。 + +## 限制 {#limitations} + +雖然 ERC-223 解決了 ERC-20 標準中的一些問題，但它也有自己的限制: + +- 采用與兼容性: ERC-223 目前還未被廣泛采用，這可能會限制其與現存工具和平台的兼容性。 +- 向後兼容性: ERC-223 不向後兼容 ERC-20，這意味著現存的 ERC-20 合約和工具無法再未經修改的情況下與 ERC-223 代幣一起使用。 +- 燃料成本: 與 ERC-20 的交易相比，ERC-223 中的額外檢查與功能可能會導致更高的燃料成本。 + +## 延伸閱讀 {#further-reading} + +- [EIP-223: ERC-223 代幣標準](https://eips.ethereum.org/EIPS/eip-223) +- [初始 ERC-223 提案](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-4626/index.md new file mode 100644 index 00000000000..6a0c98f26b2 --- /dev/null +++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-4626/index.md @@ -0,0 +1,227 @@ +--- +title: "ERC-4626 代幣化金庫標準" +description: "收益金庫的標準。" +lang: zh-tw +--- + +## 介紹 {#introduction} + +ERC-4626 是優化和統一收益金庫技術參數的標準。 它為表示單一底層 ERC-20 代幣的份額的代幣化收益金庫，提供標準應用程式介面。 ERC-4626 還概述了使用 ERC-20 的代幣化金庫的可選擴展，提供存款、提取代幣和讀取餘額的基本功能。 + +**ERC-4626 在收益金庫的作用** + +借貸市場、聚合器和本息代幣可協助使用者透過執行不同的策略，找到加密代幣的最佳收益率。 這些策略在執行時會略有不同，可能會容易出錯或浪費開發資源。 + +收益金庫的 ERC-4626 標準透過創建更一致和健壯的實作模式，無需開發者提供專門的工作，就能減少整合工作量並解鎖在各種應用程式中獲取收益的途徑。 + +[EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) 中完整說明了 ERC-4626 代幣。 + +**非同步金庫擴充功能 (ERC-7540)** + +ERC-4626 針對原子存款和贖回限制進行了優化。 如果達到限制，則無法提交新的存款或贖回。 對於任何以非同步動作或延遲作為與金庫互動的先決條件的智慧合約系統而言，這項限制的成效不彰 (例如：現實世界資產協議、抵押不足的借貸協議、跨鏈借貸協議、流動性質押代幣，或保險安全模組)。 + +ERC-7540 擴展了 ERC-4626 金庫在非同步使用案例中的實用性。 現有的金庫介面 (`deposit`/`withdraw`/`mint`/`redeem`) 已被充分利用來宣告非同步請求。 + +[ERC-7540](https://eips.ethereum.org/EIPS/eip-7540) 中完整說明了 ERC-7540 擴充功能。 + +**多鏈資產金庫擴充功能 (ERC-7575)** + +ERC-4626 不支援的一個缺失使用案例是具有多種資產或介入點的金庫，例如流動資產提供者 (LP) 代幣。 由於 ERC-4626 要求其本身是 ERC-20，這些使用案例通常難以操作或不兼容。 + +ERC-7575 透過將 ERC-20 代幣從 ERC-4626 實現外部化，增加了對多資產金庫的支援。 + +[ERC-7575](https://eips.ethereum.org/EIPS/eip-7575) 中完整說明了 ERC-7575 擴充功能。 + +## 先決條件 {#prerequisites} + +為更清楚瞭解此頁面，建議您先閱讀 [代幣標準](/developers/docs/standards/tokens/) 和 [ERC-20](/developers/docs/standards/tokens/erc-20/) 的相關資訊。 + +## ERC-4626 函式與功能： {#body} + +### 方法 {#methods} + +#### 資產 {#asset} + +```solidity +function asset() public view returns (address assetTokenAddress) +``` + +此函數傳回用於金庫記帳、存款、提款的基礎代幣的地址。 + +#### 總資產 {#totalassets} + +```solidity +function totalAssets() public view returns (uint256) +``` + +此函數傳回金庫持有的相關資產總金額。 + +#### convertToShares {#convertoshares} + +```solidity +function convertToShares(uint256 assets) public view returns (uint256 shares) +``` + +此函式會傳回金庫為所提供的 `assets` 數量所兌換的 `shares` 數量。 + +#### convertToAssets {#convertoassets} + +```solidity +function convertToAssets(uint256 shares) public view returns (uint256 assets) +``` + +此函式會傳回金庫為所提供的 `shares` 數量所兌換的 `assets` 數量。 + +#### maxDeposit {#maxdeposit} + +```solidity +function maxDeposit(address receiver) public view returns (uint256 maxAssets) +``` + +此函式傳回在單次 [`deposit`](#deposit) 呼叫中可存入的底層資產最大數量，並將份額鑄造給 `receiver`。 + +#### previewDeposit {#previewdeposit} + +```solidity +function previewDeposit(uint256 assets) public view returns (uint256 shares) +``` + +該函數允許用戶模擬其在當前區塊的存款效果。 + +#### deposit {#deposit} + +```solidity +function deposit(uint256 assets, address receiver) public returns (uint256 shares) +``` + +此函式會將底層代幣的 `assets` 存入金庫，並將 `shares` 的所有權授予 `receiver`。 + +#### maxMint {#maxmint} + +```solidity +function maxMint(address receiver) public view returns (uint256 maxShares) +``` + +此函式傳回在單次 [`mint`](#mint) 呼叫中可鑄造的最大份額數量，並將份額鑄造給 `receiver`。 + +#### previewMint {#previewmint} + +```solidity +function previewMint(uint256 shares) public view returns (uint256 assets) +``` + +該函數允許用戶在當前區塊模擬其鑄造的效果。 + +#### mint {#mint} + +```solidity +function mint(uint256 shares, address receiver) public returns (uint256 assets) +``` + +此函式透過存入底層代幣的 `assets`，為 `receiver` 精確鑄造 `shares` 數量的金庫份額。 + +#### maxWithdraw {#maxwithdraw} + +```solidity +function maxWithdraw(address owner) public view returns (uint256 maxAssets) +``` + +此函式傳回可透過單次 [`withdraw`](#withdraw) 呼叫，從 `owner` 餘額中提出的最大底層資產數量。 + +#### previewWithdraw {#previewwithdraw} + +```solidity +function previewWithdraw(uint256 assets) public view returns (uint256 shares) +``` + +該函數允許用戶模擬其在當前區塊的提款效果。 + +#### withdraw {#withdraw} + +```solidity +function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) +``` + +此函式會銷毀 `owner` 的 `shares`，並從金庫傳送確切 `assets` 數量的代幣給 `receiver`。 + +#### maxRedeem {#maxredeem} + +```solidity +function maxRedeem(address owner) public view returns (uint256 maxShares) +``` + +此函式傳回可透過 [`redeem`](#redeem) 呼叫，從 `owner` 餘額中贖回的最大份額數量。 + +#### previewRedeem {#previewredeem} + +```solidity +function previewRedeem(uint256 shares) public view returns (uint256 assets) +``` + +該函數允許允許用戶在當前區塊中模擬其贖回效果。 + +#### redeem {#redeem} + +```solidity +function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) +``` + +此函式從 `owner` 贖回特定數量的 `shares`，並從金庫傳送 `assets` 數量的底層代幣給 `receiver`。 + +#### totalSupply {#totalsupply} + +```solidity +function totalSupply() public view returns (uint256) +``` + +返回流通中未贖回的資金庫份額總數。 + +#### balanceOf {#balanceof} + +```solidity +function balanceOf(address owner) public view returns (uint256) +``` + +傳回 `owner` 目前擁有的金庫份額總量。 + +### 介面地圖 {#mapOfTheInterface} + +![ERC-4626 介面地圖](./map-of-erc-4626.png) + +### Events {#events} + +#### 存款事件 + +透過 [`mint`](#mint) 和 [`deposit`](#deposit) 方法將代幣存入金庫時，**必須**發出。 + +```solidity +event Deposit( + address indexed sender, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +其中 `sender` 是將 `assets` 兌換成 `shares`，並將這些 `shares` 轉移給 `owner` 的使用者。 + +#### 提款事件 + +當存款人透過 [`redeem`](#redeem) 或 [`withdraw`](#withdraw) 方法從金庫提出份額時，**必須**發出。 + +```solidity +event Withdraw( + address indexed sender, + address indexed receiver, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +其中 `sender` 是觸發提款，並將 `owner` 擁有的 `shares` 兌換成 `assets` 的使用者。 `receiver` 是收到所提出 `assets` 的使用者。 + +## 延伸閱讀 {#further-reading} + +- [EIP-4626：代幣化金庫標準](https://eips.ethereum.org/EIPS/eip-4626) +- [ERC-4626：GitHub 儲存庫](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) From f57d7253b1bd14961fa2c990b47013351394e0ca Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sun, 15 Feb 2026 16:12:59 +0000 Subject: [PATCH 2/2] fix(i18n): fix zh-tw translation artifacts in part 06 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Fix escaped asterisks (\*\*) in composability and testing docs - Fix 代筆 (writing brush) -> 代幣 (token) typos in ERC-223 - Fix simplified Chinese contamination: 代币->代幣, 什麽->什麼, 采->採, 游戲->遊戲 - Fix garbled frontmatter description in ERC-223 - Fix typo 再未經->在未經 in ERC-223 --- .../developers/docs/scaling/sidechains/index.md | 2 +- .../developers/docs/scaling/validium/index.md | 4 ++-- .../developers/docs/scaling/zk-rollups/index.md | 2 +- .../docs/smart-contracts/composability/index.md | 6 +++--- .../smart-contracts/formal-verification/index.md | 6 +++--- .../docs/smart-contracts/testing/index.md | 6 +++--- .../docs/standards/tokens/erc-223/index.md | 14 +++++++------- 7 files changed, 20 insertions(+), 20 deletions(-) diff --git a/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md b/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md index b3071b911fa..cc20628948f 100644 --- a/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md +++ b/public/content/translations/zh-tw/developers/docs/scaling/sidechains/index.md @@ -45,7 +45,7 @@ sidebarDepth: 3 爲了使一條獨立區塊鏈成爲以太坊主網的側鏈，區塊鏈需要支持在它與以太坊主網之間傳送資產。 這種與以太坊的互操作性是使用區塊鏈跨鏈橋實現的。 [跨鏈橋](/bridges/) 使用部署在以太坊主網和側鏈上的智能合約，來控制兩者之間的資金橋接。 -儘管跨鏈橋可以幫助使用者在以太坊和側鏈之間傳送資金，但實體資產不會在兩條鏈之間移動。 相反，通常采用與鑄造和銷毀相關的機制跨鏈傳送價值。 更多關於 [跨鏈橋的運作方式](/developers/docs/bridges/#how-do-bridges-work)。 +儘管跨鏈橋可以幫助使用者在以太坊和側鏈之間傳送資金，但實體資產不會在兩條鏈之間移動。 相反，通常採用與鑄造和銷毀相關的機制跨鏈傳送價值。 更多關於 [跨鏈橋的運作方式](/developers/docs/bridges/#how-do-bridges-work)。 ## 側鏈的優缺點 {#pros-and-cons-of-sidechains} diff --git a/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md b/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md index f1982553064..32295321c7d 100644 --- a/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md +++ b/public/content/translations/zh-tw/developers/docs/scaling/validium/index.md @@ -75,7 +75,7 @@ Validium 的狀態被雜處理湊為默克爾樹，其根儲存在以太坊的 如前所述，Validium 利用一個鏈下資料可用性模型，營運者會將所有交易資料儲存在其中，而不是以太坊主網。 Validium 的鏈上資料足跡較低，這提升了可擴展性（吞吐量不受以太坊的資料處理能力限制），並降低了使用者費用（在鏈上發佈資料的成本降低）。 -然而，鏈下資料可用性導致了一個問題：建立或驗證默克爾證明所需的資料可能不可用。 這意味著，如果營運者采取惡意行爲，使用者就可能無法從鏈上合約中提取資金。 +然而，鏈下資料可用性導致了一個問題：建立或驗證默克爾證明所需的資料可能不可用。 這意味著，如果營運者採取惡意行爲，使用者就可能無法從鏈上合約中提取資金。 各種 Validium 解決方案試圖透過將狀態資料的儲存去中心化來解決此問題。 這涉及迫使區塊生產者將底層資料發送至「資料可用性管理者」，由他們負責儲存鏈下資料並在使用者請求時提供給使用者。 @@ -139,7 +139,7 @@ Validium 透過將所有交易資料保存在鏈下，並在轉送狀態更新 | 提高使用者的資本效率（將資金提取回以太坊時不會出現延遲） | 對通用計算/智慧型合約的支持有限；開發需要使用專業化語言。 | | 對高價值應用程式中的詐欺證明型系統所面臨的某些經濟攻擊有高抵抗性。 | 生成零知識證明需要强大的算力；對於低吞吐量的應用程式不具有成本效益。 | | 透過不將回呼資料發佈到以太坊主網來降低使用者的燃料費用。 | 較慢的主觀最終性時間（生成零知識證明需要 10 - 30 分鐘），但完全最終性會快一些，因爲沒有爭議時間延遲。 | -| 這適用於特定用例，例如優先考慮交易隱私和可擴展性的交易或區塊鏈游戲。 | 可能會阻止使用者提取資金，因爲生成所有權的默克爾證明需要鏈下資料始終可用。 | +| 這適用於特定用例，例如優先考慮交易隱私和可擴展性的交易或區塊鏈遊戲。 | 可能會阻止使用者提取資金，因爲生成所有權的默克爾證明需要鏈下資料始終可用。 | | 鏈下資料可用性提升了吞吐量並增加了可擴展性。 | 安全模型依賴於信任假設和加密經濟激勵措施，與完全依賴加密安全機制的零知識卷軸不同。 | ### 使用 Validium/Volition {#use-validium-and-volitions} diff --git a/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md index 03d9cf14737..a6af801ff34 100644 --- a/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/zh-tw/developers/docs/scaling/zk-rollups/index.md @@ -90,7 +90,7 @@ SNARK（簡潔非互動式知識論證）和 STARK（可擴展透明知識論證 有些 ZK-rollups 會嘗試透過 [多方運算儀式 (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) 來解決此問題，其中會涉及受信任的個人，來為 ZK-SNARK 電路產生公開參數。 每一方都貢獻一些隨機性（稱為「有毒廢棄物」）來構建公共參考串，而且必須立即將其銷毀。 -使用可信的設定，因爲這會提高公共參考串設定的安全性。 只要誠實的參與者銷毀其輸入，ZK-SNARK 系統的安全性就會得到保證。 這種方法仍然需要信任相關人員刪除他們采樣的隨機性，並且不會破壞系統的安全保證。 +使用可信的設定，因爲這會提高公共參考串設定的安全性。 只要誠實的參與者銷毀其輸入，ZK-SNARK 系統的安全性就會得到保證。 這種方法仍然需要信任相關人員刪除他們採樣的隨機性，並且不會破壞系統的安全保證。 抛開信任假設不談，ZK-SNARK 因其更小的證明大小和恆定時間驗證而受到歡迎。 由於執行零知識證明卷軸的大部分成本用於一層網路上的證明驗證，因此二層網路使用 ZK-SNARK 來產生可在主網上快速、便宜地進行驗證的證明。 diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md index 2a53ed9b4ef..e0e5bf90843 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/composability/index.md @@ -19,11 +19,11 @@ incomplete: true 以太坊上的智慧型合約就如同公開的應用程式介面 (API)，所有人都可以與合約互動，或把它整合到去中心化應用程式獲得新增的功能。 智慧型合約的可組合性通常遵循三個原則：模塊化、自主性和可發現性。 -\*\*1. **模組化**：這是指個別元件執行特定任務的能力。 在以太坊，每個智慧型合約都有特定的使用案例（如 Uniswap 範例所顯示）。 +**1. 模組化**：這是指個別元件執行特定任務的能力。 在以太坊，每個智慧型合約都有特定的使用案例（如 Uniswap 範例所顯示）。 -\*\*2. **自主性**：可組合的元件必須能夠獨立運作。 以太坊上的每一個智慧型合約都能自我執行，且可以在不依賴系統其他部分的情況下運作。 +**2. 自主性**：可組合的元件必須能夠獨立運作。 以太坊上的每一個智慧型合約都能自我執行，且可以在不依賴系統其他部分的情況下運作。 -\*\*3. **可發現性**：如果外部合約或軟體程式庫不是公開可用的，開發人員就無法呼叫它們或將其整合到應用程式中。 智慧型合約被設計成開放原始碼，任何人都可以調用智慧型合約或分叉一個程式碼庫。 +**3. 可發現性**：如果外部合約或軟體程式庫不是公開可用的，開發人員就無法呼叫它們或將其整合到應用程式中。 智慧型合約被設計成開放原始碼，任何人都可以調用智慧型合約或分叉一個程式碼庫。 ## 可組合性的優點 {#benefits-of-composability} diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md index 751d462cd3f..bb7546344e4 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/formal-verification/index.md @@ -30,9 +30,9 @@ lang: zh-tw 低階模型被認為是理想的，因為它們代表了智能合約在以太坊執行環境 (即 [EVM](/developers/docs/evm/)) 中的實際執行。 低階模型建立技術對於在智慧型合約中建立關鍵的安全屬性和偵測潛在漏洞尤其有用。 -### 什麽是形式化規範？ {#what-is-a-formal-specification} +### 什麼是形式化規範？ {#what-is-a-formal-specification} -規範不過是特定系統必須滿足的技術要求。 在編程中，規範代表程式執行的總體思路（即程式應該做什麽）。 +規範不過是特定系統必須滿足的技術要求。 在編程中，規範代表程式執行的總體思路（即程式應該做什麼）。 在智能合約的脈絡中，形式化規範指的是「屬性」—也就是合約必須滿足之條件的形式化描述。 這樣的屬性被描述爲「不變量」，並代表了關於合約執行的邏輯斷言，該斷言在任何情況下都必須為 true，沒有例外。 @@ -46,7 +46,7 @@ lang: zh-tw 形式化規範是利用 [程式邏輯](https://en.wikipedia.org/wiki/Logic_programming) 的元素推導而來，程式邏輯可讓人對程式的屬性進行形式化推理。 程式邏輯採用形式化規則來（用數學語言）表達程序的預期行為。 建立形式化規範時，會用到各種程式邏輯，包括 [可達性邏輯](https://en.wikipedia.org/wiki/Reachability_problem)、[時序邏輯](https://en.wikipedia.org/wiki/Temporal_logic) 及 [霍爾邏輯](https://en.wikipedia.org/wiki/Hoare_logic)。 -智能合約的形式化規範可大致分為**高階**或**低階**規範。 無論規範屬於什麽類別，都必須充分且明確地描述所分析之系統的屬性。 +智能合約的形式化規範可大致分為**高階**或**低階**規範。 無論規範屬於什麼類別，都必須充分且明確地描述所分析之系統的屬性。 ### 高階規範 {#high-level-specifications} diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md index e140005feef..6e28faaf6ef 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/testing/index.md @@ -176,11 +176,11 @@ Solidity 智慧型合約的單元測試框架有不同的語言（大多數為 J 模糊測試對於評估智慧型合約輸入驗證機制很有用，因爲對意外輸入的不正確處理可能會導致意外執行並產生危險的影響。 這種基於屬性的測試形式可能非常理想，原因有多種： -1. \*\*編寫涵蓋多種情境的測試案例很困難。\*\*屬性測試只需要你定義一個行為和一個用於測試該行為的資料範圍——程式會根據定義的屬性自動產生測試案例。 +1. **編寫涵蓋多種情境的測試案例很困難。**屬性測試只需要你定義一個行為和一個用於測試該行為的資料範圍——程式會根據定義的屬性自動產生測試案例。 -2. \*\*你的測試套件可能無法充分涵蓋程式中的所有可能路徑。\*\*即使有 100% 的覆蓋率，也可能錯過邊緣案例。 +2. **你的測試套件可能無法充分涵蓋程式中的所有可能路徑。**即使有 100% 的覆蓋率，也可能錯過邊緣案例。 -3. \*\*單元測試證明合約對樣本資料能正確執行，但合約對樣本外的輸入是否能正確執行仍是未知數。\*\*屬性測試會使用給定輸入值的多種變體來執行目標合約，以找出導致斷言失敗的執行追蹤。 因此，屬性測試為合約在廣泛的輸入資料類別下正確執行提供了更多的保證。 +3. **單元測試證明合約對樣本資料能正確執行，但合約對樣本外的輸入是否能正確執行仍是未知數。**屬性測試會使用給定輸入值的多種變體來執行目標合約，以找出導致斷言失敗的執行追蹤。 因此，屬性測試為合約在廣泛的輸入資料類別下正確執行提供了更多的保證。 ### 執行智能合約屬性測試的指南 {#running-property-based-tests} diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md index 1d175b234df..d17cb1151c8 100644 --- a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-223/index.md @@ -1,6 +1,6 @@ --- title: "ERC-223 代幣標準" -description: "關於 ERC-223 同質性代筆標準的概述，包含它的運作方式以及與 ERC-20 的對代幣" +description: "關於 ERC-223 同質性代幣標準的概述，包含它的運作方式以及與 ERC-20 的比較" lang: zh-tw --- @@ -8,7 +8,7 @@ lang: zh-tw ### 什麼是 ERC-223？ {#what-is-erc223} -ERC-223 是一種同質性代筆標準，與 ERC-20 標準類似。 主要的區別在於 ERC-223 不但定義了代幣應用程式介面，還定義了從發送者向接收者傳送代幣的邏輯。 它引入了一個交流模型，使代幣傳送能夠在接收者處進行處理。 +ERC-223 是一種同質性代幣標準，與 ERC-20 標準類似。 主要的區別在於 ERC-223 不但定義了代幣應用程式介面，還定義了從發送者向接收者傳送代幣的邏輯。 它引入了一個交流模型，使代幣傳送能夠在接收者處進行處理。 ### 與 ERC-20 的區別 {#erc20-differences} @@ -55,7 +55,7 @@ function transfer(address _to, uint256 _value, bytes calldata _data) public retu function tokenReceived(address _from, uint _value, bytes calldata _data) ``` -如果 ERC-223 代筆被發送到沒有實現 `tokenReceived(..)` 函數的合約，該傳送則必定會失效，並且代幣不會從發送者的餘額中移動。 +如果 ERC-223 代幣被發送到沒有實現 `tokenReceived(..)` 函數的合約，該傳送則必定會失效，並且代幣不會從發送者的餘額中移動。 ### Events {#events} @@ -140,7 +140,7 @@ contract RecipientContract is IERC223Recipient { ## 常見問題 {#faq} -### 如果我們將一些 tokenB 發送到合約會發生什麽？ {#sending-tokens} +### 如果我們將一些 tokenB 發送到合約會發生什麼？ {#sending-tokens} 交易會失敗，並且不會發生代幣傳送。 代幣將返回至發送者的地址。 @@ -148,7 +148,7 @@ contract RecipientContract is IERC223Recipient { 調用 ERC-223 代幣的 `transfer(address,uint256)` 或 `transfer(address,uint256,bytes)` 函數，指定 `RecipientContract` 的地址。 -### 如果我們將 ERC-20 代币傳送到該合約會發生什麽？ {#erc-20-transfers} +### 如果我們將 ERC-20 代幣傳送到該合約會發生什麼？ {#erc-20-transfers} 如果 ERC-20 代幣被發送到 `RecipientContract`，這些代幣將被傳送，但該傳送不會被識別 (不會釋出 `Deposit()` 事件，存款值不會發生改變)。 無法過濾或防止不必要的 ERC-20 存款。 @@ -187,8 +187,8 @@ contract RecipientContract is IERC223Recipient { 雖然 ERC-223 解決了 ERC-20 標準中的一些問題，但它也有自己的限制: -- 采用與兼容性: ERC-223 目前還未被廣泛采用，這可能會限制其與現存工具和平台的兼容性。 -- 向後兼容性: ERC-223 不向後兼容 ERC-20，這意味著現存的 ERC-20 合約和工具無法再未經修改的情況下與 ERC-223 代幣一起使用。 +- 採用與兼容性: ERC-223 目前還未被廣泛採用，這可能會限制其與現存工具和平台的兼容性。 +- 向後兼容性: ERC-223 不向後兼容 ERC-20，這意味著現存的 ERC-20 合約和工具無法在未經修改的情況下與 ERC-223 代幣一起使用。 - 燃料成本: 與 ERC-20 的交易相比，ERC-223 中的額外檢查與功能可能會導致更高的燃料成本。 ## 延伸閱讀 {#further-reading}