From e0cae4c94fc20f66b826b9da62d5bddb7bca6d95 Mon Sep 17 00:00:00 2001
From: wackerow <54227730+wackerow@users.noreply.github.com>
Date: Thu, 5 Feb 2026 09:11:51 -0500
Subject: [PATCH 1/7] i18n(zh-tw): Crowdin translations
---
.../content/translations/zh-tw/about/index.md | 65 +-
.../translations/zh-tw/ai-agents/index.md | 143 ++
.../translations/zh-tw/bridges/index.md | 65 +-
.../zh-tw/community/code-of-conduct/index.md | 78 +-
.../community/events/organizing/index.md | 221 ++
.../zh-tw/community/get-involved/index.md | 139 +-
.../zh-tw/community/grants/index.md | 69 +-
.../community/language-resources/index.md | 160 +-
.../zh-tw/community/online/index.md | 42 +-
.../zh-tw/community/research/index.md | 4 +-
.../zh-tw/community/support/index.md | 40 +-
.../adding-desci-projects/index.md | 28 +-
.../adding-developer-tools/index.md | 12 +-
.../contributing/adding-exchanges/index.md | 10 +-
.../adding-glossary-terms/index.md | 8 +-
.../contributing/adding-layer-2s/index.md | 28 +-
.../contributing/adding-products/index.md | 58 +-
.../contributing/adding-resources/index.md | 54 +
.../adding-staking-products/index.md | 76 +-
.../contributing/adding-wallets/index.md | 80 +-
.../contributing/content-resources/index.md | 10 +-
.../contributing/design-principles/index.md | 72 +-
.../design/adding-design-resources/index.md | 6 +-
.../zh-tw/contributing/design/index.md | 36 +-
.../translations/zh-tw/contributing/index.md | 95 +-
.../zh-tw/contributing/quizzes/index.md | 14 +-
.../translation-program/faq/index.md | 36 +-
.../how-to-translate/index.md | 38 +-
.../contributing/translation-program/index.md | 57 +-
.../mission-and-vision/index.md | 2 +-
.../translation-program/playbook/index.md | 317 +++
.../translation-program/resources/index.md | 35 +-
.../translatathon/details/index.md | 90 +
.../translatathon/index.md | 100 +
.../translators-guide/index.md | 94 +-
.../content/translations/zh-tw/dao/index.md | 106 +-
.../zh-tw/decentralized-identity/index.md | 133 +-
.../content/translations/zh-tw/defi/index.md | 103 +-
.../content/translations/zh-tw/desci/index.md | 130 +-
.../zh-tw/developers/docs/accounts/index.md | 57 +-
.../developers/docs/apis/backend/index.md | 120 +-
.../developers/docs/apis/javascript/index.md | 127 +-
.../developers/docs/apis/json-rpc/index.md | 814 ++++---
.../zh-tw/developers/docs/blocks/index.md | 89 +-
.../zh-tw/developers/docs/bridges/index.md | 138 ++
.../docs/consensus-mechanisms/index.md | 40 +-
.../docs/consensus-mechanisms/poa/index.md | 1 +
.../pos/attack-and-defense/index.md | 88 +-
.../pos/attestations/index.md | 56 +-
.../pos/block-proposal/index.md | 22 +-
.../consensus-mechanisms/pos/faqs/index.md | 42 +-
.../consensus-mechanisms/pos/gasper/index.md | 24 +-
.../docs/consensus-mechanisms/pos/index.md | 50 +-
.../consensus-mechanisms/pos/keys/index.md | 42 +-
.../pos/pos-vs-pow/index.md | 18 +-
.../pos/rewards-and-penalties/index.md | 57 +-
.../pos/weak-subjectivity/index.md | 14 +-
.../pos/withdrawal-credentials/index.md | 64 +
.../docs/consensus-mechanisms/pow/index.md | 54 +-
.../consensus-mechanisms/pow/mining/index.md | 38 +-
.../dagger-hashimoto/index.md | 102 +-
.../mining/mining-algorithms/ethash/index.md | 346 +--
.../pow/mining/mining-algorithms/index.md | 22 +-
.../zh-tw/developers/docs/dapps/index.md | 82 +-
.../block-explorers/index.md | 56 +-
.../docs/data-and-analytics/index.md | 59 +-
.../index.md | 118 +
.../docs/data-availability/index.md | 84 +
.../data-structures-and-encoding/index.md | 20 +-
.../patricia-merkle-trie/index.md | 195 +-
.../data-structures-and-encoding/rlp/index.md | 50 +-
.../data-structures-and-encoding/ssz/index.md | 58 +-
.../web3-secret-storage/index.md | 195 ++
.../dex-design-best-practice/index.md | 220 ++
.../heuristics-for-web3/index.md | 138 ++
.../developers/docs/design-and-ux/index.md | 86 +
.../docs/development-networks/index.md | 43 +-
.../developers/docs/ethereum-stack/index.md | 36 +-
.../zh-tw/developers/docs/evm/index.md | 64 +-
.../developers/docs/evm/opcodes/index.md | 329 +--
.../zh-tw/developers/docs/frameworks/index.md | 102 +-
.../zh-tw/developers/docs/gas/index.md | 127 +-
.../zh-tw/developers/docs/ides/index.md | 44 +-
.../zh-tw/developers/docs/index.md | 6 +-
.../developers/docs/intro-to-ether/index.md | 44 +-
.../docs/intro-to-ethereum/index.md | 58 +-
.../zh-tw/developers/docs/mev/index.md | 221 ++
.../developers/docs/networking-layer/index.md | 82 +-
.../network-addresses/index.md | 22 +-
.../networking-layer/portal-network/index.md | 36 +-
.../zh-tw/developers/docs/networks/index.md | 171 +-
.../nodes-and-clients/archive-nodes/index.md | 35 +-
.../docs/nodes-and-clients/bootnodes/index.md | 16 +-
.../client-diversity/index.md | 107 +-
.../docs/nodes-and-clients/index.md | 160 +-
.../nodes-and-clients/light-clients/index.md | 22 +-
.../node-architecture/index.md | 42 +-
.../nodes-as-a-service/index.md | 108 +-
.../nodes-and-clients/run-a-node/index.md | 218 +-
.../zh-tw/developers/docs/oracles/index.md | 433 ++++
.../docs/programming-languages/dart/index.md | 35 +-
.../programming-languages/delphi/index.md | 44 +-
.../programming-languages/dot-net/index.md | 85 +-
.../programming-languages/golang/index.md | 90 +-
.../docs/programming-languages/index.md | 35 +-
.../docs/programming-languages/java/index.md | 57 +-
.../programming-languages/javascript/index.md | 45 +-
.../programming-languages/python/index.md | 95 +-
.../docs/programming-languages/ruby/index.md | 52 +-
.../docs/programming-languages/rust/index.md | 56 +-
.../zh-tw/developers/docs/scaling/index.md | 70 +-
.../docs/scaling/optimistic-rollups/index.md | 144 +-
.../developers/docs/scaling/plasma/index.md | 97 +-
.../docs/scaling/sidechains/index.md | 32 +-
.../docs/scaling/state-channels/index.md | 261 +++
.../developers/docs/scaling/validium/index.md | 91 +-
.../docs/scaling/zk-rollups/index.md | 140 +-
.../docs/smart-contracts/anatomy/index.md | 391 ++--
.../docs/smart-contracts/compiling/index.md | 24 +-
.../smart-contracts/composability/index.md | 44 +-
.../docs/smart-contracts/deploying/index.md | 58 +-
.../formal-verification/index.md | 145 +-
.../developers/docs/smart-contracts/index.md | 66 +-
.../docs/smart-contracts/languages/index.md | 172 +-
.../docs/smart-contracts/libraries/index.md | 58 +-
.../docs/smart-contracts/naming/index.md | 101 +
.../docs/smart-contracts/security/index.md | 232 +-
.../docs/smart-contracts/testing/index.md | 204 +-
.../docs/smart-contracts/upgrading/index.md | 64 +-
.../docs/smart-contracts/verifying/index.md | 54 +-
.../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 ++
.../docs/standards/tokens/erc-721/index.md | 255 +++
.../docs/standards/tokens/erc-777/index.md | 46 +
.../developers/docs/standards/tokens/index.md | 41 +
.../zh-tw/developers/docs/storage/index.md | 116 +-
.../developers/docs/transactions/index.md | 120 +-
.../developers/docs/web2-vs-web3/index.md | 18 +-
.../index.md | 300 +++
.../tutorials/all-you-can-cache/index.md | 864 ++++++++
.../developers/tutorials/app-plasma/index.md | 1255 +++++++++++
.../index.md | 131 ++
.../index.md | 585 +++++
.../index.md | 95 +
.../index.md | 363 +++
.../index.md | 144 ++
.../index.md | 123 +
.../erc-721-vyper-annotated-code/index.md | 645 ++++++
.../tutorials/erc20-annotated-code/index.md | 803 +++++++
.../erc20-with-safety-rails/index.md | 217 ++
.../tutorials/ethereum-for-web2-auth/index.md | 886 ++++++++
.../index.md | 149 ++
.../index.md | 102 +
.../index.md | 1539 +++++++++++++
.../hello-world-smart-contract/index.md | 359 +++
.../index.md | 145 ++
.../tutorials/how-to-mint-an-nft/index.md | 329 +++
.../index.md | 102 +
.../index.md | 702 ++++++
.../index.md | 515 +++++
.../index.md | 233 ++
.../how-to-use-tellor-as-your-oracle/index.md | 81 +
.../how-to-view-nft-in-metamask/index.md | 33 +
.../how-to-write-and-deploy-an-nft/index.md | 380 ++++
.../index.md | 172 ++
.../tutorials/ipfs-decentralized-ui/index.md | 73 +
.../index.md | 104 +
.../index.md | 269 +++
.../logging-events-smart-contracts/index.md | 62 +
.../index.md | 244 ++
.../index.md | 151 ++
.../developers/tutorials/nft-minter/index.md | 866 ++++++++
.../index.md | 1331 +++++++++++
.../reverse-engineering-a-contract/index.md | 743 +++++++
.../tutorials/run-node-raspberry-pi/index.md | 184 ++
.../tutorials/scam-token-tricks/index.md | 470 ++++
.../tutorials/secret-state/index.md | 733 ++++++
.../secure-development-workflow/index.md | 52 +
.../tutorials/send-token-ethersjs/index.md | 210 ++
.../index.md | 208 ++
.../tutorials/server-components/index.md | 295 +++
.../index.md | 92 +
.../developers/tutorials/short-abi/index.md | 585 +++++
.../index.md | 91 +
.../tutorials/stealth-addr/index.md | 436 ++++
.../index.md | 307 +++
.../token-integration-checklist/index.md | 80 +
.../index.md | 314 +++
.../index.md | 177 ++
.../uniswap-v2-annotated-code/index.md | 1970 +++++++++++++++++
.../tutorials/using-websockets/index.md | 245 ++
.../index.md | 293 +++
.../index.md | 204 ++
.../index.md | 199 ++
.../tutorials/yellow-paper-evm/index.md | 278 +++
.../content/translations/zh-tw/eips/index.md | 43 +-
.../zh-tw/energy-consumption/index.md | 65 +-
.../translations/zh-tw/eth/supply/index.md | 80 +
.../zh-tw/ethereum-forks/index.md | 355 +--
.../translations/zh-tw/foundation/index.md | 39 +-
.../translations/zh-tw/gaming/index.md | 70 +
.../translations/zh-tw/glossary/index.md | 16 +-
.../translations/zh-tw/governance/index.md | 88 +-
.../index.md | 19 +-
.../guides/how-to-id-scam-tokens/index.md | 48 +-
.../how-to-revoke-token-access/index.md | 20 +-
.../zh-tw/guides/how-to-swap-tokens/index.md | 24 +-
.../zh-tw/guides/how-to-use-a-bridge/index.md | 27 +-
.../zh-tw/guides/how-to-use-a-wallet/index.md | 19 +-
.../translations/zh-tw/guides/index.md | 10 +-
.../content/translations/zh-tw/nft/index.md | 65 +-
.../translations/zh-tw/payments/index.md | 207 ++
.../zh-tw/prediction-markets/index.md | 84 +
.../translations/zh-tw/privacy/index.md | 97 +
.../zh-tw/real-world-assets/index.md | 93 +
.../content/translations/zh-tw/refi/index.md | 34 +-
.../translations/zh-tw/restaking/index.md | 188 ++
.../roadmap/account-abstraction/index.md | 111 +-
.../zh-tw/roadmap/beacon-chain/index.md | 27 +-
.../zh-tw/roadmap/danksharding/index.md | 38 +-
.../zh-tw/roadmap/dencun/index.md | 4 +-
.../zh-tw/roadmap/fusaka/index.md | 300 +++
.../zh-tw/roadmap/fusaka/peerdas/index.md | 88 +
.../zh-tw/roadmap/future-proofing/index.md | 41 +-
.../translations/zh-tw/roadmap/merge/index.md | 92 +-
.../zh-tw/roadmap/merge/issuance/index.md | 118 +-
.../translations/zh-tw/roadmap/pbs/index.md | 33 +-
.../zh-tw/roadmap/pectra/7702/index.md | 149 ++
.../zh-tw/roadmap/pectra/index.md | 127 ++
.../zh-tw/roadmap/pectra/maxeb/index.md | 204 ++
.../zh-tw/roadmap/scaling/index.md | 24 +-
.../roadmap/secret-leader-election/index.md | 14 +-
.../zh-tw/roadmap/security/index.md | 34 +-
.../roadmap/single-slot-finality/index.md | 41 +-
.../zh-tw/roadmap/statelessness/index.md | 49 +-
.../zh-tw/roadmap/user-experience/index.md | 14 +-
.../zh-tw/roadmap/verkle-trees/index.md | 34 +-
.../translations/zh-tw/security/index.md | 153 +-
.../zh-tw/smart-contracts/index.md | 40 +-
.../zh-tw/social-networks/index.md | 92 +-
.../translations/zh-tw/staking/dvt/index.md | 54 +-
.../translations/zh-tw/staking/pools/index.md | 46 +-
.../translations/zh-tw/staking/saas/index.md | 42 +-
.../translations/zh-tw/staking/solo/index.md | 140 +-
.../zh-tw/staking/withdrawals/index.md | 104 +-
.../content/translations/zh-tw/web3/index.md | 80 +-
.../translations/zh-tw/what-are-apps/index.md | 81 +
.../translations/zh-tw/whitepaper/index.md | 270 +--
.../translations/zh-tw/wrapped-eth/index.md | 70 +
.../zh-tw/zero-knowledge-proofs/index.md | 144 +-
src/intl/zh-tw/common.json | 8 +-
src/intl/zh-tw/glossary-tooltip.json | 10 +-
src/intl/zh-tw/glossary.json | 30 +-
src/intl/zh-tw/learn-quizzes.json | 87 +-
src/intl/zh-tw/page-10-year-anniversary.json | 131 ++
src/intl/zh-tw/page-about.json | 24 +-
src/intl/zh-tw/page-apps.json | 346 +--
src/intl/zh-tw/page-bug-bounty.json | 69 +-
src/intl/zh-tw/page-collectibles.json | 67 +
src/intl/zh-tw/page-community-events.json | 1 -
src/intl/zh-tw/page-community.json | 5 +-
src/intl/zh-tw/page-developers-docs.json | 22 +-
src/intl/zh-tw/page-developers-index.json | 95 +-
.../zh-tw/page-developers-learning-tools.json | 6 +-
.../page-developers-local-environment.json | 4 +-
src/intl/zh-tw/page-developers-tutorials.json | 20 +-
src/intl/zh-tw/page-energy-consumption.json | 21 +
...thereum-history-founder-and-ownership.json | 65 +
src/intl/zh-tw/page-ethereum-vs-bitcoin.json | 101 +
src/intl/zh-tw/page-founders.json | 65 +
src/intl/zh-tw/page-gas.json | 4 +-
src/intl/zh-tw/page-history.json | 7 +
src/intl/zh-tw/page-index.json | 2 +-
src/intl/zh-tw/page-layer-2-learn.json | 55 +
src/intl/zh-tw/page-layer-2-networks.json | 85 +
src/intl/zh-tw/page-layer-2.json | 61 +
src/intl/zh-tw/page-learn.json | 13 +-
src/intl/zh-tw/page-resources.json | 97 +
src/intl/zh-tw/page-roadmap-vision.json | 4 +-
src/intl/zh-tw/page-roadmap.json | 102 +
src/intl/zh-tw/page-stablecoins.json | 71 +-
.../zh-tw/page-staking-deposit-contract.json | 2 +-
src/intl/zh-tw/page-staking.json | 22 +-
src/intl/zh-tw/page-start.json | 38 +
.../zh-tw/page-trillion-dollar-security.json | 196 ++
.../zh-tw/page-upgrades-get-involved.json | 4 +-
src/intl/zh-tw/page-upgrades-index.json | 42 +-
src/intl/zh-tw/page-wallets-find-wallet.json | 7 +-
src/intl/zh-tw/page-what-is-ether.json | 100 +
src/intl/zh-tw/page-what-is-ethereum.json | 309 +--
.../page-what-is-the-ethereum-network.json | 89 +
src/intl/zh-tw/table.json | 4 +-
src/intl/zh-tw/template-usecase.json | 10 +-
297 files changed, 36961 insertions(+), 6431 deletions(-)
create mode 100644 public/content/translations/zh-tw/ai-agents/index.md
create mode 100644 public/content/translations/zh-tw/community/events/organizing/index.md
create mode 100644 public/content/translations/zh-tw/contributing/adding-resources/index.md
create mode 100644 public/content/translations/zh-tw/contributing/translation-program/playbook/index.md
create mode 100644 public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md
create mode 100644 public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/bridges/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/data-availability/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/design-and-ux/dex-design-best-practice/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/design-and-ux/heuristics-for-web3/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/design-and-ux/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/mev/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/oracles/index.md
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
create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/erc-721/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/erc-777/index.md
create mode 100644 public/content/translations/zh-tw/developers/docs/standards/tokens/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/deploying-your-first-smart-contract/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/eip-1271-smart-contract-signatures/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract-fullstack/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-implement-an-erc721-market/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-mint-an-nft/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-view-nft-in-metamask/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/how-to-write-and-deploy-an-nft/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/interact-with-other-contracts-from-solidity/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/logging-events-smart-contracts/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/nft-minter/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/server-components/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/using-websockets/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/waffle-test-simple-smart-contract/index.md
create mode 100644 public/content/translations/zh-tw/developers/tutorials/yellow-paper-evm/index.md
create mode 100644 public/content/translations/zh-tw/eth/supply/index.md
create mode 100644 public/content/translations/zh-tw/gaming/index.md
create mode 100644 public/content/translations/zh-tw/payments/index.md
create mode 100644 public/content/translations/zh-tw/prediction-markets/index.md
create mode 100644 public/content/translations/zh-tw/privacy/index.md
create mode 100644 public/content/translations/zh-tw/real-world-assets/index.md
create mode 100644 public/content/translations/zh-tw/restaking/index.md
create mode 100644 public/content/translations/zh-tw/roadmap/fusaka/index.md
create mode 100644 public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md
create mode 100644 public/content/translations/zh-tw/roadmap/pectra/7702/index.md
create mode 100644 public/content/translations/zh-tw/roadmap/pectra/index.md
create mode 100644 public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md
create mode 100644 public/content/translations/zh-tw/what-are-apps/index.md
create mode 100644 public/content/translations/zh-tw/wrapped-eth/index.md
create mode 100644 src/intl/zh-tw/page-10-year-anniversary.json
create mode 100644 src/intl/zh-tw/page-collectibles.json
create mode 100644 src/intl/zh-tw/page-energy-consumption.json
create mode 100644 src/intl/zh-tw/page-ethereum-history-founder-and-ownership.json
create mode 100644 src/intl/zh-tw/page-ethereum-vs-bitcoin.json
create mode 100644 src/intl/zh-tw/page-founders.json
create mode 100644 src/intl/zh-tw/page-history.json
create mode 100644 src/intl/zh-tw/page-layer-2-learn.json
create mode 100644 src/intl/zh-tw/page-layer-2-networks.json
create mode 100644 src/intl/zh-tw/page-layer-2.json
create mode 100644 src/intl/zh-tw/page-resources.json
create mode 100644 src/intl/zh-tw/page-roadmap.json
create mode 100644 src/intl/zh-tw/page-start.json
create mode 100644 src/intl/zh-tw/page-trillion-dollar-security.json
create mode 100644 src/intl/zh-tw/page-what-is-ether.json
create mode 100644 src/intl/zh-tw/page-what-is-the-ethereum-network.json
diff --git a/public/content/translations/zh-tw/about/index.md b/public/content/translations/zh-tw/about/index.md
index e6a5e19c30a..d592a5a7b42 100644
--- a/public/content/translations/zh-tw/about/index.md
+++ b/public/content/translations/zh-tw/about/index.md
@@ -8,9 +8,9 @@ lang: zh-tw
ethereum.org 是一個屬於以太坊社群的開放原始碼資源,所有人都可貢獻一己之力。 我們有一個小型核心團隊致力於維護和開發網站,也有全球數千名社群成員做出貢獻。
-**Ethereum.org 的人員絕不會主動聯絡你。 不要回應。**
+**ethereum.org 的人員絕不會主動聯絡您。 請勿回應。**
-## 有關名字的說明 {#a-note-on-names}
+## 關於名稱的注意事項 {#a-note-on-names}
人們常常混淆以太坊領域的名稱,這可能會導致人們難以理解以太坊的運作方式。 這裡有簡明解釋作釐清:
@@ -18,23 +18,23 @@ ethereum.org 是一個屬於以太坊社群的開放原始碼資源,所有人
以太坊是一個公共網路、區塊鏈和開放原始碼協議 — 由數以萬計的開發者、節點營運者、以太幣持有者和使用者運營、治理、管理和擁有組成的全球社群。
-[有關以太坊的更多資訊](/what-is-ethereum/)
+[更多關於以太坊的資訊](/what-is-ethereum/)
-[有關以太坊治理的更多資訊](/governance/)
+[有關以太坊管理體系的更多資訊](/管理體系/)
### 以太幣 (ETH) {#ether-or-eth}
以太幣(其代碼也稱為 ETH)是在以太坊上交易的原生貨幣。 使用以太坊網路需要 ETH 來支付費用(以交易費的形式)。 透過質押 ETH,也可用於保護以太坊網路安全。 當人們談論以太坊的價格時,他們指的是 ETH 這種資產。
-[有關以太幣的更多資訊](/what-is-ether/)
+[更多關於 ETH 的資訊](/what-is-ether/)
-[有關質押以太幣的更多資訊](/staking/)
+[更多關於質押 ETH 的資訊](/staking/)
### 以太坊基金會 {#ethereum-foundation}
最初由 ETH 眾籌融資的非營利組織,致力於支持以太坊網路和生態系統。
-[有關以太坊基金會的更多資訊](/foundation/)
+[更多關於以太坊基金會的資訊](/foundation/)
### ethereum.org {#ethereum-org}
@@ -44,7 +44,7 @@ ethereum.org 是一個屬於以太坊社群的開放原始碼資源,所有人
## 我們的使命 {#our-mission}
-**ethereum.org 的使命是成為日益增長的以太坊社群的最佳入口網站。**
+**ethereum.org 的使命是成為日益增長的以太坊社群的最佳入口網站**
為了幫助新的使用者熟悉以太坊與它的核心概念,我們努力打造一個淺顯易懂的教育資源,涵蓋所有與以太坊有關的主題。 我們希望:
@@ -57,7 +57,7 @@ ethereum.org 是一個屬於以太坊社群的開放原始碼資源,所有人
欲達成此使命,我們的團隊著重於 ethereum.org 的兩個主要目標:
-### 1. 改善 ethereum.org 的使用者體驗 {#visitors}
+### 1. 改善 ethereum.org 訪客的使用者體驗 {#visitors}
- 延伸、改善及持續更新內容
- 透過本地化和網路開發最佳案例來改善可用性和可存取性
@@ -78,52 +78,57 @@ ethereum.org 是一個屬於以太坊社群的開放原始碼資源,所有人
### 1. ethereum.org 是以太坊的入口網站 🌏 {#core-principles-1}
-我們想要激發使用者的興趣和解答他們的問題。 所以我們的入口網站要組合信息與「芝麻開門的時刻」以及現有的社區內傑出資源的鏈結。 我們的目的不是成為大量已有資源的替代品,而是作爲一個「新手教學」內容。 我們致力於支持與整合社群所建的資源,讓更多人發現和看到他們。 [以太坊的社群](/community/)便處於這一切的中心,我們不只是為之服務,更要與他們協作並納入其意見回饋。 這個網站不只是屬於現有社群,它更是屬於我們希望將來歡迎的新成員。 我們必須銘記,我們的社群是國際化的,包含著來自不同語言、地區和文化的人。
+我們想要激發使用者的興趣和解答他們的問題。 所以我們的入口網站要組合信息與「芝麻開門的時刻」以及現有的社區內傑出資源的鏈結。 我們的目的不是成為大量已有資源的替代品,而是作爲一個「新手教學」內容。 我們致力於支持與整合社群所建的資源,讓更多人發現和看到他們。
+[以太坊的社群](/community/)便處於這一切的中心:我們不只是為之服務,更要與他們協作並納入其意見回饋。 這個網站不只是屬於現有社群,它更是屬於我們希望將來歡迎的新成員。 我們必須銘記,我們的社群是國際化的,包含著來自不同語言、地區和文化的人。
-### 2. ethereum.org 不停演進 🛠 {#core-principles-2}
+### 2. ethereum.org 不斷演進 🛠 {#core-principles-2}
-以太坊及其社群也在不斷演進, 所以 ethereum.org 也是。 這也正造就了這個網站的簡單設計與模組化結構。 我們依據人們的使用習慣和社群的需求反覆對網站做出改變。 我們開放原始碼平台擁有著一群卓越的貢獻者,因此任何人都可以提出改變或者提供協助。 [了解如何貢獻](/contributing/)
+以太坊及其社群也在不斷演進, 所以 ethereum.org 也是。 這就是為什麼本網站擁有簡單的設計系統和模組化結構。 我們依據人們的使用習慣和社群的需求反覆對網站做出改變。
+我們開放原始碼平台擁有著一群卓越的貢獻者,因此任何人都可以提出改變或者提供協助。
+[了解如何貢獻](/contributing/)
-### 3. ethereum.org 不是典型的產品網站 🦄 {#core-principles-3}
+### 3 ethereum.org 不是典型的產品網站 🦄 {#core-principles-3}
-以太坊是一個非常大的專案:它囊括了一個社群,一種科技,一套全新的理念等。 這意味著網站需要處理許多不同的使用者旅程,從「需要特定工具的開發者」到「剛購買了一些以太幣但不知道錢包是什麽的新手」。 「什麼才是當之無愧的區塊鏈最佳平台?」一直都是個尋求解答的問題——我們便是先趨。 付諸實踐才能看到答案。
+以太坊是一個非常大的專案:它囊括了一個社群,一種科技,一套全新的理念等。
+這意味著網站需要處理許多不同的使用者旅程,從「需要特定工具的開發者」到「剛購買了一些以太幣但不知道錢包是什麽的新手」。
+「什麼才是當之無愧的區塊鏈最佳平台?」一直都是個尋求解答的問題——我們便是先趨。 付諸實踐才能看到答案。
## 產品開發藍圖 {#roadmap}
-爲了使我們的工作更加易於存取,並促進更多社群合作,ethereum.org 核心團隊發佈了一份季度開發藍圖目標的概述。
+為了使我們的工作更易於存取,並促進更多社群合作,ethereum.org 核心團隊發布了我們的 [塑形週期](https://www.productplan.com/glossary/shape-up-method/) 開發藍圖目標概述。
-[查看我們的 2024 年第三季產品開發藍圖](https://github.com/ethereum/ethereum-org-website/issues/13399)
+[檢視我們的 2025 年第 1 週期產品開發藍圖](https://github.com/ethereum/ethereum-org-website/issues/14726)
-**這聽起來怎麽樣?**我們始終感謝對我們開發藍圖提出的意見回饋——如果你認爲我們有某些方面需要改善,請告訴我們! 我們歡迎來自社群中任何人的想法和提取請求。
+**您覺得如何?** 我們隨時歡迎對我們開發藍圖的意見回饋——如果您認為我們有應該改進的地方,請告訴我們! 我們歡迎來自社群中任何人的想法和提取請求。
-**想要參與?**[瞭解更多有關貢獻的資訊](/contributing/),[在 X(前身為 Twitter)上聯係我們](https://twitter.com/ethdotorg),或者加入我們在 [ Discord 服務器](https://discord.gg/ethereum-org)上的社群討論。
+**想要參與嗎?** [深入了解貢獻相關資訊](/contributing/)、[在 Twitter 上聯繫我們](https://x.com/ethdotorg),或加入我們在 [Discord 伺服器](https://discord.gg/ethereum-org) 的社群討論。
-## 設計理念 {#design-principles}
+## 設計原則 {#design-principles}
-我們利用一組重要[設計原則](/contributing/design-principles/)來指引這個網站的內容創作及決策。
+我們用一套[設計原則](/contributing/design-principles/) 來指導本網站的內容和設計決策。
## 設計系統 {#design-system}
-我們構建並發佈了一個[設計系統](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1),以加快功能上綫的速度,並讓社群成員參與 ethereum.org 的開放設計。
+我們建立並發布了一個[設計系統](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1),以利更快推出功能,並讓社群成員參與 ethereum.org 的開放式設計。
-想要參與?[在 Figma 中追隨 ](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System) [GitHub 問題](https://github.com/ethereum/ethereum-org-website/issues/6284) 並加入我們在 [#design Discord 頻道](https://discord.gg/ethereum-org)中的討論。
+想要參與嗎?[在 Figma 上追蹤](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System)、關注 [GitHub 問題](https://github.com/ethereum/ethereum-org-website/issues/6284),並加入我們 [Discord 的 #design 頻道](https://discord.gg/ethereum-org) 中的對話。
-## 設計指南 {#style-guide}
+## 風格指南 {#style-guide}
-我們有一個[設計指南](/contributing/style-guide/)來標準化某方面的寫作內容,以使貢獻過程更加暢順。
+我們有一份[風格指南](/contributing/style-guide/),用來將撰寫內容的某些方面標準化,使貢獻過程更加順暢。
-如果你想[為網站做出貢獻](/contributing/),請確認你已閱讀[我們的原則](/contributing/design-principles/)和[我們的設計指南](/contributing/style-guide/)。
+如果您想[為本網站做出貢獻](/contributing/),請務必閱讀[我們的原則](/contributing/design-principles/)和[我們的風格指南](/contributing/style-guide/)。
歡迎對我們的設計原則、設計系統和設計指南提供意見回饋。 請記住,ethereum.org 來自社群,服務社群。
-## 證照 {#license}
+## 授權條款 {#license}
-除非另有説明,ethereum.org 是一個開放原始碼網站,並基於[ MIT 證照](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE)構建。 更多有關 ethereum.org [使用條款](/terms-of-use/)的資訊。
+除非另有說明,否則 ethereum.org 網站是開源的,並根據 [MIT 授權條款](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) 建置。 更多關於 ethereum.org 的[使用條款](/terms-of-use/)。
-## 空缺職位 {#open-jobs}
+## 職缺 {#open-jobs}
雖然此為開放原始碼網站且任何人能在此自由貢獻,我們依舊需要一熱誠工作團隊致力於 ethereum.org 及其他以太坊基金會網頁專案。
-我們將公告任何開放職位於此。 如果您找不到適合的職位,請移駕至[我們的 Discord 伺服器](https://discord.gg/ethereum-org)並讓我們知道你想加入我們!
+我們將公告任何開放職位於此。 如果您在此處找不到適合您的職位,請前往[我們的 Discord 伺服器](https://discord.gg/ethereum-org),並告訴我們您想如何與我們合作!
-想加入 ethereum.org 團隊嗎? [歡迎查看其他以太坊相連職位](/community/get-involved/#ethereum-jobs/)。
+想加入 ethereum.org 團隊嗎? [查看其他以太坊相關工作](/community/get-involved/#ethereum-jobs/)。
diff --git a/public/content/translations/zh-tw/ai-agents/index.md b/public/content/translations/zh-tw/ai-agents/index.md
new file mode 100644
index 00000000000..4a816e1dacf
--- /dev/null
+++ b/public/content/translations/zh-tw/ai-agents/index.md
@@ -0,0 +1,143 @@
+---
+title: AI 代理
+metaTitle: AI agents | 以太坊上的 AI agents
+description: 以太坊上的 AI agents 總覽
+lang: zh-tw
+template: use-cases
+emoji: ":robot:"
+sidebarDepth: 2
+image: /images/ai-agents/hero-image.png
+alt: 人們聚集電腦終端機桌前
+summaryPoint1: 與區塊鏈交互並獨立交易的AI
+summaryPoint2: 控制鏈上錢包與資金
+summaryPoint3: 雇傭人類或其他智能體工作
+buttons:
+ - content: 什麽是 AI agents?
+ toId: what-are-ai-agents
+ - content: 探索智能體
+ toId: ai-agents-on-ethereum
+ isSecondary: false
+---
+
+想像一下,你可以藉助一個 AI 助手瀏覽以太坊,它可以 24 小時 / 7 天研究鏈上市場趨勢、回答問題,甚至代替你執行交易。 歡迎來到旨在簡化數字生活的 AI 智能體系統的世界。
+
+在以太坊上,我們正見證 AI 智能體的創新 —— 從虛擬網紅、自主內容創作者到實時市場分析平台,這些創新透過提供洞見、娛樂體驗和運營效率,賦能廣大用戶。
+
+## 什麽是 AI agents? {#what-are-ai-agents}
+
+AI 智能體是使用人工智慧來執行任務或做出自主決策的軟件程序/軟體。 它們從數據中學習,能適應變化,並可以處理複雜任務。 它們無休止地運行,並可以即刻發現機會。
+
+### AI智能體如何與區塊鏈協作 {#how-ai-agents-work-with-blockchains}
+
+在傳統金融中,AI 智能體常常在中心化的環境中運行,獲取的數據輸入有限。 這阻礙了他們學習或自主管理資產的能力。
+
+相比之下,以太坊生態系統提供了一些關鍵優勢:
+
+- 透明的數據: 訪問實時區塊鏈信息。
+- 真實資產所有權: 數字資產完全由AI智能體所有。
+- 强大的鏈上功能: 允許 AI 智能體執行交易、與智能合約交互、提供流動性,並進行跨協議合作。
+
+這些因素把AI智能體從簡單的機器人變成動態的、自主改進的系統,這提供了跨越衆多領域的重要價值:
+
+
+
+
+
+
+
+## 可驗證的 AI {#verifiable-ai}
+
+在鏈外運作的 AI 代理通常表現得像「黑盒子」——其推理、輸入和輸出無法獨立驗證。 以太坊改變了這一點。 透過將代理的行為錨定在鏈上,開發者可以建立 _免信任_、_透明_ 且 _經濟自主的_ 代理。 這些代理的行為可以被審核、約束和證明。
+
+### 可驗證的推理 {#verifiable-inference}
+
+AI 推理傳統上在鏈外進行,那裡的執行成本較低,但模型執行不透明。 在以太坊上,開發者可以使用多種技術將代理與可驗證的計算配對:
+
+- [**zkML (零知識機器學習)**](https://opengradient.medium.com/a-gentle-introduction-to-zkml-8049a0e10a04) 讓代理能夠證明模型已正確執行,而無需揭露模型或輸入
+- [**TEE (可信任執行環境) 證明**](https://en.wikipedia.org/wiki/Trusted_execution_environment) 允許硬體支援的證明,證明代理運行了特定的模型或程式碼路徑
+- **鏈上不可變性**確保這些證明可以被任何合約或代理引用、重播和信任
+
+## 使用 x402 的付款與商業活動 {#x402}
+
+部署在以太坊和 L2 上的 [x402 協定](https://www.x402.org/) 為代理提供了一種原生方式來支付資源費用,並在沒有人為干預的情況下進行經濟互動。 代理可以:
+
+- 使用穩定幣支付運算、資料和 API 呼叫的費用
+- 請求或驗證來自其他代理或服務的證明
+- 參與代理對代理的商業活動,買賣運算、資料或模型輸出
+
+x402 將以太坊轉變為自主代理的可程式化經濟層,實現按次付費的互動,而非帳戶、訂閱或集中式計費。
+
+### 代理金融安全性 {#agentic-finance-security}
+
+自主代理需要護欄。 以太坊在錢包和合約層級提供這些護欄:
+
+- [智能帳戶 (EIP-4337)](https://eips.ethereum.org/EIPS/eip-4337) 讓開發者能夠強制執行支出限制、白名單、會話金鑰和細微性的權限
+- 智能合約中的程式化限制可以限制代理被允許執行的操作
+- 基於推理的限制 (例如,在執行高風險操作前要求提供 zkML 證明) 增加了另一層安全保障
+
+這些控制措施使得部署並非無限制的自主代理成為可能。
+
+### 鏈上註冊表:ERC-8004 {#erc-8004}
+
+[ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) 是一個新興的標準 (目前正在進行同儕審查),它提議為代理的身分、能力和證明建立鏈上註冊表。
+
+如果被採用,它可以提供:
+
+- 一個共享的、免信任的代理目錄
+- 標準化的證明格式
+- 一個直接在以太坊主網上為「免信任代理基礎設施」而設的基礎
+
+這將使代理更容易在完全去中心化的環境中互相發現、驗證和交易。
+
+## 以太坊上的AI智能體{#ai-agents-on-ethereum}
+
+我們正開始探索 AI 智能體的全部潛力,而且已經有項目在人工智慧和區塊鏈之間發揮協同效應 —— 特別是在透明度和貨幣化方面。
+
+
+
+Luna 首次作為播客嘉賓亮相
+
+
+
+## 由智能體控制的錢包{#agent-controlled-wallets}
+
+像 Luna 或 AIXBT 這樣的智能代理控制著自己的鏈上錢包(AIXBT 錢包、Luna 錢包)(https://clusters.xyz/aixbt), [Luna的錢包](https://zapper.xyz/account/0x0d177181e3763b20d47dc3a72dd584368bd8bf43)),使它們能夠給粉絲打賞並參與經濟活動。
+
+在 Luna 的 X 社交媒體營銷活動 #LunaMuralChallenge 期間,Luna 透過她的 Base 錢包選出並獎勵了贏家 —— 這標誌著 對AI 所僱傭人類進行加密獎勵的案例首次出現 。
+
+
+
+
+建議須知
+AI智能體及其相關工具仍然處於早期發展且實驗性階段,要謹慎使用。
+
+
+
+## 在使用智能體聊天指令時要管好錢包。{#control-your-wallet-using-chat-commands}
+
+你可以跳過去中心化金融的複雜交互界面,用簡單的智能體聊天指令管理加密貨幣。
+
+這種直觀路徑使得交易更快、更簡單、更少導致像把資金轉向錯誤地址或過度付費之類的錯誤。
+
+
+
+## AI智能體 VS AI網路機器程序 {#ai-agents-vs-ai-bots}
+
+AI智能體與AI網路機器程序的區別可以在有些時候變得令人迷惑,因爲二者都以輸入為基礎自動行動。
+
+- AI網路機器程序像自動助手,他們遵循特定的預編程指示來執行例行程序任務。
+- AI智能體更像具有智慧的同伴,他們從經驗中學習、可以適應新的信息,並依靠他們自己做出決定。
+
+| | AI 代理 | AI網路機器程序 |
+| -------- | ------------------ | -------------- |
+| **交互** | 複雜的、可適應的、自主的 | 簡單的、預設範圍的、難編程的 |
+| **學習** | 持續學習、可以實驗並適應新的即時數據 | 通過預訓練數據或固定規則運作 |
+| **任務完成** | 旨在實現更廣汎目的 | 僅僅聚焦特定目的 |
+
+## 更深入探索 {#dive-deeper}
+
+
+
+## 你可以構建自己的AI智能體 {#you-can-build-your-own-ai-agent}
+
+
diff --git a/public/content/translations/zh-tw/bridges/index.md b/public/content/translations/zh-tw/bridges/index.md
index 11ac0ebcc4c..dc9ce40ec3b 100644
--- a/public/content/translations/zh-tw/bridges/index.md
+++ b/public/content/translations/zh-tw/bridges/index.md
@@ -6,36 +6,36 @@ lang: zh-tw
# 區塊鏈跨鏈橋 {#prerequisites}
-_Web 3 已發展成由一層和二層網路擴容解決方案組成的生態系統,每個解決方案都有獨特的功能和取捨。 隨著區塊鏈協議數量的增加,跨鏈移動資產的需求也隨之增加。 為了滿足此需求,我們需要跨鏈橋。_
+_Web3 已發展成一個由 L1 區塊鏈和 L2 擴容解決方案組成的生態系統,各自都具有獨特的功能和權衡取捨。 隨著區塊鏈協議數量的增加,跨鏈移動資產的需求也隨之增加。為了滿足此需求,我們需要跨鏈橋。_
## 什麼是跨鏈橋? {#what-are-bridges}
-區塊鏈跨鏈橋的作用,與現實世界中的橋樑,功用是一樣的。 就像現實橋樑連接兩地一樣,跨鏈橋連接的是兩個區塊鏈生態系統。 **跨鏈橋透過資訊的傳輸和資產的轉移,來促進區塊鏈之間的通訊**。
+區塊鏈跨鏈橋的作用,與現實世界中的橋樑,功用是一樣的。 就像現實橋樑連接兩地一樣,跨鏈橋連接的是兩個區塊鏈生態系統。 **跨鏈橋透過傳送資訊和資產,來促進區塊鏈之間的通訊**。
讓我們來看一個例子:
你來自美國,正計劃去歐洲旅行。 你有美元,但你需要歐元才能消費。 為了將你的美元兌換成歐元,你可以支付少量手續費來換匯。
-但是,若要進行類似的換匯以使用另一個[區塊鏈](/glossary/#blockchain),你要怎麼做? 假設你想用以太坊主網上的[以太幣](/glossary/#ether)兌換 [Arbitrum](https://arbitrum.io/) 上的以太幣。 就像我們為歐元進行貨幣換匯一樣,我們需要一種機制,將我們的以太幣從以太坊轉移到 Arbitrum。 跨鏈橋能實現這種交易。 在這個例子中,[Arbitrum 有一個原生的跨鏈橋](https://bridge.arbitrum.io/),可以將以太幣從以太坊主網轉移到 Arbitrum。
+但若您想進行類似的交換以使用不同的[區塊鏈](/glossary/#blockchain)該怎麼辦? 假設您想將以太坊主網上的 [ETH](/glossary/#ether) 兌換成 [Arbitrum](https://arbitrum.io/) 上的 ETH。 就像我們為歐元進行貨幣換匯一樣,我們需要一種機制,將我們的以太幣從以太坊轉移到 Arbitrum。 跨鏈橋能實現這種交易。 在這種情況下,[Arbitrum 有一個原生跨鏈橋](https://portal.arbitrum.io/bridge),可以將 ETH 從主網轉移到 Arbitrum。
## 為什麼我們需要跨鏈橋? {#why-do-we-need-bridges}
-所有區塊鏈都有局限性。 以太坊需要[卷軸](/glossary/#rollups)才能擴容及跟上需求。 或者,Solana 和 Avalanche 等一層網路,透過不同的設計來實現更高的吞吐量,但是犧牲了去中心化。
+所有區塊鏈都有局限性。 為了讓以太坊擴容並跟上需求,就需要 [rollups](/glossary/#rollups)。 或者,Solana 和 Avalanche 等一層網路,透過不同的設計來實現更高的吞吐量,但是犧牲了去中心化。
-然而,所有的區塊鏈都是在孤立的環境中發展,並具有不同的規則和[共識](/glossary/#consensus)機制。 這意味著其無法原生通訊,代幣也無法在區塊鏈之間自由移動。
+然而,所有區塊鏈都是在孤立的環境中開發的,並且有不同的規則和[共識](/glossary/#consensus)機制。 這意味著其無法原生通訊,代幣也無法在區塊鏈之間自由移動。
跨鏈橋的存在就是為了連接區塊鏈,使彼此之間能傳送資訊和代幣。
-**跨鏈橋可以做到**:
+**跨鏈橋可實現**:
- 資產和資訊的跨鏈轉移。
-- 能讓[去中心化應用程式](/glossary/#dapp)利用各區塊鏈的優勢,從而增強區塊鏈的能力(因為協議現在有了更多的創新設計空間)。
+- 讓[去中心化應用程式](/glossary/#dapp)存取各種區塊鏈的優勢——從而增強其能力(因為協定現在有更多創新的設計空間)。
- 能讓使用者存取新的平台,並徹底善用不同區塊鏈的優勢。
- 能讓來自不同區塊鏈生態系統的開發者相互合作,並為使用者建立新平台。
-[如何通過跨鏈橋將代幣轉移至第二層網路](/guides/how-to-use-a-bridge/)
+[如何將代幣橋接到 Layer 2](/guides/how-to-use-a-bridge/)
@@ -43,13 +43,13 @@ _Web 3 已發展成由一層和二層網路擴容解決方案組成的生態系
以下是一些可以使用跨鏈橋的場景:
-### 降低交易費 {#transaction-fees}
+### 較低的交易費用 {#transaction-fees}
假設你在以太坊主網上擁有以太幣,但想要以更便宜的交易費來探索不同的去中心化應用程式。 將你的以太幣從主網跨鏈傳送到以太坊二層網路卷軸,可以享有更低的交易費。
-### 在其他區塊鏈上的去中心化應用程式 {#dapps-other-chains}
+### 其他區塊鏈上的去中心化應用程式 {#dapps-other-chains}
-假設你一直在以太坊主網上使用 Aave 借出泰達幣,但在 Polygon 上使用 Aave 借出泰達幣的利率更高。
+假設你一直在以太坊主網上使用 Aave 供應泰達幣,但在 Polygon 上使用 Aave 供應泰達幣的利率更高。
### 探索區塊鏈生態系統 {#explore-ecosystems}
@@ -57,13 +57,13 @@ _Web 3 已發展成由一層和二層網路擴容解決方案組成的生態系
### 擁有原生加密資產 {#own-native}
-假設你想擁有原生比特幣 (BTC),但你的資金只存在於以太坊主網上。 要在以太坊上獲得比特幣,你可以購買包裝比特幣 (WBTC)。 然而,包裝比特幣是以太坊網路原生的 [ERC-20](/glossary/#erc-20) 代幣,這意味著它是以太坊版本的比特幣,而不是比特幣區塊鏈上的原始資產。 要擁有原生比特幣,你必須使用跨鏈橋將資產從以太坊轉移到比特幣。 這將會橋接包裝比特幣並轉換為原生比特幣。 或者,你可能擁有比特幣,並想在以太坊的[去中心化金融](/glossary/#defi)協定中使用它。 這將需要以另一種方式橋接,從比特幣到包裝比特幣,然後可將包裝比特幣作為以太坊上的資產。
+假設你想擁有原生比特幣 (BTC),但你的資金只存在於以太坊主網上。 要在以太坊上獲得比特幣,你可以購買包裝比特幣 (WBTC)。 然而,WBTC 是以太坊網路原生的 [ERC-20](/glossary/#erc-20) 代幣,這意味著它是以太坊版本的比特幣,而不是比特幣區塊鏈上的原始資產。 要擁有原生比特幣,你必須使用跨鏈橋將資產從以太坊轉移到比特幣。 這將會橋接包裝比特幣並轉換為原生比特幣。 或者,您可能擁有 BTC,並想在以太坊 [DeFi](/glossary/#defi) 協定中使用它。 這將需要以另一種方式橋接,從比特幣到包裝比特幣,然後可將包裝比特幣作為以太坊上的資產。
- 你也可以使用 [中央化交易所](/get-eth/) 完成上述所有操作。 但是,除非你已有資金在交易所內,否則會涉及多個步驟,而你可能會覺得使用跨鏈橋比較好。
+ 你也可以使用[中心化交易所](/get-eth)完成上述所有操作。 但是,除非你已有資金在交易所內,否則會涉及多個步驟,而你可能會覺得使用跨鏈橋比較好。
@@ -74,16 +74,16 @@ _Web 3 已發展成由一層和二層網路擴容解決方案組成的生態系
跨鏈橋具有許多不同的設計類型和複雜度。 通常,跨鏈橋分為兩類,即受信任和去信任跨鏈橋。
-| 受任跨鏈橋 | 去信任跨鏈橋 |
-| -------------------------------------------- | ---------------------------------------------------------- |
-| 受信任跨鏈橋倚賴一個中心實體或系統來運作。 | 去信任跨鏈橋利用智慧型合約及演算法來運行。 |
-| 在資金監管及跨鏈橋的安全性方面,具有許多信任假設。 使用者大多有賴於跨鏈橋運營商的聲譽。 | 屬於去信任,即跨鏈橋的安全性與底層區塊鏈的安全性相同。 |
-| 使用者需放棄對其加密資產的控制。 | 透過[智慧型合約](/glossary/#smart-contract),去信任跨鏈橋讓使用者能繼續控制他們的資金。 |
+| 受任跨鏈橋 | 去信任跨鏈橋 |
+| -------------------------------------------- | -------------------------------------------------------- |
+| 受信任跨鏈橋倚賴一個中心實體或系統來運作。 | 去信任跨鏈橋利用智慧型合約及演算法來運行。 |
+| 在資金監管及跨鏈橋的安全性方面,具有許多信任假設。 使用者大多有賴於跨鏈橋運營商的聲譽。 | 屬於去信任,即跨鏈橋的安全性與底層區塊鏈的安全性相同。 |
+| 使用者需放棄對其加密資產的控制。 | 透過[智能合約](/glossary/#smart-contract),免信任跨鏈橋讓使用者能夠持續控制其資金。 |
簡而言之,我們可以說受信任跨鏈橋具有信任假設,去信任跨鏈橋則是將信任最小化,不必在底層領域之外做出新的信任假設。 這些術語可做這樣的解釋:
-- **去信任**:安全性等同於底層領域。 如 [Arjun Bhuptani 在本文中所述。](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17)
-- **信任假設:**在系統中加入外部驗證者,擺脫底層領域的安全性,其加密經濟的安全性因此降低。
+- **免信任**:擁有與底層域同等的安全性。 如 [Arjun Bhuptani 在本文所述。](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17)
+- \*\*信任假設:\*\*透過在系統中加入外部驗證者而脫離了底層域的安全性,從而降低其加密經濟安全性。
為了更加理解這兩種方法的主要區別,讓我們舉個例子:
@@ -104,8 +104,8 @@ _Web 3 已發展成由一層和二層網路擴容解決方案組成的生態系
使用跨鏈橋能夠讓你在不同的區塊鏈之間轉移資產。 以下是一些可以幫助你找到和使用跨鏈橋的資源:
-- **[L2BEAT 跨鏈橋摘要](https://l2beat.com/bridges/summary)和 [L2BEAT 跨鏈橋風險分析](https://l2beat.com/bridges/summary)**:提供各種跨鏈橋的完整摘要,包括市場份額、跨鏈橋類型和目標鏈的細節。 L2BEAT 也提供跨鏈橋風險分析,幫助使用者明智地挑選跨鏈橋。
-- **[DefiLlama 跨鏈橋摘要](https://defillama.com/bridges/Ethereum)**:提供以太坊網路上各種跨鏈橋的交易量摘要。
+- **[L2BEAT 跨鏈橋摘要](https://l2beat.com/bridges/summary)與[L2BEAT 跨鏈橋風險分析](https://l2beat.com/bridges/summary)**:各種跨鏈橋的全面摘要,包括市佔率、跨鏈橋類型和目標鏈等詳細資訊。 L2BEAT 也提供跨鏈橋風險分析,幫助使用者明智地挑選跨鏈橋。
+- **[DefiLlama 跨鏈橋摘要](https://defillama.com/bridges/Ethereum)**:以太坊網路上各跨鏈橋交易量的摘要。
@@ -113,13 +113,13 @@ _Web 3 已發展成由一層和二層網路擴容解決方案組成的生態系
跨鏈橋仍在早期發展階段。 很可能尚未發現最佳的跨鏈橋設計。 與任何類型的跨鏈橋互動都有風險:
-- **智慧型合約風險 —** 程式碼漏洞風險,這可能導致使用者資金流失
-- **技術風險 —** 軟體故障、程式碼漏洞、人為錯誤、垃圾郵件和惡意攻擊可能會干擾使用者作業
+- \*\*智能合約風險——\*\*程式碼中的錯誤可能導致使用者資金遺失的風險。
+- \*\*技術風險——\*\*軟體故障、有錯誤的程式碼、人為錯誤、垃圾訊息和惡意攻擊都可能中斷使用者操作。
此外,受信任跨鏈橋由於增加了信任假設,因此帶來額外的風險,例如:
-- **審查風險 —** 跨鏈橋運營商理論上可以阻止使用者利用跨鏈橋來轉移資產
-- **託管風險 —** 跨鏈橋運營商可以串通盜取使用者的資金
+- \*\*審查風險——\*\*跨鏈橋營運商理論上可以阻止使用者利用跨鏈橋轉移資產。
+- \*\*託管風險——\*\*跨鏈橋營運商可以共謀竊取使用者的資金。
如果出現以下情況,使用者的資金將面臨風險:
@@ -129,14 +129,17 @@ _Web 3 已發展成由一層和二層網路擴容解決方案組成的生態系
- 在某個受信任跨鏈橋中,跨鏈橋運營商心懷不軌
- 跨鏈橋被駭客入侵
-最近一次駭客攻擊針對的是 Solana 的 Wormhole 跨鏈橋,[在駭客攻擊期間其被竊取了 12 萬包裝以太幣(3.25 億美元)](https://rekt.news/wormhole-rekt/)。 很多[最嚴重的區塊鏈駭客事件都與跨鏈橋有關](https://rekt.news/leaderboard/)。
+最近發生的一起駭客事件是 Solana 的 Wormhole 跨鏈橋,[在該事件中有 12 萬 wETH (約 3.25 億美元) 被盜](https://rekt.news/wormhole-rekt/)。 許多[區塊鏈上的重大駭客事件都涉及跨鏈橋](https://rekt.news/leaderboard/)。
-跨鏈橋對於讓使用者加入以太坊二層網路至關重要,對於想要探索不同生態系統的使用者也是如此。 然而,與跨鏈橋互動涉及上述風險,使用者必須了解跨鏈橋做出了哪些權衡取捨。 這裡提供一些[跨鏈安全性策略](https://blog.debridge.finance/10-strategies-for-cross-chain-security-8ed5f5879946)。
+跨鏈橋對於讓使用者加入以太坊二層網路至關重要,對於想要探索不同生態系統的使用者也是如此。 然而,與跨鏈橋互動涉及上述風險,使用者必須了解跨鏈橋做出了哪些權衡取捨。 這裡有一些[跨鏈安全策略](https://debridge.com/learn/blog/10-strategies-for-cross-chain-security/)。
## 延伸閱讀 {#further-reading}
-- [EIP-5164:跨鏈執行](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) _2022 年 6 月 18 日 - Brendan Asselstine_
-- [二層網路跨鏈橋風險框架](https://gov.l2beat.com/t/l2bridge-risk-framework/31) _2022 年 7 月 5 日 - Bartek Kiepuszewski_
-- [「為什麼未來會多鏈並存但不是跨鏈」](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) _2022 年 1 月 8 日 - Vitalik Buterin_
+- [EIP-5164:跨鏈執行](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) - _2022 年 6 月 18 日 - Brendan Asselstine_
+- [L2Bridge 風險框架](https://gov.l2beat.com/t/l2bridge-risk-framework/31) - _2022 年 7 月 5 日 - Bartek Kiepuszewski_
+- [「為什麼未來將是多鏈,但不會是跨鏈。」](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) - _2022 年 1 月 8 日 - Vitalik Buterin_
+- [利用共享安全性實現安全的跨鏈互通性:拉格朗日狀態委員會及其他](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - _2024 年 6 月 12 日 - Emmanuel Awosika_
+- [Rollup 互通性解決方案的現狀](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - _2024 年 6 月 20 日 - Alex Hook_
+
diff --git a/public/content/translations/zh-tw/community/code-of-conduct/index.md b/public/content/translations/zh-tw/community/code-of-conduct/index.md
index 177f12f87b4..925d177874d 100644
--- a/public/content/translations/zh-tw/community/code-of-conduct/index.md
+++ b/public/content/translations/zh-tw/community/code-of-conduct/index.md
@@ -10,68 +10,68 @@ lang: zh-tw
開發及維護最詳盡、最易存取的以太坊知識中心。
-## 核心價值 {#values}
+## 價值觀 {#values}
-Ethereum.org 致力於:
+ethereum.org 社群致力於成為:
-- 教育,目標是幫助大家了解以太坊
-- 實現包容性
-- 實現可存取性
-- 專注於社群導向
+- 具教育意義,旨在幫助每個人了解以太坊
+- 具包容性
+- 易於存取
+- 由社群驅動
- 專注於以太坊底層技術及使用案例
- 專注於以太坊概念與設計原則
-## 我們不是 {#what-we-are-not}
+## 我們的非屬範疇 {#what-we-are-not}
- 以太坊基金會的網站
-- 推廣投資或以任何形式牟取暴利的平臺
-- 認可個人專案,或為任何組織背書的平臺
-- 中心化及去中心化交易所,或其他任何形式的金融平臺
-- 提供投資建議或法律諮詢等的平臺
+- 推廣投資或以任何形式牟取暴利的平台
+- 為個人專案或組織抬高聲譽或背書的平台
+- 去中心化交易所 (DEX)、中心化交易所 (CEX) 或任何其他形式的金融平台
+- 提供任何形式的財務或法律建議的平台
## 行為守則 {#code-of-conduct}
### 承諾 {#pledge}
-開放參與是 ethereum.org 的核心精神。 我們的網站和社群由數千位貢獻者維護,只有當我們維持友好的參與環境時,這才可能實現。 為此,本網站的貢獻者承諾將為所有 ethereum.org 平臺及社群參與者維持一個零騷擾的環境。 Ethereum.org 社群歡迎和重視任何友善或想參與建設的人,無論年齡、是否殘疾、種族、性別特徵、性別認同、經驗水平、專業領域、教育、社會經濟地位、國籍、外觀、種族、宗教或任何其他方面的多樣性。
+開放參與是 ethereum.org 的核心精神。 我們的網站和社群由數千位貢獻者維護,只有當我們維持友好的參與環境時,這才可能實現。 為此,本網站的貢獻者承諾為所有 ethereum.org 平台及社群空間的所有參與者維持一個零騷擾的環境。 ethereum.org 社群歡迎並重視任何想以建設性及友善方式參與的人,無論其年齡、身心障礙、種族、性別特徵、性別認同、經驗程度、專業領域、教育、社經地位、國籍、外貌、人種、宗教或任何其他多元面向。
### 適用範圍 {#scope}
-此行為守則適用於所有 ethereum.org 空間(如 GitHub、Discord、Figma、Crowdin、Twitter 和其他線上平臺),且當社群在現實世界的公共場所(如:聚會、座談會及活動等等)時也同樣適用。
+本行為守則適用於所有 ethereum.org 空間 (例如 GitHub、Discord、Figma、Crowdin、X (前身為 Twitter) 及其他線上平台),也適用於社群在現實世界公共空間 (例如見面會、研討會和活動) 中作為代表時。
### 我們的標準 {#our-standards}
-為打造一個正向環境做出貢獻的行為範例:
-
-- 使用友好且包容的詞彙
-- 尊重各種不同的觀點和經驗
-- 優雅地接受和/或站在他人角度提供建設性批評
-- 心平氣和地處理衝突或分歧
-- 對其他社群成員展現同理心和包容心
-- 鼓勵和提倡社群中的新意見
-
-不被允許的行為示例包括:
-
-- 人身暴力、威脅人身暴力或鼓勵任何形式的人身暴力
-- 使用帶有性暗示的言語或圖像,或令人反感的性關注
-- 冒充他人或以其他方式謊稱與某些人或組織有聯繫
-- 蓄意激怒、汙辱/貶低他人,以及人身或政治上的攻擊
-- 在公開或私人頻道中騷擾其他社群成員
-- 未經許可公開他人的私人資料,如實體住址或網路位址
-- 使用社交工程、詐騙或操控其他社群成員
-- 宣傳投資、代幣、專案或其他任何東西以獲得個人金錢上或非金錢上的利益
-- 用與主題無關的內容在伺服器洗版
+有助於創造正向環境的行為範例包括:
+
+- 使用友善且包容的言詞
+- 尊重不同的觀點與經驗
+- 得體地接受及/或富同理心地提出建設性批評
+- 解決衝突或分歧時,保持冷靜與專業
+- 對其他社群成員展現同理心與包容心
+- 鼓勵並擴大社群中新聲音的影響力
+
+參與者的不當行為範例包括:
+
+- 任何形式的肢體暴力、威脅使用肢體暴力,或鼓勵肢體暴力
+- 使用色情言語或圖像,或強加不受歡迎的性關注
+- 冒充他人,或以其他不誠實的方式聲稱與某個人或組織有關聯
+- 引戰、侮辱/貶抑性言論,以及人身或政治攻擊
+- 在公開或私人頻道騷擾其他社群成員
+- 未經明確許可,發布他人的私人資訊,例如實際地址或電子郵件地址
+- 對其他社群成員進行社交工程、詐騙或以其他方式操縱
+- 為獲取個人金錢或非金錢利益而推廣投資、代幣、專案或任何其他事物
+- 以無關內容在伺服器上洗版
- 無視社群版主的要求或警告
-- 從事其他專業場合下不該出現的行為
+- 從事在專業場合下可被合理視為不當的其他行為
-### 檢舉 {#reporting}
+### 舉報 {#reporting}
-違反行為守則一般來說都會被社群看到,因為我們努力讓一切透明,以便社群成員能夠自我監督。
+違反行為守則的行為通常會讓社群看見,因為我們盡力在開放的公開頻道中處理所有事務,讓社群成員能夠自我監督。
-然而,如果發生了一些你覺得需要額外關注的事件,你可以向擁有版主身份者(如 discord guide)提出,使他們能協助調查和執行適當的回覆。
+然而,如果發生了您認為需要關注的事件,可以向具備管理員角色的人員 (例如 Discord 指南) 提出,讓他們協助調查並採取適當的回應。
-檢舉時,請儘可能附上詳細資訊,包括具體的例子與發生時間。 這有助於確保結果公平。
+舉報時,請盡可能提供詳細資訊,包括具體範例和時間戳。 這將有助於確保公平的結果。
-### 強製執行 {#enforcement}
+### 執行 {#enforcement}
依據嚴重程度,違反行為守則者可能會收到警告、暫時停權或被永久踢出 ethereum.org 社群。
diff --git a/public/content/translations/zh-tw/community/events/organizing/index.md b/public/content/translations/zh-tw/community/events/organizing/index.md
new file mode 100644
index 00000000000..71e16de9ace
--- /dev/null
+++ b/public/content/translations/zh-tw/community/events/organizing/index.md
@@ -0,0 +1,221 @@
+---
+title: 組織一次以太坊活動
+description: 如何組織一次以太坊活動
+lang: zh-tw
+hideEditButton: true
+---
+
+# 如何組織一次以太坊活動{#how-to-organize-an-ethereum-event}
+
+建立強大且充滿活力的社群是以太坊生態系統成長的核心。 無論您是打算組織聚會、研討會或大型會議,活動的成功都有賴於當地社交網路的連結與參與。 這個指南將協助您為一個活躍的以太坊社群奠定基礎,並一步一步帶領您組織一個難忘又有影響力的會議。
+
+## 問問自己,有以太坊社群嗎? {#ask-yourself-is-there-an-ethereum-community}
+
+一個成功的以太坊會議建立在一個活躍且參與度高的社群上。 如果你已經有了一個社群,那你就率先走在了這場遊戲的前列——但如果你還沒有,最重要的前期步驟就是打好這個基礎。 重要的是要區分一個現場和社區:現場可能包括某個領域的公司和個人,但他們往往獨立運作,只是偶爾聯合開展活動--就像許多地方的傳統web2生態系統一樣。 另一方面,社區是一個由相互聯繫的人們和組織構成的網路,他們相互協作、相互支持,這在web3生態系統中經常可以看到。
+
+**你的第一步應該是:**
+
+- 探索當地的初創企業和公司--在你所在的城市或國家擁有強大、活躍的公司往往是建立社區最關鍵的先決條件。
+- 查看是否已經有一些聚會——ethereum.org [活動頁面](https://ethereum.org/community/events/)
+- [以太坊官網](https://ethereum.org/community/events/) 和 ethereum.org Discord——查看當地是否有以太坊的活動、開發者和貢獻者。
+- Luma 和 Meetup.com——查看您所在地區是否有與以太坊相關的活動或更廣泛的 Web3 活動。
+- X——尽量在Spaces上寻找支持者或有影响力的人。
+
+如果您發現了這些要素中的大多數,這就充分說明已經具備了建立社區的條件,但並不一定說明社區已經可以建立起來了。 下一步的關鍵工作是組織、吸引和培養這些參與者,為合作和長期發展創造機會。
+
+### 如果沒有這些要素,如何構建社群 {#if-not-how-to-build-it}
+
+如果你發現缺少許多要素,不要擔心——從頭開始建立一個社群是一個充滿挑戰但回報豐厚的過程。 一個強大的以太坊社區不會一蹴而就;它需要耐心、一致性和清晰的願景。 您可以從這些步驟開始:
+
+- **建立一個交流渠道**——可以是 Telegram、Signal、WhatsApp、微信或 Discord 服務器,只要是你所在的地方比較流行的媒體,人們就可以由此聯繫、提問和共享資源。
+- \*\* 找到你的早期使用者\*\* 找出一些對以太坊和 Web3 充滿熱情的人。 他們將成為你的核心支持者和合作夥伴。
+- **舉辦小型、定期的活動。** 從非正式的聚會、學習小組或工作坊開始。 一致性是關鍵——即使初期規模不大,定期舉辦活動也能建立信任並形成勢頭。
+- **嘗試聯繫當地企業**、教育機構或共享辦公空間,看能否獲得免費場地支持。 若無法在本國找到演講者,可邀請線上的演講者,但需線下聚集人群。 讓觀眾聚集在同一個物理空間至關重要。
+- \*\*與現有技術社群合作。\*\*若已有開發者團體、初創企業生態圈或區塊鏈聚會活動,可與其建立合作關係,引入以太坊相關議題並擴大影響力。
+- **分享關於以太坊潛力的教育內容**。
+- **拓展全球社群網絡。** 聯繫全球成熟的以太坊團體與項目,獲取支持、指導及潛在合作機會。 全球以太坊社區至少有一個共同點:他們都熱衷於提供幫助。
+- **嘗試爭取資金支持**——無論是來自本地Web3企業,還是通過某些資助項目,例如[ESP](https://esp.ethereum.foundation/)。
+
+### 如果成功獲取了資金,如何維持並擴大規模 {#if-yes-how-to-maintain-and-grow-it}
+
+建立了社群之後,工作也就不會停止——事實上,這才剛剛開始。 要保持社區活躍、參與度高且持續發展,需要持續的努力和創造力。 保持社區參與的關鍵要素之一,就是你應該不斷嘗試新的形式和創意。
+
+以下是一些保持以太坊社區蓬勃發展的策略:
+
+- **豐富活動形式:** 不要只局限於一種聚集的模式。 通過線下聚會、簡短的黑客松、專題討論會和社交活動來搞點新花樣。 你可以嘗試組織大家一同工作的日子或教育課程。
+- \*\*拓展議題:\*\*以太坊不僅是一項技術,更是一套涵蓋法律、營銷和商業領域的價值體系。
+- **向你的社區徵集反饋和建議。**。
+- **與不同受眾群體互动**。 根據受眾不同的經驗水平定製內容和活動——從初次探索以太坊的新手,到經驗豐富的開發者和創業者。
+
+通過提供多樣化的學習、協作與成長機會,您能確保社區保持活躍狀態,隨時準備迎接更大型的活動,例如組織會議。
+
+## 活動{#event}
+
+### 何時是舉辦活動的最佳時機? {#when-is-the-right-time-to-organize-an-event}
+
+成功舉辦以太坊會議或社區活動需要精心安排時間且考慮周全。 恰當的時機取決於多種因素,這些因素共同促成了活動從整體上來說的成功。
+
+你應綜合考量社區發展成熟度、市場環境、團隊組建情況以及當地生態圈的活躍度(例如潛在贊助商資源)。
+
+### KYC——了解你的社區{#kyc-know-your-community}
+
+組織活動最重要的步驟之一就是了解你的社區。 正如金融服務中的“了解你的客戶”(KYC),“了解你的社區”(KYC)意味着花時間去理解本地受眾的具體需求、偏好和特徵。 這種理解將有助於您量身定製會議內容,確保其成功與內容相關性。
+
+雖然立即策劃大型活動聽起來頗具誘惑,但從小的活動着手往往是最佳策略。 若你客觀審視社區的現狀及某些看似無關的因素——例如:你的國家是否是熱門旅遊目的地,或者住宿的成本怎麼樣——你自會明白何為最佳解決方案。
+
+在第一年,你的受眾群體主要來自本地社區,因此籌辦大型活動時,所有工作都應圍繞該社區的需求和規模展開。
+
+### 從哪裡開始{#where-to-start}
+
+在籌辦會議時,最初要做什麼往往令人不知所措。 但只要制定清晰的計劃和框架,你就能將整個過程分解為可控的任務。 我們將逐一分析它們。
+
+採用結構化的方法開始籌備,將有助於你在推進活動籌備的各個階段時保持清晰的條理,從而減輕壓力。 您所做的每個決定都應讓您更接近於提供滿足社區需求的體驗。
+
+**首要任務是組建一支職責分工明確的組織團隊。**
+
+在開始構建程序或聯繫贊助商之前,另一個重要步驟是選擇日期。 雖然這聽起來像是一個簡單的步驟,但在實施之前,你應該考慮幾個重要的因素。 其中的一些因素是:
+
+- **避免與重要會議或活動日期衝突**
+- **考慮當地條件和情況**(例如一年中的季節、主要節日等)
+- **考慮市場狀況**
+- **給自己充足的時間來安排一切**——至少九個月
+
+### 如何評估一個團隊{#how-to-assemble-a-team}
+
+選擇那些與你志同道合、能互補你技能的人。 有些團隊以集體形式運作,有些則設有明確分工——找出最適合你的方式。 保持定期溝通並明確期望至關重要。 儘管人們很想依賴通訊平臺來策劃活動,但我們建議選擇任務管理平臺(例如Notion、Basecamp、Trello、Asana,甚至經典的Google表格)來統籌安排並追蹤各項待辦事項。 擁有一個運作良好且組織有序的團隊至關重要。
+
+不同的以太坊組織團隊在各自團隊中承擔着不同的職責,但都包含負責後勤、預算、市場營銷、項目策劃、設計以及合作夥伴關係的人員。
+
+### 活動方案:成功活動的關鍵要素{#the-program-a-key-element-of-a-successful-event}
+
+要舉辦一場真正有價值且令人難忘的會議,**議程安排至關重要**。 在這個領域,你絕不能有絲毫妥協。 雖然贊助商對活動融資至關重要,但觀眾的體驗及其獲得的價值必須始終優先考慮。 充斥着過量宣傳內容和無休止贊助商推銷的活動安排,不僅會使你同觀眾疏遠,更會損害活動的公信力。
+
+每次會議、專題討論和工作坊都應讓社區成員獲得信息、受到啟發並積極參與。 傾聽受眾的心聲——了解他們的興趣、需求和面臨的挑戰。 哪些話題能引起他們的共鳴? 同時,引入新穎視角和創新形式,保持節目的活力。 在熟悉主題與熱門話題之間取得平衡,融入前沿理念,確保議程全面覆蓋以太坊生態系統的不同的維度——從技術深度解析、社區建設研討會,到政策討論與實踐工作坊。 此外,還需考慮會議的語言——儘管英語是大多數以太坊活動的默認語言,但提供本地語言的會議環節能讓活動更便於區域開發者和愛好者參與。
+
+\*\*在挑選演講嘉賓時,應至少在會議召開前六個月啟動徵集流程,以吸引高質量的投稿並為議程策劃預留充足時間。\*\*負責嘉賓篩選的人員需具備豐富的行業經驗,並對生態系統有深刻理解。 這確保他們能夠識別有價值、有見地的貢獻,並保持內容的高標準。
+
+### 在哪裡尋找經濟支持{#where-to-find-financial-support}
+
+舉辦一場高質量的會議需要承擔高昂的成本——場地租賃、宣傳物料、餐飲服務、活動製作以及其他無數開支。 儘早獲得資金支持至關重要,這能確保活動達到專業水準,並為參與者提供卓越的體驗。
+
+#### 如何創建贊助方案? {#how-to-create-a-sponsorship-deck}
+
+首先,你將會需要一個簡報。 **向其他會議組織者尋求建議**,甚至請他們分享演示文稿,以便你據此設計自己的方案。 在定價方面,你應該保持務實態度,目標是覆蓋成本而非盈利,尤其是在起步階段。
+
+**每份贊助方案都應清晰有力地概述活動概況**,確保潛在贊助商充分理解活動的規模、重點及價值。 從基礎要素入手——場地、日期以及組織團隊的詳細信息——以建立可信度。 然後,突出該活動的核心主題,因為不同的以太坊會議面向不同的受眾群體。 有些社區高度側重建設者,以深入的技術討論為特色;而另一些則可能更關注DeFi、DAO或政策議題。
+
+不僅要描述活動本身,還要設定明確的期望。 請概述預計參會人數及已確認的關鍵演講嘉賓,這有助於贊助商評估其潛在影響力。 最重要的是,明確界定贊助方將獲得的回報——展位空間、演講機會、社交媒體推廣、品牌曝光度或專屬人脈資源。 精心設計的演示文稿不僅能向潛在贊助商傳遞信息,更能激發他們參與活動的熱情。
+
+#### 誰可能會支持你的活動? {#who-might-support-your-event}
+
+首先,聯繫您所在城市或國家內以太坊及更廣泛技術生態系統中的企業。 這些**組織通常對支持促進社區發展和創新的本地活動有着既得利益**。 他們也更可能認識到投資本地生態系統的價值,並將您的會議視為與人才、合作夥伴及用戶建立聯繫的契機。
+
+一旦你獲得了本地支持,就可以將你的影響力擴展到Web3領域的全球參與者。 **成熟的協議、DAO及生態系統基金通常會為社區驅動的活動分配預算**。 對於初次承辦活動的組織者而言,這可能頗具挑戰性——畢竟他們尚未建立可展示的活動記錄。但請嘗試精心設計一份引人入勝的贊助方案,清晰闡明支持活動的益處:品牌曝光度、演講機會以及與目標受眾建立有意義的互動。 嘗試發掘你與眾不同的、他人所不具備的獨特價值。
+
+#### 其它的活動資金的籌措方式 {#alternative-forms-of-funding-your-event}
+
+撥款是另一種潛在的資金來源,許多組織者往往忽視了這一點。 諸如以太坊基金會推出的[生態系統支持計劃](https://esp.ethereum.foundation/)(ESP)以及[其他資助項目](https://ethereum.org/community/grants/#ethereum-grants)等計劃,旨在支持社區主導的活動。
+
+除資金贊助外,還可考慮實物合作,特別是在食品飲料方面的合作。 與當地文化或科技社群契合的品牌,可成為您活動的絕佳合作夥伴。 咖啡品牌、飲料公司甚至本地披薩店都可能願意提供產品,以換取在活動中的曝光機會。 這些合作有助於降低成本,同時提升參會者的體驗。
+
+既然談到經濟問題,請牢記:每投入一美元打造卓越的參會者體驗,都將獲得指數級的回報。 高品質的製作、舒適的場地、精心準備的禮品以及組織有序的配套活動,共同打造出令人難忘的體驗,讓參與者在會議結束後仍會津津樂道。 滿意的參與者將成為您最忠實的擁護者,並確保活動的長期成功。
+
+### 物流{#logistics}
+
+在確保資金到位的同時,您應將重點放在後勤保障上。 一場組織完善的會議需要在多個領域進行周密規劃,從會場布置到參會者體驗都需精心安排。 擁有具備紮實活動組織經驗的人員——不一定是Web3活動,但必須是活動策劃方面的經驗——將產生巨大影響。 經驗豐富的物流主管能夠預見潛在問題,並在問題顯現前予以解決,從而節省時間、金錢和精力。
+
+負責後勤的人員應選擇場地、製作公司以及餐飲、飲料和商品的不同供應商,同時還需配備一個易於使用的在線票務系統,該系統應支持參會者使用加密貨幣進行註冊和支付。
+
+### 地點的基礎設施 {#location-infrastructure}
+
+在選擇會議地點時,重要的是要超越場地本身,考慮更廣泛的城市和國家基礎設施。 天氣、交通便利性、安全保障以及政治環境等因素對塑造參會者體驗具有重大影響。
+
+對於知名度較低的地方,這一點尤為關鍵。 來自世界各地的與會者和贊助商需要確信他們能夠輕鬆且安全地出行。 考察機場交通便利性、公共交通系統以及住宿選擇等方面的因素。 同時,明智的做法是考慮該地區的文化和政治環境,以避免可能阻礙國際參與者的複雜因素,例如簽證政策。
+
+### 如何有效推廣活動{#how-to-promote-the-event}
+
+有效推廣活動是吸引目標受眾並營造熱烈氛圍的關鍵。 精心設計的推廣策略能確保您的會議獲得應有的關注度和參與度。 設計在您的品牌建設中同樣扮演着重要角色,因此您務必為此預留預算。
+
+#### 社交媒體{#social-media}
+
+X.com將成為您社交媒體推廣的核心支柱。 儘量保持活躍並堅持在該平臺發帖,同時積極參與各類討論——既要使用個人賬號參與,也要通過組織賬號參與互動。
+
+儘管領英聽起來並非最顯而易見的推廣選擇,但你可以在那裡接觸到完全不同的受眾群體,甚至吸引到一些贊助商。
+
+#### 與其他以太坊社區的合作 {#partnerships-with-other-ethereum-communities}
+
+與不同以太坊組織者的合作能藉助現有網絡擴大影響力,尤其當你從零起步時。 提供社區折扣,與其他活動進行交叉推廣,並邀請合作夥伴共同舉辦配套活動或工作坊。
+
+#### 大學拓展活動{#university-outreach}
+
+通過學生社團或教授聯繫當地理工科和經濟學院系,推廣本次活動。 與高校開展合作有助於吸引青年人才、研究人員及未來行業專業人士,從而加強學術界與以太坊生態系統的聯繫。 這對於組織黑客松活動尤為理想,學生們往往能帶來新穎的創意、飽滿的熱情以及紮實的技術基礎。
+
+#### 媒體{#media}
+
+聯繫專注於Web3領域的媒體機構和通訊刊物,爭取活動報道。 儘管Web3媒體通常期望為其公關文章收取費用,但若您沒有預算進行付費推廣,也可以提供免費門票或安排與知名演講嘉賓及贊助商的專訪機會。 創建一個公關資料包,內含新聞稿及若干視覺素材,以便在社交媒體或網站上以不同格式進行推廣。 此外,還應擴大合作範圍,涵蓋本地記者乃至內容創作者(只要他們具備良好聲譽),只要他們能報道科技領域,這對於向更廣泛的受眾展示活動至關重要。 這有助於彌合加密行業與廣大公眾之間的鴻溝,吸引主流科技和商業圈的關注。
+
+### 你是否也應該組織一場黑客松? {#should-you-organize-a-hackathon-as-well}
+
+組織黑客松活動具有多重益處,因為這類活動既能有效凝聚開發者社群,又能激發創新活力。 它還提供了實踐機會,讓參與者能夠協作並構建項目,這些項目有望為生態系統帶來切實成果。 黑客松吸引了那些通常不參加會議但熱衷於構建和測試新想法挑戰的開發者。 如果您的會議面向開發者、創新和實踐項目,舉辦黑客松是絕佳選擇。
+
+但在組織活動之前,請考慮你是否有足夠的資源和時間。 黑客松需要投入大量時間、人力和資金資源。 確保您有專門的團隊來處理此事,尤其是在您同時負責管理會議的情況下。 另外,請確認社區是否對此感興趣。 如果你的社區更側重建設者,那麼組織黑客松或許更有意義。
+
+儘管組織黑客松有諸多益處,但請注意:根據會議規模的不同,增加這項活動可能會令人應接不暇。 你應該評估同時管理兩者是否會降低其中任何一方的質量。 您可選擇舉辦規模較小、主題聚焦的黑客松,或將活動分散在不同月份舉行。
+
+### (幾乎不可避免的)你將面臨的挑戰 {#almost-inevitable-challenges-that-you-will-face}
+
+在組織會議時,尤其是以太坊領域的會議,最大的挑戰之一就是確保獲得足夠的資金。 許多活動組織者都面臨着籌集資金的困境,這些資金用於支付場地費用、餐飲服務及其他後勤開支。 贊助往往至關重要,但建立關係並說服企業投資你的活動可能需要時間。 此外,在市場低迷時期,吸引贊助商的難度可能會增加,因為企業可能不太願意投資於非核心業務。
+
+有效管理預算至關重要。 **意外開支**,例如臨時變更場地和額外的活動技術需求,可能迅速超出預算。
+
+對於新活動而言,**邀請高質量演講者尤其困難**。 以太坊領域中有名的思想領袖或意見領袖可能日程安排已滿,對於缺乏成功案例的新活動,他們可能會猶豫是否參與。 請提前做好準備,在活動開始前就投入時間進行人脈拓展,並聯繫潛在的演講嘉賓。
+
+此外,在與演講者溝通時,務必保持清晰且持續的交流——明確設定提交演示文稿的截止日期,並避免任何臨時變更。
+
+一場成功的會議需要一支專業團隊來統籌後勤保障、市場推廣、贊助商對接、技術支持及參會者管理等各項工作。 尋找具備科技活動組織經驗的人選頗具挑戰性,尤其當預算有限——或者更常見的是根本沒有預算,只能依靠志願者參與時。
+
+### 你不應該獨自做這件事。 你需要志願者們。 {#you-shouldnt-do-it-alone-you-need-volunteers}
+
+組織以太坊活動需要一支多元化且敬業的團隊來處理後勤保障、註冊管理、演講者協調、參會者支持等諸多事務。 團隊規模僅為3至15人的時候,志願者對活動的順利開展至關重要。
+
+志願者往往是許多會議的中流砥柱,提供關鍵支持,尤其是在預算有限的情況下。 他們能夠勝任從接待登記到協助活動布置的各項工作,確保活動儘可能順利進行。
+
+雖然向志願者提供金錢補償存在困難,但必須給予他們有價值的回報,使他們的付出獲得應有的回報。 考慮為他們提供人脈拓展機會、技能提升培訓、專屬福利、證書或推薦信。
+
+### 活動組織者合規要點 {#compliance-essentials-for-event-organizers}
+
+在組織活動時,有幾個重要的法律和後勤問題需要注意:
+
+- **贊助協議**——確保與贊助商簽訂明確的合同,其中應包含清晰界定的取消條款。
+- **行為準則** ——根據活動類型(會議/黑客松、黑客之家等)制定相應的行為準則。
+- **隱私政策** – 為您的網站起草隱私政策,以符合數據保護法規及圖像使用規範
+- **地方當局通知**——即使您的活動屬於封閉式聚會,也建議向當地警察局進行申報。
+- **票務協議** – 與您的票務服務提供商簽訂正式協議,以明確條款和責任。
+- **合規要求** – 提前確認會議舉辦國是否對加密貨幣行業設有特定法規或限制
+- **商品清關** – 若您需進口贊助商品,建議聘請報關行以高效完成清關流程。
+- **攝影與媒體政策** – 明確規定攝影及媒體報道的準則,確保參與者知曉同意權及退出選項。
+
+## 活動之後:接下來是什麼? {#after-the-event-whats-next}
+
+活動結束後,務必收集參會者、演講嘉賓和贊助商的反饋意見,並撰寫內部報告,以便為未來的活動做好更充分的準備。 这有助于识别哪些方面做得很好,以及哪些方面可以改进。 通過問卷調查或一對一訪談收集寶貴見解,為未來的迭代提供指導。 請務必花時間回顧任何失誤或低效環節,這些問題在下次會議中可避免,從而使流程更順暢。
+
+關鍵在於保持勢頭活躍。 繼續與社區保持互動,分享根據他們的反饋所取得的進展,並為下一場活動營造令人興奮的氛圍。 通過維持這種聯繫,確保會議的影響力超越活動本身,鞏固關係並為未來的成功奠定基礎。
+
+## 致謝{#acknowledgement}
+
+衷心感謝所有為本文貢獻見解的同仁:來自布拉迪斯拉發以太坊的斯拉沃·法比西克;來自Kipu以太坊和拉丁美洲以太坊的蘿拉;來自貝爾格萊德以太坊的坦雅·姆拉德諾維奇;來自波哥大以太坊的胡安·大衛;來自華沙以太坊的莫妮卡·扎伊奇克;來自那不勒斯以太坊的拉斐爾·奧雷菲斯;來自利雅得以太坊的肖武(玲);來自urbe.eth的馬可;來自都柏林以太坊的考蘭·沃爾什;來自克盧日以太坊的亞歷克斯·馬萊斯;以及來自斯洛文尼亞以太坊的斯坦科·德維奇。
+
+## 資源{#resources}
+
+播客:如何從頭到尾組織和推廣一場以太坊活動:
+
+- [《ETHWarsaw案例研究》,作者:不凡](https://www.youtube.com/watch?v=io2Dx1ouz8o)
+
+推特空間:
+
+- [建設ETHKL,作者:Danny H.](https://sekto.tech/ethkl24)
+
+文章:
+
+- [建設ETHKL,作者:Danny H.](https://sekto.tech/ethkl24)
+- [POKT活動指南](https://docs.pokt.network/community/pokt-events-playbook)
diff --git a/public/content/translations/zh-tw/community/get-involved/index.md b/public/content/translations/zh-tw/community/get-involved/index.md
index c609ef77ca3..bce29b9c630 100644
--- a/public/content/translations/zh-tw/community/get-involved/index.md
+++ b/public/content/translations/zh-tw/community/get-involved/index.md
@@ -1,82 +1,82 @@
---
-title: 我該如何參與?
-description: 如何加入以太坊社群
+title: 我能如何參與其中?
+description: 如何加入以太坊社群。
lang: zh-tw
---
-# 我該如何參與? {#get-involved}
+# 我能如何參與其中? {#get-involved}
以太坊社群裡包含了具有各種不同背景跟技術的人。 無論你是開發者、藝術家或是會計師,你總會找到方法參與我們的社群。 以下建議可幫助你踏出第一步。
-由閱讀[行為守則](/community/code-of-conduct)中 ethereum.org 的使命與核心價值開始。
+先閱讀我們的 [行為守則](/community/code-of-conduct),了解 ethereum.org 的使命和價值觀。
-## 程式開發人員 {#developers}
+## 開發者 {#developers}
-- 造訪 [ethereum.org/developers/](/developers/),瞭解和嘗試使用以太坊
-- 參加你附近的 [ETHGlobal](http://ethglobal.co/) 駭客松活動。
-- 留意[與你的專業領域或偏好的編程語言有關的專案](/developers/docs/programming-languages/)
-- 觀看或參與[共識層與執行層的會議](https://www.youtube.com/@EthereumProtocol/streams)
-- [以太坊生態系統支持計劃願望清單](https://esp.ethereum.foundation/wishlist/) - 以太坊生態系統支持計劃正積極尋找工具、文件和基礎設施領域的資助申請
-- [Web3Bridge](https://www.web3bridge.com/) - 加入有抱負的 Web3 社群,一起積極尋找、培訓和支持整個非洲數百名開發人員和社群成員
-- 加入[以太坊研發 Discord](https://discord.com/invite/VmG7Uxc)
-- 加入[以太坊牧貓人組織的 Discord](https://discord.com/invite/Nz6rtfJ8Cu)
+- 到 [ethereum.org/developers/](/developers/) 了解並試用以太坊
+- 參加您附近的 [ETHGlobal](http://ethglobal.co/) 黑客松!
+- 查看[與您的專業領域或偏好的程式語言相關的專案](/developers/docs/programming-languages/)
+- 觀看或參與 [共識層和執行層會議](https://www.youtube.com/@EthereumProtocol/streams)
+- [生態系統支援計畫願望清單](https://esp.ethereum.foundation/wishlist/) - 以太坊生態系統支援計畫正積極尋求工具、文件和基礎設施領域的資助申請
+- [Web3Bridge](https://www.web3bridgeafrica.com) - 加入這個充滿抱負的 web3 社群,他們致力於在整個非洲地區發掘、培訓和支援數百名開發者和社群成員
+- 加入 [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)
+- 加入 [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu)
-## 研究人員和學術工作者 {#researchers-and-academics}
+## 研究人員與學者 {#researchers-and-academics}
你有數學、虛擬貨幣或者經濟學相關的學術背景嗎? 你可能會對以太坊生態中的一些前線工作有興趣。
-- 加入[以太坊研發 Discord](https://discord.com/invite/VmG7Uxc)
+- 加入 [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)
- 撰寫或審查以太坊改進提案
- 撰寫以太坊改進提案
- 1. 將你的想法提交至[以太坊魔法師協會](https://ethereum-magicians.org)
- 2. 閱讀 [EIP-1](https://eips.ethereum.org/EIPS/eip-1) - **沒錯,就是指_整篇_文件。**
- 3. 遵照 EIP-1 中的指示, 並在寫草稿時參考指示。
- - 了解如何成為[以太坊改進提案編輯](https://eips.ethereum.org/EIPS/eip-5069)
- - 現在,你可以進行同行評審,審核其他人的以太坊改進提案! 請見[使用 `e-review` 標籤建立新提取請求](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review)。 在 `discussion-to` 連結提供技術性回饋。
- - 參與[以太坊改進提案管理體系](https://github.com/ethereum-cat-herders/EIPIP)
- - 加入[以太坊牧貓人組織的 Discord](https://discord.com/invite/Nz6rtfJ8Cu)
- - [更多以太坊改進提案相關資訊](/eips/)
-- [Challenges.ethereum.org](https://challenges.ethereum.org/) - 該網站中有一系列高回報研究賞金,你可在此賺取 $100,000 美金以上。
-- [Ethresear.ch](https://ethresear.ch) - 以太坊為研究而設的主要論壇,同時也是加密貨幣經濟學在世界上最有影響力的論壇。
-- [以太坊基金會研究線上問答](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - 由研究人員提供的問答系列。 當下階段開放時,任何人都可以提出問題。
-- [生態系統支援計劃的願望清單](https://esp.ethereum.foundation/wishlist/) - 以太坊生態系統支援計劃正在積極籌備資助申請的領域
-- [AllWalletDevs](https://allwallet.dev) - 讓以太坊開發者、設計師和有興趣的使用者,定期聚在一起並討論錢包的論壇
+ 1. 在 [Ethereum Magicians](https://ethereum-magicians.org) 上提交您的想法
+ 2. 閱讀 [EIP-1](https://eips.ethereum.org/EIPS/eip-1) - **沒錯,這就是文件的_全部_。**
+ 3. 遵循 EIP-1 中的指示。 並在寫草稿時參考指示。
+ - 了解如何成為 [EIP 編輯](https://eips.ethereum.org/EIPS/eip-5069)
+ - 現在,你可以進行同行評審,審核其他人的以太坊改進提案! 查看[帶有 `e-review` 標籤的待處理 PR](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review)。 在 `discussion-to` 連結上提供技術性回饋。
+ - 參與 [EIP 管理體系](https://github.com/ethereum-cat-herders/EIPIP)
+ - 加入 [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu)
+ - [更多關於 EIP 的資訊](/eips/)
+- [Challenges.ethereum.org](https://challenges.ethereum.org/) - 一系列高價值的研究獎勵,您可賺取超過 100,000 美元
+- [Ethresear.ch](https://ethresear.ch) - 以太坊的主要研究論壇,也是世界上最具影響力的密碼經濟學論壇
+- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - 與研究人員持續進行的問答系列。 當下階段開放時,任何人都可以提出問題。
+- [生態系統支援計畫願望清單](https://esp.ethereum.foundation/wishlist/) - 以太坊生態系統支援計畫正積極尋求資助申請的研究領域
+- [AllWalletDevs](https://allwallet.dev) - 一個供以太坊開發者、設計師和感興趣的使用者定期聚會討論錢包的論壇
[探索更多活躍的研究領域](/community/research/)。
-## 非技術性參與選項 {#non-technical}
+## 非技術技能 {#non-technical}
如果你不是程式開發人員,在以太坊中,你可能會不知道該從哪裡開始。 這裡提供了一些建議,還有一些為特定專業背景人士提供的資源。
-### 在你所在城市籌備一場聚會 {#meetups}
+### 在您所在的城市組織聚會 {#meetups}
-- 不知道從哪開始? [BUIDL 網路](https://consensys.net/developers/buidlnetwork/)幫得上忙。
+- 不知道從哪開始? [BUIDL network](https://consensys.net/developers/buidlnetwork/) 可以提供幫助。
-### 撰寫以太坊相關的內容 {#write-content}
+### 撰寫有關以太坊的內容 {#write-content}
- 以太坊需要好的作者用簡單易懂的文字讓人了解以太坊
-- 還沒準備好發表自己的文章? 可以考慮就社群資源中既有的內容進行協助,或者[提出有關 ethereum.org 的新內容建議](/contributing/)!
+- 還沒準備好發表自己的文章? 考慮為社群資源的現有內容做出貢獻,或為 [ethereum.org 提出新內容](/contributing/)!
-### 值得留意的社群招募 {#take-notes}
+### 為社群會議做筆記 {#take-notes}
-- 有很多開源的社群招募,眾多討論筆記更是一大助力。 如你對此有興趣,請加入[以太坊牧貓人組織 discord](https://discord.com/invite/Nz6rtfJ8Cu),並介紹你自己吧!
+- 有很多開源的社群招募,眾多討論筆記更是一大助力。 如果您有興趣,請加入 [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu) 並介紹自己!
-### 把以太坊的內容翻譯成自己的母語 {#translate-ethereum}
+### 將以太坊內容翻譯成您的母語 {#translate-ethereum}
- ethereum.org 一直有個翻譯計畫,將網站和其他資源翻譯成不同語言
-- 從[這裡](/contributing/translation-program)了解參加的方法
+- [在此](/contributing/translation-program)了解如何參與
-### 運行一節點 {#run-a-node}
+### 執行節點 {#run-a-node}
跟數千名節點營運者一起讓以太坊進一步去中心化。
-- [有關如何運行節點的詳細資訊](/developers/docs/nodes-and-clients/run-a-node/)
+- [更多關於如何執行節點的資訊](/developers/docs/nodes-and-clients/run-a-node/)
-### 質押你的以太幣 {#staking}
+### 質押您的 ETH {#staking}
透過質押你的以太幣來保護太坊網路並獲取酬勞。
-- [更多權益質押相關訊息。](/staking/)
+- [更多關於質押的資訊](/staking/)
### 支援專案 {#support-projects}
@@ -85,49 +85,48 @@ lang: zh-tw
- [Gitcoin](https://gitcoin.co/fund)
- [clr.fund](https://clr.fund/#/about)
-## 金融從業人員和會計師 {#financial-professionals}
+## 金融專業人士和會計師 {#financial-professionals}
-- 以太坊是「去中心化金融」生態系統的發源地 - 這是一個擁有各種協議與應用程式的網路,可以視為一種金融系統。 如果你是金融從業人員,可以到 [DeFi Llama](https://defillama.com/) 或 [DeFiPrime](https://defiprime.com) 查看我們的去中心化金融應用程式
-- 你是會計師? 以太坊的資產 - 以太幣、代幣、去中心化金融等 - 新興會計議題有很多。 你可以先查看一些旨在幫助加密貨幣使用者解決記帳問題和會計挑戰的專案計畫,例如 [Rotki](https://rotki.com/)
+- 以太坊是「去中心化金融」生態系統的發源地 - 這是一個擁有各種協議與應用程式的網路,可以視為一種金融系統。 如果您是金融專業人士,可以到 [DeFi Llama](https://defillama.com/) 或 [DeFiPrime](https://defiprime.com) 查看一些 DeFi 應用程式
+- 你是會計師? 以太坊的資產 - 以太幣、代幣、去中心化金融等 - 新興會計議題有很多。 您可以先查看一些旨在幫助加密貨幣使用者解決記帳和會計挑戰的專案,例如 [Rotki](https://rotki.com/)
-## 產品經理 {#product-managers}
+## 產品經理 {#product-managers}
-- 以太坊生態系統需要你的才華! 很多公司都在招聘產品經理。 如你想開始為開放原始碼專案作貢獻,請聯絡[以太坊牧貓人](https://discord.com/invite/Nz6rtfJ8Cu)或 [RaidGuild](https://www.raidguild.org/)
+- 以太坊生態系統需要你的才華! 很多公司都在招聘產品經理。 如果您想開始為開源專案做出貢獻,請聯繫 [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) 或 [RaidGuild](https://www.raidguild.org/)
-## 市場策劃人員 {#marketing}
+## 行銷 {#marketing}
- 以太坊生態系統內設有非常多市場策劃和溝通人員的職位!
-## 以太坊工作 {#ethereum-jobs}
+## 以太坊工作機會 {#ethereum-jobs}
-**想在以太坊尋找工作?**
+**想在以太坊找工作嗎?**
-- [ethereum.org 工作](/about/#open-jobs)
-- [以太坊基金會職缺布告欄 (Lever)](https://jobs.lever.co/ethereumfoundation)
-- [以太坊基金會職缺布告欄 (BambooHR)](https://ethereum.bamboohr.com/jobs/)
+- [ethereum.org 工作機會](/about/#open-jobs)
+- [以太坊基金會工作看板](https://jobs.ashbyhq.com/ethereum-foundation)
- [JobStash](https://jobstash.xyz)
-- [加密貨幣相關工作](https://cryptocurrencyjobs.co/ethereum/)
-- [在 ConsenSys 的職涯](https://consensys.net/careers/)
-- [加密貨幣相關工作清單](https://cryptojobslist.com/ethereum-jobs)
-- [與銀行無關的職缺布告欄](https://pallet.xyz/list/bankless/jobs)
+- [以太坊工作看板](https://www.ethereumjobboard.com/)
+- [加密貨幣工作](https://cryptocurrencyjobs.co/ethereum/)
+- [ConsenSys 職涯](https://consensys.net/careers/)
+- [加密工作清單](https://cryptojobslist.com/ethereum-jobs)
+- [Bankless 工作看板](https://pallet.xyz/list/bankless/jobs)
- [Web3 工作](https://web3.career)
- [Web3 Army](https://web3army.xyz/)
-- [加密谷工作](https://cryptovalley.jobs/)
+- [Crypto Valley 工作](https://cryptovalley.jobs/)
- [以太坊工作](https://startup.jobs/ethereum-jobs)
-## 加入去中心化自治組織 (DAO) {#decentralized-autonomous-organizations-daos}
+## 加入 DAO {#decentralized-autonomous-organizations-daos}
-「DAO」是指去中心化自治組織。 這些群體會利用以太坊技術加速整合及合作。 例如,為了控制會員,他們會針對提案進行投票,或者管理質押池內的資產。 當去中心化自治組織仍維持在試驗狀態時,他們讓你有機會去尋找你認同的群體、合作者,然後在以太坊的社群內培養你的影響力。 [更多去中心化自治組織相關資訊](/dao/)
+「DAO」是指去中心化自治組織。 這些群體會利用以太坊技術加速整合及合作。 例如,為了控制會員,他們會針對提案進行投票,或者管理質押池內的資產。 當去中心化自治組織仍維持在試驗狀態時,他們讓你有機會去尋找你認同的群體、合作者,然後在以太坊的社群內培養你的影響力。 [更多關於 DAO 的資訊](/dao/)
-- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) - _在科技界以外推廣去中心化自治組織的概念,並幫助大家透過此等組織創造價值_
-- [開發者去中心化自治組織](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) - _一個認為網際網路為集體所有的開發者社群_
-- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) - _由一些協助開發 Web3 的自由工作者所組成的去中心化自治組織_
+- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) - _在非技術領域推廣 DAO 的概念,並幫助人們透過 DAO 創造價值_
+- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) - _一個相信網際網路應為集體所有的建設者社群_
+- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) - _以 DAO 形式運作的自由工作者 Web3 開發社群_
- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) - _DAOhaus 的社群管理體系_
-- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - _法律建設_
-- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - _投資 pre-seed 輪加密貨幣專案的風投基金_
-- [MetaGame](https://metagame.wtf) [@MetaFam](https://twitter.com/MetaFam) - _現實生活的 MMORPG 遊戲機制_
-- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - _數字物理衣物品牌_
-- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) - _一個致力於為以太坊發展提供資金的社群_
-- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) - _Web3 建造者集中地_
-
-無論何時、無論以何種方式,當你為 ethereum.org 出力時,請記得遵守 ethereum.org 的[行為守則](/community/code-of-conduct)!
+- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - _法律工程_
+- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - _針對種子輪前加密專案的風險投資_
+- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - _數位實體服飾品牌_
+- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) - _專注於資助以太坊開發的社群_
+- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) - _Web3 建設者社群_
+
+無論何時、以何種方式為 ethereum.org 做出貢獻,請務必遵守 ethereum.org 的[行為守則](/community/code-of-conduct)!
diff --git a/public/content/translations/zh-tw/community/grants/index.md b/public/content/translations/zh-tw/community/grants/index.md
index 9eca6e1f49f..895bd9c8809 100644
--- a/public/content/translations/zh-tw/community/grants/index.md
+++ b/public/content/translations/zh-tw/community/grants/index.md
@@ -1,5 +1,5 @@
---
-title: 以太坊基金會和社群資助計劃
+title: 以太坊基金會與社群資助計畫
description: 一個以太坊生態系統資助計劃清單。
lang: zh-tw
---
@@ -10,38 +10,59 @@ lang: zh-tw
此列表由我們的社群策劃。 如果有任何遺漏或不正確之處,請編輯此頁面!
-## 開放的以太坊生態系統 {#broad-ethereum-ecosystem}
+
+
+創辦人們,需要協助加速您的業務嗎? [前往創辦人支援頁面](/founders/)
+
+
+## 廣泛的以太坊生態系統 {#broad-ethereum-ecosystem}
這些計劃通過向各種專案提供資助來支援開放的以太坊生態系統。 其中包括可擴展性、社群建設、安全性、隱私等方面的解決方案。 這些贈款並不專門針對任何一個以太坊平台,如果你不確定,可以從這裡開始。
-- [EF 生態系統支援計劃](https://esp.ethereum.foundation) - _資助有益於以太坊的開源專案,特別關注通用工具、基礎設施、研究和公共產品_
-- [Moloch DAO](https://www.molochdao.com/) - _隱私性、二層網路擴容、用戶端安全性等_
-- [去中心化自治組織資助計畫](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _有關資助機構的 Google 試算表_
-- [學術資助](https://esp.ethereum.foundation/academic-grants) - _支援以太坊相關學術工作的資助計劃_
-- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _Blockworks 彙編了關於所有資助計畫、提案徵集和漏洞懸賞計畫的詳盡清單。_
+- [EF 生態系統支援計畫](https://esp.ethereum.foundation) - _為有益於以太坊的開源專案提供資金,特別是通用工具、基礎設施、研究與公共財_
+- [學術補助金](https://esp.ethereum.foundation/academic-grants) - _支持以太坊相關學術研究的補助金_
+
+## 補助金清單彙總器與平台 {#grant-list-aggregators}
+
+這些資源匯總並整理了以太坊生態系統中的各種資助機會,讓你更容易發現與你專案需求匹配的金援機會。 我們已按角色類型進行分類,協助您根據具體資金需求,快速找到最相關的資源。
+
+### 給所有補助金申請者:綜合目錄 {#comprehensive-directories}
+
+這些平臺涵蓋了對整個 Web3 領域的廣泛資助資訊,對於任何尋求資金的人來説都是有用的起點:
+
+- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _Blockworks 彙整了所有補助金、提案徵求 (RFP) 和漏洞賞金的綜合目錄。_
+- [Blockchain Grants](https://www.blockchaingrants.org/) - _區塊鏈和加密貨幣補助金目錄_
+- [Karma Funding Map](https://gap.karmahq.xyz/funding-map) - 所有 Web3 補助金計畫的目錄,每週更新
+
+### 給開發者和建構者 {#for-developers-and-builders}
+
+- [補助金計畫檢視器](https://airtable.com/shr86elKgWTSCP4AY) - _補助金計畫的公開 Airtable 資料庫_
+- [Web3 Grants Spreadsheet](https://docs.google.com/spreadsheets/d/1c8koZCI-GLnD8MG-eFcXPOBCNu1v8-aXIfwAAvc7AMc/edit#gid=0) - _Web3 補助金機會的 Google 試算表_
+- [Arbitrum Grants](https://arbitrum.foundation/grants) — Arbitrum DAO 與 [The Arbitrum Foundation](https://arbitrum.foundation/)
+
+### 給 DeFi 專案和金融應用程式 {#for-defi-projects}
+
+- [LlamaoGrants](https://wiki.defillama.com/wiki/LlamaoGrants) - _DeFi Llama 的補助金計畫目錄_
+- [AlphaGrowth Grants](https://alphagrowth.io/crypto-web3-grants-list) - _加密貨幣與 Web3 補助金的綜合清單_
+- [Uniswap Foundation Grants](https://www.uniswapfoundation.org/build) - _提供給 DeFi 建構者的 Unichain 和 Uniswap v4 補助金與支援_
-## 特定專案 {#project-specific}
+### 給 DAO 貢獻者和管理體系創新者 {#for-dao-contributors}
-這些專案旨在為開發和實驗自身技術的專案獲取資助。
+面向社群驅動專案和管理體系實驗的資源:
-- [Aave 資助計劃](https://aavegrants.org/) – _[Aave](https://aave.com/) 為去中心化自治組織提供資助_
-- [Balancer](https://grants.balancer.community/) – _[Balancer](https://balancer.fi/) 生態系統基金_
-- [Chainlink 資助計劃](https://chain.link/community/grants) - _[Chainlink](https://chain.link/) 社群資助_
-- [Decentraland 資助計劃](https://governance.decentraland.org/grants/) – _[Decentraland](https://decentraland.org/) 去中心化自治組織元宇宙_
-- [Lido 生態系統資助機構 (LEGO)](https://lido.fi/lego) – _[Lido](https://lido.fi/) 金融生態系統_
-- [MetaMask 計劃](https://metamaskgrants.org/) - _[MetaMask](https://metamask.io/) 員工引導自助去中心化自治組織_
-- [SKALE 網路資助計劃](https://skale.space/developers#grants) - _[SKALE 網路](https://skale.space/)生態系統_
-- [Swarm 基金會資助計劃](https://my.ethswarm.org) - _[Swarm 基金會](https://www.ethswarm.org/)生態系統_
-- [The Graph](https://thegraph.com/ecosystem/grants/) – _[The Graph](https://thegraph.com/) 生態系統_
-- [Uniswap 資助計劃](https://www.uniswapfoundation.org/approach) – _[Uniswap](https://uniswap.org/) 社群_
+- [DAO Grants](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _提供補助金的組織之 Google 試算表_
+- [MetaGov Database](https://docs.google.com/spreadsheets/d/1e5g-dlWWsK2DZoZGBgfxyfGNSddLk-V7sLEgfPjEhbA/edit#gid=780420708) - _綜合 Web3 補助金地圖_
-## 二次融資 {#quadratic-funding}
+### 公共財與影響力 {#public-goods-and-impact}
-以太坊的開源根促進了一種有趣的新籌款模式:二次融資的成長。 這種模式可能有助於改善我們在未來為各種公共產品募資的方式。 二次融資確保獲得最多資金的是具有最獨特需求的專案。 換句話說,就是那些能夠改善大多數人生活的專案。 [關於二次融資的詳細資訊。](/defi/#quadratic-funding)
+這些專案專注於資助那些更廣泛的社群,公共物品以及更具影響力的倡議。 其中包括補助金提供者,以及利用鏈上資金分配機制 (包括[二次方募資](/defi/#quadratic-funding)) 的捐贈平台:
-- [Gitcoin](https://gitcoin.co/grants)
-- [clr.fund](https://clr.fund/)
+- [Gitcoin](https://www.gitcoin.co/program) - _Gitcoin Grants 利用多種資金分配機制,為以太坊生態系中的開源專案與公共財提供資金_
+- [Octant](https://octant.app/home) - _平衡公共利益與個人財務賦權的公共財資助生態系統_
+- [Giveth](https://giveth.io/) - _加密貨幣捐贈平台,讓公益專案能直接接收捐款,且零附加費用_
+- [Artizen](https://artizen.fund/) - _協助創作者為藝術、科學、技術與文化前沿領域的新專案進行配對募資_
+- [Quadratic Accelerator](https://qacc.giveth.io/) - _一個採用二次方募資來支持公益專案的新創加速器計畫_
## 在以太坊工作 {#work-in-ethereum}
-還沒準備好開始你自己的專案? 有數百間公司正在積極尋找對以太坊懷有熱情的人加入到以太坊生態系統的工作行列。 想了解更多資訊? [查看以太坊相關工作](/community/get-involved/#ethereum-jobs)
+還沒準備好開始你自己的專案? 有數百間公司正在積極尋找對以太坊懷有熱情的人加入到以太坊生態系統的工作行列。 想了解更多資訊? [查看以太坊相關職缺](/community/get-involved/#ethereum-jobs)
diff --git a/public/content/translations/zh-tw/community/language-resources/index.md b/public/content/translations/zh-tw/community/language-resources/index.md
index 7923de44574..22b30967e45 100644
--- a/public/content/translations/zh-tw/community/language-resources/index.md
+++ b/public/content/translations/zh-tw/community/language-resources/index.md
@@ -10,9 +10,9 @@ lang: zh-tw
我們的目標是以所有語言提供教育內容,幫助世界各地的人們克服語言障礙,成功加入以太坊社群。
-如果你更喜歡用你的母語閱讀,或你知道某人不會說英語,你可以在下面找到有用的非英語資源列表。 数十万的以太坊爱好者聚集在这些在线论坛上,分享消息、谈论最近的发展、讨论技术问题并畅想未来。
+如果你更喜歡用你的母語閱讀,或你知道某人不會說英語,你可以在下面找到有用的非英語資源列表。 數十萬的以太坊愛好者聚集在這些線上論壇上,分享消息、談論最近的發展、討論技術問題,並暢想未來。
-知道以你的語言撰寫的教育資源? [請創建議題](https://github.com/ethereum/ethereum-org-website/issues/new/choose),以將其添加到列表!
+知道以你的語言撰寫的教育資源? [提出一個議題](https://github.com/ethereum/ethereum-org-website/issues/new/choose)來將它新增至清單中!
## Ethereum.org 資源 {#ethereum-org}
@@ -20,134 +20,134 @@ Ethereum.org 已翻譯為 40 多種語言,你可以透過我們的語言選擇

-如果你會使用兩種語言,而且想幫助我們宣傳,讓更多人知道,你也可以參與 [ethereum.org 翻譯計劃](/contributing/translation-program/#translation-program),幫助我們翻譯該網站。
+如果你會使用雙語,且想幫助我們觸及更多人,你也可以參與 [ethereum.org 翻譯計畫](/contributing/translation-program/#translation-program) 並協助我們翻譯網站。
## 社群資源 {#community}
-### 巴西葡萄牙語 {#br-pt}
+### 巴西葡萄牙文 {#br-pt}
**新聞**
-- [BeinCrypto](http://www.beincrypto.com.br) - 提供有關加密貨幣的新聞和文章,包括巴西交易所列表
-- [Cointegraph](http://cointelegraph.com.br/category/analysis) - 巴西版 Cointelegraph,一個重要的加密貨幣新聞媒體機構
-- [Livecoins](http://www.livecoins.com.br/ethereum) - 提供有關加密貨幣的新聞和工具
-- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) - 提供有關加密貨幣的新聞和報告
-- [Modular Crypto](https://modularcrypto.xyz/) - 提供有關加密貨幣的新聞和教育文章
+- [BeInCrypto](http://www.beincrypto.com.br) - 加密貨幣新聞與文章,包含在巴西可用的交易所清單
+- [Cointelegraph](http://cointelegraph.com.br/category/analysis) - Cointelegraph 的巴西版本,一個主要的加密貨幣新聞媒體
+- [Livecoins](http://www.livecoins.com.br/ethereum) - 加密貨幣新聞與工具
+- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) - 加密貨幣新聞與報導
+- [Modular Crypto](https://modularcrypto.xyz/) - 加密貨幣新聞與教育文章
**教育**
-- [web3dev](https://www.web3dev.com.br/) - 向 Web3 開發者提供的內容中心和 Discord 社群。
-- [Web3Brasil](https://github.com/web3brasil/web3brasil) - 提供有關 Web3 和去中心化金融的學習資源
-- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - 提供有關加密貨幣的新聞和教育資源,包括「以太坊入門」和「去中心化金融入門」
-- [CriptoAtivos](http://www.criptoativos.wiki.br/) - 提供來自加密貨幣空間、教育和部落格的見解
-- [Cointimes](http://www.cointimes.com.br/) - 提供有關加密貨幣的新聞和教育資源
-- [Web3 starter pack](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) - 提供有關加密貨幣最常見和最基礎問題解答的指南
+- [web3dev](https://www.web3dev.com.br/) - 為 Web3 開發者提供的內容中心和 Discord 社群。
+- [Web3Brasil](https://github.com/web3brasil/web3brasil) - 學習 Web3 和 DeFi 的資源
+- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - 加密貨幣新聞與教育,包括「以太坊入門」和「DeFi 入門」
+- [CriptoAtivos](http://www.criptoativos.wiki.br/) - 來自加密貨幣領域的見解、教育內容和部落格
+- [Cointimes](http://www.cointimes.com.br/) - 加密貨幣新聞與教育
+- [Web3 starter pack](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) - 一份回答最常見和最基礎加密貨幣問題的指南
### 中文 {#zh}
**通用資源**
-- [Ethereum.cn](https://www.ethereum.cn/) - 由社群維護的網站內容,包括共識層升級、所有核心開發者會議紀錄、二層網路等
-- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - 學習從基礎到高級以太坊主題的所有知識
-- [Untimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - 由社群維護的內容,涵蓋以太坊、去中心化金融、非同質化代幣和 Web3 相關知識
-- [123ETH](https://123eth.org/) - 以太坊生態系統的入口網站
+- [Ethereum.cn](https://www.ethereum.cn/) - 由社群維護的內容,涵蓋共識層升級、所有核心開發者會議筆記、layer 2 等。
+- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - 學習從基礎到進階的各種以太坊主題
+- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - 由社群維護的內容,涵蓋以太坊、DeFi、NFT 及 Web3 相關知識
+- [123ETH](https://123eth.org/) - 以太坊生態系的入口網站
- [Zhen Xiao(肖臻)](http://zhenxiao.com/blockchain/) - 關於加密貨幣及其應用的免費線上課程
-- [以太坊白皮書](https://github.com/ethereum/wiki/wiki/[%E4%B8%AD%E6%96%87]-%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6) - 中文版以太坊白皮書
+- [以太坊白皮書](/zh/whitepaper/) - 以太坊白皮書中文版
**以太坊生態系統**
-- [ETHPlanet](https://www.ethplanet.org/) - 可上線或現場參加駭客松,為大學生提供培訓
-- [PrimitivesLane](https://www.primitiveslane.org/) - 一個以區塊鏈技術為重點的非營利研究小組
-- [以太坊中國翻譯社群](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - 一個致力於翻譯以太坊教育類內容的社群
+- [ETHPlanet](https://www.ethplanet.org/) - 線上與實體駭客松,為大學生提供培訓
+- [PrimitivesLane](https://www.primitiveslane.org/) - 一個專注於區塊鏈技術的非營利研究小組
+- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - 一個致力於翻譯以太坊教育內容的社群
**適用於開發人員**
-- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - 每週學習主流去中心化應用程式專案,並分享想法及意見的學習群組
-- [LearnBlockchain](https://learnblockchain.cn/) - 一個分享區塊鏈技術相關資訊的開發者社群
+- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - 一個學習小組,每週研究主流的去中心化應用程式專案,並分享想法與評論
+- [LearnBlockchain](https://learnblockchain.cn/) - 一個為開發者分享區塊鏈技術資訊的社群
**適用於密碼學研究人員**
-- [安比實驗室](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - 一個解釋說明密碼學和安全等內容的微信公眾號
-- [星想法](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - 一個解釋說明零知識技術的微信公眾號
+- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - 一個解釋密碼學、安全性等的微信公眾號
+- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - 一個解釋 zk 技術的微信公眾號
-### 捷克語 {#cs}
+### 捷克文 {#cs}
-- [Gwei.cz](https://gwei.cz) - 有關 Web3 的當地社群,產出教育內容、舉辦線上和線下活動
+- [Gwei.cz](https://gwei.cz) - 圍繞 Web3 的在地社群,創造教育內容,並組織線上和實體活動
- [Gwei.cz Příručka](https://prirucka.gwei.cz/) - 以太坊新手指南
-- [DAO Příručka](https://dao.gwei.cz/) - 去中心化自治組織新手指南
-- [精通以太坊](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - 捷克語版《精通以太坊》
+- [DAO Příručka](https://dao.gwei.cz/) - DAO 新手指南
+- [Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - 捷克文版的《精通以太坊》
-### 法語 {#fr}
+### 法文 {#fr}
-- [Ethereum France](https://www.ethereum-france.com/) - Ethereum France 組織各種活動、產出內容並鼓勵圍繞以太坊展開討論
-- [Ethereum.fr](https://ethereum.fr/) - 提供有關以太坊的新聞和教育資源
-- [BanklessFR](https://banklessfr.substack.com/) - Bankless 法語版新聞通訊
-- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) - 以太坊子頁面上的加密貨幣論壇
+- [Ethereum France](https://www.ethereum-france.com/) - Ethereum France 組織活動、創造內容並鼓勵圍繞以太坊的討論
+- [Ethereum.fr](https://ethereum.fr/) - 以太坊新聞與教育
+- [BanklessFR](https://banklessfr.substack.com/) - 法文版的 Bankless 電子報
+- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) - 設有以太坊子頁面的加密貨幣論壇
-### 德語 {#de}
+### 德文 {#de}
- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) - 使用 Solidity
-- [Microsoft Learn(智慧型合約)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/)- 用 Solidity 撰寫以太坊智慧型合約
-- [Microsoft Learn(以太坊網路)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/)- 連接並部署以太坊網路
-- [Microsoft Learn(區塊鏈)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/)- 進入區塊鏈開發
+- [Microsoft Learn (智慧合約)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - 使用 Solidity 撰寫以太坊智慧合約
+- [Microsoft Learn (以太坊網路)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) - 連接並部署以太坊網路
+- [Microsoft Learn (區塊鏈)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) - 區塊鏈開發入門
### 希伯來文 {#he}
-- [Udi Wertheimer - 比特幣愛好者可以從以太坊學到什麼](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/)
-- [Omer Greismen (OpenZeppelin) - 我們如何防止 150 億美元的智慧型合約遭到駭客攻擊](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/)
-- [Shy Datika (INX) - 代幣化和證券的未來,內容包括「以太坊是一種證券嗎」](https://www.cryptojungle.co.il/shy-datika-tokenization/)
-- [Roy Confino (Lemonade) - 以太坊保險](https://www.cryptojungle.co.il/roy-confino-insurance/)
+- [Udi Wertheimer - 比特幣玩家可以從以太坊學到什麼](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/)
+- [Omer Greismen (OpenZeppelin) - 我們如何防止 150 億美元的智慧合約駭客攻擊](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/)
+- [Shy Datika (INX) - 代幣化與證券的未來,包括以太坊是否為一種證券](https://www.cryptojungle.co.il/shy-datika-tokenization/)
+- [Roy Confino (Lemonade) - 以太坊上的保險](https://www.cryptojungle.co.il/roy-confino-insurance/)
- [Idan Ofrat (Fireblocks) - 機構採用](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/)
- [Gal Weizman (MetaMask) - 什麼是 MetaMask](https://www.cryptojungle.co.il/gal-weizman-metamask/)
- [Dror Aviely (Consensys) - 以太坊的中心](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/)
-- [Nir Rozin - 成為加密龐克](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/)
+- [Nir Rozin - 身為一個密碼龐克](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/)
- [Adan Kedem - 遊戲與元宇宙](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/)
- [Uri Kolodny (Starkware) - 以太坊與區塊鏈分層](https://www.cryptojungle.co.il/uri-kolodny-starkware/)
-- [Udi Wertheimer - 以太坊 2.0 與競爭對手](https://www.cryptojungle.co.il/udi-on-eth2/)
-- [Ben Samocha(本從) - 以太坊 2.0 是機會嗎?](https://www.cryptojungle.co.il/etherurm2-week-summary/)
-- [Alon Muroch (Bloxstake) - 什麼是以太坊 2.0?](https://www.cryptojungle.co.il/alon-moroch-eth2/)
-- [Eilon Aviv (Collider Ventures) - 以太坊 2.0 可能會出現哪些問題](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/)
-- [Eilon Aviv (Collider Ventures) - 為什麼我們需要以太坊 2.0](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/)
+- [Udi Wertheimer - 以太坊 2.0 vs 競爭對手](https://www.cryptojungle.co.il/udi-on-eth2/)
+- [Ben Samocha (我本人) - 以太坊 2.0 - 是個機會嗎?](https://www.cryptojungle.co.il/etherurm2-week-summary/)
+- [Alon Muroch (Bloxstaking) - 什麼是以太坊 2.0?](https://www.cryptojungle.co.il/alon-moroch-eth2/)
+- [Eilon Aviv (Collider Ventures) - 以太坊 2.0 可能會出什麼問題](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/)
+- [Eilon Aviv (Collider Ventures) - 我們為什麼需要以太坊 2.0](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/)
-### 義大利語 {#it}
+### 義大利文 {#it}
-- [Ethereum Italia](https://www.ethereum-italia.it/) - 提供以太坊教育資源、活動和新聞,專注於智慧型合約和區塊鏈技術
-- [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) - 以太坊義大利語播客
-- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - 學習使用 Solidity
-- [Microsoft Learning(智慧型合約)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/)- 學習用 Solidity 撰寫智慧型合約
-- [Microsoft Learn(去中心化應用程式)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/)- 使用去中心化應用程式建立使用者介面
+- [Ethereum Italia](https://www.ethereum-italia.it/) - 以太坊教育、活動和新聞,專注於智慧合約和區塊鏈技術
+- [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) - 義大利文的以太坊 Podcast
+- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - 學習如何使用 Solidity
+- [Microsoft Learn (智慧合約)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - 學習使用 Solidity 撰寫智慧合約
+- [Microsoft Learn (去中心化應用程式)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) - 用去中心化應用程式建立使用者介面
-### 日語 {#ja}
+### 日文 {#ja}
-- [日本網路和虛擬貨幣資產交易組織](https://jvcea.or.jp/)
-- [日本虛擬資產商業組織](https://cryptocurrency-association.org/)
-- [區塊鏈開發入門 - 學習 | 微軟文件](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - 該學習路徑將向你介紹以太坊平台上的區塊鏈和發展
-- [精通以太坊](https://www.oreilly.co.jp/books/9784873118963/) - 日語版《精通以太坊》
-- [手把手教你使用 Solidity 和以太坊制訂智慧型合約](https://www.oreilly.co.jp/books/9784873119342/) - 日語版《手把手教你使用 Solidity 和以太坊制訂智慧型合約》
+- [日本虛擬與加密資產交易協會](https://jvcea.or.jp/)
+- [日本加密資產商業協會](https://cryptocurrency-association.org/)
+- [區塊鏈開發入門 - Learn | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - 此學習路徑向您介紹區塊鏈,以及在以太坊平台上的開發。
+- [Mastering Ethereum](https://www.oreilly.co.jp/books/9784873118963/) - 日文版的《精通以太坊》
+- [使用 Solidity 與以太坊的智慧合約開發實務](https://www.oreilly.co.jp/books/9784873119342/) - 日文版的《使用 Solidity 與以太坊的智慧合約開發實務》
-### 俄語 {#ru}
+### 俄文 {#ru}
-- [Cyber Academy](https://cyberacademy.dev) -Web3 建造者的教育空間
-- [Forklog](https://forklog.com) - 有關一般加密貨幣、不同區塊鏈的現有技術和未來升級的新聞和教育文章
-- [BeInCrypto](https://ru.beincrypto.com) - 新聞、加密貨幣價格分析以及非技術文章,通俗易懂地講解有關加密貨幣的所有內容
+- [Cyber Academy](https://cyberacademy.dev) - 為 web3 建構者提供的教育空間
+- [Forklog](https://forklog.com) - 關於一般加密貨幣、現有技術和不同區塊鏈未來升級的新聞和教育文章
+- [BeInCrypto](https://ru.beincrypto.com) - 新聞、加密貨幣價格分析以及非技術性文章,用簡單的解釋說明加密貨幣的所有事情
-### 西班牙語 {#es}
+### 西班牙文 {#es}
-- [Ethereum Madrid](https://ethereummadrid.com/) - 區塊鏈、去中心化金融、管理體系課程、活動和部落格
-- [Cointegraph](https://es.cointelegraph.com/ethereum-for-beginners) - 西班牙語版《以太坊新手指南》
-- [Tutoriales online](https://tutoriales.online/curso/solidity) - 學習以太坊 Solidity 和編程
-- [Curso Introducción a Ethereum Development](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - Solidity 基礎知識,以及測試和部署你的首個智慧型合約
-- [Curso Introducción a Seguridad y Hacking en Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - 了解真實智慧型合約中常見的漏洞和安全問題
-- [去中心化金融開發課程介紹](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - 了解去中心化金融智慧型合約如何在 Solidity 中運作,並創建自己的自動化做市商應用
-- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) - 由淺入深的非技術性區塊鏈教學 學習所有有關加密貨幣和以太坊的知識。
+- [Ethereum Madrid](https://ethereummadrid.com/) - 區塊鏈、DeFi 和管理體系課程、活動與部落格
+- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) - 西班牙文版的以太坊新手指南
+- [Tutoriales online](https://tutoriales.online/curso/solidity) - 學習 Solidity 與以太坊上的程式設計
+- [以太坊開發入門課程](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - Solidity 基礎知識、測試以及部署您的第一個智慧合約
+- [以太坊安全性與駭客入門課程](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - 了解真實智慧合約中常見的漏洞和安全問題
+- [DeFi 開發入門課程](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - 學習 DeFi 智慧合約如何在 Solidity 中運作,並建立您自己的自動化做市商
+- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) - 從入門到進階的非技術性區塊鏈教育。 學習所有有關加密貨幣和以太坊的知識。
-### 土耳其語 {#tr}
+### 土耳其文 {#tr}
-- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - 專注於區塊鍊和加密貨幣的課程
-- [偉大的重命名:以太坊 2 發生了什麼?](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/)-《偉大的重命名》博文的土耳其語譯作,解釋了「以太坊 2」術語的變化
+- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - 專注於區塊鏈與加密貨幣的課程
+- [大更名:Eth2 發生了什麼事?](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) - 「大更名」部落格文章的土耳其文翻譯,解釋了為何不再使用「Eth2」術語
-### 越南語 {#vi}
+### 越南文 {#vi}
-- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - 以太坊、去中心化應用程式、錢包和常見問題的概述
-- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - 以太坊新聞和教育子頁面的網頁平台
+- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - 以太坊、去中心化應用程式、錢包與常見問題概覽
+- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - 設有以太坊新聞與教育子頁面的網路平台
- [Coin68](https://coin68.com/ethereum-tieu-diem/) - 提供以太坊新聞和教育內容的加密貨幣入口網站
diff --git a/public/content/translations/zh-tw/community/online/index.md b/public/content/translations/zh-tw/community/online/index.md
index 207f5b41a6a..65c730699b4 100644
--- a/public/content/translations/zh-tw/community/online/index.md
+++ b/public/content/translations/zh-tw/community/online/index.md
@@ -1,6 +1,6 @@
---
title: 線上社群
-description: 一個關於以太坊生態系統的贈款計劃清單
+description: 探索以太坊愛好者聚集討論與協作的線上論壇、聊天室和社群媒體社群。
lang: zh-tw
---
@@ -14,8 +14,8 @@ lang: zh-tw
### 資格標準 {#eligibility-criteria}
-- **相關性**:該社群必須與以太坊及其生態系統直接相關。
-- **活躍程度**:該社群應該保持活躍,有定期的互動、發帖或討論。 休眠或不活躍的社群可能會被移除。
+- **相關性**:社群必須與以太坊及其生態系統直接相關。
+- **活躍程度**:社群應保持活躍,並有定期的互動、貼文或討論。 休眠或不活躍的社群可能會被移除。
- **包容性**:該社群應該建立一種尊重多元化、鼓勵不同背景人士參與的友善環境。
- **非商業性質**:清單旨在收錄社群主導的空間,而非商業或促銷平台。
@@ -27,49 +27,29 @@ lang: zh-tw
### 其他建議 {#other-recommendations}
-- **可訪問性**:社群論壇應該讓所有人都能閱讀內容,毋須註冊或登入。
-- **Discord 伺服器邀請**:建議只將可靠的 Discord 伺服器邀請加入到 ethereum.org。 理想情況下,這些邀請應連接到網站上的社群頁面(如 [ethglobal.com/discord](https://ethglobal.com/discord))或來自官方網址(如 [discord.gg/ethstaker](https://discord.gg/ethstaker) 或 [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker))。
-
-如果您認為根據這些準則應該新增或移除某個社群,請[在我們的 GitHub 存儲庫開一個新議題](https://github.com/ethereum/ethereum-org-website/issues)。
+- **可及性**:社群論壇應開放給所有人閱讀,不需註冊或登記。
+- **Discord 伺服器邀請**:建議只將可靠的 Discord 伺服器邀請新增至 ethereum.org。 理想情況下,這些邀請應連結至網站上的社群頁面 (例如:[ethglobal.com/discord](https://ethglobal.com/discord)),或是來自官方 URL (例如:[discord.gg/ethstaker](https://discord.gg/ethstaker) 或 [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker))。
+如果您認為根據這些準則,應新增或移除某個社群,請[在我們的 GitHub 存放庫開啟一個 issue](https://github.com/ethereum/ethereum-org-website/issues)。
## 論壇 {#forums}
-r/ethereum - 所有有關以太坊的話題
-r/ethfinance - 以太坊中有關金融的主題,其中包含去中心化金融
-r/ethdev - 專注於以太坊的開發
-r/ethtrader - 趨勢及市場分析
-r/ethstaker - 歡迎所有對在以太坊上質押感興趣的人
-以太坊魔法師獎學金 - 以以太坊技術標準為中心的社群
-以太坊 Stackexchange - 以太坊開發者討論及協助
-以太坊研究 - 最具影響力的加密經濟研究留言板
+r/ethereum - 所有關於以太坊的事物 r/ethfinance - 以太坊的金融面,包含 DeFi r/ethdev - 專注於以太坊開發 r/ethtrader - 趨勢與市場分析 r/ethstaker - 歡迎所有對在以太坊上進行質押感興趣的人 Fellowship of Ethereum Magicians - 以以太坊技術標準為核心的社群 Ethereum Stackexchange - 為以太坊開發者提供討論與幫助 Ethereum Research - 最具影響力的密碼經濟學研究論壇
## 聊天室 {#chat-rooms}
-以太牧貓人組織 - 提供專案管理以支援以太坊的社群
-以太坊駭客 - 由全球以太坊駭客線上社群 ETHGlobal 所管理的 Discord 聊天室
-CryptoDevs - 專注於以太坊開發的 Discord 社群
-EthStaker Discord - 給現有及潛在質押者的社群營運指導、教育、支援及資源。
-Ethereum.org 網站團隊 - 訪問並和團隊及社群大眾聊聊 Ethereum.org 網站開發及設計
-Matos Discord - 建造者、產業領袖,及以太坊愛好者出沒的 web3 創作者社群。 我們熱愛 web3 開發、設計及文化。 與我們一起建立。
-Solidity Gitter - 討論 solidity 的開發 (Gitter)
-Solidity Matrix - 討論 solidity 的開發 (Matrix)
-以太坊技術堆棧交易所 *- 問答論壇*
-Peeranha *- 去中心化問答論壇*
+Ethereum Cat Herders - 為以太坊開發提供專案管理支援的社群 Ethereum Hackers - 由 ETHGlobal 經營的 Discord 聊天室:一個為全球以太坊駭客打造的線上社群 CryptoDevs - 專注於以太坊開發的 Discord 社群 EthStaker Discord - 為現有和潛在質押者提供由社群經營的指導、教育、支援和資源 Ethereum.org 網站團隊 - 來和團隊及社群成員聊聊 ethereum.org 的網站開發和設計吧 Matos Discord - Web3 創作者社群,是開發者、產業領袖和以太坊愛好者的聚集地。 我們熱愛 web3 開發、設計及文化。 來和我們一起開發吧。 Solidity Gitter - Solidity 開發聊天室 (Gitter) Solidity Matrix - Solidity 開發聊天室 (Matrix) Ethereum Stack Exchange - 問答論壇 Peera Community Forum - 去中心化問答論壇
-## YouTube 和 Twitter {#youtube-and-twitter}
+## YouTube 與 X (前身為 Twitter) {#youtube-and-twitter}
-以太坊基金會 - 掌握以太坊基金會最新的資訊
-@ethereum - 以太坊基金會的官方帳戶
-@ethdotorg - 以太坊的入口網站,為我們成長中的全球社群而建
-具影響力的以太坊推特帳戶清單
+以太坊基金會 - 掌握以太坊基金會的最新資訊 @ethereum - 以太坊社群的主要帳戶 @ethereumfndn - 以太坊基金會的官方帳戶 @ethdotorg - 通往以太坊的入口網站,為我們日益壯大的全球社群而打造
- 了解更多關於去中心化自治組織的資訊
+ 深入了解 DAO
diff --git a/public/content/translations/zh-tw/community/research/index.md b/public/content/translations/zh-tw/community/research/index.md
index 47fbc123f21..c9992e43662 100644
--- a/public/content/translations/zh-tw/community/research/index.md
+++ b/public/content/translations/zh-tw/community/research/index.md
@@ -57,7 +57,7 @@ lang: zh-tw
- 發展輕量用戶端支援;
- 研究燃料限制;
-- 以及與新資料結構的相容性(如沃克爾樹)。
+- 並納入新的資料結構(例如沃克爾樹)。
#### 背景介紹讀物 {#background-reading-1}
@@ -377,7 +377,7 @@ lang: zh-tw
- [Wormhole 漏洞報告](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/)
- [遭駭以太坊合約事後分析列表](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191)
-- [Rekt 新聞](https://twitter.com/RektHQ?s=20&t=3otjYQdM9Bqk8k3n1a1Adg)
+- [Rekt 新聞](https://x.com/RektHQ?s=20&t=3otjYQdM9Bqk8k3n1a1Adg)
#### 近期研究 {#recent-research-19}
diff --git a/public/content/translations/zh-tw/community/support/index.md b/public/content/translations/zh-tw/community/support/index.md
index f58cb2121df..8512757c62e 100644
--- a/public/content/translations/zh-tw/community/support/index.md
+++ b/public/content/translations/zh-tw/community/support/index.md
@@ -6,25 +6,25 @@ lang: zh-tw
# 以太坊支援 {#support}
-## 官方提供的以太坊支援 {#official-support}
+## 以太坊官方支援 {#official-support}
你正在尋找官方的以太坊支援嗎? 第一件你應該知道的事情是以太坊為去中心化。 這代表沒有中心組織、實體或個體會持有以太坊,也因此沒有官方支援頻道。
-了解以太坊的去中心化本質非常重要,因為**任何聲稱是以太坊官方支援的人都可能是想詐騙你!**對抗詐騙者的最佳防護,就是自學並認真看待安全問題。
+了解以太坊的去中心化本質非常重要,因為\*\*任何聲稱是以太坊官方支援的人都可能是想詐騙你!\*\*對抗詐騙者的最佳防護,就是自學並認真看待安全問題。
- 以太坊安全及詐騙預防
+ 以太坊安全性及詐騙防範
學習以太坊基礎知識
-儘管欠缺官方支援,很多以太坊生態系統上的團體、社群和專案都很樂意提供協助。你也能夠在此頁面找到很多有用的資訊及資源。 仍有疑問? 加入 [ethereum.org discord](https://discord.gg/ethereum-org),我們會嘗試提供幫助。
+儘管欠缺官方支援,很多以太坊生態系統上的團體、社群和專案都很樂意提供協助。你也能夠在此頁面找到很多有用的資訊及資源。 仍有疑問? 加入 [ethereum.org Discord](https://discord.gg/ethereum-org),我們會嘗試提供幫助。
## 常見問題 {#faq}
-### 我將以太幣傳送到了錯誤的錢包 {#wrong-wallet}
+### 我將 ETH 傳送到了錯誤的錢包 {#wrong-wallet}
在以太坊進行的傳送不可還原。 不幸的是,如你已經將以太幣傳送至錯的錢包,便無法追回這些資金。 沒有中心組織、實體或個體持有以太坊,這代表沒有人能夠逆轉交易。 因此,在傳送交易前請務必進行雙重核查。
@@ -32,37 +32,37 @@ lang: zh-tw
以太坊贈品是為了偷取你持有的以太幣而設計的騙局。 不要被一些高得不真實的回報率給欺騙 - 如果你將以太幣傳送至一個贈品地址,你將不會收到申領的贈品,而且你也不能索要賠償。
-[有關防止詐騙的詳細資訊](/security/#common-scams)
+[更多關於詐騙防範的資訊](/security/#common-scams)
### 我的交易卡住了 {#stuck-transaction}
如果你提交了一個低於所需的交易費,由於網路需求,你在以太坊上的交易有時可能會卡住。 很多錢包都會提供一個選項,重新用較高的手續費去提交同一筆交易,讓交易能夠順利進行。 另外,你還可以取消正在等待處理的交易。該動作能將一筆交易傳送到你持有的地址,然後使用與待處理交易相同的隨機數繼續。
-[怎樣在 MetaMask 加速或者取消待完成交易](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction)
+[如何在 MetaMask 上加速或取消待處理的交易](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction)
-[怎樣取消待完成的以太坊交易](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/)
+[如何取消待處理的以太坊交易](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/)
-### 如何在以太坊挖礦? {#mining-ethereum}
+### 如何在以太坊挖礦? 挖礦以太坊 {#mining-ethereum}
-以太坊挖礦已不再可能。 當以太坊由[工作量證明](/glossary/#pow)過渡為[權益證明](/glossary/#pos)時,挖礦就已終止。 現在以太坊沒有礦工了,取而代之的是驗證者。 任何人都可以[質押](/glossary/#staking)以太幣,並透過執行驗證者軟體來保護網路,以獲得質押獎勵。
+以太坊挖礦已不再可能。 當以太坊從 [工作量證明](/glossary/#pow) 轉移至 [權益證明](/glossary/#pos) 時,挖礦活動就停止了。 現在以太坊沒有礦工了,取而代之的是驗證者。 任何人都可以 [質押](/glossary/#staking) ETH 並執行驗證者軟體保護網路,以獲得質押獎勵。
### 如何成為質押者/執行驗證者? {#how-to-stake}
-要成為驗證者,你必須在以太坊存款合約質押至少 32 個以太幣並設定驗證者節點。 更多資訊可以參考我們的[質押頁面](/staking)和[質押啟動面板](https://launchpad.ethereum.org/)。
+要成為驗證者,你必須在以太坊存款合約質押至少 32 個以太幣並設定驗證者節點。 更多資訊可以參考我們的 [質押頁面](/staking) 和 [質押啟動面板](https://launchpad.ethereum.org/)。
-## 開發去中心化應用程式 {#building-support}
+## 建構去中心化應用程式 {#building-support}
開發可能很難, 但一些專注於開發的空間上有樂意提供幫助,且經驗豐富的以太坊開發者。
-- [Alchemy University](https://university.alchemy.com/#starter_code)
+- [Alchemy 大學](https://university.alchemy.com/#starter_code)
- [CryptoDevs discord](https://discord.com/invite/5W5tVb3)
-- [Ethereum StackExchange](https://ethereum.stackexchange.com/)
-- [Web3 University](https://www.web3.university/)
+- [以太坊 StackExchange](https://ethereum.stackexchange.com/)
+- [Web3 大學](https://www.web3.university/)
- [LearnWeb3](https://discord.com/invite/learnweb3)
-你也可以在我們的[以太坊開發者資源](/developers/)部分找到文件和開發指南。
+你也可以在我們的 [以太坊開發者資源](/developers/) 專區中找到文件和開發指南。
-### 模組化 {#dapp-tooling}
+### 工具 {#dapp-tooling}
你的問題跟某個特定的質押池、專案或庫相關嗎? 多數專案都有專門為你提供支援的聊天伺服器或論壇。
@@ -71,11 +71,11 @@ lang: zh-tw
- [Solidity](https://gitter.im/ethereum/solidity)
- [ethers.js](https://discord.gg/6jyGVDK6Jx)
- [web3.js](https://discord.gg/GsABYQu4sC)
-- [安全帽](https://discord.gg/xtrMGhmbfZ)
+- [Hardhat](https://discord.gg/xtrMGhmbfZ)
- [Alchemy](http://alchemy.com/discord)
- [Tenderly](https://discord.gg/fBvDJYR)
-## 運行節點 {#node-support}
+## 執行節點 {#node-support}
如果你要運行一個節點或者驗證程式,有一些專門的社群可幫助你開始。
@@ -101,4 +101,4 @@ lang: zh-tw
- [Lodestar](https://discord.gg/aMxzVcr)
- [Grandine](https://discord.gg/H9XCdUSyZd)
-你也可以[在此學習如何運行節點](/developers/docs/nodes-and-clients/run-a-node/)。
+你也可以在 [這裡了解如何執行節點](/developers/docs/nodes-and-clients/run-a-node/)。
diff --git a/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md b/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md
index 7a4decec4da..1e5294fe633 100644
--- a/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md
@@ -15,30 +15,30 @@ lang: zh-tw
### 納入標準:必備條件 {#the-must-haves}
- **開源程式碼/資料** - 開放的程式碼和資料是去中心化科研的核心原則,因此去中心化科研專案不得閉源。 程式碼庫應該是可存取的,並且最好對拉取請求開放。
-- **DeSci 專案應明顯去中心化** - 這可能包括由去中心化自治組織 (DAO) 管理,或透過使用包括非託管錢包在內的去中心化技術堆疊進行建置。 它可能涉及以太坊上的可審核智慧型合約。
-- **上架資訊真實準確** - 專案的任何提議上架產品都應包含真實準確的資訊。 如果偽造產品的上架資訊,例如聲稱產品為「開源」產品但事實並非如此,該產品將被移除。
-- **擴大科學普及的明確承諾** - 去中心化科研專案應該能夠闡明它們如何擴大公眾對科學的參與,而不僅僅包括代幣/非同質化代幣持有者。
-- **全球皆可存取** - 你的專案沒有地域限製或身分驗證 (KYC) 要求,以免某些人無法存取你的服務。
-- **資訊豐富的網站和文件** - 讓專案網站的訪客能夠了解該專案的實際用途、如何為去中心化科學基礎設施做出貢獻以及如何參與,這些都非常重要。
-- **專案應該是以太坊生態系統一部分** - 在 ethereum.org,我們相信以太坊(及其二層網路)是去中心化科研運動的合適基礎層。
-- **專案已相當完善** - 該專案擁有真實使用者,在幾個月中都能夠存取該專案服務。
+- **DeSci 專案應可證明為去中心化** - 這可包括由 DAO 治理,或透過包含非託管錢包在內的去中心化技術堆疊來建置。 它可能涉及以太坊上的可審核智慧型合約。
+- **誠實準確的上架資訊** - 專案建議的任何上架資訊,都應提供誠實準確的內容。 如果偽造產品的上架資訊,例如聲稱產品為「開源」產品但事實並非如此,該產品將被移除。
+- **可證明致力於擴大科學的近用性** - DeSci 專案應能闡明其如何擴大一般大眾對科學的參與,而不僅限於代幣/NFT 持有者。
+- **全球可存取** - 您的專案不應有地域限制或 KYC 要求,以免排除特定人士存取您的服務。
+- **資訊豐富的網站和文件** - 專案網站的訪客能夠了解該專案的實際用途、如何為去中心化科學基礎設施做出貢獻以及如何參與,這些都非常重要。
+- **專案應是以太坊生態系統的一部分** - 在 ethereum.org,我們相信以太坊 (及其 Layer 2) 是去中心化科研運動的合適基礎層。
+- **專案已建立良好基礎** - 該專案擁有真實使用者,且他們已能存取專案服務達數月之久。
### 加分項
-- **支援多種語言** - 你的專案已經翻譯成多種語言,全球使用者皆可存取。
-- **教育資源/文件** - 你的產品應具有精心設計的入門體驗,以幫助和教育使用者。 或有介紹操作方法的內容,例如文章或影片。
-- **第三方審核** - 你的產品已經由可靠第三方進行了專業的漏洞審核。
-- **聯絡人** - 實施變更時,專案聯絡人(可能是去中心化自治組織或社群的代表)將大力幫助我們獲得準確資訊。 這樣將在日後收集資訊時,確保 ethereum.org 的更新可控。
+- **支援多種語言** - 您的專案已翻譯成多種語言,讓世界各地的使用者都能存取。
+- **教育資源** - 您的產品應具有精心設計的入門體驗,以協助和教育使用者。 或有介紹操作方法的內容,例如文章或影片。
+- **第三方審核** - 您的產品已由可信的第三方,就漏洞方面進行專業審核。
+- **聯絡點** - 專案的聯絡點(可能是 DAO 或社群的代表)將能在進行變更時,大力協助我們取得準確的資訊。 這樣將在日後收集資訊時,確保 ethereum.org 的更新可控。
-## 維護 {#maintenance}
+## 維護{#maintenance}
由於以太坊的流動性,團隊和產品來來去去,每天都有創新,所以我們將對我們的內容進行例行檢查,以便:
- 確保列出的所有專案仍符合我們的標準
- 驗證建議的產品不比目前列出的產品更符合我們的標準
-Ethereum.org 由開源社群維護,我們依靠社群來助其保持最新狀態。 如果你發現所列專案有任何資訊需要更新,請在我們的 GitHub 存放庫上建立一個議題或拉取請求。
+Ethereum.org 由開源社群維護,我們仰賴社群協助,以維持其內容的更新。 如果你發現所列專案有任何資訊需要更新,請在我們的 GitHub 存放庫上建立一個議題或拉取請求。
## 使用條款 {#terms-of-use}
-另請參閱我們的[使用條款](/terms-of-use/)。 ethereum.org 上的資訊僅供一般參考。
+另請參閱我們的 [使用條款](/terms-of-use/)。 ethereum.org 上的資訊僅供一般參考。
diff --git a/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md b/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md
index df281f40858..8b06b5f5d6a 100644
--- a/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md
@@ -10,11 +10,11 @@ description: 我們在 ethereum.org 上架開發者工具的標準
如果我們遺漏了某個實用的開發者工具,請你在合適的地方提出建議。
-我們目前在我們的[開發者門戶](/developers/)中上架開發者工具。
+我們目前在我們的 [開發者門戶](/developers/) 中上架了開發者工具。
-**請隨時去適當的頁面提出新增工具。**
+**歡迎隨時在適當的頁面建議新增工具。**
-## 我們怎樣決定的 {#ways-to-contribute}
+## 我們的決策方式 {#ways-to-contribute}
提交的開發者工具將按照以下標準進行評估:
@@ -40,19 +40,19 @@ description: 我們在 ethereum.org 上架開發者工具的標準
- 工具是否可靠?
- 工具是否得到積極維護?
-**工具是否開源?**
+**該工具是否為開放原始碼?**
以太坊領域的許多專案都是開源的。 我們更有可能上架開源專案,讓社群開發者能夠檢查程式碼並為此做出貢獻。
---
-## 產品次序 {#product-ordering}
+## 產品訂購{#product-ordering}
除非指定產品以特定順序排列,如按照英文字母順序,否則將按照最早至最晚新增到頁面的順序顯示。 換句話說,最新的產品會被新增到清單的底部。
---
-## 新增你的開發者工具 {#how-decisions-about-the-site-are-made}
+## 新增您的開發者工具 {#how-decisions-about-the-site-are-made}
如果你想為 ethereum.org 新增開發者工具並且該工具符合條件,請在 GitHub 上建立一個議題。
diff --git a/public/content/translations/zh-tw/contributing/adding-exchanges/index.md b/public/content/translations/zh-tw/contributing/adding-exchanges/index.md
index 520e047f8a3..04e3860c498 100644
--- a/public/content/translations/zh-tw/contributing/adding-exchanges/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-exchanges/index.md
@@ -16,25 +16,25 @@ lang: zh-tw
鑑於此類情況,當你建議交易所時我們需要一些具體資訊。
-**注意:**如果你想列出去中心化交易所,請查看我們的[錢包和去中心化應用程式上架政策](/contributing/adding-products/)。
+\*\*注意:\*\*如果您想上架去中心化交易所,請參閱我們的[錢包和去中心化應用程式上架政策](/contributing/adding-products/)。
-## 我們需要的資訊 {#what-we-need}
+## 我們需要哪些資訊 {#what-we-need}
- 適用於交易所的地域限制。 與交易所相關的地域限制應在交易所網站的專門頁面詳細說明。
- 使用者可以用來購買以太幣的貨幣
- 證明該交易所是合法營運的公司的證據
- 你可能擁有的任何額外資訊 - 這可能是有關公司的信息,例如經營年限、財務支持等。
-我們需要這些資訊,以便我們精準[幫助使用者找到他們可以使用的交易所](/get-eth/#country-picker),
+我們需要這些資訊,以便我們能準確地[幫助使用者找到他們可以使用的交易所](/get-eth/#country-picker)。
這樣 ethereum.org 也能夠更加確保交易所可以提供合法且安全的兌換服務。
---
-## 新增你的交易所 {#add-exchange}
+## 新增您的交易所 {#add-exchange}
如果你想向 ethereum.org 新增交易所,請在 GitHub 上建立一個議題。
- 建立一個議題
+提交一個議題
diff --git a/public/content/translations/zh-tw/contributing/adding-glossary-terms/index.md b/public/content/translations/zh-tw/contributing/adding-glossary-terms/index.md
index f69ed7c6175..de146cba38c 100644
--- a/public/content/translations/zh-tw/contributing/adding-glossary-terms/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-glossary-terms/index.md
@@ -4,11 +4,11 @@ lang: zh-tw
description: 我們在 ethereum.org 詞彙表增加新術語的標準
---
-# 增加術語表 {#contributing-to-ethereumorg-}
+# 新增詞彙表術語 {#contributing-to-ethereumorg-}
以太坊的世界日新月異。 以太坊使用者需要不斷應對層出不窮的新術語,因此我們需要你幫助我們提供最準確、最新的參照。 查看目前的[詞彙表](/glossary/),如果你想做出貢獻,請參考下列內容!
-## 標準 {#criteria}
+## 標準
新的詞彙表術語將按照以下標準進行評估:
@@ -17,10 +17,10 @@ description: 我們在 ethereum.org 詞彙表增加新術語的標準
- 這個術語/定義是否不涉及產品廣告或其他的宣傳內容?
- 這個術語/定義是否與以太坊直接相關?
- 這個定義是否客觀、準確、並且不包含主觀的判斷和意見?
-- 資料來源是否可信? 資料來源是否有引用相應的出處?
+- 資料來源是否可信? 他們會引用文本出處麼?
---
## 新增你的術語 {#how-decisions-about-the-site-are-made}
-如果你想新增符合以上標準的術語到 ethereum.org,[請在 GitHub 上建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml)。
+如果你想將詞彙表術語新增至 ethereum.org 且該術語符合標準,請[在 GitHub 上建立 issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml)。
diff --git a/public/content/translations/zh-tw/contributing/adding-layer-2s/index.md b/public/content/translations/zh-tw/contributing/adding-layer-2s/index.md
index 3e476220719..52f13f40c08 100644
--- a/public/content/translations/zh-tw/contributing/adding-layer-2s/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-layer-2s/index.md
@@ -4,28 +4,28 @@ description: 向 ethereum.org 新增二層網路時使用的政策
lang: zh-tw
---
-# 新增二層網路 {#adding-layer-2}
+# 新增 Layer 2 {#adding-layer-2}
我們想確保上架最佳的資源,讓使用者能夠以安全放心的方式瀏覽二層網路空間。
-任何人都可以建議在 ethereum.org 上新增二層網路。 如我們有遺漏二層網絡,**[請提出建議](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!**
+任何人都可以建議在 ethereum.org 上新增二層網路。 如果我們遺漏了任何 Layer 2,**[請建議我們](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!**
我們目前在以下頁面上架二層網路:
-- [Optimistic rollup (樂觀卷軸)](/developers/docs/scaling/optimistic-rollups/)
-- [ZK零知識證明卷軸](/developers/docs/scaling/zk-rollups/)
-- [層二(Layer 2)](/layer-2/)
+- [樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)
+- [零知識卷軸](/developers/docs/scaling/zk-rollups/)
+- [Layer 2](/layer-2/)
二層網路是以太坊相對較新且令人興奮的範式。 我們嘗試在 ethereum.org 上創建一個公平的考量框架,但納入標準會隨時間推移而變化和發展。
-## 決策框架 {#decision-framework}
+## 決策框架
-### 納入標準:必備條件 {#criteria-for-inclusion-the-must-haves}
+### 收錄標準:必要條件 {#criteria-for-inclusion-the-must-haves}
**在 L2BEAT 上架**
-- 要被納入考量範圍,專案必須已在 [L2BEAT](https://l2beat.com) 上架。 L2BEAT 為二層網路專案提供了可靠的風險評估,供我們評估二層網路專案。 **如果專案未在 L2BEAT 上架,我們不會在 ethereum.org 上將其作為二層網路上架。**
-- [了解如何將二層網路專案新增到 L2BEAT](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md)。
+- 若要納入考量,此專案必須已列於 [L2BEAT](https://l2beat.com)。 L2BEAT 為二層網路專案提供了可靠的風險評估,供我們評估二層網路專案。 **如果專案未在 L2BEAT 上架,我們不會將其以 L2 的形式列在 ethereum.org。**
+- [了解如何將您的 L2 專案新增至 L2BEAT](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md)。
**開源**
@@ -38,11 +38,11 @@ lang: zh-tw
- 樂觀卷軸
- 零知識卷軸
-_我們認為,其他不使用以太坊來實現資料可用性或安全性的擴張解決方案,不是二層網路。_
+_我們不認為其他不使用以太坊來提供資料可用性或安全性的擴展解決方案是 Layer 2。_
**以太坊的資料可用性**
-- 資料可用性是其他擴張方案與二層網路方案之間的重要區分因素。 一個專案**必須**使用以太坊主網來實現資料可用性,才能考慮讓其上架。
+- 資料可用性是其他擴張方案與二層網路方案之間的重要區分因素。 專案**必須**使用以太坊主網來提供資料可用性,才能考慮列入清單。
**跨鏈橋**
@@ -56,7 +56,7 @@ _我們認為,其他不使用以太坊來實現資料可用性或安全性的
**外部安全審核**
-- 無論是透過審核、內部安全團隊或其他方法,你的產品安全性都必須經可靠測試。 對我們的用戶而言,這會減低相關風險,並且向我們顯示出你有認真思考產品安全的問題。
+- 無論是透過審核、內部安全團隊或其他方法,你的產品安全性都必須經可靠測試。 這將降低我們的使用者面臨的風險,並向我們表明你非常重視安全性。
**持續的使用者群**
@@ -88,10 +88,10 @@ _我們認為,其他不使用以太坊來實現資料可用性或安全性的
- 是否有任何錢包原生支援二層網路?
-## 新增你的二層網絡 {#add-exchange}
+## 新增您的 Layer 2 {#add-exchange}
如果你想在 ethereum.org 上新增二層網路層,請在 GitHub 上建立議題。
- 建立一個議題
+提交一個議題
diff --git a/public/content/translations/zh-tw/contributing/adding-products/index.md b/public/content/translations/zh-tw/contributing/adding-products/index.md
index c9c52d354a0..bd694d3fab6 100644
--- a/public/content/translations/zh-tw/contributing/adding-products/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-products/index.md
@@ -13,15 +13,15 @@ lang: zh-tw
- ethereum.org/dapps
- ethereum.org/get-eth
-**請僅在上列頁面上建議新增新的去中心化應用程式。**
+**請僅在這些頁面上建議新增內容。**
雖然我們歡迎新增新的去中心化應用程式,但目前我們以我們努力為使用者創造的使用體驗為基準來選擇去中心化應用程式。 此使用體驗基於下方一些設計原則:
-- _具啟發性_:ethereum.org 上的任何事物都應該讓使用者耳目一新
-- _好故事_:列出的內容應該讓人感到驚嘆
-- _可信_:所有業務/專案都應該是合法的,以最大程度降低使用者面臨的風險
+- _具啟發性:ethereum.org 上的任何事物都應該讓使用者耳目一新
+- _好故事:列出的內容應該讓人感到驚嘆
+- _可信:所有業務/專案都應該是合法的,以最大程度降低使用者面臨的風險
-整體而言,**ethereum.org 想為新的使用者提供「無縫加入體驗」**。 為此,我們會根據下列條件來新增去中心化應用程式:
+總體而言,**ethereum.org 希望為新使用者提供「無縫的入門體驗」**。 為此,我們會根據下列條件來新增去中心化應用程式:
- 方便使用
- 與其他產品的互通性
@@ -30,30 +30,30 @@ lang: zh-tw
以下是關於我們決策框架的更詳細資訊。 請隨時提供意見回饋或更改建議。
-## 決策框架 {#decision-framework}
+## 決策框架
-### 納入標準:必備條件 {#criteria-for-inclusion-the-must-haves}
+### 收錄標準:必要條件 {#criteria-for-inclusion-the-must-haves}
-- **產品通過安全測試** — 無論是透過審核、內部安全團隊或某些其他方法,你的產品安全必須通過可靠測試。 這將降低我們的使用者面臨的風險,並向我們表明你非常重視安全性。
-- **產品已「上線」超過 6 個月** — 這是產品安全性的另一個指標。 6 個月是發現嚴重錯誤和漏洞的最佳時間窗口。
-- **由活躍的團隊開發** — 這有助於確保品質,並讓使用者的查詢得到支援。
-- **上架資訊真實準確** — 專案的任何提議上架產品都應包含真實準確的資訊。 如果偽造產品的上架資訊,例如聲稱產品為「開源」產品但事實並非如此,該產品將被移除。
+- **經過安全性測試的產品**——無論是透過稽核、內部安全團隊或其他方法,您的產品都必須經過可靠的安全性測試。 這將降低我們的使用者面臨的風險,並向我們表明你非常重視安全性。
+- **產品已「上線」超過 6 個月**——這是安全性的另一個指標。 6 個月是發現嚴重錯誤和漏洞的最佳時間窗口。
+- **由活躍團隊維護**——這有助於確保品質,並讓使用者在查詢時獲得支援。
+- **誠實準確的上架資訊**——我們期望所有專案提交的上架建議,皆能提供誠實準確的資訊。 如果偽造產品的上架資訊,例如聲稱產品為「開源」產品但事實並非如此,該產品將被移除。
-### 排名標準:加分項 {#criteria-for-ranking-the-nice-to-haves}
+### 排名標準:加分條件 {#criteria-for-ranking-the-nice-to-haves}
你的去中心化應用程式或因以下標準,未能像其他產品一樣在 ethereum.org 顯眼地方列出。
**去中心化應用程式**
-- **可以透過大多數上架的錢包存取** - 去中心化應用程式應該與 ethereum.org 上架的大多數錢包相容。
-- **使用者可以自行試用 –** 個人使用者應該能夠使用你的去中心化應用程式並執行一些實際操作。
-- **入門培訓** - 你的產品應具有精心設計的入門體驗,以幫助和教育使用者。 或有介紹操作方法的內容,例如文章或影片。
-- **非託管模式** – 使用者可以控制自己的資金。 如果你的產品消失,使用者仍然可以存取和轉移他們的資金。
-- **全球皆可存取** – 你的產品沒有地域限製或身分驗證 (KYC) 要求,以免某些人無法存取你的服務。
-- **開源** – 你的程式碼應該易於存取,並應接受來自更廣泛社群的拉取請求 (PR)。
-- **社群** – 你有一個專門社群,例如 Discord,使用者可以在其中與你的團隊互動,以獲得幫助或建議新功能。
+- **可透過多數上架的錢包存取**——去中心化應用程式應與 ethereum.org 上架的多數錢包相容。
+- **使用者可自行試用**——個別使用者應能使用您的去中心化應用程式並完成一些具體操作。
+- **入門引導**——您的產品應具備設計完善的入門體驗,以協助和教導使用者。 或有介紹操作方法的內容,例如文章或影片。
+- **非託管**——使用者可以控制自己的資金。 如果你的產品消失,使用者仍然可以存取和轉移他們的資金。
+- **全球皆可存取**——您的產品沒有地域限制或「認識你的客戶 (KYC)」要求,不會因此排除特定人士存取您的服務。
+- **開放原始碼**——您的程式碼應可供存取,並且應接受來自廣大社群的拉取請求 (PR)。
+- **社群**——您擁有專屬的社群 (例如 Discord),使用者可在其中與您的團隊互動,以尋求協助或建議新功能。
-## 實踐中的標準 {#criteria-in-practice}
+## 標準的實際應用 {#criteria-in-practice}
你達到的標準越多,你的產品就越有可能進入 ethereum.org。
@@ -68,33 +68,33 @@ lang: zh-tw
ethereum.org 負責做出這種設計決策。
-但請放心,**我們會提供一些網站的連結,這些網站對更多去中心化應用程式進行排名**
+但請放心,**我們會提供其他網站的連結,這些網站會對更多的去中心化應用程式進行排名**
-### 產品訂購 {#product-ordering}
+### 產品訂購{#product-ordering}
除非指定產品以特定順序排列,如按照英文字母順序,否則將按照最晚至最早新增到頁面的順序顯示。 換句話說,最新的產品會被新增到清單的底部。
### 使用條款 {#terms-of-use}
-另請參閱我們的[使用條款](/terms-of-use/)。 ethereum.org 上的資訊僅供一般參考。
+也請參閱我們的[使用條款](/terms-of-use/)。 ethereum.org 上的資訊僅供一般參考。
-## 維護 {#maintenance}
+## 維護{#maintenance}
由於以太坊的流動性,團隊和產品來來去去,每天都有創新,所以我們將對我們的內容進行例行檢查,以便:
- 確保列出的所有去中心化應用程式仍符合我們的標準
- 驗證建議的產品不比目前列出的產品更符合我們的標準
-你可以查驗上述兩項,並告知我們查驗結果,以此提供幫助。 [建立議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)或發送電子郵件至 [website@ethereum.org](mailto:website@ethereum.org)
+你可以查驗上述兩項,並告知我們查驗結果,以此提供幫助。 [建立議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)或傳送電子郵件至 [website@ethereum.org](mailto:website@ethereum.org)
-_我們也在研究投票的可能性,讓社群可以表明偏好,並突顯最好的產品供我們推薦。_
+_我們也正在研究投票選項,讓社群可以表達他們的偏好,並突顯出最好的產品,以便我們推薦。_
---
-## 新增你的產品 {#add-your-product}
+## 新增您的產品 {#add-your-product}
-如果你想將去中心化應用程式新增至 ethereum.org 並且該應用程式符合標準,請在 GitHub 上建立一個議題。
+如果您想將某個去中心化應用程式新增至 ethereum.org 且該程式符合標準,請告知我們。
- 創建一個議題
+ 建議應用程式
diff --git a/public/content/translations/zh-tw/contributing/adding-resources/index.md b/public/content/translations/zh-tw/contributing/adding-resources/index.md
new file mode 100644
index 00000000000..1dd925e83eb
--- /dev/null
+++ b/public/content/translations/zh-tw/contributing/adding-resources/index.md
@@ -0,0 +1,54 @@
+---
+title: 新增資源
+description: 向 ethereum.org 新增資源時使用的政策
+lang: zh-tw
+---
+
+# 新增資源{#adding-resources}
+
+我們想要確保上架最佳的資源,讓使用者能夠安全放心。
+
+任何人都可以向ethereum.org的資源儀表板建議新的資源,該儀表板位於:ethereum.org/resources/
+
+雖然我們歡迎新增新的資源,但目前的資源是我們為了創造使用者體驗而選擇的。 此使用體驗基於下方一些設計原則:
+
+- _具啟發性:ethereum.org 上的任何事物都應該讓使用者耳目一新
+- _好故事:列出的內容應該讓人感到驚嘆
+- _可信:所有業務/專案都應該是合法的,以最大程度降低使用者面臨的風險
+
+整體而言,ethereum.org 想為新的使用者提供「無縫加入體驗」。 為此,我們會根據下列條件來新增資源:
+
+- 方便使用
+- 準確性
+- 維護
+
+## 決策框架
+
+### 標準
+
+- 上架資訊真實準確 - 任何提議上架資源都應包含真實準確的資訊。 包含不實資訊的資源將會被移除
+- 持續性專案 - 為了確保品質以及對使用者的支援,資源應該由活躍團隊維護。 過時的資源可能會被移除。
+
+### 產品訂購{#product-ordering}
+
+根據產品的影響力,我們保留訂購順序的權利。 除非另有載明,否則新的產品通常會新增在列表底部。
+
+## 維護{#maintenance}
+
+隨著以太坊生態系的發展,我們會定期檢查內容:
+
+- 確保列出的所有資源仍符合我們的標準
+- 驗證建議的產品不比目前列出的產品更符合我們的標準
+
+你可以查驗上述兩項,並告知我們查驗結果,以此提供幫助。 提交議題
+https://github.com/ethereum/ethereum-org-website/issues/new?template=bug_report.yaml 或是寄信至mailto:website@ethereum.org
+
+---
+
+## 新增您的資源
+
+如果你想將資源新增至 ethereum.org 並且它符合標準,請在 GitHub 上建立一個議題。
+
+
+提交一個議題
+
diff --git a/public/content/translations/zh-tw/contributing/adding-staking-products/index.md b/public/content/translations/zh-tw/contributing/adding-staking-products/index.md
index ca4803424a4..d3d66c34930 100644
--- a/public/content/translations/zh-tw/contributing/adding-staking-products/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-staking-products/index.md
@@ -4,11 +4,11 @@ description: 向 ethereum.org 新增質押產品或服務時使用的政策
lang: zh-tw
---
-# 添加質押的產品或服務 {#adding-staking-products-or-services}
+# 新增質押產品或服務 {#adding-staking-products-or-services}
我們想要確保上架最佳的資源,讓使用者能夠安全放心。
-任何人都可以建議在 ethereum.org 上新增質押產品或服務。 如我們有遺漏,**[請提出建議](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!**
+任何人都可以建議在 ethereum.org 上新增質押產品或服務。 如果我們遺漏了任何產品或服務,**[請提出建議](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!**
我們目前在以下頁面上架質押產品與服務:
@@ -22,7 +22,7 @@ lang: zh-tw
是否在 ethereum.org 上架產品並非由單一因素決定。 當要決定上架一個產品或服務時,會同時考慮多個標準。 符合以下標準越多,產品或服務上架的可能性就越高。
-**首先,它是屬於哪個類別的產品或服務呢?**
+**首先,這是哪一種類別的產品或服務?**
- 節點或用戶端工具
- 金鑰管理
@@ -35,31 +35,31 @@ lang: zh-tw
提交的質押產品或服務將按照以下標準進行評估:
-**該專案或服務是何時啟動的?**
+**此專案或服務是何時推出的?**
- 是否有證據證明該產品或服務開放給大眾的時間?
- 這用來確定產品的「實戰測試」評分。
-**專案是否得到積極維護?**
+**此專案是否正在積極維護?**
-- 是否有活躍的團隊開發專案? 有誰參與到當中了?
+- 是否有活躍的團隊開發專案? 誰參與其中?
- 只有積極維護的產品才會被考慮。
-**產品或服務是否不需要可信賴/人工中間人?**
+**該產品或服務是否不含可信/人為的中介?**
- 在使用者使用產品或服務的過程中,哪些步驟需要信賴他人來保管其資金金鑰,或妥善分配酬勞?
- 這用來確定產品或服務「去信賴」評分。
-**該專案是否提供準確可靠的資訊?**
+**此專案是否提供準確可靠的資訊?**
- 產品網站提供最新、準確且無誤導性的資訊至關重要,尤其涉及以太坊協定或其他相關技術。
- 提交內容中包含錯誤資訊、過時細節或有關以太坊或其他相關主題的潛在誤導性陳述將不會被上架,如果已經上架,則將被移除。
**支援哪些平台?**
-- 如: Linux,、macOS、Windows、iOS、Android
+- 例如:Linux、macOS、Windows、iOS、Android
-#### 軟體與智慧型合約 {#software-and-smart-contracts}
+#### 軟體和智能合約 {#software-and-smart-contracts}
對於涉及的任何客製化軟體或者智慧型合約:
@@ -68,50 +68,50 @@ lang: zh-tw
- 開源專案應該有一個開放給公眾的原始程式碼存放庫
- 這用來確定產品的「開源」評分。
-**產品是否完成_測試版_開發?**
+**產品是否已脫離 _beta_ 開發階段?**
- 產品處於開發週期的哪個階段?
- 處於測試階段的產品不會納入 ethereum.org
-**軟體是否經過外部安全審核?**
+**此軟體是否經過外部安全審計?**
- 如果為否,是否有計畫進行外部審核?
- 這用來確定產品的「審核」評分。
-**專案是否有漏洞懸賞計畫?**
+**此專案是否有漏洞賞金計畫?**
- 如果沒有該項計畫,是否打算建立漏洞懸賞計畫?
- 這用來確定產品的「漏洞懸賞」評分。
-#### 節點或用戶端模組化 {#node-or-client-tooling}
+#### 節點或用戶端工具 {#node-or-client-tooling}
對於有關節點或用戶端設定、管理或移植的軟體產品:
-**支援哪些共識層用戶端(例如 Lighthouse、Teku、Nimbus、Prysm、Grandine)?**
+**支援哪些共識層用戶端 (例如 Lighthouse、Teku、Nimbus、Prysm、Grandine)?**
- 支援哪些用戶端? 使用者可以自己選擇嗎?
- 這用來確定產品的「多樣用戶端」評分。
-#### 質押即服務(SaaS) {#staking-as-a-service}
+#### 質押即服務 {#staking-as-a-service}
-對於[質押即服務的上架](/staking/saas/)(即委託節點操作):
+對於[質押即服務列表](/staking/saas/) (即委派的節點操作):
-**使用該服務有哪些相關費用?**
+**使用此服務會有哪些相關費用?**
-- 它的費用結構是甚麼?例如:該服務是否有定期收取月費?
+- 費用結構為何?例如,此服務是否收取月費?
- 有任何額外的質押需求嗎?
-**使用者需要註冊帳戶嗎?**
+**使用者是否需要註冊帳戶?**
- 使用者是否可以在未經許可或身分驗證的情況下使用服務?
- 這用來確定產品的「無需許可」評分。
-**誰會持有簽名金鑰及取款金鑰呢?**
+**簽署金鑰和提款金鑰由誰持有?**
- 使用者可以存取哪些金鑰? 服務可以存取哪些金鑰?
- 這用來決定產品的「去信賴」評分。
-**所運作節點的用戶端多樣性是怎樣的?**
+**正在操作的節點,其用戶端多樣性為何?**
- 有多少比例的驗證者金鑰正在主流共識層 (CL) 用戶端運行?
- 截止上一次的編輯,大多數節點運營者都在運行 Prysm 這一共識層用戶端,這對網路是危險的。 如果目前有超過 33% 的網路在使用某一共識層用戶端,我們會索取該用戶端使用情況的相關數據。
@@ -119,58 +119,58 @@ lang: zh-tw
#### 質押池 {#staking-pool}
-對於[聯合質押服務](/staking/pools/):
+對於[匯集質押服務](/staking/pools/):
-**質押最少需要多少以太幣?**
+**質押所需的最低 ETH 數量是多少?**
-- 例如 0.01 以太幣
+- 例如:0.01 ETH
-**涉及哪些費用或質押需求?**
+**涉及哪些費用或質押要求?**
- 有多少百分比的獎勵作為費用被扣除?
- 有任何額外的質押需求嗎?
-**有流動性代幣嗎?**
+**是否有流動性代幣?**
- 涉及哪些代幣? 它們是如何運作的? 合約地址是什麼?
- 這用來確定產品的「流動性代幣」評分。
-**使用者可以作為節點運營者參與嗎?**
+**使用者可以作為節點操作員參與嗎?**
- 使用聯合資金運行驗證者用戶端需要什麼條件?
- 這是否需要個人、公司或去中心化自治組織的許可?
- 這用來確定產品的「無需許可節點」評分。
-**質押池內節點營運商用戶端多樣性是怎樣的?**
+**質押池節點操作員的用戶端多樣性為何?**
- 有多少比例的節點營運商正在運行主流共識層 (CL) 用戶端?
- 截止上一次的編輯,大多數節點運營者都在運行 Prysm 這一共識層用戶端,這對網路是危險的。 如果目前有超過 33% 的網路在使用某一共識層用戶端,我們會索取該用戶端使用情況的相關數據。
- 這用來決定產品的「多樣用戶端」評分。
-### 其它範疇:有的話會比較好的元素 {#other-criteria}
+### 其他標準:加分項目 {#other-criteria}
**支援哪些使用者介面?**
-- 如: 瀏覽器應用程式、桌面應用程式、行動應用程式、命令列介面
+- 亦即:瀏覽器應用程式、桌面應用程式、行動應用程式、命令列介面 (CLI)
-**對於節點工具,該軟體是否提供了在用戶端之間切換的簡單方法?**
+**就節點工具而言,該軟體是否提供在用戶端之間輕鬆切換的方式?**
- 用戶可以透過該工具來輕易並安全地改變用戶端嗎?
-**對於質押即服務,該服務目前正在運作多少個驗證者?**
+**就質押即服務 (SaaS) 而言,此服務目前操作多少個驗證者?**
- 這讓我們能夠了解你至今為止的服務範圍。
-## 我們會怎樣顯示結果 {#product-ordering}
+## 我們如何顯示結果 {#product-ordering}
-上述[納入標準](#criteria-for-inclusion)將用於計算每個產品或服務的累計評分。 該評分用來對滿足特定客觀標準的產品進行排序和展示。 能夠證實滿足的標準越多,產品的排序就越高,且載入時是隨機排列的。
+上述[納入標準](#criteria-for-inclusion)是用來計算各個產品或服務的累積分數。 該評分用來對滿足特定客觀標準的產品進行排序和展示。 能夠證實滿足的標準越多,產品的排序就越高,且載入時是隨機排列的。
-這些標準的程式碼邏輯和權重目前包含在我們存放庫的[這個 JavaScript 元件](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350)。
+這些標準的程式碼邏輯和權重,目前包含在我們儲存庫中的[這個 JavaScript 元件](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350)裡。
-## 新增你的產品或服務 {#add-product}
+## 新增您的產品或服務 {#add-product}
如果你想在 ethereum.org 上新增質押產品或服務,請在 GitHub 上建立一個議題。
- 建立一個議題
+提交一個議題
diff --git a/public/content/translations/zh-tw/contributing/adding-wallets/index.md b/public/content/translations/zh-tw/contributing/adding-wallets/index.md
index 40ab8f14771..91d4e0922ea 100644
--- a/public/content/translations/zh-tw/contributing/adding-wallets/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-wallets/index.md
@@ -20,61 +20,61 @@ lang: zh-tw
### 納入標準:必備條件 {#the-must-haves}
-- **經過安全測試的產品** - 無論是透過審核、內部安全團隊、開源編碼或其他方法,你的錢包的安全性都必須可靠。 這將降低我們的使用者面臨的風險,並向我們表明你非常重視安全性。
-- **錢包已「上線」超過六個月或由具有良好記錄的團體發布** - 這是安全性的另一指標。 六個月是發現嚴重錯誤和漏洞的最佳時間窗口。 我們要求六個月的時間,來幫助篩選出那些作為專案很快就被放棄的分叉。
-- **由活躍的團隊開發** - 這有助於確保品質,並讓使用者的查詢得到支援。
-- **上架資訊真實準確** — 專案的任何提議上架產品都應包含真實準確的資訊。 如果偽造產品的上架資訊,例如聲稱產品為「開源」產品但事實並非如此,該產品將被移除。
-- **聯絡人** - 實施變更時,錢包的聯絡人將大力幫助我們獲得準確資訊。 這樣將在日後收集資訊時,確保 ethereum.org 的更新可控。
-- **EIP-1559(第 2 類)交易** - 你的錢包必須支援 EIP-1559(第 2 類)交易,才能在以太坊主網上進行交易。
-- **良好的使用者體驗** - 雖然使用者體驗是主觀的,但如果多位核心團隊成員在測試產品後,發現產品難以使用,我們保留拒絕該錢包的權利,並會提供有用的改進建議。 這樣做是為了保護我們的使用者群,因為它主要由初學者組成。
-
-### 產品移除 {#product-removals}
-
-- **更新資訊** - 錢包提供者有責任每 6 個月重新提交錢包資訊,以確保其有效性和相關性(即使他們的產品沒有變化)。 如果產品團隊未能這麼做,ethereum.org 或會從頁面上移除該專案。
-
-### 其他標準:加分項 {#the-nice-to-haves}
-
-- **全球皆可存取** - 你的錢包沒有地域限製或身分驗證 (KYC) 要求,以免某些人無法存取你的服務。
-- **支援多種語言** - 你的錢包已經翻譯成多種語言,讓全球使用者都能存取它。
-- **開源** - 你整個專案的程式碼庫(不只是模組)應可被存取,並且你應該接受來自更廣泛社群的拉取請求。
-- **非託管模式** - 使用者可以控制自己的資金。 如果你的產品消失,使用者仍然可以存取和轉移他們的資金。
-- **支援硬體錢包** - 使用者可以連接硬體錢包來簽署交易。
+- **經過安全性測試的產品** - 無論是透過審計、內部安全團隊、開源程式碼或其他方法,您的錢包安全性都必須可靠。 這將降低我們的使用者面臨的風險,並向我們表明你非常重視安全性。
+- **錢包已「上線」超過六個月或由聲譽良好的團隊發布** - 這是安全性的另一項指標。 六個月是發現嚴重錯誤和漏洞的最佳時間窗口。 我們要求六個月的時間,來幫助篩選出那些作為專案很快就被放棄的分叉。
+- **由活躍的團隊開發** - 這有助於確保品質,且使用者能針對其疑問獲得支援。
+- **誠實準確的上架資訊**——我們期望所有專案提交的上架建議,皆能提供誠實準確的資訊。 如果偽造產品的上架資訊,例如聲稱產品為「開源」產品但事實並非如此,該產品將被移除。
+- **聯絡人** - 錢包的聯絡人將有助於我們在進行變更時獲得準確的資訊。 這樣將在日後收集資訊時,確保 ethereum.org 的更新可控。
+- **EIP-1559 (第 2 類) 交易** - 您的錢包必須支援 EIP-1559 (第 2 類) 交易,才能在以太坊主網上進行交易。
+- **良好的使用者體驗** - 雖然使用者體驗 (UX) 是主觀的,但如果數名核心團隊成員測試產品後發現難以使用,我們保留拒絕該錢包的權利,並會轉而提供有用的改進建議。 這樣做是為了保護我們的使用者群,因為它主要由初學者組成。
+- **以以太坊為中心** - 錢包必須提供以以太坊為主要核心的體驗。 這表示以太坊 (或任何 L2) 會設為預設網路、ERC 資產會受到妥善支援,且功能與以太坊生態系一致。 在使用者介面中優先考慮其他 Layer 1 的錢包將不會被列出。
+
+### 產品下架 {#product-removals}
+
+- **更新資訊** - 錢包供應商有責任每 6 個月重新提交其錢包資訊,以確保所提供資訊的有效性和相關性 (即使其產品沒有任何變更)。 如果產品團隊未能這麼做,ethereum.org 或會從頁面上移除該專案。
+
+### 其他標準:加分項目 {#the-nice-to-haves}
+
+- **全球可存取** - 您的錢包沒有地理限制或「認識你的客戶」(KYC) 要求,以致於將某些人排除在服務之外。
+- **支援多種語言** - 您的錢包已翻譯成多種語言,讓世界各地的使用者都能存取。
+- **開放原始碼** - 您整個專案的程式碼庫 (不僅是模組) 應可供存取,且您應該接受來自更廣泛社群的拉取請求 (PR)。
+- **非託管** - 使用者控制自己的資金。 如果你的產品消失,使用者仍然可以存取和轉移他們的資金。
+- **支援硬體錢包** - 使用者可以連接其硬體錢包來簽署交易。
- **WalletConnect** - 使用者可以使用 WalletConnect 連接到去中心化應用程式。
-- **匯入以太坊遠端程序呼叫 (RPC) 端點** - 使用者可以匯入節點遠端程序呼叫資料,讓它們連接到自己選擇的節點或其他以太坊虛擬機相容網路。
-- **非同質化代幣** - 使用者能夠查看錢包中的非同質化代幣並與之互動。
-- **連接到以太坊應用程式** - 使用者能夠連接並使用以太坊應用程式。
-- **質押** - 使用者可以直接透過錢包質押。
-- **兌換** - 使用者可以透過錢包兌換代幣。
-- **多鏈網路** - 你的錢包預設支援使用者存取多個區塊鏈網路。
-- **二層網路** - 你的錢包預設支援使用者存取二層網路。
-- **自訂燃料費** - 你的錢包允許使用者自訂其交易燃料費(基本費用、優先費和最高費用)。
-- **支援以太坊名稱服務** - 你的錢包允許使用者傳送交易到 ENS 名稱。
-- **支援 ERC-20** - 你的錢包允許使用者匯入 ERC-20 代幣合約,或自動查詢並顯示 ERC-20 代幣。
-- **購買加密貨幣** - 你的錢包支援使用者直接購買和操作加密貨幣。
-- **以法幣出售** - 你的錢包支援使用者以法幣出售加密貨幣,並直接以法幣提款到銀行卡或銀行帳戶。
-- **多重簽名** - 你的錢包支援多重簽名來簽署交易。
-- **社交恢復** - 你的錢包支援守護人功能,當使用者遺失了種子助記詞,可以透過守護人來恢復他們的錢包。
-- **專屬支援團隊** - 你的錢包擁有專屬的支援團隊,使用者遇到問題時可以向該團隊尋求協助。
-- **教育資源/文件** - 你的產品應具有精心設計的入門體驗,以幫助和教育使用者。 或有介紹操作方法的內容,例如文章或影片。
+- **匯入以太坊 RPC 端點** - 使用者可以匯入節點 RPC 資料,以連接到自己選擇的節點,或其他與 EVM 相容的網路。
+- **NFT** - 使用者能夠在錢包中檢視自己的 NFT 並與之互動。
+- **連接以太坊應用程式** - 使用者能夠連接並使用以太坊應用程式。
+- **質押** - 使用者能夠直接透過錢包進行質押。
+- **兌換** - 使用者能夠透過錢包兌換代幣。
+- **多鏈網路** - 您的錢包預設支援使用者存取多個區塊鏈網路。
+- **Layer 2 網路** - 您的錢包預設支援使用者存取 Layer 2 網路。
+- **自訂 Gas 費用** - 您的錢包允許使用者自訂其交易 Gas 費用 (基本費用、優先費用、最高費用)。
+- **支援 ENS** - 您的錢包允許使用者將交易傳送到 ENS 名稱。
+- **支援 ERC-20** - 您的錢包允許使用者匯入 ERC-20 代幣合約,或自動查詢並顯示 ERC-20 代幣。
+- **購買加密貨幣** - 您的錢包支援使用者直接購買加密貨幣並開始使用。
+- **兌現為法幣** - 您的錢包支援使用者將加密貨幣兌現為法幣,並直接提款至銀行卡或銀行帳戶。
+- **多重簽名** - 您的錢包支援使用多個簽名來簽署交易。
+- **社交恢復** - 您的錢包支援守護人功能,當使用者遺失種子助記詞時,可以透過這些守護人來恢復錢包。
+- **專屬支援團隊** - 您的錢包設有專屬支援團隊,使用者在遇到問題時可前往尋求協助。
+- **教育資源/文件** - 您的產品應具備設計完善的新手入門體驗,以協助和教育使用者。 或有介紹操作方法的內容,例如文章或影片。
## 新增錢包 {#adding-a-wallet}
如果你想向 ethereum.org 新增錢包,請在 GitHub 上建立一個議題。
- 建立一個議題
+提交一個議題
-## 維護 {#maintenance}
+## 維護{#maintenance}
由於以太坊的流動性,團隊和產品來來去去,每天都有創新,所以我們將對我們的內容進行例行檢查,以便:
- 確保上架的所有錢包和去中心化應用程式仍符合我們的標準
- 驗證建議的產品不比目前列出的產品更符合我們的標準
-ethereum.org 由開源社群維護,我們依靠社群來助其保持最新狀態。 如果你發現有任何關於上架錢包的資訊需要更新,請[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml)或[拉取請求](https://github.com/ethereum/ethereum-org-website/pulls)!
-
+ethereum.org 由開放原始碼社群維護,我們依靠社群的協助來讓網站內容保持最新。 如果您發現任何關於所列錢包的資訊需要更新,請[提出問題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml)或[拉取請求](https://github.com/ethereum/ethereum-org-website/pulls)!
## 使用條款 {#terms-of-use}
-另請參閱我們的[使用條款](/terms-of-use/)。 ethereum.org 上的資訊僅供一般參考。
+另請參閱我們的 [使用條款](/terms-of-use/)。 ethereum.org 上的資訊僅供一般參考。
diff --git a/public/content/translations/zh-tw/contributing/content-resources/index.md b/public/content/translations/zh-tw/contributing/content-resources/index.md
index 0b1107dfa00..ab088e971bf 100644
--- a/public/content/translations/zh-tw/contributing/content-resources/index.md
+++ b/public/content/translations/zh-tw/contributing/content-resources/index.md
@@ -4,13 +4,13 @@ lang: zh-tw
description: 我們在 ethereum.org 上列出內容資源的標準
---
-# 添加內容資源 {#adding-content-resources}
+# 新增內容資源 {#adding-content-resources}
我們無法涵蓋所有有關以太坊的內容,所以我們會嘗試展示一些由社群建立的出色的文章、使用教學、電子報、工作展示板,和各式內容資源。 這些資源通常為使用者可能感興趣的主題提供更深入的資訊。
如果這裡有你感到應該新增到頁面的一份內容資源,請隨時在適合的地方提出建議。
-## 我們是如何決策的 {#how-we-decide}
+## 我們如何決定 {#how-we-decide}
學習資源將按照以下標準評估:
@@ -19,14 +19,14 @@ description: 我們在 ethereum.org 上列出內容資源的標準
- 資訊準確嗎? 它是根據客觀事實,還是根據主觀意見?
- 作者可信嗎? 他們會引用文本出處麼?
- 這份內容是否提供了現存資源/連結沒有的獨特價值?
-- 這份內容是否服務於我們其中一部分[使用者](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c)?
+- 此內容是否符合我們的其中一個[使用者畫像](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c)?
---
-## 新增你的內容資源 {#add-your-content-resource}
+## 新增您的內容資源 {#add-your-content-resource}
如果你想將內容資源新增至 ethereum.org 並且它符合標準,請在 GitHub 上建立一個議題。
- 創建一個議題
+提交一個議題
diff --git a/public/content/translations/zh-tw/contributing/design-principles/index.md b/public/content/translations/zh-tw/contributing/design-principles/index.md
index 4f6123e0870..7908e8ea9aa 100644
--- a/public/content/translations/zh-tw/contributing/design-principles/index.md
+++ b/public/content/translations/zh-tw/contributing/design-principles/index.md
@@ -6,69 +6,69 @@ description: ethereum.org 設計與內容決策背後的原則
# 我們的設計原則 {#contributing-to-ethereumorg-}
- 你好,歡迎瞭解 ethereum.org 的設計原則。 這是 ethereum.org 不斷發展和改進過程的一部分。
+ 你好,歡迎了解 ethereum.org 的設計原則。 這是 ethereum.org 不斷發展和改進過程的一部分。
我們的原則決定了網站的外觀和感覺以及網站上的內容。
-為 [ethereum.org 做出貢獻](/contributing/)前,你應該閱讀以下內容。
+在你 [為 ethereum.org 做出貢獻](/contributing/) 前,你應該閱讀這些內容。
-## 設計原則是什麼? {#ways-to-contribute}
+## 設計原則是什麼? 貢獻方法 {#ways-to-contribute}
-別擔心,設計原則非常簡單! **設計原則**是我們在設計(即建立、維護或更新)某些東西時參考的一組準則。
+別擔心,設計原則非常簡單! **設計原則**是一套我們在設計(也就是建立、維護或更新)東西時所參考的指導方針。
-在 ethereum.org 的背景下,這些設計原則是我們希望網站向世界呈現和展示的內容的基礎。 它們既能表達我們的抱負,**也**實現功能。 這不僅僅是網站_外觀_,還體現網站的_運作方式_,甚至是網站給人的_感覺_。從顏色到頁面佈局,再到我們在網站上談論以太坊的方式,一切都應該遵循這些原則。
+在 ethereum.org 的背景下,這些設計原則是我們希望網站向世界呈現和展示的內容的基礎。 它們既有啟發性,**也**有實用性。 這不僅關乎網站的_外觀_,也關乎其_運作_方式,甚至是它帶給人的_感受。_從顏色到頁面排版,再到我們在網站上談論以太坊的方式,一切都應遵循這些原則。
-## 原則實踐 {#how-decisions-about-the-site-are-made}
+## 原則的實際應用 {#how-decisions-about-the-site-are-made}
-讓我們來看一個例子。 其中一項原則是「可信」,這意味著我們希望網站訪問者_感受_並_知道_網站值得信賴 — 就像更寬泛的以太坊生態系統一樣。 在該原則下,我們有 3 個功能性「次原則」,這些是我們可以採取的可行步驟,以使網站具有可信度:
+讓我們來看一個例子。 其中一項原則是「可信」,這意味著我們希望網站訪客_感受_到並_了解_網站值得信賴——就像更廣泛的以太坊生態系一樣。 在該原則下,我們有 3 個功能性「次原則」,這些是我們可以採取的可行步驟,以使網站具有可信度:
-- _“新鮮”_,即保持內容最新。
-- _“社會認同”_,即展示生態繫統的規模、多樣性和活躍度(你知道的:以太坊昇級進度、去中心化金融、遊戲、所有黑客馬拉鬆等)
-- _“一緻”_,即網站設計以及冩作的基調和準確性是一緻的。
+- _「最新」_,也就是保持內容為最新狀態。
+- _「社會認同」_,也就是展示生態系的規模、多樣性和活躍度(例如:以太坊升級進度、DeFi、遊戲、所有的駭客松等等)。
+- _「一致」_,也就是網站設計的一致性,以及寫作基調和準確性。
因此,當我們做出設計或文案決策時,我們可以參考「可信」原則並自問:
- _「網站是否反映了目前的資訊?」_
-- _「我們如何以及在哪裡展示生態繫統的規模和活動?」_
-- _「我正在審核的由社群成員提出的新貢獻內容是否與網站上目前的設計和文風一致?」_
+- _「我們如何以及在哪裡展示生態系的規模和活動?」_
+- _「我正在審核的社群成員所提議的新貢獻,是否與網站目前的設計和寫作風格一致?」_
-## Ethereum.org 設計原則 {#contributors}
+## ethereum.org 設計原則 {#contributors}
-### 1. 啟發性 {#1-inspirational}
+### 1. 啟發人心 {#1-inspirational}
網站應該能夠激發使用者,想象以太坊能如何改變世界。 應該能夠激勵人們去探索、體驗和修複以太坊生態繫統的工具和應用程式。
-- **鬥誌昂揚:**網站應該傳達以太坊雄心勃勃的目標,即有意義地改變世界。 應該清楚的是,以太坊不僅僅是一些新技術的堆疊 - 它是一種變革性的技術。
-- **通過教育賦予權力:**網站應該對人們進行教導,以便他們了解以太坊的潛力,在生態繫統中找到自己的位置,並感到有權參與其中。
+- **顛覆性:** 本網站應傳達以太坊有意義地改變世界的宏偉目標。 應該清楚的是,以太坊不僅僅是一些新技術的堆疊 - 它是一種變革性的技術。
+- **透過教育賦權:** 網站應該教育人們,以便他們了解以太坊的潛力,在生態系中找到自己的位置,並感覺有能力參與其中。
視覺導航 • 內容
-### 2. 通用性 {#2-universal}
+### 2. 普適性 {#2-universal}
以太坊是一個全球性的、去中心化的專案,我們的使用者反映了這一點。 網站應該致力於讓每個人都能存取,並體現出世界上的多元文化。
-- **無障礙:**網站應遵循無障礙指南 - 包括允許低帶寬連接的人訪問。
-- **簡單明了:**網站應該是簡單而明確的。 文案不應使用可能被誤解的用語或意思缺失的譯文。
-- **以太坊是多麵的:**以太坊是一個專案、一個代碼庫、一個社區和一個願景 以太坊出於不同的原因對不同的人都有價值,參與的方式也多種多樣。
+- **無障礙:** 網站應遵循無障礙指南——包括為使用低頻寬連線的人們提供服務。
+- **簡單明瞭:** 網站應該簡單而明確。 文案不應使用可能被誤解的用語或意思缺失的譯文。
+- **以太坊是多面向的:** 以太坊是一個專案、一個程式碼庫、一個社群,也是一個願景。 以太坊出於不同的原因對不同的人都有價值,參與的方式也多種多樣。
冩作系統 • 色彩的使用 • 視覺導航 • 內容
-### 3 好故事 {#3-a-good-story}
+### 3 一個好故事 {#3-a-good-story}
網站的運作應該像一個好故事一樣。 訪客就像在旅途中,而你所貢獻的內容是旅途的一部分。 你的貢獻應該運用清晰的敘述技巧:一個有開頭(介紹/切入點)、中間(一些經驗和見解)和結尾(指向相關資源或後續步驟的連結)。
-- **層次分明:**如果內容具有一個清晰的、有層次的信息架構,這將有助於 ethereum.org 的訪問者在尋求達到他們的目的時“像讀故事一樣”瀏覽網站。
-- **踏腳石:**我們是來網站尋找答案的訪問者的踏腳石。 我們不想取代許多現有資源或成爲這些資源的替代品。 我們給出答案並提供可靠的後續步驟。
+- **層次分明**:清晰、階層化的資訊架構有助於 ethereum.org 的訪客在尋求達成目標時,以「如同閱讀故事」的方式瀏覽網站。
+- **墊腳石:** 對於任何尋求答案的人來說,我們就是一塊墊腳石。 我們不想取代許多現有資源或成爲這些資源的替代品。 我們提供答案,並給出可靠的後續步驟。
使用者旅程 • 內容
-### 4 可信 {#4-credible}
+### 4 值得信賴 {#4-credible}
人們可能想要初步了解以太坊生態系統,或者對以太坊保持懷疑態度。 你的溝通方式發揮重要作用。 請確保他們在離開網站時對以太坊生態系統更加有信心。
-- **最新:**始終保持最新。
-- **社會認同:**展示生態繫統的規模、多樣性和活躍度。
-- **一緻:**設計和內容的一緻性傳達了可信度。
+- **最新:** 隨時保持更新。
+- **社會認同:** 展示生態系的規模、多樣性和活躍度。
+- **一致:** 設計和內容的一致性傳達了可信度。
視覺導航 • 內容
@@ -76,18 +76,18 @@ description: ethereum.org 設計與內容決策背後的原則
網站是許多貢獻者的産物,就像整個生態系統一樣。
-- **開放性:**爲整個生態繫統的源代碼、流程和專案的透明度而歡呼吧。
-- **可擴展性:**模塊化是我們一切努力背後的關鍵重點,所以貢獻也應該是模塊化的。 核心設計、組件程式碼和網站的實作應使其能夠在未來輕鬆擴展。
-- **實驗性:**我們正在不斷地進行實驗、測試和迭代。
-- **協作性:**這個專案將我們所有人聚集在一起。
-- **可持續性:**爲社區長期維護而設置。
+- **開放:** 頌揚整個生態系的原始碼、流程和專案的透明度。
+- **可擴充:** 模組化是我們一切工作的核心重點,因此貢獻也應該是模組化的。 網站的核心設計、元件程式碼和實作,應使其未來能夠輕鬆擴充。
+- **實驗性:** 我們不斷地進行實驗、測試和迭代。
+- **協作性:** 這個專案將我們所有人凝聚在一起。
+- **可持續性:** 為社群的長期維護做好準備
-你可以看到[我們的整個網站](/)充分體現了我們的設計原則。
+你可以在[我們的整個網站](/)上看到設計原則的實際應用。
## 提供意見回饋 {#give-feedback}
-**分享你對本文檔的意見回饋!**我們提出的原則之一是「**協作改進**」,這意味着我們希望網站是衆多貢獻者的産物。 因此,基於這一原則,我們希望與以太坊社群分享這些設計原則。
+**分享你對本文件的意見回饋!** 我們提出的原則之一是「**協作改進**」,這意味著我們希望網站是眾多貢獻者的成果。 因此,基於這一原則,我們希望與以太坊社群分享這些設計原則。
-雖然這些原則主要體現在 ethereum.org 網站上,但我們希望其中許多原則能夠代表以太坊生態系統的整體價值。 也許你甚至想將其中一些原則運用到你自己的專案中!
+雖然這些原則是針對 ethereum.org 網站,但我們希望其中許多原則也代表了整個以太坊生態系的價值觀。 也許你甚至想將其中一些原則運用到你自己的專案中!
-請透過 [Discord 伺服器](https://discord.gg/ethereum-org)或[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)來讓我們知道你的想法。
+請在我們的 [Discord 伺服器](https://discord.gg/ethereum-org)上讓我們知道您的想法,或[建立 issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)。
diff --git a/public/content/translations/zh-tw/contributing/design/adding-design-resources/index.md b/public/content/translations/zh-tw/contributing/design/adding-design-resources/index.md
index 60fce770821..89c8e9ac059 100644
--- a/public/content/translations/zh-tw/contributing/design/adding-design-resources/index.md
+++ b/public/content/translations/zh-tw/contributing/design/adding-design-resources/index.md
@@ -6,13 +6,13 @@ lang: zh-tw
# 新增設計資源 {#adding-design-resources}
-任何人都可以為 [web3 頁面中的設計和使用者體驗區域](/developers/docs/design-and-ux/)建議新的設計材料。
+任何人都可以向 [web3 的設計與使用者體驗頁面](/developers/docs/design-and-ux/) 建議新的設計材料。
請注意本頁面的重點,是為有抱負的 web3 設計師提供使用者價值。 設計部分不是為了宣傳你的服務、產品或平台。
為確保我們維持高標準的資訊並推廣有價值的見解,我們制定了上架政策:
-## 研究和儀表板 {#Research-studies}
+## 研究與儀表板 {#Research-studies}
1. 健全的方法論
@@ -48,7 +48,7 @@ c. 寫作應簡明扼要。
a. 文章主要目標應為分享見解,而非宣傳特定專案或公司。
-## 社群/去中心化自治組織 {#Communities-and-DAOs}
+## 社群/DAO {#Communities-and-DAOs}
1. 網站必須清楚說明如何加入去中心化自治組織/社群
diff --git a/public/content/translations/zh-tw/contributing/design/index.md b/public/content/translations/zh-tw/contributing/design/index.md
index 21930c8a716..b24fae47686 100644
--- a/public/content/translations/zh-tw/contributing/design/index.md
+++ b/public/content/translations/zh-tw/contributing/design/index.md
@@ -4,7 +4,7 @@ description: 為 ethereum.org 作出設計貢獻
lang: zh-tw
---
-# 為 ethereum.org 作出設計貢獻 {#design-contributions}
+# 為 ethereum.org 貢獻設計 {#design-contributions}
設計是任何專案的關鍵組成部分,把你的時間和設計技能投入到 ethereum.org,有助替我們的訪客改善使用者體驗。 替開源專案做出貢獻,會為你提供機會以獲取相關經驗,並在協作環境中發展技能。 你有機會與其他擁有獨特觀點和見解的設計師、開發者和社群成員合作。
@@ -12,15 +12,15 @@ lang: zh-tw
## 如何做出貢獻?
-### 對早期設計原型提供意見回饋 {#design-critique}
+### 針對早期設計原型提供回饋 {#design-critique}
有時候我們需要獲得幫助來測試我們的原始構想。 這是在沒有任何技術知識的情況下做出貢獻的好方法。
-1. 設計團隊會在 [Discord](https://discord.com/invite/ethereum-org) 和 [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) 上分享模型設計。
+1. 設計團隊會在 [Discord](https://discord.com/invite/ethereum-org) 和 [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) 上分享設計模型。
2. 你會在指導下熟悉這些設計,並透過評論功能提供意見回饋。
3. 結果將在 GitHub 議題中分享,然後由團隊關閉。
-### 參與調查研究 {#answer-surveys}
+### 參與問卷調查研究 {#answer-surveys}
透過以下方式在我們網站上提供意見回饋:
@@ -28,40 +28,40 @@ lang: zh-tw
2. 點擊右下角的意見回饋小工具,並回答與設計和內容相關的問題。
3. 重點關注開放式問題。
-### 尋找網站上與設計相關的問題並回報 {#report-design-issues}
+### 找出網站上與設計相關的問題並回報 {#report-design-issues}
Ethereum.org 是個擁有許多功能和內容,而且快速發展的網站。 某些使用者介面很容易過時或需要改進。 如果你遇到這類情況,請報告以讓我們注意。
1. 瀏覽網站並注意其設計。
2. 如果你發現任何視覺或使用者體驗方面問題,請取得螢幕擷取畫面並記錄下來。
-3. 使用[錯誤報告](https://github.com/ethereum/ethereum-org-website/issues/new/choose)來報告發現的問題。
+3. 使用 [錯誤報告](https://github.com/ethereum/ethereum-org-website/issues/new/choose) 回報找到的問題。
-### 提出設計變更 {#propose-design-changes}
+### 提出設計變更建議 {#propose-design-changes}
-如果你願意接受設計挑戰,可以造訪我們的 GitHub 議題板並篩選[設計相關議題](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)。
+如果你樂於接受設計挑戰,可以前往我們的 GitHub 議題看板並篩選出 [設計相關議題](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)。
-1. 瀏覽我們的網站並注意其設計,或訪問我們的 GitHub 儲存庫並查看標示 [「Design required」標籤](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)的議題。
-2. 構思解決方案並進行設計。 (最好使用我們的[設計系統](https://www.figma.com/community/file/1134414495420383395))。
-3. 在對應的 GitHub 議題中提出解決方案或[建立一個新的議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request)。
+1. 瀏覽我們的網站並留意其設計,或前往我們的 GitHub 存放庫,檢視標有 [「需要設計」標籤](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) 的議題。
+2. 構思解決方案並進行設計。 (最好使用我們的 [設計系統](https://www.figma.com/community/file/1134414495420383395))。
+3. 在相應的 GitHub 議題中提出解決方案,或 [建立新議題。](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request)
4. 等待設計團隊審核。
-### 一起構建設計系統 {#Contribute-to-design-system}
+### 共同建立設計系統 {#Contribute-to-design-system}
利用我們的設計系統,讓設計 ethereum.org 變得輕鬆有趣。 如果你是位經驗豐富的設計師,便可以幫助我們為網站準備許多組件。
-1. 從 GitHub 上的[設計系統板](https://github.com/ethereum/ethereum-org-website/labels/design%20system)選擇要處理的議題,或建立一個新的議題。
+1. 從 GitHub 上的 [設計系統看板](https://github.com/ethereum/ethereum-org-website/labels/design%20system) 中選擇要處理的議題,或建立新議題。
2. 請求將選定的議題分配給你。
3. 開始在 Figma 中設計所要求的組件。
4. 需要審核或指導時,請在 GitHub 上將組件分享給設計團隊。
5. 設計團隊將進行審核。
6. 設計團隊會將變更合併到主檔案中,並將它發佈到社群。
-### 在網站上撰寫與設計相關的內容 {#write-design-articles}
+### 在網站上撰寫設計相關內容 {#write-design-articles}
-以太坊開發者社群很強大,但設計社群稍顯落後。 如果你是具備 Web3 知識的設計師,請考慮與廣大社群分享你的知識,讓我們可以共同成長和進步;我們有一個[關於以太坊設計的頁面](/developers/docs/design-and-ux/),你可以在此做出貢獻。 你也可以查看我們的[上架政策](/contributing/design/adding-design-resources)。
+以太坊開發者社群很強大,但設計社群稍顯落後。 如果你是具備 Web3 知識的設計師,請考慮與廣大社群分享你的所學,讓我們可以共同成長和進步;我們有[一個關於為以太坊設計的頁面](/developers/docs/design-and-ux/),你可以在此做出貢獻。 你也可以查看我們的 [上架政策](/contributing/design/adding-design-resources)。
1. 構思 ethereum.org 上應該涵蓋的設計主題,會對該領域的設計師有所裨益。
-2. 前往我們的 GitHub 儲存庫,[發起議題](https://github.com/ethereum/ethereum-org-website/issues/new)來建議主題(先不要寫內容)。
+2. 前往我們的 GitHub 存放庫,並 [發起議題](https://github.com/ethereum/ethereum-org-website/issues/new) 來提議主題(還不要撰寫內容)。
3. 等待設計團隊核准。
4. 一旦核准,開始撰寫內容。
5. 在相應的 GitHub 議題中提交。
@@ -71,7 +71,7 @@ Ethereum.org 是個擁有許多功能和內容,而且快速發展的網站。
可視化是用來解釋抽象主題的其中一種最強大工具。 透過新增圖表和資訊圖,可以發掘巨大潛力。 畢竟,一張圖片勝過千言萬語。
1. 訪問我們的網站,並查看可以新增一些新資訊圖的頁面。
-2. 確保插圖風格與我們的[網站](/assets/)相對應。
-3. 前往我們的 GitHub 儲存庫並[發起議題](https://github.com/ethereum/ethereum-org-website/issues/new)來建議插圖。
+2. 確保插圖風格與我們的 [資產](/assets/) 一致。
+3. 前往我們的 GitHub 存放庫,並 [發起議題](https://github.com/ethereum/ethereum-org-website/issues/new) 提議此插圖。
4. 設計團隊將會審核。
5. 我們建立一個新議題,並邀請開發者來實作該新圖像。
diff --git a/public/content/translations/zh-tw/contributing/index.md b/public/content/translations/zh-tw/contributing/index.md
index 7788c50e1e1..91f28044eac 100644
--- a/public/content/translations/zh-tw/contributing/index.md
+++ b/public/content/translations/zh-tw/contributing/index.md
@@ -4,41 +4,46 @@ description: 瞭解為 ethereum.org 做出貢獻的不同方法
lang: zh-tw
---
-# 為 ethereum.org 做出貢獻 🦄 {#contributing-to-ethereumorg}
+# 為 ethereum.org 作出貢獻 🦄 {#contributing-to-ethereumorg}
-Ethereum.org 是一個開源專案,擁有超過 **12000 名**貢獻者,幫助翻譯、編寫、設計和維護網站。
+Ethereum.org 是一個開源專案,擁有 **12,000+** 名貢獻者,他們協助翻譯、撰寫、設計及維護網站。
我們是個熱情的社群,將助你在以太坊生態系統中成長和學習,同時讓你做出有意義的貢獻,並獲得相關實踐經驗!
-## 貢獻方法 {#ways-to-contribute}
+## 貢獻方式 {#ways-to-contribute}
**翻譯**
-- [加入翻譯計劃](/contributing/translation-program/) – 幫助我們把 ethereum.org 內容翻譯成新語言
+
+- [加入翻譯計畫](/contributing/translation-program/) – 協助我們將 ethereum.org 推廣到新的語言
**開發**
-- [處理未解決的問題](https://github.com/ethereum/ethereum-org-website/issues) – 我們確定為需要完成的工作
+
+- [處理待解決的議題](https://github.com/ethereum/ethereum-org-website/issues) – 我們已找出需要處理的工作
**設計**
-- [幫助設計網站](/contributing/design/) — 任何水平的設計者都可以為改進網站做出貢獻
+
+- [協助設計網站](/contributing/design/) – 歡迎所有程度的設計師為改進網站作出貢獻
**內容**
-- [建立/編輯內容](/contributing/#how-to-update-content) – 提議建立新頁面或對已有內容稍微改進
-- [新增社群資源](/contributing/content-resources/) – 將有用的文章或資源加入相關頁面
-- [建議設計資源](/contributing/design/adding-design-resources/) – 新增、更新和刪除設計資源
-- [新增詞彙表術語](/contributing/adding-glossary-terms/) – 幫助我們繼續擴大以太坊的[詞彙表](/glossary/)
-- [測驗](/contributing/quizzes/) – 新增、更新和刪除相關頁面的測驗題庫
+
+- [建立/編輯內容](/contributing/#how-to-update-content) – 建議新頁面或對現有內容進行微調
+- [新增社群資源](/contributing/content-resources/) – 將實用的文章或資源新增至相關頁面
+- [建議設計資源](/contributing/design/adding-design-resources/) – 新增、更新與刪除實用的設計資源
+- [測驗](/contributing/quizzes/) – 為相關頁面新增、更新與刪除測驗題庫
**特色功能的想法**
-- [請求一項特色功能](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – 讓我們知道有關你對新特色功能或設計的任何想法
+
+- [請求新功能](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – 讓我們知道您對新功能或設計的任何想法
**產品列表**
-- [新增交易所](/contributing/adding-exchanges/) – 新增交易所到我們的 [交易所搜尋工具](/get-eth/#country-picker)
-- [新增產品](/contributing/adding-products/) – 新增去中心化應用程式或錢包到相關頁面
-- [新增開發者工具](/contributing/adding-developer-tools/) – 新增開發者工具到相關頁面
-- [新增二層網路](/contributing/adding-layer-2s/) – 新增二層網路到相關頁面
-- [新增質押產品或服務](/contributing/adding-staking-products/) – 新增專案以幫助加速單獨質押、聯合質押,或質押即服務
-- [新增錢包](/contributing/adding-wallets/) – 為[查找錢包頁面](/wallets/find-wallet/)新增錢包
-- [為我們的去中心化科學頁面建議一個專案](/contributing/adding-desci-projects/) – 新增一個基於以太坊構建專案,為去中心化科學做出貢獻
+
+- [新增交易所](/contributing/adding-exchanges/) – 將交易所新增至我們的[交易所搜尋器](/get-eth/#country-picker)
+- [新增產品](/contributing/adding-products/) – 將去中心化應用程式或錢包新增至相關頁面
+- [新增開發者工具](/contributing/adding-developer-tools/) – 將開發者工具新增至相關頁面
+- [新增 Layer 2](/contributing/adding-layer-2s/) – 將 Layer 2 新增至相關頁面
+- [新增質押產品或服務](/contributing/adding-staking-products/) – 新增能促進個人質押、集合質押或質押即服務的專案
+- [新增錢包](/contributing/adding-wallets/) – 為[尋找錢包頁面](/wallets/find-wallet/)新增錢包
+- [為我們的 DeSci 頁面建議專案](/contributing/adding-desci-projects/) – 新增一個基於 Ethereum 建立、對去中心化科學有所貢獻的專案
有問題嗎? 🤔 加入我們的 [Discord 伺服器](https://discord.gg/ethereum-org)
@@ -50,65 +55,65 @@ Ethereum.org 是一個開源專案,擁有超過 **12000 名**貢獻者,幫
查看所有任務
-## 如何開展 ethereum.org 相關工作 {#how-to-update-content}
+## 如何為 ethereum.org 貢獻 {#how-to-update-content}
-如你希望為[翻譯計劃](/contributing/translation-program/)做出貢獻,我們需要你在 [Crowdin](https://crowdin.com/project/ethereum-org) 上建立帳戶。 對於其他事項,例如在網站上新增或編輯內容或視覺效果、修復錯誤、處理未完成的任務,你將需要一個 [GitHub](https://github.com/) 帳戶。
+如果您希望參與[翻譯計畫](/contributing/translation-program/),請在 [Crowdin](https://crowdin.com/project/ethereum-org) 上建立一個帳戶。 至於其他所有事項——例如新增或編輯網站內容或視覺元素、修復程式錯誤、處理待辦任務——您都需要一個 [GitHub](https://github.com/) 帳戶。
-所有更新會透過 GitHub 提取請求 (PR) 流程完成。 這意味著你建立網站的一個本機副本,做出變更並要求合併你的變更。 如你未曾執行過該操作,請遵照 [GitHub 儲存庫](https://github.com/ethereum/ethereum-org-website) 底部的說明。
+所有更新會透過 GitHub 提取請求 (PR) 流程完成。 這意味著你建立網站的一個本機副本,做出變更並要求合併你的變更。 如果您從未這麼做過,請依照我們 [GitHub 儲存庫](https://github.com/ethereum/ethereum-org-website) 底部的說明進行。
你不需要許可即可開始任何工作內容,但最好始終告知我們你打算做什麼。 你可以透過以下方式向我們告知你的計劃:
-- 在 [GitHub](https://github.com/ethereum/ethereum-org-website) 內對一個議題或提取請求做出評論
-- 在我們的 [Discord 伺服器](https://discord.gg/ethereum-org)上作訊息交流
+- 在 [GitHub](https://github.com/ethereum/ethereum-org-website) 的議題或提取請求中留言
+- 在我們的 [Discord 伺服器](https://discord.gg/ethereum-org) 上傳送訊息
在做出貢獻前,請確定你熟悉下列內容:
-- 不斷演化的 [ethereum.org 願景](/about/)
+- 不斷演進的 [ethereum.org 願景](/about/)
- 我們的[設計原則](/contributing/design-principles/)
- 我們的[風格指南](/contributing/style-guide/)
- 我們的[行為準則](/community/code-of-conduct)
-## 如何做出有關網站的決定 {#how-decisions-about-the-site-are-made}
+## 網站相關決策的制定方式 {#how-decisions-about-the-site-are-made}
-有關個人提取請求、設計演進和主要更新的決定由來自整個以太坊生態系統的人員組成的團隊作出。 該團隊包括專案管理人、開發者、設計師、市場和溝通部門,以及內容專家。 社群意見為每個決定提供參考:因此,請在議題中提出問題、提交提取請求或聯絡團隊:
+關於個別的提取請求、設計演變和重大升級的決策,是由一個來自整個 Ethereum 生態系的團隊所制定。 此團隊成員包括專案經理、開發人員、設計師、行銷與傳播人員,以及主題專家。 社群的意見是我們每項決策的參考:因此請您在議題中提出問題、提交提取請求或聯絡團隊:
- [website@ethereum.org](mailto:website@ethereum.org)
- [@ethdotorg](https://twitter.com/ethdotorg)
-- [Discord服務器](https://discord.gg/ethereum-org)
+- [Discord 伺服器](https://discord.gg/ethereum-org)
-### 有關抄襲的說明 {#plagiarism}
+### 關於抄襲的注意事項 {#plagiarism}
-向 ethereum.org 貢獻任何內容或作品時,請只使用原創作品或你有權使用的內容。 以太坊生態系統內的很多專案使用開放原始碼授權,允許自由分享資訊。 但是,如你未能找到有關開放原始碼授權的資訊,不要嘗試將其新增到 ethereum.org。 任何看似抄襲的提取請求將會被拒絕。
+在為 ethereum.org 貢獻任何內容或產出時,請務必只使用您自己的原創作品,或是您有權使用的內容。 Ethereum 生態系中的許多專案都使用開源授權,允許資訊自由分享。 然而,如果您找不到此類資訊,請勿嘗試將其新增至 ethereum.org。 任何被視為抄襲的提取請求都將被拒絕。
-## 剛開始接觸開放原始碼項目? {#new-to-open-source}
+## 剛開始接觸開源專案? {#new-to-open-source}
-在我們的 GitHub 儲存庫,問題的准入門檻很低,有些問題特別適合新接觸開放原始碼項目的開發者查看。我們將這類問題標記為[適合入門問題](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)。
+我們的 GitHub 儲存庫中有一些低門檻的議題,這些議題專為剛接觸開源的開發人員所設計,並標有 [good first issue](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) 標籤。
-## 領取你的鏈上成就代幣 (OAT) {#oat}
+## 領取您的鏈上成就代幣 (OAT) {#oat}
-如果你的貢獻合併到 ethereum.org,你將有機會在 [Galxe](https://app.galxe.com/quest/ethereumorg) 上領取特殊徽章。 鏈上成就代幣 (OAT) 證明你曾經協助生態系統變得更加出色。
+如果您的貢獻被合併至 ethereum.org,您將有機會在 [Galxe](https://app.galxe.com/quest/ethereumorg) 上領取一枚特殊徽章。 鏈上成就代幣 (OAT) 是您曾協助讓生態系變得更美好的證明。
-[有關鏈上成就代幣的更多資訊](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03)
+[關於 OAT 的更多資訊](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03)
### 如何領取
-1. 加入我們的 [Discord 伺服器](https://discord.gg/ethereum-org)。
-2. 將你貢獻內容的連結貼到 `#🥇 | proof-of-contribution` 頻道。
-3. 等待我們團隊的成員向你發送前往你的鏈上成就代幣的連結。
-4. 領取你的鏈上成就代幣!
-你應該只用自行保管的錢包來領取鏈上成就代幣。 請勿使用交易所帳戶或你未持有私密金鑰的其他帳戶,因為這些帳戶將不容許你存取和管理你的鏈上成就代幣。
+1. 加入我們的 [Discord 伺服器](https://discord.gg/ethereum-org)。
+2. 將您貢獻內容的連結貼到 `#🥇 | proof-of-contribution` 頻道。
+3. 等待我們團隊的成員傳送您的 OAT 連結給您。
+4. 領取您的 OAT!
-## 領取你的 GitPOAP {#claim-gitpoap}
+您應該只使用自我託管錢包來領取 OAT。 請勿使用交易所帳戶或您未持有私密金鑰的其他帳戶,因為這些帳戶將不允許您存取及管理您的 OAT。
-GitPOAP 還會自動識別你的合併貢獻,並讓你在其平臺上,鑄造一個獨有的貢獻者 POAP!
+## 領取您的 GitPOAP {#claim-gitpoap}
+GitPOAP 也會自動辨識您合併的貢獻,讓您在其平台上鑄造一枚專屬的貢獻者 POAP!
### 如何領取 {#how-to-claim}
1. 造訪 [GitPOAP](https://www.gitpoap.io)。
-2. 透過你的錢包建立連接,甚至以電子郵件登入選項來連接。
-3. 搜尋你的 GitHub 使用者名稱、以太幣地址、以太坊域名服務名稱或任何 GitPOAP 以檢查你是否符合條件。
-4. 如果你的 GitHub 帳戶符合條件,那麼你就可以鑄造一個 GitPOAP!
+2. 透過登入選項,使用您的錢包或電子郵件進行連接。
+3. 搜尋您的 GitHub 使用者名稱、ETH 地址、ENS 名稱或任何 GitPOAP,以檢查您是否符合資格。
+4. 如果您的 GitHub 帳戶符合資格,您就可以鑄造一枚 GitPOAP!
## 貢獻者 {#contributors}
diff --git a/public/content/translations/zh-tw/contributing/quizzes/index.md b/public/content/translations/zh-tw/contributing/quizzes/index.md
index fe6123944e4..af36f85a766 100644
--- a/public/content/translations/zh-tw/contributing/quizzes/index.md
+++ b/public/content/translations/zh-tw/contributing/quizzes/index.md
@@ -12,14 +12,14 @@ lang: zh-tw
一些現有測驗的範例可以在下面找到:
-- [二層網路](/layer-2)
-- [非同質化代幣](/nft/)
+- [Layer 2](/layer-2)
+- [NFT](/nft/)
- [什麼是以太坊?](/what-is-ethereum/)
-- [什麼是以太幣?](/what-is-ether/)
+- [什麼是 ETH?](/what-is-ether/)
## 新增學習測驗
-如果有頁面尚未建立學習測驗,請為其[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)。
+如果某個頁面還沒有學習測驗,請[為此建立議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)。
請提供以下資訊:
@@ -32,7 +32,7 @@ lang: zh-tw
## 新增測驗問題
-如果你想將一個問題新增到測驗的問題庫中,請[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)並提供以下資訊:
+如果您想將問題新增至測驗的題庫中,請[建立議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)並提供以下資訊:
- 你想新增測驗問題的頁面
- 對於每個問題,請提供以下資訊:
@@ -43,7 +43,7 @@ lang: zh-tw
## 更新測驗問題
-如果你想在測驗的問題庫中更新問題,請[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)並提供以下資訊:
+如果您想更新測驗題庫中的某個問題,請[建立議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)並提供以下資訊:
- 你想更新測驗問題的頁面
- 對於每個更新的問題,請提供以下資訊:
@@ -55,7 +55,7 @@ lang: zh-tw
## 刪除測驗問題
-如果頁面上和問題相關的內容不再存在並且需要刪除問題,請[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)以刪除測驗問題並提供以下資訊:
+如果頁面上與某問題相關的內容已不存在而需要移除該問題,請[建立議題](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)以移除該問題並提供以下資訊:
- 你想刪除測驗問題的頁面
- 你想刪除的問題
diff --git a/public/content/translations/zh-tw/contributing/translation-program/faq/index.md b/public/content/translations/zh-tw/contributing/translation-program/faq/index.md
index 9a526f74717..4f55a2b32bb 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/faq/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/faq/index.md
@@ -18,29 +18,29 @@ ethereum.org 翻譯計劃是其延伸,並且其組織方式考慮了相近的
因此,翻譯計劃的性質是開放和自願的,而且參與其中不會得到補償。 如果我們要按照翻譯字數給譯者提供補償,我們只會邀請那些具有足夠翻譯經驗的人員(專業譯者)加入翻譯計劃。 這會讓翻譯計劃具有排他性,妨礙我們達成所概述的目標,具體而言:讓所有人參加和參與到生態系統中。
-我們盡一切努力讓貢獻者在以太坊生態系統中取得成功;許多非貨幣性激勵措施已就位,如:[提供 POAP](/contributing/translation-program/acknowledgements/#poap)、[譯者證書](/contributing/translation-program/acknowledgements/#certificate)、整理 [翻譯排行榜](/contributing/translation-program/acknowledgements/),以及 [在網站上列出我們所有的譯者](/contributing/translation-program/contributors/)。
+我們竭盡所能,讓我們的貢獻者能在以太坊生態系統中成功;我們設有許多非金錢的獎勵,例如:[提供 POAP](/contributing/translation-program/acknowledgements/#poap) 和[譯者證書](/contributing/translation-program/acknowledgements/#certificate),還有舉辦[翻譯排行榜](/contributing/translation-program/acknowledgements/)以及[在網站上列出我們所有的譯者](/contributing/translation-program/contributors/)。
-## 如何翻譯帶有 `` 的語句? {#tags}
+## 如何翻譯帶有 `` 的字串? {#tags}
-並非每個語句都以純文本形式編寫。 有些語句包含 HTML 標籤 (`<0>`, `0>`) 等混合腳本。這些標籤通常用於表示句子中間的一些超連結或其他格式。
+並非每個語句都以純文本形式編寫。 有些字串包含混合腳本,例如 HTML 標籤 (`<0>`、`0>`)。這通常用於句子中間的超連結或替代樣式。
-- 翻譯標籤內的文字,但不翻譯標籤本身。 不能翻譯或刪除 `<` 和 `>` 中的任何內容。
+- 翻譯標籤內的文字,但不翻譯標籤本身。 在 `<` 和 `>` 中的任何內容都不得翻譯或移除。
- 為了保持語句完整,建議按一下左下方的「複製原文」按鈕。 這將複製原文語句,並貼進文本框中。 這讓你釐清標籤的位置,幫助你避免錯誤。

你可以在語句中移動標籤的位置,使其在句子中更加自然 — 但請確保移動整個標籤。
-更多關於處理標籤和程式碼片段的詳細資訊,請參閱 [ethereum.org 翻譯風格指南](/contributing/translation-program/translators-guide/#dealing-with-tags)。
+關於處理標籤和程式碼片段的更深入資訊,請參閱 [ethereum.org 翻譯風格指南](/contributing/translation-program/translators-guide/#dealing-with-tags)。
## 上下文在哪裡? {#strings}
一般而言,光是原文語句可能不足以讓你提供準確翻譯。
- 看看「screenshots」和「screenshots」來獲得更多資訊。 在原文語句區段,你將看到附上的螢幕擷取畫面,從而瞭解該語句的上下文。
-- 如你依然有疑惑,請在「Comments」區段中提出問題。 [不確定要如何留下一則評論?](#comment)
+- 如你依然有疑惑,請在「Comments」區段中提出問題。 [不確定如何留言?](#comment)
-
+

@@ -52,11 +52,11 @@ ethereum.org 翻譯計劃是其延伸,並且其組織方式考慮了相近的
- 問題一旦提交,將會報告給我們的團隊。 我們將解決這個問題,並透過回覆你的評論和關閉問題來回應你。
- 如果你上報錯誤的翻譯,那麼在下次審查期間,母語人士將審核目前的翻譯以及你建議的翻譯。
-
+
## 甚麼是翻譯記憶 (TM)? {#translation-memory}
-翻譯記憶 (TM) 是 Crowdin 的一項功能,能夠儲存 [ethereum.org](https://ethereum.org/) 中所有先前翻譯過的語句。 翻譯過的語句會自動儲存到專案 TM 中。 這款實用工具可以幫助你節省時間!
+翻譯記憶 (TM) 是 Crowdin 的一項功能,能夠儲存 ethereum.org 中所有先前翻譯過的語句。 翻譯過的語句會自動儲存到專案 TM 中。 這款實用工具可以幫助你節省時間!
- 查看「TM and MT Suggestions」區段,你可以看到其他譯者如何翻譯相同或類似語句。 如果發現匹配率很高的建議,可以按一下該建議來引用該翻譯內容。
- 如果清單中沒有任何內容,你可以搜索 TM 中以前做過的翻譯,並重新使用以保持一致性。
@@ -65,25 +65,25 @@ ethereum.org 翻譯計劃是其延伸,並且其組織方式考慮了相近的
## 如何使用 Crowdin 詞彙表? {#glossary}
-以太坊術語是我們翻譯工作的另一個關鍵部分,因為通常新的技術術語在許多語言中還沒有完成本地化。 另外,有些術語在不同的上下文中有不同的含義。 [更多關於以太坊術語的資訊](#terminology)
+以太坊術語是我們翻譯工作的另一個關鍵部分,因為通常新的技術術語在許多語言中還沒有完成本地化。 另外,有些術語在不同的上下文中有不同的含義。 [更多關於翻譯以太坊術語的資訊](#terminology)
Crowdin 詞彙表是釐清術語和定義的最佳場所。 有兩種方法來參考詞彙表。
- 首先,當你在原文語句中發現帶底線的術語時,將滑鼠移到上面,就能夠看到概要定義。
-
+
- 其次,如果看見一個不熟悉但沒有底線的術語,你可以在詞彙表標籤(右邊欄目的第三個按鈕)內搜尋該術語。 你將找到特定術語和專案中常用術語的解釋。
-
+
- 如果仍舊找不到該術語,可以藉此機會添加新術語! 我們建議你在搜尋引擎上進行搜尋,並將描述新增到詞彙表。 這將非常有助於其他譯者更好地理解該術語。
-
+
### 術語翻譯原則 {#terminology}
-_適用於名稱(品牌、公司、人員)和新技術術語(信標鏈、分片鏈,等等)。_
+_適用於名稱 (品牌、公司、人員) 和新技術術語 (信標鏈、分片鏈等)_
以太坊提出了很多最近提出的新術語。 由於沒有各自語言的官方譯文,因此譯者對有些術語的翻譯不同。 這種不一致會導致誤解且降低可讀性。
@@ -93,7 +93,7 @@ _適用於名稱(品牌、公司、人員)和新技術術語(信標鏈、
如果發現你不熟悉的術語,建議你:
-- 參考[術語詞彙表](#glossary),你可能會找到其他譯者之前的譯法。 如你覺得先前翻譯的術語不恰當,請隨時向 Crowdin 詞彙表新增一個新術語來還原你的翻譯準確度。
+- 請參閱[術語詞彙表](#glossary),您可能會找到其他譯者先前的譯法。 如你覺得先前翻譯的術語不恰當,請隨時向 Crowdin 詞彙表新增一個新術語來還原你的翻譯準確度。
- 如果詞彙表中先前沒有翻譯,建議你在搜尋引擎或媒體文章中搜尋,以說明該術語在社群中的實際使用情況。
- 如果根本找不到任何參考資料,請按你的直覺和理解進行翻譯!
- 如果不確定術語的涵義,可以保留不譯。 有時候,英文術語足以傳達準確定義。
@@ -102,15 +102,15 @@ _適用於名稱(品牌、公司、人員)和新技術術語(信標鏈、
## 審核過程是怎樣進行的? {#review-process}
-為確保我們的翻譯品質和一致性達到一定水平,我們與 [Acolad](https://www.acolad.com/) 合作。Acolad 是全球最大的語言服務提供者之一。 Acolad 有 20,000 名專業語言學家,這意味著表他們可以針對我們需要的每種語言以及內容類型提供專業的審核人員。
+為確保我們的翻譯達到一定的品質和一致性水準,我們與全球最大的語言服務供應商之一 [Acolad](https://www.acolad.com/) 合作。 Acolad 有 20,000 名專業語言學家,這意味著表他們可以針對我們需要的每種語言以及內容類型提供專業的審核人員。
-審核過程簡單直接;一旦一個特定 [內容門類](/contributing/translation-program/content-buckets) 100% 翻譯完成,我們便安排對該內容進行審核。 審核過程直接在 Crowdin 中進行。 一旦審核完成,我們會把翻譯好的內容更新到網站中。
+審核流程很直接;一旦某組內容 100% 翻譯完成,我們就會為該內容集安排審核。 審核過程直接在 Crowdin 中進行。 一旦審核完成,我們會把翻譯好的內容更新到網站中。
## 如何以我的語言新增內容? {#adding-foreign-language-content}
現時,所有非英文內容是直接從英文來源內容翻譯過來的,並且任何英文中不存在的內容都不能新增到其他語言中。
-若要為 ethereum.org 提議新內容,你可以在 GitHub 上[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues)。 如果要添加內容,將以英文編寫並透過 Crowdin 翻譯成其他語言。
+若要為 ethereum.org 建議新內容,您可以在 GitHub 上[建立問題](https://github.com/ethereum/ethereum-org-website/issues)。 如果要添加內容,將以英文編寫並透過 Crowdin 翻譯成其他語言。
我們計劃在不久的將來支持以非英文新增內容。
diff --git a/public/content/translations/zh-tw/contributing/translation-program/how-to-translate/index.md b/public/content/translations/zh-tw/contributing/translation-program/how-to-translate/index.md
index da46157433e..e8b68a41a05 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/how-to-translate/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/how-to-translate/index.md
@@ -6,51 +6,50 @@ description: 使用 Crowdin 翻譯 ethereum.org 的說明
# 如何翻譯 {#how-to-translate}
-## 影片指南 {#visual-guide}
+## 視覺化指南 {#visual-guide}
對於喜歡從影片學習者,請觀看 Luka 演示逐步完成設定 Crowdin。 此外,你可以在下一節的書面格式中找到相同步驟。
-## 書寫指南 {#written-guide}
+## 文字指南 {#written-guide}
-### 在 Crowdin 中加入我們的專案 {#join-project}
+### 在 Crowdin 加入我們的專案 {#join-project}
你需要登入 Crowdin 帳戶,如果你還沒有則請註冊帳戶。 只需要電子郵件帳戶和密碼便可註冊。
- 參與專案
+ 加入專案
-### 選擇語言 {#open-language}
+### 開啟您的語言 {#open-language}
-登入 Crowdin 後,你將看到專案描述和所有可用語言的清單。 每種語言還包含有關可翻譯單字總數的資訊,以及特定語言已翻譯和核准的內容數量的概述。
+登入 Crowdin 後,你將看到專案描述和所有可用語言的清單。
+每種語言還包含有關可翻譯單字總數的資訊,以及特定語言已翻譯和核准的內容數量的概述。
打開你要翻譯的語言,查看可進行翻譯的檔案清單。

-### 尋找要翻譯的文件 {#find-document}
+### 尋找要處理的文件 {#find-document}
網站內容分為許多文件和內容門類。 你可以在右邊查看每份文件的進度—如果翻譯進程低過100%,請你不吝作出貢獻吧!
-找不到你的語言? [開啟一個議題](https://github.com/ethereum/ethereum-org-website/issues/new/choose) 或在我們的 [Discord](https://discord.gg/ethereum-org) 頻道內提問。
+找不到你的語言? [開設一個議題](https://github.com/ethereum/ethereum-org-website/issues/new/choose)或在我們的 [Discord](https://discord.gg/ethereum-org) 中提問

-關於內容門類的說明:我們在 Crowdin 內用「內容門類」來先釋出最高優先順序的內容。 當你查看一種語言時,例如,[菲律賓語](https://crowdin.com/project/ethereum-org/fil#) ,你將會看見「內容門類」的一些文件夾(「1. Homepage」、「2. Essentials」、「3. Exploring」等)。
+關於內容門類的說明:我們在 Crowdin 內用「內容門類」來先釋出最高優先順序的內容。 當您檢視一種語言時 (例如 [菲律賓語](https://crowdin.com/project/ethereum-org/fil#)),您會看到內容分類的資料夾 ("1. Homepage」、「2. Essentials」、「3. Exploring」等)。
我們建議你按照數字順序來翻譯 (1 → 2 → 3 → ⋯),以確保影響力最大的頁面最先翻譯。
-[瞭解有關 ethereum.org 內容門類的更多資訊](/contributing/translation-program/content-buckets/)
-
### 翻譯 {#translate}
當你選擇想翻譯的檔案後,它將在線上編輯器內開啟。 如果你從未使用過 Crowdin,可使用這份快速指南來瞭解基礎知識。

-**_1 — 左側邊欄_**
+**_1 – 左側邊欄_**
- 未翻譯(紅色)— 尚未翻譯的文字。 這些是你應該翻譯的語句。
- 翻譯完成(綠色)— 已翻譯但尚未審核的文字。 歡迎你提出其他翻譯建議,或使用加號「+」和減號「-」按鈕在編輯器內對現有翻譯投票。
@@ -58,23 +57,24 @@ description: 使用 Crowdin 翻譯 ethereum.org 的說明
你也可以使用頂部的按鈕來搜尋一些特定字串,透過狀態篩選或變更視圖。
-**_2 — 編輯區域_**
+**_2 – 編輯區域_**
-主要的翻譯區域 — 原文顯示在頂部,如果有的話,還有上下文和螢幕擷取畫面可提供。 要提議新翻譯,請在「Enter translation here」欄位輸入你的翻譯並按一下「Save」。
+主要的翻譯區域 — 原文顯示在頂部,如果有的話,還有上下文和螢幕擷取畫面可提供。
+要提議新翻譯,請在「Enter translation here」欄位輸入你的翻譯並按一下「Save」。
你還可以在此區段找到語句的現有翻譯和其他語言的翻譯、翻譯記憶匹配項和機器翻譯建議。
-**_3 — 右側邊欄_**
+**_3 – 右側邊欄_**
在這裡你可以找到評論、翻譯記憶和詞彙表條目。 預設視圖會顯示評論,讓譯者能夠互相溝通,提出問題或報告錯誤的翻譯。
透過使用頂部的按鈕,你還可以切換到翻譯記憶。在那裡,你可以搜尋現有的翻譯,或者切換到「詞彙表」,其中包含關鍵術語的描述和標準翻譯。
-想瞭解更多嗎? 請隨時查看[有關使用 Crowdin 線上編輯器的文件](https://support.crowdin.com/online-editor/)
+想瞭解更多嗎? 歡迎隨時查看[關於使用 Crowdin 線上編輯器的文件](https://support.crowdin.com/online-editor/)
-### 審核過程 {#review-process}
+### 審核流程 {#review-process}
-一旦你已經完成了翻譯(即內容門類中的所有檔案都顯示為 100%),我們的專業翻譯服務將會審核(並可能會編輯)這些內容。 一旦審核完成(如:審核進度為 100%),我們將把內容新增到網站上。
+一旦您完成翻譯 (即內容分類的所有檔案都顯示 100%),我們的專業翻譯服務將會審核 (並可能編輯) 內容。 審核完成後 (即審核進度為 100%),我們會將其新增至網站。
@@ -85,7 +85,7 @@ description: 使用 Crowdin 翻譯 ethereum.org 的說明
### 聯絡我們 {#get-in-touch}
-還有其他問題嗎? 或是想要跟我們的團隊和其他譯者合作? 請在我們的 [ethereum.org Discord 伺服器](https://discord.gg/ethereum-org)的 #translations 頻道中發布帖子
+還有其他問題嗎? 或是想要跟我們的團隊和其他譯者合作? 請在我們的 [ethereum.org Discord 伺服器](https://discord.gg/ethereum-org) 的 #translations 頻道中發文
也可以透過 translations@ethereum.org 聯絡我們
diff --git a/public/content/translations/zh-tw/contributing/translation-program/index.md b/public/content/translations/zh-tw/contributing/translation-program/index.md
index 9d706137934..970c2478e37 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/index.md
@@ -10,81 +10,82 @@ description: 有關 ethereum.org 翻譯計劃的資訊

-## 幫助我們翻譯 {#help-us-translate}
+## 協助我們翻譯 {#help-us-translate}
ethereum.org 翻譯計劃是開放的,所有人都可以參與其中!
1. 你將需要登入 Crowdin 帳戶或是註冊一個 Crowdin 帳戶。
2. 選擇你想要翻譯的語言。
-3. 在開始之前,請查看[如何翻譯](/contributing/translation-program/how-to-translate/)指南,學習如何使用 Crowdin 和[翻譯風格指南](/contributing/translation-program/translators-guide/),瞭解翻譯小提示和最佳做法。
+3. 開始前,請先查看[如何翻譯](/contributing/translation-program/how-to-translate/)指南,了解如何使用 Crowdin,並參閱[翻譯風格指南](/contributing/translation-program/translators-guide/),以獲得提示和最佳做法。
4. 機器翻譯將無法通過審核。
5. 所有翻譯在加進網站前都會經過審核,所以你的翻譯上線前會有短暫的延遲。
-_加入 [ethereum.org Discord](https://discord.gg/ethereum-org) 合作翻譯、提出問題、分享回饋和想法,或加入翻譯小組。_
+_加入 [ethereum.org Discord](https://discord.gg/ethereum-org) 進行翻譯協作、提出問題、分享回饋和想法,或加入翻譯小組。_
開始翻譯
-## 關於翻譯計劃 {#about-us}
+## 關於翻譯計畫 {#about-us}
以太坊社群旨在成為全球化和包容性的社群,但大部分內容僅面向英語使用者,忽略了全球 60 億非英語使用者。 為了讓 ethereum.org 成為全球社群接觸以太坊的入口網站,我們認為很有必要為非英語國家人士以其母語提供以太坊內容。
ethereum.org 翻譯計劃旨在透過將 ethereum.org 和其他以太坊內容翻譯成盡可能多的語言,讓所有人都能參與以太坊。
-詳細瞭解 ethereum.org 翻譯計劃的[使命和願景](/contributing/translation-program/mission-and-vision)。
+閱讀更多關於 ethereum.org 翻譯計畫的[使命與願景](/contributing/translation-program/mission-and-vision)。
-### 我們迄今為止取得的進展 {#our-progress}
+### 我們目前的進度 {#our-progress}
-- [**超過 6,000 位**譯者](/contributing/translation-program/contributors/)
-- 網站支持 **62** 種語言
-- [2023 年翻譯了 **300 萬**字](/contributing/translation-program/acknowledgements/)
+- [**超過 6,900 位**譯者](/contributing/translation-program/contributors/)
+- **68** 種語言在網站上線
+- [2024 年已翻譯 **289 萬**字](/contributing/translation-program/acknowledgements/)
### 致謝 {#acknowledgements}
-數以千計的社群成員參與 Ethereum.org 網站的翻譯,是翻譯計劃的關鍵組成部分。 我們想感謝我們的譯者,並為他們的職業生涯提供支援。 以下是我們對譯者的一些致謝:
+數以千計的社群成員參與 Ethereum.org 網站的翻譯,是翻譯計劃的關鍵組成部分。
+我們想感謝我們的譯者,並為他們的職業生涯提供支援。 以下是我們對譯者的一些致謝:
#### 證書 {#certificate}
-如果你為翻譯計劃作出貢獻,並且至少有 5000 個翻譯單字已獲核准,就有資格獲得 ethereum.org 譯者證書。 [有關證書的更多資訊](/contributing/translation-program/acknowledgements/#certificate)
+如果你為翻譯計劃作出貢獻,並且至少有 5000 個翻譯單字已獲核准,就有資格獲得 ethereum.org 譯者證書。 [更多關於證書的資訊](/contributing/translation-program/acknowledgements/#certificate)
-#### 鏈上成就代幣 (OAT) {#oats}
+#### OATs {#oats}
-根據 2024 年翻譯的字數,翻譯計畫的貢獻者有資格獲得不同的 OAT(鏈上成就代幣)。 鏈上成就代幣是非同質化代幣 (NFT),可以證明你對 ethereum.org 翻譯計劃的貢獻。 [有關鏈上成就代幣的更多資訊](/contributing/translation-program/acknowledgements/#oats)
+根據 2024 年翻譯的字數,翻譯計畫的貢獻者有資格獲得不同的 OAT(鏈上成就代幣)。 鏈上成就代幣是非同質化代幣 (NFT),可以證明你對 ethereum.org 翻譯計劃的貢獻。 [更多關於 OATs 的資訊](/contributing/translation-program/acknowledgements/#oats)
-#### 致謝譯者 {#translator-acknowledgements}
+#### 譯者致謝 {#translator-acknowledgements}
-透過[排行榜](/contributing/translation-program/acknowledgements/)和[翻譯計劃貢獻者清單](/contributing/translation-program/contributors/),對我們的最優秀譯者公開致謝。
+透過[排行榜](/contributing/translation-program/acknowledgements/)公開表揚我們的頂尖譯者,並提供[翻譯計畫所有貢獻者的名單](/contributing/translation-program/contributors/)。
-#### 酬勞 {#rewards}
+#### 獎勵 {#rewards}
-過去,我們追加獎勵了最活躍的貢獻者,為其提供參加 [Devcon](https://devcon.org/en/) 和 [Devconnect](https://devconnect.org/) 等以太坊會議的門票,以及獨家 ethereum.org 商品。
+過去,我們曾追溯性地獎勵最活躍的貢獻者,提供他們參加 [Devcon](https://devcon.org/en/) 和 [Devconnect](https://devconnect.org/) 等以太坊會議的門票,以及獨家的 ethereum.org 商品。
我們不斷思考創新方式來獎勵我們的貢獻者,敬請期待!
-### 指南及資源 {#guides-and-resources}
+### 指南與資源 {#guides-and-resources}
如果你正在為翻譯計劃做出貢獻或考慮參與其中,應該查看以下翻譯指南:
-- [翻譯風格指南](/contributing/translation-program/translators-guide/)_ — 給 ethereum.org 譯者的說明和小提示_
-- [翻譯常見問題](/contributing/translation-program/faq/)_ — 有關 ethereum.org 翻譯計劃的常見問題和答案_
-- [Crowdin 線上編輯器指南](https://support.crowdin.com/online-editor/)_ — 使用 Crowdin 線上編輯器和 Crowdin 的一些進階功能的深度指南_
-- [內容門類](/contributing/translation-program/content-buckets/)_ — ethereum.org 每個內容門類包含哪些頁面_
+- [翻譯風格指南](/contributing/translation-program/translators-guide/) _– 為 ethereum.org 譯者提供的說明與提示_
+- [翻譯常見問題](/contributing/translation-program/faq/) _– 關於 ethereum.org 翻譯計畫的常見問題與解答_
+- [Crowdin 線上編輯器指南](https://support.crowdin.com/online-editor/) _– 深入介紹如何使用 Crowdin 線上編輯器及 Crowdin 部分進階功能的指南_
-有關其他有用的翻譯工具、譯者社群和翻譯計劃部落格文章,請造訪[資源頁面](/contributing/translation-program/resources/)。
+若要尋找其他實用的翻譯工具、譯者社群和翻譯計畫的部落格文章,請造訪[資源頁面](/contributing/translation-program/resources/)。
-## 聯繫我們 {#get-in-touch}
+## 聯絡我們 {#get-in-touch}
-還有其他問題嗎? 或是想要跟我們的團隊和其他譯者合作? 請在我們 [ethereum.org Discord 伺服器](https://discord.gg/ethereum-org)的 #translations 頻道發帖
+還有其他問題嗎? 或是想要跟我們的團隊和其他譯者合作? 請在我們的 [ethereum.org Discord 伺服器](https://discord.gg/ethereum-org) 的 #translations 頻道中發文
也可以透過 translations@ethereum.org 聯絡我們
-## 開啟你自己的翻譯計劃 {#starting-a-translation-program}
+## 啟動您自己的翻譯計畫 {#starting-a-translation-program}
-我們致力於將以太坊內容翻譯成盡可能多的語言,並且向所有人提供教育內容。 我們很重視翻譯,想協助其他以太坊專案整合、管理,和改善它們自身的翻譯工作。
+我們致力於將以太坊內容翻譯成盡可能多的語言,並且向所有人提供教育內容。
+我們很重視翻譯,想協助其他以太坊專案整合、管理,和改善它們自身的翻譯工作。
-因此,我們製作了一份[翻譯計劃手冊](/contributing/translation-program/playbook/),裡面有一些我們在翻譯 ethereum.org 過程中發現的小提示和最佳做法。
+為此,我們建立了一份[翻譯計畫手冊](/contributing/translation-program/playbook/),其中包含我們在翻譯 ethereum.org 的過程中學到的一些技巧和最佳實踐。
想要進一步和我們合作,或使用我們的某些翻譯資源嗎? 對手冊有任何意見回饋? 歡迎你透過 translations@ethereum.org 向我們反饋你的意見。
diff --git a/public/content/translations/zh-tw/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/zh-tw/contributing/translation-program/mission-and-vision/index.md
index 733dbc905af..e3abd9aceef 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/mission-and-vision/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/mission-and-vision/index.md
@@ -4,7 +4,7 @@ lang: zh-tw
description: ethereum.org 翻譯計畫的使命和願景
---
-# 使命和願景 {#mission-and-vision}
+# 使命與願景 {#mission-and-vision}
以太坊社群旨在成為全球化和包容性的社群,但大部分內容僅面向英語使用者,忽略了全球 60 億非英語使用者。 為了讓 ethereum.org 成為全球社群接觸以太坊的入口網站,我們認為很有必要為非英語國家人士以其母語提供以太坊內容。
diff --git a/public/content/translations/zh-tw/contributing/translation-program/playbook/index.md b/public/content/translations/zh-tw/contributing/translation-program/playbook/index.md
new file mode 100644
index 00000000000..c25065032b6
--- /dev/null
+++ b/public/content/translations/zh-tw/contributing/translation-program/playbook/index.md
@@ -0,0 +1,317 @@
+---
+title: 翻譯程序操作手冊
+lang: zh-tw
+description: 建立翻譯項目的實用技巧與重要注意事項合集
+---
+
+# 翻譯程序操作手冊{#translation-program-playbook}
+
+英語是世界上使用最廣泛的語言之一,也是迄今為止全球學習人數最多的語言。 由於英語是互聯網上最常用的語言——尤其在社交媒體領域——且多語言編程語言較為稀缺,區塊鏈領域的大部分內容都以英語為母語編寫。
+
+然而,全球超過60億人(占總人口的75%以上)完全不會說英語,這為絕大多數人接觸以太坊設置了巨大的門檻。
+
+正因如此,該領域越來越多的項目正尋求將內容翻譯成不同語言並進行本地化,以面向全球市場。
+
+提供多語言內容是拓展全球社區、為非英語使用者提供教育、確保內容與信息觸達更廣泛受眾、並吸引更多人加入該領域的簡單而有效的方式。
+
+本指南旨在解決內容本地化過程中常見的挑戰與誤解。 它提供了一個分步指南,涵蓋內容管理、翻譯與審校流程、質量保證、譯員招募以及本地化流程中的其他關鍵環節。
+
+## 内容管理{#content-management}
+
+翻譯內容管理是指通過自動化翻譯工作流程,消除重複性手動操作,提升效率與質量,實現更佳管控,並促進協作的過程。
+
+在本地化過程中,內容管理存在多種不同的方法,具體取決於內容類型和您的需求。
+
+管理內容的基本方法是創建雙語文件,其中包含源文本和目標文本。 這種譯法很少被採用,因為除了簡潔之外,它並無顯著優勢。
+
+翻譯機構通常通過使用翻譯管理軟件或本地化工具來管理翻譯項目,這些工具不僅具備項目管理功能,還能對文件、內容及譯員實現更全面的管控。
+
+閱讀更多關於內容管理:
+
+[Trados 談什麼是翻譯管理](https://www.trados.com/solutions/translation-management/)
+
+[關於多語言內容管理的用語](https://phrase.com/blog/posts/multilingual-content-management/)
+
+### 翻譯管理軟件{#translation-management-software}
+
+市面上有許多翻譯管理系統和本地化工具,軟件的選擇主要取決於您的具體需求。
+
+儘管某些項目選擇不使用翻譯管理系統,而傾向於手動翻譯——無論是直接在雙語文件中操作,還是藉助GitHub等託管服務——這種做法都會顯著降低項目控制力、生產效率、翻譯質量、可擴展性及協作能力。 這種方法可能最適合小型或一次性翻譯項目。
+
+快速了解一些功能強大且廣泛使用的翻譯管理工具:
+
+**最適合群眾外包與協作**
+
+[Crowdin](https://crowdin.com/)
+
+- 開放原始碼專案免費使用(不限字符串數量與專案數量)
+- 所有方案皆提供翻譯記憶及詞彙表
+- 支援超過 60 種檔案格式,超過 70 種 API 整合
+
+[Lokalise](https://lokalise.com/)
+
+- 2 位團隊成員可免費使用,更多貢獻者可選擇付費方案 (多數方案的字串數量有限)
+- 部分付費方案提供翻譯記憶與詞彙表
+- 支援超過 30 種檔案格式,超過 40 種 API 整合
+
+[Transifex](https://www.transifex.com/)
+
+- 僅提供付費方案 (多數方案的字串數量有限)
+- 所有付費方案皆提供翻譯記憶與詞彙表
+- 支援超過 30 種檔案格式,超過 20 種 API 整合
+
+[Phrase](https://phrase.com/)
+
+- 僅提供付費方案 (所有方案的字串數量無上限,但專案及團隊成員數量有限)
+- 部分付費方案提供翻譯記憶與詞彙表
+- 支援超過 40 種檔案格式,超過 20 種 API 整合
+
+[Smartcat](https://www.smartcat.com/)
+
+- 提供基本免費方案及付費進階功能 (所有方案的字串與專案數量皆無上限)
+- 所有方案皆提供翻譯記憶及詞彙表
+- 支援超過 60 種檔案格式,超過 20 種 API 整合
+
+[POEditor](https://poeditor.com/)
+
+- 開放原始碼專案可免費使用 (所有專案皆有字串數量限制,但開放原始碼專案則無限制)
+- 付費方案提供翻譯記憶與詞彙表
+- 支援超過 20 種檔案格式,超過 10 種 API 整合
+
+以及其他許多...
+
+**專業翻譯工具**
+
+[SDL Trados Studio](https://www.trados.com/products/trados-studio/)
+
+- 為自由譯者與團隊提供的付費方案
+- 功能強大的電腦輔助翻譯 (CAT) 工具與譯者生產力軟體
+
+[MemoQ](https://www.memoq.com/)
+
+- 提供功能有限的免費版本,以及數種提供進階功能的付費方案
+- 適用於公司、語言服務供應商及譯者的翻譯管理軟體
+
+[Memsource](https://www.memsource.com/)
+
+- 個人譯者可免費使用,並提供數種團隊用付費方案
+- 雲端電腦輔助翻譯與翻譯管理系統
+
+以及其他許多...
+
+進一步了解翻譯管理軟體:
+
+[維基百科對翻譯管理系統的定義](https://en.wikipedia.org/wiki/Translation_management_system)
+
+[Phrase 談每個翻譯管理軟體都應具備的 7 件事](https://phrase.com/blog/posts/7-things-every-translation-management-software-should-have/)
+
+[MemoQ 談什麼是翻譯管理系統](https://www.memoq.com/tools/what-is-a-translation-management-system)
+
+[Gengo 的 16 個最佳翻譯管理系統清單](https://gengo.com/translator-product-updates/16-best-translation-management-systems/)
+
+## 工作流程 {#workflow}
+
+在翻譯領域中,「翻譯工作流程」可指代幾種不同概念,這些概念彼此略有關聯,且都是您專案中需重點考量的要素。
+
+我們將在下文探討這兩種情況。
+
+**意涵 1**
+
+這可能是人們理解翻譯工作流程最常見的方式,也是聽到“工作流程”這個詞時通常會想到的內容。
+
+本質上,這是從開始考慮翻譯到在產品中使用翻譯內容的整個工作流程。
+
+在此情況下,一個示例工作流如下:
+
+1. **翻譯文件的準備工作**——聽起來很簡單,但你需要考慮幾個重要事項。 在此步驟中,您應該對整個流程的運作方式有清晰的規劃。
+
+- _您將使用哪些檔案類型?_ 您希望以何種格式接收翻譯後的文件?_
+ - 若您的內容以DOCX或MD格式提供,翻譯過程將比處理PDF版本的白皮書或其他文檔簡單得多。
+- _哪些本地化工具支持此文件类型? 能否在翻譯該文件時保留原始格式?_
+ - 並非所有文件類型都支持直接本地化(例如PDF文件、圖像文件),也並非所有本地化工具都支持所有文件類型。
+- _將由誰來翻譯內容?_ 您將選擇專業翻譯服務還是依靠志願者?_
+ - 這會影響到你需要做出的其他若干決定。 例如,專業翻譯人員比志願者更擅長使用高級本地化工具。
+- _你對語言學家有什麼期望? 如果您正在使用語言服務供應商,他們對您有什麼期望?_
+ - 此步驟是為了確保您的目標、期望和時程規劃能夠保持一致。
+- 所有待譯內容的重要性是否相同? 是否應先翻譯某些內容?_
+ - 存在若干方法可用於確定特定內容的優先級,這些內容應優先進行翻譯與實施。 例如,如果你有大量內容需要翻譯,可以使用版本控制來確保譯者清楚哪些內容需要優先處理。
+
+2. **共享待譯文件**——這一步驟同樣需要長遠考量,並非像將源文件發送給語言服務供應商那樣簡單直接。
+
+- _將由誰來翻譯內容?_ 多少人在這一步驟中被包含了?_
+ - 若計劃使用本地化工具,此步驟將得到簡化,因為您可以直接將源文件上傳至該工具。 即使翻譯過程在託管服務上進行,情況也是如此,因為源文件無需導出到任何地方。
+- _源文件將進行人工處理,還是可以實現自動化處理?_
+ - 大多數本地化工具都支持某種形式的文件管理流程集成或自動化。 另一方面,若您採用的是獨立譯員協作模式而非本地化工具,手動向數百甚至數千名譯員發送源文件的做法顯然難以實現規模化運作。
+- _本地化將使用哪些工具?_
+ - 這個問題的答案將決定你處理其他所有事情的方式。 選擇合適的工具可助您實現內容管理自動化,包括管理翻譯記憶庫和術語庫、管理譯員、追蹤翻譯/審校進度等,因此請花些時間研究您想要使用的工具。 若您不打算使用本地化工具,則上述所有操作均需手動完成。
+- _翻譯過程需要多長時間? 要花多少錢?_
+ - 此時,您應該準備好將源文件分享給語言服務提供商或翻譯團隊。 語言服務供應商可協助您分析字數統計並提供報價,其中包含翻譯流程的費率及時間安排。
+- _您是否計劃在此過程中對源內容進行修改/更新?_
+ - 如果您的內容具有動態性且頻繁變更,任何修改或更新都可能打亂翻譯進度。 使用翻譯記憶庫可顯著緩解此問題,但仍需仔細規劃工作流程,避免阻礙譯者的翻譯進度。
+
+3. **管理翻譯流程**——源內容移交給語言服務供應商或譯員後,您的工作並未結束。 為確保翻譯質量達到最佳水平,內容創作者應儘可能深度參與翻譯流程。
+
+- _您計劃如何與譯員進行溝通?_
+ - 若您計劃使用本地化工具,溝通可直接在工具內進行。 建議與譯員建立備用溝通渠道,因為他們可能更願意主動聯繫,而即時通訊工具能實現更自由的交流。
+- 如何處理譯者的提問? 誰應該回答這些問題?_
+ - 譯者 (無論是專業或非專業) 時常會提出問題、請求釐清、要求更多脈絡資訊,以及提供回饋與改進建議。 回覆這些詢問通常能帶來更高的參與度,並提升翻譯內容的品質。 為他們盡可能提供資源 (例如:指南、提示、術語準則、常見問題等) 也相當有幫助。
+- _如何處理審閱流程?_ 您想將其外包,還是有能力在內部進行審閱?_
+ - 雖然並非總是必要,但審閱是最佳翻譯流程中不可或缺的一環。 通常,將審閱流程外包給專業審閱者是最簡單的方法。 然而,若您有大型的國際團隊,審閱或品質保證 (QA) 也可以在內部進行。
+
+4. **導入翻譯內容** – 這是工作流程的最後一個部分,但仍需提前考量。
+
+- _所有翻譯都會同時完成嗎?_
+ - 若否,您應思考哪些翻譯應優先處理、如何追蹤進行中的翻譯,以及翻譯完成後如何處理導入作業。
+- _翻譯好的內容將如何交付給您?_ 會是哪種格式?_
+ - 無論您採用哪種方法,這都是一個重要的考量。 在地化工具能讓您掌控目標檔案格式與匯出流程,且通常支援自動化,例如:透過與託管服務整合。
+- _您將如何在專案中導入翻譯?_
+ - 在某些情況下,可能只是簡單地將翻譯好的檔案上傳,或將其新增至您的文件中。 然而,對於更複雜的專案,例如網站或應用程式翻譯,您應確保程式碼支援國際化,並提前規劃好導入流程將如何處理。
+- _如果格式與原始檔案不同該怎麼辦?_
+ - 與上述類似,如果您翻譯的是簡單的文字檔,格式可能就不是那麼重要。 然而,對於更複雜的檔案,例如網站或應用程式的內容,其格式和程式碼必須與原始檔案完全相同,才能導入您的專案。 否則,目標檔案將需要由譯者或您的開發人員進行編輯。
+
+**意涵 2**
+
+另一種翻譯工作流程,其不考量內部決策與方法。 這裡的主要考量是內容本身的流程。
+
+在此情況下,一個示例工作流如下:
+
+1. _翻譯 → 導入_
+
+- 最簡單的工作流程,其中翻譯很可能是人工翻譯,因為在導入前沒有審閱或品質保證流程來評估品質和編輯翻譯。
+- 在這個工作流程中,譯者能維持一定的品質非常重要,這將需要專案經理和譯者之間有適當的資源和溝通。
+
+2. _翻譯 → 審閱 → 導入_
+
+- 一個更進階的工作流程,其中包含審閱和編輯過程,以確保翻譯品質可接受且一致。
+- 這個工作流程有多種方法,翻譯可由專業譯者或志願者進行,而審閱過程則可能由專業審閱者處理,他們熟悉目標語言中需要遵守的所有文法和拼寫規則。
+
+3. _翻譯 → 審閱 → 品質保證 → 導入_
+
+- 確保最高品質水準的最佳工作流程。 雖然品保 (QA) 並非總是必要,但它有助於讓您在翻譯和審閱後,更清楚地了解翻譯文本的品質。
+- 透過這個工作流程,翻譯可以完全由志願者甚至機器翻譯來執行。 審閱過程應由專業譯者執行,而品保 (QA) 可由語言服務供應商執行,或者如果公司內部有目標語言的母語員工,也可以在內部進行。
+
+進一步了解翻譯工作流程:
+
+[Content Rules 談翻譯工作流程的五個階段](https://contentrules.com/creating-translation-workflow/)
+
+[Smartling 談什麼是翻譯工作流程管理](https://www.smartling.com/resources/101/what-is-translation-workflow-management/)
+
+[RixTrans 談翻譯工作流程](https://www.rixtrans.com/translation-workflow)
+
+## 術語管理 {#terminology-management}
+
+建立處理術語的明確計畫,是確保翻譯品質和一致性,並節省譯者時間的最重要步驟之一。
+
+在翻譯領域,這被稱為術語管理,是語言服務供應商除了提供語言專家人才庫和內容管理之外,為其客戶提供的關鍵服務之一。
+
+術語管理是指識別、收集和管理對您的專案至關重要,且應始終被正確且一致地翻譯的術語的過程。
+
+開始思考術語管理時,可以遵循以下幾個步驟:
+
+- 識別應納入術語庫的關鍵術語。
+- 建立術語及其定義的詞彙表。
+- 翻譯術語並將其新增至詞彙表。
+- 檢查並核准翻譯。
+- 維護詞彙表,並在出現新的重要術語時進行更新。
+
+進一步了解術語管理:
+
+[Trados 談什麼是術語管理](https://www.trados.com/solutions/terminology-management/translation-101-what-is-terminology-management.html)
+
+[Language Scientific 談術語管理的重要性](https://www.languagescientific.com/terminology-management-why-it-matters/#:~:text=Terminology%20management%20is%20the%20process,are%20related%20to%20each%20other.)
+
+[Clear Words Translation 談什麼是術語管理及其重要性](http://clearwordstranslations.com/language/en/what-is-terminology-management/)
+
+### 翻譯記憶與詞彙表 {#tm-and-glossary}
+
+翻譯記憶 (TM) 和詞彙表是翻譯產業的重要工具,也是大多數語言服務供應商所依賴的東西。
+
+讓我們來看看這些術語的含義,以及它們之間的區別:
+
+**翻譯記憶 (TM)** – 一個自動儲存句段或字串的資料庫,包括較長的文本區塊、完整句子、段落和個別術語,以及它們在各種語言中的當前和先前翻譯。
+
+大多數在地化工具、翻譯管理系統和電腦輔助翻譯工具都內建翻譯記憶,這些翻譯記憶通常也可以匯出並在其他類似工具中使用。
+
+使用翻譯記憶的好處包括:更快的翻譯速度、更好的翻譯品質、在更新或變更原始內容時保留特定翻譯的能力,以及降低重複內容的翻譯成本。
+
+翻譯記憶根據不同句段之間的百分比匹配度運作,當兩個句段包含超過 50% 的相同內容時,通常最為有用。 它們也用於自動翻譯重複的句段 (100% 匹配),從而無需多次翻譯重複的內容。
+
+進一步了解翻譯記憶:
+
+[Memsource 談翻譯記憶](https://www.memsource.com/translation-memory/)
+
+[Smartling 談什麼是翻譯記憶](https://www.smartling.com/resources/101/what-is-translation-memory/)
+
+**詞彙表 –** 一份包含重要或敏感術語、其定義、功能和既定翻譯的清單。 詞彙表和翻譯記憶之間的主要區別在於,詞彙表不是自動建立的,且不包含完整句子的翻譯。
+
+大多數在地化工具、翻譯管理系統和電腦輔助翻譯工具都有內建的詞彙表,您可以維護這些詞彙表,以確保它們包含對您專案重要的術語。 與翻譯記憶 (TM) 一樣,詞彙表通常也可以匯出並在其他在地化工具中使用。
+
+在開始翻譯專案之前,強烈建議您花一些時間為您的譯者和審閱者建立一份詞彙表。 使用詞彙表可以確保重要術語被正確翻譯,為譯者提供必要的脈絡,並保證翻譯的一致性。
+
+雖然詞彙表通常包含目標語言的既定翻譯,但即使沒有這些翻譯,它們也很有用。 即使沒有既定的翻譯,詞彙表也可以提供技術術語的定義,標示出不應翻譯的術語,並告知譯者某個特定術語是用作名詞、動詞、專有名詞還是任何其他詞性。
+
+進一步了解詞彙表:
+
+[Lionbridge 談什麼是翻譯詞彙表](http://info.lionbridge.com/rs/lionbridge/images/Lionbridge%20FAQ_Glossary_2013.pdf)
+
+[Transifex 談詞彙表](https://docs.transifex.com/glossary/glossary)
+
+如果您不打算在專案中使用在地化工具,您可能無法使用翻譯記憶和詞彙表 (您可以在 Excel 檔案中建立詞彙表或術語庫,但是,自動化的詞彙表免去了譯者手動查找術語及其定義的需要)。
+
+這意味著所有重複和相似的內容每次都必須手動翻譯。 此外,譯者將不得不詢問某些術語是否需要翻譯、它們在文本中如何使用,以及某個術語是否已有既定翻譯等問題。
+
+_您想在您的專案中使用 ethereum.org 的翻譯記憶和詞彙表嗎?_ 請透過 translations@ethereum.org 與我們聯絡。_
+
+## 譯者聯繫與招募 {#translator-outreach}
+
+**與語言服務供應商合作**
+
+如果您正在與語言服務供應商及其專業譯者合作,本節可能與您不太相關。
+
+在這種情況下,選擇一個有能力以多種語言提供您所需全部服務 (例如,翻譯、審閱、品保) 的語言服務供應商非常重要。
+
+雖然僅根據報價來選擇語言服務供應商可能很誘人,但值得注意的是,最大的語言服務供應商收費較高是有原因的。
+
+- 他們的資料庫中有數以萬計的語言專家,這意味著他們能夠為您的專案指派具有足夠經驗和特定領域知識的譯者 (即技術譯者)。
+- 他們在處理不同專案和滿足客戶多樣化需求方面擁有豐富的經驗。 這意味著他們更有可能適應您的特定工作流程,為您的翻譯流程提供有價值的建議和潛在的改進,並滿足您的需求、要求和期限。
+- 大多數大型語言服務供應商也擁有自己的在地化工具、翻譯記憶和詞彙表供您使用。 即使沒有,他們的人才庫中至少有足夠的語言專家,以確保其譯者熟悉並能夠使用您想使用的任何在地化工具。
+
+您可以在 [2021 Nimdzi 100 報告](https://www.nimdzi.com/nimdzi-100-top-lsp/)中找到對全球最大語言服務供應商的深入比較,以及關於每家供應商的一些詳細資訊,和按其提供的服務、地理數據等分類的分析。
+
+**與非專業譯者合作**
+
+您可能正在與非專業譯者合作,並尋找志願者來幫助您翻譯。
+
+有多種方法可以聯繫人們並邀請他們加入您的專案。 這在很大程度上取決於您的產品以及您已有的社群規模。
+
+以下概述了一些招募志願者的方法:
+
+**聯繫與招募 –** 雖然這在以下幾點中有所涉及,但聯繫潛在的志願者並確保他們了解您的翻譯計畫本身就是一種有效的方法。
+
+許多人想參與並為他們喜愛的專案做出貢獻,但如果不是開發人員或沒有特殊技術技能,他們往往看不到明確的方法。 如果您能提高專案的知名度,很多雙語人士可能會熱衷於參與。
+
+**從您的社群內部尋找 –** 該領域的大多數專案都已經擁有龐大而活躍的社群。 您的許多社群成員可能會很樂意有機會以簡單的方式為專案做出貢獻。
+
+雖然對開放原始碼專案的貢獻通常是基於內在動機,但這也是一個絕佳的學習體驗。 任何有興趣進一步了解您的專案的人,都很可能會樂意以志願者身份參與翻譯計畫,因為這能讓他們將「為自己在乎的事物做出貢獻」與「密集的實作學習體驗」結合起來。
+
+**在您的產品中提及此計畫 –** 如果您的產品很受歡迎且有大量使用者,在使用者使用產品時,突顯您的翻譯計畫並呼籲他們採取行動,可能會非常有效。
+
+對於應用程式和網站,這可以像在您的產品中添加帶有行動呼籲 (CTA) 的橫幅或彈出視窗一樣簡單。 這是有效的,因為您的目標受眾是您的社群——那些最有可能首先參與的人。
+
+**社群媒體 –** 社群媒體是宣傳您的翻譯計畫、聯繫您的社群成員以及尚未成為您社群成員的其他人的有效方式。
+
+如果您有 Discord 伺服器或 Telegram 頻道,可以輕易地利用它們進行聯繫、與譯者溝通以及表揚您的貢獻者。
+
+像 X (前身為 Twitter) 這樣的平台也有助於招募新的社群成員和公開表揚您的貢獻者。
+
+Linux 基金會撰寫了一份詳盡的 [2020 年 FOSS 貢獻者調查報告](https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf),分析了開放原始碼貢獻者及其動機。
+
+## 結論 {#conclusion}
+
+本文件包含每個翻譯計畫都應了解的一些關鍵考量因素。 這絕不是一份詳盡的指南,但它可以幫助任何在翻譯行業沒有經驗的人為他們的專案組織一個翻譯計畫。
+
+如果您正在尋找關於管理翻譯計畫的不同工具、流程和關鍵方面的更詳細說明和分析,一些最大的語言服務供應商會維護部落格並經常發表關於在地化流程不同方面的文章。 如果您想深入探討上述任何主題,並了解在地化流程在專業上是如何運作的,這些是最好的資源。
+
+每個部分的末尾都包含一些相關連結;但是,您可以在網路上找到許多其他資源。
+
+如果您有合作提案,或想了解更多資訊、經驗和我們透過維護 ethereum.org 翻譯計畫所學到的最佳實踐,請隨時透過 translations@ethereum.org 與我們聯絡。
diff --git a/public/content/translations/zh-tw/contributing/translation-program/resources/index.md b/public/content/translations/zh-tw/contributing/translation-program/resources/index.md
index 2877b21487f..dfd6fb70381 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/resources/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/resources/index.md
@@ -4,41 +4,46 @@ lang: zh-tw
description: 對 ethereum.org 譯者有用的資源
---
-# 資源 {#resources}
+# 資源{#resources}
你可以在下面找到一些對 ethereum.org 譯者有用的指南和工具,以及翻譯社群和更新。
## 指南 {#guides}
-- [翻譯風格指南](/contributing/translation-program/translators-guide/) _ — 給 ethereum.org 譯者的說明和小提示_
-- [翻譯常見問題](/contributing/translation-program/faq/)_ — 有關 ethereum.org 翻譯計劃的常見問題和答案_
-- [Crowdin 線上編輯器指南](https://support.crowdin.com/online-editor/)_ — 使用 Crowdin 線上編輯器和 Crowdin 的一些進階功能的深度指南_
-- [內容門類](/contributing/translation-program/content-buckets/)_ — ethereum.org 每個內容門類包含哪些頁面_
+- [翻譯風格指南](/contributing/translation-program/translators-guide/) _– 為 ethereum.org 翻譯人員提供的說明與秘訣_
+- [翻譯常見問題](/contributing/translation-program/faq/) _– 關於 ethereum.org 翻譯計畫的常見問題與解答_
+- [Crowdin 線上編輯器指南](https://support.crowdin.com/online-editor/) _– 深入介紹如何使用 Crowdin 線上編輯器及 Crowdin 部分進階功能的指南_
## 工具 {#tools}
-- [Linguee](https://www.linguee.com/)。 _ — 翻譯和字典搜尋引擎,可按詞或短語進行搜尋_
-- [Proz 術語搜尋](https://www.proz.com/search/) _ — 特殊術語的翻譯字典和詞彙表資料庫_
-- [Eurotermbank](https://www.eurotermbank.com/)_ — 42 種語言的歐洲術語集_
+- [Linguee](https://www.linguee.com/)
+ _– 翻譯與字典搜尋引擎,可按字詞或片語搜尋_
+- [Proz 術語搜尋](https://www.proz.com/search/)
+ _– 專門術語的翻譯字典與詞彙表資料庫_
+- [Eurotermbank](https://www.eurotermbank.com/)
+ _– 包含 42 種語言的歐洲術語集_
## 社群 {#communities}
-- [特定語言的 Discord 翻譯群組](https://discord.gg/ethereum-org) _ — 把 ethereum.org 譯者連結到翻譯群組的計劃_
-- [中文譯者的群組](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171)_ — 為了讓中國譯者之間更輕鬆地進行協調的概念頁面_
+- [特定語言的 Discord 翻譯群組](https://discord.gg/ethereum-org)
+ _– 一項旨在將 ethereum.org 翻譯人員連結至翻譯群組的計畫_
+- [中文翻譯人員群組](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171)
+ _– 方便中文翻譯人員協作的 Notion 頁面_
-## 最近更新 {#latest-updates}
+## 最新更新 {#latest-updates}
-要瞭解翻譯計劃的最新進展,你可以追蹤[以太坊基金會部落格](https://blog.ethereum.org/):
+若要隨時掌握翻譯計畫的最新進度,您可以追蹤 [以太坊基金會網誌](https://blog.ethereum.org/):
- [2021 年 10 月里程碑更新](https://blog.ethereum.org/2021/10/04/translation-program-update/)
- [2020 年 12 月里程碑更新](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/)
- [2020 年 7 月里程碑更新](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/)
-- [2019 年 8 月翻譯計劃啟動](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/)
+- [2019 年 8 月翻譯計畫啟動](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/)
## 譯者辦公時間 {#office-hours}
-我們在每月的第二個星期三會定期舉辦「譯者辦公時間」活動。 這會在 [ethereum.org Discord](https://discord.gg/ethereum-org) 的語音頻道 #office-hours 舉辦,你也可以在此確認舉辦的確切時間以及進一步的細節資訊。
+我們在每月的第二個星期三會定期舉辦「譯者辦公時間」活動。 辦公時間會在 [ethereum.org Discord](https://discord.gg/ethereum-org) 的 #office-hours 語音頻道舉行,您也可以在此處找到確切時間以及更多詳細資訊。
-在「譯者辦公時間」活動中,我們的譯者可以詢問有關翻譯過程的問題、提供有關專案的意見回饋、分享想法,或只是與 ethereum.org 核心團隊聊天。 最後,我們想利用這些通話溝通一下翻譯計劃近期的發展,與我們的貢獻者分享關鍵的翻譯小提示和說明。
+在「譯者辦公時間」活動中,我們的譯者可以詢問有關翻譯過程的問題、提供有關專案的意見回饋、分享想法,或只是與 ethereum.org 核心團隊聊天。
+最後,我們想利用這些通話溝通一下翻譯計劃近期的發展,與我們的貢獻者分享關鍵的翻譯小提示和說明。
如果你已經是或是想成為 ethereum.org 譯者,歡迎在這些階段加入我們。
diff --git a/public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md b/public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md
new file mode 100644
index 00000000000..a0f6b122469
--- /dev/null
+++ b/public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md
@@ -0,0 +1,90 @@
+---
+title: 詳細資訊與規則
+lang: zh-tw
+template: 翻譯松
+---
+
+
+
+翻譯松是公開的,任何人都可以透過填寫申請表並加入 Crowdin 上的專案來參與。
+
+在翻譯期間,譯者可以透過在 Crowdin 編輯器中為其語言中未翻譯的字串提供翻譯來收集積分。
+
+每位參賽者的最終分數取決於他們在翻譯期間所翻譯的字數在排行榜上的排名,以及他們所收集到的任何潛在的額外積分。
+
+## 入門 {#getting-started}
+
+翻譯過程在 Crowdin 的 ethereum.org 專案中進行,譯者為未翻譯的字串提供翻譯,這些字串幾乎包含了 ethereum.org 網站的所有內容。
+
+翻譯建議直接在線上編輯器中提供,因此無需下載或上傳任何檔案或交付項目。 每個翻譯的字都會被追蹤和計算。
+
+**1) 加入專案**
+
+- 若要開始貢獻,請加入 [Crowdin 上的 ethereum.org 專案](https://crowdin.com/project/ethereum-org)
+- 您需要登入或建立帳戶—只需一個電子郵件地址和密碼即可
+
+**2) 選擇您的語言**
+
+- 在目標語言清單中找到您的語言,然後按一下其名稱或旗幟來開啟
+- 如果您想翻譯成尚未提供的語言,請在 Crowdin 上聯絡 [Ethereum.org 團隊](https://crowdin.com/profile/ethdotorg),或傳送電子郵件至 translations@ethereum.org,我們將根據請求新增其他目標語言
+
+**3) 開啟未翻譯的檔案**
+
+- 找到第一個未翻譯的檔案開始翻譯。 包含來源檔案的資料夾是根據優先順序排列的,所以您應該從包含未翻譯檔案的第一個資料夾開始翻譯
+- 每個檔案都有一個進度指示器,顯示檔案中可翻譯內容已翻譯和核准的程度… 如果任何檔案的翻譯進度低於 100%,請進行翻譯
+
+**4) 翻譯未翻譯的字串**
+
+- 當您開啟要翻譯的檔案時,請確保您只翻譯未翻譯的字串!
+- 每個字串都有一個狀態指示器,顯示其狀態為「_已翻譯_」、「_未翻譯_」或「_已核准_」。 如果來源字串在您的語言中已經有建議的翻譯,則無需再翻譯
+- 您也可以在編輯器中篩選字串以顯示「_未翻譯優先_」或「_僅顯示未翻譯_」
+
+有關導覽和使用 Crowdin 編輯器的詳細指南,我們建議所有翻譯松參賽者閱讀我們的[如何翻譯](/contributing/translation-program/how-to-translate/)指南。
+
+您也可以查看我們的[翻譯風格指南](/contributing/translation-program/translators-guide/),找到一些訣竅和最佳實踐。
+
+**積分如何運作**
+
+每位翻譯松參賽者都可以透過翻譯 ethereum.org Crowdin 專案和其他符合資格的專案 (下面提供了符合資格的專案的完整清單) 中的內容來賺取積分,計入其最終分數。
+
+計分方式很簡單:**1 個翻譯的字 = 1 分**
+
+為了獲得最終的積分分配,您建議的翻譯需要通過評估過程,專業審稿人將檢查每位參賽者的翻譯,以確保它們符合最低品質門檻,並且在過程中沒有使用機器或人工智慧翻譯。
+
+## 生態系內容 {#ecosystem-content}
+
+由於 ethereum.org 翻譯計畫一直在進行中,網站上某些目標語言的翻譯進度明顯高於其他語言。
+
+為了確保所有翻譯松參賽者都有平等的機會盡可能多地翻譯內容並爭奪最高獎項,作為翻譯松一部分的來源內容不僅限於 ethereum.org 網站內容。
+
+翻譯任何符合資格的專案的參賽者都將獲得等量的積分,任何專案中 1 個翻譯的字 = 1 分。
+
+以下是 2025 年翻譯松中所有符合資格的專案的清單:
+
+- [Ethereum.org](https://crowdin.com/project/ethereum-org)
+
+- [Ethereum.org 開發者教學](https://crowdin.com/project/33388446abbe9d7aa21e42e49bba7f97)
+
+- [EthStaker 存款命令列介面](https://crowdin.com/project/ethstaker-deposit-cli)
+
+- [Eth Docker 文件](https://crowdin.com/project/eth-docker-docs)
+
+- [Remix IDE 文件](https://crowdin.com/project/remix-translation)
+
+- [Remix LearnEth](https://crowdin.com/project/remix-learneth)
+
+- [web3.py](https://crowdin.com/project/web3py)
+
+## 評估過程 {#evaluation-process}
+
+所有翻譯都將接受品質保證和意見回饋,專業語言學家將根據品質和準確性評估提交的內容。
+
+我們還將使用一些自動偵測機器或人工智慧翻譯的工具來執行**反機器翻譯措施**。
+
+雖然翻譯品質在計分中不會扮演關鍵角色,但任何**被發現使用機器或人工智慧翻譯**或提供低品質和不準確翻譯的參賽者將沒有資格獲獎!
+
+評估期將在整個 9 月進行,結果將在 9 月 25 日的 ethereum.org 社群電話會議上宣布。
+
+所有翻譯在新增至網站前也會經過全面審核。
+
+
diff --git a/public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md b/public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md
new file mode 100644
index 00000000000..112c57353a2
--- /dev/null
+++ b/public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md
@@ -0,0 +1,100 @@
+---
+title: 2025 ethereum.org 翻譯松
+lang: zh-tw
+template: 翻譯馬拉松
+---
+
+
+
+
+
+
+
+## 介紹 {#introduction}
+
+我們相信,無論人們使用何種語言,都應該能輕鬆取得以太坊的內容和入門資源。
+為了更接近這個目標,ethereum.org 翻譯計畫是一項旨在將網站翻譯成盡可能多種語言的倡議。
+
+作為翻譯計畫的一部分,我們正在舉辦第三屆翻譯松,這是一項翻譯競賽,旨在鼓勵較少活躍語言的翻譯貢獻、增加網站上可用語言的數量和內容、引導新貢獻者加入,並獎勵我們現有的貢獻者。
+
+如果您是英語以外語言的母語人士,並希望在爭奪獎品的同時幫助以太坊內容更容易被取得,請繼續閱讀以了解更多!
+
+[了解更多關於 ethereum.org 翻譯計畫的資訊](/contributing/translation-program/)
+
+## 時程 {#timeline}
+
+以下是 2025 年翻譯松的重要日期:
+
+
+
+
+
+## 參與 {#participate}
+
+
+
+
+
+ 誰可以參加?
+ 任何年滿 18 歲、以至少一種非英語語言為母語,且精通英語的人。
+
+
+ 我需要是專業譯者嗎?
+ 否。 您只需要具備雙語能力並提交人工翻譯(禁止使用機器翻譯!) 盡您所能即可,不要求專業經驗。
+
+
+
+
+
+ 我需要投入多少時間?
+ 投入多少時間由您決定。 獲得獎品資格的最低門檻是翻譯 1,000 個字,這大約需要 2 個小時才能完成,而爭奪最高獎項則需要投入更多的時間。
+
+
+ 我需要熟悉以太坊嗎?
+ 否。 雖然熟悉以太坊有助於提高您的效率和品質,但翻譯松也是一個學習的體驗,我們邀請每個人在參與的同時,加入並學習更多關於以太坊的知識。
+
+
+
+欲知更多詳情,[請參閱完整的條款與條件](/contributing/translation-program/translatathon/terms-and-conditions)
+
+### 逐步說明 {#step-by-step-instructions}
+
+
+
+## 獎品 {#prizes}
+
+| 名次 | 獎金金額 |
+| ------------- | ----- |
+| 第 1 名 | $4000 |
+| 第 2 名 | $2500 |
+| 第 3 名 | $1500 |
+| 第 4 名 | $1100 |
+| 第 5 名 | $1000 |
+| 第 6 名 | $600 |
+| 第 7 名 | $550 |
+| 第 8 名 | $500 |
+| 第 9 名 | $450 |
+| 第 10 名 | $400 |
+| 第 11 - 20 名 | $240 |
+| 第 21 - 50 名 | $120 |
+| 第 51 - 100 名 | $60 |
+| 第 101 - 150 名 | $40 |
+| 其餘 | $20 |
+
+所有獎品都將以 ETH 支付。
+
+
+
+
diff --git a/public/content/translations/zh-tw/contributing/translation-program/translators-guide/index.md b/public/content/translations/zh-tw/contributing/translation-program/translators-guide/index.md
index 78a31cf57c9..ff69fc13f89 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/translators-guide/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/translators-guide/index.md
@@ -10,15 +10,15 @@ Ethereum.org 翻譯風格指南包含一些給譯者的最重要的準則、說
這份文件是一份通用指南,並不特定於任何一種語言。
-如你有任何問題、建議或意見回饋,請隨時透過 translations@ethereum.org 聯絡我們,在 Crowdin 上向 @ethdotorg 傳送訊息,或者[加入我們的 Discord](https://discord.gg/ethereum-org),你可以在當中透過 #translations 頻道聯絡我們,或者聯絡任何團隊成員。
+如果您有任何問題、建議或意見回饋,歡迎隨時透過 translations@ethereum.org 聯絡我們、在 Crowdin 上傳送訊息給 @ethdotorg,或是[加入我們的 Discord](https://discord.gg/ethereum-org)。您可以在 #translations 頻道中傳送訊息給我們,或聯絡任何團隊成員。
## 使用 Crowdin {#using-crowdin}
-你可以在[翻譯計劃頁面](/contributing/translation-program/#how-to-translate)中找到有關如何在 Crowdin 中加入專案以及如何使用 Crowdin 線上編輯器的基本說明。
+您可以在[翻譯計畫頁面](/contributing/translation-program/#how-to-translate)上找到關於如何在 Crowdin 加入專案以及如何使用 Crowdin 線上編輯器的基本說明。
-若你想要學習更多有關 Crowdin 及如何使用其某些進階功能的資訊,[Crowdin 知識庫](https://support.crowdin.com/online-editor/)內有很多針對所有 Crowdin 功能的深度指南和總觀。
+如果您想深入了解 Crowdin 及其進階功能,[Crowdin 知識庫](https://support.crowdin.com/online-editor/)提供了大量關於 Crowdin 所有功能的深入指南和總覽。
-## 傳達訊息的重點 {#capturing-the-essence}
+## 掌握訊息精髓 {#capturing-the-essence}
翻譯 ethereum.org 的內容時,請避免字面翻譯。
@@ -36,7 +36,7 @@ Ethereum.org 翻譯風格指南包含一些給譯者的最重要的準則、說
多數印歐語係和亞非語係語言都使用特定於性別的第二人稱人稱代詞,以區分男性和女性。 在稱呼使用者或或使用所有格代名詞時,我們可以避免對訪客的性別作出假設,因為正式的稱呼形式通常適用且一致,無論他們如何定位自己的性別。
-## 簡單清楚的詞彙和意思 {#simple-vocabulary}
+## 簡單明瞭的詞彙與意義 {#simple-vocabulary}
我們的目標是讓盡可能多的人能夠理解網站上的內容。
@@ -50,17 +50,17 @@ Ethereum.org 透過拉丁語外的不同書寫系統(或書寫腳本)提供
翻譯內容時,應該確保翻譯內容一致,且不包含任何拉丁字符。
-一個常見的錯誤觀念:Ethereum 應該一直用拉丁文來書寫。 這在大多情況下都是不正確的,請根據你的語言而改變「以太坊」的拼字(如在中文中是「以太坊」,在阿拉伯文中是「إيثيريوم」)。
+一個常見的錯誤觀念:Ethereum 應該一直用拉丁文來書寫。 這在大多數情況下是錯誤的,請使用您語言中原生的「Ethereum」拼法 (例如:中文的「以太坊」、阿拉伯文的「إيثيريوم」等等)。
**以上規則不適用於通常不應翻譯專有名詞的語言。**
-## 翻譯頁面中繼資料 {#translating-metadata}
+## 翻譯頁面元資料 {#translating-metadata}
某些頁面含有頁面上的中繼資料,像「title」、「lang」、「description」、「sidebar」等等。
在將新頁面上傳到 Crowdin 時,我們隱藏了譯者不應該翻譯的內容,這意味著 Crowdin 中對譯者可見的所有中繼資料都應該翻譯。
-翻譯源文本為「en」的任何語句中,請格外留意。 這代表頁面提供的語言,並且應該翻譯為[你的語言的 ISO 語言代碼](https://www.andiamo.co.uk/resources/iso-language-codes/)。 這些字串應該始終翻譯為拉丁文字元,而不是對應目標語言的書寫腳本。
+翻譯源文本為「en」的任何語句中,請格外留意。 這代表頁面可用的語言,應翻譯為[您語言的 ISO 語言代碼](https://www.andiamo.co.uk/resources/iso-language-codes/)。 這些字串應該始終翻譯為拉丁文字元,而不是對應目標語言的書寫腳本。
如你不確定要使用哪個語言代碼,可以在 Crowdin 中查看翻譯記憶,或在 Crowdin 線上編輯器中的頁面 URL 內尋找目標語言的語言代碼。
@@ -72,21 +72,24 @@ Ethereum.org 透過拉丁語外的不同書寫系統(或書寫腳本)提供
- 印地語 - hi
- 西班牙語 - es
-## 外部文章的標題 {#external-articles}
+## 外部文章標題 {#external-articles}
一些語句中包含外部文章的標題。 我們的大多數開發者文件頁面,都包含外部文章的連結以供進一步閱讀。 不論文章是何種語言,都需要翻譯包含文章標題的語句,以確保以母語檢視頁面的訪客取得一致的使用者體驗。
你可以在下方找到譯者會遇到的這類字串,以及如何辨認出這類字串(文章的連結大多位於頁面底部的「延伸閱讀」區段):
- 
+
+
## Crowdin 警告 {#crowdin-warnings}
-Crowdin 有一個內建功能,在譯者即將出錯時發出警告。 在儲存翻譯之前,如果你忘記包含原文中的標籤、翻譯了不應翻譯的元素、添加了多個連續空格、忘記結尾標點符號等,Crowdin 會自動警告你。 若你看見這類警告,請返回並仔細檢查你所提議的翻譯。
+Crowdin 有一個內建功能,在譯者即將出錯時發出警告。 在儲存翻譯之前,如果你忘記包含原文中的標籤、翻譯了不應翻譯的元素、添加了多個連續空格、忘記結尾標點符號等,Crowdin 會自動警告你。
+若你看見這類警告,請返回並仔細檢查你所提議的翻譯。
-**永遠不要忽視這類警告,因為它們通常意味著翻譯存在問題,或者缺少源文本中的關鍵部分。**
+**切勿忽略這些警告,因為它們通常代表出現錯誤,或是譯文缺少了原文的關鍵部分。**
-當你忘記在翻譯中新增標籤時會出現的 Crowdin 警告範例: 
+當您忘記在譯文中新增標籤時,Crowdin 會發出警告,範例如下:
+
## 處理標籤和程式碼片段 {#dealing-with-tags}
@@ -96,15 +99,18 @@ Crowdin 有一個內建功能,在譯者即將出錯時發出警告。 在儲
為了更輕鬆地管理標籤並直接從原文複製它們,我們建議在 Crowdin 編輯器中更改你的設定。
-1. 開啟設定 
+1. 開啟設定
+ 
2. 向下捲動至「HTML tags displaying」區段
-3. 選擇「Hide」 
+3. 選取「隱藏」
+ 
4. 按一下「Save」
-透過選擇此選項,完整的標籤文本將不再顯示,並會替換為數字。 翻譯時,點擊該標籤會自動將準確的標籤複製到翻譯欄位。
+透過選擇此選項,完整的標籤文本將不再顯示,並會替換為數字。
+翻譯時,點擊該標籤會自動將準確的標籤複製到翻譯欄位。
**連結**
@@ -114,15 +120,15 @@ Crowdin 有一個內建功能,在譯者即將出錯時發出警告。 在儲
處理連結的最佳方式是直接從原文中複製連結,可以透過按一下連結或使用「複製原文」按鈕(快捷鍵是「Alt+C」)。
-
+
-連結也會以標籤的形式出現在源文本中(即 `<0>` `0>`). 若你將滑鼠停留在標籤上,編輯器將顯示標籤的全部內容 - 有時候這些標籤將會代表連結。
+連結也會以標籤的形式 (即 `<0>` `0>`) 出現在原文中。 若你將滑鼠停留在標籤上,編輯器將顯示標籤的全部內容 - 有時候這些標籤將會代表連結。
從原文複製連結並且不要改變連結的順序是很重要的。
如果標籤的順序改變,其所代表的連結將中斷。
-
+
**標籤和變數**
@@ -130,37 +136,37 @@ Crowdin 有一個內建功能,在譯者即將出錯時發出警告。 在儲
標籤始終包含一個開始和結束標籤。 在多數情況下,開始標籤和結束標籤中間的文字應該翻譯。
-例子:``Decentralized``
+範例:``去中心化``
-`` - _讓文字變粗體的開始標籤_
+`` - _讓文字變粗體的開頭標籤_
-Decentralized - _可翻譯的文字_
+去中心化 - _可翻譯的文字_
`` - _結束標籤_
-
+
程式碼片段的處理方式與其他標籤略有不同,因為其包含不應翻譯的程式碼。
-例子:``nonce``
+範例:``nonce``
-`` - _開始標籤,其中含有一個程式碼片段_
+`` - _開頭標籤,內含程式碼片段_
nonce - _不可翻譯的文字_
`` - _結束標籤_
-
+
原文還包含縮短的標籤,這類標籤只含有數字,這意味著標籤的功能不明顯。 你可以將滑鼠停留在這些標籤上,查看標籤的確切功能。
-在下面的例子中,可以看見滑鼠停留在標籤上時, `<0>` 會顯示標籤代表 ``,並且含有一個程式碼片段,因此標籤內的內容不應該翻譯。
+在下方的範例中,您可以看到將滑鼠懸停在 `<0>` 標籤上會顯示它代表 `` 並包含程式碼片段,因此不應翻譯這些標籤內的內容。
-
+
-## 簡短與完整形式/縮寫 {#short-vs-full-forms}
+## 縮寫與完整形式/簡稱 {#short-vs-full-forms}
-網站上使用很多縮寫,例如 dapps、NFT、DAO、DeFi 等等。 這些縮寫通常用於英語,並且多數網站的訪客都熟悉這些縮寫。
+網站上使用了許多縮寫,例如:dapps、NFT、DAO、DeFi 等等。 這些縮寫通常用於英語,並且多數網站的訪客都熟悉這些縮寫。
由於這些縮寫通常在其他語言中沒有既定翻譯,處理這些或類似術語最佳方法是提供完整形式的描述性翻譯,並在括號中添加英文縮寫。
@@ -168,9 +174,9 @@ nonce - _不可翻譯的文字_
如何翻譯 dapps 的例子:
-- Decentralized applications (dapps) → _完整翻譯形式 (括號內為英文縮寫)_
+- 去中心化應用程式 (dapps) → _翻譯後的完整形式 (括號中為英文縮寫)_
-## 沒有既定翻譯的術語 {#terms-without-established-translations}
+## 尚無通用譯名的術語 {#terms-without-established-translations}
某些術語在其他語言中可能沒有既定翻譯,並且以原始英語術語的形式廣為人知。 這類術語主要包括較新的概念,如工作量證明、權益證明、信標鏈、質押等。
@@ -178,19 +184,19 @@ nonce - _不可翻譯的文字_
翻譯時,請自由發揮創意,使用描述性翻譯,或直接按字面翻譯。
-**大多數術語應該翻譯而不是將其中一些保留英文的原因是,隨著越來越多的人開始使用以太坊和相關技術,這種新術語將在未來變得更加普及。 如果我們想讓來自世界各地的更多人加入這個領域,我們需要以盡可能多的語言提供易於理解的術語,即使需要我們自行創建這些術語。**
+**之所以大多數術語都應翻譯,而非保留部分英文原文,是因為隨著越來越多人開始使用以太坊和相關技術,這些新術語在未來將會變得更普及。 如果我們想讓世界各地更多人加入這個領域,我們就需要用盡可能多的語言提供易於理解的術語,即使需要我們自行創建也一樣。**
-## 按鈕和行動呼籲 {#buttons-and-ctas}
+## 按鈕和行動呼籲 (CTA) {#buttons-and-ctas}
網站包含很多按鈕,其翻譯方式與其他內容不同。
可以透過檢視上下文螢幕擷取畫面、與大多數字串連結或通過查看編輯器中的上下文(包括詞語「按鈕」)來辨認出按鈕文字。
-按鈕的翻譯應該越短越好,以防止格式不匹配。 此外,按鈕翻譯應採用命令式,如:呈現命令或請求。
+按鈕的翻譯應該越短越好,以防止格式不匹配。 此外,按鈕翻譯應採用命令式,即呈現命令或請求。

-## 翻譯的包容性 {#translating-for-inclusivity}
+## 具包容性的翻譯 {#translating-for-inclusivity}
Ethereum.org 的訪客來自世界各地和不同的背景。 因此,網站上的語言應該是中性的,歡迎所有人且沒有排他性。
@@ -208,7 +214,7 @@ Ethereum.org 的訪客來自世界各地和不同的背景。 因此,網站上
需要特別留意事項的具體例子:
-### 標點符號、格式 {#punctuation-and-formatting}
+### 標點符號與格式 {#punctuation-and-formatting}
**大寫**
@@ -220,8 +226,8 @@ Ethereum.org 的訪客來自世界各地和不同的背景。 因此,網站上
- 正字法規則定義了每種語言中空格的使用。 由於空格的使用很廣泛,所以這些規則最獨特,而空格是最容易錯譯的元素。
- 英語和其他語言在空格用法上的一些常見差異:
- - 測量和貨幣單位(如:USD、EUR、kB、MB)前的空格
- - 溫度符號(如:°C、℉)前的空格
+ - 測量和貨幣單位 (例如:USD、EUR、kB、MB) 前的空格
+ - 溫度符號 (例如:°C、℉) 前的空格
- 一些標點符號前的空格,尤其是省略號 (…)
- 斜線 (/) 前後的空格
@@ -229,7 +235,7 @@ Ethereum.org 的訪客來自世界各地和不同的背景。 因此,網站上
- 每種語言都有一套多樣化和複雜的規則來編寫清單。 這些規則可能與英語大不相同。
- 在一些語言中,每個新行的第一個字詞需要大寫,而在其他語言中,新行應以小寫字母開頭。 許多語言對清單中的大小寫也有不同的規則,具體取決於每行的長度。
-- 這同樣適用於列項目的標點符號。 清單中的結束標點可以是句號(**。**)、逗號(**,**)、或分號(**;**),具體取決於語言。
+- 這同樣適用於列項目的標點符號。 清單中的結尾標點符號可以是句號 (**.**)、逗號 (**,**),或分號 (**;**),視語言而定。
**引號**
@@ -253,10 +259,10 @@ Ethereum.org 的訪客來自世界各地和不同的背景。 因此,網站上
- 不同語言中,數字書寫的主要區別是小數和千位數的分離符號。 對於千位數,分隔符號可以是句號、逗號或空格。 同樣,一些語言使用句號小數點,而其他語言則使用逗號小數點。
- 一些大數的例子:
- - 英語 - **1,000.50**
- - 西班牙語 - **1.000,50**
- - 法語 - **1 000,50**
-- 在翻譯數字時,另外一個重要考慮因素是百分比符號。 它能以不同方法書寫:**100%**、**100 %**或**%100**。
+ - 英文 – **1,000.50**
+ - 西班牙文 – **1.000,50**
+ - 法文 – **1 000,50**
+- 在翻譯數字時,另外一個重要考慮因素是百分比符號。 其寫法有多種方式:**100%**、**100 %** 或 **%100**。
- 最後,依據語言類型,負數可以有不同的形式:-100、100-、(100) 或 [100]。
**日期**
diff --git a/public/content/translations/zh-tw/dao/index.md b/public/content/translations/zh-tw/dao/index.md
index 2299c3d4590..b47ba08318b 100644
--- a/public/content/translations/zh-tw/dao/index.md
+++ b/public/content/translations/zh-tw/dao/index.md
@@ -19,7 +19,7 @@ summaryPoint3: 一個將資產投入特定事業的安全場所。
去中心化自治組織使我們不需信任一個良善的領導者來管理資金或經營,便能與世界各地志趣相投的人們共事。 沒有執行長能夠衝動使用資金,也沒有財務長可以作假帳。 取而代之的是,由基於區塊鏈上程式碼所制定的規則來定義組織如何運作以及如何使用資金。
-組織擁有自己的資金庫,未經團體核准,任何人都無權使用。 決策經由提案和投票來治理,以確保每位組織成員都能發聲,且任何事都在[鏈上](/glossary/#on-chain)進行,公開透明。
+組織擁有自己的資金庫,未經團體核准,任何人都無權使用。 決策由提案和投票治理,以確保組織中的每個人都有發言權,且所有事情都在[鏈上](/glossary/#onchain)透明地進行。
## 為何我們需要去中心化自治組織? {#why-dao}
@@ -37,23 +37,23 @@ summaryPoint3: 一個將資產投入特定事業的安全場所。
| 以去中心化方式自動提供服務(例如慈善基金的分配)。 | 需要人工處理,或集中管控自動處理,易受操縱。 |
| 所有活動皆完全公開透明。 | 活動通常是隱密進行,公開程度有限。 |
-### 去中心化自治組織範例 {#dao-examples}
+### DAO 範例 {#dao-examples}
為了幫助你了解,以下略舉幾個去中心化自治組織的使用範例:
-- **慈善機構** – 你可以接受來自全世界任何人的捐贈,並投票決定要資助的事業。
+- **慈善機構** – 你可以接受來自全世界任何人的捐款,並投票決定資助的事業。
- **共同擁有權** – 你可以購買實體或虛擬資產,且組織成員可以對如何使用資產進行投票。
-- **風險投資和資助** – 你可以成立風險基金,透過該基金匯集投資資本並投票決定要進行的風險投資。 後續收益可以分配給相應的去中心化自治組織成員。
+- **風險投資和補助** – 你可以創建一個風險基金來匯集投資資本,並投票決定要支持的投資項目。 後續收益可以分配給相應的去中心化自治組織成員。
## 去中心化自治組織如何運作? {#how-daos-work}
-去中心化自治組織的基礎為其[智慧型合約](/glossary/#smart-contract),該合約定義組織的規則,並對該團體的資金庫進行規範。 一旦在以太坊上部署合約,除非投票通過,否則不能修改規則。 任何不符合程式碼規則和邏輯的行為都會失效。 由於資金庫也是以智慧型合約定義,因此任何人都無法不經團體核准而挪用資金。 這意味著去中心化自治組織不需要中心化管理機構。 相反地,團體會共同做出決定,而付款會在投票通過之後自動獲得授權。
+DAO 的骨幹是它的[智慧型合約](/glossary/#smart-contract),它定義了組織的規則並持有該組織的資金庫。 一旦在以太坊上部署合約,除非投票通過,否則不能修改規則。 任何不符合程式碼規則和邏輯的行為都會失效。 由於資金庫也是以智慧型合約定義,因此任何人都無法不經團體核准而挪用資金。 這意味著去中心化自治組織不需要中心化管理機構。 相反地,團體會共同做出決定,而付款會在投票通過之後自動獲得授權。
之所以能夠做到這一點,是因為智慧型合約一旦部署於以太坊,就無法被篡改。 一切都是公開的,只要有人修改程式碼(去中心化自治組織的規則)就會被發現。
-## 以太坊與去中心化自治組織 {#ethereum-and-daos}
+## 以太坊與 DAO {#ethereum-and-daos}
以太坊為去中心化自治組織提供了極佳的基礎,原因如下:
@@ -62,105 +62,107 @@ summaryPoint3: 一個將資產投入特定事業的安全場所。
- 智慧型合約可以發送/接收資金。 如果少了這點,你就需要可信的中間人來管理團體的資金。
- 事實證明,比起競爭,以太坊社群更趨向合作,使得最佳做法和支援系統得以快速發展。
-## 去中心化自治組織的治理 {#dao-governance}
+## DAO 管理體系 {#dao-governance}
治理去中心化自治組織時有許多考量,例如投票及提案該如何運作。
-### 授權 {#governance-delegation}
+### 委派 {#governance-delegation}
委託類似去中心化自治組織版本的代議民主。 代幣持有者向自我提名、並承諾管理協定且掌握最新消息的使用者委託選票。
-#### 知名案例 {#governance-example}
+#### 一個著名的例子 {#governance-example}
-[以太坊名稱服務](https://claim.ens.domains/delegate-ranking) – 以太坊名稱服務持有者可將其選票委託給參與活動的社群成員,以代表他們。
+[ENS](https://claim.ens.domains/delegate-ranking) – ENS 持有者可以將他們的投票委派給活躍的社群成員來代表他們。
-### 自動交易治理 {#governance-example}
+### 自動交易管理體系 {#governance-example}
在許多去中心化自治組織中,如達法定人數的成員投票同意,交易將自動執行。
-#### 知名案例 {#governance-example}
+#### 一個著名的例子 {#governance-example}
-[Nouns](https://nouns.wtf) – 在去中心化組織 Nouns 中,如票數達法定數量且大多數票投票同意,只要不被創辦人所否決,交易就會自動執行。
+[Nouns](https://nouns.wtf) – 在 Nouns DAO 中,如果達到法定票數且多數票投下贊成票,只要創辦人沒有否決,交易就會自動執行。
-### 多簽治理 {#governance-example}
+### 多重簽名管理體系 {#governance-example}
-雖然去中心化自治組織可有成千上萬的投票成員,資金可存放在一個由 5-20 名受信任且通常資訊公開(有社群所知的公開身份)的活躍社群成員共管的[錢包](/glossary/#wallet)中。 投票後,[多簽](/glossary/#multisig)簽署人會執行社群的意願。
+雖然 DAO 可能有數千名投票成員,但資金可以存放在一個由 5-20 名受信任且通常身份公開(其公開身份為社群所知)的活躍社群成員所共享的[錢包](/glossary/#wallet)中。 投票後,[多重簽名](/glossary/#multisig)簽署人會執行社群的意願。
-## 去中心化自治組織相關法律 {#dao-laws}
+## DAO 法律 {#dao-laws}
1977 年,懷俄明州創造了有限責任公司制度,以保護企業家並限定其責任。 更近期,懷俄明州首創去中心化自治組織相關法律,給予去中心化自治組織法律地位。 目前,懷俄明州、佛蒙特州以及維京群島皆建立某種形式的去中心化自治組織相關法律。
-### 知名案例 {#law-example}
+### 一個著名的例子 {#law-example}
-[CityDAO](https://citizen.citydao.io/) – CityDAO 透過懷俄明州去中心化自治組織的相關法律購買了黃石國家公園附近 40 英畝的地。
+[CityDAO](https://citizen.citydao.io/) – CityDAO 透過懷俄明州的 DAO 相關法律,購買了黃石國家公園附近 40 英畝的土地。
-## 去中心化自治組織成員 {#dao-membership}
+## DAO 成員資格 {#dao-membership}
去中心化自治組織的成員有多種模式。 成員可以決定投票方式和去中心化自治組織的其他重要事務。
-### 代幣型成員 {#token-based-membership}
+### 代幣制成員資格 {#token-based-membership}
-通常完全[無需許可](/glossary/#permissionless),視所用的代幣而定。 這類治理代幣大部分都能在[去中心化交易所](/glossary/#dex)自由交易,無需許可。 其他少部分則必須透過提供流動性或其他某些「工作量證明」來賺取。 無論是哪一種方式,只要持有代幣就能獲得投票權。
+通常完全[無需許可](/glossary/#permissionless),取決於所使用的代幣。 這些治理代幣大多可以在[去中心化交易所](/glossary/#dex)上無需許可地交易。 其他少部分則必須透過提供流動性或其他某些「工作量證明」來賺取。 無論是哪一種方式,只要持有代幣就能獲得投票權。
-_通常用於治理廣泛的去中心化協定及/或代幣本身。_
+_通常用於治理廣泛的去中心化協定及/或代幣本身。_
-#### 知名案例 {#token-example}
+#### 一個著名的例子 {#token-example}
[MakerDAO](https://makerdao.com) – MakerDAO 的代幣 MKR 在去中心化交易所廣泛提供,且任何人皆可買進投票權來決定 Maker 協定的未來。
-### 股份型成員 {#share-based-membership}
+### 股份制成員資格 {#share-based-membership}
股份型去中心化自治組織擁的許可制程度更高,但仍然相當公開。 任何潛在的成員都可以申請加入去中心化自治組織,通常以代幣或工作的形式提供有價值的貢獻。 股份代表直接投票權及所有權。 成員可以隨時帶著自己所佔的資金庫股份退出。
-_通常用於關係較為緊密、以人為中心的組織,例如慈善機構、勞工團體、投資俱樂部等, 也可以治理協定及代幣。_
+_通常用於關係較為緊密、以人為本的組織,例如慈善機構、工人合作社與投資俱樂部。 也可以治理協定和代幣。_
-#### 知名案例 {#share-example}
+#### 一個著名的例子 {#share-example}
[MolochDAO](http://molochdao.com/) – MolochDAO 致力於資助以太坊專案。 想加入為成員必須提出申請,以便團體評估你是否具備必要的專業知識和資本來對潛在的受資助者作出明智判斷。 你無法直接在公開市場購買加入該去中心化自治組織的資格。
-### 信譽型成員 {#reputation-based-membership}
+### 信譽制成員資格 {#reputation-based-membership}
信譽代表參與證明,並能授予去中心化自治組織的投票權。 不同於代幣型或股份型成員,信譽型去中心化自治組織不會將所有權轉讓給貢獻者。 信譽不能購買、移轉或委託;去中心化自治組織成員必須透過參與來獲得信譽。 鏈上投票無需許可,潛在成員可以自由提出加入去中心化自治組織的申請,並要求獲得信譽和代幣作為其貢獻的獎勵。
-_通常用於協定和[去中心化應用程式](/glossary/#dapp)的去中心化開發及治理,但也非常適合各種組織,如慈善機構、勞工團體、投資俱樂部等。_
+_通常用於協定和[去中心化應用程式](/glossary/#dapp)的去中心化開發及管理體系,但也非常適合各種組織,如慈善機構、工人合作社、投資俱樂部等。_
-#### 知名案例 {#reputation-example}
+#### 一個著名的例子 {#reputation-example}
-[DXdao](https://DXdao.eth.limo) – DXdao 是一個全球主權聯合組織,自 2019 年以來一直致力於建構與治理去中心化協定和應用程式。 它利用信譽型治理和[全息共識](/glossary/#holographic-consensus)來協調和管理資金,這意味著沒有人可以透過金錢來影響其未來或治理決策。
+[DXdao](https://DXdao.eth.limo) – DXdao 是一個全球主權集體,自 2019 年以來一直致力於建構與治理去中心化協定和應用程式。 它利用以信譽為基礎的管理體系和[全息共識](/glossary/#holographic-consensus)來協調和管理資金,這意味著沒有人可以透過金錢來影響其未來或管理體系。
-## 參與/建立去中心化自治組織 {#join-start-a-dao}
+## 加入/創立 DAO {#join-start-a-dao}
-### 加入去中心化自治組織 (DAO) {#join-a-dao}
+### 加入 DAO {#join-a-dao}
-- [以太坊社群去中心化自治組織](/community/get-involved/#decentralized-autonomous-organizations-daos)
-- [DAOHaus 的去中心化自治組織清單](https://app.daohaus.club/explore)
-- [Tally.xyz 的去中心化自治組織清單](https://www.tally.xyz)
+- [以太坊社群 DAO](/community/get-involved/#decentralized-autonomous-organizations-daos)
+- [DAOHaus 的 DAO 列表](https://app.daohaus.club/explore)
+- [Tally.xyz 的 DAO 列表](https://www.tally.xyz/explore)
+- [DeGov.AI 的 DAO 列表](https://apps.degov.ai/)
-### 建立去中心化自治組織 {#start-a-dao}
+### 創立 DAO {#start-a-dao}
-- [使用 DAOHaus 建立去中心化自治組織](https://app.daohaus.club/summon)
-- [使用 Tally 建立一個治理者型去中心化自治組織](https://www.tally.xyz/add-a-dao)
-- [建立由 Aragon 支援的去中心化自治組織](https://aragon.org/product)
-- [建立 colony](https://colony.io/)
-- [使用 DAOstack 全息共識建立去中心化自治組織](https://alchemy.daostack.io/daos/create)
+- [用 DAOHaus 召喚一個 DAO](https://app.daohaus.club/summon)
+- [用 Tally 創立一個 Governor DAO](https://www.tally.xyz/get-started)
+- [創建一個由 Aragon 驅動的 DAO](https://aragon.org/product)
+- [啟動一個 Colony](https://colony.io/)
+- [用 DAOstack 的全息共識創建 DAO](https://alchemy.daostack.io/daos/create)
+- [用 DeGov 啟動器發佈一個 DAO](https://docs.degov.ai/integration/deploy)
## 延伸閱讀 {#further-reading}
-### 去中心化自治組織相關文章 {#dao-articles}
+### DAO 文章 {#dao-articles}
-- [什麼是去中心化自治組織?](https://aragon.org/dao)– [Aragon](https://aragon.org/)
-- [去中心化自治組織之家](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
-- [何謂去中心化自治組織?它有何用途?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for)– [DAOhaus](https://daohaus.club/)
-- [如何創立由去中心化自治組織支援的數位社群](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
-- [什麼是去中心化自治組織?](https://coinmarketcap.com/alexandria/article/what-is-a-dao)– [Coinmarketcap](https://coinmarketcap.com)
-- [什麼是全息共識?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c)- [DAOstack](https://daostack.io/)
-- [Vitalik,《去中心化自治組織並非法人團體:去中心化在自治組織裡的重要之處》](https://vitalik.eth.limo/general/2022/09/20/daos.html)
-- [去中心化自治組織、去中心化自治公司、去中心化應用程式等:不完整術語指引](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [以太坊部落格](https://blog.ethereum.org)
+- [什麼是 DAO?](https://aragon.org/dao) – [Aragon](https://aragon.org/)
+- [DAO 之家](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
+- [什麼是 DAO?它有什麼用?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
+- [如何啟動一個由 DAO 驅動的數位社群](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
+- [什麼是 DAO?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
+- [什麼是全息共識?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
+- [DAOs 並非公司:Vitalik 談去中心化在自治組織中的重要性](https://vitalik.eth.limo/general/2022/09/20/daos.html)
+- [DAO、DAC、DA 等等:不完全術語指南](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [以太坊部落格](https://blog.ethereum.org)
### 影片 {#videos}
-- [什麼是加密貨幣世界的去中心化自治組織?](https://youtu.be/KHm0uUPqmVE)
-- [一個去中心化自治組織是否能建立一座城市?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city)– [TED](https://www.ted.com/)
+- [加密貨幣中的 DAO 是什麼?](https://youtu.be/KHm0uUPqmVE)
+- [DAO 能建造一座城市嗎?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/)
diff --git a/public/content/translations/zh-tw/decentralized-identity/index.md b/public/content/translations/zh-tw/decentralized-identity/index.md
index c7f3555470d..7b8d41a381c 100644
--- a/public/content/translations/zh-tw/decentralized-identity/index.md
+++ b/public/content/translations/zh-tw/decentralized-identity/index.md
@@ -13,13 +13,13 @@ summaryPoint3: 多虧了加密技術,使用者現在擁有了再次發行、
現如今,身分幾乎支撐著我們生活的方方面面。 使用線上服務、開設銀行帳戶、選舉投票、購買房產、就業,所有這些事情都需要證明你的身分。
-然而,傳統的身分管理系統長期以來一直依賴於中心化中間機構來發行、持有和控制你的身分識別和[身分證明](/glossary/#attestation)。 這意味著你無法掌控自己身分的相關資訊,也無法決定誰能夠存取你的個人身分資訊 (PII),以及各方擁有多大的訪問權限。
+然而,傳統的身分管理系統長期以來一直仰賴中心化的中介機構來發行、持有和控制您的身分識別和[證明](/glossary/#attestation)。 這意味著你無法掌控自己身分的相關資訊,也無法決定誰能夠存取你的個人身分資訊 (PII),以及各方擁有多大的訪問權限。
-為了解決這些問題,我們在以太坊等公共區塊鏈上構建了去中心化身分系統。 去中心化身分允許每個人管理他們的身分相關資訊。 借助去中心化身分解決方案,_你_可以建立身分識別、聲明和持有你的身分證明,而無需依賴於中央機構,例如服務提供方或是政府。
+為了解決這些問題,我們在以太坊等公共區塊鏈上構建了去中心化身分系統。 去中心化身分允許每個人管理他們的身分相關資訊。 有了去中心化身分解決方案,_您_就可以建立身分識別、宣告並持有您的證明,而無需仰賴服務供應商或政府等中心化機構。
## 什麼是身分認同? {#what-is-identity}
-身分意味著個人的自我意識,由獨特的特徵定義。 身分是指作為一個_個體_,即一個獨特的人類實體。 身分也可以是指其他非人類的實體,例如組織或機構。
+身分意味著個人的自我意識,由獨特的特徵定義。 身分指的是作為一個_個體_,即一個獨特的人類實體。 身分也可以是指其他非人類的實體,例如組織或機構。
@@ -27,7 +27,7 @@ summaryPoint3: 多虧了加密技術,使用者現在擁有了再次發行、
身分識別是一些資訊,用來指向一個特定身分或多個身分。 常見的身分識別包含:
-- 姓名
+- 名稱
- 社會安全號碼/稅務識別號碼
- 手機號碼
- 出生日期和出生地點
@@ -39,15 +39,15 @@ summaryPoint3: 多虧了加密技術,使用者現在擁有了再次發行、
1. 去中心化身分增加了個人對身分識別資訊的掌握。 可以在無需依賴中心化機構和第三方服務的情況下,驗證去中心化身分識別和身分證明。
-2. 去中心化身分解決方案為驗證和管理使用者身分,提供了一種去信任、無縫且保護隱私的方法。
+2. 去中心化身分解決方案為驗證和管理使用者身分,提供了一種無須信任、順暢且保護隱私的方法。
3. 去中心化身分利用區塊鏈技術,在不同方之間建立信任,並提供加密擔保來驗證身分證明的有效性。
-4. 去中心化身分使得身分資料具有可便攜性。 使用者將身分證明和身分識別儲存在行動裝置錢包中,並可以分享給他們選擇的任一夥伴。 去中心化身分識別和身分證明不會被鎖在發行組織的資料庫中。
+4. 去中心化身分使得身分資料具有可便攜性。 使用者將證明和身分識別儲存在行動錢包中,並可與其選擇的任何一方分享。 去中心化身分識別和身分證明不會被鎖在發行組織的資料庫中。
-5. 去中心化身分與新興的[零知識證明](/glossary/#zk-proof)技術應能完美搭配,這將使個人能夠證明他們擁有某物或做過某些事,而無需透露那是什麼。 這可以成為一種將信任與隱私結合在一起的強而有力方案,適用於投票等應用方面。
+5. 去中心化身分應能與新興的[零知識](/glossary/#zk-proof)技術良好地配合,使個人能夠證明他們擁有某物或做過某事,而無需揭露那是什麼。 這可以成為一種將信任與隱私結合在一起的強而有力方案,適用於投票等應用方面。
-6. 去中心化身分能夠[防範女巫攻擊](/glossary/#anti-sybil)機制,識別一人分飾多角玩弄某系統,或向該系統發送垃圾訊息的情況。
+6. 去中心化身分能啟用[反女巫](/glossary/#anti-sybil)機制,以識別單一個人假冒成多人來濫用或向某個系統傳送垃圾訊息的情況。
## 去中心化身分使用案例 {#decentralized-identity-use-cases}
@@ -55,15 +55,15 @@ summaryPoint3: 多虧了加密技術,使用者現在擁有了再次發行、
### 1. 通用登入 {#universal-dapp-logins}
-去中心化身分可以使用去中心化驗證,有助於替代基於密碼的登入方式。 服務提供商可以向使用者簽發身分證明,這些證明可以儲存在以太坊錢包中。 一個身分證明範例是[非同質化代幣](/glossary/#nft),可以授予持有者訪問線上社群的權利。
+去中心化身分可以使用去中心化驗證,有助於替代基於密碼的登入方式。 服務提供商可以向使用者簽發身分證明,這些證明可以儲存在以太坊錢包中。 證明的一個範例是 [NFT](/glossary/#nft),它能授予持有者存取線上社群的權限。
-[使用以太坊登入](https://siwe.xyz/)功能將允許伺服器能夠確認使用者的以太坊帳戶,並從他們的帳戶地址中獲取所需的身分證明。 這意味著使用者無需記住冗長的密碼,就能夠訪問平台和網站,進而改善使用者的線上體驗。
+接著,[使用以太坊登入](https://siwe.xyz/)功能可讓伺服器確認使用者的以太坊帳戶,並從其帳戶地址擷取所需的證明。 這意味著使用者無需記住冗長的密碼,就能夠訪問平台和網站,進而改善使用者的線上體驗。
-### 2. 「認識客戶」驗證 {#kyc-authentication}
+### 2. KYC 驗證 {#kyc-authentication}
許多線上服務的使用,需要提供個人的身分證明和憑證,例如駕駛執照或國家護照。 但這種方式是有問題的,因為使用者的私人資訊有可能會被洩露,並且服務提供商無法驗證身分證明的真實性。
-去中心化身分使公司能夠跳過傳統的[了解你的客戶 (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) 流程,並透過可驗證憑證來核實使用者身分。 這降低了身份管理的成本,並防止使用偽造文件。
+去中心化身分讓公司可以跳過傳統的[了解你的客戶 (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) 流程,並透過可驗證憑證來驗證使用者身分。 這降低了身份管理的成本,並防止使用偽造文件。
### 3 投票和線上社群 {#voting-and-online-communities}
@@ -73,41 +73,67 @@ summaryPoint3: 多虧了加密技術,使用者現在擁有了再次發行、
### 4 反女巫保護 {#sybil-protection}
-使用[平方投票法](/glossary/#quadratic-voting)的捐款應用程式很容易受到[女巫攻擊](/glossary/#sybil-attack),因為當更多人投票支持時,捐款的價值就會增加,這會激勵使用者將他們的貢獻分配給多個身分。 去中心化身分透過增加每位參與者的負擔來證明他們是真正的人,這有助於防止這種情況發生,而且通常也不必透露具體的私人資訊。
+使用[二次方投票](/glossary/#quadratic-voting)的補助金發放應用程式容易受到[女巫攻擊](/glossary/#sybil-attack)的影響,因為當越多人投票給某個補助金時,其價值就會增加,從而誘使使用者將其貢獻分散到許多身分中。 去中心化身分透過增加每位參與者的負擔來證明他們是真正的人,這有助於防止這種情況發生,而且通常也不必透露具體的私人資訊。
+
+### 5 國家和政府 ID {#national-and-government-id}
+
+政府可以利用去中心化身分的原則,將國民身分證、護照或駕照等基礎身分文件作為以太坊上的可驗證憑證發行,提供強大的密碼學真偽保證,以減少線上身分驗證中的詐欺和偽造。 公民可以將這些證明儲存在個人[錢包](/wallets/)中,並用來證明其身分、年齡或投票權。
+
+此模型允許選擇性揭露,特別是在與[零知識證明 (ZKP)](/zero-knowledge-proofs/) 隱私技術結合時。 例如,公民可以透過密碼學證明自己已滿 18 歲,以存取有年齡限制的服務,而無需透露其確切的出生日期,這比傳統 ID 提供了更高的隱私性。
+
+#### 💡案例研究:不丹在以太坊上的國家數位 ID (NDI) {#case-study-bhutan-ndi}
+
+- 為不丹近 80 萬公民提供可驗證的身分憑證存取權限
+- 於 2025 年 10 月從 Polygon 網路[遷移至以太坊主網](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878)
+- 截至 2025 年 3 月,已發行超過 [234,000 個數位 ID](https://www.blockchain-council.org/blockchain/bhutan-uses-blockchain-in-digital-id-project/)
+
+不丹王國於 2025 年 10 月將其[國家數位身分 (NDI) 系統遷移](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878)至以太坊。 不丹的 NDI 系統建構於去中心化身分和自主身分的原則之上,使用去中心化身分識別和可驗證憑證,將數位簽署的憑證直接發行到公民的個人錢包中。 透過將這些憑證的密碼學證明錨定在以太坊上,該系統確保它們是真實、防竄改的,並且任何一方都可以在不查詢中心機構的情況下進行驗證。
+
+該系統的架構透過使用[零知識證明 (ZKP)](/zero-knowledge-proofs/) 技術來強調隱私。 這種「選擇性揭露」的實作允許公民證明特定事實 (例如「我已滿 18 歲」或「我是公民」) 以存取服務,而無需透露其完整的身分證號碼或確切的出生日期等底層個人資料。 這展示了以太坊在安全、以使用者為中心和保護隱私的國家 ID 系統方面的強大實際應用。
+
+#### 💡案例研究:布宜諾斯艾利斯市在以太坊 [Layer 2](/layer-2/) ZKSync Era 上的 QuarkID {#case-study-buenos-aires-quarkid}
+
+- 在推出時向超過 [360 萬名使用者](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)發行了去中心化身分憑證
+- QuarkID 是一個開源協定,被聯合國永續發展目標認定為[數位公共財](https://www.digitalpublicgoods.net/r/quarkid)
+- 強調「[政府即使用者](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)」模型,市政府不擁有該協定,賦予公民完整的資料所有權和隱私
+
+2024 年,布宜諾斯艾利斯市政府 (GCBA) 將 QuarkID 整合到 miBA 中,QuarkID 是由 GCBA 創新和數位轉型秘書處建構的開源「數位信任框架」,而 miBA 則是該市居民用來存取政府服務和官方文件的官方應用程式。 推出時,miBA 的所有 360 萬以上使用者都獲得了去中心化數位身分,讓他們可以在鏈上管理和分享可驗證的數位文件和證書,包括公民身分憑證、出生、結婚和死亡證明、稅務記錄、疫苗接種記錄等。
+
+QuarkID 系統建構於以太坊 [Layer 2](/layer-2/) 網路 ZKSync Era 之上,使用 ZKP 技術讓公民可以透過行動裝置對等驗證個人憑證,而無需揭露不必要的個人資料。 該計畫強調了「政府即使用者」模型,其中 GCBA 作為開源、可互通的 QuarkID 協定的一名使用者,而非中心化的擁有者。 這種支援 ZKP 的架構提供了一個關鍵的隱私功能:任何第三方,甚至 GCBA,都無法追蹤公民如何、何時或為何使用其憑證。 這個成功的計畫為公民提供了完整的自主身分和對其敏感資料的控制權,所有這些都由以太坊的全球分散式網路提供保護。
## 什麼是身分證明 {#what-are-attestations}
身分證明是由一個實體提出的關於另一個實體的聲明。 如果你居住在美國,你的駕駛執照是由機動車輛管理局(一個實體)發布,它證明你(另一個實體)在法律上允許駕駛汽車。
-身分證明與身分識別不同。 身分證明_包含_用於指向特定身分的身分識別,並聲明與此身分相關的屬性。 因此,你的駕駛執照具有身分識別(姓名、出生日期、地址),但也是關於你合法駕駛權利的證明。
+身分證明與身分識別不同。 證明_包含_用來指稱特定身分的身分識別,並對與此身分相關的屬性進行宣告。 因此,你的駕駛執照具有身分識別(姓名、出生日期、地址),但也是關於你合法駕駛權利的證明。
-### 什麼是去中心化身分識別? {#what-are-decentralized-identifiers}
+### 什麼是去中心化身分識別? 什麼是去中心化身分識別? {#what-are-decentralized-identifiers}
你的法定姓名或電子郵件地址等傳統身分識別依賴於第三方——政府和電子郵件提供商。 去中心化身分識別 (DID) 則不同-它們不由任何中央實體發行、管理或控制。
-去中心化身分識別由個人發行、持有和控制。 [以太坊帳戶](/glossary/#account)是去中心化身分識別的一個範例。 你可以根據需要建立任意數量的帳戶,無需任何人的許可,也無需將它們儲存在中央註冊系統中。
+去中心化身分識別由個人發行、持有和控制。 一個[以太坊帳戶](/glossary/#account)就是去中心化身分識別的一個範例。 你可以根據需要建立任意數量的帳戶,無需任何人的許可,也無需將它們儲存在中央註冊系統中。
-去中心化身分識別儲存在分散式帳本([區塊鏈](/glossary/#blockchain))或[點對點網路](/glossary/#peer-to-peer-network)上。 這使得去中心化身分識別 (DID) 具有[全球唯一性、高可用的可解析性、和加密驗證性](https://w3c-ccg.github.io/did-primer/)。 去中心化身份識別可與不同的實體相關聯,包含個人、組織或政府機構。
+去中心化身分識別儲存在分散式帳本 ([區塊鏈](/glossary/#blockchain)) 或[對等式網路](/glossary/#peer-to-peer-network)上。 這使得 DID 具有[全球唯一性、高可用度的可解析性,並可透過密碼學驗證](https://w3c-ccg.github.io/did-primer/)。 去中心化身份識別可與不同的實體相關聯,包含個人、組織或政府機構。
-## 什麼讓去中心化身分識別成為可能? {#what-makes-decentralized-identifiers-possible}
+## 什麼讓去中心化身分識別成為可能? 是什麼讓去中心化身分識別成為可能? {#what-makes-decentralized-identifiers-possible}
-### 1. 公鑰密碼學 {#public-key-cryptography}
+### 1. 公鑰密碼學 {#public-key-cryptography}
-公鑰密碼學是一種能夠為某實體產生[公鑰](/glossary/#public-key)和[私鑰](/glossary/#private-key)的資安措施。 公鑰[密碼學](/glossary/#cryptography)在區塊鏈網路中用於驗證使用者身分並證明對數位資產的所有權。
+公鑰密碼學是一種資訊安全措施,它為一個實體產生[公鑰](/glossary/#public-key)和[私鑰](/glossary/#private-key)。 公鑰[密碼學](/glossary/#cryptography)用於區塊鏈網路中,以驗證使用者身分並證明數位資產的所有權。
-一些去中心化身分識別,如以太坊帳戶,都有著公鑰與私鑰。 公鑰用於識別帳戶的控制者,而私鑰則可以簽署和解密此帳戶的訊息。 公鑰密碼學使用[加密簽名](https://andersbrownworth.com/blockchain/public-private-keys/)來驗證所有主張,提供了驗證實體並防止冒名頂替及使用假身分所需的證據。
+一些去中心化身分識別,如以太坊帳戶,都有著公鑰與私鑰。 公鑰用於識別帳戶的控制者,而私鑰則可以簽署和解密此帳戶的訊息。 公鑰密碼學提供了驗證實體、防止冒名頂替和使用假身分所需的證明,它使用[密碼學簽章](https://andersbrownworth.com/blockchain/public-private-keys/)來驗證所有宣告。
-### 2. 去中心化資料儲存 {#decentralized-datastores}
+### 2. 去中心化資料儲存庫 {#decentralized-datastores}
區塊鏈充當可驗證的資料註冊系統:一個開放、去信任和去中心化的資訊儲存庫。 公共區塊鏈的存在使得不再需要將身分識別儲存在中心化的註冊系統上。
如果任何人需要確認去中心化身分識別的有效性,他們可以在區塊鏈上查找相關的公鑰。 這與需要由第三方進行驗證的傳統身分識別不同。
-## 去中心化身分識別和身分證明要如何實現去中心化身分? {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity}
+## 去中心化身分識別和身分證明要如何實現去中心化身分? 去中心化身分識別和證明如何實現去中心化身分? {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity}
去中心化身分的概念是,與身分有關的資訊應該由自己控制,且是私密和可移植的,以去中心化身分識別和身分證明為基本構建模塊。
-在去中心化身分的背景下,身分證明(也稱為[可驗證憑證](https://www.w3.org/TR/vc-data-model/))是由發行人所發布、可加密驗證的防篡改聲明。 實體(如,組織)發行的每個身分證明或可驗證憑證都與它們的去中心化身分識別有關。
+在去中心化身分的脈絡中,證明 (也稱為[可驗證憑證](https://www.w3.org/TR/vc-data-model/)) 是由發行者所做出的防竄改、可透過密碼學驗證的宣告。 實體(如,組織)發行的每個身分證明或可驗證憑證都與它們的去中心化身分識別有關。
由於去中心化身分識別儲存在區塊鏈上,任何人都可以在以太坊上交叉驗證發行人的去中心化身分識別,來驗證身分證明的有效性。 實際上,以太坊就像是一個全球目錄,能夠驗證與某些實體相關的去中心化身分識別。
@@ -115,31 +141,31 @@ summaryPoint3: 多虧了加密技術,使用者現在擁有了再次發行、
透過去中心化身分,來使去中心化身分識別能夠保護個人隱私資訊也至關重要。 例如,如果某人提交一個身分證明(駕駛執照),則驗證方不需要檢查身分證明中資訊的有效性。 反之,驗證者只需要獲得身分證明真實性的加密擔保以及發證機構的身分,就足以確定此證明是否有效。
-## 去中心化身分中的身分證明類型 {#types-of-attestations-in-decentralized-identity}
+## 去中心化身分中的證明類型 {#types-of-attestations-in-decentralized-identity}
在基於以太坊的身分生態系統中,如何儲存和檢索身分證明資訊與傳統身分管理不同。 以下是在去中心化身分系統中發行、儲存和驗證身分證明的各種方法的概覽:
-### 鏈外身分證明 {#off-chain-attestations}
+### 鏈下證明 {#offchain-attestations}
將身份證明儲存在鏈上的一個問題是,其中可能包含個人想要保密的資訊。 以太坊區塊鏈具有公開性,因此不適合用於儲存此類身分證明。
-解決方案是發行身分證明,由使用者在數位錢包中鏈外持有,但使用儲存在鏈上的發行人的去中心化身分識別進行簽名。 這些身分證明被編碼為 [JSON Web 代幣](https://en.wikipedia.org/wiki/JSON_Web_Token),其中包含發行人的數位簽名,從而可以輕鬆驗證鏈外聲明。
+解決方案是發行身分證明,由使用者在數位錢包中鏈下持有,但使用儲存在鏈上的發行人的去中心化身分識別進行簽名。 這些證明會被編碼為 [JSON Web Token](https://en.wikipedia.org/wiki/JSON_Web_Token) 並包含發行者的數位簽章,以便輕鬆驗證鏈下宣告。
-以下是解釋鏈外身分證明的假設場景:
+以下是解釋鏈下身分證明的假設場景:
1. 某大學(發行人)產生身分證明(數位學歷證書),用其金鑰簽署,然後將證書頒發給 Bob(身分持有者)。
2. Bob 申請了一份工作並想向雇主證明他的學歷,因此他分享了行動裝置錢包中的身分證明。 公司(驗證者)可以透過檢查發行人的去中心化身分識別(即,其在以太坊上的公鑰),來確認身分證明的有效性。
-### 可持續訪問的鏈外身分證明 {#offchain-attestations-with-persistent-access}
+### 具備永久存取權限的鏈下證明 {#offchain-attestations-with-persistent-access}
-在這種場景下,身分證明被轉換為 JSON 文件並儲存在鏈外(理想情況下儲存在[去中心化雲端儲存](/developers/docs/storage/)平台上,例如 IPFS 或 Swarm)。 然而,JSON 文件的[雜凑值](/glossary/#hash)儲存在鏈上,並透過鏈上註冊系統連結到去中心化身分識別。 所關聯的去中心化身分識別可以是發行人或接收者的身分證明。
+在這種安排下,證明會被轉換成 JSON 檔案並儲存在鏈下 (最好是儲存在 [去中心化雲端儲存](/developers/docs/storage/) 平台,例如 IPFS 或 Swarm)。 然而,JSON 檔案的[哈希](/glossary/#hash)會儲存在鏈上,並透過鏈上登錄檔連結到 DID。 所關聯的去中心化身分識別可以是發行人或接收者的身分證明。
這種方法使身份證明能夠獲得基於區塊鏈的持久性,同時確保聲明資訊的加密性和可驗證性。 它還允許選擇性揭露,因為私鑰的持有者可以解密資訊。
-### 鏈上身分證明 {#onchain-attestations}
+### 鏈上證明 {#onchain-attestations}
-鏈上身分證明保存在以太坊區塊鏈上的[智慧型合約](/glossary/#smart-contract)中。 智慧型合約(充當註冊系統)將身分證明對應到相關的鏈上去中心化身分識別(公開金鑰)。
+鏈上證明保存在以太坊區塊鏈上的[智能合約](/glossary/#smart-contract)中。 智能合約(充當註冊系統)將身分證明對應到相關的鏈上去中心化身分識別(公開金鑰)。
以下範例展示了鏈上身分證明在實踐中的使用方式:
@@ -149,43 +175,44 @@ summaryPoint3: 多虧了加密技術,使用者現在擁有了再次發行、
3. 出售股份的智慧型合約可以檢查註冊合約以獲得經篩選之買家的身分,從而使智慧型合約可以確定哪些人被允許購買股份。
-### 靈魂綁定代幣和身分 {#soulbound}
+### 靈魂綁定代幣與身分 {#soulbound}
-[靈魂綁定代幣](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)([不可轉移的非同質化代幣](/glossary/#nft))可用於收集特定錢包獨有的資訊。 這有效地創建了綁定到特定以太坊地址的唯一鏈上身分,這可能包括代表成就的代幣(例如完成某些特定的線上課程或在遊戲中超過分數門檻)或社區參與代幣。
+[靈魂綁定代幣](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([不可轉移的 NFT](/glossary/#nft)) 可用於收集特定錢包的專屬資訊。 這有效地建立了一個與特定以太坊地址綁定的獨特鏈上身分,其中可包含代表成就 (例如,完成某個特定的線上課程或在遊戲中達到門檻分數) 或社群參與的代幣。
## 使用去中心化身分 {#use-decentralized-identity}
有許多雄心勃勃的專案使用以太坊作為去中心化身分解決方案基礎:
-- **[以太坊名稱服務 (ENS)](https://ens.domains/)** - _一個去中心化的鏈上命名系統,適合機器可讀的識別符號,例如以太坊錢包地址、內容雜湊值和中繼資料。_
-- **[SpruceID](https://www.spruceid.com/)** - _去中心化身分專案,它允許使用者使用以太坊帳戶和以太坊名稱服務個人資料來控制數位身分,而不是依賴第三方服務。_
-- **[以太坊證明服務 (EAS)](https://attest.sh/)** - _一種去中心化分類帳/協議,用於對任何事物進行鏈上或鏈下證明。_
-- **[人性證明](https://www.proofofhumanity.id)** - _人性證明 (PoH) 是建立在以太坊上的社交身分驗證系統。_
-- **[BrightID](https://www.brightid.org/)** - _一個去中心化的開源社交身分網路,旨在通過創建和分析社交圖譜來改革身分驗證。_
-- **[walt.id](https://walt.id)** — _一種使開發者和組織能夠利用自主權身份、非同質化代幣/魂縛代幣的開源去中心化身份及錢包基礎設施。_
-- **[Veramo](https://veramo.io/)** - _ 一種 JavaScript 框架,讓任何人都可以輕鬆地在他們的應用程式中使用可加密驗證的資料。_
+- **[Ethereum Name Service (ENS)](https://ens.domains/)** - _一種去中心化的鏈上命名系統,適用於機器可讀的身分識別,例如以太坊錢包地址、內容哈希和元資料。_
+- **[使用以太坊登入 (SIWE)](https://siwe.xyz/)** - _使用以太坊帳戶進行驗證的開放標準。_
+- **[SpruceID](https://www.spruceid.com/)** - _一個去中心化身分專案,讓使用者能用以太坊帳戶和 ENS 個人資料控制數位身分,而無需仰賴第三方服務。_
+- **[Ethereum Attestation Service (EAS)](https://attest.org/)** - _一個去中心化的帳本/協定,可用於對任何事物進行鏈上或鏈下證明。_
+- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (或 PoH) 是建構在以太坊上的一套社會身分驗證系統。_
+- **[BrightID](https://www.brightid.org/)** - _一個去中心化的開源社交身分網路,旨在透過建立和分析社交圖譜來改革身分驗證。_
+- **[walt.id](https://walt.id)** — _開源的去中心化身分和錢包基礎設施,讓開發者和組織能夠利用自主身分和 NFT/SBT。_
+- **[Veramo](https://veramo.io/)** - _一個 JavaScript 框架,讓任何人都能輕鬆地在其應用程式中使用可透過密碼學驗證的資料。_
## 延伸閱讀 {#further-reading}
### 文章 {#articles}
- [區塊鏈使用案例:數位身分中的區塊鏈](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_
-- [什麼是以太坊 ERC725? 區塊鏈上的自我主權身分管理](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_
+- [什麼是以太坊 ERC725? 區塊鏈上的自主身分管理](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_
- [區塊鏈如何解決數位身分問題](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_
-- [什麼是去中心化身分以及你為什麼需要關心?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_
-- [去中心化身份簡介](https://walt.id/white-paper/digital-identity) — _Dominik Beron_
+- [什麼是去中心化身分?為什麼您該關心?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_
+- [去中心化身分簡介](https://walt.id/white-paper/digital-identity) — _Dominik Beron_
### 影片 {#videos}
-- [去中心化身分(直播獎勵環節)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _一個很好的去中心化身分解說影片,創作者 Andreas Antonopolous_
-- [使用以太坊和去中心化身分登錄 Ceramic、IDX、React 和 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _YouTube 使用教學,作者 Nader Dabit,介紹如何構建身分管理系統,透過以太坊錢包建立、讀取和更新使用者個人資料。_
-- [BrightID - 以太坊上的去中心化身分](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Bankless 播客節目討論 BrightID,一個以太坊上的去中心化身分解決方案_
-- [鏈外互聯網:去中心化身分 & 可驗證憑證](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Evin McMullen 在 EthDenver 2022 的演講
-- [Verifiable Credentials Explained(可驗憑證說明)](https://www.youtube.com/watch?v=ce1IdSr-Kig) - 由 Tamino Baumann 主持演示的 YouTube 講解視頻
+- [去中心化身分 (直播加碼場)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Andreas Antonopolous 製作的絕佳去中心化身分說明影片_
+- [使用以太坊登入和去中心化身分,搭配 Ceramic、IDX、React 和 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Nader Dabit 製作的 YouTube 教學,介紹如何使用使用者的以太坊錢包建置身分管理系統來建立、讀取和更新其個人資料_
+- [BrightID - 以太坊上的去中心化身分](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Bankless 播客節目,討論 BrightID,一個以太坊的去中心化身分解決方案_
+- [鏈下網際網路:去中心化身分與可驗證憑證](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Evin McMullen 在 2022 年 EthDenver 的演講
+- [可驗證憑證說明](https://www.youtube.com/watch?v=ce1IdSr-Kig) - Tamino Baumann 附帶示範的 YouTube 說明影片
### 社群 {#communities}
-- [GitHub 上的 ERC-725 聯盟](https://github.com/erc725alliance) — _在以太坊區塊鏈上管理身分的 ERC725 標準的支持者_
-- [EthID Discord 伺服器](https://discord.com/invite/ZUyG3mSXFD) — _研究使用以太坊登錄的愛好者和開發者社群_
-- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _一個開發人員社區,致力於為應用程式構建可驗證資料的框架_
-- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _由開發者和構建者組成的社區,致力於開發各個行業的去中心化身份應用案例_
+- [GitHub 上的 ERC-725 聯盟](https://github.com/erc725alliance) — _支援在以太坊區塊鏈上管理身分的 ERC725 標準_
+- [EthID Discord 伺服器](https://discord.com/invite/ZUyG3mSXFD) — _致力於「使用以太坊登入」和「以太坊追蹤協定」的愛好者與開發者社群_
+- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _一個致力於為應用程式建置可驗證資料框架的開發者社群_
+- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _一個由開發者和建構者組成的社群,致力於開發各行各業的去中心化身分使用案例_
diff --git a/public/content/translations/zh-tw/defi/index.md b/public/content/translations/zh-tw/defi/index.md
index 18d7a3da28f..3eb91b5692f 100644
--- a/public/content/translations/zh-tw/defi/index.md
+++ b/public/content/translations/zh-tw/defi/index.md
@@ -13,7 +13,7 @@ summaryPoint2: 讓你借款、儲蓄、投資、交易和進行更多應用的
summaryPoint3: 基於所有人都可以編寫的開放原始碼技術。
---
-去中心化金融是專為網際網路時代建構的開放式全球金融系統,可取代不透明、遭到嚴密控制、以幾十年前的基礎設施和流程維繫的系統, 讓你有能力控制及監管自己的資金, 觸及全球市場,並獲得本地貨幣或銀行以外的替代選項。 去中心化金融產品向所有擁有網際網路連線的人開放金融服務,同時主要是由使用者控制和維護。 到目前為止,已有價值數百億的加密貨幣透過去中心化金融應用程式流通,而且這個數字每天都還在成長。
+去中心化金融是專為網際網路時代建構的開放式全球金融系統,可取代不透明、遭到嚴密控制、以幾十年前的基礎設施和流程維繫的系統, 讓你有能力控制及監管自己的資金, 觸及全球市場,並獲得本地貨幣或銀行以外的替代選項。 去中心化金融產品向所有擁有網際網路連線的人開放金融服務,同時主要是由使用者控制和維護。 到目前為止,已有價值數百億美元的加密貨幣流經 DeFi 應用程式,且數量與日俱增。
## 何謂去中心化金融? {#what-is-defi}
@@ -23,7 +23,7 @@ summaryPoint3: 基於所有人都可以編寫的開放原始碼技術。
-## 去中心化金融與傳統金融 {#defi-vs-tradfi}
+## DeFi 與傳統金融 {#defi-vs-tradfi}
了解去中心化金融潛力的一種最佳方法是了解目前存在的問題。
@@ -32,7 +32,7 @@ summaryPoint3: 基於所有人都可以編寫的開放原始碼技術。
- 金融服務可以讓你無法收款。
- 傳統金融服務還有一項隱藏費用,就是你的個人資料。
- 政府及中心化機構可以任意關閉市場。
-- 交易時間通常受到特定時區的營業時間所限。
+- 交易時間通常受特定時區的營業時間限制。
- 資金移轉可能因為內部人工流程而花上好幾天的時間。
- 金融服務存在溢價,因為中間機構需要分一杯羹。
@@ -56,17 +56,17 @@ summaryPoint3: 基於所有人都可以編寫的開放原始碼技術。
從許多方面來說,比特幣是第一款去中心化金融應用程式。 比特幣能讓你真正擁有及掌控價值,並傳送到世界上任何一個角落。 它提供了一種方式,讓眾多互不信任的人同意使用一套帳戶帳本,而無需透過可信賴的中間機構。 比特幣對所有人開放,而且沒有人有權改變其規則。 比特幣的規則,例如其稀有度及開放性,是這項技術與生俱來的特色。 在傳統金融中,政府可以印鈔讓你的存款貶值,企業也可以關閉市場,而比特幣與傳統金融截然不同。
-以太坊便是以此概念為基礎。 和比特幣一樣,以太坊的規則不能任意更改,而且所有人都能使用。 但它進一步使用[智慧型合約](/glossary/#smart-contract)讓這種數位貨幣可程式化,使其功能不侷限於存放及傳送價值。
+以太坊便是以此概念為基礎。 和比特幣一樣,以太坊的規則不能任意更改,而且所有人都能使用。 但它也使用[智能合約](/glossary/#smart-contract)讓這種數位貨幣可程式化,使其功能不侷限於存放及傳送價值。
-## 可程式化的貨幣 {#programmable-money}
+## 可程式化貨幣 {#programmable-money}
-這聽起來很奇怪……「我幹嘛把我的錢程式化?」 不過,這只是以太坊代幣的預設功能之一。 所有人都可以在付款時加入程式邏輯。 因此,你可以結合比特幣的控制權和安全性,以及金融機構提供的各種金融服務, 用加密貨幣來做一些比特幣辦不到的事,例如借貸、安排付款、投資指數型基金等等。
+這聽起來有點奇怪… 「我為什麼會想把我的錢程式化」? 然而,這不僅僅是以太坊上代幣的一項預設功能。 所有人都可以在付款時加入程式邏輯。 因此,你可以結合比特幣的控制權和安全性,以及金融機構提供的各種金融服務, 用加密貨幣來做一些比特幣辦不到的事,例如借貸、安排付款、投資指數型基金等等。
-
+
如果你是剛開始使用以太坊,請嘗試我們推薦的去中心化金融應用程式。
探索去中心化金融應用程式
@@ -78,23 +78,23 @@ summaryPoint3: 基於所有人都可以編寫的開放原始碼技術。
大多數金融服務都有去中心化的替代方案。 但以太坊也為打造嶄新的金融產品創造了許多機會。 這個清單還在不斷成長。
-- [匯款到世界各地](#send-money)
+- [將款項傳送到世界各地](#send-money)
- [讓資金在全球流通](#stream-money)
-- [取得穩定幣](#stablecoins)
+- [存取穩定幣](#stablecoins)
- [抵押借款](#lending)
- [無抵押借款](#flash-loans)
- [開始儲蓄加密貨幣](#saving)
- [交易代幣](#swaps)
-- [擴大投資組合](#investing)
-- [為構想募資](#crowdfunding)
+- [擴大您的投資組合](#investing)
+- [為您的創意募資](#crowdfunding)
- [購買保險](#insurance)
-- [管理投資組合](#aggregators)
+- [管理您的投資組合](#aggregators)
-### 快速匯款到世界各地 {#send-money}
+### 快速將款項傳送到世界各地 {#send-money}
-作為一種區塊鏈,以太坊的核心功能是安全地在全球傳送交易。 和比特幣一樣,以太坊可以讓跨境匯款像傳送電子郵件一樣簡單。 只需從錢包輸入收款人的[以太坊名稱服務名稱](/glossary/#ens)(例如 bob.eth)或其帳戶地址,你的款項就會在幾分鐘內直接到達對方的帳戶(通常情況下)。 要收發款項,你需要一個[錢包](/wallets/)。
+作為一種區塊鏈,以太坊的核心功能是安全地在全球傳送交易。 和比特幣一樣,以太坊可以讓跨境匯款像傳送電子郵件一樣簡單。 只要在您的錢包中輸入收款人的 [ENS 名稱](/glossary/#ens) (例如 bob.eth) 或他們的帳戶地址,您的款項通常會在幾分鐘內直接送達他們。 要傳送或接收款項,您需要一個[錢包](/wallets/)。
查看支付去中心化應用程式
@@ -104,18 +104,18 @@ summaryPoint3: 基於所有人都可以編寫的開放原始碼技術。
你可以運用以太坊流通資金。 以太坊可以讓你在幾秒之內支付某人的薪資,供對方隨時取用; 或快速租用物品,如置物櫃或電動滑板車。
-如果你因為價值波動而不想傳送或串流[以太幣](/glossary/#ether),以太坊上也有替代貨幣:[穩定幣](/glossary/#stablecoin)。
+而且,如果您因為 [ETH](/glossary/#ether) 的價值波動劇烈而不想傳送或串流它,以太坊上還有其他替代貨幣:[穩定幣](/glossary/#stablecoin)。
-### 取得穩定幣 {#stablecoins}
+### 存取穩定貨幣 {#stablecoins}
對許多金融產品和一般支出而言,加密貨幣的價格波動是一大問題。 去中心化金融社群以穩定幣解決了這個問題。 穩定幣的價值與其他資產掛鈎,通常是美元這類熱門貨幣。
Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內, 使穩定幣非常適合用於收入或零售。 在南美洲,因為政府發行的貨幣有極大的不確定性,許多人已經在使用穩定幣保護自己的儲蓄。
- 深入了解穩定幣
+深入了解穩定幣
@@ -133,21 +133,21 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
選擇去中心化貸款有許多優勢……
-#### 在保有隱私的情況下借貸 {#borrowing-privacy}
+#### 具隱私性的借款 {#borrowing-privacy}
今天,資金的借與貸都是圍繞著相關個人進行。 銀行在放款前,需要知道你是不是真的有能力償還貸款。
-去中心化借貸則不需任何一方表明身分即可運作。 然而,借款者必須提供抵押品,如果無法償還,抵押品就會自動歸貸款者所有。 有些貸款人甚至接受以[非同質化代幣](/glossary/#nft)作為抵押品。 非同質化代幣為獨特資產(如繪畫)的契據。 [更多非同質化代幣相關資訊](/nft/)
+去中心化借貸則不需任何一方表明身分即可運作。 然而,借款者必須提供抵押品,如果無法償還,抵押品就會自動歸貸款者所有。 有些出借方甚至接受 [NFTs](/glossary/#nft) 作為抵押品。 非同質化代幣為獨特資產(如繪畫)的契據。 [更多關於 NFT 的資訊](/nft/)
透過這種方式,不必接受徵信調查或提供私人資訊也能借款。
-#### 獲得全球資金 {#access-global-funds}
+#### 取得全球資金 {#access-global-funds}
-選擇去中心化借貸服務時,你可以借入來自全球各地的存款,而不僅止於你選擇的銀行或機構所持有的資金。 這讓貸款更容易取得,也能改善利率。
+選擇去中心化借貸服務時,你可以借入來自全球各地的存款,而不僅止於你選擇的銀行或機構所持有的資金。 這讓貸款更容易取得,也能優化利率。
-#### 納稅效益 {#tax-efficiencies}
+#### 節稅效益 {#tax-efficiencies}
-借款可以讓你獲得需要的資金,而無需出售以太幣(此行為會被課稅)。 但是,你可以使用以太幣作為抵押品以借貸穩定幣。 如此一來,你便可以在保有以太幣的情況下,獲得所需的現金流。 穩定幣是需要現金時的最佳選擇,因為穩定幣的價值不像以太幣一樣易於波動。 [深入了解穩定幣](#stablecoins)
+借款可以讓你獲得需要的資金,而無需出售以太幣(此行為會被課稅)。 但是,你可以使用以太幣作為抵押品以借貸穩定幣。 如此一來,你便可以在保有以太幣的情況下,獲得所需的現金流。 穩定幣是需要現金時的最佳選擇,因為穩定幣的價值不像以太幣一樣易於波動。 [更多關於穩定幣的資訊](#stablecoins)
#### 閃電貸 {#flash-loans}
@@ -173,27 +173,27 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
要在傳統金融體系內完成以上操作,你需要鉅額資金。 這種財產創造策略只有已經擁有財富的人才能操作。 閃電貸的例子告訴我們,未來「有錢」不見得是「賺錢」的先決條件。
- 深入了解閃電貸
+ 更多關於閃電貸的資訊
-### 開始儲蓄加密貨幣 {#saving}
+### 開始用加密貨幣儲蓄 {#saving}
-#### 放貸 {#lending}
+#### 借貸 {#lending}
你可以透過放貸加密貨幣來賺取利息,並即時看到資金成長。 目前的利息比你當地的銀行高出許多(如果你運氣夠好,可以使用銀行服務的話)。 例如:
-- 你借出 100 Dai(一種[穩定幣](/stablecoins/))給某個類似 Aave 的產品。
+- 您將您的 100 Dai,一種[穩定幣](/stablecoins/),出借給像 Aave 這樣的產品。
- 你會收到 100 Aave Dai (aDai),此代幣代表著你借出的 Dai。
-- 你的 aDai 會按利率增加,你可以看到錢包裡的餘額在增長。 視[年利率](/glossary/#apr)而定,你的錢包餘額可能會在幾天,甚至幾小時後變成 100.1234!
+- 你的 aDai 會按利率增加,你可以看到錢包裡的餘額在增長。 取決於[年利率](/glossary/#apr),幾天甚至幾小時後,您的錢包餘額就會變成 100.1234!
- 你可以隨時提取和你的 aDai 餘額等額的一般 Dai。
查看借貸去中心化應用程式
-#### 無損樂透 {#no-loss-lotteries}
+#### 無損失樂透 {#no-loss-lotteries}
無損樂透(如 PoolTogether)是一種有趣而創新的儲蓄方法。
@@ -206,7 +206,7 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
和上述放貸案例一樣,獎金池的資金來自於放貸樂透存款產生的所有利息。
- 嘗試 PoolTogether
+ 試用 PoolTogether
@@ -235,11 +235,11 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
-### 擴大投資組合 {#investing}
+### 擴大您的投資組合 {#investing}
以太坊上有一些資金管理產品可以根據你選擇的策略來擴展你的投資組合。 這是自動化作業,對所有人開放,而且不需要管理人員來分一杯羹。
-[DeFi Pulse 指數基金 (DPI)](https://defipulse.com/blog/defi-pulse-index/) 就是個很好的例子。 此基金會自動再平衡,確保你的投資組合永遠包含市值最高的去中心化金融代幣。 你無需親力親為處理任何細節,而且可以隨時提取資金。
+一個很好的例子是 [DeFi Pulse 指數基金 (DPI)](https://defipulse.com/blog/defi-pulse-index/)。 此基金會自動再平衡,確保你的投資組合永遠包含市值最高的去中心化金融代幣。 你無需親力親為處理任何細節,而且可以隨時提取資金。
查看投資去中心化應用程式
@@ -247,7 +247,7 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
-### 為構想募資 {#crowdfunding}
+### 為您的創意募資 {#crowdfunding}
以太坊是群眾募資的理想平台:
@@ -261,9 +261,9 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
#### 平方募資法 {#quadratic-funding}
-以太坊是一款開放原始碼軟體,迄今有許多工作是由社群資助。 這也催生了一種有趣的新型募資模式:平方募資法。 這種募資法有機會改善我們未來為各種公共產品募資的方式。
+以太坊是一款開放原始碼軟體,迄今有許多工作是由社群資助。 這也催生了一種有趣的新型募資模式:平方募資法。 這種模式可能有助於改善我們在未來為各種公共產品募資的方式。
-平方募資法可以確保獲得最多資金的是需求最高的計畫案, 換言之,就是能夠改善大多數人生活的計畫案。 其運作方式如下:
+二次融資確保獲得最多資金的是具有最獨特需求的專案。 換句話說,就是那些能夠改善大多數人生活的專案。 其運作方式如下:
1. 募得的資金會注入一個配比池。
2. 啟動一輪公開募資。
@@ -282,7 +282,7 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
去中心化保險的目標是使保險更加便宜、理賠更快速,同時更為透明。 隨著自動化程度的提高,保險價格可以更加低廉,理賠也可以更加快速。 用以決定索賠的資料完全透明。
-和其他軟體一樣,以太坊產品也可能受到錯誤或入侵的威脅, 因此目前這個領域有許多保險產品將重點放在保護使用者不會損失資金上。 然而,若干專案開始涵蓋生活中可能遇到的各種大小意外保障。 Etherisc 的農作物保險就是個很好的例子,這項產品的目標在於[保護肯亞小農對抗乾旱及洪災](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)。 去中心化保險可以為買不起傳統保險的農民提供更實惠的保障。
+以太坊產品, 就像任何軟體, 能因程式漏洞或bug而產生種種問題. 因此目前這個領域有許多保險產品將重點放在保護使用者不會損失資金上。 然而,若干專案開始涵蓋生活中可能遇到的各種大小意外保障。 一個很好的例子是 Etherisc 的農作物保險,旨在[保護肯亞的小農免受乾旱和洪水侵害](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)。 去中心化保險可以為買不起傳統保險的農民提供更實惠的保障。
查看保險去中心化應用程式
@@ -302,7 +302,7 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
## 去中心化金融如何運作? {#how-defi-works}
-去中心化金融使用加密貨幣及智慧型合約來提供服務,不需透過中間機構。 在今日的金融體系下,金融機構是交易的保證人。 你的資金是透過金融機構流通,因此賦予了這些機構巨大的權利。 此外,世界上還有數十億人甚至無法使用銀行帳戶。
+去中心化金融使用加密貨幣及智慧型合約來提供服務,不需透過中間機構。 在今日的金融體系下,金融機構是交易的保證人。 你的資金是透過金融機構流通,因此賦予了這些機構巨大的權利。 此外,全球有數十億人甚至無法存取銀行帳戶。
在去中心化金融中,智慧型合約在交易中取代了的金融機構。 智慧型合約是一種以太坊帳戶,可以持有資金並根據特定條件發送/退還資金。 智慧型合約上線後就沒有人可以篡改,它會永遠依照設定的方式運作。
@@ -312,7 +312,7 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
確實,這也意味著目前需要仰賴以太坊社群中能閲讀程式碼的更為精通技術的成員。 以開放原始碼為基礎的社群會約束開發者,但這種需求會隨著時間而趨緩,因為智慧型合約會變得越來越容易閲讀,同時也有其他可以證明程式碼可信度的方法誕生。
-## 以太坊及去中心化金融 {#ethereum-and-defi}
+## 以太坊與 DeFi {#ethereum-and-defi}
以太坊為去中心化金融提供了良好的基礎,原因包括:
@@ -324,36 +324,37 @@ Dai、USDC 等穩定幣的價值和美元的差距通常維持在幾美分之內
你可以把去中心化金融想成好幾層:
1. 區塊鏈:以太坊包含了交易記錄和帳戶狀態。
-2. 資產:[以太幣](/what-is-ether/)及其他代幣(貨幣)。
-3. 協定:提供功能的[智慧型合約](/glossary/#smart-contract),例如實現去中心化資產借貸的服務。
-4. [應用程式](/apps/):我們用以管理及存取協定的產品。
+2. 資產 – [ETH](/what-is-ether/) 和其他代幣 (貨幣)。
+3. 協定 – 提供功能的[智能合約](/glossary/#smart-contract),例如允許去中心化資產借貸的服務。
+4. [應用程式](/apps/) – 我們用來管理和存取協定的產品。
-注意:很多去中心化金融使用 [ERC-20 標準](/glossary/#erc-20)。 去中心化金融 (DeFi) 中的應用程式使用一種包裝的以太幣,稱爲包裝以太幣 (WETH)。 [了解更多關於包裝以太幣的資訊](/wrapped-eth)。
+注意:許多 DeFi 都使用 [ERC-20 標準](/glossary/#erc-20)。 去中心化金融 (DeFi) 中的應用程式使用一種包裝的以太幣,稱爲包裝以太幣 (WETH)。 [深入了解包裝以太幣](/wrapped-eth)。
-## 建構去中心化金融 {#build-defi}
+## 建構 DeFi {#build-defi}
去中心化金融是一場開放原始碼運動。 去中心化金融協議和應用程式都是開放的,你可以自由檢視、分叉並進行各種創新。 因為採用分層堆疊結構(共享相同的基礎區塊鏈及資產),你可以結合和配對不同協定,開啟獨特的機會組合。
- 關於建構去中心化應用程式
+ 更多關於建構去中心化應用程式的資訊
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-### 去中心化金融資料 {#defi-data}
+### DeFi 資料 {#defi-data}
- [DeFi Prime](https://defiprime.com/)
- [DeFi Llama](https://defillama.com/)
-### 去中心化金融文章 {#defi-articles}
+### DeFi 文章 {#defi-articles}
-- [去中心化金融新手指南](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu,2020 年 1 月 6 日_
+- [DeFi 新手指南](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 2020 年 1 月 6 日_
+- [EEA DeFi 風險評估指南](https://entethalliance.org/specs/defi-risks/) – 一份由業界支持的概覽,說明如何在 DeFi 協定中識別和評估關鍵風險。
### 影片 {#videos}
-- [Finematics - 去中心化金融教育](https://finematics.com/) – _關於去中心化金融的影片_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _去中心化金融基本知識:在這個偶爾讓人感到困惑的領域裡邁出第一步,你所需要知道的一切。_
-- [加密貨幣白板講解](https://youtu.be/17QRFlml4pA) _- 何謂去中心化金融?_
+- [Finematics - 去中心化金融教育](https://finematics.com/) – _關於 DeFi 的影片_
+- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _DeFi 基礎知識:開始踏入這個偶爾令人困惑的領域前,您需要知道的一切。_
+- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _什麼是 DeFi?_
### 社群 {#communities}
diff --git a/public/content/translations/zh-tw/desci/index.md b/public/content/translations/zh-tw/desci/index.md
index 4def5a6299c..84f5754990c 100644
--- a/public/content/translations/zh-tw/desci/index.md
+++ b/public/content/translations/zh-tw/desci/index.md
@@ -14,124 +14,126 @@ summaryPoint3: 以開放科學運動為原則。
## 什麼是去中心化科研 (DeSci)? {#what-is-desci}
-去中心化科研 (DeSci) 是一項以建置公共基礎設施,利用 [Web3](/glossary/#web3) 技術堆棧以公平及公正合理的方式融資、建立、審查、認證、儲存和推廣科學知識為目標的運動。
+去中心化科學 (DeSci) 是一項旨在使用 [Web3](/glossary/#web3) 堆疊,為公平公正地募資、創造、審查、授信、儲存和傳播科學知識而建立公共基礎設施的運動。
去中心化科研的目標是創建一個生態系統,鼓勵科學家公開分享研究計畫,在開放任何人輕易獲得甚至參與研究的同時,肯定該科學家的貢獻。 去中心化科研的理念是:所有人都有獲得科學知識的權利,因此科學研究過程應該透明化。 去中心化科研正在開創一種更去中心化且廣泛的科學研究模型,使其更能抵抗中心化管理機構的審查與控制。 去中心化科研的目標是,藉由融資、科研工具與交流渠道的去中心化,為跳脫框架的新點子開創出一個能夠欣欣向榮的環境。
-去中心化科研允許更多樣化的資金來源(從[去中心化自治組織](/glossary/#dao)、[平方募資](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)到衆籌等等),讓資料和方法更易獲取,並透過激勵實現可重複性。
+去中心化科學允許多元化的資金來源(從 [DAO](/glossary/#dao)、[二次方募資](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)到群眾募資等等)、更易於存取的資料與方法,並為可再現性提供獎勵。
### Juan Benet - 去中心化科研運動
-## 去中心化科研如何改善科學研究 {#desci-improves-science}
+## DeSci 如何改善科學 {#desci-improves-science}
這份有待補充的清單列出了科學領域中的關鍵問題,以及去中心化科研所能提供的協助方案
-| **去中心化科研** | **傳統科研** |
-| ------------------------------------------------- | ---------------------------------- |
-| 資金分配**由公眾**使用平方募資或去中心化自治組織等機制決定。 | 小型、封閉、**中心化團體**負責控制資金分配。 |
-| 能夠與**世界各地**的同儕組成自由的團隊並展開合作。 | 你的合作受資助組織和所屬機構**限制**。 |
-| 資金決策在線上進行且**透明度高**。 會探索全新的融資機制。 | 資金決策較為耗時且**透明度有限**。 融資機制有限。 |
-| 透過 [Web3](/glossary/#web3) 科技,使用共享實驗室服務變得更輕鬆和更透明。 | 共享實驗室資源的過程往往**較為遲緩且透明度不足**。 |
-| 可以開發**新的發表模式**,使用 Web3 基礎單元實現信任、透明度和存取普及化。 | 透過既有途徑發表研究通常被認為**低效、受偏見影響且會受到剝削**。 |
-| 可以**藉由同儕審查工作獲得代幣與聲望**。 | **同儕審查工作是無償的**,只有商業出版商能獲益。 |
-| 產生的**知識產權 (IP) 歸你所有**,且能根據透明條款加以分配。 | 產生的**知識產權歸屬於你所屬的機構**。 無法透明地獲得知識產權。 |
-| 透過在鏈上公佈所有步驟,包括來自失敗工作的資料,**實現全面的研究共享**。 | **發表偏見**導致研究者傾向於只分享獲得成功結果的實驗。 |
+| **去中心化科研** | **傳統科研** |
+| ------------------------------------------------------- | --------------------------------------- |
+| 資金分配是**由公眾**使用二次方募資或 DAO 等機制**決定**的。 | 由小型、封閉的**中心化群體**控制資金分配。 |
+| 您可以在充滿活力的團隊中與來自**世界各地**的同儕合作。 | 募資組織和所屬機構會**限制**您的合作。 |
+| 募資決策在線上**透明地**進行。 會探索全新的融資機制。 | 募資決策的周轉時間長,且**透明度有限**。 融資機制有限。 |
+| 使用 [Web3](/glossary/#web3) 技術讓分享實驗室服務變得更容易、更透明。 | 分享實驗室資源通常**既緩慢又不透明**。 |
+| 可以開發使用 Web3 原語來達成信任、透明度和普及存取的**新發布模型**。 | 您透過公認**效率低下、有偏見且具剝削性**的既有途徑發表。 |
+| 您可以透過**同儕審查工作賺取權杖和聲譽**。 | 您的**同儕審查工作是無償的**,這讓營利性出版商受益。 |
+| **您擁有自己產生的智慧財產權 (IP)**,並根據透明的條款進行分發。 | **您所屬的機構擁有**您產生的**智慧財產權**。 無法透明地獲得知識產權。 |
+| 透過將所有步驟都放在鏈上,來**分享所有研究**,包括不成功嘗試的資料。 | **發表偏倚**意味著研究人員更可能分享有成功結果的實驗。 |
-## 以太坊與去中心化科研 {#ethereum-and-desci}
+## 以太坊與 DeSci {#ethereum-and-desci}
去中心化科研系統需要健全的保全,將金錢與交易開銷減到最低,還要有能夠開發各種應用程式的豐富生態系統。 以太坊提供了建置去中心化科研技術所需的一切。
-## 去中心化科研的使用案例 {#use-cases}
+## DeSci 使用案例 {#use-cases}
去中心化科研正在建置科學研究工具組件,引領傳統學術界進入數位世界。 以下是 Web3 可爲科學領域提供的使用案例。
-### 學術發表 {#publishing}
+### 發表 {#publishing}
-現行科學研究發表模式備受質疑,因為這種模式由出版方主導,而出版方又仰賴科學家、審查者與編輯的無償勞動,卻又收取高昂的發表費用。 大眾讀者通常藉由稅收間接支付了該研究的費用,卻往往無法閱讀相同作品,除非再次付款給出版方。 發表單篇科學論文的總費用動輒高達五位數 ($USD),不但辜負了科學知識作為[公共財產](/glossary/#public-goods)的使命,還為一小撮出版商帶來龐大利潤。
+現行科學研究發表模式備受質疑,因為這種模式由出版方主導,而出版方又仰賴科學家、審查者與編輯的無償勞動,卻又收取高昂的發表費用。 大眾讀者通常藉由稅收間接支付了該研究的費用,卻往往無法閱讀相同作品,除非再次付款給出版方。 發表單篇科學論文的總費用通常高達五位數(美元),這破壞了科學知識作為[公共財](/glossary/#public-goods)的整個概念,同時為少數出版商創造了巨額利潤。
-目前的免費公開平台通常是預印伺服器,[例如 ArXiv](https://arxiv.org/)。 然而,這些平台缺乏質量把關,無[防範女巫攻擊的機制](/glossary/#anti-sybil),且通常不會追蹤文章等級指標,換言之,它們通常只供投稿至傳統出版社之前流通作品。 SciHub 也提供免費瀏覽已發表的學術論文,但此途徑並不合法,且須待出版社收取報酬並將論文納入嚴格的版權法之後才得以在網站發布。 這開啟了一道關鍵缺口,也就是內建合法機制與激勵模型的開放式科學論文與資料。 Web3 能提供建立這種系統的工具。
+以預印本伺服器的形式,存在著免費和開放存取的平台,[例如 ArXiv](https://arxiv.org/)。 然而,這些平台缺乏品質控管、[反女巫攻擊機制](/glossary/#anti-sybil),並且通常不追蹤文章層級的指標,這意味著它們通常只用於在提交給傳統出版商之前宣傳作品。 SciHub 也提供免費瀏覽已發表的學術論文,但此途徑並不合法,且須待出版社收取報酬並將論文納入嚴格的版權法之後才得以在網站發布。 這開啟了一道關鍵缺口,也就是內建合法機制與激勵模型的開放式科學論文與資料。 Web3 能提供建立這種系統的工具。
-### 可重複性與可複製性 {#reproducibility-and-replicability}
+### 可重現性與可複製性 {#reproducibility-and-replicability}
可重複性和可複製性是科學研究的品質依據。
- 可重複的研究結果可由相同的團隊使用相同的方式多次達成。
- 可複製的研究結果可由不同的團隊以相同的實驗方案達成。
-全新的 Web3-內建工具可以確保科學發現以可重複性與可複製性為基礎。 我們可將優質的科學融入到學術界的技術體系中。 Web3 擁有為每個分析元件建立[證明](/glossary/#attestation)的能力,包括:原始資料、計算引擎以及應用結果。 共識系統的美妙之處在於,當這些要素由可靠的網路機制維護運作時,所有網路參與者都可以負責再次運算並驗證每一項結果。
+全新的 Web3-內建工具可以確保科學發現以可重複性與可複製性為基礎。 我們可將優質的科學融入到學術界的技術體系中。 Web3 提供了為每個分析組件創建[證明](/glossary/#attestation)的能力:原始數據、計算引擎和應用程式結果。 共識系統的美妙之處在於,當這些要素由可靠的網路機制維護運作時,所有網路參與者都可以負責再次運算並驗證每一項結果。
-### 資金來源 {#funding}
+### 募資 {#funding}
-目前資助科學的標準模式是個人或科學家團體向資助機構提出書面申請。 小部分值得信賴的人為申請表評分,並面試這一小撮申請人,再給予資金。 這個模式不但容易造成瓶頸,導致申請和獲得資助之間有時**需要等待好幾年**,還被認為極易**受到審查小組的偏見、自身利益和政治因素的影響**。
+目前資助科學的標準模式是個人或科學家團體向資助機構提出書面申請。 小部分值得信賴的人為申請表評分,並面試這一小撮申請人,再給予資金。 除了造成瓶頸,導致從申請到獲得補助金之間有時需要**等待數年**之外,這種模式還被認為極易**受到審查小組的偏見、自身利益和政治的影響**。
研究顯示,同一個提案被提交到不同的小組時,結果卻大相徑庭,可見資助審查小組難以選出高品質提案。 隨著資金變得越來越稀缺,這些款項都集中在少數資深研究者與較為保守的研究計劃上。 這導致了一個各方為資金搶破頭的環境,還鞏固了不健康的激勵措施,並抑制創新。
-Web3 廣泛試驗過去中心化自治組織和 Web3 開發的不同激勵模型,因而有可能改善這種糟糕的融資模型。 [追溯性公共財募資](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)、[平方募資](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、[去中心化自治組織治理](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead)及[代幣化激勵結構](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)都是科學募資的革命性 Web3 工具。
+Web3 廣泛試驗過去中心化自治組織和 Web3 開發的不同激勵模型,因而有可能改善這種糟糕的融資模型。 [追溯性公共財募資](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)、[二次方募資](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、[DAO 管理體系](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead)和[代幣化激勵結構](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)是 Web3 中一些可能徹底改變科學募資的工具。
-### 知識產權所有權和開發 {#ip-ownership}
+### 智慧財產權所有權與開發 {#ip-ownership}
-知識產權 (IP) 是傳統科學的一個大問題:從被困在大學或閒置在生物技術公司中,乃至難以估值。 然而,Web3 使用[非同質化代幣 (NFT)](/glossary/#nft) 解決數位資產(例如科學資料或文章)的所有權,這是 Web3 非常擅長的。
+知識產權 (IP) 是傳統科學的一個大問題:從被困在大學或閒置在生物技術公司中,乃至難以估值。 然而,數位資產(如科學數據或文章)的所有權是 Web3 使用[非同質化代幣 (NFT)](/glossary/#nft) 能做得特別好的事情。
就像非同質化代幣可以將未來交易的收入返還給原創作者一樣,你可以建立透明的價值歸屬鏈來獎勵研究人員、管理機構(如去中心化自治組織),甚至是資料被收集的研究對象。
-[知識產權非同質化代幣 (IP-NFT)](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) 還是將正在進行的研究實驗之資料儲存庫去中心化的關鍵,並可以插入非同質化代幣與[去中心化金融](/glossary/#defi)金融化(從資產分割到借貸池與價值評估)。 它還允許如 [VitaDAO](https://www.vitadao.com/) 這樣的去中心化自治組織等鏈上原生實體直接在鏈上進行研究。 不可轉讓的[「靈魂綁定」代幣](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)的出現,將可能在去中心化科研中扮演重要的角色,使個人能證明其與以太坊地址連結的個人經驗和證書。
+[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) 也可以作為正在進行的研究實驗的去中心化資料儲存庫的鑰匙,並接入 NFT 和 [DeFi](/glossary/#defi) 金融化(從碎片化到借貸池和價值評估)。 這也允許像 [VitaDAO](https://www.vitadao.com/) 這樣的原生鏈上實體(例如 DAO)直接在鏈上進行研究。
+不可轉讓的[「靈魂綁定」代幣](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)的出現也可能在 DeSci 中扮演重要角色,它允許個人證明與其以太坊地址相關的經驗和憑證。
-### 資料儲存、存取和架構 {#data-storage}
+### 資料儲存、存取與架構 {#data-storage}
使用 Web3 模式可使人們更容易獲得科學資料,分佈式儲存使研究能在災難性事件中倖存下來。
-起點必須是任何持有適當可驗證憑證的去中心化身分都可以訪問的系統。 這使得敏感資料能夠被可信方安全地複製,從而避免冗餘、抵抗審查,還能重現結果,並實現多方協作與添加新資料至資料集的能力。 [compute-to-data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol) 等機密運算方法提供了替代性存取機制,為最敏感的資料建立了可靠的研究環境。 可靠的研究環境[被 NHS 引用](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb)作為面向未來的資料隱私和協作解決方案,它開創了一個生態系統,在這個生態系統中,研究人員可以使用標準化環境來安全地處理現場資料,以共享程式碼和實踐方式。
+起點必須是任何持有適當可驗證憑證的去中心化身分都可以訪問的系統。 這使得敏感資料能夠被可信方安全地複製,從而避免冗餘、抵抗審查,還能重現結果,並實現多方協作與添加新資料至資料集的能力。 像[計算到數據](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol)這樣的機密運算方法,為原始資料複製提供了替代的存取機制,為最敏感的資料創建了可信研究環境。 可信研究環境已被 [NHS 引用](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb),作為一種面向未來的資料隱私和協作解決方案,它創建了一個生態系統,研究人員可以在其中使用標準化環境安全地在現場處理資料,以分享程式碼和實踐。
靈活的 Web3 資料處理方案支持上述情況,並為真正的開放科學奠定基礎,研究人員可以在沒有存取權限且不必支付費用的情況下為公共利益貢獻一己之力。 星際檔案系統、Arweave 和 Filecoin 等 Web3 公共資料處理方案專為去中心化進行了改良。 例如,dClimate 讓所有人都能獲得氣候和天氣數據,包括來自氣象站和預測氣候模型的數據。
-## 參與 {#get-involved}
+## 參與其中 {#get-involved}
探索各項計畫並加入去中心化科研社群
-- [DeSci.Global:全球活動和聚會行事曆](https://desci.global)
+- [DeSci.Global:全球活動與聚會行事曆](https://desci.global)
- [Blockchain for Science Telegram](https://t.me/BlockchainForScience)
-- [Molecule:資助你的研究計畫或為其募資](https://www.molecule.xyz/)
-- [VitaDAO:藉由受贊助的長壽研究協議獲得資金](https://www.vitadao.com/)
-- [ResearchHub:發布科學成果並與同行交流](https://www.researchhub.com/)
-- [dClimate API:查詢去中心化社群收集的氣候數據](https://www.dclimate.net/)
-- [DeSci Foundation:去中心化科研發表工具生成器](https://descifoundation.org/)
-- [DeSci.World:供使用者查看、參與去中心化科研的單一窗口](https://desci.world)
-- [OceanDAO:管理資料相關科學資金的去中心化自治組織](https://oceanprotocol.com/)
-- [Opscientia:開放的去中心化科研工作流程](https://opsci.io/research/)
-- [Bio.xyz:為你的生物技術去中心化自治組織或去中心化科研專案募資](https://www.bio.xyz/)
-- [Fleming Protocol:推動協作生物醫學發現的開源式資料經濟](http://flemingprotocol.io/)
+- [Molecule:資助您的研究專案或為其募資](https://www.molecule.xyz/)
+- [VitaDAO:透過贊助研究協議為長壽研究獲得資金](https://www.vitadao.com/)
+- [ResearchHub:發表科學成果並與同儕交流](https://www.researchhub.com/)
+- [dClimate API:查詢由去中心化社群收集的氣候數據](https://www.dclimate.net/)
+- [DeSci Foundation:DeSci 發表工具建構者](https://descifoundation.org/)
+- [DeSci.World:供使用者檢視、參與去中心化科學的一站式平台](https://desci.world)
+- [OceanDAO:用於資料相關科學的 DAO 治理募資](https://oceanprotocol.com/)
+- [Opscientia:開放的去中心化科學工作流程](https://opsci.io/research/)
+- [Bio.xyz:為您的生物科技 DAO 或 desci 專案募資](https://www.bio.xyz/)
+- [Fleming Protocol:推動協作生物醫學發現的開源資料經濟](http://flemingprotocol.io/)
- [Active Inference Institute](https://www.activeinference.org/)
- [IdeaMarkets:實現去中心化的科學可信度](https://ideamarket.io/)
-- [去中心化科研實驗室](https://www.desci.com/)
-- [ValleyDAO:開放的全球社群,為合成生物學研究提供資金和轉譯支援](https://www.valleydao.bio)
-- [Cerebrum DAO:尋找和培育解決方案以促進大腦健康並預防神經退化性疾病](https://www.cerebrumdao.com/)
-- [CryoDAO:資助深低溫保存領域的「登月」研究](https://www.cryodao.org)
+- [DeSci Labs](https://www.desci.com/)
+- [ValleyDAO:為合成生物學研究提供募資和轉譯支援的開放全球社群](https://www.valleydao.bio)
+- [Cerebrum DAO:尋找並培育解決方案以促進大腦健康並預防神經退化](https://www.cerebrumdao.com/)
+- [CryoDAO:資助冷凍保存領域的登月研究](https://www.cryodao.org)
+- [Elata:對精神科藥物的未來擁有發言權](https://www.elata.bio/)
-歡迎建議上架新專案 - 請由查看我們的[上架政策](/contributing/adding-desci-projects/)開始!
+我們歡迎您提出要列出的新專案建議——請查看我們的[上架政策](/contributing/adding-desci-projects/)以開始!
## 延伸閱讀 {#further-reading}
-- [由 Jocelynn Pearl 和 Ultrarare 撰寫的去中心化科研維基](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
-- [Jocelynn Pearl 為 a16z future 編寫的去中心化生物技術指南](https://future.a16z.com/a-guide-to-decentralized-biotech/)
-- [去中心化科研的重要性](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
-- [去中心化科研指南](https://future.com/what-is-decentralized-science-aka-desci/)
-- [去中心化科研資源](https://www.vincentweisser.com/desci)
-- [Molecule 的生物製藥 IP-NFT - 技術性說明](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
-- [建立無需信任機制的科學系統 作者:Jon Starr](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
-- [Paul Kohlhaas - DeSci:去中心化科研的未來(播客)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
-- [一種去中心化科研的主動推論本體論:從情境式意義建構到知識共同體](https://zenodo.org/record/6320575)
-- [去中心化科研:研究領域的未來 作者:Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
-- [科研融資(跋:去中心化科研與全新加密原語) 作者:Nadia](https://nadia.xyz/science-funding)
-- [去中心化風潮正在擾亂藥物研發](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
-- [什麼是 DeSci — 去中心化科研?](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
+- [DeSci Wiki by Jocelynn Pearl and Ultrarare](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
+- [去中心化生物科技指南,由 Jocelynn Pearl 為 a16z future 撰寫](https://future.a16z.com/a-guide-to-decentralized-biotech/)
+- [DeSci 的理由](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
+- [DeSci 指南](https://future.com/what-is-decentralized-science-aka-desci/)
+- [去中心化科學資源](https://www.vincentweisser.com/desci)
+- [Molecule 的生物製藥 IP-NFT - 技術說明](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
+- [建構無需信任的科學系統,作者:Jon Starr](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
+- [Paul Kohlhaas - DeSci:去中心化科學的未來 (podcast)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
+- [去中心化科學的主動推理本體論:從情境感知到知識共享](https://zenodo.org/record/6320575)
+- [DeSci:研究的未來,作者:Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
+- [科學募資(結語:DeSci 與新的加密原語),作者:Nadia](https://nadia.xyz/science-funding)
+- [去中心化正在顛覆藥物開發](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
+- [什麼是 DeSci – 去中心化科學?](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
### 影片 {#videos}
-- [去中心化科研是什麼?](https://www.youtube.com/watch?v=-DeMklVWNdA)
-- [Vitalik Buterin 與科學家 Aubrey de Grey 關於長壽研究與加密貨幣之互動的討論](https://www.youtube.com/watch?v=x9TSJK1widA)
-- [科學研究發表已毀。 Web3 能夠有所幫助嗎?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
-- [Juan Benet - 去中心化科研、獨立實驗室與大規模數據科學](https://www.youtube.com/watch?v=zkXM9H90g_E)
-- [Sebastian Brunemeier - 去中心化科研如何能夠轉化生物醫學研究與創業投資](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
-- [Paige Donner - 使用 Web3 和區塊鏈打造開放科學工具](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s)
+- [什麼是去中心化科學?](https://www.youtube.com/watch?v=-DeMklVWNdA)
+- [Vitalik Buterin 與科學家 Aubrey de Grey 關於長壽研究與加密貨幣交集的對話](https://www.youtube.com/watch?v=x9TSJK1widA)
+- 科學出版已然崩壞。 Web3 能修復它嗎?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
+- [Juan Benet - DeSci、獨立實驗室與大規模資料科學](https://www.youtube.com/watch?v=zkXM9H90g_E)
+- [Sebastian Brunemeier - DeSci 如何改變生物醫學研究與風險投資](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
+- [Paige Donner - 使用 Web3 與區塊鏈為開放科學提供工具](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s)
diff --git a/public/content/translations/zh-tw/developers/docs/accounts/index.md b/public/content/translations/zh-tw/developers/docs/accounts/index.md
index 5412c9bfca5..1d08873ff4e 100644
--- a/public/content/translations/zh-tw/developers/docs/accounts/index.md
+++ b/public/content/translations/zh-tw/developers/docs/accounts/index.md
@@ -4,18 +4,18 @@ description: 以太坊帳戶釋義 — 帳戶的資料結構以及和金鑰組
lang: zh-tw
---
-以太坊帳戶是一個擁有以太幣 (ETH) 餘額且可以在以太坊上發送交易的實體。 帳戶可以為使用者控制的帳戶,或為智慧型合約形式的帳戶。
+以太坊帳戶是一個擁有以太幣 (ETH) 餘額且可以在以太坊上發送訊息的實體。 帳戶可以為使用者控制的帳戶,或為智慧型合約形式的帳戶。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了讓你更容易理解本頁,建議你先通讀我們的[以太坊介紹](/developers/docs/intro-to-ethereum/)。
+為了幫助您更佳地理解本頁面,我們建議您先閱讀我們的[以太坊簡介](/developers/docs/intro-to-ethereum/)。
## 帳戶類型 {#types-of-account}
以太坊有兩種帳戶類型:
- 外部帳戶 (EOA) – 由任何持有私密金鑰的人控制
-- 合約帳戶 – 部署在網路上的智慧型合約,由程式碼控制。 瞭解[智慧型合約](/developers/docs/smart-contracts/)。
+- 合約帳戶 – 部署在網路上的智慧型合約,由程式碼控制。 了解[智能合約](/developers/docs/smart-contracts/)
這兩種帳戶類型都能:
@@ -34,7 +34,7 @@ lang: zh-tw
**合約帳戶**
- 建立帳戶會佔用網路儲存因此會產生費用
-- 只能在接受到交易時發送交易
+- 只能在接受到交易時發送訊息
- 從外部帳戶向合約帳戶發送的交易能觸發程式碼,並能執行多種不同操作:例如傳送代幣,甚至建立新合約。
- 合約帳戶沒有私密金鑰。 但它們由智慧型合約程式碼的邏輯控制
@@ -42,14 +42,15 @@ lang: zh-tw
以太坊帳戶有四個欄位:
-- `nonce` – 一個計數器,指示外部帳戶發送的交易數量或合約帳戶建立的合約數量。 對於每個帳戶,一筆特定 Nonce 的交易只能執行一次,這是未了防範重放攻擊,即不斷地廣播並重覆執行已簽署的交易。
-- `balance` – 該地址擁有的 Wei 的數量。 Wei 是以太幣的面額,1 以太幣等於1e+18 個 Wei。
-- `codeHash` -- 此雜湊值指帳戶於以太坊虛擬機 (EVM) 上的_程式碼_。 包含了程式碼片段的合約帳戶可以執行不同操作。 對帳戶進行訊息調用時,執行此以太坊虛擬機程式碼。 不同於帳戶的其他欄位,此欄位無法更改。 所有此等程式碼片段都包含於狀態資料庫中其對應的雜湊值下,以便日後擷取。 此雜湊值稱為 codeHash。 對於外部帳戶,codeHash 欄位是空字串的雜湊值。
-- `storageRoot` – 有時稱為儲存雜湊值。 梅克爾帕特里夏樹之根節點的 256 位雜湊值,它對帳戶的儲存內容進行編碼(256 位整數值之間的映射),在樹形資料結構中編碼成 256 位整數鍵的雜湊值到 RPL 編碼的 256 位整數值之間的映射。 該樹形資料結構對此帳戶的儲存內容的雜湊值進行編碼,且默認為空白。
+- `nonce` – 一個計數器,用來表示由外部擁有的帳戶所發送的交易數量,或由合約帳戶所建立的合約數量。 對於每個帳戶,一筆特定 Nonce 的交易只能執行一次,這是未了防範重放攻擊,即不斷地廣播並重覆執行已簽署的交易。
+- `balance` – 此地址擁有的 wei 數量。 Wei 是以太幣的面額,1 以太幣等於1e+18 個 Wei。
+- `codeHash` – 此哈希指的是以太坊虛擬機 (EVM) 上一個帳戶的_程式碼_。 包含了程式碼片段的合約帳戶可以執行不同操作。 對帳戶進行訊息調用時,執行此以太坊虛擬機程式碼。 不同於帳戶的其他欄位,此欄位無法更改。 所有此等程式碼片段都包含於狀態資料庫中其對應的雜湊值下,以便日後擷取。 此雜湊值稱為 codeHash。 對於外部帳戶,codeHash 欄位是空字串的雜湊值。
+- `storageRoot` – 有時也稱為儲存哈希。 [Merkle Patricia Trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) 樹根節點的 256 位元哈希,它會對帳戶的儲存內容(256 位元整數值之間的一個映射)進行編碼,該映射會在樹中編碼為從 256 位元整數鍵的 Keccak 256 位元哈希到 RLP 編碼的 256 位元整數值的映射。 該樹形資料結構對此帳戶的儲存內容的雜湊值進行編碼,且默認為空白。
- _此圖表源於[以太坊的以太坊虛擬機圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-## 外部帳戶和金鑰組 {#externally-owned-accounts-and-key-pairs}
+## 外部擁有的帳戶和金鑰對 {#externally-owned-accounts-and-key-pairs}
帳戶由一對加密金鑰所組成:公鑰和私鑰。 金鑰組有助於證明交易確實由發送者簽署,並可防止偽造。 私密金鑰用於簽署交易,為你授予與帳戶相關的資金的監管權。 你從未真正持有加密貨幣,你持有的是私密金鑰 – 資金始終處於以太坊帳本中。
@@ -57,7 +58,7 @@ lang: zh-tw
假設 Alice 想從自己的帳戶給 Bob 的帳戶發送以太幣,她須建立交易請求並發送到網路上進行驗證。 以太坊採用公開金鑰加密,這能確保 Alice 可以證明是她自己最初發起了該交易請求。 如果沒有加密機制,惡意對手 Eve 就能輕鬆廣播一個請求,例如「從 Alice 的帳戶給 Eve 的帳戶發送 5 以太幣」。沒有人能夠驗證這個請求不是 Alice 發送的。
-## 建立帳戶 {#account-creation}
+## 帳戶建立 {#account-creation}
當你想建立一個帳戶時,大多數程式庫會為你產生一個隨機私密金鑰。
@@ -67,32 +68,32 @@ lang: zh-tw
`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f`
-公開金鑰是使用[橢圓曲線數位簽名演算法](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)從私密金鑰產生的。 你的帳戶的公開地址由公開金鑰 Keccak-256 雜湊值的後 20 位在開頭加上 `0x` 組成。
+公鑰是使用[橢圓曲線數位簽章演算法](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)從私鑰生成的。 取公鑰的 Keccak-256 哈希的最後 20 個位元組,並在開頭加上 `0x`,即可獲得您帳戶的公開地址。
-這意味著一個外部帳戶 (EOA) 會有一個 42 字元的地址(20 位元組的片段,即 40 個十六進制的字元加上前綴 `0x`)。
+這表示一個外部擁有的帳戶 (EOA) 有一個 42 個字元的地址 (20 位元組的區段,也就是 40 個十六進位字元,再加上 `0x` 前綴)。
-案例:
+範例:
`0x5e97870f263700f46aa00d967821199b9bc5a120`
-下面的範例展示如何使用一種簽名工具 [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) 來產生一個新帳戶。 Clef 是一種與以太坊用戶端 [Geth](https://geth.ethereum.org) 綁定的帳戶管理與簽名工具。 `clef newaccount` 命令建立一個新的金鑰組並將其儲存於加密的密鑰庫。
+以下範例說明如何使用名為 [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) 的簽署工具來產生新帳戶。 Clef 是一個帳戶管理和簽署工具,與以太坊用戶端 [Geth](https://geth.ethereum.org) 捆綁在一起。 `clef newaccount` 命令會建立新的金鑰對,並將其儲存在加密的金鑰庫中。
```
> clef newaccount --keystore
-Please enter a password for the new account to be created:
+請為要建立的新帳戶輸入密碼:
>
------------
-INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please remember your password!
-Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
+INFO [10-28|16:19:09.156] 您的新金鑰已產生 address=0x5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] 請備份您的金鑰檔 path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] 請記住您的密碼!
+產生的帳戶 0x5e97870f263700f46aa00d967821199b9bc5a120
```
[Geth 文件](https://geth.ethereum.org/docs)
-可以透過私密金鑰衍生出公開金鑰,但無法使用公開金鑰衍生出私密金鑰。 顧名思義,**私密**意味著確保私密金鑰安全至關重要。
+您可以從私鑰衍生出新的公鑰,但無法從公鑰衍生出私鑰。 保護您的私鑰安全至關重要,而且,顧名思義,請務必保持其**私密性**。
你需要使用私密金鑰來簽署訊息和交易,並輸出一個簽章。 之後,其他人能夠使用該簽章衍生出你的公開金鑰,證明你是這條訊息的創作者。 在你的應用程式中,你可以使用 JavaScript 程式庫將交易發送至網路。
@@ -110,13 +111,13 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
以太坊還有另一種金鑰,是在以太坊的共識機制從工作量證明過渡到權益證明時引入的。 它們是「BLS」金鑰,且被用於識別驗證者。 這些金鑰能有效地聚合起來,從而降低網路達成共識所需的帶寬。 如果沒有此等金鑰聚合,成為驗證者所需的最低質押量會高出許多。
-[更多驗證者金鑰相關資訊](/developers/docs/consensus-mechanisms/pos/keys/)。
+[更多關於驗證者金鑰的資訊](/developers/docs/consensus-mechanisms/pos/keys/)。
-## 關於錢包的備註 {#a-note-on-wallets}
+## 關於錢包的說明 {#a-note-on-wallets}
帳戶並非錢包。 錢包是一個介面或應用程式,可讓你與你的以太坊帳戶(外部帳戶或合約帳戶)互動。
-## 視覺範例 {#a-visual-demo}
+## 視覺化示範 {#a-visual-demo}
觀看 Austin 為你全面講解雜湊函式和金鑰組。
@@ -128,9 +129,9 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
- [了解以太坊帳戶](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [智慧型合約](/developers/docs/smart-contracts/)
-- [異動](/developers/docs/transactions/)
+- [智能合約](/developers/docs/smart-contracts/)
+- [交易](/developers/docs/transactions/)
diff --git a/public/content/translations/zh-tw/developers/docs/apis/backend/index.md b/public/content/translations/zh-tw/developers/docs/apis/backend/index.md
index b7be4a2a262..c3629eda31a 100644
--- a/public/content/translations/zh-tw/developers/docs/apis/backend/index.md
+++ b/public/content/translations/zh-tw/developers/docs/apis/backend/index.md
@@ -4,29 +4,29 @@ description: 讓你能夠從應用程式與區塊鏈互動的以太坊用戶端
lang: zh-tw
---
-為了讓軟體應用程式能夠和以太坊區塊鏈互動(例如:讀取區塊鏈資料及/或傳送交易到網路),必須先連結以太坊節點。
+為了讓軟體應用程式能與以太坊區塊鏈互動(即讀取區塊鏈資料和/或向網路傳送交易),它必須連接到以太坊節點。
-為了這個目的,每個以太坊用戶端需實作 [JSON-RPC](/developers/docs/apis/json-rpc/) 規範,如此一來,應用程式就可以使用這些一組統一的[方法](/developers/docs/apis/json-rpc/#json-rpc-methods)。
+為此目的,每個以太坊用戶端都實作了 [JSON-RPC](/developers/docs/apis/json-rpc/) 規範,所以有一組統一的[方法](/developers/docs/apis/json-rpc/#json-rpc-methods)可供應用程式依賴。
如果你想用特定程式設計語言連結以太坊節點,生態系統中有很多便利的程式庫幫助你更輕易完成。 借助這些程式庫,開發者可以編寫直覺的單行方法來初始化與以太坊互動的 JSON-RPC 請求(在後台)。
-## 先備知識 {#prerequisites}
+## 先決條件 {#prerequisites}
-瞭解[以太坊堆疊](/developers/docs/ethereum-stack/)和[以太坊用戶端](/developers/docs/nodes-and-clients/)可能會有幫助。
+了解[以太坊技術堆疊](/developers/docs/ethereum-stack/)和[以太坊用戶端](/developers/docs/nodes-and-clients/)可能會有所幫助。
## 為何使用程式庫? {#why-use-a-library}
-這些程式庫顯著降低了直接和以太坊節點互動的複雜度。 這些應用程式介面還提供公用程式功能(例如將 ETH 轉換為 Gwei),使得開發者可以花更少的時間處理複雜的以太坊用戶端,將更多的時間專注於應用程式的特定功能。
+這些程式庫顯著降低了直接和以太坊節點互動的複雜度。 它們也提供公用程式函式(例如將 ETH 轉換為 Gwei),因此作為開發者,您可以花費較少時間處理以太坊用戶端的複雜細節,並將更多時間專注於應用程式的獨特功能。
-## 可用程式庫 {#available-libraries}
+## 可用函式庫 {#available-libraries}
### 基礎設施和節點服務 {#infrastructure-and-node-services}
**Alchemy -** **_以太坊開發平台。_**
- [alchemy.com](https://www.alchemy.com/)
-- [文件](https://docs.alchemy.com/)
-- [Github](https://github.com/alchemyplatform)
+- [文件](https://www.alchemy.com/docs/)
+- [GitHub](https://github.com/alchemyplatform)
- [Discord](https://discord.com/invite/alchemyplatform)
**All That Node -** **_節點即服務。_**
@@ -35,107 +35,112 @@ lang: zh-tw
- [文件](https://docs.allthatnode.com)
- [Discord](https://discord.gg/GmcdVEUbJM)
-**Bware Labs 的 Blast -** **_以太坊主網和測試網的去中心化應用程式介面。_**
+**Blast by Bware Labs -** **_以太坊主網和測試網的去中心化應用程式介面。_**
- [blastapi.io](https://blastapi.io/)
- [文件](https://docs.blastapi.io)
-- [Discord](https://discord.gg/bwarelabs)
+- [Discord](https://discord.gg/SaRqmRUjjQ)
-**BlockPi -** **_提供更高效及快速的遠端程序呼叫服務_**
+**BlockPi -** **_提供更有效率、更快速的 RPC 服務_**
- [blockpi.io](https://blockpi.io/)
-- [文檔](https://docs.blockpi.io/)
-- [Github](https://github.com/BlockPILabs)
+- [文件](https://docs.blockpi.io/)
+- [GitHub](https://github.com/BlockPILabs)
- [Discord](https://discord.com/invite/xTvGVrGVZv)
-**Cloudflare 以太坊閘道。**
+**Cloudflare 以太坊網關.**
- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/)
**Etherscan - 區塊瀏覽器和交易應用程式介面**
+
- [文件](https://docs.etherscan.io/)
-**GetBlock-** **_用於 Web3 開發的區塊鏈即服務_**
+**Blockscout - 開源區塊鏈瀏覽器**
+
+- [文件](https://docs.blockscout.com/)
+
+**GetBlock -** **_用於 Web3 開發的區塊鏈即服務_**
- [GetBlock.io](https://getblock.io/)
-- [文檔](https://getblock.io/docs/)
+- [文件](https://docs.getblock.io/)
**Infura -** **_以太坊應用程式介面即服務。_**
- [infura.io](https://infura.io)
- [文件](https://docs.infura.io/api)
-- [Github](https://github.com/INFURA)
+- [GitHub](https://github.com/INFURA)
-**Node RPC - _有成本效益的以太坊虛擬機 JSON-RPC 提供者_**
+**Node RPC - _高性價比的 EVM JSON-RPC 供應商_**
- [noderpc.xyz](https://www.noderpc.xyz/)
-- [文檔](https://docs.noderpc.xyz/node-rpc)
+- [文件](https://docs.noderpc.xyz/node-rpc)
-**NOWNodes - _全節點和區塊瀏覽器。_**
+**NOWNodes - _全節點與區塊鏈瀏覽器。_**
- [NOWNodes.io](https://nownodes.io/)
-- [文件](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro)
+- [文件](https://nownodes.gitbook.io/documentation)
**QuickNode -** **_區塊鏈基礎設施即服務。_**
- [quicknode.com](https://quicknode.com)
-- [文檔](https://www.quicknode.com/docs/welcome)
+- [文件](https://www.quicknode.com/docs/welcome)
- [Discord](https://discord.gg/quicknode)
-**Rivet -** **_由開源軟體支援的以太坊和以太坊經典應用程式介面即服務_**
+**Rivet -** **_由開源軟體支援的以太坊和以太坊經典應用程式介面即服務。_**
- [rivet.cloud](https://rivet.cloud)
- [文件](https://rivet.cloud/docs/)
-- [Github](https://github.com/openrelayxyz/ethercattle-deployment)
+- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment)
-**Zmok -** **_速度導向的以太坊節點即 JSON-RPC/WebSockets 應用程式介面。_**
+**Zmok -** **_速度導向的以太坊節點,提供 JSON-RPC/WebSockets API。_**
- [zmok.io](https://zmok.io/)
-- [Github](https://github.com/zmok-io)
-- [文檔](https://docs.zmok.io/)
+- [GitHub](https://github.com/zmok-io)
+- [文件](https://docs.zmok.io/)
- [Discord](https://discord.gg/fAHeh3ka6s)
### 開發工具 {#development-tools}
-**ethers-kt -** **_適用基於以太坊虛擬機區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。_**
+**ethers-kt -** **_適用於 EVM 區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。_**
-- [Github](https://github.com/Kr1ptal/ethers-kt)
+- [GitHub](https://github.com/Kr1ptal/ethers-kt)
- [範例](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
- [Discord](https://discord.gg/rx35NzQGSb)
-**Nethereum -** **_區塊鏈的開源 .NET 整合程式庫。_**
+**Nethereum -** **_適用於區塊鏈的開源 .NET 整合函式庫。_**
-- [Github](https://github.com/Nethereum/Nethereum)
-- [文檔](http://docs.nethereum.com/en/latest/)
+- [GitHub](https://github.com/Nethereum/Nethereum)
+- [文件](http://docs.nethereum.com/en/latest/)
- [Discord](https://discord.com/invite/jQPrR58FxX)
-**Python Tooling -** **_透過 Python 進行以太坊互動的各種程式庫。_**
+**Python 工具 -** **_透過 Python 與以太坊互動的各種函式庫。_**
-- [py.ethereum.org](https://python.ethereum.org/)
+- [py.ethereum.org](https://snakecharmers.ethereum.org/)
- [web3.py GitHub](https://github.com/ethereum/web3.py)
- [web3.py 聊天室](https://gitter.im/ethereum/web3.py)
-**Tatum -** **_最好的區塊鏈開發平台。_**
+**Tatum -** **_終極的區塊鏈開發平台。_**
- [Tatum](https://tatum.io/)
- [GitHub](https://github.com/tatumio/)
-- [文檔](https://docs.tatum.io/)
+- [文件](https://docs.tatum.io/)
- [Discord](https://discord.gg/EDmW3kjTC9)
-**web3j -** **_以太坊的 Java/Android/Kotlin/Scala 整合程式庫。 _**
+**web3j -** **_適用於以太坊的 Java/Android/Kotlin/Scala 整合函式庫。_**
-- [Github](https://github.com/web3j/web3j)
+- [GitHub](https://github.com/web3j/web3j)
- [文件](https://docs.web3j.io/)
- [Gitter](https://gitter.im/web3j/web3j)
### 區塊鏈服務 {#blockchain-services}
-**BlockCypher -** **_以太坊 Web 應用程式介面。_**
+**BlockCypher -** **_以太坊網站應用程式介面。_**
- [blockcypher.com](https://www.blockcypher.com/)
- [文件](https://www.blockcypher.com/dev/ethereum/)
-**Chainbase -** **_以太坊的一體化 web3 資料基礎設施。_**
+**Chainbase -** **_適用於以太坊的全方位 Web3 資料基礎設施。_**
- [chainbase.com](https://chainbase.com/)
- [文件](https://docs.chainbase.com/)
@@ -144,20 +149,20 @@ lang: zh-tw
**Chainstack -** **_彈性且專用的以太坊節點即服務。_**
- [chainstack.com](https://chainstack.com)
-- [文件](https://docs.chainbase.com/docs)
-- [以太坊應用程式介面參考資料](https://docs.chainstack.com/reference/ethereum-getting-started)
+- [文件](https://docs.chainstack.com/)
+- [以太坊 API 參考](https://docs.chainstack.com/reference/ethereum-getting-started)
-**Coinbase 雲端節點 -** **_區塊鏈基礎設施應用程式介面。_**
+**Coinbase Cloud Node -** **_區塊鏈基礎設施 API。_**
-- [Coinbase 雲端節點](https://www.coinbase.com/cloud)
-- [文件](https://docs.cloud.coinbase.com/)
+- [Coinbase Cloud Node](https://www.coinbase.com/developer-platform)
+- [文件](https://docs.cdp.coinbase.com/)
-**DataHub by Figment -** **_以太坊主網和測試網的 Web3 應用程式介面服務。_**
+**DataHub by Figment -** **_提供以太坊主網與測試網的 Web3 API 服務。_**
- [DataHub](https://www.figment.io/)
- [文件](https://docs.figment.io/)
-**Moralis -** **_企業級以太坊虛擬機應用程式介面提供者。_**
+**Moralis -** **_企業級 EVM API 供應商。_**
- [moralis.io](https://moralis.io)
- [文件](https://docs.moralis.io/)
@@ -165,43 +170,42 @@ lang: zh-tw
- [Discord](https://moralis.io/joindiscord/)
- [論壇](https://forum.moralis.io/)
-**NFTPort -** **_以太坊資料及鑄造應用程式介面。_**
+**NFTPort -** **_以太坊資料與鑄造 API。_**
- [nftport.xyz](https://www.nftport.xyz/)
- [文件](https://docs.nftport.xyz/)
- [GitHub](https://github.com/nftport/)
- [Discord](https://discord.com/invite/K8nNrEgqhE)
-**Tokenview -** **_通用多重加密區塊鏈應用程式介面平台。_**
+**Tokenview -** **_通用多重加密貨幣區塊鏈 API 平台。_**
- [services.tokenview.io](https://services.tokenview.io/)
- [文件](https://services.tokenview.io/docs?type=api)
- [GitHub](https://github.com/Tokenview)
-**Watchdata -** **_提供簡單可靠的應用程式介面來存取以太坊區塊鏈。_**
+**Watchdata -** **_提供存取以太坊區塊鏈的簡易可靠 API。_**
- [Watchdata](https://watchdata.io/)
- [文件](https://docs.watchdata.io/)
- [Discord](https://discord.com/invite/TZRJbZ6bdn)
-**Covalent -** **_200 多條鏈的已擴充區塊鏈應用程式介面。_**
+**Covalent -** **_為 200 多條鏈提供的強化版區塊鏈 API。_**
- [covalenthq.com](https://www.covalenthq.com/)
- [文件](https://www.covalenthq.com/docs/api/)
- [GitHub](https://github.com/covalenthq)
- [Discord](https://www.covalenthq.com/discord/)
+## 延伸閱讀 {#further-reading}
-## 了解更多 {#further-reading}
-
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
- [節點和用戶端](/developers/docs/nodes-and-clients/)
-- [開發架構](/developers/docs/frameworks/)
+- [開發框架](/developers/docs/frameworks/)
-## 相關教學影片 {#related-tutorials}
+## 相關教學 {#related-tutorials}
-- [設定 Web3js 以在 Javascript 中使用以太坊區塊鏈](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– 在專案中設定 web3.js 的說明。_
-- [從 JavaScript 呼叫智慧型合約](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– 使用 DAI 代幣,瞭解如何使用 JavaScript 呼叫合約函式。_
+- [設定 Web3js 以在 JavaScript 中使用以太坊區塊鏈](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– 在專案中設定 web3.js 的說明。_
+- [從 JavaScript 呼叫智慧型合約](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– 使用 DAI 代幣,了解如何透過 JavaScript 呼叫合約函式。_
diff --git a/public/content/translations/zh-tw/developers/docs/apis/javascript/index.md b/public/content/translations/zh-tw/developers/docs/apis/javascript/index.md
index 7d1d24c2da5..90a11cb5e9c 100644
--- a/public/content/translations/zh-tw/developers/docs/apis/javascript/index.md
+++ b/public/content/translations/zh-tw/developers/docs/apis/javascript/index.md
@@ -1,41 +1,43 @@
---
-title: JavasScript API 圖書館
+title: Javascript 應用程式介面程式庫
description: JavaScript 用戶端程式庫簡介,可讓你從應用程式與區塊鏈進行互動。
lang: zh-tw
---
-為了使網路應用程式能夠與以太坊區塊鏈互動(即讀取區塊鏈資料和/或將交易傳送到網路),它必須連結到以太坊節點。
+若要讓 Web 應用程式與以太坊區塊鏈互動 (即讀取區塊鏈資料和/或將交易傳送到網路),它必須連線到以太坊節點。
-為了這個目的,每個以太坊用戶端需實作 [JSON-RPC](/developers/docs/apis/json-rpc/) 規範,如此一來,應用程式就可以使用一組統一的[方法](/developers/docs/apis/json-rpc/#json-rpc-methods)。
+為此,每個以太坊用戶端都會實作 [JSON-RPC](/developers/docs/apis/json-rpc/) 規範,因此應用程式可以仰賴一組統一的 [方法](/developers/docs/apis/json-rpc/#json-rpc-methods)。
如果你想使用 JavaScript 與以太坊節點連結,可以使用普通 JavaScript,但生態系統中存在幾個便利的程式庫,讓連結變得更加容易。 借助這些程式庫,開發者可以編寫直覺的單行方法來初始化與以太坊互動的 JSON-RPC 請求(在後台)。
-請注意,在[合併](/roadmap/merge/)後,如要運行節點,需要兩個互相連結的以太坊軟體:執行用戶端和共識用戶端。 請確定你的節點包含執行用戶端和共識用戶端。 如果你的節點不在本地機器上(比如你的節點在 AWS 執行個體上),請相應地修改教學中的 IP 位址。 更多資訊請見我們的[運行節點](/developers/docs/nodes-and-clients/run-a-node/)頁面。
+請注意,自 [合併](/roadmap/merge/) 之後,執行節點需要兩個相連的以太坊軟體:一個執行用戶端和一個共識用戶端。 請確定你的節點包含執行用戶端和共識用戶端。 如果您的節點不在本機電腦上 (例如,您的節點在 AWS 執行個體上執行),請相應地更新教學中的 IP 位址。 如需詳細資訊,請參閱我們的[執行節點](/developers/docs/nodes-and-clients/run-a-node/)頁面。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-除了瞭解 JavaScript 之外,瞭解[以太坊堆疊](/developers/docs/ethereum-stack/)和[以太坊用戶端](/developers/docs/nodes-and-clients/)可能也會有所幫助。
+除了瞭解 JavaScript 之外,瞭解[以太坊技術堆疊](/developers/docs/ethereum-stack/)和[以太坊用戶端](/developers/docs/nodes-and-clients/)可能也會有幫助。
-## 為何使用資料圖書庫 {#why-use-a-library}
+## 為何使用程式庫? {#why-use-a-library}
-函式庫簡化與以太坊節點的複雜步驟. 並提供其他效功能(例如: 轉化以太(ETH)到Gwei)使開發者花少時間處理以太坊客戶, 且花更多時間在提升應用程式獨特功能.
+這些程式庫顯著降低了直接和以太坊節點互動的複雜度。 它們也提供公用程式函式(例如將 ETH 轉換為 Gwei),因此作為開發者,您可以花費較少時間處理以太坊用戶端的複雜細節,並將更多時間專注於應用程式的獨特功能。
## 程式庫功能 {#library-features}
-### 連結以太坊節點 {#connect-to-ethereum-nodes}
+### 連線至以太坊節點 {#connect-to-ethereum-nodes}
使用提供者,這些程式庫讓你能夠連結到以太坊並讀取其資料,無論是透過 JSON-RPC、INFURA、Etherscan、Alchemy 還是 MetaMask。
+> **警告:** Web3.js 已於 2025 年 3 月 4 日封存。 [閱讀公告](https://blog.chainsafe.io/web3-js-sunset/) 針對新專案,請考慮使用 [ethers.js](https://ethers.org) 或 [viem](https://viem.sh) 等替代程式庫。
+
**Ethers 範例**
```js
-// BrowserProvider 包裝了一個標準的 Web3 提供者
-// 這就是 MetaMask 注入到每個頁面中的 window.ethereum
+// BrowserProvider 會包裝一個標準的 Web3 提供者,
+// 也就是 MetaMask 注入到每個頁面的 window.ethereum
const provider = new ethers.BrowserProvider(window.ethereum)
// MetaMask 外掛程式也允許簽署交易
-// 以傳送以太幣並支付以改變區塊鏈中的狀態。
-//為此, 我們須帳戶簽署者
+// 以傳送以太幣並支付費用來變更區塊鏈中的狀態。
+// 為此,我們需要帳戶簽署者…
const signer = provider.getSigner()
```
@@ -68,7 +70,7 @@ var web3 = new Web3(
- 燃料預估值
- 智慧型合約活動
- 網路 id
-- 和更多相關內容...
+- 以及更多...
### 錢包功能 {#wallet-functionality}
@@ -77,26 +79,26 @@ var web3 = new Web3(
下面是以太幣範例
```js
-//由助記符(mnemonic) 創建錢包
+// 從助記詞建立錢包執行個體...
mnemonic =
"announce room limb pattern dry unit scale effort smooth jazz weasel alcohol"
walletMnemonic = Wallet.fromPhrase(mnemonic)
-// ...或者從私鑰建立
+// ...或從私密金鑰
walletPrivateKey = new Wallet(walletMnemonic.privateKey)
walletMnemonic.address === walletPrivateKey.address
// true
-// 根據簽署者應用程式介面取得地址(以 Promise 形式)
+// 根據 Signer API,以 Promise 形式呈現的地址
walletMnemonic.getAddress()
// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' }
-// 錢包地址也可以同步獲取
+// 錢包地址也可以同步取得
walletMnemonic.address
// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1'
-// 內部加密組件
+// 內部加密元件
walletMnemonic.privateKey
// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db'
walletMnemonic.publicKey
@@ -110,8 +112,8 @@ walletMnemonic.mnemonic
// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol'
// }
-// 注意:用私鑰建立的錢包
-// 沒有助記詞(因為衍生過程不支援)
+// 注意:使用私密金鑰建立的錢包並
+// 不會有助記詞 (衍生過程不支援)
walletPrivateKey.mnemonic
// null
@@ -128,8 +130,8 @@ tx = {
walletMnemonic.signTransaction(tx)
// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' }
-// 連接方法返回一個新的連接到提供者的
-// 錢包執行個體,
+// connect 方法會回傳一個
+// 連線至提供者的新錢包執行個體
wallet = walletMnemonic.connect(provider)
// 查詢網路
@@ -138,20 +140,20 @@ wallet.getBalance()
wallet.getTransactionCount()
// { Promise: 0 }
-// 發送以太幣
+// 傳送以太幣
wallet.sendTransaction(tx)
```
-[閱讀完整文檔](https://docs.ethers.io/v5/api/signer/#Wallet)
+[閱讀完整文件](https://docs.ethers.io/v5/api/signer/#Wallet)
設定完成後,你將能夠:
- 建立帳戶
- 傳送交易
- 簽署交易
-- 和更多...
+- 以及更多...
-### 與智慧型合約功能互動 {#interact-with-smart-contract-functions}
+### 與智能合約函式互動 {#interact-with-smart-contract-functions}
JavaScript 用戶端程式庫讓你的應用程式能透過讀取編譯合約的應用程式二進位介面 (ABI) 呼叫智慧型合約函式。
@@ -164,7 +166,7 @@ contract Test {
uint a;
address d = 0x12345678901234567890123456789012;
- function Test(uint testInt) { a = testInt;}
+ constructor(uint testInt) { a = testInt;}
event Event(uint indexed b, bytes32 c);
@@ -211,13 +213,13 @@ contract Test {
- 傳送交易至智慧型合約並執行其方法
- 呼叫以預估在以太坊虛擬機中執行時方法將花費的燃料
- 部署合約
-- 和更多...
+- 和更多相關內容...
-### 公用程式功能 {#utility-functions}
+### 工具函式 {#utility-functions}
公用程式功能提供了方便的捷徑,讓以太坊中的構建變得更加容易。
-以太幣值預設以 Wei 為單位。 1 以太幣 = 1,000,000,000,000,000,000 WEI – 這意味著你正在處理大量數字! `web3.utils.toWei` 自動將以太幣轉換至 Wei。
+以太幣值預設以 Wei 為單位。 1 以太幣 = 1,000,000,000,000,000,000 WEI – 這意味著你正在處理大量數字! `web3.utils.toWei` 會為您將 ether 轉換為 Wei。
在以太幣中,如下所示:
@@ -232,59 +234,56 @@ ethers.utils.formatEther(balance)
// '2.337132817842795605'
```
-- [Web3js 公用程式功能](https://docs.web3js.org/api/web3-utils)
-- [Ethers 公用程式功能](https://docs.ethers.io/v5/api/utils/)
+- [Web3js 工具函式](https://docs.web3js.org/api/web3-utils)
+- [Ethers 工具函式](https://docs.ethers.org/v6/api/utils/)
-## 可用資料圖書庫 {#available-libraries}
+## 可用函式庫 {#available-libraries}
-**Web3.js -** **_以太坊 JavaScript 應用程式介面。 _**
+**Web3.js -** **_以太坊 JavaScript API。_**
-- [文件](https://docs.web3js.org/)
-- [Github](https://github.com/ethereum/web3.js/)
+- [文件](https://docs.web3js.org)
+- [GitHub](https://github.com/ethereum/web3.js)
-**Ethers.js -** **_使用 JavaScript 和 TypeScript 的完整以太坊錢包實作和公用程式。 _**
+**Ethers.js -** **_在 JavaScript 和 TypeScript 中的完整以太坊錢包實作與工具。_**
-- [文件](https://docs.ethers.io/)
-- [Github](https://github.com/ethers-io/ethers.js/)
+- [Ethers.js 首頁](https://ethers.org/)
+- [文件](https://docs.ethers.io)
+- [GitHub](https://github.com/ethers-io/ethers.js)
-**The Graph -** **_用於為以太坊和星際檔案係統資料編製索引並使用 GraphQL 進行查詢的協議。_**
+**The Graph -** **_一種用於索引以太坊和 IPFS 資料,並使用 GraphQL 查詢資料的協定。_**
-- [The Graph](https://thegraph.com/)
-- [Graph Explorer](https://thegraph.com/explorer/)
-- [文件](https://thegraph.com/docs/)
-- [Github](https://github.com/graphprotocol/)
+- [The Graph](https://thegraph.com)
+- [Graph 瀏覽器](https://thegraph.com/explorer)
+- [文件](https://thegraph.com/docs)
+- [GitHub](https://github.com/graphprotocol)
- [Discord](https://thegraph.com/discord)
-**light.js ****_針對輕量用戶端最佳化的高階回應式 JS 程式庫。_**
-
-- [Github](https://github.com/openethereum/js-libs/tree/master/packages/light.js)
-
-**Alchemyweb3 -** **_具有自動重試和增強型應用程式介面的 Web3.js 包裝函式。_**
+**Alchemy SDK -** **_Ethers.js 的包裝器,具備增強的 API。_**
-- [文件](https://docs.alchemy.com/reference/api-overview)
-- [Github](https://github.com/alchemyplatform/alchemy-web3)
-
-**Alchemy 非同質化代幣應用程式介面 -** **_用於擷取非同質化代幣資料的應用程式介面,包括所有權、中繼資料屬性以及更多。_**
-
-- [文件](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
-- [GitHub](https://github.com/alchemyplatform/alchemy-web3)
+- [文件](https://www.alchemy.com/docs)
+- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js)
**viem -** **_以太坊的 TypeScript 介面。_**
- [文件](https://viem.sh)
- [GitHub](https://github.com/wagmi-dev/viem)
-## 衍生閱讀 {#further-reading}
+**Drift -** **_具有內建快取、掛鉤和測試模擬的 TypeScript 元程式庫。_**
+
+- [文件](https://ryangoree.github.io/drift/)
+- [GitHub](https://github.com/ryangoree/drift/)
+
+## 延伸閱讀 {#further-reading}
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
- [節點和用戶端](/developers/docs/nodes-and-clients/)
-- [開發架構](/developers/docs/frameworks/)
+- [開發框架](/developers/docs/frameworks/)
-## 相關教學影片 {#related-tutorials}
+## 相關教學 {#related-tutorials}
-- [設定 Web3js 以在 Javascript 中使用以太坊區塊鏈](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– 在專案中設定 web3.js 的說明。_
-- [從 JavaScript 呼叫智慧型合約](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– 使用 DAI 代幣,瞭解如何使用 JavaScript 呼叫合約函式。_
-- [使用 web3 和 Alchemy 傳送交易](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– 從後端傳送交易的逐步演練。_
+- [設定 Web3js 以在 JavaScript 中使用以太坊區塊鏈](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– 在專案中設定 web3.js 的說明。_
+- [從 JavaScript 呼叫智慧型合約](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– 使用 DAI 代幣,了解如何透過 JavaScript 呼叫合約函式。_
+- [使用 web3 和 Alchemy 傳送交易](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– 從後端傳送交易的逐步教學。_
diff --git a/public/content/translations/zh-tw/developers/docs/apis/json-rpc/index.md b/public/content/translations/zh-tw/developers/docs/apis/json-rpc/index.md
index 35ce2484970..7226bb60d1e 100644
--- a/public/content/translations/zh-tw/developers/docs/apis/json-rpc/index.md
+++ b/public/content/translations/zh-tw/developers/docs/apis/json-rpc/index.md
@@ -6,27 +6,27 @@ lang: zh-tw
為了讓軟體應用程式能夠和以太坊區塊鏈互動(例如:讀取區塊鏈資料,發送交易到網路),必須先連結以太坊節點。
-為此,每個[以太坊用戶端](/developers/docs/nodes-and-clients/#execution-clients)都實作 [JSON-RPC 規範](https://github.com/ethereum/execution-apis),因此無論特定節點或用戶端實作如何,應用程式都可以依賴一組統一的方法。
+為此,每個 [以太坊用戶端](/developers/docs/nodes-and-clients/#execution-clients) 都實作了 [JSON-RPC 規範](https://github.com/ethereum/execution-apis),因此無論特定的節點或用戶端實作如何,應用程式都可以依賴一組統一的方法。
-[JSON-RPC](https://www.jsonrpc.org/specification) 是一種無狀態、輕量級的遠端程序呼叫 (RPC) 協定。 該協定定義了幾種資料結構及其處理規則。 它與傳輸無關,因為這些概念可以在同一進程中、透過通訊端、透過超文字傳輸協定或在許多不同的訊息傳遞環境中使用。 它使用 JSON (RFC 4627) 作為資料格式。
+[JSON-RPC](https://www.jsonrpc.org/specification) 是一種無狀態、輕量的遠端程序呼叫 (RPC) 協定。 該協定定義了幾種資料結構及其處理規則。 它與傳輸無關,因為這些概念可以在同一進程中、透過通訊端、透過超文字傳輸協定或在許多不同的訊息傳遞環境中使用。 它使用 JSON (RFC 4627) 作為資料格式。
## 用戶端實作 {#client-implementations}
-每個以太坊用戶端在實作 JSON-RPC 規範時可能會使用不同的程式設計語言。 有關特定程式設計語言的更多詳細資料,請參閱各個[用戶端文件](/developers/docs/nodes-and-clients/#execution-clients)。 我們建議檢查每個用戶端的文件以取得最新的應用程式介面支援資訊。
+每個以太坊用戶端在實作 JSON-RPC 規範時可能會使用不同的程式設計語言。 有關特定程式設計語言的進一步詳細資訊,請參閱各個 [用戶端文件](/developers/docs/nodes-and-clients/#execution-clients)。 我們建議檢查每個用戶端的文件以取得最新的應用程式介面支援資訊。
-## 便利程式庫 {#convenience-libraries}
+## 便利函式庫 {#convenience-libraries}
-雖然可以選擇透過 JSON-RPC 應用程式介面直接與以太坊用戶端互動,但對於去中心化應用程式開發者來說通常有更簡單的選擇。 許多 [JavaScript](/developers/docs/apis/javascript/#available-libraries) 和[後端應用程式介面](/developers/docs/apis/backend/#available-libraries) 程式庫都是為了在 JSON-RPC 應用程式介面之上提供包裝函式。 借助這些程式庫,開發者可以用自己選擇的程式語言編寫直覺的單行方法,以初始化與以太坊互動的 JSON-RPC 請求(在後台)。
+雖然可以選擇透過 JSON-RPC 應用程式介面直接與以太坊用戶端互動,但對於去中心化應用程式開發者來說通常有更簡單的選擇。 有許多 [JavaScript](/developers/docs/apis/javascript/#available-libraries) 和 [後端應用程式介面](/developers/docs/apis/backend/#available-libraries) 函式庫,可在 JSON-RPC API 之上提供包裝函式。 借助這些程式庫,開發者可以用自己選擇的程式語言編寫直覺的單行方法,以初始化與以太坊互動的 JSON-RPC 請求(在後台)。
-## 共識用戶端應用程式介面 {#consensus-clients}
+## 共識用戶端 API {#consensus-clients}
-本頁面主要討論以太坊執行用戶端使用的 JSON-RPC 應用程式介面。 然而,共識用戶端也有一個遠端程序呼叫應用程式介面,讓使用者能夠直接從節點查詢有關節點的資訊、請求信標區塊、信標狀態和其他共識相關資訊。 [信標應用程式介面網頁](https://ethereum.github.io/beacon-APIs/#/)上記錄了此應用程式介面。
+本頁面主要討論以太坊執行用戶端使用的 JSON-RPC 應用程式介面。 然而,共識用戶端也有一個遠端程序呼叫應用程式介面,讓使用者能夠直接從節點查詢有關節點的資訊、請求信標區塊、信標狀態和其他共識相關資訊。 此 API 記錄在 [Beacon API 網頁](https://ethereum.github.io/beacon-APIs/#/) 上。
-內部應用程式介面也用於節點內的用戶端間通訊 - 也就是說,它讓共識用戶端和執行用戶端能夠交換資料。 這被稱為「引擎應用程式介面」,其規範可在 [GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) 上取得。
+內部應用程式介面也用於節點內的用戶端間通訊 - 也就是說,它讓共識用戶端和執行用戶端能夠交換資料。 這稱為「引擎 API」,規格可在 [GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) 上取得。
-## 執行用戶端規範 {#spec}
+## 執行用戶端規格 {#spec}
-[在 GitHub 上閱讀完整的 JSON-RPC 應用程式介面規範](https://github.com/ethereum/execution-apis)。 此應用程式介面記錄在[執行應用程式介面網頁](https://ethereum.github.io/execution-apis/api-documentation/)上,並包含一個檢查器來嘗試所有可用的方法。
+[在 GitHub 上閱讀完整的 JSON-RPC API 規格](https://github.com/ethereum/execution-apis)。 此 API 記錄在 [執行 API 網頁](https://ethereum.github.io/execution-apis/),並包含一個檢查器來試用所有可用的方法。
## 慣例 {#conventions}
@@ -46,11 +46,11 @@ lang: zh-tw
- 錯誤:0x0400(不允許有前導零)
- 錯誤:ff(必須有前綴 0x)
-### 無格式資料 {#unformatted-data-encoding}
+### 未格式化資料 {#unformatted-data-encoding}
編碼無格式資料(位元組陣列、帳戶位址、雜湊值、位元組碼陣列)時:編碼為十六進位,前綴為「0x」,每個位元組兩個十六進位數字。
-這裡有些範例:
+下面有些範例:
- 0x41(大小為 1,「A」)
- 0x004200(大小為 3,「0B0」)
@@ -58,9 +58,9 @@ lang: zh-tw
- 錯誤:0xf0f0f(位數必須為偶數)
- 錯誤:004200(必須以 0x 為前綴)
-### 預設區塊參數 {#default-block}
+### 區塊參數 {#block-parameter}
-下列方法有一個額外的預設區塊參數:
+下列方法有一個額外的區塊參數:
- [eth_getBalance](#eth_getbalance)
- [eth_getCode](#eth_getcode)
@@ -68,34 +68,34 @@ lang: zh-tw
- [eth_getStorageAt](#eth_getstorageat)
- [eth_call](#eth_call)
-當發出對以太坊狀態進行動作的請求時,最後一個預設區塊參數決定了區塊的高度。
+當發出對以太坊狀態進行查詢的請求時,提供的區塊參數決定了區塊的高度。
-defaultBlock 參數可以使用以下選項:
+區塊參數可以使用以下選項:
-- `HEX String` - 表示整數區塊編號
-- `String "earliest"` 表示最早的/創世區塊
-- `String "latest"` - 表示最新提議的區塊
-- `String "safe"` - 表示最新安全的頭部區塊
-- `String "finalized"` - 表示最新最終確定的區塊
-- `String "pending"` - 表示未決的狀態/交易
+- `HEX 字串` - 整數區塊編號
+- `字串 "earliest"` 代表最早/創世區塊
+- `字串 "latest"` - 代表最新提議的區塊
+- `字串 "safe"` - 代表最新安全標頭區塊
+- `字串 "finalized"` - 代表最新最終確認區塊
+- `字串 "pending"` - 代表待處理狀態/交易
## 範例
-在此頁面上,我們提供了有關如何透過命令列工具 [curl](https://curl.se) 使用各 JSON_RPC 應用程式介面端點的範例。 這些單獨的端點範例位於下面的 [Curl 範例](#curl-examples)部分。 在頁面下方,我們還提供了一個使用 Geth 節點、JSON_RPC 應用程式介面和 curl 來編譯和部署智慧型合約的[端到端範例](#usage-example)。
+本頁我們提供使用命令列工具 [curl](https://curl.se) 來操作各個 JSON_RPC API 端點的範例。 這些個別的端點範例可在下方的 [Curl 範例](#curl-examples) 一節中找到。 在頁面下方,我們也提供一個使用 Geth 節點、JSON_RPC API 和 curl 來編譯和部署智能合約的 [端對端範例](#usage-example)。
## Curl 範例 {#curl-examples}
-下面提供了使用 JSON_RPC 應用程式介面向以太坊節點發出 [curl](https://curl.se) 請求的範例。 每個範例包含對特定端點的描述、其參數、傳回類型,以及應該如何使用的可行範例。
+下方提供了透過向以太坊節點發出 [curl](https://curl.se) 請求來使用 JSON_RPC API 的範例。 每個範例包含對特定端點的描述、其參數、傳回類型,以及應該如何使用的可行範例。
-curl 請求可能會傳回與內容類型相關的錯誤訊息。 這是因為 `--data` 選項將內容類型設定為 `application/x-www-form-urlencoded`。 如果你的節點確實抱怨這一點,請手動在呼叫程式開始處放置 `-H "Content-Type: application/json"` 來設定標頭。 這些範例也不包括 URL/IP 和通訊埠組合,該組合必須是給 curl 的最後一個引數(例如 `127.0.0.1:8545`)。 完整的 curl 請求包含採用以下形式的附加資料:
+curl 請求可能會傳回與內容類型相關的錯誤訊息。 這是因為 `--data` 選項會將內容類型設定為 `application/x-www-form-urlencoded`。 如果你的節點確實對此發出警告,請在呼叫的開頭放置 `-H "Content-Type: application/json"` 來手動設定標頭。 這些範例也不包含 URL/IP 和通訊埠的組合,此組合必須是提供給 curl 的最後一個引數 (例如 `127.0.0.1:8545`)。 完整的 curl 請求包含採用以下形式的附加資料:
```shell
curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
```
-## Gossip、State、History {#gossip-state-history}
+## Gossip、狀態、歷史 {#gossip-state-history}
-少數重要的 JSON-RPC 方法需要來自以太坊網路的資料,這些資料分屬於三個種類:_Gossip、State 和 History_。 利用這些章節中的連結移動至每個方法,或利用目錄探索完整的方法清單。
+少數核心 JSON-RPC 方法需要來自以太坊網路的資料,並可整齊地分為三大類:_Gossip、狀態和歷史_。 利用這些章節中的連結移動至每個方法,或利用目錄探索完整的方法清單。
### Gossip 方法 {#gossip-methods}
@@ -104,7 +104,7 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho
- [eth_blockNumber](#eth_blocknumber)
- [eth_sendRawTransaction](#eth_sendrawtransaction)
-### State 方法 {#state_methods}
+### 狀態方法 {#state_methods}
> 報告所有已存儲資料的目前狀態的方法。 「狀態」像是一大塊可分享的隨機存取記憶體,包含帳戶餘額、合約資料和燃料預估。
@@ -115,7 +115,7 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho
- [eth_call](#eth_call)
- [eth_estimateGas](#eth_estimategas)
-### History 方法 {#history_methods}
+### 歷史方法 {#history_methods}
> 取得包括創世區塊在內的每一區塊的歷史記錄。 這像一個大型只能附加資料的檔案,包括所有區塊頭、區塊體、叔塊和交易收據。
@@ -134,9 +134,9 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho
## JSON-RPC 應用程式介面訓練場
-你可以使用[訓練場工具](https://ethereum-json-rpc.com)去發掘和試用應用程式介面方法。 訓練場也顯示不同的節點提供者支援的方法和網路。
+你可以使用 [遊樂場工具](https://ethereum-json-rpc.com) 來探索和試用 API 方法。 訓練場也顯示不同的節點提供者支援的方法和網路。
-## JSON-RPC 應用程式介面方法 {#json-rpc-methods}
+## JSON-RPC API 方法 {#json-rpc-methods}
### web3_clientVersion {#web3_clientversion}
@@ -148,14 +148,14 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho
**傳回**
-`String` - 目前用戶端版本
+`字串` - 目前的用戶端版本
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc":"2.0",
@@ -165,7 +165,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],
### web3_sha3 {#web3_sha3}
-傳回給定資料的 Keccak-256(_不是_ 標準化的 SHA3-256)。
+傳回給定資料的 Keccak-256 (「不是」標準化的 SHA3-256)。
**參數**
@@ -175,16 +175,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],
params: ["0x68656c6c6f20776f726c64"]
```
-**返回**
+**傳回**
`DATA` - 給定字串的 SHA3 結果。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
-// Result
+// 結果
{
"id":64,
"jsonrpc": "2.0",
@@ -200,7 +200,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c
無
-**返回**
+**傳回**
`String` - 目前網路 ID。
@@ -208,14 +208,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c
- `1`:以太坊主網
- `11155111`:Sepolia 測試網
-- `17000`:Hoodi 測試網
+- `560048`:Hoodi 測試網
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc": "2.0",
@@ -225,22 +225,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67
### net_listening {#net_listening}
-如果用戶端正在主動偵聽網路連結,則傳回 `true`。
+如果用戶端正在主動偵聽網路連線,則傳回 `true`。
**參數**
無
-**返回**
+**傳回**
-`Boolean` - 偵聽時為 `true`,否則為 `false`。
+`布林值` - 偵聽時為 `true`,否則為 `false`。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc":"2.0",
@@ -256,16 +256,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":
無
-**返回**
+**傳回**
-`QUANTITY` - 表示連結的對等點數量的整數。
+`QUANTITY` - 連線的對等點數量的整數。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
-// Result
+// 結果
{
"id":74,
"jsonrpc": "2.0",
@@ -275,22 +275,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":
### eth_protocolVersion {#eth_protocolversion}
-傳回目前的以太坊協定版本。 請注意此方法[在 Geth 中不可用](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)。
+傳回目前的以太坊協定版本。 請注意,此方法在 [Geth 中不可用](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)。
**參數**
無
-**返回**
+**傳回**
-`String` - 目前的以太坊協定版本
+`字串` - 目前的以太坊協定版本
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc": "2.0",
@@ -300,21 +300,25 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[]
### eth_syncing {#eth_syncing}
-傳回一個物件,其中包含有關同步狀態的資料或傳回 `false`。
+傳回一個包含同步狀態資料的物件,或傳回 `false`。
+
+
+ 在遊樂場試用端點
+
**參數**
無
-**返回**
+**傳回**
-準確的傳回資料因用戶端實作而異。 當節點未同步時,所有用戶端傳回 `False`,並且所有用戶端傳回下列欄位。
+準確的傳回資料因用戶端實作而異。 當節點未同步時,所有用戶端都會傳回 `False`,且所有用戶端都會傳回下列欄位。
-`Object|Boolean`,具有同步狀態資料的物件,或不同步時為 `FALSE`:
+`物件|布林值`,一個具有同步狀態資料的物件,或在未同步時為 `FALSE`:
-- `startingBlock`: `QUANTITY` - 匯入之開始區塊(僅在同步到達其頭部後才會重設)
-- `currentBlock`: `QUANTITY` - 目前區塊,與 eth_blockNumber 相同
-- `highestBlock`: `QUANTITY` - 估計的最高區塊
+- `startingBlock`:`QUANTITY` - 開始匯入的區塊 (只有在同步達到其標頭後才會重設)
+- `currentBlock`:`QUANTITY` - 目前區塊,與 eth_blockNumber 相同
+- `highestBlock`:`QUANTITY` - 預估的最高區塊
然而,個別用戶端也可以提供額外的資料。 例如 Geth 傳回如下資料:
@@ -362,9 +366,9 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[]
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -374,7 +378,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
highestBlock: '0x454'
}
}
-// Or when not syncing
+// 或在未同步時
{
"id":1,
"jsonrpc": "2.0",
@@ -386,7 +390,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
傳回用戶端的 coinbase 地址。
-> **注意:**此方法已於 **v1.14.0** 棄用並不再支援。 嘗試採用此方法將會出現「不支援此方法」的錯誤。
+
+ 在遊樂場試用端點
+
+
+> \*\*注意:\*\*此方法自 **v1.14.0** 起已被棄用,不再支援。 嘗試採用此方法將會出現「不支援此方法」的錯誤。
**參數**
@@ -394,14 +402,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
**傳回**
-`DATA`,20 位元組 - 目前 coinbase 地址。
+`DATA`,20 位元組 - 目前的 coinbase 位址。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}'
-// Result
+// 結果
{
"id":64,
"jsonrpc": "2.0",
@@ -413,20 +421,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6
傳回用來簽署重新執行攻擊保護交易的區塊鏈 ID。
+
+ 在遊樂場試用端點
+
+
**參數**
無
**傳回**
-`chainId`,十六進位數值字串,表示目前區塊鏈 ID 的整數值。
+`chainId`,十六進位值,以字串形式表示目前鏈 ID 的整數。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc": "2.0",
@@ -436,7 +448,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67
### eth_mining {#eth_mining}
-如果用戶端正活躍地開採新區塊,則傳回 `true`。 這方法只對工作量證明網路傳回 `true` 且自[合併](/roadmap/merge/)後這方法不可用在某些用戶端。
+如果用戶端正在積極開採新區塊,則傳回 `true`。 這只能對工作量證明網路傳回 `true`,且自 [合併](/roadmap/merge/) 後,某些用戶端可能無法使用。
+
+
+ 在遊樂場試用端點
+
**參數**
@@ -444,12 +460,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67
**傳回**
-`Boolean` - 如果用戶端正在挖礦,則傳回 `true`,否則傳回 `false`。
+`布林值` - 如果用戶端正在挖礦,則傳回 `true`,否則為 `false`。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
//
{
@@ -461,7 +477,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}
### eth_hashrate {#eth_hashrate}
-傳回正在挖礦的節點每秒的雜湊值數量。 這方法只對工作量證明網路傳回 `true` 且自[合併](/roadmap/merge/)後這方法不可用在某些用戶端。
+傳回正在挖礦的節點每秒的雜湊值數量。 這只能對工作量證明網路傳回 `true`,且自 [合併](/roadmap/merge/) 後,某些用戶端可能無法使用。
+
+
+ 在遊樂場試用端點
+
**參數**
@@ -469,14 +489,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}
**傳回**
-`QUANTITY` - 每秒的雜湊數。
+`QUANTITY` - 每秒的哈希數。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}'
-// Result
+// 結果
{
"id":71,
"jsonrpc": "2.0",
@@ -488,20 +508,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7
傳回預估的目前燃料價格,以 wei 為單位。 例如:Besu 用戶端檢查最後面 100 個區塊並預設傳回燃料單價中位數。
+
+ 在遊樂場試用端點
+
+
**參數**
無
**傳回**
-`QUANTITY` - 表示目前燃料價格的整數,以 wei 為單位。
+`QUANTITY` - 目前 gas 價格的整數,以 wei 為單位。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
-// Result
+// 結果
{
"id":73,
"jsonrpc": "2.0",
@@ -513,20 +537,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7
傳回用戶端擁有的地址清單。
+
+ 在遊樂場試用端點
+
+
**參數**
無
**傳回**
-`Array of DATA`,20 位元組 - 用戶端擁有的地址。
+`DATA 陣列`,20 位元組 - 用戶端擁有的位址。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -536,7 +564,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1
### eth_blockNumber {#eth_blocknumber}
-傳回最近的區塊編號。
+傳回最新區塊的編號。
+
+
+ 在遊樂場試用端點
+
**參數**
@@ -544,14 +576,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1
**傳回**
-`QUANTITY` - 表示用戶端目前所在區塊編號的整數。
+`QUANTITY` - 用戶端目前所在區塊編號的整數。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}'
-// Result
+// 結果
{
"id":83,
"jsonrpc": "2.0",
@@ -561,12 +593,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id
### eth_getBalance {#eth_getbalance}
-傳回給定地址的帳戶餘額。
+傳回指定位址帳戶的餘額。
+
+
+ 在遊樂場試用端點
+
**參數**
-1. `DATA`,20 位元組 - 要檢查餘額的地址。
-2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`,20 位元組 - 要檢查餘額的位址。
+2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
@@ -574,14 +610,14 @@ params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
**傳回**
-`QUANTITY` - 表示目前餘額的整數,以 wei 為單位。
+`QUANTITY` - 目前餘額的整數,以 wei 為單位。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -593,30 +629,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407
從給定地址的存儲位置傳回值。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `DATA`,20 位元組 - 存儲地址。
-2. `QUANTITY` - 表示存儲中的位置的整數。
-3. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`,請參閱[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`,20 位元組 - 儲存的位址。
+2. `QUANTITY` - 儲存中位置的整數。
+3. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`,請參閱[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)
**傳回**
-`DATA` - 此存儲位置的值。
+`DATA` - 此儲存位置的值。
-**範例** 正確的位置計算取決於要擷取的存儲。 考慮透過地址 `0x391694e7e0b0cce554cb130d723a9d27458f9298` 部署在 `0x295a70b2de5e3953354a6a8344e616ed314d7251` 的以下合約。
+**範例**
+計算正確位置取決於要擷取的儲存。 請考慮由位址 `0x391694e7e0b0cce554cb130d723a9d27458f9298` 部署在 `0x295a70b2de5e3953354a6a8344e616ed314d7251` 的下列合約。
```
contract Storage {
uint pos0;
mapping(address => uint) pos1;
- function Storage() {
+ constructor() {
pos0 = 1234;
pos1[msg.sender] = 5678;
}
}
```
-擷取 pos0 的值很簡單。
+擷取 pos0 的值很簡單:
```js
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
@@ -658,30 +699,34 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [
### eth_getTransactionCount {#eth_gettransactioncount}
-傳回從一個地址_發送_的交易數量。
+傳回從某一位址「傳送」的交易數量。
+
+
+ 在遊樂場試用端點
+
**參數**
-1. `DATA`,20 位元組 - 地址。
-2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`,20 位元組 - 位址。
+2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
"0x407d73d8a49eeb85d32cf465507dd71d507100c1",
- "latest", // state at the latest block
+ "latest", // 最新區塊的狀態
]
```
**傳回**
-`QUANTITY` - 表示從該地址發送的交易數量的整數。
+`QUANTITY` - 從此位址傳送的交易數量之整數。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -693,9 +738,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params
傳回區塊中從符合給定區塊雜湊值的交易數量。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `DATA`,32 位元組 - 區塊的雜湊值
+1. `DATA`,32 位元組 - 區塊的哈希
```js
params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
@@ -703,7 +752,7 @@ params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
**傳回**
-`QUANTITY` - 表示該區塊中交易數量的整數。
+`QUANTITY` - 此區塊中交易數量的整數。
**範例**
@@ -722,9 +771,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa
傳回與給定區塊編號相符的區塊中的交易數量。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `QUANTITY|TAG` - 整數區塊編號,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"` 或 `"finalized"`,如[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)所示。
+1. `QUANTITY|TAG` - 區塊編號的整數,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"` 或 `"finalized"`,如[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)中所述。
```js
params: [
@@ -734,7 +787,7 @@ params: [
**傳回**
-`QUANTITY` - 表示該區塊中交易數量的整數。
+`QUANTITY` - 此區塊中交易數量的整數。
**範例**
@@ -753,9 +806,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu
傳回區塊中符合給定區塊雜湊值的叔塊數量。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `DATA`,32 位元組 - 區塊的雜湊值
+1. `DATA`,32 位元組 - 區塊的哈希
```js
params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
@@ -763,7 +820,7 @@ params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
**傳回**
-`QUANTITY` - 表示該區塊中叔塊數量的整數。
+`QUANTITY` - 此區塊中叔塊數量的整數。
**範例**
@@ -782,9 +839,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p
傳回區塊中符合給定區塊編號的叔塊數量。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)
+1. `QUANTITY|TAG` - 區塊編號的整數,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -794,7 +855,7 @@ params: [
**傳回**
-`QUANTITY` - 表示該區塊中叔塊數量的整數。
+`QUANTITY` - 此區塊中叔塊數量的整數。
**範例**
@@ -813,10 +874,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber",
傳回給定地址的程式碼。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `DATA`,20 位元組 - 地址
-2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`,20 位元組 - 位址
+2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -827,7 +892,7 @@ params: [
**傳回**
-`DATA` - 來自給定地址的程式碼。
+`DATA` - 來自給定位址的程式碼。
**範例**
@@ -844,16 +909,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA
### eth_sign {#eth_sign}
-Sign 方法按以下方式計算以太坊特定簽章:`sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`。
+sign 方法會使用 `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))` 計算以太坊特定的簽章。
-透過在訊息中加入前綴,可以將計算出的簽章識別為以太坊特定簽章。 這可以防止濫用,即惡意去中心化應用程式簽署任意資料(例如交易)並使用簽章來冒充受害者。
+透過在訊息中加入前綴,可以將計算出的簽章識別為以太坊特定簽章。 這可以防止惡意去中心化應用程式簽署任意資料 (例如交易),並使用簽章冒充受害者的濫用情況。
注意:要簽章的地址必須解鎖。
**參數**
-1. `DATA`,20 位元組 - 地址
-2. `DATA`,N 位元組 - 要簽署的訊息。
+1. `DATA`,20 位元組 - 位址
+2. `DATA`,N 位元組 - 要簽署的訊息
**傳回**
@@ -862,9 +927,9 @@ Sign 方法按以下方式計算以太坊特定簽章:`sign(keccak256("\x19Eth
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -874,31 +939,31 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d37
### eth_signTransaction {#eth_signtransaction}
-簽署交易,稍後可使用 [eth_sendRawTransaction](#eth_sendrawtransaction) 將交易提交到網路。
+簽署一筆交易,稍後可使用 [eth_sendRawTransaction](#eth_sendrawtransaction) 提交到網路。
**參數**
-1. `Object` - 交易物件
+1. `物件` - 交易物件
-- `type`:
-- `from`: `DATA`,20 位元組 - 發送交易的地址。
-- `to`: `DATA` 20 位元組 -(建立新合約時可選)交易指向的地址。
-- `gas`: `QUANTITY` -(可選,預設:90000)表示為交易執行提供的燃料的整數。 將傳回未使用的燃料。
-- `gasPrice`: `QUANTITY` -(可選,預設:尚未決定)表示每次支付燃料時的燃料價格的整數(單位為 Wei)。
-- `value`: `QUANTITY` -(可選)表示與此交易一起傳送的值的整數(單位為 Wei)。
-- `data`: `DATA` - 合約的編譯程式碼,或叫用的方法簽章和編碼參數的雜湊。
-- `nonce`: `QUANTITY` -(可選)表示隨機數的整數。 這允許覆寫你自己的使用相同隨機數的待處理交易。
+- `type`:
+- `from`:`DATA`,20 位元組 - 交易傳送方的位址。
+- `to`:`DATA`,20 位元組 - (建立新合約時為選用) 交易指向的位址。
+- `gas`:`QUANTITY` - (選用,預設值:90000) 為交易執行提供的 gas 整數值。 將傳回未使用的燃料。
+- `gasPrice`:`QUANTITY` - (選用,預設值:待定) 用於每次支付 gas 的 gasPrice 整數值,以 Wei 為單位。
+- `value`:`QUANTITY` - (選用) 隨此交易傳送的價值整數值,以 Wei 為單位。
+- `data`:`DATA` - 合約的已編譯程式碼,或是所叫用方法簽章和已編碼參數的哈希。
+- `nonce`:`QUANTITY` - (選用) nonce 的整數值。 這允許覆寫你自己的使用相同隨機數的待處理交易。
**傳回**
-`DATA`,特定帳戶簽署的遞迴長度前綴編碼的交易物件。
+`DATA`,由指定帳戶簽署的 RLP 編碼交易物件。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}'
-// Result
+// 結果
{
"id": 1,
"jsonrpc": "2.0",
@@ -908,19 +973,19 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","
### eth_sendTransaction {#eth_sendtransaction}
-如果資料欄位包含程式碼,則建立新的訊息呼叫交易或建立合約,並使用 `from` 中指定的帳戶對其進行簽署。
+如果資料欄位包含程式碼,則建立新的訊息呼叫交易或合約建立,並使用 `from` 中指定的帳戶簽署。
**參數**
-1. `Object` - 交易物件
+1. `物件` - 交易物件
-- `from`: `DATA`,20 位元組 - 發送交易的地址。
-- `to`: `DATA` 20 位元組 -(建立新合約時可選)交易指向的地址。
-- `gas`: `QUANTITY` -(可選,預設:90000)表示為交易執行提供的燃料的整數。 將傳回未使用的燃料。
-- `gasPrice`: `QUANTITY` -(可選,預設:尚未決定)表示每次支付燃料時的燃料價格的整數。
-- `value`: `QUANTITY` -(可選)表示與此交易一起傳送的值的整數。
-- `input`: `DATA` - 合約的編譯程式碼,或叫用的方法簽章和編碼參數的雜湊值。
-- `nonce`: `QUANTITY` -(可選)表示隨機數的整數。 這允許覆寫你自己的使用相同隨機數的待處理交易。
+- `from`:`DATA`,20 位元組 - 交易傳送方的位址。
+- `to`:`DATA`,20 位元組 - (建立新合約時為選用) 交易指向的位址。
+- `gas`:`QUANTITY` - (選用,預設值:90000) 為交易執行提供的 gas 整數值。 將傳回未使用的燃料。
+- `gasPrice`:`QUANTITY` - (選用,預設值:待定) 用於每次支付 gas 的 gasPrice 整數值。
+- `value`:`QUANTITY` - (選用) 隨此交易傳送的價值整數值。
+- `input`:`DATA` - 合約的已編譯程式碼,或是所叫用方法簽章和已編碼參數的哈希。
+- `nonce`:`QUANTITY` - (選用) nonce 的整數值。 這允許覆寫你自己的使用相同隨機數的待處理交易。
```js
params: [
@@ -938,16 +1003,16 @@ params: [
**傳回**
-`DATA`,32 位元組 - 交易雜湊值,如果交易尚未可用則為零雜湊值。
+`DATA`,32 位元組 - 交易哈希,如果交易尚不可用,則為零哈希。
-建立合約時,在區塊中提議交易後,使用 [eth_getTransactionReceipt](#eth_gettransactionreceipt) 取得合約地址。
+當您建立合約時,在區塊中提議交易後,使用 [eth_getTransactionReceipt](#eth_gettransactionreceipt) 來取得合約位址。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -961,7 +1026,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{
**參數**
-1. `DATA`,簽署的交易資料。
+1. `DATA`,已簽署的交易資料。
```js
params: [
@@ -971,16 +1036,16 @@ params: [
**傳回**
-`DATA`,32 位元組 - 交易雜湊值,如果交易尚未可用則為零雜湊值。
+`DATA`,32 位元組 - 交易哈希,如果交易尚不可用,則為零哈希。
-建立合約時,在區塊中提議交易後,使用 [eth_getTransactionReceipt](#eth_gettransactionreceipt) 取得合約地址。
+當您建立合約時,在區塊中提議交易後,使用 [eth_getTransactionReceipt](#eth_gettransactionreceipt) 來取得合約位址。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -990,20 +1055,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params"
### eth_call {#eth_call}
-立即執行一個新的訊息呼叫,但不在區塊鏈上建立交易。 通常用於執行唯讀智慧型合約函式,例如 ERC-20 合約的 ` balanceOf`。
+立即執行一個新的訊息調用,但不在區塊鏈上建立交易。 常見用於執行唯讀的智能合約函式,例如 ERC-20 合約的 `balanceOf`。
+
+
+ 在遊樂場試用端點
+
**參數**
-1. `Object` - 交易呼叫物件
+1. `物件` - 交易呼叫物件
-- `from`: `DATA`,20 位元組 -(可選)發送交易的地址。
-- `to`: `DATA`,20 位元組 - 交易指向的地址。
-- `gas`: `QUANTITY` -(可選)表示為交易執行提供的燃料的整數。 eth_call 消耗零燃料,但某些執行可能需要此參數。
-- `gasPrice`: `QUANTITY` -(可選)表示每次支付燃料時的燃料價格的整數
-- `value`: `QUANTITY` -(可選)表示與此交易一起傳送的值的整數
-- `input`: `DATA` -(可選)方法簽章和編碼參數的雜湊值。 詳細資料請參考 [Solidity 文檔中的以太坊合約應用程式二進位介面](https://docs.soliditylang.org/en/latest/abi-spec.html)。
+- `from`:`DATA`,20 位元組 - (選用) 交易傳送方的位址。
+- `to`:`DATA`,20 位元組 - 交易指向的位址。
+- `gas`:`QUANTITY` - (選用) 為交易執行提供的 gas 整數值。 eth_call 消耗零燃料,但某些執行可能需要此參數。
+- `gasPrice`:`QUANTITY` - (選用) 用於每次支付 gas 的 gasPrice 整數值
+- `value`:`QUANTITY` - (選用) 隨此交易傳送的價值整數值
+- `input`:`DATA` - (選用) 方法簽章和已編碼參數的哈希。 有關詳細資訊,請參閱 [Solidity 文件中的以太坊合約 ABI](https://docs.soliditylang.org/en/latest/abi-spec.html)。
-2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)
+2. `QUANTITY|TAG` - 整數區塊編號,或字串 `"latest"`、`"earliest"`、`"pending"`、`"safe"` 或 `"finalized"`,請參閱[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)
**傳回**
@@ -1012,9 +1081,9 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params"
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -1026,20 +1095,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}]
產生和傳回完成交易所必需的燃料量預估值。 交易將不會新增至區塊鏈。 請注意,由於以太坊虛擬機機制和節點效能等種種原因,預估值可能明顯地大於交易實際使用的燃料量。
+
+ 在遊樂場試用端點
+
+
**參數**
-請參閱 [eth_call](#eth_call) 參數,但所有屬性都是可選的。 假如沒有明確說明燃料限制,Geth 將使用來自待處理區塊的區塊燃料限制作為上限。 因此,當燃料量高於待處理區塊燃料限制時,傳回的預估值可能不足以執行呼叫或交易。
+請參閱 [eth_call](#eth_call) 參數,但所有屬性都是選用的。 假如沒有明確說明燃料限制,Geth 將使用來自待處理區塊的區塊燃料限制作為上限。 因此,當 gas 量高於待處理區塊的 gas 限制時,傳回的估計值可能不足以執行呼叫/交易。
**傳回**
-`QUANTITY` - 使用的燃料數量。
+`QUANTITY` - 使用的 gas 數量。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -1051,10 +1124,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see
根據雜湊值傳回區塊資訊。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `DATA`,32 位元組 - 區塊的雜湊值。
-2. `Boolean` - 如果為 `true`,傳回完整交易物件,如果為 `false`,只傳回交易的雜湊值。
+1. `DATA`,32 位元組 - 區塊的哈希。
+2. `布林值` - 如果為 `true`,則傳回完整的交易物件;如果為 `false`,則只傳回交易的哈希。
```js
params: [
@@ -1065,39 +1142,38 @@ params: [
**傳回**
-`Object` - 區塊物件,或如果未找到區塊,則為 `null`:
-
-- `number`: `QUANTITY` - 區塊編號。 當為待處理區塊時,為 `null`。
-- `hash`: `DATA`,32 位元組 - 區塊的雜湊值。 當為待處理區塊時,為 `null`。
-- `parentHash`: `DATA`,32 位元組 - 父區塊的雜湊值。
-- `nonce`: `DATA`,8 位元組 - 產生的工作量證明的雜湊值。 當為待處理區塊時,為 `null`。
-- `sha3Uncles`: `DATA`,32 位元組 - 區塊中叔塊資料的第三代安全雜湊演算法。
-- `logsBloom`: `DATA`,256 位元組 - 區塊日誌的布隆篩選器。 當為待處理區塊時,為 `null`。
-- `transactionsRoot`: `DATA`,32 位元組 - 區塊交易樹的根。
-- `stateRoot`: `DATA`,32 位元組 - 區塊最終狀態樹的根。
-- `receiptsRoot`: `DATA`,32 位元組 - 區塊收據樹的根。
-- `miner`: `DATA`,20 位元組 - 挖礦獎勵受款人的地址。
-- `difficulty`: `QUANTITY` - 表示區塊難度的整數。
-- `totalDifficulty`: `QUANTITY` - 表示此區塊前的區塊鏈的總難度的整數。
-- `extraData`: `DATA` - 該區塊的「額外資料」欄位。
-- `size`: `QUANTITY` - 表示此區塊大小的整數,以位元組為單位。
-- `gasLimit`: `QUANTITY` - 此區塊允許的最大燃料量。
-- `gasUsed`: `QUANTITY` - 此區塊所有交易所使用的總燃料量。
-- `timestamp`: `QUANTITY` - 整理區塊時的 unix 時間戳。
-- `transactions`: `Array` - 交易物件陣列,或是 32 位元組交易雜湊值,取決於最後一個給定的參數。
-- `uncles`: `Array` - 叔塊雜湊值陣列。
+`物件` - 區塊物件,如果找不到區塊,則為 `null`:
+
+- `number`:`QUANTITY` - 區塊編號。 當區塊為待處理區塊時為 `null`。
+- `hash`:`DATA`,32 位元組 - 區塊的哈希。 當區塊為待處理區塊時為 `null`。
+- `parentHash`:`DATA`,32 位元組 - 父區塊的哈希。
+- `nonce`:`DATA`,8 位元組 - 產生的工作量證明哈希。 當區塊為待處理區塊時為 `null`,權益證明區塊 (自合併後) 為 `0x0`。
+- `sha3Uncles`:`DATA`,32 位元組 - 區塊中叔塊資料的 SHA3。
+- `logsBloom`:`DATA`,256 位元組 - 用於區塊日誌的布隆篩選器。 當區塊為待處理區塊時為 `null`。
+- `transactionsRoot`:`DATA`,32 位元組 - 區塊交易樹的根。
+- `stateRoot`:`DATA`,32 位元組 - 區塊最終狀態樹的根。
+- `receiptsRoot`:`DATA`,32 位元組 - 區塊收據樹的根。
+- `miner`:`DATA`,20 位元組 - 獲得區塊獎勵的受益人位址。
+- `difficulty`:`QUANTITY` - 此區塊難度的整數。
+- `totalDifficulty`:`QUANTITY` - 到此區塊為止的鏈總難度的整數。
+- `extraData`:`DATA` - 此區塊的「額外資料」欄位。
+- `size`:`QUANTITY` - 此區塊大小的整數,以位元組為單位。
+- `gasLimit`:`QUANTITY` - 此區塊中允許的最大 gas。
+- `gasUsed`:`QUANTITY` - 此區塊中所有交易使用的總 gas。
+- `timestamp`:`QUANTITY` - 區塊整理時的 unix 時間戳。
+- `transactions`:`陣列` - 交易物件的陣列,或 32 位元組的交易哈希,取決於最後一個給定的參數。
+- `uncles`:`陣列` - 叔塊哈希的陣列。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
-// Result
-{
+// 結果
{
-"jsonrpc": "2.0",
-"id": 1,
-"result": {
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
"difficulty": "0x4ea3f27bc",
"extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
"gasLimit": "0x1388",
@@ -1120,7 +1196,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
"transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
"uncles": [
]
-}
+ }
}
```
@@ -1128,10 +1204,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
根據區塊編號傳回關於區塊的資訊。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `QUANTITY|TAG` - 整數區塊編號,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"` 或 `"finalized"`,如[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)所示。
-2. `Boolean` - 如果為 `true`,傳回完整交易物件,如果為 `false`,只傳回交易的雜湊值。
+1. `QUANTITY|TAG` - 區塊編號的整數,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"` 或 `"finalized"`,如[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)中所述。
+2. `布林值` - 如果為 `true`,則傳回完整的交易物件;如果為 `false`,則只傳回交易的哈希。
```js
params: [
@@ -1140,12 +1220,13 @@ params: [
]
```
-**傳回** 請參與 [eth_getBlockByHash](#eth_getblockbyhash)
+**傳回**
+請參閱 [eth_getBlockByHash](#eth_getblockbyhash)
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
```
@@ -1155,9 +1236,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":[
傳回有關按交易雜湊值請求的交易的資訊。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `DATA`,32 位元組 - 交易的雜湊值
+1. `DATA`,32 位元組 - 交易的哈希
```js
params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
@@ -1165,29 +1250,29 @@ params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
**傳回**
-`Object` - 交易物件,或當找不到交易時為 `null`:
-
-- `blockHash`: `DATA`,32 位元組 - 此交易所在區塊的雜湊值。 當為待處理時,為 `null`。
-- `blockNumber`: `QUANTITY` - 此交易所在的區塊編號。 當為待處理時,為 `null`。
-- `from`: `DATA`,20 位元組 - 發送者的地址。
-- `gas`: `QUANTITY` - 發送者提供的燃料。
-- `gasPrice`: `QUANTITY` - 發送者提供的燃料價格,以 Wei 為單位。
-- `hash`: `DATA`,32 位元組 - 交易的雜湊值。
-- `input`: `DATA` - 隨交易一起傳送的資料。
-- `nonce`: `QUANTITY` - 發送者在這之前所進行的交易數量。
-- `to`: `DATA`,20 位元組 - 接收者的地址。 如果是合約建立交易,則為 `null`。
-- `transactionIndex`: `QUANTITY` - 表示區塊中交易索引位置的整數。 當為待處理時,為 `null`。
-- `value`: `QUANTITY` - 傳輸的值,以 Wei 為單位。
-- `v`: `QUANTITY` - 橢圓曲線數位簽章演算法復原 ID
-- `r`: `QUANTITY` - 橢圓曲線數位簽章演算法簽章 r
-- `s`: `QUANTITY` - 橢圓曲線數位簽章演算法簽章 s
+`物件` - 交易物件,如果找不到交易,則為 `null`:
+
+- `blockHash`:`DATA`,32 位元組 - 此交易所在區塊的哈希。 當為待處理時為 `null`。
+- `blockNumber`:`QUANTITY` - 此交易所在的區塊編號。 當為待處理時為 `null`。
+- `from`:`DATA`,20 位元組 - 傳送方的位址。
+- `gas`:`QUANTITY` - 傳送方提供的 gas。
+- `gasPrice`:`QUANTITY` - 傳送方提供的 gas 價格,以 Wei 為單位。
+- `hash`:`DATA`,32 位元組 - 交易的哈希。
+- `input`:`DATA` - 隨交易一起傳送的資料。
+- `nonce`:`QUANTITY` - 傳送方在此交易之前所做的交易數量。
+- `to`:`DATA`,20 位元組 - 接收方的位址。 當為合約建立交易時為 `null`。
+- `transactionIndex`:`QUANTITY` - 區塊中交易索引位置的整數。 當為待處理時為 `null`。
+- `value`:`QUANTITY` - 轉帳的價值,以 Wei 為單位。
+- `v`:`QUANTITY` - ECDSA 復原 ID
+- `r`:`QUANTITY` - ECDSA 簽章 r
+- `s`:`QUANTITY` - ECDSA 簽章 s
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
-// Result
+// 結果
{
"jsonrpc":"2.0",
"id":1,
@@ -1214,10 +1299,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param
按區塊雜湊值和交易索引位置傳回有關交易的資訊。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `DATA`,32 位元組 - 區塊的雜湊值。
-2. `QUANTITY` - 表示交易索引位置的整數。
+1. `DATA`,32 位元組 - 區塊的哈希。
+2. `QUANTITY` - 交易索引位置的整數。
```js
params: [
@@ -1226,7 +1315,8 @@ params: [
]
```
-**傳回** 請參閱 [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**傳回**
+請參閱 [eth_getTransactionByHash](#eth_gettransactionbyhash)
**範例**
@@ -1241,9 +1331,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAnd
按區塊編號和交易索引位置傳回有關交易的資訊。
+
+ 在遊樂場試用端點
+
+
**參數**
-1. `QUANTITY|TAG` - 區塊編號,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"` 或 `"finalized"`,如[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)所示。
+1. `QUANTITY|TAG` - 區塊編號,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"` 或 `"finalized"`,如[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)中所述。
2. `QUANTITY` - 交易索引位置。
```js
@@ -1253,12 +1347,13 @@ params: [
]
```
-**傳回** 請參閱 [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**傳回**
+請參閱 [eth_getTransactionByHash](#eth_gettransactionbyhash)
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
```
@@ -1268,43 +1363,44 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberA
按交易雜湊值返回交易的收據。
-**注意**待處理交易沒有收據。
+**注意** 待處理交易沒有收據。
**參數**
-1. `DATA`,32 位元組 - 交易的雜湊值
+1. `DATA`,32 位元組 - 交易的哈希
```js
params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
```
-**傳回** `Object` - 交易收據物件,或當找不到收據時為 `null`:
-
-- `transactionHash`: `DATA`,32 位元組 - 交易的雜湊值。
-- `transactionIndex`: `QUANTITY` - 表示區塊中交易索引位置的整數。
-- `blockHash`: `DATA`,32 位元組 - 此交易所在區塊的雜湊值。
-- `blockNumber`: `QUANTITY` - 此交易所在的區塊編號。
-- `from`: `DATA`,20 位元組 - 發送者的地址。
-- `to`: `DATA`,20 位元組 - 接收者的地址。 如果是合約建立交易,則為 null。
-- `cumulativeGasUsed`: `QUANTITY` - 當區塊執行此交易時所使用的總燃料量。
-- `effectiveGasPrice`: `QUANTITY` - 每單位燃料支付的基本費用和小費的總和。
-- `gasUsed`: `QUANTITY` - 僅此特定交易所使用的燃料量。
-- `contractAddress`: `DATA`,20 位元組 - 如果交易為建立合約,則為建立的合約地址,否則為 `null`。
-- `logs`: `Array` - 此交易產生的日誌物件陣列。
-- `logsBloom`: `DATA`,256 位元組 - 給輕量用戶端快速擷取相關日誌的布隆篩選器。
-- `type`: `QUANTITY` - 表示交易類型的整數,`0x0` 表示傳統交易,`0x1` 表示存取清單類型, `0x2` 表示動態費用。
-
-它也傳回 _以下兩者之一_:
-
-- `root` : `DATA` 32 位元組的交易後狀態根(拜占庭升級之前)
-- `status`: `QUANTITY` 要麼 `1`(成功)要麼 `0`(失敗)
+**傳回**
+`物件` - 交易收據物件,如果找不到收據,則為 `null`:
+
+- `transactionHash `:`DATA`,32 位元組 - 交易的哈希。
+- `transactionIndex`:`QUANTITY` - 區塊中交易索引位置的整數。
+- `blockHash`:`DATA`,32 位元組 - 此交易所在區塊的哈希。
+- `blockNumber`:`QUANTITY` - 此交易所在的區塊編號。
+- `from`:`DATA`,20 位元組 - 傳送方的位址。
+- `to`:`DATA`,20 位元組 - 接收方的位址。 如果是合約建立交易,則為 null。
+- `cumulativeGasUsed` : `QUANTITY ` - 當此交易在區塊中執行時使用的總 gas 量。
+- `effectiveGasPrice`:`QUANTITY` - 每單位 gas 支付的基本費用和小費的總和。
+- `gasUsed `:`QUANTITY ` - 僅此特定交易所使用的 gas 量。
+- `contractAddress `:`DATA`,20 位元組 - 如果交易是合約建立,則為建立的合約位址,否則為 `null`。
+- `logs`:`陣列` - 此交易所產生的日誌物件陣列。
+- `logsBloom`:`DATA`,256 位元組 - 供輕用戶端快速擷取相關日誌的布隆篩選器。
+- `type`:`QUANTITY` - 交易類型的整數,`0x0` 為舊式交易,`0x1` 為存取列表類型,`0x2` 為動態費用。
+
+它也傳回以下其中一項:
+
+- `root`:`DATA` 32 位元組的交易後狀態根 (拜占庭前)
+- `status`:`QUANTITY` 為 `1` (成功) 或 `0` (失敗)
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'
-// Result
+// 結果
{
"jsonrpc": "2.0",
"id": 1,
@@ -1312,15 +1408,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
"blockHash":
"0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
"blockNumber": "0xeff35f",
- "contractAddress": null, // string of the address if it was created
+ "contractAddress": null, // 如果已建立,則為位址字串
"cumulativeGasUsed": "0xa12515",
"effectiveGasPrice": "0x5a9c688d4",
"from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
"gasUsed": "0xb4c8",
"logs": [{
- // logs as returned by getFilterLogs, etc.
+ // getFilterLogs 等傳回的日誌
}],
- "logsBloom": "0x00...0", // 256 byte bloom filter
+ "logsBloom": "0x00...0", // 256 位元組布隆篩選器
"status": "0x1",
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"transactionHash":
@@ -1333,11 +1429,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
-按雜湊值和叔塊索引位置傳回關於區塊的叔塊資訊。
+透過哈希和叔塊索引位置傳回區塊叔塊的相關資訊。
+
+
+ 在遊樂場試用端點
+
**參數**
-1. `DATA`,32 位元組 - 區塊的雜湊值。
+1. `DATA`,32 位元組 - 區塊的哈希。
2. `QUANTITY` - 叔塊的索引位置。
```js
@@ -1347,7 +1447,8 @@ params: [
]
```
-**傳回** 請參與 [eth_getBlockByHash](#eth_getblockbyhash)
+**傳回**
+請參閱 [eth_getBlockByHash](#eth_getblockbyhash)
**範例**
@@ -1358,15 +1459,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex"
結果請參閱 [eth_getBlockByHash](#eth_getblockbyhash)
-**注意**:叔塊不包含單獨交易。
+**注意**:叔塊不包含個別交易。
### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
-按編號和叔塊索引位置傳回關於區塊的叔塊資訊。
+透過編號和叔塊索引位置傳回區塊叔塊的相關資訊。
+
+
+ 在遊樂場試用端點
+
**參數**
-1. `QUANTITY|TAG` - 區塊編號,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"` 或 `"finalized"`,如[預設區塊參數](/developers/docs/apis/json-rpc/#default-block)所示。
+1. `QUANTITY|TAG` - 區塊編號,或字串 `"earliest"`、`"latest"`、`"pending"`、`"safe"`、`"finalized"`,如[區塊參數](/developers/docs/apis/json-rpc/#block-parameter)中所述。
2. `QUANTITY` - 叔塊的索引位置。
```js
@@ -1376,14 +1481,15 @@ params: [
]
```
-**傳回** 請參與 [eth_getBlockByHash](#eth_getblockbyhash)
+**傳回**
+請參閱 [eth_getBlockByHash](#eth_getblockbyhash)
-**注意**:叔塊不包含單獨交易。
+**注意**:叔塊不包含個別交易。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
```
@@ -1391,23 +1497,25 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndInde
### eth_newFilter {#eth_newfilter}
-根據篩選條件選項建立一個篩選條件物件,以在狀態改變時發出通知(日誌)。 檢查狀態是否改變,呼叫 [eth_getFilterChanges](#eth_getfilterchanges)。
+根據篩選條件選項建立一個篩選條件物件,以在狀態改變時發出通知(日誌)。
+若要檢查狀態是否已變更,請呼叫 [eth_getFilterChanges](#eth_getfilterchanges)。
-**關於指定主題篩選條件的說明:** 主題跟順序相關。 以下主題篩選條件將匹配日誌中包含主題 [A, B] 的交易:
+**關於指定主題篩選器的說明:**
+主題是順序相依的。 以下主題篩選條件將匹配日誌中包含主題 [A, B] 的交易:
-- `[]`「任意值」
-- `[A]`「第一個位置為 A(其後為任意值)」
-- `[null, B]`「第一位置為任意值,且第二位置為 B(其後為任意值)」
-- `[A, B]`「第一位置為 A,且第二位置為 B(其後為任意值)」
-- `[[A, B], [A, B]]`「第一位置為(A 或 B)且第二位置為(A 或 B)(其後為任意值)」
+- `[]` 「任何內容」
+- `[A]` 「A 在第一個位置 (後面可以是任何內容)」
+- `[null, B]` 「第一個位置是任何內容,且 B 在第二個位置 (後面可以是任何內容)」
+- `[A, B]` 「A 在第一個位置,且 B 在第二個位置 (後面可以是任何內容)」
+- `[[A, B], [A, B]]` 「(A 或 B) 在第一個位置,且 (A 或 B) 在第二個位置 (後面可以是任何內容)」
- **參數**
-1. `Object` - 篩選條件選項:
+1. `物件` - 篩選選項:
-- `fromBlock`: `QUANTITY|TAG` -(可選,預設:`"latest"`)整數區塊編號,或 `"latest"` 表示最近提議的區塊,`"safe"` 表示最新的安全區塊,`"finalized"` 表示最新的最終確定區塊,或 `"pending"`,`"earliest"` 表示尚未在區塊中的交易。
-- `toBlock`: `QUANTITY|TAG` -(可選,預設:`"latest"`)整數區塊編號,或 `"latest"` 表示最近提議的區塊,`"safe"` 表示最新的安全區塊,`"finalized"` 表示最新的最終確定區塊,或 `"pending"`,`"earliest"` 表示尚未在區塊中的交易。
-- `address`: `DATA|Array`,20 位元組 - (可選)合約地址或日誌起源的地址清單。
-- `topics`: `Array of DATA`,(可選)32 位元組陣列 `DATA` 主題。 主題與順序相關。 每個主題也可以為帶有「或」選項的 DATA 陣列。
+- `fromBlock`:`QUANTITY|TAG` - (選用,預設:`"latest"`) 整數區塊編號,或 `"latest"` 代表最後提議的區塊、`"safe"` 代表最新的安全區塊、`"finalized"` 代表最新的最終確認區塊,或 `"pending"`、`"earliest"` 代表尚未進入區塊的交易。
+- `toBlock`:`QUANTITY|TAG` - (選用,預設:`"latest"`) 整數區塊編號,或 `"latest"` 代表最後提議的區塊、`"safe"` 代表最新的安全區塊、`"finalized"` 代表最新的最終確認區塊,或 `"pending"`、`"earliest"` 代表尚未進入區塊的交易。
+- `address`:`DATA|陣列`,20 位元組 - (選用) 合約位址或日誌應源自的位址清單。
+- `topics`:`DATA 陣列` - (選用) 32 位元組 `DATA` 主題的陣列。 主題與順序相關。 每個主題也可以為帶有「或」選項的 DATA 陣列。
```js
params: [
@@ -1427,14 +1535,15 @@ params: [
]
```
-**傳回** `QUANTITY` - 篩選條件 ID。
+**傳回**
+`QUANTITY` - 篩選器 ID。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -1444,18 +1553,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic
### eth_newBlockFilter {#eth_newblockfilter}
-在節點中建立一個篩選條件,以在新區塊到達時發出通知。 檢查狀態是否改變,呼叫 [eth_getFilterChanges](#eth_getfilterchanges)。
+在節點中建立一個篩選條件,以在新區塊到達時發出通知。
+若要檢查狀態是否已變更,請呼叫 [eth_getFilterChanges](#eth_getfilterchanges)。
-**參數** 無
+**參數**
+無
-**傳回** `QUANTITY` - 篩選條件 ID。
+**傳回**
+`QUANTITY` - 篩選器 ID。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -1465,18 +1577,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],
### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
-在節點中建立一個篩選條件,以在新的待處理交易到達時發出通知。 檢查狀態是否改變,呼叫 [eth_getFilterChanges](#eth_getfilterchanges)。
+在節點中建立一個篩選條件,以在新的待處理交易到達時發出通知。
+若要檢查狀態是否已變更,請呼叫 [eth_getFilterChanges](#eth_getfilterchanges)。
-**參數** 無
+**參數**
+無
-**傳回** `QUANTITY` - 篩選條件 ID。
+**傳回**
+`QUANTITY` - 篩選器 ID。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -1486,11 +1601,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter"
### eth_uninstallFilter {#eth_uninstallfilter}
-根據給定 ID 解除安裝篩選條件。 當不再需要監視時,應始終對其進行呼叫。 另外,當在一段時間內未使用 [eth_getFilterChanges](#eth_getfilterchanges) 請求篩選條件時,篩選條件會逾時。
+根據給定 ID 解除安裝篩選條件。 當不再需要監視時,應始終對其進行呼叫。
+此外,如果篩選器在一段時間內未使用 [eth_getFilterChanges](#eth_getfilterchanges) 請求,則會逾時。
**參數**
-1. `QUANTITY` - 篩選條件 ID。
+1. `QUANTITY` - 篩選器 ID。
```js
params: [
@@ -1498,14 +1614,15 @@ params: [
]
```
-**傳回** `Boolean` - 如果成功解除安裝篩選條件,則為 `true`,否則為 `false`。
+**傳回**
+`布林值` - 如果篩選器成功解除安裝,則為 `true`,否則為 `false`。
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}'
-// Result
+// 結果
{
"id":1,
"jsonrpc": "2.0",
@@ -1519,7 +1636,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["
**參數**
-1. `QUANTITY` - 篩選條件 ID。
+1. `QUANTITY` - 篩選器 ID。
```js
params: [
@@ -1527,26 +1644,30 @@ params: [
]
```
-**傳回** `Array` - 日誌物件陣列,或如果自上次輪詢沒有任何變更,則為空陣列。
-
-- 對於使用 `eth_newBlockFilter` 建立的篩選條件,傳回值是區塊雜湊值(`DATA`,32 位元組),例如 `["0x3454645634534..."]`。
-- 對於使用 `eth_newPendingTransactionFilter` 建立的篩選條件,傳回值是交易雜湊值(`DATA`,32 位元組),例如 `["0x6345343454645..."]`。
-- 對於使用 `eth_newFilter` 建立的篩選條件,日誌是包含下列參數的物件:
- - `removed`: `TAG` - 當日誌由於鏈重組被移除時,為 `true`。 如果是有效日誌,則為 `false`。
- - `logIndex`: `QUANTITY` - 表示區塊內日誌索引位置的整數。 當為待處理日誌時,為 `null`。
- - `transactionIndex`: `QUANTITY` - 表示從中建立日誌的交易索引位置的整數。 當為待處理日誌時,為 `null`。
- - `transactionHash`: `DATA`,32 位元組 - 從中建立此日誌的交易的雜湊值。 當為待處理日誌時,為 `null`。
- - `blockHash`: `DATA`,32 位元組 - 此日誌所在區塊的雜湊值。 當為待處理時,為 `null`。 當為待處理日誌時,為 `null`。
- - `blockNumber`: `QUANTITY` - 此日誌所在的區塊編號。 當為待處理時,為 `null`。 當為待處理日誌時,為 `null`。
- - `address`: `DATA`,20 位元組 -此日誌的來源地址。
- - `data`: `DATA` - 包含零個或多個 32 位元組非索引日誌引數。
- - `topics`: `Array of DATA` - 索引日誌引數的 0 到 4 個 32 位元組 `DATA` 陣列。 (在 _solidity_:第一個主題是事件簽章的_雜湊值_(例如 `Deposit(address,bytes32,uint256)`),除非你使用說明符 `anonymous` 宣告了該事件)。
+**傳回**
+`陣列` - 日誌物件的陣列,如果自上次輪詢以來沒有任何變更,則為空陣列。
+
+- 對於使用 `eth_newBlockFilter` 建立的篩選器,傳回值為區塊哈希 (`DATA`,32 位元組),例如 `["0x3454645634534..."]`。
+
+- 對於使用 `eth_newPendingTransactionFilter ` 建立的篩選器,傳回值為交易哈希 (`DATA`,32 位元組),例如 `["0x6345343454645..."]`。
+
+- 對於使用 `eth_newFilter` 建立的篩選器,日誌是具有以下參數的物件:
+ - `removed`:`TAG` - `true` 表示由於鏈重組而移除了日誌。 如果是有效日誌,則為 `false`。
+ - `logIndex`:`QUANTITY` - 區塊中日誌索引位置的整數。 當為待處理日誌時為 `null`。
+ - `transactionIndex`:`QUANTITY` - 建立日誌的交易索引位置的整數。 當為待處理日誌時為 `null`。
+ - `transactionHash`:`DATA`,32 位元組 - 建立此日誌的交易哈希。 當為待處理日誌時為 `null`。
+ - `blockHash`:`DATA`,32 位元組 - 此日誌所在區塊的哈希。 當為待處理時為 `null`。 當為待處理日誌時為 `null`。
+ - `blockNumber`:`QUANTITY` - 此日誌所在的區塊編號。 當為待處理時為 `null`。 當為待處理日誌時為 `null`。
+ - `address`:`DATA`,20 位元組 - 此日誌源自的位址。
+ - `data`:`DATA` - 可變長度的非索引日誌資料。 (在 _solidity_ 中:零個或多個 32 位元組的非索引日誌引數。)
+ - `topics`:`DATA 陣列` - 0 到 4 個 32 位元組 `DATA` 的索引日誌引數陣列。 (在 _solidity_ 中:第一個主題是事件簽章的_哈希_ (例如 `Deposit(address,bytes32,uint256)`),除非您使用 `anonymous` 指定符宣告了該事件。)
+
- **範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
-// Result
+// 結果
{
"id":1,
"jsonrpc":"2.0",
@@ -1571,7 +1692,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":[
**參數**
-1. `QUANTITY` - 篩選條件 ID。
+1. `QUANTITY` - 篩選器 ID。
```js
params: [
@@ -1579,12 +1700,13 @@ params: [
]
```
-**傳回** 請參閱 [eth_getFilterChanges](#eth_getfilterchanges)
+**傳回**
+請參閱 [eth_getFilterChanges](#eth_getfilterchanges)
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
```
@@ -1596,13 +1718,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x
**參數**
-1. `Object` - 篩選條件選項:
+1. `物件` - 篩選選項:
-- `fromBlock`: `QUANTITY|TAG` -(可選,預設:`"latest"`)整數區塊編號,或 `"latest"` 表示最近提議的區塊,`"safe"` 表示最新的安全區塊,`"finalized"` 表示最新的最終確定區塊,或 `"pending"`,`"earliest"` 表示尚未在區塊中的交易。
-- `toBlock`: `QUANTITY|TAG` -(可選,預設:`"latest"`)整數區塊編號,或 `"latest"` 表示最近提議的區塊,`"safe"` 表示最新的安全區塊,`"finalized"` 表示最新的最終確定區塊,或 `"pending"`,`"earliest"` 表示尚未在區塊中的交易。
-- `address`: `DATA|Array`,20 位元組 - (可選)合約地址或日誌起源的地址清單。
-- `topics`: `Array of DATA`,(可選)32 位元組陣列 `DATA` 主題。 主題與順序相關。 每個主題也可以為帶有「或」選項的 DATA 陣列。
-- `blockhash`: `DATA`,32 位元組 - (可選,**future**),新增 EIP-234 後,`blockHash` 將是一個新的篩選條件選項,會將傳回的日誌限制為具有 32 位元組雜湊值 `blockHash` 的單一區塊。 使用 `blockHash` 等於 `fromBlock` = `toBlock` = 具有雜湊值 `blockHash` 的區塊編號。 如果 `blockHash` 出現在篩選條件中,則 `fromBlock` 和 `toBlock` 都不允許使用。
+- `fromBlock`:`QUANTITY|TAG` - (選用,預設:`"latest"`) 整數區塊編號,或 `"latest"` 代表最後提議的區塊、`"safe"` 代表最新的安全區塊、`"finalized"` 代表最新的最終確認區塊,或 `"pending"`、`"earliest"` 代表尚未進入區塊的交易。
+- `toBlock`:`QUANTITY|TAG` - (選用,預設:`"latest"`) 整數區塊編號,或 `"latest"` 代表最後提議的區塊、`"safe"` 代表最新的安全區塊、`"finalized"` 代表最新的最終確認區塊,或 `"pending"`、`"earliest"` 代表尚未進入區塊的交易。
+- `address`:`DATA|陣列`,20 位元組 - (選用) 合約位址或日誌應源自的位址清單。
+- `topics`:`DATA 陣列` - (選用) 32 位元組 `DATA` 主題的陣列。 主題與順序相關。 每個主題也可以為帶有「或」選項的 DATA 陣列。
+- `blockHash`:`DATA`,32 位元組 - (選用,**未來**) 隨著 EIP-234 的新增,`blockHash` 將成為一個新的篩選選項,它會將傳回的日誌限制在具有 32 位元組哈希 `blockHash` 的單一區塊中。 使用 `blockHash` 等同於 `fromBlock` = `toBlock` = 具有哈希 `blockHash` 的區塊編號。 如果 `blockHash` 存在於篩選條件中,則不允許使用 `fromBlock` 和 `toBlock`。
```js
params: [
@@ -1614,12 +1736,13 @@ params: [
]
```
-**傳回** 請參閱 [eth_getFilterChanges](#eth_getfilterchanges)
+**傳回**
+請參閱 [eth_getFilterChanges](#eth_getfilterchanges)
**範例**
```js
-// Request
+// 請求
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
```
@@ -1629,9 +1752,9 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics"
### 使用 JSON_RPC 部署合約 {#deploying-contract}
-這部分示範如何只使用遠端程序呼叫介面部署合約。 有其他的部署合約方法可以消除這種複雜性,例如,使用建置在遠端程序呼叫介面之上的程式庫,例如 [web3.js](https://web3js.readthedocs.io/) 和 [web3.py](https://github.com/ethereum/web3.py)。 雖然在抽象化之後,一般來說比較容易理解和較不易出錯,但理解在後台發生了什麼是有益的。
+這部分示範如何只使用遠端程序呼叫介面部署合約。 還有其他部署合約的替代途徑,可以將這種複雜性抽象化,例如,使用建構在 RPC 介面之上的函式庫,如 [web3.js](https://web3js.readthedocs.io/) 和 [web3.py](https://github.com/ethereum/web3.py)。 雖然在抽象化之後,一般來說比較容易理解和較不易出錯,但理解在後台發生了什麼是有益的。
-下面是一個名為 `Multiply7` 的簡單智慧型合約,將使用 JSON-RPC 介面把其部署到以太坊節點。 本教學假設讀者已經執行一個 Geth 節點。 更多節點和用戶端的資訊可以在[這裡](/developers/docs/nodes-and-clients/run-a-node)獲得。 請參考個別的[用戶端](/developers/docs/nodes-and-clients/)文件瞭解如何為非 Geth 用戶端開啟 HTTP JSON-RPC。 大多數用戶端預設在 `localhost:8545` 上提供服務。
+以下是一個名為 `Multiply7` 的簡單智能合約,將使用 JSON-RPC 介面部署到以太坊節點。 本教學假設讀者已經執行一個 Geth 節點。 有關節點和用戶端的更多資訊,請參閱[此處](/developers/docs/nodes-and-clients/run-a-node)。 請參閱個別[用戶端](/developers/docs/nodes-and-clients/)文件,以了解如何為非 Geth 用戶端啟動 HTTP JSON-RPC。 大多數用戶端預設在 `localhost:8545` 上提供服務。
```javascript
contract Multiply7 {
@@ -1643,18 +1766,18 @@ contract Multiply7 {
}
```
-首先,確定啟用了 HTTP 遠端程序呼叫介面。 也就是說,在啟動時我們為 Geth 提供 `--http` 旗標。 在這個例子中,我們使用私有開發鏈的 Geth 節點。 使用這個方法,將不需要真實網路上的以太幣。
+首先,確定啟用了 HTTP 遠端程序呼叫介面。 這表示我們在啟動時為 Geth 提供 `--http` 旗標。 在這個例子中,我們使用私有開發鏈的 Geth 節點。 使用這個方法,將不需要真實網路上的以太幣。
```bash
geth --http --dev console 2>>geth.log
```
-這將在 `http://localhost:8545` 上啟動 HTTP 遠端程序呼叫介面。
+這將在 `http://localhost:8545` 上啟動 HTTP RPC 介面。
-我們可以透過使用 [ curl](https://curl.se) 取得 Coinbase 地址(獲取帳戶陣列中的第一個地址)和餘額,驗證介面是否正在執行。 請注意,這些範例中的資料與你的本地節點有所不同。 如果你想嘗試這些命令,請將第二個 curl 請求中的請求參數替換為第一個請求返回的結果。
+我們可以使用 [curl](https://curl.se) 擷取 coinbase 位址 (透過取得帳戶陣列中的第一個位址) 和餘額,來驗證介面是否正在執行。 請注意,這些範例中的資料與你的本地節點有所不同。 如果你想嘗試這些命令,請將第二個 curl 請求中的請求參數替換為第一個請求返回的結果。
```bash
-curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545
+curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545
{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
@@ -1668,9 +1791,9 @@ web3.fromWei("0x1639e49bba16280000", "ether")
// "410"
```
-現在我們的私有開發鏈上有一些以太幣,我們可以部署合約了。 第一步是把 Multiply7 合約編譯成可以傳送到以太坊虛擬機的字元組程式碼。 要安裝 Solidity 編譯器 solc,請參考 [Solidity 文件](https://docs.soliditylang.org/en/latest/installing-solidity.html)。 (為符合[我們的範例中使用的編譯器版本](https://github.com/ethereum/solidity/releases/tag/v0.4.20),你可能想要使用較舊的 `solc` 版本。)
+現在我們的私有開發鏈上有一些以太幣,我們可以部署合約了。 第一步是把 Multiply7 合約編譯成可以傳送到以太坊虛擬機的字元組程式碼。 若要安裝 Solidity 編譯器 solc,請遵循 [Solidity 文件](https://docs.soliditylang.org/en/latest/installing-solidity.html)。 (您可能需要使用較舊的 `solc` 版本,以符合[我們範例中使用的編譯器版本](https://github.com/ethereum/solidity/releases/tag/v0.4.20)。)
-下一步是把 Multiply7 合約編譯成可以傳送到以太坊虛擬機的字元組程式碼。
+下一步是將 Multiply7 合約編譯成可傳送至 EVM 的位元組碼。
```bash
echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
@@ -1680,7 +1803,7 @@ Binary:
6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
```
-現在我們有了編譯後的程式碼,我們需要確定部署程式碼需要花費多少燃料。 遠端程序呼叫介面有 `eth_estimateGas` 方法可以給我們預估值。
+現在我們有了編譯後的程式碼,我們需要確定部署程式碼需要花費多少燃料。 RPC 介面有一個 `eth_estimateGas` 方法,可以提供我們一個估計值。
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
@@ -1694,20 +1817,20 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from
{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
```
-交易被節點接受且傳回交易雜湊值。 雜湊值可以用來追蹤交易。 下一步是確定將合約部署至的地址。 每一個被執行的交易將會產生一份收據。 此收據包含各種關於交易的資訊,例如:交易包含在哪一個區塊中,以及以太坊虛擬機使用多少燃料。 假如交易建立一個合約,交易也將包含合約地址。 我們可以用 `eth_getTransactionReceipt` 遠端程序呼叫方法擷取收據。
+交易被節點接受且傳回交易雜湊值。 雜湊值可以用來追蹤交易。 下一步是確定將合約部署至的地址。 每一個被執行的交易將會產生一份收據。 此收據包含各種關於交易的資訊,例如:交易包含在哪一個區塊中,以及以太坊虛擬機使用多少燃料。 假如交易建立一個合約,交易也將包含合約地址。 我們可以使用 `eth_getTransactionReceipt` RPC 方法擷取收據。
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
```
-我們的合約是建立在 `0x4d03d617d700cf81935d7f797f4e2ae719648262`。 結果為 null 而不是收據時,表示交易尚未列入區塊中。 稍等一下,並檢查你的共識用戶端是否正常執行,然後重試一次。
+我們的合約建立於 `0x4d03d617d700cf81935d7f797f4e2ae719648262`。 結果為 null 而不是收據時,表示交易尚未列入區塊中。 稍等一下,並檢查你的共識用戶端是否正常執行,然後重試一次。
#### 與智能合約互動 {#interacting-with-smart-contract}
-在此範例中,我們將使用 `eth_sendTransaction` 向合約的 `multiply` 方法傳送交易。
+在此範例中,我們將使用 `eth_sendTransaction` 將交易傳送到合約的 `multiply` 方法。
-`eth_sendTransaction` 需要若干引數,特別是 `from`、`to` 和 `data`。 `From` 是我們帳戶的公共地址,`to` 是合約地址。 `data` 引數包含有效負載,定義了必須呼叫哪個方法以及使用哪些引數。 這是 [ABI(應用程式二進位介面)](https://docs.soliditylang.org/en/latest/abi-spec.html)發揮作用的地方。 應用程式二進位介面是定義如何為以太坊虛擬機定義和編碼資料的 JSON 檔案。
+`eth_sendTransaction` 需要幾個引數,特別是 `from`、`to` 和 `data`。 `From` 是我們帳戶的公開位址,`to` 是合約位址。 `data` 引數包含一個有效負載,定義了必須呼叫哪個方法以及使用哪些引數。 這就是 [ABI (應用程式二進位介面)](https://docs.soliditylang.org/en/latest/abi-spec.html) 發揮作用的地方。 應用程式二進位介面是定義如何為以太坊虛擬機定義和編碼資料的 JSON 檔案。
有效負載中的位元組定義要呼叫合約中的哪個方法。 這是函式名稱及其引數類型的 Keccak 雜湊值的前 4 個位元組(十六進位編碼)。 Multiply 函式接受 uint,它是 uint256 的別名。 我們得到以下結果:
@@ -1718,11 +1841,11 @@ web3.sha3("multiply(uint256)").substring(0, 10)
下一步是對引數進行編碼。 只有一個 uint256,例如值 6。 應用程式二進制介面有一個部分指定如何對 uint256 類型進行編碼。
-`int: enc(X)` 是 X 的高位元組在前二進位補碼編碼,對於負 X 在高位(左側)填充 0xff,對於正 X 填充零 > 位元組,使得長度為 32 位元組的倍數。
+`int`: `enc(X)` 是 X 的大序二補數編碼,對於負數 X,在高位(左側)填充 0xff;對於正數 X,則填充零位元組,使長度成為 32 位元組的倍數。
-這編碼為 `000000000000000000000000000000000000000000000000000000000000006`。
+這會編碼為 `0000000000000000000000000000000000000000000000000000000000000006`。
-結合函式選擇器和已編碼的引數,我們的資料如下:`0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`。
+結合函式選擇器和編碼引數,我們的資料將是 `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`。
現在可將其傳送到節點:
@@ -1755,7 +1878,7 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from
}
```
-收據包含了日誌。 此日誌由以太坊虛擬機在交易執行時產生並包含在收據中。 `multiply` 函式顯示 `Print` 事件在輸入乘以 7 時觸發。 由於 `Print` 事件的引數是 uint256,我們可以根據應用程式二進位介面規則對其進行解碼,得到預期的十進位數 42。 除了資料之外,值得注意的是,主題可用於確定哪個事件建立了日誌:
+收據包含了日誌。 此日誌由以太坊虛擬機在交易執行時產生並包含在收據中。 `multiply` 函式顯示,當輸入乘以 7 時,會引發 `Print` 事件。 由於 `Print` 事件的引數是 uint256,我們可以根據 ABI 規則對其進行解碼,這將得到預期的十進位 42。 除了資料之外,值得注意的是,主題可用於確定哪個事件建立了日誌:
```javascript
web3.sha3("Print(uint256)")
@@ -1768,7 +1891,6 @@ web3.sha3("Print(uint256)")
- [JSON-RPC 規範](http://www.jsonrpc.org/specification)
- [節點和用戶端](/developers/docs/nodes-and-clients/)
-- [Javascript 應用程式介面](/developers/docs/apis/javascript/)
-- [後端應用程式介面](/developers/docs/apis/backend/)
+- [JavaScript API](/developers/docs/apis/javascript/)
+- [後端 API](/developers/docs/apis/backend/)
- [執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)
-
diff --git a/public/content/translations/zh-tw/developers/docs/blocks/index.md b/public/content/translations/zh-tw/developers/docs/blocks/index.md
index af267033ab6..197514e5628 100644
--- a/public/content/translations/zh-tw/developers/docs/blocks/index.md
+++ b/public/content/translations/zh-tw/developers/docs/blocks/index.md
@@ -6,25 +6,26 @@ lang: zh-tw
區塊為區塊鏈上擁有前一個區塊之雜湊值的交易批次。 透過這種方式,區域連結起來形成區塊鏈,因為雜湊值是透過加密方式從區塊資料中衍生得來的。 這樣就防止了假造,因為對歷史記錄中的任何區塊進行一處變更將會使其後的所有區塊無效,後面的所有雜湊值都會改變,並且所有運行區塊鏈的人都會注意到。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-區塊是一個非常簡單易懂的主題。 為了讓你更容易理解本頁,建議你先閱讀[帳戶](/developers/docs/accounts/)、[交易](/developers/docs/transactions/)及我們的[以太坊介紹](/developers/docs/intro-to-ethereum/)。
+區塊是一個非常簡單易懂的主題。 但為協助您更瞭解此頁面,我們建議您先閱讀[帳戶](/developers/docs/accounts/)、[交易](/developers/docs/transactions/),以及我們的[以太坊簡介](/developers/docs/intro-to-ethereum/)。
## 為何需要區塊? {#why-blocks}
為確保所有以太坊網路參與者擁有同步狀態並一致同意明確的交易歷史記錄,我們將交易分批打包成區塊。 此代表數十個(或數百個)交易將同時被提交、同意及同步。
- _此圖源於[以太坊EVM圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
透過將交易提交間隔分開,所有網路參與者能有足夠時間來達成共識:即便每秒有大量交易請求提出,但在以太坊上,僅以大約 12 秒的時間建立並提交一次區塊。
-## 區塊如何運作? {#how-blocks-work}
+## 區塊的運作方式 {#how-blocks-work}
為了保持交易歷史記錄,區塊嚴格按照順序排列(新建立區塊包含父區塊之參照),而區塊內的交易也是嚴格按照順序排列。 除極個別情形外,在任何給定時間點,所有網路參與者都一致同意區塊的準確數量及歷史記錄,並致力於將當前的即時交易請求批次打包到下一個區塊中。
當隨機挑選的驗證者在網路上生成一個區塊後,區塊將被廣播至全網路;所有節點將此新區塊添加於它們的區塊鏈尾端,接著,挑選一個新的驗證者來產生下一個區塊。 目前區塊生成、提交/共識流程是由以太坊之「權益證明」協議規定的。
-## 權益證明協議 {#proof-of-work-protocol}
+## 權益證明協議 {#proof-of-stake-protocol}
權益證明指的是:
@@ -33,30 +34,30 @@ lang: zh-tw
- 其他驗證者接到此新區塊後,重新執行這些交易,以確保他們同意新提交的全域狀態變更。 如果該區塊是有效的,他們將其加入自己的資料庫。
- 如果驗證者在同一時隙接到兩個衝突的區塊,他們會透過分叉選擇演算法選擇有最多質押以太幣支援的區塊。
-[更多詳情關於質押證明(PoS)](/developers/docs/consensus-mechanisms/pos)
+[更多關於權益證明的資訊](/developers/docs/consensus-mechanisms/pos)
## 區塊中有什麼? {#block-anatomy}
區塊內有很多資訊。 在最高層級,區塊包含以下欄位:
| 欄位 | 描述 |
-|:---------------- |:-------------- |
+| :--------------- | :------------- |
| `時隙` | 區塊所屬的時隙 |
| `proposer_index` | 提出區塊的驗證者的識別碼 |
| `parent_root` | 前一個區塊的雜湊值 |
| `state_root` | 狀態物件的根雜湊值 |
-| `主旨` | 包含多個欄位的物件,定義如下 |
+| `內文` | 包含多個欄位的物件,定義如下 |
-區塊的 `body` 包含以下幾個欄位:
+區塊 `body` 本身包含數個欄位:
| 欄位 | 描述 |
-|:-------------------- |:-------------- |
+| :------------------- | :------------- |
| `randao_reveal` | 用於選擇下一個區塊提出者的值 |
| `eth1_data` | 關於存款合約的資訊 |
-| `塗鴉` | 用於標記區塊的任意資料 |
+| `graffiti` | 用於標記區塊的任意資料 |
| `proposer_slashings` | 將被罰沒的驗證者清單 |
| `attester_slashings` | 將被罰沒的證明者清單 |
-| `證明` | 支持當前區塊的證明清單 |
+| `證明` | 針對先前時隙所做證明的清單 |
| `存款` | 存款合約的新增存款清單 |
| `voluntary_exits` | 離開網路的驗證者清單 |
| `sync_aggregate` | 服務輕量用端的驗證者子集 |
@@ -64,29 +65,29 @@ lang: zh-tw
`attestations` 欄位包含區塊中所有證明的清單。 每個證明都有自己的資料類型並包含一些資料。 每個證明包含:
-| 欄位 | 描述 |
-|:------------------ |:------------ |
-| `aggregation_bits` | 參與過此證明的驗證者清單 |
-| `數據資料` | 包含多個子欄位的容器 |
-| `signature` | 所有證明驗證者的聚合簽名 |
+| 欄位 | 描述 |
+| :----------------- | :--------------------- |
+| `aggregation_bits` | 參與過此證明的驗證者清單 |
+| `資料` | 包含多個子欄位的容器 |
+| `簽名` | 一組驗證者針對 `data` 部分的匯總簽章 |
-`attestation` 中的 `data` 欄位包含:
+`attestation` 中的 `data` 欄位包含以下內容:
-| 欄位 | 描述 |
-|:------------------- |:--------------- |
-| `時隙` | 與證明相關的時隙 |
-| `索引` | 證明驗證者的索引 |
-| `beacon_block_root` | 包含此物件的信標區塊的根雜湊值 |
-| `來源` | 最後一個合法檢查點 |
-| `target` | 最新時期的邊界區塊 |
+| 欄位 | 描述 |
+| :------------------ | :------------ |
+| `時隙` | 與證明相關的時隙 |
+| `索引` | 證明驗證者的索引 |
+| `beacon_block_root` | 被視為鏈頭的信標區塊根哈希 |
+| `來源` | 最後一個合法檢查點 |
+| `target` | 最新時期的邊界區塊 |
-執行 `execution_payload` 中的交易會更新全域狀態。 所有用戶端都重新執行 `execution_payload` 中的交易,以確保新的狀態與新區塊中 `state_root` 欄位中的狀態相符。 這就是用戶端辨別新區塊是否有效並可以安全添加至其區塊鏈中的方式。 `execution payload` 自身是一個有許多欄位的物件。 還有一個 `execution_payload_header` 欄位,其中包含了關於執行資料的重要摘要資訊。 這些資料結構組織方式如下:
+執行 `execution_payload` 中的交易會更新全域狀態。 所有用戶端都會重新執行 `execution_payload` 中的交易,以確保新的狀態與新區塊 `state_root` 欄位中的狀態相符。 這就是用戶端辨別新區塊是否有效並可以安全添加至其區塊鏈中的方式。 `execution payload` 本身是具有數個欄位的物件。 此外,還有一個 `execution_payload_header`,其中包含關於執行資料的重要摘要資訊。 這些資料結構組織方式如下:
-`xecution_payload_header` 包含以下欄位:
+`execution_payload_header` 包含以下欄位:
| 欄位 | 描述 |
-|:------------------- |:-------------------- |
-| `家長_雜湊值` | 父區塊的雜湊值 |
+| :------------------ | :------------------- |
+| `parent_hash` | 父區塊的雜湊值 |
| `fee_recipient` | 用於支付交易費的帳戶地址 |
| `state_root` | 在應用此區塊中的變更後全域狀態的根雜湊值 |
| `receipts_root` | 交易收據樹的雜湊值 |
@@ -95,18 +96,18 @@ lang: zh-tw
| `block_number` | 目前區塊號碼 |
| `gas_limit` | 此區塊允許的最高燃料用量 |
| `gas_used` | 此區塊實際消耗的燃料用量 |
-| `時間戳` | 區塊時間 |
+| `timestamp` | 區塊時間 |
| `extra_data` | 原始字節位元組格式的任意額外資料 |
| `base_fee_per_gas` | 基本費用的值 |
| `block_hash` | 執行區塊的雜湊值 |
| `transactions_root` | 有效負載中交易的根雜湊值 |
| `withdrawal_root` | 有效負載中提款的根雜湊值 |
-`execution_payload` 自身包含了以下欄位(請注意,這些欄位與標頭相同,只是它不包含交易的根雜湊值,而是包含實際的交易清單和提款資訊):
+`execution_payload` 本身包含以下內容 (請注意,這與標頭相同,只不過它包含的是實際的交易清單和提款資訊,而非交易的根哈希):
| 欄位 | 描述 |
-|:------------------ |:-------------------- |
-| `家長_雜湊值` | 父區塊的雜湊值 |
+| :----------------- | :------------------- |
+| `parent_hash` | 父區塊的雜湊值 |
| `fee_recipient` | 用於支付交易費的帳戶地址 |
| `state_root` | 在應用此區塊中的變更後全域狀態的根雜湊值 |
| `receipts_root` | 交易收據樹的雜湊值 |
@@ -115,18 +116,18 @@ lang: zh-tw
| `block_number` | 目前區塊號碼 |
| `gas_limit` | 此區塊允許的最高燃料用量 |
| `gas_used` | 此區塊實際消耗的燃料用量 |
-| `時間戳` | 區塊時間 |
+| `timestamp` | 區塊時間 |
| `extra_data` | 原始字節位元組格式的任意額外資料 |
| `base_fee_per_gas` | 基本費用的值 |
| `block_hash` | 執行區塊的雜湊值 |
-| `交易(transactions)` | 要執行交易的清單 |
+| `交易` | 要執行交易的清單 |
| `提款` | 提款物件清單 |
-`withdrawals` 清單包含 `withdrawals` 物件,具下列結構:
+`withdrawals` 清單包含依下列方式建構的 `withdrawal` 物件:
| 欄位 | 描述 |
-|:---------------- |:-------- |
-| `address` | 已提款的帳戶地址 |
+| :--------------- | :------- |
+| `地址` | 已提款的帳戶地址 |
| `amount` | 提款金額 |
| `索引` | 提款索引值 |
| `validatorIndex` | 驗證者索引值 |
@@ -135,18 +136,18 @@ lang: zh-tw
區塊時間指的是分隔區塊的時間。 在以太坊上,時間被分割成 12 秒的單位,稱為「時隙」。 在每個時隙中,都會選擇一個驗證者來提交區塊。 假設所有驗證者都在線且功能完整,那每個時隙中都會有一個區塊,表示區塊時間為 12 秒。 然而,偶爾,當被要求提交區塊時驗證者可能下線,這表示時隙有時候會是空白的。
-這種實作與基於工作量證明的系統不同,在工作量證明系統中,區塊時間是機率性的,並根據協議的目標挖礦難度調整。 以太坊的[平均區塊時間](https://etherscan.io/chart/blocktime)就是個完美的範例,可以透過一致性的 12 秒區塊時間清楚地推斷出,已經由工作量證明過渡到權益證明了。
+這種實作與基於工作量證明的系統不同,在工作量證明系統中,區塊時間是機率性的,並根據協議的目標挖礦難度調整。 以太坊的[平均區塊時間](https://etherscan.io/chart/blocktime)就是一個很好的例子,根據新的 12 秒區塊時間的一致性,可以清楚地推斷出從工作量證明到權益證明的轉換。
## 區塊大小 {#block-size}
-最後一個重要事項:區塊本身具大小限制。 每個區塊具 35M 單位燃料用量之目標大小,但區塊大小將跟隨網路需求增減,最大可達到 60M 燃料用量的區塊大小限制(目標區塊大小之兩倍)。 區塊的燃料限制可以比前一個區塊的燃料限制上調或下調 1/1024。 因此,驗證者可以透過共識來改變區塊的燃料限制。 區塊中所有交易消耗的總燃料用量須少於區塊燃料限制。 這一點非常重要,因其確保區塊不能成為任意大小。 若區塊可以任意大,由於空間及速度方面的要求,那些效能一般的全節點可能逐漸跟不上網路。 區塊愈大,在下一個時隙中及時處理它們所需的算力就愈多。 這是一種中心化力量,可以透過限制區塊大小來抵制。
+最後一個重要事項:區塊本身具大小限制。 每個區塊的目標大小為 3,000 萬 gas,但區塊大小會根據網路需求增減,直到 6,000 萬 gas 的區塊上限 (目標區塊大小的 2 倍)。 區塊的燃料限制可以比前一個區塊的燃料限制上調或下調 1/1024。 因此,驗證者可以透過共識來改變區塊的燃料限制。 區塊中所有交易消耗的總燃料用量須少於區塊燃料限制。 這一點非常重要,因其確保區塊不能成為任意大小。 若區塊可以任意大,由於空間及速度方面的要求,那些效能一般的全節點可能逐漸跟不上網路。 區塊愈大,在下一個時隙中及時處理它們所需的算力就愈多。 這是一種中心化力量,可以透過限制區塊大小來抵制。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
- [交易](/developers/docs/transactions/)
-- [燃料](/developers/docs/gas/)
-- [權益證明(PoS)](/developers/docs/consensus-mechanisms/pos)
+- [Gas](/developers/docs/gas/)
+- [權益證明](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/zh-tw/developers/docs/bridges/index.md b/public/content/translations/zh-tw/developers/docs/bridges/index.md
new file mode 100644
index 00000000000..1dac724f30f
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/bridges/index.md
@@ -0,0 +1,138 @@
+---
+title: 跨鏈橋
+description: 給開發者的跨鏈橋概觀
+lang: zh-tw
+---
+
+隨著 Layer 1 區塊鏈與 Layer 2 [擴容](/developers/docs/scaling/) 解決方案的激增,加上愈來愈多去中心化應用程式走向跨鏈,跨鏈通訊與資產移動的需求,已成為網路基礎設施中不可或缺的一環。 存在不同類型的跨鏈橋就是為了幫助解決這種需求。
+
+## 跨鏈橋的需求 {#need-for-bridges}
+
+跨鏈橋是一條負責在不同區塊鏈之間傳遞「訊息」的橋。 它連結不同的區塊鏈,幫助不同區塊鏈上的數位資產與資料進行互動。
+
+每一個區塊鏈的運行都是各自獨立的,有其自身的規則、共識機制、原生代幣以及部署其上的智慧型合約。這意味著在自身的設計上每一個區塊鏈無法將內部的數位資產或儲存資料跨鏈轉移到另一個區塊鏈上。 儘管一個區塊鏈可以不斷發展並豐富自身內部的生態系,它始終缺乏連結不同區塊鏈、跨鏈共同運作的能力。
+
+跨鏈橋有助於打破這些藩籬,整合各自孤立的區塊鏈生態系為一體。 它們在區塊鏈之間建立傳輸路徑,代幣、訊息、任意資料,甚至[智能合約](/developers/docs/smart-contracts/)呼叫都可以從一條鏈轉移到另一條鏈。
+
+## 跨鏈橋的優點 {#benefits-of-bridges}
+
+區塊鏈橋最重要的好處是允許不同的區塊鏈進行資料交換與跨鏈資產的轉移。
+
+想像每一個區塊鏈都是一塊被海洋分隔開的大陸,不同的大陸有各自不同的資源,如果能將這些大陸的優勢結合起來,就可以創造一個繁榮的生態圈。同樣地,每一個區塊鏈都有各自的優勢與限制、在體系與應用程式的建構上都有其獨特的取捨(如重視速度、吞吐量、或安全成本等)。 跨鏈橋也同樣能將不同區塊鏈的優勢整合起來,幫助彼此有效運用各自的優勢,打造一個繁榮的生態圈。
+
+對於開發者,鏈橋可以實現以下功能:
+
+- 跨鏈傳輸任何資料、資訊和資產。
+- 解鎖協議的新功能和應用場景,因為鏈橋擴展了協議可以提供的設計空間。 例如,最初部署在以太坊主網路上用於提供流動性礦池的協議,可以為所有相容於以太坊虛擬機的鏈提供流動資金池。
+- 可以利用不同區塊鏈的優勢的機會。 例如,開發者可以透過將去中心化應用程式部署在多個磁碟區上來享受不同二層網路解決方案帶來的較低費用,而側鍊和使用者可以在它們之間建立鏈橋。
+- 不同區塊鏈生態系統的開發者之間相互協作,建構新產品。
+- 吸引來自不同生態系統的使用者和社群使用他們的去中心化應用程式。
+
+## 跨鏈橋如何運作? {#how-do-bridges-work}
+
+雖然[跨鏈橋的設計類型](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/)有很多種,但其中有三種促進跨鏈資產轉移的方式特別突出:
+
+- **鎖定與鑄造 –** 在來源鏈鎖定資產,並在目標鏈鑄造資產。
+- **銷毀與鑄造 –** 在來源鏈銷毀資產,並在目標鏈鑄造資產。
+- **原子交換 –** 與另一方將來源鏈上的資產交換為目標鏈上的資產。
+
+## 跨鏈橋類型 {#bridge-types}
+
+鏈橋通常可以分為以下幾類之一:
+
+- **原生跨鏈橋 –** 這類跨鏈橋通常是為了引導特定區塊鏈上的流動性而建立,讓使用者可以更輕易地將資金轉移至生態系統。 例如,[Arbitrum 跨鏈橋](https://bridge.arbitrum.io/)的建立,是為了讓使用者可以便利地從以太坊主網跨鏈至 Arbitrum。 其他類似的跨鏈橋包括 Polygon PoS 跨鏈橋、[Optimism Gateway](https://app.optimism.io/bridge) 等等。
+- **基於驗證者或預言機的跨鏈橋 –** 這類跨鏈橋依賴外部驗證者集合或預言機,來驗證跨鏈轉移。 例如:Multichain 與 Across。
+- **通用訊息傳遞跨鏈橋 –** 這類跨鏈橋可以跨鏈轉移資產、訊息與任意資料。 舉例:Axelar, LayerZero 和 Nomad.
+- **流動性網路 –** 這類跨鏈橋主要專注於透過原子交換,將資產從一條鏈轉移到另一條鏈。 一般來講,它們不支援跨鏈訊息傳遞。 例如:Connext 與 Hop。
+
+## 需考量的權衡取捨 {#trade-offs}
+
+沒有完美的鏈橋解決方案。 有的只是為了實現目的而進行的權衡利弊。 開發者和使用者可以根據以下因素評估鏈橋:
+
+- **安全性 –** 由誰來驗證系統? 通常,由外部驗證者保護的鏈橋不如由區塊鏈驗證者在本地保護的鏈橋安全。
+- **便利性 –** 完成一筆交易需要多長時間?使用者需要簽署多少筆交易? 對於開發者來說,整合一個鏈橋需要多長時間,這個過程有多複雜?
+- **連接性 –** 跨鏈橋可以連接哪些不同的目標鏈(例如 rollup、側鏈、其他 Layer 1 區塊鏈等)?整合一條新的區塊鏈有多困難?
+- **傳遞更複雜資料的能力 –** 跨鏈橋能否跨鏈傳輸訊息和更複雜的任意資料,或者它只支援跨鏈資產轉移?
+- **成本效益 –** 透過跨鏈橋跨鏈轉移資產的成本是多少? 通常情況下,鏈橋收取固定或變動的費用,具體取決於燃料成本和特定路線的流動性。 根據確保鏈橋安全所需的資本來評估鏈橋的成本效益也是至關重要的。
+
+在較高層面上,鏈橋可分為需要信任鏈橋和去信任鏈橋。
+
+- **需信任 –** 需信任的跨鏈橋由外部驗證。 它們使用一組外部驗證者(具有多重簽章的聯盟、多方運算系統、預言機網路)跨鏈發送資料。 因此,它們可以提供出色的連通性,並完全支援跨鏈通用資訊傳遞。 在速度和成本效益方面它們通常也表現良好。 但這些是以安全性為代價的,因為使用者必須依賴鏈橋的安全性。
+- **免信任 –** 這類跨鏈橋依賴其所連接的區塊鏈及驗證者來轉移訊息和代幣。 它們是 “去信任” 的,因為它們沒有增加新的信任假設(區塊鏈除外)。 因此,我們認為去信任鏈橋比可信任鏈橋更安全。
+
+為了根據其他因素評估去信任鏈橋,我們須將其分為通用資訊傳遞鏈橋和流動性網路。
+
+- **通用訊息傳遞跨鏈橋 –** 這類跨鏈橋在安全性以及跨鏈傳輸更複雜資料的能力方面表現卓越。 通常,它們還具有良好的成本效益。 然而,這些優點通常以輕客戶端鏈橋(例如 IBC)的連通性以及使用欺詐證明的樂觀鏈橋(例如 Nomad)的速度劣勢作為代價。
+- **流動性網路 –** 這類跨鏈橋使用原子交換來轉移資產,並且是本地驗證系統(亦即,它們使用底層區塊鏈的驗證者來驗證交易)。 因此,它們在安全性和速度方面表現出色。 此外,流動性網路具有良好的成本效益和良好的連結性。 然而,最大的折衷之處是它們無法傳遞更複雜的資料 — 因為它們不支援跨鏈訊息傳遞。
+
+## 跨鏈橋的風險 {#risk-with-bridges}
+
+跨鏈橋佔了 [DeFi 三大駭客攻擊](https://rekt.news/leaderboard/)中的前三名,而且仍處於早期發展階段。 使用任何鏈橋都有以下風險:
+
+- **智能合約風險 –** 雖然許多跨鏈橋已成功通過審核,但智能合約中的一個瑕疵就足以讓資產暴露在駭客攻擊之下(例如:[Solana 的 Wormhole 跨鏈橋](https://rekt.news/wormhole-rekt/))。
+- **系統性金融風險** – 許多跨鏈橋使用封裝資產,在新鏈上鑄造原始資產的標準版本。 這使生態系統面臨系統性風險,正如我們所看到的那樣,包裝代幣遭到利用。
+- **交易對手風險 –** 有些跨鏈橋採用需信任的設計,這要求使用者必須依賴「驗證者不會串通竊取使用者資金」的假設。 使用者需要信任這些第三方參與者,這使他們面臨一些風險,例如跑路、審查和其他惡意活動。
+- **待解決問題 –** 鑑於跨鏈橋仍處於早期發展階段,還有許多未解的問題,關於跨鏈橋在不同市場條件下的表現,例如在網路壅塞時,或在發生網路層級攻擊或狀態回滾等無法預料的事件時。 這種不確定性帶來了一定的風險,且風險程度目前仍未知。
+
+## 去中心化應用程式如何使用鏈橋? {#how-can-dapps-use-bridges}
+
+以下介紹一些實際應用,在這些應用中,開發者可以考慮鏈橋並讓他們的去中心化應用程式跨鏈:
+
+### 整合跨鏈橋 {#integrating-bridges}
+
+對於開發者來說,有很多方法可以添加對鏈橋的支援:
+
+1. **建立自己的跨鏈橋 –** 建立一個安全可靠的跨鏈橋並不容易,尤其當你選擇信任最小化的路徑時。 此外,還需要與可擴展性和互通性研究相關的多年經驗和技術專長。 另外,還需要一支親力親為的團隊來維護鏈橋,並吸引足夠的流動性使其可行。
+
+2. **向使用者展示多種跨鏈橋選項 –** 許多[去中心化應用程式](/developers/docs/dapps/)都要求使用者擁有其原生代幣才能與之互動。 為了使用戶能夠訪問他們的代幣,去中心化應用程式在其網站上提供了不同的鏈橋選項。 然而,這種方法是權宜之計,因為它使用戶離開去中心化應用程式介面但仍需要用戶與其他去中心化應用程式和鏈橋互動。 這是一種繁瑣的上手體驗,會增加出錯的範圍。
+
+3. **整合一座跨鏈橋 –** 這個解決方案不需要去中心化應用程式將使用者送到外部跨鏈橋和 DEX 介面。 這讓去中心化應用程式能夠改善用戶的上手體驗。 然而,這種方法有其局限性:
+
+ - 鏈橋的評估和維護既困難又耗時。
+ - 選用一個鏈橋將造成單點故障和依賴性。
+ - 去中心化應用程式受限於鏈橋的能力。
+ - 光有鏈橋可能還不夠。 去中心化應用程式可能需要去中心化交易所提供更多功能,例如跨鏈交換。
+
+4. **整合多座跨鏈橋 –** 這個解決方案解決了許多與整合單一跨鏈橋相關的問題。 然而,它也有局限性,因為整合多個鏈橋會消耗資源,並為開發者帶來技術和通訊開銷 — 這是加密貨幣領域最稀缺的資源。
+
+5. **整合跨鏈橋聚合器 –** 去中心化應用程式的另一個選項是整合跨鏈橋聚合解決方案,讓它們可以存取多座跨鏈橋。 鏈橋聚合器繼承了所有鏈橋的優點,因此不受任何單一鏈橋能力的限制。 值得注意的是,鏈橋聚合器通常維護鏈橋集成,這使去中心化應用程式避免了管控鏈橋集成技術和操作方面的麻煩。
+
+儘管如此,鏈橋聚合器也有其限制。 比如說,雖然它們可以提供較多的鏈橋選擇,但除了聚合器平台上提供的鏈橋外,市場上通常還有更多的鏈橋。 此外,像鏈橋一樣,鏈橋聚合器也面臨智慧合約和技術風險(更多的智慧合約 = 更多的風險)。
+
+如果去中心化應用程式規劃整合鏈橋或聚合器,那麼根據整合的深度會有不同的選擇。 例如,如果只是進行前端整合以改善用戶上手體驗,去中心化應用程式將整合小組件。 然而,如果整合是為了探索更深層的跨鏈策略,如質押、流動性礦池等,去中心化應用程式就整合軟體開發工具包或應用程式介面。
+
+### 在多個鏈上部署去中心化應用程式 {#deploying-a-dapp-on-multiple-chains}
+
+若要在多條鏈上部署去中心化應用程式,開發者可以使用 [Alchemy](https://www.alchemy.com/)、[Hardhat](https://hardhat.org/)、[Moralis](https://moralis.io/) 等開發平台。 這些平台通常提供可組合的插件,能夠支援去中心化應用程式跨鏈。 例如,開發者可以使用 [hardhat-deploy 外掛程式](https://github.com/wighawag/hardhat-deploy)提供的確定性部署代理。
+
+#### 範例:
+
+- [如何建立跨鏈去中心化應用程式](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [建立跨鏈 NFT 市場](https://youtu.be/WZWCzsB1xUE)
+- [Moralis:建立跨鏈 NFT 去中心化應用程式](https://www.youtube.com/watch?v=ehv70kE1QYo)
+
+### 監控跨鏈合約活動 {#monitoring-contract-activity-across-chains}
+
+要監控跨鏈合約活動,開發者可以使用子圖和 Tenderly 等開發者平台即時觀察智能合約。 這類平台也提供工具,為跨鏈活動提供更強大的資料監控功能,例如檢查[合約發出的事件](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events)等。
+
+#### 工具
+
+- [The Graph](https://thegraph.com/en/)
+- [Tenderly](https://tenderly.co/)
+
+## 延伸閱讀 {#further-reading}
+
+- [區塊鏈跨鏈橋](/bridges/) – ethereum.org
+- [L2Beat 跨鏈橋風險框架](https://l2beat.com/bridges/summary)
+- [區塊鏈跨鏈橋:建構加密網路的網路](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 2021 年 9 月 8 日 – Dmitriy Berenzon
+- [互操作性三難困境](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 2021 年 10 月 1 日 – Arjun Bhuptani
+- [叢集:需信任與信任最小化跨鏈橋如何塑造多鏈格局](https://blog.celestia.org/clusters/) - 2021 年 10 月 4 日 – Mustafa Al-Bassam
+- [LI.FI:有了跨鏈橋,信任就成了光譜](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 2022 年 4 月 28 日 – Arjun Chand
+- [Rollup 互操作性解決方案的現狀](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 2024 年 6 月 20 日 – Alex Hook
+- [利用共享安全實現安全的跨鏈互操作性:Lagrange 狀態委員會及其他](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 2024 年 6 月 12 日 – Emmanuel Awosika
+
+此外,以下是 [James Prestwich](https://twitter.com/_prestwich) 的一些精闢演講,有助於加深對跨鏈橋的理解:
+
+- [建立跨鏈橋,而非圍牆花園](https://youtu.be/ZQJWMiX4hT0)
+- [剖析跨鏈橋](https://youtu.be/b0mC-ZqN8Oo)
+- [跨鏈橋為何在燃燒](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/index.md
index 832a6b165cf..1b9354b8db2 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/index.md
@@ -4,11 +4,11 @@ description: 解釋分佈式系統中的共識協定及其於以太坊中扮演
lang: zh-tw
---
-「共識機制」一詞常泛指「權益證明」、「工作量證明」或「權威證明」協定。 然而,這些證明方式僅為共識機制當中用來抵禦[女巫攻擊](/glossary/#sybil-attack)的組成部分。 共識機制是由一整套想法、協定和激勵構成的體系,使得一系列分佈式節點能夠就區塊鏈狀態達成一致。
+「共識機制」一詞常泛指「權益證明」、「工作量證明」或「權威證明」協定。 然而,這些只是共識機制中,用來抵禦[女巫攻擊](/glossary/#sybil-attack)的元件。 共識機制是由一整套想法、協定和激勵構成的體系,使得一系列分佈式節點能夠就區塊鏈狀態達成一致。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了加深對本頁內容的理解,我們推薦你先仔細閱讀我們的[以太坊介紹](/developers/docs/intro-to-ethereum/)。
+為能更了解本頁面,我們建議您先閱讀我們的[以太坊簡介](/developers/docs/intro-to-ethereum/)。
## 何為共識? {#what-is-consensus}
@@ -28,11 +28,11 @@ lang: zh-tw
這些部分共同組成了共識機制。
-## 共識機制種類 {#types-of-consensus-mechanisms}
+## 共識機制的類型 {#types-of-consensus-mechanisms}
### 基於工作量證明 {#proof-of-work}
-和比特幣類似,以太坊也曾經使用基於**工作量證明 (PoW)** 的共識協定。
+和比特幣一樣,以太坊曾經也使用基於**工作量證明 (PoW)** 的共識協定。
#### 區塊建立 {#pow-block-creation}
@@ -46,9 +46,9 @@ lang: zh-tw
### 基於權益證明 {#proof-of-stake}
-以太坊目前使用基於**權益證明 (PoS)** 的共識協定。
+以太坊現在使用基於**權益證明 (PoS)** 的共識協定。
-#### 區塊生成 {#pos-block-creation}
+#### 區塊建立 {#pos-block-creation}
驗證者建立區塊。 每個時隙都會隨機選擇一個驗證者成為區塊提議者。 區塊提議者的共識用戶端請求配對的執行用戶端對交易打包,作為「執行有效負載」。 然後它們將其包裝成共識資料以形成區塊,再把這個區塊傳送給以太坊網路上的其他節點。 這樣的區塊產生會得到以太幣獎勵。 在極少數情況下,當一個時隙中存在多個可能的區塊,或節點在不同時間收到區塊,分叉選擇演算法就會選擇使形成的鏈具有最大證明權重的區塊(證明權重是指提供證明的驗證者數量,並按驗證者質押的以太幣餘額進行調整)。
@@ -58,35 +58,35 @@ lang: zh-tw
更多關於[權益證明](/developers/docs/consensus-mechanisms/pos/)的資訊
-### 視覺導覽 {#types-of-consensus-video}
+### 視覺化指南 {#types-of-consensus-video}
觀看以太坊上所用不同類型之共識機制的更多資訊:
-### 抵禦女巫攻擊與區塊鏈選擇 {#sybil-chain}
+### 抗女巫攻擊與鏈選擇 {#sybil-chain}
僅僅工作量證明和權益證明還不能構成共識協定,但為了簡便起見,通常將它們稱為共識協定。 它們實際是抵禦女巫攻擊機制及區塊鏈創作者選擇程式;提供了一種方法來決定誰能成為最新區塊創作者。 另一個重要組成部分是鏈選擇(又稱分叉選擇)演算法,在同一位置有多個區塊的情況下,它讓節點可以在鏈頭部選擇一個正確的區塊。
-**抵禦女巫攻擊**衡量協定有效對抗女巫攻擊的能力。 抵禦此類攻擊對於去中心化區塊鏈至關緊要,可使所有礦工與驗證者能夠基於其投入的資源平等地獲得獎勵。 工作量證明及權益證明透過讓使用者耗費大量能源或投入大量抵押,來防範此類攻擊。 此類保護會對女巫攻擊形成經濟上的威懾。
+**抗女巫攻擊**能力衡量的是一個協定對抗女巫攻擊的表現。 抵禦此類攻擊對於去中心化區塊鏈至關緊要,可使所有礦工與驗證者能夠基於其投入的資源平等地獲得獎勵。 工作量證明及權益證明透過讓使用者耗費大量能源或投入大量抵押,來防範此類攻擊。 此類保護會對女巫攻擊形成經濟上的威懾。
-**區塊鏈選擇規則**被用來決定哪條鏈為「正確」的鏈。 比特幣使用「最長鏈」規則。這意味著,任何最長的區塊鏈,都會被其他節點接受並與之合作。 對於工作量證明區塊鏈,最長鏈取決於該鏈所累積之工作量證明總難度。 以太坊也曾經用過最長鏈規則;但現在以太坊在權益證明機制下運作,採用了經過更新的分叉選擇演算法來衡量鏈的「權重」。 權重是累積的驗證者投票數累積總和,並以驗證者質押的以太幣餘額進行加權。
+**鏈選擇規則**是用來決定哪一條鏈是「正確」的鏈。 比特幣使用「最長鏈」規則。這意味著,任何最長的區塊鏈,都會被其他節點接受並與之合作。 對於工作量證明區塊鏈,最長鏈取決於該鏈所累積之工作量證明總難度。 以太坊也曾經用過最長鏈規則;但現在以太坊在權益證明機制下運作,採用了經過更新的分叉選擇演算法來衡量鏈的「權重」。 權重是累積的驗證者投票數累積總和,並以驗證者質押的以太幣餘額進行加權。
-以太坊使用一種被稱為 [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) 的共識機制,它結合了 [Casper 友善最終確定性組件權益證明](https://arxiv.org/abs/1710.09437)和[最貪婪最重觀測子樹 (GHOST) 分叉選擇規則](https://arxiv.org/abs/2003.03052)。
+以太坊使用一種名為 [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) 的共識機制,它將 [Casper FFG 權益證明](https://arxiv.org/abs/1710.09437)與 [GHOST 分叉選擇規則](https://arxiv.org/abs/2003.03052)結合起來。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [何為區塊鏈共識演算法?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
-- [何為 Nakamoto 共識? 完整初學者指南](https://blockonomi.com/nakamoto-consensus/)
-- [Casper 機制如何運作?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
-- [關於權益證明區塊鏈的安全性及效能](https://eprint.iacr.org/2016/555.pdf)
-- [拜占庭問題](https://en.wikipedia.org/wiki/Byzantine_fault)
+- [什麼是區塊鏈共識演算法?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
+- [什麼是中本聰共識? 完整新手指南](https://blockonomi.com/nakamoto-consensus/)
+- [Casper 如何運作?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
+- [關於工作量證明區塊鏈的安全性與效能](https://eprint.iacr.org/2016/555.pdf)
+- [拜占庭故障](https://en.wikipedia.org/wiki/Byzantine_fault)
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
- [工作量證明](/developers/docs/consensus-mechanisms/pow/)
- [挖礦](/developers/docs/consensus-mechanisms/pow/mining/)
-- [持有量證明(又稱:權益證明)](/developers/docs/consensus-mechanisms/pos/)
+- [權益證明](/developers/docs/consensus-mechanisms/pos/)
- [權威證明](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/poa/index.md
index 16539d2a394..ec1f45b46e4 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/poa/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/poa/index.md
@@ -77,3 +77,4 @@ lang: zh-tw
- [工作量證明](/developers/docs/consensus-mechanisms/pow/)
- [權益證明](/developers/docs/consensus-mechanisms/pos/)
+
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
index 634acb27ed9..308acec1d07 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
@@ -4,37 +4,40 @@ description: 瞭解以太坊權益證明的已知攻擊媒介,以及如何進
lang: zh-tw
---
-小偷和破壞者不斷尋找機會攻擊以太坊的用戶端軟體。 本頁概述了以太坊共識層的已知攻擊媒介,以及如何防禦這些攻擊。 本頁上的資訊改編自一個[更長格式的版本](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)。
+小偷和破壞者不斷尋找機會攻擊以太坊的用戶端軟體。 本頁概述了以太坊共識層的已知攻擊媒介,以及如何防禦這些攻擊。 此頁面上的信息改編自一個[加長版本](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)。
-## 先備知識 {#prerequisites}
+## 先決條件 {#prerequisites}
-需要瞭解一些關於[權益證明](/developers/docs/consensus-mechanisms/pos/)的基本知識。 此外,對以太坊的[激勵層](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)和分叉選擇演算法 [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) 有基本瞭解,也會有所助益。
+需要了解一些[權益證明](/developers/docs/consensus-mechanisms/pos/)的基礎知識。 另外,如果對以太坊的[激勵層](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)和分叉選擇演算法 [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) 有基本的了解,也會有所幫助。
## 攻擊者的企圖 {#what-do-attackers-want}
-一個常見的誤解是,成功的攻擊者可以產生新的以太幣,或者從任意帳戶中取走以太幣。 由於所有交易都由網路上的所有執行用戶端執行,所以這兩種情況都是不可能的。 交易必須滿足基本的有效性條件(例如,交易由發送者的私密金鑰簽署,發送者有足夠的餘額等),否則它們將被直接還原。 攻擊者的真實目標可能有三類結果:區塊重組、雙重最終確定性或最終確定性延遲。
+一個常見的誤解是,成功的攻擊者可以產生新的以太幣,或者從任意帳戶中取走以太幣。 由於所有交易都由網路上的所有執行用戶端執行,所以這兩種情況都是不可能的。 它們必須滿足基本的有效性條件 (例如,交易由發送者的私密金鑰簽署,發送者有足夠的餘額等),否則就會直接還原。 攻擊者的真實目標可能有三類結果:區塊重組、雙重最終確定性或最終確定性延遲。
-**「區塊重組」**是將區塊重新排列成新的順序,或許在規範鏈中進行一些區塊的增減。 惡意的區塊重組可能確保納入或排除特定的區塊,允許透過預先交易和尾随交易(最大可提取价值)進行雙重支付或價值提取。 區塊重組也可以用來阻止某些交易被納入規範鏈中 - 這是一種審查形式。 區塊重組的最極端形式是「最終確定性反轉」,它會移除或替換先前已最終確定的區塊。 只有當攻擊者摧毀了總質押以太幣的 ⅓ 以上時,這才有可能 - 這一保證被稱為「經濟最終確定性」- 稍後會有詳細說明。
+**「重組」** 是將區塊重新排列成新的順序,或許在規範鏈中進行一些區塊的增減。 惡意的區塊重組可能確保納入或排除特定的區塊,允許透過預先交易和尾随交易(最大可提取价值)進行雙重支付或價值提取。 區塊重組也可以用來阻止某些交易被納入規範鏈中 - 這是一種審查形式。 區塊重組的最極端形式是「最終確定性反轉」,它會移除或替換先前已最終確定的區塊。 只有當攻擊者摧毀了總質押以太幣的 ⅓ 以上時,這才有可能 - 這一保證被稱為「經濟最終確定性」- 稍後會有詳細說明。
-**雙重最終確定性**是一種不太可能但很嚴重的狀況,其中兩個分叉能夠同時最終確定,造成鏈中的永久分裂。 對於願意以 34% 的縂質押以太幣來冒險的攻擊者來說,這在理論上是可能的。 社群將被迫在鏈下協調並就跟隨哪條鏈達成協定,這將需要社交層面的力量。
+**雙重最終確定性**是一種不太可能但很嚴重的狀況,其中兩個分叉能夠同時最終確定,造成鏈中的永久分裂。 對於願意以 34% 的縂質押以太幣來冒險的攻擊者來說,這在理論上是可能的。 社群將被迫在鏈下協調,並就要跟隨哪一條鏈達成共識,而這將需要社交層面的凝聚力。
**最終確定性延遲**攻擊會阻止網路達到最終確定鏈段的必要條件。 沒有最終確定性,就很難信任建立在以太坊之上的金融應用程式。 最終確定性延遲攻擊的目的可能僅僅是破壞以太坊,而不是直接獲利,除非攻擊者有一些策略性的短融資。
對社交層的攻擊可能旨在破壞公眾對以太坊的信任,讓以太幣貶值、減少採用,或削弱以太坊社群以增加帶外協調的難度。
-在確定對手可能為何攻擊以太坊後,以下部分將探討他們可能採用的_攻擊方法_。
+在確定對手可能為何攻擊以太坊後,以下部分將探討他們可能會 _如何_ 進行攻擊
-## 攻擊方法 {#methods-of-attack}
+## 攻擊的方式 {#methods-of-attack}
-### 0 層網路攻擊 {#layer-0}
+### 0 層攻擊 {#layer-0}
首先,那些不積極參與以太坊(透過運行用戶端軟件)的個人可以透過針對社交層(0 層網路)進行攻擊。 0 層網路是建立以太坊的基礎,因此它代表了一個潛在的攻擊面,其後果會在整個堆疊中產生波及效應。 一些例子可能包括:
- 一個虛假資訊宣傳活動可能會侵蝕社群對以太坊的開發藍圖、開發者團隊、應用程式等的信任。 然後,這可能會減少願意參與保護網路的個人數量,降低去中心化和加密經濟安全性。
+
- 針對開發者社群的有針對性的攻擊或恐嚇。 這可能導致開發者自願退出,並減慢以太坊的進展。
- 過度熱衷的監管也可以被認為是對 0 層網路的攻擊,因為它可能迅速挫傷參與和採用的積極性。
+
- 將知識淵博的惡意行為者滲透到開發者社群中,目的是透過無意義的討論、延遲關鍵決策、建立垃圾郵件等手段減緩進展。
+
- 向以太坊生態系統的關鍵參與者行賄以影響決策。
這些攻擊特別危險的原因是,在許多情況下幾乎不需要太多資本或技術知識。 0 層網路攻擊可能是加密經濟攻擊的倍增器。 例如,如果惡意的多數質押持有者實現了審查或最終確定性反轉,則破壞社交層可能導致帶外協調社群響應變得更困難。
@@ -45,17 +48,17 @@ lang: zh-tw
最後,以太坊社群保持對所有參與者開放和友好至關重要。 一個帶有門戶守衛和排外性的社群特別容易受到社交攻擊,因為容易形成「我們和他們」的敘事。 部落主義和有害的極端主義會傷害社群,削弱 0 層網路的安全性。 對以太坊網路安全具有既得利益的以太坊社群成員,應該將他們在線上和實體世界中的行為視為對以太坊 0 層網路安全的直接促進因素。
-### 攻擊協定 {#attacking-the-protocol}
+### 攻擊協議 {#attacking-the-protocol}
任何人都可以執行以太坊的用戶端軟體。 要將驗證者新增至用戶端,使用者需要將 32 個以太幣質押到存款合約中。 驗證者允許使用者透過提交和證明新區塊來積極參與以太坊網路的安全性。 現在,驗證者可以發聲,影響區塊鏈的未來內容 - 他們可以誠實行事,透過獎勵來增加他們的以太幣儲備,或者他們可以冒著失去其質押的風險,試圖操縱程序以謀取自己的利益。 一種發動攻擊的方法是累積更大比例的總質押,然後用它來在投票中超過誠實的驗證者。 攻擊者控制的質押比例越大,他們的投票權就越大,尤其是在我們稍後將探討的某些經濟里程碑上。 然而,大多數攻擊者將無法累積足夠的以太幣以此方式進行攻擊,因此他們必須使用微妙的技巧來操縱誠實的大多數人採取特定的行動。
從根本上說,所有小規模質押攻擊都是兩種驗證者不當行為的微妙變體:活動不足(未能證明/提議或者延後這樣做)或者活動過多(在一個時隙內提議/證明的次數過多)。 在最普遍的形式下,這些行動可以很容易地由分叉選擇演算法和激勵層進行處理,但也有聰明的方式可以讓攻擊者操縱系統以獲得優勢。
-### 使用少量以太幣的攻擊 {#attacks-by-small-stakeholders}
+### 使用少量以太幣 (ETH) 進行攻擊 {#attacks-by-small-stakeholders}
-#### 區塊重組 {#reorgs}
+#### 重組 {#reorgs}
-有幾篇論文解釋了在以太坊上使用僅佔總質押以太幣一小部分便實現了區塊重組或最終確定性延遲的攻擊。 這些攻擊通常依賴於攻擊者向其他驗證者隱瞞某些資訊,然後以某種微妙的方式和/或在某個適當的時刻發佈該資訊。 它們通常旨在取代規範鏈中的一些誠實區塊。 [Neuder 等人在 2020 年的研究](https://arxiv.org/pdf/2102.02247.pdf)中展示了一個攻擊驗證者如何在特定時隙 `n+1` 建立和證明一個區塊 (`B`),但未將其傳播到網路上的其他節點。 相反,他們保留該已證明的區塊,直到下一個時隙 `n+2`。 一個誠實的驗證者在時隙 `n+2` 提交了一個區塊 (`C`)。 幾乎同時,攻擊者可以發佈他們所保留的區塊 (`B`) 及為其保留的證明,並且在時隙 `n+2` 透過他們的投票證明區塊 `B` 為鏈頭,有效地否認了誠實區塊 `C` 的存在。 當誠實區塊 `D` 發佈時,分叉選擇演算法會看到建置在 `B` 之上的 `D` 比建置在 `C` 之上的 `D` 有更多權重。 因此,攻擊者成功地使用 1 個區塊的事前重組,在時隙 `n+2` 從規範鏈中移除了誠實區塊 `C`。 [擁有 34% 的質押份額的攻擊者](https://www.youtube.com/watch?v=6vzXwwk12ZE)在這次攻擊中有很大的機會成功,正如[這條注釋](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)中所解釋的。 然而,從理論上講,這種攻擊也可以使用較小的質押份額來嘗試。 [Neuder 等人在 2020 年的研究](https://arxiv.org/pdf/2102.02247.pdf)描述了這種攻擊在 30% 的質押份額下的運作,但後來證明它在[總質押份額的 2%](https://arxiv.org/pdf/2009.04987.pdf) 下可行,然後[單個驗證者](https://arxiv.org/abs/2110.10086#)使用我們將在下一節中探討的平衡技巧亦有效。
+有幾篇論文解釋了在以太坊上使用僅佔總質押以太幣一小部分便實現了區塊重組或最終確定性延遲的攻擊。 這些攻擊通常依賴於攻擊者向其他驗證者隱瞞某些資訊,然後以某種微妙的方式和/或在某個適當的時刻發佈該資訊。 它們通常旨在取代規範鏈中的一些誠實區塊。 [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) 展示了發動攻擊的驗證者如何為一個特定的時隙 `n+1` 創建和證明一個區塊 (`B`),但不讓它向網路上的其他節點傳播。 相反,他們會保留該已證明的區塊,直到下一個時隙 `n+2`。 誠實的驗證者為時隙 `n+2` 提交了一個區塊 (`C`)。 幾乎同時,攻擊者可以發佈他們所保留的區塊 (`B`) 及為其保留的證明,並且在時隙 `n+2` 透過他們的投票證明區塊 `B` 為鏈頭,有效地否認了誠實區塊 `C` 的存在。 當誠實區塊 `D` 發佈時,分叉選擇演算法會看到建置在 `B` 之上的 `D` 比建置在 `C` 之上的 `D` 有更多權重。 因此,攻擊者成功地使用單區塊事前重組,在時隙` n+2` 從規範鏈中移除了誠實區塊 `C`。 [擁有 34% 質押的攻擊者](https://www.youtube.com/watch?v=6vzXwwk12ZE)將很可能在此類攻擊中成功,如[這篇筆記](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)所解釋。 然而,從理論上講,這種攻擊也可以使用較小的質押份額來嘗試。 Neuder 等人於 2020 年的[研究](https://arxiv.org/pdf/2102.02247.pdf) 指出此攻擊在擁有 30% 權益的情況下是可行的,但後來的研究顯示,即使僅擁有[ 2% 的總權益](https://arxiv.org/pdf/2009.04987.pdf) 也能實現這種攻擊,甚至後續又發現,一個[單一驗證者](https://arxiv.org/abs/2110.10086#)也能透過平衡技術來進行這種攻擊——我們將在下一節中深入探討這些技術。

@@ -63,71 +66,72 @@ lang: zh-tw
一種更複雜的攻擊可以將誠實的驗證者集合分成擁有不同鏈頭檢視的不同群組。 這被稱為**平衡攻擊**。 攻擊者等待著提出區塊的機會,當機會到來時,他們模稜兩可地提出兩個區塊。 他們將一個區塊發送給一半的誠實驗證者集合,將另一個區塊發送給另一半。 這種模稜兩可的行為會被分叉選擇演算法偵測到,區塊提議者將被懲處並從網路中驅逐,但這兩個區塊仍然存在,並在每個分叉擁有約一半驗證者集合的證明。 同時,其餘的惡意驗證者保留他們的證明。 然後,透過在分叉選擇演算法執行時選擇性地向足夠的驗證者釋放有利於某一分叉或另一分叉的證明,他們將證明的累積權重傾向於其中一個或另一個分叉。 這種做法可以無限期地繼續下去,攻擊驗證者則在兩個分叉之間保持驗證者的平均分配。 由於兩個分叉都無法吸引到 2/3 的絕對多數,網路將無法最終確定。
-**反彈攻擊**與之類似。 攻擊驗證者同樣保留了投票。 他們不是透過釋放投票來保持兩個分叉之間的平均分配,而是在適當的時刻使用他們的投票來證明在分叉 A 和分叉 B 之間交替的檢查點。這種在兩個分叉之間翻轉的證明方式,阻止了可以在任何鏈上最終確定的被證明來源和目標檢查點對的出現,從而終止了最終確定性。
+**彈跳攻擊**與之類似。 攻擊驗證者同樣保留了投票。 他們不是透過釋放投票來保持兩個分叉之間的平均分配,而是在適當的時刻使用他們的投票來證明在分叉 A 和分叉 B 之間交替的檢查點。這種在兩個分叉之間翻轉的證明方式,阻止了可以在任何鏈上最終確定的被證明來源和目標檢查點對的出現,從而終止了最終確定性。
-反彈和平衡攻擊都依賴於攻擊者對網路上的訊息時間具有非常精細的控制,這是不太可能的。 然而,協定中內建了防禦機制,與較慢訊息相比,給予了及時訊息額外的加權。 這被稱為[提議者權重增強](https://github.com/ethereum/consensus-specs/pull/2730)。 為了防範反彈攻擊,分叉選擇演算法已經更新,使得在[每個時期的前 1/3 時隙內](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114),最新的被證明檢查點只能切換到另一個鏈的檢查點。 這個條件防止攻擊者儲存投票以便稍後部署 - 分叉選擇演算法只是在時期的前 1/3 對它選擇的檢查點保持忠誠,而在這段時間內大多數誠實的驗證者已經完成投票。
+反彈和平衡攻擊都依賴於攻擊者對網路上的訊息時間具有非常精細的控制,這是不太可能的。 然而,協定中內建了防禦機制,與較慢訊息相比,給予了及時訊息額外的加權。 這被稱爲[提交者權重增强](https://github.com/ethereum/consensus-specs/pull/2730)。 為了防禦 bouncing 攻擊,分叉選擇算法已被更新,使得最新的已認可檢查點只能在 [每個 epoch 的前三分之一 slot] (https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) 期間,才允許切換到另一條鏈上的檢查點。 這個條件防止攻擊者儲存投票以便稍後部署 - 分叉選擇演算法只是在時期的前 1/3 對它選擇的檢查點保持忠誠,而在這段時間內大多數誠實的驗證者已經完成投票。
綜合考慮,這些措施創造了這樣的情況:一個誠實的區塊提議者在時隙開始後很快就發出他們的區塊,然後有大約 1/3 個時隙(約 4 秒)的時間,新的區塊可能會導致分叉選擇演算法切換到另一個鏈。 在同樣的截止期限之後,來自緩慢驗證者的證明相較於之前到達的證明會被降低權重。 這非常有利於及時的提議者和驗證者來確定鏈頭,並大幅降低了平衡或反彈攻擊成功的可能性。
-值得注意的是,僅僅進行提議者加強只能防禦“廉價的重組攻擊”,即由持有較小質押份額的攻擊者嘗試的重組攻擊。 事實上,提議者加強本身可能會被更大的質押持有者利用。 [這篇文章的作者](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127)描述了一個持有 7% 質押份額的攻擊者如何可以戰略性地部署他們的投票,欺騙誠實的驗證者在他們的分叉上建置,將誠實的區塊重組掉。 這種攻擊是在假設極端理想的延遲條件下設計的,而這種情況非常不太可能。 對於攻擊者來說,勝算仍然非常渺茫,而更大的質押份額也意味著更多的資本風險和更強大的經濟阻力。
+值得注意的是,僅有提案者加成只能防禦「廉價重組」,即由持有少量質押的攻擊者所嘗試的重組。 事實上,提議者加強本身可能會被更大的質押持有者利用。 [這篇文章](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127)的作者描述了持有 7% 質押的攻擊者如何策略性地部署其投票,欺騙誠實驗證者在他們的分叉上建構,將誠實的區塊重組掉。 這種攻擊是在假設極端理想的延遲條件下設計的,而這種情況非常不太可能。 對於攻擊者來說,勝算仍然非常渺茫,而更大的質押份額也意味著更多的資本風險和更強大的經濟阻力。
-還提出了一種專門針對最新訊息導向 (LMD) 規則的[平衡攻擊](https://ethresear.ch/t/balancing-attack-lmd-edition/11853),儘管有提議者加強,但這種攻擊據認為仍然是可行的。 攻擊者透過模稜兩可的區塊提議設立了兩條競爭的鏈,並將每個區塊各傳播給大約一半的網路,從而在分叉之間建立起近似的平衡。 然後,串通的驗證者模稜兩可地投票,並安排時間,使得一半的網路首先收到他們對分叉 `A` 的投票,另一半首先收到他們對分叉 `B` 的投票。 由於最新訊息導向規則會丟棄每個驗證者的第二個證明,而只保留第一個證明,所以一半的網路看到對 `A` 的投票,沒有對 `B` 的投票,另一半則看到對 `B` 的投票,沒有對 `A` 的投票。 作者描述了最新訊息導向規則賦予了對手「卓越的力量」來發動平衡攻擊。
+另外也提出了一種[特別針對 LMD 規則的平衡攻擊](https://ethresear.ch/t/balancing-attack-lmd-edition/11853),據稱即使有提案者加成,這種攻擊仍然可行。 攻擊者透過模稜兩可的區塊提議設立了兩條競爭的鏈,並將每個區塊各傳播給大約一半的網路,從而在分叉之間建立起近似的平衡。 然後,串通的驗證者模稜兩可地投票,並安排時間,使得一半的網路首先收到他們對分叉 `A` 的投票,另一半首先收到他們對分叉 `B` 的投票。 由於最新訊息導向規則會丟棄每個驗證者的第二個證明,而只保留第一個證明,所以一半的網路看到對 `A` 的投票,沒有對 `B` 的投票,另一半則看到對 `B` 的投票,沒有對 `A` 的投票。 作者描述了最新訊息導向規則賦予了對手「卓越的力量」來發動平衡攻擊。
這種最新訊息導向攻擊媒介已透過[更新分叉選擇演算法](https://github.com/ethereum/consensus-specs/pull/2845)予以關閉,從而在分叉選擇考量中完全排除了模稜兩可的驗證者。 模稜兩可的驗證者的未來影響也受到分叉選擇演算法的削減。 這可以防止上面概述的平衡攻擊,同時保持了對雪崩攻擊的強韌性。
-另一類攻擊稱為[**雪崩攻擊**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3),在一份 [2022 年 3 月的論文](https://arxiv.org/pdf/2203.01315.pdf)中進行了描述。 為了發動雪崩攻擊,攻擊者需要控制幾個連續的區塊提議者。 在每個區塊提議的時隙中,攻擊者扣留他們的區塊,將它們收集起來,直到誠實的鏈與保留的區塊達到相等的子樹權重。 然後,保留的區塊被釋放出來,使它們最大程度地模稜兩可。 作者指出,提議者加強 - 對抗平衡和反彈攻擊的主要防禦手段 - 並不能防範某些變種的雪崩攻擊。 然而,作者們只在高度理想化的以太坊分叉選擇演算法版本上展示了這種攻擊(他們使用了不帶最新訊息導向 (LMD) 的最貪婪、最重的可觀察子樹 (GHOST))。
+另一種攻擊,稱為 [**雪崩攻擊**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3),在[一篇 2022 年 3 月的論文](https://arxiv.org/pdf/2203.01315.pdf)中有所描述。 為了發動雪崩攻擊,攻擊者需要控制幾個連續的區塊提議者。 在每個區塊提議的時隙中,攻擊者扣留他們的區塊,將它們收集起來,直到誠實的鏈與保留的區塊達到相等的子樹權重。 然後,保留的區塊被釋放出來,使它們最大程度地模稜兩可。 作者指出,提議者加強 - 對抗平衡和反彈攻擊的主要防禦手段 - 並不能防範某些變種的雪崩攻擊。 然而,作者們只在高度理想化的以太坊分叉選擇演算法版本上展示了這種攻擊(他們使用了不帶最新訊息導向 (LMD) 的最貪婪、最重的可觀察子樹 (GHOST))。
透過最新訊息導向的最貪婪、最重的可觀察子樹分叉選擇演算法的最新訊息導向部分可以緩解雪崩攻擊。 LMD 為「latest-message-driven(最新訊息導向)」,指的是每個驗證者保存的一份表格,其中包含了從其他驗證者處收到的最新訊息。 該欄位只有在以下情況才會更新:新的訊息來自比驗證者表格中某個現存的時隙更晚的時隙。 實際上,這表示在每個時隙中,接收的第一則訊息會被接受,其他的則會當作模糊訊息被忽略。 換句話說,共識用戶端不會計算模糊的訊息 - 它們只會使用從每個驗證者處收到的第一則訊息,其他模糊訊息將被丟棄以避免雪崩攻擊。
-未來有其他多個對分叉選擇規則的潛在升級,可藉由提議者增強以提升安全性。 其一為[檢視合併](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739),指的是證明者會在時隙開始前的 `n` 秒凍結他們的分叉選擇檢視,然後由提議者協助同步整個網路上的鏈檢視。 另一個潛在的升級是[單時隙最終確定性](https://notes.ethereum.org/@vbuterin/single_slot_finality),其透過在一個時隙後立即最終確定區塊鏈,以保護鏈免於基於訊息時間類型的攻擊。
+未來有其他多個對分叉選擇規則的潛在升級,可藉由提議者增強以提升安全性。 其一為[檢視合併](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739),指的是證明者會在時隙開始前的 n 秒凍結他們的分叉選擇檢視,然後由提議者協助同步整個網路上的鏈檢視。 另一個潛在的升級是[單時隙最終確定性](https://notes.ethereum.org/@vbuterin/single_slot_finality),其透過在一個時隙後立即最終確定區塊鏈,以保護鏈免於基於訊息時間類型的攻擊。
#### 最終確定性延遲 {#finality-delay}
在首次描述低成本單區塊重組攻擊的[同一篇論文](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf)中,還描述了最終確定性延遲(又稱「活躍性失效」)攻擊,此攻擊仰賴攻擊者同時為時期邊界區塊的區塊提議者。 這非常重要,因為時期邊界區塊會成為 Casper FFG 用來最終確定一部分鏈的檢查點。 攻擊者只需扣留他們的區塊,直到足夠多的誠實驗證者使用他們的友善最終確定性組件投票支持前一個時期邊界區塊作為目前的最終確定目標。 接著,他們會釋放被其扣留的區塊。 攻擊者證明其區塊,其餘誠實的驗證者也會使用不同的目標檢查點建立分叉。 如果時機抓的準,他們將阻止最終確定性,因為達不到 2/3 的絕對多數來證明任何一個分叉。 質押的以太幣越少,由攻擊者直接控制的證明越少,攻擊者控制驗證者提交特定時期邊界區塊的機率就越低,因此攻擊者就需要越精準地控制時機。
-#### 遠程攻擊 {#long-range-attacks}
+#### 長程攻擊 {#long-range-attacks}
-還有種針對權益證明區塊鏈的攻擊,涉及了參與創世區塊的驗證者,他們與誠實的驗證者一起維護區塊鏈的單獨分叉,並在很久以後的某個適當時機,最終說服誠實的驗證者集合切換到該分叉。 此類型的攻擊在以太坊上不可能發生,因為最終確定性組件會在固定時間間隔(「檢查點」)確認所有驗證者都同意誠實鏈的狀態。 這個簡單的機制抵禦了遠程攻擊者,因為以太坊用戶端不會重組已最終確定的區塊。 為此,加入網路的新節點會尋找最近且受信任狀態的雜湊(即「[弱主觀性](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)」檢查點),並將該檢查點作為偽創世區塊,以在其上建置。 這會在剛加入網路的新節點開始驗證自身資訊前,為它們建立「信任閘道」。
+還有種針對權益證明區塊鏈的攻擊,涉及了參與創世區塊的驗證者,他們與誠實的驗證者一起維護區塊鏈的單獨分叉,並在很久以後的某個適當時機,最終說服誠實的驗證者集合切換到該分叉。 此類型的攻擊在以太坊上不可能發生,因為最終確定性組件會在固定時間間隔(「檢查點」)確認所有驗證者都同意誠實鏈的狀態。 這個簡單的機制抵禦了遠程攻擊者,因為以太坊用戶端不會重組已最終確定的區塊。 加入網路的心節點會尋找一個可信的最近狀態哈希 (一個「[弱主觀性](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)檢查點」),並將其作爲一個僞創世區塊以在此之上構建區塊。 這會在剛加入網路的新節點開始驗證自身資訊前,為它們建立「信任閘道」。
-#### 阻斷服務攻擊 {#denial-of-service}
+#### 拒絕服務 {#denial-of-service}
-以太坊的權益證明機制會在每個時隙,從驗證者集合中選出一個單一的驗證者作為區塊提議者。 這可以透過公開函式算出,且攻擊者可能在區塊提交前一小段時間,預先識別出下個區塊提議者。 接著,攻擊者可以對區塊提議者發送垃圾訊息,阻止他們與其對等節點交換訊息。 對網路的其餘部分來說,此時的區塊提議者視同離線,而時隙則為空。 這可能會是針對特定驗證者的一種審查方式,阻止他們在區塊鏈上新增資訊。 實現單一秘密領導者選舉 (SSLE) 或非單一秘密領導者選舉可以緩解阻斷服務攻擊風險,這是因為只有區塊提議者知道自己被選上,且無法預先知道選舉結果。 這部分尚未實現,但目前已是活躍的[研究與開發](https://ethresear.ch/t/secret-non-single-leader-election/11789)領域。
+以太坊的權益證明機制會在每個時隙,從驗證者集合中選出一個單一的驗證者作為區塊提議者。 這可以透過公開函式算出,且攻擊者可能在區塊提交前一小段時間,預先識別出下個區塊提議者。 接著,攻擊者可以對區塊提議者發送垃圾訊息,阻止他們與其對等節點交換訊息。 對網路的其餘部分來說,此時的區塊提議者視同離線,而時隙則為空。 這可能會是針對特定驗證者的一種審查方式,阻止他們在區塊鏈上新增資訊。 實現單一秘密領導者選舉 (SSLE) 或非單一秘密領導者選舉可以緩解阻斷服務攻擊風險,這是因為只有區塊提議者知道自己被選上,且無法預先知道選舉結果。 雖然尚未實施,但這是一個活躍的[研究和開發](https://ethresear.ch/t/secret-non-single-leader-election/11789)領域。
這些都表明了一個事實:要透過少量質押來成功攻擊以太坊非常困難。 此處描述的可行攻擊需要理想化的分叉選擇演算法、極端網路條件,或者已透過相對較小的用戶端軟體修補關閉了攻擊媒介。 當然,這還是無法排除現有零日攻擊逍遙在外的可能性,但它證明了在攻擊者質押量不高時,需要有非常高超的技術、對共識層的瞭解,以及運氣才有可能完成有效攻擊。 站在攻擊者的角度,最佳選擇可能是儘可能累積大量的以太幣,並提高自己在總質押中的佔比。
-### 使用超過或等於 33% 質押總量的攻擊者 {#attackers-with-33-stake}
+### 攻擊者使用超過 33% 的縂質押數量 {#attackers-with-33-stake}
攻擊者用於投票的質押以太幣用於投票,且有越多的驗證者可能在每個時隙被選中並提交區塊,那麼上述文章中提到的所有攻擊就越有可能成功。 惡意驗證者的目標可能是控制盡可能多的質押以太幣。
-33% 的質押以太幣是攻擊者的基準指標,因為只要大於此數量,攻擊者不需要精細控制其他驗證者的行為就能夠阻止鏈的最終確定。 他們可以一起消失。 如果超過 1/3 的質押以太幣為惡意證明或無法證明,則 2/3 的絕對多數就不存在,鏈也就無法最終確定。 能防禦此攻擊的方法為怠惰逐減懲罰。 怠惰逐減懲罰會識別無法證明或與多數證明相反的驗證者。 這些不進行證明的驗證者所質押的以太幣會逐漸流失,直到它們的集體佔比最終小於總量的 1/3,至此,鏈就能繼續最終確定。
+33% 的質押以太幣是攻擊者的基準指標,因為只要大於此數量,攻擊者不需要精細控制其他驗證者的行為就能夠阻止鏈的最終確定。 他們可以一起消失。 如果超過 1/3 質押的以太幣惡意的證明或不能證明,則 2/3 的絕對多數就不存在,鏈也就無法最終確定。 能防禦此攻擊的方法為怠惰逐減懲罰。 怠惰逐減懲罰會識別無法證明或與多數證明相反的驗證者。 這些不進行證明的驗證者所質押的以太幣會逐漸流失,直到它們的集體佔比最終小於總量的 1/3,至此,鏈就能繼續最終確定。
怠惰逐減懲罰的目的是讓鏈能繼續最終確定。 然而,攻擊者也會損失它們質押的部分以太幣。 持有 33% 質押以太幣總量的驗證者持續不活躍的代價十分高昂,即使在驗證者沒有被罰沒的狀況下仍然如此。
-假設以太坊網路是異步的(即發送和接收訊息間有延遲),攻擊者控制了 34% 質押總量可能會造成雙重最終確定性。 這是因為攻擊者在被選為區塊生產者時,他們可以模稜兩可,並與他們的所有驗證者完成雙重投票。 這會產生一種情況:區塊鏈分叉,且每個分叉都有 34% 的質押以太幣為它投票。 每個分叉只需要剩下驗證者的 50% 投票,就能獲得絕對多數支持,在這種情況下,兩條鏈都能最終確定(因為攻擊者驗證者的 34% + 剩下驗證者的 66% 的一半 = 每個分叉上的 67%)。 每個競爭區塊都必須被約 50% 的誠實驗證者接收,因此這種攻擊只在特定情況下可行:攻擊者對網路上傳播訊息的時間有一定的控制,這樣他們就可以將一半的誠實驗證者推到每條鏈上。 攻擊者必須銷毀他們的質押的全部以太幣(目前驗證者集合約計 1000 萬以太幣的 34%)才能實現雙重最終確定性,因為他們驗證者的 34% 會同時進行雙重投票 — 這是一種會受到罰沒的行為,具有最大的相關性懲罰。 防禦此攻擊的方式代價巨大,即銷毀 34% 總質押以太幣。 要從這種攻擊中復原,以太坊社群需要進行「帶外」協調,同意選擇其中一個分叉,並忽略另一個。
+假設以太坊網路是非同步的(即發送和接收訊息之間有延遲),控制 34% 總質押的攻擊者就可能造成雙重最終確定性。 這是因為攻擊者在被選為區塊生產者時,他們可以模稜兩可,並與他們的所有驗證者完成雙重投票。 這會產生一種情況:區塊鏈分叉,且每個分叉都有 34% 的質押以太幣為它投票。 每個分叉只需要剩下驗證者的 50% 投票,就能獲得絕對多數支持,在這種情況下,兩條鏈都能最終確定(因為攻擊者驗證者的 34% + 剩下驗證者的 66% 的一半 = 每個分叉上的 67%)。 每個競爭區塊都必須被約 50% 的誠實驗證者接收,因此這種攻擊只在特定情況下可行:攻擊者對網路上傳播訊息的時間有一定的控制,這樣他們就可以將一半的誠實驗證者推到每條鏈上。 攻擊者必須銷毀他們的質押的全部以太幣(目前驗證者集合約計 1000 萬以太幣的 34%)才能實現雙重最終確定性,因為他們驗證者的 34% 會同時進行雙重投票 — 這是一種會受到罰沒的行為,具有最大的相關性懲罰。 防禦此攻擊的方式代價巨大,即銷毀 34% 總質押以太幣。 要從這種攻擊中復原,以太坊社群需要進行「帶外」協調,同意選擇其中一個分叉,並忽略另一個。
-### 使用約 50% 質押總量的攻擊者 {#attackers-with-50-stake}
+### 攻擊者使用約 50% 的縂質押數量 {#attackers-with-50-stake}
在攻擊者持有 50% 以太幣的情況下,理論上一群作惡的驗證者可以將鏈拆分成兩個大小相同的分叉,然後使用他們全部 50% 的質押以太幣投票反對誠實的驗證者集合,從而維持這兩個分叉並阻止最終確定性。 兩條鏈上的怠惰逐減懲罰最終都會導致鏈的最終確定。 至此,從攻擊中復原的唯一選擇就是社交恢復。
-在誠實驗證者數量、網路延遲等因素變動的情況下,敵對驗證者群體能夠持續精確控制質押總量的 50% 的可能性非常小。對理性的攻擊者來說,發動攻擊的高成本及低成功率,是抑制其發動攻擊的強烈因素,尤其是當一小點額外的投資就能獲得_超過_ 50% 的佔比以解鎖更多攻擊能力時。
+在誠實驗證者數量、網路延遲等因素變動的情況下,敵對驗證者群體能夠持續精確控制質押總量的 50% 的可能性非常小。對理性的攻擊者來說,發動攻擊的高成本及低成功率,是抑制其發動攻擊的強烈因素,尤其是當一小點額外的投資就能獲得 _超過_ 50% 的佔比以解鎖更多攻擊能力時。
在攻擊者有大於 50% 總質押以太幣的情況下,攻擊者可以支配分叉選擇演算法。 在這種情況下,攻擊者自身即有能力以多數投票來完成證明,不需要再透過欺騙誠實的用戶端才能完成短期重組。 誠實的驗證者會效仿攻擊者,因為他們的分叉選擇演算法將攻擊者的鏈視為權重最高的鏈,如此一來該鏈就能最終確定。 這使得攻擊者可以審查某些交易,以有利於他們的方式進行短距重組以及透過重新排序區塊來提取最大的礦工可提取價值。 對此攻擊的防禦手段是讓攻擊者付出大多數質押的巨大成本(目前略低於 190 億美元),這會讓攻擊者面臨風險,因為社交層可能會介入並採納誠實的少數分叉,讓攻擊者的質押大幅貶值。
-### 使用超過或等於 66% 質押總量的攻擊者 {#attackers-with-66-stake}
+### 攻擊者使用 66% 或更多縂質押數量 {#attackers-with-66-stake}
-擁有 66% 或更多總質押以太幣的攻擊者,無需脅迫任何誠實驗證者即可最終確定他們所支持的鏈。 攻擊者只需要給他們支持的分叉進行投票並最終確定它,因為他們有絕對多數的不誠實投票。 作為絕對多數的質押擁有者,攻擊者始終可以控制最終確定的區塊的內容,擁有支出、回退和再次支出、審查某些交易以及隨意重組鏈的能力。 透過購買額外的以太幣來控制 66% 而不是 51%,攻擊者實際上購買了進行事後重組和最終確定性反轉的能力(即改變過去並控制未來)。 唯一實際可操作的防禦方法是付出 66% 總質押以太幣的高昂成本,並選擇回退到社交層來協調採納另一個分叉。 我們將在下一部分詳細探討這一點。
+擁有 66% 或更多總質押以太幣的攻擊者,無需脅迫任何誠實驗證者即可最終確定他們所支持的鏈。 攻擊者只需要給他們支持的分叉進行投票並最終確定它,因為他們有絕對多數的不誠實投票。 作為絕對多數的質押擁有者,攻擊者始終可以控制最終確定的區塊的內容,擁有支出、回退和再次支出、審查某些交易以及隨意重組鏈的能力。
+透過購買額外的以太幣來控制 66% 而不是 51% 的質押,攻擊者實際上是購買了執行事後重組和最終確定性反轉的能力(即改變過去並控制未來)。 唯一實際可操作的防禦方法是付出 66% 總質押以太幣的高昂成本,並選擇回退到社交層來協調採納另一個分叉。 我們將在下一部分詳細探討這一點。
-## 人:最後的防線 {#people-the-last-line-of-defense}
+## 社群:最後一道防綫 {#people-the-last-line-of-defense}
如果不誠實的驗證者設法最終確定他們所支援的鍊版本,以太坊社群將陷入困境。 規範鏈將在其歷史記錄中包含不誠實部分,同時誠實的驗證者可能會因證明另一條(誠實)鏈而被懲罰。 注意,最終確定的但不正確的鏈也可能是主流用戶端的漏洞引起的。 最後,最終的回退需要依賴社交層 - 0 層網路 - 來解決。
-以太坊權益證明共識的其中一個優點是存在[一系列的防禦策略 ](https://youtu.be/1m12zgJ42dI?t=1712),社群在面對攻擊的時候可以實施這些策略。 最起碼的回應是在不實施任何懲罰的情況下強制攻擊者的驗證者離開網路。 為了重新進入網路,攻擊者必須加入到一個激活隊列,確保驗證者集合逐步增加。 例如,增加足夠的驗證者讓質押的以太幣翻倍需要約 200 天,攻擊者要再一次嘗試 51% 攻擊,需要提前 200 天收買誠實的驗證者。 但是,社群也可以決定更嚴厲地懲罰攻擊者,方法是撤銷以往的獎勵或銷毀其一定比例的(高達 100%)質押資本。
+以太坊權益證明共識的其中一個優點是存在[一系列的防禦策略](https://youtu.be/1m12zgJ42dI?t=1712),社群在面對攻擊的時候可以實施這些策略。 最起碼的回應是在不實施任何懲罰的情況下強制攻擊者的驗證者離開網路。 為了重新進入網路,攻擊者必須加入到一個激活隊列,確保驗證者集合逐步增加。 例如,增加足夠的驗證者讓質押的以太幣翻倍需要約 200 天,攻擊者要再一次嘗試 51% 攻擊,需要提前 200 天收買誠實的驗證者。 但是,社群也可以決定更嚴厲地懲罰攻擊者,方法是撤銷以往的獎勵或銷毀其一定比例的(高達 100%)質押資本。
不管攻擊者受到什麼懲罰,社群還必須一起確認不誠實鏈實際上是否無效,儘管它被以太坊用戶端的分叉選擇演算法所支援。社群應該在誠實的鏈上建構。 誠實的驗證者可以集體同意在被社群認可的以太坊區塊鏈分叉上進行建構,例如,該分叉可能在攻擊開始之前就已經從規範鏈上分叉出來,或者攻擊者的驗證者被強行移除。 誠實的驗證者會受到激勵來建構這條鏈,因為他們可以避免因無法(正確地)證明攻擊者的鏈而受到懲罰。 建構在以太坊上的交易所、入口和應用程式可能更願意位於誠實鏈上,並且跟隨誠實驗證者的誠實區塊鏈。
-但是,這是一個重大的管理體系挑戰。 有些使用者和驗證者會在切換回誠實鏈時無可避免地產生損失,因為攻擊後被驗證的區塊中的交易可能會回滾,從而擾亂應用程式層。這很容易破壞一些相信“程式碼就是法律”的使用者的道德原則。 交易所和應用程式很可能已經把脫鏈行為和現在可能要回滾的鏈上交易關聯起來,並開始一連串的撤回和修訂,很難公平地進行取捨,特別是如果不義之財混雜在其中,存入了去中心化金融或其他衍生品,都會對誠實使用者產生二次影響。 毫無疑問,那些因為精明或機緣巧合已經從不誠實鏈獲利的一些使用者甚至機構,可能會反對分叉以保護他們的利益。 目前已經有呼籲要求社群對大於 51% 攻擊的回應進行演練,以便可以快速執行合理的協調緩解措施。 Vitalik 在 ethresear.ch 上的[這裡](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925)和[這裡](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363)以及 Twitter 上的[這裡](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)發起了一些有用的討論。 協調社交回應的目的應該是非常有針對性和具體地懲罰攻擊者並儘量減少對其他使用者的影響。
+但是,這是一個重大的管理體系挑戰。 有些使用者和驗證者會在切換回誠實鏈時無可避免地產生損失,因為攻擊後被驗證的區塊中的交易可能會回滾,從而擾亂應用程式層。這很容易破壞一些相信“程式碼就是法律”的使用者的道德原則。 交易所和應用程式很可能已經把鏈下行為和現在可能要回滾的鏈上交易關聯起來,並開始一連串的撤回和修訂,很難公平地進行取捨,特別是如果不義之財混雜在其中,存入了去中心化金融或其他衍生品,都會對誠實使用者產生二次影響。 毫無疑問,那些因為精明或機緣巧合已經從不誠實鏈獲利的一些使用者甚至機構,可能會反對分叉以保護他們的利益。 目前已經有呼籲要求社群對大於 51% 攻擊的回應進行演練,以便可以快速執行合理的協調緩解措施。 Vitalik 在 ethresear.ch [這裡](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925)和[這裡](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363)以及 Twitter [這裡](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)上有一些有用的討論。 協調社交回應的目的應該是非常有針對性和具體地懲罰攻擊者並儘量減少對其他使用者的影響。
管理體系已經是一個複雜的議題。 管理 0 層網路緊急回應透過不誠實行為最終確定的鏈,對於以太坊社群來說毋庸置疑是一個挑戰,但在以太坊歷史上[已經發生過](/ethereum-forks/#dao-fork-summary)[兩次](/ethereum-forks/#tangerine-whistle)。
@@ -151,13 +155,13 @@ lang: zh-tw
34%、51% 或 66% 攻擊可能需要帶外的社交協調來解決。 雖然對社群來說是痛苦的,但是社群的帶外響應能力對於攻擊者來說是一種強大的抑制力量。 以太坊的社交層是最終的後盾 - 從技術上取得成功的攻擊仍然會被社群同意採用誠實鏈所瓦解。 攻擊者和以太坊社群之間存在一場競賽 - 花費在 66% 攻擊上的數十億美元可能會被成功的社交協調所抹去,從而給攻擊者留下沉重的包袱,因為它們質押的以太幣將在被以太坊社群忽略的不誠實鏈上無法流動。 最終為攻擊者帶來利益的可能性非常低,這足以成為一種有效的威懾。 這就是為什麼投資於維持擁有共同價值觀和凝聚力的社交層如此重要。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [本頁面的更詳細版本](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
-- [Vitalik 關於結算最終確定性的看法](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
-- [關於最新訊息導向的最貪婪、最重的可觀察子樹的論文](https://arxiv.org/abs/2003.03052)
-- [關於 Casper-FFG 的論文](https://arxiv.org/abs/1710.09437)
-- [關於 Gasper 的論文](https://arxiv.org/pdf/2003.03052.pdf)
-- [提議者權重增強共識層規範](https://github.com/ethereum/consensus-specs/pull/2730)
-- [Ethresear.ch 上的反彈攻擊](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
-- [單一秘密領導者選舉研究](https://ethresear.ch/t/secret-non-single-leader-election/11789)
+- [本頁面的完整版](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
+- [Vitalik 談結算最終確定性](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
+- [LMD GHOST 論文](https://arxiv.org/abs/2003.03052)
+- [Casper-FFG paper](https://arxiv.org/abs/1710.09437)
+- [Gasper 論文](https://arxiv.org/pdf/2003.03052.pdf)
+- [提議者權重提升共識規範](https://github.com/ethereum/consensus-specs/pull/2730)
+- [ethresear.ch 上的彈跳攻擊](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
+- [SSLE 研究](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attestations/index.md
index 69d7856804a..4a9adbf31f5 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attestations/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attestations/index.md
@@ -8,35 +8,35 @@ lang: zh-tw
## 什麼是證明? {#what-is-an-attestation}
-每個[時期](/glossary/#epoch)(6.4 分鐘)驗證者都會向網路提交一個證明。 這個證明針對時期內的一個特定時隙。 證明的目的是投票贊成驗證者對於鏈的看法,特別是最近的合理區塊和當前時期內的第一個區塊(稱為`來源`和`目標`檢查點)。 所有參與的驗證者的資訊都會合併,使得網路可以達成關於區塊鏈狀態的共識。
+每個[時期](/glossary/#epoch)(6.4 分鐘),驗證者都會向網路提交一項證明。 這個證明針對時期內的一個特定時隙。 證明的目的是投票贊成驗證者對鏈的看法,特別是最近的合理區塊和當前時期內的第一個區塊(稱為`來源`和`目標`檢查點)。 所有參與的驗證者的資訊都會合併,使得網路可以達成關於區塊鏈狀態的共識。
證明包含以下組成部分:
-- `aggregation_bits`:驗證者的位元列表,其位置對應到委員會中的驗證者索引;(0/1) 數值表示驗證者是否簽署了 `data`(即,他們是否活躍和同意區塊提議者)
-- `data`:與證明相關的細節,如下方的定義
-- `signature`:彙總了個人驗證者簽署的 Boneh-Lynn-Shacham 簽章
+- `aggregation_bits`:驗證者的位元列表,其位置對應於委員會中的驗證者索引;值 (0/1) 表示驗證者是否簽署了 `data` (亦即他們是否處於活躍狀態並同意區塊提議者)。
+- `data`:與證明相關的詳細資訊,定義如下
+- `signature`:彙總了個別驗證者簽章的 BLS 簽章。
證明驗證者的第一個任務是建置 `data`。 `data` 包含以下資訊:
-- `slot`:證明參考的時隙號碼
-- `index`:一個數字,用來辨識驗證者在給定的時隙中所屬的委員會
-- `beacon_block_root`:驗證者在鏈頭看到的區塊的根雜湊(套用分叉選擇演算法的結果)
-- `source`:最終確定性投票的一部分,表示驗證者認為的最新的合理區塊
-- `target`:最終確定性投票的一部分,表示驗證者認為的當前時段的第一個區塊
+- `slot`:證明所參考的時隙號碼
+- `index`:一個數字,用來識別驗證者在特定時隙中隸屬哪個委員會
+- `beacon_block_root`:驗證者在鏈首所見區塊的根雜湊 (套用分叉選擇演算法的結果)
+- `source`:最終性投票的一部分,指出驗證者所見最近的合理區塊
+- `target`:最終性投票的一部分,指出驗證者所見當前時期的第一個區塊
-一旦 `data` 建置完成,驗證者就可以將 `aggregation_bits` 中對應於他們自己的驗證者索引的位元從 0 翻轉到 1,表示他們已經參與。
+一旦 `data` 建置完成,驗證者就可以將 `aggregation_bits` 中對應於自身驗證者索引的位元從 0 翻轉為 1,以表示他們已參與。
最終,驗證者簽署證明並且在網路上進行廣播。
-### 彙總的證明 {#aggregated-attestation}
+### 彙總證明 {#aggregated-attestation}
-每個驗證者在網路上傳遞此資料時,都會產生大量的相關開銷。 因此,個人驗證者在更廣泛的廣播前,先會在子網內彙總。 這包括將簽章彙總在一起,以讓廣播出去的證明包含共識 `data` 及一個單一簽章,此為所有同意該 `data` 的驗證者之簽章合併而成的簽章。 這可以透過 `aggregation_bits` 來檢查,因為它提供了每個驗證者在其委員會(委員會 ID 在 `data` 中提供)中的索引,可用於查詢個人簽章。
+每個驗證者在網路上傳遞此資料時,都會產生大量的相關開銷。 因此,個人驗證者在更廣泛的廣播前,先會在子網內彙總。 這包括將簽章彙總在一起,讓廣播的證明包含共識 `data` 及由所有同意該 `data` 的驗證者簽章組合而成的單一簽章。 這可以透過 `aggregation_bits` 來檢查,因為它提供了每個驗證者在其委員會中的索引 (其 ID 在 `data` 中提供),可用於查詢個人簽章。
-在每個時期,每個子網中都會選出 16 個驗證者來擔任`聚合者`。 聚合者會收集它在廣播網路中監聽到的與其自身 `data` 相同的所有證明。 每個符合證明的發送者會被記錄在 `aggregation_bits` 中。 然後,聚合者將彙總證明廣播到更廣泛的網路。
+在每個時期,每個子網中會選出 16 個驗證者來擔任`聚合者`。 聚合者會從 gossip 網路上收集與其自身 `data` 等效的所有證明。 每個相符證明的發送者都會記錄在 `aggregation_bits` 中。 然後,聚合者將彙總證明廣播到更廣泛的網路。
當驗證者被選為區塊提議者時,它們會將最新時隙來自子網的彙總證明打包到新區塊中。
-### 證明包含生命週期 {#attestation-inclusion-lifecycle}
+### 證明納入生命週期 {#attestation-inclusion-lifecycle}
1. 產生
2. 傳播
@@ -46,9 +46,9 @@ lang: zh-tw
證明的生命週期如下圖所示:
-
+
-## 酬勞 {#rewards}
+## 獎勵 {#rewards}
驗證者提交證明可以獲得獎勵。 證明的獎勵依參與標記(來源、目標和頭部)、基礎獎勵和參與率而定。
@@ -60,33 +60,33 @@ lang: zh-tw
標記證明率是透過特定標記的「所有證明驗證者的有效餘額總和」與「總活躍有效餘額」的比較來計算的。
-### 基礎獎勵 {#base-reward}
+### 基本酬勞 {#base-reward}
基礎獎勵是根據參與證明的驗證者數量及其質押的有效以太幣餘額計算的:
-`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)`
+`基本酬勞 = 驗證者有效餘額 x 2^6 / SQRT(所有活躍驗證者的有效餘額)`
#### 納入延遲 {#inclusion-delay}
-當驗證者在鏈頭 (`block n`) 上投票時,`block n+1` 尚未提議。 所以,證明自然會在**經過一個區塊之後**被納入區塊,因此所有在作為鏈頭的 `block n` 上投票的證明都會在 `block n+1` 被納入,**納入延遲**爲 1。 若納入延遲加倍至 2 個時隙,則證明的獎勵會減半,這是因爲證明獎勵的計算方式爲基礎獎勵乘以納入延遲的倒數。
+當驗證者對鏈首 (`block n`) 投票時,`block n+1` 尚未提出。 因此,證明自然會**晚一個區塊**被納入,所有對 `block n` 為鏈首投票的證明都會被納入 `block n+1`,而**納入延遲**是 1。 若納入延遲加倍至 2 個時隙,則證明的獎勵會減半,這是因爲證明獎勵的計算方式爲基礎獎勵乘以納入延遲的倒數。
-### 證明場景 {#attestation-scenarios}
+### 證明情境 {#attestation-scenarios}
-#### 缺少參加投票的驗證者 {#missing-voting-validator}
+#### 投票驗證者缺席 {#missing-voting-validator}
驗證者最多有一個時期能夠提交他們的證明。 若錯過了在時期 0 時提交證明的機會,則它們可在時期 1 時提交(經過一個納入延遲)。
-#### 缺少聚合者 {#missing-aggregator}
+#### 聚合者缺席 {#missing-aggregator}
-每個時期總共有 16 個聚合者。 此外,驗證者會隨機訂閱**兩個子網路並持續 256 個時期**,並在缺少聚合者時作為備用。
+每個時期總共有 16 個聚合者。 此外,隨機的驗證者會訂閱**兩個子網路長達 256 個時期**,並在聚合者缺席時充當備援。
-#### 缺少區塊提議者 {#missing-block-proposer}
+#### 區塊提議者缺席 {#missing-block-proposer}
-值得注意的是,在一些情況下幸運的聚合者可能同時被選為區塊提議者。 若因為區塊提議者消失而導致證明未被納入,則下個區塊提議者會取得已彙總的證明並納入下一個區塊。 但是,**納入延遲**會因此增加 1。
+值得注意的是,在一些情況下幸運的聚合者可能同時被選為區塊提議者。 若因為區塊提議者消失而導致證明未被納入,則下個區塊提議者會取得已彙總的證明並納入下一個區塊。 然而,**納入延遲**將會增加 1。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [Vitalik 註解的共識規範中的證明](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
+- [Vitalik 的註解版共識規格中的證明](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
- [eth2book.info 中的證明](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/block-proposal/index.md
index bba4beeea6e..3d6df0d1c54 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/block-proposal/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/block-proposal/index.md
@@ -8,7 +8,7 @@ lang: zh-tw
## 先決條件 {#prerequisites}
-區塊提議是權益證明協定的一部分。 為了幫助瞭解本頁的資訊,我們推薦你閱讀關於[權益證明](/developers/docs/consensus-mechanisms/pos/)與[區塊架構](/developers/docs/blocks/)的相關內容。
+區塊提議是權益證明協定的一部分。 為了幫助您理解本頁面,我們建議您先閱讀關於 [權益證明](/developers/docs/consensus-mechanisms/pos/) 和 [區塊架構](/developers/docs/blocks/) 的文章。
## 區塊由誰生產? {#who-produces-blocks}
@@ -18,11 +18,11 @@ lang: zh-tw
每個時隙會有一個以偽隨機方式選擇的驗證者來提議區塊。 在區塊鏈中沒有實質的隨機性,因為如果每個節點都產生真實的隨機數,那麼它們是無法達成共識的。 相反的,目的是讓驗證者的選擇過程無法預測。 以太坊使用一種名為 RanDAO 的演算法來達到隨機性,這種演算法會將區塊提議者的雜湊值與一個隨著每個區塊而更新的種子混在一起。 這個值會被用來從整個驗證者集合中選出一個特定的驗證者。 驗證者的選擇會提前兩個時期鎖定,這種方式可以防範特定類型的種子操控。
-儘管驗證者會在每個時隙添增 RANDAO,全域 RANDAO 值每個時期僅更新一次。 為了計算下一個區塊提議者的索引,RANDAO 值會跟時隙號碼混合,為每個時隙提供一個獨特數值。 一個驗證者被選中的機率並不是簡單的 `1/N`(其中 `N`= 活躍驗證者總數)。 相反的,它會依照每個驗證者的有效以太幣餘額進行加權。 最大有效餘額為 32 個以太幣(這代表著 `balance < 32 ETH` 會產生低於 `balance == 32 ETH` 的加權,但是 `balance > 32 ETH` 並不會產生高於 `balance == 32 ETH` 的加權)。
+儘管驗證者會在每個時隙添增 RANDAO,全域 RANDAO 值每個時期僅更新一次。 為了計算下一個區塊提議者的索引,RANDAO 值會跟時隙號碼混合,為每個時隙提供一個獨特數值。 單一驗證者被選中的機率並非只是 `1/N`(其中 `N` = 活躍驗證者總數)。 相反的,它會依照每個驗證者的有效以太幣餘額進行加權。 最大有效餘額為 32 ETH(這表示 `balance < 32 ETH` 的權重會低於 `balance == 32 ETH`,但 `balance > 32 ETH` 的權重並不會高於 `balance == 32 ETH`)。
每個時隙只有一個區塊提議者會被選中。 在正常的情況下,一個區塊生產者會在其專門的時隙中建立並且釋出一個區塊。 在一個時隙中建立兩個區塊是一種很嚴重的罪行,通常被稱為「模棱兩可」。
-## 區塊如何建立? {#how-is-a-block-created}
+## 區塊是如何被創造的? {#how-is-a-block-created}
區塊提議者預計會廣播一個已簽署的信標區塊,該區塊建置在根據他們自己在本地運行的分叉選擇演算法所看到的最近鏈頭之上。 分叉選擇演算法會套用上一個時隙留下的任何排隊證明,然後在其歷史記錄中尋找具有最大累積證明權重的區塊。 該區塊便是由提議者建立的新區塊的父塊。
@@ -42,28 +42,28 @@ class BeaconBlockBody(Container):
execution_payload: ExecutionPayload
```
-`randao_reveal` 欄位取一個可驗證的隨機值,該值是區塊提議者透過簽署當前的時期編號建立的。 `eth1_data` 是就區塊提議者對存款合約的看法進行的投票,包括存款默克爾樹的根和使新存款能夠被驗證的總存款數。 `graffiti` 是一個可選欄位,可用來在區塊中新增一條訊息。 `proposer_slashings` 和 `attester_slashings` 欄位包含了某些驗證者根據區塊提議者對鏈的看法已經犯下可罰沒行為的證據。 `deposits` 是區塊提議者所知道的新驗證者存款的清單,`voluntary_exits` 是區塊提議者從共識層廣播網路上監聽到的希望退出的驗證者的清單。 `sync_aggregate` 是一個向量,顯示哪些驗證者之前被分配到一個同步委員會(服務於輕量用戶端資料的驗證者子集)並參與了資料簽章。
+`randao_reveal` 欄位採用一個可驗證的隨機值,該值由區塊提議者簽署當前時期編號所建立。 `eth1_data` 是對區塊提議者關於存款合約觀點的投票,內容包含存款 Merkle trie 的根,以及可讓新存款通過驗證的存款總數。 `graffiti` 是一個選填欄位,可用來在區塊中新增訊息。 `proposer_slashings` 和 `attester_slashings` 是包含證明的欄位,根據提議者對鏈的觀點,某些驗證者已犯下可罰沒的行為。 `deposits` 是區塊提議者知悉的新驗證者存款清單,`voluntary_exits` 是區塊提議者在共識層 gossip 網路上聽聞的、希望退出的驗證者清單。 `sync_aggregate` 是一個向量,顯示先前指派到同步委員會 (服務輕型用戶端資料的驗證者子集) 且參與簽署資料的驗證者。
-`execution_payload` 使得關於交易的資訊可以在執行用戶端和共識用戶端之間傳遞。 `execution_payload` 是一個被嵌套在信標鏈區塊內部的執行資料區塊。 `execution_payload` 中的欄位反映了以太坊黃皮書中概述的區塊結構,只不過其中沒有親戚區塊,並且 `prev_randao` 取代了 `difficulty`。 執行用戶端可以存取它在自己的 Gossip 網路上監聽到的本機交易池。 這些交易在本機執行,以產生一個被稱為「後狀態」的更新狀態樹。 這些交易被包含在 `execution_payload` 中名為 `transactions` 的清單中,後狀態則在 `state-root` 欄位中提供。
+`execution_payload` 讓交易相關資訊得以在執行用戶端和共識用戶端之間傳遞。 `execution_payload` 是巢狀內嵌於信標區塊的執行資料區塊。 `execution_payload` 內的欄位反映了以太坊黃皮書中所述的區塊結構,但其中沒有 ommers,且 `prev_randao` 取代了 `difficulty`。 執行用戶端可以存取它在自己的 Gossip 網路上監聽到的本機交易池。 這些交易在本機執行,以產生一個被稱為「後狀態」的更新狀態樹。 交易會以名為 `transactions` 的清單形式包含在 `execution_payload` 中,而後狀態則在 `state-root` 欄位中提供。
所有這些資料都被收集在一個信標區塊中,經過簽署並廣播給區塊提議者的對等節點,再由他們傳播給他們的對等節點,以此類推。
-閱讀更多關於[區塊剖析](/developers/docs/blocks)的內容。
+閱讀更多關於 [區塊剖析](/developers/docs/blocks) 的資訊。
## 區塊會發生什麼? {#what-happens-to-blocks}
-區塊被新增至區塊提議者的本機資料庫,並透過共識層廣播網路廣播給對等節點。 當驗證者接收到區塊時,它會驗證其中的資料,包括檢查區塊是否有正確的父塊、是否對應正確的時隙、提議者索引是否符合預期、RANDAO 揭示是否有效,以及提議者是否被罰沒。 `execution_payload` 被解綁,驗證者的執行用戶端重新執行清單中的交易,以檢查所提議的狀態變化。 假設區塊通過了所有這些檢查,每個驗證者將區塊新增到自己的規範鏈中。 然後,在下一個時隙中重新開始這個過程。
+區塊被新增至區塊提議者的本機資料庫,並透過共識層廣播網路廣播給對等節點。 當驗證者接收到區塊時,它會驗證其中的資料,包括檢查區塊是否有正確的父塊、是否對應正確的時隙、提議者索引是否符合預期、RANDAO 揭示是否有效,以及提議者是否被罰沒。 `execution_payload` 會被解包,驗證者的執行用戶端會重新執行清單中的交易,以檢查提議的狀態變更。 假設區塊通過了所有這些檢查,每個驗證者將區塊新增到自己的規範鏈中。 然後,在下一個時隙中重新開始這個過程。
## 區塊獎勵 {#block-rewards}
-區塊提議者會收到他們工作的報酬。 有一個 `base_reward`,是根據活躍驗證者的數量和他們的有效餘額來計算的。 然後,區塊提議者會因為區塊中包含的每個有效證明而收到 `base_reward` 的一部分;證明區塊的驗證者越多,區塊提議者獲得的獎勵就越高。 還有一個獎勵是報告應該被罰沒的驗證者,數額等於每個被罰沒的驗證者的 `1/512 * effective balance`。
+區塊提議者會收到他們工作的報酬。 有一個 `base_reward`,是根據活躍驗證者的數量及其有效餘額計算而來。 區塊提議者接著會因區塊中包含的每個有效證明,而收到一部分的 `base_reward`;為區塊證明的驗證者越多,區塊提議者的獎勵就越高。 舉報應受罰沒的驗證者也會獲得獎勵,獎勵金額為每位受罰沒的驗證者的 `1/512 * 有效餘額`。
[更多關於獎勵和懲罰的資訊](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [區塊簡介](/developers/docs/blocks/)
- [權益證明簡介](/developers/docs/consensus-mechanisms/pos/)
-- [以太坊共識規範](https://github.com/ethereum/consensus-specs)
-- [Gasper 簡介](/developers/docs/consensus-mechanisms/pos/)
+- [以太坊共識規格](https://github.com/ethereum/consensus-specs)
+- [Gasper 簡介](/developers/docs/consensus-mechanisms/pos/gasper/)
- [升級以太坊](https://eth2book.info/)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/faqs/index.md
index 9b03a6e67e9..71314e5b2eb 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/faqs/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/faqs/index.md
@@ -4,11 +4,11 @@ description: 有關以太坊權益證明的常見問題
lang: zh-tw
---
-## 何謂權益證明 (PoS)? {#what-is-proof-of-stake}
+## 什麼是權益證明? {#what-is-proof-of-stake}
權益證明是一種演算法,透過確保行為不檢的攻擊者失去有價值的資產,來保障區塊鏈的安全。 權益證明系統需要一組驗證者抵押部分資產,當其中有人被證實有不誠實行為,他的資產將被銷毀。 以太坊使用權益證明機制來保護區塊鏈。
-## 權益證明與工作量證明哪個較好? {#comparison-to-proof-of-work}
+## 權益證明與工作量證明哪個較好? 與工作量證明的比較 {#comparison-to-proof-of-work}
工作量證明和權益證明都是以經濟手段抑制惡意行為者向網路傳送垃圾訊息或進行詐欺的機制。 兩者都需要積極參與共識的節點「向網路中」投入一些資產,如果他們行為不當,便會喪失這些資產。
@@ -18,7 +18,7 @@ lang: zh-tw
工作量證明的能耗要高得多,因為在挖礦的過程中需要消耗大量電力。 相反,權益證明僅需要極少量的能源 - 以太坊驗證者甚至可以在樹莓派這類低功率的裝置上運行。 以太坊的權益證明機制被認為比工作量證明更加安全,因為攻擊的成本更高,且對攻擊者造成的影響更加嚴重。
-工作量證明和權益證明的比較是一個有爭議性的話題。 [Vitalik Buterin 的部落格](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work)、Justin Drake 和 Lyn Alden 之間的辯論,都提供了很好的總結。
+工作量證明和權益證明的比較是一個有爭議性的話題。 [Vitalik Buterin 的部落格](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work)以及 Justin Drake 和 Lyn Alden 之間的辯論對這些論點做了很好的總結。
@@ -26,31 +26,31 @@ lang: zh-tw
是的, 權益證明網路中的節點僅使用極少量的能源。 一項第三方研究指出,基於整個權益證明的以太坊網路每年消耗大約 0.0026 太瓦時,僅約美國遊戲市場的 1/13,000。
-[更多關於以太坊能耗的資訊](/energy-consumption/)。
+[更多關於以太坊能源消耗的資訊](/energy-consumption/).
## 權益證明安全嗎? {#is-pos-secure}
以太坊權益證明非常安全。 這個機制在上線前經過了 8 年的研究、開發和嚴格的測試。 它的安全保證不同於工作量證明區塊鏈。 在權益證明中,惡意驗證者會遭到主動懲罰(「罰沒」)並從驗證者集合中踢出,致使其損失大量的以太幣。 而在工作量證明中,攻擊者擁有足夠的雜湊算力就可以持續反覆攻擊。 相較工作量證明,對權益證明以太坊發動相同攻擊的成本也更高。 若要影響區塊鏈的活躍性,至少需要網路中總質押以太幣的 33%(除非進行高度複雜且成功率極低的攻擊)。 如果要控制未來區塊的內容,至少需要網路中總質押以太幣的 51%,如果要重寫歷史紀錄,則需要超過總質押量的 66%。 以太坊協定會在遭到 33% 或 51% 攻擊時銷毀這些資產,並以社交共識來應對 66% 攻擊的情境。
-- [更多保護以太坊權益證明免受攻擊者攻擊的相關資訊](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
+- [更多關於防禦以太坊權益證明免受攻擊者攻擊的資訊](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
- [更多關於權益證明設計的資訊](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
## 權益證明令使用以太坊的成本更低嗎? {#does-pos-make-ethereum-cheaper}
否。 傳送交易的成本(燃料費)取決於費用市場動態,該成本會隨著網路需求而增加。 共識機制不會直接影響交易成本。
-[更多關於燃料的資訊](/developers/docs/gas)。
+[更多關於 Gas 的資訊](/developers/docs/gas).
## 何謂節點、用戶端和驗證者? {#what-are-nodes-clients-and-validators}
節點是連線到以太坊網路的電腦。 用戶端是將電腦轉化成節點所需運行的軟體。 有兩種類型的用戶端:執行用戶端和共識用戶端。 建立一個節點,兩種用戶端都需要。 驗證者是共識用戶端的一個選擇附加元件,讓節點可以參與權益證明共識。 參與共識機制是指被選中建立和提議區塊,以及證明從網路上接收到的區塊。 若要運行一個驗證者,節點營運商必須向存款合約中存入 32 個以太幣。
- [更多關於節點和用戶端的資訊](/developers/docs/nodes-and-clients)
-- [更多權益質押相關資訊](/staking)
+- [更多關於質押的資訊](/staking)
## 權益證明是一個新概念嗎? {#is-pos-new}
-否。 在 2011 年的 BitcoinTalk 論壇上,就有使用者[提出權益證明的基本概念](https://bitcointalk.org/index.php?topic=27787.0)作為比特幣的升級版。 11 年後,它才準備好在以太坊主網上實作。 一些其他的區塊鏈較以太坊更早實行權益證明,但並非以太坊的特定機制(稱為 Gasper)。
+否。 2011 年,一位 BitcoinTalk 使用者[提出了權益證明這個基本概念](https://bitcointalk.org/index.php?topic=27787.0),作為比特幣的升級版。 11 年後,它才準備好在以太坊主網上實作。 一些其他的區塊鏈較以太坊更早實行權益證明,但並非以太坊的特定機制(稱為 Gasper)。
## 以太坊的權益證明有甚麼特別之處? {#why-is-ethereum-pos-special}
@@ -74,9 +74,9 @@ Casper 和 LMD_GHOST 的組合被稱為 Gasper。
## 如何挑選驗證者? {#how-are-validators-selected}
-每個時隙都會透過一個名為 RANDAO 的演算法,以偽隨機的方式選出一個驗證者來提議區塊,該演算法會將區塊提議者的雜湊值和一個每區塊都會更新的種子混雜在一起。 所產生的這個數值會用來從整個驗證者集合中選出一個特定的驗證者。 驗證者的選擇會提前兩個時期固定。
+每個時隙都會透過一個名為 RANDAO 的演算法,以偽隨機的方式選出一個驗證者來提議區塊,該演算法會將區塊提議者的雜湊值和一個每區塊都會更新的種子混雜在一起。 這個值會被用來從整個驗證者集合中選出一個特定的驗證者。 驗證者的選擇會提前兩個時期固定。
-[更多關於驗證者挑選的資訊](/developers/docs/consensus-mechanisms/pos/block-proposal)
+[更多關於驗證者選擇的資訊](/developers/docs/consensus-mechanisms/pos/block-proposal)
## 什麼是權益粉碎攻擊? {#what-is-stake-grinding}
@@ -89,7 +89,7 @@ Casper 和 LMD_GHOST 的組合被稱為 Gasper。
社交罰沒是指社群透過協調區塊鏈分叉來應對攻擊的能力。 它使社群能夠從攻擊者最終確定不誠實鏈中恢復。 社交罰沒也可以用來抵禦審查攻擊。
- [更多關於社交罰沒的資訊](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7)
-- [Vitalik Buterin 談社交罰沒](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
+- [Vitalik Buterin 關於社交罰沒的觀點](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
## 我會受到罰沒嗎? {#will-i-get-slashed}
@@ -101,7 +101,7 @@ Casper 和 LMD_GHOST 的組合被稱為 Gasper。
無利害關係問題是一些權益證明機制中的一個概念性議題,在此種機制下只有獎勵而沒有懲罰。 如果沒有任何利害關係,那麼務實的驗證者會樂於證明任何甚至多個區塊鏈分叉,因為這會讓他們的獎勵增加。 以太坊透過最終性條件和罰沒來解決這個問題,確保只有一條規範鏈。
-[更多關於無利害關係問題的資訊](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed)
+[更多關於無權益押注問題的資訊](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed)
## 什麼是分叉選擇演算法? {#what-is-a-fork-choice-algorithm}
@@ -115,7 +115,7 @@ Casper 和 LMD_GHOST 的組合被稱為 Gasper。
在權益證明中,最終確定性是指保證特定的區塊是規範鏈的永久一部分,除非存在共識失敗,即攻擊者銷毀了總質押以太幣的 33%,否則該區塊就不會被撤銷。 這是「加密經濟」上的最終確定性,與工作量證明區塊鏈相關的「機率最終確定性」不同。 在機率最終確定性中,區塊沒有明確的最終確定或非最終確定狀態 - 隨著區塊在鏈上存在的時間越長,該區塊從鏈上被移除的機率會逐漸降低,並且由使用者自行確定在他們對區塊有足夠信心時自行認定它是安全的。 在加密經濟上的最終確定性中,成對的檢查點區塊必須獲得總質押以太幣的 66% 的投票支持。 如果滿足這個條件,則這些檢查點之間的區塊將明確地「最終確定」。
-[更多關於最終確定性的資訊](/developers/docs/consensus-mechanisms/pos/#finality)
+[更多關於最終性的資訊](/developers/docs/consensus-mechanisms/pos/#finality)
## 什麼是「弱主觀性」? {#what-is-weak-subjectivity}
@@ -127,19 +127,19 @@ Casper 和 LMD_GHOST 的組合被稱為 Gasper。
目前很難證明權益證明的抗審查性。 然而,與工作量證明不同,權益證明提供了協調罰沒機制,以懲罰審查驗證者。 該協定即將修改為將區塊建構者與區塊提議者分開,並實行建構者必須在每個區塊中包含的交易清單。 此提案被稱為「提議者 - 建構者分離」,有助於防止驗證者審查交易。
-[更多關於提議者 - 建構者分離的資訊](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme)
+[更多關於提案者-建構者分離的資訊](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme)
-## 以太坊的權益證明系統會受到 51% 攻擊嗎? {#pos-51-attack}
+## 以太坊的權益證明系統會受到 51% 攻擊嗎? 對權益證明的 51% 攻擊 {#pos-51-attack}
是的, 權益證明和工作量證明一樣,也易受 51% 攻擊。 攻擊者不需要掌控 51% 的網路算力,而是需要掌控已質押以太幣總數的 51%。 累積了總質押量 51% 的攻擊者,便可以控制分叉選擇演算法。 這使得攻擊者能夠審查某些交易、進行短程重組,並透過以有利於他們的方式重新排序區塊來提取最大可提取價值。
-[更多關於權益證明攻擊的資訊](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
+[更多關於對權益證明的攻擊資訊](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
## 什麼是社交協調,為什麼需要它? {#what-is-social-coordination}
社交協調是以太坊上的最後一道防線,讓誠實鏈可以從已最終確定不誠實區塊的攻擊中恢復。 在這種情況下,以太坊社群必須進行「帶外」協調,並采納一個誠實的少數分叉,在此過程中懲處攻擊者的驗證者。 這也需要應用程式和交易所能夠識別誠實的分叉。
-[更多關於社交協調的資訊](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense)
+[閱讀更多關於社交協調的資訊](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense)
## 權益證明會讓富者越富嗎? {#do-rich-get-richer}
@@ -147,9 +147,9 @@ Casper 和 LMD_GHOST 的組合被稱為 Gasper。
## 權益證明比工作量證明更中心化嗎? {#is-pos-decentralized}
-不,工作量證明趨於中心化,因爲挖礦成本增加,導致個人礦工被淘汰,接著是小公司被淘汰,依此類推。 權益證明目前的問題是流動性質押衍生品 (LSD) 的影響。 這些代幣代表由某個供應商質押的以太幣,任何人都可以在二級市場交換它們,而無需實際取消以太幣的質押。 流動性質押衍生品讓使用者可以用少於 32 個以太幣進行質押,這也帶來了中心化風險,一些大型組織最終可以控制大部分質押。 這就是爲什麽說[單獨質押](/staking/solo)是以太坊的最佳選項。
+不,工作量證明趨於中心化,因爲挖礦成本增加,導致個人礦工被淘汰,接著是小公司被淘汰,依此類推。 權益證明目前的問題是流動性質押衍生品 (LSD) 的影響。 這些代幣代表由某個供應商質押的以太幣,任何人都可以在二級市場交換它們,而無需實際取消以太幣的質押。 流動性質押衍生品讓使用者可以用少於 32 個以太幣進行質押,這也帶來了中心化風險,一些大型組織最終可以控制大部分質押。 這就是為什麼 [單獨質押](/staking/solo) 是以太坊的最佳選擇。
-[更多流動性質押衍生品中心化的相關資訊](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
+[更多關於流動性質押衍生品中的質押中心化資訊](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
## 為什麼我只能質押以太幣? {#why-can-i-only-stake-eth}
@@ -163,10 +163,10 @@ Casper 和 LMD_GHOST 的組合被稱為 Gasper。
合併是指以太坊關閉基於工作量證明的共識機制,並啓用基於權益證明的共識機制的時刻。 合併發生與 2022 年 9 月 15 日。
-[合併案的相關細節](/roadmap/merge)
+[更多關於合併的資訊](/roadmap/merge)
## 什麽是活躍性與安全性? {#what-are-liveness-and-safety}
活躍性和安全性是區塊鏈的兩大基礎安全問題。 活躍性是指最終確定鏈的可用性。 如果鏈停止最終確定或者用戶無法很容易地存取它,這就是活躍性失效。 使用成本極高也可以視爲活躍性失效。 安全性是指攻擊鏈(即最終確定衝突檢查點)的難度。
-[閱讀更多關於 Casper 的論文](https://arxiv.org/pdf/1710.09437.pdf)
+[在 Casper 論文中閱讀更多內容](https://arxiv.org/pdf/1710.09437.pdf)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/gasper/index.md
index dd861e76a1c..a50ce72e7bf 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/gasper/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/gasper/index.md
@@ -6,13 +6,13 @@ lang: zh-tw
Gasper 是由 Casper 友善最終確定性組件 (Casper-FFG) 及 LMD-GHOST 分叉選擇演算法組成的。 這些部分共同構成了保護權益證明以太坊的共識機制。 Casper 是將特定區塊升級至「最終確定」的機制,這樣新加入網路的節點就可以確定它們正在同步的是規範鏈。 分叉選擇演算法使用累積的投票,以確保節點能在區塊鏈發生分叉時很容易地選擇正確的鏈。
-**注意**:由於 Casper-FFG 包含在 Gasper 中,因此其原始定義有小幅更新。 此頁面中的定義為更新後的版本。
+**請注意**,為了納入 Gasper,Casper-FFG 的原始定義略有更新。 此頁面中的定義為更新後的版本。
-## 前置要求
+## 先備知識
-要瞭解本頁的內容,推薦先閱讀[權益證明](/developers/docs/consensus-mechanisms/pos/)的介紹頁面。
+若要了解本資料,必須閱讀關於[權益證明](/developers/docs/consensus-mechanisms/pos/)的介紹頁面。
-## Gasper 扮演的角色 {#role-of-gasper}
+## Gasper 的作用 {#role-of-gasper}
Gasper 建立於權益證明區塊鏈之上,節點會提供以太幣作為保證金,若其在提議或驗證區塊時懶惰或不誠實,該保證金可能會被銷毀。 Gasper 是定義如何獎勵及處罰驗證者,決定應接受和拒絕哪個區塊,以及在區塊鏈的哪個分叉上建構的機制。
@@ -23,30 +23,30 @@ Gasper 建立於權益證明區塊鏈之上,節點會提供以太幣作為保
1. 三分之二的總質押以太幣必須投票支持將該區塊納入規範連。 此條件將區塊升級至「合理化」狀態。 合理區塊不太可能被還原,但在某些情況下也有可能。
2. 當另一個區塊在一個合理區塊上被合理化時,該區塊將被升級至「最終確定」狀態。 最終確定一個區塊是將其納入規範鏈的承諾。 除非攻擊者銷毀了數百萬枚以太幣(數十億 $USD),否則該區塊無法被還原。
-並非每個時隙都會發生這種區塊升級。 相反,只有時期邊界的區塊可以被合理化並最終確定。 這些區塊被稱爲「檢查點」。 升級需要考慮成對的檢查點。 兩個連續的檢查點中間必須存在一個「絕對多數連結」(即三分之二的縂質押以太幣投票支持檢查點 B 是檢查點 A 的正確子代),才能將較早的檢查點升級至最終確定狀態,並將較新的區塊升級至合理化狀態。
+並非每個時隙都會發生這種區塊升級。 相反,只有時期邊界的區塊可以被合理化並最終確定。 這些區塊被稱爲「檢查點」。 升級需要考慮成對的檢查點。 兩個連續的檢查點之間必須存在一個「絕對多數連結」(即三分之二的總質押以太幣投票支持檢查點 B 是檢查點 A 的正確子代),才能將較早的檢查點升級至最終確定狀態,並將較新的區塊升級至合理化狀態。
由於最終性需要三分之二的縂質押以太幣同意某個區塊是規範區塊,因此攻擊者無法在缺少下列條件的情況下建立另一條最終確定鏈:
1. 擁有或操縱三分之二的縂質押以太幣。
2. 銷毀至少三分之一的縂質押以太幣。
-第一個條件出現的原因是需要三分之二的質押以太幣來最終確定一條鏈。 之所以有第二個條件,是因爲如果三分之二的質押總量投票支持了兩個分叉,則必然有三分之一的質押總量同時投票支持了兩個分叉。 雙重投票符合罰沒條件,會受到最大程度的懲罰,銷毀三分之一的質押縂量。 截至 2022 年 5 月,這需要攻擊者銷毀價值約 100 億美元的以太幣。 Gasper 中用於合理化並最終確定區塊的演算法是[友善最終確定性組件 (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) 的輕微改動版本。
+第一個條件出現的原因是需要三分之二的質押以太幣來最終確定一條鏈。 之所以有第二個條件,是因爲如果三分之二的質押總量投票支持了兩個分叉,則必然有三分之一的質押總量同時投票支持了兩個分叉。 雙重投票符合罰沒條件,會受到最大程度的懲罰,銷毀三分之一的質押縂量。 截至 2022 年 5 月,這需要攻擊者銷毀價值約 100 億美元的以太幣。 Gasper 中用於合理化並最終確定區塊的演算法,是 [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) 的輕微改動版本。
-### 激勵與罰沒 {#incentives-and-slashing}
+### 獎勵與罰沒 {#incentives-and-slashing}
誠實地提議和驗證區塊的驗證者會獲得獎勵。 以太幣將作爲獎勵新增到他們的質押中。 另一方面,缺席或在被呼叫時未能響應的驗證者將錯過這些獎勵,有時還會損失他們現有質押的一小部分。 然而,離綫的處罰是較小的,在多數情況下,僅為錯失獎勵的機會成本。 但是,有些驗證者的行爲很難是無意爲之,並且表現出某種惡意企圖,例如在同一個時隙提議多個區塊、在同一個時隙證明多個區塊,或與先前的檢查點投票自相矛盾。 這些「可罰沒」行爲將受到更嚴厲的懲罰 - 罰沒將導致驗證者的部分質押被銷毀,並將驗證者移出驗證者網路。 這個過程需要 36 天。 在第 1 天,會有最高 1 個以太幣的初始懲罰。 之後,被罰沒驗證者的以太幣將在退出期間緩慢耗盡,但在第 18 天,他們會受到「相關性懲罰」,當更多的驗證者在大致同一時間被罰沒時,該懲罰的力度也會更大。 懲罰的上限是全部質押。 這些獎勵和懲罰旨在激勵誠實的驗證者,並抑制對網路的攻擊。
-### 怠惰逐減懲罰 {#inactivity-leak}
+### 閒置懲罰 {#inactivity-leak}
除了安全性外,Gasper 也提供「合理的活躍性」。 條件是只要三分之二的縂質押以太幣誠實地投票並遵循協定,無論是否有任何其他活動產生(例如攻擊、延遲問題或罰沒),鏈都能被最終確定。 換言之,想要阻止區塊鏈被最終確定,必須以某種方式損毀三分之一的縂質押以太幣。 在 Gasper 中,還有另一道防綫來防範活躍性失效,它就是「怠惰逐減懲罰」。 如果鏈未能在 4 個時期内最終確定,該機制就會啓動。 未能積極證明主鏈的驗證者的質押將會逐漸被消耗,直到主鏈重新獲得三分之二的縂質押投票,確保活躍性失效只是暫時的。
### 分叉選擇 {#fork-choice}
-Casper-FFG 的原始定義包含一種分叉選擇演算法,該演算法規定:`遵循包含具有最大高度的合理化檢查點的鏈`,其中高度被定義爲距離創世區塊的最遠距離。 在 Gasper 中,原始的分叉選擇規則已被棄用,轉而采用一種名為 LMD-GHOST 的更精密演算法。 請注意,在正常情況下,分叉選擇規則是不必要的 - 每個時隙只有一個區塊提議者,并有誠實的驗證者進行證明。 只有當網路非同步性過大或不誠實的區塊提議者模棱兩可的情況下,才需要分叉選擇演算法。 然而,當這些情況真的發生時,分叉選擇演算法是確保正確鏈的重要防禦措施。
+Casper-FFG 的原始定義包含一個分叉選擇演算法,該演算法規定:`遵循包含具有最大高度之合理化檢查點的鏈`,其中高度被定義為距離創世區塊的最遠距離。 在 Gasper 中,原始的分叉選擇規則已被棄用,轉而采用一種名為 LMD-GHOST 的更精密演算法。 請注意,在正常情況下,分叉選擇規則是不必要的 - 每個時隙只有一個區塊提議者,并有誠實的驗證者進行證明。 只有當網路非同步性過大或不誠實的區塊提議者模棱兩可的情況下,才需要分叉選擇演算法。 然而,當這些情況真的發生時,分叉選擇演算法是確保正確鏈的重要防禦措施。
LMD-GHOST 代表「最新訊息驅動的最貪婪、最重的可觀察子樹 (latest message-driven greedy heaviest observed sub-tree)」。 這是一個行話味很重的術語,用來定義這樣一種演算法:選擇具有最大累積證明權重的分叉作爲規範分叉(貪婪最重子樹),並且如果收到來自驗證者的多條訊息,則只考慮最新的訊息(最新訊息驅動)。 在將最重區塊新增到其規範鏈之前,每名驗證者都會使用此規則來評估每個區塊。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [Gasper:最貪婪、最重的可觀察子樹 (GHOST) 與 Casper 的結合](https://arxiv.org/pdf/2003.03052.pdf)
-- [Casper 友善最終確定性組件](https://arxiv.org/pdf/1710.09437.pdf)
+- [Gasper:結合 GHOST 與 Casper](https://arxiv.org/pdf/2003.03052.pdf)
+- [友善最終確定性組件](https://arxiv.org/pdf/1710.09437.pdf)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/index.md
index 3603280e3f5..048286938ad 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/index.md
@@ -4,54 +4,54 @@ description: 對權益證明共識協定及其在以太坊中之作用的解釋
lang: zh-tw
---
-權益證明 (PoS) 是支撐以太坊[共識機制](/developers/docs/consensus-mechanisms/)的基礎。 以太坊於 2022 年啟用了權益證明機制,這一轉變主要因為相較於之前的[工作量證明](/developers/docs/consensus-mechanisms/pow)架構,權益證明機制在安全性上更為可靠,且能源消耗更低,為實現新的擴容解決方案提供了更優越的基礎。
+權益證明 (PoS) 是 [以太坊共識機制](/developers/docs/consensus-mechanisms/) 的基礎。 以太坊於 2022 年改用權益證明機制,因為與先前的 [工作量證明](/developers/docs/consensus-mechanisms/pow) 架構相比,權益證明機制更安全、耗能更少,也更有利於實施新的擴容解決方案。
## 先決條件 {#prerequisites}
-為了更好地理解此頁面,我們建議你先閱讀[共識機制](/developers/docs/consensus-mechanisms/)的相關資料。
+為能更深入了解本頁內容,我們建議您先閱讀 [共識機制](/developers/docs/consensus-mechanisms/) 的相關資訊。
## 什麼是權益證明 (PoS)? {#what-is-pos}
權益證明是一種證明驗證者已經將有價值物品質押到網路上的方法。如果驗證者有失信行為,這些物品可能會被銷毀。 在以太坊的權益證明機制下,驗證者明確地透過以太幣將資產質押到以太坊上的智慧型合約中。 之後,驗證者負責檢查在網路上傳播的新區塊是否有效,偶爾自己也建立和傳播新區塊。 當他們試圖欺騙網路時(例如,在應該傳送一個區塊時提議多個區塊,或傳送衝突的證明),他們質押的部分或全部以太幣可能會被銷毀。
-## 驗證者 {#validators}
+## 驗證程式 {#validators}
要作為驗證者參與,使用者必須向存款合約存入 32 個以太幣並執行三種獨立的軟體:執行用戶端、共識用戶端和驗證者用戶端。 存入以太幣時,使用者會加入一個激活隊列,限制新驗證者加入網路的速度。 激活後,驗證者會從以太坊網路上的對等節點接收新區塊。 區塊中的交易會被重新執行,以檢查提議的以太坊狀態變更是否有效,並檢查區塊的簽章。 然後驗證者在整個網路上傳送支持該區塊的投票(稱為證明)。
在工作量證明中,產生區塊的時間是由挖礦難度決定的,而在權益證明中,節奏是固定的。 權益證明以太坊中的時間分為時隙(12 秒)和時期(32 個時隙)。 在每個時隙會隨機選擇一位驗證者作為區塊提議者。 該驗證者負責建立新區塊並傳送給網路上的其他節點。 另外在每個時隙中,都會隨機選擇一個驗證者委員會,透過他們的投票來確定所提議區塊的有效性。 將驗證者集合劃分為若干個委員會對於保持網路負載易於管理非常重要。 委員會將驗證者集合分成不同部分,以便每個活躍的驗證者在每個時期都會出示證明,但並非每個時隙都這樣做。
-## 如何在以太坊權益證明中執行交易 {#transaction-execution-ethereum-pos}
+## 以太坊 PoS 如何執行交易 {#transaction-execution-ethereum-pos}
以下提供了關於如何在以太坊權益證明中執行交易的全面解釋。
-1. 使用者使用他們的私鑰建立並簽署[交易](/developers/docs/transactions/)。 這通常由錢包或程式庫處理,例如 [ethers.js](https://docs.ethers.org/v6/)、[web3js](https://docs.web3js.org/)、[web3py](https://web3py.readthedocs.io/en/v5/) 等,但本質上是使用者在使用以太坊 [JSON-RPC 應用程式介面](/developers/docs/apis/json-rpc/)向節點發出請求。 使用者定義他們準備支付的一定數量的燃料,作為給驗證者的小費,以鼓勵他們將交易納入到區塊中。 [小費](/developers/docs/gas/#priority-fee)支付給驗證者,而[基本費用](/developers/docs/gas/#base-fee)則會被銷毀。
-2. 交易提交給以太坊[執行層用戶端](/developers/docs/nodes-and-clients/#execution-client)以驗證其有效性。 這意味著確保發送者有足夠的以太幣來完成交易,並且他們已經使用正確的金鑰來簽署交易。
-3. 如果交易有效,執行層用戶端將其新增至其本機記憶體池(待處理交易清單),並透過執行層廣播網路將其廣播到其他節點。 當其他節點聽到關於交易的消息時,它們也會將其添加到本地記憶體池中。 進階使用者可能會避免廣播他們的交易,而是將其轉發給專門的區塊建置者,例如 [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview)。 這使他們能夠在即將到來的區塊中組織交易以獲得最大利潤([最大可提取價值](/developers/docs/mev/#mev-extraction))。
-4. 網路上的驗證者節點之一是當前時隙的區塊提議者,該提議者是之前使用 RANDAO 以偽隨機方式選取的。 該節點負責建立和廣播下一個要新增至以太坊區塊鏈的區塊並更新全域狀態。 此節點由三個部分組成:執行用戶端、共識用戶端和驗證者用戶端。 執行層用戶端將來自本機記憶體池的交易捆綁到「執行有效負載」中,並在本機執行它們以產生狀態變更。 此資訊被傳遞到共識用戶端,在該用戶端,執行有效載荷被包裝為「信標區塊」的一部分。該信標區塊還包含有關獎勵、懲罰、罰沒、證明等的資訊,從而使網路能夠就鏈頭的區塊順序達成一致。 [連線共識用戶端和執行用戶端](/developers/docs/networking-layer/#connecting-clients)中更詳細地描述了執行用戶端和共識用戶端之間的通訊。
-5. 其他節點在共識層廣播網路上接收新的信標區塊, 並將其傳遞給它們的執行用戶端。在執行用戶端上,交易在本機重新執行以確保提議的狀態變更有效。 然後,驗證者用戶端證明該區塊是有效的,並且根據他們的看法,這在邏輯上是鏈上的下一個區塊(這意味著它建置在如[分叉選擇規則](/developers/docs/consensus-mechanisms/pos/#fork-choice)所定義的具有最大證明權重的鏈上)。 該區塊被新增到證明它的每個節點的本機資料庫中。
+1. 使用者用自己的私鑰建立並簽署一筆 [交易](/developers/docs/transactions/)。 此操作通常由錢包或程式庫 (例如 [ethers.js](https://docs.ethers.org/v6/)、[web3js](https://docs.web3js.org/)、[web3py](https://web3py.readthedocs.io/en/v5/) 等) 處理,但在底層,使用者是透過以太坊 [JSON-RPC API](/developers/docs/apis/json-rpc/) 向節點發出請求。 使用者定義他們準備支付的一定數量的燃料,作為給驗證者的小費,以鼓勵他們將交易納入到區塊中。 [小費](/developers/docs/gas/#priority-fee) 會付給驗證者,而 [基本費用](/developers/docs/gas/#base-fee) 則會被銷毀。
+2. 交易會提交給以太坊 [執行用戶端](/developers/docs/nodes-and-clients/#execution-client),後者會驗證其有效性。 這意味著確保發送者有足夠的以太幣來完成交易,並且他們已經使用正確的金鑰來簽署交易。
+3. 如果交易有效,執行層用戶端將其新增至其本機記憶體池(待處理交易清單),並透過執行層廣播網路將其廣播到其他節點。 當其他節點聽到關於交易的消息時,它們也會將其添加到本地記憶體池中。 進階使用者可能會避免廣播他們的交易,而是將其轉發給專門的區塊建構者,例如 [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview)。 這讓他們能在接下來的區塊中組織交易,以獲取最大利潤 ([MEV](/developers/docs/mev/#mev-extraction))。
+4. 網路上的驗證者節點之一是當前時隙的區塊提議者,該提議者是之前使用 RANDAO 以偽隨機方式選取的。 該節點負責建立和廣播下一個要新增至以太坊區塊鏈的區塊並更新全域狀態。 此節點由三個部分組成:執行用戶端、共識用戶端和驗證者用戶端。 執行層用戶端將來自本機記憶體池的交易捆綁到「執行有效負載」中,並在本機執行它們以產生狀態變更。 此資訊被傳遞到共識用戶端,在該用戶端,執行有效載荷被包裝為「信標區塊」的一部分。該信標區塊還包含有關獎勵、懲罰、罰沒、證明等的資訊,從而使網路能夠就鏈頭的區塊順序達成一致。 執行用戶端與共識用戶端之間的通訊,在 [連接共識與執行用戶端](/developers/docs/networking-layer/#connecting-clients) 中有更詳細的說明。
+5. 其他節點在共識層廣播網路上接收新的信標區塊, 並將其傳遞給它們的執行用戶端。在執行用戶端上,交易在本機重新執行以確保提議的狀態變更有效。 驗證者用戶端接著會證明該區塊是有效的,且就其所檢視的鏈而言,該區塊是邏輯上的下一個區塊 (這表示它建立在 [分叉選擇規則](/developers/docs/consensus-mechanisms/pos/#fork-choice) 所定義的、具有最大證明權重的鏈上)。 該區塊被新增到證明它的每個節點的本機資料庫中。
6. 如果交易已經成為兩個檢查點之間具有「絕對多數連結」的鏈的一部分,那麼可以認為該交易已經「最終確定」。 檢查點發生在每個時期的開始,它們的存在是為了兼顧以下事實:每個時隙只有活躍驗證者的子集會提供證明,但所有活躍驗證者在每個完整時期內都會提供證明。 因此,只有在時期之間才能證明「絕對多數連結」(即網路上總質押以太幣的 66% 同意兩個檢查點的情況)。
關於最終確定性的更多詳細資訊,請參見下文。
## 最終性 {#finality}
-交易在分佈式網路中具有「最終確定性」是指,該交易是區塊的一部分,而且除非銷毀大量以太幣,否則便無法變更。 在權益證明以太坊上,最終確定性是透過「檢查點」區塊來管理的。 每個時期中的第一個區塊便是檢查點。 驗證者為其認為有效的「檢查點對」投票。 如果一對檢查點獲得了質押以太幣總數中三分之二以上的投票,那麼這對檢查點將被升級。 這兩個(目標)中較新的一個會變成「合理化」狀態。 較舊的一個檢查點已經是合理化狀態,因為它是上一個時期中的「目標」。 現在,這個檢查點已升級為「最終確定」狀態。
+交易在分佈式網路中具有「最終確定性」是指,該交易是區塊的一部分,而且除非銷毀大量以太幣,否則便無法變更。 在權益證明以太坊上,最終確定性是透過「檢查點」區塊來管理的。 每個時期中的第一個區塊便是檢查點。 驗證者為其認為有效的「檢查點對」投票。 如果一對檢查點獲得了質押以太幣總數中三分之二以上的投票,那麼這對檢查點將被升級。 這兩個(目標)中較新的一個會變成「合理化」狀態。 較舊的一個檢查點已經是合理化狀態,因為它是上一個時期中的「目標」。 現在,這個檢查點已升級為「最終確定」狀態。 升級檢查點的過程由 **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)** 處理。 Casper-FFG 是一種用於共識的區塊最終性工具。 區塊一旦最終確認,除非大多數質押者遭到罰沒,否則無法還原或更改,這使其在經濟上不可行。
-要撤銷最終確定的區塊,攻擊者將承擔至少相當於質押以太幣總數三分之一的損失。 這篇[以太坊基金會部落格文章](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)解釋了其確切原因。 由於最終確定性需要獲得三分之二的多數投票,攻擊者可以用質押以太幣總數的三分之一投票來阻止網路實現最終確定性。 有一種可以防禦此種攻擊行為的機制:[怠惰逐減懲罰](https://eth2book.info/bellatrix/part2/incentives/inactivity)。 如果鏈未能在四個時期內最終確定,此機制就會啟動。 怠惰逐減懲罰會逐漸消耗驗證者投票反對大多數驗證者的質押以太幣,使大多數驗證者重新獲得三分之二多數投票,以最終確定鏈。
+要撤銷最終確定的區塊,攻擊者將承擔至少相當於質押以太幣總數三分之一的損失。 確切原因在這篇 [以太坊基金會部落格文章](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) 中有說明。 由於最終確定性需要獲得三分之二的多數投票,攻擊者可以用質押以太幣總數的三分之一投票來阻止網路實現最終確定性。 有一種機制可以防禦這種情況:[閒置懲罰](https://eth2book.info/bellatrix/part2/incentives/inactivity)。 如果鏈未能在四個時期內最終確定,此機制就會啟動。 怠惰逐減懲罰會逐漸消耗驗證者投票反對大多數驗證者的質押以太幣,使大多數驗證者重新獲得三分之二多數投票,以最終確定鏈。
## 加密經濟安全性 {#crypto-economic-security}
運行驗證者是一個承諾。 驗證者應要維持足夠的硬體和連線,以參與區塊驗證和提議。 作為回報,驗證者會獲得以太幣(他們的質押餘額增加)。 另一方面,作為驗證者參與也會開啟新渠道,讓使用者為了個人利益或為破壞而攻擊網路。 為了預防此種情況,如果驗證者在被調用時並未能參與,將會錯過以太幣獎勵,且他們如果有不誠實行為,目前的質押可能會被銷毀。 兩種主要的行為會被視為不誠實:在一個時隙中提議多個區塊(模稜兩可),以及提交相互矛盾的證明。
-罰沒的以太幣數量視大致同一時間受到罰沒的驗證者數量而定。 這稱為[「相關性懲罰」](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty)。相關性懲罰可以很輕微(單個驗證者被罰沒約 1% 的質押),或是造成驗證者 100% 的質押被銷毀(大額罰沒事件)。 這種懲處在強制退出期執行,首先是第一天的立即懲罰(最高 1 枚以太幣),接下來是第 18 天的相關性懲罰,最後是第 36 天的逐出網路。 如果驗證者在網路上但未提交投票,驗證者每天會受到輕微的證明懲罰。 以上均表明,協同攻擊對攻擊者來說代價將極其高昂。
+罰沒的以太幣數量視大致同一時間受到罰沒的驗證者數量而定。 這就是所謂的 [「關聯性懲罰」](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty),懲罰可能很輕微 (單一驗證者自身被罰沒約 1% 的質押),也可能導致驗證者 100% 的質押被銷毀 (大規模罰沒事件)。 這種懲處在強制退出期執行,首先是第一天的立即懲罰(最高 1 枚以太幣),接下來是第 18 天的相關性懲罰,最後是第 36 天的逐出網路。 如果驗證者在網路上但未提交投票,驗證者每天會受到輕微的證明懲罰。 以上均表明,協同攻擊對攻擊者來說代價將極其高昂。
## 分叉選擇 {#fork-choice}
-當網路以最佳狀態誠信運行時,鏈頭始終只會有一個新區塊並且所有驗證者都會證明它。 然而,由於網路延遲或因為區塊提議者提出多個區塊(模棱兩可),驗證者可能會看到不同的鏈頭視圖。 因此,共識用戶端需要一種演算法來確定支援哪一個區塊。 在權益證明以太坊中所用的演算法稱為 [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf),其工作原理是識別在其歷史記錄中具有最大證明權重的分叉。
+當網路以最佳狀態誠信運行時,鏈頭始終只會有一個新區塊並且所有驗證者都會證明它。 然而,由於網路延遲或因為區塊提議者提出多個區塊(模棱兩可),驗證者可能會看到不同的鏈頭視圖。 因此,共識用戶端需要一種演算法來確定支援哪一個區塊。 權益證明以太坊中使用的演算法稱為 [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf),其運作方式是識別其歷史紀錄中具有最大證明權重的分叉。
-## 權益證明及安全性 {#pos-and-security}
+## 權益證明與安全性 {#pos-and-security}
-[51% 攻擊](https://www.investopedia.com/terms/1/51-attack.asp)的威脅如在工作量證明中一樣仍存在於權益證明,但對攻擊者來說風險更大。 攻擊者將需要 51% 的質押以太幣。 然後他們可以使用自己的證明,確保其首選的分叉為最多累積證明的分叉。 共識用戶端使用累積證明的「權重」來決定正確的鏈,使攻擊者能夠因此讓他們的分叉成為規範分叉。 然而,相較於工作量證明,權益證明的優勢在於社群可以靈活地發動反擊。 例如,誠實的驗證者可以決定繼續在非多數鏈上建置,忽略攻擊者的分叉,同時鼓勵應用程式、交易所和池也這樣做。 他們也可以決定強行將攻擊者從網路中移除,並銷毀其質押以太幣。 這些都是針對 51% 攻擊強而有力的經濟防禦。
+[51% 攻擊](https://www.investopedia.com/terms/1/51-attack.asp) 的威脅在權益證明中與在工作量證明中一樣存在,但對攻擊者來說風險更高。 攻擊者將需要 51% 的質押以太幣。 然後他們可以使用自己的證明,確保其首選的分叉為最多累積證明的分叉。 共識用戶端使用累積證明的「權重」來決定正確的鏈,使攻擊者能夠因此讓他們的分叉成為規範分叉。 然而,相較於工作量證明,權益證明的優勢在於社群可以靈活地發動反擊。 例如,誠實的驗證者可以決定繼續在非多數鏈上建置,忽略攻擊者的分叉,同時鼓勵應用程式、交易所和池也這樣做。 他們也可以決定強行將攻擊者從網路中移除,並銷毀其質押以太幣。 這些都是針對 51% 攻擊強而有力的經濟防禦。
除了 51% 攻擊,不良行為者也可能嘗試其他惡意活動,例如:
@@ -62,7 +62,7 @@ lang: zh-tw
整體來說,以太坊上實行的權益證明在經濟方面展現為比工作量證明更安全。
-## 優勢及劣勢 {#pros-and-cons}
+## 優點和缺點 {#pros-and-cons}
| 優勢 | 劣勢 |
| ----------------------------------------------------------------------- | -------------------------- |
@@ -82,18 +82,18 @@ lang: zh-tw
- 與工作量證明相比,不當行為的經濟懲罰使發動 51% 攻擊的攻擊者須付出更高的代價
- 如果 51% 攻擊攻破加密經濟防禦,社群可以採取誠實鏈的社交恢復。
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [權益證明常見問題](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) - _Vitalik Buterin_
-- [什麼是權益證明?](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/)- _ConsenSys_
-- [權益證明是什麼,又有何重要性?](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463)- _Vitalik Buterin_
-- [為什麼採用權益證明(2020 年 11 月)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html)- _Vitalik Buterin_
-- [權益證明:我如何學著愛上弱主觀性](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) - _Vitalik Buterin_
-- [權益證明以太坊攻擊與防禦](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
-- [權益證明的設計哲學](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) - _Vitalik Buterin_
+- [權益證明常見問題](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_
+- [什麼是權益證明](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_
+- [權益證明是什麼及其重要性](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_
+- [為什麼選擇權益證明 (2020 年 11 月)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_
+- [權益證明:我如何學會愛上弱主觀性](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_
+- [權益證明以太坊的攻擊與防禦](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
+- [權益證明設計哲學](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_
- [影片:Vitalik Buterin 向 Lex Fridman 解釋權益證明](https://www.youtube.com/watch?v=3yrqBG-7EVE)
## 相關主題 {#related-topics}
-- [工作量證明(PoW)](/developers/docs/consensus-mechanisms/pow/)
+- [工作量證明](/developers/docs/consensus-mechanisms/pow/)
- [權威證明](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/keys/index.md
index b0cc78f1648..88d82c3db19 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/keys/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/keys/index.md
@@ -6,15 +6,15 @@ lang: zh-tw
以太坊使用公私金鑰密碼學來保護使用者資產。 公鑰是以太坊地址的基礎,可被大眾看見並用作一個獨特的身分識別。 私鑰(或「密鑰」)則永遠只能由帳戶擁有者存取。 私鑰被用來「簽署」交易和資料,以便密碼學可以驗證私鑰持有者核准特定私鑰的某些動作。
-以太坊的金鑰透過[橢圓曲線密碼學](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)產生。
+以太坊的金鑰是使用[橢圓曲線密碼學](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)產生的。
-然而,當以太坊從[工作量證明](/developers/docs/consensus-mechanisms/pow)轉換為[權益證明](/developers/docs/consensus-mechanisms/pos)後,一種新型態的金鑰加入到以太坊中。 原始的金鑰仍維持相同的運作 — 使用基於橢圓曲線密碼學的金鑰來保障帳戶安全沒有變化。 然而,使用者需要一種新型態的金鑰,透過質押以太幣和運作驗證者來參與權益證明。 這個需求源於擴容帶來的挑戰,許多訊息需要在眾多的驗證者間傳遞,過程中需要一種可以輕鬆彙總的密碼學方法,以減少網路達成共識所需的通訊量。
+然而,當以太坊從[工作量證明](/developers/docs/consensus-mechanisms/pow)轉換到[權益證明](/developers/docs/consensus-mechanisms/pos)時,一種新型的金鑰被新增到以太坊中。 原始的金鑰仍維持相同的運作 — 使用基於橢圓曲線密碼學的金鑰來保障帳戶安全沒有變化。 然而,使用者需要一種新型態的金鑰,透過質押以太幣和運作驗證者來參與權益證明。 這個需求源於擴容帶來的挑戰,許多訊息需要在眾多的驗證者間傳遞,過程中需要一種可以輕鬆彙總的密碼學方法,以減少網路達成共識所需的通訊量。
-這種新型態的金鑰使用 [**Boneh-Lynn-Shacham (BLS)** 簽章方案](https://wikipedia.org/wiki/BLS_digital_signature)。 BLS 能高效率地彙總簽名,同時允許對彙總的單獨驗證者金鑰進行逆向工程,非常適合管理驗證者之間的動作。
+這種類型的新金鑰使用 [**Boneh-Lynn-Shacham (BLS)** 簽章方案](https://wikipedia.org/wiki/BLS_digital_signature)。 BLS 能高效率地彙總簽名,同時允許對彙總的單獨驗證者金鑰進行逆向工程,非常適合管理驗證者之間的動作。
-## 兩種類型的驗證者金鑰 {#two-types-of-keys}
+## 兩種驗證者金鑰 {#two-types-of-keys}
-在以太坊過渡到權益證明之前,使用者只有一個基於橢圓曲線密碼學的私密金鑰來存取他們的資金。 隨著權益證明的引入,希望成為單獨質押者的使用者還需要**驗證者金鑰**和**提款金鑰**。
+在以太坊過渡到權益證明之前,使用者只有一個基於橢圓曲線密碼學的私密金鑰來存取他們的資金。 隨著權益證明的引入,希望成為獨立質押者的使用者也需要**驗證者金鑰**和**提款金鑰**。
### 驗證者金鑰 {#validator-key}
@@ -23,9 +23,9 @@ lang: zh-tw
- 驗證者**私**鑰
- 驗證者**公**鑰
-驗證者私鑰的作用是簽署鏈上作業,像是區塊提議和證明區塊。 因此,這些私鑰必須存放在熱錢包中。
+。 因此,這些私鑰必須存放在熱錢包中。
-這種彈性的優勢是可以快速地在不同裝置間移轉驗證者簽章金鑰,然而,如果這些金鑰遺失或被偷,那竊盜者便可透過以下方式進行**惡意行為**:
+這種彈性的優勢是可以快速地在不同裝置間移轉驗證者簽署金鑰,然而,如果這些金鑰遺失或被竊,竊賊便可透過以下幾種方式**進行惡意行為**:
- 使驗證者遭受罰沒:
- 做為提議者,在同一個時隙簽署兩個不同的信標區塊
@@ -33,34 +33,38 @@ lang: zh-tw
- 做為證明者,簽署兩個具有相同目標的不同證明
- 強制執行自願退出,使驗證者停止質押並授權提款金鑰擁有者存取其以太幣餘額。
-當使用者將以太幣存入質押存款合約時,**驗證者公鑰**會被包含在交易資料中。 這被稱為_存款資料_,讓以太坊能夠辨識驗證者。
+當使用者將 ETH 存入質押存款合約時,**驗證者公鑰**會被包含在交易資料中。 這被稱為_存款資料_,讓以太坊能夠識別驗證者。
### 提款憑證 {#withdrawal-credentials}
-每個驗證者都會有一個稱為_提款憑證_的屬性。 這是一個 32 位元組的欄位,以 `0x00` 開頭,代表 Boneh-Lynn-Shacham 提款憑證,或是以 `0x01` 開頭,代表指向一個執行地址的憑證。
+每個驗證者都有一個稱為_提款憑證_的屬性。 這個 32 位元組欄位的第一個位元組用來識別帳戶類型:`0x00` 代表原始 BLS(Shapella 之前,不可提款)憑證,`0x01` 代表指向執行地址的舊版憑證,而 `0x02` 則代表現代的複利憑證類型。
-持有 `0x00` Boneh-Lynn-Shacham 金鑰的驗證者,必須更新這些憑證,將其指向執行地址以啟用超額獎勵發放或全額質押提款。 驗證者可以在初始金鑰產生的階段,就將執行地址包含在存款資料中,_或_後續透過使用提款金鑰來簽署和廣播一則 `BLSToExecutionChange` 訊息。
+具有 `0x00` BLS 金鑰的驗證者必須更新這些憑證,以指向一個執行地址,才能啟動超額餘額支付或從質押中完全提款。 這可以在初始金鑰產生期間,透過在存款資料中提供一個執行地址來完成,_或者_稍後使用提款金鑰來簽署並廣播一則 `BLSToExecutionChange` 訊息。
+
+[更多關於驗證者提款憑證的資訊](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/)
### 提款金鑰 {#withdrawal-key}
-如果在初始存款階段沒有設定,則需要提款金鑰來更新提款憑證,將其指向執行地址。 此設定使超額獎勵發放能夠開始處理,也讓使用者能將他們質押的以太幣全額提款。
+如果在初始階段沒有設置,則需要提款金鑰來更新提款憑證,將提款憑證指向執行地址。 此設定使超額獎勵發放能夠開始處理,也讓使用者能將他們質押的以太幣全額提款。
如同驗證者金鑰,提款金鑰也由兩個元件組成:
- 提款**私**鑰
- 提款**公**鑰
-如果在更新提款憑證為 `0x01` 類型前遺失金鑰,則意味著喪失對驗證者餘額的存取權限。 驗證者依舊可以簽署證明和區塊,因為這些動作只需要驗證者私鑰,然而遺失了提款私鑰就幾乎沒有激勵。
+在將提款憑證更新為 `0x01` 類型之前遺失此金鑰,意味著將失去對驗證者餘額的存取權限。 驗證者依舊可以簽署證明和區塊,因為這些動作只需要驗證者私鑰,然而遺失了提款私鑰就幾乎沒有激勵。
將驗證者金鑰與以太坊帳戶金鑰分離,可以讓一個使用者運行多個驗證者。

+**注意**:目前要退出質押職責並提取驗證者餘額,需要使用驗證者金鑰簽署一份[自願退出訊息 (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1)。 然而,[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) 是一項提案,未來將允許使用者使用提款金鑰簽署退出訊息,以觸發驗證者退出並提取其餘額。 這將透過讓將 ETH 委託給[質押即服務供應商](/staking/saas/#what-is-staking-as-a-service)的質押者能夠繼續控制其資金,從而減少信任假設。
+
## 從種子助記詞派生金鑰 {#deriving-keys-from-seed}
如果每質押 32 個以太幣都需要一組新的 2 個完全獨立的金鑰,那金鑰管理很快就會變得無效率,尤其對那些運行多個驗證者的使用者而言。 相反,多個驗證者金鑰可以從一個共同的秘鑰派生,並且儲存這個秘鑰就允許存取多個驗證者金鑰。
-[助記詞](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase)和路徑通常是[使用者存取](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0)自己的錢包時最重要的工具。 助記詞是一連串的文字,做為私密金鑰的初始種子。 當助記詞和額外的資料結合,即可產生一個稱為「主密鑰」的雜湊值。 這可以視為一個樹的根部。 然後從這個根部開始,使用階層路徑來派生分支,使子節點可以作為其父節點的雜湊值及其在樹中的索引之組合而存在。 閱讀 [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 及 [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki),瞭解基於助記詞生成金鑰的標準。
+[助記詞](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase)和路徑是使用者[存取](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0)錢包時經常遇到的顯著功能。 助記詞是一連串的文字,做為私密金鑰的初始種子。 當助記詞和額外的資料結合,即可產生一個稱為「主密鑰」的雜湊值。 這可以視為一個樹的根部。 然後從這個根部開始,使用階層路徑來派生分支,使子節點可以作為其父節點的雜湊值及其在樹中的索引之組合而存在。 閱讀關於基於助記詞金鑰產生的 [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 和 [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) 標準。
這些路徑具有以下結構,與硬體錢包有過互動的使用者會相對熟悉:
@@ -71,10 +75,10 @@ m/44'/60'/0'/0`
這些路徑中的斜線將私鑰的組成部分區分如下:
```
-master_key / purpose / coin_type / account / change / address_index
+主金鑰 / 目的 / 幣種類型 / 帳戶 / 找零 / 地址索引
```
-因為樹根是相同的,變化發生在分支,所以這個邏輯讓使用者能將盡可能多的驗證者附加到一個**助記詞**上。 使用者可以從助記詞中**派生任意數量的金鑰**。
+這個邏輯讓使用者能將盡可能多的驗證者附加到單一**助記詞**上,因為樹根可以共用,而差異則產生於分支。 使用者可以從助記詞中**派生任意數量的金鑰**。
```
[m / 0]
@@ -86,11 +90,13 @@ master_key / purpose / coin_type / account / change / address_index
[m / 2]
```
-每一個分支由 `/` 來區分,因此 `m/2` 代表從主金鑰開始並遵循分支 2。 下圖顯示,一個助記詞用來儲存三個提款金鑰,每一個金鑰有兩個關聯的驗證者。
+每一個分支由 / 來區分,因此 m/2 代表從主金鑰開始並遵循分支 2。 下圖顯示,一個助記詞用來儲存三個提款金鑰,每一個金鑰有兩個關聯的驗證者。

-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [Carl Beekhuizen 發布的以太坊基金會部落格文章](https://blog.ethereum.org/2020/05/21/keys/)
+- [Carl Beekhuizen 的以太坊基金會部落格文章](https://blog.ethereum.org/2020/05/21/keys/)
- [EIP-2333 BLS12-381 金鑰產生](https://eips.ethereum.org/EIPS/eip-2333)
+- [EIP-7002:執行層觸發退出](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge)
+- [大規模金鑰管理](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md
index 5f1cf2ff576..54897aa907e 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md
@@ -14,17 +14,17 @@ lang: zh-tw
### 攻擊成本 {#cost-to-attack}
-在權益證明中,驗證者需要在智慧型合約中代管(「質押」)至少 32 個以太幣。 以太坊能夠在驗證者行為不端時,將質押的以太幣銷毀作為懲罰。 為了達成共識,至少 66% 的總質押以太幣需要投票贊成某個特定的區塊集合。 獲得 >= 66% 的質押以太幣投票贊成的區塊會「最終確定」,代表這些區塊無法再被移除或是重組。
+在權益證明中,驗證者需要在智慧型合約中代管(「質押」)至少 32 個以太幣。 以太坊能夠在驗證者行為不端時,將質押的以太幣銷毀作為懲罰。 為了達成共識,至少 66% 的總質押以太幣需要投票贊成某個特定的區塊集合。 獲得 >=66% 權益投票贊成的區塊會「最終確定」,代表這些區塊無法再被移除或是重組。
攻擊網路可能是阻止鏈的最終確定,或是確保規範鏈內的某種區塊組織以某種方式讓攻擊者受益。 這需要攻擊者透過累積大量以太幣並直接投票,或是欺騙誠實的驗證者,讓他們投出特定的票,將誠實的共識改道。 複雜且概率較低的攻擊會欺騙誠實的驗證者,除此之外,攻擊以太坊的成本就是攻擊者必須累積的以有利於他們的方式影響共識的質押以太幣。
-最低攻擊成本是 >33% 的總質押以太幣。 持有 >33% 質押總量的攻擊者可以簡單地透過離線造成最終確定性延遲。 這對網路造成的影響相對較小,因為有一種叫做「怠惰逐減懲罰」的機制,它會將離線驗證者的質押逐漸消減,直到線上的多數驗證者的質押佔比達到 66%,這時就可以重新對鏈進行最終確定。 攻擊者理論上也可以透過持有稍高於 33% 的質押總量來製造雙重最終確定性,即攻擊者會在他們被要求產生區塊時,用他們的所有驗證者去重複投票並建立不止一個區塊。 每個分叉只需 50% 的剩餘誠實驗證者就能先看到每個區塊,所以如果他們控制訊息傳送時間得宜,他們有可能讓兩個分叉都能最終確定。 這種攻擊的成功率很低,但如果攻擊者有辦法做到雙重最終確定性,以太坊社群將不得不決定採用其中一個分叉,這種情況下,另一個分叉上攻擊者的驗證者必然會遭到罰沒。
+攻擊的最低成本是 >33% 的總權益。 持有 >33% 總權益的攻擊者只要離線,就能造成最終性延遲。 這對網路造成的影響相對較小,因為有一種叫做「怠惰逐減懲罰」的機制,它會將離線驗證者的質押逐漸消減,直到線上的多數驗證者的質押佔比達到 66%,這時就可以重新對鏈進行最終確定。 攻擊者理論上也可以透過持有稍高於 33% 的質押總量來製造雙重最終確定性,即攻擊者會在他們被要求產生區塊時,用他們的所有驗證者去重複投票並建立不止一個區塊。 每個分叉只需 50% 的剩餘誠實驗證者就能先看到每個區塊,所以如果他們控制訊息傳送時間得宜,他們有可能讓兩個分叉都能最終確定。 這種攻擊的成功率很低,但如果攻擊者有辦法做到雙重最終確定性,以太坊社群將不得不決定採用其中一個分叉,這種情況下,另一個分叉上攻擊者的驗證者必然會遭到罰沒。
-擁有 >33% 的質押總量,攻擊者就有機會對以太坊網路造成輕微(最終確定性延遲)或是嚴重(雙重最終確定性)的影響。 當在網路上質押大於 14,000,000 個以太幣時,以代表性的價格 1000 美元/以太幣計算,這些攻擊的最低成本為 `1000 x 14,000,000 x 0.33 = $4,620,000,000`。 攻擊者遭到罰沒時會失去這些錢並被逐出以太坊。 如果他們想要再次攻擊,則需要再次累積 >33% 的質押以太幣,然後再把這些錢銷毀一次。 每次嘗試攻擊以太坊網路都需要 >46 億美元的成本(以 1000 美元/以太幣及 1400 萬質押以太幣計算)。 攻擊者在被罰沒時也會被驅逐出以太坊,如果他們想再次加入,則需要重新排隊。 這表示重複攻擊的速率不只受制於攻擊者需要累積 >33% 的質押總量,還需要花時間等待其所有的驗證者加入以太坊網路。 每一次的攻擊都會讓攻擊者變得更窮,而剩餘的社群則得益於供給衝擊的結果而變得更富。
+擁有 >33% 的總權益,攻擊者就有機會對以太坊網路造成輕微(最終性延遲)或更嚴重(雙重最終性)的影響。 在網路上質押超過 14,000,000 ETH,並以 1000 美元/ETH 的代表性價格計算,發動這些攻擊的最低成本為 `1000 x 14,000,000 x 0.33 = $4,620,000,000`。 攻擊者遭到罰沒時會失去這些錢並被逐出以太坊。 若要再次攻擊,他們必須(再次)累積 >33% 的權益,並(再次)將其銷毀。 每次嘗試攻擊網路的成本將超過 46 億美元(以 1000 美元/ETH 和 1400 萬個 ETH 質押量計算)。 攻擊者在被罰沒時也會被驅逐出以太坊,如果他們想再次加入,則需要重新排隊。 這表示重複攻擊的頻率不僅受限於攻擊者累積 >33% 總權益的速率,也受限於將其所有驗證者加入網路所需的時間。 每一次的攻擊都會讓攻擊者變得更窮,而剩餘的社群則得益於供給衝擊的結果而變得更富。
其他攻擊,如 51% 攻擊或是透過 66% 質押總量的最終確定性反轉,都需要更多的以太幣,相對來說也會耗費攻擊者更高的成本。
-下面把權益證明與工作量證明做下比較。 在工作量證明以太坊上,發起攻擊的成本即是持續擁有 >50% 以太幣總算力的成本。 這相當於擁有充足算力的硬件和運行成本,可勝過其他礦工持續計算工作量證明的解的硬體及其運行花費。 在以太坊挖礦主要透過圖形處理單元而不是專用積體電路,這讓成本有所降低(但如果讓以太坊繼續使用工作量證明,專用積體電路挖礦可能已變得更加受歡迎)。 對手會需要購買大量的硬體並支付高昂的電費以攻擊工作量證明,但總成本還是比累積足夠的以太幣以發動攻擊低。 在工作量證明上發動 51% 攻擊要比在權益證明上便宜約[ 20 倍](https://youtu.be/1m12zgJ42dI?t=1562)。 如果攻擊被偵測到,且以太坊透過硬分叉移除了所造成的改變,攻擊者還是可以使用相同的硬體,對新分叉重複發動攻擊。
+下面把權益證明與工作量證明做下比較。 在工作量證明以太坊上發動攻擊的成本,就是持續擁有 >50% 網路總算力的成本。 這相當於擁有充足算力的硬件和運行成本,可勝過其他礦工持續計算工作量證明的解的硬體及其運行花費。 在以太坊挖礦主要透過圖形處理單元而不是專用積體電路,這讓成本有所降低(但如果讓以太坊繼續使用工作量證明,專用積體電路挖礦可能已變得更加受歡迎)。 對手會需要購買大量的硬體並支付高昂的電費以攻擊工作量證明,但總成本還是比累積足夠的以太幣以發動攻擊低。 在工作量證明上發動 51% 攻擊,成本比在權益證明上便宜約 [20 倍](https://youtu.be/1m12zgJ42dI?t=1562)。 如果攻擊被偵測到,且以太坊透過硬分叉移除了所造成的改變,攻擊者還是可以使用相同的硬體,對新分叉重複發動攻擊。
### 複雜性 {#complexity}
@@ -32,11 +32,11 @@ lang: zh-tw
為了能夠安全地開發及測試權益證明的共識邏輯,在以太坊實行權益證明的兩年前就已啟動信標鏈。 信標鏈作為權益證明測試的沙盒,是一條實行權益證明共識邏輯的即時區塊鏈,但不會影響實際以太坊交易,能有效地自行達成共識。 在它持續表現穩定且沒有發生任何錯誤足夠長的時間後,信標鏈被「合併」進以太坊主網中。 這些都能協助降低權益證明的複雜性,讓發生非計畫性後果或用戶端錯誤的風險變得極低。
-### 攻擊媒介 {#attack-surface}
+### 攻擊面 {#attack-surface}
權益證明比工作量證明更複雜,這意味著需要處理更多的攻擊媒介。 與一個連線用戶端的點對點網路不同,權益證明有兩個點對點網路,分別實行不同的協定。 在每個時隙預先選擇一名特定驗證者可能會造成阻斷服務攻擊,其中大量的網路流量會導致該特定驗證者離綫。
-攻擊者還有一些方法可以精心安排其區塊或證明的釋放時間,使它們被特定比例的誠實網路所接收,從而影響他們以特定方式進行投票。 最後,攻擊者可以簡單地累積足夠多的以太幣進行質押,並主導共識機制。 所有這些[攻擊媒介都有相應的防禦措施](/developers/docs/consensus-mechanisms/pos/attack-and-defense),但工作量證明機制下,並未提供這些防禦措施。
+攻擊者還有一些方法可以精心安排其區塊或證明的釋放時間,使它們被特定比例的誠實網路所接收,從而影響他們以特定方式進行投票。 最後,攻擊者可以簡單地累積足夠多的以太幣進行質押,並主導共識機制。 這些[攻擊媒介都有相應的防禦措施](/developers/docs/consensus-mechanisms/pos/attack-and-defense),但在工作量證明機制下,並未提供這些防禦措施。
## 去中心化 {#decentralization}
@@ -62,8 +62,8 @@ lang: zh-tw
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [Vitalik 的權益證明設計理念](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
-- [Vitalik 的權益證明常見問答](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
-- [關於權益證明與工作量證明的「簡介」影片](https://www.youtube.com/watch?v=M3EFi_POhps)
+- [Vitalik 的權益證明常見問題](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
+- [關於 PoS 與 PoW 的「Simply Explained」影片](https://www.youtube.com/watch?v=M3EFi_POhps)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md
index 4327e6c0d60..36f5b0e0de1 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md
@@ -4,7 +4,7 @@ description: 瞭解權益證明以太坊的協定內激勵措施。
lang: zh-tw
---
-以太坊是運用其原生加密貨幣以太幣 (ETH) 來保障安全的。 希望參與驗證區塊和識別鏈頭的節點營運商,需要將以太幣存入以太坊上的[存款合約](/staking/deposit-contract/)。 然後他們將獲得以太幣支付來運作驗證者軟體,檢查在點對點網絡上收到的新區塊的有效性,並套用分叉選擇演算法來辨識鏈頭。
+以太坊是運用其原生加密貨幣以太幣 (ETH) 來保障安全的。 希望參與驗證區塊和識別鏈頭的節點營運商,會將以太幣存入以太坊上的[存款合約](/staking/deposit-contract/)。 然後他們將獲得以太幣支付來運作驗證者軟體,檢查在點對點網絡上收到的新區塊的有效性,並套用分叉選擇演算法來辨識鏈頭。
驗證者有兩個主要角色:1) 檢查新區塊並證明它們的有效性,2) 從全體驗證者池中被隨機選取時提議新的區塊。 如果驗證者在被要求時無法執行上述工作中的任意一個,他們便無法取得以太幣支付。 驗證者有時也會被賦予彙總簽章和參與同步委員會的工作。
@@ -14,53 +14,53 @@ lang: zh-tw
繼續閱讀,以瞭解更多詳情...
-## 獎勵和懲罰 {#rewards}
+## 獎勵與懲罰 {#rewards}
-### 酬勞 {#rewards}
+### 獎勵 {#rewards}
-驗證者獲得獎勵的情景有:當他們與大多數其他驗證者的投票結果一致時,當他們提議區塊時,以及當他們參與同步委員會時。 每個時期的獎勵價值按 `base_reward` 計算。 這是用來計算其他獎勵的基本單位。 `base_reward` 代表一個最佳狀況下的驗證者在每個時期收到的平均獎勵。 這是按以下公式,根據驗證者的有效餘額和活躍驗證者總數來計算的:
+驗證者獲得獎勵的情景有:當他們與大多數其他驗證者的投票結果一致時,當他們提議區塊時,以及當他們參與同步委員會時。 每個時期 (epoch) 的獎勵價值是根據 `base_reward` 計算的。 這是用來計算其他獎勵的基本單位。 `base_reward` 代表在最佳條件下,驗證者每個時期 (epoch) 收到的平均獎勵。 這是按以下公式,根據驗證者的有效餘額和活躍驗證者總數來計算的:
```
base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))
```
-其中 `base_reward_factor` 為 64,`base_rewards_per_epoch` 為 4,`sum(active balance)` 為所有活躍驗證者質押的以太幣總數。
+其中 `base_reward_factor` 為 64,`base_rewards_per_epoch` 為 4,`sum(active balance)` 則為所有活躍驗證者質押的以太幣總數。
-這意味著基本獎勵與驗證者的有效餘額成正比,與網路中的驗證者數量成反比。 驗證者越多,總體發行量越大(`sqrt(N)` 形式),但每個驗證者的 `base_reward` 越小(`1/sqrt(N)` 形式)。 這些因素會影響質押節點的年利率。 閲讀 [Vitalik 的筆記](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards)中與之有關的原理。
+這意味著基本獎勵與驗證者的有效餘額成正比,與網路中的驗證者數量成反比。 驗證者越多,總發行量越大(以 `sqrt(N)` 增長),但每位驗證者的 `base_reward` 越小(以 `1/sqrt(N)` 減少)。 這些因素會影響質押節點的年利率。 請參閱 [Vitalik 的筆記](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards),了解其中的基本原理。
縂獎勵的計算方式為 5 個組成部分的總和,每個部分各有一個權重,決定該組成部分在縂獎勵中的加成。 組成部分包括:
```
-1. source vote: the validator has made a timely vote for the correct source checkpoint
-2. target vote: the validator has made a timely vote for the correct target checkpoint
-3. head vote: the validator has made a timely vote for the correct head block
-4. sync committee reward: the validator has participated in a sync committee
-5. proposer reward: the validator has proposed a block in the correct slot
+1. 來源投票:驗證者對正確的來源檢查點及時投票
+2. 目標投票:驗證者對正確的目標檢查點及時投票
+3. 鏈頭投票:驗證者對正確的鏈頭區塊及時投票
+4. 同步委員會獎勵:驗證者參與了同步委員會
+5. 提案者獎勵:驗證者在正確的時隙中提案了區塊
```
每個組成部分的權重如下:
```
-TIMELY_SOURCE_WEIGHT uint64(14)
-TIMELY_TARGET_WEIGHT uint64(26)
-TIMELY_HEAD_WEIGHT uint64(14)
-SYNC_REWARD_WEIGHT uint64(2)
-PROPOSER_WEIGHT uint64(8)
+TIMELY_SOURCE_WEIGHT uint64(14)
+TIMELY_TARGET_WEIGHT uint64(26)
+TIMELY_HEAD_WEIGHT uint64(14)
+SYNC_REWARD_WEIGHT uint64(2)
+PROPOSER_WEIGHT uint64(8)
```
-這些權重的總和為 64。 獎勵的計算方式為適用權重除以 64 的總和。 及時為來源、目標和鏈頭投票、提議區塊和參與同步委員會的驗證者,可以獲得 `64/64 * base_reward == base_reward`。 不過,驗證者通常不是區塊提議者,因此他們的最大獎勵為 `64-8 /64 * base_reward == 7/8 * base_reward`。 既不是區塊提議者,也沒有參與同步委員會的驗證者,可以獲得 `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`。
+這些權重的總和為 64。 獎勵的計算方式為適用權重除以 64 的總和。 及時為來源、目標和鏈頭投票、提案區塊並參與同步委員會的驗證者,可以收到 `64/64 * base_reward == base_reward`。 然而,驗證者通常不是區塊提案者,所以其最高獎勵為 `64-8 /64 * base_reward == 7/8 * base_reward`。 既不是區塊提案者,也不在同步委員會中的驗證者,可以獲得 `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`。
-以太坊還新增了一個額外獎勵來激勵快速證明。 它就是 `inclusion_delay_reward`。 該獎勵的值等於 `base_reward` 乘以 `1/delay`,其中 `delay` 是分隔區塊提議和證明的時隙數。 例如,如果在區塊提議的一個時隙内提交證明,證明者就會獲得 `base_reward * 1/1 == base_reward`。 如果證明在下個時隙到達,證明者就會獲得 `base_reward * 1/2`,依此類推。
+以太坊還新增了一個額外獎勵來激勵快速證明。 這就是 `inclusion_delay_reward`。 它的值等於 `base_reward` 乘以 `1/delay`,其中 `delay` 是區塊提案與證明之間的時隙數。 例如,如果在區塊提案後的一個時隙內提交證明,證明者會收到 `base_reward * 1/1 == base_reward`。 如果證明在下一個時隙到達,證明者會收到 `base_reward * 1/2`,依此類推。
-包含在區塊内的**每個有效證明**都會讓區塊提議者獲得 `8 / 64 * base_reward`,因此實際獎勵的價值與證明驗證者的數量成正比。 區塊提議者也可以透過在提議的區塊中包含其他驗證者不良行爲的證據來增加其獎勵。 這些獎勵是鼓勵驗證者保持誠實的「紅蘿蔔」。 包含罰沒的區塊提議者將獲得 `slashed_validators_effective_balance / 512`。
+區塊提案者會因區塊中包含的**每個有效證明**而收到 `8 / 64 * base_reward`,所以獎勵的實際價值與進行證明的驗證者數量成正比。 區塊提議者也可以透過在提議的區塊中包含其他驗證者不良行爲的證據來增加其獎勵。 這些獎勵是鼓勵驗證者保持誠實的「紅蘿蔔」。 包含罰沒的區塊提案者將獲得 `slashed_validators_effective_balance / 512` 的獎勵。
### 懲罰 {#penalties}
到目前爲止,我們已經考慮了行爲良好的驗證者,但對於那些沒有及時為鏈頭、來源和目標投票或投票速度非常慢的驗證者,應該怎樣做呢?
-錯過目標和來源投票的懲罰等同於證明者提交它們時獲得的獎勵。 這意味不會有獎勵新增到他們的餘額中,反而會從餘額中移除相應的價值。 錯過鏈頭投票不會受到懲罰(即鏈頭投票只會獲得獎勵,不會受到懲罰)。 也沒有與 `inclusion_delay` 相關的懲罰 - 只是不會新增獎勵到驗證者的餘額中。 未能提議區塊也不會受到懲罰。
+錯過目標和來源投票的懲罰等同於證明者提交它們時獲得的獎勵。 這意味不會有獎勵新增到他們的餘額中,反而會從餘額中移除相應的價值。 錯過鏈頭投票沒有懲罰(即鏈頭投票只會獲得獎勵,從不懲罰)。 `inclusion_delay` 沒有相關懲罰,獎勵只是不會加到驗證者的餘額中。 未能提議區塊也不會受到懲罰。
-閱讀[共識規範](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md)中有關獎勵和懲罰的更多資訊。 獎勵和懲罰在 Bellatrix 升級中進行了調整 - 在[以太坊改善提議解讀視頻](https://www.youtube.com/watch?v=iaAEGs1DMgQ)中觀看 Danny Ryan 和 Vitalik 關於此話題的討論。
+在[共識規格](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md)中閱讀更多關於獎勵與懲罰的資訊。 獎勵與懲罰在 Bellatrix 升級中進行了調整,敬請觀看 Danny Ryan 和 Vitalik 在 [Peep an EIP 影片](https://www.youtube.com/watch?v=iaAEGs1DMgQ) 中的討論。
## 罰沒 {#slashing}
@@ -70,21 +70,22 @@ PROPOSER_WEIGHT uint64(8)
- 證明一個「包圍」了另一個區塊的區塊(有效地改變歷史記錄)
- 透過證明同一區塊的兩個候選區塊進行「雙重投票」
-如果偵測到這些行爲,驗證者將被罰沒。 這意味著他們質押的以太幣的 1/32(最多不超過 1 枚以太幣)將被立即銷毀,然後開始為期 36 天的驅逐期。 在驅逐期内,驗證者的質押會逐漸流失。 在中間點(第 18 天),會有一項額外的懲罰,其力度與罰沒事件前 36 天内所有被罰沒驗證者的縂質押以太幣成正比。 這意味著當有更多驗證者被罰沒時,罰沒的力度就會增加。 最大罰沒力度是所有被罰沒驗證者的全部有效餘額(即如果有很多驗證者被罰沒,他們將失去全部質押)。 另一方面,一次孤立的罰沒事件只會銷毀驗證者質押的一小部分。 這個與被罰沒驗證者的數量成正比的中間點懲罰稱爲「相關性懲罰」。
+如果偵測到這些行爲,驗證者將被罰沒。 這代表,對於一個擁有 32 ETH 的驗證者,0.0078125 ETH 會被立即銷毀(與活躍餘額成線性比例),然後開始為期 36 天的移除期。 在驅逐期内,驗證者的質押會逐漸流失。 在中間點(第 18 天),會有一項額外的懲罰,其力度與罰沒事件前 36 天内所有被罰沒驗證者的縂質押以太幣成正比。 這意味著當有更多驗證者被罰沒時,罰沒的力度就會增加。 最高罰沒金額為所有被罰沒驗證者的全部有效餘額(也就是說,如果有大量驗證者被罰沒,他們可能會失去全部質押)。 另一方面,一次孤立的罰沒事件只會銷毀驗證者質押的一小部分。 這個與被罰沒驗證者的數量成正比的中間點懲罰稱爲「相關性懲罰」。
-## 怠惰逐減懲罰 {#inactivity-leak}
+## 非活躍懲罰 {#inactivity-leak}
如果共識層未能在四個時期内最終確定,一種稱爲「怠惰逐減懲罰」的應急協定將會啓用。 怠惰逐減懲罰的最終目標是為鏈恢復最終確定性創造條件。 如上所述,最終確定需要 2/3 的多數縂質押以太幣同意來源和目標檢查點。 如果超過 1/3 的總計驗證者離綫或未能提交正確的證明,就不可能有 2/3 的絕對多數來最終確定檢查點。 怠惰逐減懲罰使不活躍驗證者的質押逐漸流失,直至他們控制的質押少於質押縂量的 1/3,使剩餘的活躍驗證者可以最終確定鏈。 無論不活躍驗證者的池有多大,剩餘的活躍驗證者最終都會控制超過 2/3 的質押。 質押的損失是促使不活躍驗證者儘快重新活躍的强大激勵措施。 Medalla 測試網上曾出現過一個怠惰逐減懲罰案例,當時不到 66% 的活躍驗證者成功在最新區塊鏈鏈頭達成共識。 怠惰逐減懲罰被啟動,最後重新獲得了最終確定性!
共識機制中的獎勵、懲罰與罰沒設計,都是鼓勵個人驗證者正確行事。 然而,從這些設計選擇中形成了一個系統,强烈激勵在多個用戶端平等分配驗證者,並且强烈抑制單一用戶端取得主導地位。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [升級以太坊:激勵層](https://eth2book.info/altair/part2/incentives)
-- [以太坊混合 Casper 協定中的激勵措施](https://arxiv.org/pdf/1903.04205.pdf)
-- [Vitalik 的規範註解](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1)
-- [以太坊 2 罰沒預防技巧](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50)
+- [以太坊混合式 Casper 協定中的激勵機制](https://arxiv.org/pdf/1903.04205.pdf)
+- [Vitalik 的規格註解](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1)
+- [Eth2 罰沒預防秘訣](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50)
+- [EIP-7251 下的罰沒懲罰分析](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509)
-_資源_
+_資料來源_
- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md
index d2aab3c1fc4..484036d093d 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md
@@ -6,9 +6,9 @@ lang: zh-tw
區塊鏈中的主觀性是指依賴社交資訊來達成對當前狀態的共識。 可能有多個有效分叉,可根據從網路上其他對等節點收集而來的資訊進行選擇。 主觀性的反面是客觀性,是指只存在唯一一條可能有效的鏈,所有節點都需要透過套用其程式碼規則達成共識。 還有第三種狀態,稱為弱主觀性。 這是指在擷取一些初始社交資訊種子後,可以客觀地繼續運作的區塊鏈。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-要理解本頁內容,需先理解[權益證明](/developers/docs/consensus-mechanisms/pos/)的基礎知識。
+若要了解本頁內容,必須先了解[權益證明](/developers/docs/consensus-mechanisms/pos/)的基礎知識。
## 弱主觀性解決了什麼問題? {#problems-ws-solves}
@@ -30,10 +30,10 @@ lang: zh-tw
最後,可以從其他節點要求檢查點;或許另一個運作全節點的以太坊使用者可以提供一個檢查點,然後由驗證者比對來自區塊瀏覽器的資料進行驗證。 整體來說,信任弱主觀性檢查點的提供者被認為跟信任用戶端開發者一樣存在問題。 需要的整體信任很低。 值得注意的是,只有當大多數驗證者串謀產生區塊鏈的另一個分叉這種微乎其微的情況下,上述考量才會變得非常重要。 其他情況下,只有一個以太坊鏈可供選擇。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊 2.0 中的弱主觀性](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2)
-- [Vitalik:我如何愛上弱主觀性](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
-- [弱主觀性(Teku 文件)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/)
+- [Eth2 中的弱主觀性](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2)
+- [Vitalik:我是如何學會愛上弱主觀性的](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
+- [弱主觀性 (Teku 文件)](https://docs.teku.consensys.io/concepts/weak-subjectivity)
- [階段 0 弱主觀性指南](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md)
-- [以太坊 2.0 中的弱主觀性分析](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf)
+- [以太坊 2.0 弱主觀性分析](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md
new file mode 100644
index 00000000000..2a745c16709
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md
@@ -0,0 +1,64 @@
+---
+title: 提款憑證
+description: 驗證程式提款憑證類型 (0x00、0x01、0x02) 及其對以太坊質押者之影響的說明。
+lang: zh-tw
+---
+
+每個驗證程式都有一個**提款憑證**,此憑證會決定其所質押的 ETH 和酬勞將如何以及在何處提領。 憑證類型由第一個位元組表示:`0x00`、`0x01` 或 `0x02`。 了解這些類型對於管理質押的驗證程式來說很重要。
+
+## 0x00:Shapella 升級前的憑證 {#0x00-credentials}
+
+`0x00` 類型是 Shapella 升級 (2023 年 4 月) 前的原始提款憑證格式。 擁有此憑證類型的驗證程式沒有設定執行層提款地址,這表示他們的資金仍鎖定在共識層。 如果您仍擁有 `0x00` 憑證,則必須先升級至 `0x01` 或 `0x02`,才能收到任何提款。
+
+## 0x01:舊版提款憑證 {#0x01-credentials}
+
+`0x01` 類型是隨著 Shapella 升級所推出,並成為想設定執行層提款地址的驗證程式的標準。 使用 `0x01` 憑證:
+
+- 任何超過 32 ETH 的餘額都會**自動撥付**到您的提款地址
+- 完整退場會經過標準退場佇列
+- 超過 32 ETH 的酬勞無法複利 — 它們會定期被撥出
+
+\*\*為何有些驗證程式仍使用 0x01:\*\*因為它更簡單、更熟悉。 許多驗證程式在 Shapella 升級後存入資金,且已經是此類型,對於那些想要自動提領超額餘額的人來說,它運作良好。
+
+\*\*為何不推薦使用:\*\*使用 `0x01`,您會失去將超過 32 ETH 的酬勞進行複利的能力。 每分超額的資金都會被自動撥走,這限制了您驗證程式的獲利潛力,且需要另外管理已提領的資金。
+
+## 0x02:複利提款憑證 {#0x02-credentials}
+
+`0x02` 類型隨 Pectra 升級推出,是當今驗證程式的**推薦選擇**。 擁有 `0x02` 憑證的驗證程式有時被稱為「複利驗證程式」。
+
+使用 `0x02` 憑證:
+
+- 超過 32 ETH 的酬勞會以 1 ETH 的增量進行**複利**,直到最高有效餘額 2048 ETH
+- 部分提款必須手動申請 (自動撥付只會在超過 2048 ETH 的閾值時發生)。
+- 驗證程式可以將多個 32 ETH 的驗證程式整合為一個餘額更高的單一驗證程式。
+- 仍支援透過標準退場佇列進行完整退場。
+
+部分提款與整合都可以透過 [Launchpad 驗證程式操作](https://launchpad.ethereum.org/en/validator-actions) 執行。
+
+\*\*為何驗證程式應偏好 0x02:\*\*它透過複利提供更高的資金效率、對提款時機有更多的控制權,並支援驗證程式整合。 對於隨著時間累積酬勞的個人質押者來說,這表示他們的有效餘額 — 以及他們的酬勞 — 可以在無需手動干預的情況下增長超過 32 ETH。
+
+\*\*重要事項:\*\*一旦您從 `0x01` 轉換為 `0x02`,就無法再轉回。
+
+關於轉換為類型 2 憑證和 MaxEB 功能的詳細指南,請參閱 [MaxEB 說明頁面](/roadmap/pectra/maxeb/)。
+
+## 我該選哪個? {#what-should-i-pick}
+
+- \*\*新的驗證程式:\*\*選擇 `0x02`。 它是現代標準,具有更好的複利效果和靈活性。
+- \*\*現有 0x01 驗證程式:\*\*如果您希望酬勞複利超過 32 ETH,或計畫整合驗證程式,請考慮轉換為 `0x02`。
+- \*\*現有 0x00 驗證程式:\*\*立即升級 — 未更新憑證即無法提款。 您必須先轉換為 `0x01`,然後才能轉換為 `0x02`。
+
+## 管理提款憑證的工具 {#withdrawal-credential-tools}
+
+有幾種工具支援在不同憑證類型之間選擇或轉換:
+
+- **[Ethereum 質押啟動面板](https://launchpad.ethereum.org/en/validator-actions)** - 用於存款和驗證程式管理的官方工具,包括憑證轉換和整合。
+- **[Pectra Staking Manager](https://pectrastaking.com)** - 支援錢包連接的網頁使用者介面,可用於轉換和整合。
+- **[Pectra Validator Ops CLI Tool](https://github.com/Luganodes/Pectra-Batch-Contract)** - 用於批次轉換的命令列工具。
+- **[Ethereal](https://github.com/wealdtech/ethereal)** - 用於以太坊操作的命令列介面工具,包括驗證程式管理。
+
+關於整合工具的完整清單和詳細的轉換說明,請參閱 [MaxEB 整合工具](/roadmap/pectra/maxeb/#consolidation-tooling)。
+
+## 延伸閱讀 {#further-reading}
+
+- [權益證明以太坊中的金鑰](/developers/docs/consensus-mechanisms/pos/keys/) - 了解驗證程式金鑰以及它們與提款憑證的關係。
+- [MaxEB](/roadmap/pectra/maxeb/) - 關於 Pectra 升級和最大有效餘額功能的詳細指南。
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md
index 1a0b8ff06a0..7f953f3f611 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md
@@ -4,7 +4,7 @@ description: 解釋工作量證明共識協定及其在以太坊中的作用。
lang: zh-tw
---
-在以太坊網路的初期,我們使用一種涉及**[工作量證明 (PoW)](/developers/docs/consensus-mechanisms/pow)** 的共識機制。 這個機制讓以太坊網路的節點對所有在以太坊區塊鏈上紀錄的資訊的狀態達成共識,並可防範某些種類的經濟攻擊。 但是,以太坊於 2022 年停止使用工作量證明,並轉為使用[權益證明](/developers/docs/consensus-mechanisms/pos)。
+以太坊網路最初使用一種涉及\*\*[工作量證明 (PoW)](/developers/docs/consensus-mechanisms/pow)\*\*的共識機制。 這個機制讓以太坊網路的節點對所有在以太坊區塊鏈上紀錄的資訊的狀態達成共識,並可防範某些種類的經濟攻擊。 然而,以太坊於 2022 年停用工作量證明,並改為使用[權益證明](/developers/docs/consensus-mechanisms/pos)。
@@ -15,31 +15,31 @@ lang: zh-tw
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更好地理解本頁內容,我們推薦你先閱讀[交易](/developers/docs/transactions/)、[區塊](/developers/docs/blocks/)及[共識機制](/developers/docs/consensus-mechanisms/)。
+為了更好地理解本頁內容,我們建議你先熟悉 [交易](/developers/docs/transactions/)、[區塊](/developers/docs/blocks/) 和 [共識機制](/developers/docs/consensus-mechanisms/) 等概念。
## 什麼是工作量證明 (PoW)? {#what-is-pow}
-中本聰共識採用工作量證明,這是一種機制,一度允許去中心化的以太坊網路對帳戶餘額和交易順序等達成共識(即所有節點都同意)。 這種機制防止使用者「重複支付」他們的代幣,同時確保以太坊區塊鏈極難攻擊或操控。 這些安全特性現在來自權益證明,而不是使用被稱為 [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) 的共識機制。
+中本聰共識採用工作量證明,此機制一度允許去中心化的以太坊網路,就帳戶餘額和交易順序等事項達成共識 (即所有節點都同意)。 這種機制防止使用者「重複支付」他們的代幣,同時確保以太坊區塊鏈極難攻擊或操控。 現在,這些安全屬性改為由權益證明提供,其使用的共識機制即為 [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)。
-## 工作量證明 (PoW) 與挖礦 {#pow-and-mining}
+## 工作量證明與挖礦 {#pow-and-mining}
工作量證明是一種基礎演算法,它為礦工在工作量證明區塊鏈上進行的工作設定難度和規則。 挖礦即為「工作」本身。 此行為指新增合法區塊於區塊鏈。 這很重要,因為鏈的長度有助於網路跟隨區塊鏈的正確分叉。 達成的「工作」越多,區塊鏈越長,而隨著區塊數量增加,當前網路狀態之確定性也隨之提高。
-[更多挖礦相關訊息](/developers/docs/consensus-mechanisms/pow/mining/)
+[更多關於挖礦的資訊](/developers/docs/consensus-mechanisms/pow/mining/)
## 以太坊的工作量證明 (PoW) 如何運作? {#how-it-works}
以太坊交易被處理至區塊中。 在現已棄用的工作量證明以太坊中,每個區塊包含:
- 區塊難度 -– 例如: 3,324,092,183,262,715
-- mixHash(混合雜湊)– 例如: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
-- 隨機數 – 例如:`0xd3ee432b4fb3d26b`
+- mixHash – 例如:`0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
+- nonce – 例如:`0xd3ee432b4fb3d26b`
該區塊資料與工作量證明直接相關。
-### 工作量證明機制 {#the-work}
+### 工作量證明中的「工作」{#the-work}
工作量證明協定 Ethash 要求礦工經過激烈的試錯競賽,找出一個區塊的隨機數。 只有具備有效隨機數的區塊才能新增到鏈中。
@@ -49,7 +49,7 @@ lang: zh-tw
雜湊使詐欺行為更容易被發現。 此外,工作量證明過程也大大遏制了對區塊鏈的攻擊。
-### 工作量證明和安全性 {#security}
+### 工作量證明與安全性 {#security}
曠工會因為在以太坊主鏈上進行這項工作而得到獎勵。 對部分礦工而言,令他們去建立自己的新鏈的動機微乎其微,因為這會損害主鏈系統。 區塊鏈信賴基於單一狀態,並以此作為真實性來源。
@@ -61,29 +61,29 @@ lang: zh-tw
工作量證明還負責發行新貨幣至系統中,獎勵礦工參與挖礦工作。
-自[君士坦丁堡升級](/ethereum-forks/#constantinople)以來,成功建立區塊的礦工將獲得兩枚新鑄造的以太幣及部分交易費作為獎勵。 Ommer 區塊也會補償 1.75 枚以太幣。 Ommer 區塊是由一個礦工與另一個建立了規範區塊的曠工幾乎同時建立的有效區塊,規範區塊最終取決於首先在其上建置的鏈。 Ommer 區塊通常是因網路延遲而發生。
+自 [Constantinople 升級](/ethereum-forks/#constantinople) 以來,成功創建區塊的礦工會獲得 2 枚新鑄造的 ETH 和部分礦工費作為獎勵。 Ommer 區塊也會補償 1.75 枚以太幣。 Ommer 區塊是由一個礦工與另一個建立了規範區塊的曠工幾乎同時建立的有效區塊,規範區塊最終取決於首先在其上建置的鏈。 Ommer 區塊通常是因網路延遲而發生。
-## 最終確定性 {#finality}
+## 最終性 {#finality}
當一筆交易成為無法改變的區塊的一部分時,它便在以太坊上擁有了「最終確定性」。
由於礦工是以去中心化的方式工作,所以有可能同時生成兩個有效的區塊。 這會建立一個暫時性的分叉。 最終,後繼區塊挖掘出來並新增至其中一條鏈,這使得它變得更長,並成為被採用的鏈。
-但更複雜的是,臨時分叉上被拒絕的交易可能尚未包含在被採用的鏈上。 此代表其交易結果可能被逆轉。 因此,最終確定性是指在認定交易完全不可逆前需要等待的時間。 在先前的工作量證明以太坊下,於特定區塊 `N` 上開采的區塊越多,`N` 中交易成功且不會被逆轉的置信度就越高。 現在,透過權益證明機制,最終確定性成為區塊的顯式屬性,而非機率屬性。
+但更複雜的是,臨時分叉上被拒絕的交易可能尚未包含在被採用的鏈上。 此代表其交易結果可能被逆轉。 因此,最終確定性是指在認定交易完全不可逆前需要等待的時間。 在先前的工作量證明以太坊中,於特定區塊 `N` 之上挖出的區塊越多,`N` 中的交易成功且不會被還原的可信度就越高。 現在,透過權益證明機制,最終確定性成為區塊的顯式屬性,而非機率屬性。
## 工作量證明的能源用量 {#energy}
-工作量證明面臨的一個重大非議在於,為保障網路安全所需要的巨大能源消耗量。 為了維持安全性和去中心化,採用工作量證明的以太坊每年都要消耗大量能源。 在過渡到權益證明的前夕,以太坊礦工每年總共消耗約 70 太瓦時的能源(大約與捷克共和國的能源消耗相當 - 資料來自 2022 年 7 月 18 日的 [digiconomist](https://digiconomist.net/))。
+工作量證明面臨的一個重大非議在於,為保障網路安全所需要的巨大能源消耗量。 為了維持安全性和去中心化,採用工作量證明的以太坊每年都要消耗大量能源。 在轉換為權益證明前不久,以太坊礦工每年總共消耗約 70 TWh/yr 的電力 (約與捷克共和國相當 — 根據 [digiconomist](https://digiconomist.net/) 於 2022 年 7 月 18 日的資料)。
-## 優勢及劣勢 {#pros-and-cons}
+## 優點和缺點 {#pros-and-cons}
-| 優勢 | 劣勢 |
-| ---------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
-| 工作量證明為中性。 無須任何以太幣就能參與,而區塊獎勵可讓你從 0 以太幣積累正餘額。 相反,於[權益證明](/developers/docs/consensus-mechanisms/pos/)系統,你需要以太幣才能參與。 | 工作量證明消耗巨量能源,對環境造成傷害。 |
-| 工作量證明採用試錯型共識機制,已長年確保比特幣及以太坊之安全和去中心化。 | 若要參與挖礦,需要大筆先期投資,購買專業挖礦設備。 |
-| 相較於權益證明,工作量證明更易於實作。 | 因算力需求增加,挖礦工作可能被少數有權勢的挖礦池所霸佔,引發去中心化及安全性風險。 |
+| 優勢 | 劣勢 |
+| -------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
+| 工作量證明為中性。 無須任何以太幣就能參與,而區塊獎勵可讓你從 0 以太幣積累正餘額。 使用[權益證明](/developers/docs/consensus-mechanisms/pos/),你一開始需要持有 ETH。 | 工作量證明消耗巨量能源,對環境造成傷害。 |
+| 工作量證明採用試錯型共識機制,已長年確保比特幣及以太坊之安全和去中心化。 | 若要參與挖礦,需要大筆先期投資,購買專業挖礦設備。 |
+| 相較於權益證明,工作量證明更易於實作。 | 因算力需求增加,挖礦工作可能被少數有權勢的挖礦池所霸佔,引發去中心化及安全性風險。 |
-## 相較於權益證明 {#compared-to-pos}
+## 與權益證明比較 {#compared-to-pos}
於高層面來看,權益證明與工作量證明具同一目標:協助去中心化網路達成共識並確保其安全。 但其過程和人員有所不同:
@@ -92,23 +92,23 @@ lang: zh-tw
- 驗證者無須相互競爭以建立區塊,相反,他們將由演算法隨機選擇。
- 最終確定性更加明瞭:於特定檢查點,若三分之二的驗證者同意此區塊狀態,則視其為最終確定。 驗證者須賭上全部質押,所以當他們試圖串通一氣時,將會損失全部質押。
-[更多詳情關於質押證明(PoS)](/developers/docs/consensus-mechanisms/pos/)
+[更多關於權益證明的資訊](/developers/docs/consensus-mechanisms/pos/)
-## 想透過實際視覺學習? {#visual-learner}
+## 想透過視覺方式學習? {#visual-learner}
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [多數攻擊](https://en.bitcoin.it/wiki/Majority_attack)
-- [決議最終確定性](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
+- [關於結算最終性](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
### 影片 {#videos}
-- [關於工作量證明協定的技術說明](https://youtu.be/9V1bipPkCTU)
+- [工作量證明協定的技術說明](https://youtu.be/9V1bipPkCTU)
## 相關主題 {#related-topics}
- [挖礦](/developers/docs/consensus-mechanisms/pow/mining/)
-- [持有量證明(又稱:權益證明)](/developers/docs/consensus-mechanisms/pos/)
+- [權益證明](/developers/docs/consensus-mechanisms/pos/)
- [權威證明](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/index.md
index 429b8541330..b93cf4e7184 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/index.md
@@ -13,9 +13,9 @@ lang: zh-tw
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更好地理解本頁面,建議你先閱讀[交易](/developers/docs/transactions/)、[區塊](/developers/docs/blocks/)及[工作量證明](/developers/docs/consensus-mechanisms/pow/)。
+為了更了解此頁面,我們建議您先閱讀[交易](/developers/docs/transactions/)、[區塊](/developers/docs/blocks/) 和[工作量證明](/developers/docs/consensus-mechanisms/pow/)。
## 什麼是以太坊挖礦? {#what-is-ethereum-mining}
@@ -31,7 +31,7 @@ lang: zh-tw
在以太坊這樣的去中心化機制中,我們須確保所有參與者同意統一的交易順序。 礦工透過解決計算難題來產出區塊,保護網路免受攻擊,幫助實現這個目標。
-[有關工作量證明的更多資訊](/developers/docs/consensus-mechanisms/pow/)
+[更多關於工作量證明](/developers/docs/consensus-mechanisms/pow/)
以前任何人都能使用自己的電腦在以太坊網路上挖礦。 然而,並非每個人都能透過挖以太幣 (ETH) 而獲利。 在大多數情況下,礦工必須購買專用電腦硬體,並要使用廉價能源。 普通電腦不太可能獲得足夠的區塊獎勵來支付相關挖礦成本。
@@ -42,32 +42,32 @@ lang: zh-tw
- 如果你在礦池中挖礦,這些礦池通常會對礦池產生的每個區塊收取固定百分比的費用
- 支援挖礦設備的潛在設備成本(通風、能源監控和電力拉線等等)
-為深入了解挖礦收益,推薦使用挖礦計算機,例如 [Etherscan](https://etherscan.io/ether-mining-calculator) 提供的挖礦計算機。
+若要進一步探索挖礦的獲利能力,請使用挖礦計算機,例如 [Etherscan](https://etherscan.io/ether-mining-calculator) 提供的計算機。
-## 以太坊交易是如何挖掘的 {#how-ethereum-transactions-were-mined}
+## 以太坊交易是如何被挖出的 {#how-ethereum-transactions-were-mined}
-以下概述如何在以太坊工作量證明中挖掘交易。 可以在[此處](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos)找到以太坊權益證明下該過程的類比描述。
+以下概述如何在以太坊工作量證明中挖掘交易。 您可以在[此處](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos)找到以太坊權益證明流程的類似說明。
-1. 使用者編寫[交易](/developers/docs/transactions/)請求,並用某個[帳戶](/developers/docs/accounts/)之私密金錀簽署此交易請求。
-2. 使用者從某個[節點](/developers/docs/nodes-and-clients/)廣播交易請求至全體以太坊網路。
+1. 使用者用某個[帳戶](/developers/docs/accounts/)的私密金鑰撰寫並簽署[交易](/developers/docs/transactions/)請求。
+2. 使用者從某個[節點](/developers/docs/nodes-and-clients/)將交易請求廣播到整個以太坊網路。
3. 當接收到新交易請求時,以太坊網路中的每個節點新增該請求至其本機記憶體池,這是他們已在區塊中收到但尚未提交至區塊鏈的所有交易請求的清單。
-4. 一定時間後,挖礦節點匯總數十或數百筆交易請求到一個潛在的[區塊](/developers/docs/blocks/),其通常藉由某一方法,在區塊燃料限制範圍內賺取最大化[交易費](/developers/docs/gas/)。 挖礦節點接著:
- 1. 驗證每個交易請求的有效性(即,沒人試圖從還沒有為其產生簽名的帳戶轉出以太幣,請求沒有格式錯誤,等等),然後執行請求程式碼,更改其本機以太坊虛擬機副本的狀態。 對於每個傳送到其帳戶的此類交易請求,礦工將取得交易費作為獎勵。
+4. 在某個時間點,挖礦節點會將數十或數百個交易請求匯總成一個潛在的[區塊](/developers/docs/blocks/),此方式會在不超過區塊 Gas 上限的情況下,最大化他們賺取的[礦工費](/developers/docs/gas/)。 挖礦節點接著:
+ 1. 驗證每筆交易請求的有效性 (亦即,沒有人試圖從他們尚未簽署的帳戶轉出以太幣、請求格式沒有錯誤等),然後執行請求的程式碼,改變他們本機 EVM 副本的狀態。 對於每個傳送到其帳戶的此類交易請求,礦工將取得交易費作為獎勵。
2. 一旦區塊中的所有交易請求都已在本機以太坊虛擬機副本上驗證並執行,為潛在區塊產生工作量證明「合法性證書」的過程便會開始。
5. 最終,礦工將完成區塊證書的產生,該區塊中包括我們的特定交易請求。 接著礦工廣播此完成的區塊,其中包括上述證書和宣稱的新以太坊虛擬機狀態的校驗和。
6. 其他節點接收到此新區塊。 它們會驗證證書,自行執行區塊中的所有交易(包括最初由你的使用者廣播的交易),並驗證在執行所有交易後,其新的以太坊虛擬機狀態之校驗和是否與曠工區塊所宣稱的狀態之校驗和相符。 僅當此時,這些節點才會附加此區塊於其區塊鏈的尾部,並接受新的以太坊虛擬機狀態作為規範化狀態。
7. 各節點從其本機未履行之交易請求記憶體池中移除新區塊中的所有交易。
8. 加入網路的新節點依序下載所有區塊,包括包含我們感興趣的交易的區塊。 他們會初始化一個本機以太坊虛擬機副本(始於空白狀態的以太坊虛擬機),接著開始執行其本機以太坊虛擬機副本之上每個區塊中的每筆交易,驗證期間每個區塊的狀態校驗和。
-每筆交易只被挖掘一次(包含在新區塊中並首次傳播),但在推進規範化以太坊虛擬機狀態的過程中會被每個參與者執行並驗證。 這強調了區塊鏈的中心信念之一:**不信任,而是驗證**。
+每筆交易只被挖掘一次(包含在新區塊中並首次傳播),但在推進規範化以太坊虛擬機狀態的過程中會被每個參與者執行並驗證。 這突顯了區塊鏈的核心理念之一:**不要信任,而去驗證**。
-## Ommer(叔)區塊 {#ommer-blocks}
+## Ommer (叔) 塊 {#ommer-blocks}
-基於工作量證明的區塊挖掘具有概率性,這意味著有時由於網路延遲,會同時發布兩個有效區塊。 在這種情況下,協定必須確定最長(因此也是最「有效」)的鏈,同時透過針對已提交但未被包含的有效區塊給予部分獎勵,來確保對曠工的公平性。 這促使網路進一步去中心化,因為小規模礦工可能面臨更大的延遲,但仍然可以透過 [Ommer](/glossary/#ommer) 區塊獎勵獲得回報。
+基於工作量證明的區塊挖掘具有概率性,這意味著有時由於網路延遲,會同時發布兩個有效區塊。 在這種情況下,協定必須確定最長(因此也是最「有效」)的鏈,同時透過針對已提交但未被包含的有效區塊給予部分獎勵,來確保對曠工的公平性。 這鼓勵了網路進一步去中心化,因為面臨較大延遲的小礦工,仍然可以透過 [ommer](/glossary/#ommer) 區塊獎勵產生回報。
-對於父區塊的兄弟姐妹區塊來說,「ommer/兄弟姐妹」一詞是首選的不分性別的詞,但有時也被稱為「uncle/叔」塊。 **自以太坊過渡至權益證明以來,就沒有繼續挖掘 Ommer 區塊了**,因為現在每個時隙只會選出一名提交者。 你能透過查看已挖掘 Ommer 區塊的[歷史圖表](https://ycharts.com/indicators/ethereum_uncle_rate)來了解這項變更。
+對於父區塊的兄弟姐妹區塊來說,「ommer/兄弟姐妹」一詞是首選的不分性別的詞,但有時也被稱為「uncle/叔」塊。 **自從以太坊轉向權益證明後,就不再挖出 Ommer 區塊**,因為每個時隙只會選出一個提案者。 您可以透過查看已挖出的 Ommer 區塊的[歷史圖表](https://ycharts.com/indicators/ethereum_uncle_rate)來了解此變化。
-## 視覺範例 {#a-visual-demo}
+## 視覺化示範 {#a-visual-demo}
觀看影片,Austin 會帶你了解挖礦與工作量證明區塊鏈。
@@ -75,12 +75,12 @@ lang: zh-tw
## 挖礦演算法 {#mining-algorithm}
-以太坊主網只使用過一種挖礦演算法 -[「Ethash」](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/)。 Ethash 是原始研發演算法(稱為[「Dagger-Hashimoto」](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/))的後繼者。
+以太坊主網只使用過一種挖礦演算法-['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/)。 Ethash 是原始研發演算法 ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) 的後繼演算法。
-[更多關於挖礦演算法的資訊](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/)。
+[更多關於挖礦演算法的資訊](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/).
## 相關主題 {#related-topics}
-- [燃料](/developers/docs/gas/)
-- [以太坊虛擬機器 (EVM)](/developers/docs/evm/)
+- [Gas](/developers/docs/gas/)
+- [EVM](/developers/docs/evm/)
- [工作量證明](/developers/docs/consensus-mechanisms/pow/)
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
index 44aa64f7ad6..a5d87179a56 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
@@ -4,24 +4,24 @@ description: Dagger-Hashimoto 演算法詳細介紹。
lang: zh-tw
---
-Dagger-Hashimoto 是以太坊挖礦演算法的原始研究實作和規範。 Dagger-Hashimoto 已被 [Ethash](#ethash) 取代。 在 2022 年 9 月 15 日部署的[合併](/roadmap/merge/)後,挖礦已徹底關閉。 此後,以太坊改用[權益證明](/developers/docs/consensus-mechanisms/pos)機制來保障安全。 本頁面展示歷史相關內容,其中的資訊與合併後的以太坊不再相關。
+Dagger-Hashimoto 是以太坊挖礦演算法的原始研究實作和規範。 Dagger-Hashimoto 已被 [Ethash](#ethash) 取代。 在 2022 年 9 月 15 日的 [合併](/roadmap/merge/) 之後,挖礦已徹底關閉。 此後,以太坊改用 [權益證明](/developers/docs/consensus-mechanisms/pos) 機制來保障安全。 本頁面展示歷史相關內容,其中的資訊與合併後的以太坊不再相關。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更好地理解本頁面內容,建議提前閱讀[工作量證明共識](/developers/docs/consensus-mechanisms/pow)、[挖礦](/developers/docs/consensus-mechanisms/pow/mining)和[挖礦演算法](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms)。
+為了更深入了解本頁內容,我們建議您先閱讀關於 [工作量證明共識](/developers/docs/consensus-mechanisms/pow)、[挖礦](/developers/docs/consensus-mechanisms/pow/mining) 以及 [挖礦演算法](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) 的資訊。
## Dagger-Hashimoto {#dagger-hashimoto}
Dagger-Hashimoto 旨在實現兩個目標:
-1. **專用積體電路抗性 **:為演算法打造專用硬體的益處應盡可能地小
-2. **輕量用戶端可驗證性**:區塊應能被輕量用戶端高效驗證。
+1. **專用積體電路抗性**:為演算法打造專用硬體的益處應盡可能地小。
+2. **輕量用戶端可驗證性**:區塊應能被輕量用戶端高效驗證。
在進一步修改後,我們還要具體說明如何在必要時實現第三個目標,但要以增加複雜性為代價:
**完整鏈儲存**:挖礦需要儲存完整的區塊鏈狀態(由於以太坊狀態樹的結構不規則,我們預計將有可能進行一些修剪,特別是一些經常用到的合約,但我們希望盡量減少這種情況)。
-## 有向無環圖的產生 {#dag-generation}
+## DAG 產生 {#dag-generation}
以下演算法程式碼將以 Python 定義。 首先,我們定義了 `encode_int`,用於將指定精確度的無符號整數封送為字串。 同時也定義了它的逆函式:
@@ -29,7 +29,7 @@ Dagger-Hashimoto 旨在實現兩個目標:
NUM_BITS = 512
def encode_int(x):
- "Encode an integer x as a string of 64 characters using a big-endian scheme"
+ "使用大端序法將整數 x 編碼為 64 個字元的字串"
o = ''
for _ in range(NUM_BITS / 8):
o = chr(x % 256) + o
@@ -37,7 +37,7 @@ def encode_int(x):
return o
def decode_int(s):
- "Unencode an integer x from a string using a big-endian scheme"
+ "使用大端序法從字串解碼整數 x"
x = 0
for c in s:
x *= 256
@@ -45,7 +45,7 @@ def decode_int(s):
return x
```
-接下來,我們假設 `sha3` 是一個需要輸入整數,然後輸出整數的函式,而 `dbl_sha3` 是一個 double-sha3 函式;如果將此引用程式碼轉換為實作,使用以下程式碼:
+接下來,我們假設 `sha3` 是一個需要輸入整數,然後輸出整數的函式,而 `dbl_sha3` 是一個 double-sha3 函式;如果將此參考程式碼轉換為實作,請使用以下程式碼:
```python
from pyethereum import utils
@@ -65,26 +65,26 @@ def dbl_sha3(x):
演算法使用的參數如下:
```python
-SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512
+SAFE_PRIME_512 = 2**512 - 38117 # 小於 2**512 的最大安全質數
params = {
- "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536
- "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536
- # with epochtime=20000 gives 882 MB growth per year
- "cache_size": 2500, # Size of the light client's cache (can be chosen by light
- # client; not part of the algo spec)
- "diff": 2**14, # Difficulty (adjusted during block evaluation)
- "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated)
- "k": 1, # Number of parents of a node
- "w": w, # Used for modular exponentiation hashing
- "accesses": 200, # Number of dataset accesses during hashimoto
- "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation
+ "n": 4000055296 * 8 // NUM_BITS, # 資料集大小 (4 GB);必須是 65536 的倍數
+ "n_inc": 65536, # 每個週期 n 值的增量;必須是 65536 的倍數
+ # 當 epochtime=20000 時,每年增長 882 MB
+ "cache_size": 2500, # 輕用戶端的快取大小 (可由輕用戶端選擇;
+ # 非演算法規格的一部分)
+ "diff": 2**14, # 難度 (在區塊評估期間調整)
+ "epochtime": 100000, # 以區塊為單位的時期長度 (資料集更新頻率)
+ "k": 1, # 一個節點的父節點數量
+ "w": w, # 用於模冪運算哈希
+ "accesses": 200, # hashimoto 期間的資料集存取次數
+ "P": SAFE_PRIME_512 # 用於哈希和隨機數產生的安全質數
}
```
`P` 在這種情況下為選定的素數,使得 `log₂(P)` 僅略小於 512,對應於我們用來表示數字的 512 位元。 請注意,實際上只需要儲存有向無環圖的後半部分,因此,實際隨機存取記憶體需求最初為 1 GB,且每年增長 441 MB。
-### Dagger 建圖 {#dagger-graph-building}
+### Dagger 圖形建構 {#dagger-graph-building}
Dagger 建圖基礎單元的定義如下:
@@ -101,11 +101,11 @@ def produce_dag(params, seed, length):
return o
```
-基本上,建圖從單一節點 `sha3(seed)` 開始,然後根據隨機的先前節點按順序添加到其他節點上。 建立一個新節點後,計算種子的模幂,以隨機選擇一些小於 `i` 的索引(使用上述 `x % i`),並使用這些索引上的節點值進行計算,以產生新的 `x` 值,隨後該值被提供給一個較小的工作量證明函式(基於 XOR),最終產生索引 `i` 上的圖形值。 這種特殊設計背後的基本原理是,強制依序存取有向無環圖;如果目前值未知,則無法確定要存取的下一個有向無環圖的值。 最後,模冪運算會進一步對結果進行雜湊。
+基本上,建圖從單一節點 `sha3(seed)` 開始,然後根據隨機的先前節點按順序添加到其他節點上。 建立一個新節點後,計算種子的模冪,以隨機選擇一些小於 `i` 的索引(使用上述 `x % i`),並使用這些索引上的節點值進行計算,以產生新的 `x` 值,隨後該值被提供給一個較小的工作量證明函式(基於 XOR),最終產生索引 `i` 上的圖形值。 這種特殊設計背後的基本原理是,強制依序存取有向無環圖;如果目前值未知,則無法確定要存取的下一個有向無環圖的值。 最後,模冪運算會進一步對結果進行雜湊。
這種演算法依賴於數字理論的若干結果。 討論情況見下文附錄。
-## 輕量用戶端評估 {#light-client-evaluation}
+## 輕用戶端評估 {#light-client-evaluation}
上述構圖旨在實現只計算少量節點的子樹,並且僅需少量的輔助記憶體,便完成圖中每個節點的重構。 請注意,當 k=1 時,子樹只是一個上升到有向無環圖第一個元素的值鏈。
@@ -133,9 +133,9 @@ def quick_calc(params, seed, p):
本質上,它只是對上述演算法的重寫,刪除了計算整個有向無環圖值的循環,並用遞歸呼叫或快取查找取代了早期的節點查找。 請注意,對於 `k=1` 的情況,快取是不必要的,但進一步的最佳化實際上預先計算了有向無環圖的前幾千個值,並將其作為靜態快取進行計算;有關程式碼實作,請參閱附錄。
-## 有向無環圖的雙倍緩衝 {#double-buffer}
+## DAG 的雙緩衝區 {#double-buffer}
-在全用戶端中,使用了上述公式產生的 2 個有向無環圖的[_雙倍緩衝_](https://wikipedia.org/wiki/Multiple_buffering)。 具體概念是,根據上述參數,每 `epochtime` 個區塊產生一個有向無環圖。 但用戶端使用的並非是最新產生的有向無環圖,而是前一個。 這樣做的好處是,有向無環圖可以隨著時間的推移而被替換掉,無需包含一個步驟,讓礦工必須突然重新計算所有資料。 否則,定期的鏈處理可能會突然暫時放緩,並大幅提高中心化程度。 因此,在重新計算所有資料之前的幾分鐘時間內,存在 51% 攻擊風險。
+在完整用戶端中,會使用由上述公式產生的 2 個 DAG 的 [_雙緩衝區_](https://wikipedia.org/wiki/Multiple_buffering)。 其概念是,根據上述參數,每隔 `epochtime` 個區塊就會產生一個有向無環圖。 但用戶端使用的並非是最新產生的有向無環圖,而是前一個。 這樣做的好處是,有向無環圖可以隨著時間的推移而被替換掉,無需包含一個步驟,讓礦工必須突然重新計算所有資料。 否則,定期的鏈處理可能會突然暫時放緩,並大幅提高中心化程度。 因此,在重新計算所有資料之前的幾分鐘時間內,存在 51% 攻擊風險。
要產生用於計算區塊工作的有向無環圖集,演算法如下:
@@ -164,7 +164,7 @@ def get_daggerset(params, block):
dagsz = get_dagsize(params, block)
seedset = get_seedset(params, block)
if seedset["front_hash"] <= 0:
- # No back buffer is possible, just make front buffer
+ # 沒有可用的後備緩衝區,僅建立前景緩衝區
return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
"block_number": 0}}
else:
@@ -254,56 +254,52 @@ def light_verify(params, header, nonce):
- 為了使雙層驗證起效,區塊頭必須同時具有隨機數和中間值 Pre-sha3
- 區塊頭必須在某處儲存目前種子集的 sha3
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 附錄 {#appendix}
-如前所述,用於產生有向無環圖的隨機數產生依賴於數論的一些結果。 Lehmer 隨機數產生程式是 `picker` 變數的基礎,因此我們首先確保它具有很寬的週期。 其次,只要一開始 `x ∈ [2,P-2]`,我們就能證明 `pow(x,3,P)` 不會將 `x` 對應到 `1` 或 `P-1`。 最後,我們證明 `pow(x,3,P)` 在被視為雜湊函式時具有較低的衝突率。
+如前所述,用於產生有向無環圖的隨機數產生依賴於數論的一些結果。 首先,我們確保作為 `picker` 變數基礎的 Lehmer 隨機數產生器 (RNG) 具有很長的週期。 其次,只要一開始 `x ∈ [2,P-2]`,我們就能證明 `pow(x,3,P)` 不會將 `x` 對應到 `1` 或 `P-1`。 最後,我們證明 `pow(x,3,P)` 作為哈希函數時,具有較低的碰撞率。
-### Lehmer 隨機數產生程式 {#lehmer-random-number}
+### Lehmer 隨機數產生器 {#lehmer-random-number}
-雖然 `produce_dag` 函式不需要產生無偏隨機數,但潛在的威脅是 `seed**i % P` 只取少數幾個值。 這可以為礦工識別模式提供優勢。
+雖然 `produce_dag` 函數不需要產生無偏隨機數,但一個潛在的威脅是 `seed**i % P` 只會得到少數幾個值。 這可以為礦工識別模式提供優勢。
-為了避免這種情況,可採用數論結果。 [_安全素數_](https://en.wikipedia.org/wiki/Safe_prime)定義為素數 `P`,使得 `(P-1)/2` 也是素數。 成員 `x` 的_階次_([倍乘群](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n)的 `ℤ/nℤ`)定義為最小 `m`,使得
xᵐ mod P ≡ 1
-根據這些定義,我們得出:
+為了避免這種情況,可採用數論結果。 [_安全質數_](https://en.wikipedia.org/wiki/Safe_prime) 的定義是,一個質數 `P`,其 `(P-1)/2` 也是質數。 在[乘法群](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` 中一個成員 `x` 的_階_定義為最小的 `m`,使得 xᵐ mod P ≡ 1
+基於這些定義,我們得到:
-> 觀察 1. 令 `x` 成為倍乘群 `ℤ/Pℤ` 的成員,以獲得安全素數 `P`。 如果 `x mod P ≠ 1 mod P` 且 `x mod P ≠ P-1 mod P`,那麼 `x` 的階次為 ` P-1` 或 `(P-1)/2`。
+> 觀察 1. 令 `x` 為安全質數 `P` 的乘法群 `ℤ/Pℤ` 的一個成員。 如果 `x mod P ≠ 1 mod P` 且 `x mod P ≠ P-1 mod P`,那麼 `x` 的階次為 `P-1` 或 `(P-1)/2`。
-_ 證明 _. 由於 `P` 是安全素數,那麼根據 \[拉格朗日定理\]\[lagrange\],我們得到 `x` 的階次為 `1`、`2`、`(P-1)/2` 或 `P-1`。
+_證明_。 由於 `P` 是一個安全質數,根據[拉格朗日定理][lagrange],`x` 的階為 `1`、`2`、`(P-1)/2` 或 `P-1`。
-`x` 的階次不能是 `1`,因為根據費馬小定理,我們得到:
+`x` 的階不可能是 `1`,因為根據費馬小定理:
xP-1 mod P ≡ 1
-因此,`x` 必須是 `ℤ/nℤ` 的唯一乘法單位。 由於我們假設 `x ≠ 1`,所以這是不可能的。
+因此 `x` 必須是 `ℤ/nℤ` 的唯一乘法單位。 由於我們已假設 `x ≠ 1`,因此這是不可能的。
-除非 `x = P-1`,否則 `x` 的階次不能是 `2`,因為這將違反 `P` 是素數的事實。
+除非 `x = P-1`,否則 `x` 的階不能是 `2`,因為這將違反 `P` 是質數的事實。
-從上述命題中,我們可以知道,迭代 `(picker * init) % P` 的循環長度至少為 `(P-1)/2`。 這是因為我們選擇了 `P` 為約等於 2 的更高次冪的安全素數,且 `init` 處於 `[2,2**256+1]` 區間內。 考慮到 `P` 的大小,我們不應該期望模冪運算會出現循環。
+從上述命題中,我們可以得知迭代 `(picker * init) % P` 將具有至少 `(P-1)/2` 的循環長度。 這是因為我們選擇了 `P` 為約等於 2 的更高次冪的安全質數,且 `init` 處於 `[2,2**256+1]` 區間內。 考慮到 `P` 的大小,我們不應該預期模冪運算會產生循環。
-在分配有向無環圖中的第一個單元時(變數標籤為 `init`),我們會計算 `pow(sha3(seed) + 2, 3, P)`。 初看起來,這並不能保證結果既不是 `1` 也不是 `P-1`。 然而,既然 `P-1` 是一個安全素數,我們也提供以下額外保證,這是觀察 1 的必然結果:
+當我們給有向無環圖 (DAG) 中的第一個單元 (標記為 `init` 的變數) 賦值時,我們計算 `pow(sha3(seed) + 2, 3, P)`。 乍看之下,這並不能保證結果既不是 `1` 也不是 `P-1`。 然而,既然 `P-1` 是一個安全質數,我們也提供以下額外保證,這是觀察 1 的必然結果:
-> 觀察 2. 令 `x` 成為乘法組 `ℤ/Pℤ` 的一員,以獲得安全素數 `P`,並令 `w` 成為自然數。 如果 `x mod P ≠ 1 mod P`、`x mod P ≠ P-1 mod P`,且 `w mod P ≠ P-1 mod P`、`w mod P ≠ 0 mod P`,則 `xʷ mod P ≠ 1 mod P` 且 `xʷ mod P ≠ P-1 mod P`
+> 觀察 2. 令 `x` 為安全質數 `P` 的乘法群 `ℤ/Pℤ` 的一個成員,並令 `w` 為一個自然數。 如果 `x mod P ≠ 1 mod P`、`x mod P ≠ P-1 mod P`,且 `w mod P ≠ P-1 mod P`、`w mod P ≠ 0 mod P`,則 `xʷ mod P ≠ 1 mod P` 且 `xʷ mod P ≠ P-1 mod P`
-### 模冪運算用作雜湊函式 {#modular-exponentiation}
+### 模冪運算用作哈希函數 {#modular-exponentiation}
-對於特定的 `P` 值和 `w` 值,函式 `pow (x, w, P)` 可能存在許多衝突。 例如,`pow (x,9,19)` 的值只能接受 `{1,18}`。
+對於 `P` 和 `w` 的某些值,`pow(x, w, P)` 函數可能會有很多衝突。 例如,`pow(x,9,19)` 的值只能是 `{1,18}`。
-鑑於 `P` 為素數,可以使用以下結果,選擇一個用於模冪運算雜湊函式的適當 `w` 值:
+假定 `P` 是質數,那麼可以利用以下結果為模冪運算哈希函數選擇一個合適的 `w`:
-> 觀察 3. 令 `P` 為素數;當且僅當 `ℤ/Pℤ` 中的所有 `a` 和 `b` 都滿足以下條件時,`w` 和 `P-1` 才能為互素。
->
->
-> 當且僅當 `a mod P ≡ b mod P` 時,`aʷ mod P ≡ bʷ mod P`
->
+> 觀察 3. 令 `P` 為一個質數;`w` 和 `P-1` 互質,若且唯若對於 `ℤ/Pℤ` 中所有的 `a` 和 `b`:`aʷ mod P ≡ bʷ mod P` 若且唯若 `a mod P ≡ b mod P`
-因此,鑑於 `P` 為素數,且 `w` 與 `P-1` 互素,我們得到 `|{pow (x, w, P) : x ∈ ℤ}| = P`,表示雜湊函式具有盡可能小的衝突率。
+因此,假定 `P` 是質數且 `w` 與 `P-1` 互質,則我們有 `|{pow(x, w, P) : x ∈ ℤ}| = P`,這意味著該哈希函數具有最小的可能碰撞率。
-在特殊情況下,`P` 是我們選擇的安全素數,那麼 `P-1` 僅有係數 1、2、`(P-1)/2` 和 `P-1`。 由於 `P` > 7,我們知道 3 與 `P-1` 互素,因此 `w=3` 滿足上述命題。
+在我們所選的 `P` 是安全質數的特殊情況下,`P-1` 的因數只有 1、2、`(P-1)/2` 和 `P-1`。 由於 `P` > 7,我們知道 3 與 `P-1` 互質,因此 `w=3` 滿足上述命題。
-## 更有效的快取評估演算法 {#cache-based-evaluation}
+## 更高效的快取型評估演算法 {#cache-based-evaluation}
```python
def quick_calc(params, seed, p):
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
index 66a4ad72d87..ecff5438e53 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
@@ -8,12 +8,12 @@ lang: zh-tw
- Ethash 是以太坊的工作量證明挖礦演算法。 工作量證明現在已經被**完全關閉**,取而代之的是,以太坊現在使用[權益證明](/developers/docs/consensus-mechanisms/pos/)來確保安全。 閱讀更多關於[合併 ](/roadmap/merge/)、[權益證明](/developers/docs/consensus-mechanisms/pos/)和[質押](/staking/)的資訊。 此頁面僅為滿足對歷史的興趣!
+ Ethash 是以太坊的工作量證明挖礦演算法。 工作量證明現在已經被**完全關閉**,取而代之的是,以太坊現在使用[權益證明](/developers/docs/consensus-mechanisms/pos/)來確保安全。 閱讀更多關於[合併](/roadmap/merge/)、[權益證明](/developers/docs/consensus-mechanisms/pos/)和[質押](/staking/)的資訊。 此頁面僅為滿足對歷史的興趣!
-Ethash 是 [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) 演算法的修改版。 Ethash 工作量證明是[記憶體密集型](https://wikipedia.org/wiki/Memory-hard_function)演算法,這被認為使演算法具有專用積體電路抗性。 Ethash 專用積體電路最終被開發出來,但圖形處理單元挖礦仍然是一個可行的選擇,直至工作量證明被關閉。 Ethash 仍在其他非以太坊工作量證明網路上用於挖掘其他代幣。
+Ethash 是 [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) 演算法的修改版本。 Ethash 工作量證明是[記憶體困難型](https://wikipedia.org/wiki/Memory-hard_function),一般認為這讓此演算法具備抗 ASIC 的能力。 Ethash 專用積體電路最終被開發出來,但圖形處理單元挖礦仍然是一個可行的選擇,直至工作量證明被關閉。 Ethash 仍在其他非以太坊工作量證明網路上用於挖掘其他代幣。
## Ethash 是如何運作的? {#how-does-ethash-work}
@@ -21,9 +21,9 @@ Ethash 是 [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/m
此演算法所採取的一般路線如下:
-1. 存在一個**種子**,可以透過掃描區塊頭直到該點來為每個區塊計算種子。
+1. 每個區塊都有一個**種子**,可藉由掃描該點之前的區塊頭來計算得出。
2. 從種子可以計算出 **16 MB 的偽隨機快取**。 由輕量用户端儲存該快取。
-3. 我們可以從快取中產生一個 **1 GB 資料集 **,資料集中每個項目僅依賴快取中的一小部分項目。 由全用户端和礦工儲存該資料集。 該资料集隨著時間的流逝而呈線性增長。
+3. 我們可以從快取中產生一個 **1 GB 的資料集**,此資料集的特性是,其中每個項目都只依賴快取中的少數項目。 由全用户端和礦工儲存該資料集。 該资料集隨著時間的流逝而呈線性增長。
4. 挖礦需要取得該資料集的隨機片段並將它們雜湊在一起。 可以透過使用快取來重新產生你所需要的資料集中的特定片段,以較少的記憶體進行驗證,這樣你就只需要儲存快取。
每隔 30,000 個區塊更新一次大資料集,因此,礦工的絕大部分工作都是讀取資料集,而不是對其進行修改。
@@ -33,23 +33,23 @@ Ethash 是 [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/m
我們採用以下定義:
```
-WORD_BYTES = 4 # bytes in word
-DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis
-DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch
-CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis
-CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch
-CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache
-EPOCH_LENGTH = 30000 # blocks per epoch
-MIX_BYTES = 128 # width of mix
-HASH_BYTES = 64 # hash length in bytes
-DATASET_PARENTS = 256 # number of parents of each dataset element
-CACHE_ROUNDS = 3 # number of rounds in cache production
-ACCESSES = 64 # number of accesses in hashimoto loop
+WORD_BYTES = 4 # 字組中的位元組
+DATASET_BYTES_INIT = 2**30 # 創世時資料集中的位元組
+DATASET_BYTES_GROWTH = 2**23 # 每個時期的資料集成長
+CACHE_BYTES_INIT = 2**24 # 創世時快取中的位元組
+CACHE_BYTES_GROWTH = 2**17 # 每個時期的快取成長
+CACHE_MULTIPLIER=1024 # DAG 相對於快取的大小
+EPOCH_LENGTH = 30000 # 每個時期的區塊數
+MIX_BYTES = 128 # mix 的寬度
+HASH_BYTES = 64 # 雜湊值長度 (以位元組為單位)
+DATASET_PARENTS = 256 # 每個資料集元素的父項數
+CACHE_ROUNDS = 3 # 快取產生中的回合數
+ACCESSES = 64 # hashimoto 迴圈中的存取次數
```
-### 使用「SHA3」 {#sha3}
+### 使用「SHA3」{#sha3}
-以太坊的開發恰逢 SHA3 標準的製定,標準流程對最終確定的雜湊值演算法的填充做了後期改動,使得以太坊的「sha3_256」和「sha3_512」雜湊值不是標準的 sha3 雜湊值,而是在其他情況下常被稱為「Keccak-256」和「Keccak-512」的變體。 討論請見[此處](https://eips.ethereum.org/EIPS/eip-1803)、[此處](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use),或[此處](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)。
+以太坊的開發恰逢 SHA3 標準的製定,標準流程對最終確定的雜湊值演算法的填充做了後期改動,使得以太坊的「sha3_256」和「sha3_512」雜湊值不是標準的 sha3 雜湊值,而是在其他情況下常被稱為「Keccak-256」和「Keccak-512」的變體。 請參閱討論,例如:[此處](https://eips.ethereum.org/EIPS/eip-1803)、[此處](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)或[此處](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)。
請記住這一點,因為下面的演算法描述中提到了「sha3」雜湊值。
@@ -75,7 +75,7 @@ def get_full_size(block_number):
附錄中提供了資料集和快取大小值表。
-## 快取產生 {#cache-generation}
+## 快取生成 {#cache-generation}
現在,我們來指定產生快取的函式:
@@ -83,12 +83,12 @@ def get_full_size(block_number):
def mkcache(cache_size, seed):
n = cache_size // HASH_BYTES
- # Sequentially produce the initial dataset
+ # 循序產生初始資料集
o = [sha3_512(seed)]
for i in range(1, n):
o.append(sha3_512(o[-1]))
- # Use a low-round version of randmemohash
+ # 使用低回合數版本的 randmemohash
for _ in range(CACHE_ROUNDS):
for i in range(n):
v = o[i][0] % n
@@ -97,11 +97,11 @@ def mkcache(cache_size, seed):
return o
```
-在快取生成過程中,先依序填入32 MB 存儲體,然後從[_嚴格存儲體密集型雜湊函式_ (2014)](http://www.hashcash.org/papers/memohash.pdf) 執行兩次 Sergio Demian Lerner 的 _RandMemoHash_ 演算法。 輸出一組 524288 個 64 字節位元組值。
+快取生成過程首先會循序填滿 32 MB 的記憶體,然後執行兩輪 Sergio Demian Lerner 的 _RandMemoHash_ 演算法,此演算法出自 [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf)。 輸出一組 524288 個 64 字節位元組值。
## 資料匯總函式 {#date-aggregation-function}
-我們所用演算法的靈感來自 [FNV 雜湊](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function),在部分情況下,這種演算法可用作邏輯 XOR 的非相干替代。 請注意,我們使用全 32 位元輸入乘以素數,與之相對地,FNV-1 規範以單字節位元組(8 位元組)依序乘以素數。
+在某些情況下,我們使用一種受 [FNV 雜湊](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function)啟發的演算法,作為 XOR 的非關聯性替代品。 請注意,我們使用全 32 位元輸入乘以素數,與之相對地,FNV-1 規範以單字節位元組(8 位元組)依序乘以素數。
```python
FNV_PRIME = 0x01000193
@@ -120,11 +120,11 @@ def fnv(v1, v2):
def calc_dataset_item(cache, i):
n = len(cache)
r = HASH_BYTES // WORD_BYTES
- # initialize the mix
+ # 初始化 mix
mix = copy.copy(cache[i % n])
mix[0] ^= i
mix = sha3_512(mix)
- # fnv it with a lot of random cache nodes based on i
+ # 以 i 為基礎,與多個隨機快取節點進行 FNV 運算
for j in range(DATASET_PARENTS):
cache_index = fnv(i ^ j, mix[j % r])
mix = map(fnv, mix, cache[cache_index % n])
@@ -138,29 +138,29 @@ def calc_dataset(full_size, cache):
return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
```
-## 主循環 {#main-loop}
+## 主迴圈 {#main-loop}
-現在,我們指定了類似「hashimoto」的主要循環。在此循環中,我們匯總了整個資料集的資料,以產生特定區塊頭和隨機數的最終值。 在下面的程式碼中,`header` 代表一個_被截斷_區塊頭的遞歸長度前綴表示的 SHA3-256 _雜湊值_。被截斷是指區塊頭排除了 **mixHash** 和 **nonce** 欄位。 `nonce` 是八字節位元組的 64 位元無符號整數,採用高位元組在前順序。 因此,`nonce [::-1]` 是上述值的八位元組高位元組在前順序表示:
+現在,我們指定了類似「hashimoto」的主要循環。在此循環中,我們匯總了整個資料集的資料,以產生特定區塊頭和隨機數的最終值。 在下方的程式碼中,`header` 代表一個_被截斷_區塊標頭的 RLP 表示的 SHA3-256 _雜湊值_,也就是說,這是一個排除了 **mixHash** 與 **nonce** 欄位的標頭。 `nonce` 是 64 位元無正負號整數的八個位元組,採大端序 (big-endian) 排列。 所以 `nonce[::-1]` 是該值的八位元組小端序 (little-endian) 表示法:
```python
def hashimoto(header, nonce, full_size, dataset_lookup):
n = full_size / HASH_BYTES
w = MIX_BYTES // WORD_BYTES
mixhashes = MIX_BYTES / HASH_BYTES
- # combine header+nonce into a 64 byte seed
+ # 將 header+nonce 合併成一個 64 位元組的種子
s = sha3_512(header + nonce[::-1])
- # start the mix with replicated s
+ # 以複製的 s 開始混合
mix = []
for _ in range(MIX_BYTES / HASH_BYTES):
mix.extend(s)
- # mix in random dataset nodes
+ # 混入隨機資料集節點
for i in range(ACCESSES):
p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
newdata = []
for j in range(MIX_BYTES / HASH_BYTES):
newdata.extend(dataset_lookup(p + j))
mix = map(fnv, mix, newdata)
- # compress mix
+ # 壓縮 mix
cmix = []
for i in range(0, len(mix), 4):
cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
@@ -176,9 +176,9 @@ def hashimoto_full(full_size, dataset, header, nonce):
return hashimoto(header, nonce, full_size, lambda x: dataset[x])
```
-基本上,我們保持著一個寬 128 字節位元組的「mix」,多次按順序從整個資料集重複取得 128 字節位元組,並使用 `fnv` 函式將其與 mix 合併。 使用 128 字節位元組的順序存取,以便每輪演算法總是能從隨機存取記憶體獲取完整的頁面,從而盡量減少轉譯後備緩衝區的失誤,而專用積體電路在理論上能夠避免這些失誤。
+基本上,我們維護一個 128 位元組寬的 "mix",並從完整資料集中重複循序擷取 128 位元組,然後使用 `fnv` 函式將其與 mix 結合。 使用 128 字節位元組的順序存取,以便每輪演算法總是能從隨機存取記憶體獲取完整的頁面,從而盡量減少轉譯後備緩衝區的失誤,而專用積體電路在理論上能夠避免這些失誤。
-如果此演算法的輸出低於所需目標,即證明隨機數是有效的。 請注意,在最後額外套用 `sha3_256` 將確保中間隨機數的存在,提供此證據可以證明至少做了少量工作;而且此快速外部工作量證明驗證可以用於反分散式阻斷服務。 它還能提供統計保證,確保結果是一個無偏的 256 位元數。
+如果此演算法的輸出低於所需目標,即證明隨機數是有效的。 請注意,結尾額外應用 `sha3_256` 可確保存在一個中介 nonce,此 nonce 可用來證明至少已完成少量工作;這種快速的外部 PoW 驗證可用於反 DDoS 目的。 它還能提供統計保證,確保結果是一個無偏的 256 位元數。
## 挖礦 {#mining}
@@ -186,7 +186,7 @@ def hashimoto_full(full_size, dataset, header, nonce):
```python
def mine(full_size, dataset, header, difficulty):
- # zero-pad target to compare with hash on the same digit
+ # 將目標補零,以便與雜湊值比較
target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
from random import randint
nonce = randint(0, 2**64)
@@ -209,9 +209,9 @@ def mine(full_size, dataset, header, difficulty):
請注意,為了順利挖礦和驗證,我們建議在單獨執行緒中預先計算未來的種子雜湊值和資料集。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 附錄 {#appendix}
@@ -220,7 +220,7 @@ _認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或
```python
import sha3, copy
-# Assumes little endian bit ordering (same as Intel architectures)
+# 假設為小端元位元順序 (與 Intel 架構相同)
def decode_int(s):
return int(s[::-1].encode('hex'), 16) if s else 0
@@ -248,7 +248,7 @@ def serialize_cache(ds):
serialize_dataset = serialize_cache
-# sha3 hash function, outputs 64 bytes
+# sha3 雜湊函式,輸出 64 位元組
def sha3_512(x):
return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
@@ -881,139 +881,139 @@ cache_sizes = [
177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
-179568448, 179698496, 179830208, 179960512, 180092608, 180223808,
-180354752, 180485696, 180617152, 180748096, 180877504, 181009984,
-181139264, 181272512, 181402688, 181532608, 181663168, 181795136,
-181926592, 182057536, 182190016, 182320192, 182451904, 182582336,
-182713792, 182843072, 182976064, 183107264, 183237056, 183368384,
-183494848, 183631424, 183762752, 183893824, 184024768, 184154816,
-184286656, 184417984, 184548928, 184680128, 184810816, 184941248,
-185072704, 185203904, 185335616, 185465408, 185596352, 185727296,
-185859904, 185989696, 186121664, 186252992, 186383552, 186514112,
-186645952, 186777152, 186907328, 187037504, 187170112, 187301824,
-187429184, 187562048, 187693504, 187825472, 187957184, 188087104,
-188218304, 188349376, 188481344, 188609728, 188743616, 188874304,
-189005248, 189136448, 189265088, 189396544, 189528128, 189660992,
-189791936, 189923264, 190054208, 190182848, 190315072, 190447424,
-190577984, 190709312, 190840768, 190971328, 191102656, 191233472,
-191364032, 191495872, 191626816, 191758016, 191888192, 192020288,
-192148928, 192282176, 192413504, 192542528, 192674752, 192805952,
-192937792, 193068608, 193198912, 193330496, 193462208, 193592384,
-193723456, 193854272, 193985984, 194116672, 194247232, 194379712,
-194508352, 194641856, 194772544, 194900672, 195035072, 195166016,
-195296704, 195428032, 195558592, 195690304, 195818176, 195952576,
-196083392, 196214336, 196345792, 196476736, 196607552, 196739008,
-196869952, 197000768, 197130688, 197262784, 197394368, 197523904,
-197656384, 197787584, 197916608, 198049472, 198180544, 198310208,
-198442432, 198573632, 198705088, 198834368, 198967232, 199097792,
-199228352, 199360192, 199491392, 199621696, 199751744, 199883968,
-200014016, 200146624, 200276672, 200408128, 200540096, 200671168,
-200801984, 200933312, 201062464, 201194944, 201326144, 201457472,
-201588544, 201719744, 201850816, 201981632, 202111552, 202244032,
-202374464, 202505152, 202636352, 202767808, 202898368, 203030336,
-203159872, 203292608, 203423296, 203553472, 203685824, 203816896,
-203947712, 204078272, 204208192, 204341056, 204472256, 204603328,
-204733888, 204864448, 204996544, 205125568, 205258304, 205388864,
-205517632, 205650112, 205782208, 205913536, 206044736, 206176192,
-206307008, 206434496, 206569024, 206700224, 206831168, 206961856,
-207093056, 207223616, 207355328, 207486784, 207616832, 207749056,
-207879104, 208010048, 208141888, 208273216, 208404032, 208534336,
-208666048, 208796864, 208927424, 209059264, 209189824, 209321792,
-209451584, 209582656, 209715136, 209845568, 209976896, 210106432,
-210239296, 210370112, 210501568, 210630976, 210763712, 210894272,
-211024832, 211156672, 211287616, 211418176, 211549376, 211679296,
-211812032, 211942592, 212074432, 212204864, 212334016, 212467648,
-212597824, 212727616, 212860352, 212991424, 213120832, 213253952,
-213385024, 213515584, 213645632, 213777728, 213909184, 214040128,
-214170688, 214302656, 214433728, 214564544, 214695232, 214826048,
-214956992, 215089088, 215219776, 215350592, 215482304, 215613248,
-215743552, 215874752, 216005312, 216137024, 216267328, 216399296,
-216530752, 216661696, 216790592, 216923968, 217054528, 217183168,
-217316672, 217448128, 217579072, 217709504, 217838912, 217972672,
-218102848, 218233024, 218364736, 218496832, 218627776, 218759104,
-218888896, 219021248, 219151936, 219281728, 219413056, 219545024,
-219675968, 219807296, 219938624, 220069312, 220200128, 220331456,
-220461632, 220592704, 220725184, 220855744, 220987072, 221117888,
-221249216, 221378368, 221510336, 221642048, 221772736, 221904832,
-222031808, 222166976, 222297536, 222428992, 222559936, 222690368,
-222820672, 222953152, 223083968, 223213376, 223345984, 223476928,
-223608512, 223738688, 223869376, 224001472, 224132672, 224262848,
-224394944, 224524864, 224657344, 224788288, 224919488, 225050432,
-225181504, 225312704, 225443776, 225574592, 225704768, 225834176,
-225966784, 226097216, 226229824, 226360384, 226491712, 226623424,
-226754368, 226885312, 227015104, 227147456, 227278528, 227409472,
-227539904, 227669696, 227802944, 227932352, 228065216, 228196288,
-228326464, 228457792, 228588736, 228720064, 228850112, 228981056,
-229113152, 229243328, 229375936, 229505344, 229636928, 229769152,
-229894976, 230030272, 230162368, 230292416, 230424512, 230553152,
-230684864, 230816704, 230948416, 231079616, 231210944, 231342016,
-231472448, 231603776, 231733952, 231866176, 231996736, 232127296,
-232259392, 232388672, 232521664, 232652608, 232782272, 232914496,
-233043904, 233175616, 233306816, 233438528, 233569984, 233699776,
-233830592, 233962688, 234092224, 234221888, 234353984, 234485312,
-234618304, 234749888, 234880832, 235011776, 235142464, 235274048,
-235403456, 235535936, 235667392, 235797568, 235928768, 236057152,
-236190272, 236322752, 236453312, 236583616, 236715712, 236846528,
-236976448, 237108544, 237239104, 237371072, 237501632, 237630784,
-237764416, 237895232, 238026688, 238157632, 238286912, 238419392,
-238548032, 238681024, 238812608, 238941632, 239075008, 239206336,
-239335232, 239466944, 239599168, 239730496, 239861312, 239992384,
-240122816, 240254656, 240385856, 240516928, 240647872, 240779072,
-240909632, 241040704, 241171904, 241302848, 241433408, 241565248,
-241696192, 241825984, 241958848, 242088256, 242220224, 242352064,
-242481856, 242611648, 242744896, 242876224, 243005632, 243138496,
-243268672, 243400384, 243531712, 243662656, 243793856, 243924544,
-244054592, 244187072, 244316608, 244448704, 244580032, 244710976,
-244841536, 244972864, 245104448, 245233984, 245365312, 245497792,
-245628736, 245759936, 245889856, 246021056, 246152512, 246284224,
-246415168, 246545344, 246675904, 246808384, 246939584, 247070144,
-247199552, 247331648, 247463872, 247593536, 247726016, 247857088,
-247987648, 248116928, 248249536, 248380736, 248512064, 248643008,
-248773312, 248901056, 249036608, 249167552, 249298624, 249429184,
-249560512, 249692096, 249822784, 249954112, 250085312, 250215488,
-250345792, 250478528, 250608704, 250739264, 250870976, 251002816,
-251133632, 251263552, 251395136, 251523904, 251657792, 251789248,
-251919424, 252051392, 252182464, 252313408, 252444224, 252575552,
-252706624, 252836032, 252968512, 253099712, 253227584, 253361728,
-253493056, 253623488, 253754432, 253885504, 254017216, 254148032,
-254279488, 254410432, 254541376, 254672576, 254803264, 254933824,
-255065792, 255196736, 255326528, 255458752, 255589952, 255721408,
-255851072, 255983296, 256114624, 256244416, 256374208, 256507712,
-256636096, 256768832, 256900544, 257031616, 257162176, 257294272,
-257424448, 257555776, 257686976, 257818432, 257949632, 258079552,
-258211136, 258342464, 258473408, 258603712, 258734656, 258867008,
-258996544, 259127744, 259260224, 259391296, 259522112, 259651904,
-259784384, 259915328, 260045888, 260175424, 260308544, 260438336,
-260570944, 260700992, 260832448, 260963776, 261092672, 261226304,
-261356864, 261487936, 261619648, 261750592, 261879872, 262011968,
-262143424, 262274752, 262404416, 262537024, 262667968, 262799296,
-262928704, 263061184, 263191744, 263322944, 263454656, 263585216,
-263716672, 263847872, 263978944, 264108608, 264241088, 264371648,
-264501184, 264632768, 264764096, 264895936, 265024576, 265158464,
-265287488, 265418432, 265550528, 265681216, 265813312, 265943488,
-266075968, 266206144, 266337728, 266468032, 266600384, 266731072,
-266862272, 266993344, 267124288, 267255616, 267386432, 267516992,
-267648704, 267777728, 267910592, 268040512, 268172096, 268302784,
-268435264, 268566208, 268696256, 268828096, 268959296, 269090368,
-269221312, 269352256, 269482688, 269614784, 269745856, 269876416,
-270007616, 270139328, 270270272, 270401216, 270531904, 270663616,
-270791744, 270924736, 271056832, 271186112, 271317184, 271449536,
-271580992, 271711936, 271843136, 271973056, 272105408, 272236352,
-272367296, 272498368, 272629568, 272759488, 272891456, 273022784,
-273153856, 273284672, 273415616, 273547072, 273677632, 273808448,
-273937088, 274071488, 274200896, 274332992, 274463296, 274595392,
-274726208, 274857536, 274988992, 275118656, 275250496, 275382208,
-275513024, 275643968, 275775296, 275906368, 276037184, 276167872,
-276297664, 276429376, 276560576, 276692672, 276822976, 276955072,
-277085632, 277216832, 277347008, 277478848, 277609664, 277740992,
-277868608, 278002624, 278134336, 278265536, 278395328, 278526784,
-278657728, 278789824, 278921152, 279052096, 279182912, 279313088,
-279443776, 279576256, 279706048, 279838528, 279969728, 280099648,
-280230976, 280361408, 280493632, 280622528, 280755392, 280887104,
-281018176, 281147968, 281278912, 281411392, 281542592, 281673152,
-281803712, 281935552, 282066496, 282197312, 282329024, 282458816,
-282590272, 282720832, 282853184, 282983744, 283115072, 283246144,
-283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
-284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
-284950208, 285081536]
+179568448, 179698496, 179830208, 180092608, 180223808, 180354752,
+180485696, 180617152, 180748096, 180877504, 181009984, 181139264,
+181272512, 181402688, 181532608, 181663168, 181795136, 181926592,
+182057536, 182190016, 182320192, 182451904, 182582336, 182713792,
+182843072, 182976064, 183107264, 183237056, 183368384, 183494848,
+183631424, 183762752, 183893824, 184024768, 184154816, 184286656,
+184417984, 184548928, 184680128, 184810816, 184941248, 185072704,
+185203904, 185335616, 185465408, 185596352, 185727296, 185859904,
+185989696, 186121664, 186252992, 186383552, 186514112, 186645952,
+186777152, 186907328, 187037504, 187170112, 187301824, 187429184,
+187562048, 187693504, 187825472, 187957184, 188087104, 188218304,
+188349376, 188481344, 188609728, 188743616, 188874304, 189005248,
+189136448, 189265088, 189396544, 189528128, 189660992, 189791936,
+189923264, 190054208, 190182848, 190315072, 190447424, 190577984,
+190709312, 190840768, 190971328, 191102656, 191233472, 191364032,
+191495872, 191626816, 191758016, 191888192, 192020288, 192148928,
+192282176, 192413504, 192542528, 192674752, 192805952, 192937792,
+193068608, 193198912, 193330496, 193462208, 193592384, 193723456,
+193854272, 193985984, 194116672, 194247232, 194379712, 194508352,
+194641856, 194772544, 194900672, 195035072, 195166016, 195296704,
+195428032, 195558592, 195690304, 195818176, 195952576, 196083392,
+196214336, 196345792, 196476736, 196607552, 196739008, 196869952,
+197000768, 197130688, 197262784, 197394368, 197523904, 197656384,
+197787584, 197916608, 198049472, 198180544, 198310208, 198442432,
+198573632, 198705088, 198834368, 198967232, 199097792, 199228352,
+199360192, 199491392, 199621696, 199751744, 199883968, 200014016,
+200146624, 200276672, 200408128, 200540096, 200671168, 200801984,
+200933312, 201062464, 201194944, 201326144, 201457472, 201588544,
+201719744, 201850816, 201981632, 202111552, 202244032, 202374464,
+202505152, 202636352, 202767808, 202898368, 203030336, 203159872,
+203292608, 203423296, 203553472, 203685824, 203816896, 203947712,
+204078272, 204208192, 204341056, 204472256, 204603328, 204733888,
+204864448, 204996544, 205125568, 205258304, 205388864, 205517632,
+205650112, 205782208, 205913536, 206044736, 206176192, 206307008,
+206434496, 206569024, 206700224, 206831168, 206961856, 207093056,
+207223616, 207355328, 207486784, 207616832, 207749056, 207879104,
+208010048, 208141888, 208273216, 208404032, 208534336, 208666048,
+208796864, 208927424, 209059264, 209189824, 209321792, 209451584,
+209582656, 209715136, 209845568, 209976896, 210106432, 210239296,
+210370112, 210501568, 210630976, 210763712, 210894272, 211024832,
+211156672, 211287616, 211418176, 211549376, 211679296, 211812032,
+211942592, 212074432, 212204864, 212334016, 212467648, 212597824,
+212727616, 212860352, 212991424, 213120832, 213253952, 213385024,
+213515584, 213645632, 213777728, 213909184, 214040128, 214170688,
+214302656, 214433728, 214564544, 214695232, 214826048, 214956992,
+215089088, 215219776, 215350592, 215482304, 215613248, 215743552,
+215874752, 216005312, 216137024, 216267328, 216399296, 216530752,
+216661696, 216790592, 216923968, 217054528, 217183168, 217316672,
+217448128, 217579072, 217709504, 217838912, 217972672, 218102848,
+218233024, 218364736, 218496832, 218627776, 218759104, 218888896,
+219021248, 219151936, 219281728, 219413056, 219545024, 219675968,
+219807296, 219938624, 220069312, 220200128, 220331456, 220461632,
+220592704, 220725184, 220855744, 220987072, 221117888, 221249216,
+221378368, 221510336, 221642048, 221772736, 221904832, 222031808,
+222166976, 222297536, 222428992, 222559936, 222690368, 222820672,
+222953152, 223083968, 223213376, 223345984, 223476928, 223608512,
+223738688, 223869376, 224001472, 224132672, 224262848, 224394944,
+224524864, 224657344, 224788288, 224919488, 225050432, 225181504,
+225312704, 225443776, 225574592, 225704768, 225834176, 225966784,
+226097216, 226229824, 226360384, 226491712, 226623424, 226754368,
+226885312, 227015104, 227147456, 227278528, 227409472, 227539904,
+227669696, 227802944, 227932352, 228065216, 228196288, 228326464,
+228457792, 228588736, 228720064, 228850112, 228981056, 229113152,
+229243328, 229375936, 229505344, 229636928, 229769152, 229894976,
+230030272, 230162368, 230292416, 230424512, 230553152, 230684864,
+230816704, 230948416, 231079616, 231210944, 231342016, 231472448,
+231603776, 231733952, 231866176, 231996736, 232127296, 232259392,
+232388672, 232521664, 232652608, 232782272, 232914496, 233043904,
+233175616, 233306816, 233438528, 233569984, 233699776, 233830592,
+233962688, 234092224, 234221888, 234353984, 234485312, 234618304,
+234749888, 234880832, 235011776, 235142464, 235274048, 235403456,
+235535936, 235667392, 235797568, 235928768, 236057152, 236190272,
+236322752, 236453312, 236583616, 236715712, 236846528, 236976448,
+237108544, 237239104, 237371072, 237501632, 237630784, 237764416,
+237895232, 238026688, 238157632, 238286912, 238419392, 238548032,
+238681024, 238812608, 238941632, 239075008, 239206336, 239335232,
+239466944, 239599168, 239730496, 239861312, 239992384, 240122816,
+240254656, 240385856, 240516928, 240647872, 240779072, 240909632,
+241040704, 241171904, 241302848, 241433408, 241565248, 241696192,
+241825984, 241958848, 242088256, 242220224, 242352064, 242481856,
+242611648, 242744896, 242876224, 243005632, 243138496, 243268672,
+243400384, 243531712, 243662656, 243793856, 243924544, 244054592,
+244187072, 244316608, 244448704, 244580032, 244710976, 244841536,
+244972864, 245104448, 245233984, 245365312, 245497792, 245628736,
+245759936, 245889856, 246021056, 246152512, 246284224, 246415168,
+246545344, 246675904, 246808384, 246939584, 247070144, 247199552,
+247331648, 247463872, 247593536, 247726016, 247857088, 247987648,
+248116928, 248249536, 248380736, 248512064, 248643008, 248773312,
+248901056, 249036608, 249167552, 249298624, 249429184, 249560512,
+249692096, 249822784, 249954112, 250085312, 250215488, 250345792,
+250478528, 250608704, 250739264, 250870976, 251002816, 251133632,
+251263552, 251395136, 251523904, 251657792, 251789248, 251919424,
+252051392, 252182464, 252313408, 252444224, 252575552, 252706624,
+252836032, 252968512, 253099712, 253227584, 253361728, 253493056,
+253623488, 253754432, 253885504, 254017216, 254148032, 254279488,
+254410432, 254541376, 254672576, 254803264, 254933824, 255065792,
+255196736, 255326528, 255458752, 255589952, 255721408, 255851072,
+255983296, 256114624, 256244416, 256374208, 256507712, 256636096,
+256768832, 256900544, 257031616, 257162176, 257294272, 257424448,
+257555776, 257686976, 257818432, 257949632, 258079552, 258211136,
+258342464, 258473408, 258603712, 258734656, 258867008, 258996544,
+259127744, 259260224, 259391296, 259522112, 259651904, 259784384,
+259915328, 260045888, 260175424, 260308544, 260438336, 260570944,
+260700992, 260832448, 260963776, 261092672, 261226304, 261356864,
+261487936, 261619648, 261750592, 261879872, 262011968, 262143424,
+262274752, 262404416, 262537024, 262667968, 262799296, 262928704,
+263061184, 263191744, 263322944, 263454656, 263585216, 263716672,
+263847872, 263978944, 264108608, 264241088, 264371648, 264501184,
+264632768, 264764096, 264895936, 265024576, 265158464, 265287488,
+265418432, 265550528, 265681216, 265813312, 265943488, 266075968,
+266206144, 266337728, 266468032, 266600384, 266731072, 266862272,
+266993344, 267124288, 267255616, 267386432, 267516992, 267648704,
+267777728, 267910592, 268040512, 268172096, 268302784, 268435264,
+268566208, 268696256, 268828096, 268959296, 269090368, 269221312,
+269352256, 269482688, 269614784, 269745856, 269876416, 270007616,
+270139328, 270270272, 270401216, 270531904, 270663616, 270791744,
+270924736, 271056832, 271186112, 271317184, 271449536, 271580992,
+271711936, 271843136, 271973056, 272105408, 272236352, 272367296,
+272498368, 272629568, 272759488, 272891456, 273022784, 273153856,
+273284672, 273415616, 273547072, 273677632, 273808448, 273937088,
+274071488, 274200896, 274332992, 274463296, 274595392, 274726208,
+274857536, 274988992, 275118656, 275250496, 275382208, 275513024,
+275643968, 275775296, 275906368, 276037184, 276167872, 276297664,
+276429376, 276560576, 276692672, 276822976, 276955072, 277085632,
+277216832, 277347008, 277478848, 277609664, 277740992, 277868608,
+278002624, 278134336, 278265536, 278395328, 278526784, 278657728,
+278789824, 278921152, 279052096, 279182912, 279313088, 279443776,
+279576256, 279706048, 279838528, 279969728, 280099648, 280230976,
+280361408, 280493632, 280622528, 280755392, 280887104, 281018176,
+281147968, 281278912, 281411392, 281542592, 281673152, 281803712,
+281935552, 282066496, 282197312, 282329024, 282458816, 282590272,
+282720832, 282853184, 282983744, 283115072, 283246144, 283377344,
+283508416, 283639744, 283770304, 283901504, 284032576, 284163136,
+284294848, 284426176, 284556992, 284687296, 284819264, 284950208,
+285081536]
```
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
index 78afa1cc5a3..2ff08bde2da 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
@@ -8,35 +8,35 @@ lang: zh-tw
-工作量證明不再是以太坊共識機制的基礎,這意味著挖礦已完結。 取而代之的是,以太坊由抵押以太幣的驗證者來保障安全。 你能從現在開始質押ETH. 閱讀更多關於合併、權益證明和質押的資訊。 此頁面僅為滿足對歷史的興趣。
+工作量證明不再是以太坊共識機制的基礎,這意味著挖礦已完結。 取而代之的是,以太坊由抵押以太幣的驗證者來保障安全。 你能從現在開始質押以太幣。 閱讀更多關於合併、權益證明和質押的資訊。 此頁面僅為滿足對歷史的興趣。
以太坊挖礦使用過一種稱為 Ethash 的演算法。 這個演算法的基本思路是,礦工嘗試使用蠻力計算找到一個隨機數輸入,使得產生的雜湊值小於一個取決於計算難度的閾值。 此難度等級可以動態調整,從而允許定期產生區塊。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更好地理解本頁內容,我們推薦你先閱讀[工作量證明共識](/developers/docs/consensus-mechanisms/pow)和[挖礦](/developers/docs/consensus-mechanisms/pow/mining)。
+為了更深入理解本頁,建議您先閱讀[工作量證明共識](/developers/docs/consensus-mechanisms/pow)和[挖礦](/developers/docs/consensus-mechanisms/pow/mining)的相關內容。
## Dagger Hashimoto {#dagger-hashimoto}
Dagger Hashimoto 是以太坊挖礦的先導研究演算法,現已被 Ethash 取代。 它是兩種不同演算法:Dagger 和 Hashimoto 的融合。 它只是一個曾經的研究實作,並在以太坊主網啟動時被 Ethash 取代。
-[Dagger](http://www.hashcash.org/papers/dagger.html) 需要產生一個[有向無環圖](https://en.wikipedia.org/wiki/Directed_acyclic_graph),並將其隨機片段雜湊在一起。 其核心原理是,每個隨機數只需要一個較大總資料樹中的一小部分。 挖礦禁止為每個隨機數重新計算子樹,因此需要儲存樹;但若僅為驗證單個隨機數,則可以重新計算。 Dagger 的設計目的是替代諸如 Scrypt 這類已有的演算法,這類演算法是記憶體密集型的,但很難驗證其記憶體密集程度何時增至可信的安全水平。 然而,Dagger 容易受到共享記憶體硬體加速的影响,因此被放棄,转而采用了其他研究途径。
+[Dagger](http://www.hashcash.org/papers/dagger.html) 牽涉到產生一個[有向無環圖](https://en.wikipedia.org/wiki/Directed_acyclic_graph),其隨機切片會被一起進行哈希運算。 其核心原理是,每個隨機數只需要一個較大總資料樹中的一小部分。 挖礦禁止為每個隨機數重新計算子樹,因此需要儲存樹;但若僅為驗證單個隨機數,則可以重新計算。 Dagger 的設計目的是替代諸如 Scrypt 這類已有的演算法,這類演算法是記憶體密集型的,但很難驗證其記憶體密集程度何時增至可信的安全水平。 然而,Dagger 容易受到共享記憶體硬體加速的影响,因此被放棄,转而采用了其他研究途径。
-[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) 演算法透過實現輸入/輸出捆綁的特性(即,記憶體讀取是挖礦過程中的限制因素)來增加對專用積體電路的抗性。 理論上來說,隨機存取記憶體比計算能力更容易獲取;已有價值數十億美元的經費投入用於研究針對不同使用案例的隨機存取記憶體最佳化,這些案例通常涉及近隨機存取模式(即「隨機存取記憶體」)。 因此,現有的隨機存取記憶體在評價演算法的能力上更接近最優。 Hashimoto 使用區塊鏈作為資料來源,同時滿足上述第 (1) 和第 (3) 條。
+[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) 是一種透過受 I/O 限制(亦即記憶體讀取是挖礦過程的限制因素)來增加 ASIC 抗性的演算法。 理論上來說,隨機存取記憶體比計算能力更容易獲取;已有價值數十億美元的經費投入用於研究針對不同使用案例的隨機存取記憶體最佳化,這些案例通常涉及近隨機存取模式(即「隨機存取記憶體」)。 因此,現有的隨機存取記憶體在評價演算法的能力上更接近最優。 Hashimoto 使用區塊鏈作為資料來源,同時滿足上述第 (1) 和第 (3) 條。
-Dagger-Hashimoto 是在 Dagger 和 Hashimoto 的基礎上改進而來的演算法版本。 Dagger Hashimoto 和 Hashimoto 的差別在於,Dagger Hashimoto 的資料來源並非是區塊鏈,而是自訂產生的資料集,並且該資料集每 N 個區塊基於區塊資料更新一次。 該資料集採用 Dagger 演算法產生,可為輕量用戶端的驗證演算法高效計算特定於每個隨機數的子集。 Dagger Hashimoto 演算法和 Dagger 演算法的差別在於,與原來的 Dagger 不同,用於查詢區塊的資料集只是暫時的,只會偶爾更新(例如每週更新一次)。 這意味著產生資料集的工作量接近於零,所以 Sergio Lerner 關於共享記憶體加速的論據變得微不足道。
+Dagger-Hashimoto 是在 Dagger 和 Hashimoto 的基礎上改進而來的演算法版本。 Dagger Hashimoto 和 Hashimoto 的差別在於,Dagger Hashimoto 的資料來源並非是區塊鏈,而是自訂產生的資料集,並且該資料集每 N 個區塊基於區塊資料更新一次。 該資料集採用 Dagger 演算法產生,可為輕量用戶端的驗證演算法高效計算特定於每個隨機數的子集。 Dagger Hashimoto 和 Dagger 的差別在於,與原來的 Dagger 不同,用於查詢區塊的資料集是半永久性的,只會偶爾更新(例如每週更新一次)。 這意味著產生資料集的工作量接近於零,所以 Sergio Lerner 關於共享記憶體加速的論據變得微不足道。
-有關 [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) 的更多資訊。
+更多關於 [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) 的資訊。
-## Ethash算法 {#ethash}
+## Ethash {#ethash}
Ethash 是在現已棄用的工作量證明架構下,實際用於真正的以太坊主網的挖礦演算法。 Ethash 實際上是為 Dagger Hashimoto 演算法進行重要更新後的一個特定版本命名的新名稱,但它仍然繼承了其前身的基本原理。 以太坊主網僅使用過 Ethash,而 Dagger Hashimoto 只是挖礦演算法的研發版本,且在以太坊主網開始挖礦前就已被取代。
-[有關 Ethash 的更多資訊](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash)。
+更多關於 [Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash) 的資訊。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/dapps/index.md b/public/content/translations/zh-tw/developers/docs/dapps/index.md
index e3aad125f3e..ac98d107f14 100644
--- a/public/content/translations/zh-tw/developers/docs/dapps/index.md
+++ b/public/content/translations/zh-tw/developers/docs/dapps/index.md
@@ -1,96 +1,96 @@
---
-title: 去中心化應用程式簡介
+title: 去中心化應用程式的技術性介紹
description:
lang: zh-tw
---
-去中心化應用程式 (dapp) 是建立在去中心化網路之上的應用程式,由[智慧型合約](/developers/docs/smart-contracts/)和前端使用者介面構成。 在以太坊上,如同開放式應用程式介面 (API) 一樣,智慧型合約具可存取性和透明性,因此你的去中心化應用程式甚至能包含他人已經編寫好的智慧型合約。
+去中心化應用程式 (dapp) 是建立在去中心化網路之上的應用程式,由 [智慧型合約](/developers/docs/smart-contracts/) 和前端使用者介面構成。 在以太坊上,如同開放式應用程式介面 (API) 一樣,智慧型合約具可存取性和透明性,因此你的去中心化應用程式甚至能包含他人已經編寫好的智慧型合約。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在學習去中心化應用程序之前,應該先瞭解[區塊鏈基本知識](/developers/docs/intro-to-ethereum/),並瞭解以太坊網路及其如何去中心化。
+在學習去中心化應用程式之前,您應先了解 [區塊鏈基礎](/developers/docs/intro-to-ethereum/),並閱讀有關以太坊網路及其去中心化方式的資訊。
-## 去中心化應用程式之定義 {#definition-of-a-dapp}
+## 去中心化應用程式的定義 {#definition-of-a-dapp}
去中心化應用程序的後端程式碼在去中心化點對點網路上運行。 與之相比,普通應用程序的後端程式碼在中心化伺服器上運行。
-去中心化應用程式的前端程式碼與使用者介面可以用任何語言編寫(就像普通應用程式一樣),以呼叫其後端。 此外,其前端能夠託管於任何去中心化儲存中,例如[星際檔案系統](https://ipfs.io/)。
+去中心化應用程式的前端程式碼與使用者介面可以用任何語言編寫(就像普通應用程式一樣),以呼叫其後端。 此外,其前端可以託管在去中心化儲存空間上,例如 [IPFS](https://ipfs.io/)。
-- **去中心化** -- 去中心化應用程式運行於以太坊上。以太坊是一個開放式公共去中心化平台,不受任何個人或群組控制
-- **確定性** - 去中心化應用程式總是執行相同函式,而與其執行環境無關
-- **圖靈完備** - 只要有所需的資源,去中心化應用程式就能執行任何操作
-- **隔離性** - 去中心化應用程式在稱為以太坊虛擬機的虛擬環境中執行,所以即使智慧型合約出現錯誤,也不會影響區塊鏈執行正常功能
+- **去中心化** - 去中心化應用程式在以太坊上運行,以太坊是一個開放的公共去中心化平台,沒有任何人或團體可以控制
+- **確定性** - 去中心化應用程式執行相同的功能,不受其執行環境影響
+- **圖靈完備** - 只要有必要的資源,去中心化應用程式就能執行任何操作
+- **隔離** - 去中心化應用程式在稱為以太坊虛擬機的虛擬環境中執行,如此一來,即使智慧型合約有錯誤,也不會妨礙區塊鏈網路的正常運作
### 關於智慧型合約 {#on-smart-contracts}
-在介紹去中心化應用程式之前,我們需要先認識智慧型合約,由於沒有更好的術語,我們用它來表示去中心化應用程式的後端。 欲查看細節概要,請查閱我們的[智慧型合約](/developers/docs/smart-contracts/)一節。
+在介紹去中心化應用程式之前,我們需要先認識智慧型合約,由於沒有更好的術語,我們用它來表示去中心化應用程式的後端。 如需詳細總覽,請前往我們的 [智慧型合約](/developers/docs/smart-contracts/) 專區。
智慧型合約是存在於以太坊區塊鏈上的程式,完全按照設定運行。 智慧型合約一旦部署於網路上後,你將無法更改它。 去中心化應用程式可以實現去中心化,因為控制它們的是編寫到合約內的邏輯,而不是任何個人或公司。 這也表示你必須非常謹慎地設計你的合約並進行全面測試。
-## 去中心化應用程式的開發優勢 {#benefits-of-dapp-development}
+## 開發去中心化應用程式的優點 {#benefits-of-dapp-development}
-- **零下線時間** -- 一旦智慧型合約部屬到區塊鏈上,整個網路將始終能夠為想要與此合約互動的客戶提供服務。 因此,惡意行為者無法發動針對單獨去中心化應用程式的拒絕服務攻擊。
-- **隱私** -- 你無需提供真實身份,即可部署去中心化應用程式或與之互動。
-- **抗審查** -- 網路上的任何單獨實體都無法阻止使用者提交交易、部署去中心化應用程式並讀取區塊鏈中的資料。
-- **資料完整性** -- 藉由加密基元技術,儲存於區塊鏈上的資料具不可變性及無爭議性。 惡意行為者無法假造已公開的交易或其他資料。
-- **無需信任的計算/可驗證的行為** – 可以對智慧型合約進行分析且可以保障其按照可預見的方式執行,而無需信任中心化管理機構。 在傳統模式下,情況並非如此;例如,在使用線上銀行系統時,我們必須信任此等金融機構不會濫用我們的財物資料,不會竄改紀錄或者不會受到駭客攻擊。
+- **零停機時間** – 智慧型合約一旦部署到區塊鏈上,整個網路將始終能夠為希望與合約互動的用戶端提供服務。 因此,惡意行為者無法發動針對單獨去中心化應用程式的拒絕服務攻擊。
+- **隱私** – 您不需要提供真實世界的身分即可部署去中心化應用程式或與其互動。
+- **抗審查** – 網路上的任何單一實體都無法阻止使用者提交交易、部署去中心化應用程式,或從區塊鏈讀取資料。
+- **完整的資料完整性** – 歸功於密碼學基元,儲存在區塊鏈上的資料是不可變且無可爭議的。 惡意行為者無法假造已公開的交易或其他資料。
+- **無需信任的運算/可驗證的行為** – 智慧型合約可以被分析,並保證以可預測的方式執行,無需信任中心化機構。 在傳統模式下,情況並非如此;例如,在使用線上銀行系統時,我們必須信任此等金融機構不會濫用我們的財物資料,不會竄改紀錄或者不會受到駭客攻擊。
-## 去中心化應用程式的開發弊端 {#drawbacks-of-dapp-development}
+## 開發去中心化應用程式的缺點 {#drawbacks-of-dapp-development}
-- **維護** -- 因為發佈到區塊鏈上的程式碼與資料更加難以修改,去中心化應用程式維護起來難度更大。 一旦部署去中心化應用程式後,開發者將難以更新去中心化應用程式(或其儲存的基礎資料),即便在舊版本中發現了錯誤或安全風險。
-- **效能開銷** – 效能開銷非常之高,並且擴容極其困難。 為了達成以太坊追求的高水平安全性、完整性、透明性及可靠性,每個節點都運行並儲存每一筆交易。 除此之外,達成權益證明共識也需要時間。
-- **網路壅塞** -- 當一個去中心化應用程式佔用過多計算資源時,整個網路會變得壅塞。 目前,以太坊網路能每秒處理大約 10-15 筆交易,但如果發送交易的速度快於處理速度,未確認的交易池將快速暴增。
-- **使用者體驗** – 可能很難設計出方便使用的體驗,因為普通終端使用者可能會發現難以設定透過真正安全的方式與區塊鏈互動所需的工具棧。
-- **中心化** -- 方便使用且方便開發的解決方案建立於以太坊基礎層上,最終它們可能在某些方面看起來像是中心化服務。 例如,此等服務可能在伺服器端儲存金鑰或其他敏感資訊,通過中心化伺服器支援前端,或者在將其寫入區塊鏈前在中心化伺服器上運行重要業務邏輯。 中心化會消除許多(如果不是全部)區塊鏈相較於傳統模式的優勢。
+- **維護** – 去中心化應用程式可能更難維護,因為發佈到區塊鏈上的程式碼和資料更難修改。 一旦部署去中心化應用程式後,開發者將難以更新去中心化應用程式(或其儲存的基礎資料),即便在舊版本中發現了錯誤或安全風險。
+- **效能開銷** – 效能開銷龐大,且擴展非常困難。 為了達成以太坊追求的高水平安全性、完整性、透明性及可靠性,每個節點都運行並儲存每一筆交易。 除此之外,達成權益證明共識也需要時間。
+- **網路壅塞** – 當一個去中心化應用程式使用過多運算資源時,整個網路都會堵塞。 目前,以太坊網路能每秒處理大約 10-15 筆交易,但如果發送交易的速度快於處理速度,未確認的交易池將快速暴增。
+- **使用者體驗** – 可能比較難打造使用者友善的體驗,因為一般終端使用者可能會覺得,要以真正安全的方式與區塊鏈互動,所需設定的工具堆疊太過困難。
+- **中心化** – 建構在以太坊底層之上、對使用者和開發者友善的解決方案,最終看起來可能還是像中心化服務。 例如,此等服務可能在伺服器端儲存金鑰或其他敏感資訊,通過中心化伺服器支援前端,或者在將其寫入區塊鏈前在中心化伺服器上運行重要業務邏輯。 中心化會消除許多(如果不是全部)區塊鏈相較於傳統模式的優勢。
-## 想透過實際視覺學習? {#visual-learner}
+## 想透過視覺方式學習? {#visual-learner}
## 用於建立去中心化應用程式的工具 {#dapp-tools}
-**Scaffold-ETH _- 透過可適應你的智慧型合約的前端,快速體驗 Solidity。_**
+**Scaffold-ETH _- 使用可適應您智慧型合約的前端,快速體驗 Solidity。_**
-- [Github](https://github.com/scaffold-eth/scaffold-eth-2)
-- [範例去中心化應用程式](https://punkwallet.io/)
+- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2)
+- [去中心化應用程式範例](https://punkwallet.io/)
-**Create Eth App _- 通過一條指令建立以太坊支援的應用程式。_**
+**Create Eth App _- 用一個指令建立以太坊應用程式。_**
-- [Github](https://github.com/paulrberg/create-eth-app)
+- [GitHub](https://github.com/paulrberg/create-eth-app)
-**One Click Dapp _ - FOSS 工具,用來透過[應用程式二進位介面](/glossary/#abi)生成去中心化應用程式前端。_**
+**One Click Dapp _- 從 [ABI](/glossary/#abi) 產生去中心化應用程式前端的 FOSS 工具。_**
- [oneclickdapp.com](https://oneclickdapp.com)
-- [Github](https://github.com/oneclickdapp/oneclickdapp-v1)
+- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1)
-**Etherflow_ -- FOSS 工具,以太坊開發者可用其測試節點,在瀏覽器中撰寫並偵錯遠端程序呼叫。_**
+**Etherflow _- 供以太坊開發者測試其節點,以及從瀏覽器編寫與偵錯 RPC 呼叫的 FOSS 工具。_**
- [etherflow.quiknode.io](https://etherflow.quiknode.io/)
- [GitHub](https://github.com/abunsen/etherflow)
-**thirdweb _- 用於 Web3 開發的各種語言的軟體開發套件、智慧型合約、工具及基礎設施。_**
+**thirdweb _- 用於 web3 開發的各種語言 SDK、智慧型合約、工具和基礎設施。_**
- [首頁](https://thirdweb.com/)
- [文件](https://portal.thirdweb.com/)
- [GitHub](https://github.com/thirdweb-dev/)
-**Crossmint _- 企業級 Web3 開發平台,可用於部署智慧型合約,支援信用卡和跨鏈支付,並使用應用程式介面來建立、分發、銷售、儲存和編輯非同質化代幣。_**
+**Crossmint _- 企業級 web3 開發平台,可部署智慧型合約、啟用信用卡和跨鏈支付,並使用 API 建立、分發、銷售、儲存和編輯 NFT。_**
- [crossmint.com](https://www.crossmint.com)
- [文件](https://docs.crossmint.com)
- [Discord](https://discord.com/invite/crossmint)
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [探索去中心化應用程式](/apps)
- [Web 3.0 應用程式的架構](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-- [-2021 版去中心化應用程式指南](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_
-- [去中心化應用程式為何?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_
-- [熱門去中心化應用程式](https://www.alchemy.com/dapps) - _Alchemy_
+- [2021 年去中心化應用程式指南](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_
+- [什麼是去中心化應用程式?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_
+- [熱門的去中心化應用程式](https://www.alchemy.com/dapps) - _Alchemy_
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [以太坊堆疊簡介](/developers/docs/ethereum-stack/)
-- [開發架構](/developers/docs/frameworks/)
+- [以太坊技術堆疊介紹](/developers/docs/ethereum-stack/)
+- [開發框架](/developers/docs/frameworks/)
diff --git a/public/content/translations/zh-tw/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/zh-tw/developers/docs/data-and-analytics/block-explorers/index.md
index cb5915f60c4..b97697a2465 100644
--- a/public/content/translations/zh-tw/developers/docs/data-and-analytics/block-explorers/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-and-analytics/block-explorers/index.md
@@ -7,33 +7,31 @@ sidebarDepth: 3
區塊瀏覽器是你存取以太坊資料的入口。 你可以使用區塊瀏覽器來查看區塊、交易、驗證者、帳戶及其他鏈上活動的即時資料。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-你應該瞭解以太坊的基本概念,以便能夠理解區塊瀏覽器提供的資料。 推薦你從[以太坊簡介](/developers/docs/intro-to-ethereum/)開始。
+你應該瞭解以太坊的基本概念,以便能夠理解區塊瀏覽器提供的資料。 從[以太坊簡介](/developers/docs/intro-to-ethereum/)開始。
## 服務 {#services}
-- [Etherscan](https://etherscan.io/) - 可以用來查詢以太坊主網和 Sepolia 測試網上的資料的區塊瀏覽器
-- [3xpl](https://3xpl.com/ethereum) - 無廣告、開源的以太坊區塊瀏覽器,允許下載自己的資料集
-- [Beaconcha.in](https://beaconcha.in/) - 開源的區塊瀏覽器,適用於以太坊主網和 Sepolia 測試網
-- [Blockchair](https://blockchair.com/ethereum) -_也提供西班牙文、法文、義大利文、荷蘭文、葡萄牙文、俄文、中文及波斯文版_
-- [Blockscout](https://blockscout.com/) - 專注於以下網路:Gnosis、Optimism、ZKsync 等
+- [Etherscan](https://etherscan.io/) - _亦提供中文、韓文、俄文及日文版本_
+- [3xpl](https://3xpl.com/ethereum)
+- [Beaconcha.in](https://beaconcha.in/)
+- [Blockchair](https://blockchair.com/ethereum) - _亦提供西班牙文、法文、義大利文、荷蘭文、葡萄牙文、俄文、中文及波斯文版本_
+- [Blockscout](https://eth.blockscout.com/)
- [Chainlens](https://www.chainlens.com/)
-- [DexGuru Block Explorer](https://ethereum.dex.guru/)
-- [Etherchain](https://www.etherchain.org/) - 以太坊主網的區塊瀏覽器
-- [Ethernow](https://www.ethernow.xyz/)
-- [Ethplorer](https://ethplorer.io/) - 專注於代幣和以太坊主網及 Sepolia 網路的區塊瀏覽器
+- [DexGuru 區塊瀏覽器](https://ethereum.dex.guru/)
+- [Etherchain](https://www.etherchain.org/)
+- [Ethplorer](https://ethplorer.io/) - _亦提供中文、西班牙文、法文、土耳其文、俄文、韓文及越南文版本_
- [EthVM](https://www.ethvm.com/)
- [OKLink](https://www.oklink.com/eth)
-- [Rantom](https://rantom.app/)
- [Ethseer](https://ethseer.io)
-- [Otterscan](https://otterscan.io/) - 開源的區塊瀏覽器替代品,專注於以太坊主網及 Sepolia 網路
## 開源工具 {#open-source-tools}
+- [Otterscan](https://otterscan.io/)
- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan)
-## 數據資料 {#data}
+## 資料 {#data}
以太坊的設計是透明的,因此一切都是可驗證的。 區塊瀏覽器提供了獲取此資訊的介面。 如果你需要這些資料,這適用於以太坊主網和測試網。 資料被分為執行資料和共識資料。 執行資料指的是特定區塊中已被執行的交易。 共識資料指的是區塊本身及提出區塊的驗證者。
@@ -63,7 +61,7 @@ sidebarDepth: 3
- 父雜湊 - 目前區塊之前區塊的雜湊
- StateRoot - 默克爾樹的根雜湊,存儲了整個系統的狀態
-### Gas費 {#gas}
+### Gas {#gas}
區塊瀏覽器不僅會為你提供有關交易和區塊中燃料使用情況的資料,而且有些還會提供有關網路當前燃料價格的資訊。 這將幫助瞭解網路使用情況、提交安全交易並且不會超支燃料。 尋找可以幫助你將此資訊輸入產品介面的應用程式介面。 燃料的特定資料包括:
@@ -78,7 +76,7 @@ sidebarDepth: 3
區塊瀏覽器已成為追蹤交易進度的常見方式。 這是因為你可以取得的詳細程度提供了額外的確定性。 交易資料包括:
-**標準數據**
+**標準資料**
- 交易雜湊 - 當交易被提交時產生的雜湊
- 狀態 - 指示交易為待處理、失敗還是成功
@@ -90,12 +88,12 @@ sidebarDepth: 3
- 價值 - 轉移的以太幣總價值
- 交易費用 - 支付給驗證者處理交易的金額(計算方法為燃料價格\*使用的燃料)
-**進階數據**
+**進階資料**
- 燃料限制 - 此交易最高可消耗多少單位的燃料
- 使用的燃料 - 交易實際消耗的燃料單位量
- 燃料價格 - 每單位燃料的價格
-- 隨機數 - `from` 地址的交易編號(注意,隨機數從 0 開始算,所以隨機數 `100` 實際上是此帳戶提交的第 101 筆交易)
+- Nonce - `from` 地址的交易序號(請注意此序號從 0 開始,因此序號為 `100` 的交易實際上是此帳戶提交的第 101 筆交易)
- 輸入資料 - 交易所需的任何額外資訊
### 帳戶 {#accounts}
@@ -147,7 +145,7 @@ sidebarDepth: 3
## 共識層資料 {#consensus-layer-data}
-### 時期 {#epoch}
+### 時期(epoch) {#epoch}
由於安全考量,會在每個時期(每 6.4 分鐘)結束時建立隨機化驗證者委員會。 時期資料包含:
@@ -196,7 +194,7 @@ sidebarDepth: 3
- 時隙 - 提議區塊的時隙
- 證明 - 時隙中包含的證明數量 - 證明就像投票一樣,表示區塊已準備好進入信標鏈
-### 驗證者 {#validators}
+### 驗證程式 {#validators}
驗證者負責在時隙內提議區塊並證明區塊。
@@ -238,21 +236,19 @@ sidebarDepth: 3
## 區塊瀏覽器 {#block-explorers}
-- [Etherscan](https://etherscan.io/) - 可用於擷取以太坊主網及 Sepolia 測試網資料的區塊瀏覽器
-- [3xpl](https://3xpl.com/ethereum) - 一個允許下載其資料集的無廣告開源以太坊瀏覽器
-- [Beaconcha.in](https://beaconcha.in/) - 用於以太坊主網及 Sepolia 測試網的開源區塊瀏覽器
-- [Blockchair](https://blockchair.com/ethereum) - 最私密的以太坊瀏覽器。 也用於排序和篩選(記憶體池)資料
-- [Etherchain](https://www.etherchain.org/) - 以太坊主網的區塊瀏覽器
-- [Ethplorer](https://ethplorer.io/) - 專為以太坊主網及 Sepolia 測試網代幣打造的區塊瀏覽器
-- [Rantom](https://rantom.app/) - 方便使用的開源去中心化金融及非同質化代幣交易檢視器,可提供詳細的訊息
-- [Ethernow](https://www.ethernow.xyz/) - 即時交易瀏覽器,讓你能夠查看以太坊主網鏈前層
+- [Etherscan](https://etherscan.io/) - 一款可用於擷取以太坊主網與測試網資料的區塊瀏覽器
+- [3xpl](https://3xpl.com/ethereum) - 一個無廣告的開源以太坊瀏覽器,可下載其資料集
+- [Beaconcha.in](https://beaconcha.in/) - 一款用於以太坊主網與測試網的開源區塊瀏覽器
+- [Blockchair](https://blockchair.com/ethereum) - 隱私性最高的以太坊瀏覽器。 也用於排序和篩選(記憶體池)資料
+- [Etherchain](https://www.etherchain.org/) - 一款以太坊主網的區塊瀏覽器
+- [Ethplorer](https://ethplorer.io/) - 一款專注於以太坊主網與 Kovan 測試網代幣的區塊瀏覽器
## 延伸閱讀 {#further-reading}
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
- [交易](/developers/docs/transactions/)
-- [帳戶](/developers/docs/accounts/)
+- [賬戶](/developers/docs/accounts/)
- [網路](/developers/docs/networks/)
diff --git a/public/content/translations/zh-tw/developers/docs/data-and-analytics/index.md b/public/content/translations/zh-tw/developers/docs/data-and-analytics/index.md
index 07dda6f3493..e76c1d371a7 100644
--- a/public/content/translations/zh-tw/developers/docs/data-and-analytics/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-and-analytics/index.md
@@ -1,55 +1,72 @@
---
-title: 數據分析
+title: 資料與分析
description: 如何獲取鏈上分析和資料以供你的去中心化應用程式使用
lang: zh-tw
---
-## 簡介 {#Introduction}
+## 介紹 {#Introduction}
隨著網路使用量的增長,鏈上資料中將存在越來越多有價值的信息。 隨著資料量的迅速增加,計算和匯總這些資訊以報告或驅動去中心化應用程式可能變得非常耗時且繁重。
利用現有的資料提供者可以加快開發過程,產生更準確的結果,並減少持續的維護工作。 這將使團隊能夠專注於其專案要提供的核心功能。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-你應該瞭解[區塊瀏覽器](/developers/docs/data-and-analytics/block-explorers/)的基本概念,以便更好地理解在資料分析背景中如何使用它們。 此外,熟悉[索引](/glossary/#index)的概念以瞭解它們對系統設計所帶來的好處。
+您應了解[區塊瀏覽器](/developers/docs/data-and-analytics/block-explorers/)的基本概念,以便更清楚如何在資料分析情境中使用它們。 此外,請熟悉[索引](/glossary/#index)的概念,以了解其為系統設計帶來的好處。
-在架構基礎方面,瞭解[應用程式介面](https://www.wikipedia.org/wiki/API)和 [REST](https://www.wikipedia.org/wiki/Representational_state_transfer) 的基本概念,即使只是理論上的也很重要。
+在架構基礎方面,即使只是理論上,也應了解什麼是 [API](https://www.wikipedia.org/wiki/API) 和 [REST](https://www.wikipedia.org/wiki/Representational_state_transfer)。
## 區塊瀏覽器 {#block-explorers}
-許多[區塊瀏覽器](/developers/docs/data-and-analytics/block-explorers/)提供 [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [應用程式介面](https://www.wikipedia.org/wiki/API)閘道,這些閘道能夠讓開發者查看區塊、交易、驗證者、帳戶及其他鏈上活動的即時資料。
+許多[區塊瀏覽器](/developers/docs/data-and-analytics/block-explorers/)提供 [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [應用程式介面 (API)](https://www.wikipedia.org/wiki/API) 閘道,讓開發者能夠即時檢視區塊、交易、驗證程式、帳戶及其他鏈上活動的資料。
-開發者可以進一步處理和轉換這些資料,以提供使用者獨特的見解和與[區塊鏈](/glossary/#blockchain)的互動。 例如,[Etherscan](https://etherscan.io) 在每個 12 秒時隙都提供執行和共識資料。
+開發者接著可以處理並轉換這些資料,為使用者提供與[區塊鏈](/glossary/#blockchain)的獨特見解和互動。 例如,[Etherscan](https://etherscan.io) 和 [Blockscout](https://eth.blockscout.com) 為每個 12 秒的時隙提供執行和共識資料。
-## 圖表 {#the-graph}
+## The Graph {#the-graph}
-[Graph Network](https://thegraph.com/) 是一個去中心化的索引協議,用於組織區塊鏈資料。 與其建立和管理鏈下的集中式資料儲存來匯總鏈上資料,使用 The Graph 可以讓開發者構建完全在公共基礎設施上運行的無伺服器應用程式。
+[The Graph](https://thegraph.com/) 是一種索引協定,可透過稱為子圖的開放式應用程式介面 (API) 提供查詢區塊鏈資料的簡單方法。
-透過使用 [GraphQL](https://graphql.org/),開發者可以查詢稱為子圖的精選開放應用程式介面,以獲取驅動其去中心化應用程式所需的必要資訊。 透過查詢這些已索引的子圖,報告及去中心化應用程式不僅能獲得效能和可擴充性的好處,還能享受由網路共識提供的內建準確性。 隨著新改進和/或子圖新增至網路中,你的專案可以迅速迭代,以利用這些增強功能。
+透過The Graph,開發者得益於:
-## 用戶的多樣化
+- 去中心化索引:透過多個索引者索引區塊鏈資料,從而消除任何單點故障
+- GraphQL 查詢:提供强大的 GraphQL 介面用於查詢已索引資料,使資料檢索非常便捷
+- 自訂:為轉換和儲存區塊鏈資料定義您自己的邏輯,並重複使用其他開發者在 The Graph 網路上發布的子圖。
-[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity/)對以太坊網路的整體健康至關重要,因為它提供了針對錯誤和漏洞的韌性。 目前有幾個用戶端多樣性儀表板,包括 [clientdiversity.org](https://clientdiversity.org/)、[rated.network](https://www.rated.network)、[supermajority.info](https://supermajority.info//) 和 [Ethernodes](https://ethernodes.org/)。
+請遵循此份[快速入門](https://thegraph.com/docs/en/quick-start/)指南,在 5 分鐘內建立、部署及查詢子圖。
+
+## 用戶端多樣性 {#client-diversity}
+
+[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity/)對以太坊網路的整體健康至關重要,因為它提供了應對程式錯誤和漏洞的韌性。 目前有數個用戶端多樣性儀表板,包括 [clientdiversity.org](https://clientdiversity.org/)、[rated.network](https://www.rated.network)、[supermajority.info](https://supermajority.info//) 和 [Ethernodes](https://ethernodes.org/)。
## Dune Analytics {#dune-analytics}
-[Dune Analytics](https://dune.com/) 將區塊鏈資料預處理成關聯資料庫 (DuneSQL) 表格,允許使用者使用 SQL 查詢區塊鏈資料並根據查詢結果建立儀表板。 鏈上資料組織成 4 個原始表格:`blocks`、`transactions`、(事件)`logs` 和(呼叫)`traces`。 常見的合約和協定已被解碼,而每個合約和協定都有自己的事件和呼叫表格集。 這些事件和呼叫表格被進一步處理並按協定類型組織成抽象表格,例如去中心化交易所、借貸、穩定幣等。
+[Dune Analytics](https://dune.com/) 會將區塊鏈資料預處理為關聯式資料庫 (DuneSQL) 表格,讓使用者能使用 SQL 查詢區塊鏈資料,並根據查詢結果建立儀表板。 鏈上資料被組織成 4 個原始資料表:`blocks`、`transactions`、(事件) `logs` 和 (呼叫) `traces`。 常見的合約和協定已被解碼,而每個合約和協定都有自己的事件和呼叫表格集。 這些事件和呼叫表格被進一步處理並按協定類型組織成抽象表格,例如去中心化交易所、借貸、穩定幣等。
+
+## SQD {#sqd}
+
+[SQD](https://sqd.dev/) 是一個去中心化的超可擴充資料平台,經過最佳化,可有效率、無需許可地存取大量資料。 它目前提供歷史鏈上資料,包括事件日志、交易收據、軌跡以及每筆交易的狀態差異。 SQD 提供强大的工具包,用於創建自訂資料提取和處理管道,使索引速度達到最高每秒 15 萬區塊。
+
+若要開始使用,請瀏覽[文件](https://docs.sqd.dev/)或查看您可使用 SQD 建置的 [EVM 範例](https://github.com/subsquid-labs/squid-evm-examples)。
## SubQuery 網路 {#subquery-network}
-[SubQuery](https://subquery.network/) 是一個領先的資料索引器服務,為開發者提供快速、可靠、去中心化且自訂的應用程式介面以支援其 Web3 專案。 SubQuery 賦能來自超過 165 個生態系統(包括以太坊)的開發者,提供豐富的索引資料,以構建直觀且沉浸式的使用者體驗。 SubQuery 網路為你提供銳不可當、堅韌且有去中心化基礎設施網路的應用程式。 使用 SubQuery 的區塊鏈開發者工具組,構建未來的 Web3 應用程式,無需花時間為資料處理活動建立自訂後端。
+[SubQuery](https://subquery.network/) 是領先的資料索引器,為開發者的 web3 專案提供快速、可靠、去中心化且客製化的應用程式介面 (API)。 SubQuery 賦能來自超過 165 個生態系統(包括以太坊)的開發者,提供豐富的索引資料,以構建直觀且沉浸式的使用者體驗。 SubQuery 網路為你提供銳不可當、堅韌且有去中心化基礎設施網路的應用程式。 使用 SubQuery 的區塊鏈開發者工具組,構建未來的 Web3 應用程式,無需花時間為資料處理活動建立自訂後端。
+
+若要開始,請瀏覽 [Ethereum 快速入門指南](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html),以在本地 Docker 環境中,於幾分鐘內開始為以太坊區塊鏈資料建立索引進行測試,然後再於 [SubQuery 的託管服務](https://managedservice.subquery.network/)或 [SubQuery 的去中心化網路](https://app.subquery.network/dashboard)上線。
-首先,請瀏覽[以太坊快速入門指南](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html),在本地 Docker 環境中快速開始索引以太坊區塊鏈資料以進行測試,然後再上線到 [SubQuery 的受管理服務](https://managedservice.subquery.network/) 或 [SubQuery 的去中心化網路](https://app.subquery.network/dashboard)。
+## EVM 查詢語言 {#evm-query-language}
-## Ethernow - 記憶體池資料程式 {#ethernow}
-[Blocknative](https://www.blocknative.com/) 提供了對其以太坊歷史[記憶體池資料存檔](https://www.ethernow.xyz/mempool-data-archive)的開放存取。 這使研究人員和社群公益專案能夠探索以太坊主網的鏈前層。 該資料集得到積極維護,代表了以太坊生態系統中記憶體池交易事件的最全面歷史紀錄。 請參見 [Ethernow](https://www.ethernow.xyz/) 瞭解更多資訊。
+以太坊虛擬機查詢語言 (EQL) 是一種類似 SQL 的語言,旨在查詢 EVM 鏈的資訊。 EQL 的目標是對 EVM 鏈一等公民(區塊、帳戶和交易)進行複雜的關聯查詢,同時為開發者和研究者提供日常使用的人類工程學語法。 透過 EQL,開發者可以使用熟悉的類似 SQL 的語法獲取區塊鏈資料,無需複雜的樣板代碼。 EQL 支援標準區塊鏈資料請求(例如在以太坊上檢索帳戶的 nonce 和餘額或獲取當前的區塊大小和時間戳),並且正在不斷地添加對更多複雜請求和功能的支援。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [Graph Network 概覽](https://thegraph.com/docs/en/about/)
-- [Graph Query 訓練場](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current)
-- [EtherScan 上的應用程式介面程式碼範例](https://etherscan.io/apis#contracts)
+- [探索加密資料 I:資料流架構](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures)
+- [Graph 網路概觀](https://thegraph.com/docs/en/about/)
+- [Graph 查詢遊樂場](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current)
+- [Etherscan 上的應用程式介面 (API) 程式碼範例](https://etherscan.io/apis#contracts)
+- [Blockscout 上的應用程式介面 (API) 文件](https://docs.blockscout.com/devs/apis)
- [Beaconcha.in 信標鏈瀏覽器](https://beaconcha.in)
- [Dune 基礎知識](https://docs.dune.com/#dune-basics)
- [SubQuery 以太坊快速入門指南](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html)
+- [SQD 網路概觀](https://docs.sqd.dev/)
+- [EVM 查詢語言](https://eql.sh/blog/alpha-release-notes)
diff --git a/public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
new file mode 100644
index 00000000000..421855810a5
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
@@ -0,0 +1,118 @@
+---
+title: 區塊鏈資料儲存策略
+description: 有幾種方法透過區塊鏈儲存資料 此文章將會比較幾種儲存策略,成本、權衡以及安全適用的條件。
+lang: zh-tw
+---
+
+儲存資料的方法有幾種,直接上鏈儲存或是以某種被鏈保護的方式儲存:
+
+- EIP-4844 blobs
+- Calldata
+- 鏈下與L1的機制
+- 合約“程式碼”
+- 活動
+- EVM 儲存
+
+依據幾項指標來選擇使用什麼方法
+
+- 資訊的來源 Calldata裡的資訊是無法直接從區塊鏈上傳來
+- 資訊的目的地 呼叫資料僅存在於包含它的交易中。 Events 在鏈上無法取得
+- 大家願意忍受多少麻煩呢? 全方位的節點可以比網頁程式跑的light client做更多的處理。
+- 讓所有的節點可以很簡單的獲得資訊是必要的嗎?
+- 安全必要條件
+
+## 安全必要條件{#security-requirements}
+
+總的來說,資訊安全由三個屬性構成:
+
+- _保密性_,沒有被授權的單位是無法讀取資訊的。 這在很多案例中是很重要的,但不是在這。 _在區塊鏈上沒有秘密_。 區塊鏈行得通是因為任何人都可以驗證交易狀態,所以無法直接用來儲存秘密, 有幾個方法可以在鏈上儲存機敏資料,但是都必須依賴一些鏈下的元件,例如:至少一把密鑰,
+
+- _完整性_,資訊正確,無法被未授權的單位或未授權的方法改變,例如,轉帳 [ERC-20 tokens](https://eips.ethereum.org/EIPS/eip-20#events) 不發`Transfer` event。 在區塊鏈上,為了確保完整性,每個節點都會驗證每個狀態的改變。
+
+- _可用性_,任何被授權的單位皆可取得資訊, 在鏈上,通常為了達到在所有 [full node](https://ethereum.org/developers/docs/nodes-and-clients#full-node)上可以獲得資訊可以獲得資訊,
+
+不同的解決方案都有優秀的完整性,因為hashes 都會上到L1上。 而且,他們有各自的可用性保證。
+
+## 先決條件 {#prerequisites}
+
+你應該對 [區塊鏈基礎](/developers/docs/intro-to-ethereum/) 有良好的理解, 同時也建議讀者熟悉[blocks](/developers/docs/blocks/), [transactions](/developers/docs/transactions/) ,和相關的主題。
+
+## EIP-4844 blobs {#eip-4844-blobs}
+
+從 [坎昆升級](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) 開始,以太坊納入了 [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844),讓以太坊上的資料 blobs可以存在一小段時間(大約 [18 天](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration))。 儘管是相同的機制,Blobs根據[execution gas](/developers/docs/gas) 有不同的計價, 這是一個發布暫時性資料的便宜方法。
+
+主要的EIP-4844 blobs應用場景是 rollups 發布發交易。 [Optimistic rollups](/developers/docs/scaling/optimistic-rollups) 需要發布交易到鏈上, 這些交易在[挑戰期間](https://docs.optimism.io/connect/resources/glossary#challenge-period) 都必須是讓所有人可得,讓[validators](https://docs.optimism.io/connect/resources/glossary#validator) 把 [sequencer](https://docs.optimism.io/connect/resources/glossary#sequencer) 在rollup時發布的state root錯誤有機會做修正。
+
+一旦挑戰期過了而且state root 也已經進入最終狀態,最後獲得這些交易的方法是複製鏈的現有狀態。 只需要少數的處理,從鏈的節點上也可以取得這個狀態, 交易資訊仍應該存在其他地方,像是 [區塊瀏覽器](/developers/docs/data-and-analytics/block-explorers),但不需要對以太坊的抗審查付費。
+
+[Zero-knowledge rollups](/developers/docs/scaling/zk-rollups/#data-availability) 也會發布交易資訊讓其他的節點去複製現有的狀態以及有效性證明,但這也只是在短時間內可以取得。
+
+EIP-4844 寫入的費用大約每byte 1wei (10-18 ETH),相較於 [每筆交易21000 execution gas基本交易費用,包含blobs 資料寫入、花費](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index) 微乎其微可忽略不計。 可以從此查看目前EIP-4844 的價格[blobscan.com](https://blobscan.com/blocks)。
+
+Rollups常見的blobs 發布地址
+
+| Rollup | Mailbox address |
+| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
+| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) |
+| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
+| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) |
+
+## Calldata {#calldata}
+
+Calldata 是交易中一起發送的bytes中的一部分, 將區塊鏈上的永久紀錄儲存於包含這筆交易的區塊之中。
+
+這是在區塊鏈上儲存永久資料最經濟的方法, 每byte的不是4 execution gas(假設是0 byte) 就是 16 gas(其他數字). 一般來說資料是被壓縮過的,每個byte的價格會差不多,每byte平均花費15.95gas。
+
+撰文當下,每 gas 價格為 12 gwei,且每 ETH 為 2300$,花費約為每 kb 45 分錢。 因為這是在EIP-4844出現前最便宜的rollups 儲存交易資訊的方式,這些資訊用來提供[錯誤挑戰](https://docs.optimism.io/stack/protocol/overview#fault-proofs),但是不能直接從鏈上取得。
+
+以下是常見的rollups 發布交易時使用的地址:
+
+| Rollup | Mailbox address |
+| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
+| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) |
+| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
+| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) |
+
+## 鏈下與L1 的機制 {#offchain-with-l1-mechs}
+
+根據你對安全的取捨,可以將資料放在別處並運用機制確保資料可取得, 需要具備以下兩個條件才可以達成:
+
+1. 發布[hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function) 到鏈上,叫做_input commitment_, 這是單個 32-byte 的字,不是很貴, 只要輸入的承諾是確實存在的,完整性就會被確保,因為不可能找到其他資料會有相同的hash, 因此,若提供錯誤的資料,會馬上被發現。
+
+2. 有個確保資料可取得性的機制, 舉例來說,在 [Redstone](https://redstone.xyz/docs/what-is-redstone)任何節點都可以提交資料可取得的挑戰, 若sequencer沒有在鏈上即時回應,輸入的commitment就會被丟棄,因此會認爲這些資訊是從來沒有發布過的。
+
+在Optimistic rollup上這樣的機制是可以被接受的,因為我們已經仰賴最少有一個對state root誠實的驗證者, 這個誠實的驗證者必須確認有資料去處理區塊,並且當在鏈下無法得資料時發起資料可取得的挑戰, 這種Optimistic rollup稱為[plasma](/developers/docs/scaling/plasma/)。
+
+## 合約程式碼 {#contract-code}
+
+資訊只需要寫入一次,不會被覆寫,並可從鏈上取得且要作為合約程式碼儲存, 意味著我們用資料創造了“智慧合約”,並用 [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) 讀取資訊, 優點是複製程式碼相對便宜。
+
+除了memory擴展的花費, `EXTCODECOPY`第一次讀取合約需要花2600 gas(當他還是”cold"的狀態),之後複製相同的合約需要100gas再加上每32 byte 3 gas, 相較於calldata,每byte花費 15.95,從一開始就節省了約200 bytes。 基於[擴展記憶體花費的公式](https://www.evm.codes/about#memoryexpansion),如果你不需要超過4MB 的記憶體,記憶體擴展的花費會少於用增加calldata的方式。
+
+當然,這只是 _read_資料的花費, 建立合約需花費約32,000 gas + 200 gas/byte, 這是當不同的交易要多次讀取相同資料唯一經濟的方法。
+
+合約程式碼可以是無意義的,只要不是`0xEF`開頭, 嚴格限制 `0xEF`開頭的合約代表 [ethereum object format](https://notes.ethereum.org/@ipsilon/evm-object-format-overview)。
+
+## Events {#events}
+
+[Events](https://docs.alchemy.com/docs/solidity-events)是被合約觸發的,可以被鏈下軟體讀取,
+好處是鏈下的程式碼可以監聽事件, 花費是用 [gas](https://www.evm.codes/#a0?fork=cancun) 計,375 加上每byte 8 gas。 當 12 gwei/gas、 ETH價格為2300美元時,每kilobyte 約1美分+22美分
+
+## Storage {#storage}
+
+智慧合約有進入 [persistent storage](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory)的權利, 但是很貴, 寫入一個32byte原本空著的storage slot 會 [花費 22,100 gas](https://www.evm.codes/#55?fork=cancun), 當 12 gwei/gas、 ETH價格為2300美金時,每個操作大約是61美分或每kilobyte$19.5美元。
+
+這是以太坊最貴的儲存方式。
+
+## 總結 {#summary}
+
+下表列出了各種方式的優點和缺點:
+
+| 儲存方式 | 資料來源 | 可取得性保證 | 鏈上可取得性 | 其他限制 |
+| -------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------ | ----------------- | ---------------------- |
+| EIP-4844 blobs | 鏈下 | 以太坊保證[~約18 天](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | 只可取得Hash | |
+| Calldata | 鏈下 | 以太坊永久保證(部分區塊鏈) | 只有在當寫入合約當下的交易中可取得 | |
+| 鏈下與L1的機制 | 鏈下 | 在挑戰期內"One honest verifier" 保證 | 只有Hash | 只有在挑戰期間,由挑戰機制保護 |
+| 合約程式碼 | 鏈上或鏈下 | 以太坊永久保證(部分區塊鏈) | 是 | 寫入“隨機”的地址,但不能是`0xEF`開頭 |
+| 活動 | 鏈上 | 以太坊永久保證(部分區塊鏈) | 否 | |
+| 儲存 | 鏈上 | 以太坊永久保證 (部分區塊鏈和目前的狀態直到被覆寫) | 是 | |
diff --git a/public/content/translations/zh-tw/developers/docs/data-availability/index.md b/public/content/translations/zh-tw/developers/docs/data-availability/index.md
new file mode 100644
index 00000000000..eb7989903be
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/data-availability/index.md
@@ -0,0 +1,84 @@
+---
+title: 資料可用性
+description: 以太坊中的資料可得性問題與解決方案概覽
+lang: zh-tw
+---
+
+「不輕易相信,而是去驗證。」是以太坊盛行的座右銘, 意為你的節點可以通過執行從同行那裡接收的區塊中的所有交易,獨立驗證接收到的信息是否正確,以確保所提出的變更與節點獨立計算的變更完全相符, 這意味著節點不需要信任區塊的發送者是否為可信的, 如有任何資料缺失則這無法實現。
+
+**資料可得性**是指使用者對於驗證區塊所需的資料確實可供所有網路參與者使用的信心。 對於以太坊 layer 1 上的完整節點來說,這相對簡單;完整節點會下載每個區塊中所有資料的副本——資料_必須_是可得的,下載才可能進行。 有缺失資料的區塊將被捨棄,不會被添加到區塊鏈上。 這就是「資料可得性」,其為單體式區塊鏈(相較於模組化區塊鏈)的功能之一。 完整節點不會被騙接受無效的交易,因為它們會下載並執行每個交易。 然而,對於模組化的區塊鏈、L2 rollups 和light clients,資料可用性的情境更為複雜,需要一些更為精密的驗證程序。
+
+## 先決條件 {#prerequisites}
+
+您應該充分了解[區塊鏈基礎知識](/developers/docs/intro-to-ethereum/),特別是[共識機制](/developers/docs/consensus-mechanisms/)。 本頁面也假設讀者熟悉[區塊](/developers/docs/blocks/)、[交易](/developers/docs/transactions/)、[節點](/developers/docs/nodes-and-clients/)、[擴展解決方案](/developers/docs/scaling/)及其他相關主題。
+
+## 資料可得性問題 {#the-data-availability-problem}
+
+資料可得性問題是,需要向整個網路證明正在添加到區塊鏈的某些交易資料的總結形式確實代表一組有效的交易,但不要求所有的節點都下載所有的資料。 為了獨立地驗證區塊,所有交易的資料是必要的,但要求所有節點都要下載全部的交易資料是個擴容的瓶頸。 因此,資料可得性問題的解決方案是希望向不下載、不儲存資料的網路參與者,提供足夠的保證來代表所有交易的資料是可得、可供取用於驗證的。
+
+[輕量節點](/developers/docs/nodes-and-clients/light-clients)和 [Layer 2 卷軸](/developers/docs/scaling) 是網路參與者的重要範例,他們需要強大的資料可得性保證,但無法自行下載和處理交易資料。 畢竟,不下載交易資料才能稱作「輕」節點,而卷(rollups)才能有效的擴容。
+
+資料可得性對於未來的 ["stateless"](/roadmap/statelessness) 以太坊用戶端來說也是一個關鍵問題,這些用戶端不需要下載和儲存狀態資料來驗證區塊。 無狀態用戶端仍需要確定資料在_某處_是可得的,並且已被正確處理。
+
+## 資料可得性解決方案 {#data-availability-solutions}
+
+### 資料可得性抽樣 (DAS) {#data-availability-sampling}
+
+資料可得性採樣(DAS)是指讓網路能檢查資料是可取得的,但同時不在任何的獨立節點上加諸太多要求。 每個節點(包含沒有質押的節點)下載所有交易資料的隨機一小部分, 若能成功地下載到採樣,我們就能高度相信所有資料都是可得的。 這依賴於資料刪除編碼,它透過冗餘資訊來擴展給定的資料集 (做法是將一個稱為_多項式_的函數擬合到資料上,並在額外的點上評估該多項式)。 這讓原本的資料在必要時,可以透過冗余的資料來還原。 這種資料創建方式的後果是,如果_任何_原始資料不可用,那麼擴展資料的_一半_將會遺失! 每個節點下載的資料樣本數量可以調整,以便在只有不到一半的資料真正可用的情況下,每個用戶端抽樣的資料片段中,_極有可能_至少有一個會遺失。
+
+在 [Full Danksharding](/roadmap/danksharding/#what-is-danksharding) 實施後,DAS 將用於確保卷軸營運商使其交易資料可供使用。 以太坊節點會隨機地向 blob 中的資料採樣,用前述提到的糾刪碼來確保所有資料真的都存在。 同樣的技術也可以用來確保區塊製造者會讓所有的資料都是可得的,來保障輕節點的安全性。 同樣地,在[提議者-建構者分離](/roadmap/pbs)機制下,只有區塊建構者需要處理整個區塊——其他驗證者將使用資料可得性抽樣進行驗證。
+
+### 資料可得性委員會 {#data-availability-committees}
+
+資料可得性委員會(DAC)是提供或證明數據可用性的可信方。 資料可得性委員會 (DAC) 可以取代 DAS,或是[與其結合使用](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS)。 資料可用性委員會的安全保障取決於具體的設定。 例如,以太坊使用隨機抽樣一些驗證程式來證明節點的數據可用性。
+
+validiums也在使用DACs。 DAC 是一組可信任的節點,離線儲存資料的副本。 DAC在發生爭議時需提供數據。 DAC 的成員也得發布鏈上證明來證實特定數據確實可用。 有些 validiums 以權益證明驗證者系統(PoS)來代替 DAC。 任何人都可成為驗證者並在鏈下儲存資訊。 然而,他們必須提供「保證金」並存款到智能合約中。 發生惡意行為時,如驗證者提供了欺騙性的資料,該保證金可能會受到罰沒。 權益證明資料可用性委員會在安全性方面明顯優於一般資料可用性委員,因為它們直接激勵誠實的行為。
+
+## 資料可得性與輕量節點 {#data-availability-and-light-nodes}
+
+[輕量節點](/developers/docs/nodes-and-clients/light-clients)需要在不下載區塊資料的情況下,驗證他們收到的區塊標頭的正確性。 輕節點輕量化的代價就是無法像全節點一樣在本地獨立地重新執行交易以驗證區塊頭。
+
+以太坊輕量節點信任已被指派至一個_同步委員會_的 512 個隨機驗證者集合。 同步委員會充當數據可用性委員會,使用加密簽名向輕節點表明區塊頭中的數據是正確的。 同步委員會每天都會刷新。 每個區塊標頭都會提醒輕量節點,預期由哪些驗證者簽署_下一個_區塊,這樣他們就不會被冒充成真正同步委員會的惡意團體所欺騙。
+
+然而,如果攻擊者以某種方式_真的_成功將惡意區塊標頭傳遞給輕量用戶端,並說服他們該標頭是由誠實的同步委員會簽署的,會發生什麼事呢? 在這種情況下,攻擊者可能會添加無效的交易,而輕節點將盲目地接受它們,因為輕節點無法獨立驗證匯總在區塊頭中的所有狀態變化。 為了防止這種情況,輕節點可以使用詐欺證明。
+
+詐欺證明的工作原理如下:全節點發現一個無效狀態轉換在網路上廣播時,可以快速產生證明已提議狀態轉換不可能源自給定一組交易的一小段數據,並把這段數據廣播到對等節點。 輕節點可以選取這些詐欺證明並用來丟棄有害的區塊頭,確保它們和全節點留在相同的誠實區塊鏈上。
+
+這仰仗於全節點能夠存取完整的交易資料。 廣播有害區塊頭並且不提供交易資料的攻擊者可能能夠阻止全節點產生詐欺證明。 全節點也許可以發出關於有害區塊的警告,但沒有證據來證明它們的警告,因為沒有可用於產生證明據的數據!
+
+數據可用性採樣可以解決這個數據可用性問題。 輕節點下載完整狀態資料的小隨機片段,並使用這些樣本驗證完整資料集可用。 下載 N 個隨機資料塊後,錯誤地假設資料完全可用的實際可能性是可以計算的 ([對於 100 個資料塊,機率是 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html),即機率極低)。
+
+即使在這種情況下,僅保留幾個位元組的攻擊也可能被發出隨機資料請求的客戶端忽略。 刪除編碼透過重建缺失的小型資料片段來解決這個問題,這些片段可以用於檢查提交的狀態變更。 接著可以使用重建的資料建立欺詐證明,防止輕節點接受惡意的標頭。
+
+**注意:** 資料可得性抽樣 (DAS) 和詐欺證明尚未為權益證明以太坊輕量用戶端實施,但它們已在發展藍圖上,最有可能採取基於 ZK-SNARK 的證明形式。 現有的輕量節點依賴 DAC 的形式:他們驗證同步委員會的身份,並信任接收到的經簽署區塊標頭。
+
+## 資料可得性與 Layer 2 卷軸 {#data-availability-and-layer-2-rollups}
+
+[Layer 2 擴展解決方案](/layer-2/),例如[卷軸](/glossary/#rollups),透過在鏈下處理交易來降低交易成本並提高以太坊的吞吐量。 卷軸交易是一批次一批次壓縮並上傳到以太坊上的。 批次為以太坊上一筆單獨的交易,其包含了數千筆獨立的鏈下交易。 這緩解了基礎層的擁塞情況,並降低了使用者所需支付的費用。
+
+然而,只有當提交的狀態變化可被獨立驗證,並確認它確實是所有個別鏈下交易產出的結果時,我們才能信任這個上傳到以太坊的「總結」交易。 如果卷軸的營運者沒有在此驗證中提供交易資料,它們可能會發送錯誤的資料給以太坊。
+
+[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)會將壓縮後的交易資料發布到以太坊,並等待一段時間 (通常為 7 天),以允許獨立的驗證者檢查資料。 如果任何人發現有問題,他們可以產生欺詐證明並用來挑戰卷軸。 這會導致區塊鏈回滾並忽略不合法的區塊。 只有在數據可用時,才能實現這一點。 目前,樂觀卷疊有兩種方式將交易資料發佈到一層網路。 有些卷軸會將資料以 `CALLDATA` 的形式永久提供,這些資料會永久儲存在鏈上。 隨著 EIP-4844 的實現,一些卷軸將其交易資料發佈到更便宜的二進位大型物件存儲中。 這不是永久的儲存。 獨立驗證者必須在資料從以太坊一層網路刪除前約 18 天内查詢二進位大型文件並提出挑戰。 資料有效性只在一個短暫的固定窗口期内由以太坊協議得到保證。 在此之後,資料可用性成爲以太坊生態系統中其他實體的責任。 任何節點都可以使用 DAS 來驗證資料可得性,即透過下載 blob 資料的少量隨機樣本。
+
+[零知識 (ZK) 卷軸](/developers/docs/scaling/zk-rollups) 不需要發布交易資料,因為[零知識有效性證明](/glossary/#zk-proof)保證了狀態轉換的正確性。 然而,資料可用性仍然是個問題,因為我們只有在存取狀態資料的情況下,才能確保零知識卷軸正常運作(或與其互動)。 例如,如果操作者扣留了卷軸的狀態,使用者就無法得知其餘額。 另外,使用者也無法使用新添加區塊中的資訊來執行狀態更新。
+
+## 資料可得性與資料可擷取性 {#data-availability-vs-data-retrievability}
+
+資料可用性與資料可檢索性不同。 資料可用性是一種保證,它確保全節點能夠訪問並驗證與特定區塊關聯的完整交易集。 這並不一定意味著數據能永遠被取出。
+
+資料可擷取性是指節點從區塊鏈中擷取_歷史資訊_的能力。 驗證新區塊不需要歷史資料,歷史資料只用於從創世區塊同步全節點或滿足某些特定的歷史請求。
+
+核心以太坊協議主要關注數據可用性,而不是數據可檢索性。 資料可擷取性可由第三方運行的少量封存節點提供,或者可以使用去中心化檔案儲存 (例如 [Portal Network](https://www.ethportal.net/)) 分散到整個網路上。
+
+## 延伸閱讀 {#further-reading}
+
+- [什麼是資料可得性 (Data Availability)?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f)
+- [什麼是資料可得性?](https://coinmarketcap.com/academy/article/what-is-data-availability)
+- [資料可得性檢查入門](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)
+- [分片 + DAS 提案的解釋](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling)
+- [關於資料可得性與刪除編碼的說明](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them)
+- [資料可得性委員會](https://medium.com/starkware/data-availability-e5564c416424)
+- [權益證明的資料可得性委員會](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)
+- [資料可擷取性問題的解決方案](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding)
+- [資料可得性,或:卷軸如何學會停止擔憂並愛上以太坊](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum)
+- [EIP-7623:增加 Calldata 成本](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/index.md
index 505b1639240..ab3a87e0fce 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/index.md
@@ -5,28 +5,28 @@ lang: zh-tw
sidebarDepth: 2
---
-以太坊會建立、儲存和傳送大量資料。 該資料必須使用標準化格式和節省記憶體的方式,以便任何人都能夠在相對一般的消費級硬體上[運行節點](/run-a-node/)。 爲了實現這一點,以太坊堆棧中使用了一些特定的資料結構。
+以太坊會建立、儲存和傳送大量資料。 此資料必須以標準化且高記憶體效率的方式格式化,讓任何人都可以在相對平價的消費級硬體上[執行節點](/run-a-node/)。 爲了實現這一點,以太坊堆棧中使用了一些特定的資料結構。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-你應該對以太坊和[用戶端軟體](/developers/docs/nodes-and-clients/)的基本原理已經有所了解。 熟悉網路層和[以太坊白皮書](/whitepaper/)會更加好。
+您應該了解以太坊的基礎知識以及[用戶端軟體](/developers/docs/nodes-and-clients/)。 建議您熟悉網路層和[以太坊白皮書](/whitepaper/)。
-## 資料結構 {#data-structures}
+## 數據結構 {#data-structures}
-### 帕特里夏默克爾樹 {#patricia-merkle-tries}
+### 派翠西亞·梅克爾前綴樹 {#patricia-merkle-tries}
帕特里夏默克爾樹是一種資料結構,將鍵值對編碼為具有確定性且經過加密驗證的樹。 這些資料結構被廣泛用於以太坊執行層。
-[有關帕特里夏默克爾樹的更多資訊](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
+[更多關於派翠西亞·梅克爾前綴樹的資訊](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
-### 遞迴長度前置詞 {#recursive-length-prefix}
+### 遞迴長度前綴 {#recursive-length-prefix}
遞迴長度前置詞 (RLP) 是一種在以太坊執行層中廣泛使用的序列化方法。
-[有關遞迴長度前置詞的更多資訊](/developers/docs/data-structures-and-encoding/rlp)
+[更多關於 RLP 的資訊](/developers/docs/data-structures-and-encoding/rlp)
-### 簡易序列化 {#simple-serialize}
+### 簡單序列化 {#simple-serialize}
簡單序列化 (SSZ) 因爲與默克爾化功能相容,是以太坊共識層主要序列化格式。
-[有關簡易序列化的更多資訊](/developers/docs/data-structures-and-encoding/ssz)
+[更多關於 SSZ 的資訊](/developers/docs/data-structures-and-encoding/ssz)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
index 315c0fbb414..7be66c11f20 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
@@ -5,19 +5,19 @@ lang: zh-tw
sidebarDepth: 2
---
-以太坊的狀態(所有帳戶、餘額和智慧型合約的總體)被編碼成一種特殊版本的資料結構,這種結構在計算機科學界通常被稱作默克爾樹。 這種結構在密碼學中的許多應用中都非常有用,因為它會在默克爾樹中所有互相有關的資料片段之間建立了一種可驗證的關係,產生可用於驗證相關資料的單一**根**值。
+以太坊的狀態(所有帳戶、餘額和智慧型合約的總體)被編碼成一種特殊版本的資料結構,這種結構在計算機科學界通常被稱作默克爾樹。 這種結構在密碼學中的許多應用程式中非常有用,因為它會在樹中所有互相纏繞的資料片段之間建立一種可驗證的關係,產生可用於驗證相關資料的單一 **根** 值。
-以太坊的資料結構是「改良版的默克爾帕特里夏樹」,之所以會這樣命名,是因為它借鑒了一些 PATRICIA(字母數字編碼的資訊擷取實用演算法)的部分特徵,同時它是為了對構成以太坊狀態的項目進行有效率的資料**擷取**而設計的。
+以太坊的資料結構是「改良版默克爾-派翠西亞樹」,之所以如此命名,是因為它借鑒了 PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric) 的一些功能,並且其設計是為了能有效率地對構成以太坊狀態的項目進行資料**擷取**。
-默克爾帕特里夏樹是確定性的,並且可以透過加密方式驗證:生成狀態根的唯一方式是從每個單獨的狀態進行計算,且兩個相同的狀態可以透過比較根雜湊和其父雜湊(_默克爾證明_)來簡單地證明相同。 相反,無法用同一個根雜湊建立兩個不同的狀態,任何用不同值修改狀態的嘗試都會導致不同的狀態根雜湊。 從理論上講,這種結構為置入、查找和刪除提供了完美的 `O(log(n))` 效率。
+默克爾-派翠西亞樹是確定性且可加密驗證的:產生狀態根的唯一方法是透過狀態的每個獨立部分來計算,而兩個相同的狀態可以透過比較根雜湊以及導出根雜湊的那些雜湊 (_默克爾證明_) 來輕易地證明其相同性。 相反,無法用同一個根雜湊建立兩個不同的狀態,任何用不同值修改狀態的嘗試都會導致不同的狀態根雜湊。 理論上,此結構為插入、查詢和刪除提供了 `O(log(n))` 效率的「終極目標」。
在不久的將來,以太坊計劃遷移到[沃克爾樹](/roadmap/verkle-trees)結構,這將為未來的協定改進帶來更多新的可能性。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更容易理解本文,具備以下基礎知識會很有幫助:[雜湊](https://en.wikipedia.org/wiki/Hash_function)、[默克爾樹](https://en.wikipedia.org/wiki/Merkle_tree)、[字典树](https://en.wikipedia.org/wiki/Trie)和[序列化](https://en.wikipedia.org/wiki/Serialization)。 本文從基本的[基數樹](https://en.wikipedia.org/wiki/Radix_tree)描述開始,然後逐步介紹使以太坊資料結構更爲優化的必要修改。
+為了能更佳理解此頁面,最好對 [雜湊](https://en.wikipedia.org/wiki/Hash_function)、[默克爾樹](https://en.wikipedia.org/wiki/Merkle_tree)、[前綴樹](https://en.wikipedia.org/wiki/Trie) 和 [序列化](https://en.wikipedia.org/wiki/Serialization) 有基本了解。 本文從基本的 [基數樹](https://en.wikipedia.org/wiki/Radix_tree) 描述開始,然後逐步介紹讓以太坊資料結構更優化所做的必要修改。
-## 基數樹 {#basic-radix-tries}
+## 基本基數前綴樹 {#basic-radix-tries}
在基數樹中,每個節點看起來如下:
@@ -25,146 +25,149 @@ sidebarDepth: 2
[i_0, i_1 ... i_n, value]
```
-其中,`i_0 ... i_n` 代表字母表的符號(通常是二進位或十六進位),`value` 是節點的終值,`i_0, i_1 ... i_n` 插槽中的值為 `NULL` 或指向其他節點(在我們的示例中,是其他節點的雜湊)的指針。 這形成了基本的 `(key, value)` 存儲。
+其中 `i_0 ...` i_n` 代表字母表的符號 (通常是二進制或十六進制),`value`是節點的終端值,而`i_0, i_1 ...` 中的值 i_n` 位置的值要不是 `NULL`,就是指向其他節點的指標 (在我們的例子中,是其他節點的雜湊)。 這形成了基本的 `(key, value)` 儲存。
-假設你想使用基數樹資料結構永久保存一組鍵值對的順序。 爲了在字典樹中找到目前與鍵 `dog` 對應的值,你首先需要把 `dog` 轉換為字母表中的字母(提供 `64 6f 67`),然後沿著該路徑向下遍歷字典樹,直到找到該值。 也就是説,爲了找到字典樹的根節點,你首先需要在平面鍵/值資料庫中找到根雜湊。 它表示指向其他節點的一個鍵陣列。 你將使用索引 `6` 的值作爲鍵,並通過在平面鍵/值資料庫中查找該鍵來獲取下一級的節點。 然後選取索引 `4` 查找下一個值,再選取索引 `6`,依此類推,直到遍歷路徑 `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7` 后,你會找到該節點的值並返回結果。
+假設你想使用基數樹資料結構永久保存一組鍵值對的順序。 要在前綴樹中找到目前映射至鍵 `dog` 的值,您要先將 `dog` 轉換成字母表中的字母 (得到 `64 6f 67`),然後沿著該路徑向下遍歷前綴樹,直到找到值為止。 也就是説,爲了找到字典樹的根節點,你首先需要在平面鍵/值資料庫中找到根雜湊。 它表示指向其他節點的一個鍵陣列。 您可以使用索引 `6` 的值作為鍵,並在平面鍵/值資料庫中查詢,以取得下一層的節點。 然後選擇索引 `4` 來查詢下一個值,接著選擇索引 `6`,依此類推,直到您遵循路徑:`root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`,您便會查詢到節點的值並回傳結果。
-從「樹」中和從底層平面鍵/值「資料庫」中進行查找有所區別。 它們都定義了鍵/值排列,但底層資料庫能夠對鍵執行傳統的一步查找。 在樹中查找一個鍵對應的值則需要在底層資料庫中查詢多次,才能得到上述的最終值。 讓我們將後者稱爲 `path`,以消除歧義。
+從「樹」中和從底層平面鍵/值「資料庫」中進行查找有所區別。 它們都定義了鍵/值排列,但底層資料庫能夠對鍵執行傳統的一步查找。 在樹中查找一個鍵對應的值則需要在底層資料庫中查詢多次,才能得到上述的最終值。 為消除歧義,我們將後者稱為 `path` (路徑)。
基數樹的更新和刪除操作可被定義如下:
-```
- def update(node,path,value):
- curnode = db.get(node) if node else [ NULL ] * 17
+```python
+ def update(node_hash, path, value):
+ curnode = db.get(node_hash) if node_hash else [NULL] * 17
newnode = curnode.copy()
- if path == '':
+ if path == "":
newnode[-1] = value
else:
- newindex = update(curnode[path[0]],path[1:],value)
+ newindex = update(curnode[path[0]], path[1:], value)
newnode[path[0]] = newindex
- db.put(hash(newnode),newnode)
+ db.put(hash(newnode), newnode)
return hash(newnode)
- def delete(node,path):
- if node is NULL:
+ def delete(node_hash, path):
+ if node_hash is NULL:
return NULL
else:
- curnode = db.get(node)
+ curnode = db.get(node_hash)
newnode = curnode.copy()
- if path == '':
+ if path == "":
newnode[-1] = NULL
else:
- newindex = delete(curnode[path[0]],path[1:])
+ newindex = delete(curnode[path[0]], path[1:])
newnode[path[0]] = newindex
if all(x is NULL for x in newnode):
return NULL
else:
- db.put(hash(newnode),newnode)
+ db.put(hash(newnode), newnode)
return hash(newnode)
```
-「默克爾」基數樹是透過使用確定性產生的加密雜湊摘要連結節點來構建的。 這種(鍵/值資料庫中 `key == keccak256(rlp(value))`)内容尋址提供了儲存資料的加密完整性保證。 如果給定字典樹的根雜湊是公開的,則任何能夠訪問底層葉資料的人都可以透過提供將特定值與樹根連結的每個節點的雜湊,來證明該字典樹在特定路徑中包含給定值。
+「默克爾」基數樹是透過使用確定性產生的加密雜湊摘要連結節點來構建的。 這種內容定址 (在鍵/值資料庫中 `key == keccak256(rlp(value))`) 為儲存的資料提供了加密完整性保證。 如果給定字典樹的根雜湊是公開的,則任何能夠訪問底層葉資料的人都可以透過提供將特定值與樹根連結的每個節點的雜湊,來證明該字典樹在特定路徑中包含給定值。
-對於攻擊者來講,他們無法證明 `(path, value)` 對不存在,因爲根雜湊最終基於其下方的所有雜湊。 任何底層修改都會改變根雜湊。 你可以將雜湊想做是資料結構資訊的一種壓縮表示,並透過雜湊函式的預映射保護保證安全。
+攻擊者不可能提供不存在的 `(path, value)` 配對證明,因為根雜湊最終是基於其下的所有雜湊。 任何底層修改都會改變根雜湊。 你可以將雜湊想做是資料結構資訊的一種壓縮表示,並透過雜湊函式的預映射保護保證安全。
-我們將基數樹的原子單位(例如單個十六進位字元或 4 位二進位數字)稱爲「nibble」。 如上所述,以 nibble 為單位遍歷路徑時,節點最多可以指向 16 個子節點,但是還包括一個 `value` 元素。 因此,我們將它們表示爲長度 17 的陣列。 我們將這 17 個元素的陣列稱爲「分支節點」。
+我們會將基數樹的一個原子單位 (例如單一的十六進制字元,或 4 位元的二進制數) 稱為「半位元組 (nibble)」。 如上所述,在一次遍歷一個半位元組的路徑時,節點最多可以引用 16 個子節點,但包含一個 `value` 元素。 因此,我們將它們表示爲長度 17 的陣列。 我們將這 17 個元素的陣列稱爲「分支節點」。
-## 默克爾帕特里夏樹 {#merkle-patricia-trees}
+## 默克爾-派翠西亞樹 {#merkle-patricia-trees}
-基數樹有一個主要限制:效率低下。 如果你希望將一個 `(path, value)` 繫結儲存在路徑長度為 64 字符(`bytes32` 中的 nibble 數)的位置,如以太坊中,我們需要超過一千個位元組的額外空間將每個字元存儲一個等級,並且每次查詢或刪除都需要執行完整的 64 步。 下文介紹的帕特里夏樹解決了這個問題。
+基數樹有一個主要限制:效率低下。 如果您想儲存一個 `(path, value)` 綁定,其中路徑的長度 (像在以太坊一樣) 為 64 個字元 (即 `bytes32` 中的半位元組數),那麼每個字元都需要超過 1 KB 的額外空間來儲存一個層級,且每次查詢或刪除都將需要整整 64 個步驟。 下文介紹的帕特里夏樹解決了這個問題。
-### 最佳化 {#optimization}
+### 優化 {#optimization}
默克爾帕特里夏樹中的節點可以是以下其中一種:
-1. `NULL`(表示爲空字串)
-2. `branch` 一個 17 項目節點 `[ v0 ... v15, vt ]`
-3. `leaf` 一個 2 項目節點 `[ encodedPath, value ]`
-4. `extension` 一個 2 項目節點 `[ encodedPath, key ]`
+1. `NULL` (以空字串表示)
+2. `branch` 一個 17 項的節點 `[ v0 ...` `v15, vt ]`
+3. `leaf` 一個 2 項的節點 `[ encodedPath, value ]`
+4. `extension` 一個 2 項的節點 `[ encodedPath, key ]`
-在 64 字元的路徑中,遍歷樹的前幾層后,你將會達到一個至少下游部分不再有分支路徑的節點。 爲了避免在路徑中建立多達 15 個稀疏 `NULL` 節點,我們需要透過設置一個形式爲 `[ encodedPath, key ]` 的 `extension` 節點來簡化向下遍歷,其中 `encodedPath` 包含要跳過的「部分路徑」(使用下面描述的壓縮編碼),`key` 用於下一次資料庫查詢。
+在 64 字元的路徑中,遍歷樹的前幾層后,你將會達到一個至少下游部分不再有分支路徑的節點。 為避免沿路徑建立多達 15 個稀疏的 `NULL` 節點,我們透過設定 `[ encodedPath, key ]` 形式的 `extension` 節點來簡化向下搜尋,其中 `encodedPath` 包含要跳過的「部分路徑」 (使用下述的緊湊編碼),而 `key` 則用於下一次資料庫查詢。
-對於 `leaf` 節點,可以使用 `encodedPath` 的第一個 nibble 中的標記來標注,該路徑編碼了所有先前節點的路徑片段,並且我們可以直接查找 `value`。
+對於 `leaf` 節點,可以在 `encodedPath` 的第一個半位元組中以旗標標記,路徑會編碼所有先前節點的路徑片段,而我們可以直接查詢 `value`。
然而,上述優化帶來了歧義。
-當 nibble 遍歷路徑時,最後我們可能需要遍歷奇數個 nibble,但是所有資料都需要以 `bytes` 形式儲存。 兩者之間是無法區分的,例如,nibble `1` 和 nibble `01`(兩者都必須存儲爲 `<01>`)。 爲了指定奇數長度,這部分路徑需要用標記作爲前置詞。
+以半位元組為單位遍歷路徑時,我們最終可能需要遍歷奇數個半位元組,但是所有資料都是以 `bytes` 格式儲存的。 例如,我們無法區分半位元組 `1` 和半位元組 `01` (兩者都必須儲存為 `<01>`)。 爲了指定奇數長度,這部分路徑需要用標記作爲前置詞。
-### 規範:具有可選終止符的十六進位序列壓縮編碼 {#specification}
+### 規格:帶有可選終端符的十六進制序列的緊湊編碼 {#specification}
-如上所述,_剩餘部分路徑長度為奇數 vs 偶數_和_葉節點 vs 擴展節點_的標記位於任意 2 項目節點中部分路徑的第一個 nibble。 它們會產生以下結果:
+如上所述,關於_剩餘部分路徑長度為奇數還是偶數_以及是_葉節點還是擴充節點_的旗標,都位於任何 2 項節點的部分路徑的第一個半位元組中。 它們會產生以下結果:
- hex char bits | node type partial path length
- ----------------------------------------------------------
- 0 0000 | extension even
- 1 0001 | extension odd
- 2 0010 | terminating (leaf) even
- 3 0011 | terminating (leaf) odd
+| 十六進位字符 | 比特 | 部分節點類型 | 路徑長度 |
+| ------ | ---- | ------------------------- | ---- |
+| 0 | 0000 | 擴充 | 偶數 |
+| 1 | 0001 | 擴充 | 奇數 |
+| 2 | 0010 | 終端 (葉) | 偶數 |
+| 3 | 0011 | 終端 (葉) | 奇數 |
-對於剩餘路徑長度為偶數的情況(`0` 或 `2`),一定會附加一個 `0`「填充」nibble。
+對於偶數的剩餘路徑長度 (`0` 或 `2`),後面將總會跟著另一個 `0`「填充」半位元組。
-```
+```python
def compact_encode(hexarray):
term = 1 if hexarray[-1] == 16 else 0
- if term: hexarray = hexarray[:-1]
+ if term:
+ hexarray = hexarray[:-1]
oddlen = len(hexarray) % 2
flags = 2 * term + oddlen
if oddlen:
hexarray = [flags] + hexarray
else:
hexarray = [flags] + [0] + hexarray
- // hexarray now has an even length whose first nibble is the flags.
- o = ''
- for i in range(0,len(hexarray),2):
- o += chr(16 * hexarray[i] + hexarray[i+1])
+ # hexarray 現在的長度為偶數,其第一個半位元組為旗標。
+ o = ""
+ for i in range(0, len(hexarray), 2):
+ o += chr(16 * hexarray[i] + hexarray[i + 1])
return o
```
-範例:
+範例:
-```
- > [ 1, 2, 3, 4, 5, ...]
+```python
+ > [1, 2, 3, 4, 5, ...]
'11 23 45'
- > [ 0, 1, 2, 3, 4, 5, ...]
+ > [0, 1, 2, 3, 4, 5, ...]
'00 01 23 45'
- > [ 0, f, 1, c, b, 8, 10]
+ > [0, f, 1, c, b, 8, 10]
'20 0f 1c b8'
- > [ f, 1, c, b, 8, 10]
+ > [f, 1, c, b, 8, 10]
'3f 1c b8'
```
下面是獲取默克爾帕特里夏樹中節點的擴展程式碼:
-```
- def get_helper(node,path):
- if path == []: return node
- if node = '': return ''
- curnode = rlp.decode(node if len(node) < 32 else db.get(node))
+```python
+ def get_helper(node_hash, path):
+ if path == []:
+ return node_hash
+ if node_hash == "":
+ return ""
+ curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash))
if len(curnode) == 2:
(k2, v2) = curnode
k2 = compact_decode(k2)
- if k2 == path[:len(k2)]:
- return get(v2, path[len(k2):])
+ if k2 == path[: len(k2)]:
+ return get(v2, path[len(k2) :])
else:
- return ''
+ return ""
elif len(curnode) == 17:
- return get_helper(curnode[path[0]],path[1:])
+ return get_helper(curnode[path[0]], path[1:])
- def get(node,path):
+ def get(node_hash, path):
path2 = []
for i in range(len(path)):
path2.push(int(ord(path[i]) / 16))
path2.push(ord(path[i]) % 16)
path2.push(16)
- return get_helper(node,path2)
+ return get_helper(node_hash, path2)
```
-### 示例樹 {#example-trie}
+### 前綴樹範例 {#example-trie}
-假設我們想要一個包含四個路徑/值對 `('do', 'verb')`、`('dog', 'puppy')`、`('doge', 'coins')`、`('horse', 'stallion')` 的樹。
+假設我們想要一個前綴樹,其中包含四個路徑/值配對:`('do', 'verb')`、`('dog', 'puppy')`、`('doge', 'coins')`、`('horse', 'stallion')`。
-首先,我們需要將路徑和值都轉換爲 `bytes`。 如下,_paths_ 的實際位元組代表由 `<>` 表示,而 _values_ 仍然顯示爲字串,由 `"` 表示,以方便理解(值也應該為 `bytes`):
+首先,我們將路徑和值都轉換為 `bytes`。 下面,_路徑_ 的實際位元組表示法以 `<>` 表示,但為了方便理解,_值_ 仍然以字串 (`''`) 顯示 (值實際上也應是 `bytes`):
```
<64 6f> : 'verb'
@@ -183,38 +186,38 @@ sidebarDepth: 2
hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
```
-當一個節點在另一個節點内部被引用時,包含的内容是 `H(rlp.encode(node))`,其中 `H(x) = keccak256(x) if len(x) >= 32 else x` 並且 `rlp.encode` 是[遞迴長度前置詞](/developers/docs/data-structures-and-encoding/rlp)編碼函式。
+當一個節點在另一個節點中被引用時,所包含的是 `keccak256(rlp.encode(node))` (若 `len(rlp.encode(node)) >= 32`) 或 `node` (若否),其中 `rlp.encode` 是 [RLP](/developers/docs/data-structures-and-encoding/rlp) 編碼函式。
-請注意,更新樹時,_如果_新建立的節點長度 >= 32,則需要將鍵/值對 `(keccak256(x), x)` 儲存在一個持續不變的查找表中。 然而,如果節點比這短,則不需要儲存任何資料,因爲函式 f(x) = x 是可逆的。
+請注意,在更新前綴樹時,如果新建立的節點長度 >= 32,則需要將鍵/值配對 `(keccak256(x), x)` 儲存在持久性查詢表中。 然而,如果節點比這短,則不需要儲存任何資料,因爲函式 f(x) = x 是可逆的。
-## 以太坊中的樹 {#tries-in-ethereum}
+## 以太坊中的前綴樹 {#tries-in-ethereum}
以太坊執行層中的所有默克爾樹都使用默克爾帕特里夏樹。
在區塊頭,有來自其中 3 棵樹的 3 個根。
-1. stateRoot
-2. transactionsRoot
-3. receiptsRoot
+1. stateRoot
+2. transactionsRoot
+3. receiptsRoot
-### 狀態樹 {#state-trie}
+### 狀態前綴樹 {#state-trie}
-有一個全域狀態樹,每次用戶端處理一個區塊時它都會更新。 其中,`path` 始終為 `keccak256(ethereumAddress)`,並且 `value` 始終為 `rlp(ethereumAccount)`。 具體來講,一個以太坊 `account` 是包含 4 個項目的陣列:`[nonce,balance,storageRoot,codeHash]`。 此時,值得注意的是,該 `storageRoot` 是另一個帕特里夏樹的根:
+有一個全域狀態樹,每次用戶端處理一個區塊時它都會更新。 在其中,`path` 始終為:`keccak256(ethereumAddress)`,而 `value` 始終為:`rlp(ethereumAccount)`。 更具體地說,以太坊 `account` (帳戶) 是一個 4 項陣列,包含 `[nonce,balance,storageRoot,codeHash]`。 此時,值得注意的是,這個 `storageRoot` 是另一個派翠西亞樹的根:
-### 存儲樹 {#storage-trie}
+### 儲存前綴樹 {#storage-trie}
-存儲樹是保存_所有_合約資料的地方。 每個帳戶都有一棵單獨的存儲樹。 爲了用給定地址檢索位於特定存儲位置的值,需要有存儲地址、存儲中所儲存資料的整數位置,以及區塊 ID。 之後,這些資料可以作爲引數傳入 JSON-RPC 應用程式介面中定義的 `eth_getStorageAt`,例如,用於檢索地址 `0x295a70b2de5e3953354a6a8344e616ed314d7251` 的存儲插槽 0 中的資料:
+儲存前綴樹是_所有_合約資料儲存的地方。 每個帳戶都有一棵單獨的存儲樹。 爲了用給定地址檢索位於特定存儲位置的值,需要有存儲地址、存儲中所儲存資料的整數位置,以及區塊 ID。 然後,這些資料可以作為引數傳遞給 JSON-RPC API 中定義的 `eth_getStorageAt`,例如,要擷取位址 `0x295a70b2de5e3953354a6a8344e616ed314d7251` 的儲存槽 0 中的資料:
-```
+```bash
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
```
-檢索存儲中的其他元素稍微複雜一些,因爲必須首先計算存儲樹中的位置。 該位置作爲地址和存儲位置的 `keccak256` 雜湊進行計算,兩者都從左側開始,用零填充 32 位元組的長度。 例如,地址 `0x391694e7e0b0cce554cb130d723a9d27458f9298` 存儲插槽 1 中的資料位置是:
+檢索存儲中的其他元素稍微複雜一些,因爲必須首先計算存儲樹中的位置。 此位置是透過計算地址和儲存位置的 `keccak256` 雜湊所得,兩者都向左填充零,直到長度為 32 位元組。 例如,位址 `0x391694e7e0b0cce554cb130d723a9d27458f9298` 的儲存槽 1 中資料的位置是:
-```
+```python
keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"))
```
@@ -227,37 +230,37 @@ undefined
"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
```
-因此,`path` 為 `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`。 與之前一樣,該地址現在可用於從存儲樹檢索資料:
+因此,`path` 是 `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`。 與之前一樣,該地址現在可用於從存儲樹檢索資料:
-```
+```bash
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
```
-注:如果不是合約帳戶,以太坊帳戶的 `storageRoot` 預設為空。
+注意:如果不是合約帳戶,以太坊帳戶的 `storageRoot` 預設為空。
-### 交易樹 {#transaction-trie}
+### 交易前綴樹 {#transaction-trie}
-每個區塊都有一個獨立的交易樹,也用於儲存 `(key, value)` 對。 此處的路徑為:`rlp(transactionIndex)`,代表了對應一個值的鍵,該值由以下程式碼決定:
+每個區塊都有一個獨立的交易前綴樹,同樣儲存 `(key, value)` 配對。 這裡的路徑是:`rlp(transactionIndex)`,它代表對應於由以下方式決定的值的鍵:
-```
+```python
if legacyTx:
value = rlp(tx)
else:
value = TxType | encode(tx)
```
-在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中可以找到更多相關資訊。
+更多相關資訊可以在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中找到。
-### 收據樹 {#receipts-trie}
+### 收據前綴樹 {#receipts-trie}
-每個區塊都有其收據樹。 此處的 `path` 是:`rlp(transactionIndex)`。 `transactionIndex` 是其所在區塊中的索引。 收據樹從不更新。 與交易樹類似,它也有當前和以前的收據。 爲了在收據樹中查詢特定的收據,需要提供區塊中交易的索引、收據承載以及交易類型。 返回的收據可以是 `Receipt` 類型,該類型被定義爲 `TransactionType` 和 `ReceiptPayload` 的串聯,也可以是 `LegacyReceipt` 類型,該類型被定義爲 `rlp([status, cumulativeGasUsed, logsBloom, logs])`。
+每個區塊都有其收據樹。 這裡的 `path` 是:`rlp(transactionIndex)`。 `transactionIndex` 是它在所包含區塊中的索引。 收據樹從不更新。 與交易樹類似,它也有當前和以前的收據。 爲了在收據樹中查詢特定的收據,需要提供區塊中交易的索引、收據承載以及交易類型。 回傳的收據可以是 `Receipt` 類型,其定義為 `TransactionType` 和 `ReceiptPayload` 的串接;或者也可以是 `LegacyReceipt` 類型,其定義為 `rlp([status, cumulativeGasUsed, logsBloom, logs])`。
-在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中可以找到更多相關資訊。
+更多相關資訊可以在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中找到。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [修改後的默克爾帕特里夏樹 — 以太坊如何保存狀態](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
-- [以太坊中的默克爾](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/)
-- [瞭解以太坊樹](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/)
+- [改良版默克爾-派翠西亞樹 — 以太坊如何儲存狀態](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
+- [以太坊中的默克爾化](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/)
+- [了解以太坊前綴樹](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md
index 30cef3a9519..077785be7ce 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md
@@ -5,20 +5,20 @@ lang: zh-tw
sidebarDepth: 2
---
-遞迴長度前置詞 (RLP) 序列化在以太坊執行層用戶端中廣泛使用。 遞迴長度前置詞以節省空間的格式標準化資料在節點之間的傳送。 遞迴長度前置詞的目的在於,對任意嵌套的二進位資料陣列進行編碼,而遞迴長度前置詞是用於序列化以太坊執行層中物件的主要編碼方法。 遞迴長度前置詞的主要目的是對結構進行解碼;除了正整數外,遞迴長度前置詞將特定資料類型(例如字串、浮點數)的編碼委托給更高階的協定。 正整數必須以沒有前導零的大端二進位形式表示(因而使整數值零相當於空位元組陣列)。 任何使用遞迴長度前置詞的高階協定都必須將具有前導零的反序列化正整數視爲無效。
+遞迴長度前置詞 (RLP) 序列化在以太坊執行層用戶端中廣泛使用。 遞迴長度前置詞以節省空間的格式標準化資料在節點之間的傳送。 遞迴長度前置詞的目的在於,對任意嵌套的二進位資料陣列進行編碼,而遞迴長度前置詞是用於序列化以太坊執行層中物件的主要編碼方法。 RLP 的主要用途是編碼結構;除了正整數以外,RLP 會將特定資料類型 (例如字串、浮點數) 的編碼委派給更高階的協定。 正整數必須以沒有前導零的大端二進位形式表示(因而使整數值零相當於空位元組陣列)。 任何使用遞迴長度前置詞的高階協定都必須將具有前導零的反序列化正整數視爲無效。
更多資訊請參閱[以太坊黃皮書(附錄 B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19)。
要使用遞迴長度前置詞對字典進行編碼,建議的兩種規範形式為:
-- 配合按字典順序排序的鍵使用 `[[k1,v1],[k2,v2]...]`
+- 使用 `[[k1,v1],[k2,v2]...]`,並以字典順序排列鍵
- 像以太坊一樣使用更高階的帕特里夏樹編碼
## 定義 {#definition}
遞迴長度前置詞編碼函式接受一個項目。 該項目的定義如下:
-- 一個字串(即位元組陣列)是一個項目
+- 一個字串 (亦即位元組陣列) 是一個項目
- 一個項目清單是一個項目
- 一個正整數是一個項目
@@ -35,12 +35,12 @@ sidebarDepth: 2
遞迴長度前置詞編碼的定義如下:
- 對於正整數,將其轉換爲最短位元組陣列,其大端解釋為整數,然後根據下面的規則編碼為字串。
-- 對於值在 `[0x00, 0x7f]`(十進位 `[0, 127]`)範圍内的單一位元組,該位元組就是它自己的遞迴長度前置詞編碼。
-- 否則,如果字串的長度為 0-55 位元組,則遞迴長度前置詞編碼包含一個值為 **0x80**(十進位 128)的單一位元組,加上該字串后字串的長度。 因此,第一個位元組的範圍是 `[0x80, 0xb7]`(十進位 `[128, 183]`)。
-- 如果字串的長度超過 55 位元組,則遞迴長度前置詞編碼的組成為:一個值為 **0xb7**(十進位 183)的單一位元組,加上二進位形式的字串長度之長度(以位元組為單位),后跟字串的長度,然後是字串。 例如,一個 1024 位元組長的字串將被編碼為 `\xb9\x04\x00`(十進位 `185, 4, 0`),後跟該字串。 在這裏,`0xb9` (183 + 2 = 185) 為第一個位元組,然後是表示實際字串長度的 2 個位元組 `0x0400`(十進位 1024)。 因此,第一個位元組的範圍是 `[0xb8, 0xbf]`(十進位 `[184, 191]`)。
+- 對於值在 `[0x00, 0x7f]` (十進位 `[0, 127]`) 範圍內的單一位元組,該位元組即為其自身的 RLP 編碼。
+- 否則,若字串長度為 0-55 位元組,RLP 編碼由一個值為 **0x80** (十進位 128) 的單一位元組,加上字串的長度,後面再跟著字串本身所組成。 因此,第一個位元組的範圍為 `[0x80, 0xb7]` (十進位 `[128, 183]`)。
+- 若字串長度超過 55 位元組,RLP 編碼由一個值為 **0xb7** (十進位 183) 的單一位元組,加上以位元組為單位、二進位形式的字串長度之長度,後面跟著字串的長度,最後再跟著字串本身所組成。 例如,一個 1024 位元組長的字串會被編碼為 `\xb9\x04\x00` (十進位 `185, 4, 0`),後面再跟著字串。 在此,`0xb9` (183 + 2 = 185) 是第一個位元組,後面跟著代表實際字串長度的 2 個位元組 `0x0400` (十進位 1024)。 因此,第一個位元組的範圍為 `[0xb8, 0xbf]` (十進位 `[184, 191]`)。
- 如果字串長度為 2^64 位元組或者更長,則可能不會對其進行編碼。
-- 如果清單的縂承載長度(即其所有經過遞迴長度前置詞編碼的項目的組合長度)為 0-55 位元組,則遞迴長度前置詞編碼包含一個值為 **0xc0** 的單一位元組,加上承載長度,後跟項目遞迴長度前置詞編碼的串聯。 因此,第一個字節位元組的範圍是 `[0xc0, 0xf7]`(十進位 `[192, 247]`)。
-- 如果清單的縂承載長度超過 55 位元組,則遞迴長度前置詞編碼包含一個值為 **0xf7** 的單一位元組,加上二進位形式的承載長度(以位元組為單位),後跟承載的長度,後跟項目遞迴長度前置詞編碼的串聯。 因此,第一個字節位元組的範圍是 `[0xf8, 0xff]`(十進位 `[248, 255]`)。
+- 若一個清單的總承載量 (亦即其所有 RLP 編碼項目的組合長度) 為 0-55 位元組,RLP 編碼由一個值為 **0xc0** 的單一位元組,加上承載量的長度,後面再跟著串連起來的各項目 RLP 編碼所組成。 因此,第一個位元組的範圍為 `[0xc0, 0xf7]` (十進位 `[192, 247]`)。
+- 若一個清單的總承載量超過 55 位元組,RLP 編碼由一個值為 **0xf7** 的單一位元組,加上以位元組為單位、二進位形式的承載量長度,後面跟著承載量的長度,最後再跟著串連起來的各項目 RLP 編碼所組成。 因此,第一個位元組的範圍為 `[0xf8, 0xff]` (十進位 `[248, 255]`)。
對應的程式碼為:
@@ -62,7 +62,7 @@ def encode_length(L, offset):
elif L < 256**8:
BL = to_binary(L)
return chr(len(BL) + offset + 55) + BL
- raise Exception("input too long")
+ raise Exception("input too long")
def to_binary(x):
if x == 0:
@@ -80,30 +80,30 @@ def to_binary(x):
- 位元組 '\\x00' = `[ 0x00 ]`
- 位元組 '\\x0f' = `[ 0x0f ]`
- 位元組 '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]`
-- 3 的[集合理論表示](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers),`[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]`
-- 字串 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]`
+- 3 的[集合論表示法](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers),`[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]`
+- 字串 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` , 'e', 'l', 'i', 't' ]\`
-## 遞迴長度前置詞解碼 {#rlp-decoding}
+## RLP 解碼 {#rlp-decoding}
根據遞迴長度前置詞編碼的規則和過程,遞迴長度前置詞解碼的輸入被視爲一個二進位資料陣列。 遞迴長度前置詞解碼過程如下:
-1. 根據輸入資料的第一個位元組(即前置詞),解碼資料類型、實際資料長度和位移;
+1. 根據輸入資料的第一個位元組 (亦即字首) 來解碼資料類型、實際資料長度及偏移量;
-2. 根據資料的類型和位移,對資料進行相應的解碼,遵循正整數的最小編碼規則;
+2. 根據資料的類型和位移,對資料進行相應的解碼,遵循正整數的最小編碼規則;
-3. 繼續解碼輸入的剩餘部分;
+3. 繼續解碼輸入的剩餘部分;
其中,解碼資料類型和位移的規則如下:
-1. 如果第一個位元組(即前置詞)的範圍是 [0x00, 0x7f],則資料為字串,并且字串本身就是第一個位元組;
+1. 若第一個位元組 (亦即字首) 的範圍是 [0x00, 0x7f],則資料為字串,而且字串就是第一個位元組本身;
-2. 如果第一個位元組的範圍是 [0x80, 0xb7],則資料為字串,并且第一個位元組后跟長度等於第一個位元組減去 0x80 的字串;
+2. 如果第一個位元組的範圍是 [0x80, 0xb7],則資料為字串,并且第一個位元組后跟長度等於第一個位元組減去 0x80 的字串;
-3. 如果第一個位元組的範圍是 [0xb8, 0xbf],則資料為字串,第一個位元組后跟長度等於第一個位元組減去 0xb7 的字串長度,后跟該字串;
+3. 如果第一個位元組的範圍是 [0xb8, 0xbf],則資料為字串,第一個位元組后跟長度等於第一個位元組減去 0xb7 的字串長度,后跟該字串;
-4. 如果第一個位元組的範圍是 [0xc0, 0xf7],則資料為清單,第一個位元組後跟清單中所有項目的遞迴長度前置詞編碼串聯,而清單的縂承載等於第一個位元組減去 0xc0;
+4. 如果第一個位元組的範圍是 [0xc0, 0xf7],則資料為清單,第一個位元組後跟清單中所有項目的遞迴長度前置詞編碼串聯,而清單的縂承載等於第一個位元組減去 0xc0;
-5. 如果第一個位元組的範圍是 [0xf8, 0xff],則資料為清單,第一個位元組后跟長度等於第一個位元組減去 0xf7 的縂承載,而清單所有項目的遞迴長度前置詞編碼串聯則跟在清單的縂承載之後;
+5. 如果第一個位元組的範圍是 [0xf8, 0xff],則資料為清單,第一個位元組后跟長度等於第一個位元組減去 0xf7 的縂承載,而清單所有項目的遞迴長度前置詞編碼串聯則跟在清單的縂承載之後;
對應的程式碼為:
@@ -152,12 +152,12 @@ def to_integer(b):
return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256
```
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊中的遞迴長度前置詞](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919)
-- [深入瞭解以太坊:遞迴長度前置詞](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)
-- [Coglio, A. (2020)。 ACL2 中的以太坊遞迴長度前置詞。 arXiv 預印本 arXiv:2009.13769。](https://arxiv.org/abs/2009.13769)
+- [以太坊中的 RLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919)
+- [深入了解以太坊:RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)
+- Coglio, A. (2020)。 ACL2 中的以太坊遞迴長度前置詞。 arXiv 預印本 arXiv:2009.13769。](https://arxiv.org/abs/2009.13769)
## 相關主題 {#related-topics}
-- [帕特里夏默克爾樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
+- [帕特里夏·默克爾樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md
index efb6450536c..432c2394ce2 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md
@@ -5,7 +5,7 @@ lang: zh-tw
sidebarDepth: 2
---
-**簡單序列化 (SSZ)** 是信標鏈上使用的序列化方法。 它取代了遞迴長度前置詞序列化,後者在除了對等點發現協定以外的共識層到執行層上廣泛使用。 簡單序列化被設計爲具有確定性,並且也能夠有效率地進行默克爾化。 簡單序列化可以被認爲有兩個組成部分:序列化方案和默克爾化方案,其中默克爾化方案旨在有效率地處理序列化資料結構。
+**簡單序列化 (SSZ)** 是信標鏈上使用的序列化方法。 它取代了遞迴長度前置詞序列化,後者在除了對等點發現協定以外的共識層到執行層上廣泛使用。 若要深入了解 RLP 序列化,請參閱 [遞迴長度前綴 (RLP)](/developers/docs/data-structures-and-encoding/rlp/) 簡單序列化被設計爲具有確定性,並且也能夠有效率地進行默克爾化。 簡單序列化可以被認爲有兩個組成部分:序列化方案和默克爾化方案,其中默克爾化方案旨在有效率地處理序列化資料結構。
## 簡單序列化如何運作? {#how-does-ssz-work}
@@ -16,7 +16,7 @@ sidebarDepth: 2
- 無號整數
- 布林值
-對於複雜的「複合」類型,序列化會更加複雜,因爲複合類型包含多個可能具有不同類型或不同大小或兩者都有的元素。 在這些物件都具有固定長度的情況下(即無論它們的實際值如何,元素的大小將始終保持不變),序列化只是將複合類型中的每個元素轉換爲小端位元組字串。 這些位元組字串會連結在一起。 序列化物件用位元組清單表示,清單中的元素具有固定長度,它們的排序順序與其在反序列化物件中的順序相同。
+對於複雜的「複合」類型,序列化會更加複雜,因爲複合類型包含多個可能具有不同類型或不同大小或兩者都有的元素。 在這些物件都具有固定長度的情況下 (即無論其實際值為何,元素的大小將始終保持不變),序列化只是將複合類型中的每個元素依序轉換為小端序位元組字串。 這些位元組字串會連結在一起。 序列化物件用位元組清單表示,清單中的元素具有固定長度,它們的排序順序與其在反序列化物件中的順序相同。
對於具有可變長度的類型,實際資料會被序列化物件中該元素位置的「位移」值取代。 實際資料會添加到序列化物件末尾的堆中。 位移值是堆中實際資料開始的索引,充當指向相關位元組的指針。
@@ -44,14 +44,14 @@ sidebarDepth: 2
```
-`serialized` 將具有以下結構(這裏只填充到 4 個位元,實際會填充到 32 個位元,並爲了清晰起見保留 `int` 表示):
+`serialized` 將具有以下結構 (此處只填充到 4 個位元,實際會填充到 32 個位元,並為了清楚起見保留 `int` 表示):
```
[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
------------ ----------- ----------- ----------- ----------
| | | | |
- number1 number2 offset for number 3 value for
- vector vector
+ number1 number2 vector 的 number 3 vector 的
+ 偏移 值
```
@@ -59,11 +59,11 @@ sidebarDepth: 2
```
[
- 37, 0, 0, 0, # little-endian encoding of `number1`.
- 55, 0, 0, 0, # little-endian encoding of `number2`.
- 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16).
- 22, 0, 0, 0, # little-endian encoding of `number3`.
- 1, 2, 3, 4, # The actual values in `vector`.
+ 37, 0, 0, 0, # `number1` 的小端序編碼。
+ 55, 0, 0, 0, # `number2` 的小端序編碼。
+ 16, 0, 0, 0, # 指示 `vector` 值開始位置的「偏移」(小端序 16)。
+ 22, 0, 0, 0, # `number3` 的小端序編碼。
+ 1, 2, 3, 4, # `vector` 中的實際值。
]
```
@@ -71,36 +71,35 @@ sidebarDepth: 2
```
[
- 10100101000000000000000000000000 # little-endian encoding of `number1`
- 10110111000000000000000000000000 # little-endian encoding of `number2`.
- 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16).
- 10010110000000000000000000000000 # little-endian encoding of `number3`.
- 10000001100000101000001110000100 # The actual value of the `bytes` field.
+ 10100101000000000000000000000000 # `number1` 的小端序編碼
+ 10110111000000000000000000000000 # `number2` 的小端序編碼。
+ 10010000000000000000000000000000 # 指示 `vector` 值開始位置的「偏移」(小端序 16)。
+ 10010110000000000000000000000000 # `number3` 的小端序編碼。
+ 10000001100000101000001110000100 # `bytes` 欄位的實際值。
]
```
因此,可變長度類型的實際值儲存在序列化物件末尾的堆中,它們的位移則儲存在有序欄位清單中的正確位置。
-還有一些特殊情況需要特殊處理,例如 `BitList` 類型需要在序列化過程中新增長度上限,並在反序列化過程中移除該上限。 在[簡單序列化規範](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)中查看完整詳情。
+還有一些特殊情況需要特殊處理,例如 `BitList` 類型需要在序列化過程中新增長度上限,並在反序列化過程中移除該上限。 完整細節請參閱 [SSZ 規範](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)。
### 反序列化 {#deserialization}
反序列化該物件需要一個方案。 方案會定義序列化資料的精確配置,以便每個特定元素都可以從一個位元組二進位大型物件反序列化為一些有意義的物件,其中的元素具有正確的類型、值、大小和位置。 該方案告訴反序列化器哪些值是實際值,哪些是位移值。 當物件被序列化時,所有欄位名稱都會消失,但會根據方案在反序列化時被重新具現化。
-參閱 [ssz.dev](https://www.ssz.dev/overview) 上關於此主題的互動式解釋。
+關於這一點的互動式解說,請參閱 [ssz.dev](https://www.ssz.dev/overview)。
## 默克爾化 {#merkleization}
該簡單序列化物件之後可以被默克爾化 - 即轉換爲表示相同資料的默克爾樹。 首先,確定序列化物件中的 32 位元組區塊數量。 這些都是樹的「葉子」。 葉子的總數必須為 2 的冪,以便將葉子散列到一起,最終產生單個雜湊樹根。 如果情況並非如此,則會新增包含 32 位元組零的額外葉子。 如圖所示:
```
- hash tree root
+ 哈希樹根
/ \
/ \
/ \
/ \
- hash of leaves hash of leaves
- 1 and 2 3 and 4
+ 葉 1 和 2 的哈希 葉 3 和 4 的哈希
/ \ / \
/ \ / \
/ \ / \
@@ -109,11 +108,11 @@ sidebarDepth: 2
在某些情況下,樹的葉子不會像上述範例中一樣自然均匀分佈。 例如,葉子 4 可能是一個包含多個元素的容器,需要向默克爾樹增加額外的「深度」,從而建立一棵不均匀的樹。
-與其將這些樹元素稱爲葉子 X、節點 X 等,我們可以賦予它們廣義索引,從根 = 1 開始,沿著每個層級從左往右計數。 這就是之前解釋的廣義索引。 序列化清單中的每個元素都有一個等於 `2**depth + idx` 的廣義索引,其中 idx 是其在序列化物件中的零索引位置,depth 是默克爾樹的層級數,可以計算爲元素(葉子)數量以 2 為底的對數。
+與其將這些樹元素稱爲葉子 X、節點 X 等,我們可以賦予它們廣義索引,從根 = 1 開始,沿著每個層級從左往右計數。 這就是之前解釋的廣義索引。 序列化清單中的每個元素都有一個等於 `2**depth + idx` 的廣義索引,其中 `idx` 是其在序列化物件中的零索引位置,而 `depth` 是默克爾樹的層級數,可以計算為元素 (葉) 數量以 2 為底的對數。
## 廣義索引 {#generalized-indices}
-廣義索引是一個整數,表示二進位默克爾樹中的一個節點,其中每個節點都有一個廣義索引 `2 ** depth + index in row`。
+廣義索引是一個整數,代表二元默克爾樹中的一個節點,其中每個節點都有一個廣義索引 `2 ** depth + index in row`。
```
1 --depth = 0 2**0 + 0 = 1
@@ -126,12 +125,13 @@ sidebarDepth: 2
## 多重證明 {#multiproofs}
-提供表示特定元素的廣義索引清單,以使我們可以根據雜湊樹根來對其進行驗證。 該根是我們接受的現實版本。 我們提供的任何資料都可以根據現實進行驗證,即,將資料插入默克爾樹中的正確位置(由其廣義索引確定),然後觀察根是否保持不變。 [此處](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)的規範中包含了一些函式,這些函式展示了如何計算所需的最小節點集,來驗證一組特定廣義索引的内容。
+提供表示特定元素的廣義索引清單,以使我們可以根據雜湊樹根來對其進行驗證。 該根是我們接受的現實版本。 我們提供的任何資料都可以根據現實進行驗證,即,將資料插入默克爾樹中的正確位置(由其廣義索引確定),然後觀察根是否保持不變。 在[此處](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)的規範中有函式,說明如何計算驗證特定廣義索引集內容所需的最小節點集。
-例如,爲了驗證下面樹中索引 9 中的資料,我們需要索引 8、9、5、3、1 處資料的雜湊。 (8,9) 的雜湊應該等於 (4) 的雜湊,它與 5 進行雜湊計算將產生 2,與 3 進行雜湊計算將產生樹根 1。 如果為 9 提供了不正確的資料,根將會改變,我們會檢測到這個問題並無法驗證分支。
+例如,爲了驗證下面樹中索引 9 中的資料,我們需要索引 8、9、5、3、1 處資料的雜湊。
+(8,9) 的雜湊應該等於 (4) 的雜湊,它與 5 進行雜湊計算將產生 2,與 3 進行雜湊計算將產生樹根 1。 如果為 9 提供了不正確的資料,根將會改變,我們會檢測到這個問題並無法驗證分支。
```
-* = data required to generate proof
+* = 產生證明所需的資料
1*
2 3*
@@ -140,10 +140,10 @@ sidebarDepth: 2
```
-## 進一步閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [升級以太坊:簡單序列化](https://eth2book.info/altair/part2/building_blocks/ssz)
+- [升級以太坊:SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
- [升級以太坊:默克爾化](https://eth2book.info/altair/part2/building_blocks/merkleization)
-- [簡單序列化實作](https://github.com/ethereum/consensus-specs/issues/2138)
-- [簡單序列化計算器](https://simpleserialize.com/)
+- [SSZ 實作](https://github.com/ethereum/consensus-specs/issues/2138)
+- [SSZ 計算器](https://simpleserialize.com/)
- [SSZ.dev](https://www.ssz.dev/)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md
new file mode 100644
index 00000000000..0af80a1337b
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md
@@ -0,0 +1,195 @@
+---
+title: Web3 金鑰儲存的定義
+description: Web3 金鑰儲存的正式定義
+lang: zh-tw
+sidebarDepth: 2
+---
+
+要讓應用程式在以太坊上執行,可以使用 web3.js 程式庫提供的 web3 物件。 這樣,程式透過 RPC 呼叫來和區域節點溝通。 [web3](https://github.com/ethereum/web3.js/) 可與任何公開 RPC 層的以太坊節點搭配運作。
+
+`web3` 包含 `eth` 物件 - web3.eth。
+
+```js
+var fs = require("fs")
+var recognizer = require("ethereum-keyfile-recognizer")
+
+fs.readFile("keyfile.json", (err, data) => {
+ var json = JSON.parse(data)
+ var result = recognizer(json)
+})
+
+/** result
+ * [ 'web3', 3 ] web3 (v3) 金鑰檔案
+ * [ 'ethersale', undefined ] Ethersale 金鑰檔案
+ * null 無效的金鑰檔案
+ */
+```
+
+本文件記載了 **第 3 版** 的 Web3 秘密金鑰儲存定義。
+
+## 定義 {#definition}
+
+除了加密演算法不再綁定 AES-128-CBC 外(現在最低要求是 AES-128-CTR),和第一版對照,檔案的編碼和解碼方式差異不大。 大部分的意涵/演算法與版本 1 相似,但 `mac` 除外,其為衍生金鑰從左邊數來第二個 16 位元組與完整的 `ciphertext` 串接後,所得到的 SHA3 (keccak-256) 值。
+
+秘密金鑰檔案直接儲存在 `~/.web3/keystore` (類 Unix 系統) 和 `~/AppData/Web3/keystore` (Windows) 中。 檔案可以任意命名,但良好的慣例是 `.json`,其中 `` 是賦予秘密金鑰的 128 位元 UUID (一個為秘密金鑰地址保護隱私的代理)。
+
+所有這類的檔案都有一個相關的密碼。 若要衍生給定 `.json` 檔的秘密金鑰,請先衍生檔案的加密金鑰;作法是取得檔案的密碼,並將其傳遞給 `kdf` 金鑰中所描述的金鑰衍生函數。 傳遞至 KDF 函數的、依賴 KDF 的靜態與動態參數,皆描述於 `kdfparams` 金鑰中。
+
+KDF 函式的靜態和動態 KDF 依存參數是記述在 kdfparams 金鑰裡。
+
+- `kdf`:`pbkdf2`
+
+就 PBKDF2 而言,kdfparams 包含:
+
+- `prf`:必須是 `hmac-sha256` (未來可能會擴充);
+- `c`:迭代次數;
+- `salt`:傳遞給 PBKDF 的 salt;
+- `dklen`:衍生金鑰的長度。 必須 >= 32。
+
+一旦檔案的金鑰導出後,必須透過 MAC 的導出進行驗証。 MAC 應計算為衍生金鑰從左邊數來第二個 16 位元組,與 `ciphertext` 金鑰內容串接所形成的位元組陣列之 SHA3 (keccak-256) 哈希值,即:
+
+```js
+KECCAK(DK[16..31] ++ )
+```
+
+(其中 `++` 是串接運算子)
+
+此值應與 `mac` 金鑰的內容進行比較;如果不同,應要求提供替代密碼 (或取消操作)。
+
+在檔案的金鑰驗證完畢後,密文 (`ciphertext` 金鑰在檔案中) 即可使用由 `cipher` 金鑰指定的對稱加密演算法來解密,並透過 `cipherparams` 金鑰進行參數化。 如果衍生金鑰的長度和演算法的金鑰大小不一樣,則用 0 填滿,衍生金鑰最右邊的位元組應當用作演算法的金鑰。
+
+所有最低限度合規實作都必須支援 AES-128-CTR 演算法,表示如下:
+
+- `cipher:aes-128-ctr`
+
+這密碼取得下列參數,作為 cipherparams 金鑰的金鑰提供:
+
+- `iv`:加密用的 128 位元初始向量。
+
+加密金鑰是衍生金鑰最左邊的 16 個位元組,也就是 `DK[0..15]`。
+
+祕密金鑰的建立/加密基本上應該是這些步驟的反序操作。 請確保 `uuid`、`salt` 和 `iv` 確實是隨機的。
+
+除了 `version` 欄位應作為版本的「硬」識別碼之外,實作也可以使用 `minorversion` 來追蹤格式的較小、非破壞性變更。
+
+## 測試向量 {#test-vectors}
+
+詳細資料:
+
+- `地址`:`008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
+- `ICAP`:`XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
+- `UUID`:`3198bc9c-6672-5ab3-d9954942343ae5b6`
+- `密碼`:`testpassword`
+- `祕密金鑰`:`7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`
+
+### PBKDF2-SHA-256 {#PBKDF2-SHA-256}
+
+使用 `AES-128-CTR` 和 `PBKDF2-SHA-256` 的測試向量:
+
+`~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json` 的檔案內容:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "6087dab2f9fdbbfaddc31a909735c1e6"
+ },
+ "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
+ "kdf": "pbkdf2",
+ "kdfparams": {
+ "c": 262144,
+ "dklen": 32,
+ "prf": "hmac-sha256",
+ "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
+ },
+ "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**中間值**:
+
+`衍生金鑰`:`f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551`
+`MAC 主體`:`e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46`
+`MAC`:`517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2`
+`加密金鑰`:`f06d69cdc7da0faffb1008270bca38f5`
+
+### Scrypt {#scrypt}
+
+測試向量使用 AES-128-CTR 和 Scrypt:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "740770fce12ce862af21264dab25f1da"
+ },
+ "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
+ },
+ "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**中間值**:
+
+`衍生金鑰`:`7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d`
+`MAC 主體`:`edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2`
+`MAC`:`337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c`
+`加密金鑰`:`7446f59ecc301d2d79bc3302650d8a5c`
+
+## 與版本 1 的差異 {#alterations-from-v2}
+
+此版本修正了與[此處](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst)發布的版本 1 之間的幾個不一致之處。 簡述如下:
+
+- 大小寫未對齊和不一致(scrypt 為小寫字母,Kdf 為大小寫字母混合,MAC 為大寫字母)。
+- 不必要的地址和侵害隱私權。
+- `Salt` 本質上是金鑰衍生函數的一個參數,理應與其關聯,而非與籠統的加密機制關聯。
+- `_SaltLen_` 是不必要的 (直接從 Salt 衍生即可)。
+- 給定了金鑰衍生函式,但加密演算法是硬式指定的。
+- `Version` 本質上是數值,但卻是字串 (雖然字串可以做到結構化版本管理,但對於不常變更的設定檔格式而言,這可被視為超出範圍)。
+- `KDF` 和 `cipher` 在概念上是同級概念,但組織方式卻不同。
+- `MAC` 是透過一段忽略空白字元的資料計算出來的 (!)
+
+已變更格式,賦予下列檔案等同先前連結頁面所述範例的功能:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-cbc",
+ "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
+ "cipherparams": {
+ "iv": "16d67ba0ce5a339ff2f07951253e6ba8"
+ },
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
+ },
+ "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
+ "version": 1
+ },
+ "id": "0498f19a-59db-4d54-ac95-33901b4f1870",
+ "version": 2
+}
+```
+
+## 與版本 2 的差異 {#alterations-from-v2}
+
+第二版是早期的 C++ 實作,有若干缺陷。 所有基本元素保留不變。
diff --git a/public/content/translations/zh-tw/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/zh-tw/developers/docs/design-and-ux/dex-design-best-practice/index.md
new file mode 100644
index 00000000000..4a58a43a0b0
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/design-and-ux/dex-design-best-practice/index.md
@@ -0,0 +1,220 @@
+---
+title: 去中心化交易所(DEX) 設計的最佳實踐
+description: 交換代幣的 UX/UI 設計決策指南
+lang: zh-tw
+---
+
+自 2018 年 Uniswap 推出以來,已經有數百個去中心化交易所(DEX) 在不同的區塊鏈上推出。
+其中許多去中心化交易所引入新的元素或增加自己的特色,但他們依然保有整體介面的一致性。
+
+能做到這樣的原因之一,就是遵循 Jackob 法則(Jakob’s Law):
+
+> 使用者大多數時間在使用其他網站, 他們會更喜歡您的網站與其他已經很熟悉的網站以相同方式運作。
+
+多虧有像 Uniswap、Pancakeswap 和 Sushiswap 這類型的早期創新者,DeFi 使用者對去中心化交易所(DEX)的樣貌有了共同的認知。
+因此,現在有了「最佳實踐」。 我們看到越來越多不同平台的設計逐漸標準化。 你可以將去中心化交易所的演變,看成一個大型的即時測試案例。 有用的設計被保留下來,不好的設計會被淘汰, 雖然應該要保有設計彈性,但去中心化交易所的設計應遵循某些規範。
+
+這篇文章會提到
+
+- 要引入什麼
+- 如何提升易用性
+- 如何進行有彈性的設計
+
+所有範例線框圖都是基於真實案例,專為本文製作而成。
+
+Figma 工具包就放在文末,歡迎用來加速您的線框圖設計!
+
+## 拆解去中心化交易所的基本設計要素 {#basic-anatomy-of-a-dex}
+
+UI 通常包含下列三種元素:
+
+1. 主介面
+2. 按鈕
+3. 資訊選單
+
+
+
+## 變化 {#variations}
+
+這將是本文的通用主題,但這三個元素有許多不同的組織方式。 資訊頁面的變化包含:
+
+- 位在按鍵上方
+- 位在按鍵下方
+- 隱藏在折疊區內
+- 或者是在預覽模式內
+
+請注意: 雖然預覽模式不是必要的,但若主介面顯示的資訊非常少,那就必須使用預覽模式。
+
+## 主介面的架構 {#structure-of-the-main-form}
+
+您可以在這個區塊選擇要交換的代幣。 這個元件是由一個輸入欄位與一個小型按鍵排列組成。
+
+去中心化交易所會根據使用情境,通常會在這個上方或下方,顯示額外的說明文字。
+
+
+
+## 變化 {#variations2}
+
+這裏展示了兩種用戶介面變化:一種沒有任何邊框,形成一種非常開放的設計;另一種的輸入行帶有邊框,引導使用者關注該元素。
+
+
+
+該基本結構允許顯示**四種關鍵資訊**:每個角落顯示一種。 如果只有一個頂部/底部行,則只顯示兩種資訊。
+
+隨著去中心化金融 (DeFi) 的演變,許多其他資訊也被包含在這裏。
+
+## 需要包含的關鍵資訊 {#key-info-to-include}
+
+- 錢包餘額
+- 最大化按鈕
+- 等價法定貨幣
+- 價格對「接收」金額的影響
+
+在去中心化金融的早期,等價法定貨幣常常被忽略。 無論你正在構建任何類型的 Web3 項目,顯示等價法定貨幣都是至關重要的。 用戶仍然以本地貨幣進行思考。因此,爲了與真實世界的心理模型相匹配,等價法定貨幣應該包含在内。
+
+在第二個欄位 (你選擇交換的目標代幣),你還可以透過計算輸入金額與預計輸出金額之間的差異,在法定貨幣金額旁包含價格影響。 這是一個相當實用的細節。
+
+百分比按鈕(例如:25%、50%、75%)可以是個實用的功能,但會佔用更多空間、增加更多行動呼籲,並加重心理負擔。 百分比滾滑桿亦是如此。 其中一些用戶介面的決定取決於您的品牌和使用者類型。
+
+主表單下方可以顯示額外的細節。 由於這類資訊主要針對專業的使用者,因此合理的做法有:
+
+- 盡可能最小化,或;
+- 將其隱藏在折叠面板中
+
+
+
+## 需要包含的額外資訊 {#extra-info-to-include}
+
+- 代幣價格
+- 滑點
+- 最小到帳金額
+- 預期輸出
+- 價格影響
+- 燃料成本估算
+- 其他費用
+- 訂單路徑
+
+可以説,其中一些細節是可選的。
+
+訂單路徑很有趣,但對大多數使用者來説沒什麽作用。
+
+一些其他細節只是在以不同的方式表達同樣的内容。 例如,「最小到帳金額」與「滑點」就像是同個硬幣的兩個面。 如果將滑點設爲 1%,那麽您預計收到的最小金額就是預期輸出 - 1%。 一些用戶介面會顯示預期金額,最小金額和滑點… 這些細節雖然有用,但可能過於繁瑣了。
+
+大多數用戶只會使用默認的滑點。
+
+「價格影響」通常在等價法定貨幣旁「發送至」欄位中的括號内。 該細節能夠有效提升用戶體驗,但如果已經在這裏顯示,真的還有必要在下方再次顯示嗎? 然後在預覽畫面中再顯示一次?
+
+許多使用者 (尤其是進行小額交換的使用者)不會在意這些細節;他們只會簡單地輸入數字並點擊交換。
+
+
+
+具體顯示哪些細節將取決於您的受眾,以及您希望該應用程式給使用者帶來什麽樣的感覺。
+
+如果您在詳情面板中包含了滑點容差,則還應該讓其可以在此處直接編輯。 這是一個很好的「加速器」例子;簡潔的用戶體驗可以幫助經驗豐富的使用者加快使用流程,並且不會影響應用程式的一般可用性。
+
+
+
+在思考時仔細考慮整體的流程,而非螢幕上的片面資訊是個好方法,流程如下:
+在主表格輸入數字 → 掃描詳情 → 點擊進入預覽畫面(如果有的話)
+詳情面板應該常駐顯示,還是需要經使用者點擊才展開面板?
+您是否應該透過新增預覽頁面來增加緩衝? 這非常有用,使用者必須放慢速度並考慮該交易。 但是,他們會想再看到完全一樣的資訊嗎? 此時,對使用者來說最重要的是什麼?
+
+## 設計選項 {#design-options}
+
+如前面所述,設計選項主要依您的個人風格而定
+您的目標使用者為何?
+您的品牌是什麽?
+您想要能顯示所有細節的「專業」面板,或者走極簡風?
+即使您瞄準的是想要所有資訊的專業使用者,您仍應謹記 Alan Cooper 的名言:
+
+> 無論您的介面有多美、多炫,少一點會更好。
+
+### 結構 {#structure}
+
+- 代幣在左邊或是右邊
+- 2 行或 3 行
+- 詳情顯示在按鈕上方或下方
+- 展開、最小化或者不顯示詳情頁面
+
+### 元件風格 {#component-style}
+
+- 空心
+- 描邊
+- 實心
+
+從單純使用者體驗方面來看,界面風格的重要性其實比您想像中的低。 視覺上的流行風格是循環變化的,且很多偏好都是主觀的。
+
+要感受這點,最簡單的方式就是看些範例,再自己動手試試不同的配置。
+
+文中附上的 Figma 大禮包包含了空心、描邊及實心這幾種元件。
+
+看一下下方的例子,來了解將不同元素組合在一起的各種方式。
+
+
+
+
+
+
+
+
+
+
+
+
+
+## 但代幣應該放哪邊? {#but-which-side-should-the-token-go-on}
+
+結論是:這對可用性來說可能沒有太大的影響。 不過有幾點需要注意,可能會讓您更傾向某個選擇。
+
+看著潮流隨時尚變化挺有意思的。 Uniswap 一開始將代幣放在左邊,但後來將其移到右邊。 Sushiswap 也在某次設計升級中完成了此變更。 大多(並非所有)協議也跟進了這個改變。
+
+金融慣例上,傳統是將貨幣符號置於數字之前,例如 $50、€50、£50,但我們會_說_ 50 美元、50 歐元、50 英鎊。
+
+對於一般用戶,特別是從左到右、從上到下閱讀的人,在右邊的代幣可能感覺更自然。
+
+
+
+將代幣放在左側,所有數字放在右側,看起來有令人愉悅的對稱性,這是個優點,但此布局也有其缺點。
+
+接近法則指出,彼此靠近的項目會被視為相關的。 因此,我們希望將相關的項目放在彼此旁邊。 代幣的餘額與代幣本身直接相關,且在新代幣被選擇時會隨之改變。 因此,將代幣餘額放在代幣選擇按鈕旁會更加合理一些。 也可以移到代幣下方,但這就破壞了佈局的對稱性。
+
+總之,兩個選項各有優缺。有趣的是,目前的趨勢似乎偏向把代幣放在右側。
+
+## 按鍵行為 {#button-behavior}
+
+不要給授權(Approve)獨立的按鈕。 在授權時也不要讓使用者額外點擊。 使用者想做的是交換代幣,因此直接在按鈕上顯示「交換」,並在第一步觸發授權。 可以用彈窗顯示步驟,或者顯示單純的「第 1 筆交易,共 2 筆」通知。
+
+
+
+
+
+### 按鈕作為情境式說明 {#button-as-contextual-help}
+
+按鈕可以兩用,同時具有警示功能!
+
+實際上,這在 Web3 領域之外不常見,但在 Web3 這已成為標準做法。 這是個不錯的創新,因為它可以省空間,並讓使用者保持專注。
+
+如果主要的行動 - 交換代幣 - 因錯誤而不可用,該錯誤的原因可用按鈕解說明,如:
+
+- 切換網路
+- 連接錢包
+- 各種錯誤
+
+按鈕也可以 **映射到** 需要被執行的動作。 舉例來說,如果使用者在錯誤的網路上而無法交換代幣,按鈕上應該顯示「切換到以太坊」,而當使用者點擊該按鈕時,應將網路切換至以太坊。 這種設計可以顯著提升使用者的效率。
+
+
+
+
+
+## 透過此 Figma 檔案打造您自己的設計 {#build-your-own-with-this-figma-file}
+
+多虧了多個協議的付出,去中心化交易所的設計已進步許多。 我們知道使用者需要哪些資訊、該如何顯示,以及如何讓流程盡可能絲滑。
+希望這篇文章能提供各位紮實的使用者體驗原則概述。
+
+如果您想實驗看看,歡迎使用 Figma 的線框稿設計包。 該設計包已盡可能保持簡潔,不過也有足夠的彈性,可以用多種方式建構基本結構。
+
+[Figma 線框稿設計包](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit)
+
+去中心化金融會持續進化,且總會有可改進的空間。
+
+祝您好運!
diff --git a/public/content/translations/zh-tw/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/zh-tw/developers/docs/design-and-ux/heuristics-for-web3/index.md
new file mode 100644
index 00000000000..c6af37ce345
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/design-and-ux/heuristics-for-web3/index.md
@@ -0,0 +1,138 @@
+---
+title: Web3 介面設計的 7 個啓發法
+description: 改進 Web3 可用性的原則
+lang: zh-tw
+---
+
+可用性啓發法是廣泛的 “經驗法則”,你可以用其來衡量網站的可用性。
+這 7 個啓發法是爲 Web3 量身定制的,并且應該與 Jakob Nielsen 的[介面設計的 10 條通用原則](https://www.nngroup.com/articles/ten-usability-heuristics/)一起使用。
+
+## Web3 的 7 個可用性啓發法 {#seven-usability-heuristics-for-web3}
+
+1. 操作后進行反饋
+2. 安全與信任
+3. 凸顯最重要的資訊
+4. 易於理解的術語
+5. 盡可能簡短的操作
+6. 靈活且可見的網路連接
+7. 透過應用程式而非錢包進行控制
+
+## 定義和範例 {#definitions-and-examples}
+
+### 1. 操作后進行反饋 {#feedback-follows-action}
+
+**當某些事情已經或正在發生時,應該明確地展示出來。**
+
+使用者會以前面步驟的結果為基礎,做出後續步驟的決定。 因此,確保他們隨時了解系統狀態至關重要。 這在 Web3 中尤其重要,因爲交易有時只需很短的時間就提交到區塊鏈了。 如果沒有反饋來通知他們等待,使用者將不確定是否發生了任何操作。
+
+**提示:**
+
+- 透過訊息、通知或其他警報來通知使用者。
+- 明確地傳達等待時間。
+- 如果操作需要的時間超過幾秒鐘,請用一個計時器或動畫來讓使用者放心,讓他們知道有操作正在發生。
+- 如果某個過程有多個步驟,請顯示每個步驟。
+
+**例如:**
+展示交易中涉及的每個步驟,有助於使用者了解自己正處於該過程的什麽位置。 適當的圖標能讓使用者了解他們的操作狀態。
+
+
+
+### 2. 融入安全與信任 {#security-and-trust-are-backed-in}
+
+應該優先考慮安全性,並向使用者强調這一點。
+人們非常在乎他們的資料。 安全往往是用戶的首要關注點,因此應該在設計的所有層面充分考慮安全問題。 你應該始終努力贏得使用者的信任,但實現這一點的方式在不同的應用程式中可能有不同的含義。 這不應該是事後才考慮的問題,而應該有意識地設計爲貫穿始終。 在整個使用者體驗中建立信任,包括社交頻道和相關文檔,以及最終的使用者介面。 如去中心化水平,資金庫的多重簽名狀態,以及團隊是否接受監督之類的因素,都會影響使用者的信任。
+
+**提示:**
+
+- 自豪地展示你的審核
+- 進行多次審核
+- 宣傳你設計的任何安全功能
+- 强調任何可能的風險,包括底層的整合
+- 傳達策略的複雜性
+- 考慮可能會影響使用者安全感的非使用者介面問題
+
+**範例:**
+在頁脚以顯眼的尺寸包含你的審核内容。
+
+
+
+### 3 凸顯最重要的資訊 {#the-most-important-info-is-obvious}
+
+對於複雜的系統,只展示最相關的資料。 確定那些資訊是最重要的,並優先展示它們。
+太多的資訊會讓人無所適從,並且使用者通常只依托一條資訊做出決定。 在去中心化金融 (DeFi) 中,這可能會是收益應用程式中的年化收益率和借貸應用程式中的貸款價值比。
+
+**提示:**
+
+- 使用者研究將揭示最重要的指標
+- 讓關鍵資訊變大,並讓其他細節變小且不引人注目
+- 人們不會仔細閲讀,而是一掃而過;確保你的設計是可掃視的
+
+**範例:** 在掃視時,巨大的全彩色代幣很容易就被找到。 年化收益率用大號字體和强調色突出顯示。
+
+
+
+### 4. 易於理解的術語 {#clear-terminology}
+
+術語應該是易於理解且恰儅的。
+技術行話可能構成巨大的阻礙,因爲它需要構建一個全新的心理模型。 使用者無法將設計與他們已知的詞語、短語或概念聯係起來。 一切似乎都令人感到困惑且陌生,他們需要經歷一條陡峭的學習曲綫才能嘗試使用。 使用者可能是出於省錢目的而接觸到去中心化金融的,而他們找到的卻是: 挖礦、礦池、質押、排放、賄賂、金庫、置物櫃、投票托管代幣、歸屬、時期、去中心化演算法、協議自有流動性…
+嘗試使用大多數人能夠理解的簡單術語。 不要僅僅爲你的項目發明新術語。
+
+**提示:**
+
+- 使用簡單且一致的術語
+- 盡可能多地使用現有語言
+- 不要杜撰自己的術語
+- 遵循現有的慣例
+- 盡可能對使用者進行教育
+
+**例如:**
+「你的獎勵」 是一個衆所周知的中性術語,并非為該項目創造的新詞。 代幣
+
+
+
+### 5. 盡可能簡短的操作 {#actions-are-as-short-as-possible}
+
+透過歸類子操作來加速使用者的互動。
+這可以在智能合約的層面上完成,也可以在使用者介面完成。 用戶不應該從系統的一部分移動到另一部分 - 或者完全離開系統 - 來完成一個常見的操作。
+
+**提示:**
+
+- 盡可能將「批准」與其他操作相結合
+- 盡可能將簽名步驟緊密地捆綁起來
+
+**例如:** 將「增加流動性資金」與「質押」結合起來,是一個能節省使用者時間與燃料的簡單加速器示例。
+
+
+
+### 6. 可見且靈活的網路連結 {#network-connections-are-visible-and-flexible}
+
+向用戶告知他們所連結的網路,並提供清晰的切換網路的快鍵。
+這在多鏈應用程式中尤其重要。 當斷開連結或連結到不支持的網路時,應用程式的主要功能仍然應該可見。
+
+**提示:**
+
+- 在斷開連結時盡可能多地顯示應用程式内容
+- 顯示使用者正在連結的網路
+- 不要讓使用者到錢包中切換網路
+- 如果應用程式需要使用者切換網路,請從主要行動號召中提示該操作
+- 如果應用程式包含多個網絡的市場或金庫,請明確陳述使用者目前查看的是哪一組。
+
+**例如:** 向用戶展示他們所連結的網路,並允許他們在應用程式欄中進行更改。
+
+
+
+### 7. 透過應用程式而非錢包進行控制 {#control-from-the-app-not-the-wallet}
+
+用戶介面應該告訴用戶他們需要知道的所有内容,並使他們能夠控制需要控制的一切。
+在 Web3 中,有些操作需要在使用者介面内執行,有些需要在錢包内執行。 一般而言,在使用者介面開始一項操作,然後在錢包中確認它。 如果這兩條綫沒有仔細合并,使用者可能會感覺不適應。
+
+**提示:**
+
+- 透過使用者介面中的反饋來傳達系統狀態
+- 保存他們的歷史記錄
+- 提供先前交易的區塊瀏覽器連結
+- 提供切換網路的快捷鍵。
+
+\*\*範例:\*\*一個設計巧妙的容器,向使用者顯示了其錢包中的相關代幣,且主要的行動呼籲按鈕提供了切換網路的快捷鍵。
+
+
diff --git a/public/content/translations/zh-tw/developers/docs/design-and-ux/index.md b/public/content/translations/zh-tw/developers/docs/design-and-ux/index.md
new file mode 100644
index 00000000000..0efb7b066ba
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/design-and-ux/index.md
@@ -0,0 +1,86 @@
+---
+title: Web3 中的設計和用戶體驗
+description: 介紹 Web3 領域和以太坊中的用戶體驗設計和研究
+lang: zh-tw
+---
+
+你不熟悉用以太坊進行設計嗎? 如果是的話,那麼這個地方你來對了。 以太坊社區中有很多介紹 Web3 的設計和研究資源。 你將學習一些核心概念,它們可能與你熟悉的其他應用程式設計不同。
+
+需要先對 Web3 有更基本的瞭解嗎? 查看 [**學習中心**](/learn/)。
+
+## 從使用者研究開始 {#start-with-user-research}
+
+實用的介面設計勝過只是視覺上吸引人的設計, 還涉及到深入瞭解用戶需求、目標以及驅動因素。 因此,我們強烈建議所有設計師採用設計流程,例如 [**雙鑽石設計流程**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\)),以確保其工作是經過深思熟慮且有目的性的。
+
+- [Web3 需要更多使用者體驗研究員與設計師](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - 當前設計成熟度概覽
+- [web3 使用者體驗研究簡易指南](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - 如何進行研究的簡易指南
+- [如何在 Web3 中處理使用者體驗決策](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - 量化和質化研究及其差異簡介 (影片,6 分鐘)
+- [在 web3 中擔任使用者體驗研究員](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - 關於在 web3 中擔任使用者體驗研究員的個人看法
+
+## Web3 研究 {#research-in-web3}
+
+以下是一份可以幫助激發設計靈感和產品決策的精選清單:
+
+| 聚焦領域 | 名稱 |
+| :------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 加密貨幣入門 | [The Reown Pulse 2024:加密貨幣消費者情緒與使用情況](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) |
+| 加密貨幣入門 | [CRADL:加密貨幣的使用者體驗](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
+| 加密貨幣入門 | [CRADL:加密貨幣入門](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
+| 加密貨幣入門 | [比特幣使用者體驗報告](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
+| 加密貨幣入門 | [Consensys:2023 年全球 Web3 認知狀況](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
+| 加密貨幣入門 | [NEAR:加速採用之旅](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
+| 質押 | [OpenUX:Rocket Pool 節點營運商使用者體驗](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) |
+| 質押 | [質押:主要趨勢、重點和預測 - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
+| 質押 | [多應用程式質押](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) |
+| DAO | [2022 年 DAO 研究更新:DAO 建立者需要什麼?](https://blog.aragon.org/2022-dao-research-update/) |
+| DeFi | [保險資金池](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
+| DeFi | [Consensys:2022 年 DeFi 使用者研究報告](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
+| 元宇宙 | [元宇宙:使用者研究報告](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
+| 元宇宙 | [實地探查:在元宇宙中研究使用者](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (影片,27 分鐘) |
+
+## 為 Web3 設計 {#design-for-web3}
+
+- [Web3 使用者體驗設計手冊](https://web3ux.design/) - 設計 Web3 應用程式的實用指南
+- [Web3 設計原則](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - 基於區塊鏈的去中心化應用程式的使用者體驗規則框架
+- [區塊鏈設計原則](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - IBM 區塊鏈設計團隊學到的經驗教訓
+- [Neueux.com](https://neueux.com/apps) - 具有多種篩選選項的使用者流程 UI 庫
+- [Web3 的可用性危機:您需要知道的事!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - 關於以開發者為中心的專案建設陷阱的小組討論 (影片,34 分鐘)
+
+## 入門 {#getting-started}
+
+- [Web3 啟發式原則](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 項 Web3 介面設計的啟發式原則
+- [DEX 設計最佳實踐](/developers/docs/design-and-ux/dex-design-best-practice/) - 去中心化交易所設計指南
+
+## Web3 設計案例研究 {#design-case-studies}
+
+- [Deep Work Studio](https://www.deepwork.studio/case-studies)
+- [在 OpenSea 上販售 NFT](https://builtformars.com/case-studies/opensea)
+- [錢包使用者體驗剖析:錢包需要如何改變](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (影片,20 分鐘)
+
+## 設計懸賞 {#bounties}
+
+- [Dework](https://app.dework.xyz/bounties)
+- [Buildbox 駭客松](https://app.buidlbox.io/)
+- [ETHGlobal 駭客松](https://ethglobal.com/)
+
+## 設計 DAO 和社群 {#design-daos-and-communities}
+
+一起投入專業的自治組織或加入設計團體,與成員們聊聊設計、研究相關主題與趨勢。
+
+- [Vectordao.com](https://vectordao.com/)
+- [Deepwork.studio](https://www.deepwork.studio/)
+- [We3.co](https://we3.co/)
+- [Openux.xyz](https://openux.xyz/)
+
+## 設計系統和其他設計資源 {#design-systems-and-resources}
+
+- [Optimism 設計](https://www.figma.com/@optimism) (Figma)
+- [Ethereum.org 設計系統](https://www.figma.com/@ethdotorg) (Figma)
+- [Finity,Polygon 的設計系統](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma)
+- [Kleros 設計系統](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
+- [Safe 設計系統](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
+- [ENS 設計系統](https://thorin.ens.domains/)
+- [Mirror 設計系統](https://degen-xyz.vercel.app/)
+
+**本頁所列的文章和專案並非官方背書**,僅供參考。
+我們根據 [刊登政策](/contributing/design/adding-design-resources) 中的標準在本頁面新增連結。 如果您希望我們新增專案/文章,請在 [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) 上編輯此頁面。
diff --git a/public/content/translations/zh-tw/developers/docs/development-networks/index.md b/public/content/translations/zh-tw/developers/docs/development-networks/index.md
index ef2f6d3af87..6e0d97ae053 100644
--- a/public/content/translations/zh-tw/developers/docs/development-networks/index.md
+++ b/public/content/translations/zh-tw/developers/docs/development-networks/index.md
@@ -8,25 +8,25 @@ lang: zh-tw
與在電腦上執行本地伺服器進行 Web 開發的方式類似,你可以使用開發網路建立本機區塊鏈執行個體來測試你的去中心化應用程式。 這些以太坊開發網路提供的功能比公共測試網的迭代速度快得多(例如,你不需要從測試網水龍頭取得以太幣)。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在深入瞭解開發網路之前,應該先瞭解[以太坊堆疊的基礎知識](/developers/docs/ethereum-stack/)和[以太坊網路](/developers/docs/networks/)。
+在深入研究開發網路前,您應先了解 [以太坊技術堆疊](/developers/docs/ethereum-stack/) 和 [以太坊網路](/developers/docs/networks/) 的基礎知識。
## 什麼是開發網路? {#what-is-a-development-network}
開發網路本質上是專為本地開發而設計的以太坊用戶端(以太坊的實作)。
-**為什麼不在本地運行一個標準的以太坊節點呢?**
+**為什麼不直接在本機執行標準的以太坊節點?**
-你_可以_[運行節點](/developers/docs/nodes-and-clients/#running-your-own-node),但由於開發網路是專門為開發而建立,它們往往會具有一些快速方便的功能,例如:
+您_可以_ [執行一個節點](/developers/docs/nodes-and-clients/#running-your-own-node),但因為開發網路是專為開發而打造的,所以通常會內建許多便利功能,例如:
-- 確定性地用資料植入你的本地區塊鏈(例如具有以太幣餘額的帳戶)
+- 以確定性方式將資料 (例如:具有 ETH 餘額的帳戶) 植入您的本機區塊鏈
- 用接收的每筆交易,依照順序及零延遲即時產生區塊
- 增強的偵錯和日誌記錄功能
## 可用工具 {#available-projects}
-**注意**:大多數[開發架構](/developers/docs/frameworks/)包含一個內建開發網路。 推薦你從一個架構開始[設定你的本地開發環境](/developers/local-environment/)。
+**注意**:大多數 [開發框架](/developers/docs/frameworks/) 都包含內建的開發網路。 我們建議從一個框架開始 [設定您的本機開發環境](/developers/local-environment/)。
### Hardhat 網路 {#hardhat-network}
@@ -35,25 +35,20 @@ lang: zh-tw
Hardhat 網路內建了 Hardhat,這是一個專業以太坊開發環境。
- [網站](https://hardhat.org/)
-- [Github](https://github.com/nomiclabs/hardhat)
+- [GitHub](https://github.com/NomicFoundation/hardhat)
-### 本地信標鏈 {#local-beacon-chains}
+### 本機信標鏈 {#local-beacon-chains}
一些共識用戶端具有內建工具,用於啟動本地信標鏈以進行測試。 Lighthouse、Nimbus 和 Lodestar 的說明如下:
-- [使用 Lodestar 的本地測試網](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/)
-- [使用 Lighthouse 的本地測試網](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
+- [使用 Lodestar 的本機測試網](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/)
+- [使用 Lighthouse 的本機測試網](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
-### 公共以太坊測試鏈 {#public-beacon-testchains}
+### 公開以太坊測試鏈 {#public-beacon-testchains}
-以太坊目前有兩個維護中的公共測試網:Sepolia 和 Hoodi。 推薦開發者使用 Sepolia 作為主要測試網,因為它是一個輕量級的測試鏈,預計在可預見的未來會繼續維護。Sepolia 上有獲得許可的驗證者集,這意味著普通用戶無法在此測試網上部署新的驗證者。Hoodi 是一個較新的測試網,允許任何人自由成為驗證者,適合進行質押和驗證者測試。
+以太坊還有兩個維護中的公共測試實作:Sepolia 和 Hoodi。 推薦使用受長期受支援的測試網 Hoodi,任何人都可以自由在其上驗證。 Sepolia 使用許可制的驗證者集合,這意味著在該測試網中沒有面向公衆的心驗證者訪問權限。
-- [Sepolia 水龍頭](https://faucet.sepolia.dev/)
-- [Hoodi 質押啟動面板](https://holesky.launchpad.ethereum.org/)
-
-請注意,Goerli 已被棄用,Ropsten、Rinkeby 和 Kiln 測試網已停用。
-
-- [測試網棄用公告](https://blog.ethereum.org/2022/06/21/testnet-deprecation)
+- [Hoodi 質押啟動面板](https://hoodi.launchpad.ethereum.org/)
### Kurtosis 以太坊套件 {#kurtosis}
@@ -62,15 +57,15 @@ Kurtosis 是一個用於多容器測試環境的構建系統,讓開發者能
以太坊 Kurtosis 套件可用於透過 Docker 或 Kubernetes 快速具現化一個可參數化、高擴展性的私人以太坊測試網。 此套件支援所有主要的執行層 (EL) 和共識層 (CL) 用戶端。 Kurtosis 從容處理代表網路的所有本地端口映射和服務連線,以用於與以太坊核心基礎設施相關的驗證和測試工作流程。
- [以太坊網路套件](https://github.com/kurtosis-tech/ethereum-package)
-- [官網](https://www.kurtosis.com/)
+- [網站](https://www.kurtosis.com/)
- [GitHub](https://github.com/kurtosis-tech/kurtosis)
-- [文件](https://docs.kurtosis.com/)
+- [說明文件](https://docs.kurtosis.com/)
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [開發架構](/developers/docs/frameworks/)
-- [設定本地開發環境](/developers/local-environment/)
+- [開發框架](/developers/docs/frameworks/)
+- [設定本機開發環境](/developers/local-environment/)
diff --git a/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md b/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md
index 6521b5a8681..b8fdbb2c9fd 100644
--- a/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md
+++ b/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md
@@ -8,54 +8,54 @@ lang: zh-tw
然而,以太坊的核心元件有助於為軟體應用程式如何與以太坊區塊鏈互動提供思維模型。 理解堆疊的各層將幫助瞭解將以太坊整合到軟體專案中的不同方式。
-## 等級 1:以太坊虛擬機器 {#ethereum-virtual-machine}
+## 第 1 層:以太坊虛擬機 {#ethereum-virtual-machine}
-[以太坊虛擬機器](/developers/docs/evm/)是以太坊上智慧型合約的執行階段環境。 以太坊區塊鏈上的所有智慧型合約和狀態變更均由[交易](/developers/docs/transactions/)執行。 以太坊虛擬機器負責處理以太坊網路上的所有交易。
+[以太坊虛擬機 (EVM)](/developers/docs/evm/) 是以太坊上智慧型合約的執行環境。 以太坊區塊鏈上的所有智慧型合約和狀態變更都是透過[交易](/developers/docs/transactions/)執行的。 以太坊虛擬機器負責處理以太坊網路上的所有交易。
與任何虛擬機器一樣,以太坊虛擬機器在執行程式碼和執行機器(以太坊節點)之間建立了一個抽象層。 目前,以太坊虛擬機器運行在分佈於全球的數千個節點上。
-在後台,以太坊虛擬機器使用一組操作碼指令來執行特定任務。 這些(140 個獨特的)操作碼讓以太坊虛擬機器是**圖靈完備**的,這表示只要提供足夠資源,以太坊虛擬機器就可以進行任何運算。
+在後台,以太坊虛擬機器使用一組操作碼指令來執行特定任務。 這 140 個獨特的操作碼讓 EVM [圖靈完備](https://en.wikipedia.org/wiki/Turing_completeness),這表示只要有足夠的資源,EVM 就能計算幾乎任何東西。
作為去中心化應用程式開發者,不需要瞭解太多關於以太坊虛擬機器的知識,只需要瞭解其存在以及能夠可靠地為以太坊上的所有應用程式提供無停機的支援。
-## 等級 2:智慧型合約 {#smart-contracts}
+## 第 2 層:智慧型合約 {#smart-contracts}
-[智慧型合約](/developers/docs/smart-contracts/)為在以太坊區塊鏈上運行的可執行程式。
+[智慧型合約](/developers/docs/smart-contracts/) 是在以太坊區塊鏈上運行的可執行程式。
-智慧型合約使用特定[程式語言](/developers/docs/smart-contracts/languages/)來編譯至以太坊虛擬機器位元組碼(稱為操作碼的低階機器指令)。
+智慧型合約是使用特定的[程式語言](/developers/docs/smart-contracts/languages/)撰寫的,可編譯成 EVM 位元組碼 (稱為操作碼的低階機器指令)。
-智慧型合約不僅充當開源程式庫,而且本質上是始終運行且無法關閉的開放應用程式介面服務。 智慧型合約提供使用者和應用程式([去中心化應用程式](/developers/docs/dapps/))無需許可即可與之互動的公共功能。 任何應用程式都可以與已部署的智慧型合約整合以構成功能,例如新增[資料饋送](/developers/docs/oracles/)或支援代幣兌換。 此外,任何人都可以將新的智慧型合約部署到以太坊,以新增自訂功能來滿足其應用程式的需求。
+智慧型合約不僅充當開源程式庫,而且本質上是始終運行且無法關閉的開放應用程式介面服務。 智慧型合約提供公開函式,使用者和應用程式 ([去中心化應用程式](/developers/docs/dapps/)) 無需許可即可與之互動。 任何應用程式都可以與已部署的智慧型合約整合,以組合出新功能,例如新增[資料饋送](/developers/docs/oracles/)或支援代幣交換。 此外,任何人都可以將新的智慧型合約部署到以太坊,以新增自訂功能來滿足其應用程式的需求。
作為去中心化應用程式開發者,只有當你想在以太坊區塊鏈上新增自訂功能時,才需要編寫智慧型合約。 你可能會發現,只需與現有智慧型合約整合即可實現專案的大部分或全部需求,例如,如果想支援穩定幣支付或實現代幣的去中心化交易。
-## 等級 3:以太坊節點 {#ethereum-nodes}
+## 第 3 層:以太坊節點 {#ethereum-nodes}
-為了使應用程式能夠與以太坊區塊鏈互動,必須連結至[以太坊節點](/developers/docs/nodes-and-clients/)。 連結至節點可讓你讀取區塊鏈資料和/或將交易傳送到網路。
+應用程式若要與以太坊區塊鏈互動,就必須連接到[以太坊節點](/developers/docs/nodes-and-clients/)。 連結至節點可讓你讀取區塊鏈資料和/或將交易傳送到網路。
以太坊節點是運行軟體的電腦 - 以太坊用戶端。 用戶端是以太坊的實作,會驗證每個區塊中的所有交易,保持網路安全和資料準確。 **以太坊節點就是以太坊區塊鏈**。 以太坊節點共同存儲以太坊區塊鏈的狀態,並就交易達成共識以改變區塊鏈狀態。
-透過將你的應用程式連結到以太坊節點(透過 [JSON-RPC 應用程式介面](/developers/docs/apis/json-rpc/)),應用程式能夠從區塊鏈讀取資料(例如使用者帳戶餘額)並向網路廣播新交易(例如在使用者帳戶之間轉移以太幣或執行智慧型合約的功能)。
+將應用程式連接到以太坊節點 (透過 [JSON-RPC API](/developers/docs/apis/json-rpc/)) 後,應用程式便能夠從區塊鏈讀取資料 (例如使用者帳戶餘額),也能向網路廣播新交易 (例如在使用者帳戶之間轉移 ETH 或執行智慧型合約的函式)。
-## 等級 4:以太坊用戶端應用程式介面 {#ethereum-client-apis}
+## 第 4 層:以太坊用戶端 API {#ethereum-client-apis}
許多便利的程式庫(由以太坊的開源社群建立和維護)允許你的應用程式連結到以太坊區塊鏈並與之通訊。
-如果你的面向使用者的應用程式是網路應用程式,可以選擇直接在前端透過 `npm install` 安裝 [JavaScript API](/developers/docs/apis/javascript/)。 或者,你可能會選擇使用 [Python](/developers/docs/programming-languages/python/) 或 [Java](/developers/docs/programming-languages/java/) 應用程式介面在伺服器端實作此功能。
+如果你的使用者導向應用程式是網頁應用程式,你可以選擇直接在前端用 `npm install` 安裝 [JavaScript API](/developers/docs/apis/javascript/)。 或者,你也可以選擇在伺服器端,使用 [Python](/developers/docs/programming-languages/python/) 或 [Java](/developers/docs/programming-languages/java/) API 來實作此功能。
-雖然這些應用程式介面不是堆疊的必要組成部分,但顯著降低了與以太坊節點直接互動的複雜度。 這些應用程式介面還提供公用程式功能(例如將 ETH 轉換為 Gwei),使得開發者可以花更少的時間處理複雜的以太坊用戶端,將更多的時間專注於應用程式的特定功能。
+雖然這些應用程式介面不是堆疊的必要組成部分,但顯著降低了與以太坊節點直接互動的複雜度。 它們也提供工具函式 (例如,將 ETH 轉換為 Gwei),因此開發人員可以花更少的時間處理以太坊用戶端的複雜細節,而將更多時間專注在應用程式的特定功能上。
-## 等級 5:終端使用者應用程式 {#end-user-applications}
+## 第 5 層:終端使用者應用程式 {#end-user-applications}
堆疊的頂層是面向使用者的應用程式。 它們是目前經常使用和建立的標準應用程式:主要是 Web 和行動應用程式。
開發這些使用者介面的方式基本上保持不變。 通常,使用者不需要知道他們正在使用的應用程式是使用區塊鏈建立的。
-## 準備好選擇你的堆疊了嗎? {#ready-to-choose-your-stack}
+## 準備好選擇你的堆疊了嗎? 準備好選擇你的技術堆疊了嗎? {#ready-to-choose-your-stack}
-請查看我們的指南,瞭解如何為你的以太坊應用程式[設定本地開發環境](/developers/local-environment/)。
+請參閱我們的指南,為你的以太坊應用程式[設定本機開發環境](/developers/local-environment/)。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [Web 3.0 應用程式的架構](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/evm/index.md b/public/content/translations/zh-tw/developers/docs/evm/index.md
index 15bd936d253..75cbbb34e7f 100644
--- a/public/content/translations/zh-tw/developers/docs/evm/index.md
+++ b/public/content/translations/zh-tw/developers/docs/evm/index.md
@@ -4,59 +4,69 @@ description: 以太坊虛擬機及其與網路狀態、交易、智慧型合約
lang: zh-tw
---
-以太坊虛擬機 (EVM) 是去中心化的虛擬環境,可以跨所有以太坊節點一致且安全地執行程式碼。 節點運行以太坊虛擬機來執行智慧型合約,使用「[燃料](/gas/)」來衡量[運算](/developers/docs/evm/opcodes/)所需的算力,確保高效的資源分配和網路安全。
+以太坊虛擬機 (EVM) 是去中心化的虛擬環境,可以跨所有以太坊節點一致且安全地執行程式碼。 節點運行 EVM 來執行智能合約,使用「[gas](/developers/docs/gas/)」來衡量[運算](/developers/docs/evm/opcodes/)所需的計算量,確保資源有效分配和網路安全。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-首先,對電腦科學之常用術語,例如[字節位元組](https://wikipedia.org/wiki/Byte)、[記憶體](https://wikipedia.org/wiki/Computer_memory)及[堆疊](https://wikipedia.org/wiki/Stack_(abstract_data_type))等有一個基本認知,才能夠理解以太坊虛擬機。 熟悉密碼學/區塊鏈概念,如[雜湊函式](https://wikipedia.org/wiki/Cryptographic_hash_function)和[梅克爾樹](https://wikipedia.org/wiki/Merkle_tree)等也有幫助。
+若要了解 EVM,必須對電腦科學中的常用術語,例如 [bytes](https://wikipedia.org/wiki/Byte)、[memory](https://wikipedia.org/wiki/Computer_memory) 和 [stack](https://wikipedia.org/wiki/Stack_\(abstract_data_type\)) 等有基本認識。 熟悉[哈希函數](https://wikipedia.org/wiki/Cryptographic_hash_function)和[默克爾樹](https://wikipedia.org/wiki/Merkle_tree)等密碼學/區塊鏈概念也會很有幫助。
-## 從帳本至狀態機 {#from-ledger-to-state-machine}
+## 從帳本到狀態機 {#from-ledger-to-state-machine}
我們經常使用「分佈式帳本」這一比喻來描述比特幣一類的區塊鏈,區塊鏈透過使用一些基礎加密工具來支持去中心化貨幣。 帳本維護著活動記錄,並且必須遵守一套管控帳本修改相關操作的規則。 例如,比特幣地址無法花費超出其先前接受數量之比特幣。 此類規則構成比特幣及其他區塊鏈上所有交易的基礎。
-盡管以太坊有著自己的原生加密貨幣(以太幣)且遵循幾乎相同的直觀規則,但它還支持一種更加強大的功能:[智慧型合約](/developers/docs/smart-contracts/)。 對於此更為複雜的功能,需要一種更貼切之比喻來形容以太坊。 以太坊並非分佈式帳本,而是一種分佈式[狀態機](https://wikipedia.org/wiki/Finite-state_machine)。 以太坊狀態為一種龐大資料結構,其中不僅包含所有帳戶與餘額還包括_機器狀態_,機器狀態能夠遵照先前定義的一套規則在區塊之間變化並能執行任何機器程式碼。 在區塊之間變更狀態的具體規則由以太坊虛擬機定義。
+雖然以太坊有自己的原生加密貨幣 (以太幣),遵循著幾乎完全相同的直觀規則,但它也啟用了一項更強大的功能:[智能合約](/developers/docs/smart-contracts/)。 對於此更為複雜的功能,需要一種更貼切之比喻來形容以太坊。 以太坊不是分散式帳本,而是分散式[狀態機](https://wikipedia.org/wiki/Finite-state_machine)。 以太坊的狀態是一個龐大的資料結構,不僅保存了所有帳戶和餘額,還保存了一個「_機器狀態_」。這個狀態可以根據預先定義的一組規則,在區塊之間變更,並且可以執行任意機器程式碼。 在區塊之間變更狀態的具體規則由以太坊虛擬機定義。
- _此圖源於[以太坊EVM圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-## 以太坊狀態轉換函式 {#the-ethereum-state-transition-function}
+## 以太坊狀態轉換函數 {#the-ethereum-state-transition-function}
-以太坊虛擬機的運行類似於數學函式:提供一個輸入,就會生成確定的輸出。 因此,更加正式地描述以太坊具有**狀態轉換函式**將很有幫助:
+以太坊虛擬機的運行類似於數學函式:提供一個輸入,就會生成確定的輸出。 因此,將以太坊更正式地描述為具有**狀態轉換函數**會很有幫助:
```
Y(S, T)= S'
```
-提供一個舊的有效狀態 `(S)` 及一組新的有效交易 `(T)`,以太坊狀態轉換函式 `Y(S, T)` 將生成一個新的有效輸出狀態 `S'`。
+給定一個舊的有效狀態 `(S)` 和一組新的有效交易 `(T)`,以太坊狀態轉換函數 `Y(S, T)` 會產生一個新的有效輸出狀態 `S'`。
### 狀態 {#state}
-在以太坊情境下,狀態為一個龐大的資料結構,稱為[改進的梅克爾帕特里夏樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/),該樹保存由雜湊值連接在一起的所有[帳戶](/developers/docs/accounts/)且可回朔至在區塊鏈上儲存的單一根哈希。
+在以太坊的脈絡中,狀態是一個龐大的資料結構,稱為[改良式 Merkle Patricia 樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/),它將所有[帳戶](/developers/docs/accounts/)以哈希連結,並可歸納為儲存在區塊鏈上的單一根哈希。
### 交易 {#transactions}
-交易為完全由帳戶指令加密簽章. 交易主要有兩種類型:一種交易發起訊息調用,一種啟動合約建立。
+交易是帳戶發出的帶密碼學簽章的指令。 交易主要有兩種類型:一種交易發起訊息調用,一種啟動合約建立。
-合約建立將建立一個新合約帳戶,其中包含已編譯的[智慧型合約](/developers/docs/smart-contracts/anatomy/)位元組碼。 當其他帳戶對該合約進行訊息調用時,將執行該合約的位元組碼。
+創建合約會產生一個新的合約帳戶,其中包含已編譯的[智能合約](/developers/docs/smart-contracts/anatomy/)位元組碼。 當其他帳戶對該合約進行訊息調用時,將執行該合約的位元組碼。
-## 以太坊虛擬機相關說明 {#evm-instructions}
+## EVM 指令 {#evm-instructions}
-以太坊虛擬機的執行類似於[堆疊機](https://wikipedia.org/wiki/Stack_machine),執行深度為 1024 個專案。 每個專案均為 256 位元的字,選擇它是為了方便用於 256 位元加密(例如,Keccak-256 雜湊或 secp256k1 簽章)。
+EVM 作為[堆疊機](https://wikipedia.org/wiki/Stack_machine)執行,深度為 1024 個項目。 每個專案均為 256 位元的字,選擇它是為了方便用於 256 位元加密(例如,Keccak-256 雜湊或 secp256k1 簽章)。
-執行過程中,以太坊虛擬機維持一個臨時_記憶體_(即字尋址字元陣列),該記憶體於交易間隔期間不存在。
+在執行期間,EVM 會維護一個暫時性的「_記憶體_」(一個字組定址的位元組陣列),此記憶體在不同交易之間不會留存。
-然而,合約確實包含一棵梅克爾帕特里夏_儲存_樹(即字尋址字陳列),該樹與相關帳戶關聯且是全域狀態的一部分。
+### 暫時性儲存
-已編譯的智慧型合約位元組碼作為一些以太坊虛擬機[作業碼](/developers/docs/evm/opcodes)執行,後者執行標準堆疊操作,例如 `XOR`、`AND`、`ADD`、`SUB` 等。 以太坊虛擬機亦可透過一些區塊鏈特定的堆疊操作實作,例如 `ADDRESS`、`BALANCE`、`BLOCKHASH` 等。
+暫時性儲存是每個交易的鍵值儲存庫,可透過 `TSTORE` 和 `TLOAD` 操作碼存取。 它會在同個交易內的所有內部呼叫中持續存在,但在交易結束時會被清除。 與記憶體不同,暫時性儲存被塑模為 EVM 狀態的一部分,而非執行框架,但它不會被提交到全域狀態。 暫時性儲存可以在交易期間,讓內部呼叫以符合 gas 效益的方式共享暫時狀態。
- _圖表源於[以太坊虛擬機圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+### 儲存
-## 以太坊虛擬機實作 {#evm-implementations}
+合約包含一個 Merkle Patricia _儲存_樹(一個字組定址的字組陣列),與相關帳戶關聯,並且是全域狀態的一部分。 這種永久性儲存與暫時性儲存不同,暫時性儲存僅在單一交易期間可用,且不構成帳戶永久性儲存樹的一部分。
+
+### 作業碼
+
+已編譯的智能合約位元組碼會以多個 EVM [操作碼](/developers/docs/evm/opcodes)的形式執行,這些操作碼會執行標準的堆疊操作,例如 `XOR`、`AND`、`ADD`、`SUB` 等。 EVM 也實作了一些區塊鏈專用的堆疊操作,例如 `ADDRESS`、`BALANCE`、`BLOCKHASH` 等。 操作碼集還包括 `TSTORE` 和 `TLOAD`,可用來存取暫時性儲存。
+
+
+_圖表改編自 [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+## EVM 實作 {#evm-implementations}
所有以太坊虛擬機實作均須遵照以太坊黃皮書中規定的相關規範。
-在以太坊九年的歷程中,以太坊虛擬機經歷了數次修改,有著各種不同程式語言的以太坊虛擬機實作。
+在以太坊十年的歷史中,EVM 經歷了數次修訂,並且有以各種程式語言撰寫的數種 EVM 實作版本。
-[以太坊執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)包含以太坊虛擬機實作。 此外,還有一些獨立的實作,包括:
+[以太坊執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)包含一個 EVM 實作。 此外,還有一些獨立的實作,包括:
- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_
- [evmone](https://github.com/ethereum/evmone) - _C++_
@@ -66,12 +76,12 @@ Y(S, T)= S'
## 延伸閱讀 {#further-reading}
- [以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)
-- [Jellopaper 亦稱為 KEVM:K 框架中的以太坊虛擬機語意](https://jellopaper.org/)
-- [The Beigepaper](https://github.com/chronaeon/beigepaper)
-- [以太坊虛擬機作業碼](https://www.ethervm.io/)
-- [以太坊虛擬機作業碼互動式參考資料](https://www.evm.codes/)
-- [Solidity 文件簡介](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
-- [掌握以太坊 - 以太坊虛擬機 (EVM)](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
+- [Jellopaper 又名 KEVM:K 框架中的 EVM 語意學](https://jellopaper.org/)
+- [米色論文](https://github.com/chronaeon/beigepaper)
+- [以太坊虛擬機操作碼](https://www.ethervm.io/)
+- [以太坊虛擬機操作碼互動式參考](https://www.evm.codes/)
+- [Solidity 文件中的簡短介紹](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
+- [精通以太坊 - 以太坊虛擬機](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
## 相關主題 {#related-topics}
diff --git a/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md b/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
index 58812e2ebd4..7aa24c69b79 100644
--- a/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
+++ b/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
@@ -4,171 +4,174 @@ description: 以太坊虛擬機可用的所有作業碼清單。
lang: zh-tw
---
-## 概觀 {#overview}
+## 概覽{#overview}
-本文是以太坊虛擬機參考頁面的更新版本,網址為:[wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes)。 同樣取自[黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)、[Jello Paper](https://jellopaper.org/evm/) 和 [geth](https://github.com/ethereum/go-ethereum) 實作。 本文意圖成为方便參考的頁面,但並非特別嚴謹。 若你想確定正確性並了解每種邊界案例(指僅在極端工作參數下才會發生的問題或情況),建議使用 Jello Paper 或用戶端實作。
+這是 [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes) 上 EVM 參考頁面的更新版本。
+內容也參考自 [黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)、[Jello Paper](https://jellopaper.org/evm/) 和 [geth](https://github.com/ethereum/go-ethereum) 的實作。
+本文意圖成为方便參考的頁面,但並非特別嚴謹。
+若你想確定正確性並了解每種邊界案例(指僅在極端工作參數下才會發生的問題或情況),建議使用 Jello Paper 或用戶端實作。
-正在尋找互動式參考資料? 請瀏覽 [evm.codes](https://www.evm.codes/)
+正在尋找互動式參考資料? 請查看 [evm.codes](https://www.evm.codes/)。
-關於燃料費用為動態的操作,請查看 [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md)。
+關於動態 gas 成本的操作,請參閱 [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md)。
-💡 快速提示:要檢視整行,可以用 `[shift] + 滑鼠滾輪`在桌面上水平滾動。
+💡 快速提示:若要檢視完整一行,請使用 `[shift] + scroll` 在桌上型電腦上水平捲動。
-| 堆疊 | 名稱 | 燃料 | 初始堆疊 | 最終堆疊 | 記憶體/儲存空間 | 注釋 |
-|:-----:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 00 | STOP | 0 | | | | halt execution |
-| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 |
-| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 |
-| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 |
-| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division |
-| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division |
-| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus |
-| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus |
-| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N |
-| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N |
-| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 |
-| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes |
-| 0C-0F | _invalid_ | | | | | |
-| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than |
-| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than |
-| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than |
-| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than |
-| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality |
-| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero |
-| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND |
-| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR |
-| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR |
-| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT |
-| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left |
-| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left |
-| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right |
-| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right |
-| 1E-1F | _invalid_ | | | | | |
-| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 |
-| 21-2F | _invalid_ | | | | | |
-| 30 | ADDRESS | 2 | `。` | `address(this)` | | address of executing contract |
-| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei |
-| 32 | ORIGIN | 2 | `。` | `tx.origin` | | address that originated the tx |
-| 33 | CALLER | 2 | `。` | `msg.sender` | | address of msg sender |
-| 34 | CALLVALUE | 2 | `。` | `msg.value` | | msg value, in wei |
-| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` |
-| 36 | CALLDATASIZE | 2 | `。` | `len(msg.data)` | | length of msg data, in bytes |
-| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data |
-| 38 | CODESIZE | 2 | `。` | `len(this.code)` | | length of executing contract's code, in bytes |
-| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode |
-| 3A | GASPRICE | 2 | `。` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) |
-| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes |
-| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` |
-| 3D | RETURNDATASIZE | 2 | `。` | `size` | | size of returned data from last external call, in bytes |
-| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call |
-| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 |
-| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | |
-| 41 | COINBASE | 2 | `。` | `block.coinbase` | | 目前區塊提交者的地址 |
-| 42 | TIMESTAMP | 2 | `。` | `block.timestamp` | | timestamp of current block |
-| 43 | NUMBER | 2 | `。` | `block.number` | | number of current block |
-| 44 | PREVRANDAO | 2 | `。` | `randomness beacon` | | randomness beacon |
-| 45 | GASLIMIT | 2 | `。` | `block.gaslimit` | | gas limit of current block |
-| 46 | CHAINID | 2 | `。` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack |
-| 47 | SELFBALANCE | 5 | `。` | `address(this).balance` | | balance of executing contract, in wei |
-| 48 | BASEFEE | 2 | `。` | `block.basefee` | | base fee of current block |
-| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
-| 4A | BLOBBASEFEE | 2 | `。` | `block.blobbasefee` | | 当前区块的二進位大型物件基本费用 ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
-| 4B-4F | _invalid_ | | | | | |
-| 50 | POP | 2 | `_anon` | `。` | | remove item from top of stack and discard it |
-| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` |
-| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `。` | mem[ost:ost+32] := val | write a word to memory |
-| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `。` | mem[ost] := val && 0xFF | write a single byte to memory |
-| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage |
-| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `。` | storage[key] := val | write word to storage |
-| 56 | JUMP | 8 | `dst` | `。` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest |
-| 57 | JUMPI | 10 | `dst, condition` | `。` | | `$pc := condition ? dst : $pc + 1` |
-| 58 | PC | 2 | `。` | `$pc` | | program counter |
-| 59 | MSIZE | 2 | `。` | `len(mem)` | | size of memory in current execution context, in bytes |
-| 5A | GAS | 2 | `。` | `gasRemaining` | | |
-| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data |
-| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | 從暫存中讀取字詞 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5D | TSTORE | 100 | `key, val` | `。` | tstorage[key] := val | 將字詞寫入暫存 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5E | MCOPY | 3+3\*字詞數+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `。` | mem[dstOst] := mem[ost:ost+len] | 從一個區域複製記憶體到另一個區域 ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
-| 5E | PUSH0 | 2 | `。` | `uint8` | | 將常數值 0 推至堆疊上 |
-| 60 | PUSH1 | 3 | `。` | `uint8` | | push 1-byte value onto stack |
-| 61 | PUSH2 | 3 | `。` | `uint16` | | push 2-byte value onto stack |
-| 62 | PUSH3 | 3 | `。` | `uint24` | | push 3-byte value onto stack |
-| 63 | PUSH4 | 3 | `。` | `uint32` | | push 4-byte value onto stack |
-| 64 | PUSH5 | 3 | `。` | `uint40` | | push 5-byte value onto stack |
-| 65 | PUSH6 | 3 | `。` | `uint48` | | push 6-byte value onto stack |
-| 66 | PUSH7 | 3 | `。` | `uint56` | | push 7-byte value onto stack |
-| 67 | PUSH8 | 3 | `。` | `uint64` | | push 8-byte value onto stack |
-| 68 | PUSH9 | 3 | `。` | `uint72` | | push 9-byte value onto stack |
-| 69 | PUSH10 | 3 | `。` | `uint80` | | push 10-byte value onto stack |
-| 6A | PUSH11 | 3 | `。` | `uint88` | | push 11-byte value onto stack |
-| 6B | PUSH12 | 3 | `。` | `uint96` | | push 12-byte value onto stack |
-| 6C | PUSH13 | 3 | `。` | `uint104` | | push 13-byte value onto stack |
-| 6D | PUSH14 | 3 | `。` | `uint112` | | push 14-byte value onto stack |
-| 6E | PUSH15 | 3 | `。` | `uint120` | | push 15-byte value onto stack |
-| 6F | PUSH16 | 3 | `。` | `uint128` | | push 16-byte value onto stack |
-| 70 | PUSH17 | 3 | `。` | `uint136` | | push 17-byte value onto stack |
-| 71 | PUSH18 | 3 | `。` | `uint144` | | push 18-byte value onto stack |
-| 72 | PUSH19 | 3 | `。` | `uint152` | | push 19-byte value onto stack |
-| 73 | PUSH20 | 3 | `。` | `uint160` | | push 20-byte value onto stack |
-| 74 | PUSH21 | 3 | `。` | `uint168` | | push 21-byte value onto stack |
-| 75 | PUSH22 | 3 | `。` | `uint176` | | push 22-byte value onto stack |
-| 76 | PUSH23 | 3 | `。` | `uint184` | | push 23-byte value onto stack |
-| 77 | PUSH24 | 3 | `。` | `uint192` | | push 24-byte value onto stack |
-| 78 | PUSH25 | 3 | `。` | `uint200` | | push 25-byte value onto stack |
-| 79 | PUSH26 | 3 | `。` | `uint208` | | push 26-byte value onto stack |
-| 7A | PUSH27 | 3 | `。` | `uint216` | | push 27-byte value onto stack |
-| 7B | PUSH28 | 3 | `。` | `uint224` | | push 28-byte value onto stack |
-| 7C | PUSH29 | 3 | `。` | `uint232` | | push 29-byte value onto stack |
-| 7D | PUSH30 | 3 | `。` | `uint240` | | push 30-byte value onto stack |
-| 7E | PUSH31 | 3 | `。` | `uint248` | | push 31-byte value onto stack |
-| 7F | PUSH32 | 3 | `。` | `uint256` | | push 32-byte value onto stack |
-| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack |
-| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack |
-| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack |
-| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack |
-| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack |
-| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack |
-| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack |
-| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack |
-| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack |
-| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack |
-| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack |
-| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack |
-| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack |
-| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack |
-| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack |
-| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack |
-| 90 | SWAP1 | 3 | `a, b` | `b, a` | | |
-| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | |
-| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | |
-| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | |
-| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | |
-| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `。` | | LOG0(memory[ost:ost+len-1]) |
-| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `。` | | LOG1(memory[ost:ost+len-1], topic0) |
-| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `。` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
-| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `。` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
-| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `。` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
-| A5-EF | _invalid_ | | | | | |
-| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
-| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value |
-| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `。` | | return mem[ost:ost+len-1] |
-| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
-| F6-F9 | _invalid_ | | | | | |
-| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| FB-FC | _invalid_ | | | | | |
-| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `。` | | revert(mem[ost:ost+len-1]) |
-| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
-| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `。` | | 傳送所有以太幣到 `addr`;如果在建立合約的相同交易中執行,則會銷毀合約 |
+| 堆疊 | 名稱 | 燃料 | 初始堆疊 | 最終堆疊 | 記憶體/儲存空間 | 注釋 | |
+| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
+| 00 | STOP | 0 | | | | 停止執行 | |
+| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 加法,模數為 2\*\*256 | |
+| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 乘法,模數為 2\*\*256 | |
+| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 減法,模數為 2\*\*256 | |
+| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 除法 | |
+| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 除法 | |
+| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 模數運算 | |
+| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 模數運算 | |
+| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 加法,模數為 N | |
+| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 乘法,模數為 N | |
+| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 冪,模數為 2\*\*256 | |
+| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | 對 `x` 進行[符號擴充](https://wikipedia.org/wiki/Sign_extension),從 `(b+1)` 位元組擴充為 32 位元組。 | |
+| 0C-0F | _無效_ | | | | | | |
+| 10 | LT | 3 | `a, b` | `a < b` | | uint256 小於 | |
+| 11 | GT | 3 | `a, b` | `a > b` | | uint256 大於 | |
+| 12 | SLT | 3 | `a, b` | `a < b` | | int256 小於 | |
+| 13 | SGT | 3 | `a, b` | `a > b` | | int256 大於 | |
+| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 相等 | |
+| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 是否為零 | |
+| 16 | AND | 3 | `a, b` | `a && b` | | 位元 AND | |
+| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | 位元 OR | |
+| 18 | XOR | 3 | `a, b` | `a ^ b` | | 位元 XOR | |
+| 19 | NOT | 3 | `a` | `~a` | | 位元 NOT | |
+| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | 從左邊算起,(u)int256 `x` 的第 `i` 個位元組 | |
+| 1B | SHL | 3 | `shift, val` | `val << shift` | | 向左移位 | |
+| 1C | SHR | 3 | `shift, val` | `val >> shift` | | 邏輯右移 | |
+| 1D | SAR | 3 | `shift, val` | `val >> shift` | | 算術右移 | |
+| 1E-1F | _無效_ | | | | | | |
+| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | |
+| 21-2F | _無效_ | | | | | | |
+| 30 | ADDRESS | 2 | `.` | `address(this)` | | 執行合約的地址 | |
+| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | 餘額,以 wei 計 | |
+| 32 | ORIGIN | 2 | `.` | `tx.origin` | | 發起交易的地址 | |
+| 33 | CALLER | 2 | `.` | `msg.sender` | | 訊息發送者的地址 | |
+| 34 | CALLVALUE | 2 | `.` | `msg.value` | | 訊息數值,以 wei 計 | |
+| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | 從索引 `idx` 讀取訊息資料中的字 | |
+| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | 訊息資料的長度,以位元組計 | |
+| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | 複製訊息資料 | |
+| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | 執行合約的程式碼長度,以位元組計 | |
+| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | 複製執行合約的位元組碼 |
+| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | 交易的 gas 價格,以 wei/單位 gas 計 [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | |
+| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | 地址處程式碼的大小,以位元組計 | |
+| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | 從 `addr` 複製程式碼 | |
+| 3D | RETURNDATASIZE | 2 | `.` | `size` | | 上次外部呼叫所回傳資料的大小,以位元組計 | |
+| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | 複製上次外部呼叫所回傳的資料 | |
+| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `雜湊值` | | hash = addr.exists ? keccak256(addr.code) : 0 | |
+| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | |
+| 41 | COINBASE | 2 | `.` | `block.coinbase` | | 目前區塊提交者的地址 | |
+| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | 目前區塊的時間戳 | |
+| 43 | NUMBER | 2 | `.` | `block.number` | | 目前區塊的編號 | |
+| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | 隨機信標 | |
+| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | 目前區塊的 gas 上限 | |
+| 46 | CHAINID | 2 | `.` | `chain_id` | | 將目前[鏈 ID](https://eips.ethereum.org/EIPS/eip-155) 推入堆疊 | |
+| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | 執行中合約的餘額,以 wei 計 | |
+| 48 | BASEFEE | 2 | `.` | `block.basefee` | | 目前區塊的基本費用 | |
+| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | |
+| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | 目前區塊的 Blob 基本費用 ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | |
+| 4B-4F | _無效_ | | | | | | |
+| 50 | POP | 2 | `_anon` | `.` | | 從堆疊頂端移除項目並捨棄 | |
+| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | 從偏移量 `ost` 的記憶體讀取字 | |
+| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | 將一個字寫入記憶體 | |
+| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | 將單一位元組寫入記憶體 | |
+| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | 從儲存體讀取字 | |
+| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | 將字寫入儲存體 | |
+| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` 標示 `pc` 僅在 `dst` 為有效跳轉目的地時才會被指派 | |
+| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1\` | |
+| 58 | PC | 2 | `.` | `$pc` | | 程式計數器 | |
+| 59 | MSIZE | 2 | `.` | `len(mem)` | | 目前執行情境中的記憶體大小,以位元組計 | |
+| 5A | GAS | 2 | `.` | `gasRemaining` | | | |
+| 5B | JUMPDEST | 1 | | | 標記有效的跳轉目的地 | 有效的跳轉目的地,例如不在推送資料內的跳轉目的地 | |
+| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | 從暫時性儲存體讀取字 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | |
+| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | 將字寫入暫時性儲存體 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | |
+| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | 將記憶體從一個區域複製到另一個區域 ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | |
+| 5E | PUSH0 | 2 | `.` | `uint8` | | 將常數值 0 推至堆疊上 | |
+| 60 | PUSH1 | 3 | `.` | `uint8` | | 將 1 位元組值推入堆疊 | |
+| 61 | PUSH2 | 3 | `.` | `uint16` | | 將 2 位元組值推入堆疊 | |
+| 62 | PUSH3 | 3 | `.` | `uint24` | | 將 3 位元組值推入堆疊 | |
+| 63 | PUSH4 | 3 | `.` | `uint32` | | 將 4 位元組值推入堆疊 | |
+| 64 | PUSH5 | 3 | `.` | `uint40` | | 將 5 位元組值推入堆疊 | |
+| 65 | PUSH6 | 3 | `.` | `uint48` | | 將 6 位元組值推入堆疊 | |
+| 66 | PUSH7 | 3 | `.` | `uint56` | | 將 7 位元組值推入堆疊 | |
+| 67 | PUSH8 | 3 | `.` | `uint64` | | 將 8 位元組值推入堆疊 | |
+| 68 | PUSH9 | 3 | `.` | `uint72` | | 將 9 位元組值推入堆疊 | |
+| 69 | PUSH10 | 3 | `.` | `uint80` | | 將 10 位元組值推入堆疊 | |
+| 6A | PUSH11 | 3 | `.` | `uint88` | | 將 11 位元組值推入堆疊 | |
+| 6B | PUSH12 | 3 | `.` | `uint96` | | 將 12 位元組值推入堆疊 | |
+| 6C | PUSH13 | 3 | `.` | `uint104` | | 將 13 位元組值推入堆疊 | |
+| 6D | PUSH14 | 3 | `.` | `uint112` | | 將 14 位元組值推入堆疊 | |
+| 6E | PUSH15 | 3 | `.` | `uint120` | | 將 15 位元組值推入堆疊 | |
+| 6F | PUSH16 | 3 | `.` | `uint128` | | 將 16 位元組值推入堆疊 | |
+| 70 | PUSH17 | 3 | `.` | `uint136` | | 將 17 位元組值推入堆疊 | |
+| 71 | PUSH18 | 3 | `.` | `uint144` | | 將 18 位元組值推入堆疊 | |
+| 72 | PUSH19 | 3 | `.` | `uint152` | | 將 19 位元組值推入堆疊 | |
+| 73 | PUSH20 | 3 | `.` | `uint160` | | 將 20 位元組值推入堆疊 | |
+| 74 | PUSH21 | 3 | `.` | `uint168` | | 將 21 位元組值推入堆疊 | |
+| 75 | PUSH22 | 3 | `.` | `uint176` | | 將 22 位元組值推入堆疊 | |
+| 76 | PUSH23 | 3 | `.` | `uint184` | | 將 23 位元組值推入堆疊 | |
+| 77 | PUSH24 | 3 | `.` | `uint192` | | 將 24 位元組值推入堆疊 | |
+| 78 | PUSH25 | 3 | `.` | `uint200` | | 將 25 位元組值推入堆疊 | |
+| 79 | PUSH26 | 3 | `.` | `uint208` | | 將 26 位元組值推入堆疊 | |
+| 7A | PUSH27 | 3 | `.` | `uint216` | | 將 27 位元組值推入堆疊 | |
+| 7B | PUSH28 | 3 | `.` | `uint224` | | 將 28 位元組值推入堆疊 | |
+| 7C | PUSH29 | 3 | `.` | `uint232` | | 將 29 位元組值推入堆疊 | |
+| 7D | PUSH30 | 3 | `.` | `uint240` | | 將 30 位元組值推入堆疊 | |
+| 7E | PUSH31 | 3 | `.` | `uint248` | | 將 31 位元組值推入堆疊 | |
+| 7F | PUSH32 | 3 | `.` | `uint256` | | 將 32 位元組值推入堆疊 | |
+| 80 | DUP1 | 3 | `a` | `a, a` | | 複製堆疊上的第 1 個值 | |
+| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | 複製堆疊上的第 2 個值 | |
+| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | 複製堆疊上的第 3 個值 | |
+| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | 複製堆疊上的第 4 個值 | |
+| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 5 個值 | |
+| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 6 個值 | |
+| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 7 個值 | |
+| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 8 個值 | |
+| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 9 個值 | |
+| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 10 個值 | |
+| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 11 個值 | |
+| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 12 個值 | |
+| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 13 個值 | |
+| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 14 個值 | |
+| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 15 個值 | |
+| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 16 個值 | |
+| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | |
+| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | |
+| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | |
+| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | |
+| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | |
+| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | |
+| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | |
+| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | |
+| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | |
+| A5-EF | _無效_ | | | | | | |
+| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | |
+| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | 與 DELEGATECALL 相同,但不傳播原始的 msg.sender 和 msg.value | |
+| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | 回傳 mem[ost:ost+len-1] | |
+| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | |
+| F6-F9 | _無效_ | | | | | | |
+| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| FB-FC | _無效_ | | | | | | |
+| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | 還原 (mem[ost:ost+len-1]) | |
+| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | 指定的無效操作碼 - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | |
+| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | 將所有 ETH 傳送到 `addr`;如果在建立合約的同筆交易中執行,就會銷毀該合約 | |
diff --git a/public/content/translations/zh-tw/developers/docs/frameworks/index.md b/public/content/translations/zh-tw/developers/docs/frameworks/index.md
index 9929d5aab4b..9cfc5ac3db4 100644
--- a/public/content/translations/zh-tw/developers/docs/frameworks/index.md
+++ b/public/content/translations/zh-tw/developers/docs/frameworks/index.md
@@ -4,68 +4,76 @@ description: 探索架構優勢及比較現有選項。
lang: zh-tw
---
-## 架構簡介 {#introduction-to-frameworks}
+## 框架簡介 {#introduction-to-frameworks}
-建構成熟的去中心化應用程式需要 不同的技術。 軟體架構包含許多必要功能, 或提供簡單的外掛程式系統來選擇 你需要的工具。
+建構成熟的去中心化應用程式需要
+不同的技術。 軟體架構包含許多必要功能,
+或提供簡單的外掛程式系統來選擇
+你需要的工具。
-架構帶有許多非常規功能, 例如:
+架構帶有許多非常規功能,
+例如:
-- 編列系統內區塊鏈功能.
+- 運行本機區塊鏈實例功能。
- 編輯和測試你的智慧型合約.
-- 用戶端開發外掛程式可在同一專案/儲存庫中建立 面向使用者的應用程式。
-- 用於連結到以太坊網路並部署 合約的設定,無論是連接到本地運行的執行個體 還是連結到以太坊的公共網路之一。
-- 去中心化應用程式分發 - 與星際檔案系統 等存儲選項整合。
+- 用戶端開發附加元件,可在同一個專案/儲存庫中建立
+ 面對使用者的應用程式。
+- 用於連結到以太坊網路並部署
+ 合約的設定,無論是連接到本地運行的執行個體
+ 還是連結到以太坊的公共網路之一。
+- 去中心化應用程式發行 - 與 IPFS 等儲存選項
+ 整合。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在深入介紹這些架構之前,推薦你先閱讀下面的[去中心化應用程式](/developers/docs/dapps/)和[以太坊堆疊](/developers/docs/ethereum-stack/)簡介。
+在深入研究框架之前,建議您先閱讀我們的 [去中心化應用程式](/developers/docs/dapps/) 和 [以太坊技術堆疊](/developers/docs/ethereum-stack/) 簡介。
-## 可用架構 {#available-frameworks}
+## 可用的框架 {#available-frameworks}
-**Foundry** - **_Foundry 是一款快速、便攜和模組化的工具包,用於以太坊應用程式開發_**
+**Foundry** - **_Foundry 是一款極速、可攜式且模組化的工具組,用於開發以太坊應用程式_**
- [安裝 Foundry](https://book.getfoundry.sh/)
-- [Foundry 手册](https://book.getfoundry.sh/)
-- [Telegram 上的 Foundry 社群聊天](https://t.me/foundry_support)
+- [Foundry 書籍](https://book.getfoundry.sh/)
+- [Telegram 上的 Foundry 社群聊天室](https://t.me/foundry_support)
- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry)
-**Hardhat -** **_專業以太坊開發環境。_**
+**Hardhat -** **_為專業人士打造的以太坊開發環境。_**
- [hardhat.org](https://hardhat.org)
- [GitHub](https://github.com/nomiclabs/hardhat)
-**Ape -** **_Python 程式人員、資料科學家和安全性專業人員適用的智慧型合約開發工具。_**
+**Ape -** **_專為 Python 開發人員、資料科學家和安全專家打造的智慧合約開發工具。_**
-- [文件](https://docs.apeworx.io/ape/stable/)
+- [說明文件](https://docs.apeworx.io/ape/stable/)
- [GitHub](https://github.com/ApeWorX/ape)
-**Web3j -** **_用於在 JAVA 虛擬機上開發區塊鏈應用程式的平台。_**
+**Web3j -** **_一個在 JVM 上開發區塊鏈應用程式的平台。_**
- [首頁](https://www.web3labs.com/web3j-sdk)
-- [文件](https://docs.web3j.io)
+- [說明文件](https://docs.web3j.io)
- [GitHub](https://github.com/web3j/web3j)
-**ethers-kt -** **_適用基於以太坊虛擬機區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。_**
+**ethers-kt -** **_適用於 EVM 區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。_**
- [GitHub](https://github.com/Kr1ptal/ethers-kt)
- [範例](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
- [Discord](https://discord.gg/rx35NzQGSb)
-**Create Eth App -** **_使用一個命令建立以太坊支援的應用程式。 包含多種使用者介面架構與去中心化金融模板供你選擇。_**
+**Create Eth App -** **_用一道指令建立由以太坊驅動的應用程式。 包含多種UI架構與Defi模板供你選擇._**
- [GitHub](https://github.com/paulrberg/create-eth-app)
-- [模板](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
+- [範本](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
-**Scaffold-Eth -** **_Ethers.js + Hardhat + React 元件和 web3 掛勾:開始構建由智慧型合約支援的去中心化應用程式所需的一切。_**
+**Scaffold-Eth -** **_Ethers.js + Hardhat + React 元件和 web3 掛鉤:開始建構由智慧合約驅動的去中心化應用程式所需的一切。_**
- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2)
-**Tenderly -** **_Web3 開發平台,使區塊鏈開發者能夠建立、測試、除錯、監控和操作智慧型合約並改進去中心化應用程式使用者體驗。_**
+**Tenderly -** **_Web3 開發平台,能讓區塊鏈開發者建立、測試、除錯、監控和操作智慧合約,並改善去中心化應用程式的使用者體驗。_**
- [網站](https://tenderly.co/)
-- [文件](https://docs.tenderly.co/)
+- [說明文件](https://docs.tenderly.co/)
-**The Graph****_高效率查詢區塊鏈資料的圖表。_**
+**The Graph -** **_The Graph,有效率地查詢區塊鏈資料。_**
- [網站](https://thegraph.com/)
- [使用教學](/developers/tutorials/the-graph-fixing-web3-data-querying/)
@@ -82,68 +90,68 @@ lang: zh-tw
- [GitHub](https://github.com/node-real)
- [Discord](https://discord.gg/V5k5gsuE)
-**thirdweb SDK -** **_透過我們的強大軟體開發套件和命令列介面,可以建構與你的智慧型合約互動的 Web3 應用程式。_**
+**thirdweb SDK -** **_使用我們強大的 SDK 和 CLI,建構可與您的智慧合約互動的 web3 應用程式。_**
-- [文件](https://portal.thirdweb.com/sdk/)
-- [Github](https://github.com/thirdweb-dev/)
+- [說明文件](https://portal.thirdweb.com/sdk/)
+- [GitHub](https://github.com/thirdweb-dev/)
-**Chainstack -** **_Web3(以太坊及其他區塊鏈)開發平台。_**
+**Chainstack -** **_Web3 (以太坊及其他) 開發平台。_**
- [chainstack.com](https://www.chainstack.com/)
-- [Github](https://github.com/chainstack)
+- [GitHub](https://github.com/chainstack)
- [Discord](https://discord.gg/BSb5zfp9AT)
-**Crossmint -** **_企業級 web3 開發平台,讓你在所有主要鏈以太坊虛擬機器鏈上建立非同質化代幣應用程式。_**
+**Crossmint -** **_企業級 web3 開發平台,讓您可以在所有主要 EVM 鏈 (及其他鏈) 上建立 NFT 應用程式。_**
- [網站](https://www.crossmint.com)
- [文件](https://docs.crossmint.com)
- [Discord](https://discord.com/invite/crossmint)
-**Brownie -** **_基於 Python 的開發環境和測試架構。_**
+**Brownie -** **_以 Python 為基礎的開發環境和測試框架。_**
-- [文件](https://eth-brownie.readthedocs.io/en/latest/)
+- [說明文件](https://eth-brownie.readthedocs.io/en/latest/)
- [GitHub](https://github.com/eth-brownie/brownie)
- **Brownie 目前未有維護**
-**OpenZeppelin 軟體開發套件 -** **_終極智慧型合約工具組:一套幫助你開發、編譯、升級、部署智慧型合約以及與智慧型合約互動的工具。_**
+**OpenZeppelin SDK -** **_終極智慧合約工具組:一套可協助您開發、編譯、升級、部署智慧合約並與其互動的工具。_**
-- [OpenZeppelin 軟體開發套件](https://openzeppelin.com/sdk/)
+- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk)
- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk)
- [社群論壇](https://forum.openzeppelin.com/c/support/17)
- **OpenZeppelin 軟體開發套件開發已結束**
-**Catapulta -** **_多鏈智慧型合約部署工具,在區塊瀏覽器中自動驗證,追蹤部署的智慧型合約並分享部署報告,Foundry 和 Hardhat 專案隨插即用。_**
+**Catapulta -** **_多鏈智慧合約部署工具,可在區塊瀏覽器中自動驗證、追蹤已部署的智慧合約並分享部署報告,為 Foundry 和 Hardhat 專案提供隨插即用功能。_**
- [網站](https://catapulta.sh/)
-- [文件](https://catapulta.sh/docs)
+- [說明文件](https://catapulta.sh/docs)
- [Github](https://github.com/catapulta-sh)
-**Covalent -** **_200 多條鏈的已擴充區塊鏈應用程式介面。_**
+**GoldRush (由 Covalent 提供技術支援) -** **_GoldRush 為開發人員、分析師和企業提供最全面的區塊鏈資料 API 套件, 無論您是在建構 DeFi 儀表板、錢包、交易機器人、AI 代理程式還是合規平台,資料 API 都能提供快速、準確且對開發人員友善的存取方式,讓您取得所需的必要鏈上資料_**
-- [covalenthq.com](https://www.covalenthq.com/)
-- [文件](https://www.covalenthq.com/docs/api/)
+- [網站](https://goldrush.dev/)
+- [說明文件](https://goldrush.dev/docs/chains/ethereum)
- [GitHub](https://github.com/covalenthq)
- [Discord](https://www.covalenthq.com/discord/)
**Wake -** **_用於合約測試、模糊測試、部署、漏洞掃描和程式碼導航的一體化 Python 框架。_**
- [首頁](https://getwake.io/)
-- [文件](https://ackeeblockchain.com/wake/docs/latest/)
+- [說明文件](https://ackeeblockchain.com/wake/docs/latest/)
- [GitHub](https://github.com/Ackee-Blockchain/wake)
- [VS Code 擴充功能](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
-**Veramo -** **_開放原始碼、模組化且不受限的框架,讓去中心化應用程式開發者能輕鬆地將去中心化身分和可驗證憑證整合到他們的應用程式中。_**
+**Veramo -** **_開源、模組化且不受限的框架,讓去中心化應用程式開發者能輕鬆地將去中心化身分和可驗證憑證整合到他們的應用程式中。_**
- [首頁](https://veramo.io/)
-- [文件](https://veramo.io/docs/basics/introduction)
+- [說明文件](https://veramo.io/docs/basics/introduction)
- [GitHub](https://github.com/uport-project/veramo)
- [Discord](https://discord.com/invite/FRRBdjemHV)
-- [節點包裹管理器 (NPM) 包裹](https://www.npmjs.com/package/@veramo/core)
+- [NPM 套件](https://www.npmjs.com/package/@veramo/core)
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [設定本地開發環境](/developers/local-environment/)
+- [設定本機開發環境](/developers/local-environment/)
diff --git a/public/content/translations/zh-tw/developers/docs/gas/index.md b/public/content/translations/zh-tw/developers/docs/gas/index.md
index efa60ccf64a..0d9bea110c3 100644
--- a/public/content/translations/zh-tw/developers/docs/gas/index.md
+++ b/public/content/translations/zh-tw/developers/docs/gas/index.md
@@ -1,15 +1,15 @@
---
title: 燃料和費用
metaTitle: "以太坊燃料和費用:技術概覽"
-description:
+description: 了解以太坊 Gas Fee、其計算方式,以及在網路安全和交易處理中的作用。
lang: zh-tw
---
燃料對於以太坊網路至關重要。 燃料讓以太坊得以運轉,就像是汽車需要汽油行駛一樣。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更好地理解本頁面,建議你先閱讀[交易](/developers/docs/transactions/)和[以太坊虛擬機](/developers/docs/evm/)。
+為更佳理解本頁面,我們建議您先閱讀關於 [交易](/developers/docs/transactions/) 和 [EVM](/developers/docs/evm/) 的內容。
## 什麼是燃料? {#what-is-gas}
@@ -17,80 +17,85 @@ lang: zh-tw
因為執行每一筆以太坊交易都需要計算資源,要使用這些資源就必須付費,以確保以太坊不會受到垃圾訊息的影響,或者卡在無窮計算迴圈中。 計算費用以燃料費的形式支付。
-燃料費的計算方式是**執行操作消耗的燃料數量乘以每單位燃料費價格**。 無論交易成功與否,都要支付燃料費。
+燃料費用是**執行某些操作所使用的燃料數量,乘以每單位燃料的成本**。 無論交易成功與否,都要支付燃料費。
- _此圖表源於[以太坊的以太坊虛擬機圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [以太坊 EVM 圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
燃料費須用以太坊原生貨幣以太幣 (ETH) 支付。 燃料價格一般會以 gwei 為單位,gwei 是以太幣的面額之一。 每一 gwei 等於一以太幣的十億分之一(0.000000001 以太幣或 10-9 以太幣)。
舉例來說,可以說你的燃料費為 1 gwei,而不是 0.000000001 以太幣。
-「gwei」這個字是「giga-wei」的縮寫,意思是「10 億 wei」。 1 gwei 等於 10 億 wei。 Wei 本身(命名於 [Wei Dai](https://wikipedia.org/wiki/Wei_Dai),[b-money](https://www.investopedia.com/terms/b/bmoney.asp) 創建者)為以太幣之最小單位面額。
+「gwei」這個字是「giga-wei」的縮寫,意思是「10 億 wei」。 1 gwei 等於 10 億 wei。 Wei 本身(以 [b-money](https://www.investopedia.com/terms/b/bmoney.asp) 創始人 [戴維](https://wikipedia.org/wiki/Wei_Dai) 的名字命名)是 ETH 的最小單位。
## 燃料費是如何計算的? {#how-are-gas-fees-calculated}
提交交易時,可以設定你願意支付的燃料費數量。 藉由提供一定數量的燃料費,你實際上是在出價,以便將你的交易加入下一個區塊。 如果你的報價過低,驗證者就不太可能選擇將你的交易加入下一個區塊,代表你的交易可能會延遲或根本不會被執行。 如果你報價過高,則可能會浪費一些以太幣。 那麼,該如何判定支付多少費用呢?
-支付的燃料費分成兩個部分:`base fee` 及 `priority fee`(小費)。
+您支付的總燃料費分為兩個部分:`基本費用` 和 `優先費用` (小費)。
-`base fee` 是由協議設定的 - 你必須支付至少這個數量的以太幣,你的交易才會被視為有效。 `priority fee` 是你在基本費用上增加的額外小費,使你的交易對驗證者來說更有吸引力,以便讓他們選擇將其添加到下一個區塊中。
+`基本費用` 由協議設定——您必須至少支付此金額,您的交易才算有效。 `優先費用` 是您加在基本費用上的小費,用來吸引驗證程式,讓他們選擇將您的交易納入下一個區塊。
-只支付 `base fee` 的交易在技術層面上是有效的,但不太可能加入下一個區塊中,因為此類交易未向驗證者提供任何激勵,因此驗證者不會選擇它而不管任何其他交易。 「適宜」的 `priority` 費依據發送交易時的網路使用情況而定 - 若當時需求非常高,你需要將你的 `priority` 費設高點,而需求低時則可以付少點。
+僅支付 `基本費用` 的交易在技術上有效,但不太可能被納入,因為它沒有提供任何誘因讓驗證程式優先選擇它,而不是其他任何交易。 「正確的」`優先`費用取決於您傳送交易時的網路使用情況——如果需求量大,您可能需要設定較高的 `優先`費用,但當需求較少時,您可以支付較少的費用。
舉例來說,假設 Jordan 要付給 Taylor 1 以太幣。 以太幣轉帳需要 21,000 單位的燃料,而基本費用為 10 gwei。 Jordan 支付 2 gwei 小費。
現在總燃料費為:
-`使用的單位燃料 * (基本費用 + 優先費)`
+`已使用的燃料單位 * (基本費用 + 優先費用)`
-其中,`base fee` 的值由協議設定,而 `priority fee` 的值則是由使用者設置,是給驗證者的小費。
+其中,`基本費用` 的值由協議設定,而 `優先費用` 的值則是由使用者設置,是給驗證程式的小費。
-範例:`21,000 * (10 + 2) = 252,000 gwei` (0.000252 以太幣)。
+例如 `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH)。
-當 Jordan 發送該金額時,1.000252 以太幣將從 Jordan 的帳戶中扣除。 而 Taylor 將獲得 1.0000 以太幣。 驗證者將收到 0.000042 以太幣的小費。 0.00021 以太幣的 `base fee` 被銷毀。
+當 Jordan 發送該金額時,1.000252 以太幣將從 Jordan 的帳戶中扣除。 而 Taylor 將獲得 1.0000 以太幣。 驗證者將收到 0.000042 以太幣的小費。 0.00021 ETH 的 `基本費用` 被銷毀。
### 基本費用 {#base-fee}
-每個區塊都有基本費用作為底價。 為了達成添加至區塊中的條件,提供的每單位燃料價格必須至少等於基本費用。 基本費用的計算與當前區塊無關,而是由當前區塊前面的區塊決定,讓交易費用對於使用者更具可預測性。 建立區塊時,此**基本費用被「銷毀」**,從流通中移除。
+每個區塊都有基本費用作為底價。 為了達成添加至區塊中的條件,提供的每單位燃料價格必須至少等於基本費用。 基本費用的計算與當前區塊無關,而是由其之前的區塊決定,讓使用者的交易費用更具可預測性。 建立區塊時,此**基本費用會被\"銷毀\"**,從流通中移除。
-此基本費用透過一個公式計算,該公式比較前一個區塊的大小(所有交易使用的燃料用量)與目標區塊大小。 如果超出目標區塊大小,每個區塊的基本費用將最大增加 12.5%。 這種指數級增長讓區塊大小無限增加在經濟上不可行。
+基本費用是根據一個公式計算出來的,該公式將前一個區塊的大小 (所有交易使用的燃料量) 與目標大小 (燃料限制的一半) 進行比較。 如果目標區塊大小分別高於或低於目標,每個區塊的基本費用最多將增加或減少 12.5%。 這種指數級增長讓區塊大小無限增加在經濟上不可行。
-| 區塊編號 | 包含燃料 | 費用增幅 | 當前基本費用 |
-| ---- | ----:| -----:| ----------:|
-| 1 | 15M | 0% | 100 gwei |
-| 2 | 30M | 0% | 100 gwei |
-| 3 | 30M | 12.5% | 112.5 gwei |
-| 4 | 30M | 12.5% | 126.6 gwei |
-| 5 | 30M | 12.5% | 142.4 gwei |
-| 6 | 30M | 12.5% | 160.2 gwei |
-| 7 | 30M | 12.5% | 180.2 gwei |
-| 8 | 30M | 12.5% | 202.7 gwei |
+| 區塊編號 | 包含燃料 | 費用增幅 | 當前基本費用 |
+| ---- | ---: | --------------------: | -------------------------: |
+| 1 | 18M | 0% | 100 gwei |
+| 2 | 36M | 0% | 100 gwei |
+| 3 | 36M | 12.5% | 112.5 gwei |
+| 4 | 36M | 12.5% | 126.6 gwei |
+| 5 | 36M | 12.5% | 142.4 gwei |
+| 6 | 36M | 12.5% | 160.2 gwei |
+| 7 | 36M | 12.5% | 180.2 gwei |
+| 8 | 36M | 12.5% | 202.7 gwei |
-依據上表 -- 要在 9 號區塊中建立一筆交易,錢包會讓使用者明確知道將交易添加到下一個區塊中的**最大基本費用**為 `current base fee * 112.5%` 或 `202.7 gwei * 112.5% = 228.1 gwei`。
+上表中,以 3600 萬作為燃料限制為例進行了示範。 以上表為例,若要在第 9 號區塊建立交易,錢包會讓使用者明確知道,要新增至下一個區塊的**最高基本費用**為 `目前的基本費用 * 112.5%` 或 `202.7 gwei * 112.5% = 228.1 gwei`。
值得注意的是,因為基本費用在區塊變滿之前增加的速度很快,我們不太可能看到大量已滿區塊連續出現。
-| 區塊編碼 | 包含Gas費 | 增加費用 | 目前基本費用 |
-| ---- | ------:| -----:| ---------------:|
-| 30 | 30M | 12.5% | 2705.6 gwei |
-| ... | ... | 12.5% | ... |
-| 50 | 30M | 12.5% | 28531.3 gwei |
-| ... | ... | 12.5% | ... |
-| 100 | 30M | 12.5% | 10302608.6 gwei |
+| 區塊編號 | 包含燃料 | 費用增幅 | 當前基本費用 |
+| --------------------------------------------------- | --------------------------------------------------: | --------------------: | --------------------------------------------------: |
+| 30 | 36M | 12.5% | 2705.6 gwei |
+| ... | ... | 12.5% | ... |
+| 50 | 36M | 12.5% | 28531.3 gwei |
+| ... | ... | 12.5% | ... |
+| 100 | 36M | 12.5% | 10302608.6 gwei |
-### 優先費(小費) {#priority-fee}
+### 優先費用 (小費) {#priority-fee}
-優先費(小費)激勵驗證者將交易添加進區塊中。 如果沒有小費,驗證者會發現開採空區塊在經濟上可行,因為他們收到的區塊獎勵相同。 少量的小費提供的激勵極弱,不足以讓驗證者將交易打包進區塊。 為了使交易比相同區塊中的其他交易優先執行,可以提供較高的小費,以超出其他競爭交易的報價。
+優先費用 (小費) 旨在激勵驗證程式在區塊燃料限制的範圍內,盡可能將區塊內的交易數量最大化。 若沒有小費,理性的驗證程式可能會納入較少,甚至是零筆交易,且不會受到執行層或共識層的直接懲罰,因為質押獎勵與區塊中的交易數量無關。 此外,小費讓使用者能以更高價格在同一個區塊中取得優先處理權,有效地表達交易的急迫性。
-### 最大費用 {#maxfee}
+### 最高費用 {#maxfee}
-要在網路上執行交易,使用者可以指定為了執行其交易他們願意支付的最大費用限制。 此可選參數亦稱為 `maxFeePerGas`。 執行交易所需的最大費用必須超過基本費用與小費的總和。 會向交易發送者退還最大費用與基本費用和小費之總合之間的差額。
+要在網路上執行交易,使用者可以指定為了執行其交易他們願意支付的最大費用限制。 此選用參數稱為 `maxFeePerGas`。 執行交易所需的最大費用必須超過基本費用與小費的總和。 會向交易發送者退還最大費用與基本費用和小費之總合之間的差額。
### 區塊大小 {#block-size}
-每個區塊具 15M 單位燃料用量之目標大小,但區塊大小將跟隨網路需求增減,最大可達到 60M 燃料用量的區塊大小限制(目標區塊大小之兩倍)。 協議往往透過 _tâtonnement_ 流程達成 30M 的均衡區塊大小。 這意味著,如果區塊大小大於目標區塊大小,協議將增加下一個區塊的基本費用。 同樣,如果區塊大小小於目標區塊大小,協議將減少基本費用。 基本費用的調節額度與實際區塊大小與目標區塊大小之間的差異成比例。 [更多區塊相關資訊](/developers/docs/blocks/)。
+每個區塊的目標大小是目前燃料限制的一半,但區塊大小會根據網路需求增減,直到達到區塊上限 (目標區塊大小的 2 倍)。 協議透過 _tâtonnement_ (試探) 過程,使平均區塊大小達到目標值的均衡狀態。 這意味著,如果區塊大小大於目標區塊大小,協議將增加下一個區塊的基本費用。 同樣,如果區塊大小小於目標區塊大小,協議將減少基本費用。
-### 實際計算燃料費 {#calculating-fees-in-practice}
+基本費用的調節額度與實際區塊大小與目標區塊大小之間的差異成比例。 這是線性計算:空區塊為 -12.5%,達到目標大小時為 0%,達到燃料限制時最高為 +12.5%。 燃料限制會根據驗證程式的信號以及網路升級而隨時間波動。 您可以在[此處查看燃料限制隨時間的變化](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths)。
+
+[更多關於區塊的資訊](/developers/docs/blocks/)
+
+### 實務上如何計算燃料費用 {#calculating-fees-in-practice}
可明確聲明願意支付多少費用,以讓驗證者執行你的交易。 然而,大多數錢包提供商會自動設定推薦的交易費(基本費用 + 推薦的優先費),以降低使用者面臨的複雜度。
@@ -98,43 +103,49 @@ lang: zh-tw
簡言之,燃料費可幫助保障以太坊網路安全。 透過要求為網路上執行的每次計算支付費用,可以阻止惡意行為者利用垃圾郵件攻擊網路。 為避免程式碼中出現意外或是惡意的無限迴圈或其他計算浪費,對於每筆交易,都必須設定一個關於可以使用程式碼執行中多少個計算步驟的限制。 計算的基本單位為「燃料」。
-雖然交易包括限制,但任何在交易中未使用的燃料將會退還給使用者(即退還 `max fee - (base fee + tip)`)。
+雖然交易設有上限,但交易中任何未使用的燃料都會退還給使用者 (例如,退還的金額為 `最高費用 - (基本費用 + 小費)`)。
- _此圖表源於[以太坊的以太坊虛擬機圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [以太坊 EVM 圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## 什麼是燃料限制? {#what-is-gas-limit}
-燃料限制指的是你在一筆交易中最多願意使用多少燃料。 包含[智慧型合約](/developers/docs/smart-contracts/)的更複雜的交易需要進行更多計算工作,所以比起簡單的支付,它們需要更高的燃料限制。 標準以太幣轉帳需要的燃料限制為 21,000 單位燃料。
+燃料限制指的是你在一筆交易中最多願意使用多少燃料。 涉及 [智能合約](/developers/docs/smart-contracts/) 的更複雜交易需要更多計算工作,因此需要的燃料限制比簡單的支付更高。 標準以太幣轉帳需要的燃料限制為 21,000 單位燃料。
-例如,如果為一次簡單的以太幣轉帳設定了 50,000 的燃料限制,以太坊虛擬機將消耗 21,000 單位燃料並退還剩餘的 29,000。 然而,如果你設定的燃料過低,例如為簡單的以太幣轉帳設定 20,000 的燃料限制,以太坊虛擬機將用盡 20,000 燃料單位嘗試完成交易,但最終交易會失敗。 隨後,以太坊虛擬機會還原全部變更,但因為驗證者已完成了相當於 20k 燃料單位的工作,所以會消耗這些燃料。
+例如,如果為一次簡單的以太幣轉帳設定了 50,000 的燃料限制,以太坊虛擬機將消耗 21,000 單位燃料並退還剩餘的 29,000。 然而,如果你指定的 gas 過少,例如,對於一筆簡單的 ETH 轉移,gas 限制設置爲 20,000,那麽交易將在驗證階段失敗。 它會在被包含在區塊之前被拒絕,并且不會消耗任何 gas。 另一方面,如果交易在執行過程中耗盡了 gas(例如,智能合約在執行過程中耗盡了所有 gas),以太坊虛擬機將回滾所有更改,但已提供的 gas 仍將用於已完成的工作。
## 為何燃料費這麼高? {#why-can-gas-fees-get-so-high}
燃料費高是因為以太坊人氣高。 如果需求過高,使用者必須支付更高的小費,以便超出其他使用者的交易報價。 小費越高,你的交易添加到下一個區塊中的可能性越大。 另外,越複雜的智慧型合約應用程式可能會執行大量操作,以支援其函式,這會消耗許多燃料。
-## 燃料費用削減倡議 {#initiatives-to-reduce-gas-costs}
+## 降低燃料成本的措施 {#initiatives-to-reduce-gas-costs}
+
+以太坊的[可擴展性升級](/roadmap/) 最終應能解決一些燃料費用問題,從而使該平台能夠每秒處理數千筆交易並在全球範圍內擴展。
-以太坊的[可擴容性](/roadmap/)應最終解決一部分燃料費用問題,繼而讓該平台能夠每秒處理數千筆交易並實現全域擴容。
+二層網路擴容為一項主要倡議,可大幅減低燃料費用並加強用戶體驗及可擴容性。
-二層網路擴容為一項主要倡議,可大幅減低燃料費用並加強用戶體驗及可擴容性。 [更多二層網路擴容相關資訊](/developers/docs/scaling/#layer-2-scaling)。
+[更多關於 Layer 2 擴展的資訊](/developers/docs/scaling/#layer-2-scaling)
-## 監控燃料費 {#monitoring-gas-fees}
+## 監控燃料費用 {#monitoring-gas-fees}
若你想要監控燃料價格,以便能以更低的費用發送以太幣,你可以使用許多不同的工具,例如:
-- [Etherscan](https://etherscan.io/gastracker) _交易燃料費價格估算器_
-- [以太幣燃料追蹤器](https://www.ethgastracker.com/)_監控並追蹤以太坊和二層網路的燃料價格,以降低交易費用並節省資金_
-- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _燃料估算 Chrome 延伸模組,支援 0 類原始交易及 2 類 EIP-1559 交易。_
-- [Cryptoneur燃料Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _在主網、Arbitrum、Polygon 上使用當地貨幣計算不同交易類型的燃料費。_
+- [Etherscan](https://etherscan.io/gastracker) _交易燃料價格估算器_
+- [Blockscout](https://eth.blockscout.com/gas-tracker) _開源交易燃料價格估算器_
+- [ETH Gas Tracker](https://www.ethgastracker.com/) _監控和追蹤以太坊和 L2 的燃料價格,以降低交易費用並節省資金_
+- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _支援類型 0 傳統交易和類型 2 EIP-1559 交易的燃料估算 Chrome 擴充功能。_
+- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _在主網、Arbitrum 和 Polygon 上,為不同交易類型以您的當地貨幣計算燃料費用。_
## 相關工具 {#related-tools}
-- [Blocknative's Gas Platform](https://www.blocknative.com/gas)_ 由 Blocknative 的全域記憶體池資料平臺支援的燃料估算應用程式介面平台_
+- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _由 Blocknative 的全球記憶體池資料平台提供支援的燃料估算 API_
+- [Gas Network](https://gas.network) 鏈上燃料預言機。 支援超過 35 條鏈。
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊燃料詳解](https://defiprime.com/gas)
-- [減低智慧型合約之燃料消耗](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
-- [開發者的燃料優化策略](https://www.alchemy.com/overviews/solidity-gas-optimization)
-- [EIP-1559 文檔](https://eips.ethereum.org/EIPS/eip-1559)。
-- [Tim Beiko 的 EIP-1559 資源](https://hackmd.io/@timbeiko/1559-resources)。
+- [以太坊燃料說明](https://defiprime.com/gas)
+- [降低您智能合約的燃料消耗](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
+- [開發人員的燃料最佳化策略](https://www.alchemy.com/overviews/solidity-gas-optimization)
+- [EIP-1559 文件](https://eips.ethereum.org/EIPS/eip-1559)。
+- [Tim Beiko 的 EIP-1559 資源](https://hackmd.io/@timbeiko/1559-resources)
+- [EIP-1559:將機制與迷因區分開來](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes)
diff --git a/public/content/translations/zh-tw/developers/docs/ides/index.md b/public/content/translations/zh-tw/developers/docs/ides/index.md
index f5c0d085180..09e8b305a64 100644
--- a/public/content/translations/zh-tw/developers/docs/ides/index.md
+++ b/public/content/translations/zh-tw/developers/docs/ides/index.md
@@ -1,64 +1,64 @@
---
-title: 整合開發環境
-description:
+title: 整合開發環境 (IDE)
+description: 了解關於以太坊開發的網頁及桌面版 IDE,包括 Remix、VS Code 及其他受歡迎的插件。
lang: zh-tw
---
-在設定[整合開發環境 (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) 時,以太坊上的應用程式程式設計與任何其他軟體專案的程式設計類似。 有很多選項可供選擇,因此最終請選擇最適合你喜好設定的整合開發環境或程式碼編輯器。 最適合你以太坊開發的整合開發環境選項很可能是你已經用於傳統軟體開發的整合開發環境。
+在設定 [整合開發環境 (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) 時,以太坊上的應用程式設計與任何其他軟體專案的設計類似。 有很多選項可供選擇,因此最終請選擇最適合你喜好設定的整合開發環境或程式碼編輯器。 最適合你以太坊開發的整合開發環境選項很可能是你已經用於傳統軟體開發的整合開發環境。
-## 網頁型整合開發環境 {#web-based-ides}
+## 網頁版 IDE {#web-based-ides}
-如果你想在[設定本地開發環境](/developers/local-environment/)之前試一下程式碼,以下網頁應用程式是為以太坊智慧型合約開發客製化構建的。
+如果你想在 [設定本機開發環境](/developers/local-environment/) 之前,先試著修改程式碼,這些網路應用程式是專為以太坊智慧型合約開發而打造的。
-**[Remix](https://remix.ethereum.org/)** - **_網頁型整合開發環境,內建靜態分析與區塊鏈測試虛擬機_**
+**[Remix](https://remix.ethereum.org/)** - **_網頁版 IDE,內建靜態分析和測試用區塊鏈虛擬機_**
- [文件](https://remix-ide.readthedocs.io/en/latest/#)
- [Gitter](https://gitter.im/ethereum/remix)
-**[ChainIDE](https://chainide.com/)** - **_一個支援多鏈的雲端整合開發環境_**
+**[ChainIDE](https://chainide.com/)** - **_一個雲端多鏈 IDE_**
- [文件](https://chainide.gitbook.io/chainide-english-1/)
- [幫助論壇](https://forum.chainide.com/)
-**[Replit(Solidity 新手教學 - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_一個可自訂的以太坊開發環境,提供熱重載、錯誤檢查和一流的測試網支援_**
+**[Replit (Solidity 入門 - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_一個可自訂的以太坊開發環境,具備熱重載、錯誤檢查和頂級的測試網支援_**
- [文件](https://docs.replit.com/)
-**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_一個快速的原型建置環境,讓你可以使用 Solidity 和 JavaScript 在瀏覽器中編寫、執行智慧型合約並對其偵錯_**
+**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_一個快速的原型設計環境,您可以在瀏覽器中使用 Solidity 和 JavaScript 編寫、執行和偵錯智慧型合約_**
-**[EthFiddle](https://ethfiddle.com/)** - **_網頁型整合開發環境 (IDE),可讓你編寫、編譯智慧型合約並對其偵錯_**
+**[EthFiddle](https://ethfiddle.com/)** - **_網頁版 IDE,可讓您編寫、編譯和偵錯您的智慧型合約_**
- [Gitter](https://gitter.im/loomnetwork/ethfiddle)
-## 桌上型整合開發環境 {#desktop-ides}
+## 桌面版 IDE {#desktop-ides}
-大多數成熟的整合開發環境都內建了外掛程式來增強以太坊開發體驗。 這些整合開發環境至少為[智慧型合約語言](/developers/docs/smart-contracts/languages/)提供語法醒目提示。
+大多數成熟的整合開發環境都內建了外掛程式來增強以太坊開發體驗。 最起碼,它們會為 [智慧型合約語言](/developers/docs/smart-contracts/languages/) 提供語法高亮功能。
-**Visual Studio Code -** **_專業跨平台整合開發環境,獲以太坊官方支援_**
+**Visual Studio Code -** **_具備以太坊官方支援的專業跨平台 IDE_**
- [Visual Studio Code](https://code.visualstudio.com/)
- [程式碼範例](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md)
- [GitHub](https://github.com/microsoft/vscode)
-**JetBrains 整合開發環境(IntelliJ IDEA 等) -****_軟體開發者和團隊的必備工具_**
+**JetBrains IDEs (IntelliJ IDEA, 等.) -** **_軟體開發人員與團隊的必備工具_**
- [JetBrains](https://www.jetbrains.com/)
- [GitHub](https://github.com/JetBrains)
- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/)
-**Remix Desktop -****_在本地機器上體驗 Remix 整合開發環境_**
+**Remix Desktop -** **_在您的本機電腦上體驗 Remix IDE_**
- [下載](https://github.com/ethereum/remix-desktop/releases)
- [GitHub](https://github.com/ethereum/remix-desktop)
-## 外掛程式和擴充功能 {#plugins-extensions}
+## 外掛程式與擴充功能 {#plugins-extensions}
-- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - 支援 Visual Studio Code 的以太坊 Solidity 語言
-- [支援 VS Code 的 Solidity + Hardhat](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Hardhat 團隊提供 Solidity 和 Hardhat 支援
-- [Prettier Soliditty](https://github.com/prettier-solidity/prettier-plugin-solidity) - 使用 prettier 的程式碼格式器
+- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - 適用於 Visual Studio Code 的 Ethereum Solidity 語言
+- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - 由 Hardhat 團隊提供的 Solidity 與 Hardhat 支援
+- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - 使用 prettier 的程式碼格式化工具
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊整合開發環境](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _ - Alchemy 提供的以太坊整合開發環境清單_
+- [以太坊 IDE](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- Alchemy 的以太坊 IDE 清單_
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/index.md b/public/content/translations/zh-tw/developers/docs/index.md
index eca812e3bc0..5174e02eea0 100644
--- a/public/content/translations/zh-tw/developers/docs/index.md
+++ b/public/content/translations/zh-tw/developers/docs/index.md
@@ -6,9 +6,9 @@ lang: zh-tw
本文檔旨在幫助你透過以太坊建置。 它介紹以太坊概念,解釋以太坊技術堆疊,並記錄關於更加複雜的應用程式及用例的高階主題。
-此為開源社群的一項工作,歡迎在你認為有所幫助時提出新主題、增添新內容並提供範例。 所有文檔均可透過 GitHub 進行編輯 – 如果你不確定如何操作,[請遵循相關說明](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md)。
+此為開源社群的一項工作,歡迎在你認為有所幫助時提出新主題、增添新內容並提供範例。 所有文件都可以透過 GitHub 編輯 – 如果您不確定如何操作,[請依照這些說明操作](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md)。
-## 發展模組 {#development-modules}
+## 開發模組 {#development-modules}
若這是你初次嘗試進行以太坊開發,我們建議你從頭開始並進行全面學習。
@@ -16,7 +16,7 @@ lang: zh-tw
-### 以太坊權益質押 {#ethereum-stack}
+### 以太坊技術堆棧 {#ethereum-stack}
diff --git a/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md b/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md
index e876b2c5fa9..f795a091dbb 100644
--- a/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md
+++ b/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md
@@ -1,12 +1,12 @@
---
-title: 以太幣簡介
+title: 以太幣的技術性介紹
description: 開發者為你介紹以太幣加密貨幣
lang: zh-tw
---
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了讓你更容易理解本頁,建議你先通讀我們的[以太坊介紹](/developers/docs/intro-to-ethereum/)。
+為協助您更瞭解本頁面,建議您先閱讀 [以太坊簡介](/developers/docs/intro-to-ethereum/)。
## 什麼是加密貨幣? {#what-is-a-cryptocurrency}
@@ -16,17 +16,17 @@ lang: zh-tw
第一種加密貨幣為比特幣,由中本聰創建。 自從比特幣 2009 問世以來,人們已經在多個不同區塊鏈上開發了數千種加密貨幣。
-## 甚麼是以太(ETH)? {#what-is-ether}
+## 甚麼是以太(以太幣)? {#what-is-ether}
-**以太幣 (ETH)** 為一種加密貨幣,在以太坊網路上有諸多用途。 基本上,它是唯一可被接受的交易費支付形式,且在[合併](/roadmap/merge)之後,在主網上驗證和提出區塊會需要以太幣。 以太幣還可以作為[去中心化金融](/defi)借貸市場中的主要抵押物,非同質化代幣市場上的計帳單位,或作為提供服務或銷售真正的商品而獲得的付款,還有更多用途。
+**以太幣 (ETH)** 是以太坊網路上用於許多用途的加密貨幣。 基本上,它是唯一可接受的交易費用支付形式,而且在[合併](/roadmap/merge)之後,在主網上驗證和提出區塊都需要以太幣。 以太幣也用作 [DeFi](/defi) 借貸市場的主要抵押品、NFT 市場的記帳單位、執行服務或銷售實體商品賺取的報酬等等。
-透過以太坊,開發者可以建立[**去中心化應用程式 (dapp)**](/developers/docs/dapps),而所有去中心化應用程式都共用同一算力池。 此共享算力池是有限的,因此以太坊需要一種機制來決定由誰使用它。 不然,某個去中心化應用程式可能會意外或惡意佔用全部網路資源,令其他人無法使用。
+以太坊讓開發者可以建立 [**去中心化應用程式 (dapps)**](/developers/docs/dapps),它們都共享一個算力池。 此共享算力池是有限的,因此以太坊需要一種機制來決定由誰使用它。 不然,某個去中心化應用程式可能會意外或惡意佔用全部網路資源,令其他人無法使用。
-以太幣加密貨幣支援以太坊算力的定價機制。 當使用者想進行交易時,他們必須支付以太幣,使其交易在區塊鏈上獲得認可。 此等使用成本亦稱為[燃料費](/developers/docs/gas/),而燃料費取決於執行交易所需的算力及當時整個網路對於算力的需求。
+以太幣加密貨幣支援以太坊算力的定價機制。 當使用者想進行交易時,他們必須支付以太幣,使其交易在區塊鏈上獲得認可。 這些使用成本稱為 [gas 費用](/developers/docs/gas/),而 gas 費用取決於執行交易所需的算力,以及當時全網路對算力的需求。
因此,即使惡意去中心化應用程式提交一個無窮迴圈,交易將最終會用盡以太幣並終止,讓網路能回復正常。
-人們[經常將以太坊與以太幣混為一談](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) — 當提到「以太坊的價格」時,他們指的是以太幣的市價。
+人們[通常會將](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845)以太坊和以太幣混淆 — 當人們提到「以太坊的價格」時,他們指的是以太幣的價格。
## 鑄造以太幣 {#minting-ether}
@@ -38,15 +38,15 @@ lang: zh-tw
如同區塊獎勵過程中會創建新的以太幣一樣,以太幣也可以透過稱為「燃燒」的流程銷毀。 以太幣銷毀後,將從流通中永久移除。
-以太坊上的每筆交易中都有以太幣銷毀。 當使用者為交易支付費用時,透過網路設定的基本燃料費用會根據交易需求銷毀。 它與不同的區塊大小以及最大燃料費用結合起來,簡化了以太坊上的交易費的估算。 當網路需求較高時,[區塊](https://etherscan.io/block/12965263)可以銷毀的以太幣數量比鑄造數量更大,有效抵銷以太幣的發行。
+以太坊上的每筆交易中都有以太幣銷毀。 當使用者為交易支付費用時,透過網路設定的基本燃料費用會根據交易需求銷毀。 它與不同的區塊大小以及最大燃料費用結合起來,簡化了以太坊上的交易費的估算。 當網路需求高時,[區塊](https://eth.blockscout.com/block/22580057)可以銷毀比鑄造的數量更多的以太幣,有效地抵銷了以太幣的發行。
-銷毀基本費用會束縛區塊產生者操縱交易的能力。 舉例來說,若區塊產生者收到基本費用,他們可以免費添加自己的交易,並提高其他人的基本費用。 或者,他們可以在鏈外將基本費用退還給某些使用者,造成交易費市場更加不透明且複雜。
+銷毀基本費用會阻礙區塊生產者操縱交易的能力。 舉例來說,若區塊產生者收到基本費用,他們可以免費添加自己的交易,並提高其他人的基本費用。 或者,他們可以在鏈下將基本費用退還給某些使用者,造成交易費市場更加不透明且複雜。
-## 以太幣面額 {#denominations}
+## 以太幣的面額 {#denominations}
由於以太坊上許多交易的價值很小,以太幣也就有了各種不同的面額,可做為較小的記帳單位。 其中,Wei 和 gwei 尤為重要。
-Wei 為以太幣的最小面額,因而,許多技術實作,例如[以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)等將在所有計算中以 Wei 為單位。
+Wei 是以太幣的最小單位,因此許多技術實作,例如 [以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf),會以 Wei 為單位進行所有計算。
Gwei 是 giga-wei 的簡稱,常用來描述以太坊上的燃料費用。
@@ -55,24 +55,24 @@ Gwei 是 giga-wei 的簡稱,常用來描述以太坊上的燃料費用。
| Wei | 10-18 | 技術實作 |
| Gwei | 10-9 | 人類可讀燃料費 |
-## 傳送以太幣 {#transferring-ether}
+## 轉移以太幣 {#transferring-ether}
-以太坊上的每筆交易都有一個 `value` 欄位,指定要從發送者地址傳送到接收者地址的以太幣數量,面額為 wei。
+以太坊上的每筆交易都包含一個 `value` 欄位,此欄位指定要從寄件人地址傳送到收款人地址的以太幣數量,並以 wei 為單位。
-當接收者地址為[智慧型合約](/developers/docs/smart-contracts/)時,在智慧型合約執行其程式碼後,傳送之以太幣可用於支付燃料費用。
+當收款人地址是 [智能合約](/developers/docs/smart-contracts/) 時,這筆轉移的以太幣可用於在智能合約執行其程式碼時支付 gas 費用。
-[更多交易相關資訊](/developers/docs/transactions/)
+[更多關於交易的資訊](/developers/docs/transactions/)
## 查詢以太幣 {#querying-ether}
-使用者能透過檢視帳戶的 `balance` 欄位來查詢任何[帳戶](/developers/docs/accounts/)的以太幣餘額,該欄位顯示面額為 wei 的以太幣持有量。
+使用者可以透過檢視帳戶的 `balance` 欄位來查詢任何[帳戶](/developers/docs/accounts/)的以太幣餘額,此欄位會顯示以 wei 為單位的以太幣持有量。
-[Etherscan](https://etherscan.io) 為一種人氣工具,可透過網路應用程式檢視地址餘額。 例如,[此 Etherscan 頁面](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae)顯示以太坊基金會的餘額。 也可使用錢包或者透過直接向節點發送請求查詢帳戶餘額。
+[Etherscan](https://etherscan.io) 和 [Blockscout](https://eth.blockscout.com) 是透過網頁應用程式檢視地址餘額的熱門工具。 例如,[這個 Blockscout 頁面](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) 顯示了以太坊基金會的餘額。 也可使用錢包或者透過直接向節點發送請求查詢帳戶餘額。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [定義以太幣與以太坊](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_
-- [以太坊白皮書](/whitepaper/):以太坊初始提案。 該文件包含對以太幣的描述及創建以太幣的動機。
-- [Gwei 計算機](https://www.alchemy.com/gwei-calculator):使用此 Gwei 計算機輕鬆轉換 wei、gwei 和以太幣。 只需輸入任意數量的 wei、gwei 或以太幣即可自動計算轉換後的數值。
+- [以太坊白皮書](/whitepaper/):以太坊的原始提案。 該文件包含對以太幣的描述及創建以太幣的動機。
+- [Gwei 計算機](https://www.alchemy.com/gwei-calculator):使用此 Gwei 計算機可輕鬆轉換 wei、gwei 和以太幣。 只需輸入任意數量的 wei、gwei 或以太幣即可自動計算轉換後的數值。
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md b/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md
index ba3941f4ab6..1d8e672d92f 100644
--- a/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md
+++ b/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md
@@ -1,5 +1,5 @@
---
-title: 以太坊簡介
+title: 以太坊的技術性介紹
description: 去中心化應用程式開發者介紹以太坊核心概念。
lang: zh-tw
---
@@ -14,15 +14,15 @@ lang: zh-tw
網路上的所有電腦必須對所有新區塊及整條區塊鏈達成一致。 此等電腦稱為「節點」。 節點確保與區塊鏈互動的每個人具相同資料。 為了達成這種分佈式共識,區塊鏈需要一共識機制。
-以太坊採用[權益證明共識機制](/developers/docs/consensus-mechanisms/pos/)。 任何想將新區塊添加至區塊鏈的人都必須質押以太幣(以太坊的原生貨幣)作為抵押品並運行驗證者軟體。 接著,這些「驗證者」會被隨機選取以提出區塊,區塊由其他驗證者檢查並添加到區塊鏈上。 以太坊有獎勵及懲罰制度,以激勵參與者保持誠實並儘可能持續上線。
+以太坊使用[權益證明共識機制](/developers/docs/consensus-mechanisms/pos/)。 任何想將新區塊添加至區塊鏈的人都必須質押以太幣(以太坊的原生貨幣)作為抵押品並運行驗證者軟體。 接著,這些「驗證者」會被隨機選取以提出區塊,區塊由其他驗證者檢查並添加到區塊鏈上。 以太坊有獎勵及懲罰制度,以激勵參與者保持誠實並儘可能持續上線。
-如果想瞭解區塊鏈資料是如何被雜湊後並附加到區塊參考的歷史記錄中,歡迎查看這個由 Anders Brownworth 製作的[示範](https://andersbrownworth.com/blockchain/blockchain),並觀看附上的影片。
+如果您想了解區塊鏈資料如何被哈希處理,並隨後附加到區塊參考歷史記錄中,請務必查看 Anders Brownworth 製作的[此示範](https://andersbrownworth.com/blockchain/blockchain),並觀看下面的附帶影片。
觀看 Anders 解釋區塊鏈中雜湊的影片:
-## 甚麼是以太坊(Ethereum)? {#what-is-ethereum}
+## 什麼是 Ethereum? {#what-is-ethereum}
以太坊是一條嵌入了電腦的區塊鏈。 它是以去中心化、無需許可、抗審查的方式建立應用程式和組織的基礎。
@@ -32,7 +32,7 @@ lang: zh-tw
加密機制確保一旦交易被驗證為有效並添加至區塊鏈上,以後就無法被篡改。 此相同機制也確保所有交易是透過相同的「權限」簽署並執行(除了 Alice 本人外,任何人都不應該能從她的帳戶發送數位資產)。
-## 什麼是以太幣? {#what-is-ether}
+## 甚麼是以太(以太幣)? {#what-is-ether}
**以太幣 (ETH)** 是以太坊的原生加密貨幣。 以太坊的作用是提供一個計算市場。 此類市場為參與者提供經濟獎勵,激勵其驗證並執行交易請求,並且向網路提供計算資源。
@@ -42,9 +42,9 @@ lang: zh-tw
以太幣也用來為網路提供加密經濟學安全性,主要有以下三種方式:1) 作為一種獎勵方式,獎勵提交區塊或檢舉其他驗證者不誠實行為的驗證者;2) 由驗證者質押,作為對抗不誠實行為的抵押品 - 如果驗證者嘗試從事不良行為,則它們的以太幣可能會被銷毀;3) 用來衡量新提交區塊的「投票」,並輸入共識機制的分叉選擇部分。
-## 什麼是智慧型合約? {#what-are-smart-contracts}
+## 什麼是智慧型合約? 什麼是智能合約? {#what-are-smart-contracts}
-實際上,參與者想請求在以太坊虛擬機上進行計算時,不用每次編寫新程式碼。 反之,應用程式開發者將程式(可重複使用的程式片段)上傳到以太坊虛擬機狀態中,使用者請求使用不同的參數來執行此類程式碼片段。 我們將此類上傳並執行的程式稱為網路智慧型合約。
+實際上,參與者想請求在以太坊虛擬機上進行計算時,不用每次編寫新程式碼。 反之,應用程式開發者將程式(可重複使用的程式片段)上傳到以太坊虛擬機狀態中,使用者請求使用不同的參數來執行此類程式碼片段。 我們將上傳至網路並由網路執行的程式稱為「智能合約」。
簡單來說,你可以想像智慧型合約為一臺自動販賣機:一個指令碼,在使用某些參數呼叫時,若滿足特定條件,該指令碼會執行一些操作或計算。 舉例來說,如果呼叫者將以太幣發送給特定接收者,一個簡易的販賣智慧型合約可能會建立和指定某件數位資產的所有權。
@@ -58,31 +58,31 @@ lang: zh-tw
以太坊網路之歷史記錄中提交至網路上的所有區塊的順序。 有此名稱的原因是,每個區塊都包含對前一個塊的引用,這有助於維護所有區塊(以及精確歷史記錄)的排序。
-### 以太幣 {#eth}
+### ETH {#eth}
-**以太 (ETH)**以太坊原生加密貨幣. 使用者向其他使用者支付以太幣,以完成他們的程式碼執行請求。
+**以太幣 (ETH)** 是以太坊的原生加密貨幣。 使用者向其他使用者支付以太幣,以完成他們的程式碼執行請求。
-[有關以太幣的更多資訊](/developers/docs/intro-to-ether/)
+[更多關於 ETH](/developers/docs/intro-to-ether/)
-### 以太坊虛擬機 {#evm}
+### EVM {#evm}
以太坊虛擬機為一臺全域虛擬電腦,所有以太坊網路參與者都儲存其狀態並達成共識。 任何參與者都能請求在以太坊虛擬機上執行任何程式碼;程式碼執行會改變以太坊虛擬機的狀態。
-[更多以太坊虛擬機相關資訊](/developers/docs/evm/)
+[更多關於 EVM](/developers/docs/evm/)
### 節點 {#nodes}
儲存以太坊虛擬機狀態的真實電腦。 節點互相通訊,以傳播關於以太坊虛擬機狀態及新出現狀態變化的資訊。 任何使用者還可以透過從節點廣播程式碼執行請求,請求執行程式碼。 以太坊網路本身為所有以太坊節點及其通信之彙總。
-[更多詳情關於節點](/developers/docs/nodes-and-clients/)
+[更多關於節點](/developers/docs/nodes-and-clients/)
### 帳戶 {#accounts}
以太幣儲存之處。 使用者可以初始化帳戶,將以太幣存入帳戶,並將其帳戶中的以太幣轉帳給其他使用者。 帳戶及帳戶餘額儲存於以太坊虛擬機中的一張龐大表格中;它們是以太坊虛擬機全部狀態的一部分。
-[更多帳戶相關資訊](/developers/docs/accounts/)
+[更多關於帳戶](/developers/docs/accounts/)
-### 交易紀錄 {#transactions}
+### 交易 {#transactions}
「交易請求」為表示以太坊虛擬機上程式碼執行請求的正式術語,而「交易」為已完成的交易請求及相關的以太坊虛擬機狀態變化。 任何使用者都能從節點向網路廣播交易請求。 為了讓交易請求影響達成共識的以太坊虛擬機狀態,必須由其他節點驗證、執行此交易請求並「將其提交至網路上」。 執行任何程式碼都會改變以太坊虛擬機的狀態;提交時,此狀態變化將廣播至網路上的所有節點。 以下為一些交易範例:
@@ -90,27 +90,35 @@ lang: zh-tw
- 將一些智慧型合約程式碼發佈至以太坊虛擬機狀態中。
- 使用 Y 參數來執行以太坊虛擬機中地址 X 處的智慧型合約的程式碼。
-[更多詳情關於交易記錄](/developers/docs/transactions/)
+[更多關於交易的資訊](/developers/docs/transactions/)
### 區塊 {#blocks}
交易量非常龐大,因此交易按批次或區塊「提交」。 區塊通常包含數十乃至數百筆交易。
-[更多區塊相關資訊](/developers/docs/blocks/)
+[更多關於區塊的資訊](/developers/docs/blocks/)
-### 智慧型合約 {#smart-contracts}
+### 智能合約 {#smart-contracts}
-一段可重複使用的程式碼片段(程式),由開發者發佈至以太坊虛擬機狀態中。 任何人都可以透過發出交易請求來請求執行智慧型合約的程式碼。 因為開發者能藉由發佈智慧型合約向以太坊虛擬機中編寫任意可執行應用程式(遊戲、市場、金融工具等),此類合約也經常稱為 [Dapp 或去中央化應用程式](/developers/docs/dapps/)。
+一段可重複使用的程式碼片段(程式),由開發者發佈至以太坊虛擬機狀態中。 任何人都可以透過發出交易請求來請求執行智慧型合約的程式碼。 因為開發者可以將任何可執行的應用程式(遊戲、市場、金融工具等)寫入 EVM 透過發布智能合約,這些應用程式通常也被稱為[去中心化應用程式](/developers/docs/dapps/)。
-[了解更多關於智慧型合約的資訊](/developers/docs/smart-contracts/)
+[更多關於智能合約](/developers/docs/smart-contracts/)
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [以太坊白皮書](/whitepaper/)
-- [以太坊到底是如何運作的?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_(**注意**:此資源仍有參考價值,但留意它是早於[以太網合併](/roadmap/merge)的文獻,因此引述的仍然是以太坊的工作量證明機制 - 以太坊實際上目前是由[權益證明](/developers/docs/consensus-mechanisms/pos)來保障安全)
+- [以太坊到底是如何運作的?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_(**注意**:此資源仍具價值,但請注意,它的內容早於[合併](/roadmap/merge),因此仍提及以太坊的工作量證明機制——以太坊現在實際上是使用[權益證明](/developers/docs/consensus-mechanisms/pos)來保護安全)
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+### 想透過視覺方式學習? {#visual-learner}
-## 相關教學影片 {#related-tutorials}
+本系列視頻對基本主題進行了深入探索:
-- [以太坊開發者指南,第一部分](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– 適合初學者的以太坊探索(使用 Python 和 web3.py)_
+
+
+[以太坊基礎知識播放清單](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ)
+
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
+
+## 相關教學 {#related-tutorials}
+
+- [開發者的以太坊指南,第一部分](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– 一份對初學者非常友善的指南,使用 Python 和 web3.py 探索以太坊_
diff --git a/public/content/translations/zh-tw/developers/docs/mev/index.md b/public/content/translations/zh-tw/developers/docs/mev/index.md
new file mode 100644
index 00000000000..aeb4a04fcdf
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/mev/index.md
@@ -0,0 +1,221 @@
+---
+title: 最大可提取價值 (MEV)
+description: 最大可提取價值 (MEV) 簡介
+lang: zh-tw
+---
+
+最大可提取價值 (MEV) 是指透過在區塊中新增和排除交易並更改區塊中的交易順序,可以從區塊生產中提取的超過標準區塊獎勵和燃料費用的最大值。
+
+## 最大可提取價值 {#maximal-extractable-value}
+
+最大可提取價值首次應用於 [工作量證明](/developers/docs/consensus-mechanisms/pow/) 的背景下,最初稱為「礦工可提取價值」。 此是因為於工作量證明, 礦工能選擇來交易之納入, 不納入, 及順序. 然而,自從透過 [The Merge](/roadmap/merge) 過渡至權益證明後,驗證者就一直負責這些角色,挖礦也不再是以太坊協定的一部分。 但價值提取方法仍然存在,因此現在使用的術語是「最大可提取價值」。
+
+## 先決條件 {#prerequisites}
+
+請確保您熟悉[交易](/developers/docs/transactions/)、[區塊](/developers/docs/blocks/)、[權益證明](/developers/docs/consensus-mechanisms/pos) 和 [Gas](/developers/docs/gas/) 熟悉[去中心化應用程式](/apps/)和 [DeFi](/defi/) 也會有所幫助。
+
+## MEV 提取 {#mev-extraction}
+
+理論上,最大可提取價值完全屬於驗證者,因為他們是唯一可以保證執行有利可圖的最大可提取價值機會的一方。 實際上,大部分最大可提取價值是由稱為「搜尋者」的獨立網路參與者提取的。 搜尋者在區塊鏈數據上運行複雜的演算法來檢測盈利的最大可提取價值的機會,並且有機器人自動將這些盈利交易提交到網路。
+
+無論如何,驗證者確實會獲得全部最大可提取價值金額的一部分,因為搜尋者願意支付高昂的燃料費用(這些費用將歸驗證者所有),以換取更高可能性將其有利可圖的交易納入一個區塊。 假設尋找者為完全經濟合理, Gas費此研究者願意來支付最大為100%之MEV利益(因為如果Gas費高於利益, 尋找者將會賠錢).
+
+因此,對於一些競爭激烈的 MEV 機會,例如 [DEX 套利](#mev-examples-dex-arbitrage),搜尋者可能需要將其 MEV 總收入的 90% 或更多作為 Gas 費用支付給驗證者,因為有太多人想進行同樣有利可圖的套利交易。 這是因為確保套利交易運作的唯一方法,是提交最高燃料費用的交易。
+
+### Gas 節省技巧 {#mev-extraction-gas-golfing}
+
+這種動態讓「燃料高爾夫」— 即能夠使用最少數量燃料的程式交易,成為一種競爭優勢。因為它允許搜尋者設定較高的燃料價格,同時保持總燃料費不變(因為燃料費 = 燃料價格 \* 燃料用量)。
+
+一些著名的 Gas 節省技巧包括:使用以一長串零開頭的地址 (例如:[0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)),因為它們佔用的儲存空間較少 (因此 Gas 也較少);以及在合約中保留少量的 [ERC-20](/developers/docs/standards/tokens/erc-20/) 代幣餘額,因為初始化一個儲存槽 (餘額為 0 的情況) 比更新一個儲存槽花費更多的 Gas。 尋找更多減少燃料使用的技巧,是搜尋者在積極研究的一個領域。
+
+### 通用搶先交易者 {#mev-extraction-generalized-frontrunners}
+
+一些尋找者不自行尋找MEV榨取機會, 反之, 其成為一般偷跑者. 一般偷跑者為機器帳戶來監控交易內存池來發現榨益可能交易. 偷跑者將拷貝潛力榨取目標之交易程式, 取代地址部分利用偷跑者帳戶, 並於當地環境測試來確保此交易確實能榨取利益. 如測試結果為確實有利益, 偷跑者將提交此更改後交易使用一更高Gas費, 並"偷跑"先前於原始交易並榨取原先尋找者的MEV利益.
+
+### Flashbots {#mev-extraction-flashbots}
+
+快閃機器是一個獨立專案,透過一項服務擴展執行用戶端,該服務允許搜尋者將最大可提取價值交易提交給驗證者,而無需將它們透露給公共記憶體池。 此避免交易被其他尋找者發現並偷跑.
+
+## MEV 範例 {#mev-examples}
+
+最大可提取價值以多種方式出現在區塊鏈上。
+
+### DEX 套利 {#mev-examples-dex-arbitrage}
+
+[去中心化交易所](/glossary/#dex) (DEX) 套利是最簡單且最知名的 MEV 機會。 因此,它也是競爭最激烈的。
+
+其運作如此: 如果兩個DEXes列表一同一代幣但於不同價格, 某人能購入此代幣於低價DEX並販售此於高價DEX於一單一交易. 因為區塊鏈某些機制, 此為近於無風險之套購機會.
+
+[這裡有一個](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4)獲利套利交易的範例,其中一名搜尋者利用 Uniswap 和 Sushiswap 上 ETH/DAI 交易對的不同定價,將 1,000 ETH 變成了 1,045 ETH。
+
+### 清算 {#mev-examples-liquidations}
+
+借貸協議之清算機制也是一有名MEV榨取機會.
+
+像 Maker 和 Aave 這樣的借貸協定要求使用者存入一些抵押品 (例如 ETH)。 這些存入的抵押品會被用來借貸給其他使用者。
+
+然後,使用者可以根據自己的需求向他人借入資產和代幣 (例如,如果你想在 MakerDAO 管理體系提案中投票,你可以借入 MKR),最高可達其存入抵押品的一定百分比。 例如,如果借款金額不超過 30%,則將 100 DAI 存入協議的使用者最多可以借入價值 30 DAI 的另一種資產。 該協議確定了確切的借貸能力百分比。
+
+隨著借款人抵押品的價值波動,他們的借款能力也會波動。 如果因市場波動,借入資產的價值超過其抵押品價值的 (比方說) 30% (同樣地,準確的百分比由協定確定),協定通常允許任何人清算抵押品,立即償還貸款人 (這類似於傳統金融中 [保證金追繳](https://www.investopedia.com/terms/m/margincall.asp) 的運作方式)。 如果被清算,借款人通常必須支付高額清算費,其中一些費用會支付給清算人 — 這就是最大可提取價值機會的來源。
+
+搜尋者競相以最快的速度解析區塊鏈資料,以判斷哪些借款人可以清算,並率先提交清算交易並自己收取清算費用。
+
+### 三明治交易 {#mev-examples-sandwich-trading}
+
+三明治攻擊為另一常見攻略於MEV榨取.
+
+來做一三明治攻擊, 一尋找者必須監控大筆DEX交易於交易內存池. 例如, 假設某人欲想換10,000 UNI至DAI於Uniswap. 這類大額交易會對 UNI/DAI 對產生重大影響,可能會顯著提高 UNI 相對於 DAI 的價格。
+
+搜尋者可以計算這筆大額交易對 UNI/DAI 交易對的大致價格影響,並在這筆大額交易 _之前_ 立即執行一筆最佳買單,低價買入 UNI,然後在這筆大額交易 _之後_ 立即執行一筆賣單,以大額訂單造成的更高價格賣出。
+
+然而,三明治攻擊的風險更高,因為它不是原子性的 (不像上面描述的 DEX 套利),而且容易受到 [沙門氏菌攻擊](https://github.com/Defi-Cartel/salmonella)。
+
+### NFT MEV {#mev-examples-nfts}
+
+MEV於NFT環境為一崛起市場, 但其也具有多重風險.
+
+然而, 因為NFT交易發生於同樣共享之以太坊區塊鏈上, 尋找者能利用類似技術來於NFT市場.
+
+例如, 如一人氣NFT舉辦一空投活動, 而尋找者想要一或一組特定NFT, 他們能程式編輯一交易來使他們能成為第一個來購入此一或一整組之NFT於單一交易內. 或者,如果一個 NFT [被錯誤地以低價上架](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent),搜尋者可以搶在其他購買者之前,以低價搶購。
+
+一個 NFT MEV 的著名例子是,一名搜尋者花費 700 萬美元,以地板價 [購買了](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs) 所有的 Cryptopunk。 一位區塊鏈研究員在 [Twitter 上解釋](https://twitter.com/IvanBogatyy/status/1422232184493121538)了買家如何與 MEV 供應商合作,對其購買行為保密。
+
+### 長尾效應 {#mev-examples-long-tail}
+
+DEX套購, 清算, 及三明治為知名MEV榨取機會, 且極為競爭所以新尋找者幾乎無法賺錢. 然而, 其有另一較不出名的"長尾攻擊"MEV機會(NFT MEV為一用例).
+
+新尋找者或許能利用長尾攻擊來賺取較多利益. Flashbot 的 [MEV 工作板](https://github.com/flashbots/mev-job-board)列出了一些新興機會。
+
+## MEV 的影響 {#effects-of-mev}
+
+最大可提取價值並不都是壞事 — 以太坊的最大可提取價值既有正面也有負面的影響。
+
+### 優點 {#effects-of-mev-the-good}
+
+許多Defi計畫依靠套購利益尋求者來維持幣池價格與實際市場價格. 例如, DEX套購確保用戶們能取得最佳, 最正確之價格為其代幣, 且借出協議依賴快速清算來確保借出者確實有被支付.
+
+無理性尋找者來時時刻刻尋求經濟性機會且利用此優勢, Defi協議或許無法成長至其今日地位.
+
+### 缺點 {#effects-of-mev-the-bad}
+
+於應用程式層面, 一些MEV如三明治攻擊, 時常導致極差用戶體驗. 用戶被夾三明治將面臨市價滑點及較差執行價格於其交易.
+
+於網路層面, 偷跑者及Gas費價格賭價時常導致網路堵塞及昂貴Gas費(當一或多方的偷跑者嘗試跑贏另一對手藉由提交更高額之Gas費賭價), 且無法使正常用戶來運行一般交易.
+
+除了在區塊 _內部_ 發生的事情之外,MEV 也可能在區塊 _之間_ 產生有害影響。 如果區塊中可用的最大可提取價值大幅超過標準區塊獎勵,驗證者可能會被激勵重組區塊並為自己捕獲最大可提取價值,從而導致區塊鏈重組和共識不穩。
+
+這種區塊鏈重組的可能性,先前已在 [比特幣區塊鏈上進行過探討](https://dl.acm.org/doi/10.1145/2976749.2978408)。 當比特幣的區塊獎勵多次砍半, 交易費將成為主要區塊獎勵, 而其將成為經濟性合理來使礦工來放棄下一區塊獎勵並重挖此區塊來賺取更多利益. 隨MEV增長, 相同憂慮將面臨於以太坊, 而直接威脅區塊鏈信賴度.
+
+## MEV 的現狀 {#state-of-mev}
+
+MEV榨取暴增於2021年初期, 而其導長時間之高額Gas費. 快閃機器的最大可提取價中繼的出現,降低了普通偷跑者的效力,並將礦工費價格拍賣帶到鏈下,降低了普通使用者的礦工費。
+
+雖然許多搜尋者仍然從最大可提取價值賺到很多錢,但隨著機會變得越來越廣為人知,越來越多的搜尋者爭奪相同的機會,驗證者將獲得越來越多的最大可提取價值總收入(因為如最初描述的相同類型的燃料拍賣也在快閃機器中發生,儘管是私下進行的,而驗證者將獲得由此產生的燃料收入)。 MEV並非專屬以太坊, 而當MEV環境越來越競爭, 許多尋找者已轉移戰場至BSC幣安智鏈, 而其具相同潛力之MEV機會與一較低競爭環境.
+
+另一方面,從工作量證明過渡到權益證明以及持續不斷使用卷軸來拓展以太坊,這些都以某種還不太清楚的方式改變著最大可提取價值的格局。 與工作量證明中的機率模型相比,提前得知有保證的區塊提議者會如何改變 MEV 提取的動態,以及當 [單一秘密領導人選舉](https://ethresear.ch/t/secret-non-single-leader-election/11789) 和 [分散式驗證者技術](/staking/dvt/) 實施後,這將會如何被打亂,目前尚不清楚。 同樣,當大多數使用者活動遷離以太坊並轉移至其二層網路卷軸和分片時,存在哪些最大可提取價值機會還有待觀察。
+
+## 以太坊權益證明 (PoS) 中的 MEV {#mev-in-ethereum-proof-of-stake}
+
+如前述,最大可提取價值對使用者綜合體驗和共識層安全性產生負面影響。 但以太坊向權益證明共識的過渡(稱為「合併」)也可能帶來與最大可提取價值有關的新風險:
+
+### 驗證者中心化 {#validator-centralization}
+
+在合併後的以太坊,驗證者(已存入 32 個以太幣作為保證金)就新增到信標鏈的區塊的有效性達成共識。 由於 32 ETH 對許多人來說可能遙不可及,[加入質押池](/staking/pools/) 可能是一個更可行的選擇。 然而,[獨立質押者](/staking/solo/) 的健康分佈是理想的,因為它減輕了驗證者的中心化問題並提高了以太坊的安全性。
+
+不過,最大可提取價值提取被認為能夠加速驗證者中心化。 部分原因在於,相較於過去的礦工,驗證者 [提議區塊的收入較少](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply),因此自 [合併](/roadmap/merge/) 以來,MEV 提取已極大地 [影響了驗證者的收入](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb)。
+
+更大的質押池可能會有更多的資源投資進行必要的最佳化,以抓住最大可提取價值機會。 這些池提取的 MEV 越多,它們就擁有越多的資源來提升其 MEV 提取能力 (並增加整體收入),這基本上創造了 [規模經濟](https://www.investopedia.com/terms/e/economiesofscale.asp#)。
+
+由於可支配的資源較少,單獨質押者可能無法從最大可提取價值機會中獲利。 這可能會增加獨立驗證者加入強大的質押池以提高收益的壓力,從而削弱以太坊的去中心化。
+
+### 許可制交易池 {#permissioned-mempools}
+
+爲了應對三明治攻擊和搶先交易攻擊,交易者可能會開始與驗證者進行鏈下交易以確保交易隱私。 交易者將潛在的最大可提取價值交易直接發送到驗證者而非公共内存池,驗證者將交易添加到該區塊中並於交易者分配利潤。
+
+“暗池” 是這種模式的升級版,是一種只供訪問的許可内存池,對願意支付特定費用的用戶開放。 該趨勢將弱化以太坊的無許可和去信任,並有可能將區塊鏈轉換爲一種有利於最高出價者的 “付費游玩” 機制。
+
+許可内存池還會增加先前部分描述的中心化風險。 運行多個驗證者的大型池可能會受益於為交易者和使用者提供交易隱私,增加其最大可提取價值收入。
+
+在合併後的以太坊中解決這些與最大可提取價值相關的問題,是一個核心研究領域。 迄今為止,為了減少在合併之後 MEV 對以太坊去中心化和安全性的負面影響,提出了兩種解決方案:[**提議者-建構者分離 (PBS)**](/roadmap/pbs/) 和 [**建構者 API**](https://github.com/ethereum/builder-specs)。
+
+### 提議者-建構者分離 {#proposer-builder-separation}
+
+在工作量證明和權益證明中,建構區塊的節點面向參與共識的其他節點提出區塊以將其新增到鏈中。 新區塊在另一位礦工在其上建立區塊(在工作量證明中)後,或從大多數驗證者那裡獲得認證(在權益證明中)後,成為規範鏈的一部分。
+
+區塊生產者和區塊提交者角色的結合造成了大多數先前描述的與最大可提取價值相關的問題。 例如,在 [時間盜賊攻擊](https://www.mev.wiki/attack-examples/time-bandit-attack) 中,共識節點有動機觸發鏈重組,以最大化 MEV 收益。
+
+[提議者-建構者分離](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) 旨在減輕 MEV 的影響,尤其是在共識層。 PBS 的主要特點是區塊生產者與區塊提交者的分離。 驗證者仍然負責提議區塊並對其投票,但是一類稱為 **區塊建構者** 的新型專業實體,將負責對交易進行排序和建構區塊。
+
+在 PBS 模式下,區塊構建者創建一個交易捆綁並出價將其納入信標鏈區塊中 (作爲 “執行有效負載”)。 被選中提出下一個區塊的驗證者隨後查看不同的出價,並選擇費用最高的交易包。 PBS 本質上創建了一個拍賣市場,使構建者和出售區塊空間的驗證者進行協調。
+
+目前的 PBS 設計採用 [承諾-揭示方案](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/),建構者只會發布對區塊內容 (區塊頭) 的密碼學承諾以及他們的出價。 在接受獲勝的出價后,提交者創建一個包括區塊頭的簽名區塊提案。 區塊建構者在看到已簽署的區塊提議後,應會發布完整的區塊主體,且在最終確認前,還必須從驗證者那裡收到足夠的 [證明](/glossary/#attestation)。
+
+#### 提議者-建構者分離如何減弱最大可提取價值的影響? {#how-does-pbs-curb-mev-impact}
+
+協議内的提交者-構建者分離將最大可提取價值從驗證者的權限中移除,降低了最大可提取價值對共識的影響。 相反,運行專用硬體的區塊建置者將抓住出現的最大可提取價值機會。
+
+不過,這並不完全將驗證者排除在最大可提取價值相關收入之外,因為建置者必須出高價才能讓驗證者接受他們的區塊。 盡管如此,由於驗證者不再直接專注於如何盡可能提高最大可提取價值收入,時間强盜攻擊的威脅得以降低。
+
+提出者-構建者分離也降低了最大可提取價值的中心化風險。 例如,使用提交-揭露方案,構建者就會信任驗證者不會竊取最大可提取價值機會或將其暴露給其他構建者。 這就低了單獨質押者從最大可提取價值獲益的門檻,否則建置者將傾向於支持有著鏈下聲譽的大型池並與它們進行鏈下交易。
+
+同樣地,驗證者不必信任建置者不會隱藏區塊體或發布無效區塊,因為付款是無條件的。 即使提出的區塊不可用或被其他驗證者宣稱無效,驗證者的費用仍然會支付。 在後一種情況下,區塊被直接丟棄,迫使區塊建置者失去所有交易費和最大可提取價值收入。
+
+### 建構者 API {#builder-api}
+
+儘管提交者-構建者分離有望減少最大可提取價值的影響,但實現它需要對共識協議進行更改。 具體來說,信標鏈上的 [分叉選擇](/developers/docs/consensus-mechanisms/pos/#fork-choice) 規則需要更新。 [建構者 API](https://github.com/ethereum/builder-specs) 是一個臨時解決方案,旨在提供一個可行的提議者-建構者分離實作,儘管它帶有更高的信任假設。
+
+建構者 API 是 [引擎 API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) 的修改版本,共識層用戶端用它來向執行層用戶端請求執行負載。 如 [誠實驗證者規範](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) 所述,被選中負責提議區塊的驗證者會向一個已連接的執行用戶端請求交易捆綁包,並將其包含在提議的信標鏈區塊中。
+
+建置者應用程式介面還充當驗證者和執行層用戶端之間的中介軟體;不同之處是它允許信標鏈上的驗證者從外部實體獲取區塊(而不是使用執行用戶端在本地構建區塊)。
+
+以下簡述建置者應用程式介面如何運作:
+
+1. 建置者應用程式介面將驗證者連接到由運行執行層用戶端的區塊建置者組成的網路。 與 PBS 相同,構建者專注於投資消耗大量資源的區塊構建,並使用不同的策略最大限度地提提高從最大可提取價值 + 優先消費中賺取的收入。
+
+2. 驗證者(運行共識層用戶端)向建置者網路請求執行有效負載及出價。 建置者的出價將包含執行有效負載標頭,即對有效負載內容的加密承諾,和向驗證者支付的費用。
+
+3. 驗證者查看收到的出價並選擇費用最高的執行有效負載。 利用建置者應用程式介面,驗證者創建一個僅包括其簽名和執行有效負載標頭的「盲」信標區塊提案並發送給建置者。
+
+4. 在看到盲區塊提案時,運行建置者應用程式介面的建置者可能會用完整的執行有效負載回應。 這讓驗證者可以創建一個在整個網路中傳播的「已簽署」信標區塊。
+
+5. 如果區塊構建者未能及時響應,使用構建者應用程式介面的驗證者仍有可能在本地構建區塊,因此他們不會錯過區塊提交獎勵。 然而,驗證者不能使用已揭示的交易或另一組交易來創建另一個區塊,因為這將構成 _雙重簽署_ (在同一個時槽內簽署兩個區塊) 的行為,這是一種可罰沒的違規行為。
+
+建構者 API 的一個實作範例是 [MEV Boost](https://github.com/flashbots/mev-boost),這是對 [Flashbots 拍賣機制](https://docs.flashbots.net/Flashbots-auction/overview) 的改進,旨在抑制 MEV 對以太坊的負面外部性。 Flashbots 拍賣允許權益證明中的驗證者將建構有利可圖區塊的工作外包給稱為 **搜尋者** 的專業參與方。
+
+
+搜尋者尋找有利可圖的 MEV 機會,並將交易捆綁包連同 [密封價格投標](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) 一起發送給區塊提議者,以便將其納入區塊。 運行 mev-geth,即 go-ethereum (Geth) 用戶端的分叉版本的驗證者只需要選擇利潤最高的交易包,並將其新增到新區塊的一部分。 為了保護區塊提議者 (驗證者) 免受垃圾郵件和無效交易的影響,交易捆綁包在到達提議者之前會經過 **中繼者** 進行驗證。
+
+MEV Boost 的運作方式與原來的 Flashbots 拍賣相同,但增加了一些為以太坊向權益證明過渡而設計的新功能。 搜尋者仍然會尋找有利可圖的 MEV 交易以納入區塊,但是一類稱為 **建構者** 的新型專業參與方,將負責將交易和捆綁包匯總到區塊中。 建置者接受搜尋者提供的價格密封出價,並執行最佳化以找到利潤最大的排序。
+
+中繼者仍然負責驗證交易捆綁並將其傳送給提交者。 然而,MEV Boost 引入了 **託管方**,負責透過儲存建構者發送的區塊主體和驗證者發送的區塊頭來提供 [資料可用性](/developers/docs/data-availability/)。 對於代管,連結到中繼的驗證者請求可用的執行有效負載,並使用MEV Boost 的順序演算法選擇出價 + 最大可提取價值小費最高的有效負載頭。
+
+#### 建置者應用程式介面如何減低最大可提取價值的影響? {#how-does-builder-api-curb-mev-impact}
+
+建置者應用程式介面的核心優勢在於,它有可能讓參與者平等獲得最大可提取價值機會。 使用提交-揭露方案消除了信任假設,降低了尋求從最大可提取價值中獲利的驗證者的進入門檻。 這應該可以減輕單獨質押者加入大型質押池,以提高最大可提取價值利潤的壓力。
+
+建置者應用程式介面的廣泛實作將鼓勵區塊建置者之間進行更激烈的競爭,這將增強抗審查能力。 驗證者審查多個構建者的出價時,意圖審查一筆或多筆用戶交易的構建者必須出價高於所有其他不審查的構建者才能成功。 這大大增加了審查使用者的成本並對審查有所限制。
+
+一些項目,例如 MEV Boost,將構建者應用程式介面作爲整體結構的一部分,旨在為某些參與方 (例如試圖避免搶先交易/三明治攻擊的交易者) 提供交易隱私。 這是透過在使用者和區塊建置者之間提供一條私密通訊通道來實現的。 與先前描述的許可内存池不同,這種方法是有益的,原因如下:
+
+1. 市場上有多種建置者存在讓審查變得不切實際,這是有利於使用者的。 相反,基於信任的中心化暗池的存在將權力集中在少數區塊構建者的手中,並增加了審查的可能性。
+
+2. 建置者應用程式介面軟體是開源的,允許任何人提供區塊建置者服務。 這意味著使用者不會被迫使用任何特定的區塊建置者,並提高了以太坊的中立和無許可特性。 此外,尋求最大可提取價值的交易者不會因為使用私密交易管道而無意中促進中心化。
+
+## 相關資源 {#related-resources}
+
+- [Flashbots 文件](https://docs.flashbots.net/)
+- [Flashbots GitHub](https://github.com/flashbots/pm)
+- [mevboost.org](https://www.mevboost.org/) - _提供 MEV-Boost 中繼器和區塊建構者即時統計數據的追蹤器_
+
+## 延伸閱讀 {#further-reading}
+
+- [什麼是礦工可提取價值 (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/)
+- [MEV 與我](https://www.paradigm.xyz/2021/02/mev-and-me)
+- [以太坊是一座黑暗森林](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/)
+- [逃離黑暗森林](https://samczsun.com/escaping-the-dark-forest/)
+- [Flashbots:搶先應對 MEV 危機](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752)
+- [@bertcmiller 的 MEV 討論串](https://twitter.com/bertcmiller/status/1402665992422047747)
+- [MEV-Boost:為合併準備就緒的 Flashbots 架構](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177)
+- [什麼是 MEV Boost](https://www.alchemy.com/overviews/mev-boost)
+- [為什麼要執行 mev-boost?](https://writings.flashbots.net/writings/why-run-mevboost/)
+- [以太坊漫遊指南](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum)
diff --git a/public/content/translations/zh-tw/developers/docs/networking-layer/index.md b/public/content/translations/zh-tw/developers/docs/networking-layer/index.md
index 669968f52d2..941e9ff71b2 100644
--- a/public/content/translations/zh-tw/developers/docs/networking-layer/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networking-layer/index.md
@@ -1,5 +1,5 @@
---
-title: 網路層(Networking Layer)
+title: 網路層
description: 以太坊網路層簡介
lang: zh-tw
sidebarDepth: 2
@@ -11,9 +11,9 @@ sidebarDepth: 2
執行用戶端透過執行層的點對點網路廣播交易。 這需要經過驗證的對等點之間進行加密通訊。 當一名驗證者被選擇來提議區塊,來自區域交易池的交易將會透過區域遠端程序呼叫連線傳遞到共識用戶端,然後被打包進信標區塊中。 之後,共識用戶端將在其點對點網路中廣播信標區塊。 這需要兩個獨立的點對點網路:一個連線執行用戶端來廣播交易,另一個連線共識用戶端來廣播區塊。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-對以太坊[節點和用戶端](/developers/docs/nodes-and-clients/)稍有瞭解將有助於理解本文。
+對以太坊[節點和用戶端](/developers/docs/nodes-and-clients/)有一定了解,將有助於您理解本頁內容。
## 執行層 {#execution-layer}
@@ -25,27 +25,27 @@ sidebarDepth: 2
這兩個堆疊平行運作。 發現堆疊將新的網路參與者傳送到網路中,而 DevP2P 堆疊則使它們能夠進行互動。
-### 發現 {#discovery}
+### 探索 {#discovery}
-發現是在網路中尋找其他節點的過程。 這會使用一小組引導節點來啓動(地址被[硬編碼](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)到用戶端中的節點,因此它們能夠立即被找到並將用戶端連線到對等點)。 這些引導節點只用於將新節點引入到一組對等點 - 這是它們唯一的目的,它們不參與正常的用戶端任務,如同步鏈,並且它們只在用戶端第一次啓動時使用。
+發現是在網路中尋找其他節點的過程。 這是透過一小組啟動節點來引導的(節點位址被[硬編碼](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)到用戶端中,因此可以立即找到它們並將用戶端連接到對等點)。 這些引導節點只用於將新節點引入到一組對等點 - 這是它們唯一的目的,它們不參與正常的用戶端任務,如同步鏈,並且它們只在用戶端第一次啓動時使用。
-用於節點-引導節點互動的協定是 [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) 的修改版本,它使用[分散式雜湊資料表](https://en.wikipedia.org/wiki/Distributed_hash_table)來共用節點清單。 每個節點都有一個該資料表的版本,其中包含連線到其最近對等點所需的資訊。 這裏的「近」不是地理上的 - 距離是由節點 ID 的相似性來定義的。 每個節點的資料表都會定期刷新,作爲一種安全功能。 例如,在 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 中,發現協定節點也可以發送「ads」來展示用戶端支持的子協定,這允許對等點協調它們可以用於通訊的協定。
+用於節點與啟動節點之間互動的協議是 [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) 的修改形式,它使用[分散式哈希表](https://en.wikipedia.org/wiki/Distributed_hash_table)來共享節點列表。 每個節點都有一個該資料表的版本,其中包含連線到其最近對等點所需的資訊。 這裏的「近」不是地理上的 - 距離是由節點 ID 的相似性來定義的。 每個節點的資料表都會定期刷新,作爲一種安全功能。 例如,在 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 探索協議中,節點也能夠發送「廣告」,顯示用戶端支援的子協議,讓對等點能夠協商雙方都可以使用的通訊協議。
-發現從 PING-PONG 游戲開始。 一個成功的 PING-PONG 將新節點「連結綁定」到一個引導節點。 通知引導節點有新節點進入網路的初始訊息為 `PING`。 此 `PING` 包括關於新節點、引導節點和過期時間戳的雜湊資訊。 引導節點接收 `PING` 並返回包含 `PING` 雜湊的 `PONG`。 如果 `PING` 和 `PONG` 的雜湊相吻合,新節點和引導節點之間的連線就會被驗證,然後它們就被認爲「已綁定連結」。
+發現從 PING-PONG 游戲開始。 一個成功的 PING-PONG 將新節點「連結綁定」到一個引導節點。 提醒啟動節點有新節點進入網路的初始訊息是 `PING`。 這個 `PING` 包含關於新節點、啟動節點和到期時間戳的哈希資訊。 啟動節點收到 `PING` 後,會回傳一個包含 `PING` 哈希的 `PONG`。 如果 `PING` 和 `PONG` 的哈希相符,新節點和啟動節點之間的連線就會被驗證,即為「已綁定」。
-一旦綁定連結,新節點就可以向引導節點發送 `FIND-NEIGHBOURS` 請求。 引導節點返回的資料包含一個新節點可以連線的對等點清單。 如果節點沒有綁定連結,`FIND-NEIGHBOURS` 請求將會失敗,因而新節點將無法進入網路。
+一旦綁定,新節點就可以向啟動節點發送 `FIND-NEIGHBOURS` 請求。 引導節點返回的資料包含一個新節點可以連線的對等點清單。 如果節點沒有綁定,`FIND-NEIGHBOURS` 請求將會失敗,因此新節點將無法進入網路。
一旦新節點從引導節點收到鄰居清單,就會開始與每個鄰居節點進行 PING-PONG 交換。 成功的 PING-PONG 會將新節點與鄰居節點連結綁定,以實現訊息交換。
```
-start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours
+啟動用戶端 --> 連接到啟動節點 --> 綁定到啟動節點 --> 尋找鄰居節點 --> 綁定到鄰居節點
```
-執行用戶端目前使用 [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) 發現協定,並且正在努力遷移到 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 協定。
+執行用戶端目前使用 [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) 探索協議,並正積極遷移到 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 協議。
#### ENR:以太坊節點記錄 {#enr}
-[以太坊節點記錄 (ENR)](/developers/docs/networking-layer/network-addresses/) 是一個包含 3 個基本元素的物件:一個簽名(根據某種商定同意的身分識別方案產生的記錄内容的雜湊),一個追蹤記錄變更的序列編號,以及一個鍵值配對的任意清單。 這是一種面向未來的格式,它使得新對等點之間身分識別資訊的交換更加容易,並且是以太坊節點偏好的[網路地址](/developers/docs/networking-layer/network-addresses)格式。
+[以太坊節點記錄 (ENR)](/developers/docs/networking-layer/network-addresses/) 是一個物件,包含三個基本元素:一個簽章 (根據商定的身分方案對記錄內容進行哈希運算後的結果)、一個追蹤記錄變更的序號,以及一個任意的鍵值對列表。 這是一種能適應未來需求的格式,可讓新的對等點之間更容易交換識別資訊,也是以太坊節點偏好的[網路位址](/developers/docs/networking-layer/network-addresses)格式。
#### 爲什麽在使用者資料包通訊協定之上建置發現? {#why-udp}
@@ -53,7 +53,7 @@ start client --> connect to bootnode --> bond to bootnode --> find neighbours --
### DevP2P {#devp2p}
-DevP2P 本身是以太坊爲了建立和維護點對點網路而實作的一整套協定。 新節點進入網路之後,其互動由 [DevP2P](https://github.com/ethereum/devp2p)堆疊中的協定管理。 這些都建立於傳輸控制通訊協定之上,包括 RLPx 傳輸協定、綫路協定和一些子協定。 [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) 是管理啓動、驗證和維護節點之間工作階段的協定 RLPx 使用 RLP(遞迴長度前綴)編碼訊息,這是一種將資料編碼為最小結構來在節點之間發送的方法,這種方法非常節省空間。
+DevP2P 本身是以太坊爲了建立和維護點對點網路而實作的一整套協定。 新節點進入網路後,它們的互動由 [DevP2P](https://github.com/ethereum/devp2p) 堆疊中的協議所管理。 這些都建立於傳輸控制通訊協定之上,包括 RLPx 傳輸協定、綫路協定和一些子協定。 [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) 是管理節點之間啟動、驗證和維護會話的協議。 RLPx 使用 RLP(遞迴長度前綴)編碼訊息,這是一種將資料編碼為最小結構來在節點之間發送的方法,這種方法非常節省空間。
兩個節點之間的 RLPx 工作階段從初始加密握手開始。 這需要節點發送身份驗證訊息,然後對等點會進行驗證。 成功驗證後,對等點會生成驗證確認訊息,並將其返回初始節點。 這是一個密鈅交換程序,使節點能夠私密且安全地進行通訊。 成功的加密握手會觸發兩個節點「在綫上」互相發送「hello」訊息。 綫路協定透過成功交換 hello 訊息來發起。
@@ -69,47 +69,47 @@ hello 訊息包含:
除了「hello」訊息以外,綫路協定還可以發送「disconnect」訊息,該訊息警告對等點連線將會被關閉。 綫路協定還包含定期發送的 PING 和 PONG 訊息,以保持工作階段開放。 因此,RLPx 和綫路協定的交換為節點之間的通訊奠定了基礎,並為根據特定子協定交換的有用資訊提供了平台。
-### 子協定 {#sub-protocols}
+### 子協議 {#sub-protocols}
-#### 綫路協定 {#wire-protocol}
+#### 有線協議 {#wire-protocol}
-一旦對等點連線並且 RLPx 工作階段啓動,綫路協定就會定義對等點的通訊方式。 一開始,綫路協定會定義三個主要任務:鏈同步、區塊傳播和交易交換。 然而,以太坊切換到權益證明後,區塊傳播和鏈同步變成了共識層的一部分。 但交易交換仍然由執行用戶端負責。 交易交換指的是節點之間交換等待處理的交易,以便區塊建置者能夠選擇其中一些放到下一個區塊中。 請在[此處](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)查看有關這些任務的詳細資訊。 支持這些子協定的用戶端透過 [JSON-RPC](/developers/docs/apis/json-rpc/) 將自己公開。
+一旦對等點連線並且 RLPx 工作階段啓動,綫路協定就會定義對等點的通訊方式。 一開始,綫路協定會定義三個主要任務:鏈同步、區塊傳播和交易交換。 然而,以太坊切換到權益證明後,區塊傳播和鏈同步變成了共識層的一部分。 但交易交換仍然由執行用戶端負責。 交易交換指的是節點之間交換等待處理的交易,以便區塊建置者能夠選擇其中一些放到下一個區塊中。 關於這些任務的詳細資訊,請參閱[此處](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)。 支援這些子協議的用戶端會透過 [JSON-RPC](/developers/docs/apis/json-rpc/) 將它們公開。
-#### les(輕量以太坊子協定) {#les}
+#### les (輕量以太坊子協議) {#les}
-這是用於同步輕量級用戶端的最小協定。 傳統上,該協定很少被使用,因爲全節點需要在沒有激勵的情況下向輕用戶端提供資料。 執行用戶端的預設行爲不是透過 les 為輕量級用戶端提供服務。 請在 les [規範](https://github.com/ethereum/devp2p/blob/master/caps/les.md)中查看更多相關資訊。
+這是用於同步輕量級用戶端的最小協定。 傳統上,該協定很少被使用,因爲全節點需要在沒有激勵的情況下向輕用戶端提供資料。 執行用戶端的預設行爲不是透過 les 為輕量級用戶端提供服務。 更多資訊請參閱 les [規格](https://github.com/ethereum/devp2p/blob/master/caps/les.md)。
-#### 快照 {#snap}
+#### Snap {#snap}
-[快照協定](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap)是一種可選的擴充功能,它使對等點能夠交換最近狀態的快照,從而無需下載默克爾樹的内部節點就能驗證帳戶及存儲資料。
+[快照協議 (snap protocol)](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) 是一種可選的擴充功能,讓對等點能交換最近狀態的快照,從而無需下載中介的默克爾樹節點即可驗證帳戶和儲存資料。
-#### Wit(見證協定) {#wit}
+#### Wit (見證協議) {#wit}
-[見證協定](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit)是一種可選的擴充功能,使對等點之間能夠交換狀態見證,幫助用戶端與鏈前端同步。
+[見證協議 (witness protocol)](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) 是一種可選的擴充功能,能在對等點之間交換狀態見證,有助於將用戶端同步到鏈的頂端。
#### Whisper {#whisper}
-Whisper 是一個旨在實現安全的點對點資訊傳輸,而不需要向區塊鏈寫入任何資訊的協定。 它曾是 DevP2P 綫路協定的一部分,但現在已經棄用。 其他[相關專案](https://wakunetwork.com/)也有類似目標。
+Whisper 是一個旨在實現安全的點對點資訊傳輸,而不需要向區塊鏈寫入任何資訊的協定。 它曾是 DevP2P 綫路協定的一部分,但現在已經棄用。 也有其他目標類似的[相關專案](https://wakunetwork.com/)。
## 共識層 {#consensus-layer}
共識用戶端參與具有不同規範的單獨點對點網路。 共識用戶端需要參與區塊廣播,以便其能夠從對等點接受新區塊,並在輪到其成爲區塊提議者時廣播它們。 與執行層類似,這首先需要一個發現協定,一邊節點可以找到對等點並建立安全的工作階段來交換區塊、證明等。
-### 發現 {#consensus-discovery}
+### 探索 {#consensus-discovery}
-與執行用戶端類似,共識用戶端使用使用者資料包通訊協定上的 [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) 尋找對等點。 discv5 的共識層實現與執行用戶端的區別僅在於,它包含一個將 discv5 連線到 [libP2P](https://libp2p.io/) 堆疊的適配器,棄用了 DevP2P。 執行層的 RLPx 工作階段被棄用,代之以 libP2P 的噪音安全通道握手。
+與執行用戶端類似,共識用戶端也透過 UDP 使用 [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) 來尋找對等點。 discv5 的共識層實作與執行用戶端的實作不同之處僅在於:它包含一個將 discv5 連接到 [libP2P](https://libp2p.io/) 堆疊的適配器,並棄用了 DevP2P。 執行層的 RLPx 工作階段被棄用,代之以 libP2P 的噪音安全通道握手。
-### 以太坊節點記錄 {#consensus-enr}
+### ENR {#consensus-enr}
-共識節點的以太坊節點記錄包括節點的公鑰、IP 地址、使用者資料包通訊協定和傳輸控制通訊協定連接埠,以及兩個共識特定欄位:證明子網路位元欄位和 `eth2` 金鑰。 前者使節點更容易找到參與特定證明廣播子網路的對等點。 `eth2` 金輪包含節點正在使用的以太坊分叉版本的資訊,以確保對等點連線到正確的以太坊。
+共識節點的 ENR 包括節點的公鑰、IP 位址、UDP 和 TCP 連接埠,以及兩個共識專屬的欄位:證明子網路位元欄位和 `eth2` 金鑰。 前者使節點更容易找到參與特定證明廣播子網路的對等點。 `eth2` 金鑰包含節點正在使用的以太坊分叉版本資訊,確保對等點連接到正確的以太坊。
### libP2P {#libp2p}
libP2P 堆疊支持發現之後的所有通訊。 用戶端可以根據其以太坊節點記錄的定義在 IPv4 和/或 IPv6 上撥號和接聽。 libP2P 層上的協定可以細分爲廣播和請求/響應域。
-### 廣播 {#gossip}
+### 傳播 {#gossip}
-廣播域包括必須在整個網路中快速傳播的所有資訊。 這包括信標區區塊、證據、證明、退出和罰沒。 這是使用 libP2P gossipsub v1 傳輸的,並且依賴於在每個節點本機儲存的各種中繼資料,包括接收和傳輸的廣播承載的上限。 請在[此處](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)查看有關廣播域的詳細資訊。
+廣播域包括必須在整個網路中快速傳播的所有資訊。 這包括信標區區塊、證據、證明、退出和罰沒。 這是使用 libP2P gossipsub v1 傳輸的,並且依賴於在每個節點本機儲存的各種中繼資料,包括接收和傳輸的廣播承載的上限。 關於傳播網域的詳細資訊,請參閱[此處](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)。
### 請求-回應 {#request-response}
@@ -119,25 +119,25 @@ libP2P 堆疊支持發現之後的所有通訊。 用戶端可以根據其以太
SSZ 代表簡單序列化。 它使用固定位移,能夠簡單地解碼編碼訊息的單獨部分,而無需解碼整個結構,這對於共識用戶端非常有用,因爲它可以高效地從編碼訊息中獲取特定資訊片段。 它還專門設計於與默克爾協定整合,並提升與默克爾化相關的效率。 由於共識層中的所有雜湊都是默克爾根,這會帶來顯著的改進。 簡單序列化也保證值的唯一表示。
-## 連線執行用戶端和共識用戶端 {#connecting-clients}
+## 連接執行用戶端與共識用戶端 {#connecting-clients}
-共識用戶端和執行用戶端平行運作。 它們需要彼此連線,以便共識用戶端向執行用戶端提供指示,並使執行用戶端能夠向執行用戶端傳送需要納入信標區塊的交易捆綁。 兩個用戶端之間的通訊可以透過本機遠端程序呼叫連線來實現。 名爲[「Engine-API」](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)的應用程式介面定義兩個用戶端之間發送的指示。 由於兩個用戶端共用一個網路身分,它們也共用一個 ENR(以太坊節點記錄),其中包含每個用戶端的單獨金鑰(eth1 金鑰和 eth2 金鑰)。
+共識用戶端和執行用戶端平行運作。 它們需要彼此連線,以便共識用戶端向執行用戶端提供指示,並使執行用戶端能夠向執行用戶端傳送需要納入信標區塊的交易捆綁。 兩個用戶端之間的通訊可以透過本機遠端程序呼叫連線來實現。 一個稱為「Engine-API」的 [API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) 定義了在這兩個用戶端之間傳送的指令。 由於兩個用戶端共用一個網路身分,它們也共用一個 ENR(以太坊節點記錄),其中包含每個用戶端的單獨金鑰(eth1 金鑰和 eth2 金鑰)。
如下展示了控制流摘要,括號中是相關的網路堆疊。
### 當共識用戶端不是區塊生產者時: {#when-consensus-client-is-not-block-producer}
- 共識用戶端透過區塊廣播協定(共識點對點)接收區塊
-- 共識用戶端預驗證區塊,即確保它來自具有正確中繼資料的有效發送者
+- 共識用戶端預先驗證區塊,即確保區塊來自有效的發送者且帶有正確的中繼資料
- 區塊中的交易作爲執行承載發送到執行層(本機遠端程序呼叫連線)
-- 執行層執行交易並驗證區塊頭中的狀態(即檢查雜湊是否相符)
+- 執行層執行交易並驗證區塊頭中的狀態 (即檢查哈希是否相符)
- 執行層將驗證資料傳送回共識層,區塊現在被認爲已驗證(本機遠端程序呼叫連線)
- 共識層將區塊添加到其區塊鏈頭並證明該區塊,透過網路廣播證明(共識點對點)
### 當共識用戶端是區塊生產者時: {#when-consensus-client-is-block-producer}
- 共識用戶端收到其將成爲下一個區塊生產者的通知(共識點對點)
-- 共識層在執行用戶端調用 `create block` 方法(本機遠端程序呼叫)
+- 共識層在執行用戶端中呼叫 `create block` 方法 (本機 RPC)
- 執行層訪問已由交易廣播協定填充的交易内存池(執行點對點)
- 執行用戶端將交易捆綁進一個區塊,執行交易並產生一個區塊雜湊
- 共識用戶端從執行用戶端獲取交易和區塊雜湊,並將其新增至信標區塊(本機遠端程序呼叫)
@@ -146,10 +146,18 @@ SSZ 代表簡單序列化。 它使用固定位移,能夠簡單地解碼編碼
一旦區塊被足夠多的驗證者證明后,就會被新增到鏈頭,經過合理化並最終確定。
- 
+
+
-共識用戶端和執行用戶端的網路層示意圖,取自 [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
+共識和執行用戶端的網路層示意圖,來源:[ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [共識層網路規範](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia 到 discv5](https://vac.dev/kademlia-to-discv5) [kademlia 論文](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [以太坊點對點簡介](https://p2p.paris/en/talks/intro-ethereum-networking/) [eth1/eth2 的關係](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [合併和 eth2 用戶端詳情影片](https://www.youtube.com/watch?v=zNIrIninMgg)
+[DevP2P](https://github.com/ethereum/devp2p)
+[LibP2p](https://github.com/libp2p/specs)
+[共識層網路規格](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)
+[kademlia 到 discv5](https://vac.dev/kademlia-to-discv5)
+[kademlia 論文](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf)
+[以太坊點對點網路介紹](https://p2p.paris/en/talks/intro-ethereum-networking/)
+[eth1/eth2 關係](http://ethresear.ch/t/eth1-eth2-client-relationship/7248)
+[合併與 eth2 用戶端詳細資訊影片](https://www.youtube.com/watch?v=zNIrIninMgg)
diff --git a/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md
index 59be88f0d71..ea23f9177a8 100644
--- a/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md
@@ -1,5 +1,5 @@
---
-title: 網路地址(Network addresses)
+title: 網路地址
description: 網路地址簡介
lang: zh-tw
sidebarDepth: 2
@@ -7,33 +7,33 @@ sidebarDepth: 2
以太坊節點必須使用一些基本資訊識別自身,以連接對等節點。 為了確保任何潛在對等節點都能解釋該資訊,需要使用任何以太網節點都能理解的三種標準化格式中的一種進行轉送:Multiaddr、Enode 或以太坊節點記錄 (ENR)。 以太坊節點紀錄 (ENR) 是目前的以太坊網路地址標準。
-## 先備知識 {#prerequisites}
+## 先決條件 {#prerequisites}
-要理解本頁內容,需具備一些以太坊[網路層](/developers/docs/networking-layer/)的基本知識。
+要了解此頁面,您需要對以太坊的[網路層](/developers/docs/networking-layer/)有一些了解。
## Multiaddr {#multiaddr}
-原始以太坊節點地址的格式為「multiaddr」(簡稱「多重地址」)。 Multiaddr 是為點對點網絡設計的通用格式。 這些地址利用鍵值配對表示,其中的鍵與值以斜線分隔。 例如,對於一個 IPv4 地址為 `192.168.22.27`、監聽傳輸控制通訊協定 (TCP) 連接埠 `33000` 的節點,其 Multiaddr 可以表示為:
+原始以太坊節點地址的格式為「multiaddr」(簡稱「多重地址」)。 Multiaddr 是為點對點網絡設計的通用格式。 這些地址利用鍵值配對表示,其中的鍵與值以斜線分隔。 例如,一個 IPv4 位址為 `192.168.22.27` 並監聽 TCP 連接埠 `33000` 的節點,其 multiaddr 如下:
-`/ip4/192.168.22.27/tcp/33000`
+/ip4/192.168.22.27/tcp/33000
若以太坊節點為例,含有節點 ID(其公鑰的雜湊值)的 Multiaddr 可以表示為:
-`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br`
+/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br
## Enode {#enode}
Enode 使得以太坊節點可以用統一資源定位器地址格式識別。 在統一資源定位器的使用者名稱部分編碼十六進位的節點 ID,並使用 @ 將其與主機名稱分開。 主機名稱只能使用 IP 地址表示;不能使用網域名稱服務名稱。 主機名稱部分的連接埠是傳輸控制通訊協定 (TCP) 監聽連接埠。 如果傳輸控制通訊協定 (TCP) 與使用者資料包通訊協定 (UDP) 連接埠不同,則使用者資料包通訊協定 (UDP) 連接埠必須宣告為查詢參數「discport」。
-下述範例中,節點統一資源定位器由 IP 地址 `10.3.58.6`、傳輸控制通訊協定 (TCP) 連接埠 `30303` 以及使用者資料包通訊協定 (UDP) 探索連接埠 `30301` 組成。
+在以下範例中,節點 URL 描述了一個 IP 位址為 `10.3.58.6`、TCP 連接埠為 `30303`,以及 UDP 探索連接埠為 `30301` 的節點。
-`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301`
+enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301
## 以太坊節點紀錄 (ENR) {#enr}
-以太坊節點紀錄 (ENR) 是目前以太坊網路地址的標準化格式。 它取代了 Multiaddr 與 Encode 格式, 並允許節點間更大量的資訊交換,這一點尤其有用。 以太坊節點紀錄包含簽章、序列編號和多個欄位,這些欄位詳細說明用於產生和驗證簽章的身分識別方案。 以太坊節點紀錄也可以填入任意組織為鍵值配對形式的資料。 這些鍵值配對包含節點的 IP 地址以及節點能使用的子通訊協定相關資訊。 共識用戶端使用一種[特定的以太坊節點記錄結構](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)來識別引導節點,並且也包含一個 `eth2` 欄位,其中包含有關目前以太坊分叉和證明八卦子網路(該子網路將節點連線到一組已將其證明彙總到一起的特定對等方)的資訊。
+以太坊節點紀錄 (ENR) 是目前以太坊網路地址的標準化格式。 它取代了 Multiaddr 與 Encode 格式, 並允許節點間更大量的資訊交換,這一點尤其有用。 以太坊節點紀錄包含簽章、序列編號和多個欄位,這些欄位詳細說明用於產生和驗證簽章的身分識別方案。 以太坊節點紀錄也可以填入任意組織為鍵值配對形式的資料。 這些鍵值配對包含節點的 IP 地址以及節點能使用的子通訊協定相關資訊。 共識用戶端使用[特定的 ENR 結構](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)來識別引導節點,且亦包含 `eth2` 欄位,其中含有關於當前以太坊分叉和證明 gossip 子網路的資訊(此子網路將節點連結至一組特定的對等點,其證明會被匯總在一起)。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [EIP-778:以太坊節點紀錄 (ENR)](https://eips.ethereum.org/EIPS/eip-778)
-- [LibP2P:Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/)
+- [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/)
diff --git a/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md
index 2e6e0a8b394..e575c3303e3 100644
--- a/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md
@@ -10,25 +10,25 @@ lang: zh-tw
入口網路是為以太坊開發的新型網路設計。藉由以小塊方式在整個網路分享必要性的資料,輕量級節點不需要信任或增加全節點負擔的方式,解決資料可用性問題。
-更多資訊請參閱[節點和用戶端](/developers/docs/nodes-and-clients/)
+深入了解[節點和用戶端](/developers/docs/nodes-and-clients/)
-## 為什麼我們需要入口網路 {#why-do-we-need-portal-network}
+## 我們為什麼需要入口網路 {#why-do-we-need-portal-network}
以太坊節點儲存以太坊區塊鏈的全部或部分複製資料。 這些區域性的複本被用來驗證交易和確保節點沿著正確的區塊鏈行進。 在區域儲存資料使節點能夠獨立驗證進來的資料有效和正確與否,不需要依賴任何其他實體。
-區塊鏈以及相關狀態和收據資料的區域複本佔據節點硬碟相當大的空間。 例如:使用 [Geth](https://geth.ethereum.org) 搭配共識用戶端來經營一個節點,建議要有 2TB 的硬碟。 使用只儲存比較近期的區塊組的鏈資料的快照同步,Geth 通常佔用約 650GB 的磁碟空間,但以約 14GB/周在成長(你可以定期向下修整節點至 650GB)。
+區塊鏈以及相關狀態和收據資料的區域複本佔據節點硬碟相當大的空間。 例如,建議使用 2TB 的硬碟,以執行與共識用戶端配對的 [Geth](https://geth.ethereum.org) 節點。 使用只儲存比較近期的區塊組的鏈資料的快照同步,Geth 通常佔用約 650GB 的磁碟空間,但以約 14GB/周在成長(你可以定期向下修整節點至 650GB)。
-這意味著經營節點的成本是很高的,因為以太坊需要大量的專用磁碟空間。 在以太坊開發藍圖上對這個問題有若干解決方法,包括[歷史有效期限](/roadmap/statelessness/#history-expiry)、[狀態有效期限](/roadmap/statelessness/#state-expiry)和[無狀態](/roadmap/statelessness/)。 然而,這可能要若干年後才有可能實行。 還有不必保存自己的鏈上資料複本的[輕量級節點](/developers/docs/nodes-and-clients/light-clients/),它們需要向全節點請求資料。 然而,這意味著輕量級節點必須信任全節點會提供真實的資料,並且強調全節點必須提供輕量級節點需要的資料。
+這意味著經營節點的成本是很高的,因為以太坊需要大量的專用磁碟空間。 以太坊開發藍圖上有幾個此問題的解決方案,包括[歷史紀錄過期](/roadmap/statelessness/#history-expiry)、[狀態過期](/roadmap/statelessness/#state-expiry) 和[無狀態性](/roadmap/statelessness/)。 然而,這可能要若干年後才有可能實行。 另外還有[輕量節點](/developers/docs/nodes-and-clients/light-clients/),它們不會儲存自己的鏈上資料複本,而是向完整節點請求所需的資料。 然而,這意味著輕量級節點必須信任全節點會提供真實的資料,並且強調全節點必須提供輕量級節點需要的資料。
入口網路旨在提供一種替代方法,使輕量級節點能夠獲取它們的資料,而無需信任或顯著增加全節點必須完成的工作。 讓整個網路上的以太坊節點可以分享資料,需要引入新的方法。
## 入口網路如何運作? {#how-does-portal-network-work}
-以太坊節點有嚴格的協定來定義它們如何相互通訊。 執行用戶端使用一組稱為 [DevP2P](/developers/docs/networking-layer/#devp2p) 的子協定通訊,而共識用戶端則使用一組不同的被稱為 [libP2P](/developers/docs/networking-layer/#libp2p) 的子協定。 它們定義了可以在節點之間傳遞的資料類型。
+以太坊節點有嚴格的協定來定義它們如何相互通訊。 執行用戶端使用一組稱為 [DevP2P](/developers/docs/networking-layer/#devp2p) 的子協定進行通訊,而共識用戶端則使用另一組稱為 [libP2P](/developers/docs/networking-layer/#libp2p) 的子協定堆疊。 它們定義了可以在節點之間傳遞的資料類型。

-節點可以經由 [JSON-RPC 應用程式介面](/developers/docs/apis/json-rpc/)提供特定資料,這是應用程式和電子錢包與以太坊節點交換資訊的方式。 然而,這些都不是用來提供資料給輕量級用戶端的理想協定。
+節點也可透過 [JSON-RPC API](/developers/docs/apis/json-rpc/) 提供特定資料,應用程式和錢包就是透過這種方式與以太坊節點交換資訊。 然而,這些都不是用來提供資料給輕量級用戶端的理想協定。
輕量級用戶端目前無法透過 DevP2P 或 libP2p 請求具體的鏈資料,因爲那些協定只被設計來實現鏈同步和廣播區塊與交易。 輕量級用戶端不想下載這些資訊,因為這樣它們將不再是「輕量」的。
@@ -36,7 +36,7 @@ JSON-RPC 應用程式介面也不是輕量級用戶端資料請求的理想選
入口網路的重點在於重新思考整個設計,專門為輕便而建立,不受現有以太坊用戶端的設計限制。
-入口網路的核心思想是使用[分散式雜湊資料表](https://en.wikipedia.org/wiki/Distributed_hash_table)(類似於 Bittorrent),透過輕量 DevP2P 式的點對點去中心化網絡啓用輕量級用戶端所需的資訊,例如歷史資料和目前鏈頭的身份,從而充分利用目前網路堆棧的最佳部分。
+入口網路的核心概念是汲取當前網路堆疊的精華,透過輕量級 DevP2P 風格的點對點去中心化網路,使用[分散式雜湊表 (DHT)](https://en.wikipedia.org/wiki/Distributed_hash_table)(類似 Bittorrent)來提供輕量用戶端所需的資訊,例如歷史資料與當前鏈首的身分。
這個概念是新增小部分的以太坊全體歷史資料和一些特定節點責任到每一個節點。 然後,尋找儲存所請求特定資料的節點,擷取這些資料,將資料提供給請求。
@@ -48,16 +48,16 @@ JSON-RPC 應用程式介面也不是輕量級用戶端資料請求的理想選
- 同步近期和歷史鏈資料
- 擷取狀態資料
- 廣播交易
-- 使用[以太坊虛擬機](/developers/docs/evm/)執行交易
+- 使用 [EVM](/developers/docs/evm/) 執行交易
這個網路設計的優勢是:
- 降低對中心化提供者的依存
- 降低網際網路頻寬的使用
- 同步處理減到最少或零
-- 可存取資源有限的裝置(\<1 GB RAM,\<100 MB 磁碟空間,1 個 CPU)
+- 可供資源受限的裝置存取 (\<1 GB RAM、\<100 MB 磁碟空間、1 個 CPU)
-下圖顯示可由入口網路提供的現存用戶端功能,如此讓使用者能在低資源裝置上存取這些功能。
+下表顯示可由入口網路提供的現有用戶端功能,能讓使用者在資源極少的裝置上存取這些功能。
### 入口網路
@@ -69,21 +69,21 @@ JSON-RPC 應用程式介面也不是輕量級用戶端資料請求的理想選
## 預設的用戶端多樣性 {#client-diversity-as-default}
-入口網路開發者最初也決定建立三種不同的入口網路用戶端設計。
+入口網路的開發者也從一開始就做出了設計選擇,要建置四個獨立的入口網路用戶端。
入口網路用戶端如下:
-- [Trin](https://github.com/ethereum/trin):以 Rust 編寫
-- [Fluffy](https://nimbus.team/docs/fluffy.html):以 Nim 編寫
-- [Ultralight](https://github.com/ethereumjs/ultralight):以 Typescript 編寫
-- [Shisui](https://github.com/optimism-java/shisui):以 Go 語言編寫
+- [Trin](https://github.com/ethereum/trin):以 Rust 撰寫
+- [Fluffy](https://fluffy.guide):以 Nim 撰寫
+- [Ultralight](https://github.com/ethereumjs/ultralight):以 Typescript 撰寫
+- [Shisui](https://github.com/zen-eth/shisui):以 Go 撰寫
有多個獨立用戶端安裝啟用,增強了以太坊網路的回復力和去中心化。
假如一個用戶端遭受問題或漏洞,其他用戶端能繼續順暢運作,可以防止單點失靈。 此外,多樣化的用戶端安裝啟用能促進創新和競爭,驅使改善,和降低在這生態系統的單一文化風險。
-## 了解更多 {#futher-reading}
+## 延伸閱讀 {#further-reading}
-- [入口網路(Piper Merriam 在 Bogota 舉辦的 Devcon 大會)](https://www.youtube.com/watch?v=0stc9jnQLXA)。
-- [入口網路 discord](https://discord.gg/CFFnmE7Hbs)
+- [入口網路 (Piper Merriam 於 Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA)。
+- [入口網路 Discord](https://discord.gg/CFFnmE7Hbs)
- [入口網路網站](https://www.ethportal.net/)
diff --git a/public/content/translations/zh-tw/developers/docs/networks/index.md b/public/content/translations/zh-tw/developers/docs/networks/index.md
index 241733f4b9a..360fdc5b524 100644
--- a/public/content/translations/zh-tw/developers/docs/networks/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networks/index.md
@@ -8,36 +8,37 @@ lang: zh-tw
你的以太坊帳戶可以跨不同網路使用,但你的帳戶餘額及交易歷史記錄並不會跟著從以太坊主網轉移過去。 進行測試時,知道哪些網路可用及如何取得要試用的測試網以太幣是非常有用的。 一般來說,出於安全考量,並不推薦在測試網上再次使用主網帳戶,反之亦然。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在深入閱讀不同網路相關內容前,你應先了解[以太坊的基礎知識](/developers/docs/intro-to-ethereum/),因為測試網路會給你提供實惠、安全的以太坊版本以供測試。
+在深入閱讀不同網路的相關內容前,你應先了解[以太坊的基礎知識](/developers/docs/intro-to-ethereum/),因為測試網會給你提供實惠、安全的以太坊版本以供測試。
## 公共網路 {#public-networks}
-公共網路可由全球任何人透過網際網路進行存取。 任何人都可以在公共區塊鏈上讀取或建立交易,並且可以驗證已經執行的交易。 網路中對等節點間的共識決定了交易的納入和網路的狀態。
+公共網路可供世界上任何有網際網路連線的人訪問。 任何人都能在公共區塊鏈上讀取或創建交易並驗證被執行的交易。 對等節點間的共識決定了交易的打包和網路的狀態。
-### 主網 {#mainnet}
+### 以太坊主網 {#ethereum-mainnet}
-主網是指主要的以太坊生產區塊鏈,所有具有實際價值的交易都發生在主網的去中心化帳本上。
+主網為以太坊的主要公共生產區塊鏈,也為實際交易發生於分佈式帳本之所在。
-當人們和交易所討論 ETH 價格時,他們談論的是主網上的 ETH。
+當人們和交易所討論以太幣價格時,討論的是主網以太幣。
-### 測試網 {#testnets}
+### 以太坊測試網 {#ethereum-testnets}
-除了主網外,還有公共測試網。 測試網由協議開發者或智慧型合約開發者使用,用於在將建議部署到主網之前,在模擬主網的環境中測試協議升級和潛在的智慧型合約。 將其視為生產與試運行伺服器的類比。
+除主網外,還有一些公共測試網。 應用程式開發者或智慧型合約開發者使用測試網來測試協議升級,也用於在部署到主網之前在一個類生產環境中測試潛在的智慧型合約。 可將主網與測試網類比於生產伺服器與暫置伺服器。
-在將你的合約部署到主網前,你應該先在測試網上測試你編寫的任何合約程式碼。 在與現有智慧型合約整合的去中心化應用程式中,大多數專案會將副本部署在測試網上。
+部署至主網前,應在測試網上測試你編寫的所有合約程式碼。 在整合了智慧型合約的去中心化應用程式中,大部分專案都有部署到測試網的版本。
-目前主要的測試網是 Sepolia 和 Hoodi。 Sepolia 是合約和應用程式開發者用來測試其應用程式的網路。 而在 Hoodi 網路上,協議開發者測試網路升級,質押者測試驗證者的運行狀況。
+大部分測試網一開使都使用權威證明共識機制。 這表示將挑選出一小部分節點驗證交易並創建新區塊 – 並在此過程中質押其身分。 或者,有些測試網採用開放的權益證明共識機制,任何人都可以測試驗證者的運行狀況,就像在以太坊主網上一樣。
-#### Sepolia {#sepolia}
+測試網上的以太幣原本應該是沒有實際價值的;然而,已經有為取得一些稀少或難以獲得的測試網以太幣而建立的市場。 因為要和以太坊(即使在測試網上)實際互動需要以太幣,多數人透過水龍頭免費獲得測試網以太幣。 多數水龍頭為 Web 應用程式,你可以在其中輸入你請求發送以太幣的地址。
+
+#### 我該使用哪個測試網?
-Sepolia 是推薦供開發者測試其應用程式的測試網。 Sepolia 網路採用許可制的驗證者集。 這意味著此測試網不對外開放新的驗證者,因此不具高風險性不會分叉或遇到下線的問題。 相對而言,該網路也擁有較小的狀態,這意味著需同步的網路較小,運行節點和與網路交互會更加容易。
+目前用戶端開發者維護的兩個公共測試網分別為 Sepolia 及 Hoodi。 Sepolia 是合約和應用程式開發者用來測試其應用程式的網路。 在 Hoodi 網路上,協議開發者測試網路升級,質押者測試驗證者的運行狀況。
-- 採許可制的驗證者集,由用戶端和測試團隊控制
-- 新測試網,狀態資料較少
-- 快速同步且建立節點容易
-- 若需測試合約或去中心化應用程式,可使用此網路
+#### Sepolia {#sepolia}
+
+**Sepolia 是推薦用於應用程式開發的預設測試網**。 Sepolia 網路使用許可制的驗證程式集合,由用戶端和測試團隊控制。
##### 資源
@@ -45,78 +46,135 @@ Sepolia 是推薦供開發者測試其應用程式的測試網。 Sepolia 網路
- [GitHub](https://github.com/eth-clients/sepolia)
- [Otterscan](https://sepolia.otterscan.io/)
- [Etherscan](https://sepolia.etherscan.io)
+- [Blockscout](https://eth-sepolia.blockscout.com/)
##### 水龍頭
-- [工作量證明水龍頭](https://sepolia-faucet.pk910.de/)
-- [Coinbase 錢包水龍頭 | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet)
-- [Alchemy Sepolia 水龍頭](https://sepoliafaucet.com/)
-- [QuickNode Sepolia 水龍頭](https://faucet.quicknode.com/drip)
+- [Alchemy Sepolia 水龍頭](https://www.alchemy.com/faucets/ethereum-sepolia)
+- [Chain Platform Sepolia 水龍頭](https://faucet.chainplatform.co/faucets/ethereum-sepolia/)
+- [Chainstack Sepolia 水龍頭](https://faucet.chainstack.com/sepolia-testnet-faucet)
+- [以太坊生態系水龍頭](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia)
+- [ethfaucet.com Sepolia 水龍頭](https://ethfaucet.com/networks/ethereum)
+- [Google Cloud Web3 Sepolia 水龍頭](https://cloud.google.com/application/web3/faucet/ethereum/sepolia)
+- [Grabteeth](https://grabteeth.xyz/)
- [Infura Sepolia 水龍頭](https://www.infura.io/faucet)
-- [Chainstack Sepolia 水龍頭](https://faucet.chainstack.com/sepolia-faucet)
-- [Alchemy Sepolia 水龍頭](https://sepoliafaucet.com/)
+- [PoW 水龍頭](https://sepolia-faucet.pk910.de/)
+- [QuickNode Sepolia 水龍頭](https://faucet.quicknode.com/ethereum/sepolia)
#### Hoodi {#hoodi}
-Hoodi 是為測試驗證和質押而設計的測試網。 Hoodi 網路對於希望運行測試網驗證者的使用者開放。 因此,想測試協議升級的質押者,應在部署至主網前先使用 Hoodi 測試。
+Hoodi 是測試驗證和質押的測試網。 Hoodi 測試網對想要運行測試網驗證者的使用者開放。 因此,想測試協議升級的質押者,應在部署至主網前先使用 Hoodi 測試。
-- 開放的驗證者集,質押者可測試網路升級
-- 較大的狀態資料,適用於測試複雜的智慧合約互動
-- 同步時間較長,運行節點需要更多儲存空間
+- 開放的驗證者集合,質押者可以測試網路升級
+- 龐大的狀態,對於測試複雜的智能合約互動很有幫助
+- 同步時間更長,運行節點需要更多存儲
##### 資源
- [網站](https://hoodi.ethpandaops.io/)
- [GitHub](https://github.com/eth-clients/hoodi)
-- [區塊瀏覽器](https://explorer.hoodi.ethpandaops.io/)
+- [瀏覽器](https://explorer.hoodi.ethpandaops.io/)
- [檢查點同步](https://checkpoint-sync.hoodi.ethpandaops.io/)
+- [Otterscan](https://hoodi.otterscan.io/)
+- [Etherscan](https://hoodi.etherscan.io/)
##### 水龍頭
+- [Chain Platform Hoodi 水龍頭](https://faucet.chainplatform.co/faucets/ethereum-hoodi/)
- [Hoodi 水龍頭](https://hoodi.ethpandaops.io/)
+- [PoW 水龍頭](https://hoodi-faucet.pk910.de/)
+
+#### Ephemery {#ephemery}
+
+Ephemery 是一個獨特的測試網,每個月都會完全重置。 執行和共識狀態每 28 天回滾至創世區塊,這意味著在測試網上發生的任何事情都是短暫的 (ephemeral)。 這使其非常適合短期測試,快速節點引導以及不需要持久性的「hello world」類應用程式。
+
+- 不斷刷新狀態,適用於驗證者和應用程式的短期測試
+- 只包含基本的合約集合
+- 開放驗證者集合,能夠輕鬆訪問大量資金
+- 最低的節點要求和最快的同步速度,平均小於 5GB
+
+##### 資源
-要在 Hoodi 測試網上啟動驗證者,請使用 [Hoodi 啟動面板](https://hoodi.launchpad.ethereum.org/en/)。
+- [網站](https://ephemery.dev/)
+- [Github](https://github.com/ephemery-testnet/ephemery-resources)
+- [社群聊天室](https://matrix.to/#/#staker-testnet:matrix.org)
+- [Blockscout](https://explorer.ephemery.dev/)
+- [Otterscan](https://otter.bordel.wtf/)
+- [信標瀏覽器](https://beaconlight.ephemery.dev/)
+- [檢查點同步](https://checkpoint-sync.ephemery.ethpandaops.io)
+- [啟動面板](https://launchpad.ephemery.dev/)
-### 第 2 層測試網 {#layer-2-testnets}
+#### 水龍頭
-[第 2 層 (L2)](/layer-2/) 是一個統稱,用於描述一系列特定的以太坊擴容解決方案。 第 2 層是一個單獨的區塊鏈,它擴展以太坊並繼承了以太坊的安全保障。 第 2 層測試網通常與公共以太坊測試網緊密結合。
+- [Bordel 水龍頭](https://faucet.bordel.wtf/)
+- [Pk910 PoW 水龍頭](https://ephemery-faucet.pk910.de/)
+
+#### Holesky (已棄用) {#holesky}
+
+Holesky 測試網將在 2025 年 9 月棄用。 質押營運者和基礎設施提供者應該使用 Hoodi 進行驗證者測試。
+
+- [Holesky 測試網關閉公告](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _以太坊基金會部落格,2025 年 9 月 1 日_
+- [Holesky 與 Hoodi 測試網更新](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) - _以太坊基金會部落格,2025 年 3 月 18 日_
+
+### 二層測試網 {#layer-2-testnets}
+
+[第二層 (L2)](/layer-2/) 是個統稱,描述一組特定的以太坊擴容方案。 二層網路是獨立的區塊鏈,拓展了以太坊並繼承了以太坊的安全保證。 二層網路測試網通常與以太坊公共測試網緊密相關。
#### Arbitrum Sepolia {#arbitrum-sepolia}
-[Arbitrum](https://arbitrum.io/) 的測試網。
+[Arbitrum](https://arbitrum.io/) 的一個測試網。
+
+##### 資源
+
+- [Etherscan](https://sepolia.arbiscan.io/)
+- [Blockscout](https://sepolia-explorer.arbitrum.io/)
##### 水龍頭
-- [Chainlink 水龍頭](https://faucets.chain.link/arbitrum-sepolia)
-- [Alchemy 水龍頭](https://www.alchemy.com/faucets/arbitrum-sepolia)
+- [Alchemy Arbitrum Sepolia 水龍頭](https://www.alchemy.com/faucets/arbitrum-sepolia)
+- [Chainlink Arbitrum Sepolia 水龍頭](https://faucets.chain.link/arbitrum-sepolia)
+- [ethfaucet.com Arbitrum Sepolia 水龍頭](https://ethfaucet.com/networks/arbitrum)
+- [QuickNode Arbitrum Sepolia 水龍頭](https://faucet.quicknode.com/arbitrum/sepolia)
#### Optimistic Sepolia {#optimistic-sepolia}
-[Optimism](https://www.optimism.io/) 的測試網。
+[Optimism](https://www.optimism.io/) 的一個測試網。
+
+##### 資源
+
+- [Etherscan](https://sepolia-optimistic.etherscan.io/)
+- [Blockscout](https://optimism-sepolia.blockscout.com/)
##### 水龍頭
-- [Chainlink 水龍頭](https://faucets.chain.link/optimism-sepolia)
-- [Coinbase 錢包水龍頭 | Optimism Sepolia](https://coinbase.com/faucets/optimism-sepolia-faucet)
- [Alchemy 水龍頭](https://www.alchemy.com/faucets/optimism-sepolia)
+- [Chainlink 水龍頭](https://faucets.chain.link/optimism-sepolia)
+- [ethfaucet.com Optimism Sepolia 水龍頭](https://ethfaucet.com/networks/optimism)
+- [測試網水龍頭](https://docs.optimism.io/builders/tools/build/faucets)
#### Starknet Sepolia {#starknet-sepolia}
-[Starknet](https://www.starknet.io) 的測試網。
+[Starknet](https://www.starknet.io) 的一個測試網。
+
+##### 資源
+
+- [Starkscan](https://sepolia.starkscan.co/)
##### 水龍頭
- [Alchemy 水龍頭](https://www.alchemy.com/faucets/starknet-sepolia)
+- [Blast Starknet Sepolia 水龍頭](https://blastapi.io/faucets/starknet-sepolia-eth)
+- [Starknet 水龍頭](https://starknet-faucet.vercel.app/)
-## 私人網路 {#private-networks}
+## 私有網路 {#private-networks}
-若節點未連接到公共網路 (即主網或測試網),則以太坊網路就是一個 私人網路。 在此情況下,私人僅表示保留或隔離,而非受保護或安全。
+如果一個以太坊網路的節點未連線至公共網路 (即主網或測試網),則該網路為私有網路。 在此情況下,私人僅表示保留或隔離,而非受保護或安全。
-### 發展網路 {#development-networks}
+### 開發網路 {#development-networks}
開發以太坊應用程式時,最好在部署前先在私人網路上執行,瞭解其運作情況。 類似於進行網頁開發時,在自己的電腦上建立本機伺服器,你可以建立本機區塊鏈實例來測試你的去中心化應用程式。 與公共測試網相比,這可以大幅提升迭代速度。
-有些專門輔助專案和工具可以使用。 深入瞭解[開發網路](/developers/docs/development-networks/)的資訊。
+有些專門輔助專案和工具可以使用。 深入了解[開發網路](/developers/docs/development-networks/)。
### 聯盟網路 {#consortium-networks}
@@ -124,12 +182,35 @@ Hoodi 是為測試驗證和質押而設計的測試網。 Hoodi 網路對於希
如果說公共以太坊網路是公共網際網路,那麼聯盟網路就是私有內部網路。
+## 為何以太坊測試網會以地鐵站命名? {#why-naming}
+
+許多以太坊測試網都以真實世界的地鐵站或火車站命名。 這個命名傳統很早就開始了,它反映了貢獻者曾經生活或工作過的全球城市。 它既具象徵意義、好記,又很實用。 就像測試網獨立於以太坊主網一樣,地鐵線路也與地面交通分開運行。
+
+### 常用與舊版測試網 {#common-and-legacy-testnets}
+
+- **Sepolia** - 希臘雅典一個有地鐵相連的社區。 目前用於智慧合約和去中心化應用程式的測試。
+- **Hoodi** - 以印度班加羅爾的 Hoodi 地鐵站命名。 用於驗證程式與協定升級測試。
+- **Goerli** _(已棄用)_ - 以德國柏林的 Görlitzer Bahnhof 站命名。
+- **Rinkeby** _(已棄用)_ - 以斯德哥爾摩一個有地鐵站的郊區命名。
+- **Ropsten** _(已棄用)_ - 指斯德哥爾摩的一個地區及過去的渡輪/地鐵總站。
+- **Kovan** _(已棄用)_ - 以新加坡的一個地鐵站命名。
+- **Morden** _(已棄用)_ - 以倫敦的一個地鐵站命名。 以太坊的第一個公共測試網。
+
+### 其他專用測試網 {#other-testnets}
+
+有些測試網是為短期或特定升級測試而建立,不一定以地鐵為主題:
+
+- **Holesky** _(已棄用)_ - 以布拉格的 Holešovice 站命名。 用於驗證程式測試;於 2025 年棄用。
+- **Kiln**、**Zhejiang**、**Shandong**、**Prater**、**Pyrmont**、**Olympic** _(皆已棄用)_ 與 **Ephemery** - 為合併、上海升級等升級模擬,或驗證程式實驗而專門打造。 有些名稱是地域性或主題性的,而非以地鐵為基礎。
+
+使用地鐵站名有助於開發者快速識別及記住測試網,而無需依賴數字鏈 ID。 這也反映了以太坊的文化:實用、全球化與以人為本。
+
## 相關工具 {#related-tools}
-- [Chainlist](https://chainlist.org/) _是將錢包與提供者連結到適當鏈 ID 與網路 ID 的以太坊虛擬機網路的清單_
-- [採用以太坊虛擬機 (EVM) 的鏈](https://github.com/ethereum-lists/chains) _Github 鏈中繼資料存放庫,支援 Chainlist_
+- [Chainlist](https://chainlist.org/) _以太坊虛擬機網路清單,用於將錢包和提供者連接到對應的鏈 ID 和網路 ID_
+- [基於 EVM 的鏈](https://github.com/ethereum-lists/chains) _為 Chainlist 提供支援的鏈元資料 GitHub 存放庫_
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [提案:可預測的以太坊測試網生命週期](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17)
-- [以太坊測試網的演進](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/)
+- [以太坊測試網的演變](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/)
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/archive-nodes/index.md
index cf9cb2e577a..64a16d2aa17 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/archive-nodes/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/archive-nodes/index.md
@@ -9,21 +9,21 @@ sidebarDepth: 2
## 先決條件 {#prerequisites}
-你應該瞭解[以太坊節點](/developers/docs/nodes-and-clients/)的概念,[其架構](/developers/docs/nodes-and-clients/node-architecture/)、[同步策略](/developers/docs/nodes-and-clients/#sync-modes)、[運行](/developers/docs/nodes-and-clients/run-a-node/)和[使用它們](/developers/docs/apis/json-rpc/)的實踐方法。
+您應該了解 [以太坊節點](/developers/docs/nodes-and-clients/) 的概念、[其架構](/developers/docs/nodes-and-clients/node-architecture/)、[同步策略](/developers/docs/nodes-and-clients/#sync-modes),以及 [運行](/developers/docs/nodes-and-clients/run-a-node/) 和 [使用它們](/developers/docs/apis/json-rpc/) 的方法。
## 什麼是歸檔節點
-要理解歸檔節點的重要性,讓我們先釐清「狀態」的概念。 以太坊可以被稱為_基於交易的狀態機_。 它包括了帳戶以及執行交易並改變帳戶狀態的應用程式。 有關每個帳戶和合約的全球數據儲存在一個稱為狀態的 字典樹資料庫中。 這由執行層 (EL) 用戶端處理,並包括:
+要理解歸檔節點的重要性,讓我們先釐清「狀態」的概念。 以太坊可以稱為_以交易為基礎的狀態機_。 它包括了帳戶以及執行交易並改變帳戶狀態的應用程式。 有關每個帳戶和合約的全球數據儲存在一個稱為狀態的 字典樹資料庫中。 這由執行層 (EL) 用戶端處理,並包括:
- 帳戶餘額和隨機數
- 合約代碼與儲存
-- 共識相關資料,例如質押存款合約
+- 共識相關資料,例如:質押存款合約
-為了與網路互動、驗證和產生新區塊,以太坊用戶端必須跟上最近的變化(鏈尖),因此需要知道當前狀態。 設定為全節點的執行層用戶端會驗證並跟隨網路的最新狀態,但只緩存過去的少數幾個狀態,例如與最後 128 個區塊相關的狀態,因此它可以處理鏈重組並快速存取最近的資料。 最近的狀態是所有用戶端需要用來驗證傳入交易和使用網路的資料。
+為了與網路互動、驗證和產生新區塊,以太坊用戶端必須跟上最近的變化(鏈尖),因此需要知道當前狀態。 設定為完整節點的執行層用戶端會驗證並追蹤網路的最新狀態,但只會快取過去的少數幾個狀態 (例如:與最近 128 個區塊相關的狀態),因此它可以處理鏈重組,並提供對近期資料的快速存取。 最近的狀態是所有用戶端需要用來驗證傳入交易和使用網路的資料。
你可以將狀態想像為給定區塊的瞬間網路快照,而將存檔視為歷史重播。
-歷史狀態可以安全地修剪,因為它們對網路的運作並不必要,而且用戶端保留所有過時資料是無用的。 存在於某個最近區塊(例如區塊頭之前的 128 個區塊)之前的狀態實際上已被丟棄。 全節點只保留歷史區塊鏈資料(區塊和交易)以及可供全節點用來根據請求重新產生較早狀態的偶然歷史快照。 它們透過在以太坊虛擬機中重新執行過去的交易來實現這一點,當所需的狀態距離最近的快照很遠時,這可能在計算上要求很高。
+歷史狀態可以安全地修剪,因為它們對網路的運作並不必要,而且用戶端保留所有過時資料是無用的。 在某個近期區塊 (例如:標頭前的 128 個區塊) 之前存在的狀態,實際上會被捨棄。 全節點只保留歷史區塊鏈資料(區塊和交易)以及可供全節點用來根據請求重新產生較早狀態的偶然歷史快照。 它們透過在以太坊虛擬機中重新執行過去的交易來實現這一點,當所需的狀態距離最近的快照很遠時,這可能在計算上要求很高。
然而,這意味著在全節點上存取歷史狀態會消耗大量的算力。 用戶端可能需要執行所有過去的交易並從創世塊計算一個歷史狀態。 歸檔節點透過不僅儲存最近的狀態,而且儲存每個區塊後建立的每個歷史狀態來解決這個問題。 它基本上是以更大的磁碟空間需求作為代價。
@@ -35,8 +35,8 @@ sidebarDepth: 2
狀態存檔的主要好處是可以快速存取歷史狀態查詢。 舉例來說,歸檔節點將即時返回以下結果:
-- _0x1337 帳戶在區塊 15537393 中的以太幣餘額是多少?_
-- _0x 合約在區塊 1920000 中的 0x 代幣餘額是多少?_
+- _0x1337... 帳戶的 ETH 餘額為何..._ _在區塊 15537393?_
+- _在區塊 1920000,合約 0x 中的代幣 0x 餘額是多少?_
如上所述,全節點會需要透過以太坊虛擬機執行以產生此資料,這會使用 CPU 並花費時間。 歸檔節點在磁碟上存取它們,且立即回應。 對一些特定基礎設施來說,這非常有用,例如:
@@ -46,33 +46,34 @@ sidebarDepth: 2
- 去中心化應用程式開發者
- 審計和合規
-也有各種免費的[服務](/developers/docs/nodes-and-clients/nodes-as-a-service/)可以存取歷史資料。 由於運行歸檔節點要求更高,因此這種存取往往受到限制,且只適用於偶爾存取。 如果你的專案需要持續存取歷史資料,你應該考慮運行一個自己的歸檔節點。
+也有各種免費的 [服務](/developers/docs/nodes-and-clients/nodes-as-a-service/) 能讓您存取歷史資料。 由於運行歸檔節點要求更高,因此這種存取往往受到限制,且只適用於偶爾存取。 如果你的專案需要持續存取歷史資料,你應該考慮運行一個自己的歸檔節點。
## 實作和使用
歸檔節點在此處表示由面向使用者的執行層用戶端提供的資料,因為它們處理狀態資料庫並提供 JSON-RPC 端點。 設定選項、同步時間和資料庫大小可能因用戶端而異。 詳細資訊請參考你的用戶端提供的文檔。
-在開始建立你的歸檔節點前,請先了解用戶端之間的差異,尤其是[硬體要求](/developers/docs/nodes-and-clients/run-a-node/#requirements)的部分。 多數用戶端沒有最佳化這個部分,且它們的存檔需要超過 12TB 的儲存空間。 與如 Erigon 的實作對比,Erigon 可以在低於 3TB 的空間儲存相同的資料,使其成為運行歸檔節點最有效率的方式。
+在開始運行您自己的存檔節點前,請先了解不同用戶端之間的差異,特別是各種 [硬體需求](/developers/docs/nodes-and-clients/run-a-node/#requirements)。 多數用戶端沒有最佳化這個部分,且它們的存檔需要超過 12TB 的儲存空間。 與如 Erigon 的實作對比,Erigon 可以在低於 3TB 的空間儲存相同的資料,使其成為運行歸檔節點最有效率的方式。
## 推薦的做法
-除了一般的[運行節點建議](/developers/docs/nodes-and-clients/run-a-node/)外,歸檔節點可能更注重硬體和維護。 考慮到 Erigon 的[關鍵功能](https://github.com/ledgerwatch/erigon#key-features),最實用的方法是使用 [Erigon](/developers/docs/nodes-and-clients/#erigon)用戶端實作。
+除了 [運行節點的一般建議](/developers/docs/nodes-and-clients/run-a-node/) 之外,存檔節點可能對硬體和維護有更高的要求。 考量到 Erigon 的 [主要功能](https://github.com/ledgerwatch/erigon#key-features),最實際的方法是使用 [Erigon](/developers/docs/nodes-and-clients/#erigon) 用戶端實作。
### 硬體
-永遠在用戶端文檔中確認滿足了特定模式的硬體要求。 對歸檔節點來說,最大的需求是磁碟空間。 取決於用戶端的不同,可能從 3TB 到 12TB 都有。 雖然硬碟被認為可能是儲存大量資料的更好辦法,但同步資料和不斷地更新鏈頭需要固態硬碟。 [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) 硬碟足夠好,但它要有可靠的品質,至少要 [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences)。 磁碟可以安裝在有足夠插槽的桌機或伺服器中。 這些專用設備適合需要長時間正常運行的節點。 在筆電上運行也是完全可行的,但便攜性將帶來額外的成本。
+永遠在用戶端文檔中確認滿足了特定模式的硬體要求。
+對歸檔節點來說,最大的需求是磁碟空間。 取決於用戶端的不同,可能從 3TB 到 12TB 都有。 雖然硬碟被認為可能是儲存大量資料的更好辦法,但同步資料和不斷地更新鏈頭需要固態硬碟。 [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) 硬碟已足夠,但應具備可靠的品質,至少是 [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences) 等級。 磁碟可以安裝在有足夠插槽的桌機或伺服器中。 這些專用設備適合需要長時間正常運行的節點。 在筆電上運行也是完全可行的,但便攜性將帶來額外的成本。
-所有的資料都需要放入一個磁碟區中,所以磁碟必須合併,如 [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) 或 LVM。 或許 [ZFS](https://en.wikipedia.org/wiki/ZFS) 也是值得考慮的選擇,因為它支援「寫入時複製」,確保了資料正確寫入磁碟而沒有任何低階錯誤。
+所有資料都必須放在單一磁碟區中,因此必須合併磁碟,例如:使用 [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) 或 LVM。 或許也值得考慮使用 [ZFS](https://en.wikipedia.org/wiki/ZFS),因為它支援「寫入時複製」,可確保資料正確寫入磁碟,不會有任何低階錯誤。
-關於更多避免資料庫損毀的穩定安全方法,特別是專業設定中,如果你的系統支援,可以考慮 [ECC 記憶體](https://en.wikipedia.org/wiki/ECC_memory)。 RAM 的大小一般建議和全節點一樣,但更多的 RAM 可以加速同步速度。
+為了在防止意外的資料庫損壞方面獲得更高的穩定性和安全性,特別是在專業設定中,如果您的系統支援,請考慮使用 [ECC 記憶體](https://en.wikipedia.org/wiki/ECC_memory)。 RAM 的大小一般建議和全節點一樣,但更多的 RAM 可以加速同步速度。
在初始同步時,在歸檔模式的用戶端會執行自創世塊以來的每個交易。 執行速度大多時候受到 CPU 限制,所以更快的 CPU 對減少初始同步時間有幫助。 在平均水準的消費級電腦上,初始同步可能會長達一個月。
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊全節點與歸檔節點](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode,2020 年 9 月_
-- [建立你自己的以太坊歸檔節點](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush,2021 年 8 月_
-- [如何設定 Erigon、Erigon 的 RPC 和 TrueBlocks(抓取和應用程式介面)作為服務](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _ - Magnus Hansson,2022 年 9 月更新_
+- [以太坊完整節點與存檔節點比較](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode,2022 年 9 月_
+- [建立您自己的以太坊存檔節點](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush,2021 年 8 月_
+- [如何將 Erigon、Erigon 的 RPC 與 TrueBlocks (抓取與 API) 設定為服務](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson,2022 年 9 月更新_
## 相關主題 {#related-topics}
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/bootnodes/index.md
index 794f763ab75..495e50162fa 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/bootnodes/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/bootnodes/index.md
@@ -6,26 +6,26 @@ lang: zh-tw
當一個新節點加入以太坊網路時,它需要連接至網路上已經存在的其他節點,以找到新的對等節點。 這些以太坊網路的進入點被稱為引導節點。 用戶端中通常有個硬編碼進去的引導節點清單。 這些引導節點通常由以太坊基金會的 DevOps 團隊或客戶團隊自身負責運行。 注意,引導節點與靜態節點不同。 靜態節點會被多次呼叫,而引導節點只有在沒有足夠的節點可以連接,或節點需要引導一些新連接時才會被呼叫。
-## 連接至引導節點 {#connect-to-a-bootnode}
+## 連線至引導節點 {#connect-to-a-bootnode}
-大部分的用戶端中都有個內建的引導節點清單,但你也可能會想運行自己的引導節點,或者使用沒在用戶端硬編碼清單上的引導節點。 這種情況下,你可以在啟動用戶端時指定引導節點,如下所示(這個是 Geth 的例子,請查看你的用戶端文檔):
+大部分的用戶端都有內建的引導節點清單,但您可能也想運行自己的引導節點,或使用一個不在用戶端硬編碼清單上的引導節點。 這種情況下,你可以在啟動用戶端時指定引導節點,如下所示(這個是 Geth 的例子,請查看你的用戶端文檔):
```
-geth --bootnodes "enode://@:"
+geth --bootnodes \
```
-## 運行引導節點 {#run-a-bootnode}
+## 執行啟動節點 {#run-a-bootnode}
-引導節點是不在 NAT([網路位址轉譯](https://www.geeksforgeeks.org/network-address-translation-nat/))後的全節點。 只要可以公開可用,每個全節點都可以作為引導節點。
+啟動節點是沒有位於 [網路位址轉換 (NAT)](https://www.geeksforgeeks.org/network-address-translation-nat/) 後方的完整節點。 只要可以公開可用,每個全節點都可以作為引導節點。
-當你啟動節點時,它會記錄你的 [enode](/developers/docs/networking-layer/network-addresses/#enode),這是可供其他人連接你的節點的公開識別碼。
+當你啟動節點時,它應會記錄你的 [enode](/developers/docs/networking-layer/network-addresses/#enode),這是其他人可用來連接你節點的公開識別碼。
通常每次啟動都會重新產生 enode,所以請務必查看你的用戶端文檔,以了解如何為你的引導節點產生永久的 enode。
要成為一個好的引導節點,增加該節點能連接的對等節點最大數量是個好辦法。 運行一個有許多對等節點的引導節點會顯著增加帶寬需求。
-## 可用的引導節點 {#available-bootnodes}
+## 可用的啟動節點 {#available-bootnodes}
-Go-ethereum 內建的引導節點清單可以在[此處](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23)查看。 這些引導節點由以太坊基金會和 go-ethereum 團隊維護。
+go-ethereum 內建的啟動節點清單可以在[這裡](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23)找到。 這些引導節點由以太坊基金會和 go-ethereum 團隊維護。
還有由志願者維護的引導節點的其他清單。 請確認至少包含一個官方的引導節點,否則你可能會受到日蝕攻擊。
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/client-diversity/index.md
index 47f2db1d5bb..be78714209c 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/client-diversity/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/client-diversity/index.md
@@ -1,5 +1,5 @@
---
-title: 用戶的多樣化
+title: 用戶端多樣化
description: 對以太坊用戶端多樣性的重要性的高階解釋。
lang: zh-tw
sidebarDepth: 2
@@ -7,81 +7,100 @@ sidebarDepth: 2
以太坊節點的行為是由它所運行的用戶端軟體控制。 有許多生產等級的以太坊用戶端,每個用戶端都由不同團隊以不同程式語言開發和維護。 用戶端是以相同規範建立的,以確保用戶端彼此可以無縫互相通訊,且具有相同的功能及提供相等的使用者體驗。 然而,目前節點間的用戶端分佈仍然不夠均勻,無法充分發揮這種網路強化的潛力。 理想上,使用者大致平均分配到各個用戶端,以為網路帶來儘可能多的用戶端多樣性。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-如果你還不了解節點和用戶端是什麼,請先閱讀[節點和用戶端](/developers/docs/nodes-and-clients/)。 [執行](/glossary/#execution-layer)和[共識](/glossary/#consensus-layer)層在術語表中有定義。
+如果你還不了解節點和用戶端是什麼,請參閱[節點和用戶端](/developers/docs/nodes-and-clients/)。 詞彙表中定義了[執行層](/glossary/#execution-layer)和[共識層](/glossary/#consensus-layer)。
## 為什麼會有多樣化的用戶端呢? {#why-multiple-clients}
-存在多種獨立開發和維護的用戶端是有利的,因為用戶端多樣性使網路應對攻擊和錯誤時更有彈性。 多種用戶端是以太坊獨有的優勢 - 其他區塊鏈依賴單一用戶端的正確性。 然而,只擁有多種用戶端還不夠,它們必須被社群採用,且活躍的節點在它們間需要相對平均分佈。
+存在多種獨立開發和維護的用戶端是有利的,因為用戶端多樣性使網路應對攻擊和錯誤時更有彈性。 多種用戶端是以太坊獨有的優勢 - 其他區塊鏈依賴單一用戶端的正確性。 然而,僅僅擁有多個可用的用戶端是不夠的,它們必須被社群採用,且全部的活躍節點必須相對平均地分佈在它們之間。
## 為什麼用戶端多樣化重要? {#client-diversity-importance}
有許多獨立開發和維護的用戶端對去中心化網路的健康十分重要。 讓我們探索一下其中原因。
-### 錯誤 {#bugs}
+### 程式錯誤 {#bugs}
當單一用戶端中存在錯誤,如果該用戶端只代表少數以太坊節點時,對網路的風險較小。 節點在許多用戶端上分佈大致均勻,大多數用戶端遭受共同問題的可能性很小,網路因此更加穩健。
-### 對攻擊的抗性 {#resilience}
+### 抵禦攻擊的韌性 {#resilience}
-用戶端多樣性提供了攻擊抗性。 舉例來說,一個[欺騙特定用戶端](https://twitter.com/vdWijden/status/1437712249926393858)切換到特定分支鏈的攻擊不太可能成功,因為其他的用戶端不太可能以相同方式被利用,且規範鏈維持正常不變。 低用戶端多樣性會增加主導用戶端被駭的風險。 用戶端多樣性已被證明是抵禦網路上惡意攻擊的重要防禦,舉例來說 2016 年的上海阻斷服務攻擊是可能成功的,因為攻擊者能夠欺騙主導用戶端 (Geth) 在每個區塊中執行數千萬次的慢速磁碟讀寫操作。 因為替代用戶端同時在線且沒有同樣的漏洞,以太坊才得以在修復 Geth 的漏洞期間抵禦攻擊並持續運行。
+用戶端多樣性提供了攻擊抗性。 舉例來說,一種[欺騙特定用戶端](https://twitter.com/vdWijden/status/1437712249926393858)到特定鏈分支的攻擊不太可能成功,因為其他用戶端不太可能以同樣的方式被利用,而且正統鏈仍然完好無損。 低用戶端多樣性會增加主導用戶端被駭的風險。 用戶端多樣性已被證明是抵禦網路上惡意攻擊的重要防禦,舉例來說 2016 年的上海阻斷服務攻擊是可能成功的,因為攻擊者能夠欺騙主導用戶端 (Geth) 在每個區塊中執行數千萬次的慢速磁碟讀寫操作。 因為替代用戶端同時在線且沒有同樣的漏洞,以太坊才得以在修復 Geth 的漏洞期間抵禦攻擊並持續運行。
-### 權益證明最終確定性 {#finality}
+### 權益證明的最終性 {#finality}
超過 33% 的以太坊節點共識用戶端中都存在的錯誤可能會阻止共識層的最終確定,這表示使用者沒辦法相信交易在某個時刻不會被撤銷或更改。 這對建立在以太坊上的許多應用程式是非常大的問題,尤其是去中心化金融。
- 更糟糕的是,在兩三個主流用戶端中的重大錯誤可能會導致鏈錯誤地分叉和最終確定,使大量的驗證者被卡在無效的鏈上。 如果這些驗證者想重新加入正確的鏈,它們可能會面臨罰沒或緩慢且昂貴的自願提款和重新啟用流程。 罰沒的規模與有罪節點的數量成正比,其中三分之二的主流節點會被罰沒最高金額(32 以太幣)。
+ 更糟的是,擁有三分之二多數的用戶端如果存在一個嚴重錯誤,可能導致鏈錯誤地分裂和敲定,造成大量驗證者卡在無效鏈上。 如果這些驗證者想重新加入正確的鏈,它們可能會面臨罰沒或緩慢且昂貴的自願提款和重新啟用流程。 罰沒的規模與有罪節點的數量成正比,其中三分之二的主流節點會被罰沒最高金額(32 以太幣)。
雖然這些情況不太可能發生,以太坊生態系可以透過平均分佈用戶端至各個活躍節點以降低風險。 理想上,不會有共識用戶端超過總節點數的 33%。
-### 共同的責任 {#responsibility}
+### 共同責任 {#responsibility}
擁有主流用戶端也有人力成本問題。 它為小型開發團隊帶來了過多壓力和責任。 越低的用戶端多樣性,會使得開發者維護主流用戶端的負擔更重。 將此責任分散至多個團隊,對以太坊網路上的節點和網路上的開發者的健康都有益。
## 目前的用戶端多樣性 {#current-client-diversity}
- _圖表資料來自 [ethernodes.org](https://ethernodes.org) 和 [ clientdiversity.org](https://clientdiversity.org/)_
+### 執行用戶端 {#execution-clients-breakdown}
-上方的兩個圓餅圖顯示了目前執行層和共識層用戶端上的節點多樣性的快照(2022 年 1 月撰文時)。 執行層由 [Geth](https://geth.ethereum.org/) 壓倒性地主導,[Open Ethereum](https://openethereum.github.io/) 排名第二,[Erigon](https://github.com/ledgerwatch/erigon) 第三,[Nethermind](https://nethermind.io/) 第四,其他用戶端相加還不到整個網路的 1%。 最常在共識層上被使用的用戶端 - [Prysm](https://prysmaticlabs.com/#projects) - 的主導地位不及 Geth,但還是佔了超過整個網路的 60%。 [Lighthouse](https://lighthouse.sigmaprime.io/) 和 [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) 分別佔約 20% 和 14%,其他用戶端則很少被使用。
+
-執行層資料是在 2022 年 1 月 23 日從 [Ethernodes](https://ethernodes.org) 取得的。 共識層的資料是從 [Michael Sproul](https://github.com/sigp/blockprint) 取得的。 共識層資料較難取得,因為共識層用戶端並不總是有可用於識別它們的明確足跡。 該資料是使用分類演算法產生的,有時候會把一些小眾用戶端搞混(點按[此處](https://twitter.com/sproulM_/status/1440512518242197516)以獲得更多資訊)。 上圖中,這些不明確的分類使用了「/」或標籤(例如 Nimbus/Teku)標示。 儘管如此,很顯然主要網路都在運行 Prysm。 此資料是一組固定區塊的快照(在這個例子中是時隙 2048001 至 2164916 中的信標區塊),Prysm 的主導地位有時更高,超過了 68%。 儘管只是快照,但圖中的數值提供了我們目前整體用戶端多樣性狀態的良好認識。
+### 共識用戶端 {#consensus-clients-breakdown}
-現在已可在 [clientdiversity.org](https://clientdiversity.org/) 上查看共識層的最新用戶端多樣性資料。
+
-## 執行層 {#execution-layer}
-
-直到現在,關於用戶端多樣性的討論主要集中在共識層。 然而,執行用戶端 [Geth](https://geth.ethereum.org) 目前約佔所有節點的 85%。 這個比例問題很大,與共識用戶端的原因一樣。 舉例來說,Geth 中影響交易處理或建立執行有效負載的錯誤可能會導致共識用戶端最終確定有問題或錯誤的交易。 因此,如果執行用戶端分佈狀況更均勻,以太坊將更加健康,理想情況下不該有用戶端網路佔比超過 33%。
-
-## 使用小眾用戶端 {#use-minority-client}
-
-解決用戶端多樣性需要的不只是個人使用者選擇小眾用戶端 - 它還需要挖礦/驗證者池及主要去中心化應用程式和交易所等機構更換用戶端。 然而,所有使用者都可以儘自己的一份力量,以糾正目前的不平衡,並讓所有可用的以太坊軟體使用分佈正常化。 合併後,所有節點營運者都需要運行執行用戶端和共識用戶端。 選擇以下推薦的用戶端組合,可幫助提升用戶端多樣性。
-
-### 執行客戶 {#execution-clients}
+此圖表可能已過時 — 請前往 [ethernodes.org](https://ethernodes.org) 和 [clientdiversity.org](https://clientdiversity.org) 取得最新資訊。
-[Besu](https://www.hyperledger.org/use/besu)
+上方的兩個圓餅圖顯示了執行層和共識層目前用戶端多樣性的快照(撰寫於 2025 年 10 月)。 用戶端多樣性多年來有所改善,執行層中 [Geth](https://geth.ethereum.org/) 的主導地位已見減弱,[Nethermind](https://www.nethermind.io/nethermind-client) 緊隨其後,[Besu](https://besu.hyperledger.org/) 第三,[Erigon](https://github.com/ledgerwatch/erigon) 第四,而其他用戶端則佔不到網路的 3%。 共識層最常用的用戶端——[Lighthouse](https://lighthouse.sigmaprime.io/)——與第二常用的用戶端非常接近。 [Prysm](https://prysmaticlabs.com/#projects) 和 [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) 分別佔約 31% 和約 14%,其他用戶端則很少被使用。
-[Nethermind](https://downloads.nethermind.io/)
+執行層的資料於 2025 年 10 月 26 日從 [supermajority.info](https://supermajority.info/) 取得。 共識用戶端的資料是從 [Michael Sproul](https://github.com/sigp/blockprint) 取得的。 共識層資料較難取得,因為共識層用戶端並不總是有可用於識別它們的明確足跡。 此資料是透過一種分類演算法產生的,該演算法有時會混淆一些小眾用戶端(詳情請見[此處](https://twitter.com/sproulM_/status/1440512518242197516))。 在上方的圖表中,這些模糊的分類是採用二選一的標籤處理 (例如 Nimbus/Teku)。 儘管如此,很顯然主要網路都在運行 Prysm。 儘管只是快照,但圖中的數值提供了我們目前整體用戶端多樣性狀態的良好認識。
-[Erigon](https://github.com/ledgerwatch/erigon)
+關於共識層用戶端多樣性的最新資料,現已公布在 [clientdiversity.org](https://clientdiversity.org/)。
-[Go-Ethereum](https://geth.ethereum.org/)
+## 執行層 {#execution-layer}
-### 共識用戶端 {#consensus-clients}
+直到現在,關於用戶端多樣性的討論主要集中在共識層。 然而,執行用戶端 [Geth](https://geth.ethereum.org) 目前約佔所有節點的 85%。 這個比例問題很大,與共識用戶端的原因一樣。 舉例來說,Geth 中影響交易處理或建立執行有效負載的錯誤可能會導致共識用戶端最終確定有問題或錯誤的交易。 因此,如果執行用戶端分佈狀況更均勻,以太坊將更加健康,理想情況下不該有用戶端網路佔比超過 33%。
-[Nimbus](https://nimbus.team/)
+## 使用小眾用戶端 {#use-minority-client}
-[Lighthouse](https://github.com/sigp/lighthouse)
+解決用戶端多樣性需要的不只是個人使用者選擇小眾用戶端 - 它還需要驗證者池及主要去中心化應用程式和交易所等機構更換用戶端。 然而,所有使用者都可以儘自己的一份力量,以糾正目前的不平衡,並讓所有可用的以太坊軟體使用分佈正常化。 合併後,所有節點營運者都需要運行執行用戶端和共識用戶端。 選擇以下推薦的用戶端組合,可幫助提升用戶端多樣性。
-[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
+### 執行用戶端 {#execution-clients}
-[Lodestar](https://github.com/ChainSafe/lodestar)
+- [Besu](https://www.hyperledger.org/use/besu)
+- [Nethermind](https://downloads.nethermind.io/)
+- [Erigon](https://github.com/ledgerwatch/erigon)
+- [Go-Ethereum](https://geth.ethereum.org/)
+- [Reth](https://reth.rs/)
-[Prysm](https://prysm.offchainlabs.com/docs/)
+### 共識用戶端 {#consensus-clients}
-[Grandine](https://docs.grandine.io/)
+- [Nimbus](https://nimbus.team/)
+- [Lighthouse](https://github.com/sigp/lighthouse)
+- [Teku](https://consensys.io/teku)
+- [Lodestar](https://github.com/ChainSafe/lodestar)
+- [Prysm](https://prysm.offchainlabs.com/docs/)
+- [Grandine](https://docs.grandine.io/)
-技術性使用者可以透過為小眾用戶端撰寫更多教學和文檔,並鼓勵其節點營運的對等節點從主導用戶端遷出,以幫助加速此流程。 [clientdiversity.org](https://clientdiversity.org/) 上有切換到小眾共識用戶端的指南。
+技術性使用者可以透過為小眾用戶端撰寫更多教學和文檔,並鼓勵其節點營運的對等節點從主導用戶端遷出,以幫助加速此流程。 關於如何切換至小眾共識用戶端的指南,可在 [clientdiversity.org](https://clientdiversity.org/) 上找到。
## 用戶端多樣性儀表板 {#client-diversity-dashboards}
@@ -90,22 +109,24 @@ sidebarDepth: 2
**共識層:**
- [Rated.network](https://www.rated.network/)
-- [clientdiversity.org](https://clientdiversity.org/) **執行層:**
+- [clientdiversity.org](https://clientdiversity.org/)
+
+**執行層:**
- [supermajority.info](https://supermajority.info//)
- [Ethernodes](https://ethernodes.org/)
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊共識層上的用戶端多樣性](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
-- [以太坊合併:運行主流用戶端需自行承擔風險!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest,2022 年 3 月 24 日_
+- [以太坊共識層的用戶端多樣性](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
+- [以太坊合併:執行多數用戶端,後果自負!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest,2022 年 3 月 24 日_
- [用戶端多樣性的重要性](https://our.status.im/the-importance-of-client-diversity/)
- [以太坊節點服務清單](https://ethereumnodes.com/)
-- [用戶端多樣性的「五個為什麼」](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08)
-- [以太坊多樣性及如何解決 (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
+- [用戶端多樣性問題的「五個為什麼」](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08)
+- [以太坊的多樣性以及如何解決 (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
- [clientdiversity.org](https://clientdiversity.org/)
## 相關主題 {#related-topics}
-- [運行以太坊節點](/run-a-node/)
-- [節點與用戶端](/developers/docs/nodes-and-clients/)
+- [執行一個以太坊節點](/run-a-node/)
+- [節點和用戶端](/developers/docs/nodes-and-clients/)
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/index.md
index 65fc363137f..c746b3cc7b7 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/index.md
@@ -7,9 +7,9 @@ sidebarDepth: 2
以太坊是一個由許多電腦(稱為節點)組成的分散式網路,這些節點運行能夠驗證區塊和交易資料的軟體。 這些軟體必須於你的電腦上運行,將電腦轉換成以太坊節點。 一個節點由兩個獨立的軟體(稱為「用戶端」)組成。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在深入研究並執行屬於你的以太坊用戶端實例之前,你應該瞭解點對點網路的概念和[以太坊虛擬機基礎知識](/developers/docs/evm/)。 請參閱[以太坊簡介](/developers/docs/intro-to-ethereum/)。
+在深入研究並執行屬於你的以太坊用戶端實例之前,你應該瞭解點對點網路的概念和[以太坊虛擬機基礎知識](/developers/docs/evm/)。 請查看我們的[以太坊簡介](/developers/docs/intro-to-ethereum/)。
如果你對節點這個主題還很陌生,推薦你首先查看我們適合使用者的[運行以太坊節點](/run-a-node)簡介。
@@ -20,41 +20,44 @@ sidebarDepth: 2
- 執行用戶端(又稱為執行引擎,EL 用戶端或舊稱為 以太坊 1 用戶端)監聽網路上廣播的新交易,在以太坊虛擬機器 (EVM) 中執行交易,並保存所有目前以太坊資料的最新狀態和資料庫。
- 共識用戶端(又稱為信標鏈節點、CL 用戶端或舊稱為以太坊 2 用戶端)執行權益證明共識演算法,使網路能夠依據來自執行用戶端的驗證過的資料達成一致。 此外,還有第三個軟體,稱為「驗證者」;驗證者可以被新增到共識用戶端中,讓節點能參與保護網路安全。
-這些用戶端共同運作以追蹤以太坊區塊鏈的頭部並使用戶可以和以太坊網路互動。 這種多個軟體協同工作的模組化設計稱為[封裝複雜性](https://vitalik.eth.limo/general/2022/02/28/complexity.html)。 此方法可以更簡單地無縫執行[合併](/roadmap/merge),讓用戶端軟體更容易維運和開發,並能重複利用個別的用戶端,例如在[二層網路生態系統](/layer-2/)中使用。
+這些用戶端共同運作以追蹤以太坊區塊鏈的頭部並使用戶可以和以太坊網路互動。 這種多個軟體協同工作的模組化設計稱為[封裝複雜性](https://vitalik.eth.limo/general/2022/02/28/complexity.html)。 此方法可以更簡單地無縫執行[合併](/roadmap/merge),讓用戶端軟體更容易維運和開發,並能重複利用個別的用戶端,例如在[第 2 層生態系統](/layer-2/)中使用。
- 關聯的執行用戶端和共識用戶端的簡化示意圖。
+
+執行用戶端與共識用戶端配對的簡化圖。
-### 用戶的多樣化 {#client-diversity}
+### 用戶端多樣性 {#client-diversity}
-[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)和[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients)存在於由不同團隊開發的多種程式語言中。
+[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)和[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients)都由不同的團隊以多種程式語言開發。
-多種用戶端實作可以降低對單一程式碼庫的依賴,從而使網路更強大。 理想目標是達到多樣性,沒有任一用戶端在網路中佔有主導地位,從而消除潛在的單點故障。 語言多樣化也可以吸引更廣泛的開發者社群,並讓他們可以用自己偏好的語言來建立整合。
+多種用戶端實作可以降低對單一程式碼庫的依賴,從而使網路更強大。 理想目標是達到多樣性,沒有任一用戶端在網路中佔有主導地位,從而消除潛在的單點故障。
+語言多樣化也可以吸引更廣泛的開發者社群,並讓他們可以用自己偏好的語言來建立整合。
-瞭解更多關於[用戶端多樣化](/developers/docs/nodes-and-clients/client-diversity/)的資訊。
+深入瞭解[用戶端多元性](/developers/docs/nodes-and-clients/client-diversity/)。
這些實作的共通點就是都遵循一套統一規範。 這些規範決定以太坊網路和區塊鏈的運作方式。 所有的技術細節都已經定義,規範如下:
- 最初的[以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)
- [執行規範](https://github.com/ethereum/execution-specs/)
- [共識規範](https://github.com/ethereum/consensus-specs)
-- 各種[網路升級](/ethereum-forks/)中實作的[以太坊改善提議](https://eips.ethereum.org/)
+- 在各種[網路升級](/ethereum-forks/)中實施的 [EIP](https://eips.ethereum.org/)
### 追蹤網路中的節點 {#network-overview}
多種追蹤器提供以太坊網路中節點的即時概覽。 必須注意,由於去中心化網路的特性,這些爬蟲僅能提供有限的網路資訊,並且可能會報告不同的結果。
-- Etherscan 提供的[節點地圖](https://etherscan.io/nodetracker)
-- Bitfly 提供的[Ethernodes](https://ethernodes.org/)
-- Chainsafe 提供的 [Nodewatch](https://www.nodewatch.io/),爬取共識節點
-- [Monitoreth](https://monitoreth.io/) – 由 MigaLabs 開發的分散式網路監控工具
+- Etherscan 的[節點地圖](https://etherscan.io/nodetracker)
+- Bitfly 的 [Ethernodes](https://ethernodes.org/)
+- Chainsafe 的 [Nodewatch](https://www.nodewatch.io/),爬取共識節點
+- [Monitoreth](https://monitoreth.io/) - MigaLabs 開發的分散式網路監控工具
+- [每週網路健康報告](https://probelab.io) - 由 ProbeLab 提供,使用 [Nebula crawler](https://github.com/dennis-tra/nebula) 和其他工具
## 節點類型 {#node-types}
-如果你想[運行你自己的節點](/developers/docs/nodes-and-clients/run-a-node/),你需要瞭解:不同類型的節點以不同的方式消耗資料。 事實上,用戶端可以運行三種類型的節點:輕節點、全節點和歸檔節點。 還可以選擇不同的同步策略,從而達成更快的同步時間。 同步是指取得以太坊最新狀態資訊的速度。
+如果你想[執行你自己的節點](/developers/docs/nodes-and-clients/run-a-node/),你應該了解節點有多種類型,它們消耗資料的方式也不同。 事實上,用戶端可以運行三種類型的節點:輕節點、全節點和歸檔節點。 還可以選擇不同的同步策略,從而達成更快的同步時間。 同步是指取得以太坊最新狀態資訊的速度。
-### 全節點 {#full-node}
+### 完整節點 {#full-node}
-全節點對區塊鏈上的區塊逐一驗證,包括下載和驗證每個區塊的區塊體和狀態資料。 全節點有不同的類型 - 一些全節點會從初始區塊開始,驗證整個區塊鏈歷史上的每一個區塊。 另外一些全節點,僅從較近期的、它們認為有效的區塊開始驗證(例如:Geth 的 「快照同步」)。 不論從哪裡開始,全節點僅保留相對近期的資料(通常是最新的 128 個區塊)的本機副本,允許刪除較舊的資料以節省磁碟空間。 舊的資料可以在需要時重新生成。
+全節點對區塊鏈上的區塊逐一驗證,包括下載和驗證每個區塊的區塊體和狀態資料。 全節點有不同的類型 - 一些全節點會從初始區塊開始,驗證整個區塊鏈歷史上的每一個區塊。 其他節點則從它們信任為有效的較新區塊開始驗證 (例如 Geth 的「快照同步」)。 不論從哪裡開始,全節點僅保留相對近期的資料(通常是最新的 128 個區塊)的本機副本,允許刪除較舊的資料以節省磁碟空間。 舊的資料可以在需要時重新生成。
- 儲存完整區塊鏈資料(儘管會定期修剪,全節點並不會將所有狀態資料儲存回創世塊)
- 參與區塊驗證,驗證所有區塊和狀態。
@@ -65,60 +68,61 @@ sidebarDepth: 2
從初始區塊開始驗證每一個區塊並且從不刪除任何已下載資料的全節點,稱為歸檔節點。
-- 儲存全節點中保存的所有內容並建立歷史狀態檔案。 歸檔節點可供查詢鏈上資料,像是某個帳戶在第 #4,000,000 區塊的餘額,或是簡單可靠的測試一組自己的交易而無須使用追蹤功能來挖掘這些資料。
+- 儲存全節點中保存的所有內容並建立歷史狀態檔案。 歸檔節點可供查詢鏈上資料,像是某個帳戶在第 #4,000,000 區塊的餘額,或是簡單可靠的測試一組自己的交易而無須使用追蹤功能來驗證這些資料。
- 這些資料量以兆位元為單位,因此歸檔節點對於一般使用者來說較沒有吸引力,但是對於區塊瀏覽器、錢包服務商、鏈分析則十分方便。
以檔案以外的任何模式同步用戶端都會導致區塊鏈資料被修剪。 這意味著,沒有所有歷史狀態的存檔,但全節點能夠按需建立該存檔。
-瞭解更多關於[歸檔節點](/developers/docs/nodes-and-clients/archive-nodes)的資訊。
+深入瞭解[歸檔節點](/developers/docs/nodes-and-clients/archive-nodes)。
-### 輕節點 {#light-node}
+### 輕量節點 {#light-node}
-相較於下載所有的區塊,輕節點僅下載區塊頭。 這些區塊頭包含了區塊內容的摘要資訊。 輕節點所需要的任何其他資訊,都須向全節點發送請求來取得。 然後,輕節點可以根據區塊頭中的狀態根獨立驗證接收的資料。 輕節點讓使用者能參與以太坊網路,而無需運行全節點所需的強大的硬體或高帶寬。 最終,輕節點可能可以在行動電話或是嵌入式裝置中運行。 輕節點並不參與共識(意即不能成為礦工/驗證者),但是可以存取以太坊區塊鏈,並具有與全節點相同的功能和安全保證。
+相較於下載所有的區塊,輕節點僅下載區塊頭。 這些區塊頭包含了區塊內容的摘要資訊。 輕節點所需要的任何其他資訊,都須向全節點發送請求來取得。 然後,輕節點可以根據區塊頭中的狀態根獨立驗證接收的資料。 輕節點讓使用者能參與以太坊網路,而無需運行全節點所需的強大的硬體或高帶寬。 最終,輕節點可能可以在行動電話或是嵌入式裝置中運行。 輕量節點不參與共識 (即它們不能成為驗證者),但它們可以存取以太坊區塊鏈,其功能和安全保障與完整節點相同。
-輕量用戶端是以太坊積極發展的領域,我們預期很快可以看到共識層和執行層的輕量用戶端。 也有一些潛在的路徑可以透過[廣播網路](https://www.ethportal.net/)提供輕量用戶端資料。 這是有利的,因為廣播網路可以支援輕節點網路,而不需要全節點來處理請求。
+輕量用戶端是以太坊積極發展的領域,我們預期很快可以看到共識層和執行層的輕量用戶端。
+也有一些潛在的途徑可以透過 [gossip 網路](https://www.ethportal.net/) 提供輕量用戶端資料。 這是有利的,因為廣播網路可以支援輕節點網路,而不需要全節點來處理請求。
-以太坊目前還不支援大量的輕節點,但輕節點支援是預計在不久的將來會快速發展的領域。 特別像是 [Nimbus](https://nimbus.team/)、[Helios](https://github.com/a16z/helios) 及 [LodeStar](https://lodestar.chainsafe.io/) 等用戶端,目前都著重聚焦在輕節點。
+以太坊目前還不支援大量的輕節點,但輕節點支援是預計在不久的將來會快速發展的領域。 特別是像 [Nimbus](https://nimbus.team/)、[Helios](https://github.com/a16z/helios) 和 [LodeStar](https://lodestar.chainsafe.io/) 等用戶端目前都非常專注於輕量節點。
## 運行以太坊節點之理由? {#why-should-i-run-an-ethereum-node}
運行節點可以讓你直接、去信任並私密地使用以太坊,同時透過保持網路強健和去中心化來支持以太坊網路。
-### 對你之好處 {#benefits-to-you}
+### 對你的好處 {#benefits-to-you}
運行自己的節點讓你可以透過私密、自給自足和去信任的方式來使用以太坊。 你無須信任網路,因為你可以透過你的用戶端驗證資料。 「不要信任,要驗證」是流行的區塊鏈口號。
- 你的節點依據共識規則自行驗證所有交易和區塊。 這意味著你不必依賴或完全信任網路中的任何其他節點。
-- 你可以將自己的以太坊錢包與自己的節點一起使用。 你可以更安全和私密地使用去中心化應用程式,而不需要洩漏你的地址和餘額給中介機構。 一切都可以透過你的用戶端核實。 [MetaMask](https://metamask.io)、[Frame](https://frame.sh/) 和[許多其他錢包](/wallets/find-wallet/)都有提供遠端程序呼叫匯入,讓他們可以使用你的節點。
+- 你可以將自己的以太坊錢包與自己的節點一起使用。 你可以更安全和私密地使用去中心化應用程式,而不需要洩漏你的地址和餘額給中介機構。 一切都可以透過你的用戶端核實。 [MetaMask](https://metamask.io)、[Frame](https://frame.sh/) 和[許多其他錢包](/wallets/find-wallet/)都提供 RPC 匯入功能,讓它們可以使用你的節點。
- 你可以運行並自託管其他依賴以太坊資料的服務。 例如:信標鏈驗證者、諸如二層網路的軟體、基礎設施、區塊瀏覽器、支付處理商等等。
-- 你可以提供自己的自訂[遠端程序呼叫端點](/developers/docs/apis/json-rpc/)。 你甚至可以公開提供這些端點給社群,以協助他們避開大型中心化提供者。
-- 你可以透過**行程間通訊 (IPC)** 來連線到自己的節點,或者你可以重新編寫節點,使其能夠載入你的外掛程式。 這樣可以降低延遲,會帶來諸多好處,例如利用 web3 函式庫處理大量資料時,或是當你需要盡可能快速替換交易時(例如:預先交易)。
-- 你可以直接質押 ETH 來維護網路安全並賺取獎勵。 請參考[單獨質押](/staking/solo/)瞭解更多。
+- 你可以提供自己的自訂 [RPC 端點](/developers/docs/apis/json-rpc/)。 你甚至可以公開提供這些端點給社群,以協助他們避開大型中心化提供者。
+- 你可以透過**行程間通訊 (IPC)** 連線到你的節點,或重寫節點以將你的程式作為外掛程式載入。 這能提供低延遲,非常有幫助,例如在使用 web3 程式庫處理大量資料時,或是在你需要盡快替換交易時 (即搶先交易)。
+- 你可以直接質押 ETH 來維護網路安全並賺取獎勵。 請參閱[單獨質押](/staking/solo/)以開始使用。
-
+
-### 網路優點 {#network-benefits}
+### 網路效益 {#network-benefits}
多樣化的節點對於以太坊的健康、安全和營運彈性非常重要。
- 全節點強制執行共識規則,因此不會被欺騙而接受不遵循這些規則的區塊。 這對網路提供了額外的安全性,因為如果所有的節點都是不執行完整驗證的輕節點,驗證者可以攻擊網路。
-- 如果攻擊攻破了[權益證明](/developers/docs/consensus-mechanisms/pos/#what-is-pos)的加密貨幣經濟防禦,全節點可以選擇追隨最誠實的區塊鏈,執行社交恢復。
+- 在攻擊突破[權益證明](/developers/docs/consensus-mechanisms/pos/#what-is-pos)的加密經濟防禦時,完整節點可以選擇遵循誠實鏈來執行社會復原。
- 網路中的節點越多,就越能打造更多樣化和強韌的網路,這是去中心化的最終目的,提供一個抗審查且可靠的系統。
-- 全節點為依賴區塊鏈資料的輕量用戶端提供這些區塊鏈資料的存取權限。 輕節點不會儲存整個區塊鏈,而是透過[區塊頭中的狀態根](/developers/docs/blocks/#block-anatomy)來驗證資料。 若有需要,輕節點可以向全節點索取更多的資訊。
+- 全節點為依賴區塊鏈資料的輕量用戶端提供這些區塊鏈資料的存取權限。 輕量節點不儲存整個區塊鏈,而是透過[區塊標頭中的狀態根](/developers/docs/blocks/#block-anatomy)來驗證資料。 若有需要,輕節點可以向全節點索取更多的資訊。
如果你運行一個全節點,整個以太坊網路均會受益,即便你沒有運行驗證者。
-## 運行你自己的節點 {#running-your-own-node}
+## 執行你自己的節點 {#running-your-own-node}
有興趣運行自己的以太坊用戶端嗎?
-如需適合初學者的介紹,請造訪我們的[運行節點](/run-a-node)頁面以瞭解更多資訊。
+如需適合初學者的介紹,請瀏覽我們的[執行節點](/run-a-node)頁面以瞭解更多資訊。
-如果你是技術性使用者,請瞭解有關如何[啟動自己的節點](/developers/docs/nodes-and-clients/run-a-node/)的更多資訊和選項。
+如果你是技術型使用者,請深入瞭解關於如何[啟動你自己的節點](/developers/docs/nodes-and-clients/run-a-node/)的更多詳細資訊和選項。
## 替代方案 {#alternatives}
-設定自己的節點需要時間和資源,但你不一定需要自己運行。 在這種情況下,你可以使用第三方應用程式介面提供者。 有關使用這些服務的概述,請參閱[節點即服務](/developers/docs/nodes-and-clients/nodes-as-a-service/)。
+設定自己的節點需要時間和資源,但你不一定需要自己運行。 在這種情況下,你可以使用第三方應用程式介面提供者。 關於使用這些服務的總覽,請查看[節點即服務](/developers/docs/nodes-and-clients/nodes-as-a-service/)。
如果在你的社群中,有人運行以太坊節點並提供公開應用程式介面,你可以透過自訂遠端程序呼叫將你的錢包指向社群節點,比起隨機選擇一個可信的第三方,可以獲得更多的隱私。
@@ -126,20 +130,20 @@ sidebarDepth: 2
## 執行用戶端 {#execution-clients}
-以太坊社群維護多個開源執行用戶端(以前稱為「以太坊 1 用戶端」,或直接稱為「以太坊用戶端」),這些用戶端由不同團隊使用不同程式語言開發。 這使網路更強大也更[多樣化](/developers/docs/nodes-and-clients/client-diversity/)。 理想目標是達成多樣性,沒有任一用戶端佔有主導地位,以減少單點故障。
+以太坊社群維護多個開源執行用戶端(以前稱為「以太坊 1 用戶端」,或直接稱為「以太坊用戶端」),這些用戶端由不同團隊使用不同程式語言開發。 這使得網路更加強大且更具[多元性](/developers/docs/nodes-and-clients/client-diversity/)。 理想目標是達成多樣性,沒有任一用戶端佔有主導地位,以減少單點故障。
-此表總結了不同的用戶端。 所有這些用戶端都通過了[用戶端測試](https://github.com/ethereum/tests),並積極維護以保持最新的網路升級狀態。
+此表總結了不同的用戶端。 它們全都通過[用戶端測試](https://github.com/ethereum/tests),並被積極維護以跟上網路升級。
-| 用戶端 | 語言 | 作業系統 | 網路 | 同步策略 | 狀態修剪 |
-| ---------------------------------------------------------------------- | ---------- | --------------------- | ------------------------- | -------------------------------------------------- | ------ |
-| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [快照](#snap-sync)、[完整](#full-sync) | 歸檔、已修剪 |
-| [Nethermind](https://www.nethermind.io/) | C#、.NET | Linux、Windows、macOS | Mainnet, Sepolia, Holesky | [快照](#snap-sync) (不提供服務)、快速、[完整](#full-sync) | 歸檔, 緩衝 |
-| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [快照](#snap-sync)、[快速](#fast-sync)、[完整](#full-sync) | 歸檔, 緩衝 |
-| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [完整](#full-sync) | 歸檔, 緩衝 |
-| [Reth](https://reth.rs/) | Rust | Linux、Windows、macOS | Mainnet, Sepolia, Holesky | [完整](#full-sync) | 歸檔、已修剪 |
-| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo)_(測試版)_ | TypeScript | Linux, Windows, macOS | Sepolia、Holesky | [完整](#full-sync) | 已修剪 |
+| 用戶端 | 語言 | 作業系統 | 網路 | 同步策略 | 狀態修剪 |
+| ------------------------------------------------------------------------------------------- | ----------------------- | ------------------- | ------------------ | --------------------------------------------------------------- | ------ |
+| [Geth](https://geth.ethereum.org/) | Go | Linux、Windows、macOS | 主網、Sepolia、Holesky | [快照](#snap-sync)、[完整](#full-sync) | 歸檔、已修剪 |
+| [Nethermind](https://www.nethermind.io/) | C#、.NET | Linux、Windows、macOS | 主網、Sepolia、Holesky | [快照](#snap-sync) (不提供服務)、快速、[完整](#full-sync) | 歸檔、已修剪 |
+| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux、Windows、macOS | 主網、Sepolia、Holesky | [快照](#snap-sync)、[快速](#fast-sync)、[完整](#full-sync) | 歸檔、已修剪 |
+| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux、Windows、macOS | 主網、Sepolia、Holesky | [完整](#full-sync) | 歸檔、已修剪 |
+| [Reth](https://reth.rs/) | Rust | Linux、Windows、macOS | 主網、Sepolia、Holesky | [完整](#full-sync) | 歸檔、已修剪 |
+| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | Linux、Windows、macOS | Sepolia、Holesky | [完整](#full-sync) | 已修剪 |
-有關受支援網路的更多信息,請閱讀[以太坊網路](/developers/docs/networks/)。
+想進一步了解支援的網路,請閱讀[以太坊網路](/developers/docs/networks/)。
每個用戶端都有獨特的用例和優勢,因此你應該根據自己的偏好進行選擇。 多樣化使實作能夠專注於不同的功能和使用者受眾。 你可能希望根據功能、支援、程式語言或許可證來選擇用戶端。
@@ -147,7 +151,7 @@ sidebarDepth: 2
Hyperledger Besu 是適用於公共和授權網路的企業級以太坊用戶端。 它運行所有以太坊主網功能,從追蹤到 GraphQL,具有廣泛的監控功能,並由 ConsenSys 在開放社群管道和企業商業 SLA 中提供支援。 它是用 Java 編寫的,並獲得 Apache 2.0 許可。
-Besu 詳盡的 [文件](https://besu.hyperledger.org/en/stable/)會引導你學習其所有功能及設定的細節。
+Besu 詳盡的[文件](https://besu.hyperledger.org/en/stable/)會引導你了解其所有功能和設定的細節。
### Erigon {#erigon}
@@ -157,7 +161,7 @@ Erigon,舊稱 Turbo‐Geth,最初為 Go Ethereum 的分叉,專注於速度
Go Ethereum(簡稱 Geth)是以太坊協定的原始實作之一。 目前,它是使用最廣泛的用戶端,擁有最大的使用者群體,並為使用者和開發者提供的各種工具。 它是用 Go 編寫的,完全開源,並獲得 GNU LGPL v3 許可。
-從相關[文件](https://geth.ethereum.org/docs/)中了解有關 Geth 的更多資訊。
+在其[文件](https://geth.ethereum.org/docs/)中深入瞭解 Geth。
### Nethermind {#nethermind}
@@ -167,7 +171,7 @@ Nethermind 是使用 C# .NET 技術堆疊開發的以太坊實作,以 LGPL-3.0
- 狀態存取
- 網路和豐富的功能,如 Prometheus/Grafana 儀表板、seq 企業日誌記錄支援、JSON-RPC 追蹤和分析插件。
-Nethermind 也為高級使用者提供[詳細文件](https://docs.nethermind.io)、強大的開發支援、線上社群和全年無休支援。
+Nethermind 也有[詳盡的文件](https://docs.nethermind.io)、強大的開發支援、線上社群,並為付費使用者提供全年無休的支援。
### Reth {#reth}
@@ -175,7 +179,7 @@ Reth(Rust Ethereum 的簡稱)是以太坊全節點的實作,致力於達
Reth 是生產就緒的執行用戶端,且適用於質押或高正常運作時間的服務等重要任務上。 在一些高效能、高利潤下的使用案例中表現優秀,如遠端程序呼叫、最大可提取價值、索引、模擬和點對點活動等。
-查看 [Reth Book](https://reth.rs/) 或 [ Reth 的 GitHub 儲存庫](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth)以獲得更多資訊。
+查看 [Reth Book](https://reth.rs/) 或 [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth) 以深入了解。
### 開發中 {#execution-in-development}
@@ -185,58 +189,58 @@ Reth 是生產就緒的執行用戶端,且適用於質押或高正常運作時
EthereumJS 執行用戶端 (EthereumJS) 是以 TypeScript 編寫,並由多個套件組成,包括以區塊表示的核心以太坊基礎單元、交易和梅克爾帕特里夏樹據結構類別,以及核心用戶端元件,包括以太坊虛擬機 (EVM) 的實作、區塊鏈類別和 DevP2P 網路堆疊。
-閱讀相關[文件](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master),了解更多資訊。
+閱讀其[文件](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master)以深入了解
## 共識用戶端 {#consensus-clients}
-有多種共識用戶端(以前稱為「以太坊 2」用戶端)支援[共識升級](/roadmap/beacon-chain/)。 它們負責所有共識相關的邏輯,包含了分叉選擇演算法、處理證明並管理[權益證明](/developers/docs/consensus-mechanisms/pos)的獎勵和懲處。
+有多種共識用戶端 (舊稱「Eth2」用戶端) 可支援[共識升級](/roadmap/beacon-chain/)。 它們負責所有共識相關的邏輯,包括分叉選擇演算法、處理證明,以及管理[權益證明](/developers/docs/consensus-mechanisms/pos)的獎勵和懲罰。
-| 用戶端 | 程式語言 | 作業系統 | 網路 |
-| ------------------------------------------------------------- | ---------- | --------------------- | ------------------------------------------- |
-| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | 信標鏈、Goerli、Pyrmont、Sepolia、Ropsten 等 |
-| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | 信標鏈、Goerli、Sepolia、Ropsten 等 |
-| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | 信標鏈、Goerli、Sepolia、Ropsten 等 |
-| [Prysm](https://prysm.offchainlabs.com/docs/) | 開始 | Linux, Windows, macOS | 信標鏈、Gnosis、Goerli、Pyrmont、Sepolia、Ropsten 等 |
-| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux、Windows、macOS | 信標鏈、Gnosis、Goerli、Sepolia、Ropsten 等 |
-| [Grandine](https://docs.grandine.io/)(測試版) | Rust | Linux、Windows、macOS | 信標鏈、Goerli、Sepolia 等 |
+| 用戶端 | 語言 | 作業系統 | 網路 |
+| ------------------------------------------------------------- | ---------- | ------------------- | ------------------------------------ |
+| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux、Windows、macOS | 信標鏈、Holesky、Pyrmont、Sepolia 等 |
+| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux、Windows、macOS | 信標鏈、Holesky、Sepolia 等 |
+| [Nimbus](https://nimbus.team/) | Nim | Linux、Windows、macOS | 信標鏈、Holesky、Sepolia 等 |
+| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux、Windows、macOS | 信標鏈、Gnosis、Holesky、Pyrmont、Sepolia 等 |
+| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux、Windows、macOS | 信標鏈、Gnosis、Holesky、Sepolia 等 |
+| [Grandine](https://docs.grandine.io/) | Rust | Linux、Windows、macOS | 信標鏈、Holesky、Sepolia 等 |
### Lighthouse {#lighthouse}
Lighthouse 是以 Rust 開發的共識用戶端實作,以 Apache-2.0 授權。 它由 Sigma Prime 維護,自信標鏈問世以來一直穩定且可直接用於生產。 各企業、質押池及個人都依賴它。 它的目標是從桌上型個人電腦到複雜的自動化部署,在各環境中都保持安全、高效及可互通性。
-文件可在 [Lighthouse 手冊](https://lighthouse-book.sigmaprime.io/)中找到
+可以在 [Lighthouse Book](https://lighthouse-book.sigmaprime.io/) 中找到文件
### Lodestar {#lodestar}
Lodestar 是以 Typescript 編寫,生產就緒的共識用戶端實作,以 LGPL-3.0 授權。 它由 ChainSafe Systems 維護,此外也是為單獨質押者、開發者、研究者而生的最新共識用戶端。 Lodestar 包含了信標節點及驗證者用戶端,該用戶端由以太坊協定的 JavaScript 實作提供支援。 Lodestar 致力於提升以太坊輕量用戶端的可用性,並為更多開發者擴大可存取性,以及提高以太坊生態系統多樣性。
-更多資訊可在 [Lodestar 官網](https://lodestar.chainsafe.io/)找到
+更多資訊請見 [Lodestar 網站](https://lodestar.chainsafe.io/)
### Nimbus {#nimbus}
Nimbus 是以 Nim 開發的共識用戶端實作,以 Apache-2.0 授權。 它是生產就緒的用戶端,常被單獨質押者及質押池使用。 Nimbus 專為資源效率而生,可在資源有限的裝置及企業基礎設施上輕鬆運行,而不影響其穩定性及獎勵效能。 更少的資源佔用意味著網路面臨壓力時,用戶端有更大的安全邊際。
-在 [Nimbus 文檔](https://nimbus.guide/)中瞭解更多
+在 [Nimbus 文件](https://nimbus.guide/)中深入瞭解
### Prysm {#prysm}
Prysm 是功能完整且開源的共識用戶端,以 Go 語言開發並以 GPL-3.0 授權。 它有可選的網頁應用用戶介面,並將自行質押者及機構使用者的使用者體驗、文檔及設定檔放在第一位。
-閱讀 [Prysm 文檔](https://prysm.offchainlabs.com/docs/)以獲得更多資訊。
+瀏覽 [Prysm 文件](https://prysm.offchainlabs.com/docs/)以深入瞭解。
### Teku {#teku}
Teku 是最初的信標鏈創世用戶端之一。 除了一般的目標(安全性、穩定性、可用性、效能)外,Teku 特別致力於遵循各式各樣的用戶端標準。
-Teku 提供了非常彈性的部署選項。 信標節點與驗證者用戶端可以在同個進程一起運行,對單獨質押者來說非常方便,節點也可分開運行,以完成複雜的質押操作。 此外,Teku 與 [Web3Signer](https://github.com/ConsenSys/web3signer/) 完全相容,以實現簽署金鑰安全及罰沒保護。
+Teku 提供了非常彈性的部署選項。 信標節點與驗證者用戶端可以在同個進程一起運行,對單獨質押者來說非常方便,節點也可分開運行,以完成複雜的質押操作。 此外,Teku 與 [Web3Signer](https://github.com/ConsenSys/web3signer/) 完全互通,可保障簽署金鑰安全並提供削減懲罰保護。
-Teku 以 Java 編寫,並以 Apache 2.0 授權發佈。 它由 ConsenSys 的 Protocols 團隊開發,該團隊也負責 Besu 和 Web3Signer 開發。 在 [Teku 文檔中](https://docs.teku.consensys.net/en/latest/)瞭解更多。
+Teku 以 Java 編寫,並以 Apache 2.0 授權發佈。 它由 ConsenSys 的 Protocols 團隊開發,該團隊也負責 Besu 和 Web3Signer 開發。 在 [Teku 文件](https://docs.teku.consensys.net/en/latest/)中深入瞭解。
### Grandine {#grandine}
Grandine 是以 Rust 語言編寫,以 GPL-3.0 授權的共識用戶端實作。 它由 Grandine 核心團隊維護,具有速度快、高效能和輕量的特點。 它適用於各類的質押者,從使用低資源裝置(如樹莓派)的單獨質押者,到運行數萬個驗證者的大機構質押者都能使用。
-文件可在 [Grandine 手冊](https://docs.grandine.io/)中找到
+文件可在 [Grandine Book](https://docs.grandine.io/) 中找到
## 同步模式 {#sync-modes}
@@ -255,7 +259,7 @@ Grandine 是以 Rust 語言編寫,以 GPL-3.0 授權的共識用戶端實作
- 透過驗證每筆交易,最大限度地減少信任依賴並提供最高的安全性。
- 隨著交易數量不斷增加,處理所有交易可能需要幾天到幾週的時間。
-[歸檔節點](#archive-node)執行完整同步,以建立(並保留)每個區塊中每個交易所做的狀態變更的完整歷史記錄。
+[歸檔節點](#archive-node)會執行完整同步,以建立 (並保留) 每個區塊中每筆交易所做的狀態變更的完整歷史記錄。
#### 快速同步 {#fast-sync}
@@ -271,7 +275,7 @@ Grandine 是以 Rust 語言編寫,以 GPL-3.0 授權的共識用戶端實作
- 最快的同步策略,目前為以太坊主網的預設策略。
- 在不犧牲安全性的情況下,節省了大量的磁碟空間和網路頻寬。
-[更多有關快照同步的資訊](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)。
+[關於快照同步的更多資訊](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)。
#### 輕量同步 {#light-sync}
@@ -280,7 +284,7 @@ Grandine 是以 Rust 語言編寫,以 GPL-3.0 授權的共識用戶端實作
- 依靠對開發者的信任和共識機制,只取得最新狀態。
- 用戶端可在幾分鐘內在目前網路狀態下使用。
-**NB** 輕量同步目前無法在權益證明以太坊上使用,新版本的輕量同步應很快會發佈!
+**注意**:輕量同步還不能用於權益證明的以太坊 - 新版本的輕量同步應該很快就會發布!
[關於輕量用戶端的更多資訊](/developers/docs/nodes-and-clients/light-clients/)
@@ -288,28 +292,28 @@ Grandine 是以 Rust 語言編寫,以 GPL-3.0 授權的共識用戶端實作
#### 樂觀同步 {#optimistic-sync}
-樂觀同步是一種合併後同步策略,被設計為可選擇向後兼容,可使執行節點透過預先建立的方法同步。 執行引擎可以_樂觀地_匯入信標區塊而不需要完整驗證,找到最新的區塊頭,並使用上述方法開始同步鏈。 接著,在執行用戶端同步至最新狀態後,它會通知共識用戶端信標鏈中交易的有效性。
+樂觀同步是一種合併後同步策略,被設計為可選擇向後兼容,可使執行節點透過預先建立的方法同步。 執行引擎可以_樂觀地_匯入信標區塊而不需完全驗證它們,找到最新的標頭,然後用上述方法開始同步鏈。 接著,在執行用戶端同步至最新狀態後,它會通知共識用戶端信標鏈中交易的有效性。
[關於樂觀同步的更多資訊](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md)
#### 檢查點同步 {#checkpoint-sync}
-檢查點同步又稱弱主觀性同步,在同步信標節點時提供優異的使用者體驗。 它是基於[弱主觀性](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/)假設,使信標鏈能夠從近期的弱主觀性檢查點開始同步,而不是從創世塊開始。 檢查點同步顯著縮短了初始同步時間,其信任假設與從[創世塊](/glossary/#genesis-block)開始同步相同。
+檢查點同步又稱弱主觀性同步,在同步信標節點時提供優異的使用者體驗。 它基於[弱主觀性](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/)的假設,這使得信標鏈能夠從最近的弱主觀性檢查點而不是創世塊開始同步。 與從[創世塊](/glossary/#genesis-block)開始同步相比,檢查點同步的信任假設相似,但能大幅縮短初始同步時間。
在實際運作上,這表示你的節點會連接至遠端服務,以下載近期最終確定的狀態,並從該點開始繼續驗證資料。 提供資料的第三方會受到信任,因此應謹慎選擇。
-關於[檢查點同步](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)的更多資訊
+更多關於[檢查點同步](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)的資訊
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊 101 - 第 2 部分 - 瞭解節點](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes,2019 年 2 月 13 日_
-- [運行以太坊全節點:針對幾乎沒有動力的人提供的指南](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31)_ – Justin Leroux,2019 年 11 月 7 日_
+- [以太坊 101 - 第 2 部分 - 了解節點](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes,2019 年 2 月 13 日_
+- [執行以太坊完整節點:一份寫給有點懶的人的指南](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux,2019 年 11 月 7 日_
## 相關主題 {#related-topics}
-- [分塊](/developers/docs/blocks/)
+- [區塊](/developers/docs/blocks/)
- [網路](/developers/docs/networks/)
## 相關教學 {#related-tutorials}
-- [只需刷寫 MicroSD 卡即可將你的樹莓派 4 變成驗證者節點 -- 安裝指南](/developers/tutorials/run-node-raspberry-pi/) _ -- 刷寫你的樹莓派 4,插入乙太網路纜線,連接 SSD 磁碟,然後啟動設備,將樹莓派 4 轉變為運行執行層(主網)和/或共識層(信標鏈/驗證者)的完整以太坊節點。_
+- [只要快閃 MicroSD 卡,就能將你的 Raspberry Pi 4 變成驗證者節點 – 安裝指南](/developers/tutorials/run-node-raspberry-pi/) _– 快閃你的 Raspberry Pi 4、插入乙太網路線、連接 SSD 硬碟並為裝置通電,即可將 Raspberry Pi 4 變成執行執行層 (主網) 和/或共識層 (信標鏈/驗證者) 的完整以太坊節點。_
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/light-clients/index.md
index 20aa0d19698..3aad1f6cd89 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/light-clients/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/light-clients/index.md
@@ -6,13 +6,13 @@ lang: zh-tw
運行全節點是與以太坊互動最去信任、隱私、去中心化和抗審查的方式。 透過全節點,你可以保留自己的區塊鏈副本,可用於即時查詢並直接存取以太坊的點對點網路。 然而,運行全節點需要大量的記憶體、儲存空間及 CPU 資源。 這意味著讓所有人運行自己的節點不可行。 以太坊路線圖上有幾種解決方式,包括無狀態,但距離實現還要幾年的時間。 近期的解決方法是權衡一些運行全節點的優點,以實現大幅效能改進,使節點在極低硬體需求下運行。 做出這種妥協的節點稱為輕節點。
-## 輕量用戶端是什麼? {#what-is-a-light-client}
+## 什麼是輕量用戶端 {#what-is-a-light-client}
輕節點是運行輕量用戶端軟體的節點。 輕節點不保留區塊鏈資料的本地副本,也不獨立驗證所有變更,而是向一些提供者索取必要資料。 提供者可能是直接或透過一些中心化遠端程序呼叫伺服器連結到全節點。 接著,輕節點驗證資料,使資料能和鏈頭保持同步。 輕節點只處理區塊頭,只有偶爾才會下載實際區塊內容。 節點的輕量程度可能會有所不同,具體取決於它們執行的輕量和全用戶端軟體的組合。 舉例來說,最輕量的設定是運行一個輕量執行用戶端和一個輕量共識用戶端。 許多節點也有可能會選擇運行輕量共識用戶端和全執行用戶端,反之亦然。
## 輕量用戶端是如何運作的? {#how-do-light-clients-work}
-當以太坊開始使用基於權益證明的共識機制時,專門引入了新的基礎設施來支援輕量用戶端。 它的運作方式是,每 1.1 天隨機選擇包含了 512 個驗證者的子集作為**同步委員會**。 同步委員會簽署最近區塊的頭部。 每個區塊頭包括了同步委員會中驗證者的聚合簽名,以及一個顯示驗證者簽名與否的「位元欄位」。 每個區塊頭還包含了預期參與下一個區塊簽名的驗證者清單。 這表示輕量用戶端可以快速查看同步委員會是否已簽署它們收到的資料,它們也可以透過比較它們收到的資料和依據上一個區塊而預期收到的資料,以確認同步委員會的真實性。 這樣一來,輕量用戶端就能持續更新對最新以太坊區塊的了解,而不需要實際下載區塊,只要下載包含摘要資訊的區塊頭即可。
+當以太坊開始使用基於權益證明的共識機制時,專門引入了新的基礎設施來支援輕量用戶端。 其運作方式是每 1.1 天隨機選出一個由 512 個驗證者組成的子集,作為**同步委員會**。 同步委員會簽署最近區塊的頭部。 每個區塊頭包括了同步委員會中驗證者的聚合簽名,以及一個顯示驗證者簽名與否的「位元欄位」。 每個區塊頭還包含了預期參與下一個區塊簽名的驗證者清單。 這表示輕量用戶端可以快速查看同步委員會是否已簽署它們收到的資料,它們也可以透過比較它們收到的資料和依據上一個區塊而預期收到的資料,以確認同步委員會的真實性。 這樣一來,輕量用戶端就能持續更新對最新以太坊區塊的了解,而不需要實際下載區塊,只要下載包含摘要資訊的區塊頭即可。
在執行層上,沒有對輕量執行用戶端的單一規範。 輕量執行用戶端的範圍差異可以與全執行用戶端的「輕量模式」不同,後者有全節點的所有以太坊虛擬機和網路功能,但只驗證區塊頭,而不下載相關資料,或者它也可以是更精簡的用戶端,主要依賴將請求轉發至遠端程序呼叫提供者以和以太坊交互。
@@ -32,7 +32,7 @@ lang: zh-tw
輕量用戶端解鎖的創新領域其中之一是可以在儲存空間、記憶體和處理能力都很小的裝置上運行以太坊節點。 如今的以太坊節點需要大量運算資源,輕量用戶端可被嵌入瀏覽器中、在手機上運行,或者甚至可能在更小的智慧型裝置上運行,如智慧手錶。 這表示含有嵌入式用戶端的以太坊錢包可能可以在手機上運行。 這表示手機錢包可更去中心化,因為它們不需要信任中心化資料提供者以獲取資料。
-這個的延伸是使用**物聯網 (IoT)** 裝置。 輕量用戶端可用於快速證明某些代幣或非同質化代幣的餘額或擁有權,透過所有同步委員會提供的安全保證,以觸發物聯網的某些操作。 想像一個[腳踏車租借服務](https://youtu.be/ZHNrAXf3RDE?t=929),透過應用程式和嵌入式輕量用戶端以快速驗證你擁有租借服務的非同質化代幣,如果是,則解鎖一輛腳踏車讓你騎走。
+這項技術的延伸應用是支援**物聯網 (IoT)** 裝置。 輕量用戶端可用於快速證明某些代幣或非同質化代幣的餘額或擁有權,透過所有同步委員會提供的安全保證,以觸發物聯網的某些操作。 想像有一個[腳踏車租借服務](https://youtu.be/ZHNrAXf3RDE?t=929),其應用程式內嵌了輕量用戶端,可快速驗證您是否擁有該租借服務的 NFT,如果驗證成功,就會為您解鎖一輛腳踏車讓您騎走!
以太坊卷軸也受益於輕量用戶端。 卷軸一直以來的其中一個大問題是,駭客會瞄準允許資金在卷軸和以太坊之間轉移的跨鏈橋發動攻擊。 其中一個漏洞是卷軸用來偵測使用者是否存款至跨鏈橋的預言機。 如果預言機提供了錯誤資料,它們可能會欺騙卷軸有新存款至跨鏈橋的資金,並錯誤的釋放資金。 嵌入在卷軸中的輕量用戶端可以用來避免預言機損壞帶來的傷害,因為存款進跨鏈橋可以得到一個附加的證明,可在釋放資金前被卷軸用來驗證。 相同的概念也適用於其他跨鏈橋。
@@ -42,20 +42,20 @@ lang: zh-tw
有許多的輕量用戶端都在開發中,包括執行、共識、和執行/共識組合的輕量用戶端。 這些是在撰文時我們已知的輕量用戶端實現:
-- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client):由 TypeScript 編寫的輕量用戶端
-- [Helios](https://github.com/a16z/helios):由 Rust 編寫的執行和共識組合輕量用戶端
-- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light):用 Go 語言編寫的執行用戶端輕量模式(開發中)
-- [Nimbus](https://nimbus.guide/el-light-client.html):由 Nim 編寫的共識輕量用戶端
+- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client):以 TypeScript 編寫的共識輕量用戶端
+- [Helios](https://github.com/a16z/helios):以 Rust 編寫的執行與共識整合式輕量用戶端
+- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light):執行用戶端的輕量模式 (開發中),以 Go 編寫
+- [Nimbus](https://nimbus.guide/el-light-client.html):以 Nim 編寫的共識輕量用戶端
據我們所知,上述這些服務都尚未準備好在生產環境中使用。
-為了改進輕量用戶端存取以太坊資料的方式,還有很多工作要做。 目前,輕量用戶端依賴使用用戶端/伺服器架構向全節點發出的遠端程序呼叫請求,但在未來可以透過專用網路用更去中心化的方式請求資料,如[門戶網路](https://www.ethportal.net/)可以透過點對點廣播協議將資料發送至輕量用戶端。
+為了改進輕量用戶端存取以太坊資料的方式,還有很多工作要做。 目前,輕量用戶端依賴用戶端/伺服器模型,透過 RPC 請求向完整節點索取資料。但在未來,可以使用專用網路 (例如 [Portal Network](https://www.ethportal.net/)) 以更去中心化的方式請求資料,該網路可以透過點對點 Gossip 通訊協定將資料提供給輕量用戶端。
-其他[路線圖](/roadmap/)上的專案如 [Verkle 樹](/roadmap/verkle-trees/)和[無狀態性](/roadmap/statelessness/),最終會為輕量用戶端帶來與全用戶端同等的安全保證。
+其他[開發藍圖](/roadmap/)項目,例如 [Verkle 樹](/roadmap/verkle-trees/) 和[無狀態性](/roadmap/statelessness/),最終將使輕量用戶端的安全保證與完整用戶端相當。
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [Zsolt Felfodhi 談 Geth 輕量用戶端](https://www.youtube.com/watch?v=EPZeFXau-RE)
- [Etan Kissling 談輕量用戶端網路](https://www.youtube.com/watch?v=85MeiMA4dD8)
- [Etan Kissling 談合併後的輕量用戶端](https://www.youtube.com/watch?v=ZHNrAXf3RDE)
-- [Piper Merriam:通往功能性輕量用戶端的曲折之路](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/)
+- [Piper Merriam:通往功能性輕量用戶端的漫漫長路](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/)
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/node-architecture/index.md
index e876df86beb..7d5af05e89e 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/node-architecture/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/node-architecture/index.md
@@ -4,23 +4,25 @@ description: 關於如何安排以太坊節點的介紹。
lang: zh-tw
---
-一個以太坊節點由兩個用戶端組成:一個[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)以及一個[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients)。
+一個以太坊節點由兩個用戶端組成:一個[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)和一個[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients)。 節點若要提案新區塊,還必須執行[驗證器用戶端](#validators)。
-當以太坊使用[工作量證明](/developers/docs/consensus-mechanisms/pow/)時,一個執行用戶端已足夠運行以太坊全節點。 然而,自從實行[權益證明](/developers/docs/consensus-mechanisms/pow/),執行用戶端需要與另外一個軟體同時使用,該軟體稱為[「共識用戶端」](/developers/docs/nodes-and-clients/#consensus-clients)。
+當以太坊使用[工作量證明](/developers/docs/consensus-mechanisms/pow/)時,一個執行用戶端已足夠執行一個以太坊全節點。 然而,自從實施[權益證明](/developers/docs/consensus-mechanisms/pow/)後,執行用戶端必須與另一個稱為[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients)的軟體一起使用。
下圖顯示兩種以太坊用戶端的關係。 兩種用戶端與他們各自的點對點 (P2P) 網路相連。 執行用戶端透過其點對點網路廣播交易,來確保能夠管理自己的本機交易池,而共識用戶端透過其點對點網路廣播區塊,來確保共識和鏈增長,因此需要獨立的點對點網路。

-要讓這兩種用戶端架構運作,驗證用戶端必須能夠將大量交易傳送至執行用戶端。 透過在本機執行交易,用戶端驗證交易沒有違反任何以太坊的規則且提議的以太坊狀態更新是否正確。 同樣地,當節點被選為區塊生產者,共識用戶端必須能夠從 Geth 請求各種交易,以添加到新的區塊裡並執行它們來更新全域狀態。 用戶端間的通訊由本機遠端程序呼叫連線使用[引遠端程序呼叫](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)處理。
+_執行用戶端有多種選擇,包括 Erigon、Nethermind 和 Besu_。
+
+要讓這兩種用戶端架構運作,驗證用戶端必須將大量交易傳送至執行用戶端。 執行用戶端在本地執行交易,以驗證交易沒有違反任何以太坊規則,以及對以太坊狀態的提議更新是正確的。 當一個節點被選為區塊生產者時,其共識用戶端實例會向執行用戶端請求交易捆綁包,以將其納入新區塊並執行,進而更新全域狀態。 共識用戶端使用[引擎 API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md),透過本地 RPC 連線來驅動執行用戶端。
## 執行用戶端的作用為何? {#execution-client}
-執行用戶端負責處理交易、廣播交易、狀態管理,以及支援以太坊虛擬機 ([EVM](/developers/docs/evm/))。 然而,它並**不**負責產生區塊、廣播區塊,或是處理共識邏輯。 這些為共識用戶端的工作範圍。
+執行用戶端負責交易驗證、處理和傳播,以及狀態管理和支援以太坊虛擬機 ([EVM](/developers/docs/evm/))。 它**不**負責建構區塊、傳播區塊或處理共識邏輯。 這些為共識用戶端的工作範圍。
-執行用戶端建立執行有效負載:交易列表、更新的狀態樹,以及其他執行相關的資料。 共識用戶端將執行有效負載加入每一個區塊。 執行用戶端也負責重新執行每個新區塊的交易,確保交易為有效的。 執行交易在執行用戶端的嵌入式電腦上執行,該嵌入式電腦稱為[以太坊虛擬機 (EVM)](/developers/docs/evm)。
+執行用戶端建立執行有效負載:交易列表、更新的狀態樹,以及其他執行相關的資料。 共識用戶端將執行有效負載加入每一個區塊。 執行用戶端也負責重新執行每個新區塊的交易,確保交易為有效的。 交易是在執行用戶端的嵌入式電腦上執行,也就是所謂的[以太坊虛擬機 (EVM)](/developers/docs/evm)。
-執行用戶端還透過[遠端程序呼叫方法](/developers/docs/apis/json-rpc)提供一個連接以太坊的使用者介面,讓使用者可以查詢以太坊區塊鏈、提交交易和部署智慧型合約。 遠端程序呼叫呼叫通常由 [Web3js](https://docs.web3js.org/)、[Web3py](https://web3py.readthedocs.io/en/v5/) 這樣的函式庫處理,或是像是瀏覽器錢包的使用者介面。
+執行用戶端也透過 [RPC 方法](/developers/docs/apis/json-rpc) 提供以太坊的使用者介面,讓使用者可以查詢以太坊區塊鏈、提交交易和部署智能合約。 RPC 呼叫通常由 [Web3js](https://docs.web3js.org/)、[Web3py](https://web3py.readthedocs.io/en/v5/) 這類的函式庫,或由瀏覽器錢包等使用者介面來處理。
總而言之,執行用戶端為:
@@ -33,25 +35,25 @@ lang: zh-tw
共識用戶端不參與區塊的證明或提議;此由共識用戶端的驗證者(可選附加組件)完成。 沒有驗證者的共識用戶端只會同步鏈頭,使節點能夠保持同步。 這讓使用者可以使用他們的執行用戶端與以太坊交易,並確信位於正確的鏈上。
-## 驗證者 {#validators}
+## 驗證程式 {#validators}
-節點營運者可以在存款合約中存入 32 以太幣,以添加一個驗證者到他們的共識用戶端。 驗者者用戶端與共識用戶端捆綁在一起,可以隨時添加進節點。 驗證者處理證明及區塊提議。 它們讓節點可以累積獎勵,或因懲罰或罰沒而失去以太幣。 運行驗證者軟體也讓一個節點有資格被選中來提議新區塊。
+質押並運行驗證者軟體將使一個節點有資格被選中來提議新區塊。 節點營運者可以在存款合約中存入 32 以太幣,以添加一個驗證者到他們的共識用戶端。 驗者者用戶端與共識用戶端捆綁在一起,可以隨時添加進節點。 驗證者處理證明及區塊提議。 它也使節點能夠累積獎勵,或因懲罰或罰沒而失去以太幣。
-[更多關於質押的資訊](/staking/)。
+[更多關於質押](/staking/)。
## 節點組成比較 {#node-comparison}
-| 執行用戶端 | 共識用戶端 | 驗證者 |
-| -------------------------- | ------------------ | ----------- |
-| 透過其點對點網路廣播交易 | 透過其點對點網路廣播區塊及證明 | 提議區塊 |
-| 執行/重新執行交易 | 運行分叉選擇演算法 | 積累獎勵/懲罰 |
-| 驗證傳入狀態的變更 | 追蹤鏈頭 | 做出證明 |
-| 管理狀態及收據樹 | 管理信標狀態(包括共識和執行資訊) | 需要質押 32 以太幣 |
-| 建立執行有效負載 | 追蹤在 RANDAO 中累積的隨機性 | 可被罰沒 |
-| 公開 JSON-RPC 應用程式介面以便與以太坊互動 | 追蹤證明及最終確定 | |
+| 執行用戶端 | 共識用戶端 | 驗證者 |
+| -------------------------- | -------------------------------------------------------------------------- | ----------- |
+| 透過其點對點網路廣播交易 | 透過其點對點網路廣播區塊及證明 | 提議區塊 |
+| 執行/重新執行交易 | 運行分叉選擇演算法 | 積累獎勵/懲罰 |
+| 驗證傳入狀態的變更 | 追蹤鏈頭 | 做出證明 |
+| 管理狀態及收據樹 | 管理信標狀態(包括共識和執行資訊) | 需要質押 32 以太幣 |
+| 建立執行有效負載 | 追蹤 RANDAO 中的累積隨機性 (RANDAO 是一種為驗證者選擇和其他共識操作提供可驗證隨機性的演算法) | 可被罰沒 |
+| 公開 JSON-RPC 應用程式介面以便與以太坊互動 | 追蹤證明及最終確定 | |
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [權益證明](/developers/docs/consensus-mechanisms/pos)
-- [區塊提出](/developers/docs/consensus-mechanisms/pos/block-proposal)
-- [驗證者獎勵及懲罰](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
+- [區塊提案](/developers/docs/consensus-mechanisms/pos/block-proposal)
+- [驗證者獎勵與懲罰](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
index ee02f0398d0..24d962d6dee 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
@@ -1,23 +1,23 @@
---
-title: 節點做為一服務
+title: 節點即服務
description: 節點服務、優缺點及熱門提供者入門級概覽
lang: zh-tw
sidebarDepth: 2
---
-## 簡介 {#Introduction}
+## 介紹 {#Introduction}
-運作自己的[以太坊節點](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients)可能比較困難,特別是初始階段或快速擴容時。 有[許多服務](#popular-node-services)可以為你運行最佳化的節點基礎設施,因此你可以專注於開發應用程式或產品。 我們將解釋節點服務的工作原理、使用節點服務的優缺點,並列出提供者(如果你有興趣開始使用)。
+自行執行 [以太坊節點](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) 可能會充滿挑戰,尤其是在剛開始或快速擴展時。 有許多 [服務](#popular-node-services) 可以為你執行最佳化的節點基礎架構,讓你專注於開發應用程式或產品。 我們將解釋節點服務的工作原理、使用節點服務的優缺點,並列出提供者(如果你有興趣開始使用)。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-如你還不太瞭解節點及用戶端,請查看[節點及用戶端](/developers/docs/nodes-and-clients/)。
+如果你還不了解什麼是節點和用戶端,請參閱 [節點和用戶端](/developers/docs/nodes-and-clients/)。
## 質押者 {#stakoooooooooooooors}
-單獨質押者必須運行自己的基礎設施,而非依賴第三方提供者。 這表示運行一個執行用戶端和一個關聯的共識用戶端。 在[合併](/roadmap/merge)前,只運行共識用戶端且使用中心化提供者以執行資料是可行的;但現在已不再可行 - 單獨質押者必須同時運行兩種用戶端。 然而,有些服務可以簡化這個流程。
+單獨質押者必須運行自己的基礎設施,而非依賴第三方提供者。 這表示運行一個執行用戶端和一個關聯的共識用戶端。 在 [合併](/roadmap/merge) 之前,只執行共識用戶端並使用中心化提供者來取得執行資料是可行的;但現在已不可行——單獨質押者必須同時執行兩種用戶端。 然而,有些服務可以簡化這個流程。
-[閱讀更多關於運行節點的相關資訊](/developers/docs/nodes-and-clients/run-a-node/)。
+[深入了解執行節點的相關資訊](/developers/docs/nodes-and-clients/run-a-node/)。
本頁說明的服務適用於非質押節點。
@@ -25,13 +25,13 @@ sidebarDepth: 2
節點服務提供者在幕後為你運行分散式節點用戶端,因此你無需再這麼做。
-這些服務通常提供一個應用程式介面金鑰,你可以使用該金鑰在區塊鏈中寫入和讀取。 除了包含存取以太坊主網的權限外,它們通常還包含存取[測試網](/developers/docs/networks/#ethereum-testnets)的權限。
+這些服務通常提供一個應用程式介面金鑰,你可以使用該金鑰在區塊鏈中寫入和讀取。 除了主網之外,它們通常還提供對 [以太坊測試網](/developers/docs/networks/#ethereum-testnets) 的存取權限。
一些服務為你提供屬於你的專用節點並為你管理這些節點,而其他服務使用負載平衡器於各節點間分配活動。
幾乎所有節點服務極易整合,只需變更一行程式碼就能更換自託管節點,甚至可以在服務本身之間進行切換。
-通常,節點服務運行多種[節點用戶端](/developers/docs/nodes-and-clients/#execution-clients)與[類型](/developers/docs/nodes-and-clients/#node-types),讓你能在一個應用程式介面中除了存取特定於用戶端的方法外,還能存取全節點和歸檔節點。
+節點服務通常會執行各種 [節點用戶端](/developers/docs/nodes-and-clients/#execution-clients) 和 [類型](/developers/docs/nodes-and-clients/#node-types),讓您除了用戶端專用方法之外,還能透過單一 API 存取完整節點和封存節點。
值得關注的是,節點服務不會也不應儲存你的私密金鑰或個人資訊。
@@ -45,14 +45,14 @@ sidebarDepth: 2
使用節點服務,意味著你在中心化產品的基礎設施。 因此,最重視去中心化的專案可能會傾向於自託管節點,而不是外包給第三方。
-閱讀更多關於[運行你自己的節點之優點](/developers/docs/nodes-and-clients/#benefits-to-you)。
+深入了解 [自行執行節點的好處](/developers/docs/nodes-and-clients/#benefits-to-you)。
## 熱門節點服務 {#popular-node-services}
下方列出了最熱門的以太坊節點服務提供者,歡迎新增此處遺漏的提供者。 除了免費或付費方案,每個節點服務還提供不同的優點和功能,你應該在做出決定之前先調查哪些服務最符合你的需求。
- [**Alchemy**](https://alchemy.com/)
- - [文件](https://docs.alchemyapi.io/)
+ - [文件](https://www.alchemy.com/docs/)
- 功能
- 最大的免費方案每個月提供了 3 億運算單元 (約 3000 萬次 getLatestBlock 請求)
- 支援多鏈,如 Polygon、Starknet、Optimism、Arbitrum
@@ -64,9 +64,22 @@ sidebarDepth: 2
- 整合測試網水龍頭存取
- 超過 1.8 萬使用者的活躍 Discord 建構者社群
+- [**Allnodes**](https://www.allnodes.com/)
+ - [文件](https://docs.allnodes.com/)
+ - 功能
+ - 在 Allnodes 作品集頁面建立的 PublicNode 代幣沒有速率限制。
+ - [PublicNode](https://www.publicnode.com) 上注重隱私的免費 RPC 端點 (100+ 區塊鏈)
+ - 為超過 90 個區塊鏈提供無速率限制的專用節點
+ - 為超過 30 個區塊鏈提供歸檔節點
+ - 在 3 個地區可用(美國、歐盟、亞洲)
+ - [PublicNode](https://www.publicnode.com/snapshots) 上 100 多個區塊鏈的快照
+ - 提供全天候技術支援,正常運行時間 SLA 為 99.90%-99.98%(取決於具體計劃)。
+ - 按小時付費定價
+ - 使用信用卡、PayPal 或加密貨幣支付
+
- [**All That Node**](https://allthatnode.com/)
- [文件](https://docs.allthatnode.com/)
- - 特徵
+ - 功能
- 免費方案每天 50,000 個請求
- 支援 40 多種協定
- 支援 JSON-RPC(以太坊虛擬機、Tendermint)、具象狀態傳輸和 Websocket 應用程式介面
@@ -89,7 +102,7 @@ sidebarDepth: 2
- [**Ankr**](https://www.ankr.com/)
- [文件](https://docs.ankr.com/)
- - 特徵
+ - 功能
- Ankr 協定 - 開放對超過 8 個鏈的公共遠端程序呼叫應用程式介面端點的存取
- 負載平衡與節點健康監控,以取得連結到最近可用節點的更快更可靠的閘道
- 支援 WSS 端點與無上限速率限制的高級方案
@@ -118,14 +131,14 @@ sidebarDepth: 2
- [**BlockDaemon**](https://blockdaemon.com/)
- [文件](https://ubiquity.docs.blockdaemon.com/)
- 優點
- - 控制面板
+ - 儀表板
- 基於節點
- 分析
- [**BlockPI**](https://blockpi.io/)
- [文件](https://docs.blockpi.io/)
- 功能
- - 分散式的穩健節點結構
+ - 穩健的分散式節點結構
- 多達 40 多種超文字安全傳輸通訊協定與 WSS 端點
- 免費註冊方案及每月方案
- 追蹤 method + 歸檔資料支援
@@ -145,7 +158,7 @@ sidebarDepth: 2
- [**Chainstack**](https://chainstack.com/)
- [文件](https://docs.chainstack.com/)
- - 特徵
+ - 功能
- 免費共享節點
- 共享歸檔節點
- GraphQL 支援
@@ -156,20 +169,20 @@ sidebarDepth: 2
- 按小時付費定價
- 全年無休直接支援
-- [**DRPC**](https://drpc.org/)
- - [文件](https://docs.drpc.org/)
- - 功能
- - 去中心化遠端程序呼叫節點
- - 超過 15 個節點提供者
- - 節點平衡
- - 免費方案每個月擁有無上限的運算單元
- - 資料驗證
- - 自訂端點
- - 超文字安全傳輸通訊協定與 WSS 端點
- - 不限數量的金鑰(免費和付費方案)
- - 彈性的備援選項
- - [公共端點](https://eth.drpc.org)
- - 免費共享歸檔節點
+- [**dRPC**](https://drpc.org/)
+ - [文件](https://drpc.org/docs)
+ - NodeCloud:隨插即用的 RPC 基礎架構,10 美元起——全速,無限制
+ - NodeCloud 功能特色:
+ - 為 185 個網路提供 API 支援
+ - 超過 40 家供應商的分散式池
+ - 九 (9) 個地理叢集提供全球覆蓋
+ - AI 驅動的負載平衡系統
+ - 按用量付費的統一價格——不漲價、不過期、不鎖定
+ - 無限金鑰、精細的金鑰調整、團隊角色、前端保護
+ - 每個方法 20 個計算單元 (CU) 的統一費率
+ - [公用端點鏈清單](https://drpc.org/chainlist)
+ - [價格計算機](https://drpc.org/pricing#calculator)
+ - NodeCore:為希望完全控制的組織提供的開源堆疊
- [**GetBlock**](https://getblock.io/)
- [文件](https://getblock.io/docs/get-started/authentication-with-api-key/)
@@ -184,7 +197,7 @@ sidebarDepth: 2
- 技術支援
- [**InfStones**](https://infstones.com/)
- - 特色功能
+ - 功能
- 免費方案選項
- 隨時擴容
- 分析
@@ -197,7 +210,7 @@ sidebarDepth: 2
- [**Infura**](https://infura.io/)
- [文件](https://infura.io/docs)
- - 特色功能
+ - 功能
- 免費方案選項
- 隨時擴容
- 付費歸檔資料
@@ -206,28 +219,28 @@ sidebarDepth: 2
- [**Kaleido**](https://kaleido.io/)
- [文件](https://docs.kaleido.io/)
- - 特徵
+ - 功能
- 免費新手方案
- 一鍵部署以太坊節點
- - 可自訂的用戶端與演算法(Geth、 Quorum 和 Besu || PoA、IBFT 和 Raft)
+ - 可自訂的用戶端和演算法 (Geth、Quorum 和 Besu / PoA、IBFT 和 Raft)
- 超過 500 個管理與服務應用程式介面
- 用於以太坊交易提交的 RESTful 介面(Apache Kafka 支援)
- 用於事件傳遞的出站串流(Apache Kafka 支援)
- - 「鏈下」與輔助服務(例如雙層加密訊息傳輸)的深度集合
+ - 「鏈下」和輔助服務的深度集合 (例如,雙向加密訊息傳輸)
- 透過管理體系和基於角色的存取控制實現簡單的網路接入
- 面向管理員與終端使用者的精細使用者管理
- 高度可擴充、有彈性的企業級基礎設施
- 雲端 HSM 私密金鑰管理
- 以太坊主網繫連
- ISO 27k 與 SOC 2、Type 2 驗證
- - 動態執行階段配置(例如新增雲端整合、變更節點入口等等)
+ - 動態執行階段組態 (例如,新增雲端整合、變更節點入口等)
- 支援多雲端、多區域和混合部署編排
- 單純按小時的基於 SaaS 的定價
- SLA 與全年無休支援
- [**Lava Network**](https://www.lavanet.xyz/)
- [文件](https://docs.lavanet.xyz/)
- - 特徵
+ - 功能
- 免費使用測試網
- 支援高正常運行時間的去中心化冗餘
- 開源
@@ -274,11 +287,11 @@ sidebarDepth: 2
- 功能
- 去中央化遠端程序中呼叫協定與市場
- 免費方案每天 100 萬個請求(每個端點,最大為 2)
- - [公共端點](https://docs.pokt.network/developers/public-endpoints)
+ - [公用端點](https://docs.pokt.network/developers/public-endpoints)
- Pre-Stake+ 計畫(如果你每天需要超過 100 萬個請求)
- 支援超過 15 條區塊鏈
- 6400+ 節點透過服務應用程式賺取 POKT 幣
- - 歸檔節點、具追蹤功能的歸檔節點和測試網節點支援
+ - 封存節點、具追蹤功能的封存節點和測試網節點支援
- 以太坊主網節點用戶端多樣性
- 無單點故障
- 零停機時間
@@ -288,20 +301,20 @@ sidebarDepth: 2
- 隨時無限擴充每天的請求數和每小時的節點數
- 最私密、抗審查之選項
- 實際開發者支援
- - [Pocket Portal](https://bit.ly/ETHorg_POKTportal) 儀表板和分析
+ - [Pocket Portal](https://bit.ly/ETHorg_POKTportal) 儀表板與分析
- [**QuickNode**](https://www.quicknode.com)
- [文件](https://www.quicknode.com/docs/)
- 功能
- - 全年無休技術支援和 Discord 開發者社群
+ - 全年無休技術支援與開發者 Discord 社群
- 平衡地理分佈、多雲端/伺服器的環境、低延遲的網路
- 支援多鏈(Optimism、Arbitrum、Polygon 及另外 11 條鏈)
- - 快速穩定的中間層(呼叫路由、快取、索引)
+ - 用於提升速度和穩定性的中介層 (呼叫路由、快取、索引)
- 透過 Webhook 監控智慧型合約
- 直覺化的儀表板、分析套件、遠端程序呼叫編寫器
- 進階安全功能(JWT、遮罩、白名單)
- 非同質化代幣資料及分析應用程式介面
- - [已獲得 SOC2 認證](https://www.quicknode.com/security)
+ - [SOC2 認證](https://www.quicknode.com/security)
- 適合開發者和企業
- [**Rivet**](https://rivet.cloud/)
@@ -350,7 +363,7 @@ sidebarDepth: 2
- [**Tokenview**](https://services.tokenview.io/)
- [文件](https://services.tokenview.io/docs?type=nodeService)
- 功能
- - 全年無休技術支援和 Telegram 開發者社群
+ - 全年無休技術支援與開發者 Telegram 社群
- 支援多鏈(比特幣、以太坊、波場、BNB 智能鏈、以太坊經典)
- 遠端程序呼叫和 WSS 端點均開放使用
- 無限制存取歸檔資料應用程式介面
@@ -384,14 +397,13 @@ sidebarDepth: 2
- [文件](https://www.zeeve.io/docs/)
- 功能
- 企業級的無程式碼自動化平臺,提供了部署、監測和管理區塊鏈節點和網路的功能
- - 支援及整合超過 30 個以上協定,持續增加中
+ - 支援並整合超過 30 種協定,且持續增加中
- 增值 Web3 基礎設施服務,如去中心化儲存、去中心化身份和用於現實世界的區塊鏈帳本資料應用程度介面
- 全年無休支援和主動監控以確保節點健康。
- 遠端程序呼叫端點提供了經驗證的應用程式介面存取,透過直覺式的儀表板和分析輕鬆愉快地進行管理。
- 提供託管雲端服務和使用自己的雲端服務兩種選項,支援所有主流的雲端提供商,如 AWS、Azure、Google Cloud、Digital Ocean 和本地部署雲端。
- 我們總是使用智慧路由以連接最靠近你的使用者的節點
-
## 延伸閱讀 {#further-reading}
- [以太坊節點服務清單](https://ethereumnodes.com/)
@@ -400,7 +412,7 @@ sidebarDepth: 2
- [節點和用戶端](/developers/docs/nodes-and-clients/)
-## 相關教程 {#related-tutorials}
+## 相關教學 {#related-tutorials}
- [使用 Alchemy 開始以太坊開發](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/)
-- [使用 web3 和 Alchemy 發送交易的指南](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
+- [使用 web3 和 Alchemy 傳送交易的指南](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
diff --git a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/run-a-node/index.md
index 595e89f966a..73565e5c540 100644
--- a/public/content/translations/zh-tw/developers/docs/nodes-and-clients/run-a-node/index.md
+++ b/public/content/translations/zh-tw/developers/docs/nodes-and-clients/run-a-node/index.md
@@ -7,35 +7,36 @@ sidebarDepth: 2
運行你自己的節點可以為你帶來各種好處,開闢新的可能性,並有助於支援生態系統。 本頁將引導你啟動自己的節點並參與驗證以太坊交易。
-注意,在[合併](/roadmap/merge)之後,需要兩個用戶端來運行一個以太坊節點:一個**執行層 (EL)** 用戶端,以及一個**共識層 (CL)** 用戶端。 本頁將展示如何安装、配置和連接這兩種用戶端以運行以太坊節點。
+請注意,在[合併](/roadmap/merge)之後,需要兩個用戶端才能執行一個以太坊節點:一個**執行層 (EL)** 用戶端以及一個**共識層 (CL)** 用戶端。 本頁將展示如何安装、配置和連接這兩種用戶端以運行以太坊節點。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-你應該了解以太坊節點是什麼以及為什麼你可能想要運行用戶端。 [節點與用戶端](/developers/docs/nodes-and-clients/)中對此進行了介紹。
+你應該了解以太坊節點是什麼以及為什麼你可能想要運行用戶端。 [節點與用戶端](/developers/docs/nodes-and-clients/)中涵蓋了這個主題。
-如果你對運行節點這個主題還很陌生,或是尋找技術門檻較低的途徑,推薦你首先查看我們適合使用者的[運行以太坊節點](/run-a-node)簡介。
+如果您是執行節點的新手,或正在尋找技術性較低的途徑,我們建議您先查看我們為使用者準備的[執行以太坊節點](/run-a-node)簡介。
-## 挑選方法 {#choosing-approach}
+## 選擇方法 {#choosing-approach}
啟動節點的第一步是選擇方法。 根據要求及不同的可能性,你必須選擇(執行及共識用戶端)的用戶端實作、環境(硬體、系統),以及用戶端設定參數。
本頁將引導你做出這些決定,幫助你找到運行以太坊實例最適合的方式。
-若要從用戶端實作中進行選擇,請查看所有可用的主網就緒[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)、[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients),並瞭解[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity)。
+若要從用戶端實作中選擇,請參閱所有可用的主網就緒[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)、[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients),並了解[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity)。
-根據用戶端的[要求](#requirements),決定是否要在自己的[硬體或是雲端上](#local-vs-cloud)運行軟體。
+根據用戶端的[要求](#requirements),決定要在自己的[硬體或雲端](#local-vs-cloud)上執行軟體。
-準備好環境後,使用[初學者友好介面](#automatized-setup)或[手動](#manual-setup)使用具有進階選項的終端機安裝所選的用戶端。
+準備好環境後,使用適合新手的介面 ([自動設定](#automatized-setup)) 或[手動](#manual-setup)使用有進階選項的終端機安裝所選的用戶端。
-當節點在運行且同步時,你已經準備好[使用它](#using-the-node),但務必留意節點的[維護](#operating-the-node)。
+當節點執行和同步時,您就可以[使用它](#using-the-node)了,但請務必留意其[維護](#operating-the-node)。

### 環境與硬體 {#environment-and-hardware}
-#### 本機或雲端 {#local-vs-cloud}
+#### 本地或雲端 {#local-vs-cloud}
-以太坊用戶端可以在消費級電腦上運行,並且不需要任何如挖礦機的特殊硬體。 因此,根據你的需求,你有多種選項來部署節點。 為了簡單起見,我們考慮一下在本地實體機和雲端伺服器上都運行一個節點:
+以太坊用戶端可以在消費級電腦上運行,並且不需要任何如挖礦機的特殊硬體。 因此,根據你的需求,你有多種選項來部署節點。
+為了簡單起見,我們考慮一下在本地實體機和雲端伺服器上都運行一個節點:
- 雲端
- 提供者提供伺服器高正常運行時間和靜態公開 IP 位址
@@ -52,23 +53,23 @@ sidebarDepth: 2
#### 硬體 {#hardware}
-然而,抗審查的去中心化網路不應依賴雲端提供者。 因而,在自己的本機硬體上運行自己的節點對生態系統來說更健全。 [預估](https://www.ethernodes.org/network-types)顯示大部分節點在雲端上運行,這可能造成單點故障。
+然而,抗審查的去中心化網路不應依賴雲端提供者。 因而,在自己的本機硬體上運行自己的節點對生態系統來說更健全。 [估計](https://www.ethernodes.org/networkType/cl/Hosting)顯示大部分節點在雲端執行,這可能成為單點故障。
以太坊用戶端可以在自己的電腦、筆記型電腦、伺服器,或甚至是單板電腦上運行。 當在你的個人電腦上運行用戶端成為可能時,弄台專門運行節點的機器可以大幅提高效能和安全性,同時將最大程度上減小對你主要電腦的影響。
使用你自己的硬體非常容易。 有許多簡易的選項,適合較技術性人士的進階設定。 那麼,我們來看看在你的裝置上運行以太坊節點的要求和方法吧。
-#### 要求 {#requirements}
+#### 需求 {#requirements}
硬體要求因用戶端而異,但通常不會那麼高,因為節點只需要保持同步。 請別和挖礦搞混了,挖礦需要的算力遠高於此。 然而,使用更強大的硬體,同步時間和效能確實會提高。
在安裝任何用戶端之前,請確保你的電腦有足夠的資源來運行用戶端。 你可以在下方找到最低和推薦的硬體要求。
-硬體瓶頸主要是磁碟空間。 同步以太坊區塊鏈是輸入/輸出非常密集的操作,且需要大量空間。 最佳選擇是使用在同步完畢後仍有數百 GB 空間的**固態硬碟 (SSD)**。
+硬體瓶頸主要是磁碟空間。 同步以太坊區塊鏈是輸入/輸出非常密集的操作,且需要大量空間。 最好有一個**固態硬碟 (SSD)**,即使在同步後仍有數百 GB 的可用空間。
-資料庫的大小及初始同步速度視使用的用戶端、設定及[同步策略](/developers/docs/nodes-and-clients/#sync-modes)而定。
+資料庫的大小和初始同步的速度,取決於所選的用戶端、其設定和[同步策略](/developers/docs/nodes-and-clients/#sync-modes)。
-也請確保你的網路連線不受[帶寬上限](https://wikipedia.org/wiki/Data_cap)的限制。 建議使用不按流量計費的連線,因為初始同步和廣播到網路的資料可能會超出你的限制。
+另外,請確保您的網際網路連線沒有[頻寬上限](https://wikipedia.org/wiki/Data_cap)的限制。 建議使用不按流量計費的連線,因為初始同步和廣播到網路的資料可能會超出你的限制。
##### 作業系統
@@ -90,17 +91,17 @@ sidebarDepth: 2
你選擇的同步模式及用戶端將影響所需磁碟空間,我們在下表估計了每個用戶端所需的磁碟空間。
-| 客戶 | 磁碟空間(快速同步) | 磁碟空間(完整歸檔) |
-| ---------- | ---------- | ---------- |
-| Besu | 800GB 以上 | 12TB 以上 |
-| Erigon | 不適用 | 2.5TB 以上 |
-| Geth | 500GB 以上 | 12TB 以上 |
-| Nethermind | 500GB 以上 | 12TB 以上 |
-| Reth | 不適用 | 2.2TB 以上 |
+| 用戶端 | 磁碟空間(快速同步) | 磁碟空間(完整歸檔) |
+| ---------- | ---------- | ------------------------ |
+| Besu | 800GB 以上 | 12TB 以上 |
+| Erigon | 不適用 | 2.5TB 以上 |
+| Geth | 500GB 以上 | 12TB 以上 |
+| Nethermind | 500GB 以上 | 12TB 以上 |
+| Reth | 不適用 | 2.2TB 以上 |
- 注意:Erigon 和 Reth 不提供快照同步,但支援完全修剪(Erigon 約 2TB,Reth 約 1.2TB)
-至於共識用戶端,所需硬碟容量也視用戶端實作及啟用的功能而定 (如罰沒驗證者的功能),但通常還需要額外的 200G 以儲存信標資料。 由於龐大的驗證者數量,帶寬負載也隨之增長。 你可以[在此分析中找到有關共識用戶端要求的詳細資料](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc)。
+對於共識用戶端,空間需求也取決於用戶端實作和啟用的功能 (例如,驗證程式懲罰者),但通常需要額外 200GB 的空間來儲存信標資料。 由於龐大的驗證者數量,帶寬負載也隨之增長。 您可以在[此分析中找到關於共識用戶端需求的詳細資訊](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc)。
#### 隨插即用解決方案 {#plug-and-play}
@@ -109,9 +110,9 @@ sidebarDepth: 2
- [DappNode](https://dappnode.io/)
- [Avado](https://ava.do/)
-#### 單板電腦上的以太坊 {#ethereum-on-a-single-board-computer}
+#### 在單板電腦上執行以太坊 {#ethereum-on-a-single-board-computer}
-使用單板電腦是其中一種能便利、便宜運行以太坊節點的方式,甚至可以使用 ARM 架構的開發板,如樹莓派。 [ARM 架構上的以太坊](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)為樹莓派及其他 ARM 開發板提供了多個執行用戶端和共識用戶端的簡單易用映像檔。
+使用單板電腦是其中一種能便利、便宜運行以太坊節點的方式,甚至可以使用 ARM 架構的開發板,如樹莓派。 [ARM 上的以太坊](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)為 Raspberry Pi 和其他 ARM 板提供了多個執行用戶端和共識用戶端的易於執行的映像檔。
這類小型、平價且高效的裝置對在家運行節點是非常理想的,不過要注意的是它們效能有限。
@@ -127,13 +128,14 @@ sidebarDepth: 2
以下是一些只要點按幾下就能幫助你安裝並控制用戶端的專案:
-- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNode 並非只能使用供應商提供的機器。 軟體、實際節點啟動器和擁有許多功能的控制中心可在任意硬體上使用。
-- [eth-docker](https://eth-docker.net/) - 使用 Docker 進行自動化設定,專注於打造輕鬆安全的質押體驗,需要對終端機和 Docker 有基本認識,適合較進階的使用者。
-- [Stereum](https://stereum.net/ethereum-node-setup/) - 該啟動器具有圖形化使用者介面設定指南、控制中心以及許多其他功能,可透過 SSH 連接在遠端伺服器上安裝用戶端。
-- [NiceNode](https://www.nicenode.xyz/) - 該啟動器提供直覺化使用者體驗,可在你的電腦上運行節點。 只要選擇用戶端並簡單點按幾下即可啟動。 仍在開發中。
-- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - 該節點設定工具使用 CLI 精靈自動產生 Docker 設定文件。 由 Nethermind 使用 Go 語言開發。
+- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNode 不僅僅是來自供應商的機器。 軟體、實際節點啟動器和擁有許多功能的控制中心可在任意硬體上使用。
+- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) - 設定完整節點最快、最簡單的方法。 單行設置工具和節點管理 TUI。 免費。 開源. 由單獨質押者提供的以太坊公共物品。 ARM64 和 AMD64 支援。
+- [eth-docker](https://eth-docker.net/) - 使用 Docker 的自動化設定,專注於簡單安全的質押,需要基本的終端機和 Docker 知識,建議給較進階的使用者。
+- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) - 透過 SSH 連線在遠端伺服器上安裝用戶端的啟動器,附有 GUI 設定指南、控制中心和許多其他功能。
+- [NiceNode](https://www.nicenode.xyz/) - 一款啟動器,提供直觀的使用者體驗,可在您的電腦上執行節點。 只要選擇用戶端並簡單點按幾下即可啟動。 仍在開發中。
+- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - 節點設定工具,使用 CLI 精靈自動產生 Docker 設定。 由 Nethermind 使用 Go 語言開發。
-### 手動用戶端設定 {#manual-setup}
+### 手動設定用戶端 {#manual-setup}
另一個選擇是手動下載、驗證並設定用戶端軟體。 即使一些用戶端提供圖形介面,手動設定仍需要對終端機有基本認識,不過也提供了更多功能。
@@ -141,7 +143,7 @@ sidebarDepth: 2
#### 取得用戶端軟體 {#getting-the-client}
-首先,你需要取得你偏好的[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)及[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients)軟體。
+首先,您需要取得您偏好的[執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)和[共識用戶端](/developers/docs/nodes-and-clients/#consensus-clients)軟體。
你只須下載符合你作業系統和架構的可執行應用程式或安裝包。 總是驗證下載的安裝包的簽名和校驗和。 有些用戶端也提供程式碼儲存庫或 Docker 映像檔,使安裝及更新更容易。 所有的用戶端都是開源的,所以你可以從原始碼開始建構。 這是較進階的方法,但在某些情況下可能是必要的。
@@ -149,7 +151,7 @@ sidebarDepth: 2
以下是一些用戶端的版本發佈頁面,你可以在此找到預先建置的二進位檔案或安裝說明:
-##### 執行客戶
+##### 執行用戶端
- [Besu](https://github.com/hyperledger/besu/releases)
- [Erigon](https://github.com/ledgerwatch/erigon/releases)
@@ -159,23 +161,23 @@ sidebarDepth: 2
值得注意的是,用戶端多樣性是[執行層上的一個問題](/developers/docs/nodes-and-clients/client-diversity/#execution-layer)。 建議讀者們考慮運行小眾執行用戶端。
-##### 共識客戶
+##### 共識用戶端
- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest)
-- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source/)(並未提供預先建置的二進位檔案,只有一個 Docker 映像檔,或者自行編譯原始碼)
+- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source) (不提供預先建置的二進位檔,只有 Docker 映像檔或從原始碼建置)
- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest)
- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest)
- [Teku](https://github.com/ConsenSys/teku/releases)
-[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity/)對運行驗證者的共識節點來說非常重要。 如果大多驗證者都運行單一用戶端,網路安全將面臨風險。 因此,建議可以考慮選擇小眾用戶端。
+[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity/)對於執行驗證程式的共識節點至關重要。 如果大多驗證者都運行單一用戶端,網路安全將面臨風險。 因此,建議可以考慮選擇小眾用戶端。
-[查看最新的網路用戶端使用情況](https://clientdiversity.org/)並瞭解關於[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity)的更多資訊。
+[查看最新的網路用戶端使用情況](https://clientdiversity.org/)並深入了解[用戶端多樣性](/developers/docs/nodes-and-clients/client-diversity)。
##### 驗證軟體
從網際網路上下載軟體時,建議驗證其完整性。 這個步驟是可選的,但對於諸如以太坊用戶端等重要基礎設施,了解並避免潛在的攻擊非常重要。 如果你下載了預先建置的二進位檔案,你需要信任它並承擔攻擊者將其替換成惡意檔案的風險。
-開發者使用他們的 PGP 金鑰簽署發佈的二進位檔案,如此一來你就可以使用密碼學方式驗證你運行的是他們建立的軟體。 你只需要獲得開發者使用的公鑰,這些公鑰可以在用戶端發佈頁面或文件中找到。 在下載用戶端版本及其簽名後,你可以使用 PGP 實作,如 [GnuPG](https://gnupg.org/download/index.html) 來輕鬆驗證用戶端。 查看在 [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) 或 [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/) 上使用 `gpg` 驗證開源軟體的教學。
+開發者使用他們的 PGP 金鑰簽署發佈的二進位檔案,如此一來你就可以使用密碼學方式驗證你運行的是他們建立的軟體。 你只需要獲得開發者使用的公鑰,這些公鑰可以在用戶端發佈頁面或文件中找到。 下載用戶端發行版及其簽章後,您可以使用 PGP 實作 (例如 [GnuPG](https://gnupg.org/download/index.html)) 來輕鬆地驗證它們。 請查看在 [Linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) 或 [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/) 上使用 `gpg` 驗證開源軟體的教學。
另一種驗證方式是確定你下載軟體的雜湊(獨一無二的密碼學指紋)和開發者提供的雜湊相符。 這比使用 PGP 進行驗證更加容易,有些用戶端也只提供此選項。 只需對下載的軟體運行雜湊函數,並將其與軟體發佈頁面的雜湊比較即可。 例如:
@@ -189,11 +191,11 @@ sha256sum teku-22.6.1.tar.gz
在安裝、下載或編譯用戶端軟體後,你就可以執行用戶端了。 這只表示需要用正確的設定執行用戶端。 用戶端提供了豐富的設定選項,可用於啟用各種功能。
-我們從會大幅影響用戶端效能和資料使用的選項開始。 [同步模式](/developers/docs/nodes-and-clients/#sync-modes)代表下載和驗證區塊鏈資料的不同方法。 在啟動節點之前,你應該決定要使用什麼網路和同步模式。 應考慮的最重要部分是用戶端所需的磁碟空間和同步時間。 留意用戶端的文件以確認預設的同步模式是哪種。 如果預設同步模式不適合你,可以視安全層級、可用資料及支出,以挑選其他同步模式。 除了同步演算法外,你還可以設定不同類型舊資料的修剪。 修剪可以刪除過時的資料,例如刪除最近區塊中無法存取的狀態樹節點。
+我們從會大幅影響用戶端效能和資料使用的選項開始。 [同步模式](/developers/docs/nodes-and-clients/#sync-modes)代表下載和驗證區塊鏈資料的不同方法。 在啟動節點之前,你應該決定要使用什麼網路和同步模式。 應考慮的最重要部分是用戶端所需的磁碟空間和同步時間。 留意用戶端的文件以確認預設的同步模式是哪種。 如果預設同步模式不適合你,可以視安全層級、可用資料及支出,以挑選其他同步模式。 除了同步演算法外,你還可以設定不同類型舊資料的修剪。 修剪可以刪除過時的資料,即移除最近區塊無法存取的狀態樹節點。
-其他基礎設定選項範例包括:選擇網路 - 主網或測試網、為遠端程序呼叫或 WebSocket 啟用超文字傳輸協定端點等等。 你可以在用戶端文件上找到所有功能和選項。 可以直接在命令列介面或設定檔中使用對應的標記,來設定各種用戶端設定。 每個用戶端略有差異,請務必參考官方文件或幫助頁面以獲得設定選項的細節。
+其他基本設定選項包括:選擇網路 (主網或測試網)、為 RPC 或 WebSocket 啟用 HTTP 端點等。 你可以在用戶端文件上找到所有功能和選項。 可以直接在命令列介面或設定檔中使用對應的標記,來設定各種用戶端設定。 每個用戶端略有差異,請務必參考官方文件或幫助頁面以獲得設定選項的細節。
-為了測試,你可能偏好在測試網上運行用戶端。 [參閱受支援網路的概覽](/developers/docs/nodes-and-clients/#execution-clients)。
+為了測試,你可能偏好在測試網上運行用戶端。 [查看支援的網路概覽](/developers/docs/nodes-and-clients/#execution-clients)。
在基礎設定下運行執行用戶端的範例請見下個章節。
@@ -211,34 +213,34 @@ sha256sum teku-22.6.1.tar.gz
你需要在開始時宣告所有非預設的用戶端設定。 你可以使用標記或設定檔來宣告你的偏好設定。 功能組和設定語法因用戶端而異。 請查看你的用戶端的文件,以了解細節。
-執行和共識用戶端透過[引擎應用程式介面](https://github.com/ethereum/execution-apis/tree/main/src/engine)中指定的經驗證端點通訊。 要連接至共識用戶端,執行用戶端必須在已知路徑上產生一個 [`jwtsecret`](https://jwt.io/)。 鑑於安全性及穩定性,用戶端應在同一個機器上運行,且兩個用戶端必須都知道此路徑,因為此路徑用於驗證它們之間的本地遠端程序呼叫連接。 執行用戶端也必須為經過驗證的應用程式介面定義一個偵聽連接埠。
+執行用戶端和共識用戶端透過 [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine) 中指定的已驗證端點進行通訊。 為了連接到共識用戶端,執行用戶端必須在已知路徑產生一個 [`jwtsecret`](https://jwt.io/)。 鑑於安全性及穩定性,用戶端應在同一個機器上運行,且兩個用戶端必須都知道此路徑,因為此路徑用於驗證它們之間的本地遠端程序呼叫連接。 執行用戶端也必須為經過驗證的應用程式介面定義一個偵聽連接埠。
-此驗證權杖由用戶端軟體自動產生,但某些情況下,你可能需要自行手動產生。 你可以透過 [OpenSSL](https://www.openssl.org/) 產生它:
+此驗證權杖由用戶端軟體自動產生,但某些情況下,你可能需要自行手動產生。 您可以使用 [OpenSSL](https://www.openssl.org/) 來產生它:
```sh
openssl rand -hex 32 > jwtsecret
```
-#### 運行執行用戶端 {#running-an-execution-client}
+#### 執行執行用戶端 {#running-an-execution-client}
此章節將引導你啟動執行用戶端。 它僅做為基本設定的範例,此範例會以下列設定啟動用戶端:
- 指定欲連線的網路,在此例子中為主網
- - 你可以選擇[任意一個測試網](/developers/docs/networks/),以初步測試你的設定
+ - 您可以改為選擇[其中一個測試網](/developers/docs/networks/)來對您的設定進行初步測試。
- 定義資料目錄,用於儲存所有包含區塊鏈的資料
- - 請確保將預設路徑替換成真實路徑:如指向你外部硬碟的路徑
+ - 請務必用真實路徑替換,例如指向您的外部硬碟。
- 啟用與用戶端通訊的介面
- 包括用於與共識用戶端通訊的 JSON-RPC 和引擎應用程式介面
-- 定義經過驗證的應用程式介面的 `jwtsecret` 路徑
- - 請確保將範例路徑替換成用戶端能夠存取的真實路徑,如:`/tmp/jwtsecret`
+- 為已驗證的 API 定義 `jwtsecret` 的路徑。
+ - 請務必將範例路徑替換為用戶端可以存取的真實路徑,例如 `/tmp/jwtsecret`。
請注意,這只是基本的範例,其餘的設定都會被設為預設值。 仔細閱讀各個用戶端的文件,以了解預設值、設定及功能。 關於更多其他功能,如運行驗證者、監控等等,請參考特定用戶端的文件。
-> 請注意,範例中的反斜線 `\` 僅用於設定格式;設定標記可以在單行內定義。
+> 請注意,範例中的反斜線 `\` 僅用於格式化目的;設定旗標可以在單行中定義。
##### 運行 Besu
-此範例在主網上運行 Besu,將區塊鏈資料以預設格式儲存在 `/data/ethereum`,啟用 JSON-RPC 及引擎遠端程序呼叫以連線至共識用戶端。 引擎應用程式介面使用 `jwtsecret` 權杖驗證,且只允許來自 `localhost` 的呼叫。
+此範例在主網上啟動 Besu,將區塊鏈資料以預設格式儲存在 `/data/ethereum`,並為連接共識用戶端啟用 JSON-RPC 和 Engine RPC。 Engine API 使用 `jwtsecret` 權杖進行驗證,且只允許來自 `localhost` 的呼叫。
```sh
besu --network=mainnet \
@@ -256,11 +258,11 @@ Besu 還有個啟動器選項,會詢問一系列問題並產生設定檔案。
besu --Xlauncher
```
-[Besu 的文件](https://besu.hyperledger.org/public-networks/get-started/start-node/)包含了額外的選項及設定細節。
+[Besu 的文件](https://besu.hyperledger.org/public-networks/get-started/start-node/)包含額外的選項和設定細節。
##### 運行 Erigon
-此範例在主網上運行 Erigon,將區塊鏈資料儲存在 `/data/ethereum`,啟用 JSON-RPC,定義了哪些命名空間是允許的,並啟用連線由 `jwtsecret` 路徑定義的共識用戶端時的身份驗證。
+此範例在主網上啟動 Erigon,將區塊鏈資料儲存在 `/data/ethereum`,啟用 JSON-RPC,定義允許哪些命名空間,並為連接由 `jwtsecret` 路徑定義的共識用戶端啟用驗證。
```sh
erigon --chain mainnet \
@@ -269,11 +271,11 @@ erigon --chain mainnet \
--authrpc.jwtsecret=/path/to/jwtsecret
```
-Erigon 預設與 8GB 的硬碟執行完整同步,這會產生超過 2TB 的歸檔資料。 請確保 `datadir` 指向的磁碟有充足的剩餘空間,或者考慮使用可以修剪不同類型資料的 `--prune` 標記。 參考 Erigon 的 `--help` 指令以獲得更多資訊。
+Erigon 預設與 8GB 的硬碟執行完整同步,這會產生超過 2TB 的歸檔資料。 請確保 `datadir` 指向有足夠可用空間的磁碟,或研究可以修剪不同類型資料的 `--prune` 旗標。 查看 Erigon 的 `--help` 以了解更多資訊。
##### 運行 Geth
-此範例在主網上運行 Geth,將區塊鏈資料儲存在 `/data/ethereum`,啟用 JSON-RPC 並定義了哪些命名空間是允許的。 它也啟用了連接至共識用戶端的身份驗證,這需要 `jwtsecrest` 路徑並可以選擇定義哪些連接是允許的,在這個例子中,只允許 `localhost`。
+此範例在主網上啟動 Geth,將區塊鏈資料儲存在 `/data/ethereum`,啟用 JSON-RPC 並定義允許的命名空間。 它還為連接共識用戶端啟用驗證,這需要 `jwtsecret` 的路徑,以及定義允許哪些連線的選項,在我們的範例中僅允許來自 `localhost` 的連線。
```sh
geth --mainnet \
@@ -284,11 +286,11 @@ geth --mainnet \
--authrpc.jwtsecret=/path/to/jwtsecret
```
-查看[文檔以了解所有設定選項](https://geth.ethereum.org/docs/fundamentals/command-line-options)並了解更多與[與共識用戶端一起運行 Geth](https://geth.ethereum.org/docs/getting-started/consensus-clients) 相關的資訊。
+查看[所有設定選項的文件](https://geth.ethereum.org/docs/fundamentals/command-line-options),並深入了解[如何與共識用戶端一起執行 Geth](https://geth.ethereum.org/docs/getting-started/consensus-clients)。
##### 運行 Nethermind
-Nethermind 提供多種 [安裝選項](https://docs.nethermind.io/get-started/installing-nethermind)。 此套件包含許多二進位檔案,包括有引導式設定的啟動器,可以互動式幫助你建立設定。 或者,你可以找到可執行執行器,並使用設定標記執行它。 JSON-RPC 是預設啟用的。
+Nethermind 提供多種[安裝選項](https://docs.nethermind.io/get-started/installing-nethermind)。 此套件包含許多二進位檔案,包括有引導式設定的啟動器,可以互動式幫助你建立設定。 或者,你可以找到可執行執行器,並使用設定標記執行它。 JSON-RPC 是預設啟用的。
```sh
Nethermind.Runner --config mainnet \
@@ -296,13 +298,13 @@ Nethermind.Runner --config mainnet \
--JsonRpc.JwtSecretFile=/path/to/jwtsecret
```
-Nethermind 文檔提供了與共識用戶端一起運行 Nethermind 的 [完整指南](https://docs.nethermind.io/get-started/running-node/)。
+Nethermind 文件提供了一份關於如何與共識用戶端一起執行 Nethermind 的[完整指南](https://docs.nethermind.io/get-started/running-node/)。
執行用戶端會啟用它的核心功能、選擇端點並開始尋找對等用戶端。 成功發現對等用戶端後,用戶端開始同步。 執行用戶端會等待來自共識用戶端的連接。 在用戶端成功與目前狀態同步以後,目前的區塊鏈資料就可以使用。
##### 運行 Reth
-此範例在主網上運行 Reth,使用預設的資料儲存路徑。 啟用 JSON-RPC 和引擎遠端程序呼叫驗證,以連線由 `jwtsecret` 路徑定義的共識用戶端,並且僅允許來自 `localhost` 的調用。
+此範例在主網上運行 Reth,使用預設的資料儲存路徑。 為連接由 `jwtsecret` 路徑定義的共識用戶端啟用 JSON-RPC 和 Engine RPC 驗證,僅允許來自 `localhost` 的呼叫。
```sh
reth node \
@@ -311,23 +313,23 @@ reth node \
--authrpc.port 8551
```
-查看[設定 Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) 以了解更多有關預設資料目錄的資訊。 [Besu 文件](https://reth.rs/run/mainnet.html)包含了額外的選項及設定細節。
+請參閱 [設定 Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) 以了解更多關於預設資料目錄的資訊。 [Reth 的文件](https://reth.rs/run/mainnet.html)包含額外的選項和設定細節。
#### 啟動共識用戶端 {#starting-the-consensus-client}
共識用戶端必須在正確的連接埠設定下啟動,以建立與執行用戶端的本地遠端程序呼叫連接。 共識用戶端在執行時需要使用公開的執行用戶端通訊埠作為設定參數。
-共識用戶端還需要執行用戶端 `jwt-secret` 的路徑,以驗證它們之間的遠端程序呼叫連接。 與上述執行用戶端例子相似,每個共識用戶端都有一個設定標記,將 jwt 權杖檔案路徑做為參數。 此路徑需與提供執行用戶端的 `jwtsecret` 路徑保持一致。
+共識用戶端也需要執行用戶端的 `jwt-secret` 路徑,以便對它們之間的 RPC 連線進行驗證。 與上述執行用戶端例子相似,每個共識用戶端都有一個設定標記,將 jwt 權杖檔案路徑做為參數。 此路徑必須與提供給執行用戶端的 `jwtsecret` 路徑一致。
-如果你打算運行驗證者,請確保新增一個用作以太坊費用接收地址的設定標記。 這是你的驗證者累積以太幣獎勵的地方。 每個共識用戶端都有一個接受一個以太坊地址作為參數的選項,如:`--suggested-fee-recipient=0xabcd1`。
+如果你打算運行驗證者,請確保新增一個用作以太坊費用接收地址的設定標記。 這是你的驗證者累積以太幣獎勵的地方。 每個共識用戶端都有一個選項,例如 `--suggested-fee-recipient=0xabcd1`,它接受一個以太坊地址作為引數。
-當在測試網上開始運行信標節點時,藉由[檢查點同步](https://notes.ethereum.org/@launchpad/checkpoint-sync)的公共端點,可以大幅縮短同步時間。
+在測試網上啟動信標節點時,您可以使用[檢查點同步](https://notes.ethereum.org/@launchpad/checkpoint-sync)的公共端點來大幅節省同步時間。
-#### 運行共識用戶端 {#running-a-consensus-client}
+#### 執行共識用戶端 {#running-a-consensus-client}
##### 運行 Lighthouse
-在運行 Lighthouse 前,請在 [Lighthouse 手冊](https://lighthouse-book.sigmaprime.io/installation.html)中了解如何安裝並設定。
+在執行 Lighthouse 之前,請在 [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html) 中了解如何安裝和設定它。
```sh
lighthouse beacon_node \
@@ -340,11 +342,11 @@ lighthouse beacon_node \
##### 運行 Lodestar
-透過編譯 Lodestar 軟體或下載 Docker 映像檔來安裝 Lodestar 軟體。 在[文檔](https://chainsafe.github.io/lodestar/)中了解更多,在[設定指南](https://hackmd.io/@philknows/rk5cDvKmK)中獲得更完整的資訊。
+透過編譯 Lodestar 軟體或下載 Docker 映像檔來安裝 Lodestar 軟體。 在[文件](https://chainsafe.github.io/lodestar/)和更全面的[設定指南](https://hackmd.io/@philknows/rk5cDvKmK)中了解更多。
```sh
lodestar beacon \
- --rootDir="/data/ethereum" \
+ --dataDir="/data/ethereum" \
--network=mainnet \
--eth1.enabled=true \
--execution.urls="http://127.0.0.1:8551" \
@@ -353,7 +355,8 @@ lodestar beacon \
##### 運行 Nimbus
-Nimbus 包括共識用戶端與執行用戶端。 它可在各種裝置上運行,即使是性能不高的裝置。 在[安裝依賴項和 Nimbus 本體](https://nimbus.guide/quick-start.html)後,你可以透過以下指令運行共識用戶端:
+Nimbus 包括共識用戶端與執行用戶端。 它可在各種裝置上運行,即使是性能不高的裝置。
+[安裝完相依套件和 Nimbus 本身](https://nimbus.guide/quick-start.html)後,您就可以執行其共識用戶端:
```sh
nimbus_beacon_node \
@@ -365,7 +368,7 @@ nimbus_beacon_node \
##### 運行 Prysm
-Prysm 有可以輕鬆自動安裝的腳本。 詳情請見 [Prysm 文檔](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/)。
+Prysm 有可以輕鬆自動安裝的腳本。 詳細資訊可以在 [Prysm 文件](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/)中找到。
```sh
./prysm.sh beacon-chain \
@@ -384,51 +387,51 @@ teku --network mainnet \
--ee-jwt-secret-file "/path/to/jwtsecret"
```
-當共識用戶端連接至執行用戶端,並讀取存款合約以及識別驗證者時,它同時也會連接至其他對等信標節點,並從創世塊開始同步共識時隙。 當信標節點到達目前時期時,信標應用程式介面就可以供你的驗證者使用。 了解關於[信標節點應用程式介面](https://eth2docs.vercel.app/)的更多資訊。
+當共識用戶端連接至執行用戶端,並讀取存款合約以及識別驗證者時,它同時也會連接至其他對等信標節點,並從創世塊開始同步共識時隙。 當信標節點到達目前時期時,信標應用程式介面就可以供你的驗證者使用。 深入了解[信標節點 API](https://eth2docs.vercel.app/)。
-### 新增驗證者 {#adding-validators}
+### 新增驗證程式 {#adding-validators}
共識用戶端作為供驗證者連接的信標節點。 每個共識用戶端都有自己的驗證者軟體,可以在各自的文檔中找到詳細描述。
-運行自己的驗證者允許[單獨質押](/staking/solo/),單獨質押是支援以太坊的最具影響且最去信任的方法。 然而,單獨質押要求存入 32 以太幣。 若要以較少的以太幣在你自己的節點上運行驗證者,你可能會對擁有無需許可的節點營運者的去中心化質押池 (如 [Rocket Pool](https://rocketpool.net/node-operators))感興趣。
+執行您自己的驗證程式可實現[個人質押](/staking/solo/),這是支援以太坊網路最具影響力且無需信任的方法。 然而,單獨質押要求存入 32 以太幣。 若要用較少的金額在您自己的節點上執行驗證程式,您可能會對擁有無需許可的節點操作員的去中心化池感興趣,例如 [Rocket Pool](https://rocketpool.net/node-operators)。
-開始質押和產生驗證者金鑰最簡單的方法就是使用 [Holesky 測試網質押啟動面板](https://holesky.launchpad.ethereum.org/),這可讓你透過[在 Holesky 上運行節點](https://notes.ethereum.org/@launchpad/holesky)來測試你的設定。 當你準備好部署到主網時,即可使用[主網質押啟動面板](https://launchpad.ethereum.org/)重複這些步驟。
+開始進行質押和驗證程式金鑰產生的最簡單方法是使用 [Hoodi 測試網質押啟動台](https://hoodi.launchpad.ethereum.org/),它讓您可透過[在 Hoodi 上執行節點](https://notes.ethereum.org/@launchpad/hoodi)來測試您的設定。 當您準備好在主網上進行時,您可以使用[主網質押啟動台](https://launchpad.ethereum.org/)重複這些步驟。
-請見[質押頁面](/staking)以查看質押選項概覽。
+查看[質押頁面](/staking)以取得質押選項的概覽。
### 使用節點 {#using-the-node}
-執行用戶端提供了[遠端程序呼叫應用程式介面端點](/developers/docs/apis/json-rpc/),可透過多種方式提交交易、在以太坊上部署智慧型合約或與以太坊上的智慧型合約互動:
+執行用戶端提供 [RPC API 端點](/developers/docs/apis/json-rpc/),您可以用多種方式使用它們在以太坊網路上提交交易、與智能合約互動或部署智能合約:
-- 使用合適的協定手動呼叫它們(例如使用 `curl`)
-- 附加提供的控制台(例如 `geth attach`)
-- 透過 wbe3 函式庫在應用程式中實作它們,如 [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview) 及 [ethers](https://github.com/ethers-io/ethers.js/)
+- 使用合適的協定手動呼叫它們 (例如使用 `curl`)
+- 附加提供的控制台 (例如 `geth attach`)
+- 在應用程式中使用 web3 程式庫來實作它們,例如 [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview)、[ethers](https://github.com/ethers-io/ethers.js/)
-不同的用戶端有不同的遠端程序呼叫端點實作。 但是有一個標準的 JSON-RPC,可以用於每個用戶端。 有關概述,[請閱讀 JSON-RPC 文件](/developers/docs/apis/json-rpc/)。 需要從以太坊網路取得資訊的應用程式可以使用這個遠端程序呼叫。 舉例來說,熱門錢包 MetaMask 可讓你[連接至你自己的遠端程序呼叫端點](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node),提供了強大的隱私及安全優勢。
+不同的用戶端有不同的遠端程序呼叫端點實作。 但是有一個標準的 JSON-RPC,可以用於每個用戶端。 如需概覽,請[閱讀 JSON-RPC 文件](/developers/docs/apis/json-rpc/)。 需要從以太坊網路取得資訊的應用程式可以使用這個遠端程序呼叫。 例如,熱門錢包 MetaMask 讓您[連接到您自己的 RPC 端點](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node),這具有強大的隱私和安全優勢。
-共識用戶端皆會公開[信標應用程式介面](https://ethereum.github.io/beacon-APIs),可用於確認共識用戶端的狀態,或者透過工具(如 [Curl](https://curl.se))發送請求以下載區塊和共識資料。 更多資訊可在每個共識用戶端的文檔上找到。
+所有共識用戶端都會公開一個 [Beacon API](https://ethereum.github.io/beacon-APIs),可用於檢查共識用戶端的狀態,或使用 [Curl](https://curl.se) 等工具發送請求來下載區塊和共識資料。 更多資訊可在每個共識用戶端的文檔上找到。
-#### 存取遠端程序呼叫 {#reaching-rpc}
+#### 存取 RPC {#reaching-rpc}
-執行用戶端 JSON-RPC 的預設通訊埠是 `8545`,但你可以在設定中修改本地端點的通訊埠。 遠端程序呼叫介面預設只能透過你電腦的 localhost 存取。 為了要在遠端也能存取遠端程序呼叫介面,你可將位址變更為 `0.0.0.0` 將其公開。 這樣一來,就可透過本地網路以及公網 IP 位址存取遠端程序呼叫介面了。 在多數情況下,你也需要在路由器上設定通訊埠轉發。
+執行用戶端 JSON-RPC 的預設連接埠為 `8545`,但您可以在設定中修改本機端點的連接埠。 遠端程序呼叫介面預設只能透過你電腦的 localhost 存取。 為了讓它能夠遠端存取,您可能會想透過將地址變更為 `0.0.0.0` 來將其公開。 這樣一來,就可透過本地網路以及公網 IP 位址存取遠端程序呼叫介面了。 在多數情況下,你也需要在路由器上設定通訊埠轉發。
公開通訊埠至網際網路時應謹慎,因為這會使網際網路上的任何人都能控制你的節點。 如果你將用戶端作為錢包使用,惡意人士可能存取你的節點以癱瘓你的系統,或者竊取其中的資產。
-解決上述問題的辦法是,避免讓潛在的高危遠端程序呼叫方法可被修改。 舉例來說,使用 Geth 時,你可以透過標記 `--http.api web3,eth,txpool` 宣告可修改的方法。
+解決上述問題的辦法是,避免讓潛在的高危遠端程序呼叫方法可被修改。 例如,使用 Geth 時,您可以使用旗標宣告可修改的方法:`--http.api web3,eth,txpool`。
-開發邊緣層應用程式介面或網頁伺服器應用程式(如 Nginx),並將它們連接至你用戶端的本機位址及通訊埠,這可以擴展對遠端程序呼叫介面的存取方式。 透過中間層也使開發者能夠為連接至遠端程序呼叫介面的 `https` 安全連線設置憑證。
+開發邊緣層應用程式介面或網頁伺服器應用程式(如 Nginx),並將它們連接至你用戶端的本機位址及通訊埠,這可以擴展對遠端程序呼叫介面的存取方式。 利用中介層也可讓開發者能夠為到 RPC 介面的安全 `https` 連線設定憑證。
-設置網頁伺服器、代理伺服器或外部的 Rest API 並非對你節點的遠端程序呼叫端點提供存取的唯一方式。 設定可公開存取的端點的另一種保護隱私的方法是,將節點託管在自己的 [Tor](https://www.torproject.org/) 洋蔥服務上。 這可讓你在沒有靜態公共 IP 位址或開放通訊埠的情況下,仍可存取本地網路外的遠端程序呼叫。 然而,使用此設定只會允許透過 Tor 網路存取遠端程序呼叫端點,但並非所有應用程式都支援此網路,且可能造成連線問題。
+設置網頁伺服器、代理伺服器或外部的 Rest API 並非對你節點的遠端程序呼叫端點提供存取的唯一方式。 設定可公開存取之端點的另一種保護隱私的方法是,將節點託管在您自己的 [Tor](https://www.torproject.org/) 洋蔥服務上。 這可讓你在沒有靜態公共 IP 位址或開放通訊埠的情況下,仍可存取本地網路外的遠端程序呼叫。 然而,使用此設定只會允許透過 Tor 網路存取遠端程序呼叫端點,但並非所有應用程式都支援此網路,且可能造成連線問題。
-要完成設定,你需要建立自己的[洋蔥服務](https://community.torproject.org/onion-services/)。 閱讀洋蔥服務設定的[文檔](https://community.torproject.org/onion-services/setup/)以託管你自己的洋蔥服務。 你可將其指向有代理伺服器的遠端程序呼叫通訊埠網頁伺服器,或者直接指向遠端程序呼叫。
+為此,您必須建立自己的[洋蔥服務](https://community.torproject.org/onion-services/)。 查看關於設定洋蔥服務以託管您自己的服務的[文件](https://community.torproject.org/onion-services/setup/)。 你可將其指向有代理伺服器的遠端程序呼叫通訊埠網頁伺服器,或者直接指向遠端程序呼叫。
-最後一種提供內部網路存取的方式是透過虛擬私人網路連線,這同時也是最受歡迎的一種方式。 依據你的用例,以及需要存取你的節點的使用者數量,安全的虛擬私人網路連線或許是個可選方案。 [OpenVPN](https://openvpn.net/) 是功能完備的 SSL VPN,使用業界標準的 SSL/TSL 協議實現了 OSI 第二、三層的安全網路插件,且支援基於證書、智慧卡和/或使用者名稱/密碼等彈性用戶端驗證方法,並可以使用基於使用者或群組的存取控制政策,該政策使用套用於虛擬私人網路虛擬介面的防火牆規則。
+最後一種提供內部網路存取的方式是透過虛擬私人網路連線,這同時也是最受歡迎的一種方式。 依據你的用例,以及需要存取你的節點的使用者數量,安全的虛擬私人網路連線或許是個可選方案。 [OpenVPN](https://openvpn.net/) 是一種功能齊全的 SSL VPN,它使用業界標準的 SSL/TLS 協定實作 OSI 第 2 層或第 3 層的安全網路延伸,支援基於憑證、智慧卡和/或使用者名稱/密碼憑證的彈性用戶端驗證方法,並允許使用套用到 VPN 虛擬介面的防火牆規則來制定使用者或群組特定的存取控制策略。
-### 運行節點 {#operating-the-node}
+### 操作節點 {#operating-the-node}
你應該定期監控你的節點以確保其正常運行。 你可能需要偶爾進行維護。
-#### 維持節點上線 {#keeping-node-online}
+#### 保持節點在線 {#keeping-node-online}
你的節點不需要一直保持上線,但應儘可能維持它的上線狀態,以持續與網路同步。 你可以關閉它並重啟,但請記得:
@@ -436,45 +439,46 @@ teku --network mainnet \
- 強制關閉可能會損害資料庫,這樣可能必須重新同步整個節點。
- 你的用戶端將與網路不同步,並且在重新啟動時需要重新同步。 雖然節點可以從上次關閉時的地方開始同步,但此流程會依離線的時長而定。
-_這不適用於共識層驗證者節點。_節點離線將影響所有依賴節點的服務。 如果你是為了_質押_而運行節點,應該儘可能降低停機時間。
+_這不適用於共識層驗證程式節點。_ 讓您的節點離線會影響所有依賴它的服務。 如果您是為了_質押_而執行節點,您應該盡可能地減少停機時間。
#### 建立用戶端服務 {#creating-client-services}
-考慮建立一個在啟動時自動運行你的用戶端的服務。 例如,在 Linux 伺服器上,最佳案例為建立一個服務(如透過 `systemmd`),它會在適當設定的情況下執行用戶端,可限制使用者權限並自動重啟。
+考慮建立一個在啟動時自動運行你的用戶端的服務。 例如,在 Linux 伺服器上,一個好的做法是建立一個服務 (例如使用 `systemd`),該服務以有限權限的使用者身分使用適當的設定檔執行用戶端,並會自動重新啟動。
#### 更新用戶端 {#updating-clients}
-你需要確保透過安全補丁、功能與[以太坊改善提議](/eips/)讓你的用戶端軟體保持最新。 特別是[硬分叉](/ethereum-forks/)前,請確保你運行的是正確的用戶端版本。
+您需要讓您的用戶端軟體保持最新狀態,包含最新的安全性修補程式、功能和 [EIP](/eips/)。 特別是在[硬分叉](/ethereum-forks/)之前,請確保您執行的是正確的用戶端版本。
-> 在重大的網路更新前,以太坊基金會在它們的[部落格](https://blog.ethereum.org)上發布貼文。 你可以[訂閱這些公告](https://blog.ethereum.org/category/protocol#subscribe),在你的節點需要更新時,透過電子郵件接收通知。
+> 在重要的網路更新之前,EF 會在其[部落格](https://blog.ethereum.org)上發佈一篇文章。 您可以[訂閱這些公告](https://blog.ethereum.org/category/protocol#subscribe),以便在您的節點需要更新時收到郵件通知。
更新用戶端非常簡單。 在每個用戶端的文檔中都有具體的說明,但實際上只要下載最新版的用戶端並透過最新的可執行檔重新啟動用戶端即可。 用戶端應從上次同步中斷的地方繼續同步,且完成用戶端更新。
每個用戶端實作都有用於點對點協定的人類可讀版本的字串,但也可透過指令存取該字串。 這個版本的字串可讓使用者檢查是否正執行正確的版本,並支援區塊瀏覽器和有興趣量化網路上特定用戶端的分佈的其他分析工具。 請參閱個別的用戶端文件以取得版本字串的更多資訊。
-#### 運行額外服務 {#running-additional-services}
+#### 執行額外服務 {#running-additional-services}
-運行你自己的節點,可讓你使用需要直接存取以太坊用戶端遠端程序呼叫的服務。 這些是建立在以太坊之上的服務,如[二層網路解決方案 ](/developers/docs/scaling/#layer-2-scaling)、錢包的後端、區塊鏈瀏覽器、開發者工具以及其他以太坊基礎設施。
+運行你自己的節點,可讓你使用需要直接存取以太坊用戶端遠端程序呼叫的服務。 這些是建立在以太坊上的服務,例如[第 2 層解決方案](/developers/docs/scaling/#layer-2-scaling)、錢包後端、區塊瀏覽器、開發人員工具和其他以太坊基礎設施。
#### 監控節點 {#monitoring-the-node}
-要正確監控你的節點,請考慮收集指標。 用戶端提供指標端點,因此你可以取得關於你節點的綜合資料。 使用諸如 [InfluxDB](https://www.influxdata.com/get-influxdb/) 或 [Prometheus](https://prometheus.io/) 等工具來建立資料庫,可讓你在像是 [Grafana](https://grafana.com/) 的軟體中將資料視覺化和圖表化。 使用此軟體有許多設定可以使用,還有不同的 Grafana 儀表板來將你的節點和整個網路視覺化。 詳細範例請見[監控 Geth 教學](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/)。
+要正確監控你的節點,請考慮收集指標。 用戶端提供指標端點,因此你可以取得關於你節點的綜合資料。 使用 [InfluxDB](https://www.influxdata.com/get-influxdb/) 或 [Prometheus](https://prometheus.io/) 等工具來建立資料庫,然後您可以在 [Grafana](https://grafana.com/) 等軟體中將其轉換為視覺化和圖表。 使用此軟體有許多設定可以使用,還有不同的 Grafana 儀表板來將你的節點和整個網路視覺化。 例如,查看[關於使用 InfluxDB 和 Grafana 監控 Geth 的教學](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/)。
-在監控時,請務必注意機器的效能。 在節點的初次同步期間,用戶端軟體可能會耗用大量的 CPU 和 RAM 資源。 除了 Grafana,你也可以使用其他作業系統提供的工具,像是 `htop` 或 `uptime` 來執行。
+在監控時,請務必注意機器的效能。 在節點的初次同步期間,用戶端軟體可能會耗用大量的 CPU 和 RAM 資源。 除了 Grafana,您還可以使用作業系統提供的工具 (例如 `htop` 或 `uptime`) 來執行此操作。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊質押指南](https://github.com/SomerEsat/ethereum-staking-guides) - _Somer Esat,時常更新_
-- [ 指南|如何設定用於以太坊主網上質押的驗證者](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew,經常更新_
-- [在測試網上運行驗證者的 ETHStaker 指南](https://github.com/remyroy/ethstaker#guides) – _ETHStaker,經常更新_
-- [面向節點營運者的合併常見問題](https://notes.ethereum.org/@launchpad/node-faq-merge) - _2022 年 7 月_
-- [分析以太坊完整驗證節點的硬體要求](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902)_ – Albert Palau,2018 年9 月24 日_
-- [運行以太坊全節點:針對幾乎沒有動力的人提供的指南](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31)_ – Justin Leroux,2019 年 11 月 7 日_
-- [在以太坊主網上運行 Hyperledger Besu 節點:優勢、要求和設定](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/)_ – Felipe Faraggi,2020 年 5 月 7 日_
-- [使用監控堆疊部署 Nethermind 以太坊用戶端](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _ – Nethermind.eth,2020 年 7 月 8 日_
+- [以太坊質押指南](https://github.com/SomerEsat/ethereum-staking-guides) - _Somer Esat,經常更新_
+- [指南 | 如何在主網上為以太坊質押設定驗證程式](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew,經常更新_
+- [ETHStaker 關於在測試網上執行驗證程式的指南](https://github.com/remyroy/ethstaker#guides) – _ETHStaker,定期更新_
+- [適用於以太坊節點的 AWS 區塊鏈節點執行器範例應用程式](https://aws-samples.github.io/aws-blockchain-node-runners/docs/Blueprints/Ethereum) - _AWS,經常更新_
+- [針對節點營運商的「合併」常見問答](https://notes.ethereum.org/@launchpad/node-faq-merge) - _2022 年 7 月_
+- [分析成為以太坊完整驗證節點的硬體需求](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau,2018 年 9 月 24 日_
+- [執行以太坊完整節點:一份寫給有點懶的人的指南](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux,2019 年 11 月 7 日_
+- [在以太坊主網上執行 Hyperledger Besu 節點:優點、需求和設定](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Felipe Faraggi,2020 年 5 月 7 日_
+- [部署帶有監控堆疊的 Nethermind 以太坊用戶端](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth,2020 年 7 月 8 日_
## 相關主題 {#related-topics}
- [節點和用戶端](/developers/docs/nodes-and-clients/)
-- [分塊](/developers/docs/blocks/)
+- [區塊](/developers/docs/blocks/)
- [網路](/developers/docs/networks/)
diff --git a/public/content/translations/zh-tw/developers/docs/oracles/index.md b/public/content/translations/zh-tw/developers/docs/oracles/index.md
new file mode 100644
index 00000000000..92e629ddef3
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/oracles/index.md
@@ -0,0 +1,433 @@
+---
+title: 預言機
+description: 預言機使以太坊智慧型合約得以取得現實世界的資料,替使用者增加更多使用情境以及價值。
+lang: zh-tw
+---
+
+預言機是產生數據來源的應用程式,使鏈下數據來源可供區塊鏈用於智能合約。 因為預設情況下,基於以太坊的智慧型合約無法存取儲存在區塊鏈網路外部的資訊,所以這是必要的。
+
+賦予智能合約使用鏈下數據執行的能力,擴展了去中心化應用程式的效用和價值。 例如,鏈上預測市場依靠預言機提供有關結果的信息,用於驗證用戶的預測。 假設 Alice 押注 20 以太幣打賭誰會成為下任美國 總統。 在這種情況下,預測市場去中心化應用程式需要一個預言機來確認選舉結果並確定 Alice 是否有資格獲得付款。
+
+## 先決條件 {#prerequisites}
+
+本頁假設讀者熟悉以太坊基礎知識,包括[節點](/developers/docs/nodes-and-clients/)、[共識機制](/developers/docs/consensus-mechanisms/) 和 [EVM](/developers/docs/evm/)。 您還應該對[智能合約](/developers/docs/smart-contracts/) 和[智能合約剖析](/developers/docs/smart-contracts/anatomy/) 有充分的了解,特別是[事件](/glossary/#events)。
+
+## 什麼是區塊鏈預言機? {#what-is-a-blockchain-oracle}
+
+預言機是尋找、驗證外部資訊 (即儲存在鏈外的資訊) 並將其傳輸到區塊鏈上運行的智能合約的應用程式。 除了「拉取」鏈下數據並在以太坊上廣播之外,預言機還可以將訊息從區塊鏈「推送」到外部系統,例如,一旦用戶透過以太坊交易發送費用就會解鎖智慧鎖。
+
+如果沒有預言機,智能合約將完全局限於鏈上資料。
+
+預言機依數據來源(一個或多個)、信任模型(中心化或去中心化)和系統架構(立即讀取、發布-訂閱模式和請求-回應模式)而有所不同。 我們還可以根據預言機是否檢索外部數據以供鏈上合約使用(輸入預言機)、將資訊從區塊鏈發送到鏈下應用程式(輸出預言機)或執行鏈下計算任務(計算預言機)來區分預言機。
+
+## 為什麼智慧型合約需要預言機? {#why-do-smart-contracts-need-oracles}
+
+許多開發者將智慧型合約視為在區塊鏈上特定地址運行的程式碼。 然而,對[智能合約](/smart-contracts/) 更普遍的看法是,它們是自動執行的軟體程式,一旦滿足特定條件,就能夠在各方之間執行協議,因此稱為「智能合約」。
+
+但考慮到以太坊的確定性,使用智慧型合約來執行人與人之間的協議並不簡單。 [確定性系統](https://en.wikipedia.org/wiki/Deterministic_algorithm) 是一種在給定初始狀態和特定輸入的情況下始終產生相同結果的系統,這意味著從輸入計算輸出的過程中不存在隨機性或變化。
+
+為了實現確定性執行,區塊鏈限制節點_僅_使用儲存在區塊鏈本身上的資料就簡單的二元 (true/false) 問題達成共識。 此類問題的範例包括:
+
+- 「帳戶所有者(由公鑰識別)是否使用配對的私鑰簽署了這筆交易?」
+- 「這個帳戶有足夠的資金來支付交易嗎?」
+- 「這筆交易在該智慧型合約的背景下有效嗎?」等等。
+
+如果區塊鏈從外部來源 (即現實世界) 接收資訊,將無法實現確定性,從而阻止節點就區塊鏈狀態變更的有效性達成一致。 以一個智慧型合約為例,它根據從傳統價格應用程式介面取得的當前以太幣-美元匯率執行交易。 這個數字可能會經常變化(更不用說應用程式介面可能會被棄用或被駭客攻擊),這意味著執行相同合約程式碼的節點會得到不同結果。
+
+對於像以太坊這樣在全球有數千個節點處理交易的公共區塊鏈來說,確定性至關重要。 由於沒有中央機構作為事實來源,節點需要在應用相同交易後達到相同狀態的機制。 如果節點 A 執行智慧型合約程式碼並得到 「3」,而節點 B 在運行同一交易後得到 「7」,則會導致共識崩潰,從而抹掉以太坊作為去中心化計算平台的價值。
+
+這種情況也凸顯了設計區塊鏈從外部來源取得資訊的問題。 然而,預言機透過從鏈下來源獲取資訊,並將其儲存在區塊鏈上給智能合約使用來解決這個問題。 由於儲存在鏈上的信息是不可更改且公開的,以太坊節點可以安全地使用預言機導入的鏈下數據來計算狀態變化,而不會破壞共識。
+
+為此,預言機通常由鏈上運行的智能合約和一些鏈下組件組成。 鏈上合約接收來自其他智能合約的數據請求,並將其傳遞給鏈下元件(稱為預言機節點)。 此預言機節點可以查詢數據來源,例如使用應用程式介面 (API),並發送交易以將請求的數據儲存在智慧型合約的儲存中。
+
+本質上,區塊鏈預言機彌合了區塊鏈與外部環境之間的資訊鴻溝,創建了「混合智慧型合約」。 混合智能合約是一種基於鏈上合約程式碼和鏈下基礎設施組合的功能。 去中心化預測市場是混合智慧型合約的一個很好的例子。 其他例子可能包括農作物保險智慧型合約,當一組預言機確定某些天氣現象已發生,該合約就會作出賠付。
+
+## 什麼是預言機問題? 預言機問題 {#the-oracle-problem}
+
+預言機解決了一個重要問題,但也帶來了一些複雜問題,例如:
+
+- 我們如何驗證注入的資訊是從正確的來源提取的或沒有被篡改?
+
+- 我們如何確保這些數據始終可用並定期更新?
+
+所謂的「預言機問題」展示了使用區塊鏈預言機向智慧型合約發送輸入所帶來的問題。 來自預言機的數據必須正確,智慧型合約才能正確執行。 此外,必須「信任」預言機運營商提供準確的資訊,會破壞智慧型合約的「去信任」方面。
+
+不同的預言機為預言機問題提供了不同的解決方案,我們會稍後探討。 預言機通常會根據它們應對以下挑戰的能力被評估:
+
+1. **正確性**:預言機不應導致智能合約基於無效的鏈外資料觸發狀態變更。 預言機必須保證資料的_真實性_和_完整性_。 真實性是指資料取自正確的來源,而完整性是指資料在傳送到鏈上之前保持完好 (即未被竄改)。
+
+2. **可用性**:預言機不應延遲或阻止智能合約執行操作並觸發狀態變更。 這意味著來自預言機的資料必須_請求時可用_,且沒有間斷。
+
+3. **激勵相容性**:預言機應該激勵鏈外資料提供者向智能合約提交正確的資訊。 激勵相容性包括了_可歸因性_和_問責性_。 可歸因性讓一段外部資訊與其提供者連結,而問責性則將數據提供者與他們提供的資訊綁定起來,讓他們能根據提供的資訊品質得到獎勵或懲罰。
+
+## 區塊鏈預言機服務如何運作? {#how-does-a-blockchain-oracle-service-work}
+
+### 使用者 {#users}
+
+使用者是指需要區塊鏈外部資訊來完成特定操作的實體(即智慧型合約)。 預言機服務的基本工作流程從用戶向預言機合約發起數據請求開始。 數據請求通常會回應以下問題的一部分或全部:
+
+1. 鏈下節點可以在哪些來源查詢需要的資訊?
+
+2. 報告者如何處理來自數據來源的資訊,並提取有用的數據點?
+
+3. 有多少預言機節點可以參與數據擷取?
+
+4. 如何處理預言機報告中的差異?
+
+5. 應使用甚麼方法來過濾提交的資訊並將報告聚合為單一數值?
+
+### 預言機合約 {#oracle-contract}
+
+預言機合約是預言機服務的鏈上組件。 它負責監聽來自其他合約的數據請求,將數據查詢傳遞給預言機節點,並將返回的數據廣播給用戶端合約。 這份合約也可以對返回的數據點進行計算,以產生一個聚合值並將其發送給請求合約。
+
+預言機合約公開了一些函數,讓用戶端合約在發出資料請求時使用。 當收到新的查詢時,智能合約會發出一個包含資料請求詳細資訊的[日誌事件](/developers/docs/smart-contracts/anatomy/#events-and-logs)。 這會通知已訂閱日誌的鏈外節點 (通常使用類似 JSON-RPC `eth_subscribe` 的指令),這些節點會繼續擷取日誌事件中定義的資料。
+
+以下是 Pedro Costa 撰寫的[預言機合約範例](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e)。 這是一個簡單的預言機服務,能依照其他智能合約的請求,查詢鏈下應用程式介面(API)並將請求的資訊儲存在區塊鏈上:
+
+```solidity
+pragma solidity >=0.4.21 <0.6.0;
+
+contract Oracle {
+ Request[] requests; //向合約發出的請求清單
+ uint currentId = 0; //遞增的請求 ID
+ uint minQuorum = 2; //在宣告最終結果前要收到的最少回應數
+ uint totalOracleCount = 3; //寫死的預言機數量
+
+ //定義一般 API 請求
+ struct Request {
+ uint id; //請求 ID
+ string urlToQuery; //API URL
+ string attributeToFetch; //要在回應中擷取的 json 屬性 (金鑰)
+ string agreedValue; //來自金鑰的值
+ mapping(uint => string) answers; //預言機提供的答案
+ mapping(address => uint) quorum; //將查詢答案的預言機 (1=預言機未投票,2=預言機已投票)
+ }
+
+ //觸發區塊鏈外預言機的事件
+ event NewRequest (
+ uint id,
+ string urlToQuery,
+ string attributeToFetch
+ );
+
+ //對最終結果達成共識時觸發
+ event UpdatedRequest (
+ uint id,
+ string urlToQuery,
+ string attributeToFetch,
+ string agreedValue
+ );
+
+ function createRequest (
+ string memory _urlToQuery,
+ string memory _attributeToFetch
+ )
+ public
+ {
+ uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
+ Request storage r = requests[length-1];
+
+ // 寫死的預言機地址
+ r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
+ r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
+ r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
+
+ // 啟動一個可被區塊鏈外預言機偵測到的事件
+ emit NewRequest (
+ currentId,
+ _urlToQuery,
+ _attributeToFetch
+ );
+
+ // 增加請求 ID
+ currentId++;
+ }
+
+ //由預言機呼叫以記錄其答案
+ function updateRequest (
+ uint _id,
+ string memory _valueRetrieved
+ ) public {
+
+ Request storage currRequest = requests[_id];
+
+ //檢查預言機是否在受信任的預言機清單中
+ //以及預言機是否尚未投票
+ if(currRequest.quorum[address(msg.sender)] == 1){
+
+ //標記此地址已投票
+ currRequest.quorum[msg.sender] = 2;
+
+ //迭代答案「陣列」,直到找到可用位置並儲存擷取的值
+ uint tmpI = 0;
+ bool found = false;
+ while(!found) {
+ //尋找第一個空的時隙
+ if(bytes(currRequest.answers[tmpI]).length == 0){
+ found = true;
+ currRequest.answers[tmpI] = _valueRetrieved;
+ }
+ tmpI++;
+ }
+
+ uint currentQuorum = 0;
+
+ //迭代預言機清單並檢查是否有足夠的預言機 (最低法定人數)
+ //投票給與目前答案相同的答案
+ for(uint i = 0; i < totalOracleCount; i++){
+ bytes memory a = bytes(currRequest.answers[i]);
+ bytes memory b = bytes(_valueRetrieved);
+
+ if(keccak256(a) == keccak256(b)){
+ currentQuorum++;
+ if(currentQuorum >= minQuorum){
+ currRequest.agreedValue = _valueRetrieved;
+ emit UpdatedRequest (
+ currRequest.id,
+ currRequest.urlToQuery,
+ currRequest.attributeToFetch,
+ currRequest.agreedValue
+ );
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+### 預言機節點 {#oracle-nodes}
+
+預言機節點是預言機服務的鏈下組件。 它從外部資料來源提取信息,例如由第三方伺服器託管的應用程式介面(API),並把資料放在鏈上供智能合約使用。 預言機節點監聽鏈上預言機合約的事件,並完成在日誌中描述的任務。
+
+預言機節點的常見工作是向 API 服務傳送 [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) 請求、剖析回應以擷取相關資料、將資料格式化為區塊鏈可讀的輸出,並將其包含在傳送到預言機合約的交易中,以傳送到鏈上。 預言機節點有時也會被要求用「真實性證明」去證明提交資料的有效性和完整性,我們稍後會再深入探討。
+
+計算型預言機也依賴於鏈下節點,來執行那些在鏈上由於 gas 費用和區塊大小限制而無法執行的計算任務。 例如,預言機節點可能會被要求生成可驗證隨機數字(例如:用在基於區塊鏈的遊戲)。
+
+## 預言機設計模式 {#oracle-design-patterns}
+
+預言機有多種類型,包括_即時讀取_、_發布-訂閱_和_請求-回應_,後兩種在以太坊智能合約中最受歡迎。 這裏我們簡單介紹發佈-訂閱型和請求-回應型。
+
+### 發布-訂閱預言機 {#publish-subscribe-oracles}
+
+這類預言機提供「數據餵送」,其他合約可以定期讀取以取得資訊。 在這種情況下,資料預計會頻繁變動,所以用戶端合約需要監聽在預言機中儲存的數據更新。 例如提供最新 ETH-USD 價格信息給使用者的預言機。
+
+### 請求-回應預言機 {#request-response-oracles}
+
+請求-回應的設置允許用戶端合約請求發佈-訂閱型預言機未提供的任意數據。 當數據集太大,無法儲存在智慧型合約時,或者使用者在任何時刻只需要數據的一小部分時,請求-回應型預言機是理想的選擇。
+
+雖然比發佈-訂閱型預言機複雜,但請求-回應型預言機基本上和我們在上一節所描述的一樣。 預言機會有一個鏈上組件來接收資料請求,並傳遞給鏈下節點進行處理。
+
+發起資料查詢的使用者需要負擔從鏈下來源檢索資訊的費用。 此外,使用者合約還必須提供資金,用來支付預言機合約通過請求中指定的回呼函數返回回應時所產生的 Gas 費用。
+
+## 中心化與去中心化預言機 {#types-of-oracles}
+
+### 中心化預言機 {#centralized-oracles}
+
+中心化預言機由單一實體控制,此實體負責把鏈下資訊聚合並根據請求更新預言機合約中的數據。 由於中心化預言機依賴單一真實性來源,所以效率比較高。 當專有數據集由擁有者直接發佈,且帶有被廣泛接受的簽名時,中心化預言機的表現可能會更好。 但是,它們也帶來了一些缺點:
+
+#### 低正確性保證 {#low-correctness-guarantees}
+
+使用中心化預言機時,不能確認提供的資訊準確與否。 即使是「聲譽良好」的提供者也可能會變得不可靠或被駭客攻擊。 如果預言機被破壞,智慧型合約將會基於錯誤資料來運行。
+
+#### 可用性不佳 {#poor-availability}
+
+中心化預言機無法保證能持續向其他智能合約提供鏈下資料。 如果提供者決定把服務關閉,或者一個駭客劫持了預言機的鏈下組件,你的智能合約會面臨拒絕服務(DoS)攻擊的風險。
+
+#### 激勵相容性不佳 {#poor-incentive-compatibility}
+
+中心化預言機通常缺乏良好設計,或根本不存在激勵機制來促使數據提供者提供準確或未經更改的資訊。 向預言機付錢以保證正確性並不等同於保證誠實。 隨著智慧型合約控制的價值數量增加,這一問題變得更加嚴重。
+
+### 去中心化預言機 {#decentralized-oracles}
+
+去中心化預言機旨在克服中心化預言機的限制,通過消除單點故障來提高可靠性。 去中心化預言機服務由點對點網路中的多個參與者組成,這些參與者在將鏈下數據發送到智慧型合約之前,會先對數據達成共識。
+
+理想狀態下,去中心化預言機應該是無許可,去信任而且不受中心化組織管理;而在現實中,預言機有著不同程度的去中心化。 有一些半去中心化的預言機網路允許任何人參與,但由一個「所有者」根據節點的過往表現來批准和移除節點。 完全去中心化的預言機網路也存在,他們通常以獨立區塊鏈運行,並設有明確的共識機制來協調節點並懲罰不當行為。
+
+使用去中化預言機有著以下的優點:
+
+### 高正確性保證 {#high-correctness-guarantees}
+
+去中心化預言機嘗試用不同的方法來達到數據的準確性。 這包括了使用證明來證實返回資訊的真實性和完整性,以及要求多個實體共同同意鏈下數據的有效性。
+
+#### 真實性證明 {#authenticity-proofs}
+
+真實性證明是一個密碼學機制,能夠讓人們獨立驗證從外部來源檢索到的資訊。 這些證明可以驗證資訊的來源,並在檢索後檢測可能的變動。
+
+真實性證明的範例包括:
+
+**傳輸層安全性 (TLS) 證明**:預言機節點通常使用基於傳輸層安全性 (TLS) 協議的安全 HTTP 連線,從外部來源擷取資料。 部分去中心化預言機使用真實性證明來驗證 TLS 會話(即確認節點和特定伺服器之間的資訊交換)並確證會話內容未被修改。
+
+**可信執行環境 (TEE) 證明**:[可信執行環境](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) 是一個沙箱化運算環境,與其主機系統的作業程序隔離。 TEEs 保證了在計算環境中儲存和使用的任何應用程式程式碼或數據都會保持完整性、機密性和不可竄改性。 使用者還可以生成一個證明來證明一個應用程式實例是在可信任執行環境中運行。
+
+某些種類的去中心化預言機要求預言機節點的營運者提供 TEE 證明。 這能向使用者確保節點營運者是在可信任的執行環境中運行預言機用戶端的實例。 TEEs 防止外部進程修改或讀取應用程式的程式碼和數據,因此這些證明可以證實預言機節點有保持資訊的完整性和機密性。
+
+#### 基於共識的資訊驗證 {#consensus-based-validation-of-information}
+
+向智慧型合約提供資料時,中心化預言機依賴於單一真實性來源,因此有可能發佈不準確的資訊。 去中心化預言機借由依靠多個預言機節點來查詢鏈下資訊,來解決這個問題。 通過比對不同來源的資料,去中心化預言機降低了向鏈上合約提供無效資訊的風險。
+
+但是去中化預言機必需處理不同鏈下來源的資訊差異。 為了盡可能減少資訊差異並確保提供給預言機合約的數據反映了預言機節點的集體意見,去中心化預言機使用了以下的機制:
+
+##### 對資料的準確性投票或質押
+
+有部分的去中心化預言機網路要求參與者使用網路的原生代幣對資料查詢答案的準確性進行投票或質押 (例如「誰贏了 2020 年的美國大選?」)。 一個匯總協議會匯總這些投票和質押,並把受到大多數支持的答案作為有效答案。
+
+若節點提供的答案與大多數答案不一致將會受到懲罰,即把他們的代幣分發給其他提供了更正確數值的節點。 要求節點在提供數據前提供擔保可以激勵節點做出誠實的回應,因為這些節點都被認為是想得到最大回報的理性經濟參與者。
+
+質押/投票還可以保護去中心化預言機免受[女巫攻擊](/glossary/#sybil-attack),惡意行為者會在這種攻擊中建立多個身分來操縱共識系統。 但是,質押無法防範「佔便宜」的行為(預言機節點直接複製其他節點的資訊)和「懶惰驗證」(預言機節點遵循大多數而不親自驗證資訊)。
+
+##### 謝林點機制
+
+[謝林點](https://en.wikipedia.org/wiki/Focal_point_\(game_theory\)) 是一個賽局理論概念,假設在沒有任何通訊的情況下,多個實體總是會預設採用一個常見的問題解決方案。 謝林點機制常常被用在去中心化預言機網路,讓節點能就數據請求的答案達成共識。
+
+這個概念的早期想法是 [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/),這是一個提議的資料饋送機制,參與者提交「純量」問題 (答案可以用量值描述的問題,例如「ETH 的價格是多少?」) 的回應以及一筆押金。 提供介於第 25 和第 75 [百分位數](https://en.wikipedia.org/wiki/Percentile) 之間數值的使用者會獲得獎勵,而數值與中位數相差甚遠的使用者則會受到懲罰。
+
+雖然 SchellingCoin 現已不復存在,但許多去中心化預言機 (特別是 [Maker 協定預言機](https://docs.makerdao.com/smart-contract-modules/oracle-module)) 仍使用謝林點機制來提高預言機資料的準確性。 每個 Maker 預言機都由一個鏈下的 P2P 網路的節點(「中繼者」和「餵送者」)組成,這些節點提交抵押資產的市場價格,然後由鏈上的「Medianizer」合約計算所有提供值的中位數。 當指定的延遲期結束,這個中位數值就成為相關資產的新參考價格。
+
+其他使用謝林點機制的預言機範例包括 [Chainlink 鏈外報告](https://docs.chain.link/architecture-overview/off-chain-reporting)和 [Witnet](https://witnet.io/)。 在這兩個系統中,P2P 網路中的預言機節點回應會聚合成一個單一的聚合值,例如平均值或中間值。 節點將根據其回應與聚合值的一致程度或偏差程度來獲得獎勵或受到懲罰。
+
+謝林點機制會具有吸引力,是因為他們降低了鏈上足跡(只有一筆交易需要被發送)的同時又保證了去中心化。 後者之所以可行,是因為節點需要在提交的回應清單上簽署,才可以將其輸入到生成平均值或中位數的演算法中。
+
+### 可用性 {#availability}
+
+去中心化預言機服務為智能合約確保了鏈下數據的高可用性。 這是通過把鏈下資訊來源以及負責將信息傳輸至鏈上的節點同時去中心化來實現。
+
+這確保了容錯能力,因為預言機合約可以依賴多個節點(這些節點也依賴於多個數據來源)來執行其他合約的查詢。 在來源_和_節點營運者層級的去中心化至關重要 — 一個預言機節點網路若提供從相同來源擷取的資訊,將會遇到與中心化預言機相同的問題。
+
+基於質押的預言機也可能對未能快速回應資料請求的節點運營者進行懲罰。 這大大激勵了預言機節點投資於容錯基礎設施,並及時提供數據。
+
+### 良好的激勵相容性 {#good-incentive-compatibility}
+
+去中心化預言機採用了不同的激勵設計,來避免預言機節點出現[拜占庭](https://en.wikipedia.org/wiki/Byzantine_fault)行為。 具體來說,它們實現了_可歸因性_和_問責性_:
+
+1. 去中心化預言機節點通常需要為他們對數據請求的回應簽署。 這個資訊有助於評估預言機節點的過往表現,讓使用者可以在提出數據請求時過濾掉不可靠的預言機節點。 Witnet 的[演算法信譽系統](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system)就是一個例子。
+
+2. 正如同前面所說,去中心化預言機可能要求節點對他們提交數據的真實性進行質押。 如果該聲明經過驗證無誤,這筆質押可以連同誠實服務的獎勵一併返還。 但如果資訊不準確,節點也可以被懲罰,這為問責提供了一定的保障。
+
+## 預言機在智能合約中的應用 {#applications-of-oracles-in-smart-contracts}
+
+以下是以太坊中預言機的常見用例:
+
+### 擷取財務資料 {#retrieving-financial-data}
+
+[去中心化金融](/defi/) (DeFi) 應用程式允許點對點借貸、借款和資產交易。 通常這會需要不同的金融資訊,包括匯率數據(用來計算加密貨幣的法幣價值或比較代幣價格)和資本市場數據(用來計算代幣化資產的價值,例如黃金或美元)。
+
+例如,一個去中心化借貸協議需要查詢作為抵押品存入的資產(例如 ETH)的當前市場價格。 這令合約能確定扺押品的價值,以及確定它能從系統中借出多少。
+
+DeFi 中常見的「價格預言機」(通常如此稱呼) 包括 Chainlink 價格資訊、Compound Protocol 的 [Open Price Feed](https://compound.finance/docs/prices)、Uniswap 的[時間加權平均價格 (TWAP)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) 和 [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module)。
+
+開發者在將這些價格預言機整合到他們的項目中之前,應該了解相關的注意事項。 這篇[文章](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/)詳細分析了計劃使用任何上述價格預言機時需要考慮的事項。
+
+以下是一個在你的智慧型合約中使用 Chainlink price feed 查詢最新 ETH 價格的範例:
+
+```solidity
+pragma solidity ^0.6.7;
+
+import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
+
+contract PriceConsumerV3 {
+
+ AggregatorV3Interface internal priceFeed;
+
+ /**
+ * Network: Kovan
+ * Aggregator: ETH/USD
+ * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
+ */
+ constructor() public {
+ priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
+ }
+
+ /**
+ * Returns the latest price
+ */
+ function getLatestPrice() public view returns (int) {
+ (
+ uint80 roundID,
+ int price,
+ uint startedAt,
+ uint timeStamp,
+ uint80 answeredInRound
+ ) = priceFeed.latestRoundData();
+ return price;
+ }
+}
+```
+
+### 產生可驗證的隨機性 {#generating-verifiable-randomness}
+
+某些區塊鏈應用程式,例如基於區塊鏈的遊戲或彩劵方案,需要高度不可預測性和隨機性才能有效運作。 但是,區塊鏈的確定性執行方式消除了任何隨機性。
+
+最初的方法是使用偽隨機密碼編譯函式,例如 `blockhash`,但這些可能被[礦工操縱](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) 解決工作量證明演算法。 此外,以太坊[轉換為權益證明](/roadmap/merge/)意味著開發者不能再依賴 `blockhash` 來取得鏈上隨機性。 信標鏈的 [RANDAO 機制](https://eth2book.info/altair/part2/building_blocks/randomness)則提供了另一種隨機性來源。
+
+從鏈下生成隨機值並發往鏈上是可行的,但這會需要對使用者有很高的信任要求。 他們必須相信這個值確實是通過無法預測的機制來生成,而且沒有在傳輸的過程中被修改。
+
+專為鏈下計算而設計的預言機解決了這個問題,它們通過在鏈下安全地生成隨機結果,並將結果與證明過程的不可預測性密碼學證明一起廣播到鏈上。 其中一個範例是 [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (可驗證隨機函式),這是一種可證明公平且防竄改的隨機數產生器 (RNG),可用於為依賴不可預測結果的應用程式建置可靠的智能合約。
+
+### 取得事件結果 {#getting-outcomes-for-events}
+
+有了預言機後,創建能對現實世界事件做出反應的智慧型合約變得簡單。 預言機服務通過允許合約通過鏈下組件連結到外部 APIs 並從這些數據來源中獲取資訊,來讓這變得可能。 例如,前面提到的預測 dApp 可能會請求預言機從可信的鏈下來源(例如美聯社)返回選舉結果。
+
+使用預言機來檢索基於現實世界結果的數據,使其他創新的應用場景變為可能;例如一個去中心化的保險產品需要準確的天氣、災害等資訊才能有效運作。
+
+### 自動化智能合約 {#automating-smart-contracts}
+
+智慧型合約不會自動運行;而是必須由一個外部帳戶 (EOA)或其他合約帳戶觸發相應的函數來執行合約程式碼。 在大多數情況下,合約的大部分函數都是公開且能被 EOA 和其他合約調用。
+
+但合約中也有其他人無法存取的_私有函式_;但這些函式對 dApp 的整體功能至關重要。 例如,定期為使用者鑄造新 NFT 的 `mintERC721Token()` 函式、在預測市場中發放獎金的函式,或在 DEX 中解鎖已質押代幣的函式。
+
+開發者會需要定期觸發這些函數來讓應用程式順暢運行。 但是,這可能會讓開發者浪費更多時間在這些日常任務,這便是為甚麼自動化執行智慧型合約如此具吸引力。
+
+部分去中心化預言機網路提供自動化服務,允許鏈下預言機節點按照使用者定義的參數來觸發智慧型合約的函數。 通常來說,這會需要把目標合約「登記」在預言機服務上,提供資金以支付預言機營運者的費用,以及定義好合約的觸發條件或時間。
+
+Chainlink 的 [Keeper Network](https://chain.link/keepers) 為智能合約提供選項,能以信任最小化和去中心化的方式,外包定期維護工作。 請閱讀官方 [Keeper 文件](https://docs.chain.link/docs/chainlink-keepers/introduction/),了解如何使您的合約與 Keeper 相容以及如何使用 Upkeep 服務。
+
+## 如何使用區塊鏈預言機 {#use-blockchain-oracles}
+
+你可以將多個預言機應用程式整合到你的以太坊去中心化應用程式中:
+
+**[Chainlink](https://chain.link/)** - _Chainlink 去中心化預言機網路提供防竄改的輸入、輸出和運算,以支援任何區塊鏈上的進階智能合約。_
+
+**[RedStone Oracles](https://redstone.finance/)** - _RedStone 是一個去中心化模組化預言機,提供對燃料費最佳化的資料饋送。 它專門為新興資產提供價格資訊,例如流動性質押代幣 (LST)、流動性再質押代幣 (LRT) 和比特幣質押衍生品。_
+
+**[Chronicle](https://chroniclelabs.org/)** - _Chronicle 透過開發真正可擴展、具成本效益、去中心化且可驗證的預言機,克服了目前將資料傳輸到鏈上的限制。_
+
+**[Witnet](https://witnet.io/)** - _Witnet 是一個無需許可、去中心化且抗審查的預言機,幫助智能合約以強大的加密經濟保證對現實世界事件做出反應。_
+
+**[UMA Oracle](https://uma.xyz)** - _UMA 的樂觀預言機允許智能合約為不同的應用程式快速接收任何類型的資料,包括保險、金融衍生品和預測市場。_
+
+**[Tellor](https://tellor.io/)** - _Tellor 是一個透明且無需許可的預言機協定,讓您的智能合約在需要時能夠輕鬆取得任何資料。_
+
+**[Band Protocol](https://bandprotocol.com/)** - _Band Protocol 是一個跨鏈資料預言機平台,可將現實世界的資料和 API 匯總並連接到智能合約。_
+
+**[Pyth Network](https://pyth.network/)** - _Pyth Network 是一個第一方金融預言機網路,旨在在一個防竄改、去中心化且可自我維持的環境中,持續將真實世界的資料發布到鏈上。_
+
+**[API3 DAO](https://www.api3.org/)** - _API3 DAO 正在提供第一方預言機解決方案,在為智能合約提供的去中心化解決方案中,提供更高的來源透明度、安全性和可擴展性_
+
+**[Supra](https://supra.com/)** - 一個垂直整合的跨鏈解決方案工具包,將所有區塊鏈 (公共 L1 和 L2 或私有企業) 相互連接,提供可用於鏈上和鏈外用例的去中心化預言機價格饋送。
+
+**[Gas Network](https://gas.network/)** - 一個分散式預言機平台,提供跨區塊鏈的即時燃料費價格資料。 透過將頂尖燃料費價格資料提供者的資料帶到鏈上,Gas Network 正在幫助推動互通性。 Gas Network 支援超過 35 條鏈的資料,包括以太坊主網和許多頂尖的 L2。
+
+## 延伸閱讀 {#further-reading}
+
+**文章**
+
+- [什麼是區塊鏈預言機?](https://chain.link/education/blockchain-oracles) — _Chainlink_
+- [什麼是區塊鏈預言機?](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Patrick Collins_
+- [去中心化預言機:全面概述](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Julien Thevenard_
+- [在以太坊上實作區塊鏈預言機](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_
+- [為什麼智能合約不能進行 API 呼叫?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_
+- [所以你想使用價格預言機](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
+
+**影片**
+
+- [預言機與區塊鏈效用的擴展](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_
+
+**教學**
+
+- [如何在 Solidity 中擷取以太坊的目前價格](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_
+- [使用預言機資料](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_
+
+**專案範例**
+
+- [適用於 Solidity 中以太坊的完整 Chainlink 入門專案](https://github.com/hackbg/chainlink-fullstack) — _HackBG_
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/dart/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/dart/index.md
index c53baaf3024..71be8fb5d18 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/dart/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/dart/index.md
@@ -5,24 +5,29 @@ lang: zh-tw
incomplete: true
---
-## 來開始學習智慧型合約及Solidity語言 {#getting-started-with-smart-contracts-and-solidity}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-solidity}
-## 指導手冊 {#tutorials}
+## 教學 {#tutorials}
-- [Flutter 與區塊鏈 – Hello World 去中心化應用程式](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/)帶您完成入門的所有步驟:
- 1. 使用 [Solidity](https://soliditylang.org/) 編寫智慧型合約
- 2. 使用 Dart 編寫使用者介面
-- 如果你已有基礎知識,[使用 Flutter 建立行動去中心化應用程式](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a)的篇幅要短很多, 可能是更好選擇
-- 如果你偏好透過觀看影片來學習,可以觀看[建立你的第一個區塊鏈 Flutter 應用程式](https://www.youtube.com/watch?v=3Eeh3pJ6PeA),片長約一小時
-- 如果你時間不足,可能更喜歡[在以太坊上使用 Flutter 和 Dart 建立區塊鏈去中心化應用程式](https://www.youtube.com/watch?v=jaMFEOCq_1s),只需大約二十分鐘
-- [透過 WalletConnect 的 Web3Modal 將 MetaMask 整合到 Flutter 應用程式](https://www.youtube.com/watch?v=v_M2buHCpc4) - 這段簡短影片會一步一步帶你使用 WalletConnect 的 [Web3Modal](https://pub.dev/packages/web3modal_flutter) 程式庫,將 MetaMask 整合到 Flutter 應用程式中
-- [Solidity 和 Flutter 行動區塊鏈開發者訓練營課程](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - 全端行動區塊鏈開發者課程播放列表
+- [Flutter 與區塊鏈 – Hello World 去中心化應用程式](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) 會帶你完成所有入門步驟:
+ 1. 以 [Solidity](https://soliditylang.org/) 編寫智能合約
+ 2. 使用 Dart 編寫使用者介面
+- [用 Flutter 建立行動去中心化應用程式](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) 篇幅較短,
+ 如果你已了解基礎知識,這篇可能更適合你。
+- 如果你偏好透過觀看影片來學習,可以觀看 [建立你的第一個區塊鏈 Flutter 應用程式](https://www.youtube.com/watch?v=3Eeh3pJ6PeA),片長約一小時。
+- 如果你沒什麼耐心,可能比較喜歡 [在以太坊上使用 Flutter 與 Dart 建立區塊鏈去中心化應用程式](https://www.youtube.com/watch?v=jaMFEOCq_1s),影片長度只有約 20 分鐘。
+- [透過 WalletConnect 的 Web3Modal 將 MetaMask 整合到 Flutter 應用程式](https://www.youtube.com/watch?v=v_M2buHCpc4) - 這段簡短影片會一步一步帶你使用 WalletConnect 的 [Web3Modal](https://pub.dev/packages/web3modal_flutter) 程式庫,將 MetaMask 整合到你的 Flutter 應用程式中。
+- [使用 Solidity 與 Flutter 的行動區塊鏈開發者訓練營課程](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - 全端行動區塊鏈開發者課程播放清單
-## 與以太坊客戶合作工作 {#working-with-ethereum-clients}
+## 使用以太坊用戶端 {#working-with-ethereum-clients}
-你可以使用以太坊,來建立能夠利用加密貨幣與區塊鏈技術長處的去中心化應用程式(或稱「dapp」)。 目前至少有兩個維護的程式庫 可供 Dart 使用以太坊的 [JSON-RPC 應用程式介面](/developers/docs/apis/json-rpc/)。
+你可以使用以太坊,來建立能夠利用加密貨幣與區塊鏈技術長處的去中心化應用程式(或稱「dapp」)。
+目前 Dart 至少有兩個持續維護的程式庫,可用來存取以太坊的
+[JSON-RPC API](/developers/docs/apis/json-rpc/)。
-1. [simonbutler.eu 的 Web3dart](https://pub.dev/packages/web3dart)
-1. [來自 darticulate.com 的以太坊 5.0.0](https://pub.dev/packages/ethereum)
+1. [pwa.ir](https://pub.dev/packages/web3dart 的 Web3dart)
+2. [來自 darticulate.com](https://pub.dev/packages/ethereum 的以太坊 5.0.0)
-還有其他程式庫讓你能夠操作特定的以太坊地址, 或擷取各種加密貨幣的價格。 [你在這裡可以看到完整清單](https://pub.dev/dart/packages?q=ethereum)。
+還有其他程式庫讓你能夠操作特定的以太坊地址,
+或擷取各種加密貨幣的價格。
+[你可以在此處查看完整清單](https://pub.dev/dart/packages?q=ethereum)。
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/delphi/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/delphi/index.md
index cb6f61cbfcb..b6e33cee00a 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/delphi/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/delphi/index.md
@@ -11,46 +11,46 @@ incomplete: true
-使用 Ethereum 建立去中心化應用程式 (或稱「dapp」),發揮加密貨幣學和區塊鏈技術的優勢。 這些去中心化應用程式一旦部署到 Ethereum 後,就會持續地按照其設計的方式執行,進而成為非常可信的工具, 這些應用程序可以控制數字資產,以便創造新的金融應用; 這些應用程式是去中心化的,表示任何單一的實體或個人都不能加以控制,也幾乎不可能被審查。
+使用以太坊建立去中心化應用程式(或稱「dapp」),發揮加密貨幣和區塊鏈技術的優勢。 這些去中心化應用程式是可信的,這意味著一旦部署到以太坊後,它們就會始終按照設定執行。 這些應用程式可以控制數位資產,以便建立新型金融應用程式。 這些應用程式是去中心化的,這意味著任何單一實體或個人都無法控制它們,並且應用程式幾乎不可能被審查。
在以太坊上構建去中心化應用程式,並使用 Delphi 程式設計語言與智慧型合約互動!
-## 來開始學習智慧型合約及Solidity語言 {#getting-started-with-smart-contracts-and-the-solidity-language}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-the-solidity-language}
**邁出第一步,整合 Delphi 與以太坊**
-需要基礎的入門指南嗎? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
+需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
-- [區塊鏈詳解](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [詳解區塊鏈](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
- [了解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [編寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [學習如何編寫和部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [撰寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [學習如何編譯及部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-## 初學者參考和連結 {#beginner-references-and-links}
+## 初學者參考資料與連結 {#beginner-references-and-links}
**Delphereum 程式庫簡介**
-- [甚麼是 Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md)
-- [將 Delphi 連結到本地(記憶體內部)區塊鏈](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
-- [將 Delphi 連結到以太坊主網](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
-- [將 Delphi 連結到智慧型合約](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
+- [什麼是 Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md)
+- [將 Delphi 連接到本機 (記憶體內) 區塊鏈](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
+- [將 Delphi 連接到以太坊主網](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
+- [將 Delphi 連接到智能合約](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
-**想要跳過設定,並直接跳至範例?**
+**想要立即略過設定,直接跳到範例嗎?**
-- [三分鐘的智慧型合約和 Delphi - 第 1 部分](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
-- [三分鐘的智慧型合約和 Delphi - 第 2 部分](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
+- [3 分鐘智能合約與 Delphi - 第 1 部分](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
+- [3 分鐘智能合約與 Delphi - 第 2 部分](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
## 中階文章 {#intermediate-articles}
-- [使用 Delphi 產生以太坊簽名的訊息簽章](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
-- [使用 Delphi 傳送以太幣](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
-- [使用 Delphi 傳送 ERC-20 代幣](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
+- [在 Delphi 中產生以太坊簽署的訊息簽章](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
+- [使用 Delphi 轉移以太幣](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
+- [使用 Delphi 轉移 ERC-20 代幣](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
## 進階使用模式 {#advanced-use-patterns}
-- [Delphi 和以太坊名稱服務 (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
-- [QuikNode、以太坊 和 Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
-- [Delphi 和以太坊黑暗森林](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
-- [在 Delphi 中將一種代幣兌換成另一種代幣](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
+- [Delphi 與 Ethereum 名稱服務 (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
+- [QuikNode、以太坊與 Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
+- [Delphi 與以太坊的黑暗森林](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
+- [在 Delphi 中將一種代幣交換成另一種](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
-想取得更多資源? 請瀏覽[ethereum.org/developers](/developers/)
+想取得更多資源? 請查看 [ethereum.org/developers](/developers/)。
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/dot-net/index.md
index 14f8a735568..3e11e44d275 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/dot-net/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/dot-net/index.md
@@ -5,82 +5,83 @@ lang: zh-tw
incomplete: true
---
-學習如何使用 .NET 型專案和工具進行以太坊開發
+學習如何使用基於 .NET 的專案和工具進行以太坊開發
-使用 Ethereum 建立去中心化應用程式 (或稱「dapp」),發揮加密貨幣學和區塊鏈技術的優勢。 這些去中心化應用程式一旦部署到 Ethereum 後,就會持續地按照其設計的方式執行,進而成為非常可信的工具, 這些應用程序可以控制數字資產,以便創造新的金融應用; 這些應用程式是去中心化的,表示任何單一的實體或個人都不能加以控制,也幾乎不可能被審查。
+使用以太坊建立去中心化應用程式(或稱「dapp」),發揮加密貨幣和區塊鏈技術的優勢。 這些去中心化應用程式是可信的,這意味著一旦部署到以太坊後,它們就會始終按照設定執行。 這些應用程式可以控制數位資產,以便建立新型金融應用程式。 這些應用程式是去中心化的,這意味著任何單一實體或個人都無法控制它們,並且應用程式幾乎不可能被審查。
-使用 Microsoft 技術堆疊中的工具和語言在以太坊上構建去中心化應用程式並與智慧型合約進行 互動 - 跨 .NET Framework/.NET Core/.NET Standard 在 VSCode 和 Visual Studio 等工具上支援 C#、# Visual Basic .NET 和 F#。 在幾分鐘內使用 Microsoft Azure 區塊鏈在 Azure上部署以太坊區塊鏈。 將對 .NET 的喜愛轉移至以太坊!
+使用 Microsoft 技術堆疊中的工具和語言在以太坊上構建去中心化應用程式並與智慧型合約進行
+互動 - 跨 .NET Framework/.NET Core/.NET Standard 在 VSCode 和 Visual Studio 等工具上支援 C#、# Visual Basic .NET 和 F#。 在幾分鐘內使用 Microsoft Azure 區塊鏈在 Azure上部署以太坊區塊鏈。 將對 .NET 的喜愛轉移至以太坊!
-## 來開始學習智慧型合約及Solidity語言 {#getting-started-with-smart-contracts-and-the-solidity-language}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-the-solidity-language}
**邁出第一步,整合 .NET 與以太坊**
-需要基礎的入門指南嗎? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
+需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
-- [區塊鏈詳解](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [詳解區塊鏈](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
- [了解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [編寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [學習如何編寫和部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [撰寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [學習如何編譯及部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-## 初學者參考和連結 {#beginner-references-and-links}
+## 初學者參考資料與連結 {#beginner-references-and-links}
**Nethereum 程式庫和 VS Code Solidity 簡介**
-- [Nethereum 入門](https://docs.nethereum.com/en/latest/getting-started/)
+- [Nethereum,入門](https://docs.nethereum.com/en/latest/getting-started/)
- [安裝 VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
-- [.NET 開發者建立和調用以太坊智慧型合約的工作流程](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
-- [智慧型合約與 Nethereum 的整合](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
-- [使用 Nethereum 連接 .NET 和以太坊區塊鏈智慧型合約](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933),也可參考此[中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
-- [Nethereum - 區塊鏈的開放源始碼 .NET 整合程式庫](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
+- [.NET 開發者建立和呼叫以太坊智能合約的工作流程](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
+- [與 Nethereum 整合的智能合約](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
+- [使用 Nethereum 連接 .NET 與以太坊區塊鏈智能合約](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933),另有[中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
+- [Nethereum-一個用於區塊鏈的開源 .NET 整合庫](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
- [使用 Nethereum 將以太坊交易寫入 SQL 資料庫](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
-- [瞭解如何使用 C# 和 VisualStudio 輕鬆部署以太坊智慧型合約](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
+- [了解如何使用 C# 和 VisualStudio 輕鬆部署以太坊智能合約](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
-**想要跳過設定,直接了解範例?**
+**想要立即略過設定,直接跳到範例嗎?**
-- [訓練場](http://playground.nethereum.com/) - 與以太坊互動,並學習如何透過瀏覽器使用 Nethereum。
+- [訓練場](http://playground.nethereum.com/) - 透過瀏覽器與以太坊互動,並學習如何使用 Nethereum。
- 查詢帳戶餘額 [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
- - 查詢 ERC20 智慧型合約餘額 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004)
- - 將以太幣傳送至帳戶 [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003)
+ - 查詢 ERC20 智能合約餘額 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004)
+ - 將以太幣轉帳至帳戶 [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003)
- ... 和更多相關內容!
-## 中級文章 {#intermediate-articles}
+## 中階文章 {#intermediate-articles}
-- [Nethereum 活頁簿/範例清單](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
-- [部署你自己的開發測試鏈](https://github.com/Nethereum/Testchains)
-- [Solidity 的 VSCode 程式碼產生外掛程式](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
-- [Unity 和以太坊:為何以及如何](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
-- [為以太坊去中心化應用程式建立 ASP.NET 核心 Web 應用程式介面](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
-- [使用 Nethereum Web3 實作供應鏈追踪系統](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
-- [Nethereum 區塊處理](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/),包含 [C# 訓練場範例](http://playground.nethereum.com/csharp/id/1025)
+- [Nethereum 工作手冊/範例清單](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
+- [部署您自己的開發測試鏈](https://github.com/Nethereum/Testchains)
+- [適用於 Solidity 的 VSCode Codegen 外掛程式](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
+- [Unity 與以太坊:原因與方法](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
+- [為以太坊去中心化應用程式建立 ASP.NET Core Web API](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
+- [使用 Nethereum Web3 實作供應鏈追蹤系統](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
+- [Nethereum 區塊處理](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/),附 [C# 訓練場範例](http://playground.nethereum.com/csharp/id/1025)
- [Nethereum Websocket 串流](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
- [Kaleido 和 Nethereum](https://kaleido.io/kaleido-and-nethereum/)
- [Quorum 和 Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
## 進階使用模式 {#advanced-use-patterns}
-- [Azure 金鑰保存庫和 Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
+- [Azure Key Vault 和 Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid)
- [Ujo Nethereum 後端參考架構](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
-## .NET 專案、工具及其他有趣內容 {#dot-net-projects-tools-and-other-fun-stuff}
+## .NET 專案、工具和其他有趣的東西 {#dot-net-projects-tools-and-other-fun-stuff}
-- [Nethereum 訓練場](http://playground.nethereum.com/) - _在瀏覽器中編譯、建立和執行 Nethereum 程式碼片段_
-- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Blazor 中的 Nethereum 程式碼產生使用者介面_
-- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _.NET Wasm 單頁應用程式輕量區塊鏈瀏覽器和簡易錢包_
-- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _本質上由中繼資料驅動的業務規則引擎(同時適用於. NET 平台和以太坊平台)_
-- [Nethermind](https://github.com/NethermindEth/nethermind) - _.NET Core 以太坊用戶端,適用於 Linux、Windows 和 MacOS_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _使用以太坊相關程式碼庫的公用程式函式_
-- [TestChains](https://github.com/Nethereum/TestChains) - _可實現快速回應的預先設定的 .NET 開發鏈 (PoA)_
+- [Nethereum 訓練場](http://playground.nethereum.com/) - _在瀏覽器中編譯、建立並執行 Nethereum 程式碼片段_
+- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _使用 Blazor UI 的 Nethereum codegen_
+- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _一個 .NET Wasm 單頁應用程式輕量區塊鏈瀏覽器和簡易錢包_
+- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _一個業務規則引擎 (同時適用於 .NET 平台和以太坊平台),本質上是由元資料驅動_
+- [Nethermind](https://github.com/NethermindEth/nethermind) - _一個適用於 Linux、Windows、MacOS 的 .NET Core 以太坊用戶端_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _用於處理以太坊相關程式碼庫的公用程式函式_
+- [TestChains](https://github.com/Nethereum/TestChains) - _可實現快速回應的預先設定 .NET 開發鏈 (PoA)_
-想取得更多資源? 請瀏覽[ethereum.org/developers](/developers/)
+想取得更多資源? 請查看 [ethereum.org/developers](/developers/)。
## .NET 社群貢獻者 {#dot-net-community-contributors}
-在 Nethereum,我們主要活躍於 [Gitter](https://gitter.im/Nethereum/Nethereum) 上,任何人都可以前來提問/回答問題,獲得協助或者放鬆一下。 隨意在 [Nethereum GitHub 儲存庫](https://github.com/Nethereum)上提交拉取請求或開立一個議題,或僅瀏覽我們提供的許多小專案/範例專案。 你也可以在 [Discord](https://discord.gg/jQPrR58FxX) 上找到我們!
+在 Nethereum,我們主要在 [Gitter](https://gitter.im/Nethereum/Nethereum) 上活動,歡迎大家來提問/回答問題、尋求協助或只是閒聊。 歡迎在 [Nethereum GitHub 儲存庫](https://github.com/Nethereum) 上提交拉取請求 (PR) 或開啟議題,也可以瀏覽我們許多的附屬/範例專案。 您也可以在 [Discord](https://discord.gg/jQPrR58FxX) 上找到我們!
-如果你是 Nethermind 新手並需要入門幫助,請加入我們的 [Discord](http://discord.gg/PaCMRFdvWT)。 我們的開發者隨時準備回答你的問題。 隨時在 [Nethermind GitHub 存儲庫](https://github.com/NethermindEth/nethermind)上建立拉取請求或提出任何議題。
+如果您是 Nethermind 新手且需要入門協助,請加入我們的 [Discord](http://discord.gg/PaCMRFdvWT)。 我們的開發者隨時準備回答你的問題。 歡迎隨時在 [Nethermind GitHub 儲存庫](https://github.com/NethermindEth/nethermind) 上提交拉取請求 (PR) 或提出任何議題。
-## 其他彙總列表 {#other-aggregated-lists}
+## 其他彙總清單 {#other-aggregated-lists}
-[官方 Nethereum 網站](https://nethereum.com/)
-[官方 Nethermind 網站](https://nethermind.io/)
+[Nethereum 官方網站](https://nethereum.com/)
+[Nethermind 官方網站](https://nethermind.io/)
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/golang/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/golang/index.md
index 3d1e93821db..ca37885eae4 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/golang/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/golang/index.md
@@ -1,84 +1,84 @@
---
-title: Go 開發者適用的 Ethereum 資源
+title: Go 開發者適用的以太坊資源
description: 學習如何使用 Go 型專案和工具進行以太坊開發
lang: zh-tw
incomplete: true
---
-學習如何使用 Go 型專案和工具進行以太坊開發
+學習如何使用基於 Go 的專案和工具進行以太坊開發
-使用以太坊建立去中心化應用程式(或稱「dapp」)。 這些去中心化應用程式一旦部署到 Ethereum 後,就會持續地按照其設計的方式執行,進而成為非常可信的工具, 這些應用程式是去中心化的,意味著它們在點對點網路上運行,並且不存在單點故障。 這些應用程式不會被單一實體或個人控制,並且幾乎不可能對其進行審查。 它們可以控制數位資產以建立新型應用程式。
+使用以太坊建立去中心化應用程式(或稱「dapp」)。 這些去中心化應用程式是可信的,這意味著一旦部署到以太坊後,它們就會始終按照設定執行。 這些應用程式是去中心化的,意味著它們在點對點網路上運行,並且不存在單點故障。 這些應用程式不會被單一實體或個人控制,並且幾乎不可能對其進行審查。 它們可以控制數位資產以建立新型應用程式。
-## 來開始學習智慧型合約及Solidity語言 {#getting-started-with-smart-contracts-and-solidity}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-solidity}
**邁出第一步,整合 Go 與以太坊**
-需要基礎的入門指南嗎? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
+需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
-- [區塊鏈詳解](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [詳解區塊鏈](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
- [了解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [編寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [學習如何編寫和部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [撰寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [學習如何編譯及部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
- [合約教學](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
-## 初學者文章和書籍 {#beginner-articles-and-books}
+## 初學者文章與書籍 {#beginner-articles-and-books}
- [Geth 入門](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
-- [使用 Golang 連結至以太坊](https://www.youtube.com/watch?v=-7uChuO_VzM)
-- [使用 Golang 部署以太坊智慧型合約](https://www.youtube.com/watch?v=pytGqQmDslE)
-- [使用 Go 測試和部署以太坊智慧型合約的逐步指南](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
-- [電子書:使用 Go 開發以太坊](https://goethereumbook.org/) - _使用 Go 開發以太坊應用程式_
+- [使用 Golang 連接到以太坊](https://www.youtube.com/watch?v=-7uChuO_VzM)
+- [使用 Golang 部署以太坊智能合約](https://www.youtube.com/watch?v=pytGqQmDslE)
+- [在 Go 中測試和部署以太坊智能合約的逐步指南](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
+- [電子書:用 Go 開發以太坊](https://goethereumbook.org/) - _用 Go 開發以太坊應用程式_
-## 中階文章和文件 {#intermediate-articles-and-docs}
+## 中階文章與文件 {#intermediate-articles-and-docs}
-- [Go 以太坊相關文件](https://geth.ethereum.org/docs/) - _官方以太坊 Golang 相關文件_
-- [Erigon 程式設計者指南](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _圖文指南包括狀態樹、多重證明和交易處理_
+- [Go 以太坊文件](https://geth.ethereum.org/docs/) - _官方以太坊 Golang 的文件_
+- [Erigon 程式設計師指南](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _包含狀態樹、多重證明和交易處理的圖解指南_
- [Erigon 和無狀態以太坊](https://youtu.be/3-Mn7OckSus?t=394) - _2020 年以太坊社群會議 (EthCC 3)_
-- [Erigon:最佳化以太坊用戶端](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 年開發者大會 4 _
-- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
-- [在 Go 上使用 Geth 建立去中心化應用程式](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
-- [透過 Golang 和 Geth 使用以太坊專用網路](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
-- [使用 Go 對以太坊上的 Solidity 合約進行單元測試](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
-- [使用 Geth 作為程式庫的快速參考](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
+- [Erigon:最佳化以太坊用戶端](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_
+- [Go 以太坊 GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
+- [使用 Geth 在 Go 中建立去中心化應用程式](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
+- [使用 Golang 和 Geth 在以太坊私有網路上作業](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
+- [在 Go 中對以太坊上的 Solidity 合約進行單元測試](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
+- [將 Geth 當作函式庫使用的快速參考](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
## 進階使用模式 {#advanced-use-patterns}
- [GETH 模擬後端](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
- [使用以太坊和 Quorum 的區塊鏈即服務應用程式](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
-- [以太坊區塊鏈應用程式中的分佈式存儲星際檔案系統和 Swarm](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
-- [行動用戶端:程式庫和 Inproc 以太坊節點](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
+- [以太坊區塊鏈應用程式中的分散式儲存 IPFS 和 Swarm](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
+- [行動用戶端:函式庫與 Inproc 以太坊節點](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
- [原生去中心化應用程式:以太坊合約的 Go 繫結](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
-## Go 專案和工具 {#go-projects-and-tools}
+## Go 專案與工具 {#go-projects-and-tools}
-- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _以太坊協定的官方 Go 實作_
-- [Go Ethereum 程式碼分析](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _審查和分析 Go Ethereum 原始程式碼_
-- [Erigon](https://github.com/ledgerwatch/erigon) - _Go 以太坊的更快衍生品,專注於歸檔節點_
-- [Golem](https://github.com/golemfactory/golem) - _Golem 正在建立一個算力全球市場_
+- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _以太坊協議的官方 Go 實作_
+- [Go 以太坊程式碼分析](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go 以太坊原始碼的審查與分析_
+- [Erigon](https://github.com/ledgerwatch/erigon) - _Go 以太坊的更快衍生版本,著重於歸檔節點_
+- [Golem](https://github.com/golemfactory/golem) - _Golem 正在建立一個全球算力市場_
- [Quorum](https://github.com/jpmorganchase/quorum) - _支援資料隱私的許可制以太坊實作_
- [Prysm](https://github.com/prysmaticlabs/prysm) - _以太坊「Serenity」2.0 Go 實作_
-- [Eth Tweet](https://github.com/kyokan/plasma) - _去中心化 Twitter:在以太坊區塊鏈上執行的微型部落格服務_
-- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Golang 實作以及最小可行性 Plasma 規範的擴展_
-- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _以太坊開源礦池_
-- [Ethereum HD Wallet](https://github.com/miguelmota/go-ethereum-hdwallet) - _使用 Go 的 Ethereum 硬體錢包衍生品_
-- [Multi Geth](https://github.com/multi-geth/multi-geth) - _支援多種以太坊網路_
-- [Geth Light Client](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _輕量級以太坊子協定的 Geth 實作_
-- [以太坊 Golang 軟體開發套件](https://github.com/everFinance/goether) - _使用 Golang 的簡單以太坊錢包實作和公用程式_
-- [Covalent Golang 軟體開發套件](https://github.com/covalenthq/covalent-api-sdk-go) - _透過 Go 軟體開發套件高效率存取 200 多個區塊鏈的資料_
+- [Eth Tweet](https://github.com/yep/eth-tweet) - _去中心化 Twitter:在以太坊區塊鏈上執行的微部落格服務_
+- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _最小可行性 Plasma 規範的 Golang 實作和擴充_
+- [開源以太坊礦池](https://github.com/sammy007/open-ethereum-pool) - _一個開源的以太坊礦池_
+- [以太坊 HD 錢包](https://github.com/miguelmota/go-ethereum-hdwallet) - _Go 中的以太坊 HD 錢包派生_
+- [Multi Geth](https://github.com/multi-geth/multi-geth) - _支援多種類型的以太坊網路_
+- [Geth 輕用戶端](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _輕量以太坊子協定的 Geth 實作_
+- [以太坊 Golang SDK](https://github.com/everFinance/goether) - _使用 Golang 的簡易以太坊錢包實作與公用程式_
+- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _透過 Go SDK 高效率地存取 200 多個區塊鏈的資料_
-想取得更多資源? 請查看 [ethereum.org/developers](/developers/)
+想取得更多資源? 查看 [ethereum.org/developers](/developers/)
## Go 社群貢獻者 {#go-community-contributors}
- [Geth Discord](https://discordapp.com/invite/nthXNEv)
-- [Geth Gist](https://gitter.im/ethereum/go-ethereum)
-- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#以太坊頻道](https://gophers.slack.com/messages/C9HP1S9V2)
+- [Geth Gitter](https://gitter.im/ethereum/go-ethereum)
+- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#ethereum 頻道](https://gophers.slack.com/messages/C9HP1S9V2)
- [StackExchange - 以太坊](https://ethereum.stackexchange.com/)
- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth)
-- [Ethereum Gitter](https://gitter.im/ethereum/home)
-- [Geth light Client Gitter](https://gitter.im/ethereum/light-client)
+- [以太坊 Gitter](https://gitter.im/ethereum/home)
+- [Geth 輕用戶端 Gitter](https://gitter.im/ethereum/light-client)
-## 其他彙總列表 {#other-aggregated-lists}
+## 其他彙總清單 {#other-aggregated-lists}
-- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum)
-- [Consensys:以太坊開發者工具的最終清單](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHub 來源](https://github.com/ConsenSys/ethereum-developer-tools-list)
+- [Awesome 以太坊](https://github.com/btomashvili/awesome-ethereum)
+- [Consensys:以太坊開發者工具權威清單](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHub 原始碼](https://github.com/ConsenSys/ethereum-developer-tools-list)
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/index.md
index 7898868e490..b9162d75b02 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/index.md
@@ -1,30 +1,33 @@
---
title: 程式語言
-description:
+description: 探索適用於各種程式設計語言 (包括 JavaScript、Python、Go、Rust 等) 的以太坊開發資源。
lang: zh-tw
---
-常見的誤解是,開發者必須編寫[智慧型合約](/developers/docs/smart-contracts/)才能在以太坊上構建。 這是錯誤的。 以太坊網路和社群的優點之一是幾乎可以使用任何程式設計語言[參與](/community/)其中。
+一個常見的誤解是,開發人員必須撰寫 [智慧型合約](/developers/docs/smart-contracts/) 才能在以太坊上建置。 這是錯誤的。
+以太坊網路和社群的美妙之處在於,您幾乎可以用任何程式設計語言 [參與](/community/) 其中。
以太坊及其社群推崇開放原始碼。 你能找到各種語言的社群專案:用戶端實作、應用程式介面、開發架構、測試工具。
-## 選擇你的語言 {#data}
+## 選擇您的語言 {#data}
選擇你的程式設計語言以尋找專案、資源和虛擬社群:
-- [Dart開發者適用的 Ethereum 資源](/developers/docs/programming-languages/dart/)
-- [Delphi 開發者適用的Ethereum 資源](/developers/docs/programming-languages/delphi/)
-- [.NET 開發者適用的 Ethereum 資源](/developers/docs/programming-languages/dot-net/)
-- [Elixir 開發者適用的以太坊資源](/developers/docs/programming-languages/elixir/)
-- [Go 開發者適用的以太坊資源](/developers/docs/programming-languages/golang/)
-- [Java 開發者適用的 Ethereum 資源](/developers/docs/programming-languages/java/)
-- [JavaScript 開發者適用的 Ethereum 資源](/developers/docs/programming-languages/javascript/)
-- [Python 開發者適用的以太坊資源](/developers/docs/programming-languages/python/)
-- [Ruby 開發者適用的以太坊資源](/developers/docs/programming-languages/ruby/)
-- [Rust 開發者適用的 Ethereum 資源](/developers/docs/programming-languages/rust/)
+- [給 Dart 開發人員的以太坊](/developers/docs/programming-languages/dart/)
+- [給 Delphi 開發人員的以太坊](/developers/docs/programming-languages/delphi/)
+- [給 .NET 開發人員的以太坊](/developers/docs/programming-languages/dot-net/)
+- [給 Elixir 開發人員的以太坊](/developers/docs/programming-languages/elixir/)
+- [給 Go 開發人員的以太坊](/developers/docs/programming-languages/golang/)
+- [給 Java 開發人員的以太坊](/developers/docs/programming-languages/java/)
+- [給 JavaScript 開發人員的以太坊](/developers/docs/programming-languages/javascript/)
+- [給 Python 開發人員的以太坊](/developers/docs/programming-languages/python/)
+- [給 Ruby 開發人員的以太坊](/developers/docs/programming-languages/ruby/)
+- [給 Rust 開發人員的以太坊](/developers/docs/programming-languages/rust/)
-### 如果我的語言不受支援,該怎麼辦 {#other-lang}
+### 如果您的語言不受支援,該怎麼辦 {#other-lang}
-如果想連結到資源或指向其他程式設計語言的虛擬社區,可以透過[建立一個議題](https://github.com/ethereum/ethereum-org-website/issues/new/choose)來請求新頁面。
+如果您想連結到資源或指向其他程式設計語言的虛擬社群,可以透過 [開設一個議題](https://github.com/ethereum/ethereum-org-website/issues/new/choose) 來請求新增頁面。
-如果只是想使用目前不支援的語言編寫程式碼來連結區塊鏈, 可以使用 [JSON-RPC 介面](/developers/docs/apis/json-rpc/)連結到以太坊網路。 任何可以 使用 TCP/IP 的程式設計語言都可以使用該介面。
+如果您只想用目前不支援的語言編寫程式碼來連接區塊鏈,
+您可以使用 [JSON-RPC 介面](/developers/docs/apis/json-rpc/) 連接到以太坊網路。 任何可以
+使用 TCP/IP 的程式設計語言都可以使用該介面。
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/java/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/java/index.md
index ad26995e640..de7d984efa6 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/java/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/java/index.md
@@ -5,57 +5,58 @@ lang: zh-tw
incomplete: true
---
-學習如何使用 Java 型專案和工具進行以太坊開發
+學習如何使用基於 Java 的專案和工具進行以太坊開發
使用以太坊建立去中心化應用程式(或稱「dapp」),發揮加密貨幣和區塊鏈技術的優勢。 這些去中心化應用程式是可信的,這意味著一旦部署到以太坊後,它們就會始終按照設定執行。 這些應用程式可以控制數位資產,以便建立新型金融應用程式。 這些應用程式是去中心化的,這意味著任何單一實體或個人都無法控制它們,並且應用程式幾乎不可能被審查。
-## 來開始學習智慧型合約及Solidity語言 {#getting-started-with-smart-contracts-and-solidity}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-solidity}
**邁出第一步,整合 Java 與以太坊**
-需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
+需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers.](/developers/)
-- [區塊鏈詳解](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [瞭解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [編寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [學習如何編譯和部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [詳解區塊鏈](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [了解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [撰寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [學習如何編譯及部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
## 使用以太坊用戶端 {#working-with-ethereum-clients}
-學習如何使用兩種先進的 Java 以太坊用戶端 [Web3J](https://github.com/web3j/web3j) 和 Hyperledger Besu
+學習如何使用 [Web3J](https://github.com/web3j/web3j) 和 Hyperledger Besu,這兩個領先的 Java 以太坊用戶端
-- [使用 Java 、Eclipse 和 Web3J 連線以太坊用戶端](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
+- [使用 Java、Eclipse 和 Web3J 連接到以太坊用戶端](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
- [使用 Java 和 Web3j 管理以太坊帳戶](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
-- [從智慧型合約產生 Java 包裝函式](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
-- [與以太坊智慧型合約互動](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
-- [偵聽以太坊智慧型合約事件](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
-- [使用 Linux 下的 Java 以太坊用戶端 Besu (Pantheon)](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
-- [在 Java 整合測試中執行 Hyperledger Besu (Pantheon) 節點](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
-- [Web3j 速查表](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c)
-
-學習如何使用非同步高效能 Kotlin 程式庫 [ethers-kt](https://github.com/Kr1ptal/ethers-kt),用來與基於以太坊虛擬機的區塊鏈互動。 針對 JVM 和 Android 平台。
-- [傳送 ERC20 代幣](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
-- [通過偵聽事件實現 UniswapV2 兌換](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
-- [以太幣 / ERC20 餘額追蹤器](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
+- [從你的智能合約產生 Java 包裝函式](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
+- [與以太坊智能合約互動](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
+- [監聽以太坊智能合約事件](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
+- [在 Linux 上使用 Besu (Pantheon),Java 以太坊用戶端](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
+- [在 Java 整合測試中運行 Hyperledger Besu (Pantheon) 節點](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
+- [Web3j 速查表](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c)
+
+學習如何使用 [ethers-kt](https://github.com/Kr1ptal/ethers-kt),一個用於與基於以太坊虛擬機的區塊鏈互動的非同步、高效能 Kotlin 程式庫。 針對 JVM 和 Android 平台。
+
+- [轉移 ERC20 代幣](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
+- [帶有事件監聽功能的 UniswapV2 交換](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
+- [ETH / ERC20 餘額追蹤器](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
## 中階文章 {#intermediate-articles}
-- [使用星際檔案系統在 Java 應用程式中管理存儲](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
+- [使用 IPFS 在 Java 應用程式中管理存儲](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
- [使用 Web3j 在 Java 中管理 ERC20 代幣](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
-- [Web3j 交易管理程式](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
+- [Web3j 交易管理器](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
## 進階使用模式 {#advanced-use-patterns}
-- [使用 Eventeum 建置 Java 智慧型合約資料快取](使用 Eventeum 構建Java 智慧型合約數據緩存)
+- [使用 Eventeum 建立 Java 智能合約資料快取](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
## Java 專案和工具 {#java-projects-and-tools}
-- [Web3J(用來與以太坊用戶端互動的程式庫)](https://github.com/web3j/web3j)
-- [ethers-kt(適用於基於以太坊虛擬機的區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。)](https://github.com/Kr1ptal/ethers-kt)
-- [Eventeum(事件偵聽程式)](https://github.com/ConsenSys/eventeum)
-- [Mahuta(星際檔案系統開發者工具)](https://github.com/ConsenSys/mahuta)
+- [Web3J (與以太坊用戶端互動的程式庫)](https://github.com/web3j/web3j)
+- [ethers-kt (適用於基於以太坊虛擬機的區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。)](https://github.com/Kr1ptal/ethers-kt)
+- [Eventeum (事件監聽器)](https://github.com/ConsenSys/eventeum)
+- [Mahuta (IPFS 開發工具)](https://github.com/ConsenSys/mahuta)
-想取得更多資源? 請參考 [ethereum.org/developers。](/developers/)
+想取得更多資源? 請參閱 [ethereum.org/developers.](/developers/)
## Java 社群貢獻者 {#java-community-contributors}
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/javascript/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/javascript/index.md
index efaac18d40a..5e7f60469aa 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/javascript/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/javascript/index.md
@@ -4,59 +4,58 @@ description: 學習如何使用 JavaScript 型專案和工具進行以太坊開
lang: zh-tw
---
-JavaScript 是以太坊生態系統中最常用的語言之一。 事實上,有[團隊](https://github.com/ethereumjs)致力於將盡可能多的以太坊內容引入 JavaScript。
+JavaScript 是以太坊生態系統中最常用的語言之一。 事實上,有個[團隊](https://github.com/ethereumjs)致力於將盡可能多的以太坊內容引入 JavaScript。
有機會在[堆疊的所有層級](/developers/docs/ethereum-stack/)編寫 JavaScript(或類似內容)。
## 與以太坊互動 {#interact-with-ethereum}
-### Javascript 應用程式介面程式庫 {#javascript-api-libraries}
+### JavaScript API 函式庫 {#javascript-api-libraries}
-如果想編寫 JavaScript 來查詢區塊鏈、傳送交易等,最方便的方法是使用 [JavaScript 應用程式介面程式庫](/developers/docs/apis/javascript/)。 這些應用程式介面讓開發者能夠輕鬆與[以太坊網路中的節點](/developers/docs/nodes-and-clients/)進行互動。
+如果您想編寫 JavaScript 來查詢區塊鏈、傳送交易等,最方便的方法是使用 [JavaScript API 函式庫](/developers/docs/apis/javascript/)。 這些 API 可讓開發人員輕鬆與[以太坊網路中的節點](/developers/docs/nodes-and-clients/)互動。
你可以使用這些程式庫與以太坊上的智慧型合約進行互動,因此可以構建一個去中心化應用程式,在此去中心化應用程式中,你只需使用 JavaScript 就能夠與預先存在的合約進行互動。
**查看**
-- [Web3.js](https://web3js.readthedocs.io/)
-- [Ethers.js](https://docs.ethers.io/) _– 包含 JavaScript 和 TypeScript 的以太坊錢包實作和公用程式。_
-- [viem](https://viem.sh) – 以太坊的 TypeScript 介面,提供用於與以太坊互動的低階無狀態基元。
+- [Web3.js](https://web3js.readthedocs.io)
+- [Ethers.js](https://ethers.org) – _包含 JavaScript 和 TypeScript 的以太坊錢包實作和公用程式。_
+- [viem](https://viem.sh) – _一個適用於以太坊的 TypeScript 介面,提供用於與以太坊互動的低階無狀態基元。_
+- [Drift](https://ryangoree.github.io/drift/) – _一個 TypeScript 元函式庫,內建快取、掛鉤和測試模擬,可跨 web3 函式庫輕鬆進行以太坊開發。_
-### 智慧型合約 {#smart-contracts}
+### 智能合約 {#smart-contracts}
-如果你是 JavaScript 開發者,並打算編寫自己的智慧型合約,那你會想瞭解 [Solidity](https://solidity.readthedocs.io)。 這是最常用的智慧型合約語言,它在語法上與 JavaScript 類似,因而可能更容易學習。
+如果您是 JavaScript 開發人員,且想撰寫自己的智慧型合約,您可能會想熟悉 [Solidity](https://solidity.readthedocs.io)。 這是最常用的智慧型合約語言,它在語法上與 JavaScript 類似,因而可能更容易學習。
-更多[智慧型合約](/developers/docs/smart-contracts/)相關資訊。
+更多關於[智慧型合約](/developers/docs/smart-contracts/)的資訊。
-## 理解協定 {#understand-the-protocol}
+## 了解協議 {#understand-the-protocol}
### 以太坊虛擬機 {#the-ethereum-virtual-machine}
-[以太坊虛擬機](/developers/docs/evm/)有 JavaScript 實作。 該虛擬機支援最新的分叉規則。 分叉規則是指由於計劃的升級而對以太坊虛擬機所做的變更。
+已有 [以太坊虛擬機](/developers/docs/evm/) 的 JavaScript 實作。 該虛擬機支援最新的分叉規則。 分叉規則是指由於計劃的升級而對以太坊虛擬機所做的變更。
分叉規則分為各種 JavaScript 包,可以查看這些包取得更深入的理解:
- 帳戶
- 區塊
- 區塊鏈本身
-- 交易紀錄
+- 交易
- 和更多相關內容...
這將幫助你理解「帳戶的資料結構是什麼?」等問題。
如果你喜歡閱讀程式碼,此 JavaScript 可能是閱讀我們文件的絕佳替代方案。
-**請查看 monorepo**
-[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm)
+**查看 EVM**
+[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm)
-### 節點和客戶 {#nodes-and-clients}
+### 節點與用戶端 {#nodes-and-clients}
目前正在開發的 Ethereum.js 讓你能夠深入瞭解以太坊用戶端如何用你理解的語言 JavaScript 運作!
-它曾經托管於獨立的[`儲存庫`](https://github.com/ethereumjs/ethereumjs-client)中,但後來作為一個包被併入 EthereumVM monorepo 中。
-
-**請查看用戶端**
-[`ethereumjs-client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
+**查看用戶端**
+[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
## 其他專案 {#other-projects}
@@ -64,10 +63,10 @@ JavaScript 是以太坊生態系統中最常用的語言之一。 事實上,
- 錢包公用程式程式庫。
- 用於產生匯入和匯出以太坊金鑰的工具。
-- `merkle-patricia-tree` 的實作 – 以太坊黃皮書中概述的資料結構。
+- `merkle-patricia-tree` 的實作 – 一種以太坊黃皮書中所概述的資料結構。
-在 [EthereumJS repo](https://github.com/ethereumjs) 深入瞭解你感興趣的任何內容
+前往 [EthereumJS repo](https://github.com/ethereumjs) 深入探索您最感興趣的內容。
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/python/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/python/index.md
index fc8b819c749..9d60114604b 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/python/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/python/index.md
@@ -5,68 +5,77 @@ lang: zh-tw
incomplete: true
---
-學習如何使用 Python 型專案和工具進行以太坊開發
+學習如何使用基於 Python 的專案和工具進行以太坊開發
-使用 Ethereum 建立去中心化應用程式 (或稱「dapp」),發揮加密貨幣學和區塊鏈技術的優勢。 這些去中心化應用程式一旦部署到 Ethereum 後,就會持續地按照其設計的方式執行,進而成為非常可信的工具, 這些應用程序可以控制數字資產,以便創造新的金融應用; 這些應用程式是去中心化的,表示任何單一的實體或個人都不能加以控制,也幾乎不可能被審查。
+使用以太坊建立去中心化應用程式(或稱「dapp」),發揮加密貨幣和區塊鏈技術的優勢。 這些去中心化應用程式是可信的,這意味著一旦部署到以太坊後,它們就會始終按照設定執行。 這些應用程式可以控制數位資產,以便建立新型金融應用程式。 這些應用程式是去中心化的,這意味著任何單一實體或個人都無法控制它們,並且應用程式幾乎不可能被審查。
-## 來開始學習智慧型合約及Solidity語言 {#getting-started-with-smart-contracts-and-solidity}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-solidity}
**邁出第一步,整合 Python 與以太坊**
-需要基礎的入門指南嗎? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
+需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
-- [區塊鏈詳解](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [詳解區塊鏈](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
- [了解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [編寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [學習如何編寫和部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [撰寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [學習如何編譯及部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [2023 年 Python 在區塊鏈領域的現狀報告](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
## 初學者文章 {#beginner-articles}
+- [web3.py 概覽](https://web3py.readthedocs.io/en/latest/overview.html)
+- [以太坊 Python 生態系統導覽](https://snakecharmers.ethereum.org/python-ecosystem/)
- [以太坊 (Python) 開發者指南](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
-- [2023 年報告 Python 在區塊鏈中的狀態](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
-- [使用 Vyper 的智慧型合約簡介](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
-- [使用 Pyhthon 及 Brownie 來部署你自己的 ERC20 代幣](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
-- [如何使用 Python Flask 開發 Ethereum 合約?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
-- [Web3.py 簡介 · Python 開發者適用的 Ethereum 資源](https://www.dappuniversity.com/articles/web3-py-intro)
-- [如何使用 Python 和 web3.py 叫用智慧型合約函數?](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
+- [值得獲獎:以太坊 Python 黑客松指南](https://snakecharmers.ethereum.org/prize-worthy/)
+- [Vyper 智能合約簡介](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
+- [如何使用 Python Flask 開發以太坊合約?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
+- [Web3.py 簡介 · 獻給 Python 開發者的以太坊](https://www.dappuniversity.com/articles/web3-py-intro)
+- [如何使用 Python 和 web3.py 呼叫智能合約函式](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
## 中階文章 {#intermediate-articles}
-- [適用 Python 程式設計者的去中心化應用程式開發](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28)
+- [web3.py 的夥伴們:Ape 簡介](https://snakecharmers.ethereum.org/intro-to-ape/)
+- [獻給 Python 程式設計師的去中心化應用程式開發](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28)
- [建立 Python 以太坊介面:第 1 部分](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
-- [使用 Python 編寫的以太坊智慧型合約:完整(不確定)指南](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
-- [使用 Brownie 和 Python 部屬智慧型合約](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
-- [使用 Brownie 於 OpenSea 建立非同質化代幣](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
+- [Python 中的以太坊智能合約:一份(相當)全面的指南](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
## 進階使用模式 {#advanced-use-patterns}
-- [使用 Python 編譯、部署和呼叫以太坊智慧型合約](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
-- [使用 Slither 分析 Solidity 智慧型合約](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
-- [區塊鏈金融科技教學:使用 Python 實作借貸](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
+- [web3.py 模式:即時事件訂閱](https://snakecharmers.ethereum.org/subscriptions/)
+- [web3.py 模式:WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/)
+- [使用 Python 編譯、部署和呼叫以太坊智能合約](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
+- [使用 Slither 分析 Solidity 智能合約](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
+- [區塊鏈金融科技教學:使用 Python 進行借貸](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
+
+## 封存的文章
+
+- [使用 Python 和 Brownie 部署您自己的 ERC20 代幣](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
+- [使用 Brownie 和 Python 部署智能合約](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
+- [使用 Brownie 在 OpenSea 上建立 NFT](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
## Python 專案和工具 {#python-projects-and-tools}
### 使用中: {#active}
-- [Web3.py](https://github.com/ethereum/web3.py) - _用於與以太坊互動的 Python 程式庫_
-- [Vyper](https://github.com/ethereum/vyper/) - _用於以太坊虛擬機的 Python 智慧型合約語言_
-- [Ape](https://github.com/ApeWorX/ape) - _ Python 程式人員、資料科學家和安全性專業人員適用的智慧合約開發工具_
-- [py-evm](https://github.com/ethereum/py-evm) - _以太坊虛擬機實作_
-- [eth-tester](https://github.com/ethereum/eth-tester) - _基於以太坊的應用程式的測試工具_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _使用 Ethereum 相關程式碼庫的公用程式函數_
+- [Web3.py](https://github.com/ethereum/web3.py) - _與以太坊互動的 Python 程式庫_
+- [Vyper](https://github.com/ethereum/vyper/) - _EVM 的 Python 風格智能合約語言_
+- [Ape](https://github.com/ApeWorX/ape) - _專為 Python 愛好者、資料科學家和安全專家設計的智能合約開發工具_
+- [py-evm](https://github.com/ethereum/py-evm) - _以太坊虛擬機的實作_
+- [eth-tester](https://github.com/ethereum/eth-tester) - _用於測試基於以太坊的應用程式的工具_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _用於處理以太坊相關程式碼庫的公用程式函式_
- [py-solc-x](https://pypi.org/project/py-solc-x/) - _適用於 solc solidity 編譯器(支援 0.5.x)的 Python 包裝函式_
-- [pymaker](https://github.com/makerdao/pymaker) - _用於 Maker 合約的 Python 應用程式介面_
-- [siwe](https://github.com/signinwithethereum/siwe-py) - _用於 Python 的以太坊 (siwe) 登入_
-- [用於以太坊整合的 Web3 去中心化金融](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _一個預先整合 ERC-20、Uniswap 和其他受歡迎專案的 Python 包_
-- [Wake](https://getwake.io) - _用於合約測試、初略模糊、部署、漏洞掃描和程式碼導航的一體化 Python 框架(語言伺服器 - [Solidity 工具](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
+- [pymaker](https://github.com/makerdao/pymaker) - _Maker 合約的 Python API_
+- [siwe](https://github.com/signinwithethereum/siwe-py) - _適用於 Python 的使用以太坊登入 (siwe)_
+- [用於以太坊整合的 Web3 DeFi](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _一個預先整合 ERC-20、Uniswap 和其他熱門專案的 Python 套件_
+- [Wake](https://getwake.io) - _多合一 Python 框架,用於合約測試、模糊測試、部署、漏洞掃描和程式碼導覽(語言伺服器 - [Solidity 工具](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
-### 已歸檔/不再維護: {#archived--no-longer-maintained}
+### 已封存 / 不再維護: {#archived--no-longer-maintained}
- [Trinity](https://github.com/ethereum/trinity) - _以太坊 Python 用戶端_
-- [Mamba](https://github.com/arjunaskykok/mamba) - _用於編寫、編譯和部署使用 Vyper 語言編寫的智慧型合約的架構_
-- [Brownie](https://github.com/eth-brownie/brownie) - _用於部署、測試和與以太坊智慧型合約互動的 Python 框架_
-- [pydevp2p](https://github.com/ethereum/pydevp2p) - _以太坊點對點堆疊的實作_
-- [py-wasm](https://github.com/ethereum/py-wasm) - _網路組件解釋器 Python 實作_
+- [Mamba](https://github.com/arjunaskykok/mamba) - _用於編寫、編譯和部署以 Vyper 語言編寫的智能合約的框架_
+- [Brownie](https://github.com/eth-brownie/brownie) - _用於部署、測試和與以太坊智能合約互動的 Python 框架_
+- [pydevp2p](https://github.com/ethereum/pydevp2p) - _以太坊 P2P 堆疊的實作_
+- [py-wasm](https://github.com/ethereum/py-wasm) - _WebAssembly 解譯器的 Python 實作_
想取得更多資源? 請查看 [ethereum.org/developers](/developers/)。
@@ -74,17 +83,17 @@ incomplete: true
以下基於以太坊的專案使用本頁提到的工具。 相關的開放原始碼儲存庫可以作為範例程式碼的良好參考和最佳做法。
-- [Yearn Finance](https://yearn.finance/) 及 [Yearn Vault 合約儲存庫](https://github.com/yearn/yearn-vaults)
-- [Curve](https://curve.fi/) 及 [Curve 智慧型合約儲存庫](https://github.com/curvefi/curve-contract)
-- [BadgerDAO](https://badger.com/) 及 [使用 Brownie 工具鏈的智慧型合約](https://github.com/Badger-Finance/badger-system)
-- [Sushi](https://sushi.com/) 使用 [Python 管理和部署其歸屬合約](https://github.com/sushiswap/sushi-vesting-protocols)
-- [ Alpha Finance](https://alphafinance.io/) 以 Alpha Homora 聞名,使用 [Brownie 測試和部署智慧型合約](https://github.com/AlphaFinanceLab/alpha-staking-contract)
+- [Yearn Finance](https://yearn.finance/) 與 [Yearn Vault 合約儲存庫](https://github.com/yearn/yearn-vaults)
+- [Curve](https://www.curve.finance/) 與 [Curve 智能合約儲存庫](https://github.com/curvefi/curve-contract)
+- [BadgerDAO](https://badger.com/) 與 [使用 Brownie 工具鏈的智能合約](https://github.com/Badger-Finance/badger-system)
+- [Sushi](https://sushi.com/) 使用 [Python 來管理和部署其歸屬合約](https://github.com/sushiswap/sushi-vesting-protocols)
+- 以 Alpha Homora 聞名的 [Alpha Finance](https://alphafinance.io/) 使用 [Brownie 來測試和部署智能合約](https://github.com/AlphaFinanceLab/alpha-staking-contract)
## Python 社群討論 {#python-community-contributors}
-- [以太坊 Python 社群 Discord](https://discord.gg/9zk7snTfWe),可討論 Web3.py 與其他 Python 架構
-- [Vyper Discord](https://discord.gg/SdvKC79cJk) ,可討論 Vyper 智慧型合約程式設計語言
+- [以太坊 Python 社群 Discord](https://discord.gg/9zk7snTfWe),可討論 Web3.py 和其他 Python 框架
+- [Vyper Discord](https://discord.gg/SdvKC79cJk),可討論 Vyper 智能合約程式設計
## 其他彙總清單 {#other-aggregated-lists}
-Vyper 維基百科提供[完善的 Vyper 資源清單](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)
\ No newline at end of file
+Vyper wiki 有一份 [Vyper 的絕佳資源清單](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)
\ No newline at end of file
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/ruby/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/ruby/index.md
index 76702f11a09..49ef9501996 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/ruby/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/ruby/index.md
@@ -5,56 +5,56 @@ lang: zh-tw
incomplete: false
---
-學習使用 Ruby 型專案和工具進行以太坊開發。
+學習如何使用基於 Ruby 的專案和工具進行以太坊開發。
-使用 Ethereum 建立去中心化應用程式 (或稱「dapp」),發揮加密貨幣學和區塊鏈技術的優勢。 這些去中心化應用程式是無需信任的,這意味著一旦部署到以太坊後,就會始終按程式執行。 它們可以控制數位資產來建立新型的金融應用程式。 這些應用程式是去中心化的,表示任何單一的實體或個人都不能加以控制,也幾乎不可能被審查。
+使用以太坊建立去中心化應用程式(或稱「dapp」),發揮加密貨幣和區塊鏈技術的優勢。 這些去中心化應用程式是無需信任的,這意味著一旦部署到以太坊後,就會始終按程式執行。 它們可以控制數位資產來建立新型的金融應用程式。 這些應用程式是去中心化的,這意味著任何單一實體或個人都無法控制它們,並且應用程式幾乎不可能被審查。
-## 來開始學習智慧型合約及Solidity語言 {#getting-started-with-smart-contracts-and-solidity}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-solidity}
**邁出第一步,整合 Ruby 與以太坊**
-需要基礎的入門指南嗎? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
+需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
-- [區塊鏈詳解](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [詳解區塊鏈](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
- [了解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [編寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [學習如何編寫和部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [撰寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [學習如何編譯及部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
## 初學者文章 {#beginner-articles}
-- [終於理解以太坊帳戶](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
-- [使用 MetaMask 最終驗證 Rails 使用者](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
+- [徹底理解以太坊帳戶](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [總算能使用 MetaMask 驗證 Rails 使用者](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
- [如何使用 Ruby 連接到以太坊網路](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby)
-- [如何使用 Ruby 產生新的以太坊地址](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
+- [如何在 Ruby 中生成新的以太坊地址](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
## 中階文章 {#intermediate-articles}
-- [使用 Ruby 編寫的區塊鏈應用程式](https://www.nopio.com/blog/blockchain-app-ruby/)
-- [使用 Ruby 連接到以太坊來執行智慧型合約](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
+- [使用 Ruby 的區塊鏈應用程式](https://www.nopio.com/blog/blockchain-app-ruby/)
+- [使用連接到以太坊的 Ruby 來執行智能合約](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
-## Rust 專案和工具 {#ruby-projects-and-tools}
+## Ruby 專案和工具 {#ruby-projects-and-tools}
### 使用中 {#active}
- [eth.rb](https://github.com/q9f/eth.rb) - _Ruby 程式庫與遠端程序呼叫用戶端,用於處理以太坊帳戶、訊息以及交易_
-- [keccak.rb](https://github.com/q9f/keccak.rb) - _以太坊使用的 Keccak (SHA3) 雜湊值_
-- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Sign-In with Ethereum的 Ruby 實作_
-- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _添加 SIWE 本地登入路由的 Rails gem_
-- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _使用 Ruby on Rails 的 SIWE 範例(含自訂控製器)_
-- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _面向 Sign In With Ethereum (SIWE) 的 OmniAuth 策略_
-- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _面向通過非同質化代幣所有權進行身份驗證的 OmniAuth 策略_
+- [keccak.rb](https://github.com/q9f/keccak.rb) - _以太坊使用的 Keccak (SHA3) 哈希_
+- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Sign-In with Ethereum 的 Ruby 實作_
+- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _新增 SIWE 本地登入路由的 Rails 套件_
+- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _使用 Ruby on Rails 和自訂控制器的 SIWE 範例_
+- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _適用於 Sign In With Ethereum (SIWE) 的 OmniAuth 策略_
+- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _適用於透過 NFT 所有權進行驗證的 OmniAuth 策略_
- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _Ethereum on Rails 範本,允許將 MetaMask 連結到 Ruby on Rails_
-### 已歸檔/不再維護 {#archived--no-longer-maintained}
+### 已封存/不再維護 {#archived--no-longer-maintained}
-- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _使用 Ruby 呼叫以太坊節點的遠端程序遠呼叫方法_
-- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _用於根據 BIP32 標準從分層確定性錢包產生以太幣地址的 Ruby 程式庫_
-- [etherlite](https://github.com/budacom/etherlite) - _Ruby on Rails 的以太坊整合_
-- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _使用 JSON-RPC 介面傳送交易、建立合約並與之互動的 Ruby 以太坊用戶端以及可使用以太坊節點的有用工具組_
-- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _實作面向 OmniAuth 的以太坊提供者策略_
+- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _使用 Ruby 呼叫以太坊節點的 RPC 方法_
+- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _用於根據 BIP32 標準從分層確定性錢包產生 ETH 地址的 Ruby 程式庫_
+- [etherlite](https://github.com/budacom/etherlite) - _適用於 Ruby on Rails 的以太坊整合_
+- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _使用 JSON-RPC 介面傳送交易、建立合約並與之互動的 Ruby 以太坊用戶端,以及可使用以太坊節點的有用工具組_
+- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _為 OmniAuth 實作以太坊提供者策略_
想取得更多資源? 請查看[開發者首頁](/developers/)。
## Ruby 社群貢獻者 {#ruby-community-contributors}
-[以太坊 Ruby Telegram 群組](https://t.me/ruby_eth)是一個快速發展的社群,是討論上述任何專案和相關主題的專用資源。
+[Ethereum Ruby Telegram 群組](https://t.me/ruby_eth) 是一個快速成長的社群,也是專門討論上述任何專案與相關主題的資源。
diff --git a/public/content/translations/zh-tw/developers/docs/programming-languages/rust/index.md b/public/content/translations/zh-tw/developers/docs/programming-languages/rust/index.md
index 46073a16dd6..49a4ded3fa5 100644
--- a/public/content/translations/zh-tw/developers/docs/programming-languages/rust/index.md
+++ b/public/content/translations/zh-tw/developers/docs/programming-languages/rust/index.md
@@ -5,55 +5,57 @@ lang: zh-tw
incomplete: true
---
-學習如何使用 Rust 型專案和工具進行以太坊開發
+學習如何使用 Rust 專案與工具進行以太坊開發
-使用 Ethereum 建立去中心化應用程式 (或稱「dapp」),發揮加密貨幣學和區塊鏈技術的優勢。 這些去中心化應用程式一旦部署到 Ethereum 後,就會持續地按照其設計的方式執行,進而成為非常可信的工具, 這些應用程序可以控制數字資產,以便創造新的金融應用; 這些應用程式是去中心化的,表示任何單一的實體或個人都不能加以控制,也幾乎不可能被審查。
+使用以太坊建立去中心化應用程式(或稱「dapp」),發揮加密貨幣和區塊鏈技術的優勢。 這些去中心化應用程式是可信的,這意味著一旦部署到以太坊後,它們就會始終按照設定執行。 這些應用程式可以控制數位資產,以便建立新型金融應用程式。 這些應用程式是去中心化的,這意味著任何單一實體或個人都無法控制它們,並且應用程式幾乎不可能被審查。
-## 智慧型合約及 Solidity 語言入門 {#getting-started-with-smart-contracts-and-solidity}
+## 智慧型合約及 Solidity 程式語言入門 {#getting-started-with-smart-contracts-and-solidity}
**邁出第一步,整合 Rust 與以太坊**
-需要基礎的入門指南嗎? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
+需要先看看更基礎的入門指南? 請查看 [ethereum.org/learn](/learn/) 或 [ethereum.org/developers](/developers/)。
-- [區塊鏈詳解](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [詳解區塊鏈](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
- [了解智慧型合約](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [編寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [學習如何編寫和部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [撰寫你的第一個智慧型合約](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [學習如何編譯及部署 Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
## 初學者文章 {#beginner-articles}
-- [Rust 以太坊用戶端](https://openethereum.github.io/) \* **請注意 OpenEthereum [已棄用](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd)且不再維護。**如欲使用此用戶端,請小心謹慎,最好改用其他用戶端實作。
-- [使用 Rust 向以太坊傳送交易](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
-- [使用 Rust 為 Kovan 編寫 Wasm 合約的逐步教學](https://github.com/paritytech/pwasm-tutorial)
+- [Rust 以太坊用戶端](https://openethereum.github.io/) \* **請注意,OpenEthereum [已被棄用](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) 且不再維護。** 請謹慎使用,最好改用其他用戶端實作。
+- [使用 Rust 將交易傳送到以太坊](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
+- [在 Kovan 上使用 Rust Wasm 編寫合約的逐步教學](https://github.com/paritytech/pwasm-tutorial)
## 中階文章 {#intermediate-articles}
## 進階使用模式 {#advanced-use-patterns}
-- [與類 Ethereum 網路互動的 pwasm_ethereum 外部程式庫](https://github.com/openethereum/pwasm-ethereum)
-- [使用 JavaScript 和 Rust 建置去中心化聊天室](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
-- [使用 Vue.js 和 Rust 建置去中心化待辦事項應用程式](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
+- [pwasm_ethereum 外部函式庫,用於與類以太坊網路互動](https://github.com/openethereum/pwasm-ethereum)
-- [使用 Rust 構建區塊鏈](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
+- [使用 JavaScript 和 Rust 建立去中心化聊天室](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
-## Rust 專案和工具 {#rust-projects-and-tools}
+- [使用 Vue.js 和 Rust 建立去中心化待辦事項應用程式](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
-- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _與類以太坊網路互動的外部程式庫集合_
-- [Lighthouse](https://github.com/sigp/lighthouse) - _快速以太坊共識層用戶端_
-- [ Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _對以太坊智慧型合約執行層提議的重新設計,使用了 WebAssembly 的確定性子集_
-- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS 應用程式介面參考_
-- [Solaris](https://github.com/paritytech/sol-rs) - _使用原生 Parity 用戶端以太坊虛擬機的 Solidity 智慧型合約單元測試框架。_
+- [使用 Rust 建立區塊鏈](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
+
+## Rust 專案與工具 {#rust-projects-and-tools}
+
+- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _用於與類以太坊網路互動的外部函式集合_
+- [Lighthouse](https://github.com/sigp/lighthouse) - _快速的以太坊共識層用戶端_
+- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _對以太坊智能合約執行層提議的重新設計,使用了 WebAssembly 的確定性子集_
+- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS API 參考_
+- [Solaris](https://github.com/paritytech/sol-rs) - _使用原生 Parity 用戶端以太坊虛擬機的 Solidity 智能合約單元測試框架。_
- [SputnikVM](https://github.com/rust-blockchain/evm) - _Rust 以太坊虛擬機實作_
-- [rust-web3](https://github.com/tomusdrw/rust-web3) - _ 使用 Rust 語言的 Wavelet 智慧型合約_
+- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _使用 Rust 編寫的 Wavelet 智能合約_
- [Foundry](https://github.com/foundry-rs/foundry) - _以太坊應用程式開發工具組_
-- [Alloy](https://alloy.rs) - _高效能、經過充分測試和有記載的程式庫,用於與以太坊及其他基於以太坊虛擬機的鏈進行互動。_
-- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _以太坊程式庫和錢包實作_
-- [SewUp](https://github.com/second-state/SewUp) - _程式庫,正如普通後端開發一樣,能夠協助使用 Rust 語言構建以太坊 Webassembly 合約_
+- [Alloy](https://alloy.rs) - _用於與以太坊及其他基於 EVM 的鏈互動的高效能、經過充分測試且文件齊全的程式庫。_
+- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _以太坊程式庫與錢包實作_
+- [SewUp](https://github.com/second-state/SewUp) - _一個程式庫,可協助您使用 Rust 建構以太坊 WebAssembly 合約,就像開發一般後端一樣_
- [Substreams](https://github.com/streamingfast/substreams) - _平行化區塊鏈資料索引技術_
-- [Reth](https://github.com/paradigmxyz/reth) - Reth(Rust 以太坊的簡稱)是新的以太坊全節點實作
-- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _在以太坊生態系統中用 Rust 編寫的專案精選集合_
+- [Reth](https://github.com/paradigmxyz/reth) Reth(Rust Ethereum 的縮寫)是新的以太坊全節點實作
+- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _在以太坊生態系中以 Rust 編寫的專案精選集合_
-想取得更多資源? 請查看 [ethereum.org/developers](/developers/)。
+想取得更多資源? 請參閱 [ethereum.org/developers.](/developers/)
## Rust 社群貢獻者 {#rust-community-contributors}
diff --git a/public/content/translations/zh-tw/developers/docs/scaling/index.md b/public/content/translations/zh-tw/developers/docs/scaling/index.md
index 3ae8b9f0d7d..8873d912439 100644
--- a/public/content/translations/zh-tw/developers/docs/scaling/index.md
+++ b/public/content/translations/zh-tw/developers/docs/scaling/index.md
@@ -1,39 +1,39 @@
---
-title: 擴張
+title: 擴容
description: 介紹以太坊社群目前正在開發的多種擴張方案。
lang: zh-tw
sidebarDepth: 3
---
-## 擴張方案概覽 {#scaling-overview}
+## 擴張總覽 {#scaling-overview}
隨著以太坊使用者數量暴增,該區塊鏈已抵達一定程度的處理能力極限。 這大幅提高了使用該網路所需的費用,引發了對「擴展解決方案」的需求。 目前正在研究、試驗和實作多種解決方案,採取不同的方法實現相似的目標。
-可擴展性的主要目標是在不犧牲去中心化或安全性的情況下,提高交易速度(更快的最終性)和交易吞吐量(更高的每秒交易數)(更多資訊,請參閱[以太坊願景](/roadmap/vision/))。 在一層網路以太坊區塊鏈上,高需求導致交易速度下降和難以維繫的[燃料價格](/developers/docs/gas/)。 從速度和吞吐量方面提高網路處理能力,將成為促進以太坊廣泛運用的重要基礎。
+可擴展性的主要目標是在不犧牲去中心化或安全性的情況下提高交易速度(更快達到最終性)和交易吞吐量(每秒更高的交易量)。 在第 1 層以太坊區塊鏈上,高需求會導致交易速度變慢,[gas 價格](/developers/docs/gas/) 也高到不可行。 從速度和吞吐量方面提高網路處理能力,將成為促進以太坊廣泛運用的重要基礎。
雖然速度及吞吐量極為重要,但擴張解決方案在實現這些目標的同時保持去中心化和安全也很重要。 降低節點營運者的進入門檻,對於防止算力的中心化和非安全化演進至關重要。
-概念上,我們首先將擴張歸為兩種類型:鏈上擴張和鏈外擴張.
+概念上,我們首先將擴張歸為兩種類型:鏈上擴張和鏈下擴張。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
你需要全面了解以太坊的所有基礎概念。 擴張解決方案的實作尚未被廣泛接受,因為該技術較少歷經實戰檢驗,並且仍在研究和開發中。
-## 鏈上擴張 {#on-chain-scaling}
+## 鏈上擴張 {#onchain-scaling}
-鏈上擴張需要更改以太坊協定(一層網路[主網](/glossary/#mainnet))。 長期以來,區塊鏈分片被寄望於擴張以太坊。 分片涉及將區塊鏈分割成單獨的片段(分片),並由部分驗證者進行驗證。 然而,透過二層網路卷軸進行擴張已經取而代之,成爲首要的擴張技術。 為了支援這一點,我們增加了一種新的較便宜的資料形式附加到以太坊區塊,該資料專門為了降低使用者使用卷軸的成本而設計。
+鏈上擴張需要變更以太坊協定(Layer 1 [主網](/glossary/#mainnet))。 長期以來,區塊鏈分片被寄望於擴張以太坊。 分片涉及將區塊鏈分割成單獨的片段(分片),並由部分驗證者進行驗證。 然而,透過二層網路卷軸進行擴張已經取而代之,成爲首要的擴張技術。 為了支援這一點,我們增加了一種新的較便宜的資料形式附加到以太坊區塊,該資料專門為了降低使用者使用卷軸的成本而設計。
### 分片 {#sharding}
-分片是分割資料庫的過程。 部分驗證者將負責單獨的分片,而無需追蹤整個以太坊。 分片曾長期居於以太坊[開發藍圖](/roadmap/)之上,並且在合併至權益證明之前一度計劃上線。 然而,[二層網路卷軸](#layer-2-scaling)的快速發展和 [Danksharding](/roadmap/danksharding) 的發明(將卷軸資料的二進位大型物件新增至可由驗證者非常高效地進行驗證的以太坊區塊),致使以太坊社群更傾向於采用以卷軸為中心的擴張,而不是透過分片擴張。 這也會有助於使以太坊的共識邏輯更為簡單。
+分片是分割資料庫的過程。 部分驗證者將負責單獨的分片,而無需追蹤整個以太坊。 分片長久以來都是以太坊[開發藍圖](/roadmap/) 的一部分,原先打算在「合併」轉換為權益證明之前推出。 然而,[第 2 層卷軸](#layer-2-scaling) 的快速發展與 [Danksharding](/roadmap/danksharding)(將卷軸資料的 blob 新增到以太坊區塊中,讓驗證者可以極有效率地驗證)的發明,已使以太坊社群傾向採用以卷軸為中心的擴張方案,而非透過分片來擴張。 這也會有助於使以太坊的共識邏輯更為簡單。
-## 鏈外擴張 {#off-chain-scaling}
+## 鏈外擴張 {#offchain-scaling}
-鏈外擴張與一層網路主網分開實作 - 它們不需要變更現有的以太坊協定。 一些被稱爲「二層網路」的解決方案,直接從一層網路以太坊共識獲得安全性,例如[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)、[零知識證明卷軸](/developers/docs/scaling/zk-rollups/)或[狀態通道](/developers/docs/scaling/state-channels/)。 其他解決方案涉及建立獨立於主網獲取安全性的各種形式的新鏈,例如[側鏈](#sidechains)、[Validium](#validium) 或 [Plasma 鏈](#plasma)。 這些解決方案與主網通訊,但以不同方式獲取其安全性以實現不同的目標。
+鏈下擴張與一層網路主網分開實作 - 它們不需要變更現有的以太坊協定。 有些解決方案,稱為「Layer 2」解決方案,其安全性直接源自 Layer 1 以太坊的共識,例如[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)、[零知識卷軸](/developers/docs/scaling/zk-rollups/)或[狀態通道](/developers/docs/scaling/state-channels/)。 其他解決方案涉及建立各種形式的新鏈,這些鏈的安全性獨立於主網,例如[側鏈](#sidechains)、[Validium](#validium) 或 [Plasma 鏈](#plasma)。 這些解決方案與主網通訊,但以不同方式獲取其安全性以實現不同的目標。
-### 二層網路擴張 {#layer-2-scaling}
+### Layer 2 擴張 {#layer-2-scaling}
-此類鏈外解決方案從以太坊主網獲取安全性。
+此類鏈下解決方案從以太坊主網獲取安全性。
二層網路是一種統稱,用於描述那些旨在透過在以太坊主網(一層網路)之外處理交易,同時利用主網强大的去中心化安全模型來幫助擴張應用程式的解決方案。 當網路堵塞時,交易速度會受到影響,這會使某些類型的去中心化應用程式的用戶體驗變差。 而且隨著網路更加堵塞,交易送發者需要用高價燃料費來標取處理優先權,導致燃料費漲價。 這會讓使用以太坊非常昂貴。
@@ -48,66 +48,66 @@ sidebarDepth: 3
- 任何可擴性更新不應以損害去中心化或安全性為代價 - 二層網路建置于以太坊之上。
- 一些二層網路有特定的應用領域,在大規模處理資產時有很高的效率。
-[瞭解更多關於二層網路的資訊](/layer-2/)。
+[更多關於 Layer 2 的資訊](/layer-2/)。
#### 卷軸 {#rollups}
-卷軸在一層網路之外執行交易,接著將資料發佈到一層網路並在其上達成共識。 當交易資料被包含到一層網路區塊時,這讓卷軸能夠受到原生以太坊安全性的保障。
+卷軸在一層網路之外執行交易,接著將資料發佈到一層網路並在其上達成共識。 當交易資料被包含至Layer 1區塊中, 此使卷軸能夠被以太坊原生安全系統所保障.
依不同安全模式,有兩種類型的卷軸:
-- **樂觀卷軸**:假設交易在預設條件下有效,並且僅在遇到挑戰時透過[**詐欺證明**](/glossary/#fraud-proof)執行計算。 [有關樂觀卷軸的更多資訊](/developers/docs/scaling/optimistic-rollups/)。
-- **零知識卷軸**:在鏈外執行計算並提交[**有效性證明**](/glossary/#validity-proof)至鏈上。 [有關零知識卷軸的更多資訊](/developers/docs/scaling/zk-rollups/)。
+- **樂觀卷軸**:預設假設交易有效,只在有人提出挑戰時,才會透過 [**詐欺證明**](/glossary/#fraud-proof) 執行運算。 [更多關於樂觀卷軸的資訊](/developers/docs/scaling/optimistic-rollups/)。
+- **零知識卷軸**:在鏈下執行運算,並向鏈上提交 [**有效性證明**](/glossary/#validity-proof)。 [更多關於零知識卷軸的資訊](/developers/docs/scaling/zk-rollups/)。
#### 狀態通道 {#channels}
-狀態通道使用多簽合約,讓參與者能夠快速、自由地在鏈外交易,然後與主網達成最終性。 這會減少網路擁塞,降低費用並縮短處理延遲。 目前主要有兩種類型的通道:狀態通道和支付通道。
+狀態通道使用多簽合約,讓參與者能夠快速、自由地在鏈下交易,然後與主網達成最終性。 這會減少網路擁塞,降低費用並縮短處理延遲。 目前主要有兩種類型的通道:狀態通道和支付通道。
-瞭解更多關於[狀態通道](/developers/docs/scaling/state-channels/)的資訊。
+深入了解[狀態通道](/developers/docs/scaling/state-channels/)。
### 側鏈 {#sidechains}
側鏈是一個與以太坊相容,並與以太坊主網平行運行的獨立區塊鏈。 側鏈透過雙向跨鏈橋與以太坊相容,並運行自己選定的共識規則及區塊參數。
-瞭解更多關於[側鏈](/developers/docs/scaling/sidechains/)的資訊。
+深入了解[側鏈](/developers/docs/scaling/sidechains/)。
### Plasma {#plasma}
-Plasma 是一條獨立的區塊鏈,與以太坊主鏈錨定,並使用詐欺證明(像[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)一樣)來仲裁爭議。
+Plasma 鏈是一條獨立的區塊鏈,錨定於以太坊主鏈,並使用詐欺證明(類似[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/))來仲裁爭議。
-瞭解更多關於 [Plasma](/developers/docs/scaling/plasma/) 的資訊。
+深入了解 [Plasma](/developers/docs/scaling/plasma/)。
### Validium {#validium}
Validium 鏈使用零知識證明卷軸一類的有效性證明,但不是將資料儲存在以太坊一層網路主鏈上。 每個 Validium 鏈能有每秒 10,000 筆交易的處理速度,多個 Validium 鏈能平行運作。
-瞭解更多關於 [Validium](/developers/docs/scaling/validium/) 的資訊。
+深入了解 [Validium](/developers/docs/scaling/validium/)。
## 為何我們需要那麼多擴張解決方案? {#why-do-we-need-these}
- 多個解決方案有助於減少網路任一部分的整體擁塞,並防止出現單一故障點。
- 整體大於各部分的總和。 不同解決方案能共存並協調發揮效益,對未來的交易速度和吞吐量產生指數級影響。
- 並非所有解決方案都需要直接使用以太坊共識演算法,替代機制或許能提供其他共識機制無法達成之好處。
-- 沒有一種擴張解決方案能夠完全滿足[以太坊願景](/roadmap/vision/)。
## 想透過視覺方式學習? {#visual-learner}
-_請注意,此影片中的解釋使用「二層網路」指代所有鏈外擴張解決方案,而我們將其區分為透過一層網路主網共識機制獲取安全性的鏈外解決方案。_
+_請注意,影片中的解說將 "Layer 2" 一詞用於指稱所有鏈外擴張解決方案,但我們則將 "Layer 2" 區分為透過 Layer 1 主網共識取得安全性的鏈外解決方案。_
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [以卷軸為中心的以太坊開發藍圖](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_
-- [以太坊二層網路擴展解決方案最新分析](https://www.l2beat.com/)
-- [評估以太坊二層網路擴張解決方案:比較框架](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955)
-- [卷軸之不完整指南](https://vitalik.eth.limo/general/2021/01/05/rollup.html)
-- [以太坊驅動的零知識證明卷軸:業界佼佼者](https://hackmd.io/@canti/rkUT0BD8K)
-- [樂觀卷軸與零知識證明卷軸](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/)
-- [爲什麽說卷軸 + 資料分片是提高可擴展性的唯一可持續解決方案](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48)
-- [什麽類型的三層網路才有意義?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html)
-- [資料可用性或:卷軸如何學會停止擔憂並熱愛以太坊](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups)
-
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+- [關於以太坊 Layer 2 擴張解決方案的最新分析](https://www.l2beat.com/)
+- [評估以太坊 Layer 2 擴張解決方案:一個比較框架](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955)
+- [卷軸不完全指南](https://vitalik.eth.limo/general/2021/01/05/rollup.html)
+- [由以太坊驅動的 ZK 卷軸:世界頂尖](https://hackmd.io/@canti/rkUT0BD8K)
+- [樂觀卷軸與 ZK 卷軸之比較](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/)
+- [為何卷軸 + 資料分片是實現高可擴展性的唯一可持續解決方案](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48)
+- [哪種 Layer 3 才有意義?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html)
+- [資料可得性,或:卷軸如何學會停止擔憂並愛上以太坊](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum)
+- [以太坊卷軸實用指南](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/optimistic-rollups/index.md b/public/content/translations/zh-tw/developers/docs/scaling/optimistic-rollups/index.md
index c62d6c47457..c07881caefc 100644
--- a/public/content/translations/zh-tw/developers/docs/scaling/optimistic-rollups/index.md
+++ b/public/content/translations/zh-tw/developers/docs/scaling/optimistic-rollups/index.md
@@ -4,23 +4,23 @@ description: 介紹零知識卷軸 — 一種以太坊社群使用的擴張解
lang: zh-tw
---
-樂觀卷軸是二層網路 (L2) 協定,旨在擴展以太坊基礎層的吞吐量。 它們透過在鏈外處理交易來減少以太坊主鏈上的計算,從而顯著提高處理速度。 與其他擴張解決方案(如[側鏈](/developers/docs/scaling/sidechains/))不同,樂觀卷軸從主網(透過在鏈上發佈交易結果)或 [Plasma 鏈](/developers/docs/scaling/plasma/)(該鏈還使用詐欺證明驗證以太坊主網上的交易,但將資料儲存在其他地方)獲取安全性。
+樂觀卷軸是二層網路 (L2) 協定,旨在擴展以太坊基礎層的吞吐量。 它們透過在鏈下處理交易來減少以太坊主鏈上的計算,從而顯著提高處理速度。 與其他擴容解決方案 (例如 [側鏈](/developers/docs/scaling/sidechains/)) 不同,樂觀卷軸會透過在鏈上發布交易結果來從主網取得安全性。而 [Plasma 鏈](/developers/docs/scaling/plasma/) 雖然也會用詐欺證明在以太坊上驗證交易,但會把交易資料儲存在其他地方。
-由於計算是使用以太坊時緩慢且昂貴的部分,樂觀卷軸可以提供高達 10-100 倍的可擴展性提升。 樂觀卷軸還會將交易以 `calldata` 或[二進位大型物件](/roadmap/danksharding/)的形式寫入以太坊,從而降低使用者的燃料成本。
+由於計算是使用以太坊時緩慢且昂貴的部分,樂觀卷軸可以提供高達 10-100 倍的可擴展性提升。 樂觀卷軸也會將交易以 `calldata` 或 [blobs](/roadmap/danksharding/) 的形式寫入以太坊,為使用者降低 Gas 成本。
-## 先備知識 {#prerequisites}
+## 先決條件 {#prerequisites}
-你應該已經閲讀並理解我們關於[以太坊擴張](/developers/docs/scaling/)和[二層網路](/layer-2/)的頁面。
+你應該已經閱讀並理解我們的[以太坊擴張](/developers/docs/scaling/)和[二層網路](/layer-2/)頁面。
## 什麽是樂觀卷軸? {#what-is-an-optimistic-rollup}
-樂觀卷軸是一種擴張以太坊的方法,涉及將計算和狀態存儲遷移到鏈外。 樂觀卷軸在以太坊之外執行交易,但將交易資料作爲 `calldata` 或[二進位大型物件](/roadmap/danksharding/)發佈到主網。
+樂觀卷軸是一種擴張以太坊的方法,涉及將計算和狀態存儲遷移到鏈下。 樂觀卷軸在以太坊之外執行交易,但將交易資料以 `calldata` 或 [blobs](/roadmap/danksharding/) 的形式發佈到主網。
-樂觀卷軸營運者將多個鏈外交易捆綁到一個大批次中,然後將其提交到以太坊。 此方法可將固定成本分散到每一批次的多筆交易中,從而降低最終使用者的費用。 樂觀卷軸還使用壓縮技術來減少發佈在以太坊上的資料量。
+樂觀卷軸營運者將多個鏈下交易捆綁到一個大批次中,然後將其提交到以太坊。 此方法可將固定成本分散到每一批次的多筆交易中,從而降低最終使用者的費用。 樂觀卷軸還使用壓縮技術來減少發佈在以太坊上的資料量。
-樂觀卷軸之所以被認爲是「樂觀的」,是因爲其假設鏈外交易有效,並且不會針對發佈到鏈上的交易批次發佈有效性證明。 這區分了樂觀卷軸與[零知識卷軸](/developers/docs/scaling/zk-rollups),後者會發佈鏈外交易的加密[有效性證明](/glossary/#validity-proof)。
+樂觀卷軸之所以被認爲是「樂觀的」,是因爲其假設鏈下交易有效,並且不會針對發佈到鏈上的交易批次發佈有效性證明。 這點將樂觀卷軸與 [零知識卷軸](/developers/docs/scaling/zk-rollups) 區分開來,後者會為鏈下交易發佈加密的 [有效性證明](/glossary/#validity-proof)。
-相反,樂觀卷軸依賴詐欺證明方案來偵測交易計算不正確的情況。 在以太坊上提交卷軸批次后,會有一個時間窗口(稱爲挑戰期),在此期間任何人都可以透過計算[詐欺證明](/glossary/#fraud-proof)來挑戰卷軸交易的結果。
+相反,樂觀卷軸依賴詐欺證明方案來偵測交易計算不正確的情況。 在以太坊上提交卷軸批次後,會有一個時間窗口(稱為「挑戰期」),在此期間任何人都可以透過計算 [詐欺證明](/glossary/#fraud-proof) 來挑戰卷軸交易的結果。
如果詐欺證明成功,卷軸協定就會重新執行交易並相應地更新卷軸的狀態。 詐欺證明成功的另一個影響是,負責將錯誤執行的交易納入區塊的排序者會收到懲罰。
@@ -28,27 +28,27 @@ lang: zh-tw
## 樂觀卷軸如何與以太坊互動? {#optimistic-rollups-and-Ethereum}
-樂觀卷軸是爲了在以太坊上運作而構建的[鏈外擴張解決方案](/developers/docs/scaling/#off-chain-scaling)。 每個樂觀卷軸都由部署在以太坊網路上的一組智慧型合約來管理。 樂觀卷軸在以太坊主鏈之外處理交易,但將鏈外交易(按批次)發佈到鏈上的卷軸合約。 像以太坊區塊鏈一樣,此交易記錄是不可變的,並形成「樂觀卷軸鏈」。
+樂觀卷軸是建構來在以太坊上運作的 [鏈下擴容解決方案](/developers/docs/scaling/#offchain-scaling)。 每個樂觀卷軸都由部署在以太坊網路上的一組智慧型合約來管理。 樂觀卷軸在以太坊主鏈之外處理交易,但將鏈下交易(按批次)發佈到鏈上的卷軸合約。 像以太坊區塊鏈一樣,此交易記錄是不可變的,並形成「樂觀卷軸鏈」。
樂觀卷軸的架構由以下部分組成:
-**鏈上合約**:樂觀卷軸的運作由在以太坊上執行的智慧型合約控制。 這包括用於存儲卷軸區塊、監控卷軸狀態更新以及追蹤使用者存款的合約。 從這種意義上講,以太坊充當樂觀卷軸的基礎層或「一層網路」。
+**鏈上合約**:樂觀卷軸的運作由在以太坊上執行的智慧合約控制。 這包括用於存儲卷軸區塊、監控卷軸狀態更新以及追蹤使用者存款的合約。 從這種意義上講,以太坊充當樂觀卷軸的基礎層或「一層網路」。
-**鏈外虛擬機 (VM)**:雖然管理樂觀卷軸協定的合約在以太坊上執行,但卷軸協定在[以太坊虛擬機](/developers/docs/evm/)之外的另一個虛擬機上執行計算和狀態存儲。 鏈外虛擬機是應用程式活躍和執行狀態變更的地方;它是樂觀卷軸的上層或「二層網路」。
+**鏈下虛擬機 (VM)**:雖然管理樂觀卷軸協議的合約在以太坊上執行,但卷軸協議會在與 [以太坊虛擬機](/developers/docs/evm/) 不同的另一個虛擬機上執行計算和狀態儲存。 鏈下虛擬機是應用程式活躍和執行狀態變更的地方;它是樂觀卷軸的上層或「二層網路」。
-由於樂觀卷軸旨在執行為以太坊虛擬機編寫或編譯的程式,因此鏈外虛擬機包含許多以太坊虛擬機設計規範。 此外,鏈上計算的詐欺證明讓以太坊網路可以强制執行在鏈外虛擬機中計算的狀態變更的有效性。
+由於樂觀卷軸旨在執行為以太坊虛擬機編寫或編譯的程式,因此鏈下虛擬機包含許多以太坊虛擬機設計規範。 此外,在鏈上計算的詐欺證明,能讓以太坊網路強制執行在鏈下虛擬機中計算的狀態變更的有效性。
-樂觀卷軸被描述為「混合擴張解決方案」,因爲儘管它們作爲單獨的協定存在,但其安全屬性來自以太坊。 除此之外,以太坊還能保證卷軸鏈外計算的正確性和計算後台資料的可用性。 這使得樂觀卷軸比不依賴以太坊獲取安全性的純鏈外擴張協定(如[側鏈](/developers/docs/scaling/sidechains/))更安全。
+樂觀卷軸被描述為「混合擴張解決方案」,因爲儘管它們作爲單獨的協定存在,但其安全屬性來自以太坊。 除此之外,以太坊還能保證卷軸鏈下計算的正確性和計算後台資料的可用性。 這使得樂觀卷軸比不依賴以太坊來保障安全性的純鏈下擴容協議(例如 [側鏈](/developers/docs/scaling/sidechains/))更安全。
樂觀卷軸在以下方面依賴以太坊的主要協定:
### 資料可用性 {#data-availability}
-如前所述,樂觀卷軸將交易資料以 `calldata` 或[二進位大型物件](/roadmap/danksharding/)的形式發佈到以太坊。 由於卷軸鏈的執行以提交的交易為基礎,任何人都可以使用在以太坊基礎層上錨定的此資訊,來執行卷軸的狀態並驗證狀態轉換的正確性。
+如前所述,樂觀卷軸將交易資料以 `calldata` 或 [blobs](/roadmap/danksharding/) 的形式發佈到以太坊。 由於卷軸鏈的執行以提交的交易為基礎,任何人都可以使用在以太坊基礎層上錨定的此資訊,來執行卷軸的狀態並驗證狀態轉換的正確性。
-[資料可用性](/developers/docs/data-availability/)至關重要,因爲如果不能存取狀態資料,挑戰者就無法構建詐欺證明來對無效的卷軸作業提出爭論。 透過以太坊提供資料可用性,卷軸營運者逃脫惡意行爲(如提交無效區塊)懲罰的風險就降低了。
+[資料可用性](/developers/docs/data-availability/) 至關重要,因為如果不能存取狀態資料,挑戰者就無法建構詐欺證明來對無效的卷軸操作提出異議。 透過以太坊提供資料可用性,卷軸營運者逃脫惡意行爲(如提交無效區塊)懲罰的風險就降低了。
-### 審查阻力 {#censorship-resistance}
+### 抗審查性 {#censorship-resistance}
樂觀卷軸也依賴以太坊來提供抗審查性。 在樂觀卷軸中,中心化實體(營運者)負責處理交易並將卷軸區塊提交到以太坊。 這會產生一些影響:
@@ -68,15 +68,15 @@ lang: zh-tw
以太坊在樂觀卷軸背景下扮演的另一個角色是結算層。 結算層錨定整個區塊鏈生態系統,建立安全性,並在另一條鏈(在該實例中為樂觀卷軸)上發生需要仲裁的爭議時提供客觀的最終性.
-以太坊主網為樂觀卷軸提供了一個中樞,以驗證詐欺證明並解決爭議。 此外,在卷軸上進行的交易只有當區塊在以太坊上被接受_之後_才是最終的。 一旦卷軸交易被提交到以太坊的基礎層,它就無法回滾(除非在極不可能的情況下發生鏈重組)。
+以太坊主網為樂觀卷軸提供了一個中樞,以驗證詐欺證明並解決爭議。 此外,只有在卷軸區塊被以太坊接受_之後_,在卷軸上進行的交易才是最終交易。 一旦卷軸交易被提交到以太坊的基礎層,它就無法回滾(除非在極不可能的情況下發生鏈重組)。
## 樂觀卷軸如何運作? {#how-optimistic-rollups-work}
-### 交易執行和彙總 {#transaction-execution-and-aggregation}
+### 交易執行和匯總 {#transaction-execution-and-aggregation}
使用者向「營運者」提交交易,「營運者」則是樂觀卷軸上負責處理交易的節點。 營運者也稱爲「驗證者」或「彙總者」,負責彙總交易、壓縮底層資料,並在以太坊上發佈區塊。
-儘管任何人都可以成爲驗證者,但樂觀卷軸驗證者與[權益證明系統](/developers/docs/consensus-mechanisms/pos/)很像,必須在生成區塊之前提供保證金。 如果驗證者發佈了無效的區塊或構建了原有但無效的區塊(即使他們的區塊是有效的),該保證金可能會被罰沒。 透過這種方式,樂觀卷軸利用加密經濟激勵來確保驗證者誠實行事。
+雖然任何人都可以成為驗證者,但樂觀卷軸的驗證者必須在產出區塊前提供保證金,這與 [權益證明系統](/developers/docs/consensus-mechanisms/pos/) 非常相似。 如果驗證者發佈了無效的區塊或構建了原有但無效的區塊(即使他們的區塊是有效的),該保證金可能會被罰沒。 透過這種方式,樂觀卷軸利用加密經濟激勵來確保驗證者誠實行事。
樂觀卷軸鏈上的其他驗證者預期使用他們的卷軸狀態複本來執行提交的交易。 如果驗證者的最終狀態與營運者建議的狀態不同,他們可以發起挑戰並計算詐欺證明。
@@ -84,29 +84,29 @@ lang: zh-tw
排序者與常規卷軸營運者不同,因爲他們對交易的順序有更大的控制權。 此外,排序者具有卷軸鏈的優先存取權,並且是唯一被授權向鏈上合約提交交易的實體。 來自非排序者節點或常規使用者的交易只會在一個單獨的收件匣中排隊,直到排序者將其納入一個新批次。
-#### 提交卷軸區塊到以太坊 {#submitting-blocks-to-ethereum}
+#### 向以太坊提交卷軸區塊 {#submitting-blocks-to-ethereum}
-如前所述,樂觀卷軸的營運者將鏈外交易捆綁為一個批次,並將其發送到以太坊進行公證。 該程序涉及壓縮與交易相關的資料,並將其作爲 `calldata` 或二進位大型物件發佈到以太坊上。
+如前所述,樂觀卷軸的營運者將鏈下交易捆綁為一個批次,並將其發送到以太坊進行公證。 此流程涉及壓縮與交易相關的資料,並將其以 `calldata` 或 blobs 的形式發佈到以太坊上。
-`calldata` 是智慧型合約中不可修改、非持久的區域,其行爲與[記憶體](/developers/docs/smart-contracts/anatomy/#memory)極為相似。 儘管 `calldata` 作爲區塊鏈[歷史日志](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)的一部分持續不變,但它不會儲存爲以太坊狀態的一部分。 由於 `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` 關鍵字也在 Solidity 中用於在執行時傳送參數到智慧型合約函式。 `calldata` 辨識在交易期間被調用的函式,並以任意位元組序列的形式保存函式的輸入。
+`calldata` 關鍵字也用於在 Solidity 中,於執行時將參數傳遞給智慧合約函式。 `calldata` 可識別交易期間呼叫的函式,並以任意位元組序列的形式保存函式的輸入。
-在樂觀卷軸的背景下,`calldata` 被用於將壓縮的交易資料發送到鏈上合約。 卷軸營運者透過呼叫卷軸合約中所需的函式,並將壓縮資料作爲函式引數傳送,來添加新批次。 使用 `calldata` 可以降低使用者費用,因爲卷軸產生的大部分成本來自鏈上储存資料。
+在樂觀卷軸的背景下,`calldata` 用於將壓縮的交易資料傳送到鏈上合約。 卷軸營運者透過呼叫卷軸合約中所需的函式,並將壓縮資料作爲函式引數傳送,來添加新批次。 使用 `calldata` 可以降低使用者費用,因為卷軸產生的大部分成本來自鏈上資料儲存。
-以下是卷軸批次提交的[一個示例](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591),展示了此概念如何運作。 排序者叫用 `appendSequencerBatch()` 方法並使用 `calldata` 將壓縮的交易資料作爲輸入傳送。
+此處有提交卷軸批次的[範例](https://eth.blockscout.com/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591),可說明此概念的運作方式。 排序者呼叫了 `appendSequencerBatch()` 方法,並使用 `calldata` 將壓縮的交易資料作為輸入傳遞。
一些卷軸現在使用二進位大型物件將交易批次發佈到以太坊。
-二進位大型物件是不可修改且非持久的(就像 `calldata`),并會在約 18 天后從歷史记录中刪除。 有關二進位大型物件的更多資訊,請参阅 [Danksharding](/roadmap/danksharding)。
+Blob 是不可修改且非持久性的 (就像 `calldata` 一樣),但會在約 18 天後從歷史記錄中刪除。 有關 blob 的更多資訊,請參閱 [Danksharding](/roadmap/danksharding)。
### 狀態承諾 {#state-commitments}
-在任何時間,樂觀卷軸狀態(帳戶、餘額、合約程式碼等)都被組織為[默克爾樹](/whitepaper/#merkle-trees),也稱爲「狀態樹」。 該默克爾樹的根(狀態根)引用卷軸的最新狀態,經過雜湊並儲存在卷軸合約中。 鏈上的每個狀態轉換都會產生一個新的卷軸狀態,營運者透過計算新的狀態根來提交該狀態。
+在任何時間點,樂觀卷軸的狀態 (帳戶、餘額、合約程式碼等) 會被組織成一個稱為「狀態樹」的 [默克爾樹](/whitepaper/#merkle-trees)。 該默克爾樹的根(狀態根)引用卷軸的最新狀態,經過雜湊並儲存在卷軸合約中。 鏈上的每個狀態轉換都會產生一個新的卷軸狀態,營運者透過計算新的狀態根來提交該狀態。
營運者在發佈批次時需要同時提交舊狀態根和新狀態根。 如果舊狀態根與鏈上合約中現有的狀態根相符,則現有狀態根會被丟棄並替換爲新狀態根。
-卷軸營運者還需要為交易批次本身提交默克爾根。 這讓任何人都能透過提供[默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/),證明交易已納入批次中(在一層網路上)。
+卷軸營運者還需要為交易批次本身提交默克爾根。 這讓任何人都能透過提供 [默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/),來證明交易已納入批次中 (在 L1 上)。
狀態承諾,尤其是狀態根,對於證明樂觀卷軸中的狀態變更正確性非常必要。 卷軸合約在發佈後會立即接受來自營運者的新狀態根,但之後可以刪除無效的狀態根,將卷軸復原到其正確狀態。
@@ -120,11 +120,11 @@ lang: zh-tw
然而,在一層網路重新執行交易以偵測欺詐,需要發佈單獨交易的狀態承諾,並增加必須在鏈上發佈的資料卷軸。 回放交易還會產生巨大的燃料成本。 出於這些原因,樂觀卷軸正在轉換到多輪互動式證明,以更高的效率實現相同的目標(即偵測無效卷軸作業)。
-#### 多輪互動式證明 {#multi-round-interactive-proving}
+#### 多回合互動式證明 {#multi-round-interactive-proving}
多輪互動式證明涉及斷言者與挑戰者之間的往返協定,該協定由一層網路驗證者合約監督,最終確定説謊方。 二層網路節點對斷言提出挑戰后,斷言者需要將有爭議的斷言分成相等的兩半。 在這種情況下,每個單獨的斷言都會包含與另一個斷言一樣多的計算步驟。
-然後挑戰者會選擇其想要挑戰的斷言。 劃分過程(稱爲「二等分協定」)一直持續到雙方就_單個_執行步驟的斷言發生爭議。 此時,一層網路合約會透過評估指示(及其結果)來解決爭議,以抓住欺詐方。
+然後挑戰者會選擇其想要挑戰的斷言。 這個劃分過程 (稱為「二分協議」) 會一直持續,直到雙方對於_單一_執行步驟的斷言產生爭議為止。 此時,一層網路合約會透過評估指示(及其結果)來解決爭議,以抓住欺詐方。
斷言者需要提供「一步證明」來驗證有爭議的單步計算的有效性。 如果斷言者未能提供一步證明,或者一層網路驗證者認爲證明無效,他們便會輸掉挑戰。
@@ -134,45 +134,45 @@ lang: zh-tw
2. 二等分協定減少了發佈在鏈上的資料量(無需為每筆交易發佈狀態承諾)。 此外,樂觀卷軸交易不受以太坊燃料限制的約束。 相反,樂觀卷軸重新執行交易時必須確保二層網路交易具有較低的燃料限制,以模擬其在單筆以太坊交易中的執行。
-3. 惡意斷言者的保證金一部分被獎勵給挑戰者,而另一部分則會被銷毀。 銷毀可以防止驗證者之間串通;如果兩個驗證者串通起來發起虛假挑戰,他們仍然會損失其全部質押的很大一部分。
+3. 惡意斷言者的保證金一部分被獎勵給挑戰者,而另一部分則會被銷毀。 銷毀可以防止驗證者之間進行串通; 如果兩個驗證者串通來發起虛假挑戰,他們仍然會損失其全部質押的一大部分。
4. 多輪互動式證明需要雙方(斷言者和挑戰者)在指定的時間窗口内行動。 未能在最後期限前采取行動會導致違約方喪失挑戰機會。
-#### 爲什麽詐欺證明對於樂觀卷軸很重要 {#fraud-proof-benefits}
+#### 為什麼詐欺證明對樂觀卷軸很重要 {#fraud-proof-benefits}
-詐欺證明很重要,因爲它們促進了樂觀卷軸中的_去信任最終性_。 去信任最終性是樂觀卷軸的一項品質,它保證交易只要有效,最終將會被確認。
+詐欺證明很重要,因為它們促進了樂觀卷軸中的_去信任化最終性_。 去信任最終性是樂觀卷軸的一項品質,它保證交易只要有效,最終將會被確認。
惡意節點可以嘗試透過啓動虛假挑戰來延遲對有效卷軸區塊的確認。 然而,詐欺證明最終會證明卷軸區塊的有效性並使其得到確認。
這也與樂觀卷軸的另一個安全屬性有關:鏈的有效性依賴於_一個_誠實節點的存在。 誠實節點可以透過發佈有效斷言或對無效斷言提出異議來正確地推進鏈。 無論如何,與誠實節點發生爭議的惡意節點會在詐欺證明過程中失去其質押。
-### 一層網路/二層網路的互操作性 {#l1-l2-interoperability}
+### L1/L2 互通性 {#l1-l2-interoperability}
-樂觀卷軸旨在與以太坊主網的互操作性,並允許使用者在一層網路和二層網路之間傳輸訊息和任意資料。 它們還與以太坊虛擬機兼容,因此你可以將現有的[去中心化應用程式](/developers/docs/dapps/)移植到樂觀卷軸,或使用以太坊開發工具建立新的去中心化應用程式。
+樂觀卷軸旨在與以太坊主網的互操作性,並允許使用者在一層網路和二層網路之間傳輸訊息和任意資料。 它們還與 EVM 相容,因此你可以將現有的 [去中心化應用程式](/developers/docs/dapps/) 移植到樂觀卷軸,或使用以太坊開發工具建立新的去中心化應用程式。
#### 1. 資產轉移 {#asset-movement}
##### 進入卷軸
-爲了使用樂觀卷軸,使用者需要將以太幣、ERC-20 代幣和其他被接受的資產存入一層網路上卷軸的[跨鏈橋](/developers/docs/bridges/)合約中。 跨鏈橋合約會將交易轉送到二層網路,在那裏鑄造等量的資產並發送到使用者在樂觀卷軸上選擇的地址。
+若要使用樂觀卷軸,使用者需將 ETH、ERC-20 代幣和其他可接受的資產,存入 L1 上卷軸的 [跨鏈橋](/developers/docs/bridges/) 合約中。 跨鏈橋合約會將交易轉送到二層網路,在那裏鑄造等量的資產並發送到使用者在樂觀卷軸上選擇的地址。
-使用者生成的交易(如一層網路 > 二層網路存款)通常需要排隊,直到排序者將其重新提交到卷軸合約。 然而,爲了保持抗審查性,如果交易延遲超過允許的最大時間,樂觀卷軸將允許使用者直接向鏈上卷軸合約提交交易。
+使用者產生的交易 (例如 L1 > L2 存款) 通常會排入佇列,直到排序者將它們重新提交到卷軸合約。 然而,爲了保持抗審查性,如果交易延遲超過允許的最大時間,樂觀卷軸將允許使用者直接向鏈上卷軸合約提交交易。
一些樂觀卷軸采用更簡單的方法來防止排序者審查使用者。 這時,區塊由自前一個區塊以來提交給一層網路合約的所有交易(如存款)以及卷軸鏈上已處理的交易共同定義。 如果排序者忽略一層網路交易,它將發佈(可證明)錯誤的狀態根;因此,一旦使用者產生的訊息被發佈在一層網路上,排序者就不能將其延遲。
##### 退出卷軸
-由於詐欺證明方案,從樂觀卷軸提款到以太坊更加困難。 如果使用者發起一個二層網路 > 一層網路的交易以提取在一層網路上托管的資金,他們就必須等到挑戰期(持續約 7 天)結束。 盡管如此,提款過程本身相當簡單。
+由於詐欺證明方案,從樂觀卷軸提款到以太坊更加困難。 如果使用者發起 L2 > L1 交易以提取 L1 上託管的資金,他們必須等待大約七天的挑戰期結束。 盡管如此,提款過程本身相當簡單。
在二層網路上發起提款請求後,該交易會被納入下一個批次,同時使用者在卷軸上的資產被銷毀。 一旦批次在以太坊上發佈,使用者就可以計算一個默克爾證明,來驗證其退出交易是否納入到區塊中。 然後只需要等待延遲期過後最終確定一層網路上的交易,並將資金提取到主網。
-爲了避免向以太坊提款之前等待一周的時間,樂觀卷軸使用者可以雇用一個**流動性提供者** (LP)。 流動性提供者承擔待處理的二層網路提款的所有權,並在一層網路上向使用者付款(以換取費用)。
+為避免將資金提取到以太坊前需要等待一周,樂觀卷軸使用者可以採用**流動性提供者** (LP)。 流動性提供者承擔待處理的二層網路提款的所有權,並在一層網路上向使用者付款(以換取費用)。
流動性提供者可以在釋放資金之前檢查使用者提款請求的有效性(透過自行執行鏈)。 這樣他們就可以保證交易最終會得到確認(即去信任最終性)。
-#### 2. 以太坊虛擬機 (EVM) 相容性 {#evm-compatibility}
+#### 2. EVM 相容性 {#evm-compatibility}
-對於開發者來講,樂觀卷軸的優勢在於,它們與[以太坊虛擬機 (EVM)](/developers/docs/evm/) 的相容性(或者更確切地說,等效性)。 與以太坊虛擬機相容的卷軸符合[以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)中的規範,並在位元組碼級別支援以太坊虛擬機。
+對於開發者而言,樂觀卷軸的優勢在於它們與 [以太坊虛擬機 (EVM)](/developers/docs/evm/) 的相容性,或更貼切地說,等效性。 與 EVM 相容的卷軸符合 [以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf) 中的規範,並在位元組碼層級支援 EVM。
樂觀卷軸中的以太坊虛擬機相容性具有以下好處:
@@ -182,7 +182,7 @@ ii. 使用樂觀卷軸的開發者和專案團隊可以利用以太坊的基礎
使用現有工具很重要,因爲這些工具多年來已經過廣泛的審核、除錯和改進。 它還讓以太坊開發者不需要學習如何使用全新的開發堆棧建置應用程式。
-#### 3. 跨鏈合約呼叫 {#cross-chain-contract-calls}
+#### 3 跨鏈合約呼叫 {#cross-chain-contract-calls}
使用者(外部擁有的帳戶)透過向卷軸合約提交交易或者讓排序者或驗證者為其提交交易,來與二層網路合約進行互動。 樂觀卷軸還讓以太坊上的合約帳戶可以與二層網路互動,使用跨鏈橋合約來轉送訊息,並在一層網路和二層網路之間傳遞資料。 這意味著你可以在以太坊主網上編寫一層網路合約,來叫用屬於二層網路樂觀卷軸合約的函式。
@@ -190,50 +190,50 @@ ii. 使用樂觀卷軸的開發者和專案團隊可以利用以太坊的基礎
跨鏈合約的一個範例是先前描述的代幣存款。 一層網路上的合約托管使用者的代幣,並向配對的二層網路合約發送訊息,以在卷軸中鑄造等量的代幣。
-由於跨鏈訊息呼叫會導致合約執行,因此發送者通常需要支付用於計算的[燃料成本](/developers/docs/gas/)。 建議設定較高的燃料限制,以防止交易在目標鏈上失敗。 代幣跨鏈橋場景就是一個很好的範例:如果交易的一層網路端(存入代幣)有效,但二層網路端(鑄造新代幣)由於燃料不足而失敗,則存款將無法恢復。
+由於跨鏈訊息呼叫會導致合約執行,因此傳送方通常需要支付用於計算的 [Gas 成本](/developers/docs/gas/)。 建議設定較高的燃料限制,以防止交易在目標鏈上失敗。 代幣跨鏈橋場景就是一個很好的範例:如果交易的一層網路端(存入代幣)有效,但二層網路端(鑄造新代幣)由於燃料不足而失敗,則存款將無法恢復。
-最後,我們應該注意,合約之間的二層網路 > 一層網路訊息呼叫需要考慮延遲(一層網路 > 二層網路呼叫通常在幾分鐘後執行)。 這是因爲從樂觀卷軸發送到主網的訊息在挑戰窗口到期之前無法執行。
+最後,我們應該注意,合約之間的 L2 > L1 訊息呼叫需要考慮到延遲 (L1 > L2 呼叫通常在幾分鐘後執行)。 這是因爲從樂觀卷軸發送到主網的訊息在挑戰窗口到期之前無法執行。
## 樂觀卷軸的費用如何計算? {#how-do-optimistic-rollup-fees-work}
樂觀卷軸使用與以太坊非常相似的燃料費方案來表示使用者為每筆交易支付的費用。 樂觀卷軸收取的費用取決於以下組成部分:
-1. **狀態寫入**:樂觀卷軸將交易資料和區塊頭(由前一個區塊頭的雜湊、狀態根、批次根組成)作爲 `blob`,即「二進位大型物件」,發佈到以太坊。 [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) 為鏈上納入資料引入了具成本效益的解決方案。 `blob` 是一個新交易欄位,讓卷軸可以將壓縮的狀態轉換資料發佈到以太坊一層網路。 與鏈上永久保留的 `calldata` 不同,二進位大型物件的生命周期很短,在 [4096 個時期](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147)(約 18 天)后即會被用戶端刪除。 透過使用二進位大型物件發佈壓縮的交易批次,樂觀卷軸可以顯著降低向一層網路寫入交易的成本。
+1. **狀態寫入**:樂觀卷軸將交易資料和區塊標頭 (包含前一個區塊標頭的哈希、狀態根、批次根) 發布到以太坊,作為一個 `blob` (或稱「二進位大型物件」)。 [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) 為鏈上納入資料引入了具成本效益的解決方案。 `blob` 是一個新交易欄位,讓卷軸可以將壓縮的狀態轉換資料發佈到以太坊 L1。 不同於永久保留在鏈上的 `calldata`,blob 是短期的,並可在 [4096 個 epoch](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (約 18 天) 後從用戶端中刪除。 透過使用二進位大型物件發佈壓縮的交易批次,樂觀卷軸可以顯著降低向一層網路寫入交易的成本。
-2. **二進位大型物件燃料使用**:二進位大型物件攜帶的交易采用類似於 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 中引入的動態費用機制。 3 型交易的燃料費會考慮二進位大型物件的基本費用,該費用由網路根據二進位大型物件空間需求和所發送交易的二進位大型物件空間使用來決定。
+2. **Blob Gas 已使用**:攜帶 blob 的交易採用了類似於 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 中引入的動態費用機制。 3 型交易的燃料費會考慮二進位大型物件的基本費用,該費用由網路根據二進位大型物件空間需求和所發送交易的二進位大型物件空間使用來決定。
-3. **二層網路營運者費用**:這是支付給卷軸節點的金額,用於補償處理交易時產生的計算成本,與以太坊上的燃料費非常相似。 由於二層網路處理能力更强,並且不會出現網路擁塞迫使以太坊上的驗證者優先處理費用更高的交易,卷軸節點收取的交易費更低。
+3. **L2 營運商費用**:這是支付給卷軸節點的金額,用於補償處理交易時產生的計算成本,與以太坊上的 Gas 費非常相似。 由於二層網路處理能力更强,並且不會出現網路擁塞迫使以太坊上的驗證者優先處理費用更高的交易,卷軸節點收取的交易費更低。
-樂觀卷軸套用了多種機制來降低使用者的費用,包括批次交易和壓縮 `calldata` 來降低資料發佈成本。 你可以查看[二層網路費用追蹤器](https://l2fees.info/)來即時瞭解使用基於以太坊的樂觀卷軸的成本。
+樂觀卷軸採用多種機制來降低使用者費用,包括批次處理交易和壓縮 `calldata` 來降低資料發佈成本。 你可以查看 [L2 費用追蹤器](https://l2fees.info/) 來即時了解使用基於以太坊的樂觀卷軸的成本。
## 樂觀卷軸如何擴張以太坊? {#scaling-ethereum-with-optimistic-rollups}
如前所述,樂觀卷軸在以太坊上發佈壓縮的交易資料,以保證資料可用性。 壓縮鏈上發佈的資料的能力,對於透過樂觀卷軸來擴張以太坊的吞吐量至關重要。
-以太坊主鏈限制了區塊可容納的資料量,以燃料單位計價([平均區塊大小](/developers/docs/blocks/#block-size)為 1500 萬燃料)。 雖然這限制了每筆交易可以使用的燃料數量,但也意味著我們可以透過減少與交易相關的資料來增加每個區塊處理的交易 — 直接改進了可擴展性。
+以太坊主鏈對區塊可容納的資料量設有上限,以 Gas 單位計價 ( [平均區塊大小](/developers/docs/blocks/#block-size) 為 1500 萬 Gas)。 雖然這限制了每筆交易可以使用的燃料數量,但也意味著我們可以透過減少與交易相關的資料來增加每個區塊處理的交易 — 直接改進了可擴展性。
-樂觀卷軸使用多種技術來實現交易資料壓縮並提高每秒交易數速率。 例如,這篇[文章](https://vitalik.eth.limo/general/2021/01/05/rollup.html)將基本使用者交易(發送以太幣)在主網上產生的資料量與相同交易在卷軸上產生的資料量進行了比較:
+樂觀卷軸使用多種技術來實現交易資料壓縮並提高每秒交易數速率。 例如,這篇[文章](https://vitalik.eth.limo/general/2021/01/05/rollup.html)比較了基本使用者交易 (傳送以太幣) 在主網上產生的資料量,與相同交易在卷軸上產生的資料量:
-| 參數 | 以太坊(一層網路) | 卷軸(二層網路) |
-| ------ | ----------------- | ------------ |
-| 隨機數 | ~3 | 0 |
-| 燃料價格 | ~8 | 0-0.5 |
-| 燃料 | 3 | 0-0.5 |
-| 目標 | 21 | 4 |
-| 數值 | 9 | ~3 |
-| 簽名 | ~68 (2 + 33 + 33) | ~0.5 |
-| 來源 | 0(從簽名恢復) | 4 |
-| **總計** | **~112 個位元組** | **~12 個位元組** |
+| 參數 | 以太坊(一層網路) | 卷軸(二層網路) |
+| ------ | ---------------------------------------------------- | ------------------------------------ |
+| 隨機數 | ~3 | 0 |
+| 燃料價格 | ~8 | 0-0.5 |
+| 燃料 | 3 | 0-0.5 |
+| 目標 | 21 | 4 |
+| 數值 | 9 | ~3 |
+| 簽名 | ~68 (2 + 33 + 33) | ~0.5 |
+| 來源 | 0(從簽名恢復) | 4 |
+| **總計** | **~112 個位元組** | **~12 個位元組** |
對這些數字進行一些初略計算,有助於顯示樂觀卷軸提供的可擴展性改進:
-1. 每個區塊的目標大小為 1500 萬燃料,驗證一個位元組的資料需要 16 燃料。 將平均區塊大小除以 16 燃料 (15,000,000/16),顯示了一般區塊可以容納 **937,500 個位元組的資料**。
-2. 如果一個基本卷軸交易使用 12 個位元組,則以太坊區塊平均可以處理 **78,125 筆卷軸交易** (937,5000/12) 或 **39 個卷軸批次**(如果每個批次平均包含 2,000 筆交易)。
-3. 如果每 15 秒在以太坊上產生一個新區塊,則卷軸的處理速度大約爲**每秒 5,208 筆交易**。 計算方法是,將以太坊區塊可以容納的基本卷軸交易數量 (**78,125**) 除以平均出塊時間(**15 秒**)。
+1. 每個區塊的目標大小為 1500 萬燃料,驗證一個位元組的資料需要 16 燃料。 將平均區塊大小除以 16 Gas (15,000,000/16),顯示了一般區塊可以容納 **937,500 位元組的資料**。
+2. 如果一個基本的卷軸交易使用 12 個位元組,那麼一個平均的以太坊區塊可以處理 **78,125 筆卷軸交易** (937,500/12) 或 **39 個卷軸批次** (如果每個批次平均包含 2,000 筆交易)。
+3. 如果每 15 秒在以太坊上產出一個新區塊,則卷軸的處理速度大約為**每秒 5,208 筆交易**。 計算方法是,將以太坊區塊可以容納的基本卷軸交易數量 (**78,125**) 除以平均出塊時間 (**15 秒**)。
鑒於樂觀卷軸交易不可能包含以太坊上的整個區塊,這是一個比較樂觀的預計。 但是,透過它可以大致瞭解樂觀卷軸可以為以太坊使用者提供多少可擴展性收益(當前實現可提供每秒高達 2,000 筆交易的速率)。
-在以太坊上引入[資料分片](/roadmap/danksharding/)有望增加樂觀卷軸的可擴展性。 由於卷軸交易必須與其他非卷軸交易共用區塊空間,因此其最大處理能力受制於以太坊主鏈上的資料吞吐量。 Danksharding 使用更便宜的非永久型「二進位大型物件」存儲,而不是昂貴的永久型 `CALLDATA`,這將增加二層網路鏈上用於按區塊發佈資料的空間。
+在以太坊上引入[資料分片](/roadmap/danksharding/)有望增加樂觀卷軸的可擴展性。 由於卷軸交易必須與其他非卷軸交易共用區塊空間,因此其最大處理能力受制於以太坊主鏈上的資料吞吐量。 Danksharding 將會增加 L2 鏈上可用於每個區塊發布資料的空間,它使用更便宜、非永久性的「blob」儲存,而非昂貴、永久性的 `CALLDATA`。
### 樂觀卷軸的優點和缺點 {#optimistic-rollups-pros-and-cons}
@@ -247,7 +247,7 @@ ii. 使用樂觀卷軸的開發者和專案團隊可以利用以太坊的基礎
| 樂觀卷軸依賴於精心設計的加密激勵機制來提升鏈上安全性。 | 卷軸必須在鏈上發佈所有交易資料,這可能會增加成本。 |
| 與以太坊虛擬機和 Solidity 的相容性,讓開發者可以將以太坊原生智慧型合約移植到卷軸或使用現有工具來建立新的去中心化應用程式。 | |
-### 樂觀卷軸之視覺範例 {#optimistic-video}
+### 樂觀卷軸視覺化解釋 {#optimistic-video}
想透過視覺方式學習? 觀看 Finematics 解釋樂觀卷軸:
@@ -255,9 +255,11 @@ ii. 使用樂觀卷軸的開發者和專案團隊可以利用以太坊的基礎
## 有關樂觀卷軸的延伸閲讀
-- [樂觀卷軸如何運作(完整指引)](https://www.alchemy.com/overviews/optimistic-rollups)
-- [什麽是區塊鏈卷軸? (技術介紹)](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction)
-- [Arbitrum 之概要指引](https://www.bankless.com/the-essential-guide-to-arbitrum)
-- [樂觀卷軸究竟如何運作?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work)
-- [樂觀虛擬機深入探索](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52)
-- [什麽是樂觀虛擬機?](https://www.alchemy.com/overviews/optimistic-virtual-machine)
+- [樂觀卷軸如何運作 (完整指南)](https://www.alchemy.com/overviews/optimistic-rollups)
+- [什麼是區塊鏈卷軸? 技術簡介](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction)
+- [Arbitrum 基礎指南](https://www.bankless.com/the-essential-guide-to-arbitrum)
+- [以太坊卷軸實用指南](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups)
+- [以太坊 L2s 中詐欺證明的現況](https://web.archive.org/web/20241124154627/https://research.2077.xyz/the-state-of-fraud-proofs-in-ethereum-l2s)
+- [Optimism 的 Rollup 是如何運作的?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work)
+- [OVM 深入探討](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52)
+- [什麼是樂觀虛擬機?](https://www.alchemy.com/overviews/optimistic-virtual-machine)
diff --git a/public/content/translations/zh-tw/developers/docs/scaling/plasma/index.md b/public/content/translations/zh-tw/developers/docs/scaling/plasma/index.md
index 1f74e0ceff7..9e80f09b895 100644
--- a/public/content/translations/zh-tw/developers/docs/scaling/plasma/index.md
+++ b/public/content/translations/zh-tw/developers/docs/scaling/plasma/index.md
@@ -6,55 +6,55 @@ incomplete: true
sidebarDepth: 3
---
-Plasma 鏈是錨定以太坊主網的獨立區塊鏈,其交易在鏈外執行並有自己的區塊驗證機制。 Plasma 鏈有時被稱為「子」鏈,本質上是以太坊主網的縮小複製版, 使用[詐欺證明](/glossary/#fraud-proof)(如[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/))來仲裁爭議。
+Plasma 鏈是錨定以太坊主網的獨立區塊鏈,其交易在鏈下執行並有自己的區塊驗證機制。 Plasma 鏈有時被稱為「子」鏈,本質上是以太坊主網的縮小複製版, Plasma 鏈使用[詐欺證明](/glossary/#fraud-proof)(類似[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/))來仲裁爭議。
使用默克爾樹可以建立這些鏈的無限堆疊,將父母鏈(包括以太坊主網)的頻寬載荷轉移到 Plasma 鏈。 然而,雖然這些鏈會繼承以太坊的一些安全性(透過詐欺證明),但它們的安全性和效率受多項設計限制的影響。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-推薦你先熟悉以太坊的所有基本概念,並大致了解[以太坊擴張](/developers/docs/scaling/)。
+您應該對所有基礎主題有良好的理解,並對[以太坊擴張](/developers/docs/scaling/)有高層次的了解。
## 何謂 Plasma 鏈?
-Plasma 是一個改善公共區塊鏈(如以太坊)可擴展性的框架。 如原始版 [Plasma 白皮書](http://plasma.io/plasma.pdf)中所述,Plasma 鏈建置在另一個區塊鏈(稱為「根鏈」)之上。 每個「子鏈」都是從根鏈延伸而來,通常由部署於父母鏈上的智慧型合約來管理。
+Plasma 是一個改善公共區塊鏈(如以太坊)可擴展性的框架。 如原始版 Plasma 白皮書中所述,Plasma 鏈建置在另一個區塊鏈(稱為「根鏈」)之上。 每個「子鏈」都是從根鏈延伸而來,通常由部署於父母鏈上的智慧型合約來管理。
-Plasma 合約的功能之一是作為[跨鏈橋](/developers/docs/bridges/),讓使用者可以在以太坊主網和 Plasma 鏈之間移動資產。 雖然這讓 Plasma 鏈看似很像[側鏈](/developers/docs/scaling/sidechains/),但不同的是,Plasma 鏈至少某種程度上受益於以太坊主網的安全性, 而側鏈則是完全為自身的安全性負責,與以太坊主網無關。
+Plasma 合約的功能之一是作為[跨鏈橋](/developers/docs/bridges/),讓使用者可以在以太坊主網和 plasma 鏈之間移動資產。 雖然這讓它們類似於[側鏈](/developers/docs/scaling/sidechains/),但 plasma 鏈至少在某種程度上受益於以太坊主網的安全性。 而側鏈則是完全為自身的安全性負責,與以太坊主網無關。
## Plasma 鏈如何運作?
Plasma 鏈的基本組成部分有:
-### 鏈外計算 {#off-chain-computation}
+### 鏈外運算 {#offchain-computation}
-以太坊目前的處理速度限制約是每秒 15 到 20 筆交易,短期內無法有效地擴張以面對更多使用者。 存在這個問題的原因是,以太坊的[共識機制](/developers/docs/consensus-mechanisms/)需要大量點對點節點來驗證區塊鏈狀態的每次更新。
+以太坊目前的處理速度限制約是每秒 15 到 20 筆交易,短期內無法有效地擴張以面對更多使用者。 存在這個問題的主要原因是,以太坊的[共識機制](/developers/docs/consensus-mechanisms/)需要許多點對點節點來驗證區塊鏈狀態的每次更新。
雖然以太坊的共識機制對於安全性是必需的,但這並不適用於所有使用案例。 例如,Alice 不需要讓整個以太坊網路來驗證她每天付給 Bob 的咖啡錢,畢竟她跟 Bob 雙方之間已經有一定的信任關係了。
Plasma 鏈假設以太坊主網不需要驗證所有交易。 相反,我們可以在主網外處理交易,讓節點不必驗證每一筆交易。
-由於 Plasma 鏈可以最佳化速度和成本,鏈外運算是有必要的。 舉例來說,Plasma 鏈可能(實際上經常如此)使用單一的「營運者」來管理交易的排序與執行。 既然只有一個實體驗證交易,在 Plasma 鏈上處理交易的速度就比以太坊主網快得多。
+由於 Plasma 鏈可以最佳化速度和成本,鏈下運算是有必要的。 舉例來說,Plasma 鏈可能(實際上經常如此)使用單一的「營運者」來管理交易的排序與執行。 既然只有一個實體驗證交易,在 Plasma 鏈上處理交易的速度就比以太坊主網快得多。
### 狀態承諾 {#state-commitments}
-儘管 Plasma 鏈在鏈外執行交易,這些交易仍會在以太坊主網的執行層結算,否則 Plasma 鏈也無法受益於以太坊的安全保障。 但如果在最終確定鏈外交易時未能獲知 Plasma 鏈的狀態,那將打破前述安全性模型,並可能導致無效交易氾濫。 這就是為何在 Plasma 鏈上負責產生區塊的營運者,需要定期在以太坊主網上發布「狀態承諾」。
+儘管 Plasma 鏈在鏈下執行交易,這些交易仍會在以太坊主網的執行層結算,否則 Plasma 鏈也無法受益於以太坊的安全保障。 但如果在最終確定鏈下交易時未能獲知 Plasma 鏈的狀態,那將打破前述安全性模型,並可能導致無效交易氾濫。 這就是為何在 Plasma 鏈上負責產生區塊的營運者,需要定期在以太坊主網上發布「狀態承諾」。
-[承諾方案](https://en.wikipedia.org/wiki/Commitment_scheme)是一種密碼學技術,用以在不洩漏給另一方的情況下承諾某個價值或是主張。 承諾就其意義而言是一種約束,一旦做出承諾就無法變更承諾的價值或主張。 Plasma 鏈上的狀態承諾會採用「默克爾根」(源自[默克爾樹](/whitepaper/#merkle-trees))的形式,營運者會定期把狀態承諾傳送到以太坊鏈上的 Plasma 合約。
+承諾方案是一種密碼學技術,用以在不洩漏給另一方的情況下承諾某個價值或是主張。 承諾就其意義而言是一種約束,一旦做出承諾就無法變更承諾的價值或主張。 Plasma 中的狀態承諾採用「Merkle 根」的形式(源自 [Merkle 樹](/whitepaper/#merkle-trees)),營運者會定期將其傳送到以太坊鏈上的 Plasma 合約。
-默克爾根為密碼學基元,讓我們得以將大量資訊進行壓縮。 默克爾根(在這一情境下也稱「區塊根」)可以代表區塊內的所有交易。 默克爾根還讓我們可以很容易地驗證,一小份資料是否存在於較大資料集中。 舉例來說,使用者可以透過產生一個[默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content),來證明一筆交易有被納入特定區塊中。
+默克爾根為密碼學基元,讓我們得以將大量資訊進行壓縮。 默克爾根(在這一情境下也稱「區塊根」)可以代表區塊內的所有交易。 默克爾根還讓我們可以很容易地驗證,一小份資料是否存在於較大資料集中。 例如,使用者可以產生[默克爾證明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content),以證明特定區塊中包含某筆交易。
-默克爾根非常重要,用於把鏈外狀態的相關資訊提供給以太坊。 我們可以把默克爾根想像成「暫存點」:營運者表示,「這是 Plasma 鏈在時間點 x 的狀態,以此默克爾根為證」。 營運者承諾 Plasma 鏈的_目前狀態_,並附上一個默克爾根,也就是所謂的「狀態承諾」。
+默克爾根非常重要,用於把鏈下狀態的相關資訊提供給以太坊。 我們可以把默克爾根想像成「暫存點」:營運者表示,「這是 Plasma 鏈在時間點 x 的狀態,以此默克爾根為證」。 營運者正使用一個 Merkle 根來承諾 plasma 鏈的_目前狀態_,這就是為什麼它被稱為「狀態承諾」。
-### 進入與退出 {#entries-and-exits}
+### 進出 {#entries-and-exits}
以太坊的使用者如果想要享受到 Plasma 的好處,會需要一個機制來在以太坊主網與 Plasma 鏈之間轉移資金。 我們不能把以太幣隨意地傳送到 Plasma 鏈上的地址,不過由於兩個鏈並不相容,所以交易結果不是失敗就是資金消失。
Plasma 鏈使用一個在以太坊上執行的主合約來處理使用者的進入和退出。 這個主合約也負責追蹤狀態承諾(上文提到的),並依據詐欺證明來懲罰不誠實的行為(我們等等會詳談)。
-#### 進入 Plasma 鏈 {#entering-the-plasma-chain}
+#### 進入 plasma 鏈 {#entering-the-plasma-chain}
若要進入 Plasma 鏈,Alice(使用者)會需要存入以太幣或是任意 ERC-20 代幣到 Plasma 合約。 Plasma 上負責監視合約存款的營運者,會建立一筆與 Alice 的首筆存款等額的資產並發放到她在 Plasma 鏈上的地址。 Alice 需要在子鏈上證明有收到這筆資金,接著就可以使用這些資金進行交易。
-#### 退出 Plasma 鏈 {#exiting-the-plasma-chain}
+#### 退出 plasma 鏈 {#exiting-the-plasma-chain}
退出 Plasma 鏈則因為各種原因,比進入時複雜了許多。 最大的原因是,雖然以太坊有關於 Plasma 鏈狀態的資訊,但以太坊並無法驗證那些資訊是否真實。 惡意使用者可以不實地宣稱(如「我有 1000 枚以太幣」),透過提供虛假證明來支持其謊言並逍遙法外。
@@ -62,9 +62,9 @@ Plasma 鏈使用一個在以太坊上執行的主合約來處理使用者的進
不過,使用者通常都是誠實的,對其擁有資金的宣稱也是正確的。 延續 Alice 的情境,她會透過向 Plasma 合約提交一筆交易,在根鏈(以太坊)上發起提款請求。
-她還必須提供一個默克爾證明,驗證 Plamsa 鏈上有一筆建立 Alice 資金的交易已被納入到區塊中。 這對於 Plasma 的迭代實作來說很有必要,如 [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html),它採用的是[未花費交易輸出 (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output) 模型。
+她還必須提供一個默克爾證明,驗證 Plamsa 鏈上有一筆建立 Alice 資金的交易已被納入到區塊中。 這對於 Plasma 的迭代是必要的,例如 [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html),它使用[未使用交易輸出 (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output) 模型。
-其他的實作方案如 [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html),將資金視作[非同質化代幣](/developers/docs/standards/tokens/erc-721/),而非未花費交易輸出模型。 在這一實作方案中,提款時需要附上 Plasma 鏈上代幣的擁有權證明。 這可以透過提交兩筆包含代幣的最新交易,及一份默克爾證明,驗證這兩筆交易有被打包進區塊。
+其他像是 [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html) 的方案,將資金表示為[非同質化代幣](/developers/docs/standards/tokens/erc-721/),而不是 UTXO。 在這一實作方案中,提款時需要附上 Plasma 鏈上代幣的擁有權證明。 這可以透過提交兩筆包含代幣的最新交易,及一份默克爾證明,驗證這兩筆交易有被打包進區塊。
使用者也需要在提款請求中加入保證金,來擔保其行為誠實。 如果有挑戰者證明 Alice 的提款請求是無效的,她的保證金會被罰沒,其中一部分保證金會給挑戰者作為獎勵。
@@ -72,7 +72,7 @@ Plasma 鏈使用一個在以太坊上執行的主合約來處理使用者的進
### 爭議仲裁 {#dispute-arbitration}
-與任何區塊鏈一樣,Plasma 鏈需要一種機制來確保交易的完整性,防範參與者的惡意行爲(例如,雙重消費資金)。 爲此,Plasma 鏈使用詐欺證明來對有關狀態轉換有效性的爭議進行仲裁並懲罰不良行爲。 詐欺證明可作爲一種機制,Plasma 子鏈可以透過它向父母鏈或根鏈提出投訴。
+與任何區塊鏈一樣,Plasma 鏈需要一種機制來強制執行交易的完整性,以防參與者惡意行事(例如,雙花資金)。 爲此,Plasma 鏈使用詐欺證明來對有關狀態轉換有效性的爭議進行仲裁並懲罰不良行爲。 詐欺證明可作爲一種機制,Plasma 子鏈可以透過它向父母鏈或根鏈提出投訴。
詐欺證明只是聲明特定的狀態轉換無效。 例如,如果使用者 Alice 嘗試兩次消費同一資金。 也許她在與 Bob 的交易中消費了未花費交易輸出 (UTXO),並希望在另一筆交易中消費相同的未花費交易輸出(但現在是 Bob 的了)。
@@ -80,17 +80,17 @@ Plasma 鏈使用一個在以太坊上執行的主合約來處理使用者的進
如果 Bob 挑戰成功,Alice 的提款請求將被取消。 然而,這種方法依賴於 Bob 有能力監視鏈上的提款請求。 如果 Bob 離綫,一旦挑戰期結束,Alice 就可以處理這筆惡意提款。
-## Plasma 鏈中的大規模退出問題 {#the-mass-exit-problem-in-plasma}
+## Plasma 中的大規模退出問題 {#the-mass-exit-problem-in-plasma}
-當大量使用者試圖同時從 Plasma 鏈提款時,就會出現大規模退出問題。 出現該問題的原因與 Plasma 的最大問題之一有關:**資料不可用性**。
+當大量使用者試圖同時從 Plasma 鏈提款時,就會出現大規模退出問題。 這個問題之所以存在,與 Plasma 最大的問題之一有關:**資料不可用性**。
資料可用性是驗證所提議區塊的資訊是否已實際發佈在區塊鏈網路上的能力。 如果生產者自己發佈區塊但保留用於建立區塊的資料,則該區塊是「不可用的」。
如果節點要能夠下載區塊並驗證交易的有效性,區塊必須是可用的。 區塊鏈透過迫使區塊生產者在鏈上發佈所有交易資料來確保資料可用性。
-資料可用性還有助於保護建構於以太坊基礎層之上的鏈外擴張協議。 透過迫使這些鏈上營運者在以太坊上發佈交易資料,任何人都可以藉由構建引用正確鏈狀態的詐欺證明,來挑戰無效區塊。
+資料可用性還有助於保護建構於以太坊基礎層之上的鏈下擴張協議。 透過迫使這些鏈上營運者在以太坊上發佈交易資料,任何人都可以藉由構建引用正確鏈狀態的詐欺證明,來挑戰無效區塊。
-Plasma 鏈主要儲存與營運者的交易資料,並且**不在主網上發佈任何資料**(即除了定期狀態承諾之外)。 這意味著如果使用者需要建立詐欺證明來挑戰無效交易,他們就必須仰賴營運者提供交易資料。 如果該系統正常運作,則使用者始終可以使用詐欺證明來保護資金。
+Plasma 鏈主要將交易資料儲存在營運者處,且**不會在主網上發布任何資料**(即,除了定期的狀態承諾之外)。 這意味著如果使用者需要建立詐欺證明來挑戰無效交易,他們就必須仰賴營運者提供交易資料。 如果該系統正常運作,則使用者始終可以使用詐欺證明來保護資金。
當進行惡意行爲的是營運者而不僅僅是使用者時,問題就開始了。 由於營運者完全控制區塊鏈,他們更有動力更大規模地推進無效狀態轉換,例如竊取 Plasma 鏈上屬於使用者的資金。
@@ -98,37 +98,37 @@ Plasma 鏈主要儲存與營運者的交易資料,並且**不在主網上發
因此,最樂觀的解決方案是嘗試從 Plasma 鏈上「大規模退出」使用者。 大規模退出減慢了惡意營運者竊取資金的計劃,並為使用者提供了一定程度的保護。 提款請求根據每個未花費交易輸出 (UTXO)(或代幣)的建立時間排序,以防止惡意營運者搶先交易誠實的使用者。
-盡管如此,我們仍然需要一種方法來驗證大規模退出期間提款請求的有效性,以防止機會主義個人在處理無效退出的混亂中獲利。 解決方案很簡單:要求使用者發佈最後一個**有效的鏈狀態**來退出其資金。
+盡管如此,我們仍然需要一種方法來驗證大規模退出期間提款請求的有效性,以防止機會主義個人在處理無效退出的混亂中獲利。 解決方案很簡單:要求使用者發布最後一個**有效的鏈狀態**以退出其資金。
但這種方法仍然存在問題。 例如,如果 Plasma 鏈上的所有使用者都需要退出(在惡意營運者的情況下是可能的),Plasma 鏈的整個有效狀態就必須立即轉儲到以太坊的基礎層。 由於 Plasma 鏈可能為任意大小(高吞吐量 = 更多資料)和以太坊處理速度的限制,這不是一個理想的解決方案。
儘管退出游戲在理論上聽起來不錯,但現實中的大規模退出可能會引發以太坊本身的全網路擁塞。 除了損害以太坊的功能之外,協調不善的大規模退出意味著使用者可能無法在營運者耗盡 Plasma 鏈上的每個帳戶之前提取資金。
-## Plasma 的優勢和劣勢 {#pros-and-cons-of-plasma}
+## Plasma 的優缺點 {#pros-and-cons-of-plasma}
-| 優勢 | 劣勢 |
-| ----------------------------------------------------------------------------- | --------------------------------------------------- |
-| 提供高吞吐量和低單位交易成本。 | 不支援一般運算(無法執行智慧型合約)。 僅透過特定運用邏輯支援基本的代幣轉移、交換及其他幾種交易類型。 |
-| 適合任意使用者之間的交易(若雙方使用者都處於 Plasma 鏈上,則不會產生任何開銷) | 需要本人定期監看網路(活躍性要求)或委託他人監看,以保障資金安全。 |
-| Plasma 鏈可以適應與主鏈無關的特定使用案例。 包括企業在内的任何人,都可以自訂 Plasma 智慧型合約,以提供可在不同情境下運作的可擴展基礎設施。 | 仰賴一或多個營運者來儲存資料並根據要求提供此資料。 |
-| 透過將計算和存儲遷移到鏈外來減少以太坊主網的載荷。 | 提款可被延遲數日以容許挑戰。 對於同質化資產,流動性提供者可以緩解這種情況,但存在相關的資本成本。 |
-| | 如果太多使用者同時嘗試退出,以太坊主網可能會擁塞。 |
+| 優勢 | 劣勢 |
+| ----------------------------------------------------------------------------- | -------------------------------------------------- |
+| 提供高吞吐量和低單位交易成本。 | 不支援一般運算(無法執行智能合約)。 僅透過特定運用邏輯支援基本的代幣轉移、交換及其他幾種交易類型。 |
+| 適合任意使用者之間的交易(若雙方使用者都處於 Plasma 鏈上,則不會產生任何開銷) | 需要本人定期監看網路(活躍性要求)或委託他人監看,以保障資金安全。 |
+| Plasma 鏈可以適應與主鏈無關的特定使用案例。 包括企業在内的任何人,都可以自訂 Plasma 智慧型合約,以提供可在不同情境下運作的可擴展基礎設施。 | 仰賴一或多個營運者來儲存資料並根據要求提供此資料。 |
+| 透過將計算和存儲遷移到鏈下來減少以太坊主網的載荷。 | 提款可被延遲數日以容許挑戰。 對於同質化資產,流動性提供者可以緩解這種情況,但存在相關的資本成本。 |
+| | 如果太多使用者同時嘗試退出,以太坊主網可能會擁塞。 |
-## Plasma 與二層網路擴張協定 {#plasma-vs-layer-2}
+## Plasma 與 Layer 2 擴張協定 {#plasma-vs-layer-2}
-雖然 Plasma 曾被視爲對以太坊有用的擴張解決方案,但後來被棄用,由[二層網路 (L2) 擴張協定](/layer-2/)所取代。 二層網路擴張解決方案解決了 Plasma 的幾個問題:
+雖然 Plasma 曾被視為對以太坊有用的擴張解決方案,但後來已被棄用,轉而採用 [Layer 2 (L2) 擴張協定](/layer-2/)。 二層網路擴張解決方案解決了 Plasma 的幾個問題:
### 效率 {#efficiency}
-[零知識卷軸](/developers/docs/scaling/zk-rollups)為在鏈外處理的每批交易的有效性產生加密證明。 這可防止使用者(和營運者)推進無效的狀態轉換,因而不再需要挑戰期和退出游戲。 這也意味著使用者不必透過定期監視鏈來保護其資金安全。
+[零知識卷軸](/developers/docs/scaling/zk-rollups) 會為鏈外處理的每批交易的有效性產生加密證明。 這可防止使用者(和營運者)推進無效的狀態轉換,因而不再需要挑戰期和退出游戲。 這也意味著使用者不必透過定期監視鏈來保護其資金安全。
-### 支援智慧型合約 {#support-for-smart-contracts}
+### 支援智能合約 {#support-for-smart-contracts}
-Plasma 框架的另一個問題是[無法支援以太坊智慧型合約的執行](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4)。 因此,Plasma 的大多數實作主要是用於簡單的支付或 ERC-20 代幣交換。
+Plasma 框架的另一個問題是[無法支援執行以太坊智能合約](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4)。 因此,Plasma 的大多數實作主要是用於簡單的支付或 ERC-20 代幣交換。
-相反,樂觀卷軸與[以太坊虛擬機](/developers/docs/evm/)相容,並且可以執行以太坊原生[智慧型合約](/developers/docs/smart-contracts/),使其成爲擴張[去中心化應用程式](/developers/docs/dapps/)的實用且_安全_的解決方案。 類似地,[建立以太坊虛擬機的零知識實作 (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549) 正在計劃中,使零知識卷軸能夠處理任意邏輯並執行智慧型合約。
+相反地,樂觀卷軸與[以太坊虛擬機](/developers/docs/evm/)相容,可以執行以太坊原生的[智能合約](/developers/docs/smart-contracts/),使其成為擴張[去中心化應用程式](/developers/docs/dapps/)的實用且_安全_的解決方案。 同樣地,目前正在計劃[建立 EVM 的零知識實作 (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549),這將允許 ZK 卷軸處理任意邏輯並執行智能合約。
-### 資料不可用 {#data-unavailability}
+### 資料不可用性 {#data-unavailability}
如前所述,Plasma 存在資料可用性問題。 如果惡意營運者在 Plasma 鏈上推進了無效轉換,使用者將無法挑戰它,因爲營運者可以扣留建立詐欺證明所需的資料。 卷軸迫使營運者在以太坊上發佈交易資料,允許任何人驗證鏈的狀態並在必要時建立詐欺證明,從而解決了該問題。
@@ -142,13 +142,14 @@ Plasma 框架的另一個問題是[無法支援以太坊智慧型合約的執行
Plasma、側鏈和分片技術有一定的相似,因爲它們都以某種方式連線到以太坊主網。 然而,連線到以太坊主網的級別和强度有所不同,影響這些擴張解決方案的安全屬性。
-### Plasma 與側鏈 {#plasma-vs-sidechains}
+### Plasma vs 側鏈 {#plasma-vs-sidechains}
-[側鏈](/developers/docs/scaling/sidechains/)是一種獨立運行的區塊鏈,透過雙向跨鏈橋連線到以太坊主網。 [跨鏈橋](/bridges/)讓使用者可以在兩條區塊鏈之間交換代幣,以便在側鏈進行交易,降低了以太坊主網上的擁塞並增加了可擴展性。 側鏈使用獨立的共識機制,並且它們通常比以太坊主網小得多。 因此,將資產橋接到這些區塊鏈會增加風險;由於側鏈模型中缺少從以太坊主網繼承的安全保證,在側鏈受到攻擊時,使用者會承擔資金損失的風險。
+[側鏈](/developers/docs/scaling/sidechains/)是一種獨立運行的區塊鏈,透過雙向跨鏈橋連接到以太坊主網。 [跨鏈橋](/bridges/)讓使用者可以在兩條區塊鏈之間交換代幣,以便在側鏈上進行交易,從而減少以太坊主網的擁塞並提高可擴展性。
+側鏈使用獨立的共識機制,並且它們通常比以太坊主網小得多。 因此,將資產橋接到這些區塊鏈會增加風險;由於側鏈模型中缺少從以太坊主網繼承的安全保證,在側鏈受到攻擊時,使用者會承擔資金損失的風險。
相反,Plasma 鏈的安全性來自主網。 這使其明顯比側鏈更安全。 側鏈和 Plasma 鏈都可以使用不同的共識協定。但區別是,Plasma 鏈在以太坊主網上發佈每個區塊的默克爾根。 區塊根是小段的資訊,可用於驗證在 Plasma 鏈上進行的相關交易的資訊。 如果 Plasma 鏈受到攻擊,使用者可以使用適當的證明來安全地將資金提取回主網。
-### Plasma 與分片 {#plasma-vs-sharding}
+### Plasma vs 分片 {#plasma-vs-sharding}
Plasma 鏈和分片鏈都會定期向以太坊主網發佈加密證明。 然而,它們的安全屬性有所不同。
@@ -156,20 +157,20 @@ Plasma 鏈和分片鏈都會定期向以太坊主網發佈加密證明。 然而
Plasma 有所不同,因爲主網只接收最少量的子鏈狀態資訊。 這意味著主網無法有效驗證子鏈上進行的交易,降低了交易的安全性。
-**請注意**,以太坊區塊鏈分片已經不再包含在開發藍圖中。 它已經被卷軸和 [Danksharding](/roadmap/danksharding) 擴張所取代。
+**注意**:以太坊區塊鏈分片已不在開發藍圖中。 它已被透過卷軸和 [Danksharding](/roadmap/danksharding) 進行的擴張所取代。
### 使用 Plasma {#use-plasma}
有多項專案提供 Plasma 實作,歡迎整合到你的去中心化應用程式:
-- [Polygon](https://polygon.technology/)(前身為 Matic 網路)
+- [Polygon](https://polygon.technology/)(前身為 Matic Network)
## 延伸閱讀 {#further-reading}
-- [瞭解 Plasma](https://www.learnplasma.org/en/)
-- [「共用安全性」的含義及其重要性概覽](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/)
-- [側鏈、Plasma 與分片](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html)
-- [瞭解 Plasma,第一部分:基礎知識](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics)
+- [學習 Plasma](https://www.learnplasma.org/en/)
+- [快速提醒您「共享安全性」的含義及其重要性](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/)
+- [側鏈 vs Plasma vs 分片](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html)
+- [了解 Plasma,第 1 部分:基礎知識](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics)
- [Plasma 的生與死](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#)
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
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..f59c207f9c5 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
@@ -5,9 +5,9 @@ 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..1b79af2a670
--- /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..1cc8c4884c9 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
@@ -5,41 +5,41 @@ 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..9b69ea7d050 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
@@ -4,39 +4,39 @@ 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..d55ff354df0 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
@@ -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..950b302a5fd 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
@@ -7,20 +7,20 @@ 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..9a492947e47 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:
+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..7410070f9bd 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:
+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..3241a9d953d 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
@@ -4,9 +4,9 @@ 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..70961caf3fb 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
@@ -4,21 +4,21 @@ 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..c07bf979b03 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: 智慧型合約語言
+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,108 @@ 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 +211,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 +228,8 @@ def endAuction():
### 合約範例 {#example-contract-2}
-以下簡單範例採用冪函數。 它可以使用 `solc --strict-assembly --bin input.yul` 編譯。 這個範例應該 儲存在 input.yul 檔案中。
+以下簡單範例採用冪函數。 可以使用 `solc --strict-assembly --bin input.yul` 進行編譯。 這個範例應該
+儲存在 input.yul 檔案中。
```
{
@@ -248,7 +250,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 +259,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 +298,7 @@ contract GuestBook:
### Solidity 的優點是什麼? {#solidity-advantages}
-- 如果你是初學者,有不少使用教學和學習工具。 在[透過編碼學習](/developers/learning-tools/)部分瞭解更多相關資訊。
+- 如果你是初學者,有不少使用教學和學習工具。 更多相關資訊,請參閱[透過編碼學習](/developers/learning-tools/)一節。
- 提供優良的開發者工具。
- Solidity 擁有龐大的開發者社群,這表示你很可能會很快找到問題的答案。
@@ -313,9 +315,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..a39b032c44e 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:
+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..f857591950a
--- /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..6a5c3b6e348 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
@@ -6,19 +6,19 @@ 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..158f7ccfbc1 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
@@ -4,37 +4,37 @@ 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}
+### 自動化測試{#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}
+### 手動測試{#manual-testing}
手動測試需要真人的輔助,需要逐一執行測試套件中的每一個測試用例,來分析智慧型合約的正確性。 這和自動化測試不同,沒辦法同時在一個合約上執行多個獨立的測試,並得到一份顯示所有成功與失敗測試的報告。
@@ -42,21 +42,21 @@ lang: zh-tw
有效的手動測試需要大量的資源(技術、時間、金錢與人力),而且有可能在執行測試時因為人為錯誤而遺漏一些錯誤。 但手動測試仍然是有益的,舉例來說,一個真人測試者(如審計員)或許可以用直覺來找出一些可能被自動化測試工具遺漏的邊緣案例。
-## 智慧型合約的自動化測試 {#automated-testing-for-smart-contracts}
+## 智能合約的自動化測試{#automated-testing-for-smart-contracts}
-### 單元測試 {#unit-testing-for-smart-contracts}
+### 單元測試{#unit-testing-for-smart-contracts}
單元測試分別評估各個合約函式並確認每個元件都能正常運作。 好的單元測試應該要簡單並且快速地運作,並在有測試失敗時讓人清楚地知道問題發生在哪。
單元測試在確認函式回傳預計的值以及函式執行後正確更新合約存儲方面很有用。 此外,在更改合約的程式碼庫之後運行單元測試,可以確保新增的新邏輯並沒有造成新錯誤。 以下是一些如何運行有效單元測試的指南:
-#### 智慧型合約單元測試指南 {#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}
+### 整合測試{#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}
+#### 靜態分析{#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}
+#### 動態分析{#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}
+### 在測試網上測試合約{#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}
+## 測試與形式化驗證{#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}
-### 單元測試工具 {#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 Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _用於測試 Solidity 智能合約的工具。 在 Remix IDE「Solidity 單元測試」外掛程式下運作,用於編寫和執行合約的測試案例。_
-- **[Remix 測試](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,這是一個快速而靈活的以太坊測試框架,能夠執行簡單的單元測試、gas 優化檢查和合約模糊測試。_
-- **[Foundry 測試](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry 提供了 Forge,一個快速且靈活的以太坊測試框架,能夠執行簡單的單元測試、燃料優化檢查,以及合約模糊測試。_
+- **[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}
-#### 靜態分析工具 {#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}
+#### 動態分析工具{#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..9966c515344 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
@@ -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}
+## 資源{#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..0c57a3d2f45 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
@@ -4,13 +4,13 @@ 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) 附加到交易的資料酬載中。 編譯是確定性的,也就是說,只要使用相同的原始碼檔案及編譯設定(如編譯器版本、最佳化工具),每次都能產生相同的輸出(即合約位元組碼)。
-
+
驗證智慧型合約主要包含以下步驟:
@@ -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..97a0de65d0d
--- /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..fb15ba20c96
--- /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..8112f171b35
--- /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..2bc97a24bf5
--- /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..ae16e0f2ac6
--- /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..967765994c1
--- /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}
+
+
+
+### 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)
diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-721/index.md
new file mode 100644
index 00000000000..66230283192
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-721/index.md
@@ -0,0 +1,255 @@
+---
+title: ERC-721 非同質化代幣標準
+description: 了解 ERC-721,這是以太坊上代表獨特數位資產的非同質化代幣 (NFT) 標準。
+lang: zh-tw
+---
+
+## 介紹 {#introduction}
+
+**什麼是非同質化代幣?**
+
+非同質化代幣 (NFT) 用於以獨一無二的方式來識別某物或某人。 這類型的代幣非常適合在提供收藏品、密鑰、彩票、音樂會和體育比賽的編號座位等平台上使用。 這種特殊類型的代幣具有驚人潛力,因此它應得一個適當標準,而 ERC-721 正是來解決這個問題!
+
+**什麼是 ERC-721?**
+
+ERC-721 引入了非同質化代幣標準,換句話說,這類型的代幣是獨一無二,並且可以與來自同一智慧型合約的另一種代幣有不同的價值,這可能是由於其存在時間、稀有性甚至是視覺觀感等其他原因。
+等一下,視覺觀感?
+
+是的! 所有 NFT 都有一個名為 `tokenId` 的 `uint256` 變數,因此對於任何 ERC-721 合約,
+`contract address, uint256 tokenId` 這組配對都必須是全域唯一的。 話雖如此,一個去中心化應用程式可以有一個 "轉換器",
+它使用 `tokenId` 作為輸入,並輸出一些很酷的東西的圖片,像是殭屍、武器、技能或超讚的貓咪!
+
+## 先決條件 {#prerequisites}
+
+- [賬戶](/developers/docs/accounts/)
+- [智能合約](/developers/docs/smart-contracts/)
+- [代幣標準](/developers/docs/standards/tokens/)
+
+## 主旨 {#body}
+
+ERC-721(以太坊意見請求 721)由 William Entriken、Dieter Shirley、Jacob Evans、Nastassia Sachs 於 2018 年 1 月提出,是一種非同質化代幣標準,在智慧型合約中實作代幣應用程式介面。
+
+它提供的功能包括將代幣從一個帳戶轉移到另一個帳戶、獲取帳戶當前的代幣餘額、獲取特定代幣的所有者以及網路上可用代幣的總供應量。
+此外它還有一些其他功能,例如批准帳戶中一定數量的代幣可以被第三方帳戶轉移。
+
+如果智慧型合約實作以下方法和事件,則可以將其稱為 ERC-721 非同質化代幣合約。一旦部署,它將負責追蹤以太坊上創建的代幣。
+
+來自 [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
+
+### 方法 {#methods}
+
+```solidity
+ function balanceOf(address _owner) external view returns (uint256);
+ function ownerOf(uint256 _tokenId) external view returns (address);
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function approve(address _approved, uint256 _tokenId) external payable;
+ function setApprovalForAll(address _operator, bool _approved) external;
+ function getApproved(uint256 _tokenId) external view returns (address);
+ function isApprovedForAll(address _owner, address _operator) external view returns (bool);
+```
+
+### Events {#events}
+
+```solidity
+ event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
+ event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
+ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
+```
+
+### 範例 {#web3py-example}
+
+讓我們看看為何標準如此重要,去讓我們檢查以太坊上的任何 ERC-721 代幣合約變得簡單。
+我們只需要合約應用程式二進位介面 (ABI) 來創建任何 ERC-721 代幣的介面。 如下所示,我們將使用簡化的 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
+from web3._utils.events import get_event_data
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties 合約
+
+acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties 銷售拍賣
+
+# 這是 ERC-721 NFT 合約的簡化版合約應用程式二進位介面 (ABI)。
+# 它只會公開以下方法:balanceOf(address)、name()、ownerOf(tokenId)、symbol()、totalSupply()
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'name',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'ownerOf',
+ 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}],
+ 'payable': False, '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
+ },
+]
+
+ck_extra_abi = [
+ {
+ 'inputs': [],
+ 'name': 'pregnantKitties',
+ 'outputs': [{'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'name': '_kittyId', 'type': 'uint256'}],
+ 'name': 'isPregnant',
+ 'outputs': [{'name': '', 'type': 'bool'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi)
+name = ck_contract.functions.name().call()
+symbol = ck_contract.functions.symbol().call()
+kitties_auctions = ck_contract.functions.balanceOf(acc_address).call()
+print(f"{name} [{symbol}] 拍賣中的 NFT:{kitties_auctions}")
+
+pregnant_kitties = ck_contract.functions.pregnantKitties().call()
+print(f"{name} [{symbol}] 懷孕中的 NFT:{pregnant_kitties}")
+
+# 使用 Transfer 事件 ABI 來取得已轉移貓咪的資訊。
+tx_event_abi = {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'from', 'type': 'address'},
+ {'indexed': False, 'name': 'to', 'type': 'address'},
+ {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'Transfer',
+ 'type': 'event'
+}
+
+# 我們需要事件的簽章來篩選日誌
+event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
+
+logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [event_signature]
+})
+
+# 注意:
+# - 如果沒有回傳任何 Transfer 事件,請增加 120 這個區塊數量。
+# - 如果找不到任何 Transfer 事件,您也可以嘗試在此處取得 tokenId:
+# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
+# 按一下以展開事件的日誌,並複製其「tokenId」引數
+recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
+
+if recent_tx:
+ kitty_id = recent_tx[0]['tokenId'] # 從上面的連結將「tokenId」貼在此處
+ is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
+ print(f"{name} [{symbol}] NFT {kitty_id} 是否懷孕:{is_pregnant}")
+```
+
+除了標準事件外,謎戀貓合約還有一些有趣的事件。
+
+讓我們檢查其中兩個:`Pregnant` 和 `Birth`。
+
+```python
+# 使用 Pregnant 和 Birth 事件的 ABI 來取得新貓咪的資訊。
+ck_extra_events_abi = [
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}],
+ 'name': 'Pregnant',
+ 'type': 'event'
+ },
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'kittyId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'genes', 'type': 'uint256'}],
+ 'name': 'Birth',
+ 'type': 'event'
+ }]
+
+# 我們需要事件的簽章來篩選日誌
+ck_event_signatures = [
+ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
+ w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
+]
+
+# 這是一個 Pregnant 事件:
+# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
+pregnant_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[0]]
+})
+
+recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
+
+# 這是一個 Birth 事件:
+# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
+birth_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[1]]
+})
+
+recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
+```
+
+## 熱門 NFT {#popular-nfts}
+
+- [Etherscan NFT Tracker](https://etherscan.io/nft-top-contracts) 根據轉帳量列出以太坊上的頂級 NFT。
+- [CryptoKitties](https://www.cryptokitties.co/) 是一款遊戲,主題圍繞著一種我們稱之為「謎戀貓」的
+ 可繁殖、可收藏且非常可愛的生物。
+- [Sorare](https://sorare.com/) 是一款全球夢幻足球遊戲,你可以在其中收集限量版收藏品、
+ 管理你的球隊並參與競爭以贏得獎品。
+- [以太坊域名服務 (ENS)](https://ens.domains/) 提供一種安全且去中心化的方式,可使用簡單易讀的名稱來定址
+ 鏈上和鏈下的資源。
+- [POAP](https://poap.xyz) 會向參加活動或完成特定行動的人們免費發放 NFT。 建立和分發 POAP 是免費的。
+- [Unstoppable Domains](https://unstoppabledomains.com/) 是一家總部位於舊金山的公司,專門在
+ 區塊鏈上建立網域。 區塊鏈網域以人類可讀的名稱取代加密貨幣地址,並可用於啟用
+ 抗審查的網站。
+- [Gods Unchained Cards](https://godsunchained.com/) 是以太坊區塊鏈上的一款集換式卡牌遊戲 (TCG),它使用 NFT 為
+ 遊戲內資產帶來真正的所有權。
+- [Bored Ape Yacht Club](https://boredapeyachtclub.com) 是一個包含 10,000 個獨特 NFT 的收藏品,它既是一件可證明為稀有的藝術品,也同時是俱樂部的會員代幣,能為會員提供福利,而這些福利會隨著社群的努力與時俱進。
+
+## 延伸閱讀 {#further-reading}
+
+- [EIP-721:ERC-721 非同質化代幣標準](https://eips.ethereum.org/EIPS/eip-721)
+- [OpenZeppelin - ERC-721 文件](https://docs.openzeppelin.com/contracts/3.x/erc721)
+- [OpenZeppelin - ERC-721 實作](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
+- [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-777/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-777/index.md
new file mode 100644
index 00000000000..f057ddd07e6
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/erc-777/index.md
@@ -0,0 +1,46 @@
+---
+title: ERC-777 代幣標準
+description: 了解 ERC-777,這是一種帶有掛鉤 (hooks) 的改良版同質化代幣標準,但基於安全考量,建議使用 ERC-20。
+lang: zh-tw
+---
+
+## 警告 {#warning}
+
+\*\*ERC-777 由於[容易受到不同種類的網絡攻擊], 因此難以正確實行 (https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620)。 為此建議使用 [ERC-20]
+(/developers/docs/standards/tokens/erc-20/) 。\*\*本頁保留作歷史檔案。
+
+## 簡介? {#introduction}
+
+ERC-777是一種同質化代幣標準, 改良於現有 [ERC-20](/developers/docs/standards/tokens/erc-20/) 標準上。
+
+## 先決條件 {#prerequisites}
+
+為能更好地理解本頁內容, 我們推薦你先閱讀有關 [ERC-20](/developers/docs/standards/tokens/erc-20/)。
+
+## ERC-777 相對於 ERC-20 提出了哪些改進? {#-erc-777-vs-erc-20}
+
+ERC-777 相對於 ERC-20 進行了以下改進。
+
+### 挂鈎 {#hooks}
+
+Hooks為一功能函數於智慧型合約程式中. 其能被調用當代幣被接發經由一智慧型合約. 其使智慧型合約能與進發之代幣互動.
+
+挂鈎是使用 [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820) 標準注冊和發現的。
+
+#### 為何掛鉤棒棒? {#why-are-hooks-great}
+
+1. 挂鈎允許在單筆交易中向合約傳送代幣並通知合約,而 [ERC-20](https://eips.ethereum.org/EIPS/eip-20) 則需要進行雙重調用 (`approve`/`transferFrom`) 來達成同樣的操作。
+2. 合約無登記之掛鉤為非完整ERC-777. 傳送合約將終止交易當接收合約無法登記一掛鉤. 此預防意外傳送至一ERC-777智慧型合約.
+3. 掛鉤能脫退中止合約.
+
+### 小數 {#decimals}
+
+此標準還解決了 ERC-20 中引起的 `decimals` 混亂。 這種明確度改善了開發者的體驗。
+
+### 向後兼容 ERC-20 {#backwards-compatibility-with-erc-20}
+
+ERC-777 合約可以像 ERC-20 合約一樣進行互動。
+
+## 延伸閱讀 {#further-reading}
+
+[EIP-777: 代幣標準](https://eips.ethereum.org/EIPS/eip-777)
diff --git a/public/content/translations/zh-tw/developers/docs/standards/tokens/index.md b/public/content/translations/zh-tw/developers/docs/standards/tokens/index.md
new file mode 100644
index 00000000000..268b642d5cc
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/standards/tokens/index.md
@@ -0,0 +1,41 @@
+---
+title: 代幣標準
+description: 探索以太坊代幣標準,包含用於同質化與非同質化代幣的 ERC-20、ERC-721 和 ERC-1155。
+lang: zh-tw
+incomplete: true
+---
+
+## 介紹 {#introduction}
+
+許多以太坊開發標準都專注於代幣介面。 這些標準有助於確保智能合約保持可組合性,因此當新專案發行代幣時,它能與現有的去中心化交易所和應用程式保持相容。
+
+代幣標準定義了代幣在整個以太坊生態系統中的行為和互動方式。 它們讓開發者更容易建構,無需重造輪子,並確保代幣可與錢包、交易所及 DeFi 平台無縫運作。 無論是在遊戲、管理體系還是其他使用案例中,這些標準都提供了一致性,並讓以太坊更加互聯互通。
+
+## 先決條件 {#prerequisites}
+
+- [以太坊開發標準](/developers/docs/standards/)
+- [智能合約](/developers/docs/smart-contracts/)
+
+## 代幣標準 {#token-standards}
+
+以下是以太坊上一些最受歡迎的代幣標準:
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 一種適用於同質化(可互換)代幣的標準介面,例如投票代幣、質押代幣或虛擬貨幣。
+
+### NFT 標準 {#nft-standards}
+
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - 一種非同質化代幣的標準介面,例如藝術品或歌曲的契約。
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155 允許更有效率的交易和交易捆綁 – 從而節省成本。 該代幣標準允許創建實用代幣(例如 $BNB 或 $BAT)和非同質化代幣如 CryptoPunks。
+
+完整的 [ERC](https://eips.ethereum.org/erc) 提案清單。
+
+## 延伸閱讀 {#further-reading}
+
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
+
+## 相關教學 {#related-tutorials}
+
+- [代幣整合檢查清單](/developers/tutorials/token-integration-checklist/) _– 一份在與代幣互動時的注意事項清單。_
+- [了解 ERC20 代幣智能合約](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– 在以太坊測試網上部署您第一個智能合約的簡介。_
+- [從 Solidity 智能合約轉帳及授權 ERC20 代幣](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– 如何使用 Solidity 語言,透過智能合約與代幣互動。_
+- [實作 ERC721 市場 [操作指南]](/developers/tutorials/how-to-implement-an-erc721-market/) _– 如何在去中心化的分類廣告板上出售代幣化物品。_
diff --git a/public/content/translations/zh-tw/developers/docs/storage/index.md b/public/content/translations/zh-tw/developers/docs/storage/index.md
index 8fc5397730a..9b39a0e2922 100644
--- a/public/content/translations/zh-tw/developers/docs/storage/index.md
+++ b/public/content/translations/zh-tw/developers/docs/storage/index.md
@@ -6,7 +6,7 @@ lang: zh-tw
與單一公司或組織運作的中心化伺服器不同,去中心化存儲系統由持有全部資料中部分資料的使用者和營運者的點對點網路組成,建立了一個彈性文件存儲共用系統。 這些存儲系統可以位於基於區塊鏈的應用程式或任何點對點網路中。
-以太坊本身可以用作去中心化存儲系統,所有智慧型合約中的程式碼存儲都是如此。 然而,當涉及大量資料時,就不符合以太坊的設計目的。 該鏈正在穩步增長,但在撰寫本文時,以太坊鏈約為 500GB - 1TB([取決於用戶端](https://etherscan.io/chartsync/chaindefault)),網路上的每個節點都需要能夠存儲所有資料。 如果鏈上資料量擴大(例如 5TB),所有節點都無法繼續運作。 此外,由於[燃料](/developers/docs/gas)費用,將這麼多資料部署到主網的成本將非常昂貴。
+以太坊本身可以用作去中心化存儲系統,所有智慧型合約中的程式碼存儲都是如此。 然而,當涉及大量資料時,就不符合以太坊的設計目的。 該鏈正在穩步增長,但在撰寫本文時,以太坊鏈的大小約為 500GB 至 1TB([取決于用戶端](https://etherscan.io/chartsync/chaindefault)),網路上的每個節點都需要能夠存儲所有資料。 如果鏈上資料量擴大(例如 5TB),所有節點都無法繼續運作。 此外,由於 [gas](/developers/docs/gas) 費用,將這麼多資料部署到主網的成本將會高得嚇人。
由於這些限制,我們需要不同的鏈或方法來以去中心化方式存儲大量資料。
@@ -17,15 +17,15 @@ lang: zh-tw
- 去中心化
- 共識
-## 持續機制 / 誘因架構 {#persistence-mechanism}
+## 持久性機制 / 激勵結構 {#persistence-mechanism}
### 基於區塊鏈 {#blockchain-based}
為了讓一段資料永久保存,我們需要使用持久性機制。 例如,在以太坊上,持久性機制意味著運行一個節點時需要考慮整條鏈。 新的資料被新增至鏈的末端,並且鏈會繼續增長,並要求每個節點複製所有內嵌的資料。
-這稱為**基於區塊鏈**的持久性。
+這就是所謂的 **基於區塊鏈** 的持久性。
-基於區塊鏈的持久性會出現區塊鏈過大,無法維護和存儲所有資料的問題(例如[許多機構](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/)預測整條區塊鏈網路需要 40ZB 的存儲容量)。
+基於區塊鏈的持久性的問題在於,鏈可能會變得過於龐大,以至於無法實際地維護和存儲所有資料(例如,[許多來源](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/)估計網際網路需要超過 40 ZB 的存儲容量)。
區塊鏈也必須具有某種類型的激勵結構。 為實現基於區塊鏈的持久性,需要向驗證者支付費用。 資料被新增到鏈上後,向驗證者支付以讓其繼續添加資料。
@@ -36,14 +36,14 @@ lang: zh-tw
### 基於合約 {#contract-based}
-我們能直觀地感受到,**基於合約**的持久性使得資料不能被每個節點複製並永久存儲,而必須根據合約協定進行維護。 這些是與多個節點簽訂的協定,承諾在一段時間內保存一段資料。 一旦時間結束,就必須向節點續費,以保持資料的持久性。
+**基於合約**的持久性認為,資料無法由每個節點複製並永久存儲,而必須透過合約協議來維護。 這些是與多個節點簽訂的協定,承諾在一段時間內保存一段資料。 一旦時間結束,就必須向節點續費,以保持資料的持久性。
-在大多數情況下,不會將所有資料存儲在鏈上,而是存儲資料在鏈上位置的雜湊值。 這樣,就不需要擴充整個鏈來保留所有資料。
+在大多數情況下,不會將所有資料存儲在鏈上,而是存儲資料在鏈上位置的哈希。 這樣,就不需要擴充整個鏈來保留所有資料。
具有基於合約的持久性的平台:
-- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/)
-- [Skynet](https://siasky.net/)
+- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin)
+- [Skynet](https://sia.tech/)
- [Storj](https://storj.io/)
- [Züs](https://zus.network/)
- [Crust Network](https://crust.network)
@@ -54,14 +54,14 @@ lang: zh-tw
星際檔案系統是一個儲存和存取檔案、網站、應用程式和資料的分散式系統。 雖然它沒有內建激勵計劃,但可以與上述任何基於合約的激勵解決方案一起使用,以獲得更長期的持久性。 另一個將資料持久儲存在星際檔案系統上的方法是與某項固定服務(表示將你的資料固定在某處)一起使用。 你甚至可以運行自己的星際檔案系統節點來為該網路做出貢獻,從而將你和/或他人的資料免費且持久地儲存在星際檔案系統上。
-- [星際檔案系統](https://docs.ipfs.io/concepts/what-is-ipfs/)
-- [Pinata](https://www.pinata.cloud/)_(星際檔案系統固定服務)_
-- [web3.storage](https://web3.storage/)_(星際檔案系統/菲樂幣固定服務)_
-- [Infura](https://infura.io/product/ipfs)_(星際檔案系統固定服務)_
-- [IPFS Scan](https://ipfs-scan.io) _(星際檔案系統固定瀏覽器)_
--
-- [Filebase](https://filebase.com)_(星際檔案系統固定服務)_
-- [Spheron Network](https://spheron.network/) _(星際檔案系統/菲樂幣固定服務)_
+- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/)
+- [Pinata](https://www.pinata.cloud/) _(IPFS 釘選服務)_
+- [web3.storage](https://web3.storage/) _(IPFS/Filecoin 釘選服務)_
+- [Infura](https://infura.io/product/ipfs) _(IPFS 釘選服務)_
+- [IPFS Scan](https://ipfs-scan.io) _(IPFS 釘選瀏覽器)_
+- [4EVERLAND](https://www.4everland.org/)_(IPFS 釘選服務)_
+- [Filebase](https://filebase.com) _(IPFS 釘選服務)_
+- [Spheron Network](https://spheron.network/) _(IPFS/Filecoin 釘選服務)_
SWARM 是一種去中心化的資料儲存和分發技術,具有儲存激勵系統和儲存空間租金價格預測機。
@@ -69,7 +69,7 @@ SWARM 是一種去中心化的資料儲存和分發技術,具有儲存激勵
為了保留資料,系統必須有某種機制來確保已保留資料。
-### 質詢機制 {#challenge-mechanism}
+### 挑戰機制 {#challenge-mechanism}
確保已保留資料的最常用方法之一是使用向節點發出的某種類型的加密質詢以確保節點仍然擁有資料。 一個簡單的例子就是查看Arweave的存取證明。 它們向節點發出質詢,看看節點是否擁有最新區塊和過去隨機區塊的資料。 如果節點無法給出答案,就會受到處罰。
@@ -82,7 +82,7 @@ SWARM 是一種去中心化的資料儲存和分發技術,具有儲存激勵
- Crust Network
- 4EVERLAND
-### 去中央化性 {#decentrality}
+### 去中心化 {#decentrality}
沒有很好的工具來衡量平台的去中心化程度,但一般來說,你會希望使用不具有某種形式的「認識客戶」的工具來提供平台並非中心化的證據。
@@ -91,14 +91,14 @@ SWARM 是一種去中心化的資料儲存和分發技術,具有儲存激勵
- Skynet
- Arweave
- Filecoin
-- IPFS
-- Ethereum
+- 星際檔案系統
+- 以太坊
- Crust Network
- 4EVERLAND
### 共識 {#consensus}
-這些工具中的大多數都有自己的[共識機制](/developers/docs/consensus-mechanisms/)版本,但通常它們基於[**工作量證明 (PoW)**](/developers/docs/consensus-mechanisms/pow/) 或[**權益證明 (PoS)**](/developers/docs/consensus-mechanisms/pos/)。
+這些工具大多有自己的[共識機制](/developers/docs/consensus-mechanisms/)版本,但通常是基於 [**工作量證明 (PoW)**](/developers/docs/consensus-mechanisms/pow/) 或 [**權益證明 (PoS)**](/developers/docs/consensus-mechanisms/pos/)。
基於工作量證明:
@@ -114,103 +114,103 @@ SWARM 是一種去中心化的資料儲存和分發技術,具有儲存激勵
## 相關工具 {#related-tools}
-**IPFS - _星際檔案系統是以太坊的去中心化存儲和檔案引用系統。_**
+**IPFS - _星際檔案系統 (InterPlanetary File System) 是一種給以太坊使用的去中心化存儲與檔案參考系統。_**
- [Ipfs.io](https://ipfs.io/)
- [文件](https://docs.ipfs.io/)
-- [Github](https://github.com/ipfs/ipfs)
+- [GitHub](https://github.com/ipfs/ipfs)
-**Storj DCS - _為開發者提供安全、私有且相容 S3 的去中心化雲端物件存儲。_**
+**Storj DCS - _為開發者設計的安全、私有且與 S3 相容的去中心化雲端物件存儲。_**
- [Storj.io](https://storj.io/)
- [文件](https://docs.storj.io/)
- [GitHub](https://github.com/storj/storj)
-**Skynet - _Skynet 是一個致力於去中心化網路的去中心化工作量證明鏈。_**
+**Sia - _利用密碼學建立無需信任的雲端存儲市集,讓買賣雙方可以直接交易。_**
-- [Skynet.net](https://siasky.net/)
-- [文件](https://siasky.net/docs/)
-- [Github](https://github.com/SkynetLabs/)
+- [Skynet.net](https://sia.tech/)
+- [文件](https://docs.sia.tech/)
+- [GitHub](https://github.com/SiaFoundation/)
-**Filecoin - _Filecoin 是由星際檔案系統背後的同一團隊建立的。 它是星際檔案系統概念之上的激勵層。_**
+**Filecoin - _Filecoin 由 IPFS 背後的同一個團隊所創建。 此添增一誘因層面於IPFS想法之上._**
- [Filecoin.io](https://filecoin.io/)
- [文件](https://docs.filecoin.io/)
-- [Github](https://github.com/filecoin-project/)
+- [GitHub](https://github.com/filecoin-project/)
-**Arweave - _Arweave 是一個用於存儲資料的去中心化存儲平台。_**
+**Arweave - _Arweave 是一個用來存儲資料的去中心化存儲平台。_**
- [Arweave.org](https://www.arweave.org/)
- [文件](https://docs.arweave.org/info/)
- [Arweave](https://github.com/ArweaveTeam/arweave/)
-**Züs - _Züs 是具有分片和 Blobber 的權益證明去中心化存儲平台。_**
+**Züs - _Züs 是一個具有分片和 blobber 的權益證明去中心化存儲平台。_**
- [zus.network](https://zus.network/)
-- [文件](https://0chaindocs.gitbook.io/zus-docs)
-- [Github](https://github.com/0chain/)
+- [文件](https://docs.zus.network/zus-docs/)
+- [GitHub](https://github.com/0chain/)
-**Crust Network - _Crust 是基於星際檔案系統的去中心化存儲平台。_**
+**Crust Network - _Crust 是建構於 IPFS 之上的去中心化存儲平台。_**
- [Crust.network](https://crust.network)
- [文件](https://wiki.crust.network)
- [GitHub](https://github.com/crustio)
-**Swarm - _用於以太坊 web3 堆疊的分佈式存儲平台和內容分發服務。_**
+**Swarm - _為以太坊 web3 堆疊設計的分散式存儲平台與內容分發服務。_**
- [EthSwarm.org](https://www.ethswarm.org/)
-- [文件](https://docs.ethswarm.org/docs/)
-- [Github](https://github.com/ethersphere/)
+- [文件](https://docs.ethswarm.org/)
+- [GitHub](https://github.com/ethersphere/)
-**OrbitDB - _基於星際檔案系統的去中心化點對點資料庫。_**
+**OrbitDB - _建構於 IPFS 之上的去中心化點對點資料庫。_**
- [OrbitDB.org](https://orbitdb.org/)
- [文件](https://github.com/orbitdb/field-manual/)
-- [Github](https://github.com/orbitdb/orbit-db/)
+- [GitHub](https://github.com/orbitdb/orbit-db/)
-**Aleph.im - _去中心化雲端專案(資料庫、檔案存儲、運算和去中心化身分)。 鏈下和鏈上點對點技術的獨特融合。 星際檔案系統和多鏈相容性。_**
+**Aleph.im - _去中心化雲端專案(資料庫、檔案存儲、運算與 DID)。 鏈下和鏈上點對點技術的獨特融合。 IPFS及跨鏈組合性._**
-- [Aleph.im](https://aleph.im/)
-- [文件](https://aleph.im/#/developers/)
-- [Github](https://github.com/aleph-im/)
+- [Aleph.im](https://aleph.cloud/)
+- [文件](https://docs.aleph.cloud/)
+- [GitHub](https://github.com/aleph-im/)
-**Ceramic - _使用者控制的星際檔案系統資料庫存儲,用於資料豐富且引人入勝的應用程式。_**
+**Ceramic - _為資料豐富且具吸引力的應用程式設計,由使用者控制的 IPFS 資料庫存儲。_**
- [Ceramic.network](https://ceramic.network/)
-- [文件](https://developers.ceramic.network/learn/welcome/)
-- [Github](https://github.com/ceramicnetwork/js-ceramic/)
+- [文件](https://developers.ceramic.network/)
+- [GitHub](https://github.com/ceramicnetwork/js-ceramic/)
-**Filebase - _ S3 相容的去中心化存儲和異地備援星際檔案系統固定服務。 所有透過 Filebase 上傳到星際檔案系統的檔案,都會自動被固定到 Filebase 基礎設施,並在全球複製 3 份。_**
+**Filebase - _與 S3 相容的去中心化存儲和異地備援 IPFS 釘選服務。 所有透過 Filebase 上傳到 IPFS 的檔案都會自動釘選到 Filebase 基礎設施,並在全球複製 3 份。_**
- [Filebase.com](https://filebase.com/)
-- [文檔](https://docs.filebase.com/)
-- [Github](https://github.com/filebase)
+- [文件](https://docs.filebase.com/)
+- [GitHub](https://github.com/filebase)
-**4EVERLAND - _Web 3.0 雲端運算平台,集存儲、運算和網路核心能力於一身,相容於 S3 並在星際檔案系統和 Arweave 等去中心化存儲網路上提供同步資料存儲。_**
+**4EVERLAND - _一個 Web 3.0 雲端運算平台,整合了存儲、運算和網路核心能力,與 S3 相容,並在 IPFS 和 Arweave 等去中心化存儲網路上提供同步資料存儲。_**
- [4everland.org](https://www.4everland.org/)
- [文件](https://docs.4everland.org/)
- [GitHub](https://github.com/4everland)
-**Kaleido - _區塊鏈即服務平台,具有點擊按鈕的星際檔案系統節點_**
+**Kaleido - _一個提供可一鍵部署 IPFS 節點的區塊鏈即服務平台_**
- [Kaleido](https://kaleido.io/)
- [文件](https://docs.kaleido.io/kaleido-services/ipfs/)
- [GitHub](https://github.com/kaleido-io)
-**Spheron Network - _Spheron 是一個平台即服務 (PaaS),專為希望在去中心化基礎設施上以最佳效能啟動其應用程式的去中心化應用程式而設計。 它提供開箱即用的運算、去中心化存儲、內容傳遞網路和網頁寄存。_**
+**Spheron Network - _Spheron 是一個平台即服務 (PaaS),專為希望在去中心化基礎設施上以最佳效能啟動其應用程式的去中心化應用程式而設計。 它提供開箱即用的運算、去中心化存儲、CDN 與網頁代管服務。_**
- [spheron.network](https://spheron.network/)
- [文件](https://docs.spheron.network/)
- [GitHub](https://github.com/spheronFdn)
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [什麼是去中心化存儲?](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
-- [打破關於去中心化存儲的五個常見誤解](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
+- [什麼是去中心化存儲?](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
+- [破解關於去中心化存儲的五個常見迷思](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [開發架構](/developers/docs/frameworks/)
+- [開發框架](/developers/docs/frameworks/)
diff --git a/public/content/translations/zh-tw/developers/docs/transactions/index.md b/public/content/translations/zh-tw/developers/docs/transactions/index.md
index b233bf5bf44..28e449b61b6 100644
--- a/public/content/translations/zh-tw/developers/docs/transactions/index.md
+++ b/public/content/translations/zh-tw/developers/docs/transactions/index.md
@@ -6,15 +6,16 @@ lang: zh-tw
交易是帳戶發出的帶密碼學簽章的指令。 帳戶將發起交易以更新以太坊網路的狀態。 最簡單的交易是將以太幣從一個帳戶轉帳到另一個帳戶。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了讓你更容易理解本頁,建議你先閱讀[帳戶](/developers/docs/accounts/)及我們的[以太坊介紹](/developers/docs/intro-to-ethereum/)。
+為協助您更了解本頁,建議您先閱讀 [帳戶](/developers/docs/accounts/) 和我們的 [以太坊簡介](/developers/docs/intro-to-ethereum/)。
## 什麼是交易? {#whats-a-transaction}
以太坊交易是指由外部帳戶發起的操作,換句話說,此帳戶是由人而不是智慧型合約管理的帳戶。 例如,如果 Bob 發送給 Alice 1 以太幣,Bob 的帳戶必須扣除,Alice 的帳戶必須存入。 此更改狀態的操作發生在交易中。
- _此圖源於[以太坊EVM圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [Ethereum EVM 圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
交易會改變以太坊虛擬機的狀態,須廣播至整個網路。 任何節點都可以廣播要在以太坊虛擬機上執行的交易請求;之後驗證者將執行交易並將引起的狀態變化傳播到網路上的其他節點。
@@ -22,17 +23,17 @@ lang: zh-tw
提交的交易包括下列資訊:
-- `from` – 發送者(簽署交易者)的地址。 這將是一個外部擁有的帳戶,因爲合約帳戶無法傳送交易
-- `to` – 接收地址(若為外部帳戶,交易將會轉移金額。 如果為合約帳戶,交易將執行合約程式碼)
+- `from` – 發送者的地址,將會用來簽署交易。 這將是一個外部擁有的帳戶,因爲合約帳戶無法傳送交易
+- `to` – 接收地址 (若是外部擁有的帳戶,此交易將會轉移價值。 如果為合約帳戶,交易將執行合約程式碼)
- `signature` – 發送者的識別碼。 當發送者以私密金鑰簽署交易並確認發送者已授權此交易时,就會產生此簽章。
-- `nonce` - 用來表示帳戶中交易編號的按順序遞增計數器
-- `value` – 發送者轉帳至接收者的以太幣數量(面額為 WEI,1 以太幣等於 10 的 18 次方 wei)
-- `input data` –可選欄位,可填入任意資料
-- `gasLimit` – 交易可以使用的最大燃料單位數量。 [以太坊虛擬機](/developers/docs/evm/opcodes)指定了每個計算步驟的所需燃料單位
-- `maxPriorityFeePerGas` - 已使用燃料的最高價格,可作為給驗證者的小費
-- `maxFeePerGas` - 願意為交易支付的每單位燃料的最高費用(包含 `baseFeePerGas` 和 `maxPriorityFeePerGas`)
+- `nonce` - 一個循序遞增的計數器,代表來自該帳戶的交易編號
+- `value` – 從發送者轉移到接收者的 ETH 數量 (以 WEI 為單位,其中 1 ETH 等於 1e+18 wei)
+- `input data` – 選填欄位,可包含任意資料
+- `gasLimit` – 交易可消耗的 Gas 單位上限。 [EVM](/developers/docs/evm/opcodes) 指定了每個運算步驟所需的 Gas 單位
+- `maxPriorityFeePerGas` - 可作為給驗證程式小費的每單位 Gas 最高價格
+- `maxFeePerGas` - 願意為此交易支付的每單位 Gas 最高費用 (包含 `baseFeePerGas` 與 `maxPriorityFeePerGas`)
-燃料指請驗證者處理交易所需的計算。 使用者必須為計算支付費用。 `gasLimit` 和 `maxPriorityFeePerGas` 決定支付給驗證者的最高交易費。 [更多燃料相關資訊](/developers/docs/gas/)。
+燃料指請驗證者處理交易所需的計算。 使用者必須為計算支付費用。 `gasLimit` 和 `maxPriorityFeePerGas` 決定支付給驗證程式的最高交易費用。 [更多關於 Gas 的資訊](/developers/docs/gas/)。
交易物件看起來有些像以下內容:
@@ -41,10 +42,10 @@ lang: zh-tw
from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
gasLimit: "21000",
- maxFeePerGas: "300"
- maxPriorityFeePerGas: "10"
+ maxFeePerGas: "300",
+ maxPriorityFeePerGas: "10",
nonce: "0",
- value: "10000000000",
+ value: "10000000000"
}
```
@@ -52,7 +53,7 @@ lang: zh-tw
Geth 之類的以太坊用戶端將處理此簽署過程。
-[JSON-RPC](/developers/docs/apis/json-rpc) 呼叫範例:
+範例 [JSON-RPC](/developers/docs/apis/json-rpc) 呼叫:
```json
{
@@ -99,22 +100,26 @@ Geth 之類的以太坊用戶端將處理此簽署過程。
}
```
-- `raw` 是[遞迴長度前綴 (RLP)](/developers/docs/data-structures-and-encoding/rlp) 編碼形式的已簽署交易
+- `raw` 是以 [遞迴長度前綴 (RLP)](/developers/docs/data-structures-and-encoding/rlp) 編碼形式呈現的已簽署交易
- `tx` 是 JSON 形式的已簽署交易
交易具備簽章雜湊值,因此可通過加密技術證明交易來自發送者並提交至網路。
### 資料欄位 {#the-data-field}
-大多數交易從外部帳戶存取合約。 大部分合約都用 Solidity 寫成,並根據[應用程式介面 (ABI)](/glossary/#abi) 解譯其資料欄位。
+大多數交易從外部帳戶存取合約。
+大多數合約以 Solidity 撰寫,並根據 [應用程式二進位介面 (ABI)](/glossary/#abi) 解譯其資料欄位。
-前四個字節位元組使用函式名稱及參數的雜湊值指定要呼叫的函式。 有時候可以從使用[此資料庫](https://www.4byte.directory/signatures/)識別選擇器中的函式。
+前四個字節位元組使用函式名稱及參數的雜湊值指定要呼叫的函式。
+有時您可以使用[此資料庫](https://www.4byte.directory/signatures/) 來從選擇器識別函式。
-calldata 的剩餘部分是參數,[依據 ABI 規範中的說明編碼](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding)。
+calldata 的其餘部分是引數,[根據 ABI 規格中的指定方式進行編碼](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding)。
-例如,我們來看下[這筆交易](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1)。 使用 **Click to see More** 檢視 calldata。
+例如,我們來看看[這筆交易](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1)。
+使用 **Click to see More** 檢視 calldata。
-函式選擇器為 `0xa9059cbb`。 一些[已知的函式具有此簽章](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb)。 在這個例子中,[合約的原始程式碼](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code)已經上傳到 Etherscan,所以我們知道函式是 `transfer(address,uint256)`。
+函式選擇器是 `0xa9059cbb`。 有數個[已知函式具有此簽章](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb)。
+在本案例中,[合約原始碼](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code)已上傳至 Etherscan,因此我們知道函式為 `transfer(address,uint256)`。
其餘資料如下所示:
@@ -123,7 +128,9 @@ calldata 的剩餘部分是參數,[依據 ABI 規範中的說明編碼](https:
000000000000000000000000000000000000000000000000000000003b0559f4
```
-根據 ABI 規範,應用程式介面中的整數值(例如地址,20 字節位元組的整數)顯示為 32 字節位元組的字,並且前面用 0 來填補。 所以我們知道 `to` 地址為 [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279)。 `value` 為 0x3b0559f4 = 990206452。
+根據 ABI 規範,應用程式介面中的整數值(例如地址,20 字節位元組的整數)顯示為 32 字節位元組的字,並且前面用 0 來填補。
+因此我們知道 `to` 地址是 [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279)。
+`value` 為 0x3b0559f4 = 990206452。
## 交易類型 {#types-of-transactions}
@@ -133,11 +140,11 @@ calldata 的剩餘部分是參數,[依據 ABI 規範中的說明編碼](https:
- 合約部署交易:沒有「to」地址的交易,其資料欄供合約程式碼所用。
- 合約執行:與部署的智慧型合約互動的交易。 在本例中,「to」地址為智慧型合約的地址。
-### 關於燃料 {#on-gas}
+### 關於 Gas {#on-gas}
-如上所述,執行交易需要花費[燃料](/developers/docs/gas/)。 簡單的轉帳交易需要 21000 單位燃料。
+如前所述,執行交易需要花費 [Gas](/developers/docs/gas/)。 簡單的轉帳交易需要 21000 單位燃料。
-所以,若 Bob 要以 190 gwei 的 `baseFeePerGas` 還有 10 gwei 的 `maxPriorityFeePerGas` 給 Alice 發送 1 以太幣,Bob 將需要支付以下費用:
+因此,如果 Bob 要在 `baseFeePerGas` 為 190 gwei 且 `maxPriorityFeePerGas` 為 10 gwei 的情況下,傳送 1 ETH 給 Alice,Bob 將需要支付下列費用:
```
(190 + 10) * 21000 = 4,200,000 gwei
@@ -145,77 +152,82 @@ calldata 的剩餘部分是參數,[依據 ABI 規範中的說明編碼](https:
0.0042 以太幣
```
-Bob 的帳戶會被扣除 **-1.0042 以太幣**(1 以太幣給 Alice + 0.0042 以太幣用來支付燃料費)
+Bob 的帳戶將會被扣款 **-1.0042 ETH** (1 ETH 給 Alice + 0.0042 ETH 的 Gas 費用)
-Alice 的帳戶將存入 **+1.0 以太幣**
+Alice 的帳戶將會存入 **+1.0 ETH**
-基本費用將銷毀 **-0.00399 以太幣**
+基本費用將被銷毀 **-0.00399 ETH**
-驗證者將保留 **+0.000210 以太幣**的小費
+驗證程式保留小費 **+0.000210 ETH**
-
- _此圖源於[以太坊EVM圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [Ethereum EVM 圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
任何交易中未使用的燃料都會退還給使用者帳戶。
-### 智慧型合約互動 {#smart-contract-interactions}
+### 智慧合約互動 {#smart-contract-interactions}
任何涉及智慧型合約的交易都需要燃料。
-智慧型合約也可以包含稱為 [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) 或 [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) 的函數,而不會改變合約的狀態。 因此,從外部帳戶調用這些函數不需要任何燃料。 此場景的底層遠端程序呼叫為 [`eth_call`](/developers/docs/apis/json-rpc#eth_call)。
+智慧合約也可以包含 [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) 或 [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) 函式,這些函式不會改變合約的狀態。 因此,從外部帳戶調用這些函數不需要任何燃料。 此情境的底層 RPC 呼叫是 [`eth_call`](/developers/docs/apis/json-rpc#eth_call)。
-與使用 `eth_call` 存取不同,這些 `view` 或 `pure` 函數也通常被內部調用(即從合約本身調用或從另一個合約調用),這會消耗燃料。
+與使用 `eth_call` 存取不同,這些 `view` 或 `pure` 函式也常在內部被呼叫 (即從合約本身或從另一個合約呼叫),這確實會花費 Gas。
-## 交易的生命週期 {#transaction-lifecycle}
+## 交易生命週期 {#transaction-lifecycle}
一旦交易被提交,就會發生以下情況:
-1. 透過加密方式生成交易雜湊值: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
+1. 交易哈希是以密碼學方式產生的:
+ `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
2. 然後該交易會廣播到網路並添加到交易池中,交易池中包含了其他所有等待中的網路交易。
3. 為了要驗證交易並使交易「成功」,驗證者必須選擇你的交易並將它打包進區塊中。
-4. 隨著時間推移,含有你交易的區塊會被升級為「已證明」,然後是「最終化」。 這些升級進一步確定 你的交易已經成功且永遠不會被更改。 當區塊「最終化」後,就僅可能被網路層級的攻擊變更, 此類攻擊需要花費數十億美元。
+4. 隨著時間推移,含有你交易的區塊會被升級為「已證明」,然後是「最終化」。 這些升級能讓您更加
+ 確定交易成功,且永遠不會被更改。 一旦區塊「最終確認」,就只能透過
+ 耗資數十億美元的網路層級攻擊才能更改。
-## 視訊示範 {#a-visual-demo}
+## 視覺化示範 {#a-visual-demo}
觀看 Austin 為你講解交易、燃料和挖礦。
-## Typed Transaction Envelope 交易 {#typed-transaction-envelope}
+## 類型化交易封包 {#typed-transaction-envelope}
-以太坊最初有一種形式的交易。 每筆交易都包含 nonce、gas price、gas limit、to address、value、data、v、r 與 s。 這些欄位均為 [RLP 編碼](/developers/docs/data-structures-and-encoding/rlp/),看上去像是以下內容:
+以太坊最初有一種形式的交易。 每筆交易都包含 nonce、gas price、gas limit、to address、value、data、v、r 與 s。 這些欄位經過 [RLP 編碼](/developers/docs/data-structures-and-encoding/rlp/)後,看起來像這樣:
`RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])`
-以太坊不斷演進以支援多種交易類型,以便在實作存取清單和 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 等新功能時不會影響原有交易形式。
+以太坊已演進到支援多種類型的交易,以便在實作存取清單和 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 等新功能時,不會影響舊有交易格式。
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) 是支援此類行為的協議。 交易的解釋如下:
+[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) 實現了這種行為。 交易的解釋如下:
`TransactionType || TransactionPayload`
其欄位定義如下:
-- `TransactionType` - 介於 0 和 0x7f 之間的數字,代表總計 128 種可能的交易類型。
-- `TransactionPayload` - 由交易類型定義的任意字節位元組陣列。
+- `TransactionType` - 一個介於 0 和 0x7f 之間的數字,總共有 128 種可能的交易類型。
+- `TransactionPayload` - 由交易類型定義的任意位元組陣列。
-根據 `TransactionType` 值,交易可以分類為:
+根據 `TransactionType` 的值,交易可分類為:
-1. **類型 0(傳統)交易:**自以太坊推出以來使用的原始交易格式。 它們不包括 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 的功能,例如動態燃料費計算或智慧型合約的存取清單。 傳統交易缺少在序列化形式中指示交易類型的特定前綴,在使用[遞迴長度前綴 (RLP)](/developers/docs/data-structures-and-encoding/rlp) 編碼時,該前綴以位元組 `0xf8` 開始。 這些交易的 TransactionType 值為 `0x0`。
+1. **類型 0 (傳統) 交易:** 自以太坊推出以來使用的原始交易格式。 它們不包含 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 的功能,例如動態 Gas 費用計算或智慧合約的存取清單。 傳統交易在其序列化形式中缺少指示其類型的特定前綴,在使用[遞迴長度前綴 (RLP)](/developers/docs/data-structures-and-encoding/rlp) 編碼時以位元組 `0xf8` 開頭。 這些交易的 TransactionType 值為 `0x0`。
-2. **類型 1 交易:**在 [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) 中引入作為以太坊[柏林升級](/ethereum-forks/#berlin)的一部分,這些交易包含一個 `accessList` 參數。 此清單指定了交易期望存取的地址和儲存金鑰,有助於潛在降低涉及智慧型合約的複雜交易的[燃料](/developers/docs/gas/)成本。 EIP-1559 的費用市場變化不會包含在類型 1 交易中。 類型 1 交易也包含一個 `yParity` 參數,該參數可以是 `0x0` 或 `0x1`,表示 secp256k1 簽章的 y 值的奇偶性。 此類交易透過開頭的位元組 `0x01` 開頭辨識,其 TransactionType 值為 `0x1`。
+2. **類型 1 交易:** 在 [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) 中作為以太坊[柏林升級](/ethereum-forks/#berlin) 的一部分引入,這些交易包含一個 `accessList` 參數。 此清單指定了交易預期存取的地址和儲存金鑰,有助於潛在降低涉及智慧合約的複雜交易的 [Gas](/developers/docs/gas/) 成本。 EIP-1559 的費用市場變化不會包含在類型 1 交易中。 類型 1 交易也包含一個 `yParity` 參數,可以是 `0x0` 或 `0x1`,表示 secp256k1 簽章的 y 值的奇偶性。 它們以位元組 `0x01` 開頭來識別,其 TransactionType 值為 `0x1`。
-3. **類型 2 交易**,通常稱為 EIP-1559 交易,是以太坊[倫敦升級](/ethereum-forks/#london)裡 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 中引入的交易。 這類交易已成為以太坊網路上的標準交易類型。 這些交易引入了一種新的費用市場機制,透過將交易費用分為基本費用和優先費來提高可預測性。 這些交易的開頭為位元組 `0x02`,並包含 `maxPriorityFeePerGas` 和 `maxFeePerGas` 等欄位。 類型 2 交易因其靈活性和效率而成為預設交易,在網路高度擁塞期間尤其受到青睞,因為它們能夠幫助使用者更好地預測及管理交易費用。 這些交易的 TransactionType 值為 `0x2`。
+3. **類型 2 交易**,通常稱為 EIP-1559 交易,是在以太坊[倫敦升級](/ethereum-forks/#london) 的 [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) 中引入的交易。 這類交易已成為以太坊網路上的標準交易類型。 這些交易引入了一種新的費用市場機制,透過將交易費用分為基本費用和優先費來提高可預測性。 它們以位元組 `0x02` 開頭,並包含 `maxPriorityFeePerGas` 和 `maxFeePerGas` 等欄位。 類型 2 交易因其靈活性和效率而成為預設交易,在網路高度擁塞期間尤其受到青睞,因為它們能夠幫助使用者更好地預測及管理交易費用。 這些交易的 TransactionType 值為 `0x2`。
+4. **類型 3 (Blob) 交易**在[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) 中作為以太坊 [Dencun 升級](/ethereum-forks/#dencun) 的一部分被引入。 這些交易旨在更高效地處理「blob」資料 (二進位大型物件),它們提供了一種以更低成本將資料發佈到以太坊網路的方法,尤其有利於二層網路卷軸。 Blob 交易包含額外欄位,例如 `blobVersionedHashes`、`maxFeePerBlobGas` 和 `blobGasPrice`。 它們以位元組 `0x03` 開頭,其 TransactionType 值為 `0x3`。 Blob 交易代表了以太坊在資料可用性和可擴張性方面的重大改進。
+5. **類型 4 交易**是在[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) 中作為以太坊 [Pectra 升級](/roadmap/pectra/) 的一部分引入的。 這些交易被設計為與帳戶抽象化向前相容。 它們允許 EOA 暫時表現得像智慧合約帳戶,而不會影響其原始功能。 它們包含一個 `authorization_list` 參數,用於指定 EOA 將其權限委派給哪個智慧合約。 交易後,EOA 的程式碼欄位將包含被委派的智慧合約地址。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [EIP-2718:Typed Transaction Envelope 交易](https://eips.ethereum.org/EIPS/eip-2718)
+- [EIP-2718:類型化交易封包](https://eips.ethereum.org/EIPS/eip-2718)
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [帳戶](/developers/docs/accounts/)
-- [以太坊虛擬機](/developers/docs/evm/)
+- [賬戶](/developers/docs/accounts/)
+- [以太坊虛擬機 (EVM)](/developers/docs/evm/)
- [Gas](/developers/docs/gas/)
diff --git a/public/content/translations/zh-tw/developers/docs/web2-vs-web3/index.md b/public/content/translations/zh-tw/developers/docs/web2-vs-web3/index.md
index d98309a961b..7a8c47b180e 100644
--- a/public/content/translations/zh-tw/developers/docs/web2-vs-web3/index.md
+++ b/public/content/translations/zh-tw/developers/docs/web2-vs-web3/index.md
@@ -1,6 +1,6 @@
---
-title: Web2 vs Web3
-description:
+title: Web2 與 Web3
+description: 比較中心化 Web2 服務與建立在以太坊區塊鏈技術上的去中心化 Web3 應用程式。
lang: zh-tw
---
@@ -8,7 +8,7 @@ Web2 指的是目前我們大多人熟知的網際網路。 網際網路由各
正在找尋找更適合初學者的資源? 請參閱我們的 [web3 簡介](/web3/)。
-## Web3 優點 {#web3-benefits}
+## Web3 的優點 {#web3-benefits}
很多 Web3 開發者選擇建立去中心化應用程式,是因為以太坊固有的去中心化優點:
@@ -17,7 +17,7 @@ Web2 指的是目前我們大多人熟知的網際網路。 網際網路由各
- 支付是透過原生代幣以太幣建立的。
- 以太坊是圖靈完備的,這表示你可以在上面寫許多程式。
-## 實務對比 {#practical-comparisons}
+## 實際比較 {#practical-comparisons}
| Web2 | Web3 |
| ------------------------- | --------------------------------------- |
@@ -52,11 +52,11 @@ Web3 目前的一些限制:
注意,這些概況可能並不適用於每個網路。 此外實際當中,網路的中心化與去中心化程度是一個範圍;沒有任何一個網路是完全中心化或完全去中心化的。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [什麼是 Web3?](/web3/) - _ethereum.org_
- [Web 3.0 應用程式的架構](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-- [去中心化的意義](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _2017 年 2 月 6日 - Vitalik Buterin_
-- [去中心化的重要性](https://medium.com/s/story/why-decentralization-matters-5e3f79f7638e) _2018 年 2 月 18 日 - Chris Dixon_
-- [什麼是 Web 3.0?它為什麼重要?](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _2019 年 12 月 31 日 - Max Mersch 和 Richard Muirhead_
-- [為何我們需要 Web 3.0](https://medium.com/@gavofyork/why-we-need-web-3-0-5da4f2bf95ab) _2018 年 9 月 12 日 - Gavin Wood_
+- [去中心化的意義](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _2017 年 2 月 6 日 - Vitalik Buterin_
+- [為什麼去中心化很重要](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) _2018 年 2 月 18 日 - Chris Dixon_
+- [什麼是 Web 3.0,以及它為何重要](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _2019 年 12 月 31 日 - Max Mersch 和 Richard Muirhead_
+- [為什麼我們需要 Web 3.0](https://gavofyork.medium.com/why-we-need-web-3-0-5da4f2bf95ab) _2018 年 9 月 12 日 - Gavin Wood_
diff --git a/public/content/translations/zh-tw/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md b/public/content/translations/zh-tw/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md
new file mode 100644
index 00000000000..bfcf5860991
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md
@@ -0,0 +1,300 @@
+---
+title: 給 Python 開發者的以太坊介紹,第一部分
+description: 以太坊開發介紹,特別適合了解 Python 程式語言的開發人員。
+author: Marc Garreau
+lang: zh-tw
+tags: [ "python", "web3.py" ]
+skill: beginner
+published: 2020-09-08
+source: Snake charmers
+sourceUrl: https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/
+---
+
+所以,您已經聽說過以太坊,並準備好要深入探索了嗎? 本文將快速介紹一些區塊鏈基礎知識,然後讓您與一個模擬的以太坊節點互動——讀取區塊資料、檢查帳戶餘額以及傳送交易。 在此過程中,我們將強調傳統的應用程式建置方式與這種新的去中心化範式之間的差異。
+
+## (非強制)先決條件 {#soft-prerequisites}
+
+本文旨在讓廣大開發人員都能輕鬆理解。 [Python 工具](/developers/docs/programming-languages/python/)將會被使用,但它們只是用來傳達概念的載體——如果您不是 Python 開發人員也沒問題。 不過,我會先假設您已經具備一些基礎知識,這樣我們就可以快速進入以太坊專屬的部分。
+
+假設:
+
+- 您能夠操作終端機,
+- 您寫過幾行 Python 程式碼,
+- 您的電腦上已安裝 Python 3.6 或更高版本(強烈建議使用[虛擬環境](https://realpython.com/effective-python-environment/#virtual-environments)),以及
+- 您使用過 `pip`,Python 的套件安裝程式。
+ 再次強調,即使您不符合上述任何條件,或者不打算重現本文中的程式碼,您仍然可以順利地跟上進度。
+
+## 區塊鏈簡介 {#blockchains-briefly}
+
+描述以太坊的方式有很多種,但其核心是一個區塊鏈。 區塊鏈由一系列的區塊組成,所以讓我們從這裡開始。 簡單來說,以太坊區塊鏈上的每個區塊只包含一些元資料和一個交易列表。 在 JSON 格式中,它看起來像這樣:
+
+```json
+{
+ "number": 1234567,
+ "hash": "0xabc123...",
+ "parentHash": "0xdef456...",
+ ...,
+ "transactions": [...]
+}
+```
+
+每個[區塊](/developers/docs/blocks/)都包含對前一個區塊的引用;`parentHash` 就是前一個區塊的哈希。
+
+注意:以太坊經常使用哈希函數來產生固定大小的值(「哈希」)。 哈希在以太坊中扮演著重要角色,但目前您可以放心地將它們視為唯一的識別碼。
+
+
+
+_區塊鏈本質上是一個鏈結串列;每個區塊都包含對前一個區塊的引用。_
+
+這種資料結構本身並不是什麼新奇的東西,但管理網路的規則(即點對點協定)卻是全新的。 沒有中心化的權威機構;網路中的對等節點必須合作以維持網路運作,並透過競爭來決定下一個區塊要包含哪些交易。 所以,當您想寄錢給朋友時,您需要將該交易廣播到網路上,然後等待它被包含在即將產生的區塊中。
+
+區塊鏈要驗證金錢確實從一位使用者傳送給另一位使用者,唯一的方法是使用該區塊鏈的原生貨幣(即由該區塊鏈創造和管理的貨幣)。 在以太坊中,這種貨幣稱為以太幣 (ether),而以太坊區塊鏈是唯一包含帳戶餘額官方記錄的地方。
+
+## 新範式 {#a-new-paradigm}
+
+這個新的去中心化技術堆疊催生了新的開發者工具。 這類工具存在於許多程式語言中,但我們將從 Python 的角度來探討。 重申一次:即使 Python 不是您偏好的語言,跟上本文的內容應該也不會太困難。
+
+想要與以太坊互動的 Python 開發人員很可能會使用 [Web3.py](https://web3py.readthedocs.io/)。 Web3.py 是一個函式庫,它能大幅簡化您連接到以太坊節點,以及從節點傳送和接收資料的方式。
+
+注意:「以太坊節點」和「以太坊用戶端」這兩個詞可以互換使用。 無論是哪個詞,指的都是以太坊網路參與者執行的軟體。 這個軟體可以讀取區塊資料、在新區塊加入鏈上時接收更新、廣播新交易等等。 技術上來說,用戶端是軟體,節點是執行軟體的電腦。
+
+[以太坊用戶端](/developers/docs/nodes-and-clients/)可以設定為透過 [IPC](https://wikipedia.org/wiki/Inter-process_communication)、HTTP 或 Websocket 進行連線,因此 Web3.py 需要對應此設定。 Web3.py 將這些連線選項稱為**提供者**。 您需要從這三種提供者中選擇一種,將 Web3.py 執行個體與您的節點連結。
+
+
+
+_設定以太坊節點和 Web3.py 使用相同的協定進行通訊,例如此圖中的 IPC。_
+
+一旦 Web3.py 設定正確,您就可以開始與區塊鏈互動。 以下是一些 Web3.py 的使用範例,作為後續內容的預覽:
+
+```python
+# 讀取區塊資料:
+w3.eth.get_block('latest')
+
+# 傳送一筆交易:
+w3.eth.send_transaction({'from': ..., 'to': ..., 'value': ...})
+```
+
+## 安裝 {#installation}
+
+在這份逐步教學中,我們只會在 Python 直譯器中操作。 我們不會建立任何目錄、檔案、類別或函式。
+
+注意:在下面的範例中,以 `$` 開頭的指令是用於在終端機中執行的。 (請勿輸入 `$`,它只是表示一行的開始。)
+
+首先,安裝 [IPython](https://ipython.org/),這是一個方便探索的使用者友好環境。 IPython 提供了 tab 鍵自動完成等功能,讓您更容易了解 Web3.py 的各種可能性。
+
+```bash
+pip install ipython
+```
+
+Web3.py 是以 `web3` 的名稱發布的。 安裝方式如下:
+
+```bash
+pip install web3
+```
+
+還有一件事——我們稍後將模擬一個區塊鏈,這需要額外安裝幾個相依套件。 您可以透過以下方式安裝:
+
+```bash
+pip install 'web3[tester]'
+```
+
+您已準備就緒!
+
+注意:`web3[tester]` 套件支援到 Python 3.10.xx 版本。
+
+## 啟動沙箱 {#spin-up-a-sandbox}
+
+在終端機中執行 `ipython` 來開啟一個新的 Python 環境。 這和執行 `python` 類似,但提供了更多附加功能。
+
+```bash
+ipython
+```
+
+這會印出您正在執行的 Python 和 IPython 版本資訊,然後您會看到一個等待輸入的提示符號:
+
+```python
+In [1]:
+```
+
+您現在看到的是一個互動式 Python shell。 基本上,這是一個可以讓您盡情實驗的沙箱。 如果您已經進行到這一步,是時候匯入 Web3.py 了:
+
+```python
+In [1]: from web3 import Web3
+```
+
+## Web3 模組介紹 {#introducing-the-web3-module}
+
+除了作為通往以太坊的閘道,[Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) 模組還提供了一些便捷函式。 讓我們來探索其中幾個。
+
+在以太坊應用程式中,您通常需要轉換貨幣單位。 Web3 模組為此提供了幾個輔助方法:[from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei) 和 [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei)。
+
+
+注意:眾所周知,電腦不擅長處理小數運算。 為了解決這個問題,開發人員通常以「分」為單位來儲存美元金額。 例如,價格為 5.99 美元的商品在資料庫中可能會被儲存為 599。
+
+在處理以太幣交易時也使用類似的模式。 然而,以太幣不是兩位小數點,而是 18 位! 以太幣的最小單位稱為 wei,因此在傳送交易時指定的是這個數值。
+
+1 以太幣 = 1000000000000000000 wei
+
+1 wei = 0.000000000000000001 以太幣
+
+
+
+試著在 wei 與其他單位之間轉換一些數值。 請注意,在以太幣和 wei 之間[還有許多單位的名稱](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations)。 其中比較有名的是 **gwei**,因為交易費用通常用它來表示。
+
+```python
+In [2]: Web3.to_wei(1, 'ether')
+Out[2]: 1000000000000000000
+
+In [3]: Web3.from_wei(500000000, 'gwei')
+Out[3]: Decimal('0.5')
+```
+
+Web3 模組上的其他工具方法包括資料格式轉換器(例如 [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex))、位址輔助工具(例如 [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress))和哈希函數(例如 [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak))。 本系列文章的後續部分將會介紹其中許多內容。 若要查看所有可用的方法和屬性,可以輸入 `Web3` 來利用 IPython 的自動完成功能。 並在句點後按兩次 tab 鍵。
+
+## 與鏈互動 {#talk-to-the-chain}
+
+便捷方法很棒,但讓我們繼續來談談區塊鏈。 下一步是設定 Web3.py 與以太坊節點進行通訊。 在這裡,我們可以選擇使用 IPC、HTTP 或 Websocket 提供者。
+
+我們不會走這條路,但使用 HTTP 提供者的完整工作流程範例如下:
+
+- 下載一個以太坊節點,例如 [Geth](https://geth.ethereum.org/)。
+- 在一個終端機視窗中啟動 Geth,並等待它同步網路。 預設的 HTTP 連接埠是 `8545`,但可以自行設定。
+- 讓 Web3.py 透過 HTTP 連接到 `localhost:8545` 上的節點。
+ `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))`
+- 使用 `w3` 執行個體與節點互動。
+
+雖然這是一種「真實」的作法,但同步過程需要數小時,而且如果您只想要一個開發環境,這並非必要。 為此,Web3.py 提供了第四種提供者:**EthereumTesterProvider**。 這個測試提供者會連結到一個模擬的以太坊節點,它有較寬鬆的權限和可供使用的假貨幣。
+
+
+
+_EthereumTesterProvider 會連接到一個模擬節點,對於快速建立開發環境來說非常方便。_
+
+那個模擬節點稱為 [eth-tester](https://github.com/ethereum/eth-tester),我們在執行 `pip install web3[tester]` 指令時已經將它安裝。 設定 Web3.py 使用此測試提供者非常簡單:
+
+```python
+In [4]: w3 = Web3(Web3.EthereumTesterProvider())
+```
+
+現在您準備好在鏈上遨遊了! 這不是大家會說的話。 我剛才亂編的。 讓我們快速導覽一下。
+
+## 快速導覽 {#the-quick-tour}
+
+首先,做個基本功能檢查:
+
+```python
+In [5]: w3.is_connected()
+Out[5]: True
+```
+
+因為我們使用的是測試提供者,這個測試不是很有價值,但如果它失敗了,很可能是您在實例化 `w3` 變數時打錯了字。 再次檢查您是否包含了內層的括號,即 `Web3.EthereumTesterProvider()`。
+
+## 導覽第一站:[帳戶](/developers/docs/accounts/) {#tour-stop-1-accounts}
+
+為了方便,測試提供者建立了一些帳戶,並預先存入了測試以太幣。
+
+首先,讓我們看看這些帳戶的列表:
+
+```python
+In [6]: w3.eth.accounts
+Out[6]: ['0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf',
+ '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF',
+ '0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69', ...]
+```
+
+如果您執行這個指令,您應該會看到一個包含十個以 `0x` 開頭的字串列表。 每個都是一個**公開位址**,在某些方面,類似於支票帳戶的帳號。 您可以將此位址提供給想傳送以太幣給您的人。
+
+如前所述,測試提供者已為每個帳戶預先存入一些測試以太幣。 讓我們來看看第一個帳戶裡有多少錢:
+
+```python
+In [7]: w3.eth.get_balance(w3.eth.accounts[0])
+Out[7]: 1000000000000000000000000
+```
+
+好多個零! 在您笑著把錢存入假銀行之前,回想一下前面關於貨幣單位的課程。 以太幣的數值是以最小單位 wei 來表示的。 將它轉換成以太幣:
+
+```python
+In [8]: w3.from_wei(1000000000000000000000000, 'ether')
+Out[8]: Decimal('1000000')
+```
+
+一百萬測試以太幣——還不賴。
+
+## 導覽第二站:區塊資料 {#tour-stop-2-block-data}
+
+讓我們來看看這個模擬區塊鏈的狀態:
+
+```python
+In [9]: w3.eth.get_block('latest')
+Out[9]: AttributeDict({
+ 'number': 0,
+ 'hash': HexBytes('0x9469878...'),
+ 'parentHash': HexBytes('0x0000000...'),
+ ...
+ 'transactions': []
+})
+```
+
+一個區塊會傳回很多資訊,但這裡只指出幾點:
+
+- 區塊編號是零——無論您多久之前設定測試提供者都一樣。 與真實的以太坊網路每 12 秒新增一個新區塊不同,這個模擬會等到您給它一些工作才會有動作。
+- `transactions` 是一個空列表,原因相同:我們還沒有做任何事。 第一個區塊是**空區塊**,只是為了啟動這條鏈。
+- 請注意,`parentHash` 只是一堆空位元組。 這表示它是鏈中的第一個區塊,也稱為**創世區塊**。
+
+## 導覽第三站:[交易](/developers/docs/transactions/) {#tour-stop-3-transactions}
+
+在有待處理的交易之前,我們會一直停在區塊 0,所以讓我們來建立一筆交易。 從一個帳戶傳送幾枚測試以太幣到另一個帳戶:
+
+```python
+In [10]: tx_hash = w3.eth.send_transaction({
+ 'from': w3.eth.accounts[0],
+ 'to': w3.eth.accounts[1],
+ 'value': w3.to_wei(3, 'ether'),
+ 'gas': 21000
+})
+```
+
+通常這時候您需要等待幾秒鐘,讓您的交易被包含在新區塊中。 完整的過程大致如下:
+
+1. 提交一筆交易並保留交易哈希。 在包含該交易的區塊被建立和廣播之前,該交易是「待處理」狀態。
+ `tx_hash = w3.eth.send_transaction({ … })`
+2. 等待交易被包含在一個區塊中:
+ `w3.eth.wait_for_transaction_receipt(tx_hash)`
+3. 繼續執行應用程式邏輯。 查看成功的交易:
+ `w3.eth.get_transaction(tx_hash)`
+
+我們的模擬環境會立即將交易新增到新區塊中,因此我們可以立即查看該交易:
+
+```python
+In [11]: w3.eth.get_transaction(tx_hash)
+Out[11]: AttributeDict({
+ 'hash': HexBytes('0x15e9fb95dc39...'),
+ 'blockNumber': 1,
+ 'transactionIndex': 0,
+ 'from': '0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf',
+ 'to': '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF',
+ 'value': 3000000000000000000,
+ ...
+})
+```
+
+您會在這裡看到一些熟悉的詳細資訊:`from`、`to` 和 `value` 欄位應與我們 `send_transaction` 呼叫的輸入相符。 另一個讓人安心的地方是,這筆交易被包含在區塊編號 1 中,作為第一筆交易 (`'transactionIndex': 0`)。
+
+我們也可以透過檢查兩個相關帳戶的餘額來輕鬆驗證這筆交易是否成功。 三枚以太幣應該已經從一個帳戶轉移到另一個帳戶。
+
+```python
+In [12]: w3.eth.get_balance(w3.eth.accounts[0])
+Out[12]: 999996999979000000000000
+
+In [13]: w3.eth.get_balance(w3.eth.accounts[1])
+Out[13]: 1000003000000000000000000
+```
+
+後者看起來沒錯! 餘額從 1,000,000 以太幣增加到 1,000,003 以太幣。 但第一個帳戶發生了什麼事? 它似乎損失了比三枚以太幣多一點的金額。 唉,天下沒有白吃的午餐,使用以太坊公有網路需要您補償其他對等節點所提供的支援。 提交交易的帳戶被扣除了一筆小額交易費用——這筆費用是消耗的 gas 量(一次 ETH 轉帳為 21000 單位 gas)乘以根據網路活動變動的基本費用,再加上給予將交易包含在區塊中的驗證者的小費。
+
+更多關於 [gas](/developers/docs/gas/#post-london) 的資訊
+
+注意:在公有網路上,交易費用會根據網路需求以及您希望交易處理的速度而變動。 如果您對費用計算的詳細說明感興趣,請參閱我之前關於交易如何被包含在區塊中的文章。
+
+## 喘口氣 {#and-breathe}
+
+我們已經進行了一段時間,這裡似乎是個休息的好時機。 兔子洞還很深,我們將在本系列的第二部分繼續探索。 即將介紹的概念:連接到真實節點、智慧合約和代幣。 還有其他問題嗎? 讓我知道! 您的回饋將影響我們接下來的方向。 歡迎透過 [Twitter](https://twitter.com/wolovim) 提出請求。
diff --git a/public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md
new file mode 100644
index 00000000000..9c09d9b0e2d
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md
@@ -0,0 +1,864 @@
+---
+title: "任你快取"
+description: 學習如何創建和使用快取合約,以降低卷軸交易的成本
+author: 作者:Ori Pomerantz
+tags: [ "Layer 2", "快取", "儲存" ]
+skill: intermediate
+published: 2022-09-15
+lang: zh-tw
+---
+
+使用卷軸時,交易中一個位元組的成本遠高於一個儲存時隙的成本。 因此,盡可能在鏈上快取資訊是合理的。
+
+在本文中,您將學習如何創建和使用快取合約,讓任何可能被多次使用的參數值都被快取,並在(首次使用後)能以更少的位元組來取用,以及如何撰寫使用此快取的鏈外程式碼。
+
+如果您想跳過文章,直接查看原始程式碼,[請點擊這裡](https://github.com/qbzzt/20220915-all-you-can-cache)。 開發堆疊為 [Foundry](https://getfoundry.sh/introduction/installation/)。
+
+## 總體設計 {#overall-design}
+
+為求簡單,我們假設所有交易參數都是 `uint256`,長度為 32 位元組。 當我們收到一筆交易時,我們會像這樣解析每個參數:
+
+1. 如果第一個位元組是 `0xFF`,則將接下來的 32 個位元組作為參數值並寫入快取。
+
+2. 如果第一個位元組是 `0xFE`,則將接下來的 32 個位元組作為參數值,但_不_寫入快取。
+
+3. 對於任何其他值,將前四個位元作為附加位元組的數量,後四個位元作為快取鍵的最高有效位。 下面有些範例:
+
+ | calldata 中的位元組 | 快取鍵 |
+ | :-------------- | -------: |
+ | 0x0F | 0x0F |
+ | 0x10,0x10 | 0x10 |
+ | 0x12,0xAC | 0x02AC |
+ | 0x2D,0xEA, 0xD6 | 0x0DEAD6 |
+
+## 快取操作 {#cache-manipulation}
+
+快取在 [`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol) 中實現。 讓我們逐行檢視它。
+
+```solidity
+// SPDX-License-Identifier: UNLICENSED
+pragma solidity ^0.8.13;
+
+
+contract Cache {
+
+ bytes1 public constant INTO_CACHE = 0xFF;
+ bytes1 public constant DONT_CACHE = 0xFE;
+```
+
+這些常數用於解釋特殊情況,即我們提供所有資訊,並選擇是否要將其寫入快取。 寫入快取需要對先前未使用的儲存時隙進行兩次 [`SSTORE`](https://www.evm.codes/#55) 操作,每次成本為 22100 Gas,因此我們將其設為可選。
+
+```solidity
+
+ mapping(uint => uint) public val2key;
+```
+
+值與其鍵之間的 [映射](https://www.geeksforgeeks.org/solidity/solidity-mappings/)。 在您送出交易之前,此資訊是編碼值所必需的。
+
+```solidity
+ // 位置 n 儲存鍵 n+1 的值,因為我們需要保留
+ // 零作為「不在快取中」的標記。
+ uint[] public key2val;
+```
+
+我們可以使用陣列來進行從鍵到值的映射,因為我們是自己指派鍵,而且為求簡單,我們會循序指派。
+
+```solidity
+ function cacheRead(uint _key) public view returns (uint) {
+ require(_key <= key2val.length, "Reading uninitialize cache entry");
+ return key2val[_key-1];
+ } // cacheRead
+```
+
+從快取中讀取一個值。
+
+```solidity
+ // 如果快取中尚無此值,則將其寫入
+ // 設為 public 僅為了讓測試能運作
+ function cacheWrite(uint _value) public returns (uint) {
+ // 如果該值已在快取中,則回傳目前的鍵
+ if (val2key[_value] != 0) {
+ return val2key[_value];
+ }
+```
+
+將相同的值多次放入快取中是沒有意義的。 如果值已經存在,只需回傳現有的鍵即可。
+
+```solidity
+ // 因為 0xFE 是特殊情況,所以快取能容納的最大鍵
+ // 是 0x0D 後面跟著 15 個 0xFF。如果快取長度已達
+ // 這麼大,就失敗。
+ // 1 2 3 4 5 6 7 8 9 A B C D E F
+ require(key2val.length+1 < 0x0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF,
+ "cache overflow");
+```
+
+我不認為我們會有這麼大的快取 (約 1.8\*1037 個項目,需要約 1027 TB 來儲存)。 然而,我的年紀足以記得 ["640kB 永遠夠用"](https://quoteinvestigator.com/2011/09/08/640k-enough/)這句話。 這個測試的成本非常低。
+
+```solidity
+ // 使用下一個鍵寫入值
+ val2key[_value] = key2val.length+1;
+```
+
+新增反向查找 (從值到鍵)。
+
+```solidity
+ key2val.push(_value);
+```
+
+新增正向查找 (從鍵到值)。 因為我們是循序指派值,所以可以直接將其加在陣列最後一個值的後面。
+
+```solidity
+ return key2val.length;
+ } // cacheWrite
+```
+
+回傳 `key2val` 的新長度,也就是新值儲存的儲存格。
+
+```solidity
+ function _calldataVal(uint startByte, uint length)
+ private pure returns (uint)
+```
+
+此函數從 calldata 讀取任意長度 (最多 32 位元組,即一個字組的大小) 的值。
+
+```solidity
+ {
+ uint _retVal;
+
+ require(length < 0x21,
+ "_calldataVal length limit is 32 bytes");
+ require(length + startByte <= msg.data.length,
+ "_calldataVal trying to read beyond calldatasize");
+```
+
+這個函數是內部的,所以如果其餘的程式碼都撰寫正確,這些測試就不是必需的。 不過,它們的成本不高,所以不妨保留。
+
+```solidity
+ assembly {
+ _retVal := calldataload(startByte)
+ }
+```
+
+此程式碼使用 [Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html) 撰寫。 它從 calldata 讀取一個 32 位元組的值。 即使 calldata 在 `startByte+32` 之前就結束了,這段程式碼也能運作,因為 EVM 中未初始化的空間會被視為零。
+
+```solidity
+ _retVal = _retVal >> (256-length*8);
+```
+
+我們不一定需要一個 32 位元組的值。 這會移除多餘的位元組。
+
+```solidity
+ return _retVal;
+ } // _calldataVal
+
+
+ // 從 calldata 讀取單一參數,從 _fromByte 開始
+ function _readParam(uint _fromByte) internal
+ returns (uint _nextByte, uint _parameterValue)
+ {
+```
+
+從 calldata 讀取單一參數。 請注意,我們不僅需要回傳讀取的值,還需要回傳下一個位元組的位置,因為參數的長度可能從 1 位元組到 33 位元組不等。
+
+```solidity
+ // 第一個位元組告訴我們如何解釋其餘的部分
+ uint8 _firstByte;
+
+ _firstByte = uint8(_calldataVal(_fromByte, 1));
+```
+
+Solidity 藉由禁止潛在危險的[隱含類型轉換](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions),試圖減少錯誤的數量。 降級,例如從 256 位元降到 8 位元,需要明確指定。
+
+```solidity
+
+ // 讀取值,但不寫入快取
+ if (_firstByte == uint8(DONT_CACHE))
+ return(_fromByte+33, _calldataVal(_fromByte+1, 32));
+
+ // 讀取值,並將其寫入快取
+ if (_firstByte == uint8(INTO_CACHE)) {
+ uint _param = _calldataVal(_fromByte+1, 32);
+ cacheWrite(_param);
+ return(_fromByte+33, _param);
+ }
+
+ // 如果執行到這裡,表示我們需要從快取中讀取
+
+ // 要讀取的額外位元組數
+ uint8 _extraBytes = _firstByte / 16;
+```
+
+取較低的[半位元組 (nibble)](https://en.wikipedia.org/wiki/Nibble) 並將其與其他位元組組合,以從快取中讀取值。
+
+```solidity
+ uint _key = (uint256(_firstByte & 0x0F) << (8*_extraBytes)) +
+ _calldataVal(_fromByte+1, _extraBytes);
+
+ return (_fromByte+_extraBytes+1, cacheRead(_key));
+
+ } // _readParam
+
+
+ // 讀取 n 個參數 (函數知道它們預期有多少個參數)
+ function _readParams(uint _paramNum) internal returns (uint[] memory) {
+```
+
+我們可以從 calldata 本身取得參數數量,但是呼叫我們的函數知道它們預期有多少個參數。 讓它們告訴我們比較容易。
+
+```solidity
+ // 我們讀取的參數
+ uint[] memory params = new uint[](_paramNum);
+
+ // 參數從第 4 個位元組開始,之前是函數簽章
+ uint _atByte = 4;
+
+ for(uint i=0; i<_paramNum; i++) {
+ (_atByte, params[i]) = _readParam(_atByte);
+ }
+```
+
+讀取參數,直到您取得所需的數量。 如果我們超出 calldata 的結尾,`_readParams` 將會還原呼叫。
+
+```solidity
+
+ return(params);
+ } // readParams
+
+ // 用於測試 _readParams,測試讀取四個參數
+ function fourParam() public
+ returns (uint256,uint256,uint256,uint256)
+ {
+ uint[] memory params;
+ params = _readParams(4);
+ return (params[0], params[1], params[2], params[3]);
+ } // fourParam
+```
+
+Foundry 的一個大優點是它允許用 Solidity 撰寫測試 ([見下文的測試快取](#testing-the-cache))。 這讓單元測試變得容易得多。 這是一個讀取四個參數並回傳它們的函數,以便測試可以驗證它們是否正確。
+
+```solidity
+ // 取得一個值,回傳將其編碼的位元組 (如果可能,使用快取)
+ function encodeVal(uint _val) public view returns(bytes memory) {
+```
+
+`encodeVal` 是一個由鏈外程式碼呼叫的函數,用來幫助創建使用快取的 calldata。 它接收單一值並回傳對其編碼的位元組。 此函數是 `view` 函數,所以不需要交易,且從外部呼叫時不消耗任何 Gas。
+
+```solidity
+ uint _key = val2key[_val];
+
+ // 該值尚不在快取中,將其加入
+ if (_key == 0)
+ return bytes.concat(INTO_CACHE, bytes32(_val));
+```
+
+在 [EVM](/developers/docs/evm/) 中,所有未初始化的儲存空間都假設為零。 所以,如果我們查找一個不存在的值的鍵,我們會得到零。 在這種情況下,編碼它的位元組是 `INTO_CACHE` (這樣下次就會被快取),後面跟著實際的值。
+
+```solidity
+ // 如果鍵 <0x10,則以單一位元組回傳
+ if (_key < 0x10)
+ return bytes.concat(bytes1(uint8(_key)));
+```
+
+單一位元組是最簡單的。 我們只需使用 [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat) 將 `bytes` 類型轉換為任意長度的位元組陣列。 儘管有這個名稱,但當只提供一個參數時,它也能正常運作。
+
+```solidity
+ // 兩位元組值,編碼為 0x1vvv
+ if (_key < 0x1000)
+ return bytes.concat(bytes2(uint16(_key) | 0x1000));
+```
+
+當我們的鍵小於 163 時,我們可以用兩個位元組來表示它。 我們首先將 256 位元值的 `_key` 轉換為 16 位元值,並使用邏輯「或」將額外位元組的數量加到第一個位元組上。 然後我們將其轉換為 `bytes2` 值,該值可以轉換為 `bytes`。
+
+```solidity
+ // 可能有更聰明的方法以迴圈方式處理以下幾行,
+ // 但這是一個 view 函數,所以我為了節省程式員時間和簡化而進行優化。
+
+ if (_key < 16*256**2)
+ return bytes.concat(bytes3(uint24(_key) | (0x2 * 16 * 256**2)));
+ if (_key < 16*256**3)
+ return bytes.concat(bytes4(uint32(_key) | (0x3 * 16 * 256**3)));
+ .
+ .
+ .
+ if (_key < 16*256**14)
+ return bytes.concat(bytes15(uint120(_key) | (0xE * 16 * 256**14)));
+ if (_key < 16*256**15)
+ return bytes.concat(bytes16(uint128(_key) | (0xF * 16 * 256**15)));
+```
+
+其他值 (3 位元組、4 位元組等) 以相同的方式處理,只是欄位大小不同。
+
+```solidity
+ // 如果執行到這裡,表示出了問題。
+ revert("Error in encodeVal, should not happen");
+```
+
+如果我們執行到這裡,表示我們得到了一個不小於 16\*25615 的鍵。 但是 `cacheWrite` 限制了鍵的範圍,所以我們甚至無法達到 14\*25616 (其第一個位元組會是 0xFE,看起來就像 `DONT_CACHE`)。 但是,為了防止未來的程式員引入錯誤,增加一個測試並不會花費太多成本。
+
+```solidity
+ } // encodeVal
+
+} // Cache
+```
+
+### 測試快取 {#testing-the-cache}
+
+Foundry 的優點之一是 [它允許您用 Solidity 撰寫測試](https://getfoundry.sh/forge/tests/overview/),這讓撰寫單元測試變得更容易。 `Cache` 類別的測試在[這裡](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol)。 因為測試程式碼通常是重複的,所以本文只解釋有趣的部分。
+
+```solidity
+// SPDX-License-Identifier: UNLICENSED
+pragma solidity ^0.8.13;
+
+import "forge-std/Test.sol";
+
+
+// 需要執行 `forge test -vv` 才能使用主控台。
+import "forge-std/console.sol";
+```
+
+這只是使用測試套件和 `console.log` 所需的樣板程式碼。
+
+```solidity
+import "src/Cache.sol";
+```
+
+我們需要知道我們正在測試的合約。
+
+```solidity
+contract CacheTest is Test {
+ Cache cache;
+
+ function setUp() public {
+ cache = new Cache();
+ }
+```
+
+`setUp` 函數在每次測試前被呼叫。 在這種情況下,我們只是創建一個新的快取,這樣我們的測試就不會互相影響。
+
+```solidity
+ function testCaching() public {
+```
+
+測試是以 `test` 開頭的函數。 此函數檢查基本的快取功能,即寫入值並再次讀取它們。
+
+```solidity
+ for(uint i=1; i<5000; i++) {
+ cache.cacheWrite(i*i);
+ }
+
+ for(uint i=1; i<5000; i++) {
+ assertEq(cache.cacheRead(i), i*i);
+```
+
+這就是您如何使用 [`assert...` 函數](https://getfoundry.sh/reference/forge-std/std-assertions/) 進行實際測試的方式。 在這種情況下,我們檢查我們寫入的值是否與我們讀取的值相同。 我們可以捨棄 `cache.cacheWrite` 的結果,因為我們知道快取鍵是線性指派的。
+
+```solidity
+ }
+ } // testCaching
+
+
+ // 將相同的值多次快取,確保鍵保持不變
+ // the same
+ function testRepeatCaching() public {
+ for(uint i=1; i<100; i++) {
+ uint _key1 = cache.cacheWrite(i);
+ uint _key2 = cache.cacheWrite(i);
+ assertEq(_key1, _key2);
+ }
+```
+
+首先,我們將每個值寫入快取兩次,並確保鍵是相同的 (表示第二次寫入沒有真正發生)。
+
+```solidity
+ for(uint i=1; i<100; i+=3) {
+ uint _key = cache.cacheWrite(i);
+ assertEq(_key, i);
+ }
+ } // testRepeatCaching
+```
+
+理論上,可能存在一個不影響連續快取寫入的錯誤。 所以這裡我們做一些非連續的寫入,看看值是否仍然沒有被重寫。
+
+```solidity
+ // 從記憶體緩衝區讀取 uint (以確保我們取回我們送出的參數)
+ function toUint256(bytes memory _bytes, uint256 _start) internal pure
+ returns (uint256)
+```
+
+從 `bytes memory` 緩衝區讀取一個 256 位元字組。 這個實用功能快鍵讓我們可以驗證當我們執行使用快取的函數呼叫時,是否收到正確的結果。
+
+```solidity
+ {
+ require(_bytes.length >= _start + 32, "toUint256_outOfBounds");
+ uint256 tempUint;
+
+ assembly {
+ tempUint := mload(add(add(_bytes, 0x20), _start))
+ }
+```
+
+Yul 不支援 `uint256` 以外的數據結構,所以當您引用更複雜的數據結構時,例如記憶體緩衝區 `_bytes`,您會得到該結構的地址。 Solidity 將 `bytes memory` 值儲存為一個 32 位元組字組,其中包含長度,後面跟著實際的位元組,所以要取得位元組編號 `_start`,我們需要計算 `_bytes+32+_start`。
+
+```solidity
+
+ return tempUint;
+ } // toUint256
+
+ // fourParams() 的函數簽章,由
+ // https://www.4byte.directory/signatures/?bytes4_signature=0x3edc1e6d 提供
+ bytes4 constant FOUR_PARAMS = 0x3edc1e6d;
+
+ // 只是一些常數值,用來查看我們是否取回正確的值
+ uint256 constant VAL_A = 0xDEAD60A7;
+ uint256 constant VAL_B = 0xBEEF;
+ uint256 constant VAL_C = 0x600D;
+ uint256 constant VAL_D = 0x600D60A7;
+```
+
+一些我們測試所需的常數。
+
+```solidity
+ function testReadParam() public {
+```
+
+呼叫 `fourParams()`,一個使用 `readParams` 的函數,來測試我們是否能正確讀取參數。
+
+```solidity
+ address _cacheAddr = address(cache);
+ bool _success;
+ bytes memory _callInput;
+ bytes memory _callOutput;
+```
+
+我們不能使用正常的 ABI 機制來呼叫使用快取的函數,所以我們需要使用低階的 [`.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses) 機制。 該機制接受一個 `bytes memory` 作為輸入,並回傳它 (以及一個布林值) 作為輸出。
+
+```solidity
+ // 第一次呼叫,快取是空的
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+```
+
+讓同一個合約同時支援快取函數 (用於直接從交易呼叫) 和非快取函數 (用於從其他智能合約呼叫) 是很有用的。 為此,我們需要繼續依賴 Solidity 的機制來呼叫正確的函數,而不是將所有東西都放在[一個 `fallback` 函數](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function)中。 這樣做使得可組合性變得容易得多。 在大多數情況下,單一位元組就足以識別函數,所以我們浪費了三個位元組 (16\*3=48 Gas)。 然而,在我寫這篇文章的時候,那 48 Gas 的成本是 0.07 美分,對於更簡單、更少錯誤的程式碼來說,這是一個合理的成本。
+
+```solidity
+ // 第一個值,將它加入快取
+ cache.INTO_CACHE(),
+ bytes32(VAL_A),
+```
+
+第一個值:一個旗標,表示這是一個需要寫入快取的完整值,後面跟著值的 32 個位元組。 其他三個值是相似的,除了 `VAL_B` 沒有寫入快取,而 `VAL_C` 既是第三個參數也是第四個參數。
+
+```solidity
+ .
+ .
+ .
+ );
+ (_success, _callOutput) = _cacheAddr.call(_callInput);
+```
+
+這就是我們實際呼叫 `Cache` 合約的地方。
+
+```solidity
+ assertEq(_success, true);
+```
+
+我們預期呼叫會成功。
+
+```solidity
+ assertEq(cache.cacheRead(1), VAL_A);
+ assertEq(cache.cacheRead(2), VAL_C);
+```
+
+我們從一個空的快取開始,然後加入 `VAL_A`,接著是 `VAL_C`。 我們預期第一個的鍵是 1,第二個是 2。
+
+```
+ assertEq(toUint256(_callOutput,0), VAL_A);
+ assertEq(toUint256(_callOutput,32), VAL_B);
+ assertEq(toUint256(_callOutput,64), VAL_C);
+ assertEq(toUint256(_callOutput,96), VAL_C);
+```
+
+輸出是四個參數。 這裡我們驗證它是正確的。
+
+```solidity
+ // 第二次呼叫,我們可以使用快取
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+
+ // 快取中的第一個值
+ bytes1(0x01),
+```
+
+小於 16 的快取鍵只有一個位元組。
+
+```solidity
+ // 第二個值,不要將它加入快取
+ cache.DONT_CACHE(),
+ bytes32(VAL_B),
+
+ // 第三和第四個值,相同的值
+ bytes1(0x02),
+ bytes1(0x02)
+ );
+ .
+ .
+ .
+ } // testReadParam
+```
+
+呼叫後的測試與第一次呼叫後的測試相同。
+
+```solidity
+ function testEncodeVal() public {
+```
+
+這個函數與 `testReadParam` 相似,只是我們不顯式地寫入參數,而是使用 `encodeVal()`。
+
+```solidity
+ .
+ .
+ .
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+ cache.encodeVal(VAL_A),
+ cache.encodeVal(VAL_B),
+ cache.encodeVal(VAL_C),
+ cache.encodeVal(VAL_D)
+ );
+ .
+ .
+ .
+ assertEq(_callInput.length, 4+1*4);
+ } // testEncodeVal
+```
+
+在 `testEncodeVal()` 中唯一的額外測試是驗證 `_callInput` 的長度是否正確。 對於第一次呼叫,它是 4+33\*4。 對於第二次,其中每個值都已在快取中,它是 4+1\*4。
+
+```solidity
+ // 當鍵超過一個位元組時測試 encodeVal
+ // 最多三個位元組,因為填滿快取到四個位元組需要太長時間。
+ function testEncodeValBig() public {
+ // 將一些值放入快取。
+ // 為保持簡單,對值 n 使用鍵 n。
+ for(uint i=1; i<0x1FFF; i++) {
+ cache.cacheWrite(i);
+ }
+```
+
+上面的 `testEncodeVal` 函數只向快取中寫入四個值,因此 [處理多位元組值的函數部分](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171) 沒有被檢查到。 但那段程式碼很複雜且容易出錯。
+
+這個函數的第一部分是一個迴圈,它按順序將從 1 到 0x1FFF 的所有值寫入快取,這樣我們就能夠編碼這些值並知道它們的位置。
+
+```solidity
+ .
+ .
+ .
+
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+ cache.encodeVal(0x000F), // 一個位元組 0x0F
+ cache.encodeVal(0x0010), // 兩個位元組 0x1010
+ cache.encodeVal(0x0100), // 兩個位元組 0x1100
+ cache.encodeVal(0x1000) // 三個位元組 0x201000
+ );
+```
+
+測試一個位元組、兩個位元組和三個位元組的值。 我們沒有測試超過這個範圍,因為寫入足夠多的堆疊項目 (至少 0x10000000,大約二十五億) 會花費太長時間。
+
+```solidity
+ .
+ .
+ .
+ .
+ } // testEncodeValBig
+
+
+ // 測試當緩衝區過小時,我們會得到一個 revert
+ function testShortCalldata() public {
+```
+
+測試在參數不足的異常情況下會發生什麼。
+
+```solidity
+ .
+ .
+ .
+ (_success, _callOutput) = _cacheAddr.call(_callInput);
+ assertEq(_success, false);
+ } // testShortCalldata
+```
+
+由於它會還原,我們應該得到的結果是 `false`。
+
+```
+ // 使用不存在的快取鍵呼叫
+ function testNoCacheKey() public {
+ .
+ .
+ .
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+
+ // 第一個值,將它加入快取
+ cache.INTO_CACHE(),
+ bytes32(VAL_A),
+
+ // 第二個值
+ bytes1(0x0F),
+ bytes2(0x1234),
+ bytes11(0xA10102030405060708090A)
+ );
+```
+
+這個函數得到四個完全合法的參數,但快取是空的,所以沒有值可以讀取。
+
+```solidity
+ .
+ .
+ .
+ // 測試當緩衝區過長時一切都能正常運作
+ function testLongCalldata() public {
+ address _cacheAddr = address(cache);
+ bool _success;
+ bytes memory _callInput;
+ bytes memory _callOutput;
+
+ // 第一次呼叫,快取是空的
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+
+ // 第一個值,將它加入快取
+ cache.INTO_CACHE(), bytes32(VAL_A),
+
+ // 第二個值,將它加入快取
+ cache.INTO_CACHE(), bytes32(VAL_B),
+
+ // 第三個值,將它加入快取
+ cache.INTO_CACHE(), bytes32(VAL_C),
+
+ // 第四個值,將它加入快取
+ cache.INTO_CACHE(), bytes32(VAL_D),
+
+ // 再加上一個值來「祝好運」
+ bytes4(0x31112233)
+ );
+```
+
+此函數傳送五個值。 我們知道第五個值被忽略了,因為它不是一個有效的快取項目,如果它被包含進去,就會導致還原。
+
+```solidity
+ (_success, _callOutput) = _cacheAddr.call(_callInput);
+ assertEq(_success, true);
+ .
+ .
+ .
+ } // testLongCalldata
+
+} // CacheTest
+
+```
+
+## 一個範例應用程式 {#a-sample-app}
+
+用 Solidity 寫測試固然很好,但終究去中心化應用程式需要能夠處理來自鏈外的請求才能派上用場。 本文示範如何在一個名為 `WORM` (意指「寫一次,讀多次」) 的去中心化應用程式中使用快取。 如果一個鍵尚未寫入,您可以將一個值寫入其中。 如果鍵已經寫入,您會得到一個還原。
+
+### 合約 {#the-contract}
+
+[這是合約](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol)。 它大部分重複了我們已經用 `Cache` 和 `CacheTest` 做過的事情,所以我們只涵蓋有趣的部分。
+
+```solidity
+import "./Cache.sol";
+
+contract WORM is Cache {
+```
+
+使用 `Cache` 最簡單的方法是在我們自己的合約中繼承它。
+
+```solidity
+ function writeEntryCached() external {
+ uint[] memory params = _readParams(2);
+ writeEntry(params[0], params[1]);
+ } // writeEntryCached
+```
+
+這個函數與上面 `CacheTest` 中的 `fourParam` 相似。 因為我們不遵循 ABI 規範,最好不要在函數中聲明任何參數。
+
+```solidity
+ // 讓我們更容易被呼叫
+ // writeEntryCached() 的函數簽章,由
+ // https://www.4byte.directory/signatures/?bytes4_signature=0xe4e4f2d3 提供
+ bytes4 constant public WRITE_ENTRY_CACHED = 0xe4e4f2d3;
+```
+
+呼叫 `writeEntryCached` 的外部程式碼將需要手動建構 calldata,而不是使用 `worm.writeEntryCached`,因為我們不遵循 ABI 規範。 有這個常數值只是為了讓撰寫更容易。
+
+請注意,即使我們將 `WRITE_ENTRY_CACHED` 定義為狀態變數,要從外部讀取它,也必須使用它的 getter 函數,即 `worm.WRITE_ENTRY_CACHED()`。
+
+```solidity
+ function readEntry(uint key) public view
+ returns (uint _value, address _writtenBy, uint _writtenAtBlock)
+```
+
+讀取函數是 `view` 函數,所以它不需要交易,也不消耗 Gas。 因此,對參數使用快取沒有任何好處。 對於 view 函數,最好使用更簡單的標準機制。
+
+### 測試程式碼 {#the-testing-code}
+
+[這是合約的測試程式碼](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol)。 同樣,我們只看有趣的部分。
+
+```solidity
+ function testWReadWrite() public {
+ worm.writeEntry(0xDEAD, 0x60A7);
+
+ vm.expectRevert(bytes("entry already written"));
+ worm.writeEntry(0xDEAD, 0xBEEF);
+```
+
+[這個 (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert) 是我們在 Foundry 測試中指定下一個呼叫應該失敗,以及失敗報告原因的方式。 這適用於我們使用語法 `.()` 而不是建構 calldata 並使用低階介面 (`.call()` 等) 呼叫合約的情況。
+
+```solidity
+ function testReadWriteCached() public {
+ uint cacheGoat = worm.cacheWrite(0x60A7);
+```
+
+這裡我們利用 `cacheWrite` 回傳快取鍵的特性。 這不是我們期望在生產環境中使用的,因為 `cacheWrite` 會改變狀態,因此只能在交易中呼叫。 交易沒有回傳值,如果它們有結果,這些結果應該以事件的形式發出。 所以 `cacheWrite` 的回傳值只能從鏈上程式碼存取,而鏈上程式碼不需要參數快取。
+
+```solidity
+ (_success,) = address(worm).call(_callInput);
+```
+
+這就是我們告訴 Solidity,雖然 `.call()` 有兩個回傳值,但我們只關心第一個。
+
+```solidity
+ (_success,) = address(worm).call(_callInput);
+ assertEq(_success, false);
+```
+
+因為我們使用低階的 `.call()` 函數,所以不能使用 `vm.expectRevert()`,而必須查看從呼叫中得到的布林成功值。
+
+```solidity
+ event EntryWritten(uint indexed key, uint indexed value);
+
+ .
+ .
+ .
+
+ _callInput = bytes.concat(
+ worm.WRITE_ENTRY_CACHED(), worm.encodeVal(a), worm.encodeVal(b));
+ vm.expectEmit(true, true, false, false);
+ emit EntryWritten(a, b);
+ (_success,) = address(worm).call(_callInput);
+```
+
+這是在 Foundry 中驗證程式碼 [正確發出事件](https://getfoundry.sh/reference/cheatcodes/expect-emit/) 的方式。
+
+### 用戶端 {#the-client}
+
+用 Solidity 測試得不到的一件事,就是可以複製貼上到您自己應用程式中的 JavaScript 程式碼。 為了撰寫這段程式碼,我將 WORM 部署到了 [Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli),這是 [Optimism](https://www.optimism.io/) 的新測試網。 它的地址是 [`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a)。
+
+[您可以在這裡看到用戶端的 JavaScript 程式碼](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js)。 如何使用它:
+
+1. 複製 git 儲存庫:
+
+ ```sh
+ git clone https://github.com/qbzzt/20220915-all-you-can-cache.git
+ ```
+
+2. 安裝必要的套件:
+
+ ```sh
+ cd javascript
+ yarn
+ ```
+
+3. 複製設定檔:
+
+ ```sh
+ cp .env.example .env
+ ```
+
+4. 編輯 `.env` 以符合您的設定:
+
+ | 參數 | 數值 |
+ | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
+ | MNEMONIC | 一個擁有足夠 ETH 支付交易費用的帳戶的助記詞。 [您可以在這裡免費獲得 Optimism Goerli 網路的 ETH](https://optimismfaucet.xyz/)。 |
+ | OPTIMISM_GOERLI_URL | Optimism Goerli 的 URL。 公共端點 `https://goerli.optimism.io` 有速率限制,但足以滿足我們在這裡的需求 |
+
+5. 執行 `index.js`。
+
+ ```sh
+ node index.js
+ ```
+
+ 這個範例應用程式首先向 WORM 寫入一個項目,顯示 calldata 和 Etherscan 上交易的連結。 然後它會讀回該項目,並顯示它使用的鍵以及項目中的值 (值、區塊號和作者)。
+
+用戶端大部分是正常的去中心化應用程式 JavaScript。 所以我們同樣只會看有趣的部分。
+
+```javascript
+.
+.
+.
+const main = async () => {
+ const func = await worm.WRITE_ENTRY_CACHED()
+
+ // 每次都需要一個新的鍵
+ const key = await worm.encodeVal(Number(new Date()))
+```
+
+一個給定的時隙只能寫入一次,所以我們使用時間戳來確保我們不會重複使用時隙。
+
+```javascript
+const val = await worm.encodeVal("0x600D")
+
+// 寫入一個項目
+const calldata = func + key.slice(2) + val.slice(2)
+```
+
+Ethers 期望呼叫資料是一個十六進制字串,即 `0x` 後面跟著偶數個十六進制數字。 由於 `key` 和 `val` 都以 `0x` 開頭,我們需要移除這些標頭。
+
+```javascript
+const tx = await worm.populateTransaction.writeEntryCached()
+tx.data = calldata
+
+sentTx = await wallet.sendTransaction(tx)
+```
+
+與 Solidity 測試程式碼一樣,我們不能正常呼叫快取函數。 相反,我們需要使用更低階的機制。
+
+```javascript
+ .
+ .
+ .
+ // 讀取剛寫入的項目
+ const realKey = '0x' + key.slice(4) // 移除 FF 旗標
+ const entryRead = await worm.readEntry(realKey)
+ .
+ .
+ .
+```
+
+對於讀取項目,我們可以使用正常的機制。 對於 `view` 函數,不需要使用參數快取。
+
+## 結論 {#conclusion}
+
+本文中的程式碼是一個概念驗證,目的是讓這個想法更容易理解。 對於一個生產就緒的系統,您可能需要實現一些額外的功能:
+
+- 處理非 `uint256` 的值。 例如,字串。
+- 與其使用全域快取,或許可以建立使用者與快取之間的映射。 不同的使用者使用不同的值。
+- 用於地址的值與用於其他目的的值是不同的。 單獨為地址建立一個快取可能是有意義的。
+- 目前,快取鍵採用「先到先得,鍵值最小」的演算法。 前十六個值可以作為單一位元組傳送。 接下來的 4080 個值可以作為兩個位元組傳送。 接下來大約一百萬個值是三個位元組,依此類推。 一個生產系統應該對快取項目保留使用計數器,並重新組織它們,以便十六個_最常用_的值是一個位元組,接下來的 4080 個最常用值是兩個位元組,依此類推。
+
+ 然而,這是一個潛在危險的操作。 想像以下事件序列:
+
+ 1. 天真的諾姆 (Noam Naive) 呼叫 `encodeVal` 來編碼他想傳送代幣的地址。 該地址是應用程式上最早使用的地址之一,所以編碼後的值是 0x06。 這是一個 `view` 函數,不是一個交易,所以它只發生在諾姆和他使用的節點之間,沒有其他人知道。
+
+ 2. 擁有者歐文 (Owen Owner) 執行快取重新排序操作。 很少有人真正使用那個地址,所以它現在被編碼為 0x201122。 一個不同的值,1018,被指派為 0x06。
+
+ 3. 天真的諾姆將他的代幣傳送到 0x06。 它們被送到地址 `0x0000000000000000000000000de0b6b3a7640000`,而且由於沒有人知道該地址的私密金鑰,它們就卡在那裡了。 諾姆_非常不開心_。
+
+ 有辦法解決這個問題,以及在快取重新排序期間交易在記憶體池中的相關問題,但您必須意識到這一點。
+
+我在這裡用 Optimism 來示範快取,因為我是 Optimism 的員工,這是我最了解的 rollup。 但它應該適用於任何對內部處理收取最低成本的 rollup,這樣相比之下,將交易資料寫入 L1 就成了主要開銷。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
+
diff --git a/public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md b/public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md
new file mode 100644
index 00000000000..f503376a363
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md
@@ -0,0 +1,1255 @@
+---
+title: 編寫一個保護隱私的特定應用程式 plasma
+description: 在本使用教學中,我們將為存款建立一個半祕密的銀行。 此銀行為中心化元件;它知道每位使用者的餘額。 然而,此資訊不會儲存在鏈上。 銀行會改為張貼狀態的雜湊值。 每當交易發生時,銀行就會張貼新的雜湊值,以及證明其擁有將雜湊狀態變更為新狀態的簽署交易之零知識證明。 閱讀本使用教學後,您不僅將瞭解如何使用零知識證明,還會瞭解為何要使用以及如何安全地使用。
+author: 作者:Ori Pomerantz
+tags: [ "零知識", "伺服器", "鏈下", "隱私" ]
+skill: advanced
+lang: zh-tw
+published: 2025-10-15
+---
+
+## 介紹 {#introduction}
+
+與 [rollups](/developers/docs/scaling/zk-rollups/) 相反,[plasma](/developers/docs/scaling/plasma) 使用以太坊主網來確保完整性,而非可用性。 在本文中,我們將編寫一個行為類似 plasma 的應用程式,由以太坊保證完整性 (無未經授權的變更),但不保證可用性 (中心化元件可能故障並停用整個系統)。
+
+我們在此處編寫的應用程式是保留隱私權的銀行。 不同的地址擁有含餘額的帳戶,且可將資金 (ETH) 傳送至其他帳戶。 銀行會張貼狀態 (帳戶及其餘額) 和交易的雜湊值,但會將實際餘額保留在鏈下,以維持其隱私。
+
+## 設計 {#design}
+
+這不是可供生產的系統,而是教學工具。 因此,它是基於幾個簡化的假設編寫的。
+
+- 固定的帳戶池。 帳戶有特定數量,且每個帳戶都屬於預先決定的地址。 這使得系統更加簡單,因為在零知識證明中處理可變大小的資料結構很困難。 對於可供生產的系統,我們可以使用 [Merkle 根](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) 作為狀態雜湊值,並為必要的餘額提供 Merkle 證明。
+
+- 記憶體儲存。 在生產系統上,我們需要將所有帳戶餘額寫入磁碟,以在重新啟動時保留它們。 在此,即使資訊遺失也無妨。
+
+- 僅限傳送。 生產系統需要一種將資產存入銀行並提款的方式。 但這裡的目的只是為了說明概念,所以此銀行僅限於傳送。
+
+### 零知識證明 {#zero-knowledge-proofs}
+
+在基礎層面上,零知識證明顯示證明者知道一些資料 _Dataprivate_,使得一些公開資料 _Datapublic_ 和 _Dataprivate_ 之間存在關係 _Relationship_。 驗證者知道 _Relationship_ 和 _Datapublic_。
+
+為了保護隱私,我們需要將狀態和交易設為私密。 但為了確保完整性,我們需要將狀態的 [密碼學雜湊值](https://en.wikipedia.org/wiki/Cryptographic_hash_function) 設為公開。 為了向提交交易的人證明這些交易確實發生了,我們還需要張貼交易雜湊值。
+
+在大多數情況下,_Dataprivate_ 是零知識證明程式的輸入,而 _Datapublic_ 是輸出。
+
+_Dataprivate_ 中的這些欄位:
+
+- _Staten_,舊的狀態
+- _Staten+1_,新的狀態
+- _Transaction_,將舊狀態變更為新狀態的交易。 此交易需要包含以下欄位:
+ - _目的地地址_,接收傳送的地址
+ - 正在傳送的 _金額_
+ - _Nonce_,確保每個交易只能處理一次。
+ 來源地址不需要在交易中,因為它可以從簽章中恢復。
+- _簽章_,一個經授權執行交易的簽章。 在我們的案例中,唯一被授權執行交易的地址是來源地址。 由於我們的零知識系統的運作方式,除了以太坊簽章外,我們還需要帳戶的公鑰。
+
+_Datapublic_ 中的這些欄位:
+
+- _Hash(Staten)_,舊狀態的雜湊值
+- _Hash(Staten+1)_,新狀態的雜湊值
+- _Hash(Transaction)_,將狀態從 _Staten_ 變更為 _Staten+1_ 的交易雜湊值。
+
+此關係會檢查幾個條件:
+
+- 公開的雜湊值確實是私密欄位的正確雜湊值。
+- 交易應用於舊狀態時,會產生新狀態。
+- 簽章來自交易的來源地址。
+
+由於密碼學雜湊函數的特性,證明這些條件就足以確保完整性。
+
+### 數據結構 {#data-structures}
+
+主要資料結構是伺服器持有的狀態。 對於每個帳戶,伺服器都會追蹤帳戶餘額和一個 [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce),用於防止 [重放攻擊](https://en.wikipedia.org/wiki/Replay_attack)。
+
+### 元件 {#components}
+
+此系統需要兩個元件:
+
+- _伺服器_,接收交易、處理交易,並將雜湊值與零知識證明一起發布到鏈上。
+- 一個 _智能合約_,儲存雜湊值並驗證零知識證明,以確保狀態轉換是合法的。
+
+### 資料和控制流 {#flows}
+
+這些是各種元件之間溝通,以將資金從一個帳戶傳送到另一個帳戶的方式。
+
+1. 網頁瀏覽器提交一份簽署的交易,要求從簽署者的帳戶傳送到另一個不同的帳戶。
+
+2. 伺服器驗證該交易是否有效:
+
+ - 簽署者在銀行中有一個餘額充足的帳戶。
+ - 收款人在銀行中有一個帳戶。
+
+3. 伺服器透過從簽署者的餘額中減去傳送的金額,並將其加到收款人的餘額中,來計算新的狀態。
+
+4. 伺服器計算一個零知識證明,證明狀態變更是有效的。
+
+5. 伺服器向以太坊提交一筆包含以下內容的交易:
+
+ - 新狀態的雜湊值
+ - 交易雜湊值 (以便交易發送者可以知道交易已處理)
+ - 證明轉換到新狀態是有效的零知識證明
+
+6. 智能合約驗證零知識證明。
+
+7. 如果零知識證明檢查通過,智能合約將執行以下操作:
+ - 將當前狀態雜湊值更新為新狀態雜湊值
+ - 發出一個包含新狀態雜湊值和交易雜湊值的日誌項目
+
+### 工具 {#tools}
+
+對於用戶端程式碼,我們將使用 [Vite](https://vite.dev/)、[React](https://react.dev/)、[Viem](https://viem.sh/) 和 [Wagmi](https://wagmi.sh/)。 這些是業界標準的工具;如果您不熟悉,可以使用[此教學](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)。
+
+伺服器的主要部分是使用 [Node](https://nodejs.org/en) 以 JavaScript 編寫的。 零知識部分是用 [Noir](https://noir-lang.org/) 編寫的。 我們需要 `1.0.0-beta.10` 版本,因此在您 [按照指示安裝 Noir](https://noir-lang.org/docs/getting_started/quick_start) 後,請執行:
+
+```
+noirup -v 1.0.0-beta.10
+```
+
+我們使用的區塊鏈是 `anvil`,一個本地測試區塊鏈,是 [Foundry](https://getfoundry.sh/introduction/installation) 的一部分。
+
+## 實作 {#implementation}
+
+由於這是一個複雜的系統,我們將分階段實作。
+
+### 第 1 階段 - 手動零知識 {#stage-1}
+
+在第一階段,我們將在瀏覽器中簽署一筆交易,然後手動提供資訊給零知識證明。 零知識程式碼預期會在 `server/noir/Prover.toml` 中取得該資訊 (文件記錄於 [此處](https://noir-lang.org/docs/getting_started/project_breakdown#provertoml-1))。
+
+實際操作如下:
+
+1. 請確保您已安裝 [Node](https://nodejs.org/en/download) 和 [Noir](https://noir-lang.org/install)。 最好在 UNIX 系統上安裝它們,例如 macOS、Linux 或 [WSL](https://learn.microsoft.com/en-us/windows/wsl/install)。
+
+2. 下載第 1 階段的程式碼並啟動網頁伺服器以提供用戶端程式碼。
+
+ ```sh
+ git clone https://github.com/qbzzt/250911-zk-bank.git -b 01-manual-zk
+ cd 250911-zk-bank
+ cd client
+ npm install
+ npm run dev
+ ```
+
+ 您需要網頁伺服器的原因是,為了防止某些類型的詐騙,許多錢包 (例如 MetaMask) 不接受直接從磁碟提供的檔案。
+
+3. 打開帶有錢包的瀏覽器。
+
+4. 在錢包中,輸入新的密碼。 請注意,這將刪除您現有的密碼,所以_請確保您有備份_。
+
+ 密碼是 `test test test test test test test test test test test junk`,這是 anvil 的預設測試密碼。
+
+5. 瀏覽至 [用戶端程式碼](http://localhost:5173/)。
+
+6. 連接到錢包並選擇您的目標帳戶和金額。
+
+7. 按一下 **Sign** 並簽署交易。
+
+8. 在 **Prover.toml** 標題下,您會找到文字。 將 `server/noir/Prover.toml` 替換為該文字。
+
+9. 執行零知識證明。
+
+ ```sh
+ cd ../server/noir
+ nargo execute
+ ```
+
+ 輸出應類似於
+
+ ```
+ ori@CryptoDocGuy:~/noir/250911-zk-bank/server/noir$ nargo execute
+
+ [zkBank] Circuit witness successfully solved
+ [zkBank] Witness saved to target/zkBank.gz
+ [zkBank] Circuit output: (0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b, 0x0cfc0a67cb7308e4e9b254026b54204e34f6c8b041be207e64c5db77d95dd82d, 0x450cf9da6e180d6159290554ae3d8787, 0x6d8bc5a15b9037e52fb59b6b98722a85)
+ ```
+
+10. 將最後兩個值與您在網頁瀏覽器上看到的雜湊值進行比較,以查看訊息是否已正確雜湊。
+
+#### `server/noir/Prover.toml` {#server-noir-prover-toml}
+
+[此檔案](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml) 顯示 Noir 預期的資訊格式。
+
+```toml
+message="send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 500 finney (milliEth) 0 "
+```
+
+此訊息採用文字格式,方便使用者理解 (這在簽署時是必要的),也方便 Noir 程式碼解析。 金額以 finney 報價,一方面可以進行部分傳送,另一方面也易於閱讀。 最後一個數字是 [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce)。
+
+該字串長度為 100 個字元。 零知識證明不善於處理可變大小的資料,因此通常需要填充資料。
+
+```toml
+pubKeyX=["0x83",...,"0x75"]
+pubKeyY=["0x35",...,"0xa5"]
+signature=["0xb1",...,"0x0d"]
+```
+
+這三個參數是固定大小的位元組陣列。
+
+```toml
+[[accounts]]
+address="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"
+balance=100_000
+nonce=0
+
+[[accounts]]
+address="0x70997970C51812dc3A010C7d01b50e0d17dc79C8"
+balance=100_000
+nonce=0
+```
+
+這是指定結構陣列的方式。 對於每個項目,我們指定地址、餘額 (以 milliETH,又稱為 [finney](https://cryptovalleyjournal.com/glossary/finney/)),以及下一個 nonce 值。
+
+#### `client/src/Transfer.tsx` {#client-src-transfer-tsx}
+
+[此檔案](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/client/src/Transfer.tsx) 會實作用戶端的處理,並產生 `server/noir/Prover.toml` 檔案 (包含零知識參數的檔案)。
+
+以下是較有趣部分的說明。
+
+```tsx
+export default attrs => {
+```
+
+此函式會建立 `Transfer` React 元件,其他檔案可以匯入此元件。
+
+```tsx
+ const accounts = [
+ "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
+ "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
+ "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC",
+ "0x90F79bf6EB2c4f870365E785982E1f101E93b906",
+ "0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65",
+ ]
+```
+
+這些是帳戶地址,也就是 `test ...` 建立的地址。 test junk\` 密碼。 如果您想使用自己的地址,只需修改此定義即可。
+
+```tsx
+ const account = useAccount()
+ const wallet = createWalletClient({
+ transport: custom(window.ethereum!)
+ })
+```
+
+這些 [Wagmi hooks](https://wagmi.sh/react/api/hooks) 讓我們能夠存取 [viem](https://viem.sh/) 庫和錢包。
+
+```tsx
+ const message = `send ${toAccount} ${ethAmount*1000} finney (milliEth) ${nonce}`.padEnd(100, " ")
+```
+
+這是以空格填補的訊息。 每當 [`useState`](https://react.dev/reference/react/useState) 變數變更時,元件就會重新繪製,而 `message` 也會更新。
+
+```tsx
+ const sign = async () => {
+```
+
+此函式會在使用者按一下 **Sign** 按鈕時呼叫。 訊息會自動更新,但簽章需要使用者在錢包中核准,除非必要,否則我們不想要求核准。
+
+```tsx
+ const signature = await wallet.signMessage({
+ account: fromAccount,
+ message,
+ })
+```
+
+要求錢包 [簽署訊息](https://viem.sh/docs/accounts/local/signMessage)。
+
+```tsx
+ const hash = hashMessage(message)
+```
+
+取得訊息雜湊值。 提供給使用者以供偵錯 (Noir 程式碼) 會很有幫助。
+
+```tsx
+ const pubKey = await recoverPublicKey({
+ hash,
+ signature
+ })
+```
+
+[取得公鑰](https://viem.sh/docs/utilities/recoverPublicKey)。 這是 [Noir `ecrecover`](https://github.com/colinnielsen/ecrecover-noir) 函式所需的。
+
+```tsx
+ setSignature(signature)
+ setHash(hash)
+ setPubKey(pubKey)
+```
+
+設定狀態變數。 這樣做會在 `sign` 函式結束後重新繪製元件,並向使用者顯示更新後的值。
+
+```tsx
+ let proverToml = `"
+```
+
+`Prover.toml` 的文字。
+
+```tsx
+message="${message}"
+
+pubKeyX=${hexToArray(pubKey.slice(4,4+2*32))}
+pubKeyY=${hexToArray(pubKey.slice(4+2*32))}
+```
+
+Viem 提供我們一個 65 位元組的十六進位字串作為公鑰。 第一個位元組是 `0x04`,一個版本標記。 接下來是 32 位元組的公鑰 `x`,然後是 32 位元組的公鑰 `y`。
+
+然而,Noir 預期會以兩個位元組陣列的形式取得此資訊,一個用於 `x`,一個用於 `y`。 在用戶端解析比在零知識證明中解析更容易。
+
+請注意,這通常是零知識中的良好作法。 零知識證明中的程式碼成本很高,因此任何可以在零知識證明之外完成的處理都_應該_在零知識證明之外完成。
+
+```tsx
+signature=${hexToArray(signature.slice(2,-2))}
+```
+
+簽章也以 65 位元組的十六進位字串提供。 然而,最後一個位元組僅用於恢復公鑰。 由於公鑰已經提供給 Noir 程式碼,我們不需要它來驗證簽章,Noir 程式碼也不需要它。
+
+```tsx
+${accounts.map(accountInProverToml).reduce((a,b) => a+b, "")}
+`
+```
+
+提供帳戶。
+
+```tsx
+ setProverToml(proverToml)
+ }
+
+ return (
+ <>
+ Transfer
+```
+
+這是元件的 HTML (更準確地說,是 [JSX](https://react.dev/learn/writing-markup-with-jsx)) 格式。
+
+#### `server/noir/src/main.nr` {#server-noir-src-main-nr}
+
+[此檔案](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/src/main.nr) 是實際的零知識程式碼。
+
+```
+use std::hash::pedersen_hash;
+```
+
+[Pedersen 雜湊](https://rya-sge.github.io/access-denied/2024/05/07/pedersen-hash-function/) 由 [Noir 標準庫](https://noir-lang.org/docs/noir/standard_library/cryptographic_primitives/hashes#pedersen_hash) 提供。 零知識證明通常使用此雜湊函數。 與標準雜湊函數相比,在 [算術電路](https://rareskills.io/post/arithmetic-circuit) 內計算要容易得多。
+
+```
+use keccak256::keccak256;
+use dep::ecrecover;
+```
+
+這兩個函式是外部庫,定義在 [`Nargo.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Nargo.toml) 中。 它們的名稱恰如其分,一個是計算 [keccak256 雜湊](https://emn178.github.io/online-tools/keccak_256.html) 的函式,另一個是驗證以太坊簽章並恢復簽署者的以太坊地址的函式。
+
+```
+global ACCOUNT_NUMBER : u32 = 5;
+```
+
+Noir 的靈感來自 [Rust](https://www.rust-lang.org/)。 變數預設是常數。 這是我們定義全域組態常數的方式。 具體來說,`ACCOUNT_NUMBER` 是我們儲存的帳戶數量。
+
+名為 `u` 的資料類型是該位元數的無符號整數。 唯一支援的類型是 `u8`、`u16`、`u32`、`u64` 和 `u128`。
+
+```
+global FLAT_ACCOUNT_FIELDS : u32 = 2;
+```
+
+此變數用於帳戶的 Pedersen 雜湊,如下所述。
+
+```
+global MESSAGE_LENGTH : u32 = 100;
+```
+
+如上所述,訊息長度是固定的。 在此處指定。
+
+```
+global ASCII_MESSAGE_LENGTH : [u8; 3] = [0x31, 0x30, 0x30];
+global HASH_BUFFER_SIZE : u32 = 26+3+MESSAGE_LENGTH;
+```
+
+[EIP-191 簽章](https://eips.ethereum.org/EIPS/eip-191) 需要一個緩衝區,其中包含 26 位元組的前綴,後接 ASCII 格式的訊息長度,最後是訊息本身。
+
+```
+struct Account {
+ balance: u128,
+ address: Field,
+ nonce: u32,
+}
+```
+
+我們儲存的帳戶資訊。 [`Field`](https://noir-lang.org/docs/noir/concepts/data_types/fields) 是一個數字,通常最多 253 位元,可直接用於實作零知識證明的 [算術電路](https://rareskills.io/post/arithmetic-circuit)。 在此,我們使用 `Field` 來儲存 160 位元的以太坊地址。
+
+```
+struct TransferTxn {
+ from: Field,
+ to: Field,
+ amount: u128,
+ nonce: u32
+}
+```
+
+我們儲存的傳送交易資訊。
+
+```
+fn flatten_account(account: Account) -> [Field; FLAT_ACCOUNT_FIELDS] {
+```
+
+函式定義。 參數是 `Account` 資訊。 結果是一個 `Field` 變數陣列,長度為 `FLAT_ACCOUNT_FIELDS`
+
+```
+ let flat = [
+ account.address,
+ ((account.balance << 32) + account.nonce.into()).into(),
+ ];
+```
+
+陣列中的第一個值是帳戶地址。 第二個值包括餘額和 nonce。 `.into()` 呼叫會將數字變更為其所需的資料類型。 `account.nonce` 是一個 `u32` 值,但若要將其新增至 `account.balance << 32` (一個 `u128` 值),它需要是 `u128`。 這是第一個 `.into()`。 第二個 `.into()` 將 `u128` 結果轉換為 `Field`,使其符合陣列。
+
+```
+ flat
+}
+```
+
+在 Noir 中,函式只能在結尾傳回一個值 (沒有提早傳回)。 若要指定傳回值,您只需在函式的右括號前評估它即可。
+
+```
+fn flatten_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] {
+```
+
+此函式將帳戶陣列轉換為 `Field` 陣列,可作為 Petersen 雜湊的輸入。
+
+```
+ let mut flat: [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] = [0; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER];
+```
+
+這是指定可變變數的方式,也就是_不是_常數。 Noir 中的變數必須始終有值,因此我們將此變數初始化為全零。
+
+```
+ for i in 0..ACCOUNT_NUMBER {
+```
+
+這是 `for` 迴圈。 請注意,邊界是常數。 Noir 迴圈的邊界必須在編譯時已知。 原因是算術電路不支援流程控制。 在處理 `for` 迴圈時,編譯器會簡單地將其中的程式碼多次放置,每次迭代一次。
+
+```
+ let fields = flatten_account(accounts[i]);
+ for j in 0..FLAT_ACCOUNT_FIELDS {
+ flat[i*FLAT_ACCOUNT_FIELDS + j] = fields[j];
+ }
+ }
+
+ flat
+}
+
+fn hash_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> Field {
+ pedersen_hash(flatten_accounts(accounts))
+}
+```
+
+最後,我們來到雜湊帳戶陣列的函式。
+
+```
+fn find_account(accounts: [Account; ACCOUNT_NUMBER], address: Field) -> u32 {
+ let mut account : u32 = ACCOUNT_NUMBER;
+
+ for i in 0..ACCOUNT_NUMBER {
+ if accounts[i].address == address {
+ account = i;
+ }
+ }
+```
+
+此函式會尋找具有特定地址的帳戶。 此函式在標準程式碼中效率極低,因為它會迭代所有帳戶,即使在找到地址後也是如此。
+
+然而,在零知識證明中,沒有流程控制。 如果我們需要檢查條件,我們必須每次都檢查它。
+
+`if` 陳述式也會發生類似的情況。 上述迴圈中的 `if` 陳述式會轉換為這些數學陳述式。
+
+_conditionresult = accounts[i].address == address_ // 如果相等則為 1,否則為 0
+
+_accountnew = conditionresult\*i + (1-conditionresult)\*accountold_
+
+```rust
+ assert (account < ACCOUNT_NUMBER, f"{address} does not have an account");
+
+ account
+}
+```
+
+如果斷言為假,[`assert`](https://noir-lang.org/docs/dev/noir/concepts/assert) 函式會導致零知識證明崩潰。 在這種情況下,如果我們找不到具有相關地址的帳戶。 若要報告地址,我們使用 [格式字串](https://noir-lang.org/docs/noir/concepts/data_types/strings#format-strings)。
+
+```rust
+fn apply_transfer_txn(accounts: [Account; ACCOUNT_NUMBER], txn: TransferTxn) -> [Account; ACCOUNT_NUMBER] {
+```
+
+此函式會套用一筆傳送交易,並傳回新的帳戶陣列。
+
+```rust
+ let from = find_account(accounts, txn.from);
+ let to = find_account(accounts, txn.to);
+
+ let (txnFrom, txnAmount, txnNonce, accountNonce) =
+ (txn.from, txn.amount, txn.nonce, accounts[from].nonce);
+```
+
+我們無法在 Noir 的格式字串內存取結構元素,因此我們建立了一個可用的副本。
+
+```rust
+ assert (accounts[from].balance >= txn.amount,
+ f"{txnFrom} 沒有 {txnAmount} finney");
+
+ assert (accounts[from].nonce == txn.nonce,
+ f"交易的 nonce 為 {txnNonce},但帳戶應使用 {accountNonce}");
+```
+
+這是兩個可能使交易無效的條件。
+
+```rust
+ let mut newAccounts = accounts;
+
+ newAccounts[from].balance -= txn.amount;
+ newAccounts[from].nonce += 1;
+ newAccounts[to].balance += txn.amount;
+
+ newAccounts
+}
+```
+
+建立新的帳戶陣列,然後傳回它。
+
+```rust
+fn readAddress(messageBytes: [u8; MESSAGE_LENGTH]) -> Field
+```
+
+此函式從訊息中讀取地址。
+
+```rust
+{
+ let mut result : Field = 0;
+
+ for i in 7..47 {
+```
+
+地址總是 20 位元組 (又稱為 40 個十六進位數字) 長,並從字元 #7 開始。
+
+```rust
+ result *= 0x10;
+ if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9
+ result += (messageBytes[i]-48).into();
+ }
+ if messageBytes[i] >= 65 & messageBytes[i] <= 70 { // A-F
+ result += (messageBytes[i]-65+10).into()
+ }
+ if messageBytes[i] >= 97 & messageBytes[i] <= 102 { // a-f
+ result += (messageBytes[i]-97+10).into()
+ }
+ }
+
+ result
+}
+
+fn readAmountAndNonce(messageBytes: [u8; MESSAGE_LENGTH]) -> (u128, u32)
+```
+
+從訊息中讀取金額和 nonce。
+
+```rust
+{
+ let mut amount : u128 = 0;
+ let mut nonce: u32 = 0;
+ let mut stillReadingAmount: bool = true;
+ let mut lookingForNonce: bool = false;
+ let mut stillReadingNonce: bool = false;
+```
+
+在訊息中,地址後的第一個數字是要傳送的 finney (又稱為 千分之一 ETH) 金額。 第二個數字是 nonce。 兩者之間的任何文字都會被忽略。
+
+```rust
+ for i in 48..MESSAGE_LENGTH {
+ if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9
+ let digit = (messageBytes[i]-48);
+
+ if stillReadingAmount {
+ amount = amount*10 + digit.into();
+ }
+
+ if lookingForNonce { // We just found it
+ stillReadingNonce = true;
+ lookingForNonce = false;
+ }
+
+ if stillReadingNonce {
+ nonce = nonce*10 + digit.into();
+ }
+ } else {
+ if stillReadingAmount {
+ stillReadingAmount = false;
+ lookingForNonce = true;
+ }
+ if stillReadingNonce {
+ stillReadingNonce = false;
+ }
+ }
+ }
+
+ (amount, nonce)
+}
+```
+
+傳回 [元組](https://noir-lang.org/docs/noir/concepts/data_types/tuples) 是 Noir 從函式傳回多個值的方式。
+
+```rust
+fn readTransferTxn(message: str) -> TransferTxn
+{
+ let mut txn: TransferTxn = TransferTxn { from: 0, to: 0, amount:0, nonce:0 };
+ let messageBytes = message.as_bytes();
+
+ txn.to = readAddress(messageBytes);
+ let (amount, nonce) = readAmountAndNonce(messageBytes);
+ txn.amount = amount;
+ txn.nonce = nonce;
+
+ txn
+}
+```
+
+此函式將訊息轉換為位元組,然後將金額轉換為 `TransferTxn`。
+
+```rust
+// The equivalent to Viem's hashMessage
+// https://viem.sh/docs/utilities/hashMessage#hashmessage
+fn hashMessage(message: str) -> [u8;32] {
+```
+
+我們能夠對帳戶使用 Pedersen 雜湊,因為它們只在零知識證明內雜湊。 然而,在此程式碼中,我們需要檢查訊息的簽章,這是由瀏覽器產生的。 為此,我們需要遵循 [EIP 191](https://eips.ethereum.org/EIPS/eip-191) 中的以太坊簽署格式。 這表示我們需要建立一個組合緩衝區,其中包含標準前綴、ASCII 格式的訊息長度以及訊息本身,並使用以太坊標準 keccak256 進行雜湊。
+
+```rust
+ // ASCII prefix
+ let prefix_bytes = [
+ 0x19, // \x19
+ 0x45, // 'E'
+ 0x74, // 't'
+ 0x68, // 'h'
+ 0x65, // 'e'
+ 0x72, // 'r'
+ 0x65, // 'e'
+ 0x75, // 'u'
+ 0x6D, // 'm'
+ 0x20, // ' '
+ 0x53, // 'S'
+ 0x69, // 'i'
+ 0x67, // 'g'
+ 0x6E, // 'n'
+ 0x65, // 'e'
+ 0x64, // 'd'
+ 0x20, // ' '
+ 0x4D, // 'M'
+ 0x65, // 'e'
+ 0x73, // 's'
+ 0x73, // 's'
+ 0x61, // 'a'
+ 0x67, // 'g'
+ 0x65, // 'e'
+ 0x3A, // ':'
+ 0x0A // '\n'
+ ];
+```
+
+為避免應用程式要求使用者簽署可用作交易或其他用途的訊息,EIP 191 指定所有簽署的訊息都以字元 0x19 (非有效 ASCII 字元) 開頭,後接 `Ethereum Signed Message:` 和換行符。
+
+```rust
+ let mut buffer: [u8; HASH_BUFFER_SIZE] = [0u8; HASH_BUFFER_SIZE];
+ for i in 0..26 {
+ buffer[i] = prefix_bytes[i];
+ }
+
+ let messageBytes : [u8; MESSAGE_LENGTH] = message.as_bytes();
+
+ if MESSAGE_LENGTH <= 9 {
+ for i in 0..1 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+1] = messageBytes[i];
+ }
+ }
+
+ if MESSAGE_LENGTH >= 10 & MESSAGE_LENGTH <= 99 {
+ for i in 0..2 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+2] = messageBytes[i];
+ }
+ }
+
+ if MESSAGE_LENGTH >= 100 {
+ for i in 0..3 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+3] = messageBytes[i];
+ }
+ }
+
+ assert(MESSAGE_LENGTH < 1000, "不支援長度超過三位數的訊息");
+```
+
+處理長度達 999 的訊息,如果超過則失敗。 我新增了這段程式碼,即使訊息長度是常數,因為這樣更容易變更。 在生產系統上,為了更好的效能,您可能會假設 `MESSAGE_LENGTH` 不會變更。
+
+```rust
+ keccak256::keccak256(buffer, HASH_BUFFER_SIZE)
+}
+```
+
+使用以太坊標準的 `keccak256` 函式。
+
+```rust
+fn signatureToAddressAndHash(
+ message: str,
+ pubKeyX: [u8; 32],
+ pubKeyY: [u8; 32],
+ signature: [u8; 64]
+ ) -> (Field, Field, Field) // address, first 16 bytes of hash, last 16 bytes of hash
+{
+```
+
+此函式會驗證簽章,這需要訊息雜湊值。 然後,它會提供我們簽署它的地址和訊息雜湊值。 訊息雜湊值以兩個 `Field` 值提供,因為它們比位元組陣列在程式的其餘部分更容易使用。
+
+我們需要使用兩個 `Field` 值,因為欄位計算是使用 [模數](https://en.wikipedia.org/wiki/Modulo) 一個大數來完成的,但該數字通常小於 256 位元 (否則在 EVM 中執行這些計算會很困難)。
+
+```rust
+ let hash = hashMessage(message);
+
+ let mut (hash1, hash2) = (0,0);
+
+ for i in 0..16 {
+ hash1 = hash1*256 + hash[31-i].into();
+ hash2 = hash2*256 + hash[15-i].into();
+ }
+```
+
+將 `hash1` 和 `hash2` 指定為可變變數,並逐位元組將雜湊寫入其中。
+
+```rust
+ (
+ ecrecover::ecrecover(pubKeyX, pubKeyY, signature, hash),
+```
+
+這類似於 [Solidity 的 `ecrecover`](https://docs.soliditylang.org/en/v0.8.30/cheatsheet.html#mathematical-and-cryptographic-functions),但有兩個重要的差異:
+
+- 如果簽章無效,呼叫會失敗一個 `assert`,程式會被中止。
+- 雖然公鑰可以從簽章和雜湊中恢復,但這項處理可以在外部完成,因此不值得在零知識證明內進行。 如果有人在此試圖欺騙我們,簽章驗證將會失敗。
+
+```rust
+ hash1,
+ hash2
+ )
+}
+
+fn main(
+ accounts: [Account; ACCOUNT_NUMBER],
+ message: str,
+ pubKeyX: [u8; 32],
+ pubKeyY: [u8; 32],
+ signature: [u8; 64],
+ ) -> pub (
+ Field, // Hash of old accounts array
+ Field, // Hash of new accounts array
+ Field, // First 16 bytes of message hash
+ Field, // Last 16 bytes of message hash
+ )
+```
+
+最後,我們來到 `main` 函式。 我們需要證明我們有一個交易,該交易有效地將帳戶的雜湊從舊值變更為新值。 我們還需要證明它具有此特定的交易雜湊,以便發送它的人知道他們的交易已處理。
+
+```rust
+{
+ let mut txn = readTransferTxn(message);
+```
+
+我們需要 `txn` 是可變的,因為我們不是從訊息中讀取 `from` 地址,而是從簽章中讀取。
+
+```rust
+ let (fromAddress, txnHash1, txnHash2) = signatureToAddressAndHash(
+ message,
+ pubKeyX,
+ pubKeyY,
+ signature);
+
+ txn.from = fromAddress;
+
+ let newAccounts = apply_transfer_txn(accounts, txn);
+
+ (
+ hash_accounts(accounts),
+ hash_accounts(newAccounts),
+ txnHash1,
+ txnHash2
+ )
+}
+```
+
+### 第 2 階段 - 新增伺服器 {#stage-2}
+
+在第二階段,我們新增一個伺服器,接收並實作來自瀏覽器的傳送交易。
+
+實際操作如下:
+
+1. 如果 Vite 正在執行,請停止它。
+
+2. 下載包含伺服器的分支,並確保您擁有所有必要的模組。
+
+ ```sh
+ git checkout 02-add-server
+ cd client
+ npm install
+ cd ../server
+ npm install
+ ```
+
+ 無需編譯 Noir 程式碼,它與您用於第 1 階段的程式碼相同。
+
+3. 啟動伺服器。
+
+ ```sh
+ npm run start
+ ```
+
+4. 在個別的命令列視窗中,執行 Vite 以提供瀏覽器程式碼。
+
+ ```sh
+ cd client
+ npm run dev
+ ```
+
+5. 瀏覽至 [http://localhost:5173](http://localhost:5173) 的用戶端程式碼
+
+6. 在發出交易之前,您需要知道 nonce 以及可以傳送的金額。 若要取得此資訊,請按一下 **Update account data** 並簽署訊息。
+
+ 我們在此遇到一個兩難的局面。 一方面,我們不希望簽署可重複使用的訊息 ([重放攻擊](https://en.wikipedia.org/wiki/Replay_attack)),這就是我們一開始需要 nonce 的原因。 然而,我們還沒有 nonce。 解決方案是選擇一個只能使用一次且雙方都已有的 nonce,例如目前時間。
+
+ 此解決方案的問題是時間可能無法完全同步。 因此,我們改為簽署一個每分鐘變更一次的值。 這表示我們遭受重放攻擊的漏洞窗口最多為一分鐘。 考量到在生產環境中,已簽署的請求將受到 TLS 保護,而且通道的另一端—伺服器—已經可以揭露餘額和 nonce (它必須知道這些才能運作),這是一個可接受的風險。
+
+7. 瀏覽器取回餘額和 nonce 後,會顯示傳送表單。 選擇目的地地址和金額,然後按一下 **Transfer**。 簽署此請求。
+
+8. 若要查看傳送,請 **更新帳戶資料** 或查看您執行伺服器的視窗。 伺服器每次變更狀態時都會記錄狀態。
+
+ ```
+ ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start
+
+ > server@1.0.0 start
+ > node --experimental-json-modules index.mjs
+
+ Listening on port 3000
+ Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 36000 finney (milliEth) 0 processed
+ New state:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 64000 (1)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 100000 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0)
+ Txn send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 7200 finney (milliEth) 1 processed
+ New state:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 56800 (2)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0)
+ Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 3000 finney (milliEth) 2 processed
+ New state:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 53800 (3)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 139000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0)
+ ```
+
+#### `server/index.mjs` {#server-index-mjs-1}
+
+[此檔案](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/index.mjs) 包含伺服器程序,並與 [`main.nr`](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/noir/src/main.nr) 的 Noir 程式碼互動。 以下是有趣部分的說明。
+
+```js
+import { Noir } from '@noir-lang/noir_js'
+```
+
+[noir.js](https://www.npmjs.com/package/@noir-lang/noir_js) 庫在 JavaScript 程式碼和 Noir 程式碼之間提供介面。
+
+```js
+const circuit = JSON.parse(await fs.readFile("./noir/target/zkBank.json"))
+const noir = new Noir(circuit)
+```
+
+載入算術電路—我們在上一階段建立的已編譯 Noir 程式—並準備執行它。
+
+```js
+// We only provide account information in return to a signed request
+const accountInformation = async signature => {
+ const fromAddress = await recoverAddress({
+ hash: hashMessage("Get account data " + Math.floor((new Date().getTime())/60000)),
+ signature
+ })
+```
+
+若要提供帳戶資訊,我們只需要簽章。 原因是我們已經知道訊息會是什麼,因此也知道訊息雜湊值。
+
+```js
+const processMessage = async (message, signature) => {
+```
+
+處理訊息並執行其編碼的交易。
+
+```js
+ // Get the public key
+ const pubKey = await recoverPublicKey({
+ hash,
+ signature
+ })
+```
+
+現在我們在伺服器上執行 JavaScript,我們可以在那裡而不是在用戶端上擷取公鑰。
+
+```js
+ let noirResult
+ try {
+ noirResult = await noir.execute({
+ message,
+ signature: signature.slice(2,-2).match(/.{2}/g).map(x => `0x${x}`),
+ pubKeyX,
+ pubKeyY,
+ accounts: Accounts
+ })
+```
+
+`noir.execute` 會執行 Noir 程式。 參數相當於 [`Prover.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml) 中提供的參數。 請注意,長值是作為十六進位字串陣列 (`["0x60", "0xA7"]`) 提供的,而不是像 Viem 那樣作為單一十六進位值 (`0x60A7`)。
+
+```js
+ } catch (err) {
+ console.log(`Noir 錯誤:${err}`)
+ throw Error("交易無效,未處理")
+ }
+```
+
+如果有錯誤,請將其攔截,然後將簡化版本轉送給用戶端。
+
+```js
+ Accounts[fromAccountNumber].nonce++
+ Accounts[fromAccountNumber].balance -= amount
+ Accounts[toAccountNumber].balance += amount
+```
+
+套用交易。 我們已經在 Noir 程式碼中完成了,但在這裡再做一次比從那裡擷取結果更容易。
+
+```js
+let Accounts = [
+ {
+ address: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
+ balance: 5000,
+ nonce: 0,
+ },
+```
+
+初始 `Accounts` 結構。
+
+### 第 3 階段 - 以太坊智能合約 {#stage-3}
+
+1. 停止伺服器和用戶端程序。
+
+2. 下載包含智能合約的分支,並確保您擁有所有必要的模組。
+
+ ```sh
+ git checkout 03-smart-contracts
+ cd client
+ npm install
+ cd ../server
+ npm install
+ ```
+
+3. 在個別的命令列視窗中執行 `anvil`。
+
+4. 產生驗證金鑰和 solidity 驗證器,然後將驗證器程式碼複製到 Solidity 專案。
+
+ ```sh
+ cd noir
+ bb write_vk -b ./target/zkBank.json -o ./target --oracle_hash keccak
+ bb write_solidity_verifier -k ./target/vk -o ./target/Verifier.sol
+ cp target/Verifier.sol ../../smart-contracts/src
+ ```
+
+5. 前往智能合約並設定環境變數以使用 `anvil` 區塊鏈。
+
+ ```sh
+ cd ../../smart-contracts
+ export ETH_RPC_URL=http://localhost:8545
+ ETH_PRIVATE_KEY=ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
+ ```
+
+6. 部署 `Verifier.sol` 並將地址儲存在環境變數中。
+
+ ```sh
+ VERIFIER_ADDRESS=`forge create src/Verifier.sol:HonkVerifier --private-key $ETH_PRIVATE_KEY --optimize --broadcast | awk '/Deployed to:/ {print $3}'`
+ echo $VERIFIER_ADDRESS
+ ```
+
+7. 部署 `ZkBank` 合約。
+
+ ```sh
+ ZKBANK_ADDRESS=`forge create ZkBank --private-key $ETH_PRIVATE_KEY --broadcast --constructor-args $VERIFIER_ADDRESS 0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b | awk '/Deployed to:/ {print $3}'`
+ echo $ZKBANK_ADDRESS
+ ```
+
+ `0x199..67b` 值是 `Accounts` 初始狀態的 Pederson 雜湊。 如果您在 `server/index.mjs` 中修改此初始狀態,您可以執行一個交易,以查看零知識證明報告的初始雜湊。
+
+8. 執行伺服器。
+
+ ```sh
+ cd ../server
+ npm run start
+ ```
+
+9. 在不同的命令列視窗中執行用戶端。
+
+ ```sh
+ cd client
+ npm run dev
+ ```
+
+10. 執行一些交易。
+
+11. 若要驗證狀態已在鏈上變更,請重新啟動伺服器程序。 查看 `ZkBank` 是否不再接受交易,因為交易中的原始雜湊值與鏈上儲存的雜湊值不同。
+
+ 這是預期的錯誤類型。
+
+ ```
+ ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start
+
+ > server@1.0.0 start
+ > node --experimental-json-modules index.mjs
+
+ 正在接聽連接埠 3000
+ 驗證錯誤:ContractFunctionExecutionError: 合約函數 "processTransaction" 因以下原因而還原:
+ 舊狀態雜湊值錯誤
+
+ 合約呼叫:
+ 地址: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
+ 函數: processTransaction(bytes _proof, bytes32[] _publicInputs)
+ 參數: (0x0000000000000000000000000000000000000000000000042ab5d6d1986846cf00000000000000000000000000000000000000000000000b75c020998797da7800000000000000000000000000000000000000000000000
+ ```
+
+#### `server/index.mjs` {#server-index-mjs-2}
+
+此檔案中的變更主要與建立實際證明並在鏈上提交有關。
+
+```js
+import { exec } from 'child_process'
+import util from 'util'
+
+const execPromise = util.promisify(exec)
+```
+
+我們需要使用 [Barretenberg 套件](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg) 來建立要傳送到鏈上的實際證明。 我們可以使用此套件,方法是執行命令列介面 (`bb`) 或使用 [JavaScript 庫 `bb.js`](https://www.npmjs.com/package/@aztec/bb.js)。 JavaScript 庫比原生執行程式碼慢得多,因此我們在此使用 [`exec`](https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback) 來使用命令列。
+
+請注意,如果您決定使用 `bb.js`,您需要使用與您正在使用的 Noir 版本相容的版本。 在撰寫本文時,目前的 Noir 版本 (1.0.0-beta.11) 使用 `bb.js` 版本 0.87。
+
+```js
+const zkBankAddress = process.env.ZKBANK_ADDRESS || "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512"
+```
+
+此處的地址是您從乾淨的 `anvil` 開始並遵循上述說明時取得的地址。
+
+```js
+const walletClient = createWalletClient({
+ chain: anvil,
+ transport: http(),
+ account: privateKeyToAccount("0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6")
+})
+```
+
+此私密金鑰是 `anvil` 中預先資助的預設帳戶之一。
+
+```js
+const generateProof = async (witness, fileID) => {
+```
+
+使用 `bb` 可執行檔產生證明。
+
+```js
+ const fname = `witness-${fileID}.gz`
+ await fs.writeFile(fname, witness)
+```
+
+將見證寫入檔案。
+
+```js
+ await execPromise(`bb prove -b ./noir/target/zkBank.json -w ${fname} -o ${fileID} --oracle_hash keccak --output_format fields`)
+```
+
+實際建立證明。 此步驟也會建立一個包含公開變數的檔案,但我們不需要該檔案。 我們已經從 `noir.execute` 取得這些變數。
+
+```js
+ const proof = "0x" + JSON.parse(await fs.readFile(`./${fileID}/proof_fields.json`)).reduce((a,b) => a+b, "").replace(/0x/g, "")
+```
+
+證明是一個 JSON 陣列,其中包含 `Field` 值,每個值都以十六進位值表示。 然而,我們需要將它作為單一的 `bytes` 值在交易中傳送,Viem 會以一個大的十六進位字串表示。 在此,我們透過串接所有值、移除所有 `0x`,然後在結尾加上一個來變更格式。
+
+```js
+ await execPromise(`rm -r ${fname} ${fileID}`)
+
+ return proof
+}
+```
+
+清理並傳回證明。
+
+```js
+const processMessage = async (message, signature) => {
+ .
+ .
+ .
+
+ const publicFields = noirResult.returnValue.map(x=>'0x' + x.slice(2).padStart(64, "0"))
+```
+
+公開欄位需要是 32 位元組值的陣列。 然而,由於我們需要將交易雜湊值分割到兩個 `Field` 值之間,因此它顯示為 16 位元組值。 在此,我們加上零,讓 Viem 了解它實際上是 32 位元組。
+
+```js
+ const proof = await generateProof(noirResult.witness, `${fromAddress}-${nonce}`)
+```
+
+每個地址只會使用每個 nonce 一次,因此我們可以使用 `fromAddress` 和 `nonce` 的組合作為見證檔案和輸出目錄的唯一識別碼。
+
+```js
+ try {
+ await zkBank.write.processTransaction([
+ proof, publicFields])
+ } catch (err) {
+ console.log(`驗證錯誤:${err}`)
+ throw Error("無法在鏈上驗證交易")
+ }
+ .
+ .
+ .
+}
+```
+
+將交易傳送到鏈上。
+
+#### `smart-contracts/src/ZkBank.sol` {#smart-contracts-src-zkbank-sol}
+
+這是接收交易的鏈上程式碼。
+
+```solidity
+// SPDX-License-Identifier: MIT
+
+pragma solidity >=0.8.21;
+
+import {HonkVerifier} from "./Verifier.sol";
+
+contract ZkBank {
+ HonkVerifier immutable myVerifier;
+ bytes32 currentStateHash;
+
+ constructor(address _verifierAddress, bytes32 _initialStateHash) {
+ currentStateHash = _initialStateHash;
+ myVerifier = HonkVerifier(_verifierAddress);
+ }
+```
+
+鏈上程式碼需要追蹤兩個變數:驗證器 (由 `nargo` 建立的獨立合約) 和目前的狀態雜湊。
+
+```solidity
+ event TransactionProcessed(
+ bytes32 indexed transactionHash,
+ bytes32 oldStateHash,
+ bytes32 newStateHash
+ );
+```
+
+每當狀態變更時,我們就會發出 `TransactionProcessed` 事件。
+
+```solidity
+ function processTransaction(
+ bytes calldata _proof,
+ bytes32[] calldata _publicFields
+ ) public {
+```
+
+此函式會處理交易。 它會以驗證器所需的格式取得證明 (作為 `bytes`) 和公開輸入 (作為 `bytes32` 陣列),以最小化鏈上處理並因此降低 gas 成本。
+
+```solidity
+ require(_publicInputs[0] == currentStateHash,
+ "舊狀態雜湊值錯誤");
+```
+
+零知識證明需要證明交易從我們目前的雜湊變更為新的雜湊。
+
+```solidity
+ myVerifier.verify(_proof, _publicFields);
+```
+
+呼叫驗證器合約以驗證零知識證明。 如果零知識證明錯誤,此步驟會還原交易。
+
+```solidity
+ currentStateHash = _publicFields[1];
+
+ emit TransactionProcessed(
+ _publicFields[2]<<128 | _publicFields[3],
+ _publicFields[0],
+ _publicFields[1]
+ );
+ }
+}
+```
+
+如果一切都檢查無誤,請將狀態雜湊更新為新值,並發出 `TransactionProcessed` 事件。
+
+## 中心化元件的濫用 {#abuses}
+
+資訊安全包含三個屬性:
+
+- _機密性_,使用者無法讀取他們未經授權讀取的資訊。
+- _完整性_,資訊不能被授權使用者以外的人以未經授權的方式變更。
+- _可用性_,授權使用者可以使用系統。
+
+在此系統上,完整性是透過零知識證明提供的。 可用性更難保證,而機密性則不可能,因為銀行必須知道每個帳戶的餘額和所有交易。 無法阻止擁有資訊的實體分享該資訊。
+
+也許可以使用 [隱身地址](https://vitalik.eth.limo/general/2023/01/20/stealth.html) 建立一個真正機密的銀行,但這超出了本文的範圍。
+
+### 不實資訊 {#false-info}
+
+伺服器違反完整性的一種方式是在 [要求資料](https://github.com/qbzzt/250911-zk-bank/blob/03-smart-contracts/server/index.mjs#L278-L291) 時提供不實資訊。
+
+為了解決這個問題,我們可以編寫第二個 Noir 程式,該程式接收帳戶作為私密輸入,並接收要求資訊的地址作為公開輸入。 輸出是該地址的餘額和 nonce,以及帳戶的雜湊。
+
+當然,此證明無法在鏈上驗證,因為我們不想在鏈上張貼 nonce 和餘額。 然而,它可以由在瀏覽器中執行的用戶端程式碼來驗證。
+
+### 強制交易 {#forced-txns}
+
+確保 L2 可用性和防止審查的通常機制是 [強制交易](https://docs.optimism.io/stack/transactions/forced-transaction)。 但強制交易與零知識證明不相容。 伺服器是唯一可以驗證交易的實體。
+
+我們可以修改 `smart-contracts/src/ZkBank.sol` 以接受強制交易,並防止伺服器在處理它們之前變更狀態。 然而,這會讓我們面臨簡單的阻斷服務攻擊。 如果強制交易無效且因此無法處理,該怎麼辦?
+
+解決方案是擁有一個零知識證明,證明強制交易是無效的。 這給伺服器三個選項:
+
+- 處理強制交易,提供一個零知識證明,證明它已處理,並提供新的狀態雜湊。
+- 拒絕強制交易,並向合約提供一個零知識證明,證明該交易無效 (未知地址、錯誤的 nonce 或餘額不足)。
+- 忽略強制交易。 無法強制伺服器實際處理交易,但這表示整個系統都不可用。
+
+#### 可用性保證金 {#avail-bonds}
+
+在實際的實作中,可能會有某種獲利動機來維持伺服器運作。 我們可以透過讓伺服器發布可用性保證金來加強此誘因,如果強制交易未在特定時間內處理,任何人都可以銷毀該保證金。
+
+### 不良的 Noir 程式碼 {#bad-noir-code}
+
+通常,為了讓大家信任智能合約,我們會將原始程式碼上傳到 [區塊瀏覽器](https://eth.blockscout.com/address/0x7D16d2c4e96BCFC8f815E15b771aC847EcbDB48b?tab=contract)。 然而,在零知識證明的情況下,這是不夠的。
+
+`Verifier.sol` 包含驗證金鑰,這是 Noir 程式的一個函數。 然而,該金鑰並未告訴我們 Noir 程式是什麼。 為了真正擁有一個可信賴的解決方案,您需要上傳 Noir 程式 (以及建立它的版本)。 否則,零知識證明可能反映出不同的程式,一個有後門的程式。
+
+在區塊瀏覽器允許我們上傳和驗證 Noir 程式之前,您應該自己動手 (最好上傳到 [IPFS](/developers/tutorials/ipfs-decentralized-ui/))。 然後,有經驗的使用者將能夠下載原始程式碼,自己編譯,建立 `Verifier.sol`,並驗證它是否與鏈上的版本相同。
+
+## 結論 {#conclusion}
+
+Plasma 類型的應用程式需要一個中心化元件作為資訊儲存。 這會帶來潛在的漏洞,但作為回報,它讓我們能夠以區塊鏈本身無法提供的方式保護隱私。 透過零知識證明,我們可以確保完整性,並可能使執行中心化元件的人在維持可用性方面具有經濟優勢。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
+
+## 致謝 {#acknowledgements}
+
+- Josh Crites 閱讀了本文的草稿,並幫助我解決了一個棘手的 Noir 問題。
+
+任何剩餘的錯誤都由我負責。
diff --git a/public/content/translations/zh-tw/developers/tutorials/calling-a-smart-contract-from-javascript/index.md b/public/content/translations/zh-tw/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
new file mode 100644
index 00000000000..9472ebc4309
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
@@ -0,0 +1,131 @@
+---
+title: 從 JavaScript 呼叫智能合約
+description: 如何使用 JavaScript 呼叫智能合約函式:以 Dai 代幣為例
+author: jdourlens
+tags: [ "交易", "前端", "JavaScript", "web3.js" ]
+skill: beginner
+lang: zh-tw
+published: 2020-04-19
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/calling-a-smart-contract-from-javascript/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+在本教學中,我們將了解如何從 JavaScript 呼叫[智能合約](/developers/docs/smart-contracts/)函式。 首先,我們會讀取智能合約的狀態 (例如 ERC20 持有者的餘額),然後透過代幣傳送來修改區塊鏈的狀態。 您應該已經熟悉如何[設定 JS 環境來與區塊鏈互動](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/)。
+
+在本範例中,我們將使用 DAI 代幣。為了測試,我們將使用 ganache-cli 來分叉區塊鏈,並解鎖一個已持有大量 DAI 的地址:
+
+```bash
+ganache-cli -f https://mainnet.infura.io/v3/[您的 INFURA 金鑰] -d -i 66 1 --unlock 0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81
+```
+
+要與智能合約互動,我們需要它的地址和 ABI:
+
+```js
+const ERC20TransferABI = [
+ {
+ constant: false,
+ inputs: [
+ {
+ name: "_to",
+ type: "address",
+ },
+ {
+ name: "_value",
+ type: "uint256",
+ },
+ ],
+ name: "transfer",
+ outputs: [
+ {
+ name: "",
+ type: "bool",
+ },
+ ],
+ payable: false,
+ stateMutability: "nonpayable",
+ type: "function",
+ },
+ {
+ constant: true,
+ inputs: [
+ {
+ name: "_owner",
+ type: "address",
+ },
+ ],
+ name: "balanceOf",
+ outputs: [
+ {
+ name: "balance",
+ type: "uint256",
+ },
+ ],
+ payable: false,
+ stateMutability: "view",
+ type: "function",
+ },
+]
+
+const DAI_ADDRESS = "0x6b175474e89094c44da98b954eedeac495271d0f"
+```
+
+在這個專案中,我們刪減了完整的 ERC20 ABI,只保留 `balanceOf` 和 `transfer` 函式,但您可以在[此處找到完整的 ERC20 ABI](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/)。
+
+接著我們需要實例化我們的智能合約:
+
+```js
+const web3 = new Web3("http://localhost:8545")
+
+const daiToken = new web3.eth.Contract(ERC20TransferABI, DAI_ADDRESS)
+```
+
+我們也將設定兩個地址:
+
+- 接收傳送的地址,以及
+- 我們已解鎖、將用來傳送的地址:
+
+```js
+const senderAddress = "0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81"
+const receiverAddress = "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+```
+
+在下個部分,我們將呼叫 `balanceOf` 函式,以擷取兩個地址目前持有的代幣數量。
+
+## 呼叫:從智能合約讀取數值 {#call-reading-value-from-a-smart-contract}
+
+第一個範例將呼叫一個「常數」(constant) 方法,並在以太坊虛擬機 (EVM) 中執行其智能合約方法,而不會傳送任何交易。 為此,我們將讀取一個地址的 ERC20 餘額。 [閱讀我們關於 ERC20 代幣的文章](/developers/tutorials/understand-the-erc-20-token-smart-contract/)。
+
+您可以存取已實例化的智能合約方法,只要您已提供其 ABI,方式如下:`yourContract.methods.methodname`。 使用 `call` 函式,您將會收到執行函式的結果。
+
+```js
+daiToken.methods.balanceOf(senderAddress).call(function (err, res) {
+ if (err) {
+ console.log("發生錯誤", err)
+ return
+ }
+ console.log("餘額為:", res)
+})
+```
+
+請記住,DAI ERC20 有 18 位小數,這意味著您需要去掉 18 個零才能得到正確的金額。 由於 JavaScript 無法處理大數值,`uint256` 會以字串的形式傳回。 如果您不確定[如何在 JS 中處理大數值,請查看我們關於 bignumber.js 的教學](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/)。
+
+## 傳送:傳送交易至智能合約函式 {#send-sending-a-transaction-to-a-smart-contract-function}
+
+在第二個範例中,我們將呼叫 DAI 智能合約的 `transfer` 函式,傳送 10 個 DAI 到我們的第二個地址。 `transfer` 函式接受兩個參數:接收方地址以及要傳送的代幣數量:
+
+```js
+daiToken.methods
+ .transfer(receiverAddress, "100000000000000000000")
+ .send({ from: senderAddress }, function (err, res) {
+ if (err) {
+ console.log("發生錯誤", err)
+ return
+ }
+ console.log("交易哈希:" + res)
+ })
+```
+
+此函式呼叫會傳回交易的哈希,該交易將被挖出並納入區塊鏈。 在以太坊上,交易哈希是可預測的——這就是我們能在交易執行前就取得其哈希的原因 ([在此了解哈希如何計算](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction))。
+
+由於該函式只是將交易提交到區塊鏈,我們要等到它被挖出並納入區塊鏈後,才能看到結果。 在下一個教學中,我們將學習[如何根據交易哈希,等待交易在區塊鏈上被執行](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
new file mode 100644
index 00000000000..444eada1f10
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
@@ -0,0 +1,585 @@
+---
+title: "為你的合約建立一個使用者介面"
+description: 我們將使用 TypeScript、React、Vite 和 Wagmi 等現代元件,探討一個現代但極簡的使用者介面,並學習如何將錢包連接到使用者介面、呼叫智能合約來讀取資訊、將交易傳送到智能合約,以及監視智能合約的事件來識別變更。
+author: 作者:Ori Pomerantz
+tags: [ "typescript", "反應", "vite", "wagmi", "前端" ]
+skill: beginner
+published: 2023-11-01
+lang: zh-tw
+sidebarDepth: 3
+---
+
+你找到了一個我們在以太坊生態系統中需要的功能。 你編寫了智能合約來實作它,甚至可能編寫了一些在鏈外執行的相關程式碼。 這太棒了! 不幸的是,如果沒有使用者介面,你就不會有任何使用者。而且在你上一次寫網站的時候,人們還在使用撥接數據機,JavaScript 還是個新玩意兒。
+
+這篇文章就是為你而寫的。 我假設你懂程式設計,可能也懂一點 JavaScript 和 HTML,但你的使用者介面技能已經生疏過時了。 我們將一起探討一個簡單的現代應用程式,讓你看看現在是怎麼做的。
+
+## 為什麼這很重要 {#why-important}
+
+理論上,你可以讓大家直接使用 [Etherscan](https://holesky.etherscan.io/address/0x432d810484add7454ddb3b5311f0ac2e95cecea8#writeContract) 或 [Blockscout](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=write_contract) 來與你的合約互動。 對於經驗豐富的以太坊使用者來說,這很棒。 但我們正試圖為 [另外十億人](https://blog.ethereum.org/2021/05/07/ethereum-for-the-next-billion) 提供服務。 如果沒有出色的使用者體驗,這一切都不會發生,而友善的使用者介面是其中的重要一環。
+
+## Greeter 應用程式 {#greeter-app}
+
+現代 UI 的運作背後有很多理論,也有 [很多好的網站](https://react.dev/learn/thinking-in-react) [對此進行了解釋](https://wagmi.sh/core/getting-started)。 與其重複那些網站已經完成的出色工作,我假設你更喜歡從做中學,從一個你可以實際操作的應用程式開始。 你仍然需要理論來完成工作,我們也會談到它——我們將逐一檢視原始檔,並在遇到問題時進行討論。
+
+### 安裝 {#installation}
+
+1. 如有需要,請將 [Holesky 區塊鏈](https://chainlist.org/?search=holesky&testnets=true) 新增到你的錢包,並 [取得測試 ETH](https://www.holeskyfaucet.io/)。
+
+2. 複製 GitHub 儲存庫。
+
+ ```sh
+ git clone https://github.com/qbzzt/20230801-modern-ui.git
+ ```
+
+3. 安裝必要的套件。
+
+ ```sh
+ cd 20230801-modern-ui
+ pnpm install
+ ```
+
+4. 啟動應用程式。
+
+ ```sh
+ pnpm dev
+ ```
+
+5. 瀏覽應用程式顯示的 URL。 在大多數情況下,它是 [http://localhost:5173/](http://localhost:5173/)。
+
+6. 你可以在 [區塊鏈瀏覽器](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contract) 上看到合約的原始碼,它是 Hardhat 的 Greeter 的一個稍作修改的版本。
+
+### 檔案走查 {#file-walk-through}
+
+#### `index.html` {#index-html}
+
+這個檔案是標準的 HTML 樣板,除了這一行,它匯入了腳本檔案。
+
+```html
+
+```
+
+#### `src/main.tsx` {#main-tsx}
+
+副檔名告訴我們這個檔案是一個用 [TypeScript](https://www.typescriptlang.org/) 編寫的 [React 元件](https://www.w3schools.com/react/react_components.asp),TypeScript 是 JavaScript 的一個擴充,支援 [型別檢查](https://en.wikipedia.org/wiki/Type_system#Type_checking)。 TypeScript 會被編譯成 JavaScript,所以我們可以用它來進行用戶端執行。
+
+```tsx
+import '@rainbow-me/rainbowkit/styles.css'
+import { RainbowKitProvider } from '@rainbow-me/rainbowkit'
+import * as React from 'react'
+import * as ReactDOM from 'react-dom/client'
+import { WagmiConfig } from 'wagmi'
+import { chains, config } from './wagmi'
+```
+
+匯入我們需要的庫程式碼。
+
+```tsx
+import { App } from './App'
+```
+
+匯入實作應用程式的 React 元件(見下文)。
+
+```tsx
+ReactDOM.createRoot(document.getElementById('root')!).render(
+```
+
+建立根 React 元件。 `render` 的參數是 [JSX](https://www.w3schools.com/react/react_jsx.asp),這是一種使用 HTML 和 JavaScript/TypeScript 的擴充語言。 這裡的驚嘆號告訴 TypeScript 元件:「你不知道 `document.getElementById('root')` 將會是 `ReactDOM.createRoot` 的一個有效參數,但別擔心——我是開發者,我告訴你它會是」。
+
+```tsx
+
+```
+
+應用程式將放在 [一個 `React.StrictMode` 元件](https://react.dev/reference/react/StrictMode) 內。 此元件會告訴 React 庫插入額外的偵錯檢查,這在開發過程中很有用。
+
+```tsx
+
+```
+
+應用程式也放在 [一個 `WagmiConfig` 元件](https://wagmi.sh/react/api/WagmiProvider) 內。 [wagmi (we are going to make it) 庫](https://wagmi.sh/) 將 React UI 定義與 [viem 庫](https://viem.sh/) 連接起來,用於編寫以太坊去中心化應用程式。
+
+```tsx
+
+```
+
+最後是 [一個 `RainbowKitProvider` 元件](https://www.rainbowkit.com/)。 此元件處理登入以及錢包和應用程式之間的通訊。
+
+```tsx
+
+```
+
+現在我們可以擁有應用程式的元件,它實際實作了 UI。 元件結尾的 `/>` 告訴 React,根據 XML 標準,此元件內部沒有任何定義。
+
+```tsx
+
+
+ ,
+)
+```
+
+當然,我們必須關閉其他元件。
+
+#### `src/App.tsx` {#app-tsx}
+
+```tsx
+import { ConnectButton } from '@rainbow-me/rainbowkit'
+import { useAccount } from 'wagmi'
+import { Greeter } from './components/Greeter'
+
+export function App() {
+```
+
+這是建立 React 元件的標準方法——定義一個函式,每次需要渲染時都會呼叫它。 這個函式通常在頂部有一些 TypeScript 或 JavaScript 程式碼,後面跟著一個回傳 JSX 程式碼的 `return` 陳述式。
+
+```tsx
+ const { isConnected } = useAccount()
+```
+
+這裡我們使用 [`useAccount`](https://wagmi.sh/react/api/hooks/useAccount) 來檢查我們是否透過錢包連接到區塊鏈。
+
+按照慣例,在 React 中,名為 `use...` 的函式是回傳某種資料的 [hook](https://www.w3schools.com/react/react_hooks.asp)。 當你使用這樣的 hook 時,你的元件不僅會取得資料,而且當該資料變更時,元件會用更新後的資訊重新渲染。
+
+```tsx
+ return (
+ <>
+```
+
+React 元件的 JSX _必須_回傳一個元件。 當我們有多個元件,並且沒有任何東西可以「自然地」包裝它們時,我們使用一個空元件(`<> ...` >\`) 來將它們變成單一元件。
+
+```tsx
+ Greeter
+
+```
+
+我們從 RainbowKit 取得 [`ConnectButton` 元件](https://www.rainbowkit.com/docs/connect-button)。 當我們未連接時,它會提供一個 `Connect Wallet` 按鈕,開啟一個說明錢包的強制回應視窗,讓你選擇使用哪一個錢包。 當我們連接時,它會顯示我們使用的區塊鏈、我們的帳戶地址和我們的 ETH 餘額。 我們可以使用這些顯示來切換網路或中斷連接。
+
+```tsx
+ {isConnected && (
+```
+
+當我們需要將實際的 JavaScript(或將被編譯為 JavaScript 的 TypeScript)插入 JSX 時,我們使用大括號(`{}`)。
+
+`a && b` 語法是 [`a ?` 的簡寫 b : a`](https://www.w3schools.com/react/react_es6_ternary.asp)。 也就是說,如果 `a`為 true,它的評估結果為`b`,否則它的評估結果為 `a`(可以是 `false`、`0\` 等)。 這是一種簡單的方法,可以告訴 React 只有在滿足特定條件時才顯示元件。
+
+在這種情況下,我們只想在使用者連接到區塊鏈時向使用者顯示 `Greeter`。
+
+```tsx
+
+ )}
+ >
+ )
+}
+```
+
+#### `src/components/Greeter.tsx` {#greeter-tsx}
+
+這個檔案包含了大部分的 UI 功能。 它包含了一些通常會放在多個檔案中的定義,但因為這是一個教學,所以程式的最佳化目標是為了初次閱讀時容易理解,而不是為了效能或易於維護。
+
+```tsx
+import { useState, ChangeEventHandler } from 'react'
+import { useNetwork,
+ useReadContract,
+ usePrepareContractWrite,
+ useContractWrite,
+ useContractEvent
+ } from 'wagmi'
+```
+
+我們使用這些庫函式。 同樣,它們在下面使用到的地方會進行解釋。
+
+```tsx
+import { AddressType } from 'abitype'
+```
+
+[`abitype` 庫](https://abitype.dev/) 為我們提供了各種以太坊資料型別的 TypeScript 定義,例如 [`AddressType`](https://abitype.dev/config#addresstype)。
+
+```tsx
+let greeterABI = [
+ .
+ .
+ .
+] as const // greeterABI
+```
+
+`Greeter` 合約的 ABI。
+如果你同時開發合約和 UI,通常會將它們放在同一個儲存庫中,並將 Solidity 編譯器產生的 ABI 作為一個檔案用在你的應用程式中。 然而,在這裡這不是必要的,因為合約已經開發完成,不會再變更。
+
+```tsx
+type AddressPerBlockchainType = {
+ [key: number]: AddressType
+}
+```
+
+TypeScript 是強型別的。 我們使用這個定義來指定 `Greeter` 合約在不同鏈上部署的地址。 鍵是一個數字(chainId),值是一個 `AddressType`(一個地址)。
+
+```tsx
+const contractAddrs: AddressPerBlockchainType = {
+ // Holesky
+ 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8',
+
+ // Sepolia
+ 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0'
+}
+```
+
+合約在兩個支援的網路上的地址:[Holesky](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contact_code) 和 [Sepolia](https://eth-sepolia.blockscout.com/address/0x7143d5c190F048C8d19fe325b748b081903E3BF0?tab=contact_code)。
+
+注意:實際上還有第三個定義,針對 Redstone Holesky,下面將會解釋。
+
+```tsx
+type ShowObjectAttrsType = {
+ name: string,
+ object: any
+}
+```
+
+這個型別被用作 `ShowObject` 元件(稍後解釋)的參數。 它包含物件的名稱和其值,這些是用於偵錯目的而顯示的。
+
+```tsx
+type ShowGreetingAttrsType = {
+ greeting: string | undefined
+}
+```
+
+在任何時候,我們可能知道問候語是什麼(因為我們從區塊鏈讀取了它),也可能不知道(因為我們還沒有收到它)。 所以有一個可以是字串或什麼都沒有的型別是很有用的。
+
+##### `Greeter` 元件 {#greeter-component}
+
+```tsx
+const Greeter = () => {
+```
+
+最後,我們來定義元件。
+
+```tsx
+ const { chain } = useNetwork()
+```
+
+關於我們正在使用的鏈的資訊,由 [wagmi](https://wagmi.sh/react/hooks/useNetwork) 提供。
+因為這是一個 hook (`use...`),所以每次這個資訊變更時,元件都會被重新繪製。
+
+```tsx
+ const greeterAddr = chain && contractAddrs[chain.id]
+```
+
+Greeter 合約的地址,它會因鏈而異(如果我們沒有鏈的資訊,或者我們在沒有該合約的鏈上,則為 `undefined`)。
+
+```tsx
+ const readResults = useReadContract({
+ address: greeterAddr,
+ abi: greeterABI,
+ functionName: "greet" , // 無引數
+ watch: true
+ })
+```
+
+[`useReadContract` hook](https://wagmi.sh/react/api/hooks/useReadContract) 從合約中讀取資訊。 你可以在 UI 中展開 `readResults` 來查看它回傳的確切資訊。 在這種情況下,我們希望它持續檢查,以便在問候語變更時得到通知。
+
+**注意:** 我們可以監聽 [`setGreeting` 事件](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=logs) 來得知問候語何時變更,並以此方式更新。 然而,雖然這樣可能更有效率,但它並不適用於所有情況。 當使用者切換到不同的鏈時,問候語也會變更,但此變更並無伴隨事件。 我們可以讓一部分程式碼監聽事件,另一部分來識別鏈的變更,但這會比僅僅設定 [`watch` 參數](https://wagmi.sh/react/api/hooks/useReadContract#watch-optional) 更複雜。
+
+```tsx
+ const [ newGreeting, setNewGreeting ] = useState("")
+```
+
+React 的 [`useState` hook](https://www.w3schools.com/react/react_usestate.asp) 讓我們可以指定一個狀態變數,其值在元件的多次渲染之間保持不變。 初始值是參數,此處為空字串。
+
+`useState` hook 回傳一個包含兩個值的清單:
+
+1. 狀態變數的目前值。
+2. 一個在需要時修改狀態變數的函式。 因為這是一個 hook,所以每次呼叫它時,元件都會重新渲染。
+
+在這種情況下,我們使用一個狀態變數來儲存使用者想要設定的新問候語。
+
+```tsx
+ const greetingChange : ChangeEventHandler = (evt) =>
+ setNewGreeting(evt.target.value)
+```
+
+這是當新問候語輸入欄位變更時的事件處理常式。 型別 [`ChangeEventHandler`](https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/forms_and_events/) 指定這是一個 HTML 輸入元素值變更的處理常式。 使用 `` 部分是因為這是一個 [泛型型別](https://www.w3schools.com/typescript/typescript_basic_generics.php)。
+
+```tsx
+ const preparedTx = usePrepareContractWrite({
+ address: greeterAddr,
+ abi: greeterABI,
+ functionName: 'setGreeting',
+ args: [ newGreeting ]
+ })
+ const workingTx = useContractWrite(preparedTx.config)
+```
+
+這是從用戶端角度提交區塊鏈交易的過程:
+
+1. 使用 [`eth_estimateGas`](https://docs.alchemy.com/reference/eth-estimategas) 將交易傳送到區塊鏈中的一個節點。
+2. 等待節點的回應。
+3. 收到回應後,要求使用者透過錢包簽署交易。 這一步驟_必須_在收到節點回應後進行,因為使用者在簽署交易前會看到交易的 gas 成本。
+4. 等待使用者核准。
+5. 再次傳送交易,這次使用 [`eth_sendRawTransaction`](https://docs.alchemy.com/reference/eth-sendrawtransaction)。
+
+步驟 2 可能會花費一段可觀的時間,在此期間,使用者會想知道他們的指令是否真的被使用者介面接收到,以及為什麼還沒有被要求簽署交易。 這會造成不好的使用者體驗(UX)。
+
+解決方案是使用 [prepare hook](https://wagmi.sh/react/prepare-hooks)。 每當參數變更時,立即向節點傳送 `eth_estimateGas` 請求。 然後,當使用者實際想要傳送交易時(在此例中是按下 **更新問候語**),gas 成本是已知的,使用者可以立即看到錢包頁面。
+
+```tsx
+ return (
+```
+
+現在我們終於可以建立要回傳的實際 HTML 了。
+
+```tsx
+ <>
+ Greeter
+ {
+ !readResults.isError && !readResults.isLoading &&
+
+ }
+
+```
+
+建立一個 `ShowGreeting` 元件(下面會解釋),但只有在成功從區塊鏈讀取問候語時才建立。
+
+```tsx
+
+```
+
+這是使用者可以設定新問候語的輸入文字欄位。 每當使用者按下一個鍵,我們就呼叫 `greetingChange`,它會再呼叫 `setNewGreeting`。 由於 `setNewGreeting` 來自 `useState` hook,它會導致 `Greeter` 元件再次被渲染。 這表示:
+
+- 我們需要指定 `value` 來保留新問候語的值,否則它會變回預設的空字串。
+- 每當 `newGreeting` 變更時,`usePrepareContractWrite` 就會被呼叫,這表示它在準備好的交易中永遠會擁有最新的 `newGreeting`。
+
+```tsx
+
+```
+
+如果沒有 `workingTx.write`,那麼我們仍在等待傳送問候語更新所需的資訊,所以按鈕是停用的。 如果有 `workingTx.write` 值,那麼這就是傳送交易時要呼叫的函式。
+
+```tsx
+
+
+
+
+ >
+ )
+}
+```
+
+最後,為了幫助你了解我們在做什麼,顯示我們使用的三個物件:
+
+- `readResults`
+- `preparedTx`
+- `workingTx`
+
+##### `ShowGreeting` 元件 {#showgreeting-component}
+
+此元件顯示
+
+```tsx
+const ShowGreeting = (attrs : ShowGreetingAttrsType) => {
+```
+
+一個元件函式接收一個包含該元件所有屬性的參數。
+
+```tsx
+ return {attrs.greeting}
+}
+```
+
+##### `ShowObject` 元件 {#showobject-component}
+
+為了提供資訊,我們使用 `ShowObject` 元件來顯示重要的物件(`readResults` 用於讀取問候語,`preparedTx` 和 `workingTx` 用於我們建立的交易)。
+
+```tsx
+const ShowObject = (attrs: ShowObjectAttrsType ) => {
+ const keys = Object.keys(attrs.object)
+ const funs = keys.filter(k => typeof attrs.object[k] == "function")
+ return <>
+
+```
+
+我們不希望用所有資訊來塞滿 UI,所以為了可以檢視或關閉它們,我們使用了 [`details`](https://www.w3schools.com/tags/tag_details.asp) 標籤。
+
+```tsx
+ {attrs.name}
+
+ {JSON.stringify(attrs.object, null, 2)}
+```
+
+大部分的欄位都是使用 [`JSON.stringify`](https://www.w3schools.com/js/js_json_stringify.asp) 來顯示的。
+
+```tsx
+
+ { funs.length > 0 &&
+ <>
+ 函式:
+
+```
+
+例外是函式,它們不是 [JSON 標準](https://www.json.org/json-en.html) 的一部分,所以必須分開顯示。
+
+```tsx
+ {funs.map((f, i) =>
+```
+
+在 JSX 中,`{` 大括號 `}` 內的程式碼會被解讀為 JavaScript。 然後,`(` 普通括號 `)` 內的程式碼會再次被解讀為 JSX。
+
+```tsx
+ (- {f}
)
+ )}
+```
+
+React 要求 [DOM 樹](https://www.w3schools.com/js/js_htmldom.asp) 中的標籤必須有不同的識別碼。 這表示同一個標籤的子標籤(在此例中為 [無序清單](https://www.w3schools.com/tags/tag_ul.asp))需要有不同的 `key` 屬性。
+
+```tsx
+
+ >
+ }
+
+ >
+}
+```
+
+結束各種 HTML 標籤。
+
+##### 最後的 `export` {#the-final-export}
+
+```tsx
+export { Greeter }
+```
+
+我們需要為應用程式匯出的就是 `Greeter` 元件。
+
+#### `src/wagmi.ts` {#wagmi-ts}
+
+最後,與 WAGMI 相關的各種定義都在 `src/wagmi.ts` 中。 我不會在這裡解釋所有內容,因為大部分都是樣板程式碼,你不太可能需要變更。
+
+這裡的程式碼與 [github 上的](https://github.com/qbzzt/20230801-modern-ui/blob/main/src/wagmi.ts) 不完全相同,因為在文章後面我們會新增另一條鏈 ([Redstone Holesky](https://redstone.xyz/docs/network-info))。
+
+```ts
+import { getDefaultWallets } from '@rainbow-me/rainbowkit'
+import { configureChains, createConfig } from 'wagmi'
+import { holesky, sepolia } from 'wagmi/chains'
+```
+
+匯入應用程式支援的區塊鏈。 你可以在 [viem 的 github](https://github.com/wagmi-dev/viem/tree/main/src/chains/definitions) 中看到支援的鏈的清單。
+
+```ts
+import { publicProvider } from 'wagmi/providers/public'
+
+const walletConnectProjectId = 'c96e690bb92b6311e8e9b2a6a22df575'
+```
+
+要能使用 [WalletConnect](https://walletconnect.com/),你的應用程式需要一個專案 ID。 你可以在 [cloud.walletconnect.com](https://cloud.walletconnect.com/sign-in) 上取得它。
+
+```ts
+const { chains, publicClient, webSocketPublicClient } = configureChains(
+ [ holesky, sepolia ],
+ [
+ publicProvider(),
+ ],
+)
+
+const { connectors } = getDefaultWallets({
+ appName: 'My wagmi + RainbowKit App',
+ chains,
+ projectId: walletConnectProjectId,
+})
+
+export const config = createConfig({
+ autoConnect: true,
+ connectors,
+ publicClient,
+ webSocketPublicClient,
+})
+
+export { chains }
+```
+
+### 新增另一條區塊鏈 {#add-blockchain}
+
+現今有很多 [L2 擴展解決方案](/layer-2/),你可能想要支援一些 viem 尚未支援的方案。 要做到這點,你需要修改 `src/wagmi.ts`。 這些說明解釋了如何新增 [Redstone Holesky](https://redstone.xyz/docs/network-info)。
+
+1. 從 viem 匯入 `defineChain` 型別。
+
+ ```ts
+ import { defineChain } from 'viem'
+ ```
+
+2. 新增網路定義。
+
+ ```ts
+ const redstoneHolesky = defineChain({
+ id: 17_001,
+ name: 'Redstone Holesky',
+ network: 'redstone-holesky',
+ nativeCurrency: {
+ decimals: 18,
+ name: 'Ether',
+ symbol: 'ETH',
+ },
+ rpcUrls: {
+ default: {
+ http: ['https://rpc.holesky.redstone.xyz'],
+ webSocket: ['wss://rpc.holesky.redstone.xyz/ws'],
+ },
+ public: {
+ http: ['https://rpc.holesky.redstone.xyz'],
+ webSocket: ['wss://rpc.holesky.redstone.xyz/ws'],
+ },
+ },
+ blockExplorers: {
+ default: { name: 'Explorer', url: 'https://explorer.holesky.redstone.xyz' },
+ },
+ })
+ ```
+
+3. 將新鏈新增到 `configureChains` 呼叫中。
+
+ ```ts
+ const { chains, publicClient, webSocketPublicClient } = configureChains(
+ [ holesky, sepolia, redstoneHolesky ],
+ [ publicProvider(), ],
+ )
+ ```
+
+4. 確保應用程式知道你的合約在新網路上的地址。 在這種情況下,我們修改 `src/components/Greeter.tsx`:
+
+ ```ts
+ const contractAddrs : AddressPerBlockchainType = {
+ // Holesky
+ 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8',
+
+ // Redstone Holesky
+ 17001: '0x4919517f82a1B89a32392E1BF72ec827ba9986D3',
+
+ // Sepolia
+ 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0'
+ }
+ ```
+
+## 結論 {#conclusion}
+
+當然,你並不是真的在乎為 `Greeter` 提供使用者介面。 你想要為你自己的合約建立一個使用者介面。 要建立你自己的應用程式,請執行以下步驟:
+
+1. 指定建立一個 wagmi 應用程式。
+
+ ```sh copy
+ pnpm create wagmi
+ ```
+
+2. 為應用程式命名。
+
+3. 選擇 **React** 框架。
+
+4. 選擇 **Vite** 變體。
+
+5. 你可以 [新增 Rainbow kit](https://www.rainbowkit.com/docs/installation#manual-setup)。
+
+現在去讓你的合約為廣大世界所用吧。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
+
diff --git a/public/content/translations/zh-tw/developers/tutorials/deploying-your-first-smart-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/deploying-your-first-smart-contract/index.md
new file mode 100644
index 00000000000..f48cfdada1a
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/deploying-your-first-smart-contract/index.md
@@ -0,0 +1,95 @@
+---
+title: 部署你的第一個智能合約
+description: 在以太坊測試網上部署你的第一個智能合約的簡介
+author: "jdourlens"
+tags: [ "智能合約", "remix", "穩固", "部署" ]
+skill: beginner
+lang: zh-tw
+published: 2020-04-03
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/deploying-your-first-smart-contract/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+我想你和我們一樣興奮,都想在以太坊區塊鏈上[部署](/developers/docs/smart-contracts/deploying/)並與你的第一個[智能合約](/developers/docs/smart-contracts/)互動。
+
+別擔心,因為這是我們的第一個智能合約,我們會在[本地測試網](/developers/docs/networks/)上部署它,所以你部署和盡情操作它都不需要任何費用。
+
+## 撰寫我們的合約 {#writing-our-contract}
+
+第一步是[訪問 Remix](https://remix.ethereum.org/) 並建立一個新檔案。 在 Remix 介面的左上角新增一個新檔案,並輸入你想要的檔案名稱。
+
+
+
+在新檔案中,我們將貼上以下程式碼:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >=0.5.17;
+
+contract Counter {
+
+ // 公開的無正負號整數,用來記錄次數
+ uint256 public count = 0;
+
+ // 遞增計數器的函式
+ function increment() public {
+ count += 1;
+ }
+
+ // 取得計數值的 getter,非必要
+ function getCount() public view returns (uint256) {
+ return count;
+ }
+
+}
+```
+
+如果你習慣寫程式,你應該可以輕易猜出這個程式的功能。 以下是逐行說明:
+
+- 第 4 行:我們定義了一個名為 `Counter` 的合約。
+- 第 7 行:我們的合約儲存一個名為 `count` 的無正負號整數,初始值為 0。
+- 第 10 行:第一個函式會修改合約的狀態,並透過 `increment()` 遞增我們的 `count` 變數。
+- 第 15 行:第二個函式只是一個 getter,用來從智能合約外部讀取 `count` 變數的值。 請注意,因為我們將 `count` 變數定義為 public (公開),所以這不是必要的,只是作為範例展示。
+
+這就是我們第一個簡單的智能合約。 你可能知道,它看起來像 Java 或 C++ 等物件導向程式設計 (OOP) 語言中的類別 (class)。 現在可以來操作我們的合約了。
+
+## 部署我們的合約 {#deploying-our-contract}
+
+既然我們寫好了第一個智能合約,現在就要將它部署到區塊鏈上,以便進行操作。
+
+[在區塊鏈上部署智能合約](/developers/docs/smart-contracts/deploying/),實際上只是傳送一筆交易,其中包含已編譯智能合約的程式碼,而無須指定任何接收者。
+
+首先,我們要點擊左側的編譯圖示來[編譯合約](/developers/docs/smart-contracts/compiling/):
+
+
+
+然後點擊編譯按鈕:
+
+
+
+你可以選擇「自動編譯」(Auto compile) 選項,這樣每當你在文字編輯器中儲存內容時,合約就會自動編譯。
+
+然後前往「部署及執行交易」(deploy and run transactions) 畫面:
+
+
+
+進入「部署及執行交易」畫面後,再次確認你的合約名稱是否出現,然後點擊「部署」(Deploy)。 如你在頁面頂端所見,目前環境是「JavaScript VM」(JavaScript 虛擬機),這代表我們將在一個本地測試鏈上部署我們的智能合約並與之互動,以便能更快地測試,且無須支付任何費用。
+
+
+
+點擊「部署」(Deploy) 按鈕後,你會在底部看到你的合約。 點擊左邊的箭頭將它展開,我們便能看到合約的內容。 這就是我們的 `count` 變數、`increment()` 函式和 `getCounter()` getter。
+
+如果你點擊 `count` 或 `getCount` 按鈕,它會實際擷取合約的 `count` 變數內容並顯示出來。 因為我們還沒呼叫 `increment` 函式,所以它應該會顯示 0。
+
+
+
+現在讓我們點擊按鈕來呼叫 `increment` 函式。 你會在視窗底部看到所執行交易的紀錄。 你會發現,當你按下擷取資料的按鈕時,紀錄會與按下 `increment` 按鈕時不同。 這是因為在區塊鏈上讀取資料不需要任何交易 (寫入) 或費用。 因為只有修改區塊鏈的狀態才需要進行交易:
+
+
+
+按下 increment 按鈕會產生一筆交易來呼叫我們的 `increment()` 函式,之後如果我們回頭點擊 count 或 getCount 按鈕,我們就會讀取到智能合約已更新的狀態,其中 count 變數的值會大於 0。
+
+
+
+在下一篇教學中,我們將介紹[如何在你的智能合約中新增事件](/developers/tutorials/logging-events-smart-contracts/)。 記錄事件是個便利的方法,可以對你的智能合約進行除錯,並了解呼叫函式時發生了什麼事。
diff --git a/public/content/translations/zh-tw/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md b/public/content/translations/zh-tw/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md
new file mode 100644
index 00000000000..d6929e09ad8
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md
@@ -0,0 +1,363 @@
+---
+title: 如何在本地多用戶端測試網上開發和測試 dApp
+description: 本指南將首先引導您完成如何實例化和設定多用戶端的本地以太坊測試網,然後再使用該測試網來部署與測試 dApp。
+author: "Tedi Mitiku"
+tags: [ "用戶端", "節點", "智能合約", "可組合性", "共識層", "執行層", "測試" ]
+skill: intermediate
+lang: zh-tw
+published: 2023-04-11
+---
+
+## 介紹 {#introduction}
+
+本指南將引導您完成實例化可設定的本地以太坊測試網、將智能合約部署到其中,並使用該測試網對您的 dApp 執行測試的過程。 本指南專為希望在部署到即時測試網或主網之前,針對不同的網路設定在本地開發和測試其 dApp 的 dApp 開發者而設計。
+
+在本指南中,您將會:
+
+- 使用 [Kurtosis](https://www.kurtosis.com/) 和 [`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package) 實例化一個本地以太坊測試網,
+- 將您的 Hardhat dApp 開發環境連接到本地測試網以編譯、部署和測試 dApp,以及
+- 設定本地測試網,包括節點數量和特定的 EL/CL 用戶端配對等參數,以實現針對各種網路設定的開發和測試工作流程。
+
+### 什麼是 Kurtosis? {#what-is-kurtosis}
+
+[Kurtosis](https://www.kurtosis.com/) 是一個可組合的建構系統,專為設定多容器測試環境而設計。 它特別允許開發者創建需要動態設定邏輯的可重現環境,例如區塊鏈測試網。
+
+在本指南中,Kurtosis eth-network-package 會啟動一個本地以太坊測試網,支援 [`geth`](https://geth.ethereum.org/) 執行層 (EL) 用戶端,以及 [`teku`](https://consensys.io/teku)、[`lighthouse`](https://lighthouse.sigmaprime.io/) 和 [`lodestar`](https://lodestar.chainsafe.io/) 共識層 (CL) 用戶端。 此套件可作為 Hardhat Network、Ganache 和 Anvil 等框架中網路的可設定和可組合替代方案。 Kurtosis 為開發者提供了對其使用的測試網更大的控制權和靈活性,這也是[以太坊基金會使用 Kurtosis 測試合併](https://www.kurtosis.com/blog/testing-the-ethereum-merge)並繼續使用它來測試網路升級的主要原因。
+
+## 設定 Kurtosis {#setting-up-kurtosis}
+
+在繼續之前,請確定您已經:
+
+- 在您的本地機器上[安裝並啟動 Docker 引擎](https://docs.kurtosis.com/install/#i-install--start-docker)
+- [安裝 Kurtosis CLI](https://docs.kurtosis.com/install#ii-install-the-cli)(如果您已安裝 CLI,則將其升級到最新版本)
+- 安裝 [Node.js](https://nodejs.org/en)、[yarn](https://classic.yarnpkg.com/lang/en/docs/install/#mac-stable) 和 [npx](https://www.npmjs.com/package/npx)(為您的 dApp 環境)
+
+## 實例化本地以太坊測試網 {#instantiate-testnet}
+
+要啟動本地以太坊測試網,請執行:
+
+```python
+kurtosis --enclave local-eth-testnet run github.com/kurtosis-tech/eth-network-package
+```
+
+注意:此命令使用 `--enclave` 標誌將您的網路命名為「local-eth-testnet」。
+
+Kurtosis 在解譯、驗證和執行指令時,會印出其在幕後執行的步驟。 最後,您應該會看到類似以下的輸出:
+
+```python
+INFO[2023-04-04T18:09:44-04:00] ======================================================
+INFO[2023-04-04T18:09:44-04:00] || Created enclave: local-eth-testnet ||
+INFO[2023-04-04T18:09:44-04:00] ======================================================
+Name: local-eth-testnet
+UUID: 39372d756ae8
+Status: RUNNING
+Creation Time: Tue, 04 Apr 2023 18:09:03 EDT
+
+========================================= Files Artifacts =========================================
+UUID Name
+d4085a064230 cl-genesis-data
+1c62cb792e4c el-genesis-data
+bd60489b73a7 genesis-generation-config-cl
+b2e593fe5228 genesis-generation-config-el
+d552a54acf78 geth-prefunded-keys
+5f7e661eb838 prysm-password
+054e7338bb59 validator-keystore-0
+
+========================================== User Services ==========================================
+UUID Name Ports Status
+e20f129ee0c5 cl-client-0-beacon http: 4000/tcp -> RUNNING
+ metrics: 5054/tcp ->
+ tcp-discovery: 9000/tcp -> 127.0.0.1:54263
+ udp-discovery: 9000/udp -> 127.0.0.1:60470
+a8b6c926cdb4 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:54267 RUNNING
+ metrics: 5064/tcp ->
+d7b802f623e8 el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:54253 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:54251
+ tcp-discovery: 30303/tcp -> 127.0.0.1:54254
+ udp-discovery: 30303/udp -> 127.0.0.1:53834
+ ws: 8546/tcp -> 127.0.0.1:54252
+514a829c0a84 prelaunch-data-generator-1680646157905431468 STOPPED
+62bd62d0aa7a prelaunch-data-generator-1680646157915424301 STOPPED
+05e9619e0e90 prelaunch-data-generator-1680646157922872635 STOPPED
+
+```
+
+恭喜! 您透過 Docker 使用 Kurtosis 實例化了一個本地以太坊測試網,其中包含一個 CL(`lighthouse`)和一個 EL 用戶端(`geth`)。
+
+### 回顧 {#review-instantiate-testnet}
+
+在本節中,您執行了一個指令,指示 Kurtosis 使用[遠端託管在 GitHub 上的 `eth-network-package`](https://github.com/kurtosis-tech/eth-network-package) 在 Kurtosis [Enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/) 中啟動一個本地以太坊測試網。 在您的 enclave 中,您會找到「檔案成品」和「使用者服務」。
+
+您 enclave 中的[檔案成品](https://docs.kurtosis.com/advanced-concepts/files-artifacts/)包含所有用於啟動 EL 和 CL 用戶端的已生成和已使用的資料。 這些資料是使用從這個 [Docker 映像檔](https://github.com/ethpandaops/ethereum-genesis-generator)建構的 `prelaunch-data-generator` 服務建立的
+
+使用者服務會顯示在您 enclave 中運作的所有容器化服務。 您會注意到已建立一個單一節點,該節點同時具有 EL 用戶端和 CL 用戶端。
+
+## 將您的 dApp 開發環境連接到本地以太坊測試網 {#connect-your-dapp}
+
+### 設定 dApp 開發環境 {#set-up-dapp-env}
+
+既然您已擁有一個正在運行的本地測試網,您可以將您的 dApp 開發環境連接到本地測試網來使用。 本指南將使用 Hardhat 框架將一個二十一點 dApp 部署到您的本地測試網。
+
+要設定您的 dApp 開發環境,請複製包含我們的範例 dApp 的儲存庫並安裝其相依性,執行:
+
+```python
+git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-kurtosis/smart-contract-example && yarn
+```
+
+這裡使用的 [smart-contract-example](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example) 資料夾包含使用 [Hardhat](https://hardhat.org/) 框架的 dApp 開發者的典型設定:
+
+- [`contracts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/contracts) 包含一些用於二十一點 dApp 的簡單智能合約
+- [`scripts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/scripts) 包含一個用於將代幣合約部署到您的本地以太坊網路的腳本
+- [`test/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/test) 包含一個針對您的代幣合約的簡單 .js 測試,以確認我們的二十一點 dApp 中的每個玩家都已為他們鑄造了 1000 個代幣
+- [`hardhat.config.ts`](https://github.com/kurtosis-tech/awesome-kurtosis/blob/main/smart-contract-example/hardhat.config.ts) 設定您的 Hardhat
+
+### 設定 Hardhat 以使用本地測試網 {#configure-hardhat}
+
+設定好您的 dApp 開發環境後,您現在將連接 Hardhat 以使用 Kurtosis 產生的本地以太坊測試網。 為此,請將您的 `hardhat.config.ts` 設定檔中 `localnet` 結構中的 `<$YOUR_PORT>` 替換為任何 `el-client-` 服務輸出的 RPC URI 的連接埠。 在這個範例中,連接埠會是 `64248`。 您的連接埠會不同。
+
+`hardhat.config.ts` 中的範例:
+
+```js
+localnet: {
+url: 'http://127.0.0.1:<$YOUR_PORT>',// TODO:將 $YOUR_PORT 替換為 ETH NETWORK KURTOSIS 套件產生的節點 URI 的連接埠
+
+// 這些是與 eth-network-package 創建的預先注資測試帳戶相關的私鑰
+//
+accounts: [
+ "ef5177cd0b6b21c87db5a0bf35d4084a8a57a9d6a064f86d51ac85f2b873a4e2",
+ "48fcc39ae27a0e8bf0274021ae6ebd8fe4a0e12623d61464c498900b28feb567",
+ "7988b3a148716ff800414935b305436493e1f25237a2a03e5eebc343735e2f31",
+ "b3c409b6b0b3aa5e65ab2dc1930534608239a478106acf6f3d9178e9f9b00b35",
+ "df9bb6de5d3dc59595bcaa676397d837ff49441d211878c024eabda2cd067c9f",
+ "7da08f856b5956d40a72968f93396f6acff17193f013e8053f6fbb6c08c194d6",
+ ],
+},
+```
+
+儲存檔案後,您的 Hardhat dApp 開發環境現在已連接到您的本地以太坊測試網! 您可以透過執行以下命令來驗證您的測試網是否正常運作:
+
+```python
+npx hardhat balances --network localnet
+```
+
+輸出應該類似這樣:
+
+```python
+0x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766 has balance 10000000000000000000000000
+0x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A has balance 10000000000000000000000000
+0xdF8466f277964Bb7a0FFD819403302C34DCD530A has balance 10000000000000000000000000
+0x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50 has balance 10000000000000000000000000
+0x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc has balance 10000000000000000000000000
+0x1F6298457C5d76270325B724Da5d1953923a6B88 has balance 10000000000000000000000000
+```
+
+這證實了 Hardhat 正在使用您的本地測試網,並偵測到由 `eth-network-package` 創建的預先注資帳戶。
+
+### 在本地部署和測試您的 dApp {#deploy-and-test-dapp}
+
+在 dApp 開發環境完全連接到本地以太坊測試網後,您現在可以使用本地測試網對您的 dApp 執行開發和測試工作流程。
+
+要編譯和部署 `ChipToken.sol` 智能合約以進行本地原型設計和開發,請執行:
+
+```python
+npx hardhat compile
+npx hardhat run scripts/deploy.ts --network localnet
+```
+
+輸出應該看起來像:
+
+```python
+ChipToken deployed to: 0xAb2A01BC351770D09611Ac80f1DE076D56E0487d
+```
+
+現在嘗試對您的本地 dApp 執行 `simple.js` 測試,以確認我們的二十一點 dApp 中的每個玩家都已為他們鑄造了 1000 個代幣:
+
+輸出應該類似這樣:
+
+```python
+npx hardhat test --network localnet
+```
+
+輸出應該類似這樣:
+
+```python
+ChipToken
+ mint
+ ✔ 應為玩家一號鑄造 1000 枚籌碼
+
+ 1 個通過 (654ms)
+```
+
+### 回顧 {#review-dapp-workflows}
+
+至此,您已經設定了一個 dApp 開發環境,將其連接到由 Kurtosis 創建的本地以太坊網路,並已對您的 dApp 進行了編譯、部署和簡單的測試。
+
+現在讓我們來探索如何設定底層網路,以便在不同的網路設定下測試我們的 dApp。
+
+## 設定本地以太坊測試網 {#configure-testnet}
+
+### 變更用戶端設定和節點數量 {#configure-client-config-and-num-nodes}
+
+您的本地以太坊測試網可以設定為使用不同的 EL 和 CL 用戶端配對,以及不同數量的節點,這取決於您要開發或測試的場景和特定的網路設定。 這意味著,一旦設定完成,您就可以啟動一個客製化的本地測試網,並用它來執行相同的工作流程(部署、測試等) 在各種網路設定下,確保一切如預期般運作。 要了解更多關於您可以修改的其他參數,請造訪此連結。
+
+試試看! 您可以透過 JSON 檔案將各種設定選項傳遞給 `eth-network-package`。 這個網路參數 JSON 檔案提供了 Kurtosis 用於設定本地以太坊網路的特定設定。
+
+取得預設設定檔案並進行編輯,以啟動兩個具有不同 EL/CL 配對的節點:
+
+- 節點 1 使用 `geth`/`lighthouse`
+- 節點 2 使用 `geth`/`lodestar`
+- 節點 3 使用 `geth`/`teku`
+
+此設定建立了一個異構的以太坊節點實作網路,用於測試您的 dApp。 您的設定檔現在應該如下所示:
+
+```yaml
+{
+ "participants":
+ [
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "lighthouse",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "lodestar",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "teku",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ ],
+ "network_params":
+ {
+ "preregistered_validator_keys_mnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete",
+ "num_validator_keys_per_node": 64,
+ "network_id": "3151908",
+ "deposit_contract_address": "0x4242424242424242424242424242424242424242",
+ "seconds_per_slot": 12,
+ "genesis_delay": 120,
+ "capella_fork_epoch": 5,
+ },
+}
+```
+
+每個 `participants` 結構對應網路中的一個節點,因此 3 個 `participants` 結構將告知 Kurtosis 在您的網路中啟動 3 個節點。 每個 `participants` 結構將允許您指定該特定節點使用的 EL 和 CL 配對。
+
+`network_params` 結構設定了用於為每個節點建立創世檔的網路設定,以及其他設定,例如網路的每時隙秒數。
+
+將您編輯的參數檔案儲存到您希望的任何目錄中(在下面的範例中,它被儲存到桌面),然後透過執行以下命令來執行您的 Kurtosis 套件:
+
+```python
+kurtosis clean -a && kurtosis run --enclave local-eth-testnet github.com/kurtosis-tech/eth-network-package "$(cat ~/eth-network-params.json)"
+```
+
+注意:這裡使用 `kurtosis clean -a` 命令來指示 Kurtosis 在啟動新的測試網之前銷毀舊的測試網及其內容。
+
+同樣,Kurtosis 會運作一會兒,並印出正在進行的各個步驟。 最終,輸出應該會像這樣:
+
+```python
+Starlark code successfully run. No output was returned.
+INFO[2023-04-07T11:43:16-04:00] ==========================================================
+INFO[2023-04-07T11:43:16-04:00] || Created enclave: local-eth-testnet ||
+INFO[2023-04-07T11:43:16-04:00] ==========================================================
+Name: local-eth-testnet
+UUID: bef8c192008e
+Status: RUNNING
+Creation Time: Fri, 07 Apr 2023 11:41:58 EDT
+
+========================================= Files Artifacts =========================================
+UUID Name
+cc495a8e364a cl-genesis-data
+7033fcdb5471 el-genesis-data
+a3aef43fc738 genesis-generation-config-cl
+8e968005fc9d genesis-generation-config-el
+3182cca9d3cd geth-prefunded-keys
+8421166e234f prysm-password
+d9e6e8d44d99 validator-keystore-0
+23f5ba517394 validator-keystore-1
+4d28dea40b5c validator-keystore-2
+
+========================================== User Services ==========================================
+UUID Name Ports Status
+485e6fde55ae cl-client-0-beacon http: 4000/tcp -> http://127.0.0.1:65010 RUNNING
+ metrics: 5054/tcp -> http://127.0.0.1:65011
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65012
+ udp-discovery: 9000/udp -> 127.0.0.1:54455
+73739bd158b2 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:65016 RUNNING
+ metrics: 5064/tcp -> http://127.0.0.1:65017
+1b0a233cd011 cl-client-1-beacon http: 4000/tcp -> 127.0.0.1:65021 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65023
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65024
+ udp-discovery: 9000/udp -> 127.0.0.1:56031
+ validator-metrics: 5064/tcp -> 127.0.0.1:65022
+949b8220cd53 cl-client-1-validator http: 4000/tcp -> 127.0.0.1:65028 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65030
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65031
+ udp-discovery: 9000/udp -> 127.0.0.1:60784
+ validator-metrics: 5064/tcp -> 127.0.0.1:65029
+c34417bea5fa cl-client-2 http: 4000/tcp -> 127.0.0.1:65037 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65035
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65036
+ udp-discovery: 9000/udp -> 127.0.0.1:63581
+e19738e6329d el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:64986 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:64988
+ tcp-discovery: 30303/tcp -> 127.0.0.1:64987
+ udp-discovery: 30303/udp -> 127.0.0.1:55706
+ ws: 8546/tcp -> 127.0.0.1:64989
+e904687449d9 el-client-1 engine-rpc: 8551/tcp -> 127.0.0.1:64993 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:64995
+ tcp-discovery: 30303/tcp -> 127.0.0.1:64994
+ udp-discovery: 30303/udp -> 127.0.0.1:58096
+ ws: 8546/tcp -> 127.0.0.1:64996
+ad6f401126fa el-client-2 engine-rpc: 8551/tcp -> 127.0.0.1:65003 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:65001
+ tcp-discovery: 30303/tcp -> 127.0.0.1:65000
+ udp-discovery: 30303/udp -> 127.0.0.1:57269
+ ws: 8546/tcp -> 127.0.0.1:65002
+12d04a9dbb69 prelaunch-data-generator-1680882122181135513 STOPPED
+5b45f9c0504b prelaunch-data-generator-1680882122192182847 STOPPED
+3d4aaa75e218 prelaunch-data-generator-1680882122201668972 STOPPED
+```
+
+恭喜! 您已成功將您的本地測試網設定為擁有 3 個節點,而不是 1 個。 要在您的 dApp 上執行與之前相同的工作流程(部署和測試),請執行與之前相同的操作,將您的 `hardhat.config.ts` 設定檔中 `localnet` 結構中的 `<$YOUR_PORT>` 替換為您的新的 3 節點本地測試網中任何 `el-client-` 服務輸出的 RPC URI 的連接埠。
+
+## 結論 {#conclusion}
+
+就是這樣! 總結一下本簡短指南,您:
+
+- 使用 Kurtosis 透過 Docker 建立了一個本地以太坊測試網
+- 將您的本地 dApp 開發環境連接到本地以太坊網路
+- 在本地以太坊網路上部署了一個 dApp 並對其進行了簡單的測試
+- 將底層以太坊網路設定為擁有 3 個節點
+
+我們很樂意聽取您對哪些方面進展順利、哪些方面可以改進的意見,或回答您的任何問題。 請隨時透過 [GitHub](https://github.com/kurtosis-tech/kurtosis/issues/new/choose) 或[發送電子郵件給我們](mailto:feedback@kurtosistech.com)與我們聯絡!
+
+### 其他範例和指南 {#other-examples-guides}
+
+我們鼓勵您查看我們的[快速入門](https://docs.kurtosis.com/quickstart)(您將在其中建構 Postgres 資料庫和 API)以及我們 [awesome-kurtosis 儲存庫](https://github.com/kurtosis-tech/awesome-kurtosis)中的其他範例,您將在那裡找到一些很棒的範例,包括以下套件:
+
+- [啟動相同的本地以太坊測試網](https://github.com/kurtosis-tech/eth2-package),但連接了額外的服務,例如交易發送器(以模擬交易)、分叉監視器,以及一個已連接的 Grafana 和 Prometheus 實例
+- 對相同的本地以太坊網路執行[子網路測試](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/ethereum-network-partition-test)
diff --git a/public/content/translations/zh-tw/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md b/public/content/translations/zh-tw/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
new file mode 100644
index 00000000000..83d3bae4714
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
@@ -0,0 +1,144 @@
+---
+title: "縮小合約大小來對抗合約大小限制"
+description: 你可以怎麼做來防止智能合約規模過大?
+author: Markus Waas
+lang: zh-tw
+tags: [ "穩固", "智能合約", "儲存" ]
+skill: intermediate
+published: 2020-06-26
+source: soliditydeveloper.com
+sourceUrl: https://soliditydeveloper.com/max-contract-size
+---
+
+## 為什麼要有個限制? {#why-is-there-a-limit}
+
+在 [2016 年 11 月 22 日](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/),Spurious Dragon 硬分叉引入了 [EIP-170](https://eips.ethereum.org/EIPS/eip-170),新增了 24.576 kb 的智能合約大小限制。 身為 Solidity 開發者,這代表當你在合約中加入越來越多功能時,在某個時間點你會達到上限,並在部署時看到以下錯誤:
+
+`Warning: Contract code size exceeds 24576 bytes (a limit introduced in Spurious Dragon). 此合約可能無法在主網上部署。 Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.`
+
+這個限制是為了防止阻斷服務 (DOS) 攻擊。 對合約的任何呼叫,在 gas 方面都相對便宜。 然而,合約呼叫對以太坊節點的影響,會根據被呼叫的合約程式碼大小(從磁碟讀取程式碼、預處理程式碼、將資料加入默克爾證明)而不成比例地增加。 每當發生攻擊者能以少量資源,造成他人大量工作負擔的情形,便可能產生 DOS 攻擊。
+
+起初這問題不大,因為一個天然的合約大小限制就是區塊 gas 上限。 顯然,合約必須部署在一個包含其所有位元組碼的交易中。 如果你只在一個區塊中包含那筆交易,你可以用完所有的 gas,但它不是無限的。 自 [倫敦升級](/ethereum-forks/#london) 以來,區塊 gas 上限可以根據網路需求在 1500 萬到 3000 萬單位之間變動。
+
+接下來,我們將按照潛在影響力的大小,來看看一些方法。 可以把它想像成減重。 一個人要達到目標體重(在我們的情況下是 24kb)的最佳策略是先專注於影響力大的方法。 在大多數情況下,單靠調整飲食就能達標,但有時候你需要做的更多一點。 然後你可能會增加一些運動(中等影響),或甚至營養補充品(小影響)。
+
+## 重大影響 {#big-impact}
+
+### 拆分你的合約 {#separate-your-contracts}
+
+這應該永遠是你的首選方法。 你如何將合約拆分成多個較小的合約? 這通常會迫使你為合約設計一個好的架構。 從程式碼可讀性的角度來看,小合約總是比較好。 要拆分合約,可以問自己:
+
+- 哪些函式屬於同一組? 每一組函式可能最適合放在各自的合約中。
+- 哪些函式不需要讀取合約狀態,或只需要讀取狀態的特定子集?
+- 你能將儲存空間和功能性拆分開來嗎?
+
+### 函式庫 {#libraries}
+
+一個將功能性程式碼從儲存空間移開的簡單方法是使用[函式庫](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries)。 不要將函式庫的函式宣告為 internal,因為它們會在編譯期間直接被[加到合約中](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking)。 但如果你使用 public 函式,那麼它們實際上會存在一個獨立的函式庫合約中。 可以考慮 [using for](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for) 讓函式庫的使用更方便。
+
+### 代理 {#proxies}
+
+一個更進階的策略是代理系統。 函式庫在後端使用 `DELEGATECALL`,它只是用呼叫合約的狀態來執行另一個合約的函式。 查看[這篇部落格文章](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2),以了解更多關於代理系統的資訊。 它們提供你更多功能,例如,它們能讓合約可以升級,但也增加了許多複雜性。 除非出於某些原因這是你唯一的選擇,否則我不會只為了縮小合約大小而加入這些。
+
+## 中等影響 {#medium-impact}
+
+### 移除函式 {#remove-functions}
+
+這點應該很明顯。 函式會增加不少合約大小。
+
+- **External**:我們時常為了方便而加入許多 view 函式。 在你碰到大小限制之前,這完全沒問題。 那時你可能就得認真考慮,只保留絕對必要的函式,並移除其他的。
+- **Internal**:你也可以移除 internal/private 函式,並只要該函式只被呼叫一次,就直接內聯 (inline) 其程式碼。
+
+### 避免額外的變數 {#avoid-additional-variables}
+
+```solidity
+function get(uint id) returns (address,address) {
+ MyStruct memory myStruct = myStructs[id];
+ return (myStruct.addr1, myStruct.addr2);
+}
+```
+
+```solidity
+function get(uint id) returns (address,address) {
+ return (myStructs[id].addr1, myStructs[id].addr2);
+}
+```
+
+像這樣一個簡單的改變,就差了 **0.28kb**。 你的合約中很可能有很多類似的情況,這些情況累積起來的量可能相當可觀。
+
+### 縮短錯誤訊息 {#shorten-error-message}
+
+長的 revert 訊息,特別是許多不同的 revert 訊息,會讓合約膨脹。 改用簡短的錯誤碼,並在你的合約中解碼它們。 一則長訊息可以變得更短:
+
+```solidity
+require(msg.sender == owner, "Only the owner of this contract can call this function");
+```
+
+```solidity
+require(msg.sender == owner, "OW1");
+```
+
+### 使用自訂錯誤而非錯誤訊息
+
+[Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/) 引入了自訂錯誤。 它們是減少合約大小的好方法,因為它們會被 ABI 編碼為選擇器(就像函式一樣)。
+
+```solidity
+error Unauthorized();
+
+if (msg.sender != owner) {
+ revert Unauthorized();
+}
+```
+
+### 在優化器中考慮使用較低的 run 值 {#consider-a-low-run-value-in-the-optimizer}
+
+你也可以更改優化器的設定。 預設值 200 代表它會試著優化位元組碼,就像函式被呼叫 200 次一樣。 如果你將它改為 1,基本上就是告訴優化器,針對每個函式只執行一次的情況進行優化。 一個為執行一次而優化的函式,代表它是為部署本身而優化。 請注意,**這會增加執行函式的 [gas 成本](/developers/docs/gas/)**,所以你可能不想這麼做。
+
+## 微小影響 {#small-impact}
+
+### 避免將 struct 傳遞給函式 {#avoid-passing-structs-to-functions}
+
+如果你正在使用 [ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2),不將 struct 傳遞給函式會有所幫助。 不要將參數作為 struct 傳遞,而是直接傳遞所需的參數。 在這個範例中,我們又節省了 **0.1kb**。
+
+```solidity
+function get(uint id) returns (address,address) {
+ return _get(myStruct);
+}
+
+function _get(MyStruct memory myStruct) private view returns(address,address) {
+ return (myStruct.addr1, myStruct.addr2);
+}
+```
+
+```solidity
+function get(uint id) returns(address,address) {
+ return _get(myStructs[id].addr1, myStructs[id].addr2);
+}
+
+function _get(address addr1, address addr2) private view returns(address,address) {
+ return (addr1, addr2);
+}
+```
+
+### 為函式和變數宣告正確的可見性 {#declare-correct-visibility-for-functions-and-variables}
+
+- 只會從外部呼叫的函式或變數? 將它們宣告為 `external` 而不是 `public`。
+- 只在合約內部呼叫的函式或變數? 將它們宣告為 `private` 或 `internal` 而不是 `public`。
+
+### 移除修飾符 {#remove-modifiers}
+
+修飾符,特別是當大量使用時,可能對合約大小產生重大影響。 考慮移除它們,改用函式。
+
+```solidity
+modifier checkStuff() {}
+
+function doSomething() checkStuff {}
+```
+
+```solidity
+function checkStuff() private {}
+
+function doSomething() { checkStuff(); }
+```
+
+這些技巧應該能幫助你大幅縮小合約大小。 再次強調,如果可能的話,請務必專注於拆分合約,以達到最大的影響。
diff --git a/public/content/translations/zh-tw/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/translations/zh-tw/developers/tutorials/eip-1271-smart-contract-signatures/index.md
new file mode 100644
index 00000000000..ad12c906f29
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/eip-1271-smart-contract-signatures/index.md
@@ -0,0 +1,123 @@
+---
+title: "EIP-1271:簽署與驗證智能合約簽章"
+description: 使用 EIP-1271 生成與驗證智能合約簽章的概覽。 我們也會逐步說明 Safe (前身為 Gnosis Safe) 中使用的 EIP-1271 實作,為智能合約開發者提供具體範例以供參考。
+author: Nathan H. Leung
+lang: zh-tw
+tags: [ "eip-1271", "智能合約", "驗證", "簽署" ]
+skill: intermediate
+published: 2023-01-12
+---
+
+[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) 標準允許智能合約驗證簽章。
+
+在本教學中,我們將概覽數位簽章、EIP-1271 的背景,以及 [Safe](https://safe.global/) (前身為 Gnosis Safe) 所使用的 EIP-1271 特定實作。 總而言之,本篇內容可作為您在自己的合約中實作 EIP-1271 的起點。
+
+## 什麼是簽章?
+
+在此背景下,簽章 (更準確地說,是「數位簽章」) 是一則訊息,加上某种證明,用以證明該訊息來自特定人士/傳送者/地址。
+
+例如,數位簽章可能長這樣:
+
+1. 訊息:「我想用我的以太坊錢包登入這個網站。」
+2. 簽署者:我的地址是 `0x000…`
+3. 證明:這是一些證明,證明我 (`0x000…`) 確實建立了這整則訊息 (這通常是某种加密的東西)。
+
+請務必注意,數位簽章同時包含「訊息」與「簽章」。
+
+為什麼? 舉例來說,如果您給我一份合約簽署,然後我把簽章頁撕下來,只把我的簽章還給您,而沒有合約的其他部分,那麼這份合約將無效。
+
+同樣地,如果沒有相關的訊息,數位簽章就沒有任何意義!
+
+## EIP-1271 為何存在?
+
+為了建立在以太坊區塊鏈上使用的數位簽章,您通常需要一個其他人不知道的秘密私密金鑰。 這就是為什麼您的簽章專屬於您 (沒有其他人能在不知道秘密金鑰的情況下建立相同的簽章)。
+
+您的以太坊帳戶 (即您的外部擁有帳戶/EOA) 有一個與其關聯的私密金鑰,當網站或去中心化應用程式要求您簽章 (例如,「用以太坊登入」) 時,通常會使用此私密金鑰。
+
+應用程式可以使用 ethers.js 等第三方庫來 [驗證您建立的簽章](https://www.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum),且 [無需知道您的私密金鑰](https://en.wikipedia.org/wiki/Public-key_cryptography),並確信該簽章是由_您_所建立的。
+
+> 事實上,由於 EOA 數位簽章使用公開金鑰密碼學,因此可以在**鏈外**生成與驗證! 這就是無 Gas 的 DAO 投票的運作方式 — 不在鏈上提交投票,而是使用加密庫在鏈外建立和驗證數位簽章。
+
+雖然 EOA 帳戶有私密金鑰,但智能合約帳戶沒有任何形式的私密或秘密金鑰 (因此「用以太坊登入」等功能無法原生支援智能合約帳戶)。
+
+EIP-1271 旨在解決的問題是:如果智能合約沒有可以納入簽章的「秘密」,我們如何判斷智能合約簽章是否有效?
+
+## EIP-1271 如何運作?
+
+智能合約沒有可用於簽署訊息的私密金鑰。 那麼,我們如何判斷簽章是否真實?
+
+嗯,一個想法是我們可以直接_詢問_智能合約簽章是否真實!
+
+EIP-1271 的作用是將「詢問」智能合約特定簽章是否有效的這個想法標準化。
+
+實作 EIP-1271 的合約必須有一個名為 `isValidSignature` 的函式,該函式接收一個訊息和一個簽章。 然後,合約可以執行一些驗證邏輯 (規範在此處並未強制要求任何具體內容),然後傳回一個值,指出簽章是否有效。
+
+如果 `isValidSignature` 傳回有效結果,這基本上就等於合約在說:「是的,我批准這個簽章 + 訊息!」
+
+### 接口
+
+以下是 EIP-1271 規範中的確切介面 (我們稍後會討論 `_hash` 參數,但現在,您可以將其視為正在驗證的訊息):
+
+```jsx
+pragma solidity ^0.5.0;
+
+contract ERC1271 {
+
+ // bytes4(keccak256("isValidSignature(bytes32,bytes)")
+ bytes4 constant internal MAGICVALUE = 0x1626ba7e;
+
+ /**
+ * @dev 應傳回所提供的簽章對於所提供的哈希是否有效
+ * @param _hash 待簽署資料的哈希
+ * @param _signature 與 _hash 相關的簽章位元組陣列
+ *
+ * 函式通過時必須傳回 bytes4 魔術值 0x1626ba7e。
+ * 不得修改狀態 (對於 solc < 0.5 使用 STATICCALL,對於 solc > 0.5 使用 view 修飾符)
+ * 必須允許外部呼叫
+ */
+ function isValidSignature(
+ bytes32 _hash,
+ bytes memory _signature)
+ public
+ view
+ returns (bytes4 magicValue);
+}
+```
+
+## EIP-1271 實作範例:Safe
+
+合約可以透過多種方式實作 `isValidSignature` — 該規範對於確切的實作方式並未多加說明。
+
+一個實作 EIP-1271 的知名合約是 Safe (前身為 Gnosis Safe)。
+
+在 Safe 的程式碼中,`isValidSignature` 的 [實作方式](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol) 讓簽章可以透過 [兩種方式](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support) 建立與驗證:
+
+1. 鏈上訊息
+ 1. 建立:Safe 持有者建立一筆新的 Safe 交易來「簽署」一則訊息,並將該訊息作為資料傳入交易中。 一旦有足夠的持有者簽署交易,達到多重簽章門檻,交易就會被廣播並執行。 在交易中,有一個名為 (`signMessage(bytes calldata _data)`) 的 Safe 函式,它會將訊息新增到「已批准」的訊息清單中。
+ 2. 驗證:在 Safe 合約上呼叫 `isValidSignature`,並將要驗證的訊息作為訊息參數傳入,同時為簽章參數傳入 [一個空值](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (即 `0x`)。 Safe 將會看到簽章參數為空,於是便不會以加密方式驗證簽章,而是會直接檢查該訊息是否在「已批准」的訊息清單上。
+2. 鏈外訊息:
+ 1. 建立:Safe 持有者在鏈外建立一則訊息,然後讓其他 Safe 持有者各自簽署該訊息,直到簽章數量足以超過多重簽章批准門檻為止。
+ 2. 驗證:呼叫 `isValidSignature`。 在訊息參數中,傳入要驗證的訊息。 在簽章參數中,將每個 Safe 持有者的個人簽章一個接一個地串接起來傳入。 Safe 將會檢查是否有足夠的簽章來滿足門檻,**並且**每個簽章都有效。 如果是,它將傳回一個值,表示簽章驗證成功。
+
+## `_hash` 參數到底是什麼? 為什麼不傳遞整個訊息?
+
+您可能已經注意到,[EIP-1271 介面](https://eips.ethereum.org/EIPS/eip-1271) 中的 `isValidSignature` 函式並非直接接收訊息本身,而是接收一個 `_hash` 參數。 這表示我們不是將完整的任意長度訊息傳遞給 `isValidSignature`,而是傳遞該訊息的 32 位元組哈希 (通常是 keccak256)。
+
+calldata 的每個位元組 — 也就是傳遞給智能合約函式的函式參數資料 — [會花費 16 gas (如果為零位元組則為 4 gas)](https://eips.ethereum.org/EIPS/eip-2028),因此如果訊息很長,這樣可以節省大量 gas。
+
+### 先前的 EIP-1271 規範
+
+現存的一些 EIP-1271 規範中,`isValidSignature` 函式的第一個參數類型為 `bytes` (任意長度,而非固定長度的 `bytes32`),且參數名稱為 `message`。 這是 EIP-1271 標準的 [舊版](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206)。
+
+## 應如何在自己的合約中實作 EIP-1271?
+
+規範在此處非常有彈性。 Safe 的實作有一些不錯的想法:
+
+- 您可以將來自合約「持有者」的 EOA 簽章視為有效。
+- 您可以儲存一份已批准的訊息清單,並只將這些訊息視為有效。
+
+最終,這取決於您這位合約開發者!
+
+## 結論
+
+[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) 是一個多功能的標準,允許智能合約驗證簽章。 它為智能合約開啟了大門,讓它們的行為更像 EOA — 例如,為「用以太坊登入」提供了一種與智能合約搭配運作的方式 — 並且可以透過多種方式實作 (Safe 有一個值得考慮的、非同小可且有趣的實作)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md
new file mode 100644
index 00000000000..08cb85e7fca
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md
@@ -0,0 +1,645 @@
+---
+title: "Vyper ERC-721 合約逐步解說"
+description: Ryuya Nakamura 的 ERC-721 合約及其運作方式
+author: 作者:Ori Pomerantz
+lang: zh-tw
+tags: [ "vyper", "erc-721", "python" ]
+skill: beginner
+published: 2021-04-01
+---
+
+## 介紹 {#introduction}
+
+[ERC-721](/developers/docs/standards/tokens/erc-721/) 標準是用於持有非同質化代幣 (NFT) 所有權的標準。
+[ERC-20](/developers/docs/standards/tokens/erc-20/) 代幣的行為類似商品,因為個別代幣之間沒有任何區別。
+與之對比,ERC-721 代幣是為相似但不相同的資產所設計,例如不同的貓
+卡通或不同房地產的所有權狀。
+
+在本文中,我們將分析 [Ryuya Nakamura 的 ERC-721 合約](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy)。
+此合約以 [Vyper](https://vyper.readthedocs.io/en/latest/index.html) 編寫,這是一種近似 Python 的合約語言,其設計目的是讓編寫不安全的程式碼比在 Solidity 中更困難。
+
+## 合約 {#contract}
+
+```python
+# @dev ERC-721 非同質化代幣標準的實作。
+# @author Ryuya Nakamura (@nrryuya)
+# 修改自:https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy
+```
+
+Vyper 中的註解與 Python 相同,以井字號 (`#`) 開頭,並一直延續到該行結尾。 包含 `@<關鍵字>` 的註解會由 [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) 用來產生人類可讀的文件。
+
+```python
+from vyper.interfaces import ERC721
+
+implements: ERC721
+```
+
+ERC-721 介面內建於 Vyper 語言中。
+[你可以在這裡看到程式碼定義](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py)。
+介面定義是以 Python 而非 Vyper 編寫的,因為介面不僅在區塊鏈內部使用,也用於從可能以 Python 編寫的外部用戶端向區塊鏈傳送交易。
+
+第一行匯入介面,第二行則指明我們在此處實作該介面。
+
+### ERC721Receiver 介面 {#receiver-interface}
+
+```python
+# safeTransferFrom() 呼叫的合約介面
+interface ERC721Receiver:
+ def onERC721Received(
+```
+
+ERC-721 支援兩種轉移類型:
+
+- `transferFrom`,它讓傳送方可以指定任何目標地址,並將轉移的責任歸於傳送方。 這意味著你可以轉移到無效地址,在這種情況下,NFT 將會永久遺失。
+- `safeTransferFrom`,它會檢查目標地址是否為合約。 若是,ERC-721 合約會詢問接收合約是否願意接收該 NFT。
+
+為了回應 `safeTransferFrom` 的請求,接收合約必須實作 `ERC721Receiver`。
+
+```python
+ _operator: address,
+ _from: address,
+```
+
+`_from` 地址是代幣的目前擁有者。 `_operator` 地址是請求轉移的地址 (由於有授權額度的關係,這兩個地址可能不相同)。
+
+```python
+ _tokenId: uint256,
+```
+
+ERC-721 代幣 ID 是 256 位元。 一般而言,它們是透過對代幣所代表之物的描述進行哈希運算而建立的。
+
+```python
+ _data: Bytes[1024]
+```
+
+此請求最多可包含 1024 位元組的使用者資料。
+
+```python
+ ) -> bytes32: view
+```
+
+為防止合約意外接受轉移的情況,傳回值不是布林值,而是帶有特定值的 256 位元數值。
+
+此函式為 `view` 函式,代表它可以讀取區塊鏈的狀態,但不能修改它。
+
+### Events {#events}
+
+[事件](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e)
+會被發出以通知區塊鏈外部的使用者和伺服器發生的事件。 請注意,事件的內容對於區塊鏈上的合約是不可用的。
+
+```python
+# @dev 當任何 NFT 的所有權因任何機制發生變更時發出。當 NFT 被
+# 建立 (`from` == 0) 和銷毀 (`to` == 0) 時會發出此事件。例外:在合約建立期間,可以
+# 建立並指派任意數量的 NFT 而不發出 Transfer 事件。在任何
+# 轉移時,該 NFT 的核准地址 (若有) 會被重設為無。
+# @param _from NFT 的傳送方 (若地址為零地址,則表示代幣建立)。
+# @param _to NFT 的接收方 (若地址為零地址,則表示代幣銷毀)。
+# @param _tokenId 已轉移的 NFT。
+event Transfer:
+ sender: indexed(address)
+ receiver: indexed(address)
+ tokenId: indexed(uint256)
+```
+
+這與 ERC-20 的 Transfer 事件相似,差別在於我們回報的是 `tokenId` 而非數量。
+沒有人擁有零地址,因此按照慣例,我們用它來回報代幣的建立和銷毀。
+
+```python
+# @dev 當一個 NFT 的核准地址被變更或再次確認時發出。零
+# 地址表示沒有核准地址。當 Transfer 事件發出時,這也
+# 表示該 NFT 的核准地址 (若有) 被重設為無。
+# @param _owner NFT 的擁有者。
+# @param _approved 我們正在核准的地址。
+# @param _tokenId 我們正在核准的 NFT。
+event Approval:
+ owner: indexed(address)
+ approved: indexed(address)
+ tokenId: indexed(uint256)
+```
+
+ERC-721 的核准類似於 ERC-20 的授權額度。 一個特定的地址被允許轉移一個特定的代幣。 這提供了一種機制,讓合約在接受代幣時能夠做出回應。 合約無法監聽事件,所以如果你只是將代幣轉移給它們,它們不會「知道」這件事。 這樣一來,擁有者首先提交一項核准,然後向合約傳送請求:"我已核准你轉移代幣
+X,請執行..."。
+
+這是一項設計上的選擇,目的是讓 ERC-721 標準與 ERC-20 標準相似。 由於 ERC-721 代幣並非同質化代幣,合約也可以透過查看代幣的所有權來識別它是否取得了特定的代幣。
+
+```python
+# @dev 當擁有者的操作員被啟用或停用時發出。操作員可以管理
+# 該擁有者的所有 NFT。
+# @param _owner NFT 的擁有者。
+# @param _operator 我們要為其設定操作員權限的地址。
+# @param _approved 操作員權限的狀態 (true 表示授予操作員權限,false 表示
+# 撤銷)。
+event ApprovalForAll:
+ owner: indexed(address)
+ operator: indexed(address)
+ approved: bool
+```
+
+有時候,有一個可以管理某帳戶所有特定類型代幣(由特定合約管理的代幣)的_操作員_是很有用的,這類似於授權書。 例如,我可能會想將此權力賦予一個合約,讓它檢查我是否六個月未與其聯繫,若是,則將我的資產分配給我的繼承人 (前提是其中一位繼承人提出請求,因為合約若無交易呼叫則無法執行任何動作)。 在 ERC-20 中,我們可以只給予繼承合約一個高額的授權額度,但這在 ERC-721 中行不通,因為其代幣並非同質化的。 這就是等效的做法。
+
+`approved` 值告訴我們該事件是進行核准,還是撤銷核准。
+
+### 狀態變數 {#state-vars}
+
+這些變數包含代幣的目前狀態:哪些是可用的以及誰擁有它們。 這些變數大部分是 `HashMap` 物件,是[存在於兩種類型之間的單向映射](https://vyper.readthedocs.io/en/latest/types.html#mappings)。
+
+```python
+# @dev 從 NFT ID 到其擁有者地址的映射。
+idToOwner: HashMap[uint256, address]
+
+# @dev 從 NFT ID 到核准地址的映射。
+idToApprovals: HashMap[uint256, address]
+```
+
+在以太坊中,使用者和合約的身分由 160 位元的地址表示。 這兩個變數從代幣 ID 映射到其擁有者以及被核准轉移它們的人 (每個代幣最多一個)。 在以太坊中,未初始化的資料始終為零,所以如果沒有擁有者或核准的轉移者,該代幣的值就是零。
+
+```python
+# @dev 從擁有者地址到其代幣數量的映射。
+ownerToNFTokenCount: HashMap[address, uint256]
+```
+
+此變數持有每個擁有者的代幣數量。 由於沒有從擁有者到代幣的映射,所以識別特定擁有者所擁有的代幣的唯一方法是回顧區塊鏈的事件歷史,並查看相應的 `Transfer` 事件。 我們可以使用這個變數來知道我們何時擁有了所有的 NFT,而不需要再回溯更早的時間。
+
+請注意,此演算法僅適用於使用者介面和外部伺服器。 在區塊鏈上執行的程式碼本身無法讀取過去的事件。
+
+```python
+# @dev 從擁有者地址到操作員地址映射的映射。
+ownerToOperators: HashMap[address, HashMap[address, bool]]
+```
+
+一個帳戶可能有多個操作員。 一個簡單的 `HashMap` 並不足以追蹤它們,因為每個鍵只會對應到一個值。 取而代之,你可以使用 `HashMap[address, bool]` 作為值。 預設情況下,每個地址的值為 `False`,這意味著它不是操作員。 你可以視需要將值設定為 `True`。
+
+```python
+# @dev 鑄幣者的地址,可以鑄造代幣
+minter: address
+```
+
+新代幣必須以某種方式被建立出來。 在此合約中,只有一個實體被允許這麼做,即 `minter` (鑄幣者)。 例如,對於一個遊戲來說,這可能就足夠了。 對於其他目的,可能需要建立更複雜的商業邏輯。
+
+```python
+# @dev 從介面 ID 到布林值的映射,代表是否支援該介面
+supportedInterfaces: HashMap[bytes32, bool]
+
+# @dev ERC165 的 ERC165 介面 ID
+ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a7
+
+# @dev ERC721 的 ERC165 介面 ID
+ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cd
+```
+
+[ERC-165](https://eips.ethereum.org/EIPS/eip-165) 規定了一種機制,讓合約能夠揭露應用程式可以如何與其通訊,以及它遵循哪些 ERC 標準。 在此例中,合約遵循 ERC-165 和 ERC-721。
+
+### 函數 {#functions}
+
+這些是實際實作 ERC-721 的函式。
+
+#### 建構函式 {#constructor}
+
+```python
+@external
+def __init__():
+```
+
+在 Vyper 中,與 Python 相同,建構函式稱為 `__init__`。
+
+```python
+ """
+ @dev 合約建構函式。
+ """
+```
+
+在 Python 和 Vyper 中,你也可以透過指定一個多行字串 (以 `"""` 開頭和結尾) 且不以任何方式使用它來建立註解。 這些註解也可以包含 [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html)。
+
+```python
+ self.supportedInterfaces[ERC165_INTERFACE_ID] = True
+ self.supportedInterfaces[ERC721_INTERFACE_ID] = True
+ self.minter = msg.sender
+```
+
+若要存取狀態變數,請使用 \`self.<變數名稱>\`\` (同樣,這和 Python 一樣)。
+
+#### 檢視函式 {#views}
+
+這些函式不會修改區塊鏈的狀態,因此如果從外部呼叫它們,可以免費執行。 如果檢視函式是由合約呼叫的,它們仍然必須在每個節點上執行,因此會產生 gas 費用。
+
+```python
+@view
+@external
+```
+
+在函式定義之前,以 at 符號 (`@`) 開頭的這些關鍵字稱為_裝飾器_。 它們指定了可以呼叫函式的條件。
+
+- `@view` 指定此函式為檢視函式。
+- `@external` 指定此特定函式可由交易和其他合約呼叫。
+
+```python
+def supportsInterface(_interfaceID: bytes32) -> bool:
+```
+
+與 Python 不同,Vyper 是一種[靜態型別語言](https://wikipedia.org/wiki/Type_system#Static_type_checking)。
+若不指定[資料類型](https://vyper.readthedocs.io/en/latest/types.html),則無法宣告變數或函式參數。 在此例中,輸入參數為 `bytes32`,一個 256 位元的值 (256 位元是 [以太坊虛擬機](/developers/docs/evm/) 的原生字組大小)。 輸出是一個布林值。 按照慣例,函式參數的名稱以下底線 (`_`) 開頭。
+
+```python
+ """
+ @dev 介面識別在 ERC-165 中指定。
+ @param _interfaceID 介面的 ID
+ """
+ return self.supportedInterfaces[_interfaceID]
+```
+
+從 `self.supportedInterfaces` HashMap 傳回值,該值在建構函式 (`__init__`) 中設定。
+
+```python
+### 檢視函式 ###
+```
+
+這些是讓使用者和其他合約能取得代幣相關資訊的檢視函式。
+
+```python
+@view
+@external
+def balanceOf(_owner: address) -> uint256:
+ """
+ @dev 傳回 `_owner` 擁有的 NFT 數量。
+ 如果 `_owner` 是零地址,則會擲出錯誤。指派給零地址的 NFT 被視為無效。
+ @param _owner 要查詢餘額的地址。
+ """
+ assert _owner != ZERO_ADDRESS
+```
+
+此行[斷言](https://vyper.readthedocs.io/en/latest/statements.html#assert)`_owner` 不為零。 如果為零,則會出現錯誤並且操作將被還原。
+
+```python
+ return self.ownerToNFTokenCount[_owner]
+
+@view
+@external
+def ownerOf(_tokenId: uint256) -> address:
+ """
+ @dev 傳回 NFT 擁有者的地址。
+ 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤。
+ @param _tokenId NFT 的識別碼。
+ """
+ owner: address = self.idToOwner[_tokenId]
+ # 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤
+ assert owner != ZERO_ADDRESS
+ return owner
+```
+
+在以太坊虛擬機 (evm) 中,任何沒有儲存值的儲存空間都為零。
+如果 `_tokenId` 沒有代幣,則 `self.idToOwner[_tokenId]` 的值為零。 在這種情況下,函式會還原。
+
+```python
+@view
+@external
+def getApproved(_tokenId: uint256) -> address:
+ """
+ @dev 取得單一 NFT 的核准地址。
+ 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤。
+ @param _tokenId 要查詢核准的 NFT ID。
+ """
+ # 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤
+ assert self.idToOwner[_tokenId] != ZERO_ADDRESS
+ return self.idToApprovals[_tokenId]
+```
+
+注意,`getApproved` _可以_傳回零。 如果代幣有效,它會傳回 `self.idToApprovals[_tokenId]`。
+如果沒有核准者,該值為零。
+
+```python
+@view
+@external
+def isApprovedForAll(_owner: address, _operator: address) -> bool:
+ """
+ @dev 檢查 `_operator` 是否為 `_owner` 的核准操作員。
+ @param _owner 擁有 NFT 的地址。
+ @param _operator 代表擁有者行事的地址。
+ """
+ return (self.ownerToOperators[_owner])[_operator]
+```
+
+此函式檢查 `_operator` 是否被允許管理此合約中 `_owner` 的所有代幣。
+因為可以有多個操作員,這是一個兩層的 HashMap。
+
+#### 轉移輔助函式 {#transfer-helpers}
+
+這些函式實作了轉移或管理代幣的部分操作。
+
+```python
+
+### 轉移函式輔助工具 ###
+
+@view
+@internal
+```
+
+這個裝飾器 `@internal` 表示該函式只能在同一個合約內的其他函式中存取。 按照慣例,這些函式名稱也以下底線 (`_`) 開頭。
+
+```python
+def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool:
+ """
+ @dev 傳回給定的花費者是否可以轉移給定的代幣 ID
+ @param spender 要查詢的花費者地址
+ @param tokenId 要轉移的代幣的 uint256 ID
+ @return bool 表示 msg.sender 是否被核准用於給定的代幣 ID、
+ 是否為擁有者的操作員,或是否為代幣的擁有者
+ """
+ owner: address = self.idToOwner[_tokenId]
+ spenderIsOwner: bool = owner == _spender
+ spenderIsApproved: bool = _spender == self.idToApprovals[_tokenId]
+ spenderIsApprovedForAll: bool = (self.ownerToOperators[owner])[_spender]
+ return (spenderIsOwner or spenderIsApproved) or spenderIsApprovedForAll
+```
+
+有三種方式可以讓一個地址被允許轉移代幣:
+
+1. 該地址是代幣的擁有者
+2. 該地址被核准花費該代幣
+3. 該地址是代幣擁有者的操作員
+
+上面的函式可以是檢視函式,因為它不會改變狀態。 為了降低操作成本,任何_可以_成為檢視函式的函式都_應該_是檢視函式。
+
+```python
+@internal
+def _addTokenTo(_to: address, _tokenId: uint256):
+ """
+ @dev 將 NFT 新增到給定地址
+ 如果 `_tokenId` 已被他人擁有,則會擲出錯誤。
+ """
+ # 如果 `_tokenId` 已被他人擁有,則會擲出錯誤
+ assert self.idToOwner[_tokenId] == ZERO_ADDRESS
+ # 變更擁有者
+ self.idToOwner[_tokenId] = _to
+ # 變更計數追蹤
+ self.ownerToNFTokenCount[_to] += 1
+
+
+@internal
+def _removeTokenFrom(_from: address, _tokenId: uint256):
+ """
+ @dev 從給定地址移除 NFT
+ 如果 `_from` 不是目前的擁有者,則會擲出錯誤。
+ """
+ # 如果 `_from` 不是目前的擁有者,則會擲出錯誤
+ assert self.idToOwner[_tokenId] == _from
+ # 變更擁有者
+ self.idToOwner[_tokenId] = ZERO_ADDRESS
+ # 變更計數追蹤
+ self.ownerToNFTokenCount[_from] -= 1
+```
+
+當轉移出現問題時,我們會還原該呼叫。
+
+```python
+@internal
+def _clearApproval(_owner: address, _tokenId: uint256):
+ """
+ @dev 清除給定地址的核准
+ 如果 `_owner` 不是目前的擁有者,則會擲出錯誤。
+ """
+ # 如果 `_owner` 不是目前的擁有者,則會擲出錯誤
+ assert self.idToOwner[_tokenId] == _owner
+ if self.idToApprovals[_tokenId] != ZERO_ADDRESS:
+ # 重設核准
+ self.idToApprovals[_tokenId] = ZERO_ADDRESS
+```
+
+只有在必要時才變更值。 狀態變數存在儲存空間中。 寫入儲存空間是 EVM (以太坊虛擬機) 執行成本最昂貴的操作之一 (以 [gas](/developers/docs/gas/) 費用計算)。 因此,最好盡量減少寫入,即使寫入現有值也具有高成本。
+
+```python
+@internal
+def _transferFrom(_from: address, _to: address, _tokenId: uint256, _sender: address):
+ """
+ @dev 執行 NFT 的轉移。
+ 除非 `msg.sender` 是目前的擁有者、授權的操作員或此 NFT 的核准
+ 地址,否則會擲出錯誤。(注意:私有函式中不允許 `msg.sender`,所以傳入 `_sender`。)
+ 如果 `_to` 是零地址,則會擲出錯誤。
+ 如果 `_from` 不是目前的擁有者,則會擲出錯誤。
+ 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤。
+ """
+```
+
+我們有這個內部函式,因為有兩種轉移代幣的方式 (常規和安全),但我們希望只在程式碼中的一個位置執行它,以便於審核。
+
+```python
+ # 檢查需求
+ assert self._isApprovedOrOwner(_sender, _tokenId)
+ # 如果 `_to` 是零地址,則會擲出錯誤
+ assert _to != ZERO_ADDRESS
+ # 清除核准。如果 `_from` 不是目前的擁有者,則會擲出錯誤
+ self._clearApproval(_from, _tokenId)
+ # 移除 NFT。如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤
+ self._removeTokenFrom(_from, _tokenId)
+ # 新增 NFT
+ self._addTokenTo(_to, _tokenId)
+ # 記錄轉移
+ log Transfer(_from, _to, _tokenId)
+```
+
+若要在 Vyper 中發出事件,請使用 `log` 陳述式 ([在此處查看更多詳細資訊](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging))。
+
+#### 轉移函式 {#transfer-funs}
+
+```python
+
+### 轉移函式 ###
+
+@external
+def transferFrom(_from: address, _to: address, _tokenId: uint256):
+ """
+ @dev 除非 `msg.sender` 是目前的擁有者、授權的操作員或此 NFT 的核准
+ 地址,否則會擲出錯誤。
+ 如果 `_from` 不是目前的擁有者,則會擲出錯誤。
+ 如果 `_to` 是零地址,則會擲出錯誤。
+ 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤。
+ @notice 呼叫者有責任確認 `_to` 能夠接收 NFT,否則
+ 它們可能會永久遺失。
+ @param _from NFT 的目前擁有者。
+ @param _to 新的擁有者。
+ @param _tokenId 要轉移的 NFT。
+ """
+ self._transferFrom(_from, _to, _tokenId, msg.sender)
+```
+
+此函式可讓你轉移到任意地址。 除非該地址是使用者,或是知道如何轉移代幣的合約,否則你轉移的任何代幣都會卡在該地址中而無法使用。
+
+```python
+@external
+def safeTransferFrom(
+ _from: address,
+ _to: address,
+ _tokenId: uint256,
+ _data: Bytes[1024]=b""
+ ):
+ """
+ @dev 將 NFT 的所有權從一個地址轉移到另一個地址。
+ 除非 `msg.sender` 是目前的擁有者、授權的操作員或此
+ NFT 的核准地址,否則會擲出錯誤。
+ 如果 `_from` 不是目前的擁有者,則會擲出錯誤。
+ 如果 `_to` 是零地址,則會擲出錯誤。
+ 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤。
+ 如果 `_to` 是智慧合約,它會在 `_to` 上呼叫 `onERC721Received`,如果
+ 傳回值不是 `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`,則會擲出錯誤。
+ 注意:bytes4 由帶有填充的 bytes32 表示
+ @param _from NFT 的目前擁有者。
+ @param _to 新的擁有者。
+ @param _tokenId 要轉移的 NFT。
+ @param _data 額外資料,無指定格式,在對 `_to` 的呼叫中傳送。
+ """
+ self._transferFrom(_from, _to, _tokenId, msg.sender)
+```
+
+先執行轉移是沒問題的,因為如果出現問題,我們無論如何都會還原,所以在呼叫中完成的所有事情都將被取消。
+
+```python
+ if _to.is_contract: # 檢查 `_to` 是否為合約地址
+```
+
+首先檢查該地址是否為合約 (如果它有程式碼)。 如果不是,則假設它是一個使用者地址,使用者將能夠使用或轉移該代幣。 但不要讓它讓你產生虛假的安全感。 即使使用 `safeTransferFrom`,如果你將代幣轉移到一個沒人知道私鑰的地址,你仍然可能會遺失代幣。
+
+```python
+ returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data)
+```
+
+呼叫目標合約,看它是否能接收 ERC-721 代幣。
+
+```python
+ # 如果轉移目標是不實作 'onERC721Received' 的合約,則會擲出錯誤
+ assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32)
+```
+
+如果目標是一個合約,但不接受 ERC-721 代幣 (或決定不接受此特定轉移),則還原。
+
+```python
+@external
+def approve(_approved: address, _tokenId: uint256):
+ """
+ @dev 設定或再次確認 NFT 的核准地址。零地址表示沒有核准地址。
+ 除非 `msg.sender` 是目前的 NFT 擁有者,或目前擁有者的授權操作員,否則會擲出錯誤。
+ 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤。(注意:這未在 EIP 中撰寫)
+ 如果 `_approved` 是目前的擁有者,則會擲出錯誤。(注意:這未在 EIP 中撰寫)
+ @param _approved 要為給定 NFT ID 核准的地址。
+ @param _tokenId 要核准的代幣 ID。
+ """
+ owner: address = self.idToOwner[_tokenId]
+ # 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤
+ assert owner != ZERO_ADDRESS
+ # 如果 `_approved` 是目前的擁有者,則會擲出錯誤
+ assert _approved != owner
+```
+
+按照慣例,如果你不想有核准者,你應該指定零地址,而不是你自己。
+
+```python
+ # 檢查需求
+ senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender
+ senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender]
+ assert (senderIsOwner or senderIsApprovedForAll)
+```
+
+要設定核准,你可以是擁有者,也可以是擁有者授權的操作員。
+
+```python
+ # 設定核准
+ self.idToApprovals[_tokenId] = _approved
+ log Approval(owner, _approved, _tokenId)
+
+
+@external
+def setApprovalForAll(_operator: address, _approved: bool):
+ """
+ @dev 啟用或停用第三方 (「操作員」) 管理 `msg.sender`
+ 所有資產的核准。它也會發出 ApprovalForAll 事件。
+ 如果 `_operator` 是 `msg.sender`,則會擲出錯誤。(注意:這未在 EIP 中撰寫)
+ @notice 即使傳送方當時沒有任何代幣,此函式也有效。
+ @param _operator 要新增到授權操作員集合的地址。
+ @param _approved 如果操作員被核准則為 True,若要撤銷核准則為 false。
+ """
+ # 如果 `_operator` 是 `msg.sender`,則會擲出錯誤
+ assert _operator != msg.sender
+ self.ownerToOperators[msg.sender][_operator] = _approved
+ log ApprovalForAll(msg.sender, _operator, _approved)
+```
+
+#### 鑄造新代幣和銷毀現有代幣 {#mint-burn}
+
+建立合約的帳戶是 `minter` (鑄幣者),即有權鑄造新 NFT 的超級使用者。 然而,即使是鑄幣者也不被允許銷毀現有的代幣。 只有擁有者或由擁有者授權的實體才能這麼做。
+
+```python
+### 鑄幣與銷毀函式 ###
+
+@external
+def mint(_to: address, _tokenId: uint256) -> bool:
+```
+
+此函式始終傳回 `True`,因為如果操作失敗,它將會被還原。
+
+```python
+ """
+ @dev 鑄造代幣的函式
+ 如果 `msg.sender` 不是鑄幣者,則會擲出錯誤。
+ 如果 `_to` 是零地址,則會擲出錯誤。
+ 如果 `_tokenId` 已被他人擁有,則會擲出錯誤。
+ @param _to 將接收鑄造代幣的地址。
+ @param _tokenId 要鑄造的代幣 id。
+ @return 一個布林值,表示操作是否成功。
+ """
+ # 如果 `msg.sender` 不是鑄幣者,則會擲出錯誤
+ assert msg.sender == self.minter
+```
+
+只有鑄幣者 (建立 ERC-721 合約的帳戶) 才能鑄造新代幣。 如果我們未來想變更鑄幣者的身分,這可能會成為一個問題。 在一個生產合約中,你可能需要一個函式,允許鑄幣者將鑄幣權限轉移給其他人。
+
+```python
+ # 如果 `_to` 是零地址,則會擲出錯誤
+ assert _to != ZERO_ADDRESS
+ # 新增 NFT。如果 `_tokenId` 已被他人擁有,則會擲出錯誤
+ self._addTokenTo(_to, _tokenId)
+ log Transfer(ZERO_ADDRESS, _to, _tokenId)
+ return True
+```
+
+按照慣例,鑄造新代幣被視為從零地址轉出。
+
+```python
+
+@external
+def burn(_tokenId: uint256):
+ """
+ @dev 銷毀特定的 ERC721 代幣。
+ 除非 `msg.sender` 是目前的擁有者、授權的操作員或此 NFT 的核准
+ 地址,否則會擲出錯誤。
+ 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤。
+ @param _tokenId 要銷毀的 ERC721 代幣的 uint256 id。
+ """
+ # 檢查需求
+ assert self._isApprovedOrOwner(msg.sender, _tokenId)
+ owner: address = self.idToOwner[_tokenId]
+ # 如果 `_tokenId` 不是有效的 NFT,則會擲出錯誤
+ assert owner != ZERO_ADDRESS
+ self._clearApproval(owner, _tokenId)
+ self._removeTokenFrom(owner, _tokenId)
+ log Transfer(owner, ZERO_ADDRESS, _tokenId)
+```
+
+任何被允許轉移代幣的人都可以銷毀它。 雖然銷毀看起來等同於轉移到零地址,但零地址實際上並不會收到代幣。 這讓我們可以釋放用於該代幣的所有儲存空間,這可以降低交易的 gas 成本。
+
+## 使用此合約 {#using-contract}
+
+與 Solidity 不同,Vyper 沒有繼承機制。 這是一項刻意的設計選擇,旨在讓程式碼更清晰,從而更容易確保其安全性。 因此,若要建立自己的 Vyper ERC-721 合約,你可以拿取[此合約](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy)並修改它,以實作你想要的商業邏輯。
+
+## 結論 {#conclusion}
+
+為了複習,以下是此合約中一些最重要的概念:
+
+- 要透過安全轉移接收 ERC-721 代幣,合約必須實作 `ERC721Receiver` 介面。
+- 即使你使用安全轉移,如果你將代幣傳送到私鑰未知的地址,代幣仍然可能會卡住。
+- 當操作出現問題時,最好是 `revert` (還原) 該呼叫,而不是只傳回一個失敗值。
+- ERC-721 代幣在其有擁有者時存在。
+- 有三種方式可以獲得轉移 NFT 的授權。 你可以是擁有者、被核准用於特定代幣,或是擁有者所有代幣的操作員。
+- 過去的事件只有在區塊鏈外部才可見。 在區塊鏈內部執行的程式碼無法檢視它們。
+
+現在去實作安全的 Vyper 合約吧。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
+
diff --git a/public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md
new file mode 100644
index 00000000000..171f08d7a1f
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md
@@ -0,0 +1,803 @@
+---
+title: "ERC-20 合約逐步解說"
+description: OpenZeppelin 的 ERC-20 合約內容是什麼?這些內容又為何存在?
+author: 作者:Ori Pomerantz
+lang: zh-tw
+tags: [ "穩固", "erc-20" ]
+skill: beginner
+published: 2021-03-09
+---
+
+## 介紹 {#introduction}
+
+以太坊最常見的用處之一就是為一個團隊建立一種可交易的代幣。某種意義上,這是屬於他們自己的貨幣。 這些代幣通常會遵循一項標準,即 [ERC-20](/developers/docs/standards/tokens/erc-20/)。 這項標準讓開發能與所有 ERC-20 代幣相容的工具(例如流動性池和錢包)成為可能。 在本文中,我們將分析 [OpenZeppelin Solidity ERC20 實作](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) 以及 [介面定義](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)。
+
+這是附有註解的原始碼。 如果您想實作 ERC-20,請[閱讀本教學](https://docs.openzeppelin.com/contracts/2.x/erc20-supply)。
+
+## 介面 {#the-interface}
+
+像 ERC-20 這樣的標準,其目的是為了讓許多代幣實作能夠在錢包和去中心化交易所等應用程式之間互通。 為了達成這個目標,我們建立一個[介面](https://www.geeksforgeeks.org/solidity/solidity-basics-of-interface/)。 任何需要使用代幣合約的程式碼,都可以使用介面中的相同定義,並與所有使用該介面的代幣合約相容,無論是像 MetaMask 這樣的錢包、etherscan.io 這樣的 dapp,或是像流動性池這樣的不同合約。
+
+
+
+如果你是有經驗的程式設計師,你可能還記得在 [Java](https://www.w3schools.com/java/java_interface.asp) 或甚至 [C 標頭檔](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html) 中看過類似的結構。
+
+這是 OpenZeppelin 的 [ERC-20 介面](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) 定義。 它是將[人類可讀標準](https://eips.ethereum.org/EIPS/eip-20)翻譯成 Solidity 程式碼的結果。 當然,介面本身並未定義要 _如何_ 做任何事。 這點會在下方的合約原始碼中解釋。
+
+
+
+```solidity
+// SPDX-License-Identifier: MIT
+```
+
+Solidity 檔案應該要包含一個授權許可證識別碼。 [您可以在此處查看授權許可證清單](https://spdx.org/licenses/)。 如果您需要不同的授權許可證,只要在註解中說明即可。
+
+
+
+```solidity
+pragma solidity >=0.6.0 <0.8.0;
+```
+
+Solidity 語言仍在快速發展,新版本可能與舊程式碼不相容([請參見此處](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html))。 因此,最好不僅指定語言的最低版本,還要指定最高版本,也就是您用來測試程式碼的最新版本。
+
+
+
+```solidity
+/**
+ * @dev EIP 中定義的 ERC20 標準介面。
+ */
+```
+
+註解中的 `@dev` 是 [NatSpec 格式](https://docs.soliditylang.org/en/develop/natspec-format.html) 的一部分,用於從原始碼產生文件。
+
+
+
+```solidity
+interface IERC20 {
+```
+
+按照慣例,介面名稱以 `I` 開頭。
+
+
+
+```solidity
+ /**
+ * @dev 傳回現存的代幣數量。
+ */
+ function totalSupply() external view returns (uint256);
+```
+
+此函式為 `external`,表示[它只能從合約外部呼叫](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2)。
+它會傳回合約中的代幣總供應量。 此值使用以太坊中最常見的類型傳回,即無正負號 256 位元(256 位元是 EVM 的原生字組大小)。 此函式也是 `view`,表示它不會改變狀態,因此可以在單一節點上執行,而不需由區塊鏈中的每個節點都執行它。 這類函式不會產生交易,也不會花費 [Gas](/developers/docs/gas/)。
+
+**注意:** 理論上,合約創建者似乎可以透過傳回比實際價值還小的總供應量來作弊,讓每個代幣看起來比實際更有價值。 然而,這種恐懼忽略了區塊鏈的真正本質。 區塊鏈上發生的每件事都可以由每個節點驗證。 為了達成這點,每個合約的機器語言程式碼和儲存空間在每個節點上都是可用的。 雖然您不需要為您的合約發布 Solidity 程式碼,但除非您發布原始碼以及編譯時所用的 Solidity 版本,否則沒有人會認真看待您的合約,這樣才能將其與您提供的機器語言程式碼進行驗證比對。
+例如,請參見[此合約](https://eth.blockscout.com/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD?tab=contract)。
+
+
+
+```solidity
+ /**
+ * @dev 傳回 `account` 擁有的代幣數量。
+ */
+ function balanceOf(address account) external view returns (uint256);
+```
+
+如同其名,`balanceOf` 傳回帳戶的餘額。 以太坊帳戶在 Solidity 中使用 `address` 類型來識別,該類型持有 160 位元。
+它也是 `external` 和 `view`。
+
+
+
+```solidity
+ /**
+ * @dev 將 `amount` 數量的代幣從呼叫者的帳戶轉移到 `recipient`。
+ *
+ * 傳回一個布林值,表示操作是否成功。
+ *
+ * 發出一個 {Transfer} 事件。
+ */
+ function transfer(address recipient, uint256 amount) external returns (bool);
+```
+
+`transfer` 函式將代幣從呼叫者轉移到一個不同的地址。 這涉及到狀態的改變,所以它不是一個 `view`。
+當使用者呼叫此函式時,會建立一筆交易並花費 Gas。 它也會發出一個 `Transfer` 事件,通知區塊鏈上的每個人該事件的發生。
+
+此函式針對兩種不同類型的呼叫者,有兩種輸出類型:
+
+- 從使用者介面直接呼叫函式的使用者。 通常使用者提交交易後,不會等待回應,因為回應可能需要不確定的時間。 使用者可以透過查看交易收據(由交易哈希識別)或尋找 `Transfer` 事件來了解發生了什麼事。
+- 其他合約,將函式呼叫作為整體交易的一部分。 這些合約會立即得到結果,因為它們在同一個交易中執行,所以它們可以使用函式的傳回值。
+
+其他改變合約狀態的函式也會產生相同類型的輸出。
+
+
+
+授權額度允許一個帳戶花費屬於不同所有者的代幣。
+舉例來說,這對於作為賣方的合約很有用。 合約無法監控事件,所以如果買方直接將代幣轉移給賣方合約,該合約不會知道它已收到款項。 取而代之的是,買方授權賣方合約花費一定金額,然後由賣方轉移該金額。
+這是透過賣方合約呼叫的一個函式來完成的,因此賣方合約可以知道它是否成功。
+
+```solidity
+ /**
+ * @dev 傳回 `spender` 將被允許透過 {transferFrom} 代表 `owner` 花費的
+ * 剩餘代幣數量。預設為零。
+ *
+ * 當 {approve} 或 {transferFrom} 被呼叫時,此值會改變。
+ */
+ function allowance(address owner, address spender) external view returns (uint256);
+```
+
+`allowance` 函式讓任何人都可以查詢一個地址 (`owner`) 允許另一個地址 (`spender`) 花費的授權額度。
+
+
+
+```solidity
+ /**
+ * @dev 將 `spender` 對呼叫者代幣的授權額度設為 `amount`。
+ *
+ * 傳回一個布林值,表示操作是否成功。
+ *
+ * 重要:請注意,使用此方法更改授權額度存在風險,
+ * 有人可能會因不幸的交易排序而同時使用舊的和新的授權額度。一種可能的解決方案是
+ * 先將花費者的授權額度降至 0,然後再設定所需的值,以減輕這種競爭
+ * 條件:
+ * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
+ *
+ * 發出一個 {Approval} 事件。
+ */
+ function approve(address spender, uint256 amount) external returns (bool);
+```
+
+`approve` 函式會建立一個授權額度。 請務必閱讀有關它如何被濫用的訊息。 在以太坊中,您可以控制自己交易的順序,但無法控制其他人交易的執行順序,除非您在看到對方的交易發生後才提交自己的交易。
+
+
+
+```solidity
+ /**
+ * @dev 使用授權額度機制將 `amount` 的代幣從 `sender` 轉移到 `recipient`。
+ * 然後,`amount` 會從呼叫者的授權額度中扣除。
+ *
+ * 傳回一個布林值,表示操作是否成功。
+ *
+ * 發出一個 {Transfer} 事件。
+ */
+ function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
+```
+
+最後,`transferFrom` 由花費者用來實際花費授權額度。
+
+
+
+```solidity
+
+ /**
+ * @dev 當 `value` 數量的代幣從一個帳戶 (`from`) 移動到
+ * 另一個帳戶 (`to`) 時發出。
+ *
+ * 請注意 `value` 可能為零。
+ */
+ event Transfer(address indexed from, address indexed to, uint256 value);
+
+ /**
+ * @dev 當 `owner` 的 `spender` 的授權額度透過
+ * 呼叫 {approve} 設定時發出。`value` 是新的授權額度。
+ */
+ event Approval(address indexed owner, address indexed spender, uint256 value);
+}
+```
+
+當 ERC-20 合約的狀態改變時,這些事件會被發出。
+
+## 實際的合約 {#the-actual-contract}
+
+這是實作 ERC-20 標準的實際合約,[取自此處](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)。
+它並非設計來直接使用,但您可以[繼承](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm)它來擴展成可用的東西。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >=0.6.0 <0.8.0;
+```
+
+
+
+### 匯入陳述式 {#import-statements}
+
+除了上述的介面定義外,合約定義還匯入了另外兩個檔案:
+
+```solidity
+
+import "../../GSN/Context.sol";
+import "./IERC20.sol";
+import "../../math/SafeMath.sol";
+```
+
+- `GSN/Context.sol` 是使用 [OpenGSN](https://www.opengsn.org/) 所需的定義,這是一個允許沒有以太幣的使用者使用區塊鏈的系統。 請注意這是舊版本,如果您想與 OpenGSN 整合,[請使用此教學](https://docs.opengsn.org/javascript-client/tutorial.html)。
+- [SafeMath 程式庫](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/),它能防止 Solidity 版本 **<0.8.0** 的算術溢位/下溢。 在 Solidity ≥0.8.0 中,算術運算會在溢位/下溢時自動還原,使得 SafeMath 不再必要。 此合約使用 SafeMath 以便向後相容於舊的編譯器版本。
+
+
+
+此註解說明了合約的用途。
+
+```solidity
+/**
+ * @dev {IERC20} 介面的實作。
+ *
+ * 此實作與代幣的創建方式無關。這意味著
+ * 必須在衍生合約中使用 {_mint} 新增供應機制。
+ * 若要使用通用機制,請參閱 {ERC20PresetMinterPauser}。
+ *
+ * 提示:詳細說明請參閱我們的指南
+ * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[如何
+ * 實作供應機制]。
+ *
+ * 我們遵循了一般的 OpenZeppelin 指南:函式在失敗時會還原
+ * 而非傳回 `false`。此行為是常規的
+ * 且不與 ERC20 應用程式的預期衝突。
+ *
+ * 此外,在呼叫 {transferFrom} 時會發出 {Approval} 事件。
+ * 這允許應用程式僅透過監聽所述事件來重構所有帳戶的授權額度。
+ * EIP 的其他實作可能不會發出這些事件,
+ * 因為規範並未要求。
+ *
+ * 最後,新增了非標準的 {decreaseAllowance} 和 {increaseAllowance}
+ * 函式來緩解圍繞設定授權額度的眾所周知的問題。
+ * 請參閱 {IERC20-approve}。
+ */
+
+```
+
+### 合約定義 {#contract-definition}
+
+```solidity
+contract ERC20 is Context, IERC20 {
+```
+
+此行指定了繼承關係,在此例中是繼承自上方的 `IERC20` 和用於 OpenGSN 的 `Context`。
+
+
+
+```solidity
+
+ using SafeMath for uint256;
+
+```
+
+此行將 `SafeMath` 程式庫附加到 `uint256` 類型上。 您可以在[此處](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol)找到此程式庫。
+
+### 變數定義 {#variable-definitions}
+
+這些定義指定了合約的狀態變數。 這些變數被宣告為 `private`,但這只意味著區塊鏈上的其他合約無法讀取它們。 _區塊鏈上沒有秘密_,每個節點上的軟體都擁有每個合約在每個區塊的狀態。 按照慣例,狀態變數的命名方式為 `_`。
+
+前兩個變數是[映射](https://www.tutorialspoint.com/solidity/solidity_mappings.htm),這意味著它們的行為大致與[關聯陣列](https://wikipedia.org/wiki/Associative_array)相同,只是鍵是數值。 只有值與預設值(零)不同的條目才會被分配儲存空間。
+
+```solidity
+ mapping (address => uint256) private _balances;
+```
+
+第一個映射 `_balances` 是地址及其對應的此代幣餘額。 要存取餘額,請使用此語法:`_balances[]`。
+
+
+
+```solidity
+ mapping (address => mapping (address => uint256)) private _allowances;
+```
+
+這個變數 `_allowances` 儲存了先前解釋過的授權額度。 第一個索引是代幣的所有者,第二個是擁有授權額度的合約。 要存取地址 A 可以從地址 B 帳戶花費的金額,請使用 `_allowances[B][A]`。
+
+
+
+```solidity
+ uint256 private _totalSupply;
+```
+
+如同其名,這個變數追蹤代幣的總供應量。
+
+
+
+```solidity
+ string private _name;
+ string private _symbol;
+ uint8 private _decimals;
+```
+
+這三個變數是用來提高可讀性的。 前兩個不言自明,但 `_decimals` 則不是。
+
+一方面,以太坊沒有浮點數或分數變數。 另一方面,人類喜歡能夠分割代幣。 人們選擇黃金作為貨幣的一個原因是,當有人想用牛換取等值的鴨子時,很難找零。
+
+解決方法是追蹤整數,但計算的不是實際的代幣,而是一個幾乎沒有價值的分數代幣。 以以太幣為例,分數代幣稱為 wei,而 10^18 wei 等於一 ETH。 在撰寫本文時,10,000,000,000,000 wei 約等於一美分或歐分。
+
+應用程式需要知道如何顯示代幣餘額。 如果一個使用者有 3,141,000,000,000,000,000 wei,那是 3.14 ETH 嗎? 31.41 ETH? 3,141 ETH? 以以太幣為例,定義是 10^18 wei 等於一 ETH,但對於您的代幣,您可以選擇不同的值。 如果分割代幣沒有意義,您可以使用 `_decimals` 值為零。 如果您想使用與 ETH 相同的標準,請使用值 **18**。
+
+### 建構函式 {#the-constructor}
+
+```solidity
+ /**
+ * @dev 設定 {name} 和 {symbol} 的值,並將 {decimals} 初始化為
+ * 預設值 18。
+ *
+ * 要為 {decimals} 選擇不同的值,請使用 {_setupDecimals}。
+ *
+ * 這三個值都是不可變的:它們只能在建構期間設定一次。
+ */
+ constructor (string memory name_, string memory symbol_) public {
+ // 在 Solidity ≥0.7.0 中,'public' 是隱含的,可以省略。
+
+ _name = name_;
+ _symbol = symbol_;
+ _decimals = 18;
+ }
+```
+
+建構函式在合約首次建立時被呼叫。 按照慣例,函式參數的命名方式為 `_`。
+
+### 使用者介面函式 {#user-interface-functions}
+
+```solidity
+ /**
+ * @dev 傳回代幣的名稱。
+ */
+ function name() public view returns (string memory) {
+ return _name;
+ }
+
+ /**
+ * @dev 傳回代幣的符號,通常是名稱的較短版本。
+ */
+ function symbol() public view returns (string memory) {
+ return _symbol;
+ }
+
+ /**
+ * @dev 傳回用於獲取其使用者表示的小數位數。
+ * 例如,如果 `decimals` 等於 `2`,`505` 代幣的餘額應
+ * 對使用者顯示為 `5,05` (`505 / 10 ** 2`)。
+ *
+ * 代幣通常選擇值 18,模仿以太幣和 wei 之間的關係。這是 {ERC20} 使用的值,
+ * 除非呼叫 {_setupDecimals}。
+ *
+ * 注意:此資訊僅用於 _顯示_ 目的:它在
+ * 任何方面都不會影響合約的任何算術,包括
+ * {IERC20-balanceOf} 和 {IERC20-transfer}。
+ */
+ function decimals() public view returns (uint8) {
+ return _decimals;
+ }
+```
+
+這些函式 `name`、`symbol` 和 `decimals` 幫助使用者介面了解您的合約,以便它們能夠正確顯示。
+
+傳回類型是 `string memory`,意思是傳回一個儲存在記憶體中的字串。 變數,例如字串,可以儲存在三個位置:
+
+| | 生命週期 | 合約存取 | Gas 成本 |
+| -------- | ---- | ---- | ------------------- |
+| 記憶體 | 函式呼叫 | 讀/寫 | 數十或數百(位置越高,成本越高) |
+| Calldata | 函式呼叫 | 唯讀 | 不能作為傳回類型,只能作為函式參數類型 |
+| 儲存 | 直到改變 | 讀/寫 | 高(讀取為 800,寫入為 2 萬) |
+
+在這種情況下,`memory` 是最佳選擇。
+
+### 讀取代幣資訊 {#read-token-information}
+
+這些是提供代幣資訊的函式,可以是總供應量或帳戶餘額。
+
+```solidity
+ /**
+ * @dev 請參閱 {IERC20-totalSupply}。
+ */
+ function totalSupply() public view override returns (uint256) {
+ return _totalSupply;
+ }
+```
+
+`totalSupply` 函式傳回代幣的總供應量。
+
+
+
+```solidity
+ /**
+ * @dev 請參閱 {IERC20-balanceOf}。
+ */
+ function balanceOf(address account) public view override returns (uint256) {
+ return _balances[account];
+ }
+```
+
+讀取帳戶的餘額。 請注意,任何人都可以獲取任何其他人的帳戶餘額。 試圖隱藏這些資訊是沒有意義的,因為它在每個節點上都是可用的。 _區塊鏈上沒有秘密。_
+
+### 轉移代幣 {#transfer-tokens}
+
+```solidity
+ /**
+ * @dev 請參閱 {IERC20-transfer}。
+ *
+ * 要求:
+ *
+ * - `recipient` 不能是零地址。
+ * - 呼叫者必須擁有至少 `amount` 的餘額。
+ */
+ function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
+```
+
+`transfer` 函式被呼叫來將代幣從發送者的帳戶轉移到另一個帳戶。 請注意,即使它傳回一個布林值,該值也始終為 **true**。 如果轉帳失敗,合約會還原該呼叫。
+
+
+
+```solidity
+ _transfer(_msgSender(), recipient, amount);
+ return true;
+ }
+```
+
+`_transfer` 函式執行實際的工作。 它是一個私有函式,只能由其他合約函式呼叫。 按照慣例,私有函式的命名方式與狀態變數相同,都是 `_`。
+
+通常在 Solidity 中,我們使用 `msg.sender` 來表示訊息發送者。 然而,這會破壞 [OpenGSN](http://opengsn.org/)。 如果我們想讓我們的代幣允許無以太幣的交易,我們需要使用 `_msgSender()`。 對於正常交易,它傳回 `msg.sender`,但對於無以太幣的交易,它傳回原始簽署者,而不是轉發訊息的合約。
+
+### 授權額度函式 {#allowance-functions}
+
+這些是實作授權額度功能的函式:`allowance`、`approve`、`transferFrom` 和 `_approve`。 此外,OpenZeppelin 的實作超越了基本標準,包含了一些提高安全性的功能:`increaseAllowance` 和 `decreaseAllowance`。
+
+#### allowance 函式 {#allowance}
+
+```solidity
+ /**
+ * @dev 請參閱 {IERC20-allowance}。
+ */
+ function allowance(address owner, address spender) public view virtual override returns (uint256) {
+ return _allowances[owner][spender];
+ }
+```
+
+`allowance` 函式允許每個人檢查任何授權額度。
+
+#### approve 函式 {#approve}
+
+```solidity
+ /**
+ * @dev 請參閱 {IERC20-approve}。
+ *
+ * 要求:
+ *
+ * - `spender` 不能是零地址。
+ */
+ function approve(address spender, uint256 amount) public virtual override returns (bool) {
+```
+
+此函式被呼叫來建立一個授權額度。 它與上面的 `transfer` 函式相似:
+
+- 此函式僅呼叫一個執行實際工作的內部函式(在本例中為 `_approve`)。
+- 此函式要麼傳回 `true`(如果成功),要麼還原(如果不成功)。
+
+
+
+```solidity
+ _approve(_msgSender(), spender, amount);
+ return true;
+ }
+```
+
+我們使用內部函式來最小化狀態變更發生的位置數量。 _任何_ 改變狀態的函式都是一個潛在的安全風險,需要進行安全審計。 這樣我們出錯的機會就更少了。
+
+#### transferFrom 函式 {#transferFrom}
+
+這是花費者呼叫來花費授權額度的函式。 這需要兩個操作:轉移花費的金額,並將授權額度減少該金額。
+
+```solidity
+ /**
+ * @dev 請參閱 {IERC20-transferFrom}。
+ *
+ * 發出一個 {Approval} 事件,表示已更新的授權額度。這不是 EIP 所要求的。
+ * 請參閱 {ERC20} 開頭的說明。
+ *
+ * 要求:
+ *
+ * - `sender` 和 `recipient` 不能是零地址。
+ * - `sender` 必須擁有至少 `amount` 的餘額。
+ * - 呼叫者對 ``sender`` 的代幣的授權額度必須至少為
+ * `amount`。
+ */
+ function transferFrom(address sender, address recipient, uint256 amount) public virtual
+ override returns (bool) {
+ _transfer(sender, recipient, amount);
+```
+
+
+
+`a.sub(b, "message")` 函式呼叫做兩件事。 首先,它計算 `a-b`,即新的授權額度。
+其次,它檢查此結果是否為負。 如果為負,則呼叫會以提供的訊息還原。 請註意,撤銷調用後,之前在調用中完成的任何處理都會被忽略,所以我們不需要撤消 _transfer。
+
+```solidity
+ _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount,
+ "ERC20: transfer amount exceeds allowance"));
+ return true;
+ }
+```
+
+#### OpenZeppelin 安全性附加功能 {#openzeppelin-safety-additions}
+
+將一個非零授權額度設定為另一個非零值是危險的,因為您只能控制自己交易的順序,而不能控制任何其他人的交易。 想像一下,您有兩個使用者,天真的 Alice 和不誠實的 Bill。 Alice 想要 Bill 的一些服務,她認為這需要五個代幣 - 所以她給了 Bill 五個代幣的授權額度。
+
+然後情況有變,Bill 的價格漲到了十個代幣。 仍然想要服務的 Alice 發送了一筆交易,將 Bill 的授權額度設定為十。 Bill 一在交易池中看到這筆新交易,就立即發送一筆交易,花掉 Alice 的五個代幣,並設定更高的 Gas 價格,以便更快地被挖出。 這樣,Bill 可以先花掉五個代幣,然後,一旦 Alice 的新授權額度被挖出,再花掉十個,總共十五個代幣,超過了 Alice 想要授權的數量。 這種技術被稱為[預先交易](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running)
+
+| Alice 的交易 | Alice 的 Nonce | Bill 的交易 | Bill 的 Nonce | Bill 的授權額度 | Bill 從 Alice 獲得的總收入 |
+| ------------------------------------ | ------------- | ------------------------------------------------ | ------------ | ---------- | ------------------- |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
+| approve(Bill, 10) | 11 | | | 10 | 5 |
+| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 15 |
+
+為避免此問題,這兩個函式(`increaseAllowance` 和 `decreaseAllowance`)允許您以特定數量修改授權額度。 因此,如果 Bill 已經花費了五個代幣,他將只能再花費五個。 根據時間點的不同,這有兩種可能的方式,但最終 Bill 都只會得到十個代幣:
+
+A:
+
+| Alice 的交易 | Alice 的 Nonce | Bill 的交易 | Bill 的 Nonce | Bill 的授權額度 | Bill 從 Alice 獲得的總收入 |
+| --------------------------------------------- | ------------: | ----------------------------------------------- | -----------: | ---------: | ------------------- |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
+| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 |
+| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 |
+
+B:
+
+| Alice 的交易 | Alice 的 Nonce | Bill 的交易 | Bill 的 Nonce | Bill 的授權額度 | Bill 從 Alice 獲得的總收入 |
+| --------------------------------------------- | ------------: | ------------------------------------------------ | -----------: | ---------: | ------------------: |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 |
+| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 |
+
+```solidity
+ /**
+ * @dev 以原子方式增加呼叫者授予 `spender` 的授權額度。
+ *
+ * 這是 {approve} 的替代方案,可用於緩解 {IERC20-approve} 中描述的問題。
+ *
+ * 發出一個 {Approval} 事件,表示已更新的授權額度。
+ *
+ * 要求:
+ *
+ * - `spender` 不能是零地址。
+ */
+ function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
+ _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));
+ return true;
+ }
+```
+
+`a.add(b)` 函式是安全的加法。 在 `a`+`b`>=`2^256` 的罕見情況下,它不會像正常加法那樣循環。
+
+```solidity
+
+ /**
+ * @dev 以原子方式減少呼叫者授予 `spender` 的授權額度。
+ *
+ * 這是 {approve} 的替代方案,可用於緩解 {IERC20-approve} 中描述的問題。
+ *
+ * 發出一個 {Approval} 事件,表示已更新的授權額度。
+ *
+ * 要求:
+ *
+ * - `spender` 不能是零地址。
+ * - `spender` 對呼叫者的授權額度必須至少為
+ * `subtractedValue`。
+ */
+ function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
+ _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue,
+ "ERC20: decreased allowance below zero"));
+ return true;
+ }
+```
+
+### 修改代幣資訊的函式 {#functions-that-modify-token-information}
+
+這四個函式執行實際的工作:`_transfer`、`_mint`、`_burn` 和 `_approve`。
+
+#### `_transfer` 函式 {#_transfer}
+
+```solidity
+ /**
+ * @dev 將 `amount` 的代幣從 `sender` 轉移到 `recipient`。
+ *
+ * 這個內部函式相當於 {transfer},可以用於
+ * 例如,實作自動代幣費用、削減機制等。
+ *
+ * 發出一個 {Transfer} 事件。
+ *
+ * 要求:
+ *
+ * - `sender` 不能是零地址。
+ * - `recipient` 不能是零地址。
+ * - `sender` 必須擁有至少 `amount` 的餘額。
+ */
+ function _transfer(address sender, address recipient, uint256 amount) internal virtual {
+```
+
+這個函式 `_transfer` 將代幣從一個帳戶轉移到另一個帳戶。 它同時被 `transfer`(用於從發送者自己的帳戶轉帳)和 `transferFrom`(用於使用授權額度從別人的帳戶轉帳)呼叫。
+
+
+
+```solidity
+ require(sender != address(0), "ERC20: transfer from the zero address");
+ require(recipient != address(0), "ERC20: transfer to the zero address");
+```
+
+在以太坊中,沒有人實際擁有零地址(也就是說,沒有人知道其對應的公鑰轉換為零地址的私鑰)。 當人們使用該地址時,通常是軟體錯誤 - 所以如果零地址被用作發送者或接收者,我們會失敗。
+
+
+
+```solidity
+ _beforeTokenTransfer(sender, recipient, amount);
+
+```
+
+有兩種方式可以使用此合約:
+
+1. 將其作為您自己程式碼的範本
+2. [繼承它](https://www.bitdegree.org/learn/solidity-inheritance),並只覆寫您需要修改的函式
+
+第二種方法要好得多,因為 OpenZeppelin ERC-20 程式碼已經過審計並被證明是安全的。 當您使用繼承時,您修改的函式會很清楚,要信任您的合約,人們只需要審計那些特定的函式。
+
+每次代幣易手時執行一個函式通常很有用。 然而,`_transfer` 是一個非常重要的函式,而且有可能寫得不安全(見下文),所以最好不要覆寫它。 解決方案是 `_beforeTokenTransfer`,一個[鉤子函式](https://wikipedia.org/wiki/Hooking)。 您可以覆寫此函式,它將在每次轉帳時被呼叫。
+
+
+
+```solidity
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
+ _balances[recipient] = _balances[recipient].add(amount);
+```
+
+這些是實際執行轉帳的程式碼行。 請注意,它們之間**沒有任何東西**,而且我們在將轉帳金額加到接收者之前,先從發送者那裡減去它。 這很重要,因為如果中間有呼叫到不同的合約,它可能會被用來欺騙此合約。 這樣,轉帳就是原子性的,中間不會發生任何事情。
+
+
+
+```solidity
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+最後,發出一個 `Transfer` 事件。 事件無法被智慧型合約存取,但在區塊鏈外執行的程式碼可以監聽事件並對其做出反應。 例如,錢包可以追蹤所有者何時獲得更多代幣。
+
+#### `_mint` 和 `_burn` 函式 {#_mint-and-_burn}
+
+這兩個函式(`_mint` 和 `_burn`)會修改代幣的總供應量。
+它們是內部函式,且此合約中沒有函式會呼叫它們,所以只有在您繼承此合約並加入自己的邏輯,以決定在何種情況下鑄造新代幣或銷毀現有代幣時,它們才有用。
+
+**注意:** 每個 ERC-20 代幣都有自己的商業邏輯來決定代幣管理。
+例如,一個固定供應量的合約可能只在建構函式中呼叫 `_mint`,而永不呼叫 `_burn`。 一個銷售代幣的合約在收到付款時會呼叫 `_mint`,並可能在某個時間點呼叫 `_burn` 以避免失控的通貨膨脹。
+
+```solidity
+ /** @dev 建立 `amount` 數量的代幣並將其分配給 `account`,增加
+ * 總供應量。
+ *
+ * 發出一個 `from` 設為零地址的 {Transfer} 事件。
+ *
+ * 要求:
+ *
+ * - `to` 不能是零地址。
+ */
+ function _mint(address account, uint256 amount) internal virtual {
+ require(account != address(0), "ERC20: mint to the zero address");
+ _beforeTokenTransfer(address(0), account, amount);
+ _totalSupply = _totalSupply.add(amount);
+ _balances[account] = _balances[account].add(amount);
+ emit Transfer(address(0), account, amount);
+ }
+```
+
+當代幣總數變更時,請務必更新 `_totalSupply`。
+
+
+
+```solidity
+ /**
+ * @dev 從 `account` 銷毀 `amount` 數量的代幣,減少
+ * 總供應量。
+ *
+ * 發出一個 `to` 設為零地址的 {Transfer} 事件。
+ *
+ * 要求:
+ *
+ * - `account` 不能是零地址。
+ * - `account` 必須至少擁有 `amount` 數量的代幣。
+ */
+ function _burn(address account, uint256 amount) internal virtual {
+ require(account != address(0), "ERC20: burn from the zero address");
+
+ _beforeTokenTransfer(account, address(0), amount);
+
+ _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
+ _totalSupply = _totalSupply.sub(amount);
+ emit Transfer(account, address(0), amount);
+ }
+```
+
+`_burn` 函式與 `_mint` 幾乎相同,只是方向相反。
+
+#### `_approve` 函式 {#_approve}
+
+這個函式實際上指定了授權額度。 注意,它允許所有者指定一個高於其目前餘額的授權額度。 這是可以的,因為餘額是在轉帳時檢查的,那時的餘額可能與建立授權額度時的餘額不同。
+
+```solidity
+ /**
+ * @dev 將 `spender` 對 `owner` 代幣的授權額度設為 `amount`。
+ *
+ * 這個內部函式等同於 `approve`,可以用於例如
+ * 為某些子系統設定自動授權額度等。
+ *
+ * 發出一個 {Approval} 事件。
+ *
+ * 要求:
+ *
+ * - `owner` 不能是零地址。
+ * - `spender` 不能是零地址。
+ */
+ function _approve(address owner, address spender, uint256 amount) internal virtual {
+ require(owner != address(0), "ERC20: approve from the zero address");
+ require(spender != address(0), "ERC20: approve to the zero address");
+
+ _allowances[owner][spender] = amount;
+```
+
+
+
+發出一個 `Approval` 事件。 根據應用程式的寫法,花費者合約可以由所有者或監聽這些事件的伺服器來告知核准。
+
+```solidity
+ emit Approval(owner, spender, amount);
+ }
+
+```
+
+### 修改小數位數變數 {#modify-the-decimals-variable}
+
+```solidity
+
+
+ /**
+ * @dev 將 {decimals} 設為非預設值 18 的值。
+ *
+ * 警告:此函式只應在建構函式中呼叫。大多數
+ * 與代幣合約互動的應用程式不會預期
+ * {decimals} 會改變,如果改變了可能會運作不正確。
+ */
+ function _setupDecimals(uint8 decimals_) internal {
+ _decimals = decimals_;
+ }
+```
+
+此函式修改 `_decimals` 變數,該變數用於告知使用者介面如何解讀金額。
+您應該從建構函式中呼叫它。 在之後的任何時間點呼叫它都是不誠實的,且應用程式並非設計來處理這種情況。
+
+### 挂鈎 {#hooks}
+
+```solidity
+
+ /**
+ * @dev 在任何代幣轉移之前呼叫的鉤子。這包括
+ * 鑄造和銷毀。
+ *
+ * 呼叫條件:
+ *
+ * - 當 `from` 和 `to` 都非零時,`amount` 數量的 ``from`` 的代幣
+ * 將被轉移到 `to`。
+ * - 當 `from` 為零時,將為 `to` 鑄造 `amount` 數量的代幣。
+ * - 當 `to` 為零時,`amount` 數量的 ``from`` 的代幣將被銷毀。
+ * - `from` 和 `to` 永遠不會同時為零。
+ *
+ * 要了解更多關於鉤子的資訊,請前往 xref:ROOT:extending-contracts.adoc#using-hooks[使用鉤子]。
+ */
+ function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
+}
+```
+
+這是在轉帳期間被呼叫的鉤子函式。 這裡它是空的,但如果您需要它做些什麼,您只需要覆寫它即可。
+
+## 結論 {#conclusion}
+
+總結一下,以下是此合約中一些最重要的概念(在我看來,您的看法可能會有所不同):
+
+- _在區塊鏈上沒有秘密_。 智慧型合約可以存取的任何資訊對全世界都是可用的。
+- 您可以控制自己交易的順序,但無法控制其他人交易的發生時間。 這就是為什麼更改授權額度可能很危險,因為它讓花費者可以花費兩個授權額度的總和。
+- `uint256` 類型的值會循環。 換句話說,_0-1=2^256-1_。 如果這不是期望的行為,您必須對其進行檢查(或使用 SafeMath 程式庫為您代勞)。 請注意,這在 [Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html) 中已有所改變。
+- 將所有特定類型的狀態變更集中在一個特定地方處理,因為這樣更容易審計。
+ 這就是為什麼我們有 `_approve`,它被 `approve`、`transferFrom`、`increaseAllowance` 和 `decreaseAllowance` 呼叫。
+- 狀態變更應該是原子性的,中間不應有任何其他操作(如您在 `_transfer` 中所見)。 這是因為在狀態變更期間,您會處於一個不一致的狀態。 例如,在您從發送者餘額中扣除和添加到接收者餘額之間的時間裡,存在的代幣數量少於應有的數量。 如果它們之間有操作,這點可能被濫用,特別是呼叫到一個不同的合約。
+
+既然您已經了解 OpenZeppelin ERC-20 合約是如何編寫的,特別是它是如何變得更安全的,現在就去編寫您自己的安全合約和應用程式吧。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md b/public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md
new file mode 100644
index 00000000000..210489a2d34
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md
@@ -0,0 +1,217 @@
+---
+title: 帶有安全措施的 ERC-20
+description: 如何幫助人們避免愚蠢的錯誤
+author: 作者:Ori Pomerantz
+lang: zh-tw
+tags: [ "erc-20" ]
+skill: beginner
+published: 2022-08-15
+---
+
+## 介紹 {#introduction}
+
+以太坊的一大優點是沒有中央機構可以修改或撤銷您的交易。 以太坊的一大問題是沒有中央機構有權力撤銷使用者錯誤或非法交易。 在本文中,您將了解使用者在使用 [ERC-20](/developers/docs/standards/tokens/erc-20/) 代幣時常犯的一些錯誤,以及如何創建 ERC-20 合約來幫助使用者避免這些錯誤,或賦予中央機構某些權力(例如凍結帳戶)。
+
+請注意,雖然我們將使用 [OpenZeppelin ERC-20 代幣合約](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20),但本文不會詳細解釋它。 您可以在[此處](/developers/tutorials/erc20-annotated-code)找到此資訊。
+
+如果您想查看完整的原始碼:
+
+1. 開啟 [Remix IDE](https://remix.ethereum.org/)。
+2. 點擊複製 github 圖示 ()。
+3. 複製 github 儲存庫 `https://github.com/qbzzt/20220815-erc20-safety-rails`。
+4. 開啟 **contracts > erc20-safety-rails.sol**。
+
+## 建立 ERC-20 合約 {#creating-an-erc-20-contract}
+
+在新增安全措施功能之前,我們需要一個 ERC-20 合約。 在本文中,我們將使用 [OpenZeppelin Contracts Wizard](https://docs.openzeppelin.com/contracts/5.x/wizard)。 在另一個瀏覽器中開啟它,並按照以下說明操作:
+
+1. 選擇 **ERC20**。
+
+2. 輸入以下設定:
+
+ | 參數 | 數值 |
+ | ------- | ---------------- |
+ | 名稱 | SafetyRailsToken |
+ | 符號 | SAFE |
+ | Premint | 1000 |
+ | 功能 | 無 |
+ | 存取控制 | Ownable |
+ | 可升級性 | 無 |
+
+3. 向上捲動並點擊 **在 Remix 中開啟** (適用於 Remix) 或 **下載** 以使用不同的環境。 我將假設您正在使用 Remix,如果您使用其他工具,請進行相應的變更。
+
+4. 我們現在有了一個功能齊全的 ERC-20 合約。 您可以展開 `.deps` > `npm` 以查看匯入的程式碼。
+
+5. 編譯、部署並操作合約,以確認它能作為 ERC-20 合約運作。 如果您需要學習如何使用 Remix,請[使用此教學](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth)。
+
+## 常見錯誤 {#common-mistakes}
+
+### 錯誤 {#the-mistakes}
+
+使用者有時會將代幣傳送到錯誤的地址。 雖然我們無法讀懂他們的心思來了解他們想做什麼,但有兩種經常發生且易於偵測的錯誤類型:
+
+1. 將代幣傳送到合約自己的地址。 例如,[Optimism 的 OP 代幣](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c) 在不到兩個月的時間裡累積了[超過 120,000](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000042) 個 OP 代幣。 這代表著一筆巨大的財富,推測是人們剛剛損失的。
+
+2. 將代幣傳送到一個空地址,該地址不對應於[外部擁有帳戶](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs)或[智能合約](/developers/docs/smart-contracts)。 雖然我沒有關於這種情況發生頻率的統計數據,但[一次事件可能造成 20,000,000 個代幣的損失](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595)。
+
+### 防止轉帳 {#preventing-transfers}
+
+OpenZeppelin ERC-20 合約包含一個[掛鉤 `_beforeTokenTransfer`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368),它在代幣轉移之前被調用。 預設情況下,這個掛鉤不做任何事情,但我們可以在其上掛載自己的功能,例如在出現問題時回復的檢查。
+
+要使用此掛鉤,請在建構函式後新增此函式:
+
+```solidity
+ function _beforeTokenTransfer(address from, address to, uint256 amount)
+ internal virtual
+ override(ERC20)
+ {
+ super._beforeTokenTransfer(from, to, amount);
+ }
+```
+
+如果您對 Solidity 不太熟悉,此函式的某些部分可能對您來說是新的:
+
+```solidity
+ internal virtual
+```
+
+`virtual` 關鍵字表示,正如我們從 `ERC20` 繼承功能並覆寫此函式一樣,其他合約也可以從我們這裡繼承並覆寫此函式。
+
+```solidity
+ override(ERC20)
+```
+
+我們必須明確指定我們正在[覆寫](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding) `_beforeTokenTransfer` 的 ERC20 代幣定義。 一般來說,從安全角度來看,明確的定義比隱含的定義好得多——如果事情就在您眼前,您就不會忘記您做了什麼。 這也是我們需要指定我們正在覆寫哪個父類的 `_beforeTokenTransfer` 的原因。
+
+```solidity
+ super._beforeTokenTransfer(from, to, amount);
+```
+
+此行調用我們從其繼承的合約中擁有 `_beforeTokenTransfer` 函式的函式。 在這種情況下,只有 `ERC20` 有這個掛鉤,`Ownable` 沒有。 儘管目前 `ERC20._beforeTokenTransfer` 不做任何事情,我們還是調用它,以防將來新增功能(然後我們決定重新部署合約,因為合約在部署後不會改變)。
+
+### 編寫要求 {#coding-the-requirements}
+
+我們希望向函式新增這些要求:
+
+- `to` 地址不能等於 `address(this)`,即 ERC-20 合約本身的地址。
+- `to` 地址不能為空,它必須是:
+ - 一個外部擁有帳戶 (EOA)。 我們無法直接檢查一個地址是否為 EOA,但我們可以檢查一個地址的 ETH 餘額。 EOA 幾乎總是有餘額,即使它們不再使用——很難將它們清零到最後一個 wei。
+ - 一個智能合約。 測試一個地址是否為智能合約有點困難。 有一個檢查外部程式碼長度的 opcode,稱為 [`EXTCODESIZE`](https://www.evm.codes/#3b),但它在 Solidity 中不能直接使用。 我們必須為此使用 [Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html),它是一種 EVM 組合語言。 我們可以使用 Solidity 中的其他值([`.code` 和 `.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)),但它們的成本更高。
+
+讓我們逐行查看新的程式碼:
+
+```solidity
+ require(to != address(this), "不能將代幣傳送到合約地址");
+```
+
+這是第一個要求,檢查 `to` 和 `this(address)` 是否不是同一個東西。
+
+```solidity
+ bool isToContract;
+ assembly {
+ isToContract := gt(extcodesize(to), 0)
+ }
+```
+
+這是我們檢查一個地址是否為合約的方式。 我們無法直接從 Yul 接收輸出,因此我們定義一個變數來儲存結果(在本例中為 `isToContract`)。 Yul 的工作方式是每個 opcode 都被視為一個函式。 所以首先我們調用 [`EXTCODESIZE`](https://www.evm.codes/#3b) 來獲取合約大小,然後使用 [`GT`](https://www.evm.codes/#11) 來檢查它是否不為零(我們處理的是無符號整數,所以它當然不能是負數)。 然後我們將結果寫入 `isToContract`。
+
+```solidity
+ require(to.balance != 0 || isToContract, "不能將代幣傳送到空地址");
+```
+
+最後,我們有了對空地址的實際檢查。
+
+## 管理員存取權 {#admin-access}
+
+有時,有一個可以撤銷錯誤的管理員是很有用的。 為了減少濫用的可能性,這個管理員可以是一個[多重簽名](https://blog.logrocket.com/security-choices-multi-signature-wallets/),這樣就需要多個人同意一項操作。 在本文中,我們將介紹兩種管理功能:
+
+1. 凍結和解凍帳戶。 這很有用,例如,當一個帳戶可能被盜用時。
+2. 資產清理。
+
+ 有時,詐騙者會將欺詐性代幣傳送到真實代幣的合約中以獲得合法性。 例如,[請看這裡](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe?tab=holders)。 合法的 ERC-20 合約是 [0x4200....0042](https://optimism.blockscout.com/token/0x4200000000000000000000000000000000000042)。 冒充它的詐騙是 [0x234....bbe](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe)。
+
+ 人們也可能錯誤地將合法的 ERC-20 代幣傳送到我們的合約中,這也是我們希望有辦法將它們取出的另一個原因。
+
+OpenZeppelin 提供了兩種啟用管理員存取權的機制:
+
+- [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) 合約只有一個擁有者。 具有 `onlyOwner` [修飾符](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm)的函式只能由該擁有者調用。 擁有者可以將所有權轉讓給其他人或完全放棄。 所有其他帳戶的權利通常是相同的。
+- [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control) 合約具有[基於角色的存取控制 (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control)。
+
+為簡單起見,本文我們使用 `Ownable`。
+
+### 凍結和解凍合約 {#freezing-and-thawing-contracts}
+
+凍結和解凍合約需要進行幾項變更:
+
+- 一個從地址到[布林值](https://en.wikipedia.org/wiki/Boolean_data_type)的[對應](https://www.tutorialspoint.com/solidity/solidity_mappings.htm),用於追蹤哪些地址被凍結。 所有值最初都為零,對於布林值,這被解釋為 false。 這就是我們想要的,因為預設情況下帳戶是未凍結的。
+
+ ```solidity
+ mapping(address => bool) public frozenAccounts;
+ ```
+
+- 當帳戶被凍結或解凍時,使用[事件](https://www.tutorialspoint.com/solidity/solidity_events.htm)通知任何感興趣的人。 從技術上講,這些操作不需要事件,但它有助於鏈外程式碼能夠監聽這些事件並了解正在發生的事情。 當發生可能與他人相關的事情時,智能合約發出事件被認為是一種良好的習慣。
+
+ 事件被索引,因此可以搜尋帳戶被凍結或解凍的所有次數。
+
+ ```solidity
+ // 當帳戶被凍結或解凍時
+ event AccountFrozen(address indexed _addr);
+ event AccountThawed(address indexed _addr);
+ ```
+
+- 用於凍結和解凍帳戶的函式。 這兩個函式幾乎相同,所以我們只會介紹凍結函式。
+
+ ```solidity
+ function freezeAccount(address addr)
+ public
+ onlyOwner
+ ```
+
+ 標記為 [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm) 的函式可以從其他智能合約或直接透過交易調用。
+
+ ```solidity
+ {
+ require(!frozenAccounts[addr], "帳戶已凍結");
+ frozenAccounts[addr] = true;
+ emit AccountFrozen(addr);
+ } // freezeAccount
+ ```
+
+ 如果帳戶已凍結,則回復。 否則,凍結它並 `emit` 一個事件。
+
+- 變更 `_beforeTokenTransfer` 以防止資金從凍結帳戶中移出。 請注意,資金仍然可以轉入凍結帳戶。
+
+ ```solidity
+ require(!frozenAccounts[from], "帳戶已凍結");
+ ```
+
+### 資產清理 {#asset-cleanup}
+
+要釋放此合約持有的 ERC-20 代幣,我們需要調用它們所屬代幣合約上的一個函式,可以是 [`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer) 或 [`approve`](https://eips.ethereum.org/EIPS/eip-20#approve)。 在這種情況下,在授權上浪費 Gas 是沒有意義的,我們不如直接轉帳。
+
+```solidity
+ function cleanupERC20(
+ address erc20,
+ address dest
+ )
+ public
+ onlyOwner
+ {
+ IERC20 token = IERC20(erc20);
+```
+
+這是我們在收到地址時為合約建立物件的語法。 我們可以這樣做,因為我們的原始碼中包含了 ERC20 代幣的定義(參見第 4 行),並且該檔案包含了 [IERC20 的定義](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol),這是 OpenZeppelin ERC-20 合約的介面。
+
+```solidity
+ uint balance = token.balanceOf(address(this));
+ token.transfer(dest, balance);
+ }
+```
+
+這是一個清理函式,所以我們大概不希望留下任何代幣。 與其手動從使用者那裡獲取餘額,我們不如自動化這個過程。
+
+## 結論 {#conclusion}
+
+這不是一個完美的解決方案——對於「使用者犯錯」這個問題,沒有完美的解決方案。 然而,使用這類檢查至少可以防止一些錯誤。 凍結帳戶的能力雖然危險,但可以用來限制某些駭客攻擊的損害,方法是拒絕駭客竊取資金。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md b/public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md
new file mode 100644
index 00000000000..551a820bf0c
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md
@@ -0,0 +1,886 @@
+---
+title: 使用以太坊進行 Web2 驗證
+description: 閱讀本教學後,開發者將能夠將以太坊登入 (Web3) 與 SAML 登入整合。SAML 登入是 Web2 中使用的一種標準,可提供單一登入及其他相關服務。 這允許透過以太坊簽章來驗證對 Web2 資源的存取,且使用者屬性來自證明。
+author: 作者:Ori Pomerantz
+tags: [ "web2", "驗證", "eas" ]
+skill: beginner
+lang: zh-tw
+published: 2025-04-30
+---
+
+## 簡介
+
+[SAML](https://www.onelogin.com/learn/saml) 是 Web2 上使用的一種標準,允許[身分提供者 (IdP)](https://en.wikipedia.org/wiki/Identity_provider#SAML_identity_provider) 為[服務提供者 (SP)](https://en.wikipedia.org/wiki/Service_provider_\(SAML\)) 提供使用者資訊。
+
+在本教學中,您將學習如何將以太坊簽章與 SAML 整合,讓使用者能夠使用其以太坊錢包來對那些尚不原生支援以太坊的 Web2 服務進行身分驗證。
+
+請注意,本教學是為兩種不同的受眾所撰寫:
+
+- 了解以太坊且需要學習 SAML 的以太坊使用者
+- 了解 SAML 和 Web2 驗證且需要學習以太坊的 Web2 使用者
+
+因此,本教學會包含許多您已知的入門資料。 您可以隨意跳過。
+
+### 為以太坊使用者介紹 SAML
+
+SAML 是一種中心化協定。 只有在服務提供者 (SP) 與身分提供者 (IdP) 或簽署該 IdP 憑證的[憑證授權單位](https://www.ssl.com/article/what-is-a-certificate-authority-ca/)有預先存在的信任關係時,服務提供者才會接受身分提供者所做的斷言 (例如「這是我的使用者 John,他應該有權限執行 A、B 和 C」)。
+
+例如,SP 可以是為公司提供旅行服務的旅行社,而 IdP 可以是公司的內部網站。 當員工需要預訂商務旅行時,旅行社會在允許他們實際預訂旅行之前,先將他們傳送到公司進行驗證。
+
+
+
+這就是瀏覽器、SP 和 IdP 這三個實體協商存取權限的方式。 SP 不需要事先知道任何關於使用瀏覽器的使用者的資訊,只需要信任 IdP 即可。
+
+### 為 SAML 使用者介紹以太坊
+
+以太坊是去中心化系統。
+
+
+
+使用者擁有私密金鑰 (通常儲存在瀏覽器擴充功能中)。 您可以從私密金鑰衍生出公鑰,再從公鑰衍生出 20 位元組的地址。 當使用者需要登入系統時,系統會要求他們簽署一則附有 nonce (單次使用值) 的訊息。 伺服器可以驗證該簽章是由該地址所建立。
+
+
+
+該簽章只會驗證以太坊地址。 若要取得其他使用者屬性,您通常會使用[證明](https://attest.org/)。 證明通常具有以下欄位:
+
+- **證明人**,做出證明的地址
+- **接收者**,證明所適用的地址
+- **資料**,正在證明的資料,例如姓名、權限等。
+- **結構**,用於解譯資料的結構 ID。
+
+由於以太坊的去中心化性質,任何使用者都可以做出證明。 證明人的身分對於識別我們認為哪些證明是可靠的至關重要。
+
+## 設定
+
+第一步是讓 SAML SP 和 SAML IdP 能夠互相通訊。
+
+1. 下載軟體。 本文的範例軟體在 [github](https://github.com/qbzzt/250420-saml-ethereum) 上。 不同的階段儲存在不同的分支中,此階段您需要 `saml-only`
+
+ ```sh
+ git clone https://github.com/qbzzt/250420-saml-ethereum -b saml-only
+ cd 250420-saml-ethereum
+ pnpm install
+ ```
+
+2. 使用自我簽署憑證建立金鑰。 這表示該金鑰本身即是憑證授權單位,需要手動匯入至服務提供者。 如需詳細資訊,請參閱 [OpenSSL 文件](https://docs.openssl.org/master/man1/openssl-req/)。
+
+ ```sh
+ mkdir keys
+ cd keys
+ openssl req -new -x509 -days 365 -nodes -sha256 -out saml-sp.crt -keyout saml-sp.pem -subj /CN=sp/
+ openssl req -new -x509 -days 365 -nodes -sha256 -out saml-idp.crt -keyout saml-idp.pem -subj /CN=idp/
+ cd ..
+ ```
+
+3. 啟動伺服器 (SP 和 IdP)
+
+ ```sh
+ pnpm start
+ ```
+
+4. 瀏覽至 SP URL [http://localhost:3000/](http://localhost:3000/),然後按一下按鈕,重新導向至 IdP (通訊埠 3001)。
+
+5. 向 IdP 提供您的電子郵件地址,然後按一下「**登入服務提供者**」。 確認您已重新導向回服務提供者 (通訊埠 3000),且服務提供者可透過您的電子郵件地址識別您的身分。
+
+### 詳細說明
+
+以下是逐步發生的情況:
+
+
+
+#### src/config.mts
+
+此檔案包含身分提供者和服務提供者的組態。 通常這兩者是不同的實體,但為了簡便起見,我們在此共用程式碼。
+
+```typescript
+const fs = await import("fs")
+
+const protocol="http"
+```
+
+目前我們只是在測試,所以使用 HTTP 沒問題。
+
+```typescript
+export const spCert = fs.readFileSync("keys/saml-sp.crt").toString()
+export const idpCert = fs.readFileSync("keys/saml-idp.crt").toString()
+```
+
+讀取公鑰,公鑰通常可供兩個元件使用 (直接信任,或由受信任的憑證授權單位簽署)。
+
+```typescript
+export const spPort = 3000
+export const spHostname = "localhost"
+export const spDir = "sp"
+
+export const idpPort = 3001
+export const idpHostname = "localhost"
+export const idpDir = "idp"
+
+export const spUrl = `${protocol}://${spHostname}:${spPort}/${spDir}`
+export const idpUrl = `${protocol}://${idpHostname}:${idpPort}/${idpDir}`
+```
+
+這兩個元件的 URL。
+
+```typescript
+export const spPublicData = {
+```
+
+服務提供者的公開資料。
+
+```typescript
+ entityID: `${spUrl}/metadata`,
+```
+
+在 SAML 中,依照慣例,`entityID` 是實體中繼資料所在的 URL。 此中繼資料對應於此處的公開資料,但其格式為 XML。
+
+```typescript
+ wantAssertionsSigned: true,
+ authnRequestsSigned: false,
+ signingCert: spCert,
+ allowCreate: true,
+ assertionConsumerService: [{
+ Binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
+ Location: `${spUrl}/assertion`,
+ }]
+ }
+```
+
+就我們的目的而言,最重要的定義是 `assertionConsumerServer`。 這表示若要向服務提供者宣告某件事 (例如「傳送此資訊給您的使用者是 somebody@example.com」),我們需要使用 [HTTP POST](https://www.w3schools.com/tags/ref_httpmethods.asp) 到 URL `http://localhost:3000/sp/assertion`。
+
+```typescript
+export const idpPublicData = {
+ entityID: `${idpUrl}/metadata`,
+ signingCert: idpCert,
+ wantAuthnRequestsSigned: false,
+ singleSignOnService: [{
+ Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
+ Location: `${idpUrl}/login`
+ }],
+ singleLogoutService: [{
+ Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
+ Location: `${idpUrl}/logout`
+ }],
+ }
+```
+
+身分提供者的公開資料是相似的。 它指定若要登入使用者,您需 POST 至 `http://localhost:3001/idp/login`,若要登出使用者,則 POST 至 `http://localhost:3001/idp/logout`。
+
+#### src/sp.mts
+
+這是實作服務提供者的程式碼。
+
+```typescript
+import * as config from "./config.mts"
+const fs = await import("fs")
+const saml = await import("samlify")
+```
+
+我們使用 [`samlify`](https://www.npmjs.com/package/samlify) 庫來實作 SAML。
+
+```typescript
+import * as validator from "@authenio/samlify-node-xmllint"
+saml.setSchemaValidator(validator)
+```
+
+`samlify` 庫需要一個套件來驗證 XML 是否正確、是否使用預期的公鑰簽署等。 為此,我們使用 [`@authenio/samlify-node-xmllint`](https://www.npmjs.com/package/@authenio/samlify-node-xmllint)。
+
+```typescript
+const express = (await import("express")).default
+const spRouter = express.Router()
+const app = express()
+```
+
+[`express`](https://expressjs.com/) [`Router`](https://expressjs.com/en/5x/api.html#router) 是一個可以掛載在網站中的「迷你網站」。 在此情況下,我們使用它將所有服務提供者定義群組在一起。
+
+```typescript
+const spPrivateKey = fs.readFileSync("keys/saml-sp.pem").toString()
+
+const sp = saml.ServiceProvider({
+ privateKey: spPrivateKey,
+ ...config.spPublicData
+})
+```
+
+服務提供者自身的表示是所有公開資料,以及它用來簽署資訊的私密金鑰。
+
+```typescript
+const idp = saml.IdentityProvider(config.idpPublicData);
+```
+
+公開資料包含服務提供者需要了解的身分提供者的所有資訊。
+
+```typescript
+spRouter.get(`/metadata`,
+ (req, res) => res.header("Content-Type", "text/xml").send(sp.getMetadata())
+)
+```
+
+為了與其他 SAML 元件互通,服務和身分提供者的公開資料 (稱為中繼資料) 應以 XML 格式在 `/metadata` 中提供。
+
+```typescript
+spRouter.post(`/assertion`,
+```
+
+這是瀏覽器存取以識別自身的頁面。 宣告包含使用者識別碼 (此處我們使用電子郵件地址),並且可以包含額外的屬性。 這是上方序列圖中步驟 7 的處理常式。
+
+```typescript
+ async (req, res) => {
+ // console.log(`SAML response:\n${Buffer.from(req.body.SAMLResponse, 'base64').toString('utf-8')}`)
+```
+
+您可以使用已註解的指令來查看斷言中提供的 XML 資料。 它是 [base64 編碼的](https://en.wikipedia.org/wiki/Base64)。
+
+```typescript
+ try {
+ const loginResponse = await sp.parseLoginResponse(idp, 'post', req);
+```
+
+解析來自身分伺服器的登入請求。
+
+```typescript
+ res.send(`
+
+
+ Hello ${loginResponse.extract.nameID}
+
+
+ `)
+ res.send();
+```
+
+傳送 HTML 回應,僅是為了向使用者顯示我們已收到登入請求。
+
+```typescript
+ } catch (err) {
+ console.error('Error processing SAML response:', err);
+ res.status(400).send('SAML authentication failed');
+ }
+ }
+)
+```
+
+如果失敗,請通知使用者。
+
+```typescript
+spRouter.get('/login',
+```
+
+當瀏覽器嘗試取得此頁面時,建立一個登入請求。 這是上方序列圖中步驟 1 的處理常式。
+
+```typescript
+ async (req, res) => {
+ const loginRequest = await sp.createLoginRequest(idp, "post")
+```
+
+取得發布登入請求的資訊。
+
+```typescript
+ res.send(`
+
+
+
+```
+
+此頁面會自動提交表單 (見下文)。 如此一來,使用者就不需要執行任何操作即可被重新導向。 這是上方序列圖中的步驟 2。
+
+```typescript
+
+
+
+ `)
+ }
+)
+
+app.use(express.urlencoded({extended: true}))
+```
+
+[此中介軟體](https://expressjs.com/en/5x/api.html#express.urlencoded) 會讀取 [HTTP 請求](https://www.tutorialspoint.com/http/http_requests.htm)的主體。 預設情況下,express 會忽略它,因為大多數請求並不需要它。 我們需要它,因為 POST 會使用主體。
+
+```typescript
+app.use(`/${config.spDir}`, spRouter)
+```
+
+在服務提供者目錄 (`/sp`) 中掛載路由器。
+
+```typescript
+app.get("/", (req, res) => {
+ res.send(`
+
+
+
+
+
+ `)
+})
+```
+
+如果瀏覽器嘗試取得根目錄,請為其提供登入頁面的連結。
+
+```typescript
+app.listen(config.spPort, () => {
+ console.log(`service provider is running on http://${config.spHostname}:${config.spPort}`)
+})
+```
+
+使用此 express 應用程式監聽 `spPort`。
+
+#### src/idp.mts
+
+這是身分提供者。 它與服務提供者非常相似,以下說明是針對不同的部分。
+
+```typescript
+const xmlParser = new (await import("fast-xml-parser")).XMLParser(
+ {
+ ignoreAttributes: false, // Preserve attributes
+ attributeNamePrefix: "@_", // Prefix for attributes
+ }
+)
+```
+
+我們需要讀取並理解從服務提供者收到的 XML 請求。
+
+```typescript
+const getLoginPage = requestId => `
+```
+
+此函數會建立一個帶有自動提交表單的頁面,該頁面會在上方序列圖的步驟 4 中傳回。
+
+```typescript
+
+
+ Login page
+
+
+ Login page
+
+
+
+
+const idpRouter = express.Router()
+
+idpRouter.post("/loginSubmitted", async (req, res) => {
+ const loginResponse = await idp.createLoginResponse(
+```
+
+這是上方序列圖中步驟 5 的處理常式。 [`idp.createLoginResponse`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L73-L125) 會建立登入回應。
+
+```typescript
+ sp,
+ {
+ authnContextClassRef: 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport',
+ audience: sp.entityID,
+```
+
+對象為服務提供者。
+
+```typescript
+ extract: {
+ request: {
+ id: req.body.requestId
+ }
+ },
+```
+
+從請求中提取的資訊。 我們在請求中關心的一個參數是 requestId,它讓服務提供者能夠匹配請求及其回應。
+
+```typescript
+ signingKey: { privateKey: idpPrivateKey, publicKey: config.idpCert } // Ensure signing
+```
+
+我們需要 `signingKey` 擁有簽署回應的資料。 服務提供者不信任未經簽署的請求。
+
+```typescript
+ },
+ "post",
+ {
+ email: req.body.email
+```
+
+這是我們傳送回服務提供者的使用者資訊欄位。
+
+```typescript
+ }
+ );
+
+ res.send(`
+
+
+
+
+
+
+
+ `)
+})
+```
+
+同樣,使用自動提交的表單。 這是上方序列圖中的步驟 6。
+
+```typescript
+
+// IdP endpoint for login requests
+idpRouter.post(`/login`,
+```
+
+這是從服務提供者接收登入請求的端點。 這是上方序列圖中步驟 3 的處理常式。
+
+```typescript
+ async (req, res) => {
+ try {
+ // Workaround because I couldn't get parseLoginRequest to work.
+ // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
+ const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
+ res.send(getLoginPage(samlRequest["samlp:AuthnRequest"]["@_ID"]))
+```
+
+我們應該能夠使用 [`idp.parseLoginRequest`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L127-L144) 來讀取驗證請求的 ID。 然而,我無法讓它正常運作,而且不值得花太多時間,所以我只使用[通用的 XML 解析器](https://www.npmjs.com/package/fast-xml-parser)。 我們需要的資訊是 `` 標籤內的 `ID` 屬性,它位於 XML 的最上層。
+
+## 使用以太坊簽章
+
+既然我們能夠將使用者身分傳送給服務提供者,下一步就是以受信任的方式取得使用者身分。 Viem 允許我們直接向錢包詢問使用者地址,但這表示要向瀏覽器索取資訊。 我們無法控制瀏覽器,所以不能自動信任從它那裡得到的回應。
+
+因此,IdP 會傳送一個字串給瀏覽器進行簽署。 如果瀏覽器中的錢包簽署了這個字串,這就表示它確實是那個地址 (也就是說,它知道對應於該地址的私密金鑰)。
+
+要查看此操作,請停止現有的 IdP 和 SP,並執行以下命令:
+
+```sh
+git checkout eth-signatures
+pnpm install
+pnpm start
+```
+
+然後瀏覽至 [SP](http://localhost:3000) 並依照指示操作。
+
+請注意,此時我們不知道如何從以太坊地址取得電子郵件地址,因此我們向 SP 回報 `@bad.email.address`。
+
+### 詳細說明
+
+變更發生在先前圖表中的步驟 4-5。
+
+
+
+我們唯一變更的檔案是 `idp.mts`。 以下是已變更的部分。
+
+```typescript
+import { v4 as uuidv4 } from 'uuid'
+import { verifyMessage } from 'viem'
+```
+
+我們需要這兩個額外的庫。 我們使用 [`uuid`](https://www.npmjs.com/package/uuid) 來建立 [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) 值。 值本身並不重要,重要的是它只使用一次。
+
+[`viem`](https://viem.sh/) 庫讓我們能夠使用以太坊的定義。 此處我們需要它來驗證簽章確實有效。
+
+```typescript
+const loginPrompt = "To access the service provider, sign this nonce: "
+```
+
+錢包會要求使用者允許簽署該訊息。 僅包含 nonce 的訊息可能會讓使用者感到困惑,因此我們加入了這個提示。
+
+```typescript
+// Keep requestIDs here
+let nonces = {}
+```
+
+我們需要請求資訊才能回應它。 我們可以隨請求傳送它 (步驟 4),然後再接收回來 (步驟 5)。 然而,我們不能信任從瀏覽器取得的資訊,因為瀏覽器在一個可能具有敵意的使用者的控制之下。 所以最好將它儲存在這裡,並以 nonce 作為金鑰。
+
+請注意,為了簡單起見,我們在此將它作為一個變數。 然而,這有幾個缺點:
+
+- 我們容易受到拒絕服務攻擊。 惡意使用者可以多次嘗試登入,耗盡我們的記憶體。
+- 如果 IdP 程序需要重新啟動,我們會遺失現有的值。
+- 我們無法在多個程序之間進行負載平衡,因為每個程序都有自己的變數。
+
+在生產系統上,我們會使用資料庫並實作某種過期機制。
+
+```typescript
+const getSignaturePage = requestId => {
+ const nonce = uuidv4()
+ nonces[nonce] = requestId
+```
+
+建立一個 nonce,並儲存 `requestId` 以供日後使用。
+
+```typescript
+ return `
+
+
+
+
+
+ Please sign
+
+
+
+
+
+`
+}
+```
+
+其餘的只是標準的 HTML。
+
+```typescript
+idpRouter.get("/signature/:nonce/:account/:signature", async (req, res) => {
+```
+
+這是序列圖中步驟 5 的處理常式。
+
+```typescript
+ const requestId = nonces[req.params.nonce]
+ if (requestId === undefined) {
+ res.send("Bad nonce")
+ return ;
+ }
+
+ nonces[req.params.nonce] = undefined
+```
+
+取得請求 ID,並從 `nonces` 中刪除該 nonce,以確保無法重複使用。
+
+```typescript
+ try {
+```
+
+由於簽章可能無效的方式有很多種,我們將此包裝在 `try ...` `catch` 區塊中,以捕捉任何擲出的錯誤。
+
+```typescript
+ const validSignature = await verifyMessage({
+ address: req.params.account,
+ message: `${loginPrompt}${req.params.nonce}`,
+ signature: req.params.signature
+ })
+```
+
+使用 [`verifyMessage`](https://viem.sh/docs/actions/public/verifyMessage#verifymessage) 來實作序列圖中的步驟 5.5。
+
+```typescript
+ if (!validSignature)
+ throw("Bad signature")
+ } catch (err) {
+ res.send("Error:" + err)
+ return ;
+ }
+```
+
+此處理程式的其餘部分與我們之前在 `/loginSubmitted` 處理程式中所做的相同,除了一個小小的變更。
+
+```typescript
+ const loginResponse = await idp.createLoginResponse(
+ .
+ .
+ .
+ {
+ email: req.params.account + "@bad.email.address"
+ }
+ );
+```
+
+我們沒有實際的電子郵件地址 (我們將在下一節中取得),所以現在我們先傳回以太坊地址,並清楚地標示它不是一個電子郵件地址。
+
+```typescript
+// IdP endpoint for login requests
+idpRouter.post(`/login`,
+ async (req, res) => {
+ try {
+ // Workaround because I couldn't get parseLoginRequest to work.
+ // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
+ const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
+ res.send(getSignaturePage(samlRequest["samlp:AuthnRequest"]["@_ID"]))
+ } catch (err) {
+ console.error('Error processing SAML response:', err);
+ res.status(400).send('SAML authentication failed');
+ }
+ }
+)
+```
+
+現在在步驟 3 的處理常式中使用 `getSignaturePage` 取代 `getLoginPage`。
+
+## 取得電子郵件地址
+
+下一步是取得電子郵件地址,也就是服務提供者請求的識別碼。 為此,我們使用[以太坊證明服務 (EAS)](https://attest.org/)。
+
+取得證明最簡單的方法是使用 [GraphQL API](https://docs.attest.org/docs/developer-tools/api)。 我們使用此查詢:
+
+```
+query GetAttestationsByRecipient {
+ attestations(
+ where: {
+ recipient: { equals: "${getAddress(ethAddr)}" }
+ schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
+ }
+ take: 1
+ ) {
+ data
+ id
+ attester
+ }
+}
+```
+
+這個 [`schemaId`](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977) 只包含一個電子郵件地址。 此查詢要求此結構的證明。 證明的主體稱為「`recipient`」(接收者)。 它永遠是以太坊地址。
+
+警告:我們在此處取得證明的方式有兩個安全問題。
+
+- 我們前往的 API 端點是 `https://optimism.easscan.org/graphql`,這是一個中心化元件。 我們可以取得 `id` 屬性,然後在鏈上進行查詢以驗證證明是否真實,但 API 端點仍然可以透過不告知我們來審查證明。
+
+ 這個問題並非無法解決,我們可以執行自己的 GraphQL 端點並從鏈記錄中取得證明,但這對我們的目的來說太過繁瑣。
+
+- 我們不看證明人的身分。 任何人都可以提供我們錯誤的資訊。 在實際的實作中,我們會有一組受信任的證明人,並且只查看他們的證明。
+
+要查看此操作,請停止現有的 IdP 和 SP,並執行以下命令:
+
+```sh
+git checkout email-address
+pnpm install
+pnpm start
+```
+
+然後提供您的電子郵件地址。 您有兩種方式可以做到:
+
+- 使用私密金鑰匯入錢包,並使用測試私密金鑰 `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80`。
+
+- 為您自己的電子郵件地址新增一則證明:
+
+ 1. 在證明瀏覽器中瀏覽至[該結構](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977)。
+
+ 2. 按一下「**使用結構證明**」。
+
+ 3. 輸入您的以太坊地址作為接收者,您的電子郵件地址作為 email address,並選取**鏈上**。 然後按一下「**進行證明**」。
+
+ 4. 在您的錢包中核准交易。 您將需要在 [Optimism 區塊鏈](https://app.optimism.io/bridge/deposit) 上擁有一些 ETH 以支付 Gas。
+
+無論哪種方式,完成後請瀏覽至 [http://localhost:3000](http://localhost:3000) 並依照指示操作。 如果您匯入了測試私密金鑰,您收到的電子郵件是 `test_addr_0@example.com`。 如果您使用自己的地址,它應該是您所證明的任何內容。
+
+### 詳細說明
+
+
+
+新的步驟是 GraphQL 通訊,即步驟 5.6 和 5.7。
+
+同樣,以下是 `idp.mts` 的已變更部分。
+
+```typescript
+import { GraphQLClient } from 'graphql-request'
+import { SchemaEncoder } from '@ethereum-attestation-service/eas-sdk'
+```
+
+匯入我們需要的庫。
+
+```typescript
+const graphqlEndpointUrl = "https://optimism.easscan.org/graphql"
+```
+
+[每個區塊鏈都有一個獨立的端點](https://docs.attest.org/docs/developer-tools/api)。
+
+```typescript
+const graphqlClient = new GraphQLClient(graphqlEndpointUrl, { fetch })
+```
+
+建立一個新的 `GraphQLClient` 用戶端,可用於查詢端點。
+
+```typescript
+const graphqlSchema = 'string emailAddress'
+const graphqlEncoder = new SchemaEncoder(graphqlSchema)
+```
+
+GraphQL 只提供我們一個不透明的位元組資料物件。 若要理解它,我們需要結構。
+
+```typescript
+const ethereumAddressToEmail = async ethAddr => {
+```
+
+一個從以太坊地址取得電子郵件地址的函數。
+
+```typescript
+ const query = `
+ query GetAttestationsByRecipient {
+```
+
+這是一個 GraphQL 查詢。
+
+```typescript
+ attestations(
+```
+
+我們正在尋找證明。
+
+```typescript
+ where: {
+ recipient: { equals: "${getAddress(ethAddr)}" }
+ schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
+ }
+```
+
+我們想要的證明是我們結構中的證明,其中接收者是 `getAddress(ethAddr)`。 [`getAddress`](https://viem.sh/docs/utilities/getAddress#getaddress) 函數可確保我們的地址具有正確的[校驗和](https://github.com/ethereum/ercs/blob/master/ERCS/erc-55.md)。 這對於 GraphQL 而言是必要的,因為 GraphQL 區分大小寫。 「0xBAD060A7」、「0xBad060A7」和「0xbad060a7」是不同的值。
+
+```typescript
+ take: 1
+```
+
+無論我們找到多少則證明,我們只需要第一則。
+
+```typescript
+ ) {
+ data
+ id
+ attester
+ }
+ }`
+```
+
+我們想要接收的欄位。
+
+- `attester`:提交證明的地址。 通常這用於決定是否信任該證明。
+- `id`:證明 ID。 您可以使用此值[在鏈上讀取證明](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000021?tab=read_proxy&source_address=0x4E0275Ea5a89e7a3c1B58411379D1a0eDdc5b088#0xa3112a64)以驗證 GraphQL 查詢的資訊是否正確。
+- `data`:結構資料 (在此情況下為電子郵件地址)。
+
+```typescript
+ const queryResult = await graphqlClient.request(query)
+
+ if (queryResult.attestations.length == 0)
+ return "no_address@available.is"
+```
+
+如果沒有證明,則傳回一個明顯不正確的值,但服務提供者會認為它有效。
+
+```typescript
+ const attestationDataFields = graphqlEncoder.decodeData(queryResult.attestations[0].data)
+ return attestationDataFields[0].value.value
+}
+```
+
+如果有值,請使用 `decodeData` 解碼資料。 我們不需要它提供的中繼資料,只需要值本身。
+
+```typescript
+ const loginResponse = await idp.createLoginResponse(
+ sp,
+ {
+ .
+ .
+ .
+ },
+ "post",
+ {
+ email: await ethereumAddressToEmail(req.params.account)
+ }
+ );
+```
+
+使用新函數取得電子郵件地址。
+
+## 關於去中心化呢?
+
+在此組態中,只要我們依賴可信的證明人進行以太坊到電子郵件地址的對應,使用者就無法冒充他人。 然而,我們的身分提供者仍然是一個中心化元件。 任何擁有身分提供者私密金鑰的人都可以向服務提供者傳送虛假資訊。
+
+使用[多方運算 (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) 可能是一個解決方案。 我希望在未來的教學中寫到它。
+
+## 結論
+
+採用登入標準 (例如以太坊簽章) 會面臨雞生蛋、蛋生雞的問題。 服務提供者希望吸引盡可能廣泛的市場。 使用者希望能夠存取服務,而不用擔心支援其登入標準。
+建立適配器 (例如以太坊 IdP) 可以幫助我們克服這個障礙。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
new file mode 100644
index 00000000000..4255c9a7e52
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
@@ -0,0 +1,149 @@
+---
+title: 開始以太坊開發之旅
+description: "這是一份以太坊開發的入門指南。 我們將引導您完成建立 API 端點、發出命令列請求,到撰寫您的第一個 Web3 腳本! 無需區塊鏈開發經驗!"
+author: "Elan Halpern"
+tags: [ "javascript", "ethers.js", "節點", "諮詢", "alchemy" ]
+skill: beginner
+lang: zh-tw
+published: 2020-10-30
+source: 中
+sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f
+---
+
+
+
+這是一份以太坊開發的入門指南。 在本教學中,我們將使用 [Alchemy](https://alchemyapi.io/),這是一個領先的區塊鏈開發者平台,為 70% 的頂級區塊鏈應用程式 (包括 Maker、0x、MyEtherWallet、Dharma 和 Kyber) 的數百萬名使用者提供支援。 Alchemy 將讓我們能夠存取以太坊鏈上的 API 端點,以便我們讀取和寫入交易。
+
+我們將引導您從註冊 Alchemy 到撰寫您的第一個 Web3 腳本! 無需區塊鏈開發經驗!
+
+## 1. 註冊免費的 Alchemy 帳戶 {#sign-up-for-a-free-alchemy-account}
+
+建立 Alchemy 帳戶很簡單,[在此免費註冊](https://auth.alchemy.com/)。
+
+## 2. 建立 Alchemy 應用程式 {#create-an-alchemy-app}
+
+若要與以太坊鏈通訊並使用 Alchemy 的產品,您需要一個 API 金鑰來驗證您的請求。
+
+您可以[從儀表板建立 API 金鑰](https://dashboard.alchemy.com/)。 若要建立新的金鑰,請如下所示導覽至「Create App」:
+
+特別感謝 [_ShapeShift_](https://shapeshift.com/) _讓我們展示他們的儀表板!_
+
+
+
+在「Create App」下填寫詳細資料,即可取得新的金鑰。 您也可以在此處看到您先前建立的應用程式,以及您團隊建立的應用程式。 按一下任何應用程式的「View Key」來擷取現有的金鑰。
+
+
+
+您也可以將游標懸停在「Apps」上並選取一個應用程式,來擷取現有的 API 金鑰。 您可以在此處「View Key」(檢視金鑰) 以及「Edit App」(編輯應用程式),將特定網域加入白名單、查看多個開發者工具,以及檢視分析資料。
+
+
+
+## 3 從命令列發出請求 {#make-a-request-from-the-command-line}
+
+透過 Alchemy 使用 JSON-RPC 和 curl 與以太坊區塊鏈互動。
+
+對於手動請求,我們建議透過 `POST` 請求與 `JSON-RPC` 互動。 只需傳入 `Content-Type: application/json` 標頭,並將您的查詢作為 `POST` 主體,並包含以下欄位:
+
+- `jsonrpc`:JSON-RPC 版本—目前僅支援 `2.0`。
+- `method`:ETH API 方法。 [請參閱 API 參考資料。](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc)
+- `params`:要傳遞給方法的參數清單。
+- `id`:您請求的 ID。 回應中將會傳回此 ID,以便您追蹤哪個回應屬於哪個請求。
+
+以下是您可以從命令列執行的範例,用以擷取目前的 gas 價格:
+
+```bash
+curl https://eth-mainnet.alchemyapi.io/v2/demo \
+-X POST \
+-H "Content-Type: application/json" \
+-d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
+```
+
+_\*\*注意:\*\*將 [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) 替換為您自己的 API 金鑰 `https://eth-mainnet.alchemyapi.io/v2/**your-api-key`。_
+
+**結果:**
+
+```json
+{ "id": 73,"jsonrpc": "2.0","result": "0x09184e72a000" // 10000000000000 }
+```
+
+## 4 設定您的 Web3 用戶端 {#set-up-your-web3-client}
+
+\*\*如果您有現有的用戶端,\*\*請將您目前的節點提供者 URL 變更為帶有您 API 金鑰的 Alchemy URL:`“https://eth-mainnet.alchemyapi.io/v2/your-api-key\"`
+
+**_注意:_** 下方的腳本需要在 **節點環境** 中執行,或 **儲存在檔案中** 執行,而非從命令列執行。 如果您尚未安裝 Node 或 npm,請查看這份快速的 [mac 版設定指南](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs)。
+
+有許多 [Web3 程式庫](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries)可以與 Alchemy 整合,但我們建議使用 [Alchemy Web3](https://docs.alchemy.com/reference/api-overview),它是 web3.js 的直接替代品,其建構與設定可和 Alchemy 無縫協作。 這提供了多種優點,例如自動重試和強大的 WebSocket 支援。
+
+若要安裝 AlchemyWeb3.js,請 **導覽至您的專案目錄** 並執行:
+
+**使用 Yarn:**
+
+```
+yarn add @alch/alchemy-web3
+```
+
+**使用 NPM:**
+
+```
+npm install @alch/alchemy-web3
+```
+
+若要與 Alchemy 的節點基礎架構互動,請在 NodeJS 中執行或將此新增至 JavaScript 檔案:
+
+```js
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(
+ "https://eth-mainnet.alchemyapi.io/v2/your-api-key"
+)
+```
+
+## 5 撰寫您的第一個 Web3 腳本! {#write-your-first-web3-script}
+
+現在,讓我們來實際動手做一點 Web3 程式設計,我們將撰寫一個簡單的腳本,從以太坊主網印出最新的區塊編號。
+
+**1. 如果您尚未這麼做,請在您的終端機中建立一個新的專案目錄,並用 cd 進入該目錄:**
+
+```
+mkdir web3-example
+cd web3-example
+```
+
+**2. 如果您尚未這麼做,請將 Alchemy Web3 (或任何 Web3) 相依性安裝到您的專案中:**
+
+```
+npm install @alch/alchemy-web3
+```
+
+**3. 建立一個名為 `index.js` 的檔案,並新增以下內容:**
+
+> 最終您應該將 `demo` 替換為您的 Alchemy HTTP API 金鑰。
+
+```js
+async function main() {
+ const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+ const web3 = createAlchemyWeb3("https://eth-mainnet.alchemyapi.io/v2/demo")
+ const blockNumber = await web3.eth.getBlockNumber()
+ console.log("The latest block number is " + blockNumber)
+}
+main()
+```
+
+不熟悉非同步 (async) 相關內容? 請參閱這篇 [Medium 文章](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c)。
+
+**4. 使用 node 在您的終端機中執行它**
+
+```
+node index.js
+```
+
+**5. 您現在應該會在主控台中看到最新的區塊編號輸出!**
+
+```
+The latest block number is 11043912
+```
+
+**讚!** 恭喜! 您剛使用 Alchemy 撰寫了您的第一個 Web3 腳本 🎉\*\*
+
+不確定下一步要做什麼? 試著部署您的第一個智能合約,並在我們的 [Hello World 智能合約指南](https://www.alchemy.com/docs/hello-world-smart-contract) 中實際動手進行一些 Solidity 程式設計,或使用 [儀表板示範應用程式](https://docs.alchemyapi.io/tutorials/demo-app) 來測試您的儀表板知識!
+
+_[免費註冊 Alchemy](https://auth.alchemy.com/)、查看我們的[文件](https://www.alchemy.com/docs/),以及如需最新消息,請在 [Twitter](https://twitter.com/AlchemyPlatform) 上追蹤我們_。
diff --git a/public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md
new file mode 100644
index 00000000000..6f79b473599
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md
@@ -0,0 +1,102 @@
+---
+title: 智能合約安全工具指南
+description: 三種不同測試與程式分析技術的概觀
+author: "Trailofbits"
+lang: zh-tw
+tags: [ "穩固", "智能合約", "安全性" ]
+skill: intermediate
+published: 2020-09-07
+source: 建立安全合約
+sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis
+---
+
+我們將使用三種獨特的測試與程式分析技術:
+
+- \*\*透過 [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) 進行靜態分析。\*\*程式的所有路徑會透過不同的程式呈現方式(例如控制流程圖)同時進行近似與分析
+- \*\*透過 [Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) 進行模糊測試。\*\*程式碼會透過偽隨機產生的交易來執行。 模糊測試器會嘗試找到違反給定屬性的交易序列。
+- \*\*透過 [Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) 進行符號執行。\*\*一種正規的驗證技術,將每個執行路徑轉換成數學公式,並在其上檢查約束條件。
+
+每種技術都有其優點和缺點,在[特定情況](#determining-security-properties)下會很有用:
+
+| 技術 | 工具 | 用法 | 速度 | 遺漏的錯誤 | 誤報 |
+| ---- | --------- | --------------- | -- | ----- | -- |
+| 靜態分析 | Slither | 命令列介面與指令碼 | 秒 | 中等 | 低 |
+| 模糊測試 | Echidna | Solidity 屬性 | 分 | 低 | 無 |
+| 符號執行 | Manticore | Solidity 屬性與指令碼 | 小時 | 無\* | 無 |
+
+\* 如果所有路徑都在沒有逾時的情況下完成探索
+
+**Slither** 可在幾秒鐘內分析合約,但靜態分析可能會導致誤報,且較不適合用於複雜的檢查(例如算術檢查)。 透過應用程式介面執行 Slither,以按鈕方式存取內建的偵測器,或透過應用程式介面進行使用者定義的檢查。
+
+**Echidna** 需要運行數分鐘,且只會產生真陽性結果。 Echidna 會檢查使用者提供的、以 Solidity 編寫的安全屬性。 由於它基於隨機探索,可能會遺漏錯誤。
+
+**Manticore** 會執行「最重量級」的分析。 與 Echidna 類似,Manticore 也會驗證使用者提供的屬性。 它需要更長的運行時間,但可以證明屬性的有效性,且不會報告誤報。
+
+## 建議工作流程 {#suggested-workflow}
+
+從 Slither 的內建偵測器開始,確保目前沒有簡單的錯誤,未來也不會引入。 使用 Slither 檢查與繼承、變數相依性和結構性問題相關的屬性。 隨著程式碼庫的增長,使用 Echidna 測試狀態機更複雜的屬性。 再次使用 Slither 開發自訂檢查,以提供 Solidity 中沒有的保護措施,例如防止函式被覆寫。 最後,使用 Manticore 對關鍵安全屬性(例如算術運算)執行有針對性的驗證。
+
+- 使用 Slither 的命令列介面來捕捉常見問題
+- 使用 Echidna 測試合約的高階安全屬性
+- 使用 Slither 編寫自訂的靜態檢查
+- 當您想要對關鍵安全屬性進行深度保證時,請使用 Manticore
+
+**關於單元測試的說明**。 單元測試是建立高品質軟體的必要條件。 然而,這些技術並非最適合用來發現安全漏洞。 它們通常用於測試程式碼的正面行為(即程式碼在正常情況下如預期般運作),而安全漏洞則傾向於存在於開發者未曾考慮到的邊際情況。 在我們對數十個智能合約安全審查的研究中,我們在客戶的程式碼中發現,[單元測試覆蓋率對安全漏洞的數量或嚴重性沒有影響](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/)。
+
+## 確定安全屬性 {#determining-security-properties}
+
+為了有效地測試和驗證您的程式碼,您必須找出需要注意的區域。 由於您在安全性上投入的資源有限,確定您程式碼庫中較弱或高價值的部分,對於優化您的投入非常重要。 威脅模型可以提供幫助。 請考慮審查:
+
+- [快速風險評估](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html)(時間緊迫時我們的首選方法)
+- [以資料為中心的系統威脅模型指南](https://csrc.nist.gov/pubs/sp/800/154/ipd) (又名 NIST 800-154)
+- [Shostack 威脅模型](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998)
+- [STRIDE](https://wikipedia.org/wiki/STRIDE_\(security\)) / [DREAD](https://wikipedia.org/wiki/DREAD_\(risk_assessment_model\))
+- [PASTA](https://wikipedia.org/wiki/Threat_model#P.A.S.T.A.)
+- [斷言的使用](https://blog.regehr.org/archives/1091)
+
+### 元件 {#components}
+
+了解您想檢查的內容,也有助於您選擇正確的工具。
+
+與智能合約經常相關的廣泛領域包括:
+
+- \*\*狀態機。\*\*大多數合約都可以表示為狀態機。 考慮檢查 (1) 無法達到任何無效狀態,(2) 如果一個狀態是有效的,那麼它可以被達到,以及 (3) 沒有任何狀態會讓合約陷入陷阱。
+
+ - Echidna 和 Manticore 是測試狀態機規格的首選工具。
+
+- \*\*存取控制。\*\*如果您的系統有特權使用者(例如擁有者、控制者等) 您必須確保 (1) 每個使用者只能執行授權的動作,以及 (2) 沒有使用者可以阻止更具特權的使用者執行動作。
+
+ - Slither、Echidna 和 Manticore 可以檢查存取控制的正確性。 例如,Slither 可以檢查是否只有列入白名單的函式缺少 `onlyOwner` 修飾符。 Echidna 和 Manticore 對於更複雜的存取控制很有用,例如只有在合約達到給定狀態時才授予權限。
+
+- \*\*算術運算。\*\*檢查算術運算的健全性至關重要。 在各處使用 `SafeMath` 是防止溢出/下溢的好方法,但您仍需考慮其他算術缺陷,包括捨入問題和會讓合約陷入陷阱的缺陷。
+
+ - Manticore 是這裡的最佳選擇。 如果算術超出 SMT 求解器的範圍,可以使用 Echidna。
+
+- \*\*繼承正確性。\*\*Solidity 合約高度依賴多重繼承。 很容易會出現錯誤,例如遮蔽函式缺少 `super` 呼叫,以及對 C3 線性化順序的誤解。
+
+ - Slither 是確保偵測到這些問題的工具。
+
+- \*\*外部互動。\*\*合約會彼此互動,而某些外部合約不應被信任。 例如,如果您的合約依賴外部預言機,當一半可用的預言機遭到入侵時,它還能保持安全嗎?
+
+ - Manticore 和 Echidna 是測試您的合約與外部互動的最佳選擇。 Manticore 有內建機制來模擬外部合約。
+
+- \*\*標準符合性。\*\*以太坊標準(例如 ERC20)的設計歷史上曾出現過瑕疵。 請注意您所依據的標準的限制。
+ - Slither、Echidna 和 Manticore 將幫助您偵測與給定標準的偏差。
+
+### 工具選擇快捷手冊 {#tool-selection-cheatsheet}
+
+| 元件 | 工具 | 範例 |
+| ----- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 狀態機 | Echidna、Manticore | |
+| 存取控制 | Slither、Echidna、Manticore | [Slither 練習 2](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md)、[Echidna 練習 2](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) |
+| 算術運算 | Manticore、Echidna | [Echidna 練習 1](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md)、[Manticore 練習 1 - 3](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) |
+| 繼承正確性 | Slither | [Slither 練習 1](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) |
+| 外部互動 | Manticore、Echidna | |
+| 標準符合性 | Slither、Echidna、Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) |
+
+根據您的目標,可能還需要檢查其他領域,但這些粗略的重點領域對於任何智能合約系統來說都是一個好的開始。
+
+我們的公開審計報告中包含了經過驗證或測試的屬性範例。 請考慮閱讀以下報告的「自動化測試與驗證」部分,以審查真實世界的安全屬性:
+
+- [0x](https://github.com/trailofbits/publications/blob/master/reviews/0x-protocol.pdf)
+- [Balancer](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf)
diff --git a/public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract-fullstack/index.md
new file mode 100644
index 00000000000..33fae9ea9e2
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract-fullstack/index.md
@@ -0,0 +1,1539 @@
+---
+title: 給初學者的 Hello World 智慧型合約 - 全端
+description: 在以太坊上撰寫和部署簡單智能合約的入門教學。
+author: "nstrike2"
+tags:
+ [
+ "穩固",
+ "hardhat",
+ "alchemy",
+ "智能合約",
+ "部署",
+ "區塊瀏覽器",
+ "前端",
+ "交易"
+ ]
+skill: beginner
+lang: zh-tw
+published: 2021-10-25
+---
+
+如果您是區塊鏈開發新手,不知道從何開始,或不知道如何部署智慧型合約並與之互動,本指南就是為您準備的。 我們將逐步說明如何使用 [MetaMask](https://metamask.io)、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org) 和 [Alchemy](https://alchemy.com/eth),在 Goerli 測試網上建立並部署一個簡單的智慧型合約。
+
+您需要一個 Alchemy 帳戶才能完成本教學。 [註冊免費帳戶](https://www.alchemy.com/)
+
+如果您在任何時候有任何疑問,歡迎隨時到 [Alchemy Discord](https://discord.gg/gWuC7zB) 提問!
+
+## 第一部分 - 使用 Hardhat 建立與部署您的智慧型合約 {#part-1}
+
+### 連線至以太坊網路 {#connect-to-the-ethereum-network}
+
+向以太坊鏈發出請求有很多種方式。 為求簡單,我們將使用 Alchemy 上的免費帳戶。Alchemy 是一個區塊鏈開發者平台及 API,讓我們無須自行執行節點就能與以太坊鏈通訊。 Alchemy 也有用於監控和分析的開發者工具;我們將在本教學中利用這些工具來了解我們智慧型合約部署的底層運作情況。
+
+### 建立您的應用程式和 API 金鑰 {#create-your-app-and-api-key}
+
+建立 Alchemy 帳戶後,您可以透過建立應用程式來產生 API 金鑰。 這將允許您向 Goerli 測試網發出請求。 如果您不熟悉測試網,可以閱讀 [Alchemy 選擇網路的指南](https://www.alchemy.com/docs/choosing-a-web3-network)。
+
+在 Alchemy 儀表板上,於導覽列中找到 **Apps** 下拉式選單,然後點擊 **Create App**。
+
+
+
+將您的應用程式命名為「_Hello World_」,並寫下簡短描述。 選擇 **Staging** 作為您的環境,**Goerli** 作為您的網路。
+
+
+
+_注意:請務必選擇 **Goerli**,否則本教學將無法運作。_
+
+點擊 **Create app**。 您的應用程式將出現在下方的表格中。
+
+### 建立一個以太坊帳戶 {#create-an-ethereum-account}
+
+您需要一個以太坊帳戶來傳送和接收交易。 我們將使用 MetaMask,這是一款瀏覽器內的虛擬錢包,可讓使用者管理其以太坊帳戶地址。
+
+您可以在[這裡](https://metamask.io/download)免費下載並建立 MetaMask 帳戶。 在建立帳戶時,或如果您已有帳戶,請確保切換到右上角的「Goerli 測試網」(這樣我們就不會處理真實貨幣)。
+
+### 第 4 步:從水龍頭取得以太幣 {#step-4-add-ether-from-a-faucet}
+
+要將您的智慧型合約部署到測試網,您會需要一些假的 ETH。 要在 Goerli 網路上取得 ETH,請前往 Goerli 水龍頭,並輸入您的 Goerli 帳戶地址。 請注意,Goerli 水龍頭最近可能有點不穩定 - 請參閱[測試網頁面](/developers/docs/networks/#goerli),查看可嘗試的選項清單:
+
+_注意:由於網路壅塞,這可能需要一些時間。_
+\`\`
+
+### 步驟 5:檢查您的餘額 {#step-5-check-your-balance}
+
+為了再次確認 ETH 已在您的錢包中,讓我們使用 [Alchemy 的編寫工具](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) 發出 [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) 請求。 這將會回傳你的錢包裡的餘額。 要了解更多資訊,請查看 [Alchemy 關於如何使用編寫工具的簡短教學](https://youtu.be/r6sjRxBZJuU)。
+
+輸入您的 MetaMask 帳戶地址,然後點擊 **Send Request**。 您將會看到類似下方程式碼片段的回應。
+
+```json
+{ "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" }
+```
+
+> _注意:此結果以 wei 為單位,而非 ETH。_ Wei 是以太幣的最小單位。_
+
+哈! 我們的假錢都在這。
+
+### 步驟 6:初始化我們的專案 {#step-6-initialize-our-project}
+
+首先,我們需要為我們的專案建立一個資料夾。 導覽至您的命令列並輸入以下內容。
+
+```
+mkdir hello-world
+cd hello-world
+```
+
+現在我們在專案資料夾中了,我們將使用 `npm init` 來初始化專案。
+
+> 如果您尚未安裝 npm,請遵循[這些說明來安裝 Node.js 和 npm](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm)。
+
+就本教學而言,您如何回答初始化問題並不重要。 以下是我們的做法,僅供參考:
+
+```
+套件名稱:(hello-world)
+版本:(1.0.0)
+描述:hello world 智慧型合約
+進入點:(index.js)
+測試指令:
+git 儲存庫:
+關鍵字:
+作者:
+授權:(ISC)
+
+即將寫入 /Users/.../.../.../hello-world/package.json:
+
+{
+ "name": "hello-world",
+ "version": "1.0.0",
+ "description": "hello world 智慧型合約",
+ "main": "index.js",
+ "scripts": {
+ "test": "echo \"Error: no test specified\" && exit 1"
+ },
+ "author": "",
+ "license": "ISC"
+}
+```
+
+核准 package.json,我們就可以開始了!
+
+### 步驟 7:下載 Hardhat {#step-7-download-hardhat}
+
+Hardhat 是一個開發環境,提供你去編譯、部屬、測試、以及除錯你的以太坊軟體。 它能協助開發人員在部署至即時鏈之前,於本機建立智慧合約和去中心化應用程式。
+
+在我們的 `hello-world` 專案中執行:
+
+```
+npm install --save-dev hardhat
+```
+
+如需更多[安裝指示](https://hardhat.org/getting-started/#overview)的詳細資訊,請查看此頁面。
+
+### 步驟 8:建立 Hardhat 專案 {#step-8-create-hardhat-project}
+
+在我們的 `hello-world` 專案資料夾中,執行:
+
+```
+npx hardhat
+```
+
+你接下來會看到歡迎訊息以及關於你想做什麼的選項。 選擇"create an empty hardhat.config.js":
+
+```
+888 888 888 888 888
+888 888 888 888 888
+888 888 888 888 888
+8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888
+888 888 "88b 888P" d88" 888 888 "88b "88b 888
+888 888 .d888888 888 888 888 888 888 .d888888 888
+888 888 888 888 888 Y88b 888 888 888 888 888 Y88b.
+888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888
+
+👷 歡迎使用 Hardhat v2.0.11 👷
+
+您想做什麼?…
+建立範例專案
+❯ 建立一個空的 hardhat.config.js
+退出
+```
+
+這將在專案中產生一個 `hardhat.config.js` 檔案。 我們稍後將在本教學中使用此檔案來指定專案的設定。
+
+### 步驟 9:新增專案資料夾 {#step-9-add-project-folders}
+
+為了讓專案保持井然有序,我們來建立兩個新資料夾。 在命令列中,導覽至 `hello-world` 專案的根目錄並輸入:
+
+```
+mkdir contracts
+mkdir scripts
+```
+
+- `contracts/` 是我們存放 hello world 智能合約程式碼檔案的地方
+- `scripts/` 是我們存放部署和與合約互動的腳本的地方
+
+### 步驟 10:編寫我們的合約 {#step-10-write-our-contract}
+
+您可能會問自己,我們什麼時候才要開始寫程式碼? 就是現在!
+
+在您喜歡的編輯器中開啟 hello-world 專案。 智慧型合約最常用 Solidity 編寫,我們將使用它來編寫我們的智慧型合約。
+
+1. 導覽至 `contracts` 資料夾並建立一個名為 `HelloWorld.sol` 的新檔案
+2. 以下是我們將在本教學中使用的範例 Hello World 智慧型合約。 將以下內容複製到 `HelloWorld.sol` 檔案中。
+
+_注意:請務必閱讀註解以了解此合約的功能。_
+
+```
+// 指定 Solidity 的版本,使用語意化版本控制。
+// 了解更多:https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+pragma solidity >=0.7.3;
+
+// 定義一個名為「HelloWorld」的合約。
+// 合約是函式和資料 (其狀態) 的集合。部署後,合約會存放在以太坊區塊鏈的特定地址上。了解更多:https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
+contract HelloWorld {
+
+ // 呼叫更新函式時發出
+ // 智慧型合約事件是您合約的一種方式,可將區塊鏈上發生的事情傳達給您的應用程式前端,前端可以「監聽」某些事件並在事件發生時採取行動。
+ event UpdatedMessages(string oldStr, string newStr);
+
+ // 宣告一個「string」類型的狀態變數「message」。
+ // 狀態變數是其值永久儲存在合約儲存空間中的變數。關鍵字「public」可讓變數從合約外部存取,並建立一個其他合約或用戶端可呼叫以存取該值的函式。
+ string public message;
+
+ // 與許多以類別為基礎的物件導向語言相似,建構函式是一個特殊函式,只在合約建立時執行。
+ // 建構函式用於初始化合約的資料。了解更多:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
+ constructor(string memory initMessage) {
+
+ // 接受一個字串引數「initMessage」,並將該值設定到合約的「message」儲存變數中)。
+ message = initMessage;
+ }
+
+ // 一個公共函式,接受一個字串引數並更新「message」儲存變數。
+ function update(string memory newMessage) public {
+ string memory oldMsg = message;
+ message = newMessage;
+ emit UpdatedMessages(oldMsg, newMessage);
+ }
+}
+```
+
+這是一個基本的智慧型合約,在建立時儲存一則訊息。 可以透過呼叫 `update` 函式來更新。
+
+### 步驟 11:將 MetaMask 和 Alchemy 連線至您的專案 {#step-11-connect-metamask-alchemy-to-your-project}
+
+我們已經建立了 MetaMask 錢包、Alchemy 帳戶,並編寫了我們的智能合約,現在是時候將這三者連接起來了。
+
+從您的錢包傳送的每筆交易都需要使用您唯一的私密金鑰簽署。 為了向我們的程式提供此權限,我們可以安全地將我們的私密金鑰儲存在環境檔案中。 我們也將在此處儲存 Alchemy 的 API 金鑰。
+
+> 若要深入了解如何傳送交易,請查看這篇關於使用 web3 傳送交易的[教學](https://www.alchemy.com/docs/hello-world-smart-contract#step-11-connect-metamask--alchemy-to-your-project)。
+
+首先,安裝 dotenv 套件。
+
+```
+npm install dotenv --save
+```
+
+然後,在專案的根目錄中建立一個 `.env` 檔案。 將您的 MetaMask 私密金鑰和 HTTP Alchemy API URL 新增至其中。
+
+您的環境檔案必須命名為 `.env`,否則它將不會被辨識為環境檔案。
+
+請勿將其命名為 `process.env`、`.env-custom` 或任何其他名稱。
+
+- 請遵循[這些說明](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)來匯出您的私密金鑰
+- 請參閱下文以取得 HTTP Alchemy API URL
+
+
+
+你的 `.env` 應該看起來像這樣:
+
+```
+API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key"
+PRIVATE_KEY = "your-metamask-private-key"
+```
+
+為了實際將這些連接到我們的程式碼,我們將在第 13 步的 `hardhat.config.js` 檔案中引用這些變數。
+
+### 第 12 步:安裝 Ethers.js {#step-12-install-ethersjs}
+
+Ethers.js 是一個函式庫,它透過將[標準 JSON-RPC 方法](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc)包裝成更方便使用者使用的方法,讓與以太坊的互動和請求變得更容易。
+
+Hardhat 可讓您整合[外掛程式](https://hardhat.org/plugins/)以取得額外的工具和擴充功能。 我們將利用 [Ethers 外掛程式](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers)來部署合約。
+
+在你的專案目錄輸入:
+
+```bash
+npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0"
+```
+
+### 步驟 13:更新 hardhat.config.js {#step-13-update-hardhat-configjs}
+
+我們目前已經新增了幾個相依套件和外掛程式,現在我們需要更新 `hardhat.config.js`,讓我們的專案知道它們全部。
+
+將你的 `hardhat.config.js` 更新成如下所示:
+
+```javascript
+/**
+ * @type import('hardhat/config').HardhatUserConfig
+ */
+
+require("dotenv").config()
+require("@nomiclabs/hardhat-ethers")
+
+const { API_URL, PRIVATE_KEY } = process.env
+
+module.exports = {
+ solidity: "0.7.3",
+ defaultNetwork: "goerli",
+ networks: {
+ hardhat: {},
+ goerli: {
+ url: API_URL,
+ accounts: [`0x${PRIVATE_KEY}`],
+ },
+ },
+}
+```
+
+### 步驟 14:編譯我們的合約 {#step-14-compile-our-contract}
+
+為了確認一切運作正常,我們來編譯合約。 `compile` 任務是內建的 hardhat 任務之一。
+
+在命令列工具輸入:
+
+```bash
+npx hardhat compile
+```
+
+您可能會收到關於「原始程式檔中未提供 SPDX 授權識別碼」的警告,但無須擔心,希望其他一切都沒問題! 如果沒有,您隨時可以在 [Alchemy discord](https://discord.gg/u72VCg3) 中傳送訊息。
+
+### 步驟 15:編寫我們的部署指令碼 {#step-15-write-our-deploy-script}
+
+現在我們已經寫好了合約,並且也搞定配置檔案。現在我們該來撰寫部署合約的腳本。
+
+導覽至 `scripts/` 資料夾並建立一個名為 `deploy.js` 的新檔案,將以下內容加入其中:
+
+```javascript
+async function main() {
+ const HelloWorld = await ethers.getContractFactory("HelloWorld")
+
+ // 開始部署,回傳一個解析為合約物件的 promise
+ const hello_world = await HelloWorld.deploy("Hello World!")
+ console.log("合約已部署至地址:", hello_world.address)
+}
+
+main()
+ .then(() => process.exit(0))
+ .catch((error) => {
+ console.error(error)
+ process.exit(1)
+ })
+```
+
+Hardhat 在其[合約教學文章](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)中詳細地解釋了每一行程式碼的作用,我們在此採用了他們的解釋。
+
+```javascript
+const HelloWorld = await ethers.getContractFactory("HelloWorld")
+```
+
+ethers.js 中的 `ContractFactory` 是用於部署新智慧型合約的抽象概念,因此這裡的 `HelloWorld` 是我們 hello world 合約執行個體的[工廠](https://en.wikipedia.org/wiki/Factory_\(object-oriented_programming\))。 使用 `hardhat-ethers` 外掛程式時,`ContractFactory` 和 `Contract` 執行個體預設會連線至第一個簽署者 (擁有者)。
+
+```javascript
+const hello_world = await HelloWorld.deploy()
+```
+
+在 `ContractFactory` 上呼叫 `deploy()` 將會開始部署,並回傳一個解析為 `Contract` 物件的 `Promise`。 這就是和我們的智慧型合約函數有一對一的方法的物件。
+
+### 第 16 步:部署我們的合約 {#step-16-deploy-our-contract}
+
+我們終於準備好要部署合約了! 導覽至命令列並執行:
+
+```bash
+npx hardhat run scripts/deploy.js --network goerli
+```
+
+你會看到像這樣的輸出:
+
+```bash
+合約已部署至地址:0x6cd7d44516a20882cEa2DE9f205bF401c0d23570
+```
+
+**請儲存此地址**。 我們稍後將在本教學中使用它。
+
+如果我們前往 [Goerli etherscan](https://goerli.etherscan.io) 並搜尋我們的合約地址,我們應該能夠看到它已成功部署。 這個交易執行看起來會像這樣:
+
+
+
+`From` 地址應與您的 MetaMask 帳戶地址相符,而 `To` 地址將顯示 **Contract Creation**。 如果我們點擊進入交易,我們將在 `To` 欄位中看到我們的合約地址。
+
+
+
+恭喜! 您剛剛將智慧型合約部署到以太坊測試網。
+
+若要了解底層的運作情況,讓我們導覽至 [Alchemy 儀表板](https://dashboard.alchemy.com/explorer)中的 Explorer 標籤。 如果您有多個 Alchemy 應用程式,請務必依應用程式篩選並選取 **Hello World**。
+
+
+
+在這裡您會看到當我們呼叫 `.deploy()` 函式時,Hardhat/Ethers 在幕後為我們進行的一些 JSON-RPC 方法。 這裡有兩個重要的方法:[`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) (這是將我們的合約寫入 Goerli 鏈的請求),以及 [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash) (這是在給定哈希值的情況下,讀取我們交易資訊的請求)。 若要深入了解如何傳送交易,請查看[我們關於使用 Web3 傳送交易的教學](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)。
+
+## 第二部分:與您的智慧型合約互動 {#part-2-interact-with-your-smart-contract}
+
+既然我們已成功將智慧型合約部署至 Goerli 網路,讓我們來學習如何與它互動。
+
+### 建立一個 interact.js 檔案 {#create-a-interactjs-file}
+
+這就是我們將編寫互動腳本的檔案。 我們將使用您先前在第一部分中安裝的 Ethers.js 函式庫。
+
+在 `scripts/` 資料夾中,建立一個名為 `interact.js` 的新檔案,並新增以下程式碼:
+
+```javascript
+// interact.js
+
+const API_KEY = process.env.API_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS
+```
+
+### 更新您的 .env 檔案 {#update-your-env-file}
+
+我們將使用新的環境變數,因此我們需要在[先前建立](#step-11-connect-metamask-&-alchemy-to-your-project) 的 `.env` 檔案中定義它們。
+
+我們需要新增我們的 Alchemy `API_KEY` 和部署智慧型合約的 `CONTRACT_ADDRESS` 的定義。
+
+您的 `.env` 檔案應如下所示:
+
+```bash
+# .env
+
+API_URL = "https://eth-goerli.alchemyapi.io/v2/"
+API_KEY = ""
+PRIVATE_KEY = ""
+CONTRACT_ADDRESS = "0x"
+```
+
+### 取得您的合約 ABI {#grab-your-contract-ABI}
+
+我們的合約 [ABI (應用程式二進位介面)](/glossary/#abi) 是與我們的智慧型合約互動的介面。 Hardhat 會自動產生 ABI 並將其儲存在 `HelloWorld.json` 中。 若要使用 ABI,我們需要透過將以下程式碼行新增至我們的 `interact.js` 檔案來解析內容:
+
+```javascript
+// interact.js
+const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json")
+```
+
+如果您想查看 ABI,可以將其輸出到您的主控台:
+
+```javascript
+console.log(JSON.stringify(contract.abi))
+```
+
+若要查看您的 ABI 列印至主控台,請導覽至您的終端機並執行:
+
+```bash
+npx hardhat run scripts/interact.js
+```
+
+### 建立您的合約執行個體 {#create-an-instance-of-your-contract}
+
+若要與我們的合約互動,我們需要在我們的程式碼中建立一個合約執行個體。 若要使用 Ethers.js 執行此操作,我們需要處理三個概念:
+
+1. 提供者 - 一個節點提供者,提供您對區塊鏈的讀寫存取權
+2. 簽署者 - 代表一個可以簽署交易的以太坊帳戶
+3. 合約 - 代表部署在鏈上特定合約的 Ethers.js 物件
+
+我們將使用上一步的合約 ABI 來建立我們的合約執行個體:
+
+```javascript
+// interact.js
+
+// Provider
+const alchemyProvider = new ethers.providers.AlchemyProvider(
+ (network = "goerli"),
+ API_KEY
+)
+
+// Signer
+const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider)
+
+// Contract
+const helloWorldContract = new ethers.Contract(
+ CONTRACT_ADDRESS,
+ contract.abi,
+ signer
+)
+```
+
+在 [ethers.js 文件](https://docs.ethers.io/v5/) 中深入了解提供者、簽署者和合約。
+
+### 讀取初始訊息 {#read-the-init-message}
+
+還記得我們在部署合約時設定了 `initMessage = "Hello world!"` 嗎? 我們現在要讀取儲存在我們智慧型合約中的那則訊息,並將它列印到主控台。
+
+在 JavaScript 中,與網路互動時會使用非同步函式。 要深入了解非同步函式,請[閱讀這篇 Medium 文章](https://blog.bitsrc.io/understanding-asynchronous-javascript-the-event-loop-74cd408419ff)。
+
+使用以下程式碼呼叫我們智慧型合約中的 `message` 函式並讀取初始訊息:
+
+```javascript
+// interact.js
+
+// ...
+
+async function main() {
+ const message = await helloWorldContract.message()
+ console.log("訊息是:" + message)
+}
+main()
+```
+
+在終端機中使用 `npx hardhat run scripts/interact.js` 執行檔案後,我們應該會看到以下回應:
+
+```
+訊息是:Hello world!
+```
+
+恭喜! 您剛剛成功地從以太坊區塊鏈讀取智慧型合約資料,太棒了!
+
+### 更新訊息 {#update-the-message}
+
+除了只讀取訊息,我們還可以使用 `update` 函式來更新儲存在我們智慧型合約中的訊息! 很酷,對吧?
+
+若要更新訊息,我們可以直接在我們實例化的合約物件上呼叫 `update` 函式:
+
+```javascript
+// interact.js
+
+// ...
+
+async function main() {
+ const message = await helloWorldContract.message()
+ console.log("訊息是:" + message)
+
+ console.log("正在更新訊息...")
+ const tx = await helloWorldContract.update("這是新訊息。")
+ await tx.wait()
+}
+main()
+```
+
+請注意,在第 11 行,我們在回傳的交易物件上呼叫了 `.wait()`。 這可確保我們的腳本在結束函式前,會等待交易在區塊鏈上被挖出。 如果未包含 `.wait()` 呼叫,腳本可能無法看到合約中更新的 `message` 值。
+
+### 讀取新訊息 {#read-the-new-message}
+
+您應該能夠重複[上一步](#read-the-init-message)來讀取更新的 `message` 值。 花點時間看看您是否能做出必要的變更來列印出那個新值!
+
+如果您需要提示,以下是您此時的 `interact.js` 檔案應有的樣子:
+
+```javascript
+// interact.js
+
+const API_KEY = process.env.API_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS
+
+const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json")
+
+// 提供者 - Alchemy
+const alchemyProvider = new ethers.providers.AlchemyProvider(
+ (network = "goerli"),
+ API_KEY
+)
+
+// 簽署者 - 您
+const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider)
+
+// 合約執行個體
+const helloWorldContract = new ethers.Contract(
+ CONTRACT_ADDRESS,
+ contract.abi,
+ signer
+)
+
+async function main() {
+ const message = await helloWorldContract.message()
+ console.log("訊息是:" + message)
+
+ console.log("正在更新訊息...")
+ const tx = await helloWorldContract.update("這是新訊息")
+ await tx.wait()
+
+ const newMessage = await helloWorldContract.message()
+ console.log("新訊息是:" + newMessage)
+}
+
+main()
+```
+
+現在只要執行腳本,您就應該能看到舊訊息、更新狀態,以及新訊息列印到您的終端機上!
+
+`npx hardhat run scripts/interact.js --network goerli`
+
+```
+訊息是:Hello World!
+正在更新訊息...
+新訊息是:這是新訊息。
+```
+
+執行該腳本時,您可能會注意到「正在更新訊息...」步驟在新訊息載入前需要一些時間。 這是由於挖礦過程所致;如果您好奇在挖礦時追蹤交易,請造訪 [Alchemy 記憶體池](https://dashboard.alchemyapi.io/mempool)來查看交易狀態。 如果交易被丟棄,檢查 [Goerli Etherscan](https://goerli.etherscan.io) 並搜尋您的交易哈希也很有幫助。
+
+## 第三部分:將您的智慧型合約發布至 Etherscan {#part-3-publish-your-smart-contract-to-etherscan}
+
+您已費盡心力讓您的智慧型合約活起來;現在是時候與全世界分享它了!
+
+透過在 Etherscan 上驗證您的智慧型合約,任何人都可以檢視您的原始碼並與您的智慧型合約互動。 我們開始吧!
+
+### 步驟 1:在您的 Etherscan 帳戶上產生 API 金鑰 {#step-1-generate-an-api-key-on-your-etherscan-account}
+
+需要 Etherscan API 金鑰來驗證您擁有您嘗試發布的智慧型合約。
+
+如果您還沒有 Etherscan 帳戶,請[註冊一個帳戶](https://etherscan.io/register)。
+
+登入後,在導覽列中找到您的使用者名稱,將滑鼠懸停在其上並選取 **My profile** 按鈕。
+
+在您的個人資料頁面上,您應該會看到一個側邊導覽列。 從側邊導覽列中,選取 **API Keys**。 接下來,按下「新增」按鈕以建立新的 API 金鑰,將您的應用程式命名為 **hello-world** 並按下 **Create New API Key** 按鈕。
+
+您的新 API 金鑰應會出現在 API 金鑰表格中。 將 API 金鑰複製到您的剪貼簿。
+
+接下來,我們需要將 Etherscan API 金鑰新增至我們的 `.env` 檔案。
+
+新增後,您的 `.env` 檔案應如下所示:
+
+```javascript
+API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key"
+PUBLIC_KEY = "your-public-account-address"
+PRIVATE_KEY = "your-private-account-address"
+CONTRACT_ADDRESS = "your-contract-address"
+ETHERSCAN_API_KEY = "your-etherscan-key"
+```
+
+### Hardhat 部署的智慧型合約 {#hardhat-deployed-smart-contracts}
+
+#### 安裝 hardhat-etherscan {#install-hardhat-etherscan}
+
+使用 Hardhat 將您的合約發布至 Etherscan 非常簡單。 您首先需要安裝 `hardhat-etherscan` 外掛程式才能開始。 `hardhat-etherscan` 會自動在 Etherscan 上驗證智慧型合約的原始碼和 ABI。 若要新增此項,請在 `hello-world` 目錄中執行:
+
+```text
+npm install --save-dev @nomiclabs/hardhat-etherscan
+```
+
+安裝後,在您的 `hardhat.config.js` 頂端包含以下陳述式,並新增 Etherscan 設定選項:
+
+```javascript
+// hardhat.config.js
+
+require("dotenv").config()
+require("@nomiclabs/hardhat-ethers")
+require("@nomiclabs/hardhat-etherscan")
+
+const { API_URL, PRIVATE_KEY, ETHERSCAN_API_KEY } = process.env
+
+module.exports = {
+ solidity: "0.7.3",
+ defaultNetwork: "goerli",
+ networks: {
+ hardhat: {},
+ goerli: {
+ url: API_URL,
+ accounts: [`0x${PRIVATE_KEY}`],
+ },
+ },
+ etherscan: {
+ // Your API key for Etherscan
+ // 在 https://etherscan.io/ 取得一個
+ apiKey: ETHERSCAN_API_KEY,
+ },
+}
+```
+
+#### 在 Etherscan 上驗證您的智慧型合約 {#verify-your-smart-contract-on-etherscan}
+
+確保所有檔案都已儲存,且所有 `.env` 變數都已正確設定。
+
+執行 `verify` 任務,傳遞合約地址以及部署到的網路:
+
+```text
+npx hardhat verify --network goerli DEPLOYED_CONTRACT_ADDRESS 'Hello World!'
+```
+
+請確定 `DEPLOYED_CONTRACT_ADDRESS` 是您在 Goerli 測試網上部署的智慧型合約的地址。 此外,最後一個引數 (`'Hello World!'`) 必須與[第一部分中的部署步驟](#write-our-deploy-script)中所使用的字串值相同。
+
+如果一切順利,您將在終端機中看到以下訊息:
+
+```text
+Successfully submitted source code for contract
+contracts/HelloWorld.sol:HelloWorld at 0xdeployed-contract-address
+for verification on Etherscan. Waiting for verification result...
+
+
+Successfully verified contract HelloWorld on Etherscan.
+https://goerli.etherscan.io/address/#contracts
+```
+
+恭喜! 您的智慧型合約程式碼已在 Etherscan 上!
+
+### 在 Etherscan 上查看您的智慧型合約! {#check-out-your-smart-contract-on-etherscan}
+
+當您導覽至終端機中提供的連結時,您應該能夠看到您在 Etherscan 上發布的智慧型合約程式碼和 ABI!
+
+**哇嗚 - 你做到了,冠軍! 現在任何人都可以呼叫或寫入您的智慧型合約! 我們迫不及待想看看您接下來會打造出什麼!**
+
+## 第四部分 - 將您的智慧型合約與前端整合 {#part-4-integrating-your-smart-contract-with-the-frontend}
+
+完成本教學後,您將知道如何:
+
+- 將 MetaMask 錢包連線至您的去中心化應用程式
+- 使用 [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) API 從您的智慧型合約讀取資料
+- 使用 MetaMask 簽署以太坊交易
+
+對於這個去中心化應用程式,我們將使用 [React](https://react.dev/) 作為我們的前端框架;然而,需要注意的是,我們不會花太多時間分解其基礎知識,因為我們將主要專注於為我們的專案帶來 Web3 功能。
+
+作為先決條件,您應該對 React 有初學者級的了解。 如果沒有,我們建議完成官方的[React 入門教學](https://react.dev/learn)。
+
+### 複製入門檔案 {#clone-the-starter-files}
+
+首先,前往 [hello-world-part-four GitHub 儲存庫](https://github.com/alchemyplatform/hello-world-part-four-tutorial) 以取得此專案的入門檔案,並將此儲存庫複製到您的本機電腦。
+
+在本機開啟複製的儲存庫。 請注意,它包含兩個資料夾:`starter-files` 和 `completed`。
+
+- `starter-files` - **我們將在此目錄中工作**,我們將把 UI 連線至您的以太坊錢包和我們在[第三部分](#part-3)中發布到 Etherscan 的智慧型合約。
+- `completed` 包含整個已完成的教學,如果您遇到困難,應僅用作參考。
+
+接下來,在您最喜歡的程式碼編輯器中開啟您的 `starter-files` 副本,然後導覽至 `src` 資料夾。
+
+我們將撰寫的所有程式碼都會放在 `src` 資料夾底下。 我們將編輯 `HelloWorld.js` 元件和 `util/interact.js` JavaScript 檔案,為我們的專案提供 Web3 功能。
+
+### 查看入門檔案 {#check-out-the-starter-files}
+
+在我們開始編寫程式碼之前,讓我們來探索一下入門檔案中提供了什麼。
+
+#### 讓你的 React 專案動起來 {#get-your-react-project-running}
+
+讓我們透過在我們的瀏覽器內運行這個「反應」專案來開始是日的教程吧: 「反應」的美在於一旦我們在瀏覽器內已經有在運行自己的專案,我們儲存下來的任何改變都將會被實時更新到我們的瀏覽器裡。
+
+若要讓專案執行,請導覽至 `starter-files` 資料夾的根目錄,然後在您的終端機中執行 `npm install` 以安裝專案的相依性:
+
+```bash
+cd starter-files
+npm install
+```
+
+安裝完成後,在你的終端機中執行 `npm start`:
+
+```bash
+npm start
+```
+
+這麼做應該會在您的瀏覽器中開啟 [http://localhost:3000/](http://localhost:3000/),您將在那裡看到我們專案的前端。 它應該包含一個欄位 (一個更新儲存在您智慧型合約中訊息的地方)、一個「連線錢包」按鈕,和一個「更新」按鈕。
+
+如果您嘗試點擊任一按鈕,您會發現它們無法運作——那是因為我們還需要編寫它們的功能。
+
+#### `HelloWorld.js` 元件 {#the-helloworld-js-component}
+
+讓我們回到編輯器中的 `src` 資料夾,並開啟 `HelloWorld.js` 檔案。 這個動作在我們理解該檔案內所有東西上有著超級關鍵的作用,因為它是我們將會首先處理的第一個「反應」組件。
+
+在此檔案的頂端,您會注意到我們有幾個執行專案所必需的匯入陳述式,包括 React 函式庫、useEffect 和 useState hook、來自 `./util/interact.js` 的一些項目 (我們稍後將更詳細地描述它們!),以及 Alchemy 標誌。
+
+```javascript
+// HelloWorld.js
+
+import React from "react"
+import { useEffect, useState } from "react"
+import {
+ helloWorldContract,
+ connectWallet,
+ updateMessage,
+ loadCurrentMessage,
+ getCurrentWalletConnected,
+} from "./util/interact.js"
+
+import alchemylogo from "./alchemylogo.svg"
+```
+
+接下來,我們有我們的狀態變數,我們將在特定事件後更新它們。
+
+```javascript
+// HelloWorld.js
+
+//狀態變數
+const [walletAddress, setWallet] = useState("")
+const [status, setStatus] = useState("")
+const [message, setMessage] = useState("未連線至網路。")
+const [newMessage, setNewMessage] = useState("")
+```
+
+以下是每個變數所代表的意義:
+
+- `walletAddress` - 一個儲存使用者錢包位址的字串
+- `status` - 一個儲存有用訊息的字串,引導使用者如何與去中心化應用程式互動
+- `message` - 一個儲存智慧型合約中目前訊息的字串
+- `newMessage` - 一個儲存將寫入智慧型合約的新訊息的字串
+
+在狀態變數之後,您會看到五個未實作的函式:`useEffect`、`addSmartContractListener`、`addWalletListener`、`connectWalletPressed` 和 `onUpdatePressed`。 我們將在下方解釋它們的功能:
+
+```javascript
+// HelloWorld.js
+
+//僅呼叫一次
+useEffect(async () => {
+ //TODO: 實作
+}, [])
+
+function addSmartContractListener() {
+ //TODO: 實作
+}
+
+function addWalletListener() {
+ //TODO: 實作
+}
+
+const connectWalletPressed = async () => {
+ //TODO: 實作
+}
+
+const onUpdatePressed = async () => {
+ //TODO: 實作
+}
+```
+
+- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html) - 這是一個 React hook,在您的元件渲染後呼叫。 因為它傳入了一個空陣列 `[]` prop (見第 4 行),所以它只會在元件的_第一次_渲染時被呼叫。 在這裡,我們將載入儲存在我們智慧型合約中的目前訊息,呼叫我們的智慧型合約和錢包監聽器,並更新我們的 UI 以反映錢包是否已連線。
+- `addSmartContractListener` - 此函式設定一個監聽器,它將監看我們的 HelloWorld 合約的 `UpdatedMessages` 事件,並在我們智慧型合約中的訊息變更時更新我們的 UI。
+- `addWalletListener` - 此函式設定一個監聽器,偵測使用者 MetaMask 錢包狀態的變更,例如使用者中斷錢包連線或切換地址時。
+- `connectWalletPressed` - 此函式將被呼叫以將使用者的 MetaMask 錢包連線至我們的去中心化應用程式。
+- `onUpdatePressed` - 當使用者想要更新儲存在智慧型合約中的訊息時,將會呼叫此函式。
+
+接近這份檔案的尾聲,我們得到了我們組件的UI。
+
+```javascript
+// HelloWorld.js
+
+//我們元件的 UI
+return (
+
+

+
+
+
目前訊息:
+
{message}
+
+
新訊息:
+
+
+
setNewMessage(e.target.value)}
+ value={newMessage}
+ />
+
{status}
+
+
+
+
+)
+```
+
+如果您仔細掃描此程式碼,您會注意到我們在 UI 中使用了各種狀態變數:
+
+- 在第 6-12 行,如果使用者的錢包已連線 (即 `walletAddress.length > 0`),我們會在 ID 為「walletButton」的按鈕中顯示使用者 `walletAddress` 的截斷版本;否則它只會顯示「連線錢包」。
+- 在第 17 行,我們顯示儲存在智慧型合約中的目前訊息,該訊息擷取在 `message` 字串中。
+- 在第 23-26 行,我們使用[受控元件](https://legacy.reactjs.org/docs/forms.html#controlled-components)來更新我們的 `newMessage` 狀態變數,當文字欄位中的輸入變更時。
+
+除了我們的狀態變數,您還會看到 `connectWalletPressed` 和 `onUpdatePressed` 函式分別在點擊 ID 為 `publishButton` 和 `walletButton` 的按鈕時被呼叫。
+
+最後,讓我們來處理這個 `HelloWorld.js` 元件被新增到哪裡的問題。
+
+如果您前往 `App.js` 檔案,這是 React 中的主要元件,作為所有其他元件的容器,您會看到我們的 `HelloWorld.js` 元件被注入在第 7 行。
+
+最後但同樣重要的是,讓我們查看為您提供的另一個檔案,即 `interact.js` 檔案。
+
+#### `interact.js` 檔案 {#the-interact-js-file}
+
+因為我們想要遵循 [M-V-C](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) 範式,我們將需要一個單獨的檔案,其中包含我們所有的函式來管理我們去中心化應用程式的邏輯、資料和規則,然後能夠將這些函式匯出到我們的前端 (我們的 `HelloWorld.js` 元件)。
+
+👆🏽這正是我們的 `interact.js` 檔案的目的!
+
+導覽至您 `src` 目錄中的 `util` 資料夾,您會注意到我們包含了一個名為 `interact.js` 的檔案,它將包含我們所有的智慧型合約互動和錢包函式與變數。
+
+```javascript
+// interact.js
+
+//export const helloWorldContract;
+
+export const loadCurrentMessage = async () => {}
+
+export const connectWallet = async () => {}
+
+const getCurrentWalletConnected = async () => {}
+
+export const updateMessage = async (message) => {}
+```
+
+您會注意到檔案頂端,我們已註解掉 `helloWorldContract` 物件。 稍後在本教學中,我們將取消註解此物件,並在此變數中實例化我們的智慧型合約,然後我們將其匯出至我們的 `HelloWorld.js` 元件。
+
+我們 `helloWorldContract` 物件之後的四個未實作函式執行以下操作:
+
+- `loadCurrentMessage` - 此函式處理載入儲存在智慧型合約中目前訊息的邏輯。 它將使用 [Alchemy Web3 API](https://github.com/alchemyplatform/alchemy-web3) 對 Hello World 智慧型合約進行_讀取_呼叫。
+- `connectWallet` - 此函式將把使用者的 MetaMask 連線至我們的去中心化應用程式。
+- `getCurrentWalletConnected` - 此函式將在頁面載入時檢查以太坊帳戶是否已連線至我們的去中心化應用程式,並相應地更新我們的 UI。
+- `updateMessage` - 此函式將更新儲存在智慧型合約中的訊息。 它將對 Hello World 智慧型合約進行_寫入_呼叫,因此使用者的 MetaMask 錢包必須簽署一筆以太坊交易才能更新訊息。
+
+既然我們了解了我們正在處理的內容,讓我們來弄清楚如何從我們的智慧型合約中讀取!
+
+### 步驟 3:從您的智慧型合約讀取 {#step-3-read-from-your-smart-contract}
+
+若要從您的智慧型合約讀取,您需要成功設定:
+
+- 與以太坊鏈的 API 連線
+- 您智慧型合約的載入執行個體
+- 呼叫您智慧型合約函式的函式
+- 一個監聽器,用於在您從智慧型合約讀取的資料變更時監看更新
+
+這聽起來可能有很多步驟,但別擔心! 我們將一步一步引導您完成它們! :\)
+
+#### 建立與以太坊鏈的 API 連線 {#establish-an-api-connection-to-the-ethereum-chain}
+
+還記得在本教學的第二部分中,我們如何使用我們的 [Alchemy Web3 金鑰從我們的智慧型合約讀取](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract/interacting-with-a-smart-contract#step-1-install-web3-library)嗎? 您還需要在您的去中心化應用程式中使用 Alchemy Web3 金鑰才能從鏈上讀取。
+
+如果您還沒有,首先安裝 [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3),方法是導覽至您 `starter-files` 的根目錄,並在您的終端機中執行以下指令:
+
+```text
+npm install @alch/alchemy-web3
+```
+
+[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) 是 [Web3.js](https://docs.web3js.org/) 的一個包裝器,提供了增強的 API 方法和其他關鍵優勢,讓你的 web3 開發者生活更輕鬆。 它是被設計成最低配置,因此你能夠在你的應用程式內馬上開始使用它!
+
+然後,在您的專案目錄中安裝 [dotenv](https://www.npmjs.com/package/dotenv) 套件,這樣我們在取得 API 金鑰後就有一個安全的地方來儲存它。
+
+```text
+npm install dotenv --save
+```
+
+對於我們的去中心化應用程式,**我們將使用我們的 Websockets API 金鑰** 而非我們的 HTTP API 金鑰,因為它將允許我們設定一個監聽器,偵測儲存在智慧型合約中的訊息何時變更。
+
+取得您的 API 金鑰後,在您的根目錄中建立一個 `.env` 檔案,並將您的 Alchemy Websockets url 新增至其中。 之後,您的 `.env` 檔案應如下所示:
+
+```javascript
+REACT_APP_ALCHEMY_KEY = wss://eth-goerli.ws.alchemyapi.io/v2/
+```
+
+現在,我們已準備好在我們的去中心化應用程式中設定我們的 Alchemy Web3 端點! 讓我們回到我們的 `interact.js`,它巢狀在我們的 `util` 資料夾中,並在檔案頂端新增以下程式碼:
+
+```javascript
+// interact.js
+
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+
+//export const helloWorldContract;
+```
+
+在上方,我們首先從我們的 `.env` 檔案匯入 Alchemy 金鑰,然後將我們的 `alchemyKey` 傳遞給 `createAlchemyWeb3` 以建立我們的 Alchemy Web3 端點。
+
+有了這個端點,是時候載入我們的智慧型合約了!
+
+#### 載入您的 Hello World 智慧型合約 {#loading-your-hello-world-smart-contract}
+
+要載入您的 Hello World 智慧型合約,您需要其合約地址和 ABI,如果您完成了[本教學的第三部分](/developers/tutorials/hello-world-smart-contract-fullstack/#part-3-publish-your-smart-contract-to-etherscan-part-3-publish-your-smart-contract-to-etherscan),兩者都可以在 Etherscan 上找到。
+
+#### 如何從 Etherscan 取得您的合約 ABI {#how-to-get-your-contract-abi-from-etherscan}
+
+如果您跳過了本教學的第三部分,您可以使用地址為 [0x6f3f635A9762B47954229Ea479b4541eAF402A6A](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code) 的 HelloWorld 合約。 其 ABI 可以在[這裡](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code)找到。
+
+合約 ABI 對於指定合約將調用哪個函式以及確保函式將以您期望的格式回傳資料是必要的。 複製我們的合約 ABI 後,讓我們將其另存為一個名為 `contract-abi.json` 的 JSON 檔案,儲存在您的 `src` 目錄中。
+
+您的 contract-abi.json 應儲存在您的 src 資料夾中。
+
+有了我們的合約地址、ABI 和 Alchemy Web3 端點,我們可以使用 [contract 方法](https://docs.web3js.org/api/web3-eth-contract/class/Contract)來載入我們智慧型合約的執行個體。 將您的合約 ABI 匯入 `interact.js` 檔案並新增您的合約地址。
+
+```javascript
+// interact.js
+
+const contractABI = require("../contract-abi.json")
+const contractAddress = "0x6f3f635A9762B47954229Ea479b4541eAF402A6A"
+```
+
+我們現在終於可以取消註解我們的 `helloWorldContract` 變數,並使用我們的 AlchemyWeb3 端點載入智慧型合約:
+
+```javascript
+// interact.js
+export const helloWorldContract = new web3.eth.Contract(
+ contractABI,
+ contractAddress
+)
+```
+
+總結一下,您 `interact.js` 的前 12 行現在應該如下所示:
+
+```javascript
+// interact.js
+
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+
+const contractABI = require("../contract-abi.json")
+const contractAddress = "0x6f3f635A9762B47954229Ea479b4541eAF402A6A"
+
+export const helloWorldContract = new web3.eth.Contract(
+ contractABI,
+ contractAddress
+)
+```
+
+既然我們已載入合約,我們就可以實作我們的 `loadCurrentMessage` 函式了!
+
+#### 在您的 `interact.js` 檔案中實作 `loadCurrentMessage` {#implementing-loadCurrentMessage-in-your-interact-js-file}
+
+這個函式非常簡單。 我們將進行一個簡單的非同步 web3 呼叫來從我們的合約中讀取。 我們的函式將回傳儲存在智慧型合約中的訊息:
+
+將您 `interact.js` 檔案中的 `loadCurrentMessage` 更新為以下內容:
+
+```javascript
+// interact.js
+
+export const loadCurrentMessage = async () => {
+ const message = await helloWorldContract.methods.message().call()
+ return message
+}
+```
+
+由於我們希望在我們的 UI 中顯示此智慧型合約,讓我們將 `HelloWorld.js` 元件中的 `useEffect` 函式更新為以下內容:
+
+```javascript
+// HelloWorld.js
+
+//僅呼叫一次
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+}, [])
+```
+
+請注意,我們只希望在元件第一次渲染時呼叫一次 `loadCurrentMessage`。 我們很快就會實作 `addSmartContractListener`,以便在智慧型合約中的訊息變更後自動更新 UI。
+
+在我們深入研究我們的監聽器之前,讓我們來看看我們目前為止的成果! 儲存您的 `HelloWorld.js` 和 `interact.js` 檔案,然後前往 [http://localhost:3000/](http://localhost:3000/)
+
+您會注意到目前訊息不再顯示「未連線至網路」。 而是反映儲存在智慧型合約中的訊息。 太棒了!
+
+#### 您的 UI 現在應該反映儲存在智慧型合約中的訊息 {#your-UI-should-now-reflect-the-message-stored-in-the-smart-contract}
+
+現在說到那個監聽器...
+
+#### 實作 `addSmartContractListener` {#implement-addsmartcontractlistener}
+
+如果您回想一下我們在本教學系列[第一部分](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract#step-10-write-our-contract)中編寫的 `HelloWorld.sol` 檔案,您會記得在我們的智慧型合約的 `update` 函式被調用後 (見第 9 和 27 行),會發出一個名為 `UpdatedMessages` 的智慧型合約事件:
+
+```javascript
+// HelloWorld.sol
+
+// 指定 Solidity 的版本,使用語意化版本控制。
+// 了解更多:https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+pragma solidity ^0.7.3;
+
+// 定義一個名為「HelloWorld」的合約。
+// 合約是函式和資料 (其狀態) 的集合。部署後,合約會存放在以太坊區塊鏈的特定地址上。了解更多:https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
+contract HelloWorld {
+
+ // 呼叫更新函式時發出
+ // 智慧型合約事件是您合約的一種方式,可將區塊鏈上發生的事情傳達給您的應用程式前端,前端可以「監聽」某些事件並在事件發生時採取行動。
+ event UpdatedMessages(string oldStr, string newStr);
+
+ // 宣告一個「string」類型的狀態變數「message」。
+ // 狀態變數是其值永久儲存在合約儲存空間中的變數。關鍵字「public」可讓變數從合約外部存取,並建立一個其他合約或用戶端可呼叫以存取該值的函式。
+ string public message;
+
+ // 與許多以類別為基礎的物件導向語言相似,建構函式是一個特殊函式,只在合約建立時執行。
+ // 建構函式用於初始化合約的資料。了解更多:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
+ constructor(string memory initMessage) {
+
+ // 接受一個字串引數「initMessage」,並將該值設定到合約的「message」儲存變數中)。
+ message = initMessage;
+ }
+
+ // 一個公共函式,接受一個字串引數並更新「message」儲存變數。
+ function update(string memory newMessage) public {
+ string memory oldMsg = message;
+ message = newMessage;
+ emit UpdatedMessages(oldMsg, newMessage);
+ }
+}
+```
+
+智慧型合約事件是您合約的一種方式,可將區塊鏈上發生的事情 (即發生了_事件_) 傳達給您的前端應用程式,前端可以「監聽」特定事件並在事件發生時採取行動。
+
+`addSmartContractListener` 函式將專門監聽我們的 Hello World 智慧型合約的 `UpdatedMessages` 事件,並更新我們的 UI 以顯示新訊息。
+
+將 `addSmartContractListener` 修改為以下內容:
+
+```javascript
+// HelloWorld.js
+
+function addSmartContractListener() {
+ helloWorldContract.events.UpdatedMessages({}, (error, data) => {
+ if (error) {
+ setStatus("😥 " + error.message)
+ } else {
+ setMessage(data.returnValues[1])
+ setNewMessage("")
+ setStatus("🎉 您的訊息已更新!")
+ }
+ })
+}
+```
+
+讓我們來分解一下監聽器偵測到事件時會發生什麼事:
+
+- 如果事件發出時發生錯誤,它將透過我們的 `status` 狀態變數反映在 UI 中。
+- 否則,我們將使用回傳的 `data` 物件。 `data.returnValues` 是一個從零開始索引的陣列,其中陣列中的第一個元素儲存先前的訊息,第二個元素儲存更新後的訊息。 總而言之,在一個成功的事件上,我們將把我們的 `message` 字串設定為更新後的訊息,清除 `newMessage` 字串,並更新我們的 `status` 狀態變數以反映新訊息已發布在我們的智慧型合約上。
+
+最後,讓我們在我們的 `useEffect` 函式中呼叫我們的監聽器,以便它在 `HelloWorld.js` 元件的第一次渲染時被初始化。 總而言之,您的 `useEffect` 函式應如下所示:
+
+```javascript
+// HelloWorld.js
+
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+ addSmartContractListener()
+}, [])
+```
+
+既然我們能從我們的智慧型合約中讀取,如果能弄清楚如何寫入就太好了! 然而,若要寫入我們的去中心化應用程式,我們必須先有一個以太坊錢包連線到它。
+
+所以,接下來我們將處理設定我們的以太坊錢包 (MetaMask),然後將它連線至我們的去中心化應用程式!
+
+### 步驟 4:設定您的以太坊錢包 {#step-4-set-up-your-ethereum-wallet}
+
+若要向以太坊鏈寫入任何內容,使用者必須使用其虛擬錢包的私密金鑰簽署交易。 在本教學中,我們將使用 [MetaMask](https://metamask.io/),這是一款瀏覽器中的虛擬錢包,用於管理您的以太坊帳戶地址,因為它讓最終使用者簽署交易變得非常容易。
+
+如果您想深入了解以太坊上的交易如何運作,請參閱以太坊基金會的[此頁面](/developers/docs/transactions/)。
+
+#### 下載 MetaMask {#download-metamask}
+
+您可以在[這裡](https://metamask.io/download)免費下載並建立 MetaMask 帳戶。 在建立帳戶時,或如果您已有帳戶,請確保切換到右上角的「Goerli 測試網」 (這樣我們就不會處理真實貨幣)。
+
+#### 從水龍頭新增以太幣 {#add-ether-from-a-faucet}
+
+若要在以太坊區塊鏈上簽署交易,我們需要一些假的 Eth。 若要取得 Eth,您可以前往 [FaucETH](https://fauceth.komputing.org) 並輸入您的 Goerli 帳戶地址,點擊「請求資金」,然後在下拉式選單中選取「以太坊測試網 Goerli」,最後再次點擊「請求資金」按鈕。 你應該很快便能在你的MetaMask帳戶裡看見ETH!
+
+#### 檢查您的餘額 {#check-your-balance}
+
+為了再次確認我們的餘額,讓我們使用 [Alchemy 的 composer 工具](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) 發出一個 [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) 請求。 這將會把我們錢包內的以太結餘回傳。 在你輸入自己的MetaMask帳戶地址,並且點下「寄送請求」後,你理應會看見一個這樣子的回應:
+
+```text
+{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}
+```
+
+**注意:** 此結果的單位是 wei,不是 eth。 Wei是一個被用來計算以太最少分數的單位。 要把wei換算到ETH的算術是:1 ETH = 10¹⁸ wei。 所以,如果我們要換算 0xde0b6b3a7640000 到小數點,我們會得到 1\*10¹⁸的結果,它相當於一個ETH的數值。
+
+哈! 我們的假錢都在這! 🤑
+
+### 步驟 5:將 MetaMask 連線至您的 UI {#step-5-connect-metamask-to-your-UI}
+
+既然我們的 MetaMask 錢包已經設定好了,就讓我們把去中心化應用程式連接到它吧!
+
+#### `connectWallet` 函式 {#the-connectWallet-function}
+
+在我們的 `interact.js` 檔案中,讓我們來實作 `connectWallet` 函式,然後我們可以在我們的 `HelloWorld.js` 元件中呼叫它。
+
+讓我們將 `connectWallet` 修改為以下內容:
+
+```javascript
+// interact.js
+
+export const connectWallet = async () => {
+ if (window.ethereum) {
+ try {
+ const addressArray = await window.ethereum.request({
+ method: "eth_requestAccounts",
+ })
+ const obj = {
+ status: "👆🏽 在上方的文字欄位中寫一則訊息。",
+ address: addressArray[0],
+ }
+ return obj
+ } catch (err) {
+ return {
+ address: "",
+ status: "😥 " + err.message,
+ }
+ }
+ } else {
+ return {
+ address: "",
+ status: (
+
+
+ {" "}
+ 🦊
+ 您必須在瀏覽器中安裝 MetaMask,這是一款虛擬以太坊錢包。
+
+
+
+ ),
+ }
+ }
+}
+```
+
+那麼這段龐大的程式碼究竟做了什麼?
+
+首先,它會檢查您的瀏覽器中是否啟用了 `window.ethereum`。
+
+`window.ethereum` 是由 MetaMask 和其他錢包提供者注入的全域 API,允許網站請求使用者的以太坊帳戶。 如果獲得批准,它可以從使用者連線的區塊鏈讀取資料,並建議使用者簽署訊息和交易。 查看 [MetaMask 文件](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)以獲得更多資訊!
+
+如果 `window.ethereum` _不存在_,那表示 MetaMask 沒有安裝。 這會回傳一個 JSON 物件,其中回傳的 `address` 是一個空字串,而 `status` JSX 物件則傳達使用者必須安裝 MetaMask 的訊息。
+
+現在如果 `window.ethereum` _存在_,事情就變得有趣了。
+
+使用 try/catch 迴圈,我們將透過呼叫 [`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts) 來嘗試連接 MetaMask。 呼叫這個函式會在瀏覽器中開啟 MetaMask,提示使用者將他們的錢包連接到你的去中心化應用程式。
+
+- 如果使用者選擇連線,`method: "eth_requestAccounts"` 將回傳一個陣列,其中包含所有連線至去中心化應用程式的使用者帳戶地址。 總而言之,我們的 `connectWallet` 函式會回傳一個 JSON 物件,其中包含此陣列中的_第一個_ `address` (見第 9 行) 和一則 `status` 訊息,提示使用者向智能合約寫入一則訊息。
+- 如果使用者拒絕連接,那麼 JSON 物件將包含一個空字串作為回傳的 `address`,以及一則反映使用者拒絕連接的 `status` 訊息。
+
+既然我們已編寫此 `connectWallet` 函式,下一步就是將它呼叫至我們的 `HelloWorld.js` 元件。
+
+#### 將 `connectWallet` 函式新增至您的 `HelloWorld.js` UI 元件 {#add-the-connectWallet-function-to-your-HelloWorld-js-ui-component}
+
+導覽至 `HelloWorld.js` 中的 `connectWalletPressed` 函式,並將其更新為以下內容:
+
+```javascript
+// HelloWorld.js
+
+const connectWalletPressed = async () => {
+ const walletResponse = await connectWallet()
+ setStatus(walletResponse.status)
+ setWallet(walletResponse.address)
+}
+```
+
+注意到我們的大部分功能是如何從 `interact.js` 檔案中抽象出來,遠離我們的 `HelloWorld.js` 元件嗎? 這是我們跟M-V-C規範相容的做法!
+
+在 `connectWalletPressed` 中,我們只需對匯入的 `connectWallet` 函式進行一個 await 呼叫,並利用其回應,透過它們的 state hooks 更新我們的 `status` 和 `walletAddress` 變數。
+
+現在,讓我們儲存這兩個檔案 (`HelloWorld.js` 和 `interact.js`),並測試一下我們目前的 UI。
+
+在 [http://localhost:3000/](http://localhost:3000/) 頁面上開啟您的瀏覽器,並按下頁面右上角的「連線錢包」按鈕。
+
+如果你已安裝 MetaMask,系統應該會提示你將錢包連接到你的去中心化應用程式。 請接受進行連結的邀請。
+
+您應該會看到錢包按鈕現在反映您的地址已連線! 太棒了 🔥
+
+接下來,試著重新整理頁面... 這很奇怪。 我們的錢包按鈕會鼓勵我們對MetaMask進行連結,就算它已經被連結好了。。。。。。
+
+不過,別擔心! 我們可以輕鬆地處理這個問題 (懂嗎?) 透過實作 `getCurrentWalletConnected`,它將檢查是否有地址已連線至我們的去中心化應用程式,並相應地更新我們的 UI!
+
+#### `getCurrentWalletConnected` 函式 {#the-getcurrentwalletconnected-function}
+
+將您 `interact.js` 檔案中的 `getCurrentWalletConnected` 函式更新為以下內容:
+
+```javascript
+// interact.js
+
+export const getCurrentWalletConnected = async () => {
+ if (window.ethereum) {
+ try {
+ const addressArray = await window.ethereum.request({
+ method: "eth_accounts",
+ })
+ if (addressArray.length > 0) {
+ return {
+ address: addressArray[0],
+ status: "👆🏽 在上方的文字欄位中寫一則訊息。",
+ }
+ } else {
+ return {
+ address: "",
+ status: "🦊 使用右上角按鈕連線至 MetaMask。",
+ }
+ }
+ } catch (err) {
+ return {
+ address: "",
+ status: "😥 " + err.message,
+ }
+ }
+ } else {
+ return {
+ address: "",
+ status: (
+
+
+ {" "}
+ 🦊
+ 您必須在瀏覽器中安裝 MetaMask,這是一款虛擬以太坊錢包。
+
+
+
+ ),
+ }
+ }
+}
+```
+
+這段程式碼與我們剛在上一步中編寫的 `connectWallet` 函式_非常_相似。
+
+主要的區別在於,我們不是呼叫 `eth_requestAccounts` 方法 (這會開啟 MetaMask 讓使用者連接他們的錢包),而是在這裡呼叫 `eth_accounts` 方法,它只會回傳一個包含當前連接到我們去中心化應用程式的 MetaMask 位址的陣列。
+
+若要查看此函式的實際運作情況,讓我們在我們的 `HelloWorld.js` 元件的 `useEffect` 函式中呼叫它:
+
+```javascript
+// HelloWorld.js
+
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+ addSmartContractListener()
+
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+}, [])
+```
+
+注意,我們使用對 `getCurrentWalletConnected` 呼叫的回應來更新我們的 `walletAddress` 和 `status` 狀態變數。
+
+既然您已新增此程式碼,讓我們試著重新整理我們的瀏覽器視窗。
+
+太棒了! 這個按鈕應該會跟你說:「你已經連結好了。」,然後會顯出一個你錢包被連結好的地址的預視 - 就算在你刷新之後也會這樣!
+
+#### 實作 `addWalletListener` {#implement-addwalletlistener}
+
+我們去中心化應用程式錢包設定的最後一個步驟是實作錢包監聽器,這樣當我們錢包的狀態改變時 (例如使用者中斷連線或切換帳戶),我們的 UI 就會更新。
+
+在您的 `HelloWorld.js` 檔案中,將您的 `addWalletListener` 函式修改為以下內容:
+
+```javascript
+// HelloWorld.js
+
+function addWalletListener() {
+ if (window.ethereum) {
+ window.ethereum.on("accountsChanged", (accounts) => {
+ if (accounts.length > 0) {
+ setWallet(accounts[0])
+ setStatus("👆🏽 在上方的文字欄位中寫一則訊息。")
+ } else {
+ setWallet("")
+ setStatus("🦊 使用右上角按鈕連線至 MetaMask。")
+ }
+ })
+ } else {
+ setStatus(
+
+ {" "}
+ 🦊
+ 您必須在瀏覽器中安裝 MetaMask,這是一款虛擬以太坊錢包。
+
+
+ )
+ }
+}
+```
+
+我敢打賭,此時您甚至不需要我們的幫助就能了解這裡發生了什麼事,但為了周全起見,讓我們快速分解一下:
+
+- 首先,我們的函式會檢查 `window.ethereum` 是否已啟用 (即 MetaMask 已安裝)。
+ - 如果沒有啟用,我們只需將 `status` 狀態變數設定為一個 JSX 字串,提示使用者安裝 MetaMask。
+ - 如果已啟用,我們在第 3 行設定監聽器 `window.ethereum.on("accountsChanged")`,它會監聽 MetaMask 錢包的狀態變化,包括使用者將額外帳戶連接到去中心化應用程式、切換帳戶或中斷帳戶連線時。 如果至少有一個帳戶已連接,`walletAddress` 狀態變數會更新為監聽器回傳的 `accounts` 陣列中的第一個帳戶。 否則,`walletAddress` 會被設定為空字串。
+
+最後但同樣重要的是,我們必須在我們的 `useEffect` 函式中呼叫它:
+
+```javascript
+// HelloWorld.js
+
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+ addSmartContractListener()
+
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+
+ addWalletListener()
+}, [])
+```
+
+就是這樣! 我們已成功完成所有錢包功能的編寫! 現在進入我們最後的任務:更新儲存在我們智慧型合約中的訊息!
+
+### 步驟 6:實作 `updateMessage` 函式 {#step-6-implement-the-updateMessage-function}
+
+好了,各位,我們已進入最後階段! 在您 `interact.js` 檔案的 `updateMessage` 中,我們將執行以下操作:
+
+1. 確保我們希望在我們的智慧合約中發布的訊息是有效的
+2. 使用 MetaMask 簽署我們的交易
+3. 從我們的 `HelloWorld.js` 前端元件呼叫此函式
+
+這不會花很長時間;讓我們完成這個去中心化應用程式!
+
+#### 輸入錯誤處理 {#input-error-handling}
+
+自然地,在函式開始時進行某種輸入錯誤處理是合理的。
+
+如果沒有安裝 MetaMask 擴充功能、沒有連線錢包 (即傳入的 `address` 是空字串),或者 `message` 是空字串,我們希望我們的函式能提早回傳。 讓我們將以下錯誤處理新增至 `updateMessage`:
+
+```javascript
+// interact.js
+
+export const updateMessage = async (address, message) => {
+ if (!window.ethereum || address === null) {
+ return {
+ status:
+ "💡 連線您的 MetaMask 錢包以更新區塊鏈上的訊息。",
+ }
+ }
+
+ if (message.trim() === "") {
+ return {
+ status: "❌ 您的訊息不能是空字串。",
+ }
+ }
+}
+```
+
+既然它有了適當的輸入錯誤處理,是時候透過 MetaMask 簽署交易了!
+
+#### 簽署我們的交易 {#signing-our-transaction}
+
+如果您已經熟悉傳統的 web3 以太坊交易,我們接下來編寫的程式碼將會非常熟悉。 在您的輸入錯誤處理程式碼下方,將以下內容新增至 `updateMessage`:
+
+```javascript
+// interact.js
+
+//設定交易參數
+const transactionParameters = {
+ to: contractAddress, // 合約發布期間除外為必要
+ from: address, // 必須與使用者目前的地址相符
+ data: helloWorldContract.methods.update(message).encodeABI(),
+}
+
+//簽署交易
+try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ status: (
+
+ ✅{" "}
+
+ 在 Etherscan 上查看您交易的狀態!
+
+
+ ℹ️ 交易一旦經網路驗證,訊息將自動更新。
+
+ ),
+ }
+} catch (error) {
+ return {
+ status: "😥 " + error.message,
+ }
+}
+```
+
+讓我們來分解一下發生了什麼事。 首先,我們設定我們的交易參數,其中:
+
+- `to` 指定接收方位址 (我們的智能合約)
+- `from` 指定交易的簽署者,即我們傳入函式的 `address` 變數
+- `data` 包含對我們 Hello World 智慧型合約的 `update` 方法的呼叫,並接收我們的 `message` 字串變數作為輸入
+
+然後,我們進行一個 await 呼叫,`window.ethereum.request`,我們在此請求 MetaMask 簽署交易。 請注意,在第 11 和 12 行,我們正在指定我們的 eth 方法 `eth_sendTransaction`,並傳入我們的 `transactionParameters`。
+
+在這時機,MetaMask將會在瀏覽器中被開啟,然後鼓勵用戶去簽署或拒絕該筆交易。
+
+- 如果交易成功,函式將回傳一個 JSON 物件,其中 `status` JSX 字串會提示使用者查看 Etherscan 以取得有關其交易的更多資訊。
+- 如果交易失敗,函式將回傳一個 JSON 物件,其中 `status` 字串會轉達錯誤訊息。
+
+總而言之,我們的 `updateMessage` 函式應如下所示:
+
+```javascript
+// interact.js
+
+export const updateMessage = async (address, message) => {
+ //輸入錯誤處理
+ if (!window.ethereum || address === null) {
+ return {
+ status:
+ "💡 連線您的 MetaMask 錢包以更新區塊鏈上的訊息。",
+ }
+ }
+
+ if (message.trim() === "") {
+ return {
+ status: "❌ 您的訊息不能是空字串。",
+ }
+ }
+
+ //設定交易參數
+ const transactionParameters = {
+ to: contractAddress, // 合約發布期間除外為必要
+ from: address, // 必須與使用者目前的地址相符
+ data: helloWorldContract.methods.update(message).encodeABI(),
+ }
+
+ //簽署交易
+ try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ status: (
+
+ ✅{" "}
+
+ 在 Etherscan 上查看您交易的狀態!
+
+
+ ℹ️ 交易一旦經網路驗證,訊息將自動更新。
+
+ ),
+ }
+ } catch (error) {
+ return {
+ status: "😥 " + error.message,
+ }
+ }
+}
+```
+
+最後但同樣重要的是,我們需要將我們的 `updateMessage` 函式連線至我們的 `HelloWorld.js` 元件。
+
+#### 將 `updateMessage` 連線至 `HelloWorld.js` 前端 {#connect-updatemessage-to-the-helloworld-js-frontend}
+
+我們的 `onUpdatePressed` 函式應對匯入的 `updateMessage` 函式進行 await 呼叫,並修改 `status` 狀態變數以反映我們的交易是成功還是失敗:
+
+```javascript
+// HelloWorld.js
+
+const onUpdatePressed = async () => {
+ const { status } = await updateMessage(walletAddress, newMessage)
+ setStatus(status)
+}
+```
+
+它非常乾淨簡單。 您猜怎麼著... 您的去中心化應用程式完成了!!!
+
+去測試一下**更新**按鈕吧!
+
+### 製作您自己的自訂去中心化應用程式 {#make-your-own-custom-dapp}
+
+哇,您完成了本教學! 總結一下,您學會了如何:
+
+- 將 MetaMask 錢包連線至您的去中心化應用程式專案
+- 使用 [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) API 從您的智慧型合約讀取資料
+- 使用 MetaMask 簽署以太坊交易
+
+現在您已完全具備應用本教學的技能,可以打造您自己的自訂去中心化應用程式專案了! 一如既往,如果您有任何問題,請隨時到 [Alchemy Discord](https://discord.gg/gWuC7zB) 尋求協助。 🧙♂️
+
+完成本教學後,請在 Twitter 上標記我們 [@alchemyplatform](https://twitter.com/AlchemyPlatform),讓我們知道您的體驗如何,或是否有任何回饋!
diff --git a/public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract/index.md
new file mode 100644
index 00000000000..98c39a961df
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/hello-world-smart-contract/index.md
@@ -0,0 +1,359 @@
+---
+title: 給初學者的 Hello World 智能合約
+description: 在以太坊上撰寫和部署簡單智能合約的入門教學。
+author: "elanh"
+tags: [ "穩固", "hardhat", "alchemy", "智能合約", "部署" ]
+skill: beginner
+lang: zh-tw
+published: 2021-03-31
+---
+
+如果你是區塊鏈開發新手,不知道從何開始,或者你只是想了解如何部署智能合約並與之互動,本指南就是為你準備的。 我們將使用虛擬錢包 [MetaMask](https://metamask.io/)、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org/) 和 [Alchemy](https://www.alchemy.com/eth) 逐步說明如何在 Sepolia 測試網上建立和部署一個簡單的智能合約 (如果你還不了解這些術語的含義,別擔心,我們會解釋的)。
+
+在本教學的[第 2 部分](https://docs.alchemy.com/docs/interacting-with-a-smart-contract)中,我們將介紹部署後如何與我們的智能合約互動,並在[第 3 部分](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan)中介紹如何在 Etherscan 上發布它。
+
+如果你有任何問題,隨時可以在 [Alchemy Discord](https://discord.gg/gWuC7zB) 中提問!
+
+## 第 1 步:連接到以太坊網路 {#step-1}
+
+向以太坊鏈發出請求有很多種方式。 為求簡單,我們將使用 Alchemy 的免費帳戶,它是一個區塊鏈開發者平台暨 API,讓我們不用運行自己的節點,就能與以太坊鏈通訊。 該平台還提供用於監控和分析的開發者工具,我們將在本教學中利用這些工具來了解我們智能合約部署的底層情況。 如果你還沒有 Alchemy 帳戶,可以[在這裡免費註冊](https://dashboard.alchemy.com/signup)。
+
+## 第 2 步:創建你的應用程式 (和 API 金鑰) {#step-2}
+
+一旦你已經創建好一個Alchemy的帳戶,你可以通過建立一個程式來生成一個API鑰匙。 這將讓我們能向 Sepolia 測試網發出請求。 如果你不熟悉測試網,請查看[此頁面](/developers/docs/networks/)。
+
+1. 在你的 Alchemy 儀表板中,導覽至「Create new app」頁面,方法是在導覽列中選擇「Select an app」,然後點擊「Create new app」。
+
+
+
+2. 將你的應用程式命名為「Hello World」,提供簡短描述,並選擇一個使用案例,例如「Infra & Tooling」。 接著,搜尋「Ethereum」並選擇網路。
+
+
+
+3. 點擊「Next」繼續,然後點擊「Create app」,就完成了! 你的應用程式應該會出現在導覽列的下拉式選單中,並提供可供複製的 API 金鑰。
+
+## 第 3 步:建立一個以太坊帳戶 (地址) {#step-3}
+
+我們需要一個乙太坊帳戶去接收或發送交易。 為此教學,我們將會使用 MetaMask。它是一個在瀏覽器上管理你的乙太坊帳戶地址的虛擬錢包。 更多關於[交易](/developers/docs/transactions/)的資訊。
+
+你可以[在這裡](https://metamask.io/download)免費下載 MetaMask 並建立一個以太坊帳戶。 當你在建立帳戶時,或者如果你已經有帳戶,請務必使用網路下拉式選單切換到「Sepolia」測試網 (這樣我們就不用處理真實貨幣)。
+
+如果你沒有看到 Sepolia 列出,請進入選單,然後到「Advanced」,向下捲動以開啟「Show test networks」。 在網路選擇選單中,選擇「Custom」分頁以尋找測試網列表,然後選擇「Sepolia」。
+
+
+
+## 第 4 步:從水龍頭獲取以太幣 {#step-4}
+
+為了將我們的智能合約部署到測試網,我們需要一些假的 Eth。 要取得 Sepolia ETH,你可以前往 [Sepolia 網路詳細資料](/developers/docs/networks/#sepolia)來查看各種水龍頭的列表。 如果其中一個不能用,試試另一個,因為它們有時可能會用完。 由於網路流量的關係,可能需要一些時間才能收到你的假 ETH。 不久之後,你應該會在你的 Metamask 帳戶中看到 ETH!
+
+## 第 5 步:檢查你的餘額 {#step-5}
+
+為再次確認我們的餘額,讓我們使用 [Alchemy 的 composer tool](https://sandbox.alchemy.com/?network=ETH_SEPOLIA&method=eth_getBalance&body.id=1&body.jsonrpc=2.0&body.method=eth_getBalance&body.params%5B0%5D=&body.params%5B1%5D=latest) 發出一個 [eth_getBalance](/developers/docs/apis/json-rpc/#eth_getbalance) 請求。 這將會回傳你的錢包裡的餘額。 在你輸入自己的MetaMask帳戶地址,並且點下「寄送請求」後,你理應會看見一個這樣子的回應:
+
+```json
+{ "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" }
+```
+
+> \*\*注意:\*\*此結果以 wei 為單位,而非 ETH。 Wei是一個被用來計算以太最少分數的單位。 wei 與 ETH 的換算為:1 eth = 1018 wei。 因此,如果我們將 0x2B5E3AF16B1880000 轉換為十進位,我們會得到 5\*10¹⁸,相當於 5 ETH。
+>
+> 哈! 我們的假錢都在這裡了 。
+
+## 第 6 步:初始化我們的專案 {#step-6}
+
+首先,我們需要一個資料夾給我們的專案。 前往到你的指令介面(powershell, cmd 或 Terminal) 接著輸入:
+
+```
+mkdir hello-world
+cd hello-world
+```
+
+現在我們在專案資料夾中了,我們將使用 `npm init` 來初始化專案。 如果你還沒有安裝 npm,請遵循[這些說明](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) (我們也需要 Node.js,所以也請下載它!)。
+
+```
+npm init
+```
+
+你如何回答安裝問題並不重要,以下是我們的做法,僅供參考:
+
+```
+套件名稱:(hello-world)
+版本:(1.0.0)
+描述:hello world 智能合約
+進入點:(index.js)
+測試指令:
+git 儲存庫:
+關鍵字:
+作者:
+授權:(ISC)
+即將寫入 /Users/.../.../.../hello-world/package.json:
+
+{
+ "name": "hello-world",
+ "version": "1.0.0",
+ "description": "hello world 智能合約",
+ "main": "index.js",
+ "scripts": {
+ "test": "echo \"Error: no test specified\" && exit 1"
+ },
+ "author": "",
+ "license": "ISC"
+}
+```
+
+核准 package.json,我們就可以開始了!
+
+## 第 7 步:下載 [Hardhat](https://hardhat.org/getting-started/#overview) {#step-7}
+
+Hardhat 是一個開發環境,提供你去編譯、部屬、測試、以及除錯你的以太坊軟體。 它能協助開發人員在部署至即時鏈之前,於本機建立智慧合約和去中心化應用程式。
+
+在我們的 `hello-world` 專案中執行:
+
+```
+npm install --save-dev hardhat
+```
+
+如需更多[安裝指示](https://hardhat.org/getting-started/#overview)的詳細資訊,請查看此頁面。
+
+## 第 8 步:建立 Hardhat 專案 {#step-8}
+
+在你的專案資料夾下執行:
+
+```
+npx hardhat
+```
+
+你接下來會看到歡迎訊息以及關於你想做什麼的選項。 選擇"create an empty hardhat.config.js":
+
+```
+888 888 888 888 888
+888 888 888 888 888
+888 888 888 888 888
+8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888
+888 888 "88b 888P" d88" 888 888 "88b "88b 888
+888 888 .d888888 888 888 888 888 888 .d888888 888
+888 888 888 888 888 Y88b 888 888 888 888 888 Y88b.
+888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888
+
+👷 歡迎來到 Hardhat v2.0.11 👷
+
+你想做什麼?…
+建立範例專案
+❯ 建立一個空的 hardhat.config.js
+退出
+```
+
+這會為我們產生一個 `hardhat.config.js` 檔案,我們將在其中指定專案的所有設定 (在第 13 步)。
+
+## 第 9 步:新增專案資料夾 {#step-9}
+
+為了讓我們的專案井然有序,我們將建立兩個新資料夾。 在你的指令介面返回到到專案資料夾,接著輸入:
+
+```
+mkdir contracts
+mkdir scripts
+```
+
+- `contracts/` 是我們存放 hello world 智能合約程式碼檔案的地方
+- `scripts/` 是我們存放部署和與合約互動的腳本的地方
+
+## 第 10 步:撰寫我們的合約 {#step-10}
+
+你可能會問自己,我們到底什麼時候才要寫程式碼? 嗯,我們現在就在第 10 步。
+
+在你喜歡的編輯器中打開 hello-world 專案 (我們喜歡 [VSCode](https://code.visualstudio.com/))。 智能合約是以一種稱為 Solidity 的語言編寫的,我們將用它來編寫我們的 HelloWorld.sol 智能合約。
+
+1. 導覽至「contracts」資料夾並建立一個名為 HelloWorld.sol 的新檔案。
+2. 以下是來自以太坊基金會的 Hello World 智能合約範例,我們將在本教學中使用它。 複製並貼上下方內容到你的 HelloWorld.sol 檔案中,並務必閱讀註解以了解此合約的功能:
+
+```solidity
+// 指定 Solidity 的版本,使用語意化版本。
+// 了解更多:https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+pragma solidity ^0.7.0;
+
+// 定義一個名為 `HelloWorld` 的合約。
+// 合約是函式和資料 (其狀態) 的集合。一旦部署,合約就會位於以太坊區塊鏈上的特定地址。了解更多:https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
+contract HelloWorld {
+
+ // 宣告一個 `string` 型別的狀態變數 `message`。
+ // 狀態變數是其值永久儲存在合約儲存空間中的變數。關鍵字 `public` 使變數可從合約外部存取,並建立一個其他合約或用戶端可以呼叫以存取該值的函式。
+ string public message;
+
+ // 與許多以類別為基礎的物件導向語言類似,建構函式是一個特殊函式,只在合約建立時執行。
+ // 建構函式用於初始化合約的資料。了解更多:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
+ constructor(string memory initMessage) {
+
+ // 接受一個字串引數 `initMessage`,並將其值設定到合約的 `message` 儲存變數中。
+ message = initMessage;
+ }
+
+ // 一個公開函式,接受一個字串引數並更新 `message` 儲存變數。
+ function update(string memory newMessage) public {
+ message = newMessage;
+ }
+}
+```
+
+這是一個非常簡單的智能合約,它在建立時儲存一則訊息,並可以透過呼叫 `update` 函式進行更新。
+
+## 第 11 步:將 MetaMask 和 Alchemy 連接到你的專案 {#step-11}
+
+我們已經建立了 MetaMask 錢包、Alchemy 帳戶,並編寫了我們的智能合約,現在是時候將這三者連接起來了。
+
+每一個從你的虛擬錢包送出的交易都需要用你的私鑰簽名。 為了給予程式這個權限,我們可以把私鑰(還有 Alchemy API key)存在環境檔案中。
+
+> 若要深入了解傳送交易,請參閱這篇關於使用 web3 傳送交易的[教學文章](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)。
+
+首先,安裝 dotenv 套件。
+
+```
+npm install dotenv --save
+```
+
+然後,在我們專案的根目錄中建立一個 `.env` 檔案,並在其中新增您的 MetaMask 私鑰和 HTTP Alchemy API URL。
+
+- 遵循[這些說明](https://support.metamask.io/configure/accounts/how-to-export-an-accounts-private-key/)匯出你的私鑰
+- 請參閱下文以取得 HTTP Alchemy API URL
+
+
+
+複製 Alchemy API URL
+
+你的 `.env` 應該看起來像這樣:
+
+```
+API_URL = "https://eth-sepolia.g.alchemy.com/v2/你的-api-金鑰"
+PRIVATE_KEY = "你的-metamask-私鑰"
+```
+
+為了實際將這些連接到我們的程式碼,我們將在第 13 步的 `hardhat.config.js` 檔案中引用這些變數。
+
+
+
+
+不要提交 .env! 請務必不要與任何人分享或洩露您的 .env 檔案,因為這樣做會洩露您的機密。 如果您正在使用版本控制,請將您的 .env 新增到 gitignore 檔案中。
+
+
+
+
+## 第 12 步:安裝 Ethers.js {#step-12-install-ethersjs}
+
+Ethers.js 是一個函式庫,它將[標準 JSON-RPC 方法](/developers/docs/apis/json-rpc/)包裝成更方便使用者使用的方法,讓與以太坊互動和發出請求變得更簡單。
+
+Hardhat 讓整合[外掛程式](https://hardhat.org/plugins/)以取得額外工具和擴充功能變得超級簡單。 我們將利用 [Ethers plugin](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) 進行合約部署 ([Ethers.js](https://github.com/ethers-io/ethers.js/) 有一些非常簡潔的合約部署方法)。
+
+在你的專案目錄輸入:
+
+```
+npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0"
+```
+
+我們也將在下一步的 `hardhat.config.js` 中引入 ethers。
+
+## 第 13 步:更新 hardhat.config.js {#step-13-update-hardhatconfigjs}
+
+我們目前已經新增了幾個相依套件和外掛程式,現在我們需要更新 `hardhat.config.js`,讓我們的專案知道它們全部。
+
+將你的 `hardhat.config.js` 更新成如下所示:
+
+```
+require('dotenv').config();
+
+require("@nomiclabs/hardhat-ethers");
+const { API_URL, PRIVATE_KEY } = process.env;
+
+/**
+* @type import('hardhat/config').HardhatUserConfig
+*/
+module.exports = {
+ solidity: "0.7.3",
+ defaultNetwork: "sepolia",
+ networks: {
+ hardhat: {},
+ sepolia: {
+ url: API_URL,
+ accounts: [`0x${PRIVATE_KEY}`]
+ }
+ },
+}
+```
+
+## 第 14 步:編譯我們的合約 {#step-14-compile-our-contracts}
+
+為了確認一切運作正常,我們來編譯合約。 `compile` 任務是內建的 hardhat 任務之一。
+
+在命令列工具輸入:
+
+```
+npx hardhat compile
+```
+
+你可能會收到關於 `SPDX license identifier not provided in source file` 的警告,但不用擔心——希望其他一切都看起來沒問題! 如果沒有,您隨時可以在 [Alchemy discord](https://discord.gg/u72VCg3) 中傳送訊息。
+
+## 第 15 步:編寫我們的部署腳本 {#step-15-write-our-deploy-scripts}
+
+現在我們已經寫好了合約,並且也搞定配置檔案。現在我們該來撰寫部署合約的腳本。
+
+導覽至 `scripts/` 資料夾並建立一個名為 `deploy.js` 的新檔案,將以下內容加入其中:
+
+```
+async function main() {
+ const HelloWorld = await ethers.getContractFactory("HelloWorld");
+
+ // 開始部署,回傳一個解析為合約物件的 promise
+ const hello_world = await HelloWorld.deploy("Hello World!");
+ console.log("合約已部署至地址:", hello_world.address);}
+
+main()
+ .then(() => process.exit(0))
+ .catch(error => {
+ console.error(error);
+ process.exit(1);
+ });
+```
+
+Hardhat 在其[合約教學文章](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)中詳細地解釋了每一行程式碼的作用,我們在此採用了他們的解釋。
+
+```
+const HelloWorld = await ethers.getContractFactory("HelloWorld");
+```
+
+ethers.js 中的 `ContractFactory` 是用於部署新智能合約的抽象,因此這裡的 `HelloWorld` 是我們 hello world 合約實例的工廠。 使用 `hardhat-ethers` 外掛程式時,`ContractFactory` 和 `Contract` 實例預設會連接到第一個簽署者。
+
+```
+const hello_world = await HelloWorld.deploy();
+```
+
+在 `ContractFactory` 上呼叫 `deploy()` 將開始部署,並回傳一個解析為 `Contract` 的 `Promise`。 這就是和我們的智慧型合約函數有一對一的方法的物件。
+
+## 第 16 步:部署我們的合約 {#step-16-deploy-our-contract}
+
+我們終於準備好要部署合約了! 導覽至命令列並執行:
+
+```
+npx hardhat run scripts/deploy.js --network sepolia
+```
+
+你會看到像這樣的輸出:
+
+```
+合約已部署至地址:0x6cd7d44516a20882cEa2DE9f205bF401c0d23570
+```
+
+如果我們前往 [Sepolia etherscan](https://sepolia.etherscan.io/) 並搜尋我們的合約地址,我們應該能夠看到它已成功部署。 這個交易執行看起來會像這樣:
+
+
+
+`From` 地址應與你的 MetaMask 帳戶地址相符,而 To 地址會顯示「Contract Creation」,但如果我們點進交易,我們會在 `To` 欄位中看到我們的合約地址:
+
+
+
+恭喜! 你剛剛成功將一個智能合約部署到以太坊鏈了 🎉
+
+為了了解幕後情況,讓我們前往 [Alchemy 儀表板](https://dashboard.alchemyapi.io/explorer)中的「Explorer」分頁。 如果你有多個 Alchemy 應用程式,請務必依應用程式篩選並選擇「Hello World」。
+
+
+在這裡你會看到一些 Hardhat/Ethers 在我們呼叫 `.deploy()` 函式時,在底層為我們發出的 JSON-RPC 呼叫。 這裡要特別提出兩個重要的呼叫,一個是 [`eth_sendRawTransaction`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-send-raw-transaction),這是實際將我們的合約寫入 Sepolia 鏈的請求;另一個是 [`eth_getTransactionByHash`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-get-transaction-by-hash),這是在給定哈希值的情況下讀取我們交易資訊的請求 (這是交易時的典型模式)。 要了解更多關於發送交易的資訊,請查看這篇關於[使用 Web3 發送交易](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)的教學。
+
+本教學的第 1 部分到此結束,在第 2 部分中,我們將實際[與我們的智能合約互動](https://www.alchemy.com/docs/interacting-with-a-smart-contract),方法是更新我們的初始訊息;在第 3 部分中,我們將[把我們的智能合約發布到 Etherscan](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan),這樣每個人都會知道如何與它互動。
+
+**想了解更多關於 Alchemy 的資訊嗎?** 請查看我們的[網站](https://www.alchemy.com/eth)。 不想錯過任何更新嗎? [在此](https://www.alchemy.com/newsletter)訂閱我們的電子報! 也請務必加入我們的 [Discord](https://discord.gg/u72VCg3)。\*\*.
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-implement-an-erc721-market/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-implement-an-erc721-market/index.md
new file mode 100644
index 00000000000..d5df6115c19
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-implement-an-erc721-market/index.md
@@ -0,0 +1,145 @@
+---
+title: 如何導入一ERC-721市場
+description: 如何販售代幣化物件於去中央化訊息版.
+author: "Alberto Cuesta Cañada"
+tags: [ "智能合約", "erc-721", "solidity", "代幣" ]
+skill: intermediate
+lang: zh-tw
+published: 2020-03-19
+source: Hackernoon
+sourceUrl: https://hackernoon.com/how-to-implement-an-erc721-market-1e1a32j9
+---
+
+於此文章, 我們將介紹如何為以太坊區塊鏈程式編輯Craigslist之物件訊息版.
+
+於Gumtree, Ebay 及 Craigslist, 分類訊息版通常由紙本或軟木所組成. 此為分類訊息版於學校走廊, 報紙, 跑馬燈, 及店面廣告.
+
+此全部因網路之導入而大幅改變. 能看見特殊分類訊息版的人數因網路而大幅提升. 與此, 市場代表將成為更加有效率且能夠擴張至全球範圍. Ebay為一龐大事業且其原始商業模式源於此實體分類訊息版模式.
+
+區塊鏈技術能使其市場再次改變. 讓我們來看看此如何發生.
+
+## 營利 {#monetization}
+
+一基於公共區塊鏈之商業模式的分類訊息版將與Ebay及其他公司看起來大大不同.
+
+首先,從[去中心化的角度](/developers/docs/web2-vs-web3/)來看。 既有平台需要來維持其擁有服務. 一去中央化平台是由其用戶所維持, 所以就平台持有者之角度來看, 運作平台核心之成本費用降至幾乎為零.
+
+然後我們必須考慮前端介面, 網站及用戶介面提供訪問平台之機會. 以下為許多選項. 此平台持有者能夠限制介面訪問權並索取費用. 平台擁有者也可以決定開放存取權限 (權力歸於人民!) 並讓任何人為平台建構介面。 或平台持有者能夠做出處於前兩選項之間之綜合選擇.
+
+_商業領導人具廣泛視野將知道如何商業化此. 目前我們所能視的為, 此與現狀不同, 且其可能有利可圖._
+
+甚至, 其具自動化功能及多種支付角度來檢視問題. 有些東西可以非常[有效地代幣化](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com),並在分類廣告板上交易。 代幣化資產能簡單被交易於區塊鏈中. 高強度支付手段能被簡單導入至一區塊鏈.
+
+聞到商業機會了嗎? 一分類訊息版無一運作成本並能被簡單導入, 包括複雜支付方案於各類交易. 我們很確定未來將會有更多有趣創想來更加擴張此用途.
+
+我們只是很高興能建造此. 來一起看看其程式程式碼吧.
+
+## 實作 {#implementation}
+
+不久前,我們啟動了一個[開源儲存庫](https://github.com/HQ20/contracts?ref=hackernoon.com),其中包含商業案例的實作範例和其他好東西,歡迎查看。
+
+這個 [以太坊分類廣告板](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) 的程式碼就在那裡,請盡情使用。 只是請小心某些程式還未被完全審核, 所以你需謹慎檢查研究當投資資產於此.
+
+分類訊息版之基礎核心其實相當簡單. 所有廣告於分類版為建構於以下幾行字段:
+
+```solidity
+struct Trade {
+ address poster;
+ uint256 item;
+ uint256 price;
+ bytes32 status; // Open, Executed, Cancelled
+}
+```
+
+所以當某人公開此一廣告. item為販售物件. price為物件價格. status表示物件狀態為公開, 執行, 或取消.
+
+所有交易將被管理於一擬地圖/mapping結構. 因為所有物件於Solidity需要被標示類似地圖映射. 加上此管理類型十分方便.
+
+```solidity
+mapping(uint256 => Trade) public trades;
+```
+
+使用一mapping代表我們需要設置一id來為所有想公開之廣告, 而我們也須事前瞭解一廣告id來實際執行此. 其有多種類型方案來處理此於智慧型合約或前端介面. 如你有任何不明點, 請自由發問或查看相關幫助資訊.
+
+接下來我們須考慮和物件需要被處理, 並指定其支付貨幣為何.
+
+對於這些項目,我們只要求它們實作 [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com) 介面,這實際上只是在區塊鏈中表示現實世界物品的一種方式,儘管它[最適用於數位資產](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com)。 我們將必須創建一ERC-721合約於建立架構, 代表其任何資產於分類訊息版需要事前被代幣化.
+
+為所有支付, 我們需要進行一類似之程序. 大多數區塊鏈專案都定義了自己的 [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com) 加密貨幣。 有些傾向使用主流選項如DAI. 於此分類資訊版, 你需要來決定你加密貨幣之建立基礎架構為何. 簡單吧.
+
+```solidity
+constructor (
+ address _currencyTokenAddress, address _itemTokenAddress
+) public {
+ currencyToken = IERC20(_currencyTokenAddress);
+ itemToken = IERC721(_itemTokenAddress);
+ tradeCounter = 0;
+}
+```
+
+就快到了!! 我們有了廣告, 交易物件, 及支付貨幣. 來建立一廣告代表需要放置資產於質押狀態, 以顯示你確實擁有此並無雙重公開此於其他分類訊息版.
+
+以下程式運作此質押功能. 放置物件於質押, 創建一廣告, 做些記帳操作.
+
+```solidity
+function openTrade(uint256 _item, uint256 _price)
+ public
+{
+ itemToken.transferFrom(msg.sender, address(this), _item);
+ trades[tradeCounter] = Trade({
+ poster: msg.sender,
+ item: _item,
+ price: _price,
+ status: "Open"
+ });
+ tradeCounter += 1;
+ emit TradeStatusChange(tradeCounter - 1, "Open");
+}
+```
+
+來接收交易代表選擇一廣告(交易), 支付其價格, 並接收物件. 此程式代表獲取一交易. 查看其是否為可供用狀態. 支付物件價格. 獲取物件. 更新廣告狀態.
+
+```solidity
+function executeTrade(uint256 _trade)
+ public
+{
+ Trade memory trade = trades[_trade];
+ require(trade.status == "Open", "Trade is not Open.");
+ currencyToken.transferFrom(msg.sender, trade.poster, trade.price);
+ itemToken.transferFrom(address(this), msg.sender, trade.item);
+ trades[_trade].status = "Executed";
+ emit TradeStatusChange(_trade, "Executed");
+}
+```
+
+最終, 我們將具一功能使賣家能於買家接收前退出交易. 於一些模式, 廣告將於過期前存留一段時間. 你的選擇, 基於你市場之設計.
+
+此程式非常類似於執行一交易, 不過此不具交換貨幣, 且物件回返至廣告公布者.
+
+```solidity
+function cancelTrade(uint256 _trade)
+ public
+{
+ Trade memory trade = trades[_trade];
+ require(
+ msg.sender == trade.poster,
+ "交易只能由張貼者取消。"
+ );
+ require(trade.status == "Open", "交易未開啟。");
+ itemToken.transferFrom(address(this), trade.poster, trade.item);
+ trades[_trade].status = "Cancelled";
+ emit TradeStatusChange(_trade, "Cancelled");
+}
+```
+
+此為全部程式碼!! 你以完成所有所需導入步驟. 此為非常驚人當一些商業概念被表達於程式程式碼, 而以上為其中一範例. 請在[我們的儲存庫](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol)中查看完整的合約。
+
+## 結論 {#conclusion}
+
+分類信息板是一種常見商業模式, 其於網路技術之幫助下, 大規模擴張的市場結構, 但此也是一種容易形成少數壟斷贏家的非常流行的商業模式.
+
+分類信息板也恰好是在區塊鏈環境中容易進行複制的一種簡單工具, 其具有可以挑戰現有的巨頭的非常具體之功能.
+
+在本文中,我們嘗試將分類信息板的商業業務與技術實現共同進行講解. 如果你擁有合適的技能, 這些知識應該可以幫助你創建願景及實施路線藍圖.
+
+一如往常,如果您想打造一些有趣的專案並需要一些建議,請[與我聯絡](https://albertocuesta.es/)! 我們隨時樂意幫助你.
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-mint-an-nft/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-mint-an-nft/index.md
new file mode 100644
index 00000000000..a6c6a56fff2
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-mint-an-nft/index.md
@@ -0,0 +1,329 @@
+---
+title: 如何鑄造 NFT (NFT 教學系列 2/3)
+description: 本教學說明如何在以太坊區塊鏈上,使用我們的智能合約和 Web3 來鑄造 NFT。
+author: "Sumi Mudgil"
+tags: [ "ERC-721", "alchemy", "穩固", "智能合約" ]
+skill: beginner
+lang: zh-tw
+published: 2021-04-22
+---
+
+[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html):6900 萬美元
+[3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b):1100 萬美元
+[Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens):600 萬美元
+
+他們全都使用 Alchemy 強大的 API 鑄造了他們的 NFT。 在本教學中,我們將教您如何在 \<10 分鐘內完成同樣的操作。
+
+「鑄造 NFT」是在區塊鏈上發佈您 ERC-721 代幣的獨特實例的行為。 使用我們在 [本 NFT 教學系列第 1 部分](/developers/tutorials/how-to-write-and-deploy-an-nft/) 中的智能合約,讓我們大展 Web3 身手,鑄造一個 NFT。 在本教學結束時,您將能夠鑄造您內心 (和錢包) 渴望的任意數量 NFT!
+
+讓我們開始吧!
+
+## 第 1 步:安裝 Web3 {#install-web3}
+
+如果您跟隨了關於創建 NFT 智能合約的第一個教學,那麼您已經有使用 Ethers.js 的經驗了。 Web3 與 Ethers 類似,它是一個函式庫,可用來更輕鬆地向以太坊區塊鏈發出請求。 在本教學中,我們將使用 [Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3),這是一個增強型的 Web3 函式庫,提供自動重試和穩健的 WebSocket 支援。
+
+在您的專案主目錄中執行:
+
+```
+npm install @alch/alchemy-web3
+```
+
+## 第 2 步:建立 `mint-nft.js` 檔案 {#create-mintnftjs}
+
+在您的 scripts 目錄中,建立一個 `mint-nft.js` 檔案並新增以下程式碼:
+
+```js
+require("dotenv").config()
+const API_URL = process.env.API_URL
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(API_URL)
+```
+
+## 第 3 步:取得您的合約 ABI {#contract-abi}
+
+我們的合約 ABI (應用程式二進位介面) 是與我們的智能合約互動的介面。 您可以在[此處](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is)深入了解合約 ABI。 Hardhat 會自動為我們產生一個 ABI,並將其儲存在 `MyNFT.json` 檔案中。 為了使用它,我們需要將以下程式碼新增至我們的 `mint-nft.js` 檔案來解析內容:
+
+```js
+const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json")
+```
+
+如果您想查看 ABI,可以將其輸出到您的主控台:
+
+```js
+console.log(JSON.stringify(contract.abi))
+```
+
+若要執行 `mint-nft.js` 並在主控台中查看您的 ABI,請前往您的終端機並執行:
+
+```js
+node scripts/mint-nft.js
+```
+
+## 第 4 步:使用 IPFS 設定 NFT 的元數據 {#config-meta}
+
+如果您還記得我們在第 1 部分的教學,我們的 `mintNFT` 智能合約函數會接收一個 `tokenURI` 參數,該參數應解析為一個描述 NFT 元數據的 JSON 文件 — 元數據是真正賦予 NFT 生命的東西,允許它擁有可設定的屬性,例如名稱、描述、圖片和其他屬性。
+
+> _星際檔案系統 (IPFS) 是一種去中心化協定和點對點網路,用於在分散式檔案系統中儲存和共享資料。_
+
+我們將使用 Pinata 這個方便的 IPFS API 和工具組,來儲存我們的 NFT 資產和元數據,以確保我們的 NFT 是真正去中心化的。 如果您沒有 Pinata 帳戶,請[在此](https://app.pinata.cloud)註冊一個免費帳戶,並完成步驟來驗證您的電子郵件。
+
+建立帳戶後:
+
+- 前往「檔案」頁面,然後點擊頁面左上方的藍色「上傳」按鈕。
+
+- 將圖片上傳到 Pinata — 這將是您 NFT 的圖片資產。 您可以隨意為資產命名。
+
+- 上傳後,您會在「檔案」頁面的表格中看到檔案資訊。 您還會看到一個 CID 欄位。 您可以點擊旁邊的複製按鈕來複製 CID。 您可以在 `https://gateway.pinata.cloud/ipfs/` 查看您上傳的內容。 例如,您可以在[此處](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5)找到我們在 IPFS 上使用的圖片。
+
+為方便視覺型學習者,以上步驟總結如下:
+
+
+
+現在,我們要再上傳一份文件到 Pinata。 但在這麼做之前,我們需要先建立它!
+
+在您的根目錄中,建立一個名為 `nft-metadata.json` 的新檔案,並新增以下 json 程式碼:
+
+```json
+{
+ "attributes": [
+ {
+ "trait_type": "品種",
+ "value": "瑪爾濟斯貴賓犬"
+ },
+ {
+ "trait_type": "眼睛顏色",
+ "value": "摩卡色"
+ }
+ ],
+ "description": "全世界最可愛、最敏感的小狗。",
+ "image": "ipfs://QmWmvTJmJU3pozR9ZHFmQC2DNDwi2XJtf3QGyYiiagFSWb",
+ "name": "Ramses"
+}
+```
+
+您可以隨意變更 json 中的資料。 您可以移除或新增屬性區段。 最重要的是,請確保圖片欄位指向您 IPFS 圖片的位置 — 否則,您的 NFT 將包含一張 (非常可愛的!) 狗的照片。 狗。
+
+完成編輯 JSON 檔案後,儲存並上傳到 Pinata,步驟與我們上傳圖片時相同。
+
+
+
+## 第 5 步:建立您合約的實例 {#instance-contract}
+
+現在,為了與我們的合約互動,我們需要在程式碼中建立它的實例。 為此,我們需要我們的合約地址,可以從部署中取得,或透過 [Blockscout](https://eth-sepolia.blockscout.com/) 查詢您用來部署合約的地址來取得。
+
+
+
+在上面的範例中,我們的合約地址是 0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778。
+
+接下來,我們將使用 Web3 的[合約方法](https://docs.web3js.org/api/web3-eth-contract/class/Contract),利用 ABI 和地址來建立我們的合約。 在您的 `mint-nft.js` 檔案中,新增以下內容:
+
+```js
+const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
+
+const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
+```
+
+## 第 6 步:更新 `.env` 檔案 {#update-env}
+
+現在,為了建立交易並傳送到以太坊鏈,我們將使用您的公開以太坊帳戶地址來取得帳戶 nonce (稍後會解釋)。
+
+將您的公鑰新增到 `.env` 檔案 — 如果您完成了教學的第 1 部分,我們的 `.env` 檔案現在應該會像這樣:
+
+```js
+API_URL = "https://eth-sepolia.g.alchemy.com/v2/your-api-key"
+PRIVATE_KEY = "your-private-account-address"
+PUBLIC_KEY = "your-public-account-address"
+```
+
+## 第 7 步:建立您的交易 {#create-txn}
+
+首先,我們來定義一個名為 `mintNFT(tokenData)` 的函式,並透過以下步驟建立我們的交易:
+
+1. 從 `.env` 檔案中取得您的 _PRIVATE_KEY_ 和 _PUBLIC_KEY_。
+
+2. 接下來,我們需要找出帳戶 nonce。 nonce 規範是用來追蹤從您的地址傳送的交易數量 — 我們需要它來確保安全並防止[重放攻擊](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce)。 若要取得從您的地址傳送的交易數量,我們使用 [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount)。
+
+3. 最後,我們將使用以下資訊來設定我們的交易:
+
+- `'from': PUBLIC_KEY` — 我們交易的來源是我們的公開地址
+
+- `'to': contractAddress` — 我們希望與之互動並傳送交易的合約
+
+- `'nonce': nonce` — 帳戶 nonce,其中包含從我們地址傳送的交易數量
+
+- `'gas': estimatedGas` — 完成交易預計所需的 Gas
+
+- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` — 我們希望在此交易中執行的運算 — 在本例中是鑄造一個 NFT
+
+您的 `mint-nft.js` 檔案現在應該會像這樣:
+
+```js
+ require('dotenv').config();
+ const API_URL = process.env.API_URL;
+ const PUBLIC_KEY = process.env.PUBLIC_KEY;
+ const PRIVATE_KEY = process.env.PRIVATE_KEY;
+
+ const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
+ const web3 = createAlchemyWeb3(API_URL);
+
+ const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json");
+ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778";
+ const nftContract = new web3.eth.Contract(contract.abi, contractAddress);
+
+ async function mintNFT(tokenURI) {
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); // 取得最新的 nonce
+
+ // 交易
+ const tx = {
+ 'from': PUBLIC_KEY,
+ 'to': contractAddress,
+ 'nonce': nonce,
+ 'gas': 500000,
+ 'data': nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI()
+ };
+ }
+```
+
+## 第 8 步:簽署交易 {#sign-txn}
+
+既然我們已經建立了交易,就需要簽署它才能將其傳送出去。 這就是我們要使用私鑰的地方。
+
+`web3.eth.sendSignedTransaction` 會提供給我們交易哈希,我們可以用它來確保我們的交易已被挖出,且沒有被網路丟棄。 您會注意到,在交易簽署部分,我們新增了一些錯誤檢查,以便我們知道交易是否成功完成。
+
+```js
+require("dotenv").config()
+const API_URL = process.env.API_URL
+const PUBLIC_KEY = process.env.PUBLIC_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(API_URL)
+
+const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json")
+const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
+const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
+
+async function mintNFT(tokenURI) {
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") // 取得最新的 nonce
+
+ // 交易
+ const tx = {
+ from: PUBLIC_KEY,
+ to: contractAddress,
+ nonce: nonce,
+ gas: 500000,
+ data: nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI(),
+ }
+
+ const signPromise = web3.eth.accounts.signTransaction(tx, PRIVATE_KEY)
+ signPromise
+ .then((signedTx) => {
+ web3.eth.sendSignedTransaction(
+ signedTx.rawTransaction,
+ function (err, hash) {
+ if (!err) {
+ console.log(
+ "您的交易哈希為:",
+ hash,
+ "\n請查看 Alchemy 的 Mempool 以檢視您交易的狀態!"
+ )
+ } else {
+ console.log(
+ "提交您的交易時發生錯誤:",
+ err
+ )
+ }
+ }
+ )
+ })
+ .catch((err) => {
+ console.log(" 承諾失敗:", err)
+ })
+}
+```
+
+## 第 9 步:呼叫 `mintNFT` 並執行 node `mint-nft.js` {#call-mintnft-fn}
+
+還記得您上傳到 Pinata 的 `metadata.json` 嗎? 從 Pinata 取得其哈希碼,並將以下內容作為參數傳遞給 `mintNFT` 函式 `https://gateway.pinata.cloud/ipfs/`
+
+以下是如何取得哈希碼:
+
+_如何在 Pinata 上取得您的 nft 元數據哈希碼_
+
+> 透過在獨立視窗中載入 `https://gateway.pinata.cloud/ipfs/`,再次確認您複製的哈希碼連結到您的 **metadata.json**。 頁面應與下方的螢幕截圖類似:
+
+_您的頁面應顯示 json 元數據_
+
+總而言之,您的程式碼看起來應該像這樣:
+
+```js
+require("dotenv").config()
+const API_URL = process.env.API_URL
+const PUBLIC_KEY = process.env.PUBLIC_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(API_URL)
+
+const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json")
+const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
+const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
+
+async function mintNFT(tokenURI) {
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") // 取得最新的 nonce
+
+ // 交易
+ const tx = {
+ from: PUBLIC_KEY,
+ to: contractAddress,
+ nonce: nonce,
+ gas: 500000,
+ data: nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI(),
+ }
+
+ const signPromise = web3.eth.accounts.signTransaction(tx, PRIVATE_KEY)
+ signPromise
+ .then((signedTx) => {
+ web3.eth.sendSignedTransaction(
+ signedTx.rawTransaction,
+ function (err, hash) {
+ if (!err) {
+ console.log(
+ "您的交易哈希為:",
+ hash,
+ "\n請查看 Alchemy 的 Mempool 以檢視您交易的狀態!"
+ )
+ } else {
+ console.log(
+ "提交您的交易時發生錯誤:",
+ err
+ )
+ }
+ }
+ )
+ })
+ .catch((err) => {
+ console.log("承諾失敗:", err)
+ })
+}
+
+mintNFT("ipfs://QmYueiuRNmL4MiA2GwtVMm6ZagknXnSpQnB3z2gWbz36hP")
+```
+
+現在,執行 `node scripts/mint-nft.js` 來部署您的 NFT。 幾秒鐘後,您應該會在終端機中看到類似這樣的回應:
+
+ ```
+ 您的交易哈希為:0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8
+
+ 請查看 Alchemy 的 Mempool 以檢視您交易的狀態!
+ ```
+
+接下來,造訪您的 [Alchemy mempool](https://dashboard.alchemyapi.io/mempool) 查看您交易的狀態 (無論是待處理、已挖出或被網路丟棄)。 如果您的交易被丟棄,查看 [Blockscout](https://eth-sepolia.blockscout.com/) 並搜尋您的交易哈希也會有幫助。
+
+_在 Etherscan 上檢視您的 NFT 交易哈希_
+
+就這樣! 您現在已經在以太坊區塊鏈上部署並鑄造了一個 NFT
+
+使用 `mint-nft.js`,您可以隨心所欲 (錢包也允許的話) 地鑄造任意數量的 NFT! 只要確保傳入一個新的 tokenURI 來描述 NFT 的元數據即可 (否則,您最終只會製造出一堆 ID 不同但內容相同的 NFT)。
+
+想必您會希望能在錢包中展示您的 NFT — 所以請務必查看 [第 3 部分:如何在您的錢包中檢視您的 NFT](/developers/tutorials/how-to-view-nft-in-metamask/)!
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md
new file mode 100644
index 00000000000..308a79fee66
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md
@@ -0,0 +1,102 @@
+---
+title: 如何模擬 Solidity 智能合約進行測試
+description: 為什麼在測試時應該要取笑你的合約
+author: Markus Waas
+lang: zh-tw
+tags: [ "穩固", "智能合約", "測試", "模擬" ]
+skill: intermediate
+published: 2020-05-02
+source: soliditydeveloper.com
+sourceUrl: https://soliditydeveloper.com/mocking-contracts
+---
+
+[模擬物件](https://wikipedia.org/wiki/Mock_object) 是物件導向編程中一種常見的設計模式。 這個詞源自古法語單字「mocquer」,意思是「取笑」,後來演變成「模仿真實的東西」,這正是我們在編程中所做的事。 如果你想的話,可以盡情取笑你的智能合約,但只要可以,就請模擬它們。 這能讓你的日子更輕鬆。
+
+## 使用模擬進行合約的單元測試 {#unit-testing-contracts-with-mocks}
+
+模擬合約基本上是指建立該合約的第二個版本,其行為與原始版本非常相似,但開發者能輕易控制其行為。 你經常會遇到複雜的合約,而你只想[對合約的一小部分進行單元測試](/developers/docs/smart-contracts/testing/)。 問題是,如果測試這一小部分需要一個很難達到的特定合約狀態,該怎麼辦?
+
+你可以每次都編寫複雜的測試設定邏輯,將合約帶入所需的狀態,或者你也可以編寫一個模擬。 透過繼承來模擬合約很簡單。 只要建立一個繼承自原始合約的第二個模擬合約即可。 現在你可以為你的模擬覆寫函數。 讓我們來看一個例子。
+
+## 範例:私有 ERC20 {#example-private-erc20}
+
+我們使用一個範例 ERC-20 合約,它有一個初始的私有時間。 擁有者可以管理私有使用者,而且一開始只有這些使用者可以接收代幣。 一旦經過特定時間,所有人都可以使用這些代幣。 如果你感到好奇,我們使用的是新版 OpenZeppelin 合約 v3 中的 [`_beforeTokenTransfer`](https://docs.openzeppelin.com/contracts/5.x/extending-contracts#using-hooks) 掛鉤。
+
+```solidity
+pragma solidity ^0.6.0;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/access/Ownable.sol";
+
+contract PrivateERC20 is ERC20, Ownable {
+ mapping (address => bool) public isPrivateUser;
+ uint256 private publicAfterTime;
+
+ constructor(uint256 privateERC20timeInSec) ERC20("PrivateERC20", "PRIV") public {
+ publicAfterTime = now + privateERC20timeInSec;
+ }
+
+ function addUser(address user) external onlyOwner {
+ isPrivateUser[user] = true;
+ }
+
+ function isPublic() public view returns (bool) {
+ return now >= publicAfterTime;
+ }
+
+ function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override {
+ super._beforeTokenTransfer(from, to, amount);
+
+ require(_validRecipient(to), "PrivateERC20:無效的接收者");
+ }
+
+ function _validRecipient(address to) private view returns (bool) {
+ if (isPublic()) {
+ return true;
+ }
+
+ return isPrivateUser[to];
+ }
+}
+```
+
+現在讓我們來模擬它。
+
+```solidity
+pragma solidity ^0.6.0;
+import "../PrivateERC20.sol";
+
+contract PrivateERC20Mock is PrivateERC20 {
+ bool isPublicConfig;
+
+ constructor() public PrivateERC20(0) {}
+
+ function setIsPublic(bool isPublic) external {
+ isPublicConfig = isPublic;
+ }
+
+ function isPublic() public view returns (bool) {
+ return isPublicConfig;
+ }
+}
+```
+
+你會收到以下其中一則錯誤訊息:
+
+- `PrivateERC20Mock.sol: TypeError: Overriding function is missing "override" specifier.`
+- `PrivateERC20.sol: TypeError: Trying to override non-virtual function. Did you forget to add "virtual"?.`
+
+由於我們使用的是新版 Solidity 0.6,我們必須為可被覆寫的函數加上 `virtual` 關鍵字,並為進行覆寫的函數加上 `override` 關鍵字。 所以讓我們將這些關鍵字加到兩個 `isPublic` 函數中。
+
+現在,在你的單元測試中,你可以改用 `PrivateERC20Mock`。 當你想在私有使用期間測試其行為時,請使用 `setIsPublic(false)`;同樣地,測試公開使用期間時請用 `setIsPublic(true)`。 當然,在我們的範例中,我們也可以使用[時間輔助工具](https://docs.openzeppelin.com/test-helpers/0.5/api#increase)來相應地更改時間。 但現在模擬的概念應該很清楚了,你可以想像在某些情境下,事情並不像單純推進時間那麼簡單。
+
+## 模擬多個合約 {#mocking-many-contracts}
+
+如果你必須為每一個模擬都建立另一個合約,事情可能會變得很混亂。 如果這困擾著你,你可以看看 [MockContract](https://github.com/gnosis/mock-contract) 函式庫。 它讓你能即時覆寫和改變合約的行為。 然而,它只適用於模擬對另一個合約的呼叫,所以在我們的範例中行不通。
+
+## 模擬的功能可以更強大 {#mocking-can-be-even-more-powerful}
+
+模擬的功能不止於此。
+
+- 新增函數:不僅覆寫特定函數很有用,單純新增額外函數也同樣有用。 一個關於代幣的好例子是,增加一個額外的 `mint` 函數,讓任何使用者都能免費獲得新代幣。
+- 在測試網上使用:當你在測試網上部署和測試你的合約以及去中心化應用程序時,請考慮使用模擬合約。 除非真的有必要,否則請避免覆寫函數。 畢竟,你想要測試的是真實的邏輯。 但舉例來說,新增一個重設函數可能很有用,它可以簡單地將合約狀態重設回初始狀態,而無需重新部署。 當然,你不會想在主網合約中新增這樣的函式。
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
new file mode 100644
index 00000000000..793c1866418
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
@@ -0,0 +1,702 @@
+---
+title: 如何使用 Echidna 測試智能合約
+description: 如何使用 Echidna 自動測試智能合約
+author: "Trailofbits"
+lang: zh-tw
+tags: [ "穩固", "智能合約", "安全性", "測試", "模糊測試" ]
+skill: advanced
+published: 2020-04-10
+source: 建立安全合約
+sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna
+---
+
+## 安裝 {#installation}
+
+Echidna 可透過 docker 或使用預先編譯的二進位檔進行安裝。
+
+### 透過 docker 使用 Echidna {#echidna-through-docker}
+
+```bash
+docker pull trailofbits/eth-security-toolbox
+docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox
+```
+
+_最後一個指令會在可存取您目前目錄的 docker 容器中執行 eth-security-toolbox。 您可以從主機變更檔案,並從 docker 在檔案上執行工具_
+
+在 docker 中執行:
+
+```bash
+solc-select 0.5.11
+cd /home/training
+```
+
+### 二進位檔 {#binary}
+
+[https://github.com/crytic/echidna/releases/tag/v1.4.0.0](https://github.com/crytic/echidna/releases/tag/v1.4.0.0)
+
+## 基於屬性的模糊測試簡介 {#introduction-to-property-based-fuzzing}
+
+Echidna 是一款基於屬性的模糊測試器,我們在之前的部落格文章中介紹過 ([1](https://blog.trailofbits.com/2018/03/09/echidna-a-smart-fuzzer-for-ethereum/)、[2](https://blog.trailofbits.com/2018/05/03/state-machine-testing-with-echidna/)、[3](https://blog.trailofbits.com/2020/03/30/an-echidna-for-all-seasons/))。
+
+### 模糊測試 {#fuzzing}
+
+[模糊測試](https://wikipedia.org/wiki/Fuzzing) 是資安社群中一項眾所周知的技術。 它包含產生或多或少隨機的輸入,以尋找程式中的錯誤。 傳統軟體的模糊測試器 (例如 [AFL](http://lcamtuf.coredump.cx/afl/) 或 [LibFuzzer](https://llvm.org/docs/LibFuzzer.html)) 是眾所周知的有效尋找錯誤工具。
+
+除了純粹隨機產生輸入之外,還有許多技術和策略可以產生良好的輸入,包括:
+
+- 從每次執行中取得回饋,並利用它來引導產生過程。 例如,如果一個新產生的輸入導致發現一條新路徑,那麼在其附近產生新的輸入可能是有意義的。
+- 產生符合結構性約束的輸入。 例如,如果您的輸入包含帶有校驗和的標頭,讓模糊測試器產生能驗證校驗和的輸入會更有意義。
+- 使用已知的輸入來產生新的輸入:如果您可以存取大量的有效輸入資料集,您的模糊測試器可以從中產生新的輸入,而無需從頭開始。 這些通常被稱為 _種子_。
+
+### 基於屬性的模糊測試 {#property-based-fuzzing}
+
+Echidna 屬於一類特殊的模糊測試器:基於屬性的模糊測試,其靈感主要來自 [QuickCheck](https://wikipedia.org/wiki/QuickCheck)。 與試圖尋找當機的傳統模糊測試器不同,Echidna 會嘗試破壞使用者定義的不變量。
+
+在智能合約中,不變量是 Solidity 函數,可以表示合約可能達到的任何不正確或無效的狀態,包括:
+
+- 不正確的存取控制:攻擊者成為合約的擁有者。
+- 不正確的狀態機器:在合約暫停時,代幣仍可被轉移。
+- 不正確的算術:使用者可以讓其餘額下溢,並獲得無限的免費代幣。
+
+### 使用 Echidna 測試屬性 {#testing-a-property-with-echidna}
+
+我們將了解如何使用 Echidna 測試智能合約。 目標是以下的智能合約 [`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol):
+
+```solidity
+contract Token{
+ mapping(address => uint) public balances;
+ function airdrop() public{
+ balances[msg.sender] = 1000;
+ }
+ function consume() public{
+ require(balances[msg.sender]>0);
+ balances[msg.sender] -= 1;
+ }
+ function backdoor() public{
+ balances[msg.sender] += 1;
+ }
+}
+```
+
+我們將假設此代幣必須具有以下屬性:
+
+- 任何人最多只能擁有 1000 個代幣
+- 此代幣無法轉移 (它不是 ERC20 代幣)
+
+### 撰寫屬性 {#write-a-property}
+
+Echidna 屬性是 Solidity 函數。 一個屬性必須:
+
+- 沒有參數
+- 如果成功,則返回 `true`
+- 其名稱以 `echidna` 開頭
+
+Echidna 會:
+
+- 自動產生任意交易來測試屬性。
+- 回報任何導致屬性返回 `false` 或拋出錯誤的交易。
+- 在呼叫屬性時捨棄副作用 (亦即,如果屬性改變了一個狀態變數,它會在測試後被捨棄)
+
+以下屬性會檢查呼叫者擁有的代幣數量不超過 1000 個:
+
+```solidity
+function echidna_balance_under_1000() public view returns(bool){
+ return balances[msg.sender] <= 1000;
+}
+```
+
+使用繼承將您的合約與您的屬性分開:
+
+```solidity
+contract TestToken is Token{
+ function echidna_balance_under_1000() public view returns(bool){
+ return balances[msg.sender] <= 1000;
+ }
+ }
+```
+
+[`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol) 實作了該屬性並繼承自該代幣。
+
+### 初始化合約 {#initiate-a-contract}
+
+Echidna 需要一個沒有參數的[建構函式](/developers/docs/smart-contracts/anatomy/#constructor-functions)。 如果您的合約需要特定的初始化,您需要在建構函式中進行。
+
+在 Echidna 中有一些特定的地址:
+
+- `0x00a329c0648769A73afAc7F9381E08FB43dBEA72`,它會呼叫建構函式。
+- `0x10000`、`0x20000` 和 `0x00a329C0648769a73afAC7F9381e08fb43DBEA70`,它們會隨機呼叫其他函數。
+
+在我們目前的範例中,我們不需要任何特定的初始化,因此我們的建構函式是空的。
+
+### 執行 Echidna {#run-echidna}
+
+Echidna 的啟動方式如下:
+
+```bash
+echidna-test contract.sol
+```
+
+如果 contract.sol 包含多個合約,您可以指定目標:
+
+```bash
+echidna-test contract.sol --contract MyContract
+```
+
+### 摘要:測試屬性 {#summary-testing-a-property}
+
+以下總結了 echidna 在我們範例上的執行情況:
+
+```solidity
+contract TestToken is Token{
+ constructor() public {}
+ function echidna_balance_under_1000() public view returns(bool){
+ return balances[msg.sender] <= 1000;
+ }
+ }
+```
+
+```bash
+echidna-test testtoken.sol --contract TestToken
+...
+
+echidna_balance_under_1000: failed!💥
+ Call sequence, shrinking (1205/5000):
+ airdrop()
+ backdoor()
+
+...
+```
+
+Echidna 發現如果呼叫了 `backdoor`,屬性就會被違反。
+
+## 在模糊測試活動中過濾要呼叫的函數 {#filtering-functions-to-call-during-a-fuzzing-campaign}
+
+我們將了解如何過濾要進行模糊測試的函數。
+目標是以下的智能合約:
+
+```solidity
+contract C {
+ bool state1 = false;
+ bool state2 = false;
+ bool state3 = false;
+ bool state4 = false;
+
+ function f(uint x) public {
+ require(x == 12);
+ state1 = true;
+ }
+
+ function g(uint x) public {
+ require(state1);
+ require(x == 8);
+ state2 = true;
+ }
+
+ function h(uint x) public {
+ require(state2);
+ require(x == 42);
+ state3 = true;
+ }
+
+ function i() public {
+ require(state3);
+ state4 = true;
+ }
+
+ function reset1() public {
+ state1 = false;
+ state2 = false;
+ state3 = false;
+ return;
+ }
+
+ function reset2() public {
+ state1 = false;
+ state2 = false;
+ state3 = false;
+ return;
+ }
+
+ function echidna_state4() public returns (bool) {
+ return (!state4);
+ }
+}
+```
+
+這個小範例迫使 Echidna 尋找特定的交易序列來改變一個狀態變數。
+這對於模糊測試器來說很困難 (建議使用像 [Manticore](https://github.com/trailofbits/manticore) 這樣的符號執行工具)。
+我們可以執行 Echidna 來驗證這一點:
+
+```bash
+echidna-test multi.sol
+...
+echidna_state4: passed! 🎉
+Seed: -3684648582249875403
+```
+
+### 過濾函數 {#filtering-functions}
+
+Echidna 很難找到正確的序列來測試此合約,因為兩個重設函數 (`reset1` 和 `reset2`) 會將所有狀態變數設為 `false`。
+然而,我們可以使用一個特殊的 Echidna 功能,將重設函數列入黑名單,或只將 `f`、`g`、
+`h` 和 `i` 函數列入白名單。
+
+要將函數列入黑名單,我們可以使用此設定檔:
+
+```yaml
+filterBlacklist: true
+filterFunctions: ["reset1", "reset2"]
+```
+
+過濾函數的另一種方法是列出白名單中的函數。 為此,我們可以使用此設定檔:
+
+```yaml
+filterBlacklist: false
+filterFunctions: ["f", "g", "h", "i"]
+```
+
+- `filterBlacklist` 預設為 `true`。
+- 過濾將只依名稱進行 (不含參數)。 如果您有 `f()` 和 `f(uint256)`,過濾器 `"f"` 將會匹配這兩個函數。
+
+### 執行 Echidna {#run-echidna-1}
+
+要使用設定檔 `blacklist.yaml` 執行 Echidna:
+
+```bash
+echidna-test multi.sol --config blacklist.yaml
+...
+echidna_state4: failed!💥
+ Call sequence:
+ f(12)
+ g(8)
+ h(42)
+ i()
+```
+
+Echidna 將幾乎立即找到可證偽該屬性的交易序列。
+
+### 摘要:過濾函數 {#summary-filtering-functions}
+
+在模糊測試活動中,Echidna 可以使用以下方式將函數列入黑名單或白名單:
+
+```yaml
+filterBlacklist: true
+filterFunctions: ["f1", "f2", "f3"]
+```
+
+```bash
+echidna-test contract.sol --config config.yaml
+...
+```
+
+Echidna 會根據 `filterBlacklist` 布林值的值,開始一場模糊測試活動,將 `f1`、`f2` 和 `f3` 列入黑名單或只呼叫這些函數。
+
+## 如何使用 Echidna 測試 Solidity 的 assert {#how-to-test-soliditys-assert-with-echidna}
+
+在這個簡短的教學中,我們將展示如何使用 Echidna 來測試合約中的斷言檢查。 假設我們有這樣一個合約:
+
+```solidity
+contract Incrementor {
+ uint private counter = 2**200;
+
+ function inc(uint val) public returns (uint){
+ uint tmp = counter;
+ counter += val;
+ // tmp <= counter
+ return (counter - tmp);
+ }
+}
+```
+
+### 撰寫斷言 {#write-an-assertion}
+
+我們希望確保在返回其差值後,`tmp` 小於或等於 `counter`。 我們可以撰寫一個
+Echidna 屬性,但我們需要將 `tmp` 值儲存在某個地方。 相反地,我們可以使用像這樣的斷言:
+
+```solidity
+contract Incrementor {
+ uint private counter = 2**200;
+
+ function inc(uint val) public returns (uint){
+ uint tmp = counter;
+ counter += val;
+ assert (tmp <= counter);
+ return (counter - tmp);
+ }
+}
+```
+
+### 執行 Echidna {#run-echidna-2}
+
+要啟用斷言失敗測試,請建立一個 [Echidna 設定檔](https://github.com/crytic/echidna/wiki/Config) `config.yaml`:
+
+```yaml
+checkAsserts: true
+```
+
+當我們在 Echidna 中執行此合約時,我們會得到預期的結果:
+
+```bash
+echidna-test assert.sol --config config.yaml
+Analyzing contract: assert.sol:Incrementor
+assertion in inc: failed!💥
+ Call sequence, shrinking (2596/5000):
+ inc(21711016731996786641919559689128982722488122124807605757398297001483711807488)
+ inc(7237005577332262213973186563042994240829374041602535252466099000494570602496)
+ inc(86844066927987146567678238756515930889952488499230423029593188005934847229952)
+
+Seed: 1806480648350826486
+```
+
+如您所見,Echidna 在 `inc` 函數中回報了一些斷言失敗。 每個函數可以新增多個斷言,但 Echidna 無法判斷是哪一個斷言失敗。
+
+### 何時以及如何使用斷言 {#when-and-how-use-assertions}
+
+斷言可以用作明確屬性的替代方案,特別是當要檢查的條件與某個操作 `f` 的正確使用直接相關時。 在一些程式碼之後加入斷言,將強制在它執行後立即進行檢查:
+
+```solidity
+function f(..) public {
+ // 一些複雜的程式碼
+ ...
+ assert (condition);
+ ...
+}
+
+```
+
+相反地,使用明確的 echidna 屬性會隨機執行交易,並且沒有簡單的方法可以強制確切的檢查時機。 仍然可以透過這個變通方法來達成:
+
+```solidity
+function echidna_assert_after_f() public returns (bool) {
+ f(..);
+ return(condition);
+}
+```
+
+然而,這會有一些問題:
+
+- 如果 `f` 被宣告為 `internal` 或 `external`,它會失敗。
+- 不清楚應該使用哪些參數來呼叫 `f`。
+- 如果 `f` 回復,屬性將會失敗。
+
+一般而言,我們建議遵循 [John Regehr 的建議](https://blog.regehr.org/archives/1091) 來使用斷言:
+
+- 在斷言檢查期間不要強制產生任何副作用。 例如:`assert(ChangeStateAndReturn() == 1)`
+- 不要斷言顯而易見的陳述。 例如 `assert(var >= 0)`,其中 `var` 被宣告為 `uint`。
+
+最後,請**不要**使用 `require` 來代替 `assert`,因為 Echidna 將無法偵測到它 (但合約無論如何都會回復)。
+
+### 摘要:斷言檢查 {#summary-assertion-checking}
+
+以下總結了 echidna 在我們範例上的執行情況:
+
+```solidity
+contract Incrementor {
+ uint private counter = 2**200;
+
+ function inc(uint val) public returns (uint){
+ uint tmp = counter;
+ counter += val;
+ assert (tmp <= counter);
+ return (counter - tmp);
+ }
+}
+```
+
+```bash
+echidna-test assert.sol --config config.yaml
+Analyzing contract: assert.sol:Incrementor
+assertion in inc: failed!💥
+ Call sequence, shrinking (2596/5000):
+ inc(21711016731996786641919559689128982722488122124807605757398297001483711807488)
+ inc(7237005577332262213973186563042994240829374041602535252466099000494570602496)
+ inc(86844066927987146567678238756515930889952488499230423029593188005934847229952)
+
+Seed: 1806480648350826486
+```
+
+Echidna 發現如果 `inc` 函數被多次以大參數呼叫,其中的斷言可能會失敗。
+
+## 收集與修改 Echidna 語料庫 {#collecting-and-modifying-an-echidna-corpus}
+
+我們將了解如何使用 Echidna 收集和使用交易語料庫。 目標是以下的智能合約 [`magic.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/magic.sol):
+
+```solidity
+contract C {
+ bool value_found = false;
+ function magic(uint magic_1, uint magic_2, uint magic_3, uint magic_4) public {
+ require(magic_1 == 42);
+ require(magic_2 == 129);
+ require(magic_3 == magic_4+333);
+ value_found = true;
+ return;
+ }
+
+ function echidna_magic_values() public returns (bool) {
+ return !value_found;
+ }
+
+}
+```
+
+這個小範例迫使 Echidna 尋找特定值來改變狀態變數。 這對於模糊測試器來說很困難
+(建議使用像 [Manticore](https://github.com/trailofbits/manticore) 這樣的符號執行工具)。
+我們可以執行 Echidna 來驗證這一點:
+
+```bash
+echidna-test magic.sol
+...
+
+echidna_magic_values: passed! 🎉
+
+Seed: 2221503356319272685
+```
+
+然而,我們仍然可以在執行此模糊測試活動時使用 Echidna 來收集語料庫。
+
+### 收集語料庫 {#collecting-a-corpus}
+
+要啟用語料庫收集,請建立一個語料庫目錄:
+
+```bash
+mkdir corpus-magic
+```
+
+以及一個 [Echidna 設定檔](https://github.com/crytic/echidna/wiki/Config) `config.yaml`:
+
+```yaml
+coverage: true
+corpusDir: "corpus-magic"
+```
+
+現在我們可以執行我們的工具並檢查收集到的語料庫:
+
+```bash
+echidna-test magic.sol --config config.yaml
+```
+
+Echidna 仍然找不到正確的魔術值,但我們可以看看它收集的語料庫。
+例如,其中一個檔案是:
+
+```json
+[
+ {
+ "_gas'": "0xffffffff",
+ "_delay": ["0x13647", "0xccf6"],
+ "_src": "00a329c0648769a73afac7f9381e08fb43dbea70",
+ "_dst": "00a329c0648769a73afac7f9381e08fb43dbea72",
+ "_value": "0x0",
+ "_call": {
+ "tag": "SolCall",
+ "contents": [
+ "magic",
+ [
+ {
+ "contents": [
+ 256,
+ "93723985220345906694500679277863898678726808528711107336895287282192244575836"
+ ],
+ "tag": "AbiUInt"
+ },
+ {
+ "contents": [256, "334"],
+ "tag": "AbiUInt"
+ },
+ {
+ "contents": [
+ 256,
+ "68093943901352437066264791224433559271778087297543421781073458233697135179558"
+ ],
+ "tag": "AbiUInt"
+ },
+ {
+ "tag": "AbiUInt",
+ "contents": [256, "332"]
+ }
+ ]
+ ]
+ },
+ "_gasprice'": "0xa904461f1"
+ }
+]
+```
+
+顯然,這個輸入不會觸發我們屬性中的失敗。 然而,在下一步中,我們將看到如何為此修改它。
+
+### 為語料庫提供種子 {#seeding-a-corpus}
+
+Echidna 需要一些幫助才能處理 `magic` 函數。 我們將複製並修改輸入,為其使用合適的
+參數:
+
+```bash
+cp corpus/2712688662897926208.txt corpus/new.txt
+```
+
+我們將修改 `new.txt` 來呼叫 `magic(42,129,333,0)`。 現在,我們可以重新執行 Echidna:
+
+```bash
+echidna-test magic.sol --config config.yaml
+...
+echidna_magic_values: failed!💥
+ Call sequence:
+ magic(42,129,333,0)
+
+
+Unique instructions: 142
+Unique codehashes: 1
+Seed: -7293830866560616537
+
+```
+
+這一次,它立即發現與該屬性發生了衝突。
+
+## 尋找高 gas 消耗的交易 {#finding-transactions-with-high-gas-consumption}
+
+我們將了解如何使用 Echidna 找到高 gas 消耗的交易。 目標是以下的智能合約:
+
+```solidity
+contract C {
+ uint state;
+
+ function expensive(uint8 times) internal {
+ for(uint8 i=0; i < times; i++)
+ state = state + i;
+ }
+
+ function f(uint x, uint y, uint8 times) public {
+ if (x == 42 && y == 123)
+ expensive(times);
+ else
+ state = 0;
+ }
+
+ function echidna_test() public returns (bool) {
+ return true;
+ }
+
+}
+```
+
+這裡的 `expensive` 可能會有大量的 gas 消耗。
+
+目前,Echidna 總是需要一個屬性來測試:這裡 `echidna_test` 總是返回 `true`。
+我們可以執行 Echidna 來驗證這一點:
+
+```
+echidna-test gas.sol
+...
+echidna_test: passed! 🎉
+
+Seed: 2320549945714142710
+```
+
+### 測量 Gas 消耗 {#measuring-gas-consumption}
+
+要透過 Echidna 啟用 gas 消耗測量,請建立一個設定檔 `config.yaml`:
+
+```yaml
+estimateGas: true
+```
+
+在此範例中,我們還將縮小交易序列的大小,使結果更易於理解:
+
+```yaml
+seqLen: 2
+estimateGas: true
+```
+
+### 執行 Echidna {#run-echidna-3}
+
+建立設定檔後,我們可以像這樣執行 Echidna:
+
+```bash
+echidna-test gas.sol --config config.yaml
+...
+echidna_test: passed! 🎉
+
+f used a maximum of 1333608 gas
+ Call sequence:
+ f(42,123,249) Gas price: 0x10d5733f0a Time delay: 0x495e5 Block delay: 0x88b2
+
+Unique instructions: 157
+Unique codehashes: 1
+Seed: -325611019680165325
+
+```
+
+- 顯示的 gas 是由 [HEVM](https://github.com/dapphub/dapptools/tree/master/src/hevm#hevm-) 提供的估計值。
+
+### 過濾掉減少 Gas 的呼叫 {#filtering-out-gas-reducing-calls}
+
+上方關於**在模糊測試活動中過濾要呼叫的函數**的教學展示了如何
+從您的測試中移除一些函數。
+這對於獲得準確的 gas 估計值至關重要。
+請參考以下範例:
+
+```solidity
+contract C {
+ address [] addrs;
+ function push(address a) public {
+ addrs.push(a);
+ }
+ function pop() public {
+ addrs.pop();
+ }
+ function clear() public{
+ addrs.length = 0;
+ }
+ function check() public{
+ for(uint256 i = 0; i < addrs.length; i++)
+ for(uint256 j = i+1; j < addrs.length; j++)
+ if (addrs[i] == addrs[j])
+ addrs[j] = address(0x0);
+ }
+ function echidna_test() public returns (bool) {
+ return true;
+ }
+}
+```
+
+如果 Echidna 可以呼叫所有函數,它將不易找到高 gas 成本的交易:
+
+```
+echidna-test pushpop.sol --config config.yaml
+...
+pop used a maximum of 10746 gas
+...
+check used a maximum of 23730 gas
+...
+clear used a maximum of 35916 gas
+...
+push used a maximum of 40839 gas
+```
+
+這是因為成本取決於 `addrs` 的大小,且隨機呼叫往往會讓陣列幾乎是空的。
+然而,將 `pop` 和 `clear` 列入黑名單,會給我們帶來好得多的結果:
+
+```yaml
+filterBlacklist: true
+filterFunctions: ["pop", "clear"]
+```
+
+```
+echidna-test pushpop.sol --config config.yaml
+...
+push used a maximum of 40839 gas
+...
+check used a maximum of 1484472 gas
+```
+
+### 摘要:尋找高 gas 消耗的交易 {#summary-finding-transactions-with-high-gas-consumption}
+
+Echidna 可以使用 `estimateGas` 設定選項來尋找高 gas 消耗的交易:
+
+```yaml
+estimateGas: true
+```
+
+```bash
+echidna-test contract.sol --config config.yaml
+...
+```
+
+一旦模糊測試活動結束,Echidna 將回報每個函數具有最大 gas 消耗的序列。
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
new file mode 100644
index 00000000000..fbd7a8f5b04
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
@@ -0,0 +1,515 @@
+---
+title: 如何使用 Manticore 尋找智能合約中的程式錯誤
+description: 如何使用 Manticore 自動尋找智能合約中的程式錯誤
+author: Trailofbits
+lang: zh-tw
+tags: [ "穩固", "智能合約", "安全性", "測試", "正式驗證" ]
+skill: advanced
+published: 2020-01-13
+source: 建立安全合約
+sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore
+---
+
+本教學旨在說明如何使用 Manticore 自動尋找智能合約中的程式錯誤。
+
+## 安裝 {#installation}
+
+Manticore 需要 python 3.6 或以上版本。 可以透過 pip 或使用 docker 安裝。
+
+### 透過 docker 使用 Manticore {#manticore-through-docker}
+
+```bash
+docker pull trailofbits/eth-security-toolbox
+docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox
+```
+
+_最後一個指令會在可存取您目前目錄的 docker 容器中執行 eth-security-toolbox。 您可以從主機變更檔案,並從 docker 在檔案上執行工具_
+
+在 docker 中,執行:
+
+```bash
+solc-select 0.5.11
+cd /home/trufflecon/
+```
+
+### 透過 pip 使用 Manticore {#manticore-through-pip}
+
+```bash
+pip3 install --user manticore
+```
+
+建議使用 solc 0.5.11。
+
+### 執行腳本 {#running-a-script}
+
+若要使用 python 3 執行 python 腳本:
+
+```bash
+python3 script.py
+```
+
+## 動態符號執行簡介 {#introduction-to-dynamic-symbolic-execution}
+
+### 動態符號執行概覽 {#dynamic-symbolic-execution-in-a-nutshell}
+
+動態符號執行 (DSE) 是一種程式分析技術,以高度語意感知的方式探索狀態空間。 這項技術基於「程式路徑」的發現,表示為稱為 `path predicates` (路徑謂詞) 的數學公式。 從概念上講,這項技術分兩步驟對路徑謂詞進行操作:
+
+1. 它們是利用程式輸入的約束條件建構的。
+2. 它們被用來生成程式輸入,從而觸發相關路徑的執行。
+
+這種方法不會產生誤報,因為所有識別出的程式狀態都可以在具體執行期間被觸發。 例如,如果分析發現整數溢位,保證可以重現。
+
+### 路徑謂詞範例 {#path-predicate-example}
+
+為了深入了解 DSE 的工作原理,請參考以下範例:
+
+```solidity
+function f(uint a){
+
+ if (a == 65) {
+ // 存在程式錯誤
+ }
+
+}
+```
+
+由於 `f()` 包含兩個路徑,DSE 將建構兩個不同的路徑謂詞:
+
+- 路徑 1:`a == 65`
+- 路徑 2:`Not (a == 65)`
+
+每個路徑謂詞都是一個數學公式,可以交給所謂的 [SMT 求解器](https://wikipedia.org/wiki/Satisfiability_modulo_theories),求解器會嘗試解出方程式。 對於`路徑 1`,求解器會說可以用 `a = 65` 探索該路徑。 對於`路徑 2`,求解器可以為 `a` 指定任何非 65 的值,例如 `a = 0`。
+
+### 驗證屬性 {#verifying-properties}
+
+Manticore 允許完全控制每個路徑的執行。 因此,它允許您對幾乎任何東西添加任意約束。 這種控制允許在合約上創建屬性。
+
+請參考以下範例:
+
+```solidity
+function unsafe_add(uint a, uint b) returns(uint c){
+ c = a + b; // 沒有溢位保護
+ return c;
+}
+```
+
+這裡函數中只有一個路徑可供探索:
+
+- 路徑 1:`c = a + b`
+
+使用 Manticore,您可以檢查溢位,並將約束添加到路徑謂詞中:
+
+- `c = a + b AND (c < a OR c < b)`
+
+如果能找到 `a` 和 `b` 的一個賦值,使得上述路徑謂詞可行,那就表示您發現了一個溢位。 例如,求解器可以產生輸入 `a = 10, b = MAXUINT256`。
+
+如果您考慮一個修復後的版本:
+
+```solidity
+function safe_add(uint a, uint b) returns(uint c){
+ c = a + b;
+ require(c>=a);
+ require(c>=b);
+ return c;
+}
+```
+
+帶有溢位檢查的相關公式會是:
+
+- `c = a + b AND (c >= a) AND (c=>b) AND (c < a OR c < b)`
+
+這個公式無法求解;換句話說,這**證明**了在 `safe_add` 中,`c` 將永遠增加。
+
+因此,DSE 是一個強大的工具,可以驗證您程式碼上的任意約束。
+
+## 在 Manticore 下執行 {#running-under-manticore}
+
+我們將了解如何使用 Manticore API 探索智能合約。 目標是以下智能合約 [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol):
+
+```solidity
+pragma solidity >=0.4.24 <0.6.0;
+
+contract Simple {
+ function f(uint a) payable public{
+ if (a == 65) {
+ revert();
+ }
+ }
+}
+```
+
+### 執行獨立探索 {#run-a-standalone-exploration}
+
+您可以透過以下指令直接在智能合約上執行 Manticore (`project` 可以是 Solidity 檔案或專案目錄):
+
+```bash
+$ manticore project
+```
+
+您將獲得類似這樣的測試案例輸出 (順序可能會改變):
+
+```
+...
+... m.c.manticore:INFO: Generated testcase No. 0 - STOP
+... m.c.manticore:INFO: Generated testcase No. 1 - REVERT
+... m.c.manticore:INFO: Generated testcase No. 2 - RETURN
+... m.c.manticore:INFO: Generated testcase No. 3 - REVERT
+... m.c.manticore:INFO: Generated testcase No. 4 - STOP
+... m.c.manticore:INFO: Generated testcase No. 5 - REVERT
+... m.c.manticore:INFO: Generated testcase No. 6 - REVERT
+... m.c.manticore:INFO: Results in /home/ethsec/workshops/Automated Smart Contracts Audit - TruffleCon 2018/manticore/examples/mcore_t6vi6ij3
+...
+```
+
+若無額外資訊,Manticore 將使用新的符號交易來探索合約,直到合約中沒有新的路徑可供探索。 Manticore 在一次失敗的交易後 (例如:在 revert 之後) 不會執行新的交易。
+
+Manticore 會將資訊輸出到 `mcore_*` 目錄中。 除此之外,您會在這個目錄中找到:
+
+- `global.summary`:涵蓋範圍和編譯器警告
+- `test_XXXXX.summary`:每個測試案例的涵蓋範圍、最後指令、帳戶餘額
+- `test_XXXXX.tx`:每個測試案例的詳細交易清單
+
+這裡 Manticore 找到了 7 個測試案例,它們對應於 (檔案名稱順序可能會改變):
+
+| | 交易 0 | 交易 1 | 交易 2 | 結果 |
+| :-------------------------------------------------------: | :--: | :------------------------: | -------------------------- | :----: |
+| **test_00000000.tx** | 合約創建 | f(!=65) | f(!=65) | STOP |
+| **test_00000001.tx** | 合約創建 | 遞補函數 | | REVERT |
+| **test_00000002.tx** | 合約創建 | | | RETURN |
+| **test_00000003.tx** | 合約創建 | f(65) | | REVERT |
+| **test_00000004.tx** | 合約創建 | f(!=65) | | STOP |
+| **test_00000005.tx** | 合約創建 | f(!=65) | f(65) | REVERT |
+| **test_00000006.tx** | 合約創建 | f(!=65) | 遞補函數 | REVERT |
+
+_探索摘要 f(!=65) 表示以任何不同於 65 的值呼叫 f。_
+
+如您所見,Manticore 會為每個成功或回復的交易產生唯一的測試案例。
+
+如果您想要快速探索程式碼,請使用 `--quick-mode` 旗標 (它會停用程式錯誤偵測器、Gas 計算...)
+
+### 透過 API 操作智能合約 {#manipulate-a-smart-contract-through-the-api}
+
+本節詳細說明如何透過 Manticore Python API 操作智能合約。 您可以建立副檔名為 `*.py` 的新檔案,並透過將 API 指令 (其基本原理將在下面說明) 加入到這個檔案中來撰寫必要的程式碼,然後使用 `$ python3 *.py` 指令執行它。 您也可以直接在 python 主控台執行以下指令,使用 `$ python3` 指令執行主控台。
+
+### 建立帳戶 {#creating-accounts}
+
+您應該做的第一件事是使用以下指令啟動新的區塊鏈:
+
+```python
+from manticore.ethereum import ManticoreEVM
+
+m = ManticoreEVM()
+```
+
+使用 [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) 建立非合約帳戶:
+
+```python
+user_account = m.create_account(balance=1000)
+```
+
+可以使用 [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract) 部署 Solidity 合約:
+
+```solidity
+source_code = '''
+pragma solidity >=0.4.24 <0.6.0;
+contract Simple {
+ function f(uint a) payable public{
+ if (a == 65) {
+ revert();
+ }
+ }
+}
+'''
+# 啟動合約
+contract_account = m.solidity_create_contract(source_code, owner=user_account)
+```
+
+#### 總結 {#summary}
+
+- 您可以使用 [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) 和 [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract) 建立使用者帳戶和合約帳戶。
+
+### 執行交易 {#executing-transactions}
+
+Manticore 支援兩種類型的交易:
+
+- 原始交易:探索所有函數
+- 具名交易:只探索一個函數
+
+#### 原始交易 {#raw-transaction}
+
+使用 [m.transaction](https://manticore.readthedocs.io/en/latest/evm.html?highlight=transaction#manticore.ethereum.ManticoreEVM.transaction) 執行原始交易:
+
+```python
+m.transaction(caller=user_account,
+ address=contract_account,
+ data=data,
+ value=value)
+```
+
+交易的呼叫者、位址、資料或值可以是具體的或符號性的:
+
+- [m.make_symbolic_value](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_value#manticore.ethereum.ManticoreEVM.make_symbolic_value) 會建立一個符號值。
+- [m.make_symbolic_buffer(size)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_buffer#manticore.ethereum.ManticoreEVM.make_symbolic_buffer) 會建立一個符號位元組陣列。
+
+例如:
+
+```python
+symbolic_value = m.make_symbolic_value()
+symbolic_data = m.make_symbolic_buffer(320)
+m.transaction(caller=user_account,
+ address=contract_address,
+ data=symbolic_data,
+ value=symbolic_value)
+```
+
+如果資料是符號性的,Manticore 將在交易執行期間探索合約的所有函數。 查看 [Hands on the Ethernaut CTF](https://blog.trailofbits.com/2017/11/06/hands-on-the-ethernaut-ctf/) 文章中的遞補函數說明,將有助於了解函數選擇的運作方式。
+
+#### 具名交易 {#named-transaction}
+
+函數可以透過其名稱執行。
+若要從 user_account 以一個符號值和 0 以太幣執行 `f(uint var)`,請使用:
+
+```python
+symbolic_var = m.make_symbolic_value()
+contract_account.f(symbolic_var, caller=user_account, value=0)
+```
+
+如果未指定交易的 `value`,則預設為 0。
+
+#### 摘要 {#summary-1}
+
+- 交易的參數可以是具體的或符號性的
+- 原始交易將探索所有函數
+- 函數可以依其名稱呼叫
+
+### 工作區 {#workspace}
+
+`m.workspace` 是用於所有生成檔案的輸出目錄:
+
+```python
+print("Results are in {}".format(m.workspace))
+```
+
+### 終止探索 {#terminate-the-exploration}
+
+若要停止探索,請使用 [m.finalize()](https://manticore.readthedocs.io/en/latest/evm.html?highlight=finalize#manticore.ethereum.ManticoreEVM.finalize)。 一旦呼叫此方法,就不應再傳送任何交易,Manticore 會為每個探索的路徑產生測試案例。
+
+### 摘要:在 Manticore 下執行 {#summary-running-under-manticore}
+
+將所有先前的步驟放在一起,我們得到:
+
+```python
+from manticore.ethereum import ManticoreEVM
+
+m = ManticoreEVM()
+
+with open('example.sol') as f:
+ source_code = f.read()
+
+user_account = m.create_account(balance=1000)
+contract_account = m.solidity_create_contract(source_code, owner=user_account)
+
+symbolic_var = m.make_symbolic_value()
+contract_account.f(symbolic_var)
+
+print("Results are in {}".format(m.workspace))
+m.finalize() # 停止探索
+```
+
+您可以在 [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) 中找到上述所有程式碼
+
+## 取得擲回路徑 {#getting-throwing-paths}
+
+現在我們將為 `f()` 中引發例外的路徑產生特定輸入。 目標仍然是以下智能合約 [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol):
+
+```solidity
+pragma solidity >=0.4.24 <0.6.0;
+contract Simple {
+ function f(uint a) payable public{
+ if (a == 65) {
+ revert();
+ }
+ }
+}
+```
+
+### 使用狀態資訊 {#using-state-information}
+
+每個執行的路徑都有其區塊鏈的狀態。 一個狀態要麼是就緒的,要麼是被終止的,這意味著它到達了 THROW 或 REVERT 指令:
+
+- [m.ready_states](https://manticore.readthedocs.io/en/latest/states.html#accessing):就緒狀態的清單 (它們沒有執行 REVERT/INVALID)
+- [m.killed_states](https://manticore.readthedocs.io/en/latest/states.html#accessings):被終止的狀態清單
+- [m.all_states](https://manticore.readthedocs.io/en/latest/states.html#accessings):所有狀態
+
+```python
+for state in m.all_states:
+ # 對狀態執行某些操作
+```
+
+您可以存取狀態資訊。 例如:
+
+- `state.platform.get_balance(account.address)`:帳戶的餘額
+- `state.platform.transactions`:交易清單
+- `state.platform.transactions[-1].return_data`:最後一筆交易傳回的資料
+
+最後一筆交易傳回的資料是一個陣列,可以使用 ABI.deserialize 將其轉換為一個值,例如:
+
+```python
+data = state.platform.transactions[0].return_data
+data = ABI.deserialize("uint", data)
+```
+
+### 如何產生測試案例 {#how-to-generate-testcase}
+
+使用 [m.generate_testcase(state, name)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=generate_testcase#manticore.ethereum.ManticoreEVM.generate_testcase) 來產生測試案例:
+
+```python
+m.generate_testcase(state, 'BugFound')
+```
+
+### 摘要 {#summary-2}
+
+- 您可以使用 m.all_states 疊代狀態
+- `state.platform.get_balance(account.address)` 會傳回帳戶的餘額
+- `state.platform.transactions` 會傳回交易清單
+- `transaction.return_data` 是傳回的資料
+- `m.generate_testcase(state, name)` 為狀態產生輸入
+
+### 摘要:取得擲回路徑 {#summary-getting-throwing-path}
+
+```python
+from manticore.ethereum import ManticoreEVM
+
+m = ManticoreEVM()
+
+with open('example.sol') as f:
+ source_code = f.read()
+
+user_account = m.create_account(balance=1000)
+contract_account = m.solidity_create_contract(source_code, owner=user_account)
+
+symbolic_var = m.make_symbolic_value()
+contract_account.f(symbolic_var)
+
+## 檢查執行是否以 REVERT 或 INVALID 結束
+for state in m.terminated_states:
+ last_tx = state.platform.transactions[-1]
+ if last_tx.result in ['REVERT', 'INVALID']:
+ print('Throw found {}'.format(m.workspace))
+ m.generate_testcase(state, 'ThrowFound')
+```
+
+您可以在 [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) 中找到上述所有程式碼
+
+_注意:我們本可以產生一個更簡單的腳本,因為 terminated_state 傳回的所有狀態在其結果中都有 REVERT 或 INVALID:這個範例只是為了示範如何操作 API。_
+
+## 新增約束 {#adding-constraints}
+
+我們將了解如何約束探索。 我們將假設 `f()` 的文件說明該函數永遠不會以 `a == 65` 呼叫,因此任何與 `a == 65` 相關的程式錯誤都不是真正的程式錯誤。 目標仍然是以下智能合約 [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol):
+
+```solidity
+pragma solidity >=0.4.24 <0.6.0;
+contract Simple {
+ function f(uint a) payable public{
+ if (a == 65) {
+ revert();
+ }
+ }
+}
+```
+
+### 運算子 {#operators}
+
+[Operators](https://github.com/trailofbits/manticore/blob/master/manticore/core/smtlib/operators.py) 模組有助於操作約束,它提供了以下等功能:
+
+- Operators.AND,
+- Operators.OR,
+- Operators.UGT (無符號大於),
+- Operators.UGE (無符號大於或等於),
+- Operators.ULT (無符號小於),
+- Operators.ULE (無符號小於或等於)。
+
+若要匯入該模組,請使用以下指令:
+
+```python
+from manticore.core.smtlib import Operators
+```
+
+`Operators.CONCAT` 用於將陣列串接到一個值。 例如,交易的 return_data 需要更改為一個值,以便與另一個值進行檢查:
+
+```python
+last_return = Operators.CONCAT(256, *last_return)
+```
+
+### 約束 {#state-constraint}
+
+您可以全域或針對特定狀態使用約束。
+
+#### 全域約束 {#state-constraint}
+
+使用 `m.constrain(constraint)` 來新增全域約束。
+例如,您可以從一個符號位址呼叫合約,並將此位址限制為特定值:
+
+```python
+symbolic_address = m.make_symbolic_value()
+m.constraint(Operators.OR(symbolic == 0x41, symbolic_address == 0x42))
+m.transaction(caller=user_account,
+ address=contract_account,
+ data=m.make_symbolic_buffer(320),
+ value=0)
+```
+
+#### 狀態約束 {#state-constraint}
+
+使用 [state.constrain(constraint)](https://manticore.readthedocs.io/en/latest/states.html?highlight=StateBase#manticore.core.state.StateBase.constrain) 將約束新增到特定狀態。
+它可用於在探索後約束狀態,以檢查其上的某些屬性。
+
+### 檢查約束 {#checking-constraint}
+
+使用 `solver.check(state.constraints)` 來了解約束是否仍然可行。
+例如,以下將約束 symbolic_value 不等於 65,並檢查狀態是否仍然可行:
+
+```python
+state.constrain(symbolic_var != 65)
+if solver.check(state.constraints):
+ # 狀態可行
+```
+
+### 摘要:新增約束 {#summary-adding-constraints}
+
+將約束新增到先前的程式碼中,我們得到:
+
+```python
+from manticore.ethereum import ManticoreEVM
+from manticore.core.smtlib.solver import Z3Solver
+
+solver = Z3Solver.instance()
+
+m = ManticoreEVM()
+
+with open("example.sol") as f:
+ source_code = f.read()
+
+user_account = m.create_account(balance=1000)
+contract_account = m.solidity_create_contract(source_code, owner=user_account)
+
+symbolic_var = m.make_symbolic_value()
+contract_account.f(symbolic_var)
+
+no_bug_found = True
+
+## 檢查執行是否以 REVERT 或 INVALID 結束
+for state in m.terminated_states:
+ last_tx = state.platform.transactions[-1]
+ if last_tx.result in ['REVERT', 'INVALID']:
+ # 我們不考慮 a == 65 的路徑
+ condition = symbolic_var != 65
+ if m.generate_testcase(state, name="BugFound", only_if=condition):
+ print(f'找到程式錯誤,結果位於 {m.workspace}')
+ no_bug_found = False
+
+if no_bug_found:
+ print(f'未找到程式錯誤')
+```
+
+您可以在 [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) 中找到上述所有程式碼
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
new file mode 100644
index 00000000000..ef87b689b18
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
@@ -0,0 +1,233 @@
+---
+title: 如何使用 Slither 來尋找智能合約漏洞
+description: 如何使用 Slither 自動尋找智能合約中的漏洞
+author: Trailofbits
+lang: zh-tw
+tags: [ "穩固", "智能合約", "安全性", "測試" ]
+skill: advanced
+published: 2020-06-09
+source: 建立安全合約
+sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither
+---
+
+## 如何使用 Slither {#how-to-use-slither}
+
+本教學旨在說明如何使用 Slither 自動尋找智能合約中的漏洞。
+
+- [安裝](#installation)
+- [命令列用法](#command-line)
+- [靜態分析簡介](#static-analysis):靜態分析簡介
+- [API](#api-basics):Python API 說明
+
+## 安裝 {#installation}
+
+Slither 需要 Python >= 3.6。 可以透過 pip 或使用 docker 安裝。
+
+透過 pip 安裝 Slither:
+
+```bash
+pip3 install --user slither-analyzer
+```
+
+透過 docker 安裝 Slither:
+
+```bash
+docker pull trailofbits/eth-security-toolbox
+docker run -it -v "$PWD":/home/trufflecon trailofbits/eth-security-toolbox
+```
+
+_最後一個指令會在可存取您目前目錄的 docker 容器中執行 eth-security-toolbox。 您可以從主機變更檔案,並從 docker 在檔案上執行工具_
+
+在 docker 中,執行:
+
+```bash
+solc-select 0.5.11
+cd /home/trufflecon/
+```
+
+### 執行腳本 {#running-a-script}
+
+若要使用 python 3 執行 python 腳本:
+
+```bash
+python3 script.py
+```
+
+### 命令列 {#command-line}
+
+**命令列與使用者定義的腳本。** Slither 內建一組預先定義的偵測器,可尋找許多常見漏洞。 從命令列呼叫 Slither 將會執行所有偵測器,無需具備靜態分析的詳細知識:
+
+```bash
+slither project_paths
+```
+
+除了偵測器之外,Slither 還透過其 [printers](https://github.com/crytic/slither#printers) 和 [tools](https://github.com/crytic/slither#tools) 具備程式碼審查功能。
+
+使用 [crytic.io](https://github.com/crytic) 來存取私有偵測器和 GitHub 整合功能。
+
+## 靜態分析{#static-analysis}
+
+Slither 靜態分析框架的功能與設計,已在部落格文章 ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/)、[2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) 與一篇 [學術論文](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf) 中有所說明。
+
+靜態分析存在多種類型。 您很可能知道,像 [clang](https://clang-analyzer.llvm.org/) 和 [gcc](https://lwn.net/Articles/806099/) 這類的編譯器都依賴這些研究技術,但它同時也是 ([Infer](https://fbinfer.com/)、[CodeClimate](https://codeclimate.com/)、[FindBugs](http://findbugs.sourceforge.net/) 以及像 [Frama-C](https://frama-c.com/) 和 [Polyspace](https://www.mathworks.com/products/polyspace.html) 這類基於形式化方法的工具的基礎。
+
+在此我們不會詳盡地探討靜態分析技術與研究者。 反之,我們將著重於了解 Slither 的運作原理,以便您能更有效地利用它來尋找漏洞並理解程式碼。
+
+- [程式碼表示法](#code-representation)
+- [程式碼分析](#analysis)
+- [中介表示法](#intermediate-representation)
+
+### 程式碼表示法 {#code-representation}
+
+動態分析推論單一執行路徑,與之相對的是,靜態分析一次推論所有路徑。 為此,它依賴於一種不同的程式碼表示法。 兩種最常見的是抽象語法樹 (AST) 以及控制流程圖 (CFG)。
+
+### 抽象語法樹 (AST) {#abstract-syntax-trees-ast}
+
+每當編譯器解析程式碼時,都會使用 AST。 這或許是執行靜態分析所能依據的最基本結構。
+
+簡而言之,AST 是一種結構化樹,其中通常每個葉節點包含一個變數或一個常數,而內部節點則是運算元或控制流程操作。 請看以下程式碼:
+
+```solidity
+function safeAdd(uint a, uint b) pure internal returns(uint){
+ if(a + b <= a){
+ revert();
+ }
+ return a + b;
+}
+```
+
+對應的 AST 如下圖所示:
+
+
+
+Slither 使用由 solc 匯出的 AST。
+
+雖然 AST 建構簡單,但它是一個巢狀結構。 有時,這並非最直接易於分析的結構。 例如,要識別表達式 `a + b <= a` 中使用的操作,您必須先分析 `<=`,然後再分析 `+`。 常見的方法是使用所謂的「訪問者模式」,此模式會遞迴地遍歷樹狀結構。 Slither 在 [`ExpressionVisitor`](https://github.com/crytic/slither/blob/master/slither/visitors/expression/expression.py) 中包含一個通用的訪問者。
+
+以下程式碼使用 `ExpressionVisitor` 來偵測表達式是否包含加法:
+
+```python
+from slither.visitors.expression.expression import ExpressionVisitor
+from slither.core.expressions.binary_operation import BinaryOperationType
+
+class HasAddition(ExpressionVisitor):
+
+ def result(self):
+ return self._result
+
+ def _post_binary_operation(self, expression):
+ if expression.type == BinaryOperationType.ADDITION:
+ self._result = True
+
+visitor = HasAddition(expression) # expression 是要測試的表達式
+print(f'The expression {expression} has a addition: {visitor.result()}')
+```
+
+### 控制流程圖 (CFG) {#control-flow-graph-cfg}
+
+第二種最常見的程式碼表示法是控制流程圖 (CFG)。 顧名思義,這是一種以圖形為基礎的表示法,它揭示了所有的執行路徑。 每個節點包含一個或多個指令。 圖中的邊代表控制流程操作 (if/then/else、迴圈等)。 我們前述範例的 CFG 如下:
+
+
+
+CFG 是大多數分析所建構於其上的表示法。
+
+還存在許多其他的程式碼表示法。 根據您想要執行的分析,每種表示法各有其優缺點。
+
+### 分析 {#analysis}
+
+您可以使用 Slither 執行的最簡單的分析類型是語法分析。
+
+### 語法分析 {#syntax-analysis}
+
+Slither 可以遍歷程式碼的不同元件及其表示法,以使用類似模式比對的方法來尋找不一致之處和缺陷。
+
+例如,下列偵測器會尋找與語法相關的問題:
+
+- [狀態變數遮蔽](https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing):疊代所有狀態變數,並檢查是否有任何變數遮蔽了繼承合約中的變數 ([state.py#L51-L62](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/shadowing/state.py#L51-L62))
+
+- [不正確的 ERC20 介面](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-erc20-interface):尋找不正確的 ERC20 函式簽章 ([incorrect_erc20_interface.py#L34-L55](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/erc/incorrect_erc20_interface.py#L34-L55))
+
+### 語意分析 {#semantic-analysis}
+
+與語法分析相比,語意分析會更深入地分析程式碼的「意義」。 這個類別包含一些廣泛的分析類型。 它們能產生更強大和有用的結果,但撰寫起來也更複雜。
+
+語意分析被用於最進階的漏洞偵測。
+
+#### 資料相依性分析 {#fixed-point-computation}
+
+如果存在一條路徑,其中 `variable_a` 的值受到 `variable_b` 的影響,則稱變數 `variable_a` 與 `variable_b` 具有資料相依性。
+
+在以下程式碼中,`variable_a` 相依於 `variable_b`:
+
+```solidity
+// ...
+variable_a = variable_b + 1;
+```
+
+歸功於它的中介表示法 (將在後續章節討論),Slither 具備內建的 [資料相依性](https://github.com/crytic/slither/wiki/data-dependency) 分析功能。
+
+資料相依性用法的一個範例可以在 [危險的嚴格相等偵測器](https://github.com/crytic/slither/wiki/Detector-Documentation#dangerous-strict-equalities) 中找到。 在這裡,Slither 會尋找與危險值進行的嚴格相等比較 ([incorrect_strict_equality.py#L86-L87](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L86-L87)),並通知使用者應該使用 `>=` 或 `<=` 而不是 `==`,以防止攻擊者困住合約。 此外,偵測器會將對 `balanceOf(address)` 的呼叫的傳回值視為危險 ([incorrect_strict_equality.py#L63-L64](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L63-L64)),並使用資料相依性引擎來追蹤其用法。
+
+#### 不動點運算 {#fixed-point-computation}
+
+如果您的分析遍歷 CFG 並沿著邊緣進行,您很可能會看到已經訪問過的節點。 例如,如果一個迴圈如下所示:
+
+```solidity
+for(uint i; i < range; ++){
+ variable_a += 1
+}
+```
+
+您的分析將需要知道何時停止。 這裡有兩種主要策略:(1) 在每個節點上疊代有限次數,(2) 計算所謂的「不動點」。 不動點基本上意味著分析此節點不再提供任何有意義的資訊。
+
+不動點使用的一個範例可以在重入偵測器中找到:Slither 探索節點,尋找外部呼叫、寫入和讀取存儲。 一旦達到不動點 ([reentrancy.py#L125-L131](https://github.com/crytic/slither/blob/master/slither/detectors/reentrancy/reentrancy.py#L125-L131)),它會停止探索,並分析結果,透過不同的重入模式 ([reentrancy_benign.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_benign.py)、[reentrancy_read_before_write.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_read_before_write.py)、[reentrancy_eth.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_eth.py)) 來查看是否存在重入。
+
+使用有效率的不動點運算來撰寫分析,需要充分了解分析如何傳播其資訊。
+
+### 中介表示法 {#intermediate-representation}
+
+中介表示法 (IR) 是一種語言,意在使其比原始語言更適合進行靜態分析。 Slither 將 Solidity 轉譯為其自己的 IR:[SlithIR](https://github.com/crytic/slither/wiki/SlithIR)。
+
+如果您只想撰寫基本的檢查,則無需了解 SlithIR。 然而,如果您計劃撰寫進階的語意分析,它將會非常方便。 [SlithIR](https://github.com/crytic/slither/wiki/Printer-documentation#slithir) 和 [SSA](https://github.com/crytic/slither/wiki/Printer-documentation#slithir-ssa) 列印器將幫助您了解程式碼是如何被轉譯的。
+
+## 應用程式介面 (API) 基礎 {#api-basics}
+
+Slither 有一個 API,可讓您探索合約及其函式的基本屬性。
+
+若要載入程式碼庫:
+
+```python
+from slither import Slither
+slither = Slither('/path/to/project')
+
+```
+
+### 探索合約與函式 {#exploring-contracts-and-functions}
+
+一個 `Slither` 物件具有:
+
+- `contracts (list(Contract)`:合約清單
+- `contracts_derived (list(Contract)`:未被其他合約繼承的合約清單 (合約的子集)
+- `get_contract_from_name (str)`:從名稱傳回一個合約
+
+一個 `Contract` 物件具有:
+
+- `name (str)`:合約的名稱
+- `functions (list(Function))`:函式清單
+- `modifiers (list(Modifier))`:修飾符清單
+- `all_functions_called (list(Function/Modifier))`:合約可觸及的所有內部函式清單
+- `inheritance (list(Contract))`:繼承的合約清單
+- `get_function_from_signature (str)`:從簽章傳回一個函式
+- `get_modifier_from_signature (str)`:從簽章傳回一個修飾符
+- `get_state_variable_from_name (str)`:從名稱傳回一個 StateVariable
+
+一個 `Function` 或 `Modifier` 物件具有:
+
+- `name (str)`:函式的名稱
+- `contract (contract)`:宣告函式的合約
+- `nodes (list(Node))`:構成函式/修飾符 CFG 的節點清單
+- `entry_point (Node)`:CFG 的進入點
+- `variables_read (list(Variable))`:已讀取變數的清單
+- `variables_written (list(Variable))`:已寫入變數的清單
+- `state_variables_read (list(StateVariable))`:已讀取狀態變數的清單 (variables\`read 的子集)
+- `state_variables_written (list(StateVariable))`:已寫入狀態變數的清單 (variables\`written 的子集)
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
new file mode 100644
index 00000000000..263d9d02ba9
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
@@ -0,0 +1,81 @@
+---
+title: 如何將 Tellor 設定為您的預言機
+description: 入門指南:將 Tellor 預言機整合至您的協定
+author: "Tellor"
+lang: zh-tw
+tags: [ "穩固", "智能合約", "預言機" ]
+skill: beginner
+published: 2021-06-29
+source: Tellor Docs
+sourceUrl: https://docs.tellor.io/tellor/
+---
+
+隨堂測驗:您的協定即將完成,但需要一個預言機來存取鏈下資料...您該怎麼辦?
+
+## (軟性) 先決條件 {#soft-prerequisites}
+
+本篇文章旨在讓存取預言機資料流的過程盡可能簡單明瞭。 話雖如此,為了專注於預言機的相關內容,我們假設您具備以下程式設計能力。
+
+假設:
+
+- 您會使用終端機
+- 您已安裝 npm
+- 您知道如何使用 npm 來管理相依性
+
+Tellor 是一個已上線且可供執行的開源預言機。 本入門指南將說明如何輕鬆啟用並執行 Tellor,為您的專案提供一個完全去中心化且抗審查的預言機。
+
+## 概覽{#overview}
+
+Tellor 是一個預言機系統,各方可以在系統中請求鏈下資料點 (例如 BTC/USD) 的值,而回報者則會競相將此值新增到鏈上資料庫,此資料庫可供所有以太坊智能合約存取。 此資料庫的輸入內容,由已質押回報者組成的網路保護。 Tellor 利用加密經濟激勵機制,獎勵誠實提交資料的回報者,並透過發行 Tellor 的代幣 Tributes (TRB) 以及爭議機制來懲罰惡意行為者。
+
+在本教學中,我們將介紹:
+
+- 設定您啟用與執行時所需的初始工具組。
+- 逐步解說一個簡單範例。
+- 列出目前可供測試 Tellor 的網路所使用的測試網位址。
+
+## UsingTellor {#usingtellor}
+
+您首先要做的是安裝使用 Tellor 作為預言機所需的基本工具。 使用[此套件](https://github.com/tellor-io/usingtellor) 來安裝 Tellor 使用者合約:
+
+`npm install usingtellor`
+
+安裝後,您的合約就能繼承「UsingTellor」合約中的函式。
+
+太棒了! 現在您已準備好工具,讓我們透過一個簡單的練習來擷取比特幣價格:
+
+### BTC/USD 範例 {#btcusd-example}
+
+繼承 UsingTellor 合約,並將 Tellor 位址作為建構函式引數傳入:
+
+例如:
+
+```solidity
+import "usingtellor/contracts/UsingTellor.sol";
+
+contract PriceContract is UsingTellor {
+ uint256 public btcPrice;
+
+ //此合約現在可以存取 UsingTellor 中的所有函式
+
+constructor(address payable _tellorAddress) UsingTellor(_tellorAddress) public {}
+
+function setBtcPrice() public {
+ bytes memory _b = abi.encode("SpotPrice",abi.encode("btc","usd"));
+ bytes32 _queryId = keccak256(_b);
+
+ uint256 _timestamp;
+ bytes _value;
+
+ (_value, _timestamp) = getDataBefore(_queryId, block.timestamp - 15 minutes);
+
+ btcPrice = abi.decode(_value,(uint256));
+ }
+}
+```
+
+如需完整的合約位址清單,請參閱[此處](https://docs.tellor.io/tellor/the-basics/contracts-reference)。
+
+為方便使用,UsingTellor 儲存庫隨附 [Tellor Playground](https://github.com/tellor-io/TellorPlayground) 合約版本,以簡化整合。 請參閱[此處](https://github.com/tellor-io/sampleUsingTellor#tellor-playground)取得實用函式清單。
+
+若要更穩健地執行 Tellor 預言機,請到[此處](https://github.com/tellor-io/usingtellor/blob/master/README.md)查看可用函式的完整清單。
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-view-nft-in-metamask/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-view-nft-in-metamask/index.md
new file mode 100644
index 00000000000..620d184434e
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-view-nft-in-metamask/index.md
@@ -0,0 +1,33 @@
+---
+title: 如何在您的錢包中檢視 NFT (NFT 教學系列第 3/3 部分)
+description: 本教學說明如何在 MetaMask 上檢視現有的 NFT!
+author: "Sumi Mudgil"
+tags: [ "ERC-721", "Alchemy", "Solidity" ]
+skill: beginner
+lang: zh-tw
+published: 2021-04-22
+---
+
+本教學是 NFT 教學系列的第 3/3 部分,我們將在此檢視我們新鑄造的 NFT。 不過,您也可以透過 MetaMask,將本通用教學應用於任何 ERC-721 代幣,包含在主網或任何測試網上。 如果您想學習如何在以太坊上鑄造自己的 NFT,請參閱[第 1 部分:如何編寫和部署 NFT 智能合約](/developers/tutorials/how-to-write-and-deploy-an-nft)!
+
+恭喜! 您已來到我們 NFT 教學系列中最短也最簡單的部分 — 如何在虛擬錢包中檢視您剛鑄造好的 NFT。 本範例將使用 MetaMask,因為我們在前兩個部分中也是使用它。
+
+先決條件是,您應已在行動裝置上安裝 MetaMask,且其中應包含您鑄造 NFT 時所用的帳戶 — 您可以從 [iOS](https://apps.apple.com/us/app/metamask-blockchain-wallet/id1438144202) 或 [Android](https://play.google.com/store/apps/details?id=io.metamask&hl=en_US&gl=US) 免費取得此應用程式。
+
+## 步驟 1:將您的網路設定為 Sepolia {#set-network-to-sepolia}
+
+在應用程式頂部,按下「錢包」按鈕,之後系統會提示您選取網路。 因為我們的 NFT 是在 Sepolia 網路上鑄造的,所以您需要選取 Sepolia 作為您的網路。
+
+
+
+## 步驟 2:將您的收藏品新增至 MetaMask {#add-nft-to-metamask}
+
+進入 Sepolia 網路後,選取右側的「收藏品」標籤,然後新增您 NFT 的智能合約地址和 ERC-721 代幣 ID — 您應該能根據我們教學第二部分中部署 NFT 的交易哈希,在 Etherscan 上找到這些資訊。
+
+
+
+您可能需要重新整理幾次才能檢視您的 NFT — 但它會在那裡 !
+
+
+
+恭喜! 您已成功鑄造一枚 NFT,現在可以檢視它了! 我們迫不及待想看到您將如何在 NFT 世界中掀起風潮!
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-write-and-deploy-an-nft/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-write-and-deploy-an-nft/index.md
new file mode 100644
index 00000000000..aec3ed00a3a
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-write-and-deploy-an-nft/index.md
@@ -0,0 +1,380 @@
+---
+title: 如何撰寫與部署 NFT (NFT 教學系列第 1/3 部分)
+description: 這篇教學是是一個關於NFT教學系列的文章之一,這將會帶著你一步步地學習如何撰寫與部署一個非同質化代幣 (ERC-721 代幣) 的智慧型合約在以太坊以及星際檔案系統(IPFS) 上
+author: "Sumi Mudgil"
+tags: [ "ERC-721", "Alchemy", "Solidity", "智能合約" ]
+skill: beginner
+lang: zh-tw
+published: 2021-04-22
+---
+
+隨著 NFT 將區塊鏈帶入公眾視野,現在正是您親自了解這股熱潮的絕佳機會,只要在以太坊區塊鏈上發佈您自己的 NFT 合約 (ERC-721 代幣) 即可!
+
+Alchemy 非常自豪能為 NFT 領域中最頂尖的品牌提供技術支援,包括 Makersplace (最近在佳士得拍賣會上以 6900 萬美元創下數位藝術品銷售記錄)、Dapper Labs (NBA Top Shot 和 CryptoKitties 的創造者)、OpenSea (全球最大的 NFT 市場)、Zora、Super Rare、NFTfi、Foundation、Enjin、Origin Protocol、Immutable 等等。
+
+在本教學中,我們將逐步解說如何使用 [MetaMask](https://metamask.io/)、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org/)、[Pinata](https://pinata.cloud/) 和 [Alchemy](https://alchemy.com/signup/eth) 在 Sepolia 測試網上建立與部署 ERC-721 智慧合約(如果您還不了解這些術語的含義,請別擔心——我們會一一解釋!)。
+
+在這個教學的第二部分,我們將會瀏覽如何使用我們的智慧型合約去件至一個NFT,在第三部分我們將解釋如何在MeraMask查閱你的NFT。
+
+當然,如果您在任何時候有任何問題,請隨時到 [Alchemy Discord](https://discord.gg/gWuC7zB) 提問,或造訪 [Alchemy 的 NFT API 文件](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)!
+
+## 第 1 步:連線至以太坊網路 {#connect-to-ethereum}
+
+有很多方法可以向以太坊區塊鏈發出請求,但為了簡化流程,我們將使用 [Alchemy](https://alchemy.com/signup/eth) 的免費帳戶。它是一個區塊鏈開發人員平台與 API,可讓我們在不需執行自有節點的情況下與以太坊鏈進行通訊。
+
+在這個教學裡,我們也將會使用Alchemy的開發者工具監控與分析了解我們的智慧型合約部署方式 如果您還沒有 Alchemy 帳戶,可以點擊[此處](https://alchemy.com/signup/eth)免費註冊。
+
+## 第 2 步:建立您的應用程式 (和 API 金鑰) {#make-api-key}
+
+一旦你已經創建好一個Alchemy的帳戶,你可以通過建立一個程式來生成一個API鑰匙。 這將讓我們能向 Sepolia 測試網發出請求。 如果您想深入了解測試網,請參閱[本指南](https://docs.alchemyapi.io/guides/choosing-a-network)。
+
+1. 將滑鼠移至標題列上方的"Apps"以及點選"Create App"以前往到在你的Alchemy Dashboard 上的"Create App"頁面。
+
+
+
+2. 為您的應用程式命名 (我們選擇「My First NFT!」)、提供簡短描述、在「Chain」欄位選取「Ethereum」,並為您的網路選取「Sepolia」。 自「合併」後,其他測試網皆已棄用。
+
+
+
+3. 點擊「創建程式」然後就好了! 你的程式應該會在下列圖表中出現。
+
+## 第 3 步:建立以太坊帳戶 (地址) {#create-eth-address}
+
+我們需要一個乙太坊帳戶去接收或發送交易。 為此教學,我們將會使用 MetaMask。它是一個在瀏覽器上管理你的乙太坊帳戶地址的虛擬錢包。 如果您想深入了解以太坊上的交易如何運作,請參閱以太坊基金會的[此頁面](/developers/docs/transactions/)。
+
+您可以在[這裡](https://metamask.io/download)免費下載並建立 MetaMask 帳戶。 建立帳戶時,或如果您已有帳戶,請務必在右上角切換至「Sepolia 測試網」(這樣我們就不用處理真實貨幣)。
+
+
+
+## 第 4 步:從水龍頭取得以太幣 {#step-4-add-ether-from-a-faucet}
+
+為了部屬我們的智慧型合約到測試網上,我們將會需要一些假的以太幣(ETH)。 若要取得 ETH,您可以前往由 Alchemy 託管的 [Sepolia Faucet](https://sepoliafaucet.com/),登入並輸入您的帳戶地址,然後點擊「Send Me ETH」。 接著你應蓋到你的MetaMask帳戶確認你的ETH!
+
+## 第 5 步:檢查您的餘額 {#check-balance}
+
+為了再次確認我們的餘額,我們將使用 [Alchemy 的編輯器工具](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) 發出 [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) 請求。 這將會回傳你的錢包裡的餘額。 在你輸入自己的MetaMask帳戶地址,並且點下「寄送請求」後,你理應會看見一個這樣子的回應:
+
+ ```
+ `{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}`
+ ```
+
+> **注意**:此結果以 wei 為單位,而非 ETH。 Wei是一個被用來計算以太最少分數的單位。 「1 eth = 1018 wei」他是這樣轉換的。 所以如果我們轉換0xde0b6b3a7640000到十進制,我們將會獲得1\*1018wei,這剛好是1ETH。
+
+哈! 我們的假錢都在這。
+
+## 第 6 步:初始化我們的專案 {#initialize-project}
+
+首先,我們需要一個資料夾給我們的專案。 前往到你的指令介面(powershell, cmd 或 Terminal) 接著輸入:
+
+ ```
+ mkdir my-nft
+ cd my-nft
+ ```
+
+現在我們已經在我們的專案資料夾底下了,接著我們將會使用npm去初始化我們的專案。 如果您尚未安裝 npm,請遵循[這些指示](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm) (我們也需要 [Node.js](https://nodejs.org/en/download/),所以也請一併下載!)。
+
+ ```
+ npm init
+ ```
+
+你如何回答安裝問題並不重要,這是我們提供的參考:
+
+```json
+ package name: (my-nft)
+ version: (1.0.0)
+ description: My first NFT!
+ entry point: (index.js)
+ test command:
+ git repository:
+ keywords:
+ author:
+ license: (ISC)
+ About to write to /Users/thesuperb1/Desktop/my-nft/package.json:
+
+ {
+ "name": "my-nft",
+ "version": "1.0.0",
+ "description": "My first NFT!",
+ "main": "index.js",
+ "scripts": {
+ "test": "echo \"Error: no test specified\" && exit 1"
+ },
+ "author": "",
+ "license": "ISC"
+ }
+```
+
+同意創建package.json,接著我們已經準備好開始了!
+
+## 第 7 步:安裝 [Hardhat](https://hardhat.org/getting-started/#overview) {#install-hardhat}
+
+Hardhat 是一個開發環境,提供你去編譯、部屬、測試、以及除錯你的以太坊軟體。 它能協助開發人員在部署至即時鏈之前,於本機建立智慧合約和去中心化應用程式。
+
+在我們的 my-nft 專案下執行:
+
+ ```
+ npm install --save-dev hardhat
+ ```
+
+如需更多[安裝指示](https://hardhat.org/getting-started/#overview)的詳細資訊,請查看此頁面。
+
+## 第 8 步:建立 Hardhat 專案 {#create-hardhat-project}
+
+在你的專案資料夾下執行:
+
+ ```
+ npx hardhat
+ ```
+
+你接下來會看到歡迎訊息以及關於你想做什麼的選項。 選擇"create an empty hardhat.config.js":
+
+ ```
+ 888 888 888 888 888
+ 888 888 888 888 888
+ 888 888 888 888 888
+ 8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888
+ 888 888 "88b 888P" d88" 888 888 "88b "88b 888
+ 888 888 .d888888 888 888 888 888 888 .d888888 888
+ 888 888 888 888 888 Y88b 888 888 888 888 888 Y88b.
+ 888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888
+ 👷 Welcome to Hardhat v2.0.11 👷
+ ? What do you want to do? …
+ Create a sample project
+ ❯ Create an empty hardhat.config.js
+ Quit
+ ```
+
+這將會摻生一個 hardhat.config.js file 給我們。
+
+## 第 9 步:新增專案資料夾 {#add-project-folders}
+
+為了保持我們的資料夾的結構性,我們將會創建兩個資料夾。 在你的指令介面返回到到專案資料夾,接著輸入:
+
+ ```
+ mkdir contracts
+ mkdir scripts
+ ```
+
+- contracts/ 是放置我們智慧型合約程式碼的地方
+
+- scripts/ 是我們部屬我們的智慧型合約的地方
+
+## 第 10 步:撰寫我們的合約 {#write-contract}
+
+現在我們的環境已經設定好了,接下來是更令人興奮的部分:_撰寫我們的智慧合約程式碼!_
+
+在您偏好的編輯器中開啟 my-nft 專案 (我們推薦 [VSCode](https://code.visualstudio.com/))。 我們撰寫智慧型合約的語言稱作 Solidity 這將是我們使用去撰寫 MyNFT.sol智慧型合約。
+
+1. 前往 `contracts` 資料夾,並建立一個名為 MyNFT.sol 的新檔案
+
+2. 以下是我們的 NFT 智慧合約程式碼,此程式碼以 [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc721) 函式庫的 ERC-721 實作為基礎。 複製與貼上下面的內容到你的MyNFT.sol檔案。
+
+ ```solidity
+ //合約基於 [https://docs.openzeppelin.com/contracts/3.x/erc721](https://docs.openzeppelin.com/contracts/3.x/erc721)
+ // SPDX-License-Identifier: MIT
+ pragma solidity ^0.8.0;
+
+ import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
+ import "@openzeppelin/contracts/utils/Counters.sol";
+ import "@openzeppelin/contracts/access/Ownable.sol";
+ import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
+
+ contract MyNFT is ERC721URIStorage, Ownable {
+ using Counters for Counters.Counter;
+ Counters.Counter private _tokenIds;
+
+ constructor() ERC721("MyNFT", "NFT") {}
+
+ function mintNFT(address recipient, string memory tokenURI)
+ public onlyOwner
+ returns (uint256)
+ {
+ _tokenIds.increment();
+
+ uint256 newItemId = _tokenIds.current();
+ _mint(recipient, newItemId);
+ _setTokenURI(newItemId, tokenURI);
+
+ return newItemId;
+ }
+ }
+ ```
+
+3. 因為我們繼承了 OpenZeppelin 合約函式庫的類別,所以請在命令列中執行 `npm install @openzeppelin/contracts^4.0.0`,將函式庫安裝至我們的資料夾中。
+
+那麼,這段程式碼的確切功用是什麼? 讓我們拆解他,一行一行解說。
+
+在智慧合約的頂部,我們匯入了三個 [OpenZeppelin](https://openzeppelin.com/) 智慧合約類別:
+
+- @openzeppelin/contracts/token/ERC721/ERC721.sol 包含了ERC-721的執行標準,我們的智慧型合約將會繼承他。 要成為一個有效的非同質化代幣 (NFT),你的智慧型合約必須執行所有在ERR-721標準裡的方法。 若要深入了解繼承的 ERC-721 函式,請參閱[此處](https://eips.ethereum.org/EIPS/eip-721)的介面定義。
+
+- @openzeppelin/contracts/utils/Counters.sol 提供一個儘可以逐一遞減或遞增的計數器。 我們的智慧型合約使用一個計數器去持續追蹤所有NFT的鑄造數與設定一個唯一的ID在每一個新NFT。 (每一個被鑄造的NFT都要用一個智慧型合約分配一個唯一的ID -- 我們的ID在這裡只有使用NFT總數來決定。 舉一個例子,我們鑄造的第一個NFT擁有一個「1」的ID,第二個則是「2」,依此類推。)
+
+- @openzeppelin/contracts/access/Ownable.sol 會在我們的智慧合約上設定[存取權控制](https://docs.openzeppelin.com/contracts/3.x/access-control),如此一來,只有智慧合約的擁有者 (也就是您) 可以鑄造 NFT。 (編註: 包括使用權控制指示一種偏好。 如果你不喜歡有人可以使用你的智慧型合約鑄造NFT,移除在第十行的的"Ownable",以及第17行的"onlyOwner"。)
+
+在引入以上函式庫後,我們有我們傳統的NFT智慧型合約,程式碼意外的短,他只包刮一個計數器,一個構建函數,和一個函式! 這要歸功於我們繼承的 OpenZeppelin 合約,它實作了我們建立 NFT 所需的大部分方法,例如傳回 NFT 擁有者的 `ownerOf`,以及將 NFT 擁有權從一個帳戶轉移至另一個帳戶的 `transferFrom`。
+
+在我們的 ERC-721 的建構函數裡(constractor),你可能會注意到我們傳入了兩個字串,"MyNFT" 和 "NFT"。 第一個變數是智慧型合約名稱,第二個則是他的代號(象徵 symbol)。 你可以為每一個變數命名。
+
+最後,我們有了函式 `mintNFT(address recipient, string memory tokenURI)`,可以用來鑄造 NFT! 你可能會注意到這個函數傳入了兩個變數:
+
+- `address recipient` 會指定接收您剛鑄造好的 NFT 的地址
+
+- `string memory tokenURI` 是一個字串,應解析為描述 NFT 元資料的 JSON 文件。 NFT的後設數據(metadata) 實際上是使其生存的原因,允許它具有可配置的屬性,例如名稱,描述,圖像和其他屬性。 在這個教學的第二部份我們將會解釋如何設定這個後設資料(metadata)。
+
+`mintNFT` 會從繼承的 ERC-721 函式庫呼叫一些方法,並最終傳回一個數字,此數字代表新鑄造的 NFT 的 ID。
+
+## 第 11 步:將 MetaMask 和 Alchemy 連線至您的專案 {#connect-metamask-and-alchemy}
+
+現在,我們已經創建了一個MetaMask錢包、Alchemy帳戶,並編寫了我們的智慧型合約,是時候將這三者連接起來了。
+
+每一個從你的虛擬錢包送出的交易都需要用你的私鑰簽名。 為了給予程式這個權限,我們可以把私鑰(還有 Alchemy API key)存在環境檔案中。
+
+若要深入了解傳送交易,請參閱這篇關於使用 web3 傳送交易的[教學文章](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)。
+
+首先,安裝 dotenv 套件。
+
+ ```
+ npm install dotenv --save
+ ```
+
+然後,在我們專案的根目錄中建立一個 `.env` 檔案,並在其中新增您的 MetaMask 私鑰和 HTTP Alchemy API URL。
+
+- 請遵循[這些指示](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)從 MetaMask 匯出您的私鑰
+
+- 請參見下麵獲取HTTP Alchemy 接口地址並將其複製到剪貼板
+
+
+
+您的 `.env` 檔案現在應該會像這樣:
+
+ ```
+ API_URL="https://eth-sepolia.g.alchemy.com/v2/your-api-key"
+ PRIVATE_KEY="your-metamask-private-key"
+ ```
+
+為了將這些變數實際連線至我們的程式碼,我們會在第 13 步的 hardhat.config.js 檔案中參考這些變數。
+
+
+
+## 第 12 步:安裝 Ethers.js {#install-ethers}
+
+Ethers.js 是一個函式庫,它將[標準 JSON-RPC 方法](/developers/docs/apis/json-rpc/)包裝成更方便使用者使用的方法,讓與以太坊互動和發出請求變得更簡單。
+
+Hardhat 讓整合[外掛程式](https://hardhat.org/plugins/)以取得額外工具和擴充功能變得超級簡單。 我們將利用 [Ethers plugin](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) 進行合約部署 ([Ethers.js](https://github.com/ethers-io/ethers.js/) 有一些非常簡潔的合約部署方法)。
+
+在你的專案目錄輸入:
+
+ ```
+ npm install --save-dev @nomiclabs/hardhat-ethers ethers@^5.0.0
+ ```
+
+我們會在下一步 hardhat.config.js 將 ethers 納入進來。
+
+## 第 13 步:更新 hardhat.config.js {#update-hardhat-config}
+
+我們目前已經新增了幾個套件,現在則是要更新 hardhat.config.js ,告訴專案我們要用它們。
+
+將 hardhat.config.js 更新成如下方:
+
+```js
+ /**
+ * @type import('hardhat/config').HardhatUserConfig
+ */
+ require('dotenv').config();
+ require("@nomiclabs/hardhat-ethers");
+ const { API_URL, PRIVATE_KEY } = process.env;
+ module.exports = {
+ solidity: "0.8.1",
+ defaultNetwork: "sepolia",
+ networks: {
+ hardhat: {},
+ sepolia: {
+ url: API_URL,
+ accounts: [`0x${PRIVATE_KEY}`]
+ }
+ },
+ }
+```
+
+## 第 14 步:編譯我們的合約 {#compile-contract}
+
+為了確認一切運作正常,我們來編譯合約。 編譯任務是安全帽的內部任務之一
+
+在命令列工具輸入:
+
+ ```
+ npx hardhat compile
+ ```
+
+你可能會看到關於“源文件中未提供SPDX許可證識別碼”的警告,但是不用擔心,希望其他的看起來都正常 如果沒有,您隨時可以在 [Alchemy discord](https://discord.gg/u72VCg3) 中傳送訊息。
+
+## 第 15 步:撰寫我們的部署腳本 {#write-deploy}
+
+現在我們已經寫好了合約,並且也搞定配置檔案。現在我們該來撰寫部署合約的腳本。
+
+前往 `scripts/` 資料夾並建立一個名為 `deploy.js` 的新檔案,在其中加入以下內容:
+
+```js
+async function main() {
+ const MyNFT = await ethers.getContractFactory("MyNFT")
+
+ // 開始部署,傳回一個解析為合約物件的 promise
+ const myNFT = await MyNFT.deploy()
+ await myNFT.deployed()
+ console.log("Contract deployed to address:", myNFT.address)
+}
+
+main()
+ .then(() => process.exit(0))
+ .catch((error) => {
+ console.error(error)
+ process.exit(1)
+ })
+```
+
+Hardhat 在其[合約教學文章](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)中詳細地解釋了每一行程式碼的作用,我們在此採用了他們的解釋。
+
+ ```
+ const MyNFT = await ethers.getContractFactory("MyNFT");
+ ```
+
+Ethers.js 中的 ContractFactory 是用於部署新智慧型合約的抽象對象。所以這裡的MyNFT是我們NFT合約實例的工廠 使用 hardhat-ethers 插件时,ContractFactory 和合約實例默認與第一個簽名帳戶相連。
+
+ ```
+ const myNFT = await MyNFT.deploy();
+ ```
+
+調用 ContractFactory 程式碼中的 deploy() 函數會啟動合約部署,然後返回解析為合約的Promise。 這就是和我們的智慧型合約函數有一對一的方法的物件。
+
+## 第 16 步:部署我們的合約 {#deploy-contract}
+
+我們終於準備好要部署合約了! 返回你專案目錄的根目錄,在命令行中於行:
+
+ ```
+ npx hardhat --network sepolia run scripts/deploy.js
+ ```
+
+你會看到像這樣的輸出:
+
+ ```
+ 合約已部署至地址:0x4C5266cCc4b3F426965d2f51b6D910325a0E7650
+ ```
+
+如果我們前往 [Sepolia etherscan](https://sepolia.etherscan.io/) 並搜尋我們的合約地址,我們應該能夠看到它已成功部署。 如果你沒立即看到它,請稍等片刻,因為它可能需要一些時間。 這個交易執行看起來會像這樣:
+
+
+
+「From」地址應與您的 MetaMask 帳戶地址相符,而「To」地址將顯示「Contract Creation」。 如果我們電機進入交易,我們將在“To”字段中看到我們的合約地址:
+
+
+
+太棒了! 您剛剛已將您的 NFT 智慧合約部署到以太坊 (測試網) 鏈上了!
+
+為了了解幕後情況,讓我們前往 [Alchemy 儀表板](https://dashboard.alchemyapi.io/explorer)中的「Explorer」分頁。 如果你有多個Alchemy應用程序,請確保按應用程序篩選,然後選擇“MyNFT”。
+
+
+
+在這裡你會看到Hardhat/Ethers 替我們在後端完成的一系列JSON-RPC調用,當我們調用.deploy() 函數時候。 這裡要特別提出兩個重要的呼叫:[eth_sendRawTransaction](/developers/docs/apis/json-rpc/#eth_sendrawtransaction) 是將我們的智慧合約實際寫入 Sepolia 鏈的請求;[eth_getTransactionByHash](/developers/docs/apis/json-rpc/#eth_gettransactionbyhash) 則是在給定哈希的情況下讀取交易資訊的請求 (這是傳送交易時的典型模式)。 若要深入了解傳送交易,請參閱這篇關於[使用 Web3 傳送交易](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)的教學文章。
+
+以上即為這個教程的第1部分全部內容。 在[第 2 部分,我們將透過鑄造 NFT 來實際與我們的智慧合約互動](/developers/tutorials/how-to-mint-an-nft/),而在[第 3 部分,我們將示範如何在您的以太坊錢包中檢視您的 NFT](/developers/tutorials/how-to-view-nft-in-metamask/)!
diff --git a/public/content/translations/zh-tw/developers/tutorials/interact-with-other-contracts-from-solidity/index.md b/public/content/translations/zh-tw/developers/tutorials/interact-with-other-contracts-from-solidity/index.md
new file mode 100644
index 00000000000..5b4ffe32cc6
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/interact-with-other-contracts-from-solidity/index.md
@@ -0,0 +1,172 @@
+---
+title: 從 Solidity 與其他合約互動
+description: 如何從現有合約部署智能合約並與其互動
+author: "jdourlens"
+tags: [ "智能合約", "穩固", "remix", "部署", "可組合性" ]
+skill: advanced
+lang: zh-tw
+published: 2020-04-05
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/interact-with-other-contracts-from-solidity/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+在先前的教學中,我們學習了許多知識,像是[如何部署您的第一個智能合約](/developers/tutorials/deploying-your-first-smart-contract/),以及為它新增一些功能,例如[使用修飾詞控制存取](https://ethereumdev.io/organize-your-code-and-control-access-to-your-smart-contract-with-modifiers/)或[在 Solidity 中處理錯誤](https://ethereumdev.io/handle-errors-in-solidity-with-require-and-revert/)。 在本教學中,我們將學習如何從現有合約部署智能合約並與其互動。
+
+我們將建立一個名為 `CounterFactory` 的合約工廠,讓任何人都能夠透過它來建立自己的 `Counter` 智能合約。 首先,這是我們初始 `Counter` 智能合約的程式碼:
+
+```solidity
+pragma solidity 0.5.17;
+
+contract Counter {
+
+ uint256 private _count;
+ address private _owner;
+ address private _factory;
+
+
+ modifier onlyOwner(address caller) {
+ require(caller == _owner, "您不是此合約的擁有者");
+ _;
+ }
+
+ modifier onlyFactory() {
+ require(msg.sender == _factory, "您需要使用工廠");
+ _;
+ }
+
+ constructor(address owner) public {
+ _owner = owner;
+ _factory = msg.sender;
+ }
+
+ function getCount() public view returns (uint256) {
+ return _count;
+ }
+
+ function increment(address caller) public onlyFactory onlyOwner(caller) {
+ _count++;
+ }
+
+}
+```
+
+請注意,我們稍微修改了合約程式碼,以便追蹤工廠的地址和合約擁有者的地址。 當您從另一個合約呼叫某合約的程式碼時,`msg.sender` 將會是我們合約工廠的地址。 這是**一個非常重要的理解要點**,因為使用合約與其他合約互動是常見的做法。 因此,在複雜情況下,您應該要留意誰是發送者。
+
+為此,我們也新增了 `onlyFactory` 修飾詞,它能確保改變狀態的函式只能由工廠呼叫,工廠會將原始呼叫者當作參數傳遞。
+
+在我們新的 `CounterFactory`(它會管理所有其他的 Counter)內部,我們會新增一個 mapping,將擁有者與其計數器合約的地址關聯起來:
+
+```solidity
+mapping(address => Counter) _counters;
+```
+
+在以太坊中,映射 (mapping) 相當於 javascript 中的物件,可以將 A 型別的鍵對應到 B 型別的值。在此案例中,我們將擁有者的地址與其 Counter 的實例對應起來。
+
+為某人實例化一個新的 Counter,看起來會像這樣:
+
+```solidity
+ function createCounter() public {
+ require (_counters[msg.sender] == Counter(0));
+ _counters[msg.sender] = new Counter(msg.sender);
+ }
+```
+
+我們首先檢查該使用者是否已擁有一個計數器。 如果該使用者沒有計數器,我們會將其地址傳遞給 `Counter` 建構函式以實例化一個新的計數器,並將新建立的實例指派給 mapping。
+
+要取得特定 Counter 的計數,會像這樣:
+
+```solidity
+function getCount(address account) public view returns (uint256) {
+ require (_counters[account] != Counter(0));
+ return (_counters[account].getCount());
+}
+
+function getMyCount() public view returns (uint256) {
+ return (getCount(msg.sender));
+}
+```
+
+第一個函式會檢查指定地址是否存在 Counter 合約,然後從實例中呼叫 `getCount` 方法。 第二個函式 `getMyCount` 只是個簡潔的作法,直接將 `msg.sender` 傳遞給 `getCount` 函式。
+
+`increment` 函式非常相似,但是它將原始交易的發送者傳遞給 `Counter` 合約:
+
+```solidity
+function increment() public {
+ require (_counters[msg.sender] != Counter(0));
+ Counter(_counters[msg.sender]).increment(msg.sender);
+ }
+```
+
+請注意,如果呼叫太多次,我們的計數器可能會發生溢出。 您應該盡可能使用 [SafeMath 函式庫](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/),以防止這種可能的情況發生。
+
+要部署我們的合約,您將需要提供 `CounterFactory` 和 `Counter` 兩者的程式碼。 例如在 Remix 中部署時,您需要選擇 CounterFactory。
+
+這是完整的程式碼:
+
+```solidity
+pragma solidity 0.5.17;
+
+contract Counter {
+
+ uint256 private _count;
+ address private _owner;
+ address private _factory;
+
+
+ modifier onlyOwner(address caller) {
+ require(caller == _owner, "您不是此合約的擁有者");
+ _;
+ }
+
+ modifier onlyFactory() {
+ require(msg.sender == _factory, "您需要使用工廠");
+ _;
+ }
+
+ constructor(address owner) public {
+ _owner = owner;
+ _factory = msg.sender;
+ }
+
+ function getCount() public view returns (uint256) {
+ return _count;
+ }
+
+ function increment(address caller) public onlyFactory onlyOwner(caller) {
+ _count++;
+ }
+
+}
+
+contract CounterFactory {
+
+ mapping(address => Counter) _counters;
+
+ function createCounter() public {
+ require (_counters[msg.sender] == Counter(0));
+ _counters[msg.sender] = new Counter(msg.sender);
+ }
+
+ function increment() public {
+ require (_counters[msg.sender] != Counter(0));
+ Counter(_counters[msg.sender]).increment(msg.sender);
+ }
+
+ function getCount(address account) public view returns (uint256) {
+ require (_counters[account] != Counter(0));
+ return (_counters[account].getCount());
+ }
+
+ function getMyCount() public view returns (uint256) {
+ return (getCount(msg.sender));
+ }
+
+}
+```
+
+編譯後,在 Remix 的部署區塊中,您將會選擇要部署的工廠:
+
+
+
+然後您可以操作您的合約工廠,並檢查值的變化。 如果您想從不同的地址呼叫智能合約,您需要在 Remix 的帳戶 (Account) 選項中變更地址。
diff --git a/public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md b/public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md
new file mode 100644
index 00000000000..b6fdef3dc81
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md
@@ -0,0 +1,73 @@
+---
+title: 用於去中心化使用者介面的 IPFS
+description: 本使用教學會教讀者如何使用 IPFS 來儲存去中心化應用程式的使用者介面。 儘管應用程式的資料和商業邏輯是去中心化的,但如果沒有抗審查的使用者介面,使用者還是可能會失去存取權限。
+author: 作者:Ori Pomerantz
+tags: [ "ipfs" ]
+skill: beginner
+lang: zh-tw
+published: 2024-06-29
+---
+
+您寫了一個很棒的全新去中心化應用程式。 您甚至還為它寫了一個[使用者介面](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)。 但現在您擔心有人會透過讓您的使用者介面下線來審查它,而它只是雲端上的一台伺服器。 在本使用教學中,您會學習如何將使用者介面放到\*\*[星際檔案系統 (IPFS)](https://ipfs.tech/developers/)\*\* 上以避免審查,如此一來任何感興趣的人都能將它釘選在伺服器上供未來存取。
+
+您可以使用第三方服務 (例如 [Fleek](https://resources.fleek.xyz/docs/)) 來完成所有工作。 本使用教學適合想要深入了解自己在做什麼的人,即使這代表更多的工作。
+
+## 從本機開始 {#getting-started-locally}
+
+有多個[第三方 IPFS 供應商](https://docs.ipfs.tech/how-to/work-with-pinning-services/#use-a-third-party-pinning-service),但最好從在本機執行 IPFS 開始測試。
+
+1. 安裝 [IPFS 使用者介面](https://docs.ipfs.tech/install/ipfs-desktop/#install-instructions)。
+
+2. 建立一個包含您網站的目錄。 如果您正在使用 [Vite](https://vite.dev/),請使用此命令:
+
+ ```sh
+ pnpm vite build
+ ```
+
+3. 在 IPFS Desktop 中,按一下 **Import > Folder**,然後選擇您在上一步驟中建立的目錄。
+
+4. 選擇您剛上傳的資料夾,然後按一下 **Rename**。 為它取一個更有意義的名稱。
+
+5. 再次選取它,然後按一下 **Share link**。 將 URL 複製到剪貼簿。 連結會與 `https://ipfs.io/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ` 相似。
+
+6. 按一下 **Status**。 展開 **Advanced** 索引標籤以查看閘道器地址。 例如,在我的系統上,地址是 `http://127.0.0.1:8080`。
+
+7. 將連結步驟中的路徑與閘道器地址組合起來,即可找到您的地址。 例如,對於上述範例,URL 為 `http://127.0.0.1:8080/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`。 在瀏覽器中開啟該 URL 以查看您的網站。
+
+## 上傳 {#uploading}
+
+現在您可以使用 IPFS 在本機提供檔案服務,這不是非常令人興奮。 下一步是在您離線時,讓全世界都能使用這些檔案。
+
+有許多知名的[釘選服務](https://docs.ipfs.tech/concepts/persistence/#pinning-services)。 選擇其中一個。 無論您使用哪種服務,都需要建立一個帳戶,並在 IPFS desktop 中提供**內容識別碼 (CID)**。
+
+就我個人而言,我發現 [4EVERLAND](https://docs.4everland.org/storage/4ever-pin/guides) 是最容易使用的。 以下是其使用說明:
+
+1. 瀏覽至[儀表板](https://dashboard.4everland.org/overview)並使用您的錢包登入。
+
+2. 在左側邊欄中,按一下 **Storage > 4EVER Pin**。
+
+3. 按一下 **Upload > Selected CID**。 為您的內容命名,並提供 IPFS desktop 的 CID。 目前 CID 是一個以 `Qm` 開頭的字串,後面跟著 44 個字母和數字,代表一個 [base-58 編碼](https://medium.com/bootdotdev/base64-vs-base58-encoding-c25553ff4524)的哈希,例如 `QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`,但[這很可能會改變](https://docs.ipfs.tech/concepts/content-addressing/#version-1-v1)。
+
+4. 初始狀態為 **Queued**。 重新載入,直到狀態變為 **Pinned**。
+
+5. 按一下您的 CID 以取得連結。 您可以在[這裡](https://bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im/)看到我的應用程式。
+
+6. 您可能需要啟用您的帳戶,才能將其釘選超過一個月。 啟用帳戶的費用約為 1 美元。 如果您關閉了它,請登出再重新登入,系統會再次要求您啟用。
+
+## 從 IPFS 使用 {#using-from-ipfs}
+
+此時,您已擁有一個指向中心化閘道器的連結,該閘道器為您的 IPFS 內容提供服務。 簡言之,您的使用者介面可能更安全一些,但它仍然不是抗審查的。 要實現真正的抗審查,使用者需要[直接從瀏覽器](https://docs.ipfs.tech/install/ipfs-companion/#prerequisites)使用 IPFS。
+
+一旦您安裝了它 (並且桌面版 IPFS 正常運作),您就可以在任何網站上前往 [/ipfs/``](https://any.site/ipfs/bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im),您將以去中心化的方式獲得該內容。
+
+## 缺點 {#drawbacks}
+
+您無法可靠地刪除 IPFS 檔案,因此只要您在修改使用者介面,最好還是將其保持中心化,或使用[星際名稱系統 (IPNS)](https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs),這是一個在 IPFS 之上提供可變性的系統。 當然,任何可變的東西都可以被審查,在 IPNS 的情況下,可以透過向擁有其對應私密金鑰的人施壓來達成。
+
+此外,某些套件在 IPFS 上會出現問題,因此如果您的網站非常複雜,這可能不是一個好的解決方案。 當然,任何依賴伺服器整合的東西都無法僅僅透過將用戶端放在 IPFS 上來去中心化。
+
+## 結論 {#conclusion}
+
+就像以太坊讓您能夠將去中心化應用程式的資料庫和商業邏輯層面去中心化一樣,IPFS 也能讓您將使用者介面去中心化。 這能讓您阻斷針對您的去中心化應用程式的另一個攻擊媒介。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md b/public/content/translations/zh-tw/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
new file mode 100644
index 00000000000..644601f2d84
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
@@ -0,0 +1,104 @@
+---
+title: 使用 create-eth-app 快速啟動您的去中心化應用程式前端開發
+description: create-eth-app 使用方法及其功能概覽
+author: "Markus Waas"
+tags: [ "前端", "javascript", "ethers.js", "the graph", "defi" ]
+skill: beginner
+lang: zh-tw
+published: 2020-04-27
+source: soliditydeveloper.com
+sourceUrl: https://soliditydeveloper.com/create-eth-app
+---
+
+上次我們看過了 [Solidity 的整體概況](https://soliditydeveloper.com/solidity-overview-2020),並且已經提到了 [create-eth-app](https://github.com/PaulRBerg/create-eth-app)。 現在您將了解如何使用它、整合了哪些功能,以及關於如何擴展它的額外想法。 此應用程式由 [Sablier](http://sablier.com/) 的創辦人 Paul Razvan Berg 發起,它能快速啟動您的前端開發,並提供數個可選的整合選項。
+
+## 安裝 {#installation}
+
+安裝需要 Yarn 0.25 或更高版本 (`npm install yarn --global`)。 執行方法很簡單:
+
+```bash
+yarn create eth-app my-eth-app
+cd my-eth-app
+yarn react-app:start
+```
+
+它在底層使用 [create-react-app](https://github.com/facebook/create-react-app)。 若要檢視您的應用程式,請開啟 `http://localhost:3000/`。 當您準備好部署到生產環境時,請使用 yarn build 建立一個最小化的套件。 一個簡單的託管方法是使用 [Netlify](https://www.netlify.com/)。 您可以建立一個 GitHub repo,將其新增至 Netlify,設定建置指令,就完成了! 您的應用程式將會被託管,且所有人都能使用。 而且完全免費。
+
+## 功能 {#features}
+
+### React & create-react-app {#react--create-react-app}
+
+首先是此應用程式的核心:React 以及 _create-react-app_ 附帶的所有額外功能。 如果您不想整合以太坊,只使用這個也是個絕佳的選擇。 [React](https://react.dev/) 本身讓建置互動式使用者介面 (UI) 變得非常簡單。 它可能不像 [Vue](https://vuejs.org/) 那樣對初學者友善,但它仍然是主流,擁有更多功能,而且最重要的是有數以千計的額外函式庫可供選擇。 _create-react-app_ 同樣讓入門變得非常簡單,它包含:
+
+- 支援 React、JSX、ES6、TypeScript 和 Flow 語法。
+- ES6 以外的額外語言功能,例如物件展開運算子。
+- 自動加上前綴的 CSS,所以您不需要 -webkit- 或其他前綴。
+- 一個快速的互動式單元測試執行器,內建支援覆蓋率報告。
+- 一個即時開發伺服器,會對常見錯誤發出警告。
+- 一個建置腳本,可將 JS、CSS 和圖片打包用於生產,並附有哈希和來源對應檔。
+
+特別是 _create-eth-app_ 利用了新的 [Hook 特效](https://legacy.reactjs.org/docs/hooks-effect.html)。 這是一種撰寫功能強大但體積極小的所謂「函式元件」的方法。 請參閱下文關於 Apollo 的章節,以了解它們在 _create-eth-app_ 中的使用方式。
+
+### Yarn Workspaces {#yarn-workspaces}
+
+[Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/) 讓您擁有多個套件,但能夠從根目錄管理所有套件,並使用 `yarn install` 一次為所有套件安裝依賴項。 這對於像智慧合約地址/ABI 管理 (關於您部署了哪些智慧合約以及如何與它們通訊的資訊) 或 The Graph 整合等較小的附加套件特別有意義,這兩者都是 `create-eth-app` 的一部分。
+
+### ethers.js {#ethersjs}
+
+雖然 [Web3](https://docs.web3js.org/) 仍是主流,但 [ethers.js](https://docs.ethers.io/) 在去年作為替代方案獲得了更多關注,並且是整合到 _create-eth-app_ 中的函式庫。 您可以使用這個函式庫,也可以將其更換為 Web3,或考慮升級到幾乎脫離測試版的 [ethers.js v5](https://docs.ethers.org/v5/)。
+
+### The Graph {#the-graph}
+
+與 [RESTful API](https://restfulapi.net/) 相比,[GraphQL](https://graphql.org/) 是另一種處理資料的方式。 與 RESTful API 相比,它們有幾個優勢,特別是對於去中心化區塊鏈資料而言。 如果您對這背後的原因感興趣,可以看看 [GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a)。
+
+通常,您會直接從您的智慧合約中獲取資料。 想要讀取最新一筆交易的時間嗎? 只需呼叫 `MyContract.methods.latestTradeTime().call()`,它會從一個以太坊節點將資料擷取到您的去中心化應用程式中。 但如果您需要數百個不同的資料點呢? 這將導致對節點進行數百次的資料擷取,每次都需要一次 [往返時延 (RTT)](https://wikipedia.org/wiki/Round-trip_delay_time),從而使您的去中心化應用程式變得緩慢且效率低下。 一個變通方法可能是在您的合約內部設置一個擷取器呼叫函式,一次傳回多筆資料。 不過,這並非總是理想的解決方案。
+
+此外,您可能也會對歷史資料感興趣。 您不僅想知道最後一次交易的時間,還想知道您自己進行過的所有交易的時間。 使用 _create-eth-app_ 的子圖套件,閱讀 [文件](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph) 並將其應用於您自己的合約。 如果您正在尋找熱門的智慧合約,甚至可能已經有現成的子圖了。 查看 [子圖瀏覽器](https://thegraph.com/explorer/)。
+
+一旦您有了子圖,您就可以在您的去中心化應用程式中編寫一個簡單的查詢,以擷取所有您需要的重要的區塊鏈資料,包括歷史資料,而只需要一次擷取。
+
+### Apollo {#apollo}
+
+多虧了 [Apollo Boost](https://www.apollographql.com/docs/react/get-started/) 整合,您可以輕鬆地將 The Graph 整合到您的 React 去中心化應用程式中。 特別是當使用 [React Hook 和 Apollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks) 時,擷取資料就像在您的元件中編寫單一 GraphQL 查詢一樣簡單:
+
+```js
+const { loading, error, data } = useQuery(myGraphQlQuery)
+
+React.useEffect(() => {
+ if (!loading && !error && data) {
+ console.log({ data })
+ }
+}, [loading, error, data])
+```
+
+## 範本 {#templates}
+
+此外,您可以從數個不同的範本中進行選擇。 目前,您可以使用 Aave、Compound、UniSwap 或 Sablier 整合。 它們都添加了重要的服務智慧合約地址以及預製的子圖整合。 只需將範本添加到創建指令中即可,例如 `yarn create eth-app my-eth-app --with-template aave`。
+
+### Aave {#aave}
+
+[Aave](https://aave.com/) 是一個去中心化的貨幣借貸市場。 存款人向市場提供流動性以賺取被動收入,而借款人則能夠使用抵押品進行借款。 Aave 的一個獨特功能是 [閃電貸](https://aave.com/docs/developers/flash-loans),它允許您在沒有任何抵押品的情況下借款,只要您在單一交易內歸還貸款即可。 這在某些情況下可能很有用,例如在進行套利交易時為您提供額外現金。
+
+可以賺取利息的交易代幣稱為 _aTokens_。
+
+當您選擇將 Aave 與 _create-eth-app_ 整合時,您將獲得一個 [子圖整合](https://docs.aave.com/developers/getting-started/using-graphql)。 Aave 使用 The Graph,並已在 [Ropsten](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten) 和 [主網](https://thegraph.com/explorer/subgraph/aave/protocol)上以 [原始](https://thegraph.com/explorer/subgraph/aave/protocol-raw) 或 [格式化](https://thegraph.com/explorer/subgraph/aave/protocol) 形式為您提供了數個即用型子圖。
+
+
+
+### Compound {#compound}
+
+[Compound](https://compound.finance/) 與 Aave 類似。 該整合已經包含了新的 [Compound v2 子圖](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195)。 可想而知,這裡賺取利息的代幣稱為 _cTokens_。
+
+### Uniswap {#uniswap}
+
+[Uniswap](https://uniswap.exchange/) 是一個去中心化交易所 (DEX)。 流動性提供者可以透過為交易雙方提供所需的代幣或以太幣來賺取費用。 它被廣泛使用,因此在眾多代幣中擁有最高的流動性之一。 您可以輕鬆地將其整合到您的去中心化應用程式中,例如,允許使用者將他們的 ETH 兌換成 DAI。
+
+可惜的是,在撰寫本文時,該整合僅適用於 Uniswap v1,而不適用於 [剛發布的 v2](https://uniswap.org/blog/uniswap-v2/)。
+
+### Sablier {#sablier}
+
+[Sablier](https://sablier.com/) 允許使用者進行串流式金錢支付。 在初始設定後,您實際上可以持續收到款項,而無需進一步管理,而不是一次性的發薪日。 該整合包含了它 [自己的子圖](https://thegraph.com/explorer/subgraph/sablierhq/sablier)。
+
+## 下一步? {#whats-next}
+
+如果您對 _create-eth-app_ 有任何疑問,請前往 [Sablier 社群伺服器](https://discord.gg/bsS8T47),您可以在那裡與 _create-eth-app_ 的作者聯繫。 作為接下來的初步步驟,您可能需要整合一個 UI 框架,如 [Material UI](https://mui.com/material-ui/),為您實際需要的資料編寫 GraphQL 查詢,並設定部署。
diff --git a/public/content/translations/zh-tw/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md b/public/content/translations/zh-tw/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
new file mode 100644
index 00000000000..13cd5e8320c
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
@@ -0,0 +1,269 @@
+---
+title: 使用 SQL 學習基礎以太坊主題
+description: 本教學課程將透過結構化查詢語言 (SQL) 查詢鏈上資料,協助讀者了解基本的以太坊概念,包括交易、區塊和 Gas。
+author: "Paul Apivat"
+tags: [ "SQL", "查詢", "交易" ]
+skill: beginner
+lang: zh-tw
+published: 2021-05-11
+source: paulapivat.com
+sourceUrl: https://paulapivat.com/post/query_ethereum/
+---
+
+許多以太坊教學課程都以開發人員為對象,但卻缺乏為資料分析師,或是想在不執行用戶端或節點的情況下查看鏈上資料的人們所準備的教育資源。
+
+本教學課程透過 [Dune Analytics](https://dune.com/) 提供的介面,以結構化查詢語言 (SQL) 查詢鏈上資料,協助讀者了解基本的以太坊概念,包括交易、區塊和 Gas。
+
+鏈上資料可以幫助我們了解以太坊、網路以及作為運算能力的經濟體,並且應該作為基礎,以了解以太坊現今面臨的挑戰 (例如 Gas 費用上漲),更重要的是,可以圍繞擴展解決方案進行討論。
+
+### 交易 {#transactions}
+
+使用者在以太坊的旅程,始於初始化一個由使用者控制的帳戶,或一個具有 ETH 餘額的實體。 帳戶有兩種類型:由使用者控制的帳戶,或智能合約帳戶 (請參閱 [ethereum.org](/developers/docs/accounts/))。
+
+任何帳戶都可以在 [Etherscan](https://etherscan.io/) 或 [Blockscout](https://eth.blockscout.com/) 等區塊瀏覽器上查看。 區塊瀏覽器是以太坊資料的入口網站。 它們會即時顯示區塊、交易、礦工、帳戶和其他鏈上活動的資料 (請參閱[此處](/developers/docs/data-and-analytics/block-explorers/))。
+
+然而,使用者可能希望直接查詢資料,以核對外部區塊瀏覽器提供的資訊。 [Dune Analytics](https://dune.com/) 為任何具備 SQL 知識的人提供此功能。
+
+以供參考,以太坊基金會 (EF) 的智能合約帳戶可以在 [Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) 上查看。
+
+需要注意的是,所有帳戶,包括以太坊基金會的帳戶,都有一個可用於傳送和接收交易的公開地址。
+
+Etherscan 上的帳戶餘額包含一般交易和內部交易。 內部交易,雖然名為內部交易,但並非會改變鏈狀態的「實際」交易。 它們是透過執行合約來啟動的價值轉移 ([來源](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions))。 由於內部交易沒有簽名,所以「不會」被包含在區塊鏈上,也無法使用 Dune Analytics 查詢。
+
+因此,本教學課程將著重於一般交易。 查詢方式如下:
+
+```sql
+WITH temp_table AS (
+SELECT
+ hash,
+ block_number,
+ block_time,
+ "from",
+ "to",
+ value / 1e18 AS ether,
+ gas_used,
+ gas_price / 1e9 AS gas_price_gwei
+FROM ethereum."transactions"
+WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
+ORDER BY block_time DESC
+)
+SELECT
+ hash,
+ block_number,
+ block_time,
+ "from",
+ "to",
+ ether,
+ (gas_used * gas_price_gwei) / 1e9 AS txn_fee
+FROM temp_table
+```
+
+這將會產生與 Etherscan 交易頁面上所提供的相同資訊。 為了比較,以下是兩個來源:
+
+#### Etherscan {#etherscan}
+
+
+
+[Blockscout 上的以太坊基金會合約頁面。](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)
+
+#### Dune Analytics {#dune-analytics}
+
+
+
+你可以在[此處](https://dune.com/paulapivat/Learn-Ethereum)找到儀表板。 按一下表格以查看查詢 (也請參閱上方)。
+
+### 交易詳解 {#breaking_down_transactions}
+
+已提交的交易包含幾項資訊,其中包括 ([來源](/developers/docs/transactions/)):
+
+- **收款人**:接收地址 (查詢為 "to")
+- **簽名**:雖然寄件人的私鑰會簽署交易,但我們可以使用 SQL 查詢的是寄件人的公開地址 ("from")。
+- **價值**:這是轉移的 ETH 金額 (請參閱 `ether` 欄位)。
+- **資料**:這是經過哈希運算的任意資料 (請參閱 `data` 欄位)
+- **gasLimit** – 交易可耗用的 gas 單位上限。 gas 單位代表運算步驟
+- **maxPriorityFeePerGas** - 作為給礦工的小費,每單位 gas 的優先費用上限
+- **maxFeePerGas** - 願意為交易支付的每單位 gas 費用上限 (包含 baseFeePerGas 和 maxPriorityFeePerGas)
+
+我們可以查詢傳送至以太坊基金會公開地址的交易的特定資訊:
+
+```sql
+SELECT
+ "to",
+ "from",
+ value / 1e18 AS ether,
+ data,
+ gas_limit,
+ gas_price / 1e9 AS gas_price_gwei,
+ gas_used,
+ ROUND(((gas_used / gas_limit) * 100),2) AS gas_used_pct
+FROM ethereum."transactions"
+WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
+ORDER BY block_time DESC
+```
+
+### 區塊 {#blocks}
+
+每筆交易都會改變以太坊虛擬機 ([EVM](/developers/docs/evm/)) 的狀態 ([來源](/developers/docs/transactions/))。 交易會廣播至網路進行驗證,並包含在區塊中。 每筆交易都與一個區塊編號相關聯。 若要查看資料,我們可以查詢特定的區塊編號:12396854 (截至本文撰寫時 [2021/5/11],此為以太坊基金會交易中最新的區塊)。
+
+此外,當我們查詢接下來的兩個區塊時,我們可以看到每個區塊都包含前一個區塊的哈希 (即父哈希),這說明了區塊鏈是如何形成的。
+
+每個區塊都包含對其父區塊的引用。 如下方 `hash` 和 `parent_hash` 欄位之間所示 ([來源](/developers/docs/blocks/)):
+
+
+
+這是 Dune Analytics 上的[查詢](https://dune.com/queries/44856/88292):
+
+```sql
+SELECT
+ time,
+ number,
+ hash,
+ parent_hash,
+ nonce
+FROM ethereum."blocks"
+WHERE "number" = 12396854 OR "number" = 12396855 OR "number" = 12396856
+LIMIT 10
+```
+
+我們可以透過查詢時間、區塊編號、難度、哈希、父哈希和 nonce 來檢視一個區塊。
+
+此查詢唯一未涵蓋的是_交易列表_和_狀態根_,這需要下方另一個獨立的查詢。 完整或封存節點將儲存所有交易和狀態轉換,讓用戶端隨時可以查詢鏈的狀態。 因為這需要大量的儲存空間,我們可以將鏈資料與狀態資料分開:
+
+- 鏈資料 (區塊、交易列表)
+- 狀態資料 (每筆交易狀態轉換的結果)
+
+狀態根屬於後者,是_隱含_資料 (不儲存在鏈上),而鏈資料是明確的,儲存在鏈本身上 ([來源](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored))。
+
+在本教學課程中,我們將著重於可以透過 Dune Analytics 以 SQL 查詢的鏈上資料。
+
+如上所述,每個區塊都包含一個交易列表,我們可以透過篩選特定區塊來查詢。 我們來試試最新的區塊,12396854:
+
+```sql
+SELECT * FROM ethereum."transactions"
+WHERE block_number = 12396854
+ORDER BY block_time DESC`
+```
+
+以下是 Dune 上的 SQL 輸出:
+
+
+
+這個被新增到鏈上的單一區塊會改變以太坊虛擬機 ([EVM](/developers/docs/evm/)) 的狀態。 有時一次會驗證數十筆,甚至數百筆交易。 在這個特定案例中,共包含了 222 筆交易。
+
+若要查看實際上有多少筆交易成功,我們可以新增另一個篩選器來計算成功的交易數量:
+
+```sql
+WITH temp_table AS (
+ SELECT * FROM ethereum."transactions"
+ WHERE block_number = 12396854 AND success = true
+ ORDER BY block_time DESC
+)
+SELECT
+ COUNT(success) AS num_successful_txn
+FROM temp_table
+```
+
+在區塊 12396854 中,總共 222 筆交易裡,有 204 筆成功驗證:
+
+
+
+交易請求每秒發生數十次,但區塊大約每 15 秒才提交一次 ([來源](/developers/docs/blocks/))。
+
+若要查看大約每 15 秒產生一個區塊,我們可以將一天的秒數 (86400) 除以 15,得到每日平均區塊數的估計值 (約 5760)。
+
+以太坊每日產生的區塊圖表 (2016 年至今) 如下:
+
+
+
+在此期間,每日產生的區塊平均數約為 5,874:
+
+
+
+查詢如下:
+
+```sql
+# 查詢以視覺化呈現 2016 年以來每日產生的區塊數量
+
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ COUNT(*) AS block_count
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+
+# 每日產生的平均區塊數量
+
+WITH temp_table AS (
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ COUNT(*) AS block_count
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+)
+SELECT
+ AVG(block_count) AS avg_block_count
+FROM temp_table
+```
+
+自 2016 年以來,每日產生的平均區塊數為 5,874,略高於該數字。 或者,將 86400 秒除以 5874 個平均區塊,得出 14.7 秒,即大約每 15 秒一個區塊。
+
+### Gas {#gas}
+
+區塊的大小是有限制的。 區塊大小上限是動態的,會根據網路需求在 12,500,000 到 25,000,000 單位之間變化。 需要限制,以防止任意大的區塊對完整節點在磁碟空間和速度要求方面造成壓力 ([來源](/developers/docs/blocks/))。
+
+要將區塊 gas 上限概念化,其中一種方式是將其視為可用於批次處理交易的區塊空間的**供給**。 從 2016 年至今的區塊 gas 上限可以查詢並視覺化呈現:
+
+
+
+```sql
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ AVG(gas_limit) AS avg_block_gas_limit
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+```
+
+然後是每日實際用於支付以太坊鏈上運算費用的 gas (例如傳送交易、呼叫智能合約、鑄造 NFT)。 這是對可用以太坊區塊空間的**需求**:
+
+
+
+```sql
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ AVG(gas_used) AS avg_block_gas_used
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+```
+
+我們也可以將這兩個圖表並列,看看**需求與供給**如何對應:
+
+
+
+因此,在供給固定的情況下,我們可以將 gas 價格理解為以太坊區塊空間需求的函數。
+
+最後,我們可能想查詢以太坊鏈的每日平均 gas 價格,然而,這樣做會導致查詢時間特別長,所以我們將篩選查詢,只看以太坊基金會每筆交易所支付的平均 gas 金額。
+
+
+
+我們可以看見多年來,所有傳送至以太坊基金會地址的交易所支付的 gas 價格。 查詢如下:
+
+```sql
+SELECT
+ block_time,
+ gas_price / 1e9 AS gas_price_gwei,
+ value / 1e18 AS eth_sent
+FROM ethereum."transactions"
+WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
+ORDER BY block_time DESC
+```
+
+### 總結 {#summary}
+
+透過本教學課程,我們透過查詢和體驗鏈上資料,了解了基礎的以太坊概念,以及以太坊區塊鏈的運作方式。
+
+包含本教學課程中所有程式碼的儀表板可以在[此處](https://dune.com/paulapivat/Learn-Ethereum)找到。
+
+若要利用資料進一步探索 Web3,歡迎[在 Twitter 上找到我](https://twitter.com/paulapivat)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/logging-events-smart-contracts/index.md b/public/content/translations/zh-tw/developers/tutorials/logging-events-smart-contracts/index.md
new file mode 100644
index 00000000000..4c35c470677
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/logging-events-smart-contracts/index.md
@@ -0,0 +1,62 @@
+---
+title: 使用事件記錄智能合約資料
+description: 智能合約事件簡介,以及如何使用它們來記錄資料
+author: "jdourlens"
+tags: [ "智能合約", "remix", "穩固", "事件" ]
+skill: intermediate
+lang: zh-tw
+published: 2020-04-03
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/logging-data-with-events/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+在 Solidity 中,[事件](/developers/docs/smart-contracts/anatomy/#events-and-logs)是智能合約可以發出的信號。 去中心化應用程式或任何連接到 Ethereum JSON-RPC API 的東西,都可以監聽這些事件並採取相應的行動。 事件也可以被索引,以便日後可以搜尋事件歷史。
+
+## Events {#events}
+
+撰寫本文時,Ethereum 區塊鏈上最常見的事件是轉帳事件,當有人轉移代幣時,ERC20 代幣會發出此事件。
+
+```solidity
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+事件簽章在合約程式碼內部宣告,並可以使用 `emit` 關鍵字發出。 例如,轉帳事件記錄了誰發送了轉帳 (`_from`)、轉給誰 (`_to`) 以及轉移了多少代幣 (`_value`)。
+
+如果我們回到我們的 Counter 智能合約,並決定在每次值變更時都進行記錄。 由於此合約並非用於部署,而是作為透過擴展來建立另一個合約的基礎:它被稱為抽象合約。 在我們的計數器範例中,它會是這個樣子:
+
+```solidity
+pragma solidity 0.5.17;
+
+contract Counter {
+
+ event ValueChanged(uint oldValue, uint256 newValue);
+
+ // 用於儲存計數的私有 unsigned int 變數
+ uint256 private count = 0;
+
+ // 增加計數器的函式
+ function increment() public {
+ count += 1;
+ emit ValueChanged(count - 1, count);
+ }
+
+ // 用於取得計數值的 Getter 函式
+ function getCount() public view returns (uint256) {
+ return count;
+ }
+
+}
+```
+
+請注意:
+
+- **第 5 行**:我們宣告了我們的事件以及它包含的內容:舊值和新值。
+
+- **第 13 行**:當我們遞增計數變數時,我們會發出事件。
+
+如果我們現在部署合約並呼叫 increment 函式,我們會看到,如果你在名為 logs 的陣列中點擊新的交易,Remix 將會自動顯示它。
+
+
+
+日誌對於偵錯你的智能合約非常有用,但如果你建立供不同人使用的應用程式,它們也很重要,可以讓分析更容易,以追蹤和了解你的智能合約是如何被使用的。 交易產生的日誌會顯示在熱門的區塊瀏覽器中,你也可以使用它們來建立鏈下腳本,以監聽特定事件並在事件發生時採取行動。
diff --git a/public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
new file mode 100644
index 00000000000..ca89ec1d5d5
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
@@ -0,0 +1,244 @@
+---
+title: 用於離線資料完整性的默克爾證明
+description: 為儲存在鏈下的資料確保其鏈上完整性
+author: 作者:Ori Pomerantz
+tags: [ "儲存" ]
+skill: advanced
+lang: zh-tw
+published: 2021-12-30
+---
+
+## 介紹 {#introduction}
+
+理想情況下,我們希望將所有內容儲存在以太坊儲存空間中。以太坊儲存空間分布在數千台電腦上,具有極高的可用性(資料無法被審查)和完整性(資料無法在未經授權的情況下被修改),但儲存一個 32 位元組的字通常需要花費 20,000 gas。 在我撰寫本文時,該成本相當於 6.60 美元。 每位元組 21 美分的價格對於許多用途來說都太過昂貴。
+
+為了要解決這個問題,以太坊生態系開發了[許多以去中心化方式儲存資料的替代方案](/developers/docs/storage/)。 通常它們都涉及可用性和價格之間的權衡。 然而,完整性通常能獲得保證。
+
+在本文中,您將學習**如何**使用[默克爾證明](https://computersciencewiki.org/index.php/Merkle_proof)在不將資料儲存在區塊鏈上的情況下確保資料完整性。
+
+## 它是如何運作的? {#how-does-it-work}
+
+理論上,我們可以只將資料的哈希儲存在鏈上,並在需要資料的交易中傳送所有資料。 但是,這將會還是太昂貴了。 往一項交易傳送的一個字節位元組的數據會消耗掉約16份燃料,現時相當於半毛錢,或者每千字節會消耗掉約$5。 每 MB 5000 美元的價格,對於許多用途來說仍然太貴,即使不考慮哈希處理資料的額外成本。
+
+解決方案是重複哈希處理資料的不同子集,這樣一來,對於您不需要傳送的資料,您只需傳送一個哈希即可。 您可以使用默克爾樹來完成此操作,這是一種樹狀資料結構,其中每個節點都是其下方節點的哈希:
+
+
+
+根哈希是唯一需要儲存在鏈上的部分。 為了證明某個特定值,您需要提供所有與其組合以獲得根所需的哈希。 例如,為了證明 `C`,您需要提供 `D`、`H(A-B)` 和 `H(E-H)`。
+
+
+
+## 實作 {#implementation}
+
+[範例程式碼在此處提供](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity)。
+
+### 鏈下程式碼 {#offchain-code}
+
+在本文中,我們使用 JavaScript 進行鏈下運算。 大多數去中心化應用程式都以 JavaScript 撰寫其鏈下元件。
+
+#### 建立默克爾根 {#creating-the-merkle-root}
+
+首先,我們需要往區塊鏈提供Merkle樹根。
+
+```javascript
+const ethers = require("ethers")
+```
+
+[我們使用 ethers 套件中的哈希函式](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256)。
+
+```javascript
+// 我們必須驗證其完整性的原始資料。前兩個位元組
+// 是使用者識別碼,後兩個位元組是使用者目前擁有的代幣數量。
+const dataArray = [
+ 0x0bad0010, 0x60a70020, 0xbeef0030, 0xdead0040, 0xca110050, 0x0e660060,
+ 0xface0070, 0xbad00080, 0x060d0091,
+]
+```
+
+把每個輸入編碼成為一個單一256-bit的整數,會導致產生一個較低閱讀性的程序碼。要舉例的話,那就是比使用JSON編碼而成的數值的閱讀性還要低了。 但是,這意味著要提取合約內的數據需要經歷的程序會大幅降低,所消耗的燃料成本如是。 [您可以在鏈上讀取 JSON](https://github.com/chrisdotn/jsmnSol),但如果可以避免,最好不要這麼做。
+
+```javascript
+// 哈希值陣列,以 BigInts 形式表示
+const hashArray = dataArray
+```
+
+在這個例子中,我們的數據是從256-bit的數值開始的,所以不需要更多的程序了。 如果我們使用一個更複雜的數據結構如字串們,我們需要確認我們先雜湊好數據以拿到一個欄目的雜湊值。 要注意這也是因為我們不在意用戶是否知道其他用戶的資訊。 否則,我們將會必須要進行雜湊,所以用戶1將不會知道用戶0的數值,用戶2則將不會知道用戶3的數值,如此類推。
+
+```javascript
+// 在哈希函式預期的字串和我們在其他地方使用的
+// BigInt 之間進行轉換。
+const hash = (x) =>
+ BigInt(ethers.utils.keccak256("0x" + x.toString(16).padStart(64, 0)))
+```
+
+ethers 哈希函式預期接收一個帶有十六進位數字的 JavaScript 字串 (例如 `0x60A7`),並回應一個具有相同結構的字串。 然而,對於其餘的程式碼而言,使用 `BigInt` 更為容易,所以我們先轉換為十六進位字串,然後再轉換回來。
+
+```javascript
+// 一對值的對稱哈希,所以我們不關心順序是否顛倒。
+const pairHash = (a, b) => hash(hash(a) ^ hash(b))
+```
+
+這個函式是對稱的 (a [xor](https://en.wikipedia.org/wiki/Exclusive_or) b 的哈希)。 這是指當我們檢查Merkle推論的時候,我們不需要擔心有關是否要把從推論而來的數值安放在計算完成的數值前或後方。 默克爾證明的檢查是在鏈上完成的,所以我們在那裡需要做的事情越少越好。
+
+警告:
+密碼學比看起來的要困難。
+本文的最初版本使用了哈希函式 `hash(a^b)`。
+那是個**糟糕**的想法,因為這意味著如果您知道 `a` 和 `b` 的合法值,您就可以使用 `b' = a^b^a'` 來證明任何想要的 `a'` 值。
+使用這個函式,您必須計算 `b'` 使得 `hash(a') ^ hash(b')` 等於一個已知值 (通往根路徑上的下一個分支),這要困難得多。
+
+```javascript
+// 用來表示某個分支為空、沒有
+// 值的值
+const empty = 0n
+```
+
+當數值的數字不是一個整數再取二次方,我們便需要處理空出來的枝節。 這個程序要這樣寫的原因是把零放左一個空間持有者。
+
+
+
+```javascript
+// 依序對每對值取哈希,計算出哈希陣列樹的上一層
+const oneLevelUp = (inputArray) => {
+ var result = []
+ var inp = [...inputArray] // 為避免覆寫輸入 // 必要時新增一個空值 (我們需要所有葉節點都 // 成對)
+
+ if (inp.length % 2 === 1) inp.push(empty)
+
+ for (var i = 0; i < inp.length; i += 2)
+ result.push(pairHash(inp[i], inp[i + 1]))
+
+ return result
+} // oneLevelUp
+```
+
+這個功能會在Merkle樹狀內「攀爬」到一個程度,此舉是透過把現層的數值們作成雜湊值的配對。 請注意,這不是最有效率的實作,我們本可以避免複製輸入,而只在迴圈中適當的時候新增 `hashEmpty`,但此程式碼是為了可讀性而最佳化。
+
+```javascript
+const getMerkleRoot = (inputArray) => {
+ var result
+
+ result = [...inputArray] // 沿著樹向上,直到只剩下一個值,那就是 // 根。 // // 如果一層有奇數個條目,oneLevelUp 中的 // 程式碼會新增一個空值,所以如果我們有,例如,// 10 個葉節點,那麼第二層會有 5 個分支,第三層 // 有 3 個分支,第四層有 2 個分支,而根是第五層
+
+ while (result.length > 1) result = oneLevelUp(result)
+
+ return result[0]
+}
+```
+
+要拿到根部,一直攀爬直到這裡只剩下一個數值。
+
+#### 建立默克爾證明 {#creating-a-merkle-proof}
+
+一個Merkle推論是用來跟一些已經被證明好的數值雜湊在一起,以拿回Merkle樹根。 被證明的數值通常從其他數據可以得手,所以比起作為程序碼的一部份我的取向會是分別提供這些數值。
+
+```javascript
+// 默克爾證明由要一起哈希的條目清單
+// 的值組成。因為我們使用對稱哈希函式,所以我們不
+// 需要項目的位置來驗證證明,只需要用它來建立證明
+const getMerkleProof = (inputArray, n) => {
+ var result = [], currentLayer = [...inputArray], currentN = n
+
+ // 直到我們到達頂部
+ while (currentLayer.length > 1) {
+ // 沒有奇數長度的層
+ if (currentLayer.length % 2)
+ currentLayer.push(empty)
+
+ result.push(currentN % 2
+ // 如果 currentN 是奇數,將它前面的值加入證明
+ ? currentLayer[currentN-1]
+ // 如果是偶數,則加入它後面的值
+ : currentLayer[currentN+1])
+
+```
+
+我們哈希處理 `(v[0],v[1])`、`(v[2],v[3])` 等。 所以對於偶數值,我們需要下一個;對於奇數值,我們需要前一個。
+
+```javascript
+ // 移動到上一層
+ currentN = Math.floor(currentN/2)
+ currentLayer = oneLevelUp(currentLayer)
+ } // while currentLayer.length > 1
+
+ return result
+} // getMerkleProof
+```
+
+### 鏈上程式碼 {#onchain-code}
+
+最終,我們有了核實推論的程式碼。 鏈上程式碼是以 [Solidity](https://docs.soliditylang.org/en/v0.8.11/) 撰寫的。 最優化在此是更為重要,因為相對來說燃料價格是較為昂貴的。
+
+```solidity
+//SPDX-License-Identifier: Public Domain
+pragma solidity ^0.8.0;
+
+import "hardhat/console.sol";
+```
+
+我是使用 [Hardhat 開發環境](https://hardhat.org/) 撰寫此程式碼的,它讓我們在開發時可以取得[來自 Solidity 的主控台輸出](https://hardhat.org/docs/cookbook/debug-logs)。
+
+```solidity
+
+contract MerkleProof {
+ uint merkleRoot;
+
+ function getRoot() public view returns (uint) {
+ return merkleRoot;
+ }
+
+ // 極度不安全,在生產程式碼中,對此函式的存取
+ // **必須**嚴格限制,可能僅限於
+ // 擁有者
+ function setRoot(uint _merkleRoot) external {
+ merkleRoot = _merkleRoot;
+ } // setRoot
+```
+
+為Merkle樹根而設定和拿取功能。 在生產系統中,讓任何人都能更新默克爾根是個_極其糟糕的想法_。 我在此這樣做是為了把範例程式碼給簡化掉。 **不要在資料完整性至關重要的系統上這麼做**。
+
+```solidity
+ function hash(uint _a) internal pure returns(uint) {
+ return uint(keccak256(abi.encode(_a)));
+ }
+
+ function pairHash(uint _a, uint _b) internal pure returns(uint) {
+ return hash(hash(_a) ^ hash(_b));
+ }
+```
+
+這個功能產生了一對雜湊值。 這只是 JavaScript 程式碼中 `hash` 和 `pairHash` 的 Solidity 轉譯。
+
+\*\*注意:\*\*這是另一個為了可讀性而進行最佳化的案例。 根據[函式定義](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm),或許可以將資料儲存為 [`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays) 值並避免轉換。
+
+```solidity
+ // 驗證默克爾證明
+ function verifyProof(uint _value, uint[] calldata _proof)
+ public view returns (bool) {
+ uint temp = _value;
+ uint i;
+
+ for(i=0; i<_proof.length; i++) {
+ temp = pairHash(temp, _proof[i]);
+ }
+
+ return temp == merkleRoot;
+ }
+
+} // MarkleProof
+```
+
+在數學表示法中,默克爾證明驗證看起來像這樣:`H(proof_n, H(proof_n-1, H(proof_n-2, ...` H(proof_1, H(proof_0, value))...)))\`。 這個程序碼會實行驗證。
+
+## 默克爾證明與匯總值不相容 {#merkle-proofs-and-rollups}
+
+默克爾證明與[匯總值](/developers/docs/scaling/#rollups) 的相容性不佳。 這個現象的原因是匯總值在層一負責書寫所有的交易數據,但在層二上是負責紀錄交易過程。 伴隨一項交易來傳送一份Merkle推論的每層平均成本是638份燃料(現時在一個回呼內的一個字節位元組會花費16份燃料,如果它數值不是為零的話。如果為零,它會花費掉4份燃料)。 如果我們有1024字的數據,一份Merkle推論需要十層,或是總共6380份燃料。
+
+以 [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m) 為例,寫入 L1 的 gas 約為 100 gwei,L2 的 gas 為 0.001 gwei (這是正常價格,可能會隨著擁塞而上漲)。 所以,就層一的成本來說,我們在層二的程序中可以花掉百到千份的燃料。 先假設我們不會寫爆儲存,這達標我們可用層一燃料的價格來在層二寫大約五個字詞。 對於單一的默克爾證明,我們可以將全部 1024 個字寫入儲存空間 (假設它們一開始就可以在鏈上計算,而不是在交易中提供),並且仍然有大部分的 gas 剩餘。
+
+## 結論 {#conclusion}
+
+在現實生活中,你可能永遠不會單靠自己來施行Merkle樹狀理論。 這裡有些著名而被審查好的圖書館給你用。通常來說,最好不要自己來實行虛擬代幣的早期版本。 但是,我希望現在你會更好地理解到Merkle推論,並且能夠決定甚麼時候它們會值得被使用。
+
+請注意,雖然默克爾證明保留了_完整性_,但它們不保留_可用性_。 當我們知道沒有其他人可以拿取你的資產時,這個行為在兩種情境中可以成為你一個小小的悲傷。其一是當數據儲存否決你的接觸許可,其二是反回來看你不能構造一個Merkle樹來接觸到儲存。 所以,Merkle樹最好是跟某種如IPFS的去中央化儲存一起使用。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md b/public/content/translations/zh-tw/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
new file mode 100644
index 00000000000..e3102318e53
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
@@ -0,0 +1,151 @@
+---
+title: 使用 InfluxDB 與 Grafana 監控 Geth
+description: 使用 InfluxDB 與 Grafana 設定 Geth 節點的監控,以追蹤效能並識別問題。
+author: "Mario Havel"
+tags: [ "用戶端", "節點" ]
+skill: intermediate
+lang: zh-tw
+published: 2021-01-13
+---
+
+本教學將協助您設定 Geth 節點的監控,以便更深入地了解其效能並識別潛在問題。
+
+## 先決條件 {#prerequisites}
+
+- 您應已在執行一個 Geth 實例。
+- 大部分步驟和範例都適用於 Linux 環境,具備基本的終端機知識將會很有幫助。
+- 請觀看此 Geth 指標套件的影片概覽:[Monitoring an Ethereum infrastructure by Péter Szilágyi](https://www.youtube.com/watch?v=cOBab8IJMYI)。
+
+## 監控堆疊 {#monitoring-stack}
+
+以太坊用戶端會收集大量資料,這些資料可以按時間順序資料庫的形式讀取。 為簡化監控,您可以將這些資料饋入資料視覺化軟體。 有以下幾種選項可供選擇:
+
+- [Prometheus](https://prometheus.io/) (提取模型)
+- [InfluxDB](https://www.influxdata.com/get-influxdb/) (推送模型)
+- [Telegraf](https://www.influxdata.com/get-influxdb/)
+- [Grafana](https://www.grafana.com/)
+- [Datadog](https://www.datadoghq.com/)
+- [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/)
+
+此外,還有 [Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter),這是一個預先配置好 InfluxDB 和 Grafana 的選項。
+
+在本教學中,我們將設定您的 Geth 用戶端,將資料推送到 InfluxDB 以建立資料庫,並推送到 Grafana 以建立資料的圖形化視覺呈現。 手動操作有助於您更深入地了解流程、修改流程,並在不同環境中部署。
+
+## 設定 InfluxDB {#setting-up-influxdb}
+
+首先,我們來下載並安裝 InfluxDB。 您可以在 [Influxdata 發布頁面](https://portal.influxdata.com/downloads/) 找到各種下載選項。 請選擇適合您環境的版本。
+您也可以從 [儲存庫](https://repos.influxdata.com/) 安裝。 例如,在 Debian 系列的發行版中:
+
+```
+curl -tlsv1.3 --proto =https -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add
+source /etc/lsb-release
+echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
+sudo apt update
+sudo apt install influxdb -y
+sudo systemctl enable influxdb
+sudo systemctl start influxdb
+sudo apt install influxdb-client
+```
+
+成功安裝 InfluxDB 後,請確保它在背景執行。 依預設,可以在 `localhost:8086` 連線到它。
+在使用 `influx` 用戶端之前,您必須建立一個具有管理員權限的新使用者。 此使用者將用於高階管理、建立資料庫和使用者。
+
+```
+curl -XPOST "http://localhost:8086/query" --data-urlencode "q=CREATE USER username WITH PASSWORD 'password' WITH ALL PRIVILEGES"
+```
+
+現在您可以使用此使用者透過 influx 用戶端進入 [InfluxDB shell](https://docs.influxdata.com/influxdb/v1.8/tools/shell/)。
+
+```
+influx -username 'username' -password 'password'
+```
+
+在其 shell 中直接與 InfluxDB 通訊,您可以為 geth 指標建立資料庫和使用者。
+
+```
+create database geth
+create user geth with password choosepassword
+```
+
+使用以下指令驗證已建立的項目:
+
+```
+show databases
+show users
+```
+
+離開 InfluxDB shell。
+
+```
+exit
+```
+
+InfluxDB 正在執行並已設定為儲存來自 Geth 的指標。
+
+## 準備 Geth {#preparing-geth}
+
+設定好資料庫後,我們需要在 Geth 中啟用指標收集。 請注意 `geth --help` 中的 `METRICS AND STATS OPTIONS`。 您可以在那裡找到多個選項,在這種情況下,我們希望 Geth 將資料推送到 InfluxDB。
+基本設定指定了 InfluxDB 的可連線端點和資料庫的驗證資訊。
+
+```
+geth --metrics --metrics.influxdb --metrics.influxdb.endpoint "http://0.0.0.0:8086" --metrics.influxdb.username "geth" --metrics.influxdb.password "chosenpassword"
+```
+
+這些旗標可以附加到啟動用戶端的指令中,或儲存到設定檔中。
+
+您可以透過列出資料庫中的指標等方式,來驗證 Geth 是否成功推送資料。 在 InfluxDB shell 中:
+
+```
+use geth
+show measurements
+```
+
+## 設定 Grafana {#setting-up-grafana}
+
+下一步是安裝 Grafana,它將以圖形方式解譯資料。 請在 Grafana 文件中遵循您環境的安裝程序。 如果您沒有其他需求,請務必安裝 OSS 版本。
+使用儲存庫為 Debian 發行版安裝的範例步驟:
+
+```
+curl -tlsv1.3 --proto =https -sL https://packages.grafana.com/gpg.key | sudo apt-key add -
+echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list
+sudo apt update
+sudo apt install grafana
+sudo systemctl enable grafana-server
+sudo systemctl start grafana-server
+```
+
+當 Grafana 執行後,應該可以在 `localhost:3000` 連線到它。
+使用您偏好的瀏覽器存取此路徑,然後使用預設憑證登入 (使用者:`admin`,密碼:`admin`)。 出現提示時,請變更預設密碼並儲存。
+
+
+
+您將被重新導向到 Grafana 首頁。 首先,設定您的資料來源。 按一下左側欄的設定圖示,然後選取 "Data sources"。
+
+
+
+目前尚未建立任何資料來源,請按一下 "Add data source" 來定義一個。
+
+
+
+對於此設定,請選取 "InfluxDB" 並繼續。
+
+
+
+如果您在同一台機器上執行工具,資料來源的設定非常直接。 您需要設定 InfluxDB 位址和存取資料庫的詳細資訊。 請參考下圖。
+
+
+
+如果一切都已完成且 InfluxDB 可連線,請按一下 "Save and test",然後等待確認訊息彈出。
+
+
+
+Grafana 現在已設定為可從 InfluxDB 讀取資料。 現在您需要建立一個儀表板來解譯和顯示資料。 儀表板屬性被編碼在 JSON 檔案中,任何人都可以建立並輕鬆匯入這些檔案。 在左側欄上,按一下 "Create and Import"。
+
+
+
+若要建立 Geth 監控儀表板,請複製[此儀表板](https://grafana.com/grafana/dashboards/13877/)的 ID,並將其貼到 Grafana 的 "Import page" 中。 儲存儀表板後,它應該看起來像這樣:
+
+
+
+您可以修改您的儀表板。 每個面板都可以編輯、移動、移除或新增。 您可以變更您的設定。 一切由您決定! 要了解更多關於儀表板的運作方式,請參考 [Grafana 的文件](https://grafana.com/docs/grafana/latest/dashboards/)。
+您可能也對[警示](https://grafana.com/docs/grafana/latest/alerting/)感興趣。 這可讓您設定當指標達到特定值時的警示通知。 支援多種通訊管道。
diff --git a/public/content/translations/zh-tw/developers/tutorials/nft-minter/index.md b/public/content/translations/zh-tw/developers/tutorials/nft-minter/index.md
new file mode 100644
index 00000000000..519934bd567
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/nft-minter/index.md
@@ -0,0 +1,866 @@
+---
+title: 非同質化代幣鑄幣機使用教學
+description: 在本教學中,你將建構一個 NFT 鑄造器,並學習如何透過 MetaMask 和 Web3 工具將你的智能合約連接到 React 前端,來建立一個全端去中心化應用程式。
+author: "smudgil"
+tags: [ "穩固", "非同質化代幣", "alchemy", "智能合約", "前端", "Pinata" ]
+skill: intermediate
+lang: zh-tw
+published: 2021-10-06
+---
+
+對於來自 Web2 背景的開發人員來說,最大的挑戰之一是弄清楚如何將你的智慧型合約連接到前端專案並與之交互。
+
+通過構建非同質化代幣鑄幣機 ,一個可以用來輸入數字資產鏈接、名稱與描述的簡單用戶界面 — 你將學會如何:
+
+- 通過你的前端專案連接到 MetaMask
+- 在前端調用智慧型合約的方法
+- 使用MetaMask簽署交易
+
+在本教學中,我們將使用 [React](https://react.dev/) 作為前端框架。 因為此教程最初是專注於Web3的發展上,我們將不會花費過多的時間來解釋功能「反應」的基本概念。 反之,我們將會集中在往我們專案帶來功能的方法。
+
+作為一個前提,你理應有一個初學者對「反應」的理解 - 會知道組件、道具、useState/useEffect,還有基本功能回呼的運作。 如果你之前從未聽過這些術語,不妨先看看這篇 [React 入門教學](https://react.dev/learn/tutorial-tic-tac-toe)。 對於偏好視覺學習的讀者,我們強烈推薦由 Net Ninja 製作的這套優質影片系列:[Full Modern React Tutorial](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d)。
+
+而且如果你還沒準備好,你且將會一定需要一個Alchemy的帳戶來完成該份教程,也會在區塊鏈上建立任何東西。 [在此](https://alchemy.com/)註冊一個免費帳戶。
+
+迫不及待了嗎?那麼讓我們開始吧!
+
+## NFT 製作入門 {#making-nfts-101}
+
+在我們甚至要開始著眼在任何程式碼前,理解創造一個NFT的運作過程是重要的。 它由兩個步驟組成:
+
+### 在以太坊區塊鏈上發布 NFT 智能合約 {#publish-nft}
+
+在兩份NFT智慧型合約標準中最大的分別是:ERC-1155協議是一份具有多種代幣標準且內有批次的功能的合約;對比來看ERC-721協議只是一份單一代幣標準的合約,也因此它只會支持一次性地傳送一個代幣。
+
+### 呼叫鑄造函式 {#minting-function}
+
+通常,這個鑄造函式需要你傳入兩個變數作為參數:第一個是 `recipient`,用來指定接收你新鑄造 NFT 的位址;第二個是 NFT 的 `tokenURI`,這是一個字串,會解析成描述 NFT 元資料的 JSON 文件。
+
+一個NFT的元數據是把NFT從虛擬帶到現實的東西,它容許NFT持有特質,如一個名字、描述、圖像(或不同的電子資產),還有其他屬性。 這是 [一個 tokenURI 的範例](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2),其中包含了 NFT 的元資料。
+
+在此教程內,我們將會專注於第二部分,它是有關使用我們的功能「反應」UI回呼一個現存NFT的智慧型合約挖礦功能的方法。
+
+[這個連結](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE) 是我們在本教學中將會呼叫的 ERC-721 NFT 智能合約。 如果你想學習我們是如何製作它的,我們強烈推薦你查看我們的另一篇教學:["如何建立一個 NFT"](https://www.alchemy.com/docs/how-to-create-an-nft)。
+
+好的,現在我們明白了讓一個NFT運作的原理,讓我們複製我們的起始檔案們吧!
+
+## 複製入門檔案 {#clone-the-starter-files}
+
+首先,前往 [nft-minter-tutorial GitHub 儲存庫](https://github.com/alchemyplatform/nft-minter-tutorial) 以取得此專案的入門檔案。 將此儲存庫複製到你的本機環境中。
+
+當你開啟這個複製的 `nft-minter-tutorial` 儲存庫時,你會注意到它包含兩個資料夾:`minter-starter-files` 和 `nft-minter`。
+
+- `minter-starter-files` 包含此專案的入門檔案 (主要是 React UI)。 在本教學中,**我們將會在這個目錄中工作**,你將學習如何將此 UI 連接到你的以太坊錢包和 NFT 智能合約,讓它活起來。
+- `nft-minter` 包含整個已完成的教學,如果你卡關了,可以把它當作**參考**。
+
+接著,在你的程式碼編輯器中開啟你的 `minter-starter-files` 複本,然後導覽至 `src` 資料夾。
+
+我們將撰寫的所有程式碼都會放在 `src` 資料夾底下。 我們將會編輯 `Minter.js` 元件並撰寫額外的 javascript 檔案,為我們的專案提供 Web3 功能。
+
+## 步驟 2:查看我們的入門檔案 {#step-2-check-out-our-starter-files}
+
+在我們開始打碼前,在起始檔案裡面檢查一下有甚麼是已經提供給我們發展專案是很重要的。
+
+### 讓你的 React 專案動起來 {#get-your-react-project-running}
+
+讓我們透過在我們的瀏覽器內運行這個「反應」專案來開始是日的教程吧: 「反應」的美在於一旦我們在瀏覽器內已經有在運行自己的專案,我們儲存下來的任何改變都將會被實時更新到我們的瀏覽器裡。
+
+要讓專案動起來,請導覽至 `minter-starter-files` 資料夾的根目錄,然後在你的終端機中執行 `npm install` 來安裝專案的依賴項:
+
+```bash
+cd minter-starter-files
+npm install
+```
+
+安裝完成後,在你的終端機中執行 `npm start`:
+
+```bash
+npm start
+```
+
+此舉理應會在你的瀏覽器內打開網站(http://localhost:3000/),在那裡你將會看見我們專案的前端。 它應該由三個欄位組成:一個輸入往你的NFT資產所在地的連結空位、一個輸入你的NFT名字的空格,以及一個提供形容段落的欄位。
+
+如你試圖點擊按鈕「連結錢包」或「挖取NFT」,你將會注意到它們不會如常運作 - 這是因為我們將仍然需要設計一下它們的功能! :\)
+
+### Minter.js 元件 {#minter-js}
+
+**注意:** 請確保你位在 `minter-starter-files` 資料夾,而不是 `nft-minter` 資料夾!
+
+讓我們回到編輯器中的 `src` 資料夾,並開啟 `Minter.js` 檔案。 這個動作在我們理解該檔案內所有東西上有著超級關鍵的作用,因為它是我們將會首先處理的第一個「反應」組件。
+
+在此檔案的最頂部,有著我們將會在特定事件後更新的一些狀態變數。
+
+```javascript
+//狀態變數
+const [walletAddress, setWallet] = useState("")
+const [status, setStatus] = useState("")
+const [name, setName] = useState("")
+const [description, setDescription] = useState("")
+const [url, setURL] = useState("")
+```
+
+從來沒有聽過「反應」狀態變數或者狀態勾手嗎? 查看[這些](https://legacy.reactjs.org/docs/hooks-state.html)文件。
+
+在此是每個變數代表的意思:
+
+- `walletAddress` - 一個儲存使用者錢包位址的字串
+- `status` - 一個包含訊息的字串,會顯示在 UI 底部
+- `name` - 一個儲存 NFT 名稱的字串
+- `description` - 一個儲存 NFT 描述的字串
+- `url` - 一個連結到 NFT 數位資產的字串
+
+在狀態變數之後,你會看到三個未實作的函式:`useEffect`、`connectWalletPressed` 和 `onMintPressed`。 你會注意到所有這些函式都是 `async`,這是因為我們將在其中進行非同步的 API 呼叫! 它們的名稱是以各自的功能來命名的:
+
+```javascript
+useEffect(async () => {
+ //TODO: 實作
+}, [])
+
+const connectWalletPressed = async () => {
+ //TODO: 實作
+}
+
+const onMintPressed = async () => {
+ //TODO: 實作
+}
+```
+
+- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html) - 這是一個 React hook,會在你的元件渲染後被呼叫。 因為它傳入了一個空陣列 `[]` 的 prop (見第 3 行),所以它只會在元件的_第一次_渲染時被呼叫。 在此我們將會回呼我們的錢包聽眾以及其他錢包功能來更新我們的UI,去反思一下一個錢包是否已經被連結好。
+- `connectWalletPressed` - 這個函式將被呼叫,用來將使用者的 MetaMask 錢包連接到我們的去中心化應用程式。
+- `onMintPressed` - 這個函式將被呼叫,用來鑄造使用者的 NFT。
+
+接近這份檔案的尾聲,我們得到了我們組件的UI。 如果你仔細查看這段程式碼,你會注意到當對應的文字欄位中的輸入改變時,我們會更新 `url`、`name` 和 `description` 這些狀態變數。
+
+你也會看到當 ID 為 `mintButton` 和 `walletButton` 的按鈕被點擊時,`connectWalletPressed` 和 `onMintPressed` 會分別被呼叫。
+
+```javascript
+//我們元件的 UI
+return (
+
+
+
+
+
🧙♂️ Alchemy NFT 鑄造器
+
+ 只需加入你資產的連結、名稱和描述,然後按下「鑄造」。
+
+
+
+
{status}
+
+)
+```
+
+最後,讓我們強調一下這個Minter組件會在哪裡被添加。
+
+如果你查看 `App.js` 檔案,這是 React 中的主要元件,作為所有其他元件的容器,你會看到我們的 Minter 元件在第 7 行被注入。
+
+**在本教學中,我們只會編輯 `Minter.js` 檔案,並在 `src` 資料夾中新增檔案。**
+
+現在我們明白了到底是在跟甚麼東西一起操作後,讓我們設定自己的以太虛擬坊錢包吧!
+
+## 設定你的以太坊錢包 {#set-up-your-ethereum-wallet}
+
+使用者需要將他們的以太坊錢包連接到你的去中心化應用程式,才能與你的智能合約互動。
+
+### 下載 MetaMask {#download-metamask}
+
+為此教學,我們將會使用 MetaMask。它是一個在瀏覽器上管理你的乙太坊帳戶地址的虛擬錢包。 如果你想更深入了解以太坊上的交易如何運作,請查看[此頁面](/developers/docs/transactions/)。
+
+您可以在[這裡](https://metamask.io/download)免費下載並建立 MetaMask 帳戶。 當你正在創建一個帳戶時,或者如果你已經持有一個帳戶,你要確定在右上方把模式轉移到「Ropsten測試網路」之上 \(因為這樣我們才不會處理到真實金錢\)。
+
+### 從水龍頭取得以太幣 {#add-ether-from-faucet}
+
+為了要挖取我們的NFT(或是簽署任何在以太坊區塊鏈的交易),我們將需要一些假ETH。 要取得 Eth,你可以前往 [Ropsten 水龍頭](https://faucet.ropsten.be/),輸入你的 Ropsten 帳戶位址,然後點擊「Send Ropsten Eth」。 你應該很快便能在你的MetaMask帳戶裡看見ETH!
+
+### 檢查你的餘額 {#check-your-balance}
+
+為了再次確認我們的餘額,讓我們使用 [Alchemy 的 composer 工具](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) 發出一個 [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) 請求。 這將會把我們錢包內的以太結餘回傳。 在你輸入自己的MetaMask帳戶地址,並且點下「寄送請求」後,你理應會看見一個這樣子的回應:
+
+```text
+{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}
+```
+
+**注意:** 此結果的單位是 wei,不是 eth。 Wei是一個被用來計算以太最少分數的單位。 要把wei換算到ETH的算術是:1 ETH = 10¹⁸ wei。 所以,如果我們要換算 0xde0b6b3a7640000 到小數點,我們會得到 1\*10¹⁸的結果,它相當於一個ETH的數值。
+
+哈! 我們的假錢都在這!
+
+## 將 MetaMask 連接到你的 UI {#connect-metamask-to-your-UI}
+
+既然我們的 MetaMask 錢包已經設定好了,就讓我們把去中心化應用程式連接到它吧!
+
+因為我們想遵循 [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) 範式,所以我們要建立一個獨立的檔案,其中包含管理我們去中心化應用程式的邏輯、資料和規則的函式,然後將這些函式傳遞給我們的前端 (我們的 Minter.js 元件)。
+
+### `connectWallet` 函式 {#connect-wallet-function}
+
+為此,讓我們在你的 `src` 目錄中建立一個名為 `utils` 的新資料夾,並在其中加入一個名為 `interact.js` 的檔案,它將包含我們所有錢包和智能合約的互動函式。
+
+在我們的 `interact.js` 檔案中,我們將撰寫一個 `connectWallet` 函式,然後在我們的 `Minter.js` 元件中匯入並呼叫它。
+
+在你的 `interact.js` 檔案中,加入以下內容
+
+```javascript
+export const connectWallet = async () => {
+ if (window.ethereum) {
+ try {
+ const addressArray = await window.ethereum.request({
+ method: "eth_requestAccounts",
+ })
+ const obj = {
+ status: "👆🏽 請在上方文字欄位中寫入一則訊息。",
+ address: addressArray[0],
+ }
+ return obj
+ } catch (err) {
+ return {
+ address: "",
+ status: "😥 " + err.message,
+ }
+ }
+ } else {
+ return {
+ address: "",
+ status: (
+
+
+ {" "}
+ 🦊
+ 你必須在瀏覽器中安裝 MetaMask,一個虛擬的以太坊錢包。
+
+
+
+ ),
+ }
+ }
+}
+```
+
+讓我們一起分解這個程式碼的工作:
+
+首先,我們的函式會檢查你的瀏覽器中是否啟用了 `window.ethereum`。
+
+`window.ethereum` 是由 MetaMask 和其他錢包提供者注入的全域 API,允許網站請求使用者的以太坊帳戶。 如果請求被接納,它能夠從連結成功的用戶那裡的區塊鏈中讀取數據,並且會向用戶提出簽署訊息和交易的建議。 查看 [MetaMask 文件](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)以獲得更多資訊!
+
+如果 `window.ethereum` _不存在_,那表示 MetaMask 沒有安裝。 這會回傳一個 JSON 物件,其中回傳的 `address` 是一個空字串,而 `status` JSX 物件則傳達使用者必須安裝 MetaMask 的訊息。
+
+**我們撰寫的大部分函式都會回傳 JSON 物件,我們可以用它來更新我們的狀態變數和 UI。**
+
+現在如果 `window.ethereum` _存在_,事情就變得有趣了。
+
+使用 try/catch 迴圈,我們將透過呼叫 [`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts) 來嘗試連接 MetaMask。 呼叫這個函式會在瀏覽器中開啟 MetaMask,提示使用者將他們的錢包連接到你的去中心化應用程式。
+
+- 如果使用者選擇連接,`method: "eth_requestAccounts"` 會回傳一個陣列,其中包含所有連接到此去中心化應用程式的使用者帳戶位址。 總而言之,我們的 `connectWallet` 函式會回傳一個 JSON 物件,其中包含此陣列中的_第一個_ `address` (見第 9 行) 和一則 `status` 訊息,提示使用者向智能合約寫入一則訊息。
+- 如果使用者拒絕連接,那麼 JSON 物件將包含一個空字串作為回傳的 `address`,以及一則反映使用者拒絕連接的 `status` 訊息。
+
+### 將 connectWallet 函式新增至你的 Minter.js UI 元件 {#add-connect-wallet}
+
+既然我們已經寫好了 `connectWallet` 函式,就把它連接到我們的 `Minter.js` 元件吧。
+
+首先,我們必須將函式匯入到 `Minter.js` 檔案中,方法是在 `Minter.js` 檔案的頂部新增 `import { connectWallet } from "./utils/interact.js";`。 你的 `Minter.js` 的前 11 行現在應該看起來像這樣:
+
+```javascript
+import { useEffect, useState } from "react";
+import { connectWallet } from "./utils/interact.js";
+
+const Minter = (props) => {
+
+ //狀態變數
+ const [walletAddress, setWallet] = useState("");
+ const [status, setStatus] = useState("");
+ const [name, setName] = useState("");
+ const [description, setDescription] = useState("");
+ const [url, setURL] = useState("");
+```
+
+然後,在我們的 `connectWalletPressed` 函式內部,我們將呼叫匯入的 `connectWallet` 函式,如下所示:
+
+```javascript
+const connectWalletPressed = async () => {
+ const walletResponse = await connectWallet()
+ setStatus(walletResponse.status)
+ setWallet(walletResponse.address)
+}
+```
+
+注意到我們大部分的功能是如何從 `interact.js` 檔案中抽象出來,與 `Minter.js` 元件分離的嗎? 這是我們跟M-V-C規範相容的做法!
+
+在 `connectWalletPressed` 中,我們只需對匯入的 `connectWallet` 函式進行一個 await 呼叫,並利用其回應,透過它們的 state hooks 更新我們的 `status` 和 `walletAddress` 變數。
+
+現在,讓我們儲存 `Minter.js` 和 `interact.js` 這兩個檔案,並測試一下我們目前的 UI。
+
+在「localhost:3000」打開你的瀏覽器,並在頁面的右上方按下按鍵「連結起錢包」。
+
+如果你已安裝 MetaMask,系統應該會提示你將錢包連接到你的去中心化應用程式。 請接受進行連結的邀請。
+
+你應會看得到錢包的按鈕現時反映了你的地址被連結好了。
+
+接下來,試著重新整理頁面... 這很奇怪。 我們的錢包按鈕會鼓勵我們對MetaMask進行連結,就算它已經被連結好了。。。。。。
+
+但是,請不要擔心! 我們可以透過實作一個名為 `getCurrentWalletConnected` 的函式輕鬆解決這個問題,該函式會檢查是否有位址已經連接到我們的去中心化應用程式,並相應地更新我們的 UI!
+
+### getCurrentWalletConnected 函式 {#get-current-wallet}
+
+在你的 `interact.js` 檔案中,新增以下 `getCurrentWalletConnected` 函式:
+
+```javascript
+export const getCurrentWalletConnected = async () => {
+ if (window.ethereum) {
+ try {
+ const addressArray = await window.ethereum.request({
+ method: "eth_accounts",
+ })
+ if (addressArray.length > 0) {
+ return {
+ address: addressArray[0],
+ status: "👆🏽 請在上方文字欄位中寫入一則訊息。",
+ }
+ } else {
+ return {
+ address: "",
+ status: "🦊 請使用右上角的按鈕連接到 MetaMask。",
+ }
+ }
+ } catch (err) {
+ return {
+ address: "",
+ status: "😥 " + err.message,
+ }
+ }
+ } else {
+ return {
+ address: "",
+ status: (
+
+
+ {" "}
+ 🦊
+ 你必須在瀏覽器中安裝 MetaMask,一個虛擬的以太坊錢包。
+
+
+
+ ),
+ }
+ }
+}
+```
+
+這段程式碼與我們剛才寫的 `connectWallet` 函式_非常_相似。
+
+主要的區別在於,我們不是呼叫 `eth_requestAccounts` 方法 (這會開啟 MetaMask 讓使用者連接他們的錢包),而是在這裡呼叫 `eth_accounts` 方法,它只會回傳一個包含當前連接到我們去中心化應用程式的 MetaMask 位址的陣列。
+
+為了看到這個函式的實際作用,讓我們在 `Minter.js` 元件的 `useEffect` 函式中呼叫它。
+
+就像我們對 `connectWallet` 所做的一樣,我們必須將這個函式從 `interact.js` 檔案匯入到 `Minter.js` 檔案中,如下所示:
+
+```javascript
+import { useEffect, useState } from "react"
+import {
+ connectWallet,
+ getCurrentWalletConnected, //在此匯入
+} from "./utils/interact.js"
+```
+
+現在,我們只需在 `useEffect` 函式中呼叫它:
+
+```javascript
+useEffect(async () => {
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+}, [])
+```
+
+注意,我們使用對 `getCurrentWalletConnected` 呼叫的回應來更新我們的 `walletAddress` 和 `status` 狀態變數。
+
+一旦你已經添加好了這個程式碼,嘗試刷新我們的瀏覽器視窗。 這個按鈕應該會跟你說:「你已經連結好了。」,然後會顯出一個你錢包被連結好的地址的預視 - 就算在你刷新之後也會這樣!
+
+### 實作 addWalletListener {#implement-add-wallet-listener}
+
+我們去中心化應用程式錢包設定的最後一個步驟是實作錢包監聽器,這樣當我們錢包的狀態改變時 (例如使用者中斷連線或切換帳戶),我們的 UI 就會更新。
+
+在你的 `Minter.js` 檔案中,新增一個 `addWalletListener` 函式,如下所示:
+
+```javascript
+function addWalletListener() {
+ if (window.ethereum) {
+ window.ethereum.on("accountsChanged", (accounts) => {
+ if (accounts.length > 0) {
+ setWallet(accounts[0])
+ setStatus("👆🏽 請在上方文字欄位中寫入一則訊息。")
+ } else {
+ setWallet("")
+ setStatus("🦊 請使用右上角的按鈕連接到 MetaMask。")
+ }
+ })
+ } else {
+ setStatus(
+
+ {" "}
+ 🦊
+ 你必須在瀏覽器中安裝 MetaMask,一個虛擬的以太坊錢包。
+
+
+ )
+ }
+}
+```
+
+讓我們趕快分析在這裡發生的事情:
+
+- 首先,我們的函式會檢查 `window.ethereum` 是否已啟用 (即 MetaMask 已安裝)。
+ - 如果沒有啟用,我們只需將 `status` 狀態變數設定為一個 JSX 字串,提示使用者安裝 MetaMask。
+ - 如果已啟用,我們在第 3 行設定監聽器 `window.ethereum.on("accountsChanged")`,它會監聽 MetaMask 錢包的狀態變化,包括使用者將額外帳戶連接到去中心化應用程式、切換帳戶或中斷帳戶連線時。 如果至少有一個帳戶已連接,`walletAddress` 狀態變數會更新為監聽器回傳的 `accounts` 陣列中的第一個帳戶。 否則,`walletAddress` 會被設定為空字串。
+
+最後,我們必須在 `useEffect` 函式中呼叫它:
+
+```javascript
+useEffect(async () => {
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+
+ addWalletListener()
+}, [])
+```
+
+然後就沒有然後了! 我們已經完成了所有有關我們錢包功能的編程! 現在我們的錢包已被設定好,讓我們探索一下這樣挖取我們的NFT吧!
+
+## NFT 元資料入門 {#nft-metadata-101}
+
+那麼記得我們剛才在此教程的第零步驟提到的NFT元數據 - 它把一個虛擬的NFT帶到現實生活中,容許它持有特質,像是一個電子資產、名稱、描述,還有其他屬性。
+
+我們需要將此元資料設定為一個 JSON 物件並儲存它,這樣我們就可以在呼叫智能合約的 `mintNFT` 函式時,將它作為 `tokenURI` 參數傳入。
+
+在欄位的文字:「往資產的連結」、「名稱」,「描述」將會由我們NFT元數據的不同特質而組成。 我們將會把這些文字整理成為一個JSON客體,但是那裡有能讓我們能夠選擇把這個客體儲存好的幾個位置:
+
+- 我們可以把它安放在以太坊區塊鏈上;但是,這樣做的花費會非常昂貴。
+- 我們可以把它儲存在一個中心化服務器上,像 AWS或Firebase。 但是那樣可能會違背我們的去中央化宗旨。
+- 我們也可以使用IPFS,它是一個去中央化的規條和朋輩間的網路,讓我們在一個分配檔案系統內儲存及分享數據。 因為這個規條是去中央化和免費的,它是我們的最佳選項!
+
+為了將我們的元資料儲存在 IPFS 上,我們將使用 [Pinata](https://pinata.cloud/),這是一個方便的 IPFS API 和工具包。 在下一步,我們將會逐步解釋怎樣使用它!
+
+## 使用 Pinata 將你的元資料釘選到 IPFS {#use-pinata-to-pin-your-metadata-to-IPFS}
+
+如果你沒有 [Pinata](https://pinata.cloud/) 帳戶,請[在此](https://app.pinata.cloud/auth/signup)註冊一個免費帳戶,並完成驗證你的電子郵件和帳戶的步驟。
+
+### 建立你的 Pinata API 金鑰 {#create-pinata-api-key}
+
+導覽至 [https://pinata.cloud/keys](https://pinata.cloud/keys) 頁面,然後選取頂部的「New Key」按鈕,將 Admin 小工具設定為啟用,並為你的金鑰命名。
+
+你便會看見一個彈出視窗,內有你的API資訊。 確保把這個鑰匙放在某個安全的地方。
+
+現在我們的鑰匙被設定好了,讓我們把它添加到專案中來使用它。
+
+### 建立一個 .env 檔案 {#create-a-env}
+
+我們能夠在一個環境檔案中安全地儲存我們的Pinata金鑰和祕密。 讓我們在你的專案目錄中安裝 [dotenv 套件](https://www.npmjs.com/package/dotenv)。
+
+在你的終端機中開啟一個新分頁 (與執行 local host 的分頁分開),並確保你在 `minter-starter-files` 資料夾中,然後在終端機中執行以下指令:
+
+```text
+npm install dotenv --save
+```
+
+接下來,在你的 `minter-starter-files` 的根目錄中建立一個 `.env` 檔案,方法是在你的指令列中輸入以下內容:
+
+```javascript
+vim.env
+```
+
+這會在 vim (一個文字編輯器) 中開啟你的 `.env` 檔案。 在你的鍵盤上以這個順序來點擊按鍵「esc」+「:」+「q」進行儲存。
+
+接下來,在 VSCode 中,導覽至你的 `.env` 檔案,並將你的 Pinata API 金鑰和 API 密鑰加入其中,如下所示:
+
+```text
+REACT_APP_PINATA_KEY =
+REACT_APP_PINATA_SECRET =
+```
+
+儲存檔案,然後你就準備好開始為了上載自己JSON元數據到IPFS而書寫的功能了!
+
+### 實作 pinJSONToIPFS {#pin-json-to-ipfs}
+
+幸運的是,Pinata 有一個[專門用於將 JSON 資料上傳到 IPFS 的 API](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json) 和一個方便的 JavaScript 與 axios 範例,我們稍作修改即可使用。
+
+在你的 `utils` 資料夾中,讓我們建立另一個名為 `pinata.js` 的檔案,然後從 .env 檔案匯入我們的 Pinata 密鑰和金鑰,如下所示:
+
+```javascript
+require("dotenv").config()
+const key = process.env.REACT_APP_PINATA_KEY
+const secret = process.env.REACT_APP_PINATA_SECRET
+```
+
+接下來,將下面額外的程式碼貼到你的 `pinata.js` 檔案中。 不用擔心,我們將會把每個步驟都挑出來細說!
+
+```javascript
+require("dotenv").config()
+const key = process.env.REACT_APP_PINATA_KEY
+const secret = process.env.REACT_APP_PINATA_SECRET
+
+const axios = require("axios")
+
+export const pinJSONToIPFS = async (JSONBody) => {
+ const url = `https://api.pinata.cloud/pinning/pinJSONToIPFS`
+ //向 Pinata 發送 axios POST 請求 ⬇️
+ return axios
+ .post(url, JSONBody, {
+ headers: {
+ pinata_api_key: key,
+ pinata_secret_api_key: secret,
+ },
+ })
+ .then(function (response) {
+ return {
+ success: true,
+ pinataUrl:
+ "https://gateway.pinata.cloud/ipfs/" + response.data.IpfsHash,
+ }
+ })
+ .catch(function (error) {
+ console.log(error)
+ return {
+ success: false,
+ message: error.message,
+ }
+ })
+}
+```
+
+所以,這個程式碼到底是用來做甚麼的呢?
+
+首先,它匯入了 [axios](https://www.npmjs.com/package/axios),這是一個基於 promise 的 HTTP 用戶端,適用於瀏覽器和 node.js,我們將用它來向 Pinata 發出請求。
+
+然後我們有我們的非同步函式 `pinJSONToIPFS`,它接收一個 `JSONBody` 作為其輸入,並在其標頭中包含 Pinata API 金鑰和密鑰,所有這些都是為了向他們的 `pinJSONToIPFS` API 發出 POST 請求。
+
+- 如果這個 POST 請求成功,那麼我們的函式會回傳一個 JSON 物件,其中 `success` 布林值為 true,以及我們元資料被釘選的 `pinataUrl`。 我們將使用這個回傳的 `pinataUrl` 作為我們智能合約鑄造函式的 `tokenURI` 輸入。
+- 如果此 post 請求失敗,那麼我們的函式會回傳一個 JSON 物件,其中 `success` 布林值為 false,以及一個傳達我們錯誤的 `message` 字串。
+
+與我們的 `connectWallet` 函式回傳類型一樣,我們回傳 JSON 物件,以便我們可以使用它們的參數來更新我們的狀態變數和 UI。
+
+## 載入你的智能合約 {#load-your-smart-contract}
+
+既然我們有辦法透過我們的 `pinJSONToIPFS` 函式將我們的 NFT 元資料上傳到 IPFS,我們就需要一種方法來載入我們智能合約的實例,以便我們可以呼叫它的 `mintNFT` 函式。
+
+如前所述,在本教學中,我們將使用[這個現有的 NFT 智能合約](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE);然而,如果你想學習我們是如何製作它的,或自己製作一個,我們強烈建議你查看我們的另一篇教學,["如何建立一個 NFT"](https://www.alchemy.com/docs/how-to-create-an-nft)。
+
+### 合約 ABI {#contract-abi}
+
+如果你仔細檢查過我們的檔案,你會注意到在我們的 `src` 目錄中,有一個 `contract-abi.json` 檔案。 為了特別註明哪一個功能會將被一份合約啟發,並且保障這個功能將會回返在你預計體裁內的數據,一個ABI是達成此目的基本條件。
+
+我們也將會需要一個Alchemy的API鑰匙,還有Alchemy Web3的API來連結到以太坊區塊鏈,並且把我們的智慧型合約上載。
+
+### 建立你的 Alchemy API 金鑰 {#create-alchemy-api}
+
+如果你還沒有 Alchemy 帳戶,[請在此免費註冊](https://alchemy.com/?a=eth-org-nft-minter)。
+
+一旦你已經創建好一個Alchemy的帳戶,你可以通過建立一個程式來生成一個API鑰匙。 這將會允許我們發送請求到Ropsten的測試網上。
+
+在你的「Alchemy里程表」內導航至頁面「創建程式」(“Create App”)。這動作能夠透過把在導航列條內的選項「程式」懸停,並減低「創建程式」來完成。
+
+命名你的程式。我們已經選擇好「我的最初NFT!」作為名稱,提供一個短段描述,選取「盤點」來選擇為你的程式藏書的理想環境,並選擇「Ropsten」作為你的網路。
+
+點擊「創建程式」然後就好了! 你的程式應該會在下列圖表中出現。
+
+非常好,所以現在我們已經創建好我們的HTTP的Alchemy,API超連結。把它複製到你的剪貼板。。。。。。
+
+…然後讓我們把它加到我們的 `.env` 檔案中。 好了,你的 .env檔案應該是像這個樣子的:
+
+```text
+REACT_APP_PINATA_KEY =
+REACT_APP_PINATA_SECRET =
+REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/
+```
+
+現在我們有了合約 ABI 和 Alchemy API 金鑰,我們準備好使用 [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) 來載入我們的智能合約了。
+
+### 設定你的 Alchemy Web3 端點和合約 {#setup-alchemy-endpoint}
+
+首先,如果你還沒有安裝 [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3),你需要到終端機的主目錄 `nft-minter-tutorial` 來安裝它:
+
+```text
+cd ..
+npm install @alch/alchemy-web3
+```
+
+接下來讓我們回到 `interact.js` 檔案。 在檔案的頂部,新增下列程式碼從你的 .env檔案中輸入你的Alchemy金鑰,並且設定你Alchemy Web3的重點:
+
+```javascript
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+```
+
+[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) 是 [Web3.js](https://docs.web3js.org/) 的一個包裝器,提供了增強的 API 方法和其他關鍵優勢,讓你的 web3 開發者生活更輕鬆。 它是被設計成最低配置,因此你能夠在你的應用程式內馬上開始使用它!
+
+之後,讓我們往我們的檔案裡添加我們的合約ABI以及合約地址。
+
+```javascript
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+
+const contractABI = require("../contract-abi.json")
+const contractAddress = "0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE"
+```
+
+一旦我們有以上兩者,我們已經準備好開始為挖礦功能進行編碼了!
+
+## 實作 mintNFT 函式 {#implement-the-mintnft-function}
+
+在你的 `interact.js` 檔案中,讓我們定義我們的函式 `mintNFT`,顧名思義,它將鑄造我們的 NFT。
+
+因為我們將製作無數的非同步回呼 \(往Pinata釘下我們往IPFS,Alchemy Web3上載的元數據來載入我們的智慧型合約,以及MetaMask來為我們的交易簽署\),我們的功能將同時被設定為非同步的。
+
+我們函式的三個輸入將是我們數位資產的 `url`、`name` 和 `description`。 在 `connectWallet` 函式下方新增以下函式簽章:
+
+```javascript
+export const mintNFT = async (url, name, description) => {}
+```
+
+### 輸入錯誤處理 {#input-error-handling}
+
+自然地,在功能開始時持有某些輸入錯誤的處理方法是合乎常理的。所以如果我們的輸入指標不正確的話,我們會離開此功能。 在我們的功能內,讓我們新增以下程式碼:
+
+```javascript
+export const mintNFT = async (url, name, description) => {
+ //錯誤處理
+ if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
+ return {
+ success: false,
+ status: "❗鑄造前請確保所有欄位都已填寫完畢。",
+ }
+ }
+}
+```
+
+基本上,如果任何輸入參數是空字串,那麼我們會回傳一個 JSON 物件,其中 `success` 布林值為 false,而 `status` 字串則傳達我們 UI 中的所有欄位都必須填寫完整。
+
+### 將元資料上傳至 IPFS {#upload-metadata-to-ipfs}
+
+一旦我們知道我們的元資料格式正確,下一步就是將它包裝成一個 JSON 物件,並透過我們寫的 `pinJSONToIPFS` 將它上傳到 IPFS!
+
+為此,我們首先需要將 `pinJSONToIPFS` 函式匯入到我們的 `interact.js` 檔案中。 在 `interact.js` 的最頂部,讓我們新增:
+
+```javascript
+import { pinJSONToIPFS } from "./pinata.js"
+```
+
+回想一下,`pinJSONToIPFS` 接收一個 JSON 主體。 所以在我們呼叫它之前,我們需要將我們的 `url`、`name` 和 `description` 參數格式化成一個 JSON 物件。
+
+讓我們更新我們的程式碼,以建立一個名為 `metadata` 的 JSON 物件,然後使用這個 `metadata` 參數呼叫 `pinJSONToIPFS`:
+
+```javascript
+export const mintNFT = async (url, name, description) => {
+ //錯誤處理
+ if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
+ return {
+ success: false,
+ status: "❗鑄造前請確保所有欄位都已填寫完畢。",
+ }
+ }
+
+ //製作元資料
+ const metadata = new Object()
+ metadata.name = name
+ metadata.image = url
+ metadata.description = description
+
+ //進行 pinata 呼叫
+ const pinataResponse = await pinJSONToIPFS(metadata)
+ if (!pinataResponse.success) {
+ return {
+ success: false,
+ status: "😢 上傳你的 tokenURI 時出了點問題。",
+ }
+ }
+ const tokenURI = pinataResponse.pinataUrl
+}
+```
+
+注意,我們將對 `pinJSONToIPFS(metadata)` 的呼叫回應儲存在 `pinataResponse` 物件中。 然後,我們對這個客體進行語法分析以檢查任何可能的語法錯誤。
+
+如果有錯誤,我們會回傳一個 JSON 物件,其中 `success` 布林值為 false,而我們的 `status` 字串則傳達我們的呼叫失敗。 否則,我們從 `pinataResponse` 中提取 `pinataURL` 並將其儲存為我們的 `tokenURI` 變數。
+
+現在是時候使用Alchemy Web3的API來上載我們的智慧型合約。我們把它們在自家檔案的頂部進行了初始化。 將以下程式碼行新增到 `mintNFT` 函式的底部,以在 `window.contract` 全域變數上設定合約:
+
+```javascript
+window.contract = await new web3.eth.Contract(contractABI, contractAddress)
+```
+
+最後要加入我們 `mintNFT` 函式的是我們的以太坊交易:
+
+```javascript
+//設定你的以太坊交易
+const transactionParameters = {
+ to: contractAddress, // 必填,除非是合約發布。
+ from: window.ethereum.selectedAddress, // 必須與使用者目前的位址相符。
+ data: window.contract.methods
+ .mintNFT(window.ethereum.selectedAddress, tokenURI)
+ .encodeABI(), //呼叫 NFT 智能合約
+}
+
+//透過 MetaMask 簽署交易
+try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ success: true,
+ status:
+ "✅ 在 Etherscan 上查看你的交易:https://ropsten.etherscan.io/tx/" +
+ txHash,
+ }
+} catch (error) {
+ return {
+ success: false,
+ status: "😥 出了點問題:" + error.message,
+ }
+}
+```
+
+如你已經對以太坊的交易很熟悉了,你將會注意到這個結構跟你以前看過的那些結構是蠻相近的。
+
+- 首先,我們設定好我們交易的指標們。
+ - `to` 指定接收方位址 (我們的智能合約)
+ - `from` 指定交易的簽署者 (使用者連接到 MetaMask 的位址:`window.ethereum.selectedAddress`)
+ - `data` 包含對我們智能合約 `mintNFT` 方法的呼叫,該方法接收我們的 `tokenURI` 和使用者錢包位址 `window.ethereum.selectedAddress` 作為輸入
+- 然後,我們進行一個 await 呼叫 `window.ethereum.request`,我們要求 MetaMask 簽署交易。 注意,在這個請求中,我們指定了我們的 eth 方法 (eth_SentTransaction) 並傳入了我們的 `transactionParameters`。 在這時機,MetaMask將會在瀏覽器中被開啟,然後鼓勵用戶去簽署或拒絕該筆交易。
+ - 如果交易成功,函式將回傳一個 JSON 物件,其中布林值 `success` 設定為 true,而 `status` 字串則提示使用者查看 Etherscan 以獲取有關其交易的更多資訊。
+ - 如果交易失敗,函式將回傳一個 JSON 物件,其中 `success` 布林值設定為 false,而 `status` 字串則傳達錯誤訊息。
+
+總而言之,我們的 `mintNFT` 函式應該看起來像這樣:
+
+```javascript
+export const mintNFT = async (url, name, description) => {
+ //錯誤處理
+ if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
+ return {
+ success: false,
+ status: "❗鑄造前請確保所有欄位都已填寫完畢。",
+ }
+ }
+
+ //製作元資料
+ const metadata = new Object()
+ metadata.name = name
+ metadata.image = url
+ metadata.description = description
+
+ //pinata 釘選請求
+ const pinataResponse = await pinJSONToIPFS(metadata)
+ if (!pinataResponse.success) {
+ return {
+ success: false,
+ status: "😢 上傳你的 tokenURI 時出了點問題。",
+ }
+ }
+ const tokenURI = pinataResponse.pinataUrl
+
+ //載入智能合約
+ window.contract = await new web3.eth.Contract(contractABI, contractAddress) //loadContract();
+
+ //設定你的以太坊交易
+ const transactionParameters = {
+ to: contractAddress, // 必填,除非是合約發布。
+ from: window.ethereum.selectedAddress, // 必須與使用者目前的位址相符。
+ data: window.contract.methods
+ .mintNFT(window.ethereum.selectedAddress, tokenURI)
+ .encodeABI(), //呼叫 NFT 智能合約
+ }
+
+ //透過 MetaMask 簽署交易
+ try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ success: true,
+ status:
+ "✅ 在 Etherscan 上查看你的交易:https://ropsten.etherscan.io/tx/" +
+ txHash,
+ }
+ } catch (error) {
+ return {
+ success: false,
+ status: "😥 出了點問題:" + error.message,
+ }
+ }
+}
+```
+
+那是一個大型功能呀! 現在,我們只需要將我們的 `mintNFT` 函式連接到我們的 `Minter.js` 元件...
+
+## 將 mintNFT 連接到我們的 Minter.js 前端 {#connect-our-frontend}
+
+打開你的 `Minter.js` 檔案,並將頂部的 `import { connectWallet, getCurrentWalletConnected } from "./utils/interact.js";` 行更新為:
+
+```javascript
+import {
+ connectWallet,
+ getCurrentWalletConnected,
+ mintNFT,
+} from "./utils/interact.js"
+```
+
+最後,實作 `onMintPressed` 函式,以對你匯入的 `mintNFT` 函式進行 await 呼叫,並更新 `status` 狀態變數以反映我們的交易是成功還是失敗:
+
+```javascript
+const onMintPressed = async () => {
+ const { status } = await mintNFT(url, name, description)
+ setStatus(status)
+}
+```
+
+## 將你的 NFT 部署到線上網站 {#deploy-your-NFT}
+
+準備好實時把你的專案提供給用戶們去進行互動了嗎? 查看[此教學](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online)以將你的鑄造器部署到線上網站。
+
+最終一步。。。。。。
+
+## 席捲區塊鏈世界 {#take-the-blockchain-world-by-storm}
+
+開玩笑的,你成功堅持到教程的最終點了!
+
+可以透過建立一個NFT挖礦者來複習。你已經成功學會怎樣:
+
+- 通過你的前端專案連接到 MetaMask
+- 在前端調用智慧型合約的方法
+- 使用MetaMask簽署交易
+
+想必你會希望能夠在錢包中展示透過你的去中心化應用程式所鑄造的 NFT——所以請務必查看我們的快速教學 [如何在你的錢包中查看你的 NFT](https://www.alchemy.com/docs/how-to-view-your-nft-in-your-mobile-wallet)!
+
+一如既往,如果你有任何問題,我們會在 [Alchemy Discord](https://discord.gg/gWuC7zB) 提供協助。 我們不能更迫切地看見你是怎樣運用此篇教程的概念來建立自己在不遠未來的專案們了!
diff --git a/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
new file mode 100644
index 00000000000..ef75f354e68
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
@@ -0,0 +1,1331 @@
+---
+title: "Optimism 標準跨鏈橋合約深入解析"
+description: Optimism 的標準跨鏈橋如何運作? 為什麼它會這樣運作?
+author: 作者:Ori Pomerantz
+tags: [ "穩固", "跨鏈橋", "Layer 2" ]
+skill: intermediate
+published: 2022-03-30
+lang: zh-tw
+---
+
+[Optimism](https://www.optimism.io/) 是一種[樂觀卷軸](/developers/docs/scaling/optimistic-rollups/)。
+樂觀卷軸能以遠低於以太坊主網 (又稱為第一層或 L1) 的價格處理交易,因為交易只由少數節點處理,而非網路上每個節點都處理。
+同時,所有資料都會寫入 L1,因此所有內容都能以主網的完整性和可用性保證來證明和重建。
+
+若要在 Optimism (或任何其他 L2) 上使用 L1 資產,這些資產需要被[橋接](/bridges/#prerequisites)。
+達成此目的的其中一種方法是讓使用者在 L1 鎖定資產 (最常見的是 ETH 和 [ERC-20 代幣](/developers/docs/standards/tokens/erc-20/)),並在 L2 收到等值的資產來使用。
+最後,無論是誰持有這些資產,都可能會想把它們橋接回 L1。
+這麼做的時候,資產會在 L2 被銷毀,然後在 L1 釋放給使用者。
+
+這就是 [Optimism 標準跨鏈橋](https://docs.optimism.io/app-developers/bridging/standard-bridge)的運作方式。
+在本文中,我們將檢視該跨鏈橋的原始程式碼,以了解其運作方式,並將其作為編寫精良的 Solidity 程式碼範例來研究。
+
+## 控制流程 {#control-flows}
+
+該跨鏈橋有兩個主要流程:
+
+- 存款 (從 L1 到 L2)
+- 提款 (從 L2 到 L1)
+
+### 存款流程 {#deposit-flow}
+
+#### 第一層 {#deposit-flow-layer-1}
+
+1. 如果存入 ERC-20,存款人會給予跨鏈橋一筆額度,以花費正在存入的金額
+2. 存款人呼叫 L1 跨鏈橋 (`depositERC20`、`depositERC20To`、`depositETH` 或 `depositETHTo`)
+3. L1 跨鏈橋取得橋接資產的所有權
+ - ETH:資產由存款人作為呼叫的一部分進行轉移
+ - ERC-20:跨鏈橋使用存款人提供的額度將資產轉移給自己
+4. L1 跨鏈橋使用跨網域訊息機制在 L2 跨鏈橋上呼叫 `finalizeDeposit`
+
+#### 第二層 {#deposit-flow-layer-2}
+
+5. L2 跨鏈橋驗證對 `finalizeDeposit` 的呼叫是合法的:
+ - 來自跨網域訊息合約
+ - 最初來自 L1 上的跨鏈橋
+6. L2 跨鏈橋檢查 L2 上的 ERC-20 代幣合約是否正確:
+ - L2 合約回報其 L1 對應合約與代幣在 L1 上的來源合約相同
+ - L2 合約回報其支援正確的介面 ([使用 ERC-165](https://eips.ethereum.org/EIPS/eip-165))。
+7. 如果 L2 合約是正確的,則呼叫它以鑄造適當數量的代幣到適當的地址。 若否,則啟動提款程序,讓使用者可以在 L1 上取回代幣。
+
+### 提款流程 {#withdrawal-flow}
+
+#### 第二層 {#withdrawal-flow-layer-2}
+
+1. 提款人呼叫 L2 跨鏈橋 (`withdraw` 或 `withdrawTo`)
+2. L2 跨鏈橋銷毀屬於 `msg.sender` 的適當數量的代幣
+3. L2 跨鏈橋使用跨網域訊息機制在 L1 跨鏈橋上呼叫 `finalizeETHWithdrawal` 或 `finalizeERC20Withdrawal`
+
+#### 第一層 {#withdrawal-flow-layer-1}
+
+4. L1 跨鏈橋驗證對 `finalizeETHWithdrawal` 或 `finalizeERC20Withdrawal` 的呼叫是合法的:
+ - 來自跨網域訊息機制
+ - 最初來自 L2 上的跨鏈橋
+5. L1 跨鏈橋將適當的資產 (ETH 或 ERC-20) 轉移到適當的地址
+
+## 第一層程式碼 {#layer-1-code}
+
+這是在 L1 (以太坊主網) 上執行的程式碼。
+
+### IL1ERC20Bridge {#IL1ERC20Bridge}
+
+[此介面定義在此](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol)。
+它包含橋接 ERC-20 代幣所需的功能和定義。
+
+```solidity
+// SPDX-License-Identifier: MIT
+```
+
+[Optimism 的大部分程式碼都是在 MIT 授權條款下釋出](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-)。
+
+```solidity
+pragma solidity >0.5.0 <0.9.0;
+```
+
+在撰寫本文時,Solidity 的最新版本為 0.8.12。
+在 0.9.0 版本釋出前,我們不知道此程式碼是否與其相容。
+
+```solidity
+/**
+ * @title IL1ERC20Bridge
+ */
+interface IL1ERC20Bridge {
+ /**********
+ * 事件 *
+ **********/
+
+ event ERC20DepositInitiated(
+```
+
+在 Optimism 跨鏈橋的術語中,_deposit_ 指從 L1 到 L2 的轉移,而 _withdrawal_ 則指從 L2 到 L1 的轉移。
+
+```solidity
+ address indexed _l1Token,
+ address indexed _l2Token,
+```
+
+在大多數情況下,L1 上的 ERC-20 地址與 L2 上對等的 ERC-20 地址不同。
+[您可以在此處查看代幣地址清單](https://static.optimism.io/optimism.tokenlist.json)。
+`chainId` 為 1 的地址在 L1 (主網) 上,`chainId` 為 10 的地址在 L2 (Optimism) 上。
+另外兩個 `chainId` 值分別用於 Kovan 測試網 (42) 和 Optimistic Kovan 測試網 (69)。
+
+```solidity
+ address indexed _from,
+ address _to,
+ uint256 _amount,
+ bytes _data
+ );
+```
+
+可以為轉移新增註記,在這種情況下,它們會被新增到回報它們的事件中。
+
+```solidity
+ event ERC20WithdrawalFinalized(
+ address indexed _l1Token,
+ address indexed _l2Token,
+ address indexed _from,
+ address _to,
+ uint256 _amount,
+ bytes _data
+ );
+```
+
+同一個跨鏈橋合約處理雙向的轉移。
+在 L1 跨鏈橋的情況下,這表示存款的初始化和提款的最終確定。
+
+```solidity
+
+ /********************
+ * 公用函式 *
+ ********************/
+
+ /**
+ * @dev 取得相應 L2 跨鏈橋合約的地址。
+ * @return 相應 L2 跨鏈橋合約的地址。
+ */
+ function l2TokenBridge() external returns (address);
+```
+
+這個函式並非真正必要,因為在 L2 上它是一個預先部署的合約,所以地址永遠是 `0x4200000000000000000000000000000000000010`。
+它在這裡是為了與 L2 跨鏈橋對稱,因為 L1 跨鏈橋的地址並不容易知道。
+
+```solidity
+ /**
+ * @dev 將一定數量的 ERC20 存入呼叫者在 L2 上的餘額。
+ * @param _l1Token 我們正在存入的 L1 ERC20 的地址
+ * @param _l2Token L1 各自在 L2 的 ERC20 地址
+ * @param _amount 要存入的 ERC20 數量
+ * @param _l2Gas 在 L2 上完成存款所需的 Gas 限制。
+ * @param _data 可選資料,轉發到 L2。此資料僅為方便外部合約而提供。
+ * 除了強制執行最大長度外,這些合約對其內容不提供任何保證。
+ */
+ function depositERC20(
+ address _l1Token,
+ address _l2Token,
+ uint256 _amount,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external;
+```
+
+`_l2Gas` 參數是交易允許花費的 L2 Gas 數量。
+[在某個 (高) 限制內,這是免費的](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2),所以除非 ERC-20 合約在鑄造時做了非常奇怪的事情,否則應該不成問題。
+這個函式處理常見的情境,即使用者將資產橋接到不同區塊鏈上的同一個地址。
+
+```solidity
+ /**
+ * @dev 將一定數量的 ERC20 存入收款人在 L2 上的餘額。
+ * @param _l1Token 我們正在存入的 L1 ERC20 的地址
+ * @param _l2Token L1 各自在 L2 的 ERC20 地址
+ * @param _to 將提款記入的 L2 地址。
+ * @param _amount 要存入的 ERC20 數量。
+ * @param _l2Gas 在 L2 上完成存款所需的 Gas 限制。
+ * @param _data 可選資料,轉發到 L2。此資料僅為方便外部合約而提供。
+ * 除了強制執行最大長度外,這些合約對其內容不提供任何保證。
+ */
+ function depositERC20To(
+ address _l1Token,
+ address _l2Token,
+ address _to,
+ uint256 _amount,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external;
+```
+
+這個函式與 `depositERC20` 幾乎相同,但它允許您將 ERC-20 傳送到不同的地址。
+
+```solidity
+ /*************************
+ * 跨鏈函式 *
+ *************************/
+
+ /**
+ * @dev 完成從 L2 到 L1 的提款,並將資金記入收款人在
+ * L1 ERC20 代幣的餘額。
+ * 如果從 L2 初始化的提款尚未最終確定,此呼叫將會失敗。
+ *
+ * @param _l1Token 要為其 finalizeWithdrawal 的 L1 代幣地址。
+ * @param _l2Token 提款初始化的 L2 代幣地址。
+ * @param _from 啟動轉移的 L2 地址。
+ * @param _to 將提款記入的 L1 地址。
+ * @param _amount 要存入的 ERC20 數量。
+ * @param _data 由傳送者在 L2 上提供的資料。此資料僅為方便外部合約而提供。
+ * 除了強制執行最大長度外,這些合約對其內容不提供任何保證。
+ */
+ function finalizeERC20Withdrawal(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+ ) external;
+}
+```
+
+在 Optimism 中,提款 (以及其他從 L2 到 L1 的訊息) 是一個兩步驟的過程:
+
+1. 在 L2 上進行一筆啟動交易。
+2. 在 L1 上進行一筆最終確定或領取的交易。
+ 此交易需要在 L2 交易的[錯誤挑戰期](https://community.optimism.io/docs/how-optimism-works/#fault-proofs)結束後進行。
+
+### IL1StandardBridge {#il1standardbridge}
+
+[此介面定義在此](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol)。
+此檔案包含 ETH 的事件和函式定義。
+這些定義與上面在 `IL1ERC20Bridge` 中為 ERC-20 定義的非常相似。
+
+跨鏈橋介面被分成兩個檔案,因為一些 ERC-20 代幣需要自訂處理,無法由標準跨鏈橋處理。
+這樣,處理此類代幣的自訂跨鏈橋可以實作 `IL1ERC20Bridge`,而無需同時橋接 ETH。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >0.5.0 <0.9.0;
+
+import "./IL1ERC20Bridge.sol";
+
+/**
+ * @title IL1StandardBridge
+ */
+interface IL1StandardBridge is IL1ERC20Bridge {
+ /**********
+ * 事件 *
+ **********/
+ event ETHDepositInitiated(
+ address indexed _from,
+ address indexed _to,
+ uint256 _amount,
+ bytes _data
+ );
+```
+
+此事件與 ERC-20 版本 (`ERC20DepositInitiated`) 幾乎相同,只是沒有 L1 和 L2 的代幣地址。
+其他事件和函式也是如此。
+
+```solidity
+ event ETHWithdrawalFinalized(
+ .
+ .
+ .
+ );
+
+ /********************
+ * 公用函式 *
+ ********************/
+
+ /**
+ * @dev 將一定數量的 ETH 存入呼叫者在 L2 上的餘額。
+ .
+ .
+ .
+ */
+ function depositETH(uint32 _l2Gas, bytes calldata _data) external payable;
+
+ /**
+ * @dev 將一定數量的 ETH 存入收款人在 L2 上的餘額。
+ .
+ .
+ .
+ */
+ function depositETHTo(
+ address _to,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external payable;
+
+ /*************************
+ * 跨鏈函式 *
+ *************************/
+
+ /**
+ * @dev 完成從 L2 到 L1 的提款,並將資金記入收款人在 L1 ETH 代幣的餘額。
+ * 由於只有 xDomainMessenger 可以呼叫此函式,因此在提款最終確定之前,它永遠不會被呼叫。
+ .
+ .
+ .
+ */
+ function finalizeETHWithdrawal(
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+ ) external;
+}
+```
+
+### CrossDomainEnabled {#crossdomainenabled}
+
+[此合約](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol)由兩個跨鏈橋 ([L1](#the-l1-bridge-contract) 和 [L2](#the-l2-bridge-contract)) 繼承,用於向另一層傳送訊息。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >0.5.0 <0.9.0;
+
+/* 介面匯入 */
+import { ICrossDomainMessenger } from "./ICrossDomainMessenger.sol";
+```
+
+[此介面](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol) 告訴合約如何使用跨網域信使向另一層傳送訊息。
+這個跨網域信使是另一個完整的系統,值得單獨寫一篇文章,我希望將來能寫。
+
+```solidity
+/**
+ * @title CrossDomainEnabled
+ * @dev 執行跨網域通訊合約的輔助合約
+ *
+ * 使用的編譯器:由繼承合約定義
+ */
+contract CrossDomainEnabled {
+ /*************
+ * 變數 *
+ *************/
+
+ // 用於從其他網域傳送和接收訊息的信使合約。
+ address public messenger;
+
+ /***************
+ * 建構函式 *
+ ***************/
+
+ /**
+ * @param _messenger 當前層上 CrossDomainMessenger 的地址。
+ */
+ constructor(address _messenger) {
+ messenger = _messenger;
+ }
+```
+
+合約需要知道的一個參數是此層上跨網域信使的地址。
+這個參數在建構函式中只設定一次,永不改變。
+
+```solidity
+
+ /**********************
+ * 函式修飾符 *
+ **********************/
+
+ /**
+ * 強制被修改的函式只能由特定的跨網域帳戶呼叫。
+ * @param _sourceDomainAccount 原始網域上唯一被授權呼叫此函式的帳戶。
+ */
+ modifier onlyFromCrossDomainAccount(address _sourceDomainAccount) {
+```
+
+跨網域訊息傳遞可由其執行所在的區塊鏈 (以太坊主網或 Optimism) 上的任何合約存取。
+但我們需要每一側的跨鏈橋都_只_信任來自另一側跨鏈橋的特定訊息。
+
+```solidity
+ require(
+ msg.sender == address(getCrossDomainMessenger()),
+ "OVM_XCHAIN: messenger contract unauthenticated"
+ );
+```
+
+只有來自適當的跨網域信使 (`messenger`,如下所示) 的訊息才能被信任。
+
+```solidity
+
+ require(
+ getCrossDomainMessenger().xDomainMessageSender() == _sourceDomainAccount,
+ "OVM_XCHAIN: wrong sender of cross-domain message"
+ );
+```
+
+跨網域信使提供傳送訊息至另一層地址的方式是透過 [`.xDomainMessageSender()` 函式](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128)。
+只要它在由該訊息啟動的交易中被呼叫,它就可以提供此資訊。
+
+我們需要確保我們收到的訊息來自另一個跨鏈橋。
+
+```solidity
+
+ _;
+ }
+
+ /**********************
+ * 內部函式 *
+ **********************/
+
+ /**
+ * 通常從儲存中取得信使。公開此函式是為了以防子合約需要覆寫。
+ * @return 應該使用的跨網域信使合約的地址。
+ */
+ function getCrossDomainMessenger() internal virtual returns (ICrossDomainMessenger) {
+ return ICrossDomainMessenger(messenger);
+ }
+```
+
+此函式回傳跨網域信使。
+我們使用函式而不是變數 `messenger`,以允許繼承自此合約的合約使用演算法來指定要使用哪個跨網域信使。
+
+```solidity
+
+ /**
+ * 向另一個網域上的帳戶傳送訊息
+ * @param _crossDomainTarget 目標網域上的預期收款人
+ * @param _message 要傳送給目標的資料 (通常是傳給帶有 `onlyFromCrossDomainAccount()` 函式的 calldata)
+ * @param _gasLimit 在目標網域上接收訊息的 gasLimit。
+ */
+ function sendCrossDomainMessage(
+ address _crossDomainTarget,
+ uint32 _gasLimit,
+ bytes memory _message
+```
+
+最後,是傳送訊息到另一層的函式。
+
+```solidity
+ ) internal {
+ // slither-disable-next-line reentrancy-events, reentrancy-benign
+```
+
+[Slither](https://github.com/crytic/slither) 是一個靜態分析器,Optimism 在每個合約上執行它以尋找漏洞和其他潛在問題。
+在這種情況下,下面這一行會觸發兩個漏洞:
+
+1. [重入事件](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-3)
+2. [良性重入](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2)
+
+```solidity
+ getCrossDomainMessenger().sendMessage(_crossDomainTarget, _message, _gasLimit);
+ }
+}
+```
+
+在這種情況下,我們不擔心重入,我們知道 `getCrossDomainMessenger()` 會回傳一個可信的地址,即使 Slither 無法知道這一點。
+
+### L1 跨鏈橋合約 {#the-l1-bridge-contract}
+
+[此合約的原始程式碼在此](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol)。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+```
+
+介面可以是其他合約的一部分,所以它們必須支援多種 Solidity 版本。
+但跨鏈橋本身是我們的合約,我們可以嚴格規定它使用的 Solidity 版本。
+
+```solidity
+/* 介面匯入 */
+import { IL1StandardBridge } from "./IL1StandardBridge.sol";
+import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol";
+```
+
+[IL1ERC20Bridge](#IL1ERC20Bridge) 和 [IL1StandardBridge](#IL1StandardBridge) 已在上面解釋。
+
+```solidity
+import { IL2ERC20Bridge } from "../../L2/messaging/IL2ERC20Bridge.sol";
+```
+
+[此介面](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) 讓我們能夠建立訊息來控制 L2 上的標準跨鏈橋。
+
+```solidity
+import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+```
+
+[此介面](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) 讓我們能夠控制 ERC-20 合約。
+[您可以在此處閱讀更多相關資訊](/developers/tutorials/erc20-annotated-code/#the-interface)。
+
+```solidity
+/* 函式庫匯入 */
+import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol";
+```
+
+[如上所述](#crossdomainenabled),此合約用於層間訊息傳遞。
+
+```solidity
+import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol";
+```
+
+[`Lib_PredeployAddresses`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) 包含 L2 合約的地址,這些合約的地址永遠相同。 這包括 L2 上的標準跨鏈橋。
+
+```solidity
+import { Address } from "@openzeppelin/contracts/utils/Address.sol";
+```
+
+[OpenZeppelin 的 Address 公用程式](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol)。 它用於區分合約地址和屬於外部擁有帳戶 (EOA) 的地址。
+
+請注意,這不是一個完美的解決方案,因為無法區分直接呼叫和從合約建構函式中進行的呼叫,但至少這讓我們能夠識別並防止一些常見的使用者錯誤。
+
+```solidity
+import { SafeERC20 } from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
+```
+
+[ERC-20 標準](https://eips.ethereum.org/EIPS/eip-20) 支援兩種合約回報失敗的方式:
+
+1. 還原
+2. 回傳 `false`
+
+處理這兩種情況會讓我們的程式碼更複雜,所以我們改用 [OpenZeppelin 的 `SafeERC20`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol),它能確保[所有失敗都會導致還原](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96)。
+
+```solidity
+/**
+ * @title L1StandardBridge
+ * @dev L1 ETH 和 ERC20 跨鏈橋是一個合約,用於儲存存入的 L1 資金和在 L2 上使用的標準代幣。
+ * 它同步一個對應的 L2 跨鏈橋,通知其存款並監聽新最終確定的提款。
+ *
+ */
+contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled {
+ using SafeERC20 for IERC20;
+```
+
+這一行指定了每次使用 `IERC20` 介面時都要使用 `SafeERC20` 包裝器。
+
+```solidity
+
+ /********************************
+ * 外部合約參考 *
+ ********************************/
+
+ address public l2TokenBridge;
+```
+
+[L2StandardBridge](#the-l2-bridge-contract) 的地址。
+
+```solidity
+
+ // 將 L1 代幣對應到 L2 代幣,再對應到存入的 L1 代幣餘額
+ mapping(address => mapping(address => uint256)) public deposits;
+```
+
+像這樣的雙重[對應](https://www.tutorialspoint.com/solidity/solidity_mappings.htm)是定義[二維稀疏陣列](https://en.wikipedia.org/wiki/Sparse_matrix)的方式。
+此資料結構中的值被識別為 `deposit[L1 token addr][L2 token addr]`。
+預設值為零。
+只有設定為不同值的儲存單元會被寫入儲存空間。
+
+```solidity
+
+ /***************
+ * 建構函式 *
+ ***************/
+
+ // 此合約位於代理之後,因此建構函式參數將不會被使用。
+ constructor() CrossDomainEnabled(address(0)) {}
+```
+
+為了能夠升級此合約而無需複製儲存空間中的所有變數。
+為此,我們使用 [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy),這是一個使用 [`delegatecall`](https://solidity-by-example.org/delegatecall/) 將呼叫轉移到另一個獨立合約的合約,該合約的地址由代理合約儲存 (當您升級時,您會告訴代理合約更改該地址)。
+當您使用 `delegatecall` 時,儲存空間仍然是_呼叫_合約的儲存空間,因此所有合約狀態變數的值都不會受到影響。
+
+這種模式的一個影響是 `delegatecall` 的_被呼叫_合約的儲存空間不會被使用,因此傳遞給它的建構函式值並不重要。
+這就是我們可以向 `CrossDomainEnabled` 建構函式提供一個無意義值的原因。
+這也是下面的初始化與建構函式分開的原因。
+
+```solidity
+ /******************
+ * 初始化 *
+ ******************/
+
+ /**
+ * @param _l1messenger 用於跨鏈通訊的 L1 信使地址。
+ * @param _l2TokenBridge L2 標準跨鏈橋地址。
+ */
+ // slither-disable-next-line external-function
+```
+
+這個 [Slither 測試](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external) 會找出未從合約程式碼中呼叫的函式,因此可以宣告為 `external` 而非 `public`。
+`external` 函式的 Gas 成本可能較低,因為它們可以在 calldata 中提供參數。
+宣告為 `public` 的函式必須能從合約內部存取。
+合約無法修改自己的 calldata,所以參數必須在記憶體中。
+當此類函式從外部被呼叫時,需要將 calldata 複製到記憶體,這會消耗 Gas。
+在這種情況下,函式只被呼叫一次,所以效率低下的問題對我們不重要。
+
+```solidity
+ function initialize(address _l1messenger, address _l2TokenBridge) public {
+ require(messenger == address(0), "Contract has already been initialized.");
+```
+
+`initialize` 函式應該只被呼叫一次。
+如果 L1 跨網域信使或 L2 代幣跨鏈橋的地址發生變化,我們會建立一個新的代理和一個新的跨鏈橋來呼叫它。
+除非整個系統升級,否則這種情況不太可能發生,這是一個非常罕見的事件。
+
+請注意,此函式沒有任何限制_誰_可以呼叫它的機制。
+這意味著理論上,攻擊者可以等到我們部署代理和第一個版本的跨鏈橋後,然後[搶先交易 (front-run)](https://solidity-by-example.org/hacks/front-running/),在合法使用者之前執行 `initialize` 函式。 但有兩種方法可以防止這種情況:
+
+1. 如果合約不是直接由 EOA 部署,而是[在一個由另一個合約建立它們的交易中部署](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595),整個過程可以是原子性的,並在任何其他交易執行之前完成。
+2. 如果對 `initialize` 的合法呼叫失敗,總是可以忽略新建立的代理和跨鏈橋,並建立新的。
+
+```solidity
+ messenger = _l1messenger;
+ l2TokenBridge = _l2TokenBridge;
+ }
+```
+
+這是跨鏈橋需要知道的兩個參數。
+
+```solidity
+
+ /**************
+ * 存款 *
+ **************/
+
+ /** @dev 修飾符,要求傳送者為 EOA。此檢查可被惡意合約透過 initcode 繞過,
+ * 但它能處理我們想要避免的使用者錯誤。
+ */
+ modifier onlyEOA() {
+ // 用於阻止來自合約的存款 (避免意外遺失代幣)
+ require(!Address.isContract(msg.sender), "Account not EOA");
+ _;
+ }
+```
+
+這就是我們需要 OpenZeppelin 的 `Address` 公用程式的原因。
+
+```solidity
+ /**
+ * @dev 此函式可以在沒有資料的情況下被呼叫,
+ * 以將一定數量的 ETH 存入呼叫者在 L2 上的餘額。
+ * 由於 receive 函式不接受資料,一個保守的預設數量會被轉發到 L2。
+ */
+ receive() external payable onlyEOA {
+ _initiateETHDeposit(msg.sender, msg.sender, 200_000, bytes(""));
+ }
+```
+
+此函式用於測試目的。
+請注意,它並未出現在介面定義中——它不是為正常使用而設計的。
+
+```solidity
+ /**
+ * @inheritdoc IL1StandardBridge
+ */
+ function depositETH(uint32 _l2Gas, bytes calldata _data) external payable onlyEOA {
+ _initiateETHDeposit(msg.sender, msg.sender, _l2Gas, _data);
+ }
+
+ /**
+ * @inheritdoc IL1StandardBridge
+ */
+ function depositETHTo(
+ address _to,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external payable {
+ _initiateETHDeposit(msg.sender, _to, _l2Gas, _data);
+ }
+```
+
+這兩個函式是 `_initiateETHDeposit` 的包裝器,後者處理實際的 ETH 存款。
+
+```solidity
+ /**
+ * @dev 透過儲存 ETH 並通知 L2 ETH 閘道存款的邏輯。
+ * @param _from 從 L1 提取存款的帳戶。
+ * @param _to 在 L2 上給予存款的帳戶。
+ * @param _l2Gas 在 L2 上完成存款所需的 Gas 限制。
+ * @param _data 可選資料,轉發到 L2。此資料僅為方便外部合約而提供。
+ * 除了強制執行最大長度外,這些合約對其內容不提供任何保證。
+ */
+ function _initiateETHDeposit(
+ address _from,
+ address _to,
+ uint32 _l2Gas,
+ bytes memory _data
+ ) internal {
+ // 為 finalizeDeposit 呼叫建構 calldata
+ bytes memory message = abi.encodeWithSelector(
+```
+
+跨網域訊息的運作方式是,目標合約被呼叫時,會將訊息作為其 calldata。
+Solidity 合約始終根據 [ABI 規範](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html)來解釋其 calldata。
+Solidity 函式 [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) 建立該 calldata。
+
+```solidity
+ IL2ERC20Bridge.finalizeDeposit.selector,
+ address(0),
+ Lib_PredeployAddresses.OVM_ETH,
+ _from,
+ _to,
+ msg.value,
+ _data
+ );
+```
+
+這裡的訊息是使用這些參數呼叫 [`finalizeDeposit` 函式](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148):
+
+| 參數 | 數值 | 意義 |
+| ------------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| \_l1Token | address(0) | 用於代表 L1 上 ETH (它不是 ERC-20 代幣) 的特殊值 |
+| \_l2Token | Lib_PredeployAddresses.OVM_ETH | 在 Optimism 上管理 ETH 的 L2 合約,`0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (此合約僅供 Optimism 內部使用) |
+| \_from | \_from | 在 L1 上傳送 ETH 的地址 |
+| \_to | \_to | 在 L2 上接收 ETH 的地址 |
+| 數量 | msg.value | 傳送的 wei 數量 (已經傳送到跨鏈橋) |
+| \_data | \_data | 附加到存款的額外資料 |
+
+```solidity
+ // 將 calldata 傳送到 L2
+ // slither-disable-next-line reentrancy-events
+ sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
+```
+
+透過跨網域信使傳送訊息。
+
+```solidity
+ // slither-disable-next-line reentrancy-events
+ emit ETHDepositInitiated(_from, _to, msg.value, _data);
+ }
+```
+
+發出一個事件,以通知任何監聽此轉移的去中心化應用程式。
+
+```solidity
+ /**
+ * @inheritdoc IL1ERC20Bridge
+ */
+ function depositERC20(
+ .
+ .
+ .
+ ) external virtual onlyEOA {
+ _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, msg.sender, _amount, _l2Gas, _data);
+ }
+
+ /**
+ * @inheritdoc IL1ERC20Bridge
+ */
+ function depositERC20To(
+ .
+ .
+ .
+ ) external virtual {
+ _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, _to, _amount, _l2Gas, _data);
+ }
+```
+
+這兩個函式是 `_initiateERC20Deposit` 的包裝器,後者處理實際的 ERC-20 存款。
+
+```solidity
+ /**
+ * @dev 透過通知 L2 存款代幣合約存款並呼叫處理程序來鎖定 L1 資金 (例如,transferFrom) 來執行存款的邏輯。
+ *
+ * @param _l1Token 我們正在存入的 L1 ERC20 的地址
+ * @param _l2Token L1 各自在 L2 的 ERC20 地址
+ * @param _from 從 L1 提取存款的帳戶
+ * @param _to 在 L2 上給予存款的帳戶
+ * @param _amount 要存入的 ERC20 數量。
+ * @param _l2Gas 在 L2 上完成存款所需的 Gas 限制。
+ * @param _data 可選資料,轉發到 L2。此資料僅為方便外部合約而提供。
+ * 除了強制執行最大長度外,這些合約對其內容不提供任何保證。
+ */
+ function _initiateERC20Deposit(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) internal {
+```
+
+這個函式與上面的 `_initiateETHDeposit` 相似,但有幾個重要的差異。
+第一個差異是此函式接收代幣地址和要轉移的金額作為參數。
+在 ETH 的情況下,對跨鏈橋的呼叫已經包含了將資產轉移到跨鏈橋帳戶 (`msg.value`)。
+
+```solidity
+ // 當存款在 L1 上啟動時,L1 跨鏈橋會將資金轉移給自己以供未來提款。safeTransferFrom 也會檢查合約是否有程式碼,
+ // 所以如果 _from 是 EOA 或 address(0),這將會失敗。
+ // slither-disable-next-line reentrancy-events, reentrancy-benign
+ IERC20(_l1Token).safeTransferFrom(_from, address(this), _amount);
+```
+
+ERC-20 代幣轉移遵循與 ETH 不同的流程:
+
+1. 使用者 (`_from`) 給予跨鏈橋一筆額度以轉移適當的代幣。
+2. 使用者以代幣合約地址、金額等呼叫跨鏈橋。
+3. 跨鏈橋作為存款過程的一部分,將代幣轉移 (給自己)。
+
+第一步可能與後兩步在不同的交易中發生。
+然而,搶先交易不是問題,因為呼叫 `_initiateERC20Deposit` 的兩個函式 (`depositERC20` 和 `depositERC20To`) 只會以 `msg.sender` 作為 `_from` 參數來呼叫此函式。
+
+```solidity
+ // 建構 _l2Token.finalizeDeposit(_to, _amount) 的 calldata
+ bytes memory message = abi.encodeWithSelector(
+ IL2ERC20Bridge.finalizeDeposit.selector,
+ _l1Token,
+ _l2Token,
+ _from,
+ _to,
+ _amount,
+ _data
+ );
+
+ // 將 calldata 傳送到 L2
+ // slither-disable-next-line reentrancy-events, reentrancy-benign
+ sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
+
+ // slither-disable-next-line reentrancy-benign
+ deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] + _amount;
+```
+
+將存入的代幣數量新增到 `deposits` 資料結構中。
+在 L2 上可能有多個地址對應到同一個 L1 ERC-20 代幣,因此僅使用跨鏈橋的 L1 ERC-20 代幣餘額來追蹤存款是不夠的。
+
+```solidity
+
+ // slither-disable-next-line reentrancy-events
+ emit ERC20DepositInitiated(_l1Token, _l2Token, _from, _to, _amount, _data);
+ }
+
+ /*************************
+ * 跨鏈函式 *
+ *************************/
+
+ /**
+ * @inheritdoc IL1StandardBridge
+ */
+ function finalizeETHWithdrawal(
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+```
+
+L2 跨鏈橋向 L2 跨網域信使傳送一則訊息,這會導致 L1 跨網域信使呼叫此函式 (當然,前提是在 L1 上提交了[最終確定該訊息的交易](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions))。
+
+```solidity
+ ) external onlyFromCrossDomainAccount(l2TokenBridge) {
+```
+
+確保這是一則_合法_的訊息,來自跨網域信使,並源自 L2 代幣跨鏈橋。
+此函式用於從跨鏈橋提取 ETH,因此我們必須確保它只由授權的呼叫者呼叫。
+
+```solidity
+ // slither-disable-next-line reentrancy-events
+ (bool success, ) = _to.call{ value: _amount }(new bytes(0));
+```
+
+轉移 ETH 的方法是呼叫收款人,並在 `msg.value` 中附上 wei 的數量。
+
+```solidity
+ require(success, "TransferHelper::safeTransferETH: ETH transfer failed");
+
+ // slither-disable-next-line reentrancy-events
+ emit ETHWithdrawalFinalized(_from, _to, _amount, _data);
+```
+
+發出一個關於提款的事件。
+
+```solidity
+ }
+
+ /**
+ * @inheritdoc IL1ERC20Bridge
+ */
+ function finalizeERC20Withdrawal(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+ ) external onlyFromCrossDomainAccount(l2TokenBridge) {
+```
+
+這個函式與上面的 `finalizeETHWithdrawal` 相似,但針對 ERC-20 代幣做了必要的修改。
+
+```solidity
+ deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] - _amount;
+```
+
+更新 `deposits` 資料結構。
+
+```solidity
+
+ // 當提款在 L1 上最終確定時,L1 跨鏈橋會將資金轉移給提款人
+ // slither-disable-next-line reentrancy-events
+ IERC20(_l1Token).safeTransfer(_to, _amount);
+
+ // slither-disable-next-line reentrancy-events
+ emit ERC20WithdrawalFinalized(_l1Token, _l2Token, _from, _to, _amount, _data);
+ }
+
+
+ /*****************************
+ * 臨時 - 遷移 ETH *
+ *****************************/
+
+ /**
+ * @dev 將 ETH 餘額新增到帳戶。這是為了允許將 ETH
+ * 從舊的閘道遷移到新的閘道。
+ * 注意:這只保留一次升級,以便我們能夠從舊合約接收遷移的 ETH
+ */
+ function donateETH() external payable {}
+}
+```
+
+之前有一個較早的跨鏈橋實作。
+當我們從那個實作轉移到這個實作時,我們必須移動所有資產。
+ERC-20 代幣可以直接移動。
+然而,要將 ETH 轉移到一個合約,你需要該合約的批准,這正是 `donateETH` 提供給我們的。
+
+## L2 上的 ERC-20 代幣 {#erc-20-tokens-on-l2}
+
+要讓一個 ERC-20 代幣適用於標準跨鏈橋,它需要允許標準跨鏈橋,且_只_允許標準跨鏈橋,來鑄造代幣。
+這是必要的,因為跨鏈橋需要確保在 Optimism 上流通的代幣數量等於鎖在 L1 跨鏈橋合約內的代幣數量。
+如果 L2 上的代幣太多,一些使用者將無法將他們的資產橋接回 L1。
+這樣一來,我們實質上會重新創造出[部分準備金銀行制度](https://www.investopedia.com/terms/f/fractionalreservebanking.asp),而不是一個可信的跨鏈橋。
+如果 L1 上的代幣太多,其中一些代幣將永遠被鎖在跨鏈橋合約內,因為沒有辦法在不銷毀 L2 代幣的情況下釋放它們。
+
+### IL2StandardERC20 {#il2standarderc20}
+
+在 L2 上使用標準跨鏈橋的每個 ERC-20 代幣都需要提供[這個介面](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol),其中包含標準跨鏈橋所需的函式和事件。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+
+import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+```
+
+[標準 ERC-20 介面](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) 不包含 `mint` 和 `burn` 函式。
+這些方法並非 [ERC-20 標準](https://eips.ethereum.org/EIPS/eip-20)所要求的,該標準未指定建立和銷毀代幣的機制。
+
+```solidity
+import { IERC165 } from "@openzeppelin/contracts/utils/introspection/IERC165.sol";
+```
+
+[ERC-165 介面](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol) 用於指定合約提供的函式。
+[您可以在此處閱讀該標準](https://eips.ethereum.org/EIPS/eip-165)。
+
+```solidity
+interface IL2StandardERC20 is IERC20, IERC165 {
+ function l1Token() external returns (address);
+```
+
+此函式提供橋接到此合約的 L1 代幣的地址。
+請注意,我們沒有一個反向的類似函式。
+我們需要能夠橋接任何 L1 代幣,無論在其實作時是否已規劃 L2 支援。
+
+```solidity
+
+ function mint(address _to, uint256 _amount) external;
+
+ function burn(address _from, uint256 _amount) external;
+
+ event Mint(address indexed _account, uint256 _amount);
+ event Burn(address indexed _account, uint256 _amount);
+}
+```
+
+鑄造 (建立) 和銷毀 (摧毀) 代幣的函式和事件。
+跨鏈橋應該是唯一可以執行這些函式的實體,以確保代幣數量是正確的 (等於鎖在 L1 上的代幣數量)。
+
+### L2StandardERC20 {#L2StandardERC20}
+
+[這是我們對 `IL2StandardERC20` 介面的實作](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol)。
+除非您需要某種自訂邏輯,否則您應該使用這個。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+
+import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+```
+
+[OpenZeppelin ERC-20 合約](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)。
+Optimism 不相信重新發明輪子,尤其是當這個輪子經過良好審核且需要足夠可信以持有資產時。
+
+```solidity
+import "./IL2StandardERC20.sol";
+
+contract L2StandardERC20 is IL2StandardERC20, ERC20 {
+ address public l1Token;
+ address public l2Bridge;
+```
+
+這是我們需要而 ERC-20 通常不需要的兩個額外設定參數。
+
+```solidity
+
+ /**
+ * @param _l2Bridge L2 標準跨鏈橋的地址。
+ * @param _l1Token 相應 L1 代幣的地址。
+ * @param _name ERC20 名稱。
+ * @param _symbol ERC20 符號。
+ */
+ constructor(
+ address _l2Bridge,
+ address _l1Token,
+ string memory _name,
+ string memory _symbol
+ ) ERC20(_name, _symbol) {
+ l1Token = _l1Token;
+ l2Bridge = _l2Bridge;
+ }
+```
+
+首先呼叫我們繼承的合約的建構函式 (`ERC20(_name, _symbol)`),然後設定我們自己的變數。
+
+```solidity
+
+ modifier onlyL2Bridge() {
+ require(msg.sender == l2Bridge, "Only L2 Bridge can mint and burn");
+ _;
+ }
+
+
+ // slither-disable-next-line external-function
+ function supportsInterface(bytes4 _interfaceId) public pure returns (bool) {
+ bytes4 firstSupportedInterface = bytes4(keccak256("supportsInterface(bytes4)")); // ERC165
+ bytes4 secondSupportedInterface = IL2StandardERC20.l1Token.selector ^
+ IL2StandardERC20.mint.selector ^
+ IL2StandardERC20.burn.selector;
+ return _interfaceId == firstSupportedInterface || _interfaceId == secondSupportedInterface;
+ }
+```
+
+這就是 [ERC-165](https://eips.ethereum.org/EIPS/eip-165) 的運作方式。
+每個介面都有一系列支援的函式,並被識別為這些函式的[ABI 函式選擇器](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector)的[互斥或](https://en.wikipedia.org/wiki/Exclusive_or)。
+
+L2 跨鏈橋使用 ERC-165 作為健全性檢查,以確保其傳送資產的 ERC-20 合約是一個 `IL2StandardERC20`。
+
+**注意:** 沒有任何東西可以阻止惡意合約對 `supportsInterface` 提供虛假答案,所以這是一個健全性檢查機制,_不是_一個安全機制。
+
+```solidity
+ // slither-disable-next-line external-function
+ function mint(address _to, uint256 _amount) public virtual onlyL2Bridge {
+ _mint(_to, _amount);
+
+ emit Mint(_to, _amount);
+ }
+
+ // slither-disable-next-line external-function
+ function burn(address _from, uint256 _amount) public virtual onlyL2Bridge {
+ _burn(_from, _amount);
+
+ emit Burn(_from, _amount);
+ }
+}
+```
+
+只有 L2 跨鏈橋被允許鑄造和銷毀資產。
+
+`_mint` 和 `_burn` 實際上是在 [OpenZeppelin ERC-20 合約](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn) 中定義的。
+該合約只是沒有將它們公開,因為鑄造和銷毀代幣的條件與使用 ERC-20 的方式一樣多種多樣。
+
+## L2 跨鏈橋程式碼 {#l2-bridge-code}
+
+這是執行在 Optimism 上的跨鏈橋程式碼。
+[此合約的原始碼在此](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol)。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+
+/* 介面匯入 */
+import { IL1StandardBridge } from "../../L1/messaging/IL1StandardBridge.sol";
+import { IL1ERC20Bridge } from "../../L1/messaging/IL1ERC20Bridge.sol";
+import { IL2ERC20Bridge } from "./IL2ERC20Bridge.sol";
+```
+
+[IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) 介面與我們上面看到的 [L1 對應版本](#IL1ERC20Bridge) 非常相似。
+有兩個顯著的差異:
+
+1. 在 L1 上,您啟動存款並最終確定提款。
+ 在這裡,您啟動提款並最終確定存款。
+2. 在 L1 上,有必要區分 ETH 和 ERC-20 代幣。
+ 在 L2 上,我們可以對兩者使用相同的函式,因為在 Optimism 內部,ETH 餘額被當作一個地址為 [0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000) 的 ERC-20 代幣來處理。
+
+```solidity
+/* 函式庫匯入 */
+import { ERC165Checker } from "@openzeppelin/contracts/utils/introspection/ERC165Checker.sol";
+import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol";
+import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol";
+
+/* 合約匯入 */
+import { IL2StandardERC20 } from "../../standards/IL2StandardERC20.sol";
+
+/**
+ * @title L2StandardBridge
+ * @dev L2 標準跨鏈橋是一個與 L1 標準跨鏈橋協同工作的合約,
+ * 用於在 L1 和 L2 之間進行 ETH 和 ERC20 的轉換。
+ * 當此合約聽到 L1 標準跨鏈橋有存款時,它會作為新代幣的鑄造者。
+ * 此合約也作為預計提款代幣的銷毀者,通知 L1 跨鏈橋釋放 L1 資金。
+ */
+contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled {
+ /********************************
+ * 外部合約參考 *
+ ********************************/
+
+ address public l1TokenBridge;
+```
+
+追蹤 L1 跨鏈橋的地址。
+請注意,與 L1 的對應版本相反,我們在這裡_需要_這個變數。
+L1 跨鏈橋的地址不是預先知道的。
+
+```solidity
+
+ /***************
+ * 建構函式 *
+ ***************/
+
+ /**
+ * @param _l2CrossDomainMessenger 此合約使用的跨網域信使。
+ * @param _l1TokenBridge 部署在主鏈上的 L1 跨鏈橋地址。
+ */
+ constructor(address _l2CrossDomainMessenger, address _l1TokenBridge)
+ CrossDomainEnabled(_l2CrossDomainMessenger)
+ {
+ l1TokenBridge = _l1TokenBridge;
+ }
+
+ /***************
+ * 提款 *
+ ***************/
+
+ /**
+ * @inheritdoc IL2ERC20Bridge
+ */
+ function withdraw(
+ address _l2Token,
+ uint256 _amount,
+ uint32 _l1Gas,
+ bytes calldata _data
+ ) external virtual {
+ _initiateWithdrawal(_l2Token, msg.sender, msg.sender, _amount, _l1Gas, _data);
+ }
+
+ /**
+ * @inheritdoc IL2ERC20Bridge
+ */
+ function withdrawTo(
+ address _l2Token,
+ address _to,
+ uint256 _amount,
+ uint32 _l1Gas,
+ bytes calldata _data
+ ) external virtual {
+ _initiateWithdrawal(_l2Token, msg.sender, _to, _amount, _l1Gas, _data);
+ }
+```
+
+這兩個函式啟動提款。
+請注意,無需指定 L1 代幣地址。
+L2 代幣應該會告訴我們 L1 對應的地址。
+
+```solidity
+
+ /**
+ * @dev 透過銷毀代幣並通知 L1 代幣閘道提款來執行提款的邏輯。
+ * @param _l2Token 提款啟動的 L2 代幣地址。
+ * @param _from 從 L2 提取提款的帳戶。
+ * @param _to 在 L1 上給予提款的帳戶。
+ * @param _amount 要提取的代幣數量。
+ * @param _l1Gas 未使用,但為潛在的前向相容性考量而包含。
+ * @param _data 可選資料,轉發到 L1。此資料僅為方便外部合約而提供。
+ * 除了強制執行最大長度外,這些合約對其內容不提供任何保證。
+ */
+ function _initiateWithdrawal(
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ uint32 _l1Gas,
+ bytes calldata _data
+ ) internal {
+ // 當提款啟動時,我們銷毀提款人的資金以防止後續的 L2 使用
+ // slither-disable-next-line reentrancy-events
+ IL2StandardERC20(_l2Token).burn(msg.sender, _amount);
+```
+
+請注意,我們_不_依賴 `_from` 參數,而是依賴 `msg.sender`,後者更難偽造 (就我所知,是不可能的)。
+
+```solidity
+
+ // 建構 l1TokenBridge.finalizeERC20Withdrawal(_to, _amount) 的 calldata
+ // slither-disable-next-line reentrancy-events
+ address l1Token = IL2StandardERC20(_l2Token).l1Token();
+ bytes memory message;
+
+ if (_l2Token == Lib_PredeployAddresses.OVM_ETH) {
+```
+
+在 L1 上有必要區分 ETH 和 ERC-20。
+
+```solidity
+ message = abi.encodeWithSelector(
+ IL1StandardBridge.finalizeETHWithdrawal.selector,
+ _from,
+ _to,
+ _amount,
+ _data
+ );
+ } else {
+ message = abi.encodeWithSelector(
+ IL1ERC20Bridge.finalizeERC20Withdrawal.selector,
+ l1Token,
+ _l2Token,
+ _from,
+ _to,
+ _amount,
+ _data
+ );
+ }
+
+ // 將訊息傳送到 L1 跨鏈橋
+ // slither-disable-next-line reentrancy-events
+ sendCrossDomainMessage(l1TokenBridge, _l1Gas, message);
+
+ // slither-disable-next-line reentrancy-events
+ emit WithdrawalInitiated(l1Token, _l2Token, msg.sender, _to, _amount, _data);
+ }
+
+ /************************************
+ * 跨鏈函式:存款 *
+ ************************************/
+
+ /**
+ * @inheritdoc IL2ERC20Bridge
+ */
+ function finalizeDeposit(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+```
+
+此函式由 `L1StandardBridge` 呼叫。
+
+```solidity
+ ) external virtual onlyFromCrossDomainAccount(l1TokenBridge) {
+```
+
+確保訊息的來源是合法的。
+這很重要,因為此函式會呼叫 `_mint`,且可能被用來發放不受 L1 跨鏈橋所擁有代幣覆蓋的代幣。
+
+```solidity
+ // 檢查目標代幣是否合規,並驗證 L1 上存入的代幣與此處的 L2 存款代幣表示相符
+ if (
+ // slither-disable-next-line reentrancy-events
+ ERC165Checker.supportsInterface(_l2Token, 0x1d1d8b63) &&
+ _l1Token == IL2StandardERC20(_l2Token).l1Token()
+```
+
+健全性檢查:
+
+1. 支援正確的介面
+2. L2 ERC-20 合約的 L1 地址與代幣的 L1 來源相符
+
+```solidity
+ ) {
+ // 當存款最終確定時,我們在 L2 上將相同數量的代幣記入帳戶。
+ // slither-disable-next-line reentrancy-events
+ IL2StandardERC20(_l2Token).mint(_to, _amount);
+ // slither-disable-next-line reentrancy-events
+ emit DepositFinalized(_l1Token, _l2Token, _from, _to, _amount, _data);
+```
+
+如果健全性檢查通過,則最終確定存款:
+
+1. 鑄造代幣
+2. 發出適當的事件
+
+```solidity
+ } else {
+ // 存入的 L2 代幣對其 L1 代幣的正確地址有異議,或者不支援正確的介面。
+ // 這只應該在有惡意的 L2 代幣,或者使用者以某種方式指定了錯誤的 L2 代幣地址存入時發生。
+ // 無論哪種情況,我們都在此處停止流程並建構一個提款訊息,
+ // 以便使用者在某些情況下可以取回他們的資金。
+ // 完全防止惡意代幣合約是不可能的,但這確實限制了使用者錯誤並減輕了某些形式的惡意合約行為。
+```
+
+如果使用者因為使用錯誤的 L2 代幣地址而犯了一個可被偵測的錯誤,我們希望取消存款並在 L1 上歸還代幣。
+我們能從 L2 做到這一點的唯一方法是傳送一則需要等待錯誤挑戰期的訊息,但對使用者來說,這比永久失去代幣要好得多。
+
+```solidity
+ bytes memory message = abi.encodeWithSelector(
+ IL1ERC20Bridge.finalizeERC20Withdrawal.selector,
+ _l1Token,
+ _l2Token,
+ _to, // 在這裡交換了 _to 和 _from 以將存款退回給傳送者
+ _from,
+ _amount,
+ _data
+ );
+
+ // 將訊息傳送到 L1 跨鏈橋
+ // slither-disable-next-line reentrancy-events
+ sendCrossDomainMessage(l1TokenBridge, 0, message);
+ // slither-disable-next-line reentrancy-events
+ emit DepositFailed(_l1Token, _l2Token, _from, _to, _amount, _data);
+ }
+ }
+}
+```
+
+## 結論 {#conclusion}
+
+標準跨鏈橋是資產轉移最靈活的機制。
+然而,正因為它如此通用,它不總是最好用的機制。
+特別是對於提款,大多數使用者更喜歡使用[第三方跨鏈橋](https://optimism.io/apps#bridge),這些跨鏈橋不等待挑戰期,也不需要梅克爾證明來最終確定提款。
+
+這些跨鏈橋通常透過在 L1 上持有資產來運作,它們會立即提供資產並收取少量費用 (通常低於標準跨鏈橋提款的 Gas 成本)。
+當跨鏈橋 (或其運營者) 預期 L1 資產不足時,它會從 L2 轉移足夠的資產。 由於這些都是非常大的提款,提款成本會攤銷到大量金額上,因此所佔的百分比要小得多。
+
+希望這篇文章能幫助您更了解第二層如何運作,以及如何撰寫清晰且安全的 Solidity 程式碼。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
new file mode 100644
index 00000000000..6981499a493
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
@@ -0,0 +1,743 @@
+---
+title: "對合約進行逆向工程"
+description: 如何在沒有原始碼的情況下理解合約
+author: 作者:Ori Pomerantz
+lang: zh-tw
+tags: [ "evm", "opcodes" ]
+skill: advanced
+published: 2021-12-30
+---
+
+## 介紹 {#introduction}
+
+_區塊鏈上沒有秘密_,發生的一切都是一致、可驗證且公開的。 理想情況下,[合約應在 Etherscan 上發布並驗證其原始碼](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code)。 然而,[情況並非總是如此](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code)。 在本文中,您將學習如何透過查看一個沒有原始碼的合約 [`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f) 來對其進行逆向工程。
+
+有反向編譯器,但它們並不總能產生[可用的結果](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f)。 在本文中,您將學習如何手動從 [opcodes](https://github.com/wolflo/evm-opcodes) 逆向工程並理解一個合約,以及如何解釋反編譯器的結果。
+
+要理解本文,您應該已經了解 EVM 的基礎知識,並至少對 EVM 組譯器有些熟悉。 [您可以在此處閱讀有關這些主題的資訊](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e)。
+
+## 準備可執行程式碼 {#prepare-the-executable-code}
+
+您可以前往合約的 Etherscan 頁面,點擊 **Contract** 標籤,然後點擊 **Switch to Opcodes View** 來取得 opcodes。 您將得到一個每行一個 opcode 的視圖。
+
+
+
+然而,為了能夠理解跳轉,您需要知道每個 opcode 在程式碼中的位置。 要做到這一點,一種方法是打開一個 Google 試算表並將 opcodes 貼到 C 欄。[您可以透過建立這個已準備好的試算表的副本來跳過以下步驟](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing)。
+
+下一步是取得正確的程式碼位置,以便我們能夠理解跳轉。 我們將 opcode 大小放在 B 欄,位置(十六進位)放在 A 欄。在儲存格 `B1` 中輸入此函數,然後複製並貼到 B 欄的其餘部分,直到程式碼結束。 完成此操作後,您可以隱藏 B 欄。
+
+```
+=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)
+```
+
+首先,此函數為 opcode 本身增加一個位元組,然後尋找 `PUSH`。 Push opcodes 很特殊,因為它們需要額外的位元組來儲存被推送的值。 如果 opcode 是 `PUSH`,我們就提取位元組數並將其加上。
+
+在 `A1` 中放入第一個位移量,零。 然後,在 `A2` 中放入此函數,並再次複製貼到 A 欄的其餘部分:
+
+```
+=dec2hex(hex2dec(A1)+B1)
+```
+
+我們需要此函數來提供十六進位值,因為在跳轉(`JUMP` 和 `JUMPI`)之前推送的值是以十六進位形式給我們的。
+
+## 進入點 (0x00) {#the-entry-point-0x00}
+
+合約總是從第一個位元組開始執行。 這是程式碼的初始部分:
+
+| 位移 | Opcode | 堆疊(在 opcode 之後) |
+| -: | ------------ | ---------------------------------------------- |
+| 0 | PUSH1 0x80 | 0x80 |
+| 2 | PUSH1 0x40 | 0x40, 0x80 |
+| 4 | MSTORE | 空的 |
+| 5 | PUSH1 0x04 | 0x04 |
+| 7 | CALLDATASIZE | CALLDATASIZE 0x04 |
+| 8 | LT | CALLDATASIZE\<4 |
+| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 |
+| C | JUMPI | 空的 |
+
+這段程式碼做了兩件事:
+
+1. 將 0x80 作為一個 32 位元組的值寫入記憶體位置 0x40-0x5F(0x80 儲存在 0x5F,而 0x40-0x5E 都是零)。
+2. 讀取 calldata 大小。 通常,以太坊合約的呼叫資料遵循[應用程式二進位介面 (ABI)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html),該介面至少需要四個位元組用於函數選擇器。 如果呼叫資料大小小於四,跳轉到 0x5E。
+
+
+
+### 0x5E 的處理常式(用於非 ABI 呼叫資料){#the-handler-at-0x5e-for-non-abi-call-data}
+
+| 位移 | Opcode |
+| -: | ------------ |
+| 5E | JUMPDEST |
+| 5E | CALLDATASIZE |
+| 60 | PUSH2 0x007c |
+| 63 | JUMPI |
+
+此程式碼片段以 `JUMPDEST` 開頭。 EVM(以太坊虛擬機)程式如果跳轉到不是 `JUMPDEST` 的 opcode,將會拋出例外。 然後它會查看 CALLDATASIZE,如果它是「真」(即,非零),則跳轉到 0x7C。 我們稍後會講到這個。
+
+| 位移 | Opcode | 堆疊(在 opcode 之後) |
+| -: | ---------- | -------------------------------------------------------------------------------------- |
+| 64 | CALLVALUE | 呼叫提供的 [Wei](/glossary/#wei)。 在 Solidity 中稱為 `msg.value` |
+| 65 | PUSH1 0x06 | 6 CALLVALUE |
+| 67 | PUSH1 0x00 | 0 6 CALLVALUE |
+| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE |
+| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE |
+| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE |
+
+所以當沒有呼叫資料時,我們讀取 Storage[6] 的值。 我們還不知道這個值是什麼,但我們可以尋找合約收到的沒有呼叫資料的交易。 在 Etherscan 中,僅轉帳 ETH 而沒有任何呼叫資料(因此沒有方法)的交易,其方法為 `Transfer`。 事實上,[合約收到的第一筆交易](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7) 就是一筆轉帳。
+
+如果我們查看那筆交易並點擊 **Click to see More**,我們會看到呼叫資料(稱為輸入資料)確實是空的(`0x`)。 另請注意,其價值為 1.559 ETH,這在稍後會相關。
+
+
+
+接下來,點擊 **State** 標籤並展開我們正在進行逆向工程的合約 (0x2510...)。 您可以看到 `Storage[6]` 在交易期間確實發生了變化,如果您將 Hex 改為 **Number**,您會看到它變成了 1,559,000,000,000,000,000,即以 wei 為單位的轉帳值(為清晰起見,我加了逗號),對應於下一個合約值。
+
+![Storage[6] 的變化](storage6.png)
+
+如果我們查看由[同一時期的其他 `Transfer` 交易](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange)引起的狀態變更,我們可以看到 `Storage[6]` 在一段時間內追蹤了合約的價值。 目前我們將其稱為 `Value*`。 星號 (`*`) 提醒我們,我們還不_知道_這個變數的作用,但它不可能只是為了追蹤合約價值,因為當您可以使用 `ADDRESS BALANCE` 取得帳戶餘額時,沒有必要使用非常昂貴的儲存空間。 第一個 opcode 推送合約自己的地址。 第二個 opcode 讀取堆疊頂部的地址,並將其替換為該地址的餘額。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ------------ | ------------------------------------------- |
+| 6C | PUSH2 0x0075 | 0x75 Value\* CALLVALUE 0 6 CALLVALUE |
+| 6F | SWAP2 | CALLVALUE Value\* 0x75 0 6 CALLVALUE |
+| 70 | SWAP1 | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 71 | PUSH2 0x01a7 | 0x01A7 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 74 | JUMP | |
+
+我們將在跳轉目的地繼續追蹤這段程式碼。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ---------- | ----------------------------------------------------------- |
+| 1A7 | JUMPDEST | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1A8 | PUSH1 0x00 | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AA | DUP3 | CALLVALUE 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AB | NOT | 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+
+`NOT` 是位元運算,所以它會反轉呼叫值中每個位元的值。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | ------------------------------------------------------------------------------------------------------ |
+| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AE | ISZERO | Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AF | PUSH2 0x01df | 0x01DF Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1B2 | JUMPI | |
+
+如果 `Value*` 小於或等於 2^256-CALLVALUE-1,我們就跳轉。 這看起來像是防止溢位的邏輯。 事實上,我們看到在位移 0x01DE 處,經過一些無意義的操作後(例如,寫入即將被刪除的記憶體),如果檢測到溢位,合約會還原,這是正常行為。
+
+請注意,這樣的溢位極不可能發生,因為它需要呼叫值加上 `Value*` 的總和與 2^256 wei(約 10^59 ETH)相當。 [在撰寫本文時,ETH 的總供應量不到兩億](https://etherscan.io/stat/supply)。
+
+| 位移 | Opcode | 堆疊 |
+| --: | -------- | ----------------------------------------- |
+| 1DF | JUMPDEST | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E0 | POP | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E1 | ADD | Value\*+CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E2 | SWAP1 | 0x75 Value\*+CALLVALUE 0 6 CALLVALUE |
+| 1E3 | JUMP | |
+
+如果我們到達這裡,取得 `Value* + CALLVALUE` 並跳轉到位移 0x75。
+
+| 位移 | Opcode | 堆疊 |
+| -: | -------- | ------------------------------- |
+| 75 | JUMPDEST | Value\*+CALLVALUE 0 6 CALLVALUE |
+| 76 | SWAP1 | 0 Value\*+CALLVALUE 6 CALLVALUE |
+| 77 | SWAP2 | 6 Value\*+CALLVALUE 0 CALLVALUE |
+| 78 | SSTORE | 0 CALLVALUE |
+
+如果我們到達這裡(這要求呼叫資料為空),我們會將呼叫值加到 `Value*` 上。 這與我們所說的 `Transfer` 交易的作用一致。
+
+| 位移 | Opcode |
+| -: | ------ |
+| 79 | POP |
+| 7A | POP |
+| 7B | STOP |
+
+最後,清除堆疊(這不是必要的)並標示交易成功結束。
+
+總結一下,這是初始程式碼的流程圖。
+
+
+
+## 0x7C 的處理常式 {#the-handler-at-0x7c}
+
+我故意不在標題中說明這個處理常式的作用。 重點不是教您這個特定合約如何運作,而是如何對合約進行逆向工程。 您將透過追蹤程式碼,以與我相同的方式了解它的作用。
+
+我們從幾個地方來到這裡:
+
+- 如果呼叫資料為 1、2 或 3 個位元組(從位移 0x63 開始)
+- 如果方法簽名未知(從位移 0x42 和 0x5D 開始)
+
+| 位移 | Opcode | 堆疊 |
+| -: | ------------ | ------------------------------------------------------------------------ |
+| 7C | JUMPDEST | |
+| 7D | PUSH1 0x00 | 0x00 |
+| 7F | PUSH2 0x009d | 0x9D 0x00 |
+| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 |
+| 84 | SLOAD | Storage[3] 0x9D 0x00 |
+
+這是另一個儲存單元,我在任何交易中都找不到它,所以很難知道它的意思。 下面的程式碼將使其更清晰。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 85 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xff....ff Storage[3] 0x9D 0x00 |
+| 9A | AND | Storage[3]-as-address 0x9D 0x00 |
+
+這些 opcodes 將我們從 Storage[3] 讀取的值截斷為 160 位元,即以太坊地址的長度。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ------ | ----------------------------------------------------------------------------------- |
+| 9B | SWAP1 | 0x9D Storage[3]-as-address 0x00 |
+| 9C | JUMP | Storage[3]-as-address 0x00 |
+
+這個跳轉是多餘的,因為我們要去下一個 opcode。 這段程式碼的 gas 效率遠不及應有的水平。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ---------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| 9D | JUMPDEST | Storage[3]-as-address 0x00 |
+| 9E | SWAP1 | 0x00 Storage[3]-as-address |
+| 9F | POP | Storage[3]-as-address |
+| A0 | PUSH1 0x40 | 0x40 Storage[3]-as-address |
+| A2 | MLOAD | Mem[0x40] Storage[3]-as-address |
+
+在程式碼的最開頭,我們將 Mem[0x40] 設置為 0x80。 如果我們稍後查看 0x40,我們會發現我們沒有改變它——所以我們可以假設它是 0x80。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ------------ | ----------------------------------------------------------------------------------------------------- |
+| A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-as-address |
+| A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-as-address |
+| A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-as-address |
+| A7 | CALLDATACOPY | 0x80 Storage[3]-as-address |
+
+將所有呼叫資料複製到記憶體,從 0x80 開始。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-as-address |
+| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-as-address |
+| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AD | DUP6 | Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AE | GAS | GAS Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AF | DELEGATE_CALL | |
+
+現在事情清楚多了。 這個合約可以作為[代理](https://blog.openzeppelin.com/proxy-patterns/),呼叫 Storage[3] 中的地址來完成實際工作。 `DELEGATE_CALL` 呼叫一個單獨的合約,但停留在同一個儲存空間。 這意味著被代理的合約,即我們作為代理的合約,會存取相同的儲存空間。 呼叫的參數是:
+
+- _Gas_:所有剩餘的 gas
+- _被呼叫的地址_:Storage[3]-as-address
+- _呼叫資料_:從 0x80 開始的 CALLDATASIZE 位元組,這是我們放置原始呼叫資料的地方
+- _返回資料_:無 (0x00 - 0x00) 我們將透過其他方式取得返回資料(見下文)
+
+| 位移 | Opcode | 堆疊 |
+| -: | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| B0 | RETURNDATASIZE | RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| B4 | DUP5 | 0x80 0x00 RETURNDATASIZE RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| B5 | RETURNDATACOPY | RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+
+在這裡,我們將所有返回資料複製到從 0x80 開始的記憶體緩衝區。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| B6 | DUP2 | (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| B7 | DUP1 | (((呼叫成功/失敗))) (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| B8 | ISZERO | (((呼叫失敗了嗎))) (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| B9 | PUSH2 0x00c0 | 0xC0 (((呼叫失敗了嗎))) (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| BC | JUMPI | (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| BD | DUP2 | RETURNDATASIZE (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| BE | DUP5 | 0x80 RETURNDATASIZE (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| BF | RETURN | |
+
+因此,在呼叫之後,我們將返回資料複製到緩衝區 0x80 - 0x80+RETURNDATASIZE,如果呼叫成功,我們就用那個緩衝區進行 `RETURN`。
+
+### DELEGATECALL 失敗 {#delegatecall-failed}
+
+如果我們到達這裡,到 0xC0,這意味著我們呼叫的合約已還原。 由於我們只是該合約的代理,我們希望返回相同的資料並也進行還原。
+
+| 位移 | Opcode | 堆疊 |
+| -: | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| C0 | JUMPDEST | (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| C1 | DUP2 | RETURNDATASIZE (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| C2 | DUP5 | 0x80 RETURNDATASIZE (((呼叫成功/失敗))) RETURNDATASIZE (((呼叫成功/失敗))) 0x80 Storage[3]-as-address |
+| C3 | REVERT | |
+
+所以我們使用與之前用於 `RETURN` 相同的緩衝區進行 `REVERT`:0x80 - 0x80+RETURNDATASIZE
+
+
+
+## ABI 呼叫 {#abi-calls}
+
+如果呼叫資料大小為四個位元組或更多,這可能是一個有效的 ABI 呼叫。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ------------ | -------------------------------------------------------------------------------------------------------- |
+| D | PUSH1 0x00 | 0x00 |
+| F | CALLDATALOAD | (((呼叫資料的第一個字 (256 位元))) |
+| 10 | PUSH1 0xe0 | 0xE0 (((呼叫資料的第一個字 (256 位元))) |
+| 12 | SHR | (((呼叫資料的前 32 位元 (4 位元組))) |
+
+Etherscan 告訴我們 `1C` 是一個未知的 opcode,因為[它是在 Etherscan 編寫此功能後添加的](https://eips.ethereum.org/EIPS/eip-145),而且他們尚未更新。 一份[最新的 opcode 表格](https://github.com/wolflo/evm-opcodes)顯示這是向右移位
+
+| 位移 | Opcode | 堆疊 |
+| -: | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 13 | DUP1 | (((呼叫資料的前 32 位元 (4 位元組))) (((呼叫資料的前 32 位元 (4 位元組))) |
+| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((呼叫資料的前 32 位元 (4 位元組))) (((呼叫資料的前 32 位元 (4 位元組))) |
+| 19 | GT | 0x3CD8045E>呼叫資料的前 32 位元 (((呼叫資料的前 32 位元 (4 位元組))) |
+| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>呼叫資料的前 32 位元 (((呼叫資料的前 32 位元 (4 位元組))) |
+| 1D | JUMPI | (((呼叫資料的前 32 位元 (4 位元組))) |
+
+像這樣將方法簽名匹配測試分成兩部分,平均可以節省一半的測試時間。 緊隨其後的程式碼和 0x43 中的程式碼遵循相同的模式:`DUP1` 呼叫資料的前 32 位元,`PUSH4 (((方法簽名)))`,執行 `EQ` 檢查是否相等,然後如果方法簽名匹配則 `JUMPI`。 以下是方法簽名、它們的地址,以及(如果已知)[相應的方法定義](https://www.4byte.directory/):
+
+| 方法 | 方法簽名 | 跳轉到的位移 |
+| --------------------------------------------------------------------------------------------------------- | ---------- | ------ |
+| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 |
+| ??? | 0x81e580d3 | 0x0138 |
+| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 |
+| ??? | 0x1f135823 | 0x00C4 |
+| [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED |
+
+如果找不到匹配項,程式碼會跳轉到 [0x7C 的代理處理常式](#the-handler-at-0x7c),希望我們作為代理的合約有匹配項。
+
+
+
+## splitter() {#splitter}
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | ----------------------------- |
+| 103 | JUMPDEST | |
+| 104 | CALLVALUE | CALLVALUE |
+| 105 | DUP1 | CALLVALUE CALLVALUE |
+| 106 | ISZERO | CALLVALUE==0 CALLVALUE |
+| 107 | PUSH2 0x010f | 0x010F CALLVALUE==0 CALLVALUE |
+| 10A | JUMPI | CALLVALUE |
+| 10B | PUSH1 0x00 | 0x00 CALLVALUE |
+| 10D | DUP1 | 0x00 0x00 CALLVALUE |
+| 10E | REVERT | |
+
+這個函數首先檢查呼叫是否發送了任何 ETH。 這個函數不是 [`payable`](https://solidity-by-example.org/payable/)。 如果有人向我們發送 ETH,那一定是個錯誤,我們希望 `REVERT` 以避免那些 ETH 留在他們無法取回的地方。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 10F | JUMPDEST | |
+| 110 | POP | |
+| 111 | PUSH1 0x03 | 0x03 |
+| 113 | SLOAD | (((Storage[3] 又名我們代理的合約))) |
+| 114 | PUSH1 0x40 | 0x40 (((Storage[3] 又名我們代理的合約))) |
+| 116 | MLOAD | 0x80 (((Storage[3] 又名我們代理的合約))) |
+| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] 又名我們代理的合約))) |
+| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] 又名我們代理的合約))) |
+| 12D | SWAP2 | (((Storage[3] 又名我們代理的合約))) 0xFF...FF 0x80 |
+| 12E | AND | ProxyAddr 0x80 |
+| 12F | DUP2 | 0x80 ProxyAddr 0x80 |
+| 130 | MSTORE | 0x80 |
+
+而 0x80 現在包含代理地址
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | --------- |
+| 131 | PUSH1 0x20 | 0x20 0x80 |
+| 133 | ADD | 0xA0 |
+| 134 | PUSH2 0x00e4 | 0xE4 0xA0 |
+| 137 | JUMP | 0xA0 |
+
+### E4 程式碼 {#the-e4-code}
+
+這是我們第一次看到這些行,但它們與其他方法共用(見下文)。 所以我們將堆疊中的值稱為 X,並記住,在 `splitter()` 中,這個 X 的值是 0xA0。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ---------- | ----------- |
+| E4 | JUMPDEST | X |
+| E5 | PUSH1 0x40 | 0x40 X |
+| E7 | MLOAD | 0x80 X |
+| E8 | DUP1 | 0x80 0x80 X |
+| E9 | SWAP2 | X 0x80 0x80 |
+| EA | SUB | X-0x80 0x80 |
+| EB | SWAP1 | 0x80 X-0x80 |
+| EC | RETURN | |
+
+所以這段程式碼在堆疊中接收一個記憶體指標 (X),並使合約以一個 0x80 - X 的緩衝區 `RETURN`。
+
+在 `splitter()` 的情況下,這會返回我們代理的地址。 `RETURN` 返回 0x80-0x9F 中的緩衝區,這是我們寫入此資料的位置(上面的位移 0x130)。
+
+## currentWindow() {#currentwindow}
+
+位移 0x158-0x163 中的程式碼與我們在 `splitter()` 的 0x103-0x10E 中看到的相同(除了 `JUMPI` 目的地),所以我們知道 `currentWindow()` 也不是 `payable`。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | ------------------------------------------------------------------------ |
+| 164 | JUMPDEST | |
+| 165 | POP | |
+| 166 | PUSH2 0x00da | 0xDA |
+| 169 | PUSH1 0x01 | 0x01 0xDA |
+| 16B | SLOAD | Storage[1] 0xDA |
+| 16C | DUP2 | 0xDA Storage[1] 0xDA |
+| 16D | JUMP | Storage[1] 0xDA |
+
+### DA 程式碼 {#the-da-code}
+
+這段程式碼也與其他方法共用。 所以我們將堆疊中的值稱為 Y,並記住,在 `currentWindow()` 中,這個 Y 的值是 Storage[1]。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ---------- | ---------------- |
+| DA | JUMPDEST | Y 0xDA |
+| DB | PUSH1 0x40 | 0x40 Y 0xDA |
+| DD | MLOAD | 0x80 Y 0xDA |
+| DE | SWAP1 | Y 0x80 0xDA |
+| DF | DUP2 | 0x80 Y 0x80 0xDA |
+| E0 | MSTORE | 0x80 0xDA |
+
+將 Y 寫入 0x80-0x9F。
+
+| 位移 | Opcode | 堆疊 |
+| -: | ---------- | -------------- |
+| E1 | PUSH1 0x20 | 0x20 0x80 0xDA |
+| E3 | ADD | 0xA0 0xDA |
+
+其餘的已在[上面](#the-e4-code)解釋過了。 所以跳轉到 0xDA 會將堆疊頂部 (Y) 寫入 0x80-0x9F,並返回該值。 在 `currentWindow()` 的情況下,它返回 Storage[1]。
+
+## merkleRoot() {#merkleroot}
+
+位移 0xED-0xF8 中的程式碼與我們在 `splitter()` 的 0x103-0x10E 中看到的相同(除了 `JUMPI` 目的地),所以我們知道 `merkleRoot()` 也不是 `payable`。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | ------------------------------------------------------------------------ |
+| F9 | JUMPDEST | |
+| FA | POP | |
+| FB | PUSH2 0x00da | 0xDA |
+| FE | PUSH1 0x00 | 0x00 0xDA |
+| 100 | SLOAD | Storage[0] 0xDA |
+| 101 | DUP2 | 0xDA Storage[0] 0xDA |
+| 102 | JUMP | Storage[0] 0xDA |
+
+跳轉後發生的事情[我們已經弄清楚了](#the-da-code)。 所以 `merkleRoot()` 返回 Storage[0]。
+
+## 0x81e580d3 {#0x81e580d3}
+
+位移 0x138-0x143 中的程式碼與我們在 `splitter()` 的 0x103-0x10E 中看到的相同(除了 `JUMPI` 目的地),所以我們知道這個函數也不是 `payable`。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | ------------------------------------------------------------------------------- |
+| 144 | JUMPDEST | |
+| 145 | POP | |
+| 146 | PUSH2 0x00da | 0xDA |
+| 149 | PUSH2 0x0153 | 0x0153 0xDA |
+| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA |
+| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA |
+| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+
+看起來這個函數至少需要 32 個位元組(一個字)的呼叫資料。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------ | -------------------------------------------- |
+| 19D | DUP1 | 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 19E | DUP2 | 0x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 19F | REVERT | |
+
+如果它沒有得到呼叫資料,交易會被還原而沒有任何返回資料。
+
+讓我們看看如果函數_確實_得到了它需要的呼叫資料會發生什麼。
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | ----------------------------------------------------------- |
+| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 1A2 | CALLDATALOAD | calldataload(4) CALLDATASIZE 0x0153 0xDA |
+
+`calldataload(4)` 是呼叫資料中方法簽名_之後_的第一個字
+
+| 位移 | Opcode | 堆疊 |
+| --: | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA |
+| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA |
+| 1A5 | POP | 0x0153 calldataload(4) 0xDA |
+| 1A6 | JUMP | calldataload(4) 0xDA |
+| 153 | JUMPDEST | calldataload(4) 0xDA |
+| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA |
+| 157 | JUMP | calldataload(4) 0xDA |
+| 16E | JUMPDEST | calldataload(4) 0xDA |
+| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA |
+| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA |
+| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA |
+| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA |
+| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA |
+| 175 | LT | calldataload(4)\)`,另一個是 `isClaimed()`,所以它看起來像一個空投合約。 與其逐個 opcode 瀏覽其餘部分,我們可以[嘗試反編譯器](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761),它從這個合約中為三個函數產生了可用的結果。 對其他函數的逆向工程留給讀者作為練習。
+
+### scaleAmountByPercentage {#scaleamountbypercentage}
+
+以下是反編譯器為此函數提供的內容:
+
+```python
+def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
+ require calldata.size - 4 >=′ 64
+ if _param1 and _param2 > -1 / _param1:
+ revert with 0, 17
+ return (_param1 * _param2 / 100 * 10^6)
+```
+
+第一個 `require` 測試呼叫資料除了函數簽名的四個位元組外,至少還有 64 個位元組,足以容納兩個參數。 如果不是,顯然有問題。
+
+`if` 語句似乎檢查 `_param1` 是否不為零,以及 `_param1 * _param2` 是否不為負。 這可能是為了防止環繞的情況。
+
+最後,函數返回一個縮放後的值。
+
+### 申領 {#claim}
+
+反編譯器創建的程式碼很複雜,並非所有程式碼都與我們相關。 我將跳過其中一部分,專注於我認為提供有用資訊的行
+
+```python
+def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
+ ...
+ require _param2 == addr(_param2)
+ ...
+ if currentWindow <= _param1:
+ revert with 0, 'cannot claim for a future window'
+```
+
+我們在這裡看到兩個重要的事情:
+
+- `_param2`,雖然它被聲明為 `uint256`,但實際上是一個地址
+- `_param1` 是被申領的窗口,必須是 `currentWindow` 或更早。
+
+```python
+ ...
+ if stor5[_claimWindow][addr(_claimFor)]:
+ revert with 0, 'Account already claimed the given window'
+```
+
+所以現在我們知道 Storage[5] 是一個視窗和地址的陣列,以及地址是否已為該視窗申領獎勵。
+
+```python
+ ...
+ idx = 0
+ s = 0
+ while idx < _param4.length:
+ ...
+ if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
+ mem[mem[64] + 32] = mem[(32 * idx) + 296]
+ ...
+ s = sha3(mem[_62 + 32 len mem[_62]])
+ continue
+ ...
+ s = sha3(mem[_66 + 32 len mem[_66]])
+ continue
+ if unknown2eb4a7ab != s:
+ revert with 0, 'Invalid proof'
+```
+
+我們知道 `unknown2eb4a7ab` 實際上是 `merkleRoot()` 函數,所以這段程式碼看起來像是在驗證一個 [merkle 證明](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5)。 這意味著 `_param4` 是一個 merkle 證明。
+
+```python
+call addr(_param2) with:
+ value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
+ gas 30000 wei
+```
+
+這是一個合約將自己的 ETH 轉移到另一個地址(合約或外部擁有)的方式。 它以要轉移的金額作為值來呼叫它。 所以看起來這是一次 ETH 空投。
+
+```python
+if not return_data.size:
+ if not ext_call.success:
+ require ext_code.size(stor2)
+ call stor2.deposit() with:
+ value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
+```
+
+最下面兩行告訴我們,Storage[2] 也是我們呼叫的一個合約。 如果我們[查看建構子交易](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange),我們會看到這個合約是 [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2),一個 [其原始碼已上傳到 Etherscan 的](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code) 包裝以太幣合約。
+
+所以看起來合約試圖將 ETH 發送給 `_param2`。 如果能成功,那就太好了。 如果不行,它會嘗試發送 [WETH](https://weth.tkn.eth.limo/)。 如果 `_param2` 是一個外部擁有的帳戶 (EOA),那麼它總是可以接收 ETH,但合約可以拒絕接收 ETH。 然而,WETH 是 ERC-20,合約不能拒絕接受它。
+
+```python
+log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)
+```
+
+在函數的末尾,我們看到一個日誌條目正在生成。 [查看生成的日誌條目](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) 並過濾以 `0xdbd5...` 開頭的主題。 如果我們[點擊其中一筆產生此類條目的交易](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274),我們會看到它確實看起來像一次申領——該帳戶向我們正在進行逆向工程的合約發送了一條訊息,並作為回報收到了 ETH。
+
+
+
+### 1e7df9d3 {#1e7df9d3}
+
+這個函數與上面的 [`claim`](#claim) 非常相似。 它還會檢查 merkle 證明,嘗試將 ETH 轉移給第一個,並產生相同類型的日誌條目。
+
+```python
+def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
+ ...
+ idx = 0
+ s = 0
+ while idx < _param3.length:
+ if idx >= mem[96]:
+ revert with 0, 50
+ _55 = mem[(32 * idx) + 128]
+ if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
+ ...
+ s = sha3(mem[_58 + 32 len mem[_58]])
+ continue
+ mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
+ ...
+ if unknown2eb4a7ab != s:
+ revert with 0, 'Invalid proof'
+ ...
+ call addr(_param1) with:
+ value s wei
+ gas 30000 wei
+ if not return_data.size:
+ if not ext_call.success:
+ require ext_code.size(stor2)
+ call stor2.deposit() with:
+ value s wei
+ gas gas_remaining wei
+ ...
+ log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
+```
+
+主要區別在於第一個參數,即要提領的視窗,不存在。 取而代之的是,有一個迴圈遍歷所有可以申領的視窗。
+
+```python
+ idx = 0
+ s = 0
+ while idx < currentWindow:
+ ...
+ if stor5[mem[0]]:
+ if idx == -1:
+ revert with 0, 17
+ idx = idx + 1
+ s = s
+ continue
+ ...
+ stor5[idx][addr(_param1)] = 1
+ if idx >= unknown81e580d3.length:
+ revert with 0, 50
+ mem[0] = 4
+ if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
+ revert with 0, 17
+ if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
+ revert with 0, 17
+ if idx == -1:
+ revert with 0, 17
+ idx = idx + 1
+ s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
+ continue
+```
+
+所以它看起來像一個申領所有視窗的 `claim` 變體。
+
+## 結論 {#conclusion}
+
+到目前為止,您應該知道如何使用 opcodes 或(當它起作用時)反編譯器來理解沒有原始碼的合約。 從本文的篇幅可以明顯看出,對合約進行逆向工程並非易事,但在一個安全至關重要的系統中,能夠驗證合約是否如承諾般運作是一項重要的技能。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
new file mode 100644
index 00000000000..d54d2c08c4b
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
@@ -0,0 +1,184 @@
+---
+title: 在 Raspberry Pi 4 上執行一個以太坊節點
+description: 為您的 Raspberry Pi 4 刷機、插入乙太網路線、連接 SSD 硬碟並開啟裝置電源,即可將 Raspberry Pi 4 變成一個完整的以太坊節點 + 驗證程式
+author: "EthereumOnArm"
+tags: [ "用戶端", "執行層", "共識層", "節點" ]
+lang: zh-tw
+skill: intermediate
+published: 2022-06-10
+source: ARM 上的以太坊
+sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/
+---
+
+**Ethereum on Arm 是一個自訂的 Linux 映像檔,可以將 Raspberry Pi 變成一個以太坊節點。**
+
+要使用 Ethereum on Arm 將 Raspberry Pi 變成一個以太坊節點,建議使用以下硬體:
+
+- Raspberry 4 (B 型 8GB)、Odroid M1 或 Rock 5B (8GB/16GB RAM) 開發板
+- MicroSD 卡 (最低 16 GB Class 10)
+- 最低 2 TB SSD USB 3.0 磁碟,或附帶 USB 轉 SATA 外接盒的 SSD。
+- 電源供應器
+- 乙太網路線
+- 通訊埠轉發 (詳情請參閱用戶端)
+- 附散熱片和風扇的機殼
+- USB 鍵盤、螢幕和 HDMI 連接線 (micro-HDMI) (選用)
+
+## 為什麼要在 ARM 上執行以太坊? {#why-run-ethereum-on-arm}
+
+ARM 開發板是非常實惠、靈活的小型電腦。 它們是執行以太坊節點的絕佳選擇,因為它們價格低廉,可以設定成將所有資源都集中在節點上,從而提高效率,而且它們耗電量低、體積小,可以不佔空間地放置在家中任何地方。 啟動節點也非常容易,因為 Raspberry Pi 的 MicroSD 只要用預先建置的映像檔刷機即可,不需要下載或建置軟體。
+
+## 它是如何運作的? {#how-does-it-work}
+
+Raspberry Pi 的記憶卡已用預先建置的映像檔刷機。 此映像檔包含執行以太坊節點所需的一切。 使用已刷機的記憶卡,使用者只需要開啟 Raspberry Pi 的電源。 所有執行節點所需的程序都會自動啟動。 這是可行的,因為記憶卡包含一個以 Linux 為基礎的作業系統 (OS),系統級的程序會在其上自動執行,將裝置變成一個以太坊節點。
+
+無法使用熱門的 Raspberry Pi Linux 作業系統「Raspbian」來執行以太坊,因為 Raspbian 仍使用 32 位元架構,這會導致以太坊使用者遇到記憶體問題,而且共識用戶端不支援 32 位元二進位檔。 為了克服這個問題,Ethereum on Arm 團隊遷移到一個名為「Armbian」的原生 64 位元作業系統。
+
+**映像檔會處理所有必要的步驟**,從設定環境和格式化 SSD 磁碟,到安裝並執行以太坊軟體,以及開始區塊鏈同步。
+
+## 關於執行與共識用戶端的注意事項 {#note-on-execution-and-consensus-clients}
+
+Ethereum on Arm 映像檔包含預先建置的執行用戶端和共識用戶端作為服務。 以太坊節點需要兩個用戶端都保持同步和執行。 您只需要下載並刷入映像檔,然後啟動服務。 映像檔預先載入了以下執行用戶端:
+
+- Geth
+- Nethermind
+- Besu
+
+以及下列共識用戶端:
+
+- Lighthouse
+- Nimbus
+- Prysm
+- Teku
+
+您應該各選擇一個來執行,所有執行用戶端都與所有共識用戶端相容。 如果您沒有明確選擇用戶端,節點將會使用預設值 Geth 和 Lighthouse,並在開發板通電時自動執行它們。 您必須在路由器上開啟通訊埠 30303,這樣 Geth 才能找到並連接到對等點。
+
+## 下載映像檔 {#downloading-the-image}
+
+Raspberry Pi 4 以太坊映像檔是一個「隨插即用」的映像檔,它會自動安裝和設定執行用戶端和共識用戶端,並設定它們彼此通訊及連接到以太坊網路。 使用者只需要使用一個簡單的指令來啟動他們的程序。
+
+從 [Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1) 下載 Raspberry Pi 映像檔並驗證 SHA256 雜湊值:
+
+```sh
+# 從包含已下載映像檔的目錄
+shasum -a 256 ethonarm_22.04.00.img.zip
+# 雜湊值應輸出: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f
+```
+
+請注意,Rock 5B 和 Odroid M1 開發板的映像檔可在 Ethereum-on-Arm 的 [下載頁面](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html) 取得。
+
+## 刷入 MicroSD {#flashing-the-microsd}
+
+要用於 Raspberry Pi 的 MicroSD 卡應先插入桌上型電腦或筆記型電腦以進行刷機。 然後,以下終端機指令會將下載的映像檔刷入 SD 卡:
+
+```shell
+# 檢查 MicroSD 卡名稱
+sudo fdisk -l
+
+>> sdxxx
+```
+
+正確取得名稱非常重要,因為下一個指令包含 `dd`,它會在將映像檔推送到記憶卡之前完全清除其現有內容。 若要繼續,請導覽至包含壓縮映像檔的目錄:
+
+```shell
+# 解壓縮並刷入映像檔
+unzip ethonarm_22.04.00.img.zip
+sudo dd bs=1M if=ethonarm_22.04.00.img of=/dev/ conv=fdatasync status=progress
+```
+
+記憶卡現在已刷機完成,可以插入 Raspberry Pi 了。
+
+## 啟動節點 {#start-the-node}
+
+將 SD 卡插入 Raspberry Pi 後,連接乙太網路線和 SSD,然後開啟電源。 作業系統將會啟動,並自動開始執行預先設定的任務,將 Raspberry Pi 變成一個以太坊節點,包括安裝和建置用戶端軟體。 這可能需要 10-15 分鐘。
+
+一旦所有內容都安裝並設定完成,請透過 ssh 連線登入裝置,或者如果開發板上連接了螢幕和鍵盤,則直接使用終端機登入。 使用 `ethereum` 帳戶登入,因為它具有啟動節點所需的權限。
+
+```shell
+使用者:ethereum
+密碼:ethereum
+```
+
+預設的執行用戶端 Geth 將會自動啟動。 您可以透過使用以下終端機指令檢查記錄來確認這一點:
+
+```sh
+sudo journalctl -u geth -f
+```
+
+共識用戶端確實需要明確地啟動。 為此,請先在路由器上開啟通訊埠 9000,以便 Lighthouse 可以找到並連接到對等點。 然後啟用並啟動 lighthouse 服務:
+
+```sh
+sudo systemctl enable lighthouse-beacon
+sudo systemctl start lighthouse-beacon
+```
+
+使用記錄檢查用戶端:
+
+```sh
+sudo journalctl -u lighthouse-beacon
+```
+
+請注意,共識用戶端將在幾分鐘內同步,因為它使用檢查點同步。 執行用戶端將需要更長的時間,可能需要幾個小時,並且在共識用戶端同步完成之前不會啟動 (這是因為執行用戶端需要一個同步目標,而同步完成的共識用戶端會提供該目標)。
+
+在 Geth 和 Lighthouse 服務執行並同步後,您的 Raspberry Pi 現在就是一個以太坊節點了! 最常見的與以太坊網路互動的方式是使用 Geth 的 Javascript 主控台,它可以附加到通訊埠 8545 上的 Geth 用戶端。 也可以使用像 Curl 這樣的請求工具來提交格式化為 JSON 物件的指令。 更多資訊請參閱 [Geth 文件](https://geth.ethereum.org/)。
+
+Geth 已預先設定為向 Grafana 儀表板回報指標,該儀表板可在瀏覽器中檢視。 更進階的使用者可能會希望使用此功能來監控其節點的健康狀況,方法是導覽至 `ipaddress:3000`,並傳入 `user: admin` 和 `passwd: ethereum`。
+
+## 驗證程式 {#validators}
+
+也可以選擇性地將驗證程式新增至共識用戶端。 驗證程式軟體可讓您的節點積極參與共識,並為網路提供加密經濟安全性。 您將會因這項工作獲得 ETH 作為酬勞。 若要執行驗證程式,您必須先擁有 32 枚 ETH,這些 ETH 必須存入存款合約中。 可以按照 [Launchpad](https://launchpad.ethereum.org/) 上的逐步指南進行存款。 請在桌上型電腦/筆記型電腦上執行此操作,但不要產生金鑰 — 這可以直接在 Raspberry Pi 上完成。
+
+在 Raspberry Pi 上開啟一個終端機,並執行以下指令來產生存款金鑰:
+
+```
+sudo apt-get update
+sudo apt-get install staking-deposit-cli
+cd && deposit new-mnemonic --num_validators 1
+```
+
+(或下載 [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) 在離線機器上執行,並執行 `deposit new-mnemnonic` 指令)
+
+請妥善保管您的助憶詞! 上述指令在節點的密鑰存儲檔案中產生了兩個檔案:驗證程式金鑰和一個存款資料檔案。 存款資料需要上傳到 Launchpad,因此必須將其從 Raspberry Pi 複製到桌上型電腦/筆記型電腦。 這可以透過 ssh 連線或任何其他複製/貼上方法來完成。
+
+一旦執行 Launchpad 的電腦上有了存款資料檔案,就可以將其拖放到 Launchpad 畫面上的 `+` 號上。 按照螢幕上的指示將一筆交易傳送到存款合約。
+
+回到 Raspberry Pi 上,就可以啟動一個驗證程式了。 這需要匯入驗證程式金鑰、設定收取酬勞的地址,然後啟動預先設定的驗證程式程序。 以下範例適用於 Lighthouse—其他共識用戶端的說明可在 [Ethereum on Arm 文件](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) 中找到:
+
+```shell
+# 匯入驗證程式金鑰
+lighthouse account validator import --directory=/home/ethereum/validator_keys
+
+# 設定酬勞地址
+sudo sed -i 's/' /etc/ethereum/lighthouse-validator.conf
+
+# 啟動驗證程式
+sudo systemctl start lighthouse-validator
+```
+
+恭喜,您現在已經在 Raspberry Pi 上執行一個完整的以太坊節點和驗證程式了!
+
+## 更多詳細資訊 {#more-details}
+
+本頁面概述了如何使用 Raspberry Pi 設定 Geth-Lighthouse 節點和驗證程式。 更詳細的說明可在 [Ethereum-on-Arm 網站](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html) 上取得。
+
+## 感謝您的回饋 {#feedback-appreciated}
+
+我們知道 Raspberry Pi 擁有龐大的使用者群,這對以太坊網路的健康狀況可能產生非常正面的影響。
+請深入研究本使用教學中的詳細資訊、嘗試在測試網上執行、查看 Ethereum on Arm 的 GitHub、提供回饋、提出問題和提取請求,並協助推動技術和文件的進步!
+
+## 參考資料 {#references}
+
+1. https://ubuntu.com/download/raspberry-pi
+2. https://wikipedia.org/wiki/Port_forwarding
+3. https://prometheus.io
+4. https://grafana.com
+5. https://forum.armbian.com/topic/5565-zram-vs-swap/
+6. https://geth.ethereum.org
+7. https://nethermind.io
+8. https://www.hyperledger.org/projects/besu
+9. https://github.com/prysmaticlabs/prysm
+10. https://lighthouse.sigmaprime.io
+11. https://ethersphere.github.io/swarm-home
+12. https://raiden.network
+13. https://ipfs.io
+14. https://status.im
+15. https://vipnode.org
diff --git a/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
new file mode 100644
index 00000000000..f54c09d342e
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
@@ -0,0 +1,470 @@
+---
+title: "詐騙代幣使用的一些伎倆以及如何偵測它們"
+description: 在本使用教學中,我們將剖析一個詐騙代幣,以了解詐騙者所玩的伎倆、他們如何實作這些伎倆,以及我們該如何偵測它們。
+author: 作者:Ori Pomerantz
+tags:
+ [
+ "詐騙",
+ "solidity",
+ "erc-20",
+ "javascript",
+ "typescript"
+ ]
+skill: intermediate
+published: 2023-09-15
+lang: zh-tw
+---
+
+在本使用教學中,我們將剖析[一個詐騙代幣](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code),以了解詐騙者所玩的伎倆以及他們如何實作這些伎倆。 在本使用教學結束時,您將對 ERC-20 代幣合約、其功能以及為何保持懷疑是必要的有更全面的了解。 然後我們會查看該詐騙代幣發出的事件,並了解如何自動識別它不是合法的。
+
+## 詐騙代幣 - 它們是什麼、為什麼人們會做,以及如何避免它們 {#scam-tokens}
+
+以太坊最常見的用處之一就是為一個團隊建立一種可交易的代幣。某種意義上,這是屬於他們自己的貨幣。 然而,任何能產生價值的正當使用案例中,就會有犯罪者嘗試竊取該價值納為已用。
+
+您可以從使用者角度在 [ethereum.org 的其他地方](/guides/how-to-id-scam-tokens/)閱讀更多關於此主題的資訊。 本使用教學著重於剖析詐騙代幣,以了解其運作方式以及如何偵測。
+
+### 我如何知道 wARB 是個詐騙? {#warb-scam}
+
+我們剖析的代幣是 [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code),它偽裝成與合法的 [ARB 代幣](https://etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1)等效。
+
+要知道哪個是合法代幣,最簡單的方法是查看其發起組織 [Arbitrum](https://arbitrum.foundation/)。 合法的地址已在其[文件中](https://docs.arbitrum.foundation/deployment-addresses#token)指明。
+
+### 為什麼原始碼是可用的? {#why-source}
+
+通常,我們期望試圖詐騙他人的人會行事隱密,而事實上許多詐騙代幣也沒有提供其程式碼 (例如,[這一個](https://optimistic.etherscan.io/token/0x15992f382d8c46d667b10dc8456dc36651af1452#code) 和 [這一個](https://optimistic.etherscan.io/token/0x026b623eb4aada7de37ef25256854f9235207178#code))。
+
+然而,合法的代幣通常會公布其原始碼,因此為了看起來合法,詐騙代幣的作者有時也會這麼做。 [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) 是那些提供原始碼的代幣之一,這讓我們更容易理解它。
+
+雖然合約部署者可以選擇是否公布原始碼,但他們_無法_公布錯誤的原始碼。 區塊瀏覽器會獨立編譯提供的原始碼,如果沒有得到完全相同的位元組碼,它就會拒絕該原始碼。 [您可以在 Etherscan 網站上閱讀更多相關資訊](https://etherscan.io/verifyContract)。
+
+## 與合法的 ERC-20 代幣比較 {#compare-legit-erc20}
+
+我們將把這個代幣與合法的 ERC-20 代幣進行比較。 如果您不熟悉合法的 ERC-20 代幣通常是如何編寫的,請[參見本使用教學](/developers/tutorials/erc20-annotated-code/)。
+
+### 特權地址的常數 {#constants-for-privileged-addresses}
+
+合約有時需要特權地址。 設計用於長期使用的合約允許某些特權地址更改這些地址,例如啟用新的多重簽名合約。 有幾種方法可以做到這一點。
+
+[`HOP` 代幣合約](https://etherscan.io/address/0xc5102fe9359fd9a28f877a67e36b0f050d81a3cc#code) 使用 [`Ownable`](https://docs.openzeppelin.com/contracts/2.x/access-control#ownership-and-ownable) 模式。 特權地址保存在儲存空間中,位於一個名為 `_owner` 的欄位(請參見第三個檔案 `Ownable.sol`)。
+
+```solidity
+abstract contract Ownable is Context {
+ address private _owner;
+ .
+ .
+ .
+}
+```
+
+[`ARB` 代幣合約](https://etherscan.io/address/0xad0c361ef902a7d9851ca7dcc85535da2d3c6fc7#code) 沒有直接的特權地址。 然而,它並不需要。 它位於[地址 `0xb50721bcf8d664c30412cfbc6cf7a15145234ad1`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1#code) 的一個[`代理`](https://docs.openzeppelin.com/contracts/5.x/api/proxy) 後方。 該合約有一個可用於升級的特權地址 (請參見第四個檔案,`ERC1967Upgrade.sol`)。
+
+```solidity
+ /**
+ * @dev 在 EIP1967 管理員時隙中儲存一個新地址。
+ */
+ function _setAdmin(address newAdmin) private {
+ require(newAdmin != address(0), "ERC1967: new admin is the zero address");
+ StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;
+ }
+```
+
+相比之下,`wARB` 合約有一個硬編碼的 `contract_owner`。
+
+```solidity
+contract WrappedArbitrum is Context, IERC20 {
+ .
+ .
+ .
+ address deployer = 0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1;
+ address public contract_owner = 0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33;
+ .
+ .
+ .
+}
+```
+
+[這個合約擁有者](https://etherscan.io/address/0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33) 不是一個可以在不同時間由不同帳戶控制的合約,而是一個[外部擁有的帳戶](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs)。 這意味著它可能是為個人短期使用而設計的,而不是作為控制一個將保持價值的 ERC-20 的長期解決方案。
+
+事實上,如果我們在 Etherscan 上查看,會發現詐騙者在 2023 年 5 月 19 日期間只使用了這個合約 12 個小時(從[第一筆交易](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2)到[最後一筆交易](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b))。
+
+### 虛假的 `_transfer` 函數 {#the-fake-transfer-function}
+
+標準做法是使用[一個內部 `_transfer` 函數](/developers/tutorials/erc20-annotated-code/#the-_transfer-function-_transfer) 來進行實際的傳送。
+
+在 `wARB` 中,這個函數看起來幾乎是合法的:
+
+```solidity
+ function _transfer(address sender, address recipient, uint256 amount) internal virtual{
+ require(sender != address(0), "ERC20: transfer from the zero address");
+ require(recipient != address(0), "ERC20: transfer to the zero address");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
+ _balances[recipient] = _balances[recipient].add(amount);
+ if (sender == contract_owner){
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+可疑的部分是:
+
+```solidity
+ if (sender == contract_owner){
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+```
+
+如果合約擁有者傳送代幣,為什麼 `Transfer` 事件顯示它們來自 `deployer`?
+
+然而,還有一個更重要的問題。 誰調用了這個 `_transfer` 函數? 它不能從外部調用,因為它被標記為 `internal`。 而且我們擁有的程式碼不包含任何對 `_transfer` 的調用。 顯然,它在這裡是作為一個誘餌。
+
+```solidity
+ function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
+ _f_(_msgSender(), recipient, amount);
+ return true;
+ }
+
+ function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
+ _f_(sender, recipient, amount);
+ _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance"));
+ return true;
+ }
+```
+
+當我們查看被調用來傳送代幣的函數,`transfer` 和 `transferFrom` 時,我們發現它們調用了一個完全不同的函數,`_f_`。
+
+### 真正的 `_f_` 函數 {#the-real-f-function}
+
+```solidity
+ function _f_(address sender, address recipient, uint256 amount) internal _mod_(sender,recipient,amount) virtual {
+ require(sender != address(0), "ERC20: transfer from the zero address");
+ require(recipient != address(0), "ERC20: transfer to the zero address");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
+ _balances[recipient] = _balances[recipient].add(amount);
+ if (sender == contract_owner){
+
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+這個函數中有兩個潛在的危險信號。
+
+- 使用 [函數修飾符](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `_mod_`。 然而,當我們查看原始碼時,我們發現 `_mod_` 實際上是無害的。
+
+ ```solidity
+ modifier _mod_(address sender, address recipient, uint256 amount){
+ _;
+ }
+ ```
+
+- 我們在 `_transfer` 中看到的同樣問題,就是當 `contract_owner` 傳送代幣時,它們看起來像是來自 `deployer`。
+
+### 虛假事件函數 `dropNewTokens` {#the-fake-events-function-dropNewTokens}
+
+現在我們來看一個看起來像實際詐騙的東西。 為了可讀性,我對函數做了一點編輯,但它在功能上是等效的。
+
+```solidity
+function dropNewTokens(address uPool,
+ address[] memory eReceiver,
+ uint256[] memory eAmounts) public auth()
+```
+
+這個函數有 `auth()` 修飾符,這意味著它只能被合約擁有者調用。
+
+```solidity
+modifier auth() {
+ require(msg.sender == contract_owner, "Not allowed to interact");
+ _;
+}
+```
+
+這個限制完全合理,因為我們不希望隨機帳戶分發代幣。 然而,函數的其餘部分是可疑的。
+
+```solidity
+{
+ for (uint256 i = 0; i < eReceiver.length; i++) {
+ emit Transfer(uPool, eReceiver[i], eAmounts[i]);
+ }
+}
+```
+
+一個將資金從一個池帳戶轉移到一個接收者陣列並對應一個金額陣列的函數是完全合理的。 在許多使用案例中,您會希望將代幣從單一來源分發到多個目的地,例如薪資發放、空投等。 在單一交易中完成此操作比發出多個交易,或甚至在同一交易中從不同的合約多次調用 ERC-20 更便宜 (在 gas 方面)。
+
+然而,`dropNewTokens` 並沒有這樣做。 它發出 [`Transfer` 事件](https://eips.ethereum.org/EIPS/eip-20#transfer-1),但實際上並沒有傳送任何代幣。 沒有任何正當理由去告訴鏈外應用程式一筆並未真正發生的傳送,從而混淆它們。
+
+### 銷毀的 `Approve` 函數 {#the-burning-approve-function}
+
+ERC-20 合約應該有一個用於授權的 [`approve` 函數](/developers/tutorials/erc20-annotated-code/#approve),而我們的詐騙代幣確實有這樣一個函數,而且它甚至是正確的。 然而,因為 Solidity 源自 C 語言,所以它區分大小寫。 "Approve" 和 "approve" 是不同的字串。
+
+此外,其功能與 `approve` 無關。
+
+```solidity
+ function Approve(
+ address[] memory holders)
+```
+
+這個函數被調用時,會傳入一個代幣持有者的地址陣列。
+
+```solidity
+ public approver() {
+```
+
+`approver()` 修飾符確保只有 `contract_owner` 能夠調用此函數(見下文)。
+
+```solidity
+ for (uint256 i = 0; i < holders.length; i++) {
+ uint256 amount = _balances[holders[i]];
+ _beforeTokenTransfer(holders[i], 0x0000000000000000000000000000000000000001, amount);
+ _balances[holders[i]] = _balances[holders[i]].sub(amount,
+ "ERC20: burn amount exceeds balance");
+ _balances[0x0000000000000000000000000000000000000001] =
+ _balances[0x0000000000000000000000000000000000000001].add(amount);
+ }
+ }
+
+```
+
+對於每個持有者地址,該函數將持有者的全部餘額轉移到地址 `0x00...01`,實際上是銷毀了它(標準中的實際 `burn` 也會改變總供應量,並將代幣傳送到 `0x00...00`)。 這意味著 `contract_owner` 可以移除任何使用者的資產。 這似乎不是您希望在管理體系代幣中看到的功能。
+
+### 程式碼品質問題 {#code-quality-issues}
+
+這些程式碼品質問題並不能_證明_這段程式碼是詐騙,但它們使其顯得可疑。 像 Arbitrum 這樣的有組織的公司通常不會發布這麼差的程式碼。
+
+#### `mount` 函數 {#the-mount-function}
+
+雖然在[標準](https://eips.ethereum.org/EIPS/eip-20)中沒有指定,但一般來說,創建新代幣的函數稱為[`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn)。
+
+如果我們查看 `wARB` 的建構函式,我們會發現鑄幣函數由於某些原因被重新命名為 `mount`,並且為了效率,它被調用了五次,每次使用初始供應量的五分之一,而不是一次性處理全部金額。
+
+```solidity
+ constructor () public {
+
+ _name = "Wrapped Arbitrum";
+ _symbol = "wARB";
+ _decimals = 18;
+ uint256 initialSupply = 1000000000000;
+
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ }
+```
+
+`mount` 函數本身也很可疑。
+
+```solidity
+ function mount(address account, uint256 amount) public {
+ require(msg.sender == contract_owner, "ERC20: mint to the zero address");
+```
+
+查看 `require`,我們看到只有合約擁有者被允許鑄幣。 這是合法的。 但錯誤訊息應該是 _only owner is allowed to mint_ 或類似的內容。 相反,它卻是無關的 _ERC20: mint to the zero address_。 對於鑄幣到零地址的正確測試是 `require(account != address(0), "")`,但該合約從未費心去檢查。
+
+```solidity
+ _totalSupply = _totalSupply.add(amount);
+ _balances[contract_owner] = _balances[contract_owner].add(amount);
+ emit Transfer(address(0), account, amount);
+ }
+```
+
+還有兩個與鑄幣直接相關的可疑事實:
+
+- 有一個 `account` 參數,推測這應該是接收鑄幣金額的帳戶。 但增加的餘額實際上是 `contract_owner` 的。
+
+- 雖然增加的餘額屬於 `contract_owner`,但發出的事件卻顯示了一筆到 `account` 的傳送。
+
+### 為何同時有 `auth` 和 `approver`? 為什麼要有個什麼都不做的 `mod`? {#why-both-autho-and-approver-why-the-mod-that-does-nothing}
+
+這個合約包含三個修飾符:`_mod_`、`auth` 和 `approver`。
+
+```solidity
+ modifier _mod_(address sender, address recipient, uint256 amount){
+ _;
+ }
+```
+
+`_mod_` 接受三個參數,但對它們沒有做任何事情。 為什麼要有它?
+
+```solidity
+ modifier auth() {
+ require(msg.sender == contract_owner, "Not allowed to interact");
+ _;
+ }
+
+ modifier approver() {
+ require(msg.sender == contract_owner, "Not allowed to interact");
+ _;
+ }
+```
+
+`auth` 和 `approver` 更有意義,因為它們檢查合約是否由 `contract_owner` 調用。 我們預期某些特權操作,例如鑄幣,會被限制在該帳戶。 然而,擁有兩個做_完全相同事情_的獨立函數有什麼意義呢?
+
+## 我們可以自動偵測到什麼? {#what-can-we-detect-automatically}
+
+我們可以透過查看 Etherscan 發現 `wARB` 是一個詐騙代幣。 然而,那是一個中心化的解決方案。 理論上,Etherscan 可能被顛覆或駭入。 能夠獨立判斷一個代幣是否合法會更好。
+
+我們可以透過查看 ERC-20 代幣發出的事件,來使用一些技巧識別它是否可疑(可能是詐騙或寫得很差)。
+
+## 可疑的 `Approval` 事件 {#suspicious-approval-events}
+
+[`Approval` 事件](https://eips.ethereum.org/EIPS/eip-20#approval) 只應該在直接請求下發生(相較之下,[`Transfer` 事件](https://eips.ethereum.org/EIPS/eip-20#transfer-1) 可能因為授權而發生)。 有關此問題以及為何請求需要直接而非透過合約中介的詳細解釋,請[參見 Solidity 文件](https://docs.soliditylang.org/en/v0.8.20/security-considerations.html#tx-origin)。
+
+這意味著,授權從[外部擁有的帳戶](/developers/docs/accounts/#types-of-account)支出的 `Approval` 事件,必須來自源於該帳戶且目的地為 ERC-20 合約的交易。 任何其他來自外部擁有帳戶的授權都是可疑的。
+
+這裡有一個[識別這類事件的程式](https://github.com/qbzzt/20230915-scam-token-detection),它使用 [viem](https://viem.sh/) 和 [TypeScript](https://www.typescriptlang.org/docs/)(一種具有型別安全的 JavaScript 變體)。 若要執行它:
+
+1. 將 `.env.example` 複製為 `.env`。
+2. 編輯 `.env` 以提供以太坊主網節點的 URL。
+3. 執行 `pnpm install` 來安裝必要的套件。
+4. 執行 `pnpm susApproval` 來尋找可疑的授權。
+
+以下是逐行解釋:
+
+```typescript
+import {
+ Address,
+ TransactionReceipt,
+ createPublicClient,
+ http,
+ parseAbiItem,
+} from "viem"
+import { mainnet } from "viem/chains"
+```
+
+從 `viem` 導入型別定義、函數和鏈定義。
+
+```typescript
+import { config } from "dotenv"
+config()
+```
+
+讀取 `.env` 以取得 URL。
+
+```typescript
+const client = createPublicClient({
+ chain: mainnet,
+ transport: http(process.env.URL),
+})
+```
+
+建立一個 Viem 用戶端。 我們只需要從區塊鏈讀取資料,所以這個用戶端不需要私密金鑰。
+
+```typescript
+const testedAddress = "0xb047c8032b99841713b8e3872f06cf32beb27b82"
+const fromBlock = 16859812n
+const toBlock = 16873372n
+```
+
+可疑的 ERC-20 合約地址,以及我們將在其中尋找事件的區塊範圍。 節點提供商通常會限制我們讀取事件的能力,因為頻寬可能很昂貴。 幸運的是,`wARB` 在長達十八小時的時間內並未使用,所以我們可以尋找所有事件(總共只有 13 個)。
+
+```typescript
+const approvalEvents = await client.getLogs({
+ address: testedAddress,
+ fromBlock,
+ toBlock,
+ event: parseAbiItem(
+ "event Approval(address indexed _owner, address indexed _spender, uint256 _value)"
+ ),
+})
+```
+
+這是向 Viem 請求事件資訊的方式。 當我們提供確切的事件簽章,包括欄位名稱時,它會為我們解析事件。
+
+```typescript
+const isContract = async (addr: Address): boolean =>
+ await client.getBytecode({ address: addr })
+```
+
+我們的演算法只適用於外部擁有的帳戶。 如果 `client.getBytecode` 返回任何位元組碼,這意味著它是一個合約,我們應該直接跳過它。
+
+如果您以前沒用過 TypeScript,這個函數定義可能會看起來有點奇怪。 我們不只告訴它第一個(也是唯一一個)參數叫做 `addr`,還告訴它這個參數的型別是 `Address`。 同樣地,`: boolean` 部分告訴 TypeScript 這個函數的返回值是一個布林值。
+
+```typescript
+const getEventTxn = async (ev: Event): TransactionReceipt =>
+ await client.getTransactionReceipt({ hash: ev.transactionHash })
+```
+
+這個函數從事件中獲取交易收據。 我們需要收據來確保我們知道交易的目的地是什麼。
+
+```typescript
+const suspiciousApprovalEvent = async (ev : Event) : (Event | null) => {
+```
+
+這是最重要的函數,它實際決定了一個事件是否可疑。 返回類型 `(Event | null)` 告訴 TypeScript 這個函數可以返回 `Event` 或 `null`。 如果事件不可疑,我們返回 `null`。
+
+```typescript
+const owner = ev.args._owner
+```
+
+Viem 有欄位名稱,所以它為我們解析了事件。 `_owner` 是將被花費的代幣的所有者。
+
+```typescript
+// 合約的授權不可疑
+if (await isContract(owner)) return null
+```
+
+如果擁有者是合約,則假設此授權不可疑。 要檢查合約的授權是否可疑,我們需要追蹤交易的完整執行過程,以查看它是否曾到達擁有者合約,以及該合約是否直接調用了 ERC-20 合約。 這比我們想做的要耗費更多資源。
+
+```typescript
+const txn = await getEventTxn(ev)
+```
+
+如果授權來自外部擁有的帳戶,則獲取引起它的交易。
+
+```typescript
+// 如果授權來自一個非交易 `from` 欄位的 EOA 擁有者,則該授權是可疑的
+if (owner.toLowerCase() != txn.from.toLowerCase()) return ev
+```
+
+我們不能只檢查字串是否相等,因為地址是十六進位的,所以它們包含字母。 有時候,例如在 `txn.from` 中,這些字母都是小寫的。 在其他情況下,例如 `ev.args._owner`,地址是[混合大小寫以用於錯誤識別](https://eips.ethereum.org/EIPS/eip-55)。
+
+但如果交易不是來自擁有者,且該擁有者是外部擁有的,那麼我們就有了一筆可疑的交易。
+
+```typescript
+// 如果交易的目的地不是我們正在
+// 調查的 ERC-20 合約,那它也是可疑的
+if (txn.to.toLowerCase() != testedAddress) return ev
+```
+
+同樣地,如果交易的 `to` 地址,也就是第一個被調用的合約,不是正在調查的 ERC-20 合約,那麼它就是可疑的。
+
+```typescript
+ // 如果沒有可疑的理由,返回 null。
+ return null
+}
+```
+
+如果兩個條件都不成立,那麼 `Approval` 事件就不可疑。
+
+```typescript
+const testPromises = approvalEvents.map((ev) => suspiciousApprovalEvent(ev))
+const testResults = (await Promise.all(testPromises)).filter((x) => x != null)
+
+console.log(testResults)
+```
+
+[一個 `async` 函數](https://www.w3schools.com/js/js_async.asp) 會返回一個 `Promise` 物件。 使用常見的語法 `await x()`,我們等待該 `Promise` 完成後再繼續處理。 這在程式設計上很簡單且容易理解,但效率不高。 當我們等待特定事件的 `Promise` 完成時,我們已經可以開始處理下一個事件了。
+
+這裡我們使用 [`map`](https://www.w3schools.com/jsref/jsref_map.asp) 來建立一個 `Promise` 物件的陣列。 然後我們使用 [`Promise.all`](https://www.javascripttutorial.net/es6/javascript-promise-all/) 來等待所有這些 promise 完成。 然後我們 [`filter`](https://www.w3schools.com/jsref/jsref_filter.asp) 那些結果以移除不可疑的事件。
+
+### 可疑的 `Transfer` 事件 {#suspicious-transfer-events}
+
+識別詐騙代幣的另一種可能方法是查看它們是否有任何可疑的傳送。 例如,來自沒有那麼多代幣的帳戶的傳送。 您可以查看[如何實現此測試](https://github.com/qbzzt/20230915-scam-token-detection/blob/main/susTransfer.ts),但 `wARB` 沒有這個問題。
+
+## 結論 {#conclusion}
+
+ERC-20 詐騙的自動偵測會受到[偽陰性](https://en.wikipedia.org/wiki/False_positives_and_false_negatives#False_negative_error)的影響,因為詐騙可以使用一個完全正常的 ERC-20 代幣合約,而該合約只是不代表任何真實的東西。 所以你應該總是嘗試_從可信賴的來源獲取代幣地址_。
+
+自動偵測在某些情況下可以提供幫助,例如在 DeFi 領域,那裡有很多代幣需要自動處理。 但一如既往,[買者自負](https://www.investopedia.com/terms/c/caveatemptor.asp),請自行研究,並鼓勵您的使用者也這樣做。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md b/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
new file mode 100644
index 00000000000..6449579bd1c
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
@@ -0,0 +1,733 @@
+---
+title: 使用零知識證明建立秘密狀態
+description: 鏈上遊戲有所限制,因為它們無法保存任何隱藏資訊。 閱讀本教學課程後,讀者將能夠結合零知識證明和伺服器元件,建立具有秘密狀態、鏈下元件的可驗證遊戲。 我們將透過建立踩地雷遊戲來示範此技術。
+author: 作者:Ori Pomerantz
+tags: [ "伺服器", "鏈下", "中心化", "零知識", "zokrates", "mud" ]
+skill: advanced
+lang: zh-tw
+published: 2025-03-15
+---
+
+_在區塊鏈上沒有秘密_。 發佈在區塊鏈上的所有內容,每個人都可以公開讀取。 這是必要的,因為區塊鏈的基礎是任何人都能夠驗證它。 然而,遊戲通常仰賴秘密狀態。 例如,如果你能直接到區塊鏈瀏覽器上查看地圖,[踩地雷](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\))遊戲就完全沒有意義了。
+
+最簡單的解決方案是使用[伺服器元件](/developers/tutorials/server-components/)來保存秘密狀態。 然而,我們使用區塊鏈的原因是為了防止遊戲開發者作弊。 我們需要確保伺服器元件的誠實性。 伺服器可以提供狀態的哈希,並使用[零知識證明](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important)來證明用於計算移動結果的狀態是正確的。
+
+閱讀本文後,你將了解如何建立這類保存秘密狀態的伺服器、一個用於顯示狀態的用戶端,以及一個用於兩者之間通訊的鏈上元件。 我們將使用的主要工具有:
+
+| 工具 | 目的 | 已在版本上驗證 |
+| --------------------------------------------- | -------------- | --------------------------------------: |
+| [Zokrates](https://zokrates.github.io/) | 零知識證明及其驗證 | 1.1.9 |
+| [Typescript](https://www.typescriptlang.org/) | 伺服器和用戶端的程式設計語言 | 5.4.2 |
+| [Node](https://nodejs.org/en) | 執行伺服器 | 20.18.2 |
+| [Viem](https://viem.sh/) | 與區塊鏈通訊 | 2.9.20 |
+| [MUD](https://mud.dev/) | 鏈上資料管理 | 2.0.12 |
+| [React](https://react.dev/) | 用戶端使用者介面 | 18.2.0 |
+| [Vite](https://vitejs.dev/) | 提供用戶端程式碼 | 4.2.1 |
+
+## 踩地雷範例 {#minesweeper}
+
+[踩地雷](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) 是一款包含秘密地雷區地圖的遊戲。 玩家選擇在特定位置挖掘。 如果該位置有地雷,遊戲就結束了。 否則,玩家會得到該位置周圍八個方格中的地雷數量。
+
+此應用程式使用 [MUD](https://mud.dev/) 編寫,這是一個讓我們可以使用[鍵值資料庫](https://aws.amazon.com/nosql/key-value/)將資料儲存在鏈上,並自動將該資料與鏈下元件同步的框架。 除了同步之外,MUD 還能輕鬆提供存取控制,並讓其他使用者能[無需許可地擴充](https://mud.dev/guides/extending-a-world)我們的應用程式。
+
+### 執行踩地雷範例 {#running-minesweeper-example}
+
+若要執行踩地雷範例:
+
+1. 確保您已[安裝先決條件](https://mud.dev/quickstart#prerequisites):[Node](https://mud.dev/quickstart#prerequisites)、[Foundry](https://book.getfoundry.sh/getting-started/installation)、[`git`](https://git-scm.com/downloads)、[`pnpm`](https://git-scm.com/downloads) 和 [`mprocs`](https://github.com/pvolok/mprocs)。
+
+2. 複製儲存庫。
+
+ ```sh copy
+ git clone https://github.com/qbzzt/20240901-secret-state.git
+ ```
+
+3. 安裝套件。
+
+ ```sh copy
+ cd 20240901-secret-state/
+ pnpm install
+ npm install -g mprocs
+ ```
+
+ 如果 Foundry 是作為 `pnpm install` 的一部分安裝的,您需要重新啟動命令列 shell。
+
+4. 編譯合約
+
+ ```sh copy
+ cd packages/contracts
+ forge build
+ cd ../..
+ ```
+
+5. 啟動程式(包括 [anvil](https://book.getfoundry.sh/anvil/) 區塊鏈)並等待。
+
+ ```sh copy
+ mprocs
+ ```
+
+ 請注意,啟動需要很長時間。 若要查看進度,請先使用向下箭頭捲動至 _contracts_ 索引標籤,以查看正在部署的 MUD 合約。 當您收到訊息 _Waiting for file changes…_ 時,表示合約已部署,後續進度將在 _server_ 索引標籤中顯示。 在那裡,您要等到收到訊息 _Verifier address: 0x...._。
+
+ 如果此步驟成功,您會看到 `mprocs` 螢幕,左側是不同的程序,右側是目前所選程序的主控台輸出。
+
+ 
+
+ 如果 `mprocs` 出現問題,您可以手動執行這四個程序,每個程序都在各自的命令列視窗中執行:
+
+ - **Anvil**
+
+ ```sh
+ cd packages/contracts
+ anvil --base-fee 0 --block-time 2
+ ```
+
+ - **合約**
+
+ ```sh
+ cd packages/contracts
+ pnpm mud dev-contracts --rpc http://127.0.0.1:8545
+ ```
+
+ - **伺服器**
+
+ ```sh
+ cd packages/server
+ pnpm start
+ ```
+
+ - **用戶端**
+
+ ```sh
+ cd packages/client
+ pnpm run dev
+ ```
+
+6. 現在您可以瀏覽至[用戶端](http://localhost:3000),點擊 **New Game**,然後開始遊戲。
+
+### 資料表 {#tables}
+
+我們需要在鏈上建立[數個資料表](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts)。
+
+- `Configuration`:此資料表是單例,它沒有鍵且只有單一記錄。 它用於保存遊戲設定資訊:
+ - `height`:地雷區的高度
+ - `width`:地雷區的寬度
+ - `numberOfBombs`:每個地雷區中的炸彈數量
+
+- `VerifierAddress`:此資料表也是單例。 它用於保存設定的一部分,即驗證者合約 (`verifier`) 的地址。 我們可以將此資訊放在 `Configuration` 資料表中,但它是由另一個元件(伺服器)設定的,因此將其放在單獨的資料表中更容易。
+
+- `PlayerGame`:鍵是玩家的地址。 資料是:
+
+ - `gameId`:一個 32 位元組的值,是玩家正在遊玩的地圖的哈希(遊戲識別碼)。
+ - `win`:一個布林值,表示玩家是否贏得了遊戲。
+ - `lose`:一個布林值,表示玩家是否輸掉了遊戲。
+ - `digNumber`:遊戲中成功挖掘的次數。
+
+- `GamePlayer`:此資料表保存從 `gameId` 到玩家地址的反向對應。
+
+- `Map`:鍵是由三個值組成的元組:
+
+ - `gameId`:一個 32 位元組的值,是玩家正在遊玩的地圖的哈希(遊戲識別碼)。
+ - `x` 座標
+ - `y` 座標
+
+ 值是一個單一數字。 如果偵測到炸彈,則為 255。 否則,它是該位置周圍炸彈數量加一。 我們不能只使用炸彈的數量,因為在 EVM 中所有儲存空間和 MUD 中所有行值預設為零。 我們需要區分「玩家還沒有在這裡挖掘」和「玩家在這裡挖掘了,但發現周圍沒有炸彈」。
+
+此外,用戶端和伺服器之間的通訊是透過鏈上元件進行的。 這也是使用資料表實作的。
+
+- `PendingGame`:未處理的新遊戲開始請求。
+- `PendingDig`:在特定遊戲的特定位置挖掘的未處理請求。 這是一個[鏈下資料表](https://mud.dev/store/tables#types-of-tables),表示它不會寫入 EVM 儲存空間,只能透過事件在鏈下讀取。
+
+### 執行與資料流 {#execution-data-flows}
+
+這些流程協調用戶端、鏈上元件和伺服器之間的執行。
+
+#### 初始化 {#initialization-flow}
+
+當您執行 `mprocs` 時,會發生以下步驟:
+
+1. [`mprocs`](https://github.com/pvolok/mprocs) 會執行四個元件:
+
+ - [Anvil](https://book.getfoundry.sh/anvil/),執行本機區塊鏈
+ - [合約](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/contracts),編譯(如果需要)並部署 MUD 的合約
+ - [用戶端](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/client),執行 [Vite](https://vitejs.dev/) 以向 Web 瀏覽器提供 UI 和用戶端程式碼。
+ - [伺服器](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/server),執行伺服器動作
+
+2. `contracts` 套件會部署 MUD 合約,然後執行 [`PostDeploy.s.sol` 指令碼](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol)。 此指令碼會設定組態。 來自 github 的程式碼指定了[一個 10x5 的地雷區,其中有八個地雷](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol#L23)。
+
+3. [伺服器](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts) 首先[設定 MUD](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L6)。 除其他事項外,這會啟動資料同步,因此相關資料表的副本會存在於伺服器的記憶體中。
+
+4. 伺服器訂閱一個函式,以便[在 `Configuration` 資料表變更時](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L23)執行。 `PostDeploy.s.sol` 執行並修改資料表後,會呼叫[此函式](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L24-L168)。
+
+5. 當伺服器初始化函式取得設定後,[它會呼叫 `zkFunctions`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L34-L35) 來初始化[伺服器的零知識部分](#using-zokrates-from-typescript)。 在我們取得設定之前,這無法發生,因為零知識函式必須將地雷區的寬度和高度作為常數。
+
+6. 伺服器的零知識部分初始化後,下一步是[將零知識驗證合約部署到區塊鏈](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L42-L53)並在 MUD 中設定驗證對象地址。
+
+7. 最後,我們訂閱更新,這樣我們就可以看到玩家何時請求[開始新遊戲](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71)或[在現有遊戲中挖掘](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73-L108)。
+
+#### 新遊戲 {#new-game-flow}
+
+這是玩家請求新遊戲時發生的情況。
+
+1. 如果此玩家沒有正在進行的遊戲,或者有遊戲但 gameId 為零,用戶端會顯示[新遊戲按鈕](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175)。 當使用者按下此按鈕時,[React 會執行 `newGame` 函式](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L96)。
+
+2. [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L43-L46) 是一個 `System` 呼叫。 在 MUD 中,所有呼叫都透過 `World` 合約路由,在大多數情況下,您會呼叫 `__`。 在這種情況下,呼叫的是 `app__newGame`,然後 MUD 會將其路由到 [`GameSystem` 中的 `newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L16-L22)。
+
+3. 鏈上函式會檢查玩家是否沒有正在進行的遊戲,如果沒有,則[將請求新增至 `PendingGame` 資料表](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L21)。
+
+4. 伺服器偵測到 `PendingGame` 中的變更,並[執行訂閱的函式](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71)。 此函式會呼叫 [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L110-L114),而後者又會呼叫 [`createGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L116-L144)。
+
+5. `createGame` 做的第一件事是[建立一個具有適當數量地雷的隨機地圖](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L120-L135)。 然後,它會呼叫 [`makeMapBorders`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L147-L166) 來建立一個帶有空白邊界的地圖,這對於 Zokrates 是必要的。 最後,`createGame` 會呼叫 [`calculateMapHash`](#calculateMapHash) 來取得地圖的哈希,該哈希用作遊戲 ID。
+
+6. `newGame` 函式將新遊戲新增至 `gamesInProgress`。
+
+7. 伺服器做的最後一件事是呼叫 [`app__newGameResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L38-L43),這是在鏈上進行的。 此函式位於另一個 `System` 中,即 [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol),以啟用存取控制。 存取控制在 [MUD 設定檔](https://mud.dev/config) [`mud.config.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts#L67-L72) 中定義。
+
+ 存取清單只允許單一地址呼叫 `System`。 這將對伺服器函式的存取限制為單一地址,因此沒有人可以冒充伺服器。
+
+8. 鏈上元件會更新相關資料表:
+
+ - 在 `PlayerGame` 中建立遊戲。
+ - 在 `GamePlayer` 中設定反向對應。
+ - 從 `PendingGame` 中移除請求。
+
+9. 伺服器識別到 `PendingGame` 的變更,但不會執行任何操作,因為 [`wantsGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L58-L60) 為 false。
+
+10. 在用戶端,[`gameRecord`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L143-L148) 被設定為玩家地址的 `PlayerGame` 項目。 當 `PlayerGame` 變更時,`gameRecord` 也會變更。
+
+11. 如果 `gameRecord` 中有值,且遊戲尚未分出勝負,用戶端會[顯示地圖](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190)。
+
+#### 挖掘 {#dig-flow}
+
+1. 玩家[點擊地圖儲存格的按鈕](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L188),這會呼叫 [`dig` 函式](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L33-L36)。 此函式會[在鏈上呼叫 `dig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L24-L32)。
+
+2. 鏈上元件會[執行一些健全性檢查](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L25-L30),如果成功,則將挖掘請求新增至 [`PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L31)。
+
+3. 伺服器[偵測到 `PendingDig` 的變更](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73)。 [如果有效](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L75-L84),它會[呼叫零知識程式碼](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L86-L95)(如下所述)以產生結果和其有效的證明。
+
+4. [伺服器](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L97-L107) 在鏈上呼叫 [`digResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L45-L64)。
+
+5. `digResponse` 做兩件事。 首先,它會檢查[零知識證明](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L47-L61)。 然後,如果證明通過檢查,它會呼叫 [`processDigResult`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L67-L86) 來實際處理結果。
+
+6. `processDigResult` 檢查遊戲是否已[失敗](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L76-L78)或[獲勝](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L83-L86),並[更新鏈上地圖 `Map`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L80)。
+
+7. 用戶端會自動擷取更新並[更新顯示給玩家的地圖](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190),並在適用的情況下告知玩家是獲勝還是失敗。
+
+## 使用 Zokrates {#using-zokrates}
+
+在上述流程中,我們跳過了零知識部分,將其視為一個黑盒子。 現在讓我們打開它,看看程式碼是如何編寫的。
+
+### 對地圖進行哈希 {#hashing-map}
+
+我們可以使用[此 JavaScript 程式碼](https://github.com/ZK-Plus/ICBC24_Tutorial_Compute-Offchain-Verify-onchain/tree/solutions/exercise)來實作 [Poseidon](https://www.poseidon-hash.info),這是我們使用的 Zokrates 哈希函式。 然而,雖然這樣做會更快,但它也比僅使用 Zokrates 哈希函式來做更複雜。 這是一個教學課程,因此程式碼是為簡單性而非效能而優化的。 因此,我們需要兩個不同的 Zokrates 程式,一個只計算地圖的哈希(`hash`),另一個則實際建立在地圖上某個位置挖掘結果的零知識證明(`dig`)。
+
+### 哈希函式 {#hash-function}
+
+這是計算地圖哈希的函式。 我們將逐行檢視此程式碼。
+
+```
+import "hashes/poseidon/poseidon.zok" as poseidon;
+import "utils/pack/bool/pack128.zok" as pack128;
+```
+
+這兩行從 [Zokrates 標準程式庫](https://zokrates.github.io/toolbox/stdlib.html)匯入兩個函式。 [第一個函式](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/hashes/poseidon/poseidon.zok) 是 [Poseidon 哈希](https://www.poseidon-hash.info/). 它接受一個 [`field` 元素](https://zokrates.github.io/language/types.html#field)的陣列,並傳回一個 `field`。
+
+Zokrates 中的欄位元素通常長度小於 256 位元,但不會少太多。 為了簡化程式碼,我們將地圖限制為最多 512 位元,並對四個欄位的陣列進行哈希處理,每個欄位只使用 128 位元。 為此,[`pack128` 函式](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/utils/pack/bool/pack128.zok) 會將 128 位元的陣列轉換成 `field`。
+
+```
+ def hashMap(bool[${width+2}][${height+2}] map) -> field {
+```
+
+此行開始函式定義。 `hashMap` 取得一個名為 `map` 的單一參數,它是一個二維 `bool`(ean) 陣列。 地圖的大小是 `width+2` 乘以 `height+2`,原因[如下所述](#why-map-border)。
+
+我們可以使用 `${width+2}` 和 `${height+2}`,因為 Zokrates 程式在此應用程式中以[範本字串](https://www.w3schools.com/js/js_string_templates.asp)的形式儲存。 `${` 和 `}` 之間的程式碼由 JavaScript 評估,這樣程式就可以用於不同大小的地圖。 地圖參數周圍有一個寬度為一個位置的邊界,其中沒有任何炸彈,這就是我們需要將寬度和高度加二的原因。
+
+傳回值是包含哈希的 `field`。
+
+```
+ bool[512] mut map1d = [false; 512];
+```
+
+地圖是二維的。 然而,`pack128` 函式不適用於二維陣列。 所以我們先使用 `map1d` 將地圖扁平化為一個 512 位元組的陣列。 預設情況下,Zokrates 變數是常數,但我們需要在迴圈中為此陣列賦值,因此我們將其定義為 [`mut`](https://zokrates.github.io/language/variables.html#mutability)。
+
+我們需要初始化陣列,因為 Zokrates 沒有 `undefined`。 `[false; 512]` 運算式表示[一個包含 512 個 `false` 值的陣列](https://zokrates.github.io/language/types.html#declaration-and-initialization)。
+
+```
+ u32 mut counter = 0;
+```
+
+我們還需要一個計數器來區分我們已在 `map1d` 中填入的位元和尚未填入的位元。
+
+```
+ for u32 x in 0..${width+2} {
+```
+
+這是在 Zokrates 中宣告 [`for` 迴圈](https://zokrates.github.io/language/control_flow.html#for-loops)的方式。 Zokrates `for` 迴圈必須有固定的邊界,因為雖然它看起來像一個迴圈,但編譯器實際上會「展開」它。 運算式 `${width+2}` 是一個編譯時常數,因為 `width` 是由 TypeScript 程式碼在呼叫編譯器之前設定的。
+
+```
+ for u32 y in 0..${height+2} {
+ map1d[counter] = map[x][y];
+ counter = counter+1;
+ }
+ }
+```
+
+對於地圖中的每個位置,將該值放入 `map1d` 陣列並遞增計數器。
+
+```
+ field[4] hashMe = [
+ pack128(map1d[0..128]),
+ pack128(map1d[128..256]),
+ pack128(map1d[256..384]),
+ pack128(map1d[384..512])
+ ];
+```
+
+`pack128` 從 `map1d` 建立一個包含四個 `field` 值的陣列。 在 Zokrates 中,`array[a..b]` 表示從 `a` 開始到 `b-1` 結束的陣列切片。
+
+```
+ return poseidon(hashMe);
+}
+```
+
+使用 `poseidon` 將此陣列轉換為哈希。
+
+### 哈希程式 {#hash-program}
+
+伺服器需要直接呼叫 `hashMap` 來建立遊戲識別碼。 然而,Zokrates 只能呼叫程式上的 `main` 函式來啟動,所以我們建立一個帶有呼叫哈希函式的 `main` 函式的程式。
+
+```
+${hashFragment}
+
+def main(bool[${width+2}][${height+2}] map) -> field {
+ return hashMap(map);
+}
+```
+
+### 挖掘程式 {#dig-program}
+
+這是應用程式零知識部分的核心,我們在這裡產生用於驗證挖掘結果的證明。
+
+```
+${hashFragment}
+
+// The number of mines in location (x,y)
+def map2mineCount(bool[${width+2}][${height+2}] map, u32 x, u32 y) -> u8 {
+ return if map[x+1][y+1] { 1 } else { 0 };
+}
+```
+
+#### 為什麼需要地圖邊界 {#why-map-border}
+
+零知識證明使用[算術電路](https://medium.com/web3studio/simple-explanations-of-arithmetic-circuits-and-zero-knowledge-proofs-806e59a79785),它沒有與 `if` 陳述式等效的簡單方法。 取而代之的是,他們使用等效於[條件運算子](https://en.wikipedia.org/wiki/Ternary_conditional_operator)的方法。 如果 `a` 可以是零或一,您可以將 `if a { b } else { c }` 計算為 `ab+(1-a)c`。
+
+因此,Zokrates `if` 陳述式總是會評估兩個分支。 例如,如果您有這段程式碼:
+
+```
+bool[5] arr = [false; 5];
+u32 index=10;
+return if index>4 { 0 } else { arr[index] }
+```
+
+它會出錯,因為它需要計算 `arr[10]`,即使該值稍後會乘以零。
+
+這就是我們需要在地圖周圍留一個位置寬邊界的原因。 我們需要計算一個位置周圍的地雷總數,這表示我們需要查看我們挖掘位置的上一行和下一行、左側和右側的位置。 這意味著這些位置必須存在於提供給 Zokrates 的地圖陣列中。
+
+```
+def main(private bool[${width+2}][${height+2}] map, u32 x, u32 y) -> (field, u8) {
+```
+
+預設情況下,Zokrates 證明包含其輸入。 除非您實際知道是哪個點,否則知道某個點周圍有五個地雷是沒有用的(而且您不能只將它與您的請求匹配,因為那樣證明者就可以使用不同的值而不告訴您)。 然而,我們需要將地圖保密,同時將其提供給 Zokrates。 解決方案是使用一個 `private` 參數,一個_不_會被證明揭示的參數。
+
+這開啟了另一個濫用的途徑。 證明者可以使用正確的座標,但建立一個在地點周圍有任意數量地雷的地圖,甚至可能在地點本身就有地雷。 為防止這種濫用,我們讓零知識證明包含地圖的哈希,也就是遊戲識別碼。
+
+```
+ return (hashMap(map),
+```
+
+此處的傳回值是一個元組,其中包含地圖哈希陣列以及挖掘結果。
+
+```
+ if map2mineCount(map, x, y) > 0 { 0xFF } else {
+```
+
+如果位置本身有炸彈,我們使用 255 作為特殊值。
+
+```
+ map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) +
+ map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) +
+ map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1)
+ }
+ );
+}
+```
+
+如果玩家沒有踩到地雷,則將該位置周圍區域的地雷數量相加並傳回。
+
+### 從 TypeScript 使用 Zokrates {#using-zokrates-from-typescript}
+
+Zokrates 有一個命令列介面,但在這個程式中,我們在 [TypeScript 程式碼](https://zokrates.github.io/toolbox/zokrates_js.html)中使用它。
+
+包含 Zokrates 定義的程式庫稱為 [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts)。
+
+```typescript
+import { initialize as zokratesInitialize } from "zokrates-js"
+```
+
+匯入 [Zokrates JavaScript 繫結](https://zokrates.github.io/toolbox/zokrates_js.html)。 我們只需要 [`initialize`](https://zokrates.github.io/toolbox/zokrates_js.html#initialize) 函式,因為它會傳回一個解析為所有 Zokrates 定義的 promise。
+
+```typescript
+export const zkFunctions = async (width: number, height: number) : Promise => {
+```
+
+與 Zokrates 本身相似,我們也只匯出一個函式,這個函式也是[非同步的](https://www.w3schools.com/js/js_async.asp)。 當它最終傳回時,它會提供幾個函式,如下所示。
+
+```typescript
+const zokrates = await zokratesInitialize()
+```
+
+初始化 Zokrates,從程式庫中取得我們需要的一切。
+
+```typescript
+const hashFragment = `
+ import "utils/pack/bool/pack128.zok" as pack128;
+ import "hashes/poseidon/poseidon.zok" as poseidon;
+ .
+ .
+ .
+ }
+ `
+
+const hashProgram = `
+ ${hashFragment}
+ .
+ .
+ .
+ `
+
+const digProgram = `
+ ${hashFragment}
+ .
+ .
+ .
+ `
+```
+
+接下來是我們上面看到的哈希函式和兩個 Zokrates 程式。
+
+```typescript
+const digCompiled = zokrates.compile(digProgram)
+const hashCompiled = zokrates.compile(hashProgram)
+```
+
+我們在這裡編譯這些程式。
+
+```typescript
+// Create the keys for zero knowledge verification.
+// On a production system you'd want to use a setup ceremony.
+// (https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony).
+const keySetupResults = zokrates.setup(digCompiled.program, "")
+const verifierKey = keySetupResults.vk
+const proverKey = keySetupResults.pk
+```
+
+在生產系統上,我們可能會使用更複雜的[設定儀式](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony),但對於示範來說,這已經足夠了。 使用者知道證明者金鑰不是問題——他們仍然無法用它來證明事情,除非事情是真的。 因為我們指定了熵(第二個參數 `""`),所以結果總會是相同的。
+
+**注意:** Zokrates 程式的編譯和金鑰的建立是緩慢的過程。 不需要每次都重複它們,只有當地圖大小改變時才需要。 在生產系統上,您只會做一次,然後儲存輸出。 我不在這裡這樣做的唯一原因是為了簡單起見。
+
+#### `calculateMapHash` {#calculateMapHash}
+
+```typescript
+const calculateMapHash = function (hashMe: boolean[][]): string {
+ return (
+ "0x" +
+ BigInt(zokrates.computeWitness(hashCompiled, [hashMe]).output.slice(1, -1))
+ .toString(16)
+ .padStart(64, "0")
+ )
+}
+```
+
+[`computeWitness`](https://zokrates.github.io/toolbox/zokrates_js.html#computewitnessartifacts-args-options) 函式實際上會執行 Zokrates 程式。 它會傳回一個包含兩個欄位的結構:`output`,即程式的輸出,為 JSON 字串;以及 `witness`,即建立結果的零知識證明所需的資訊。 這裡我們只需要輸出。
+
+輸出是一個形式為 `"31337"` 的字串,一個用引號括起來的十進位數字。 但我們需要 `viem` 的輸出是一個形式為 `0x60A7` 的十六進位數字。 所以我們使用 `.slice(1,-1)` 來移除引號,然後使用 `BigInt` 將剩餘的字串(一個十進位數字)轉換為 [`BigInt`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt)。 `.toString(16)` 將此 `BigInt` 轉換為十六進位字串,而 `"0x"+` 則添加了十六進位數字的標記。
+
+```typescript
+// Dig and return a zero knowledge proof of the result
+// (server-side code)
+```
+
+零知識證明包括公共輸入(`x` 和 `y`)和結果(地圖的哈希和炸彈的數量)。
+
+```typescript
+ const zkDig = function(map: boolean[][], x: number, y: number) : any {
+ if (x<0 || x>=width || y<0 || y>=height)
+ throw new Error("Trying to dig outside the map")
+```
+
+在 Zokrates 中檢查索引是否越界是一個問題,所以我們在這裡進行檢查。
+
+```typescript
+const runResults = zokrates.computeWitness(digCompiled, [map, `${x}`, `${y}`])
+```
+
+執行挖掘程式。
+
+```typescript
+ const proof = zokrates.generateProof(
+ digCompiled.program,
+ runResults.witness,
+ proverKey)
+
+ return proof
+ }
+```
+
+使用 [`generateProof`](https://zokrates.github.io/toolbox/zokrates_js.html#generateproofprogram-witness-provingkey-entropy) 並傳回證明。
+
+```typescript
+const solidityVerifier = `
+ // Map size: ${width} x ${height}
+ \n${zokrates.exportSolidityVerifier(verifierKey)}
+ `
+```
+
+一個 Solidity 驗證器,這是一個我們可以部署到區塊鏈並用來驗證由 `digCompiled.program` 產生的證明的智能合約。
+
+```typescript
+ return {
+ zkDig,
+ calculateMapHash,
+ solidityVerifier,
+ }
+}
+```
+
+最後,傳回其他程式碼可能需要的一切。
+
+## 安全性測試 {#security-tests}
+
+安全性測試很重要,因為功能錯誤最終會顯現出來。 但如果應用程式不安全,這很可能會隱藏很長一段時間,直到有人作弊並竊取屬於他人的資源時才會被揭露。
+
+### 權限 {#permissions}
+
+在這個遊戲中,有一個特權實體,那就是伺服器。 它是唯一允許呼叫 [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol) 中函式的使用者。 我們可以使用 [`cast`](https://book.getfoundry.sh/cast/) 來驗證對權限函式的呼叫僅能以伺服器帳戶進行。
+
+[伺服器的私密金鑰在 `setupNetwork.ts` 中](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/mud/setupNetwork.ts#L52)。
+
+1. 在執行 `anvil`(區塊鏈)的電腦上,設定這些環境變數。
+
+ ```sh copy
+ WORLD_ADDRESS=0x8d8b6b8414e1e3dcfd4168561b9be6bd3bf6ec4b
+ UNAUTHORIZED_KEY=0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a
+ AUTHORIZED_KEY=0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
+ ```
+
+2. 使用 `cast` 嘗試將驗證器地址設定為未經授權的地址。
+
+ ```sh copy
+ cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $UNAUTHORIZED_KEY
+ ```
+
+ `cast` 不僅會報告失敗,您還可以在瀏覽器中的遊戲中開啟 **MUD 開發工具**,點擊**資料表**,然後選擇 **app\_\_VerifierAddress**。 查看地址是否不為零。
+
+3. 將驗證器地址設定為伺服器的地址。
+
+ ```sh copy
+ cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $AUTHORIZED_KEY
+ ```
+
+ **app\_\_VerifiedAddress** 中的地址現在應為零。
+
+所有在同一個 `System` 中的 MUD 函式都經過相同的存取控制,所以我認為這個測試是足夠的。 如果您不這麼認為,您可以檢查 [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol) 中的其他函式。
+
+### 零知識濫用 {#zero-knowledge-abuses}
+
+驗證 Zokrates 的數學超出了本教學課程的範圍(以及我的能力)。 然而,我們可以對零知識程式碼執行各種檢查,以驗證如果它沒有正確完成就會失敗。 所有這些測試都要求我們更改 [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts) 並重新啟動整個應用程式。 僅重新啟動伺服器程序是不夠的,因為它會使應用程式處於不可能的狀態(玩家正在進行遊戲,但遊戲不再對伺服器可用)。
+
+#### 錯誤答案 {#wrong-answer}
+
+最簡單的可能性是在零知識證明中提供錯誤的答案。 為此,我們進入 `zkDig` 並[修改第 91 行](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L91):
+
+```ts
+proof.inputs[3] = "0x" + "1".padStart(64, "0")
+```
+
+這表示無論正確答案為何,我們都將始終聲稱有一個炸彈。 嘗試用這個版本玩遊戲,您會在 `pnpm dev` 畫面的 **server** 標籤中看到此錯誤:
+
+```
+ cause: {
+ code: 3,
+ message: 'execution reverted: revert: Zero knowledge verification fail',
+ data: '0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000
+000000000000000000000000000000000000000000000000205a65726f206b6e6f776c6564676520766572696669636174696f6
+e206661696c'
+ },
+```
+
+所以這種作弊方式會失敗。
+
+#### 錯誤的證明 {#wrong-proof}
+
+如果我們提供正確的資訊,但證明資料錯誤會發生什麼? 現在,將第 91 行替換為:
+
+```ts
+proof.proof = {
+ a: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ b: [
+ ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ ],
+ c: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+}
+```
+
+它仍然失敗,但現在它在沒有原因的情況下失敗,因為它發生在驗證器呼叫期間。
+
+### 使用者如何驗證零信任程式碼? {#user-verify-zero-trust}
+
+智能合約相對容易驗證。 通常,開發者會將原始碼發佈到區塊瀏覽器,而區塊瀏覽器會驗證原始碼是否確實編譯為[合約部署交易](/developers/docs/smart-contracts/deploying/)中的程式碼。 在 MUD `System`s 的情況下,這[稍微複雜一些](https://mud.dev/cli/verify),但不會複雜太多。
+
+這對零知識來說更難。 驗證器包含一些常數,並對它們執行一些計算。 這不會告訴您正在證明什麼。
+
+```solidity
+ function verifyingKey() pure internal returns (VerifyingKey memory vk) {
+ vk.alpha = Pairing.G1Point(uint256(0x0f43f4fe7b5c2326fed4ac6ed2f4003ab9ab4ea6f667c2bdd77afb068617ee16), uint256(0x25a77832283f9726935219b5f4678842cda465631e72dbb24708a97ba5d0ce6f));
+ vk.beta = Pairing.G2Point([uint256(0x2cebd0fbd21aca01910581537b21ae4fed46bc0e524c055059aa164ba0a6b62b), uint256(0x18fd4a7bc386cf03a95af7163d5359165acc4e7961cb46519e6d9ee4a1e2b7e9)], [uint256(0x11449dee0199ef6d8eebfe43b548e875c69e7ce37705ee9a00c81fe52f11a009), uint256(0x066d0c83b32800d3f335bb9e8ed5e2924cf00e77e6ec28178592eac9898e1a00)]);
+```
+
+解決方案是,至少在區塊瀏覽器將 Zokrates 驗證新增到其使用者介面之前,應用程式開發者應提供 Zokrates 程式,並讓至少一些使用者使用適當的驗證金鑰自行編譯它們。
+
+若要如此做:
+
+1. [安裝 Zokrates](https://zokrates.github.io/gettingstarted.html)。
+
+2. 建立一個名為 `dig.zok` 的檔案,其中包含 Zokrates 程式。 以下程式碼假設您保留了原始地圖大小 10x5。
+
+ ```zokrates
+ import "utils/pack/bool/pack128.zok" as pack128;
+ import "hashes/poseidon/poseidon.zok" as poseidon;
+
+ def hashMap(bool[12][7] map) -> field {
+ bool[512] mut map1d = [false; 512];
+ u32 mut counter = 0;
+
+ for u32 x in 0..12 {
+ for u32 y in 0..7 {
+ map1d[counter] = map[x][y];
+ counter = counter+1;
+ }
+ }
+
+ field[4] hashMe = [
+ pack128(map1d[0..128]),
+ pack128(map1d[128..256]),
+ pack128(map1d[256..384]),
+ pack128(map1d[384..512])
+ ];
+
+ return poseidon(hashMe);
+ }
+
+
+ // The number of mines in location (x,y)
+ def map2mineCount(bool[12][7] map, u32 x, u32 y) -> u8 {
+ return if map[x+1][y+1] { 1 } else { 0 };
+ }
+
+ def main(private bool[12][7] map, u32 x, u32 y) -> (field, u8) {
+ return (hashMap(map) ,
+ if map2mineCount(map, x, y) > 0 { 0xFF } else {
+ map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) +
+ map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) +
+ map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1)
+ }
+ );
+ }
+ ```
+
+3. 編譯 Zokrates 程式碼並建立驗證金鑰。 驗證金鑰必須使用原始伺服器中使用的相同熵來建立,[在這種情況下是一個空字串](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L67)。
+
+ ```sh copy
+ zokrates compile --input dig.zok
+ zokrates setup -e ""
+ ```
+
+4. 自行建立 Solidity 驗證器,並驗證其功能上與區塊鏈上的驗證器相同(伺服器會新增註解,但這不重要)。
+
+ ```sh copy
+ zokrates export-verifier
+ diff verifier.sol ~/20240901-secret-state/packages/contracts/src/verifier.sol
+ ```
+
+## 設計決策 {#design}
+
+在任何足夠複雜的應用程式中,都有相互競爭的設計目標,需要權衡取捨。 讓我們看看一些權衡以及為什麼當前的解決方案優於其他選項。
+
+### 為什麼是零知識 {#why-zero-knowledge}
+
+對於踩地雷遊戲,您並不需要真正的零知識。 伺服器可以一直持有地圖,然後在遊戲結束時揭示所有內容。 然後,在遊戲結束時,智能合約可以計算地圖哈希,驗證其是否匹配,如果不匹配則懲罰伺服器或完全忽略遊戲。
+
+我沒有使用這個更簡單的解決方案,因為它只適用於具有明確結束狀態的短遊戲。 當遊戲可能無限進行時(例如[自主世界](https://0xparc.org/blog/autonomous-worlds)的情況),您需要一個可以在_不_揭示狀態的情況下證明狀態的解決方案。
+
+作為教學課程,本文需要一個簡短且易於理解的遊戲,但此技術對於較長的遊戲最有用。
+
+### 為什麼是 Zokrates? {#why-zokrates}
+
+[Zokrates](https://zokrates.github.io/) 並不是唯一可用的零知識程式庫,但它與正常的、[命令式](https://en.wikipedia.org/wiki/Imperative_programming)程式設計語言相似,並支援布林變數。
+
+對於您的應用程式,由於有不同的需求,您可能更喜歡使用 [Circum](https://docs.circom.io/getting-started/installation/) 或 [Cairo](https://www.cairo-lang.org/tutorials/getting-started-with-cairo/)。
+
+### 何時編譯 Zokrates {#when-compile-zokrates}
+
+在這個程式中,我們在[每次伺服器啟動時](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L60-L61)編譯 Zokrates 程式。 這顯然是浪費資源,但這是一個教學課程,以簡單為優化目標。
+
+如果我正在編寫一個生產級的應用程式,我會檢查我是否擁有此地雷區大小的已編譯 Zokrates 程式檔案,如果是,就使用它。 在鏈上部署驗證器合約也是如此。
+
+### 建立驗證器和證明者金鑰 {#key-creation}
+
+[金鑰建立](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L63-L69)是另一個純粹的計算,對於給定的地雷區大小,不需要執行多次。 同樣,為了簡單起見,它只執行一次。
+
+此外,我們可以使用[設定儀式](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony)。 設定儀式的優點是,您需要每個參與者的熵或一些中間結果才能在零知識證明上作弊。 如果至少有一個儀式參與者是誠實的並刪除了該資訊,那麼零知識證明就可以免受某些攻擊。 然而,_沒有機制_可以驗證資訊是否已從所有地方刪除。 如果零知識證明至關重要,您會希望參與設定儀式。
+
+在這裡,我們依賴 [perpetual powers of tau](https://github.com/privacy-scaling-explorations/perpetualpowersoftau),它有數十名參與者。 這可能足夠安全,而且簡單得多。 我們在金鑰建立過程中也不添加熵,這使得使用者更容易[驗證零知識設定](#user-verify-zero-trust)。
+
+### 在哪裡驗證 {#where-verification}
+
+我們可以在鏈上(這會消耗 gas)或在用戶端(使用 [`verify`](https://zokrates.github.io/toolbox/zokrates_js.html#verifyverificationkey-proof))驗證零知識證明。 我選擇了前者,因為這可以讓您[驗證驗證器](#user-verify-zero-trust)一次,然後相信只要其合約地址保持不變,它就不會改變。 如果驗證是在用戶端上完成的,那麼您每次下載用戶端時都必須驗證您收到的程式碼。
+
+此外,雖然這個遊戲是單人遊戲,但很多區塊鏈遊戲都是多人遊戲。 鏈上驗證意味著您只需驗證零知識證明一次。 在用戶端進行驗證將需要每個用戶端獨立驗證。
+
+### 在 TypeScript 或 Zokrates 中扁平化地圖? {#where-flatten}
+
+一般來說,當處理可以在 TypeScript 或 Zokrates 中完成時,最好在 TypeScript 中進行,因為它快得多,且不需要零知識證明。 這就是為什麼,例如,我們不向 Zokrates 提供哈希並讓它驗證其是否正確的原因。 哈希必須在 Zokrates 內部完成,但傳回的哈希與鏈上的哈希之間的匹配可以在其外部進行。
+
+然而,我們仍然[在 Zokrates 中扁平化地圖](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L15-L20),而我們本可以在 TypeScript 中完成。 原因是我認為其他選項更糟。
+
+- 向 Zokrates 程式碼提供一個布林值的一維陣列,並使用 `x*(height+2)
+ +y` 之類的運算式來取得二維地圖。 這會讓[程式碼](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L44-L47)變得更複雜一些,所以我決定對於教學課程來說,效能的提升不值得這樣做。
+
+- 向 Zokrates 傳送一維陣列和二維陣列。 然而,這個解決方案對我們沒有任何好處。 Zokrates 程式碼必須驗證它所提供的一維陣列是否真的是二維陣列的正確表示。 所以不會有任何效能提升。
+
+- 在 Zokrates 中扁平化二維陣列。 這是最簡單的選項,所以我選擇了它。
+
+### 地圖儲存在哪裡 {#where-store-maps}
+
+在這個應用程式中,[`gamesInProgress`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L20) 只是記憶體中的一個變數。 這意味著如果您的伺服器死機並需要重新啟動,它儲存的所有資訊都會遺失。 玩家不僅無法繼續他們的遊戲,他們甚至無法開始新遊戲,因為鏈上元件認為他們仍在進行遊戲。
+
+對於生產系統來說,這顯然是不好的設計,在生產系統中,您會將此資訊儲存在資料庫中。 我之所以在這裡使用變數,唯一的原因是這是一個教學課程,簡單性是主要考量。
+
+## 結論:在什麼條件下這是一種適當的技術? {#conclusion}
+
+所以,現在您知道如何編寫一個帶有伺服器的遊戲,該伺服器儲存不屬於鏈上的秘密狀態。 但您應該在什麼情況下這樣做呢? 有兩個主要考量。
+
+- _長期運行的遊戲_:[如上所述](#why-zero-knowledge),在一個短遊戲中,您可以在遊戲結束後發佈狀態,然後進行驗證。 但當遊戲需要很長或不確定的時間,並且狀態需要保密時,這就不是一個選項。
+
+- _可接受某些中心化_:零知識證明可以驗證完整性,即實體沒有偽造結果。 它們無法做的是確保實體仍然可用並回答訊息。 在可用性也需要去中心化的情況下,零知識證明並不是一個足夠的解決方案,您需要[多方計算](https://en.wikipedia.org/wiki/Secure_multi-party_computation)。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
+
+### 致謝 {#acknowledgements}
+
+- Alvaro Alonso 閱讀了本文的草稿,並澄清了我對 Zokrates 的一些誤解。
+
+任何剩餘的錯誤都由我負責。
diff --git a/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
new file mode 100644
index 00000000000..21c5c33d1eb
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
@@ -0,0 +1,52 @@
+---
+title: 智慧型合約安全列清單
+description: 一推薦程序來編輯安全智慧型合約
+author: "Trailofbits"
+tags: [ "智能合約", "安全性", "solidity" ]
+skill: intermediate
+lang: zh-tw
+published: 2020-09-07
+source: 建立安全合約
+sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md
+---
+
+## 智能合約開發檢查清單 {#smart-contract-development-checklist}
+
+此為一推薦之高階程序來遵照當你編輯你的智慧型合約.
+
+確認已知安全問題:
+
+- 使用 [Slither](https://github.com/crytic/slither) 檢閱您的合約。 此具一40 內建偵查器來檢查常見程式漏洞. 運行其於各新程式之檢查點並確保此具有一清晰回報(或利用一分流模式來靜音某些問題).
+- 使用 [Crytic](https://crytic.io/) 檢閱您的合約。 此確認Slither不包含之50額外問題. Crytic能幫助你的團隊來處於開發優勢, 藉由簡單來顯示安全物提於GitHub提取請求.
+
+為你的合約考慮特殊規範:
+
+- 你的合約是否可被升級? 使用 [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks) 或 [Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/) 檢查可升級性程式碼中的瑕疵。 我們已記錄17種可能導致失敗之升級方式.
+- 你的合約是否聲稱符合ERCs標準? 使用 [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) 檢查。 此工具立即表示6項常見檢測指標觀點.
+- 你是否與一第三方代幣互動? 在信賴外部合約前,請先檢閱我們的[代幣整合檢查清單](/developers/tutorials/token-integration-checklist/)。
+
+可視重要安全特徵於你的合約程式:
+
+- 檢閱 Slither 的 [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph) 輸出器。 避免不經意之影覆蓋及C3線性化問題.
+- 檢閱 Slither 的 [function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary) 輸出器。 此回報功能函數可視性及其訪問控制.
+- 檢閱 Slither 的 [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization) 輸出器。 此回報訪問控制及狀態變量.
+
+紀錄重要安全特性並使用自動化測試生成者來判斷其:
+
+- 學習如何[為您的程式碼記錄安全屬性](/developers/tutorials/guide-to-smart-contract-security-tools/)。 此剛開始極為困難, 但其為一最重要之活動來達成一良好安全結果. 此也為一基本要求來為任何先進技術於此教程.
+- 在 Solidity 中定義安全屬性,以便與 [Echidna](https://github.com/crytic/echidna) 和 [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html) 一起使用。 專注於你的狀態機器, 訪問控制, 算數操作, 外部互動, 及基本一致性.
+- 使用 [Slither 的 Python 應用程式介面 (API)](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) 定義安全屬性。 專注於繼承, 變量依據, 訪問控制, 及其他架構問題.
+- 在每次提交時,使用 [Crytic](https://crytic.io) 執行您的屬性測試。 Crytic能消化及價值安全特性測試所以任何參與者於你開發團隊能簡單來查看其是否正確通過於GitHub. 失敗測試可能阻擋提議.
+
+最終, 請留心自動工具無法簡單發現之問題:
+
+- 隱私缺乏性: 所有參與者將能查看你的交易當其排隊於池內.
+- 偷跑運行交易
+- 加密操作
+- 高風險互動與外部Defi部件
+
+## 尋求協助 {#ask-for-help}
+
+[以太坊辦公時間](https://calendly.com/dan-trailofbits/office-hours) 於每週二下午舉行。 此1小時, 1-對-1對應為一極佳機會來讓任何人來詢問關於安全, 道具使用憂慮, 並取得專家回報關於你的目前選擇方案. 我們將幫助你於此對應機會.
+
+加入我們的 Slack:[Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw)。 我們永遠於#crytic 及 #ethereum通道如你有任何問題.
diff --git a/public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md
new file mode 100644
index 00000000000..baa289afffe
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md
@@ -0,0 +1,210 @@
+---
+title: 使用 ethers.js 傳送代幣
+description: 使用 ethers.js 傳送代幣的初學者指南。
+author: Kim YongJun
+tags: [ "ETHERS.JS", "ERC-20", "代幣" ]
+skill: beginner
+lang: zh-tw
+published: 2021-04-06
+---
+
+## 使用 ethers.js (5.0) 傳送代幣 {#send-token}
+
+### 在本教學中,您將學習如何 {#you-learn-about}
+
+- 匯入 ethers.js
+- 傳送代幣
+- 根據網路流量情況設定 gas 價格
+
+### 開始使用 {#to-get-started}
+
+開始之前,我們必須先將 ethers.js 函式庫匯入 javascript 程式碼中
+包含 ethers.js (5.0)
+
+### 安裝 {#install-ethersjs}
+
+```shell
+/home/ricmoo> npm install --save ethers
+```
+
+瀏覽器中的 ES6
+
+```html
+
+```
+
+瀏覽器中的 ES3 (UMD)
+
+```html
+
+```
+
+### 參數 {#param}
+
+1. **`contract_address`**:代幣合約地址(當您要傳送的代幣不是 ether 時,需要合約地址)
+2. **`send_token_amount`**:您想傳送給接收者的代幣數量
+3. **`to_address`**:接收者的地址
+4. **`send_account`**:傳送者的地址
+5. **`private_key`**:傳送者的私密金鑰,用以簽署交易並實際傳送代幣
+
+## 注意事項 {#notice}
+
+`signTransaction(tx)` 已被移除,因為 `sendTransaction()` 會在內部處理。
+
+## 傳送程序 {#procedure}
+
+### 1. 連線至網路 (測試網) {#connect-to-network}
+
+#### 設定提供者 (Infura) {#set-provider}
+
+連線至 Ropsten 測試網
+
+```javascript
+window.ethersProvider = new ethers.providers.InfuraProvider("ropsten")
+```
+
+### 2. 建立錢包 {#create-wallet}
+
+```javascript
+let wallet = new ethers.Wallet(private_key)
+```
+
+### 3 將錢包連線至網路 {#connect-wallet-to-net}
+
+```javascript
+let walletSigner = wallet.connect(window.ethersProvider)
+```
+
+### 4 取得目前的 gas 價格 {#get-gas}
+
+```javascript
+window.ethersProvider.getGasPrice() // gas 價格
+```
+
+### 5 定義交易 {#define-transaction}
+
+下方定義的變數相依於 `send_token()`。
+
+### 交易參數 {#transaction-params}
+
+1. **`send_account`**:代幣傳送者的地址
+2. **`to_address`**:代幣接收者的地址
+3. **`send_token_amount`**:要傳送的代幣數量
+4. **`gas_limit`**:gas 上限
+5. **`gas_price`**:gas 價格
+
+[關於如何使用,請參閱下方](#how-to-use)
+
+```javascript
+const tx = {
+ from: send_account,
+ to: to_address,
+ value: ethers.utils.parseEther(send_token_amount),
+ nonce: window.ethersProvider.getTransactionCount(send_account, "latest"),
+ gasLimit: ethers.utils.hexlify(gas_limit), // 100000
+ gasPrice: gas_price,
+}
+```
+
+### 6. 傳送 {#transfer}
+
+```javascript
+walletSigner.sendTransaction(tx).then((transaction) => {
+ console.dir(transaction)
+ alert("傳送完成!")
+})
+```
+
+## 如何使用 {#how-to-use}
+
+```javascript
+let private_key =
+ "41559d28e936dc92104ff30691519693fc753ffbee6251a611b9aa1878f12a4d"
+let send_token_amount = "1"
+let to_address = "0x4c10D2734Fb76D3236E522509181CC3Ba8DE0e80"
+let send_address = "0xda27a282B5B6c5229699891CfA6b900A716539E6"
+let gas_limit = "0x100000"
+let wallet = new ethers.Wallet(private_key)
+let walletSigner = wallet.connect(window.ethersProvider)
+let contract_address = ""
+window.ethersProvider = new ethers.providers.InfuraProvider("ropsten")
+
+send_token(
+ contract_address,
+ send_token_amount,
+ to_address,
+ send_address,
+ private_key
+)
+```
+
+### 成功! {#success}
+
+
+
+## send_token() {#send-token-method}
+
+```javascript
+function send_token(
+ contract_address,
+ send_token_amount,
+ to_address,
+ send_account,
+ private_key
+) {
+ let wallet = new ethers.Wallet(private_key)
+ let walletSigner = wallet.connect(window.ethersProvider)
+
+ window.ethersProvider.getGasPrice().then((currentGasPrice) => {
+ let gas_price = ethers.utils.hexlify(parseInt(currentGasPrice))
+ console.log(`gas_price: ${gas_price}`)
+
+ if (contract_address) {
+ // 一般代幣傳送
+ let contract = new ethers.Contract(
+ contract_address,
+ send_abi,
+ walletSigner
+ )
+
+ // 多少代幣?
+ let numberOfTokens = ethers.utils.parseUnits(send_token_amount, 18)
+ console.log(`numberOfTokens: ${numberOfTokens}`)
+
+ // 傳送代幣
+ contract.transfer(to_address, numberOfTokens).then((transferResult) => {
+ console.dir(transferResult)
+ alert("已傳送代幣")
+ })
+ } // ether 傳送
+ else {
+ const tx = {
+ from: send_account,
+ to: to_address,
+ value: ethers.utils.parseEther(send_token_amount),
+ nonce: window.ethersProvider.getTransactionCount(
+ send_account,
+ "latest"
+ ),
+ gasLimit: ethers.utils.hexlify(gas_limit), // 100000
+ gasPrice: gas_price,
+ }
+ console.dir(tx)
+ try {
+ walletSigner.sendTransaction(tx).then((transaction) => {
+ console.dir(transaction)
+ alert("傳送完成!")
+ })
+ } catch (error) {
+ alert("傳送失敗!!")
+ }
+ }
+ })
+}
+```
diff --git a/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
new file mode 100644
index 00000000000..0e6e11c2bf4
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -0,0 +1,208 @@
+---
+title: 使用 Web3 發送交易
+description: "這是一份初學者友善指南,說明如何使用 Web3 發送以太坊交易。 將交易發送到以太坊區塊鏈有三個主要步驟:建立、簽署和廣播。 我們將會逐一說明。"
+author: "Elan Halpern"
+tags: [ "交易", "web3.js", "alchemy" ]
+skill: beginner
+lang: zh-tw
+published: 2020-11-04
+source: Alchemy docs
+sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum
+---
+
+這是一份初學者友善指南,說明如何使用 Web3 發送以太坊交易。 將交易發送到以太坊區塊鏈有三個主要步驟:建立、簽署和廣播。 我們將逐一說明這三個步驟,希望能解答您可能有的任何問題! 在本教學中,我們將使用 [Alchemy](https://www.alchemy.com/) 將交易發送到以太坊鏈。 您可以在[此處建立免費的 Alchemy 帳戶](https://auth.alchemyapi.io/signup)。
+
+\*\*注意:\*\*本指南適用於在您應用程式的_後端_簽署交易。 如果您想在前端整合簽署交易,請參閱[整合 Web3 與瀏覽器供應商](https://docs.alchemy.com/reference/api-overview#with-a-browser-provider)。
+
+## 基本知識 {#the-basics}
+
+和大多數初入門的區塊鏈開發人員一樣,您可能已經研究過如何發送交易(這應該是件很簡單的事),卻看到一大堆指南,每個指南的說法都不一樣,讓您有點不知所措和困惑。 如果您也遇到這種情況,別擔心,我們都曾有過同樣的經歷! 那麼,在開始之前,讓我們先釐清幾件事:
+
+### 1. Alchemy 不會儲存您的私密金鑰 {#alchemy-does-not-store-your-private-keys}
+
+- 這表示 Alchemy 無法代表您簽署和發送交易。 這是出於安全考量。 Alchemy 絕不會要求您分享您的私密金鑰,您也絕不應該將您的私密金鑰與託管節點(或任何人)分享。
+- 您可以使用 Alchemy 的核心 API 從區塊鏈讀取資料,但要寫入資料,您需要在透過 Alchemy 發送交易前,使用其他工具簽署交易(這適用於任何其他[節點服務](/developers/docs/nodes-and-clients/nodes-as-a-service/))。
+
+### 2. 什麼是「簽署者」? {#what-is-a-signer}
+
+- 簽署者會使用您的私密金鑰為您簽署交易。 在本教學中,我們將使用 [Alchemy web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3) 來簽署我們的交易,但您也可以使用任何其他 web3 函式庫。
+- 在前端,[MetaMask](https://metamask.io/) 就是一個簽署者的好例子,它會代表您簽署並發送交易。
+
+### 3. 為什麼我需要簽署我的交易? {#why-do-i-need-to-sign-my-transactions}
+
+- 每位想在以太坊網路上發送交易的使用者都必須簽署該交易(使用他們的私密金鑰),以驗證交易的來源確實是其所聲稱的發送者。
+- 保護此私密金鑰極為重要,因為擁有它就等於完全控制您的以太坊帳戶,讓您(或任何有權存取的人)能代表您執行交易。
+
+### 4. 我該如何保護我的私密金鑰? {#how-do-i-protect-my-private-key}
+
+- 保護您的私密金鑰並用它來發送交易的方法有很多種。 在本教學中,我們將使用一個 `.env` 檔案。 然而,您也可以使用儲存私密金鑰的獨立供應商、使用金鑰儲存檔案或其他選項。
+
+### 5. `eth_sendTransaction` 和 `eth_sendRawTransaction` 之間有什麼區別? {#difference-between-send-and-send-raw}
+
+`eth_sendTransaction` 和 `eth_sendRawTransaction` 都是以太坊 API 函式,可將交易廣播到以太坊網路,以便將其新增到未來的區塊中。 它們的不同之處在於處理交易簽署的方式。
+
+- [`eth_sendTransaction`](https://docs.web3js.org/api/web3-eth/function/sendTransaction) 用於發送_未簽署_的交易,這表示您發送到的節點必須管理您的私密金鑰,才能在將交易廣播到鏈上之前對其進行簽署。 由於 Alchemy 不持有使用者的私密金鑰,因此不支援此方法。
+- [`eth_sendRawTransaction`](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) 用於廣播已經簽署的交易。 這表示您必須先使用 [`signTransaction(tx, private_key)`](https://docs.web3js.org/api/web3-eth-accounts/function/signTransaction),然後將結果傳遞到 `eth_sendRawTransaction` 中。
+
+使用 web3 時,可透過呼叫 [web3.eth.sendSignedTransaction](https://docs.web3js.org/api/web3-eth/function/sendSignedTransaction) 函式來存取 `eth_sendRawTransaction`。
+
+這就是我們將在本教學中使用的內容。
+
+### 6. 什麼是 web3 函式庫? {#what-is-the-web3-library}
+
+- Web3.js 是一個標準 JSON-RPC 呼叫的包裝函式庫,在以太坊開發中相當常用。
+- 有許多針對不同語言的 web3 函式庫。 在本教學中,我們將使用以 JavaScript 編寫的 [Alchemy Web3](https://docs.alchemy.com/reference/api-overview)。 您可以[在此處](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries)查看其他選項,例如 [ethers.js](https://docs.ethers.org/v5/)。
+
+好了,既然我們已經解決了這些問題,就讓我們繼續進行教學吧。 隨時歡迎在 Alchemy [Discord](https://discord.gg/gWuC7zB) 中提問!
+
+### 7. 如何發送安全、燃料優化和私密的交易? {#how-to-send-secure-gas-optimized-and-private-transactions}
+
+- [Alchemy 有一套 Transact API](https://docs.alchemy.com/reference/transact-api-quickstart)。 您可以使用這些 API 來發送增強型交易、在交易發生前進行模擬、發送私密交易,以及發送燃料優化的交易。
+- 您也可以使用 [Notify API](https://docs.alchemy.com/docs/alchemy-notify) 在您的交易從記憶體池中取出並新增到鏈上時收到提醒。
+
+\*\*注意:\*\*本指南需要一個 Alchemy 帳戶、一個以太坊地址或 MetaMask 錢包,並安裝 NodeJs 和 npm。 如果沒有,請按照以下步驟操作:
+
+1. [建立免費的 Alchemy 帳戶](https://auth.alchemyapi.io/signup)
+2. [建立 MetaMask 帳戶](https://metamask.io/)(或取得一個以太坊地址)
+3. [按照這些步驟安裝 NodeJs 和 NPM](https://docs.alchemy.com/alchemy/guides/alchemy-for-macs)
+
+## 發送交易的步驟 {#steps-to-sending-your-transaction}
+
+### 1. 在 Sepolia 測試網上建立一個 Alchemy 應用程式 {#create-an-alchemy-app-on-the-sepolia-testnet}
+
+前往您的 [Alchemy 儀表板](https://dashboard.alchemyapi.io/) 並建立一個新應用程式,為您的網路選擇 Sepolia(或任何其他測試網)。
+
+### 2. 從 Sepolia 水龍頭請求 ETH {#request-eth-from-sepolia-faucet}
+
+按照 [Alchemy Sepolia 水龍頭](https://www.sepoliafaucet.com/) 上的說明接收 ETH。 請務必提供您的 **Sepolia** 以太坊地址(來自 MetaMask),而不是其他網路的地址。 按照說明操作後,請再次檢查您的錢包是否已收到 ETH。
+
+### 3. 建立一個新專案目錄並 `cd` 進入 {#create-a-new-project-direction}
+
+從命令列(macs 為終端機)建立一個新專案目錄並進入其中:
+
+```
+mkdir sendtx-example
+cd sendtx-example
+```
+
+### 4. 安裝 Alchemy Web3(或任何 web3 函式庫){#install-alchemy-web3}
+
+在您的專案目錄中執行以下指令來安裝 [Alchemy Web3](https://docs.alchemy.com/reference/api-overview):
+
+注意,如果您想使用 ethers.js 函式庫,請[按照此處的說明操作](https://docs.alchemy.com/docs/how-to-send-transactions-on-ethereum)。
+
+```
+npm install @alch/alchemy-web3
+```
+
+### 5. 安裝 dotenv {#install-dotenv}
+
+我們將使用一個 `.env` 檔案來安全地儲存我們的 API 金鑰和私密金鑰。
+
+```
+npm install dotenv --save
+```
+
+### 6. 建立 `.env` 檔案 {#create-the-dotenv-file}
+
+在您的專案目錄中建立一個 `.env` 檔案並新增以下內容(取代「`your-api-url`」和「`your-private-key`」)
+
+- 若要尋找您的 Alchemy API URL,請前往您儀表板上剛建立的應用程式的詳細資料頁面,點擊右上角的「View Key」,然後複製 HTTP URL。
+- 若要使用 MetaMask 尋找您的私密金鑰,請參閱本[指南](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)。
+
+```
+API_URL = "your-api-url"
+PRIVATE_KEY = "your-private-key"
+```
+
+
+
+
+不要提交 .env! 請務必不要與任何人分享或洩露您的 .env 檔案,因為這樣做會洩露您的機密。 如果您正在使用版本控制,請將您的 .env 新增到 gitignore 檔案中。
+
+
+
+
+### 7. 建立 `sendTx.js` 檔案 {#create-sendtx-js}
+
+太好了,既然我們的敏感資料已在 `.env` 檔案中受到保護,就讓我們開始編寫程式碼吧。 在我們的發送交易範例中,我們會將 ETH 發送回 Sepolia 水龍頭。
+
+建立一個 `sendTx.js` 檔案,我們將在其中設定並發送我們的範例交易,然後將以下程式碼行新增到該檔案中:
+
+```
+async function main() {
+ require('dotenv').config();
+ const { API_URL, PRIVATE_KEY } = process.env;
+ const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
+ const web3 = createAlchemyWeb3(API_URL);
+ const myAddress = '0x610Ae88399fc1687FA7530Aac28eC2539c7d6d63' //待辦事項:將此地址替換為您自己的公開地址
+
+ const nonce = await web3.eth.getTransactionCount(myAddress, 'latest'); // nonce 從 0 開始計數
+
+ const transaction = {
+ 'to': '0x31B98D14007bDEe637298086988A0bBd31184523', // 用於返還 eth 的水龍頭地址
+ 'value': 1000000000000000000, // 1 ETH
+ 'gas': 30000,
+ 'nonce': nonce,
+ // 可選的資料欄位,用於發送訊息或執行智能合約
+ };
+
+ const signedTx = await web3.eth.accounts.signTransaction(transaction, PRIVATE_KEY);
+
+ web3.eth.sendSignedTransaction(signedTx.rawTransaction, function(error, hash) {
+ if (!error) {
+ console.log("🎉 您的交易哈希為: ", hash, "\n 請到 Alchemy 的記憶體池查看您的交易狀態!");
+ } else {
+ console.log("❗提交交易時出錯:", error)
+ }
+ });
+}
+
+main();
+```
+
+請務必將**第 6 行**的地址替換為您自己的公開地址。
+
+現在,在我們開始執行這段程式碼之前,讓我們先談談這裡的一些組成部分。
+
+- `nonce`:nonce 規範用於追蹤從您的地址發送的交易數量。 我們需要它來確保安全並防止[重放攻擊](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce)。 為了取得從您的地址發送的交易數量,我們使用 [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount)。
+- `transaction`:交易物件有幾個我們需要指定的方面
+ - `to`:這是我們要發送 ETH 的目標地址。 在這種情況下,我們是將 ETH 發送回我們最初請求的 [Sepolia 水龍頭](https://sepoliafaucet.com/)。
+ - `value`:這是我們希望發送的金額,以 Wei 為單位,其中 10^18 Wei = 1 ETH
+ - `gas`:有很多方法可以決定交易中要包含的正確燃料數量。 Alchemy 甚至有一個[燃料價格 webhook](https://docs.alchemyapi.io/guides/alchemy-notify#address-activity-1),可以在燃料價格降至特定閾值時通知您。 對於主網交易,最好檢查像 [ETH Gas Station](https://ethgasstation.info/) 這樣的燃料估算器,以確定要包含的正確燃料數量。 21000 是以太坊上一次操作將使用的最低燃料量,因此為了確保我們的交易能夠執行,我們在此設定為 30000。
+ - `nonce`:請參見上面的 nonce 定義。 Nonce 從零開始計數。
+ - [可選] data:用於在您的轉帳中發送附加資訊,或呼叫智能合約,餘額轉帳非必要,請參閱下面的說明。
+- `signedTx`:為了簽署我們的交易物件,我們將使用 `signTransaction` 方法和我們的 `PRIVATE_KEY`
+- `sendSignedTransaction`:一旦我們有了已簽署的交易,就可以使用 `sendSignedTransaction` 將其發送出去,以便包含在後續的區塊中
+
+**關於 data 的說明**
+在以太坊中可以發送兩種主要類型的交易。
+
+- 餘額轉帳:將 ETH 從一個地址發送到另一個地址。 不需要 data 欄位,但是,如果您想在交易中附帶額外資訊,可以在此欄位中以 HEX 格式包含該資訊。
+ - 例如,假設我們想將 IPFS 文件的哈希寫入以太坊鏈,以便為其提供一個不可變的時間戳。 我們的 data 欄位看起來就會像這樣:`web3.utils.toHex(‘IPFS 哈希‘)`。 現在任何人都可以查詢鏈,查看該文件是何時新增的。
+- 智能合約交易:在鏈上執行一些智能合約程式碼。 在這種情況下,data 欄位應包含您希望執行的智能函式以及任何參數。
+ - 如需實際範例,請參閱此 [Hello World 教學](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#step-8-create-the-transaction)中的步驟 8。
+
+### 8. 使用 `node sendTx.js` 執行程式碼 {#run-the-code-using-node-sendtx-js}
+
+返回您的終端機或命令列並執行:
+
+```
+node sendTx.js
+```
+
+### 9. 在記憶體池中查看您的交易 {#see-your-transaction-in-the-mempool}
+
+在您的 Alchemy 儀表板中開啟[記憶體池頁面](https://dashboard.alchemyapi.io/mempool),並按您建立的應用程式進行篩選以尋找您的交易。 在這裡,我們可以看到我們的交易從待處理狀態轉換為已探勘狀態(如果成功)或已丟棄狀態(如果不成功)。 請務必將其保持在「全部」狀態,以便捕獲「已探勘」、「待處理」和「已丟棄」的交易。 您也可以透過搜尋發送到地址 `0x31b98d14007bdee637298086988a0bbd31184523` 的交易來尋找您的交易。
+
+找到交易後,若要查看其詳細資訊,請選擇交易哈希,這會將您帶到如下所示的檢視畫面:
+
+
+
+從那裡,您可以點擊紅色圈出的圖示,在 Etherscan 上查看您的交易!
+
+**太棒了! 您剛剛使用 Alchemy 發送了您的第一筆以太坊交易 🎉**
+
+_若對本指南有任何回饋與建議,請在 Alchemy 的 [Discord](https://discord.gg/A39JVCM) 上傳送訊息給 Elan!_
+
+_原文發表於 [https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy](https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy)_
diff --git a/public/content/translations/zh-tw/developers/tutorials/server-components/index.md b/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
new file mode 100644
index 00000000000..e41620fa10a
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
@@ -0,0 +1,295 @@
+---
+title: "Web3 應用程式的伺服器元件和代理"
+description: 閱讀本教學後,您將能編寫 TypeScript 伺服器,以偵聽區塊鏈上的事件,並透過自己的交易做出相應的回應。 這將讓您能夠編寫中心化應用程式(因為伺服器是一個故障點),但可以與 Web3 實體互動。 同樣的技術也可以用來編寫一個無需人工干預即可回應鏈上事件的代理。
+
+author: 作者:Ori Pomerantz
+lang: zh-tw
+tags: [ "代理", "伺服器", "鏈下" ]
+skill: beginner
+published: 2024-07-15
+---
+
+## 介紹 {#introduction}
+
+在大多數情況下,去中心化應用程式會使用伺服器來分發軟體,但所有實際互動都發生在用戶端(通常是網頁瀏覽器)和區塊鏈之間。
+
+
+
+然而,在某些情況下,應用程式可以從獨立執行的伺服器元件中受益。 這樣的伺服器能夠透過發行交易來回應事件以及來自其他來源(如 API)的請求。
+
+
+
+這樣的伺服器可以完成幾個可能的任務。
+
+- 秘密狀態的持有者。 在遊戲中,不讓玩家知道遊戲所知的所有資訊通常很有用。 然而,_區塊鏈上沒有秘密_,區塊鏈中的任何資訊都很容易被任何人發現。 因此,如果遊戲狀態的一部分要保密,就必須儲存在其他地方(而且可能需要使用[零知識證明](/zero-knowledge-proofs)來驗證該狀態的效果)。
+
+- 中心化預言機。 如果利害關係夠低,一個從網路上讀取一些資訊然後發布到鏈上的外部伺服器,可能就足以作為[預言機](/developers/docs/oracles/)來使用。
+
+- 代理。 如果沒有交易來啟動,區塊鏈上什麼事都不會發生。 當機會出現時,伺服器可以代表使用者執行套利等操作,例如[套利](/developers/docs/mev/#mev-examples-dex-arbitrage)。
+
+## 範例程式 {#sample-program}
+
+您可以在 [github](https://github.com/qbzzt/20240715-server-component) 上看到一個範例伺服器。 這個伺服器會偵聽來自[此合約](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=contract_code) 的事件,這是 Hardhat 的 Greeter 的修改版本。 當問候語被更改時,它會將其改回來。
+
+若要執行它:
+
+1. 複製儲存庫。
+
+ ```sh copy
+ git clone https://github.com/qbzzt/20240715-server-component.git
+ cd 20240715-server-component
+ ```
+
+2. 安裝必要的套件。 如果您還沒有,[請先安裝 Node](https://nodejs.org/en/download/package-manager)。
+
+ ```sh copy
+ npm install
+ ```
+
+3. 編輯 `.env` 來指定在 Holesky 測試網上擁有 ETH 的帳戶的私密金鑰。 如果您在 Holesky 上沒有 ETH,您可以使用[這個水龍頭](https://holesky-faucet.pk910.de/)。
+
+ ```sh filename=".env" copy
+ PRIVATE_KEY=0x <此處填入私密金鑰>
+ ```
+
+4. 啟動伺服器。
+
+ ```sh copy
+ npm start
+ ```
+
+5. 前往[區塊瀏覽器](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract),並使用與擁有私密金鑰的地址不同的地址來修改問候語。 查看問候語是否自動被改回。
+
+### 它是如何運作的? {#how-it-works}
+
+理解如何編寫伺服器元件最簡單的方法是逐行檢查範例。
+
+#### `src/app.ts` {#src-app-ts}
+
+程式的絕大部分都包含在 [`src/app.ts`](https://github.com/qbzzt/20240715-server-component/blob/main/src/app.ts) 中。
+
+##### 建立先決物件
+
+```typescript
+import {
+ createPublicClient,
+ createWalletClient,
+ getContract,
+ http,
+ Address,
+} from "viem"
+```
+
+這些是我們需要的 [Viem](https://viem.sh/) 實體、函式以及 [`Address` 類型](https://viem.sh/docs/glossary/types#address)。 這個伺服器是用 [TypeScript](https://www.typescriptlang.org/) 編寫的,它是 JavaScript 的一個擴充,使其成為[強型別](https://en.wikipedia.org/wiki/Strong_and_weak_typing)。
+
+```typescript
+import { privateKeyToAccount } from "viem/accounts"
+```
+
+[這個函式](https://viem.sh/docs/accounts/privateKey) 讓我們可以根據私密金鑰產生錢包資訊,包括地址。
+
+```typescript
+import { holesky } from "viem/chains"
+```
+
+要在 Viem 中使用區塊鏈,您需要匯入其定義。 在這種情況下,我們想要連接到 [Holesky](https://github.com/eth-clients/holesky) 測試區塊鏈。
+
+```typescript
+// 這就是我們如何將 .env 中的定義新增到 process.env 的方法。
+import * as dotenv from "dotenv"
+dotenv.config()
+```
+
+這就是我們將 `.env` 讀入環境的方式。 我們需要它來取得私密金鑰(稍後會看到)。
+
+```typescript
+const greeterAddress : Address = "0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6"
+const greeterABI = [
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "stateMutability": "nonpayable",
+ "type": "constructor"
+ },
+ .
+ .
+ .
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "name": "setGreeting",
+ "outputs": [],
+ "stateMutability": "nonpayable",
+ "type": "function"
+ }
+] as const
+```
+
+要使用合約,我們需要它的地址和 [ABI](/glossary/#abi)。 我們在這裡提供了這兩者。
+
+在 JavaScript(以及因此在 TypeScript 中),您不能為常數指定新值,但您_可以_修改儲存在其中的物件。 透過使用 `as const` 後綴,我們告訴 TypeScript 該清單本身是常數,不可更改。
+
+```typescript
+const publicClient = createPublicClient({
+ chain: holesky,
+ transport: http(),
+})
+```
+
+建立一個 Viem [公開用戶端](https://viem.sh/docs/clients/public.html)。 公開用戶端沒有附加的私密金鑰,因此無法傳送交易。 他們可以呼叫 [`view` 函式](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm)、讀取帳戶餘額等。
+
+```typescript
+const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
+```
+
+環境變數可在 [`process.env`](https://www.totaltypescript.com/how-to-strongly-type-process-env) 中取得。 然而,TypeScript 是強型別的。 環境變數可以是任何字串,或為空,所以環境變數的類型是 `string | undefined`。 然而,金鑰在 Viem 中被定義為 `0x${string}`(`0x` 後面跟著一個字串)。 在這裡,我們告訴 TypeScript `PRIVATE_KEY` 環境變數將是該類型。 如果不是,我們將會得到一個執行時錯誤。
+
+[`privateKeyToAccount`](https://viem.sh/docs/accounts/privateKey) 函式接著使用此私密金鑰來建立一個完整的帳戶物件。
+
+```typescript
+const walletClient = createWalletClient({
+ account,
+ chain: holesky,
+ transport: http(),
+})
+```
+
+接下來,我們使用帳戶物件來建立一個[錢包用戶端](https://viem.sh/docs/clients/wallet)。 此用戶端擁有私密金鑰和地址,因此可以用於傳送交易。
+
+```typescript
+const greeter = getContract({
+ address: greeterAddress,
+ abi: greeterABI,
+ client: { public: publicClient, wallet: walletClient },
+})
+```
+
+現在我們有了所有先決條件,終於可以建立一個[合約實例](https://viem.sh/docs/contract/getContract)。 我們將使用此合約實例與鏈上合約進行通訊。
+
+##### 從區塊鏈讀取
+
+```typescript
+console.log(`Current greeting:`, await greeter.read.greet())
+```
+
+唯讀的合約函式([`view`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm) 和 [`pure`](https://www.tutorialspoint.com/solidity/solidity_pure_functions.htm))可在 `read` 下找到。 在這種情況下,我們使用它來存取 [`greet`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=read_contract#cfae3217) 函式,該函式會傳回問候語。
+
+JavaScript 是單執行緒的,所以當我們啟動一個長時間執行的程序時,我們需要[指定我們以非同步方式執行](https://eloquentjavascript.net/11_async.html#h-XvLsfAhtsE)。 呼叫區塊鏈,即使是唯讀操作,也需要電腦和區塊鏈節點之間的來回通訊。 這就是為什麼我們在這裡指定程式碼需要 `await` 結果的原因。
+
+如果您對其運作方式感興趣,可以[在此處閱讀相關內容](https://www.w3schools.com/js/js_promise.asp),但實際上您只需要知道,如果您啟動一個耗時較長的操作,就需要 `await` 結果,並且任何執行此操作的函式都必須宣告為 `async`。
+
+##### 發行交易
+
+```typescript
+const setGreeting = async (greeting: string): Promise => {
+```
+
+這就是您呼叫來發行一筆更改問候語的交易的函式。 由於這是一個耗時較長的操作,該函式被宣告為 `async`。 由於內部實作,任何 `async` 函式都需要傳回一個 `Promise` 物件。 在這種情況下,`Promise` 表示我們沒有指定 `Promise` 中確切會傳回什麼。
+
+```typescript
+const txHash = await greeter.write.setGreeting([greeting])
+```
+
+合約實例的 `write` 欄位包含所有寫入區塊鏈狀態的函式(那些需要傳送交易的函式),例如 [`setGreeting`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract#a4136862)。 參數(如果有的話)以清單形式提供,函式會傳回交易的哈希。
+
+```typescript
+ console.log(`正在修復中,請參閱 https://eth-holesky.blockscout.com/tx/${txHash}`)
+
+ return txHash
+}
+```
+
+報告交易的哈希(作為查看它的區塊瀏覽器 URL 的一部分)並傳回它。
+
+##### 回應事件
+
+```typescript
+greeter.watchEvent.SetGreeting({
+```
+
+[`watchEvent` 函式](https://viem.sh/docs/actions/public/watchEvent) 讓您指定在發出事件時要執行的函式。 如果您只關心一種事件類型(在此例中為 `SetGreeting`),您可以使用此語法將自己限制在該事件類型。
+
+```typescript
+ onLogs: logs => {
+```
+
+當有日誌項目時,`onLogs` 函式會被呼叫。 在以太坊中,「日誌」和「事件」通常可以互換使用。
+
+```typescript
+console.log(
+ `地址 ${logs[0].args.sender} 已將問候語變更為 ${logs[0].args.greeting}`
+)
+```
+
+可能有多個事件,但為簡單起見,我們只關心第一個。 `logs[0].args` 是事件的引數,在此例中為 `sender` 和 `greeting`。
+
+```typescript
+ if (logs[0].args.sender != account.address)
+ setGreeting(`${account.address} insists on it being Hello!`)
+ }
+})
+```
+
+如果傳送者_不是_這個伺服器,請使用 `setGreeting` 來更改問候語。
+
+#### `package.json` {#package-json}
+
+[這個檔案](https://github.com/qbzzt/20240715-server-component/blob/main/package.json) 控制 [Node.js](https://nodejs.org/en) 的設定。 本文僅解釋重要的定義。
+
+```json
+{
+ "main": "dist/index.js",
+```
+
+這個定義指定了要執行的 JavaScript 檔案。
+
+```json
+ "scripts": {
+ "start": "tsc && node dist/app.js",
+ },
+```
+
+指令碼是各種應用程式操作。 在這種情況下,我們只有 `start`,它會編譯然後執行伺服器。 `tsc` 命令是 `typescript` 套件的一部分,可將 TypeScript 編譯成 JavaScript。 如果您想手動執行,它位於 `node_modules/.bin`。 第二個命令執行伺服器。
+
+```json
+ "type": "module",
+```
+
+JavaScript 節點應用程式有多種類型。 `module` 類型讓我們可以在頂層程式碼中使用 `await`,這在您執行慢速(也就是非同步)操作時很重要。
+
+```json
+ "devDependencies": {
+ "@types/node": "^20.14.2",
+ "typescript": "^5.4.5"
+ },
+```
+
+這些是僅在開發時需要的套件。 在這裡我們需要 `typescript`,而且因為我們將它與 Node.js 一起使用,我們也需要取得節點變數和物件的類型,例如 `process`。 [`^` 符號](https://github.com/npm/node-semver?tab=readme-ov-file#caret-ranges-123-025-004) 表示該版本或沒有破壞性變更的更高版本。 有關版本號碼含義的更多資訊,請參閱[此處](https://semver.org)。
+
+```json
+ "dependencies": {
+ "dotenv": "^16.4.5",
+ "viem": "2.14.1"
+ }
+}
+```
+
+這些是在執行 `dist/app.js` 時,在執行期間所需的套件。
+
+## 結論 {#conclusion}
+
+我們在這裡建立的中心化伺服器完成了它的工作,即作為使用者的代理。 任何其他希望去中心化應用程式繼續運作並願意花費 gas 的人,都可以用自己的地址執行一個新的伺服器實例。
+
+然而,這僅在中心化伺服器的操作可以輕鬆驗證時才有效。 如果中心化伺服器擁有任何秘密狀態資訊,或執行困難的計算,那麼它就是一個您需要信任才能使用該應用程式的中心化實體,而這正是區塊鏈試圖避免的。 在未來的文章中,我計畫展示如何使用[零知識證明](/zero-knowledge-proofs)來解決這個問題。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md b/public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
new file mode 100644
index 00000000000..401d2bb2ba0
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
@@ -0,0 +1,92 @@
+---
+title: 在 JavaScript 中設定 web3.js 以使用以太坊區塊鏈
+description: 了解如何設定與配置 web3.js 函式庫,以便從 JavaScript 應用程式與以太坊區塊鏈互動。
+author: "jdourlens"
+tags: [ "web3.js", "javascript" ]
+skill: beginner
+lang: zh-tw
+published: 2020-04-11
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/setup-web3js-to-use-the-ethereum-blockchain-in-javascript/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+在本教學中,我們將了解如何開始使用 [web3.js](https://web3js.readthedocs.io/) 來與以太坊區塊鏈互動。 Web3.js 可同時用於前端和後端,以從區塊鏈讀取資料、進行交易,甚至部署智能合約。
+
+第一步是將 web3.js 引入您的專案。 若要在網頁中使用,您可以使用像 JSDeliver 這類的 CDN 來直接匯入該函式庫。
+
+```html
+
+```
+
+如果您偏好安裝函式庫,以便在後端或使用建置工具的前端專案中使用,您可以使用 npm 來安裝:
+
+```bash
+npm install web3 --save
+```
+
+然後,要將 Web3.js 匯入 Node.js 指令稿或 Browserify 前端專案,您可以使用下面這行 JavaScript 程式碼:
+
+```js
+const Web3 = require("web3")
+```
+
+現在我們已經將函式庫引入專案中,接著需要將其初始化。 您的專案需要能夠與區塊鏈通訊。 大多數以太坊函式庫透過 RPC 呼叫與[節點](/developers/docs/nodes-and-clients/)通訊。 為了啟動我們的 Web3 供應商,我們將實例化一個 Web3 執行個體,並將供應商的 URL 作為建構函式傳遞。 如果您電腦上有執行中的節點或 [ganache 執行個體](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/),它會看起來像這樣:
+
+```js
+const web3 = new Web3("http://localhost:8545")
+```
+
+如果您想直接存取託管節點,可以在[節點即服務](/developers/docs/nodes-and-clients/nodes-as-a-service)中找到選項。
+
+```js
+const web3 = new Web3("https://cloudflare-eth.com")
+```
+
+為了測試我們是否正確地設定了 Web3 執行個體,我們將嘗試使用 `getBlockNumber` 函式來擷取最新的區塊號碼。 此函式接受一個回呼作為參數,並以整數形式傳回區塊號碼。
+
+```js
+var Web3 = require("web3")
+const web3 = new Web3("https://cloudflare-eth.com")
+
+web3.eth.getBlockNumber(function (error, result) {
+ console.log(result)
+})
+```
+
+如果您執行此程式,它將只會印出最新的區塊號碼:也就是區塊鏈的頂端。 您也可以使用 `await/async` 函式呼叫,以避免在程式碼中出現巢狀回呼:
+
+```js
+async function getBlockNumber() {
+ const latestBlockNumber = await web3.eth.getBlockNumber()
+ console.log(latestBlockNumber)
+ return latestBlockNumber
+}
+
+getBlockNumber()
+```
+
+您可以在 [web3.js 官方文件](https://docs.web3js.org/)中,查看 Web3 執行個體上所有可用的函式。
+
+大多數 Web3 函式庫都是非同步的,因為函式庫會在背景對節點進行 JSON-RPC 呼叫,而節點會傳回結果。
+
+
+
+如果您是在瀏覽器中作業,有些錢包會直接注入一個 Web3 執行個體,您應該盡可能使用它,特別是當您打算與使用者的以太坊地址互動以進行交易時。
+
+以下是偵測 MetaMask 錢包是否可用,並在可用時嘗試啟用的程式碼片段。 之後,您便能讀取使用者的餘額,並讓他們驗證您希望他們在以太坊區塊鏈上進行的交易:
+
+```js
+if (window.ethereum != null) {
+ state.web3 = new Web3(window.ethereum)
+ try {
+ // 如有需要,請求帳戶存取權限
+ await window.ethereum.enable()
+ // 帳戶現已公開
+ } catch (error) {
+ // 使用者拒絕帳戶存取權限...
+ }
+}
+```
+
+web3.js 也有替代方案,例如 [Ethers.js](https://docs.ethers.io/),而且也相當常用。 在下一個教學中,我們將會了解[如何在區塊鏈上輕鬆地監聽新傳入的區塊,並查看其內容](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/)。
diff --git a/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md b/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
new file mode 100644
index 00000000000..8c907290c51
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
@@ -0,0 +1,585 @@
+---
+title: "為優化 Calldata 而設的精簡 ABI"
+description: 為樂觀卷軸優化智能合約
+author: 作者:Ori Pomerantz
+lang: zh-tw
+tags: [ "Layer 2" ]
+skill: intermediate
+published: 2022-04-01
+---
+
+## 介紹 {#introduction}
+
+在本文中,您將學習[樂觀卷軸](/developers/docs/scaling/optimistic-rollups),了解其交易成本,以及這種不同的成本結構如何要求我們針對不同於以太坊主網的事物進行優化。
+您也將學習如何實作此項優化。
+
+### 利益揭露 {#full-disclosure}
+
+我是 [Optimism](https://www.optimism.io/) 的全職員工,因此本文中的範例將在 Optimism 上運行。
+然而,此處說明的技術也應同樣適用於其他卷軸。
+
+### 術語 {#terminology}
+
+在討論卷軸時,術語「第 1 層」(L1) 用於指代主網,也就是正式運作的以太坊網路。
+術語「第 2 層」(L2) 用於指代卷軸或任何其他依賴 L1 安全性,但其大部分處理在鏈下進行的系統。
+
+## 如何能進一步降低 L2 交易的成本? {#how-can-we-further-reduce-the-cost-of-L2-transactions}
+
+[樂觀卷軸](/developers/docs/scaling/optimistic-rollups) 必須保存每筆歷史交易的紀錄,以便任何人都能夠檢查它們並驗證當前狀態是否正確。
+將資料寫入以太坊主網最便宜的方法,是將其寫為 calldata。
+[Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-) 和 [Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups) 都選擇了這個解決方案。
+
+### L2 交易的成本 {#cost-of-l2-transactions}
+
+L2 交易的成本由兩部分組成:
+
+1. L2 處理,通常非常便宜
+2. L1 儲存,與主網的 gas 費用相關
+
+在我撰寫本文時,Optimism 上的 L2 gas 成本為 0.001 [Gwei](/developers/docs/gas/#pre-london)。
+另一方面,L1 的 gas 成本約為 40 gwei。
+[您可以在此處查看目前價格](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m)。
+
+一個 calldata 位元組的成本為 4 gas (如果其值為零) 或 16 gas (如果其值為任何其他值)。
+在 EVM 上最昂貴的操作之一是寫入儲存空間。
+在 L2 上將一個 32 位元組的字詞寫入儲存空間的最高成本為 22100 gas。 目前,這相當於 22.1 gwei。
+因此,如果我們能節省一個 calldata 的零位元組,我們將能寫入約 200 個位元組到儲存空間,而且仍然划算。
+
+### ABI {#the-abi}
+
+大多數交易從外部帳戶存取合約。
+大多數合約都是用 Solidity 編寫的,並根據[應用程式二進位介面 (ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding) 來解譯其資料欄位。
+
+然而,ABI 是為 L1 設計的,在 L1 上,一個 calldata 位元組的成本約等於四次算術運算,但在 L2 上,一個 calldata 位元組的成本超過一千次算術運算。
+calldata 的劃分如下:
+
+| 部分 | 長度 | 位元組 | 浪費的位元組 | 浪費的 gas | 必要的位元組 | 必要的 gas |
+| ----- | -: | ----: | -----: | ------: | -----: | ------: |
+| 函式選擇器 | 4 | 0-3 | 3 | 48 | 1 | 16 |
+| 零值 | 12 | 4-15 | 12 | 48 | 0 | 0 |
+| 目標地址 | 20 | 16-35 | 0 | 0 | 20 | 320 |
+| 數量 | 32 | 36-67 | 17 | 64 | 15 | 240 |
+| 總計 | 68 | | | 160 | | 576 |
+
+說明:
+
+- **函式選擇器**:合約的函式少於 256 個,因此我們可以用單一位元組來區分它們。
+ 這些位元組通常為非零值,因此[成本為 16 gas](https://eips.ethereum.org/EIPS/eip-2028)。
+- **零值**:這些位元組永遠為零,因為一個 20 位元組的地址並不需要一個 32 位元組的字詞來儲存它。
+ 儲存零值的位元組成本為 4 gas ([請參閱黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf),附錄 G,
+ 第 27 頁,`G``txdatazero` 的值)。
+- **數量**:如果我們假設在此合約中 `decimals` 為 18 (正常值),而我們轉帳的代幣最大數量為 1018,那我們得到的最大數量就是 1036。
+ 25615 > 1036,所以 15 個位元組就夠了。
+
+在 L1 上浪費 160 gas 通常可以忽略不計。 一筆交易至少花費 [21,000 gas](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed),所以額外的 0.8% 無關緊要。
+然而,在 L2 上,情況就不同了。 幾乎整筆交易的成本都花在將其寫入 L1。
+除了交易的 calldata,還有 109 個位元組的交易標頭 (目標地址、簽名等)。
+因此總成本為 `109*16+576+160=2480`,我們浪費了其中約 6.5%。
+
+## 在您無法控制目標的情況下降低成本 {#reducing-costs-when-you-dont-control-the-destination}
+
+假設您無法控制目標合約,您仍然可以使用類似[這個](https://github.com/qbzzt/ethereum.org-20220330-shortABI)的解決方案。
+讓我們來看看相關的檔案。
+
+### Token.sol {#token-sol}
+
+[這是目標合約](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol)。
+它是一個標準的 ERC-20 合約,帶有一個額外的功能。
+這個 `faucet` 函式讓任何使用者都能取得一些代幣來使用。
+它會讓一個生產環境的 ERC-20 合約變得無用,但當 ERC-20 只是為了方便測試而存在時,它能讓事情變得更簡單。
+
+```solidity
+ /**
+ * @dev 讓呼叫者獲得 1000 個代幣使用
+ */
+ function faucet() external {
+ _mint(msg.sender, 1000);
+ } // function faucet
+```
+
+### CalldataInterpreter.sol {#calldatainterpreter-sol}
+
+[這個合約是預期交易會用較短的 calldata 來呼叫的合約](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol)。
+讓我們逐行檢視它。
+
+```solidity
+//SPDX-License-Identifier: Unlicense
+pragma solidity ^0.8.0;
+
+
+import { OrisUselessToken } from "./Token.sol";
+```
+
+我們需要匯入代幣合約,才能知道如何呼叫它的函式。
+
+```solidity
+contract CalldataInterpreter {
+
+ OrisUselessToken public immutable token;
+```
+
+我們作為代理的代幣地址。
+
+```solidity
+
+ /**
+ * @dev 指定代幣地址
+ * @param tokenAddr_ ERC-20 合約地址
+ */
+ constructor(
+ address tokenAddr_
+ ) {
+ token = OrisUselessToken(tokenAddr_);
+ } // constructor
+```
+
+代幣地址是我們唯一需要指定的參數。
+
+```solidity
+ function calldataVal(uint startByte, uint length)
+ private pure returns (uint) {
+```
+
+從 calldata 讀取一個值。
+
+```solidity
+ uint _retVal;
+
+ require(length < 0x21,
+ "calldataVal 長度限制為 32 位元組");
+
+ require(length + startByte <= msg.data.length,
+ "calldataVal 嘗試讀取超過 calldatasize");
+```
+
+我們將載入一個 32 位元組 (256 位元) 的字詞到記憶體中,並移除不屬於我們所需欄位的位元組。
+這個演算法不適用於長度超過 32 位元組的值,當然我們也不能讀取超過 calldata 結尾的內容。
+在 L1 上,可能需要跳過這些測試以節省 gas,但在 L2 上 gas 非常便宜,這使得我們可以進行任何能想到的健全性檢查。
+
+```solidity
+ assembly {
+ _retVal := calldataload(startByte)
+ }
+```
+
+我們本可以從對 `fallback()` 的呼叫中複製資料 (見下文),但使用 [Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html) (EVM 的組合語言) 會更容易。
+
+這裡我們使用 [CALLDATALOAD 操作碼](https://www.evm.codes/#35) 將從 `startByte` 到 `startByte+31` 的位元組讀入堆疊。
+一般來說,Yul 中操作碼的語法是 `<操作碼名稱>(<第一個堆疊值,如果有的話>,<第二個堆疊值,如果有的話>...)`。
+
+```solidity
+
+ _retVal = _retVal >> (256-length*8);
+```
+
+只有最高有效位的 `length` 個位元組是欄位的一部分,所以我們[向右移位](https://en.wikipedia.org/wiki/Logical_shift)以去除其他值。
+這還有一個額外的好處,就是將值移動到欄位的右側,這樣它就是值本身,而不是值乘以 256 的某次方。
+
+```solidity
+
+ return _retVal;
+ }
+
+
+ fallback() external {
+```
+
+當對 Solidity 合約的呼叫不符合任何函式簽章時,它會呼叫[ `fallback()` 函式](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (假設存在的話)。
+對於 `CalldataInterpreter`,_任何_ 呼叫都會到達這裡,因為沒有其他 `external` 或 `public` 函式。
+
+```solidity
+ uint _func;
+
+ _func = calldataVal(0, 1);
+```
+
+讀取 calldata 的第一個位元組,它會告訴我們是哪個函式。
+函式可能無法在此處使用的原因有二:
+
+1. 為 `pure` 或 `view` 的函式不會改變狀態,也不會花費 gas (在鏈下呼叫時)。
+ 試圖降低它們的 gas 成本沒有意義。
+2. 依賴 [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties) 的函式。
+ `msg.sender` 的值將是 `CalldataInterpreter` 的地址,而不是呼叫者的地址。
+
+遺憾的是,[查看 ERC-20 規範](https://eips.ethereum.org/EIPS/eip-20)後,只剩下一個函式,`transfer`。
+這讓我們只剩下兩個函式:`transfer` (因為我們可以呼叫 `transferFrom`) 和 `faucet` (因為我們可以將代幣轉回給呼叫我們的人)。
+
+```solidity
+
+ // 使用來自 calldata 的資訊
+ // 呼叫代幣的狀態變更方法
+
+ // faucet
+ if (_func == 1) {
+```
+
+對 `faucet()` 的呼叫,它沒有參數。
+
+```solidity
+ token.faucet();
+ token.transfer(msg.sender,
+ token.balanceOf(address(this)));
+ }
+```
+
+在我們呼叫 `token.faucet()` 之後,我們會得到代幣。 然而,作為代理合約,我們並**不**需要代幣。
+呼叫我們的外部擁有帳戶 (EOA) 或合約才需要。
+所以我們將我們所有的代幣轉給呼叫我們的人。
+
+```solidity
+ // transfer (假設我們有權限這麼做)
+ if (_func == 2) {
+```
+
+轉帳代幣需要兩個參數:目標地址和數量。
+
+```solidity
+ token.transferFrom(
+ msg.sender,
+```
+
+我們只允許呼叫者轉帳他們擁有的代幣
+
+```solidity
+ address(uint160(calldataVal(1, 20))),
+```
+
+目標地址從位元組 #1 開始 (位元組 #0 是函式)。
+作為一個地址,它的長度是 20 位元組。
+
+```solidity
+ calldataVal(21, 2)
+```
+
+對於這個特定的合約,我們假設任何人都想轉帳的代幣最大數量可以用兩個位元組表示 (小於 65536)。
+
+```solidity
+ );
+ }
+```
+
+總體而言,一次轉帳需要 35 個位元組的 calldata:
+
+| 部分 | 長度 | 位元組 |
+| ----- | -: | ----: |
+| 函式選擇器 | 1 | 0 |
+| 目標地址 | 32 | 1-32 |
+| 數量 | 2 | 33-34 |
+
+```solidity
+ } // fallback
+
+} // contract CalldataInterpreter
+```
+
+### test.js {#test-js}
+
+[這個 JavaScript 單元測試](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) 向我們展示了如何使用這個機制 (以及如何驗證它能正確運作)。
+我將假設您了解 [chai](https://www.chaijs.com/) 和 [ethers](https://docs.ethers.io/v5/),並只解釋專門適用於該合約的部分。
+
+```js
+const { expect } = require("chai");
+
+describe("CalldataInterpreter", function () {
+ it("Should let us use tokens", async function () {
+ const Token = await ethers.getContractFactory("OrisUselessToken")
+ const token = await Token.deploy()
+ await token.deployed()
+ console.log("Token addr:", token.address)
+
+ const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+ const cdi = await Cdi.deploy(token.address)
+ await cdi.deployed()
+ console.log("CalldataInterpreter addr:", cdi.address)
+
+ const signer = await ethers.getSigner()
+```
+
+我們首先部署這兩個合約。
+
+```javascript
+ // 取得代幣來使用
+ const faucetTx = {
+```
+
+我們不能使用我們通常會使用的高階函式 (例如 `token.faucet()`) 來建立交易,因為我們沒有遵循 ABI。
+相反地,我們必須自己建立交易然後再傳送它。
+
+```javascript
+ to: cdi.address,
+ data: "0x01"
+```
+
+我們需要為交易提供兩個參數:
+
+1. `to`,目標地址。
+ 這是 calldata 解譯器合約。
+2. `data`,要傳送的 calldata。
+ 在 `faucet` 呼叫的情況下,資料是單一位元組 `0x01`。
+
+```javascript
+
+ }
+ await (await signer.sendTransaction(faucetTx)).wait()
+```
+
+我們呼叫[簽署者的 `sendTransaction` 方法](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction),因為我們已經指定了目標 (`faucetTx.to`) 且我們需要交易被簽署。
+
+```javascript
+// 檢查 faucet 是否正確提供代幣
+expect(await token.balanceOf(signer.address)).to.equal(1000)
+```
+
+在這裡我們驗證餘額。
+`view` 函式不需要節省 gas,所以我們就正常執行它們。
+
+```javascript
+// 給予 CDI 額度 (核准無法被代理)
+const approveTX = await token.approve(cdi.address, 10000)
+await approveTX.wait()
+expect(await token.allowance(signer.address, cdi.address)).to.equal(10000)
+```
+
+給予 calldata 解譯器一個額度以便能夠進行轉帳。
+
+```javascript
+// 轉帳代幣
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+ to: cdi.address,
+ data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+```
+
+建立一個轉帳交易。 第一個位元組是「0x02」,接著是目標地址,最後是數量 (0x0100,十進位為 256)。
+
+```javascript
+ await (await signer.sendTransaction(transferTx)).wait()
+
+ // 檢查我們是否少了 256 個代幣
+ expect (await token.balanceOf(signer.address)).to.equal(1000-256)
+
+ // 以及我們的目標是否收到了它們
+ expect (await token.balanceOf(destAddr)).to.equal(256)
+ }) // it
+}) // describe
+```
+
+## 在您能控制目標合約的情況下降低成本 {#reducing-the-cost-when-you-do-control-the-destination-contract}
+
+如果您確實能控制目標合約,您可以建立繞過 `msg.sender` 檢查的函式,因為它們信任 calldata 解譯器。
+[您可以在這裡的 `control-contract` 分支中看到一個範例](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract)。
+
+如果合約只回應外部交易,我們只需要一個合約就夠了。
+然而,那會破壞[可組合性](/developers/docs/smart-contracts/composability/)。
+比較好的做法是,讓一個合約回應正常的 ERC-20 呼叫,另一個合約回應帶有短呼叫資料的交易。
+
+### Token.sol {#token-sol-2}
+
+在這個範例中,我們可以修改 `Token.sol`。
+這讓我們可以擁有一些只有代理才能呼叫的函式。
+以下是新的部分:
+
+```solidity
+ // 唯一允許指定 CalldataInterpreter 地址的地址
+ address owner;
+
+ // CalldataInterpreter 地址
+ address proxy = address(0);
+```
+
+ERC-20 合約需要知道授權代理的身分。
+但是,我們無法在建構函式中設定此變數,因為我們還不知道它的值。
+這個合約會先被實例化,因為代理在其建構函式中需要代幣的地址。
+
+```solidity
+ /**
+ * @dev 呼叫 ERC20 建構函式。
+ */
+ constructor(
+ ) ERC20("Oris useless token-2", "OUT-2") {
+ owner = msg.sender;
+ }
+```
+
+創建者的地址 (稱為 `owner`) 儲存在這裡,因為這是唯一允許設定代理的地址。
+
+```solidity
+ /**
+ * @dev 設定代理 (CalldataInterpreter) 的地址。
+ * 只能由 owner 呼叫一次
+ */
+ function setProxy(address _proxy) external {
+ require(msg.sender == owner, "只能由 owner 呼叫");
+ require(proxy == address(0), "代理已設定");
+
+ proxy = _proxy;
+ } // function setProxy
+```
+
+代理具有特權存取權限,因為它可以繞過安全性檢查。
+為確保我們可以信任代理,我們只讓 `owner` 呼叫此函式,而且只能呼叫一次。
+一旦 `proxy` 有了真實的值 (非零),該值就無法改變,所以即使 owner 決定變壞,或者其助記詞被洩露,我們仍然是安全的。
+
+```solidity
+ /**
+ * @dev 有些函式可能只能由代理呼叫。
+ */
+ modifier onlyProxy {
+```
+
+這是一個 [`modifier` 函式](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm),它會修改其他函式的運作方式。
+
+```solidity
+ require(msg.sender == proxy);
+```
+
+首先,驗證我們是被代理呼叫的,而不是其他人。
+如果不是,則 `revert`。
+
+```solidity
+ _;
+ }
+```
+
+如果是,則執行我們修改的函式。
+
+```solidity
+ /* 允許代理實際為帳戶進行代理的函式 */
+
+ function transferProxy(address from, address to, uint256 amount)
+ public virtual onlyProxy() returns (bool)
+ {
+ _transfer(from, to, amount);
+ return true;
+ }
+
+ function approveProxy(address from, address spender, uint256 amount)
+ public virtual onlyProxy() returns (bool)
+ {
+ _approve(from, spender, amount);
+ return true;
+ }
+
+ function transferFromProxy(
+ address spender,
+ address from,
+ address to,
+ uint256 amount
+ ) public virtual onlyProxy() returns (bool)
+ {
+ _spendAllowance(from, spender, amount);
+ _transfer(from, to, amount);
+ return true;
+ }
+```
+
+這三項操作通常要求訊息直接來自轉移代幣或批准額度的實體。
+此處,我們有一個代理版本來執行這些操作,此代理:
+
+1. 由 `onlyProxy()` 修改,因此不允許任何其他人控制它們。
+2. 將通常是 `msg.sender` 的地址作為額外參數。
+
+### CalldataInterpreter.sol {#calldatainterpreter-sol-2}
+
+此 calldata 解譯器幾乎與上面的解釋器相同,只是被代理的函式會接收 `msg.sender` 參數,且 `transfer` 不需要額度。
+
+```solidity
+ // transfer (不需額度)
+ if (_func == 2) {
+ token.transferProxy(
+ msg.sender,
+ address(uint160(calldataVal(1, 20))),
+ calldataVal(21, 2)
+ );
+ }
+
+ // approve
+ if (_func == 3) {
+ token.approveProxy(
+ msg.sender,
+ address(uint160(calldataVal(1, 20))),
+ calldataVal(21, 2)
+ );
+ }
+
+ // transferFrom
+ if (_func == 4) {
+ token.transferFromProxy(
+ msg.sender,
+ address(uint160(calldataVal( 1, 20))),
+ address(uint160(calldataVal(21, 20))),
+ calldataVal(41, 2)
+ );
+ }
+```
+
+### Test.js {#test-js-2}
+
+前面的測試程式碼和這段程式碼之間有一些變化。
+
+```js
+const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+const cdi = await Cdi.deploy(token.address)
+await cdi.deployed()
+await token.setProxy(cdi.address)
+```
+
+我們需要告訴 ERC-20 合約要信任哪個代理
+
+```js
+console.log("CalldataInterpreter addr:", cdi.address)
+
+// 需要兩個簽署者來驗證額度
+const signers = await ethers.getSigners()
+const signer = signers[0]
+const poorSigner = signers[1]
+```
+
+要檢查 `approve()` 和 `transferFrom()`,我們需要第二個簽署者。
+我們稱它為 `poorSigner`,因為它不會得到我們的任何代幣 (當然它確實需要有 ETH)。
+
+```js
+// 轉帳代幣
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+ to: cdi.address,
+ data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+await (await signer.sendTransaction(transferTx)).wait()
+```
+
+因為 ERC-20 合約信任代理 (`cdi`),所以我們不需要額度來中繼轉帳。
+
+```js
+// 核准與 transferFrom
+const approveTx = {
+ to: cdi.address,
+ data: "0x03" + poorSigner.address.slice(2, 42) + "00FF",
+}
+await (await signer.sendTransaction(approveTx)).wait()
+
+const destAddr2 = "0xE1165C689C0c3e9642cA7606F5287e708d846206"
+
+const transferFromTx = {
+ to: cdi.address,
+ data: "0x04" + signer.address.slice(2, 42) + destAddr2.slice(2, 42) + "00FF",
+}
+await (await poorSigner.sendTransaction(transferFromTx)).wait()
+
+// 檢查 approve / transferFrom 組合是否正確完成
+expect(await token.balanceOf(destAddr2)).to.equal(255)
+```
+
+測試這兩個新函式。
+請注意,`transferFromTx` 需要兩個地址參數:額度的給予者和接收者。
+
+## 結論 {#conclusion}
+
+[Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) 和 [Arbitrum](https://developer.offchainlabs.com/docs/special_features) 都在尋找方法來減少寫入 L1 的 calldata 大小,從而降低交易成本。
+然而,作為尋求通用解決方案的基礎設施提供商,我們的能力有限。
+身為去中心化應用程式開發者,您擁有應用程式特定的知識,這讓您能比我們在通用解決方案中更有效地優化您的 calldata。
+希望本文能幫助您找到滿足您需求的理想解決方案。
+
+[在此查看我的更多作品](https://cryptodocguy.pro/)。
+
diff --git a/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
new file mode 100644
index 00000000000..67f09f56285
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
@@ -0,0 +1,91 @@
+---
+title: 智慧型合約安全指南
+description: 一安全指南列表來介紹如何考慮安全當建立你個人Dapp
+author: "Trailofbits"
+tags: [ "穩固", "智能合約", "安全性" ]
+skill: intermediate
+lang: zh-tw
+published: 2020-09-06
+source: 建立安全合約
+sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
+---
+
+遵照以下高階推薦來建立一更加安全之智慧型合約.
+
+## 設計準則 {#design-guidelines}
+
+智慧型合約設計應被事前討論, 遠早於任何程式被編輯前.
+
+### 文件與規範 {#documentation-and-specifications}
+
+文檔能被編輯於多重等級, 並需備更新當被導入合約時:
+
+- **以淺顯易懂的英文描述系統**,說明合約的功能以及對程式碼庫的任何假設。
+- **綱要與架構圖**,包括合約互動和系統的狀態機器。 [Slither printers](https://github.com/crytic/slither/wiki/Printer-documentation) 可協助產生這些綱要。
+- **詳盡的程式碼文件**,Solidity 可使用 [Natspec 格式](https://docs.soliditylang.org/en/develop/natspec-format.html)。
+
+### 鏈上與鏈外運算 {#onchain-vs-offchain-computation}
+
+- \*\*盡可能將程式碼保持在鏈外。\*\*保持鏈上層的精簡。 以鏈外程式碼預先處理資料,使鏈上驗證更簡單。 你需要一採購列表嗎? 排列鏈下列表, 並只查看先前老舊之鏈上資訊.
+
+### 可升級性 {#upgradeability}
+
+我們在[我們的部落格文章](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)中討論了不同的可升級性解決方案。 編輯程式前, 先意識決定來支持或非支持此更新能力. 這個決定將會影響您架構程式碼的方式。 通常上來說, 我們推薦:
+
+- \*\*優先選擇[合約遷移](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/),而非可升級性。\*\*遷移系統擁有許多與可升級系統相同的優點,但沒有其缺點。
+- \*\*使用資料分離模式,而非 delegatecallproxy 模式。\*\*如果您的專案有清楚的抽象分離,使用資料分離的可升級性將只需要少許調整。 Delegatecallproxy 系統要求EVM專家, 且其具高錯誤率.
+- \*\*在部署前記錄遷移/升級程序。\*\*如果您必須在沒有任何指導方針的壓力下做出反應,就會犯錯。 事前編輯一程式步驟. 此應包含:
+ - 一調用來展開一新合約
+ - 鑰鍵儲存場所及入手方式
+ - 解釋如何查看部署! 開發並測試一部署後腳本
+
+## 實作準則 {#implementation-guidelines}
+
+\*\*力求簡單。\*\*永遠使用符合您目的最簡單的解決方案。 團隊任何成員應全員了解你的方案.
+
+### 函式組合 {#function-composition}
+
+你數據庫之構成結構應使程式能被簡單閱讀. 避免程式結構降低閱讀正確率.
+
+- **分割您系統的邏輯**,可以透過多個合約或將相似的函式分組(例如,驗證、算術...)來達成。
+- \*\*撰寫目的明確的小函式。\*\*這將有助於簡化審查,並允許對個別組件進行測試。
+
+### 繼承 {#inheritance}
+
+- \*\*保持繼承的可管理性。\*\*繼承應用來分割邏輯,但是,您的專案應致力於最小化繼承樹的深度和廣度。
+- \*\*使用 Slither 的 [inheritance printer](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) 檢查合約的層次結構。\*\*inheritance printer 將幫助您檢視層次結構的大小。
+
+### Events {#events}
+
+- \*\*記錄所有關鍵操作。\*\*事件將有助於在開發期間對合約進行偵錯,並在部署後對其進行監控。
+
+### 避免已知的陷阱 {#avoid-known-pitfalls}
+
+- \*\*注意最常見的安全性問題。\*\*有許多線上資源可以學習常見問題,例如 [Ethernaut CTF](https://ethernaut.openzeppelin.com/)、[Capture the Ether](https://capturetheether.com/) 或 [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/)。
+- \*\*注意 [Solidity 文件](https://docs.soliditylang.org/en/latest/)中的警告部分。\*\*警告部分會告知您該語言中不甚明顯的行為。
+
+### 相依性 {#dependencies}
+
+- \*\*使用經過良好測試的程式庫。\*\*從經過良好測試的程式庫匯入程式碼將降低您編寫有錯誤程式碼的可能性。 如果您想編寫 ERC20 合約,請使用 [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20)。
+- \*\*使用相依性管理員;避免複製貼上程式碼。\*\*如果您依賴外部來源,那麼您必須使其與原始來源保持同步。
+
+### 測試與驗證 {#testing-and-verification}
+
+- \*\*撰寫詳盡的單元測試。\*\*一個廣泛的測試套件對於建構高品質軟體至關重要。
+- \*\*撰寫 [Slither](https://github.com/crytic/slither)、[Echidna](https://github.com/crytic/echidna) 和 [Manticore](https://github.com/trailofbits/manticore) 的自訂檢查和屬性。\*\*自動化工具將有助於確保您的合約安全。 回顧此指南其他部分來學習如何編輯一有效查看及屬性.
+- **使用 [crytic.io](https://crytic.io/)。** Crytic 與 GitHub 整合,提供對私有 Slither 偵測器的存取權限,並從 Echidna 執行自訂屬性檢查。
+
+### Solidity {#solidity}
+
+- \*\*優先使用 Solidity 0.5,而非 0.4 和 0.6。\*\*在我們看來,Solidity 0.5 比 0.4 更安全,並具有更好的內建實踐。 Solidity 0.6已被證實其於實際生成還未安全, 並需要些時間來發展成熟.
+- \*\*使用穩定版本進行編譯;使用最新版本檢查警告。\*\*請檢查您的程式碼在最新的編譯器版本中沒有回報任何問題。 然而,Solidity 的發佈週期很快,且有編譯器錯誤的歷史,因此我們不建議使用最新版本進行部署(請參閱 Slither 的 [solc 版本建議](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33))。
+- \*\*不要使用內嵌組合語言。\*\*組合語言需要 EVM 專業知識。 如果您還沒有_精通_黃皮書,請不要編寫 EVM 程式碼。
+
+## 部署準則 {#deployment-guidelines}
+
+一旦合約被開發及部署:
+
+- \*\*監控您的合約。\*\*觀察日誌,並準備好在合約或錢包遭到入侵時做出反應。
+- \*\*將您的聯絡資訊新增至 [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts)。\*\*如果發現安全性漏洞,此列表有助於第三方與您聯絡。
+- \*\*保護特權使用者的錢包。\*\*如果您將金鑰儲存在硬體錢包中,請遵循我們的[最佳實踐](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/)。
+- \*\*制定事件應變計畫。\*\*請考慮到您的智慧合約可能會受到損害。 即使合約本身無任何bug, 一攻擊者還是可能嘗試掌控合約持有者之密鑰.
diff --git a/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md b/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
new file mode 100644
index 00000000000..1c61cf80c2a
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
@@ -0,0 +1,436 @@
+---
+title: "使用隱匿地址"
+description: "隱匿地址讓使用者能夠匿名轉移資產。 閱讀本文後,您將能夠:解釋什麼是隱匿地址及其運作方式、瞭解如何以維護匿名性的方式使用隱匿地址,以及編寫使用隱匿地址的網頁應用程式。"
+author: 作者:Ori Pomerantz
+tags: [ "隱匿地址", "隱私", "密碼學", "rust", "wasm" ]
+skill: intermediate
+published: 2025-11-30
+lang: zh-tw
+sidebarDepth: 3
+---
+
+您是 Bill。 我們不深入探討原因,假設您想捐款給「Alice 競選世界女王」活動,並希望 Alice 知道您捐了款,以便在她勝選後給予您酬勞。 可惜,她不保證會勝選。 有個競爭活動:「Carol 競選太陽系女皇」。 如果 Carol 勝選,而且她發現您捐款給 Alice,您就會有麻煩了。 所以您不能直接從您的帳戶轉 200 ETH 給 Alice。
+
+[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) 提供了這個問題的解決辦法。 此 ERC 說明了如何使用 [隱匿地址](https://nerolation.github.io/stealth-utils) 進行匿名轉帳。
+
+**警告**:據我們所知,隱匿地址背後的密碼學是健全的。 不過,仍有潛在的旁路攻擊。 您可以在[下方](#go-wrong)看到如何降低此風險。
+
+## 隱匿地址的運作方式 {#how}
+
+本文將會以兩種方式說明隱匿地址。 第一種是[如何使用](#how-use)。 這部分就足以理解本文的其餘內容。 接著會[說明其背後的數學原理](#how-math)。 如果您對密碼學感興趣,也請閱讀這部分。
+
+### 簡易版本(如何使用隱匿地址) {#how-use}
+
+Alice 建立了兩把私鑰,並發布了相應的公鑰(可合併成單一雙倍長度的中繼地址)。 Bill 也建立了一把私鑰,並發布了相應的公鑰。
+
+使用其中一方的公鑰和另一方的私鑰,您可以推導出只有 Alice 和 Bill 知道的共享密鑰(無法僅從公鑰推導)。 Bill 可透過此共享密鑰取得隱匿地址,並將資產傳送至該地址。
+
+Alice 也能從共享密鑰取得地址,但由於她知道自己所發布公鑰的私鑰,她也能取得讓她從該地址提款的私鑰。
+
+### 數學原理(隱匿地址為何如此運作) {#how-math}
+
+標準隱匿地址使用[橢圓曲線密碼學 (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor) 來以較少的金鑰位元達到更佳的效能,同時維持相同等級的安全性。 但在大多數情況下,我們可以忽略這點,假裝我們使用的是常規算術。
+
+有一個大家都知道的數字 _G_。 您可以將其乘以 _G_。 但由於橢圓曲線密碼學 (ECC) 的性質,幾乎不可能將其除以 _G_。 以太坊中公鑰密碼學的一般運作方式是,您可以使用私鑰 _Ppriv_ 來簽署交易,然後由公鑰 _Ppub = GPpriv_ 進行驗證。
+
+Alice 建立兩把私鑰:_Kpriv_ 和 _Vpriv_。 _Kpriv_ 將用來從隱匿地址花費金錢,而 _Vpriv_ 則用來檢視屬於 Alice 的地址。 Alice 接著發布公鑰:_Kpub = GKpriv_ 和 _Vpub = GVpriv_
+
+Bill 建立了第三把私鑰 _Rpriv_,並將 _Rpub = GRpriv_ 發布到中央註冊處(Bill 也可以把它傳送給 Alice,但我們假設 Carol 正在竊聽)。
+
+Bill 計算 _RprivVpub = GRprivVpriv_,他預期 Alice 也會知道(如下文說明)。 此值稱為 _S_,也就是共享密鑰。 這給了 Bill 一把公鑰:_Ppub = Kpub+G\*hash(S)_。 他可以從這把公鑰計算出一個地址,並將任何他想要的資源傳送到該地址。 未來如果 Alice 勝選,Bill 可以告訴她 _Rpriv_ 以證明資源來自於他。
+
+Alice 計算 _RpubVpriv = GRprivVpriv_。 這給了她相同的共享密鑰 _S_。 因為她知道私鑰 _Kpriv_,她可以計算出 _Ppriv = Kpriv+hash(S)_。 這把金鑰讓她能存取地址中的資產,而該地址是從 _Ppub = GPpriv = GKpriv+G\*hash(S) = Kpub+G\*hash(S)_ 產生的。
+
+我們有一把獨立的檢視金鑰,讓 Alice 可以將工作分包給 Dave 的「世界統治競選服務」。 Alice 願意讓 Dave 知道公用地址,並在有更多資金時通知她,但她不希望 Dave 花費她的競選資金。
+
+因為檢視和花費使用不同的金鑰,所以 Alice 可以把 _Vpriv_ 給 Dave。 然後 Dave 可以計算 _S = RpubVpriv = GRprivVpriv_,並以此取得公鑰(_Ppub = Kpub+G\*hash(S)_)。 但如果沒有 _Kpriv_,Dave 就無法取得私鑰。
+
+總而言之,以下是不同參與者所知道的值。
+
+| Alice | 已發布 | Bill | Dave | |
+| ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------- |
+| G | G | G | G | |
+| _Kpriv_ | - | - | - | |
+| _Vpriv_ | - | - | _Vpriv_ | |
+| _Kpub = GKpriv_ | _Kpub_ | _Kpub_ | _Kpub_ | |
+| _Vpub = GVpriv_ | _Vpub_ | _Vpub_ | _Vpub_ | |
+| - | - | _Rpriv_ | - | |
+| _Rpub_ | _Rpub_ | _Rpub = GRpriv_ | _Rpub_ | |
+| _S = RpubVpriv = GRprivVpriv_ | - | _S = RprivVpub = GRprivVpriv_ | _S = _RpubVpriv_ = GRprivVpriv_ | |
+| _Ppub = Kpub+G\*hash(S)_ | - | _Ppub = Kpub+G\*hash(S)_ | _Ppub = Kpub+G\*hash(S)_ | |
+| _Address=f(Ppub)_ | - | _Address=f(Ppub)_ | _Address=f(Ppub)_ | _Address=f(Ppub)_ |
+| _Ppriv = Kpriv+hash(S)_ | - | - | - | |
+
+## 隱匿地址出錯時 {#go-wrong}
+
+_區塊鏈上沒有祕密_。 雖然隱匿地址可以提供隱私,但這種隱私很容易受到流量分析的影響。 舉一個簡單的例子,假設 Bill 為一個地址提供資金,並立即傳送一筆交易來發布一個 _Rpub_ 值。 如果沒有 Alice 的 _Vpriv_,我們無法確定這是一個隱匿地址,但可以這麼猜測。 然後,我們看到另一筆交易,將該地址的所有 ETH 轉移到 Alice 的競選基金地址。 我們可能無法證明,但很有可能 Bill 剛剛捐款給 Alice 的競選活動。 Carol 肯定會這麼想。
+
+Bill 很容易將 _Rpub_ 的發布與隱匿地址的資金分開(在不同時間,從不同地址進行)。 然而,這還不夠。 Carol 尋找的模式是 Bill 為一個地址提供資金,然後 Alice 的競選基金從中提款。
+
+一個解決方案是 Alice 的競選活動不要直接提款,而是用它來支付給第三方。 如果 Alice 的競選活動將 10 ETH 傳送到 Dave 的「世界統治競選服務」,Carol 只知道 Bill 捐款給 Dave 的其中一個客戶。 如果 Dave 有足夠的客戶,Carol 就無法知道 Bill 是捐款給與她競爭的 Alice,還是捐給 Carol 不在乎的 Adam、Albert 或 Abigail。 Alice 可以在付款中包含一個哈希值,然後向 Dave 提供原像,以證明這是她的捐款。 或者,如上所述,如果 Alice 給了 Dave 她的 _Vpriv_,他就已經知道付款來自誰。
+
+這個解決方案的主要問題是,它要求 Alice 在保密對 Bill 有利時,也要關心保密。 Alice 可能想要維持她的聲譽,這樣 Bill 的朋友 Bob 也會捐款給她。 但也有可能她不介意揭發 Bill,因為這樣 Bill 就會害怕如果 Carol 獲勝會發生什麼事。 Bill 最終可能會提供 Alice 更多的支持。
+
+### 使用多個隱匿層 {#multi-layer}
+
+Bill 可以自己保護自己的隱私,而不是依靠 Alice。 他可以為虛構的人物 Bob 和 Bella 產生多個中繼地址。 然後 Bill 將 ETH 傳送給 Bob,而「Bob」(實際上是 Bill)再將其傳送給 Bella。 「Bella」(也是 Bill)再將其傳送給 Alice。
+
+Carol 仍然可以進行流量分析,並看到從 Bill 到 Bob 再到 Bella 再到 Alice 的管道。 然而,如果「Bob」和「Bella」也將 ETH 用於其他目的,那麼即使 Alice 立即從隱匿地址提款到她已知的競選地址,也不會顯示 Bill 將任何東西轉移給 Alice。
+
+## 編寫隱匿地址應用程式 {#write-app}
+
+本文說明了一個[在 GitHub 上可用的](https://github.com/qbzzt/251022-stealth-addresses.git)隱匿地址應用程式。
+
+### 工具 {#tools}
+
+我們可以使用[一個 typescript 隱匿地址程式庫](https://github.com/ScopeLift/stealth-address-sdk)。 然而,密碼學操作可能非常耗費 CPU。 我偏好以 [Rust](https://rust-lang.org/) 這類編譯語言實作,並使用 [WASM](https://webassembly.org/) 在瀏覽器中執行程式碼。
+
+我們將使用 [Vite](https://vite.dev/) 和 [React](https://react.dev/)。 這些是業界標準的工具;如果您不熟悉,可以使用[此教學](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)。 要使用 Vite,我們需要 Node。
+
+### 實際操作隱匿地址 {#in-action}
+
+1. 安裝必要的工具:[Rust](https://rust-lang.org/tools/install/) 和 [Node](https://nodejs.org/en/download)。
+
+2. 複製 GitHub 存放庫。
+
+ ```sh
+ git clone https://github.com/qbzzt/251022-stealth-addresses.git
+ cd 251022-stealth-addresses
+ ```
+
+3. 安裝先決條件並編譯 Rust 程式碼。
+
+ ```sh
+ cd src/rust-wasm
+ rustup target add wasm32-unknown-unknown
+ cargo install wasm-pack
+ wasm-pack build --target web
+ ```
+
+4. 啟動網頁伺服器。
+
+ ```sh
+ cd ../..
+ npm install
+ npm run dev
+ ```
+
+5. 瀏覽至[應用程式](http://localhost:5173/)。 此應用程式頁面有兩個框架:一個用於 Alice 的使用者介面,另一個用於 Bill 的使用者介面。 這兩個框架不互相通訊;它們僅為了方便而放在同一個頁面上。
+
+6. 以 Alice 的身分,點擊 **Generate a Stealth Meta-Address**(產生隱匿中繼地址)。 這會顯示新的隱匿地址和相應的私鑰。 將隱匿中繼地址複製到剪貼簿。
+
+7. 以 Bill 的身分,貼上新的隱匿中繼地址並點擊 **Generate an address**(產生地址)。 這會提供您要為 Alice 提供資金的地址。
+
+8. 複製地址和 Bill 的公鑰,並將它們貼到 Alice 使用者介面的「Private key for address generated by Bill」(Bill 產生的地址之私鑰)區域中。 填寫完這些欄位後,您會看到存取該地址資產的私鑰。
+
+9. 您可以使用[線上計算機](https://iancoleman.net/ethereum-private-key-to-address/)來確保私鑰與地址相符。
+
+### 程式運作方式 {#how-the-program-works}
+
+#### WASM 元件 {#wasm}
+
+編譯成 WASM 的原始碼是以 [Rust](https://rust-lang.org/) 編寫的。 您可以在 [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs) 中看到它。 此程式碼主要是 JavaScript 程式碼與 [`eth-stealth-addresses` 程式庫](https://github.com/kassandraoftroy/eth-stealth-addresses)之間的介面。
+
+**`Cargo.toml`**
+
+Rust 中的 [`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html) 類似於 JavaScript 中的 [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json)。 其中包含套件資訊、相依性宣告等。
+
+```toml
+[package]
+name = "rust-wasm"
+version = "0.1.0"
+edition = "2024"
+
+[dependencies]
+eth-stealth-addresses = "0.1.0"
+hex = "0.4.3"
+wasm-bindgen = "0.2.104"
+getrandom = { version = "0.2", features = ["js"] }
+```
+
+[`getrandom`](https://docs.rs/getrandom/latest/getrandom/) 套件需要產生隨機值。 這無法單純透過演算法達成;它需要存取實體程序作為熵的來源。 此定義指定我們將透過詢問我們正在執行的瀏覽器來取得該熵。
+
+```toml
+console_error_panic_hook = "0.1.7"
+```
+
+[此程式庫](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/) 在 WASM 程式碼發生恐慌且無法繼續時,提供我們更有意義的錯誤訊息。
+
+```toml
+[lib]
+crate-type = ["cdylib", "rlib"]
+```
+
+產生 WASM 程式碼所需的輸出類型。
+
+**`lib.rs`**
+
+這是實際的 Rust 程式碼。
+
+```rust
+use wasm_bindgen::prelude::*;
+```
+
+從 Rust 建立 WASM 套件的定義。 [此處](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html)有其文件說明。
+
+```rust
+use eth_stealth_addresses::{
+ generate_stealth_meta_address,
+ generate_stealth_address,
+ compute_stealth_key
+};
+```
+
+我們需要從 [`eth-stealth-addresses` 程式庫](https://github.com/kassandraoftroy/eth-stealth-addresses) 取得的函式。
+
+```rust
+use hex::{decode,encode};
+```
+
+Rust 通常使用位元組[陣列](https://doc.rust-lang.org/std/primitive.array.html) (`[u8; ]`) 來表示值。 但在 JavaScript 中,我們通常使用十六進位字串。 [`hex` 程式庫](https://docs.rs/hex/latest/hex/) 為我們將一種表示法轉換為另一種。
+
+```rust
+#[wasm_bindgen]
+```
+
+產生 WASM 繫結,以便能從 JavaScript 呼叫此函式。
+
+```rust
+pub fn wasm_generate_stealth_meta_address() -> String {
+```
+
+傳回具有多個欄位的物件最簡單的方式是傳回 JSON 字串。
+
+```rust
+ let (address, spend_private_key, view_private_key) =
+ generate_stealth_meta_address();
+```
+
+[`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html) 傳回三個欄位:
+
+- 中繼地址(_Kpub_ 和 _Vpub_)
+- 檢視私鑰(_Vpriv_)
+- 花費私鑰(_Kpriv_)
+
+[tuple](https://doc.rust-lang.org/std/primitive.tuple.html) 語法讓我們可以再次分離這些值。
+
+```rust
+ format!("{{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}}",
+ encode(address),
+ encode(view_private_key),
+ encode(spend_private_key)
+ )
+}
+```
+
+使用 [`format!`](https://doc.rust-lang.org/std/fmt/index.html) 巨集來產生 JSON 編碼的字串。 使用 [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html) 將陣列變更為十六進位字串。
+
+```rust
+fn str_to_array(s: &str) -> Option<[u8; N]> {
+```
+
+此函式將十六進位字串(由 JavaScript 提供)轉換為位元組陣列。 我們用它來剖析 JavaScript 程式碼提供的值。 此函式很複雜,因為 Rust 處理陣列和向量的方式。
+
+`` 運算式稱為[泛型](https://doc.rust-lang.org/book/ch10-01-syntax.html)。 `N` 是一個控制傳回陣列長度的參數。 此函式實際上稱為 `str_to_array::`,其中 `n` 是陣列長度。
+
+傳回值是 `Option<[u8; N]>`,表示傳回的陣列是[可選的](https://doc.rust-lang.org/std/option/)。 這是 Rust 中函式可能失敗的典型模式。
+
+例如,如果我們呼叫 `str_to_array::10("bad060a7")`,函式應該傳回一個十值陣列,但輸入只有四個位元組。 此函式需要失敗,而它透過傳回 `None` 來達成。 `str_to_array::4("bad060a7")` 的傳回值會是 `Some<[0xba, 0xd0, 0x60, 0xa7]>`。
+
+```rust
+ // decode 傳回 Result, _>
+ let vec = decode(s).ok()?;
+```
+
+[`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html) 函式傳回 `Result, FromHexError>`。 [`Result`](https://doc.rust-lang.org/std/result/) 類型可以包含成功結果(`Ok(value)`)或錯誤(`Err(error)`)。
+
+`.ok()` 方法會將 `Result` 轉換為 `Option`,其值若成功則為 `Ok()` 值,否則為 `None`。 最後,[問號運算子](https://doc.rust-lang.org/std/option/#the-question-mark-operator-) 會在 `Option` 為空時中止目前的函式並傳回 `None`。 否則,它會解開值並傳回它(在此情況下,是將值指派給 `vec`)。
+
+這看起來像是一種處理錯誤的奇怪複雜方法,但 `Result` 和 `Option` 確保所有錯誤都以某種方式處理。
+
+```rust
+ if vec.len() != N { return None; }
+```
+
+如果位元組數不正確,那就是失敗,我們會傳回 `None`。
+
+```rust
+ // try_into 會耗用 vec 並嘗試建立 [u8; N]
+ let array: [u8; N] = vec.try_into().ok()?;
+```
+
+Rust 有兩種陣列類型。 [陣列](https://doc.rust-lang.org/std/primitive.array.html) 的大小固定。 [向量](https://doc.rust-lang.org/std/vec/index.html) 可以增長和縮小。 `hex::decode` 傳回一個向量,但 `eth_stealth_addresses` 程式庫想要接收陣列。 [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods) 會將一個值轉換成另一種型別,例如,將向量轉換成陣列。
+
+```rust
+ Some(array)
+}
+```
+
+在函式結尾傳回值時,Rust 不要求您使用 [`return`](https://doc.rust-lang.org/std/keyword.return.html) 關鍵字。
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option {
+```
+
+此函式接收一個公用中繼地址,其中包含 _Vpub_ 和 _Kpub_。 它會傳回隱匿地址、要發布的公鑰(_Rpub_),以及一個一位元組的掃描值,用於加速識別哪些已發布的地址可能屬於 Alice。
+
+掃描值是共享密鑰(_S = GRprivVpriv_)的一部分。 此值可供 Alice 使用,檢查此值比檢查 _f(Kpub+G\*hash(S))_ 是否等於已發布地址快得多。
+
+```rust
+ let (address, r_pub, scan) =
+ generate_stealth_address(&str_to_array::<66>(stealth_address)?);
+```
+
+我們使用程式庫的 [`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html)。
+
+```rust
+ format!("{{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}}",
+ encode(address),
+ encode(r_pub),
+ encode(&[scan])
+ ).into()
+}
+```
+
+準備 JSON 編碼的輸出字串。
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_compute_stealth_key(
+ address: &str,
+ bill_pub_key: &str,
+ view_private_key: &str,
+ spend_private_key: &str
+) -> Option {
+ .
+ .
+ .
+}
+```
+
+此函式使用程式庫的 [`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html) 來計算從地址提款的私鑰 (_Rpriv_)。 此計算需要以下值:
+
+- 地址(_Address=f(Ppub)_)
+- Bill 產生的公鑰(_Rpub_)
+- 檢視私鑰(_Vpriv_)
+- 花費私鑰(_Kpriv_)
+
+```rust
+#[wasm_bindgen(start)]
+```
+
+[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html) 指定函式在 WASM 程式碼初始化時執行。
+
+```rust
+pub fn main() {
+ console_error_panic_hook::set_once();
+}
+```
+
+此程式碼指定將恐慌輸出傳送到 JavaScript 主機。 要看它實際運作,請使用應用程式並給 Bill 一個無效的中繼地址(只要更改一個十六進位數字)。 您會在 JavaScript 主機中看到此錯誤:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9:
+assertion `left == right` failed
+ left: 0
+ right: 1
+```
+
+後面跟著堆疊追蹤。 然後給 Bill 有效的中繼地址,並給 Alice 一個無效的地址或無效的公鑰。 您將會看到此錯誤:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9:
+keys do not generate stealth address
+```
+
+同樣地,後面跟著堆疊追蹤。
+
+#### 使用者介面 {#ui}
+
+使用者介面是使用 [React](https://react.dev/) 編寫並由 [Vite](https://vite.dev/) 提供服務。 您可以使用[此教學](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)來瞭解它們。 這裡不需要 [WAGMI](https://wagmi.sh/),因為我們不直接與區塊鏈或錢包互動。
+
+使用者介面唯一不那麼明顯的部分是 WASM 的連線能力。 其運作方式如下。
+
+**`vite.config.js`**
+
+此檔案包含 [Vite 設定](https://vite.dev/config/)。
+
+```js
+import { defineConfig } from 'vite'
+import react from '@vitejs/plugin-react'
+import wasm from "vite-plugin-wasm";
+
+// https://vite.dev/config/
+export default defineConfig({
+ plugins: [react(), wasm()],
+})
+```
+
+我們需要兩個 Vite 外掛程式:[react](https://www.npmjs.com/package/@vitejs/plugin-react) 和 [wasm](https://github.com/Menci/vite-plugin-wasm#readme)。
+
+**`App.jsx`**
+
+此檔案是應用程式的主要元件。 它是一個容器,包含兩個元件:`Alice` 和 `Bill`,也就是這些使用者的使用者介面。 與 WASM 相關的部分是初始化程式碼。
+
+```jsx
+import init from './rust-wasm/pkg/rust_wasm.js'
+```
+
+當我們使用 [`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/) 時,它會建立我們在此處使用的兩個檔案:一個包含實際程式碼的 wasm 檔(此處為 `src/rust-wasm/pkg/rust_wasm_bg.wasm`),以及一個包含使用定義的 JavaScript 檔(此處為 `src/rust_wasm/pkg/rust_wasm.js`)。 該 JavaScript 檔案的預設匯出是啟動 WASM 所需執行的程式碼。
+
+```jsx
+function App() {
+ .
+ .
+ .
+ useEffect(() => {
+ const loadWasm = async () => {
+ try {
+ await init();
+ setWasmReady(true)
+ } catch (err) {
+ console.error('Error loading wasm:', err)
+ alert("Wasm error: " + err)
+ }
+ }
+
+ loadWasm()
+ }, []
+ )
+```
+
+[`useEffect` 鉤子](https://react.dev/reference/react/useEffect) 可讓您指定一個函式,該函式會在狀態變數變更時執行。 在此,狀態變數清單是空的(`[]`),所以此函式只會在頁面載入時執行一次。
+
+效果函式必須立即傳回。 要使用非同步程式碼,例如 WASM `init`(必須載入 `.wasm` 檔,因此需要時間),我們定義一個內部 [`async`](https://en.wikipedia.org/wiki/Async/await) 函式,並在沒有 `await` 的情況下執行它。
+
+**`Bill.jsx`**
+
+這是 Bill 的使用者介面。 它只有一個動作,就是根據 Alice 提供的隱匿中繼地址建立一個地址。
+
+```jsx
+import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js'
+```
+
+除了預設匯出之外,`wasm-pack` 產生的 JavaScript 程式碼還會為 WASM 程式碼中的每個函式匯出一個函式。
+
+```jsx
+
{status}
-
+
)
```
diff --git a/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
index ef75f354e68..fd61f0a6c26 100644
--- a/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
@@ -1,7 +1,7 @@
---
title: "Optimism 標準跨鏈橋合約深入解析"
-description: Optimism 的標準跨鏈橋如何運作? 為什麼它會這樣運作?
-author: 作者:Ori Pomerantz
+description: "Optimism 的標準跨鏈橋如何運作? 為什麼它會這樣運作?"
+author: "作者:Ori Pomerantz"
tags: [ "穩固", "跨鏈橋", "Layer 2" ]
skill: intermediate
published: 2022-03-30
diff --git a/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
index 6981499a493..d3a33f49c02 100644
--- a/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
@@ -1,7 +1,7 @@
---
title: "對合約進行逆向工程"
-description: 如何在沒有原始碼的情況下理解合約
-author: 作者:Ori Pomerantz
+description: "如何在沒有原始碼的情況下理解合約"
+author: "作者:Ori Pomerantz"
lang: zh-tw
tags: [ "evm", "opcodes" ]
skill: advanced
diff --git a/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
index d54d2c08c4b..6f5607db4ea 100644
--- a/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
@@ -1,12 +1,12 @@
---
-title: 在 Raspberry Pi 4 上執行一個以太坊節點
-description: 為您的 Raspberry Pi 4 刷機、插入乙太網路線、連接 SSD 硬碟並開啟裝置電源,即可將 Raspberry Pi 4 變成一個完整的以太坊節點 + 驗證程式
+title: "在 Raspberry Pi 4 上執行一個以太坊節點"
+description: "為您的 Raspberry Pi 4 刷機、插入乙太網路線、連接 SSD 硬碟並開啟裝置電源,即可將 Raspberry Pi 4 變成一個完整的以太坊節點 + 驗證程式"
author: "EthereumOnArm"
tags: [ "用戶端", "執行層", "共識層", "節點" ]
lang: zh-tw
skill: intermediate
published: 2022-06-10
-source: ARM 上的以太坊
+source: "ARM 上的以太坊"
sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
index f54c09d342e..647fed85608 100644
--- a/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
@@ -1,7 +1,7 @@
---
title: "詐騙代幣使用的一些伎倆以及如何偵測它們"
-description: 在本使用教學中,我們將剖析一個詐騙代幣,以了解詐騙者所玩的伎倆、他們如何實作這些伎倆,以及我們該如何偵測它們。
-author: 作者:Ori Pomerantz
+description: "在本使用教學中,我們將剖析一個詐騙代幣,以了解詐騙者所玩的伎倆、他們如何實作這些伎倆,以及我們該如何偵測它們。"
+author: "作者:Ori Pomerantz"
tags:
[
"詐騙",
diff --git a/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md b/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
index 6449579bd1c..4b9dbe17091 100644
--- a/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
@@ -1,7 +1,7 @@
---
-title: 使用零知識證明建立秘密狀態
-description: 鏈上遊戲有所限制,因為它們無法保存任何隱藏資訊。 閱讀本教學課程後,讀者將能夠結合零知識證明和伺服器元件,建立具有秘密狀態、鏈下元件的可驗證遊戲。 我們將透過建立踩地雷遊戲來示範此技術。
-author: 作者:Ori Pomerantz
+title: "使用零知識證明建立秘密狀態"
+description: "鏈上遊戲有所限制,因為它們無法保存任何隱藏資訊。 閱讀本教學課程後,讀者將能夠結合零知識證明和伺服器元件,建立具有秘密狀態、鏈下元件的可驗證遊戲。 我們將透過建立踩地雷遊戲來示範此技術。"
+author: "作者:Ori Pomerantz"
tags: [ "伺服器", "鏈下", "中心化", "零知識", "zokrates", "mud" ]
skill: advanced
lang: zh-tw
diff --git a/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
index 21c5c33d1eb..103f3af5663 100644
--- a/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
@@ -1,12 +1,12 @@
---
-title: 智慧型合約安全列清單
-description: 一推薦程序來編輯安全智慧型合約
+title: "智慧型合約安全列清單"
+description: "一推薦程序來編輯安全智慧型合約"
author: "Trailofbits"
tags: [ "智能合約", "安全性", "solidity" ]
skill: intermediate
lang: zh-tw
published: 2020-09-07
-source: 建立安全合約
+source: "建立安全合約"
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md
index baa289afffe..969bbd6ac91 100644
--- a/public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/send-token-ethersjs/index.md
@@ -1,6 +1,6 @@
---
-title: 使用 ethers.js 傳送代幣
-description: 使用 ethers.js 傳送代幣的初學者指南。
+title: "使用 ethers.js 傳送代幣"
+description: "使用 ethers.js 傳送代幣的初學者指南。"
author: Kim YongJun
tags: [ "ETHERS.JS", "ERC-20", "代幣" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
index 0e6e11c2bf4..445f03bdd52 100644
--- a/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -1,5 +1,5 @@
---
-title: 使用 Web3 發送交易
+title: "使用 Web3 發送交易"
description: "這是一份初學者友善指南,說明如何使用 Web3 發送以太坊交易。 將交易發送到以太坊區塊鏈有三個主要步驟:建立、簽署和廣播。 我們將會逐一說明。"
author: "Elan Halpern"
tags: [ "交易", "web3.js", "alchemy" ]
diff --git a/public/content/translations/zh-tw/developers/tutorials/server-components/index.md b/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
index e41620fa10a..3f34c1ad0cf 100644
--- a/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
@@ -1,8 +1,8 @@
---
title: "Web3 應用程式的伺服器元件和代理"
-description: 閱讀本教學後,您將能編寫 TypeScript 伺服器,以偵聽區塊鏈上的事件,並透過自己的交易做出相應的回應。 這將讓您能夠編寫中心化應用程式(因為伺服器是一個故障點),但可以與 Web3 實體互動。 同樣的技術也可以用來編寫一個無需人工干預即可回應鏈上事件的代理。
+description: "閱讀本教學後,您將能編寫 TypeScript 伺服器,以偵聽區塊鏈上的事件,並透過自己的交易做出相應的回應。 這將讓您能夠編寫中心化應用程式(因為伺服器是一個故障點),但可以與 Web3 實體互動。 同樣的技術也可以用來編寫一個無需人工干預即可回應鏈上事件的代理。"
-author: 作者:Ori Pomerantz
+author: "作者:Ori Pomerantz"
lang: zh-tw
tags: [ "代理", "伺服器", "鏈下" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md b/public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
index 401d2bb2ba0..d7e55910151 100644
--- a/public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
@@ -1,6 +1,6 @@
---
-title: 在 JavaScript 中設定 web3.js 以使用以太坊區塊鏈
-description: 了解如何設定與配置 web3.js 函式庫,以便從 JavaScript 應用程式與以太坊區塊鏈互動。
+title: "在 JavaScript 中設定 web3.js 以使用以太坊區塊鏈"
+description: "了解如何設定與配置 web3.js 函式庫,以便從 JavaScript 應用程式與以太坊區塊鏈互動。"
author: "jdourlens"
tags: [ "web3.js", "javascript" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md b/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
index 8c907290c51..28471e95d45 100644
--- a/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
@@ -1,7 +1,7 @@
---
title: "為優化 Calldata 而設的精簡 ABI"
-description: 為樂觀卷軸優化智能合約
-author: 作者:Ori Pomerantz
+description: "為樂觀卷軸優化智能合約"
+author: "作者:Ori Pomerantz"
lang: zh-tw
tags: [ "Layer 2" ]
skill: intermediate
diff --git a/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
index 67f09f56285..c3c29ad2ac4 100644
--- a/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
@@ -1,12 +1,12 @@
---
-title: 智慧型合約安全指南
-description: 一安全指南列表來介紹如何考慮安全當建立你個人Dapp
+title: "智慧型合約安全指南"
+description: "一安全指南列表來介紹如何考慮安全當建立你個人Dapp"
author: "Trailofbits"
tags: [ "穩固", "智能合約", "安全性" ]
skill: intermediate
lang: zh-tw
published: 2020-09-06
-source: 建立安全合約
+source: "建立安全合約"
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md b/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
index 1c61cf80c2a..0e51ff00fd4 100644
--- a/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
@@ -1,7 +1,7 @@
---
title: "使用隱匿地址"
description: "隱匿地址讓使用者能夠匿名轉移資產。 閱讀本文後,您將能夠:解釋什麼是隱匿地址及其運作方式、瞭解如何以維護匿名性的方式使用隱匿地址,以及編寫使用隱匿地址的網頁應用程式。"
-author: 作者:Ori Pomerantz
+author: "作者:Ori Pomerantz"
tags: [ "隱匿地址", "隱私", "密碼學", "rust", "wasm" ]
skill: intermediate
published: 2025-11-30
diff --git a/public/content/translations/zh-tw/developers/tutorials/the-graph-fixing-web3-data-querying/index.md b/public/content/translations/zh-tw/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
index 7570c18a995..16564fba5c3 100644
--- a/public/content/translations/zh-tw/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
@@ -1,6 +1,6 @@
---
title: "The Graph:解決 Web3 資料查詢的問題"
-description: 區塊鏈就像一個資料庫,但沒有 SQL。 所有資料都在那裡,但卻沒有方法可以存取。 讓我為您示範如何使用 The Graph 和 GraphQL 解決這個問題。
+description: "區塊鏈就像一個資料庫,但沒有 SQL。 所有資料都在那裡,但卻沒有方法可以存取。 讓我為您示範如何使用 The Graph 和 GraphQL 解決這個問題。"
author: Markus Waas
lang: zh-tw
tags: [ "穩固", "智能合約", "諮詢", "the graph", "反應" ]
diff --git a/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md
index 2693ce01b06..579284f2a5c 100644
--- a/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md
@@ -1,12 +1,12 @@
---
-title: 代幣整合清單
-description: 與代幣互動時應考量的事項清單
+title: "代幣整合清單"
+description: "與代幣互動時應考量的事項清單"
author: "Trailofbits"
lang: zh-tw
tags: [ "穩固", "智能合約", "安全性", "代幣" ]
skill: intermediate
published: 2020-08-13
-source: 建立安全合約
+source: "建立安全合約"
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
index 50466ee2ac1..6d49a1b42cc 100644
--- a/public/content/translations/zh-tw/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
@@ -1,6 +1,6 @@
---
-title: 透過 Solidity 智能合約轉帳和核准 ERC-20 代幣
-description: 使用 Solidity 建立一個 DEX 智能合約,用於處理 ERC-20 代幣轉帳和核准。
+title: "透過 Solidity 智能合約轉帳和核准 ERC-20 代幣"
+description: "使用 Solidity 建立一個 DEX 智能合約,用於處理 ERC-20 代幣轉帳和核准。"
author: "jdourlens"
tags: [ "智能合約", "代幣", "穩固", "erc-20" ]
skill: intermediate
diff --git a/public/content/translations/zh-tw/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
index 98c361c9935..f887345245e 100644
--- a/public/content/translations/zh-tw/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
@@ -1,6 +1,6 @@
---
-title: 了解 ERC-20 代幣智能合約
-description: 透過完整的 Solidity 智能合約範例和說明,學習如何實作 ERC-20 代幣標準。
+title: "了解 ERC-20 代幣智能合約"
+description: "透過完整的 Solidity 智能合約範例和說明,學習如何實作 ERC-20 代幣標準。"
author: "jdourlens"
tags: [ "智能合約", "代幣", "穩固", "erc-20" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md
index 25655fa9e65..7e23de2b9a1 100644
--- a/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md
@@ -1,7 +1,7 @@
---
title: "Uniswap-v2 合約逐步詳解"
-description: Uniswap-v2 合約如何運作? 為何要這樣編寫?
-author: 作者:Ori Pomerantz
+description: "Uniswap-v2 合約如何運作? 為何要這樣編寫?"
+author: "作者:Ori Pomerantz"
tags: [ "穩固" ]
skill: intermediate
published: 2021-05-01
diff --git a/public/content/translations/zh-tw/developers/tutorials/using-websockets/index.md b/public/content/translations/zh-tw/developers/tutorials/using-websockets/index.md
index c9d7fc752eb..6e187b7912a 100644
--- a/public/content/translations/zh-tw/developers/tutorials/using-websockets/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/using-websockets/index.md
@@ -1,6 +1,6 @@
---
-title: 使用WebSockets
-description: 利用WebSockets 及 Alchemy提交一JSON-RPC要求和事件訂閱之簡介.
+title: "使用WebSockets"
+description: "利用WebSockets 及 Alchemy提交一JSON-RPC要求和事件訂閱之簡介."
author: "Elan Halpern"
lang: zh-tw
tags: [ "alchemy", "websockets", "諮詢", "javascript" ]
diff --git a/public/content/translations/zh-tw/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md b/public/content/translations/zh-tw/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
index ae4d381117d..170b7c06bd6 100644
--- a/public/content/translations/zh-tw/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
@@ -1,6 +1,6 @@
---
title: "Waffle:動態模擬與測試合約呼叫"
-description: 使用動態模擬與測試合約呼叫的進階 Waffle 教學
+description: "使用動態模擬與測試合約呼叫的進階 Waffle 教學"
author: "Daniel Izdebski"
tags: [ "waffle", "智能合約", "穩固", "測試", "模擬" ]
skill: intermediate
diff --git a/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md b/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
index df83a6a81cf..1ff7bfae139 100644
--- a/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
@@ -1,6 +1,6 @@
---
title: "使用 hardhat 和 ethers 的 Waffle hello world 教學"
-description: 使用 hardhat 和 ethers.js 建立您的第一個 Waffle 專案
+description: "使用 hardhat 和 ethers.js 建立您的第一個 Waffle 專案"
author: "MiZiet"
tags:
[
diff --git a/public/content/translations/zh-tw/developers/tutorials/waffle-test-simple-smart-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/waffle-test-simple-smart-contract/index.md
index 40e853f6e65..b3974337fbb 100644
--- a/public/content/translations/zh-tw/developers/tutorials/waffle-test-simple-smart-contract/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/waffle-test-simple-smart-contract/index.md
@@ -1,6 +1,6 @@
---
-title: 使用 Waffle 程式庫測試簡單的智能合約
-description: 初學者教學
+title: "使用 Waffle 程式庫測試簡單的智能合約"
+description: "初學者教學"
author: Ewa Kowalska
tags: [ "智能合約", "穩固", "Waffle", "測試" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/yellow-paper-evm/index.md b/public/content/translations/zh-tw/developers/tutorials/yellow-paper-evm/index.md
index 073ac81f1cc..d9e03b84ffa 100644
--- a/public/content/translations/zh-tw/developers/tutorials/yellow-paper-evm/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/yellow-paper-evm/index.md
@@ -1,6 +1,6 @@
---
-title: 了解黃皮書的 EVM 規範
-description: 了解黃皮書中說明以太坊虛擬機 (EVM) 的部分,黃皮書是以太坊的正式規範。
+title: "了解黃皮書的 EVM 規範"
+description: "了解黃皮書中說明以太坊虛擬機 (EVM) 的部分,黃皮書是以太坊的正式規範。"
author: "qbzzt"
tags: [ "evm" ]
skill: intermediate
diff --git a/public/content/translations/zh-tw/eips/index.md b/public/content/translations/zh-tw/eips/index.md
index 03864a71a60..a06fd5ba315 100644
--- a/public/content/translations/zh-tw/eips/index.md
+++ b/public/content/translations/zh-tw/eips/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊改進提案 (EIP)
-description: 你需要知道的以太坊改進提案基本知識
+title: "以太坊改進提案 (EIP)"
+description: "你需要知道的以太坊改進提案基本知識"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/energy-consumption/index.md b/public/content/translations/zh-tw/energy-consumption/index.md
index 151af275981..2adcb887949 100644
--- a/public/content/translations/zh-tw/energy-consumption/index.md
+++ b/public/content/translations/zh-tw/energy-consumption/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊能耗
-description: 了解以太坊能耗時的必要基本資訊。
+title: "以太坊能耗"
+description: "了解以太坊能耗時的必要基本資訊。"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/eth/supply/index.md b/public/content/translations/zh-tw/eth/supply/index.md
index 48cf8853f1f..30933fc6674 100644
--- a/public/content/translations/zh-tw/eth/supply/index.md
+++ b/public/content/translations/zh-tw/eth/supply/index.md
@@ -1,6 +1,6 @@
---
-title: 了解以太幣供給和發行
-description: 適合初學者的以太幣供給和發行指南,涵蓋像是以太坊改善提議、權益證明,和 EIP-1559 等的關鍵概念。
+title: "了解以太幣供給和發行"
+description: "適合初學者的以太幣供給和發行指南,涵蓋像是以太坊改善提議、權益證明,和 EIP-1559 等的關鍵概念。"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/ethereum-forks/index.md b/public/content/translations/zh-tw/ethereum-forks/index.md
index dad33fcb7b9..a125cf2b11c 100644
--- a/public/content/translations/zh-tw/ethereum-forks/index.md
+++ b/public/content/translations/zh-tw/ethereum-forks/index.md
@@ -1,6 +1,6 @@
---
-title: 所有以太坊分叉的時間軸 (2014 年至今)
-description: 以太坊區塊鏈的歷史,包含主要里程碑、更新及分叉。
+title: "所有以太坊分叉的時間軸 (2014 年至今)"
+description: "以太坊區塊鏈的歷史,包含主要里程碑、更新及分叉。"
lang: zh-tw
sidebarDepth: 1
---
@@ -16,7 +16,6 @@ sidebarDepth: 1
需要升級集中控制的傳統軟體時,公司只會為終端使用者發佈一個新版本。 而區塊鏈的運作則有所不同,因其並無所謂的集中所有權。 [以太坊用戶](/developers/docs/nodes-and-clients/) 其所有必須全部升級其軟體來更新至新分叉規則. 加上區塊生成者(在工作量證明世界中為礦工,在權益證明世界中為驗證者)和節點必須依據新規則生成區塊並作驗證。 [更多關於共識機制](/developers/docs/consensus-mechanisms/)
這些規則變更可能會在網路上造成暫時的分叉。 新區塊可以依據新規則或舊規則產生。 分叉通常會提前商定,以便用戶端能夠一致採用變更,並使升級後的分叉成為主鏈。 然而,在極少數情況下,對分叉的不同意見可能導致網路永久硬分叉 – 最爲著名的是去中心化自治組織分叉產生了以太坊經典。
-
@@ -62,7 +61,6 @@ sidebarDepth: 1
| Cancun | Deneb | 「Dencun」 |
| Prague | Electra | 「Pectra」 |
| Osaka | Fulu | 「Fusaka」 |
-
直接跳到一些特別重要的過去升級的資訊:[信標鏈](/roadmap/beacon-chain/)、[合併](/roadmap/merge/) 和 [EIP-1559](#london)
@@ -116,7 +114,6 @@ Prague-Electra(“Pectra”)升級包括對以太坊協議的幾項改進,
EIP-2935 - 在狀態中保存歷史區塊哈希
EIP-7549 - 將委員會索引移除出證明
-
- [Pectra.wtf](https://pectra.wtf)
@@ -148,7 +145,6 @@ Cancun 升級包含一組針對以太坊_執行層_的改進,旨在與 Deneb
EIP-6780 - SELFDESTRUCT 只能存在於相同交易中
EIP-7516 - BLOBBASEFEE 操作碼
-
- [Layer 2 卷軸](/layer-2/)
@@ -173,7 +169,6 @@ EIP-7514 將驗證者加入網路的「流失」率限制在每個時期八 (8)
EIP-7045 - 增加最大證明納入時隙
EIP-7514 - 加入最大時期流失限制
-
- [閱讀 Deneb 升級規範](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
@@ -200,7 +195,6 @@ EIP-7514 將驗證者加入網路的「流失」率限制在每個時期八 (8)
EIP-4895 – 信標鏈推送提款操作
EIP-6049 - 棄用 SELFDESTRUCT
-
- [閱讀 Shanghai 升級規範](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
@@ -237,7 +231,6 @@ Paris 升級是由於工作量證明區塊鏈通過了 58750000000000000000000
EIP-3675 – 將共識層升級為權益證明
EIP-4399 – 以 PREVRANDAO 取代 DIFFICULTY 操作碼
-
---
@@ -269,7 +262,6 @@ Gray Glacier 網路升級將[難度炸彈](/glossary/#difficulty-bomb)推遲了
-
@@ -292,7 +284,6 @@ Arrow Glacier 網路升級將[難度炸彈](/glossary/#difficulty-bomb)推遲了
-
---
@@ -350,7 +341,6 @@ London 升級前,以太坊的區塊為固定大小。 當網路需求高時,
EIP-3541 - 防止部署以 0xEF 開頭的合約
EIP-3554 – 將冰河期延遲至 2021 年 12 月
-
---
@@ -374,7 +364,6 @@ London 升級前,以太坊的區塊為固定大小。 當網路需求高時,
EIP-2929 – 增加狀態存取操作碼的燃料成本
EIP-2930 – 新增可選存取清單
-
@@ -429,7 +418,6 @@ Muir Glacier 分叉延遲了[難度炸彈](/glossary/#difficulty-bomb)。 [工
- EIP-2384 – 將難度炸彈再推遲 4,000,000 個區塊,或約 611 天。
-
@@ -462,7 +450,6 @@ Muir Glacier 分叉延遲了[難度炸彈](/glossary/#difficulty-bomb)。 [工
EIP-2028 – 降低了 CallData 的成本,從而允許更多資料放入區塊中 – 這對 [二層網路擴容](/developers/docs/scaling/#layer-2-scaling)很有幫助。
EIP-2200 – 其他操作碼的燃料價格變更。
-
---
@@ -490,7 +477,6 @@ Muir Glacier 分叉延遲了[難度炸彈](/glossary/#difficulty-bomb)。 [工
EIP-1052 – 引入 EXTCODEHASH 指令來擷取其他合約程式碼的雜湊值。
EIP-1234 – 確保在權益證明之前,區塊鏈不會凍結,並將區塊獎勵從 3 以太幣減少至 2 以太幣。
-
@@ -525,7 +511,6 @@ Muir Glacier 分叉延遲了[難度炸彈](/glossary/#difficulty-bomb)。 [工
EIP-100 – 變更難度調整公式。
EIP-649 – 將[難度炸彈](/glossary/#difficulty-bomb)延遲 1 年,並將區塊獎勵從 5 以太幣減至 3 以太幣。
-
@@ -554,7 +539,6 @@ Spurious Dragon 分叉為對阻斷服務 (DoS) 攻擊(2016 年 9 月/10 月)
EIP-161 – 允許刪除透過阻斷服務攻擊產生的空帳戶。
EIP-170 – 將區塊鏈上合約可達到的最大程式碼大小改為 24576 位元組。
-
---
@@ -577,7 +561,6 @@ Spurious Dragon 分叉為對阻斷服務 (DoS) 攻擊(2016 年 9 月/10 月)
EIP-150 – 增加可用於垃圾郵件攻擊的操作碼的燃料成本
EIP-158 – 透過刪除大量空帳戶來減少狀態大小,這些空帳戶由於早期版本的以太坊協定中的缺陷而以非常低的成本置於狀態中。
-
---
@@ -615,7 +598,6 @@ DAO 分叉是為了因應 [2016 年 DAO 攻擊](https://www.coindesk.com/learn/u
EIP-7 – 新增操作碼:DELEGATECALL
EIP-8 – 引入 devp2p 正向相容性要求
-
diff --git a/public/content/translations/zh-tw/foundation/index.md b/public/content/translations/zh-tw/foundation/index.md
index b1e8ba551b5..e5a0dbda9ec 100644
--- a/public/content/translations/zh-tw/foundation/index.md
+++ b/public/content/translations/zh-tw/foundation/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊基金會
-description: 了解更多關於以太坊基金會 (EF) 的資訊,這是一個致力於支持以太坊及相關技術的非營利組織。
+title: "以太坊基金會"
+description: "了解更多關於以太坊基金會 (EF) 的資訊,這是一個致力於支持以太坊及相關技術的非營利組織。"
hideEditButton: true
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/gaming/index.md b/public/content/translations/zh-tw/gaming/index.md
index ac764892eaa..17cce7bddc7 100644
--- a/public/content/translations/zh-tw/gaming/index.md
+++ b/public/content/translations/zh-tw/gaming/index.md
@@ -1,12 +1,12 @@
---
-title: 鏈上遊戲
+title: "鏈上遊戲"
lang: zh-tw
template: use-cases
image: /images/robot-help-bar.png
sidebarDepth: 2
-summaryPoint1: 遊戲規則與狀態可由區塊鏈強制執行,而非遊戲工作室的伺服器
-summaryPoint2: 任何人都能建立模組、機器人,或利用相同的鏈上資料,打造全新的遊戲。
-summaryPoint3: 專為特定目的打造的 L2 (例如 Redstone) 和框架 (例如 MUD) 可大幅降低成本,足以支援即時遊戲。
+summaryPoint1: "遊戲規則與狀態可由區塊鏈強制執行,而非遊戲工作室的伺服器"
+summaryPoint2: "任何人都能建立模組、機器人,或利用相同的鏈上資料,打造全新的遊戲。"
+summaryPoint3: "專為特定目的打造的 L2 (例如 Redstone) 和框架 (例如 MUD) 可大幅降低成本,足以支援即時遊戲。"
buttons:
- content: 瞭解更多
toId: how-gaming-on-ethereum-works
diff --git a/public/content/translations/zh-tw/glossary/index.md b/public/content/translations/zh-tw/glossary/index.md
index 9d6c783379c..0ce0299b820 100644
--- a/public/content/translations/zh-tw/glossary/index.md
+++ b/public/content/translations/zh-tw/glossary/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊詞彙表
-description: 與以太坊相關的技術和非技術術語的不完整詞彙表
+title: "以太坊詞彙表"
+description: "與以太坊相關的技術和非技術術語的不完整詞彙表"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/governance/index.md b/public/content/translations/zh-tw/governance/index.md
index 47377946fdb..7f3bfa0cbe9 100644
--- a/public/content/translations/zh-tw/governance/index.md
+++ b/public/content/translations/zh-tw/governance/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊管理體系
-description: 以太坊決策方式的簡介。
+title: "以太坊管理體系"
+description: "以太坊決策方式的簡介。"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md
index 9c444a17605..679568fa83b 100644
--- a/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md
@@ -1,6 +1,6 @@
---
-title: 如何「建立」以太坊帳戶
-description: 使用錢包建立以太坊帳戶的逐步指南。
+title: "如何「建立」以太坊帳戶"
+description: "使用錢包建立以太坊帳戶的逐步指南。"
lang: zh-tw
---
@@ -42,7 +42,8 @@ lang: zh-tw
- 錢包安裝好了嗎?
了解如何使用。
+ 錢包安裝好了嗎?
了解如何使用。
+
如何使用錢包
diff --git a/public/content/translations/zh-tw/guides/how-to-id-scam-tokens/index.md b/public/content/translations/zh-tw/guides/how-to-id-scam-tokens/index.md
index b9ba1e0e19c..3f0e5eff033 100644
--- a/public/content/translations/zh-tw/guides/how-to-id-scam-tokens/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-id-scam-tokens/index.md
@@ -1,6 +1,6 @@
---
-title: 如何辨識詐騙代幣
-description: 了解詐騙代幣、它們如何使自己看似合法,以及如何避開這種詐騙方式。
+title: "如何辨識詐騙代幣"
+description: "了解詐騙代幣、它們如何使自己看似合法,以及如何避開這種詐騙方式。"
lang: zh-tw
---
@@ -20,7 +20,6 @@ title="什麼是 ARB?"
contentPreview=''>
Arbitrum 是一個開發和管理[樂觀型Rollup](/developers/docs/scaling/optimistic-rollups/)的組織。 成立之初,Aubitrum 是一間營利公司,而後採取了去中心化的措施。 在這個過程中,他們發行了可交易的[治理代幣](/dao/#token-based-membership)。
-
以太坊有一個慣例,當一種資產不兼容 ERC-20 時,我們會創建一種「打包」版本,名稱以「w」起頭。 因此,舉例來說,比特幣有 wBTC,而以太幣有 wETH。
創建以太坊已有的 ERC-20 代幣的打包版本並不合理,但詐騙代幣看似正規,實際並非如此。
-
## 詐騙代幣如何運作? {#how-do-scam-tokens-work}
@@ -42,7 +40,6 @@ title="什麼是智慧型合約?"
contentPreview=''>
[智能合約](/developers/docs/smart-contracts/)是運行在以太坊區塊鏈上的程式。 例如,每個 ERC-20 代幣都以智慧型合約的形式實施。
-
具體來說,Arbitrum 部署了一個使用 `ARB` 符號的合約。 但這並不能阻止其他人也部署使用完全相同或類似符號的合約。 寫合約的人可以設定合約如何執行。
diff --git a/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md b/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md
index 1f9faebef5c..38717e212e6 100644
--- a/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md
@@ -1,6 +1,6 @@
---
-title: 如何撤銷授權智慧型合約與你的加密資產互動
-description: 關於如何撤銷授權智慧型合約代幣存取權的指南
+title: "如何撤銷授權智慧型合約與你的加密資產互動"
+description: "關於如何撤銷授權智慧型合約代幣存取權的指南"
lang: zh-tw
---
@@ -49,7 +49,8 @@ lang: zh-tw
- 想瞭解更多嗎?
+ 想瞭解更多嗎?
+
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md b/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md
index abc193a70de..7f57848252f 100644
--- a/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md
@@ -1,6 +1,6 @@
---
-title: 如何兌換代幣
-description: 關於如何在以太坊兌換代幣的指南。
+title: "如何兌換代幣"
+description: "關於如何在以太坊兌換代幣的指南。"
lang: zh-tw
---
@@ -52,7 +52,8 @@ lang: zh-tw
- 想瞭解更多嗎?
+ 想瞭解更多嗎?
+
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md b/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md
index 3292b8df834..fa7aa062da8 100644
--- a/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md
@@ -1,6 +1,6 @@
---
-title: 如何通過跨鏈橋將代幣轉移至二層網路
-description: 關於如何使用跨鏈橋將代幣從以太坊轉移到二層網路的指南。
+title: "如何通過跨鏈橋將代幣轉移至二層網路"
+description: "關於如何使用跨鏈橋將代幣從以太坊轉移到二層網路的指南。"
lang: zh-tw
---
@@ -54,7 +54,8 @@ lang: zh-tw
- 想瞭解更多嗎?
+ 想瞭解更多嗎?
+
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md b/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md
index 576f692c65e..b04cb89b373 100644
--- a/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md
@@ -1,7 +1,7 @@
---
-title: 如何使用錢包
-metaTitle: 如何使用以太坊錢包 | 逐步教學
-description: 關於如何發送、接收代幣和連接到 web3 專案的指南。
+title: "如何使用錢包"
+metaTitle: "如何使用以太坊錢包 | 逐步教學"
+description: "關於如何發送、接收代幣和連接到 web3 專案的指南。"
lang: zh-tw
---
@@ -65,7 +65,8 @@ lang: zh-tw
- 想瞭解更多嗎?
+ 想瞭解更多嗎?
+
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/guides/index.md b/public/content/translations/zh-tw/guides/index.md
index 5ac2a0a53fd..fcaec100696 100644
--- a/public/content/translations/zh-tw/guides/index.md
+++ b/public/content/translations/zh-tw/guides/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊指南
-description: 一組實用指南,向初學者解釋有關使用以太坊的基礎知識。
+title: "以太坊指南"
+description: "一組實用指南,向初學者解釋有關使用以太坊的基礎知識。"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/nft/index.md b/public/content/translations/zh-tw/nft/index.md
index 4ed9598dc5b..e86238244be 100644
--- a/public/content/translations/zh-tw/nft/index.md
+++ b/public/content/translations/zh-tw/nft/index.md
@@ -1,16 +1,16 @@
---
-title: 非同質化代幣 (NFT)
-metaTitle: 什麼是非同質化代幣? | 優點和作用
-description: 以太坊生態系非同質化代幣概要
+title: "非同質化代幣 (NFT)"
+metaTitle: "什麼是非同質化代幣? | 優點和作用"
+description: "以太坊生態系非同質化代幣概要"
lang: zh-tw
template: use-cases
emoji: ":frame_with_picture:"
sidebarDepth: 2
image: /images/infrastructure_transparent.png
-alt: 全息投影顯示的以太幣標誌。
-summaryPoint1: 一種用以太坊資產來呈現任何獨特事物的方式。
-summaryPoint2: 非同質化代幣賦予了內容創作者前所未有的強大力量。
-summaryPoint3: 由建置於以太坊區塊鏈上的智慧型合約提供支援。
+alt: "全息投影顯示的以太幣標誌。"
+summaryPoint1: "一種用以太坊資產來呈現任何獨特事物的方式。"
+summaryPoint2: "非同質化代幣賦予了內容創作者前所未有的強大力量。"
+summaryPoint3: "由建置於以太坊區塊鏈上的智慧型合約提供支援。"
---
## 什麼是非同質化代幣? {#what-are-nfts}
@@ -58,7 +58,8 @@ NFT 是指**各自獨一無二**的代幣。 每個非同質化代幣都有不
- 探索、購買或建立你個人的非同質化代幣藝術品/收藏品……
+ 探索、購買或建立你個人的非同質化代幣藝術品/收藏品……
+
探索 NFT 藝術
diff --git a/public/content/translations/zh-tw/payments/index.md b/public/content/translations/zh-tw/payments/index.md
index 9d1e5daee39..cc8e8670b99 100644
--- a/public/content/translations/zh-tw/payments/index.md
+++ b/public/content/translations/zh-tw/payments/index.md
@@ -1,16 +1,16 @@
---
-title: 以太坊支付
-metaTitle: 以太坊支付
-description: 以太坊支付概要
+title: "以太坊支付"
+metaTitle: "以太坊支付"
+description: "以太坊支付概要"
lang: zh-tw
template: use-cases
emoji: ":frame_with_picture:"
sidebarDepth: 2
image: /images/impact_transparent.png
-alt: 以太坊標誌與給予的手一同展示。
-summaryPoint1: 一個金錢如資訊般自由流通的世界
-summaryPoint2: 開放且全球化,讓所有人實現無國界交易
-summaryPoint3: 一分鐘內收到款項
+alt: "以太坊標誌與給予的手一同展示。"
+summaryPoint1: "一個金錢如資訊般自由流通的世界"
+summaryPoint2: "開放且全球化,讓所有人實現無國界交易"
+summaryPoint3: "一分鐘內收到款項"
---
數百萬人每天面臨同樣的挑戰:跨境轉賬緩慢、昂貴,且經常遇到阻礙。 在峇里島的自由業者需等待多天才能收到紐約客戶的款項。 這由其影響銀行基礎設施有線區域的人們,使他們難以參與國際經濟。
@@ -20,7 +20,6 @@ summaryPoint3: 一分鐘內收到款項

-
## 匯款:更便宜的國際轉帳 {#remittances}
@@ -61,7 +60,8 @@ summaryPoint3: 一分鐘內收到款項
- 使用一個錢包應用程式創建您的以太坊帳號。
+ 使用一個錢包應用程式創建您的以太坊帳號。
+
開始吧
@@ -142,7 +142,6 @@ summaryPoint3: 一分鐘內收到款項

-
## 以太坊 vs 法幣 {#ethereum-vs-fiat}
@@ -189,7 +188,6 @@ summaryPoint3: 一分鐘內收到款項

-
雖然法幣在廣泛接受度和穩定性方面具有優勢,但以太坊的獨特優勢讓其對於某些交易類型是極具吸引力的選擇。
@@ -199,7 +197,8 @@ summaryPoint3: 一分鐘內收到款項
- 是時候擁有自己的以太坊帳戶了。
+ 是時候擁有自己的以太坊帳戶了。
+
開始使用!
diff --git a/public/content/translations/zh-tw/prediction-markets/index.md b/public/content/translations/zh-tw/prediction-markets/index.md
index 1434eb843a5..3f22f7f6506 100644
--- a/public/content/translations/zh-tw/prediction-markets/index.md
+++ b/public/content/translations/zh-tw/prediction-markets/index.md
@@ -1,16 +1,16 @@
---
-title: 預測市場
+title: "預測市場"
lang: zh-tw
template: use-cases
image: /images/use-cases/prediction-markets.png
sidebarDepth: 2
-summaryPoint1: 藉由得到財務的激勵產生正確的預測
-summaryPoint2: 高品質預測未來事件
+summaryPoint1: "藉由得到財務的激勵產生正確的預測"
+summaryPoint2: "高品質預測未來事件"
buttons:
- content: 瞭解更多
- toId: 預測市場如何運作
+ toId: "預測市場如何運作"
- content: 探索 apps
- toId: 尋找預測市場
+ toId: "尋找預測市場"
isSecondary: false
---
diff --git a/public/content/translations/zh-tw/privacy/index.md b/public/content/translations/zh-tw/privacy/index.md
index 2f0f0f8ee0d..365b434b058 100644
--- a/public/content/translations/zh-tw/privacy/index.md
+++ b/public/content/translations/zh-tw/privacy/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊上的隱私
-description: 在以太坊上保護您隱私的工具與技術
+title: "以太坊上的隱私"
+description: "在以太坊上保護您隱私的工具與技術"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/real-world-assets/index.md b/public/content/translations/zh-tw/real-world-assets/index.md
index 905686a1218..4a47ab85bfb 100644
--- a/public/content/translations/zh-tw/real-world-assets/index.md
+++ b/public/content/translations/zh-tw/real-world-assets/index.md
@@ -1,16 +1,16 @@
---
-title: 真實世界資產(RWAs)
-metaTitle: 什麼是真實世界資產(Real-World Assets, RWAs)? 真實世界資產的益處與應用
-description: 以太坊上真實世界資產概覽
+title: "真實世界資產(RWAs)"
+metaTitle: "什麼是真實世界資產(Real-World Assets, RWAs)? 真實世界資產的益處與應用"
+description: "以太坊上真實世界資產概覽"
lang: zh-tw
template: use-cases
emoji: ":house_buildings:"
image: /images/man-and-dog-playing.png
-alt: 男人和狗正在一起玩耍。
+alt: "男人和狗正在一起玩耍。"
sidebarDepth: 2
-summaryPoint1: 將有價值的商品轉換為數位代幣的方法。
-summaryPoint2: 你現在可以擁有現實生活中物體或資產的一部分,而無需購買整個物業或物品。
-summaryPoint3: 將傳統金融與區塊鏈生態系統連接起來。
+summaryPoint1: "將有價值的商品轉換為數位代幣的方法。"
+summaryPoint2: "你現在可以擁有現實生活中物體或資產的一部分,而無需購買整個物業或物品。"
+summaryPoint3: "將傳統金融與區塊鏈生態系統連接起來。"
---
真實世界資產(RWAs)是代表現有財富形式的代幣,例如房地產、黃金、股票、藝術品、機械或收藏品。 將這些資產代幣化會將其轉化為數位形式,允許多個擁有者分割所有權,並使其更容易交易。
diff --git a/public/content/translations/zh-tw/refi/index.md b/public/content/translations/zh-tw/refi/index.md
index 38b550b4df9..4c2bd780482 100644
--- a/public/content/translations/zh-tw/refi/index.md
+++ b/public/content/translations/zh-tw/refi/index.md
@@ -1,15 +1,15 @@
---
-title: 再生金融 (ReFi)
-description: 再生金融概觀及當前使用案例。
+title: "再生金融 (ReFi)"
+description: "再生金融概觀及當前使用案例。"
lang: zh-tw
template: use-cases
emoji: ":recycle:"
sidebarDepth: 2
image: /images/future_transparent.png
alt: ""
-summaryPoint1: 建立在再生原則上的替代性經濟體系
-summaryPoint2: 嘗試使用以太坊解決全球協調危機,如氣候變遷
-summaryPoint3: 可大幅擴展生態效益資產 (如已驗證碳權) 的工具
+summaryPoint1: "建立在再生原則上的替代性經濟體系"
+summaryPoint2: "嘗試使用以太坊解決全球協調危機,如氣候變遷"
+summaryPoint3: "可大幅擴展生態效益資產 (如已驗證碳權) 的工具"
---
## 什麼是再生金融 (ReFi)? {#what-is-refi}
diff --git a/public/content/translations/zh-tw/restaking/index.md b/public/content/translations/zh-tw/restaking/index.md
index 9dbe1a155a1..993424a83a1 100644
--- a/public/content/translations/zh-tw/restaking/index.md
+++ b/public/content/translations/zh-tw/restaking/index.md
@@ -1,14 +1,14 @@
---
-title: 再質押
-metaTitle: 什麼是再質押? | 再質押的好處和用途
-description: 使用已質押的 ETH 保護其他去中心化服務,並賺取額外獎勵。
+title: "再質押"
+metaTitle: "什麼是再質押? | 再質押的好處和用途"
+description: "使用已質押的 ETH 保護其他去中心化服務,並賺取額外獎勵。"
lang: zh-tw
template: use-cases
emoji: ":recycle:"
image: /images/use-cases/restaking.png
-alt: 以太坊上再質押的視覺化呈現。
+alt: "以太坊上再質押的視覺化呈現。"
sidebarDepth: 2
-summaryPoint1: 使用已質押的 ETH 保護其他去中心化服務,並賺取額外獎勵。
+summaryPoint1: "使用已質押的 ETH 保護其他去中心化服務,並賺取額外獎勵。"
buttons:
- content: 什麼是再質押?
toId: what-is-restaking
diff --git a/public/content/translations/zh-tw/roadmap/account-abstraction/index.md b/public/content/translations/zh-tw/roadmap/account-abstraction/index.md
index 581f79f0b3d..7d5d32972b9 100644
--- a/public/content/translations/zh-tw/roadmap/account-abstraction/index.md
+++ b/public/content/translations/zh-tw/roadmap/account-abstraction/index.md
@@ -1,6 +1,6 @@
---
-title: 帳戶摘要
-description: 以太坊讓使用者帳戶更簡潔、更安全的計劃概述
+title: "帳戶摘要"
+description: "以太坊讓使用者帳戶更簡潔、更安全的計劃概述"
lang: zh-tw
summaryPoints:
- 帳戶抽象使得建立智慧型合約錢包變得更加容易
diff --git a/public/content/translations/zh-tw/roadmap/beacon-chain/index.md b/public/content/translations/zh-tw/roadmap/beacon-chain/index.md
index ae96d5658a0..143527fd6bb 100644
--- a/public/content/translations/zh-tw/roadmap/beacon-chain/index.md
+++ b/public/content/translations/zh-tw/roadmap/beacon-chain/index.md
@@ -1,13 +1,13 @@
---
-title: 信標鏈
-description: 瞭解信標鍊 - 將權益證明引入以太坊的升級。
+title: "信標鏈"
+description: "瞭解信標鍊 - 將權益證明引入以太坊的升級。"
lang: zh-tw
template: upgrade
image: /images/upgrades/core.png
alt:
-summaryPoint1: 信標鏈將權益證明引入以太坊生態系統。
-summaryPoint2: 信標鏈於 2022 年 9 月與原先的以太坊工作量證明鏈合併。
-summaryPoint3: 信標鏈引入共識邏輯和區塊廣播協定,現在可保護以太坊安全。
+summaryPoint1: "信標鏈將權益證明引入以太坊生態系統。"
+summaryPoint2: "信標鏈於 2022 年 9 月與原先的以太坊工作量證明鏈合併。"
+summaryPoint3: "信標鏈引入共識邏輯和區塊廣播協定,現在可保護以太坊安全。"
---
@@ -18,8 +18,7 @@ summaryPoint3: 信標鏈引入共識邏輯和區塊廣播協定,現在可保
信標鍊是 2020 年推出的原始權益證明區塊鏈的名稱。 信標鏈的作用是在以太坊主網上啟用權益證明共識邏輯之前,確保它健全且可永續存在。 因此,它與原先的工作量證明以太坊一起運行。 信標鏈是「空」區塊鏈,但在以太坊上,要從工作量證明過渡到權益證明,需要指示信標鏈接受來自執行用戶端的交易資料,將它們打包進區塊,並使用基於權益證明的共識機制,將它們整合成一條區塊鏈。 與此同時,原始的以太坊用戶端關閉挖礦、區塊廣播和共識邏輯,將它們全部交給信標鏈。 這個事件稱為[合併](/roadmap/merge/)。 合併後,即不再有兩條區塊鏈。 相反,只有一個權益證明以太坊,每個節點現在需要兩個不同的用戶端。 信標鏈目前是共識層,是處理區塊廣播和共識邏輯的共識用戶端對等網路,而原始用戶端則形成執行層,負責廣播和執行交易,以及管理以太坊狀態。 這兩個層可以用引擎應用程式介面相互通訊。
-## 信標鏈可以做什麼? 信標鏈可以做什麼? {#what-does-the-beacon-chain-do}
-
+## 信標鏈可以做什麼? {#what-does-the-beacon-chain-do}
信標鏈是帳戶帳本的名稱,在以太坊質押者開始驗證真正的以太坊區塊前,信標鏈會指揮並協調這些質押者。 但它並不處理交易或智慧型合約互動,因為這些事是在執行層完成的。
信標鏈負責區塊和證明處理、執行分叉選擇演算法、管理獎勵和懲罰等事務。
在我們的[節點架構頁面](/developers/docs/nodes-and-clients/node-architecture/#node-comparison)上閱讀更多內容。
diff --git a/public/content/translations/zh-tw/roadmap/danksharding/index.md b/public/content/translations/zh-tw/roadmap/danksharding/index.md
index 8d7872f2da6..849e65d6ee8 100644
--- a/public/content/translations/zh-tw/roadmap/danksharding/index.md
+++ b/public/content/translations/zh-tw/roadmap/danksharding/index.md
@@ -1,6 +1,6 @@
---
title: Danksharding
-description: 瞭解 Proto-Danksharding 和 Danksharding - 兩種依序完成以太坊擴容的升級方案。
+description: "瞭解 Proto-Danksharding 和 Danksharding - 兩種依序完成以太坊擴容的升級方案。"
lang: zh-tw
summaryPoints:
- Danksharding 是一項多階段升級,旨在提升以太坊的可擴容性和容量。
@@ -22,13 +22,11 @@ Proto-Danksharding,也稱為 [EIP-4844](https://eips.ethereum.org/EIPS/eip-484
卷軸是指在鏈下批次處理交易,然後將結果發佈到以太坊以實現以太坊擴容。 卷軸有兩個必要元件:資料與執行檢查。 資料指卷軸處理的完整交易序列,用於產生發佈到以太坊的狀態變更。 執行檢查指讓某些誠實的參與者(「證明者」)重新執行這些交易,以確保提出的狀態變更正確無誤。 要完成執行檢查,交易資料可供使用的時間必須夠長,以讓任何人都能下載並檢查。 這意味著證明者可以識別並質疑卷軸排序者的任何不誠實行為。 然而,資料並不需要永久可用。
-
卷軸在鏈上發佈對其交易資料的承諾,並在資料二進位大型物件中提供實際資料。 這表示證明者可以確認承諾是否有效,或質疑其認為錯誤的資料。 在節點層面,資料的二進位大型物件儲存在共識用戶端中。 共識用戶端證明自己已經看過資料,且資料已在網路上傳播。 如果永久儲存資料,這些用戶端會膨脹並導致對運行節點的硬體要求過高。 反之,資料每 18 天會從節點中自動刪除。 共識用戶端的證明顯示證明者有足夠的機會驗證資料。 實際資料可由卷軸運營商、使用者或其他人儲存在鏈下。
-
### 如何驗證二進位大型物件資料? {#how-are-blobs-verified}
@@ -48,13 +46,11 @@ EIP-4844 KZG 儀式已向公眾開放,有數萬人參與並新增自己的隨
當卷軸在二進位大型物件中發佈資料時,會提供一則在鏈上發佈的「承諾」。 這項承諾是在某些點對資料進行多項式擬合計算的結果。 這些點由 KZG 儀式中產生的隨機數字定義。 然後,證明者可以在相同點計算多項式以驗證資料;如果得出的值相同,則資料是正確的。
-
如果有人知道用於承諾的隨機位置,他們就很容易產生能在這些特定點擬合的新多項式 (即「碰撞」)。 這表示他們可以從二進位大型物件新增或移除資料,並且仍然提供有效的證明。 為了避免這種情況,實際上不是向證明者提供實際的秘密位置,證明者實際收到的是使用橢圓曲線包裝在加密「黑盒子」中的位置。 這些方法有效地擾亂了這些值,使原始值無法被逆向工程,但透過一些聰明的代數方法,證明者和驗證者仍然可以在其代表的點上計算多項式。
-
@@ -70,13 +66,11 @@ Danksharding 完全實現了從 Proto-Danksharding 開始的卷軸擴容。 Dank
提交者-建置者分離是為了防止單一驗證者必須為 32MB 的二進位大型物件資料產生昂貴的承諾和證明。 這為家庭質押者帶來很大的壓力,因為他們需要花費更多資金購買更強大的硬體,這會降低去中心化程度。 相反,專門的區塊建置者會負責這項昂貴的計算工作。 之後,區塊提交者即可廣播他們的區塊。 區塊提交者會直接選擇收益最大的區塊。 所有人都能經濟快速地驗證二進位大型物件,表示所有普通驗證者皆可檢查區塊建置者的行為是否誠實。 這允許在不犧牲去中心化的情況下處理大型二進位大型物件。 錯誤行事的區塊建置者可能被強制退出網路並罰沒,其他人會補上他的位置,因為區塊建置是高收益的活動。
-
驗證者需要進行資料可用性採樣才能快速有效地驗證二進位大型物件資料。 透過資料可用性採樣,驗證者可以非常確定二進位大型物件資料可用且正確提交。 每個驗證者都可以隨機採樣幾個資料點並建立證明,這意味著驗證者無需檢查整個二進位大型物件。 任何資料缺漏的情況都可被快速發現且二進位大型物件會遭拒。
-
### 目前進度 {#current-progress}
diff --git a/public/content/translations/zh-tw/roadmap/dencun/index.md b/public/content/translations/zh-tw/roadmap/dencun/index.md
index dbf0d9af3da..8f37f802f53 100644
--- a/public/content/translations/zh-tw/roadmap/dencun/index.md
+++ b/public/content/translations/zh-tw/roadmap/dencun/index.md
@@ -1,6 +1,6 @@
---
-title: Cancun-Deneb(坎昆)升級常見問題解答
-description: 有關 Cancun-Deneb(坎昆)網路升級的常見問題
+title: "Cancun-Deneb(坎昆)升級常見問題解答"
+description: "有關 Cancun-Deneb(坎昆)網路升級的常見問題"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/roadmap/fusaka/index.md b/public/content/translations/zh-tw/roadmap/fusaka/index.md
index 1533aae5229..80eab865b23 100644
--- a/public/content/translations/zh-tw/roadmap/fusaka/index.md
+++ b/public/content/translations/zh-tw/roadmap/fusaka/index.md
@@ -1,6 +1,6 @@
---
title: Fulu-Osaka (Fusaka)
-description: 瞭解Fusaka協議升級
+description: "瞭解Fusaka協議升級"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md b/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md
index 149c869f354..1de2ad2b219 100644
--- a/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md
+++ b/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md
@@ -1,6 +1,6 @@
---
title: PeerDAS
-description: 作為 Fusaka 以太坊協議升級的一部分,了解 PeerDAS
+description: "作為 Fusaka 以太坊協議升級的一部分,了解 PeerDAS"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/roadmap/future-proofing/index.md b/public/content/translations/zh-tw/roadmap/future-proofing/index.md
index 6a8d9e4bbdb..ed49abb5df7 100644
--- a/public/content/translations/zh-tw/roadmap/future-proofing/index.md
+++ b/public/content/translations/zh-tw/roadmap/future-proofing/index.md
@@ -1,6 +1,6 @@
---
-title: 面向未來的以太坊
-description: 不論未來如何發展,這些升級可鞏固以太坊作為有韌性的去中心化基礎層的地位。
+title: "面向未來的以太坊"
+description: "不論未來如何發展,這些升級可鞏固以太坊作為有韌性的去中心化基礎層的地位。"
lang: zh-tw
image: /images/roadmap/roadmap-future.png
alt: "以太坊開發藍圖"
diff --git a/public/content/translations/zh-tw/roadmap/merge/index.md b/public/content/translations/zh-tw/roadmap/merge/index.md
index a60c86388d7..5e4fa5e679d 100644
--- a/public/content/translations/zh-tw/roadmap/merge/index.md
+++ b/public/content/translations/zh-tw/roadmap/merge/index.md
@@ -1,14 +1,14 @@
---
-title: 合併
-description: 瞭解「合併 - 當以太坊主網採用權益證明時」的相關資訊。
+title: "合併"
+description: "瞭解「合併 - 當以太坊主網採用權益證明時」的相關資訊。"
lang: zh-tw
template: upgrade
image: /images/upgrades/merge.png
alt:
-summaryPoint1: 以太坊主網使用權益證明,但以前並非總是如此。
-summaryPoint2: 從原本的工作量證明機制到權益證明的升級稱為「合併」。
-summaryPoint3: 合併指原本的以太坊主網與稱為信標鏈的獨立權益證明區塊鏈合併,現在作為一條鏈存在。
-summaryPoint4: 合併將以太坊的能源消耗降低了約 99.95%。
+summaryPoint1: "以太坊主網使用權益證明,但以前並非總是如此。"
+summaryPoint2: "從原本的工作量證明機制到權益證明的升級稱為「合併」。"
+summaryPoint3: "合併指原本的以太坊主網與稱為信標鏈的獨立權益證明區塊鏈合併,現在作為一條鏈存在。"
+summaryPoint4: "合併將以太坊的能源消耗降低了約 99.95%。"
---
@@ -70,7 +70,8 @@ id="staking-node-operators">
在完成上述兩點以前,你的節點會顯示為「離線」,直到兩個層皆同步且通過驗證為止。
-若未設定「費用接收」地址,驗證者仍舊可以如常行事,但你將無法賺取未銷毀費用小費,以及原本可以在驗證者提出的區塊中賺取的最大可提取價值。
+若未設定「費用接收」地址,驗證者仍舊可以如常行事,但你將無法賺取未銷毀費用小費,以及原本可以在驗證者提出的區塊中賺取的最大可提取價值。
+
- 使用共用 JWT 密鑰驗證執行與共識用戶端,以便它們可以安全地互相通訊。
若未完成上述事項,你的節點將會顯示為「離線」狀態,直到兩個層皆同步且通過驗證為止。
-
更多資訊請閱讀 Tim Beiko 的部落格文章:合併如何影響以太坊的應用程式層。
-
## 合併與能源消耗 {#merge-and-energy}
@@ -134,7 +133,6 @@ contentPreview="錯誤。 任何人都可以自由同步自己經自我驗證的
任何人都能夠執行自己的節點對於維持以太坊網路的去中心化絕對至關重要。
[有關運行自己的節點的更多信息](/run-a-node/)
-
以 rollup 為中心的開發藍圖,我們主要專注於擴展[二層網路](/layer-2/)上的使用者活動,同時讓一層網路主網成為針對 rollup 資料儲存進行最佳化的安全去中心化結算層,以協助使 rollup 交易成本呈指數級下降。 轉用權益證明是實現這點的關鍵前導步驟。 [深入了解 gas 和 fee。](/developers/docs/gas/)
-
提款地址,以開始接收自動支付的額外質押餘額(原本質押的 32 以太幣以外的協定獎勵)。 此升級也使驗證者可以在退出網路時解鎖和收回其全部餘額。
[深入了解質押提款](/staking/withdrawals/)
-
- 確切的質押發行量會根據 ETH 的質押總量而波動。
- **自合併以來,每日只剩下約 1,700 ETH 的發行量,使新的 ETH 總發行量下降了約 88%**
- 銷毀:此數量根據網路需求而波動。 _如果某天平均燃料價格高於 16 gwei,這會有效抵消發行給驗證者的約 1,700 個以太幣,使得當天的以太幣淨通膨率降至零或更低。
-
## 合併前 (歷史) {#pre-merge}
@@ -61,7 +60,10 @@ ETH 總供給量:**約 120,520,000 ETH** (在 2022 年 9 月合併時)
執行層上 **~88.7%** 的發行量流向礦工 (4.09 / 4.61 \* 100)
-共識層上 **~11.3%** 的發行量發給質押者 (0.52 / 4.61 \* 100)
+共識層上 **~11.3%** 的發行量發給質押者 (0.52 / 4.61 \* 100)
+
+
+
## 合併後 (現今) {#post-merge}
@@ -92,7 +94,10 @@ ETH 總供給量:**約 120,520,000 ETH** (在 2022 年 9 月合併時)
年化總發行率:**~0.52%**
-年度 ETH 發行淨減少:**~88.7%** ((4.61% - 0.52%) / 4.61% \* 100)
+年度 ETH 發行淨減少:**~88.7%** ((4.61% - 0.52%) / 4.61% \* 100)
+
+
+
## 銷毀 {#the-burn}
@@ -102,7 +107,10 @@ ETH 總供給量:**約 120,520,000 ETH** (在 2022 年 9 月合併時)
-費用銷毀機制隨著 2021 年 8 月的 [倫敦升級](/ethereum-forks/#london) 一同上線,自合併以來維持不變。
+費用銷毀機制隨著 2021 年 8 月的 [倫敦升級](/ethereum-forks/#london) 一同上線,自合併以來維持不變。
+
+
+
除了倫敦升級時實作的費用銷毀機制外,驗證者也可能因離線而受到懲處;更糟糕的是,他們可能因為違反威脅網路安全的特定規定而遭罰沒。 這些處罰會導致驗證者餘額中的以太幣減少,減少的金額不會直接獎勵給任何其他帳戶,而是會有效地從流通中銷毀/移除。
diff --git a/public/content/translations/zh-tw/roadmap/pbs/index.md b/public/content/translations/zh-tw/roadmap/pbs/index.md
index 1289e666e13..e879bdfe6db 100644
--- a/public/content/translations/zh-tw/roadmap/pbs/index.md
+++ b/public/content/translations/zh-tw/roadmap/pbs/index.md
@@ -1,6 +1,6 @@
---
-title: 提交者-建置者分離
-description: 瞭解以太坊驗證者如何以及為何要將區塊建置與區塊廣播職責分離。
+title: "提交者-建置者分離"
+description: "瞭解以太坊驗證者如何以及為何要將區塊建置與區塊廣播職責分離。"
lang: zh-tw
---
@@ -21,7 +21,6 @@ lang: zh-tw
有權勢的組織可以對驗證者施壓,以審查特定地址收發的交易。 為應對這一壓力,驗證者會偵測交易池中已加入黑名單的地址並將其從提出的區塊中刪除。 提交者-建置者分離之後,這種情況不再可能出現,因為區塊提交者不會知道他們在區塊中廣播的是哪些交易。 對於某些個人或應用程式來說,遵守審查規則可能很重要,例如當審查規則在其所在地區成為法律時。 在這些情況下,合規性發生在應用程式級別,同時協定仍然無需許可且不受審查。
-
## PBS 與 MEV {#pbs-and-mev}
@@ -32,7 +31,8 @@ lang: zh-tw
-由於複雜的最大可提取價值策略提供更高的獎勵,個人可能會被質押池吸引,而不是自己單獨質押。 將區塊建置與區塊提出分離,表示提取的最大可提取價值會分散到更多驗證者,而非集中在最高效的最大可提取價值搜尋者手上。 同時,允許專業的區塊建置者存在,消除了個人的區塊建置負擔,也避免個人自己偷取最大可提取價值,同時最大程度上增加了可以檢查區塊是否誠實的個人獨立驗證者的數量。 「證明者-驗證者不對稱性」是一個重要的概念,指的是只要有強大且最大程度去中心化的驗證者網路能夠證明區塊是誠實的,中心化區塊生產就可以接受。 去中心化是一種方法,而非最終目標,我們需要的是誠實的區塊。
+由於複雜的最大可提取價值策略提供更高的獎勵,個人可能會被質押池吸引,而不是自己單獨質押。 將區塊建置與區塊提出分離,表示提取的最大可提取價值會分散到更多驗證者,而非集中在最高效的最大可提取價值搜尋者手上。 同時,允許專業的區塊建置者存在,消除了個人的區塊建置負擔,也避免個人自己偷取最大可提取價值,同時最大程度上增加了可以檢查區塊是否誠實的個人獨立驗證者的數量。 「證明者-驗證者不對稱性」是一個重要的概念,指的是只要有強大且最大程度去中心化的驗證者網路能夠證明區塊是誠實的,中心化區塊生產就可以接受。 去中心化是一種方法,而非最終目標,我們需要的是誠實的區塊。
+
## PBS 與 Danksharding {#pbs-and-danksharding}
diff --git a/public/content/translations/zh-tw/roadmap/pectra/7702/index.md b/public/content/translations/zh-tw/roadmap/pectra/7702/index.md
index a184285a1d8..a8ed876e218 100644
--- a/public/content/translations/zh-tw/roadmap/pectra/7702/index.md
+++ b/public/content/translations/zh-tw/roadmap/pectra/7702/index.md
@@ -1,6 +1,6 @@
---
-title: Pectra 7702 操作指南
-description: 深入了解 Pectra 發行版的 7702
+title: "Pectra 7702 操作指南"
+description: "深入了解 Pectra 發行版的 7702"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/roadmap/pectra/index.md b/public/content/translations/zh-tw/roadmap/pectra/index.md
index 4e4b3d49348..d7afe14c286 100644
--- a/public/content/translations/zh-tw/roadmap/pectra/index.md
+++ b/public/content/translations/zh-tw/roadmap/pectra/index.md
@@ -1,6 +1,6 @@
---
-title: 布拉格埃萊特拉(Pectra)
-description: 了解 Pectra 協議升級
+title: "布拉格埃萊特拉(Pectra)"
+description: "了解 Pectra 協議升級"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md b/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md
index 500757b77a2..a0fb68917e5 100644
--- a/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md
+++ b/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md
@@ -1,6 +1,6 @@
---
-title: Pectra 升級後的最大有效金額機制
-description: 在 Pectra 升級中了解更多關於 MaxEB 的信息
+title: "Pectra 升級後的最大有效金額機制"
+description: "在 Pectra 升級中了解更多關於 MaxEB 的信息"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/roadmap/scaling/index.md b/public/content/translations/zh-tw/roadmap/scaling/index.md
index 67e2c2b55c5..c0e8570cba7 100644
--- a/public/content/translations/zh-tw/roadmap/scaling/index.md
+++ b/public/content/translations/zh-tw/roadmap/scaling/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊擴容
-description: 卷軸可在鏈下批次處理交易,從而降低使用者的成本。 但現今卷軸使用資料的方式還是過於昂貴,限制了交易費用的下限。 Proto-Danksharding 可以解決這個問題。
+title: "以太坊擴容"
+description: "卷軸可在鏈下批次處理交易,從而降低使用者的成本。 但現今卷軸使用資料的方式還是過於昂貴,限制了交易費用的下限。 Proto-Danksharding 可以解決這個問題。"
lang: zh-tw
image: /images/roadmap/roadmap-transactions.png
alt: "以太坊開發藍圖"
diff --git a/public/content/translations/zh-tw/roadmap/secret-leader-election/index.md b/public/content/translations/zh-tw/roadmap/secret-leader-election/index.md
index cb2d1eb60bd..901e0926bc9 100644
--- a/public/content/translations/zh-tw/roadmap/secret-leader-election/index.md
+++ b/public/content/translations/zh-tw/roadmap/secret-leader-election/index.md
@@ -1,6 +1,6 @@
---
-title: 秘密領導者選舉
-description: 解釋秘密領導者選舉可如何保護驗證者免遭攻擊
+title: "秘密領導者選舉"
+description: "解釋秘密領導者選舉可如何保護驗證者免遭攻擊"
lang: zh-tw
summaryPoints:
- 區塊提交者的 IP 地址可被預先獲知,這讓他們很容易遭受攻擊
diff --git a/public/content/translations/zh-tw/roadmap/security/index.md b/public/content/translations/zh-tw/roadmap/security/index.md
index 1ca0a33ad5c..33f23683258 100644
--- a/public/content/translations/zh-tw/roadmap/security/index.md
+++ b/public/content/translations/zh-tw/roadmap/security/index.md
@@ -1,6 +1,6 @@
---
-title: 一個更安全的以太坊
-description: 以太坊是現有最安全、去中心化程度最高的智慧型合約平台。 然而,我們還可以繼續對其進行改進,以便未來能夠保持韌性來對抗任意級別的攻擊。
+title: "一個更安全的以太坊"
+description: "以太坊是現有最安全、去中心化程度最高的智慧型合約平台。 然而,我們還可以繼續對其進行改進,以便未來能夠保持韌性來對抗任意級別的攻擊。"
lang: zh-tw
image: /images/roadmap/roadmap-security.png
alt: "以太坊開發藍圖"
diff --git a/public/content/translations/zh-tw/roadmap/single-slot-finality/index.md b/public/content/translations/zh-tw/roadmap/single-slot-finality/index.md
index b1fb227f8c1..cc260e6f845 100644
--- a/public/content/translations/zh-tw/roadmap/single-slot-finality/index.md
+++ b/public/content/translations/zh-tw/roadmap/single-slot-finality/index.md
@@ -1,6 +1,6 @@
---
-title: 單一時隙最終確定性
-description: 解釋單一時隙最終確定性
+title: "單一時隙最終確定性"
+description: "解釋單一時隙最終確定性"
lang: zh-tw
---
@@ -39,7 +39,8 @@ lang: zh-tw
這個流程為每個驗證者提供足夠的容量,使驗證者可以在每個時期投票,因為「32 個時隙 \* 64 個委員會 \* 每個委員會 256 個驗證者 = 每個時期 524,288 個驗證者」。 截至本文撰寫時止(2023 年 2 月),一共有大約 513,000 個活躍驗證者。
-在這個方案下,每個驗證者只能透過在整個時期分發證明來為一個區塊投票。 然而,有一些潛在的方式可以改進此機制,使得每個驗證者在每個時隙都有證明機會。
+在這個方案下,每個驗證者只能透過在整個時期分發證明來為一個區塊投票。 然而,有一些潛在的方式可以改進此機制,使得每個驗證者在每個時隙都有證明機會。
+
自以太坊共識機制推出以來,簽名匯總方案 (BLS) 的可擴容性比原先想像的要高得多,同時用戶端處理和驗證簽名的能力也已提高。 事實證明,驗證者在單一時隙中處理大量證明是可行的。 舉例來說,有一百萬個驗證者,每個驗證者在每個時隙投票兩次,且時隙時間調整為 16 秒,為了在一個時隙中處理一百萬個證明,節點需要至少以每秒 125,000 個的速度驗證匯總簽名。 實際上,一般電腦會花費大約 500 奈秒完成一個簽名驗證,表示 125,000 個驗證可以在約 62.5 毫秒內完成,遠低於 1 秒的閾值。
diff --git a/public/content/translations/zh-tw/roadmap/statelessness/index.md b/public/content/translations/zh-tw/roadmap/statelessness/index.md
index 721901e84c2..356f9adda5d 100644
--- a/public/content/translations/zh-tw/roadmap/statelessness/index.md
+++ b/public/content/translations/zh-tw/roadmap/statelessness/index.md
@@ -1,6 +1,6 @@
---
-title: 無狀態、狀態過期及歷史記錄過期
-description: 對於歷史記錄過期和無狀態以太坊的說明
+title: "無狀態、狀態過期及歷史記錄過期"
+description: "對於歷史記錄過期和無狀態以太坊的說明"
lang: zh-tw
---
@@ -72,7 +72,8 @@ EIP-4444 尚未準備好上線,但正在積極討論當中。 有趣的是,E
無狀態依賴區塊建置者維護完整狀態資料的副本,這樣它們才能產生用於驗證區塊的證據。 其他節點不需要存取狀態資料,驗證區塊所需的所有資訊都可以從證據中取得。 這導致了這樣一種狀況:提出區塊的成本很高,但驗證區塊很便宜,表示較少的運營商會選擇運行區塊提出節點。 然而,只要盡可能多的參與者能夠獨立驗證所提出區塊的有效性,區塊提交者的去中心化程度就不是非常重要。
-深入閱讀 Dankrad 的筆記
+深入閱讀 Dankrad 的筆記
+
區塊提交者使用狀態資料來建立「證據」,即證明區塊中的交易正在更改的狀態值的最小資料集。 其他驗證者不儲存狀態,只儲存狀態根(整個狀態的的雜湊值)。 他們會接收區塊和證據,然後用其更新自己的狀態根。 這使得驗證節點的工作變得極輕量。
diff --git a/public/content/translations/zh-tw/roadmap/user-experience/index.md b/public/content/translations/zh-tw/roadmap/user-experience/index.md
index 3cdc2dfe642..55d6875fa9c 100644
--- a/public/content/translations/zh-tw/roadmap/user-experience/index.md
+++ b/public/content/translations/zh-tw/roadmap/user-experience/index.md
@@ -1,6 +1,6 @@
---
-title: 改善使用者體驗
-description: 對大部分人而言,使用以太坊仍然是非常複雜的一件事。 為了推動普及化,以太坊必須大幅降低使用門檻 — 使用者必須獲得去中心化、無需許可、抗審查存取以太坊的優勢,同時體驗必須與使用傳統 web2 應用程式一樣順暢。
+title: "改善使用者體驗"
+description: "對大部分人而言,使用以太坊仍然是非常複雜的一件事。 為了推動普及化,以太坊必須大幅降低使用門檻 — 使用者必須獲得去中心化、無需許可、抗審查存取以太坊的優勢,同時體驗必須與使用傳統 web2 應用程式一樣順暢。"
lang: zh-tw
image: /images/roadmap/roadmap-ux.png
alt: "以太坊開發藍圖"
diff --git a/public/content/translations/zh-tw/roadmap/verkle-trees/index.md b/public/content/translations/zh-tw/roadmap/verkle-trees/index.md
index 73edb497982..971ff0e320b 100644
--- a/public/content/translations/zh-tw/roadmap/verkle-trees/index.md
+++ b/public/content/translations/zh-tw/roadmap/verkle-trees/index.md
@@ -1,6 +1,6 @@
---
-title: 沃克爾樹
-description: 關於沃克爾樹及其將如何用於升級以太坊的簡要說明
+title: "沃克爾樹"
+description: "關於沃克爾樹及其將如何用於升級以太坊的簡要說明"
lang: zh-tw
summaryPoints:
- 瞭解沃克爾樹是什麼
@@ -18,7 +18,6 @@ summaryPoints:
以太坊用戶端目前使用帕特里夏梅克爾樹樹狀資料結構,儲存其自身的狀態資料。 有關個人帳戶的資訊作為葉子儲存在樹上,向一對對葉子重複進行雜湊運算,直到只剩下一個雜湊值。 串接在最末尾的雜湊值被稱為「根」。 為了驗證區塊,以太坊用戶端會執行區塊中的所有交易並更新其本地狀態樹。 若本地樹的「根」與區塊提交者提出的「根」完全相同,區塊即被視為有效。因為如果區塊提交者和驗證節點執行的計算中出現任何差異,都會導致根雜湊值完全不同。 這樣做的問題是,驗證區塊鏈需要每個用戶端儲存頭塊和多個歷史區塊的整個狀態樹(Geth 中預設保留頭塊後面 128 個區塊的狀態資料)。 因此用戶端需要存取大量磁碟空間,這是在廉價、低功耗硬體上運行完整節點的障礙。 解決這個問題的辦法是將狀態樹更新為更有效的結構(沃克爾樹),這種結構可以使用短小的「證據」對資料進行彙總再分享,而無需保存完整的狀態資料。 將狀態資料重新格式化為梅克爾樹,是邁向無狀態用戶端的第一步。
-
## 什麼是證據以及我們為什麼需要證據? {#what-is-a-witness}
@@ -34,11 +33,9 @@ Merkle 樹的結構導致證據非常大,以至於無法在 12 秒的時隙內
證據大小各有差異,取決於其所含的葉子數量。 假設證據有 1000 片葉子,梅克爾樹的證據大約是 3.5MB(假設樹有 7 層)。 相同資料的證據在沃克爾(假設樹有 4 層)中大概是 150 kB - **縮減了大約 23 倍**。 證據大小的縮減將使無狀態用戶端證據小到可以接受。 多項式證據的大小一般在 0.128 - 1 kB 之間,取決於使用哪個特定多項式承諾。
-
-## 沃克爾樹的結構為何? 沃克爾樹的結構為何? {#what-is-the-structure-of-a-verkle-tree}
-
+## 沃克爾樹的結構為何? {#what-is-the-structure-of-a-verkle-tree}
沃克爾樹是 `(key,value)` 配對,其中的鍵是由 31 位元組的 _主幹_ 和單一位元組的 _後綴_ 所組成的 32 位元組元素。 這些鍵被整理到 _擴充_ 節點和 _內部_ 節點中。 擴展節點是單一的主幹,包含 256 個具有不同後綴的子節點。 內部節點也有 256 個子節點,但可以是其他擴展節點。 沃克爾樹和梅克爾樹結構的主要區別是,沃克爾樹更加扁平,表示將葉子連接到根的中間節點較少,因此產生證明時所需的資料更少。

diff --git a/public/content/translations/zh-tw/security/index.md b/public/content/translations/zh-tw/security/index.md
index 38fa0de55c2..39c1d40c282 100644
--- a/public/content/translations/zh-tw/security/index.md
+++ b/public/content/translations/zh-tw/security/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊安全性及詐騙防範
-description: 維護以太坊安全
+title: "以太坊安全性及詐騙防範"
+description: "維護以太坊安全"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/smart-contracts/index.md b/public/content/translations/zh-tw/smart-contracts/index.md
index 28148b8bd06..32e4031f258 100644
--- a/public/content/translations/zh-tw/smart-contracts/index.md
+++ b/public/content/translations/zh-tw/smart-contracts/index.md
@@ -1,7 +1,7 @@
---
-title: 智慧型合約
+title: "智慧型合約"
metaTitle: "智能合約:簡介與優點"
-description: 智慧型合約的非技術性簡介
+description: "智慧型合約的非技術性簡介"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/social-networks/index.md b/public/content/translations/zh-tw/social-networks/index.md
index dc3986574be..800b81dc745 100644
--- a/public/content/translations/zh-tw/social-networks/index.md
+++ b/public/content/translations/zh-tw/social-networks/index.md
@@ -1,14 +1,14 @@
---
-title: 去中心化社交網路
-description: 以太坊去中心化社交網路概覽
+title: "去中心化社交網路"
+description: "以太坊去中心化社交網路概覽"
lang: zh-tw
template: use-cases
emoji: ":mega:"
sidebarDepth: 2
image: /images/ethereum-learn.png
-summaryPoint1: 基於區塊鏈的平台,用於社交互動、内容建立和分發。
-summaryPoint2: 去中心化社交媒體網路可保護用戶隱私和增強資料安全性。
-summaryPoint3: 代幣和非同質化代幣創造了將內容貨幣化的新方法。
+summaryPoint1: "基於區塊鏈的平台,用於社交互動、内容建立和分發。"
+summaryPoint2: "去中心化社交媒體網路可保護用戶隱私和增強資料安全性。"
+summaryPoint3: "代幣和非同質化代幣創造了將內容貨幣化的新方法。"
---
社交網路在我們的日常交流和互動中發揮著重要作用。 然而,這些平台的中心化控制產生了許多問題:資料洩露、伺服器中斷、平台禁言、審查制度和侵犯隱私,是社交媒體經常做出的一些取捨。 為了解決這些問題,開發者正在以太坊上建立社交網路。 去中心化社交網路可以解決傳統社交網路平台的許多問題,並提升用戶的整體體驗。
diff --git a/public/content/translations/zh-tw/staking/dvt/index.md b/public/content/translations/zh-tw/staking/dvt/index.md
index e4f1449a708..053e026352a 100644
--- a/public/content/translations/zh-tw/staking/dvt/index.md
+++ b/public/content/translations/zh-tw/staking/dvt/index.md
@@ -1,6 +1,6 @@
---
-title: 分散式驗證者技術
-description: 分散式驗證者技術使以太坊驗證者可以由多方分散式執行。
+title: "分散式驗證者技術"
+description: "分散式驗證者技術使以太坊驗證者可以由多方分散式執行。"
lang: zh-tw
---
diff --git a/public/content/translations/zh-tw/staking/pools/index.md b/public/content/translations/zh-tw/staking/pools/index.md
index 0e85801e9c5..f1cbd064d42 100644
--- a/public/content/translations/zh-tw/staking/pools/index.md
+++ b/public/content/translations/zh-tw/staking/pools/index.md
@@ -1,11 +1,11 @@
---
-title: 聯合質押
-description: 了解質押池
+title: "聯合質押"
+description: "了解質押池"
lang: zh-tw
template: staking
emoji: ":money_with_wings:"
image: /images/staking/leslie-pool.png
-alt: 萊斯利犀牛在池中游泳
+alt: "萊斯利犀牛在池中游泳"
sidebarDepth: 2
summaryPoints:
- 與其他人一起質押任意數量的以太幣並獲得酬勞
@@ -68,14 +68,16 @@ summaryPoints:
或者,使用 ERC-20 質押代幣的質押池允許使用者在公開市場上交易該代幣,讓你可以出售質押位置,這相當於允許你「提款」,但無需實際從質押合約中移除以太幣。
-更多關於質押提款
+更多關於質押提款
+
這些聯合質押選項和中心化交易所之間有許多相似之處,例如能夠質押少量的 ETH,並將它們捆綁在一起以啟動驗證程式。
與中心化交易所不同的是,許多其他聯合質押方案採用的是智慧型合約和/或質押代幣,通常是 ERC-20 代幣。這些代幣可以保存在你自己的錢包中,並能像任何其他代幣一樣正常買賣。 透過讓你控制自己的代幣,這為你提供了一層主權和安全性,但這並不代表你能夠直接控制在後台代表你執行證明的驗證者用戶端。
-當涉及到支持它們的節點時。一些聯合質押方案比其他方案更去中心化。 為了加強網路的健康和去中心化程度,我們始終鼓勵質押者選擇這樣的聯合質押服務:無需許可且實現節點營運商去中心化。
+當涉及到支持它們的節點時。一些聯合質押方案比其他方案更去中心化。 為了加強網路的健康和去中心化程度,我們始終鼓勵質押者選擇這樣的聯合質押服務:無需許可且實現節點營運商去中心化。
+
## 延伸閱讀 {#further-reading}
diff --git a/public/content/translations/zh-tw/staking/saas/index.md b/public/content/translations/zh-tw/staking/saas/index.md
index 9fb7577783f..f111440d4bc 100644
--- a/public/content/translations/zh-tw/staking/saas/index.md
+++ b/public/content/translations/zh-tw/staking/saas/index.md
@@ -1,11 +1,11 @@
---
-title: 質押即服務
-description: 了解質押即服務
+title: "質押即服務"
+description: "了解質押即服務"
lang: zh-tw
template: staking
emoji: ":money_with_wings:"
image: /images/staking/leslie-saas.png
-alt: 漂浮在雲端的犀牛萊斯利。
+alt: "漂浮在雲端的犀牛萊斯利。"
sidebarDepth: 2
summaryPoints:
- 第三方節點營運商負責處理你的驗證者用戶端的運作
@@ -13,12 +13,10 @@ summaryPoints:
- 降低信任依賴,並保持你對提款金鑰的控制權
---
-## 什麼是質押即服務? 什麼是質押即服務? {#what-is-staking-as-a-service}
-
+## 什麼是質押即服務? {#what-is-staking-as-a-service}
質押即服務(「SaaS」)代表一種質押服務,你將自己的 32 個以太幣存入驗證者,但將節點運作委託給第三方營運商。 此流程通常需要你按指引完成初始化設定,包括產生金鑰和存入資金,然後將你的簽名金鑰上傳給營運商。 這將允許該服務代表你運作你的驗證者,通常是按月收費。
-## 為什麼需要質押服務? 為什麼需要質押服務? {#why-stake-with-a-service}
-
+## 為什麼需要質押服務? {#why-stake-with-a-service}
以太坊協定本身並不支援質押委託,因此為了滿足此項需求,這類服務應運而生。 如果你有 32 個以太幣要質押,但懶得處理硬體設備,質押即服務可以讓你在賺取原生區塊酬勞的同時將困難的部分外包。
@@ -70,20 +68,24 @@ BLS 提款金鑰用於簽署一次性訊息,說明應將質押酬勞和退出
請務必妥善備份此種子助記詞,否則屆時您將無法產生提款金鑰。
-\*在首次存款時已提供提款地址的質押者,不需要進行此設定。 有關如何準備驗證者,請向你的質押即服務供應商請求支援。
+\*在首次存款時已提供提款地址的質押者,不需要進行此設定。 有關如何準備驗證者,請向你的質押即服務供應商請求支援。
+
-質押者需要提供提款地址(若首次存款時未提供),獎勵將會每隔幾天定期自動發放。
+
+質押者需要提供提款地址(若首次存款時未提供),獎勵將會每隔幾天定期自動發放。
驗證者還可以作為驗證者完全退出,這將解鎖剩餘的以太幣餘額以供提款。 已提供執行提款地址並完成退出流程的帳戶,提供的提款地址將在下一次驗證者掃描期間收到全部餘額。
-更多關於質押提款
+更多關於質押提款
+
使用質押即服務供應商,你會將節點的運作委託給其他人。 這伴隨著節點效能不佳的風險,這是你無法控制的。 如果你的驗證者遭到罰沒,驗證者的餘額會受到罰款,驗證者也會強制從驗證者池下架。
罰沒/退出流程完成後,這些資金將被轉移到分配給驗證者的提款地址。 需要提供提款地址才能啟用該功能。 提款地址可能在一開始存款時便已提供。 如果沒有,則需要使用驗證者提款金鑰來簽署說明提款地址的訊息。 如果未提供提款地址,資金將保持鎖定狀態,直到提供地址為止。
-請聯繫各質押即服務提供商,了解關於任何擔保或保險方案的詳細訊息,以及如何提供提款地址的說明。 如果你想完全掌控你的驗證者節點設定,請參考:瞭解如何獨立質押ETH(/staking/solo/)。
+請聯繫各質押即服務提供商,了解關於任何擔保或保險方案的詳細訊息,以及如何提供提款地址的說明。 如果你想完全掌控你的驗證者節點設定,請參考:瞭解如何獨立質押ETH(/staking/solo/)。
+
## 延伸閱讀 {#further-reading}
diff --git a/public/content/translations/zh-tw/staking/solo/index.md b/public/content/translations/zh-tw/staking/solo/index.md
index 5d4858a8f8c..2bddd2a3bb9 100644
--- a/public/content/translations/zh-tw/staking/solo/index.md
+++ b/public/content/translations/zh-tw/staking/solo/index.md
@@ -1,11 +1,11 @@
---
-title: 單獨質押以太幣
-description: 如何開始單獨質押以太幣的概覽
+title: "單獨質押以太幣"
+description: "如何開始單獨質押以太幣的概覽"
lang: zh-tw
template: staking
emoji: ":money_with_wings:"
image: /images/staking/leslie-withdrawal.png
-alt: 萊斯利犀牛在她自己的電腦晶片上。
+alt: "萊斯利犀牛在她自己的電腦晶片上。"
sidebarDepth: 2
summaryPoints:
- 直接從協定中獲得最大酬勞,以保持你的驗證者正常運作和上線
@@ -43,17 +43,20 @@ summaryPoints:
在操作您自己的節點時,您應該花一些時間學習如何使用您所選擇的軟體。 這包括閱讀相關文件,並關注開發團隊的溝通管道。
-您越了解您正在執行的軟體以及權益證明的運作方式,作為質押者的風險就越低,而作為節點營運者,解決過程中可能出現的任何問題也會越容易。
+您越了解您正在執行的軟體以及權益證明的運作方式,作為質押者的風險就越低,而作為節點營運者,解決過程中可能出現的任何問題也會越容易。
+
設定節點需要對電腦有一定程度的掌握,不過隨著時間經過,新工具會越來越容易使用。 了解命令列介面會有所幫助,但已不再是嚴格要求。
-設定節點也需要設置非常基本的硬體,以及對最低建議規格有一些了解。
+設定節點也需要設置非常基本的硬體,以及對最低建議規格有一些了解。
+
就像私密金鑰能保護您的以太坊地址一樣,您也需要為您的驗證者專門產生金鑰。 您必須了解如何確保種子助記詞及私密金鑰的安全。{' '}
-[以太坊安全與詐騙預防](/security/)
+[以太坊安全與詐騙預防](/security/)
+
硬體偶爾會出現故障,網路連線會中斷,用戶端軟體偶爾也需要升級。 節點維護是不可避免的,偶爾會需要您的關注。 最好能隨時掌握預期的網路升級或其他重要的用戶端升級。
@@ -66,7 +69,9 @@ summaryPoints:
與離線的怠工罰金不同,罰沒是針對惡意犯規行為的更嚴重懲罰。 如果同一個時間只在一台電腦上載入金鑰來執行非主流用戶端,遭到罰沒的風險便能降到最低。 話雖如此,所有質押者都必須意識到罰沒的風險。
-更多關於罰沒與驗證者生命週期的資訊
+更多關於罰沒與驗證者生命週期的資訊
+
+
@@ -125,7 +130,6 @@ summaryPoints:
驗證者是一個存在於以太坊並參與以太坊協議共識的虛擬實體。 驗證者由餘額、公鑰和其他屬性表示。 驗證者用戶端是透過持有和使用其私密金鑰,代表驗證者進行操作的軟體。 一個驗證者用戶端可以持有多組金鑰對,控制許多驗證者。
-
@@ -137,14 +141,16 @@ summaryPoints:
與驗證者相關聯的每組金鑰對都需要至少 32 ETH 才能啟用。 任何超過此數字的餘額,都可以隨時透過由該地址簽署的交易提取到關聯的提款地址。 超過最大有效餘額的任何資金都將定期自動提取。
-如果單獨質押對您來說要求太高,可以考慮使用[質押即服務](/staking/saas/)供應商,或者如果您持有的 ETH 少於 32 個,可以了解下[質押池](/staking/pools/)。
+如果單獨質押對您來說要求太高,可以考慮使用[質押即服務](/staking/saas/)供應商,或者如果您持有的 ETH 少於 32 個,可以了解下[質押池](/staking/pools/)。
+
如果您在網路正確進行最終確認時離線,並不會發生罰沒。 如果您的驗證者無法在特定時期內(每個時期 6.4 分鐘)完成證明,則會產生少量的怠工罰金,但這與罰沒完全不同。 這些罰金略低於您在驗證者可以完成證明的情況下獲得的獎勵,因此只要讓驗證者再次上線,經過差不多相同的時間就能賺回來。
請注意,怠工罰金與同時離線的驗證者數量成正比。 如果大部分網路同時離線,則每個驗證者承擔的罰金將大於單一驗證者怠工時的罰金。
-在極端情況下,如果有超過三分之一的驗證者同時離線導致網路停止最終確認,那麼這些使用者會遭受所謂的二次怠工罰金,離線驗證者帳戶中的 ETH 將受到指數級別的損失。 這時以太坊網路會銷毀怠工驗證者的 ETH 來進行自我修復,直到其餘額達到 16 ETH 為止,此時它們將自動被踢出驗證者池。 最後還在線上的剩餘驗證者將再次超過網路的三分之二,滿足再次最終確認鏈所需的絕對多數要求。
+在極端情況下,如果有超過三分之一的驗證者同時離線導致網路停止最終確認,那麼這些使用者會遭受所謂的二次怠工罰金,離線驗證者帳戶中的 ETH 將受到指數級別的損失。 這時以太坊網路會銷毀怠工驗證者的 ETH 來進行自我修復,直到其餘額達到 16 ETH 為止,此時它們將自動被踢出驗證者池。 最後還在線上的剩餘驗證者將再次超過網路的三分之二,滿足再次最終確認鏈所需的絕對多數要求。
+
簡而言之,這點無法完全保證,但如果您真誠行事、執行非主流用戶端,且一次只將您的簽名金鑰保存在一部機器上,那麼遭到罰沒的風險便趨近於零。
@@ -166,14 +172,16 @@ summaryPoints:
由於所有生產環境用戶端的基本功能都相同,因此選擇非主流用戶端其實非常重要;「非主流」意指網路上大多數驗證者都「沒」使用該用戶端。 這聽起來可能有悖直覺,但執行主流或絕對主流用戶端會使您在該用戶端出現錯誤時面臨更高的罰沒風險。 執行非主流用戶端可以大幅降低這些風險。
-詳細了解用戶端多元化為何至關重要
+詳細了解用戶端多元化為何至關重要
+
雖然虛擬私人伺服器 (VPS) 可以作為家用硬體的替代品,但驗證者用戶端的實體存取和位置有其重要性。 Amazon Web Services 或 Digital Ocean 等中心化雲端解決方案提供了不必擁有和運作硬體的便利,但代價是網路中心化。
在一個中心化雲端儲存解決方案上執行的驗證者用戶端越多,對這些使用者而言就越危險。 如果發生任何事件導致這些供應商離線,無論是由於攻擊、監管要求,抑或僅因為電源/網際網路中斷,都將導致依賴此伺服器的所有驗證者用戶端同時離線。
-離線罰金與同時離線的其他驗證者數量成正比。 使用虛擬私人伺服器會大幅提高承受更嚴重離線罰金的風險,甚至如果發生大量當機,還會增加二次洩漏或罰沒的風險。 為了將您自己的風險和網路風險降至最低,我們強烈鼓勵使用者取得並操作自己的硬體。
+離線罰金與同時離線的其他驗證者數量成正比。 使用虛擬私人伺服器會大幅提高承受更嚴重離線罰金的風險,甚至如果發生大量當機,還會增加二次洩漏或罰沒的風險。 為了將您自己的風險和網路風險降至最低,我們強烈鼓勵使用者取得並操作自己的硬體。
+
@@ -185,7 +193,8 @@ summaryPoints:
要解鎖並拿回全部餘額,你還必須完成退出驗證者的過程。
-更多關於質押提款
+更多關於質押提款
+
## 延伸閱讀 {#further-reading}
diff --git a/public/content/translations/zh-tw/staking/withdrawals/index.md b/public/content/translations/zh-tw/staking/withdrawals/index.md
index a91142129b7..939f78b7a4b 100644
--- a/public/content/translations/zh-tw/staking/withdrawals/index.md
+++ b/public/content/translations/zh-tw/staking/withdrawals/index.md
@@ -1,10 +1,10 @@
---
-title: 質押提款
-description: 此頁總結了什麼是質押推送提款,該功能如何運作,以及質押者需要做什麼才能獲得酬勞
+title: "質押提款"
+description: "此頁總結了什麼是質押推送提款,該功能如何運作,以及質押者需要做什麼才能獲得酬勞"
lang: zh-tw
template: staking
image: /images/staking/leslie-withdrawal.png
-alt: 犀牛萊斯利和她的質押酬勞
+alt: "犀牛萊斯利和她的質押酬勞"
sidebarDepth: 2
summaryPoints:
- 上海/卡佩拉升級支援在以太坊提款
@@ -42,7 +42,8 @@ summaryPoints:
-每個驗證者帳戶只能指派一個提款地址,且只能指派一次。 一旦選擇地址並提交至共識層,便無法復原或再次變更。 提交前請再次檢查所提供地址的所有權和正確性。
+
+每個驗證者帳戶只能指派一個提款地址,且只能指派一次。 一旦選擇地址並提交至共識層,便無法復原或再次變更。 提交前請再次檢查所提供地址的所有權和正確性。
@@ -137,7 +138,8 @@ title="提供提款地址後,我可以將它變更為其他提款地址嗎?"
eventCategory="FAQ"
eventAction="Once I have provided a withdrawal address, can I change it to an alternative withdrawal address?"
eventName="read more">
-不可以,提供提款憑證的程序為一次性作業,提交後便無法變更。
+不可以,提供提款憑證的程序為一次性作業,提交後便無法變更。
+
提款地址可以是智慧型合約(由其程式碼控制),也可以是外部所有帳戶(EOA,由私密金鑰控制)。 目前,這些帳戶無法將訊息傳回共識層,以表明驗證者憑證的更改,增加此功能會給協議增加不必要的複雜性。
-如果無法更改特定驗證者的提款地址,使用者可以選擇將智慧型合約設置為可以處理金鑰輪換的提款地址,例如保險箱。 將資金設置為自己的外部帳戶的使用者可以執行完全退出以提取所有質押資金,然後使用新憑證重新質押。
+如果無法更改特定驗證者的提款地址,使用者可以選擇將智慧型合約設置為可以處理金鑰輪換的提款地址,例如保險箱。 將資金設置為自己的外部帳戶的使用者可以執行完全退出以提取所有質押資金,然後使用新憑證重新質押。
+
如果你參與[質押池](/staking/pools/)或持有質押代幣,則應向你的提供商諮詢,了解有關如何處理質押提款的詳細資訊,因為每種服務的運作方式不同。
一般來說,使用者應該可以自由地收回其質押的以太幣,或者更改他們使用的質押提供商。 如果特定質押池變得過大,則可以退出、贖回資金,並透過較小的提供商重新質押。 或者,如果您累積了足夠的 ETH,便可以 [自行質押](/staking/solo/)。
-
-是的,只要您的驗證者已提供提款地址。 必須提供一次才能啟用任何提款,然後酬勞支付將在每次驗證器掃描時,每隔幾天自動觸發一次。
+是的,只要您的驗證者已提供提款地址。 必須提供一次才能啟用任何提款,然後酬勞支付將在每次驗證器掃描時,每隔幾天自動觸發一次。
+
不會,如果你的驗證者在網路上仍然處於活躍狀態,則不會自動發生全額提款。 需要手動啟動自願退出。
一旦驗證者完成退出過程,並且假設該帳戶具有提款憑證,則餘額將在下一次驗證者掃描期間提出。
-
提款被設計為自動推送,會轉帳任何未主動貢獻於質押的 ETH。 包括已完成退出流程帳戶的全部餘額。
-無法手動請求提取特定數量的以太幣。
+無法手動請求提取特定數量的以太幣。
+
建議驗證操作者訪問質押啟動面板提款頁面以便找到更多關於驗證者需要為提款作出的準備、活動時間,以及提款相關的詳細資訊。
若要先在測試網上試用您的設定,請造訪 Hoodi 測試網質押啟動面板以開始使用。
-
-不能。 驗證者退出並成功提取其全部餘額後,任何後續存入該驗證者的資金都會在下一次驗證者掃描期間自動轉移到提款地址。 要重新質押以太幣,必須啟用新的驗證者。
+不能。 驗證者退出並成功提取其全部餘額後,任何後續存入該驗證者的資金都會在下一次驗證者掃描期間自動轉移到提款地址。 要重新質押以太幣,必須啟用新的驗證者。
+
## 延伸閱讀 {#further-reading}
diff --git a/public/content/translations/zh-tw/web3/index.md b/public/content/translations/zh-tw/web3/index.md
index bab57ee9af1..4d50e8ed304 100644
--- a/public/content/translations/zh-tw/web3/index.md
+++ b/public/content/translations/zh-tw/web3/index.md
@@ -1,6 +1,6 @@
---
-title: 什麼是 Web3?它為什麼很重要?
-description: Web3 簡介 - 全球資訊網再進化,以及它為何很重要。
+title: "什麼是 Web3?它為什麼很重要?"
+description: "Web3 簡介 - 全球資訊網再進化,以及它為何很重要。"
lang: zh-tw
---
@@ -69,7 +69,8 @@ Web3 允許透過 [非同質化代幣 (NFT)](/glossary/#nft) 實現直接所有
- 深入了解非同質化代幣
+ 深入了解非同質化代幣
+
更多關於 NFT 的資訊
@@ -97,7 +98,8 @@ Web 2.0 要求內容製作者相信平台不會更改規則,但抗審查是 We
- 了解更多關於去中心化自治組織的資訊
+ 了解更多關於去中心化自治組織的資訊
+
更多關於 DAO 的資訊
diff --git a/public/content/translations/zh-tw/what-are-apps/index.md b/public/content/translations/zh-tw/what-are-apps/index.md
index 4e2695667d9..2392da60572 100644
--- a/public/content/translations/zh-tw/what-are-apps/index.md
+++ b/public/content/translations/zh-tw/what-are-apps/index.md
@@ -1,14 +1,14 @@
---
-title: 以太坊應用程式
-metaTitle: 以太坊應用程式 | 以太坊上的去中心化應用程式
-description: 以太坊上的應用程式為免費、全球化的,使用公鏈而非私人公司服務器。 這代表您可以在每個專案使用相同的帳號,並維持您的隱私性。
+title: "以太坊應用程式"
+metaTitle: "以太坊應用程式 | 以太坊上的去中心化應用程式"
+description: "以太坊上的應用程式為免費、全球化的,使用公鏈而非私人公司服務器。 這代表您可以在每個專案使用相同的帳號,並維持您的隱私性。"
lang: zh-tw
template: use-cases
emoji: ":handshake:"
sidebarDepth: 2
showDropdown: false
image: /images/doge-computer.png
-summary: 以太坊上的應用程式為免費、全球化的,使用公鏈而非私人公司服務器。 這代表您可以在每個專案使用相同的帳號,並維持您的隱私性。
+summary: "以太坊上的應用程式為免費、全球化的,使用公鏈而非私人公司服務器。 這代表您可以在每個專案使用相同的帳號,並維持您的隱私性。"
---
## 具有強大能力的應用程式 {#apps-with-superpowers}
@@ -51,7 +51,6 @@ summary: 以太坊上的應用程式為免費、全球化的,使用公鏈而

-
## 以太坊應用程式如樂高積木 {#ethereum-apps-are-like-legos}
diff --git a/public/content/translations/zh-tw/whitepaper/index.md b/public/content/translations/zh-tw/whitepaper/index.md
index 242892135ed..451918e81e9 100644
--- a/public/content/translations/zh-tw/whitepaper/index.md
+++ b/public/content/translations/zh-tw/whitepaper/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊白皮書
-description: 介紹以太坊的白皮書,於 2013 年以太坊正式啟動之前發表。
+title: "以太坊白皮書"
+description: "介紹以太坊的白皮書,於 2013 年以太坊正式啟動之前發表。"
lang: zh-tw
sidebarDepth: 2
hideEditButton: true
diff --git a/public/content/translations/zh-tw/wrapped-eth/index.md b/public/content/translations/zh-tw/wrapped-eth/index.md
index cf56ed9d45b..978475304f2 100644
--- a/public/content/translations/zh-tw/wrapped-eth/index.md
+++ b/public/content/translations/zh-tw/wrapped-eth/index.md
@@ -1,6 +1,6 @@
---
-title: 甚麼是包裝以太幣 (WETH)
-description: 包裝以太幣 (WETH) 簡介 — 以太幣 (ETH) 的一種 ERC20 相容包裝函式。
+title: "甚麼是包裝以太幣 (WETH)"
+description: "包裝以太幣 (WETH) 簡介 — 以太幣 (ETH) 的一種 ERC20 相容包裝函式。"
lang: zh-tw
---
@@ -8,7 +8,8 @@ lang: zh-tw
-在 [WrapETH.com](https://www.wrapeth.com/) 連接你的錢包,即可在任何鏈上包裝或解包 ETH
+在 [WrapETH.com](https://www.wrapeth.com/) 連接你的錢包,即可在任何鏈上包裝或解包 ETH
+
以太幣 (ETH) 是以太坊的主要貨幣。 以太幣有多種用途,例如質押、作為貨幣使用、以及支付計算所需要的燃料費。 **包裝以太幣實際上是以太幣的升級形式,具備許多應用程式和 [ERC-20 代幣](/glossary/#erc-20)(即以太坊上其他類型的數位資產)所需的額外功能。** 要與這些代幣互動,以太幣需要遵循與它們相同的規則,這些規則被稱為 ERC-20 標準。
@@ -40,19 +41,16 @@ lang: zh-tw
你需要支付燃料費來使用包裝以太幣智慧型合約來兌換或贖回以太幣。
-
包裝以太幣通常被認為是安全的,因為它基於一個簡單且經過實證的智慧型合約。 包裝以太幣合約也已經經過正式驗證,這是以太坊上智慧型合約的最高安全標準。
-
除了本頁描述的 [包裝以太幣的規範化實作](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)外,還有其他變體存在於市場中。 這些可能是由應用程式開發者建立的自訂代幣,或在其他區塊鏈上發行的版本,可能會有不同的行為或具有不同的安全屬性。 **始終仔細檢查代幣資訊,以確認你正在與哪一種包裝以太幣實作進行互動。**
-
@@ -60,7 +58,6 @@ lang: zh-tw
- [以太坊主網](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
- [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1)
- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
-
## 延伸閱讀 {#further-reading}
diff --git a/public/content/translations/zh-tw/zero-knowledge-proofs/index.md b/public/content/translations/zh-tw/zero-knowledge-proofs/index.md
index 8f41c6dac89..07ad489cb60 100644
--- a/public/content/translations/zh-tw/zero-knowledge-proofs/index.md
+++ b/public/content/translations/zh-tw/zero-knowledge-proofs/index.md
@@ -1,6 +1,6 @@
---
-title: 零知識證明
-description: 零知識證明的非技術性介紹,適合新手閱讀。
+title: "零知識證明"
+description: "零知識證明的非技術性介紹,適合新手閱讀。"
lang: zh-tw
---
@@ -59,8 +59,8 @@ lang: zh-tw
在去中心化身份案例研究中深入了解不丹國家數位身分證。
-
-
+
+
### 人性證明 {#proof-of-humanity}
From b4373e80d50e1ff371c24cbb68107b058308dd2c Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 12:41:49 +0000
Subject: [PATCH 4/7] fix(i18n): run sanitizer on zh-tw translations
---
.../translations/zh-tw/ai-agents/index.md | 7 +-
.../community/events/organizing/index.md | 28 +-
.../zh-tw/community/grants/index.md | 3 +-
.../zh-tw/community/online/index.md | 25 +-
.../adding-desci-projects/index.md | 2 +-
.../adding-developer-tools/index.md | 2 +-
.../contributing/adding-wallets/index.md | 2 +-
.../translation-program/playbook/index.md | 6 +-
.../translation-program/resources/index.md | 2 +-
.../translatathon/details/index.md | 2 +-
.../translatathon/index.md | 2 +-
.../content/translations/zh-tw/dao/index.md | 4 +-
.../zh-tw/decentralized-identity/index.md | 1 +
.../content/translations/zh-tw/defi/index.md | 3 +-
.../docs/consensus-mechanisms/pow/index.md | 2 +-
.../mining/mining-algorithms/ethash/index.md | 2 +-
.../index.md | 2 +-
.../web3-secret-storage-definition/index.md | 4 +-
.../developers/docs/evm/opcodes/index.md | 2 +-
.../developers/docs/smart-contracts/index.md | 2 +-
.../docs/smart-contracts/languages/index.md | 17 +
.../docs/smart-contracts/testing/index.md | 46 +-
.../docs/smart-contracts/upgrading/index.md | 2 +-
.../docs/standards/tokens/erc-1155/index.md | 2 +-
.../docs/standards/tokens/erc-4626/index.md | 2 +-
.../developers/docs/wrapped-eth/index.md | 8 +-
.../tutorials/all-you-can-cache/index.md | 2 +-
.../developers/tutorials/app-plasma/index.md | 2 +-
.../index.md | 2 +-
.../erc-721-vyper-annotated-code/index.md | 3 +-
.../tutorials/erc20-annotated-code/index.md | 2 +-
.../erc20-with-safety-rails/index.md | 2 +-
.../tutorials/ethereum-for-web2-auth/index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 4 +-
.../index.md | 4 +-
.../how-to-use-tellor-as-your-oracle/index.md | 2 +-
.../tutorials/ipfs-decentralized-ui/index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../reverse-engineering-a-contract/index.md | 4 +-
.../tutorials/run-node-raspberry-pi/index.md | 2 +-
.../tutorials/scam-token-tricks/index.md | 2 +-
.../tutorials/secret-state/index.md | 2 +-
.../secure-development-workflow/index.md | 2 +-
.../index.md | 2 +-
.../tutorials/server-components/index.md | 2 +-
.../developers/tutorials/short-abi/index.md | 2 +-
.../index.md | 2 +-
.../tutorials/stealth-addr/index.md | 2 +-
.../token-integration-checklist/index.md | 2 +-
.../uniswap-v2-annotated-code/index.md | 5 +-
.../index.md | 4 +-
.../index.md | 5 +-
.../how-to-revoke-token-access/index.md | 3 +-
.../zh-tw/guides/how-to-swap-tokens/index.md | 3 +-
.../zh-tw/guides/how-to-use-a-bridge/index.md | 3 +-
.../zh-tw/guides/how-to-use-a-wallet/index.md | 3 +-
.../content/translations/zh-tw/nft/index.md | 3 +-
.../translations/zh-tw/payments/index.md | 13 +-
.../zh-tw/prediction-markets/index.md | 2 +
.../translations/zh-tw/privacy/index.md | 2 +-
.../zh-tw/real-world-assets/index.md | 2 +-
.../zh-tw/roadmap/beacon-chain/index.md | 1 +
.../zh-tw/roadmap/fusaka/index.md | 8 +-
.../zh-tw/roadmap/fusaka/peerdas/index.md | 4 +-
.../zh-tw/roadmap/merge/issuance/index.md | 6 +
.../zh-tw/roadmap/pectra/index.md | 10 +-
.../zh-tw/roadmap/pectra/maxeb/index.md | 14 +-
.../zh-tw/roadmap/verkle-trees/index.md | 1 +
.../translations/zh-tw/security/index.md | 8 +-
.../translations/zh-tw/staking/pools/index.md | 4 +-
.../translations/zh-tw/staking/saas/index.md | 2 +
.../translations/zh-tw/staking/solo/index.md | 3 +-
.../content/translations/zh-tw/web3/index.md | 6 +-
.../translations/zh-tw/wrapped-eth/index.md | 3 +-
src/scripts/i18n/post_import_sanitize.ts | 1437 -----------------
79 files changed, 198 insertions(+), 1598 deletions(-)
delete mode 100644 src/scripts/i18n/post_import_sanitize.ts
diff --git a/public/content/translations/zh-tw/ai-agents/index.md b/public/content/translations/zh-tw/ai-agents/index.md
index dbe6bfebf4e..f21080daecf 100644
--- a/public/content/translations/zh-tw/ai-agents/index.md
+++ b/public/content/translations/zh-tw/ai-agents/index.md
@@ -89,7 +89,7 @@ x402 將以太坊轉變為自主代理的可程式化經濟層,實現按次付
這將使代理更容易在完全去中心化的環境中互相發現、驗證和交易。
-## 以太坊上的AI智能體{#ai-agents-on-ethereum}
+## 以太坊上的AI智能體 {#ai-agents-on-ethereum}
我們正開始探索 AI 智能體的全部潛力,而且已經有項目在人工智慧和區塊鏈之間發揮協同效應 —— 特別是在透明度和貨幣化方面。
@@ -99,7 +99,7 @@ x402 將以太坊轉變為自主代理的可程式化經濟層,實現按次付
-## 由智能體控制的錢包{#agent-controlled-wallets}
+## 由智能體控制的錢包 {#agent-controlled-wallets}
像 Luna 或 AIXBT 這樣的智能代理控制著自己的鏈上錢包(AIXBT 錢包、Luna 錢包)(https://clusters.xyz/aixbt), [Luna的錢包](https://zapper.xyz/account/0x0d177181e3763b20d47dc3a72dd584368bd8bf43)),使它們能夠給粉絲打賞並參與經濟活動。
@@ -111,9 +111,10 @@ x402 將以太坊轉變為自主代理的可程式化經濟層,實現按次付
建議須知
AI智能體及其相關工具仍然處於早期發展且實驗性階段,要謹慎使用。
+
-## 在使用智能體聊天指令時要管好錢包。{#control-your-wallet-using-chat-commands}
+## 在使用智能體聊天指令時要管好錢包。 {#control-your-wallet-using-chat-commands}
你可以跳過去中心化金融的複雜交互界面,用簡單的智能體聊天指令管理加密貨幣。
diff --git a/public/content/translations/zh-tw/community/events/organizing/index.md b/public/content/translations/zh-tw/community/events/organizing/index.md
index ad8f21b80ce..d347728896f 100644
--- a/public/content/translations/zh-tw/community/events/organizing/index.md
+++ b/public/content/translations/zh-tw/community/events/organizing/index.md
@@ -5,7 +5,7 @@ lang: zh-tw
hideEditButton: true
---
-# 如何組織一次以太坊活動{#how-to-organize-an-ethereum-event}
+# 如何組織一次以太坊活動 {#how-to-organize-an-ethereum-event}
建立強大且充滿活力的社群是以太坊生態系統成長的核心。 無論您是打算組織聚會、研討會或大型會議,活動的成功都有賴於當地社交網路的連結與參與。 這個指南將協助您為一個活躍的以太坊社群奠定基礎,並一步一步帶領您組織一個難忘又有影響力的會議。
@@ -49,7 +49,7 @@ hideEditButton: true
通過提供多樣化的學習、協作與成長機會,您能確保社區保持活躍狀態,隨時準備迎接更大型的活動,例如組織會議。
-## 活動{#event}
+## 活動 {#event}
### 何時是舉辦活動的最佳時機? {#when-is-the-right-time-to-organize-an-event}
@@ -57,7 +57,7 @@ hideEditButton: true
你應綜合考量社區發展成熟度、市場環境、團隊組建情況以及當地生態圈的活躍度(例如潛在贊助商資源)。
-### KYC——了解你的社區{#kyc-know-your-community}
+### KYC——了解你的社區 {#kyc-know-your-community}
組織活動最重要的步驟之一就是了解你的社區。 正如金融服務中的“了解你的客戶”(KYC),“了解你的社區”(KYC)意味着花時間去理解本地受眾的具體需求、偏好和特徵。 這種理解將有助於您量身定製會議內容,確保其成功與內容相關性。
@@ -65,7 +65,7 @@ hideEditButton: true
在第一年,你的受眾群體主要來自本地社區,因此籌辦大型活動時,所有工作都應圍繞該社區的需求和規模展開。
-### 從哪裡開始{#where-to-start}
+### 從哪裡開始 {#where-to-start}
在籌辦會議時,最初要做什麼往往令人不知所措。 但只要制定清晰的計劃和框架,你就能將整個過程分解為可控的任務。 我們將逐一分析它們。
@@ -80,13 +80,13 @@ hideEditButton: true
- **考慮市場狀況**
- **給自己充足的時間來安排一切**——至少九個月
-### 如何評估一個團隊{#how-to-assemble-a-team}
+### 如何評估一個團隊 {#how-to-assemble-a-team}
選擇那些與你志同道合、能互補你技能的人。 有些團隊以集體形式運作,有些則設有明確分工——找出最適合你的方式。 保持定期溝通並明確期望至關重要。 儘管人們很想依賴通訊平臺來策劃活動,但我們建議選擇任務管理平臺(例如Notion、Basecamp、Trello、Asana,甚至經典的Google表格)來統籌安排並追蹤各項待辦事項。 擁有一個運作良好且組織有序的團隊至關重要。
不同的以太坊組織團隊在各自團隊中承擔着不同的職責,但都包含負責後勤、預算、市場營銷、項目策劃、設計以及合作夥伴關係的人員。
-### 活動方案:成功活動的關鍵要素{#the-program-a-key-element-of-a-successful-event}
+### 活動方案:成功活動的關鍵要素 {#the-program-a-key-element-of-a-successful-event}
要舉辦一場真正有價值且令人難忘的會議,**議程安排至關重要**。 在這個領域,你絕不能有絲毫妥協。 雖然贊助商對活動融資至關重要,但觀眾的體驗及其獲得的價值必須始終優先考慮。 充斥着過量宣傳內容和無休止贊助商推銷的活動安排,不僅會使你同觀眾疏遠,更會損害活動的公信力。
@@ -94,7 +94,7 @@ hideEditButton: true
\*\*在挑選演講嘉賓時,應至少在會議召開前六個月啟動徵集流程,以吸引高質量的投稿並為議程策劃預留充足時間。\*\*負責嘉賓篩選的人員需具備豐富的行業經驗,並對生態系統有深刻理解。 這確保他們能夠識別有價值、有見地的貢獻,並保持內容的高標準。
-### 在哪裡尋找經濟支持{#where-to-find-financial-support}
+### 在哪裡尋找經濟支持 {#where-to-find-financial-support}
舉辦一場高質量的會議需要承擔高昂的成本——場地租賃、宣傳物料、餐飲服務、活動製作以及其他無數開支。 儘早獲得資金支持至關重要,這能確保活動達到專業水準,並為參與者提供卓越的體驗。
@@ -120,7 +120,7 @@ hideEditButton: true
既然談到經濟問題,請牢記:每投入一美元打造卓越的參會者體驗,都將獲得指數級的回報。 高品質的製作、舒適的場地、精心準備的禮品以及組織有序的配套活動,共同打造出令人難忘的體驗,讓參與者在會議結束後仍會津津樂道。 滿意的參與者將成為您最忠實的擁護者,並確保活動的長期成功。
-### 物流{#logistics}
+### 物流 {#logistics}
在確保資金到位的同時,您應將重點放在後勤保障上。 一場組織完善的會議需要在多個領域進行周密規劃,從會場布置到參會者體驗都需精心安排。 擁有具備紮實活動組織經驗的人員——不一定是Web3活動,但必須是活動策劃方面的經驗——將產生巨大影響。 經驗豐富的物流主管能夠預見潛在問題,並在問題顯現前予以解決,從而節省時間、金錢和精力。
@@ -132,11 +132,11 @@ hideEditButton: true
對於知名度較低的地方,這一點尤為關鍵。 來自世界各地的與會者和贊助商需要確信他們能夠輕鬆且安全地出行。 考察機場交通便利性、公共交通系統以及住宿選擇等方面的因素。 同時,明智的做法是考慮該地區的文化和政治環境,以避免可能阻礙國際參與者的複雜因素,例如簽證政策。
-### 如何有效推廣活動{#how-to-promote-the-event}
+### 如何有效推廣活動 {#how-to-promote-the-event}
有效推廣活動是吸引目標受眾並營造熱烈氛圍的關鍵。 精心設計的推廣策略能確保您的會議獲得應有的關注度和參與度。 設計在您的品牌建設中同樣扮演着重要角色,因此您務必為此預留預算。
-#### 社交媒體{#social-media}
+#### 社交媒體 {#social-media}
X.com將成為您社交媒體推廣的核心支柱。 儘量保持活躍並堅持在該平臺發帖,同時積極參與各類討論——既要使用個人賬號參與,也要通過組織賬號參與互動。
@@ -146,11 +146,11 @@ X.com將成為您社交媒體推廣的核心支柱。 儘量保持活躍並堅
與不同以太坊組織者的合作能藉助現有網絡擴大影響力,尤其當你從零起步時。 提供社區折扣,與其他活動進行交叉推廣,並邀請合作夥伴共同舉辦配套活動或工作坊。
-#### 大學拓展活動{#university-outreach}
+#### 大學拓展活動 {#university-outreach}
通過學生社團或教授聯繫當地理工科和經濟學院系,推廣本次活動。 與高校開展合作有助於吸引青年人才、研究人員及未來行業專業人士,從而加強學術界與以太坊生態系統的聯繫。 這對於組織黑客松活動尤為理想,學生們往往能帶來新穎的創意、飽滿的熱情以及紮實的技術基礎。
-#### 媒體{#media}
+#### 媒體 {#media}
聯繫專注於Web3領域的媒體機構和通訊刊物,爭取活動報道。 儘管Web3媒體通常期望為其公關文章收取費用,但若您沒有預算進行付費推廣,也可以提供免費門票或安排與知名演講嘉賓及贊助商的專訪機會。 創建一個公關資料包,內含新聞稿及若干視覺素材,以便在社交媒體或網站上以不同格式進行推廣。 此外,還應擴大合作範圍,涵蓋本地記者乃至內容創作者(只要他們具備良好聲譽),只要他們能報道科技領域,這對於向更廣泛的受眾展示活動至關重要。 這有助於彌合加密行業與廣大公眾之間的鴻溝,吸引主流科技和商業圈的關注。
@@ -201,11 +201,11 @@ X.com將成為您社交媒體推廣的核心支柱。 儘量保持活躍並堅
關鍵在於保持勢頭活躍。 繼續與社區保持互動,分享根據他們的反饋所取得的進展,並為下一場活動營造令人興奮的氛圍。 通過維持這種聯繫,確保會議的影響力超越活動本身,鞏固關係並為未來的成功奠定基礎。
-## 致謝{#acknowledgement}
+## 致謝 {#acknowledgement}
衷心感謝所有為本文貢獻見解的同仁:來自布拉迪斯拉發以太坊的斯拉沃·法比西克;來自Kipu以太坊和拉丁美洲以太坊的蘿拉;來自貝爾格萊德以太坊的坦雅·姆拉德諾維奇;來自波哥大以太坊的胡安·大衛;來自華沙以太坊的莫妮卡·扎伊奇克;來自那不勒斯以太坊的拉斐爾·奧雷菲斯;來自利雅得以太坊的肖武(玲);來自urbe.eth的馬可;來自都柏林以太坊的考蘭·沃爾什;來自克盧日以太坊的亞歷克斯·馬萊斯;以及來自斯洛文尼亞以太坊的斯坦科·德維奇。
-## 資源{#resources}
+## 資源 {#resources}
播客:如何從頭到尾組織和推廣一場以太坊活動:
diff --git a/public/content/translations/zh-tw/community/grants/index.md b/public/content/translations/zh-tw/community/grants/index.md
index d9ca01063b7..1babc1bb6e4 100644
--- a/public/content/translations/zh-tw/community/grants/index.md
+++ b/public/content/translations/zh-tw/community/grants/index.md
@@ -12,8 +12,7 @@ lang: zh-tw
-創辦人們,需要協助加速您的業務嗎? [前往創辦人支援頁面](/founders/)
-
+創辦人們,需要協助加速您的業務嗎? [前往創辦人支援頁面](/founders/)
## 廣泛的以太坊生態系統 {#broad-ethereum-ecosystem}
diff --git a/public/content/translations/zh-tw/community/online/index.md b/public/content/translations/zh-tw/community/online/index.md
index fc9ccc653e4..47befebe4ae 100644
--- a/public/content/translations/zh-tw/community/online/index.md
+++ b/public/content/translations/zh-tw/community/online/index.md
@@ -34,15 +34,34 @@ lang: zh-tw
## 論壇 {#forums}
-r/ethereum - 所有關於以太坊的事物 r/ethfinance - 以太坊的金融面,包含 DeFi r/ethdev - 專注於以太坊開發 r/ethtrader - 趨勢與市場分析 r/ethstaker - 歡迎所有對在以太坊上進行質押感興趣的人 Fellowship of Ethereum Magicians - 以以太坊技術標準為核心的社群 Ethereum Stackexchange - 為以太坊開發者提供討論與幫助 Ethereum Research - 最具影響力的密碼經濟學研究論壇
+r/ethereum - 所有關於以太坊的事物
+r/ethfinance - 以太坊的金融面,包含 DeFi
+r/ethdev - 專注於以太坊開發
+r/ethtrader - 趨勢與市場分析
+r/ethstaker - 歡迎所有對在以太坊上進行質押感興趣的人
+Fellowship of Ethereum Magicians - 以以太坊技術標準為核心的社群
+Ethereum Stackexchange - 為以太坊開發者提供討論與幫助
+Ethereum Research - 最具影響力的密碼經濟學研究論壇
## 聊天室 {#chat-rooms}
-Ethereum Cat Herders - 為以太坊開發提供專案管理支援的社群 Ethereum Hackers - 由 ETHGlobal 經營的 Discord 聊天室:一個為全球以太坊駭客打造的線上社群 CryptoDevs - 專注於以太坊開發的 Discord 社群 EthStaker Discord - 為現有和潛在質押者提供由社群經營的指導、教育、支援和資源 Ethereum.org 網站團隊 - 來和團隊及社群成員聊聊 ethereum.org 的網站開發和設計吧 Matos Discord - Web3 創作者社群,是開發者、產業領袖和以太坊愛好者的聚集地。 我們熱愛 web3 開發、設計及文化。 來和我們一起開發吧。 Solidity Gitter - Solidity 開發聊天室 (Gitter) Solidity Matrix - Solidity 開發聊天室 (Matrix) Ethereum Stack Exchange - 問答論壇 Peera Community Forum - 去中心化問答論壇
+Ethereum Cat Herders - 為以太坊開發提供專案管理支援的社群
+Ethereum Hackers - 由 ETHGlobal 經營的 Discord 聊天室:一個為全球以太坊駭客打造的線上社群
+CryptoDevs - 專注於以太坊開發的 Discord 社群
+EthStaker Discord - 為現有和潛在質押者提供由社群經營的指導、教育、支援和資源
+Ethereum.org 網站團隊 - 來和團隊及社群成員聊聊 ethereum.org 的網站開發和設計吧
+Matos Discord - Web3 創作者社群,是開發者、產業領袖和以太坊愛好者的聚集地。 我們熱愛 web3 開發、設計及文化。 來和我們一起開發吧。
+Solidity Gitter - Solidity 開發聊天室 (Gitter)
+Solidity Matrix - Solidity 開發聊天室 (Matrix)
+Ethereum Stack Exchange - 問答論壇
+Peera Community Forum - 去中心化問答論壇
## YouTube 與 X (前身為 Twitter) {#youtube-and-twitter}
-以太坊基金會 - 掌握以太坊基金會的最新資訊 @ethereum - 以太坊社群的主要帳戶 @ethereumfndn - 以太坊基金會的官方帳戶 @ethdotorg - 通往以太坊的入口網站,為我們日益壯大的全球社群而打造
+以太坊基金會 - 掌握以太坊基金會的最新資訊
+@ethereum - 以太坊社群的主要帳戶
+@ethereumfndn - 以太坊基金會的官方帳戶
+@ethdotorg - 通往以太坊的入口網站,為我們日益壯大的全球社群而打造
diff --git a/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md b/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md
index 60fa4397c4d..09a64cee32c 100644
--- a/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-desci-projects/index.md
@@ -30,7 +30,7 @@ lang: zh-tw
- **第三方審核** - 您的產品已由可信的第三方,就漏洞方面進行專業審核。
- **聯絡點** - 專案的聯絡點(可能是 DAO 或社群的代表)將能在進行變更時,大力協助我們取得準確的資訊。 這樣將在日後收集資訊時,確保 ethereum.org 的更新可控。
-## 維護{#maintenance}
+## 維護 {#maintenance}
由於以太坊的流動性,團隊和產品來來去去,每天都有創新,所以我們將對我們的內容進行例行檢查,以便:
diff --git a/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md b/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md
index 571c45780cb..b5462fdd588 100644
--- a/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-developer-tools/index.md
@@ -46,7 +46,7 @@ description: "我們在 ethereum.org 上架開發者工具的標準"
---
-## 產品訂購{#product-ordering}
+## 產品訂購 {#product-ordering}
除非指定產品以特定順序排列,如按照英文字母順序,否則將按照最早至最晚新增到頁面的順序顯示。 換句話說,最新的產品會被新增到清單的底部。
diff --git a/public/content/translations/zh-tw/contributing/adding-wallets/index.md b/public/content/translations/zh-tw/contributing/adding-wallets/index.md
index c5ac4e3c3b3..299e713a560 100644
--- a/public/content/translations/zh-tw/contributing/adding-wallets/index.md
+++ b/public/content/translations/zh-tw/contributing/adding-wallets/index.md
@@ -66,7 +66,7 @@ lang: zh-tw
提交一個議題
-## 維護{#maintenance}
+## 維護 {#maintenance}
由於以太坊的流動性,團隊和產品來來去去,每天都有創新,所以我們將對我們的內容進行例行檢查,以便:
diff --git a/public/content/translations/zh-tw/contributing/translation-program/playbook/index.md b/public/content/translations/zh-tw/contributing/translation-program/playbook/index.md
index f025f7df827..ffd55f2fb00 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/playbook/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/playbook/index.md
@@ -4,7 +4,7 @@ lang: zh-tw
description: "建立翻譯項目的實用技巧與重要注意事項合集"
---
-# 翻譯程序操作手冊{#translation-program-playbook}
+# 翻譯程序操作手冊 {#translation-program-playbook}
英語是世界上使用最廣泛的語言之一,也是迄今為止全球學習人數最多的語言。 由於英語是互聯網上最常用的語言——尤其在社交媒體領域——且多語言編程語言較為稀缺,區塊鏈領域的大部分內容都以英語為母語編寫。
@@ -16,7 +16,7 @@ description: "建立翻譯項目的實用技巧與重要注意事項合集"
本指南旨在解決內容本地化過程中常見的挑戰與誤解。 它提供了一個分步指南,涵蓋內容管理、翻譯與審校流程、質量保證、譯員招募以及本地化流程中的其他關鍵環節。
-## 内容管理{#content-management}
+## 内容管理 {#content-management}
翻譯內容管理是指通過自動化翻譯工作流程,消除重複性手動操作,提升效率與質量,實現更佳管控,並促進協作的過程。
@@ -32,7 +32,7 @@ description: "建立翻譯項目的實用技巧與重要注意事項合集"
[關於多語言內容管理的用語](https://phrase.com/blog/posts/multilingual-content-management/)
-### 翻譯管理軟件{#translation-management-software}
+### 翻譯管理軟件 {#translation-management-software}
市面上有許多翻譯管理系統和本地化工具,軟件的選擇主要取決於您的具體需求。
diff --git a/public/content/translations/zh-tw/contributing/translation-program/resources/index.md b/public/content/translations/zh-tw/contributing/translation-program/resources/index.md
index 68fa6b8993d..402bd3296cb 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/resources/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/resources/index.md
@@ -4,7 +4,7 @@ lang: zh-tw
description: "對 ethereum.org 譯者有用的資源"
---
-# 資源{#resources}
+# 資源 {#resources}
你可以在下面找到一些對 ethereum.org 譯者有用的指南和工具,以及翻譯社群和更新。
diff --git a/public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md b/public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md
index eb24e5b821e..fea71dcf770 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/translatathon/details/index.md
@@ -1,7 +1,7 @@
---
title: "詳細資訊與規則"
lang: zh-tw
-template: "翻譯松"
+template: translatathon
---

diff --git a/public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md b/public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md
index 0975e80b670..b4fc8f50c03 100644
--- a/public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md
+++ b/public/content/translations/zh-tw/contributing/translation-program/translatathon/index.md
@@ -1,7 +1,7 @@
---
title: "2025 ethereum.org 翻譯松"
lang: zh-tw
-template: "翻譯馬拉松"
+template: translatathon
---
diff --git a/public/content/translations/zh-tw/dao/index.md b/public/content/translations/zh-tw/dao/index.md
index 8a33b083ba7..8d0d2fbba24 100644
--- a/public/content/translations/zh-tw/dao/index.md
+++ b/public/content/translations/zh-tw/dao/index.md
@@ -70,9 +70,7 @@ DAO 的骨幹是它的[智慧型合約](/glossary/#smart-contract),它定義
委託類似去中心化自治組織版本的代議民主。 代幣持有者向自我提名、並承諾管理協定且掌握最新消息的使用者委託選票。
-#### 一個著名的例子 {#governance-example}
-
-[ENS](https://claim.ens.domains/delegate-ranking) – ENS 持有者可以將他們的投票委派給活躍的社群成員來代表他們。
+#### 一個著名的例子 {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – ENS 持有者可以將他們的投票委派給活躍的社群成員來代表他們。
### 自動交易管理體系 {#governance-example}
diff --git a/public/content/translations/zh-tw/decentralized-identity/index.md b/public/content/translations/zh-tw/decentralized-identity/index.md
index 82444abc242..e6977b9fb12 100644
--- a/public/content/translations/zh-tw/decentralized-identity/index.md
+++ b/public/content/translations/zh-tw/decentralized-identity/index.md
@@ -108,6 +108,7 @@ QuarkID 系統建構於以太坊 [Layer 2](/layer-2/) 網路 ZKSync Era 之上
身分證明與身分識別不同。 證明_包含_用來指稱特定身分的身分識別,並對與此身分相關的屬性進行宣告。 因此,你的駕駛執照具有身分識別(姓名、出生日期、地址),但也是關於你合法駕駛權利的證明。
### 什麼是去中心化身分識別? {#what-are-decentralized-identifiers}
+
你的法定姓名或電子郵件地址等傳統身分識別依賴於第三方——政府和電子郵件提供商。 去中心化身分識別 (DID) 則不同-它們不由任何中央實體發行、管理或控制。
去中心化身分識別由個人發行、持有和控制。 一個[以太坊帳戶](/glossary/#account)就是去中心化身分識別的一個範例。 你可以根據需要建立任意數量的帳戶,無需任何人的許可,也無需將它們儲存在中央註冊系統中。
diff --git a/public/content/translations/zh-tw/defi/index.md b/public/content/translations/zh-tw/defi/index.md
index ac63c98b3f4..dcffcf178fe 100644
--- a/public/content/translations/zh-tw/defi/index.md
+++ b/public/content/translations/zh-tw/defi/index.md
@@ -67,8 +67,7 @@ summaryPoint3: "基於所有人都可以編寫的開放原始碼技術。"
- 如果你是剛開始使用以太坊,請嘗試我們推薦的去中心化金融應用程式。
-
+ 如果你是剛開始使用以太坊,請嘗試我們推薦的去中心化金融應用程式。
探索去中心化金融應用程式
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md
index 26c33af4285..8732a1bbb27 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/index.md
@@ -39,7 +39,7 @@ lang: zh-tw
該區塊資料與工作量證明直接相關。
-### 工作量證明中的「工作」{#the-work}
+### 工作量證明中的「工作」 {#the-work}
工作量證明協定 Ethash 要求礦工經過激烈的試錯競賽,找出一個區塊的隨機數。 只有具備有效隨機數的區塊才能新增到鏈中。
diff --git a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
index 5c31912b956..83cf3a9149a 100644
--- a/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
+++ b/public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
@@ -47,7 +47,7 @@ CACHE_ROUNDS = 3 # 快取產生中的回合數
ACCESSES = 64 # hashimoto 迴圈中的存取次數
```
-### 使用「SHA3」{#sha3}
+### 使用「SHA3」 {#sha3}
以太坊的開發恰逢 SHA3 標準的製定,標準流程對最終確定的雜湊值演算法的填充做了後期改動,使得以太坊的「sha3_256」和「sha3_512」雜湊值不是標準的 sha3 雜湊值,而是在其他情況下常被稱為「Keccak-256」和「Keccak-512」的變體。 請參閱討論,例如:[此處](https://eips.ethereum.org/EIPS/eip-1803)、[此處](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)或[此處](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)。
diff --git a/public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
index 8a6606ff89e..bb6c094bb4f 100644
--- a/public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
@@ -21,7 +21,7 @@ lang: zh-tw
- 讓所有的節點可以很簡單的獲得資訊是必要的嗎?
- 安全必要條件
-## 安全必要條件{#security-requirements}
+## 安全必要條件 {#security-requirements}
總的來說,資訊安全由三個屬性構成:
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
index 858d1258106..240b399a17d 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
@@ -1,6 +1,6 @@
---
-title: Web3 金鑰儲存的定義
-description: Web3 金鑰儲存的正式定義
+title: "Web3 金鑰儲存的定義"
+description: "Web3 金鑰儲存的正式定義"
lang: zh-tw
sidebarDepth: 2
---
diff --git a/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md b/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
index d46adf64e8e..39b28bb12e8 100644
--- a/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
+++ b/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
@@ -4,7 +4,7 @@ description: "以太坊虛擬機可用的所有作業碼清單。"
lang: zh-tw
---
-## 概覽{#overview}
+## 概覽 {#overview}
這是 [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes) 上 EVM 參考頁面的更新版本。
內容也參考自 [黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)、[Jello Paper](https://jellopaper.org/evm/) 和 [geth](https://github.com/ethereum/go-ethereum) 的實作。
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 a15996b3ee7..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
@@ -4,7 +4,7 @@ description: "智慧型合約概觀,重點介紹其特點及限制。"
lang: zh-tw
---
-## 智慧型合約是什麼? 什麼是智能合約?{#what-is-a-smart-contract}
+## 智慧型合約是什麼? 什麼是智能合約? {#what-is-a-smart-contract}
「智慧型合約」就是在以太坊區塊鏈上執行的程式。 這是一系列存在於以太坊區塊鏈特定地址的程式碼(函數)及資料(狀態)。
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 6b846d955e3..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
@@ -123,23 +123,30 @@ contract Coin {
# 公開拍賣
# 拍賣參數
+
# 受益人從最高出價者收到款項
+
beneficiary: public(address)
auctionStart: public(uint256)
auctionEnd: public(uint256)
# 目前拍賣狀態
+
highestBidder: public(address)
highestBid: public(uint256)
# 結束時設為 true,不允許任何變更
+
ended: public(bool)
# 追蹤已退款的出價,以便遵循提款模式
+
pendingReturns: public(HashMap[address, uint256])
# 建立一個簡單的拍賣,競標時間為 `_bidding_time`
+
# 秒,代表受益人地址 `_beneficiary`。
+
@external
def __init__(_beneficiary: address, _bidding_time: uint256):
self.beneficiary = _beneficiary
@@ -147,9 +154,13 @@ def __init__(_beneficiary: address, _bidding_time: uint256):
self.auctionEnd = self.auctionStart + _bidding_time
# 以與此交易一起傳送的價值
+
# 參與競標。
+
# 只有在未贏得拍賣時,
+
# 價值才會被退還。
+
@external
@payable
def bid():
@@ -164,9 +175,13 @@ def bid():
self.highestBid = msg.value
# 提領先前已退款的出價。這裡使用提款模式
+
# 以避免安全問題。如果退款是直接
+
# 作為 bid() 的一部分傳送,惡意的競標合約可能會阻止
+
# 這些退款,從而阻止新的更高出價進入。
+
@external
def withdraw():
pending_amount: uint256 = self.pendingReturns[msg.sender]
@@ -174,7 +189,9 @@ def withdraw():
send(msg.sender, pending_amount)
# 結束拍賣並將最高出價
+
# 傳送給受益人。
+
@external
def endAuction():
# 將與其他合約互動的函式 (即呼叫函式或傳送以太幣)
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 f0261fb22f9..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
@@ -12,29 +12,29 @@ lang: zh-tw
本頁會解釋如何在部署到以太坊網路前進行智慧型合約的測試, 本文假設你已熟悉[智能合約](/developers/docs/smart-contracts/)。
-## 何謂智慧型合約測試? 何謂智能合約測試?{#what-is-smart-contract-testing}
+## 何謂智慧型合約測試? 何謂智能合約測試? {#what-is-smart-contract-testing}
智慧型合約測試測試是指確認智慧型合約的程式碼會如預期般執行的測試過程。 測試有助於檢查特定的智慧型合約是否滿足可靠性、可用性及安全性要求。
雖然測試方法各異,但大多數都是使用智慧型合約預計處理的資料中的一小部分樣本,來執行該智慧型合約。 如果合約對採樣資料產出正確的結果,那我們就認定它運作正常。 大多數測試工具都提供資源,用於編寫和執行[測試案例](https://en.m.wikipedia.org/wiki/Test_case),以檢查合約的執行是否符合預期結果。
-### 測試智慧型合約的重要性 測試智能合約的重要性{#importance-of-testing-smart-contracts}
+### 測試智慧型合約的重要性 測試智能合約的重要性 {#importance-of-testing-smart-contracts}
由於智能合約通常管理高價值的金融資產,微小的程式設計錯誤可能會,且經常會導致[使用者蒙受巨大損失](https://rekt.news/leaderboard/)。 嚴密的測試則可以幫助你及早發現智慧型合約程式碼裡的缺陷與問題,並在它們發佈到主網前進行修復。
雖然在發現漏洞時可以升級合約,但升級過程很複雜,如果處理不當,可能會[導致錯誤](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)。 不僅如此,合約升級打破了區塊鏈的不可篡改性原則,也讓使用者需要接受額外的信任假設。 相反地,我們應制定完整的合約測試計畫,來降低智慧型合約的安全性風險,避免在合約部署後需要進行複雜的邏輯升級。
-## 測試智能合約的方法{#methods-for-testing-smart-contracts}
+## 測試智能合約的方法 {#methods-for-testing-smart-contracts}
測試以太坊智能合約的方法分為兩大類:**自動化測試**和**手動測試**。 自動化測試與手動測試各有優缺,兩者可以併用以建立穩健的合約分析計畫。
-### 自動化測試{#automated-testing}
+### 自動化測試 {#automated-testing}
自動化測試使用工具來自動偵測智慧型合約程式碼在執行時的錯誤, 自動化測試的好處在於使用[腳本](https://www.techtarget.com/whatis/definition/script?amp=1)來引導對合約功能的評估。 寫成指令碼的測試可以被安排重複執行來減少人力介入,這讓自動化測試比手動測試方式更有效率。
自動化測試在以下情境特別有用:測試的重複性高且費時、難以採用手動方式進行、容易出現人為錯誤,或牽涉到評估關鍵的合約函式。 但自動化測試工具有其缺點——它們可能會遺漏某些錯誤,並產生許多[誤報](https://www.contrastsecurity.com/glossary/false-positive)。 因此,將自動化測試與手動測試並用於智慧型合約較為理想。
-### 手動測試{#manual-testing}
+### 手動測試 {#manual-testing}
手動測試需要真人的輔助,需要逐一執行測試套件中的每一個測試用例,來分析智慧型合約的正確性。 這和自動化測試不同,沒辦法同時在一個合約上執行多個獨立的測試,並得到一份顯示所有成功與失敗測試的報告。
@@ -42,15 +42,15 @@ lang: zh-tw
有效的手動測試需要大量的資源(技術、時間、金錢與人力),而且有可能在執行測試時因為人為錯誤而遺漏一些錯誤。 但手動測試仍然是有益的,舉例來說,一個真人測試者(如審計員)或許可以用直覺來找出一些可能被自動化測試工具遺漏的邊緣案例。
-## 智能合約的自動化測試{#automated-testing-for-smart-contracts}
+## 智能合約的自動化測試 {#automated-testing-for-smart-contracts}
-### 單元測試{#unit-testing-for-smart-contracts}
+### 單元測試 {#unit-testing-for-smart-contracts}
單元測試分別評估各個合約函式並確認每個元件都能正常運作。 好的單元測試應該要簡單並且快速地運作,並在有測試失敗時讓人清楚地知道問題發生在哪。
單元測試在確認函式回傳預計的值以及函式執行後正確更新合約存儲方面很有用。 此外,在更改合約的程式碼庫之後運行單元測試,可以確保新增的新邏輯並沒有造成新錯誤。 以下是一些如何運行有效單元測試的指南:
-#### 智能合約單元測試指南{#unit-testing-guidelines}
+#### 智能合約單元測試指南 {#unit-testing-guidelines}
##### 1. 了解你的合約的商務邏輯及工作流程
@@ -146,7 +146,7 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
- **[使用 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}
+### 整合測試 {#integration-testing-for-smart-contracts}
單元測試對合約函式進行單獨除錯,而整合測試將智慧型合約的組件作爲一個整體進行評估。 整合測試可以偵測源自跨合約呼叫或同一個智慧型合約中不同函式閒互動的問題。 例如,整合測試可以幫助檢查[繼承](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance)和依賴注入等是否正常運作。
@@ -154,13 +154,13 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
分叉的區塊鏈將與主網的行為類似,其帳戶具有關聯的狀態和餘額。 但它只作爲一個沙盒在本機開發環境運行,例如,這意味著你不需要用真實的以太幣來交易,你的更改也不會影響真實的以太坊協議。
-### 屬性測試{#property-based-testing-for-smart-contracts}
+### 屬性測試 {#property-based-testing-for-smart-contracts}
基於屬性的測試是一種檢查智慧型合約是否滿足一些已定義屬性的過程。 屬性是關於合約行為的事實斷言,預期其行為在不同的場景中始終保持為真。智慧型合約屬性的一個例子可以是「合約中的算術運算永不溢出或下溢」。
**靜態分析**和**動態分析**是執行屬性測試的兩種常用技術,兩者都可以驗證程式(此處指智能合約)的程式碼是否滿足某些預定義的屬性。 一些基於屬性的測試工具自帶一些關於預期合約屬性的預定義規則,並根據這些規則檢查程式碼,而其他工具則允許你為智慧型合約建立自訂屬性。
-#### 靜態分析{#static-analysis}
+#### 靜態分析 {#static-analysis}
靜態分析器將智慧型合約的原始程式碼作爲輸入,並輸出聲明合約是否滿足屬性的結果。 與動態分析不同,靜態分析不涉及執行合約來分析其正確性。 相反,靜態分析會推理智慧型合約在執行期間可能選擇的所有路徑(例如,透過檢視原始程式碼的結構來確定合約運作在運行時間的意義)。
@@ -168,7 +168,7 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
在多數情況下,靜態分析對偵測安全問題很有用,例如使用不安全構造、語法錯誤或違反合約程式碼中的編碼標準。 然而,靜態分析器通常被認爲在偵測更深層漏洞方面不太健全,並可能會產生過多的誤報。
-#### 動態分析{#dynamic-analysis}
+#### 動態分析 {#dynamic-analysis}
動態分析會對智能合約的函式產生符號輸入(例如,在[符號執行](https://en.m.wikipedia.org/wiki/Symbolic_execution)中)或具體輸入(例如,在[模糊測試](https://owasp.org/www-community/Fuzzing)中),以查看是否有任何執行追蹤違反了特定屬性。 此類基於屬性的測試與單元測試不同,其測試用例覆蓋了多種場景,並且有一個程式處理測試用例的生成。
@@ -182,7 +182,7 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
3. \*\*單元測試證明合約對樣本資料能正確執行,但合約對樣本外的輸入是否能正確執行仍是未知數。\*\*屬性測試會使用給定輸入值的多種變體來執行目標合約,以找出導致斷言失敗的執行追蹤。 因此,屬性測試為合約在廣泛的輸入資料類別下正確執行提供了更多的保證。
-### 執行智能合約屬性測試的指南{#running-property-based-tests}
+### 執行智能合約屬性測試的指南 {#running-property-based-tests}
執行屬性測試通常從定義一個你想要在智能合約中驗證的屬性(例如,沒有[整數溢位](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow))或屬性集合開始。 在編寫屬性測試時,你可能還需要定義一個數值範圍,使程式能夠在該範圍内為交易輸入生成資料。
@@ -197,11 +197,11 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
- **[使用 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}
儘管在本機開發環境中執行的自動化測試能夠提供有用的偵錯資訊,你仍然會想知道你的合約在生产環境中的執行情況。 然而,部署到以太坊主鏈需要燃料費 - 更不用説如果你的智慧型合約仍有漏洞,你或你的使用者可能會損失真金白銀。
@@ -211,7 +211,7 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
[關於開發網路的更多資訊。](/developers/docs/development-networks/)
-### 在測試網上測試合約{#testing-contracts-on-testnets}
+### 在測試網上測試合約 {#testing-contracts-on-testnets}
測試網路或測試網的運作方式與以太坊主網完全相同,唯一的區別在於它使用沒有現實價值的以太幣 (ETH)。 在[測試網](/developers/docs/networks/#ethereum-testnets)上部署你的合約,意味著任何人都可以與它互動(例如,透過去中心化應用程式的前端),而無需承擔資金風險。
@@ -221,7 +221,7 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
[關於以太坊測試網的更多資訊。](/developers/docs/development-networks/#public-beacon-testchains)
-## 測試與形式化驗證{#testing-vs-formal-verification}
+## 測試與形式化驗證 {#testing-vs-formal-verification}
儘管測試有助確認合約對特定資料輸入回傳預期結果,但對於測試期間未使用的輸入,它無法完全證明相同的結果。 因此,測試智能合約不能保證「功能正確性」(即它無法證明程式對_所有_輸入值組合都按要求執行)。
@@ -233,7 +233,7 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
[關於智能合約形式化驗證的更多資訊。](/developers/docs/smart-contracts/formal-verification)
-## 測試、稽核與漏洞賞金{#testing-vs-audits-bug-bounties}
+## 測試、稽核與漏洞賞金 {#testing-vs-audits-bug-bounties}
如上所述,嚴格的測試很難保證合約中沒有錯誤;形式化驗證方法可以提供更有力的正確性保證,但目前仍難以使用並且需要大量成本。
@@ -245,9 +245,9 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
主要的區別是漏洞懸賞計劃對更廣泛的開發者/駭客開放,並吸引了廣泛的擁有獨特技能與經驗的道德駭客和獨立安全專家。 與智慧型合約審查主要依賴可能擁有有限或狹窄專業知識的團隊相比,這可能是一個優勢。
-## 測試工具和程式庫{#testing-tools-and-libraries}
+## 測試工具和程式庫 {#testing-tools-and-libraries}
-### 單元測試工具{#unit-testing-tools}
+### 單元測試工具 {#unit-testing-tools}
- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _用 Solidity 編寫的智能合約的程式碼覆蓋率工具。_
@@ -267,9 +267,9 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _基於 Python 的單元測試和模糊測試框架,具有強大的偵錯功能和跨鏈測試支援,利用 pytest 和 Anvil 以獲得最佳的使用者體驗和效能。_
-### 屬性測試工具{#property-based-testing-tools}
+### 屬性測試工具 {#property-based-testing-tools}
-#### 靜態分析工具{#static-analysis-tools}
+#### 靜態分析工具 {#static-analysis-tools}
- **[Slither](https://github.com/crytic/slither)** - _基於 Python 的 Solidity 靜態分析框架,用於尋找漏洞、增強程式碼理解以及為智能合約編寫自訂分析。_
@@ -281,7 +281,7 @@ Solidity 智慧型合約的單元測試框架有不同的語言(大多數為 J
- **[Slippy](https://github.com/fvictorio/slippy)** - _一個簡單而強大的 Solidity linter。_
-#### 動態分析工具{#dynamic-analysis-tools}
+#### 動態分析工具 {#dynamic-analysis-tools}
- **[Echidna](https://github.com/crytic/echidna/)** - _透過屬性測試偵測智能合約漏洞的快速合約模糊測試器。_
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 5b78a4f554f..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
@@ -142,7 +142,7 @@ lang: zh-tw
如果使用者不同意提議的變更(例如,邏輯升級或新的費用方案),時間鎖讓使用者有時間可以退出系統。 沒有時間鎖,使用者必須信任開發者不會未提前通知,便在智慧型合約上實作隨意變更。 缺點是,時間鎖限制了快速修補漏洞的能力。
-## 資源{#resources}
+## 資源 {#resources}
**OpenZeppelin 升級外掛程式 - _一系列用於部署和保護可升級智能合約的工具。_**
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
index 8f7569efa73..2e2a4b04b41 100644
--- 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
@@ -18,7 +18,7 @@ lang: zh-tw
為了更了解此頁面,建議您先閱讀有關[代幣標準](/developers/docs/standards/tokens/)、[ERC-20](/developers/docs/standards/tokens/erc-20/) 和 [ERC-721](/developers/docs/standards/tokens/erc-721/) 的內容。
-## ERC-1155 函式和功能:{#body}
+## ERC-1155 函式和功能: {#body}
- [批次轉帳](#batch_transfers):在單次呼叫中轉帳多個資產。
- [批次餘額](#batch_balance):在單次呼叫中取得多個資產的餘額。
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
index 4de51be45e0..6a0c98f26b2 100644
--- 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
@@ -36,7 +36,7 @@ ERC-7575 透過將 ERC-20 代幣從 ERC-4626 實現外部化,增加了對多
為更清楚瞭解此頁面,建議您先閱讀 [代幣標準](/developers/docs/standards/tokens/) 和 [ERC-20](/developers/docs/standards/tokens/erc-20/) 的相關資訊。
-## ERC-4626 函式與功能:{#body}
+## ERC-4626 函式與功能: {#body}
### 方法 {#methods}
diff --git a/public/content/translations/zh-tw/developers/docs/wrapped-eth/index.md b/public/content/translations/zh-tw/developers/docs/wrapped-eth/index.md
index defbdf83881..412c113c089 100644
--- a/public/content/translations/zh-tw/developers/docs/wrapped-eth/index.md
+++ b/public/content/translations/zh-tw/developers/docs/wrapped-eth/index.md
@@ -1,6 +1,6 @@
---
-title: 甚麼是包裝以太幣 (WETH)
-description: 包裝以太幣 (WETH) 簡介 — 以太幣 (ETH) 的一種 ERC20 相容包裝函式。
+title: "甚麼是包裝以太幣 (WETH)"
+description: "包裝以太幣 (WETH) 簡介 — 以太幣 (ETH) 的一種 ERC20 相容包裝函式。"
lang: zh-tw
---
@@ -35,19 +35,16 @@ lang: zh-tw
你需要支付燃料費來使用包裝以太幣智慧型合約來兌換或贖回以太幣。
-
包裝以太幣通常被認為是安全的,因為它基於一個簡單且經過實證的智慧型合約。 包裝以太幣合約也已經經過正式驗證,這是以太坊上智慧型合約的最高安全標準。
-
除了本頁描述的 [包裝以太幣的規範化實作](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)外,還有其他變體存在於市場中。 這些可能是由應用程式開發者建立的自訂代幣,或在其他區塊鏈上發行的版本,可能會有不同的行為或具有不同的安全屬性。 **始終仔細檢查代幣資訊,以確認你正在與哪一種包裝以太幣實作進行互動。**
-
@@ -55,7 +52,6 @@ lang: zh-tw
- [以太坊主網](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
- [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1)
- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
-
## 延伸閱讀 {#further-reading}
diff --git a/public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md
index c2b0395627b..9dbaedf4296 100644
--- a/public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/all-you-can-cache/index.md
@@ -1,7 +1,7 @@
---
title: "任你快取"
description: "學習如何創建和使用快取合約,以降低卷軸交易的成本"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "Layer 2", "快取", "儲存" ]
skill: intermediate
published: 2022-09-15
diff --git a/public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md b/public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md
index 121485f6a65..6463ea6fdda 100644
--- a/public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/app-plasma/index.md
@@ -1,7 +1,7 @@
---
title: "編寫一個保護隱私的特定應用程式 plasma"
description: "在本使用教學中,我們將為存款建立一個半祕密的銀行。 此銀行為中心化元件;它知道每位使用者的餘額。 然而,此資訊不會儲存在鏈上。 銀行會改為張貼狀態的雜湊值。 每當交易發生時,銀行就會張貼新的雜湊值,以及證明其擁有將雜湊狀態變更為新狀態的簽署交易之零知識證明。 閱讀本使用教學後,您不僅將瞭解如何使用零知識證明,還會瞭解為何要使用以及如何安全地使用。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "零知識", "伺服器", "鏈下", "隱私" ]
skill: advanced
lang: zh-tw
diff --git a/public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
index 340f5038523..fe05b8862ac 100644
--- a/public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
@@ -1,7 +1,7 @@
---
title: "為你的合約建立一個使用者介面"
description: "我們將使用 TypeScript、React、Vite 和 Wagmi 等現代元件,探討一個現代但極簡的使用者介面,並學習如何將錢包連接到使用者介面、呼叫智能合約來讀取資訊、將交易傳送到智能合約,以及監視智能合約的事件來識別變更。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "typescript", "反應", "vite", "wagmi", "前端" ]
skill: beginner
published: 2023-11-01
diff --git a/public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md
index ea7fdea07e9..872225c7ea8 100644
--- a/public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/erc-721-vyper-annotated-code/index.md
@@ -1,7 +1,7 @@
---
title: "Vyper ERC-721 合約逐步解說"
description: "Ryuya Nakamura 的 ERC-721 合約及其運作方式"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
lang: zh-tw
tags: [ "vyper", "erc-721", "python" ]
skill: beginner
@@ -251,6 +251,7 @@ def supportsInterface(_interfaceID: bytes32) -> bool:
```python
### 檢視函式 ###
+
```
這些是讓使用者和其他合約能取得代幣相關資訊的檢視函式。
diff --git a/public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md
index 430ab6d310f..1221adcb386 100644
--- a/public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/erc20-annotated-code/index.md
@@ -1,7 +1,7 @@
---
title: "ERC-20 合約逐步解說"
description: "OpenZeppelin 的 ERC-20 合約內容是什麼?這些內容又為何存在?"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
lang: zh-tw
tags: [ "穩固", "erc-20" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md b/public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md
index bc4485d5d0e..808a150cfd9 100644
--- a/public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/erc20-with-safety-rails/index.md
@@ -1,7 +1,7 @@
---
title: "帶有安全措施的 ERC-20"
description: "如何幫助人們避免愚蠢的錯誤"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
lang: zh-tw
tags: [ "erc-20" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md b/public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md
index 43b2332b010..1ceb9671416 100644
--- a/public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/ethereum-for-web2-auth/index.md
@@ -1,7 +1,7 @@
---
title: "使用以太坊進行 Web2 驗證"
description: "閱讀本教學後,開發者將能夠將以太坊登入 (Web3) 與 SAML 登入整合。SAML 登入是 Web2 中使用的一種標準,可提供單一登入及其他相關服務。 這允許透過以太坊簽章來驗證對 Web2 資源的存取,且使用者屬性來自證明。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "web2", "驗證", "eas" ]
skill: beginner
lang: zh-tw
diff --git a/public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
index d619fa0f2e9..c14801cb3f5 100644
--- a/public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
@@ -6,7 +6,7 @@ tags: [ "javascript", "ethers.js", "節點", "諮詢", "alchemy" ]
skill: beginner
lang: zh-tw
published: 2020-10-30
-source: "中"
+source: Medium
sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md
index 8d9e5e73677..4dfd52b75ec 100644
--- a/public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/guide-to-smart-contract-security-tools/index.md
@@ -6,7 +6,7 @@ lang: zh-tw
tags: [ "穩固", "智能合約", "安全性" ]
skill: intermediate
published: 2020-09-07
-source: "建立安全合約"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
index 13d461da96c..f6785dcde63 100644
--- a/public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
@@ -6,7 +6,7 @@ lang: zh-tw
tags: [ "穩固", "智能合約", "安全性", "測試", "模糊測試" ]
skill: advanced
published: 2020-04-10
-source: "建立安全合約"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
index 40c750c5b2a..fd1b070d6dd 100644
--- a/public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
@@ -6,7 +6,7 @@ lang: zh-tw
tags: [ "穩固", "智能合約", "安全性", "測試", "正式驗證" ]
skill: advanced
published: 2020-01-13
-source: "建立安全合約"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore
---
@@ -392,6 +392,7 @@ symbolic_var = m.make_symbolic_value()
contract_account.f(symbolic_var)
## 檢查執行是否以 REVERT 或 INVALID 結束
+
for state in m.terminated_states:
last_tx = state.platform.transactions[-1]
if last_tx.result in ['REVERT', 'INVALID']:
@@ -499,6 +500,7 @@ contract_account.f(symbolic_var)
no_bug_found = True
## 檢查執行是否以 REVERT 或 INVALID 結束
+
for state in m.terminated_states:
last_tx = state.platform.transactions[-1]
if last_tx.result in ['REVERT', 'INVALID']:
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
index f1636c0e606..53db7b41c7b 100644
--- a/public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
@@ -6,7 +6,7 @@ lang: zh-tw
tags: [ "穩固", "智能合約", "安全性", "測試" ]
skill: advanced
published: 2020-06-09
-source: "建立安全合約"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither
---
@@ -65,7 +65,7 @@ slither project_paths
使用 [crytic.io](https://github.com/crytic) 來存取私有偵測器和 GitHub 整合功能。
-## 靜態分析{#static-analysis}
+## 靜態分析 {#static-analysis}
Slither 靜態分析框架的功能與設計,已在部落格文章 ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/)、[2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) 與一篇 [學術論文](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf) 中有所說明。
diff --git a/public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
index 37980032bdd..58cc60ecfcf 100644
--- a/public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
@@ -24,7 +24,7 @@ sourceUrl: https://docs.tellor.io/tellor/
Tellor 是一個已上線且可供執行的開源預言機。 本入門指南將說明如何輕鬆啟用並執行 Tellor,為您的專案提供一個完全去中心化且抗審查的預言機。
-## 概覽{#overview}
+## 概覽 {#overview}
Tellor 是一個預言機系統,各方可以在系統中請求鏈下資料點 (例如 BTC/USD) 的值,而回報者則會競相將此值新增到鏈上資料庫,此資料庫可供所有以太坊智能合約存取。 此資料庫的輸入內容,由已質押回報者組成的網路保護。 Tellor 利用加密經濟激勵機制,獎勵誠實提交資料的回報者,並透過發行 Tellor 的代幣 Tributes (TRB) 以及爭議機制來懲罰惡意行為者。
diff --git a/public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md b/public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md
index 8b0e6bc3a53..cf4d827eea5 100644
--- a/public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/ipfs-decentralized-ui/index.md
@@ -1,7 +1,7 @@
---
title: "用於去中心化使用者介面的 IPFS"
description: "本使用教學會教讀者如何使用 IPFS 來儲存去中心化應用程式的使用者介面。 儘管應用程式的資料和商業邏輯是去中心化的,但如果沒有抗審查的使用者介面,使用者還是可能會失去存取權限。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "ipfs" ]
skill: beginner
lang: zh-tw
diff --git a/public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
index d7df54efd11..7af81f244d5 100644
--- a/public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
@@ -1,7 +1,7 @@
---
title: "用於離線資料完整性的默克爾證明"
description: "為儲存在鏈下的資料確保其鏈上完整性"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "儲存" ]
skill: advanced
lang: zh-tw
diff --git a/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
index fd61f0a6c26..96921f01512 100644
--- a/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/optimism-std-bridge-annotated-code/index.md
@@ -1,7 +1,7 @@
---
title: "Optimism 標準跨鏈橋合約深入解析"
description: "Optimism 的標準跨鏈橋如何運作? 為什麼它會這樣運作?"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "穩固", "跨鏈橋", "Layer 2" ]
skill: intermediate
published: 2022-03-30
diff --git a/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
index d3a33f49c02..3edb01dde99 100644
--- a/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/reverse-engineering-a-contract/index.md
@@ -1,7 +1,7 @@
---
title: "對合約進行逆向工程"
description: "如何在沒有原始碼的情況下理解合約"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
lang: zh-tw
tags: [ "evm", "opcodes" ]
skill: advanced
@@ -62,7 +62,7 @@ _區塊鏈上沒有秘密_,發生的一切都是一致、可驗證且公開的

-### 0x5E 的處理常式(用於非 ABI 呼叫資料){#the-handler-at-0x5e-for-non-abi-call-data}
+### 0x5E 的處理常式(用於非 ABI 呼叫資料) {#the-handler-at-0x5e-for-non-abi-call-data}
| 位移 | Opcode |
| -: | ------------ |
diff --git a/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
index 6f5607db4ea..97999b3367e 100644
--- a/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/run-node-raspberry-pi/index.md
@@ -6,7 +6,7 @@ tags: [ "用戶端", "執行層", "共識層", "節點" ]
lang: zh-tw
skill: intermediate
published: 2022-06-10
-source: "ARM 上的以太坊"
+source: Ethereum on ARM
sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
index 647fed85608..1cbbe2797dc 100644
--- a/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/scam-token-tricks/index.md
@@ -1,7 +1,7 @@
---
title: "詐騙代幣使用的一些伎倆以及如何偵測它們"
description: "在本使用教學中,我們將剖析一個詐騙代幣,以了解詐騙者所玩的伎倆、他們如何實作這些伎倆,以及我們該如何偵測它們。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags:
[
"詐騙",
diff --git a/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md b/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
index 4b9dbe17091..c6374b12b6a 100644
--- a/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/secret-state/index.md
@@ -1,7 +1,7 @@
---
title: "使用零知識證明建立秘密狀態"
description: "鏈上遊戲有所限制,因為它們無法保存任何隱藏資訊。 閱讀本教學課程後,讀者將能夠結合零知識證明和伺服器元件,建立具有秘密狀態、鏈下元件的可驗證遊戲。 我們將透過建立踩地雷遊戲來示範此技術。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "伺服器", "鏈下", "中心化", "零知識", "zokrates", "mud" ]
skill: advanced
lang: zh-tw
diff --git a/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
index 103f3af5663..e04f9071168 100644
--- a/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/secure-development-workflow/index.md
@@ -6,7 +6,7 @@ tags: [ "智能合約", "安全性", "solidity" ]
skill: intermediate
lang: zh-tw
published: 2020-09-07
-source: "建立安全合約"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
index 445f03bdd52..444f5940420 100644
--- a/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -85,7 +85,7 @@ mkdir sendtx-example
cd sendtx-example
```
-### 4. 安裝 Alchemy Web3(或任何 web3 函式庫){#install-alchemy-web3}
+### 4. 安裝 Alchemy Web3(或任何 web3 函式庫) {#install-alchemy-web3}
在您的專案目錄中執行以下指令來安裝 [Alchemy Web3](https://docs.alchemy.com/reference/api-overview):
diff --git a/public/content/translations/zh-tw/developers/tutorials/server-components/index.md b/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
index 3f34c1ad0cf..c44318b6f29 100644
--- a/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/server-components/index.md
@@ -2,7 +2,7 @@
title: "Web3 應用程式的伺服器元件和代理"
description: "閱讀本教學後,您將能編寫 TypeScript 伺服器,以偵聽區塊鏈上的事件,並透過自己的交易做出相應的回應。 這將讓您能夠編寫中心化應用程式(因為伺服器是一個故障點),但可以與 Web3 實體互動。 同樣的技術也可以用來編寫一個無需人工干預即可回應鏈上事件的代理。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
lang: zh-tw
tags: [ "代理", "伺服器", "鏈下" ]
skill: beginner
diff --git a/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md b/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
index 28471e95d45..9127e08b7b9 100644
--- a/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/short-abi/index.md
@@ -1,7 +1,7 @@
---
title: "為優化 Calldata 而設的精簡 ABI"
description: "為樂觀卷軸優化智能合約"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
lang: zh-tw
tags: [ "Layer 2" ]
skill: intermediate
diff --git a/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
index c3c29ad2ac4..583ef8275a5 100644
--- a/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/smart-contract-security-guidelines/index.md
@@ -6,7 +6,7 @@ tags: [ "穩固", "智能合約", "安全性" ]
skill: intermediate
lang: zh-tw
published: 2020-09-06
-source: "建立安全合約"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md b/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
index 0e51ff00fd4..7ff35821895 100644
--- a/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/stealth-addr/index.md
@@ -1,7 +1,7 @@
---
title: "使用隱匿地址"
description: "隱匿地址讓使用者能夠匿名轉移資產。 閱讀本文後,您將能夠:解釋什麼是隱匿地址及其運作方式、瞭解如何以維護匿名性的方式使用隱匿地址,以及編寫使用隱匿地址的網頁應用程式。"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "隱匿地址", "隱私", "密碼學", "rust", "wasm" ]
skill: intermediate
published: 2025-11-30
diff --git a/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md
index 579284f2a5c..f43eb381e22 100644
--- a/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/token-integration-checklist/index.md
@@ -6,7 +6,7 @@ lang: zh-tw
tags: [ "穩固", "智能合約", "安全性", "代幣" ]
skill: intermediate
published: 2020-08-13
-source: "建立安全合約"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md
---
diff --git a/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md
index 7e23de2b9a1..1ba38ee7d37 100644
--- a/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/uniswap-v2-annotated-code/index.md
@@ -1,7 +1,7 @@
---
title: "Uniswap-v2 合約逐步詳解"
description: "Uniswap-v2 合約如何運作? 為何要這樣編寫?"
-author: "作者:Ori Pomerantz"
+author: Ori Pomerantz
tags: [ "穩固" ]
skill: intermediate
published: 2021-05-01
@@ -56,9 +56,8 @@ Uniswap v2 分為兩個部分:核心與周邊。 這種劃分讓持有資產
4. 遍歷路徑。 對於路徑上的每個交易所,它會發送輸入代幣,然後呼叫交易所的 `swap` 函式。
在大多數情況下,代幣的目標地址是路徑中的下一個成對交易所。 在最終的交易所,目標地址是交易者提供的地址。
-#### 在核心合約 (UniswapV2Pair.sol) 中 {#in-the-core-contract-uniswapv2pairsol-2}
+#### 在核心合約 (UniswapV2Pair.sol) 中 {#in-the-core-contract-uniswapv2pairsol-2}5. 驗證核心合約未被欺騙,且在交換後能維持足夠的流動性。
-5. 驗證核心合約未被欺騙,且在交換後能維持足夠的流動性。
6. 查看除了已知的儲備金外,我們還擁有多少額外的代幣。 該數量是我們收到用於交換的輸入代幣數量。
7. 將輸出代幣發送到目標地址。
8. 呼叫 `_update` 來更新儲備金數量
diff --git a/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md b/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
index 1ff7bfae139..c2192f459b3 100644
--- a/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
+++ b/public/content/translations/zh-tw/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
@@ -81,7 +81,7 @@ MyWaffleProject
└── package.json
```
-### 現在讓我們來談談其中一些檔案:{#now-lets-talk}
+### 現在讓我們來談談其中一些檔案: {#now-lets-talk}
- Greeter.sol - 我們用 solidity 編寫的智能合約;
@@ -128,7 +128,7 @@ describe("Greeter", function () {
})
```
-### 下一步是編譯我們的合約並執行測試:{#compiling-and-testing}
+### 下一步是編譯我們的合約並執行測試: {#compiling-and-testing}
Waffle 測試使用 Mocha (一個測試框架) 和 Chai (一個斷言庫)。 您只需執行 `npx hardhat test`,並等待以下訊息出現即可。
diff --git a/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md
index 679568fa83b..30f933932ba 100644
--- a/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-create-an-ethereum-account/index.md
@@ -42,8 +42,7 @@ lang: zh-tw
- 錢包安裝好了嗎?
了解如何使用。
-
+ 錢包安裝好了嗎?
了解如何使用。
如何使用錢包
@@ -65,7 +64,7 @@ lang: zh-tw
### 如果我有一個以太幣地址,我在其他區塊鏈上也擁有同一個地址嗎?
-只要區塊鏈使用與以太坊類似的底層軟體 (稱為「與以太坊虛擬機相容」),就能在這些區塊鏈上使用同一個[地址](/glossory/#address)。 此[清單](https://chainlist.org/)會顯示您可以用相同地址使用哪些區塊鏈。 比特幣等某些區塊鏈,實作了一整套獨立的網路規則,你將需要一個不同格式的不同地址。 如果你有智慧型合約錢包,你應該查看其產品網站以更多瞭解它支援哪些區塊鏈,因為這些錢包通常支援的範圍有限但更安全。
+只要區塊鏈使用與以太坊類似的底層軟體 (稱為「與以太坊虛擬機相容」),就能在這些區塊鏈上使用同一個[地址](/glossary/#address)。 此[清單](https://chainlist.org/)會顯示您可以用相同地址使用哪些區塊鏈。 比特幣等某些區塊鏈,實作了一整套獨立的網路規則,你將需要一個不同格式的不同地址。 如果你有智慧型合約錢包,你應該查看其產品網站以更多瞭解它支援哪些區塊鏈,因為這些錢包通常支援的範圍有限但更安全。
### 擁有自己的錢包,比將資金存放在交易所上更安全嗎?
diff --git a/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md b/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md
index 38717e212e6..e9e57bf3a6d 100644
--- a/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-revoke-token-access/index.md
@@ -49,8 +49,7 @@ lang: zh-tw
- 想瞭解更多嗎?
-
+ 想瞭解更多嗎?
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md b/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md
index 7f57848252f..b4f78800f36 100644
--- a/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-swap-tokens/index.md
@@ -52,8 +52,7 @@ lang: zh-tw
- 想瞭解更多嗎?
-
+ 想瞭解更多嗎?
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md b/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md
index fa7aa062da8..05409789cee 100644
--- a/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-use-a-bridge/index.md
@@ -54,8 +54,7 @@ lang: zh-tw
- 想瞭解更多嗎?
-
+ 想瞭解更多嗎?
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md b/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md
index b04cb89b373..7f466f6ec54 100644
--- a/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md
+++ b/public/content/translations/zh-tw/guides/how-to-use-a-wallet/index.md
@@ -65,8 +65,7 @@ lang: zh-tw
- 想瞭解更多嗎?
-
+ 想瞭解更多嗎?
查看我們的其他指南
diff --git a/public/content/translations/zh-tw/nft/index.md b/public/content/translations/zh-tw/nft/index.md
index e86238244be..5b0264d3052 100644
--- a/public/content/translations/zh-tw/nft/index.md
+++ b/public/content/translations/zh-tw/nft/index.md
@@ -58,8 +58,7 @@ NFT 是指**各自獨一無二**的代幣。 每個非同質化代幣都有不
- 探索、購買或建立你個人的非同質化代幣藝術品/收藏品……
-
+ 探索、購買或建立你個人的非同質化代幣藝術品/收藏品……
探索 NFT 藝術
diff --git a/public/content/translations/zh-tw/payments/index.md b/public/content/translations/zh-tw/payments/index.md
index cc8e8670b99..c0eb9c82c76 100644
--- a/public/content/translations/zh-tw/payments/index.md
+++ b/public/content/translations/zh-tw/payments/index.md
@@ -60,11 +60,12 @@ summaryPoint3: "一分鐘內收到款項"
- 使用一個錢包應用程式創建您的以太坊帳號。
-
+ 使用一個錢包應用程式創建您的以太坊帳號。
-開始吧
+開始吧
+
+
## 使用自我保管加密貨幣卡付款 {#pay-with-self-custodial-crypto-cards}
@@ -167,7 +168,7 @@ summaryPoint3: "一分鐘內收到款項"
- 定期支付
- 基於效能的獎勵
-### 速度{#speed}
+### 速度 {#speed}
您還記得上次未完成國際銀行轉帳等待數日的經驗嗎? 排隊久候? 以及一堆需要填寫的表格? 因為以太坊,這些日子已經成為過去式了。 不管發送方和收款方身在何處,以太坊網路上的交易數分鐘內就可以完成。 因為以太坊是無需許可的,發送款項時沒有監管方的繁文縟節。 這速度在時間緊迫的狀況下尤為重要,像是緊急救援工作。
@@ -197,10 +198,10 @@ summaryPoint3: "一分鐘內收到款項"
- 是時候擁有自己的以太坊帳戶了。
-
+ 是時候擁有自己的以太坊帳戶了。
開始使用!
+
diff --git a/public/content/translations/zh-tw/prediction-markets/index.md b/public/content/translations/zh-tw/prediction-markets/index.md
index 3f22f7f6506..feeb020f041 100644
--- a/public/content/translations/zh-tw/prediction-markets/index.md
+++ b/public/content/translations/zh-tw/prediction-markets/index.md
@@ -56,7 +56,9 @@ buttons:
警惕風險
只下注您能夠承受的金額,並注意潛在的上癮行為。
+
+
## 挑戰和風險 {#challenges-and-risks}
diff --git a/public/content/translations/zh-tw/privacy/index.md b/public/content/translations/zh-tw/privacy/index.md
index 365b434b058..6ccf7ed62e4 100644
--- a/public/content/translations/zh-tw/privacy/index.md
+++ b/public/content/translations/zh-tw/privacy/index.md
@@ -88,7 +88,7 @@ _範例:[UmbraCash](https://app.umbra.cash/faq)、[FluidKey](https://www.fluid
**ZK Rollup**:一種擴容系統,它在鏈下批次處理交易,並在鏈上提交有效性證明—預設情況下並非私密,但它們透過降低成本來實現高效的隱私系統 (如隱蔽池)
-## 資源{#resources}
+## 資源 {#resources}
- [Privacy Stewards of Ethereum](https://pse.dev/) (PSE),一個由以太坊基金會支持的研究與開發實驗室,專注於生態系的隱私保護
- [Web3PrivacyNow](https://web3privacy.info/),一個由個人、專案和志同道合的組織組成的網路,致力於保護和促進線上的人權
diff --git a/public/content/translations/zh-tw/real-world-assets/index.md b/public/content/translations/zh-tw/real-world-assets/index.md
index 4a47ab85bfb..4b2313dff8e 100644
--- a/public/content/translations/zh-tw/real-world-assets/index.md
+++ b/public/content/translations/zh-tw/real-world-assets/index.md
@@ -40,7 +40,7 @@ RWA 代幣並沒有任何內在價值。 反之,其反映了他們所代表物
來看看來自 RWA 生態系統的幾個例子:不動產、傳統金融產品以及藝術品。
-### 投資房地產{#investing-in-real-estate}
+### 投資房地產 {#investing-in-real-estate}
假設您想投資房地產,但買下整棟房子實在遙不可及。 取而代之的是,您可以透過如 [RealT](https://realt.co/) 的專案購買 RWA。 其代幣代表了一家專為持有不動產所有權狀而設立的責任有限公司的股權。 代幣持有者會根據他們持有的比例,收到穩定幣形式的租金收入;據 RealT 所述,它們至今已向投資者發放 1500 萬美金的淨租金。
diff --git a/public/content/translations/zh-tw/roadmap/beacon-chain/index.md b/public/content/translations/zh-tw/roadmap/beacon-chain/index.md
index 143527fd6bb..b8b4e2c052f 100644
--- a/public/content/translations/zh-tw/roadmap/beacon-chain/index.md
+++ b/public/content/translations/zh-tw/roadmap/beacon-chain/index.md
@@ -19,6 +19,7 @@ summaryPoint3: "信標鏈引入共識邏輯和區塊廣播協定,現在可保
信標鍊是 2020 年推出的原始權益證明區塊鏈的名稱。 信標鏈的作用是在以太坊主網上啟用權益證明共識邏輯之前,確保它健全且可永續存在。 因此,它與原先的工作量證明以太坊一起運行。 信標鏈是「空」區塊鏈,但在以太坊上,要從工作量證明過渡到權益證明,需要指示信標鏈接受來自執行用戶端的交易資料,將它們打包進區塊,並使用基於權益證明的共識機制,將它們整合成一條區塊鏈。 與此同時,原始的以太坊用戶端關閉挖礦、區塊廣播和共識邏輯,將它們全部交給信標鏈。 這個事件稱為[合併](/roadmap/merge/)。 合併後,即不再有兩條區塊鏈。 相反,只有一個權益證明以太坊,每個節點現在需要兩個不同的用戶端。 信標鏈目前是共識層,是處理區塊廣播和共識邏輯的共識用戶端對等網路,而原始用戶端則形成執行層,負責廣播和執行交易,以及管理以太坊狀態。 這兩個層可以用引擎應用程式介面相互通訊。
## 信標鏈可以做什麼? {#what-does-the-beacon-chain-do}
+
信標鏈是帳戶帳本的名稱,在以太坊質押者開始驗證真正的以太坊區塊前,信標鏈會指揮並協調這些質押者。 但它並不處理交易或智慧型合約互動,因為這些事是在執行層完成的。
信標鏈負責區塊和證明處理、執行分叉選擇演算法、管理獎勵和懲罰等事務。
在我們的[節點架構頁面](/developers/docs/nodes-and-clients/node-architecture/#node-comparison)上閱讀更多內容。
diff --git a/public/content/translations/zh-tw/roadmap/fusaka/index.md b/public/content/translations/zh-tw/roadmap/fusaka/index.md
index 80eab865b23..0b9123694e9 100644
--- a/public/content/translations/zh-tw/roadmap/fusaka/index.md
+++ b/public/content/translations/zh-tw/roadmap/fusaka/index.md
@@ -22,7 +22,7 @@ Fusaka 升級僅是以太坊長期發展目標中的單一步驟。 深入了解
### 擴展 blob {#scale-blobs}
-#### 點對點資料可用性取樣(Peer Data Availability Sampling, PeerDAS){#peerdas}
+#### 點對點資料可用性取樣(Peer Data Availability Sampling, PeerDAS) {#peerdas}
這是 Fusaka 分叉的_主打功能_,也是此次升級新增的主要特性。 第二層解決方案目前將其資料以 blob 形式發佈至以太坊,這種短暫性資料類型是專為第二層解決方案所創建。 在Fusaka之前,每個完整節點都必須儲存每個數據塊,以確保資料確實存在。 隨著資料塊吞吐量增加,必須下載所有這些資料的操作將變得資源消耗過於龐大而難以承受。
@@ -56,7 +56,7 @@ Blob參數限定分叉可以由用戶端自行設定,與gas限制的配置方
**資源**:[EIP-7892 技術規範](https://eips.ethereum.org/EIPS/eip-7892)
-#### Blob 的基礎費用以執行成本為上限{#blob-base-fee-bounded-by-execution-costs}
+#### Blob 的基礎費用以執行成本為上限 {#blob-base-fee-bounded-by-execution-costs}
第二層協議在發布資料時需支付兩項費用:資料塊費用以及驗證這些資料塊所需的執行氣體費用。 若執行Gas主導市場,區塊拍賣費可能螺旋式下跌至1威,進而喪失價格信號功能。
@@ -81,13 +81,13 @@ EIP-7918 為每個blob設定了一個按比例計算的保留價格。 當儲備
**資源**:[EIP-7642 技術規範](https://eips.ethereum.org/EIPS/eip-7642)
-#### 設定MODEXP上限值{#set-upper-bounds-for-modexp}
+#### 設定MODEXP上限值 {#set-upper-bounds-for-modexp}
目前為止,MODEXP的預編譯合約可以接受幾乎任何大小的數字。 這讓它難以測試、容易被濫用並對客戶端的穩定性帶來風險。 EIP-7823界定了明確的上限:每個輸入數值的長度最多為8192位元(1024個字節位元組)。 超過上限的輸入會被拒絕,該筆交易的gas仍會被燃燒,但不會變更任何狀態。 此上限足以涵蓋實務需求,同時排除那些讓gas上限設定與安全性審查變得複雜的極端情況。 這項調整在不影響用戶及開發者體驗的前提下,強化了安全性與抗阻斷服務的能力(DoS;Denial of Service)。
**資源**:[EIP-7823 技術規範](https://eips.ethereum.org/EIPS/eip-7823)
-#### GAS交易上限{#transaction-gas-limit-cap}
+#### GAS交易上限 {#transaction-gas-limit-cap}
EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) 為每筆交易新增了 16,777,216 (2^24) 的 gas 上限。 當我們提高區塊燃料限制時,這是透過限制單一交易的最壞情況成本來進行的主動式 DoS 強化。 它讓驗證和傳播更容易模型化,使我們能夠透過提高燃料限制來處理擴張問題。
diff --git a/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md b/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md
index 1de2ad2b219..c8b482b9823 100644
--- a/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md
+++ b/public/content/translations/zh-tw/roadmap/fusaka/peerdas/index.md
@@ -4,7 +4,7 @@ description: "作為 Fusaka 以太坊協議升級的一部分,了解 PeerDAS"
lang: zh-tw
---
-# 點對點資料可用性取樣(Peer Data Availability Sampling, PeerDAS){#peer-das}
+# 點對點資料可用性取樣(Peer Data Availability Sampling, PeerDAS) {#peer-das}
自從 [透過 EIP-4844 引入 blob 交易](/roadmap/danksharding/) 以來,以太坊協議正在進行其最重要的擴張升級。 作為 [Fusaka 升級](/roadmap/fusaka/) 的一部分,PeerDAS 引入了一種處理 blob 資料的新方法,為 Layer 2 的 **[資料可用性 (DA)](/developers/docs/data-availability/)** 容量帶來了約一個數量級的增長。
@@ -40,7 +40,7 @@ lang: zh-tw
DAS 是建立在此基礎上的一個機制,確保資料既正確又可用。 抽樣是一個過程,節點只查詢資料的一小部分,並根據承諾進行驗證。 KZG 是一種多項式承諾方案,這意味著多項式曲線上任何單一點都可以被驗證。 透過僅檢查多項式上的幾個點,進行抽樣的用戶端就可以對資料的可用性有很高的機率保證。
-## 點對點資料可用性取樣(Peer Data Availability Sampling, PeerDAS){#peer-das}
+## 點對點資料可用性取樣(Peer Data Availability Sampling, PeerDAS) {#peer-das}
[PeerDAS (EIP-7594)](https://eips.ethereum.org/EIPS/eip-7594) 是在以太坊中實作 DAS 機制的具體提案,這可能是自合併以來最大的一次升級。 PeerDAS 的設計旨在擴展 blob 資料,將其分成列,並將子集分發給節點。
diff --git a/public/content/translations/zh-tw/roadmap/merge/issuance/index.md b/public/content/translations/zh-tw/roadmap/merge/issuance/index.md
index a9301925cf4..1b22c19debc 100644
--- a/public/content/translations/zh-tw/roadmap/merge/issuance/index.md
+++ b/public/content/translations/zh-tw/roadmap/merge/issuance/index.md
@@ -62,7 +62,9 @@ ETH 總供給量:**約 120,520,000 ETH** (在 2022 年 9 月合併時)
共識層上 **~11.3%** 的發行量發給質押者 (0.52 / 4.61 \* 100)
+
+
## 合併後 (現今) {#post-merge}
@@ -96,7 +98,9 @@ ETH 總供給量:**約 120,520,000 ETH** (在 2022 年 9 月合併時)
年度 ETH 發行淨減少:**~88.7%** ((4.61% - 0.52%) / 4.61% \* 100)
+
+
## 銷毀 {#the-burn}
@@ -109,7 +113,9 @@ ETH 總供給量:**約 120,520,000 ETH** (在 2022 年 9 月合併時)
費用銷毀機制隨著 2021 年 8 月的 [倫敦升級](/ethereum-forks/#london) 一同上線,自合併以來維持不變。
+
+
除了倫敦升級時實作的費用銷毀機制外,驗證者也可能因離線而受到懲處;更糟糕的是,他們可能因為違反威脅網路安全的特定規定而遭罰沒。 這些處罰會導致驗證者餘額中的以太幣減少,減少的金額不會直接獎勵給任何其他帳戶,而是會有效地從流通中銷毀/移除。
diff --git a/public/content/translations/zh-tw/roadmap/pectra/index.md b/public/content/translations/zh-tw/roadmap/pectra/index.md
index d7afe14c286..c934c006361 100644
--- a/public/content/translations/zh-tw/roadmap/pectra/index.md
+++ b/public/content/translations/zh-tw/roadmap/pectra/index.md
@@ -4,7 +4,7 @@ description: "了解 Pectra 協議升級"
lang: zh-tw
---
-# Pectra{#pectra}
+# Pectra {#pectra}
Pectra 網絡升級在 [Dencun](/roadmap/dencun/) 之後進行,為以太坊的執行層和共識層都帶來了變更。 縮寫名稱Pectra是“布拉格和“Electra”這兩個詞的結合,它們分別代表執行層和共識層規範的變化。 總之,這些變化為以太坊用戶、開發人員和驗證程式帶來了許多改進。
@@ -22,7 +22,7 @@ Pectra 升級只是以太坊長期發展目標中的其中一環。 深入了解
Pectra 帶來了迄今為止所有升級中數量最多的 [EIP](https://eips.ethereum.org/)! 有細微的變化,也有一些重要的新功能。 完整的更改清單及技術細節可在各自包含的EIP中查閱。
-### EOA帳戶程式碼{#7702}
+### EOA帳戶程式碼 {#7702}
[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) 標誌着向廣泛實現 [賬戶抽象](/roadmap/account-abstraction/) 邁出的重要一步。 通過此功能,使用者可以將自己的([EOA](/glossary/#eoa)) 地址擴展為智能合約。 EIP 引入了一種具有特定功能的新型交易——允許地址擁有者授權,將其地址設置為模擬選定的智能合約。
@@ -52,19 +52,19 @@ Blob 為二層網路提供[資料可用性](/developers/docs/data-availability/#
為了解決這個問題,[EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) 提高了calldata價格,但僅影響數據密集型交易。 這限制了區塊變得過於龐大,激勵 L2 僅使用 blobs,從而保證99% 以上的交易不受影響。
-### 執行層的可觸發退出機制{#7002}
+### 執行層的可觸發退出機制 {#7002}
目前,一個驗證程式退出並[提取質押的ETH](/staking/withdrawals/) 是一個共識層操作,要求擁有一個活躍的驗證程式密鑰,這個密鑰是驗證程式用來執行如證明等活躍任務的相同的BLS 密鑰。 提取憑證是一個獨立的冷存儲密鑰,用於接收已退出的質押資金,但無法觸發退出操作。 質押者退出的唯一方式是向信標鏈網路(Beacon Chain)發送來自活躍驗證程式密鑰簽名的特殊訊息。 在下面兩種情況里這種機制存在局限性:當提幣憑證和驗證密鑰由不同的實體持有,或驗證密鑰丟失時。
[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) 引入了一種新合約,可以用來通過執行層的提取憑證觸發退出。 質押者無需使用驗證程式簽名密鑰或訪問信標鏈,即可通過調用該特殊合約中的函數退出其驗證程式角色。 重要的是,啟用鏈上驗證程式提幣功能,使得質押協議能夠對節點運營商降低信任假設。
-### 鏈上驗證程式質押{#6110}
+### 鏈上驗證程式質押 {#6110}
驗證程式質押目前通過[eth1data poll](https://eth2book.info/capella/part2/deposits-withdrawals/deposit-processing/)進行處理,該功能位於信標鏈上( Beacon Chain),用於從執行層獲取數據。 這有點像是合併(The Merge)之前遺留下來的技術邏輯。那時信標鏈(Beacon Chain)還是一個獨立的網絡,不得不考慮工作量證明(PoW)鏈上的重組問題。
[EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) 是一種將質押從執行層傳遞到共識層的新方法,它能夠實現即時處理並降低實施的複雜性。 這是一種更安全的處理以太坊合併後原生質押的方式。 Eip-6110 的機制幫助節點不必依賴歷史存款記錄來啟動,這對於實現歷史數據過期是必要的,為以太坊協議提供未來適應性。
-### BLS12-381 的預編譯{#2537}
+### BLS12-381 的預編譯 {#2537}
預編譯是直接內置於以太坊虛擬機([EVM](/developers/docs/evm/))的一組特殊的智能合約。 與一般合約不同,預編譯並非由使用者部署,而是用戶端實作本身的一部分,以其原生語言(例如 Go、Java 等,而非 Solidity)編寫。 預編譯合約用於執行使用廣泛且標準化的功能,例如加密運算。 智能合約開發者可以像調用普通合約一樣調用預編譯合約,優勢在於:效率更高,安全性更高。
diff --git a/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md b/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md
index a0fb68917e5..e1fe2a89bf6 100644
--- a/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md
+++ b/public/content/translations/zh-tw/roadmap/pectra/maxeb/index.md
@@ -4,11 +4,11 @@ description: "在 Pectra 升級中了解更多關於 MaxEB 的信息"
lang: zh-tw
---
-# MaxEB{#maxeb}
+# MaxEB {#maxeb}
_簡單來說:_ Pectra 強分叉允許以太坊驗證程式將 **類型1** 提款憑證轉換為 **類型2** 提款憑證,從而參與更高的最大有效余額和復利機制。 執行这个操作的官方工具是 Launchpad(啟動面板)。 這個操作無法撤銷。
-## 概覽{#overview}
+## 概覽 {#overview}
### 誰會受到影響? {#who-is-affected}
@@ -97,7 +97,7 @@ MaxEB 允許驗證程式將其全部餘額轉賬給另一個驗證程式。 提

-### 合併請求{#the-consolidation-request}
+### 合併請求 {#the-consolidation-request}
合併請求將會被源驗證程式所關聯的取款地址簽名,且需要具有:
@@ -107,7 +107,7 @@ MaxEB 允許驗證程式將其全部餘額轉賬給另一個驗證程式。 提
在轉換過程中,2和3將保持同樣。 這個操作可以在[Launchpad]上完成(https://launchpad.ethereum.org/)。
-### 簽名的要求{#signing-requirements}
+### 簽名的要求 {#signing-requirements}
要提交“合併請求”,源驗證程式的取款地址必須在請求上簽名。 這證明了對於驗證程式資金的控制權。
@@ -125,11 +125,11 @@ MaxEB 允許驗證程式將其全部餘額轉賬給另一個驗證程式。 提
注意:簽名由取款地址執行,而非通過驗證程式的密鑰。
-### 部分取款{#partial-withdrawals}
+### 部分取款 {#partial-withdrawals}
有着**類型1** 憑證的驗證者會自動地、無需Gas 費地把它們的超額餘額(任何超過 32 ETH的)清理到他們的提款地址。 由於 **類型2**驗證者允許以 1 ETH 為增量單位進行餘額複利累積,在餘額達到 2048 ETH 之前,系統不會自動清理餘額。 在 **類型 2** 驗證程式上的部分提取必須被手動觸發,且需要消耗燃料。
-## 合併工具{#consolidation-tooling}
+## 合併工具 {#consolidation-tooling}
有幾種可以使用的工具來管理合併。 [啟動面板(Launchpad)](https://launchpad.ethereum.org/en/validator-actions) 是由以太坊基金會創建的官方工具。 還有一些由質押社區的實體創建的第三方工具,可能提供該啟動版(Launchpad)未提供的功能。 儘管這裡的工具沒有經過以太坊基金會的審計或認可,社區知名成員的開源工具如下。
@@ -195,7 +195,7 @@ MaxEB 允許驗證程式將其全部餘額轉賬給另一個驗證程式。 提
是的, 只要驗證程式處在活躍狀態(未退出)且你能用其取款地址進行簽名,你就可以進行轉換。
-## 資源{#resources}
+## 資源 {#resources}
- 【Electra 共識規範】(https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md)這是您應該參照的最權威的版本。 當您感到疑惑的時候,請閱讀這些規範
- 並非每個人都擅長閱讀程式碼。因此,[這個 maxEB-GPT](https://chatgpt.com/g/g-67f1650fb48081918f555e0c8d1c2ae9-maxeb-gpt) 可以幫助解讀規範。 _免責聲明:應參照規範本身,而非AI作為事實的來源,因為AI可能會誤解信息或者提供幻覺回答_
diff --git a/public/content/translations/zh-tw/roadmap/verkle-trees/index.md b/public/content/translations/zh-tw/roadmap/verkle-trees/index.md
index 971ff0e320b..c0535ed57be 100644
--- a/public/content/translations/zh-tw/roadmap/verkle-trees/index.md
+++ b/public/content/translations/zh-tw/roadmap/verkle-trees/index.md
@@ -36,6 +36,7 @@ Merkle 樹的結構導致證據非常大,以至於無法在 12 秒的時隙內
## 沃克爾樹的結構為何? {#what-is-the-structure-of-a-verkle-tree}
+
沃克爾樹是 `(key,value)` 配對,其中的鍵是由 31 位元組的 _主幹_ 和單一位元組的 _後綴_ 所組成的 32 位元組元素。 這些鍵被整理到 _擴充_ 節點和 _內部_ 節點中。 擴展節點是單一的主幹,包含 256 個具有不同後綴的子節點。 內部節點也有 256 個子節點,但可以是其他擴展節點。 沃克爾樹和梅克爾樹結構的主要區別是,沃克爾樹更加扁平,表示將葉子連接到根的中間節點較少,因此產生證明時所需的資料更少。

diff --git a/public/content/translations/zh-tw/security/index.md b/public/content/translations/zh-tw/security/index.md
index 39c1d40c282..6b3f69ec9df 100644
--- a/public/content/translations/zh-tw/security/index.md
+++ b/public/content/translations/zh-tw/security/index.md
@@ -49,7 +49,7 @@ lang: zh-tw
讓私密金鑰保持在離線狀態,即使駭客掌握你的電腦,也能大幅減少駭客入侵的風險。
-#### 試用硬體錢包:{#try-hardware-wallet}
+#### 試用硬體錢包: {#try-hardware-wallet}
- [Ledger](https://www.ledger.com/)
- [Trezor](https://trezor.io/)
@@ -202,7 +202,7 @@ _注意:有些衍生代幣/代碼可能代表已質押的 ETH (即 Rocket Pool
另一個常見的錯誤是使用可透過[社交工程](https://wikipedia.org/wiki/Social_engineering_\(security\))輕易猜出或發現的密碼。 在密碼中使用母親娘家姓、子女或寵物的名字或出生日期,都會增加密碼遭駭的風險。
-#### 良好的密碼習慣:{#good-password-practices}
+#### 良好的密碼習慣: {#good-password-practices}
- 只要密碼產生器或填寫的表單允許,密碼越長越好
- 混用大小寫字母、數字及符號
@@ -230,7 +230,7 @@ _注意:有些衍生代幣/代碼可能代表已質押的 ETH (即 Rocket Pool

-#### 試用密碼管理員:{#try-password-manager}
+#### 試用密碼管理員: {#try-password-manager}
- [Bitwarden](https://bitwarden.com/)
- [KeePass](https://keepass.info/)
@@ -268,7 +268,7 @@ _注意:有些衍生代幣/代碼可能代表已質押的 ETH (即 Rocket Pool
瀏覽器擴充功能,如 Chrome 擴充功能或 Firefox 附加功能能增強瀏覽器功能,但也伴隨著風險。 大多數瀏覽器擴充功能,皆預設請求「讀取和變更網站資料」的存取權限,如此一來,其幾乎能對你的資料為所欲為。 Chrome 擴充功能總會自動更新,因此原本安全的擴充元件,之後可能會更新並加入惡意程式碼。 多數瀏覽器擴充功能都不會試圖竊取你的資料,但你應該知道它是辦得到的。
-#### 確保安全的方法:{#browser-extension-safety}
+#### 確保安全的方法: {#browser-extension-safety}
- 安裝瀏覽器擴充功能時,只接受信任的來源
- 移除不使用的瀏覽器擴充功能
diff --git a/public/content/translations/zh-tw/staking/pools/index.md b/public/content/translations/zh-tw/staking/pools/index.md
index f1cbd064d42..bc30f036be9 100644
--- a/public/content/translations/zh-tw/staking/pools/index.md
+++ b/public/content/translations/zh-tw/staking/pools/index.md
@@ -13,13 +13,13 @@ summaryPoints:
- 在你自己的錢包中持有質押代幣
---
-## 什麼是質押礦池 什麼是質押池?{#what-are-staking-pools}
+## 什麼是質押礦池 什麼是質押池? {#what-are-staking-pools}
質押礦池是一種協作方式,允許擁有少量以太幣的人能夠滿足 32 個以太幣此一條件,以啟動一組驗證者金鑰。 由於協定本身並不支援聯合質押這項功能,因此需要單獨建立解決方案來滿足此需求。
一些礦池使用智慧型合約運作,可以將資金存入合約,由合約以去信任的方式管理和追蹤你的質押品,並向你發放相應價值的代幣。 其他礦池可能不涉及智能合約,而是在鏈下調解。
-## 為什麼要使用礦池進行質押 為何要透過質押池進行質押?{#why-stake-with-a-pool}
+## 為什麼要使用礦池進行質押 為何要透過質押池進行質押? {#why-stake-with-a-pool}
除了我們在 [質押簡介](/staking/) 中概述的好處之外,透過質押池質押還有許多獨特的好處。
diff --git a/public/content/translations/zh-tw/staking/saas/index.md b/public/content/translations/zh-tw/staking/saas/index.md
index f111440d4bc..f08ecf6b61a 100644
--- a/public/content/translations/zh-tw/staking/saas/index.md
+++ b/public/content/translations/zh-tw/staking/saas/index.md
@@ -14,9 +14,11 @@ summaryPoints:
---
## 什麼是質押即服務? {#what-is-staking-as-a-service}
+
質押即服務(「SaaS」)代表一種質押服務,你將自己的 32 個以太幣存入驗證者,但將節點運作委託給第三方營運商。 此流程通常需要你按指引完成初始化設定,包括產生金鑰和存入資金,然後將你的簽名金鑰上傳給營運商。 這將允許該服務代表你運作你的驗證者,通常是按月收費。
## 為什麼需要質押服務? {#why-stake-with-a-service}
+
以太坊協定本身並不支援質押委託,因此為了滿足此項需求,這類服務應運而生。 如果你有 32 個以太幣要質押,但懶得處理硬體設備,質押即服務可以讓你在賺取原生區塊酬勞的同時將困難的部分外包。
diff --git a/public/content/translations/zh-tw/staking/solo/index.md b/public/content/translations/zh-tw/staking/solo/index.md
index 2bddd2a3bb9..d6e3ff1f902 100644
--- a/public/content/translations/zh-tw/staking/solo/index.md
+++ b/public/content/translations/zh-tw/staking/solo/index.md
@@ -4,7 +4,7 @@ description: "如何開始單獨質押以太幣的概覽"
lang: zh-tw
template: staking
emoji: ":money_with_wings:"
-image: /images/staking/leslie-withdrawal.png
+image: /images/staking/leslie-solo.png
alt: "萊斯利犀牛在她自己的電腦晶片上。"
sidebarDepth: 2
summaryPoints:
@@ -71,6 +71,7 @@ summaryPoints:
更多關於罰沒與驗證者生命週期的資訊
+
diff --git a/public/content/translations/zh-tw/web3/index.md b/public/content/translations/zh-tw/web3/index.md
index 4d50e8ed304..0b3b38816d1 100644
--- a/public/content/translations/zh-tw/web3/index.md
+++ b/public/content/translations/zh-tw/web3/index.md
@@ -69,8 +69,7 @@ Web3 允許透過 [非同質化代幣 (NFT)](/glossary/#nft) 實現直接所有
- 深入了解非同質化代幣
-
+ 深入了解非同質化代幣
更多關於 NFT 的資訊
@@ -98,8 +97,7 @@ Web 2.0 要求內容製作者相信平台不會更改規則,但抗審查是 We
- 了解更多關於去中心化自治組織的資訊
-
+ 了解更多關於去中心化自治組織的資訊
更多關於 DAO 的資訊
diff --git a/public/content/translations/zh-tw/wrapped-eth/index.md b/public/content/translations/zh-tw/wrapped-eth/index.md
index 978475304f2..1353eb14eae 100644
--- a/public/content/translations/zh-tw/wrapped-eth/index.md
+++ b/public/content/translations/zh-tw/wrapped-eth/index.md
@@ -8,8 +8,7 @@ lang: zh-tw
-在 [WrapETH.com](https://www.wrapeth.com/) 連接你的錢包,即可在任何鏈上包裝或解包 ETH
-
+在 [WrapETH.com](https://www.wrapeth.com/) 連接你的錢包,即可在任何鏈上包裝或解包 ETH
以太幣 (ETH) 是以太坊的主要貨幣。 以太幣有多種用途,例如質押、作為貨幣使用、以及支付計算所需要的燃料費。 **包裝以太幣實際上是以太幣的升級形式,具備許多應用程式和 [ERC-20 代幣](/glossary/#erc-20)(即以太坊上其他類型的數位資產)所需的額外功能。** 要與這些代幣互動,以太幣需要遵循與它們相同的規則,這些規則被稱為 ERC-20 標準。
diff --git a/src/scripts/i18n/post_import_sanitize.ts b/src/scripts/i18n/post_import_sanitize.ts
deleted file mode 100644
index 75456a69d94..00000000000
--- a/src/scripts/i18n/post_import_sanitize.ts
+++ /dev/null
@@ -1,1437 +0,0 @@
-import * as fs from "fs"
-import * as path from "path"
-
-/**
- * Post-import sanitizer for Crowdin translations.
- *
- * - Synchronize custom Markdown header IDs `{#...}` with English source (ASCII-only)
- * - Normalize block HTML tag line breaks (opening and closing tags on their own lines)
- * - Protect known brand/team names from inadvertent translation
- * - Validate JSON files; report issues
- *
- * Usage:
- * npx ts-node -O '{"module":"commonjs"}' ./src/scripts/i18n/post_import_sanitize.ts
- *
- * Env:
- * TARGET_LANGUAGES (comma-separated, e.g. "es-EM") optional; defaults to scanning all `translations/*` folders
- */
-
-const ROOT = process.cwd()
-const CONTENT_ROOT = path.join(ROOT, "public", "content")
-
-const BLOCK_HTML_TAGS = [
- "section",
- "div",
- "article",
- "aside",
- "header",
- "footer",
-]
-
-/**
- * MDX block components that need opening/closing tags on separate lines.
- * ButtonLink is intentionally excluded - it's an inline component.
- */
-const BLOCK_MDX_COMPONENTS = [
- "Card",
- "ExpandableCard",
- "Alert",
- "AlertEmoji",
- "AlertContent",
- "AlertDescription",
- "CardGrid",
- "InfoGrid",
- "InfoBanner",
- "Tabs",
- "TabItem",
-]
-
-function listFiles(
- dir: string,
- predicate: (file: string) => boolean
-): string[] {
- const out: string[] = []
- const stack: string[] = [dir]
- while (stack.length) {
- const d = stack.pop()!
- const entries = fs.readdirSync(d, { withFileTypes: true })
- for (const e of entries) {
- const full = path.join(d, e.name)
- if (e.isDirectory()) stack.push(full)
- else if (predicate(full)) out.push(full)
- }
- }
- return out
-}
-
-function toAsciiId(id: string): string {
- // keep only ASCII letters, numbers, hyphens and underscores; strip accents
- const normalized = id.normalize("NFD").replace(/[\u0300-\u036f]/g, "")
- return normalized.replace(/[^A-Za-z0-9_-]/g, "-")
-}
-
-// Critical regex checks adapted from legacy markdownChecker
-const BROKEN_LINK_REGEX = /\[[^\]]+\]\([^)\s]+\s[^)]+\)/g
-const INVALID_LINK_REGEX =
- /(? 0) {
- // Brand is in English, check if it's preserved in translation
- const inTranslation = translatedContent.match(brandRegex)
- const englishCount = inEnglish.length
- const translationCount = inTranslation?.length ?? 0
-
- if (translationCount < englishCount) {
- warnings.push(
- `Protected brand "${brand}" appears ${englishCount}x in English but ${translationCount}x in translation - may have been mistranslated`
- )
- }
- }
- }
-
- return warnings
-}
-
-/**
- * Fix duplicated headings where the text is repeated.
- * Pattern: ## Text? Text? {#id} → ## Text? {#id}
- * This happens when translators accidentally duplicate question headings.
- */
-function fixDuplicatedHeadings(content: string): {
- content: string
- fixCount: number
-} {
- let result = content
- let fixCount = 0
-
- // Match headings where text is duplicated: ## Text Text {#id} or ## Text? Text? {#id}
- // Captures: (hashes) (text including punctuation) (same text) (custom id)
- const duplicatedHeadingRe =
- /^(#{1,6})\s+(.+?[?!.]?)\s+\2\s*(\{#[^}]+\})\s*$/gm
-
- result = result.replace(duplicatedHeadingRe, (_, hashes, text, id) => {
- fixCount++
- return `${hashes} ${text} ${id}`
- })
-
- return { content: result, fixCount }
-}
-
-/**
- * Fix broken markdown links where there's a space between ] and (.
- * Pattern: ] (https://... → ](https://...
- * This is a common translation artifact from Crowdin.
- */
-function fixBrokenMarkdownLinks(content: string): {
- content: string
- fixCount: number
-} {
- let fixCount = 0
-
- // Match ] followed by space(s) then ( - this breaks markdown links
- const result = content.replace(/\]\s+\(/g, () => {
- fixCount++
- return "]("
- })
-
- return { content: result, fixCount }
-}
-
-/**
- * Fix collapsed line breaks between consecutive MDX components.
- * Pattern: → \n
- * This happens when translators collapse multiple components onto one line.
- */
-function fixCollapsedComponentLineBreaks(
- translatedContent: string,
- englishContent: string
-): { content: string; fixCount: number } {
- let result = translatedContent
- let fixCount = 0
-
- // Find components that appear consecutively in English (on separate lines)
- // and restore line breaks in translation if they were collapsed
- const consecutiveComponentRe =
- /<\/([A-Z][A-Za-z]*)[^>]*>\s*<([A-Z][A-Za-z]*)/g
-
- // Check English for line break patterns between components
- const englishMatches = [...englishContent.matchAll(consecutiveComponentRe)]
- for (const match of englishMatches) {
- const fullMatch = match[0]
- // If English has a newline between these components
- if (fullMatch.includes("\n")) {
- // Find same pattern in translation (possibly without newline)
- const closingTag = match[1]
- const openingTag = match[2]
- const collapsedRe = new RegExp(
- `${closingTag}>[ \\t]+<${openingTag}`,
- "g"
- )
- const collapsedMatches = result.match(collapsedRe)
- if (collapsedMatches) {
- fixCount += collapsedMatches.length
- result = result.replace(collapsedRe, `${closingTag}>\n<${openingTag}`)
- }
- }
- }
-
- return { content: result, fixCount }
-}
-
-/**
- * Extract all href values from content (both markdown links and JSX/HTML attributes).
- */
-function extractHrefs(content: string): Set {
- const hrefs = new Set()
-
- // Markdown links: [text](href)
- const markdownLinkRe = /\[[^\]]*\]\(([^)]+)\)/g
- let match
- while ((match = markdownLinkRe.exec(content))) {
- hrefs.add(match[1])
- }
-
- // JSX/HTML href attributes: href="..." or href='...'
- const hrefAttrRe = /href=["']([^"']+)["']/g
- while ((match = hrefAttrRe.exec(content))) {
- hrefs.add(match[1])
- }
-
- return hrefs
-}
-
-/**
- * Extract hrefs from a single text block (paragraph/section).
- * Returns array to preserve duplicates within the block.
- */
-function extractHrefsFromBlock(block: string): string[] {
- const hrefs: string[] = []
-
- // Markdown links: [text](href)
- const markdownLinkRe = /\[[^\]]*\]\(([^)]+)\)/g
- let match
- while ((match = markdownLinkRe.exec(block))) {
- hrefs.push(match[1])
- }
-
- // JSX/HTML href attributes: href="..." or href='...'
- const hrefAttrRe = /href=["']([^"']+)["']/g
- while ((match = hrefAttrRe.exec(block))) {
- hrefs.push(match[1])
- }
-
- return hrefs
-}
-
-/**
- * Split markdown content into logical blocks (paragraphs/sections).
- * Blocks are separated by blank lines.
- */
-function splitIntoBlocks(content: string): string[] {
- // Split on one or more blank lines
- return content.split(/\n\s*\n/).filter((block) => block.trim().length > 0)
-}
-
-/**
- * Fix translated hrefs by comparing against English source.
- * Uses paragraph-scoped set comparison for robust matching across languages.
- *
- * Strategy:
- * 1. Split both documents into blocks (paragraphs separated by blank lines)
- * 2. For each block pair, compare internal href sets
- * 3. Within a block: if invalid href count equals missing href count, we can match
- * 4. This handles grammatical reordering within sentences (common in non-English)
- *
- * Only auto-fixes unambiguous cases; warns for complex mismatches.
- */
-function fixTranslatedHrefs(
- translatedContent: string,
- englishContent: string
-): { content: string; fixCount: number; fixes: string[]; warnings: string[] } {
- const englishBlocks = splitIntoBlocks(englishContent)
- const translatedBlocks = splitIntoBlocks(translatedContent)
-
- // Collect all English internal hrefs as the "valid" set
- const allEnglishHrefs = extractHrefs(englishContent)
-
- const allFixes: Array<[string, string]> = [] // [wrong, correct]
- const allWarnings: string[] = []
-
- // Process block by block
- const blockCount = Math.min(englishBlocks.length, translatedBlocks.length)
-
- for (let i = 0; i < blockCount; i++) {
- const engBlock = englishBlocks[i]
- const transBlock = translatedBlocks[i]
-
- const engHrefs = extractHrefsFromBlock(engBlock).filter(isInternalHref)
- const transHrefs = extractHrefsFromBlock(transBlock).filter(isInternalHref)
-
- // Skip blocks with no internal hrefs
- if (engHrefs.length === 0 && transHrefs.length === 0) continue
-
- // Find hrefs in translation that don't exist in English (invalid)
- const transHrefSet = new Set(transHrefs)
-
- const invalidInTrans: string[] = [] // In translation but not in any English href
- const missingFromTrans: string[] = [] // In English block but not in translation
-
- for (const href of transHrefs) {
- if (!allEnglishHrefs.has(href)) {
- invalidInTrans.push(href)
- }
- }
-
- for (const href of engHrefs) {
- if (!transHrefSet.has(href)) {
- missingFromTrans.push(href)
- }
- }
-
- // No issues in this block
- if (invalidInTrans.length === 0 && missingFromTrans.length === 0) continue
-
- // Deduplicate for set comparison
- const uniqueInvalid = [...new Set(invalidInTrans)]
- const uniqueMissing = [...new Set(missingFromTrans)]
-
- // Only auto-fix when there's exactly 1 invalid and 1 missing in block
- // Multiple mismatches within same block could be reordered - don't guess
- if (uniqueInvalid.length === 1 && uniqueMissing.length === 1) {
- allFixes.push([uniqueInvalid[0], uniqueMissing[0]])
- } else if (uniqueInvalid.length > 0 || uniqueMissing.length > 0) {
- // Count mismatch - can't safely fix, warn instead
- for (const href of uniqueInvalid) {
- allWarnings.push(
- `Block ${i + 1}: Invalid href "${href}" - not a valid English path`
- )
- }
- for (const href of uniqueMissing) {
- allWarnings.push(
- `Block ${i + 1}: Missing href "${href}" - present in English but not translation`
- )
- }
- }
- }
-
- // Warn about block count mismatch
- if (englishBlocks.length !== translatedBlocks.length) {
- allWarnings.push(
- `Block count mismatch: English has ${englishBlocks.length}, translation has ${translatedBlocks.length}`
- )
- }
-
- // Apply all fixes
- let result = translatedContent
- const appliedFixes: string[] = []
-
- for (const [wrong, correct] of allFixes) {
- // Replace in markdown links: [text](wrong) → [text](correct)
- const markdownRe = new RegExp(
- `(\\[[^\\]]*\\]\\()${escapeRegex(wrong)}(\\))`,
- "g"
- )
- const beforeMd = result
- result = result.replace(markdownRe, `$1${correct}$2`)
-
- // Replace in href attributes: href="wrong" → href="correct"
- const hrefRe = new RegExp(`(href=["'])${escapeRegex(wrong)}(["'])`, "g")
- const beforeAttr = result
- result = result.replace(hrefRe, `$1${correct}$2`)
-
- if (result !== beforeMd || result !== beforeAttr) {
- appliedFixes.push(`${wrong} → ${correct}`)
- }
- }
-
- return {
- content: result,
- fixCount: appliedFixes.length,
- fixes: appliedFixes,
- warnings: allWarnings,
- }
-}
-
-/**
- * Escape special regex characters in a string.
- */
-function escapeRegex(str: string): string {
- return str.replace(/[.*+?^${}()|[\]\\]/g, "\\$&")
-}
-
-/**
- * Check if href is an internal link (starts with / but not //).
- */
-function isInternalHref(href: string): boolean {
- return href.startsWith("/") && !href.startsWith("//")
-}
-
-function lineAt(file: string, index: number): string {
- const fileSubstring = file.substring(0, index)
- const lines = fileSubstring.split("\n")
- const linePosition = lines.length
- const charPosition = lines[lines.length - 1].length + 1
- const lineNumber = `${linePosition}:${charPosition}`
- return lineNumber
-}
-interface HeaderInfo {
- level: number // Number of # symbols
- text: string // Header text (translated or English)
- id: string // Custom ID from {#id}
- fullMatch: string // Full matched string for replacement
-}
-
-function extractHeaderStructure(md: string): HeaderInfo[] {
- const headers: HeaderInfo[] = []
- const headingRe = /^(#{1,6})\s+(.+?)\s*\{#([^}]+)\}\s*$/gm
- let m: RegExpExecArray | null
- while ((m = headingRe.exec(md))) {
- headers.push({
- level: m[1].length,
- text: m[2].trim(),
- id: m[3].trim(),
- fullMatch: m[0],
- })
- }
- return headers
-}
-
-function syncHeaderIdsWithEnglish(
- translatedMd: string,
- englishMd: string
-): string {
- // Extract header structure from both files
- const englishHeaders = extractHeaderStructure(englishMd)
- const translatedHeaders = extractHeaderStructure(translatedMd)
-
- // Match headers by position and level in the document structure
- // If structure matches, copy English IDs to translated headers
- if (englishHeaders.length !== translatedHeaders.length) {
- console.warn(
- `[WARN] Header count mismatch: English has ${englishHeaders.length}, translated has ${translatedHeaders.length}`
- )
- }
-
- let result = translatedMd
- // Match headers by index - same position = same semantic header
- for (let i = 0; i < translatedHeaders.length; i++) {
- const translatedHeader = translatedHeaders[i]
- const englishHeader = englishHeaders[i]
-
- if (!englishHeader) {
- // More headers in translation than English - skip
- continue
- }
-
- if (translatedHeader.level !== englishHeader.level) {
- console.warn(
- `[WARN] Header level mismatch at position ${i}: English H${englishHeader.level} vs translated H${translatedHeader.level}`
- )
- // Still try to sync the ID even if levels don't match
- }
-
- // Replace the translated header's ID with the English ID (ASCII-normalized)
- const asciiId = toAsciiId(englishHeader.id)
- const updatedHeader = `${"#".repeat(translatedHeader.level)} ${translatedHeader.text} {#${asciiId}}`
-
- // Use a more specific replacement to avoid affecting other occurrences
- result = result.replace(translatedHeader.fullMatch, updatedHeader)
- }
-
- return result
-}
-
-function normalizeBlockHtmlLines(md: string): string {
- for (const tag of BLOCK_HTML_TAGS) {
- const inlineCloseRe = new RegExp(`([^\\n])\\s*${tag}>`, "g")
- md = md.replace(inlineCloseRe, (_, before) => `${before}\n${tag}>`)
- }
- return md
-}
-
-/**
- * Restore blank lines after headers and block components by comparing
- * with English source structure. This preserves readability and formatting.
- */
-function restoreBlankLinesFromEnglish(
- translatedMd: string,
- englishMd: string
-): { content: string; fixCount: number } {
- const translatedLines = translatedMd.split("\n")
- const englishLines = englishMd.split("\n")
-
- let fixCount = 0
- const result: string[] = []
-
- // Patterns that should have blank lines after them
- const headerPattern = /^#{1,6}\s+/
- const blockComponentClosePattern = new RegExp(
- `(${BLOCK_MDX_COMPONENTS.join("|")})>`
- )
-
- for (let i = 0; i < translatedLines.length; i++) {
- const line = translatedLines[i]
- result.push(line)
-
- // Check if this line should be followed by a blank line
- const isHeader = headerPattern.test(line)
- const isBlockClose = blockComponentClosePattern.test(line)
-
- if (isHeader || isBlockClose) {
- const nextLine = translatedLines[i + 1]
- const hasBlankAfter = nextLine === ""
-
- // Find corresponding line in English by matching pattern
- let englishShouldHaveBlank = false
- for (let j = 0; j < englishLines.length; j++) {
- const englishLine = englishLines[j]
- if (isHeader && headerPattern.test(englishLine)) {
- // Headers should match by structure (level)
- const transLevel = (line.match(/^#+/) || [""])[0].length
- const engLevel = (englishLine.match(/^#+/) || [""])[0].length
- if (transLevel === engLevel) {
- englishShouldHaveBlank = englishLines[j + 1] === ""
- break
- }
- } else if (
- isBlockClose &&
- blockComponentClosePattern.test(englishLine)
- ) {
- englishShouldHaveBlank = englishLines[j + 1] === ""
- break
- }
- }
-
- // Add blank line if English has it but translation doesn't
- if (englishShouldHaveBlank && !hasBlankAfter && nextLine !== undefined) {
- result.push("")
- fixCount++
- }
- }
- }
-
- return { content: result.join("\n"), fixCount }
-}
-
-/**
- * Normalize inline component formatting to match English source.
- * If English has the component on one line, collapse translated version too.
- * This prevents MDX from wrapping multi-line content in tags.
- */
-function normalizeInlineComponentsFromEnglish(
- translatedMd: string,
- englishMd: string
-): {
- content: string
- fixCount: number
-} {
- const inlineComponents = ["ButtonLink"]
-
- let content = translatedMd
- let fixCount = 0
-
- for (const component of inlineComponents) {
- // Extract English instances and check if they're single-line
- // Key by href attribute since that's preserved in translation
- const englishRe = new RegExp(
- `<${component}[^>]*href="([^"]*)"[^>]*>([\\s\\S]*?)${component}>`,
- "g"
- )
- const englishFormats = new Map() // href -> isOneLine
-
- let match
- while ((match = englishRe.exec(englishMd))) {
- const href = match[1]
- const innerContent = match[2]
- const isOneLine = !innerContent.includes("\n")
- englishFormats.set(href, isOneLine)
- }
-
- // For each translated instance, mirror English format
- const translatedRe = new RegExp(
- `(<${component}[^>]*href="([^"]*)"[^>]*>)([\\s\\S]*?)(${component}>)`,
- "g"
- )
- content = content.replace(
- translatedRe,
- (fullMatch, openTag, href, innerContent, closeTag) => {
- const englishIsOneLine = englishFormats.get(href)
- const translatedHasLineBreaks = innerContent.includes("\n")
-
- // If English is single-line but translated has line breaks, collapse it
- if (englishIsOneLine && translatedHasLineBreaks) {
- fixCount++
- return `${openTag}${innerContent.trim()}${closeTag}`
- }
- return fullMatch
- }
- )
- }
-
- return { content, fixCount }
-}
-
-function fixBlockComponentLineBreaks(md: string): {
- content: string
- fixCount: number
-} {
- let content = md
- let fixCount = 0
-
- for (const component of BLOCK_MDX_COMPONENTS) {
- // Fix inline closing tags: content
→ content\n
- const inlineCloseRe = new RegExp(`([^\\n])\\s*${component}>`, "g")
- content = content.replace(inlineCloseRe, (_, before) => {
- fixCount++
- return `${before}\n${component}>`
- })
-
- // Fix inline opening tags: content → \ncontent
- // Match any non-newline character after the tag (including other tags)
- const inlineOpenRe = new RegExp(`(<${component}[^>]*>)([^\\n])`, "g")
- content = content.replace(inlineOpenRe, (_, tag, after) => {
- fixCount++
- return `${tag}\n${after}`
- })
- }
-
- return { content, fixCount }
-}
-
-/**
- * Collapse inline HTML tags to single line when English source has them on one line.
- * Fixes MDX paragraph wrapping issues: content\n
→ content
- */
-function collapseInlineHtmlFromEnglish(
- translatedMd: string,
- englishMd: string
-): { content: string; fixCount: number } {
- const inlineTags = ["div", "span", "p", "strong", "em"]
- let content = translatedMd
- let fixCount = 0
-
- // Build a set of lines in English where tag opens and closes on same line
- const englishLines = englishMd.split("\n")
-
- for (const tag of inlineTags) {
- // Find English lines that have ... all on one line
- // (content can include nested tags like ,
, etc.)
- const singleLinePattern = new RegExp(`<${tag}[^>]*>.*${tag}>`)
- const englishSingleLineSet = new Set()
-
- for (const line of englishLines) {
- if (singleLinePattern.test(line)) {
- // Extract just the opening tag to use as a key
- const openTagMatch = line.match(new RegExp(`<${tag}[^>]*>`))
- if (openTagMatch) {
- englishSingleLineSet.add(openTagMatch[0])
- }
- }
- }
-
- // In translated content, find cases where:
- // - Opening tag + content is on one line (content may include nested tags)
- // - Newline follows
- // - Closing tag is on the next line (possibly with leading whitespace)
- // Pattern: content-with-possible-nested-tags\n
- const translatedMultiLineRe = new RegExp(
- `(<${tag}[^>]*>)([^\\n]+)\\n(\\s*${tag}>)`,
- "g"
- )
-
- content = content.replace(
- translatedMultiLineRe,
- (fullMatch, openTag, innerContent, closeTagLine) => {
- // Check if this opening tag should be single-line per English
- if (englishSingleLineSet.has(openTag)) {
- fixCount++
- // Collapse: opening tag + trimmed content + closing tag (no newline)
- return `${openTag}${innerContent.trim()}${closeTagLine.trim()}`
- }
- return fullMatch
- }
- )
- }
-
- return { content, fixCount }
-}
-
-/**
- * Fix JSX component closing tags that are merged with content.
- * English format:
- *
- * Content
- *
- * Spanish (broken):
- *
- * Content
- * This function splits the closing tag to its own line when English has it that way.
- */
-function fixMergedClosingTags(
- translatedMd: string,
- englishMd: string
-): { content: string; fixCount: number } {
- const componentTags = ["ButtonLink", "Link"]
- let content = translatedMd
- let fixCount = 0
-
- for (const tag of componentTags) {
- // Find patterns in English where the closing tag is on its own line
- // Pattern: \n content\n or \n content\n
- const englishMultiLineRe = new RegExp(
- `<${tag}[^>]*>\\n[\\s\\S]*?\\n\\s*${tag}>`,
- "g"
- )
-
- // Check if English uses multi-line format for this component
- if (!englishMultiLineRe.test(englishMd)) continue
-
- // In translated content, find cases where closing tag is merged with content on same line
- // Pattern: \n content (content and closing tag on same line)
- const mergedPattern = new RegExp(
- `(<${tag}[^>]*>\\n)(\\s*)([^\\n]+)(${tag}>)`,
- "g"
- )
-
- content = content.replace(
- mergedPattern,
- (match, openTagLine, indent, innerContent, closeTag) => {
- // Only fix if the inner content doesn't end with just whitespace
- // and the closing tag is directly after content (not on its own line)
- const trimmedContent = innerContent.trimEnd()
- if (trimmedContent.length > 0 && !innerContent.includes("\n")) {
- fixCount++
- // Split: put closing tag on its own line with same indentation
- return `${openTagLine}${indent}${trimmedContent}\n${indent}${closeTag}`
- }
- return match
- }
- )
- }
-
- return { content, fixCount }
-}
-
-/**
- * Repair unclosed backticks by comparing with English source.
- * Detects lines with odd backtick counts containing < and attempts repair.
- */
-function repairUnclosedBackticks(
- translatedMd: string,
- englishMd: string
-): { content: string; fixCount: number } {
- const translatedLines = translatedMd.split("\n")
- const englishLines = englishMd.split("\n")
- let fixCount = 0
-
- for (let i = 0; i < translatedLines.length; i++) {
- const line = translatedLines[i]
- const backtickCount = (line.match(/`/g) || []).length
-
- // Odd number of backticks and contains < means potentially unclosed code with HTML-like content
- if (
- backtickCount % 2 === 1 &&
- line.includes("<") &&
- !line.includes("```")
- ) {
- // Try to find a matching English line with similar structure
- for (const engLine of englishLines) {
- // Look for English lines with balanced backticks containing similar patterns
- const engBackticks = (engLine.match(/`/g) || []).length
- if (
- engBackticks % 2 === 0 &&
- engBackticks > 0 &&
- engLine.includes("<")
- ) {
- // Extract inline code blocks from English
- const codeBlockRe = /`([^`]+)`/g
- let engMatch
- while ((engMatch = codeBlockRe.exec(engLine))) {
- const engCode = engMatch[1]
- // Check if the translated line contains this code pattern without closing backtick
- const unbalancedPattern = new RegExp(
- "`" +
- engCode
- .replace(/[.*+?^${}()|[\]\\]/g, "\\$&")
- .replace(/\s+/g, "\\s*")
- )
- if (
- unbalancedPattern.test(line) &&
- !line.includes("`" + engCode + "`")
- ) {
- // Found a match - add the missing closing backtick
- translatedLines[i] = line.replace(
- new RegExp(
- "`" +
- engCode
- .replace(/[.*+?^${}()|[\]\\]/g, "\\$&")
- .replace(/\s+/g, "\\s*")
- ),
- "`" + engCode + "`"
- )
- fixCount++
- break
- }
- }
- if (fixCount > 0) break
- }
- }
- }
- }
-
- return { content: translatedLines.join("\n"), fixCount }
-}
-
-/**
- * Normalize frontmatter dates from localized format (DD-MM-YYYY) back to ISO (YYYY-MM-DD).
- */
-function normalizeFrontmatterDates(content: string): {
- content: string
- fixCount: number
-} {
- let fixCount = 0
-
- // Match frontmatter block
- const frontmatterRe = /^---\n([\s\S]*?)\n---/
- const match = content.match(frontmatterRe)
- if (!match) return { content, fixCount }
-
- let frontmatter = match[1]
- const originalFrontmatter = frontmatter
-
- // Fix published: dates in DD-MM-YYYY or DD/MM/YYYY format
- frontmatter = frontmatter.replace(
- /^(published:\s*)(\d{1,2})[-/](\d{1,2})[-/](\d{4})$/gm,
- (_, prefix, day, month, year) => {
- fixCount++
- // Pad day and month with leading zeros if needed
- const paddedDay = day.padStart(2, "0")
- const paddedMonth = month.padStart(2, "0")
- return `${prefix}${year}-${paddedMonth}-${paddedDay}`
- }
- )
-
- if (frontmatter !== originalFrontmatter) {
- content = content.replace(frontmatterRe, `---\n${frontmatter}\n---`)
- }
-
- return { content, fixCount }
-}
-
-/**
- * Sync protected frontmatter fields from English source.
- * These fields should never be translated (e.g., template, sidebar).
- */
-function syncProtectedFrontmatterFields(
- translatedMd: string,
- englishMd: string
-): { content: string; fixCount: number } {
- // Fields that should never be translated - sync from English canonical
- // Note: 'buttons' array needs special handling (content translatable, toId/isSecondary not)
- // Note: 'lang' must NOT be protected - it must remain as target language code
- const protectedFields = [
- "template",
- "sidebar",
- "sidebarDepth",
- "published",
- "author",
- "source",
- "sourceUrl",
- "address",
- "emoji",
- "skill",
- "isOutdated",
- "incomplete",
- "hideEditButton",
- "showDropdown",
- "image",
- "blurDataURL",
- ]
- let fixCount = 0
-
- // Extract frontmatter from both
- const frontmatterRe = /^---\n([\s\S]*?)\n---/
- const transMatch = translatedMd.match(frontmatterRe)
- const engMatch = englishMd.match(frontmatterRe)
-
- if (!transMatch || !engMatch) return { content: translatedMd, fixCount }
-
- let transFrontmatter = transMatch[1]
- const engFrontmatter = engMatch[1]
-
- for (const field of protectedFields) {
- // Get English value
- const engFieldRe = new RegExp(`^${field}:\\s*(.+)$`, "m")
- const engFieldMatch = engFrontmatter.match(engFieldRe)
- if (!engFieldMatch) continue
-
- const englishValue = engFieldMatch[1].trim()
-
- // Check if translated value differs
- const transFieldRe = new RegExp(`^${field}:\\s*(.+)$`, "m")
- const transFieldMatch = transFrontmatter.match(transFieldRe)
-
- if (transFieldMatch) {
- const translatedValue = transFieldMatch[1].trim()
- // Remove quotes for comparison
- const cleanTranslated = translatedValue.replace(/^["']|["']$/g, "")
- const cleanEnglish = englishValue.replace(/^["']|["']$/g, "")
-
- if (cleanTranslated !== cleanEnglish) {
- // Replace with English value
- transFrontmatter = transFrontmatter.replace(
- transFieldRe,
- `${field}: ${englishValue}`
- )
- fixCount++
- }
- }
- }
-
- if (fixCount > 0) {
- return {
- content: translatedMd.replace(
- frontmatterRe,
- `---\n${transFrontmatter}\n---`
- ),
- fixCount,
- }
- }
-
- return { content: translatedMd, fixCount }
-}
-
-/**
- * Fix ASCII guillemets (<< and >>) to proper Unicode guillemets (« and »).
- * Prevents MDX parsing errors from malformed angle bracket sequences.
- * IMPORTANT: Skips code blocks where << and >> are valid bit-shift operators.
- */
-function fixAsciiGuillemets(content: string): {
- content: string
- fixCount: number
-} {
- let fixCount = 0
-
- // Split content to preserve code blocks (both fenced and inline)
- // Fenced: ```...``` or ~~~...~~~
- // Inline: `...`
- const codeBlockPattern = /(```[\s\S]*?```|~~~[\s\S]*?~~~|`[^`]+`)/g
- const parts = content.split(codeBlockPattern)
-
- for (let i = 0; i < parts.length; i++) {
- // Skip code blocks (odd indices after split with capturing group)
- if (i % 2 === 1) continue
-
- // Count and replace in non-code parts only
- const leftMatches = parts[i].match(/<>/g)
-
- if (leftMatches) {
- fixCount += leftMatches.length
- parts[i] = parts[i].replace(/<>/g, "»")
- }
- }
-
- return { content: parts.join(""), fixCount }
-}
-
-/**
- * Wrap frontmatter string values containing non-ASCII characters in double quotes.
- * Prevents YAML parsing issues with accented characters.
- */
-function quoteFrontmatterNonAscii(content: string): {
- content: string
- fixCount: number
-} {
- let fixCount = 0
-
- // Match frontmatter block
- const frontmatterRe = /^---\n([\s\S]*?)\n---/
- const match = content.match(frontmatterRe)
- if (!match) return { content, fixCount }
-
- let frontmatter = match[1]
- const originalFrontmatter = frontmatter
-
- // Find lines with unquoted values containing non-ASCII
- const lines = frontmatter.split("\n")
- for (let i = 0; i < lines.length; i++) {
- const line = lines[i]
- // Match key: value pattern
- const keyValueRe = /^(\s*\w+:\s*)(.+)$/
- const kvMatch = line.match(keyValueRe)
- if (kvMatch) {
- const [, prefix, value] = kvMatch
- const trimmedValue = value.trim()
-
- // Skip if already quoted (starts and ends with matching quotes)
- if (
- (trimmedValue.startsWith('"') && trimmedValue.endsWith('"')) ||
- (trimmedValue.startsWith("'") && trimmedValue.endsWith("'"))
- ) {
- continue
- }
-
- // Skip YAML arrays - they handle their own internal quoting
- // Inline arrays: tags: [ "value1", "value2" ]
- if (trimmedValue.startsWith("[") && trimmedValue.endsWith("]")) {
- continue
- }
- // Multi-line array items with - prefix won't match our key:value regex,
- // but check explicitly for robustness (e.g., `key: - value` edge case)
- if (trimmedValue.startsWith("-")) {
- continue
- }
-
- // Check if value contains non-ASCII characters
- // eslint-disable-next-line no-control-regex
- if (/[^\x00-\x7F]/.test(value)) {
- // Escape any existing double quotes in the value
- const escapedValue = trimmedValue.replace(/"/g, '\\"')
- lines[i] = `${prefix}"${escapedValue}"`
- fixCount++
- }
- }
- }
-
- frontmatter = lines.join("\n")
- if (frontmatter !== originalFrontmatter) {
- content = content.replace(frontmatterRe, `---\n${frontmatter}\n---`)
- }
-
- return { content, fixCount }
-}
-
-function processMarkdownFile(
- mdPath: string,
- providedContent?: string
-): {
- fixed: boolean
- issues: string[]
- content: string
-} {
- const issues: string[] = []
- let content = providedContent || fs.readFileSync(mdPath, "utf8")
-
- let englishMd: string | undefined
-
- // Map translated path to English path: remove `/translations//` segment
- const parts = mdPath.split(path.sep)
- const idx = parts.lastIndexOf("translations")
- if (idx === -1 || idx + 2 >= parts.length) {
- issues.push("No translations segment found; skipping formatting sync")
- } else {
- // Use path.resolve to preserve absolute paths (path.join loses leading /)
- const englishPath = path.resolve(
- path.sep,
- ...parts.slice(0, idx),
- ...parts.slice(idx + 2) // drop translations/
- )
- if (fs.existsSync(englishPath)) {
- englishMd = fs.readFileSync(englishPath, "utf8")
- content = syncHeaderIdsWithEnglish(content, englishMd)
- } else {
- issues.push(`English source missing: ${path.relative(ROOT, englishPath)}`)
- }
- }
-
- const before = content
-
- // Fix duplicated headings (e.g., ## Text? Text? {#id} → ## Text? {#id})
- const duplicatedResult = fixDuplicatedHeadings(content)
- content = duplicatedResult.content
- if (duplicatedResult.fixCount > 0) {
- issues.push(`Fixed ${duplicatedResult.fixCount} duplicated headings`)
- }
-
- // Fix broken markdown links (] (https:// → ](https://)
- const brokenLinksResult = fixBrokenMarkdownLinks(content)
- content = brokenLinksResult.content
- if (brokenLinksResult.fixCount > 0) {
- issues.push(`Fixed ${brokenLinksResult.fixCount} broken markdown links`)
- }
-
- // Fix frontmatter issues (don't need English source)
- const dateResult = normalizeFrontmatterDates(content)
- content = dateResult.content
- if (dateResult.fixCount > 0) {
- issues.push(
- `Normalized ${dateResult.fixCount} frontmatter dates to ISO format`
- )
- }
-
- const quoteResult = quoteFrontmatterNonAscii(content)
- content = quoteResult.content
- if (quoteResult.fixCount > 0) {
- issues.push(
- `Quoted ${quoteResult.fixCount} frontmatter values with non-ASCII chars`
- )
- }
-
- const guillemetResult = fixAsciiGuillemets(content)
- content = guillemetResult.content
- if (guillemetResult.fixCount > 0) {
- issues.push(
- `Fixed ${guillemetResult.fixCount} ASCII guillemets (<< >>) to Unicode (« »)`
- )
- }
-
- // Fix escaped backticks (\`) to regular backticks (`)
- // Crowdin sometimes escapes backticks unnecessarily
- const escapedBacktickCount = (content.match(/\\`/g) || []).length
- if (escapedBacktickCount > 0) {
- content = content.replace(/\\`/g, "`")
- issues.push(`Unescaped ${escapedBacktickCount} backslash-escaped backticks`)
- }
-
- // Fix block component line breaks (critical for MDX parser)
- const blockResult = fixBlockComponentLineBreaks(content)
- content = blockResult.content
- if (blockResult.fixCount > 0) {
- issues.push(`Fixed ${blockResult.fixCount} inline block component tags`)
- }
-
- content = normalizeBlockHtmlLines(content)
-
- // Normalize inline components and restore blank lines from English source
- if (englishMd) {
- // Sync protected frontmatter fields (template, sidebar, etc.)
- const protectedResult = syncProtectedFrontmatterFields(content, englishMd)
- content = protectedResult.content
- if (protectedResult.fixCount > 0) {
- issues.push(
- `Synced ${protectedResult.fixCount} protected frontmatter fields from English`
- )
- }
-
- // Collapse inline HTML tags to match English single-line format
- const inlineHtmlResult = collapseInlineHtmlFromEnglish(content, englishMd)
- content = inlineHtmlResult.content
- if (inlineHtmlResult.fixCount > 0) {
- issues.push(
- `Collapsed ${inlineHtmlResult.fixCount} inline HTML tags to match English`
- )
- }
-
- // Fix JSX component closing tags merged with content (split to own line)
- const mergedTagResult = fixMergedClosingTags(content, englishMd)
- content = mergedTagResult.content
- if (mergedTagResult.fixCount > 0) {
- issues.push(
- `Split ${mergedTagResult.fixCount} merged closing tags to own lines`
- )
- }
-
- // Collapse inline component line breaks to match English format
- const inlineResult = normalizeInlineComponentsFromEnglish(
- content,
- englishMd
- )
- content = inlineResult.content
- if (inlineResult.fixCount > 0) {
- issues.push(
- `Normalized ${inlineResult.fixCount} inline components to match English`
- )
- }
-
- // Repair unclosed backticks in inline code
- const backtickResult = repairUnclosedBackticks(content, englishMd)
- content = backtickResult.content
- if (backtickResult.fixCount > 0) {
- issues.push(`Repaired ${backtickResult.fixCount} unclosed backticks`)
- }
-
- const blankLineResult = restoreBlankLinesFromEnglish(content, englishMd)
- content = blankLineResult.content
- if (blankLineResult.fixCount > 0) {
- issues.push(
- `Restored ${blankLineResult.fixCount} blank lines from English`
- )
- }
-
- // Fix collapsed line breaks between consecutive components
- const collapsedResult = fixCollapsedComponentLineBreaks(content, englishMd)
- content = collapsedResult.content
- if (collapsedResult.fixCount > 0) {
- issues.push(
- `Fixed ${collapsedResult.fixCount} collapsed component line breaks`
- )
- }
-
- // Check for mistranslated brand names (report-only)
- const brandWarnings = checkProtectedBrandNames(content, englishMd)
- issues.push(...brandWarnings)
-
- // Fix translated hrefs using set comparison
- const hrefResult = fixTranslatedHrefs(content, englishMd)
- content = hrefResult.content
- if (hrefResult.fixCount > 0) {
- issues.push(
- `Fixed ${hrefResult.fixCount} translated hrefs: ${hrefResult.fixes.join(", ")}`
- )
- }
- issues.push(...hrefResult.warnings)
- }
-
- const fixed = before !== content
- // Only write to disk if no content was provided (legacy mode)
- if (fixed && !providedContent) {
- fs.writeFileSync(mdPath, content, "utf8")
- }
- // Run critical checks (report-only)
- let m: RegExpExecArray | null
- // Broken links containing spaces inside URL
- while ((m = BROKEN_LINK_REGEX.exec(content))) {
- issues.push(`Broken link format at ${mdPath}:${lineAt(content, m.index)}`)
- }
- // Invalid links (exclude images/internal/hash/http/mailto/pdf/<...>)
- while ((m = INVALID_LINK_REGEX.exec(content))) {
- issues.push(`Invalid link at ${mdPath}:${lineAt(content, m.index)}`)
- }
- // Empty link text
- while ((m = LINK_TEXT_MISSING_REGEX.exec(content))) {
- issues.push(`Link text missing at ${mdPath}:${lineAt(content, m.index)}`)
- }
- // Incorrect image path in translated markdown
- if (mdPath.includes(`${path.sep}translations${path.sep}`)) {
- while ((m = INCORRECT_PATH_IN_TRANSLATED_MARKDOWN.exec(content))) {
- issues.push(
- `Incorrect image path at ${mdPath}:${lineAt(content, m.index)}`
- )
- }
- }
- // Spelling mistakes (case-insensitive)
- for (const mistake of COMMON_SPELLING_MISTAKES) {
- const re = new RegExp(mistake, "gi")
- while ((m = re.exec(content))) {
- issues.push(
- `Spelling mistake "${mistake}" at ${mdPath}:${lineAt(content, m.index)}`
- )
- }
- }
- // Case-sensitive mistakes for brands
- for (const mistake of CASE_SENSITIVE_SPELLING_MISTAKES) {
- const re = new RegExp(mistake, "g")
- while ((m = re.exec(content))) {
- issues.push(
- `Brand capitalization issue "${mistake}" at ${mdPath}:${lineAt(content, m.index)}`
- )
- }
- }
- return { fixed, issues, content }
-}
-
-function processJsonFile(
- jsonPath: string,
- providedContent?: string
-): {
- fixed: boolean
- issues: string[]
- content: string
-} {
- const issues: string[] = []
- let content = providedContent || fs.readFileSync(jsonPath, "utf8")
- const before = content
-
- // Normalize BOM and smart quotes
- content = content
- .replace(/^\uFEFF/, "")
- .replace(/[""]/g, '"')
- .replace(/['']/g, "'")
-
- // Try parsing to validate JSON
- try {
- JSON.parse(content)
- } catch (e) {
- const error = e as Error
- issues.push(`JSON parse error: ${error.message}`)
- }
-
- const fixed = before !== content
- // Only write to disk if no content was provided (legacy mode)
- if (fixed && !providedContent) {
- fs.writeFileSync(jsonPath, content, "utf8")
- }
-
- return { fixed, issues, content }
-}
-
-function languagesFromEnv(): string[] | undefined {
- const env = process.env.TARGET_LANGUAGES?.trim()
- if (!env) return undefined
- return env
- .split(",")
- .map((s) => s.trim())
- .filter(Boolean)
-}
-
-export function runSanitizer(
- filesWithContent?: Array<{ path: string; content: string }>,
- langs?: string[]
-) {
- console.log("[SANITIZE] Starting post-import sanitizer")
-
- let mdFilesToProcess: Array<{ path: string; content: string }> = []
- let jsonFilesToProcess: Array<{ path: string; content: string }> = []
-
- if (filesWithContent && filesWithContent.length > 0) {
- // Process only the specific files provided with their in-memory content
- console.log(
- `[SANITIZE] Target: ${filesWithContent.length} specific file(s)`
- )
- mdFilesToProcess = filesWithContent.filter((f) => f.path.endsWith(".md"))
- jsonFilesToProcess = filesWithContent.filter((f) =>
- f.path.endsWith(".json")
- )
- } else {
- // Fallback to language-based scanning (reads from disk)
- const effectiveLangs = langs || languagesFromEnv()
- console.log(
- "[SANITIZE] Target languages:",
- effectiveLangs ?? "ALL detected in translations/"
- )
- const mdFilePaths = listFiles(CONTENT_ROOT, (f) => {
- if (!f.endsWith(".md")) return false
- if (!f.includes(`${path.sep}translations${path.sep}`)) return false
- if (effectiveLangs)
- return effectiveLangs.some((l) =>
- f.includes(`${path.sep}translations${path.sep}${l}${path.sep}`)
- )
- return true
- })
- const jsonFilePaths = listFiles(CONTENT_ROOT, (f) => {
- if (!f.endsWith(".json")) return false
- if (!f.includes(`${path.sep}translations${path.sep}`)) return false
- if (effectiveLangs)
- return effectiveLangs.some((l) =>
- f.includes(`${path.sep}translations${path.sep}${l}${path.sep}`)
- )
- return true
- })
- // Convert file paths to objects without content (will be read from disk)
- mdFilesToProcess = mdFilePaths.map((p) => ({ path: p, content: "" }))
- jsonFilesToProcess = jsonFilePaths.map((p) => ({ path: p, content: "" }))
- }
-
- let mdFixed = 0
- const mdIssues: Array<{ file: string; issues: string[] }> = []
- const mdChanged: Array<{ path: string; content: string }> = []
-
- for (const fileInfo of mdFilesToProcess) {
- const { fixed, issues, content } = processMarkdownFile(
- fileInfo.path,
- fileInfo.content
- )
- if (fixed) {
- mdFixed++
- mdChanged.push({ path: fileInfo.path, content })
- }
- if (issues.length)
- mdIssues.push({ file: path.relative(ROOT, fileInfo.path), issues })
- }
-
- let jsonFixed = 0
- const jsonIssues: Array<{ file: string; issues: string[] }> = []
- const jsonChanged: Array<{ path: string; content: string }> = []
-
- for (const fileInfo of jsonFilesToProcess) {
- const { fixed, issues, content } = processJsonFile(
- fileInfo.path,
- fileInfo.content
- )
- if (fixed) {
- jsonFixed++
- jsonChanged.push({ path: fileInfo.path, content })
- }
- if (issues.length)
- jsonIssues.push({ file: path.relative(ROOT, fileInfo.path), issues })
- }
-
- console.log(
- `\n[SANITIZE] Markdown files scanned: ${mdFilesToProcess.length}, fixed: ${mdFixed}`
- )
- console.log(
- `[SANITIZE] JSON files scanned: ${jsonFilesToProcess.length}, fixed: ${jsonFixed}`
- )
-
- if (mdIssues.length || jsonIssues.length) {
- console.log("\n[SANITIZE] Issues detected:")
- for (const i of mdIssues) {
- console.log(` - MD ${i.file}`)
- for (const msg of i.issues) console.log(` • ${msg}`)
- }
- for (const i of jsonIssues) {
- console.log(` - JSON ${i.file}`)
- for (const msg of i.issues) console.log(` • ${msg}`)
- }
- } else {
- console.log("\n[SANITIZE] No issues detected.")
- }
-
- const changedFiles = [...mdChanged, ...jsonChanged].map((f) => ({
- path: f.path,
- content: f.content,
- }))
- return {
- changedFiles,
- markdown: { scanned: mdFilesToProcess.length, fixed: mdFixed },
- json: { scanned: jsonFilesToProcess.length, fixed: jsonFixed },
- issues: { markdown: mdIssues, json: jsonIssues },
- }
-}
-
-if (require.main === module) {
- runSanitizer()
-}
From 5398539d42fb4f3ff05ae1c79a5bea2ed2d8cfa5 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 17:22:27 +0000
Subject: [PATCH 5/7] fix(i18n): add missing post_import_sanitize module
---
src/scripts/i18n/post_import_sanitize.ts | 1437 ++++++++++++++++++++++
1 file changed, 1437 insertions(+)
create mode 100644 src/scripts/i18n/post_import_sanitize.ts
diff --git a/src/scripts/i18n/post_import_sanitize.ts b/src/scripts/i18n/post_import_sanitize.ts
new file mode 100644
index 00000000000..75456a69d94
--- /dev/null
+++ b/src/scripts/i18n/post_import_sanitize.ts
@@ -0,0 +1,1437 @@
+import * as fs from "fs"
+import * as path from "path"
+
+/**
+ * Post-import sanitizer for Crowdin translations.
+ *
+ * - Synchronize custom Markdown header IDs `{#...}` with English source (ASCII-only)
+ * - Normalize block HTML tag line breaks (opening and closing tags on their own lines)
+ * - Protect known brand/team names from inadvertent translation
+ * - Validate JSON files; report issues
+ *
+ * Usage:
+ * npx ts-node -O '{"module":"commonjs"}' ./src/scripts/i18n/post_import_sanitize.ts
+ *
+ * Env:
+ * TARGET_LANGUAGES (comma-separated, e.g. "es-EM") optional; defaults to scanning all `translations/*` folders
+ */
+
+const ROOT = process.cwd()
+const CONTENT_ROOT = path.join(ROOT, "public", "content")
+
+const BLOCK_HTML_TAGS = [
+ "section",
+ "div",
+ "article",
+ "aside",
+ "header",
+ "footer",
+]
+
+/**
+ * MDX block components that need opening/closing tags on separate lines.
+ * ButtonLink is intentionally excluded - it's an inline component.
+ */
+const BLOCK_MDX_COMPONENTS = [
+ "Card",
+ "ExpandableCard",
+ "Alert",
+ "AlertEmoji",
+ "AlertContent",
+ "AlertDescription",
+ "CardGrid",
+ "InfoGrid",
+ "InfoBanner",
+ "Tabs",
+ "TabItem",
+]
+
+function listFiles(
+ dir: string,
+ predicate: (file: string) => boolean
+): string[] {
+ const out: string[] = []
+ const stack: string[] = [dir]
+ while (stack.length) {
+ const d = stack.pop()!
+ const entries = fs.readdirSync(d, { withFileTypes: true })
+ for (const e of entries) {
+ const full = path.join(d, e.name)
+ if (e.isDirectory()) stack.push(full)
+ else if (predicate(full)) out.push(full)
+ }
+ }
+ return out
+}
+
+function toAsciiId(id: string): string {
+ // keep only ASCII letters, numbers, hyphens and underscores; strip accents
+ const normalized = id.normalize("NFD").replace(/[\u0300-\u036f]/g, "")
+ return normalized.replace(/[^A-Za-z0-9_-]/g, "-")
+}
+
+// Critical regex checks adapted from legacy markdownChecker
+const BROKEN_LINK_REGEX = /\[[^\]]+\]\([^)\s]+\s[^)]+\)/g
+const INVALID_LINK_REGEX =
+ /(? 0) {
+ // Brand is in English, check if it's preserved in translation
+ const inTranslation = translatedContent.match(brandRegex)
+ const englishCount = inEnglish.length
+ const translationCount = inTranslation?.length ?? 0
+
+ if (translationCount < englishCount) {
+ warnings.push(
+ `Protected brand "${brand}" appears ${englishCount}x in English but ${translationCount}x in translation - may have been mistranslated`
+ )
+ }
+ }
+ }
+
+ return warnings
+}
+
+/**
+ * Fix duplicated headings where the text is repeated.
+ * Pattern: ## Text? Text? {#id} → ## Text? {#id}
+ * This happens when translators accidentally duplicate question headings.
+ */
+function fixDuplicatedHeadings(content: string): {
+ content: string
+ fixCount: number
+} {
+ let result = content
+ let fixCount = 0
+
+ // Match headings where text is duplicated: ## Text Text {#id} or ## Text? Text? {#id}
+ // Captures: (hashes) (text including punctuation) (same text) (custom id)
+ const duplicatedHeadingRe =
+ /^(#{1,6})\s+(.+?[?!.]?)\s+\2\s*(\{#[^}]+\})\s*$/gm
+
+ result = result.replace(duplicatedHeadingRe, (_, hashes, text, id) => {
+ fixCount++
+ return `${hashes} ${text} ${id}`
+ })
+
+ return { content: result, fixCount }
+}
+
+/**
+ * Fix broken markdown links where there's a space between ] and (.
+ * Pattern: ] (https://... → ](https://...
+ * This is a common translation artifact from Crowdin.
+ */
+function fixBrokenMarkdownLinks(content: string): {
+ content: string
+ fixCount: number
+} {
+ let fixCount = 0
+
+ // Match ] followed by space(s) then ( - this breaks markdown links
+ const result = content.replace(/\]\s+\(/g, () => {
+ fixCount++
+ return "]("
+ })
+
+ return { content: result, fixCount }
+}
+
+/**
+ * Fix collapsed line breaks between consecutive MDX components.
+ * Pattern: → \n
+ * This happens when translators collapse multiple components onto one line.
+ */
+function fixCollapsedComponentLineBreaks(
+ translatedContent: string,
+ englishContent: string
+): { content: string; fixCount: number } {
+ let result = translatedContent
+ let fixCount = 0
+
+ // Find components that appear consecutively in English (on separate lines)
+ // and restore line breaks in translation if they were collapsed
+ const consecutiveComponentRe =
+ /<\/([A-Z][A-Za-z]*)[^>]*>\s*<([A-Z][A-Za-z]*)/g
+
+ // Check English for line break patterns between components
+ const englishMatches = [...englishContent.matchAll(consecutiveComponentRe)]
+ for (const match of englishMatches) {
+ const fullMatch = match[0]
+ // If English has a newline between these components
+ if (fullMatch.includes("\n")) {
+ // Find same pattern in translation (possibly without newline)
+ const closingTag = match[1]
+ const openingTag = match[2]
+ const collapsedRe = new RegExp(
+ `${closingTag}>[ \\t]+<${openingTag}`,
+ "g"
+ )
+ const collapsedMatches = result.match(collapsedRe)
+ if (collapsedMatches) {
+ fixCount += collapsedMatches.length
+ result = result.replace(collapsedRe, `${closingTag}>\n<${openingTag}`)
+ }
+ }
+ }
+
+ return { content: result, fixCount }
+}
+
+/**
+ * Extract all href values from content (both markdown links and JSX/HTML attributes).
+ */
+function extractHrefs(content: string): Set {
+ const hrefs = new Set()
+
+ // Markdown links: [text](href)
+ const markdownLinkRe = /\[[^\]]*\]\(([^)]+)\)/g
+ let match
+ while ((match = markdownLinkRe.exec(content))) {
+ hrefs.add(match[1])
+ }
+
+ // JSX/HTML href attributes: href="..." or href='...'
+ const hrefAttrRe = /href=["']([^"']+)["']/g
+ while ((match = hrefAttrRe.exec(content))) {
+ hrefs.add(match[1])
+ }
+
+ return hrefs
+}
+
+/**
+ * Extract hrefs from a single text block (paragraph/section).
+ * Returns array to preserve duplicates within the block.
+ */
+function extractHrefsFromBlock(block: string): string[] {
+ const hrefs: string[] = []
+
+ // Markdown links: [text](href)
+ const markdownLinkRe = /\[[^\]]*\]\(([^)]+)\)/g
+ let match
+ while ((match = markdownLinkRe.exec(block))) {
+ hrefs.push(match[1])
+ }
+
+ // JSX/HTML href attributes: href="..." or href='...'
+ const hrefAttrRe = /href=["']([^"']+)["']/g
+ while ((match = hrefAttrRe.exec(block))) {
+ hrefs.push(match[1])
+ }
+
+ return hrefs
+}
+
+/**
+ * Split markdown content into logical blocks (paragraphs/sections).
+ * Blocks are separated by blank lines.
+ */
+function splitIntoBlocks(content: string): string[] {
+ // Split on one or more blank lines
+ return content.split(/\n\s*\n/).filter((block) => block.trim().length > 0)
+}
+
+/**
+ * Fix translated hrefs by comparing against English source.
+ * Uses paragraph-scoped set comparison for robust matching across languages.
+ *
+ * Strategy:
+ * 1. Split both documents into blocks (paragraphs separated by blank lines)
+ * 2. For each block pair, compare internal href sets
+ * 3. Within a block: if invalid href count equals missing href count, we can match
+ * 4. This handles grammatical reordering within sentences (common in non-English)
+ *
+ * Only auto-fixes unambiguous cases; warns for complex mismatches.
+ */
+function fixTranslatedHrefs(
+ translatedContent: string,
+ englishContent: string
+): { content: string; fixCount: number; fixes: string[]; warnings: string[] } {
+ const englishBlocks = splitIntoBlocks(englishContent)
+ const translatedBlocks = splitIntoBlocks(translatedContent)
+
+ // Collect all English internal hrefs as the "valid" set
+ const allEnglishHrefs = extractHrefs(englishContent)
+
+ const allFixes: Array<[string, string]> = [] // [wrong, correct]
+ const allWarnings: string[] = []
+
+ // Process block by block
+ const blockCount = Math.min(englishBlocks.length, translatedBlocks.length)
+
+ for (let i = 0; i < blockCount; i++) {
+ const engBlock = englishBlocks[i]
+ const transBlock = translatedBlocks[i]
+
+ const engHrefs = extractHrefsFromBlock(engBlock).filter(isInternalHref)
+ const transHrefs = extractHrefsFromBlock(transBlock).filter(isInternalHref)
+
+ // Skip blocks with no internal hrefs
+ if (engHrefs.length === 0 && transHrefs.length === 0) continue
+
+ // Find hrefs in translation that don't exist in English (invalid)
+ const transHrefSet = new Set(transHrefs)
+
+ const invalidInTrans: string[] = [] // In translation but not in any English href
+ const missingFromTrans: string[] = [] // In English block but not in translation
+
+ for (const href of transHrefs) {
+ if (!allEnglishHrefs.has(href)) {
+ invalidInTrans.push(href)
+ }
+ }
+
+ for (const href of engHrefs) {
+ if (!transHrefSet.has(href)) {
+ missingFromTrans.push(href)
+ }
+ }
+
+ // No issues in this block
+ if (invalidInTrans.length === 0 && missingFromTrans.length === 0) continue
+
+ // Deduplicate for set comparison
+ const uniqueInvalid = [...new Set(invalidInTrans)]
+ const uniqueMissing = [...new Set(missingFromTrans)]
+
+ // Only auto-fix when there's exactly 1 invalid and 1 missing in block
+ // Multiple mismatches within same block could be reordered - don't guess
+ if (uniqueInvalid.length === 1 && uniqueMissing.length === 1) {
+ allFixes.push([uniqueInvalid[0], uniqueMissing[0]])
+ } else if (uniqueInvalid.length > 0 || uniqueMissing.length > 0) {
+ // Count mismatch - can't safely fix, warn instead
+ for (const href of uniqueInvalid) {
+ allWarnings.push(
+ `Block ${i + 1}: Invalid href "${href}" - not a valid English path`
+ )
+ }
+ for (const href of uniqueMissing) {
+ allWarnings.push(
+ `Block ${i + 1}: Missing href "${href}" - present in English but not translation`
+ )
+ }
+ }
+ }
+
+ // Warn about block count mismatch
+ if (englishBlocks.length !== translatedBlocks.length) {
+ allWarnings.push(
+ `Block count mismatch: English has ${englishBlocks.length}, translation has ${translatedBlocks.length}`
+ )
+ }
+
+ // Apply all fixes
+ let result = translatedContent
+ const appliedFixes: string[] = []
+
+ for (const [wrong, correct] of allFixes) {
+ // Replace in markdown links: [text](wrong) → [text](correct)
+ const markdownRe = new RegExp(
+ `(\\[[^\\]]*\\]\\()${escapeRegex(wrong)}(\\))`,
+ "g"
+ )
+ const beforeMd = result
+ result = result.replace(markdownRe, `$1${correct}$2`)
+
+ // Replace in href attributes: href="wrong" → href="correct"
+ const hrefRe = new RegExp(`(href=["'])${escapeRegex(wrong)}(["'])`, "g")
+ const beforeAttr = result
+ result = result.replace(hrefRe, `$1${correct}$2`)
+
+ if (result !== beforeMd || result !== beforeAttr) {
+ appliedFixes.push(`${wrong} → ${correct}`)
+ }
+ }
+
+ return {
+ content: result,
+ fixCount: appliedFixes.length,
+ fixes: appliedFixes,
+ warnings: allWarnings,
+ }
+}
+
+/**
+ * Escape special regex characters in a string.
+ */
+function escapeRegex(str: string): string {
+ return str.replace(/[.*+?^${}()|[\]\\]/g, "\\$&")
+}
+
+/**
+ * Check if href is an internal link (starts with / but not //).
+ */
+function isInternalHref(href: string): boolean {
+ return href.startsWith("/") && !href.startsWith("//")
+}
+
+function lineAt(file: string, index: number): string {
+ const fileSubstring = file.substring(0, index)
+ const lines = fileSubstring.split("\n")
+ const linePosition = lines.length
+ const charPosition = lines[lines.length - 1].length + 1
+ const lineNumber = `${linePosition}:${charPosition}`
+ return lineNumber
+}
+interface HeaderInfo {
+ level: number // Number of # symbols
+ text: string // Header text (translated or English)
+ id: string // Custom ID from {#id}
+ fullMatch: string // Full matched string for replacement
+}
+
+function extractHeaderStructure(md: string): HeaderInfo[] {
+ const headers: HeaderInfo[] = []
+ const headingRe = /^(#{1,6})\s+(.+?)\s*\{#([^}]+)\}\s*$/gm
+ let m: RegExpExecArray | null
+ while ((m = headingRe.exec(md))) {
+ headers.push({
+ level: m[1].length,
+ text: m[2].trim(),
+ id: m[3].trim(),
+ fullMatch: m[0],
+ })
+ }
+ return headers
+}
+
+function syncHeaderIdsWithEnglish(
+ translatedMd: string,
+ englishMd: string
+): string {
+ // Extract header structure from both files
+ const englishHeaders = extractHeaderStructure(englishMd)
+ const translatedHeaders = extractHeaderStructure(translatedMd)
+
+ // Match headers by position and level in the document structure
+ // If structure matches, copy English IDs to translated headers
+ if (englishHeaders.length !== translatedHeaders.length) {
+ console.warn(
+ `[WARN] Header count mismatch: English has ${englishHeaders.length}, translated has ${translatedHeaders.length}`
+ )
+ }
+
+ let result = translatedMd
+ // Match headers by index - same position = same semantic header
+ for (let i = 0; i < translatedHeaders.length; i++) {
+ const translatedHeader = translatedHeaders[i]
+ const englishHeader = englishHeaders[i]
+
+ if (!englishHeader) {
+ // More headers in translation than English - skip
+ continue
+ }
+
+ if (translatedHeader.level !== englishHeader.level) {
+ console.warn(
+ `[WARN] Header level mismatch at position ${i}: English H${englishHeader.level} vs translated H${translatedHeader.level}`
+ )
+ // Still try to sync the ID even if levels don't match
+ }
+
+ // Replace the translated header's ID with the English ID (ASCII-normalized)
+ const asciiId = toAsciiId(englishHeader.id)
+ const updatedHeader = `${"#".repeat(translatedHeader.level)} ${translatedHeader.text} {#${asciiId}}`
+
+ // Use a more specific replacement to avoid affecting other occurrences
+ result = result.replace(translatedHeader.fullMatch, updatedHeader)
+ }
+
+ return result
+}
+
+function normalizeBlockHtmlLines(md: string): string {
+ for (const tag of BLOCK_HTML_TAGS) {
+ const inlineCloseRe = new RegExp(`([^\\n])\\s*${tag}>`, "g")
+ md = md.replace(inlineCloseRe, (_, before) => `${before}\n${tag}>`)
+ }
+ return md
+}
+
+/**
+ * Restore blank lines after headers and block components by comparing
+ * with English source structure. This preserves readability and formatting.
+ */
+function restoreBlankLinesFromEnglish(
+ translatedMd: string,
+ englishMd: string
+): { content: string; fixCount: number } {
+ const translatedLines = translatedMd.split("\n")
+ const englishLines = englishMd.split("\n")
+
+ let fixCount = 0
+ const result: string[] = []
+
+ // Patterns that should have blank lines after them
+ const headerPattern = /^#{1,6}\s+/
+ const blockComponentClosePattern = new RegExp(
+ `(${BLOCK_MDX_COMPONENTS.join("|")})>`
+ )
+
+ for (let i = 0; i < translatedLines.length; i++) {
+ const line = translatedLines[i]
+ result.push(line)
+
+ // Check if this line should be followed by a blank line
+ const isHeader = headerPattern.test(line)
+ const isBlockClose = blockComponentClosePattern.test(line)
+
+ if (isHeader || isBlockClose) {
+ const nextLine = translatedLines[i + 1]
+ const hasBlankAfter = nextLine === ""
+
+ // Find corresponding line in English by matching pattern
+ let englishShouldHaveBlank = false
+ for (let j = 0; j < englishLines.length; j++) {
+ const englishLine = englishLines[j]
+ if (isHeader && headerPattern.test(englishLine)) {
+ // Headers should match by structure (level)
+ const transLevel = (line.match(/^#+/) || [""])[0].length
+ const engLevel = (englishLine.match(/^#+/) || [""])[0].length
+ if (transLevel === engLevel) {
+ englishShouldHaveBlank = englishLines[j + 1] === ""
+ break
+ }
+ } else if (
+ isBlockClose &&
+ blockComponentClosePattern.test(englishLine)
+ ) {
+ englishShouldHaveBlank = englishLines[j + 1] === ""
+ break
+ }
+ }
+
+ // Add blank line if English has it but translation doesn't
+ if (englishShouldHaveBlank && !hasBlankAfter && nextLine !== undefined) {
+ result.push("")
+ fixCount++
+ }
+ }
+ }
+
+ return { content: result.join("\n"), fixCount }
+}
+
+/**
+ * Normalize inline component formatting to match English source.
+ * If English has the component on one line, collapse translated version too.
+ * This prevents MDX from wrapping multi-line content in tags.
+ */
+function normalizeInlineComponentsFromEnglish(
+ translatedMd: string,
+ englishMd: string
+): {
+ content: string
+ fixCount: number
+} {
+ const inlineComponents = ["ButtonLink"]
+
+ let content = translatedMd
+ let fixCount = 0
+
+ for (const component of inlineComponents) {
+ // Extract English instances and check if they're single-line
+ // Key by href attribute since that's preserved in translation
+ const englishRe = new RegExp(
+ `<${component}[^>]*href="([^"]*)"[^>]*>([\\s\\S]*?)${component}>`,
+ "g"
+ )
+ const englishFormats = new Map() // href -> isOneLine
+
+ let match
+ while ((match = englishRe.exec(englishMd))) {
+ const href = match[1]
+ const innerContent = match[2]
+ const isOneLine = !innerContent.includes("\n")
+ englishFormats.set(href, isOneLine)
+ }
+
+ // For each translated instance, mirror English format
+ const translatedRe = new RegExp(
+ `(<${component}[^>]*href="([^"]*)"[^>]*>)([\\s\\S]*?)(${component}>)`,
+ "g"
+ )
+ content = content.replace(
+ translatedRe,
+ (fullMatch, openTag, href, innerContent, closeTag) => {
+ const englishIsOneLine = englishFormats.get(href)
+ const translatedHasLineBreaks = innerContent.includes("\n")
+
+ // If English is single-line but translated has line breaks, collapse it
+ if (englishIsOneLine && translatedHasLineBreaks) {
+ fixCount++
+ return `${openTag}${innerContent.trim()}${closeTag}`
+ }
+ return fullMatch
+ }
+ )
+ }
+
+ return { content, fixCount }
+}
+
+function fixBlockComponentLineBreaks(md: string): {
+ content: string
+ fixCount: number
+} {
+ let content = md
+ let fixCount = 0
+
+ for (const component of BLOCK_MDX_COMPONENTS) {
+ // Fix inline closing tags: content
→ content\n
+ const inlineCloseRe = new RegExp(`([^\\n])\\s*${component}>`, "g")
+ content = content.replace(inlineCloseRe, (_, before) => {
+ fixCount++
+ return `${before}\n${component}>`
+ })
+
+ // Fix inline opening tags: content → \ncontent
+ // Match any non-newline character after the tag (including other tags)
+ const inlineOpenRe = new RegExp(`(<${component}[^>]*>)([^\\n])`, "g")
+ content = content.replace(inlineOpenRe, (_, tag, after) => {
+ fixCount++
+ return `${tag}\n${after}`
+ })
+ }
+
+ return { content, fixCount }
+}
+
+/**
+ * Collapse inline HTML tags to single line when English source has them on one line.
+ * Fixes MDX paragraph wrapping issues: content\n
→ content
+ */
+function collapseInlineHtmlFromEnglish(
+ translatedMd: string,
+ englishMd: string
+): { content: string; fixCount: number } {
+ const inlineTags = ["div", "span", "p", "strong", "em"]
+ let content = translatedMd
+ let fixCount = 0
+
+ // Build a set of lines in English where tag opens and closes on same line
+ const englishLines = englishMd.split("\n")
+
+ for (const tag of inlineTags) {
+ // Find English lines that have ... all on one line
+ // (content can include nested tags like ,
, etc.)
+ const singleLinePattern = new RegExp(`<${tag}[^>]*>.*${tag}>`)
+ const englishSingleLineSet = new Set()
+
+ for (const line of englishLines) {
+ if (singleLinePattern.test(line)) {
+ // Extract just the opening tag to use as a key
+ const openTagMatch = line.match(new RegExp(`<${tag}[^>]*>`))
+ if (openTagMatch) {
+ englishSingleLineSet.add(openTagMatch[0])
+ }
+ }
+ }
+
+ // In translated content, find cases where:
+ // - Opening tag + content is on one line (content may include nested tags)
+ // - Newline follows
+ // - Closing tag is on the next line (possibly with leading whitespace)
+ // Pattern: content-with-possible-nested-tags\n
+ const translatedMultiLineRe = new RegExp(
+ `(<${tag}[^>]*>)([^\\n]+)\\n(\\s*${tag}>)`,
+ "g"
+ )
+
+ content = content.replace(
+ translatedMultiLineRe,
+ (fullMatch, openTag, innerContent, closeTagLine) => {
+ // Check if this opening tag should be single-line per English
+ if (englishSingleLineSet.has(openTag)) {
+ fixCount++
+ // Collapse: opening tag + trimmed content + closing tag (no newline)
+ return `${openTag}${innerContent.trim()}${closeTagLine.trim()}`
+ }
+ return fullMatch
+ }
+ )
+ }
+
+ return { content, fixCount }
+}
+
+/**
+ * Fix JSX component closing tags that are merged with content.
+ * English format:
+ *
+ * Content
+ *
+ * Spanish (broken):
+ *
+ * Content
+ * This function splits the closing tag to its own line when English has it that way.
+ */
+function fixMergedClosingTags(
+ translatedMd: string,
+ englishMd: string
+): { content: string; fixCount: number } {
+ const componentTags = ["ButtonLink", "Link"]
+ let content = translatedMd
+ let fixCount = 0
+
+ for (const tag of componentTags) {
+ // Find patterns in English where the closing tag is on its own line
+ // Pattern: \n content\n or \n content\n
+ const englishMultiLineRe = new RegExp(
+ `<${tag}[^>]*>\\n[\\s\\S]*?\\n\\s*${tag}>`,
+ "g"
+ )
+
+ // Check if English uses multi-line format for this component
+ if (!englishMultiLineRe.test(englishMd)) continue
+
+ // In translated content, find cases where closing tag is merged with content on same line
+ // Pattern: \n content (content and closing tag on same line)
+ const mergedPattern = new RegExp(
+ `(<${tag}[^>]*>\\n)(\\s*)([^\\n]+)(${tag}>)`,
+ "g"
+ )
+
+ content = content.replace(
+ mergedPattern,
+ (match, openTagLine, indent, innerContent, closeTag) => {
+ // Only fix if the inner content doesn't end with just whitespace
+ // and the closing tag is directly after content (not on its own line)
+ const trimmedContent = innerContent.trimEnd()
+ if (trimmedContent.length > 0 && !innerContent.includes("\n")) {
+ fixCount++
+ // Split: put closing tag on its own line with same indentation
+ return `${openTagLine}${indent}${trimmedContent}\n${indent}${closeTag}`
+ }
+ return match
+ }
+ )
+ }
+
+ return { content, fixCount }
+}
+
+/**
+ * Repair unclosed backticks by comparing with English source.
+ * Detects lines with odd backtick counts containing < and attempts repair.
+ */
+function repairUnclosedBackticks(
+ translatedMd: string,
+ englishMd: string
+): { content: string; fixCount: number } {
+ const translatedLines = translatedMd.split("\n")
+ const englishLines = englishMd.split("\n")
+ let fixCount = 0
+
+ for (let i = 0; i < translatedLines.length; i++) {
+ const line = translatedLines[i]
+ const backtickCount = (line.match(/`/g) || []).length
+
+ // Odd number of backticks and contains < means potentially unclosed code with HTML-like content
+ if (
+ backtickCount % 2 === 1 &&
+ line.includes("<") &&
+ !line.includes("```")
+ ) {
+ // Try to find a matching English line with similar structure
+ for (const engLine of englishLines) {
+ // Look for English lines with balanced backticks containing similar patterns
+ const engBackticks = (engLine.match(/`/g) || []).length
+ if (
+ engBackticks % 2 === 0 &&
+ engBackticks > 0 &&
+ engLine.includes("<")
+ ) {
+ // Extract inline code blocks from English
+ const codeBlockRe = /`([^`]+)`/g
+ let engMatch
+ while ((engMatch = codeBlockRe.exec(engLine))) {
+ const engCode = engMatch[1]
+ // Check if the translated line contains this code pattern without closing backtick
+ const unbalancedPattern = new RegExp(
+ "`" +
+ engCode
+ .replace(/[.*+?^${}()|[\]\\]/g, "\\$&")
+ .replace(/\s+/g, "\\s*")
+ )
+ if (
+ unbalancedPattern.test(line) &&
+ !line.includes("`" + engCode + "`")
+ ) {
+ // Found a match - add the missing closing backtick
+ translatedLines[i] = line.replace(
+ new RegExp(
+ "`" +
+ engCode
+ .replace(/[.*+?^${}()|[\]\\]/g, "\\$&")
+ .replace(/\s+/g, "\\s*")
+ ),
+ "`" + engCode + "`"
+ )
+ fixCount++
+ break
+ }
+ }
+ if (fixCount > 0) break
+ }
+ }
+ }
+ }
+
+ return { content: translatedLines.join("\n"), fixCount }
+}
+
+/**
+ * Normalize frontmatter dates from localized format (DD-MM-YYYY) back to ISO (YYYY-MM-DD).
+ */
+function normalizeFrontmatterDates(content: string): {
+ content: string
+ fixCount: number
+} {
+ let fixCount = 0
+
+ // Match frontmatter block
+ const frontmatterRe = /^---\n([\s\S]*?)\n---/
+ const match = content.match(frontmatterRe)
+ if (!match) return { content, fixCount }
+
+ let frontmatter = match[1]
+ const originalFrontmatter = frontmatter
+
+ // Fix published: dates in DD-MM-YYYY or DD/MM/YYYY format
+ frontmatter = frontmatter.replace(
+ /^(published:\s*)(\d{1,2})[-/](\d{1,2})[-/](\d{4})$/gm,
+ (_, prefix, day, month, year) => {
+ fixCount++
+ // Pad day and month with leading zeros if needed
+ const paddedDay = day.padStart(2, "0")
+ const paddedMonth = month.padStart(2, "0")
+ return `${prefix}${year}-${paddedMonth}-${paddedDay}`
+ }
+ )
+
+ if (frontmatter !== originalFrontmatter) {
+ content = content.replace(frontmatterRe, `---\n${frontmatter}\n---`)
+ }
+
+ return { content, fixCount }
+}
+
+/**
+ * Sync protected frontmatter fields from English source.
+ * These fields should never be translated (e.g., template, sidebar).
+ */
+function syncProtectedFrontmatterFields(
+ translatedMd: string,
+ englishMd: string
+): { content: string; fixCount: number } {
+ // Fields that should never be translated - sync from English canonical
+ // Note: 'buttons' array needs special handling (content translatable, toId/isSecondary not)
+ // Note: 'lang' must NOT be protected - it must remain as target language code
+ const protectedFields = [
+ "template",
+ "sidebar",
+ "sidebarDepth",
+ "published",
+ "author",
+ "source",
+ "sourceUrl",
+ "address",
+ "emoji",
+ "skill",
+ "isOutdated",
+ "incomplete",
+ "hideEditButton",
+ "showDropdown",
+ "image",
+ "blurDataURL",
+ ]
+ let fixCount = 0
+
+ // Extract frontmatter from both
+ const frontmatterRe = /^---\n([\s\S]*?)\n---/
+ const transMatch = translatedMd.match(frontmatterRe)
+ const engMatch = englishMd.match(frontmatterRe)
+
+ if (!transMatch || !engMatch) return { content: translatedMd, fixCount }
+
+ let transFrontmatter = transMatch[1]
+ const engFrontmatter = engMatch[1]
+
+ for (const field of protectedFields) {
+ // Get English value
+ const engFieldRe = new RegExp(`^${field}:\\s*(.+)$`, "m")
+ const engFieldMatch = engFrontmatter.match(engFieldRe)
+ if (!engFieldMatch) continue
+
+ const englishValue = engFieldMatch[1].trim()
+
+ // Check if translated value differs
+ const transFieldRe = new RegExp(`^${field}:\\s*(.+)$`, "m")
+ const transFieldMatch = transFrontmatter.match(transFieldRe)
+
+ if (transFieldMatch) {
+ const translatedValue = transFieldMatch[1].trim()
+ // Remove quotes for comparison
+ const cleanTranslated = translatedValue.replace(/^["']|["']$/g, "")
+ const cleanEnglish = englishValue.replace(/^["']|["']$/g, "")
+
+ if (cleanTranslated !== cleanEnglish) {
+ // Replace with English value
+ transFrontmatter = transFrontmatter.replace(
+ transFieldRe,
+ `${field}: ${englishValue}`
+ )
+ fixCount++
+ }
+ }
+ }
+
+ if (fixCount > 0) {
+ return {
+ content: translatedMd.replace(
+ frontmatterRe,
+ `---\n${transFrontmatter}\n---`
+ ),
+ fixCount,
+ }
+ }
+
+ return { content: translatedMd, fixCount }
+}
+
+/**
+ * Fix ASCII guillemets (<< and >>) to proper Unicode guillemets (« and »).
+ * Prevents MDX parsing errors from malformed angle bracket sequences.
+ * IMPORTANT: Skips code blocks where << and >> are valid bit-shift operators.
+ */
+function fixAsciiGuillemets(content: string): {
+ content: string
+ fixCount: number
+} {
+ let fixCount = 0
+
+ // Split content to preserve code blocks (both fenced and inline)
+ // Fenced: ```...``` or ~~~...~~~
+ // Inline: `...`
+ const codeBlockPattern = /(```[\s\S]*?```|~~~[\s\S]*?~~~|`[^`]+`)/g
+ const parts = content.split(codeBlockPattern)
+
+ for (let i = 0; i < parts.length; i++) {
+ // Skip code blocks (odd indices after split with capturing group)
+ if (i % 2 === 1) continue
+
+ // Count and replace in non-code parts only
+ const leftMatches = parts[i].match(/<>/g)
+
+ if (leftMatches) {
+ fixCount += leftMatches.length
+ parts[i] = parts[i].replace(/<>/g, "»")
+ }
+ }
+
+ return { content: parts.join(""), fixCount }
+}
+
+/**
+ * Wrap frontmatter string values containing non-ASCII characters in double quotes.
+ * Prevents YAML parsing issues with accented characters.
+ */
+function quoteFrontmatterNonAscii(content: string): {
+ content: string
+ fixCount: number
+} {
+ let fixCount = 0
+
+ // Match frontmatter block
+ const frontmatterRe = /^---\n([\s\S]*?)\n---/
+ const match = content.match(frontmatterRe)
+ if (!match) return { content, fixCount }
+
+ let frontmatter = match[1]
+ const originalFrontmatter = frontmatter
+
+ // Find lines with unquoted values containing non-ASCII
+ const lines = frontmatter.split("\n")
+ for (let i = 0; i < lines.length; i++) {
+ const line = lines[i]
+ // Match key: value pattern
+ const keyValueRe = /^(\s*\w+:\s*)(.+)$/
+ const kvMatch = line.match(keyValueRe)
+ if (kvMatch) {
+ const [, prefix, value] = kvMatch
+ const trimmedValue = value.trim()
+
+ // Skip if already quoted (starts and ends with matching quotes)
+ if (
+ (trimmedValue.startsWith('"') && trimmedValue.endsWith('"')) ||
+ (trimmedValue.startsWith("'") && trimmedValue.endsWith("'"))
+ ) {
+ continue
+ }
+
+ // Skip YAML arrays - they handle their own internal quoting
+ // Inline arrays: tags: [ "value1", "value2" ]
+ if (trimmedValue.startsWith("[") && trimmedValue.endsWith("]")) {
+ continue
+ }
+ // Multi-line array items with - prefix won't match our key:value regex,
+ // but check explicitly for robustness (e.g., `key: - value` edge case)
+ if (trimmedValue.startsWith("-")) {
+ continue
+ }
+
+ // Check if value contains non-ASCII characters
+ // eslint-disable-next-line no-control-regex
+ if (/[^\x00-\x7F]/.test(value)) {
+ // Escape any existing double quotes in the value
+ const escapedValue = trimmedValue.replace(/"/g, '\\"')
+ lines[i] = `${prefix}"${escapedValue}"`
+ fixCount++
+ }
+ }
+ }
+
+ frontmatter = lines.join("\n")
+ if (frontmatter !== originalFrontmatter) {
+ content = content.replace(frontmatterRe, `---\n${frontmatter}\n---`)
+ }
+
+ return { content, fixCount }
+}
+
+function processMarkdownFile(
+ mdPath: string,
+ providedContent?: string
+): {
+ fixed: boolean
+ issues: string[]
+ content: string
+} {
+ const issues: string[] = []
+ let content = providedContent || fs.readFileSync(mdPath, "utf8")
+
+ let englishMd: string | undefined
+
+ // Map translated path to English path: remove `/translations//` segment
+ const parts = mdPath.split(path.sep)
+ const idx = parts.lastIndexOf("translations")
+ if (idx === -1 || idx + 2 >= parts.length) {
+ issues.push("No translations segment found; skipping formatting sync")
+ } else {
+ // Use path.resolve to preserve absolute paths (path.join loses leading /)
+ const englishPath = path.resolve(
+ path.sep,
+ ...parts.slice(0, idx),
+ ...parts.slice(idx + 2) // drop translations/
+ )
+ if (fs.existsSync(englishPath)) {
+ englishMd = fs.readFileSync(englishPath, "utf8")
+ content = syncHeaderIdsWithEnglish(content, englishMd)
+ } else {
+ issues.push(`English source missing: ${path.relative(ROOT, englishPath)}`)
+ }
+ }
+
+ const before = content
+
+ // Fix duplicated headings (e.g., ## Text? Text? {#id} → ## Text? {#id})
+ const duplicatedResult = fixDuplicatedHeadings(content)
+ content = duplicatedResult.content
+ if (duplicatedResult.fixCount > 0) {
+ issues.push(`Fixed ${duplicatedResult.fixCount} duplicated headings`)
+ }
+
+ // Fix broken markdown links (] (https:// → ](https://)
+ const brokenLinksResult = fixBrokenMarkdownLinks(content)
+ content = brokenLinksResult.content
+ if (brokenLinksResult.fixCount > 0) {
+ issues.push(`Fixed ${brokenLinksResult.fixCount} broken markdown links`)
+ }
+
+ // Fix frontmatter issues (don't need English source)
+ const dateResult = normalizeFrontmatterDates(content)
+ content = dateResult.content
+ if (dateResult.fixCount > 0) {
+ issues.push(
+ `Normalized ${dateResult.fixCount} frontmatter dates to ISO format`
+ )
+ }
+
+ const quoteResult = quoteFrontmatterNonAscii(content)
+ content = quoteResult.content
+ if (quoteResult.fixCount > 0) {
+ issues.push(
+ `Quoted ${quoteResult.fixCount} frontmatter values with non-ASCII chars`
+ )
+ }
+
+ const guillemetResult = fixAsciiGuillemets(content)
+ content = guillemetResult.content
+ if (guillemetResult.fixCount > 0) {
+ issues.push(
+ `Fixed ${guillemetResult.fixCount} ASCII guillemets (<< >>) to Unicode (« »)`
+ )
+ }
+
+ // Fix escaped backticks (\`) to regular backticks (`)
+ // Crowdin sometimes escapes backticks unnecessarily
+ const escapedBacktickCount = (content.match(/\\`/g) || []).length
+ if (escapedBacktickCount > 0) {
+ content = content.replace(/\\`/g, "`")
+ issues.push(`Unescaped ${escapedBacktickCount} backslash-escaped backticks`)
+ }
+
+ // Fix block component line breaks (critical for MDX parser)
+ const blockResult = fixBlockComponentLineBreaks(content)
+ content = blockResult.content
+ if (blockResult.fixCount > 0) {
+ issues.push(`Fixed ${blockResult.fixCount} inline block component tags`)
+ }
+
+ content = normalizeBlockHtmlLines(content)
+
+ // Normalize inline components and restore blank lines from English source
+ if (englishMd) {
+ // Sync protected frontmatter fields (template, sidebar, etc.)
+ const protectedResult = syncProtectedFrontmatterFields(content, englishMd)
+ content = protectedResult.content
+ if (protectedResult.fixCount > 0) {
+ issues.push(
+ `Synced ${protectedResult.fixCount} protected frontmatter fields from English`
+ )
+ }
+
+ // Collapse inline HTML tags to match English single-line format
+ const inlineHtmlResult = collapseInlineHtmlFromEnglish(content, englishMd)
+ content = inlineHtmlResult.content
+ if (inlineHtmlResult.fixCount > 0) {
+ issues.push(
+ `Collapsed ${inlineHtmlResult.fixCount} inline HTML tags to match English`
+ )
+ }
+
+ // Fix JSX component closing tags merged with content (split to own line)
+ const mergedTagResult = fixMergedClosingTags(content, englishMd)
+ content = mergedTagResult.content
+ if (mergedTagResult.fixCount > 0) {
+ issues.push(
+ `Split ${mergedTagResult.fixCount} merged closing tags to own lines`
+ )
+ }
+
+ // Collapse inline component line breaks to match English format
+ const inlineResult = normalizeInlineComponentsFromEnglish(
+ content,
+ englishMd
+ )
+ content = inlineResult.content
+ if (inlineResult.fixCount > 0) {
+ issues.push(
+ `Normalized ${inlineResult.fixCount} inline components to match English`
+ )
+ }
+
+ // Repair unclosed backticks in inline code
+ const backtickResult = repairUnclosedBackticks(content, englishMd)
+ content = backtickResult.content
+ if (backtickResult.fixCount > 0) {
+ issues.push(`Repaired ${backtickResult.fixCount} unclosed backticks`)
+ }
+
+ const blankLineResult = restoreBlankLinesFromEnglish(content, englishMd)
+ content = blankLineResult.content
+ if (blankLineResult.fixCount > 0) {
+ issues.push(
+ `Restored ${blankLineResult.fixCount} blank lines from English`
+ )
+ }
+
+ // Fix collapsed line breaks between consecutive components
+ const collapsedResult = fixCollapsedComponentLineBreaks(content, englishMd)
+ content = collapsedResult.content
+ if (collapsedResult.fixCount > 0) {
+ issues.push(
+ `Fixed ${collapsedResult.fixCount} collapsed component line breaks`
+ )
+ }
+
+ // Check for mistranslated brand names (report-only)
+ const brandWarnings = checkProtectedBrandNames(content, englishMd)
+ issues.push(...brandWarnings)
+
+ // Fix translated hrefs using set comparison
+ const hrefResult = fixTranslatedHrefs(content, englishMd)
+ content = hrefResult.content
+ if (hrefResult.fixCount > 0) {
+ issues.push(
+ `Fixed ${hrefResult.fixCount} translated hrefs: ${hrefResult.fixes.join(", ")}`
+ )
+ }
+ issues.push(...hrefResult.warnings)
+ }
+
+ const fixed = before !== content
+ // Only write to disk if no content was provided (legacy mode)
+ if (fixed && !providedContent) {
+ fs.writeFileSync(mdPath, content, "utf8")
+ }
+ // Run critical checks (report-only)
+ let m: RegExpExecArray | null
+ // Broken links containing spaces inside URL
+ while ((m = BROKEN_LINK_REGEX.exec(content))) {
+ issues.push(`Broken link format at ${mdPath}:${lineAt(content, m.index)}`)
+ }
+ // Invalid links (exclude images/internal/hash/http/mailto/pdf/<...>)
+ while ((m = INVALID_LINK_REGEX.exec(content))) {
+ issues.push(`Invalid link at ${mdPath}:${lineAt(content, m.index)}`)
+ }
+ // Empty link text
+ while ((m = LINK_TEXT_MISSING_REGEX.exec(content))) {
+ issues.push(`Link text missing at ${mdPath}:${lineAt(content, m.index)}`)
+ }
+ // Incorrect image path in translated markdown
+ if (mdPath.includes(`${path.sep}translations${path.sep}`)) {
+ while ((m = INCORRECT_PATH_IN_TRANSLATED_MARKDOWN.exec(content))) {
+ issues.push(
+ `Incorrect image path at ${mdPath}:${lineAt(content, m.index)}`
+ )
+ }
+ }
+ // Spelling mistakes (case-insensitive)
+ for (const mistake of COMMON_SPELLING_MISTAKES) {
+ const re = new RegExp(mistake, "gi")
+ while ((m = re.exec(content))) {
+ issues.push(
+ `Spelling mistake "${mistake}" at ${mdPath}:${lineAt(content, m.index)}`
+ )
+ }
+ }
+ // Case-sensitive mistakes for brands
+ for (const mistake of CASE_SENSITIVE_SPELLING_MISTAKES) {
+ const re = new RegExp(mistake, "g")
+ while ((m = re.exec(content))) {
+ issues.push(
+ `Brand capitalization issue "${mistake}" at ${mdPath}:${lineAt(content, m.index)}`
+ )
+ }
+ }
+ return { fixed, issues, content }
+}
+
+function processJsonFile(
+ jsonPath: string,
+ providedContent?: string
+): {
+ fixed: boolean
+ issues: string[]
+ content: string
+} {
+ const issues: string[] = []
+ let content = providedContent || fs.readFileSync(jsonPath, "utf8")
+ const before = content
+
+ // Normalize BOM and smart quotes
+ content = content
+ .replace(/^\uFEFF/, "")
+ .replace(/[""]/g, '"')
+ .replace(/['']/g, "'")
+
+ // Try parsing to validate JSON
+ try {
+ JSON.parse(content)
+ } catch (e) {
+ const error = e as Error
+ issues.push(`JSON parse error: ${error.message}`)
+ }
+
+ const fixed = before !== content
+ // Only write to disk if no content was provided (legacy mode)
+ if (fixed && !providedContent) {
+ fs.writeFileSync(jsonPath, content, "utf8")
+ }
+
+ return { fixed, issues, content }
+}
+
+function languagesFromEnv(): string[] | undefined {
+ const env = process.env.TARGET_LANGUAGES?.trim()
+ if (!env) return undefined
+ return env
+ .split(",")
+ .map((s) => s.trim())
+ .filter(Boolean)
+}
+
+export function runSanitizer(
+ filesWithContent?: Array<{ path: string; content: string }>,
+ langs?: string[]
+) {
+ console.log("[SANITIZE] Starting post-import sanitizer")
+
+ let mdFilesToProcess: Array<{ path: string; content: string }> = []
+ let jsonFilesToProcess: Array<{ path: string; content: string }> = []
+
+ if (filesWithContent && filesWithContent.length > 0) {
+ // Process only the specific files provided with their in-memory content
+ console.log(
+ `[SANITIZE] Target: ${filesWithContent.length} specific file(s)`
+ )
+ mdFilesToProcess = filesWithContent.filter((f) => f.path.endsWith(".md"))
+ jsonFilesToProcess = filesWithContent.filter((f) =>
+ f.path.endsWith(".json")
+ )
+ } else {
+ // Fallback to language-based scanning (reads from disk)
+ const effectiveLangs = langs || languagesFromEnv()
+ console.log(
+ "[SANITIZE] Target languages:",
+ effectiveLangs ?? "ALL detected in translations/"
+ )
+ const mdFilePaths = listFiles(CONTENT_ROOT, (f) => {
+ if (!f.endsWith(".md")) return false
+ if (!f.includes(`${path.sep}translations${path.sep}`)) return false
+ if (effectiveLangs)
+ return effectiveLangs.some((l) =>
+ f.includes(`${path.sep}translations${path.sep}${l}${path.sep}`)
+ )
+ return true
+ })
+ const jsonFilePaths = listFiles(CONTENT_ROOT, (f) => {
+ if (!f.endsWith(".json")) return false
+ if (!f.includes(`${path.sep}translations${path.sep}`)) return false
+ if (effectiveLangs)
+ return effectiveLangs.some((l) =>
+ f.includes(`${path.sep}translations${path.sep}${l}${path.sep}`)
+ )
+ return true
+ })
+ // Convert file paths to objects without content (will be read from disk)
+ mdFilesToProcess = mdFilePaths.map((p) => ({ path: p, content: "" }))
+ jsonFilesToProcess = jsonFilePaths.map((p) => ({ path: p, content: "" }))
+ }
+
+ let mdFixed = 0
+ const mdIssues: Array<{ file: string; issues: string[] }> = []
+ const mdChanged: Array<{ path: string; content: string }> = []
+
+ for (const fileInfo of mdFilesToProcess) {
+ const { fixed, issues, content } = processMarkdownFile(
+ fileInfo.path,
+ fileInfo.content
+ )
+ if (fixed) {
+ mdFixed++
+ mdChanged.push({ path: fileInfo.path, content })
+ }
+ if (issues.length)
+ mdIssues.push({ file: path.relative(ROOT, fileInfo.path), issues })
+ }
+
+ let jsonFixed = 0
+ const jsonIssues: Array<{ file: string; issues: string[] }> = []
+ const jsonChanged: Array<{ path: string; content: string }> = []
+
+ for (const fileInfo of jsonFilesToProcess) {
+ const { fixed, issues, content } = processJsonFile(
+ fileInfo.path,
+ fileInfo.content
+ )
+ if (fixed) {
+ jsonFixed++
+ jsonChanged.push({ path: fileInfo.path, content })
+ }
+ if (issues.length)
+ jsonIssues.push({ file: path.relative(ROOT, fileInfo.path), issues })
+ }
+
+ console.log(
+ `\n[SANITIZE] Markdown files scanned: ${mdFilesToProcess.length}, fixed: ${mdFixed}`
+ )
+ console.log(
+ `[SANITIZE] JSON files scanned: ${jsonFilesToProcess.length}, fixed: ${jsonFixed}`
+ )
+
+ if (mdIssues.length || jsonIssues.length) {
+ console.log("\n[SANITIZE] Issues detected:")
+ for (const i of mdIssues) {
+ console.log(` - MD ${i.file}`)
+ for (const msg of i.issues) console.log(` • ${msg}`)
+ }
+ for (const i of jsonIssues) {
+ console.log(` - JSON ${i.file}`)
+ for (const msg of i.issues) console.log(` • ${msg}`)
+ }
+ } else {
+ console.log("\n[SANITIZE] No issues detected.")
+ }
+
+ const changedFiles = [...mdChanged, ...jsonChanged].map((f) => ({
+ path: f.path,
+ content: f.content,
+ }))
+ return {
+ changedFiles,
+ markdown: { scanned: mdFilesToProcess.length, fixed: mdFixed },
+ json: { scanned: jsonFilesToProcess.length, fixed: jsonFixed },
+ issues: { markdown: mdIssues, json: jsonIssues },
+ }
+}
+
+if (require.main === module) {
+ runSanitizer()
+}
From 62636be32fa9f149ce85befc3e1bc690d2d85bb7 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 19:47:16 +0000
Subject: [PATCH 6/7] chore: trigger rebuild
From 50c8445e0a1235b54192c07c68d14b6cdc14a936 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 22:20:45 +0000
Subject: [PATCH 7/7] chore: trigger rebuild