├── docs ├── _static │ ├── img │ │ ├── favicon.ico │ │ ├── favicon.png │ │ ├── moon.svg │ │ ├── hamburger-dark.svg │ │ ├── hamburger-light.svg │ │ ├── solid-share-arrow.svg │ │ ├── logo.svg │ │ ├── logo-dark.svg │ │ └── sun.svg │ ├── css │ │ ├── fonts.css │ │ ├── toggle.css │ │ └── pygments.css │ └── js │ │ ├── constants.js │ │ └── toggle.js ├── _templates │ ├── footer.html │ ├── layout.html │ └── versions.html ├── solidity-by-example.rst ├── grammar.rst ├── robots.txt.template ├── logo.svg ├── README.md ├── diff.py ├── types.rst ├── requirements.txt ├── internals │ ├── layout_in_calldata.rst │ ├── layout_in_memory.rst │ ├── variable_cleanup.rst │ └── source_mappings.rst ├── credits-and-attribution.rst ├── contracts.rst ├── solidity_logo.svg ├── docs.sh ├── brand-guide.rst ├── ext │ ├── html_extra_template_renderer.py │ └── remix_code_links.py ├── language-influences.rst ├── examples │ ├── modular.rst │ ├── safe-remote.rst │ └── voting.rst ├── contracts │ ├── interfaces.rst │ ├── abstract-contracts.rst │ ├── custom-storage-layout.rst │ ├── creating-contracts.rst │ ├── function-modifiers.rst │ ├── errors.rst │ ├── constant-state-variables.rst │ └── events.rst ├── progress-checklist.md ├── structure-of-a-contract.rst ├── types │ ├── operator-precedence-table.rst │ └── operators.rst ├── index.rst ├── text_linter.py ├── bugs.rst ├── Makefile ├── make.bat ├── analysing-compilation-output.rst ├── cheatsheet.rst ├── layout-of-source-files.rst └── 070-breaking-changes.rst ├── translation-bot.json ├── .gitignore ├── .readthedocs.yml ├── .github ├── scripts │ ├── check-remote-branch.sh │ ├── set-assignees.sh │ ├── create-sync-branch-for-release.sh │ ├── load-translation-bot-config.sh │ ├── pull-and-resolve-english-changes.sh │ └── generate-pr-body.sh └── workflows │ ├── build.yml │ └── create-weekly-docs-sync-pr.yaml ├── README.md └── CMakeLists.txt /docs/_static/img/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/solidity-docs/ja-japanese/HEAD/docs/_static/img/favicon.ico -------------------------------------------------------------------------------- /docs/_static/img/favicon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/solidity-docs/ja-japanese/HEAD/docs/_static/img/favicon.png -------------------------------------------------------------------------------- /docs/_static/css/fonts.css: -------------------------------------------------------------------------------- 1 | @import url("https://fonts.cdnfonts.com/css/overpass"); 2 | @import url("https://fonts.cdnfonts.com/css/overpass-mono"); -------------------------------------------------------------------------------- /translation-bot.json: -------------------------------------------------------------------------------- 1 | { 2 | "disabled": true, 3 | "custom_sync_disabled": false, 4 | "randomly_assign_maintainers": false, 5 | "pr_labels": [ 6 | "sync-pr" 7 | ] 8 | } 9 | -------------------------------------------------------------------------------- /docs/_templates/footer.html: -------------------------------------------------------------------------------- 1 | {% extends "!footer.html" %} 2 | 3 | {% block extrafooter %} 4 |

5 | Credits and attribution. 6 |

7 | {% endblock %} 8 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Built docs 2 | /docs/_build 3 | 4 | # Automatically generated robots.txt 5 | /docs/_static/robots.txt 6 | 7 | # Python bytecode 8 | *.pyc 9 | __pycache__ 10 | 11 | .vscode 12 | 13 | .DS_Store 14 | 15 | venv 16 | 17 | AGENTS.md -------------------------------------------------------------------------------- /docs/_templates/layout.html: -------------------------------------------------------------------------------- 1 | {% extends "!layout.html" %} 2 | 3 | {% block menu %} 4 | {{ super() }} 5 | 10 | {% endblock %} 11 | -------------------------------------------------------------------------------- /.readthedocs.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | 3 | build: 4 | os: ubuntu-22.04 5 | tools: 6 | python: "3.11" 7 | 8 | sphinx: 9 | builder: html 10 | configuration: docs/conf.py 11 | 12 | formats: 13 | - pdf 14 | - epub 15 | 16 | python: 17 | install: 18 | - requirements: docs/requirements.txt 19 | -------------------------------------------------------------------------------- /docs/solidity-by-example.rst: -------------------------------------------------------------------------------- 1 | ################### 2 | Solidity by Example 3 | ################### 4 | 5 | .. include:: examples/voting.rst 6 | 7 | .. include:: examples/blind-auction.rst 8 | 9 | .. include:: examples/safe-remote.rst 10 | 11 | .. include:: examples/micropayment.rst 12 | 13 | .. include:: examples/modular.rst -------------------------------------------------------------------------------- /docs/grammar.rst: -------------------------------------------------------------------------------- 1 | ********** 2 | 言語の文法 3 | ********** 4 | 5 | .. a4:autogrammar:: SolidityParser 6 | :only-reachable-from: SolidityParser.sourceUnit 7 | :undocumented: 8 | :cc-to-dash: 9 | 10 | .. a4:autogrammar:: SolidityLexer 11 | :only-reachable-from: SolidityParser.sourceUnit 12 | :fragments: 13 | :cc-to-dash: 14 | 15 | -------------------------------------------------------------------------------- /docs/_static/img/moon.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/_static/img/hamburger-dark.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/_static/img/hamburger-light.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /docs/robots.txt.template: -------------------------------------------------------------------------------- 1 | User-Agent: * 2 | Sitemap: http://docs.soliditylang.org/sitemap.xml 3 | Host: docs.soliditylang.org 4 | 5 | Allow: /en/latest/ 6 | Allow: /en/v0.7.6/ 7 | Allow: /en/v{{ LATEST_VERSION }}/ 8 | Allow: /_/downloads/en/latest/ 9 | Allow: /_/downloads/en/0.7.6/ 10 | Allow: /_/downloads/en/{{ LATEST_VERSION }}/ 11 | 12 | # Prevent documentation for the development branches and older Solidity 13 | # versions from showing up in search results. 14 | Disallow: /en/* 15 | Disallow: /_/downloads/en/* 16 | -------------------------------------------------------------------------------- /docs/_static/img/solid-share-arrow.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.github/scripts/check-remote-branch.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | 4 | function fail { >&2 echo -e "ERROR: $1"; exit 1; } 5 | 6 | (( $# == 1 )) || fail "Wrong number of arguments\nUsage: $0 > "$GITHUB_OUTPUT" 20 | -------------------------------------------------------------------------------- /docs/logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /docs/_static/img/logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /docs/_static/img/logo-dark.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | # Solidity Language Docs 2 | 3 | ## Local environment setup 4 | 5 | 1. Install python https://www.python.org/downloads/ 6 | 1. Install sphinx (the tool used to generate the docs) https://www.sphinx-doc.org/en/master/usage/installation.html 7 | 8 | Go to `/docs` and run `./docs.sh` to install dependencies and build the project: 9 | 10 | ```sh 11 | cd docs 12 | ./docs.sh 13 | ``` 14 | 15 | That will output the generated htmls under _build/ 16 | 17 | ## Serve environment 18 | 19 | ```py 20 | python3 -m http.server -d _build/html --cgi 8080 21 | ``` 22 | 23 | Visit dev server at http://localhost:8080 24 | -------------------------------------------------------------------------------- /docs/_static/img/sun.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.github/workflows/build.yml: -------------------------------------------------------------------------------- 1 | name: build 2 | 3 | on: 4 | push: 5 | branches: [ "develop" ] 6 | pull_request: 7 | branches: [ "develop" ] 8 | 9 | workflow_dispatch: 10 | 11 | jobs: 12 | build: 13 | runs-on: ubuntu-latest 14 | if: github.event.pull_request.draft == false 15 | 16 | steps: 17 | - uses: actions/checkout@v3 18 | 19 | - uses: actions/setup-python@v4 20 | with: 21 | python-version: '3.10' 22 | # cache: 'pip' # ERROR 23 | - run: pip install -r docs/requirements.txt 24 | 25 | - name: Build 26 | working-directory: ./docs 27 | run: make html 28 | 29 | -------------------------------------------------------------------------------- /docs/diff.py: -------------------------------------------------------------------------------- 1 | import re 2 | 3 | """ 4 | ただ改行するだけの変更かどうかを判別 5 | """ 6 | 7 | a = """ 8 | """ 9 | 10 | b = """ 11 | """ 12 | 13 | a = a.split("\n") 14 | for i in range(len(a)): 15 | if a[i].startswith("-"): 16 | a[i] = a[i][1:] 17 | 18 | b = b.split("\n") 19 | for i in range(len(b)): 20 | if b[i].startswith("+"): 21 | b[i] = b[i][1:] 22 | 23 | a = " ".join(a).replace(".", ".\n").split("\n") 24 | b = " ".join(b).replace(".", ".\n").split("\n") 25 | 26 | for x, y in zip(a, b): 27 | x , y = x.strip(), y.strip() 28 | x = re.sub(r"\s+", " ", x) 29 | y = re.sub(r"\s+", " ", y) 30 | if x != y: 31 | print(x) 32 | print(y) 33 | print() -------------------------------------------------------------------------------- /docs/types.rst: -------------------------------------------------------------------------------- 1 | .. index:: type 2 | 3 | .. _types: 4 | 5 | ** 6 | 型 7 | ** 8 | 9 | Solidityは静的型付け言語です。 10 | つまり、各変数（ステートとローカル）の型を指定する必要があります。 11 | Solidityにはいくつかの基本的な型があり、それらを組み合わせて複雑な型を作ることができます。 12 | 13 | また、演算子を含む式では、型同士が相互に作用できます。 14 | 様々な演算子のクイックリファレンスについては、 :ref:`order` を参照してください。 15 | 16 | Solidityには "undefined"や"null"の値の概念はありませんが、新しく宣言された変数は常にその型に依存した :ref:`デフォルト値` を持ちます。 17 | 予期せぬ値を処理するには、 :ref:`リバート` を使ってトランザクション全体をリバートするか、成功を示す ``bool`` 値を2番目に持つタプルを返す必要があります。 18 | 19 | .. include:: types/value-types.rst 20 | 21 | .. include:: types/reference-types.rst 22 | 23 | .. include:: types/mapping-types.rst 24 | 25 | .. include:: types/operators.rst 26 | 27 | .. include:: types/conversion.rst 28 | 29 | -------------------------------------------------------------------------------- /docs/requirements.txt: -------------------------------------------------------------------------------- 1 | # Older versions of sphinx-rtd-theme do not work with never docutils but have a bug in the dependency 2 | # which could result in it being installed anyway and the style (especially bullet points) being broken. 3 | # See https://github.com/readthedocs/sphinx_rtd_theme/issues/1115 4 | # theme >=3.0.0 removes the display_version option in favor of version_selector and language_selector 5 | sphinx_rtd_theme>=0.5.2, <3.0.0 6 | 7 | pygments-lexer-solidity>=0.7.0 8 | sphinx-a4doc>=1.6.0; python_version < '3.13' 9 | # todo remove this once there is a version > 1.6.0 10 | sphinx-a4doc @ git+https://github.com/taminomara/sphinx-a4doc@f63d3b2; python_version >= '3.13' 11 | 12 | # Sphinx 2.1.0 is the oldest version that accepts a lexer class in add_lexer() 13 | sphinx>=2.1.0, <9.0 14 | -------------------------------------------------------------------------------- /.github/scripts/set-assignees.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | LANGUAGE=$1 4 | 5 | # extracts de from de-german 6 | lang_code=${LANGUAGE:0:2} 7 | number_of_maintainers=$(jq '.maintainers | length' ".github-workflow/langs/$lang_code.json") 8 | 9 | 10 | assignee=$((($RANDOM%$number_of_maintainers))) 11 | reviewer=$((($RANDOM%$number_of_maintainers))) 12 | 13 | while [[ $assignee == "$reviewer" && number_of_maintainers -gt 1 ]] 14 | do 15 | reviewer=$((($RANDOM%$number_of_maintainers))) 16 | done 17 | 18 | echo "reviewer=$( 19 | jq --raw-output ".maintainers[$reviewer]" ".github-workflow/langs/$lang_code.json" 20 | )" >> $GITHUB_ENV 21 | 22 | echo "assignee=$( 23 | jq --raw-output ".maintainers[$assignee]" ".github-workflow/langs/$lang_code.json" 24 | )" >> $GITHUB_ENV 25 | 26 | -------------------------------------------------------------------------------- /docs/internals/layout_in_calldata.rst: -------------------------------------------------------------------------------- 1 | 2 | .. index: calldata layout 3 | 4 | ************************ 5 | コールデータのレイアウト 6 | ************************ 7 | 8 | .. The input data for a function call is assumed to be in the format defined by the :ref:`ABI 9 | .. specification `. Among others, the ABI specification requires arguments to be padded to multiples of 32 10 | .. bytes. The internal function calls use a different convention. 11 | 12 | 関数呼び出しの入力データは、 :ref:`ABIの仕様` で定義されたフォーマットであることが前提となっています。 13 | とりわけ、ABI仕様では、引数を32バイトの倍数にパディングすることが求められています。 14 | 内部の関数呼び出しでは、これとは異なる規則が用いられています。 15 | 16 | .. Arguments for the constructor of a contract are directly appended at the end of the 17 | .. contract's code, also in ABI encoding. The constructor will access them through a hard-coded offset, and 18 | .. not by using the ``codesize`` opcode, since this of course changes when appending 19 | .. data to the code. 20 | 21 | コントラクトのコンストラクタの引数は、コントラクトのコードの最後にABIエンコーディングで直接追加されます。 22 | コンストラクタはハードコードされたオフセットを使ってアクセスしますが、コードにデータを追加するときに変更されるため、 ``codesize`` オペコードは使用しません。 23 | 24 | -------------------------------------------------------------------------------- /.github/scripts/create-sync-branch-for-release.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | 4 | # This script creates sync branches matching tagged releases in the main Solidity repository. 5 | # The result is a sync commit and a branch. The script does NOT push the branch or create a PR. 6 | 7 | # ASSUMPTIONS: 8 | # - The current directory already contains a clone of the translation repository. 9 | # - If a remote called 'english' exists, it points to the main Solidity repository. 10 | 11 | script_dir="$(dirname "$0")" 12 | 13 | function fail { >&2 echo -e "ERROR: $1"; exit 1; } 14 | 15 | (( $# == 1 )) || fail "Wrong number of arguments\nUsage: $0 " 16 | TAG="$1" 17 | if ! git config remote.english.url; then 18 | git remote add english "https://github.com/ethereum/solidity.git" 19 | fi 20 | 21 | git fetch english tag "$TAG" --no-tags 22 | git fetch english develop 23 | 24 | git checkout origin/develop 25 | git checkout -b "sync-${TAG}" 26 | 27 | today=$(date -u +%Y-%m-%d) 28 | "${script_dir}/pull-and-resolve-english-changes.sh" "$TAG" "Sync with ethereum/solidity@${TAG} (${today})" 29 | -------------------------------------------------------------------------------- /docs/credits-and-attribution.rst: -------------------------------------------------------------------------------- 1 | .. This page is meant to be linked to from the footer. 2 | 3 | :orphan: 4 | 5 | .. Credits and Attribution 6 | 7 | ############################## 8 | クレジットとアトリビューション 9 | ############################## 10 | 11 | Webサイトのアイコン 12 | =================== 13 | 14 | .. |icon-share-solid| image:: _static/img/solid-share-arrow.svg 15 | .. _share icon: https://fontawesome.com/v5.15/icons/share?style=solid 16 | .. _Font Awesome Free License: https://fontawesome.com/license/free 17 | 18 | +-------------------------+-----------------------------------------------------------------------+ 19 | | アイコン | アトリビューション | 20 | +=========================+=======================================================================+ 21 | | |icon-share-solid| | - ソース: `share icon`_ from Font Awesome 5.15.0 | 22 | | | - ライセンス: `Font Awesome Free License`_ (CC BY 4.0) | 23 | +-------------------------+-----------------------------------------------------------------------+ 24 | 25 | -------------------------------------------------------------------------------- /docs/_templates/versions.html: -------------------------------------------------------------------------------- 1 | {# Add rst-badge after rst-versions for small badge style. #} 2 |
3 | 4 | RTD 5 | 6 | 7 | 8 | 9 | 10 | 11 | v: {{ current_version }} 12 | 13 | 14 |
15 |
16 |
{{ _('Downloads') }}
{% for type, url in downloads %} 17 |
{{ type }}
18 | {% endfor %} 19 |
20 |
21 |
{{ _('Versions') }}
{% for slug, url in versions %} 22 |
{{ slug }}
23 | {% endfor %} 24 |
25 |
26 | {# Translators: The phrase "Read the Docs" is not translated #} 27 |
{{ _('On Read the Docs') }}
28 |
29 | {{ _('Project Home') }} 30 |
31 |
32 | {{ _('Builds') }} 33 |
34 |
35 |
36 |
37 | -------------------------------------------------------------------------------- /docs/contracts.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! contract 2 | 3 | .. _contracts: 4 | 5 | ############ 6 | コントラクト 7 | ############ 8 | 9 | .. Contracts in Solidity are similar to classes in object-oriented languages. They 10 | .. contain persistent data in state variables, and functions that can modify these 11 | .. variables. Calling a function on a different contract (instance) will perform 12 | .. an EVM function call and thus switch the context such that state variables 13 | .. in the calling contract are 14 | .. inaccessible. A contract and its functions need to be called for anything to happen. 15 | .. There is no "cron" concept in Ethereum to call a function at a particular event automatically. 16 | 17 | Solidityのコントラクトは、オブジェクト指向言語のクラスに似ています。 18 | コントラクトには、状態変数に格納された永続的なデータと、これらの変数を変更できる関数が含まれています。 19 | 別のコントラクト（インスタンス）の関数を呼び出すと、EVM関数呼び出しが実行され、呼び出したコントラクトの状態変数にアクセスできないようにコンテキストが切り替わります。 20 | コントラクトとその関数は、何かが起こるために呼び出される必要があります。 21 | Ethereumには、特定のイベントで自動的に関数を呼び出す「cron」の概念はありません。 22 | 23 | .. include:: contracts/creating-contracts.rst 24 | 25 | .. include:: contracts/visibility-and-getters.rst 26 | 27 | .. include:: contracts/function-modifiers.rst 28 | 29 | .. include:: contracts/transient-storage.rst 30 | 31 | .. include:: contracts/constant-state-variables.rst 32 | .. include:: contracts/custom-storage-layout.rst 33 | .. include:: contracts/functions.rst 34 | 35 | .. include:: contracts/events.rst 36 | .. include:: contracts/errors.rst 37 | 38 | .. include:: contracts/inheritance.rst 39 | 40 | .. include:: contracts/abstract-contracts.rst 41 | .. include:: contracts/interfaces.rst 42 | 43 | .. include:: contracts/libraries.rst 44 | 45 | .. include:: contracts/using-for.rst 46 | -------------------------------------------------------------------------------- /docs/solidity_logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | Vector 1 8 | Created with Sketch. 9 | 10 | 11 | 12 | 14 | 16 | 18 | 20 | 22 | 24 | 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /docs/_static/js/constants.js: -------------------------------------------------------------------------------- 1 | // Site URL 2 | const SITE_URL = "https://docs.soliditylang.org" 3 | const { origin, pathname } = location; 4 | const pathSplit = pathname.split("/"); 5 | const rootPath = origin.includes(SITE_URL) && pathSplit.length > 3 ? pathSplit.splice(1, 2).join("/") : '' 6 | const ROOT_URL = `${origin}/${rootPath}`; 7 | 8 | // Color mode constants 9 | const [DARK, LIGHT] = ["dark", "light"]; 10 | const LIGHT_LOGO_PATH = `${ROOT_URL}/_static/img/logo.svg`; 11 | const DARK_LOGO_PATH = `${ROOT_URL}/_static/img/logo-dark.svg`; 12 | const SUN_ICON_PATH = `${ROOT_URL}/_static/img/sun.svg`; 13 | const MOON_ICON_PATH = `${ROOT_URL}/_static/img/moon.svg`; 14 | const LIGHT_HAMBURGER_PATH = `${ROOT_URL}/_static/img/hamburger-light.svg`; 15 | const DARK_HAMBURGER_PATH = `${ROOT_URL}/_static/img/hamburger-dark.svg`; 16 | const COLOR_TOGGLE_ICON_CLASS = "color-toggle-icon"; 17 | const SOLIDITY_LOGO_CLASS = "solidity-logo"; 18 | const LS_COLOR_SCHEME = "color-scheme"; 19 | 20 | // Solidity navigation constants 21 | const SOLIDITY_HOME_URL = "https://soliditylang.org"; 22 | const BLOG_URL = `${SOLIDITY_HOME_URL}/blog`; 23 | const DOCS_URL = "/"; 24 | const USE_CASES_PATH = `${SOLIDITY_HOME_URL}/use-cases`; 25 | const CONTRIBUTE_PATH = `/en/latest/contributing.html`; 26 | const ABOUT_PATH = `${SOLIDITY_HOME_URL}/about`; 27 | const FORUM_URL = "https://forum.soliditylang.org/"; 28 | const NAV_LINKS = [ 29 | { name: "Blog", href: BLOG_URL }, 30 | { name: "Documentation", href: DOCS_URL }, 31 | { name: "Use cases", href: USE_CASES_PATH }, 32 | { name: "Contribute", href: CONTRIBUTE_PATH }, 33 | { name: "About", href: ABOUT_PATH }, 34 | { name: "Forum", href: FORUM_URL }, 35 | ]; 36 | 37 | const MOBILE_MENU_TOGGLE_CLASS = "shift"; 38 | const WRAPPER_CLASS = "unified-wrapper"; 39 | -------------------------------------------------------------------------------- /docs/docs.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | 3 | #------------------------------------------------------------------------------ 4 | # Bash script to build the Solidity Sphinx documentation locally. 5 | # 6 | # The documentation for solidity is hosted at: 7 | # 8 | # https://docs.soliditylang.org 9 | # 10 | # ------------------------------------------------------------------------------ 11 | # This file is part of solidity. 12 | # 13 | # solidity is free software: you can redistribute it and/or modify 14 | # it under the terms of the GNU General Public License as published by 15 | # the Free Software Foundation, either version 3 of the License, or 16 | # (at your option) any later version. 17 | # 18 | # solidity is distributed in the hope that it will be useful, 19 | # but WITHOUT ANY WARRANTY; without even the implied warranty of 20 | # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 21 | # GNU General Public License for more details. 22 | # 23 | # You should have received a copy of the GNU General Public License 24 | # along with solidity. If not, see 25 | # 26 | # (c) 2016 solidity contributors. 27 | #------------------------------------------------------------------------------ 28 | 29 | set -euo pipefail 30 | 31 | script_dir="$(dirname "$0")" 32 | 33 | cd "${script_dir}" 34 | # TODO `--ignore-installed` now fixes an issue where pip tries to uninstall a Debian installed package, but is unable to 35 | # TODO since Debian has decided to not use the RECORD file, which then breaks pip. 36 | # TODO https://github.com/pypa/pip/issues/11631 and https://bugs.launchpad.net/ubuntu/+source/wheel/+bug/2063151 37 | pip3 install -r requirements.txt --ignore-installed --upgrade --upgrade-strategy eager 38 | sphinx-build -nW -b html -d _build/doctrees . _build/html 39 | -------------------------------------------------------------------------------- /docs/_static/js/toggle.js: -------------------------------------------------------------------------------- 1 | function toggleColorMode() { 2 | // Check localStorage for previous color scheme preference, assign the opposite 3 | var newMode = localStorage.getItem(LS_COLOR_SCHEME) == DARK ? LIGHT : DARK; 4 | 5 | // Update localStorage with new color scheme preference 6 | localStorage.setItem(LS_COLOR_SCHEME, newMode); 7 | 8 | // Update the root element with the new color scheme preference 9 | document 10 | .querySelector(":root") 11 | .setAttribute("style", `--color-scheme: ${newMode}`); 12 | 13 | // Update logo 14 | document 15 | .querySelector(`img.${SOLIDITY_LOGO_CLASS}`) 16 | .setAttribute("src", newMode === LIGHT ? LIGHT_LOGO_PATH : DARK_LOGO_PATH); 17 | 18 | // Update color mode toggle icon 19 | document 20 | .querySelector(`img.${COLOR_TOGGLE_ICON_CLASS}`) 21 | .setAttribute("src", newMode === LIGHT ? MOON_ICON_PATH : SUN_ICON_PATH); 22 | 23 | // Update hamburger menu icon color 24 | document 25 | .querySelector("button.mobile-menu-button img") 26 | .setAttribute( 27 | "src", 28 | newMode === LIGHT ? LIGHT_HAMBURGER_PATH : DARK_HAMBURGER_PATH 29 | ); 30 | } 31 | 32 | function toggleMenu(options = {}) { 33 | const handleClassToggle = ({ classList }, className) => { 34 | if (typeof options.force !== "undefined") { 35 | classList.toggle(className, options.force); 36 | } else { 37 | classList.toggle(className); 38 | } 39 | }; 40 | document 41 | .querySelectorAll('[data-toggle="rst-versions"]') 42 | .forEach((e) => handleClassToggle(e, MOBILE_MENU_TOGGLE_CLASS)); 43 | document 44 | .querySelectorAll('[data-toggle="wy-nav-shift"]') 45 | .forEach((e) => handleClassToggle(e, MOBILE_MENU_TOGGLE_CLASS)); 46 | handleClassToggle(document.querySelector(`.${WRAPPER_CLASS}`), "menu-open"); 47 | } 48 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Japanese Translation of the Solidity Documentation 2 | 3 | Solidityドキュメントの日本語翻訳プロジェクトです。 4 | 進捗状況は https://github.com/solidity-docs/ja-japanese/issues/1 で確認できます。 5 | このリポジトリは https://docs.soliditylang.org/ja/latest/ と連携しています。 6 | 7 | Solidityドキュメントの翻訳者のチャットは https://forum.soliditylang.org/t/new-communication-channel-about-solidity-docs-community-translations/918 に記載されています。 8 | 9 | なお以前は、 https://solidity-ja.readthedocs.io/ で日本語翻訳を閲覧可能でした（ビルド元はこのリポジトリと同期している https://github.com/minaminao/ja-japanese です）。 10 | 現在は https://docs.soliditylang.org/ja/ にリダイレクトされます。 11 | 12 | ## 翻訳に際して 13 | 14 | ### 同期PRの対処の仕方 15 | 16 | [ethereum/solidity](https://github.com/ethereum/solidity) と同期するPRが定期的に作成される。 17 | 18 | 基本的にGitHubのGUIだけでは翻訳するのは難しく、gitコマンドを使ったCUI操作が必要。 19 | 20 | まず、同期PRの「Files changed」から変更されたドキュメントのファイル一覧を見る。 21 | 22 | 次に、前回の同期PRの最終コミットハッシュから、今回の同期PRの最新コミットハッシュ間の差分を、オリジナルの ethereum/solidity リポジトリで、 `git diff ..` を実行して表示する。 23 | 具体的なコミットハッシュは前回の同期PRの最後のコミットハッシュ（botによるコミットの直前）と、今回の同期PRの最後のコミットハッシュ（botによるコミットの直前）を使えば良い。 24 | 25 | そして、変更された各ファイルごとに、 `git diff` の結果画面で `/` コマンドで変更点を調べる。 26 | `gh pr checkout ` 等を用いて該当PRのブランチに切り替え、コンフリクトの対処や翻訳を行う。 27 | 28 | ### 環境構築の一例 29 | 30 | ``` 31 | pyenv shell 3.12.7 32 | python -m venv venv 33 | source venv/bin/activate.fish 34 | pip install -r docs/requirements.txt 35 | ``` 36 | 37 | ### ビルド 38 | 39 | HTML: 40 | ``` 41 | source venv/bin/activate.fish 42 | cd docs 43 | make html 44 | ``` 45 | 46 | PDF: 47 | ``` 48 | source venv/bin/activate.fish 49 | cd docs 50 | make latexpdf 51 | ``` 52 | 53 | 58 | 59 | ### 特定のバージョンの同期PRの作り方 60 | 61 | https://github.com/solidity-docs/.github/blob/main/scripts/create-sync-branch-for-release.sh をこのリポジトリのルートで実行するとブランチが生成される。 62 | それをpushしてPRを作成する。 63 | -------------------------------------------------------------------------------- /docs/brand-guide.rst: -------------------------------------------------------------------------------- 1 | ###################### 2 | Solidityブランドガイド 3 | ###################### 4 | 5 | このブランドガイドでは、Solidityのブランドポリシーやロゴ使用のガイドラインなどを紹介します。 6 | 7 | Solidityのブランド 8 | ================== 9 | 10 | Solidity プログラミング言語は、コアチームが運営するオープンソースのコミュニティプロジェクトです。 11 | コアチームのスポンサーは `Ethereum Foundation `_ です。 12 | 13 | このドキュメントは、Solidityのブランド名とロゴの最適な使用方法についての情報を提供することを目的としています。 14 | 15 | ブランド名やロゴを使用する前に、この文書をよくお読みになってください。 16 | 皆様のご協力に深く感謝いたします！ 17 | 18 | Solidityのブランド名 19 | ==================== 20 | 21 | 『Solidity』は、Solidity プログラミング言語のみを指す言葉です。 22 | 23 | 以下の場合に『Solidity』は使用しないでください: 24 | 25 | - 他のプログラミング言語を指し示す行為。 26 | - 誤解を招くような方法や、無関係なモジュール、ツール、ドキュメント、その他のリソースとSolidityの関連性を示唆するような方法での使用。 27 | - Solidity プログラミング言語がオープンソースであり無料で使用できるかどうかについて、コミュニティを混乱させるような方法。 28 | 29 | Solidityロゴのライセンス 30 | ======================== 31 | 32 | .. image:: https://i.creativecommons.org/l/by/4.0/88x31.png 33 | :width: 88 34 | :alt: Creative Commons License 35 | 36 | Solidityのロゴは、 `Creative Commons Attribution 4.0 International License `_ の下で配布され、ライセンスされています。 37 | 38 | これは、最も寛容なクリエイティブ・コモンズ・ライセンスであり、いかなる目的のためにも再利用や修正を認めています。 39 | 40 | あなたは後で示す条件のもとで次のことを自由に行えます: 41 | 42 | - **Share** — 媒体や形式を問わず、コピーして再配布すること。 43 | - **Adapt** — 営利目的含むいかなる目的であっても、素材をリミックス、変換、構築すること。 44 | 45 | 条件は以下です: 46 | 47 | - **Attribution** — 適切なクレジットを表示し、ライセンスへのリンクを提供し、変更が加えられた場合にはその旨を明示しなければなりません。これらは社会通念上適切と認められる範囲で行うことができますが、Solidity コアチームがあなたやあなたの利用を支持していると示唆するような方法で行ってはなりません。 48 | 49 | また、Solidityロゴを使用する際は、Solidityロゴのガイドラインを尊重してください。 50 | 51 | Solidityロゴのガイドライン 52 | ========================== 53 | 54 | .. image:: solidity_logo.svg 55 | :width: 256 56 | 57 | *（ロゴの上で右クリックするとダウンロードできます。）* 58 | 59 | 次のことをしないでください: 60 | 61 | - ロゴの比率を変更すること（伸ばしたり切ったりしない）。 62 | - ロゴの色を変更すること。どうしても必要な場合を除く。 63 | 64 | クレジット 65 | ========== 66 | 67 | このドキュメントは、 `Python Software Foundation Trademark Usage Policy `_ と `Rust Media Guide `_ から派生した部分があります。 68 | -------------------------------------------------------------------------------- /docs/ext/html_extra_template_renderer.py: -------------------------------------------------------------------------------- 1 | import os.path 2 | 3 | 4 | def render_html_extra_templates(app): 5 | if app.builder.format != 'html': 6 | # Non-HTML builders do not provide .templates.render_string(). Note that a HTML 7 | # builder is still used also when building some other formats like json or epub. 8 | return 9 | 10 | for input_path, template_config in app.config.html_extra_templates.items(): 11 | # Requiring absolute paths simplifies the implementation. 12 | if not os.path.isabs(input_path): 13 | raise RuntimeError(f"Template input path is not absolute: {input_path}") 14 | if not os.path.isabs(template_config['target']): 15 | raise RuntimeError(f"Template target path is not absolute: {template_config['target']}") 16 | 17 | with open(input_path, 'r', encoding='utf8') as input_file: 18 | # This runs Jinja2, which supports rendering {{ }} tags among other things. 19 | rendered_template = app.builder.templates.render_string( 20 | input_file.read(), 21 | template_config['context'], 22 | ) 23 | 24 | with open(template_config['target'], 'w', encoding='utf8') as target_file: 25 | target_file.write(rendered_template) 26 | 27 | app.config.html_extra_path.append(template_config['target']) 28 | 29 | 30 | def setup(app): 31 | app.add_config_value('html_extra_templates', default={}, rebuild='', types=dict) 32 | 33 | # Register a handler for the env-before-read-docs event. Any event that's fired before static 34 | # files get copied would do. 35 | app.connect( 36 | 'env-before-read-docs', 37 | lambda app, env, docnames: render_html_extra_templates(app) 38 | ) 39 | 40 | return { 41 | # NOTE: Need to access _raw_config here because setup() runs before app.config is ready. 42 | 'version': app.config._raw_config['version'], # pylint: disable=protected-access 43 | 'parallel_read_safe': True, 44 | 'parallel_write_safe': True, 45 | } 46 | -------------------------------------------------------------------------------- /.github/scripts/load-translation-bot-config.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | 4 | CONFIG_FILE="$1" 5 | 6 | function load_option { 7 | local option="$1" 8 | local default="$2" 9 | 10 | if [[ ! -e $CONFIG_FILE ]]; then 11 | echo "$default" 12 | return 0 13 | fi 14 | 15 | # We want single-line output to be able to easily pass it to $GITHUB_OUTPUT 16 | local value 17 | value=$(jq --compact-output ".${option}" "$CONFIG_FILE") 18 | 19 | if [[ $value == null ]]; then 20 | echo "$default" 21 | else 22 | echo "$value" 23 | fi 24 | } 25 | 26 | function validate_boolean { 27 | local option="$1" 28 | local value="$2" 29 | 30 | if [[ $value != true && $value != false ]]; then 31 | >&2 echo "${CONFIG_FILE}: Invalid option value for '${option}'. Expected 'true' or 'false', got '${value}'." 32 | return 1 33 | fi 34 | } 35 | 36 | function validate_list { 37 | local option="$1" 38 | local value="$2" 39 | 40 | if ! echo "$value" | jq > /dev/null 2>&1; then 41 | >&2 echo "${CONFIG_FILE}: Invalid option value for '${option}'. Expected a JSON list, got '${value}'." 42 | return 1 43 | fi 44 | } 45 | 46 | function print_option { 47 | local option="$1" 48 | local value="$2" 49 | 50 | # The second echo is there so that we can actually see the value in the log for debug purposes 51 | echo "${option}=${value}" >> "$GITHUB_OUTPUT" 52 | echo "${option}: ${value}" 53 | } 54 | 55 | # NOTE: If you change defaults here, remember to update the README 56 | bot_disabled=$(load_option custom_sync_disabled true) 57 | randomly_assign_maintainers=$(load_option randomly_assign_maintainers false) 58 | pr_labels=$(load_option pr_labels '["sync-pr"]') 59 | 60 | validate_boolean disabled "$bot_disabled" 61 | validate_boolean randomly_assign_maintainers "$randomly_assign_maintainers" 62 | validate_list pr_labels "$pr_labels" 63 | 64 | print_option bot_disabled "$bot_disabled" 65 | print_option randomly_assign_maintainers "$randomly_assign_maintainers" 66 | print_option pr_labels "$pr_labels" 67 | -------------------------------------------------------------------------------- /docs/_static/css/toggle.css: -------------------------------------------------------------------------------- 1 | input[type=checkbox] { 2 | visibility: hidden; 3 | height: 0; 4 | width: 0; 5 | margin: 0; 6 | } 7 | 8 | .rst-versions .rst-current-version { 9 | padding: 10px; 10 | display: flex; 11 | justify-content: space-between; 12 | background-color: var(--color-f); 13 | border-top: 1px solid var(--color-c); 14 | } 15 | 16 | .fa-caret-down, 17 | .fa-book { 18 | color: var(--color-a) !important; 19 | } 20 | 21 | .rst-versions .rst-current-version .fa-book, 22 | .rst-versions .rst-current-version .fa-v, 23 | .rst-versions .rst-current-version .fa-caret-down { 24 | height: 24px; 25 | line-height: 24px; 26 | vertical-align: middle; 27 | } 28 | 29 | .rst-versions .rst-current-version .fa-element { 30 | width: 80px; 31 | text-align: center; 32 | } 33 | 34 | .rst-versions .rst-current-version .fa-book { 35 | text-align: left; 36 | } 37 | 38 | .rst-versions .rst-current-version .fa-v { 39 | color: #27AE60; 40 | text-align: right; 41 | } 42 | 43 | label { 44 | margin: 0 auto; 45 | display: inline-block; 46 | justify-content: center; 47 | align-items: right; 48 | border-radius: 100px; 49 | position: relative; 50 | cursor: pointer; 51 | text-indent: -9999px; 52 | width: 50px; 53 | height: 21px; 54 | background: #000; 55 | } 56 | 57 | label:after { 58 | border-radius: 50%; 59 | position: absolute; 60 | content: ''; 61 | background: #fff; 62 | width: 15px; 63 | height: 15px; 64 | top: 3px; 65 | left: 3px; 66 | transition: ease-in-out 200ms; 67 | } 68 | 69 | input:checked+label { 70 | background: #3a7ca8; 71 | } 72 | 73 | input:checked+label:after { 74 | left: calc(100% - 5px); 75 | transform: translateX(-100%); 76 | } 77 | 78 | html.transition, 79 | html.transition *, 80 | html.transition *:before, 81 | html.transition *:after { 82 | transition: ease-in-out 200ms !important; 83 | transition-delay: 0 !important; 84 | } 85 | 86 | .wy-menu-vertical a:hover { 87 | background-color: #0002; 88 | } 89 | 90 | body { 91 | font-weight: 300; 92 | letter-spacing: 0.5px; 93 | } -------------------------------------------------------------------------------- /docs/language-influences.rst: -------------------------------------------------------------------------------- 1 | .. Language Influences 2 | 3 | ########## 4 | 言語の影響 5 | ########## 6 | 7 | Solidityは、いくつかの有名なプログラミング言語に影響やインスピレーションを受けた `カーリーブラケット言語 `_ です。 8 | 9 | .. Solidity is most profoundly influenced by C++, but also borrowed concepts from languages like Python, JavaScript, and others. 10 | 11 | Solidityは、C++から最も大きな影響を受けていますが、PythonやJavaScriptなどの言語からもコンセプトを借りています。 12 | 13 | .. The influence from C++ can be seen in the syntax for variable declarations, for loops, the concept of overloading functions, implicit and explicit type conversions and many other details. 14 | 15 | C++からの影響は、変数宣言やforループの構文、関数のオーバーロードの概念、暗黙的な型変換と明示的な型変換、その他多くの細部に見られます。 16 | 17 | .. In the early days of the language, Solidity used to be partly influenced by JavaScript. 18 | .. This was due to function-level scoping of variables and the use of the keyword ``var``. 19 | .. The JavaScript influence was reduced starting from version 0.4.0. 20 | .. Now, the main remaining similarity to JavaScript is that functions are defined using the keyword ``function``. 21 | .. Solidity also supports import syntax and semantics that are similar to those available in JavaScript. 22 | .. Besides those points, Solidity looks like most other curly-bracket languages and has no major JavaScript influence anymore. 23 | 24 | 言語開発の初期において、SolidityはJavaScriptの影響を部分的に受けていました。 25 | これは、関数レベルでの変数のスコープや、キーワード ``var`` の使用によるものでした。 26 | JavaScriptの影響はバージョン0.4.0から少なくなりました。 27 | 現在、JavaScriptとの主な類似点は、関数がキーワード ``function`` を使って定義されていることです。 28 | また、Solidityは、JavaScriptと同様のインポート構文とセマンティクスをサポートしています。 29 | これらの点を除けば、Solidityは他の多くのカーリーブラケット言語と同じように見えますし、もはやJavaScriptの影響は大きくありません。 30 | 31 | .. Another influence to Solidity was Python. 32 | .. Solidity's modifiers were added trying to model Python's decorators with a much more restricted functionality. 33 | .. Furthermore, multiple inheritance, C3 linearization, and the ``super`` keyword are taken from Python as well as the general assignment and copy semantics of value and reference types. 34 | 35 | もう一つSolidityに影響を与えたのがPythonです。 36 | Solidityのモディファイアは、Pythonのデコレータをモデルにして追加されたもので、機能はより制限されています。 37 | さらに、多重継承、C3線形化、 ``super`` キーワードは、値や参照型の一般的な代入とコピーのセマンティクスと同様に、Pythonから採用されています。 38 | -------------------------------------------------------------------------------- /docs/examples/modular.rst: -------------------------------------------------------------------------------- 1 | .. index:: contract;modular, modular contract 2 | 3 | ********************** 4 | モジュラーコントラクト 5 | ********************** 6 | 7 | モジュラーアプローチでコントラクトを構築すると、複雑さを軽減し、読みやすさを向上させることができ、開発やコードレビューの際にバグや脆弱性を特定するのに役立ちます。 8 | 各モジュールの動作を個別に指定して制御する場合、考慮しなければならない相互作用はモジュールの仕様間のものだけで、コントラクトの他のすべての可動部分ではありません。 9 | 以下の例では、コントラクトは ``Balances`` :ref:`ライブラリ ` の ``move`` メソッドを使用して、アドレス間で送信された残高が期待したものと一致するかどうかをチェックしています。 10 | このように、 ``Balances`` ライブラリはアカウントの残高を適切に追跡する独立したコンポーネントを提供しています。 11 | ``Balances`` ライブラリが負の残高やオーバーフローを決して生成せず、すべての残高の合計がコントラクトのライフタイムにわたって不変であることを簡単に確認できます。 12 | 13 | .. code-block:: solidity 14 | 15 | // SPDX-License-Identifier: GPL-3.0 16 | pragma solidity >=0.5.0 <0.9.0; 17 | 18 | library Balances { 19 | function move(mapping(address => uint256) storage balances, address from, address to, uint amount) internal { 20 | require(balances[from] >= amount); 21 | require(balances[to] + amount >= balances[to]); 22 | balances[from] -= amount; 23 | balances[to] += amount; 24 | } 25 | } 26 | 27 | contract Token { 28 | mapping(address => uint256) balances; 29 | using Balances for *; 30 | mapping(address => mapping(address => uint256)) allowed; 31 | 32 | event Transfer(address from, address to, uint amount); 33 | event Approval(address owner, address spender, uint amount); 34 | 35 | function transfer(address to, uint amount) external returns (bool success) { 36 | balances.move(msg.sender, to, amount); 37 | emit Transfer(msg.sender, to, amount); 38 | return true; 39 | 40 | } 41 | 42 | function transferFrom(address from, address to, uint amount) external returns (bool success) { 43 | require(allowed[from][msg.sender] >= amount); 44 | allowed[from][msg.sender] -= amount; 45 | balances.move(from, to, amount); 46 | emit Transfer(from, to, amount); 47 | return true; 48 | } 49 | 50 | function approve(address spender, uint tokens) external returns (bool success) { 51 | require(allowed[msg.sender][spender] == 0, ""); 52 | allowed[msg.sender][spender] = tokens; 53 | emit Approval(msg.sender, spender, tokens); 54 | return true; 55 | } 56 | 57 | function balanceOf(address tokenOwner) external view returns (uint balance) { 58 | return balances[tokenOwner]; 59 | } 60 | } 61 | 62 | -------------------------------------------------------------------------------- /.github/scripts/pull-and-resolve-english-changes.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | 4 | function fail { >&2 echo -e "ERROR: $1"; exit 1; } 5 | 6 | (( $# == 2 )) || fail "Wrong number of arguments\nUsage: $0 " 7 | git config remote.english.url || fail "Remote 'english' is not defined" 8 | SOLIDITY_REF="$1" 9 | COMMIT_MESSAGE="$2" 10 | 11 | # ASSUMPTIONS: 12 | # - We're in the root directory of a working copy of the translation repository. 13 | # - Remote 'english' exists and points at the main Solidity repository. 14 | # - Working copy is clean, with no modified or untracked files. 15 | 16 | # Try to merge changes from the main repository. Anything changed at the same time in the translation 17 | # and in the main repo will result in a conflict and will make the command fail. This is fine. 18 | # We want to include the conflict markers as a part of the merge commit so that they're easy to spot in the PR. 19 | # The command will also fail if in the main repo there were modifications to files outside 20 | # of docs/ (these files are deleted in translation repos). These are the conflicts we want to ignore. 21 | if ! git merge "${SOLIDITY_REF}" -m "$COMMIT_MESSAGE"; then 22 | # Unstage everything without aborting the merge. 23 | # This also "resolves" conflicts by keeping conflicted files as is including the conflict markers. 24 | git reset . 25 | 26 | # The only changes from the main repo that we're interested in are those in docs/ and 27 | # CMakeLists.txt, which is parsed by our Sphinx config to determine version. Stage them. 28 | git add docs/ CMakeLists.txt .readthedocs.yml 29 | 30 | # Reset any files seen by git as modified/deleted to the state from before the merge. 31 | # We need this for files outside of docs/ that happen to match the path of some file that exists 32 | # in the main repo, for example README.md or .gitignore. We do not copy these when setting up a 33 | # translation repo but to git they look like files from the main repo that need to be synced. 34 | files_to_reset=$(git ls-files --modified --deleted) 35 | if [[ $files_to_reset != "" ]]; then 36 | # NOTE: If the file list passed to `git checkout` is empty, git aborts the merge. We don't want that. 37 | git ls-files --modified --deleted | xargs git checkout -- 38 | fi 39 | 40 | # All the other files from the original merge commit are now untracked. We don't want them in the PR. 41 | git clean -d --force 42 | 43 | # Finalize the merge. Should create a commit with the message we specified in the original command. 44 | git commit --no-edit 45 | fi 46 | -------------------------------------------------------------------------------- /docs/contracts/interfaces.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! contract;interface, ! interface contract 2 | 3 | .. _interfaces: 4 | 5 | **************** 6 | インターフェース 7 | **************** 8 | 9 | インターフェースは、抽象コントラクトと似ていますが、いかなる関数も実装できません。 10 | さらに以下の制限があります。 11 | 12 | - 他のコントラクトを継承できませんが、他のインターフェースを継承できます。 13 | - 宣言された関数は、コントラクトでpublicであっても、インターフェースではexternalでなければなりません。 14 | - コンストラクタを宣言できません。 15 | - 状態変数を宣言できません。 16 | - モディファイアを宣言できません。 17 | 18 | これらの制限の一部は、将来解除される可能性があります。 19 | 20 | インターフェースは基本的にコントラクトABIが表現できる内容に限定されており、ABIとインターフェースの間の変換は情報を失うことなく可能でなければなりません。 21 | 22 | インターフェースは、次のように定義されます。 23 | 24 | .. code-block:: solidity 25 | 26 | // SPDX-License-Identifier: GPL-3.0 27 | pragma solidity >=0.6.2 <0.9.0; 28 | 29 | interface Token { 30 | enum TokenType { Fungible, NonFungible } 31 | struct Coin { string obverse; string reverse; } 32 | function transfer(address recipient, uint amount) external; 33 | } 34 | 35 | コントラクトは、他のコントラクトを継承するように、インターフェースを継承できます。 36 | 37 | .. All functions declared in interfaces are implicitly ``virtual`` and any 38 | .. functions that override them do not need the ``override`` keyword. 39 | .. This does not automatically mean that an overriding function can be overridden again - 40 | .. this is only possible if the overriding function is marked ``virtual``. 41 | 42 | インターフェースで宣言されたすべての関数は暗黙のうちに ``virtual`` となり、それをオーバーライドする関数には ``override`` キーワードは必要ありません。 43 | これは、オーバーライドされた関数が再びオーバーライドできることを自動的に意味するものではありません。 44 | オーバーライドされた関数が ``virtual`` とマークされている場合にのみ、それは可能です。 45 | 46 | インターフェースは、他のインターフェースを継承できます。 47 | これには通常の継承と同じルールがあります。 48 | 49 | .. code-block:: solidity 50 | 51 | // SPDX-License-Identifier: GPL-3.0 52 | pragma solidity >=0.6.2 <0.9.0; 53 | 54 | interface ParentA { 55 | function test() external returns (uint256); 56 | } 57 | 58 | interface ParentB { 59 | function test() external returns (uint256); 60 | } 61 | 62 | interface SubInterface is ParentA, ParentB { 63 | // Parentと互換性があることを主張するために、testを再定義する必要があります。 64 | function test() external override(ParentA, ParentB) returns (uint256); 65 | } 66 | 67 | .. Types defined inside interfaces and other contract-like structures 68 | .. can be accessed from other contracts: ``Token.TokenType`` or ``Token.Coin``. 69 | 70 | インターフェースや他のコントラクトに似た構造の中で定義された型は、他のコントラクトからアクセスできます。 71 | ``Token.TokenType`` または ``Token.Coin`` 。 72 | 73 | .. warning:: 74 | 75 | .. Interfaces have supported ``enum`` types since :doc:`Solidity version 0.5.0 <050-breaking-changes>`, make sure the pragma version specifies this version as a minimum. 76 | 77 | インターフェースは :doc:`Solidity version 0.5.0 <050-breaking-changes>` 以降 ``enum`` 型をサポートしています。 78 | プラグマバージョンが最低限このバージョンを指定していることを確認してください。 79 | -------------------------------------------------------------------------------- /docs/progress-checklist.md: -------------------------------------------------------------------------------- 1 | ## Translation Progress Checklist 2 | 3 | This document helps to track the state of your translation. Please copy it as an issue into your translation repo to track your progress. 4 | 5 | ### Maintainer List 6 | 7 | [List the maintainers here.] 8 | 9 | ### Information for New Translators 10 | 11 | To translate a page: 12 | 13 | Check that no one else has claimed your page in the checklist and comments below. 14 | Comment below with the name of the page you would like to translate. Please take only one page at a time. 15 | Clone this repo, translate your page, and submit a pull request! 16 | 17 | Before contributing, read the glossary and style guide (link them here if they exist) to understand how to translate various technical or Solidity/Ethereum-specific terms. 18 | 19 | Please be prompt with your translations! If you find that you can't commit anymore, let the maintainers know so they can assign the page to someone else. 20 | 21 | ### For Maintainers 22 | 23 | When someone likes to contribute, edit this issue with the username of the contributor, and with the PR. 24 | 25 | E.g. 26 | - [ ] index (@franzihei) #1 27 | 28 | When PRs are merged, make sure to mark that page as completed. 29 | 30 | ### Core Pages 31 | 32 | These pages need to be translated before the translation will be added as a new language to the Solidity docs flyout menu. Please translate these pages first. 33 | 34 | #### Basics 35 | - [ ] index 36 | - [ ] intro-to-smart-contracts 37 | - [ ] installing-solidity 38 | - [ ] solidity-by-example 39 | 40 | #### Language Description 41 | - [ ] layout-of-source-files 42 | - [ ] structure-of-a-contract 43 | - [ ] types 44 | - [ ] units-and-global-variables 45 | - [ ] control-structures 46 | - [ ] contracts 47 | - [ ] assembly 48 | - [ ] cheatsheet 49 | - [ ] grammar 50 | 51 | #### Internals 52 | - [ ] layout_in_storage 53 | - [ ] layout_in_memory 54 | - [ ] layout_in_calldata 55 | - [ ] variable_cleanup 56 | - [ ] source_mappings 57 | - [ ] optimiser 58 | - [ ] metadata 59 | - [ ] abi-spec 60 | 61 | #### Additional Material 62 | - [ ] yul 63 | - [ ] natspec-format 64 | - [ ] security-considerations 65 | - [ ] common-patterns 66 | 67 | ### Next Steps 68 | 69 | These are the next most important translations, ordered by importance: 70 | 71 | #### Additional Material 72 | 73 | - [ ] using-the-compiler 74 | - [ ] contributing 75 | - [ ] 080-breaking-changes 76 | - [ ] 070-breaking-changes 77 | - [ ] 060-breaking-changes 78 | - [ ] 050-breaking-changes 79 | - [ ] resources 80 | - [ ] bugs 81 | 82 | ### Additional Translations 83 | 84 | These are not the primary translation targets but still a nice to have! 85 | 86 | - [ ] style-guide 87 | - [ ] brand-guide 88 | 89 | 90 | _Credits: This doc is derived from the [Progress Template](https://github.com/reactjs/reactjs.org-translation/blob/master/PROGRESS.template.md) of the ReactJS Localization Team._ -------------------------------------------------------------------------------- /docs/contracts/abstract-contracts.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! contract;abstract, ! abstract contract 2 | 3 | .. _abstract-contract: 4 | 5 | **************** 6 | 抽象コントラクト 7 | **************** 8 | 9 | コントラクトは、その関数の少なくとも1つが実装されていない場合、またはすべてのベースコントラクトコンストラクタに引数を提供しない場合、abstractとマークする必要があります。 10 | そうでない場合でも、コントラクトを直接作成するつもりがない場合などには、コントラクトをabstractとマークすることがあります。 11 | 抽象コントラクトは :ref:`interfaces` と似ていますが、インターフェースは宣言できる内容がより限定されています。 12 | 13 | 抽象コントラクトは、次の例に示すように ``abstract`` キーワードを使用して宣言します。 14 | 関数 ``utterance()`` が宣言されているが、実装が提供されていない（実装本体 `{ }` が与えられていない）ため、このコントラクトは抽象として定義する必要があることに注意してください。 15 | 16 | .. code-block:: solidity 17 | 18 | // SPDX-License-Identifier: GPL-3.0 19 | pragma solidity >=0.6.0 <0.9.0; 20 | 21 | abstract contract Feline { 22 | function utterance() public virtual returns (bytes32); 23 | } 24 | 25 | .. Such abstract contracts can not be instantiated directly. 26 | .. This is also true, if an abstract contract itself does implement all defined functions. The usage of an abstract contract as a base class is shown in the following example: 27 | 28 | このような抽象コントラクトは、直接インスタンス化できません。 29 | これは、抽象コントラクト自体がすべての定義された関数を実装している場合にも当てはまります。 30 | ベースクラスとしての抽象コントラクトの使い方を以下の例で示します。 31 | 32 | .. code-block:: solidity 33 | 34 | // SPDX-License-Identifier: GPL-3.0 35 | pragma solidity >=0.6.0 <0.9.0; 36 | 37 | abstract contract Feline { 38 | function utterance() public pure virtual returns (bytes32); 39 | } 40 | 41 | contract Cat is Feline { 42 | function utterance() public pure override returns (bytes32) { return "miaow"; } 43 | } 44 | 45 | コントラクトが抽象コントラクトを継承し、オーバーライドによって未実装関数を全て実装していない場合は、抽象としてマークする必要があります。 46 | 47 | .. Note that a function without implementation is different from 48 | .. a :ref:`Function Type ` even though their syntax looks very similar. 49 | 50 | なお、実装のない関数は、構文がよく似ていても、 :ref:`関数型 ` とは異なるものです。 51 | 52 | 実装のない関数（関数宣言）の例: 53 | 54 | .. code-block:: solidity 55 | 56 | function foo(address) external returns (address); 57 | 58 | 型が関数型である変数の宣言の例: 59 | 60 | .. code-block:: solidity 61 | 62 | function(address) external returns (address) foo; 63 | 64 | .. Abstract contracts decouple the definition of a contract from its 65 | .. implementation providing better extensibility and self-documentation and 66 | .. facilitating patterns like the `Template method `_ and removing code duplication. 67 | .. Abstract contracts are useful in the same way that defining methods 68 | .. in an interface is useful. It is a way for the designer of the 69 | .. abstract contract to say "any child of mine must implement this method". 70 | 71 | 抽象コントラクトは、コントラクトの定義とその実装を切り離し、より良い拡張性と自己文書化を提供し、 `テンプレートメソッド `_ のようなパターンを促進し、コードの重複を取り除きます。 72 | 抽象コントラクトは、インターフェースでメソッドを定義することが有用であるのと同じ方法で有用です。 73 | 抽象コントラクトの設計者が「私の子供はこのメソッドを実装しなければならない」と言える方法です。 74 | 75 | .. note:: 76 | 77 | 抽象コントラクトは、実装済みの仮想関数を未実装の仮想関数で上書きできません。 78 | -------------------------------------------------------------------------------- /docs/ext/remix_code_links.py: -------------------------------------------------------------------------------- 1 | import base64 2 | import docutils # pragma pylint: disable=import-error 3 | 4 | from sphinx.util import logging # pragma pylint: disable=import-error 5 | 6 | # NOTE: 2000 should generally be safe for all browsers, while 8000 for most of them. 7 | MAX_SAFE_URL_LENGTH = 10000 8 | 9 | logger = logging.getLogger(__name__) 10 | 11 | 12 | def insert_node_before(child, new_sibling): 13 | assert child in child.parent.children 14 | 15 | for position, node in enumerate(child.parent.children): 16 | if node == child: 17 | child.parent.insert(position, new_sibling) 18 | break 19 | 20 | 21 | def remix_code_url(source_code, language, solidity_version): 22 | # NOTE: base64 encoded data may contain +, = and / characters. Remix seems to handle them just 23 | # fine without any escaping. 24 | base64_encoded_source = base64.b64encode(source_code.encode('utf-8')).decode('ascii') 25 | return f"https://remix.ethereum.org/?#language={language}&version={solidity_version}&code={base64_encoded_source}" 26 | 27 | 28 | def build_remix_link_node(url): 29 | reference_node = docutils.nodes.reference('', 'open in Remix', internal=False, refuri=url, target='_blank') 30 | reference_node['classes'].append('remix-link') 31 | 32 | paragraph_node = docutils.nodes.paragraph() 33 | paragraph_node['classes'].append('remix-link-container') 34 | paragraph_node.append(reference_node) 35 | return paragraph_node 36 | 37 | 38 | def insert_remix_link(app, doctree, solidity_version): 39 | if app.builder.format != 'html' or app.builder.name == 'epub': 40 | return 41 | 42 | for literal_block_node in doctree.traverse(docutils.nodes.literal_block): 43 | assert 'language' in literal_block_node.attributes 44 | language = literal_block_node.attributes['language'].lower() 45 | if language not in ['solidity', 'yul']: 46 | continue 47 | 48 | text_nodes = list(literal_block_node.traverse(docutils.nodes.Text)) 49 | assert len(text_nodes) == 1 50 | 51 | remix_url = remix_code_url(text_nodes[0], language, solidity_version) 52 | url_length = len(remix_url.encode('utf-8')) 53 | if url_length > MAX_SAFE_URL_LENGTH: 54 | logger.warning( 55 | "Remix URL generated from the code snippet exceeds the maximum safe URL length " 56 | " (%d > %d bytes).", 57 | url_length, 58 | MAX_SAFE_URL_LENGTH, 59 | location=(literal_block_node.source, literal_block_node.line), 60 | ) 61 | 62 | insert_node_before(literal_block_node, build_remix_link_node(remix_url)) 63 | 64 | 65 | def setup(app): 66 | # NOTE: Need to access _raw_config here because setup() runs before app.config is ready. 67 | solidity_version = app.config._raw_config['version'] # pylint: disable=protected-access 68 | 69 | app.connect( 70 | 'doctree-resolved', 71 | lambda app, doctree, docname: insert_remix_link(app, doctree, solidity_version) 72 | ) 73 | 74 | return { 75 | 'version': solidity_version, 76 | 'parallel_read_safe': True, 77 | 'parallel_write_safe': True, 78 | } 79 | -------------------------------------------------------------------------------- /docs/internals/layout_in_memory.rst: -------------------------------------------------------------------------------- 1 | 2 | .. index: memory layout 3 | 4 | ******************** 5 | メモリ内のレイアウト 6 | ******************** 7 | 8 | .. Solidity reserves four 32-byte slots, with specific byte ranges (inclusive of endpoints) being used as follows: 9 | .. - ``0x00`` - ``0x3f`` (64 bytes): scratch space for hashing methods 10 | .. - ``0x40`` - ``0x5f`` (32 bytes): currently allocated memory size (aka. free memory pointer) 11 | .. - ``0x60`` - ``0x7f`` (32 bytes): zero slot 12 | 13 | Solidityは4つの32バイトスロットを確保しており、特定のバイト範囲（エンドポイントを含む）は以下のように使用されます。 14 | 15 | - ``0x00`` - ``0x3f`` （64バイト）: ハッシュ化のためのスクラッチ領域 16 | 17 | - ``0x40`` - ``0x5f`` （32バイト）: 現在割り当てられているメモリサイズ（別名: フリーメモリポインタ） 18 | 19 | - ``0x60`` - ``0x7f`` （32バイト）: ゼロスロット 20 | 21 | .. Scratch space can be used between statements (i.e. within inline assembly). 22 | .. The zero slot is used as initial value for dynamic memory arrays and should never be written to (the free memory pointer points to ``0x80`` initially). 23 | 24 | スクラッチ領域は、文の間（インラインアセンブリ内）で使用できます。 25 | ゼロスロットは、動的メモリ配列の初期値として使用され、決して書き込まれてはいけません（フリーメモリポインタは初期値として ``0x80`` を指します）。 26 | 27 | .. Solidity always places new objects at the free memory pointer and 28 | .. memory is never freed (this might change in the future). 29 | 30 | Solidityは常に新しいオブジェクトをフリーメモリポインタに配置し、メモリは解放されません（これは将来変更されるかもしれません）。 31 | 32 | .. Elements in memory arrays in Solidity always occupy multiples of 32 bytes (this 33 | .. is even true for ``bytes1[]``, but not for ``bytes`` and ``string``). 34 | .. Multi-dimensional memory arrays are pointers to memory arrays. The length of a 35 | .. dynamic array is stored at the first slot of the array and followed by the array 36 | .. elements. 37 | 38 | Solidityのメモリ配列の要素は、常に32バイトの倍数を占めています（これは ``bytes1[]`` でも当てはまりますが、 ``bytes`` と ``string`` では当てはまりません）。 39 | 多次元のメモリ配列は、メモリ配列へのポインタです。 40 | 動的配列の長さは、配列の最初のスロットに格納され、その後に配列要素が続きます。 41 | 42 | .. .. warning:: 43 | 44 | .. There are some operations in Solidity that need a temporary memory area 45 | .. larger than 64 bytes and therefore will not fit into the scratch space. 46 | .. They will be placed where the free memory points to, but given their 47 | .. short lifetime, the pointer is not updated. The memory may or may not 48 | .. be zeroed out. Because of this, one should not expect the free memory 49 | .. to point to zeroed out memory. 50 | 51 | .. While it may seem like a good idea to use ``msize`` to arrive at a 52 | .. definitely zeroed out memory area, using such a pointer non-temporarily 53 | .. without updating the free memory pointer can have unexpected results. 54 | 55 | .. warning:: 56 | 57 | Solidityには、64バイト以上の一時的なメモリ領域を必要とする操作があり、そのためスクラッチ領域には収まりません。 58 | これらはフリーメモリが指す場所に配置されますが、その寿命が短いため、ポインタは更新されません。 59 | メモリはゼロになってもならなくても構いません。 60 | このため、フリーメモリがゼロアウトされたメモリを指していると思ってはいけません。 61 | 62 | 確実にゼロになったメモリ領域に到達するために ``msize`` を使用するのは良いアイデアに思えるかもしれませんが、空きメモリポインタを更新せずにそのようなポインタを非一時的に使用すると、予期しない結果になることがあります。 63 | 64 | ストレージ内のレイアウトとの違い 65 | ================================ 66 | 67 | 以上のように、メモリ上のレイアウトと :ref:`ストレージ` 上のレイアウトは異なります。 68 | 以下、いくつかの例を紹介します。 69 | 70 | 配列における違いの例 71 | -------------------- 72 | 73 | 次の配列は、ストレージでは32バイト（1スロット）ですが、メモリでは128バイト（32バイトずつの4つのアイテム）を占有します。 74 | 75 | .. code-block:: solidity 76 | 77 | uint8[4] a; 78 | 79 | 構造体レイアウトにおける違いの例 80 | -------------------------------- 81 | 82 | 次の構造体は、ストレージでは96バイト（32バイトのスロットが3つ）ですが、メモリでは128バイト（32バイトずつのアイテムが4つ）を占有します。 83 | 84 | .. code-block:: solidity 85 | 86 | struct S { 87 | uint a; 88 | uint b; 89 | uint8 c; 90 | uint8 d; 91 | } 92 | 93 | -------------------------------------------------------------------------------- /docs/contracts/custom-storage-layout.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! custom storage layout, ! storage layout specifier, ! layout at, ! base slot 2 | 3 | .. _custom-storage-layout: 4 | 5 | **************************** 6 | カスタムストレージレイアウト 7 | **************************** 8 | 9 | .. A contract can define an arbitrary location for its storage using the ``layout`` specifier. 10 | .. The contract's state variables, including those inherited from base contracts, start from the specified base slot instead of the default slot zero. 11 | 12 | コントラクトは ``layout`` 指定子を使って、ストレージの開始位置を任意に定義できます。 13 | この場合、基底コントラクトから継承された変数を含む状態変数は、デフォルトのスロット 0 ではなく、指定されたベーススロットから配置されます。 14 | 15 | .. code-block:: solidity 16 | 17 | // SPDX-License-Identifier: GPL-3.0 18 | pragma solidity ^0.8.29; 19 | 20 | contract C layout at 0xAAAA + 0x11 { 21 | uint[3] x; // Occupies slots 0xAABB..0xAABD 22 | } 23 | 24 | .. As the above example shows, the specifier uses the ``layout at `` syntax and is located in the header of a contract definition. 25 | 26 | 上の例に示されているように、この指定子は ``layout at `` という構文を使用し、 27 | コントラクト定義のヘッダー部分に記述されます。 28 | 29 | .. The layout specifier can be placed either before or after the inheritance specifier, and can appear at most once. 30 | .. The ``base-slot-expression`` must be an :ref:`integer literal` expression that can be evaluated at compilation time and yields a value in the range of ``uint256``. 31 | 32 | layout 指定子は、継承指定子の前でも後でも記述可能で、1つのコントラクトにつき1回までしか使用できません。 33 | ``base-slot-expression`` は、コンパイル時に評価可能な :ref:`整数リテラル` 式である必要があり、 34 | その値は ``uint256`` の範囲内でなければなりません。 35 | 36 | .. A custom layout cannot make contract's storage "wrap around". 37 | .. If the selected base slot would push the static variables past the end of storage, the compiler will issue an error. 38 | .. Note that the data areas of dynamic arrays and mappings are not affected by this check because their layout is not linear. 39 | .. Regardless of the base slot used, their locations are calculated in a way that always puts them within the range of ``uint256`` and their sizes are not known at compilation time. 40 | 41 | カスタムレイアウトを使用しても、コントラクトのストレージが「ラップアラウンド（末尾から先頭へ巻き戻る）」することはできません。 42 | もし指定されたベーススロットによって、静的変数がストレージの末尾を超えることになる場合、コンパイラはエラーを出力します。 43 | なお、動的配列やマッピングのデータ領域は線形なレイアウトを持たないため、このチェックの対象外となります。 44 | 使用するベーススロットに関係なく、それらの位置は ``uint256`` の範囲内に収まるように計算され、 45 | またそのサイズはコンパイル時には不明です。 46 | 47 | .. While there are no other limits placed on the base slot, it is recommended to avoid locations that are too close to the end of the address space. 48 | .. Leaving too little space may complicate contract upgrades or cause problems for contracts that store additional values past their allocated space using inline assembly. 49 | 50 | ベーススロットに対して他の制限はありませんが、アドレス空間の末尾に近すぎる位置は避けることが推奨されます。 51 | 残されたスペースが少なすぎると、コントラクトのアップグレードが難しくなったり、 52 | インラインアセンブリで割り当て領域を超えて値を保存するようなコントラクトで問題が発生する可能性があります。 53 | 54 | .. The storage layout can only be specified for the topmost contract of an inheritance tree, and affects locations of all the storage variables in all the contracts in that tree. 55 | .. Variables are laid out according to the order of their definitions and the positions of their contracts in the :ref:`linearized inheritance hierarchy` and a custom base slot preserves their relative positions, shifting them all by the same amount. 56 | 57 | ストレージレイアウトは、継承ツリーの最上位のコントラクトに対してのみ指定でき、 58 | そのツリー内にあるすべてのコントラクトのストレージ変数の位置に影響を与えます。 59 | 変数は、定義された順番とコントラクトの :ref:`線形化された継承階層` に従って配置され、 60 | カスタムベーススロットを指定した場合でも、それらの相対位置は保たれ、すべて同じ量だけシフトされます。 61 | 62 | .. The storage layout cannot be specified for abstract contracts, interfaces and libraries. 63 | .. Also, it is important to note that it does *not* affect transient state variables. 64 | 65 | ストレージレイアウトは、抽象コントラクト、インターフェース、およびライブラリには指定できません。 66 | また、この指定はトランジェント状態変数には *影響を与えない* ことにも注意が必要です。 67 | 68 | .. For details about storage layout and the effect of the layout specifier on it see 69 | .. :ref:`layout of storage variables`. 70 | 71 | ストレージレイアウトの詳細や、layout 指定子がそれに与える影響については 72 | :ref:`ストレージ変数のレイアウト` を参照してください。 73 | 74 | .. warning:: 75 | .. The identifiers ``layout`` and ``at`` are not yet reserved as keywords in the language. 76 | .. It is strongly recommended to avoid using them since they will become reserved in a future 77 | .. breaking release. 78 | 79 | 識別子 ``layout`` および ``at`` は、現時点ではまだ言語の予約語ではありません。 80 | しかし、将来の後方互換性を破るリリースにおいて予約語となる予定のため、これらを使用しないことが強く推奨されます。 81 | -------------------------------------------------------------------------------- /docs/contracts/creating-contracts.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! contract;creation, constructor 2 | 3 | ****************** 4 | コントラクトの作成 5 | ****************** 6 | 7 | コントラクトは、Ethereumのトランザクションを介して「外部から」作成することも、Solidityのコントラクトから作成することもできます。 8 | 9 | `Remix `_ に代表されるIDEは、UIによって作成プロセスをシームレスにします。 10 | 11 | Ethereumでプログラマティックにコントラクトを作成する方法の一つとして、JavaScript APIの `web3.js `_ があります。 12 | これにはコントラクトの作成を容易にする `web3.eth.Contract `_ という関数があります。 13 | 14 | コントラクトが作成されると、その :ref:`コンストラクタ ` （ ``constructor`` キーワードで宣言された関数）が一度だけ実行されます。 15 | 16 | コンストラクタはオプションです。 17 | ココンストラクタは1つしか許可されていないので、オーバーロードはサポートされていません。 18 | 19 | .. After the constructor has executed, the final code of the contract is stored on the 20 | .. blockchain. This code includes all public and external functions and all functions 21 | .. that are reachable from there through function calls. The deployed code does not 22 | .. include the constructor code or internal functions only called from the constructor. 23 | 24 | コンストラクタが実行された後、コントラクトの最終コードがブロックチェーンに保存されます。 25 | このコードには、すべてのパブリック関数と外部関数、および関数呼び出しによってそこから到達可能なすべての関数が含まれます。 26 | デプロイされたコードには、コンストラクタのコードや、コンストラクタからのみ呼び出される内部関数は含まれません。 27 | 28 | .. index:: constructor;arguments 29 | 30 | .. Internally, constructor arguments are passed :ref:`ABI encoded ` after the code of 31 | .. the contract itself, but you do not have to care about this if you use ``web3.js``. 32 | 33 | 内部的にはコンストラクタの引数はコントラクト自体のコードの後に :ref:`ABIエンコード ` を渡していますが、 ``web3.js`` を使用する場合はこれを気にする必要はありません。 34 | 35 | あるコントラクトが別のコントラクトを作成したい場合、作成するコントラクトのソースコード（およびバイナリ）を作成者が知っていなければなりません。 36 | これは周期的な作成の依存関係は不可能であることを意味します。 37 | 38 | .. code-block:: solidity 39 | 40 | // SPDX-License-Identifier: GPL-3.0 41 | pragma solidity >=0.4.22 <0.9.0; 42 | 43 | contract OwnedToken { 44 | // `TokenCreator` は、以下で定義されるコントラクトの型です。 45 | // 新しいコントラクトを作成するために使用しない限り、これを参照することは問題ありません。 46 | TokenCreator creator; 47 | address owner; 48 | bytes32 name; 49 | 50 | // 作成者と割り当てられた名前を登録するコンストラクタです。 51 | constructor(bytes32 name_) { 52 | // 状態変数には、その名前を通してアクセスします（`this.owner` などではない）。 53 | // 関数には、直接アクセスすることも、 `this.f` を介してアクセスすることもできますが、後者は関数への外部からのアクセスを提供します。 54 | // 特にコンストラクタでは、まだ関数が存在しないので、外部から関数にアクセスするべきではありません。 55 | // 詳しくは次のセクションを参照してください。 56 | owner = msg.sender; 57 | 58 | // `address` から `TokenCreator` への明示的な型変換を行い、 59 | // 呼び出したコントラクトの型が `TokenCreator` であることを仮定していますが、 60 | // 実際にそれを確認する方法はありません。 61 | // これは新しいコントラクトを作成するわけではありません。 62 | creator = TokenCreator(msg.sender); 63 | name = name_; 64 | } 65 | 66 | function changeName(bytes32 newName) public { 67 | // 作成者のみが名称を変更できます。 68 | // コントラクトの比較は、アドレスに明示的に変換することで取得できるアドレスをもとに行う。 69 | if (msg.sender == address(creator)) 70 | name = newName; 71 | } 72 | 73 | function transfer(address newOwner) public { 74 | // トークンを送信できるのは、現在の所有者のみです。 75 | if (msg.sender != owner) return; 76 | 77 | // 以下に定義する `TokenCreator` コントラクトの関数を用いて、送金を進めるべきかどうかを作成者コントラクトに問い合わせます。 78 | // 呼び出しに失敗した場合（ガス欠など）、ここでの実行も失敗します。 79 | if (creator.isTokenTransferOK(owner, newOwner)) 80 | owner = newOwner; 81 | } 82 | } 83 | 84 | contract TokenCreator { 85 | function createToken(bytes32 name) 86 | public 87 | returns (OwnedToken tokenAddress) 88 | { 89 | // 新しい `Token` コントラクトを作成し、そのアドレスを返す。 90 | // JavaScript側から見ると、この関数の戻り値の型は `address` です。 91 | // これはABIで利用可能な最も近い型だからです。 92 | return new OwnedToken(name); 93 | } 94 | 95 | function changeName(OwnedToken tokenAddress, bytes32 name) public { 96 | // ここでも、`tokenAddress` の外部型は単純に `address` です。 97 | tokenAddress.changeName(name); 98 | } 99 | 100 | // `OwnedToken`コントラクトにトークンを送信するかどうかのチェックを行う。 101 | function isTokenTransferOK(address currentOwner, address newOwner) 102 | public 103 | pure 104 | returns (bool ok) 105 | { 106 | // 送金を進めるかどうか、任意の条件をチェックします。 107 | return keccak256(abi.encodePacked(currentOwner, newOwner))[0] == 0x7f; 108 | } 109 | } 110 | 111 | -------------------------------------------------------------------------------- /docs/examples/safe-remote.rst: -------------------------------------------------------------------------------- 1 | .. index:: purchase, remote purchase, escrow 2 | 3 | ****************** 4 | 安全なリモート購入 5 | ****************** 6 | 7 | 現在、遠隔地で商品を購入するには、複数の当事者がお互いに信頼し合う必要があります。 8 | 最もシンプルなのは、売り手と買い手の関係です。 9 | 買い手は売り手から商品を受け取り、売り手はその見返りとして対価（例えばEther）を得たいと考えます。 10 | 問題となるのは、ここでの発送です。 11 | 商品が買い手に届いたかどうかを確実に判断する方法がありません。 12 | 13 | この問題を解決するには複数の方法がありますが、いずれも1つまたは他の方法で不足しています。 14 | 次の例では、両当事者がアイテムの2倍の価値をエスクローとして コントラクトに入れなければなりません。 15 | これが起こるとすぐに、買い手がアイテムを受け取ったことを確認するまで、Etherはコントラクトの中にロックされたままになります。 16 | その後、買い手にはvalue（デポジットの半分）が返却され、売り手にはvalueの3倍（デポジット + value）が支払われます。 17 | これは、双方が事態を解決しようとするインセンティブを持ち、そうしないとEtherが永遠にロックされてしまうという考えに基づいています。 18 | 19 | このコントラクトはもちろん問題を解決するものではありませんが、コントラクトの中でステートマシンのような構造をどのように使用できるかの概要を示しています。 20 | 21 | .. code-block:: solidity 22 | 23 | // SPDX-License-Identifier: GPL-3.0 24 | pragma solidity ^0.8.4; 25 | contract Purchase { 26 | uint public value; 27 | address payable public seller; 28 | address payable public buyer; 29 | 30 | enum State { Created, Locked, Release, Inactive } 31 | // state変数のデフォルト値は、最初のメンバーである`State.created`です。 32 | State public state; 33 | 34 | modifier condition(bool condition_) { 35 | require(condition_); 36 | _; 37 | } 38 | 39 | /// 買い手だけがこの機能を呼び出すことができます。 40 | error OnlyBuyer(); 41 | /// 売り手だけがこの機能を呼び出すことができます。 42 | error OnlySeller(); 43 | /// 現在の状態では、この関数を呼び出すことはできません。 44 | error InvalidState(); 45 | /// 提供される値は偶数でなければなりません。 46 | error ValueNotEven(); 47 | 48 | modifier onlyBuyer() { 49 | if (msg.sender != buyer) 50 | revert OnlyBuyer(); 51 | _; 52 | } 53 | 54 | modifier onlySeller() { 55 | if (msg.sender != seller) 56 | revert OnlySeller(); 57 | _; 58 | } 59 | 60 | modifier inState(State state_) { 61 | if (state != state_) 62 | revert InvalidState(); 63 | _; 64 | } 65 | 66 | event Aborted(); 67 | event PurchaseConfirmed(); 68 | event ItemReceived(); 69 | event SellerRefunded(); 70 | 71 | // `msg.value` が偶数であることを確認します。 72 | // 割り算は奇数だと切り捨てられます。 73 | // 奇数でなかったことを乗算で確認します。 74 | constructor() payable { 75 | seller = payable(msg.sender); 76 | value = msg.value / 2; 77 | if ((2 * value) != msg.value) 78 | revert ValueNotEven(); 79 | } 80 | 81 | /// 購入を中止し、Etherを再クレームします。 82 | /// コントラクトがロックされる前に売り手によってのみ呼び出すことができます。 83 | function abort() 84 | external 85 | onlySeller 86 | inState(State.Created) 87 | { 88 | emit Aborted(); 89 | state = State.Inactive; 90 | // ここではtransferを直接使っています。 91 | // この関数の最後のコールであり、すでに状態を変更しているため、reentrancy-safeになっています。 92 | seller.transfer(address(this).balance); 93 | } 94 | 95 | /// 買い手として購入を確認します。 96 | /// 取引には `2 * value` のEtherが含まれていなければなりません。 97 | /// EtherはconfirmReceivedが呼ばれるまでロックされます。 98 | function confirmPurchase() 99 | external 100 | inState(State.Created) 101 | condition(msg.value == (2 * value)) 102 | payable 103 | { 104 | emit PurchaseConfirmed(); 105 | buyer = payable(msg.sender); 106 | state = State.Locked; 107 | } 108 | 109 | /// あなた（買い手）が商品を受け取ったことを確認します。 110 | /// これにより、ロックされていたEtherが解除されます。 111 | function confirmReceived() 112 | external 113 | onlyBuyer 114 | inState(State.Locked) 115 | { 116 | emit ItemReceived(); 117 | // 最初に状態を変更することが重要です。 118 | // そうしないと、以下の `send` を使用して呼び出されたコントラクトが、ここで再び呼び出される可能性があるからです。 119 | state = State.Release; 120 | 121 | buyer.transfer(value); 122 | } 123 | 124 | /// この機能は、売り手に返金する、つまり売り手のロックされた資金を払い戻すものです。 125 | function refundSeller() 126 | external 127 | onlySeller 128 | inState(State.Release) 129 | { 130 | emit SellerRefunded(); 131 | // otherwise, the contracts called using `send` below 132 | // can call in again here. 133 | // 最初に状態を変更することが重要です。 134 | // そうしないと、以下の `send` を使用して呼び出されたコントラクトが、ここで再び呼び出される可能性があるからです。 135 | state = State.Inactive; 136 | 137 | seller.transfer(3 * value); 138 | } 139 | } 140 | 141 | -------------------------------------------------------------------------------- /docs/internals/variable_cleanup.rst: -------------------------------------------------------------------------------- 1 | .. index: variable cleanup 2 | 3 | ******************** 4 | 変数のクリーンアップ 5 | ******************** 6 | 7 | .. Ultimately, all values in the EVM are stored in 256 bit words. 8 | .. Thus, in some cases, when the type of a value has less than 256 bits, it is necessary to clean the remaining bits. 9 | .. The Solidity compiler is designed to do such cleaning before any operations 10 | .. that might be adversely affected by the potential garbage in the remaining bits. 11 | .. For example, before writing a value to memory, the remaining bits need 12 | .. to be cleared because the memory contents can be used for computing 13 | .. hashes or sent as the data of a message call. Similarly, before 14 | .. storing a value in the storage, the remaining bits need to be cleaned 15 | .. because otherwise the garbled value can be observed. 16 | 17 | 値が256ビットよりも短い場合、場合によっては残りのビットをクリーンアップする必要があります。 18 | 最終的に、EVM内のすべての値は256ビットのワードで保存されます。 19 | したがって、値の型が256ビット未満である場合、残りのビットをクリーニングする必要があるケースがあります。 20 | Solidityのコンパイラは、残りのビットに含まれる潜在的なゴミによって悪影響を受ける可能性のある演算の前に、このようなクリーニングを行うように設計されています。 21 | 22 | 例えば、値をメモリに書き込む前に、残りのビットをクリアする必要があります。 23 | これは、メモリの内容がハッシュの計算に使用されたり、メッセージコールのデータとして送信されたりする可能性があるためです。 24 | 同様に、ストレージに値を格納する前に、残りのビットを消去する必要があります。 25 | そうしないと、文字化けした値が観測される可能性があるからです。 26 | 27 | .. Note that access via inline assembly is not considered such an operation: 28 | .. If you use inline assembly to access Solidity variables 29 | .. shorter than 256 bits, the compiler does not guarantee that 30 | .. the value is properly cleaned up. 31 | 32 | なお、インラインアセンブリによるアクセスはそのような操作とはみなされません。 33 | インラインアセンブリを使用して256ビットより短いSolidity変数にアクセスした場合、コンパイラは値が適切にクリーンアップされることを保証しません。 34 | 35 | .. Moreover, we do not clean the bits if the immediately 36 | .. following operation is not affected. For instance, since any non-zero 37 | .. value is considered ``true`` by ``JUMPI`` instruction, we do not clean 38 | .. the boolean values before they are used as the condition for 39 | .. ``JUMPI``. 40 | 41 | また、直後の演算に影響がない場合は、ビットのクリーニングは行いません。 42 | 例えば、 ``JUMPI`` 命令では0以外の値は ``true`` とみなされるので、 ``JUMPI`` の条件として使われる前のブーリアン値のクリーニングは行いません。 43 | 44 | .. In addition to the design principle above, the Solidity compiler 45 | .. cleans input data when it is loaded onto the stack. 46 | 47 | 上記の設計原理に加えて、Solidityのコンパイラは、入力データがスタックに読み込まれる際に、入力データをクリーニングします。 48 | 49 | .. The following table describes the cleaning rules applied to different types, where ``higher bits`` refers to the remaining bits in case the type has less than 256 bits. 50 | 51 | 次の表は、異なるタイプに適用されるクリーニングルールを説明するもので、 ``higher bits`` は、タイプが256ビット未満の場合の残りのビットを指します。 52 | 53 | .. csv-table:: 54 | :header: "型", "有効な値", "無効な値のクリーンアップ" 55 | :widths: 10, 10, 30 56 | 57 | "n個のメンバーのenum", "0 から n-1", "例外を投げる" 58 | "bool", "0 あるいは 1", "1になる" 59 | "符号付き整数", "higher bits set to the sign bit", "currently silently signextends to a valid value, i.e. all higher bits are set to the sign bit; may throw an exception in the future" 60 | "符号なし整数", "上位ビットがゼロ", "currently silently masks to a valid value, i.e. all higher bits are set to zero; may throw an exception in the future" 61 | 62 | .. Note that valid and invalid values are dependent on their type size. 63 | .. Consider ``uint8``, the unsigned 8-bit type, which has the following valid values: 64 | 65 | 有効な値と無効な値は、その型サイズに依存することに注意してください。 66 | 符号なし8ビット型である ``uint8`` を考えてみると、次のような有効な値があります: 67 | 68 | .. code-block:: none 69 | 70 | 0000...0000 0000 0000 71 | 0000...0000 0000 0001 72 | 0000...0000 0000 0010 73 | .... 74 | 0000...0000 1111 1111 75 | 76 | .. Any invalid value will have the higher bits set to zero: 77 | 78 | 無効な値は、上位ビットが0に設定されます: 79 | 80 | .. code-block:: none 81 | 82 | 0101...1101 0010 1010 invalid value 83 | 0000...0000 0010 1010 cleaned value 84 | 85 | .. For ``int8``, the signed 8-bit type, the valid values are: 86 | 87 | 符号付き8ビット型である ``int8`` の場合、有効な値は次のとおりです: 88 | 89 | Negative 90 | 91 | .. code-block:: none 92 | 93 | 1111...1111 1111 1111 94 | 1111...1111 1111 1110 95 | .... 96 | 1111...1111 1000 0000 97 | 98 | Positive 99 | 100 | .. code-block:: none 101 | 102 | 0000...0000 0000 0000 103 | 0000...0000 0000 0001 104 | 0000...0000 0000 0010 105 | .... 106 | 0000...0000 1111 1111 107 | 108 | .. The compiler will ``signextend`` the sign bit, which is 1 for negative and 0 for positive values, overwriting the higher bits: 109 | 110 | コンパイラは符号ビットを ``signextend`` します。 111 | 符号ビットは負の値を1、正の値を0とし、上位ビットを上書きします: 112 | 113 | Negative 114 | 115 | .. code-block:: none 116 | 117 | 0010...1010 1111 1111 invalid value 118 | 1111...1111 1111 1111 cleaned value 119 | 120 | Positive 121 | 122 | .. code-block:: none 123 | 124 | 1101...0101 0000 0100 invalid value 125 | 0000...0000 0000 0100 cleaned value 126 | -------------------------------------------------------------------------------- /.github/workflows/create-weekly-docs-sync-pr.yaml: -------------------------------------------------------------------------------- 1 | name: weekly docs sync PR 2 | 3 | on: 4 | schedule: 5 | # Runs "at minute 44 past midnight on Mondays" 6 | - cron: "44 0 * * 1" 7 | workflow_dispatch: 8 | 9 | env: 10 | BOT_USERNAME: soldocsbot 11 | BOT_EMAIL: solidity-docs-translations@ethereum.org 12 | GITHUB_REPOSITORY_OWNER: solidity-docs 13 | 14 | jobs: 15 | createPullRequest: 16 | runs-on: ubuntu-latest 17 | permissions: 18 | contents: write 19 | pull-requests: write 20 | steps: 21 | - name: Fetch translation repository 22 | uses: actions/checkout@v2 23 | with: 24 | token: ${{ secrets.GITHUB_TOKEN }} 25 | repository: ${{ env.GITHUB_REPOSITORY_OWNER }}/ja-japanese 26 | # By default, checkout is fetching only the last commit. This will 27 | # cause "unrelated histories" error. "0" means unlimited fetch-depth. 28 | fetch-depth: 0 29 | # This is the working copy we'll prepare the sync PR in. 30 | path: translation/ 31 | 32 | - name: Configure translation repository 33 | run: | 34 | cd translation/ 35 | git config user.name "$BOT_USERNAME" 36 | git config user.email "$BOT_EMAIL" 37 | git remote add english "https://github.com/ethereum/solidity.git" 38 | git fetch english develop 39 | 40 | - name: Fetch main Solidity repository 41 | uses: actions/checkout@v2 42 | with: 43 | repository: ethereum/solidity 44 | fetch-depth: 0 45 | # This is the checkout where we can safely fetch the tags from the main Soldity repo and use git describe. 46 | # Translation repositories have their own version tags that conflict with the ones in the main repo. 47 | path: solidity/ 48 | 49 | - name: Fetch bot's repository 50 | uses: actions/checkout@v2 51 | with: 52 | token: ${{ secrets.GITHUB_TOKEN }} 53 | repository: ${{ github.repository }} 54 | path: bot/ 55 | 56 | - name: Load bot configuration from translation-bot.json in the translation repository 57 | id: bot-config 58 | run: | 59 | bot/.github/scripts/load-translation-bot-config.sh translation/translation-bot.json 60 | 61 | - name: Prepare pull request title and description 62 | if: ${{ steps.bot-config.outputs.bot_disabled == 'false' }} 63 | run: | 64 | # Use the main repository checkout with tags to get them in `git describe` output. 65 | cd solidity/ 66 | ../bot/.github/scripts/generate-pr-body.sh 67 | 68 | - name: Check if sync branch already exists 69 | id: check-sync-branch 70 | if: ${{ steps.bot-config.outputs.bot_disabled == 'false' }} 71 | run: | 72 | pushd solidity/ 73 | sync_branch="sync-$(git describe --tags --always develop)" 74 | echo "branch_name=$sync_branch" >> "$GITHUB_OUTPUT" 75 | popd 76 | 77 | cd translation/ 78 | ../bot/.github/scripts/check-remote-branch.sh "$sync_branch" 79 | 80 | - name: Prepare pull request content 81 | if: ${{ steps.bot-config.outputs.bot_disabled == 'false' && steps.check-sync-branch.outputs.branch_exists == 'false' }} 82 | run: | 83 | cd translation/ 84 | 85 | # NOTE: The script will end up not creating a merge commit if there are no new upstream changes. 86 | # In that case we expect that the PR action will simply not create a PR. 87 | ../bot/.github/scripts/pull-and-resolve-english-changes.sh english/develop "$pr_title" 88 | 89 | if [[ ${{ steps.bot-config.outputs.randomly_assign_maintainers }} == 'true' ]]; then 90 | ../bot/.github/scripts/set-assignees.sh "ja-japanese" 91 | fi 92 | 93 | - name: Remove this repository 94 | if: ${{ steps.bot-config.outputs.bot_disabled == 'false' && steps.check-sync-branch.outputs.branch_exists == 'false' }} 95 | run: | 96 | rm -rf bot/ 97 | 98 | - name: Create Pull Request 99 | if: ${{ steps.bot-config.outputs.bot_disabled == 'false' && steps.check-sync-branch.outputs.branch_exists == 'false' }} 100 | uses: peter-evans/create-pull-request@v3 101 | with: 102 | path: translation/ 103 | token: "${{ secrets.GITHUB_TOKEN }}" 104 | commit-message: "${{ env.pr_title }}" 105 | committer: "${{ env.BOT_USERNAME }} <${{ env.BOT_EMAIL }}>" 106 | author: "${{ env.BOT_USERNAME }} <${{ env.BOT_EMAIL }}>" 107 | branch: "${{ steps.check-sync-branch.outputs.branch_name }}" 108 | title: "${{ env.pr_title }}" 109 | body: "${{ env.pr_body }}" 110 | labels: "${{ join(fromJSON(steps.bot-config.outputs.pr_labels)) }}" 111 | assignees: ${{ env.assignee }} 112 | reviewers: ${{ env.reviewer }} 113 | -------------------------------------------------------------------------------- /.github/scripts/generate-pr-body.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -euo pipefail 3 | 4 | function modified_file_list { 5 | commit_hash=$(git rev-parse --verify develop) 6 | git status --short | 7 | grep "docs" | 8 | awk '{print "- [ ] ["$2"](https://github.com/ethereum/solidity/tree/'"${commit_hash}"'/"$2")"}' 9 | } 10 | 11 | function today_utc { 12 | date --utc +%Y-%m-%d 13 | } 14 | 15 | function sync_commit_human_readable_id { 16 | git describe --tags --always develop 17 | } 18 | 19 | function sync_commit_link { 20 | local commit_hash truncated_commit_hash 21 | commit_hash=$(git rev-parse --verify develop) 22 | truncated_commit_hash=$(echo "$commit_hash" | head -c 8) 23 | 24 | echo "[${truncated_commit_hash}](https://github.com/ethereum/solidity/tree/${commit_hash})" 25 | } 26 | 27 | function title { 28 | echo "English documentation updates up to $(sync_commit_human_readable_id) ($(today_utc))" 29 | } 30 | 31 | # shellcheck disable=SC2016 # Any Backticks here are markdown syntax not Bash expressions 32 | function pr_body { 33 | echo "This is an automatically-generated sync PR to bring this translation repository up to date with the state of the English documentation as of $(today_utc) (commit $(sync_commit_link))." 34 | echo 35 | echo "### How to work on a sync PR" 36 | echo "#### Resolve conflicts and translate newly added text" 37 | echo "- The PR includes all documentation changes from the main repository since the last time a sync PR was merged. " \ 38 | "If this translation repository is fully caught up with the English version, translate any newly added English text you see here by pushing more commits to the PR. " \ 39 | "However, if the translation is incomplete, you may prefer to leave the text added in this PR and add it to your translation checklist to handle at a later time." 40 | echo "- Scan the PR for merge conflict markers. " \ 41 | "If there were changes in the English text that has already been translated, the PR will contain merge conflicts that need to be resolved:" 42 | echo ' ```diff' 43 | echo ' <<<<<<< HEAD' 44 | echo ' El valor más grande representable por el tipo ``T``.' 45 | echo ' =======' 46 | echo ' The smallest value representable by type ``T``.' 47 | echo ' >>>>>>> 800088e38b5835ebdc71e9ba5299a70a5accd7c2' 48 | echo ' ```' 49 | echo " The top part of the conflict is the current translation (corresponding to the old English text), the bottom shows the new English text. " \ 50 | "To solve the conflict simply translate the new text, possibly reusing parts of the current translation. " \ 51 | "**After doing so, do not forget to remove the conflict markers.**" 52 | echo "- You may get conflicts also if there were structual changes that did not affect the meaning of the text and therefore do not require retranslation. " \ 53 | "For example when text is moved from one page to another, you will find matching conflicts in two places and the solution is to move the translation to the new spot. " \ 54 | "If only whitespace changed, it may even seem like there was no change at all but if there is a conflict, there is always a reason, however trivial it may be." \ 55 | "Be careful, though, because there is a possibility that the text was both moved **and** modified. " 56 | echo 57 | echo "#### Work on one sync PR at a time" 58 | echo "- Sync PRs are produced by the translation bot in regular intervals as long as there are changes in the English documentation. " \ 59 | "You will not lose any updates by closing this PR. " \ 60 | "The next sync PR will also include them. " \ 61 | "The latest sync PR will always include all changes that need to be done. " \ 62 | "If you haven't worked on any sync PR yet and there are several open sync PRs in your repo, choose the latest (newest) one to get started." 63 | echo "- It is recommended to work only on one sync PR at a time. " \ 64 | "Close this PR if you are already working on a different one." 65 | echo "- Once you merge this PR, the conflict resolutions and new commits you pushed to it are likely to cause conflicts with other open sync PRs. " \ 66 | "It is possible solve these conflicts if you are proficient with git and fully understand what changed in which PR, " \ 67 | "but for simplicity it is recommended to close all pending sync PRs and wait for a fresh one, which will no longer include the merged changes." 68 | echo 69 | echo "#### Do not squash merge or rebase this PR" 70 | echo "Rebasing or squashing a sync PR erases the information about the commits that the changes originally came from, which will result in extra conflicts in the next sync PR." 71 | echo "If you do it by accident, don't worry - simply make sure to handle the next sync PR properly, which will restore the missing commits." 72 | echo 73 | echo "### Review checklist" 74 | echo "The following files were modified in this pull request. " \ 75 | "Please review them before merging the PR:" 76 | modified_file_list 77 | } 78 | 79 | printf "pr_title=%s\n" "$(title)" >> "$GITHUB_ENV" 80 | printf "pr_body<> "$GITHUB_ENV" 81 | -------------------------------------------------------------------------------- /docs/structure-of-a-contract.rst: -------------------------------------------------------------------------------- 1 | .. index:: contract, state variable, function, event, struct, enum, function;modifier 2 | 3 | .. _contract_structure: 4 | 5 | ****************** 6 | コントラクトの構造 7 | ****************** 8 | 9 | Solidityのコントラクトは、オブジェクト指向言語のクラスに似ています。 10 | 各コントラクトは、 :ref:`structure-state-variables` 、 :ref:`structure-functions` 、 :ref:`structure-function-modifiers` 、 :ref:`structure-events` 、 :ref:`structure-errors` 、 :ref:`structure-struct-types` 、 :ref:`structure-enum-types` の宣言を含むことができます。 11 | さらに、コントラクトは他のコントラクトを継承できます。 12 | 13 | また、 :ref:`ライブラリ` や :ref:`インターフェース` と呼ばれる特別な種類のコントラクトもあります。 14 | 15 | :ref:`コントラクト` のセクションには、このセクションよりも詳細な情報が記載されており、概要を説明するための役割を担っています。 16 | 17 | .. _structure-state-variables: 18 | 19 | 状態変数 20 | ======== 21 | 22 | 状態変数とは、その値がコントラクトのストレージに永続的に保存されるか、 23 | あるいは一時的にトランジェントストレージに保存され、トランザクションの終了時にクリアされる変数です。 24 | 詳細については :ref:`データロケーション ` を参照してください。 25 | 26 | .. code-block:: solidity 27 | 28 | // SPDX-License-Identifier: GPL-3.0 29 | pragma solidity >=0.4.0 <0.9.0; 30 | 31 | contract SimpleStorage { 32 | uint storedData; // 状態変数 33 | // ... 34 | } 35 | 36 | 有効な状態変数の型については :ref:`types` セクションを、ビジビリティについての可能な選択肢については :ref:`visibility-and-getters` を参照してください。 37 | 38 | .. _structure-functions: 39 | 40 | 関数 41 | ==== 42 | 43 | 関数は、実行可能なコードの単位です。 44 | 関数は通常、コントラクトの中で定義されますが、コントラクトの外で定義することもできます。 45 | 46 | .. code-block:: solidity 47 | 48 | // SPDX-License-Identifier: GPL-3.0 49 | pragma solidity >=0.7.1 <0.9.0; 50 | 51 | contract SimpleAuction { 52 | function bid() public payable { // 関数 53 | // ... 54 | } 55 | } 56 | 57 | // コントラクトの外で定義されたヘルパー関数 58 | function helper(uint x) pure returns (uint) { 59 | return x * 2; 60 | } 61 | 62 | :ref:`function-calls` は内部または外部で起こり、他のコントラクトに対して異なるレベルの :ref:`ビジビリティ` を持つことができます。 63 | :ref:`関数` は、それらの間でパラメータと値を渡すために :ref:`パラメータと返り値` を受け入れます。 64 | 65 | .. _structure-function-modifiers: 66 | 67 | 関数モディファイア 68 | ================== 69 | 70 | 関数モディファイアを使うと、宣言的に関数のセマンティクスを変更できます（コントラクトセクションの :ref:`modifiers` を参照）。 71 | 72 | オーバーロード、つまり、同じモディファイア名で異なるパラメータを持つことはできません。 73 | 74 | 関数と同様、モディファイアも :ref:`オーバーライド ` できます。 75 | 76 | .. code-block:: solidity 77 | 78 | // SPDX-License-Identifier: GPL-3.0 79 | pragma solidity >=0.4.22 <0.9.0; 80 | 81 | contract Purchase { 82 | address public seller; 83 | 84 | modifier onlySeller() { // モディファイア 85 | require( 86 | msg.sender == seller, 87 | "Only seller can call this." 88 | ); 89 | _; 90 | } 91 | 92 | function abort() public view onlySeller { // モディファイアの使用 93 | // ... 94 | } 95 | } 96 | 97 | .. _structure-events: 98 | 99 | イベント 100 | ======== 101 | 102 | イベントは、EVMのログ機能を使った便利なインターフェースです。 103 | 104 | .. code-block:: solidity 105 | 106 | // SPDX-License-Identifier: GPL-3.0 107 | pragma solidity ^0.8.22; 108 | 109 | event HighestBidIncreased(address bidder, uint amount); // イベント 110 | 111 | contract SimpleAuction { 112 | function bid() public payable { 113 | // ... 114 | emit HighestBidIncreased(msg.sender, msg.value); // イベントのトリガー 115 | } 116 | } 117 | 118 | イベントがどのように宣言され、dapp内でどのように使用されるかについては、コントラクトセクションの :ref:`events` を参照してください。 119 | 120 | .. _structure-errors: 121 | 122 | エラー 123 | ====== 124 | 125 | エラーは障害が発生したときの記述的な名前とデータを定義できます。 126 | エラーは :ref:`リバート文` で使用できます。 127 | 文字列による説明に比べて、エラーははるかに安価で、追加データをエンコードできます。 128 | NatSpecを使って、ユーザーにエラーを説明できます。 129 | 130 | .. code-block:: solidity 131 | 132 | // SPDX-License-Identifier: GPL-3.0 133 | pragma solidity ^0.8.4; 134 | 135 | // 送金資金の不足。要求したのは`requested`だが、利用可能なのは`available`だけ。 136 | error NotEnoughFunds(uint requested, uint available); 137 | 138 | contract Token { 139 | mapping(address => uint) balances; 140 | function transfer(address to, uint amount) public { 141 | uint balance = balances[msg.sender]; 142 | if (balance < amount) 143 | revert NotEnoughFunds(amount, balance); 144 | balances[msg.sender] -= amount; 145 | balances[to] += amount; 146 | // ... 147 | } 148 | } 149 | 150 | 詳しくは、コントラクト編の :ref:`errors` を参照してください。 151 | 152 | .. _structure-struct-types: 153 | 154 | 構造体型 155 | ======== 156 | 157 | 構造体（struct）は、複数の変数をグループ化できるカスタム定義の型です（型の項の :ref:`structs` を参照）。 158 | 159 | .. code-block:: solidity 160 | 161 | // SPDX-License-Identifier: GPL-3.0 162 | pragma solidity >=0.4.0 <0.9.0; 163 | 164 | contract Ballot { 165 | struct Voter { // 構造体 166 | uint weight; 167 | bool voted; 168 | address delegate; 169 | uint vote; 170 | } 171 | } 172 | 173 | .. _structure-enum-types: 174 | 175 | 列挙型 176 | ====== 177 | 178 | 列挙（enum）は、有限の「定数値」を持つカスタム型を作成するために使用できます（型の項の :ref:`enums` を参照）。 179 | 180 | .. code-block:: solidity 181 | 182 | // SPDX-License-Identifier: GPL-3.0 183 | pragma solidity >=0.4.0 <0.9.0; 184 | 185 | contract Purchase { 186 | enum State { Created, Locked, Inactive } // 列挙 187 | } 188 | 189 | -------------------------------------------------------------------------------- /docs/types/operator-precedence-table.rst: -------------------------------------------------------------------------------- 1 | 演算子の優先順位を評価順に並べると以下のようになります。 2 | 3 | +------------+-------------------------------------+--------------------------------------------+ 4 | | 優先順位 | 説明 | 演算子 | 5 | +============+=====================================+============================================+ 6 | | *1* | 後置インクリメントとデクリメント | ``++``, ``--`` | 7 | + +-------------------------------------+--------------------------------------------+ 8 | | | New式 | ``new `` | 9 | + +-------------------------------------+--------------------------------------------+ 10 | | | 配列添字アクセス | ``[]`` | 11 | + +-------------------------------------+--------------------------------------------+ 12 | | | メンバアクセス | ``.`` | 13 | + +-------------------------------------+--------------------------------------------+ 14 | | | 関数的呼び出し | ``()`` | 15 | + +-------------------------------------+--------------------------------------------+ 16 | | | 括弧 | ``()`` | 17 | +------------+-------------------------------------+--------------------------------------------+ 18 | | *2* | 前置インクリメントとデクリメント | ``++``, ``--`` | 19 | + +-------------------------------------+--------------------------------------------+ 20 | | | 単項マイナス | ``-`` | 21 | + +-------------------------------------+--------------------------------------------+ 22 | | | 単項演算子 | ``delete`` | 23 | + +-------------------------------------+--------------------------------------------+ 24 | | | 論理否定 | ``!`` | 25 | + +-------------------------------------+--------------------------------------------+ 26 | | | ビット単位の否定 | ``~`` | 27 | +------------+-------------------------------------+--------------------------------------------+ 28 | | *3* | 累乗 | ``**`` | 29 | +------------+-------------------------------------+--------------------------------------------+ 30 | | *4* | 乗算、除算、剰余 | ``*``, ``/``, ``%`` | 31 | +------------+-------------------------------------+--------------------------------------------+ 32 | | *5* | 加算、減算 | ``+``, ``-`` | 33 | +------------+-------------------------------------+--------------------------------------------+ 34 | | *6* | ビット単位のシフト演算 | ``<<``, ``>>`` | 35 | +------------+-------------------------------------+--------------------------------------------+ 36 | | *7* | ビット単位のAND | ``&`` | 37 | +------------+-------------------------------------+--------------------------------------------+ 38 | | *8* | ビット単位のXOR | ``^`` | 39 | +------------+-------------------------------------+--------------------------------------------+ 40 | | *9* | ビット単位のOR | ``|`` | 41 | +------------+-------------------------------------+--------------------------------------------+ 42 | | *10* | 不等号演算子 | ``<``, ``>``, ``<=``, ``>=`` | 43 | +------------+-------------------------------------+--------------------------------------------+ 44 | | *11* | 等号演算子 | ``==``, ``!=`` | 45 | +------------+-------------------------------------+--------------------------------------------+ 46 | | *12* | 論理AND | ``&&`` | 47 | +------------+-------------------------------------+--------------------------------------------+ 48 | | *13* | 論理OR | ``||`` | 49 | +------------+-------------------------------------+--------------------------------------------+ 50 | | *14* | 三項演算子 | `` ? : `` | 51 | + +-------------------------------------+--------------------------------------------+ 52 | | | 代入演算子 | ``=``, ``|=``, ``^=``, ``&=``, ``<<=``, | 53 | | | | ``>>=``, ``+=``, ``-=``, ``*=``, ``/=``, | 54 | | | | ``%=`` | 55 | +------------+-------------------------------------+--------------------------------------------+ 56 | | *15* | カンマ演算子 | ``,`` | 57 | +------------+-------------------------------------+--------------------------------------------+ 58 | -------------------------------------------------------------------------------- /CMakeLists.txt: -------------------------------------------------------------------------------- 1 | cmake_minimum_required(VERSION 3.13.0) 2 | 3 | set(ETH_CMAKE_DIR "${CMAKE_CURRENT_LIST_DIR}/cmake" CACHE PATH "The path to the cmake directory") 4 | list(APPEND CMAKE_MODULE_PATH ${ETH_CMAKE_DIR}) 5 | 6 | # Set the build type, if none was specified. 7 | if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES) 8 | if(EXISTS "${PROJECT_SOURCE_DIR}/.git") 9 | set(DEFAULT_BUILD_TYPE "RelWithDebInfo") 10 | else() 11 | set(DEFAULT_BUILD_TYPE "Release") 12 | endif() 13 | set(CMAKE_BUILD_TYPE "${DEFAULT_BUILD_TYPE}" CACHE STRING "Choose the type of build, options are: Debug Release RelWithDebInfo MinSizeRel" FORCE) 14 | set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "RelWithDebInfo" "MinSizeRel") 15 | endif() 16 | 17 | include(EthToolchains) 18 | 19 | # Set cmake_policies 20 | include(EthPolicy) 21 | eth_policy() 22 | 23 | # project name and version should be set after cmake_policy CMP0048 24 | set(PROJECT_VERSION "0.8.31") 25 | # OSX target needed in order to support std::visit 26 | set(CMAKE_OSX_DEPLOYMENT_TARGET "10.14") 27 | project(solidity VERSION ${PROJECT_VERSION} LANGUAGES C CXX) 28 | 29 | include(TestBigEndian) 30 | TEST_BIG_ENDIAN(IS_BIG_ENDIAN) 31 | if (IS_BIG_ENDIAN) 32 | message(FATAL_ERROR "${PROJECT_NAME} currently does not support big endian systems.") 33 | endif() 34 | 35 | option(SOLC_LINK_STATIC "Link solc executable statically on supported platforms" OFF) 36 | option(SOLC_STATIC_STDLIBS "Link solc against static versions of libgcc and libstdc++ on supported platforms" OFF) 37 | option(STRICT_Z3_VERSION "Require the exact version of Z3 solver expected by our test suite." ON) 38 | option(PEDANTIC "Enable extra warnings and pedantic build flags. Treat all warnings as errors." ON) 39 | option(PROFILE_OPTIMIZER_STEPS "Output performance metrics for the optimiser steps." OFF) 40 | option( 41 | IGNORE_VENDORED_DEPENDENCIES 42 | "Ignore libraries provided as submodules of the repository and allow CMake to look for \ 43 | them in the typical locations, including system-wide dirs." 44 | OFF 45 | ) 46 | option( 47 | ONLY_BUILD_SOLIDITY_LIBRARIES 48 | "Only build library targets that can be statically linked against. Do not build executables or tests." 49 | OFF 50 | ) 51 | mark_as_advanced(PROFILE_OPTIMIZER_STEPS) 52 | mark_as_advanced(IGNORE_VENDORED_DEPENDENCIES) 53 | mark_as_advanced(ONLY_BUILD_SOLIDITY_LIBRARIES) 54 | 55 | # Setup cccache. 56 | include(EthCcache) 57 | 58 | # Let's find our dependencies 59 | include(EthDependencies) 60 | if (NOT IGNORE_VENDORED_DEPENDENCIES) 61 | include(fmtlib) 62 | include(nlohmann-json) 63 | include(range-v3) 64 | else () 65 | message(WARNING "-- Ignoring vendored dependencies. Will use installed versions if found. Versions may differ from the ones the compiler was tested with. Make sure to run the test suite and thoroughly test the resulting binaries before using them in production.") 66 | find_package(fmt REQUIRED) 67 | find_package(nlohmann_json REQUIRED) 68 | find_package(range-v3 REQUIRED) 69 | endif() 70 | 71 | find_package(Threads) 72 | 73 | if(NOT PEDANTIC) 74 | message(WARNING "-- Pedantic build flags turned off. Warnings will not make compilation fail. This is NOT recommended in development builds.") 75 | endif() 76 | 77 | if (PROFILE_OPTIMIZER_STEPS) 78 | add_definitions(-DPROFILE_OPTIMIZER_STEPS) 79 | endif() 80 | 81 | # Figure out what compiler and system are we using 82 | include(EthCompilerSettings) 83 | 84 | # Include utils 85 | include(EthUtils) 86 | 87 | # Create license.h from LICENSE.txt and template 88 | # Converting to char array is required due to MSVC's string size limit. 89 | file(READ ${PROJECT_SOURCE_DIR}/LICENSE.txt LICENSE_TEXT HEX) 90 | string(REGEX MATCHALL ".." LICENSE_TEXT "${LICENSE_TEXT}") 91 | string(REGEX REPLACE ";" ",\n\t0x" LICENSE_TEXT "${LICENSE_TEXT}") 92 | set(LICENSE_TEXT "0x${LICENSE_TEXT}") 93 | 94 | configure_file("${PROJECT_SOURCE_DIR}/cmake/templates/license.h.in" include/license.h) 95 | 96 | include(EthOptions) 97 | configure_project(TESTS) 98 | 99 | if(EMSCRIPTEN) 100 | set(TESTED_Z3_VERSION "4.13.3") 101 | set(MINIMUM_Z3_VERSION "4.8.16") 102 | find_package(Z3) 103 | if (${Z3_FOUND}) 104 | add_definitions(-DEMSCRIPTEN_BUILD) 105 | if (${STRICT_Z3_VERSION}) 106 | if (NOT ("${Z3_VERSION_STRING}" VERSION_EQUAL ${TESTED_Z3_VERSION})) 107 | message( 108 | FATAL_ERROR 109 | "SMTChecker tests require Z3 ${TESTED_Z3_VERSION} for all tests to pass.\n" 110 | ) 111 | endif() 112 | else() 113 | if ("${Z3_VERSION_STRING}" VERSION_LESS ${MINIMUM_Z3_VERSION}) 114 | message( 115 | FATAL_ERROR 116 | "Solidity requires Z3 ${MINIMUM_Z3_VERSION} or newer." 117 | ) 118 | endif() 119 | endif() 120 | else() 121 | message(FATAL_ERROR "Solidity requires Z3 for emscripten build.") 122 | endif() 123 | endif() 124 | 125 | add_subdirectory(libsolutil) 126 | add_subdirectory(liblangutil) 127 | add_subdirectory(libsmtutil) 128 | add_subdirectory(libevmasm) 129 | add_subdirectory(libyul) 130 | add_subdirectory(libsolidity) 131 | add_subdirectory(libsolc) 132 | add_subdirectory(libstdlib) 133 | 134 | if (NOT ONLY_BUILD_SOLIDITY_LIBRARIES) 135 | add_subdirectory(tools) 136 | 137 | if (NOT EMSCRIPTEN) 138 | add_subdirectory(solc) 139 | endif() 140 | 141 | if (TESTS AND NOT EMSCRIPTEN) 142 | add_subdirectory(test) 143 | endif() 144 | endif() 145 | -------------------------------------------------------------------------------- /docs/internals/source_mappings.rst: -------------------------------------------------------------------------------- 1 | .. index:: source mappings 2 | 3 | **************** 4 | ソースマッピング 5 | **************** 6 | 7 | .. As part of the AST output, the compiler provides the range of the source 8 | .. code that is represented by the respective node in the AST. This can be 9 | .. used for various purposes ranging from static analysis tools that report 10 | .. errors based on the AST and debugging tools that highlight local variables 11 | .. and their uses. 12 | 13 | コンパイラは、ASTの出力の一部として、ASTの各ノードで表現されるソースコードの範囲を提供します。 14 | これは、ASTに基づいてエラーを報告する静的解析ツールや、ローカル変数とその用途を強調するデバッグツールなど、さまざまな目的に利用できます。 15 | 16 | .. Furthermore, the compiler can also generate a mapping from the bytecode 17 | .. to the range in the source code that generated the instruction. This is again 18 | .. important for static analysis tools that operate on bytecode level and 19 | .. for displaying the current position in the source code inside a debugger 20 | .. or for breakpoint handling. This mapping also contains other information, 21 | .. like the jump type and the modifier depth (see below). 22 | 23 | さらに、コンパイラは、バイトコードから、その命令を生成したソースコードの範囲へのマッピングを生成することもできます。 24 | これは、バイトコードレベルで動作する静的解析ツールや、デバッガ内でソースコードの現在の位置を表示したり、ブレークポイントを処理する際にも重要です。 25 | このマッピングには、ジャンプタイプやモディファイアの深さなど、他の情報も含まれています（後述）。 26 | 27 | .. Both kinds of source mappings use integer identifiers to refer to source files. 28 | .. The identifier of a source file is stored in 29 | .. ``output['sources'][sourceName]['id']`` where ``output`` is the output of the 30 | .. standard-json compiler interface parsed as JSON. 31 | .. For some utility routines, the compiler generates "internal" source files 32 | .. that are not part of the original input but are referenced from the source 33 | .. mappings. These source files together with their identifiers can be 34 | .. obtained via ``output['contracts'][sourceName][contractName]['evm']['bytecode']['generatedSources']``. 35 | 36 | どちらのソースマッピングも、ソースファイルの参照には整数の識別子を使用します。 37 | ソースファイルの識別子は ``output['sources'][sourceName]['id']`` に格納され、 ``output`` はJSONとして解析されたstandard-jsonコンパイラインターフェースの出力です。 38 | 一部のユーティリティルーチンでは、コンパイラーは元の入力の一部ではなく、ソースマッピングから参照される「内部」ソースファイルを生成します。 39 | これらのソースファイルは、その識別子とともに、 ``output['contracts'][sourceName][contractName]['evm']['bytecode']['generatedSources']`` を通じて入手できます。 40 | 41 | .. .. note:: 42 | .. In the case of instructions that are not associated with any particular source file, 43 | .. the source mapping assigns an integer identifier of ``-1``. This may happen for 44 | .. bytecode sections stemming from compiler-generated inline assembly statements. 45 | 46 | .. note:: 47 | 特定のソースファイルに関連付けられていない命令の場合、ソースマッピングでは ``-1`` という整数の識別子が割り当てられます。 48 | これは、コンパイラによって生成されたインラインアセンブリ文に由来するバイトコードセクションで発生する可能性があります。 49 | 50 | .. The source mappings inside the AST use the following notation: 51 | 52 | AST内部のソースマッピングは以下の表記を使用しています。 53 | 54 | ``s:l:f`` 55 | 56 | .. Where ``s`` is the byte-offset to the start of the range in the source file, 57 | .. ``l`` is the length of the source range in bytes and ``f`` is the source 58 | .. index mentioned above. 59 | 60 | ``s`` はソースファイル内の範囲の開始点へのバイトオフセット、 ``l`` はソース範囲の長さ（バイト）、 ``f`` は前述のソースインデックスです。 61 | 62 | .. The encoding in the source mapping for the bytecode is more complicated: 63 | .. It is a list of ``s:l:f:j:m`` separated by ``;``. Each of these 64 | .. elements corresponds to an instruction, i.e. you cannot use the byte offset 65 | .. but have to use the instruction offset (push instructions are longer than a single byte). 66 | .. The fields ``s``, ``l`` and ``f`` are as above. ``j`` can be either 67 | .. ``i``, ``o`` or ``-`` signifying whether a jump instruction goes into a 68 | .. function, returns from a function or is a regular jump as part of e.g. a loop. 69 | .. The last field, ``m``, is an integer that denotes the "modifier depth". This depth 70 | .. is increased whenever the placeholder statement (``_``) is entered in a modifier 71 | .. and decreased when it is left again. This allows debuggers to track tricky cases 72 | .. like the same modifier being used twice or multiple placeholder statements being 73 | .. used in a single modifier. 74 | 75 | バイトコードのソースマッピングでのエンコーディングはもっと複雑です。 76 | それは ``;`` で区切られた ``s:l:f:j:m`` のリストです。 77 | これらの要素はそれぞれ命令に対応しています。 78 | つまり、バイトオフセットを使用することはできず、命令オフセットを使用する必要があります（プッシュ命令は1バイトよりも長い）。 79 | フィールド ``s`` 、 ``l`` 、 ``f`` は上記の通りです。 80 | ``j`` は ``i`` 、 ``o`` 、 ``-`` のいずれかで、ジャンプ命令が関数に入るのか、関数から戻るのか、ループなどの一部としての通常のジャンプなのかを示します。 81 | 最後のフィールド ``m`` は、「モディファイアの深さ」を示す整数です。 82 | この深さは、モディファイアにプレースホルダー文（ ``_`` ）が入力されるたびに増加し、再び入力されると減少します。 83 | これにより、同じモディファイアが2回使われたり、1つのモディファイアに複数のプレースホルダー文が使われたりするようなトリッキーなケースをデバッガーが追跡できます。 84 | 85 | .. In order to compress these source mappings especially for bytecode, the 86 | .. following rules are used: 87 | .. - If a field is empty, the value of the preceding element is used. 88 | .. - If a ``:`` is missing, all following fields are considered empty. 89 | 90 | 特にバイトコードの場合、これらのソースマッピングを圧縮するために、以下のルールが使われています。 91 | 92 | - フィールドが空の場合は、直前の要素の値が使用されます。 93 | 94 | - ``:`` がない場合、以下のすべてのフィールドは空であるとみなされます。 95 | 96 | これは、次のソースマッピングが同じ情報を表していることを意味します。 97 | 98 | ``1:2:1;1:9:1;2:1:2;2:1:2;2:1:2`` 99 | 100 | ``1:2:1;:9;2:1:2;;`` 101 | 102 | .. Important to note is that when the :ref:`verbatim ` builtin is used, 103 | .. the source mappings will be invalid: The builtin is considered a single 104 | .. instruction instead of potentially multiple. 105 | 106 | 重要なのは、 :ref:`verbatim ` ビルトインを使用すると、ソースマッピングが無効になることです。 107 | ビルドインは複数の命令ではなく、1つの命令とみなされます。 108 | -------------------------------------------------------------------------------- /docs/index.rst: -------------------------------------------------------------------------------- 1 | Solidity 2 | ======== 3 | 4 | Solidityは、スマートコントラクトを実装するための、オブジェクト指向の高級言語です。 5 | スマートコントラクトとは、Ethereumのアカウントの動作を制御するプログラムのことです。 6 | 7 | Solidityは、 Ethereum Virtual Machine (EVM)をターゲットに設計されている `カーリーブラケット言語 `_ です。 8 | C++、Python、JavaScriptの影響を受けています。 9 | Solidityがどの言語から影響を受けているかについては、 :doc:`言語の影響 ` のセクションで詳しく説明しています。 10 | 11 | Solidityは、静的型付け、継承、ライブラリ、複雑なユーザー定義型などの機能をサポートしています。 12 | 13 | Solidityでは、投票、クラウドファンディング、ブラインドオークション、マルチシグネチャウォレットなどの用途に応じたコントラクトを作成できます。 14 | 15 | コントラクトをデプロイする際には、Solidityの最新のリリースバージョンを使用すべきです。 16 | 例外的なケースを除いて、最新バージョンには `セキュリティフィックス `_ が施されています。 17 | さらに、破壊的な変更や新機能も定期的に導入されています。 18 | 私たちは現在、 `この速いペースでの変更を示すため `_ に、0.y.zというバージョン番号を使用しています。 19 | 20 | .. warning:: 21 | 22 | Solidityは最近バージョン0.8.xをリリースしましたが、変更点が多くあります。 23 | 必ず :doc:`その詳細なリスト <080-breaking-changes>` を読んでください。 24 | 25 | Solidityやこのドキュメントを改善するためのアイデアはいつでも歓迎します。 26 | 詳細は :doc:`コントリビューターガイド ` を読んでください。 27 | 28 | .. Hint:: 29 | 30 | このドキュメントは、右下のバージョン表示メニューをクリックして、希望のダウンロード形式を選択すると、PDF、HTML、Epub のいずれかでダウンロードできます。 31 | 32 | 33 | はじめに 34 | -------- 35 | 36 | **1. スマートコントラクトの基本を理解する** 37 | 38 | スマートコントラクトの概念を初めて知る方には、まず「:doc:`スマートコントラクトの紹介 `」を掘り下げて読むことをお勧めします。 39 | これには次のコンテンツが含まれています。 40 | 41 | * :ref:`スマートコントラクトのシンプルな例 ` （Solidityで書かれたもの） 42 | * :ref:`ブロックチェーンの基本 ` 43 | * :ref:`Ethereum Virtual Machine ` 44 | 45 | **2. Solidityを知る** 46 | 47 | 基本的な操作に慣れてきたら、 「:doc:`Solidity by Example `」や「言語仕様」にあるセクションを読んで、言語のコアコンセプトを理解することをお勧めします。 48 | 49 | **3. Solidityコンパイラをインストールする** 50 | 51 | Solidityコンパイラをインストールするには様々な方法があります。 52 | 好みのオプションを選択して、 :ref:`インストールページ ` に記載されている手順に従ってください。 53 | 54 | .. hint:: 55 | `Remix IDE `_ を使えば、ブラウザ上で直接コードの例を試すことができます。 56 | RemixはWebブラウザベースのIDEで、Solidityをローカルにインストールすることなく、Solidityスマートコントラクトの作成、デプロイ、管理を行うことができます。 57 | 58 | .. warning:: 59 | 人間がソフトウェアを書くと、バグが発生することがあります。 60 | そのため、スマートコントラクトを作成する際には、確立されたソフトウェア開発のベストプラクティスに従うべきです。 61 | これには、コードレビュー、テスト、監査、およびコレクトネス（実装が仕様に沿っていること）の証明が含まれます。 62 | スマートコントラクトのユーザーは、コードの作成者よりもコードを信頼している場合があります。 63 | また、ブロックチェーンやスマートコントラクトには、注意すべき特有の問題があるため、本番のコードに取り組む前に、必ず :ref:`security_considerations` のセクションを読んでください。 64 | 65 | **4. さらに学ぶ** 66 | 67 | Ethereumでの分散型アプリケーションの構築について詳しく知りたい場合は、 `Ethereum Developer Resources `_ で、Ethereumに関するさらに一般的なドキュメントや、幅広い種類のチュートリアル、ツール、開発フレームワークを紹介しています。 68 | 69 | 疑問点があれば、検索したり、 `Ethereum StackExchange `_ や `Gitterチャンネル `_ で聞いてみると良いでしょう。 70 | 71 | .. _translations: 72 | 73 | 翻訳 74 | ---- 75 | 76 | このドキュメントは、コミュニティのコントリビューターによって、いくつかの言語に翻訳されています。 77 | これらの言語は、完成度と最新度が異なります。 78 | 正確な情報を得たい場合は、英語版を参考にしてください。 79 | 80 | 右下のフライアウトメニューをクリックし、好みの言語を選択することで言語を切り替えることができます。 81 | 82 | * `中国語 `_ 83 | * `フランス語 `_ 84 | * `インドネシア語 `_ 85 | * `日本語 `_ 86 | * `韓国語 `_ 87 | * `ペルシア語 `_ 88 | * `ロシア語 `_ 89 | * `スペイン語 `_ 90 | * `トルコ語 `_ 91 | 92 | .. note:: 93 | 94 | 私たちは、コミュニティの取り組みを効率化するために、GitHubのオーガナイゼーションと翻訳ワークフローをセットアップしました。 95 | 新しい言語での翻訳を始めたり、コミュニティの翻訳に貢献する方法については、 `solidity-docsオーガナイゼーション `_ にある翻訳ガイドを参照してください。 96 | 97 | コンテンツ 98 | ========== 99 | 100 | :ref:`キーワードインデックス `, :ref:`検索ページ ` 101 | 102 | .. toctree:: 103 | :maxdepth: 2 104 | :caption: 基本 105 | 106 | introduction-to-smart-contracts.rst 107 | solidity-by-example.rst 108 | installing-solidity.rst 109 | 110 | .. toctree:: 111 | :maxdepth: 2 112 | :caption: 言語仕様 113 | 114 | layout-of-source-files.rst 115 | structure-of-a-contract.rst 116 | types.rst 117 | units-and-global-variables.rst 118 | control-structures.rst 119 | contracts.rst 120 | assembly.rst 121 | cheatsheet.rst 122 | grammar.rst 123 | 124 | .. toctree:: 125 | :maxdepth: 2 126 | :caption: コンパイラ 127 | 128 | using-the-compiler.rst 129 | analysing-compilation-output.rst 130 | ir-breaking-changes.rst 131 | 132 | .. toctree:: 133 | :maxdepth: 2 134 | :caption: 内部仕様 135 | 136 | internals/layout_in_storage.rst 137 | internals/layout_in_memory.rst 138 | internals/layout_in_calldata.rst 139 | internals/variable_cleanup.rst 140 | internals/source_mappings.rst 141 | internals/optimizer.rst 142 | metadata.rst 143 | abi-spec.rst 144 | 145 | .. toctree:: 146 | :maxdepth: 2 147 | :caption: アドバイザリーコンテンツ 148 | 149 | security-considerations.rst 150 | bugs.rst 151 | 050-breaking-changes.rst 152 | 060-breaking-changes.rst 153 | 070-breaking-changes.rst 154 | 080-breaking-changes.rst 155 | 156 | .. toctree:: 157 | :maxdepth: 2 158 | :caption: 補足資料 159 | 160 | natspec-format.rst 161 | smtchecker.rst 162 | yul.rst 163 | path-resolution.rst 164 | 165 | .. toctree:: 166 | :maxdepth: 2 167 | :caption: その他の資料 168 | 169 | style-guide.rst 170 | common-patterns.rst 171 | resources.rst 172 | contributing.rst 173 | language-influences.rst 174 | brand-guide.rst 175 | -------------------------------------------------------------------------------- /docs/contracts/function-modifiers.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! function;modifier 2 | 3 | .. _modifiers: 4 | 5 | ****************** 6 | 関数モディファイア 7 | ****************** 8 | 9 | モディファイアは、宣言的な方法で関数の動作を変更するために使用できます。 10 | 例えば、モディファイアを使って、関数を実行する前に自動的に条件をチェックできます。 11 | 12 | モディファイアはコントラクトの継承可能なプロパティであり、派生コントラクトでオーバーライドできますが、 ``virtual`` マークが付いている場合に限ります。 13 | 詳細は、 :ref:`モディファイアのオーバーライド ` を参照してください。 14 | 15 | .. code-block:: solidity 16 | 17 | // SPDX-License-Identifier: GPL-3.0 18 | pragma solidity >=0.7.1 <0.9.0; 19 | 20 | contract owned { 21 | constructor() { owner = payable(msg.sender); } 22 | address payable owner; 23 | 24 | // このコントラクトはモディファイアを定義するだけで、それを使用することはありません。 25 | // 派生コントラクトで使用されます。 26 | // 関数本体は、モディファイアの定義にある特別な記号 `_;` が現れる場所に挿入されます。 27 | // これは、オーナーがこの関数を呼び出した場合は関数が実行され、そうでない場合は例外がスローされることを意味します。 28 | modifier onlyOwner { 29 | require( 30 | msg.sender == owner, 31 | "Only owner can call this function." 32 | ); 33 | _; 34 | } 35 | } 36 | 37 | contract priced { 38 | // モディファイアは引数を受け取ることができます: 39 | modifier costs(uint price) { 40 | if (msg.value >= price) { 41 | _; 42 | } 43 | } 44 | } 45 | 46 | contract Register is priced, owned { 47 | mapping(address => bool) registeredAddresses; 48 | uint price; 49 | 50 | constructor(uint initialPrice) { price = initialPrice; } 51 | 52 | // ここで `payable` キーワードを指定することも重要です。 53 | // さもなければ、この関数は送られてきたすべての Ether を自動的に拒否します。 54 | function register() public payable costs(price) { 55 | registeredAddresses[msg.sender] = true; 56 | } 57 | 58 | // This contract inherits the `onlyOwner` modifier from 59 | // the `owned` contract. As a result, calls to `changePrice` will 60 | // only take effect if they are made by the stored owner. 61 | function changePrice(uint price_) public onlyOwner { 62 | price = price_; 63 | } 64 | } 65 | 66 | contract Mutex { 67 | bool locked; 68 | modifier noReentrancy() { 69 | require( 70 | !locked, 71 | "Reentrant call." 72 | ); 73 | locked = true; 74 | _; 75 | locked = false; 76 | } 77 | 78 | /// この関数はミューテックスで保護されているので、 `msg.sender.call` 内からのリエントラントなコールは `f` を再び呼び出すことができません。 79 | /// `return 7` 文は戻り値に 7 を代入しますが、その後にモディファイアの `locked = false` という文は実行されます。 80 | function f() public noReentrancy returns (uint) { 81 | (bool success,) = msg.sender.call(""); 82 | require(success); 83 | return 7; 84 | } 85 | } 86 | 87 | .. If you want to access a modifier ``m`` defined in a contract ``C``, you can use ``C.m`` to 88 | .. reference it without virtual lookup. It is only possible to use modifiers defined in the current 89 | .. contract or its base contracts. Modifiers can also be defined in libraries but their use is 90 | .. limited to functions of the same library. 91 | 92 | コントラクト ``C`` で定義されたモディファイア ``m`` にアクセスしたい場合は、 ``C.m`` を使って仮想ルックアップなしで参照できます。 93 | 現在のコントラクトまたはそのベースコントラクトで定義されたモディファイアのみを使用できます。 94 | モディファイアはライブラリで定義することもできますが、その使用は同じライブラリの関数に限られます。 95 | 96 | .. Multiple modifiers are applied to a function by specifying them in a 97 | .. whitespace-separated list and are evaluated in the order presented. 98 | 99 | 複数のモディファイアをホワイトスペースで区切ったリストで指定すると、その関数に適用され、提示された順序で評価されます。 100 | 101 | .. Modifiers cannot implicitly access or change the arguments and return values of functions they modify. 102 | .. Their values can only be passed to them explicitly at the point of invocation. 103 | 104 | モディファイアは、自分が修飾する関数の引数や戻り値に暗黙のうちにアクセスしたり変更したりできません。 105 | モディファイアの値は、呼び出しの時点で明示的に渡されるだけです。 106 | 107 | .. In function modifiers, it is necessary to specify when you want the function to which the modifier is applied to be run. 108 | .. The placeholder statement (denoted by a single underscore character ``_``) is used to denote where the body of the function being modified should be inserted. 109 | .. Note that the placeholder operator is different from using underscores as leading or trailing characters in variable names, which is a stylistic choice. 110 | 111 | 関数モディファイアでは、モディファイアが適用された関数をいつ実行させたいかを指定する必要があります。 112 | プレースホルダ文（アンダースコア1文字 ``_`` で示される）は、修飾される関数のボディが挿入されるべき場所を示すために使用されます。 113 | プレースホルダ演算子は、アンダースコアを変数名の先頭や末尾に使用するのとは異なることに注意してください（これはスタイル上の選択です）。 114 | 115 | .. Explicit returns from a modifier or function body only leave the current 116 | .. modifier or function body. Return variables are assigned and 117 | .. control flow continues after the ``_`` in the preceding modifier. 118 | 119 | モディファイアや関数本体からの明示的なリターンは、現在のモディファイアや関数本体のみを残します。 120 | 戻り値の変数は割り当てられ、コントロールフローは先行するモディファイアの ``_`` の後に続きます。 121 | 122 | .. warning:: 123 | 124 | Solidityの以前のバージョンでは、モディファイアを持つ関数内の ``return`` 文の動作が異なっていました。 125 | 126 | .. An explicit return from a modifier with ``return;`` does not affect the values returned by the function. 127 | .. The modifier can, however, choose not to execute the function body at all and in that case the return 128 | .. variables are set to their :ref:`default values` just as if the function had an empty body. 129 | 130 | ``return;`` を持つモディファイアからの明示的なリターンは、関数が返す値に影響を与えません。 131 | しかし、モディファイアは、関数本体を全く実行しないことを選択でき、その場合、関数本体が空であった場合と同様に、戻り値の変数は :ref:`デフォルト値` に設定されます。 132 | 133 | ``_`` 記号は、modifier の中で複数回登場することがあります。 134 | それぞれの出現箇所が関数本体に置き換えられ、最後の ``_`` の返り値が関数の戻り値となります。 135 | 136 | .. Arbitrary expressions are allowed for modifier arguments and in this context, all symbols visible from the function are visible in the modifier. 137 | .. Symbols introduced in the modifier are not visible in the function (as they might change by overriding). 138 | 139 | モディファイアの引数には任意の式が許されており、このコンテキストでは、関数から見えるすべてのシンボルがモディファイアでも見えます。 140 | モディファイアで導入されたシンボルは、（オーバーライドによって変更される可能性があるため）関数では見えません。 141 | -------------------------------------------------------------------------------- /docs/text_linter.py: -------------------------------------------------------------------------------- 1 | import glob 2 | import unicodedata 3 | import re 4 | 5 | def check_terms(): 6 | 7 | check_list = [ 8 | ("インターフェース", ("インターフェイス",)), 9 | ("状態変数", ("ステート変数",)), 10 | ("演算子", ("オペレータ",)), 11 | ("モディファイア", ("修飾子",)), 12 | ("代入", ("割り当て",)), 13 | (" ", ("　",)), 14 | (":", ("：",)), 15 | ("、", ("，",)), 16 | ("。", ("．",)), 17 | ("+", ("＋",)), 18 | ("ストレージ", ("記憶",)), 19 | ("でき", ("することができ",)), 20 | ("ます。", ("る。",)), # だ・である調を使うときは、「。」を使わないようにしたい 21 | ("です。", ("だ。",)), 22 | ("?", ("[^さ]い。",)), 23 | ("", ("・",)), 24 | ("型", ("タイプ",)), 25 | ("シグネチャ", ("シグネチャー",)), 26 | ("シャドーイング", ("シャドウイング",)), 27 | ("オプティマイザ", ("オプティマイザー",)), 28 | ("セレクタ", ("セレクター",)), 29 | ("動的", ("ダイナミック",)), 30 | ("静的", ("スタティック",)), 31 | ("継承", ("相続",)), 32 | # ("ため、", ("ので、",)), 33 | ("コントロールフロー", ("制御フロー",)), 34 | ("ハイレベル", ("高レベル",)), 35 | ("関数", ("ファンクション",)), 36 | ("リターン変数", ("戻り値変数", "戻り変数")), 37 | ("文", ("ステートメント",)), 38 | ("データロケーション", ("データ位置",)), 39 | ("リバート", ("復帰", "元に戻")), 40 | ("参照して", ("ご覧",)), 41 | ("作成者", ("オリジネーター",)), 42 | ("将来", ("将来的に",)), 43 | ("抽象コントラクト", ("抽象的なコントラクト",)), 44 | ("インポート文", ("import文",)), 45 | ("``: ", ("`` : ",)), 46 | ("\n", (" \n",)), 47 | ("$1アカウント", ("([^行])口座",)), 48 | # ("$1$2", ("([a-zA-Z0-9]) ([ぁ-んー])", "([ぁ-んー]) ([a-zA-Z0-9])")), 49 | # ("$1コール", ("([^数部])呼び出し",)), # function call = 関数呼び出し, call = コール 50 | # (": ", (" : ",)), 51 | ] 52 | 53 | for correct_term, raw_patterns in check_list: 54 | for raw_pattern in raw_patterns: 55 | for file in glob.glob("./**/*.rst", recursive=True): 56 | lines = open(file).readlines() 57 | for i, line in enumerate(lines): 58 | pattern = re.compile(raw_pattern) 59 | if pattern.search(line): 60 | print(f"{file}:{i + 1} '{raw_pattern}' => '{correct_term}'") 61 | 62 | 63 | def check_kuten(): 64 | for file in glob.glob("./**/*.rst", recursive=True): 65 | lines = open(file).readlines() 66 | for i, line in enumerate(lines): 67 | lstripped_line = line.lstrip() 68 | if len(lstripped_line) > 0 and lstripped_line[0] in "-*#/|1234567890": 69 | continue 70 | if line.find("。") != -1 and line.find("。") != len(line) - 2: 71 | print(f"{file}:{i + 1} '。([^\\n])' -> '。\\n$1") 72 | 73 | 74 | def check_headers(): 75 | def get_char_width(text): 76 | width = 0 77 | for c in text: 78 | if unicodedata.east_asian_width(c) in 'FWA': 79 | width += 2 80 | else: 81 | width += 1 82 | return width 83 | 84 | for file in glob.glob("./**/*.rst", recursive=True): 85 | lines = open(file).readlines() 86 | for i in range(len(lines) - 1): 87 | line = lines[i][:-1] 88 | next_line = lines[i + 1][:-1] 89 | 90 | if len(line) == 0 or len(next_line) == 0: 91 | continue 92 | 93 | if len(set(next_line)) != 1: 94 | continue 95 | 96 | if next_line[0] not in "=-^~*": 97 | continue 98 | 99 | line_length = get_char_width(line) 100 | next_line_length = len(next_line) 101 | 102 | if line_length != next_line_length: 103 | print(f"{file}:{i + 1} Header length mismatch: {line_length} != {next_line_length}") 104 | 105 | # ご検知も多いため適宜ONにする 106 | # if line_length == len(line): 107 | # print(f"{file}:{i} Header might be not translated: {line}") 108 | 109 | def detect_untranslated_lines(): 110 | for file in glob.glob("./**/*.rst", recursive=True): 111 | lines = open(file).readlines() 112 | ignore_block = False 113 | for i, line in enumerate(lines): 114 | lstripped_line = line.lstrip() 115 | removed_code_and_link_line = re.sub(r"`[^`]+`", "", re.sub(r"``[^`]+``", "", line)) 116 | 117 | if lstripped_line.startswith(".. code-block::") \ 118 | or lstripped_line.startswith(".. toctree::"): 119 | ignore_block = True 120 | indent = len(line) - len(lstripped_line) 121 | elif ignore_block and (line.startswith(" " + " " * indent) or line == "\n"): 122 | continue 123 | else: 124 | ignore_block = False 125 | 126 | if re.search(r"[ぁ-んァ-ヶｱ-ﾝﾞﾟ一-龠、。]", line): 127 | continue 128 | if lstripped_line.startswith("..") \ 129 | or lstripped_line.startswith(":widths:") \ 130 | or lstripped_line.startswith(":only-reachable-from:") \ 131 | or lstripped_line.startswith("http"): 132 | continue 133 | if not re.search(r"[a-zA-Z]", removed_code_and_link_line): 134 | continue 135 | if not re.search(r"[,.][\n ]", removed_code_and_link_line): 136 | continue 137 | if lstripped_line.replace("\n", "") in [ 138 | "tx.origin", 139 | "revert CustomError(arg1, arg2);", 140 | "datasize, dataoffset, datacopy", 141 | "setimmutable, loadimmutable", 142 | "#. **Standard JSON**", 143 | "Functions can be declared ``pure`` in which case they promise not to read from or modify the state.", 144 | "When invoking the compiler, you can specify how to discover the first element of a path, and also path prefix remappings."]: 145 | continue 146 | print(f"{file}:{i + 1} Untranslated line: {line[:-1]}") 147 | 148 | if __name__ == "__main__": 149 | check_terms() 150 | check_kuten() 151 | check_headers() 152 | detect_untranslated_lines() 153 | -------------------------------------------------------------------------------- /docs/contracts/errors.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! error, revert, require, ! selector; of an error 2 | .. _errors: 3 | 4 | ************** 5 | カスタムエラー 6 | ************** 7 | 8 | Solidityのエラーは、操作が失敗した理由をユーザーに説明するための、便利でガス効率の良い方法です。 9 | エラーはコントラクト（インターフェースやライブラリを含む）の内外で定義できます。 10 | 11 | .. TODO: 12 | 13 | They have to be used together with the :ref:`revert statement ` 14 | or the :ref:`require function `. 15 | In the case of ``revert`` statements, or ``require`` calls where the condition is evaluated to be false, 16 | all changes in the current call are reverted, and the error data passed back to the caller. 17 | 18 | The example below shows custom error usage with the ``revert`` statement in function ``transferWithRevertError``, 19 | as well as the newer approach with ``require`` in function ``transferWithRequireError``. 20 | 21 | .. code-block:: solidity 22 | 23 | // SPDX-License-Identifier: GPL-3.0 24 | pragma solidity ^0.8.27; 25 | 26 | /// 送金の残高不足 27 | /// `required`必要だが、`available`しか利用可能でない 28 | /// @param available 利用可能な残高 29 | /// @param required 送金の要求額 30 | error InsufficientBalance(uint256 available, uint256 required); 31 | 32 | contract TestToken { 33 | mapping(address => uint) balance; 34 | function transferWithRevertError(address to, uint256 amount) public { 35 | if (amount > balance[msg.sender]) 36 | revert InsufficientBalance({ 37 | available: balance[msg.sender], 38 | required: amount 39 | }); 40 | balance[msg.sender] -= amount; 41 | balance[to] += amount; 42 | } 43 | function transferWithRequireError(address to, uint256 amount) public { 44 | require(amount <= balance[msg.sender], InsufficientBalance(balance[msg.sender], amount)); 45 | balance[msg.sender] -= amount; 46 | balance[to] += amount; 47 | } 48 | // ... 49 | } 50 | 51 | .. TODO: 52 | 53 | Another important detail to mention when it comes to using ``require`` with custom errors, is that memory 54 | allocation for the error-based revert reason will only happen in the reverting case, which, along with 55 | optimization of constants and string literals makes this about as gas-efficient as the 56 | ``if (!condition) revert CustomError(args)`` pattern. 57 | 58 | エラーはオーバーロードやオーバーライドできませんが、継承されます。 59 | スコープが異なっている限り、同じエラーを複数の場所で定義できます。 60 | エラーのインスタンスは、 ``revert`` 文を使うか、 ``require`` 関数の第2引数としてのみ作成できます。 61 | 62 | .. The error creates data that is then passed to the caller with the revert operation to either return to the off-chain component or catch it in a :ref:`try/catch statement `. 63 | .. Note that an error can only be caught when coming from an external call, reverts happening in internal calls or inside the same function cannot be caught. 64 | 65 | エラーが発生すると、データが作成され、リバート操作で呼び出し側に渡され、オフチェーンコンポーネントに戻るか、 :ref:`try/catch文 ` でキャッチされます。 66 | エラーをキャッチできるのは、外部からの呼び出しの場合のみで、内部呼び出しや同じ関数内で発生したリバートはキャッチできないことに注意してください。 67 | 68 | .. If you do not provide any parameters, the error only needs four bytes of 69 | .. data and you can use :ref:`NatSpec ` as above 70 | .. to further explain the reasons behind the error, which is not stored on chain. 71 | .. This makes this a very cheap and convenient error-reporting feature at the same time. 72 | 73 | パラメータを何も与えなければ、エラーは4バイトのデータだけで済み、上記のように :ref:`NatSpec ` を使ってエラーの理由をさらに説明できますが、これはチェーンには保存されません。 74 | これにより、非常に安価で便利なエラー報告機能を同時に実現しています。 75 | 76 | .. More specifically, an error instance is ABI-encoded in the same way as 77 | .. a function call to a function of the same name and types would be 78 | .. and then used as the return data in the ``revert`` opcode. 79 | .. This means that the data consists of a 4-byte selector followed by :ref:`ABI-encoded` data. 80 | .. The selector consists of the first four bytes of the keccak256-hash of the signature of the error type. 81 | 82 | 具体的には、エラーインスタンスは、同じ名前と型を持つ関数への関数呼び出しと同じ方法でABIエンコードされ、 ``revert`` オペコードのリターンデータとして使用されます。 83 | つまり、データは4バイトのセレクタとそれに続く :ref:`ABIエンコード` されたデータで構成されています。 84 | セレクタは、エラー型のシグネチャのkeccak256ハッシュの最初の4バイトで構成されています。 85 | 86 | .. .. note:: 87 | 88 | .. It is possible for a contract to revert with different errors of the same name or even with errors defined in different places that are indistinguishable by the caller. 89 | .. For the outside, i.e. the ABI, only the name of the error is relevant, not the contract or file where it is defined. 90 | 91 | .. note:: 92 | 93 | コントラクトが同じ名前の異なるエラーでリバートすることは可能ですし、呼び出し元では区別できない異なる場所で定義されたエラーであっても可能です。 94 | 外部、つまりABIにとっては、エラーの名前だけが重要であり、そのエラーが定義されているコントラクトやファイルは関係ありません。 95 | 96 | .. The statement ``require(condition, "description");`` would be equivalent to 97 | .. ``if (!condition) revert Error("description")`` if you could define ``error Error(string)``. 98 | .. Note, however, that ``Error`` is a built-in type and cannot be defined in user-supplied code. 99 | 100 | ``require(condition, "description");`` という文は、 ``error Error(string)`` を定義できれば ``if (!condition) revert Error("description")`` と同じになります。 101 | ただし、 ``Error`` は組み込み型であり、ユーザーが提供するコードでは定義できないことに注意してください。 102 | 103 | .. Similarly, a failing ``assert`` or similar conditions will revert with an error of the built-in type ``Panic(uint256)``. 104 | 105 | 同様に、 ``assert`` が失敗した場合や同様の条件の場合は、ビルトイン型の ``Panic(uint256)`` エラーでリバートします。 106 | 107 | .. .. note:: 108 | 109 | .. Error data should only be used to give an indication of failure, but 110 | .. not as a means for control-flow. The reason is that the revert data 111 | .. of inner calls is propagated back through the chain of external calls 112 | .. by default. This means that an inner call 113 | .. can "forge" revert data that looks like it could have come from the 114 | .. contract that called it. 115 | 116 | .. note:: 117 | 118 | エラーデータは、失敗の兆候を示すためにのみ使用すべきで、コントロールフローの手段としては使用しないでください。 119 | その理由は、インナーコールのリバートデータは、デフォルトでは外部呼び出しのチェーンを通じて伝搬されるからです。 120 | つまり、内側の呼び出しは、それを呼び出したコントラクトから来たように見えるリバートデータを「偽造」できるということです。 121 | 122 | .. Members of Errors 123 | 124 | エラーのメンバー 125 | ================ 126 | 127 | .. - ``error.selector``: A ``bytes4`` value containing the error selector. 128 | 129 | - ``error.selector``: エラーセレクタを含む ``bytes4`` の値。 130 | -------------------------------------------------------------------------------- /docs/examples/voting.rst: -------------------------------------------------------------------------------- 1 | .. index:: voting, ballot 2 | 3 | .. _voting: 4 | 5 | **** 6 | 投票 7 | **** 8 | 9 | 次のコントラクトは非常に複雑ですが、Solidityの機能の多くを紹介しています。 10 | これは、投票コントラクトを実装しています。 11 | もちろん、電子投票の主な問題点は、いかにして正しい人に投票権を割り当てるか、いかにして操作を防ぐかです。 12 | ここですべての問題を解決するわけではありませんが、少なくとも、投票数のカウントが **自動的** に行われ、同時に **完全に透明** であるように、委任投票を行う方法を紹介する予定です。 13 | 14 | アイデアとしては、1つの投票用紙に対して1つのコントラクトを作成し、それぞれの選択肢に短い名前をつけます。 15 | そして、議長を務めるコントラクトの作成者が、各アドレスに個別に投票権を与えます。 16 | 17 | そして、そのアドレスを持つ人は、自分で投票するか、信頼できる人に投票を委任するかを選ぶことができます。 18 | 19 | 投票時間終了後、最も多くの票を獲得したプロポーザルを ``winningProposal()`` に返します。 20 | 21 | .. code-block:: solidity 22 | 23 | // SPDX-License-Identifier: GPL-3.0 24 | pragma solidity >=0.7.0 <0.9.0; 25 | /// @title 委任による投票 26 | contract Ballot { 27 | // 新しい複合型を宣言し、後で変数に使用します。 28 | // 一人の投票者を表します。 29 | struct Voter { 30 | uint weight; // ウェイトは委任により蓄積される 31 | bool voted; // trueならすでにその人は投票済み 32 | address delegate; // 委任先 33 | uint vote; // 投票したプロポーザルのインデックス 34 | } 35 | 36 | // 1つのプロポーザルの型です。 37 | struct Proposal { 38 | bytes32 name; // 短い名前（上限32バイト） 39 | uint voteCount; // 投票数 40 | } 41 | 42 | address public chairperson; 43 | 44 | // アドレスごとに `Voter` 構造体を格納する状態変数を宣言しています。 45 | mapping(address => Voter) public voters; 46 | 47 | // `Proposal` 構造体の動的サイズの配列 48 | Proposal[] public proposals; 49 | 50 | /// `proposalNames` のいずれかを選択するための新しい投票を作成します。 51 | constructor(bytes32[] memory proposalNames) { 52 | chairperson = msg.sender; 53 | voters[chairperson].weight = 1; 54 | 55 | // 指定されたプロポーザル名ごとに新しいプロポーザルオブジェクトを作成し、配列の末尾に追加します。 56 | for (uint i = 0; i < proposalNames.length; i++) { 57 | // `Proposal({...})` は一時的なプロポーザルオブジェクトを作成し、 `proposals.push(...)` はそれを `proposals` の末尾に追加します。 58 | proposals.push(Proposal({ 59 | name: proposalNames[i], 60 | voteCount: 0 61 | })); 62 | } 63 | } 64 | 65 | // `voter` にこの投票用紙に投票する権利を与えます。 66 | // `chairperson` だけが呼び出すことができます。 67 | function giveRightToVote(address voter) external { 68 | // `require` の第一引数の評価が `false` の場合、実行は終了し、状態やEther残高のすべての変更がリバートされます。 69 | // これは、古いEVMのバージョンでは全てのガスを消費していましたが、今はそうではありません。 70 | // 関数が正しく呼び出されているかどうかを確認するために、 `require` を使用するのは良いアイデアです。 71 | // 第二引数として、何が悪かったのかについての説明を記述することもできます。 72 | require( 73 | msg.sender == chairperson, 74 | "Only chairperson can give right to vote." 75 | ); 76 | require( 77 | !voters[voter].voted, 78 | "The voter already voted." 79 | ); 80 | require(voters[voter].weight == 0); 81 | voters[voter].weight = 1; 82 | } 83 | 84 | /// 投票者 `to` に投票を委任します。 85 | function delegate(address to) external { 86 | // 参照を代入 87 | Voter storage sender = voters[msg.sender]; 88 | require(sender.weight != 0, "You have no right to vote"); 89 | require(!sender.voted, "You already voted."); 90 | 91 | require(to != msg.sender, "Self-delegation is disallowed."); 92 | 93 | // `to` もデリゲートされている限り、デリゲートを転送します。 94 | // 一般的に、このようなループは非常に危険です。 95 | // なぜなら、ループが長くなりすぎると、ブロック内で利用できる量よりも多くのガスが必要になる可能性があるからです。 96 | // この場合、デリゲーションは実行されません。 97 | // しかし、他の状況では、このようなループによってコントラクトが完全に「スタック」してしまう可能性があります。 98 | while (voters[to].delegate != address(0)) { 99 | to = voters[to].delegate; 100 | 101 | // 委任でループを発見した場合、委任は許可されません。 102 | require(to != msg.sender, "Found loop in delegation."); 103 | } 104 | 105 | Voter storage delegate_ = voters[to]; 106 | 107 | // 投票者は、投票できないアカウントに委任できません。 108 | require(delegate_.weight >= 1); 109 | 110 | // `sender` は参照なので、`voters[msg.sender]` を修正します。 111 | sender.voted = true; 112 | sender.delegate = to; 113 | 114 | if (delegate_.voted) { 115 | // 代表者が既に投票している場合は、直接投票数に加算する 116 | proposals[delegate_.vote].voteCount += sender.weight; 117 | } else { 118 | // 代表者がまだ投票していない場合は、その人の重みに加える 119 | delegate_.weight += sender.weight; 120 | } 121 | } 122 | 123 | /// あなたの投票権（あなたに委任された投票権を含む）をプロポーザル `proposals[proposal].name` に与えてください。 124 | function vote(uint proposal) external { 125 | Voter storage sender = voters[msg.sender]; 126 | require(sender.weight != 0, "Has no right to vote"); 127 | require(!sender.voted, "Already voted."); 128 | sender.voted = true; 129 | sender.vote = proposal; 130 | 131 | // もし `proposal` が配列の範囲外であれば、自動的にスローされ、すべての変更が取り消されます。 132 | proposals[proposal].voteCount += sender.weight; 133 | } 134 | 135 | /// @dev 以前の投票をすべて考慮した上で、当選案を計算します。 136 | function winningProposal() public view 137 | returns (uint winningProposal_) 138 | { 139 | uint winningVoteCount = 0; 140 | for (uint p = 0; p < proposals.length; p++) { 141 | if (proposals[p].voteCount > winningVoteCount) { 142 | winningVoteCount = proposals[p].voteCount; 143 | winningProposal_ = p; 144 | } 145 | } 146 | } 147 | 148 | // winningProposal()関数をコールして、プロポーザルの配列に含まれる当選案のインデックスを取得し、当選案の名前を返します。 149 | function winnerName() external view 150 | returns (bytes32 winnerName_) 151 | { 152 | winnerName_ = proposals[winningProposal()].name; 153 | } 154 | } 155 | 156 | 改良の可能性 157 | ============ 158 | 159 | .. Currently, many transactions are needed to assign the rights to vote to all participants. 160 | .. Moreover, if two or more proposals have the same number of votes, ``winningProposal()`` is not able to register a tie. 161 | .. Can you think of a way to fix these issues? 162 | 163 | 現状では、すべての参加者に投票権を割り当てるために多くのトランザクションが必要です。 164 | また、2つ以上の提案の投票数が同じ場合、 ``winningProposal()`` は同票を登録できません。 165 | これらの問題を解決する方法を考えてみてください。 166 | -------------------------------------------------------------------------------- /docs/bugs.rst: -------------------------------------------------------------------------------- 1 | .. index:: Bugs 2 | 3 | .. _known_bugs: 4 | 5 | ################## 6 | 既知のバグのリスト 7 | ################## 8 | 9 | .. Below, you can find a JSON-formatted list of some of the known security-relevant bugs in the 10 | .. Solidity compiler. The file itself is hosted in the `GitHub repository 11 | .. `_. 12 | .. The list stretches back as far as version 0.3.0, bugs known to be present only 13 | .. in versions preceding that are not listed. 14 | 15 | 以下に、Solidityコンパイラのセキュリティ関連の既知のバグをJSON形式でリストアップしています。 16 | このファイルは `GitHubリポジトリ `_ にあります。 17 | このリストはバージョン0.3.0までさかのぼりますが、それ以前のバージョンにしか存在しないことがわかっているバグはリストに含まれていません。 18 | 19 | .. There is another file called `bugs_by_version.json 20 | .. `_, 21 | .. which can be used to check which bugs affect a specific version of the compiler. 22 | 23 | また、 `bugs_by_version.json `_ というファイルがあり、特定のバージョンのコンパイラーに影響を与えるバグを確認できます。 24 | 25 | .. Contract source verification tools and also other tools interacting with 26 | .. contracts should consult this list according to the following criteria: 27 | 28 | コントラクトソース検証ツール、およびコントラクトと相互作用するその他のツールは、以下の基準に従ってこのリストを参照する必要があります。 29 | 30 | .. - It is mildly suspicious if a contract was compiled with a nightly compiler version instead of a released version. This list does not keep track of unreleased or nightly versions. 31 | 32 | - コントラクトがリリースされたバージョンではなく、nightlyコンパイラのバージョンでコンパイルされた場合は、少し疑わしいです。 33 | このリストでは、リリースされていないバージョンやnightlyバージョンの記録は取っていません。 34 | 35 | .. - It is also mildly suspicious if a contract was compiled with a version that was 36 | .. not the most recent at the time the contract was created. For contracts 37 | .. created from other contracts, you have to follow the creation chain 38 | .. back to a transaction and use the date of that transaction as creation date. 39 | 40 | - また、コントラクトが作成された時点で最新ではないバージョンでコンパイルされていた場合、少し疑わしいです。 41 | 他のコントラクトから作成されたコントラクトについては、作成の連鎖をトランザクションまでさかのぼり、そのトランザクションの日付を作成日として使用する必要があります。 42 | 43 | .. - It is highly suspicious if a contract was compiled with a compiler that 44 | .. contains a known bug and the contract was created at a time where a newer 45 | .. compiler version containing a fix was already released. 46 | 47 | - 既知のバグを含むコンパイラを使用してコントラクトを作成し、修正プログラムを含む新しいバージョンのコンパイラがすでにリリースされている時期にコントラクトが作成された場合、非常に疑わしいです。 48 | 49 | .. The JSON file of known bugs below is an array of objects, one for each bug, with the following keys: 50 | 51 | 以下の既知のバグのJSONファイルは、各バグに1つずつ、以下のキーを持つオブジェクトの配列です。 52 | 53 | .. uid 54 | .. Unique identifier given to the bug in the form of ``SOL--``. 55 | .. It is possible that multiple entries exists with the same uid. This means 56 | .. multiple version ranges are affected by the same bug. 57 | .. name 58 | .. Unique name given to the bug 59 | .. summary 60 | .. Short description of the bug 61 | .. description 62 | .. Detailed description of the bug 63 | .. link 64 | .. URL of a website with more detailed information, optional 65 | .. introduced 66 | .. The first published compiler version that contained the bug, optional 67 | .. fixed 68 | .. The first published compiler version that did not contain the bug anymore 69 | .. publish 70 | .. The date at which the bug became known publicly, optional 71 | .. severity 72 | .. Severity of the bug: very low, low, medium, high. Takes into account 73 | .. discoverability in contract tests, likelihood of occurrence and 74 | .. potential damage by exploits. 75 | .. conditions 76 | .. Conditions that have to be met to trigger the bug. The following 77 | .. keys can be used: 78 | .. ``optimizer``, Boolean value which means that the optimizer has to be switched on to enable the bug. 79 | .. ``evmVersion``, a string that indicates which EVM version compiler settings trigger the bug. 80 | .. The string can contain comparison operators. 81 | .. For example, ``">=constantinople"`` means that the bug is present when the EVM version is set to ``constantinople`` or 82 | .. later. 83 | .. If no conditions are given, assume that the bug is present. 84 | .. check 85 | .. This field contains different checks that report whether the smart contract contains the bug or not. 86 | .. The first type of check are JavaScript regular expressions that are to be matched against the source code ("source-regex") if the bug is present. 87 | .. If there is no match, then the bug is very likely not present. 88 | .. If there is a match, the bug might be present. 89 | .. For improved accuracy, the checks should be applied to the source code after stripping comments. 90 | .. The second type of check are patterns to be checked on the compact AST of 91 | .. the Solidity program ("ast-compact-json-path"). The specified search query 92 | .. is a `JsonPath `_ expression. 93 | .. If at least one path of the Solidity AST matches the query, the bug is 94 | .. likely present. 95 | 96 | uid 97 | ``SOL--`` 形式でバグに与えられた一意の識別子。 98 | 同じuidで複数のエントリが存在する可能性があります。 99 | name 100 | バグに付けられたユニークな名前。 101 | summary 102 | バグの短い説明。 103 | description 104 | バグの詳細な説明。 105 | link 106 | より詳細な情報があるウェブサイトのURL。 107 | オプション。 108 | introduced 109 | バグを含んで最初に公開されたコンパイラバージョン。 110 | オプション。 111 | fixed 112 | バグを含まなくなって最初に公開されたコンパイラバージョン。 113 | publish 114 | バグが公に知られるようになった日付。 115 | オプション。 116 | severity 117 | バグの深刻度: very low、low、medium、high。 118 | コントラクトテストでの発見可能性、発生の可能性、悪用による被害の可能性を考慮しています。 119 | conditions 120 | バグを発生させるために満たさなければならない条件。 121 | 以下のキーが使用できます。 122 | ``optimizer``: ブール値。 123 | バグを有効にするにはオプティマイザがオンになっていなければならないことを意味します。 124 | ``evmVersion``: どのEVMバージョンのコンパイラ設定がバグを引き起こすかを示す文字列。 125 | この文字列には比較演算子を含めることができます。 126 | 例えば、 ``">=constantinople"`` は EVM バージョンが ``constantinople`` 以降に設定されている場合にバグが発生することを意味します。 127 | check 128 | このフィールドには、スマートコントラクトにバグが含まれているかどうかを報告するさまざまなチェックが含まれます。 129 | 最初のタイプのチェックは、バグが存在する場合にソースコード（「source-regex」）に対してマッチされるJavaScriptの正規表現です。 130 | 一致しない場合は、バグが存在しない可能性が高いです。 131 | 一致するものがあれば、そのバグは存在する可能性があります。 132 | 精度を上げるためには、コメントを削除した後のソースコードにチェックを適用する必要があります。 133 | 2番目のタイプのチェックは、SolidityプログラムのコンパクトASTにチェックするパターンです（「ast-compact-json-path」）。 134 | 指定された検索クエリは、 `JsonPath `_ の式です。 135 | SolidityのASTの少なくとも1つのパスがクエリにマッチする場合、バグが存在する可能性が高いです。 136 | 137 | .. literalinclude:: bugs.json 138 | :language: js 139 | 140 | -------------------------------------------------------------------------------- /docs/Makefile: -------------------------------------------------------------------------------- 1 | # Makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = -W 6 | SPHINXBUILD = sphinx-build 7 | PAPER = 8 | BUILDDIR = _build 9 | 10 | # User-friendly check for sphinx-build 11 | ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1) 12 | $(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/) 13 | endif 14 | 15 | # Internal variables. 16 | PAPEROPT_a4 = -D latex_paper_size=a4 17 | PAPEROPT_letter = -D latex_paper_size=letter 18 | ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . 19 | # the i18n builder cannot share the environment and doctrees with the others 20 | I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . 21 | 22 | .PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext 23 | 24 | help: 25 | @echo "Please use \`make ' where is one of" 26 | @echo " html to make standalone HTML files" 27 | @echo " dirhtml to make HTML files named index.html in directories" 28 | @echo " singlehtml to make a single large HTML file" 29 | @echo " pickle to make pickle files" 30 | @echo " json to make JSON files" 31 | @echo " htmlhelp to make HTML files and a HTML help project" 32 | @echo " qthelp to make HTML files and a qthelp project" 33 | @echo " devhelp to make HTML files and a Devhelp project" 34 | @echo " epub to make an epub" 35 | @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" 36 | @echo " latexpdf to make LaTeX files and run them through pdflatex" 37 | @echo " text to make text files" 38 | @echo " man to make manual pages" 39 | @echo " texinfo to make Texinfo files" 40 | @echo " info to make Texinfo files and run them through makeinfo" 41 | @echo " gettext to make PO message catalogs" 42 | @echo " changes to make an overview of all changed/added/deprecated items" 43 | @echo " xml to make Docutils-native XML files" 44 | @echo " pseudoxml to make pseudoxml-XML files for display purposes" 45 | @echo " linkcheck to check all external links for integrity" 46 | @echo " doctest to run all doctests embedded in the documentation (if enabled)" 47 | 48 | clean: 49 | rm -rf $(BUILDDIR)/* 50 | 51 | html: 52 | $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html 53 | @echo 54 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." 55 | 56 | dirhtml: 57 | $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml 58 | @echo 59 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." 60 | 61 | singlehtml: 62 | $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml 63 | @echo 64 | @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." 65 | 66 | pickle: 67 | $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle 68 | @echo 69 | @echo "Build finished; now you can process the pickle files." 70 | 71 | json: 72 | $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json 73 | @echo 74 | @echo "Build finished; now you can process the JSON files." 75 | 76 | htmlhelp: 77 | $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp 78 | @echo 79 | @echo "Build finished; now you can run HTML Help Workshop with the" \ 80 | ".hhp project file in $(BUILDDIR)/htmlhelp." 81 | 82 | qthelp: 83 | $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp 84 | @echo 85 | @echo "Build finished; now you can run "qcollectiongenerator" with the" \ 86 | ".qhcp project file in $(BUILDDIR)/qthelp, like this:" 87 | @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Solidity.qhcp" 88 | @echo "To view the help file:" 89 | @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Solidity.qhc" 90 | 91 | devhelp: 92 | $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp 93 | @echo 94 | @echo "Build finished." 95 | @echo "To view the help file:" 96 | @echo "# mkdir -p $$HOME/.local/share/devhelp/Solidity" 97 | @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Solidity" 98 | @echo "# devhelp" 99 | 100 | epub: 101 | $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub 102 | @echo 103 | @echo "Build finished. The epub file is in $(BUILDDIR)/epub." 104 | 105 | latex: 106 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 107 | @echo 108 | @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." 109 | @echo "Run \`make' in that directory to run these through (pdf)latex" \ 110 | "(use \`make latexpdf' here to do that automatically)." 111 | 112 | latexpdf: 113 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 114 | @echo "Running LaTeX files through pdflatex..." 115 | $(MAKE) -C $(BUILDDIR)/latex all-pdf 116 | @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." 117 | 118 | text: 119 | $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text 120 | @echo 121 | @echo "Build finished. The text files are in $(BUILDDIR)/text." 122 | 123 | man: 124 | $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man 125 | @echo 126 | @echo "Build finished. The manual pages are in $(BUILDDIR)/man." 127 | 128 | texinfo: 129 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 130 | @echo 131 | @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo." 132 | @echo "Run \`make' in that directory to run these through makeinfo" \ 133 | "(use \`make info' here to do that automatically)." 134 | 135 | info: 136 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 137 | @echo "Running Texinfo files through makeinfo..." 138 | make -C $(BUILDDIR)/texinfo info 139 | @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo." 140 | 141 | gettext: 142 | $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale 143 | @echo 144 | @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale." 145 | 146 | changes: 147 | $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes 148 | @echo 149 | @echo "The overview file is in $(BUILDDIR)/changes." 150 | 151 | linkcheck: 152 | $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck 153 | @echo 154 | @echo "Link check complete; look for any errors in the above output " \ 155 | "or in $(BUILDDIR)/linkcheck/output.txt." 156 | 157 | doctest: 158 | $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest 159 | @echo "Testing of doctests in the sources finished, look at the " \ 160 | "results in $(BUILDDIR)/doctest/output.txt." 161 | 162 | xml: 163 | $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml 164 | @echo 165 | @echo "Build finished. The XML files are in $(BUILDDIR)/xml." 166 | 167 | pseudoxml: 168 | $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml 169 | @echo 170 | @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml." 171 | -------------------------------------------------------------------------------- /docs/_static/css/pygments.css: -------------------------------------------------------------------------------- 1 | pre { 2 | line-height: 125%; 3 | } 4 | 5 | td.linenos .normal { 6 | color: inherit; 7 | background-color: transparent; 8 | padding-left: 5px; 9 | padding-right: 5px; 10 | } 11 | 12 | span.linenos { 13 | color: inherit; 14 | background-color: transparent; 15 | padding-left: 5px; 16 | padding-right: 5px; 17 | } 18 | 19 | td.linenos .special { 20 | color: #000000; 21 | background-color: #ffffc0; 22 | padding-left: 5px; 23 | padding-right: 5px; 24 | } 25 | 26 | span.linenos.special { 27 | color: #000000; 28 | background-color: #ffffc0; 29 | padding-left: 5px; 30 | padding-right: 5px; 31 | } 32 | 33 | .highlight .hll { 34 | background-color: #ffffcc 35 | } 36 | 37 | .highlight { 38 | background: #eeffcc; 39 | } 40 | 41 | .highlight .c { 42 | color: #408090; 43 | font-style: italic 44 | } 45 | 46 | /* Comment */ 47 | .highlight .err { 48 | border: 1px solid #FF0000 49 | } 50 | 51 | /* Error */ 52 | .highlight .k { 53 | color: #007020; 54 | font-weight: bold 55 | } 56 | 57 | /* Keyword */ 58 | .highlight .o { 59 | color: #666666 60 | } 61 | 62 | /* Operator */ 63 | .highlight .ch { 64 | color: #408090; 65 | font-style: italic 66 | } 67 | 68 | /* Comment.Hashbang */ 69 | .highlight .cm { 70 | color: #408090; 71 | font-style: italic 72 | } 73 | 74 | /* Comment.Multiline */ 75 | .highlight .cp { 76 | color: #007020 77 | } 78 | 79 | /* Comment.Preproc */ 80 | .highlight .cpf { 81 | color: #408090; 82 | font-style: italic 83 | } 84 | 85 | /* Comment.PreprocFile */ 86 | .highlight .c1 { 87 | color: #408090; 88 | font-style: italic 89 | } 90 | 91 | /* Comment.Single */ 92 | .highlight .cs { 93 | color: #408090; 94 | background-color: #fff0f0 95 | } 96 | 97 | /* Comment.Special */ 98 | .highlight .gd { 99 | color: #A00000 100 | } 101 | 102 | /* Generic.Deleted */ 103 | .highlight .ge { 104 | font-style: italic 105 | } 106 | 107 | /* Generic.Emph */ 108 | .highlight .gr { 109 | color: #FF0000 110 | } 111 | 112 | /* Generic.Error */ 113 | .highlight .gh { 114 | color: #000080; 115 | font-weight: bold 116 | } 117 | 118 | /* Generic.Heading */ 119 | .highlight .gi { 120 | color: #00A000 121 | } 122 | 123 | /* Generic.Inserted */ 124 | .highlight .go { 125 | color: #333333 126 | } 127 | 128 | /* Generic.Output */ 129 | .highlight .gp { 130 | color: #c65d09; 131 | font-weight: bold 132 | } 133 | 134 | /* Generic.Prompt */ 135 | .highlight .gs { 136 | font-weight: bold 137 | } 138 | 139 | /* Generic.Strong */ 140 | .highlight .gu { 141 | color: #800080; 142 | font-weight: bold 143 | } 144 | 145 | /* Generic.Subheading */ 146 | .highlight .gt { 147 | color: #0044DD 148 | } 149 | 150 | /* Generic.Traceback */ 151 | .highlight .kc { 152 | color: #007020; 153 | font-weight: bold 154 | } 155 | 156 | /* Keyword.Constant */ 157 | .highlight .kd { 158 | color: #007020; 159 | font-weight: bold 160 | } 161 | 162 | /* Keyword.Declaration */ 163 | .highlight .kn { 164 | color: #007020; 165 | font-weight: bold 166 | } 167 | 168 | /* Keyword.Namespace */ 169 | .highlight .kp { 170 | color: #007020 171 | } 172 | 173 | /* Keyword.Pseudo */ 174 | .highlight .kr { 175 | color: #007020; 176 | font-weight: bold 177 | } 178 | 179 | /* Keyword.Reserved */ 180 | .highlight .kt { 181 | color: #902000 182 | } 183 | 184 | /* Keyword.Type */ 185 | .highlight .m { 186 | color: #208050 187 | } 188 | 189 | /* Literal.Number */ 190 | .highlight .s { 191 | color: #4070a0 192 | } 193 | 194 | /* Literal.String */ 195 | .highlight .na { 196 | color: #4070a0 197 | } 198 | 199 | /* Name.Attribute */ 200 | .highlight .nb { 201 | color: #007020 202 | } 203 | 204 | /* Name.Builtin */ 205 | .highlight .nc { 206 | color: #0e84b5; 207 | font-weight: bold 208 | } 209 | 210 | /* Name.Class */ 211 | .highlight .no { 212 | color: #60add5 213 | } 214 | 215 | /* Name.Constant */ 216 | .highlight .nd { 217 | color: #555555; 218 | font-weight: bold 219 | } 220 | 221 | /* Name.Decorator */ 222 | .highlight .ni { 223 | color: #d55537; 224 | font-weight: bold 225 | } 226 | 227 | /* Name.Entity */ 228 | .highlight .ne { 229 | color: #007020 230 | } 231 | 232 | /* Name.Exception */ 233 | .highlight .nf { 234 | color: #06287e 235 | } 236 | 237 | /* Name.Function */ 238 | .highlight .nl { 239 | color: #002070; 240 | font-weight: bold 241 | } 242 | 243 | /* Name.Label */ 244 | .highlight .nn { 245 | color: #0e84b5; 246 | font-weight: bold 247 | } 248 | 249 | /* Name.Namespace */ 250 | .highlight .nt { 251 | color: #062873; 252 | font-weight: bold 253 | } 254 | 255 | /* Name.Tag */ 256 | .highlight .nv { 257 | color: #bb60d5 258 | } 259 | 260 | /* Name.Variable */ 261 | .highlight .ow { 262 | color: #007020; 263 | font-weight: bold 264 | } 265 | 266 | /* Operator.Word */ 267 | .highlight .w { 268 | color: #bbbbbb 269 | } 270 | 271 | /* Text.Whitespace */ 272 | .highlight .mb { 273 | color: #208050 274 | } 275 | 276 | /* Literal.Number.Bin */ 277 | .highlight .mf { 278 | color: #208050 279 | } 280 | 281 | /* Literal.Number.Float */ 282 | .highlight .mh { 283 | color: #208050 284 | } 285 | 286 | /* Literal.Number.Hex */ 287 | .highlight .mi { 288 | color: #208050 289 | } 290 | 291 | /* Literal.Number.Integer */ 292 | .highlight .mo { 293 | color: #208050 294 | } 295 | 296 | /* Literal.Number.Oct */ 297 | .highlight .sa { 298 | color: #4070a0 299 | } 300 | 301 | /* Literal.String.Affix */ 302 | .highlight .sb { 303 | color: #4070a0 304 | } 305 | 306 | /* Literal.String.Backtick */ 307 | .highlight .sc { 308 | color: #4070a0 309 | } 310 | 311 | /* Literal.String.Char */ 312 | .highlight .dl { 313 | color: #4070a0 314 | } 315 | 316 | /* Literal.String.Delimiter */ 317 | .highlight .sd { 318 | color: #4070a0; 319 | font-style: italic 320 | } 321 | 322 | /* Literal.String.Doc */ 323 | .highlight .s2 { 324 | color: #4070a0 325 | } 326 | 327 | /* Literal.String.Double */ 328 | .highlight .se { 329 | color: #4070a0; 330 | font-weight: bold 331 | } 332 | 333 | /* Literal.String.Escape */ 334 | .highlight .sh { 335 | color: #4070a0 336 | } 337 | 338 | /* Literal.String.Heredoc */ 339 | .highlight .si { 340 | color: #70a0d0; 341 | font-style: italic 342 | } 343 | 344 | /* Literal.String.Interpol */ 345 | .highlight .sx { 346 | color: #c65d09 347 | } 348 | 349 | /* Literal.String.Other */ 350 | .highlight .sr { 351 | color: #235388 352 | } 353 | 354 | /* Literal.String.Regex */ 355 | .highlight .s1 { 356 | color: #4070a0 357 | } 358 | 359 | /* Literal.String.Single */ 360 | .highlight .ss { 361 | color: #517918 362 | } 363 | 364 | /* Literal.String.Symbol */ 365 | .highlight .bp { 366 | color: #007020 367 | } 368 | 369 | /* Name.Builtin.Pseudo */ 370 | .highlight .fm { 371 | color: #06287e 372 | } 373 | 374 | /* Name.Function.Magic */ 375 | .highlight .vc { 376 | color: #bb60d5 377 | } 378 | 379 | /* Name.Variable.Class */ 380 | .highlight .vg { 381 | color: #bb60d5 382 | } 383 | 384 | /* Name.Variable.Global */ 385 | .highlight .vi { 386 | color: #bb60d5 387 | } 388 | 389 | /* Name.Variable.Instance */ 390 | .highlight .vm { 391 | color: #bb60d5 392 | } 393 | 394 | /* Name.Variable.Magic */ 395 | .highlight .il { 396 | color: #208050 397 | } 398 | 399 | /* Literal.Number.Integer.Long */ -------------------------------------------------------------------------------- /docs/contracts/constant-state-variables.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! constant 2 | 3 | .. _constants: 4 | 5 | **************************************** 6 | 定数の状態変数とイミュータブルの状態変数 7 | **************************************** 8 | 9 | 状態変数は ``constant`` または ``immutable`` として宣言できます。 10 | どちらの場合も、コントラクトが構築された後は、変数を変更できません。 11 | ``constant`` 変数の場合はコンパイル時に値を固定する必要がありますが、 ``immutable`` の場合はコンストラクション時にも値を代入できます。 12 | 13 | また、ファイルレベルで ``constant`` 変数を定義することも可能です。 14 | 15 | .. Every occurrence of such a variable in the source is replaced by its underlying value and the compiler does not reserve a storage slot for it. 16 | .. It cannot be assigned a slot in transient storage using the ``transient`` keyword either. 17 | 18 | このような変数は、ソースコード内で出現するたびにその指定した値に置き換えられ、コンパイラはそのためのストレージスロットを確保しません。 19 | また、 ``transient`` キーワードを使用してトランジェントストレージ内にスロットを割り当てることもできません。 20 | 21 | .. Compared to regular state variables, the gas costs of constant and immutable variables 22 | .. are much lower. For a constant variable, the expression assigned to it is copied to 23 | .. all the places where it is accessed and also re-evaluated each time. This allows for local 24 | .. optimizations. Immutable variables are evaluated once at construction time and their value 25 | .. is copied to all the places in the code where they are accessed. For these values, 26 | .. 32 bytes are reserved, even if they would fit in fewer bytes. Due to this, constant values 27 | .. can sometimes be cheaper than immutable values. 28 | 29 | 通常の状態変数と比較して、定数変数やイミュータブル変数のガスコストは非常に低くなります。 30 | 定数変数の場合、それに割り当てられた式は、アクセスされるすべての場所にコピーされ、また毎回再評価されます。 31 | これにより、局所的な最適化が可能になります。 32 | イミュータブルの変数は、構築時に一度だけ評価され、その値はコード内のアクセスされるすべての場所にコピーされます。 33 | これらの値のために、たとえそれより少ないバイト数で収まるとしても、32バイトが確保されます。 34 | このため、定数値の方がイミュータブル値よりもコストが低い場合があります。 35 | 36 | 現時点では、定数やイミュータブルのすべての型が実装されているわけではありません。 37 | サポートされているのは、 :ref:`strings ` （定数のみ）と :ref:`値型` のみです。 38 | 39 | .. code-block:: solidity 40 | 41 | // SPDX-License-Identifier: GPL-3.0 42 | pragma solidity ^0.8.21; 43 | 44 | uint constant X = 32**22 + 8; 45 | 46 | contract C { 47 | string constant TEXT = "abc"; 48 | bytes32 constant MY_HASH = keccak256("abc"); 49 | uint immutable decimals = 18; 50 | uint immutable maxBalance; 51 | address immutable owner = msg.sender; 52 | 53 | constructor(uint decimals_, address ref) { 54 | if (decimals_ != 0) 55 | // Immutables are only immutable when deployed. 56 | // At construction time they can be assigned to any number of times. 57 | decimals = decimals_; 58 | 59 | // Assignments to immutables can even access the environment. 60 | maxBalance = ref.balance; 61 | } 62 | 63 | function isBalanceTooHigh(address other) public view returns (bool) { 64 | return other.balance > maxBalance; 65 | } 66 | } 67 | 68 | 定数 69 | ==== 70 | 71 | .. For ``constant`` variables, the value has to be a constant at compile time and it has to be 72 | .. assigned where the variable is declared. Any expression 73 | .. that accesses storage, blockchain data (e.g. ``block.timestamp``, ``address(this).balance`` or 74 | .. ``block.number``) or 75 | .. execution data (``msg.value`` or ``gasleft()``) or makes calls to external contracts is disallowed. Expressions 76 | .. that might have a side-effect on memory allocation are allowed, but those that 77 | .. might have a side-effect on other memory objects are not. The built-in functions 78 | .. ``keccak256``, ``sha256``, ``ripemd160``, ``ecrecover``, ``addmod`` and ``mulmod`` 79 | .. are allowed (even though, with the exception of ``keccak256``, they do call external contracts). 80 | 81 | ``constant`` 変数については、コンパイル時に値が定数である必要があり、変数が宣言された場所で代入されなければなりません。 82 | ストレージ、ブロックチェーンデータ（例: ``block.timestamp`` 、 ``address(this).balance`` 、 ``block.number`` ）、実行データ（ ``msg.value`` 、 ``gasleft()`` ）にアクセスしたり、外部コントラクトを呼び出したりする式はすべて許可されていません。 83 | メモリの割り当てに副作用を及ぼす可能性のある式は許可されますが、他のメモリオブジェクトに副作用を及ぼす可能性のある式は許可されません。 84 | 組み込み関数の ``keccak256`` 、 ``sha256`` 、 ``ripemd160`` 、 ``ecrecover`` 、 ``addmod`` 、 ``mulmod`` は許可されています（ ``keccak256`` を除いて外部コントラクトをコールしていますが）。 85 | 86 | .. The reason behind allowing side-effects on the memory allocator is that it 87 | .. should be possible to construct complex objects like e.g. lookup-tables. 88 | .. This feature is not yet fully usable. 89 | 90 | メモリアロケータの副作用を許可した理由は、ルックアップテーブルなどの複雑なオブジェクトを構築できるようにするためです。 91 | この機能はまだ完全には使用できません。 92 | 93 | イミュータブル 94 | ============== 95 | 96 | ``immutable`` として宣言された変数は、 ``constant`` として宣言された変数よりも制限が緩いです。 97 | 具体的には、イミュータブルの変数は、コントラクション時に値を代入できます。 98 | その値は、デプロイメントの前であればいつでも変更でき、その後永続的な値になります。 99 | 100 | .. One additional restriction is that immutables can only be assigned to inside expressions for which there is no possibility of being executed after creation. 101 | .. This excludes all modifier definitions and functions other than constructors. 102 | 103 | もう一つの制限として、 ``immutable`` 変数への代入は、その実行が作成後に行われる可能性がない式の中でのみ行うことができます。 104 | これは、すべての modifier 定義およびコンストラクタ以外の関数を除外することを意味します。 105 | 106 | .. There are no restrictions on reading immutable variables. 107 | .. The read is even allowed to happen before the variable is written to for the first time because variables in Solidity always have a well-defined initial value. 108 | .. For this reason it is also allowed to never explicitly assign a value to an immutable. 109 | 110 | ``immutable`` 変数の読み取りには制限はありません。 111 | Solidity では変数には常に明確に定義された初期値があるため、変数が初めて書き込まれる前に読み取ることも許可されています。 112 | このため、 ``immutable`` 変数に明示的に値を代入しないことも許容されます。 113 | 114 | .. warning:: 115 | .. When accessing immutables at construction time, please keep the :ref:`initialization order ` in mind. 116 | .. Even if you provide an explicit initializer, some expressions may end up being evaluated before that initializer, especially when they are at a different level in inheritance hierarchy. 117 | 118 | コンストラクション時に ``immutable`` 変数へアクセスする場合は、:ref:`初期化の順序 ` に注意してください。 119 | 明示的に初期化子を指定した場合でも、特に継承階層の異なるレベルにある場合は、いくつかの式がその初期化子よりも前に評価される可能性があります。 120 | 121 | .. note:: 122 | .. Before Solidity 0.8.21 initialization of immutable variables was more restrictive. 123 | .. Such variables had to be initialized exactly once at construction time and could not be read before then. 124 | 125 | Solidity 0.8.21 より前のバージョンでは、 ``immutable`` 変数の初期化はより制限されていました。 126 | これらの変数はコンストラクション時にちょうど一度だけ初期化される必要があり、それ以前に読み取ることはできませんでした。 127 | 128 | .. The contract creation code generated by the compiler will modify the contract's runtime code before it is returned by replacing all references to immutables with the values assigned to them. 129 | .. This is important if you are comparing the runtime code generated by the compiler with the one actually stored in the blockchain. 130 | .. The compiler outputs where these immutables are located in the deployed bytecode in the ``immutableReferences`` field of the :ref:`compiler JSON standard output `. 131 | 132 | コンパイラが生成したコントラクト作成コードは、イミュータブルへのすべての参照をイミュータブルに割り当てられた値に置き換えることで、コントラクトのランタイムコードを返す前に修正します。 133 | これは、コンパイラによって生成されたランタイムコードと、実際にブロックチェーンに保存されているランタイムコードを比較する場合に重要です。 134 | コンパイラは、デプロイされたバイトコードのどこにこれらのイミュータブルがあるかを :ref:`コンパイラのJSONスタンダードアウトプット ` の ``immutableReferences`` フィールドに出力します。 135 | -------------------------------------------------------------------------------- /docs/make.bat: -------------------------------------------------------------------------------- 1 | @ECHO OFF 2 | 3 | REM Command file for Sphinx documentation 4 | 5 | if "%SPHINXBUILD%" == "" ( 6 | set SPHINXBUILD=sphinx-build 7 | ) 8 | set BUILDDIR=_build 9 | set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% . 10 | set I18NSPHINXOPTS=%SPHINXOPTS% . 11 | if NOT "%PAPER%" == "" ( 12 | set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS% 13 | set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS% 14 | ) 15 | 16 | if "%1" == "" goto help 17 | 18 | if "%1" == "help" ( 19 | :help 20 | echo.Please use `make ^` where ^ is one of 21 | echo. html to make standalone HTML files 22 | echo. dirhtml to make HTML files named index.html in directories 23 | echo. singlehtml to make a single large HTML file 24 | echo. pickle to make pickle files 25 | echo. json to make JSON files 26 | echo. htmlhelp to make HTML files and a HTML help project 27 | echo. qthelp to make HTML files and a qthelp project 28 | echo. devhelp to make HTML files and a Devhelp project 29 | echo. epub to make an epub 30 | echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter 31 | echo. latexpdf to make LaTeX files and run them through pdflatex 32 | echo. text to make text files 33 | echo. man to make manual pages 34 | echo. texinfo to make Texinfo files 35 | echo. gettext to make PO message catalogs 36 | echo. changes to make an overview over all changed/added/deprecated items 37 | echo. xml to make Docutils-native XML files 38 | echo. pseudoxml to make pseudoxml-XML files for display purposes 39 | echo. linkcheck to check all external links for integrity 40 | echo. doctest to run all doctests embedded in the documentation if enabled 41 | goto end 42 | ) 43 | 44 | if "%1" == "clean" ( 45 | for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i 46 | del /q /s %BUILDDIR%\* 47 | goto end 48 | ) 49 | 50 | 51 | %SPHINXBUILD% 2> nul 52 | if errorlevel 9009 ( 53 | echo. 54 | echo.The 'sphinx-build' command was not found. Make sure you have Sphinx 55 | echo.installed, then set the SPHINXBUILD environment variable to point 56 | echo.to the full path of the 'sphinx-build' executable. Alternatively you 57 | echo.may add the Sphinx directory to PATH. 58 | echo. 59 | echo.If you don't have Sphinx installed, grab it from 60 | echo.http://sphinx-doc.org/ 61 | exit /b 1 62 | ) 63 | 64 | if "%1" == "html" ( 65 | %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html 66 | if errorlevel 1 exit /b 1 67 | echo. 68 | echo.Build finished. The HTML pages are in %BUILDDIR%/html. 69 | goto end 70 | ) 71 | 72 | if "%1" == "dirhtml" ( 73 | %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml 74 | if errorlevel 1 exit /b 1 75 | echo. 76 | echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml. 77 | goto end 78 | ) 79 | 80 | if "%1" == "singlehtml" ( 81 | %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml 82 | if errorlevel 1 exit /b 1 83 | echo. 84 | echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml. 85 | goto end 86 | ) 87 | 88 | if "%1" == "pickle" ( 89 | %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle 90 | if errorlevel 1 exit /b 1 91 | echo. 92 | echo.Build finished; now you can process the pickle files. 93 | goto end 94 | ) 95 | 96 | if "%1" == "json" ( 97 | %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json 98 | if errorlevel 1 exit /b 1 99 | echo. 100 | echo.Build finished; now you can process the JSON files. 101 | goto end 102 | ) 103 | 104 | if "%1" == "htmlhelp" ( 105 | %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp 106 | if errorlevel 1 exit /b 1 107 | echo. 108 | echo.Build finished; now you can run HTML Help Workshop with the ^ 109 | .hhp project file in %BUILDDIR%/htmlhelp. 110 | goto end 111 | ) 112 | 113 | if "%1" == "qthelp" ( 114 | %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp 115 | if errorlevel 1 exit /b 1 116 | echo. 117 | echo.Build finished; now you can run "qcollectiongenerator" with the ^ 118 | .qhcp project file in %BUILDDIR%/qthelp, like this: 119 | echo.^> qcollectiongenerator %BUILDDIR%\qthelp\Solidity.qhcp 120 | echo.To view the help file: 121 | echo.^> assistant -collectionFile %BUILDDIR%\qthelp\Solidity.ghc 122 | goto end 123 | ) 124 | 125 | if "%1" == "devhelp" ( 126 | %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp 127 | if errorlevel 1 exit /b 1 128 | echo. 129 | echo.Build finished. 130 | goto end 131 | ) 132 | 133 | if "%1" == "epub" ( 134 | %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub 135 | if errorlevel 1 exit /b 1 136 | echo. 137 | echo.Build finished. The epub file is in %BUILDDIR%/epub. 138 | goto end 139 | ) 140 | 141 | if "%1" == "latex" ( 142 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 143 | if errorlevel 1 exit /b 1 144 | echo. 145 | echo.Build finished; the LaTeX files are in %BUILDDIR%/latex. 146 | goto end 147 | ) 148 | 149 | if "%1" == "latexpdf" ( 150 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 151 | cd %BUILDDIR%/latex 152 | make all-pdf 153 | cd %BUILDDIR%/.. 154 | echo. 155 | echo.Build finished; the PDF files are in %BUILDDIR%/latex. 156 | goto end 157 | ) 158 | 159 | if "%1" == "text" ( 160 | %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text 161 | if errorlevel 1 exit /b 1 162 | echo. 163 | echo.Build finished. The text files are in %BUILDDIR%/text. 164 | goto end 165 | ) 166 | 167 | if "%1" == "man" ( 168 | %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man 169 | if errorlevel 1 exit /b 1 170 | echo. 171 | echo.Build finished. The manual pages are in %BUILDDIR%/man. 172 | goto end 173 | ) 174 | 175 | if "%1" == "texinfo" ( 176 | %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo 177 | if errorlevel 1 exit /b 1 178 | echo. 179 | echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo. 180 | goto end 181 | ) 182 | 183 | if "%1" == "gettext" ( 184 | %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale 185 | if errorlevel 1 exit /b 1 186 | echo. 187 | echo.Build finished. The message catalogs are in %BUILDDIR%/locale. 188 | goto end 189 | ) 190 | 191 | if "%1" == "changes" ( 192 | %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes 193 | if errorlevel 1 exit /b 1 194 | echo. 195 | echo.The overview file is in %BUILDDIR%/changes. 196 | goto end 197 | ) 198 | 199 | if "%1" == "linkcheck" ( 200 | %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck 201 | if errorlevel 1 exit /b 1 202 | echo. 203 | echo.Link check complete; look for any errors in the above output ^ 204 | or in %BUILDDIR%/linkcheck/output.txt. 205 | goto end 206 | ) 207 | 208 | if "%1" == "doctest" ( 209 | %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest 210 | if errorlevel 1 exit /b 1 211 | echo. 212 | echo.Testing of doctests in the sources finished, look at the ^ 213 | results in %BUILDDIR%/doctest/output.txt. 214 | goto end 215 | ) 216 | 217 | if "%1" == "xml" ( 218 | %SPHINXBUILD% -b xml %ALLSPHINXOPTS% %BUILDDIR%/xml 219 | if errorlevel 1 exit /b 1 220 | echo. 221 | echo.Build finished. The XML files are in %BUILDDIR%/xml. 222 | goto end 223 | ) 224 | 225 | if "%1" == "pseudoxml" ( 226 | %SPHINXBUILD% -b pseudoxml %ALLSPHINXOPTS% %BUILDDIR%/pseudoxml 227 | if errorlevel 1 exit /b 1 228 | echo. 229 | echo.Build finished. The pseudo-XML files are in %BUILDDIR%/pseudoxml. 230 | goto end 231 | ) 232 | 233 | :end 234 | -------------------------------------------------------------------------------- /docs/contracts/events.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! event, ! event; anonymous, ! event; indexed, ! event; topic 2 | 3 | .. _events: 4 | 5 | ******** 6 | イベント 7 | ******** 8 | 9 | .. Solidity events give an abstraction on top of the EVM's logging functionality. 10 | .. Applications can subscribe and listen to these events through the RPC interface of an Ethereum client. 11 | 12 | Solidityのイベントは、EVMのロギング機能の上に抽象化を与えます。 13 | アプリケーションは、EthereumクライアントのRPCインターフェースを介して、これらのイベントをサブスクライブし、リッスンできます。 14 | 15 | .. Events can be defined at file level or as inheritable members of contracts (including interfaces and libraries). 16 | .. When you call them, they cause the arguments to be stored in the transaction's log - a special data structure 17 | .. in the blockchain. These logs are associated with the address of the contract, 18 | .. are incorporated into the blockchain, and stay there as long as a block is 19 | .. accessible (forever as of now, but this might 20 | .. change in the future). The Log and its event data are not accessible from within 21 | .. contracts (not even from the contract that created them). 22 | 23 | イベントは、ファイルレベルで定義することも、コントラクト（インターフェースやライブラリを含む）の継承可能なメンバーとして定義することもできます。 24 | イベントを呼び出すと、引数がトランザクションのログ（ブロックチェーンの特別なデータ構造）に保存されます。 25 | これらのログはそれらをemitしたコントラクトのアドレスに関連付けられ、ブロックチェーンに組み込まれ、ブロックがアクセス可能である限りそこに留まります（現時点では永遠ですが、将来変わるかもしれません）。 26 | ログとそのイベントデータはコントラクト内からはアクセスできません（ログを作成したコントラクトからもアクセスできません）。 27 | 28 | .. It is possible to request a Merkle proof for logs, so if 29 | .. an external entity supplies a contract with such a proof, it can check 30 | .. that the log actually exists inside the blockchain. You have to supply block headers 31 | .. because the contract can only see the last 256 block hashes. 32 | 33 | ログのMerkle証明を要求することが可能なので、外部のエンティティがコントラクトにそのような証明を供給すれば、ログがブロックチェーン内に実際に存在することをチェックできます。 34 | コントラクトは直近の256個のブロックハッシュしか見ることができないため、ブロックヘッダを提供する必要があります。 35 | 36 | .. You can add the attribute ``indexed`` to up to three parameters which adds them 37 | .. to a special data structure known as :ref:`"topics" ` instead of 38 | .. the data part of the log. 39 | .. A topic can only hold a single word (32 bytes) so if you use a :ref:`reference type 40 | .. ` for an indexed argument, the Keccak-256 hash of the value is stored 41 | .. as a topic instead. 42 | 43 | 最大3つのパラメータに ``indexed`` 属性を追加すると、ログのデータ部分ではなく、 :ref:`"topics" ` と呼ばれる特別なデータ構造に追加されます。 44 | トピックは1つのワード（32バイト）しか保持できないため、インデックス付きの引数に :ref:`参照型 ` を使用した場合、値のKeccak-256ハッシュが代わりにトピックとして保存されます。 45 | 46 | ``indexed`` 属性を持たないパラメータはすべて、ログのデータ部分に :ref:`ABIエンコード ` されます。 47 | 48 | .. Topics allow you to search for events, for example when filtering a sequence of 49 | .. blocks for certain events. You can also filter events by the address of the 50 | .. contract that emitted the event. 51 | 52 | トピックを使用すると、イベントを検索できます。 53 | たとえば、一連のブロックを特定のイベントでフィルタリングする場合などです。 54 | また、イベントを発したコントラクトのアドレスでイベントをフィルタリングすることもできます。 55 | 56 | .. For example, the code below uses the web3.js ``subscribe("logs")`` 57 | .. `method `_ to filter 58 | .. logs that match a topic with a certain address value: 59 | 60 | 例えば、以下のコードでは、web3.jsの ``subscribe("logs")`` `メソッド `_ を使用して、特定のアドレス値を持つトピックにマッチするログをフィルタリングしています。 61 | 62 | .. code-block:: javascript 63 | 64 | var options = { 65 | fromBlock: 0, 66 | address: web3.eth.defaultAccount, 67 | topics: ["0x0000000000000000000000000000000000000000000000000000000000000000", null, null] 68 | }; 69 | web3.eth.subscribe('logs', options, function (error, result) { 70 | if (!error) 71 | console.log(result); 72 | }) 73 | .on("data", function (log) { 74 | console.log(log); 75 | }) 76 | .on("changed", function (log) { 77 | }); 78 | 79 | .. The hash of the signature of the event is one of the topics, except if you 80 | .. declared the event with the ``anonymous`` specifier. This means that it is 81 | .. not possible to filter for specific anonymous events by name, you can 82 | .. only filter by the contract address. The advantage of anonymous events 83 | .. is that they are cheaper to deploy and call. It also allows you to declare 84 | .. four indexed arguments rather than three. 85 | 86 | ``anonymous`` 指定子でイベントを宣言した場合を除き、イベントのシグネチャのハッシュはトピックの一つです。 87 | つまり、特定の匿名イベントを名前でフィルタリングできず、コントラクトアドレスでしかフィルタリングできません。 88 | 匿名イベントの利点は、デプロイや呼び出しが安く済むことです。 89 | また、インデックス付きの引数を3つではなく4つ宣言できます。 90 | 91 | .. .. note:: 92 | 93 | .. Since the transaction log only stores the event data and not the type, you have to know the type of the event, including which parameter is indexed and if the event is anonymous in order to correctly interpret the data. 94 | .. In particular, it is possible to "fake" the signature of another event using an anonymous event. 95 | 96 | .. note:: 97 | 98 | トランザクションログにはイベントデータのみが保存され、型は保存されないので、データを正しく解釈するためには、どのパラメータがインデックスされているか、イベントが匿名であるかなど、イベントの型を知る必要があります。 99 | 特に、匿名イベントを使って別のイベントのシグネチャを「偽装」することが可能です。 100 | 101 | .. index:: ! selector; of an event 102 | 103 | .. Members of Events 104 | 105 | イベントのメンバー 106 | ================== 107 | 108 | .. - ``event.selector``: For non-anonymous events, this is a ``bytes32`` value containing the ``keccak256`` hash of the event signature, as used in the default topic. 109 | 110 | - ``event.selector``: 匿名でないイベントの場合、デフォルトのトピックで使用されるイベントシグネチャの ``keccak256`` ハッシュを含む ``bytes32`` 値 111 | 112 | 例 113 | == 114 | 115 | .. code-block:: solidity 116 | 117 | // SPDX-License-Identifier: GPL-3.0 118 | pragma solidity >=0.4.21 <0.9.0; 119 | 120 | contract ClientReceipt { 121 | event Deposit( 122 | address indexed from, 123 | bytes32 indexed id, 124 | uint value 125 | ); 126 | 127 | function deposit(bytes32 id) public payable { 128 | // イベントは `emit` を使って発行され、その後にイベント名と引数 (もしあれば) が括弧で囲まれます。 129 | // このような呼び出しは (深くネストされていても) JavaScript API から `Deposit` をフィルタリングすることで検出できます。 130 | emit Deposit(msg.sender, id, msg.value); 131 | } 132 | } 133 | 134 | JavaScript APIでの使用方法は以下の通りです。 135 | 136 | .. code-block:: javascript 137 | 138 | var abi = /* コンパイラが生成するABI */; 139 | var ClientReceipt = web3.eth.contract(abi); 140 | var clientReceipt = ClientReceipt.at("0x1234...ab67" /* アドレス */); 141 | 142 | var depositEvent = clientReceipt.Deposit(); 143 | 144 | // 変更を監視 145 | depositEvent.watch(function(error, result){ 146 | // resultには、`Deposit` の呼び出しに与えられたインデックス付けされていない引数とトピックが含まれます。 147 | if (!error) 148 | console.log(result); 149 | }); 150 | 151 | // また、コールバックを渡すとすぐに監視を開始します。 152 | var depositEvent = clientReceipt.Deposit(function(error, result) { 153 | if (!error) 154 | console.log(result); 155 | }); 156 | 157 | 上記の出力は以下のようになります（トリミング済み）。 158 | 159 | .. code-block:: json 160 | 161 | { 162 | "returnValues": { 163 | "from": "0x1111…FFFFCCCC", 164 | "id": "0x50…sd5adb20", 165 | "value": "0x420042" 166 | }, 167 | "raw": { 168 | "data": "0x7f…91385", 169 | "topics": ["0xfd4…b4ead7", "0x7f…1a91385"] 170 | } 171 | } 172 | 173 | イベントを理解するための追加資料 174 | ================================ 175 | 176 | - `JavaScriptドキュメント `_ 177 | 178 | - `イベントの使用例 `_ 179 | 180 | - `JSからイベントへのアクセス方法 `_ 181 | -------------------------------------------------------------------------------- /docs/analysing-compilation-output.rst: -------------------------------------------------------------------------------- 1 | .. index:: analyse, asm 2 | 3 | ###################### 4 | コンパイラの出力の解析 5 | ###################### 6 | 7 | .. It is often useful to look at the assembly code generated by the compiler. 8 | .. The generated binary, i.e., the output of ``solc --bin contract.sol``, is generally difficult to read. 9 | .. It is recommended to use the flag ``--asm`` to analyse the assembly output. 10 | .. Even for large contracts, looking at a visual diff of the assembly before and after a change is often very enlightening. 11 | 12 | コンパイラが生成したアセンブリコードを見ると便利なことが多くあります。 13 | 生成されたバイナリ、すなわち ``solc --bin contract.sol`` の出力は、一般に読みにくいです。 14 | フラグ ``--asm`` を使用して、アセンブリ出力を分析することをお勧めします。 15 | 大規模なコントラクトであっても、変更前と変更後のアセンブリの視覚的なdiffを見ることは、しばしば非常に有益です。 16 | 17 | .. Consider the following contract (named, say ``contract.sol``): 18 | 19 | 次のようなコントラクトを考えます（名前は ``contract.sol`` とします）。 20 | 21 | .. code-block:: solidity 22 | 23 | // SPDX-License-Identifier: GPL-3.0 24 | pragma solidity >=0.5.0 <0.9.0; 25 | contract C { 26 | function one() public pure returns (uint) { 27 | return 1; 28 | } 29 | } 30 | 31 | ``solc --asm contract.sol`` の出力は以下のようになります。 32 | 33 | .. code-block:: none 34 | 35 | ======= contract.sol:C ======= 36 | EVM assembly: 37 | /* "contract.sol":0:86 contract C {... */ 38 | mstore(0x40, 0x80) 39 | callvalue 40 | dup1 41 | iszero 42 | tag_1 43 | jumpi 44 | 0x00 45 | dup1 46 | revert 47 | tag_1: 48 | pop 49 | dataSize(sub_0) 50 | dup1 51 | dataOffset(sub_0) 52 | 0x00 53 | codecopy 54 | 0x00 55 | return 56 | stop 57 | 58 | sub_0: assembly { 59 | /* "contract.sol":0:86 contract C {... */ 60 | mstore(0x40, 0x80) 61 | callvalue 62 | dup1 63 | iszero 64 | tag_1 65 | jumpi 66 | 0x00 67 | dup1 68 | revert 69 | tag_1: 70 | pop 71 | jumpi(tag_2, lt(calldatasize, 0x04)) 72 | shr(0xe0, calldataload(0x00)) 73 | dup1 74 | 0x901717d1 75 | eq 76 | tag_3 77 | jumpi 78 | tag_2: 79 | 0x00 80 | dup1 81 | revert 82 | /* "contract.sol":17:84 function one() public pure returns (uint) {... */ 83 | tag_3: 84 | tag_4 85 | tag_5 86 | jump // in 87 | tag_4: 88 | mload(0x40) 89 | tag_6 90 | swap2 91 | swap1 92 | tag_7 93 | jump // in 94 | tag_6: 95 | mload(0x40) 96 | dup1 97 | swap2 98 | sub 99 | swap1 100 | return 101 | tag_5: 102 | /* "contract.sol":53:57 uint */ 103 | 0x00 104 | /* "contract.sol":76:77 1 */ 105 | 0x01 106 | /* "contract.sol":69:77 return 1 */ 107 | swap1 108 | pop 109 | /* "contract.sol":17:84 function one() public pure returns (uint) {... */ 110 | swap1 111 | jump // out 112 | /* "#utility.yul":7:125 */ 113 | tag_10: 114 | /* "#utility.yul":94:118 */ 115 | tag_12 116 | /* "#utility.yul":112:117 */ 117 | dup2 118 | /* "#utility.yul":94:118 */ 119 | tag_13 120 | jump // in 121 | tag_12: 122 | /* "#utility.yul":89:92 */ 123 | dup3 124 | /* "#utility.yul":82:119 */ 125 | mstore 126 | /* "#utility.yul":72:125 */ 127 | pop 128 | pop 129 | jump // out 130 | /* "#utility.yul":131:353 */ 131 | tag_7: 132 | 0x00 133 | /* "#utility.yul":262:264 */ 134 | 0x20 135 | /* "#utility.yul":251:260 */ 136 | dup3 137 | /* "#utility.yul":247:265 */ 138 | add 139 | /* "#utility.yul":239:265 */ 140 | swap1 141 | pop 142 | /* "#utility.yul":275:346 */ 143 | tag_15 144 | /* "#utility.yul":343:344 */ 145 | 0x00 146 | /* "#utility.yul":332:341 */ 147 | dup4 148 | /* "#utility.yul":328:345 */ 149 | add 150 | /* "#utility.yul":319:325 */ 151 | dup5 152 | /* "#utility.yul":275:346 */ 153 | tag_10 154 | jump // in 155 | tag_15: 156 | /* "#utility.yul":229:353 */ 157 | swap3 158 | swap2 159 | pop 160 | pop 161 | jump // out 162 | /* "#utility.yul":359:436 */ 163 | tag_13: 164 | 0x00 165 | /* "#utility.yul":425:430 */ 166 | dup2 167 | /* "#utility.yul":414:430 */ 168 | swap1 169 | pop 170 | /* "#utility.yul":404:436 */ 171 | swap2 172 | swap1 173 | pop 174 | jump // out 175 | 176 | auxdata: 0xa2646970667358221220a5874f19737ddd4c5d77ace1619e5160c67b3d4bedac75fce908fed32d98899864736f6c637827302e382e342d646576656c6f702e323032312e332e33302b636f6d6d69742e65613065363933380058 177 | } 178 | 179 | .. Alternatively, the above output can also be obtained from `Remix `_, under the option "Compilation Details" after compiling a contract. 180 | 181 | また、上記の出力は、コントラクトをコンパイルした後、 `Remix `_ のオプション「Compilation Details」からも得ることができます。 182 | 183 | .. Notice that the ``asm`` output starts with the creation / constructor code. 184 | .. The deploy code is provided as part of the sub object (in the above example, it is part of the sub-object ``sub_0``). 185 | .. The ``auxdata`` field corresponds to the contract :ref:`metadata `. 186 | .. The comments in the assembly output point to the source location. 187 | .. Note that ``#utility.yul`` is an internally generated file of utility functions that can be obtained using the flags ``--combined-json generated-sources,generated-sources-runtime``. 188 | 189 | ``asm`` の出力は、作成/コンストラクタのコードで始まることに注意してください。 190 | 配置コードは、サブオブジェクトの一部として提供されます（上記の例では、サブオブジェクト ``sub_0`` の一部です）。 191 | ``auxdata`` フィールドはコントラクトの :ref:`メタデータ ` に対応しています。 192 | アセンブリ出力のコメントは、ソースの位置を示しています。 193 | ``#utility.yul`` は、フラグ ``--combined-json generated-sources,generated-sources-runtime`` を使用して取得できるユーティリティー関数の内部生成ファイルであることに注意してください。 194 | 195 | .. Similarly, the optimized assembly can be obtained with the command: ``solc --optimize --asm contract.sol``. Often times, it is interesting to see if two different sources in Solidity result in 196 | .. the same optimized code. For example, to see if the expressions ``(a * b) / c``, ``a * b / c`` 197 | .. generates the same bytecode. This can be easily done by taking a ``diff`` of the corresponding 198 | .. assembly output, after potentially stripping comments that reference the source locations. 199 | 200 | 同様に、最適化されたアセンブリは、次のコマンドで得ることができます: ``solc --optimize --asm contract.sol`` 。 201 | しばしば、Solidityの2つの異なるソースが同じ最適化されたコードになるかどうかを確認することは興味深いことです。 202 | 例えば、 ``(a * b) / c`` , ``a * b / c`` という式が同じバイトコードを生成するかどうかを確認できます。 203 | これは、ソースの位置を参照するコメントを削除した後、対応するアセンブリ出力の ``diff`` を取ることで簡単に行うことができます。 204 | 205 | .. .. note:: 206 | 207 | .. The ``--asm`` output is not designed to be machine readable. Therefore, there may be breaking 208 | .. changes on the output between minor versions of solc. 209 | 210 | .. note:: 211 | 212 | ``--asm`` 出力は機械で読めるようには設計されていません。 213 | そのため、solcのマイナーバージョン間では、出力に変更がある可能性があります。 214 | -------------------------------------------------------------------------------- /docs/types/operators.rst: -------------------------------------------------------------------------------- 1 | .. index:: ! operator 2 | 3 | 4 | 演算子 5 | ====== 6 | 7 | .. Arithmetic and bit operators can be applied even if the two operands do not have the same type. 8 | .. For example, you can compute ``y = x + z``, where ``x`` is a ``uint8`` and ``z`` has the type ``uint32``. 9 | .. In these cases, the following mechanism will be used to determine the type in which the operation is computed (this is important in case of overflow) and the type of the operator's result: 10 | 11 | 算術演算子やビット演算子は、2つのオペランドが同じ型でなくても適用できます。 12 | 例えば、 ``y = x + z`` で ``x`` は ``uint8`` で、 ``z`` は ``uint32`` という型を持っていても計算できます。 13 | このような場合、次のようなメカニズムで、演算が計算される型（これはオーバーフローの場合に重要です）と演算子の結果の型を決定します: 14 | 15 | .. 1. If the type of the right operand can be implicitly converted to the type of the left operand, use the type of the left operand, 16 | .. 2. if the type of the left operand can be implicitly converted to the type of the right operand, use the type of the right operand, 17 | .. 3. otherwise, the operation is not allowed. 18 | 19 | 1. 右オペランドの型が左オペランドの型に暗黙のうちに変換できる場合、左オペランドの型を使用します。 20 | 2. 左オペランドの型が右オペランドの型に暗黙のうちに変換できる場合、右オペランドの型を使用します。 21 | 3. それ以外の場合は、演算ができません。 22 | 23 | .. In case one of the operands is a :ref:`literal number ` it is first converted to its "mobile type", which is the smallest type that can hold the value (unsigned types of the same bit-width are considered "smaller" than the signed types). 24 | .. If both are literal numbers, the operation is computed with effectively unlimited precision in that the expression is evaluated to whatever precision is necessary so that none is lost when the result is used with a non-literal type. 25 | 26 | オペランドの一方が :ref:`リテラルの数値 ` の場合、まずその値を保持できる最小の型である「モバイル型」に変換されます（同じビット幅の符号なし型は符号付き型より「小さい」とみなされます）。 27 | 両方がリテラルの数値の場合、演算は事実上無制限の精度で計算されます。 28 | つまり、式は必要な限りの精度で評価され、結果がリテラルでない型で使われたときに失われることはありません。 29 | 30 | .. The operator's result type is the same as the type the operation is performed in, except for comparison operators where the result is always ``bool``. 31 | 32 | 演算子の結果の型は、結果が常に ``bool`` になる比較演算子を除いて、演算が行われた型と同じです。 33 | 34 | .. The operators ``**`` (exponentiation), ``<<`` and ``>>`` use the type of the left operand for the operation and the result. 35 | 36 | 演算子 ``**`` （指数）、 ``<<`` 、 ``>>`` は、演算と結果において左オペランドの型を使用します。 37 | 38 | 三項演算子 39 | ---------- 40 | 41 | .. The ternary operator is used in expressions of the form `` ? : ``. 42 | .. It evaluates one of the latter two given expressions depending upon the result of the evaluation of the main ````. 43 | .. If ```` evaluates to ``true``, then ```` will be evaluated, otherwise ```` is evaluated. 44 | 45 | 三項演算子は、 `` ? : `` という形式の式で使われます。 46 | これは、メインの ```` の評価結果に応じて、後者の2つの式のうち1つを評価するものです。 47 | もし ```` が ``true`` と評価されれば ```` が評価され、そうでなければ ```` が評価されます。 48 | 49 | .. The result of the ternary operator does not have a rational number type, even if all of its operands are rational number literals. 50 | .. The result type is determined from the types of the two operands in the same way as above, converting to their mobile type first if required. 51 | 52 | 三項演算子の結果は、たとえすべてのオペランドが有理数リテラルであっても、有理数型を持ちません。 53 | 結果の型は、上記と同じように2つのオペランドの型から決定され、必要であれば最初にその移動型に変換されます。 54 | 55 | .. As a consequence, ``255 + (true ? 1 : 0)`` will revert due to arithmetic overflow. 56 | .. The reason is that ``(true ? 1 : 0)`` is of ``uint8`` type, which forces the addition to be performed in ``uint8`` as well, and 256 exceeds the range allowed for this type. 57 | 58 | その結果、 ``255 + (true ? 1 : 0)`` は算術オーバーフローによりリバートされてしまいます。 59 | これは ``(true ? 1 : 0)`` が ``uint8`` 型であるため、加算も ``uint8`` で行う必要があり、256はこの型で許される範囲を超えているためです。 60 | 61 | .. Another consequence is that an expression like ``1.5 + 1.5`` is valid but ``1.5 + (true ? 1.5 : 2.5)`` is not. 62 | .. This is because the former is a rational expression evaluated in unlimited precision and only its final value matters. 63 | .. The latter involves a conversion of a fractional rational number to an integer, which is currently disallowed. 64 | 65 | もう一つの結果として、 ``1.5 + 1.5`` のような式は有効だが、 ``1.5 + (true ? 1.5 : 2.5)`` は無効です。 66 | これは、前者が無制限の精度で評価される有理式であり、その最終値のみが重要だからです。 67 | 後者は小数有理数から整数への変換を伴うので、現在では認められていません。 68 | 69 | .. index:: assignment, lvalue, ! compound operators 70 | 71 | 複合演算子、インクリメント/デクリメント演算子 72 | --------------------------------------------- 73 | 74 | .. If ``a`` is an LValue (i.e. a variable or something that can be assigned to), the 75 | .. following operators are available as shorthands: 76 | 77 | ``a`` がLValue（すなわち変数や代入可能なもの）の場合、以下の演算子がショートハンドとして利用できます。 78 | 79 | .. ``a += e`` is equivalent to ``a = a + e``. The operators ``-=``, ``*=``, ``/=``, ``%=``, 80 | .. ``|=``, ``&=``, ``^=``, ``<<=`` and ``>>=`` are defined accordingly. ``a++`` and ``a--`` are equivalent 81 | .. to ``a += 1`` / ``a -= 1`` but the expression itself still has the previous value 82 | .. of ``a``. In contrast, ``--a`` and ``++a`` have the same effect on ``a`` but 83 | .. return the value after the change. 84 | 85 | ``a += e`` は ``a = a + e`` と同等です。 86 | 演算子 ``-=`` 、 ``*=`` 、 ``/=`` 、 ``%=`` 、 ``|=`` 、 ``&=`` 、 ``^=`` 、 ``<<=`` 、 ``>>=`` はそれぞれ定義されています。 87 | ``a++`` と ``a--`` は ``a += 1`` / ``a -= 1`` に相当しますが、表現自体は ``a`` の前の値のままです。 88 | 一方、 ``--a`` と ``++a`` は、 ``a`` に同じ効果を与えますが、変更後の値を返します。 89 | 90 | .. index:: !delete 91 | 92 | .. _delete: 93 | 94 | delete 95 | ------ 96 | 97 | .. ``delete a`` assigns the initial value for the type to ``a``. I.e. for integers it is 98 | .. equivalent to ``a = 0``, but it can also be used on arrays, where it assigns a dynamic 99 | .. array of length zero or a static array of the same length with all elements set to their 100 | .. initial value. ``delete a[x]`` deletes the item at index ``x`` of the array and leaves 101 | .. all other elements and the length of the array untouched. This especially means that it leaves 102 | .. a gap in the array. If you plan to remove items, a :ref:`mapping ` is probably a better choice. 103 | 104 | ``delete a`` は、 ``a`` に型の初期値を割り当てます。 105 | つまり、整数の場合は ``a = 0`` と同じですが、配列にも使用でき、長さ0の動的配列や、すべての要素を初期値に設定した同じ長さの静的配列を割り当てます。 106 | ``delete a[x]`` は、配列のインデックス ``x`` の項目を削除し、他のすべての要素と配列の長さはそのままにします。 107 | これは特に、配列にギャップを残すことを意味します。 108 | アイテムを削除する予定なら、 :ref:`マッピング` の方が良いでしょう。 109 | 110 | .. For structs, it assigns a struct with all members reset. In other words, 111 | .. the value of ``a`` after ``delete a`` is the same as if ``a`` would be declared 112 | .. without assignment, with the following caveat: 113 | 114 | 構造体の場合は、すべてのメンバーがリセットされた構造体が割り当てられます。 115 | つまり、 ``delete a`` 後の ``a`` の値は、以下の注意点を除いて、 ``a`` が代入なしで宣言された場合と同じになります。 116 | 117 | .. ``delete`` has no effect on mappings (as the keys of mappings may be arbitrary and 118 | .. are generally unknown). So if you delete a struct, it will reset all members that 119 | .. are not mappings and also recurse into the members unless they are mappings. 120 | .. However, individual keys and what they map to can be deleted: If ``a`` is a 121 | .. mapping, then ``delete a[x]`` will delete the value stored at ``x``. 122 | 123 | ``delete`` はマッピングには影響を与えません（マッピングのキーは任意である可能性があり、一般的には不明であるため）。 124 | そのため、構造体を削除すると、マッピングではないすべてのメンバーがリセットされ、またマッピングでない限り、そのメンバーに再帰します。 125 | しかし、個々のキーとそれが何にマッピングされているかは削除できます。 126 | ``a`` がマッピングであれば、 ``delete a[x]`` は ``x`` に格納されている値を削除します。 127 | 128 | .. It is important to note that ``delete a`` really behaves like an 129 | .. assignment to ``a``, i.e. it stores a new object in ``a``. 130 | .. This distinction is visible when ``a`` is reference variable: It 131 | .. will only reset ``a`` itself, not the 132 | .. value it referred to previously. 133 | 134 | ``delete a`` は実際には ``a`` への代入のように振る舞います。 135 | つまり、 ``a`` に新しいオブジェクトを格納するということに注意することが重要です。 136 | この違いは、 ``a`` が参照変数の場合に見られます。 137 | ``delete a`` は ``a`` 自体をリセットするだけで、以前参照していた値はリセットしません。 138 | 139 | .. code-block:: solidity 140 | 141 | // SPDX-License-Identifier: GPL-3.0 142 | pragma solidity >=0.4.0 <0.9.0; 143 | 144 | contract DeleteExample { 145 | uint data; 146 | uint[] dataArray; 147 | 148 | function f() public { 149 | uint x = data; 150 | delete x; // xを0にセットし、dataには影響を与えない 151 | delete data; // dataを0にセットし、xには影響を与えない 152 | uint[] storage y = dataArray; 153 | delete dataArray; // これは dataArray.length を 0 にするものですが、 154 | // uint[] は複合オブジェクトであるため、ストレージオブジェクトのエイリアスである y にも影響が及びます。 155 | // ストレージオブジェクトを参照するローカル変数への代入は、既存のストレージオブジェクトからしか行えないため、"delete y"は有効ではありません。 156 | assert(y.length == 0); 157 | } 158 | } 159 | 160 | .. index:: ! operator; precedence 161 | .. _order: 162 | 163 | 演算子の優先順位 164 | ---------------- 165 | 166 | .. include:: types/operator-precedence-table.rst 167 | -------------------------------------------------------------------------------- /docs/cheatsheet.rst: -------------------------------------------------------------------------------- 1 | ************ 2 | チートシート 3 | ************ 4 | 5 | .. index:: operator;precedence 6 | 7 | 演算子の優先順位 8 | ================ 9 | 10 | .. include:: types/operator-precedence-table.rst 11 | 12 | .. index:: abi;decode, abi;encode, abi;encodePacked, abi;encodeWithSelector, abi;encodeCall, abi;encodeWithSignature 13 | 14 | ABIのエンコード関数とデコード関数 15 | ================================= 16 | 17 | - ``abi.decode(bytes memory encodedData, (...)) returns (...)``: 18 | 与えたデータを :ref:`ABI ` デコードします。 19 | 型は第2引数として括弧内に与えられます。 20 | 例 ``(uint a, uint[2] memory b, bytes memory c) = abi.decode(data, (uint, uint[2], bytes))`` 21 | 22 | - ``abi.encode(...) returns (bytes memory)``: 23 | 与えた引数を :ref:`ABI ` エンコードします。 24 | 25 | - ``abi.encodePacked(...) returns (bytes memory)``: 26 | 与えた引数の :ref:`packed encoding ` を実行します。 27 | このエンコーディングは曖昧になる可能性があることに注意してください！ 28 | 29 | - ``abi.encodeWithSelector(bytes4 selector, ...) returns (bytes memory)``: 30 | 与えた引数を2番目から順に :ref:`ABI ` エンコードし、与えた4バイトのセレクタを前に付加します。 31 | 32 | - ``abi.encodeCall(function functionPointer, (...)) returns (bytes memory)``: 33 | タプルに含まれる引数を用いて ``functionPointer`` の呼び出しをABIエンコードします。 34 | 完全な型チェックを行い、型が関数のシグネチャと一致することを保証します。 35 | 結果は ``abi.encodeWithSelector(functionPointer.selector, ...)`` に等くなります。 36 | 37 | - ``abi.encodeWithSignature(string memory signature, ...) returns (bytes memory)``: 38 | ``abi.encodeWithSelector(bytes4(keccak256(bytes(signature))), ...)`` と同等です。 39 | 40 | .. index:: bytes;concat, string;concat 41 | 42 | ``bytes`` と ``string`` のメンバー 43 | ================================== 44 | 45 | - ``bytes.concat(...) returns (bytes memory)``: 46 | :ref:`可変個の引数を1つのバイト配列に連結します ` 。 47 | 48 | - ``string.concat(...) returns (string memory)``: :ref:`可変個の引数を1つの文字列に連結します ` 。 49 | 50 | .. index:: address;balance, address;codehash, address;send, address;code, address;transfer 51 | 52 | ``address`` のメンバー 53 | ====================== 54 | 55 | .. TODO: 56 | 57 | - ``
.balance`` (``uint256``): :ref:`address` の残高（Wei） 58 | - ``
.code`` (``bytes memory``): :ref:`address` のコード（空にもなり得る） 59 | - ``
.codehash`` (``bytes32``): :ref:`address` のコードハッシュ 60 | - ``
.call(bytes memory) returns (bool, bytes memory)``: issue low-level ``CALL`` with the given payload, returns success condition and return data 61 | - ``
.delegatecall(bytes memory) returns (bool, bytes memory)``: issue low-level ``DELEGATECALL`` with the given payload, returns success condition and return data 62 | - ``
.staticcall(bytes memory) returns (bool, bytes memory)``: issue low-level ``STATICCALL`` with the given payload, returns success condition and return data 63 | - ``
.send(uint256 amount) returns (bool)``: 指定した量のWeiを :ref:`address` に送り、失敗したら ``false`` を返します。 64 | - ``
.transfer(uint256 amount)``: 指定した量のWeiを :ref:`address` に送り、失敗したらリバートします。 65 | 66 | .. index:: blockhash, blobhash, block, block;basefee, block;blobbasefee, block;chainid, block;coinbase, block;difficulty, block;gaslimit, block;number, block;prevrandao, block;timestamp 67 | .. index:: gasleft, msg;data, msg;sender, msg;sig, msg;value, tx;gasprice, tx;origin 68 | 69 | ブロックとトランザクションのプロパティ 70 | ====================================== 71 | 72 | - ``blockhash(uint blockNumber) returns (bytes32)``: 指定したブロックのハッシュ。最新の256ブロックに対してのみ動作します。 73 | 74 | - ``blobhash(uint index) returns (bytes32)``: versioned hash of the ``index``-th blob associated with the current transaction. 75 | A versioned hash consists of a single byte representing the version (currently ``0x01``), followed by the last 31 bytes 76 | of the SHA256 hash of the KZG commitment (`EIP-4844 `_). 77 | Returns zero if no blob with the given index exists. 78 | 79 | - ``block.basefee`` (``uint``): カレントブロックのベースフィー（base fee）（ `EIP-3198 `_ と `EIP-1559 `_ ）。 80 | 81 | - ``block.blobbasefee`` (``uint``): カレントブロックのブロブベースフィー（blob base fee）（ `EIP-7516 `_ と `EIP-4844 `_ ）。 82 | 83 | - ``block.chainid`` (``uint``): カレントブロックのチェーンID。 84 | 85 | - ``block.coinbase`` (``address payable``): カレントブロックのマイナーのアドレス。 86 | 87 | - ``block.difficulty`` (``uint``): 88 | カレントブロックの難易度（ ``EVM < Paris`` ）。 89 | EVMの他のバージョンでは、 ``block.prevrandao`` の非推奨のエイリアスとして動作し、次のブレーキングリリースで削除される予定です。 90 | 91 | - ``block.gaslimit`` (``uint``): カレントブロックのガスリミット。 92 | 93 | - ``block.number`` (``uint``): カレントブロックの番号。 94 | 95 | - ``block.prevrandao`` (``uint``): 96 | ビーコンチェーンが提供する乱数（ ``EVM < Paris`` ）。 97 | `EIP-4399 `_ を参照してください。 98 | 99 | - ``block.timestamp`` ( ``uint`` ): Unixエポックからのカレントブロックのタイムスタンプ（秒）。 100 | 101 | - ``gasleft() returns (uint256)``: 残りのガス。 102 | 103 | - ``msg.data`` (``bytes``): 完全なコールデータ。 104 | 105 | - ``msg.sender`` (``address``): メッセージの送信者（現在のコール）。 106 | 107 | - ``msg.sig`` (``bytes4``): コールデータの最初の4バイト（すなわち関数識別子）。 108 | 109 | - ``msg.value`` (``uint``): メッセージと一緒に送られたweiの数。 110 | 111 | - ``tx.gasprice`` (``uint``): トランザクションのガスプライス。 112 | 113 | - ``tx.origin`` (``address``): トランザクションの送信者（フルコールチェーン）。 114 | 115 | .. index:: assert, require, revert 116 | 117 | バリデーションとアサーション 118 | ============================ 119 | 120 | - ``assert(bool condition)``: 条件が ``false`` の場合、実行を中止し、ステートの変化をリバートします（内部エラーに使用）。 121 | 122 | - ``require(bool condition)``: 条件が ``false`` の場合、実行を中止し、ステートの変化をリバートします（不正な入力や外部コンポーネントのエラーに使用）。 123 | 124 | - ``require(bool condition, string memory message)``: 条件が ``false`` の場合、実行を中止し、ステートの変化をリバートします（不正な入力や外部コンポーネントのエラーに使用）。また、エラーメッセージを表示します。 125 | 126 | - ``revert()``: 実行を中止し、状態の変化をリバートします。 127 | 128 | - ``revert(string memory message)``: 実行を中止し、説明文字列を提供してステートの変化をリバートします。 129 | 130 | .. index:: cryptography, keccak256, sha256, ripemd160, ecrecover, addmod, mulmod 131 | 132 | 数学的関数と暗号学的関数 133 | ======================== 134 | 135 | - ``keccak256(bytes memory) returns (bytes32)``: 入力のKeccak-256ハッシュを計算します。 136 | 137 | - ``sha256(bytes memory) returns (bytes32)``: 入力のSHA-256ハッシュを計算します。 138 | 139 | - ``ripemd160(bytes memory) returns (bytes20)``: 入力のRIPEMD-160ハッシュを計算します。 140 | 141 | - ``ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address)``: 楕円曲線署名から公開鍵に関連したアドレスをリカバリーします。エラー時は0を返します。 142 | 143 | - ``addmod(uint x, uint y, uint k) returns (uint)``: 任意の精度で加算が実行され、 ``2**256`` で切り捨てられない ``(x + y) % k`` を計算します。バージョン0.5.0から ``k != 0`` であることをアサートします。 144 | 145 | - ``mulmod(uint x, uint y, uint k) returns (uint)``: 任意の精度で乗算が実行され、 ``2**256`` で切り捨てられない ``(x * y) % k`` を計算します。バージョン0.5.0から ``k != 0`` であることをアサートします。 146 | 147 | .. index:: this, super, selfdestruct 148 | 149 | コントラクト関連 150 | ================ 151 | 152 | - ``this`` （現在のコントラクトの型）: 現在のコントラクトで、 ``address`` または ``address payable`` に明示的に変換できるもの。 153 | - ``super``: 継承階層の1つ上の階層のコントラクト。 154 | - ``selfdestruct(address payable recipient)``: すべての資金を指定されたアドレスに送金し、（Cancun 以前の EVM において、あるいは、コントラクトの作成トランザクション内で呼び出された場合に限り）コントラクトを破壊。 155 | 156 | .. index:: type;name, type;creationCode, type;runtimeCode, type;interfaceId, type;min, type;max 157 | 158 | 型情報 159 | ====== 160 | 161 | - ``type(C).name`` (``string``): コントラクトの名前。 162 | 163 | - ``type(C).creationCode`` ( ``bytes memory`` ): 164 | 与えられたコントラクトの作成バイトコード、 :ref:`型情報` を参照。 165 | 166 | - ``type(C).runtimeCode`` ( ``bytes memory`` ): 167 | 与えられたコントラクトのランタイムのバイトコード、 :ref:`型情報` を参照。 168 | 169 | - ``type(I).interfaceId`` (``bytes4``): 170 | 指定されたインターフェースのEIP-165インターフェース識別子を含む値、 :ref:`型情報` を参照。 171 | 172 | - ``type(T).min`` (``T``): 173 | 整数型 ``T`` で表現可能な最小値、 :ref:`型情報` を参照。 174 | 175 | - ``type(T).max`` (``T``): 176 | 整数型 ``T`` で表現可能な最大値、 :ref:`型情報` を参照。 177 | 178 | .. index:: visibility, public, private, external, internal 179 | 180 | 関数のビジビリティ指定子 181 | ======================== 182 | 183 | .. code-block:: solidity 184 | :force: 185 | 186 | function myFunction() returns (bool) { 187 | return true; 188 | } 189 | 190 | - ``public``: 外部にも内部にも見えます（ストレージ/状態変数の :ref:`ゲッター関数` を作成する）。 191 | - ``private``: 現在のコントラクトでのみ見えます。 192 | - ``external``: 外部にしか見えません（関数のみ）。つまり、メッセージコールしかできません（ ``this.func`` 経由）。 193 | - ``internal``: 内部でのみ見えます。 194 | 195 | .. index:: modifiers, pure, view, payable, constant, anonymous, indexed 196 | 197 | モディファイア 198 | ============== 199 | 200 | - 関数の ``pure``: 状態の変更やアクセスを禁止します。 201 | - 関数の ``view``: 状態の変更を不可とします。 202 | - 関数の ``payable``: コールと同時にEtherを受信できるようにします。 203 | - 状態変数の ``constant``: 初期化を除き、代入を禁止し、ストレージスロットを占有しません。 204 | - 状態変数の ``immutable``: コンストラクション時に代入を可能にし、デプロイ後は定数となります。コードに格納されます。 205 | - イベントの ``anonymous``: イベントのシグネチャをトピックとして保存しません。 206 | - イベントパラメータの ``indexed``: パラメータをトピックとして保存します。 207 | - 関数やモディファイアの ``virtual``: 関数やモディファイアの動作を派生コントラクトで変更できるようにします。 208 | - ``override``: この関数、モディファイア、パブリックの状態変数が、ベースコントラクト内の関数やモディファイアの動作を変更することを示します。 209 | -------------------------------------------------------------------------------- /docs/layout-of-source-files.rst: -------------------------------------------------------------------------------- 1 | ********************************** 2 | Solidityソースファイルのレイアウト 3 | ********************************** 4 | 5 | ソースファイルには、任意の数の :ref:`コントラクト定義` 、import_ 、 :ref:`pragma` 、:ref:`using for` ディレクティブと :ref:`struct` 、 :ref:`enum` 、 :ref:`function` 、 :ref:`error` 、 :ref:`constant variable` の定義を含めることができます。 6 | 7 | .. index:: ! license, spdx 8 | 9 | SPDXライセンス識別子 10 | ==================== 11 | 12 | スマートコントラクトの信頼性は、そのソースコードが利用可能であれば、より確立されます。 13 | ソースコードを公開することは、著作権に関する法的な問題に常に触れることになるため、Solidityコンパイラでは、機械が解釈可能な `SPDXライセンス識別子（SPDX license identifier） `_ の使用を推奨しています。 14 | すべてのソースファイルは、そのライセンスを示すコメントで始まるべきです。 15 | 16 | ``// SPDX-License-Identifier: MIT`` 17 | 18 | コンパイラはライセンスが `SPDXで許可されたリスト `_ の一部であることを検証しませんが、供給された文字列は :ref:`bytecodeメタデータ ` に含まれます。 19 | 20 | .. Note that ``UNLICENSED`` (no usage allowed, not present in SPDX license list) is different from ``UNLICENSE`` (grants all rights to everyone). 21 | .. Solidity follows `the npm recommendation `_. 22 | 23 | ライセンスを指定したくない場合や、ソースコードがオープンソースでない場合は、特別な値 ``UNLICENSED`` を使用してください。 24 | ``UNLICENSED`` （使用不可、SPDXライセンスリストに存在しない）は、 ``UNLICENSE`` （すべての権利をすべての人に与える）とは異なることに注意してください。 25 | Solidity は `npm recommendation `_ に従っています。 26 | 27 | もちろん、このコメントを提供することで、各ソースファイルに特定のライセンスヘッダーを記載しなければならないとか、オリジナルの著作権者に言及しなければならないといった、ライセンスに関する他の義務から解放されるわけではありません。 28 | 29 | コメントは、ファイルレベルではファイルのどこにあってもコンパイラに認識されますが、ファイルの先頭に置くことをお勧めします。 30 | 31 | SPDXライセンス識別子の使用方法の詳細は、 `SPDXのWebサイト `_ に記載されています。 32 | 33 | .. index:: ! pragma 34 | 35 | .. _pragma: 36 | 37 | pragma 38 | ====== 39 | 40 | ``pragma`` キーワードは、特定のコンパイラの機能やチェックを有効にするために使用されます。 41 | pragmaディレクティブは、常にソースファイルに局所的に適用されるため、プロジェクト全体で有効にしたい場合は、すべてのファイルにpragmaを追加する必要があります。 42 | 他のファイルを :ref:`インポート` した場合、そのファイルのpragmaは自動的にインポートしたファイルには適用されません。 43 | 44 | .. index:: ! pragma;version 45 | 46 | .. _version_pragma: 47 | 48 | バージョンpragma 49 | ---------------- 50 | 51 | ソースファイルには、互換性のない変更が加えられる可能性のある将来のバージョンのコンパイラでのコンパイルを拒否するために、バージョンpragmaで注釈を付けることができます（また、そうすべきです）。 52 | 私たちはこれらの変更を最小限にとどめ、セマンティクスの変更がシンタックスの変更を必要とするような方法で導入するようにしていますが、これは必ずしも可能ではありません。 53 | このため、少なくとも変更点を含むリリースについては、変更履歴に目を通すことをお勧めします。 54 | これらのリリースには、常に ``0.x.0`` または ``x.0.0`` という形式のバージョンがあります。 55 | 56 | バージョンpragmaは次のように使用されます: ``pragma solidity ^0.5.2;``。 57 | 58 | 上記の行を含むソースファイルは、バージョン0.5.2以前のコンパイラではコンパイルできず、バージョン0.6.0以降のコンパイラでも動作しません（この2番目の条件は ``^`` を使用することで追加されます）。 59 | また、バージョン0.6.0以降のコンパイラでは動作しません。 60 | コンパイラの正確なバージョンは固定されていないので、バグフィックスリリースも可能です。 61 | 62 | コンパイラバージョンには、より複雑なルールを指定できますが、これらは `npm `_ で使用されているのと同じ構文に従います。 63 | 64 | .. note:: 65 | 66 | バージョンpragmaを使用しても、コンパイラのバージョンを変更することはありません。 67 | また、コンパイラの機能を有効にしたり無効にしたりすることもありません。 68 | コンパイラに対して、そのバージョンがpragmaで要求されているものと一致するかどうかをチェックするように指示するだけです。 69 | 一致しない場合、コンパイラはエラーを発行します。 70 | 71 | .. index:: ! ABI coder, ! pragma; abicoder, pragma; ABIEncoderV2 72 | .. _abi_coder: 73 | 74 | ABIコーダーpragma 75 | ----------------- 76 | 77 | ``pragma abicoder v1`` または ``pragma abicoder v2`` を使用すると、ABIエンコーダおよびデコーダの2つの実装を選択できます。 78 | 79 | .. Apart from supporting more types, it involves more extensive validation and safety checks, which may result in higher gas costs, but also heightened security. 80 | .. It is considered non-experimental as of Solidity 0.6.0 and it is enabled by default starting with Solidity 0.8.0. 81 | .. The old ABI coder can still be selected using ``pragma abicoder v1;``. 82 | 83 | 新しいABIコーダー（v2）は、任意にネストされた配列や構造体をエンコードおよびデコードできます。 84 | より多くの型をサポートするだけでなく、より広範な検証と安全チェックを伴うため、ガスコストが高くなる可能性がありますが、セキュリティも強化されます。 85 | Solidity 0.6.0の時点では非実験的とみなされ、Solidity 0.8.0からデフォルトで有効になりました。 86 | 古いABIコーダーは ``pragma abicoder v1;`` を使用して選択できます。 87 | 88 | 新しいエンコーダーがサポートする型のセットは、古いエンコーダーがサポートする型の厳密なスーパーセットです。 89 | このエンコーダーを使用するコントラクトは、制限なしに使用しないコントラクトと相互作用できます。 90 | 逆は、 ``abicoder v2`` ではないコントラクトが、新しいエンコーダでのみサポートされている型のデコードを必要とするような呼び出しを行わない限り可能です。 91 | コンパイラはこれを検知してエラーを出します。 92 | コントラクトで ``abicoder v2`` を有効にするだけで、このエラーは解消されます。 93 | 94 | .. note:: 95 | 96 | このpragmaは、コードが最終的にどこに到達するかにかかわらず、このpragmaが有効になっているファイルで定義されたすべてのコードに適用されます。 97 | つまり、ソースファイルがABIコーダーv1でコンパイルするように選択されているコントラクトでも、他のコントラクトから継承することで新しいエンコーダを使用するコードを含むことができます。 98 | これは、新しい型が内部的にのみ使用され、外部の関数の署名に使用されない場合に許可されます。 99 | 100 | .. note:: 101 | 102 | Solidity 0.7.4までは、 ``pragma experimental ABIEncoderV2`` を使用してABIコーダーv2を選択できましたが、coder v1がデフォルトであるため、明示的に選択できませんでした。 103 | 104 | .. index:: ! pragma; experimental 105 | .. _experimental_pragma: 106 | 107 | 実験的pragma 108 | ------------ 109 | 110 | 2つ目のpragmaは、実験的pragmaです。 111 | これは、デフォルトではまだ有効になっていないコンパイラや言語の機能を有効にするために使用できます。 112 | 現在、以下の実験的pragmaがサポートされています。 113 | 114 | .. index:: ! pragma; ABIEncoderV2 115 | 116 | ABIEncoderV2 117 | ~~~~~~~~~~~~ 118 | 119 | ABIコーダーv2は実験的なものではなくなったので、Solidity 0.7.4から ``pragma abicoder v2`` （上記参照）で選択できるようになりました。 120 | 121 | .. index:: ! pragma; SMTChecker 122 | .. _smt_checker: 123 | 124 | SMTChecker 125 | ~~~~~~~~~~ 126 | 127 | このコンポーネントは、Solidityコンパイラのビルド時に有効にする必要があるため、すべてのSolidityバイナリで利用できるわけではありません。 128 | :ref:`build instructions` では、このオプションを有効にする方法を説明しています。 129 | ほとんどのバージョンのUbuntu PPAリリースでは有効になっていますが、Dockerイメージ、Windowsバイナリ、静的ビルドのLinuxバイナリでは有効になっていません。 130 | SMTソルバーがローカルにインストールされていて、ブラウザではなくnode経由でsolc-jsを実行している場合、 `smtCallback `_ 経由でsolc-jsを有効にできます。 131 | 132 | ``pragma experimental SMTChecker;`` を使用する場合は、SMTソルバーへの問い合わせによって得られる追加の :ref:`safety warnings` を取得します。 133 | このコンポーネントは、Solidity言語のすべての機能をサポートしておらず、多くの警告を出力する可能性があります。 134 | サポートされていない機能が報告された場合、解析が完全にはうまくいかない可能性があります。 135 | 136 | .. index:: source file, ! import, module, source unit 137 | 138 | .. _import: 139 | 140 | 他のソースファイルのインポート 141 | ============================== 142 | 143 | シンタックスとセマンティクス 144 | ---------------------------- 145 | 146 | Solidityは、JavaScript（ES6以降）と同様に、コードをモジュール化するためのインポート文をサポートしています。 147 | しかし、Solidityは `default export `_ の概念をサポートしていません。 148 | 149 | グローバルレベルでは、次のような形式のインポート文を使用できます。 150 | 151 | .. code-block:: solidity 152 | 153 | import "filename"; 154 | 155 | ``filename`` の部分は、 *importパス* と呼ばれます。 156 | この文は、"filename"からのすべてのグローバルシンボル（およびそこでインポートされたシンボル）を、現在のグローバルスコープにインポートします（ES6とは異なりますが、Solidityでは後方互換性があります）。 157 | この形式は、予測できないほど名前空間を汚染するので、使用を推奨しません。 158 | "filename"の中に新しいトップレベルのアイテムを追加すると、"filename"からこのようにインポートされたすべてのファイルに自動的に表示されます。 159 | 特定のシンボルを明示的にインポートする方が良いでしょう。 160 | 161 | 次の例では、 ``"filename"`` のすべてのグローバルシンボルをメンバーとする新しいグローバルシンボル ``symbolName`` を作成しています。 162 | 163 | .. code-block:: solidity 164 | 165 | import * as symbolName from "filename"; 166 | 167 | と入力すると、すべてのグローバルシンボルが ``symbolName.symbol`` 形式で利用できるようになります。 168 | 169 | この構文のバリエーションとして、ES6には含まれていませんが、便利なものがあります。 170 | 171 | .. code-block:: solidity 172 | 173 | import "filename" as symbolName; 174 | 175 | となっており、これは ``import * as symbolName from "filename";`` と同じです。 176 | 177 | 名前の衝突があった場合、インポート中にシンボルの名前を変更できます。 178 | 例えば、以下のコードでは、新しいグローバルシンボル ``alias`` と ``symbol2`` を作成し、それぞれ ``"filename"`` の内部から ``symbol1`` と ``symbol2`` を参照しています。 179 | 180 | .. code-block:: solidity 181 | 182 | import {symbol1 as alias, symbol2} from "filename"; 183 | 184 | .. index:: virtual filesystem, source unit name, import; path, filesystem path, import callback, Remix IDE 185 | 186 | インポートパス 187 | -------------- 188 | 189 | すべてのプラットフォームで再現可能なビルドをサポートするために、Solidityコンパイラは、ソースファイルが保存されているファイルシステムの詳細を抽象化する必要があります。 190 | このため、インポートパスはホストファイルシステム上のファイルを直接参照しません。 191 | 代わりに、コンパイラは内部データベース（ *バーチャルファイルシステム（virtual filesystem）* あるいは略して *VFS* ）を維持し、各ソースユニットに不透明で構造化されていない識別子である一意の *ソースユニット名* を割り当てます。 192 | インポート文で指定されたインポートパスは、ソースユニット名に変換され、このデータベース内の対応するソースユニットを見つけるために使用されます。 193 | 194 | :ref:`Standard JSON ` APIを使用すると、すべてのソースファイルの名前と内容を、コンパイラの入力の一部として直接提供できます。 195 | この場合、ソースユニット名は本当に任意です。 196 | しかし、コンパイラが自動的にソースコードを見つけてVFSにロードしたい場合は、ソースユニット名を :ref:`import callback ` が見つけられるように構造化する必要があります。 197 | コマンドラインコンパイラを使用する場合、デフォルトのインポートコールバックはホストファイルシステムからのソースコードのロードのみをサポートしているため、ソースユニット名はパスでなければなりません。 198 | 環境によっては、より汎用性の高いカスタムコールバックを提供しています。 199 | 例えば、 `Remix IDE `_ は、 `HTTP、IPFS、SwarmのURLからファイルをインポートしたり、NPMレジストリのパッケージを直接参照したりできる `_ ものを提供しています。 200 | 201 | バーチャルファイルシステムとコンパイラが使用するパス解決ロジックの完全な説明は、 :ref:`Path Resolution ` を参照してください。 202 | 203 | .. index:: ! comment, natspec 204 | 205 | コメント 206 | ======== 207 | 208 | 一行コメント (``//``) と複数行コメント (``/*...*/``) が使用可能です。 209 | 210 | .. code-block:: solidity 211 | 212 | // これは一行コメントです。 213 | 214 | /* 215 | これは 216 | 複数行コメントです。 217 | */ 218 | 219 | .. note:: 220 | 221 | 一行コメントは、UTF-8エンコーディングの任意のunicode行終端記号（LF、VF、FF、CR、NEL、LS、PS）で終了します。 222 | ターミネーターはコメントの後もソースコードの一部であるため、ASCIIシンボル（NEL、LS、PS）でない場合はパーサーエラーになります。 223 | 224 | さらに、NatSpecコメントと呼ばれる別の種類のコメントがあり、その詳細は :ref:`style guide` に記載されています。 225 | このコメントは、トリプルスラッシュ（ ``///`` ）またはダブルアスタリスクブロック（ ``/** ... */`` ）で記述され、関数宣言や文の上で使用されます。 226 | -------------------------------------------------------------------------------- /docs/070-breaking-changes.rst: -------------------------------------------------------------------------------- 1 | ***************************** 2 | Solidity v0.7.0の破壊的変更点 3 | ***************************** 4 | 5 | .. This section highlights the main breaking changes introduced in Solidity version 0.7.0, along with the reasoning behind the changes and how to update affected code. 6 | .. For the full list check `the release changelog `_. 7 | 8 | このセクションでは、Solidityバージョン0.7.0で導入された主な変更点と、変更の理由、影響を受けるコードの更新方法について説明します。 9 | 完全なリストは `リリースチェンジログ `_ を参照してください。 10 | 11 | 12 | .. Silent Changes of the Semantics 13 | 14 | セマンティクスのサイレントな変更点 15 | ================================== 16 | 17 | .. * Exponentiation and shifts of literals by non-literals (e.g. ``1 << x`` or ``2 ** x``) 18 | .. will always use either the type ``uint256`` (for non-negative literals) or 19 | .. ``int256`` (for negative literals) to perform the operation. 20 | .. Previously, the operation was performed in the type of the shift amount / the 21 | .. exponent which can be misleading. 22 | 23 | * リテラルの非リテラル（ ``1 << x`` や ``2 ** x`` など）による指数化やシフトは、常に ``uint256`` 型（非負のリテラル用）または ``int256`` 型（負のリテラル用）を使用して演算を行います。 24 | これまでは、シフト量／指数の型で演算を行っていたため、誤解を招く恐れがありました。 25 | 26 | 27 | .. Changes to the Syntax 28 | 29 | シンタックスの変更点 30 | ==================== 31 | 32 | .. * In external function and contract creation calls, Ether and gas is now specified using a new syntax: 33 | .. ``x.f{gas: 10000, value: 2 ether}(arg1, arg2)``. 34 | .. The old syntax -- ``x.f.gas(10000).value(2 ether)(arg1, arg2)`` -- will cause an error. 35 | 36 | * 外部関数やコントラクト作成コールで、Etherやガスが新しい構文で指定されるようになりました。 37 | ``x.f{gas: 10000, value: 2 ether}(arg1, arg2)`` です。 38 | 従来の構文（ ``x.f.gas(10000).value(2 ether)(arg1, arg2)`` ）ではエラーになります。 39 | 40 | .. * The global variable ``now`` is deprecated, ``block.timestamp`` should be used instead. 41 | .. The single identifier ``now`` is too generic for a global variable and could give the impression 42 | .. that it changes during transaction processing, whereas ``block.timestamp`` correctly 43 | .. reflects the fact that it is just a property of the block. 44 | 45 | * グローバル変数 ``now`` は非推奨であり、代わりに ``block.timestamp`` を使用すべきです。 46 | ``now`` という単一の識別子は、グローバル変数としては一般的すぎて、トランザクション処理中に変化するような印象を与える可能性がありますが、 ``block.timestamp`` は単なるブロックのプロパティであるという事実を正しく反映しています。 47 | 48 | .. * NatSpec comments on variables are only allowed for public state variables and not 49 | .. for local or internal variables. 50 | 51 | * 変数に関するNatSpecコメントは、パブリックな状態の変数に対してのみ許可され、ローカルまたは内部の変数に対しては許可されません。 52 | 53 | .. * The token ``gwei`` is a keyword now (used to specify, e.g. ``2 gwei`` as a number) 54 | .. and cannot be used as an identifier. 55 | 56 | * トークン ``gwei`` は、現在のキーワード（例えば ``2 gwei`` を数字で指定するために使用）であり、識別子としては使用できません。 57 | 58 | .. * String literals now can only contain printable ASCII characters and this also includes a variety of 59 | .. escape sequences, such as hexadecimal (``\xff``) and unicode escapes (``\u20ac``). 60 | 61 | * 文字列リテラルには、印刷可能なASCII文字のみを含めることができるようになり、16進数（ ``\xff`` ）やユニコードエスケープ（ ``\u20ac`` ）などの様々なエスケープシーケンスも含まれています。 62 | 63 | .. * Unicode string literals are supported now to accommodate valid UTF-8 sequences. They are identified 64 | .. with the ``unicode`` prefix: ``unicode"Hello 😃"``. 65 | 66 | * Unicode文字列リテラルがサポートされ、有効なUTF-8シーケンスに対応できるようになりました。 67 | これらは ``unicode`` という接頭語で識別されます: ``unicode"Hello 😃"`` 。 68 | 69 | .. * State Mutability: The state mutability of functions can now be restricted during inheritance: 70 | .. Functions with default state mutability can be overridden by ``pure`` and ``view`` functions 71 | .. while ``view`` functions can be overridden by ``pure`` functions. 72 | .. At the same time, public state variables are considered ``view`` and even ``pure`` 73 | .. if they are constants. 74 | 75 | * ステートミュータビリティ: 継承の際に、関数のステートミュータビリティを制限できるようになりました。 76 | デフォルトのステートミュータビリティを持つ関数は、 ``pure`` および ``view`` 関数でオーバーライドでき、 ``view`` 関数は ``pure`` 関数でオーバーライドできます。 77 | 同時に、パブリックな状態変数は ``view`` とみなされ、定数であれば ``pure`` ともみなされます。 78 | 79 | 80 | インラインアセンブリ 81 | -------------------- 82 | 83 | .. * Disallow ``.`` in user-defined function and variable names in inline assembly. 84 | .. It is still valid if you use Solidity in Yul-only mode. 85 | 86 | * インラインアセンブリのユーザー定義関数および変数名に ``.`` を使用できないようにしました。 87 | SolidityをYul-onlyモードで使用している場合も有効です。 88 | 89 | .. * Slot and offset of storage pointer variable ``x`` are accessed via ``x.slot`` 90 | .. and ``x.offset`` instead of ``x_slot`` and ``x_offset``. 91 | 92 | * ストレージポインタ変数 ``x`` のスロットとオフセットは、 ``x_slot`` と ``x_offset`` ではなく ``x.slot`` と ``x.offset`` でアクセスされます。 93 | 94 | 未使用または安全でない機能の削除 95 | ================================ 96 | 97 | ストレージ外のマッピング 98 | ------------------------ 99 | 100 | .. NOTE: https://github.com/ethereum/solidity/issues/6444 101 | 102 | * 構造体や配列にマッピングが含まれている場合、その構造体と配列はストレージでのみ使用できるようになりました。 103 | これまでは、マッピングのメンバーはメモリ内では無視されていたため、混乱してエラーが発生しやすい状況になっていました。 104 | 105 | * ストレージ内の構造体や配列にマッピングが含まれていると代入が動作しなくなるようになりました。 106 | これまでは、マッピングはコピー操作中に自動的に無視されていましたが、これは誤解を招きやすく、エラーが発生しやすい状況になっていました。 107 | 108 | 関数とイベント 109 | -------------- 110 | 111 | .. * Visibility (``public`` / ``internal``) is not needed for constructors anymore: 112 | .. To prevent a contract from being created, it can be marked ``abstract``. 113 | .. This makes the visibility concept for constructors obsolete. 114 | 115 | * コンストラクタにはビジビリティ（ ``public`` / ``internal`` ）は必要なくなりました。 116 | コントラクトが作成されないようにするには、 ``abstract`` マークを付けることができます。 117 | これにより、コンストラクタのビジビリティの概念は廃止されました。 118 | 119 | .. * Type Checker: Disallow ``virtual`` for library functions: 120 | .. Since libraries cannot be inherited from, library functions should not be virtual. 121 | 122 | * 型チェッカー: ライブラリ関数の ``virtual`` を禁止します。 123 | ライブラリは継承できないので、ライブラリ関数は仮想関数であってはなりません。 124 | 125 | .. * Multiple events with the same name and parameter types in the same 126 | .. inheritance hierarchy are disallowed. 127 | 128 | * 同一の継承階層に同一名称、同一パラメータ型のイベントが複数存在することは認められません。 129 | 130 | .. * ``using A for B`` only affects the contract it is mentioned in. 131 | .. Previously, the effect was inherited. Now, you have to repeat the ``using`` 132 | .. statement in all derived contracts that make use of the feature. 133 | 134 | * ``using A for B`` は、記載されているコントラクトにのみ影響を与えます。 135 | 以前は、この効果は継承されていました。 136 | 現在では、この関数を利用するすべての派生コントラクトで ``using`` 文を繰り返さなければなりません。 137 | 138 | .. Expressions 139 | 140 | 式 141 | -- 142 | 143 | .. * Shifts by signed types are disallowed. 144 | .. Previously, shifts by negative amounts were allowed, but reverted at runtime. 145 | 146 | * 符号付きの型によるシフトは禁止されています。 147 | 以前は、負の金額によるシフトは許可されていましたが、実行時にリバートされました。 148 | 149 | .. * The ``finney`` and ``szabo`` denominations are removed. 150 | .. They are rarely used and do not make the actual amount readily visible. Instead, explicit 151 | .. values like ``1e20`` or the very common ``gwei`` can be used. 152 | 153 | * ``finney`` と ``szabo`` のデノミネーションは削除されています。 154 | これらはほとんど使用されず、実際の金額を容易に確認できません。 155 | 代わりに、 ``1e20`` や非常に一般的な ``gwei`` のような明確な値を使用できます。 156 | 157 | 宣言 158 | ---- 159 | 160 | .. * The keyword ``var`` cannot be used anymore. 161 | .. Previously, this keyword would parse but result in a type error and a suggestion about which type to use. 162 | .. Now, it results in a parser error. 163 | 164 | * キーワード ``var`` が使用できなくなりました。 165 | 以前は、このキーワードは解析されますが、型エラーが発生し、どの型を使用すべきかの提案がありました。 166 | 現在は、パーサーエラーとなります。 167 | 168 | インターフェースの変更点 169 | ======================== 170 | 171 | .. * JSON AST: Mark hex string literals with ``kind: "hexString"``. 172 | .. * JSON AST: Members with value ``null`` are removed from JSON output. 173 | .. * NatSpec: Constructors and functions have consistent userdoc output. 174 | 175 | * JSON AST: 16進文字列リテラルを ``kind: "hexString"`` でマークするようになりました。 176 | * JSON AST: 値が ``null`` のメンバーをJSON出力から削除しました。 177 | * NatSpec: コンストラクタと関数に一貫したユーザードキュメントを出力するようにしました。 178 | 179 | コードのアップデート方法 180 | ======================== 181 | 182 | .. This section gives detailed instructions on how to update prior code for every breaking change. 183 | 184 | このセクションでは、変更のたびに先行コードを更新する方法を詳しく説明しています。 185 | 186 | .. * Change ``x.f.value(...)()`` to ``x.f{value: ...}()``. Similarly ``(new C).value(...)()`` to ``new C{value: ...}()`` and ``x.f.gas(...).value(...)()`` to ``x.f{gas: ..., value: ...}()``. 187 | .. * Change types of right operand in shift operators to unsigned types. For example change ``x >> (256 - y)`` to ``x >> uint(256 - y)``. 188 | .. * Repeat the ``using A for B`` statements in all derived contracts if needed. 189 | .. * Remove the ``public`` keyword from every constructor. 190 | .. * Remove the ``internal`` keyword from every constructor and add ``abstract`` to the contract (if not already present). 191 | .. * Change ``_slot`` and ``_offset`` suffixes in inline assembly to ``.slot`` and ``.offset``, respectively. 192 | 193 | * ``x.f.value(...)()`` を ``x.f{value: ...}()`` に変更してください。同様に ``(new C).value(...)()`` を ``new C{value: ...}()`` に、 ``x.f.gas(...).value(...)()`` を ``x.f{gas: ..., value: ...}()`` にしてください。 194 | * ``now`` を ``block.timestamp`` に変更してください。 195 | * シフト演算子の右オペランドの型を符号なしに変更してください。例えば、 ``x >> (256 - y)`` を ``x >> uint(256 - y)`` に変更してください。 196 | * 必要に応じて、すべての派生コントラクトで ``using A for B`` 文を繰り返してください。 197 | * すべてのコンストラクタから ``public`` キーワードを削除してください。 198 | * すべてのコンストラクタから ``internal`` キーワードを削除し、コントラクトに ``abstract`` を追加してください（まだ存在しない場合）。 199 | * インラインアセンブリの ``_slot`` と ``_offset`` の接尾辞をそれぞれ ``.slot`` と ``.offset`` に変更してください。 200 | --------------------------------------------------------------------------------