diff --git a/docs/solutions/translation-review/crowdin-import-review-japanese-pr-17132.md b/docs/solutions/translation-review/crowdin-import-review-japanese-pr-17132.md new file mode 100644 index 00000000000..9a89ae38d1d --- /dev/null +++ b/docs/solutions/translation-review/crowdin-import-review-japanese-pr-17132.md @@ -0,0 +1,216 @@ +--- +title: "Japanese Translation Import Review — PR #17132" +date: 2026-02-24 +category: translation-review +severity: high +component: src/scripts/i18n/post_import_sanitize.ts +pipeline: review-translations-local +language: ja +pr_number: 17132 +file_count_in_pr: 306 +final_files_changed: 31 +final_commit: 0bc77ee8b7 +tags: + - i18n + - japanese + - crowdin-import + - sanitizer + - translation-review + - pipeline-first-run + - post-import-sanitize + - ai-review-agents + - manual-review + - brand-tags + - mdx-escaping +related_prs: + - "#17132" +related_branches: + - i18n/import/2026-01-21T17-37-56-ja + - fix-review-translations +symptoms: + - "Old sanitizer produced ~46 modified files, ~35 of which contained incorrect changes" + - "5 distinct bugs identified in the original post_import_sanitize.ts" + - "Silent corruption of translation files — no errors raised, bad changes applied quietly" + - "AI review agent patches included 2 bad changes (lowercased brand tag, corrupted href)" + - "Whitespace issues in href attributes in restaking/index.md" + - "Typo present in roadmap/merge content" +root_causes: + - "Buggy post_import_sanitize.ts applying incorrect transformations to imported translations" + - "Sanitizer lacked adequate guards against false-positive pattern matches" + - "AI review agents occasionally producing invalid fixes (brand tag lowercasing, href corruption)" + - "First-run pipeline — no prior calibration against Japanese translation corpus" +--- + +# Japanese Translation Import Review — PR #17132 + +## Problem + +During the Japanese (ja) translation review of PR #17132 (branch `i18n/import/2026-01-21T17-37-56-ja`, 306 files), the `review-translations-local` pipeline exposed two intertwined categories of issues: + +**Category A — Sanitizer corruption (the blocking problem):** The `post_import_sanitize.ts` script, invoked as Phase 1e via `sanitize-pr.ts --pr=17132`, modified 46 files. Manual review of the staged sanitizer output revealed that approximately 40 of those 46 files contained at least one incorrect change. Five distinct bugs in the sanitizer were silently corrupting translated content: + +1. **Href substitution across misaligned paragraphs** — `fixTranslatedHrefs` replaced valid hrefs with unrelated paths (e.g., `/staking/` became `/roadmap/`) +2. **Brand tag lowercase casing** — `fixBrandTags` copied English source values (`"solidity"`) instead of canonical casing (`"Solidity"`) +3. **Invalid ticker correction + code-fence blindness** — `KECCAK` incorrectly listed as misspelling; no code-fence awareness +4. **Orphaned tag removal inside code spans** — stripped `` `` `` from backticks +5. **Orphaned tag removal order inverted** — removed paired closers instead of trailing orphans + +**Category B — Legitimate translation quality issues:** The AI review agents found genuine problems in the Crowdin translations: + +- Japanese typos: `なりまりました` → `なりました`, `バリデター` → `バリデータ`, `あな` → `あなた`, `ハッカーよく` → `ハッカーがよく` +- Broken HTML in glossary JSON: `` → `をご覧ください。` +- Typo in href: `/saking/pools/` → `/staking/pools/` +- Transliteration error: `ブルーフ・オブ・ステーク` → `プルーフ・オブ・ステーク` +- Duplicated heading anchors: `{#scam-alert} {#scam-alert}` +- Missing blank lines after markdown headers +- Orphaned trailing `` tags and `href = "..."` whitespace in HTML attributes + +## Solution + +The solution required a two-phase approach: fix the sanitizer itself, then re-run the pipeline and layer on legitimate review fixes. + +### Phase 1: Sanitizer Bug Fixes (commit `d67a75cf9d`) + +All 5 bugs were fixed in `post_import_sanitize.ts` on the `fix-review-translations` branch (109 insertions, 153 deletions). Full details in the [companion bug analysis document](../integration-issues/post-import-sanitizer-bugs-found-japanese-review.md). + +Key fixes: +- `fixTranslatedHrefs` converted to **warn-only** (no content modification) +- `fixBrandTags` uses canonical casing from `PROTECTED_BRAND_NAMES` constant + targeted per-tag replacement preserving YAML formatting +- `KECCAK` removed from `TICKER_CORRECTIONS`; code-fence skipping added to `fixTickerTranspositions` +- `removeOrphanedClosingTags` gained code-block/code-span awareness and corrected removal order (keep paired closers, remove trailing orphans) + +### Phase 2: Reset, Re-run, and Selective Patch Application + +1. **Saved review-fix patches** for 3 files with both sanitizer and review changes (MM git state) +2. **Reverted all 46 sanitizer-modified files** back to HEAD +3. **Updated sanitizer** to the fixed version from `fix-review-translations` +4. **Re-ran sanitizer** — clean output with only legitimate fixes +5. **Selectively re-applied review patches**, rejecting 2 bad changes: + - Rejected: lowercased brand tag `"Solidity"` → `"solidity"` in `uniswap-v2-annotated-code` + - Rejected: corrupted href `/roadmap/` → `/energy-consumption/` in `roadmap/merge` + - Accepted: structural repair (missing blank line after header) in `uniswap-v2-annotated-code` + - Accepted: typo fix `なりまりました` → `なりました` in `roadmap/merge` +6. **Applied manual fix** for href attribute whitespace in `restaking/index.md`: + +```html + +text...prose... + + +text...prose... +``` + +### Final Commit (`0bc77ee8b7`) + +31 files changed, 44 insertions, 42 deletions: + +| Category | Files | Example | +|----------|-------|---------| +| Brand tag canonical casing | 10 | `"hardhat"` → `"Hardhat"` in frontmatter tags | +| MDX angle bracket escaping | 4 | `<1 GB RAM` → `<1 GB RAM` | +| Japanese typo fixes | 8 | `イーサリウム` → `イーサリアム` | +| Broken HTML repair | 2 | `` → `をご覧ください。` | +| Href typo fix | 2 | `/saking/pools/` → `/staking/pools/` | +| Transliteration fix | 2 | `ブルーフ` → `プルーフ` | +| Duplicate heading anchor removal | 4 | `{#scam-alert} {#scam-alert}` → `{#scam-alert}` | +| Structural repair | 1 | Missing blank line after header | +| Orphaned tag + href whitespace | 1 | Trailing `` removal + `href =` normalization | +| Character/particle fixes | 2 | `あな` → `あなた`, `ハッカーよく` → `ハッカーがよく` | + +--- + +## Lessons Learned + +### 1. Sanitizer Output Is Not Trustworthy Until Manually Verified + +The sanitizer modified 46 files during the initial run. Approximately 40 contained at least one incorrect change. Had these been committed directly (as the automated `sanitization.ts` workflow does via `batchCommitFiles`), the corruption would have shipped to production. **The sanitizer generates candidates, not final output.** + +### 2. AI Review Agents Introduce Their Own Error Class + +Two of three review-fix patches contained bad changes. This mirrors the Czech review (PR #17553) where 27 of 29 initial findings were false positives. AI agents are a second sanitizer layer, not a human replacement. **Selective patch application** — accepting some hunks and rejecting others — was required. + +### 3. Git Staging Discipline Is a Critical Safety Mechanism + +The pipeline's design staged sanitizer output separately from review agent fixes (staged vs unstaged). This made it possible to attribute each change to its origin phase. When everything was unstaged, the two-phase categorization was lost and recovery was more complex. **Staging boundaries are a traceability mechanism.** + +### 4. MM State Files Require Special Handling + +When a file has been modified by both the sanitizer (staged) and the review agent (unstaged), a simple `git checkout` destroys the review information. The correct recovery sequence: +1. Save the review-only diff: `git diff path/to/file > /tmp/review-fix.patch` +2. Reset the file: `git checkout HEAD -- path/to/file` +3. Re-run fixed sanitizer +4. Re-apply review patch: `git apply /tmp/review-fix.patch` + +### 5. Worktree Script Copies Drift From Upstream + +The initial sanitizer run used an old copy of `post_import_sanitize.ts`. After fixing bugs on `fix-review-translations`, the worktree copy had to be manually updated. Changes on other branches do not propagate to worktrees automatically. + +### 6. Auto-Fix Functions Require Unambiguous Correctness Criteria + +Three of five sanitizer bugs attempted auto-fixes based on heuristics that were not reliably correct. If the correct output depends on document structure that the translation platform can modify, the fix must be warn-only. + +--- + +## Pipeline Improvements + +### 1. Mandatory Diff-Review Gate Between Sanitizer and Commit + +Insert a review gate that generates a change summary, samples random diffs, and requires explicit confirmation before committing. Prevents silent corruption of ~40 files. + +### 2. Sanitizer Version Pinning in Worktrees + +When creating a worktree, record the sanitizer commit hash. Before running, compare against the latest version and prompt to update if they differ. + +### 3. Structured Warning Handoff + +Write sanitizer warnings to `sanitizer-warnings.json` instead of just stdout. Review agents can read this as input context, creating an explicit handoff rather than relying on operator relay. + +### 4. Code-Region Immunity Check + +Add a pre-commit verification that no transforms modified content inside fenced code blocks or inline code spans. Parse both original and modified files, extract code regions, and assert byte-identical content. + +### 5. Review Agent Patches Must Be Individually Addressable + +Each fix should be a discrete, independently-applicable unit — not a monolithic patch. Present fixes in a structured format (file, line, old, new, category, confidence) that the operator can accept/reject individually. + +--- + +## Checklist for Future Reviews + +### Pre-Sanitizer +- [ ] Verify sanitizer script matches latest version on `dev` or `fix-review-translations` +- [ ] Confirm English source files available at expected paths +- [ ] Note current `git status` — all files should be clean + +### Sanitizer Execution +- [ ] Run with PR-scoped entry point (`sanitize-pr.ts `) +- [ ] Review stdout summary — if >50% of files written, investigate +- [ ] Spot-check 5 modified files for: href changes, brand tag casing, code fence integrity, orphan tag correctness +- [ ] If any spot-check fails, **stop and investigate** + +### Staging +- [ ] Stage only sanitizer changes +- [ ] Verify with `git diff --cached --stat` +- [ ] Keep review agent output unstaged for clear separation + +### Review Agent Execution +- [ ] If new language, run on 5–10 calibration files first +- [ ] Check first 5 findings manually — if >1 is false positive, stop and calibrate +- [ ] Never bulk-apply review fixes without per-fix inspection + +### Recovery (If Something Goes Wrong) +- [ ] Save review diffs before resetting: `git diff > /tmp/.review.patch` +- [ ] Reset to clean: `git checkout HEAD -- ` +- [ ] Re-run fixed sanitizer +- [ ] Selectively re-apply review patches + +--- + +## Related Documentation + +- [Post-Import Sanitizer: 5 Bugs Found](../integration-issues/post-import-sanitizer-bugs-found-japanese-review.md) — Detailed root cause analysis of the 5 sanitizer bugs +- [Review Agent Calibration (Czech)](../integration-issues/crowdin-import-review-agent-calibration.md) — False positive calibration on Czech translations +- [Crowdin File Path Mapping and Review Workflow](../integration-issues/crowdin-file-path-mapping-and-review-workflow.md) — Worktree workflow, automation permissions +- [Turkish PR #17182 Review](./crowdin-import-review-turkish-pr-17182.md) — First review case study establishing baseline issue catalog +- [Scaling Translation Review Pipeline](./scaling-translation-review-pipeline.md) — Strategic roadmap with prevention matrix +- [Review Translations Permissions](../integration-issues/review-translations-permissions.md) — Sandbox permissions inventory for the pipeline diff --git a/docs/solutions/translation-review/japanese-translation-quality-review-fix-process-pr-17132.md b/docs/solutions/translation-review/japanese-translation-quality-review-fix-process-pr-17132.md new file mode 100644 index 00000000000..384a693becd --- /dev/null +++ b/docs/solutions/translation-review/japanese-translation-quality-review-fix-process-pr-17132.md @@ -0,0 +1,313 @@ +--- +title: "Japanese Translation Quality Scoring, Review & Fix Process — PR #17132" +date: 2026-02-24 +category: translation-review +severity: medium +component: public/content/translations/ja +pipeline: review-translations-local +language: ja +pr_number: 17132 +file_count_reviewed: 306 +overall_quality_score: 4.89 +final_commit: 0b2a385fd8 +tags: + - i18n + - japanese + - crowdin-import + - quality-scoring + - parallel-review-agents + - escaped-bold + - tag-regression + - duplicate-headings + - edge-cases + - mdx-escaping +related_prs: + - "#17132" +related_branches: + - i18n/import/2026-01-21T17-37-56-ja +related_docs: + - ./crowdin-import-review-japanese-pr-17132.md + - ./crowdin-import-review-turkish-pr-17182.md + - ../integration-issues/crowdin-import-review-agent-calibration.md + - ../integration-issues/review-translations-permissions.md +symptoms: + - "Escaped bold markers (\\*\\*text\\*\\*) in 49 files from Crowdin escaping" + - "Tag regression スマート契約 instead of スマートコントラクト in 27 tutorial files" + - "Duplicate/concatenated headings in 8 files (12 instances)" + - "Critical data corruption: digit dropped in ethash constant (584685552 → 5846855552)" + - "Critical mistranslation: オラクル → 神託 (oracle mistranslated as divine message)" + - "Critical mistranslation: ゼロ知識ロールアップ → ゼロ知識糾合 (zk-rollup garbled)" + - "Missing heading text: ## 。 instead of ## 関係者 in governance" + - "Broken markdown link syntax in dart/index.md" + - "Rude imperative form: パーティーに参加しろ instead of しよう" +root_causes: + - "Crowdin automated escaping of markdown bold markers during translation" + - "Crowdin translator regression on established terminology (smart contract)" + - "Heading concatenation artifacts from Crowdin segment merging" + - "Human translator errors on technical constants and specialized terms" + - "Tone register mismatch in imperative translations" +metrics: + scoring_dimensions: 5 + parallel_agents: 13 + chunk_size: 25 + files_with_fixes: 89 + insertions: 169 + deletions: 169 +--- + +# Japanese Translation Quality Scoring, Review & Fix Process — PR #17132 + +## Context + +After the initial sanitizer phase (documented in [crowdin-import-review-japanese-pr-17132.md](./crowdin-import-review-japanese-pr-17132.md)) which fixed structural/mechanical issues, a comprehensive quality scoring review was performed on all 306 Japanese translation files in PR #17132. This second phase focused on translation accuracy, terminology consistency, and content integrity. + +## Approach: Parallel Agent Quality Scoring + +### Architecture + +All 306 files were divided into 25-file chunks and reviewed by 13 parallel sub-agents (chunks aa through am). Each agent scored files on 5 quality dimensions: + +| Dimension | Weight | Description | +|-----------|--------|-------------| +| Completeness | 1.0 | No missing sections, paragraphs, or list items vs English source | +| MDX/HTML Integrity | 1.0 | All tags balanced, no broken markup, valid frontmatter | +| Brand Name Handling | 1.0 | Ethereum, Solidity, etc. preserved correctly (not transliterated) | +| Code Block Preservation | 1.0 | Code fences, inline code, and technical constants unchanged | +| Formatting Preservation | 1.0 | Heading levels, link syntax, list structure match source | + +### Results + +| Chunk | Files | Score | +|-------|-------|-------| +| aa | 1–25 | 4.84 | +| ab | 26–50 | 4.91 | +| ac | 51–75 | 4.91 | +| ad | 76–100 | 4.78 | +| ae | 101–125 | 4.92 | +| af | 126–150 | 4.97 | +| ag | 151–175 | 4.79 | +| ah | 176–200 | 4.80 | +| ai | 201–225 | 4.89 | +| aj | 226–250 | 4.90 | +| ak | 251–275 | 4.91 | +| al | 276–300 | 4.97 | +| am | 301–306 | 4.98 | +| **Overall** | **306** | **4.89/5.0** | + +--- + +## Issues Found and Fixed + +### Critical Issues (6) + +These required immediate, targeted fixes: + +1. **Ethash data corruption** — `public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md` + - `584685552` → `5846855552` (digit dropped from constant) + - Impact: Incorrect technical specification data + +2. **Oracle mistranslation** — `public/content/translations/ja/developers/docs/oracles/index.md` + `src/intl/ja/page-developers-docs.json` + - `title: "神託"` → `title: "オラクル"` (page title) + - `"docs-nav-oracles": "神託"` → `"docs-nav-oracles": "オラクル"` (nav label) + - Impact: "Oracle" translated as "divine message" instead of using standard katakana loanword + +3. **ZK-Rollup garbling** — `src/intl/ja/glossary.json` + - `"zk-rollup-term": "ゼロ知識糾合"` → `"zk-rollup-term": "ゼロ知識ロールアップ"` + - Impact: Established term replaced with meaningless kanji combination + +4. **Missing heading text** — `public/content/translations/ja/governance/index.md` + - `## 。 {#who-is-involved}` → `## 関係者 {#who-is-involved}` + - Impact: Section heading was just a period + +5. **Broken markdown link** — `public/content/translations/ja/developers/docs/programming-languages/dart/index.md` + - `[darticulate.com](https://pub.dev/packages/ethereumのEthereum 5.0.0)` → `[darticulate.comのEthereum 5.0.0](https://pub.dev/packages/ethereum)` + - Impact: URL contained Japanese text, link text and URL were swapped + +6. **MEV-Boost description** — Traced to English source, not a translation bug. Noted but not fixed in translation. + +### Systematic Issues + +#### Escaped Bold (49 files) + +Crowdin escaped markdown bold markers during translation: + +```markdown + +\*\*イーサリアム\*\* は分散型プラットフォームです + + +**イーサリアム** は分散型プラットフォームです +``` + +Pattern: `\*\*text\*\*` → `**text**` across 49 files. + +#### Tag Regression: Smart Contract (27 tutorial files) + +Crowdin reverted the established term back to a literal translation: + +```markdown + +スマート契約をデプロイする + + +スマートコントラクトをデプロイする +``` + +Pattern: `スマート契約` → `スマートコントラクト` in 27 tutorial files. + +#### Duplicate/Concatenated Headings (8 files, 12 instances) + +Crowdin segment merging produced concatenated headings: + +```markdown + +## デザイン原則とは 貢献の方法 {#ways-to-contribute} + + +## デザイン原則とは {#ways-to-contribute} +``` + +Note: The anchor ID `{#ways-to-contribute}` not matching heading text `デザイン原則とは` is inherited from the English source — **not a translation bug**. + +### Notable Individual Issues (7 files) + +| File | Issue | Fix | +|------|-------|-----| +| `src/intl/ja/page-roadmap.json` | Duplicated sentence + typo `このになります` | Removed dupe, fixed → `ことになります` | +| `src/intl/ja/page-layer-2.json` | Garbled `複イーサリアムクライアント` | Fixed → `複数のイーサリアムクライアント` | +| `src/intl/ja/page-10-year-anniversary.json` | Rude imperative `パーティーに参加しろ` (2x) | Fixed → `パーティーに参加しよう` | +| `public/.../whitepaper/index.md` | `または` in code fence (should be English) | Restored → `or` | +| `src/intl/ja/page-community-events.json` | `ハッカソン画像` (extra word) | Fixed → `ハッカソン` | +| `public/.../run-node-raspberry-pi/index.md` | `ベス` (transliterated brand) | Restored → `Besu` | +| `public/.../how-to-mint-an-nft/index.md` | `\<10分で` | Fixed → `\<10分で` (MDX-safe) | + +--- + +## Edge Cases and False Positives + +### Critical Learning: Intentional `\*\*` in EVM Opcodes + +The fix agent changed `\*\*` to `**` in `evm/opcodes/index.md`. However, this file uses `\*\*` **intentionally** for exponentiation notation in markdown tables: + +```markdown +| 0x0A | EXP | 指数関数 | a b → a \*\* b | +``` + +Here `\*\*` represents the exponentiation operator `2**256`, escaped to prevent markdown bold rendering inside the table. **This change was reverted.** + +**Lesson:** Not all `\*\*` patterns are Crowdin escaping artifacts. In tables with mathematical notation, they represent literal asterisks for operators. + +### Critical Learning: MDX `\<` Escaping + +The English source uses `\<10 minutes` to prevent MDX from interpreting `<10` as an HTML tag. The correct Japanese equivalent is `\<10分で`, not `<10分で` (bare angle bracket) or `\<10分で` (HTML entity). + +**Lesson:** When English source uses `\<`, the translation must preserve this MDX escape pattern. + +### Critical Learning: Heading Anchor Inheritance + +Some headings have anchor IDs that don't match their translated text: + +```markdown +## デザイン原則とは {#ways-to-contribute} +``` + +This looks wrong (the heading says "What are design principles?" but the anchor says "ways-to-contribute"). However, this mismatch is inherited from the English source file. **Do not "fix" anchor IDs — they are stable identifiers used in external links.** + +### Not a Translation Bug: Lorem Ipsum in page-trillion-dollar-security + +The `page-trillion-dollar-security` content contains lorem ipsum placeholder text. This matches the English source — it's intentional placeholder content, not a translation error. + +--- + +## Prevention Strategies + +### 1. Escaped Bold Pattern Filter + +Add to the sanitizer to automatically fix the most common Crowdin artifact: + +```typescript +function fixEscapedBold(content: string): string { + // Skip code blocks + const codeBlockRegex = /```[\s\S]*?```|`[^`]+`/g; + const codeBlocks: Array<{ start: number; end: number }> = []; + let match; + while ((match = codeBlockRegex.exec(content)) !== null) { + codeBlocks.push({ start: match.index, end: match.index + match[0].length }); + } + + return content.replace(/\\\*\\\*(.+?)\\\*\\\*/g, (m, inner, offset) => { + // Don't fix inside code blocks + if (codeBlocks.some(b => offset >= b.start && offset < b.end)) return m; + // Don't fix in markdown tables (likely math operators) + const lineStart = content.lastIndexOf('\n', offset) + 1; + const line = content.slice(lineStart, content.indexOf('\n', offset)); + if (line.trimStart().startsWith('|')) return m; + return `**${inner}**`; + }); +} +``` + +Key guard: **Skip markdown table rows** to avoid the EVM opcodes false positive. + +### 2. Terminology Regression Checklist + +Maintain a per-language protected terms list: + +```yaml +# ja-protected-terms.yaml +terms: + - source: "smart contract" + correct: "スマートコントラクト" + incorrect: ["スマート契約", "賢い契約"] + - source: "oracle" + correct: "オラクル" + incorrect: ["神託", "託宣"] + - source: "zero-knowledge rollup" + correct: "ゼロ知識ロールアップ" + incorrect: ["ゼロ知識糾合"] + - source: "proof of stake" + correct: "プルーフ・オブ・ステーク" + incorrect: ["ブルーフ・オブ・ステーク"] +``` + +### 3. Technical Constant Validation + +For files containing numeric constants (ethash parameters, gas costs, etc.), compare all numbers in the translation against the English source. Flag any that differ. + +### 4. Quality Scoring as Gate + +Use the 5-dimension scoring (completeness, MDX integrity, brand names, code blocks, formatting) as a CI gate. Any file scoring below 4.0 on any dimension gets flagged for human review. + +### 5. Review Checklist for Future Japanese Imports + +Before committing: + +- [ ] Search for `\*\*` — fix in prose, **skip in tables** +- [ ] Search for `スマート契約` — should be `スマートコントラクト` +- [ ] Search for `神託` — should be `オラクル` +- [ ] Search for `糾合` — likely garbled `ロールアップ` +- [ ] Search for `ブルーフ` — should be `プルーフ` +- [ ] Verify numeric constants in ethash, gas, and EVM pages against English source +- [ ] Check heading anchors — mismatches with text are OK if inherited from English +- [ ] Check `\<` patterns — preserve MDX escaping from English source +- [ ] Check tone — `しろ` (rude imperative) should be `しよう` (friendly volitional) + +--- + +## Commit Summary + +**Commit `0b2a385fd8`** on branch `i18n/import/2026-01-21T17-37-56-ja`: + +- 89 files changed +- 169 insertions, 169 deletions +- Categories: 6 critical fixes, 49 escaped bold, 27 tag regressions, 12 duplicate heading fixes, 7 notable individual fixes, 1 revert (evm/opcodes) + +--- + +## Related Documentation + +- [Japanese Translation Import Review (Sanitizer Phase)](./crowdin-import-review-japanese-pr-17132.md) — Phase 1: sanitizer bugs and structural fixes +- [Turkish PR #17182 Review](./crowdin-import-review-turkish-pr-17182.md) — First review establishing baseline issue catalog +- [Review Agent Calibration (Czech)](../integration-issues/crowdin-import-review-agent-calibration.md) — False positive calibration learnings +- [Review Translations Permissions](../integration-issues/review-translations-permissions.md) — Pipeline sandbox permissions +- [Ethereum.org Translation Program](https://ethereum.org/en/contributing/translation-program/) — Upstream translation program docs diff --git a/public/content/translations/ja/about/index.md b/public/content/translations/ja/about/index.md index 4fdd08081e1..222cb8e7287 100644 --- a/public/content/translations/ja/about/index.md +++ b/public/content/translations/ja/about/index.md @@ -1,6 +1,6 @@ --- -title: ethereum.orgについて -description: チーム、コミュニティ、ethereum.orgのミッションについて +title: "ethereum.orgについて" +description: "チーム、コミュニティ、ethereum.orgのミッションについて" lang: ja --- @@ -8,7 +8,9 @@ lang: ja ethereum.orgは、イーサリアムコミュニティのために公開されたオープンソースのリソースで、誰でも参加できます。 私たちは、世界中の何千ものコミュニティメンバーからの貢献によって、サイトの維持と開発を行うことに専念する少数精鋭のチームで構成されています。 -## 名称に関するメモ {#a-note-on-names} +**ethereum.orgのスタッフからあなたに連絡することはありません。 反応しないでください。** + +## 名称に関する注記 {#a-note-on-names} イーサリアム環境内には多数の名称があり、皆さんの混乱のもとになっています。これでは、イーサリアムの仕組みについて深く理解できない可能性があります。 そこで、名称について簡単な説明をします。 @@ -18,15 +20,15 @@ ethereum.orgは、イーサリアムコミュニティのために公開され [イーサリアムについての詳細](/what-is-ethereum/) -[イーサリアムのガバナンスについての詳細](/governance/) +[イーサリアムにおけるガバナンスの詳細](/governance/) -### イーサ(ETH)画像 {#ether-or-eth} +### イーサ(ETH) {#ether-or-eth} イーサ(ティッカーシンボル「ETH」としても知られています)は、イーサリアムで取引されるネイティブ通貨です。 ETHは、イーサリアムのネットワーク使用料を(取引手数料の形で)支払うために必要となり、 ETHは、ステークキングでネットワークを保護するためにも使用されます。 イーサリアムの価格について話している時は、ETHを資産として言及しています。 -[ETHの詳細](/what-is-ether/) +[ETHについての詳細](/what-is-ether/) -[ETHのステーキングの詳細](/staking/) +[ETHのステーキングに関する詳細](/staking/) ### イーサリアム・ファウンデーション {#ethereum-foundation} @@ -40,9 +42,9 @@ ethereum.orgは、イーサリアムコミュニティのために公開され このページでは、ethereum.orgに関する詳細情報をご紹介します。 -## ethereum.orgのミッション {#our-mission} +## 私たちのミッション {#our-mission} -**ethereum.orgのミッションは、増大するイーサリアムコミュニティのための最高のポータルになることです。** +**ethereum.orgのミッションは、増大するイーサリアムコミュニティのための最高のポータルになることです** 私たちは、イーサリアムに関連するすべてのトピックについて、理解しやすい教育リソースを構築するよう努めており、新しいユーザーがイーサリアムとその主要概念を熟知できるようサポートすることを目的としています。 具体的なミッションは以下の通りです。 @@ -62,7 +64,7 @@ ethereum.orgは、イーサリアムコミュニティのために公開され - アンケート、クイズ、Web3の統合などの機能を介して、ユーザーのエンゲージメントを高めます。 - ウェブサイトを軽量にして、パフォーマンスを保ちます。 -### 2. コミュニティ貢献者の増加、強化、権限付与 {#community} +### 2. 貢献者コミュニティの成長、強化、活性化 {#community} - ウェブサイトへの貢献者の総数を増加させます。 - エンゲージメント、謝辞、報酬により貢献者の定着率を向上させます。 @@ -70,58 +72,63 @@ ethereum.orgは、イーサリアムコミュニティのために公開され - コード、コンテンツ、デザイン、翻訳、モデレーションなど、貢献の多様性を促進します。 - コードベースをモダンかつクリーンに、しっかりと文書化された状態に維持します。 -## 基本方針 {#core-principles} +## 基本原則 {#core-principles} ミッションを達成するためにいくつかの基本原則があります。 ### 1. ethereum.orgは、イーサリアムへの入口となる場所です🌏 {#core-principles-1} -ユーザーの皆さんには、興味関心を高め、疑問をなくしていただきたいと考えています。 そのためには、情報・"魔法の瞬間"・素晴らしいコミュニティリソースへのリンクという三つの組み合わせが重要になります。 このコンテンツの目的は、既存の広大な資料の代用として機能することではなく、「入門研修用ポータルサイト」となることです。 コミュニティが作り上げた情報源を支援・統合し、見やすく、見つけやすくしたいと考えています。 [イーサリアムのコミュニティ](/community/)は、その中心となる場所です。ここでは単にコミュニティにサービス提供するだけでなく、協働し、フィードバックを取り入れていきます。 このウェブサイトは現在のコミュニティのためだけではありません。発展した未来のコミュニティのためのものでもあります。 多言語・多地域・多文化の人々が集まったグローバルなコミュニティであることを決して忘れてはなりません。 +ユーザーの皆さんには、興味関心を高め、疑問をなくしていただきたいと考えています。 そのためには、情報・"魔法の瞬間"・素晴らしいコミュニティリソースへのリンクという三つの組み合わせが重要になります。 このコンテンツの目的は、既存の広大な資料の代用として機能することではなく、「入門研修用ポータルサイト」となることです。 コミュニティが作り上げた情報源を支援・統合し、見やすく、見つけやすくしたいと考えています。 +[イーサリアムのコミュニティ](/community/)がその中核をなしています。私たちは、ただコミュニティにサービスを提供するだけでなく、彼らと協力し、フィードバックを取り入れていく必要があります。 このウェブサイトは現在のコミュニティのためだけではありません。発展した未来のコミュニティのためのものでもあります。 多言語・多地域・多文化の人々が集まったグローバルなコミュニティであることを決して忘れてはなりません。 ### 2. ethereum.orgは常に進化しています🛠 {#core-principles-2} -イーサリアムとコミュニティは常に進化しており、ethereum.orgも同様です。 このサイトがシンプルデザインのシステムで、モジュラー構造を取り入れているのもそのためです。 サイトの活用方法やコミュニティがサイトに望むことについて理解を深めながら、それに合わせて継続的に変更を加えていきます。 また、コントリビューターのコミュニティを有するオープンソースであるため、誰でも変更を提案したり、支援したりすることができます。 [貢献についての詳細](/contributing/)。 +イーサリアムとコミュニティは常に進化しており、ethereum.orgも同様です。 そのため、当サイトはシンプルなデザインシステムとモジュラー構造を採用しています。 サイトの活用方法やコミュニティがサイトに望むことについて理解を深めながら、それに合わせて継続的に変更を加えていきます。 +また、コントリビューターのコミュニティを有するオープンソースであるため、誰でも変更を提案したり、支援したりすることができます。 +[貢献について学ぶ](/contributing/) ### 3. ethereum.orgは製品を紹介するだけの典型的なウェブサイトではありません🦄 {#core-principles-3} -イーサリアムとは、コミュニティ、テクノロジー、ひとまとまりのアイデア・思想などが盛り込まれた大きな概念です。 つまり、このウェブサイトは、「具体的なツールが欲しいデベロッパー」から、「ETHを少し買いたいだけだが、ウォレットが何なのかも知らない初心者」まで多様なユーザーの要望に応える必要があるということです。 「ブロックチェーン・プラットフォームについて、一番いいウェブサイトはどこ？」という質問は今も投げかけられ続けていますが、私たちはその先駆者です。 こういったものを作るには試行錯誤が必要です。 +イーサリアムとは、コミュニティ、テクノロジー、ひとまとまりのアイデア・思想などが盛り込まれた大きな概念です。 +つまり、このウェブサイトは、「具体的なツールが欲しいデベロッパー」から、「ETHを少し買いたいだけだが、ウォレットが何なのかも知らない初心者」まで多様なユーザーの要望に応える必要があるということです。 +「ブロックチェーン・プラットフォームについて、一番いいウェブサイトはどこ？」という質問は今も投げかけられ続けていますが、私たちはその先駆者です。 こういったものを作るには試行錯誤が必要です。 ## 製品ロードマップ {#roadmap} -ethereum.orgコアチームは、私たちの取り組みへのアクセスを簡素化し、より多くのコミュニティとのコラボレーションを促進するために、四半期ごとのロードマップ目標の概要を公開しています。 +私たちの取り組みをより身近なものにし、コミュニティの連携をさらに促進するため、ethereum.orgのコアチームは、[シェイプアップサイクル](https://www.productplan.com/glossary/shape-up-method/)のロードマップ目標の概要を公開しています。 -[2024年第3四半期のプロダクトロードマップをご覧ください。](https://github.com/ethereum/ethereum-org-website/issues/13399) +[2025年サイクル1の製品ロードマップを見る](https://github.com/ethereum/ethereum-org-website/issues/14726) -**いかがでしょうか?**ロードマップに関するフィードバックをお待ちしております。私たちが取り組むべきことについてご意見があれば、お知らせください。 コミュニティからのアイデアやPRをお待ちしています。 +**いかがでしょうか?** ロードマップに関するフィードバックをお待ちしております。私たちが取り組むべきことについてご意見があれば、お知らせください。 コミュニティからのアイデアやPRをお待ちしています。 -**参加を希望されますか?** [貢献の詳細](/contributing/)をご参照ください。[Twitter](https://twitter.com/ethdotorg)で連絡いただくか、[Discordサーバー](https://discord.gg/ethereum-org)のコミュニティディスカッションに参加してください。 +**参加しませんか？** [貢献についての詳細を学ぶ](/contributing/)、[Twitterで私たちにご連絡いただく](https://x.com/ethdotorg)か、あるいは[私たちのDiscordサーバー](https://discord.gg/ethereum-org)のコミュニティディスカッションにご参加ください。 ## デザイン原則 {#design-principles} -私たちは、 [デザイン原則](/contributing/design-principles/)を使用して、ウェブサイトのコンテンツおよびデザインの決定を行います。 +私たちはサイト上のコンテンツとデザインの決定を導くために、一連の[デザイン原則](/contributing/design-principles/)を使用しています。 ## デザインシステム {#design-system} -私たちは、機能のリリースを迅速化するために[デザインシステム](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1)を構築し、コミュニティメンバーがethereum.orgのオープンデザインに参加できるようにしました。 +私たちは、機能をより迅速にリリースし、コミュニティメンバーがethereum.orgのオープンデザインに参加できるようにするために、[デザインシステム](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1)を構築し、公開しました。 -参加を希望されますか?[Figma](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System)をフォローするか、[GitHubイシュー](https://github.com/ethereum/ethereum-org-website/issues/6284)に従うか、もしくは[#design Discordチャンネル](https://discord.gg/ethereum-org)の打ち合わせに加わってください。 +参加を希望されますか?[Figmaでフォロー](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System)、[GitHub issue](https://github.com/ethereum/ethereum-org-website/issues/6284) を確認し、私たちの [#design Discordチャンネル](https://discord.gg/ethereum-org)での会話にご参加ください。 ## スタイルガイド {#style-guide} -貢献プロセスをスムーズにするために、[スタイルガイド](/contributing/style-guide/)で文章の標準化を図っています。 +貢献プロセスをよりスムーズにするために、コンテンツ作成の特定の側面を標準化するための[スタイルガイド](/contributing/style-guide/)があります。 -[イーサリアムのウェブサイト](/contributing/design-principles/)への貢献をご希望される場合は、最初に[原則](/contributing/style-guide/)と[スタイルガイド](/contributing/)をお読みください。 +もし[サイトに貢献する](/contributing/)ことを希望される場合は、[私たちの原則](/contributing/design-principles/)と[私たちのスタイルガイド](/contributing/style-guide/)を必ずお読みください。 デザインの原則、デザインシステム、スタイルガイドに関するフィードバックをお待ちしています。 ethereum.orgはコミュニティによるコミュニティのためのものであることを忘れないでください。 ## ライセンス {#license} -Ethereum.orgのウェブサイトは、特に指定がない限り、[MITライセンス](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE)の下でオープンソースとして構築されています。 詳細は、ethereum.orgの[利用規約](/terms-of-use/)をご覧ください。 +特に明記されていない限り、ethereum.orgのウェブサイトはオープンソースであり、[MITライセンス](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE)の下で構築されています。 ethereum.orgの[利用規約](/terms-of-use/)についての詳細 ## 求人情報 {#open-jobs} このウェブサイトはオープンソースで、誰でも作業できますが、ethereum.orgや他のイーサリアム・ファウンデーションのWebプロジェクトに専念するチームがあります。 -求人情報はすべてこちらに掲載されます。 ご自身に向いている役割が見つからない場合は、[Discordサーバー](https://discord.gg/ethereum-org)にアクセスして、協働したい内容について教えてください。 +求人情報はすべてこちらに掲載されます。 ご自身に合った役割が見つからない場合は、[私たちのDiscordサーバー](https://discord.gg/ethereum-org)にお越しいただき、どのような形で協力したいかをお知らせください。 -ethereum.orgチーム以外にも目を向けてみませんか？ [他のイーサリアム関連の求人情報もぜひご覧ください。](/community/get-involved/#ethereum-jobs/). +ethereum.orgチーム以外にも目を向けてみませんか？ [その他のイーサリアム関連の求人を見る](/community/get-involved/#ethereum-jobs/) diff --git a/public/content/translations/ja/ai-agents/index.md b/public/content/translations/ja/ai-agents/index.md new file mode 100644 index 00000000000..fc2be54d839 --- /dev/null +++ b/public/content/translations/ja/ai-agents/index.md @@ -0,0 +1,146 @@ +--- +title: "AIエージェント" +metaTitle: "AIエージェント | Ethereum上のAIエージェント" +description: "イーサリアム上の AI エージェントの概要" +lang: ja +template: use-cases +emoji: ":robot:" +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: "ターミナルテーブルに集まった人々" +summaryPoint1: "ブロックチェーン上で自律的に売買を行うAI" +summaryPoint2: "オンチェーンウォレットと資金を管理します" +summaryPoint3: "人間や他のエージェントを雇用して作業を依頼します" +buttons: + - content: AIエージェントとは？ + toId: what-are-ai-agents + - content: エージェントを探索 + toId: ai-agents-on-ethereum + isSecondary: false +--- + +AIアシスタントがオンチェーンの市場トレンドを24時間365日分析し、質問に回答し、さらにあなたに代わってトランザクションを実行し、イーサリアムの世界をナビゲートすることを想像してみてください。 AIエージェントの世界へようこそ——あなたのデジタルライフをよりシンプルにするために設計されたインテリジェントシステムです。 + +イーサリアム上では、AIエージェントによる革新が次々と生まれています。 +バーチャルインフルエンサーや自律的なコンテンツクリエイターから、リアルタイム市場分析プラットフォームに至るまで、これらの技術はユーザーに洞察・エンターテインメント・業務効率をもたらし、より大きな力を与えています。 + +## AIエージェントとは？ {#what-are-ai-agents} + +AIエージェントとは、人工知能を用いてタスクを実行したり、自ら意思決定を行ったりするソフトウェアプログラムのことです。 それらはデータから学習し、変化に適応し、複雑なタスクをこなします。 それらは休むことなく稼働し、チャンスを瞬時に見つけ出すことができます。 + +### AIエージェントがブロックチェーンとどのように連携するか {#how-ai-agents-work-with-blockchains} + +従来の金融システムでは、AIエージェントは主に中央集権的な環境で動作し、利用できるデータ入力が限られています。 このことが、Aiエージェントが自律的に学習したり資産を管理したりする能力を妨げています。 + +対照的に、Ethereumの分散型エコシステムには、いくつかの重要な利点があります： + +- 透明性のあるデータ： リアルタイムのブロックチェーン情報へのアクセス。 +- 真の資産所有権: デジタル資産はAIエージェント自身が完全に所有します。 +- 堅牢なオンチェーン機能: AIエージェントが取引を実行し、スマートコントラクトとやり取りし、流動性を提供し、複数のプロトコル間で協働することを可能にします。 + +これらの要素によって、AIエージェントは単なるボットから、複数の分野で大きな価値を生み出す動的で自己進化型のシステムへと変貌します： + + + + + + + +## 検証可能なAI {#verifiable-ai} + +オフチェーンで実行されるAIエージェントは、しばしば「ブラックボックス」のように振る舞います。その推論、入力、出力は独立して検証することができません。 イーサリアムはそれを変えます。 エージェントの行動をオンチェーンにアンカリングすることで、デベロッパーは_トラストレス_で、_透明性_があり、_経済的に自律した_エージェントを構築できます。 そのようなエージェントの行動は、監査、制約、証明が可能です。 + +### 検証可能な推論 {#verifiable-inference} + +AIの推論は従来、オフチェーンで行われます。そこでは実行コストは安いですが、モデルの実行は不透明です。 イーサリアムでは、デベロッパーはいくつかの技術を使って、エージェントを検証可能な計算と組み合わせることができます。 + +- [**zkML (ゼロ知識機械学習)**](https://opengradient.medium.com/a-gentle-introduction-to-zkml-8049a0e10a04)は、エージェントがモデルや入力を明かすことなく、モデルが正しく実行されたことを証明することを可能にします。 +- [**TEE (信頼できる実行環境) アテステーション**](https://en.wikipedia.org/wiki/Trusted_execution_environment)は、エージェントが特定のモデルまたはコードパスを実行したという、ハードウェアに裏付けられた証明を可能にします。 +- **オンチェーンの不変性**は、これらの証明とアテステーションが、あらゆるコントラクトやエージェントによって参照、再生、信頼できることを保証します。 + +## x402による支払いと商取引 {#x402} + +イーサリアムとL2にデプロイされている[x402プロトコル](https://www.x402.org/)は、エージェントが人間の介入なしにリソースの支払いを行い、経済的に相互作用するためのネイティブな方法を提供します。 エージェントは以下を実行できます。 + +- ステーブルコインを使用して、コンピュート、データ、APIコールの支払いを行う +- 他のエージェントやサービスからのアテステーションを要求または検証する +- エージェント間の商取引に参加し、コンピュート、データ、またはモデルの出力を売買する + +x402はイーサリアムを自律エージェントのためのプログラム可能な経済レイヤーに変え、アカウント、サブスクリプション、または中央集権型の請求ではなく、都度払いのインタラクションを可能にします。 + +### エージェント型金融のセキュリティ {#agentic-finance-security} + +自律エージェントにはガードレールが必要です。 イーサリアムは、ウォレットとコントラクトのレベルでそれらを提供します。 + +- [スマートアカウント (EIP-4337)](https://eips.ethereum.org/EIPS/eip-4337)により、デベロッパーは支払い上限、ホワイトリスト、セッションキー、詳細な権限を強制できます。 +- スマートコントラクトにプログラムされた制約は、エージェントに許可されていることを制限できます。 +- 推論ベースの制限(例えば、高リスクのアクションを実行する前にzkML証明を要求するなど)は、さらなる安全性のレイヤーを追加します。 + +これらの制御により、無制限ではない自律エージェントのデプロイが可能になります。 + +### オンチェーンレジストリ: ERC-8004 {#erc-8004} + +[ERC-8004](https://eips.ethereum.org/EIPS/eip-8004)は、エージェントのアイデンティティ、機能、アテステーションのためのオンチェーンレジストリを提案する新しい標準です (現在ピアレビュー中)。 + +採用されれば、以下を提供できる可能性があります。 + +- エージェントの共有されたトラストレスなディレクトリ +- 標準化されたアテステーションのフォーマット +- イーサリアムメインネット上に直接構築される「トラストレスなエージェントインフラストラクチャ」のための基盤 + +これにより、完全に分散化された環境でエージェントが互いに発見、検証、取引することが容易になります。 + +## イーサリアム上のAIエージェント {#ai-agents-on-ethereum} + +私たちは今まさに、AIエージェントの持つ潜在能力を本格的に探求し始めています。 +すでにいくつかのプロジェクトでは、AIとブロックチェーンの相乗効果――特に透明性と収益化の分野で――を活用し始めています。 + + + +Lunaの初めてのポッドキャスト出演 + + + +## エージェント制御ウォレット {#agent-controlled-wallets} + +LunaやAIXBTのようなエージェントは、自身のオンチェーンウォレット（[AIXBTのウォレット](https://clusters.xyz/aixbt)、[Lunaのウォレット](https://zapper.xyz/account/0x0d177181e3763b20d47dc3a72dd584368bd8bf43)）を管理しており、ファンへのチップ送付や経済活動への参加を可能にしています。 + +LunaのXでのソーシャルキャンペーン「#LunaMuralChallenge」において、Lunaは自身のBaseウォレットを通じて受賞者を選び、報酬を支払いました。これは、AIが初めて人間を雇い、暗号資産による報酬を与えた事例として注目されました。 + + + + +

知っておくと良いこと

+

AIエージェントおよび関連ツールは、まだ開発の初期段階にあり、非常に実験的な段階です——使用には注意が必要です。

+ + + + +## チャットコマンドでウォレットを操作する {#control-your-wallet-using-chat-commands} + +複雑なDeFiのインターフェースを使わずに、シンプルなチャットコマンドで暗号資産を管理できます。 + +この直感的なアプローチにより、取引はより迅速かつ簡単になり、誤送金や手数料の過払いといったエラーの発生も減少します。 + + + +## AIエージェントとAIボットの違い {#ai-agents-vs-ai-bots} + +AIエージェントとAIボットの違いは、どちらも入力に基づいて自動的に動作するという点で混同されやすいことがあります。 + +- AIボットは自動化されたアシスタントのような存在で、特定のあらかじめプログラムされた指示に従って定型的なタスクを実行します。 +- AIエージェントは、より知的なコンパニオンのような存在です。経験から学習し、新しい情報に適応し、自ら判断を下すことができます。 + +| | AIエージェント | AIボット | +| ------------ | --------------------------------------- | --------------------------------- | +| **インタラクション** | 複雑で、適応性があり、自律的 | シンプルで、あらかじめ定義された範囲を持ち、ハードコードされている | +| **学習** | 継続的に学習し、リアルタイムで新しいデータに基づいて試行・適応することができる | 事前に学習されたデータや固定されたルールに基づいて動作する | +| **タスクの完了** | より広い目的の達成を目指す | 特定のタスクのみに焦点を当てる | + +## さらに深掘りする {#dive-deeper} + + + +## 自分のAIエージェントを構築する {#you-can-build-your-own-ai-agent} + + diff --git a/public/content/translations/ja/bridges/index.md b/public/content/translations/ja/bridges/index.md index 15569aecc66..19656bcf4d1 100644 --- a/public/content/translations/ja/bridges/index.md +++ b/public/content/translations/ja/bridges/index.md @@ -1,37 +1,37 @@ --- -title: ブロックチェーンブリッジの紹介 -description: 異なるブロックチェーン間の資金移動を可能にするブリッジ +title: "ブロックチェーンブリッジの紹介" +description: "異なるブロックチェーン間の資金移動を可能にするブリッジ" lang: ja --- # ブロックチェーンブリッジ {#prerequisites} -_Web3は、L1ブロックチェーンとL2スケーリングソリューションのエコシステムに発展し、それぞれ独自の機能とトレードオフがあります。 ブロックチェーンのプロトコルが増えるにつれ、チェーン間で資産を移動させる需要も増えています。 この需要を満たすのが、ブリッジです。_ +_Web3は、L1ブロックチェーンとL2スケーリングソリューションのエコシステムへと進化し、それぞれが独自の機能とトレードオフを持つように設計されています。_ ブロックチェーンのプロトコルが増えるにつれ、チェーン間で資産を移動させる需要も増えています。_この需要を満たすためには、ブリッジが必要です。_ ## ブリッジとは {#what-are-bridges} -ブロックチェーンの世界でのブリッジとは、その名のとおりブリッジ(橋)と同じような機能があります。 橋が2つの場所をつなぐように、ブロックチェーンのブリッジは2つのブロックチェーンエコシステムをつなぎ、 **ブロックチェーン間の情報・資産をやり取りできます**。 +ブロックチェーンの世界でのブリッジとは、その名のとおりブリッジ(橋)と同じような機能があります。 橋が2つの場所をつなぐように、ブロックチェーンのブリッジは2つのブロックチェーンエコシステムをつなぎ、 **ブリッジは、情報と資産の転送を通じて、ブロックチェーン間のコミュニケーションを促進します**。 例を考えてみましょう。 アメリカからヨーロッパに旅行を計画しているとします。 米ドルを持ってますが、支払いにはユーロが必要です。 手数料を払って両替所を利用し、米ドルをユーロに両替することができます。 -しかし、異なる[ブロックチェーン](/glossary/#blockchain)を利用するために、同様の両替を行う場合は、どうすればいいでしょうか? イーサリアムメインネット上のETHから、[Arbitrum](https://arbitrum.io/)の[ETH](/glossary/#ether)への両替を希望しているとします。 米ドルからユーロへの両替のように、イーサリアムからArbitrumへETHを移動させるメカニズムが必要です。 ブリッジはこのようなトランザクションを可能にします。 この場合、[Arbitrumのネイティブブリッジ](https://bridge.arbitrum.io/)があり、メインネットからArbitrumにETHを移動できます。 +しかし、異なる[blockchain](/glossary/#blockchain)を利用するために同様の交換を行いたい場合、どうすればよいのでしょうか？ 例えば、Ethereumメインネット上の[ETH](/glossary/#ether)を[Arbitrum](https://arbitrum.io/)上のETHに交換したいとします。 米ドルからユーロへの両替のように、イーサリアムからArbitrumへETHを移動させるメカニズムが必要です。 ブリッジはこのようなトランザクションを可能にします。 この場合、[Arbitrumにはネイティブブリッジがあり](https://portal.arbitrum.io/bridge)、メインネットからArbitrumにETHを転送できます。 ## ブリッジが必要な理由 {#why-do-we-need-bridges} -すべてのブロックチェーンには制限があります。 イーサリアムが需要に追いつくためにスケールアップするには、[ロールアップ](/glossary/#rollups)が必要です。 あるいは、SolanaやAvalancheのようなL1チェーンでは、分散化を代償にして、より高いスループットを実現するために異なる設計をしています。 +すべてのブロックチェーンには制限があります。 Ethereumがスケーリングして需要に追いつくためには、[rollups](/glossary/#rollups)が必要でした。 あるいは、SolanaやAvalancheのようなL1チェーンでは、分散化を代償にして、より高いスループットを実現するために異なる設計をしています。 -しかし、すべてのブロックチェーンは、独立した環境で開発され、異なるルールと[合意](/glossary/#consensus)メカニズムを使用します。 つまり、ネイティブではブロックチェーン間の通信ができず、トークンもブロックチェーン間を自由に移動できません。 +しかし、すべてのブロックチェーンは独立した環境で開発されており、それぞれが異なるルールと[consensus](/glossary/#consensus)メカニズムを持っています。 つまり、ネイティブではブロックチェーン間の通信ができず、トークンもブロックチェーン間を自由に移動できません。 ブリッジはブロックチェーンを接続し、ブロックチェーン間の情報、トークンを移動できます。 **ブリッジが可能にすること**: - チェーンの垣根を超えた資産、情報の移動 -- [分散型アプリ(Dapp)](/glossary/#dapp)が複数のブロックチェーンの強みを活用し、機能を向上(プロトコルに現在イノベーションに利用可能な設計余地が増えたため) +- [dapps](/glossary/#dapp)がさまざまなブロックチェーンの強みにアクセスできるようにし、それによって能力を向上させる (プロトコルがイノベーションのためのより多くの設計スペースを持つようになったため)。 - 新しいプラットフォームにアクセスし、異なるチェーンの利点を活用 - 異なるブロックチェーンエコシステムからのデベロッパー同士が協力し、新しいプラットフォームの開発 @@ -43,27 +43,27 @@ _Web3は、L1ブロックチェーンとL2スケーリングソリューショ 下記は、ブリッジを活用できるシナリオです。 -### トランザクションフィーを安価に {#transaction-fees} +### より低い取引手数料 {#transaction-fees} 例えば、イーサリアムメインネットのETHを持っていると仮定して、他の分散型アプリ(Dapp)を探すため、トランザクションフィーをより安価にしたいとします。 メインネットからイーサリアムのL2ロールアップに、ETHをブリッジすることで、トランザクションフィーを安価にすることができます。 -### 他のブロックチェーンの分散型アプリ(Dapp) {#dapps-other-chains} +### 他のブロックチェーン上のdapps {#dapps-other-chains} -USDTを貸し出すのにイーサリアムムメインネットのAaveを使用している場合、PolygonのAaveでUSDTを貸し出すと、金利がより高くなります。 +もしこれまでイーサリアムメインネット上のAaveでUSDTを供給していたとしても、Polygon上のAaveでUSDTを供給した場合の方が、受け取れる金利が高い可能性があります。 -### ブロックチェーンエコシステムの探索 {#explore-ecosystems} +### ブロックチェーンエコシステムを探る {#explore-ecosystems} イーサリアムメインネットでETHを所有していて、代替のL1の分散型アプリ(Dapp)を使用したいとします。 ブリッジを使って、イーサリアムメインネットから他のL1にETHを移動させることができます。 -### ネイティブ仮想通貨の所有 {#own-native} +### ネイティブ暗号資産を所有する {#own-native} -例えば、ネイティブビットコイン(BTC)の保有を希望しており、資金はイーサリアムメインネットにあるとします。 イーサリアムでBTCを入手するために、ラップドビットコイン(WBTC)を購入できます。 しかし、WBTCはイーサリアムネットワークの[ERC-20](/glossary/#erc-20)トークンであり、ビットコインのイーサリアム版のようなもので、ビットコインブロックチェーンの資産ではありません。 ネイティブのBTCを保有するには、イーサリアムからビットコインに資産をブリッジする必要があります。 WBTCをブリッジすれば、ネイティブのBTCに交換できます。 あるいは、BTCを保有していて、イーサリアムの[分散型金融(DeFi)](/glossary/#defi)プロトコルで使用したいとします。 これには、逆にBTCからWBTCへのブリッジが必要となり、WBTCはイーサリアムの資産として使用することができます。 +例えば、ネイティブビットコイン(BTC)の保有を希望しており、資金はイーサリアムメインネットにあるとします。 イーサリアムでBTCを入手するために、ラップドビットコイン(WBTC)を購入できます。 しかし、WBTCはEthereumネットワークにネイティブな[ERC-20](/glossary/#erc-20)トークンです。これは、WBTCがBitcoinのEthereum版であり、Bitcoinブロックチェーン上の本来の資産ではないことを意味します。 ネイティブのBTCを保有するには、イーサリアムからビットコインに資産をブリッジする必要があります。 WBTCをブリッジすれば、ネイティブのBTCに取引できます。 あるいは、BTCを所有していて、それをEthereumの[DeFi](/glossary/#defi)プロトコルで使用したい場合もあるでしょう。 これには、逆にBTCからWBTCへのブリッジが必要となり、WBTCはイーサリアムの資産として使用することができます。 - [中央集権型取引所](/get-eth/)を使用すると、これらのすべてを行えます。 しかし、取引所に資産がある場合を除いては、複数の手順が必要になるため、ブリッジを使用する方が手間が省けます。 + これらすべては、[集中型取引所](/get-eth)を使用して行うこともできます。 しかし、取引所に資産がある場合を除いては、複数の手順が必要になるため、ブリッジを使用する方が手間が省けます。 @@ -74,16 +74,16 @@ USDTを貸し出すのにイーサリアムムメインネットのAaveを使用 ブリッジには多くの種類の設計や複雑さがあります。 一般的に、ブリッジは、トラストとトラストレスの2つのカテゴリに分類されます。 -| トラストブリッジ | トレストレスブリッジ | -| ------------------------------------------------------------ | -------------------------------------------------------------------------- | -| トラストブリッジでは、運用を中央エンティティやシステムに依存します。 | トレストレスブリッジは、スマートコントラクトやアルゴリズムを用いて運用します。 | -| 資産の保管やセキュリティをトラストブリッジに信頼しなければなりません。 ユーザーは主にブリッジ運営の評判に頼っています。 | ブリッジのセキュリティは基盤となるブロックチェーンのセキュリティと同じで、信頼する必要がなく、トラストレスです。 | -| 自分自身の仮想通貨の管理を諦める必要があります。 | [スマートコントラクト](/glossary/#smart-contract)を経由して、トラストレスブリッジにより、自分自身の資金管理ができます。 | +| トラストブリッジ | トレストレスブリッジ | +| ------------------------------------------------------------ | -------------------------------------------------------------------------------------- | +| トラストブリッジでは、運用を中央エンティティやシステムに依存します。 | トレストレスブリッジは、スマートコントラクトやアルゴリズムを用いて運用します。 | +| 資産の保管やセキュリティをトラストブリッジに信頼しなければなりません。 ユーザーは主にブリッジ運営の評判に頼っています。 | ブリッジのセキュリティは基盤となるブロックチェーンのセキュリティと同じで、信頼する必要がなく、トラストレスです。 | +| 自分自身の仮想通貨の管理を諦める必要があります。 | [smart contracts](/glossary/#smart-contract)を通じて、トラストレスブリッジはユーザーが自身の資金を管理し続けられるようにします。 | 一言で言えば、トラストブリッジでは、サードパーティへの「信頼の前提」があると言え、一方のトラストレスブリッジでは、この信頼を最小限にし、基盤となるドメインを超える範囲で、新たに信頼を置く必要がありません。 これらの用語を下記に説明します。 -- **トラストレス**: 基盤となるドメインと同等のセキュリティ。 [Arjun Bhuptaniのこちらの記事で](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17)説明されています。 -- **信頼の前提:** 外部の検証者をシステムに含めることで、基盤となるドメインのセキュリティから離れ、暗号経済的にセキュリティが低下。 +- **トラストレス**: 基盤となるドメインと同等のセキュリティを持つこと。 [こちらの記事でArjun Bhuptani氏が説明しています。](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17) +- **信頼の前提:** システムに外部の検証者を追加することで、基盤となるドメインのセキュリティから離れ、暗号経済学的な安全性を低下させること。 2つのアプローチの重要な違いをもっと理解するために、例を見てみましょう。 @@ -100,17 +100,26 @@ USDTを貸し出すのにイーサリアムムメインネットのAaveを使用 -## ブリッジ利用のリスク {#bridge-risk} +## ブリッジの使用 {#use-bridge} + +ブリッジを使えば、異なるブロックチェーン間で資金を移動させることができます。 ブリッジを探して活用するのに役立つリソースをいくつか紹介します： + +- **[L2BEAT Bridges概要](https://l2beat.com/bridges/summary) & [L2BEAT Bridgesリスク分析](https://l2beat.com/bridges/summary)**: 市場シェア、ブリッジの種類、宛先チェーンなどの詳細を含む、さまざまなブリッジの包括的な概要。 また、リスク分析も実施しており、ユーザーのブリッジ選択を補助します。 +- **[DefiLlamaブリッジ概要](https://defillama.com/bridges/Ethereum)**: Ethereumネットワークにおけるブリッジの取引量の概要。 + + + +## ブリッジを使用するリスク {#bridge-risk} ブリッジは開発の初期段階です。 最適なブリッジの設計はまだ発見されていない可能性があります。 そのため、どの種類のブリッジでもリスクが伴います。 -- **スマートコントラクトのリスク —** 資金を失ってしまう可能性のあるコードのバグ -- **テクノロジーのリスク — **ソフトウェアの障害、コードのバグ、ヒューマンエラー、スパム、悪意のある攻撃による障害 +- **スマートコントラクトのリスク —** コード内のバグによりユーザーの資金が失われる可能性のあるリスク +- **テクノロジーリスク —** ソフトウェアの障害、バグのあるコード、ヒューマンエラー、スパム、悪意のある攻撃がユーザーの操作を妨害する可能性 さらに、トラストブリッジでは「信頼の前提」が必要なため、下記のようなリスクがあります。 -- **検閲のリスク — ** 理論的にはブリッジの運営側が、ユーザーのブリッジを使用した資産の移動を停止可能 -- **資産保管のリスク —** ブリッジ運営側による不正行為と資金の窃取 +- **検閲リスク —** ブリッジの運営者が、理論上、ユーザーがブリッジを使って資産を転送するのを阻止できるリスク +- **カストディリスク —** ブリッジの運営者が共謀してユーザーの資金を盗むリスク 下記の場合は、ユーザーの資金にリスクにさらされます。 @@ -120,14 +129,17 @@ USDTを貸し出すのにイーサリアムムメインネットのAaveを使用 - トラストブリッジで、ブリッジ運営側による悪意的な行動 - ブリッジのハッキング -最近のハッキングされた例として、Solanaのワームホールブリッジで、[120k wETH (3億2500万米ドル)が盗難](https://rekt.news/wormhole-rekt/)の被害に逢いました。 [規模の大きいブロックチェーンのハッキングの多くはブリッジに関連したもの](https://rekt.news/leaderboard/)でした。 +最近のハッキング事例としては、SolanaのWormholeブリッジがあり、[このハッキングで12万wETH（3億2500万米ドル）が盗まれました](https://rekt.news/wormhole-rekt/)。 [ブロックチェーンにおける大規模なハッキングの多く](https://rekt.news/leaderboard/)には、ブリッジが関与していました。 -ブリッジは、イーサリアムのL2を初めて利用するユーザー、またさまざまなエコシステムを探索したいユーザーにとっても重要なものです。 しかし、ブリッジ利用に伴うリスクを考慮し、ブリッジのトレードオフの理解が必要です。 これらは[クロスチェーンセキュリティの戦略](https://blog.debridge.finance/10-strategies-for-cross-chain-security-8ed5f5879946)です。 +ブリッジは、イーサリアムのL2を初めて利用するユーザー、またさまざまなエコシステムを探索したいユーザーにとっても重要なものです。 しかし、ブリッジ利用に伴うリスクを考慮し、ブリッジのトレードオフの理解が必要です。 これらは、[クロスチェーンセキュリティのための戦略](https://debridge.com/learn/blog/10-strategies-for-cross-chain-security/)の一部です。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} + +- [EIP-5164: クロスチェーン実行](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) - _2022年6月18日 - Brendan Asselstine_ +- [L2Bridgeリスクフレームワーク](https://gov.l2beat.com/t/l2bridge-risk-framework/31) - _2022年7月5日 - Bartek Kiepuszewski_ +- ["なぜ未来はマルチチェーンになるが、クロスチェーンにはならないのか"](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) - _2022年1月8日 - Vitalik Buterin_ +- [安全なクロスチェーン相互運用性のための共有セキュリティの活用：Lagrange State Committeesとその先へ](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - _2024年6月12日 - Emmanuel Awosika_ +- [ロールアップ相互運用性ソリューションの現状](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - _2024年6月20日 - Alex Hook_ -- [EIP-5164: クロスチェーンの実行](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) _2022年6月18日 - Brendan Asselstine_ -- [L2ブリッジ・リスク・フレームワーク](https://gov.l2beat.com/t/l2bridge-risk-framework/31) _2022年7月5日 - Bartek Kiepuszewski_ -- [「未来はマルチチェーンになるが、クロスチェーンにはならない理由」](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) _2022年1月8日 - Vitalik Buterin_ diff --git a/public/content/translations/ja/community/code-of-conduct/index.md b/public/content/translations/ja/community/code-of-conduct/index.md index 0f466f26a8d..a9322f46863 100644 --- a/public/content/translations/ja/community/code-of-conduct/index.md +++ b/public/content/translations/ja/community/code-of-conduct/index.md @@ -1,6 +1,6 @@ --- -title: 行動規範 -description: ethereum.orgにおいて目指す基本原則 +title: "行動規範" +description: "ethereum.orgの各スペースで私たちが目指す基本基準。" lang: ja --- @@ -8,70 +8,70 @@ lang: ja ## ミッション {#mission} -最も包括的で利用しやすいイーサリアムの知識ハブを作り維持する +イーサリアムのための最も包括的で、アクセスしやすいナレッジハブを開発し、維持すること。 -## バリュー {#values} +## 価値観 {#values} -ethereum.orgコミュニティは以下のことを追求します： +ethereum.orgコミュニティは以下を目指します: -- 教育的ですべての人がイーサリアムを理解できるようにすること +- 教育的であり、すべての人がイーサリアムを理解できるようにすること - 包括的であること -- 利用しやすいこと -- コミュニティドリブンであること -- イーサリアムの根底にある技術やユースケースに集中すること -- イーサリアムのコンセプトやデザイン原則に集中すること +- アクセスしやすいこと +- コミュニティ主導であること +- イーサリアムの基盤技術とユースケースに焦点を当てること +- イーサリアムの概念と設計原則に焦点を当てること -## ethereum.orgは以下ではありません： {#what-we-are-not} +## 私たちが目指さないこと {#what-we-are-not} -- イーサリアム・ファウンデーションのウェブサイト -- 特定の者への投資を促進したり利益を供与するようなプラットフォーム -- 個々のプロジェクトや組織を推奨または支持するためのプラットフォーム -- DEXやCEXなどの金融プラットフォーム -- 金融または法的なアドバイスなどを提供するプラットフォーム +- イーサリアム財団のウェブサイト +- いかなる種類の投資や利益追求も促進するためのプラットフォーム +- 個別のプロジェクトや組織を称賛または支持するためのプラットフォーム +- DEXやCEX、その他の金融プラットフォーム +- いかなる種類の金融または法的なアドバイスも提供するプラットフォーム ## 行動規範 {#code-of-conduct} ### 誓約 {#pledge} -オープンな参加が、ethereum.orgのコアとなる行動規範です。 私たちは、数千ものコントリビュータによって維持されているウェブサイトとコミュニティです。常に他者を歓迎し、参加型の環境であるからこそ維持することができます。 これを達成するには、このサイトのコントリビュータは、すべてのethereum.orgプラットフォームおよびコミュニティスペースのすべての参加者に対してハラスメントのない環境を維持することを誓約します。 ethereum.orgコミュニティは、建設的で友好的なマナーで参加したい人を歓迎し、尊重します。年齢、障害、民族、性的特徴、性同一性、経験レベル、専門分野、教育、社会経済的地位、国籍、外見、人種、宗教、その他の多様性の側面で区別しません。 +オープンな参加は、ethereum.orgの精神の中核をなすものです。 私たちは数千人のコントリビューターによって維持されているウェブサイトとコミュニティであり、これは私たちが歓迎的で参加しやすい環境を維持することによってのみ可能です。 この目的のために、このサイトのコントリビューターは、すべてのethereum.orgプラットフォームとコミュニティスペースにおいて、すべての参加者のためにハラスメントのない環境を維持することを誓約します。 ethereum.orgコミュニティは、年齢、障害、民族、性的特徴、性自認、経験レベル、専門分野、学歴、社会経済的地位、国籍、個人の外見、人種、宗教、その他あらゆる多様性に関係なく、建設的かつ友好的な方法で参加したい人を誰でも歓迎し、尊重します。 ### 適用範囲 {#scope} -この行動規範は、すべてのethereum.orgスペース (GitHub、Discord、Figma、Crowdin、Twitter、その他のオンラインプラットフォーム) に適用されます。また、ミートアップ、カンファレンス、イベントなど、現実世界の公共スペースでコミュニティを開催する場合にも当てはまります。 +この行動規範は、すべてのethereum.orgスペース (GitHub、Discord、Figma、Crowdin、X(旧Twitter)、その他のオンラインプラットフォームなど) に適用されます。また、ミートアップ、カンファレンス、イベントなどの現実世界の公共スペースでコミュニティを代表する場合にも適用されます。 ### 私たちの基準 {#our-standards} -前向きな環境の推進に貢献する振る舞いの例を示します： +ポジティブな環境づくりに貢献する行動の例は以下の通りです: -- 友好的で差別的な表現がない言葉を使用する -- 異なる視点や経験を尊重する -- 礼儀正しく受け入れたり、共感をもって建設的な批判をする -- 対立や意見の相違を解決する場合は、冷静かつ専門的なマナーをもって行動する -- 他のコミュニティメンバーに対して共感と寛容を示す -- コミュニティ内の新しい考えを奨励し、広める +- 歓迎的で包括的な言葉遣い +- 異なる視点や経験を尊重すること +- 建設的な批判を素直に受け入れたり、あるいは共感を持って提供したりすること +- 対立や意見の相違を解決する際に、冷静かつプロフェッショナルに行動すること +- 他のコミュニティメンバーに対して共感と寛容を示すこと +- コミュニティの新しい声を奨励し、広めること -容認できない参加者の行為の例を示します： +参加者による許容されない行動の例は以下の通りです: -- 身体的暴力、あらゆる種類の身体的暴力の奨励または身体的暴力を加える脅迫 -- 性的な言葉や画像を使用したり、望まない性的関心を強いること -- 他の個人になりすましたり、何らかの個人または組織との関係を不正に主張すること -- いわゆる荒らし行為、侮辱／軽蔑的なコメント、および個人攻撃、または政治的攻撃 -- パブリックまたはプライベートチャンネルのコミュニティメンバーに対して嫌がらせ行為をする -- 物理的または電子的なアドレスなどといった他人の個人情報を明示的な許可なく公開する -- ソーシャルエンジニアリング、詐欺、その他のコミュニティメンバーを操作する -- 投資、トークン、プロジェクト、個人の金銭的または非金銭的な利益を促進すること -- トピックから外れたサーバーにスパムを送信すること -- コミュニティモデレータからのリクエストや警告を無視すること -- 仕事場において、合理的に考えて不適切と見なされるような、その他の行為に携わること +- 身体的暴力、身体的暴力の脅迫、またはいかなる種類の身体的暴力の助長 +- 性的な言葉や画像の使用、または歓迎されない性的な関心を強要すること +- 他人になりすましたり、個人や組織との提携を不正に主張したりすること +- 荒らし行為、侮辱的・軽蔑的なコメント、個人攻撃や政治的攻撃 +- パブリックまたはプライベートなチャンネルで、他のコミュニティメンバーに嫌がらせをすること +- 物理的な住所や電子的なアドレスなど、他人の個人情報を明示的な許可なく公開すること +- ソーシャルエンジニアリング、詐欺、またはその他の方法で他のコミュニティメンバーを操作すること +- 個人的な金銭的・非金銭的利益のために、投資、トークン、プロジェクトなどを宣伝すること +- サーバーでトピックに関係のないコンテンツをスパム投稿すること +- コミュニティモデレーターからの要請や警告を無視すること +- プロフェッショナルな場において不適切と合理的にみなされる可能性のある、その他の行為を行うこと -### 通報 {#reporting} +### 報告 {#reporting} -私たちはオープンな公開チャンネルですべてを行うことを努めています。そのため、行動規範への違反行為は、通常コミュニティの眼に触れることになり、コミュニティメンバーが自警できるようにしています。 +私たちはオープンな公開チャンネルですべてを行うよう努めているため、行動規範への違反は通常コミュニティの目に触れることになり、コミュニティメンバーが自警できるようになります。 -しかし、注意が必要なことが起こった場合、調整の役割りを持つ人 (例: discordガイド) に報告し、調査と適切な対応を支援を受けることができます。 +しかし、注意が必要と思われる事態が発生した場合は、モデレーションの役割を持つ人 (例: Discordガイド) に報告してください。そうすれば、その人が調査と適切な対応の実施を手伝ってくれます。 -報告する際は、具体的な例やタイムスタンプなど、できるだけ詳細を含めてください。 この情報は、公正な結果を保証するのに役立てることができます。 +報告の際には、具体的な例やタイムスタンプなど、できるだけ詳細な情報を含めてください。 これは公正な結果を保証するのに役立ちます。 -### 施行 {#enforcement} +### 執行 {#enforcement} -深刻さに応じて、行動規範の違反をする人々は、警告、一時的なアカウント停止、永続的なアカウントの停止の処置をethereum.orgコミュニティから受けます。 +深刻度に応じて、行動規範に違反した人は、ethereum.orgコミュニティから警告、一時的な追放、または永久追放を受けることがあります。 diff --git a/public/content/translations/ja/community/events/organizing/index.md b/public/content/translations/ja/community/events/organizing/index.md new file mode 100644 index 00000000000..e4e94a2931a --- /dev/null +++ b/public/content/translations/ja/community/events/organizing/index.md @@ -0,0 +1,221 @@ +--- +title: "イーサリアムイベントの開催" +description: "イーサリアムイベントの開催方法" +lang: ja +hideEditButton: true +--- + +# イーサリアムイベントの開催方法 {#how-to-organize-an-ethereum-event} + +強固で活気のあるコミュニティを構築することは、イーサリアムエコシステムを成長させる上で中心的な役割を果たします。 ミートアップ、ワークショップ、または本格的なカンファレンスの開催を計画しているかどうかにかかわらず、イベントの成功はローカルネットワーク内のつながりとエンゲージメントにかかっています。 このガイドは、活発なイーサリアムコミュニティの基盤を築き、記憶に残り、影響力のあるカンファレンスを開催するプロセスを段階的に説明します。 + +## 自問してみましょう、イーサリアムコミュニティは存在しますか？ {#ask-yourself-is-there-an-ethereum-community} + +成功するイーサリアムカンファレンスは、活発で熱心なコミュニティの上に成り立っています。 もし既にコミュニティがあるなら、あなたは有利な立場にいます。しかし、もしなければ、その基盤を築くことが不可欠な準備段階となります。 シーンとコミュニティを区別することが重要です。シーンには、特定の地域に存在する企業や個人が含まれるかもしれませんが、彼らはしばしば独立して活動し、時折共同のイニシアチブを取るだけです。これは多くの場所における従来のweb2エコシステムのようなものです。 一方、コミュニティとは、相互につながった人々や組織が協力し合い、支え合うネットワークであり、これはweb3エコシステムでよく見られます。 + +**最初のステップは次のとおりです:** + +- 地元のスタートアップや企業を探しましょう。あなたの都市や国に強力で活発な企業が存在することは、コミュニティを構築するための最も重要な前提条件であることが多いです。 +- すでにいくつかのミートアップがあるかどうかを確認してください — ethereum.orgの[イベントページ](https://ethereum.org/community/events/) +- [ethereum.orgのウェブサイト](https://ethereum.org/community/events/)およびethereum.orgのDiscordで、地元のイーサリアムイベント、デベロッパー、コントリビューターがいるかどうかを確認します。 +- LumaおよびMeetup.comで、お住まいの地域でイーサリアム関連のイベントやより広範なweb3イベントが開催されているかどうかを確認します。 +- X — この分野で地元の支持者やインフルエンサーを見つけてみてください。 + +これらの要素のほとんどが見つかった場合、それはコミュニティを構築する条件が存在することの強力な兆候ですが、必ずしもコミュニティがすでに存在しているわけではありません。 次のステップは、これらの関係者を組織し、関与させ、育成するという重要な作業であり、協力と長期的な成長のための機会を創出します。 + +### ない場合は、どうやって構築するか {#if-not-how-to-build-it} + +これらの要素の多くが欠けていることに気づいても、心配しないでください。コミュニティをゼロから構築することは、困難ですが非常にやりがいのあるプロセスです。 強力なイーサリアムコミュニティは一夜にして現れるものではありません。忍耐力、一貫性、そして明確なビジョンが必要です。 始める方法は次のとおりです。 + +- **コミュニケーションチャネルを設定する** — Telegram、Signal、WhatsApp、WeChat、Discordサーバーなど、お住まいの地域でより人気のあるものを利用して、人々がつながり、質問し、リソースを共有できるようにします。 +- **アーリーアダプターを見つける。**イーサリアムとWeb3に情熱を持つ数人を見つけましょう。 彼らはあなたの中核となる支持者であり、協力者となるでしょう。 +- **小規模で一貫性のあるイベントを主催する。**非公式なミートアップ、勉強会、ワークショップから始めましょう。 一貫性が鍵です — 最初はグループが小さくても、定期的なイベントは信頼と勢いを築きます。 +- **地元の企業**、教育機関、コワーキングスペースに連絡して、無料でスペースを提供してもらえないか試してみてください。 自国からスピーカーが見つからない場合は、オンラインでスピーカーを招待し、人々を物理的に集めましょう。 聴衆を物理的に1か所に集めておくことが重要です。 +- **既存の技術コミュニティと協力する。**すでにデベロッパーグループ、スタートアップエコシステム、またはブロックチェーンミートアップが確立されている場合は、彼らと提携してイーサリアムのトピックを紹介し、リーチを拡大しましょう。 +- イーサリアムの可能性に関する**教育コンテンツを共有する**。 +- **グローバルコミュニティに連絡を取る。**世界中の確立されたイーサリアムグループやプロジェクトとつながり、サポート、メンターシップ、潜在的な協力を求めましょう。 世界中のイーサリアムコミュニティには、少なくとも1つの共通点があります。それは、誰もが喜んで手助けをしてくれるということです。 +- 地元のweb3企業から、または[ESP](https://esp.ethereum.foundation/)などの助成金プログラムを通じて、**資金を確保**してみてください。 + +### ある場合は、どのように維持し、成長させるか {#if-yes-how-to-maintain-and-grow-it} + +確立されたコミュニティができても、作業は終わりません。実際には、それはまだ始まったばかりです。 コミュニティを活発に保ち、関与させ、成長させるには、継続的な努力と創造性が必要です。 コミュニティの関与を維持するための重要な要素の1つは、新しいフォーマットやアイデアを常に試すことです。 + +活気のあるイーサリアムコミュニティを維持するための戦略をいくつか紹介します。 + +- **イベントの形式を多様化する:** 1つのタイプの集まりに固執しないでください。 ミートアップ、短期ハッカソン、パネルディスカッション、ネットワーキングイベントなどを組み合わせて、変化をつけましょう。 コワーキングデーや教育コースを企画することもできます。 +- **トピックを多様化する:** イーサリアムは単なるテクノロジーではありません。法律、マーケティング、ビジネスを含む一連の価値観でもあります。 +- フィードバックやアイデアを**コミュニティに求める**。 +- **異なるオーディエンス**セグメントと関わる。 初めてイーサリアムを探求する初心者から、経験豊富なデベロッパーや起業家まで、さまざまな経験レベルに合わせてコンテンツやイベントを調整します。 + +学習、協力、成長のための多様な機会を提供することで、コミュニティが活発に活動し続け、カンファレンスの開催のようなより大きな取り組みに備えることができます。 + +## イベント {#event} + +### イベントを開催するのに最適な時期はいつですか？ {#when-is-the-right-time-to-organize-an-event} + +成功するイーサリアムカンファレンスやコミュニティイベントを企画するには、慎重なタイミングと検討が必要です。 適切なタイミングは、イベント全体の成功に寄与するさまざまな要因によって決まります。 + +コミュニティの成熟度、市況、チームの有無、地元のシーン(潜在的なスポンサーなど)の有無を考慮する必要があります。 + +### KYC — コミュニティを知る {#kyc-know-your-community} + +イベントを企画する上で最も重要なステップの1つは、コミュニティを理解することです。 金融サービスのKnow Your Customer (KYC)と同様に、Know Your Community (KYC)は、時間をかけて地元のオーディエンスの特定のニーズ、好み、特性を理解することを意味します。 この理解は、カンファレンスを調整してその成功と関連性を確保するのに役立ちます。 + +すぐに大規模なイベントを目指したくなりますが、多くの場合、小規模から始めるのが最善のアプローチです。 コミュニティの状態や、一見無関係に見えるかもしれない他の側面(例えば、あなたの国が人気の観光地であるか、宿泊費など)を客観的に見れば、あなたにとって最善の解決策がわかるでしょう。 + +初年度は、オーディエンスの大部分が地元のコミュニティになるため、より大きなイベントを企画する初年度に行うすべてのことは、そのコミュニティのニーズと規模に対応するものであるべきです。 + +### どこから始めるか {#where-to-start} + +カンファレンスを企画するとなると、最初のステップは圧倒されるように感じることがあります。 しかし、明確な計画と構造があれば、プロセスを管理可能なタスクに分解できます。 それぞれを分解していきます。 + +構造化されたアプローチから始めることで、イベントを企画するさまざまな段階を進むにつれて、整理された状態を保ち、ストレスを軽減するのに役立ちます。 あなたが下す各決定は、コミュニティのニーズを満たす体験を提供するという目標にあなたを近づけるはずです。 + +**最初にすべきことは、明確な役割と責任を持つ組織チームを構築することです。** + +プログラムの構築やスポンサーへの連絡を始める前のもう1つの重要なステップは、日程を決めることです。 それは簡単なステップのように聞こえますが、事前に考慮すべきいくつかの重要な要素があります。 そのうちのいくつかを以下に示します。 + +- **主要なカンファレンス**やイベントとの日程の重複を避ける +- **地域の状況や事情を考慮する** (季節、主要な祝日など) +- **市況を考慮に入れる** +- **すべてを整理するのに十分な時間を自分に与える** — 少なくとも9か月 + +### チームの編成方法 {#how-to-assemble-a-team} + +あなたのビジョンを共有し、あなたのスキルを補完する人々を選びましょう。 集団として機能するチームもあれば、役割が定義されているチームもあります。あなたに最適なものを見つけてください。 定期的なコミュニケーションと明確な期待が不可欠です。 イベントの計画にコミュニケーションプラットフォームに頼りたくなりますが、やるべきことを整理し、追跡するためにタスク管理プラットフォーム(Notion、Basecamp、Trello、Asana、あるいは古き良きGoogleスプレッドシートなど)を選ぶことをお勧めします。 うまく機能し、よく組織されたチームを持つことが重要です。 + +さまざまなイーサリアム主催者チームは、チーム内で異なる役割を担っていますが、ロジスティクス、予算編成、マーケティング、プログラム、デザイン、パートナーシップに取り組む人々が共通しています。 + +### プログラム: 成功するイベントの重要な要素 {#the-program-a-key-element-of-a-successful-event} + +本当に価値があり、記憶に残るカンファレンスを企画するとなると、**プログラムがすべてです**。 これは妥協できる分野ではありません。 スポンサーは重要であり、イベントの資金調達にとってしばしば不可欠ですが、オーディエンスの体験と彼らが受け取る価値は常に優先されなければなりません。 宣伝コンテンツや際限のないスポンサーの売り込みで過負荷になったプログラムは、参加者を遠ざけ、イベントの信頼性を損ないます。 + +すべてのセッション、パネル、ワークショップは、コミュニティに情報を提供し、インスピレーションを与え、関与させるものであるべきです。 オーディエンスの声に耳を傾けましょう。彼らの興味、ニーズ、課題を理解してください。 どのトピックが彼らの心に響きますか？ 同時に、新鮮な視点と革新的な形式を導入して、プログラムをダイナミックに保ちましょう。 おなじみの話題やトレンドのトピックと最先端のアイデアをバランスよく組み合わせ、技術的な深掘りやコミュニティ構築セッションから、ポリシーに関する議論や実践的なワークショップまで、イーサリアムエコシステムのさまざまな側面を網羅する、バランスの取れた議題を確保します。 さらに、カンファレンスの言語も考慮しましょう。ほとんどのイーサリアムイベントでは英語がデフォルトですが、現地の言語でセッションを提供することで、地域のデベロッパーや愛好家にとってイベントがよりアクセスしやすくなります。 + +**スピーカーを選ぶ際は、カンファレンスの少なくとも6か月前に公募を開始し、質の高い応募を集め、議題のキュレーションに十分な時間を確保しましょう。**スピーカーの選定を担当する人は、業界でかなりの経験を持ち、エコシステムを深く理解している必要があります。 これにより、彼らが価値のある洞察に満ちた貢献を特定し、高いコンテンツ水準を維持できることが保証されます。 + +### 資金援助の見つけ方 {#where-to-find-financial-support} + +高品質なカンファレンスを開催するには、会場のレンタル料、販促物、飲食物、制作費、その他数え切れないほどの費用など、多額のコストがかかります。 早い段階で資金援助を確保することは、イベントが専門的な基準を満たし、参加者に素晴らしい体験を提供するために不可欠です。 + +#### スポンサーシップ資料の作成方法は？ {#how-to-create-a-sponsorship-deck} + +まず、資料が必要になります。 **他のカンファレンス主催者にアドバイスを求め**、可能であれば彼らの資料を共有してもらい、それに基づいてパッケージを作成しましょう。 パッケージの価格設定に関しては現実的であるべきで、特に最初は、お金を稼ぐのではなく、費用をカバーすることを目指すべきです。 + +**すべてのスポンサーシップ資料は、イベントの明確で説得力のある概要を提供**し、潜在的なスポンサーがその範囲、焦点、価値を理解できるようにする必要があります。 信頼性を確立するために、会場、日程、組織チームの詳細といった基本から始めましょう。 次に、イベントの主な焦点を強調します。なぜなら、イーサリアムのカンファレンスはそれぞれ異なるオーディエンスを対象としているからです。 中には、深い技術的な議論を特徴とする、ビルダー志向の強いものもあれば、DeFi、DAO、またはポリシートピックに重点を置くものもあります。 + +イベントを説明するだけでなく、明確な期待値を設定しましょう。 **予想される参加者数と、すでに確定している主要なスピーカーを概説**してください。これは、スポンサーが潜在的なリーチを測るのに役立ちます。 最も重要なことは、スポンサーシップの見返りとして何を受け取るかを明確に定義することです。ブーススペース、講演機会、ソーシャルメディアでのプロモーション、ブランドの可視性、または独占的なネットワーキングアクセスなどです。 よく構成された資料は、情報を提供するだけでなく、潜在的なスポンサーにあなたのイベントの一部になる機会について興奮させます。 + +#### 誰があなたのイベントをサポートしてくれるでしょうか？ {#who-might-support-your-event} + +まず、あなたの都市や国にあるイーサリアムおよびより広範な技術エコシステム内の企業に連絡を取ることから始めましょう。 これらの**組織は、コミュニティの成長とイノベーションを促進する地域のイベントを支援することに既得権益を持っていることが多い**です。 彼らはまた、地元のエコシステムに投資する価値を認識し、あなたのカンファレンスを才能、パートナー、ユーザーとつながる機会と見なす可能性が高いです。 + +地元のサポートを活用したら、web3分野のグローバルなプレイヤーにまで活動範囲を広げましょう。 **確立されたプロトコル、DAO、エコシステムファンドは、コミュニティ主導のイベントのために予算を割り当てることが多い**です。 これは、実績がまだない初めての主催者にとっては少し難しいかもしれませんが、ブランドの認知度、講演の機会、ターゲットオーディエンスとの有意義なエンゲージメントなど、イベントを支援するメリットを明確に概説した魅力的なスポンサーシップパッケージを作成してみてください。 他の人が持っていないかもしれない、あなた独自の価値を見つけるようにしてください。 + +#### イベント資金調達の代替手段 {#alternative-forms-of-funding-your-event} + +助成金は、多くの主催者が見落としがちなもう一つの潜在的な資金源です。 Ethereum Foundationの[エコシステムサポートプログラム](https://esp.ethereum.foundation/) (ESP)や[その他の助成金イニシアチブ](https://ethereum.org/community/grants/#ethereum-grants)のようなプログラムは、コミュニティ主導のイベントを支援するために存在します。 + +金銭的なスポンサーシップ以外に、特に飲食物については現物支給のパートナーシップを検討してください。 地元の文化や技術コミュニティに合致するブランドは、あなたのイベントにとって素晴らしいパートナーとなり得ます。 コーヒーブランド、飲料会社、あるいは地元のピザ屋でさえ、イベントでの知名度と引き換えに製品を提供してくれるかもしれません。 これらの協力は、コストを削減しつつ、参加者の体験を向上させるのに役立ちます。 + +財務について話しているので、これを覚えておいてください。卓越した参加者体験を創造するために投資する1ドルごとに、指数関数的に報われるでしょう。 質の高いプロダクション、快適な会場、心のこもった記念品、そしてよく組織されたサイドイベントは、カンファレンスが終わった後も長く参加者が語り継ぐような、記憶に残る体験に貢献します。 満足した参加者はあなたの最大の支持者となり、イベントの長期的な成功を確実にします。 + +### ロジスティクス {#logistics} + +資金確保と並行して、主な焦点はロジスティクスにあるべきです。 よく組織されたカンファレンスには、会場の設営から参加者の体験まで、複数の分野にわたる綿密な計画が必要です。 イベント運営の確かな経験を持つ人がいると、大きな違いが生まれます。必ずしもweb3イベントである必要はなく、一般的なイベントの経験で十分です。 経験豊富なロジスティクスリーダーは、潜在的な問題を予見し、それが問題になる前に解決することで、時間、費用、ストレスを節約できます。 + +ロジスティクス担当者は、会場、制作会社、飲食物やグッズのさまざまなベンダーを選ぶべきです。また、参加者が暗号通貨で登録・支払いできる使いやすいオンラインチケットシステムも選ぶべきです。 + +### ロケーションインフラ {#location-infrastructure} + +カンファレンスの場所を選ぶ際には、会場そのものを超えて、より広範な都市や国のインフラを考慮することが重要です。 天候、移動のしやすさ、安全性、政治環境などの要因は、参加者の体験を形作る上で大きな役割を果たします。 + +あまり知られていない場所では、これが特に重要になります。 世界中からの参加者やスポンサーは、簡単かつ安全に旅行できると確信できる必要があります。 空港へのアクセス、公共交通機関、宿泊施設の選択肢などの側面を調べてください。 また、ビザポリシーなど、国際的な参加者を妨げる可能性のある複雑な事態を避けるために、その地域の文化的・政治的状況を考慮することも賢明です。 + +### イベントの宣伝方法 {#how-to-promote-the-event} + +イベントを効果的に宣伝することは、適切なオーディエンスを引きつけ、興奮を醸成するための鍵です。 よく練られたプロモーション戦略は、あなたのカンファレンスがそれにふさわしい可視性とエンゲージメントを得ることを保証します。 デザインもブランドにとって重要な役割を果たすので、そのための予算も必ず確保すべきです。 + +#### ソーシャルメディア {#social-media} + +X.comはあなたのソーシャルメディアプロモーションのバックボーンとなるでしょう。 そこでの投稿に積極的かつ一貫性を持つように努めるだけでなく、個人アカウントと組織のアカウントの両方で、さまざまな会話に参加してください。 + +LinkedInはプロモーションの最も明白な選択肢には聞こえないかもしれませんが、そこでは全く異なるオーディエンス、あるいは一部のスポンサーにさえリーチできます。 + +#### 他のイーサリアムコミュニティとのパートナーシップ {#partnerships-with-other-ethereum-communities} + +さまざまなイーサリアムの主催者とのパートナーシップは、既存のネットワークを活用することで、特にゼロから始める場合にリーチを拡大するのに役立ちます。 コミュニティ割引を提供し、他のイベントと相互に宣伝し、パートナーをサイドイベントやワークショップの共同主催に招待しましょう。 + +#### 大学へのアプローチ {#university-outreach} + +イベントを宣伝するために、学生クラブや教授を通じて、町の技術系および経済学系の学部に連絡を取りましょう。 大学と関わることは、若い才能、研究者、将来の業界専門家を引きつけ、学界とイーサリアムエコシステムの間のより強い結びつきを育むのに役立ちます。 これは、ハッカソンを企画する場合に特に素晴らしいです。なぜなら、学生はしばしば新鮮なアイデア、熱意、そして強力な技術的基盤をもたらすからです。 + +#### メディア {#media} + +イベントの報道を依頼するために、web3に焦点を当てたメディアやニュースレターに連絡を取りましょう。 Web3メディアはPR記事に対して報酬を期待しますが、有料プロモーションの予算がない場合は、無料チケットや著名なスピーカーやスポンサーとのインタビューを提供することができます。 プレスリリースと、ソーシャルメディアやウェブサイトでさまざまな形式で宣伝できるビジュアルを含むPRパッケージを作成しましょう。 また、地元のジャーナリストや、(評判が良い限り)コンテンツクリエイターにまで範囲を広げてテクノロジーを取材してもらうことも、イベントをより多くの聴衆に紹介するために重要です。 これは、暗号通貨業界と一般大衆との間のギャップを埋め、主流の技術およびビジネスコミュニティからの関心を引きつけるのに役立ちます。 + +### ハッカソンも開催すべきでしょうか？ {#should-you-organize-a-hackathon-as-well} + +ハッカソンは、デベロッパーコミュニティを巻き込み、イノベーションを促進する素晴らしい方法であるため、ハッカソンの開催は有益です。 また、プロジェクトで協力し、構築する実践的な機会も提供し、エコシステムにとって具体的な成果につながる可能性があります。 ハッカソンは、普段はカンファレンスに参加しないかもしれないが、新しいアイデアを構築しテストするという挑戦に熱心なデベロッパーを引きつけます。 あなたのカンファレンスがデベロッパー、イノベーション、実践的なプロジェクトを対象としている場合、ハッカソンを主催するのは自然な流れです。 + +しかし、開催する前に、十分なリソースと時間があるかどうかを検討してください。 **ハッカソンには、時間、労働力、資金投資の面で多大なリソースが必要です**。 特にカンファレンスも管理している場合は、それを担当する専任チームがいることを確認してください。 また、あなたのコミュニティに関心があるかどうかも確認してください。 あなたのコミュニティがよりビルダー志向であれば、それを開催するのは理にかなっているでしょう。 + +開催には多くの利点がありますが、カンファレンスの規模によっては、ハッカソンを追加することが圧倒的になる可能性があることを考慮に入れてください。 両方を管理することで、どちらかの質が低下するかどうかを評価する必要があります。 より小規模で焦点を絞ったハッカソンを選ぶか、イベントを数か月にわたってずらして開催することもできます。 + +### (ほぼ避けられない)直面する課題 {#almost-inevitable-challenges-that-you-will-face} + +カンファレンスを企画する際の最大の課題の1つは、特にイーサリアム分野において、十分な資金を確保することです。 **多くのイベント主催者は、会場費**、ケータリング、その他の物流費を賄うために必要な資金を調達するのに苦労しています。 スポンサーシップはしばしば不可欠ですが、関係を築き、企業にイベントへの投資を説得するには時間がかかることがあります。 さらに、市場の低迷期には、企業が非中核的な活動への投資に消極的になる可能性があるため、スポンサーを引きつけるのが難しくなることがあります。 + +予算を効果的に管理することが鍵です。 直前の会場変更や追加のイベント技術要件など、**予期せぬ出費**がすぐに予算をオーバーさせてしまうことがあります。 + +新しいイベントでは、**質の高いスピーカーを確保することが特に難しい**場合があります。 イーサリアム分野で確立された思想的リーダーやインフルエンサーは、すでにスケジュールが埋まっており、実績のない新しいイベントへの参加をためらうかもしれません。 イベントのずっと前から、ネットワーキングや潜在的なスピーカーへの連絡に時間を費やす準備をしておきましょう。 + +また、スピーカーに関しては、明確で絶え間ないコミュニケーションを取り、プレゼンテーションの提出期限を設定し、直前の変更を避けるようにしましょう。 + +成功するカンファレンスには、ロジスティクス、マーケティング、スポンサーシップ、技術サポート、参加者管理を処理できる専任チームが必要です。 技術イベントの企画経験を持つ個人を見つけることは、特に小規模な予算で作業している場合や、ほとんどの場合、予算がなくボランティアベースで作業している場合には、困難な場合があります。 + +### 一人でやるべきではありません。 ボランティアが必要です。 {#you-shouldnt-do-it-alone-you-need-volunteers} + +イーサリアムイベントを企画するには、ロジスティクス、登録、スピーカーの調整、参加者サポートなど、さまざまな業務を処理するための多様で献身的なチームが必要です。 チームの規模がわずか3人から15人の範囲であることを考えると、イベントの円滑な運営にはボランティアが不可欠であることが明らかになります。 + +ボランティアは多くのカンファレンスの屋台骨であり、特に限られた予算で作業している場合に重要なサポートを提供します。 彼らは受付デスクの担当からイベントの設営支援まであらゆることをこなし、イベントが可能な限りスムーズに進行するようにします。 + +ボランティアに金銭的な報酬を提供することは難しいですが、彼らの経験を価値あるものにするために、何か価値のあるものを提供することが不可欠です。 ネットワーキングの機会、スキル開発、いくつかの限定的な特典、証明書や推薦状を提供することを検討してください。 + +### イベント主催者のためのコンプライアンスの要点 {#compliance-essentials-for-event-organizers} + +イベントを企画する際には、留意すべきいくつかの重要な法的および物流上の考慮事項があります。 + +- **スポンサーシップ契約** – スポンサーとの明確な契約書を用意し、明確に定義されたキャンセルポリシーを含めるようにしてください。 +- **行動規範** – 特定のイベントタイプ(カンファレンス/ハッカソン、ハッカーハウスなど)に合わせた行動規範を準備します。 +- **プライバシーポリシー** – データ保護規制と画像に関する規制に準拠するため、ウェブサイトのプライバシーポリシーを作成します +- **地方自治体への届出** – イベントが非公開の集まりであっても、地元の警察署に届け出ることが望ましいです。 +- **チケット販売契約** – チケット販売サービスプロバイダーとの正式な契約を確立し、条件と責任を明確にします。 +- **規制遵守** – カンファレンスを主催する国に、暗号通貨業界に対する特定の規制や制限があるかどうかを事前に確認してください +- **商品の通関** – スポンサーの商品を輸入する場合は、税関代理店を雇って手続きを効率的に処理することをお勧めします。 +- **写真およびメディアポリシー** – 写真撮影およびメディア報道に関するガイドラインを明確に定義し、参加者が同意およびオプトアウトの選択肢について知らされていることを確認します。 + +## イベント後: 次は何をすべきか？ {#after-the-event-whats-next} + +イベント終了後、参加者、スピーカー、スポンサーからフィードバックを収集し、内部報告書を作成して、将来のイベントにより良く備えることが重要です。 これにより、何がうまくいったか、どこを改善できるかを特定するのに役立ちます。 アンケートや1対1のインタビューを利用して、将来の反復を導く貴重な洞察を収集します。 次のカンファレンスで避けることができるため、間違いや非効率な領域を見直す時間を取ってください。これにより、プロセスがよりスムーズになります。 + +重要なのは、勢いを維持し続けることです。 コミュニティとの関わりを続け、彼らのフィードバックに基づいて進捗状況に関する最新情報を共有し、次のイベントへの期待感を高めましょう。 このつながりを維持することで、カンファレンスの影響がイベント自体を超えて広がり、関係を強化し、将来の成功への舞台を整えることができます。 + +## 謝辞 {#acknowledgement} + +この記事に洞察を共有して貢献してくださった皆様に心から感謝申し上げます。ETHBratislavaのSlavo Fabisik氏、ETH KipuおよびETH LatamのLola氏、ETH BelgradeのTanja Mladenovic氏、Ethereum BogotaのJuan David氏、ETHWarsawのMonika Zając氏、NapulETHのRaffaele Orefice氏、ETH RiyadhのXiao Wu(Ling)氏、urbe.ethのMarco氏、ETH DublinのCaolán Walsh氏、ETHClujのAlex Males氏、そしてETH SloveniaのStanko Devic氏。 + +## 参考リソース {#resources} + +ポッドキャスト: ETHイベントをAからZまで企画し、宣伝する方法: + +- [Out of OrdinaryによるETHWarsawのケーススタディ](https://www.youtube.com/watch?v=io2Dx1ouz8o) + +Twitterスペース: + +- [ETHコミュニティAMA](https://x.com/NapulETH/status/1905732699094151623) + +記事: + +- [Danny H.によるETHKLの構築](https://sekto.tech/ethkl24) +- [POKTイベントプレイブック](https://docs.pokt.network/community/pokt-events-playbook) diff --git a/public/content/translations/ja/community/get-involved/index.md b/public/content/translations/ja/community/get-involved/index.md index a293d186789..d1c1706dd61 100644 --- a/public/content/translations/ja/community/get-involved/index.md +++ b/public/content/translations/ja/community/get-involved/index.md @@ -1,6 +1,6 @@ --- -title: 参加方法 -description: イーサリアムコミュニティへの参加方法 +title: "参加方法" +description: "イーサリアムコミュニティへの参加方法" lang: ja --- @@ -10,123 +10,123 @@ lang: ja まずは、[行動規範](/community/code-of-conduct)に記載されているethereum.orgのミッションとバリューについて読むことから始めましょう。 -## デベロッパー {#developers} +## デベロッパー ‍ {#developers} -- [ethereum.org/developers/](/developers/) - イーサリアムについての学習 -- [ETHGlobal](http://ethglobal.co/) - お近くのETHGlobalハッカソンへの参加 -- [自分の専門分野や好きなプログラミング言語に関連するプロジェクト](/developers/docs/programming-languages/)の確認 -- [コンセンサスおよび実行レイヤーのコール](https://www.youtube.com/@EthereumProtocol/streams)の視聴、もしくは参加 -- [エコシステム・サポート・プログラムのウィッシュリスト](https://esp.ethereum.foundation/wishlist/) - イーサリアムのエコシステム・サポート・プログラムが助成金の申請を募集しているツール、ドキュメント、インフラストラクチャ分野 -- [Web3Bridge](https://www.web3bridge.com/) - アフリカ全土の何百人ものデベロッパーやコミュニティメンバーを特定し、トレーニングし、サポートする、意欲的なWeb3コミュニティの取り組み -- [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)への参加 -- [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu)に加わりましょう。 +- [ethereum.org/developers/](/developers/)でイーサリアムについて学び、試す +- お近くの[ETHGlobal](http://ethglobal.co/)ハッカソンに参加する！ +- あなたの専門分野や好みのプログラミング言語に関連する[プロジェクトをチェックする](/developers/docs/programming-languages/) +- [コンセンサスレイヤーと実行レイヤーのコール](https://www.youtube.com/@EthereumProtocol/streams)を視聴または参加する +- [エコシステム・サポート・プログラムのウィッシュリスト](https://esp.ethereum.foundation/wishlist/) - イーサリアム・エコシステム・サポート・プログラムが助成金の申請を積極的に募集しているツール、ドキュメンテーション、インフラストラクチャ分野 +- [Web3Bridge](https://www.web3bridgeafrica.com) - アフリカ全土で何百人ものデベロッパーやコミュニティメンバーを特定、トレーニング、サポートすることを目的とした、意欲的なWeb3コミュニティのイニシアチブに参加する +- [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)に参加する +- [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu)に参加する -## 研究者および学者 {#researchers-and-academics} +## 研究者 & 学者 ‍ {#researchers-and-academics} 数学、暗号技術、または経済学に関する学術的なバックグランドを持っている方は、 イーサリアムのエコシステムで行われている最先端の取り組みをご覧ください。 -- [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)への参加 +- [Eth R&D Discord](https://discord.com/invite/VmG7Uxc)に参加する - イーサリアム改善提案の執筆およびレビュー - EIPの執筆 - 1. [イーサリアム・マジシャンズ](https://ethereum-magicians.org)へアイデアの提出 - 2. [EIP-1](https://eips.ethereum.org/EIPS/eip-1) **を読んでください。これが_すべての_ドキュメント**です。 + 1. [Ethereum Magicians](https://ethereum-magicians.org)であなたのアイデアを提案する + 2. [EIP-1](https://eips.ethereum.org/EIPS/eip-1)を読む - **そうです、これがドキュメントの_すべて_です。** 3. EIP-1の指示に従います。 草案を書く際の参考にしてください。 - - [EIP編集者](https://eips.ethereum.org/EIPS/eip-5069)になる方法を学ぶ - - いつでもEIPをピアレビューできます。 [`e-review`タグが付いたオープンなプルリクエスト](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review)を参照してください。 `discussion-to`リンクで技術的なフィードバックを提供してください。 - - [EIP ガバナンス](https://github.com/ethereum-cat-herders/EIPIP)への参加 - - [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu)に加わりましょう。 - - [イーサリアム改善提案(EIP)の詳細](/eips/) -- [Challenges.ethereum.org](https://challenges.ethereum.org/) - 10万米ドルまでの高額報酬を獲得できる研究 + - [EIPエディター](https://eips.ethereum.org/EIPS/eip-5069)になる方法を学ぶ + - いつでもEIPをピアレビューできます。 [`e-review`タグが付いたオープンなPR](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review)を見る。 `discussion-to`リンクで技術的なフィードバックを提供する。 + - [EIPガバナンス](https://github.com/ethereum-cat-herders/EIPIP)に参加する + - [Ethereum Cat Herders Discord](https://discord.com/invite/Nz6rtfJ8Cu)に参加する + - [EIPの詳細](/eips/) +- [Challenges.ethereum.org](https://challenges.ethereum.org/) - 10万米ドル以上を獲得できる、高額な研究報奨金の一覧 - [Ethresear.ch](https://ethresear.ch) - イーサリアム研究の主要なフォーラムであり、暗号経済学の世界で最も影響力のあるフォーラム -- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - 研究者とのQ&Aシリーズ。 次のパートが始まるたびに、誰でも質問を投稿可能 -- [エコシステム・サポート・プログラムのウィッシュリスト](https://esp.ethereum.foundation/wishlist/) - イーサリアムのエコシステム・サポート・プログラムが助成金の申請を募集している研究分野 -- [AllWalletDevs](https://allwallet.dev) - イーサリアムデベロッパー、デザイナー、関心のあるユーザーが定期的に集まってウォレットについて議論するフォーラム +- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - 研究者との継続的なQ&Aシリーズです。 次のパートが始まるたびに、誰でも質問を投稿可能 +- [エコシステム・サポート・プログラムのウィッシュリスト](https://esp.ethereum.foundation/wishlist/) - イーサリアム・エコシステム・サポート・プログラムが助成金の申請を積極的に募集している研究分野 +- [AllWalletDevs](https://allwallet.dev) - イーサリアムのデベロッパー、デザイナー、そして関心のあるユーザーが定期的に集まりウォレットについて議論するためのフォーラム -[研究が活発な領域を探索](/community/research/) +[より活発な研究分野を探索する](/community/research/) -## 非技術的なスキル {#non-technical} +## 非技術的なスキルセット ‍ {#non-technical} デベロッパーでない場合は、イーサリアムで何から始めればよいか、迷われる場合があると思います。 下記に、いくつかのお勧めと特定の専門的な背景を持つ方向けのリソースを紹介します。 -### 自分の都市でミートアップを開催 {#meetups} +### あなたの街でミートアップを開催する {#meetups} -- 何から始めればいいか分からない場合は、 [BUIDL network](https://consensys.net/developers/buidlnetwork/)をご覧ください。 +- 何から始めればいいか分からない場合は、 [BUIDL network](https://consensys.net/developers/buidlnetwork/)が役立ちます。 -### イーサリアムに関するコンテンツの執筆 {#write-content} +### イーサリアムに関するコンテンツを書く {#write-content} - 簡単な言葉でイーサリアムの価値を説明できる、優れたライターが必要です。 -- 自分自身の記事を公開する準備ができていない場合は、 コミュニティリソースの既存のコンテンツに貢献するか、[ethereum.orgに新しいコンテンツをご提案ください](/contributing/)！ +- 自分自身の記事を公開する準備ができていない場合は、 コミュニティリソースの既存のコンテンツに貢献するか、[ethereum.orgの新しいコンテンツを提案する](/contributing/)ことを検討してください！ -### コミュニティ会議の記録 {#take-notes} +### コミュニティコールの議事録作成を申し出る {#take-notes} -- 多くのオープンソースのコミュニティ会議があり、会議メモを取ってくださると非常に助かります。 ご興味があれば、ぜひ[Ethereum Cat Herders discord](https://discord.com/invite/Nz6rtfJ8Cu)に参加し、自己紹介してください。 +- 多くのオープンソースのコミュニティ会議があり、会議メモを取ってくださると非常に助かります。 興味があれば、[Ethereum Cat Herders discord](https://discord.com/invite/Nz6rtfJ8Cu)に参加して、自己紹介をしてください！ -### イーサリアムコンテンツの母国語への翻訳 {#translate-ethereum} +### イーサリアムのコンテンツをあなたの母国語に翻訳する {#translate-ethereum} - ethereum.orgでは、ウェブサイトやその他のリソースをさまざまな言語に翻訳する翻訳プログラムがあります。 -- 参加方法は[こちら](/contributing/translation-program)をご確認ください。 +- 参加方法は[こちら](/contributing/translation-program)で確認できます -### ノードの運用 {#run-a-node} +### ノードを運営する {#run-a-node} 何千人ものノードオペレーターの一員に加わり、イーサリアムの分散化にご協力ください。 -- [ノードの運用方法の詳細](/developers/docs/nodes-and-clients/run-a-node/) +- [ノードの運営方法についての詳細](/developers/docs/nodes-and-clients/run-a-node/) -### ETHのステーキング {#staking} +### ETHをステークする {#staking} ETHをステーキングすると、イーサリアムネットワークの保護に貢献しながら、報酬を獲得することができます。 - [ステーキングの詳細](/staking/) -### プロジェクト支援 {#support-projects} +### プロジェクトを支援する {#support-projects} イーサリアムのエコシステムは、公共善や影響のあるプロジェクトに資金を提供しています。 少額の寄付であなたの支援を示し、重要なプロジェクトの実現にご協力ください。 - [Gitcoin](https://gitcoin.co/fund) - [clr.fund](https://clr.fund/#/about) -## 金融専門家および会計士 {#financial-professionals} +## 金融専門家 & 会計士 ‍ {#financial-professionals} -- イーサリアムは、代替金融システムを提供するプロトコルとアプリケーションのネットワークである「分散型金融 (DeFi) 」エコシステムの本拠地です。 金融業界の方は、[DeFi Llama](https://defillama.com/)または [DeFiPrime](https://defiprime.com)で分散型金融(DeFi)アプリをご確認ください。 -- ETH、トークン、分散型金融(DeFi)など、イーサリアムのアセットは、新しい会計上の問題を数多くもたらします。 会計士の方は、[Rotki](https://rotki.com/)のような、暗号通貨ユーザーの簿記や会計に関する問題解決を目指しているプロジェクトをぜひ一度ご確認ください。 +- イーサリアムは、代替金融システムを提供するプロトコルとアプリケーションのネットワークである「分散型金融 (DeFi) 」エコシステムの本拠地です。 あなたが金融の専門家なら、[DeFi Llama](https://defillama.com/)や[DeFiPrime](https://defiprime.com)でDeFiアプリをチェックしてみてください +- ETH、トークン、分散型金融(DeFi)など、イーサリアムのアセットは、新しい会計上の問題を数多くもたらします。 まずは、[Rotki](https://rotki.com/)のような、暗号通貨ユーザーの簿記や会計の課題解決を支援するプロジェクトをチェックすることから始められます -## プロダクトマネージャー {#product-managers} +## プロダクトマネージャー ‍ {#product-managers} -- イーサリアムエコシステムは皆さんの才能が必要です。 多くの企業がプロダクトマネージャーの求人を行っています。 オープンソースプロジェクトへの貢献を始めたい場合は、[Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu)または[RaidGuild](https://www.raidguild.org/)にご連絡ください。 +- イーサリアムエコシステムは皆さんの才能が必要です。 多くの企業がプロダクトマネージャーの求人を行っています。 オープンソースプロジェクトへの貢献から始めたい場合は、[Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu)または[RaidGuild](https://www.raidguild.org/)に連絡してください -## マーケティング {#marketing} +## マーケティング ‍ {#marketing} - イーサリアムエコシステムには、多くのマーケティングや広報のポジションがあります。 -## イーサリアムの人材募集 {#ethereum-jobs} +## イーサリアム関連の仕事 {#ethereum-jobs} -**イーサリアムに関する求人情報** +**イーサリアム関連の仕事を見つけたいですか？** -- [ethereum.org](/about/#open-jobs) -- [イーサリアム・ファウンデーションの求人掲示板](https://jobs.ashbyhq.com/ethereum-foundation) +- [ethereum.orgの求人](/about/#open-jobs) +- [イーサリアム・ファウンデーション求人掲示板](https://jobs.ashbyhq.com/ethereum-foundation) - [JobStash](https://jobstash.xyz) -- [暗号通貨の求人](https://cryptocurrencyjobs.co/ethereum/) -- [ConsenSysの求人](https://consensys.net/careers/) -- [暗号通貨求人リスト](https://cryptojobslist.com/ethereum-jobs) +- [Ethereum Job Board](https://www.ethereumjobboard.com/) +- [Cryptocurrency Jobs](https://cryptocurrencyjobs.co/ethereum/) +- [ConsenSysでのキャリア](https://consensys.net/careers/) +- [Crypto Jobs List](https://cryptojobslist.com/ethereum-jobs) - [Bankless求人掲示板](https://pallet.xyz/list/bankless/jobs) -- [Web3の求人](https://web3.career) +- [Web3 Jobs](https://web3.career) - [Web3 Army](https://web3army.xyz/) - [Crypto Valley Jobs](https://cryptovalley.jobs/) -- [イーサリアムの人材募集](https://startup.jobs/ethereum-jobs) +- [Ethereum Jobs](https://startup.jobs/ethereum-jobs) -## 分散型自律組織(DAO)への参加 {#decentralized-autonomous-organizations-daos} +## DAOに参加する {#decentralized-autonomous-organizations-daos} -「DAO」とは分散型自律組織のことで、 メンバーシップの管理、提案への投票、またはプールされた資産の管理など、イーサリアム技術を活用し、組織やコラボレーションを円滑化しているグループを指します 。 分散型自律組織(DAO)はまだ実験段階ではありますが、自分が共感できるグループを見つけ、協力者を探し、イーサリアムコミュニティへの影響力を拡大する機会を提供してくれます。 [分散型自律組織(DAO)の詳細](/dao/) +「DAO」とは分散型自律組織のことで、 メンバーシップの管理、提案への投票、またはプールされた資産の管理など、イーサリアム技術を活用し、組織やコラボレーションを円滑化しているグループを指します 。 分散型自律組織(DAO)はまだ実験段階ではありますが、自分が共感できるグループを見つけ、協力者を探し、イーサリアムコミュニティへの影響力を拡大する機会を提供してくれます。 [DAOの詳細](/dao/) -- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) - _非技術分野で分散型自律組織(DAO)の概念をプロモーションし、価値の創造を支援_ -- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) - _インターネットは共同所有されるべきという信念を共有するデベロッパーコミュニティ_ -- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) - _分散型自律組織(DAO)として機能しているフリーランスのWeb3開発共同体_ +- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) - _非技術分野でDAOの概念を推進し、人々がDAOを通じて価値を創造するのを支援します_ +- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) - _インターネットの共同所有を信じるビルダーのコミュニティ_ +- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) - _DAOとして活動するフリーランサーのWeb3開発者集団_ - [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) - _DAOhausのコミュニティガバナンス_ -- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - _リーガル・エンジニアリング_ -- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - _プレシード暗号プロジェクトのベンチャー_ -- [MetaGame](https://metagame.wtf) [@MetaFam](https://twitter.com/MetaFam) - _実際のMMORPGゲームメカニクス_ -- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - _デジ・フィジカルのアパレルブランド_ -- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) - _イーサリアム開発の資金調達に注力するコミュニティ_ -- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) - _Web3デベロッパーの共同体_ - -ethereum.orgに貢献するときは、いつでも、どのような形であれethereum.org の[行動規範](/community/code-of-conduct)を必ず遵守することを忘れずに！ +- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - _リーガルエンジニアリング_ +- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - _プレシード期の暗号資産プロジェクト向けベンチャー_ +- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - _デジフィジカルアパレルブランド_ +- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) - _イーサリアム開発への資金提供に焦点を当てたコミュニティ_ +- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) - _Web3ビルダーの集団_ + +ethereum.orgに貢献する際は、いつでも、どのような方法であっても、ethereum.orgの[行動規範](/community/code-of-conduct)を遵守することを忘れないでください！ diff --git a/public/content/translations/ja/community/grants/index.md b/public/content/translations/ja/community/grants/index.md index 79775c2b2af..08adb247f27 100644 --- a/public/content/translations/ja/community/grants/index.md +++ b/public/content/translations/ja/community/grants/index.md @@ -1,47 +1,68 @@ --- -title: イーサリアム・ファウンデーションとコミュニティの助成プログラム -description: イーサリアムエコシステム全体の助成プログラムリスト +title: "イーサリアム・ファウンデーションとコミュニティの助成プログラム" +description: "イーサリアムエコシステムの助成プログラムリスト" lang: ja --- -# イーサリアムの助成プログラム {#ethereum-grants} +# イーサリアム助成金 {#ethereum-grants} 下記のプログラムは、イーサリアムエコシステムの成功と成長を促進するプロジェクトに対して、さまざまな助成を提供しています。 これを手引きとして助成プログラムを探し、申請を行い、ご自身のイーサリアムプロジェクトの成功につなげてください。 これはコミュニティにより収集され、公開されているリストです。 もし不足や誤りがある場合は、このページを編集してください。 -## イーサリアムエコシステム全般 {#broad-ethereum-ecosystem} + + +
創設者の皆さん、事業の加速に支援は必要ですか？ [創設者サポートにアクセス](/founders/)
+ + +## 広範なイーサリアムエコシステム {#broad-ethereum-ecosystem} これらのプログラムは、広範囲のプロジェクトに助成金を提供し、イーサリアムエコシステムを幅広くサポートするものです。 拡張性、コミュニティ構築、セキュリティ、プライバシーなどのソリューションが対象となり、 どれか1つのイーサリアムプラットフォームに固有の助成プログラムではありません。 不明な場合は、まずはこちらから始めてみてください。 -- [EFエコシステム・サポート・プログラム](https://esp.ethereum.foundation) - _ユニバーサルツール、インフラストラクチャ、研究、公共財を対象とした、イーサリアムにプラスとなるオープンソース・プロジェクトへの資金提供_ -- [Moloch DAO](https://www.molochdao.com/) - _プライバシー、レイヤー2スケーリング、クライアントセキュリティなど_ -- [分散型自律組織(DAO)の助成](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _助成プログラムを提供する組織のGoogleスプレッドシート_ -- [学術助成金](https://esp.ethereum.foundation/academic-grants) - _イーサリアム関連の学術研究をサポートする助成金_ -- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _Blockworksは、すべての助成金、RFP、バグ報奨金をディレクトリとしてまとめています。_ +- [EFエコシステム・サポート・プログラム](https://esp.ethereum.foundation) - _イーサリアムに貢献するオープンソースプロジェクトへの資金提供。特にユニバーサルツール、インフラ、研究、公共財に重点を置いています_ +- [学術助成金](https://esp.ethereum.foundation/academic-grants) - _イーサリアム関連の学術研究を支援する助成金_ + +## 助成金リストのアグリゲーターとプラットフォーム {#grant-list-aggregators} + +これらのリソースは、イーサリアムエコシステム全体のさまざまな助成金の機会を収集、整理しており、プロジェクトのニーズに合った資金調達の機会を簡単に見つけることができます。 特定の資金調達ニーズに基づいて最も関連性の高いリソースを見つけ始められるように、ペルソナ別に整理しました。 + +### すべての助成金申請者向け: 総合ディレクトリ {#comprehensive-directories} + +これらの一般的なプラットフォームは、Web3空間全体の助成金を幅広くカバーしており、資金調達先を探している人にとって有用な出発点となります: + +- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _Blockworksは、すべての助成金、RFP、バグ報奨金の包括的なディレクトリをまとめています。_ +- [Blockchain Grants](https://www.blockchaingrants.org/) - _ブロックチェーンと暗号資産の助成金ディレクトリ_ +- [Karma Funding Map](https://gap.karmahq.xyz/funding-map) - すべてのWeb3助成金プログラムのディレクトリ、毎週更新 + +### デベロッパーおよびビルダー向け {#for-developers-and-builders} + +- [Grant Programs Viewer](https://airtable.com/shr86elKgWTSCP4AY) - _助成金プログラムの公開Airtableデータベース_ +- [Web3 Grants Spreadsheet](https://docs.google.com/spreadsheets/d/1c8koZCI-GLnD8MG-eFcXPOBCNu1v8-aXIfwAAvc7AMc/edit#gid=0) - _Web3助成金機会のGoogleスプレッドシート_ +- [Arbitrum Grants](https://arbitrum.foundation/grants) — Arbitrum DAOおよび[The Arbitrum Foundation](https://arbitrum.foundation/) + +### DeFiプロジェクトおよび金融アプリケーション向け {#for-defi-projects} + +- [LlamaoGrants](https://wiki.defillama.com/wiki/LlamaoGrants) - _DeFi Llamaの助成金プログラムディレクトリ_ +- [AlphaGrowth Grants](https://alphagrowth.io/crypto-web3-grants-list) - _暗号資産とWeb3の助成金の包括的リスト_ +- [Uniswap Foundation Grants](https://www.uniswapfoundation.org/build) - _DeFiビルダー向けのUnichainおよびUniswap v4の助成金とサポート_ -## 固有のプロジェクト {#project-specific} +### DAOのコントリビューターおよびガバナンスのイノベーター向け {#for-dao-contributors} -下記は、独自のテクノロジーの開発とテストを目的とした、プロジェクトに特化した助成プログラムです。 +コミュニティ主導のプロジェクトやガバナンスの実験のためのリソース: -- [Aave Grants Program](https://aavegrants.org/) – _[Aave](https://aave.com/)の分散型自律組織(DAO)助成プログラム_ -- [Balancer](https://grants.balancer.community/) – _[Balancer](https://balancer.fi/)エコシステムファンド_ -- [Chainlink助成プログラム](https://chain.link/community/grants) - _[Chainlink](https://chain.link/) コミュニティ助成プログラム_ -- [分散型助成金プログラム](https://governance.decentraland.org/grants/) – _[分散型](https://decentraland.org/)DAOメタバース_ -- [Lido Ecosystem Grants Organisation (LEGO)](https://lido.fi/lego) – _[Lido](https://lido.fi/)金融エコシステム_ -- [MetaMaskプログラム](https://metamaskgrants.org/) - _[MetaMask](https://metamask.io/)従業員主導のDAO助成プログラム_ -- [SKALE Network助成金プログラム](https://skale.space/developers#grants) - _[SKALE Network](https://skale.space/)エコシステム_ -- [Swarm Foundation助成金プログラム](https://my.ethswarm.org) - _[Swarm Foundation](https://www.ethswarm.org/)エコシステム_ -- [The Graph](https://thegraph.com/ecosystem/grants/) – _[The Graph](https://thegraph.com/)エコシステム_ -- [ユニスワップ助成金プログラム](https://www.uniswapfoundation.org/approach) – _[ユニスワップ](https://uniswap.org/)コミュニティ_ +- [DAO Grants](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _助成金を提供する組織のGoogleスプレッドシート_ +- [MetaGov Database](https://docs.google.com/spreadsheets/d/1e5g-dlWWsK2DZoZGBgfxyfGNSddLk-V7sLEgfPjEhbA/edit#gid=780420708) - _包括的なWeb3助成金マップ_ -## クオドラティック・ファンディング {#quadratic-funding} +### 公共財とインパクト {#public-goods-and-impact} -イーサリアムのオープンソースのルーツにより、「クオドラティック・ファンディング」という新しく、興味深い資金調達モデルが成長してきています。 クアドラティック・ファンディングは、将来的にすべての種類の公共財の資金供給方法を改善できる可能性を秘めており、 最もユニークな必要性があるプロジェクトが、最多の資金を受け取るようになっています。 つまり、最も多くの人々が必要なものに資金が渡り、人々の生活の向上につながるプロジェクトです。 [クオドラティック・ファンディングの詳細](/defi/#quadratic-funding) +これらのプログラムは、広範なコミュニティ、公共財、インパクトイニシアチブに貢献するプロジェクトへの資金提供に重点を置いています。 これらには、助成金の提供者に加え、[クアドラティックファンディング](/defi/#quadratic-funding)などのオンチェーンの資金配分メカニズムを活用した寄付プラットフォームが含まれます: -- [Gitcoin](https://gitcoin.co/grants) -- [clr.fund](https://clr.fund/) +- [Gitcoin](https://www.gitcoin.co/program) - _Gitcoin Grantsは、複数の資本配分メカニズムを活用し、イーサリアムエコシステム内のオープンソースプロジェクトや公共財に資金を提供しています_ +- [Octant](https://octant.app/home) - _共通善と個人の経済的エンパワーメントのバランスをとる公共財資金調達エコシステム_ +- [Giveth](https://giveth.io/) - _追加手数料なしで慈善プロジェクトに直接寄付できる暗号資産寄付プラットフォーム_ +- [Artizen](https://artizen.fund/) - _アート、科学、テクノロジー、文化のフロンティアで、クリエイターが新しいプロジェクトにマッチングファンドで資金調達できるよう支援します_ +- [Quadratic Accelerator](https://qacc.giveth.io/) - _クアドラティックファンディングを利用して公共の利益に資するプロジェクトを支援する、スタートアップアクセラレータープログラム_ -## イーサリアムの人材募集 {#work-in-ethereum} +## イーサリアムで働く {#work-in-ethereum} -自分自身のプロジェクトを始める準備ができていなくても、 イーサリアムエコシステムに取り組み、貢献する情熱的な人材を積極的に探している何百もの企業があります。 詳細は [イーサリアム関連の求人をチェックしてみてください](/community/get-involved/#ethereum-jobs)。 +自分自身のプロジェクトを始める準備ができていなくても、 イーサリアムエコシステムに取り組み、貢献する情熱的な人材を積極的に探している何百もの企業があります。 詳細は [イーサリアム関連の求人をチェックする](/community/get-involved/#ethereum-jobs) diff --git a/public/content/translations/ja/community/language-resources/index.md b/public/content/translations/ja/community/language-resources/index.md index 0c7e60093ba..74ea061c6c2 100644 --- a/public/content/translations/ja/community/language-resources/index.md +++ b/public/content/translations/ja/community/language-resources/index.md @@ -1,6 +1,6 @@ --- -title: 言語リソース -description: イーサリアムに関する英語以外のリソース +title: "言語リソース" +description: "イーサリアムに関する英語以外のリソース" lang: ja --- @@ -12,141 +12,142 @@ lang: ja 自分の母国語でのコンテンツの閲覧をご希望の場合、または英語を話さない人に情報を共有したい場合は、下記の翻訳されたリソースをご確認ください。 何十万人ものイーサリアム愛好家がこれらのオンラインフォーラムに集まり、ニュースを共有し、最近の開発や技術的な問題を議論し、未来を想像しています。 -あなたの母国語での教育リソースをご存知の場合は、 [こちら](https://github.com/ethereum/ethereum-org-website/issues/new/choose)からリストに追加してください。 +あなたの母国語での教育リソースをご存知の場合は、 リストに追加するには、[issueを開いてください](https://github.com/ethereum/ethereum-org-website/issues/new/choose)。 -## ethereum.orgのリソース {#ethereum-org} +## Ethereum.orgのリソース {#ethereum-org} ethereum.orgは、40言語以上のネイティブに翻訳されており、各ページのトップにある言語選択メニューで選択可能です。 -![言語選択メニュー](./language-selector-menu.png) +![言語セレクターメニュー](./language-selector-menu.png) -バイリンガルで、イーサリアムをより多くの人に知ってもらいたいと思われる方は、ぜひ[ethereum.org翻訳プログラム](/contributing/translation-program/#translation-program)に参加し、ウェブサイトの翻訳にご協力ください。 +もしあなたがバイリンガルで、より多くの人々にリーチする手助けをしたい場合は、[ethereum.org翻訳プログラム](/contributing/translation-program/#translation-program)に参加して、ウェブサイトの翻訳を手伝うこともできます。 ## コミュニティリソース {#community} -### ブラジル・ポルトガル語 {#br-pt} +### ブラジルポルトガル語 {#br-pt} **ニュース** -- [BeInCrypto](http://www.beincrypto.com.br) - ブラジルで利用できる交換所のリストを含む暗号通貨ニュースと記事 -- [Cointelegraph](http://cointelegraph.com.br/category/analysis) - ブラジル版Cointelegraph、主要な暗号通貨報道機関 -- [Livecoins](http://www.livecoins.com.br/ethereum) - 暗号通貨ニュースとツール -- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) - 暗号通貨ニュースとレポート -- [Modular Crypto](https://modularcrypto.xyz/) - 暗号通貨ニュースおよび教育記事 +- [BeInCrypto](http://www.beincrypto.com.br) - ブラジルで利用可能な取引所のリストを含む、暗号通貨のニュースと記事 +- [Cointelegraph](http://cointelegraph.com.br/category/analysis) - 大手暗号通貨ニュースメディアであるCointelegraphのブラジル版 +- [Livecoins](http://www.livecoins.com.br/ethereum) - 暗号通貨のニュースとツール +- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) - 暗号通貨のニュースとレポート +- [Modular Crypto](https://modularcrypto.xyz/) - 暗号通貨のニュースと教育記事 **教育** -- [web3dev](https://www.web3dev.com.br/) - Web3デベロッパー向けコンテンツハブとDiscordコミュニティ -- [Web3Brasil](https://github.com/web3brasil/web3brasil) - Web3と分散型金融(DeFi)に関するリソース -- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - 「初心者のためのイーサリアム」や「分散型金融(DeFi)」などの暗号通貨ニュースと教育 -- [CriptoAtivos](http://www.criptoativos.wiki.br/) - 暗号通貨、教育、ブログ -- [Cointimes](http://www.cointimes.com.br/) - 暗号通貨ニュースと教育 -- [Web3 starter pack](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) - 基本的な暗号資産に関するよくある質問へのガイド +- [web3dev](https://www.web3dev.com.br/) - Web3開発者向けのコンテンツハブおよびDiscordコミュニティ。 +- [Web3Brasil](https://github.com/web3brasil/web3brasil) - Web3とDeFiを学ぶためのリソース +- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - 「初心者向けイーサリアム」や「初心者向けDeFi」など、暗号通貨のニュースと教育 +- [CriptoAtivos](http://www.criptoativos.wiki.br/) - 暗号通貨分野からのインサイト、教育、ブログ +- [Cointimes](http://www.cointimes.com.br/) - 暗号通貨のニュースと教育 +- [Web3スターターパック](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) - 暗号資産に関する最も頻繁に寄せられる基本的な質問に答えるガイド ### 中国語 {#zh} **一般リソース** -- [Ethereum.cn](https://www.ethereum.cn/) - コンセンサスレイヤーのアップグレード、すべてのコアデベロッパー会議メモ、レイヤー2など、コミュニティにより維持されているコンテンツ -- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - 基本から高度なトピックまでイーサリアムのすべて -- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - イーサリアム、分散型金融(DeFi)、非代替性トークン(NFT)、Web3関連のコミュニティにより維持されているコンテンツ -- [123ETH](https://123eth.org/) -イーサリアムエコシステムのポータル -- [Zhen Xiao](http://zhenxiao.com/blockchain/) - 暗号通貨とアプリケーションに関する無料オンラインコース -- [イーサリアム・ホワイトペーパー](https://github.com/ethereum/wiki/wiki/[%E4%B8%AD%E6%96%87]-%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6) - 中国語版のイーサリアム・ホワイトペーパー +- [Ethereum.cn](https://www.ethereum.cn/) - コンセンサスレイヤーのアップグレード、すべてのコア開発者会議の議事録、レイヤー2などをカバーする、コミュニティによって維持されているコンテンツ。 +- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - イーサリアムの基礎から応用まで、あらゆるトピックを学べます +- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - イーサリアム、DeFi、NFT、Web3関連の知識を網羅した、コミュニティによって維持されているコンテンツ +- [123ETH](https://123eth.org/) - イーサリアムエコシステムへのポータル +- [Zhen Xiao](http://zhenxiao.com/blockchain/) - 暗号通貨とその応用に関する無料オンラインコース +- [イーサリアムホワイトペーパー](/zh/whitepaper/) - 中国語版のイーサリアムホワイトペーパー **イーサリアムエコシステム** -- [ETHPlanet](https://www.ethplanet.org/) - 大学生へのトレーニングを提供する、オンラインおよび対面ハッカソン -- [PrimitivesLane](https://www.primitiveslane.org/) - ブロックチェーン技術に焦点を当てた非営利研究グループ -- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - イーサリアム教育コンテンツの翻訳に専念するコミュニティ +- [ETHPlanet](https://www.ethplanet.org/) - 大学生向けのトレーニングを提供する、オンラインおよび対面のハッカソン +- [PrimitivesLane](https://www.primitiveslane.org/) - ブロックチェーン技術に特化した非営利の研究グループ +- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - イーサリアムの教育コンテンツの翻訳に特化したコミュニティ **デベロッパー向け** -- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - 主流の分散型アプリ(Dapp)プロジェクトを研究し、考えやコメントを毎週共有する学習グループ -- [LearnBlockchain](https://learnblockchain.cn/) - デベロッパー向けコミュニティ、ブロックチェーン技術に関する情報共有 +- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - 主流のdappプロジェクトを研究し、毎週考察やコメントを共有する学習グループ +- [LearnBlockchain](https://learnblockchain.cn/) - ブロックチェーン技術に関する情報を共有する、開発者向けのコミュニティ **暗号技術研究者向け** -- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - 暗号技術、セキュリティなどに関するWeChatアカウント -- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - ZK(ゼロ知識証明)技術に関するWeChatアカウント +- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - 暗号技術やセキュリティなどを解説するWeChatアカウント +- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - zk技術を解説するWeChatアカウント ### チェコ語 {#cs} -- [Gwei.cz](https://gwei.cz) - Web3に関するローカル コミュニティ、教育コンテンツの作成、オンラインおよび対面イベントの開催 +- [Gwei.cz](https://gwei.cz) - Web3に関する地域コミュニティ。教育コンテンツの作成、オンラインおよび対面イベントの開催 - [Gwei.cz Příručka](https://prirucka.gwei.cz/) - 初心者向けイーサリアムガイド -- [DAO Příručka](https://dao.gwei.cz/) - 初心者向け分散型アプリ(Dapp)ガイド -- [Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - チェコ語でイーサリアムをマスター +- [DAO Příručka](https://dao.gwei.cz/) - DAOの初心者向けガイド +- [Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - チェコ語版『Mastering Ethereum』 ### フランス語 {#fr} -- [Ethereum France](https://www.ethereum-france.com/) - イーサリアムイベントの開催、コンテンツの作成、イーサリアムに関する議論 +- [Ethereum France](https://www.ethereum-france.com/) - Ethereum Franceはイベントを主催し、コンテンツを作成し、イーサリアムに関する議論を奨励しています - [Ethereum.fr](https://ethereum.fr/) - イーサリアムのニュースと教育 - [BanklessFR](https://banklessfr.substack.com/) - フランス語版Banklessニュースレター - [CryptoFR](https://cryptofr.com/category/44/ethereum-general) - イーサリアムのサブページがある暗号通貨フォーラム ### ドイツ語 {#de} -- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) - Solidityの使い方 -- [Microsoft Learn (スマートコントラクト)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - Solidityを使ったイーサリアムのスマートコントラクトの書き方 -- [Microsoft Learn (イーサリアムネットワーク)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) - イーサリアムネットワークへの接続およびデプロイ -- [Microsoft Learn (ブロックチェーン)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) - ブロックチェーン開発入門 +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) - Solidityの使用 +- [Microsoft Learn (スマートコントラクト)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - Solidityを使ったイーサリアムスマートコントラクトの作成 +- [Microsoft Learn (イーサリアムネットワーク)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) - イーサリアムネットワークへの接続とデプロイ +- [Microsoft Learn (ブロックチェーン)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) - ブロックチェーン開発への入門 ### ヘブライ語 {#he} -- [ウディ・ヴァルトハイマー - ビットコイナーがイーサリアムから学べること](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/) -- [オマー・グレイスマン (OpenZeppelin) - 150億ドルのスマートコントラクトハックを防いだ方法](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/) -- [シャイ・ダティカ (INX) - トークン化と証券の未来、そしてイーサリアムは証券かどうか](https://www.cryptojungle.co.il/shy-datika-tokenization/) -- [ロイ・コンフィノ (Lemonade) - イーサリアムでの保険](https://www.cryptojungle.co.il/roy-confino-insurance/) -- [イダン・オフラット (Fireblocks) - 機関投資家の採用](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/) -- [ガル・ワイズマン (MetaMask) - MetaMaskとは何か](https://www.cryptojungle.co.il/gal-weizman-metamask/) -- [ドロール・アヴィエリ (Consensys) - イーサリアムの中心](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/) -- [ニル・ロジン - クリプトパンクであること](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/) -- [アダン・ケデム - ゲーミング & メタバース](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/) -- [ウリ・コロドニー (Starkware) - イーサリアムとブロックチェーンレイヤー](https://www.cryptojungle.co.il/uri-kolodny-starkware/) -- [ウディ・ヴァルトハイマー - イーサリアム2.0と競合](https://www.cryptojungle.co.il/udi-on-eth2/) -- [ベン・サモチャ (私自身) - イーサリアム2.0はチャンスか？](https://www.cryptojungle.co.il/etherurm2-week-summary/) -- [アロン・ムロック (Bloxstaking) - イーサリアム2.0とは何か？](https://www.cryptojungle.co.il/alon-moroch-eth2/) -- [エイロン・アヴィヴ (Collider Ventures) - イーサリアム2.0で起こりうる問題](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/) -- [エイロン・アヴィヴ (Collider Ventures) - なぜイーサリアム2.0が必要なのか](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/) +- [Udi Wertheimer - ビットコイナーがイーサリアムから学べること](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/) +- [Omer Greismen (OpenZeppelin) - 150億ドルのスマートコントラクトハッキングをいかにして防いだか](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/) +- [Shy Datika (INX) - トークン化と証券の未来、イーサリアムは証券かという問題も含む](https://www.cryptojungle.co.il/shy-datika-tokenization/) +- [Roy Confino (Lemonade) - イーサリアムにおける保険](https://www.cryptojungle.co.il/roy-confino-insurance/) +- [Idan Ofrat (Fireblocks) - 機関投資家による採用](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/) +- [Gal Weizman (MetaMask) - MetaMaskとは何か](https://www.cryptojungle.co.il/gal-weizman-metamask/) +- [Dror Aviely (Consensys) - イーサリアムの中心](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/) +- [Nir Rozin - クリプトパンクであること](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/) +- [Adan Kedem - ゲームとメタバース](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/) +- [Uri Kolodny (Starkware) - イーサリアムとブロックチェーンレイヤー](https://www.cryptojungle.co.il/uri-kolodny-starkware/) +- [Udi Wertheimer - Ethereum 2.0 vs 競合](https://www.cryptojungle.co.il/udi-on-eth2/) +- [Ben Samocha (私自身) - Ethereum 2.0 - 機会か？](https://www.cryptojungle.co.il/etherurm2-week-summary/) +- [Alon Muroch (Bloxstaking) - Ethereum 2.0とは何か？](https://www.cryptojungle.co.il/alon-moroch-eth2/) +- [Eilon Aviv (Collider Ventures) - Ethereum 2.0で起こりうる問題](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/) +- [Eilon Aviv (Collider Ventures) - なぜEthereum 2.0が必要なのか](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/) ### イタリア語 {#it} -- [Ethereum Italia](https://www.ethereum-italia.it/) - スマートコントラクトとブロックチェーン技術に焦点を置いたイーサリアムの教育、イベント、ニュース +- [Ethereum Italia](https://www.ethereum-italia.it/) - スマートコントラクトとブロックチェーン技術に焦点を当てた、イーサリアムの教育、イベント、ニュース - [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) - イタリア語のイーサリアムポッドキャスト -- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - Solidityの使い方 -- [Microsoft Learn (Smart contracts)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - Solidityを使ったイーサリアムのスマートコントラクトの書き方 -- [Microsoft Learn 分散型アプリ(Dapp)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) - 分散型アプリでユーザーインターフェースを作成 +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - Solidityの使い方を学ぶ +- [Microsoft Learn (スマートコントラクト)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - Solidityを使ったスマートコントラクトの作成について学ぶ +- [Microsoft Learn (dapps)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) - 分散型アプリケーションでユーザーインターフェースを作成する ### 日本語 {#ja} - [一般社団法人日本暗号資産取引業協会](https://jvcea.or.jp/) - [一般社団法人日本暗号資産ビジネス協会](https://cryptocurrency-association.org/) -- [ブロックチェーン開発の概要 - Learn | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - ブロックチェーンとイーサリアムプラットフォームでの開発に関する説明 -- [マスタリング・イーサリアム](https://www.oreilly.co.jp/books/9784873118963/) - スマートコントラクトと分散型アプリ(Dapp)の構築 +- [ブロックチェーン開発を始めましょう - Learn | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - このラーニングパスでは、ブロックチェーンとイーサリアムプラットフォームでの開発について紹介します +- [Mastering Ethereum](https://www.oreilly.co.jp/books/9784873118963/) - 日本語版『Mastering Ethereum』 +- [SolidityとEthereumによる実践スマートコントラクト開発](https://www.oreilly.co.jp/books/9784873119342/) - 日本語版『SolidityとEthereumによる実践スマートコントラクト開発』 ### ロシア語 {#ru} -- [Cyber Academy](https://cyberacademy.dev) - Web3ビルダーのための学習スペース -- [Forklog](https://forklog.com) - 暗号資産全般に関するニュースや教育的な記事、既存技術やさまざまなブロックチェーンの将来のアップグレードについて -- [BeInCrypto](https://ru.beincrypto.com) - ニュース、暗号資産の価格分析、そして暗号資産全般についての非技術的で簡単な説明を含む記事 +- [Cyber Academy](https://cyberacademy.dev) - Web3ビルダーのための教育スペース +- [Forklog](https://forklog.com) - 暗号資産全般、既存の技術、さまざまなブロックチェーンの将来のアップグレードに関するニュースと教育記事 +- [BeInCrypto](https://ru.beincrypto.com) - ニュース、暗号資産の価格分析、暗号資産のすべてについて簡単な説明を付けた非技術的な記事 ### スペイン語 {#es} -- [Ethereum Madrid](https://ethereummadrid.com/) - ブロックチェーン、分散型金融(DeFi)、およびガバナンスに関するコース、イベント、ブログ -- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) - 初心者向けのスペイン語イーサリアムガイド -- [Tutoriales online](https://tutoriales.online/curso/solidity) - イーサリアムでのSolidityとプログラミングの学習 -- [Curso Introduction a Ethereum Development](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - Solidityの基本、はじめてのスマートコントラクト(テストとデプロイ) -- [Curso Introducción a Seguridad y Hacking en Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - 実際のスマートコントラクトでよくある脆弱性とセキュリティ問題の理解 -- [Curso Introduction a DeFi Development](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - 分散型金融(DeFi)スマートコントラクトがSolidityでどのように動作し、独自の自動マーケットメーカーを作成するかの学習 -- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) - 初心者から上級者までの非技術的なブロックチェーン学習。 暗号技術とイーサリアムに関するすべての学び +- [Ethereum Madrid](https://ethereummadrid.com/) - ブロックチェーン、DeFi、ガバナンスに関するコース、イベント、ブログ +- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) - スペイン語の初心者向けイーサリアムガイド +- [Tutoriales online](https://tutoriales.online/curso/solidity) - Solidityとイーサリアムでのプログラミングを学ぶ +- [Curso Introducción a Ethereum Development](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - Solidityの基礎、最初のスマートコントラクトのテストとデプロイ +- [Curso Introducción a Seguridad y Hacking en Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - 実際のスマートコントラクトにおける一般的な脆弱性とセキュリティ問題を理解する +- [Curso Introducción a DeFi Development](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - DeFiスマートコントラクトがSolidityでどのように機能するかを学び、独自の自動マーケットメーカーを作成する +- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) - 初心者から上級者までを対象とした、非技術者向けのブロックチェーン教育。 暗号技術とイーサリアムに関するすべての学び ### トルコ語 {#tr} -- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - ブロックチェーンと暗号通貨に焦点を置いたコース -- [リブランディング: Eth2の名称廃止](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) - トルコ語版「Eth2」の名称廃止に関するブログ投稿 +- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - ブロックチェーンと暗号通貨に特化したコース +- [名称変更：Eth2はどうなったのか？](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) - 「Eth2」という用語を使わなくなったことを説明する、名称変更に関するブログ記事のトルコ語訳 ### ベトナム語 {#vi} -- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - イーサリアム、分散型アプリ(Dapp)、ウォレットの概要、よくある質問 -- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - イーサリアムのニュースと教育のサブページがあるウェブプラットフォーム -- [Coin68](https://coin68.com/ethereum-tieu-diem/) - イーサリアムのニュースと教育コンテンツを含む暗号通貨ポータル +- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - イーサリアム、dapps、ウォレット、FAQの概要 +- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - イーサリアムのニュースと教育用のサブページがあるウェブプラットフォーム +- [Coin68](https://coin68.com/ethereum-tieu-diem/) - イーサリアムのニュースと教育コンテンツを備えた暗号通貨ポータル diff --git a/public/content/translations/ja/community/online/index.md b/public/content/translations/ja/community/online/index.md index 157900c8943..ada756af2ad 100644 --- a/public/content/translations/ja/community/online/index.md +++ b/public/content/translations/ja/community/online/index.md @@ -1,6 +1,6 @@ --- -title: オンラインコミュニティ -description: イーサリアムエコシステムの助成プログラムリスト +title: "オンラインコミュニティ" +description: "イーサリアムの愛好家が集まって議論や協力を行うオンラインフォーラム、チャットルーム、ソーシャルメディアコミュニティを見つけましょう。" lang: ja --- @@ -8,43 +8,67 @@ lang: ja 何十万人ものイーサリアム愛好家がこれらのオンラインフォーラムに集まり、ニュースを共有し、最近の開発や技術的な問題を議論し、未来を想像しています。 +## 掲載ポリシー {#listing-policy} + +リストアップされたコミュニティの完全性と価値を維持するため、ethereum.orgは適格性を判断するための厳格な方針に従っています: + +### 適格基準 {#eligibility-criteria} + +- **関連性**: コミュニティは、イーサリアムとそのエコシステムに直接関連している必要があります。 +- **アクティビティレベル**: コミュニティは、定期的な交流、投稿、または議論が行われ、アクティブである必要があります。 休止中または非アクティブなコミュニティは削除される場合があります。 +- **包括性**: コミュニティは、多様性を尊重し、あらゆる背景を持つ人々の参加を奨励する、歓迎的な環境を育む必要があります。 +- **非営利重視**: 掲載は、商業的または宣伝的なプラットフォームではなく、コミュニティ主導のスペースを対象としています。 + +### コンテンツガイドライン {#content-guidelines} + +- **適切なコンテンツ**: コミュニティは、スパム、ヘイトスピーチ、ハラスメント、または違法行為を助長するコンテンツを避け、独自のモデレーションガイドラインを設ける必要があります。 +- **言語**: 主な言語は英語ですが、包括的で敬意のある雰囲気を維持している限り、他の言語のコミュニティからの申請も歓迎します。 +- **透明性**: コミュニティの目的、ルール、モデレーターに関する明確な情報が、メンバーに提供されている必要があります。 + +### その他の推奨事項 {#other-recommendations} + +- **アクセシビリティ**: コミュニティフォーラムは、サインアップや登録を必要とせずに、誰もが閲覧できる必要があります。 +- **Discordサーバーへの招待**: ethereum.orgには、信頼できるDiscordサーバーの招待のみを追加することが推奨されます。 理想的には、これらの招待はウェブサイトのコミュニティページ (例: [ethglobal.com/discord](https://ethglobal.com/discord)) にリンクするか、公式URL (例: [discord.gg/ethstaker](https://discord.gg/ethstaker) または [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker)) からのものであるべきです。 + +これらのガイドラインに基づいてコミュニティを追加または削除すべきだと思われる場合は、[GitHubリポジトリでissueをオープン](https://github.com/ethereum/ethereum-org-website/issues)してください。 + ## フォーラム {#forums} -r/ethereum - イーサリアム全般 -r/ethfinance - 分散型金融(DeFi)などイーサリアムの金融面 -r/ethdev - イーサリアム開発 +r/ethereum - イーサリアムに関するすべて +r/ethfinance - DeFi を含むイーサリアムの金融面 +r/ethdev - イーサリアム開発に特化 r/ethtrader - トレンドと市場分析 -r/ethstaker - イーサリアムステーキングに関心のある方向け -Fellowship of Ethereum Magicians - イーサリアムの技術標準規格に関するコミュニティ -Ethereum Stackexchange - イーサリアムデベロッパー向けの議論とサポート -Ethereum Research - 暗号経済研究の最も影響力のある掲示板 +r/ethstaker - イーサリアムでのステーキングに関心のあるすべての人を歓迎 +Fellowship of Ethereum Magicians - イーサリアムの技術標準を中心としたコミュニティ +Ethereum Stackexchange - イーサリアムデベロッパーのためのディスカッションとヘルプ +Ethereum Research - 暗号経済学研究のための最も影響力のあるメッセージボード ## チャットルーム {#chat-rooms} -Ethereum Cat Herders - イーサリアム開発プロジェクトの管理支援に関するコミュニティ -Ethereum Hackers - ETHGlobalが運営するDiscordチャット: 世界中のイーサリアムハッカーのオンラインコミュニティ -CryptoDevs - イーサリアム開発に関するDiscordコミュニティ -EthStaker Discord - コミュニティが運営するステーカーおよびステーカーになるこを考えている人向けのガイダンス、教育、サポート、リソース -ethereum.orgウェブサイトチーム - ethereum.orgウェブ開発とデザインのコミュニティチャット -Matos Discord - 事業者、業界のリーダー、イーサリアム愛好家が集う、Web3のクリエイターのコミュニティ。 Web3開発、設計、文化に熱心です。 参加して一緒に開発しましょう。 -Solidity Gitter - Solidity開発に関するチャット(Gitter) -Solidity Gitter - Solidity開発に関するチャット(Matrix) -Ethereum Stack Exchange *- 質疑応答フォーラム* -Peeranha *- 分散型の質疑応答フォーラム* +Ethereum Cat Herders - イーサリアム開発へのプロジェクト管理サポートの提供を中心としたコミュニティ +Ethereum Hackers - ETHGlobalが運営するDiscordチャット: 世界中のイーサリアムハッカーのためのオンラインコミュニティ +CryptoDevs - イーサリアム開発に特化したDiscordコミュニティ +EthStaker Discord - 既存および潜在的なステーカーのための、コミュニティによるガイダンス、教育、サポート、リソース +Ethereum.org website team - チームやコミュニティの人々と一緒にethereum.orgのWeb開発やデザインについてチャットしましょう +Matos Discord - ビルダー、業界の重鎮、イーサリアムの愛好家が集まるWeb3クリエイターコミュニティ。 Web3開発、設計、文化に熱心です。 ぜひ一緒に開発しましょう。 +Solidity Gitter - Solidity開発のためのチャット (Gitter) +Solidity Matrix - Solidity開発のためのチャット (Matrix) +Ethereum Stack Exchange - 質問と回答のフォーラム +Peera Community Forum - 分散型の質問と回答のフォーラム -## YouTubeとTwitter {#youtube-and-twitter} +## YouTubeとX (旧Twitter) {#youtube-and-twitter} -イーサリアム・ファウンデーション - イーサリアム・ファウンデーションの最新情報 -@ethereum - イーサリアム・ファウンデーションの公式アカウント -@ethdotorg - 日々拡大するグローバルコミュニティのために作られたイーサリアムへのポータル -影響力のあるイーサリアムに関するTwitterアカウントリスト +Ethereum Foundation - イーサリアム・ファウンデーションからの最新情報を入手 +@ethereum - コミュニティ向けの主要なイーサリアムアカウント +@ethereumfndn - イーサリアム・ファウンデーションの公式アカウント +@ethdotorg - 成長を続けるグローバルコミュニティのために構築された、イーサリアムへのポータル
- 非代替性トークン(NFT)の詳細 + DAOについてもっと知る -
+ diff --git a/public/content/translations/ja/community/research/index.md b/public/content/translations/ja/community/research/index.md index 3b46ab27913..780e9f3b536 100644 --- a/public/content/translations/ja/community/research/index.md +++ b/public/content/translations/ja/community/research/index.md @@ -1,6 +1,6 @@ --- -title: イーサリアムのアクティブな研究分野 -description: さまざまなオープンリサーチの分野を探求し、参加方法を学ぶ。 +title: "イーサリアムのアクティブな研究分野" +description: "さまざまなオープンリサーチの分野を探求し、参加方法を学ぶ。" lang: ja --- @@ -18,7 +18,7 @@ lang: ja 2022年5月に[DelphiDigital](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) が発行したこのレポートは、イーサリアムのロードマップの良い概要を提供しています。 -## 資金提供の源{#sources-of-funding} +## 資金提供の源 {#sources-of-funding} イーサリアムの研究に参加して報酬を得ることができます！ たとえば、[イーサリアム・ファウンデーション](/foundation/) は最近、[学術助成金の資金調達ラウンド](https://esp.ethereum.foundation/academic-grants) を実施しました。 現在の資金提供機会や今後の機会については、[イーサリアムの助成金ページ](/community/grants/) で情報を見つけることができます。 @@ -57,7 +57,7 @@ lang: ja - ライトクライアントサポートの構築 - ガスリミットの研究 -- 新しいデータ構造の組み込み (例：バークルツリー) +- 新しいデータ構造の組み込み(例：Verkleトライ)。 #### バックグラウンドリーディング {#background-reading-1} @@ -83,7 +83,7 @@ lang: ja 1. コンセンサスクライアント：ブロックチェーンのヘッドを追跡し、ブロックを伝播し、コンセンサスロジックを処理します。 2. 実行クライアント：イーサリアム仮想マシンをサポートし、トランザクションやスマートコントラクトを実行します。 -ノードやクライアントの詳細については、[ノードとクライアントのページ](/developers/docs/nodes-and-clients/) で確認でき、すべての現行クライアント実装のリストもご覧いただけます。 また、イーサリアムの全てのアップグレード履歴は[履歴ページ](/ethereum-forks/) で確認可能です。 +ノードとクライアント、および現在のすべてのクライアント実装のリストについて詳しくは、[ノードとクライアントページ](/developers/docs/nodes-and-clients/)をご覧ください。 また、イーサリアムの全てのアップグレード履歴は[履歴ページ](/ethereum-forks/) で確認可能です。 ### 実行クライアント {#execution-clients} @@ -111,7 +111,7 @@ lang: ja #### 最近の研究 {#recent-research-2} - [シーケンサーに対するArbitrumのフェアオーダリング](https://eprint.iacr.org/2021/1465) -- [ethresear.ch レイヤー2](https://ethresear.ch/c/layer-2/32) +- [Ethresear.chレイヤー2](https://ethresear.ch/c/layer-2/32) - [ロールアップ中心のロードマップ](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) - [L2Beat](https://l2beat.com/) @@ -189,7 +189,7 @@ lang: ja - [ウォレットの概要](/wallets/) - [ウォレットセキュリティの概要](/security/) -- [ethresear.ch セキュリティ](https://ethresear.ch/tag/security) +- [Ethresear.chセキュリティ](https://ethresear.ch/tag/security) - [EIP-2938 アカウント抽象化](https://eips.ethereum.org/EIPS/eip-2938) - [EIP-4337 アカウント抽象化](https://eips.ethereum.org/EIPS/eip-4337) @@ -358,7 +358,7 @@ lang: ja ### オラクル {#oracles} -オラクルは、パーミッションレスで分散化された方法でオフチェーンデータをブロックチェーンにインポートします。 このデータをオンチェーンに取り込むことで、dappsは現実世界の資産価格の変動、オフチェーンアプリのイベント、さらには天候の変化などの現実世界の現象に反応できるようになります。 +オラクルは、オフチェーンデータをパーミッションレスかつ分散型の方法でブロックチェーンにインポートします。 このデータをオンチェーンに取得することで、dAppsが現実世界の資産の価格変動、オフチェーンアプリのイベント、さらには天候の変化など、現実世界の現象に反応できるようになります。 #### バックグラウンドリーディング {#background-reading-18} @@ -377,11 +377,11 @@ lang: ja - [Wormholeの脆弱性報告書](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/) - [イーサリアムコントラクトのハッキング事後分析リスト](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) -- [Rekt News](https://twitter.com/RektHQ?s=20\&t=3otjYQdM9Bqk8k3n1a1Adg) +- [Rekt News](https://x.com/RektHQ?s=20&t=3otjYQdM9Bqk8k3n1a1Adg) #### 最近の研究 {#recent-research-19} -- [ethresear.chのアプリケーション](https://ethresear.ch/c/applications/18) +- [Ethresear.chアプリケーション](https://ethresear.ch/c/applications/18) ### テクノロジースタック {#technology-stack} diff --git a/public/content/translations/ja/community/support/index.md b/public/content/translations/ja/community/support/index.md index 1e6d1fa29e1..0af78c2d31a 100644 --- a/public/content/translations/ja/community/support/index.md +++ b/public/content/translations/ja/community/support/index.md @@ -1,30 +1,30 @@ --- -title: イーサリアムサポート -description: イーサリアムエコシステムにおけるサポート +title: "イーサリアムサポート" +description: "イーサリアムエコシステムにおけるサポート" lang: ja --- -# イーサリアムサポート {#support} +# イーサリアムのサポート {#support} ## イーサリアムの公式サポート {#official-support} イーサリアムの公式サポートをお探しの場合は、まず始めに、 イーサリアムは非集中的な分散型であるということをご理解ください。 イーサリアムは、中央組織、団体、または個人により所有されていないため、公式のサポートチャンネルはありません。 -「イーサリアムの公式サポート」を称する人物は、詐欺であるおそれがあります。このため、イーサリアムの分散型の性質をご理解ください。 詐欺師から身を守るには、自分自身で学び、セキュリティを真剣に受け止めることが何よりも大切です。 +イーサリアムの分散型の性質を理解することは極めて重要です。なぜなら、**イーサリアムの公式サポートを名乗る人は、おそらくあなたを騙そうとしているからです！**詐欺師に対する最良の防御は、自分自身を教育し、セキュリティを真剣に考えることです。 イーサリアムのセキュリティと詐欺対策 - イーサリアムの基礎知識を学ぶ + イーサリアムの基礎を学ぶ -公式サポートはありませんが、イーサリアムエコシステム全体で多くのグループ、コミュニティ、およびプロジェクトからサポートを受けることができます。このページに有用な情報やリソースを記載していますので、ご確認ください。 ご質問やご不明点がある場合は、 [ethereum.org Discord](https://discord.gg/ethereum-org)に参加すると、サポートできることがあると思います。 +公式サポートはありませんが、イーサリアムエコシステム全体で多くのグループ、コミュニティ、およびプロジェクトからサポートを受けることができます。このページに有用な情報やリソースを記載していますので、ご確認ください。 ご質問やご不明点がある場合は、 [ethereum.org Discord](https://discord.gg/ethereum-org)にご参加ください。私たちがサポートします。 ## よくある質問 {#faq} -### 間違ったウォレットにETHを誤送信してしまいましたが、どうすれば良いですか？ {#wrong-wallet} +### 間違ったウォレットにETHを送ってしまいました {#wrong-wallet} イーサリアムで送信されたトランザクションはもとに戻すことはできません。 間違ったウォレットにETHを送信してしまった場合、残念ながら、これらの資金を回収する方法はありません。 イーサリアムは、中央組織、団体、個人により所有されていないため、誰もトランザクションを取り消すことができません。 そのため、必ず送信前に細心の注意を払って、ダブルチェックを行ってください。 @@ -32,35 +32,35 @@ lang: ja イーサリアムをプレゼントするというものは、ETHを盗もうと企てる詐欺です。 うま過ぎる話しには騙されないでください。プレゼントを受け取ろうと、相手先のアドレスにETHを送金してしまった場合、プレゼントはもらえず、自分の資金を回収することもできません。 -[詐欺防止に関する詳細](/security/#common-scams) +[詐欺対策の詳細](/security/#common-scams) -### トランザクションが処理されず、止まってしまっていますがどうすれば良いですか？ {#stuck-transaction} +### トランザクションが保留中のままです {#stuck-transaction} イーサリアムのトランザクションは、必要とされるよりも低いトランザクションフィーを提示した場合、ネットワークの需要により、トランザクションが保留になってしまうことがあります。 多くのウォレットは、トランザクションが処理されるよう、トランザクションフィーの金額を上げて、同一トランザクションを再送信するオプションがあります。 もしくは、自分のアドレスにトランザクションを送信し、保留中のトランザクションと同じノンス (nonce)を使用することで、保留中のトランザクションをキャンセルすることができます。 -[MetaMaskのトランザクションを高速化またはキャンセルする方法](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction) +[MetaMaskで保留中のトランザクションを高速化またはキャンセルする方法](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction) [保留中のイーサリアムのトランザクションをキャンセルする方法](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/) ### イーサリアムのマイニング方法を教えてください {#mining-ethereum} -イーサリアムのマイニングはできなくなりました。 イーサリアムの[プルーフ・オブ・ワーク](/glossary/#pow)から[プルーフ・オブ・ステーク](/glossary/#pos)への移行に伴い、マイニングは停止されました。 現在は、マイナーの代わりとなるバリデータが活躍しており、 誰でもETHを[ステーキング](/glossary/#staking)することができ、ステーキング報酬はバリデータソフトウェアを立ち上げて、ネットワークのセキュリティを確保することで受け取れます。 +イーサリアムのマイニングはできなくなりました。 イーサリアムが[プルーフ・オブ・ワーク](/glossary/#pow)から[プルーフ・オブ・ステーク](/glossary/#pos)に移行した際、マイニングは停止されました。 現在は、マイナーの代わりとなるバリデータが活躍しており、 誰でもETHを[ステーク](/glossary/#staking)して、バリデータソフトウェアを実行しネットワークの安全を確保することで、ステーキング報酬を受け取ることができます。 ### ステーカーになる/バリデータを立ち上げる方法は？ {#how-to-stake} -バリデータになるには、イーサリアムのデポジットコントラクトに32ETHをステーキングし、バリデータノードを設定する必要があります。 詳細については、[ステーキングのページ](/staking)と[ステーキングランチパッド](https://launchpad.ethereum.org/)をご覧ください。 +バリデータになるには、イーサリアムのデポジットコントラクトに32ETHをステーキングし、バリデータノードを設定する必要があります。 詳細は、[ステーキングのページ](/staking)および[ステーキング・ローンチパッド](https://launchpad.ethereum.org/)でご覧いただけます。 -## 分散型アプリ(Dapp)の開発 {#building-support} +## dappsの構築 {#building-support} 開発では問題にぶち当たることもあります。 下記は、経験豊富なイーサリアムデベロッパーがいる、開発に特化したスペースです。 -- [Alchemy University](https://university.alchemy.com/#starter_code) +- [Alchemyユニバーシティ](https://university.alchemy.com/#starter_code) - [CryptoDevs discord](https://discord.com/invite/5W5tVb3) - [Ethereum StackExchange](https://ethereum.stackexchange.com/) -- [Web3 University](https://www.web3.university/) +- [Web3ユニバーシティ](https://www.web3.university/) - [LearnWeb3](https://discord.com/invite/learnweb3) -また、[イーサリアムデベロッパー向けリソース](/developers/)セクションには、ドキュメントや開発ガイドが掲載されています。 +私たちの[イーサリアムデベロッパー向けリソース](/developers/)セクションでも、ドキュメントや開発ガイドを見つけることができます。 ### ツール {#dapp-tooling} @@ -75,7 +75,7 @@ lang: ja - [Alchemy](http://alchemy.com/discord) - [Tenderly](https://discord.gg/fBvDJYR) -## ノードの運用 {#node-support} +## ノードの実行 {#node-support} ノードを実行している場合やバリデータの方は、下記のコミュニティでサポートを受けることができます。 @@ -99,5 +99,6 @@ lang: ja - [Lighthouse](https://discord.gg/cyAszAh) - [Teku](https://discord.gg/7hPv2T6) - [Lodestar](https://discord.gg/aMxzVcr) +- [Grandine](https://discord.gg/H9XCdUSyZd) -また、[ノードの運用方法についてはこちら](/developers/docs/nodes-and-clients/run-a-node/)をご覧ください。 +また、[こちらでノードの実行方法を学ぶ](/developers/docs/nodes-and-clients/run-a-node/)こともできます。 diff --git a/public/content/translations/ja/contributing/adding-desci-projects/index.md b/public/content/translations/ja/contributing/adding-desci-projects/index.md index a6c2474add2..967582d1e20 100644 --- a/public/content/translations/ja/contributing/adding-desci-projects/index.md +++ b/public/content/translations/ja/contributing/adding-desci-projects/index.md @@ -1,6 +1,6 @@ --- -title: DeSciプロジェクトの追加 -description: ethereum.orgのDeSciへージにプロジェクトのリンクを追加する際の掲載ポリシー +title: "DeSciプロジェクトの追加" +description: "ethereum.orgのDeSciページにプロジェクトへのリンクを追加する際に使用するポリシー" lang: ja --- @@ -10,7 +10,7 @@ lang: ja 誰でも自由にethereum.orgのDeSciページにプロジェクトの掲載を提案することができます。 同様に、関連が無くなってしまったり、掲載基準を満たさなくなってしまったプロジェクトについては、自由に削除を提案できます。 -## 基準のフレームワーク {#the-decision-framework} +## 意思決定のフレームワーク {#the-decision-framework} ### 掲載基準: 必須条件 {#the-must-haves} @@ -30,7 +30,7 @@ lang: ja - **サードパーティによる監査** - 製品が、信頼のあるサードパーティによって専門的に脆弱性が監査されていること。 - **問い合わせ窓口** - 変更が行われたときに正確な情報を得るには、プロジェクトの問い合わせ窓口(DAOやコミュニティの代表等)が非常に役立ちます。 今後の情報を収集する際に、ethereum.orgが常に最新で管理しやすい状態に保たれます。 -## メンテナンス {#maintenance} +## 保守性 {#maintenance} イーサリアムの流動的な性質により、チームと製品が現れては消え、イノベーションは毎日起こっています。そのため、下記のようなコンテンツの定期的なチェックを実施しています。 @@ -41,4 +41,4 @@ ethereum.orgは、オープンソースコミュニティによって維持さ ## 利用規約 {#terms-of-use} -[利用規約](/terms-of-use/)も参照してください。 ethereum.orgの情報は、一般的な情報提供のみを目的としています。 +当サイトの[利用規約](/terms-of-use/)も参照してください。 ethereum.orgの情報は、一般的な情報提供のみを目的としています。 diff --git a/public/content/translations/ja/contributing/adding-developer-tools/index.md b/public/content/translations/ja/contributing/adding-developer-tools/index.md index f3af23b46b0..ffeb8808fa6 100644 --- a/public/content/translations/ja/contributing/adding-developer-tools/index.md +++ b/public/content/translations/ja/contributing/adding-developer-tools/index.md @@ -1,7 +1,7 @@ --- -title: デベロッパー向けツールの追加 +title: "デベロッパー向けツールの追加" lang: ja -description: ethereum.orgデベロッパー向けツールへの掲載基準 +description: "ethereum.orgデベロッパー向けツールへの掲載基準" --- # デベロッパー向けツールの追加 {#contributing-to-ethereumorg-} @@ -14,48 +14,48 @@ description: ethereum.orgデベロッパー向けツールへの掲載基準 **掲載に適切なページと新しいツールの追加をご提案ください。** -## 掲載基準 {#ways-to-contribute} +## 決定方法 {#ways-to-contribute} 申請されたデベロッパー向けツールは、以下の基準に基づいて審査されます。 -**すでに掲載されているツールとの差別化** +**すでに掲載されているツールと有意義な差別化が図られていますか？** - 新しいカテゴリーまたは新しいツールの種類 - 既存の類似ツールにない新機能がある - 既存の類似ツールが未対応のユースケースを対象としている -**ドキュメントは十分に整備されているか** +**ツールのドキュメントは十分に整備されていますか？** - ドキュメントが存在する - ツールの利用に必要な情報が十分に記載されている - 最終更新日が最近である -**広く使われているツールであるか** +**そのツールは広く使用されていますか？** - GitHubのスター数、ダウンロード数、知名度の高い企業やプロジェクトで使用された実績などの指標を検討 -**ツールの信頼性は十分か** +**ツールの信頼性は十分ですか？** - 繰り返し発生しているバグがない - 信頼性の高いツールである - ツールが積極的にメンテナンスされている -**オープンソースになっているか** +**ツールはオープンソースですか？** 多くのイーサリアムプロジェクトはオープンソースです。 コミュニティのデベロッパーがコードを検証し、貢献できるよう、オープンソースのプロジェクトを掲載する傾向があります。 --- -## 掲載時の表示順序 {#product-ordering} +## プロダクト順序 {#product-ordering} アルファベット順など特に指定がない限り、製品はページに古いものから順に掲載されます。 つまり、新しい製品はリストの一番下に追加されます。 --- -## 追加方法 {#how-decisions-about-the-site-are-made} +## あなたのデベロッパー向けツールを追加する {#how-decisions-about-the-site-are-made} 本基準を満たしたツールのethereum.orgへの掲載をご希望の場合は、GitHubで問題を作成してください。 - 問題の作成 + イシューを作成 diff --git a/public/content/translations/ja/contributing/adding-exchanges/index.md b/public/content/translations/ja/contributing/adding-exchanges/index.md index 2ebcd8604a1..e36104e7c2e 100644 --- a/public/content/translations/ja/contributing/adding-exchanges/index.md +++ b/public/content/translations/ja/contributing/adding-exchanges/index.md @@ -1,6 +1,6 @@ --- -title: 取引所の追加 -description: ethereum.orgへの取引所の掲載ポリシー +title: "取引所の追加" +description: "ethereum.orgへの取引所の掲載ポリシー" lang: ja --- @@ -16,16 +16,16 @@ lang: ja このため、取引所の掲載の提案時には具体的な情報が必要となります。 -**注:** 分散型取引所をリストする際は、事前に [ウォレットと分散型アプリ(Dapp)の掲載ポリシー](/contributing/adding-products/)を参照してください。 +**注：**分散型取引所の掲載をご希望の場合は、[ウォレットとdappsの掲載ポリシー](/contributing/adding-products/)をご参照ください。 -## 必要な情報: {#what-we-need} +## 必要な情報 {#what-we-need} - 取引所に適用される地理的な制限. 取引所に関する地理的制限は、取引所のウェブサイトの専用ページまたはセクションに詳しく記述されているはずです。 - ETHの購入に使用できる通貨 - 取引所が合法な取引会社であることの証拠 - その他の追加情報(会社に関する営業年数、財政基盤などの) -これらは[ユーザが利用できる取引所を正しく見つけられるようにするため](/get-eth/#country-picker)に必要な情報です。 +この情報により、[ユーザーが利用できる取引所を見つける手助けを](/get-eth/#country-picker)正確に行うことができます。 また、取引所が合法かつ安全であることをethereum.orgが確認するためでもあります。 @@ -36,5 +36,5 @@ lang: ja ethereum.orgに取引所を追加掲載するには、GitHubで問題を作成してください。 - 問題の作成 +　イシューを作成 diff --git a/public/content/translations/ja/contributing/adding-glossary-terms/index.md b/public/content/translations/ja/contributing/adding-glossary-terms/index.md index c93aed24cf7..4236526addf 100644 --- a/public/content/translations/ja/contributing/adding-glossary-terms/index.md +++ b/public/content/translations/ja/contributing/adding-glossary-terms/index.md @@ -1,12 +1,12 @@ --- -title: 用語集への用語の追加 +title: "用語集への用語の追加" lang: ja -description: ethereum.org用語集に新しい用語を追加する基準 +description: "ethereum.org用語集に新しい用語を追加する基準" --- -# 用語集への用語の追加 {#contributing-to-ethereumorg-} +# 用語集の用語を追加する {#contributing-to-ethereumorg-} -この世界は日々変化しています。 イーサリアムでは常に新しい用語が生まれ続けるため、イーサリアムに関する正確で最新のリファレンスを提供できるよう、皆様のご協力が必要です。 最新の[用語集](/glossary/)をチェックし、ご貢献いただける場合は、以下を参照してください。 +この世界は日々変化しています。 イーサリアムでは常に新しい用語が生まれ続けるため、イーサリアムに関する正確で最新のリファレンスを提供できるよう、皆様のご協力が必要です。 現在の[用語集](/glossary/)を確認し、貢献したい場合は以下を参照してください。 ## 基準 {#criteria} @@ -17,10 +17,10 @@ description: ethereum.org用語集に新しい用語を追加する基準 - 用語/定義には広告や宣伝が含まれていない - 用語/定義はイーサリアムに直接関係する - 定義は客観的かつ正確で、主観的な判断や意見が含まれていない -- 情報源は信頼に足り、 出典が明記されている +- 情報源は信頼に足り、 出典の明記 --- -## 用語の追加 {#how-decisions-about-the-site-are-made} +## 用語を追加する {#how-decisions-about-the-site-are-made} -上記の基準を満たす用語の追加をご希望の場合は、 [GitHubで問題を作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml)してください +ethereum.orgに用語集の用語を追加したい場合で、その用語が基準を満たしている場合は、[GitHubでissueを作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml)してください。 diff --git a/public/content/translations/ja/contributing/adding-layer-2s/index.md b/public/content/translations/ja/contributing/adding-layer-2s/index.md index 9a8b1a8646b..00244e685dd 100644 --- a/public/content/translations/ja/contributing/adding-layer-2s/index.md +++ b/public/content/translations/ja/contributing/adding-layer-2s/index.md @@ -1,6 +1,6 @@ --- -title: レイヤー2の追加 -description: ethereum.orgへのレイヤー2の掲載ポリシー +title: "レイヤー2の追加" +description: "ethereum.orgへのレイヤー2の掲載ポリシー" lang: ja --- @@ -8,7 +8,7 @@ lang: ja ユーザーがレイヤー2を安全かつ自信を持ってナビゲートできるように、可能な限り最良のリソースをリストアップしたいと考えています。 -誰でも新たにレイヤー2のethereum.orgへの掲載を提案することができます。 不足しているレイヤー2がある場合は、**[こちらからご提案ください](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)**。 +誰でも新たにレイヤー2のethereum.orgへの掲載を提案することができます。 掲載されていないレイヤー2がありましたら、**[こちらから提案してください](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!** 現在、以下のページにレイヤー2を掲載しています。 @@ -18,14 +18,14 @@ lang: ja レイヤー2は、イーサリアムにとって比較的新しいエキサイティングなパラダイムです。 公正なフレームワークの作成を試みていますが、掲載基準は時間と共に変化し、進化する場合があります。 -## 基準のフレームワーク {#decision-framework} +## 意思決定のフレームワーク {#decision-framework} -### 掲載基準: 必須条件 {#criteria-for-inclusion-the-must-haves} +### 掲載基準：必須条件 {#criteria-for-inclusion-the-must-haves} **L2BEATへの掲載** -- 提案するプロジェクトが[L2BEAT](https://l2beat.com)に掲載されている必要があります (L2BEATは、レイヤー2プロジェクトを評価する堅固なリスクアセスメントを提供するため)。 **L2BEATで紹介されていない場合は、ethereum.orgにレイヤー2として掲載しません。** -- [L2BEATにレイヤー2プロジェクトを追加する方法](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md) +- 検討の対象となるには、このプロジェクトが[L2BEAT](https://l2beat.com)に掲載されている必要があります。 (L2BEATは、レイヤー2プロジェクトを評価する堅固なリスクアセスメントを提供するため)。 **プロジェクトがL2BEATで紹介されていない場合、ethereum.orgではL2として掲載しません。** +- [L2プロジェクトをL2BEATに追加する方法](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md)。 **オープンソース** @@ -38,11 +38,11 @@ lang: ja - オプティミスティック・ロールアップ - ゼロ知識ロールアップ -_データの可用性やセキュリティにイーサリアムを使用しない、その他のスケーリング・ソリューションはレイヤー2とは見なしていません。_ +_データの可用性やセキュリティにイーサリアムを使用しない他のスケーリングソリューションは、レイヤー2とは見なしません。_ **イーサリアムによるデータ可用性** -- データ可用性は、他のスケーリング・ソリューションとレイヤー2を区別する重要な差別化要因であり、 掲載にあたっては、データ可用性にイーサリアムメインネットの使用は**必須**となります。 +- データ可用性は、他のスケーリング・ソリューションとレイヤー2を区別する重要な差別化要因であり、 掲載対象として検討されるには、プロジェクトはデータ可用性のためにイーサリアムメインネットを**必ず**使用しなければなりません。 **ブリッジ** @@ -88,10 +88,10 @@ _データの可用性やセキュリティにイーサリアムを使用しな - 任意のウォレットがネイティブにレイヤー2に対応していること。 -## レイヤー2の追加 {#add-exchange} +## あなたのレイヤー2を追加 {#add-exchange} ethereum.orgにレイヤー2の追加をご希望の場合は、GitHubで問題を作成してください。 - 問題の作成 +　イシューを作成 diff --git a/public/content/translations/ja/contributing/adding-products/index.md b/public/content/translations/ja/contributing/adding-products/index.md index bd08df4489a..e9f64fa2304 100644 --- a/public/content/translations/ja/contributing/adding-products/index.md +++ b/public/content/translations/ja/contributing/adding-products/index.md @@ -1,12 +1,12 @@ --- -title: イーサリアムプロダクトの追加 -description: ethereum.orgへの分散型アプリ(Dapp)の掲載ポリシー +title: "イーサリアムプロダクトの追加" +description: "ethereum.orgへの分散型アプリ(Dapp)の掲載ポリシー" lang: ja --- -# イーサリアムプロダクトの追加 {#adding-products} +# イーサリアム製品の追加 {#adding-products} -誰でもethereum.orgの適切なページへ新しい分散型アプリ(Dapp)の掲載を提案できます。 **なお、ホームページには分散型アプリ(Dapp)を掲載することはありません**😜 +誰でもethereum.orgの適切なページへ新しい分散型アプリ(Dapp)の掲載を提案できます。 **いいえ、ホームページにあなたのdappを掲載することはありません** 😜 分散型アプリ(Dapp)は、以下に掲載されます。 @@ -17,9 +17,9 @@ lang: ja 新たな追加はもちろん歓迎しますが、現在記載されている分散型アプリ(Dapp)は、私たちが実現しようとしているユーザーエクスペリエンスに沿うもののみを選択しています。 以下のようなデザイン原理に基づきます。 -- _新規性_: ethereum.org上のものすべて、インスピレーションを与える、何か新しいものを提供する -- _良いストーリー_: ひらめきを与えるような「アハ体験」を提供する -- _信頼性_: ユーザへのリスクを最小化するため、すべての企業/プロジェクトの合法性 +- _新規性_: ethereum.org上のものはすべて、ユーザーに新しい何かを提供するべきです +- _良いストーリー_: 掲載されるものは「アハ体験」を提供するべきです +- _信頼性_: ユーザーへのリスクを最小化するため、すべて合法的なビジネスやプロジェクトであるべきです 全体的に**ethereum.orgは、新規ユーザーに「シームレスなオンボーディング体験」を提供したいと考えています**。 そのため、以下の点に基づいて分散型アプリ(Dapp)を追加しています。 @@ -30,30 +30,30 @@ lang: ja 基準のフレームワークについて、下記に詳細を記載します。 意見や変更すべき点をお聞かせください。 -## 基準のフレームワーク {#decision-framework} +## 意思決定のフレームワーク {#decision-framework} -### 掲載基準: 必須条件 {#criteria-for-inclusion-the-must-haves} +### 掲載基準：必須条件 {#criteria-for-inclusion-the-must-haves} - **セキュリティテストがされていること** – 監査、内部セキュリティチーム、またはその他の方法を問わず、確実に製品のセキュリティが検証されていること。 ユーザーへのリスクが軽減されると同時に、セキュリティを真剣に受け止めている証拠となります。 -- **6か月以上「稼働」していること** - セキュリティの1つの指標で、 6か月間は重大なバグや脆弱性の発見に適度な期間です。 -- **アクティブなチームによる活動** - 品質を確保することと、ユーザーが質問に対するサポートを得るのに役立ちます。 -- **情報の誠実性および正確さ** - プロジェクトが記載するすべての内容は、誠実で正確な情報が含まれること。 虚偽の情報が含まれる、例えば、実際にはそうではないのに製品を「オープンソース」と定義している場合は、製品の記載は削除となります。 +- **6か月以上「稼働」している製品であること** – これはセキュリティのもう一つの指標です。 6か月間は重大なバグや脆弱性の発見に適度な期間です。 +- **活発なチームによって開発されていること** – これにより品質が保証され、ユーザーは問い合わせに対するサポートを得ることができます。 +- **誠実かつ正確な掲載情報** - プロジェクトから提案される掲載情報には、誠実かつ正確な情報が含まれていることが求められます。 虚偽の情報が含まれる、例えば、実際にはそうではないのに製品を「オープンソース」と定義している場合は、製品の記載は削除となります。 -### ランキング基準: 任意項目 {#criteria-for-ranking-the-nice-to-haves} +### ランキング基準：推奨条件 {#criteria-for-ranking-the-nice-to-haves} ある分散型アプリ(Dapp)が、ethereum.orgであまり目立たずに掲載されているのは、次の基準によるものです。 -**分散型アプリ(Dapp)** +**Dapps** -- **掲載されているウォレットの大半を通してアクセス可能** – 掲載を希望する分散型アプリ(Dapp)が、ethereum.orgに掲載されているウォレットの大半で動作すること。 -- **ユーザー自身で試せること –** 個々のユーザーが、その分散型アプリ(Dapp)を使用でき、具体的な何かを達成できること。 -- **オンボーディング** – 製品にユーザーを支援し教育するオンボーディングエクスペリエンスがあること。 もしくは、記事や動画などの使用方法コンテンツのエビデンスがあること。 +- **掲載されているウォレットの大半からアクセスできること** – dappsは、ethereum.orgに掲載されている大半のウォレットで動作すること。 +- **ユーザー自身で試せること –** 個々のユーザーがそのdappを使用して、何か具体的なことを達成できること。 +- **オンボーディング** – 製品には、ユーザーの支援と教育を目的とした、よく設計されたオンボーディング体験があること。 もしくは、記事や動画などの使用方法コンテンツのエビデンスがあること。 - **ノンカストディアル** – ユーザーが自分の資金を管理すること。 製品がなくなっても、ユーザーは引き続き資金にアクセスして移動できること。 -- **グローバルにアクセス可能** – 製品に特定の人々がサービスにアクセスすることを除外する地理的制限や本人確認要件がないこと。 -- **オープンソース** – コードはアクセス可能で、より広いコミュニティからPRを受け入れること。 -- **コミュニティ** – Discordなどの専用コミュニティがあり、ユーザーがチームから支援を受けたり、新しい機能を提案したりできること。 +- **グローバルにアクセス可能** – 製品に、特定の人々がサービスにアクセスすることを妨げる、地理的制限やKYC (本人確認) 要件がないこと。 +- **オープンソース** – コードがアクセス可能であり、より広範なコミュニティからのPRを受け入れること。 +- **コミュニティ** – Discordなどの専用コミュニティがあり、ユーザーがチームと交流してサポートを受けたり、新機能を提案したりできること。 -## 基準の実践 {#criteria-in-practice} +## 基準の運用 {#criteria-in-practice} より多くの基準を満たせば満たすほど、製品がethereum.orgに掲載されやすくなります。 @@ -68,33 +68,33 @@ lang: ja これはethereum.orgによるデザインの決定となります。 -ですが、**より多くの分散型アプリ(Dapp)をランク付けする他のウェブサイトへのリンクがあります**ので、ご安心ください。 +ですがご安心ください。**より多くのdappsをランク付けしている他のウェブサイトへのリンクがあります** -### 掲載時の表示順序 {#product-ordering} +### プロダクト順序 {#product-ordering} アルファベット順など特に指定がない限り、製品はページに古いものから順に掲載されます。 つまり、新しい製品はリストの一番下に追加されます。 ### 利用規約 {#terms-of-use} -[利用規約](/terms-of-use/)も参照してください。 ethereum.orgの情報は、一般的な情報提供のみを目的としています。 +[利用規約](/terms-of-use/)もご参照ください。 ethereum.orgの情報は、一般的な情報提供のみを目的としています。 -## メンテナンス {#maintenance} +## 保守性 {#maintenance} イーサリアムの流動的な性質により、チームと製品が現れては消え、イノベーションは毎日起こっています。そのため、下記のようなコンテンツの定期的なチェックを実施しています。 - 掲載されている分散型アプリ(Dapp)のすべてが、引き続き基準を満たしているかどうかの確認 - 現在掲載されている製品よりも、多くの基準を満たす製品の提案がないかの確認 -上記の確認にご協力ください。 [イシューを作成するか](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)[website@ethereum.org](mailto:website@ethereum.org)へメールでお知らせください。 +上記の確認にご協力ください。 [issueを作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)するか、[website@ethereum.org](mailto:website@ethereum.org)にメールを送信してください -_コミュニティーが好みの製品や最高の製品を推奨できるよう、投票できるオプションの導入についても検討しています。_ +_コミュニティが好みの製品や最高の製品を推奨できるよう、投票できるオプションの導入についても検討しています。_ --- ## 製品の追加 {#add-your-product} -本基準を満たした分散型アプリ(Dapp)のethereum.orgへの掲載をご希望の場合は、GitHubでイシューを作成してください。 +ethereum.orgにdappを追加したいとお考えで、そのdappが基準を満たしている場合は、お知らせください。 - 問題の作成 + アプリを提案 diff --git a/public/content/translations/ja/contributing/adding-resources/index.md b/public/content/translations/ja/contributing/adding-resources/index.md new file mode 100644 index 00000000000..553f010b167 --- /dev/null +++ b/public/content/translations/ja/contributing/adding-resources/index.md @@ -0,0 +1,53 @@ +--- +title: "リソースの追加" +description: "ethereum.orgにリソースを追加する時のポリシー" +lang: ja +--- + +# リソースの追加 {#adding-resources} + +ユーザーの安全と信用を保ちながら、可能な限り最善のリソースを掲載したいと考えています。 + +現在[ethereum.org/resources](/resources/)上にあるethereum.orgのリソースダッシュボードに、誰でも自由に新しいリソース追加を提案することができます。 + +新たな追加はもちろん歓迎しますが、今あるリソースは私達がユーザーに提供しようとしている体験に基づいて厳選されています。 以下のようなデザイン原理に基づきます。 + +- _新規性_: ethereum.org上のものはすべて、ユーザーに新しい何かを提供するべきです +- _良いストーリー_: 掲載されるものは「アハ体験」を提供するべきです +- _信頼性_: ユーザーへのリスクを最小化するため、すべて合法的なビジネスやプロジェクトであるべきです + +全般的に**ethereum.orgは、新規ユーザーに円滑なオンボーディング体験を提供することを目標にしています**。 そのため、以下の点に基づいてリソースを追加しています： + +- 使いやすさ +- 正確性 +- 保守性 + +## 意思決定のフレームワーク {#decision-framework} + +### 基準 {#criteria} + +- **誠実で正確な情報の掲載** - 提案されるすべての掲載内容は、誠実で正確な情報から来なくてはなりません。 情報を捏造するプロダクトは取り除かれます。 +- **活発的なプロジェクト** – リソースは、質の担保とユーザーのサポートをする為に、活動的なチームによって維持されるべきです。 情報の古いリソースは除去の対象です。 + +### プロダクト順序 {#product-ordering} + +私達は(掲載される)プロダクトの影響度に基づいて、順序を並べ替える権利を保持します。 新しいプロダクトは、特に指定がない限り、基本的には一覧の最後に追加されます。 + +## 保守性 {#maintenance} + +イーサリアムのエコシステムが進化するに伴い、私たちは定期的に以下の点でコンテンツの精査を行います： + +- 掲載されているリソースのすべてが、引き続き基準を満たしているかどうかの確認 +- 現在掲載されている製品よりも、多くの基準を満たす製品の提案がないかの確認 + +上記の確認にご協力ください。 [イシューの報告](https://github.com/ethereum/ethereum-org-website/issues/new?template=bug_report.yaml) もしくは [website@ethereum.org](mailto:website@ethereum.org)へEメール。 + +--- + +## あなたのリソースを追加 {#add-your-resource} + +本基準を満たしたリソースをethereum.orgに掲載することをご希望の場合は、GitHubでイシューを作成してください。 + + +　イシューを作成 + diff --git a/public/content/translations/ja/contributing/adding-staking-products/index.md b/public/content/translations/ja/contributing/adding-staking-products/index.md index 2a79c563a69..8c0c299d76f 100644 --- a/public/content/translations/ja/contributing/adding-staking-products/index.md +++ b/public/content/translations/ja/contributing/adding-staking-products/index.md @@ -1,28 +1,28 @@ --- -title: ステーキングの製品・サービスの追加 -description: ethereum.orgへのステーキング製品・サービスの掲載ポリシー +title: "ステーキングの製品・サービスの追加" +description: "ethereum.orgへのステーキング製品・サービスの掲載ポリシー" lang: ja --- -# ステーキングの製品・サービスの追加 {#adding-staking-products-or-services} +# ステーキング製品・サービスの追加 {#adding-staking-products-or-services} ユーザーの安全と信用を保ちながら、可能な限り最善のリソースを掲載したいと考えています。 -誰でも新たにステーキングの製品・サービスのethereum.orgへの掲載を提案することができます。 もし、不足している製品・サービスがあれば、**[こちらからご提案](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)ください**。 +誰でも新たにステーキングの製品・サービスのethereum.orgへの掲載を提案することができます。 掲載されていない製品・サービスがある場合、**[こちらから提案してください](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!** 現在、以下のページにステーキングの製品・サービスを掲載しています。 - [ソロステーキング](/staking/solo/) -- [ステーキングサービス](/staking/saas/) +- [ステーキング・アズ・ア・サービス](/staking/saas/) - [ステーキングプール](/staking/pools/) ビーコンチェーンのプルーフ・オブ・ステークは、2020年12月1日から稼働しています。 ステーキングは比較的まだ新しいものですが、ethereum.orgで判断するために、公平で透明なフレームワークの作成を心掛けました。しかし、掲載基準は時間の経過とともに変更となることがあり、最終的にはethereum.orgウェブサイトチームの裁量に委ねられています。 -## 基準のフレームワーク {#the-decision-framework} +## 意思決定のフレームワーク {#the-decision-framework} ethereum.orgへの製品の掲載は、1つの要因で決められるものではありません。 製品やサービスの掲載を決定する際には、複数の基準で総合的に判断が行われます。 満たす基準が多いほど、掲載される可能性が高くなります。 -**初めに、製品・サービスに該当するカテゴリーをご確認ください。** +**まず、製品またはサービスのカテゴリーはどれですか？** - ノードまたはクライアントツール - 鍵の管理 @@ -35,50 +35,50 @@ ethereum.orgへの製品の掲載は、1つの要因で決められるもので ステーキング製品・サービスの基準: -**プロジェクト・サービスのローンチ時期** +**プロジェクトまたはサービスはいつローンチされましたか？** - プロダクト・サービスの公開時期を示す証拠の有無。 - これは製品の「実環境でのバトルテスト」スコアを決定するために使用されます。 -**積極的なメンテナンス** +**プロジェクトは積極的にメンテナンスされていますか？** - プロジェクト開発をしているアクティブなチームや従事者の有無 。 - アクティブにメンテナンスされている製品のみが検討の対象となります。 -**トラストレスまたは人間の仲介者が必要ない製品・サービス** +**製品またはサービスは、信頼できる仲介者や人的な仲介者を介さずに利用できますか？** - ユーザージャーニーのどの段階で、人間がユーザー資金への鍵を保有したり、報酬を適切に分配する必要があるか。 - これは製品・サービスの「トラストレス」スコアを決定するために使用されます。 -**プロジェクトが正確で信頼できる情報を提供** +**プロジェクトは正確で信頼できる情報を提供していますか？** - 特に製品がイーサリアムプロトコルまたはその他の関連テクノロジーに関係するならば、その製品のウェブサイトで最新で正確、誤解を招かない情報を掲載することが重要です。 - 提出されたものに、誤情報、古い詳細情報、イーサリアムに対して誤解を与える可能性のある記述を含んでいると掲載されないか、すでに掲載されている場合は削除されます。 -**対応プラットフォーム** +**どのプラットフォームがサポートされていますか？** -- 例: Linux、macOS、Windows、iOS、Android +- すなわち、Linux、macOS、Windows、iOS、Android -#### ソフトウェアおよびスマートコントラクト {#software-and-smart-contracts} +#### ソフトウェアとスマートコントラクト {#software-and-smart-contracts} カスタムソフトウェアまたはスマートコントラクト関連: -**すべてオープンソース** +**すべてオープンソースですか？** - オープンソースプロジェクトであり、かつ公開されているソースコードリポジトリが必要。 - これは製品の「オープンソース」スコアを決定するために使用されます。 -**_ベータ_開発を終了済み** +**製品は_ベータ_開発を完了していますか？** - 製品の開発サイクルはどの段階か。 - ベータ段階の製品は、ethereum.orgに掲載されません。 -**外部セキュリティ監査** +**ソフトウェアは外部セキュリティ監査を受けていますか？** - まだの場合は、外部監査を受ける予定の有無。 - これは製品の「監査」スコアを決定するために使用されます。 -**バグ報奨プログラム** +**プロジェクトにはバグ報奨金プログラムがありますか？** - なければ、セキュリティに関するバグ報奨を設定する計画の有無。 - これは製品の「バグ報奨」スコアを決定するために使用されます。 @@ -87,31 +87,31 @@ ethereum.orgへの製品の掲載は、1つの要因で決められるもので ノードまたはクライアントのセットアップ、管理、移行に関するソフトウェア製品: -**どのコンセンサスレイヤークライアント ( Lighthouse、Teku、Nimbus、Prysm)をサポートしているか。** +**どのコンセンサスレイヤークライアント（例：Lighthouse、Teku、Nimbus、Prysm、Grandine）がサポートされていますか？** - 対応しているクライアント、 ユーザーの選択の可否。 - これは製品の「マルチクライアント」スコアを決定するために使用されます。 -#### ステーキングサービス {#staking-as-a-service} +#### ステーキング・アズ・ア・サービス {#staking-as-a-service} -[ステーキング・アズ・ア・サービス](/staking/saas/)(ノード運用の委任)関連: +[ステーキング・アズ・ア・サービス](/staking/saas/)の掲載（すなわちノード運用の委任）について： -**サービスの利用料金** +**サービスの利用にはどのような手数料がかかりますか？** -- 料金構成、たとえばサービスに月額料金が設定されているか。 +- 料金体系はどのようになっていますか？（例：サービスの月額料金はありますか？） - その他のステーキング要件の有無。 -**ユーザーによるアカウント・サインアップの必要性** +**ユーザーはアカウント登録が必要ですか？** - パーミッションレスまたはKYC無しでのサービス利用可否。 - これは製品の「パーミッションレス」スコアを決定するために使用されます。 -**署名鍵と引き出し鍵の保有者** +**署名鍵と出金鍵は誰が保有していますか？** - ユーザーが常に維持する鍵、 サービスがアクセスする鍵の種類。 - これは製品の「トラストレス」スコアを決定するために使用されます。 -**運用されているノードのクライアントの多様性** +**運用されているノードにおけるクライアントの多様性はどの程度ですか？** - マジョリティのコンセンサス レイヤー(CL)クライアントによって実行されているバリデータ鍵の割合 - 最新の編集時点で、Prysmがノードオペレータのマジョリティで稼働中のコンセンサスレイヤークライアントとなっており、ネットワークにとって危険な状況を呈しています。 そのためCLクライアントが現在ネットワークの33%以上で使用されている場合、使用率に関するデータが必要となります。 @@ -119,29 +119,29 @@ ethereum.orgへの製品の掲載は、1つの要因で決められるもので #### ステーキングプール {#staking-pool} -[ステーキングプールサービス](/staking/pools/): +[プール型ステーキングサービス](/staking/pools/)の場合： -**ステーキングに必要な最小ETH** +**ステーキングに必要な最小ETH額はいくらですか？** -- 例: 0.01ETH +- 例：0.01 ETH -**関連する手数料またはステーキング要件** +**どのような手数料やステーキング要件がありますか？** - 報酬のうち、手数料として取られる割合。 - その他のステーキング要件の有無。 -**流動性トークン** +**流動性トークンはありますか？** - 関係するトークン、 仕組み、 コントラクトアドレス。 - これは製品の「流動性トークン」スコアを決定するのに使用されます。 -**ノードオペレーターとしてのユーザー参加可否** +**ユーザーはノードオペレーターとして参加できますか？** - プール資金を利用したバリデータクライアントの実行要件。 - 個人、会社、分散型自律組織(DAO)からのパーミッションの必要有無。 - これは製品の「パーミッションレスノード」スコアを決定するために使用されます。 -**プールノードオペレーターのクライアントの多様性** +**プールノードオペレーターのクライアントの多様性はどの程度ですか？** - マジョリティのコンセンサス レイヤー(CL)クライアントを実行しているノードオペレーターの割合。 - 最新の編集時点で、Prysmがノードオペレータのマジョリティで稼働中のコンセンサスレイヤークライアントとなっており、ネットワークにとって危険な状況を呈しています。 そのためCLクライアントが現在ネットワークの33%以上で使用されている場合、使用率に関するデータが必要となります。 @@ -149,28 +149,28 @@ ethereum.orgへの製品の掲載は、1つの要因で決められるもので ### その他の基準: 任意項目 {#other-criteria} -**対応ユーザーインターフェース:** +**どのユーザーインターフェースがサポートされていますか？** -- 例: ブラウザアプリ、デスクトップアプリ、モバイルアプリ、CLI +- すなわち、ブラウザアプリ、デスクトップアプリ、モバイルアプリ、CLI -**ノードツールの場合、ソフトウェアがクライアントを簡単に切り替える方法を提供しているか。** +**ノードツールの場合、ソフトウェアはクライアントを簡単に切り替える方法を提供していますか？** - ユーザーは、ツールを使用して簡単かつ安全にクライアントを変更できるか。 -**SaaSの場合、サービスで現在運用されているバリデータ数** +**SaaSの場合、現在そのサービスによって運用されているバリデーター数はいくつですか？** - これはサービスの到達度の判断に使用されます。 -## 結果の算出方法 {#product-ordering} +## 結果の表示方法 {#product-ordering} 上記の[掲載基準](#criteria-for-inclusion)をもとに、各製品・サービスの累積スコアを算出します。 これは、一定の客観的基準を満たした製品の掲載と掲載順を決める手段として使われます。 証拠が提供された基準が多ければ、製品の表示順序が上がります。同点の場合は、ロード時にランダムで表示されます。 -これらの基準のコードのロジックと重みは、現在リポジトリの [JavaScriptコンポーネント](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350)にあります。 +これらの基準のコードロジックと重みは、現在、リポジトリ内の[このJavaScriptコンポーネント](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350)に含まれています。 ## 製品・サービスの追加 {#add-product} ethereum.orgにステーキング製品の追加をご希望の場合は、GitHubでイシューを作成してください。 - 問題の作成 +　イシューを作成 diff --git a/public/content/translations/ja/contributing/adding-wallets/index.md b/public/content/translations/ja/contributing/adding-wallets/index.md index 7e8620b88df..017798cdff5 100644 --- a/public/content/translations/ja/contributing/adding-wallets/index.md +++ b/public/content/translations/ja/contributing/adding-wallets/index.md @@ -1,6 +1,6 @@ --- -title: ウォレットの追加 -description: ethereum.orgへのウォレットの掲載ポリシー +title: "ウォレットの追加" +description: "ethereum.orgへのウォレットの掲載ポリシー" lang: ja --- @@ -16,65 +16,65 @@ lang: ja イーサリアムのウォレットは、急速に変化しています。 公正なフレームワークの作成を試みていますが、掲載基準は時間と共に変化し、進化する場合があります。 -## 基準のフレームワーク {#the-decision-framework} +## 意思決定のフレームワーク {#the-decision-framework} ### 掲載基準: 必須条件 {#the-must-haves} -- **セキュリティテストがされていること** - 監査、内部セキュリティチーム、オープンソースのコード、またはその他のどの方法であれ、ウォレットのセキュリティが信頼できること。 ユーザーへのリスクが軽減されると同時に、セキュリティを真剣に受け止めている証拠となります。 -- **ウォレットが半年以上「稼働」しているか、実績の評判が良いグループによってリリースされていること** - これもセキュリティの指標です。 半年は重大なバグや脆弱性の発見に適度な期間です。 プロジェクトとして、即座に破棄されたフォークを除外するのに半年をお願いしています。 -- **アクティブなチームによる活動** - 品質を確保し、ユーザーが質問に対するサポートを得られるようにすることに役立ちます。 -- **情報の誠実性および正確さ** - プロジェクトが記載するすべての内容は、誠実で正確な情報が含まれること。 虚偽の情報が含まれる、例えば、実際にはそうではないのに製品を「オープンソース」と定義している場合、製品は削除されます。 -- **問い合わせ窓口** - 変更が行われたときに正確な情報を得るには、ウォレットの問い合わせ窓口が非常に役立ちます。 今後の情報を収集する際に、ethereum.orgが常に最新で管理しやすい状態に保たれます。 -- **EIP-1559 (タイプ2) トランザクション** - ウォレットがメインネットのイーサリアムのトランザクションでEIP-1559 (タイプ2) トランザクションをサポートしていること。 -- **優れたユーザーエクスペリエンス** - ユーザーエクスペリエンスは主観的ですが、コアメンバーの何人かが製品をテストして、使いにくいと感じた場合、私たちはウォレットの掲載を拒否する権利を有しており、代わりに改善に役立つ提案をします。 これは、主に初心者で構成される私たちのユーザーベースを保護するためです。 +- **セキュリティテスト済みの製品であること** - 監査、内部セキュリティチーム、オープンソースのコード、その他の方法を問わず、ウォレットのセキュリティは信頼できるものでなければなりません。 ユーザーへのリスクが軽減されると同時に、セキュリティを真剣に受け止めている証拠となります。 +- **ウォレットが半年以上「稼働」している、または信頼できる実績のあるグループによってリリースされていること** - これはセキュリティのもう一つの指標です。 半年は重大なバグや脆弱性の発見に適度な期間です。 プロジェクトとして、即座に破棄されたフォークを除外するのに半年をお願いしています。 +- **活発なチームによって開発されていること** - これにより、品質が保証され、ユーザーは問い合わせに対するサポートを得ることができます。 +- **誠実かつ正確な掲載情報** - プロジェクトから提案される掲載情報には、誠実かつ正確な情報が含まれていることが求められます。 虚偽の情報が含まれる、例えば、実際にはそうではないのに製品を「オープンソース」と定義している場合、製品は削除されます。 +- **問い合わせ窓口** - ウォレットの問い合わせ窓口があると、変更が行われた際に私たちが正確な情報を得る上で非常に役立ちます。 今後の情報を収集する際に、ethereum.orgが常に最新で管理しやすい状態に保たれます。 +- **EIP-1559 (タイプ2) トランザクション** - ウォレットがイーサリアムメインネット上のトランザクションで、EIP-1559 (タイプ2) トランザクションをサポートしていること。 +- **優れたユーザーエクスペリエンス** - UXは主観的なものですが、複数のコアチームメンバーが製品をテストして使いにくいと判断した場合、私たちはそのウォレットの掲載を拒否する権利を留保し、代わりに改善のための有益な提案を行います。 これは、主に初心者で構成される私たちのユーザーベースを保護するためです。 +- **イーサリアムに特化していること** - ウォレットは、イーサリアムに特化した主要なエクスペリエンスを提供する必要があります。 これは、イーサリアム (またはいずれかのL2) がデフォルトのネットワークとして設定され、ERCアセットが適切にサポートされ、機能がイーサリアムエコシステムに沿っていることを意味します。 UIで代替のレイヤー1を優先するウォレットは掲載されません。 ### 製品の削除 {#product-removals} -- **更新情報** -ウォレットプロバイダーは、半年ごとにウォレットの情報を再送信する責任があります(製品に変更がない場合でも必要です)。これにより、提供された情報の正当性と関連性を確保します。 製品チームがこれを怠った場合、ethereum.orgはページから該当の製品を削除することがあります。 +- **情報の更新** - ウォレットの提供者は、提供された情報の有効性と関連性を確保するため、6か月ごとにウォレット情報を再提出する責任があります (製品に変更がない場合でも)。 製品チームがこれを怠った場合、ethereum.orgはページから該当の製品を削除することがあります。 ### その他の基準: 任意項目 {#the-nice-to-haves} -- **グローバルにアクセス可能** - ウォレットに、特定の人々がサービスにアクセスすることを除外する地理的制限や本人確認要件がないこと。 -- **複数の言語で利用可能** - ウォレットが複数の言語で翻訳されており、世界中のユーザーがアクセスできること。 -- **オープンソース** - プロジェクト全体のコードベース (モジュールだけではない) にアクセスでき、より広いコミュニティからPRを受け入れられること。 -- **ノンカストディアル** - ユーザーが自分の資金を管理すること。 製品がなくなっても、ユーザーは引き続き資金にアクセスして移動できること。 -- **ハードウェアウォレットのサポート** - ユーザーがトランザクションを署名するためにハードウェアウォレットを接続できること。 -- **ウォレット接続** - ユーザーがウォレット接続を利用してDappに接続できること。 -- **イーサリアムRPCのインポート** - ユーザーが、ノードのRPCデータをインポートして、選択したノードまたは他のEVM互換のネットワークに接続できること。 -- **NFT** - ユーザーが、ウォレットにあるNFTを表示したり、やり取りができること。 -- **イーサリアムアプリケーションへの接続** - ユーザーが、イーサリアムアプリケーションに接続および使用できること。 -- **ステーキング** - ユーザーが、ウォレットを通して直接ステーキングができること。 -- **スワップ** - ユーザーが、ウォレットを通してトークンをスワップできること。 -- **マルチチェーンネットワーク** - ユーザーが複数のブロックチェーンネットワークにデフォルトでアクセスすることを、ウォレットがサポートしていること。 -- **レイヤー2ネットワーク** - ユーザーがレイヤー2ネットワークにアクセスすることを、デフォルトでウォレットがサポートしていること。 -- **ガス代のカスタマイズ** - ユーザーが、ウォレットでトランザクションのガス代をカスタマイズできること (ベースフィー、プライオリティフィー、最大フィー)。 -- **ENSのサポート** - ウォレットでユーザーがENS名を使ったトランザクションの送信ができること。 -- **ERC-20サポート** - ウォレットでユーザーがERC-20トークンコントラクトをインポートしたり、ERC-20トークンのクエリや表示を自動で実行したりできること。 -- **暗号資産の購入** - ユーザーが暗号資産を直接購入して開始することを、ウォレットがサポートしていること。 -- **法定通貨での売却** - ユーザーが直接カードや銀行口座に法定通貨で売却や引き出しを行うことを、ウォレットがサポートしていること。 -- **マルチシグ** - ウォレットがトランザクションの署名にマルチシグによる署名をサポートしていること。 -- **ソーシャルリカバリー** - ウォレットがガーディアンをサポートしており、シードフレーズを失くしてしまった場合、ユーザーはこれらのガーディアンを使ってウォレットを回復できること。 -- **専任のサポートチーム** - ウォレットに専任のサポートチームがあり、問題があった場合にユーザーがサポートを受けられること。 -- **教育リソースまたはドキュメント** - 製品にユーザーを支援し教育するオンボーディングエクスペリエンスがあること。 もしくは、記事や動画などの使用方法コンテンツのエビデンスがあること。 +- **グローバルにアクセス可能であること** - ウォレットに、特定の人々がサービスにアクセスできなくなるような地理的制限やKYC要件がないこと。 +- **複数の言語で利用可能であること** - ウォレットが複数の言語に翻訳されており、世界中のユーザーがアクセスできること。 +- **オープンソースであること** - プロジェクト全体のコードベース (モジュールだけでなく) にアクセス可能で、より広範なコミュニティからのPRを受け入れること。 +- **ノンカストディアルであること** - ユーザーが自身の資金を管理すること。 製品がなくなっても、ユーザーは引き続き資金にアクセスして移動できること。 +- **ハードウェアウォレットをサポートしていること** - ユーザーがハードウェアウォレットを接続してトランザクションに署名できること。 +- **WalletConnect** - ユーザーがWalletConnectを使ってdappsに接続できること。 +- **イーサリアムRPCエンドポイントのインポートが可能であること** - ユーザーがノードのRPCデータをインポートし、任意のノードや他のEVM互換ネットワークに接続できること。 +- **NFT** - ユーザーがウォレット内で自身のNFTを表示し、操作できること。 +- **イーサリアムアプリケーションへの接続** - ユーザーがイーサリアムアプリケーションに接続して使用できること。 +- **ステーキング** - ユーザーがウォレットを通じて直接ステーキングできること。 +- **スワップ** - ユーザーがウォレットを通じてトークンをスワップできること。 +- **マルチチェーンネットワーク** - ウォレットが、ユーザーが複数のブロックチェーンネットワークにデフォルトでアクセスすることをサポートしていること。 +- **レイヤー2ネットワーク** - ウォレットが、ユーザーがレイヤー2ネットワークにデフォルトでアクセスすることをサポートしていること。 +- **ガス代のカスタマイズ** - ウォレットで、ユーザーがトランザクションのガス代 (ベースフィー、プライオリティフィー、最大フィー) をカスタマイズできること。 +- **ENSのサポート** - ウォレットで、ユーザーがENS名宛にトランザクションを送信できること。 +- **ERC-20のサポート** - ウォレットで、ユーザーがERC-20トークンコントラクトをインポートしたり、ERC-20トークンを自動的に照会・表示したりできること。 +- **暗号資産の購入** - ウォレットが、ユーザーによる暗号資産の直接購入と利用開始をサポートしていること。 +- **法定通貨での売却** - ウォレットが、ユーザーによるカードまたは銀行口座への法定通貨での直接売却および出金をサポートしていること。 +- **マルチシグ** - ウォレットが、トランザクションに署名するための複数署名をサポートしていること。 +- **ソーシャルリカバリー** - ウォレットがガーディアンをサポートしており、ユーザーがシードフレーズを紛失した場合に、これらのガーディアンを使ってウォレットを復元できること。 +- **専任のサポートチーム** - ウォレットに専任のサポートチームがあり、ユーザーが問題に直面した際に相談できること。 +- **教育リソース/ドキュメント** - 製品に、ユーザーを支援し教育するための、よく設計されたオンボーディング体験があること。 もしくは、記事や動画などの使用方法コンテンツのエビデンスがあること。 ## ウォレットの追加 {#adding-a-wallet} ethereum.orgにウォレットの追加をご希望の場合は、GitHubでイシューを作成してください。 - 問題の作成 +　イシューを作成 -## メンテナンス {#maintenance} +## 保守性 {#maintenance} イーサリアムの流動的な性質により、チームと製品が現れては消え、イノベーションは毎日起こっています。そのため、下記のようなコンテンツの定期的なチェックを実施しています。 - 掲載されているウォレットと分散型アプリ(Dapp)のすべてが、引き続き基準を満たしているかどうかの確認 - 現在掲載されている製品よりも、多くの基準を満たす製品の提案がないかの確認 -ethereum.orgは、オープンソースコミュニティによって維持されており、最新の状態に保つためにコミュニティの力を借りています。 掲載されているウォレットに関する情報に更新が必要であることに気付いた場合は、 [イシューを作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml)するか[プルリクエスト](https://github.com/ethereum/ethereum-org-website/pulls)をしてください！ - +ethereum.orgはオープンソースコミュニティによって維持されており、私たちはこれを最新の状態に保つためにコミュニティの協力に頼っています。 掲載されているウォレットに関する情報で更新が必要なものにお気づきの場合は、[issueを立てる](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml)か、[プルリクエスト](https://github.com/ethereum/ethereum-org-website/pulls)を送信してください！ ## 利用規約 {#terms-of-use} -[利用規約](/terms-of-use/)も参照してください。 ethereum.orgの情報は、一般的な情報提供のみを目的としています。 +当サイトの[利用規約](/terms-of-use/)も参照してください。 ethereum.orgの情報は、一般的な情報提供のみを目的としています。 diff --git a/public/content/translations/ja/contributing/content-resources/index.md b/public/content/translations/ja/contributing/content-resources/index.md index b4cbcb02fa9..2597c134f00 100644 --- a/public/content/translations/ja/contributing/content-resources/index.md +++ b/public/content/translations/ja/contributing/content-resources/index.md @@ -1,7 +1,7 @@ --- -title: コンテンツリソースの追加 +title: "コンテンツリソースの追加" lang: ja -description: ethereum.orgへのコンテンツリソースの掲載基準 +description: "ethereum.orgへのコンテンツリソースの掲載基準" --- # コンテンツリソースの追加 {#adding-content-resources} @@ -10,7 +10,7 @@ description: ethereum.orgへのコンテンツリソースの掲載基準 ページに追加した方が良いと感じるコンテンツリソースがある場合は、適切な場所でご提案ください。 -## 審査基準 {#how-we-decide} +## 決定方法 {#how-we-decide} 学習リソースは以下の基準に基づいて審査されます。 @@ -19,14 +19,14 @@ description: ethereum.orgへのコンテンツリソースの掲載基準 - 情報の正確さ、 事実に基づくまたは意見に基づくものか - 信用できる著者、 出典の明記 - 既存のリソースやリンクがカバーしていないコンテンツで、明確な価値を加えるコンテンツ -- [ユーザーペルソナ](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c)にとって有用なコンテンツ +- このコンテンツは、私たちの[ユーザーペルソナ](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c)のいずれかに役立ちますか？ --- -## コンテンツリソースの追加 {#add-your-content-resource} +## あなたのコンテンツリソースを追加 {#add-your-content-resource} 本基準を満たしたコンテンツのethereum.orgへの掲載をご希望の場合は、GitHubで問題を作成してください。 - 問題の作成 +　イシューを作成 diff --git a/public/content/translations/ja/contributing/design-principles/index.md b/public/content/translations/ja/contributing/design-principles/index.md index 0c36bdde26a..19a736d63f0 100644 --- a/public/content/translations/ja/contributing/design-principles/index.md +++ b/public/content/translations/ja/contributing/design-principles/index.md @@ -1,45 +1,45 @@ --- -title: デザイン原則 +title: "デザイン原則" lang: ja -description: ethereum.orgのデザインとコンテンツに関する原則 +description: "ethereum.orgのデザインとコンテンツに関する原則" --- -# デザイン原則 {#contributing-to-ethereumorg-} +# 私たちのデザイン原則 {#contributing-to-ethereumorg-} - ethereum.orgのデザイン原則へようこそ。 これは、ethereum.orgを進化させ、改善するための継続的なプロセスの一環となるものです。 + こんにちは。ethereum.orgのデザイン原則へようこそ。 これは、ethereum.orgを進化させ、改善するための継続的なプロセスの一環となるものです。 本原則は、サイトの見た目、雰囲気、掲載するコンテンツに関するものです。 -[ethereum.orgへの貢献にあたって、まずはこちら](/contributing/)を読んでください。 +[ethereum.orgに貢献する](/contributing/)前に、こちらをお読みください。 ## デザイン原則とは {#ways-to-contribute} -とてもシンプルですので、ご心配は無用です! **デザイン原則**とは、何かをデザイン(作成、メンテナンス、更新)する上での一連のガイドラインです。 +とてもシンプルですので、ご心配は無用です! **デザイン原則**とは、何かをデザイン(作成、維持、更新など)する際に参照する一連のガイドラインです。 -ethereum.orgでは、本デザイン原則は、ウェブサイトを表現し、世界へと発信するための基礎となるものです。 向上的**かつ**機能的な原則です。 ウェブサイトが_どう見えるか_だけでなく、_どう機能するか_、さらには_どう感じられるか_、色からページのレイアウト、ウェブサイト上でイーサリアムについての説明方法など、すべてが本原則に基づく必要があります。 +ethereum.orgでは、本デザイン原則は、ウェブサイトを表現し、世界へと発信するための基礎となるものです。 それらは意欲的なものであると**同時に**、機能的なものでもあります。 ウェブサイトがどう_見えるか_だけでなく、どう_機能するか_、さらには人にどう_感じさせるか_。色からページのレイアウト、ウェブサイト上でイーサリアムについて語る方法まで、すべてがこれらの原則に沿って行われるべきです。 ## 原則の実践 {#how-decisions-about-the-site-are-made} -例を見てみましょう。 原則の1つは「信頼性」です。訪問者に、より広いイーサリアムのエコシステム同様、本サイトが信頼に値すると_感じてもらい_、_知ってもらう_ことです。 この原則の中に、3つの機能的な「副原則」があり、本サイトを信頼に足るものにするための実用的なステップです。 +例を見てみましょう。 原則の一つに「信頼性」があります。これは、サイトの訪問者に、より広範なイーサリアムエコシステムと同様に、このサイトが信頼できるものであると_感じ_、そして_知って_もらうことを意味します。 この原則の中に、3つの機能的な「副原則」があり、本サイトを信頼に足るものにするための実用的なステップです。 -- _「フレッシュ」_: コンテンツを最新の状態に保つこと。 -- _「ソーシャルプルーフ」_: エコシステム(イーサリアムのアップグレード進捗、ゲーム、すべてのハッカソンなど)の規模、多様性、活動性を示すこと。 -- _「一貫性」_: サイトのデザイン、文章のトーンや正確さに一貫性があること。 +- _「フレッシュ」_、つまりコンテンツを常に最新の状態に保つことです。 +- _「ソーシャルプルーフ」_、つまり、エコシステムの規模、多様性、活発さを示すことです(例えば、イーサリアムのアップグレードの進捗、DeFi、ゲーム、あらゆるハッカソンなど)。 +- _「一貫性」_、つまり、サイトのデザイン、文章のトーンや正確さにおける一貫性です。 デザインやコピーライティングの決定時に、「信頼性」の原則に沿うものかどうかを検討します。 -- _「サイトに最新の情報が反映されているか」_ -- _「エコシステムの規模や活動を、どこでどのように見せているか」_ -- _「コミュニティメンバーの新しい投稿案は、現在のサイトのデザインや文章と整合性が取れているか」_ +- _「サイトには最新の情報が反映されているか？」_ +- _「エコシステムの規模や活発さを、どこでどのように示しているか？」_ +- _「レビュー中のコミュニティメンバーによる新しい貢献案は、サイトの現在のデザインや記述と一貫しているか？」_ ## ethereum.orgのデザイン原則 {#contributors} -### 1. インスピレーション {#1-inspirational} +### 1. インスピレーションを与える {#1-inspirational} イーサリアムがどのように世界を変えるのか、ユーザーにとってインスピレーションを与えるようなサイトにする必要があります。 イーサリアムのエコシステムのツールやアプリを探求し、遊び、試してみる動機付けとなるものです。 -- **ラディカル:** 世界を有意義なものに変えるというイーサリアムの野心的な目標を伝えるもの。 イーサリアムは単なる新しい技術スタックではなく、変革をもたらす技術であるということを明らかにする必要があります。 -- **教育によるエンパワーメント: **人々がイーサリアムの可能性を理解し、エコシステムの中で自分の位置を見つけ、それに参加するようにエンパワーメントするようなサイト。 +- **ラディカル:** 世界を意義ある形に変えるというイーサリアムの野心的な目標を伝えるサイトであるべきです。 イーサリアムは単なる新しい技術スタックではなく、変革をもたらす技術であるということを明らかにする必要があります。 +- **教育によるエンパワーメント:** サイトは人々を教育し、イーサリアムの可能性を理解し、エコシステムにおける自分の居場所を見つけ、エコシステムへの参加意欲を高めるものでなければなりません。 ビジュアルディレクション・コンテンツ @@ -47,18 +47,18 @@ ethereum.orgでは、本デザイン原則は、ウェブサイトを表現し イーサリアムはグローバルで非中央集権的なプロジェクトであり、これはサイトの閲覧者にも表れています。 誰もが利用でき、世界のさまざまな文化に配慮したサイトにすることを目指しています。 -- **アクセス可能: **低帯域幅の接続を持つ人々を含め、アクセシビリティのガイドラインに従っていること。 -- **分かりやすい: **シンプルで曖昧さがないこと。 コピーには誤解を招いたり、不明瞭な言葉を使わないこと。 -- **多面性: ** イーサリアムはプロジェクトであり、コードベースであり、コミュニティであり、そしてビジョンです。 イーサリアムは使う人によって異なる理由で価値があり、さまざまな関わり方がある多面性を配慮する必要があります。 +- **アクセシビリティ:** サイトは、低帯域幅の接続を利用している人々を含め、アクセシビリティのガイドラインに従うべきです。 +- **分かりやすさ:** サイトはシンプルで、曖昧さがないべきです。 コピーには誤解を招いたり、不明瞭な言葉を使わないこと。 +- **イーサリアムは多面的:** イーサリアムはプロジェクトであり、コードベースであり、コミュニティであり、ビジョンでもあります。 イーサリアムは使う人によって異なる理由で価値があり、さまざまな関わり方がある多面性を配慮する必要があります。 -ライティングシステム・色使い・ビジュアルディレクション・コンテンツ +ライティングシステム • 色使い • ビジュアルディレクション • コンテンツ -### 3. 良いストーリー性 {#3-a-good-story} +### 3. 優れたストーリー {#3-a-good-story} ウェブサイトは、良いストーリーのようにあるべきです。 訪問者のジャーニーの途中に、あなたが貢献するコンテンツがあります。 貢献するコンテンツは、明確なストーリーに沿ったものになるよう、始まり(導入/書き出し)、中間(学習と洞察)、締めくくり(関連リソースへのリンク、または次のステップ)が必要です。 -- **階層的**: 明確で階層的に構造化された情報アーキテクチャは、ethereum.orgの訪問者が目的を達成するためにサイトを「物語として」ナビゲートするのに効果的です。 -- **足掛かり: **私たちは、答えを探している人の足掛かり的な存在です。 すでに存在する多くのリソースに取って代わったり、その代わりになることは望まず、 答えを与え、確実な次のステップを提供することを意図します。 +- **階層的**: 明確で階層的に構造化された情報アーキテクチャは、ethereum.orgの訪問者が目的を達成しようとする際に、サイトを「物語として」ナビゲートするのに役立ちます。 +- **足がかり:** 私たちは、答えを探しているすべての人にとっての足がかりです。 すでに存在する多くのリソースに取って代わったり、その代わりになることは望まず、 私たちは答えを提示し、信頼できる次のステップを提供します。 ユーザージャーニー・コンテンツ @@ -66,28 +66,28 @@ ethereum.orgでは、本デザイン原則は、ウェブサイトを表現し イーサリアムのエコシステムを始めようとしている人もいれば、懐疑的な人もいます。 その責任を認識した上で、コミュニケーションをとり、 イーサリアムのエコシステムがより大きな信頼を得られるようにします。 -- **フレッシュ: **常に最新の情報を提供。 -- **ソーシャルプルーフ: **エコシステムの規模、多様性、活動を提示。 -- **一貫性: ** デザインとコンテンツの一貫性は、信頼性につながります。 +- **鮮度:** 常に最新であること。 +- **ソーシャルプルーフ:** エコシステムの規模、多様性、活発さを示します。 +- **一貫性:** デザインとコンテンツにおける一貫性は、信頼性を伝えます。 -ビジュアルディレクション ・コンテンツ +ビジュアルディレクション・コンテンツ -### 5. コラボレーションによる改善 {#5-collaborative-improvement} +### 5. 協調的な改善 {#5-collaborative-improvement} 本ウェブサイトは、エコシステム全体がそうであるように、多くの貢献者の成果物です。 -- **オープン: ** エコシステム全体におけるソースコード、プロセス、プロジェクトの透明性。 -- **拡張性: ** モジュラリティは、私たちが行うすべてにある重要な焦点であり、貢献もまたモジュラー式であるべきと考えています。 本サイトのコアとなるデザイン、コンポーネントコード、実装は、将来の拡張を容易にするものである必要があります。 -- **実験的: **常に実験、テスト、反復を繰り返しています。 -- **コラボレーション: **プロジェクトは、私たち全員の力を結集したものです。 -- **サステナブル: **コミュニティが長期的にメンテナンスできるように考慮します。 +- **オープン:** エコシステム全体のソースコード、プロセス、プロジェクトの透明性を称賛します。 +- **拡張性:** モジュール性は、私たちが行うすべてのことの核となる焦点であり、貢献もモジュール式であるべきです。 サイトのコアデザイン、コンポーネントコード、実装は、将来的に容易に拡張できるものでなければなりません。 +- **実験的:** 私たちは常に実験、テスト、反復を繰り返しています。 +- **協調的:** このプロジェクトは、私たち全員を結びつけます。 +- **持続可能性:** コミュニティによる長期的なメンテナンスのために設定します。 -本デザイン原理は、[サイト全体に](/)反映されています。 +私たちのデザイン原則が[サイト全体](/)で実践されているのを見ることができます。 -## フィードバック {#give-feedback} +## フィードバックを送る {#give-feedback} -**本ドキュメントに関するフィードバックをお聞かせください。** 私たちが提案する原則の1つは「**コラボレーションによる改善**」で、このウェブサイトが多くの貢献者の成果となることを希望しています。 その精神に則り、本デザイン原則をイーサリアムコミュニティと共有します。 +**このドキュメントに関するフィードバックをお寄せください！** 私たちが提案する原則の一つは「**協調的な改善**」であり、これはウェブサイトを多くの貢献者の産物にしたいという私たちの願いを意味します。 その精神に則り、本デザイン原則をイーサリアムコミュニティと共有します。 -本原則はethereum.orgのウェブサイトに焦点を当てていますが、その多くがイーサリアムエコシステム全体の価値を表すことを望んでいます。 ご自由にこれらの一部を自分のプロジェクトに取り入れてみてください。 +これらの原則はethereum.orgウェブサイトに焦点を当てていますが、その多くがイーサリアムエコシステム全体の価値観を代表するものであることを願っています。 ご自由にこれらの一部を自分のプロジェクトに取り入れてみてください。 -[Discordサーバー](https://discord.gg/ethereum-org)か[イシューを作成して](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)ご意見をお聞かせください。 +[Discordサーバー](https://discord.gg/ethereum-org)で、または[issueを作成する](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=)ことで、ご意見をお聞かせください。 diff --git a/public/content/translations/ja/contributing/design/adding-design-resources/index.md b/public/content/translations/ja/contributing/design/adding-design-resources/index.md index d3231e542e2..8610e68894b 100644 --- a/public/content/translations/ja/contributing/design/adding-design-resources/index.md +++ b/public/content/translations/ja/contributing/design/adding-design-resources/index.md @@ -1,12 +1,12 @@ --- -title: デザインリソースの追加 -description: ethereum.orgのデザイン素材の品質を保証するためのガイドラインと要件 +title: "デザインリソースの追加" +description: "ethereum.orgのデザイン素材の品質を保証するためのガイドラインと要件" lang: ja --- # デザインリソースの追加 {#adding-design-resources} -誰でも[Web3ページのデザインとUX](/developers/docs/design-and-ux/)に新しいデザイン素材を提案できます。 +誰でも[Web3のデザインとUXページ](/developers/docs/design-and-ux/)に新しいデザイン素材を提案できます。 ユーザー価値を意欲的なWeb3デザイナーに提供することにこのページは焦点を当てています。 デザインセクションは、サービス、製品、プラットフォームを宣伝することが目的ではありません。 @@ -48,7 +48,7 @@ c. 文章は簡潔かつ要領を得たものである必要があります。 a. 記事の主な目的は、特定のプロジェクトや企業を宣伝することではなく、洞察を共有することです。 -## コミュニティおよびDAO {#Communities-and-DAOs} +## コミュニティ / DAO {#Communities-and-DAOs} 1. ウェブサイトにDAOおよびコミュニティへの参加方法が明確に示されている必要がある @@ -56,7 +56,7 @@ a. 記事の主な目的は、特定のプロジェクトや企業を宣伝す a. メンバーになるベネフィットが明確に示されている必要があります。 -**例**: 作品に関するフィードバックを受け取れる、雇用機会へのアクセスや報奨金、デザインやリサーチにおける洞察の共有等 +**例**：作品へのフィードバックの受け取り、雇用機会や報奨金へのアクセス、デザインやリサーチにおけるインサイトの共有。 3. Discordでの活発で活気のあるコミュニケーション diff --git a/public/content/translations/ja/contributing/design/index.md b/public/content/translations/ja/contributing/design/index.md index 7385a1e88f6..6206821cf15 100644 --- a/public/content/translations/ja/contributing/design/index.md +++ b/public/content/translations/ja/contributing/design/index.md @@ -1,10 +1,10 @@ --- -title: デザインでの貢献 -description: ethereum.orgにデザインで貢献する +title: "デザインでの貢献" +description: "ethereum.orgにデザインで貢献する" lang: ja --- -# ethereum.orgにデザインで貢献する {#design-contributions} +# ethereum.orgへのデザインの貢献 {#design-contributions} デザインは、どのプロジェクトにおいても重要な要素です。あなたの時間とデザインスキルをethereum.orgに費やすことで、ethereum.orgの訪問者のユーザーエクスペリエンスの向上に貢献できます。 オープンソースプロジェクトに貢献することで、関連する経験を積むことができ、コラボレーション環境の中でスキルを得ることができます。 それぞれ独自な視点や洞察を持った他のデザイナー、デベロッパー、コミュニティメンバーと一緒に働く機会が得られます。 @@ -12,15 +12,15 @@ lang: ja ## 貢献方法 -###  初期デザインプロトタイプにフィードバックを提供する {#design-critique} +###  初期デザインプロトタイプへのフィードバックの提供 {#design-critique} 未開発のアイデアをテストするのに助けが必要になることがあります。 技術的な知識を必要とせずに貢献ができる素晴らしい方法です。 -1. デザインチームは、モックアップデザインを[Discord](https://discord.com/invite/ethereum-org)と[GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)で共有します。 +1. デザインチームは、[Discord](https://discord.com/invite/ethereum-org)と[GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)でモックアップデザインを共有します。 2. コメント機能でフィードバックを提供することでデザインを成功に導きます。 3. 結果はGitHubのイシューで共有され、その後チームによってクローズされます。 -###  調査研究に参加する {#answer-surveys} +###  アンケート調査への参加 {#answer-surveys} 次の方法でウェブサイトにフィードバックを提供することができます。 @@ -28,28 +28,28 @@ lang: ja 2. ページの最後の右端にあるフィードバックウィジェットをクリックし、デザインやコンテンツ関連の質問に回答します。 3. 自由形式の質問に詳細に回答します。 -###  ウェブサイトでデザイン関連の問題を見つけ報告する {#report-design-issues} +###  ウェブサイトでデザイン関連の問題を見つけて報告する {#report-design-issues} ethereum.orgは急速に成長しているウェブサイトで、沢山の機能とコンテンツがあります。 UIのいくつかは、すぐに時代遅れになり改善が必要になります。 そのような状況を見つけた場合、私たちにお知らせください。 1. デザインに注目して、ウェブサイトを確認します。 2. 視覚またはUXの問題があれば、スクリーンショットとメモを取ります。 -3. [bug report](https://github.com/ethereum/ethereum-org-website/issues/new/choose)を使って、見つけた問題を報告します。 +3. 見つかった問題は、[バグレポート](https://github.com/ethereum/ethereum-org-website/issues/new/choose)を使用して報告してください。 -###  デザイン変更を提案する {#propose-design-changes} +###  デザイン変更の提案 {#propose-design-changes} -デザインの課題に気軽に挑戦したいならば、GitHubのイシューボードを訪れて[デザイン関連のイシュー](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)でフィルターしてみてください。 +デザインの課題に取り組むことに抵抗がなければ、GitHubのissuesボードにアクセスし、[デザイン関連のissues](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)で絞り込むことができます。 -1. デザインに注目してウェブサイトを確認するか、GitHubリポジトリに行き、 [「Design required」タグ](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)でフラグ付けされたイシューをレビューします。 -2. 解決策を考えてデザインします (私たちの[デザインシステム](https://www.figma.com/community/file/1134414495420383395)を使うことが理想的です)。 -3. 対応しているGitHubイシューまたは[新しいイシューを作成し](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request)解決策を提案します。 +1. 当サイトのデザインに注意を払うか、GitHubリポジトリにアクセスして[「Design required」タグ](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8)が付いたissuesを確認してください。 +2. 解決策を考えてデザインします (理想的には、当サイトの[デザインシステム](https://www.figma.com/community/file/1134414495420383395)を使用してください)。 +3. 対応するGitHub issueで解決策を提案するか、[新規に作成してください。](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request) 4. デザインチームがレビューするのを待ってください。 ###  デザインシステムを一緒に構築する {#Contribute-to-design-system} 私たちのデザインシステムを使うとethereum.orgのデザインが楽しく簡単にできます。 経験豊富なデザイナーの皆さんは、ウェブサイトで使う豊富なコンポーネントの用意を手伝うことができます。 -1. GitHubの[design systemのボード](https://github.com/ethereum/ethereum-org-website/labels/design%20system)からイシューを選ぶか、新しいイシューを作成します。 +1. GitHubの[デザインシステムボード](https://github.com/ethereum/ethereum-org-website/labels/design%20system)から取り組むissueを選択するか、新規に作成してください。 2. 選んだイシューが自分にアサインされるようにリクエストをします。 3. Figmaでリクエストしたコンポーネントのデザインを開始します。 4. レビューやガイダンスが必要になった時点でGitHubでデザインチームに共有してください。 @@ -58,10 +58,10 @@ ethereum.orgは急速に成長しているウェブサイトで、沢山の機 ###  ウェブサイトにデザイン関連のコンテンツを執筆する {#write-design-articles} -イーサリアムのデベロッパーコミュニティは強力ですが、デザインコミュニティはわずかに遅れをとっています。 web3の知識のあるデザイナーならば、学んだことをより大きなコミュニティと共有することを考えてくれませんか。私たちと一緒に成長と改善をできるようにしていきましょう。[イーサリアムのデザインページ](/developers/docs/design-and-ux/)があり、そこへ貢献することができます。 [掲載ポリシー](/contributing/design/adding-design-resources)もご確認ください。 +イーサリアムのデベロッパーコミュニティは強力ですが、デザインコミュニティはわずかに遅れをとっています。 Web3の知識をお持ちのデザイナーの方は、コミュニティ全体で共に成長・改善できるよう、ぜひご自身の学びを共有してください。当サイトには、ご協力いただける[イーサリアムのデザインに関するページ](/developers/docs/design-and-ux/)があります。 当サイトの[掲載ポリシー](/contributing/design/adding-design-resources)もご確認いただけます。 1. ethereum.org上で扱うべきデザイナーにとって有益になるようなデザイントピックのアイデアを考えます。 -2. GitHubリポジトリへ行き、[イシューを作成して](https://github.com/ethereum/ethereum-org-website/issues/new)トピックを提案します(コンテンツはまだ書かないでください) 。 +2. GitHubリポジトリにアクセスし、トピックを提案する[issueを作成してください](https://github.com/ethereum/ethereum-org-website/issues/new)（コンテンツはまだ執筆しないでください）。 3. デザインチームが承認するのを待ちます。 4. 承認されれば、コンテンツを執筆できます。 5. 関連するGitHubイシューにコンテンツを提出します。 @@ -71,7 +71,7 @@ ethereum.orgは急速に成長しているウェブサイトで、沢山の機 視覚化は、抽象的なトピックを説明するのに役立つ最も強力なツールの1つです。 図やインフォグラフィックスを加えることで、大きな可能性が生じます。 何と言っても、1つの画像が千の言葉に勝ることがあります。 1. ウェブサイトに行き、新しいインフォグラフィックスを追加できるページを確認します。 -2. イラストのスタイルが必ず[アセット](/assets/)に対応するようにします。 -3. GitHubリポジトリへ行き、[イシューを作成して](https://github.com/ethereum/ethereum-org-website/issues/new)イラストを提案します。 +2. イラストのスタイルが、当サイトの[アセット](/assets/)と一致していることを確認してください。 +3. GitHubリポジトリにアクセスし、イラストを提案する[issueを作成してください](https://github.com/ethereum/ethereum-org-website/issues/new)。 4. デザインチームがレビューをします。 5. 私たちが新しいイシューを作成して、デベロッパーに新しいイメージを実装するよう依頼します。 diff --git a/public/content/translations/ja/contributing/index.md b/public/content/translations/ja/contributing/index.md index 0003c148d54..8ddc83dd97a 100644 --- a/public/content/translations/ja/contributing/index.md +++ b/public/content/translations/ja/contributing/index.md @@ -1,46 +1,51 @@ --- -title: 貢献 -description: ethereum.orgに貢献できる様々な方法 +title: "貢献" +description: "ethereum.orgに貢献できる様々な方法" lang: ja --- -# ethereum.orgへの貢献🦄 {#contributing-to-ethereumorg} +# ethereum.orgへの貢献 🦄 {#contributing-to-ethereumorg} -ethereum.orgは、オープンソースで運営されているプロジェクトで、**12,000人以上**のコントリビューターが翻訳、執筆、デザイン、保守を行っているウェブサイトです。 +Ethereum.orgはオープンソースで運営されているプロジェクトで、**12,000人以上**のコントリビューターがウェブサイトの翻訳、執筆、デザイン、保守を支援しています。 私たちは友好的なコミュニティで、イーサリアムエコシステム内であなたの成長と学習を支援し、あなたは有意義に貢献して関連する実践的な経験を得ることができます。 -## 貢献の方法 {#ways-to-contribute} +## 貢献する方法 {#ways-to-contribute} **翻訳** -- [翻訳プログラムへの参加](/contributing/translation-program/) – 新しい言語へのethereum.orgの翻訳を支援する + +- [翻訳プログラムに参加する](/contributing/translation-program/) – ethereum.orgの多言語化にご協力ください **開発** -- [未解決のイシューに取り組む](https://github.com/ethereum/ethereum-org-website/issues) – 必要と判断されたタスク + +- [オープンなIssueに取り組む](https://github.com/ethereum/ethereum-org-website/issues) – 私たちが特定した、対応が必要な作業 **デザイン** -- [ウェブサイトのデザインの支援](/contributing/design/) – あらゆるレベルのデザイナーがウェブサイトの改善に貢献できる + +- [ウェブサイトのデザインを手伝う](/contributing/design/) – あらゆるレベルのデザイナーがウェブサイトの改善に貢献できます **コンテンツ** -- [コンテンツの作成/編集](/contributing/#how-to-update-content) – 新しいページを提案するか、すでにあるものに手を加える -- [コミュニティリソースの追加](/contributing/content-resources/) – 関連ページに役立つ記事やリソースを追加する -- [デザインリソースの提案](/contributing/design/adding-design-resources/) – 有用なデザインリソースを追加、更新、削除する -- [用語の追加](/contributing/adding-glossary-terms/) – イーサリアム[用語集](/glossary/)の継続的な拡張を支援する -- [クイズ](/contributing/quizzes/) – 関連するページのクイズ問題集の内容に追加、更新、削除を行う + +- [コンテンツの作成/編集](/contributing/#how-to-update-content) – 新しいページを提案したり、既存のコンテンツを微調整したりする +- [コミュニティリソースを追加する](/contributing/content-resources/) – 関連ページに役立つ記事やリソースを追加する +- [デザインリソースを提案する](/contributing/design/adding-design-resources/) – 役立つデザインリソースを追加、更新、削除する +- [クイズ](/contributing/quizzes/) – 関連ページのクイズ問題集を追加、更新、削除する **機能のアイデア** -- [機能のリクエスト](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – 新しい機能やデザインに関するアイデアを知らせる + +- [機能をリクエストする](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – 新機能やデザインに関するアイデアをお知らせください **製品リスト** -- [取引所の追加](/contributing/adding-exchanges/) – [取引所を探す](/get-eth/#country-picker)に取引所を追加する -- [製品の追加](/contributing/adding-products/) – 関連ページに分散型アプリ(Dapp)やウォレットを追加する -- [デベロッパーツールの追加](/contributing/adding-developer-tools/) – 関連ページにデベロッパーツールを追加する -- [レイヤー2の追加](/contributing/adding-layer-2s/) – 関連ページにレイヤー2を追加する -- [ステーキング製品やサービスの追加](/contributing/adding-staking-products/) – ソロステーキング、プールステーキング、またはステーキング・アズ・ア・サービスを促進するプロジェクトを追加する -- [ウォレットの追加](/contributing/adding-wallets/) – [ウォレットを探すページ](/wallets/find-wallet/)にウォレットを追加する -- [分散型サイエンス(DeSci)ページのプロジェクトの提案](/contributing/adding-desci-projects/) – 分散型サイエンスに貢献するイーサリアム上のプロジェクトを追加する -ご質問はありますか？ 🤔 そうならば[Discordサーバー](https://discord.gg/ethereum-org)に参加してください！ +- [取引所を追加する](/contributing/adding-exchanges/) – 私たちの[取引所検索](/get-eth/#country-picker)に取引所を追加する +- [プロダクトを追加する](/contributing/adding-products/) – 関連ページにdappやウォレットを追加する +- [開発者ツールを追加する](/contributing/adding-developer-tools/) – 関連ページに開発者ツールを追加する +- [レイヤー2を追加する](/contributing/adding-layer-2s/) – 関連ページにレイヤー2を追加する +- [ステーキングプロダクトまたはサービスを追加する](/contributing/adding-staking-products/) – ソロステーキング、プールステーキング、またはステーキング・アズ・ア・サービスを促進するプロジェクトを追加する +- [ウォレットを追加する](/contributing/adding-wallets/) – [ウォレット検索ページ](/wallets/find-wallet/)にウォレットを追加する +- [DeSciページのプロジェクトを提案する](/contributing/adding-desci-projects/) – 分散型サイエンスに貢献する、イーサリアム上で構築されたプロジェクトを追加する + +ご質問はありますか？ 🤔 私たちの[Discordサーバー](https://discord.gg/ethereum-org)に参加しましょう ## 貢献を始めるのに適した最初のタスク @@ -48,68 +53,68 @@ ethereum.orgは、オープンソースで運営されているプロジェク -すべてのタスクを確認する +すべてのタスクを見る -## ethereum.orgでの活動方法 {#how-to-update-content} +## ethereum.orgでの作業方法 {#how-to-update-content} -[翻訳プログラム](/contributing/translation-program/)で貢献したい場合は、[Crowdin](https://crowdin.com/project/ethereum-org)でアカウントを作成してください。 その他、具体的にはコンテンツやビジュアルの追加や編集、バグの修正、オープンされているタスクに取り組みたい場合などは、[GitHub](https://github.com/)アカウントが必要になります。 +[翻訳プログラム](/contributing/translation-program/)への貢献を希望される場合は、[Crowdin](https://crowdin.com/project/ethereum-org)でアカウントを作成してください。 その他のすべて – ウェブサイトへのコンテンツやビジュアルの追加や編集、バグの修正、オープンなタスクへの取り組みなど – には[GitHub](https://github.com/)アカウントが必要です。 -すべてのアップデートは、GitHubのPRプロセスを通して行われます。 つまり、ウェブサイトのローカルコピーを作成し、変更を加え、更新するようリクエストします。 初めての場合は、[GitHubリポジトリ](https://github.com/ethereum/ethereum-org-website)の一番下にある説明に従ってください。 +すべてのアップデートは、GitHubのPRプロセスを通して行われます。 つまり、ウェブサイトのローカルコピーを作成し、変更を加え、更新するようリクエストします。 このような作業が初めての場合は、私たちの[GitHubリポジトリ](https://github.com/ethereum/ethereum-org-website)の最後にある指示に従ってください。 作業するのに許可は必要ありませんが、何をするつもりなのかお知らせください。 これは次の方法で行うことができます。 -- [GitHub](https://github.com/ethereum/ethereum-org-website)の問題やPRにコメントする -- [Discordサーバー](https://discord.gg/ethereum-org)にメッセージを送る +- [GitHub](https://github.com/ethereum/ethereum-org-website)のIssueやPRにコメントする +- 私たちの[Discordサーバー](https://discord.gg/ethereum-org)でメッセージを送る 貢献するにあたって、以下のことを確認してください。 -- 進化する[ethereum.orgのビジョン](/about/) -- [デザイン原則](/contributing/design-principles/) -- [スタイルガイド](/contributing/style-guide/) -- [行動規範](/community/code-of-conduct) +- 進化し続ける[ethereum.orgのビジョン](/about/) +- 私たちの[デザイン原則](/contributing/design-principles/) +- 私たちの[スタイルガイド](/contributing/style-guide/) +- 私たちの[行動規範](/community/code-of-conduct) -## サイトに関する決定 {#how-decisions-about-the-site-are-made} +## サイトに関する決定はどのように行われるか {#how-decisions-about-the-site-are-made} -個々のPR、デザインの進化、メジャーなアップグレードに関する決定は、イーサリアムのエコシステム全体からなるチームによって行われます。 このチームには、プロジェクトマネージャー、デベロッパー、デザイナー、マーケティングとコミュニケーションなど各領域の専門家が含まれます。 コミュニティからの情報は、すべての決定に反映されるため、イシューの質問、PRの送信、チームへの連絡をお願いします。 +個々のPR、デザインの進化、メジャーアップグレードに関する決定は、イーサリアムエコシステム全体からなるチームによって行われます。 このチームには、プロジェクトマネージャー、デベロッパー、デザイナー、マーケティングおよびコミュニケーション担当者、そして各分野の専門家が含まれます。 コミュニティからの意見はあらゆる決定に反映されます。issueでの質問、PRの提出、またはチームへの連絡をお願いします: - [website@ethereum.org](mailto:website@ethereum.org) - [@ethdotorg](https://twitter.com/ethdotorg) - [Discordサーバー](https://discord.gg/ethereum-org) -### 盗用に関する注意点 {#plagiarism} +### 盗用に関する注意 {#plagiarism} -ethereum.orgにコンテンツや成果物を提供する際は、オリジナルの作品や使用許可を得たコンテンツのみを使用するようにしてください。 イーサリアムのエコシステム内の多くのプロジェクトは、自由に情報を共有できるオープンソースライセンスを採用しています。 ただし、この情報が見つからない場合は、ethereum.orgには追加しないでください。 盗用とみなされたプルリクエストは拒絶されます。 +ethereum.orgにコンテンツやアーティファクトを投稿する際は、ご自身のオリジナル作品または使用許可を得たコンテンツのみを使用してください。 イーサリアムエコシステム内の多くのプロジェクトでは、情報の自由な共有を許可するオープンソースライセンスが使用されています。 ただし、この情報が見つからない場合は、ethereum.orgに追加しようとしないでください。 盗用と見なされるプルリクエストはすべて拒否されます。 -## オープンソースが初めての場合 {#new-to-open-source} +## オープンソースは初めてですか？ {#new-to-open-source} -GitHubリポジトリには、オープンソースに初めて触れるデベロッパーのために特別に設計された、取り組みやすい初心者向けのイシューがあり、[good first issue(初心者向け)](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)とラベル付けされています。 +私たちのGitHubリポジトリには、オープンソース初心者のデベロッパー向けに特別に設計された、参入障壁の低いissueがあり、[good first issue](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)というラベルが付けられています。 -## オンチェーン功績トークン(OAT)の申請 {#oat} +## オンチェーン功績トークン(OAT)を請求する {#oat} -あなたの貢献がethereum.orgにマージされると、[Galxe](https://app.galxe.com/quest/ethereumorg)で特別なバッジを請求できるようになります。 オンチェーン功績トークン(OAT)は、エコシステムをささやかながらより素晴らしいものにするのに貢献したことの証拠です。 +あなたの貢献がethereum.orgにマージされると、[Galxe](https://app.galxe.com/quest/ethereumorg)で特別なバッジを請求するチャンスがあります。 オンチェーン功績トークン(OAT)は、あなたがエコシステムを少しでも素晴らしいものにする手助けをしたことの証明です。 [OATの詳細](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03) -### 申請方法 -1. [Discordサーバー](https://discord.gg/ethereum-org)に参加します。 -2. `#🥇 | proof-of-contribution`チャンネルにあなたの投稿へのリンクを貼り付けてください。 -3. OATへのリンクが送られるまでお待ちください。 -4. OATを受け取ります。 +### 請求方法 -OATの受け取りには、セルフ・カストディのウォレットのみを使用してください。 取引所のアカウントや秘密鍵を保有していないその他のアカウントなどは、使わないでください。これらのアカウントでは、OATへのアクセスや管理ができません。 +1. 私たちの[Discordサーバー](https://discord.gg/ethereum-org)に参加する。 +2. `#🥇 | proof-of-contribution`チャンネルに、あなたの貢献へのリンクを貼り付ける。 +3. 私たちのチームのメンバーからOATへのリンクが送られてくるのを待つ。 +4. OATを請求する！ -## GitPOAPの申請 {#claim-gitpoap} +OATの請求には、セルフカストディウォレットのみを使用してください。 取引所のアカウントや、ご自身で秘密鍵を保持していないその他のアカウントは使用しないでください。これらのアカウントではOATにアクセスしたり管理したりすることができません。 -GitPOAPは、マージされたコントリビューションを自動的に認識し、プラットフォーム上で別々に固有のコントリビューターPOAPをミントできます。 +## GitPOAPを請求する {#claim-gitpoap} +GitPOAPはまた、マージされたあなたの貢献を自動的に認識し、そのプラットフォーム上で個別のユニークなコントリビューターPOAPをミントさせてくれます！ -### 申請方法 {#how-to-claim} +### 請求方法 {#how-to-claim} -1. [GitPOAP](https://www.gitpoap.io)にアクセスします。 -2. サインインオプションで、ウォレットまたは電子メールで接続します。 -3. GitHubのユーザー名、ETHアドレス、ENS名、またはGitPOAPを検索して、条件を満たしているか確認してください。 -4. あなたのGitHubアカウントが条件を満たしていれば、GitPOAPをミントできます。 +1. [GitPOAP](https://www.gitpoap.io)にアクセスする。 +2. サインインオプションから、ウォレットまたはEメールで接続する。 +3. GitHubのユーザー名、ETHアドレス、ENS名、または任意のGitPOAPを検索して、対象かどうかを確認する。 +4. GitHubアカウントが対象であれば、GitPOAPをミントできる！ -## 貢献者 {#contributors} +## コントリビューター {#contributors} diff --git a/public/content/translations/ja/contributing/quizzes/index.md b/public/content/translations/ja/contributing/quizzes/index.md index 9a6d56f183a..271db8c8ab6 100644 --- a/public/content/translations/ja/contributing/quizzes/index.md +++ b/public/content/translations/ja/contributing/quizzes/index.md @@ -1,6 +1,6 @@ --- -title: クイズの追加 -description: ethereum.orgへのクイズの掲載ポリシー +title: "クイズの追加" +description: "ethereum.orgへのクイズの掲載ポリシー" lang: ja --- @@ -14,12 +14,12 @@ lang: ja - [レイヤー2](/layer-2) - [NFT](/nft/) -- [イーサリアムとは？](/what-is-ethereum/) -- [ETHとは何？](/what-is-ether/) +- [イーサリアムとは](/what-is-ethereum/) +- [ETHとは](/what-is-ether/) ## 学習クイズの追加 -学習クイズが無いページがある場合は、[イシューを作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)してください。 +学習クイズが作成されていないページがある場合は、[issueを開いて](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)ください。 次の情報を提供してください。 @@ -32,7 +32,7 @@ lang: ja ## クイズの追加 -問題バンクにクイズを追加したい場合は、 [イシューを作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)して次の情報を提供してください。 +クイズの問題バンクに追加したい質問がある場合は、[issueを開いて](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)、以下の情報を提供してください。 - クイズを追加したいページ - 各問題について、以下の情報を入力してください。 @@ -43,7 +43,7 @@ lang: ja ## クイズの更新 -問題バンクに更新したいクイズがある場合は、[イシューを作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)して次の情報を提供してください。 +クイズの問題バンクにある質問を更新したい場合は、[issueを開いて](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)、以下の情報を提供してください。 - クイズを更新したいページ - 各問題を更新するために次の情報を入力してください。 @@ -55,7 +55,7 @@ lang: ja ## クイズの削除 -問題に関する内容がページに無く、削除する必要がある場合は、[イシューを作成](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)し、次の情報を提供して問題を削除してください。 +質問のコンテンツがページになく、削除が必要な場合は、質問を削除するために[issueを開いて](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml)、以下の情報を提供してください。 - クイズを削除したいページ - 削除したい問題 diff --git a/public/content/translations/ja/contributing/translation-program/faq/index.md b/public/content/translations/ja/contributing/translation-program/faq/index.md index 22a64038735..310d65fb7f3 100644 --- a/public/content/translations/ja/contributing/translation-program/faq/index.md +++ b/public/content/translations/ja/contributing/translation-program/faq/index.md @@ -1,10 +1,10 @@ --- -title: 翻訳プログラムに関するよくある質問(FAQ) +title: "翻訳プログラムに関するよくある質問(FAQ)" lang: ja -description: ethereum.orgの翻訳プログラムに関するよくある質問 +description: "ethereum.orgの翻訳プログラムに関するよくある質問" --- -# ethereum.orgの翻訳ガイド {#translating-ethereum-guide} +# ethereum.org翻訳ガイド {#translating-ethereum-guide} 翻訳プログラムが初めてで、参加をためらっているのであれば、まずはこちらのよくある質問をご覧ください。 このガイドでは、よくある質問に対する答えを記載しています。 @@ -18,31 +18,31 @@ ethereum.orgの翻訳プログラムはその延長線上にあり、同じよ このため、本翻訳プログラムはオープンかつ自発的なものであり、参加は報酬の対象とはなりません。 翻訳した文字数に応じて報酬を支払うとなると、十分な翻訳経験を持つ翻訳者(プロの翻訳者)でなければ、「翻訳プログラム」に参加してもらうことができません。 これでは、「翻訳プログラム」が排他的になり、「誰もが参加でき、エコシステムに関与できるようにする」という目標に反することになります。 -貢献者がイーサリアムのエコシステムで成功できるよう、あらゆる努力を行っています。[出席証明プロトコル(POAP)の提供](/contributing/translation-program/acknowledgements/#poap)や[翻訳者証明書](/contributing/translation-program/acknowledgements/#certificate)など、金銭以外のインセンティブも多く用意されています。同時に、[翻訳リーダーボード](/contributing/translation-program/acknowledgements/)や[サイトの全翻訳者リスト](/contributing/translation-program/contributors/)を整理しているところです。 +イーサリアムエコシステムでコントリビューターが成功できるよう、私たちはあらゆる努力をしています。たとえば、[POAPの提供](/contributing/translation-program/acknowledgements/#poap)や[翻訳者証明書](/contributing/translation-program/acknowledgements/#certificate)、[翻訳リーダーボード](/contributing/translation-program/acknowledgements/)の開催、[サイトへの全翻訳者の掲載](/contributing/translation-program/contributors/)など、金銭的でない多くのインセンティブが用意されています。 -## ``はどのように翻訳すればいいですか? {#tags} +## ``を含む文字列はどのように翻訳すればよいですか？ {#tags} -翻訳するすべての文字列が純粋なテキスト形式で書かれているわけではありません。 HTMLタグ(`<0>`、``)などのスクリプトが含まれている文字列もあります。これは通常、ハイパーリンクや文章の途中でスタイルを変えるためのものです。 +翻訳するすべての文字列が純粋なテキスト形式で書かれているわけではありません。 HTMLタグ (`<0>`, ``) のように、複数のスクリプトで構成される文字列があります。これらは通常、文中のハイパーリンクや代替スタイルのためのものです。 -- タグ内のテキストは翻訳しますが、タグはそのまま残します。 `<` と `>`の間は、翻訳したり削除しないでください。 +- タグ内のテキストは翻訳しますが、タグはそのまま残します。 `<` と `>` の中にあるものは、翻訳したり削除したりしてはいけません。 - 間違えないようにするために、左下の[Copy Source]ボタンをクリックすると、 元の文字列がコピーされ、テキストボックスに貼り付けられ、 タグがどこにあるかがよくわかり、ミスを避けることができます。 -![[Copy Source]ボタンがハイライトされているCrowdinインターフェイス](./html-tag-strings.png) +![「ソースをコピー」ボタンがハイライトされたCrowdinインターフェース](./html-tag-strings.png) より自然な翻訳文になるよう、文字列のタグの位置は移動できますが、タグの一部ではなく、タグすべてを移動してください。 -タグやコードの扱いについてのより詳細な情報については、[ethereum.org 翻訳スタイルガイド](/contributing/translation-program/translators-guide/#dealing-with-tags)を参照してください。 +タグやコードスニペットの扱いに関する詳細については、[ethereum.org翻訳スタイルガイド](/contributing/translation-program/translators-guide/#dealing-with-tags)を参照してください。 ## 翻訳する文字列はページのどこに使われていますか? {#strings} 時にはソースの文字列だけでは、情報が足らず、正確な翻訳ができないことがあります。 - 詳細な情報については、[Screenshot]と[Context]を参照してください。 ソースの文字列セクションに、その文字列がどのように使われているのか、コンテクストが分かるスクリーンショット画像が表示されます。 -- それでも不明な場合は、[Comment Section]で質問できます。 [コメントを残す方法が分からない場合は、こちらを参照してください](#comment)。 +- それでも不明な場合は、[Comment Section]で質問できます。 [コメントの残し方がわからない場合](#comment) -![文字列に対するコンテキストのスクリーンショット](./source-string.png) +![スクリーンショットを使用して文字列にコンテキストを提供する方法](./source-string.png) -![コンテキストを提供するスクリーンショットの例](./source-string-2.png) +![コンテキストとして追加されたスクリーンショットの例](./source-string-2.png) ## 問題や誤字を指摘したいのですが、コメントや質問をするにはどうすればいいですか ? {#comment} @@ -52,11 +52,11 @@ ethereum.orgの翻訳プログラムはその延長線上にあり、同じよ - 送信された時点で、私たちのチームに報告されます。 問題を修正してから、コメントに返信してお知らせし、問題をクローズします。 - 誤った翻訳を報告した場合、該当する文章と提案された修正案は、次回のレビュー時にネイティブスピーカーによりレビューが行われます。 -![コメントと問題の作成方法](./comment-issue.png) +![コメントと課題の作成方法](./comment-issue.png) ## 翻訳メモリ(TM) とは何ですか? {#translation-memory} -翻訳メモリ(TM)とは、[ethereum.org](https://ethereum.org/)全体で過去に翻訳されたすべての文字列を保存するCrowdinの機能の一つです。 文字列が翻訳されると、自動的にプロジェクトのTMに保存されます。 これは便利なツールで、時間の節約につながります。 +翻訳メモリ(TM)とは、ethereum.org全体で過去に翻訳されたすべての文字列を保存するCrowdinの機能の一つです。 文字列が翻訳されると、自動的にプロジェクトのTMに保存されます。 これは便利なツールで、時間の節約につながります。 - [TM and MT Suggestions]のセクションに、他の翻訳者が同じまたは類似する文字列をどのように翻訳したかが表示されます。 マッチ率の高い提案を見つけたら、その翻訳をクリックして気軽に使用してください。 - リストに何も表示されない場合は、一貫性を持たせるために、過去の翻訳をTMで検索し、再利用することができます。 @@ -65,7 +65,7 @@ ethereum.orgの翻訳プログラムはその延長線上にあり、同じよ ## Crowdinの用語集の使い方を教えてください {#glossary} -新しい技術用語は多くの言語にローカライズされていないため、イーサリアムの用語集も翻訳作業で重要な役割を果たします。 また、文脈によって意味が異なる用語もあります。 [イーサリアム用語集の翻訳の詳細](#terminology) +新しい技術用語は多くの言語にローカライズされていないため、イーサリアムの用語集も翻訳作業で重要な役割を果たします。 また、文脈によって意味が異なる用語もあります。 [イーサリアムの専門用語の翻訳の詳細](#terminology) Crowdinの用語集を利用して、用語や定義を明確にできます。 用語集を参照するには、2つの方法があります。 @@ -75,15 +75,15 @@ Crowdinの用語集を利用して、用語や定義を明確にできます。 - 次に、知らない単語で下線が引かれていないものの場合は、[Terminology]タブ(右欄の3番目のボタン)から検索できます。 プロジェクト内で頻繁に使用される用語の説明が表示されます。 -![Crowdinの用語集タブの場所を示すスクリーンショット](./glossary-tab.png) +![Crowdinで用語集タブを見つける場所を示すスクリーンショット](./glossary-tab.png) - それでも見つからない場合は、新しい用語を追加してください。 検索エンジンで調べて、その説明を用語集に加えることをお勧めします。 他の翻訳者にとっても、その用語をより理解する上で大きな助けとなるでしょう。 -![Crowdinで用語を用語集に追加する方法を示すスクリーンショット](./add-glossary-term.png) +![Crowdinに用語集の用語を追加する方法を示すスクリーンショット](./add-glossary-term.png) ### 用語の翻訳ポリシー {#terminology} -_固有名詞(ブランド、企業、人名)および新しい技術用語(ビーコンチェーン、シェアードチェーンなど) :_ +_固有名詞(ブランド、企業、人名)および新しい技術用語(ビーコンチェーン、シャードチェーンなど)の場合_ イーサリアムには、最近作られた新しい用語がたくさん使われています。 それぞれの言語に公式な翻訳がないため、翻訳者によって使う用語が異なる場合があります。 このような不一致は、読み手に誤解を生じさせ、また読みやすさも損なわれます。 @@ -104,16 +104,16 @@ _固有名詞(ブランド、企業、人名)および新しい技術用語(ビ 翻訳の品質と一貫性を一定レベルに保つため、世界最大級の言語サービスプロバイダーである[Acolad](https://www.acolad.com/)と協働しています。 Acoladには20,000人のプロの翻訳者がおり、プロが必要なあらゆる言語、あらゆるコンテンツのレビューを行うことができます。 -レビュープロセスは簡単で、ある[コンテンツバケット](/contributing/translation-program/content-buckets)が100%翻訳されると、そのコンテンツバケットに対してレビューが行われます。 レビュー自体はCrowdinで直接行われます。 レビュー終了後、翻訳されたコンテンツにウェブサイトを更新します。 +レビュープロセスは簡単です。あるコンテンツセットが100%翻訳されると、そのコンテンツバケットのレビューを依頼します。 レビュー自体はCrowdinで直接行われます。 レビュー終了後、翻訳されたコンテンツにウェブサイトを更新します。 ## 私の言語でコンテンツを追加するにはどうすればいいですか? {#adding-foreign-language-content} 現在、英語以外のコンテンツはすべて英語のコンテンツからの翻訳です。また、英語にないコンテンツを他の言語に追加できません。 -ethereum.orgの新しいコンテンツを提案するには、GitHubで[問題を作成](https://github.com/ethereum/ethereum-org-website/issues)してください。 コンテンツが追加される場合、コンテンツはまず英語で書かれ、Crowdin上で多言語化されます。 +ethereum.orgの新しいコンテンツを提案するには、GitHubで[課題を作成](https://github.com/ethereum/ethereum-org-website/issues)できます。 コンテンツが追加される場合、コンテンツはまず英語で書かれ、Crowdin上で多言語化されます。 近い将来、英語以外のコンテンツの追加にも対応する予定です。 ## お問い合わせ {#contact} -これら全文をお読みいただき、ありがとうございました。 翻訳プログラムへの参加に向けて、本ドキュメントが役立つことを願っています。 [Discord翻訳チャンネル](https://discord.gg/ethereum-org)に気軽に参加して、質問をしたり、他の翻訳者とコラボレーションをしてください。または、translations@ethereum.orgまでお問い合わせください。 +これら全文をお読みいただき、ありがとうございました。 翻訳プログラムへの参加に向けて、本ドキュメントが役立つことを願っています。 [Discord翻訳チャンネル](https://discord.gg/ethereum-org)に気軽に参加して質問をしたり、他の翻訳者とコラボレーションをしたり、またはtranslations@ethereum.orgまでお問い合わせください。 diff --git a/public/content/translations/ja/contributing/translation-program/how-to-translate/index.md b/public/content/translations/ja/contributing/translation-program/how-to-translate/index.md index b9586f503c4..83d2c187488 100644 --- a/public/content/translations/ja/contributing/translation-program/how-to-translate/index.md +++ b/public/content/translations/ja/contributing/translation-program/how-to-translate/index.md @@ -1,10 +1,10 @@ --- -title: 翻訳方法 +title: "翻訳方法" lang: ja -description: ethereum.orgの翻訳でCrowdinを使う手順 +description: "ethereum.orgの翻訳でCrowdinを使う手順" --- -# 翻訳方法 {#how-to-translate} +# 翻訳の方法 {#how-to-translate} ## ビジュアルガイド {#visual-guide} @@ -12,9 +12,9 @@ description: ethereum.orgの翻訳でCrowdinを使う手順 -## 文書によるガイド {#written-guide} +## 文章ガイド {#written-guide} -### Crowdinにあるプロジェクトに参加する {#join-project} +### Crowdinのプロジェクトに参加する {#join-project} お持ちのCrowdinアカウントでログインします。無い場合はサインアップする必要があります。 サインアップに必要なのは、Eメールとパスワードだけです。 @@ -22,35 +22,34 @@ description: ethereum.orgの翻訳でCrowdinを使う手順 プロジェクトに参加 -### 翻訳する言語を開く {#open-language} +### 言語を選択する {#open-language} -Crowdinへログインすると、プロジェクトの説明と翻訳可能な言語のリストが表示されます。 各言語には、その言語における翻訳可能な単語の総数、どの程度の翻訳が完了し承認されているかに関する概要の情報も含まれています。 +Crowdinへログインすると、プロジェクトの説明と翻訳可能な言語のリストが表示されます。 +各言語には、その言語における翻訳可能な単語の総数、どの程度の翻訳が完了し承認されているかに関する概要の情報も含まれています。 翻訳したい言語を開き、翻訳が可能になっているファイルのリストを確認してください。 -![Crowdinにある言語のリスト](./list-of-languages.png) +![Crowdinの言語リスト](./list-of-languages.png) ### 作業するドキュメントを見つける {#find-document} ウェブサイトのコンテンツは、多数のドキュメントとコンテンツバケットに分割されています。 各ドキュメントの進捗状況は右側で確認できます。翻訳の進捗が100％未満の場合は、ぜひご協力ください! -あなたの言語が表示されてない場合は、 [イシューを作成する](https://github.com/ethereum/ethereum-org-website/issues/new/choose)か、[Discord](https://discord.gg/ethereum-org) で問い合わせてください。 +あなたの言語が表示されてない場合は、 [issueを立てる](https://github.com/ethereum/ethereum-org-website/issues/new/choose)か、[Discord](https://discord.gg/ethereum-org)で質問してください -![Crowdinにある翻訳されたファイルと未翻訳のファイル](./crowdin-files.png) +![Crowdin内の翻訳済みファイルと未翻訳ファイル](./crowdin-files.png) -コンテンツバケットに関する注意事項: Crowdinでは、「コンテンツバケット」を使用して、最初に最優先コンテンツをリリースします。 例えば、[フィリピン語](https://crowdin.com/project/ethereum-org/fil#)など言語をチェックアウトすると、コンテンツバケットのフォルダが表示されます ("1. Homepage"、"2. Essentials"、"3. Exploring"など) 。 +コンテンツバケットに関する注意事項: Crowdinでは、「コンテンツバケット」を使用して、最初に最優先コンテンツをリリースします。 例えば[フィリピン語](https://crowdin.com/project/ethereum-org/fil#)のような言語をチェックすると、コンテンツバケット（「1.）用のフォルダが表示されます。 Homepage"、"2. Essentials"、"3. Exploring"など) 。 最も影響度のあるページを最初に翻訳するために、この数字順 (1 → 2 → 3 → ⋯) で翻訳することを推奨します。 -[ethereum.orgのコンテンツ一覧について詳しくはこちらをご覧ください。](/contributing/translation-program/content-buckets/) - -### 翻訳 {#translate} +### 翻訳する {#translate} 翻訳したいファイルを選択すると、オンラインエディターが開きます。 Crowdinを使ったことがない方は、このクイックガイドで基本的なことを確認してください。 ![Crowdinオンラインエディター](./online-editor.png) -**_1 - 左サイドバー_** +**_1 – 左サイドバー_** - Untranslated (赤) - まだ翻訳されていないテキスト。 これらは、翻訳が必要な文字列です。 - Translated (緑) - 翻訳されているが、まだレビューされていないテキスト。 別の翻訳を提案したり、エディタの「+」と「-」ボタンを使って、既存の翻訳への投票が自由にできます。 @@ -58,23 +57,24 @@ Crowdinへログインすると、プロジェクトの説明と翻訳可能な また、上部のボタンを使って、特定の文字列を検索したり、ステータスでフィルタリングしたり、表示を変更したりすることができます。 -**_2 - エディターエリア_** +**_2 – エディターエリア_** -メインの翻訳エリア - 原文が上部に表示され、追加でコンテキストやスクリーンショットがある場合はそれらも表示されます。 新しい翻訳を提案するには、「Enter translation here」の欄に翻訳を入力し、[Save]をクリックします。 +メインの翻訳エリア - 原文が上部に表示され、追加でコンテキストやスクリーンショットがある場合はそれらも表示されます。 +新しい翻訳を提案するには、「Enter translation here」の欄に翻訳を入力し、[Save]をクリックします。 また、このセクションでは、文字列の既存の翻訳や他の言語への翻訳のほか、翻訳メモリの一致や機械翻訳の候補も見つけることができます。 -**_3 - 右サイドバー_** +**_3 – 右サイドバー_** ここには、コメントや翻訳メモリのエントリ、用語集のエントリがあります。 デフォルトの表示では、コメントが表示され、翻訳者がコミュニケーションを取ったり、問題を提起したり、間違った翻訳を報告したりすることができます。 また、上部のボタンで、既存の翻訳を検索できる「翻訳メモリ」や、重要な用語の説明や標準的な翻訳を収録した「用語集」に切り替えることができます。 -さらに詳しく知りたいですか？ [Crowdinオンラインエディターの使用方法に関するドキュメント](https://support.crowdin.com/online-editor/)をご参照ください。 +さらに詳しく知りたいですか？ [Crowdinオンラインエディターの使用に関するドキュメント](https://support.crowdin.com/online-editor/)をお気軽にご確認ください ### レビュープロセス {#review-process} -翻訳が完了(コンテンツバケットの全ファイルが100％と表示)したら、プロの翻訳サービスがコンテンツをレビューします。またレビューの際は、編集する場合もあります。 レビューが完了(レビューの進捗率が100％)したら、ウェブサイトに追加されます。 +翻訳が完了すると(つまり、コンテンツバケットのすべてのファイルが100%と表示されると)、プロの翻訳サービスがコンテンツをレビュー(および必要に応じて編集)します。 レビューが完了したら(つまり、レビューの進捗が100%になったら)、ウェブサイトに追加します。 @@ -85,7 +85,7 @@ Crowdinへログインすると、プロジェクトの説明と翻訳可能な ### お問い合わせ {#get-in-touch} -何かご質問がある場合や、 私たちのチームや他の翻訳者とコラボレーションしたい場合は、 [ethereum.orgのDiscordサーバー](https://discord.gg/ethereum-org)の#translationチャネルに投稿してください。 +何かご質問がある場合や、 私たちのチームや他の翻訳者とコラボレーションしたい場合は、 [ethereum.org Discordサーバー](https://discord.gg/ethereum-org)の#translationsチャンネルに投稿してください。 または、translations@ethereum.orgまでご連絡ください diff --git a/public/content/translations/ja/contributing/translation-program/index.md b/public/content/translations/ja/contributing/translation-program/index.md index cad6e59ff38..cc6c9fa076a 100644 --- a/public/content/translations/ja/contributing/translation-program/index.md +++ b/public/content/translations/ja/contributing/translation-program/index.md @@ -1,7 +1,7 @@ --- -title: 翻訳プログラム +title: "翻訳プログラム" lang: ja -description: ethereum.org翻訳プログラムについて +description: "ethereum.org翻訳プログラムについて" --- # 翻訳プログラム {#translation-program} @@ -10,17 +10,17 @@ description: ethereum.org翻訳プログラムについて ![](./enterprise-eth.png) -## 翻訳への協力 {#help-us-translate} +## 翻訳にご協力ください {#help-us-translate} ethereum.org翻訳プログラムはオープンで、誰でも貢献できます。 1. Crowdinアカウントにログイン、またはサインアップします。 2. 貢献したい言語を選択します。 -3. 始める前に、まず [翻訳方法](/contributing/translation-program/how-to-translate/)ガイドでCrowdinの使い方を学び、[翻訳スタイルガイド](/contributing/translation-program/translators-guide/)でコツと最善の方法を確認します。 +3. 開始する前に、[翻訳方法](/contributing/translation-program/how-to-translate/)ガイドでCrowdinの使用方法を、[翻訳スタイルガイド](/contributing/translation-program/translators-guide/)でヒントやベストプラクティスをご確認ください。 4. 機械翻訳は承認されません。 5. すべての翻訳は、サイトに追加される前にレビューされるため、翻訳が掲載されるまで若干のライムラグがあります。 -_[ethereum.orgのDiscord](https://discord.gg/ethereum-org)に参加すると、翻訳でのコラボレーション、質問、フィードバックやアイデアの共有、または翻訳グループへの参加ができます。_ +_[ethereum.org Discord](https://discord.gg/ethereum-org)に参加して、翻訳での共同作業、質問、フィードバックやアイデアの共有、または翻訳グループへの参加ができます。_ 翻訳を始める @@ -32,35 +32,36 @@ _[ethereum.orgのDiscord](https://discord.gg/ethereum-org)に参加すると、 ethereum.org翻訳プログラムは、ethereum.orgやその他のイーサリアムコンテンツをできるだけ多くの言語に翻訳することで、誰もがイーサリアムを利用できるようにすることを目的としています。 -ethereum.org翻訳プログラムの詳細については、[ミッションとビジョン](/contributing/translation-program/mission-and-vision)を参照してください。 +ethereum.org翻訳プログラムの[ミッションとビジョン](/contributing/translation-program/mission-and-vision)の詳細をご覧ください。 ### これまでの進捗 {#our-progress} -- [**6,000人以上**の翻訳者](/contributing/translation-program/contributors/) -- **62**言語に対応 -- [**300万**語翻訳(2023年時点)](/contributing/translation-program/acknowledgements/) +- [**6,900人以上**の翻訳者](/contributing/translation-program/contributors/) +- **68**言語に対応 +- [2024年に翻訳された**289万**語](/contributing/translation-program/acknowledgements/) ### 謝辞 {#acknowledgements} -ethereum.orgは、何千人ものコミュニティメンバーによって翻訳されており、翻訳プログラムに欠かせない重要な役割を担っています。 翻訳者の皆様に感謝すると同時に、翻訳者の皆様のキャリアパスをサポートしたいと考えています。 以下に、翻訳者の皆様への感謝の形をいくつか紹介します。 +ethereum.orgは、何千人ものコミュニティメンバーによって翻訳されており、翻訳プログラムに欠かせない重要な役割を担っています。 +翻訳者の皆様に感謝すると同時に、翻訳者の皆様のキャリアパスをサポートしたいと考えています。 以下に、翻訳者の皆様への感謝の形をいくつか紹介します。 #### 証明書 {#certificate} 翻訳プログラムに貢献し、5000語以上の翻訳が承認された場合、ethereum.org翻訳者証明書受け取ることができます。 [証明書の詳細](/contributing/translation-program/acknowledgements/#certificate) -#### OAT {#oats} +#### OATs {#oats} -翻訳プログラムのコントリビュータは、2024年の翻訳単語数に基づいて様々なOAT(オンチェーン功績トークン)を受け取る資格があります。 OATは、ethereum.org翻訳プログラムへ貢献したことを証明するNFTです。 [OATの詳細](/contributing/translation-program/acknowledgements/#oats) +翻訳プログラムのコントリビュータは、2024年の翻訳単語数に基づいて様々なOAT(オンチェーン功績トークン)を受け取る資格があります。 OATは、ethereum.org翻訳プログラムへ貢献したことを証明するNFTです。 [OATsの詳細](/contributing/translation-program/acknowledgements/#oats) -#### 翻訳者の表彰 {#translator-acknowledgements} +#### 翻訳者への謝辞 {#translator-acknowledgements} -[リーダーボード](/contributing/translation-program/acknowledgements/)でトップの翻訳者を公表します。また、[翻訳プログラムへのすべての貢献者のリストを公開しています](/contributing/translation-program/contributors/)。 +[リーダーボード](/contributing/translation-program/acknowledgements/)や[翻訳プログラムの全コントリビューターリスト](/contributing/translation-program/contributors/)で、トップ翻訳者を公に紹介しています。 #### 報酬 {#rewards} -これまで、アクティブな貢献者には、[開発者会議](https://devcon.org/en/)や[Devconnect](https://devconnect.org/)などのイーサリアム会議のチケットや、ethereum.orgの限定グッズを提供してきました。 +これまで、特に貢献度の高かったコントリビューターには、[Devcon](https://devcon.org/en/)や[Devconnect](https://devconnect.org/)などのイーサリアムカンファレンスのチケット、およびethereum.org限定グッズを遡って贈呈してきました。 貢献者に報いることができる、新しいイノベーティブな方法を常に検討しています。 @@ -68,23 +69,23 @@ ethereum.orgは、何千人ものコミュニティメンバーによって翻 翻訳プログラムに貢献している、または参加を検討中の方は、以下の翻訳ガイドを参照してください。 -- [翻訳スタイルガイド](/contributing/translation-program/translators-guide/) _– ethereum.org翻訳者向けの説明とヒント_ -- [翻訳に関するよくある質問](/contributing/translation-program/faq/) _– ethereum.org 翻訳プログラムに関するよくある質問とその回答_ -- [Crowdinオンラインエディタガイド](https://support.crowdin.com/online-editor/) _– Crowdinオンラインエディタと高度な機能を使用するための詳細なガイド_ -- [コンテンツバケット](/contributing/translation-program/content-buckets/) _– ethereum.orgのコンテンツバケットに含まれているページ_ +- [翻訳スタイルガイド](/contributing/translation-program/translators-guide/) _– ethereum.orgの翻訳者向けの指示とヒント_ +- [翻訳に関するよくある質問](/contributing/translation-program/faq/) _– ethereum.org翻訳プログラムに関するよくある質問と回答_ +- [Crowdinオンラインエディターガイド](https://support.crowdin.com/online-editor/) _– Crowdinオンラインエディターの使用方法と、Crowdinの高度な機能に関する詳細なガイド_ -他の有用な翻訳ツール、翻訳コミュニティ、翻訳プログラムのブログ記事については、 [リソースページ](/contributing/translation-program/resources/)を参照してください。 +その他の便利な翻訳ツール、翻訳者コミュニティ、翻訳プログラムのブログ記事については、[リソースページ](/contributing/translation-program/resources/)をご覧ください。 ## お問い合わせ {#get-in-touch} -何かご質問がある場合や、 私たちのチームや他の翻訳者とコラボレーションしたい場合は、 [ethereum.orgのDiscordサーバー](https://discord.gg/ethereum-org)の#translationチャネルに投稿してください。 +何かご質問がある場合や、 私たちのチームや他の翻訳者とコラボレーションしたい場合は、 [ethereum.org Discordサーバー](https://discord.gg/ethereum-org)の#translationsチャンネルに投稿してください。 または、translations@ethereum.orgまでご連絡ください -## あなた自身の翻訳プログラムの開始 {#starting-a-translation-program} +## 独自の翻訳プログラムを始める {#starting-a-translation-program} -私たちはイーサリアムコンテンツをできるだけ多くの言語に翻訳し、教育コンテンツを誰にでも利用できるようにすることに専念しています。 翻訳に焦点を置くのと同様に、他のイーサリアムプロジェクトが、翻訳活動を組織、管理、改善する支援を行いたいと考えています。 +私たちはイーサリアムコンテンツをできるだけ多くの言語に翻訳し、教育コンテンツを誰にでも利用できるようにすることに専念しています。 +翻訳に焦点を置くのと同様に、他のイーサリアムプロジェクトが、翻訳活動を組織、管理、改善する支援を行いたいと考えています。 -このため、ethereum.orgを翻訳する過程で得てきた、ヒントとベストプラクティスを盛り込んだ[翻訳プログラムプレイブック](/contributing/translation-program/playbook/)を作成しました。 +このため、ethereum.orgを翻訳する過程で得たヒントやベストプラクティスを盛り込んだ[翻訳プログラムプレイブック](/contributing/translation-program/playbook/)を作成しました。 コラボレーションのご要望、翻訳リソースの利用、 またはプレイブックについてのご意見があれば、 translations@ethereum.orgまでご連絡ください。 diff --git a/public/content/translations/ja/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/ja/contributing/translation-program/mission-and-vision/index.md index 5d6e82a6c49..892980dc79a 100644 --- a/public/content/translations/ja/contributing/translation-program/mission-and-vision/index.md +++ b/public/content/translations/ja/contributing/translation-program/mission-and-vision/index.md @@ -1,7 +1,7 @@ --- -title: ミッションとビジョン +title: "ミッションとビジョン" lang: ja -description: ethereum.org翻訳プログラムのミッションとビジョン +description: "ethereum.org翻訳プログラムのミッションとビジョン" --- # ミッションとビジョン {#mission-and-vision} @@ -10,7 +10,7 @@ description: ethereum.org翻訳プログラムのミッションとビジョン ethereum.org翻訳プログラムは、ethereum.orgやその他のイーサリアムコンテンツをできるだけ多くの言語に翻訳することで、誰もがイーサリアムを利用できるようにすることを目的としています。 -## ethereum.orgのミッション {#our-mission} +## 私たちのミッション {#our-mission} - 世界中の訪問者が母国語でEthereumについて学べるようにするために、サイトの翻訳版を提供する - グローバルなEthereumコミュニティに、より多くのメンバーの参加を促す diff --git a/public/content/translations/ja/contributing/translation-program/playbook/index.md b/public/content/translations/ja/contributing/translation-program/playbook/index.md new file mode 100644 index 00000000000..381229c065c --- /dev/null +++ b/public/content/translations/ja/contributing/translation-program/playbook/index.md @@ -0,0 +1,317 @@ +--- +title: "翻訳プログラムプレイブック" +lang: ja +description: "翻訳プログラムを立ち上げるためのヒントと重要な考慮事項のコレクションです。" +--- + +# 翻訳プログラムプレイブック {#translation-program-playbook} + +英語は世界で最も話されている言語の一つであり、世界で最も学習されている言語でもあります。 英語はインターネット、特にソーシャルメディアで最も一般的に使用される言語であり、多言語対応のプログラミング言語は希少なため、ブロックチェーン分野のコンテンツの大部分は英語で書かれています。 + +しかし、世界の60億人以上 (人口の75%以上) が全く英語を話さないため、これは世界の大多数の人口にとってイーサリアムへの参入の大きな障壁となっています。 + +このため、この分野では、コンテンツをさまざまな言語に翻訳し、グローバルコミュニティ向けにローカライズしようとするプロジェクトが増えています。 + +多言語コンテンツを提供することは、グローバルコミュニティを成長させ、英語を話さない人々に教育を提供し、コンテンツやコミュニケーションをより多くの人々に届け、より多くの人々をこの分野にオンボーディングするためのシンプルで効果的な方法です。 + +このガイドは、コンテンツのローカライズに関する一般的な課題や誤解を取り上げることを目的としています。 コンテンツ管理、翻訳とレビューのプロセス、品質保証、翻訳者の募集、ローカライゼーションプロセスのその他の重要な側面について、ステップバイステップのガイドを提供します。 + +## コンテンツ管理 {#content-management} + +翻訳コンテンツ管理とは、翻訳ワークフローを自動化するプロセスを指します。これにより、反復的な手作業の必要性がなくなり、効率と品質が向上し、より優れた管理が可能になり、コラボレーションが実現します。 + +ローカライゼーションプロセスにおけるコンテンツ管理には、コンテンツやニーズに応じてさまざまなアプローチがあります。 + +コンテンツを管理する基本的な方法は、原文と訳文を含むバイリンガルファイルを作成することです。 これは、シンプルさ以外に大きな利点がないため、翻訳ではほとんど使用されません。 + +翻訳会社は通常、翻訳管理ソフトウェアやローカライゼーションツールを使用して翻訳管理に取り組みます。これらのツールは、プロジェクト管理機能を提供し、ファイル、コンテンツ、言語学者をより高度に管理できます。 + +コンテンツ管理の詳細については、以下をご覧ください。 + +[Tradosによる翻訳管理とは](https://www.trados.com/solutions/translation-management/) + +[Phraseによる多言語コンテンツ管理](https://phrase.com/blog/posts/multilingual-content-management/) + +### 翻訳管理ソフトウェア {#translation-management-software} + +翻訳管理システムやローカライゼーションツールは数多くあり、ソフトウェアの選択は主にニーズによって決まります。 + +一部のプロジェクトでは、翻訳管理システムを使用せず、バイリンガルファイルで直接、またはGitHubなどのホスティングサービスで手動で翻訳を処理することを好みますが、これにより管理、生産性、品質、スケーラビリティ、コラボレーション機能が大幅に低下します。 このようなアプローチは、小規模なプロジェクトや一度限りの翻訳プロジェクトに最も有益な場合があります。 + +最も強力で広く使用されている翻訳管理ツールのいくつかをご紹介します。 + +**クラウドソーシングとコラボレーションに最適** + +[Crowdin](https://crowdin.com/) + +- オープンソースプロジェクトは無料 (文字列とプロジェクトの数に制限なし) +- すべてのプランでTMと用語集が利用可能 +- 60以上のサポートされているファイル形式、70以上のAPI連携 + +[Lokalise](https://lokalise.com/) + +- チームメンバー2名までは無料、それ以上のコントリビューターは有料プラン (ほとんどのプランで文字列数に制限あり) +- 一部の有料プランでTMと用語集が利用可能 +- 30以上のサポートされているファイル形式、40以上のAPI連携 + +[Transifex](https://www.transifex.com/) + +- 有料プランのみ (ほとんどのプランで文字列数に制限あり) +- すべての有料プランでTMと用語集が利用可能 +- 30以上のサポートされているファイル形式、20以上のAPI連携 + +[Phrase](https://phrase.com/) + +- 有料プランのみ (すべてのプランで文字列数は無制限、プロジェクト数とチームメンバー数に制限あり) +- 一部の有料プランでTMと用語集が利用可能 +- 40以上のサポートされているファイル形式、20以上のAPI連携 + +[Smartcat](https://www.smartcat.com/) + +- 基本的な無料プランと有料の高度な機能 (すべてのプランで文字列とプロジェクトの数は無制限) +- すべてのプランでTMと用語集が利用可能 +- 60以上のサポートされているファイル形式、20以上のAPI連携 + +[POEditor](https://poeditor.com/) + +- オープンソースプロジェクトは無料 (すべてのプロジェクトで文字列数に制限あり、オープンソースプロジェクトは無制限) +- 有料プランでTMと用語集が利用可能 +- 20以上のサポートされているファイル形式、10以上のAPI連携 + +その他多数... + +**プロフェッショナルな翻訳ツール** + +[SDL Trados Studio](https://www.trados.com/products/trados-studio/) + +- フリーランス翻訳者とチーム向けの有料プラン +- 非常に強力なコンピュータ支援翻訳 (CAT) ツールと翻訳者生産性向上ソフトウェア + +[MemoQ](https://www.memoq.com/) + +- 限定的な無料版と、高度な機能向けのいくつかの有料プランが利用可能 +- 企業、言語サービスプロバイダー、翻訳者向けの翻訳管理ソフトウェア + +[Memsource](https://www.memsource.com/) + +- 個人翻訳者は無料、チーム向けのいくつかの有料プランあり +- クラウドベースのコンピュータ支援翻訳および翻訳管理システム + +その他多数... + +翻訳管理ソフトウェアの詳細については、以下をご覧ください。 + +[Wikipediaによる翻訳管理システムの定義](https://en.wikipedia.org/wiki/Translation_management_system) + +[Phraseによる、すべての翻訳管理ソフトウェアが持つべき7つのこと](https://phrase.com/blog/posts/7-things-every-translation-management-software-should-have/) + +[MemoQによる翻訳管理システムとは](https://www.memoq.com/tools/what-is-a-translation-management-system) + +[Gengoによる、16の最高の翻訳管理システムのリスト](https://gengo.com/translator-product-updates/16-best-translation-management-systems/) + +## ワークフロー {#workflow} + +翻訳分野では、翻訳ワークフローはいくつかの異なる意味を持つことがあり、どちらも相互に関連しており、プロジェクトにとって重要な考慮事項です。 + +以下で両方について説明します。 + +**意味 1** + +これはおそらく、翻訳ワークフローについて考える最も一般的な方法であり、ワークフローという言葉を聞いて通常思い浮かぶものです。 + +本質的には、翻訳について考え始めてから、翻訳されたコンテンツを製品で使用するまでの「作業の流れ」です。 + +この場合のワークフローの例は次のとおりです。 + +1. **翻訳用ファイルの準備** – シンプルに聞こえますが、いくつかの重要なことを考慮する必要があります。 このステップでは、プロセス全体がどのように機能するかについて明確な計画を立てる必要があります。 + +- _どのファイルタイプを使用しますか？ _翻訳されたファイルをどの形式で受け取りたいですか？_ + - コンテンツがDOCXまたはMD形式で利用できる場合、ホワイトペーパーやその他のドキュメントのPDF版を翻訳する場合よりも、アプローチははるかに簡単になります。 +- _どのローカライゼーションツールがこのファイルタイプをサポートしていますか？ _元の書式を保持したままファイルを翻訳できますか？_ + - すべてのファイルタイプが直接のローカライゼーションをサポートしているわけではなく (例：PDFファイル、画像ファイル)、すべてのローカライゼーションツールがすべてのファイルタイプをサポートしているわけでもありません。 +- _誰がコンテンツを翻訳しますか？ _プロの翻訳を注文しますか、それともボランティアに頼りますか？_ + - これは、あなたが行う必要がある他の多くの決定に影響します。 たとえば、プロの翻訳者は、ボランティアよりも高度なローカライゼーションツールを扱うことに慣れています。 +- _言語学者に何を期待しますか？ _言語サービスプロバイダーを使用している場合、彼らはあなたに何を期待しますか？_ + - これは、目標、期待、タイムラインが一致していることを確認するステップです。 +- _翻訳対象のすべてのコンテンツは同じように重要ですか？ _一部のコンテンツを先に翻訳すべきですか？_ + - 特定のコンテンツを優先し、最初に翻訳して実装する方法がいくつかあります。 たとえば、翻訳するコンテンツが多い場合は、バージョン管理を使用して、翻訳者が優先すべきコンテンツを認識できるようにすることができます。 + +2. **翻訳用ファイルの共有** – このステップには長期的な思考も必要であり、原文ファイルを言語サービスプロバイダーに送信するほど単純ではありません。 + +- _誰がコンテンツを翻訳しますか？ _このプロセスには何人が関与しますか？_ + - ローカライゼーションツールを使用する予定がある場合、原文ファイルをツールに直接アップロードできるため、このステップは簡素化されます。 翻訳プロセスがホスティングサービス上で行われる場合も同様です。原文ファイルをどこにもエクスポートする必要がないためです。 +- _原文ファイルは手動で処理されますか、それともこのプロセスを自動化できますか？_ + - ほとんどのローカライゼーションツールでは、ファイル管理プロセスのある種の統合または自動化が可能です。 一方、個人の翻訳者と協力していてローカライゼーションツールを使用していない場合、数百または数千の翻訳者に手動で原文ファイルを送信することは、スケーラブルなプロセスではありません。 +- _ローカライゼーションにはどのツールが使用されますか？_ + - この質問への答えが、他のすべてへのアプローチ方法を決定します。 適切なツールを選択することで、コンテンツ管理、翻訳メモリと用語集の管理、翻訳者の管理、翻訳/レビューの進捗状況の追跡などを自動化できます。したがって、使用したいツールについて時間をかけて調査してください。 ローカライゼーションツールを使用する予定がない場合、上記のすべてを手動で行う必要があります。 +- _翻訳プロセスにはどのくらいの時間がかかりますか？ _費用はいくらかかりますか？_ + - この時点で、原文ファイルを言語サービスプロバイダーまたは翻訳者プールと共有する準備が整っているはずです。 言語サービスプロバイダーは、単語数の分析を支援し、翻訳プロセスの料金とタイムラインを含む見積もりを提供できます。 +- _このプロセス中に原文コンテンツを変更/更新する予定はありますか？_ + - コンテンツが動的で頻繁に変更される場合、変更やアップデートによって翻訳の進捗が妨げられる可能性があります。 翻訳メモリを使用すると、これを大幅に軽減できますが、プロセスがどのように機能するか、翻訳者の進捗を妨げないようにする方法を考えることは依然として重要です。 + +3. **翻訳プロセスの管理** – 原文コンテンツを言語サービスプロバイダーまたは翻訳者に引き渡しても、あなたの仕事は終わりではありません。 翻訳の最適な品質を確保するために、コンテンツ作成者は可能な限り翻訳プロセスに関与する必要があります。 + +- _翻訳者とどのようにコミュニケーションを取る予定ですか？_ + - ローカライゼーションツールを使用する予定がある場合、コミュニケーションはツール内で直接行うことができます。 翻訳者との代替コミュニケーションチャネルを設定することも推奨されます。そうすることで、翻訳者が連絡を取るのをためらわなくなり、メッセージングツールによってより自由なコミュニケーションが可能になるためです。 +- _翻訳者からの質問にどのように対応しますか？ _誰がこれらの質問に答えるべきですか？_ + - 翻訳者 (プロと非プロの両方) は、質問や明確化、追加の文脈の要求、フィードバック、改善のアイデアなどについて、しばしば連絡してきます。 これらの問い合わせに返信することは、エンゲージメントと翻訳コンテンツの品質向上につながることがよくあります。 また、できるだけ多くのリソース (例：ガイド、ヒント、用語ガイドライン、FAQなど) を提供することも貴重です。 +- _レビュープロセスはどのように処理しますか？ _それをアウトソースしますか、それとも社内でレビューを実行する能力がありますか？_ + - 常に必要というわけではありませんが、レビューは最適な翻訳プロセスの不可欠な部分です。 通常、レビュープロセスをプロのレビュー担当者にアウトソースするのが最も簡単です。 しかし、大規模な国際チームがいる場合は、レビューやQAを社内で処理することもできます。 + +4. **翻訳されたコンテンツの実装** – ワークフローの最後の部分ですが、事前に考慮することが重要です。 + +- _すべての翻訳は同時に完了しますか？_ + - そうでない場合は、どの翻訳を優先すべきか、進行中の翻訳をどのように追跡するか、翻訳が行われている間に実装をどのように処理するかを考える必要があります。 +- _翻訳されたコンテンツはどのように配信されますか？ _どのような形式になりますか？_ + - これは、どのアプローチを使用するかにかかわらず、重要な考慮事項です。 ローカライゼーションツールを使用すると、ターゲットファイル形式とエクスポートプロセスを管理でき、通常はホスティングサービスとの統合を有効にすることで自動化をサポートします。 +- _プロジェクトに翻訳をどのように実装しますか？_ + - 場合によっては、翻訳されたファイルをアップロードしたり、ドキュメントに追加したりするだけで済むこともあります。 しかし、ウェブサイトやアプリの翻訳のようなより複雑なプロジェクトでは、コードが国際化をサポートしていることを確認し、実装プロセスがどのように処理されるかを事前に確立する必要があります。 +- _書式が原文と異なる場合はどうなりますか？_ + - 上記と同様に、単純なテキストファイルを翻訳している場合、書式はそれほど重要ではないかもしれません。 しかし、ウェブサイトやアプリケーションのコンテンツのようなより複雑なファイルでは、プロジェクトに実装するために、書式とコードが原文と同一である必要があります。 そうでない場合、ターゲットファイルは翻訳者または開発者によって編集される必要があります。 + +**意味 2** + +内部の決定やアプローチを考慮しない、代替の翻訳ワークフロー。 ここでの主な考慮事項は、コンテンツ自体の流れです。 + +この場合のワークフローの例は次のとおりです。 + +1. _翻訳 → 実装_ + +- 最も単純なワークフローで、実装前に品質を評価し、翻訳を編集するためのレビューやQAプロセスがないため、翻訳は人間による翻訳になる可能性が高いです。 +- このワークフローでは、翻訳者が一定の品質レベルを維持することが重要であり、そのためにはプロジェクトマネージャーと翻訳者の間で適切なリソースとコミュニケーションが必要になります。 + +2. _翻訳 → レビュー → 実装_ + +- 翻訳の品質が許容可能で一貫していることを保証するためのレビューと編集プロセスを含む、より高度なワークフロー。 +- このワークフローにはいくつかのアプローチがあり、翻訳はプロの翻訳者またはボランティアによって行われ、レビュープロセスは、ターゲット言語で遵守する必要があるすべての文法および正書法ルールに精通したプロのレビュー担当者によって処理される可能性が高いです。 + +3. _翻訳 → レビュー → QA → 実装_ + +- 最高レベルの品質を確保するための最適なワークフロー。 QAは常に必要というわけではありませんが、翻訳とレビュー後の翻訳テキストの品質をよりよく把握するのに役立ちます。 +- このワークフローでは、翻訳はボランティアまたは機械翻訳によってのみ行われる可能性があります。 レビュープロセスはプロの翻訳者が行うべきであり、QAは、ターゲット言語のネイティブスピーカーである従業員がいる場合は、言語サービスプロバイダーまたは社内で行うことができます。 + +翻訳ワークフローの詳細については、以下をご覧ください。 + +[翻訳ワークフローの5つのフェーズに関するコンテンツルール](https://contentrules.com/creating-translation-workflow/) + +[Smartlingによる翻訳ワークフロー管理とは](https://www.smartling.com/resources/101/what-is-translation-workflow-management/) + +[RixTransによる翻訳ワークフロー](https://www.rixtrans.com/translation-workflow) + +## 用語管理 {#terminology-management} + +用語の取り扱い方法に関する明確な計画を立てることは、翻訳の品質と一貫性を確保し、翻訳者の時間を節約するための最も重要なステップの1つです。 + +翻訳分野では、これは用語管理として知られており、言語サービスプロバイダーが、言語学者のプールへのアクセスとコンテンツ管理に加えて、クライアントに提供する主要なサービスの1つです。 + +用語管理とは、プロジェクトにとって重要であり、常に正しく一貫して翻訳されるべき用語を特定、収集、管理するプロセスを指します。 + +用語管理について考え始めるときに、従うべきいくつかのステップがあります。 + +- 用語ベースに含めるべき主要な用語を特定する。 +- 用語とその定義の用語集を作成する。 +- 用語を翻訳し、用語集に追加する。 +- 翻訳をチェックして承認する。 +- 用語集を維持し、重要になった新しい用語で更新する。 + +用語管理の詳細については、以下をご覧ください。 + +[Tradosによる用語管理とは](https://www.trados.com/solutions/terminology-management/translation-101-what-is-terminology-management.html) + +[Language Scientificによる用語管理が重要な理由](https://www.languagescientific.com/terminology-management-why-it-matters/#:~:text=Terminology%20management%20is%20the%20process,are%20related%20to%20each%20other.) + +[Clear Words Translationによる用語管理とその重要性](http://clearwordstranslations.com/language/en/what-is-terminology-management/) + +### 翻訳メモリと用語集 {#tm-and-glossary} + +翻訳メモリと用語集は、翻訳業界における重要なツールであり、ほとんどの言語サービスプロバイダーが依存しているものです。 + +これらの用語が何を意味し、互いにどのように異なるかを見てみましょう。 + +**翻訳メモリ (TM)** – 長いテキストのブロック、完全な文、段落、個々の用語を含むセグメントや文字列、および各言語での現在および以前の翻訳を自動的に保存するデータベース。 + +ほとんどのローカライゼーションツール、翻訳管理システム、コンピュータ支援翻訳ツールには、翻訳メモリが組み込まれており、通常はエクスポートして他の同様のツールでも使用できます。 + +翻訳メモリを使用する利点には、翻訳の高速化、翻訳品質の向上、原文コンテンツの更新または変更時に特定の翻訳を保持する能力、反復的なコンテンツの翻訳コストの削減などがあります。 + +翻訳メモリは、異なるセグメント間のパーセンテージマッチに基づいて機能し、通常、2つのセグメントに同じコンテンツが50%以上含まれている場合に最も役立ちます。 また、100%一致する反復的なセグメントを自動的に翻訳するためにも使用され、反復的なコンテンツを複数回翻訳する必要がなくなります。 + +翻訳メモリの詳細については、以下をご覧ください。 + +[Memsourceによる翻訳メモリ](https://www.memsource.com/translation-memory/) + +[Smartlingによる翻訳メモリとは](https://www.smartling.com/resources/101/what-is-translation-memory/) + +**用語集 –** 重要または機密性の高い用語、その定義、機能、および確立された翻訳のリスト。 用語集と翻訳メモリの主な違いは、用語集は自動的に作成されず、完全な文の翻訳を含まないことです。 + +ほとんどのローカライゼーションツール、翻訳管理システム、コンピュータ支援翻訳ツールには、プロジェクトにとって重要な用語が含まれていることを確認するために維持できる用語集が組み込まれています。 TMと同様に、用語集も通常はエクスポートして他のローカライゼーションツールで使用できます。 + +翻訳プロジェクトを開始する前に、時間をかけて翻訳者とレビュー担当者のための用語集を作成することを強くお勧めします。 用語集を使用すると、重要な用語が正しく翻訳され、翻訳者に必要な文脈が提供され、翻訳の一貫性が保証されます。 + +用語集はほとんどの場合、ターゲット言語で確立された翻訳を含んでいますが、それがなくても役立ちます。 確立された翻訳がなくても、用語集は技術用語の定義を持ち、翻訳すべきでない用語を強調表示し、特定の用語が名詞、動詞、固有名詞、またはその他の品詞として使用されるかどうかを翻訳者に知らせることができます。 + +用語集の詳細については、以下をご覧ください。 + +[Lionbridgeによる翻訳用語集とは](http://info.lionbridge.com/rs/lionbridge/images/Lionbridge%20FAQ_Glossary_2013.pdf) + +[Transifexによる用語集](https://docs.transifex.com/glossary/glossary) + +プロジェクトにローカライゼーションツールを使用する予定がない場合、翻訳メモリと用語集を使用することはできないでしょう (Excelファイルで用語集や用語ベースを作成することはできますが、自動化された用語集は翻訳者が手動で用語とその定義を探す必要をなくします)。 + +これは、すべての反復的で類似したコンテンツを毎回手動で翻訳する必要があることを意味します。 さらに、翻訳者は、特定の用語を翻訳する必要があるかどうか、テキストでどのように使用されているか、用語にすでに確立された翻訳があるかどうかについて、質問するために連絡を取る必要があります。 + +_プロジェクトでethereum.orgの翻訳メモリと用語集を使用しますか？_ translations@ethereum.orgまでご連絡ください。_ + +## 翻訳者の募集 {#translator-outreach} + +**言語サービスプロバイダーとの協力** + +言語サービスプロバイダーとそのプロの翻訳者と協力している場合、このセクションはあまり関係ないかもしれません。 + +この場合、必要なすべてのサービス (例：翻訳、レビュー、QA) を多くの言語で提供できる能力を持つ言語サービスプロバイダーを選択することが重要です。 + +提示された料金のみに基づいて言語サービスプロバイダーを選択したくなるかもしれませんが、最大の言語サービスプロバイダーが高い料金を設定しているのには理由があることに注意することが重要です。 + +- 彼らはデータベースに数万人の言語学者を抱えています。つまり、特定のセクターに関する十分な経験と知識を持つ翻訳者をプロジェクトに割り当てることができます (つまり、技術翻訳者)。 +- 彼らはさまざまなプロジェクトに取り組み、クライアントの多様なニーズに応えてきた豊富な経験を持っています。 つまり、彼らは特定のワークフローに適応し、翻訳プロセスのための貴重な提案や改善の可能性を提示し、ニーズ、要件、締め切りを満たす可能性が高いということです。 +- 最大の言語サービスプロバイダーのほとんどは、使用できる独自のローカライゼーションツール、翻訳メモリ、用語集も持っています。 そうでない場合でも、彼らは少なくとも、翻訳者が使用したいローカライゼーションツールに精通し、作業できるように、プールに十分な言語学者を抱えています。 + +世界最大の言語サービスプロバイダーの詳細な比較、それぞれに関するいくつかの詳細、提供するサービス、地理データなどによる内訳は、[2021 Nimdzi 100レポート](https://www.nimdzi.com/nimdzi-100-top-lsp/)で確認できます。 + +**非プロの翻訳者との協力** + +非プロの翻訳者と協力し、翻訳を手伝ってくれるボランティアを探しているかもしれません。 + +人々に連絡を取り、プロジェクトへの参加を呼びかける方法はいくつかあります。 これは、あなたの製品と、すでに持っているコミュニティの規模に大きく依存します。 + +ボランティアをオンボーディングする方法のいくつかを以下に示します。 + +**募集 –** これは以下の点でいくらかカバーされていますが、潜在的なボランティアに連絡を取り、翻訳イニシアチブについて認識させることは、それ自体で効果的です。 + +多くの人々は、お気に入りのプロジェクトに関与し、貢献したいと考えていますが、開発者であるか、特別な技術スキルがないと、それを行う明確な方法が見つからないことがよくあります。 プロジェクトについての認知度を高めることができれば、多くのバイリンガルが関与することに熱心になるでしょう。 + +**コミュニティ内での探し方 –** この分野のほとんどのプロジェクトには、すでに大規模で活発なコミュニティがあります。 コミュニティメンバーの多くは、簡単な方法でプロジェクトに貢献する機会を高く評価するでしょう。 + +オープンソースプロジェクトへの貢献は、多くの場合、内発的な動機に基づいていますが、素晴らしい学習体験でもあります。 プロジェクトについてもっと学びたいと思っている人は誰でも、ボランティアとして翻訳プログラムに参加することを喜んでくれるでしょう。それは、自分が気にかけていることに貢献したという事実と、集中的な実践的な学習体験を組み合わせることができるからです。 + +**製品内でのイニシアチブの言及 –** 製品が人気で多くの人々に使用されている場合、翻訳プログラムを強調し、製品の使用中にユーザーに行動を呼びかけることは非常に効果的です。 + +これは、アプリケーションやウェブサイトの製品にCTA付きのバナーやポップアップを追加するのと同じくらい簡単です。 これは効果的です。なぜなら、ターゲットオーディエンスはあなたのコミュニティ、つまり最初に関与する可能性が最も高い人々だからです。 + +**ソーシャルメディア –** ソーシャルメディアは、翻訳プログラムについての認知度を高め、コミュニティメンバーだけでなく、まだコミュニティメンバーではない他の人々にも働きかける効果的な方法です。 + +DiscordサーバーやTelegramチャンネルがある場合、それを使って募集活動、翻訳者とのコミュニケーション、コントリビューターへの謝辞を伝えるのが簡単です。 + +X (旧Twitter) のようなプラットフォームも、新しいコミュニティメンバーをオンボーディングしたり、コントリビューターを公に謝辞したりするのに役立ちます。 + +Linux Foundationは、オープンソースコントリビューターとその動機を分析した広範な[2020 FOSSコントリビューター調査に関するレポート](https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf)を作成しました。 + +## 結論 {#conclusion} + +このドキュメントには、すべての翻訳プログラムが認識すべきいくつかの主要な考慮事項が含まれています。 これは決して網羅的なガイドではありませんが、翻訳業界での経験がない人がプロジェクトの翻訳プログラムを組織するのに役立ちます。 + +翻訳プログラムの管理に関するさまざまなツール、プロセス、重要な側面についてのより詳細な指示や内訳を探している場合は、最大の言語サービスプロバイダーの一部がブログを維持しており、ローカライゼーションプロセスのさまざまな側面に関する記事を頻繁に公開しています。 これらは、上記のいずれかのトピックをさらに深く掘り下げ、ローカライゼーションプロセスが専門的にどのように機能するかを理解したい場合に最適なリソースです。 + +各セクションの最後にいくつかの関連リンクが含まれていますが、オンラインで他の多くのリソースを見つけることができます。 + +協力の提案や、ethereum.org翻訳プログラムを維持することで得た追加情報、学習、ベストプラクティスについては、translations@ethereum.orgまでお気軽にお問い合わせください。 diff --git a/public/content/translations/ja/contributing/translation-program/resources/index.md b/public/content/translations/ja/contributing/translation-program/resources/index.md index 4125fd6a06b..820e6a5b6e4 100644 --- a/public/content/translations/ja/contributing/translation-program/resources/index.md +++ b/public/content/translations/ja/contributing/translation-program/resources/index.md @@ -1,44 +1,49 @@ --- -title: 翻訳者のためのリソース +title: "翻訳者のためのリソース" lang: ja -description: ethereum.org翻訳者向けの有用なリソース +description: "ethereum.org翻訳者向けの有用なリソース" --- -# リソース {#resources} +# 参考リソース {#resources} ethereum.org翻訳者向けの有用なガイド、ツール、翻訳コミュニティ、最新情報を以下から見つけられます。 ## ガイド {#guides} -- [翻訳スタイルガイド](/contributing/translation-program/translators-guide/) _– ethereum.org翻訳者向けの説明とヒント_ -- [翻訳に関するよくある質問](/contributing/translation-program/faq/) _– ethereum.org 翻訳プログラムに関するよくある質問とその回答_ -- [Crowdinオンラインエディタガイド](https://support.crowdin.com/online-editor/) _– Crowdinオンラインエディタと高度な機能を使用するための詳細なガイド_ -- [コンテンツバケット](/contributing/translation-program/content-buckets/) _– ethereum.orgのコンテンツバケットに含まれているページ_ +- [翻訳スタイルガイド](/contributing/translation-program/translators-guide/) _– ethereum.org翻訳者向けの指示とヒント_ +- [翻訳に関するよくある質問](/contributing/translation-program/faq/) _– ethereum.org翻訳プログラムに関するよくある質問と回答_ +- [Crowdinオンラインエディターガイド](https://support.crowdin.com/online-editor/) _– Crowdinオンラインエディターの使用方法と、Crowdinの高度な機能に関する詳細なガイド_ ## ツール {#tools} -- [Linguee](https://www.linguee.com/) _– 単語やフレーズでの検索が可能な翻訳・辞書検索エンジン_ -- [Proz term search](https://www.proz.com/search/) _– 専門用語の翻訳辞書・用語集のデータベース_ -- [Eurotermbank](https://www.eurotermbank.com/) _– 42言語の欧州用語集_ +- [Linguee](https://www.linguee.com/) + _– 単語やフレーズでの検索が可能な翻訳・辞書検索エンジン_ +- [Proz term search](https://www.proz.com/search/) + _– 専門用語の翻訳辞書・用語集のデータベース_ +- [Eurotermbank](https://www.eurotermbank.com/) + _– 42言語の欧州用語集_ ## コミュニティ {#communities} -- [言語別のDiscord翻訳グループ](https://discord.gg/ethereum-org) _– ethereum.orgの翻訳者を翻訳グループにつなげる取り組み_ -- [中国語翻訳者グループ](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) _– 中国語翻訳者間の調整を容易にするノーションページ_ +- [言語別のDiscord翻訳グループ](https://discord.gg/ethereum-org) + _– ethereum.orgの翻訳者を翻訳グループにつなげる取り組み_ +- [中国語翻訳者グループ](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) + _– 中国語翻訳者間の連携を円滑にするためのNotionページ_ -## 最新情報 {#latest-updates} +## 最新アップデート {#latest-updates} -最新の翻訳プログラムの進捗状況については、[イーサリアム・ファウンデーションのブログ](https://blog.ethereum.org/)をご覧ください。 +翻訳プログラムの最新の進捗状況を把握するには、[イーサリアム・ファウンデーションのブログ](https://blog.ethereum.org/)をフォローしてください: -- [2021年10月マイルストーンの更新](https://blog.ethereum.org/2021/10/04/translation-program-update/) -- [2020年12月マイルストーンの更新](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/) -- [2020年7月のマイルストーンの更新](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/) -- [2019年8月翻訳プログラム始動](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/) +- [2021年10月のマイルストーンアップデート](https://blog.ethereum.org/2021/10/04/translation-program-update/) +- [2020年12月のマイルストーンアップデート](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/) +- [2020年7月のマイルストーンアップデート](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/) +- [2019年8月の翻訳プログラム開始](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/) -## 翻訳者のためのオフィスアワー {#office-hours} +## 翻訳者向けオフィスアワー {#office-hours} -毎月第2水曜日に翻訳者のためのオフィスアワーを設けています。 これらは、[ethereum.org Discord](https://discord.gg/ethereum-org) の#office-hours ボイスチャンネルで行われ、ここで正確な時間や追加の詳細を確認できます。 +毎月第2水曜日に翻訳者のためのオフィスアワーを設けています。 これらは[ethereum.org Discord](https://discord.gg/ethereum-org)の#office-hoursボイスチャンネルで開催され、そこで正確な時間や追加の詳細を確認できます。 -オフィスアワーには、翻訳者が翻訳プロセスについて質問したり、プログラムについてフィードバックをしたり、アイデアを共有したり、ethereum.orgのコアチームとチャットしたりすることができます。 最終的に、この会話を通じて、翻訳プログラムの最新動向を伝えて、重要なヒントや指示を貢献者の皆様と共有したいと考えています。 +オフィスアワーには、翻訳者が翻訳プロセスについて質問したり、プログラムについてフィードバックをしたり、アイデアを共有したり、ethereum.orgのコアチームとチャットしたりすることができます。 +最終的に、この会話を通じて、翻訳プログラムの最新動向を伝えて、重要なヒントや指示を貢献者の皆様と共有したいと考えています。 ethereum.org の翻訳者、または翻訳者になりたい方は、これらのセッションのいずれかにお気軽にご参加ください。 diff --git a/public/content/translations/ja/contributing/translation-program/translatathon/details/index.md b/public/content/translations/ja/contributing/translation-program/translatathon/details/index.md new file mode 100644 index 00000000000..adce77ab769 --- /dev/null +++ b/public/content/translations/ja/contributing/translation-program/translatathon/details/index.md @@ -0,0 +1,90 @@ +--- +title: "詳細とルール" +lang: ja +template: translatathon +--- + +![](./participate.png) + +Translatathonは誰でも参加でき、応募フォームに記入してCrowdinのプロジェクトに参加することで参加できます。 + +翻訳者は、翻訳期間中にCrowdinエディターで自分の言語の未翻訳の文字列に翻訳を提案することでポイントを集めます。 + +各参加者の最終スコアは、翻訳期間中に翻訳した単語数に基づくリーダーボードでの順位と、獲得した可能性のあるボーナスポイントによって決定されます。 + +## はじめに {#getting-started} + +翻訳プロセスはCrowdinのethereum.orgプロジェクトで行われ、翻訳者はethereum.orgウェブサイトのほぼすべてのコンテンツで構成される未翻訳の文字列に対する翻訳を提案します。 + +翻訳はオンラインエディターで直接提案されるため、ファイルや成果物をダウンロードまたはアップロードする必要はありません。 翻訳された各単語は追跡され、カウントされます。 + +**1) プロジェクトに参加する** + +- 貢献を開始するには、[Crowdinのethereum.orgプロジェクト](https://crowdin.com/project/ethereum-org)に参加してください。 +- サインインするか、アカウントを作成する必要があります。必要なのはメールアドレスとパスワードだけです。 + +**2) 言語を選択する** + +- ターゲット言語のリストから自分の言語を見つけ、その名前または旗をクリックして開きます。 +- 利用できない言語に翻訳したい場合は、Crowdinで[Ethereum.orgチーム](https://crowdin.com/profile/ethdotorg)に連絡するか、translations@ethereum.orgにメールを送信してください。リクエストに応じてターゲット言語を追加します。 + +**3) 未翻訳のファイルを開く** + +- 最初に翻訳を開始する未翻訳のファイルを見つけます。 ソースファイルを含むフォルダーは優先度に基づいているため、未翻訳のファイルを含む最初のフォルダーから翻訳を開始する必要があります。 +- 各ファイルには、ファイル内の翻訳可能なコンテンツがどのくらい翻訳され、承認されたかを示す進捗インジケーターがあります... いずれかのファイルの翻訳進捗状況が100%未満の場合は、翻訳してください。 + +**4) 未翻訳の文字列を翻訳する** + +- 翻訳するためにファイルを開くときは、未翻訳の文字列のみを翻訳していることを確認してください。 +- 各文字列には、_翻訳済み_、_未翻訳_、または_承認済み_かどうかを示すステータスインジケーターがあります。 ソース文字列にあなたの言語で翻訳がすでに提案されている場合は、翻訳する必要はありません。 +- エディターで文字列をフィルタリングして、_未翻訳を最初に表示_または_未翻訳のみ表示_することもできます。 + +Crowdinエディターのナビゲートと使用に関する詳細なガイドについては、すべてのTranslatathon参加者が当社の[翻訳方法](/contributing/translation-program/how-to-translate/)ガイドを読むことをお勧めします。 + +また、[翻訳スタイルガイド](/contributing/translation-program/translators-guide/)で、いくつかのヒントやベストプラクティスを見つけることもできます。 + +**ポイントの仕組み** + +すべてのTranslatathon参加者は、ethereum.orgのCrowdinプロジェクトおよびその他の対象プロジェクト(対象プロジェクトの完全なリストは以下で入手可能)のコンテンツを翻訳することにより、最終スコアに向けたポイントを獲得します。 + +スコアリングはシンプルです:**翻訳1単語 = 1ポイント** + +最終的なポイント割り当てを受けるには、提案された翻訳が評価プロセスに合格する必要があります。このプロセスでは、専門のレビュー担当者が各参加者の翻訳をチェックし、最低限の品質基準を満たしていること、およびその過程で機械翻訳やAI翻訳が使用されていないことを確認します。 + +## エコシステムコンテンツ {#ecosystem-content} + +ethereum.orgの翻訳プログラムは常時稼働しているため、ウェブサイト上のいくつかのターゲット言語での翻訳の進捗は、他の言語に比べて著しく高くなっています。 + +すべてのTranslatathon参加者が、できるだけ多くのコンテンツを翻訳し、最優秀賞を競う機会を平等に得られるように、Translatathonの一部であるソースコンテンツは、ethereum.orgウェブサイトのコンテンツだけに限定されていません。 + +対象プロジェクトのいずれかを翻訳した参加者は同等のポイントを獲得でき、いずれのプロジェクトでも翻訳1単語=1ポイントとなります。 + +以下は、2025 Translatathonの一部であるすべての対象プロジェクトのリストです: + +- [Ethereum.org](https://crowdin.com/project/ethereum-org) + +- [Ethereum.orgデベロッパーチュートリアル](https://crowdin.com/project/33388446abbe9d7aa21e42e49bba7f97) + +- [EthStakerデポジットCLI](https://crowdin.com/project/ethstaker-deposit-cli) + +- [Eth Dockerドキュメント](https://crowdin.com/project/eth-docker-docs) + +- [Remix IDEドキュメント](https://crowdin.com/project/remix-translation) + +- [Remix LearnEth](https://crowdin.com/project/remix-learneth) + +- [web3.py](https://crowdin.com/project/web3py) + +## 評価プロセス {#evaluation-process} + +すべての翻訳は品質保証(QA)とフィードバックの対象となり、専門の言語学者が品質と正確性に基づいて提出物を評価します。 + +また、機械翻訳やAI翻訳を自動的に検出するツールを使用して、**機械翻訳対策**も実施します。 + +翻訳の品質はスコアリングにおいて重要な役割を果たしませんが、**機械翻訳やAI翻訳を使用していることが判明した参加者**や、低品質で不正確な翻訳を提案した参加者は、賞品の対象外となります。 + +評価期間は9月中に行われ、結果は9月25日のethereum.orgコミュニティコールで発表されます。 + +すべての翻訳は、ウェブサイトに追加される前に完全にレビューされます。 + + diff --git a/public/content/translations/ja/contributing/translation-program/translatathon/index.md b/public/content/translations/ja/contributing/translation-program/translatathon/index.md new file mode 100644 index 00000000000..d477c04c85a --- /dev/null +++ b/public/content/translations/ja/contributing/translation-program/translatathon/index.md @@ -0,0 +1,100 @@ +--- +title: "2025 ethereum.org トランスレイトソン" +lang: ja +template: translatathon +--- + + + + + + + +## はじめに {#introduction} + +私たちは、使用する言語に関わらず、誰もがイーサリアムのコンテンツやオンボーディングのリソースにアクセスできるべきだと考えています。 +この目標に近づくために、ethereum.org翻訳プログラムは、ウェブサイトをできるだけ多くの言語に翻訳するイニシアチブです。 + +翻訳プログラムの一環として、私たちは第3回トランスレイトソンを開催します。これは、あまり活発でない言語への翻訳貢献を奨励し、サイトで利用可能な言語とコンテンツの量を増やし、新しいコントリビューターを迎え入れ、既存のコントリビューターに報酬を与えることを目的とした翻訳コンテストです。 + +あなたが英語以外の言語のネイティブスピーカーで、賞品を競いながらイーサリアムのコンテンツをよりアクセスしやすくすることに貢献したいとお考えなら、ぜひ読み進めて詳細をご確認ください！ + +[ethereum.org翻訳プログラムについて詳しく知る](/contributing/translation-program/) + +## タイムライン {#timeline} + +2025年トランスレイトソンの重要な日程は以下の通りです： + + + + + +## 参加 {#participate} + +![コミュニティと地球の画像](./participate.png) + + + +

誰が参加できますか？

+ 18歳以上で、英語以外の言語を少なくとも1つ母国語とし、英語に堪能な方ならどなたでも参加できます。 + + +

翻訳者である必要がありますか？

+ できません。 バイリンガルであり、人力による翻訳を提案するだけで大丈夫です (機械翻訳の使用は禁止されています！)。 ご自身の能力の限りを尽くしていただければ、専門的な経験は必要ありません。 + + + + + +

どれくらいの時間を費やす必要がありますか？

+ 好きなだけ時間を費やせます。 賞品の対象となるための最低基準は1,000単語の翻訳で、これには約2時間かかると予想されます。一方、上位の賞品を狙うには、より多くの時間を費やす必要があります。 + + +

イーサリアムに精通している必要はありますか？

+ できません。 イーサリアムに精通していると生産性と品質の向上に役立ちますが、トランスレイトソンは学習体験でもあります。参加しながらイーサリアムについてさらに学ぶために、どなたでもご参加いただけます。 + + + +詳細については、[利用規約の全文をご覧ください](/contributing/translation-program/translatathon/terms-and-conditions) + +### ステップバイステップの手順 {#step-by-step-instructions} + + + +## 賞品 {#prizes} + +| 順位 | 賞金額 | +| --------- | ----- | +| 1位 | $4000 | +| 2位 | $2500 | +| 3位 | $1500 | +| 4位 | $1100 | +| 5位 | $1000 | +| 6位 | $600 | +| 7位 | $550 | +| 8位 | $500 | +| 9位 | $450 | +| 10位 | $400 | +| 11位～20位 | $240 | +| 21位～50位 | $120 | +| 51位～100位 | $60 | +| 101位～150位 | $40 | +| その他 | $20 | + +すべての賞金はETHで支払われます。 + + + + diff --git a/public/content/translations/ja/contributing/translation-program/translators-guide/index.md b/public/content/translations/ja/contributing/translation-program/translators-guide/index.md index 750d214ed35..44cd47b93d2 100644 --- a/public/content/translations/ja/contributing/translation-program/translators-guide/index.md +++ b/public/content/translations/ja/contributing/translation-program/translators-guide/index.md @@ -1,22 +1,22 @@ --- -title: 翻訳者ガイド +title: "翻訳者ガイド" lang: ja -description: ethereum.org翻訳者向けの説明とヒント +description: "ethereum.org翻訳者向けの説明とヒント" --- -# ethereum.org翻訳スタイルガイド {#style-guide} +# Ethereum.org 翻訳スタイルガイド {#style-guide} ethereum.org翻訳スタイルガイドには、翻訳者向けの最も重要なガイドライン、説明、ヒントを記載しています。ウェブサイトのローカライズに役立ててください。 本ドキュメントは一般的なガイドであり、特定の言語に固有のものではありません。 -ご質問、ご提案、ご意見などございましたら、translations@ethereum.orgまでお気軽にお問い合わせください。またはCrowdinで@ethdotorgにメッセージを送るか、 [Discordに参加](https://discord.gg/ethereum-org)して、#translationチャンネルでメッセージ、またはチームメンバーに直接連絡を取ることも可能です。 +ご質問、ご提案、フィードバックがございましたら、translations@ethereum.orgまでお気軽にご連絡いただくか、Crowdinで@ethdotorgにメッセージを送信、または[私たちのDiscordに参加](https://discord.gg/ethereum-org)してください。#translationsチャンネルでメッセージを送信したり、チームメンバーに連絡を取ることができます。 ## Crowdinの使用 {#using-crowdin} -Crowdinでプロジェクトに参加する方法とCrowdinオンラインエディタの使い方については、 [翻訳プログラムページ](/contributing/translation-program/#how-to-translate)に基本的な事項が紹介されています。 +Crowdinでのプロジェクトへの参加方法とCrowdinオンラインエディタの使用方法に関する基本的な手順については、[翻訳プログラムのページ](/contributing/translation-program/#how-to-translate)でご確認いただけます。 -Crowdinの詳細とその高度な機能の一部を使用したい場合は、 [Crowdinのナレッジベース](https://support.crowdin.com/online-editor/)にCrowdinのすべての機能の詳細なガイドと概要が記載されています。 +Crowdinについて、またその高度な機能の使用方法についてさらに詳しく知りたい場合は、[Crowdinナレッジベース](https://support.crowdin.com/online-editor/)に、Crowdinの全機能に関する詳細なガイドと概要が多数掲載されています。 ## メッセージの本質を捉える {#capturing-the-essence} @@ -28,7 +28,7 @@ ethereum.org コンテンツを翻訳するときは、直訳はしないでく ソースを直訳するのではなく、 一度文章全体を読んで翻訳する言語の文法に合うように変えてください。 -## フォーマルかインフォーマルか {#formal-vs-informal} +## フォーマルとインフォーマル {#formal-vs-informal} 常に、すべての訪問者に対して、丁寧かつ適切なフォーマルな形式を使います。 @@ -42,7 +42,7 @@ ethereum.org コンテンツを翻訳するときは、直訳はしないでく 短く簡単な用語を使用することによって、この目的を容易に達成できる場合が多いです。 ある単語に対して、同じ意味を持つ複数の翻訳がある場合、 最も短い単語で、意味を明確に反映しているものを選ぶようにします。 -## 表記方法 {#writing-system} +## 表記体系 {#writing-system} ethereum.orgは多くの言語で利用可能で、ラテンではない翻訳言語で表記します。 @@ -50,17 +50,17 @@ ethereum.orgは多くの言語で利用可能で、ラテンではない翻訳 コンテンツを翻訳する際には、翻訳に一貫性があり、ラテン文字が含まれていないことを意識してください。 -よくある誤解には、イーサリウムを常に「Ethereum」とラテン文字で記載しなければならないというものがあります。 これは多くの場合誤りであり、日本語の場合は「イーサリアム」(他の言語では中国語「以太坊」 、アラビア語「إيثيريوم」など)と記載します。 +よくある誤解には、イーサリアムを常に「Ethereum」とラテン文字で記載しなければならないというものがあります。 これはほとんどの場合、正しくありません。日本語の「イーサリアム」のように、あなたの言語に固有のスペルを使用してください (例: 中国語では「以太坊」、アラビア語では「إيثيريوم」など)。 -**上記は、原則として固有名詞が翻訳されるべきでない言語には該当しません。** +**上記は、原則として固有名詞を翻訳すべきではない言語には適用されません。** -## ページのメタデータの翻訳 {#translating-metadata} +## ページメタデータの翻訳 {#translating-metadata} ページによっては、「title」、「lang」、「description」、「sidebar」などのメタデータを含むものもあります。 Crowdinに新しいページをアップロードする際、翻訳者が翻訳すべきではないコンテンツは非表示にしています。つまり、Crowdinの翻訳者に表示される、これらのメタデータはすべて翻訳する必要があります。 -ソースが「en」の文字列を翻訳する場合は特に注意してください。 これは、ページで利用可能な言語を表し、あなたの言語の [ISO言語コード](https://www.andiamo.co.uk/resources/iso-language-codes/)に変更する必要があります(日本語の場合は「ja」)。 これらの文字列は翻訳先の言語に固有の文字を書くのではなく、ラテン文字を使う必要があります。 +ソースが「en」の文字列を翻訳する場合は特に注意してください。 これは、ページが利用可能な言語を表しており、[あなたの言語に対応するISO言語コード](https://www.andiamo.co.uk/resources/iso-language-codes/)に変更する必要があります。 これらの文字列は翻訳先の言語に固有の文字を書くのではなく、ラテン文字を使う必要があります。 自分の言語コードが不明な場合は、 Crowdinで翻訳メモリを確認するか、CrowdinのオンラインエディタのページのURLで言語コードを確認することができます。 @@ -72,23 +72,26 @@ Crowdinに新しいページをアップロードする際、翻訳者が翻訳 - ヒンディー語 - hi - スペイン語 - es -## 外部記事のタイトル {#external-articles} +## 外部リンク先の記事タイトル {#external-articles} 外部記事のタイトルを含む文字列もあります。 デベロッパー向けドキュメントページのほとんどには、外部記事へのリンクが含まれています。 訪問者が自分の言語でページを閲覧する際、より一貫性のあるユーザーエクスペリエンスとなるよう、記事が書かれている言語に関係なく、タイトルを翻訳する必要があります。 これらの文字列がどのように表示されるか、またこれらの識別方法を、以下に例として記載します(外部記事へのリンクは、主にページの下部の「参考文献」にあります)。 -![外部記事のタイトルsidebar.png](./article-titles-in-sidebar.png) ![エディタの外部記事のタイトルeditor.png](./article-titles-in-editor.png) +![サイドバーの記事タイトル](./article-titles-in-sidebar.png) +![エディタの記事タイトル](./article-titles-in-editor.png) ## Crowdinの警告 {#crowdin-warnings} -Crowdinには、間違いを防ぐための翻訳者に警告する機能が組み込まれています。 ソースにあるタグがターゲットに入っていない、翻訳するべきではない要素を翻訳、複数の連続したスペース、文末の句読点がない場合など、翻訳を保存する前にCrowdinが自動的に警告します。 このような警告が表示された場合は、翻訳に戻り、警告メッセージを再確認してください。 +Crowdinには、間違いを防ぐための翻訳者に警告する機能が組み込まれています。 ソースにあるタグがターゲットに入っていない、翻訳するべきではない要素を翻訳、複数の連続したスペース、文末の句読点がない場合など、翻訳を保存する前にCrowdinが自動的に警告します。 +このような警告が表示された場合は、翻訳に戻り、警告メッセージを再確認してください。 -**これらの警告は、通常は何かが間違っている、またはソーステキストの重要な部分が欠落していることを意味するため、無視しないでください。** +**これらの警告は、通常は何かが間違っている、または翻訳に原文の重要な部分が欠けていることを意味するため、決して無視しないでください。** -Crowdin警告の例(タグの追加漏れ):![Crowdinの警告例](./crowdin-warning-example.png) +翻訳にタグを追加し忘れた場合のCrowdin警告の例: +![Crowdin警告の例](./crowdin-warning-example.png) -## タグとコードスニペット {#dealing-with-tags} +## タグとコードスニペットの取り扱い {#dealing-with-tags} 多くのソースコンテンツにはタグと変数が含まれており、Crowdinエディタでは黄色にハイライト表示されます。 これらは異なる機能を提供し、それぞれ正しく翻訳する必要があります。 @@ -96,15 +99,18 @@ Crowdin警告の例(タグの追加漏れ):![Crowdinの警告例](./crowdin-warn タグを簡単に管理し、ソースから直接コピーできるように、Crowdinのエディタで下記のように設定を変更することをお勧めします。 -1. 設定を開きます![エディタで設定を開く方法](./editor-settings.png) +1. 設定を開く + ![エディタで設定を開く方法](./editor-settings.png) 2. [HTML tags displaying]までスクロールします -3. [Hide]を選択します ![[Hide]を選択](./hide-tags.png) +3. 「非表示」を選択 + ![「非表示」を選択してください](./hide-tags.png) 4. [Save]をクリックします -この設定を選択すると、タグがフルで表示されなくなり、番号で表示されます。 翻訳時にこのタグをクリックすると、自動で翻訳フィールドにタグをコピーできます。 +この設定を選択すると、タグがフルで表示されなくなり、番号で表示されます。 +翻訳時にこのタグをクリックすると、自動で翻訳フィールドにタグをコピーできます。 **リンク** @@ -112,11 +118,11 @@ ethereum.orgまたは他のウェブサイトのページへのフルリンク リンクはソースと全く同じである必要があります。変更や翻訳はしないでください。 リンクの翻訳、変更、またはバックスラッシュ(/)の削除などの一部の変更だけでも、そのリンクは壊れ、機能しなくなります。 -リンクを処理する場合、ソースから直接コピーするのが確実です。タグをクリックするか、\[Copy Source\] (Alt+C)を使用してください。 +リンクを処理する場合、ソースから直接コピーするのが確実です。タグをクリックするか、[Copy Source](Alt+C)を使用してください。 ![リンクの例link.png](./example-of-link.png) -また、リンクはタグ形式でソーステキストにも表示されます(例: \<0> \). タグにカーソルを合わせると、エディタにはフルコンテンツが表示されます。これらのタグはリンクを指定している場合があります。 +リンクは、原文にタグの形式(`<0>` ``など)で表示されることもあります。 タグにカーソルを合わせると、エディタにはフルコンテンツが表示されます。これらのタグはリンクを指定している場合があります。 ソースからリンクをコピーして、タグの順序を変更しないことが非常に重要です。 @@ -130,11 +136,11 @@ ethereum.orgまたは他のウェブサイトのページへのフルリンク タグは常に開始タグと終了タグのペアです。 ほとんどの場合、タグの開始と終了の間のテキストは、翻訳する必要があります。 -例: ``Decentralized`` +例: ``Decentralized`` `` - _テキストを太字にする開始タグ_ -Decentralized - _翻訳するテキスト_ +Decentralized - _翻訳対象のテキスト_ `` - _終了タグ_ @@ -144,9 +150,9 @@ Decentralized - _翻訳するテキスト_ 例: ``nonce`` -`` - _コードスニペットの開始タグく_ +`` - _コードスニペットを含む開始タグ_ -nonce - _翻訳しないテキスト_ +nonce - _翻訳対象外のテキスト_ `` - _終了タグ_ @@ -154,13 +160,13 @@ nonce - _翻訳しないテキスト_ ソーステキストに数値のみの短縮タグも含まれている場合があり、そのタグの意味がすぐには分からない場合があります。 これらのタグにカーソルを合わせると、タグの意味や機能を確認できます。 -以下の例では、 \<0> タグにカーソルを合わせると、 ``が表示され、コードスニペットであることが分かります。そのため、これらのタグ内のテキストは翻訳しないでください。 +以下の例では、`<0>`タグにカーソルを合わせると、それが``を表し、コードスニペットを含んでいることがわかります。したがって、これらのタグ内のコンテンツは翻訳しないでください。 ![不明なタグの例tags.png](./example-of-ambiguous-tags.png) -## 短縮語、非短縮語／略語 {#short-vs-full-forms} +## 短縮形と完全形/略語 {#short-vs-full-forms} -本ウェブサイトではdapp、NFT、DAO、DeFiなど多くの略語が使用されています。 これらの略語は英語で一般的に使用されており、ウェブサイトの多くの訪問者はそれらが何を意味するのか知っています。 +このウェブサイトでは、dapps、NFT、DAO、DeFiなど、多くの略語が使用されています。 これらの略語は英語で一般的に使用されており、ウェブサイトの多くの訪問者はそれらが何を意味するのか知っています。 これらの用語は、他の言語で確立された翻訳がないことが多いため、省略していない原語をフルで翻訳し、英語の略語を括弧で追加します。 @@ -168,9 +174,9 @@ nonce - _翻訳しないテキスト_ 「dapp」の翻訳例: -- Decentralized application (dapp) → _非省略形の用語の翻訳(英語の略語)_ +- Decentralized applications (dapps) → _翻訳された完全形 (括弧内に英語の略語)_ -## 確立された翻訳のない用語 {#terms-without-established-translations} +## 定訳のない用語 {#terms-without-established-translations} いくつかの用語は、他の言語では確立された用語がない場合があり、元の英語の用語の方が広く知られていることがあります。 このような用語には、主に、proof-of-work、proof-of-stake、Beacon Chain、stakingなどを含む比較的新しい概念のものが含まれます。 @@ -178,7 +184,7 @@ nonce - _翻訳しないテキスト_ それらを翻訳するときは、クリエイティブな翻訳、説明的な翻訳、もしくは単に文字通りに翻訳します。 -**大半の用語を英語ではなく、各言語に翻訳するのは、 イーサリアムと関連技術がより多くの人々に使われるにつれて、これらの新しい用語が将来、より広く普及するであろうという考えによるものです。 世界中のより多くの人々にイーサリアムを使用してもらうため、たとえ造語であっても可能な限り多くの言語で理解できる用語を提供する必要があります。** +**ほとんどの用語を英語のままにせず翻訳すべき理由は、将来、より多くの人々がイーサリアムや関連技術を使い始めるにつれて、この新しい専門用語がより広く普及するという事実にあります。** **世界中のより多くの人々をこの分野に迎え入れたいのであれば、たとえ自分たちで造語する必要があるとしても、できるだけ多くの言語で理解しやすい専門用語を提供する必要があります。** ## ボタンとCTA {#buttons-and-ctas} @@ -186,11 +192,11 @@ nonce - _翻訳しないテキスト_ ボタンのテキストは、ほとんどの文字列同様、コンテキストのスクリーンショット、またはエディタのコンテキストで確認することができます。(エディタのコンテキストに「button」と記載)。 -ボタンの翻訳は、書式の不一致を防ぐためにできるだけ短くする必要があります。 さらに、ボタンの翻訳は、コマンドやリクエストを示すものでなければなりません。 +ボタンの翻訳は、書式の不一致を防ぐためにできるだけ短くする必要があります。 さらに、ボタンの翻訳は、命令や要求を表す命令形にする必要があります。 ![ボタンを見つける方法button.png](./how-to-find-a-button.png) -## 包括性を踏まえた翻訳 {#translating-for-inclusivity} +## インクルーシビティを意識した翻訳 {#translating-for-inclusivity} ethereum.orgには、世界中から、さまざまな背景を持った訪問者が来ます。 そのため、ウェブサイトは中立的、かつ非排他的、すべての人を歓迎するものである必要があります。 @@ -200,7 +206,7 @@ ethereum.orgには、世界中から、さまざまな背景を持った訪問 最後に、すべての訪問者と年齢層に適している必要があります。 -## 言語特有の翻訳 {#language-specific-translations} +## 言語固有の翻訳 {#language-specific-translations} 翻訳するときは、ソースからコピーするのではなく、翻訳言語の文法ルール、規定、書式に従うことが重要です。 ソースは英語の文法ルールと規則に従っており、他の多くの言語には当てはまりません。 @@ -208,7 +214,7 @@ ethereum.orgには、世界中から、さまざまな背景を持った訪問 特に注意すべき事例: -### 句読点、書式設定 {#punctuation-and-formatting} +### 句読点、フォーマット {#punctuation-and-formatting} **大文字表記** @@ -220,16 +226,16 @@ ethereum.orgには、世界中から、さまざまな背景を持った訪問 - 各言語のスペースの使用については、正書法に従ってください。 スペースはあらゆるところで使われているため、最も目立つものであり、またスペースは最も誤りが多い点の一つです。 - 英語と他の言語のスペースの使用の一般的な違い: - - 単位と通貨(例: USD、EUR、kB、MB)の前のスペース - - 特殊記号の前のスペース(例:°C、°F) + - 計量単位や通貨 (例: USD、EUR、kB、MB) の前のスペース + - 度記号 (例: °C、℉) の前のスペース - 句読点の前のスペース、特にエリプシス(…)の前のスペース - スラッシュ(/)の前後のスペース -**箇条書き** +**リスト** - 箇条書きに関して、言語により多様で複雑な規則があります。 これらは英語とは大幅に異なる場合があります。 - ある言語では新しい行の最初の単語を大文字、またその他の言語では新しい行は小文字で始める必要があります。 各行の長さに応じて、箇条書きの大文字に関するルールも多くあります。 -- 同様のことが行項目の句読点にも当てはまります。 箇条書きの終止符は言語により、句点(**。**)、読点(**、**)、セミコロン(**;**)である場合があります。 +- 同様のことが行項目の句読点にも当てはまります。 リストの文末の句読点は、言語によってピリオド(.)、コンマ(,)、またはセミコロン(;)の場合があります。 **引用符** @@ -247,16 +253,16 @@ ethereum.orgには、世界中から、さまざまな背景を持った訪問 - 英語では、単語間や単語の異なる部分を結合するためにハイフン(-)が使用されます。対して、範囲を示したり、中断を入れるためにダッシュ(-)が使用されます。 - 言語により、ハイフンとダッシュの使用ルールが異なります。 -### 書式 {#formats} +### フォーマット {#formats} **数字** - 数字の表記に関する言語による主な違いは、小数と3桁の区切りに使用される区切り文字です。 千の単位の場合、ピリオド、カンマ、スペースが使われることがあります。 同様に、小数点を使用する言語もあれば、小数点にコンマを使用する言語もあります。 - 数字の表記の例: - - 英語 ｰ **1,000.50** - - スペイン語 ｰ **1.000,50** - - フランス語 ｰ **1,000,50** -- 数字を翻訳する際、気を付けるべきもう一つ重要な事項は、パーセント記号です。 **100%**、**100 %**または**%100**と異なる表記方法があります。 + - 英語 – **1,000.50** + - スペイン語 – **1.000,50** + - フランス語 – **1 000,50** +- 数字を翻訳する際、気を付けるべきもう一つ重要な事項は、パーセント記号です。 **100%**、**100 %**、**%100**など、さまざまな書き方があります。 - 最後に、マイナスの数字は言語により、 -100、100-、(100)、または[100]と表記方法が異なります。 **日付** @@ -284,7 +290,7 @@ ethereum.orgには、世界中から、さまざまな背景を持った訪問 - 原則として、単位はソースと同じにします。 あなたの国が別の単位を使用している場合は、括弧内に変換した数値と単位を記載することができます。 - 測定単位以外にも、言語によるこれらの単位の表記方法の違いについても注意することも重要です。 主には、数字と単位のスペースが言語により異なります。 例: 100kBと100 kB、 50ºFと50 ºFなど -## まとめ {#conclusion} +## 結論 {#conclusion} ethereum.orgを翻訳することでイーサリアムのさまざまな側面について学ぶことができます。 diff --git a/public/content/translations/ja/dao/index.md b/public/content/translations/ja/dao/index.md index c8bcea98654..8ffbf3f879d 100644 --- a/public/content/translations/ja/dao/index.md +++ b/public/content/translations/ja/dao/index.md @@ -1,15 +1,16 @@ --- -title: 分散型自律組織(DAO) -description: イーサリアムにおける分散型自律組織(DAO)の概要 +title: "DAOとは何ですか？" +metaTitle: "DAOとは何ですか？ | 分散型自律組織" +description: "イーサリアムにおける分散型自律組織(DAO)の概要" lang: ja template: use-cases emoji: ":handshake:" sidebarDepth: 2 image: /images/use-cases/dao-2.png -alt: 提案に対する分散型自律組織(DAO)投票 -summaryPoint1: 中央集権的な制御がない、メンバー所有のコミュニティ -summaryPoint2: インターネットの見知らぬ人と協力する安全な方法 -summaryPoint3: 特定の目的に資金を委ねるのに安全な場所 +alt: "提案に対する分散型自律組織(DAO)投票" +summaryPoint1: "中央集権的な制御がない、メンバー所有のコミュニティ" +summaryPoint2: "インターネットの見知らぬ人と協力する安全な方法" +summaryPoint3: "特定の目的に資金を委ねるのに安全な場所" --- ## 自律分散組織(DAO)とは {#what-are-daos} @@ -18,41 +19,41 @@ DAOは、共通の目的のために行動する、集団所有された組織 分散型自律組織(DAO)は資金や運営の管理において、誰かを信用することなく、世界中の同じ志を持つ人々と共に働くことを可能します。 気まぐれに資金を使い込むCEOはいませんし、帳簿を操作できるCFOもいません。 誰かを依存・信用するのではなく、ブロックチェーンベースのルールがコード化され、組織の運営や資金の使われ方を定義しています。 -グループの承認なしには誰もアクセスできない資金が組み込まれています。 意思決定は、提案と投票によって行われ、組織内の誰しもが発言権を持つことが保障されています。また、全て[オンチェーン](/glossary/#on-chain)で行われるため、透明性も確保されています。 +グループの承認なしには誰もアクセスできない資金が組み込まれています。 決定は提案と投票によって管理され、組織内の全員が発言権を持ち、すべてが透明に[オンチェーン](/glossary/#onchain)で行われることが保証されています。 ## 分散型自律組織(DAO)が必要な理由 {#why-dao} -組織を誰かと一緒に組織を立ち上げるには、資金やお金が関わるため、相手との信頼関係が必要になります。 しかし、インターネット上でしか交流のない人を信用するのは難しいと思います。 分散型自律組織(DAO)では、グループ内の他の誰かを信用する必要はなく、100％透明で誰でも検証可能なコードだけを信用すれば大丈夫です。 +資金や金銭が関わる組織を誰かと一緒に立ち上げるには、一緒に働く人々との間に多くの信頼が必要になります。 しかし、インターネット上でしか交流のない人を信用するのは難しいと思います。 分散型自律組織(DAO)では、グループ内の他の誰かを信用する必要はなく、100％透明で誰でも検証可能なコードだけを信用すれば大丈夫です。 これにより、グローバルなコラボレーションやコーディネーションに新たな可能性が広がりました。 ### 比較 {#dao-comparison} -| 分散型自律組織(DAO) | 従来の組織 | -| ----------------------------------------- | ----------------------------------------------- | -| 通常はフラットな組織で、完全に民主化 | 通常は階層的 | -| 変更を実行するには、メンバーによる投票が必要 | 組織構造によっては、単独の当事者から変更が要求されることがあり、または投票が行われる場合がある | -| 投票は集計され、結果は信頼できる仲介者なしに自動的に実行される | 投票が可能な場合、投票は内部で集計され、投票結果は手動での処理が必要 | +| 自律分散型組織 | 従来の組織 | +| ------------------------------------------------------------ | ----------------------------------------------- | +| 通常はフラットな組織で、完全に民主化 | 通常は階層的 | +| 変更を実行するには、メンバーによる投票が必要 | 組織構造によっては、単独の当事者から変更が要求されることがあり、または投票が行われる場合がある | +| 投票は集計され、結果は信頼できる仲介者なしに自動的に実行される | 投票が可能な場合、投票は内部で集計され、投票結果は手動での処理が必要 | | 提供されるサービスは、自動的に分散化された方法で処理される(例えば慈善資金の分配) | 人間による処理、または集中管理された自動化を必要とし、改ざんされるおそれがある | -| すべてのアクティビティは透明で完全に公開 | 通常、アクティビティは非公開で、一般には非公開 | +| すべてのアクティビティは透明で完全に公開 | 通常、アクティビティは非公開で、一般には非公開 | -### 分散型自律組織(DAO)の事例 {#dao-examples} +### DAOの例 {#dao-examples} もう少し理解を深められるように、分散型自律組織(DAO)の使用方法についていくつか例をご紹介します。 - **慈善事業** – 世界中の誰からでも寄付を受け付け、資金の使い道を投票にて決定可能。 -- **共同所有**– 物理的またはデジタル資産を購入し、メンバーは資産の活用方法について投票できる。 -- **ベンチャーキャピタルと助成金** - 投資資金をプールし、投票により支援先ベンチャーを選択する、ベンチャーファンドを作成可能。 返済金は後に分散型自律組織(DAO)のメンバー間で再配分できる。 +- **共同所有** – 物理的またはデジタル資産を購入し、メンバーは資産の活用方法について投票できる。 +- **ベンチャーキャピタルと助成** – 投資資金をプールし、投票により支援先ベンチャーを選択、ベンチャーファンドを作成可能。 返済金は後に分散型自律組織(DAO)のメンバー間で再配分できる。 ## 分散型自律組織(DAO)の仕組み {#how-daos-work} -組織のルールを定義し、その組織の資産を保持している[スマートコントラクト](/glossary/#smart-contract)が、分散型自律組織(DAO) のバックボーンです。 このスマートコントラクトがイーサリアム上で稼働し始めると、投票以外では誰もルールを変更できません。 もし誰かがコードのルールやロジックでカバーされていないことを試みても失敗に終わります。 また、資産はスマートコントラクトによって定義されているため、グループの承認なしには誰も組織の資金を使うことができません。 つまり、分散型自律組織(DAO)は中央集権を必要とせず、 グループが集合的に決定を下し、投票が可決されると支払いが自動的に承認されます。 +DAOのバックボーンは、組織のルールを定義し、グループの財源を保持する[スマートコントラクト](/glossary/#smart-contract)です。 このスマートコントラクトがイーサリアム上で稼働し始めると、投票以外では誰もルールを変更できません。 もし誰かがコードのルールやロジックでカバーされていないことを試みても失敗に終わります。 また、資産はスマートコントラクトによって定義されているため、グループの承認なしには誰も組織の資金を使うことができません。 つまり、分散型自律組織(DAO)は中央集権を必要とせず、 グループが集合的に決定を下し、投票が可決されると支払いが自動的に承認されます。 これが可能なのは、スマートコントラクトがイーサリアム上で稼働すると、改ざんができないためです。 すべてが公開されているので、コード(分散型自律組織のルール)を誰にも気づかれずに、変更することはできません。 -## イーサリアムと分散型自律組織(DAO) {#ethereum-and-daos} +## イーサリアムとDAO {#ethereum-and-daos} イーサリアムは、次の理由から分散型自律組織(DAO)の完璧な基盤となります。 @@ -61,105 +62,105 @@ DAOは、共通の目的のために行動する、集団所有された組織 - スマートコントラクトは、資金の送受信が可能。 これができないと、グループ資金を管理する信頼できる仲介者が必要となる。 - イーサリアムのコミュニティは、競争的なものではなく、むしろ協調的であることが証明されており、最善の方法やサポートシステムが迅速に生みだされている。 -## 分散型自律組織(DAO)ガバナンス {#dao-governance} +## DAOのガバナンス {#dao-governance} 分散型自律組織(DAO)のガバナンスには、投票や提案の仕組みなど様々な考慮事項があります。 -### デリゲーション(委任) {#governance-delegation} +### 委任 {#governance-delegation} デリゲーション(委任)とは、分散型自律組織版の議会制民主主義のようなものです。 トークン保有者は、プロトコルを管理し、最新情報を入手することにコミットする立候補者に投票権を委任します。 -#### 有名な事例 {#governance-example} +#### 有名な例 {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – ENS保有者は、自分たちの代表として、熱心なコミュニティメンバーに投票を委任できます。 -[ENS](https://claim.ens.domains/delegate-ranking) – ENS保有者は、自分たちの代表として、コミュニティメンバーに投票を委任できます。 - -### 自動トランザクションガバナンス {#governance-example} +### 自動取引ガバナンス {#governance-example} 多くの分散型自律組織(DAO)では、メンバーの賛成票が定足数を満たせば自動的にトランザクションが実行されます。 -#### 有名な事例 {#governance-example} +#### 有名な例 {#governance-example} [Nouns](https://nouns.wtf) – Nouns DAOでは、定足数を満たし、過半数が賛成票であれば、創設者が拒否権を行使しない限り、トランザクションは自動的に実行されます。 -### マルチシグガバナンス {#governance-example} +### マルチシグ・ガバナンス {#governance-example} -分散型自律組織(DAO)には投票権のあるメンバーが何千人も在籍するかもしれませんが、資金は5～20人のアクティブなメンバーが共有する[ウォレット](/glossary/#wallet)に保有されている場合があります。これらのメンバーは信用されており、通常は個人情報が公開されています(コミュニティに公的な身元が公開)。 投票の結果をもって、[マルチシグ](/glossary/#multisig)の署名者はコミュニティの意思を実施します。 +DAOには何千人もの投票メンバーがいる場合がありますが、資金は信頼され、通常はdoxxed(コミュニティに身元が公開されている)状態の5～20人のアクティブなコミュニティメンバーが共有する[ウォレット](/glossary/#wallet)に存在することがあります。 投票後、[multisig](/glossary/#multisig)署名者はコミュニティの意思を実行します。 -## 分散型自律組織(DAO)法 {#dao-laws} +## DAOの法律 {#dao-laws} 1977年にワイオミング州は、起業家を保護し、責任を有限にする合同会社(LLC)を制定しました。 近年では、ワイオミング州は分散型自律組織(DAO)の法的地位を確立する法律を制定し、パイオニアとなっています。 現在、ワイオミング州、バーモント州、ヴァージン諸島に、何らかの形の分散型自律組織(DAO)法があります。 -### 有名な事例 {#law-example} +### 有名な例 {#law-example} -[CityDAO](https://citizen.citydao.io/) – CityDAOは、ワイオミング州の分散型自律組織(DAO)法を利用して、イエローストーン国立公園近くの40エーカーの土地を購入しました。 +[CityDAO](https://citizen.citydao.io/) – CityDAOはワイオミング州のDAO法を利用して、イエローストーン国立公園の近くにある40エーカーの土地を購入しました。 -## 分散型自律組織(DAO)のメンバーシップ {#dao-membership} +## DAOのメンバーシップ {#dao-membership} 分散型自律組織(DAO)のメンバーシップにはいくつかのモデルがあります。 メンバーシップにより、投票の仕組みやDAOの他の重要な部分を決定することができます。 ### トークンベースのメンバーシップ {#token-based-membership} -使用されるトークンにもよりますが、通常は完全に[パーミッションレス](/glossary/#permissionless)です。 ほとんどの場合、これらのガバナンストークンは、[分散型取引所](/glossary/#dex)でパーミッションレスで取引できます。 それ以外のトークンは、流動性もしくはその他の「プルーフ・オブ・ワーク」を提供することで獲得する必要があります。 いずれにせよ、トークンの保持により投票権が付与されます。 +使用されるトークンによりますが、通常は完全に[パーミッションレス](/glossary/#permissionless)です。 ほとんどの場合、これらのガバナンストークンは、[分散型取引所](/glossary/#dex)でパーミッションレスに取引できます。 それ以外のトークンは、流動性もしくはその他の「プルーフ・オブ・ワーク」を提供することで獲得する必要があります。 いずれにせよ、トークンの保持により投票権が付与されます。 _一般的には、広範な分散型プロトコルやトークン自体を管理するために使用されます。_ -#### 有名な事例 {#token-example} +#### 有名な例 {#token-example} [MakerDAO](https://makerdao.com) – MakerDAOのトークンであるMKRは分散型取引所で広く入手可能で、購入することにより、誰でもMakerプロトコルの将来についての投票権を得ることができます。 -### シェアベースのメンバーシップ {#share-based-membership} +### 株式ベースのメンバーシップ {#share-based-membership} シェアベースの分散型自律組織(DAO)は、よりパーミッション型ではありますが、かなりオープンです。 分散型自律組織(DAO)への参加希望者は、トークンや作品といった何らかの価値のある物を提供することで、自分自身の参加を提案します。 シェアは、直接投票権と所有権を表します。 メンバーはいつでも、自分の保有する資産の持分を持って退会できます。 -_一般的には、慈善団体やワーカーズ・コレクティブ、投資クラブなど、より密接な関係を持つ人間が中心となる組織に使われています。 また、プロトコルやトークンも管理できます。_ +_一般的には、慈善団体やワーカーズ・コレクティブ、投資クラブなど、より密接な関係を持つ人間が中心となる組織に使われています。_ _また、プロトコルやトークンも管理できます。_ -#### 有名な事例 {#share-example} +#### 有名な例 {#share-example} -[MolochDAO](http://molochdao.com/) - MolochDAOは主にイーサリアムプロジェクトの資金調達を行っています。 メンバーになるには、提案が必要となります。この提案によって、あなたが助成先候補に関して、十分な情報に基づいて判断できるだけの必要な専門知識と資本を持っているかどうかが評価されます。 オープン市場で権利を購入するだけでは、この分散型自律組織(DAO)に参加することはできません。 +[MolochDAO](http://molochdao.com/) – MolochDAOは、イーサリアムプロジェクトへの資金提供に重点を置いています。 メンバーになるには、提案が必要となります。この提案によって、あなたが助成先候補に関して、十分な情報に基づいて判断できるだけの必要な専門知識と資本を持っているかどうかが評価されます。 オープン市場で権利を購入するだけでは、この分散型自律組織(DAO)に参加することはできません。 -### レピュテーション(評価・評判)ベースのメンバーシップ {#reputation-based-membership} +### 評判ベースのメンバーシップ {#reputation-based-membership} -レピュテーション(評価・評判)とは、分散型自律組織(DAO)における参加証明と投票権の付与を表します。 トークンやシェアベースのメンバーシップとは異なり、レピュテーションベースの分散型自律組織(DAO)は所有権をコントリビューターに譲渡しません。 レピュテーションは購入、移管、または委任できず、分散型自律組織メンバーは参加を通じてレピュテーションを構築する必要があります。 オンチェーン投票はパーミッションレスで、メンバー候補は分散型自律組織(DAO)への参加を自由に提案でき、貢献の対価としてレピュテーションやトークンを受け取ることを要求することができます。 +レピュテーション(評価・評判)とは、分散型自律組織(DAO)における参加証明と投票権の付与を表します。 トークンやシェアベースのメンバーシップとは異なり、レピュテーションベースの分散型自律組織(DAO)は所有権をコントリビューターに譲渡しません。 レピュテーションは購入、移管、または委任できず、分散型自律組織メンバーは参加を通じてレピュテーションを構築する必要があります。 オンチェーン投票は許可不要で、将来のメンバーは自由にDAOへの参加提案を提出し、貢献の対価として報酬として評判とトークンを受け取ることを要求できます。 -_主にプロトコルや[分散型アプリ(Dapp)](/glossary/#dapp)の分散型開発や分散型ガバナンスに利用されていますが、慈善団体、ワーカーズ・コレクティブ、投資クラブなど、多様な組織にも向いています。_ +_主にプロトコルや[dapps](/glossary/#dapp)の分散型開発とガバナンスに利用されますが、慈善団体、ワーカーズコレクティブ、投資クラブといった多様な組織にもよく適しています。_ -#### 有名な事例 {#reputation-example} +#### 有名な例 {#reputation-example} -[DXdao](https://DXdao.eth.limo) - DXdaoは、2019年から分散型プロトコルやアプリケーションを構築し統治するグローバル・ソブリン団体でした。 レピュテーションに基づくガバナンスと[ホログラフィック・コンセンサス](/glossary/#holographic-consensus)を活用して資金を調整・管理することで、誰かが金銭的な手段を使って、DXdaoの今後に影響をおよぼしたり、支配したりすることはできませんでした。 +[DXdao](https://DXdao.eth.limo) – DXdaoは、2019年から分散型プロトコルやアプリケーションを構築・管理する、世界的な主権を持つコレクティブでした。 評判に基づくガバナンスと[ホログラフィック・コンセンサス](/glossary/#holographic-consensus)を活用して資金を調整・管理することで、誰も金銭的な手段を使ってその将来やガバナンスに影響を及ぼすことはできませんでした。 -## DAOに参加する/DAOを立ち上げる {#join-start-a-dao} +## DAOへの参加/DAOの設立 {#join-start-a-dao} -### 分散型自律組織(DAO)への参加 {#join-a-dao} +### DAOに参加する {#join-a-dao} -- [イーサリアムコミュニティ分散型自律組織(DAO)](/community/get-involved/#decentralized-autonomous-organizations-daos) -- [DAOHausの分散型自律組織(DAO)リスト](https://app.daohaus.club/explore) -- [Tally.xyzの分散型自律組織(DAO)リスト](https://www.tally.xyz) +- [イーサリアムコミュニティのDAO](/community/get-involved/#decentralized-autonomous-organizations-daos) +- [DAOHausのDAOリスト](https://app.daohaus.club/explore) +- [Tally.xyzのDAOリスト](https://www.tally.xyz/explore) +- [DeGov.AIのDAOリスト](https://apps.degov.ai/) -### 分散型自律組織(DAO)を始める {#start-a-dao} +### DAOを始める {#start-a-dao} -- [DAOHausで分散型自律組織(DAO)を招集](https://app.daohaus.club/summon) -- [TallyでGovernor DAOを始める](https://www.tally.xyz/add-a-dao) -- [Aragonによる分散型自律組織(DAO)を作成](https://aragon.org/product) +- [DAOHausでDAOを召喚する](https://app.daohaus.club/summon) +- [TallyでGovernor DAOを始める](https://www.tally.xyz/get-started) +- [Aragonを利用してDAOを作成する](https://aragon.org/product) - [コロニーを始める](https://colony.io/) -- [DAOstackのホログラフィック・コンセンサスでDAOを作成](https://alchemy.daostack.io/daos/create) +- [DAOstackのホログラフィック・コンセンサスでDAOを作成する](https://alchemy.daostack.io/daos/create) +- [DeGov LauncherでDAOを立ち上げる](https://docs.degov.ai/integration/deploy) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -### 分散型自律組織(DAO)の関連記事 {#dao-articles} +### DAO関連の記事 {#dao-articles} -- [分散型自律組織(DAO)とは](https://aragon.org/dao) – [Aragon](https://aragon.org/) -- [分散型自律組織(DAO)](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/) -- [分散型自律組織(DAO)とは、およびその目的](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/) -- [分散型自律組織(DAO)のデジタルコミュニティの作成方法](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/) -- [分散型自律組織(DAO)とは](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com) -- [ホログラフィック・コンセンサスとは](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/) -- [分散型自律組織(DAO)とは企業ではなく、分散型の自律組織 – Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html) -- [分散型自律組織(DAO)、分散型自律企業(DAC)、分散型アプリケーション(DA)など: 不完全な用語集](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [イーサリアムブログ](https://blog.ethereum.org) +- [DAOとは？](https://aragon.org/dao) – [Aragon](https://aragon.org/) +- [House of DAOs](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/) +- [DAOとは何か、何のためのものか？](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/) +- [DAOを活用したデジタルコミュニティの始め方](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/) +- [DAOとは？](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com) +- [ホログラフィック・コンセンサスとは？](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/) +- [DAOは企業ではない：自律的組織における分散化の重要性 (ヴィタリック筆)](https://vitalik.eth.limo/general/2022/09/20/daos.html) +- [DAO、DAC、DAなど：不完全な用語ガイド](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [イーサリアムブログ](https://blog.ethereum.org) -### ビデオ {#videos} +### 動画 {#videos} -- [仮想通貨における分散型自律組織(DAO)とは](https://youtu.be/KHm0uUPqmVE) -- [分散型自律組織(DAO)で街はつくれるのか?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/) +- [暗号資産におけるDAOとは？](https://youtu.be/KHm0uUPqmVE) +- [DAOは都市を建設できるか？](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/) diff --git a/public/content/translations/ja/decentralized-identity/index.md b/public/content/translations/ja/decentralized-identity/index.md index 9818baaf876..12f60ee812f 100644 --- a/public/content/translations/ja/decentralized-identity/index.md +++ b/public/content/translations/ja/decentralized-identity/index.md @@ -1,25 +1,25 @@ --- -title: 分散型アイデンティティ -description: 分散型アイデンティティとは、またこれが重要な理由 +title: "分散型アイデンティティ" +description: "分散型アイデンティティとは、またこれが重要な理由" lang: ja template: use-cases emoji: ":id:" sidebarDepth: 2 image: /images/eth-gif-cat.png -summaryPoint1: 身元を証明するIDは中央集権的に発行、更新、管理されてきた従来のアイデンティティ制度 -summaryPoint2: 分散型アイデンティティにより、中央集権的なサードパーティへの依存から脱却 -summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテステーションを発行、保持、管理することが可能 +summaryPoint1: "身元を証明するIDは中央集権的に発行、更新、管理されてきた従来のアイデンティティ制度" +summaryPoint2: "分散型アイデンティティにより、中央集権的なサードパーティへの依存から脱却" +summaryPoint3: "暗号技術により、今や再び自分自身のIDとアテステーションを発行、保持、管理することが可能" --- 身分を証明するアイデンティティは、今日の生活のほぼすべての側面の基盤となっています。 オンラインサービスの利用、銀行口座の開設、選挙での投票、不動産の購入、雇用の確保、これらすべてにおいて身分証明が必要です。 -しかし、従来の身分証明書管理システムは、IDと[アテステーション](/glossary/#attestation)を発行、保有、管理する中央管理型の仲介機関に長く依存してきました。 つまり、自分の身元証明に関する情報を自分自身で管理したり、誰が個人を特定できる情報(PII)にアクセスできるか、またこれらの機関がどのくらいアクセス権を持っているかを決めることはできないということです。 +しかし、従来のID管理システムは、IDと[アテステーション](/glossary/#attestation)を発行、保有、管理する中央集権型の仲介機関に長く依存してきました。 つまり、自分の身元証明に関する情報を自分自身で管理したり、誰が個人を特定できる情報(PII)にアクセスできるか、またこれらの機関がどのくらいアクセス権を持っているかを決めることはできないということです。 -こうした問題を解決するために、イーサリアムのようなパブリックブロックチェーン上に分散型アイデンティティシステムを構築しています。 分散型アイデンティティでは、自分の身元証明に関する情報を管理することができます。 サービスプロバイダーや政府などの中央機関に依存することなく、_自分自身で_身分証明を作成し、本人であるというアテステーションを主張・保持することができます。 +こうした問題を解決するために、イーサリアムのようなパブリックブロックチェーン上に分散型アイデンティティシステムを構築しています。 分散型アイデンティティでは、自分の身元証明に関する情報を管理することができます。 分散型IDソリューションを使えば、サービスプロバイダーや政府のような中央機関に頼ることなく、_あなた_がIDを作成し、自分のアテステーションを請求・保持できます。 ## アイデンティティとは? {#what-is-identity} -アイデンティティとは、自分が自分であるという自覚で、その人が誰であるかということを表す性質や特徴により定義されます。 アイデンティティとは、_個_であること、すなわち一人の確たる人間存在であることを意味します。 またアイデンティティは、組織や行政機関などのように人間ではない存在を指すこともあります。 +アイデンティティとは、自分が自分であるという自覚で、その人が誰であるかということを表す性質や特徴により定義されます。 「アイデンティティ」とは、_個人_であること、すなわち、個別の人間存在であることを指します。 またアイデンティティは、組織や行政機関などのように人間ではない存在を指すこともあります。 @@ -35,67 +35,93 @@ summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテス 上記のような例では、IDは中央機関や組織により発行、保持、管理されています。 氏名の変更には政府からの、ユーザー名の変更にはソーシャルメディアからの承認が必要です。 -## 分散型アイデンティティの利点 {#benefits-of-decentralized-identity} +## 分散型IDのメリット {#benefits-of-decentralized-identity} 1. 分散型アイデンティティは、自分自身のID情報をより管理することができます。 中央集権機関やサードパーティのサービスに依存することなく、分散型IDとアテステーションを検証することができます。 -2. 分散型アイデンティティのソリューションは、信頼性が高く、シームレスで、プライバシーを保護しつつ、ユーザーのアイデンティティの検証と管理を容易にします。 +2. 分散型IDソリューションは、ユーザーのIDを検証・管理するための、信頼を必要としない (トラストレスな) 、シームレスでプライバシーを保護する方法を容易にします。 3. 分散型アイデンティティは、ブロックチェーン技術を活用し、異なる当事者間の信頼関係を構築し、暗号的にアテステーションの正当性を証明することができます。 -4. 分散型アイデンティティは、アイデンティティデータのポータブル化を実現します。 ユーザーは、アテステーションとIDをモバイルウォレットに保存し、任意の相手と共有することができます。 分散型IDとアテステーションは、発行組織のデータベースに保管されることはありません。 +4. 分散型アイデンティティは、アイデンティティデータのポータブル化を実現します。 ユーザーは、アテステーションとIDをモバイルウォレットに保存し、任意の相手と共有できます。 分散型IDとアテステーションは、発行組織のデータベースに保管されることはありません。 -5. 分散型アイデンティティは、新しい[ゼロ知識証明](/glossary/#zk-proof)技術とうまく機能すると考えられています。ゼロ知識証明とは、個人の所有または何かを行ったことを、それが何であるかを明かすことなく証明できるものです。 これは、投票などのアプリケーションでの応用において、信頼性とプライバシーを両立させる強力な方法となる可能性を秘めています。 +5. 分散型IDは、個人がそれが何であるかを明かすことなく、何かを所有している、あるいは何かを成し遂げたことを証明できる、新しい[ゼロ知識](/glossary/#zk-proof)技術とうまく連携するはずです。 これは、投票などのアプリケーションでの応用において、信頼性とプライバシーを両立させる強力な方法となる可能性を秘めています。 -6. 分散型アイデンティティは、[耐シビル](/glossary/#anti-sybil)メカニズムを実現するため、一人の人間が複数の人間になりすました操作やスパムを防ぐことができます。 +6. 分散型IDは、[アンチシビル](/glossary/#anti-sybil)メカニズムを可能にし、一個人がシステムを悪用したりスパム行為をしたりするために複数の人間になりすましているのを識別します。 -## 分散型アイデンティティのユースケース {#decentralized-identity-use-cases} +## 分散型IDのユースケース {#decentralized-identity-use-cases} 分散型アイデンティティには、多くの潜在的なユースケースがあります。 ### 1. ユニバーサルログイン {#universal-dapp-logins} -分散型アイデンティティは、パスワードベースのログインを分散型認証に置き換えるのに役立ちます。 サービスプロバイダーは、アテステーションを発行することができ、ユーザーはそれをイーサリアムのウォレットに保存できます。 アテステーションの例としては、[非代替性トークン(NFT)](/glossary/#nft)保有者にオンラインコミュニティへのアクセスを許可することなどが挙げられます。 +分散型アイデンティティは、パスワードベースのログインを分散型認証に置き換えるのに役立ちます。 サービスプロバイダーは、アテステーションを発行することができ、ユーザーはそれをイーサリアムのウォレットに保存できます。 アテステーションの例として、保有者にオンラインコミュニティへのアクセスを許可する[NFT](/glossary/#nft)が挙げられます。 -[イーサリアムでサインイン](https://siwe.xyz/)機能を使うと、サーバはユーザーのイーサリアムアカウントを確認し、アカウントアドレスから必要なアテステーションを取得することができます。 これにより、ユーザーは長いパスワードを記憶することなくプラットフォームやウェブサイトにアクセスでき、オンライン・エクスペリエンスを向上させることができます。 +[Sign-In with Ethereum](https://siwe.xyz/)機能により、サーバーはユーザーのEthereumアカウントを確認し、そのアカウントアドレスから必要なアテステーションを取得できるようになります。 これにより、ユーザーは長いパスワードを記憶することなくプラットフォームやウェブサイトにアクセスでき、オンライン・エクスペリエンスを向上させることができます。 ### 2. KYC認証 {#kyc-authentication} オンラインサービスの多くを利用するには、運転免許証やパスポートなどのアテステーションを提出する必要があります。 しかし、この方法では、ユーザーの個人情報が漏洩するおそれがあり、サービスプロバイダーはアテステーションの正当性を確認できないという問題があります。 -分散型アイデンティティにより、企業は従来の[本人確認(KYC)](https://en.wikipedia.org/wiki/Know_your_customer)プロセスを省略し、検証可能な資格情報を利用してユーザーのアイデンティティを認証することができます。 これにより、ID管理のコストを削減し、偽造文書の使用を防ぐことができます。 +分散型IDにより、企業は従来の[顧客確認 (KYC)](https://en.wikipedia.org/wiki/Know_your_customer)プロセスを省略し、検証可能な資格情報を使ってユーザーIDを認証できます。 これにより、ID管理のコストを削減し、偽造文書の使用を防ぐことができます。 ### 3. 投票とオンラインコミュニティ {#voting-and-online-communities} -オンライン投票とソーシャルメディアは、分散型アイデンティティの新しい適用です。 オンライン投票の仕組みでは、悪意ある者が偽のIDを作成し投票することで、改ざんされるおそれがあります。 個人に対してオンチェーン・アテステーションを求めることで、オンライン投票プロセスの信頼性を向上できます。 +オンライン投票とソーシャルメディアは、分散型アイデンティティの新しい適用です。 オンライン投票の仕組みでは、悪意ある者が偽のIDを作成し投票することで、改ざんされるおそれがあります。 個人にオンチェーンのアテステーションの提示を求めることで、オンライン投票プロセスの健全性を向上させることができます。 -分散型アイデンティティは、偽アカウントのないオンラインコミュニティの構築に役立ちます。 例えば、ENS(イーサリアム・ネーム・サービス)のようなオンチェーンのアイデンティティシステムを使って認証させることで、ボットを減らすことができる可能性があります。 +分散型アイデンティティは、偽アカウントのないオンラインコミュニティの構築に役立ちます。 例えば、各ユーザーがEthereum Name ServiceのようなオンチェーンのIDシステムを使って本人認証を行うことで、ボットの可能性を減らせるかもしれません。 -### 4. シビル攻撃の防御 {#sybil-protection} +### 4. アンチシビル対策 {#sybil-protection} -[クアドラティック・ボーティング](/glossary/#quadratic-voting)を用いた助成金授与アプリケーションでは、より多くの投票が集まることで助成金の価値が上がり、多くのIDを使って寄付するというインセンティブが働くため、[シビル攻撃](/glossary/#sybil-attack)を受けやすくなっています。 分散型アイデンティティは、多くの場合、特定の個人情報を明らかにすることなく、各参加者自身が機械ではなく本当に人間であることを証明するという負担を高めることで、シビル攻撃の防止に役立ちます。 +[クアドラティック・ボーティング](/glossary/#quadratic-voting)を使用する助成金提供アプリケーションは、[シビル攻撃](/glossary/#sybil-attack)に対して脆弱です。なぜなら、より多くの個人が投票すると助成金の価値が上がり、ユーザーが多くのIDに貢献を分割するインセンティブが働くからです。 分散型アイデンティティは、多くの場合、特定の個人情報を明らかにすることなく、各参加者自身が機械ではなく本当に人間であることを証明するという負担を高めることで、シビル攻撃の防止に役立ちます。 + +### 5. 国および政府のID {#national-and-government-id} + +政府は、分散型IDの原則を用いて、国民ID、パスポート、運転免許証などの基本的な身分証明書をEthereum上の検証可能な資格情報として発行し、オンラインでの本人確認における詐欺や偽造を減らすための強力な暗号学的真正性保証を提供できます。 市民はこれらのアテステーションを個人の[ウォレット](/wallets/)に保存し、身元、年齢、または投票権を証明するために使用できます。 + +このモデルは、特に[ゼロ知識証明 (ZKP)](/zero-knowledge-proofs/) プライバシー技術と組み合わせることで、選択的開示を可能にします。 例えば、市民は、従来のIDよりも高いプライバシーを提供し、正確な生年月日を明かすことなく、年齢制限のあるサービスにアクセスするために18歳以上であることを暗号技術によって証明できます。 + +#### 💡ケーススタディ: Ethereum上のブータン国民デジタルID (NDI) {#case-study-bhutan-ndi} + +- ブータンの約80万人の国民に、検証可能なID資格情報へのアクセスを提供 +- 2025年10月にPolygonネットワークから[Ethereumメインネット](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878)に移行 +- 2025年3月時点で[234,000件以上](https://www.blockchain-council.org/blockchain/bhutan-uses-blockchain-in-digital-id-project/)のデジタルIDを発行 + +ブータン王国は、2025年10月に[国民デジタルID (NDI) システムをEthereumに移行しました](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878)。 分散型IDと自己主権型IDの原則に基づいて構築されたブータンのNDIシステムは、分散型IDと検証可能な資格情報を使用して、デジタル署名された資格情報を市民の個人ウォレットに直接発行します。 これらの資格情報の暗号学的証明をEthereum上に固定することで、システムはそれらが本物で改ざん不可能であり、中央機関に問い合わせることなくどの当事者でも検証できることを保証します。 + +このシステムのアーキテクチャは、[ゼロ知識証明 (ZKP)](/zero-knowledge-proofs/) 技術の使用を通じてプライバシーを重視しています。 この「選択的開示」の実装により、市民は完全なID番号や正確な生年月日などの基礎となる個人データを明かすことなく、サービスにアクセスするために特定の事実 (例:「私は18歳以上です」または「私は国民です」) を証明できます。 これは、安全でユーザー中心、かつプライバシーを保護する国民IDシステムのための、Ethereumの強力な実世界での使用例を示しています。 + +#### 💡ケーススタディ: Ethereumの[レイヤー2](/layer-2/)であるZKSync Era上のブエノスアイレス市のQuarkID {#case-study-buenos-aires-quarkid} + +- ローンチ時に[360万人以上のユーザー](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)に分散型ID資格情報を発行 +- QuarkIDは、国連の持続可能な開発目標の下で[デジタル公共財](https://www.digitalpublicgoods.net/r/quarkid)として認識されているオープンソースプロトコルです +- 市がプロトコルを所有せず、市民に完全なデータ所有権とプライバシーを与える「[ユーザーとしての政府](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)」モデルを強調 + +2024年、ブエノスアイレス市政府 (GCBA) は、GCBAのイノベーション・デジタル変革事務局が構築したオープンソースの「デジタル信頼フレームワーク」であるQuarkIDを、住民が政府サービスや公式文書にアクセスするための市の公式アプリであるmiBAに統合しました。 ローンチ時、miBAの360万人以上の全ユーザーに分散型デジタルIDが発行され、市民権の証明書、出生、結婚、死亡証明書、納税記録、ワクチン接種記録など、検証可能なデジタル文書や証明書をオンチェーンで管理・共有できるようになりました。 + +Ethereumの[レイヤー2](/layer-2/)ネットワークであるZKSync Era上に構築されたQuarkIDシステムは、ZKP技術を使用して、市民が不必要な個人データを公開することなく、モバイルデバイスを通じてピアツーピアで個人の資格情報を検証できるようにします。 このプログラムは、GCBAが中央集権的な所有者としてではなく、オープンソースで相互運用可能なQuarkIDプロトコルの1ユーザーとして機能する「ユーザーとしての政府」モデルを強調しています。 このZKP対応アーキテクチャは、重要なプライバシー機能を提供します。第三者、GCBAでさえも、市民がいつ、どこで、なぜ資格情報を使用したかを追跡することはできません。 この成功したプログラムは、市民に完全な自己主権型IDと機密データに対する管理権を提供し、そのすべてがEthereumの世界的に分散したネットワークによって保護されています。 ## アテステーションとは {#what-are-attestations} アテステーションとは、ある存在が別の存在に対して行われる証明を意味します。 例えばアメリカに住んでいる場合、車両管理局(ある存在)が、あなた(別の存在)が合法的に車の運転を許可されているということを証明するために運転免許証を発行します。 -アテステーションは身分を証明するIDとは異なります。 アテステーションには、_特定のアイデンティティを参照するためのIDを含み_、また当該アイデンティティに関連する属性についても証します。 つまり、運転免許証には身分を証明するID(氏名、生年月日、住所)が含まれ、同時に、運転できるという法的権利(属性)に関しても証明します。 +アテステーションは身分を証明するIDとは異なります。 アテステーションは、特定のアイデンティティを参照するためのIDを_含み_、このアイデンティティに関連する属性についての主張を行います。 つまり、運転免許証には身分を証明するID(氏名、生年月日、住所)が含まれ、同時に、運転できるという法的権利(属性)に関しても証明します。 ### 分散型IDとは {#what-are-decentralized-identifiers} 氏名やメールアドレスといった従来のIDは、政府やメールプロバイダーといったサードパーティに依存します。 分散型ID (DID)は、中央集権組織により発行、管理、制御されないという点で異なります。 -分散型IDは、自分自身で発行、保有、管理することができます。 [イーサリアムアカウント](/glossary/#account)は、分散型IDの一例です。 誰からの許可も不要で、また中央台帳に保存する必要もなく、好きなだけアカウントを作成することができます。 +分散型IDは、自分自身で発行、保有、管理することができます。 [Ethereumアカウント](/glossary/#account)は、分散型IDの一例です。 誰からの許可も不要で、また中央台帳に保存する必要もなく、好きなだけアカウントを作成することができます。 -分散型IDは、分散型台帳([ブロックチェーン](/glossary/#blockchain))や[ピアツーピアネットワーク](/glossary/#peer-to-peer-network)に格納されるため、 分散型IDは[世界的に一意で、高い可用性で解決可能で、暗号技術で検証可能](https://w3c-ccg.github.io/did-primer/)なものです。 分散型IDは、人、組織、政府機関など、さまざまなエンティティに関連付けることができます。 +分散型IDは、分散型台帳 ([ブロックチェーン](/glossary/#blockchain)) や[ピアツーピア・ネットワーク](/glossary/#peer-to-peer-network)に保存されます。 これにより、DIDは[世界的に一意で、高い可用性で解決可能で、暗号技術によって検証可能](https://w3c-ccg.github.io/did-primer/)になります。 分散型IDは、人、組織、政府機関など、さまざまなエンティティに関連付けることができます。 -## 分散型IDを実現する技術 {#what-makes-decentralized-identifiers-possible} +## 分散型IDを実現する技術 分散型IDを可能にするもの {#what-makes-decentralized-identifiers-possible} ### 1. 公開鍵暗号 {#public-key-cryptography} -公開鍵暗号とは、あるエンティティに対して[公開鍵](/glossary/#public-key)と[秘密鍵](/glossary/#private-key)を生成する情報セキュリティのことです。 公開鍵の[暗号技術](/glossary/#cryptography)は、ブロックチェーンネットワークにおいて、ユーザーの身分を認証し、デジタル資産の所有権を証明するために使用されます。 +公開鍵暗号は、エンティティに対して[公開鍵](/glossary/#public-key)と[秘密鍵](/glossary/#private-key)を生成する情報セキュリティ対策です。 公開鍵[暗号](/glossary/#cryptography)は、ブロックチェーンネットワークにおいて、ユーザーIDを認証し、デジタル資産の所有権を証明するために使用されます。 -イーサリアムアカウントなどの分散型IDには、公開鍵と秘密鍵があるものがあります。 公開鍵はアカウントのコントローラを識別し、秘密鍵はこのアカウントのメッセージに署名および復号化します。 公開鍵暗号は、[暗号署名](https://andersbrownworth.com/blockchain/public-private-keys/)を使用してすべての主張を検証することにより、エンティティを認証し、なりすましや偽のIDの使用を防ぎます。 +イーサリアムアカウントなどの分散型IDには、公開鍵と秘密鍵があるものがあります。 公開鍵はアカウントのコントローラを識別し、秘密鍵はこのアカウントのメッセージに署名および復号化します。 公開鍵暗号は、[暗号署名](https://andersbrownworth.com/blockchain/public-private-keys/)を使用してすべての主張を検証することで、エンティティを認証し、なりすましや偽のIDの使用を防ぐために必要な証明を提供します。 ### 2. 分散型データストア {#decentralized-datastores} @@ -107,7 +133,7 @@ summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテス 分散型アイデンティティとは、アイデンティティに関連する情報は自己管理され、プライベートでポータブルであるべきという考え方であり、分散型IDとアテステーションにより成り立っています。 -分散型アイデンティティの文脈では、アテステーション([検証可能な資格情報](https://www.w3.org/TR/vc-data-model/))とは、改ざんできず、暗号学的に検証できる発行者の主張です。 エンティティ(組織など)が発行するすべてのアテステーション、すなわち検証可能な資格情報は、その分散型ID (DID)と紐づけられます。 +分散型IDの文脈において、アテステーション (別名[検証可能な資格情報](https://www.w3.org/TR/vc-data-model/)) は、発行者によってなされる、改ざん不可能で暗号技術によって検証可能な主張です。 エンティティ(組織など)が発行するすべてのアテステーション、すなわち検証可能な資格情報は、その分散型ID (DID)と紐づけられます。 分散型ID (DID)はブロックチェーンに保存されるため、発行者のDIDをイーサリアム上で照合すれば、誰でもアテステーションの正当性を確認することができます。 基本的に、イーサリアムのブロックチェーンは、特定のエンティティに関連する分散型IDの検証を可能にするグローバルディレクトリのように機能します。 @@ -115,77 +141,78 @@ summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテス また、分散型IDは個人情報のプライバシーを保護する上でも非常に重要になります。 例えば、個人がアテステーション(運転免許証)を提出する場合、検証者は証明書の情報の正当性を確認する必要はありません。 検証者は、アテステーションの正当性の暗号学的な保証と、発行組織のアイデンティティだけで証明書の正当性を判断できます。 -## 分散型アイデンティティにおけるアテステーションの種類 {#types-of-attestations-in-decentralized-identity} +## 分散型IDにおけるアテステーションの種類 {#types-of-attestations-in-decentralized-identity} イーサリアムベースの分散型アイデンティティにおいては、アテステーション情報をどのように保存し、取得するかは、従来のアイデンティティ管理とは異なります。 ここでは、分散型IDシステムにおけるアテステーションの発行、保管、検証のためのさまざまなアプローチの概要を説明します。 -### オフチェーン・アテステーション {#off-chain-attestations} +### オフチェーンアテステーション {#offchain-attestations} -アテステーションをオンチェーンで保存する場合の懸念点として、個人が秘密にしたい情報が含まれている可能性があることが挙げられます。 イーサリアムのブロックチェーンはパブリックな性質を持っているため、個人情報が含まれるアテステーションを保存することは望ましくありません。 +アテステーションをオンチェーンで保存する際の懸念の1つは、個人が非公開にしておきたい情報が含まれている可能性があることです。 イーサリアムのブロックチェーンはパブリックな性質を持っているため、個人情報が含まれるアテステーションを保存することは望ましくありません。 -解決策としては、ユーザーがオフチェーンでデジタルウォレットに保有し、オンチェーンで保存されている発行者の分散型ID (DID)で署名されたアテステーションを発行することです。 これらのアテステーションは[JSONウェブトークン](https://en.wikipedia.org/wiki/JSON_Web_Token)としてエンコードされ、発行者のデジタル署名を含んでいるため、オフチェーンでの主張を簡単に検証することができます。 +解決策は、ユーザーがオフチェーンのデジタルウォレットで保持し、発行者のオンチェーンに保存されたDIDで署名されたアテステーションを発行することです。 これらのアテステーションは、[JSON Web Token](https://en.wikipedia.org/wiki/JSON_Web_Token)としてエンコードされ、発行者のデジタル署名を含んでいるため、オフチェーンでの主張を簡単に検証できます。 -ここで、仮想シナリオを用いてオフチェーン・アテステーションの説明します。 +オフチェーンアテステーションを説明するための、仮説のシナリオを以下に示します: 1. 大学(発行者)は証明書(デジタル学術証明書)を生成し、大学の鍵で署名し、ボブ(アイデンティティ所有者)に発行します。 2. ボブは就職活動で、自分の学歴を雇用主に証明するため、モバイルウォレットからアテステーションを共有します。 企業(検証者)は、発行者の分散型ID (イーサリアム上の公開鍵)を確認することで、アテステーションの正当性を確認することができます。 -### 永続的なアクセスによるオフチェーン・アテステーション {#offchain-attestations-with-persistent-access} +### 永続的アクセスが可能なオフチェーンアテステーション {#offchain-attestations-with-persistent-access} -この方式のアテステーションでは、JSONファイルに変換され、オフチェーンに保存されます(理想的には、IPFSやSwarmなどの [分散型クラウドストレージ](/developers/docs/storage/) プラットフォーム上)。 ただし、JSONファイルの[ハッシュ](/glossary/#hash)はオンチェーンに保存され、オンチェーンレジストリ経由で分散型IDにリンクされています。 紐づけられる分散型IDは、アテステーションの発行者または受取人のどちらかのものであることがあります。 +この方式では、アテステーションはJSONファイルに変換され、オフチェーン (理想的にはIPFSやSwarmなどの[分散型クラウドストレージ](/developers/docs/storage/)プラットフォーム) に保存されます。 しかし、JSONファイルの[ハッシュ](/glossary/#hash)はオンチェーンに保存され、オンチェーンレジストリを介してDIDにリンクされます。 紐づけられる分散型IDは、アテステーションの発行者または受取人のどちらかのものであることがあります。 このアプローチにより、アテステーションはブロックチェーンベースの永続性を得て、主張する情報を暗号化し検証可能な状態に保つことができます。 また、秘密鍵の保有者は情報を復号化できるため、選択的に開示することも可能です。 -### オフチェーン・アテステーション {#onchain-attestations} +### オンチェーンアテステーション {#onchain-attestations} -オンチェーン・アテステーションは、イーサリアムのブロックチェーン上の[スマートコントラクト](/glossary/#smart-contract)に保持されます。 スマートコントラクト(レジストリとして機能)は、アテステーションを該当するオンチェーン分散型ID公開鍵)にマッピングします。 +オンチェーンアテステーションは、Ethereumブロックチェーン上の[スマートコントラクト](/glossary/#smart-contract)で保持されます。 スマートコントラクト (レジストリとして機能) は、アテステーションを対応するオンチェーンの分散型ID (公開鍵) にマッピングします。 -ここでは、オンチェーン・アテステーションがどのように機能するか例を紹介します。 +オンチェーンアテステーションが実際にどのように機能するかの例を以下に示します: 1. ある企業(XYZ Corp)は、スマートコントラクトを使用して所有権の株式を売却することを計画していますが、バックグラウンドチェックを通った買手のみを求めています。 -2. XYZ Corpは、バックグラウンドチェックを行う会社に、イーサリアム上でオンチェーン・アテステーションを発行してもらうことができます。 このアテステーションは、個人情報を明かすことなくバックグラウンドチェックに通ったことを証明するものです。 +2. XYZ社は、身元調査を行う会社に、Ethereum上でオンチェーンアテステーションを発行させることができます。 このアテステーションは、個人情報を明かすことなくバックグラウンドチェックに通ったことを証明するものです。 3. 株式を売却するスマートコントラクトは、レジストリコントラクトで審査した買い手の身元を確認し、株式の買手を判断することができます。 -### ソウルバウンド・トークンとアイデンティティ {#soulbound} +### ソウルバウンドトークンとID {#soulbound} -[ソウルバウンドトークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)([譲渡不可の非代替性トークン](/glossary/#nft))は、特定のウォレットに固有の情報の収集に使用される可能性があります。 これは、特定のイーサリアムアドレスに結びついた一意のオンチェーンアイデンティティを効果的に作成し、業績(例えば、特定のオンラインコースの修了や、ゲームで閾値のスコアの通過など)やコミュニティへの参加を表すトークンを含むことができます。 +[ソウルバウンドトークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([譲渡不可能なNFT](/glossary/#nft)) は、特定のウォレットに固有の情報を収集するために使用できます。 これにより、特定のEthereumアドレスに紐付けられた一意のオンチェーンIDが効果的に作成されます。これには、実績 (例: 特定のオンラインコースの修了、ゲームでのしきい値スコアの達成) やコミュニティへの参加を表すトークンを含めることができます。 -## 分散型アイデンティティの利用 {#use-decentralized-identity} +## 分散型IDを使用する {#use-decentralized-identity} 分散型アイデンティティソリューションの基盤としてイーサリアムを使用する、大掛かりなプロジェクトが数多くあります。 -- **[イーサリアム・ネーム・サービス(ENS)](https://ens.domains/)** - _イーサリアムウォレットアドレス、コンテンツハッシュ、メタデータなどのオンチェーン、機械読み取り可能なIDの分散型ネーミングシステム_ -- **[SpruceID](https://www.spruceid.com/)** - _サードパーティーのサービスに頼らず、イーサリアムアカウントとENSプロファイルでデジタルアイデンティティを管理できるようにする分散型アイデンティティプロジェクト_ -- **[イーサリアム・アテステーション・サービス (EAS)](https://attest.sh/)** - _あらゆるものについてオンチェーンまたはオフチェーンのアテステーションを作成するための分散型台帳/プロトコル_ -- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (PoH)は、イーサリアム上に構築されたソーシャルID認証システム_ -- **[BrightID](https://www.brightid.org/)** - _ソーシャルグラフの作成と分析を通じて、本人確認の改革を目指す分散型オープンソース・ソーシャルアイデンティティネットワーク_ -- **[walt.id](https://walt.id)** — _オープンソースの分散型アイデンティティとウォレットのインフラストラクチャです。これにより、デベロッパーや組織は、自己主権型アイデンティティとNFT/SBTを活用可能にします。_ -- **[Veramo](https://veramo.io/)** - _JavaScriptフレームワークで、暗号学的に検証可能なデータを誰でも簡単にアプリケーションで利用することができます。_ +- **[Ethereum Name Service (ENS)](https://ens.domains/)** - _Ethereumウォレットアドレス、コンテンツハッシュ、メタデータなどのオンチェーンで機械可読なIDのための分散型ネーミングシステム。_ +- **[Sign in with Ethereum (SIWE)](https://siwe.xyz/)** - _Ethereumアカウントによる認証のためのオープンスタンダード。_ +- **[SpruceID](https://www.spruceid.com/)** - _サードパーティのサービスに依存せず、EthereumアカウントとENSプロファイルでデジタルIDを管理できる分散型IDプロジェクト。_ +- **[Ethereum Attestation Service (EAS)](https://attest.org/)** - _あらゆるものについてオンチェーンまたはオフチェーンのアテステーションを行うための分散型台帳/プロトコル。_ +- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (またはPoH) は、Ethereum上に構築されたソーシャルID認証システムです。_ +- **[BrightID](https://www.brightid.org/)** - _ソーシャルグラフの作成と分析を通じて、ID認証の改革を目指す、分散型のオープンソース・ソーシャルIDネットワーク。_ +- **[walt.id](https://walt.id)** — _開発者や組織が自己主権型IDとNFT/SBTを活用できるようにする、オープンソースの分散型IDおよびウォレットインフラストラクチャ。_ +- **[Veramo](https://veramo.io/)** - _誰でもアプリケーションで暗号技術によって検証可能なデータを簡単に使用できるようにするJavaScriptフレームワーク。_ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} ### 記事 {#articles} -- [ブロックチェーンの活用事例: デジタルIDにおけるブロックチェーン](https://consensys.net/blockchain-use-cases/digital-identity/) —_ConsenSys_ -- [イーサリアムERC725とは ブロックチェーン上の自己主権型ID管理](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_ -- [ブロックチェーンはデジタルID問題をどのように解決するか](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_ -- [分散型アイデンティティとは、注目に値する理由](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_ -- [分散型アイデンティティの紹介](https://walt.id/white-paper/digital-identity) — _Dominik Beron_ +- [ブロックチェーンのユースケース: デジタルIDにおけるブロックチェーン](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_ +- [イーサリアムERC725とは？ ブロックチェーン上での自己主権型ID管理](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_ +- [ブロックチェーンはデジタルIDの問題をどのように解決できるか](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_ +- [分散型IDとは何か、そしてなぜ気にかけるべきか？](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_ +- [分散型ID入門](https://walt.id/white-paper/digital-identity) — _Dominik Beron_ -### ビデオ {#videos} +### 動画 {#videos} -- [分散型アイデンティティ(ボーナスライブストリームセッション)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Andreas Antonopolousによる分散型アイデンティティに関する秀逸な解説ビデオ_ -- [イーサリアムでサインインし、Ceramic、IDX、React、および 3ID Connectを使用した分散型ID](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Nader Dabitによるイーサリアムウォレットを使用したユーザープロファイルの作成、読み取り、更新のID管理システムの構築に関するYouTubeチュートリアルビデオ_ -- [BrightID - イーサリアム上の分散型アイデンティティ](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _イーサリアムの分散型IDソリューション「BrightID」に関するBanklessポッドキャスト_ -- [オフ・チェーン・インターネット: 分散型アイデンティティと検証可能な資格情報](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Evin McMullenによるEthDenver 2022のプレゼンテーション -- [検証可能な資格情報の説明](https://www.youtube.com/watch?v=ce1IdSr-Kig) - Tamino Baumannによるデモを含んだYouTubeの説明ビデオ +- [分散型ID (ボーナスライブストリームセッション)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Andreas Antonopolousによる分散型IDに関する秀逸な解説動画_ +- [Ceramic、IDX、React、3ID Connectを使ったイーサリアムでのサインインと分散型ID](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Nader Dabitによる、Ethereumウォレットを使用してユーザーのプロファイルを作成、読み取り、更新するためのID管理システムを構築するYouTubeチュートリアル_ +- [BrightID - Ethereum上の分散型ID](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Ethereum向けの分散型IDソリューションであるBrightIDについて議論するBanklessポッドキャストエピソード_ +- [オフチェーンインターネット: 分散型IDと検証可能な資格情報](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Evin McMullenによるEthDenver 2022でのプレゼンテーション +- [検証可能な資格情報の説明](https://www.youtube.com/watch?v=ce1IdSr-Kig) - Tamino Baumannによるデモ付きYouTube解説動画 ### コミュニティ {#communities} -- [GitHub上のERC-725アライアンス](https://github.com/erc725alliance) — _イーサリアムのブロックチェーン上でIDを管理するための規格「ERC725」のサポーターコミュニティ_ -- [EthID Discordサーバ](https://discord.com/invite/ZUyG3mSXFD) — _「イーサリアムでサインイン」に取り組むファンやデベロッパーのためのコミュニティ_ -- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _アプリケーション向けの検証可能なデータのフレームワークの構築に貢献するデベロッパーのコミュニティ_ -- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _さまざまな業界にわたる分散型IDのユースケースに取り組むデベロッパーおよびビルダーのコミュニティ_ +- [GitHubのERC-725アライアンス](https://github.com/erc725alliance) — _Ethereumブロックチェーン上でIDを管理するためのERC725標準の支持者_ +- [EthID Discordサーバー](https://discord.com/invite/ZUyG3mSXFD) — _Sign-in with EthereumおよびEthereum Follow Protocolに取り組む愛好家と開発者のためのコミュニティ_ +- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _アプリケーション向けの検証可能データのためのフレームワーク構築に貢献する開発者のコミュニティ_ +- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _さまざまな業界にわたる分散型IDのユースケースに取り組む開発者とビルダーのコミュニティ_ diff --git a/public/content/translations/ja/defi/index.md b/public/content/translations/ja/defi/index.md index fb74ec963bb..9d68d98127d 100644 --- a/public/content/translations/ja/defi/index.md +++ b/public/content/translations/ja/defi/index.md @@ -1,15 +1,16 @@ --- -title: 分散型金融(DeFi) -description: イーサリアムにおける分散型金融(DeFi)の概要 +title: "分散型金融(DeFi)" +metaTitle: "分散型金融(DeFi)とは | 分散型金融の利点と使用法" +description: "イーサリアムにおける分散型金融(DeFi)の概要" lang: ja template: use-cases emoji: ":money_with_wings:" image: /images/use-cases/defi.png -alt: レゴブロックで作られたETHのロゴ +alt: "レゴブロックで作られたETHのロゴ" sidebarDepth: 2 -summaryPoint1: 現在の金融システムに変わる、グローバルで開かれた分散型金融。 -summaryPoint2: 借りる、貯蓄、投資、取引などを実現する製品。 -summaryPoint3: オープンソース技術に基づき、誰でもプログラミング可能。 +summaryPoint1: "現在の金融システムに変わる、グローバルで開かれた分散型金融。" +summaryPoint2: "借りる、貯蓄、投資、取引などを実現する製品。" +summaryPoint3: "オープンソース技術に基づき、誰でもプログラミング可能。" --- 分散型金融(DeFi)は、インターネット時代に対応したオープンでグローバルな金融システムであり、不透明で厳しく管理された、何十年も前のインフラやプロセスのシステムを置き換えるものです。 自分のお金をコントロールし、可視化することができます。 グローバル市場に入ることができ、自国の通貨や銀行の選択肢の代替となります。 分散型金融(DeFi)製品は、インターネットの接続がある人であれば誰でも金融サービスを受けることができ、ほとんどがユーザーによって所有・維持されています。 これまでに数百億ドル相当の暗号資産が、分散型金融(DeFi)アプリケーションを経由しており、その額は日々増加しています。 @@ -22,7 +23,7 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ -## 分散型金融(DeFi)と従来の金融システムとの比較 {#defi-vs-tradfi} +## DeFi 対 従来の金融 {#defi-vs-tradfi} 分散型金融(DeFi)の可能性を知るための最良の方法の一つは、現在ある問題を理解することです。 @@ -31,24 +32,24 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ - 金融サービスは、あなたをブロックし、支払いを受けることができないようにすることができます。 - 金融サービスへの隠された料金には、利用者の個人情報があります。 - 政府や中央集権機関が自由に市場を閉鎖することができます。 -- 取引時間は、大抵特定の営業時間帯に限定されます。 +- 取引時間は、多くの場合、特定のタイムゾーンの営業時間内に限定されます。 - 内部の人的なプロセスにより、送金には数日かかる場合があります。 - 仲介機関への分け前が必要なため、金融サービスには手数料が必要です。 ### 比較 {#defi-comparison} -| 分散型金融(DeFi) | 従来の金融システム | +| 分散型金融(DeFi) | 従来の金融システム | | ----------------------------------------------------- | --------------------------------------------------- | | 自分でお金を保有します。 | 企業があなたのお金を保有します。 | | 自分のお金がどこに行くか、どのように使われるかをコントロールすることができます。 | リスクの高い借り手に貸し出す等、企業があなたのお金を煩雑に管理していないことを信用する必要があります。 | | 資金の移動は数分で完了します。 | 支払いには手動の作業プロセスのために数日かかることがあります。 | | トランザクションは仮名で行われます。 | 金融活動は、利用者の個人情報と密接に結びついています。 | -| 分散型金融(DeFi)は誰でも利用できます。 | 金融サービスの利用申請が必要です。 | +| 分散型金融(DeFi)は誰でも利用できます。 | 金融サービスの利用申請が必要です。 | | 市場は常にオープンしています。 | 従業員の休息のため、市場が閉じる時間があります。 | | 誰もが製品データを見て、システムがどのように機能しているかを調べることができる、透明性の高いシステムです。 | 金融機関はクローズド・ブックであり、融資の履歴や運用資産の記録などを見せてもらうことはできません。 | - 分散型金融(DeFi)アプリを探す + DeFiアプリを探す ## 始まりはビットコイン... {#bitcoin} @@ -59,16 +60,16 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ -## プログラム可能な通貨 {#programmable-money} +## プログラム可能なお金 {#programmable-money} -これは一見奇妙なことのように聞こえます。「なぜ自分のお金をプログラムする必要があるのでしょうか?」 しかし、これはむしろイーサリアムのトークンのデフォルト機能に過ぎません。 誰でも支払いに論理をプログラムすることができます。 プログラミングにより、金融機関が提供するサービスに、ビットコインのコントロールとセキュリティを混在させることができます。 貸し借りや支払いのスケジューリング、インデックスファンドへの投資など、ビットコインではできないことを暗号通貨で行うことができます。 +奇妙に聞こえるかもしれませんが… 「なぜ自分のお金をプログラムする必要があるのでしょうか?」 しかし、これはむしろイーサリアムのトークンのデフォルト機能に過ぎません。 誰でも支払いに論理をプログラムすることができます。 プログラミングにより、金融機関が提供するサービスに、ビットコインのコントロールとセキュリティを混在させることができます。 貸し借りや支払いのスケジューリング、インデックスファンドへの投資など、ビットコインではできないことを暗号通貨で行うことができます。 - +
イーサリアムを初めて使う方にお勧めの分散型金融(DeFi)アプリケーション
- 分散型金融(DeFi)アプリを探す + DeFiアプリを探す @@ -77,49 +78,49 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ ほとんどの金融サービスには、分散型の代替手段があります。 しかし、イーサリアムは、次のようなまったく新しい金融商品を生み出す機会も与えてくれます。 リストは増え続けていきます。 -- [世界中への送金](#send-money) -- [世界中へのお金の流通](#stream-money) -- [安定した通貨へのアクセス](#stablecoins) -- [担保から資金の借り入れ](#lending) -- [担保なしの借り入れ](#flash-loans) -- [暗号資産の預金口座の開設](#saving) -- [トークンのトランザクション](#swaps) -- [ポートフォリオの拡大](#investing) -- [アイデアへの資金供給](#crowdfunding) -- [保険の購入](#insurance) -- [ポートフォリオ管理](#aggregators) +- [世界中に送金する](#send-money) +- [世界中にお金をストリーミングする](#stream-money) +- [ステーブルコインにアクセスする](#stablecoins) +- [担保付きで資金を借りる](#lending) +- [担保なしで借りる](#flash-loans) +- [暗号資産で貯蓄を始める](#saving) +- [トークンを取引する](#swaps) +- [ポートフォリオを拡大する](#investing) +- [アイデアの資金を調達する](#crowdfunding) +- [保険に加入する](#insurance) +- [ポートフォリオを管理する](#aggregators) -### 世界中に素早く送金 {#send-money} +### 世界中に素早く送金する {#send-money} -イーサリアムはブロックチェーンとして、安全かつグローバルな方法でトランザクションを行うために設計されています。 ビットコイン同様、イーサリアムは世界中にお金を送ることが、メールを送るように簡単にできます。 受信者の[イーサリアム・ネーム・サービス(ENS)名](/glossary/#ens) (例: bob.eth)またはウォレットのアカウントアドレスを入力するだけで、通常、数分後には支払いが直接相手に届きます。 支払いの送受信には、 [ウォレット](/wallets/)が必要です。 +イーサリアムはブロックチェーンとして、安全かつグローバルな方法でトランザクションを行うために設計されています。 ビットコイン同様、イーサリアムは世界中にお金を送ることが、メールを送るように簡単にできます。 受信者の[ENS名](/glossary/#ens)(bob.ethなど)またはウォレットのアカウントアドレスを入力するだけで、通常は数分で支払いが直接相手に届きます。 支払いの送受信には、[ウォレット](/wallets/)が必要です。 - 支払いの分散型アプリ(Dapp)を見る + 決済dappsを見る #### 世界中へのお金の流通... {#stream-money} また、イーサリアムでお金を流通させることもできます。 これにより、誰かに給料を秒単位で支払うことができ、受取人は必要なときにいつでもお金にアクセスすることができます。 また、コインロッカーや電動自転車など、秒単位でレンタルすることもできます。 -また、[ETH](/glossary/#ether)の価値がどれだけ変わるかわからないので、送金や流通はしたくないという方には、イーサリアムの代替通貨である[ステーブルコイン](/glossary/#stablecoin)があります。 +また、価値の変動が大きいため[ETH](/glossary/#ether)の送金やストリーミングをしたくない場合でも、イーサリアムには代替通貨である[ステーブルコイン](/glossary/#stablecoin)があります。 -### 安定した通貨へのアクセス {#stablecoins} +### ステーブルコインへのアクセス {#stablecoins} 暗号通貨の変動性は、多くの金融商品や一般歳出にとっては問題となります。 分散型金融(DeFi)コミュニティはこれをステーブルコインで解決しました。 ステーブルコインの価値は、別の資産、通常はドルのような一般的な通貨を担保にしています。 DaiやUSDCのようなコインの価値変動は、1ドルで数セントの範囲内です。 そのため、給与や小売業に最適です。 中南米では、政府が発行する通貨に大きな不安があるため、自分の貯蓄を守る手段として、多くの人々がステーブルコインを利用しています。 - ステーブルコインの詳細 +ステーブルコインの詳細はこちら -### 融資 {#lending} +### 借り入れ {#lending} 分散型プロバイダーからお金を借りるには、大きく分けて2種類あります。 @@ -127,24 +128,24 @@ DaiやUSDCのようなコインの価値変動は、1ドルで数セントの範 - プールベース: 借り手が借り入れることができるプールに、貸し手が資金(流動性)を提供する方法です。 - 融資分散型アプリ(Dapp)を見る + 借り入れdappsを見る 分散型貸付業者の利用には、多くの利点があります。 -#### プライバシーを守りながらの借り入れ {#borrowing-privacy} +#### プライバシーを確保した借り入れ {#borrowing-privacy} 現在、お金の貸し借りは、すべて個人が中心となって行われています。 銀行は融資をする前に、借り手に返済する見込みがあるかどうかを見極める必要があります。 -分散型融資は、どちらも自分の名前を名乗る必要がありません。 その代わり、借り手は担保を提供する必要があり、その担保は融資が返済されない場合に貸し手が自動的に受け取ることになります。 一部の貸し手では、[非代替性トークン(NFT)](/glossary/#nft)を担保として受け入れています。 非代替性トークン(NFT)とは、美術絵画のような唯一無二の資産に対する証明です。 [非代替性トークン(NFT)の詳細](/nft/) +分散型融資は、どちらも自分の名前を名乗る必要がありません。 その代わり、借り手は担保を提供する必要があり、その担保は融資が返済されない場合に貸し手が自動的に受け取ることになります。 貸し手の中には、[NFT](/glossary/#nft)を担保として受け入れるところもあります。 非代替性トークン(NFT)とは、美術絵画のような唯一無二の資産に対する証明です。 [NFTの詳細](/nft/) これにより、クレジットチェックや個人情報を開示せずにお金を借りることができます。 -#### グローバル資金へのアクセス {#access-global-funds} +#### グローバルな資金へのアクセス {#access-global-funds} -分散型金融機関を利用すると、あなたが選んだ銀行や金融機関に預けている資金だけでなく、世界中から入金された資金にアクセスすることができます。 これにより、ローンがより利用しやすくなり、金利も改善されます。 +分散型金融機関を利用すると、あなたが選んだ銀行や金融機関に預けている資金だけでなく、世界中から入金された資金にアクセスすることができます。 これによりローンがより利用しやすくなり、金利が改善されます。 -#### 課税効率 {#tax-efficiencies} +#### 税効率 {#tax-efficiencies} ETHを売却(課税対象)することなく、必要な資金を借り入れることができます。 その代わり、ETHを担保にステーブルコインを借りることができます。 これにより、必要なキャッシュフローを得ることができ、ETHをそのまま保有しておくことができます。 ステーブルコインは、ETHのように価値が変動しないので、現金が必要な時にはより適しているトークンです。 [ステーブルコインの詳細](#stablecoins) @@ -177,22 +178,22 @@ ETHを売却(課税対象)することなく、必要な資金を借り入れる -### 暗号資産で預金を始める {#saving} +### 暗号資産で貯蓄を始める {#saving} -#### 貸付 {#lending} +#### 貸し出し {#lending} -暗号通貨を貸すことで利息を得ることができ、資金が増えていく様子をリアルタイムで見ることができます。 現在の利息は、地元の銀行で得られる金利よりもはるかに高いです(運良く銀行を利用できた場合)。 次に例を示します。 +暗号通貨を貸すことで利息を得ることができ、資金が増えていく様子をリアルタイムで見ることができます。 現在の利息は、地元の銀行で得られる金利よりもはるかに高いです(運良く銀行を利用できた場合)。 具体的なコードは、以下のようになります： -- [ステーブルコイン](/stablecoins/)である100 DaiをAaveのようなサービスに貸し付けます。 +- [ステーブルコイン](/stablecoins/)である100 Daiを、Aaveのようなプロダクトに貸し付けます。 - 貸したDaiを表すトークンである100 Aave Dai (aDai)を受領します。 -- aDaiは金利に基づいて増加し、あなたのウォレットで残高が増えていくのを見ることができます。 [年換算利回り(APR)](/glossary/#apr)に応じて、数日後、あるいは数時間後にウォレットの残高が100.1234のように表示されます。 +- aDaiは金利に基づいて増加し、あなたのウォレットで残高が増えていくのを見ることができます。 [APR](/glossary/#apr)(年換算利回り)に応じて、数日後、あるいは数時間後にはウォレットの残高が100.1234のように表示されます。 - aDai残高と同額の通常のDaiをいつでも引き出すことができます。 - 貸付サービスの分散型アプリ(Dapp)を見る + レンディングdappsを見る -#### 損失がない宝くじ {#no-loss-lotteries} +#### 損失のでない宝くじ {#no-loss-lotteries} PoolTogetherのような損失のない宝くじは、楽しく革新的な新しい貯蓄方法です。 @@ -210,14 +211,14 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新 -### トークンの交換 {#swaps} +### トークンを交換する {#swaps} イーサリアムには何千ものトークンがあります。 分散型取引所(DEX)でいつでも異なるトークンを取引できます。 ご自身の資産の管理をあきらめる必要はありません。 これは、外国に行ったときに両替所を利用するようなものです。 しかし、分散型金融(DeFi)では両替所は閉じることはありません。 市場は365日24時間体制で、テクノロジーにより、取引を受け付ける人が常にいます。 -例えば、上述の損失のない宝くじPoolTogetherを利用したい場合、DaiやUSDCなどのトークンが必要になります。 これらの分散型取引所では、自分のETHをそれらのトークンと交換し、終了後またETHに戻すことができます。 +例えば、上述の損失のない宝くじPoolTogetherを利用したい場合、DaiやUSDCなどのトークンが必要になります。 これらの分散型取引所では、自分のETHをそれらのトークンと取引し、終了後またETHに戻すことができます。 - トークン交換所を見る + トークン取引所を見る @@ -229,24 +230,24 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新 中央集権的な取引所を利用する場合は、取引を行う前に資産を預けて、その資産の管理を任せなければなりません。 中央の取引所はハッカーにとって魅力的なターゲットであるため、資産が預けられている間はリスクがあります。 - トレード分散型アプリ(Dapp)を見る + トレーディングdappsを見る -### ポートフォリオの拡大 {#investing} +### ポートフォリオを拡大する {#investing} イーサリアムには、自分が選んだ戦略に基づいてポートフォリオを拡大を図るファンドマネジメント商品があります。 これは、自動的、誰にでも開かれていて、かつ管理者に利益の一部を取られる必要はありません。 -その良い例が、[分散型金融Pulseインデックスファンド(DPI)](https://defipulse.com/blog/defi-pulse-index/)です。 これは、あなたのポートフォリオが常に時価総額上位のDeFiトークンを含むように自動的にリバランスするファンドです。 細かい管理をする必要がなく、好きな時にファンドから引き出すことができます。 +良い例として、[DeFi Pulse Indexファンド(DPI)](https://defipulse.com/blog/defi-pulse-index/)が挙げられます。 これは、あなたのポートフォリオが常に時価総額上位のDeFiトークンを含むように自動的にリバランスするファンドです。 細かい管理をする必要がなく、好きな時にファンドから引き出すことができます。 - 投資分散型アプリ(Dapp)を見る + 投資dappsを見る -### アイデアへの資金供給 {#crowdfunding} +### アイデアの資金を調達する {#crowdfunding} イーサリアムはクラウドファンディングに理想的なプラットフォームです。 @@ -255,14 +256,14 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新 - 出資者は、例えば、特定の期限や最低金額が達成されなかった場合、自動的に返金されるように設定することができます。 - クラウドファンディング分散型アプリ(Dapp)を見る + クラウドファンディングdappsを見る -#### クオドラティック・ファンディング {#quadratic-funding} +#### クアドラティック・ファンディング {#quadratic-funding} -イーサリアムはオープンソースソフトウェアであり、これまでの作業の多くはコミュニティの資金提供を受けてきました。 これにより、クオドラティック・ファンディングという興味深い新しい資金調達モデルが成長しました。 将来的に、私達が公共財のすべてのタイプに資金を供給する方法を改善する可能性があるファンディングです。 +イーサリアムはオープンソースソフトウェアであり、これまでの作業の多くはコミュニティの資金提供を受けてきました。 これにより、クオドラティック・ファンディングという興味深い新しい資金調達モデルが成長しました。 クアドラティック・ファンディングは、将来的にすべての種類の公共財の資金供給方法を改善できる可能性を秘めており、 -クオドラティック・ファンディングでは、最もユニークな必要性があるプロジェクトが、最も多くの資金を受け取るようになっています。 つまり、ほとんどの人々の生活を向上させるためのプロジェクトです。 その仕組みは次のとおりです。 +最もユニークな必要性があるプロジェクトが、最多の資金を受け取るようになっています。 つまり、最も多くの人々が必要なものに資金が渡り、人々の生活の向上につながるプロジェクトです。 その仕組みは次のとおりです。 1. 寄付を集めて供与先を決めるためのマッチングプールがあります。 2. 資金供与のラウンドが始まります。 @@ -272,7 +273,7 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新 つまり、1ドルの寄付が100件集まったプロジェクトAの方が、1つの1万ドルの寄付に支援されたプロジェクトBよりも多くの資金を得られる可能性があるということです(マッチングプールの大きさによります)。 - クオドラティック・ファンディングの詳細 + クアドラティック・ファンディングの詳細 @@ -281,10 +282,10 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新 分散型保険は、保険料をより安く、より早く、より透明にすることを目指しています。 自動化が進めば、保険料はより手頃になり、支払いもより迅速になります。 保険請求を決定するために使用されるデータには、完全に透明性があります。 -他のソフトウェアと同様、イーサリアム製品は、バグや不正搾取の問題があります。 そのため、現在のところ、この分野の保険商品の多くは、ユーザーが資金を失うことを防ぐことに重点を置いています。 しかし、起こりうるあらゆることをカバーするプロジェクトも存在しています。 その良い例が、[ケニアの零細農家を干ばつや洪水から守ることを目的とした](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)Etheriscの生産物保証です。 分散型の保険は、従来の保険では値段が高過ぎて手がでないことが多い農民に、より安価な保険を提供することができます。 +Ethereum製品は、他のソフトウェアと同様に、バグや不正搾取に悩まされることがあります。 そのため、現在のところ、この分野の保険商品の多くは、ユーザーが資金を失うことを防ぐことに重点を置いています。 しかし、起こりうるあらゆることをカバーするプロジェクトも存在しています。 この良い例は、[ケニアの小規模農家を干ばつや洪水から守る](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)ことを目的としたEtheriscのCrop coverです。 分散型の保険は、従来の保険では値段が高過ぎて手がでないことが多い農民に、より安価な保険を提供することができます。 - 保険分散型アプリ(Dapp)見る + 保険dappsを見る @@ -294,7 +295,7 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新 多くのことが行われているため、すべての投資、ローン、取引を記録する方法が必要になります。 すべての分散型金融(DeFi)アクティビティを1つの場所で管理できる製品が多数あります。 これが分散型金融(DeFi)のオープンアーキテクチャーの魅力です。 製品すべての残高を確認できるだけでなく、その機能を利用できるインターフェースを構築することができます。 分散型金融(DeFi)をより深く知るための参考にしてみてください。 - ポートフォリオ分散型アプリ(Dapp)を見る + ポートフォリオdappsを見る @@ -311,53 +312,54 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新 これは、現在のところ、コードを解読できるイーサリアムコミュニティの技術的なメンバーを信頼する必要があることを意味しています。 オープンソースベースのコミュニティは、デベロッパーをチェックするのに役立っていますが、スマートコントラクトが解読しやすくなり、コードの信頼性を証明する他の方法が開発されるにつれて、この必要性は時間とともに減少していくでしょう。 -## イーサリアムと分散型金融(DeFi) {#ethereum-and-defi} +## イーサリアムとDeFi {#ethereum-and-defi} イーサリアムは、さまざまな理由から分散型金融(DeFi)の基盤として最適です。 - イーサリアムやスマートコントラクトは誰かの所有物ではないため、誰もが分散型金融(DeFi)を利用することができます。 これはまた、誰もあなたに関するルールを変更できないことを意味します。 -- 分散型金融(DeFi)製品はすべて、舞台裏で同じ言語を話しており、その言語はイーサリアムです。 このため、多くの製品がシームレスに連携します。 あるプラットフォームでトークンを貸し出し、その利息付きトークンを全く別のアプリケーションで別の市場で交換することができます。 これは、銀行でポイントを現金化できるようなものです。 +- 分散型金融(DeFi)製品はすべて、舞台裏で同じ言語を話しており、その言語はイーサリアムです。 このため、多くの製品がシームレスに連携します。 あるプラットフォームでトークンを貸し出し、その利息付きトークンを全く別のアプリケーションで別の市場で取引することができます。 これは、銀行でポイントを現金化できるようなものです。 - トークンと暗号通貨は、共有台帳であるイーサリアムに組み込まれています。トランザクションや所有権を追跡することは、イーサリアムの得意とするところです。 - イーサリアムは完全な経済的自由を可能にします。ほとんどの製品はあなたの資金を管理することはなく、自分の資金を自分でコントロールすることができます。 分散型金融(DeFi)をレイヤーで考えてみましょう。 1. ブロックチェーン - イーサリアムには、トランザクション履歴やアカウント状態が記録されています。 -2. 資産 - [ETH](/what-is-ether/)とその他のトークン(通貨) -3. プロトコル - 機能を提供する[スマートコントラクト](/glossary/#smart-contract)は、例えば資産の分散型レンディングを可能にするサービスなどを提供します。 -4. [アプリ](/apps/) - プロトコルの管理やアクセスのために使用する製品 +2. 資産 – [ETH](/what-is-ether/)およびその他のトークン(通貨)のことです。 +3. プロトコル – 機能を提供する[スマートコントラクト](/glossary/#smart-contract)のことで、例えば資産の分散型貸付を可能にするサービスなどです。 +4. [アプリケーション](/apps/) – プロトコルを管理し、アクセスするために使用するプロダクトのことです。 -注意: DeFiの多くは、[ERC-20規格](/glossary/#erc-20)を使っています。 DeFiのアプリケーションでは、ラップドイーサ(WETH)というラップされたETHを使うことになります。 [ラップドイーサの詳細](/wrapped-eth)。 +注：DeFiの多くは[ERC-20規格](/glossary/#erc-20)を利用しています。 DeFiのアプリケーションでは、Wrapped ether（WETH）と呼ばれるETHのラッパーを使用します。 [ラップされたEtherの詳細はこちら](/wrapped-eth)。 -## 分散型金融(DeFi)の構築 {#build-defi} +## DeFiを構築する {#build-defi} 分散型金融(DeFi)はオープンソースのムーブメントです。 分散型金融(DeFi)のプロトコルとアプリケーションはすべて公開されており、ユーザーが検査、フォーク(分岐)、改変を行うことができます。 このようにレイヤー状になっているため(ベースとなるブロックチェーンや資産はすべて共通)、プロトコルを組み合わせ、ユニークな組み合わせでのチャンスを生み出すことができます。 - 分散型アプリ(Dapp)構築の詳細 + dapps構築の詳細 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -### 分散型金融(DeFi)データ {#defi-data} +### DeFiデータ {#defi-data} - [DeFi Prime](https://defiprime.com/) - [DeFi Llama](https://defillama.com/) -### 分散型金融(DeFi)に関する記事 {#defi-articles} +### DeFi関連記事 {#defi-articles} -- [DeFi初心者ガイド](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu (2020年1月6日)_ +- [DeFi初心者ガイド](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu、2020年1月6日_ +- [EEA DeFiリスク評価ガイドライン](https://entethalliance.org/specs/defi-risks/) – DeFiプロトコルの主要なリスクを特定・評価する方法について、業界が支援する概要。 -### ビデオ {#videos} +### 動画 {#videos} -- [Finematics - 分散型金融に関する教育](https://finematics.com/) – _分散型金融(DeFi)に関するビデオ_ -- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _分散型金融(DeFi)の基本: 時に不可解な分散型金融を始めるために学ぶべきことすべて。_ -- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _分散型金融(DeFi)とは_ +- [Finematics - 分散型金融の教育](https://finematics.com/) – _DeFiに関するビデオ_ +- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _DeFiの基礎: 時には難解なこの分野を始めるために知っておくべきことのすべて。_ +- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _DeFiとは?_ ### コミュニティ {#communities} -- [DeFi Pulse Discord server](https://discord.defillama.com/) -- [DeFi Pulse Discord server](https://discord.gg/Gx4TCTk) +- [DeFi LlamaのDiscordサーバー](https://discord.defillama.com/) +- [DeFi PulseのDiscordサーバー](https://discord.gg/Gx4TCTk) diff --git a/public/content/translations/ja/desci/index.md b/public/content/translations/ja/desci/index.md index 2096652408c..e12a7708586 100644 --- a/public/content/translations/ja/desci/index.md +++ b/public/content/translations/ja/desci/index.md @@ -1,43 +1,43 @@ --- -title: 分散型科学 (DeSci) -description: イーサリアム上の分散型科学の概要 +title: "分散型サイエンス(DeSci)" +description: "イーサリアム上の分散型科学の概要" lang: ja template: use-cases emoji: ":microscope:" sidebarDepth: 2 image: /images/future_transparent.png alt: "" -summaryPoint1: 現在の科学に代わる、グローバルで開かれたシステム。 -summaryPoint2: 科学者が資金を調達し、実験を行い、データーを共有し、得られた見識を広めることなどを可能にする技術。 -summaryPoint3: オープンサイエンス運動の上に構築。 +summaryPoint1: "現在の科学に代わる、グローバルで開かれたシステム。" +summaryPoint2: "科学者が資金を調達し、実験を行い、データーを共有し、得られた見識を広めることなどを可能にする技術。" +summaryPoint3: "オープンサイエンス運動の上に構築。" --- ## 分散型科学(DeSci)とは何か {#what-is-desci} -分散型科学(DeSci)は[Web3](/glossary/#web3)スタックを用いることで、科学的知見に対する財政支援、そして科学的知見の創造、審査、認定、保管、普及のための、公平公正な公的インフラストラクチャの形成を目指す運動です。 +分散型科学(DeSci)は、[Web3](/glossary/#web3)スタックを使用して、科学的知識の資金調達、創造、レビュー、単位認定、保存、普及を公正かつ公平に行うための公共インフラの構築を目指す運動です。 DeSciは、科学者が自身の研究を公然と共有することにインセンティブを与えられ、そしてその仕事に対する名声を得られ、一方で誰もが簡単にその研究にアクセスし、さらに研究に貢献できるようなエコシステムの形成を目指しています。 DeSciは、科学的知識は誰にでもアクセス可能であり、科学研究のプロセスは透明であるべきという考えに則っています。 DeSciはより非中央集権的で分散型の科学研究モデルを形成することで、中央当局による検閲と管理に対する抵抗力を高めます。 DeSciは、資金調達、科学的ツール、コミュニケーション手段へのアクセスを分散化することによって、慣習にとらわれない新しいアイデアが繁栄する環境を作りたいと考えています。 -分散型科学により、多様な資金調達方法([分散型自律組織](/glossary/#dao)、[クアドラティックドネーション](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、クラウドファンディングなど)が可能となることで、データや科学的手法へのアクセスが容易になり、さらに再現性へのインセンティブを付与することができます。 +分散型科学は、[DAO](/glossary/#dao)や[クアドラティックドネーション](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)からクラウドファンディングなど、より多様な資金源を可能にし、データや手法へのアクセスを容易にし、再現性へのインセンティブも提供します。 ### Juan Benet - DeSci運動 -## いかにしてDeSciが科学を向上させるのか {#desci-improves-science} +## DeSciが科学をいかに改善するか {#desci-improves-science} 科学の主要な問題点と、分散型科学でどのような解決が可能かをまとめた現時点におけるリストです。 -| **分散型科学** | **従来の科学** | -| --------------------------------------------------------------- | ------------------------------------------------------------- | -| 資金分配は、クアドラティックドネーションやDAOなどのメカニズムを用いて、**大衆によって決定されます**。 | 小規模で閉鎖的な**中央集権化されたグループ**が、資金分配をコントロールします。 | -| **世界中の誰とでも**、動的なチームを形成して研究ができます。 | 資金提供団体や科学者の所属機関により、共同研究が**制限**されます。 | -| 資金調達の決定は、オンラインかつ**透明性**をもって実行されます。 新しい資金調達のメカニズムが検討されます。 | 資金調達の決定には長い時間がかかり、**限られた透明性**の中で実行しています。 資金調達のメカニズムはほぼ存在しません。 | -| [Web3](/glossary/#web3)技術を利用することで、研究所のサービスをより簡単かつ透明性をもって共有できます。 | 研究所のリソースを共有できるまでに**時間がかかることが多く、その手続きも不透明**です。 | -| Web3プリミティブによって、信頼性と透明性が高く、かつ普遍的アクセスを実現する**新たな出版モデル**の開発が可能です。 | **非効率的でバイアスがあり、悪用されうる**旧来の手続きによって研究成果が出版されます。 | -| **論文を査読することでトークンや評価を得ることができます**。 | 研究者が**無報酬で査読**し、営利目的の出版社に利益を提供します。 | -| 科学者が自身の生み出した**知的財産(IP)を所有し**、透明性のある条件に従って配布します。 | 科学者が生み出した**知的財産は所属機関が所有**します。 知的財産へのアクセスは不透明です。 | -| 全手順をオンチェーンにすることで、失敗した作業のデータも含めて、**すべての研究を共有できます**。 | **出版バイアス**とは、成功した実験ほど共有する傾向が強いというバイアスです。 | +| **分散型科学** | **従来の科学** | +| -------------------------------------------------------------- | ------------------------------------------------------------ | +| 資金の分配は、クアドラティックドネーションやDAOなどのメカニズムを用いて**一般の人々によって決定されます**。 | 小規模で閉鎖的な**中央集権化されたグループ**が、資金の分配をコントロールします。 | +| ダイナミックなチームで**世界中の**仲間と共同作業ができます。 | 資金提供団体や所属機関によって、共同研究が**制限されます**。 | +| 資金調達の決定は、オンラインかつ**透明性をもって**実行されます。 新しい資金調達のメカニズムが検討されます。 | 資金調達の決定には長い時間がかかり、**限られた透明性**の中で実行されます。 資金調達のメカニズムはほぼ存在しません。 | +| [Web3](/glossary/#web3)技術を利用することで、研究室サービスの共有がより簡単かつ透明になります。 | 研究室リソースの共有は、しばしば**遅くて不透明です**。 | +| 信頼、透明性、普遍的なアクセスのためにWeb3プリミティブを使用する**新しい出版モデル**を開発することができます。 | しばしば**非効率的、偏向的、搾取的**と見なされる既存の経路を通して出版されます。 | +| **査読作業でトークンと評価を得る**ことができます。 | **査読作業は無報酬**で、営利目的の出版社に利益をもたらします。 | +| **あなたが生成した知的財産(IP)を所有**し、透明性のある条件に従って配布します。 | **あなたが生成したIPは、所属機関が所有します**。 知的財産へのアクセスは不透明です。 | +| すべてのステップをオンチェーンにすることで、失敗した取り組みのデータを含む**すべての研究を共有**します。 | **出版バイアス**とは、研究者が成功した結果の実験を共有する可能性が高いことを意味します。 | ## イーサリアムとDeSci {#ethereum-and-desci} @@ -49,89 +49,91 @@ DeSciは、従来の学術界をデジタルの世界にオンボーディング ### 出版 {#publishing} -科学論文の出版は顕著な問題を抱えており、その背景には、論文の作成にあたり、科学者、査読者、編集者を無報酬で働かせ、法外な出版料を請求する出版社の存在があります。 一般市民は税金という形で科学者の活動費と出版費を間接的に支払っていますが、通常は、出版社に対して追加で支払いを行わないと、出版物を閲覧することはできません。 個々の科学論文の出版にかかる総額は、通常米ドルで5桁に上り、[公共財](/glossary/#public-goods)としての科学的知識の概念が損なわれる一方で、少数の出版社に莫大な利益がもたらされています。 +科学論文の出版は顕著な問題を抱えており、その背景には、論文の作成にあたり、科学者、査読者、編集者を無報酬で働かせ、法外な出版料を請求する出版社の存在があります。 一般市民は税金という形で科学者の活動費と出版費を間接的に支払っていますが、通常は、出版社に対して追加で支払いを行わないと、出版物を閲覧することはできません。 個々の科学論文を出版するための総費用は、しばしば5桁(米ドル)に上り、科学的知識を[公共財](/glossary/#public-goods)とみなす概念を損なう一方で、少数の出版社に莫大な利益がもたらされています。 -無料のオープンアクセスプラットフォームは、[ArXiv](https://arxiv.org/)などのプリントサーバーという形で存在します。 しかし、こうしたプラットフォームは品質管理や[シビル攻撃を防ぐメカニズム](/glossary/#anti-sybil)が不足しているうえに、通常は個々の論文の評価も追跡しません。つまり、従来の出版社に投稿する前に研究を発表するためだけに利用されています。 SciHubでは出版された論文に自由にアクセスできますが、合法ではありません。自由なアクセスは、出版社が料金を受け取った後、厳格に著作権法に則って提供されるべきものです。 科学論文やデーターをアクセスしやすい形で、かつ合法性が担保された枠組みで提供することについては、大きな改善の余地があります。 Web3には、このようなシステムを構築するためのツールが存在します。 +無料のオープンアクセスプラットフォームは、[ArXiv](https://arxiv.org/)などのプレプリントサーバーの形で存在します。 しかし、これらのプラットフォームは品質管理や[アンチシビルメカニズム](/glossary/#anti-sybil)に欠けており、通常、記事レベルの指標を追跡しません。つまり、従来の出版社に投稿する前に研究を公表するためにのみ使用されているのが普通です。 SciHubでは出版された論文に自由にアクセスできますが、合法ではありません。自由なアクセスは、出版社が料金を受け取った後、厳格に著作権法に則って提供されるべきものです。 科学論文やデーターをアクセスしやすい形で、かつ合法性が担保された枠組みで提供することについては、大きな改善の余地があります。 Web3には、このようなシステムを構築するためのツールが存在します。 -### 再現可能性と再生可能性 {#reproducibility-and-replicability} +### 再現性と複製可能性 {#reproducibility-and-replicability} 再現可能性と再生可能性は価値ある科学的発見の基礎となるものです。 - 再現可能な結果とは、同一の研究グループが同じ手法を用いて、繰り返し連続で得られるものです。 - 再生可能な結果とは、別の研究グループが、同一の実験設定の下で得られるものです。 -新しいWeb3ネイティブなツールによって、再現性と複製性が発見の基礎であることが保証できるようになります。 アカデミアの技術的な構造に優れた科学を織り込むことができます。 Web3によって、生データ、計算エンジン、アプリケーションの結果などの解析コンポーネントに関する[アテステーション](/glossary/#attestation)を作成できるようになります。 コンセンサスシステムの素晴らしいところは、信頼できるネットワークを作成してそれらのコンポーネントを維持する場合に、ネットワークの各参加者が計算の再現と結果の検証に貢献できることにあります。 +新しいWeb3ネイティブなツールによって、再現性と複製性が発見の基礎であることが保証できるようになります。 アカデミアの技術的な構造に優れた科学を織り込むことができます。 Web3により、生データ、計算エンジン、アプリケーションの結果といった各分析コンポーネントの[アテステーション](/glossary/#attestation)を作成できます。 コンセンサスシステムの素晴らしいところは、信頼できるネットワークを作成してそれらのコンポーネントを維持する場合に、ネットワークの各参加者が計算の再現と結果の検証に貢献できることにあります。 ### 資金調達 {#funding} -科学への資金提供における現在の標準モデルでは、個人や科学者のグループが資金配分機関に書面にて申請する手順となっています。 信頼できる少数の識者が申請書を採点し、その後候補者の面接を経て、評価の高かった一部の候補者に資金が提供されます。 助成金の申請から受領まで、時に**年単位で待つ**ことになるボトルネックを生み出すだけでなく、このモデルは、審査委員会による**偏見、私欲、権力闘争に対して非常に脆弱である**と言われています。 +科学への資金提供における現在の標準モデルでは、個人や科学者のグループが資金配分機関に書面にて申請する手順となっています。 信頼できる少数の識者が申請書を採点し、その後候補者の面接を経て、評価の高かった一部の候補者に資金が提供されます。 助成金の申請から受領までの間に時に**年単位の待ち時間**が生じるボトルネックを生み出すだけでなく、このモデルは審査委員会の**偏見、私利私欲、政治に対して非常に脆弱である**ことが知られています。 同じ提案であっても同委員会の担当者によって結果が大きく異なることがあり、優れた提案を選択するうえで助成金審査委員会は責務を果たしていないことが研究によって示されています。 資金調達が厳しくなる中で、資金の行く先は保守的なプロジェクトを行う少人数の上席研究者へと集中してきました。 その結果、非常に競争の激しい資金調達環境が生み出され、歪んだインセンティブを根付かせ、イノベーションを妨げることになりました。 -DAOとWeb3によって培われた各種インセンティブモデルを広く試すことで、現在の破綻した資金調達モデルを食い止めることができるかもしれません。 [遡及的な公共財の資金調達](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)、[クオドラティック・ファンディング](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、[DAOガバナンス](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead)、[トークン化されたインセンティブ構造](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)などのWeb3ツールには、科学の資金調達に大変革をもたらす可能性があります。 +DAOとWeb3によって培われた各種インセンティブモデルを広く試すことで、現在の破綻した資金調達モデルを食い止めることができるかもしれません。 [遡及的な公共財ファンディング](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)、[クアドラティックファンディング](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、[DAOガバナンス](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead)、[トークン化されたインセンティブ構造](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)は、科学の資金調達に革命を起こしうるWeb3ツールの一部です。 ### IPの所有権と開発 {#ip-ownership} -従来の科学において知的財産(IP)は大きな問題となっています。大学で身動きが取れない状況に陥っていたり、バイオテクノロジー業界で応用されていなかったり、評価ができない状態になってしまっています。 しかし、Web3が[非代替性トークン(NFT)](/glossary/#nft)を活用することで、デジタル資産(科学的データや論文など)を真に所有できるようになります。 +従来の科学において知的財産(IP)は大きな問題となっています。大学で身動きが取れない状況に陥っていたり、バイオテクノロジー業界で応用されていなかったり、評価ができない状態になってしまっています。 しかし、Web3は[非代替性トークン(NFT)](/glossary/#nft)を使用することで、デジタル資産(科学データや記事など)の所有権を非常にうまく扱うことができます。 NFTが将来の取引の収益を元の作成者に還元できるように、透明性のある価値の帰属チェーンを確立することができます。これにより、研究者やDAOのような管理団体、そしてデータの収集元となった被験者へも報酬を与えることができます。 -[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6)もまた、進行中の研究実験の分散データレポジトリにアクセスするための鍵として機能し、NFTや[DeFi](/glossary/#defi)の金融化(資産の分散、融資プールと価値評価) へとつながります。 また、[VitaDAO](https://www.vitadao.com/)のようなネイティブにチェーン上に存在するDAOを使用することで、研究活動を直接オンチェーンで行うことができます。 譲渡不可の[「ソウルバウンド」トークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)の出現により、イーサリアムアドレスにリンクされた経験や経歴を個人が証明できるようになるため、DeSciで重要な役割を果たす可能性があります。 +[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6)は、実施されている研究実験の分散型データリポジトリへの鍵として機能し、NFTや[DeFi](/glossary/#defi)の金融化(フラクショナル化からレンディングプール、価値評価まで)に接続することも可能です。 また、[VitaDAO](https://www.vitadao.com/)のようなDAOなど、ネイティブにオンチェーンのエンティティが、研究を直接オンチェーンで実施することも可能になります。 +譲渡不可能な["ソウルバウンド"トークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)の登場は、個人が自身のイーサリアムアドレスに紐づいた経験や信用情報を証明することを可能にするため、DeSciにおいて重要な役割を果たす可能性があります。 ### データストレージ、アクセス、アーキテクチャ {#data-storage} Web3の様式を活用することで科学データへのアクセスが大幅に向上し、分散ストレージによって研究成果を大災害から守ることができます。 -起点となるシステムは、適切かつ検証可能な認証情報を備えた分散型アイデンティティでアクセスできる必要があります。 そうすることで、冗長性や検閲耐性、結果の再現を可能にし、さらには複数の関係者が協力してデータセットに新しいデータを追加できるようになり、信頼のおける関係者によって機密データを安全に再生することができます。 [compute-to-data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol)のような機密コンピューティング方法は、生データの再生への代替アクセス機構を提供し、極めて機密性の高いデータに対して「信頼できる研究環境」を生成します。 [NHS](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb)は、信頼できる研究環境について、データプライバシーとコラボレーションにおいて将来的な解決策であると言及しています。これは、研究者がデータを安全に扱い、コードやプラクティスを共有するための標準化された環境を利用してオンサイトで作業できるエコシステムの構築を意味します。 +起点となるシステムは、適切かつ検証可能な認証情報を備えた分散型アイデンティティでアクセスできる必要があります。 そうすることで、冗長性や検閲耐性、結果の再現を可能にし、さらには複数の関係者が協力してデータセットに新しいデータを追加できるようになり、信頼のおける関係者によって機密データを安全に再生することができます。 [コンピュート・トゥ・データ](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol)のような秘匿コンピューティング手法は、生データの複製に代わるアクセスメカニズムを提供し、最も機密性の高いデータのために信頼できる研究環境を創出します。 信頼できる研究環境は、研究者がコードやプラクティスを共有するための標準化された環境を使用してオンサイトで安全にデータと連携できるエコシステムを作成することで、データプライバシーとコラボレーションの将来を見据えたソリューションとして、[NHSによって言及されています](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb)。 柔軟なWeb3データソリューションは、上記のシナリオをサポートし、研究者がアクセス許可や手数料なしで公共財を作成できる真のオープンサイエンスの基盤を提供します。 IPFS、Arweave、FilecoinなどのWeb3パブリックデータソリューションは、分散化のために最適化されています。 たとえば、dClimateは、気象観測所や予測気候モデルなどを含む、気候や気象データへの普遍的なアクセスを提供しています。 -## 参加 {#get-involved} +## 参加する {#get-involved} プロジェクトを探索し、DeSciコミュニティに参加してください。 -- [DeSci.Global: グローバルなイベントとオフ会カレンダー](https://desci.global) -- [サイエンステレグラムのためのブロックチェーン](https://t.me/BlockchainForScience) -- [Molecule: 研究プロジェクトのための資金提供と資金獲得](https://www.molecule.xyz/) -- [VitaDAO: 長寿研究のための研究スポンサー契約を通じた資金獲得](https://www.vitadao.com/) +- [DeSci.Global: 世界的なイベントとミートアップカレンダー](https://desci.global) +- [Blockchain for Science Telegram](https://t.me/BlockchainForScience) +- [Molecule: 研究プロジェクトへの資金提供と資金調達](https://www.molecule.xyz/) +- [VitaDAO: 長寿研究のためのスポンサー付き研究契約を通じて資金提供を受ける](https://www.vitadao.com/) - [ResearchHub: 科学的成果を投稿し、仲間と会話する](https://www.researchhub.com/) -- [dClimate API: 分散型コミュニティに収集された気候データのクエリ](https://www.dclimate.net/) -- [DeSci財団: DeSci出版ツールビルダー](https://descifoundation.org/) -- [DeSci.World: ユーザーが閲覧して参加できる分散型科学のワンストップショップ](https://desci.world) -- [OceanDAO: データ関連科学のための、DAOに統制された資金調達](https://oceanprotocol.com/) -- [Opsciana: オープン分散型サイエンスワークフロー](https://opsci.io/research/) -- [Bio.xyz: バイオテクノロジーDAOや分散型サイエンスプロジェクトのための資金獲得](https://www.bio.xyz/) -- [Flemingプロトコル: 共同のバイオメディカルの発見を促進するオープンソースのデータエコノミー](http://flemingprotocol.io/) +- [dClimate API: 分散型コミュニティによって収集された気候データをクエリする](https://www.dclimate.net/) +- [DeSci Foundation: DeSci出版ツールビルダー](https://descifoundation.org/) +- [DeSci.World: ユーザーが分散型科学を閲覧し、関与するためのワンストップショップ](https://desci.world) +- [OceanDAO: データ関連科学のためのDAOによる資金調達](https://oceanprotocol.com/) +- [Opscientia: オープンな分散型科学ワークフロー](https://opsci.io/research/) +- [Bio.xyz: バイオテクノロジーDAOまたはDeSciプロジェクトのための資金調達](https://www.bio.xyz/) +- [Fleming Protocol: 協調的な生物医学的発見を促進するオープンソースのデータエコノミー](http://flemingprotocol.io/) - [Active Inference Institute](https://www.activeinference.org/) -- [IdeaMarkets: 分散型科学の信ぴょう性の有効化](https://ideamarket.io/) +- [IdeaMarkets: 分散型科学の信頼性を実現](https://ideamarket.io/) - [DeSci Labs](https://www.desci.com/) -- [ValleyDAO: オープンなグローバルコミュニティで合成生物学研究のファンディングおよび翻訳に関するサポートを提供](https://www.valleydao.bio) -- [Cerebrum DAO: 脳の健康と神経変性を防ぐためのソリューションの調達と育成](https://www.cerebrumdao.com/) -- [CryoDAO: 冷凍保存分野におけるムーンショット型研究へのファンディング](https://www.cryodao.org) - -新しいプロジェクトを提案する際には[ポリシー一覧](/contributing/adding-desci-projects/)をご覧ください。 - -## 参考文献 {#further-reading} - -- [Jocelynn PearlとUltraareによるDeSci Wiki](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#) -- [Jocelynn Pearlによるa16zの未来のための分散型バイオテックのガイド](https://future.a16z.com/a-guide-to-decentralized-biotech/) -- [DeSciのケース](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/) -- [DeSciのガイド](https://future.com/what-is-decentralized-science-aka-desci/) -- [分散型科学のリソース](https://www.vincentweisser.com/desci) -- [MoleculeのBiopharma IP-NFTs - 技術説明](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description) -- [Jon Starrによるトラストレスな科学システムの構築](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673) -- [Paul Kohlaas - DeSci: 分散型科学の未来(ポッドキャスト)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a) -- [分散型サイエンスのための活発な推論オントロジー: 状況感覚から知識コモンズへ](https://zenodo.org/record/6320575) -- [DeSci: Samuel Akinoshoによる研究の未来](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec) -- [サイエンスファンディング(エピローグ: DeSciと新しい暗号プリミティブ) by Nadia](https://nadia.xyz/science-funding) -- [分散化は薬物開発を妨害する](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f) -- [DeSci - 分散型科学とは何か？](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/) +- [ValleyDAO: 合成生物学研究に資金提供とトランスレーショナルサポートを提供するオープンなグローバルコミュニティ](https://www.valleydao.bio) +- [Cerebrum DAO: 脳の健康を促進し、神経変性を予防するためのソリューションのソーシングと育成](https://www.cerebrumdao.com/) +- [CryoDAO: 人体冷凍保存分野のムーンショット研究への資金提供](https://www.cryodao.org) +- [Elata: 精神医学の未来に発言権を持つ](https://www.elata.bio/) + +新しいプロジェクトの掲載提案を歓迎します。まずは[掲載ポリシー](/contributing/adding-desci-projects/)をご覧ください。 + +## 参考リンク {#further-reading} + +- [Jocelynn PearlとUltrarareによるDeSci Wiki](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#) +- [Jocelynn Pearlによる分散型バイオテクノロジーのガイド(a16z future)](https://future.a16z.com/a-guide-to-decentralized-biotech/) +- [DeSciの事例](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/) +- [DeSciガイド](https://future.com/what-is-decentralized-science-aka-desci/) +- [分散型科学リソース](https://www.vincentweisser.com/desci) +- [Moleculeのバイオ医薬品IP-NFT - 技術的説明](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description) +- [Jon Starr著『トラストが不要な科学のシステムの構築』](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673) +- [Paul Kohlhaas - DeSci: 分散型科学の未来(ポッドキャスト)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a) +- [分散型科学のための能動的推論オントロジー: 状況的意味形成から認識論的コモンズまで](https://zenodo.org/record/6320575) +- [Samuel Akinosho著『DeSci: 研究の未来』](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec) +- [Nadia著『科学への資金提供(エピローグ: DeSciと新しい暗号プリミティブ)』](https://nadia.xyz/science-funding) +- [分散化が医薬品開発を破壊する](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f) +- [DeSci(分散型科学)とは何か](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/) ### 動画 {#videos} - [分散型科学とは何か](https://www.youtube.com/watch?v=-DeMklVWNdA) -- [長寿研究と暗号の交点についてのVitalik Buterinと科学者Aubrey de Greyの会話](https://www.youtube.com/watch?v=x9TSJK1widA) -- [破綻している科学出版業界を Web3で救えるか?](https://www.youtube.com/watch?v=WkvzYgCvWj8) -- [Juan Benet - DeSci、Independent Labs、及び大規模データサイエンス](https://www.youtube.com/watch?v=zkXM9H90g_E) -- [Sebastian Brunemeier - DeSciによる生体医学研究 & ベンチャーキャピタルの転換](https://www.youtube.com/watch?v=qB4Tc3FcVbM) -- [Paige Donner - Web3とブロックチェーンによるオープンサイエンスのツール化](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) +- [Vitalik Buterinと科学者Aubrey de Greyの対談: 長寿研究と暗号通貨の交差点](https://www.youtube.com/watch?v=x9TSJK1widA) +- 科学出版は破綻している。 Web3はそれを修正できるか？](https://www.youtube.com/watch?v=WkvzYgCvWj8) +- [Juan Benet - DeSci、独立研究室、大規模データサイエンス](https://www.youtube.com/watch?v=zkXM9H90g_E) +- [Sebastian Brunemeier - DeSciはいかにして生物医学研究とベンチャーキャピタルを変革できるか](https://www.youtube.com/watch?v=qB4Tc3FcVbM) +- [Paige Donner - Web3とブロックチェーンによるオープンサイエンスのツーリング](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) diff --git a/public/content/translations/ja/developers/docs/accounts/index.md b/public/content/translations/ja/developers/docs/accounts/index.md index e638d0c0488..5e7a041ee2d 100644 --- a/public/content/translations/ja/developers/docs/accounts/index.md +++ b/public/content/translations/ja/developers/docs/accounts/index.md @@ -1,28 +1,28 @@ --- -title: イーサリアムアカウント -description: イーサリアムアカウントの説明 - データ構造、鍵ペア暗号技術との関係 +title: "イーサリアムアカウント" +description: "イーサリアムアカウントの説明 - データ構造、鍵ペア暗号技術との関係" lang: ja --- -イーサリアムアカウントとは、イーサリアム上でトランザクションを送信できるEther(ETH)残高を持つエンティティです。 アカウントはユーザーが管理し、スマートコントラクトとしてデプロイすることができます。 +イーサリアムアカウントは、イーサ（ETH）残高を持ち、イーサリアム上でメッセージを送信できるエンティティです。 アカウントはユーザーが管理し、スマートコントラクトとしてデプロイすることができます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをよりよく理解するためには、[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 +このページをよりよく理解するために、まず[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 ## アカウントの種類 {#types-of-account} イーサリアムには2種類のアカウントがあります。 - 外部所有アカウント(EOA) – 秘密鍵の保有者により管理 -- コントラクトアカウント – ネットワークにデプロイされたスマートコントラクトでコードにより制御される。 [スマートコントラクト](/developers/docs/smart-contracts/)の詳細 +- コントラクトアカウント – ネットワークにデプロイされたスマートコントラクトでコードにより制御される。 [スマートコントラクト](/developers/docs/smart-contracts/)について学ぶ 両方のアカウントで次のことができます。 - ETHやトークンの受信、保有、送信 - 展開されたスマートコントラクトとのやりとり -### 主な相違点 {#key-differences} +### 主な違い {#key-differences} **外部所有アカウント** @@ -31,10 +31,10 @@ lang: ja - 外部所有アカウント間のトランザクションは、ETHやトークンの送金のみ可能 - アカウントの活動をコントロールする公開鍵と秘密鍵という暗号鍵のペアで構成 -**コントラクトアカウント** +**コントラクト** - コントラクト作成は有償(ネットワークストレージを使用するため) -- トランザクションの受信に応じてのみ、トランザクションを送信可能 +- トランザクションを受信することに対してのみメッセージを送信可能 - 外部アカウントからコントラクトアカウントへのトランザクションは、トークンの転送や新しいコントラクト作成まで、さまざまなアクションを実行するコードをトリガー可能 - コントラクトアカウントには秘密鍵がなく スマートコントラクトのコードのロジックによって制御される @@ -42,14 +42,15 @@ lang: ja イーサリアムアカウントには4つのフィールドがあります。 -- `nonce` – カウンターで、外部所有アカウントから送信されたトランザクションの数、あるいはコントラクトアカウントによって作成されたコントラクトの数を表します。 各アカウントは、既定のnonceを持つトランザクションを1回だけ実行するように設計されています。これにより、署名済みのトランザクションが繰り返しブロードキャスト、再実行されるリプレイ攻撃を防いでいます。 -- `balance` - アドレスが所有するwei額。 weiはETHの最小単位で、1ETHは1e+18wei。 -- `codeHash` - このハッシュは、イーサリアム仮想マシン(EVM)のアカウントの_コード_を指す。 コントラクトアカウントには、さまざまな操作を行えるコードの断片がプログラムされており、 このEVMコードはアカウントにメッセージ呼び出しがあった場合に実行される。 他のアカウントのフィールドとは異なり、変更することはできない。 このようなコードの断片はすべて、対応するハッシュの状態データベースに含まれ、後で取得可能。 このハッシュ値がcodeHashとして知られている。 外部所有アカウントの場合、codeHashフィールドは空の文字列のハッシュとなる。 -- `storageRoot` – ストレージハッシュとも呼ばれる。 アカウントのストレージ内容をコード化するMerkle Patriciaツリーのルートノードの256ビットハッシュ(256ビット整数値間のマッピング)で、256ビット整数キーのKeccak 256ビットハッシュからRLPエンコードされた256ビット整数値へのマッピングとしてデジタルツリーの中へコード化される。 このツリーは、このアカウントのストレージコンテンツのハッシュであり、デフォルトは空です。 +- `nonce` – 外部所有アカウントから送信されたトランザクションの数、またはコントラクトアカウントによって作成されたコントラクトの数を示すカウンター。 各アカウントは、既定のnonceを持つトランザクションを1回だけ実行するように設計されています。これにより、署名済みのトランザクションが繰り返しブロードキャスト、再実行されるリプレイ攻撃を防いでいます。 +- `balance` – このアドレスが所有するweiの数。 weiはETHの最小単位で、1ETHは1e+18wei。 +- `codeHash` – このハッシュは、イーサリアム仮想マシン(EVM)のアカウントの_コード_を指します。 コントラクトアカウントには、さまざまな操作を行えるコードの断片がプログラムされており、 このEVMコードはアカウントにメッセージ呼び出しがあった場合に実行される。 他のアカウントのフィールドとは異なり、変更することはできない。 このようなコードの断片はすべて、対応するハッシュの状態データベースに含まれ、後で取得可能。 このハッシュ値がcodeHashとして知られている。 外部所有アカウントの場合、codeHashフィールドは空の文字列のハッシュとなる。 +- `storageRoot` – ストレージハッシュとも呼ばれます。 アカウントのストレージ内容（256ビット整数値間のマッピング）をエンコードする[マークルパトリシアトライ](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)のルートノードの256ビットハッシュであり、256ビット整数キーのKeccak-256ハッシュからRLPエンコードされた256ビット整数値へのマッピングとしてトライにエンコードされます。 このツリーは、このアカウントのストレージコンテンツのハッシュであり、デフォルトは空です。 -![アカウントの構成図](./accounts.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +![アカウントの構成を示す図](./accounts.png) +_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)を参考に作成_ -## 外部所有アカウントと鍵のペア {#externally-owned-accounts-and-key-pairs} +## 外部所有アカウントと鍵ペア {#externally-owned-accounts-and-key-pairs} アカウントは、公開鍵と秘密鍵の暗号鍵のペアで構成されています。 トランザクションが送信者によって実際に署名されていることを証明し、偽造を防ぐためです。 秘密鍵はトランザクションの署名に使用されるもので、アカウントに紐づく資金を管理する権限を与えます。 暗号通貨を実際に保有することはなく、秘密鍵を保有するだけで、資金は常にイーサリアム台帳にあります。 @@ -63,36 +64,36 @@ lang: ja 秘密鍵は64文字で構成されており、パスワードで暗号化することができます。 -例: +例： `fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f` -公開鍵は、秘密鍵から[楕円曲線DSA](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)を用いて生成されます。 公開鍵のkeccak-256ハッシュの末尾20バイトに`0x` を先頭に追加することで、アカウントの公開アドレスを取得できます。 +公開鍵は、[楕円曲線デジタル署名アルゴリズム](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)を用いて秘密鍵から生成されます。 アカウントの公開アドレスは、公開鍵のKeccak-256ハッシュの最後の20バイトを取り出し、先頭に「0x」を付加することで得られます。 -これにより、外部所有アカウント (EOA) は42文字のアドレスを持ちます (20バイトのセグメントの40文字の16進数と `0x` のプレフィックスから成ります) 。 +これは、外部所有アカウント(EOA)のアドレスが42文字（20バイトのセグメントである40の16進文字に、プレフィックス「0x」を加えたもの）であることを意味します。 -例: +例： `0x5e97870f263700f46aa00d967821199b9bc5a120` -次の例は、[Clef](https://geth.ethereum.org/docs/tools/clef/introduction) というサインツールで、新しいアカウントを生成する方法です。 Clefは、イーサリアムクライアントの[Geth](https://geth.ethereum.org)に含まれる、アカウント管理および署名ツールです。 `clef newaccount`コマンドは、新しい鍵ペアを作成して、暗号化された鍵ストアに保存します。 +以下の例では、[Clef](https://geth.ethereum.org/docs/tools/clef/introduction)という署名ツールを使って新しいアカウントを生成する方法を説明します。 Clefは、イーサリアムクライアントである[Geth](https://geth.ethereum.org)にバンドルされているアカウント管理・署名ツールです。 `clef newaccount`コマンドは、新しい鍵ペアを作成し、暗号化されたキーストアに保存します。 ``` > clef newaccount --keystore -Please enter a password for the new account to be created: +作成する新しいアカウントのパスワードを入力してください: > ------------ -INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120 -WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120 -WARN [10-28|16:19:09.306] Please remember your password! -Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120 +INFO [10-28|16:19:09.156] 新しい鍵が生成されました address=0x5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] 鍵ファイルをバックアップしてください path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] パスワードを忘れないでください! +生成されたアカウント 0x5e97870f263700f46aa00d967821199b9bc5a120 ``` -[GETHのドキュメント](https://geth.ethereum.org/docs) +[Gethドキュメンテーション](https://geth.ethereum.org/docs) -秘密鍵から新しい公開鍵を生成することは可能ですが、公開鍵から秘密鍵を生成することはできません。 秘密鍵を安全に保つことは非常に重要であり、その名の通り**秘密**にしておくべきです。 +秘密鍵から新しい公開鍵を生成することは可能ですが、公開鍵から秘密鍵を生成することはできません。 秘密鍵を安全に保管し、その名の通り**秘密**にしておくことが極めて重要です。 署名を出力するメッセージとトランザクションに署名するには秘密鍵が必要です。 他者はそのメッセージの発信者を証明するための署名を取り出すことができます。 アプリケーション内では、JavaScriptライブラリを使用してネットワークにトランザクションを送信できます。 @@ -100,19 +101,19 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120 コントラクトアカウントも、 42文字の16進数のアドレスを持っています。 -例: +例： `0x06012c8cf97bead5deae237070f9587f8e7a266d` 通常、コントラクトアドレスは、コントラクトがイーサリアムブロックチェーンにデプロイされるときに与えられます。 アドレスは作成者のアドレスとそのアドレスから送信されたトランザクション数(nonce)から作られます。 -## バリデータ鍵 {#validators-keys} +## バリデータキー {#validators-keys} イーサリアムにはもう1種類の鍵があり、これはイーサリアムがプルーフ・オブ・ワークからプルーフ・オブ・ステークに基づくコンセンサスに切り替えた際に導入されたものです。 「BLS」鍵で、バリデータを識別するために使用されます。 これらの鍵は効率的に集約され、ネットワークがコンセンサスに至るまでに必要な帯域幅を削減できます。 この鍵集約がなければ、バリデータの最小ステーク額ははるかに高くなってしまいます。 -[バリデータ鍵の詳細](/developers/docs/consensus-mechanisms/pos/keys/) +[バリデータキーの詳細](/developers/docs/consensus-mechanisms/pos/keys/) -## ウォレットについて {#a-note-on-wallets} +## ウォレットに関する注記 {#a-note-on-wallets} アカウントはウォレットではありません。 ウォレットは、イーサリアムのアカウント（外部所有アカウントまたはコントラクトアカウント）とやり取りするためのインターフェースやアプリケーションです。 @@ -124,11 +125,11 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムアカウントについて理解する](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan +- [イーサリアムアカウントの理解](https://info.etherscan.com/understanding-ethereum-accounts/) - Etherscan -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/apis/backend/index.md b/public/content/translations/ja/developers/docs/apis/backend/index.md index 4183389e222..fd8a2ee761a 100644 --- a/public/content/translations/ja/developers/docs/apis/backend/index.md +++ b/public/content/translations/ja/developers/docs/apis/backend/index.md @@ -1,66 +1,71 @@ --- -title: バックエンドAPIライブラリ -description: アプリケーションからブロックチェーンへやりとりできるイーサリアムクライアントAPIの紹介。 +title: "バックエンドAPIライブラリ" +description: "アプリケーションからブロックチェーンへやりとりできるイーサリアムクライアントAPIの紹介。" lang: ja --- -ソフトウェアアプリケーションがイーサリアムブロックチェーンとやりとりを行うには (例: ブロックチェーンデータの読み込み、トランザクションの送信など) 、イーサリアムノードに接続する必要があります。 +ソフトウェアアプリケーションがイーサリアムブロックチェーンとやりとりを行うには(つまり、ブロックチェーンデータの読み込みやネットワークへのトランザクションの送信)、イーサリアムノードに接続する必要があります。 -この目的のために、すべてのイーサリアムクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)の仕様を実装しています。そのため、アプリケーションは統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットを使用できます。 +この目的のために、すべてのイーサリアムクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)仕様を実装しているため、アプリケーションが信頼して利用できる統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットが用意されています。 もし特定のプログラミング言語を使用してイーサリアムノードに接続したい場合には、独自のソリューションのほかに公開されている既存のライブライを使用することでより簡単に実装できます。 これらのライブラリにより、デベロッパーは直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを (内部的に) 初期化できるようになります。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[イーサリアムスタック](/developers/docs/ethereum-stack/) と [イーサリアムクライアント](/developers/docs/nodes-and-clients/)も内容を理解するのに役立ちます。 +[イーサリアムスタック](/developers/docs/ethereum-stack/)と[イーサリアムクライアント](/developers/docs/nodes-and-clients/)を理解しておくと、役立つでしょう。 ## ライブラリの利点 {#why-use-a-library} -これらのライブラリは、イーサリアムノードと直接やり取りする複雑な大部分を抽象化します。 また、ユーティリティ関数 (ETHをGweiに変換する関数など) も提供されています。そのため、デベロッパーは複雑なイーサリアムクライアントの作業に費やす時間を削減でき、自身のアプリケーションの独自機能の開発作業に専念できます。 +これらのライブラリにより、イーサリアムノードと直接やり取りする際の複雑さが抽象化されます。 また、ユーティリティ関数(例: ETHからGweiへの変換)も提供されているため、開発者はイーサリアムクライアントの複雑な処理に費やす時間を減らし、アプリケーション独自の機能に集中できます。 ## 利用可能なライブラリ {#available-libraries} ### インフラストラクチャとノードサービス {#infrastructure-and-node-services} -**Alchemy -** **_イーサリアム開発プラットフォーム_** +**Alchemy -** **_Ethereum開発プラットフォーム。_** - [alchemy.com](https://www.alchemy.com/) -- [ドキュメント](https://docs.alchemy.com/) +- [ドキュメント](https://www.alchemy.com/docs/) - [GitHub](https://github.com/alchemyplatform) - [Discord](https://discord.com/invite/alchemyplatform) -**All That Node -** **_ノード・アズ・ア・サービス_** +**All That Node -** **_サービスとしてのノード。_** - [All That Node.com](https://www.allthatnode.com/) - [ドキュメント](https://docs.allthatnode.com) - [Discord](https://discord.gg/GmcdVEUbJM) -**Blast by Bware Labs -** **_イーサリアムメインネットとテストネットのための分散型API_** +**Blast by Bware Labs -** **_イーサリアムメインネットおよびテストネット用の分散型API。_** - [blastapi.io](https://blastapi.io/) - [ドキュメント](https://docs.blastapi.io) -- [Discord](https://discord.gg/bwarelabs) +- [Discord](https://discord.gg/SaRqmRUjjQ) -**BlockPi -** **_より効率的かつ高速なRPCサービスを提供_** +**BlockPi -** **_より効率的で高速なRPCサービスを提供_** - [blockpi.io](https://blockpi.io/) - [ドキュメント](https://docs.blockpi.io/) - [GitHub](https://github.com/BlockPILabs) - [Discord](https://discord.com/invite/xTvGVrGVZv) -**Cloudflareのイーサリアムゲートウェイ** +**Cloudflareイーサリアムゲートウェイ。** - [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/) **Etherscan - ブロックエクスプローラーおよびトランザクションAPI** + - [ドキュメント](https://docs.etherscan.io/) -**GetBlock-** **_Web3開発用のBlockchain-as-a-service_** +**Blockscout - オープンソースブロックエクスプローラー** + +- [ドキュメント](https://docs.blockscout.com/) + +**GetBlock -** **_Web3開発向けのサービスとしてのブロックチェーン_** - [GetBlock.io](https://getblock.io/) -- [ドキュメント](https://getblock.io/docs/) +- [ドキュメント](https://docs.getblock.io/) -**Infura -** **_アズ・ア・サービス型のイーサリアムAPI_** +**Infura -** **_サービスとしてのイーサリアムAPI。_** - [infura.io](https://infura.io) - [ドキュメント](https://docs.infura.io/api) @@ -71,24 +76,24 @@ lang: ja - [noderpc.xyz](https://www.noderpc.xyz/) - [ドキュメント](https://docs.noderpc.xyz/node-rpc) -**NOWNodes - _フルノードとブロックエクスプローラー_** +**NOWNodes - _フルノードとブロックエクスプローラー。_** - [NOWNodes.io](https://nownodes.io/) -- [ドキュメント](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro) +- [ドキュメント](https://nownodes.gitbook.io/documentation) -**QuickNode -** **_アズ・ア・サービス型のブロックチェーンインフラストラクチャ_** +**QuickNode -** **_サービスとしてのブロックチェーンインフラストラクチャ。_** - [quicknode.com](https://quicknode.com) - [ドキュメント](https://www.quicknode.com/docs/welcome) - [Discord](https://discord.gg/quicknode) -**Rivet -** **_オープンソースソフトウェアを搭載した、アズ・ア・サービス型のイーサリアムとイーサリアムクラシックのAPI_** +**Rivet -** **_オープンソースソフトウェアを搭載した、サービスとしてのイーサリアムおよびイーサリアムクラシックAPI。_** - [rivet.cloud](https://rivet.cloud) - [ドキュメント](https://rivet.cloud/docs/) - [GitHub](https://github.com/openrelayxyz/ethercattle-deployment) -**Zmok -** **_JSON-RPC/WebSocket APIとしてのスピード重視のイーサリアムノード_** +**Zmok -** **_速度を重視した、JSON-RPC/WebSockets APIとしてのイーサリアムノード。_** - [zmok.io](https://zmok.io/) - [GitHub](https://github.com/zmok-io) @@ -97,32 +102,32 @@ lang: ja ### 開発ツール {#development-tools} -**ethers-kt -** **_EVMベースのブロックチェーン用の非同期、ハイパフォーマンスのKotlin/Java/Androidライブラリ_** +**ethers-kt -** **_EVMベースのブロックチェーン向けの、非同期で高性能なKotlin/Java/Androidライブラリ。_** - [GitHub](https://github.com/Kr1ptal/ethers-kt) -- [実例：](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [サンプル](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) - [Discord](https://discord.gg/rx35NzQGSb) -**Nethereum -** **_オープンソースのブロックチェーン用.NET統合ライブラリ_** +**Nethereum -** **_ブロックチェーン向けのオープンソース.NET統合ライブラリ。_** - [GitHub](https://github.com/Nethereum/Nethereum) - [ドキュメント](http://docs.nethereum.com/en/latest/) - [Discord](https://discord.com/invite/jQPrR58FxX) -**Python Tooling -** **_Pythonでイーサリアムとやり取りするための各種ライブラリ_** +**Python Tooling -** **_Pythonでイーサリアムと対話するための各種ライブラリ。_** -- [py.ethereum.org](https://python.ethereum.org/) +- [py.ethereum.org](https://snakecharmers.ethereum.org/) - [web3.py GitHub](https://github.com/ethereum/web3.py) -- [web3.pyチャット](https://gitter.im/ethereum/web3.py) +- [web3.py Chat](https://gitter.im/ethereum/web3.py) -**Tatum -** **_究極のブロックチェーン開発プラットフォーム_** +**Tatum -** **_究極のブロックチェーン開発プラットフォーム。_** - [Tatum](https://tatum.io/) - [GitHub](https://github.com/tatumio/) - [ドキュメント](https://docs.tatum.io/) - [Discord](https://discord.gg/EDmW3kjTC9) -**web3j -** **_イーサリアム用のJava/Android/Kotlin/Scalaの統合ライブラリ_** +**web3j -** **_イーサリアム向けのJava/Android/Kotlin/Scala統合ライブラリ。_** - [GitHub](https://github.com/web3j/web3j) - [ドキュメント](https://docs.web3j.io/) @@ -130,34 +135,34 @@ lang: ja ### ブロックチェーンサービス {#blockchain-services} -**BlockCypher -** **_イーサリアム Web API_** +**BlockCypher -** **_イーサリアムWeb API。_** - [blockcypher.com](https://www.blockcypher.com/) - [ドキュメント](https://www.blockcypher.com/dev/ethereum/) -**Chainbase -** **_イーサリアム向けのオールインワンWeb3データインフラストラクチャ_** +**Chainbase -** **_イーサリアム向けのオールインワンWeb3データインフラストラクチャ。_** - [chainbase.com](https://chainbase.com/) - [ドキュメント](https://docs.chainbase.com/) - [Discord](https://discord.gg/Wx6qpqz4AF) -**Chainstack -** **_柔軟性の高い、専用のアズ・ア・サービス型イーサリアムノード_** +**Chainstack -** **_柔軟で専用の、サービスとしてのイーサリアムノード。_** - [chainstack.com](https://chainstack.com) -- [ドキュメンテーション](https://docs.chainbase.com/docs) +- [ドキュメント](https://docs.chainstack.com/) - [イーサリアムAPIリファレンス](https://docs.chainstack.com/reference/ethereum-getting-started) -**Coinbase Cloud Node -** **_ブロックチェーンインフラストラクチャAPI_** +**Coinbase Cloud Node -** **_ブロックチェーンインフラストラクチャAPI。_** -- [Coinbase Cloud Node](https://www.coinbase.com/cloud) -- [ドキュメンテーション](https://docs.cloud.coinbase.com/) +- [Coinbase Cloud Node](https://www.coinbase.com/developer-platform) +- [ドキュメント](https://docs.cdp.coinbase.com/) -**Figment社が提供するDataHub -** **_イーサリアムプロトコル(メインネットとテストネット)を使用したWeb3 APIサービス_** +**DataHub by Figment -** **_イーサリアムメインネットおよびテストネット対応のWeb3 APIサービス。_** - [DataHub](https://www.figment.io/) - [ドキュメント](https://docs.figment.io/) -**Moralis -** **_エンタープライズグレードのEVM APIプロバイダ_** +**Moralis -** **_エンタープライズグレードのEVM APIプロバイダー。_** - [moralis.io](https://moralis.io) - [ドキュメント](https://docs.moralis.io/) @@ -165,43 +170,42 @@ lang: ja - [Discord](https://moralis.io/joindiscord/) - [フォーラム](https://forum.moralis.io/) -**NFTPort -** **_イーサリアムデータとミントAPI_** +**NFTPort -** **_イーサリアムのデータおよびミントAPI。_** - [nftport.xyz](https://www.nftport.xyz/) - [ドキュメント](https://docs.nftport.xyz/) - [GitHub](https://github.com/nftport/) - [Discord](https://discord.com/invite/K8nNrEgqhE) -**Tokenview -** **_ジェネラルなマルチクリプトブロックチェーンAPIプラットフォーム_** +**Tokenview -** **_汎用マルチクリプト・ブロックチェーンAPIプラットフォーム。_** - [services.tokenview.io](https://services.tokenview.io/) - [ドキュメント](https://services.tokenview.io/docs?type=api) - [GitHub](https://github.com/Tokenview) -**Watchdata -** **_イーサリアムブロックチェーンへのシンプルで信頼性の高いAPIアクセス_** +**Watchdata -** **_イーサリアムブロックチェーンへの、シンプルで信頼性の高いAPIアクセスを提供。_** - [Watchdata](https://watchdata.io/) - [ドキュメント](https://docs.watchdata.io/) - [Discord](https://discord.com/invite/TZRJbZ6bdn) -**Covalent -** **_200以上のチェーンで使えるリッチなブロックチェーンAPI_** +**Covalent -** **_200以上のチェーンに対応した、豊富なブロックチェーンAPI。_** - [covalenthq.com](https://www.covalenthq.com/) - [ドキュメント](https://www.covalenthq.com/docs/api/) - [GitHub](https://github.com/covalenthq) - [Discord](https://www.covalenthq.com/discord/) +## 参考リンク {#further-reading} -## 参考文献 {#further-reading} - -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} -- [ ノードとクライアント](/developers/docs/nodes-and-clients/) +- [ノードとクライアント](/developers/docs/nodes-and-clients/) - [開発フレームワーク](/developers/docs/frameworks/) ## 関連チュートリアル {#related-tutorials} -- [Javascriptでイーサリアムブロックチェーンを使用するためのWeb3jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップするための手順。_ -- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使って、JavaScriptからスマートコントラクトを呼び出す方法を確認する。_ +- [JavaScriptでイーサリアムブロックチェーンを使用するためのWeb3.jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップする手順。_ +- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使用して、JavaScriptからコントラクト関数を呼び出す方法を説明します。_ diff --git a/public/content/translations/ja/developers/docs/apis/javascript/index.md b/public/content/translations/ja/developers/docs/apis/javascript/index.md index 5c282bdc3db..e767afdc115 100644 --- a/public/content/translations/ja/developers/docs/apis/javascript/index.md +++ b/public/content/translations/ja/developers/docs/apis/javascript/index.md @@ -1,41 +1,43 @@ --- -title: JavaScript APIライブラリ -description: アプリケーションからブロックチェーンへやり取りできるJavaScriptクライアントライブラリの紹介。 +title: "JavaScript APIライブラリ" +description: "アプリケーションからブロックチェーンへやり取りできるJavaScriptクライアントライブラリの紹介。" lang: ja --- -Webアプリはイーサリアムブロックチェーンとやりとりを行うために(例えば、ブロックチェーンデータの読み込みやトランザクションの送信など) 、イーサリアムノードに接続する必要があります。 +ウェブアプリがEthereumブロックチェーンと対話する（すなわち、ブロックチェーンデータの読み取りやネットワークへのトランザクション送信）には、Ethereumノードに接続する必要があります。 -この目的のために、すべてのイーサリアムクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)の仕様を実装しています。そのため、アプリケーションは統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットを使用できます。 +この目的のために、すべてのEthereumクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)仕様を実装しており、アプリケーションが利用できる統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットが用意されています。 JavaScriptでイーサリアムノードに接続する場合、通常のJavaScriptを使用することは可能です。しかし、エコシステム内には、作業をより簡単にするいくつかの便利なライブラリがあります。 これらのライブラリにより、デベロッパーは直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを (内部的に) 初期化できるようになります。 -[マージ](/roadmap/merge/)以降は、ノードの実行には、実行クライアントとコンセンサスクライアントという2つのつながったイーサリアムソフトウェアが必要になることに注意してください。 必ず、ノードに実行クライアントとコンセンサスクライアントの両方が含まれるようにしてください。 ノードがローカルマシン上にない(ノードがAWSインスタンス上で動作しているなど)場合は、適宜、チュートリアルのIPアドレスをアップデートしてください。 詳細については、[ノードの実行](/developers/docs/nodes-and-clients/run-a-node/)ページをご覧ください。 +[マージ](/roadmap/merge/)以降は、ノードの実行には、実行クライアントとコンセンサスクライアントという2つの接続されたEthereumソフトウェアが必要になることに注意してください。 必ず、ノードに実行クライアントとコンセンサスクライアントの両方が含まれるようにしてください。 ご使用のノードがローカルマシン上にない場合（例：ノードがAWSインスタンス上で実行されている）、チュートリアルのIPアドレスを適宜更新してください。 詳細については、[ノードの実行](/developers/docs/nodes-and-clients/run-a-node/)に関するページをご覧ください。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -JavaScriptを理解している必要があります。また、[イーサリアムスタック](/developers/docs/ethereum-stack/)と[イーサリアムクライアント](/developers/docs/nodes-and-clients/)についても理解していることが推奨されます。 +JavaScriptを理解することに加えて、[Ethereumスタック](/developers/docs/ethereum-stack/)と[Ethereumクライアント](/developers/docs/nodes-and-clients/)を理解しておくと役立つでしょう。 ## ライブラリの利点 {#why-use-a-library} -これらのライブラリにより、イーサリアムノードと直接やり取りする際の複雑さが抽象化されます。 また、ユーティリティ関数 (ETHをGweiに変換する関数など) も提供されています。そのため、デベロッパーは複雑なイーサリアムクライアントの作業に費やす時間を削減でき、自身のアプリケーションの独自機能の開発作業に専念できます。 +これらのライブラリにより、イーサリアムノードと直接やり取りする際の複雑さが抽象化されます。 また、ユーティリティ関数(例: ETHからGweiへの変換)も提供されているため、開発者はイーサリアムクライアントの複雑な処理に費やす時間を減らし、アプリケーション独自の機能に集中できます。 ## ライブラリの機能 {#library-features} -### イーサリアムノードに接続 {#connect-to-ethereum-nodes} +### Ethereumノードへの接続 {#connect-to-ethereum-nodes} -providersライブラリを使用することで、JSON-RPC、INFURA、Etherscan、AlchemyまたはMetaMaskであっても、イーサリアムに接続してデータを読み取ることができます。 +providersライブラリを使用することで、JSON-RPC、INFURA、Etherscan、AlchemyまたはMetaMaskに関係なく、イーサリアムに接続してデータを読み取ることができます。 + +> **警告:** Web3.jsは2025年3月4日にアーカイブされました。 [発表を読む](https://blog.chainsafe.io/web3-js-sunset/)。 新しいプロジェクトでは、[ethers.js](https://ethers.org)や[viem](https://viem.sh)のような代替ライブラリの使用を検討してください。 **Ethers.jsを使った例** ```js -// A BrowserProvider wraps a standard Web3 provider, which is -// what MetaMask injects as window.ethereum into each page +// BrowserProviderは標準のWeb3プロバイダをラップしたもので、 +// MetaMaskが各ページにwindow.ethereumとしてインジェクトするものです const provider = new ethers.BrowserProvider(window.ethereum) -// The MetaMask plugin also allows signing transactions to -// send ether and pay to change state within the blockchain. -// For this, we need the account signer... +// MetaMaskプラグインは、トランザクションに署名して +// イーサを送信し、ブロックチェーン内の状態を変更するための支払いを行うこともできます。 +// そのためには、アカウントの署名者が必要です... const signer = provider.getSigner() ``` @@ -68,41 +70,41 @@ var web3 = new Web3( - ガスの推定値 - スマートコントラクトのイベント - ネットワークID -- その他 +- 等々。 -### ウォレットの機能 {#wallet-functionality} +### ウォレット機能 {#wallet-functionality} これらのライブラリは、ウォレットの作成、キーの管理、トランザクションへ署名を行います。 Ethers.jsを使った例 ```js -// Create a wallet instance from a mnemonic... +// ニーモニックからウォレットインスタンスを作成... mnemonic = "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol" walletMnemonic = Wallet.fromPhrase(mnemonic) -// ...or from a private key +// ...または秘密鍵から walletPrivateKey = new Wallet(walletMnemonic.privateKey) walletMnemonic.address === walletPrivateKey.address // true -// The address as a Promise per the Signer API +// Signer APIごとのPromiseとしてのアドレス walletMnemonic.getAddress() // { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' } -// A Wallet address is also available synchronously +// ウォレットアドレスは同期的に利用することもできます walletMnemonic.address // '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' -// The internal cryptographic components +// 内部の暗号コンポーネント walletMnemonic.privateKey // '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db' walletMnemonic.publicKey // '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64' -// The wallet mnemonic +// ウォレットのニーモニック walletMnemonic.mnemonic // { // locale: 'en', @@ -110,12 +112,12 @@ walletMnemonic.mnemonic // phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol' // } -// Note: A wallet created with a private key does not -// have a mnemonic (the derivation prevents it) +// 注: 秘密鍵で作成されたウォレットには +// ニーモニックがありません (派生によりこれが妨げられるため) walletPrivateKey.mnemonic // null -// Signing a message +// メッセージへの署名 walletMnemonic.signMessage("Hello World") // { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' } @@ -124,34 +126,34 @@ tx = { value: utils.parseEther("1.0"), } -// Signing a transaction +// トランザクションへの署名 walletMnemonic.signTransaction(tx) // { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' } -// The connect method returns a new instance of the -// Wallet connected to a provider +// connectメソッドは、プロバイダに接続された +// ウォレットの新しいインスタンスを返します wallet = walletMnemonic.connect(provider) -// Querying the network +// ネットワークへのクエリ wallet.getBalance() // { Promise: { BigNumber: "42" } } wallet.getTransactionCount() // { Promise: 0 } -// Sending ether +// イーサの送信 wallet.sendTransaction(tx) ``` -[全ドキュメントを読む](https://docs.ethers.io/v5/api/signer/#Wallet) +[完全なドキュメントを読む](https://docs.ethers.io/v5/api/signer/#Wallet) セットアップ後、以下が可能になります。 - アカウントの作成 - トランザクションの送信 - トランザクションへの署名 -- 等々... +- 等々。 -### スマートコントラクト関数とのやり取り {#interact-with-smart-contract-functions} +### スマートコントラクト関数との対話 {#interact-with-smart-contract-functions} Javascriptクライアントライブラリを使用すると、コンパイルされたコントラクトのアプリケーションバイナリインタフェース (ABI) を読み取ることによって、アプリからスマートコントラクト関数を呼び出せるようになります。 @@ -164,7 +166,7 @@ contract Test { uint a; address d = 0x12345678901234567890123456789012; - function Test(uint testInt) { a = testInt;} + constructor(uint testInt) { a = testInt;} event Event(uint indexed b, bytes32 c); @@ -211,13 +213,13 @@ contract Test { - スマートコントラクトにトランザクションを送信し、メソッドを実行 - EVMでメソッド実行時にかかるガス代を見積もるためにコール - コントラクトのデプロイ -- 等々... +- その他 ### ユーティリティ関数 {#utility-functions} ユーティリティ関数は、イーサリアムでの構築を少し簡単にする便利なショートカットです。 -ETHの値は、デフォルトでweiに設定されています。 1 ETHは、1,000,000,000,000,000,000,000,000,000,000,000,000 wei です。つまり、非常に巨大な数値を扱っているということです。 Etherは`web3.utils.toWei`によって、weiに変換されます。 +ETHの値は、デフォルトでweiに設定されています。 1 ETHは、1,000,000,000,000,000,000,000,000,000,000,000,000 wei です。つまり、非常に巨大な数値を扱っているということです。 `web3.utils.toWei`は、etherをWeiに変換します。 Ethers.jsで記述した場合は次のようになります: @@ -232,59 +234,56 @@ ethers.utils.formatEther(balance) // '2.337132817842795605' ``` -- [Web3jsのユーティリティ関数](https://docs.web3js.org/api/web3-utils) -- [Ethersのユーティリティ関数](https://docs.ethers.io/v5/api/utils/) +- [Web3jsユーティリティ関数](https://docs.web3js.org/api/web3-utils) +- [Ethersユーティリティ関数](https://docs.ethers.org/v6/api/utils/) ## 利用可能なライブラリ {#available-libraries} -**Web3.js -** **_イーサリアムのJavaScript API_** +**Web3.js -** **_Ethereum JavaScript API_** -- [ドキュメント](https://docs.web3js.org/) -- [GitHub](https://github.com/ethereum/web3.js/) +- [ドキュメンテーション](https://docs.web3js.org) +- [GitHub](https://github.com/ethereum/web3.js) -**Ethers.js -** **_JavaScriptとTypeScriptでの完全なイーサリアムウォレットの実装とユーティリティ_** +**Ethers.js -** **_JavaScriptとTypeScriptにおける完全なEthereumウォレットの実装とユーティリティ。_** -- [ドキュメント](https://docs.ethers.io/) -- [GitHub](https://github.com/ethers-io/ethers.js/) +- [Ethers.jsホーム](https://ethers.org/) +- [ドキュメンテーション](https://docs.ethers.io) +- [GitHub](https://github.com/ethers-io/ethers.js) -**The Graph -** **_イーサリアムとIPFSのデータをインデックス化し、GraphQLを使用してクエリを実行するためのプロトコル_** +**The Graph -** **_EthereumとIPFSのデータをインデックス化し、GraphQLを使用してクエリを実行するためのプロトコル。_** -- [The Graph](https://thegraph.com/) -- [Graph Explorer](https://thegraph.com/explorer/) -- [ドキュメント](https://thegraph.com/docs/) -- [GitHub](https://github.com/graphprotocol/) +- [The Graph](https://thegraph.com) +- [Graph Explorer](https://thegraph.com/explorer) +- [ドキュメンテーション](https://thegraph.com/docs) +- [GitHub](https://github.com/graphprotocol) - [Discord](https://thegraph.com/discord) -**light.js -** **_ライトクライアント向けに最適化された高位のリアクティブJSライブラリ_** - -- [GitHub](https://github.com/openethereum/js-libs/tree/master/packages/light.js) +**Alchemy SDK -** **_強化されたAPIを備えたEthers.jsのラッパー。_** -**Alchemyweb3 -** **_自動リトライと強化されたAPIを備えた、Web3.jsのラッパー_** +- [ドキュメンテーション](https://www.alchemy.com/docs) +- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js) -- [ドキュメント](https://docs.alchemy.com/reference/api-overview) -- [GitHub](https://github.com/alchemyplatform/alchemy-web3) +**viem -** **_EthereumのためのTypeScriptインターフェース。_** -**Alchemy NFT API -** **_所有権やメタデータ属性などのNFTデータを取得するためのAPI_** - -- [ドキュメント](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) -- [GitHub](https://github.com/alchemyplatform/alchemy-web3) +- [ドキュメンテーション](https://viem.sh) +- [GitHub](https://github.com/wagmi-dev/viem) -**viem -** **_イーサリアム用のTypeScriptインターフェース。_** +**Drift -** **_組み込みのキャッシュ、フック、テストモックを備えたTypeScriptメタライブラリ。_** -- [ドキュメント](https://viem.sh) -- [GitHub](https://github.com/wagmi-dev/viem) +- [ドキュメンテーション](https://ryangoree.github.io/drift/) +- [GitHub](https://github.com/ryangoree/drift/) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} -- [ ノードとクライアント](/developers/docs/nodes-and-clients/) +- [ノードとクライアント](/developers/docs/nodes-and-clients/) - [開発フレームワーク](/developers/docs/frameworks/) ## 関連チュートリアル {#related-tutorials} -- [Javascriptでイーサリアムブロックチェーンを使用するためのWeb3jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップするための手順。_ -- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使って、JavaScriptからスマートコントラクトを呼び出す方法を確認する。_ -- [Web3とAlchemyを使用してトランザクションを送信する](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– バックエンドからトランザクションを送信するための段階的ガイド。_ +- [JavaScriptでイーサリアムブロックチェーンを使用するためのWeb3.jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップする手順。_ +- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使用して、JavaScriptからコントラクト関数を呼び出す方法を説明します。_ +- [web3とAlchemyを使用したトランザクションの送信](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– バックエンドからトランザクションを送信するためのステップバイステップのウォークスルー。_ diff --git a/public/content/translations/ja/developers/docs/apis/json-rpc/index.md b/public/content/translations/ja/developers/docs/apis/json-rpc/index.md index 54c178cd6a7..a91f6d1a06b 100644 --- a/public/content/translations/ja/developers/docs/apis/json-rpc/index.md +++ b/public/content/translations/ja/developers/docs/apis/json-rpc/index.md @@ -1,40 +1,40 @@ --- title: JSON-RPC API -description: イーサリアムクライアント用のステートレスで軽量なリモートプロシージャコール(RPC)プロトコル。 +description: "イーサリアムクライアント用のステートレスで軽量なリモートプロシージャコール(RPC)プロトコル。" lang: ja --- ブロックチェーンデータの読み取りやネットワークへのトランザクションの送信など、ソフトウェアアプリケーションがイーサリアムブロックチェーンとやり取りするには、イーサリアムノードに接続する必要があります。 -そのため、すべての[イーサリアムクライアント](/developers/docs/nodes-and-clients/#execution-clients)は[JSON-RPC仕様](https://github.com/ethereum/execution-apis)を実装しており、ノードやクライアントの実装がどのようなものであっても、アプリケーションは統一されたメソッドのセットを使用できます。 +この目的のために、すべての[Ethereumクライアント](/developers/docs/nodes-and-clients/#execution-clients)は[JSON-RPC仕様](https://github.com/ethereum/execution-apis)を実装しているため、特定のノードやクライアントの実装に関係なく、アプリケーションが依拠できる統一されたメソッドセットが存在します。 [JSON-RPC](https://www.jsonrpc.org/specification)は、ステートレスで軽量なリモートプロシージャコール(RPC)プロトコルです。 いくつかのデータ構造とその処理に関するルールを定義しています。 トランスポートに依存しないため、同じプロセス内だけでなく、ソケット経由、HTTP経由など、さまざまなメッセージパッシング環境で利用できます。 データ形式としては、JSON(RFC 4627)を使用します。 -## クライアントの実装 {#client-implementations} +## クライアント実装 {#client-implementations} -各イーサリアムクライアントでは、JSON-RPC仕様を実装する際に異なるプログラミング言語を使用できます。 特定のプログラミング言語に関連する詳細については、各[クライアントのドキュメント](/developers/docs/nodes-and-clients/#execution-clients)を参照してください。 最新のAPIサポート情報についても、各クライアントのドキュメントを確認することをお勧めします。 +各イーサリアムクライアントでは、JSON-RPC仕様を実装する際に異なるプログラミング言語を使用できます。 特定のプログラミング言語に関する詳細については、個々の[クライアントのドキュメント](/developers/docs/nodes-and-clients/#execution-clients)を参照してください。 最新のAPIサポート情報についても、各クライアントのドキュメントを確認することをお勧めします。 ## 便利なライブラリ {#convenience-libraries} -JSON-RPC APIを介してイーサリアムクライアントと直接やり取りすることもできますが、dappデベロッパーの作業が多くの場合に簡単になるオプションもあります。 [JavaScript](/developers/docs/apis/javascript/#available-libraries)と[バックエンドAPI](/developers/docs/apis/backend/#available-libraries)には、JSON-RPC APIの上にラッパーを提供する多くのライブラリが存在します。 これらのライブラリを使用することで、デベロッパーは任意のプログラミング言語による直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを(内部的に)初期化できるようになります。 +JSON-RPC APIを介してイーサリアムクライアントと直接やり取りすることもできますが、dappデベロッパーの作業が多くの場合に簡単になるオプションもあります。 JSON-RPC API上にラッパーを提供する、多くの[JavaScript](/developers/docs/apis/javascript/#available-libraries)ライブラリや[バックエンドAPI](/developers/docs/apis/backend/#available-libraries)ライブラリが存在します。 これらのライブラリを使用することで、デベロッパーは任意のプログラミング言語による直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを(内部的に)初期化できるようになります。 ## コンセンサスクライアントAPI {#consensus-clients} -このページでは、主にイーサリアムの実行クライアントで使用されるJSON-RPC APIについて説明します。 しかし、コンセンサスクライアントには、ユーザーがノードについての情報のクエリを行えるRPC APIが用意されており、ビーコンブロック、ビーコンの状態、その他のコンセンサス関連の情報を直接ノードにリクエストできます。 このAPIについては 、[ビーコンAPIのウェブページ](https://ethereum.github.io/beacon-APIs/#/)に記載されています。 +このページでは、主にイーサリアムの実行クライアントで使用されるJSON-RPC APIについて説明します。 しかし、コンセンサスクライアントには、ユーザーがノードについての情報のクエリを行えるRPC APIが用意されており、ビーコンブロック、ビーコンの状態、その他のコンセンサス関連の情報を直接ノードにリクエストできます。 このAPIは[Beacon APIウェブページ](https://ethereum.github.io/beacon-APIs/#/)に文書化されています。 -内部APIは、ノード内のクライアント間通信にも使用されます。 つまり、コンセンサスクライアントと実行クライアントとの間のデータ交換を可能にします。 これは「Engine API」と呼ばれており、仕様は[Github](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)で参照できます。 +内部APIは、ノード内のクライアント間通信にも使用されます。 つまり、コンセンサスクライアントと実行クライアントとの間のデータ交換を可能にします。 これは「エンジンAPI」と呼ばれ、仕様は[GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)で入手できます。 -## 実行クライアントの仕様 {#spec} +## 実行クライアント仕様 {#spec} -[GitHub上でJSON-RPC APIの全仕様を確認しましょう](https://github.com/ethereum/execution-apis)。 このAPIは[Execution APIウェブページ](https://ethereum.github.io/execution-apis/api-documentation/)でドキュメント化されており、利用可能なすべてのメソッドを試すためのインスペクターも含まれています。 +[GitHubでJSON-RPC APIの全仕様を読む](https://github.com/ethereum/execution-apis)。 このAPIは、[Execution APIウェブページ](https://ethereum.github.io/execution-apis/)に文書化されており、利用可能なすべてのメソッドを試すためのインスペクターが含まれています。 -## 慣例 {#conventions} +## 規約 {#conventions} -### 16進数のエンコーディング {#hex-encoding} +### 16進数値エンコーディング {#hex-encoding} フォーマットされていないバイト配列とそのバイト数という、2つのキーデータ型がJSONで渡されます。 どちらも16進数エンコーディングで渡されますが、フォーマットの要件は異なります。 -#### バイト数 {#quantities-encoding} +#### 数量 {#quantities-encoding} バイト数(整数、数字)をエンコーディングする際は、接頭辞「0x」の16進数でエンコードするのが最も簡潔です。ただし、ゼロは「0x0」と表記する必要があります。 @@ -46,7 +46,7 @@ JSON-RPC APIを介してイーサリアムクライアントと直接やり取 - 誤り: 0x0400(先頭にゼロは入力できません) - 誤り: ff(接頭辞は0xでなければなりません) -### フォーマットされていないデータ {#unformatted-data-encoding} +### 未フォーマットデータ {#unformatted-data-encoding} フォーマットされていないデータ(バイト配列、アカウントアドレス、ハッシュ、バイトコード配列)をエンコードする場合、16進数としてエンコードし、接頭辞を「0x」とし、1バイトごとに2桁の16進数でエンコードします。 @@ -58,9 +58,9 @@ JSON-RPC APIを介してイーサリアムクライアントと直接やり取 - 誤り: 0xf0f0f(偶数でなければなりません) - 誤り: 004200(接頭辞が0xでなければなりません) -### デフォルトのブロックパラメータ {#default-block} +### ブロックパラメータ {#block-parameter} -以下のメソッドには、追加のデフォルトブロックパラメータがあります。 +以下のメソッドにはブロックパラメータがあります: - [eth_getBalance](#eth_getbalance) - [eth_getCode](#eth_getcode) @@ -68,26 +68,26 @@ JSON-RPC APIを介してイーサリアムクライアントと直接やり取 - [eth_getStorageAt](#eth_getstorageat) - [eth_call](#eth_call) -イーサリアムの状態に作用するリクエストを行う場合は、最後のデフォルトブロックパラメータによってブロックの高さが決定します。 +Ethereumの状態を照会するリクエストが行われる際、指定されたブロックパラメータがブロックの高さを決定します。 -デフォルトブロックパラメータには、以下のオプションがあります。 +ブロックパラメータには、以下のオプションが使用できます: - `HEX String` - 整数のブロック番号 -- `String "earliest"` - 最も古い/始まりのブロック -- `String "latest"` - 最も新しい提案されたブロック -- `String "safe"` - 最も新しい安全な先頭ブロック -- `String "finalized"` - 最も新しい確定済みブロック +- `String "earliest"` - 最古/ジェネシスブロック +- `String "latest"` - 最新の提案されたブロック +- `String "safe"` - 最新の安全なヘッドブロック +- `String "finalized"` - 最新のファイナライズされたブロック - `String "pending"` - 保留中の状態/トランザクション -## 使用例 +## 実例： -このページでは、コマンドラインツールである[curl](https://curl.se)を使用した、各JSON-RPC APIエンドポイントの使用方法の例を紹介します。 各エンドポイントの使用例は、[curlの使用例](#curl-examples)セクションで確認できます。 ページの下方には、Gethノード、JSON-RPC API、curlを使用したスマートコントラクトのコンパイルとデプロイの[エンドツーエンドの例](#usage-example)もあります。 +このページでは、コマンドラインツールである[curl](https://curl.se)を使用して、個々のJSON_RPC APIエンドポイントを使用する方法の例を示します。 これらの個々のエンドポイントの例は、以下の[Curlの例](#curl-examples)のセクションにあります。 さらにページの下部では、Gethノード、JSON_RPC API、curlを使用してスマートコントラクトをコンパイルし、デプロイするための[エンドツーエンドの例](#usage-example)も提供しています。 -## Curlの使用例 {#curl-examples} +## Curlの例 {#curl-examples} -以下に、[curl](https://curl.se)でイーサリアムノードへのリクエストを行うことによってJSON-RPC APIを使用する例をいくつか示します。 それぞれの例には、エンドポイントの説明、パラメータ、戻り値の型、使用方法の範例が含まれています。 +以下に、[curl](https://curl.se)を使用してEthereumノードにリクエストを行うことでJSON_RPC APIを使用する例を示します。 それぞれの例には、エンドポイントの説明、パラメータ、戻り値の型、使用方法の範例が含まれています。 -curlリクエストは、コンテンツタイプに関するエラーメッセージを返すことがあります。 この理由は、`--data`オプションによって、コンテンツタイプが`application/x-www-form-urlencoded`に設定されるためです。 これによってノードがエラーになる場合は、呼び出しの最初に、手動で`-H "Content-Type: application/json"`と記述してヘッダーを設定してください。 また、使用例には、curlで最後に指定する引数であるURL/IPとポートの組み合わせ(例: `127.0.0.1:8545`)が含まれていません 。 これらの追加データが含まれた完全なcurlリクエストは、次の形式になります。 +curlリクエストは、コンテンツタイプに関するエラーメッセージを返すことがあります。 これは、`--data`オプションがコンテントタイプを`application/x-www-form-urlencoded`に設定するためです。 もしノードがこれについて文句を言う場合は、呼び出しの最初に`-H "Content-Type: application/json"`を配置して、手動でヘッダーを設定してください。 また、この例には、curlに与える最後の引数でなければならないURL/IPとポートの組み合わせ(例: `127.0.0.1:8545`)は含まれていません。 これらの追加データが含まれた完全なcurlリクエストは、次の形式になります。 ```shell curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545 @@ -95,7 +95,7 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho ## ゴシップ、状態、履歴 {#gossip-state-history} -少数のコアJSON-RPCメソッドは、イーサリアムネットワークからのデータを必要とします。該当メソッドは、*ゴシップ、状態、履歴*という、3つの主要カテゴリーに明確に分類できます。 各メソッドは、セクションにあるリンクからジャンプするか、目次でメソッドの全リストを調べることで見つけられます。 +一部のコアJSON-RPCメソッドはEthereumネットワークからのデータを必要とし、_ゴシップ、状態、履歴_の3つの主要なカテゴリにきれいに分類されます。 各メソッドは、セクションにあるリンクからジャンプするか、目次でメソッドの全リストを調べることで見つけられます。 ### ゴシップメソッド {#gossip-methods} @@ -134,7 +134,7 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho ## JSON-RPC APIプレイグラウンド -APIメソッドの発見と試用に[プレイグラウンドツール](https://ethereum-json-rpc.com)が使えます。 プレイグラウンドツールでは、さまざまなノードプロバイダーによってサポートされているメソッドとネットワークも表示されます。 +[プレイグラウンドツール](https://ethereum-json-rpc.com)を使用して、APIメソッドを発見し、試すことができます。 プレイグラウンドツールでは、さまざまなノードプロバイダーによってサポートされているメソッドとネットワークも表示されます。 ## JSON-RPC APIメソッド {#json-rpc-methods} @@ -148,7 +148,7 @@ APIメソッドの発見と試用に[プレイグラウンドツール](https:// **戻り値** -`String` - 現在のクライアントのバージョン +`String` - 現在のクライアントバージョン **例** @@ -165,7 +165,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[], ### web3_sha3 {#web3_sha3} -標準のSHA3-256ではなく、指定されたデータのKeccak-256__を返します。 +指定されたデータのKeccak-256 (標準化されたSHA3-256では_ない_)を返します。 **パラメータ** @@ -177,14 +177,14 @@ params: ["0x68656c6c6f20776f726c64"] **戻り値** -`DATA` - 指定された文字列のSHA3結果 +`DATA` - 指定された文字列のSHA3結果。 **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}' -// Result +// 結果 { "id":64, "jsonrpc": "2.0", @@ -202,20 +202,20 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c **戻り値** -`String` - 現在のネットワークID +`String` - 現在のネットワークID。 現在のネットワークIDの全リストは、[chainlist.org](https://chainlist.org)で入手できます。 よく使われるネットワークIDは、以下の通りです。 -- `1`: イーサリアムメインネット +- `1`: Ethereumメインネット - `11155111`: Sepoliaテストネット -- `17000`: Hoodiテストネット +- `560048` : Hoodiテストネット **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}' -// Result +// 結果 { "id":67, "jsonrpc": "2.0", @@ -225,7 +225,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67 ### net_listening {#net_listening} -クライアントのネットワーク接続のリッスンがアクティブな場合に、`true`を返します。 +クライアントがネットワーク接続をアクティブにリッスンしている場合は`true`を返します。 **パラメータ** @@ -233,14 +233,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67 **戻り値** -`Boolean` - リッスンしている場合は`true`、その他の場合は`false` +`Boolean` - リッスンしている場合は`true`、それ以外は`false`。 **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}' -// Result +// 結果 { "id":67, "jsonrpc":"2.0", @@ -258,14 +258,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id": **戻り値** -`QUANTITY` - 接続されているピア数(整数)。 +`QUANTITY` - 接続されているピアの数の整数。 **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' -// Result +// 結果 { "id":74, "jsonrpc": "2.0", @@ -275,7 +275,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id": ### eth_protocolVersion {#eth_protocolversion} -現在のイーサリアムプロトコルのバージョンを返します。 このメソッドは、[Gethでは利用できないこと](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)に注意してください。 +現在のイーサリアムプロトコルのバージョンを返します。 このメソッドは[Gethでは利用できない](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)ことに注意してください。 **パラメータ** @@ -283,14 +283,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id": **戻り値** -`String` - 現在のイーサリアムプロトコルのバージョン +`String` - 現在のEthereumプロトコルバージョン **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}' -// Result +// 結果 { "id":67, "jsonrpc": "2.0", @@ -300,7 +300,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[] ### eth_syncing {#eth_syncing} -同期ステータスに関するデータを含むオブジェクトか、`false`を返します。 +同期ステータスに関するデータを含むオブジェクト、または`false`を返します。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** @@ -308,13 +312,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[] **戻り値** -クライアント実装によって、厳密にはリターンデータが異なります。 ノードが同期していない場合、すべてのクライアントは`False`を返します。また、すべてのクライアントは次のフィールドを返します。 +クライアント実装によって、厳密にはリターンデータが異なります。 すべてのクライアントは、ノードが同期していない場合に`False`を返し、すべてのクライアントが以下のフィールドを返します。 -`Object|Boolean` - 同期ステータスデータを含むオブジェクト、または同期していない場合は`FALSE` +`Object|Boolean`、同期ステータスデータを含むオブジェクト、または同期していない場合は`FALSE`: -- `startingBlock`: `QUANTITY` - インポートを開始したブロック(同期がブロックの先頭に達したときのみリセットされる) -- `currentBlock`: `QUANTITY` - 現在のブロックであり、eth_blockNumberと同一 -- `highestBlock`: `QUANTITY` - 最大ブロック高の推定値 +- `startingBlock`: `QUANTITY` - インポートが開始されたブロック(同期がヘッドに達した後にのみリセットされます) +- `currentBlock`: `QUANTITY` - 現在のブロック、eth_blockNumberと同じ +- `highestBlock`: `QUANTITY` - 推定される最も高いブロック ただし、クライアントによっては、追加のデータを提供する場合もあります。 例えば、Gethでは以下のデータを返します。 @@ -386,6 +390,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1} クライアントのコインベースアドレスを返します。 + + プレイグラウンドでエンドポイントを試す + + +> **注:** このメソッドは**v1.14.0**で廃止され、サポートされなくなりました。 このメソッドを使用しようとすると、「メソッドはサポートされていません」というエラーが発生します。 + **パラメータ** なし @@ -411,13 +421,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6 リプレイ保護されたトランザクションの署名に使われるチェーンIDを返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** なし **戻り値** -`chainId`、16進数の文字列で表された現在のチェーンIDの整数値。 +`chainId`、現在のチェーンIDの整数を表す16進値の文字列。 **例** @@ -434,7 +448,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67 ### eth_mining {#eth_mining} -クライアントの新規ブロックのマイニングがアクティブな場合に、`true`を返します。 プルーフ・オブ・ワークのネットワークに対してのみ `true`を返します。[マージ](/roadmap/merge/)以降、一部のクライアントでは使用できない場合があります。 +クライアントが新しいブロックをアクティブにマイニングしている場合は`true`を返します。 これはプルーフオブワークのネットワークに対してのみtrueを返し、[マージ](/roadmap/merge/)以降、一部のクライアントでは利用できない場合があります。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** @@ -442,7 +460,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67 **戻り値** -`Boolean` - クライアントがマイニングしている場合は`true`、その他の場合は`false` +`Boolean` - クライアントがマイニングしている場合は`true`、それ以外は`false`を返します。 **例** @@ -459,7 +477,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71} ### eth_hashrate {#eth_hashrate} -ノードがマイニングしている1秒あたりのハッシュの数を返します。 プルーフ・オブ・ワークのネットワークに対してのみ `true`を返します。[マージ](/roadmap/merge/)以降、一部のクライアントでは使用できない場合があります。 +ノードがマイニングしている1秒あたりのハッシュの数を返します。 これはプルーフオブワークのネットワークに対してのみtrueを返し、[マージ](/roadmap/merge/)以降、一部のクライアントでは利用できない場合があります。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** @@ -467,7 +489,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71} **戻り値** -`QUANTITY` - 1秒あたりのハッシュの数 +`QUANTITY` - 1秒あたりのハッシュ数。 **例** @@ -486,13 +508,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7 現在のガス価格の見積りをweiで返します。 例えば、Besuクライアントではデフォルトで、最新の100ブロックを検査し、ガスのユニット価格における中央値を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** なし **戻り値** -`QUANTITY` - 現在のガス価格(wei単位の整数) +`QUANTITY` - wei単位での現在のガス価格の整数。 **例** @@ -511,13 +537,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7 クライアントが所有するアドレスのリストを返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** なし **戻り値** -`DATA配列`、20バイト - クライアントが所有するアドレス +`Array of DATA`、20バイト - クライアントが所有するアドレス。 **例** @@ -534,7 +564,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1 ### eth_blockNumber {#eth_blocknumber} -最も新しいブロックの番号を返します。 +最新のブロック番号を返します。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** @@ -542,7 +576,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1 **戻り値** -`QUANTITY` - クライアントの現在のブロックの番号(整数) +`QUANTITY` - クライアントが現在いるブロック番号の整数。 **例** @@ -561,10 +595,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id 指定されたアドレスのアカウントの残高を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `DATA`、20バイト - 残高を確認するアドレス -2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください +1. `DATA`、20バイト - 残高を確認するアドレス。 +2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照 ```js params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] @@ -572,7 +610,7 @@ params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] **戻り値** -`QUANTITY` - 現在の残高(wei単位の整数) +`QUANTITY` - wei単位の現在の残高の整数。 **例** @@ -591,30 +629,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407 指定されたアドレスのストレージの位置の値を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `DATA`、20バイト - ストレージのアドレス -2. `QUANTITY` - ストレージの位置(整数) -3. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください +1. `DATA`、20バイト - ストレージのアドレス。 +2. `QUANTITY` - ストレージ内の位置の整数。 +3. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照 **戻り値** -`DATA` - このストレージの位置の値 +`DATA` - このストレージ位置の値。 -**例: ** 正確な位置計算は、取得するストレージによって変わります。 ここでは、アドレス`0x391694e7e0b0cce554cb130d723a9d27458f9298`で、`0x295a70b2de5e3953354a6a8344e616ed314d7251`にデプロイされているコントラクトについて考えます。 +**例** +正しい位置の計算は、取得するストレージによって異なります。 アドレス`0x391694e7e0b0cce554cb130d723a9d27458f9298`によって、`0x295a70b2de5e3953354a6a8344e616ed314d7251`にデプロイされた以下のコントラクトについて考えてみましょう。 ``` contract Storage { uint pos0; mapping(address => uint) pos1; - function Storage() { + constructor() { pos0 = 1234; pos1[msg.sender] = 5678; } } ``` -pos0の値の取得は簡単です。 +pos0の値の取得は簡単です: ```js curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 @@ -656,12 +699,16 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [ ### eth_getTransactionCount {#eth_gettransactioncount} -アドレスから_送信_されたトランザクションの数を返します。 +アドレスから_送信された_トランザクションの数を返します。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** -1. `DATA`、20バイト - アドレス -2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください +1. `DATA`、20バイト - アドレス。 +2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照 ```js params: [ @@ -672,7 +719,7 @@ params: [ **戻り値** -`QUANTITY` - このアドレスから送信されたトランザクションの数(整数) +`QUANTITY` - このアドレスから送信されたトランザクションの数の整数。 **例** @@ -691,9 +738,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params 指定されたブロックハッシュに一致するブロック内のトランザクションの数を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `DATA`、32バイト - ブロックハッシュ +1. `DATA`、32バイト - ブロックのハッシュ ```js params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"] @@ -701,7 +752,7 @@ params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"] **戻り値** -`QUANTITY` - このブロック内のトランザクションの数(整数) +`QUANTITY` - このブロック内のトランザクションの数の整数。 **例** @@ -720,9 +771,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa 指定されたブロック番号に一致するブロックのトランザクションの数を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください +1. `QUANTITY|TAG` - ブロック番号の整数、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`または`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。 ```js params: [ @@ -732,7 +787,7 @@ params: [ **戻り値** -`QUANTITY` - このブロック内のトランザクションの数(整数) +`QUANTITY` - このブロック内のトランザクションの数の整数。 **例** @@ -751,9 +806,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu 指定されたブロックハッシュに一致するブロックのアンクルの数を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `DATA`、32バイト - ブロックハッシュ +1. `DATA`、32バイト - ブロックのハッシュ ```js params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] @@ -761,7 +820,7 @@ params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] **戻り値** -`QUANTITY` - このブロック内のアンクルの数(整数) +`QUANTITY` - このブロック内のアンクルの数の整数。 **例** @@ -780,9 +839,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p 指定されたブロック番号に一致するブロック内のアンクルの数を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください +1. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照 ```js params: [ @@ -792,7 +855,7 @@ params: [ **戻り値** -`QUANTITY` - このブロック内のアンクルの数(整数) +`QUANTITY` - このブロック内のアンクルの数の整数。 **例** @@ -811,10 +874,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber", 指定されたアドレスのコードを返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** 1. `DATA`、20バイト - アドレス -2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください +2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照 ```js params: [ @@ -825,7 +892,7 @@ params: [ **戻り値** -`DATA` - 指定されたアドレスからのコード +`DATA` - 指定されたアドレスからのコード。 **例** @@ -842,9 +909,9 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA ### eth_sign {#eth_sign} -この署名メソッドは、イーサリアム固有の署名を次のように計算します。`sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`。 +署名メソッドは、`sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`で、Ethereum固有の署名を計算します。 -メッセージに接頭辞を追加することで、計算された署名がイーサリアム固有の署名として認識されるようになります。 これにより、悪意のあるdappによって任意のデータ(トランザクションなど)が署名され、被害者のなりすましに悪用される被害を防ぐことができます。 +メッセージに接頭辞を追加することで、計算された署名がイーサリアム固有の署名として認識されるようになります。 これにより、悪意のあるdappが任意のデータ(トランザクションなど)に署名し、その署名を利用して被害者になりすますといった不正使用を防ぎます。 注: 署名するアドレスのロックを解除する必要があります。 @@ -872,24 +939,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d37 ### eth_signTransaction {#eth_signtransaction} -[eth_sendRawTransaction](#eth_sendrawtransaction)を使用して、ネットワークに後から送信可能なトランザクションに署名します。 +[eth_sendRawTransaction](#eth_sendrawtransaction)を使用して、後でネットワークに送信できるトランザクションに署名します。 **パラメータ** 1. `Object` - トランザクションオブジェクト - `type`: -- `from`: `DATA`、20バイト - トランザクションの送信元アドレス -- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス -- `gas`: `QUANTITY` - (オプション、デフォルトは90000)トランザクションを実行するために提供されているガス(整数)で、 使用されなかったガスは返却される -- `gasPrice`: `QUANTITY` - (オプション、デフォルトは未確定)ガスごとに支払われるガス価格(wei単位の整数) -- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値(wei単位の整数) -- `data`: `DATA` - コンパイルされたコントラクトのコード。または呼び出されたメソッドの署名とエンコードされたパラメータのハッシュ -- `nonce`: `QUANTITY` - (オプション)ノンス(nonce)の整数で、 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる +- `from`: `DATA`、20バイト - トランザクションの送信元アドレス。 +- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス。 +- `gas`: `QUANTITY` - (オプション、デフォルト: 90000)トランザクションの実行に提供されるガスの整数。 使用されなかったガスは返却される +- `gasPrice`: `QUANTITY` - (オプション、デフォルト: 未確定)支払われるガスごとに使用されるgasPriceの整数(Wei単位)。 +- `value`: `QUANTITY` - (オプション)このトランザクションで送信される値の整数(Wei単位)。 +- `data`: `DATA` - コントラクトのコンパイル済みコード、または呼び出されたメソッド署名のハッシュとエンコードされたパラメータ。 +- `nonce`: `QUANTITY` - (オプション)ノンスの整数。 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる **戻り値** -`DATA`、特定のアカウントによって署名され、RLPエンコードされたトランザクションオブジェクト。 +`DATA`、指定されたアカウントによって署名された、RLPエンコードされたトランザクションオブジェクト。 **例** @@ -906,19 +973,19 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction"," ### eth_sendTransaction {#eth_sendtransaction} -データフィールドにコードが含まれている場合は、新しいメッセージコールトランザクションまたはコントラクト作成を行います。また、`from`で指定されたアカウントを使ってデータフィールドに署名します。 +データフィールドにコードが含まれている場合は、新しいメッセージコールトランザクションまたはコントラクト作成を行い、`from`で指定されたアカウントを使ってそれに署名します。 **パラメータ** 1. `Object` - トランザクションオブジェクト -- `from`: `DATA`、20バイト - トランザクションの送信元アドレス -- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス -- `gas`: `QUANTITY` - (オプション、デフォルトは90000)トランザクションを実行するために提供されているガス(整数)で、 使用されなかったガスは返却される -- `gasPrice`: `QUANTITY` - (オプション、デフォルトは未確定)ガスの支払いに適用されたガス価格(整数) -- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値(整数) -- `input`: `DATA` - コンパイルされたコントラクトのコード。または呼び出されたメソッドの署名とエンコードされたパラメータのハッシュ -- `nonce`: `QUANTITY` - (オプション)ノンス(nonce)の整数で、 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる +- `from`: `DATA`、20バイト - トランザクションの送信元アドレス。 +- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス。 +- `gas`: `QUANTITY` - (オプション、デフォルト: 90000)トランザクションの実行に提供されるガスの整数。 使用されなかったガスは返却される +- `gasPrice`: `QUANTITY` - (オプション、デフォルト: 未確定)ガスの支払いに適用されるgasPriceの整数。 +- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値の整数。 +- `input`: `DATA` - コントラクトのコンパイル済みコード、または呼び出されたメソッド署名のハッシュとエンコードされたパラメータ。 +- `nonce`: `QUANTITY` - (オプション)ノンスの整数。 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる ```js params: [ @@ -936,9 +1003,9 @@ params: [ **戻り値** -`DATA`、32バイト - トランザクションのハッシュ、またはトランザクションがまだ使用可能でない場合はゼロハッシュ +`DATA`、32バイト - トランザクションハッシュ、またはトランザクションがまだ利用できない場合はゼロハッシュ。 -コントラクトを作成した際、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。 +コントラクトを作成した場合、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。 **例** @@ -959,7 +1026,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{ **パラメータ** -1. `DATA` - 署名されたトランザクションのデータ +1. `DATA`、署名されたトランザクションデータ。 ```js params: [ @@ -969,9 +1036,9 @@ params: [ **戻り値** -`DATA`、32バイト - トランザクションのハッシュ、またはトランザクションがまだ使用可能でない場合はゼロハッシュ +`DATA`、32バイト - トランザクションハッシュ、またはトランザクションがまだ利用できない場合はゼロハッシュ。 -コントラクトを作成した際、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。 +コントラクトを作成した場合、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。 **例** @@ -988,24 +1055,28 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params" ### eth_call {#eth_call} -ブロックチェーン上にトランザクションを作成せずに、即座に新規メッセージ呼び出しを実行できます。 読み取り専用のスマートコントラクト関数を実行するために頻繁に使われます(例えば、ERC-20 コントラクトの`balanceOf`など)。 +ブロックチェーン上にトランザクションを作成せずに、新しいメッセージコールを即座に実行します。 ERC-20コントラクトの`balanceOf`など、読み取り専用のスマートコントラクト関数を実行するためによく使用されます。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** -1. `Object` - トランザクションの呼び出しオブジェクト +1. `Object` - トランザクションコールオブジェクト -- `from`: `DATA`、20バイト - (オプション)トランザクションの送信元アドレス -- `to`: `DATA`、20バイト - トランザクションの宛先アドレス -- `gas`: `QUANTITY` - (オプション)トランザクションを実行するために提供されているガス(整数) 。 eth_callはガスを消費しませんが、一部の実行ではこのパラメータが必要になる場合があります。 -- `gasPrice`: `QUANTITY` - (オプション)ガスの支払いに適用されるガス価格(整数) -- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値(整数) -- `input`: `DATA` - (オプション)メソッド署名とエンコードされたパラメータのハッシュ。 詳細については、[SolidityのドキュメントのイーサリアムコントラクトABI](https://docs.soliditylang.org/en/latest/abi-spec.html)を参照してください。 +- `from`: `DATA`、20バイト - (オプション)トランザクションの送信元アドレス。 +- `to`: `DATA`、20バイト - トランザクションの宛先アドレス。 +- `gas`: `QUANTITY` - (オプション)トランザクションの実行に提供されるガスの整数。 eth_callはガスを消費しませんが、一部の実行ではこのパラメータが必要になる場合があります。 +- `gasPrice`: `QUANTITY` - (オプション)支払われるガスごとに使用されるgasPriceの整数 +- `value`: `QUANTITY` - (オプション)このトランザクションで送信される値の整数 +- `input`: `DATA` - (オプション)メソッド署名とエンコードされたパラメータのハッシュ。 詳細については、[SolidityドキュメントのEthereum Contract ABI](https://docs.soliditylang.org/en/latest/abi-spec.html)を参照してください。 -2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください +2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照 **戻り値** -`DATA` - 実行されたコントラクトの戻り値 +`DATA` - 実行されたコントラクトの戻り値。 **例** @@ -1024,13 +1095,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}] トランザクションの完了に必要なガスの推定値を計算して返します。 このトランザクションはブロックチェーンに追加されません。 推定値は、EVMの仕組みやノードのパフォーマンスなどのさまざまな理由により、トランザクションによって実際に使われるガス量を大幅に上回る可能性があることに注意してください。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -[eth_call](#eth_call)パラメータを参照してください。ただし、すべてのプロパティはオプションです。 ガスリミットが指定されていない場合、Gethでは保留中のブロックのガスリミットが上限値として使用されます。 その結果、保留中のブロックのガスリミットよりガス量が多い場合には、返される推定値の量では、呼び出し/トランザクションを実行するには十分でないことがあります。 +[eth_call](#eth_call)パラメータを参照してください。ただし、すべてのプロパティはオプションです。 ガスリミットが指定されていない場合、Gethでは保留中のブロックのガスリミットが上限値として使用されます。 その結果、ガス量が保留中のブロックのガスリミットより高い場合、返された推定値ではコール/トランザクションの実行に十分でない可能性があります。 **戻り値** -`QUANTITY` - ガス使用量 +`QUANTITY` - 使用されたガス量。 **例** @@ -1049,10 +1124,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see ハッシュを使用して、ブロックに関する情報を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `DATA`、32バイト - ブロックのハッシュ -2. `Boolean` - `true`の場合は、完全なトランザクションオブジェクトを返します。 `false`の場合は、トランザクションのハッシュのみを返します +1. `DATA`、32バイト - ブロックのハッシュ。 +2. `Boolean` - `true`の場合は完全なトランザクションオブジェクトを返し、`false`の場合はトランザクションのハッシュのみを返します。 ```js params: [ @@ -1063,39 +1142,38 @@ params: [ **戻り値** -`Object` - ブロックオブジェクト、またはブロックが見つからなかった場合は`null` - -- `number`: `QUANTITY` - ブロック番号。 保留中のブロックの場合は`null` -- `hash`: `DATA`、32バイト - ブロックのハッシュ。 保留中のブロックの場合は`null` -- `parentHash`: `DATA`、32バイト - 親ブロックのハッシュ -- `nonce`: `DATA`、8バイト - 生成されたプルーフ・オブ・ワークのハッシュ。 保留中のブロックの場合は`null` -- `sha3Uncles`: `DATA`、32バイト - ブロックのアンクルデータのSHA3 -- `logsBloom`: `DATA`、256バイト - ブロックのログのブルームフィルタ。 保留中のブロックの場合は`null` -- `transactionsRoot`: `DATA`、32バイト - ブロックのトランザクションツリーのルート -- `stateRoot`: `DATA`、32バイト - ブロックの最終状態ツリーのルート -- `receiptsRoot`: `DATA`、32バイト - ブロックのレシートツリーのルート -- `miner`: `DATA`、20バイト - マイニング報酬が支払われる受益者のアドレス -- `difficulty`: `QUANTITY` - このブロックの難易度(整数) -- `totalDifficulty`: `QUANTITY` - このブロックまでのチェーンの合計難易度(整数) -- `extraData`: `DATA` - このブロックの「追加データ」フィールド -- `size`: `QUANTITY` - このブロックのサイズのバイト数(整数) -- `gasLimit`: `QUANTITY` - このブロックで許可されているガスの最大量 -- `gasUsed`: `QUANTITY` - このブロックのすべてのトランザクションで使用されたガスの合計量 -- `timestamp`: `QUANTITY` - ブロックが照合されたときのUNIXタイムスタンプ -- `transactions`: `Array` - 最後に指定したパラメータに応じて、トランザクションオブジェクトの配列、または32バイトのトランザクションハッシュ -- `uncles`: `Array` - アンクルハッシュの配列 +`Object` - ブロックオブジェクト、またはブロックが見つからなかった場合は`null`: + +- `number`: `QUANTITY` - ブロック番号。 保留中のブロックの場合はnull。 +- `hash`: `DATA`、32バイト - ブロックのハッシュ。 保留中のブロックの場合はnull。 +- `parentHash`: `DATA`、32バイト - 親ブロックのハッシュ。 +- `nonce`: `DATA`、8バイト - 生成されたプルーフオブワークのハッシュ。 保留中のブロックの場合は`null`、プルーフオブステークのブロックの場合は`0x0` (マージ以降) +- `sha3Uncles`: `DATA`、32バイト - ブロック内のアンクルデータのSHA3。 +- `logsBloom`: `DATA`、256バイト - ブロックのログのブルームフィルタ。 保留中のブロックの場合はnull。 +- `transactionsRoot`: `DATA`、32バイト - ブロックのトランザクションツリーのルート。 +- `stateRoot`: `DATA`、32バイト - ブロックの最終状態ツリーのルート。 +- `receiptsRoot`: `DATA`、32バイト - ブロックのレシートツリーのルート。 +- `miner`: `DATA`、20バイト - ブロック報酬が与えられた受益者のアドレス。 +- `difficulty`: `QUANTITY` - このブロックの難易度の整数。 +- `totalDifficulty`: `QUANTITY` - このブロックまでのチェーンの合計難易度の整数。 +- `extraData`: `DATA` - このブロックの「追加データ」フィールド。 +- `size`: `QUANTITY` - このブロックのサイズ(バイト単位)の整数。 +- `gasLimit`: `QUANTITY` - このブロックで許可されているガスの最大量。 +- `gasUsed`: `QUANTITY` - このブロック内のすべてのトランザクションによって使用されたガスの合計量。 +- `timestamp`: `QUANTITY` - ブロックが照合されたときのUNIXタイムスタンプ。 +- `transactions`: `Array` - 最後に与えられたパラメータに応じて、トランザクションオブジェクトの配列、または32バイトのトランザクションハッシュ。 +- `uncles`: `Array` - アンクルハッシュの配列。 **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}' -// Result -{ +// 結果 { -"jsonrpc": "2.0", -"id": 1, -"result": { + "jsonrpc": "2.0", + "id": 1, + "result": { "difficulty": "0x4ea3f27bc", "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32", "gasLimit": "0x1388", @@ -1118,7 +1196,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0 "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [ ] -} + } } ``` @@ -1126,10 +1204,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0 ブロック番号を使用して、ブロックに関する情報を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください -2. `Boolean` - `true`の場合は、完全なトランザクションオブジェクトを返します。 `false`の場合は、トランザクションのハッシュのみを返します +1. `QUANTITY|TAG` - ブロック番号の整数、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`または`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。 +2. `Boolean` - `true`の場合は完全なトランザクションオブジェクトを返し、`false`の場合はトランザクションのハッシュのみを返します。 ```js params: [ @@ -1138,7 +1220,8 @@ params: [ ] ``` -**戻り値**については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。 +**戻り値** +[eth_getBlockByHash](#eth_getblockbyhash)を参照 **例** @@ -1147,12 +1230,16 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}' ``` -結果については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。 +結果は[eth_getBlockByHash](#eth_getblockbyhash)を参照 ### eth_getTransactionByHash {#eth_gettransactionbyhash} トランザクションハッシュを使用して、リクエストされたトランザクションに関する情報を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** 1. `DATA`、32バイト - トランザクションのハッシュ @@ -1163,20 +1250,20 @@ params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] **戻り値** -`Object` - トランザクションオブジェクト、またはトランザクションが見つからなかった場合は`null` - -- `blockHash`: `DATA`、32バイト - このトランザクションが組み込まれていたブロックのハッシュ。 保留中の場合は`null` -- `blockNumber`: `QUANTITY` - このトランザクションが組み込まれていたブロックの番号 保留中の場合は`null` -- `from`: `DATA`、20バイト - 送信者のアドレス -- `gas`: `QUANTITY` - 送信者が提供するガス -- `gasPrice`: `QUANTITY` - 送信者が指定したガス価格(wei単位) -- `hash`: `DATA`、32バイト - トランザクションのハッシュ -- `input`: `DATA` - トランザクションと共に送信されるデータ -- `nonce`: `QUANTITY` - 送信者がこのトランザクションより前に送信したトランザクションの数 -- `to`: `DATA`、20バイト - 受信者のアドレス。 コントラクト作成時のトランザクションは`null` -- `transactionIndex`: `QUANTITY` - ブロック内のトランザクションのインデックスの位置(整数)。 保留中の場合は`null` -- `value`: `QUANTITY` - 送金された価値(wei単位) -- `v`: `QUANTITY` - ECDSAのリカバリID +`Object` - トランザクションオブジェクト、またはトランザクションが見つからなかった場合は`null`: + +- `blockHash`: `DATA`、32バイト - このトランザクションが含まれていたブロックのハッシュ。 保留中の場合はnull。 +- `blockNumber`: `QUANTITY` - このトランザクションが含まれていたブロック番号。 保留中の場合はnull。 +- `from`: `DATA`、20バイト - 送信者のアドレス。 +- `gas`: `QUANTITY` - 送信者によって提供されたガス。 +- `gasPrice`: `QUANTITY` - 送信者によって提供されたガス価格(Wei単位)。 +- `hash`: `DATA`、32バイト - トランザクションのハッシュ。 +- `input`: `DATA` - トランザクションと共に送信されるデータ。 +- `nonce`: `QUANTITY` - これより前に送信者によって行われたトランザクションの数。 +- `to`: `DATA`、20バイト - 受信者のアドレス。 コントラクト作成トランザクションの場合は`null`。 +- `transactionIndex`: `QUANTITY` - ブロック内でのトランザクションのインデックス位置の整数。 保留中の場合はnull。 +- `value`: `QUANTITY` - Wei単位で転送された値。 +- `v`: `QUANTITY` - ECDSAリカバリID - `r`: `QUANTITY` - ECDSA署名r - `s`: `QUANTITY` - ECDSA署名s @@ -1212,10 +1299,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param ブロックのハッシュとトランザクションのインデックスの位置を使用して、トランザクションに関する情報を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `DATA`、32バイト - ブロックのハッシュ -2. `QUANTITY` - トランザクションのインデックスの位置(整数) +1. `DATA`、32バイト - ブロックのハッシュ。 +2. `QUANTITY` - トランザクションのインデックス位置の整数。 ```js params: [ @@ -1224,7 +1315,8 @@ params: [ ] ``` -**戻り値**については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。 +**戻り値** +[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照 **例** @@ -1233,16 +1325,20 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` -結果については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。 +結果は[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照 ### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex} ブロック番号とトランザクションのインデックスの位置を使用して、トランザクションに関する情報を返します。 + + プレイグラウンドでエンドポイントを試す + + **パラメータ** -1. `QUANTITY|TAG` - ブロックの番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください -2. `QUANTITY` - トランザクションのインデックスの位置 +1. `QUANTITY|TAG` - ブロック番号、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`または`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。 +2. `QUANTITY` - トランザクションのインデックス位置。 ```js params: [ @@ -1251,22 +1347,23 @@ params: [ ] ``` -**戻り値**については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。 +**戻り値** +[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照 **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}' ``` -結果については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。 +結果は[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照 ### eth_getTransactionReceipt {#eth_gettransactionreceipt} トランザクションのハッシュを使用して、トランザクションのレシートを返します。 -**注** : 保留中のトランザクションでは、レシートは取得できません。 +**注** 保留中のトランザクションではレシートは利用できません。 **パラメータ** @@ -1276,26 +1373,27 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberA params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"] ``` -**戻り値** `Object` - トランザクションレシートのオブジェクト、またはレシートが見つからなかった場合は`null` +**戻り値** +`Object` - トランザクションレシートオブジェクト、またはレシートが見つからない場合は`null`: -- `transactionHash`: `DATA`、32バイト - トランザクションのハッシュ -- `transactionIndex`: `QUANTITY` - ブロック内のトランザクションのインデックスの位置(整数)。 -- `blockHash`: `DATA`、32バイト - このトランザクションが組み込まれていたブロックのハッシュ。 -- `blockNumber`: `QUANTITY` - このトランザクションが組み込まれていたブロックの番号 -- `from`: `DATA`、20バイト - 送信者のアドレス +- `transactionHash `: `DATA`、32バイト - トランザクションのハッシュ。 +- `transactionIndex`: `QUANTITY` - ブロック内でのトランザクションのインデックス位置の整数。 +- `blockHash`: `DATA`、32バイト - このトランザクションが含まれていたブロックのハッシュ。 +- `blockNumber`: `QUANTITY` - このトランザクションが含まれていたブロック番号。 +- `from`: `DATA`、20バイト - 送信者のアドレス。 - `to`: `DATA`、20バイト - 受信者のアドレス。 コントラクト作成時のトランザクションはnull -- `cumulativeGasUsed`: `QUANTITY` - ブロック内でこのトランザクションの実行時に使用されたガスの総量 -- `effectiveGasPrice` : `QUANTITY` - ガスユニットごとに支払われるベースフィーとチップの合計 -- `gasUsed`: `QUANTITY` - この特定のトランザクションのみで使用されたガスの量 -- `contractAddress`: `DATA`、20バイト - コントラクト作成のトランザクションの場合は、作成されたコントラクトのアドレス、その他の場合は`null` -- `logs`: `Array` - このトランザクションが生成したログオブジェクトの配列 -- `logsBloom`: `DATA`、256バイト - 関連ログを迅速に取得するためのライトクライアント用のブルームフィルター。 -- `type`: `QUANTITY` - トランザクションタイプの整数、`0x0`でレガシートランザクション、 `0x1`でアクセスリストタイプ、`0x2`で動的フィー。 +- `cumulativeGasUsed` : `QUANTITY ` - このトランザクションがブロック内で実行された際に使用されたガスの総量。 +- `effectiveGasPrice` : `QUANTITY` - ガスユニットごとに支払われるベースフィーとチップの合計。 +- `gasUsed `: `QUANTITY ` - この特定のトランザクションだけで使用されたガスの量。 +- `contractAddress `: `DATA`、20バイト - トランザクションがコントラクト作成だった場合に作成されたコントラクトアドレス、それ以外は`null`。 +- `logs`: `Array` - このトランザクションが生成したログオブジェクトの配列。 +- `logsBloom`: `DATA`、256バイト - ライトクライアントが関連ログを迅速に取得するためのブルームフィルター。 +- `type`: `QUANTITY` - トランザクションタイプの整数、`0x0`はレガシートランザクション、`0x1`はアクセスリストタイプ、`0x2`は動的フィー。 -また、以下のうち_いずれか_を返します。 +また、以下のいずれかを返します。 -- `root` : `DATA`、32バイト - トランザクション後の状態ルート(ビザンチウム以前) -- `status`: `QUANTITY` - `1`(成功)、または`0`(失敗) +- `root` : `DATA` トランザクション後の状態ルートの32バイト(ビザンチウム以前) +- `status`: `QUANTITY` `1` (成功) または `0` (失敗) のいずれか **例** @@ -1331,12 +1429,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para ### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex} -ハッシュとアンクルインデックスの位置を使用して、ブロックのアンクルに関する情報を返します。 +ハッシュとアンクルインデックス位置によって、ブロックのアンクルに関する情報を返します。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** -1. `DATA`、32バイト - ブロックのハッシュ -2. `QUANTITY` - アンクルのインデックスの位置 +1. `DATA`、32バイト - ブロックのハッシュ。 +2. `QUANTITY` - アンクルのインデックス位置。 ```js params: [ @@ -1345,7 +1447,8 @@ params: [ ] ``` -**戻り値**については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。 +**戻り値** +[eth_getBlockByHash](#eth_getblockbyhash)を参照 **例** @@ -1354,18 +1457,22 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` -結果については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。 +結果は[eth_getBlockByHash](#eth_getblockbyhash)を参照 -**注**: アンクルには、個々のトランザクションは含まれていません。 +**注**: アンクルには個別のトランザクションは含まれません。 ### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex} -ブロック番号とアンクルのインデックスの位置を使用して、ブロックのアンクルに関する情報を返します。 +ブロック番号とアンクルインデックス位置によって、ブロックのアンクルに関する情報を返します。 + + + プレイグラウンドでエンドポイントを試す + **パラメータ** -1. `QUANTITY|TAG` - ブロックの番号、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください。 -2. `QUANTITY` - アンクルのインデックスの位置 +1. `QUANTITY|TAG` - ブロック番号、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`、`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。 +2. `QUANTITY` - アンクルのインデックス位置。 ```js params: [ @@ -1374,9 +1481,10 @@ params: [ ] ``` -**戻り値**については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。 +**戻り値** +[eth_getBlockByHash](#eth_getblockbyhash)を参照 -**注**: アンクルには、個々のトランザクションは含まれていません。 +**注**: アンクルには個別のトランザクションは含まれません。 **例** @@ -1385,27 +1493,29 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}' ``` -結果については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。 +結果は[eth_getBlockByHash](#eth_getblockbyhash)を参照 ### eth_newFilter {#eth_newfilter} -(ログの)状態変更を通知するために、フィルターオプションに基づいてフィルターオブジェクトを作成します。 状態変更を確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。 +(ログの)状態変更を通知するために、フィルターオプションに基づいてフィルターオブジェクトを作成します。 +状態が変更されたかを確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。 -**トピックフィルターを指定する際の注:** トピックは順序に依存します。 トピック [A, B] を持つログのトランザクションは、下記のトピックフィルターによってマッチングされます。 +**トピックフィルター指定に関する注意:** +トピックは順序に依存します。 トピック [A, B] を持つログのトランザクションは、下記のトピックフィルターによってマッチングされます。 -- `[]` 「条件なし」 -- `[A]` 「最初の位置がA(その後の位置については条件なし) 」 -- `[null, B]`「最初の位置は条件なし、かつ2番目の位置がB(その後の位置については条件なし) 」 -- `[A, B]`「最初の位置がA、かつ2番目の位置がB(その後の位置については条件なし) 」 -- `[[A, B], [A, B]]`「最初の位置が(AまたはB)、かつ2番目の位置が(AまたはB)(その後の位置については条件なし) 」 +- `[]`「すべて」 +- `[A]`「最初の位置がA(それ以降はすべて)」 +- `[null, B]`「最初の位置はすべて、かつ2番目の位置がB(それ以降はすべて)」 +- `[A, B]`「最初の位置がA、かつ2番目の位置がB(それ以降はすべて)」 +- `[[A, B], [A, B]]`「最初の位置が(AまたはB)、かつ2番目の位置が(AまたはB)(それ以降はすべて)」 - **パラメータ** -1. `Object` - フィルターオプション +1. `Object` - フィルターオプション: -- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。 -- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。 -- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレス、またはアドレスのリスト -- `topics`: `Array of DATA`、- (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能 +- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。 +- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。 +- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレスまたはアドレスのリスト。 +- `topics`: `Array of DATA` - (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能 ```js params: [ @@ -1425,7 +1535,8 @@ params: [ ] ``` -**戻り値** `QUANTITY` - フィルターID +**戻り値** +`QUANTITY` - フィルターID。 **例** @@ -1442,11 +1553,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic ### eth_newBlockFilter {#eth_newblockfilter} -新しいブロックの到着を通知するために、ノードにフィルターを作成します。 状態変更を確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。 +新しいブロックの到着を通知するために、ノードにフィルターを作成します。 +状態が変更されたかを確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。 -**パラメータ** なし +**パラメータ** +なし -**戻り値** `QUANTITY` - フィルターID +**戻り値** +`QUANTITY` - フィルターID。 **例** @@ -1463,11 +1577,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[], ### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter} -新しい保留中のトランザクションの到着を通知するために、ノードにフィルターを作成します。 状態変更を確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。 +新しい保留中のトランザクションの到着を通知するために、ノードにフィルターを作成します。 +状態が変更されたかを確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。 -**パラメータ** なし +**パラメータ** +なし -**戻り値** `QUANTITY` - フィルターID +**戻り値** +`QUANTITY` - フィルターID。 **例** @@ -1484,11 +1601,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter" ### eth_uninstallFilter {#eth_uninstallfilter} -指定されたIDを使用して、フィルターをアンインストールします。 ウォッチが不要になったら、必ず呼び出す必要があります。 また、フィルターは一定期間、[eth_getFilterChanges](#eth_getfilterchanges)を使用してリクエストされなければタイムアウトします。 +指定されたIDを使用して、フィルターをアンインストールします。 ウォッチが不要になったら、必ず呼び出す必要があります。 +また、フィルターは一定期間[eth_getFilterChanges](#eth_getfilterchanges)でリクエストされないとタイムアウトします。 **パラメータ** -1. `QUANTITY` - フィルターID +1. `QUANTITY` - フィルターID。 ```js params: [ @@ -1496,7 +1614,8 @@ params: [ ] ``` -**戻り値** `Boolean` - フィルターのアンインストールに成功した場合は`true`、その他の場合は`false` +**戻り値** +`Boolean` - フィルターが正常にアンインストールされた場合は`true`、それ以外は`false`。 **例** @@ -1517,7 +1636,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":[" **パラメータ** -1. `QUANTITY` - フィルターID +1. `QUANTITY` - フィルターID。 ```js params: [ @@ -1525,26 +1644,30 @@ params: [ ] ``` -**戻り値** `Array` - ログオブジェクトの配列、または最後のポーリングから変化がない場合は空の配列 - -- `eth_newBlockFilter`で作成したフィルターでは、ブロックハッシュ(`DATA`、32バイト)が返されます(例: `["0x3454645634534..."]`) -- `eth_newPendingTransactionFilter`で作成したフィルターでは、トランザクションハッシュ(`DATA`、32バイト)が返されます(例: `["0x6345343454645..."]`) -- `eth_newFilter`で作成されたフィルターでは、ログは下記のパラメータを持つオブジェクトになります - - `removed`: `TAG` - チェーンの再編成によってログが削除された場合は`true`。 ログが有効な場合は`false` - - `logIndex`: `QUANTITY` - ブロック内のログインデックスの位置(整数)。 保留中のログの場合は`null` - - `transactionIndex`: `QUANTITY` - ログの作成元のトランザクションのインデックスの位置(整数) 。 保留中のログの場合は`null` - - `transactionHash`: `DATA`、32バイト - このログが作成されたトランザクションのハッシュ。 保留中のログの場合は`null` - - `blockHash`: `DATA`、32バイト - このログが存在したブロックのハッシュ。 保留中の場合は`null` 保留中のログの場合は`null` - - `blockNumber`: `QUANTITY` - このログが存在したブロックの番号。 保留中の場合は`null` 保留中のログの場合は`null` - - `address`: `DATA`、20バイト - このログの作成元のアドレス - - `data`: `DATA` - ゼロまたは32バイト以上のインデックス付けがされていないログの引数を含む - - `topics`: `Array of DATA` - 0から4つの32バイトのインデックス付けされたログの引数の`DATA`配列。 (_Solidity_の場合: 最初のトピックはイベント(例: `Deposit(address,bytes32,uint256)`)の署名の_ハッシュ_。ただし、`anonymous`指定子でイベントを宣言した場合を除く) +**戻り値** +`Array` - ログオブジェクトの配列、または最後のポーリング以降に変更がない場合は空の配列。 + +- `eth_newBlockFilter`で作成されたフィルターの場合、戻り値はブロックハッシュ(`DATA`、32バイト)です(例: `["0x3454645634534..."]`)。 + +- `eth_newPendingTransactionFilter`で作成されたフィルターの場合、戻り値はトランザクションハッシュ(`DATA`、32バイト)です(例: `["0x6345343454645..."]`)。 + +- `eth_newFilter`で作成されたフィルターの場合、ログは以下のパラメータを持つオブジェクトです: + - `removed`: `TAG` - チェーンの再編成によりログが削除された場合は`true`。 有効なログの場合は`false`。 + - `logIndex`: `QUANTITY` - ブロック内のログインデックス位置の整数。 保留中のログの場合はnull。 + - `transactionIndex`: `QUANTITY` - ログが作成されたトランザクションのインデックス位置の整数。 保留中のログの場合はnull。 + - `transactionHash`: `DATA`、32バイト - このログが作成されたトランザクションのハッシュ。 保留中のログの場合はnull。 + - `blockHash`: `DATA`、32バイト - このログが含まれていたブロックのハッシュ。 保留中の場合はnull。 保留中のログの場合はnull。 + - `blockNumber`: `QUANTITY` - このログが含まれていたブロック番号。 保留中の場合はnull。 保留中のログの場合はnull。 + - `address`: `DATA`、20バイト - このログの生成元のアドレス。 + - `data`: `DATA` - 可変長のインデックスなしログデータ。 (_Solidity_の場合: 0個以上の32バイトのインデックスなしログ引数。) + - `topics`: `Array of DATA` - 0から4つの32バイト`DATA`からなる、インデックス付けされたログ引数の配列。 (_Solidity_の場合: 最初のトピックは、イベントの署名の_ハッシュ_です(例: `Deposit(address,bytes32,uint256)`)。ただし、`anonymous`指定子でイベントを宣言した場合を除きます。) + - **例** ```js -// Request +// リクエスト curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}' -// Result +// 結果 { "id":1, "jsonrpc":"2.0", @@ -1569,7 +1692,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":[ **パラメータ** -1. `QUANTITY` - フィルターID +1. `QUANTITY` - フィルターID。 ```js params: [ @@ -1577,7 +1700,8 @@ params: [ ] ``` -**戻り値**については、 [eth_getFilterChanges](#eth_getfilterchanges)を参照してください。 +**戻り値** +[eth_getFilterChanges](#eth_getfilterchanges)を参照 **例** @@ -1586,7 +1710,7 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}' ``` -結果については、[eth_getFilterChanges](#eth_getfilterchanges)を参照してください。 +結果は[eth_getFilterChanges](#eth_getfilterchanges)を参照 ### eth_getLogs {#eth_getlogs} @@ -1594,13 +1718,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x **パラメータ** -1. `Object` - フィルターオプション +1. `Object` - フィルターオプション: -- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。 -- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。 -- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレス、またはアドレスのリスト -- `topics`: `Array of DATA`、- (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能 -- `blockhash`: `DATA`、32バイト - (オプション、**実装予定**) EIP-234が追加されたことにより、`blockHash`が新たなフィルターオプションになります。これは、返されるログを32バイトのハッシュ`blockHash`を持つ単一のブロックに制限します。 `blockHash`を使用することは、`fromBlock`と`toBlock`に`blockHash`のハッシュのブロック番号を指定することと同等です。 `blockHash`がフィルター条件にある場合、`fromBlock`と`toBlock`は使用できません。 +- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。 +- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。 +- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレスまたはアドレスのリスト。 +- `topics`: `Array of DATA` - (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能 +- `blockHash`: `DATA`、32バイト - (オプション、**将来**)EIP-234の追加により、`blockHash`は新しいフィルターオプションとなり、返されるログを32バイトハッシュ`blockHash`を持つ単一ブロックに制限します。 `blockHash`を使用することは、`fromBlock` = `toBlock` = ハッシュ`blockHash`を持つブロック番号と等価です。 フィルター条件に`blockHash`が存在する場合、`fromBlock`も`toBlock`も許可されません。 ```js params: [ @@ -1612,7 +1736,8 @@ params: [ ] ``` -**戻り値**については、 [eth_getFilterChanges](#eth_getfilterchanges)を参照してください。 +**戻り値** +[eth_getFilterChanges](#eth_getfilterchanges)を参照 **例** @@ -1621,15 +1746,15 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}' ``` -結果については、[eth_getFilterChanges](#eth_getfilterchanges)を参照してください。 +結果は[eth_getFilterChanges](#eth_getfilterchanges)を参照 ## 使用例 {#usage-example} -### JSON_RPCを使用してコントラクトをデプロイする {#deploying-contract} +### JSON_RPCを使用したコントラクトのデプロイ {#deploying-contract} -このセクションでは、RPCインターフェースのみを使用してコントラクトをデプロイする方法について、実例を交えて説明します。 コントラクトをデプロイする際には、複雑さを抽象化できる別の方法があります。例えば、RPCインターフェースを基盤としたライブラリ([web3.js](https://web3js.readthedocs.io/)、[web3.py](https://github.com/ethereum/web3.py)など)を使用できます。 通常、抽象化すると簡単に理解できるようになり、エラーも起こりにくくなります。それでも、内部の仕組みを知っておくことで、理解を深めることができます。 +このセクションでは、RPCインターフェースのみを使用してコントラクトをデプロイする方法について、実例を交えて説明します。 この複雑さが抽象化されている、コントラクトをデプロイするための代替ルートがあります。例えば、[web3.js](https://web3js.readthedocs.io/)や[web3.py](https://github.com/ethereum/web3.py)など、RPCインターフェース上に構築されたライブラリを使用する方法です。 通常、抽象化すると簡単に理解できるようになり、エラーも起こりにくくなります。それでも、内部の仕組みを知っておくことで、理解を深めることができます。 -以下は、JSON-RPCインターフェースを使用してイーサリアムノードにデプロイされる、`Multiply7`と呼ばれる簡単なスマートコントラクトです。 このチュートリアルは、読者がすでにGethノードを実行していることを前提としています。 ノードとクライアントの詳細については、[こちら](/developers/docs/nodes-and-clients/run-a-node)をご覧ください。 また、Gethクライアント以外のHTTP JSON-RPCを起動する方法については、それぞれの[クライアント](/developers/docs/nodes-and-clients/)のドキュメントを参照してください。 ほとんどのクライアントは、デフォルトでは`localhost:8545`で動作します。 +以下は、`Multiply7`という単純なスマートコントラクトで、JSON-RPCインターフェースを使用してEthereumノードにデプロイされます。 このチュートリアルは、読者がすでにGethノードを実行していることを前提としています。 ノードとクライアントに関する詳細情報は、[こちら](/developers/docs/nodes-and-clients/run-a-node)で入手できます。 Geth以外のクライアントでHTTP JSON-RPCを開始する方法については、個々の[クライアント](/developers/docs/nodes-and-clients/)のドキュメントを参照してください。 ほとんどのクライアントは、デフォルトで`localhost:8545`でサービスを提供します。 ```javascript contract Multiply7 { @@ -1641,18 +1766,18 @@ contract Multiply7 { } ``` -まず、HTTP RPCインターフェースが有効になっていることを確認します。 つまり、Gethの起動時に`--http`フラグを設定します。 この例では、プライベート開発チェーン上のGethノードを使用します。 このアプローチを使用する際には、本物のネットワーク上のEtherは必要ありません。 +まず、HTTP RPCインターフェースが有効になっていることを確認します。 これは、起動時にGethに`--http`フラグを供給することを意味します。 この例では、プライベート開発チェーン上のGethノードを使用します。 このアプローチを使用する際には、本物のネットワーク上のEtherは必要ありません。 ```bash geth --http --dev console 2>>geth.log ``` -これにより、HTTP RPCインターフェースが`http://localhost:8545`で開始します。 +これにより、HTTP RPCインターフェースが`http://localhost:8545`で開始されます。 -[curl](https://curl.se)を使用してCoinbaseアドレスと残高を取得することにより、インターフェースが実行されていることを確認できます。 例で示されているデータは、ローカルノードによって異なりますのでご注意ください。 これらのコマンドを試す場合は、2番目のcurlリクエストのrequestパラメータの値を、1番目のcurlリクエストから返されたresultパラメータに置き換えてください。 +[curl](https://curl.se)を使用して、コインベースアドレス(アカウントの配列から最初のアドレスを取得)と残高を取得することで、インターフェースが実行中であることを確認できます。 例で示されているデータは、ローカルノードによって異なりますのでご注意ください。 これらのコマンドを試す場合は、2番目のcurlリクエストのrequestパラメータの値を、1番目のcurlリクエストから返されたresultパラメータに置き換えてください。 ```bash -curl --data '{"jsonrpc":"2.0","method":"eth_coinbase", "id":1}' -H "Content-Type: application/json" localhost:8545 +curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545 {"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]} curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545 @@ -1666,9 +1791,9 @@ web3.fromWei("0x1639e49bba16280000", "ether") // "410" ``` -これで、プライベート開発チェーンにEtherが存在するようになったため、コントラクトをデプロイできるようになりました。 最初のステップは、Multiply7コントラクトをEVMに送信できるバイトコードにコンパイルすることです。 Solidityのコンパイラであるsolcをインストールするには、[Solidityドキュメント](https://docs.soliditylang.org/en/latest/installing-solidity.html)を参照してください ([この例で使用しているコンパイラのバージョン](https://github.com/ethereum/solidity/releases/tag/v0.4.20)に適合するように、古い`solc`リリースを使用することをお勧めします)。 +これで、プライベート開発チェーンにEtherが存在するようになったため、コントラクトをデプロイできるようになりました。 最初のステップは、Multiply7コントラクトをEVMに送信できるバイトコードにコンパイルすることです。 Solidityコンパイラであるsolcをインストールするには、[Solidityドキュメント](https://docs.soliditylang.org/en/latest/installing-solidity.html)に従ってください。 (この例で使用されているコンパイラのバージョンに合わせるために、古い`solc`リリース([v0.4.20](https://github.com/ethereum/solidity/releases/tag/v0.4.20)など)を使用することをお勧めします。) -次のステップでは、Multiply7コントラクトを、EVMに送信できるバイトコードにコンパイルします。 +次のステップは、Multiply7コントラクトを、EVMに送信できるバイトコードにコンパイルすることです。 ```bash echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin @@ -1678,7 +1803,7 @@ Binary: 6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029 ``` -これで、コードがコンパイルされました。次に、デプロイに必要なガスの量を特定する必要があります。 RPCインターフェースには、推定値を取得するための`eth_estimateGas`メソッドがあります。 +これで、コードがコンパイルされました。次に、デプロイに必要なガスの量を特定する必要があります。 RPCインターフェースには、推定値を提供する`eth_estimateGas`メソッドがあります。 ```bash curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545 @@ -1692,20 +1817,21 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from {"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"} ``` -トランザクションがノードによって受け入れられると、トランザクションのハッシュが返されます。 このハッシュはトランザクションの追跡に使用されます。 次のステップは、コントラクトがデプロイされているアドレスを特定することです。 実行された各トランザクションによって、レシートが作成されます。 このレシートには、トランザクションが含まれていたブロックや、EVMによって使用されたガスの量など、トランザクションに関するさまざまな情報が含まれています。 トランザクション でコントラクトが作成される場合は、コントラクトのアドレスも含まれています。 レシートは、`eth_getTransactionReceipt`RPCメソッドで取得できます。 +トランザクションがノードによって受け入れられると、トランザクションのハッシュが返されます。 このハッシュはトランザクションの追跡に使用されます。 次のステップは、コントラクトがデプロイされているアドレスを特定することです。 実行された各トランザクションによって、レシートが作成されます。 このレシートには、トランザクションが含まれていたブロックや、EVMによって使用されたガスの量など、トランザクションに関するさまざまな情報が含まれています。 トランザクション +でコントラクトが作成される場合は、コントラクトのアドレスも含まれています。 `eth_getTransactionReceipt`RPCメソッドでレシートを取得できます。 ```bash curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545 {"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}} ``` -これで、コントラクトが`0x4d03d617d700cf81935d7f797f4e2ae719648262`に作成されました。 レシートの代わりにnullが返された場合、それはトランザクションがまだブロックに含まれていないことを意味します。 少し待ってから、コンセンサスクライアントが正常に動作しているか確認し、再試行してください。 +コントラクトは`0x4d03d617d700cf81935d7f797f4e2ae719648262`に作成されました。 レシートの代わりにnullが返された場合、それはトランザクションがまだブロックに含まれていないことを意味します。 少し待ってから、コンセンサスクライアントが正常に動作しているか確認し、再試行してください。 -#### スマートコントラクトとのやりとり {#interacting-with-smart-contract} +#### スマートコントラクトとの対話 {#interacting-with-smart-contract} この例では、`eth_sendTransaction`を使用して、コントラクトの`multiply`メソッドにトランザクションを送信します。 -`eth_sendTransaction`にはいくつかの引数、具体的には`from`、`to`、`data`が必要です。 `from`は、アカウントの公開アドレスで、`to`はコントラクトアドレスです。 引数`data`には、どのメソッドがどの引数で呼び出されるのかが定義されたペイロードが含まれています。 ここで、[ABI(アプリケーション・バイナリー・インターフェース)](https://docs.soliditylang.org/en/latest/abi-spec.html)を使用します。 ABIは、EVMのためにデータの定義とエンコードの方法を明示したJSONファイルです。 +`eth_sendTransaction`には、`from`、`to`、`data`など、いくつかの引数が必要です。 `From`は私たちのアカウントの公開アドレスで、`to`はコントラクトアドレスです。 `data`引数には、どのメソッドをどの引数で呼び出すかを定義するペイロードが含まれています。 ここで[ABI (アプリケーションバイナリインターフェース)](https://docs.soliditylang.org/en/latest/abi-spec.html)が関係してきます。 ABIは、EVMのためにデータの定義とエンコードの方法を明示したJSONファイルです。 ペイロードのバイトによって、コントラクトのどのメソッドが呼び出されるかが定義されています。 これは、関数名とその引数の型を16進数でエンコードしたKeccakハッシュの最初の4バイトです。 multiply関数はuint256のエイリアスであるuintを受け取ります。 そのため、以下のようになります。 @@ -1716,11 +1842,11 @@ web3.sha3("multiply(uint256)").substring(0, 10) 次のステップでは、引数をエンコードします。 uint256は1つのみです。この例では6とします。 ABIには、uint256型のエンコード方法を指定するセクションがあります。 -`int: enc(X)`は、Xのビッグエンディアンの2の補数表現でのエンコーディングです。長さが32バイトの倍数になるように、Xが負の場合は0xffを使用して、正の場合は0>バイトを使用して左詰めされます。 +`int: enc(X)`は、Xのビッグエンディアン2の補数エンコーディングで、長さが32バイトの倍数になるように、負のXの場合は上位(左)側が0xffで、正のXの場合はゼロバイトでパディングされます。 -これにより、`00000000000000000000000000000000000000000000006`とエンコードされます。 +これは`0000000000000000000000000000000000000000000000000000000000000006`にエンコードされます。 -関数セレクターとエンコードされた引数を組み合わせると、データは `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`になります。 +関数セレクタとエンコードされた引数を組み合わせると、データは`0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`になります。 これを、以下のようにノードに送信します。 @@ -1753,7 +1879,7 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from } ``` -レシートには、ログが含まれています。 このログは、EVMによってトランザクションの実行時に生成され、レシートに含まれます。 `multiply`関数によって、`Print`イベントが入力の7倍で発生したことが示されています。 `Print`イベントの引数はuint256であるため、ABIルールに従ってデコードできます。これにより、期待される10進数である42が得られます。 このデータのほかに、トピックを使用することでどのイベントによってログが作成されたかを把握することもできます。 +レシートには、ログが含まれています。 このログは、EVMによってトランザクションの実行時に生成され、レシートに含まれます。 `multiply`関数は、`Print`イベントが入力の7倍で発生したことを示しています。 `Print`イベントの引数はuint256であったため、ABIルールに従ってデコードできます。これにより、期待される10進数である42が得られます。 このデータのほかに、トピックを使用することでどのイベントによってログが作成されたかを把握することもできます。 ```javascript web3.sha3("Print(uint256)") @@ -1764,8 +1890,8 @@ web3.sha3("Print(uint256)") ## 関連トピック {#related-topics} -- [JSON-RPCの仕様](http://www.jsonrpc.org/specification) -- [ ノードとクライアント](/developers/docs/nodes-and-clients/) -- [JavaScript APIs](/developers/docs/apis/javascript/) +- [JSON-RPC仕様](http://www.jsonrpc.org/specification) +- [ノードとクライアント](/developers/docs/nodes-and-clients/) +- [JavaScript API](/developers/docs/apis/javascript/) - [バックエンドAPI](/developers/docs/apis/backend/) - [実行クライアント](/developers/docs/nodes-and-clients/#execution-clients) diff --git a/public/content/translations/ja/developers/docs/blocks/index.md b/public/content/translations/ja/developers/docs/blocks/index.md index c0a1bfd96db..aacbf459e06 100644 --- a/public/content/translations/ja/developers/docs/blocks/index.md +++ b/public/content/translations/ja/developers/docs/blocks/index.md @@ -1,20 +1,21 @@ --- -title: ブロック -description: イーサリアムブロックチェーンの概要 - データ構造、データ構造の背景と構成 +title: "ブロック" +description: "イーサリアムブロックチェーンの概要 - データ構造、データ構造の背景と構成" lang: ja --- ブロックとは、チェーンの1つ前のハッシュとトランザクションのバッチのことです。 ハッシュはブロックデータから暗号的に生成されるため、チェーンのブロックはお互いに繋がっています。 前のブロックのハッシュを用いるため、どれかのブロックが改ざんされるとデータの整合性が取れなくなるため、ブロックチェーンを実行しているすべての人が改ざんに気づくことになります。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -この記事は初心者向けに記載していますが、 より理解を深めるために、まず[アカウント](/developers/docs/accounts/)、[トランザクション](/developers/docs/transactions/)そして[イーサリアムの導入](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 +この記事は初心者向けに記載していますが、 ただし、このページをより深く理解するために、最初に[アカウント](/developers/docs/accounts/)、[トランザクション](/developers/docs/transactions/)、そして[イーサリアムの紹介](/developers/docs/intro-to-ethereum/)をお読みになることをお勧めします。 ## ブロックを使用する背景 {#why-blocks} ブロックはすべてのイーサリアムネットワークへの参加者が同期された状態を維持し、トランザクションの正確な履歴に同意できるように、複数のトランザクションをブロックにバッチとして格納します。 これは、何十件(もしくは数百) ものトランザクションが一度にコミット、合意、同期されることを意味します。 -![状態の変更を引き起こすブロック内のトランザクションを示す図](./tx-block.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +![ブロック内のトランザクションが状態変化を引き起こす様子を示す図](./tx-block.png) +_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)を参考に作成_ コミットの間隔をあけ、すべてのネットワーク参加者がコンセンサスに至るまでの十分な時間を確保しています。たとえトランザクション要求が毎秒数十回発生したとしても、ブロックはイーサリアム上で12秒に1回生成され、コミットされます。 @@ -24,68 +25,68 @@ lang: ja ランダムに選ばれたバリデータがブロックをまとめると、そのブロックは残りの他のネットワークに伝播されます。すべてのノードはこのブロックをブロックチェーンの最後尾に追加します。そして、新しいバリデータが選ばれ、次のブロックを生成します。 このブロック生成とコミットメント/コンセンサスプロセスは、現在イーサリアム「プルーフ・オブ・ステーク (PoS) 」プロトコルによって定義されています。 -## プルーフ・オブ・ステーク(PoS)プロトコル {#proof-of-work-protocol} +## プルーフ・オブ・ステークのプロトコル {#proof-of-stake-protocol} プルーフ・オブ・ステークとは、以下のことを意味します。 - 検証を行うノードは、不正行為をしない担保として、デポジットコントラクトに32 ETHのステーキングが必要。 明らかに不誠実な行為を行うと、担保のステーキングの一部またはすべてが失うことになるため、ネットワークの保護を目的としている。 - すべてのスロット(12秒間隔)において、ランダムに1つのバリデータがブロックの提案者として選出される。 選ばれたバリデータが、トランザクションを1つにまとめ、実行し新たな「状態」を決定し、 この情報をブロックに格納し、他のバリデータに渡す。 -- 新しいブロックに関する情報を受け取った他のバリデータは、トランザクションを再実行し、グローバル状態への変更提案について同意することを確認する。 ブロックが有効であった場合、それを自分のデータベースに追加する。 +- 新しいブロックに関する情報を受け取った他のバリデータは、トランザクションを再実行し、グローバル状態への変更提案について同意することを確認します。 ブロックが有効であると判断した場合、それを自分のデータベースに追加します。 - バリデータが同一スロットで2つの競合するブロックの情報を受け取った場合は、フォーク・チョイス・アルゴリズムを使用して、最も多額のETHステーキングにより支持されている方を選択する。 -[プルーフ・オブ・ステーク(PoS)の詳細](/developers/docs/consensus-mechanisms/pos) +[プルーフ・オブ・ステークの詳細](/developers/docs/consensus-mechanisms/pos) ## ブロックが保持するパラメータ {#block-anatomy} ブロックにはたくさんの情報が含まれており、 大まかには、以下のようなフィールドがあります。 | フィールド | 説明 | -|:---------------- |:------------------------------- | -| `スロット (slot)` | ブロックが所属するスロット | +| :--------------- | :------------------------------ | +| `slot` | ブロックが所属するスロット | | `proposer_index` | ブロックを提案するバリデータのID | | `parent_root` | 先行ブロックのハッシュ値 | | `state_root` | 状態オブジェクトのルートハッシュ | | `規格の概要` | 以下に定義されているように、複数のフィールドを含むオブジェクト | -ブロックの`body`には独自のフィールドがいくつかあります。 +ブロックの`body`には、独自のフィールドがいくつか含まれています。 | フィールド | 説明 | -|:-------------------- |:------------------------------ | +| :------------------- | :----------------------------- | | `randao_reveal` | 次のブロック提案者の選択に使用される値 | | `eth1_data` | デポジットコントラクトの情報 | -| `グラフィティ` | ブロックのタグ付けに使われる任意のデータ | +| `graffiti` | ブロックのタグ付けに使われる任意のデータ | | `proposer_slashings` | スラッシュされるバリデータのリスト | | `attester_slashings` | スラッシュされる証明者のリスト | -| `アテステーション` | 現在のブロックに賛成しているアテステーションのリスト | +| `アテステーション` | 以前のスロットに対して行われたアテステーションのリスト | | `入金` | デポジットコントラクトに対する新しい入金のリスト | | `voluntary_exits` | ネットワークに存在するバリデータのリスト | | `sync_aggregate` | ライトクライアントへの提供に使用されるバリデータのサブセット | | `execution_payload` | 実行クライアントから渡されるトランザクション | -`attestations`フィールドには、ブロック内のすべてのアテステーションのリストが含まれます。 アテステーションは、複数のデータを含むそれぞれの独自のデータ型があり、 それぞれのアテステーションには以下が含まれています。 +`attestations`フィールドには、ブロック内のすべてのアテステーションのリストが含まれています。 アテステーションは、複数のデータを含むそれぞれの独自のデータ型があり、 それぞれのアテステーションには以下が含まれています。 | フィールド | 説明 | -|:------------------ |:-------------------------- | +| :----------------- | :------------------------- | | `aggregation_bits` | このアテステーションに参加しているバリデータのリスト | | `データ` | 複数のサブフィールドを持つコンテナ | -| `署名` | 証明する全バリデータによる署名の集約　 | +| `署名` | `data`部分に対するバリデータのセットの集約署名 | `attestation`の`data`フィールドには、以下が含まれます。 -| フィールド | 説明 | -|:------------------- |:--------------------------- | -| `スロット (slot)` | アテステーションに関連するスロット | -| `インデックス` | 証明するバリデータのインデックス | -| `beacon_block_root` | このオブジェクトを含むビーコンブロックのルートハッシュ | -| `情報源` | 最後に正当化されたチェックポイント | -| `target` | 最新のエポック境界ブロック | +| フィールド | 説明 | +| :------------------ | :----------------------------- | +| `slot` | アテステーションに関連するスロット | +| `インデックス` | 証明するバリデータのインデックス | +| `beacon_block_root` | チェーンのヘッドと見なされるビーコンブロックのルートハッシュ | +| `情報源` | 最後に正当化されたチェックポイント | +| `target` | 最新のエポック境界ブロック | -`execution_payload`のトランザクションを実行すると、グローバル状態が更新されます。 すべてのクライアントは「新しい状態」が「新しいブロック」の`state_root`フィールドの状態と一致することを確認するために、`execution_payload`のトランザクションを再実行します。 このようにして、クライアントは「新しいブロック」が有効であり、ブロックチェーンに追加しても安全であることを判断します。 `execution payload`自体は、いくつかのフィールドを持つオブジェクトです。 実行データに関する重要な要約情報を含む`execution_payload_header`もあります。 これらのデータ構造は、以下のように構成されています。 +`execution_payload`内のトランザクションを実行すると、グローバル状態が更新されます。 すべてのクライアントは、新しい状態が新しいブロックの`state_root`フィールドの状態と一致することを確認するために、`execution_payload`内のトランザクションを再実行します。 このようにして、クライアントは「新しいブロック」が有効であり、ブロックチェーンに追加しても安全であることを判断します。 `execution payload`自体は、いくつかのフィールドを持つオブジェクトです。 実行データに関する重要な要約情報を含む`execution_payload_header`もあります。 これらのデータ構造は、以下のように構成されています。 `execution_payload_header`には、以下のフィールドが含まれます。 | フィールド | 説明 | -|:------------------- |:------------------------------------ | +| :------------------ | :----------------------------------- | | `parent_hash` | 親ブロックのハッシュ | | `fee_recipient` | トランザクションフィーの支払先アカウントアドレス | | `state_root` | このブロックに変更を適用した後のグローバルステートに対するルートハッシュ | @@ -95,17 +96,17 @@ lang: ja | `block_number` | 現在のブロック番号 | | `gas_limit` | このブロックで許可されているガスの最大値 | | `gas_used` | このブロックで実際に使われたガスの量 | -| `タイムスタンプ` | ブロックタイム | +| `timestamp` | ブロックタイム | | `extra_data` | 生バイトで表される任意の追加データ | | `base_fee_per_gas` | ベースフィーの値 | | `block_hash` | 実行ブロックのハッシュ | | `transactions_root` | ペイロードに含まれるトランザクションのルートハッシュ | | `withdrawal_root` | ペイロードに含まれる引き出しのルートハッシュ | -`execution_payload`自体には、以下のものが含まれます(注:トランザクションのルートハッシュの代わりに実際のトランザクションリストと引き出し情報を含んでいることを除けば、ヘッダーと同じ)。 +`execution_payload`自体には、以下のものが含まれます(注:トランザクションのルートハッシュの代わりに実際のトランザクションリストと引き出し情報を含んでいることを除けば、ヘッダーと同じです)。 | フィールド | 説明 | -|:------------------ |:------------------------------------ | +| :----------------- | :----------------------------------- | | `parent_hash` | 親ブロックのハッシュ | | `fee_recipient` | トランザクションフィーの支払先アカウントアドレス | | `state_root` | このブロックに変更を適用した後のグローバルステートに対するルートハッシュ | @@ -115,18 +116,18 @@ lang: ja | `block_number` | 現在のブロック番号 | | `gas_limit` | このブロックで許可されているガスの最大値 | | `gas_used` | このブロックで実際に使われたガスの量 | -| `タイムスタンプ` | ブロックタイム | +| `timestamp` | ブロックタイム | | `extra_data` | 生バイトで表される任意の追加データ | | `base_fee_per_gas` | ベースフィーの値 | | `block_hash` | 実行ブロックのハッシュ | -| `処理` | 実行されるトランザクションのリスト | -| `引き出し` | 引き出しオブジェクトのリスト | +| `トランザクション` | 実行されるトランザクションのリスト | +| `出金` | 引き出しオブジェクトのリスト | -`withdrawals`リストには、次のように構造化された`withdrawals`オブジェクトが含まれています。 +`withdrawals`リストには、次のように構造化された`withdrawal`オブジェクトが含まれています。 | フィールド | 説明 | -|:---------------- |:--------------- | -| `address` | 引き出されたアカウントアドレス | +| :--------------- | :-------------- | +| `アドレス` | 引き出されたアカウントアドレス | | `金額` | 引き出し金額 | | `インデックス` | 引き出しのインデックス値 | | `validatorIndex` | バリデータのインデックス値 | @@ -135,15 +136,15 @@ lang: ja ブロックタイムとは、ブロックの生成間隔のことです。 イーサリアムでは、12秒単位で時間を分割し、その単位を「スロット」と呼びます。 各スロットでは、1人のバリデータが選ばれ、ブロックを提案します。 すべてのバリデータがオンラインで完全に稼働している場合、すべてのスロットにブロックが1つ生成され、ブロックタイムは12秒となります。 しかし、バリデータがブロックを提案するタイミングでオフラインになっていることがあり、その場合、スロットが空になることがあります。 -この実装は、ブロックタイムが不規則であり、プロトコルがターゲットとして定めるマイニングの難易度によって調整されるプルーフ・オブ・ワークを基としたシステムとは異なります。 イーサリアムの[平均ブロックタイム](https://etherscan.io/chart/blocktime)は、12秒という新しいブロックタイムで安定しており、これは、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行が明確に示される最も良い例です。 +この実装は、ブロックタイムが不規則であり、プロトコルがターゲットとして定めるマイニングの難易度によって調整されるプルーフ・オブ・ワークを基としたシステムとは異なります。 イーサリアムの[平均ブロックタイム](https://etherscan.io/chart/blocktime)は、新しい12秒のブロックタイムの一貫性に基づき、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行が明確に推測できる完璧な例です。 ## ブロックサイズ {#block-size} -最後に重要なのは、ブロックのサイズには制限があるということです。 各ブロックの目標サイズは3,000万ガスですが、ネットワークの需要に合わせて、ブロックの上限である6,000万ガス(目標ブロックサイズの2倍)まで増減します。 ブロックのガスリミットは、前のブロックのガスリミットから1/1024の割合で上下に調整することができます。 したがって、バリデータはコンセンサスによってブロックのガスリミットを変更することができます。 ブロックの全トランザクションで消費されたガスの総量は、ブロックのガスリミットを超えてはいけません。 ブロックが勝手に大きくなりすぎるのを防ぐという点で、この制限は重要です。 ブロックサイズが大きすぎると、スペースと速度の要件により、パフォーマンスの低いフルノードはネットワークに追いつけなくなり、 次のスロットに間に合うように処理するために必要な計算能力も高くなります。 これが中央集権的な力につながってしまうことから、ブロックサイズに上限を設けています。 +最後に重要なのは、ブロックのサイズには制限があるということです。 各ブロックの目標サイズは3000万ガスですが、ネットワークの需要に応じて、ブロックの上限である6000万ガス(目標ブロックサイズの2倍)まで増減します。 ブロックのガスリミットは、前のブロックのガスリミットから1/1024の割合で上下に調整することができます。 したがって、バリデータはコンセンサスによってブロックのガスリミットを変更することができます。 ブロックの全トランザクションで消費されたガスの総量は、ブロックのガスリミットを超えてはいけません。 ブロックが勝手に大きくなりすぎるのを防ぐという点で、この制限は重要です。 ブロックサイズが大きすぎると、スペースと速度の要件により、パフォーマンスの低いフルノードはネットワークに追いつけなくなり、 次のスロットに間に合うように処理するために必要な計算能力も高くなります。 これが中央集権的な力につながってしまうことから、ブロックサイズに上限を設けています。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/bridges/index.md b/public/content/translations/ja/developers/docs/bridges/index.md index e42e20e7088..96ce2dbfd18 100644 --- a/public/content/translations/ja/developers/docs/bridges/index.md +++ b/public/content/translations/ja/developers/docs/bridges/index.md @@ -1,20 +1,20 @@ --- -title: ブリッジ -description: デベロッパー向けのブリッジ概要 +title: "ブリッジ" +description: "デベロッパー向けのブリッジ概要" lang: ja --- -L1のブロックチェーンおよびL2の[スケーリング](/developers/docs/scaling/)ソリューションが一般化し、ますます多くの分散型アプリケーションがクロスチェーンで運用されつつある現在、複数のチェーン間における通信および資産移動を実現する機能がネットワークインフラにおける不可欠な要素となっています。 この機能を提供するために、さまざまな種類のブリッジが開発されています。 +L1ブロックチェーンとL2[スケーリング](/developers/docs/scaling/)ソリューションが普及し、クロスチェーン化する分散型アプリケーションが増え続ける中、チェーンをまたいだ通信と資産移動は、ネットワークインフラに不可欠な要素となっています。 この機能を提供するために、さまざまな種類のブリッジが開発されています。 -## ブリッジがなぜ必要か？ {#need-for-bridges} +## ブリッジの必要性 {#need-for-bridges} ブリッジは、複数のブロックチェーンネットワークを接続するために開発されました。 これにより、複数のブロックチェーンが接続され、相互運用が可能になります。 ブロックチェーンはサイロ化された環境で存在するため、あるブロックチェーンがそれ自体で他のブロックチェーンと取引したり通信したりすることはできません。 このため、特定のエコシステムにおいて活発なアクティビティやイノベーションが発生していたとしても、他のエコシステムとの接続性や相互運用性が存在しないために、当該エコシステム自体の限界を越えることができません。 -ブリッジは、相互に隔離されているブロックチェーン環境を接続する手段を提供します。 複数のブロックチェーン間における転送ルートを提供することで、トークン、メッセージ、任意のデータ、および[スマートコントラクト](/developers/docs/smart-contracts/)の呼び出しさえも、あるブロックチェーンから他のブロックチェーンに転送することが可能になります。 +ブリッジは、相互に隔離されているブロックチェーン環境を接続する手段を提供します。 ブリッジはブロックチェーン間に転送ルートを確立し、トークン、メッセージ、任意のデータ、さらには[スマートコントラクト](/developers/docs/smart-contracts/)の呼び出しまでもが、あるチェーンから別のチェーンへと転送できるようになります。 -## ブリッジの利点 {#benefits-of-bridges} +## ブリッジのメリット {#benefits-of-bridges} ブリッジの有用性は、複数のブロックチェーン間におけるデータの交換や資産の移動を可能にすることで、数多くの新たなユースケースを生み出す可能性を持つ点にあります。 @@ -30,106 +30,109 @@ L1のブロックチェーンおよびL2の[スケーリング](/developers/docs ## ブリッジはどのように機能するのか？ {#how-do-bridges-work} -[ブリッジの設計](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/)には多くの種類がありますが、特に、クロスチェーンで資産を移転する以下の3つの方法が重要です。 +ブリッジの設計には多くの[種類](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/)がありますが、資産のクロスチェーン転送を可能にする方法として、以下の3つが際立っています。 -- **ロックとミント** - ソースチェーン上のアセットをロックした上で、宛先チェーン上でアセットをミントする方式。 -- **バーンとミント** - ソースチェーン上のトークンをバーンした上で、宛先チェーン上で新たにトークンをミントする方式。 -- **アトミックスワップ** - ソースチェーン上の資産と、他のユーザーの宛先チェーン上の資産を直接交換する方式。 +- **ロック・アンド・ミント –** ソースチェーンで資産をロックし、宛先チェーンで資産をミントします。 +- **バーン・アンド・ミント –** ソースチェーンで資産をバーンし、宛先チェーンで資産をミントします。 +- **アトミックスワップ –** 他の当事者と、ソースチェーン上の資産を宛先チェーン上の資産と交換します。 ## ブリッジの種類 {#bridge-types} ブリッジは通常、以下のカテゴリーに分類されます： -- **ネイティブブリッジ** - 通常、特定のブロックチェーンにおいて流動性を自動供給するための構築されたブリッジであり、当該エコシステムに対する資金の転送を容易にするものです。 例えば、[ Arbitrumブリッジ](https://bridge.arbitrum.io/)は、イーサリアムからArbitrumへの資金転送を容易にするために開発されたブリッジです。 この種類のブリッジとしては、Polygon PoSブリッジや[Optimismゲートウェイ](https://app.optimism.io/bridge)等があります。 -- **バリデータ／オラクルベースのブリッジ** - クロスチェーン間の転送につき、外部のバリデータ群またはオラクルによる検証に依存するブリッジです。 MultichainやAcrossが含まれます。 -- **一般的なメッセージの受け渡しを伴うブリッジ** - チェーン間の資産転送につき、メッセージおよび任意のデータと共に実行するもの。 例: Axelar、LayerZero、Nomad。 -- **流動性ネットワーク** - 主に、アトミック・スワップによるチェーン間の資産転送に焦点をあてたブリッジです。 通常、この種類のブリッジはチェーン間のメッセージの受け渡しには対応しません。 ConextやHopが含まれます。 +- **ネイティブブリッジ –** 通常、特定のブロックチェーンの流動性をブートストラップするために構築され、ユーザーがエコシステムに資金を移動しやすくするためのブリッジです。 例えば、[Arbitrum Bridge](https://bridge.arbitrum.io/)は、ユーザーがイーサリアムメインネットからArbitrumにブリッジするのを便利にするために構築されています。 その他の同様のブリッジには、Polygon PoSブリッジ、[Optimism Gateway](https://app.optimism.io/bridge)などがあります。 +- **バリデータまたはオラクルベースのブリッジ –** これらのブリッジは、クロスチェーン転送を検証するために、外部のバリデータセットまたはオラクルに依存します。 MultichainやAcrossが含まれます。 +- **汎用メッセージパッシングブリッジ –** これらのブリッジは、資産だけでなく、メッセージや任意のデータもチェーン間で転送できます。 例: Axelar、LayerZero、Nomad。 +- **流動性ネットワーク –** これらのブリッジは、主にアトミックスワップを介して、あるチェーンから別のチェーンへ資産を転送することに焦点を当てています。 通常、この種類のブリッジはチェーン間のメッセージの受け渡しには対応しません。 ConextやHopが含まれます。 ## 考慮すべきトレードオフ {#trade-offs} どのブリッジも、完璧なソリューションとは言えません。 むしろ、各ブリッジは特定の目的を実現する一方で、トレードオフがあると考えるべきです。 デベロッパーおよびユーザーは、以下の特性に基づいて各ブリッジを評価するとよいでしょう： -- **セキュリティ** - システムの検証を誰が担うか？ 一般に、外部のバリデータによりセキュリティを保証するブリッジは、当該ブロックチェーンのバリデータがローカル／ネイティブにセキュリティを保証する場合よりもセキュリティが低くなります。 -- **利便性** - トランザクションの実行にかかる時間と、ユーザーが署名する必要があるトランザクションの数はどの程度か？ デベロッパーにとっては、ブリッジを組み込むプロセスの時間や複雑さを検討する必要があります。 -- **接続性** - 様々な宛先チェーン（ロールアップ、サイドチェーン、他のL1ブロックチェーン等）にどれだけ接続でき、新規ブロックチェーンとの統合がどの程度難しいかについて検討が必要です。 -- **複雑なデータの伝達能力** - チェーン間におけるメッセージやより複雑な任意データの転送が可能か、あるいは、チェーン間の資産移転のみに対応しているかが問題になります。 -- **コスト効率** - ブリッジによるチェーン間の資産転送において、どの程度コストが発生するかです。 ブリッジは一般に、固定の手数料またはガス代および特定の転送レートの流動性に基づく変動料金を請求します。 さらに、セキュリティを確保するのにどれだけの手数料が必要になるかに基づき、特定のブリッジにおけるコスト効率を評価することが非常に重要です。 +- **セキュリティ –** システムの検証を誰が担うか？ 一般に、外部のバリデータによりセキュリティを保証するブリッジは、当該ブロックチェーンのバリデータがローカル／ネイティブにセキュリティを保証する場合よりもセキュリティが低くなります。 +- **利便性 –** トランザクションの完了にかかる時間と、ユーザーが署名する必要があるトランザクションの数はどのくらいか？ デベロッパーにとっては、ブリッジを組み込むプロセスの時間や複雑さを検討する必要があります。 +- **接続性 –** ブリッジが接続できる宛先チェーンの種類 (ロールアップ、サイドチェーン、他のレイヤー1ブロックチェーンなど) は何か、また新しいブロックチェーンを統合するのはどれくらい難しいか？ +- **より複雑なデータの転送能力 –** ブリッジは、メッセージやより複雑な任意のデータをチェーン間で転送できるか、それともクロスチェーンの資産転送のみをサポートしているか？ +- **コスト効率 –** ブリッジを介してチェーン間で資産を転送するのに、どれくらいのコストがかかるか？ ブリッジは一般に、固定の手数料またはガス代および特定の転送レートの流動性に基づく変動料金を請求します。 さらに、セキュリティを確保するのにどれだけの手数料が必要になるかに基づき、特定のブリッジにおけるコスト効率を評価することが非常に重要です。 より大まかに見れば、ブリッジはトラステッドとトラストレスの2種類に分類できます。 -- **トラステッド** - トラステッドのブリッジとは、外部による検証に依存するブリッジです。 つまり、チェーン間のデータ送信につき、外部の検証者セット（マルチシグによるフェデレーション、マルチパーティの計算システム、オラクルネットワーク）が介在するブリッジを指します。 これにより、接続性に優れ、完全に汎用化されたメッセージをチェーン間でやりとりすることができます。 さらに、速度やコスト効率の面からも優れている場合が多いです。 ただし、ユーザーはブリッジ自体のセキュリティに依存するため、セキュリティが損なわれる可能性があります。 -- **トラストレス** - これらのブリッジは、接続するブロックチェーンならびに転送するメッセージやトークンに対するバリデータに依存しています。 これらのブリッジが「トラストレス」と呼ばれるのは、（ブロックチェーン自体で想定するものを除き）、新たな信頼想定を追加しないためです。 これにより、トラステッドのブリッジと比較してセキュリティが高いと評価されます。 +- **トラステッド –** トラステッドブリッジは外部で検証されます。 つまり、チェーン間のデータ送信につき、外部の検証者セット（マルチシグによるフェデレーション、マルチパーティの計算システム、オラクルネットワーク）が介在するブリッジを指します。 これにより、接続性に優れ、完全に汎用化されたメッセージをチェーン間でやりとりすることができます。 さらに、速度やコスト効率の面からも優れている場合が多いです。 ただし、ユーザーはブリッジ自体のセキュリティに依存するため、セキュリティが損なわれる可能性があります。 +- **トラストレス –** これらのブリッジは、接続しているブロックチェーンとそのバリデータに依存して、メッセージとトークンを転送します。 これらのブリッジが「トラストレス」と呼ばれるのは、（ブロックチェーン自体で想定するものを除き）、新たな信頼想定を追加しないためです。 これにより、トラステッドのブリッジと比較してセキュリティが高いと評価されます。 トラストレスのブリッジを他の要素で評価する場合、汎用型メッセージの受け渡しが可能なブリッジと、流動性ネットワークのブリッジに分けて考える必要があります。 -- **汎用型メッセージを受け渡すブリッジ** - この種類のブリッジは、チェーン間において、より複雑なデータを安全に転送するのに有用です。 また、多くの場合コスト効率性も優れています。 ただし、これらの強みを持つ一方で、ライトクライアントのブリッジ（例: IBC）に接続できない点や、オプティミスティック・ブリッジ（例: Nomad）の場合に速度が低下するなどの欠点があります。 -- **流動性ネットワーク** - この種類のブリッジは、アトミックスワップを用いて資産を転送するもので、ローカルで検証されるシステムです（つまり、トランザクションを検証するために、裏付けとなるブロックチェーンのバリデータを用います）。 このため、セキュリティと実行速度の両方が優れています。 さらに、コスト効率性や接続性も比較的優れていると考えられています。 ただし、チェーン間におけるメッセージの受け渡しが不可能であるため、より複雑なデータを扱えないという大きな欠点があります。 +- **汎用メッセージパッシングブリッジ –** これらのブリッジは、セキュリティと、より複雑なデータをチェーン間で転送する能力に優れています。 また、多くの場合コスト効率性も優れています。 ただし、これらの強みを持つ一方で、ライトクライアントのブリッジ（例: IBC）に接続できない点や、オプティミスティック・ブリッジ（例: Nomad）の場合に速度が低下するなどの欠点があります。 +- **流動性ネットワーク –** これらのブリッジは、資産の転送にアトミックスワップを使用し、ローカルで検証されるシステムです (つまり、トランザクションを検証するために基盤となるブロックチェーンのバリデータを使用します)。 このため、セキュリティと実行速度の両方が優れています。 さらに、コスト効率性や接続性も比較的優れていると考えられています。 ただし、チェーン間におけるメッセージの受け渡しが不可能であるため、より複雑なデータを扱えないという大きな欠点があります。 -## ブリッジに伴うリスク {#risk-with-bridges} +## ブリッジのリスク {#risk-with-bridges} -ブリッジは、[DeFiにおける最悪のハッキング事例](https://rekt.news/leaderboard/)上位3位における原因となっており、現在も開発途上の技術です。 ブリッジの利用は、以下のようなリスクを伴います: +ブリッジは、[DeFiにおける最大のハッキング](https://rekt.news/leaderboard/)のトップ3を占めており、まだ開発の初期段階にあります。 ブリッジの利用は、以下のようなリスクを伴います: -- **スマートコントラクトのリスク** - 多くのブリッジは監査に合格しているものの、スマートコントラクトに欠陥がひとつでも含まれていれば、資産に対するハッキング攻撃が可能になります（例: [Solanaのワームホールブリッジ](https://rekt.news/wormhole-rekt/)）。 -- **システミックな財務リスク** - 多くのブリッジでは、原資産の正規バージョンを新規チェーンでミントするためにラップ資産を用います。 ラップされたトークンが悪用された事例はすでに発生しており、エコシステム全体にシステミックリスクをもたらします。 -- **カウンターパーティリスク** - 一部のブリッジでは、複数のバリデータが共謀してユーザーの資金を奪い取ろうと考えることはないという信頼の想定をユーザーに要求する、信頼ベースの設計を採用しています。 ユーザーは、これらのサードパーティアクターを信頼しなければならないため、ラグプル、検閲、およびその他の悪意の行為が発生するリスクにさらされています。 -- **未解決の問題** - 現在でもブリッジは開発の初期段階にあるため、様々な市場環境（ネットワーク混雑時や、ネットワーク全体への攻撃やステートのロールバックといった予見できないイベントの発生時）においてブリッジがどのように機能するかについては、未確認の事項が多く残っています。 この不確実性は様々なリスクをもたらすものですが、その影響の度合いはまだ不明です。 +- **スマートコントラクトのリスク –** 多くのブリッジは監査に合格していますが、スマートコントラクトに1つの欠陥があるだけで、資産がハッキングにさらされる可能性があります (例: [SolanaのWormholeブリッジ](https://rekt.news/wormhole-rekt/))。 +- **システミックな金融リスク** – 多くのブリッジは、新しいチェーンで元の資産のカノニカルバージョンをミントするために、ラップされた資産を使用します。 ラップされたトークンが悪用された事例はすでに発生しており、エコシステム全体にシステミックリスクをもたらします。 +- **カウンターパーティリスク –** 一部のブリッジは、バリデータが共謀してユーザーの資金を盗むことはないという仮定にユーザーが依存することを要求する、トラステッドな設計を利用しています。 ユーザーは、これらのサードパーティアクターを信頼しなければならないため、ラグプル、検閲、およびその他の悪意の行為が発生するリスクにさらされています。 +- **未解決の問題 –** ブリッジは開発の初期段階にあるため、ネットワークの混雑時や、ネットワークレベルの攻撃やステートのロールバックなどの予期せぬイベントの発生時といった、さまざまな市場状況でブリッジがどのように機能するかについては、多くの未解決の疑問があります。 この不確実性は様々なリスクをもたらすものですが、その影響の度合いはまだ不明です。 ## Dappでブリッジを利用する方法 {#how-can-dapps-use-bridges} 以下では、デベロッパがブリッジを活用してDappのクロスチェーン化を検討する際の実践的な応用例について紹介します: -### ブリッジとの統合 {#integrating-bridges} +### ブリッジの統合 {#integrating-bridges} 開発中のDappをブリッジに対応させるには、多くの方法が存在します: -1. **独自のブリッジを構築する** - 安全で信頼性が高いブリッジの開発は、特にトラストレスのアプローチを採用した場合、容易ではありません。 さらに、スケーラビリティや相互運用性に関する豊富な経験や技術的な知識が必要です。 また、ブリッジを管理し、実務上要求される十分な流動性を維持するためには常駐チームが必要です。 +1. **独自のブリッジを構築する –** 安全で信頼性の高いブリッジを構築するのは容易ではありません。特に、より信頼を最小化するアプローチをとる場合はなおさらです。 さらに、スケーラビリティや相互運用性に関する豊富な経験や技術的な知識が必要です。 また、ブリッジを管理し、実務上要求される十分な流動性を維持するためには常駐チームが必要です。 -2. **ユーザーが様々なブリッジから選択できるようにする** - 多くの[Dapp](/developers/docs/dapps/)では、ユーザーに対してネイティブトークンでのやりとりを要求しています。 ユーザーが所有するトークンを利用できるようにするために、Dappのウェブサイトでは様々なブリッジのオプションを提供しています。 しかしこの方法は、自社のDappのインターフェイスだけでプロセスを完結できず、他のDappやブリッジとのやりとりが必要になるため、その場しのぎの対策と言わざるを得ません。 また、ユーザーのオンボーディングが複雑になり、ミスが発生する可能性も高まります。 +2. **ユーザーに複数のブリッジオプションを提示する –** 多くの[dapps](/developers/docs/dapps/)では、それらと対話するためにユーザーがネイティブトークンを持っている必要があります。 ユーザーが所有するトークンを利用できるようにするために、Dappのウェブサイトでは様々なブリッジのオプションを提供しています。 しかしこの方法は、自社のDappのインターフェイスだけでプロセスを完結できず、他のDappやブリッジとのやりとりが必要になるため、その場しのぎの対策と言わざるを得ません。 また、ユーザーのオンボーディングが複雑になり、ミスが発生する可能性も高まります。 -3. **Dapp内にブリッジを組み込む** - このアプローチでは、ユーザーは外部のブリッジやDEXインターフェイスとやりとりする必要がなくなります。 このため、ユーザーのオンボーディング体験が向上します。 しかし、このアプローチにも以下のような制限があります: +3. **ブリッジを統合する –** このソリューションでは、dappがユーザーを外部のブリッジやDEXインターフェイスに送る必要はありません。 このため、ユーザーのオンボーディング体験が向上します。 しかし、このアプローチにも以下のような制限があります: - ブリッジに対する評価やメンテナンスは、手間や時間がかかる。 - ひとつのブリッジを選択することで、単一障害点や依存関係が発生する。 - 当該ブリッジの機能により、Dappのサービスが制限される。 - ブリッジだけでは対応できない機能が必要になる場合がある。 チェーン間のスワップなどの機能を追加するには、DEXを含める必要がある場合がある。 -4. **複数のブリッジを組み込む** - このアプローチは、ひとつのブリッジを統合する場合の多くの問題を解消できます。 一方で、複数のブリッジとの統合は多くのリソースを消費し、暗号資産の分野において最も希少性が高いリソースであるデベロッパーにとって、技術面およびコミュニケーション面での負担が増加してしまいます。 +4. **複数のブリッジを統合する –** このソリューションは、単一のブリッジの統合に関連する多くの問題を解決します。 一方で、複数のブリッジとの統合は多くのリソースを消費し、暗号資産の分野において最も希少性が高いリソースであるデベロッパーにとって、技術面およびコミュニケーション面での負担が増加してしまいます。 -5. **ブリッジアグリゲーターを導入する** - 複数のブリッジにアクセスできる、ブリッジアグリゲーションを活用するのもひとつの方法です。 ブリッジアグリゲーターはすべてのブリッジの強みを継承するため、各ブリッジが提供する機能のみに制限されなくなります。 特に、通常はブリッジアグリゲーターがDappとブリッジとの統合を管理するため、Dappのデベロッパー側はブリッジとの統合における技術的／運用的な側面を管理する作業から解放されます。 +5. **ブリッジアグリゲーターを統合する –** dappsのもう一つの選択肢は、複数のブリッジへのアクセスを提供するブリッジアグリゲーションソリューションを統合することです。 ブリッジアグリゲーターはすべてのブリッジの強みを継承するため、各ブリッジが提供する機能のみに制限されなくなります。 特に、通常はブリッジアグリゲーターがDappとブリッジとの統合を管理するため、Dappのデベロッパー側はブリッジとの統合における技術的／運用的な側面を管理する作業から解放されます。 ブリッジアグリゲーターは、このような利点を持つ一方で、欠点もあります。 例えば、より多くのブリッジを活用するオプションを提供することは事実ですが、特定のアグリゲーターのプラットフォームが提供するブリッジよりもさらに多くのブリッジが市場で提供されています。 さらに、ブリッジの場合と同じように、ブリッジアグリゲーターもスマートコントラクトやテクノロジーに由来するリスクにさらされています（対応するコントラクトが多くなれば、リスクも拡大します）。 Dappにブリッジやブリッジアグリゲーターを組み込む場合、統合の度合いに応じて様々なオプションが考えられます。 例えば、ユーザーにおけるオンボーディング体験の向上を目的とするフロントエンドのみの統合では、ウィジェットを搭載すればよいでしょう。 しかし、ステーキングやイールドファーミング等のより複雑なチェーン間のやりとりを実現するには、SDKやAPIを統合する必要があります。 -### 複数のチェーン上でDappをデプロイする {#deploying-a-dapp-on-multiple-chains} +### 複数のチェーンにdappをデプロイする {#deploying-a-dapp-on-multiple-chains} -To deploy a dapp on multiple chains, developers can use development platforms like [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/), etc. 一般にこれらのプラットフォームには、Dappのクロスチェーン化を実現するコンポーザブルなプラグインが含まれています。 例えば、 [hardhat-deploy plugin](https://github.com/wighawag/hardhat-deploy)で提供される決定論的なデプロイ用プロキシを活用することができます。 +複数のチェーンにdappをデプロイするために、開発者は[Alchemy](https://www.alchemy.com/)、[Hardhat](https://hardhat.org/)、[Moralis](https://moralis.io/)などの開発プラットフォームを利用できます。 一般にこれらのプラットフォームには、Dappのクロスチェーン化を実現するコンポーザブルなプラグインが含まれています。 例えば、開発者は[hardhat-deployプラグイン](https://github.com/wighawag/hardhat-deploy)によって提供される決定論的デプロイメントプロキシを使用できます。 -#### 例: +#### 例： -- [クロスチェーン対応のDappを開発する方法](https://moralis.io/how-to-build-cross-chain-dapps/) -- [クロスチェーン対応のNFTマーケットプレイスを開発する方法](https://youtu.be/WZWCzsB1xUE) -- [Moralis: クロスチェーン対応のDAppsを開発する](https://www.youtube.com/watch?v=ehv70kE1QYo) +- [クロスチェーンdappsの構築方法](https://moralis.io/how-to-build-cross-chain-dapps/) +- [クロスチェーンNFTマーケットプレイスの構築](https://youtu.be/WZWCzsB1xUE) +- [Moralis: クロスチェーンNFT dappsの構築](https://www.youtube.com/watch?v=ehv70kE1QYo) -### コントラクトにおけるチェーン間のやりとりを監視する {#monitoring-contract-activity-across-chains} +### チェーンをまたいだコントラクトアクティビティの監視 {#monitoring-contract-activity-across-chains} -コントラクトにおけるチェーン間のやりとりを監視するには、サブグラフや、Tenderly等の開発プラットフォームを用いて、スマートコントラクトの状態をリアルタイムで観察することができます。 これらのプラットフォームにはさらに、[コントラクトが発行したイベント](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events)をチェックするなど、チェーン間のやりとりを対象としてより充実したデータ監視機能を実現できるツールが含まれています。 +コントラクトにおけるチェーン間のやりとりを監視するには、サブグラフや、Tenderly等の開発プラットフォームを用いて、スマートコントラクトの状態をリアルタイムで観察することができます。 このようなプラットフォームには、[コントラクトによって発行されたイベント](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events)のチェックなど、クロスチェーンアクティビティのためのより高度なデータ監視機能を提供するツールも含まれています。 #### ツール - [The Graph](https://thegraph.com/en/) - [Tenderly](https://tenderly.co/) -## さらに学びたい方へ {#further-reading} +## 参考リンク {#further-reading} -- [ブロックチェーンにおけるブリッジ](/bridges/) - ethereum.org -- [ブロックチェーンにおけるブリッジ: クリプトネットワークのネットワーク構築](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 2021年9月8日、ドミトリー・ベレンゾン作成。 -- [相互運用性のトリレンマ](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 2021年10月1日、アルジュン・ブプタニ作成。 -- [クラスタ: 信頼ベースおよび信頼最小化のブリッジは、マルチチェーン環境をどのように変化させるか](https://blog.celestia.org/clusters/) 2021年10月4日、ムスタファ・アル＝バッサム作成。 -- [LI.FI: ブリッジの信頼依存度は様々に異なる](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 2022年4月28日 、アルジュン・チャンド作成。 +- [ブロックチェーンブリッジ](/bridges/) – ethereum.org +- [L2Beatブリッジリスクフレームワーク](https://l2beat.com/bridges/summary) +- [ブロックチェーンブリッジ: 暗号ネットワークのネットワークを構築する](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 2021年9月8日 – Dmitriy Berenzon +- [相互運用性のトリレンマ](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 2021年10月1日 – Arjun Bhuptani +- [クラスター: トラステッドブリッジとトラストミニマイズドブリッジがマルチチェーンのランドスケープをどのように形成するか](https://blog.celestia.org/clusters/) - 2021年10月4日 – Mustafa Al-Bassam +- [LI.FI: ブリッジにおいて、信頼はスペクトラムである](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 2022年4月28日 – Arjun Chand +- [ロールアップの相互運用性ソリューションの現状](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 2024年6月20日 – Alex Hook +- [安全なクロスチェーン相互運用性のための共有セキュリティの活用: ラグランジュステート委員会とその先](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 2024年6月12日 – Emmanuel Awosika -ブリッジについてさらに理解を深めたい方は、 [ジェイムズ・プレストウィッチ](https://twitter.com/_prestwich)による洞察溢れる講演をご覧ください: +さらに、ブリッジへの理解を深めるのに役立つ、[James Prestwich](https://twitter.com/_prestwich)による洞察に満ちたプレゼンテーションをいくつか紹介します。 -- [塀に囲まれたガーデンではなく、ブリッジを構築する](https://youtu.be/ZQJWMiX4hT0) -- [ブリッジを破壊する](https://youtu.be/b0mC-ZqN8Oo) -- [ブリッジはなぜ燃えているのか](https://youtu.be/c7cm2kd20j8) +- [壁に囲まれた庭ではなく、ブリッジを築く](https://youtu.be/ZQJWMiX4hT0) +- [ブリッジの徹底解説](https://youtu.be/b0mC-ZqN8Oo) +- [なぜブリッジは燃えているのか](https://youtu.be/c7cm2kd20j8) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md index 9c86bda817f..1c4de03f3c0 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md @@ -1,14 +1,14 @@ --- -title: 合意メカニズム -description: 分散システムにおける合意形成プロトコルと、イーサリアムにおける合意形成プロトコルの役割についての解説 +title: "合意メカニズム" +description: "分散システムにおける合意形成プロトコルと、イーサリアムにおける合意形成プロトコルの役割についての解説" lang: ja --- -合意メカニズムという用語は、「プルーフ・オブ・ステーク」、「プルーフ・オブ・ワーク」、「プルーフ・オブ・オーソリティ」といったプロトコルを指すのに使われることがあります。 しかし、これらはあくまで[シビル攻撃](/glossary/#sybil-attack)に対抗するための合意メカニズムの一部に過ぎません。 合意メカニズムは、分散された一連のノードがブロックチェーンの状態に合意できるようにする考え方、プロトコル、およびインセンティブを完全にまとめたメカニズムです。 +合意メカニズムという用語は、「プルーフ・オブ・ステーク」、「プルーフ・オブ・ワーク」、「プルーフ・オブ・オーソリティ」といったプロトコルを指すのに使われることがあります。 しかし、これらは[シビル攻撃](/glossary/#sybil-attack)を防ぐ合意メカニズムの構成要素に過ぎません。 合意メカニズムは、分散された一連のノードがブロックチェーンの状態に合意できるようにする考え方、プロトコル、およびインセンティブを完全にまとめたメカニズムです。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページの理解を深めるために、まずは[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 +このページをより深く理解するために、まずは[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 ## コンセンサス(合意)とは {#what-is-consensus} @@ -28,9 +28,9 @@ lang: ja これらの構成要素が一体となって合意メカニズムを形成しています。 -## 合意形成アルゴリズムの種類 {#types-of-consensus-mechanisms} +## 合意メカニズムの種類 {#types-of-consensus-mechanisms} -### プルーフ・オブ・ワーク方式 {#proof-of-work} +### プルーフ・オブ・ワークベース {#proof-of-work} ビットコインと同様に、イーサリアムもかつては**プルーフ・オブ・ワーク(PoW)**に基づいたコンセンサスプロトコルを使用していました。 @@ -44,7 +44,7 @@ lang: ja [プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)の詳細 -### プルーフ・オブ・ステーク方式 {#proof-of-stake} +### プルーフ・オブ・ステークベース {#proof-of-stake} イーサリアムは現在、**プルーフ・オブ・ステーク(PoS)**に基づいたコンセンサスプロトコルを使用しています。 @@ -56,7 +56,7 @@ lang: ja 仮にプルーフ・オブ・ステーク・システムでチェーンを支配しようとすると、攻撃者は大量のETHを破壊しなければならないため、暗号経済的に安全性が保たれています。 報酬システムがステーカーに対して、誠実な行動を取るようにインセンティブを与える一方、ペナルティは悪意のある行動を抑制しています。 -[プルーフ・オブ・ステーク ](/developers/docs/consensus-mechanisms/pos/)の詳細 +[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)の詳細 ### ビジュアルガイド {#types-of-consensus-video} @@ -68,21 +68,21 @@ lang: ja プルーフ・オブ・ワークとプルーフ・オブ・ステークは、それ自体はコンセンサスプロトコルではありませんが、分かりやすくするためにそのように呼ばれることがよくあります。 これらは実際にはシビル耐性メカニズムであり、誰が最新のブロックを作成するかを決めるものです。 もう一つの重要なコンポーネントは、チェーン・チョイス(別名:フォーク選択)アルゴリズムです。これはチェーンの先頭に複数のブロックが存在する場合、正しいブロックをノードが1つ選択するアルゴリズムです。 -**シビル耐性**はシビル攻撃に対するプロトコルの性能を測るものです。 この種の攻撃への耐性は、分散型ブロックチェーンには不可欠であり、この耐性があることにより、投入されたリソースに応じてマイナーとバリデータが平等に報酬を得ることができます。 プルーフ・オブ・ワークやプルーフ・オブ・ステークは、ユーザーに多くのエネルギーを消費させたり、多くの担保を入れさせることで、この問題を解決します。 これらは、シビル攻撃に対する経済的な抑止力となります。 +**シビル耐性**は、プロトコルがシビル攻撃に対してどの程度有効かを測るものです。 この種の攻撃への耐性は、分散型ブロックチェーンには不可欠であり、この耐性があることにより、投入されたリソースに応じてマイナーとバリデータが平等に報酬を得ることができます。 プルーフ・オブ・ワークやプルーフ・オブ・ステークは、ユーザーに多くのエネルギーを消費させたり、多くの担保を入れさせることで、この問題を解決します。 これらは、シビル攻撃に対する経済的な抑止力となります。 -**チェーン・セレクション・ルール**は、どのチェーンが「正しい」チェーンであるかを決定するルールです。 イーサリアムとビットコインは、ブロックチェーンの長さが長い方を、他のノードが有効なものとして受け入れるという「最長のチェーン」ルールを採用しています。 プルーフ・オブ・ワークチェーンの場合、最長のチェーンはチェーンの累積プルーフ・オブ・ワーク難易度によって決定されます。 イーサリアムも以前は「最長チェーン」ルールを採用していましたが、現在のイーサリアムはプルーフ・オブ・ステークで実行されており、チェーンの「重み」を測定する最新のフォーク・チョイス・アルゴリズムを採用しています。 この重みは、バリデータの投票の累計をバリデータがステーキングしたイーサ残高により加重されて決まります。 +**チェーン選択ルール**は、どのチェーンが「正しい」チェーンであるかを決定するために使用されます。 イーサリアムとビットコインは、ブロックチェーンの長さが長い方を、他のノードが有効なものとして受け入れるという「最長のチェーン」ルールを採用しています。 プルーフ・オブ・ワークチェーンの場合、最長のチェーンはチェーンの累積プルーフ・オブ・ワーク難易度によって決定されます。 イーサリアムも以前は「最長チェーン」ルールを採用していました。しかし、現在のイーサリアムはプルーフ・オブ・ステークで実行されており、チェーンの「重み」を測定する最新のフォーク選択アルゴリズムを採用しています。 この重みは、バリデータの投票の累計をバリデータがステーキングしたイーサ残高により加重されて決まります。 -イーサリアムでは、[Casper FFGプルーフ・オブ・ステーク](https://arxiv.org/abs/1710.09437)と[GHOSTフォーク・チョイスルール](https://arxiv.org/abs/2003.03052)を組み合わせた[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)と呼ばれる合意メカニズムが採用されています。 +イーサリアムは、[Casper FFG プルーフ・オブ・ステーク](https://arxiv.org/abs/1710.09437)と[GHOSTフォークチョイスルール](https://arxiv.org/abs/2003.03052)を組み合わせた、[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)として知られる合意メカニズムを使用しています。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [ブロックチェーンの合意アルゴリズムとは](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm) -- [ナカモトコンセンサスとは 初心者向け完全ガイド](https://blockonomi.com/nakamoto-consensus/) -- [Casperの仕組み](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) -- [プルーフ・オブ・ワーク・ブロックチェーンのセキュリティと性能について](https://eprint.iacr.org/2016/555.pdf) +- [ブロックチェーンのコンセンサスアルゴリズムとは？](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm) +- [ナカモトコンセンサスとは？ 完全初心者向けガイド](https://blockonomi.com/nakamoto-consensus/) +- [Casperはどのように機能するのか？](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) +- [プルーフ・オブ・ワーク・ブロックチェーンのセキュリティとパフォーマンスについて](https://eprint.iacr.org/2016/555.pdf) - [ビザンチン障害](https://en.wikipedia.org/wiki/Byzantine_fault) -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md index 964fa0274fc..c5d372b4101 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md @@ -1,12 +1,12 @@ --- -title: プルーフ・オブ・オーソリティ(PoA) -description: ブロックチェーンエコシステムにおけるプルーフ・オブ・オーソリティのコンセンサスプロトコルとその役割について +title: "プルーフ・オブ・オーソリティ(PoA)" +description: "ブロックチェーンエコシステムにおけるプルーフ・オブ・オーソリティのコンセンサスプロトコルとその役割について" lang: ja --- **プルーフ・オブ・オーソリティ(PoA)** は、評判ベースのコンセンサスアルゴリズムで[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)を変更したバージョンです。 主にプライベートチェーン、テストネット、ローカル開発用ネットワークで使われています。 評判ベースのコンセンサスアルゴリズムであるプルーフ・オブ・オーソリティは、ブロックを生成するために、認証された署名者達のセットを信頼することを求めます。この点でステーキングベースのメカニズムであるプルーフ・オブ・ステークと違います。 -## 前提条件{#prerequisites} +## 前提条件 {#prerequisites} このページについて深く理解するには、事前に[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。 @@ -18,7 +18,7 @@ lang: ja プルーフ・オブ・オーソリティには、複数の実装がありますが、イーサリアムの実装の標準は、**Clique**です。これは、[EIP-225](https://eips.ethereum.org/EIPS/eip-225)を実装しています。 Cliqueは、デベロッパーフレンドリーで、簡単に実装できる標準であり、クライアントの同期タイプのすべてをサポートしています。 他の実装としては、[IBFT 2.0](https://besu.hyperledger.org/private-networks/concepts/poa) や[Aura](https://openethereum.github.io/Chain-specification)などがあります。 -## 仕組みの説明{#how-it-works} +## 仕組みの説明 {#how-it-works} プルーフ・オブ・オーソリティでは、新しいブロックを作るために、認証された署名者達のセットが選ばれます。 署名者達は、評判ベースで選ばれ、これらの署名者達のみが新しいブロックを作成することを許されます。 ラウンドロビン方式で署名者達が選ばれます。選ばれた各署名者は、特定の時間枠内でブロックを作成することが許されます。 このブロック作成時間は固定されており、署名者達は時間枠内にブロックを作成しなければなりません。 @@ -28,36 +28,36 @@ lang: ja 小さなフォークが起こる状況があり得えます。ブロックの難易度は、署名が順序か順序外かによって違います。 「順序」のブロックの難易度は2、「順序外」のブロックの難易度は1です。 小さなフォークが発生した場合、「順序」ブロックにシールした多数の署名者を持つチェーンに最も多い難易度が累積し、勝利します。 -## 攻撃ベクトル{#attack-vectors} +## 攻撃ベクトル {#attack-vectors} -### 悪意のある署名者達{#malicious-signers} +### 悪意のある署名者達 {#malicious-signers} 署名者リストに悪意のあるユーザーが追加されたり、署名鍵およびマシンが侵害されたりする可能性があります。 このようなシナリオにおいて、プロトコルには、再編成やスパムに対して防御する能力が必要になります。 提案された解決策では、N人の認証された署名者のリストが与えられた場合、各署名者はK回ごとに1つのブロックしかミントできません。これにより、被害が限定され、残りのバリデータが悪意のあるユーザーを排除するための投票を行うことが可能になります。 -### 検閲{#censorship-attack} +### 検閲 {#censorship-attack} もう1つの興味深い攻撃ベクトルは、署名者(あるいは署名者のグループ)が、認証者リストからそれらの署名者を削除することに投票したブロックを検閲しようとする場合です。 これに対処する方法は、署名者に許可されるミントの頻度をN/2の中から1に制限することです。 これにより、悪意のある署名者達は、署名するアカウントの最低51%をコントロールする必要があります。51%に達すれば、チェーンの新たな信頼できる情報源になることができます。 -### スパム{#spam-attack} +### スパム {#spam-attack} 他の小さな攻撃ベクトルは、悪意のある署名者達がミントする各ブロック内において新たな投票提案をすることです。 ノードは、実際の認証された署名者のリストを作成するために、投票のすべてを集計する必要があるため、常に投票のすべてを記録しなければなりません。 投票枠に制限を設けないと、投票はゆっくりと、しかし無制限に増える可能性があります。 これに対する解決策は、Wブロックの _移動_ 枠を設けて、そのWブロック後の投票が古いと見なすことです。 _妥当な枠は1～2エポックでしょう。_ -### 同時発生ブロック{#concurrent-blocks} +### 同時発生ブロック {#concurrent-blocks} PoAネットワークでは、N人の認証された署名者がいる場合、各署名者はK回ごとに1つのブロックをミントすることが許可されています。つまり、任意の時点でN-K+1人のバリデータがブロックをミントできることになります。 これらのバリデーターがブロックを競って生成するのを防ぐために、各署名者は新しいブロックをリリースする時間に小さなランダムな「オフセット」を追加する必要があります。 このプロセスにより、小規模なフォークが発生する可能性は低くなりますが、それでも時折フォークが発生することがあります。これはメインネットと同様です。 署名者が権限を悪用したり混乱を引き起こしたりした場合、他の署名者達は投票により排除することができます。 例えば、10人の認証された署名者がいて、各署名者が20回ごとに1つのブロックを作成できる場合、任意の時点で11人のバリデータがブロックを作成できることになります。 マイナー同士のブロック作成の競争を防ぐために、各署名者は 新しいブロックをリリースする時間に、小さなランダムな「オフセット」を追加します。 これにより、小さなフォークの発生を減らすことが出来ますが、イーサリアムのメインネットで見られるように、場合によってはフォークが発生する可能性があります。 署名者が権限を悪用したり、混乱を引き起こした場合、投票によりネットワークから排除することができます。 -## メリットとデメリット{#pros-and-cons} +## メリットとデメリット {#pros-and-cons} -| メリット | デメリット | +| 長所 | 短所 | | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | ブロック署名者の数を制限することをベースとしているため、他の一般的なメカニズムであるプルーフ・オブ・ステークやプルーフ・オブ・ワークなどよりもスケーラブル。 | プルーフ・オブ・オーソリティのネットワークでは、検証ノードの数が比較的少ない。 これにより、プルーフ・オブ・オーソリティのネットワークは、より集中化する。 | | プルーフ・オブ・オーソリティは、実行と維持が安価。 | ブロックチェーンは評判の確立したエンティティを要求するため、一般的な人は通常、認証された署名者になることができない。 | | トランザクションの承認が非常に速い。新しいブロックの検証に必要な署名者の数が限られているため、1秒未満で達成可能。 | 悪意のある署名者達が、ネットワークにおいて再編成、二重支払い、トランザクションの検閲をする可能性がある。これらの攻撃を軽減することはできるが、完全に防止はできない。 | -## 参考リンク{#further-reading} +## 参考リンク {#further-reading} - [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique標準_ - [プルーフ・オブ・オーソリティの研究](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_ @@ -74,7 +74,8 @@ PoAネットワークでは、N人の認証された署名者がいる場合、 -## 関連トピック{#related-topics} +## 関連トピック {#related-topics} - [プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/) - [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/) + diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md index 6674abbc459..25f756ed887 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -1,12 +1,12 @@ --- -title: イーサリアムのプルーフ・オブ・ステークにおける攻撃および防御 -description: イーサリアムのプルーフ・オブ・ステークに対する既知の攻撃ベクトルについて知り、防御方法について学ぶ +title: "イーサリアムのプルーフ・オブ・ステークにおける攻撃および防御" +description: "イーサリアムのプルーフ・オブ・ステークに対する既知の攻撃ベクトルについて知り、防御方法について学ぶ" lang: ja --- イーサリアムのクライアントソフトウェアは、常に窃盗や破壊行為の脅威にさらされています。 このページでは、イーサリアムのコンセンサスレイヤーに対する既知の攻撃ベクトルについて概説し、これらの攻撃をどのように防ぐべきかについて説明します。 このページの内容は、[こちらの長文バージョン](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)を要約したものです。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)の基本的な知識が必要です。 また、イーサリアムの[インセンティブレイヤー](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)とフォーク選択アルゴリズム、[LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper)について基礎的に理解しておくとよいでしょう。 @@ -14,7 +14,7 @@ lang: ja イーサリアムに対する攻撃については、攻撃が成功した場合に新規のイーサを生成したり、ランダムに選んだアカウントからイーサを盗み取ることが可能だ、と誤解している人が多いです。 実際にはこれらは不可能です。なぜなら、イーサリアムにおけるすべてのトランザクションは、イーサリアム・ネットワークに含まれるすべての実行クライアントにより実行されるからです。 トランザクションが有効であるためには基本的な条件を満たす必要があり（送信者の秘密鍵を使って署名されており、送信者の残高が十分であるなど）、これらの条件を満たさない場合には、トランザクションを実行する前の状態に復元されます。 このため、攻撃者が現実的に望みうるのは、再編成、二重ファイナリティ、またはファイナリティの遅延という3つの結果だけです。 -**「再編成」**とは、ブロックの順番が変更されるようにシャッフルすることであり、正規チェーンに新たなブロックを追加したり、既存のブロックが削除される場合が多いです。 悪意に基づく再編成は特定のブロックを追加／削除することを目的とする場合があり、トランザクションをフロントランニング／バックランニングすることで、二重支出や価値の抜き取りが可能になります。 再編成はまた、特定のトランザクションが正規チェーンに追加されないようにするために用いられる場合もあり、これは一種の検閲を目指すものだと言えます。 再編成攻撃のうち最も極端なものは「ファイナリティの取消」であり、すでにファイナライズされたブロックを除去／置換するものです。 この攻撃では、攻撃者はステーキングされたイーサの合計のうち3分の1以上を破壊しなければなりません。この保証を「経済的なファイナリティ」と呼びますが、詳細については以下で説明します。 +「再編成」とは、ブロックの順番が変更されるようにシャッフルすることであり、正規チェーンに新たなブロックを追加したり、既存のブロックが削除される場合が多いです。 悪意に基づく再編成は特定のブロックを追加／削除することを目的とする場合があり、トランザクションをフロントランニング／バックランニングすることで、二重支出や価値の抜き取りが可能になります。 再編成はまた、特定のトランザクションが正規チェーンに追加されないようにするために用いられる場合もあり、これは一種の検閲を目指すものだと言えます。 再編成攻撃のうち最も極端なものは「ファイナリティの取消」であり、すでにファイナライズされたブロックを除去／置換するものです。 この攻撃では、攻撃者はステーキングされたイーサの合計のうち3分の1以上を破壊しなければなりません。この保証を「経済的なファイナリティ」と呼びますが、詳細については以下で説明します。 **二重ファイナリティ**とは、2つのフォークが同時にファイナライズ可能な状態に置かれ、チェーンに永続的な亀裂が生じるもので、発生確率は低いですが非常に深刻な状況だと言えます。 理論的には、攻撃者がステーキングされたETH全体の34%を失っても構わないと考える場合にこの状態が発生可能になります。 ユーザーコミュニティは、オフチェーンでの議論を通じてどのチェーンに従うかを決定することを迫られますので、ソーシャルレイヤーの強じんさが求められます。 @@ -22,7 +22,7 @@ lang: ja ソーシャルレイヤーに対する攻撃は、イーサリアムに対する世間の信頼を毀損するため、イーサの価値や利用度を引き下げるため、あるいは、イーサリアム・コミュニティを弱体化させることにより、帯域外の連携を妨害することを目的とするかもしれません。 -以上が、攻撃者がイーサリアムを攻撃する理由として考えられるものです。以下のセクションでは、これらの攻撃を_どのように実行するか_について検討します。 +以上が、攻撃者がイーサリアムを攻撃する理由として考えられるものです。以下のセクションでは、これらの攻撃を _どのように_ 実行するかについて検討します。 ## さまざまな攻撃手段 {#methods-of-attack} @@ -31,10 +31,13 @@ lang: ja まず、イーサリアム・ネットワークへの積極的な関与（クライアント・ソフトウェアを実行すること）を行わない攻撃者は、ソーシャルレイヤー（レイヤー0）を標的とする攻撃を行う可能性があります。 レイヤー0は、イーサリアム・ネットワークを構築するための土台であり、攻撃対象となった場合はその影響がスタックの他の部分に波及しかねません。 具体的には、以下のような攻撃が考えられます： - 虚偽情報を流布するキャンペーンを行うことで、ユーザーコミュニティにおけるイーサリアムのロードマップ、開発者チーム、アプリ等に対する信頼を失わせる攻撃。 この攻撃は、イーサリアム・ネットワークのセキュリティを維持するために参加するユーザーの数を減少させることで、分散化および暗号経済的なセキュリティを低下させる意図を持ちます。 + - 開発者コミュニティに対する標的を絞った攻撃および／または脅迫。 この攻撃により、開発者が自発的にコミュニティから退去し、イーサリアムの開発速度が遅れる可能性があります。 - 必要以上に規制を厳しくすることも、イーサリアムへの参加者数や利用度を大きく引き下げる可能性を持つため、レイヤー0に対する攻撃と見なすことが可能です。 + - 関連知識を持つ悪意のアクターが開発者コミュニティに侵入する場合。ここでの目的は、些末な議論を繰り広げたり、重要な判断を遅らせたり、スパムを送信するなどの方法により、イーサリアムの開発を遅らせることです。 + - イーサリアムのエコシステムに含まれるキープレイヤーに対して賄賂を提供して、意思決定に影響を及ぼそうとする行為。 これらの攻撃がとりわけ危険な理由は、ごくわずかな資本あるいは技術的ノウハウしか持たない者でも実行が可能である場合が多いためです。 レイヤー0攻撃は、暗号経済的な攻撃の被害をさらに拡大する可能性があります。 例えば、悪意のある多数派のステークホルダーにより検閲やファイナリティの撤回が達成された場合、ソーシャルレイヤーが弱体化していれば、帯域外においてユーザーコミュニティ全体が団結して対応することが難しくなるかもしれません。 @@ -55,9 +58,9 @@ lang: ja #### 再編成 {#reorgs} -ステーキングされたイーサ全体のごく一部を用いて、チェーンの再編成またはファイナリティの遅延を実行するという攻撃については、すでにいくつかのペーパーにより詳説されています。 これらの攻撃は通常、攻撃者以外のバリデータに対して一部の情報を秘匿しておき、特定のニュアンスを持つ方法で、および／または攻撃者にとって有利な時点で、その情報を公開するという手段を用います。 攻撃者は通常、一部の誠実なブロック（複数の場合あり）を正規チェーンから削除することを目的とします。 [ノイダー他（2020年）](https://arxiv.org/pdf/2102.02247.pdf)の論文では、攻撃者であるバリデータが特定のスロット `n+1` に対してブロック(`B`) を作成し、アテステーションを実行しつつ、ネットワークの他のノードへの送信を控える方法について説明しています。 攻撃者は、アテステーションを実行したブロックを次のスロット（`n+2`まで公開せずに残しておきます。 誠実なバリデータは、あるブロック（`C`）を`n+2`スロットに提案します。 攻撃者は、これとほぼ同時に、秘匿していたブロック（`B`）およびこれに対するアテステーションをリリースし、さらに、十分な投票権と共にスロット`n+2`におけるチェーンの先頭が`B`であるというアテステーションを実行することで、誠実なブロック`C`の存在を事実上否定することができます。 誠実なブロック `D` がリリースされると、フォーク選択アルゴリズムにより、ブロック`B`上で構築された`D`の方が、ブロック`C`上で構築されたブロック`D`よりも重みが大きいと判断します。 つまり攻撃者は、1つ後のブロックにおけるチェーンの再編成により、スロット`n+2`における誠実なブロック`C`を正規チェーンから削除することが可能になるのです。 [攻撃者がステーク全体の34%を保有する場合](https://www.youtube.com/watch?v=6vzXwwk12ZE)、[この注記](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)で述べられているように、この攻撃が成功する可能性は非常に高いと言えます。 さらに、理論的にはより少ない割合のステークでもこの攻撃を試みることが可能です。 [ノイダー他（2020年）](https://arxiv.org/pdf/2102.02247.pdf)では、この攻撃は30%ステークでも可能だと述べていますが、その後の研究により、[ステーク全体のわずか2%](https://arxiv.org/pdf/2009.04987.pdf)を保有するだけでこの攻撃が可能であると判明しました。この場合、[単独のバリデータ](https://arxiv.org/abs/2110.10086#)によるバランシングのテクニックが用いられますが、これについては以下のセクションで検証します。 +ステーキングされたイーサ全体のごく一部を用いて、チェーンの再編成またはファイナリティの遅延を実行するという攻撃については、すでにいくつかの論文により詳説されています。 これらの攻撃は通常、攻撃者以外のバリデータに対して一部の情報を秘匿しておき、特定のニュアンスを持つ方法で、および／または攻撃者にとって有利な時点で、その情報を公開するという手段を用います。 攻撃者は通常、一部の誠実なブロック（複数の場合あり）を正規チェーンから削除することを目的とします。 [ノイダー他（2020年）の論文](https://arxiv.org/pdf/2102.02247.pdf)では、攻撃者であるバリデータが特定のスロット `n+1` に対してブロック(`B`) を作成し、アテステーションを実行しつつ、ネットワークの他のノードへの送信を控える方法について説明しています。 攻撃者は、アテステーションを実行したブロックを次のスロット（`n+2`まで公開せずに残しておきます。 誠実なバリデータは、あるブロック（`C`）を`n+2`スロットに提案します。 攻撃者は、これとほぼ同時に、秘匿していたブロック（`B`）およびこれに対するアテステーションをリリースし、さらに、十分な投票権と共にスロット`n+2`におけるチェーンの先頭が`B`であるというアテステーションを実行することで、誠実なブロック`C`の存在を事実上否定することができます。 誠実なブロック`D`がリリースされると、フォーク選択アルゴリズムにより、ブロック`B`上で構築された`D`の方が、ブロック`C`上で構築されたブロック`D`よりも重みが大きいと判断します。 つまり攻撃者は、1つ後のブロックにおけるチェーンの再編成により、スロット`n+2`における誠実なブロック`C`を正規チェーンから削除することが可能になるのです。 [攻撃者がステーク全体の34%を保有する場合](https://www.youtube.com/watch?v=6vzXwwk12ZE) 、[この注記](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)で述べられているように、この攻撃が成功する可能性は非常に高いと言えます。 さらに、理論的にはより少ない割合のステークでもこの攻撃を試みることが可能です。 [ノイダー他（2020年）](https://arxiv.org/pdf/2102.02247.pdf)では、この攻撃は30%ステークでも可能だと述べていますが、その後の研究により、[ステーク全体のわずか2%](https://arxiv.org/pdf/2009.04987.pdf)を保有するだけでこの攻撃が可能であると判明しました。この場合、[単独のバリデータ](https://arxiv.org/abs/2110.10086#) によるバランシングのテクニックが用いられますが、これについては以下のセクションで検証します。 -![事前の再編成](reorg-schematic.png) +![事前reorg](reorg-schematic.png) 上記の1ブロック後の再編成攻撃の概念図 (https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair を修正) @@ -67,7 +70,7 @@ lang: ja -バランシング攻撃およびバウンス攻撃のいずれも、ネットワークにおけるメッセージ送信のタイミングを攻撃者が非常に細かく制御できなければならず、実際に発生する可能性は高くありません。 攻撃の可能性は低いものの、これらの攻撃に対する防御手段として、プロトコルにおいては迅速なメッセージがよりメッセージよりも重みが大きくなるように設定されています。 これは、[提案者重みブースティング](https://github.com/ethereum/consensus-specs/pull/2730)と呼ばれています。 また、バウンス攻撃を回避するため、正当化された最新のチェックポイントを代替のチェーンに切り替えできる時期が[エポック全体の前半3分の1のスロット](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)のみとなるようにフォーク選択アルゴリズムが修正されました。 この条件により、攻撃者が後で投票するための投票権を蓄積することが不可能になりました。フォーク選択アルゴリズムは、大部分の誠実なバリデータが投票するであろう各エポックの前半3分の1の時間内において選択されたチェックポイントをそのまま選択し続けるからです。 +バランシング攻撃およびバウンス攻撃のいずれも、ネットワークにおけるメッセージ送信のタイミングを攻撃者が非常に細かく制御できなければならず、実際に発生する可能性は高くありません。 攻撃の可能性は低いものの、これらの攻撃に対する防御手段として、プロトコルにおいては迅速なメッセージがよりメッセージよりも重みが大きくなるように設定されています。 これは、[提案者加重ブースティング](https://github.com/ethereum/consensus-specs/pull/2730)と呼ばれています。 また、バウンス攻撃を回避するため、正当化された最新のチェックポイントを代替のチェーンに切り替えできる時期が[エポック全体の前半3分の1のスロット](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)のみとなるようにフォーク選択アルゴリズムが修正されました。 この条件により、攻撃者が後で投票するための投票権を蓄積することが不可能になりました。フォーク選択アルゴリズムは、大部分の誠実なバリデータが投票するであろう各エポックの前半3分の1の時間内において選択されたチェックポイントをそのまま選択し続けるからです。 これらの対策を組み合わせた場合、誠実なブロック提案者が各スロットの開始時点でただちにブロックを送信するが、スロットの前半3分の1（4秒間）においては、新規ブロックの生成によりフォーク選択アルゴリズムを通じて他のチェーンへの切り替えが可能な状態が発生するというシナリオが想定されます。 この締切時間が到来した後は、作業が遅いバリデータから送信されたアテステーションは、作業が早いバリデータからのアテステーションよりも重みが小さくなるのです。 これにより、チェーンの先頭を決定する作業において迅速に行動した提案者およびバリデータが有利になるため、バランシング攻撃やバウンス攻撃が成功する確率を大きく引き下げることができます。 @@ -81,23 +84,23 @@ lang: ja アバランチ攻撃の脅威は、LMD-GHOSTというフォーク選択アルゴリズムのLMDによって軽減されます。 LMDとは、「最新メッセージ主導型」を意味し、各バリデータが維持し、他のバリデータから受信する最新のメッセージが含まれている表を指しています。 このフィールドが更新されるのは、各バリデータの表においてすでに記入済みであるスロットよりも後のスロットにおいて新規メッセージを受信した場合のみです。 これにより、実際には各スロットにおいて最初に受信されたメッセージが認証され、その後のすべてのメッセージは曖昧化をもたらすものとして却下されます。 つまり、コンセンサス・クライアントは曖昧化をもたらすメッセージを考慮せず、各バリデータから最初に受信したメッセージのみを採用し、その後の曖昧化させるメッセージは単に無視されるため、アバランチ攻撃が不可能になります。 -提案者の重み追加が提供するセキュリティをさらに強めるために、フォーク選択ルールに対しては今後もいくつかのアップデート案が検討されています。 そのうちの1つが [ビュー・マージ](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739)であり、アテステーションを行うユーザーは、各自のフォーク選択のビューが当該スロットが開始される`n`秒前にフリーズされるため、提案者はネットワーク全体にわたるチェーンビューを同期しやすくなります。 もう1つのアップグレード案は、 [シングルスロット・ファイナリティ](https://notes.ethereum.org/@vbuterin/single_slot_finality)であり、1スロット後にチェーンをファイナライズすることにより、メッセージを送信するタイミングに基づいた攻撃を回避するというものです。 +提案者の重み追加が提供するセキュリティをさらに強めるために、フォーク選択ルールに対しては今後もいくつかのアップデート案が検討されています。 そのうちの1つが[ビュー・マージ](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739)であり、アテステーションを行うユーザーは、各自のフォーク選択のビューが当該スロットが開始されるn秒前にフリーズされるため、提案者はネットワーク全体にわたるチェーンビューを同期しやすくなります。 もう1つのアップグレード案は、 [シングルスロット・ファイナリティ](https://notes.ethereum.org/@vbuterin/single_slot_finality)であり、1スロット後にチェーンをファイナライズすることにより、メッセージを送信するタイミングに基づいた攻撃を回避するというものです。 #### ファイナリティ遅延 {#finality-delay} -低コストで単一ブロックを対象とする再編成攻撃について説明したのと[同じ論文](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf)では、さらに、攻撃者がエポックの境界となるブロックの提案者となることで実行可能になるファイナリティ遅延（「生存性障害」とも呼ばれます）攻撃についても説明されています。 この攻撃が非常に重要であるのは、エポック境界ブロックはキャスパーFFGがチェーンの各部分をファイナライズするために参照するチェックポイントになるためです。 攻撃者は、ひとつ前のエポック境界ブロックを現在のファイナライズ対象にすることを支持する誠実なバリデータによる投票が十分に集まるまで、自分のブロックを保留するだけでよいのです。 攻撃者はその上で、保留してきたブロックをリリースします。 彼らは自らのブロックに対するアテステーションを実行し、攻撃者以外の誠実なバリデータも同様に実行するので、ターゲットのチェックポイントが異なる複数のフォークが作成されてしまうのです。 適切なタイミングで実行された場合、いずれのフォークに対するアテステーションにおいても3分の2のスーパーマジョリティを得られないため、ファイナリティを実現できなくなります。 この場合、ステークの規模が小さければ小さいほど、攻撃が成功する実行のタイミングが狭まります。と言うのも、攻撃者が直接支配するアテステーションの数がより少なくなり、特定のエポック境界ブロックを提案するバリデータを攻撃者が支配する可能性が低くなるからです。 +低コストで単一ブロックを対象とする再編成攻撃について説明したのと[同じ論文](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) では、さらに、攻撃者がエポックの境界となるブロックの提案者となることで実行可能になるファイナリティ遅延（「生存性障害」とも呼ばれます）攻撃についても説明されています。 この攻撃が非常に重要であるのは、エポック境界ブロックはキャスパーFFGがチェーンの各部分をファイナライズするために参照するチェックポイントになるためです。 攻撃者は、ひとつ前のエポック境界ブロックを現在のファイナライズ対象にすることを支持する誠実なバリデータによる投票が十分に集まるまで、自分のブロックを保留するだけでよいのです。 攻撃者はその上で、保留してきたブロックをリリースします。 彼らは自らのブロックに対するアテステーションを実行し、攻撃者以外の誠実なバリデータも同様に実行するので、ターゲットのチェックポイントが異なる複数のフォークが作成されてしまうのです。 適切なタイミングで実行された場合、いずれのフォークに対するアテステーションにおいても3分の2のスーパーマジョリティを得られないため、ファイナリティを実現できなくなります。 この場合、ステークの規模が小さければ小さいほど、攻撃が成功する実行のタイミングが狭まります。と言うのも、攻撃者が直接支配するアテステーションの数がより少なくなり、特定のエポック境界ブロックを提案するバリデータを攻撃者が支配する可能性が低くなるからです。 #### ロングレンジ攻撃 {#long-range-attacks} プルーフ・オブ・ステークを採用したブロックチェーン特有のもう一つの攻撃カテゴリーとして、ジェネシスブロックの作成に関与したバリデータが誠実なチェーンとは異なる別途のフォークを維持し、最終的に誠実なバリデータ群に対し、かなりの時間を経た適当なタイミングで代替フォークに移行するように説得するという手法があります。 イーサリアムにおいては、ファイナリティ・ガジェットによりすべてのバリデータが誠実なチェーンについて定期的な感覚（「チェックポイント」）において同意する必要があるため、この種の攻撃は実行できません。 このシンプルなメカニズムによりイーサリアムのクライアントにおいてはファイナライズされたブロックの再編成が不可能であり、ロングレンジ攻撃は無効化されます。 イーサリアム・ネットワークに新たに参加するノードは、信頼できる最新状態のハッシュ（「[弱い主観性](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)チェックポイント」）を見つけ、このチェックポイントを疑似的なジェネシスブロックとして、その上に新たなブロックを作成します。 この方法により、新たにネットワークに参加するノードに対して「信頼性ゲートウェイ」が提供され、ノード自身が情報を検証できるようになります。 -#### サービス拒否 (DOS) {#denial-of-service} +#### サービス拒否 (DOS) {#denial-of-service} -イーサリアムにおけるプルーフ・オブ・ステークのメカニズムでは、すべてのバリデータの中から、各スロットにおけるブロック提案者として1名のバリデータを選出します。 この選出は公開された関数を用いて計算できるため、攻撃者は、ブロック提案のタイミングをわずかに先立つ時点で次のブロック提案者を特定することが可能です。 攻撃者はこの情報を得ることで、次のブロック提案者にスパムを送信し、他のピアとの情報交換を妨げることができます。 ネットワークの他のユーザーにとっては、次のブロック提案者がオフラインになり、スロットは空のままであるように見えます。 これは、特定のバリデータを対象とする一種の検閲として機能させることができ、それらのユーザーがブロックチェーンに情報を追加するのを妨害することが可能です。 単独非公開リーダー選挙（SSLE）あるいは非単独非公開リーダー選挙を実施する場合、当該のブロック提案者自身のみが提案者に選出されたことを知ることができ、選出を事前に知ることが不可能になるため、DoSリスクを軽減することができます。 このようなメカニズムはまだ実装されていませんが、積極的な[研究開発](https://ethresear.ch/t/secret-non-single-leader-election/11789)が進められています。 +イーサリアムにおけるプルーフ・オブ・ステークのメカニズムでは、すべてのバリデータの中から、各スロットにおけるブロック提案者として1名のバリデータを選出します。 この選出は公開された関数を用いて計算できるため、攻撃者は、ブロック提案のタイミングをわずかに先立つ時点で次のブロック提案者を特定することが可能です。 攻撃者はこの情報を得ることで、次のブロック提案者にスパムを送信し、他のピアとの情報交換を妨げることができます。 ネットワークの他のユーザーにとっては、次のブロック提案者がオフラインになり、スロットは空のままであるように見えます。 これは、特定のバリデータを対象とする一種の検閲として機能させることができ、それらのユーザーがブロックチェーンに情報を追加するのを妨害することが可能です。 単独非公開リーダー選挙（SSLE）あるいは非単独非公開リーダー選挙を実施する場合、当該のブロック提案者自身のみが提案者に選出されたことを知ることができ、選出を事前に知ることが不可能になるため、DoSリスクを軽減することができます。 これはまだ実装されていませんが、活発な[研究開発](https://ethresear.ch/t/secret-non-single-leader-election/11789)分野です。 以上の説明はすべて、ステークが小規模なユーザーがイーサリアムへの攻撃を成功させることが非常に困難であることを示しています。 ここで紹介した実行可能な攻撃はいずれも、理想的なフォーク選択アルゴリズム、非現実的なネットワーク状況、あるいはクライアント・ソフトウェアに対する比較的小規模なパッチ修正によりすでに実行不可能になった攻撃ベクトルを前提としています。 もちろん、ゼロデイ攻撃が発生する可能性を否定することはできませんが、小規模のステークに基づく攻撃が成功するためには、非常に高い水準の技術的な能力、コンセンサスレイヤーに関する知識、および運が要求されることを示しています。 攻撃者の立場で考えた場合、できるだけ多くのイーサを蓄積した上で、ステーク全体に対する支配力を高めることが攻撃の成功率を高める最善の手段だと言うことになるでしょう。 -### >= 33%のステークを用いた攻撃 {#attackers-with-33-stake} +### ステーク全体の33%以上を支配する攻撃者の場合 {#attackers-with-33-stake} これまでに紹介したすべての攻撃手段は、攻撃者が投票できるステークの規模を大きくし、各スロットでブロックを提案するバリデータとして選出される可能性が高まるほど、成功する確率が高まります。 従って、悪意のバリデータはできる限り多くのステーキングされたイーサを支配しようとするでしょう。 @@ -107,11 +110,11 @@ lang: ja イーサリアム・ネットワークが非同期型である（つまり、メッセージの送受信に遅延が生じる）と想定すると、ステーク全体の34%を支配する攻撃者は二重ファイナリティを発生させることができます。 これは、攻撃者がブロック作成者に選出された場合、曖昧化を実行し、支配するバリデータ全員と共に二重投票が可能になるからです。 これは、ブロックチェーンに分岐が発生し、それぞれのフォークに対してステークされたイーサの34%が投票するという事態を招きます。 各フォークがスーパーマジョリティの支持を得るには、残りのバリデータのうち50%の投票を得ればよいので、どちらのチェーンもファイナライズが可能になってしまいます（つまり、攻撃者であるバリデータの34%と、残余のバリデータの66%の半分を足すと、各フォークが67%を達成できます）。 競合するブロックは誠実なバリデータのうちおよそ50%の投票を得る必要があるので、この攻撃が成功するためには、ネットワークにメッセージが伝播される他ミングを攻撃者がある程度管理でき、誠実なバリデータを各チェーンに半分づつ振り分けられなければなりません。 攻撃者がこの二重ファイナリティを達成するには、支配下である34%のバリデータは二重投票を同時に実行する必要があり、これは最大の相関ペナルティが科せられるスラッシング対象の違反行為であるため、攻撃者のステーク全体（現在、バリデータによる合計ステークはおよそ1,000万イーサなので、その34%）を破壊する必要があります。 この攻撃に対する防御策は、ステークされたイーサ全体の34%を破壊することであるため、非常に大きなコストを伴います。 この攻撃から復旧するには、イーサリアム・コミュニティ全体が「帯域外」で連携し、フォークの一方を正当として、もう一方を破棄することに同意する必要があります。 -### ステーク全体の最大50%を支配する攻撃者の場合 {#attackers-with-50-stake} +### ステーク全体の最大50%を支配する攻撃者の場合 {#attackers-with-50-stake} 悪意のバリデータ集団がステークされたイーサ全体の50%に対する支配力を持つ場合、理論的にはチェーンを同サイズの2つのフォークに分割し、彼らが持つ50%のステーク全体を用いて誠実なバリデータ群とは異なる投票を行うことで、2つのフォークが存在する状態を維持し、ファイナリティの実現を妨げることができます。 最終的には、両方のフォークに対するインアクティブ・リークを実行することで、両方のチェーンがファイナライズされることになるでしょう。 この場合は、ソーシャルリカバリーの力に頼るしかありません。 -誠実なバリデータ数やネットワーク遅延などの値が常に流動的であることを考慮すると、悪意のバリデータ集団がステーク全体に対して正確に50%の支配権を維持できる可能性はきわめて低く、このような攻撃の実行は非常にコストが高く、成功率が低いことを考えると、特にわずかな追加投資により50%_以上_のステークを取得すればさらに大きな攻撃力を得られることを考えると、合理的な攻撃者がこの手段を講じる可能性は少ないと言えるでしょう。 +誠実なバリデータ数やネットワーク遅延などの値が常に流動的であることを考慮すると、悪意のバリデータ集団がステーク全体に対して正確に50%の支配権を維持できる可能性はきわめて低く、このような攻撃の実行は非常にコストが高く、成功率が低いことを考えると、特にわずかな追加投資により _50%以上_ のステークを取得すればさらに大きな攻撃力を得られることを考えると、合理的な攻撃者がこの手段を講じる可能性は少ないと言えるでしょう。 攻撃者がステーク合計の50%以上を支配する場合、フォーク選択アルゴリズムを操作することが可能になります。 この場合、攻撃者は多数派の投票に基づくアテステーションが可能になるため、誠実なクライアントを騙す必要なしに、ショートレンジの再編成攻撃を実行するために十分な支配権を持つことになります。 この場合、誠実なバリデータも、彼らのフォーク選択アルゴリズムが攻撃者の選好チェーンの重みが最も大きいと判断するために攻撃者の支持に従い、チェーンがファイナライズ可能になります。 攻撃者は、このメカニズムを通して特定のトランザクションに対する検閲やショートレンジの再編成攻撃を実行することで、自らが有利になるようにブロックを再編成し、最大限のMEVを抽出することが可能になります。 この攻撃を防ぐには、ソーシャルレイヤーの介入により、誠実な少数派フォークを正当と認識することで、攻撃者のステークが持つ価値を大幅に引き下げる必要がありますが、これは同時に多数派のステーク全体（現時点の価値は190億米ドル弱）を攻撃のリスクに晒すことを意味します。 @@ -127,13 +130,13 @@ lang: ja さらに、攻撃者に科されるペナルティがどのようなものであれ、ユーザーコミュニティ全体が、イーサリアム・クライアントに搭載されたフォーク選択アルゴリズムにより選好されているが不正であるチェーンにつき、実際にそれが不正なチェーンであり、誠実なチェーン上でのブロック生成に戻るべきだということを決定しなければなりません。 誠実なバリデータ群は、攻撃が開始される前に正規チェーンから分岐した、ユーザーコミュニティが承認したイーサリアム・ブロックチェーンのフォークにおいて今後の開発を継続するか、あるいは、攻撃者の支配下にあるバリデータを強制的に排除するかについて、集団的に同意することが可能でしょう。 誠実なバリデータは、攻撃者のチェーンに対するアテステーションを実行しないという正しい行動に対してペナルティが科せられるのを避けたいと考えるため、この正規チェーンで開発を続行するインセンティブが存在します。 イーサリアム上で開発された取引所、オンランプ、およびアプリケーションは、誠実なチェーン上での利用を望むと予想されるので、誠実なバリデータの決定に従って誠実なブロックチェーンを選択するでしょう。 -しかし、これはガバナンス上の大きな問題をもたらします。 一部のユーザーおよびバリデータは誠実なチェーンへの再移行に伴い確実に自分の資産を失うことになり、攻撃後に確定したブロック内のトランザクションはロールバックされる可能性がありあるため、アプリケーションレイヤーにおいて混乱が発生します。つまり、「コードは法である」という確信が強い一部のユーザーの倫理観が揺らいでしまうのです。 取引所およびアプリケーションにおいては、すでにオフチェーンにおけるアクションをオンチェーンのトランザクションとを関連付けている可能性が高く、オンチェーンのトランザクションをロールバックするとなると、取消や修正が相次ぐことになりますが、特に不正に獲得した利益がすでに正当な利益混合しており、DeFIやその他のデリバティブにおいて入金されている場合、誠実なユーザーに対しても二次的な影響を及ぼすため、公平な方法で元の状態に戻すのは困難になるでしょう。 おそらく組織ユーザーをも含む一部のユーザーは、意図的または偶然によりすでに不正なチェーンから何らかの利益を得ているはずであり、この利益を守るために正規フォークへの再移行に反対するかもしれません。 コミュニティ全体の連携に基づく賢明なリスク軽減策を迅速に実行できる体制を整えておくために、51%攻撃に対するコミュニティ全体の対応をリハーサルするべきだという声も多いです。 ヴィタリクによるethresear.chでの有益な議論については、[こちら](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925)と[こちら](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363)、そしてTwitterの[こちら](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)でご確認ください。 コミュニティ全体が連携したソーシャル対応は、攻撃者を罰し、他のユーザーへの影響を最小化するという具体的な目的に絞り込む必要があります。 +しかし、これはガバナンス上の大きな問題をもたらします。 一部のユーザーおよびバリデータは誠実なチェーンへの再移行に伴い確実に自分の資産を失うことになり、攻撃後に確定したブロック内のトランザクションはロールバックされる可能性がありあるため、アプリケーションレイヤーにおいて混乱が発生します。つまり、「コードは法である」という確信が強い一部のユーザーの倫理観が揺らいでしまうのです。 取引所およびアプリケーションにおいては、すでにオフチェーンにおけるアクションをオンチェーンのトランザクションとを関連付けている可能性が高く、オンチェーンのトランザクションをロールバックするとなると、取消や修正が相次ぐことになりますが、特に不正に獲得した利益がすでに正当な利益混合しており、DeFIやその他のデリバティブにおいて入金されている場合、誠実なユーザーに対しても二次的な影響を及ぼすため、公平な方法で元の状態に戻すのは困難になるでしょう。 おそらく組織ユーザーをも含む一部のユーザーは、意図的または偶然によりすでに不正なチェーンから何らかの利益を得ているはずであり、この利益を守るために正規フォークへの再移行に反対するかもしれません。 コミュニティ全体の連携に基づく賢明なリスク軽減策を迅速に実行できる体制を整えておくために、51%攻撃に対するコミュニティ全体の対応をリハーサルするべきだという声も多いです。 ヴィタリクによるethresear.chでの有益な議論については、[こちら](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) と[こちら](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363)、そしてTwitterの[こちら](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)でご確認ください。 コミュニティ全体が連携したソーシャル対応は、攻撃者を罰し、他のユーザーへの影響を最小化するという具体的な目的に絞り込む必要があります。 -ブロックチェーンのガバナンスは、それ自体が複雑なトピックです。 不正なバリデータがファイナライズしてしまったチェーンに対するレイヤー0の緊急対応をいかに管理するかは、イーサリアムコミュニティにとって間違いなく大きな課題であり、イーサリアムの歴史において、すでに[2回](/ethereum-forks/#dao-fork-summary)[も発生しています](/ethereum-forks/#tangerine-whistle)。 +ブロックチェーンのガバナンスは、それ自体が複雑なトピックです。 不正なバリデータがファイナライズしてしまったチェーンに対するレイヤー0の緊急対応をいかに管理するかは、イーサリアムコミュニティにとって間違いなく大きな課題であり、イーサリアムの歴史において、すでに[2回](/ethereum-forks/#tangerine-whistle)も[発生](/ethereum-forks/#dao-fork-summary)しています。 しかしながら、最悪の事態においても現実世界において解決策を見出せるという事実には、やや安堵感を覚えます。 究極的に、私たちが利用しているこの驚くべきテクノロジースタックにおいても、最悪の事態が発生した場合には、ユーザーである実際の人間たちが議論を通じて解決策を見出すしかないのです。 -## 要約 {#summary} +## まとめ {#summary} この記事では、イーサリアムにおけるプルーフ・オブ・ステークのコンセンサス・プロトコルを悪用する攻撃手法のいくつかについて説明しました。 攻撃者のステークがイーサ全体に対してどの程度の割合を占めるかに応じて、再編成攻撃やファイナリティ遅延攻撃がどのように変化するのかについても掘り下げました。 一般論として、資金が潤沢である攻撃者は、より大きな投票権を持ち、以後のブロックの内容に対して影響力を及ぼせるため、攻撃が成功する可能性が高まります。 攻撃者の攻撃能力は、ステークしたイーサの割合が特定のしきい値を越えるに従って増加します： @@ -151,13 +154,13 @@ lang: ja 一方で、34%攻撃、51%攻撃、あるいは66%攻撃に対しては帯域外のソーシャルな連携による解決が必要になる場合が多いです。 これはユーザーコミュニティにとって痛みを伴うものですが、帯域外での連携による対応が可能だという事実は、攻撃者にとって大きな抑止効果を持ちます。 イーサリアムのソーシャルレイヤーは最終的な防御手段であり、攻撃が技術的に成功した場合でも、コミュニティが誠実なフォークを選択することに同意できれば、攻撃を無力化することができます。 これは、攻撃者とイーサリアム・コミュニティとの間の争いとなるでしょう。つまり、66%攻撃を実行するために数十億ドルもの資金を投じたとしても、ソーシャル連携を通じて反撃を迅速に実行できれば、攻撃者は、イーサリアム・コミュニティにとって無意味である既知の不正チェーンにステークされた、換金不可能なイーサを背負い込むことになるだけだからです。 攻撃者にとってはこの攻撃から利益を上げられる可能性が非常に低くなるため、事実上の効果的な抑止力として機能します。 これこそ、緊密に連携した価値観に基づき、団結力を持つソーシャルレイヤーを維持するために投資することが重要である理由です。 -## さらに学びたい方へ {#further-reading} +## 参考リンク {#further-reading} - [本記事の詳細版](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) - [ヴィタリックによる決済のファイナリティに関する説明](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) -- [LMD-GHOSTについての論文](https://arxiv.org/abs/2003.03052) -- [Casper-FFGについての論文](https://arxiv.org/abs/1710.09437) -- [ガスパーについての論文](https://arxiv.org/pdf/2003.03052.pdf) -- [提案者の加重ブーストに関するコンセンサス仕様](https://github.com/ethereum/consensus-specs/pull/2730) -- [ethresear.chに対するバウンス攻撃](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) -- [SSLEについてのリサーチ](https://ethresear.ch/t/secret-non-single-leader-election/11789) +- [LMD GHOSTの論文](https://arxiv.org/abs/2003.03052) +- [Casper-FFG ペーパー](https://arxiv.org/abs/1710.09437) +- [Gasperの論文](https://arxiv.org/pdf/2003.03052.pdf) +- [提案者加重ブーストのコンセンサス仕様](https://github.com/ethereum/consensus-specs/pull/2730) +- [バウンス攻撃(ethresear.ch)](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) +- [SSLEの研究](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attestations/index.md index 49ade6239c0..567253cef13 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attestations/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -1,6 +1,6 @@ --- -title: アテステーション -description: イーサリアムのプルーフ・オブ・ステークにおけるアテステーションについての説明 +title: "アテステーション" +description: "イーサリアムのプルーフ・オブ・ステークにおけるアテステーションについての説明" lang: ja --- @@ -8,35 +8,35 @@ lang: ja ## アテステーションとは何か？ {#what-is-an-attestation} -バリデータは、[エポック](/glossary/#epoch) (6.4分) ごとに、ネットワークに対するアテステーションを提案します。 アテステーションは、当該エポックにおける特定のスロットのみを対象とします。 アテステーションとは、チェーンに対するバリデータの意見を支持する投票を行うことです。具体的には、最新の正当化されたブロックと、現在のエポックにおける最初のブロック（それぞれ、`ソース`と`ターゲット`のチェックポイントと呼ぶ）を対象とします。 この情報は、参加するすべてのバリデータを対象として結合されるため、ネットワークがブロックチェーンの状態についてコンセンサスに達することが可能になります。 +[エポック](/glossary/#epoch) (6.4分) ごとに、バリデータはネットワークにアテステーションを提案します。 アテステーションは、当該エポックにおける特定のスロットのみを対象とします。 アテステーションの目的は、バリデータのチェーン観、特に最新の正当化されたブロックと、現在のエポックの最初のブロック (`source` と `target` のチェックポイントとして知られる) に賛成票を投じることです。 この情報は、参加するすべてのバリデータを対象として結合されるため、ネットワークがブロックチェーンの状態についてコンセンサスに達することが可能になります。 アテステーションには、以下の構成要素が含まれます： -- `aggregation_bits`：バリデータ委員会における当該バリデータのインデックスにポジションがマッピングされたバリデータのビットリスト。この値（0または1）は、当該バリデータが当該`データ`を署名したか否か（つまり、当該バリデータがアクティブであり、ブロック提案者に同意するか否か）を示します。 -- `data`：当該アテステーションに関する詳細情報（以下の定義を参照）。 -- `signature`：個々のバリデータの署名を集約したBLS署名。 +- `aggregation_bits`: バリデータのビットリストで、位置がその委員会におけるバリデータインデックスに対応します。値(0/1)は、バリデータが`data`に署名したかどうか(つまり、アクティブであり、ブロック提案者に同意しているかどうか)を示します。 +- `data`: 以下に定義される、アテステーションに関する詳細 +- `signature`: 個々のバリデータの署名を集約したBLS署名 -アテステーションを行うバリデータはまず、`データ<./code>を構築する必要があります。 このデータ`には、以下の情報が含まれます： +アテステーションを行うバリデータの最初のタスクは、`data`を構築することです。 `data`には以下の情報が含まれます: -- `slot`：当該のアテステーションが参照するスロット番号。 -- `index`：特定のスロットにおいて、当該バリデータが所属する委員会を特定する番号。 -- `beacon_block_root`：当該バリデータが、（フォーク選択アルゴリズムを適用した結果として）チェーンの先頭にあると認識するブロックのルートハッシュ。 -- `source`：ファイナリティ投票の一部であり、当該バリデータがどのブロックを最も最近正当化されたブロックとして認識するかを示す。 -- `target`：ファイナリティ投票の一部であり、当該バリデータがどのブロックを現在のエポックにおける最初のブロックとして認識するかを示します。 +- `slot`: アテステーションが参照するスロット番号 +- `index`: 特定のスロットでバリデータが属する委員会を識別する番号 +- `beacon_block_root`: バリデータがチェーンの先頭に見るブロックのルートハッシュ(フォークチョイスアルゴリズムを適用した結果) +- `source`: バリデータが最新の正当化されたブロックとして見なすものを示すファイナリティ投票の一部 +- `target`: バリデータが現在のエポックの最初のブロックとして見なすものを示すファイナリティ投票の一部 -`data`が構築されると、バリデータは、自分が参加したことを示すために、自身のバリデータ・インデックスに対応した`aggregation_bits`のビットを0から1に変更することができます。 +`data`が構築されると、バリデータは参加したことを示すために、自身のバリデータインデックスに対応する`aggregation_bits`のビットを0から1に反転させることができます。 バリデータは最後に、このアテステーションに署名し、ネットワークに送信します。 -### アテステーションの集約 {#aggregated-attestation} +### 集約アテステーション {#aggregated-attestation} -このデータを各バリデータに提供する場合、ネットワークに対する負担が大きくなります。 このため、各バリデータからのアテステーションは、より広汎に送信する前にサブネット内で集約されます。 具体的には、各バリデータの署名を集約することで、送信されるアテステーションに当該コンセンサスの`データ`と、この`データ`に同意するすべてのバリデータの署名を結合した単一の署名が含まれるようにします。 これは、`aggregation_bits`を用いて確認することができます。aggregation_bitsは、各バリデータが所属する委員会におけるインデックス（バリデータのIDは`データ`に含まれています）であり、個々の署名に対してクエリを実行するために使用できるからです。 +このデータを各バリデータに提供する場合、ネットワークに対する負担が大きくなります。 このため、各バリデータからのアテステーションは、より広汎に送信する前にサブネット内で集約されます。 これには署名を一緒に集約することも含まれ、ブロードキャストされるアテステーションにはコンセンサス`data`と、その`data`に同意するすべてのバリデータの署名を結合して形成された単一の署名が含まれます。 これは`aggregation_bits`を使って確認できます。なぜなら、これは各バリデータの委員会におけるインデックスを提供し (委員会のIDは`data`で提供)、個々の署名を照会するために使用できるからです。 -エポックごとに、各サブネットから16のバリデータが`アグリゲータ`に選定されます。 アグリゲータは、ゴシップネットワーク上において、自身のアテステーションと同等の`データ`を持つすべてのアテステーションを収集します。 データが一致するアテステーションを送信したすべてのユーザーは、`aggregatoin_bits`に記録されます。 アグリゲータは次に、この集約されたアテステーションをより広汎なネットワークに送信します。 +各エポックで、各サブネットの16のバリデータが`aggregators`として選ばれます。 アグリゲータは、ゴシップネットワークを介して耳にする、自身のものと同等の`data`を持つすべてのアテステーションを収集します。 一致する各アテステーションの送信者は、`aggregation_bits`に記録されます。 アグリゲータは次に、この集約されたアテステーションをより広汎なネットワークに送信します。 バリデータがブロック提案者に選定されると、当該の新規ブロックにおける最新のスロットまで、各サブネットからのアテステーションを集約して、パッケージ化します。 -### アテステーション追加のライフサイクル {#attestation-inclusion-lifecycle} +### アテステーション取り込みのライフサイクル {#attestation-inclusion-lifecycle} 1. 生成 2. 伝播 @@ -46,7 +46,7 @@ lang: ja 以下の図は、アテステーションのライフサイクルの概略を示したものです。 -![アテステーションのライフサイクル](./attestation_schematic.png) +![アテステーションライフサイクル](./attestation_schematic.png) ## 報酬 {#rewards} @@ -64,29 +64,29 @@ lang: ja ベース報酬は、アテステーションを行うバリデータの数と、彼らの有効なステーク済みイーサ残高により計算されます。 -`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` +`ベース報酬 = バリデータ有効残高 x 2^6 / SQRT(全アクティブバリデータの有効残高)` -#### 追加の遅延 {#inclusion-delay} +#### 取り込み遅延 {#inclusion-delay} -各バリデータがチェーンの先頭（`ブロック n`）で投票した時点では、`ブロック n+1`はまだ提案されていません。 このため、追加されるアテステーションは当然**1ブロック後**になり、`ブロック n`がチェーンの先頭である時点で投票したすべてのバリデータのアテステーションは`ブロック n+1`に含まれることになるため、**追加の遅延**は「1」になります。 アテステーション報酬は、ベース報酬に追加遅延の値の逆数を掛け合わせて算出されるため、追加の遅延が「2」スロットに倍増した場合、アテステーション報酬は2分の1になります。 +バリデータがチェーンの先頭(`ブロックn`)に投票した時点では、`ブロックn+1`はまだ提案されていませんでした。 そのため、アテステーションは自然に**1ブロック後**に取り込まれ、`ブロックn`がチェーンヘッドであることに投票したすべてのアテステーションが`ブロックn+1`に取り込まれるため、**取り込み遅延**は1になります。 アテステーション報酬は、ベース報酬に追加遅延の値の逆数を掛け合わせて算出されるため、追加の遅延が「2」スロットに倍増した場合、アテステーション報酬は2分の1になります。 -### アテステーションで発生しうるシナリオ {#attestation-scenarios} +### アテステーションのシナリオ {#attestation-scenarios} -#### 投票を行うバリデータが欠席する場合 {#missing-voting-validator} +#### 投票バリデータの欠落 {#missing-voting-validator} バリデータがアテステーションを提出できるのは、最長で1エポックの期間です。 エポック0でアテステーションを提出しなかった場合、エポック1で提出できますが、追加遅延が発生します。 -#### アグリゲータが欠席する場合 {#missing-aggregator} +#### アグリゲータの欠落 {#missing-aggregator} -エポックごとに、合計16名のアグリゲータが存在します。 さらに、**256件のエポックを対象とする2つのサブネット**を講読するランダムなバリデータが存在し、アグリゲータが欠席する際のバックアップとして機能します。 +エポックごとに、合計16名のアグリゲータが存在します。 さらに、ランダムなバリデータが**256エポックの間、2つのサブネット**を購読し、アグリゲータが欠落した場合のバックアップとして機能します。 -#### ブロック提案者が欠席する場合 {#missing-block-proposer} +#### ブロック提案者の欠落 {#missing-block-proposer} -運が良ければ、アグリゲータがブロック提案者になる場合もあります。 ブロック提案者が欠席したためにアテステーションが追加されなかった場合、次のブロック提案者がこの集約済みのアテステーションを継承して、次のブロックに追加します。 ただし、**追加の遅延**の値が1増えます。 +運が良ければ、アグリゲータがブロック提案者になる場合もあります。 ブロック提案者が欠席したためにアテステーションが追加されなかった場合、次のブロック提案者がこの集約済みのアテステーションを継承して、次のブロックに追加します。 ただし、**取り込み遅延**は1増加します。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [Vitalikのコンセンサス仕様（注釈付）におけるアテステーションの説明](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) -- [eth2book.infoにおけるアテステーションの説明](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) +- [Vitalikの注釈付きコンセンサス仕様のアテステーション](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [eth2book.infoのアテステーション](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) -_役に立つコミュニティリソースをご存知の場合は、 このページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/block-proposal/index.md index 91fbb196266..ac3407cc2a8 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/block-proposal/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -1,24 +1,24 @@ --- -title: ブロック提案 -description: イーサリアムのプルーフ・オブ・ステークにおけるブロックの提案方法についての説明 +title: "ブロック提案" +description: "イーサリアムのプルーフ・オブ・ステークにおけるブロックの提案方法についての説明" lang: ja --- ブロックは、ブロックチェーンにおける基本的な単位です。 ブロックとは、各ノード間で受け渡しされ、合意され、各ノードのデータベースに追加される情報を区切った単位です。 このページでは、ブロックがどのように生成されるのかを説明します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -ブロックの提案は、プルーフ・オブ・ステークのプロトコルの一部です。 このページの内容を理解するためには、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)および[ブロックのアーキテクチャ](/developers/docs/blocks/)を読んでおくとよいでしょう。 +ブロックの提案は、プルーフ・オブ・ステークのプロトコルの一部です。 このページを理解するために、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)と[ブロックの構造](/developers/docs/blocks/)について読むことを推奨します。 ## 誰がブロックを生成するのか？ {#who-produces-blocks} ブロックは、バリデータのアカウントが提案します。 バリデータのアカウントは、実行クライアントおよびコンセンサス・クライアントの一部としてバリデータ・ソフトウェアを実行し、少なくともデポジット・コントラクトの残高が少なくとも32イーサ以上であるノードのオペレータが管理します。 ただし、各バリデータがすべてのブロックを提案する訳ではありません。 イーサリアムでは、時間をスロットおよびエポック単位で把握します。 1スロットは12秒であり、1エポックは32スロット（6.4分）です。 各スロットは、イーサリアムに新規ブロックを追加する期間を表します。 -### 無作為の選出 {#random-selection} +### 無作為抽出 {#random-selection} -各スロットにおいてブロックを提案するために、1名のバリデータがほぼ無作為に選出されます。 各ノードによる番号の生成が真に無作為であればノード間においてコンセンサスを実現することが不可能になるため、ブロックチェーンにおいては真の無作為性は存在しません。 むしろ、ここでの目的は、バリデータの選出プロセスを予測不可能にすることです。 イーサリアムでは、RANDAOと呼ばれるアルゴリズムを用いてバリデータ選出の無作為性を実現します。これは、ブロック提案者のハッシュと、ブロックごとに更新されるシードと混合するアルゴリズムです。 この混合された値に基づき、バリデータの全リストから特定のバリデータを選出します。 バリデータは、シードに対する特定の種類の不正操作から保護するために、2エポック前の時点で選出が確定します。 +各スロットにおいてブロックを提案するために、1名のバリデータがほぼ無作為に選出されます。 各ノードによる番号の生成が真に無作為であればノード間においてコンセンサスを実現することが不可能になるため、ブロックチェーンにおいては真の無作為性は存在しません。 むしろ、ここでの目的は、バリデータの選出プロセスを予測不可能にすることです。 イーサリアムでは、RANDAOと呼ばれるアルゴリズムを用いてバリデータ選出の無作為性を実現します。これは、ブロック提案者のハッシュと、ブロックごとに更新されるシードと混合するアルゴリズムです。 この混合値は、バリデータの全リストから当該の1名を選出するために用いられます。 バリデータは、シードに対する特定の種類の不正操作から保護するために、2エポック前の時点で選出が確定します。 -バリデータは各スロットにおいてRANDAOに追加されますが、グローバルなRANDAO値は各エポックにつき1回のみ更新されます。 次のブロック提案者のインデックスを算出するために、RANDAO値はスロット番号とミックスされ、スロットごとに固有値が得られます。 特定のバリデータが選出される確率は、単に`1/N`（`N`は、アクティブなバリデータの合計数）ではありません。 これは、各バリデータの有効なイーサ残高によって加重されるためです。 有効な残高の上限は32イーサです（つまり、`残高<32イーサ`の場合、`残高＝32イーサ`の場合よりも加重が低くなりますが、`残高>32`でああっても`残高＝32イーサ`の場合よりも加重は大きくなりません。 +バリデータは各スロットにおいてRANDAOに追加されますが、グローバルなRANDAO値は各エポックにつき1回のみ更新されます。 次のブロック提案者のインデックスを算出するために、RANDAO値はスロット番号とミックスされ、スロットごとに固有値が得られます。 特定のバリデータが選出される確率は、単に`1/N`（Nは、アクティブなバリデータの合計数）ではありません。 これは、各バリデータの有効なイーサ残高によって加重されるためです。 最大有効残高は32 ETHです（これは、`balance < 32 ETH` の場合は `balance == 32 ETH` よりも重みが低くなりますが、`balance > 32 ETH` の場合でも `balance == 32 ETH` より重みは高くならないことを意味します）。 各スロットにおいて選出されるブロック提案者は1名のみです。 通常、1名のブロック生成者が、専用のスロットにおいて1つのブロックを生成し、リリースします。 同一スロットにおいて2つのブロックを生成することはスラッシングの対象となる不正行為であり、これを「曖昧化」と呼びます。 @@ -42,28 +42,28 @@ class BeaconBlockBody(Container): execution_payload: ExecutionPayload ``` -ブロック提案者が現在のエポック番号に署名することによって作成する検証可能なランダム値を`randao_reveal`フィールドで受け取ります。 `eth1_data`は、ブロック提案者における入金コントラクトのビューに対する投票であり、入金コントラクトのマークルツリーにおけるルートと、新規の入金に対する検証を可能にする入金件数の総数が含まれています。 `graffiti`は、ブロックにメッセージを追加するための使用できるオプション項目です。 `proposer_slashings`および `attester_slashings`は、提案者によるチェーンビューに基づき、特定のバリデータがスラッシュ対象の違反行為を実行したことを証明する項目です。 `deposits`は、ブロック提案者が認識しているバリデータによる新規の入金リストであり、`voluntary_exits`は、ブロック提案者がコンセンサスレイヤーのゴシップネットワークにおいて、退出を希望する意向を確認したバリデータのリストです。 `sync_aggregate`は、どのバリデータが、以前に同期委員会（軽量のクライアントデータを担当するバリデータのサブセット）に指定されたことがあり、データの署名を実行したことがあるのかを示すベクトルです。 +`randao_reveal`フィールドは、ブロック提案者が現在のエポック番号に署名することによって作成する検証可能なランダム値を受け取ります。 `eth1_data`は、ブロック提案者における入金コントラクトのビューに対する投票であり、入金コントラクトのマークルツリーにおけるルートと、新規の入金に対する検証を可能にする入金件数の総数が含まれています。 `graffiti`は、ブロックにメッセージを追加するために使用できるオプションのフィールドです。 `proposer_slashings`および`attester_slashings`は、提案者のチェーンビューに基づき、特定のバリデータがスラッシュ対象の違反行為を実行したことを証明するフィールドです。 `deposits`は、ブロック提案者が認識しているバリデータによる新規の入金リストであり、`voluntary_exits`は、ブロック提案者がコンセンサスレイヤーのゴシップネットワークにおいて、退出を希望する意向を確認したバリデータのリストです。 `sync_aggregate`は、どのバリデータが、以前に同期委員会（軽量のクライアントデータを担当するバリデータのサブセット）に指定されたことがあり、データの署名を実行したことがあるのかを示すベクトルです。 -`execution_payload`は、トランザクションに関する情報が実行クライアントとコンセンサス・クライアントとの間で受け渡されることを可能にします。 `execution_payload`は、ビーコンブロック内にネスティングされるブロックの実行データです。 `execution_payload`内の各フィールドは、イーサリアムのイエローペーパーで概説されたブロックの構造を反映しています。ただし、オマーブロックを含まず、`難易度`の代わりに`prev_randao`を含む点が異なります。 実行クライアントは、自身のゴシップネットワークで耳にしたトランザクションのローカルプールにアクセスすることができます。 これらのトランザクションはローカルで実行され、ポストステートと呼ばれる更新後の状態ツリーを生成します。 これらのトランザクションは、`execution_payload`において`トランザクション`という名称のリストに含まれており、当該のポストステートは`state-root`フィールドに書き込まれます。 +`execution_payload`は、トランザクションに関する情報が実行クライアントとコンセンサスクライアントとの間で受け渡されることを可能にします。 `execution_payload`は、ビーコンブロック内にネストされる実行データのブロックです。 `execution_payload`内の各フィールドは、イーサリアムのイエローペーパーで概説されたブロックの構造を反映しています。ただし、オマーブロックを含まず、難易度の代わりに`prev_randao`を含む点が異なります。 実行クライアントは、自身のゴシップネットワークで耳にしたトランザクションのローカルプールにアクセスすることができます。 これらのトランザクションはローカルで実行され、ポストステートと呼ばれる更新後の状態ツリーを生成します。 これらのトランザクションは、`execution_payload`においてトランザクションという名称のリストに含まれており、当該のポストステートは`state-root`フィールドに書き込まれます。 これらのデータはすべてビーコンブロックで収集、署名された上で、ブロック提案者のピアユーザーのブロードキャストされ、受信したピアはさらにそのピアユーザーに送信します。 -詳細については、[ブロックの構造](/developers/docs/blocks)をご覧ください。 +[ブロックの構造についての詳細](/developers/docs/blocks/) ## 生成されたブロックには、何が起きるのか？ {#what-happens-to-blocks} -生成されたブロックはブロック提案者のローカルデータベースに追加され、コンセンサスレイヤーのゴシップネットワークを通じてピアユーザーにブロードキャストされます。 ブロックを受け取ったバリデータは、そのブロックに含まれるデータを検証します。具体的には、親ブロックが適切かどうか、適切なスロットに対応しているか、提案者インデックスが予期されたものであるか、RANDAO開示が有効か、および提案者がスラッシュ対象になっていないか、について確認します。 `execution_payload`のバンドルが解除され、バリデータの実行クライアントが当該リストに含まれるトランザクションを実行して、提案される状態変更についてチェックします。 当該ブロックがこれらのチェックにすべて合格した場合、各バリデータはブロックを自身の正規チェーンに追加します。 以上のプロセスを、次のスロットでも繰り返します。 +生成されたブロックはブロック提案者のローカルデータベースに追加され、コンセンサスレイヤーのゴシップネットワークを通じてピアユーザーにブロードキャストされます。 ブロックを受け取ったバリデータは、そのブロックに含まれるデータを検証します。具体的には、親ブロックが適切かどうか、適切なスロットに対応しているか、提案者インデックスが予期されたものであるか、RANDAO開示が有効か、および提案者がスラッシュ対象になっていないか、について確認します。 `execution_payload`のバンドルが解除され、バリデータの実行クライアントがリスト内のトランザクションを再実行して、提案された状態変更をチェックします。 当該ブロックがこれらのチェックにすべて合格した場合、各バリデータはブロックを自身の正規チェーンに追加します。 以上のプロセスを、次のスロットでも繰り返します。 ## ブロック報酬 {#block-rewards} -ブロック提案者は、この作業に対する報酬を獲得します。 `base_reward` は、アクティブなバリデータの数と、それらのバリデータにおける有効な残高に基づいて計算されます。 その上で、ブロック提案者は、当該ブロックに含まれる1件の有効なアテステーションごとに`base_reward`の一部を受け取ります。当該ブロックをアテステーションするバリデータの数が多ければ多いほど、ブロック提案者の報酬は増えます。 スラッシングが必要なバリデータを報告したユーザーに対しても報酬が提供されます。この報酬額は、スラッシングされたバリデータにおける`有効な残高の512分の1`となります。 +ブロック提案者は、この作業に対する報酬を獲得します。 `base_reward` は、アクティブなバリデータの数と、それらのバリデータにおける有効な残高に基づいて計算されます。 その上で、ブロック提案者は、当該ブロックに含まれる1件の有効なアテステーションごとに`base_reward`の一部を受け取ります。当該ブロックをアテステーションするバリデータの数が多ければ多いほど、ブロック提案者の報酬は増えます。 スラッシングが必要なバリデータを報告したユーザーに対しても報酬が提供されます。この報酬額は、スラッシングされたバリデータにおける有効な残高の512分の1となります。 -[報酬およびペナルティの詳細](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) +[報酬とペナルティの詳細](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [ブロック入門](/developers/docs/blocks/) - [プルーフ・オブ・ステーク入門](/developers/docs/consensus-mechanisms/pos/) -- [イーサリアムにおけるコンセンサスの仕様](https://github.com/ethereum/consensus-specs) -- [ガスパー入門](/developers/docs/consensus-mechanisms/pos/) +- [イーサリアムコンセンサス仕様](https://github.com/ethereum/consensus-specs) +- [Gasper入門](/developers/docs/consensus-mechanisms/pos/gasper/) - [イーサリアムのアップグレード](https://eth2book.info/) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/faqs/index.md index ca13cd89276..258e9e84add 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/faqs/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -1,14 +1,14 @@ --- -title: よくある質問 -description: プルーフ・オブ・ステークについてのよくある質問 +title: "よくある質問" +description: "プルーフ・オブ・ステークについてのよくある質問" lang: ja --- -## プルーフ・オブ・ステークとは何ですか？ {#what-is-proof-of-stake} +## プルーフ・オブ・ステークとは {#what-is-proof-of-stake} プルーフ・オブ・ステークとは、悪意の行為を実行した攻撃者の資産価値を没収することで、ブロックチェーンの安全性を保護するアルゴリズムのクラスを指します。 プルーフ・オブ・ステークのシステムでは、バリデータ(検証者)が不正行為を行ったと実証される場合、自分の資産の一部が破壊されることを了承した上で預け入れる意思を持つバリデータ群が必要になります。 イーサリアムでは、ブロックチェーンの安全性を保護するためにプルーフ・オブ・ステークのメカニズムを採用しています。 -## プルーフ・オブ・ステークとプルーフ・オブ・ワークの違いは何ですか？ {#comparison-to-proof-of-work} +## プルーフ・オブ・ステークとプルーフ・オブ・ワークの違いは何ですか？ プルーフ・オブ・ワークとの比較 {#comparison-to-proof-of-work} プルーフ・オブ・ワークとプルーフ・オブ・ステークはいずれも、悪意のアクターがスパム行為やネットワーク上の不正行為を行う場合に経済的な不利益を被ることになるメカニズムであるという点では共通しています。 どちらのメカニズムでも、コンセンサスに積極的に関与する各ノードは、自分の資産の一部を「ネットワークに預け入れる」必要があり、預け入れられた資産は不正行為が発覚した場合に没収されます。 @@ -18,7 +18,7 @@ lang: ja プルーフ・オブ・ワークではマイニングにおいて電力が消費されるため、よりエネルギー効率が低いと言えます。 一方、プルーフ・オブ・ステークではエネルギー消費量は非常に少なく抑えることができ、イーサリアムのバリデータはRaspberry Piなどの低電力消費のコンピュータでも作業を実行できます。 イーサリアムが採用したプルーフ・オブ・ステークのメカニズムでは、攻撃者が負担するコストがより大きく、より厳格な制裁が課されるため、プルーフ・オブ・ワークよりも安全性が高いと考えられています。 -プルーフ・オブ・ワークとプルーフ・オブ・ステークのどちらが優れているかについては、現在も論争が続いています。 [ビタリック・ブテリンのブログ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work)およびジャスティン・ドレイクとリン・オールデンとのディベートは、この論争で参考となる要約になっています。 +プルーフ・オブ・ワークとプルーフ・オブ・ステークのどちらが優れているかについては、現在も論争が続いています。 [ヴィタリック・ブテリンのブログ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work)やジャスティン・ドレイクとリン・オールデンとのディベートで、議論の概要がよくまとめられています。 @@ -26,33 +26,33 @@ lang: ja プルーフ・オブ・ステークのネットワークに含まれる各ノードは、ごくわずかの電力しか消費しません。 あるサードパーティ調査によれば、イーサリアムにおけるプルーフ・オブ・ステークのネットワーク全体で消費される電力は年間0.0026TWhであり、米国のゲーム用途の電力消費量と比較するとおよそ1万3,000分の1に過ぎません。 -[イーサリアムのエネルギー消費についての詳細](/energy-consumption/) +[イーサリアムのエネルギー消費の詳細](/energy-consumption/) ## プルーフ・オブ・ステークは安全ですか？ {#is-pos-secure} イーサリアムのプルーフ・オブ・ステークは、非常に安全性が高いと言えます。 プルーフ・オブ・ステークのメカニズムは、実際に導入される前に、8年間にわたりって研究・開発、厳格な検証が行われてきました。 プルーフ・オブ・ステークによるセキュリティの保証は、プルーフ・オブ・ワークの場合とは異なっています。 プルーフ・オブ・ステークでは、悪意のバリデータを積極的に処罰し(「スラッシュする」)、バリデータリストから削除できるため、攻撃者は多額のイーサを失うことになります。 一方プルーフ・オブ・ワークでは、攻撃者はハッシュパワーが十分である限り攻撃を継続できてしまいます。 また、同等の攻撃を行うための費用も、プルーフ・オブ・ステークの方がプルーフ・オブ・ワークよりも高価になります。 プルーフ・オブ・ステークでは、チェーンの生存性に悪影響を及ぼすためにはネットワークにステーキングするイーサの量が全体の33%以上でなければなりません(成功確率がきわめて低い非常に洗練された攻撃の場合を除く)。 将来のブロックの内容を支配するためには、ステーキングされたイーサの合計量の51%以上が必要であり、履歴の変更には66%以上が必要になります。 イーサリアムのプロトコルでは、これらの33%あるいは51%を保有する攻撃者の資産を破壊することができ、66%の攻撃シナリオでは社会的コンセンサスにより破壊が可能です。 -- [イーサリアムにおけるプルーフ・オブ・ステークのメカニズムを攻撃者から防御する方法についての詳細](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [イーサリアムのプルーフ・オブ・ステークに対する攻撃と防御の詳細](/developers/docs/consensus-mechanisms/pos/attack-and-defense) - [プルーフ・オブ・ステークの設計に関する詳細](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) ## プルーフ・オブ・ステークの導入により、イーサリアムの利用コストを引き下げられますか？ {#does-pos-make-ethereum-cheaper} できません。 トランザクションを送信するコスト(ガス代)は常に変化する手数料市場により決定され、ネットワーク需要と比例して上昇します。 イーサリアムのコンセンサス・メカニズムは、利用コストに直接的な影響を及ぼしません。 -[ガスについての詳細](/developers/docs/gas) +[ガスの詳細](/developers/docs/gas)。 ## ノード、クライアント、バリデータとは何ですか？ {#what-are-nodes-clients-and-validators} ノードとは、イーサリアム・ネットワークに接続されたコンピュータを指します。 クライアントとは、各コンピュータがノードとして機能するために実行されるソフトウェアを指します。 クライアントには、実行クライアントとコンセンサス・クライアントの2種類があります。 ノードとして機能するためには、これら2種類のソフトウェアが両方必要です。 バリデータとは、コンセンサス・クライアントがオプションで搭載できるアドオン機能であり、この機能を持つノードはプルーフ・オブ・ステークによるコンセンサス作業に参加できるようになります。 具体的には、バリデータに選定された場合にブロックを作成、提案でき、ネットワーク上で情報を得たブロックに対するアテステーションを実行できるようになります。 ノードの運用者がバリデータを実行するには、入金コントラクトに32イーサを預け入れる必要があります。 -- [ノードおよびクライアントについての詳細](/developers/docs/nodes-and-clients) -- [ステークの詳細](/staking) +- [ノードとクライアントの詳細](/developers/docs/nodes-and-clients) +- [ステーキングの詳細](/staking) ## プルーフ・オブ・ステークは新しいアイデアですか？ {#is-pos-new} -できません。 BitcoinTalk上のあるユーザーが2011年に、ビットコインをアップグレードする方法として[プルーフ・オブ・ステークの基本概念](https://bitcointalk.org/index.php?topic=27787.0)を提案しました。 イーサリアム・メインネット上でプルーフ・オブ・ステークの導入が可能になる11年前のことでした。 他のいくつかのブロックチェーンではイーサリアムよりも早期にプルーフ・オブ・ステークのメカニズムを導入しましたが、イーサリアムが導入したメカニズム(ガスパー)とは異なります。 +できません。 2011年、BitcoinTalkのあるユーザーが、ビットコインへのアップグレードとして[プルーフ・オブ・ステークの基本概念を提案しました](https://bitcointalk.org/index.php?topic=27787.0)。 イーサリアム・メインネット上でプルーフ・オブ・ステークの導入が可能になる11年前のことでした。 他のいくつかのブロックチェーンではイーサリアムよりも早期にプルーフ・オブ・ステークのメカニズムを導入しましたが、イーサリアムが導入したメカニズム(ガスパー)とは異なります。 -## イーサリアムにおけるプルーフ・オブ・ステークのメカニズムは、他のチェーンの場合と何が異なりますか？ {#why-is-ethereum-pos-special} +## イーサリアムにおけるプルーフ・オブ・ステークのメカニズムは、他のチェーンの場合と何が異なりますか？ イーサリアムのPoSが特別な理由 {#why-is-ethereum-pos-special} イーサリアムにおけるプルーフ・オブ・ステークのメカニズムは、独自の設計になっています。 イーサリアムに先がけて設計、実装されたプルーフ・オブ・ステークのメカニズムと比較すると、最も堅牢なメカニズムであると言えるでしょう。 イーサリアムにおけるプルーフ・オブ・ステークのメカニズムは、「キャスパー」と呼ばれます。 キャスパーでは、ブロック提案を行うバリデータを選出する方法、アテステーションがいつ、どのように作成されるか、アテステーションをどのように数えるか、バリデータに提供される報酬およびバリデータに課されるペナルティ、スラッシングの実行条件、インアクティブ・リークなどのフェイルセーフのメカニズム、および「ファイナリティ」の条件といった事項が定義されています。 ファイナリティとは、当該ブロックが正規チェーンの永続的な一部であると見なされるための条件であり、ネットワーク上でステーキングされたイーサ総量の少なくとも66%以上が投票する必要があります。 キャスパーは、特にイーサリアムを念頭に置いて開発されたメカニズムであり、イーサリアムが最初に実装して以降、現在も他のブロックチェーンは採用していません。 @@ -60,13 +60,13 @@ lang: ja キャスパーおよびLMD-GHOSTをまとめて、「ガスパー」と呼んでいます。 -[ガスパーについての詳細](/developers/docs/consensus-mechanisms/pos/gasper/) +[Gasperの詳細](/developers/docs/consensus-mechanisms/pos/gasper/) ## スラッシングとは何ですか？ {#what-is-slashing} スラッシングとは、バリデータがステーキングした資産の一部を破壊し、バリデータをネットワークから退出させる行為を指します。 スラッシングで破壊されるイーサの量は、スラッシング対象のバリデータの数に応じて変化します。つまり、複数のバリデータが共謀して悪意の行為を行った場合、1名の悪意のユーザーに対する場合よりも厳格に罰せられます。 -[スラッシングについての詳細](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) +[スラッシングの詳細](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) ## バリデータが32イーサを預け入れなければならないのはなぜですか？ {#why-32-eth} @@ -76,32 +76,32 @@ lang: ja 各スロットにおいてブロックを提案できるバリデータが、疑似的な無作為性に基づき1名選出されます。これは、ブロック提案者のハッシュとブロックごとに更新されるシードを混合するRANDAOというアルゴリズムを用いて行われます。 この混合値は、バリデータの全リストから当該の1名を選出するために用いられます。 バリデータの選出は、2つ前のエポックの時点で事前に完了しています。 -[バリデータの選出についての詳細](/developers/docs/consensus-mechanisms/pos/block-proposal) +[バリデータ選択の詳細](/developers/docs/consensus-mechanisms/pos/block-proposal) ## ステーク・グラインディングとは何ですか？ {#what-is-stake-grinding} ステーク・グラインディングとは、プルーフ・オブ・ステークのネットワークに対する攻撃の一種であり、攻撃者が自分にとって有利なバリデータが選出されるようにバリデータ選出アルゴリズムを影響付けようとする手法です。 RANDAOに対するステーク・グラインディング攻撃を実行するには、ステーキングされたイーサ総量の約半分が必要になります。 -[ステーク・グラインディングについての詳細](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) +[ステーク・グラインディングの詳細](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) ## ソーシャルスラッシングとは何ですか？ {#what-is-social-slashing} ソーシャルスラッシングとは、ネットワークが攻撃を受けた際に、ユーザーコミュニティがブロックチェーンのフォークを調整する能力を指します。 ユーザーコミュニティは、ソーシャルスラッシングを通じて、攻撃者がファイナライズしてしまった不正なチェーンを元に戻すことができます。 ソーシャルスラッシングはさらに、検閲攻撃に対しても活用できます。 -- [ソーシャルスラッシングについての詳細](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) -- [ソーシャルスラッシングについてのヴィタリック・ブテリンの意見](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [ソーシャルスラッシングの詳細](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [ソーシャルスラッシングに関するヴィタリック・ブテリンの見解](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) ## 私もスラッシングの対象になりますか？ {#will-i-get-slashed} バリデータに対しては、故意に悪意の行動を実行しない限り、スラッシングの対象になる可能性は非常に低いです。 スラッシングが実行されるのは、バリデータが同一スロットに対して複数のブロックを提案する場合や、アテステーションと矛盾した行動を取るという非常に限定的なシナリオにおいてのみであり、これらの状況が偶然発生する可能性はほとんどありません。 -[スラッシングの実行条件についての詳細](https://eth2book.info/altair/part2/incentives/slashing) +[スラッシングの条件に関する詳細](https://eth2book.info/altair/part2/incentives/slashing) ## ステーキング無しの問題とは何ですか？ {#what-is-nothing-at-stake-problem} ステーキング無しの問題とは、報酬のみを伴い、ペナルティが科せられない一部のプルーフ・オブ・ステークのメカニズムにおける概念上の問題です。 ステーキングが要求されない場合、実利を求めるバリデータは、報酬を増やすために、ブロックチェーンのいかなるいかなるフォークに対して、あるいは複数のフォークに対して喜んでアテステーションを行うでしょう。 イーサリアムでは、ファイナリティ条件とスラッシングのメカニズムを採用することで、唯一の正規チェーンを維持できるようにしています。 -[ステーキング無し問題についての詳細](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) +[ナッシング・アット・ステーク問題の詳細](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) ## フォーク選択アルゴリズムとは何ですか？ {#what-is-a-fork-choice-algorithm} @@ -109,13 +109,13 @@ lang: ja イーサリアムでは、LMD-GHOSTというフォーク選択アルゴリズムを採用しています。 このアルゴリズムでは、アテステーションの加重が最も大きいフォーク、つまりステーキングされたイーサ量を最も多く集めたフォークが選択されます。 -[LMD-GHOSTについての詳細](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) +[LMD-GHOSTの詳細](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) ## プルーフ・オブ・ステークにおけるファイナリティとは何ですか？ {#what-is-finality} プルーフ・オブ・ステークにおけるファイナリティとは、特定のブロックが正規チェーンの永続的な一部となり、攻撃者がステーキングされたイーサ総量の33%をバーンすることでコンセンサス障害を発生させない限り、取り消すことができない状況を指します。 これは、「暗号経済的な」ファイナリティであり、プルーフ・オブ・ワークを採用したブロックチェーンにおける「確率論的なファイナリティ」と対比される概念です。 確率論的なファイナリティにおいては、ブロックに対して明確にファイナライズされた/されていない状態というものが存在しません。つまり、各ブロックは、作成後の時間が経過するに従ってチェーンから削除される可能性が徐々に少なくなり、ユーザー自身が当該ブロックが「安全」である時期が到来したかどうかを決定する必要があるのです。 暗号経済的なファイナリティは、ステーキングされたイーサ総量の66%を占めるユーザーが、チェックポイントとなるブロックのペアを投票することで決定されます。 この投票で認められた場合、チェックポイントであるブロックのペア間に挟まれたブロックは明示的に「ファイナライズ」されます。 -[ファイナリティについての詳細](/developers/docs/consensus-mechanisms/pos/#finality) +[ファイナリティの詳細](/developers/docs/consensus-mechanisms/pos/#finality) ## 「弱い主観性」とは何ですか? {#what-is-weak-subjectivity} @@ -127,19 +127,19 @@ lang: ja 現在のところ、検閲耐性を証明するのは困難です。 ただしプルーフ・オブ・ワークの場合とは異なり、プルーフ・オブ・ステークではスラッシングを連携して実行するオプションが提供されるため、検閲するバリデータを罰することができます。 今後予定されているプロトコルの変更では、ブロック作成者とブロック提案者が分離され、作成者が各ブロックに含まなければならないトランザクションのリストが実装されます。 この提案は、提案者/作成者の分離と呼ばれており、バリデータがトランザクションを検閲できなくするために役立ちます。 -[提案者/作成者の分離についての詳細](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) +[提案者-ビルダー分離についての詳細](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) -## イーサリアムのプルーフ・オブ・ステークに対しては、51%攻撃が可能ですか？ {#pos-51-attack} +## イーサリアムのプルーフ・オブ・ステークに対しては、51%攻撃が可能ですか？ PoSの51%攻撃 {#pos-51-attack} プルーフ・オブ・ワークの場合と同様に、プルーフ・オブ・ステークも51%攻撃に対する脆弱性が存在します。 ただし、攻撃者に必要なのはネットワーク全体のハッシュパワーのうち51%ではなく、ステーキングされたイーサ総量の51%である点が異なります。 攻撃者は、ステーキングされたイーサ総量の51%することで、フォーク選択アルゴリズムを支配することが可能になります。 この場合、攻撃者は一部のトランザクションを検閲し、ショートレンジの再編成を行い、自分に有利になるようにブロックの順序を入れ換えることでMEVを獲得することができます。 -[プルーフ・オブ・ステークに対する攻撃の詳細](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +[プルーフ・オブ・ステークへの攻撃に関する詳細](/developers/docs/consensus-mechanisms/pos/attack-and-defense) ## ソーシャル・コーディネーションとは何であり、なぜ必要なのですか？ {#what-is-social-coordination} ソーシャル・コーディネーションは、イーサリアムにおける最後の防衛ラインであり、不正なブロックをファイナライズした攻撃から、正当なチェーンを回復することが可能になるものです。 この場合、イーサリアム・コミュニティは「帯域外」で連携して、正当な少数派フォークを採用することに合意し、同時に攻撃者のバリデータに対してスラッシングを実行する必要があります。 このプロセスには、正当なフォークを認識するためのアプリおよび取引所も必要になります。 -[ソーシャル・コーディネーションについての詳細](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) +[ソーシャルコーディネーションの詳細](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) ## プルーフ・オブ・ステークでは、すでに資金が豊富なユーザーがさらに富を得るのですか？ {#do-rich-get-richer} @@ -147,15 +147,15 @@ lang: ja ## プルーフ・オブ・ステークのメカニズムは、プルーフ・オブ・ワークよりも分散性が低いのですか？ {#is-pos-decentralized} -いいえ。むしろプルーフ・オブ・ワークの方が、マイニングの費用が高額になり、参加できないユーザーや中小企業等が増加するため、分散性が損なわれます。 プルーフ・オブ・ステークが現在直面している課題は、流動性ステーキングデリバティブ(LSD)の影響をどう排除するかです。 LSDは、一部のプロバイダーがステーキングしたイーサを原資産とするトークンであり、ステーキングされた実際のイーサを解除することなく、流通市場で誰もがスワップすることができます。 このようなLSDを用いることで、32イーサ未満の資産でもステーキングが可能にありますが、ステークの大部分を少数の大規模組織が支配することが可能になるため、中央集権化のリスクを生み出してしまいます。 このため、イーサリアムにおいては [ソロ・ステーキング](/staking/solo)が最善の選択肢なのです。 +いいえ。むしろプルーフ・オブ・ワークの方が、マイニングの費用が高額になり、参加できないユーザーや中小企業等が増加するため、分散性が損なわれます。 プルーフ・オブ・ステークが現在直面している課題は、流動性ステーキングデリバティブ(LSD)の影響をどう排除するかです。 LSDは、一部のプロバイダーがステーキングしたイーサを原資産とするトークンであり、ステーキングされた実際のイーサを解除することなく、流通市場で誰もがスワップすることができます。 このようなLSDを用いることで、32イーサ未満の資産でもステーキングが可能にありますが、ステークの大部分を少数の大規模組織が支配することが可能になるため、中央集権化のリスクを生み出してしまいます。 このため、イーサリアムにおいては[ソロ・ステーキング](/staking/solo)が最善の選択肢なのです。 -[LSDによるステークの分散性低下についての詳細](https://notes.ethereum.org/@djrtwo/risks-of-lsd) +[LSDにおけるステークの中央集権化に関する詳細](https://notes.ethereum.org/@djrtwo/risks-of-lsd) ## ステーキングにイーサしか利用できないのはなぜですか？ {#why-can-i-only-stake-eth} ETHはイーサリアムにおけるネイティブな通貨です。 投票の加重を決定し、セキュリティを維持するためには有効残高を正確に計算することが必要であり、それには、すべてのステーキングを同一の単位で表示する単一の通貨を定めなければなりません。 ETHは、それ自体がイーサリアムの基本的な構成要素であり、単なるスマートコントラクトとは言えません。 他の通貨を利用可能にする場合、ステーキングのプロセスがさらに複雑になり、安全性が低下します。 -## イーサリアムは、プルーフ・オブ・ステークを採用した唯一のブロックチェーンですか？ {#is-ethereum-the-only-pos-blockchain} +## イーサリアムは、プルーフ・オブ・ステークを採用した唯一のブロックチェーンですか？ PoSブロックチェーンはイーサリアムだけか {#is-ethereum-the-only-pos-blockchain} いいえ、他にもプルーフ・オブ・ステークを採用しているブロックチェーンが存在します。 ただし、イーサリアムにおけるプルーフ・オブ・ステークは独自のメカニズムを採用しており、他のブロックチェーンの場合とは異なります。 @@ -167,6 +167,6 @@ ETHはイーサリアムにおけるネイティブな通貨です。 投票の ## 生存性および安全性とは何ですか？ {#what-are-liveness-and-safety} -生存性と安全性は、ブロックチェーンにおいて最も基本的なセキュリティ上の懸念事項です。 生存性とは、ファイナライズされたチェーンが存在することを指します。 つまり、チェーンのファイナライズが実行されなくなったり、ユーザーがファイナライズされたチェーンに簡単にアクセスできなくなった場合、生存性が失われたと言えます。 また、ネットワークへのアクセス費用が非常に高額になった場合も、生存性が失われたと考えられるでしょう。 一方、安全性とは、チェーンへの攻撃(競合するチェックポイントをファイナライズすること)がどれだけ困難であるかを示す概念です。 +生存性と安全性は、ブロックチェーンにおいて最も基本的なセキュリティ上の懸念事項です。 生存性とは、ファイナライズされたチェーンが存在することを指します。 つまり、チェーンのファイナライズが実行されなくなったり、ユーザーがファイナライズされたチェーンに簡単にアクセスできなくなった場合、生存性が失われたと言えます。 また、ネットワークへのアクセス費用が非常に高額になった場合も、生存性が失われたと考えられるでしょう。 安全性とは、チェーンを攻撃すること、つまり競合するチェックポイントをファイナライズすることが、どれほど困難であるかを指します。 -[キャスパー文書でより詳細に学ぶ](https://arxiv.org/pdf/1710.09437.pdf) +[Casperの論文で続きを読む](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/gasper/index.md index 49dd0dd9353..243dcb737e5 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/gasper/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -1,18 +1,18 @@ --- -title: ガスパー (Gasper) -description: ガスパー・プルーフ・オブ・ステーク・メカニズムの説明 +title: "ガスパー (Gasper)" +description: "ガスパー・プルーフ・オブ・ステーク・メカニズムの説明" lang: ja --- ガスパー(Gasper)は、Casper-FFG (Casper the Friendly Finality Gadget)とLMD-GHOSTフォーク・チョイス・アルゴリズムを組み合わせたものです。 これらのコンポーネントが合わさって、プルーフ・オブ・ステークのイーサリアムを保護する合意メカニズムを形成します。 Casper(キャスパー)は、特定のブロックを「ファイナライズ (確定) 」にアップグレードするメカニズムであり、ネットワークへの新規参入者が正規のブロックチェーンと同期していることが確信できます。 フォーク・チョイス・アルゴリズムは、ブロックチェーンでフォークの発生時に、累積票を使用してノードが正しいものを簡単に選択できます。 -**注** Casper-FFG の元の定義は、ガスパーを包括させるため、若干更新されました。 このページでは、更新されたバージョンを考慮しています。 +**注** Casper-FFGの元の定義は、Gasperに含めるために若干更新されました。 このページでは、更新されたバージョンを考慮しています。 -## 前提知識 +## 事前に必要な環境 -この資料を理解するためには、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)入門ページを読む必要があります。 +この資料を理解するには、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)の入門ページを読む必要があります。 -## ガスパーの役割 {#role-of-gasper} +## Gasperの役割 {#role-of-gasper} ガスパーは、プルーフ・オブ・ステーク・ブロックチェーンの上部にあり、ノードがEtherをセキュリティデポジットとして提供します。このセキュリティデポジットは、ブロックの提案や検証を怠ったり、不正をした場合には破棄されます。 ガスパーは、バリデータがどのように報酬と罰を受け、どのブロックを受け入れ、拒否するかを決定し、ブロックチェーンのどのフォークで構築するかを定めるメカニズムです。 @@ -20,33 +20,34 @@ lang: ja ファイナリティとは、ブロックのプロパティで、致命的なコンセンサスの障害があり、攻撃者が少なくともステークされたETH総数の3分の1を破壊しない限り、元に戻すことはできないことを意味します。 ファイナライズされたブロックは、ブロックチェーンが確信している情報だと考えることができます。 ファイナライズされるには、ブロックは2つのステップのアップブレード手順を経る必要があります。 -1. ステークされたETH総数の3分の2が、そのブロックが正規のチェーンに含まれることに賛成票を投じることが必要。 この条件によって、ブロックは「正当 (justified)」にアップグレードされる。 正当とされたブロックは、元に戻される可能性は低いものの、一定の条件下で元に戻されることがある。 +1. ステークされたETH総数の3分の2が、そのブロックが正規のチェーンに含まれることに賛成票を投じることが必要。 この条件によって、ブロックは「正当 (justified)」にアップグレードされる。 + 正当とされたブロックは、元に戻される可能性は低いものの、一定の条件下で元に戻されることがある。 2. 正当とされたブロック上で、別のブロックが再び正当となった時、「ファイナライズ」にアップグレードされる。 ブロックがファイナライズされるとは、いわば正規チェーンにそのブロックを含めることにコミットすることである。 攻撃者が、数百万ETH (数十億$USD)を破壊しない限り、元に戻すことはできない。 -これらのブロックのアップグレードは、すべてのスロットで発生するわけではありません。 エポック境界ブロックが、正当およびファイナライズになることがあります。 これらのブロックは、「チェックポイント」とも呼ばれています。 アップグレードは、チェックポイントのペアを考慮します。 2つの連続するチェックポイント(すなわち、チェックポイントBが、チェックポイントAの正しい子孫であるというステークされたETH総数の3分の2の投票) 間に、「スーパーマジョリティ・リンク」が存在する必要があります。 +これらのブロックのアップグレードは、すべてのスロットで発生するわけではありません。 エポック境界ブロックが、正当およびファイナライズになることがあります。 これらのブロックは、「チェックポイント」とも呼ばれています。 アップグレードは、チェックポイントのペアを考慮します。 より古いチェックポイントをファイナライズ済みに、より新しいブロックを正当化済みに更新するには、2つの連続したチェックポイント間に「スーパーマジョリティ・リンク」が存在する必要があります（すなわち、ステークされたether総量の3分の2が、チェックポイントBがチェックポイントAの正しい子孫であると投票すること）。 ファイナリティには、ブロックが正規なものであるという3分の2の合意が必要となるため、攻撃者はファイナライズされたチェーンの代替を次の方法でしか作成できません。 1. ステークされたETH総数の3分の2を所有または操作する。 2. ステークされたETH総数の少なくとも3分の1を破壊する。 -1つ目の条件が生じるのは、チェーンをファイナライズさせるにはステークされたETHの3分の2が必要なためです。 2つ目の条件が生じるのは、ステーク合計の3分の2が両方のフォークに賛成票を投じた場合、3分の1が両方に投票したことになるためです。 2重投票は、最大限の処罰を受けるスラッシング条件で、ステーキング総額の3分の1が破壊されます。 2022年5月の時点では、攻撃者は約100億ドル相当のETHをバーン(燃焼)する必要があります。 ガスパーのブロックを正当化およびファイナライズさせるアルゴリズムは、[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf)を少し変更した形式となっています。 +1つ目の条件が生じるのは、チェーンをファイナライズさせるにはステークされたETHの3分の2が必要なためです。 2つ目の条件が生じるのは、ステーク合計の3分の2が両方のフォークに賛成票を投じた場合、3分の1が両方に投票したことになるためです。 2重投票は、最大限の処罰を受けるスラッシング条件で、ステーキング総額の3分の1が破壊されます。 2022年5月の時点では、攻撃者は約100億ドル相当のETHをバーン(燃焼)する必要があります。 Gasperのブロックを正当化およびファイナライズするアルゴリズムは、[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf)を若干変更した形式です。 ### インセンティブとスラッシング {#incentives-and-slashing} バリデータは、誠実にブロックを提案し、検証することで報酬を得ることができます。 ETHが報酬として与えられ、ステークに加えられます。 一方、呼び出されたときにオフラインおよび行動しなかったバリデータは、これらの報酬を逃し、時には既存のステークのごく一部を失うこともあります。 しかし、オフラインであることのペナルティは小さく、ほとんどの場合、報酬を逃したことによる機会コストに相当します。 ただし、一部のバリデータには、偶然に実行することが非常に困難であり、同じスロットに対して複数のブロックを提案する、同じスロットに対して複数のブロックを証明する、または以前のチェックポイントの投票に矛盾するなど、何らかの悪意が感じられる行動を取るものもあります。 これらは、「スラッシング対象」となる行為であり、より厳しいペナルティが課されます。スラッシングされると、バリデータのステークの一部は破壊され、そのバリデータはネットワークから削除されます。 このプロセスには、36日間を要します。 第1日目における初回のペナルティは、最大1ETHまでです。 次に、スラッシュシングされたバリデータのETHは、退出期間全体を通してゆっくりと失われます。18日目には、「相関ペナルティ」が発生し、これは、より多くのバリデータが同時にスラッシングされた場合に大きくなります。 最大のペナルティは、ステーク全額です。 これらの報酬とペナルティは、誠実なバリデータにインセンティブを与え、ネットワークへの攻撃を阻害するように設計されています。 -### 非稼働リーク {#inactivity-leak} +### 無活動リーク {#inactivity-leak} セキュリティだけでなく、ガスパーは、「信ぴょう性のある生存度」も提供します。 これは、ステークされたETH総数の3分の2が、誠実な投票をしており、プロトコルに従っている限り、他のアクティビティ(攻撃、遅延、スラッシングなど)に関係なく、チェーンがファイナライズできるという条件です。 言い換えれば、ステークされたETH合計の3分の1は、チェーンがファイナライズするのを防ぐために何らかの方法で損なわれる必要があります。 ガスパーには、「非稼働リーク」として知られる生存度障害に対する追加の防御策があります。 このメカニズムは、4エポック以上、チェーンのファイナライズに失敗した場合に作動します。 マジョリティのチェーンを積極的に証明しないバリデータは、マジョリティがステーク合計の3分の2を取り戻すまで、バリデータのステークが徐々に失われるため、生存度障害が確実に一時的なものになるようにします。 -### フォークの選択 {#fork-choice} +### フォーク選択 {#fork-choice} -オリジナルのCasper-FFGの定義には、次のルールを課すフォーク・チョイス・アルゴリズムを含んでいました。 `follow the chain containing the justified checkpoint that has the greatest height` ここで、「高さ (Height) 」は始まりのブロックからの最大距離として定義されます。 ガスパーでは、LMD-GHOSTと呼ばれるより洗練されたアルゴリズムが選ばれたため、元のフォーク・チョイス・ルールは廃止されました。 通常の条件下では、フォーク・チョイス・ルールは不要であることを認識することが重要です。スロットごとに単一のブロック提案者がいて、誠実なバリデータがそれを証明するだけです。 ネットワークの非同期性が大きい場合や、または不誠実なブロック提案者がフォーク・チョイス・アルゴリズムが必要であると主張した場合にのみ必要です。 ただし、これらのケースが発生した場合、フォーク・チョイス・アルゴリズムは、正しいチェーンを保護する重要な防御策になります。 +Casper-FFGの元の定義には、「`follow the chain containing the justified checkpoint that has the greatest height`」というルールを課すフォーク選択アルゴリズムが含まれていました。ここで、height（高さ）はジェネシスブロックからの最長距離として定義されます。 ガスパーでは、LMD-GHOSTと呼ばれるより洗練されたアルゴリズムが選ばれたため、元のフォーク・チョイス・ルールは廃止されました。 通常の条件下では、フォーク・チョイス・ルールは不要であることを認識することが重要です。スロットごとに単一のブロック提案者がいて、誠実なバリデータがそれを証明するだけです。 ネットワークの非同期性が大きい場合や、または不誠実なブロック提案者がフォーク・チョイス・アルゴリズムが必要であると主張した場合にのみ必要です。 ただし、これらのケースが発生した場合、フォーク・チョイス・アルゴリズムは、正しいチェーンを保護する重要な防御策になります。 LMD-GHOSTは、「Latest Message-Driven Greedy Heaviest Observed Sub-Tree」の略です。 これは、専門用語が多い定義ですが、アテステーションの最大の累積重みを持つフォークを正規のものとして選択し(Greedy Heaviest SubTree)、バリデータから複数のメッセージを受信した場合、最新のメッセージ(Latest-Message Driven)のみが考慮されるというアルゴリズムです。 最大の累積重みを持つブロックを正規チェーンに追加する前に、すべてのバリデータがこのLMD-GHOSTルールを使用して各ブロックを評価します。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [ガスパー: GHOSTとキャスパーの組み合わせ](https://arxiv.org/pdf/2003.03052.pdf) -- [キャスパー：フレンドリーなファイナリティ用ガジェット](https://arxiv.org/pdf/1710.09437.pdf) +- [Gasper: Combining GHOST and Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/index.md index b5d0c0bfb5e..c453d47d3ec 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/index.md @@ -1,14 +1,14 @@ --- -title: プルーフ・オブ・ステーク(PoS) -description: イーサリアムにおけるプルーフ・オブ・ステーク (PoS)プロトコルとその役割 +title: "プルーフ・オブ・ステーク(PoS)" +description: "イーサリアムにおけるプルーフ・オブ・ステーク (PoS)プロトコルとその役割" lang: ja --- -プルーフ・オブ・ステーク(PoS)は、イーサリアムの[合意形成のメカニズム](/developers/docs/consensus-mechanisms/)の基礎となっています。 イーサリアムは2022年プルーフ・オブ・ステークのメカニズムに移行しました。これまでの[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow)のアーキテクチャと比較して、より安全で、エネルギー消費量が少なく、新たなスケーリングソリューションの導入に適しています。 +プルーフ・オブ・ステーク(PoS)は、イーサリアムの[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)の基礎となっています。 イーサリアムは2022年、プルーフ・オブ・ステークメカニズムに移行しました。これまでの[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow)アーキテクチャと比較して、より安全で、エネルギー消費量が少なく、新たなスケーリングソリューションの導入に適しているためです。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをより理解するために、まずは[合意メカニズム](/developers/docs/consensus-mechanisms/)を読むことをお勧めします。 +このページをよりよく理解するために、まず[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。 ## プルーフ・オブ・ステーク(PoS)とは {#what-is-pos} @@ -20,38 +20,39 @@ lang: ja プルーフ・オブ・ワークでは、ブロックのタイミングはマイニングの難易度によって決まりますが、プルーフ・オブ・ステークでは、間隔は固定されています。 プルーフ・オブ・ステークのイーサリアムにおける時間は、スロット(12秒)とエポック(32スロット)に分かれています。 すべてのスロットで、1つのバリデータがランダムに選択され、ブロックを提案できます。 このバリデータは新しいブロックを作成後、ネットワーク上の他のノードに新しいブロックを送信します。 また、すべてのスロットでバリデータの委員会がランダムに選択され、提案されているブロックの有効性を判断し、投票が行われます。 バリデータセットを委員会に分割することは、ネットワークの負荷を管理可能な状態に維持するために重要です。 委員会は、すべてのアクティブなバリデータが、各スロットではなく各エポックにで証明できるように、バリデータのセットを分割します。 -## イーサリアムのプルーフ・オブ・ステークでは、トランザクションはどのように実行されるか？ {#transaction-execution-ethereum-pos} +## イーサリアムPoSにおけるトランザクションの実行方法 {#transaction-execution-ethereum-pos} 以下では、イーサリアムのプルーフ・オブ・ステークにおいて、トランザクションがどのように実行するかをエンドツーエンドの視点で説明します。 -1. ユーザーはまず、自分の秘密鍵を使って[トランザクション](/developers/docs/transactions/)を作成し、署名します。 この作業は通常、ウォレットや、[ethers.js](https://docs.ethers.org/v6/)、[web3js](https://docs.web3js.org/)、[web3py](https://web3py.readthedocs.io/en/v5/)といったライブラリにより実行されますが、実際には、ユーザーはイーサリアムの[JSON-RPC API](/developers/docs/apis/json-rpc/)を用いてノードへのリクエストを実行しています。 作成ユーザーは、バリデータに支払う意思があるチップとして特定のガス代を提示することで、このトランザクションをブロックに追加してもらえるように促します。 この[チップ](/developers/docs/gas/#priority-fee)はバリデータに支払われ、[ベース報酬](/developers/docs/gas/#base-fee)はバーンされます。 -2. 作成されたトランザクションは、イーサリアムの[実行クライアント](/developers/docs/nodes-and-clients/#execution-client)に送信され、実行クライアントにおいてその有効性が検証されます。 この検証では、送信者がトランザクションを実行するために十分なイーサ残高を持っているか、および適切な鍵で署名されているかを確認できます。 -3. トランザクションが有効であれば、実行クライアントは自分のローカルメムプール(実行待ちのトランザクションリスト)にこのトランザクションを追加し、さらに、実行レイヤーのゴシップネットワークを通じてその他のノードにこのトランザクションを送信します。 このトランザクションについて耳にしたその他のノードも、自分のメムプールにこのトランザクションを追加します。 より高度なユーザーは、トランザクションをブロードキャストすることを避けて、[フラッシュボット・オークション](https://docs.flashbots.net/flashbots-auction/overview)などの特化されたブロックビルダーに送信してもよいでしょう。 これにより、今後のブロックにトランザクションを追加する順番を整理することで、利益を最大化することができます([MEV](/developers/docs/mev/#mev-extraction))。 -4. ネットワーク上のバリデータノードの1つが、RANDAOを使用して疑似ランダムに選ばれ、現在のスロットのブロック提案者となります。 ブロック提案者のノードは、イーサリアムのブロックチェーンに追加される次のブロックを生成、ブロードキャストし、グローバルステートを更新する役割を担います。 このノードは、実行クライアント、コンセンサスクライアント、およびバリデータクライアントの3つの部分で構成されます。 実行クライアントは、ローカルのメムプールに含まれるトランザクションを「実行ペイロード」としてバンドル化した上でローカルに実行し、状態変更を生成します。 状態変更の情報はコンセンサスクライアントに送信され、コンセンサスクライアントにおいて実行ペイロードが「ビーコンブロック」の一部としてラップされます。ビーコンブロックにはその他にも、報酬、ペナルティ、スラッシング、アテステーション等に関する情報が含まれており、チェーンの先頭におけるブロックのシーケンスについてネットワーク全体が合意することが可能になります。 実行クライアントとコンセンサスクライアントとの間のコミュニケーションについては、[「コンセンサスクライアントと実行クライアントを接続する」](/developers/docs/networking-layer/#connecting-clients)でより詳細に説明されています。 -5. 他のノードは、コンセンサスレイヤーのゴシップネットワークでこの新しいビーコンブロックを受け取ります。 その上で、このビーコンブロックを実行クライアントに送信し、実行クライアントがローカルでトランザクションを再実行することで、提案された状態変更が有効なものであることを確認します。 次にバリデータクライアントが、当該ブロックが有効であり、自分のチェーンビューにおいて論理的な次のブロックであるとのアテステーションを実行します(つまり、[フォーク選択ルール](/developers/docs/consensus-mechanisms/pos/#fork-choice)の規定に基づき、最大の重みを持つアテステーションに基づいてチェーンを構築します)。 当該ブロックは、アテステーションを実行した各ノードのローカルデータベースに追加されます。 +1. ユーザーは自身の秘密鍵で[トランザクション](/developers/docs/transactions/)を作成し、署名します。 これは通常、ウォレットや[ethers.js](https://docs.ethers.org/v6/)、[web3js](https://docs.web3js.org/)、[web3py](https://web3py.readthedocs.io/en/v5/)などのライブラリによって処理されますが、内部的にはユーザーはイーサリアムの[JSON-RPC API](/developers/docs/apis/json-rpc/)を使用してノードにリクエストを送信しています。 作成ユーザーは、バリデータに支払う意思があるチップとして特定のガス代を提示することで、このトランザクションをブロックに追加してもらえるように促します。 [チップ](/developers/docs/gas/#priority-fee)はバリデータに支払われ、[ベースフィー](/developers/docs/gas/#base-fee)はバーンされます。 +2. トランザクションはイーサリアムの[実行クライアント](/developers/docs/nodes-and-clients/#execution-client)に送信され、その有効性が検証されます。 この検証では、送信者がトランザクションを実行するために十分なイーサ残高を持っているか、および適切な鍵で署名されているかを確認できます。 +3. トランザクションが有効であれば、実行クライアントは自分のローカルメムプール(実行待ちのトランザクションリスト)にこのトランザクションを追加し、さらに、実行レイヤーのゴシップネットワークを通じてその他のノードにこのトランザクションを送信します。 このトランザクションについて耳にしたその他のノードも、自分のメムプールにこのトランザクションを追加します。 上級ユーザーは、トランザクションをブロードキャストせず、代わりに[Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview)のような専門のブロックビルダーに転送することもあります。 これにより、次のブロック内のトランザクションを整理して、利益を最大化することができます([MEV](/developers/docs/mev/#mev-extraction))。 +4. ネットワーク上のバリデータノードの1つが、RANDAOを使用して疑似ランダムに選ばれ、現在のスロットのブロック提案者となります。 ブロック提案者のノードは、イーサリアムのブロックチェーンに追加される次のブロックを生成、ブロードキャストし、グローバルステートを更新する役割を担います。 このノードは、実行クライアント、コンセンサスクライアント、およびバリデータクライアントの3つの部分で構成されます。 実行クライアントは、ローカルのメムプールに含まれるトランザクションを「実行ペイロード」としてバンドル化した上でローカルに実行し、状態変更を生成します。 状態変更の情報はコンセンサスクライアントに送信され、コンセンサスクライアントにおいて実行ペイロードが「ビーコンブロック」の一部としてラップされます。ビーコンブロックにはその他にも、報酬、ペナルティ、スラッシング、アテステーション等に関する情報が含まれており、チェーンの先頭におけるブロックのシーケンスについてネットワーク全体が合意することが可能になります。 実行クライアントとコンセンサスクライアント間の通信については、[コンセンサスクライアントと実行クライアントの接続](/developers/docs/networking-layer/#connecting-clients)で詳しく説明されています。 +5. 他のノードは、コンセンサスレイヤーのゴシップネットワークでこの新しいビーコンブロックを受け取ります。 その上で、このビーコンブロックを実行クライアントに送信し、実行クライアントがローカルでトランザクションを再実行することで、提案された状態変更が有効なものであることを確認します。 次にバリデータクライアントは、そのブロックが有効であり、自身のチェーンビューにおいて論理的な次のブロックであるとアテステーションします(つまり、[フォーク選択ルール](/developers/docs/consensus-mechanisms/pos/#fork-choice)で定義されているように、アテステーションの重みが最も大きいチェーン上に構築されることを意味します)。 当該ブロックは、アテステーションを実行した各ノードのローカルデータベースに追加されます。 6. トランザクションは、2つのチェックポイント間の「過半数リンク」を持った形でチェーンの一部となった場合に、「ファイナライズ済み」であると見なすことができます。 チェックポイントは、各エポックの開始時に発生します。このチェックポイントは、各スロットではアクティブなバリデータのサブセットが証明を行いますが、各エポック全体では、すべてのアクティブなバリデータが証明を行っていることを示すためのものです。 そのため、「過半数リンク」が実証できるのはエポック間のみです(これは、ネットワーク上でステーキングされたETH全体の66%が2つのチェックポイントに合意した場所)。 ファイナリティに関する詳細については、以下をご覧ください。 ## ファイナリティ {#finality} -分散ネットワークにおけるトランザクションのファイナリティとは、ブロックの当該部分を変更するためには大量のイーサをバーンする必要がある場合に達成されます。 イーサリアムのプルーフ・オブ・ステークでは、ファイナリティは「チェックポイント」ブロックを用いて管理されます。 各エポックの最初のブロックがチェックポイントになります。 バリデータは、有効だと見なすチェックポイントのペアに対して投票を行います。 ステーキングされたイーサの合計のうち少なくとも3分の2が当該のチェックポイントのペアに対して投票した場合、これらのチェックポイントは更新されます。 2つの(ターゲットである)チェックポイントのうち、より新しいチェックポイントの方が「正当化」されます。 チェックポイントのペアにおけるより古いチェックポイントは、1つ前のエポックにおいて「ターゲット」のチェックポイントとしてすでに正当化されています。 こうして正当化されたチェックポイントは、「ファイナライズ済み」にアップグレードされます。 +分散ネットワークにおけるトランザクションのファイナリティとは、ブロックの当該部分を変更するためには大量のイーサをバーンする必要がある場合に達成されます。 イーサリアムのプルーフ・オブ・ステークでは、ファイナリティは「チェックポイント」ブロックを用いて管理されます。 各エポックの最初のブロックがチェックポイントになります。 バリデータは、有効だと見なすチェックポイントのペアに対して投票を行います。 ステーキングされたイーサの合計のうち少なくとも3分の2が当該のチェックポイントのペアに対して投票した場合、これらのチェックポイントは更新されます。 2つの(ターゲットである)チェックポイントのうち、より新しいチェックポイントの方が「正当化」されます。 チェックポイントのペアにおけるより古いチェックポイントは、1つ前のエポックにおいて「ターゲット」のチェックポイントとしてすでに正当化されています。 こうして正当化されたチェックポイントは、「ファイナライズ済み」にアップグレードされます。 このチェックポイントをアップグレードするプロセスは、**[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**によって処理されます。 Casper-FFGはコンセンサスのためのブロックファイナリティツールです。 ブロックが一度ファイナライズされると、ステーカーの大多数のスラッシングなしには覆したり変更したりすることはできず、経済的に実行不可能になります。 -攻撃者は、ステーキングされたイーサの総供給量のうち少なくとも3分の1を犠牲にすれば、ファイナライズされたブロックを以前の状態に戻すことが可能になります。 このように設定されている具体的な理由については、こちらの[イーサリアム・ファウンデーションによるブログ投稿](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)をご覧ください。 ファイナリティを達成するには3分の2以上の投票が必要であるため、攻撃者は、ステーキングされたイーサ合計の3分の1を投じることで、ネットワークのファイナリティ実現を阻止することが可能です。 ただし、この攻撃を防ぐために、[インアクティブ・リーク](https://eth2book.info/bellatrix/part2/incentives/inactivity)という防御メカニズムが導入されています。 インアクティブ・リークは、チェーンが4エポック以上にわたりファイナライズに失敗した場合に発動します。 インアクティブ・リークが実行されると、多数派に対抗して投票したバリデータがステーキングしたイーサが没収されるため、多数派のユーザーが3分の2の過半数を取り戻し、チェーンのファイナライズを完了できるようになります。 +攻撃者は、ステーキングされたイーサの総供給量のうち少なくとも3分の1を犠牲にすれば、ファイナライズされたブロックを以前の状態に戻すことが可能になります。 この正確な理由は、こちらの[イーサリアム・ファウンデーションのブログ記事](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)で説明されています。 ファイナリティを達成するには3分の2以上の投票が必要であるため、攻撃者は、ステーキングされたイーサ合計の3分の1を投じることで、ネットワークのファイナリティ実現を阻止することが可能です。 これに対抗するメカニズムとして、[非アクティブリーク](https://eth2book.info/bellatrix/part2/incentives/inactivity)があります。 インアクティブ・リークは、チェーンが4エポック以上にわたりファイナライズに失敗した場合に発動します。 インアクティブ・リークが実行されると、多数派に対抗して投票したバリデータがステーキングしたイーサが没収されるため、多数派のユーザーが3分の2の過半数を取り戻し、チェーンのファイナライズを完了できるようになります。 -## 暗号経済におけるセキュリティとは {#crypto-economic-security} +## 暗号経済学的セキュリティ {#crypto-economic-security} バリデータを務めることは、ひとつのコミットメントです。 バリデータは、ブロックの検証／提案を行うのに必要な水準のハードウェアとネット接続を維持することが要求されます。 バリデータはその代償として、イーサを受け取ります（ステーキングした残高が増加します）。 一方で、バリデータとしてネットワークに参加することで、ユーザーは個人的な利益や迷惑行為を目的としてネットワークを攻撃できる手段が得られることも事実です。 これを防止する手段として、呼び出し時に参加しなかったバリデータはイーサ報酬を受け取ることができず、不正行為を行った場合には既存のステークが没収されます。 バリデータにおける不正行為とは主に、1つのスロットで複数のブロックを提案する場合(曖昧化)と、相互に矛盾するアテステーションを提出する場合の2種類が考えられます。 -スラッシングされるイーサの額は、ほぼ同時にスラッシング対象となるバリデータの数に応じて異なります。 これは[相関性ペナルティ](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty)と呼ばれており、スラッシングされる額がわずかである場合(1名のバリデータにおけるスラッシング額がステーキングした全体の1%未満である場合)から、ステーキング残高の100%が没収される場合(大規模なスラッシングイベント)までさまざまです。 スラッシングは、1日目には即時のペナルティ(最大1イーサまで)で科され、18日目にはコリレーション・ペナルティが科され、最終的に36日目にはネットワークからの強制退出が実行されます。そのため、コリレーション・ペナルティは、強制退出に至る期間の中間点で実行されることになります。 バリデータがネットワークに参加していても、投票を実行しない場合、アテステーションに対する軽微なペナルティが毎日科されます。 これらの防御システムはすべて、組織的な攻撃者による攻撃が非常にコスト高になるように設計されています。 +スラッシングされるイーサの額は、ほぼ同時にスラッシング対象となるバリデータの数に応じて異なります。 これは["相関ペナルティ"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty)として知られており、軽微な場合(単独でスラッシュされた単一バリデータのステークの約1%)から、バリデータのステークが100%破棄される(大量スラッシングイベント)場合まであります。 スラッシングは、1日目には即時のペナルティ(最大1イーサまで)で科され、18日目にはコリレーション・ペナルティが科され、最終的に36日目にはネットワークからの強制退出が実行されます。そのため、コリレーション・ペナルティは、強制退出に至る期間の中間点で実行されることになります。 バリデータがネットワークに参加していても、投票を実行しない場合、アテステーションに対する軽微なペナルティが毎日科されます。 +これらの防御システムはすべて、組織的な攻撃者による攻撃が非常にコスト高になるように設計されています。 -## フォーク・チョイス {#fork-choice} +## フォーク選択 {#fork-choice} -ネットワークが最適化された誠実な方法で実行されている場合、チェーンの先頭には常に新規ブロックが1つだけ存在し、すべてのバリデータがこの新規ブロックに対してアテステーションを実行しています。 しかし、ネットワークが遅延したり、ブロック提案者が曖昧化を実行した場合、各バリデータに対するチェーンの先頭のビューが異なる可能性があります。 このため、コンセンサスクライアントでは、どのフォークを支持すべきかについてのアルゴリズムが必要になります。 イーサリアムのプルーフ・オブ・ステークで採用されているアルゴリズムは[LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf)と呼ばれ、履歴においてアテステーションの重みが最大であるフォークを特定する方式です。 +ネットワークが最適化された誠実な方法で実行されている場合、チェーンの先頭には常に新規ブロックが1つだけ存在し、すべてのバリデータがこの新規ブロックに対してアテステーションを実行しています。 しかし、ネットワークが遅延したり、ブロック提案者が曖昧化を実行した場合、各バリデータに対するチェーンの先頭のビューが異なる可能性があります。 このため、コンセンサスクライアントでは、どのフォークを支持すべきかについてのアルゴリズムが必要になります。 プルーフ・オブ・ステークのイーサリアムで使われるアルゴリズムは[LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf)と呼ばれ、その履歴の中で最もアテステーションの重みが大きいフォークを特定することで機能します。 ## プルーフ・オブ・ステークとセキュリティ {#pos-and-security} -プルーフ・オブ・ワークと同様、プルーフ・オブ・ステークにおいても[51%攻撃](https://www.investopedia.com/terms/1/51-attack.asp)の脅威は存在しますが、プルーフ・オブ・ステークでは攻撃者のリスクがさらに高まります。 攻撃者は、ステーキングされたイーサ総量の51%を保有する必要があるからです。 必要なイーサを確保できれば、攻撃者は自分のアテステーションを用いて、希望するフォークでのアテステーションの蓄積量を最大にすることができます。 蓄積されたアテステーションの「重み」は、コンセンサスクライアントが正規チェーンを決定する際に参照する基準となるため、攻撃者は、この「重み」を操作することで、希望するフォークを正規チェーンにすることができます。 しかし、プルーフ・オブ・ワークと比較した場合、プルーフ・オブ・ステークは攻撃者に対する反撃をより柔軟に行えるという利点があります。 例えば、誠実なバリデータは、マイノリティのチェーン構築を継続することで、攻撃者のフォークを無視し、アプリや取引所、プールにも同様の対応を促すことができます。 さらに、攻撃者をネットワークから強制的に排除し、攻撃者がステーキングしたイーサを破壊するように決定することもできます。 これらの手段は、51%攻撃に対する強力な経済的防御メカニズムと言えます。 +プルーフ・オブ・ワークと同様に、プルーフ・オブ・ステークにも[51%攻撃](https://www.investopedia.com/terms/1/51-attack.asp)の脅威は存在しますが、攻撃者にとってはさらにリスクが高くなります。 攻撃者は、ステーキングされたイーサ総量の51%を保有する必要があるからです。 必要なイーサを確保できれば、攻撃者は自分のアテステーションを用いて、希望するフォークでのアテステーションの蓄積量を最大にすることができます。 蓄積されたアテステーションの「重み」は、コンセンサスクライアントが正規チェーンを決定する際に参照する基準となるため、攻撃者は、この「重み」を操作することで、希望するフォークを正規チェーンにすることができます。 しかし、プルーフ・オブ・ワークと比較した場合、プルーフ・オブ・ステークは攻撃者に対する反撃をより柔軟に行えるという利点があります。 例えば、誠実なバリデータは、マイノリティのチェーン構築を継続することで、攻撃者のフォークを無視し、アプリや取引所、プールにも同様の対応を促すことができます。 さらに、攻撃者をネットワークから強制的に排除し、攻撃者がステーキングしたイーサを破壊するように決定することもできます。 これらの手段は、51%攻撃に対する強力な経済的防御メカニズムと言えます。 51%攻撃以外にも、悪意のある者は次のような悪質な行動を企てる可能性があります。 @@ -64,7 +65,7 @@ lang: ja ## メリットとデメリット {#pros-and-cons} -| メリット | デメリット | +| 長所 | 短所 | | ---------------------------------------------------------------------------------------------------- | -------------------------------------------- | | ステーキングにより個人がネットワークの安全性に参画しやすくなり、分散化を促進。 バリデータノードは通常のラップトップで実行可能。 ステーキングプールを利用すると、32 ETH未満でもステーキング可能。 | プルーフ・オブ・ステークは若く、プルーフ・オブ・ワークと比較して実環境でのテストが少ない | | ステーキングはより分散型であり、 規模の経済がプルーフ・オブ・ワークのマイニングの場合と同じようには適用されない。 | プルーフ・オブ・ステークは、プルーフ・オブ・ワークよりも実装が複雑 | @@ -82,16 +83,16 @@ lang: ja - 不正に対する経済制裁により、プルーフ・オブ・ワークと比較して51%攻撃のコストが高くなる - 51%攻撃が暗号経済の防御を乗り越えた場合でも、正当なチェーンの社会的な回復が可能 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [プルーフ・オブ・ステークFAQ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _ビタリック・ブテリン_ +- [プルーフ・オブ・ステークFAQ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ - [プルーフ・オブ・ステークとは](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ -- [プルーフ・オブ・ステークとは何か、またその重要性](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ -- [なぜプルーフ・オブ・ステークなのか (2020年11月)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _ビタリック・ブテリン_ -- [プルーフ・オブ・ステーク: 弱い主観性の利点](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _ヴィタリック・ブテリン_ -- [プルーフ・オブ・ステークのイーサリアム対する攻撃と防御](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) -- [プルーフ・オブ・ステークの設計思想](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _ヴィタリック・ブテリン_ -- [ヴィタリック・ブテリンがLex Fridmanにプルーフ・オブ・ステークについて解説するビデオ](https://www.youtube.com/watch?v=3yrqBG-7EVE) +- [プルーフ・オブ・ステークとは何か、なぜそれが重要なのか](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [なぜプルーフ・オブ・ステークなのか (2020年11月)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [プルーフ・オブ・ステーク: 私が弱い主観性を愛するようになった経緯](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [プルーフ・オブ・ステークのイーサリアムにおける攻撃と防御](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [プルーフ・オブ・ステークの設計哲学](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [動画: ヴィタリック・ブテリンがレックス・フリードマンにプルーフ・オブ・ステークを解説](https://www.youtube.com/watch?v=3yrqBG-7EVE) ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/keys/index.md index 16827fb9733..79835cc47a2 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -1,20 +1,20 @@ --- -title: イーサリアムのプルーフ・オブ・ステークにおける鍵について -description: イーサリアムにおけるプルーフ・オブ・ステークのコンセンサスメカニズムで使用される各種の鍵の説明 +title: "イーサリアムのプルーフ・オブ・ステークにおける鍵について" +description: "イーサリアムにおけるプルーフ・オブ・ステークのコンセンサスメカニズムで使用される各種の鍵の説明" lang: ja --- イーサリアムでは、公開鍵と秘密鍵による暗号化を用いてユーザーの資産を保護しています。 公開鍵は、イーサリアムアドレスの基盤として使用されるもので、誰もが見ることができ、一意の識別子として使用されます。 一方で、プライベートキー(すなわち「秘密鍵」)はアカウント所有者以外はアクセスできないものでなければなりません。 秘密鍵は、トランザクションおよびデータに「署名」するために用いられ、特定の秘密鍵の所有者がその鍵のアクションを承認したことを暗号化によって証明できるものです。 -イーサリアムの鍵は、[楕円曲線暗号](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)を用いて生成されます。 +イーサリアムの鍵は、[楕円曲線暗号](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)を使用して生成されます。 -ただし、イーサリアムにおける[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow)から[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)への移行に伴い、新たな種類の鍵が追加されています。 従来の鍵も、これまでとまったく同様に機能し、楕円曲線暗号を用いて生成された鍵により保護されるアカウントは従来とまったく変更されません。 しかし、イーサのステーキングやバリデータの実行によりプルーフ・オブ・ステークに参加するには、新しい種類の鍵が必要になります。 この新しい種類の鍵は、暗号化の手段を必要とする非常に多くのバリデータ間におけるメッセージのやりとりが必要であるというスケーラビリティの課題を克服するために導入されたもので、メッセージを集約することで、ネットワークがコンセンサスを実現するために必要なコミュニケーションの規模を縮小することができます。 +しかし、イーサリアムが[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow)から[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)に移行した際、新しい種類の鍵がイーサリアムに追加されました。 従来の鍵も、これまでとまったく同様に機能し、楕円曲線暗号を用いて生成された鍵により保護されるアカウントは従来とまったく変更されません。 しかし、イーサのステーキングやバリデータの実行によりプルーフ・オブ・ステークに参加するには、新しい種類の鍵が必要になります。 この新しい種類の鍵は、暗号化の手段を必要とする非常に多くのバリデータ間におけるメッセージのやりとりが必要であるというスケーラビリティの課題を克服するために導入されたもので、メッセージを集約することで、ネットワークがコンセンサスを実現するために必要なコミュニケーションの規模を縮小することができます。 -この新しい種類の鍵では、 [**Boneh-Lynn-Shacham (BLS)**署名スキーム](https://wikipedia.org/wiki/BLS_digital_signature)を使用します。 BLSは、署名を非常に効率的に集約できるだけでなく、集約された個々のバリデータの鍵に対してリバースエンジニアリングを実行することも可能であり、バリデータ間のアクションを管理する上で理想的なソリューションです。 +この新しい種類の鍵は、[**Boneh-Lynn-Shacham (BLS)** 署名方式](https://wikipedia.org/wiki/BLS_digital_signature)を使用します。 BLSは、署名を非常に効率的に集約できるだけでなく、集約された個々のバリデータの鍵に対してリバースエンジニアリングを実行することも可能であり、バリデータ間のアクションを管理する上で理想的なソリューションです。 -## バリデータ向けの2種類の鍵 {#two-types-of-keys} +## 2種類のバリデータ鍵 {#two-types-of-keys} -イーサリアムでは、プルーフ・オブ・ステークへの移行前は、楕円曲線ベースの秘密鍵だけを用いて資金にアクセスしていました。 プルーフ・オブ・ステークの導入により、ソロステークの実行を希望するユーザーは、**バリデータ鍵**と**引き出し鍵**の両方が必要になりました。 +イーサリアムでは、プルーフ・オブ・ステークへの移行前は、楕円曲線ベースの秘密鍵だけを用いて資金にアクセスしていました。 プルーフ・オブ・ステークの導入により、ソロステーカーになることを希望するユーザーには、**バリデータ鍵**と**出金鍵**も必要になりました。 ### バリデータ鍵 {#validator-key} @@ -25,7 +25,7 @@ lang: ja バリデータ秘密鍵は、ブロックの提案やアテステーションといったオンチェーンの操作を行うために使用します。 このため、バリデータ秘密鍵は常にホットウォレットで管理しなければなりません。 -バリデータ秘密鍵におけるこの柔軟性は、ひとつの端末から他の端末に移動させるのが容易であるという利点がありますが、紛失／盗難時には、以下のような**悪意の行為**の被害を受ける可能性があります： +この柔軟性により、バリデータの署名鍵をあるデバイスから別のデバイスに非常に迅速に移動できるという利点がありますが、紛失または盗難された場合、攻撃者はいくつかの方法で**悪意のある行動**をとることができます: - 以下の行為に対して、バリデータの資産がスラッシングされうる： - 提案者となり、同一スロットにおいて2つの異なるビーコンブロックに署名してしまう @@ -33,13 +33,13 @@ lang: ja - アテスターとなり、同一のターゲットに対して2つの異なるアテステーションを署名する場合 - 自発的な退出を強制して、当該のバリデータがステーキングを行えなくし、出金鍵の所有者がバリデータのETH残高にアクセスできるようにする場合 -**バリデータ公開鍵**は、ユーザーがステーキング入金コントラクトにETHを入金する際のトランザクションデータに含まれています。 これは、_入金データ_と呼ばれ、イーサリアムがバリデータを特定するために用いられます。 +**バリデータ公開鍵**は、ユーザーがステーキングの入金コントラクトにETHを入金する際のトランザクションデータに含まれています。 これは、入金データと呼ばれ、イーサリアムがバリデータを特定するために用いられます。 -### 引出における認証情報 {#withdrawal-credentials} +### 出金の認証情報 {#withdrawal-credentials} -すべてのバリデータは、_出金の認証情報_と呼ばれるプロパティを持ちます。 この32バイトのフィールドは、BLSによる出金の認証情報を表す`0x00`か、実行アドレスを示す認証情報を表す`0x01`のどちらかで始まります。 +すべてのバリデータは、_出金の認証情報_として知られるプロパティを持っています。 この32バイトのフィールドは、BLSによる出金の認証情報を表す`0x00`か、実行アドレスを示す認証情報を表す`0x01`のどちらかで始まります。 -`0x00`のBLS キーを持つバリデータは、超過残高の支払いを実行したり、ステーキングした資金を全額出金したい場合、実行アドレスを示すこれらの認証情報を更新する必要があります。 具体的には、鍵を最初に生成する際において入金データに含まれていた実行アドレスを提供するか、_あるいは_事後的に出金鍵を用いて署名し、` BLSToExecutionChange`のメッセージをブロードキャストする必要があります。 +`0x00`のBLS鍵を持つバリデータは、超過残高の支払いやステーキングからの全額出金を有効にするために、これらの認証情報を実行アドレスを指すように更新する必要があります。 これは、最初の鍵生成時に入金データで実行アドレスを提供するか、_または_後で出金鍵を使用して`BLSToExecutionChange`メッセージに署名し、ブロードキャストすることで行えます。 ### 出金鍵 {#withdrawal-key} @@ -50,17 +50,19 @@ lang: ja - 出金用**秘密**鍵 - 出金用**公開**鍵 -出金の認証情報を`0x01`タイプに更新する前にこの鍵を紛失してしまうと、バリデータは残高にアクセスできなくなります。 ブロックや署名に必要なのはバリデータの秘密鍵であるため、この場合でも、バリデータはアテステーションやブロックに署名を行うことができますが、出金鍵を紛失してしまった場合、バリデータが署名を行う理由はほぼ／まったくなくなります。 +出金の認証情報を0x01タイプに更新する前にこの鍵を紛失してしまうと、バリデータは残高にアクセスできなくなります。 ブロックや署名に必要なのはバリデータの秘密鍵であるため、この場合でも、バリデータはアテステーションやブロックに署名を行うことができますが、出金鍵を紛失してしまった場合、バリデータが署名を行う理由はほぼ／まったくなくなります。 イーサリアムのアカウント鍵とバリデータ鍵を分離することで、1人のユーザーが複数のバリデータを実行することが可能になります。 -![バリデータ鍵の図](validator-key-schematic.png) +![バリデータ鍵の概略図](validator-key-schematic.png) -## シードフレーズから鍵を導出するには {#deriving-keys-from-seed} +**注**: 現在、ステーキングの責務から退出してバリデータの残高を引き出すには、バリデータ鍵で[自発的退出メッセージ(VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1)に署名する必要があります。 ただし、[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002)は、将来、ユーザーが出金鍵で退出メッセージに署名することで、バリデータの退出をトリガーし、その残高を引き出すことを可能にする提案です。 これにより、[ステーキング・アズ・ア・サービス・プロバイダー](/staking/saas/#what-is-staking-as-a-service)にETHを委任するステーカーが自身の資金の管理を維持できるようになり、信頼の仮定が軽減されます。 + +## シードフレーズからの鍵の導出 {#deriving-keys-from-seed} ユーザーが32ETHをステークするには、相互に完全に独立した2つの鍵セットが新たに必要になるため、特に複数のバリデータを実行するユーザーにとっては鍵の管理がとても煩雑になります。 この状況を回避するため、1つの共通のシークレットから複数のバリデータ鍵を導出できるようになっており、この1つのシークレットを保存することで、複数のバリデータ鍵へのアクセスが可能になります。 -ユーザーが各自のウォレットに[アクセス](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0)する際には、[ニーモニック](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase)やパスの機能が目に入るでしょう。 ニーモニックとは、特定の秘密鍵に対する当初のシードとして機能する単語のつらなりです。 ニーモニックは、追加のデータと結合することで、「マスター鍵」と呼ばれるハッシュを生成できます。 マスター鍵は、特定のツリーにおけるルートだと考えればよいでしょう。 このルートから派生したブランチについては、階層的なパスを用いて導出できるので、子ノードは親ノードのハッシュとツリー上のインデックスを結合したものとして存在することになります。 ニーモニックによる鍵の生成については、[BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)標準と[BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)標準をご覧ください。 +[ニーモニック](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase)とパスは、ユーザーが自分のウォレットに[アクセスする](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0)際によく遭遇する顕著な機能です。 ニーモニックとは、特定の秘密鍵に対する当初のシードとして機能する単語のつらなりです。 ニーモニックは、追加のデータと結合することで、「マスター鍵」と呼ばれるハッシュを生成できます。 マスター鍵は、特定のツリーにおけるルートだと考えればよいでしょう。 このルートから派生したブランチについては、階層的なパスを用いて導出できるので、子ノードは親ノードのハッシュとツリー上のインデックスを結合したものとして存在することになります。 ニーモニックベースの鍵生成に関する[BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)および[BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)標準についてお読みください。 パスは、以下のような構造を持ちます。ハードウェアのウォレットを使用したことがあるユーザーにとっては、おなじみでしょう。 @@ -74,7 +76,7 @@ m/44'/60'/0'/0` master_key / purpose / coin_type / account / change / address_index ``` -このロジックにより、ツリーの共通ルートから異なるブランチをいくつでも設定できるため、ユーザーは1つの**ニーモニックフレーズ**にいくつでもバリデータを追加することができます。 ユーザーは、ニーモニックフレーズを用いて、**鍵をいくつでも導出**することができます。 +このロジックにより、ツリーのルートは共通で、分岐点で差別化できるため、ユーザーは単一の**ニーモニックフレーズ**にできるだけ多くのバリデータを関連付けることができます。 ユーザーは、ニーモニックフレーズを用いて、鍵をいくつでも導出することができます。 ``` [m / 0] @@ -86,11 +88,13 @@ master_key / purpose / coin_type / account / change / address_index [m / 2] ``` -各ブランチは、`/`で区切られるため、`m/2`は、マスター鍵で開始され、ブランチ2に従うことを意味します。 以下の図の場合、1つのニーモニックフレーズを用いて3つの出金鍵が保存され、それぞれに2つのバリデータが関連付けられています。 +各ブランチは、/で区切られるため、m/2は、マスター鍵で開始され、ブランチ2に従うことを意味します。 以下の図の場合、1つのニーモニックフレーズを用いて3つの出金鍵が保存され、それぞれに2つのバリデータが関連付けられています。 ![バリデータ鍵のロジック](multiple-keys.png) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [カール・ベークハイゼンによるイーサリアム・ファウンデーションのブログ記事](https://blog.ethereum.org/2020/05/21/keys/) -- [EIP-2333 BLS12-381 鍵の生成](https://eips.ethereum.org/EIPS/eip-2333) +- [Carl Beekhuizenによるイーサリアム・ファウンデーションのブログ投稿](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 BLS12-381 鍵生成](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: 実行レイヤーによってトリガーされる退出](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [大規模な鍵管理](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md index 56710ddac0f..3026dc01a20 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -1,6 +1,6 @@ --- -title: プルーフ・オブ・ステークとプルーフ・オブ・ワークの比較 -description: イーサリアムのプルーフ・オブ・ステークとプルーフ・オブ・ワークベースの合意メカニズムの比較 +title: "プルーフ・オブ・ステークとプルーフ・オブ・ワークの比較" +description: "イーサリアムのプルーフ・オブ・ステークとプルーフ・オブ・ワークベースの合意メカニズムの比較" lang: ja --- @@ -14,19 +14,19 @@ lang: ja ### 攻撃コスト {#cost-to-attack} -プルーフ・オブ・ステークでは、バリデータはスマートコントラクトに少なくとも32ETHをエスクロー(ステーク)する必要があります。 イーサリアムは、不正行為を行ったバリデータを罰するために、ステークされたイーサを破壊することができます。 合意に達するには、ステークされたイーサ全体の少なくとも66%が特定のブロックのセットに賛成票を投じる必要があります。 ステークの66％の投票を受けたブロックは「ファイナライズ」となり、削除や再編成ができなくなります。 +プルーフ・オブ・ステークでは、バリデータはスマートコントラクトに少なくとも32ETHをエスクロー(ステーク)する必要があります。 イーサリアムは、不正行為を行ったバリデータを罰するために、ステークされたイーサを破壊することができます。 合意に達するには、ステークされたイーサ全体の少なくとも66%が特定のブロックのセットに賛成票を投じる必要があります。 ステークの66%以上の投票を得たブロックは"ファイナライズ"され、削除や再編成ができなくなります。 ネットワークを攻撃するということは、チェーンのファイナライズを妨げたり、何らかの形で攻撃者に利益をもたらすように正規チェーン内のブロックの特定の構成を確保したりすることを意味する場合があります。 そのためには、攻撃者が大量のイーサを蓄積して直接投票するか、正直なバリデータをだまして特定の方法で投票させることにより、誠実なコンセンサスの道を妨害する必要があります。 正直なバリデータをだます洗練された低確率の攻撃は別として、イーサリアムを攻撃するコストは、攻撃者が自分たちに有利なコンセンサスに影響を与えるために蓄積しなければならないステークのコストです。 -攻撃の最低コストは総ステークの33%以上です。 攻撃者が総ステークの33%以上を保有している場合、オフラインになるだけでファイナリティ遅延が発生する可能性があります。 オンライン過半数がステークの66%を占め、再びチェーンを完成させることができるまで、オフラインのバリデータからステークを漏洩させる「非アクティブリーク」として知られるメカニズムがあるため、これはネットワークにとって比較的小さな問題です。 また理論的には、攻撃者がブロック生成者になるよう求められたときにブロックを 1つではなく2つ作成し、バリデータ全員に二重投票することで、総ステークの33%強でダブルファイナリティを引き起こすことも可能です。 各フォークでは、残りの誠実なバリデータの50%が各ブロックを最初に確認するだけでよいため、メッセージのタイミングを適切に調整できれば、両方のフォークを完了できる可能性があります。 これが成功する可能性は低いですが、攻撃者が二重ファイナリティを引き起こすことができた場合、イーサリアムコミュニティは、一方のフォークに従うことを決定する必要があります。その場合、攻撃者のバリデータは、必然的にもう一方のフォークでスラッシュされることになります。 +攻撃の最低コストは、総ステークの33%超です。 攻撃者が総ステークの33%超を保有している場合、オフラインになるだけでファイナリティ遅延が発生する可能性があります。 オンライン過半数がステークの66%を占め、再びチェーンを完成させることができるまで、オフラインのバリデータからステークを漏洩させる「非アクティブリーク」として知られるメカニズムがあるため、これはネットワークにとって比較的小さな問題です。 また理論的には、攻撃者がブロック生成者になるよう求められたときにブロックを 1つではなく2つ作成し、バリデータ全員に二重投票することで、総ステークの33%強でダブルファイナリティを引き起こすことも可能です。 各フォークでは、残りの誠実なバリデータの50%が各ブロックを最初に確認するだけでよいため、メッセージのタイミングを適切に調整できれば、両方のフォークを完了できる可能性があります。 これが成功する可能性は低いですが、攻撃者が二重ファイナリティを引き起こすことができた場合、イーサリアムコミュニティは、一方のフォークに従うことを決定する必要があります。その場合、攻撃者のバリデータは、必然的にもう一方のフォークでスラッシュされることになります。 -総ステークの33%以上を使用すると、攻撃者はイーサリアムネットワークに軽微な影響(ファイナリティ遅延)またはより深刻な影響 (二重ファイナリティ) を与える可能性があります。 ネットワーク上に14,000,000 ETH以上がステークされており、代表的な価格が1000 ドル/ETHであるため、これらの攻撃を仕掛ける最小コストは、`1000 x 14,000,000 x 0.33 = 46億2,000,000ドル`となります。 攻撃者はスラッシュによってこのお金を失い、ネットワークから排除されてしまいます。 再度攻撃するには、ステークの33%以上を再び蓄積し、バーンする必要があります。 ネットワークへの攻撃を試みるたびに、46億ドル以上の費用がかかります(1,000ドル/ETHで1,400万ETHをステークした場合)。 攻撃者はスラッシュされるとネットワークからも排除され、再参加するにはアクティベーションキューに参加する必要があります。 これは、攻撃者が合計ステークの33%以上を蓄積できる割合に対してだけでなく、すべてのバリデータをネットワークにオンボードするのにかかる時間にも、反復攻撃の割合が制限されることを意味します。 攻撃者が攻撃するたびに、攻撃者はさらに貧乏になり、結果として生じる供給ショックのおかげで、他のコミュニティメンバーはさらに裕福になります。 +総ステークの33%超を使用すると、攻撃者はイーサリアムネットワークに軽微な(ファイナリティ遅延)またはより深刻な(二重ファイナリティ)影響を与える可能性があります。 ネットワーク上に14,000,000 ETH以上がステークされており、代表的な価格が1000ドル/ETHである場合、これらの攻撃を仕掛けるための最低コストは `1000 x 14,000,000 x 0.33 = $4,620,000,000` となります。 攻撃者はスラッシュによってこのお金を失い、ネットワークから排除されてしまいます。 再度攻撃するには、ステークの33%超を再び蓄積し、それをバーン(焼却)する(再び)必要があります。 ネットワークへの攻撃を試みるたびに、46億ドル超の費用がかかります(1000ドル/ETHで1,400万ETHをステークした場合)。 攻撃者はスラッシュされるとネットワークからも排除され、再参加するにはアクティベーションキューに参加する必要があります。 これは、反復攻撃の頻度が、攻撃者が総ステークの33%超を蓄積できる速さだけでなく、すべてのバリデータをネットワークにオンボードするのにかかる時間によっても制限されることを意味します。 攻撃者が攻撃するたびに、攻撃者はさらに貧乏になり、結果として生じる供給ショックのおかげで、他のコミュニティメンバーはさらに裕福になります。 51%攻撃や総ステークの66%によるファイナリティ復帰などの他の攻撃では、必要なETHの量が大幅に増加するため、攻撃者にとってははるかにコストがかかります。 -これをプルーフ・オブ・ワークと比較してください。 プルーフ・オブ・ワークのイーサリアムに対する攻撃を開始するためには、総ネットワークハッシュレートの50%を継続的に所有するコストが必要でした。 このコストは、他のマイナーと競合して、プルーフ・オブ・ワーク・ソリューションを一貫して計算するために必要な、十分な計算能力を備えたハードウェアとランニングコストに相当します。 イーサリアムは主にASICではなくGPUでマイニングされていたため、コストを抑えることができていました(ただし、イーサリアムがプルーフ・オブ・ワークのままであった場合、ASICマイニングがさらに普及していた可能性もあります)。 攻撃者は、プルーフ・オブ・ワークのイーサリアムネットワークを攻撃するために、大量のハードウェアを購入し、それを稼働させるための電気代を支払う必要があります。しかし、その総コストは、攻撃を開始するのに十分なETHを蓄積するのに必要なコストよりも低くなります。 51%攻撃は、プルーフ・オブ・ワークの場合、プルーフ・オブ・ステークの20分の1以下の費用で実行できます。 攻撃が検出され、変更を削除するためにチェーンがハードフォークされた場合、攻撃者は同じハードウェアを繰り返し使用して新しいフォークを攻撃する可能性があります。 +これをプルーフ・オブ・ワークと比較してください。 プルーフ・オブ・ワークのイーサリアムに対する攻撃を開始するためのコストは、総ネットワークハッシュレートの50%超を継続的に所有するためのコストでした。 このコストは、他のマイナーと競合して、プルーフ・オブ・ワーク・ソリューションを一貫して計算するために必要な、十分な計算能力を備えたハードウェアとランニングコストに相当します。 イーサリアムは主にASICではなくGPUでマイニングされていたため、コストを抑えることができていました(ただし、イーサリアムがプルーフ・オブ・ワークのままであった場合、ASICマイニングがさらに普及していた可能性もあります)。 攻撃者は、プルーフ・オブ・ワークのイーサリアムネットワークを攻撃するために、大量のハードウェアを購入し、それを稼働させるための電気代を支払う必要があります。しかし、その総コストは、攻撃を開始するのに十分なETHを蓄積するのに必要なコストよりも低くなります。 51%攻撃は、プルーフ・オブ・ステークに比べ、プルーフ・オブ・ワークの方が[約20分の1](https://youtu.be/1m12zgJ42dI?t=1562)の費用で済みます。 攻撃が検出され、変更を削除するためにチェーンがハードフォークされた場合、攻撃者は同じハードウェアを繰り返し使用して新しいフォークを攻撃する可能性があります。 -### 複雑性 {#complexity} +### 複雑さ {#complexity} プルーフ・オブ・ステークはプルーフ・オブ・ワークよりもはるかに複雑です。 単純なプロトコルは、誤ったバグや意図しない影響が入り込みにくいため、プルーフ・オブ・ワークの安全性に有利になる可能性があります。 しかし、その複雑性は、長年にわたる研究開発、シミュレーション、テストネットの実装によって軽減されてきました。 プルーフ・オブ・ステークのプロトコルは、5つのプログラミング言語で、実行レイヤーとコンセンサスレイヤーのそれぞれを担当する5つの個別のチームによって独立して実装されており、クライアントのバグに対する回復力を提供します。 @@ -36,7 +36,7 @@ lang: ja プルーフ・オブ・ステークはプルーフ・オブ・ワークよりも複雑です。そのため、処理すべき潜在的な攻撃ベクトルもより多く存在します。 クライアントを接続する1つのピアツーピアネットワークの代わりに、2つのピアツーピアネットワークがあり、それぞれが別のプロトコルを実装しています。 各スロットでブロックを提案する特定のバリデータ1つを事前に選択すると、大量のネットワークトラフィックによってそのバリデータがオフラインになり、サービス妨害の可能性が生じます。 -攻撃者がブロックやアテステーションのリリースのタイミングを慎重に調整することで、それらが誠実なネットワークの一定割合で受信され、特定の方法で投票するように影響を与えることができます。 また、攻撃者は単純に十分なETHを蓄積してステーキングし、合意メカニズムを支配することもできます。 これらの攻撃ベクトルにはそれぞれ防御手段がありますが、プルーフ・オブ・ワークの下では十分な防御とはなりません。 +攻撃者がブロックやアテステーションのリリースのタイミングを慎重に調整することで、それらが誠実なネットワークの一定割合で受信され、特定の方法で投票するように影響を与えることができます。 また、攻撃者は単純に十分なETHを蓄積してステーキングし、合意メカニズムを支配することもできます。 これらの[攻撃ベクトルにはそれぞれ関連する防御策があります](/developers/docs/consensus-mechanisms/pos/attack-and-defense)が、プルーフ・オブ・ワークではこれらの攻撃ベクトル自体が存在しません。 ## 分散化 {#decentralization} @@ -46,7 +46,7 @@ lang: ja バリデータが自宅のコンピュータ上でローカルに実行し、分散化を最大限に高めることが、イーサリアムにとって最善の選択肢です。 そのため、イーサリアムは、ノードおよびバリデータを実行するためのハードウェア要件の増加に対する変更に反対しています。 -## サステナビリティ {#sustainability} +## 持続可能性 {#sustainability} プルーフ・オブ・ステークは、プルーフ・オブ・ワークに比べて、ブロックチェーンを保護するために必要な炭素排出量が少なくなっています。 プルーフ・オブ・ワークでは、ブロックをマイニングする権利をめぐり競争が繰り広げられています。 マイナーは、計算を速く実行できれば、成功する可能性が高くなるので、ハードウェアやエネルギー消費に投資する傾向があります。 この現象は、イーサリアムがプルーフ・オブ・ステークに移行する前に見られました。 プルーフ・オブ・ステークに移行する直前、イーサリアムの年間消費電力量は約78TWに達し、小国一国分の電力に匹敵していました。 しかし、移行後はエネルギー消費は約99.98%削減され、 イーサリアムはエネルギー効率の高い低炭素プラットフォームへと生まれ変わりました。 @@ -62,8 +62,8 @@ Justin Drakが、プルーフ・オブ・ワークよりも優れたプルーフ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [ヴィタリックによるプルーフ・オブ・ステークの設計哲学](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) -- [ヴィタリックによるプルーフ・オブ・ステークのFAQ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) -- [シンプルにPoSとPoWの比較を説明したビデオ](https://www.youtube.com/watch?v=M3EFi_POhps) +- [Vitalikによるプルーフ・オブ・ステークの設計思想](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Vitalikによるプルーフ・オブ・ステークに関するよくある質問](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [posとpowに関する「Simply Explained」のビデオ](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index d38009e3d05..59dfa3a5dbf 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -1,10 +1,10 @@ --- -title: プルーフ・オブ・ステークにおける報酬とペナルティ -description: イーサリアムのプルーフ・オブ・ステークのプロトコルにおけるインセンティブについて学ぶ +title: "プルーフ・オブ・ステークにおける報酬とペナルティ" +description: "イーサリアムのプルーフ・オブ・ステークのプロトコルにおけるインセンティブについて学ぶ" lang: ja --- -イーサリアムでは、ネイティブの暗号通貨であるイーサ(ETH)を使用することでセキュリティを維持しています。 ブロックの検証や、チェーンの先頭の特定に関与したいノードオペレーターは、イーサリアム上の[デポジットコントラクト](/staking/deposit-contract/)に対してイーサを入金する必要があります。 ノードの運用者は、ピアツーピアネットワークで受信した新規ブロックの正当性を確認するためのバリデータ・ソフトウェアを実行し、チェーンの先頭を特定するためのフォーク選択アルゴリズムを適用することで、報酬を得ることができます。 +イーサリアムでは、ネイティブの暗号通貨であるイーサ(ETH)を使用することでセキュリティを維持しています。 ブロックの検証やチェーンのヘッドの特定に参加したいノードオペレーターは、イーサリアムの[デポジットコントラクト](/staking/deposit-contract/)にイーサを入金します。 ノードの運用者は、ピアツーピアネットワークで受信した新規ブロックの正当性を確認するためのバリデータ・ソフトウェアを実行し、チェーンの先頭を特定するためのフォーク選択アルゴリズムを適用することで、報酬を得ることができます。 バリデータは、主に、1) 新規ブロックを確認し、それが正当なブロックでることを「証明」(アテステーション)すること、および2) バリデータの全体プールから選出された場合に、新規ブロックを提案すること、という2つの役割を担います。 バリデータがこれらのタスクの実行を要求された場合に実行できない場合、イーサの支払いを受け取る機会を逃すことになります。 バリデータはさらに、署名の集約作業や同期委員会に参加することが求められる場合もあります。 @@ -18,48 +18,49 @@ lang: ja ### 報酬 {#rewards} -バリデータは、ブロックが提案された場合と同期委員会に参加する際に、多数派のバリデータと同じ投票を行うことでで報酬を受け取ります。 各エポックにおける報酬額は、`べース報酬`により算出されます。 ベース報酬は、その他の報酬を算定する際の基準値です。 `ベース報酬`は、各エポックの最適な条件下において、1名のバリデータが受け取る平均報酬額を示す値です。 ベース報酬額は、当該バリデータにおける有効な残高と、アクティブなバリデータ数を掛け合わせて算出します。具体的な数式は、以下の通りです: +バリデータは、ブロックが提案された場合と同期委員会に参加する際に、多数派のバリデータと同じ投票を行うことでで報酬を受け取ります。 各エポックの報酬額は、`base_reward`から計算されます。 ベース報酬は、その他の報酬を算定する際の基準値です。 `base_reward`は、最適な条件下でバリデータがエポックごとに受け取る平均報酬を表します。 ベース報酬額は、当該バリデータにおける有効な残高と、アクティブなバリデータ数を掛け合わせて算出します。具体的な数式は、以下の通りです: ``` base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) ``` -この数式において、`base_reward_factor`は64であり、`base_rewards_per_epoch`は4で、`sum(active balance)`はアクティブなバリデータ全員がステーキングしたイーサの合計です。 +ここで`base_reward_factor`は64、`base_rewards_per_epoch`は4、`sum(active balance)`はすべてのアクティブなバリデータによってステークされたイーサの合計です。 -この数式により、ベース報酬は当該バリデータの有効な残高と比例し、ネットワークに含まれるバリデータの数と反比例することが分かります。 バリデータの数が増えれば、(`sqrt(N)`)により全体の発行額も増えますが、バリデータ1名あたりの`ベース報酬`は(`1/sqrt(N)`)により少なくなります。 これらの要因は、ステーキングを行うノードのAPRに影響を及ぼします。 この仕様の根拠については、[ヴィタリックの説明](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards)をご覧ください。 +この数式により、ベース報酬は当該バリデータの有効な残高と比例し、ネットワークに含まれるバリデータの数と反比例することが分かります。 バリデータが多いほど、全体の発行量は (`sqrt(N)` として) 大きくなりますが、バリデータあたりの `base_reward` は (`1/sqrt(N)` として) 小さくなります。 これらの要因は、ステーキングを行うノードのAPRに影響を及ぼします。 この理論的根拠については、[ヴィタリックのメモ](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards)をお読みください。 次に合計報酬を計算しますが、これは、それぞれが異なる重みを持つ5つの構成要素を合計して算出します。この重みは、合計報酬を算出するにあたり、各構成要素がどれだけ重要であるかを決定する値です。 5つの構成要素は、以下の通りです: ``` -1. ソース投票：バリデータが、適切なソース・チェックポイントに対して、適時に投票したかどうか。2. ターゲット投票：バリデータが、適切なターゲット・チェックポイントに対して、適時に投票したかどうか。 -3. ヘッド投票：バリデータが、適切な先頭ブロックに対して適時に投票したかどうか。 -4. 同期委員会の報酬：バリデータが、同期委員会に参加したかどうか。 -5. 提案者の報酬：バリデータが、適切なスロットにブロックを提案したかどうか。 +1. ソース投票：バリデータが正しいソースチェックポイントに対して適時に投票した +2. ターゲット投票：バリデータが正しいターゲットチェックポイントに対して適時に投票した +3. ヘッド投票：バリデータが正しいヘッドブロックに対して適時に投票した +4. 同期委員会報酬：バリデータが同期委員会に参加した +5. 提案者報酬：バリデータが正しいスロットでブロックを提案した ``` これらの構成要素に対する重み付けは以下のようになっています: ``` -TIMELY_SOURCE_WEIGHT uint64(14) -TIMELY_TARGET_WEIGHT uint64(26) -TIMELY_HEAD_WEIGHT uint64(14) -SYNC_REWARD_WEIGHT uint64(2) -PROPOSER_WEIGHT uint64(8) +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) ``` -各要素の重みを合計すると、64になります。 報酬額は、該当する重みの合計を64で割ることで算出されます。 つまり、ソース/ターゲット/先頭の投票を適時に行い、ブロックを提案し、同期委員会に参加した場合のベース報酬は、`64/64 * base_reward == base_reward`になります。 ただし、通常の場合バリデータはブロック提案者にはならないので、ブロック提案者に選出されない場合の報酬の上限は、`64-8 /64 * base_reward == 7/8 * base_reward`となります。 ブロック提案者に選出されず、同期委員会にも参加しない場合は、`64-8-2 / 64 * base_reward == 6.75/8 * base_reward`となります。 +各要素の重みを合計すると、64になります。 報酬額は、該当する重みの合計を64で割ることで算出されます。 適時にソース、ターゲット、ヘッドの投票を行い、ブロックを提案し、同期委員会に参加したバリデータは、`64/64 * base_reward == base_reward` を受け取ることができます。 ただし、バリデータは通常ブロック提案者ではないため、その最大報酬は `64-8 /64 * base_reward == 7/8 * base_reward` になります。 ブロック提案者でもなく、同期委員会にも属していないバリデータは、`64-8-2 / 64 * base_reward == 6.75/8 * base_reward`を受け取ることができます。 -さらに、アテステーションの迅速な実行を促すインセンティブとして、追加の報酬が付与されます。 これは、`inclusion_delay_reward`です。 追加遅延報酬は、`base_reward`に`1/delay`を掛けて算出され、`delay`は、ブロック提案とアテステーションとの間のスロット数です。 例えば、ブロック提案が発生してから1スロット内にアテステーションを送信した場合、アテステーションを行ったバリデータの報酬は`base_reward * 1/1 == base_reward`になります。 アテステーションを次のスロットで実行した場合の報酬は、`base_reward * 1/2`となります。 +さらに、アテステーションの迅速な実行を促すインセンティブとして、追加の報酬が付与されます。 これは `inclusion_delay_reward` です。 これは`base_reward`に`1/delay`を乗じた値と等しく、ここで`delay`はブロック提案とアテステーションを隔てるスロット数です。 例えば、アテステーションがブロック提案から1スロット以内に提出された場合、証明者は `base_reward * 1/1 == base_reward` を受け取ります。 アテステーションが次のスロットに到着した場合、証明者は`base_reward * 1/2`を受け取り、以下同様です。 -ブロック提案者は、当該ブロックに含まれる**それぞれの正当なアテステーション**ごとに、`8 / 64 * base_reward`を受け取りますので、実際の報酬額は、アテステーションを行うバリデータの数と比例します。 ブロック提案者はさらに、提案されたブロックに含まれる他のバリデータの不正行為の証拠を提出することで、報酬を追加することができます。 これらの報酬は、バリデータに対して誠実な行為を促す「アメ」だと言えます。 スラッシングを含むブロックの提案者は、`slashed_validators_effective_balance / 512`の報酬を得ます。 +ブロック提案者は、ブロックに含まれる**有効な各アテステーション**に対して `8 / 64 * base_reward` を受け取るため、実際の報酬額はアテステーションを行うバリデータの数に応じて変動します。 ブロック提案者はさらに、提案されたブロックに含まれる他のバリデータの不正行為の証拠を提出することで、報酬を追加することができます。 これらの報酬は、バリデータに対して誠実な行為を促す「アメ」だと言えます。 スラッシングを含むブロック提案者は `slashed_validators_effective_balance / 512` の報酬を得ます。 ### ペナルティ {#penalties} 以上は、適切に振る舞うバリデータの報酬ですが、ヘッド/ソース/ターゲットの投票を適時に行わないか、遅延した場合にはどうなるでしょうか？ -ターゲットおよびソースの投票を実行しなかった場合のペナルティは、アテステーションを実行した場合に受け取る報酬と同額です。 つまり、投票を行うことで残高が増えるのとは反対に、残高から報酬分が減額されます。 ヘッド投票を行わない場合のペナルティはありません(つまり、ヘッド投票を行った場合には報酬を得られますが、行わなくてもペナルティは発生しません)。 また、`inclusion_delay`に対してもペナルティは存在せず、追加の遅延による報酬がバリデータの残高に追加されないだけです。 ブロック提案を行わない場合についても、ペナルティは科せられません。 +ターゲットおよびソースの投票を実行しなかった場合のペナルティは、アテステーションを実行した場合に受け取る報酬と同額です。 つまり、投票を行うことで残高が増えるのとは反対に、残高から報酬分が減額されます。 ヘッド投票を行わなかった場合のペナルティはありません（つまり、ヘッド投票は報酬の対象にはなっても、ペナルティの対象になることはありません）。 `inclusion_delay`に関連するペナルティはありません。単に報酬がバリデータの残高に追加されないだけです。 ブロック提案を行わない場合についても、ペナルティは科せられません。 -報酬とペナルティに関する詳細については、[コンセンサス仕様](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md)を確認してください。 Bellatrixアップグレードにより、報酬およびペナルティが調整されました。調整の内容については、このダニー・ライアンとヴィタリックによる[「Peep an EIP」動画](https://www.youtube.com/watch?v=iaAEGs1DMgQ)をご覧ください。 +報酬とペナルティに関する詳細は、[コンセンサス仕様](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md)をお読みください。 報酬とペナルティはBellatrixアップグレードで調整されました。これについては、ダニー・ライアンとヴィタリックが議論しているこちらの[Peep an EIPビデオ](https://www.youtube.com/watch?v=iaAEGs1DMgQ)をご覧ください。 ## スラッシング {#slashing} @@ -69,21 +70,22 @@ PROPOSER_WEIGHT uint64(8) - あるブロックを「取り囲む」ブロックに対してアテステーションを提供した場合(事実上、履歴を変更した場合) - 同一ブロックの2つの候補にアテステーションを提供することで、「二重投票」を行った場合 -バリデータによるこのような行為が発見された場合、このバリデータはスラッシングの対象となります。 具体的には、対象となるバリデータがステーキングしたイーサの32分の1(上限は1ETH)がただちにバーンされ、さらに36日間の削除期間が開始されます。 この削除期間にわたり、バリデータのステークは徐々に減少します。 この期間の中間点(18日目)には追加のペナルティが科されますが、その額は、当該のスラッシング・イベントが発生する前の36日間においてスラッシングの対象となったすべてのバリデータがステークしたイーサの合計に基づいて決定されます。 つまり、スラッシング対象のバリデータが多いほど、このスラッシングの額が大きくなります。 最悪の場合、スラッシングは対象のバリデータにおける有効な残高が全額没収されます(つまり、スラッシング対象のバリデータが多数である場合、彼らはステークをすべて失う可能性があります)。 一方、1件のスラッシングイベントのみが発生した場合、バリデータのステークのうちごく一部しかバーンされません。 スラッシング対象のバリデータ数に応じて決定される中間地点におけるペナルティは、「コリレーション・ペナルティ」と呼ばれます。 +バリデータによるこのような行為が発見された場合、このバリデータはスラッシングの対象となります。 具体的には、対象となる32 ETHのバリデータから0.0078125 ETHが即時にバーンされ(アクティブバランスに応じて線形的に増加）、同時に36日の削除期間が開始されます。 この削除期間にわたり、バリデータのステークは徐々に減少します。 この期間の中間点(18日目)には追加のペナルティが科されますが、その額は、当該のスラッシング・イベントが発生する前の36日間においてスラッシングの対象となったすべてのバリデータがステークしたイーサの合計に基づいて決定されます。 つまり、スラッシング対象のバリデータが多いほど、このスラッシングの額が大きくなります。 最大スラッシュ額は、スラッシングされたすべてのバリデータの有効残高の全額です（つまり、多くのバリデータがスラッシングされた場合、彼らはステークの全額を失う可能性があります）。 一方、1件のスラッシングイベントのみが発生した場合、バリデータのステークのうちごく一部しかバーンされません。 スラッシング対象のバリデータ数に応じて決定される中間地点におけるペナルティは、「コリレーション・ペナルティ」と呼ばれます。 -## インアクティブ・リーク {#inactivity-leak} +## 無活動リーク {#inactivity-leak} コンセンサスレイヤーにおいて、4エポック連続でファイナライズが実行されない状態になると、「インアクティブ・リーク」と呼ばれる緊急プロトコルが実行されます。 インアクティブ・リークの究極的な目的は、チェーンがファイナリティを回復できる状況に戻すことです。 上述したように、ファイナリティを実現するには、ステークされたイーサの合計の3分の2が、ソースおよびターゲットのチェックポイントについて同意する必要があります。 バリデータ全体の3分の1以上のバリデータがオフラインになったり、適切なアテステーションを送信しない場合、3分の2のスーパーマジョリティによるチェックポイントのファイナライズが不可能になります。 インアクティブ・リークでは、インアクティブなバリデータに帰属するステークを最終的にはステーク合計の3分の1未満になるまで徐々に減少させることで、残りのアクティブなバリデータがチェーンをファイナライズできるようにします。 インアクティブなバリデータの数がどんなに大規模であろうと、最終的には残りのアクティブなバリデータがステーク合計の3分の2以上を支配できるようになります。 このメカニズムによるステークの喪失は、インアクティブなバリデータに対してできる限り早くアクティブな状態に復帰しなければならないという強力なインセンティブとして機能します。 Madallaテストネットにおいてインアクティブ・リークが発動した事例では、アクティブなバリデータの割合が全体の66%未満でしたが、ブロックチェーンの現在の先頭ブロックについてコンセンサスに達することができました。 インアクティブ・リークを実行した結果、ファイナリティを取り戻すことができたのです！ 合意メカニズムにおける報酬、ペナルティ、スラッシングは、個々のバリデータにおける適切な行為を促すように設計されています。 しかし、これらの設計上の選択により、複数のクライアントにわたりバリデータを平等に配分することを強く奨励するシステムとなっており、単独のクライアントによる支配を断固として拒否することができるはずです。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムのアップグレオード：インセンティブ・レイヤー](https://eth2book.info/altair/part2/incentives) -- [イーサリアムにおけるハイブリッド型のキャスパー・プロトコルによるインセンティブ](https://arxiv.org/pdf/1903.04205.pdf) -- [ヴィタリクによる注釈付き仕様](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) -- [Eth2においてスラッシングを避けるためのヒント](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [イーサリアムのアップグレード：インセンティブレイヤー](https://eth2book.info/altair/part2/incentives) +- [イーサリアムのハイブリッドCasperプロトコルにおけるインセンティブ](https://arxiv.org/pdf/1903.04205.pdf) +- [ヴィタリックの注釈付き仕様](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Eth2のスラッシングを防ぐヒント](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [EIP-7251におけるスラッシングペナルティの分析](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) -_ソース_ +_出典_ - _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md index 2aceda844de..1a7141c3dcd 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -1,14 +1,14 @@ --- -title: 弱い主観性 -description: 弱い主観性とプルーフ・オブ・ステーク(PoS)イーサリアムにおける役割 +title: "弱い主観性" +description: "弱い主観性とプルーフ・オブ・ステーク(PoS)イーサリアムにおける役割" lang: ja --- ブロックチェーンにおける主観性とは、現在の状態(ステート)に同意するために社会的な情報を信用することを指します。 ネットワーク上の他のピアから収集された情報に従って、複数の有効なフォークが選択されることがあります。 この逆は客観性で、すべてのノードがコード化されたルールを適用することによって必然的に同意し、有効なチェーンが1つだけ存在することを指します。 また、第三の状態として、弱い主観性と呼ばれるものがあります。 これは情報の最初のシードが社会的に取得された後、客観的に進むことができるチェーンを指します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページを理解するには、まず[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)の基礎を理解している必要があります。 +このページを理解するには、まず[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)の基礎を理解する必要があります。 ## 弱い主観性が解決する問題 {#problems-ws-solves} @@ -16,7 +16,7 @@ lang: ja ## 弱い主観性チェックポイント {#ws-checkpoints} -弱い主観性は、「弱い主観性チェックポイント」を使って、プルーフ・オブ・ステークのイーサリアムに実装されています。 弱い主観性チェックポイントとは、ネットワーク上のすべてのノードが正規チェーンに属していることに同意するステートルートです。 ブロックチェーンの始まりの位置にいないことを除いて、始まりのブロックと同じ「普遍的な真実」としての目的を果たします。 フォーク・チョイス・アルゴリズムは、そのチェックポイントで定義されたブロックチェーンの状態が正しく、その時点以降のチェーンを独立して客観的に検証することを信頼します。 弱い主観性チェックポイント前のブロックは変えられないため、「戻り制限」として機能します。 メカニズム設計の一部として、単に長いフォークが無効であると定義することで、長距離型攻撃を弱体化させます。 バリデータの引き出し期間よりも、弱い主観性チェックポイントを短い間隔で区切ることにより、ステークが引き出される前に、チェーンをフォークするバリデータは、少なくともある程度のしきい額のスラッシングを受けるようにします。ステークが引き出されたバリデータによって、新規参加者が不正なフォークに騙されることはなくなります。 +弱い主観性は、「弱い主観性チェックポイント」を使って、プルーフ・オブ・ステークのイーサリアムに実装されています。 弱い主観性チェックポイントとは、ネットワーク上のすべてのノードが正規チェーンに属していることに同意するステートルートです。 ブロックチェーンの始まりの位置にいないことを除いて、始まりのブロックと同様に「普遍的な真実」の目的を果たします。 フォーク・チョイス・アルゴリズムは、そのチェックポイントで定義されたブロックチェーンの状態が正しく、その時点以降のチェーンを独立して客観的に検証することを信頼します。 弱い主観性チェックポイント前のブロックは変えられないため、「戻り制限」として機能します。 メカニズム設計の一部として、単に長いフォークが無効であると定義することで、長距離型攻撃を弱体化させます。 バリデータの引き出し期間よりも、弱い主観性チェックポイントを短い間隔で区切ることにより、ステークが引き出される前に、チェーンをフォークするバリデータは、少なくともある程度のしきい額のスラッシングを受けるようにします。ステークが引き出されたバリデータによって、新規参加者が不正なフォークに騙されることはなくなります。 ## 弱い主観性チェックポイントとファイナライズされたブロックの違い {#difference-between-ws-and-finalized-blocks} @@ -30,10 +30,10 @@ lang: ja 最後に、他のノードからチェックポイントをリクエストすることができます。フルノードを実行している他のイーサリアムユーザーは、バリデータがブロックエクスプローラーからのデータに対し検証するチェックポイントを提供できます。 総じて、弱い主観性チェックポイントのプロバイダーを信頼することは、クライアントデベロッパーを信頼するのと同等の問題があると考えられます。 しかし、必要とされる総合的な信頼は低いです。 これらの考慮事項は、大多数のバリデータが共謀しブロックチェーンの代替フォークを作成するような非常にまれなイベントでのみ重要になるということに留意してください。 それ以外の状況では、選択できるイーサリアムチェーンは1つだけです。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [Eth2における弱い主観性](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) -- [Vitalik: 弱い主観性の利点](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) -- [弱い主観性(Tekuドキュメント)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/) -- [Phase-0弱い主観性ガイド](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [ヴィタリック：私がどのようにして弱い主観性を好きになったか](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [弱い主観性 (Tekuドキュメント)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [Phase-0 弱い主観性ガイド](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) - [イーサリアム2.0における弱い主観性の分析](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/index.md index 5c4a04a5c55..ca950e8b8a4 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/index.md @@ -1,27 +1,27 @@ --- -title: プルーフ・オブ・ワーク(PoW) -description: イーサリアムにおけるプルーフ・オブ・ワーク (PoW)プロトコルとその役割について +title: "プルーフ・オブ・ワーク(PoW)" +description: "イーサリアムにおけるプルーフ・オブ・ワーク (PoW)プロトコルとその役割について" lang: ja --- -イーサリアムのネットワークは、**[プルーフ・オブ・ワーク(PoW)](/developers/docs/consensus-mechanisms/pow)**という合意メカニズムを使用して始まりました。 このメカニズムにより、イーサリアムネットワークのノードは、ブロックチェーンに記録されたすべての情報に関してネットワーク全体で合意を取り、特定の種類の経済的な攻撃を防ぎました。 しかしながら、イーサリアムは2022年にプルーフ・オブ・ワーク(PoW)を停止し、これに代わる[プルーフ・オブ・ステーク(PoS)](/developers/docs/consensus-mechanisms/pos)の使用を開始しました。 +イーサリアムネットワークは、**[プルーフ・オブ・ワーク(PoW)](/developers/docs/consensus-mechanisms/pow)**というコンセンサスメカニズムを使用して始まりました。 このメカニズムにより、イーサリアムネットワークのノードは、ブロックチェーンに記録されたすべての情報に関してネットワーク全体で合意を取り、特定の種類の経済的な攻撃を防ぎました。 しかし、イーサリアムは2022年にプルーフ・オブ・ワークを停止し、代わりに[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)を使用し始めました。 - 現在、プルーフ・オブ・ワークは廃止されています。 イーサリアムの合意メカニズムにはプルーフ・オブ・ワークではなく、 現在はプルーフ・オブ・ステークが採用されています。 詳細については、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)と[ステーキング](/staking/)を参照してください。 + 現在、プルーフ・オブ・ワークは廃止されています。 イーサリアムの合意メカニズムにはプルーフ・オブ・ワークではなく、 現在はプルーフ・オブ・ステークが採用されています。 [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)と[ステーキング](/staking/)について詳しく読む。 ## 前提条件 {#prerequisites} -このページをよく理解するためには、まず[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、および[合意メカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。 +このページについて深く理解するには、事前に[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。 ## プルーフ・オブ・ワーク(PoW)とは {#what-is-pow} -ナカモトコンセンサスはプルーフ・オブ・ワークを利用した旧メカニズムで、分散型のイーサリアムネットワークが、アカウント残高やトランザクションの順序などについてコンセンサス(例: すべてのノードが合意すること)を得ることを可能にしました。 加えてユーザーのコインの「二重支出」を防ぎ、イーサリアムチェーンの攻撃や改ざんを非常に困難なものにしました。 これらのセキュリティは現在、[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)として知られる合意メカニズムを用いたプルーフ・オブ・ステークによりもたらされています。 +プルーフ・オブ・ワークを利用するナカモトコンセンサスは、分散型イーサリアムネットワークがアカウント残高やトランザクションの順序などについてコンセンサス(すなわち、すべてのノードが合意すること)を得ることをかつて可能にしていたメカニズムです。 加えてユーザーのコインの「二重支出」を防ぎ、イーサリアムチェーンの攻撃や改ざんを非常に困難なものにしました。 現在、これらのセキュリティプロパティは、[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)として知られるコンセンサスメカニズムを用いたプルーフ・オブ・ステークによってもたらされています。 ## プルーフ・オブ・ワークとマイニング {#pow-and-mining} @@ -39,7 +39,7 @@ lang: ja このブロックデータは、プルーフ・オブ・ワーク(PoW)に直接由来していました。 -### プルーフ・オブ・ワークの詳細 {#the-work} +### プルーフ・オブ・ワークにおける「ワーク」 {#the-work} プルーフ・オブ・ワークのプロトコルであるEthashでは、有効なノンスを持つブロックのみがチェーンに追加され、マイナーはブロックを生成するノンスを見つけるためにトライ&エラー(試行錯誤)を繰り返し、マイナー間の激しい競争を必要としました 。 @@ -47,7 +47,7 @@ lang: ja 難易度はハッシュのターゲット値の大きさを決定し、 ターゲットが小さいほど、有効なハッシュのセットは小さくなります。 一度ブロックが生成されると、他のマイナーやクライアントは驚くほど簡単にブロックを検証できました。 たとえ1つのトランザクションが変更された場合でも、ハッシュが全く異なり、不正が明らかになりました。 -まとめると、ハッシュはトランザクションの改竄の発見を容易にします。 また、プロセスとしてのプルーフ・オブ・ワークは、チェーンに対する攻撃への大きな抑止力にもなりました。 +まとめると、ハッシュによりトランザクションの改ざんを容易に発見できます。 また、プロセスとしてのプルーフ・オブ・ワークは、チェーンに対する攻撃への大きな抑止力にもなりました。 ### プルーフ・オブ・ワークとセキュリティ {#security} @@ -57,11 +57,11 @@ lang: ja 悪意のあるブロックを有効なものとして、一貫して作成するためには、悪意を持ったマイナーは他のマイナーに勝つ必要があります。そのためには、ネットワークのマイニングパワーの51%以上が必要でした。 その「ワーク」量には、多くの高価な計算能力が必要であり、それに費やされるエネルギーは、攻撃で得られる利益を上回る可能性さえありました。 -### プルーフ・オブ・ワークの経済 {#economics} +### プルーフ・オブ・ワークの経済性 {#economics} また、プルーフ・オブ・ワークは通貨を新規発行し、マイナーにインセンティブを与えていました。 -[コンスタンティノープルアップグレード](/ethereum-forks/#constantinople)以降、ブロックの生成を正常に行ったマイナーには、新たにミントされた2 ETHとトランザクションフィーの一部が報酬として支払われました。 また、Ommerブロックの場合には、1.75 ETHを補償しました。 Ommerブロックとは、あるマイナーが有効ブロックを生成したのとほぼ同時に、違うマイナーが有効なブロックを生成したことを指します。最終的にはどのチェーンが先端に入るかが決定されました。 このOmmerブロックは、通常ネットワークの遅延が原因で起こりました。 +[コンスタンティノープル・アップグレード](/ethereum-forks/#constantinople)以降、ブロックの作成に成功したマイナーは、新たに発行された2 ETHとトランザクション手数料の一部を報酬として受け取りました。 また、Ommerブロックの場合には、1.75 ETHを補償しました。 Ommerブロックとは、あるマイナーが有効ブロックを生成したのとほぼ同時に、違うマイナーが有効なブロックを生成したことを指します。最終的にはどのチェーンが先端に入るかが決定されました。 このOmmerブロックは、通常ネットワークの遅延が原因で起こりました。 ## ファイナリティ {#finality} @@ -69,19 +69,19 @@ lang: ja マイナーは分散して作業するため、2つの有効なブロックが同時にマイニングされることがありました。 これは一時的なフォークを作成します。 最終的には、これらのチェーンの内の1つが容認されたチェーンとなり、後続のブロックがマイニングされて追加され、チェーンが長くなっていきました。 -さらに複雑なことに、一時的なフォークで拒否されたトランザクションが、容認されたチェーンの方に含まれていない可能性がありました。 これはトランザクションが取り消される可能性があることを意味します。 そのため、ファイナリティとは、トランザクションを取り消し不可能と見なすまでに待機する時間を指します。 以前のプルーフ・オブ・ワークのイーサリアムでは、特定のブロック`N`の上に多くのブロックをマイニングすればするほど、`N`のトランザクションが成功し、元に戻されなくなり、より高い信頼性を得られました。 現在のプルーフ・オブ・ステークではファイナリティは確率的なものではなく、明示的で、ブロックのプロパティによりファイナリティに至ります。 +さらに複雑なことに、一時的なフォークで拒否されたトランザクションが、容認されたチェーンの方に含まれていない可能性がありました。 これはトランザクションが取り消される可能性があることを意味します。 そのため、ファイナリティとは、トランザクションを取り消し不可能と見なすまでに待機する時間を指します。 以前のプルーフ・オブ・ワークのイーサリアムでは、特定のブロック`N`の上により多くのブロックがマイニングされるほど、`N`内のトランザクションが成功し、覆されることはないという確信度が高まりました。 現在のプルーフ・オブ・ステークではファイナリティは確率的なものではなく、明示的で、ブロックのプロパティによりファイナリティに至ります。 -## プルーフ・オブ・ワークのエネルギー使用 {#energy} +## プルーフ・オブ・ワークのエネルギー消費 {#energy} -ネットワークを安全に保つために必要なエネルギー量は、プルーフ・オブ・ワークが批判を受ける大きな要因です。 セキュリティと分散化を維持するために、プルーフ・オブ・ワークのイーサリアムは多量のエネルギーを消費しました。 イーサリアムは、プルーフ・オブ・ステークに移行する少し前、マイナーによる年間消費電力量が合計で年間約70 TWhに達していました(2022年7月18日の[digiconomist](https://digiconomist.net/)によるとチェコ共和国の年間消費電力量とほぼ同等) 。 +ネットワークを安全に保つために必要なエネルギー量は、プルーフ・オブ・ワークが批判を受ける大きな要因です。 セキュリティと分散化を維持するために、プルーフ・オブ・ワークのイーサリアムは多量のエネルギーを消費しました。 プルーフ・オブ・ステークへの移行直前、イーサリアムのマイナーは年間合計で約70 TWhを消費していました(2022年7月18日の[digiconomist](https://digiconomist.net/)によると、これはチェコ共和国の消費量とほぼ同じです)。 ## メリットとデメリット {#pros-and-cons} -| メリット | デメリット | -| ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | -| プルーフ・オブ・ワークは中立。 開始時にETHは必要なく、ブロック報酬により残高が0 ETHから増える。 [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)では、最初にETHが必要。 | プルーフ・オブ・ワークはエネルギーを大量に消費するため、環境への悪影響がある。 | -| プルーフ・オブ・ワークは、長年にわたって、ビットコインやイーサリアムを安全性と分散性を維持してきた十分にテスト・試行された合意メカニズム。 | マイニングをしたい場合は、専門機器が必要となり、始めるにあたって多額の投資が必要。 | -| プルーフ・オブ・ステークと比較すると、実装が比較的容易。 | 必要な計算量が増えるため、マイニングプールがマイニングゲームを支配する可能性があり、集中化とセキュリティのリスクにつながる。 | +| 長所 | 短所 | +| ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | +| プルーフ・オブ・ワークは中立。 開始時にETHは必要なく、ブロック報酬により残高が0 ETHから増える。 [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)では、まずETHが必要です。 | プルーフ・オブ・ワークはエネルギーを大量に消費するため、環境への悪影響がある。 | +| プルーフ・オブ・ワークは、長年にわたって、ビットコインやイーサリアムを安全性と分散性を維持してきた十分にテスト・試行された合意メカニズム。 | マイニングをしたい場合は、専門機器が必要となり、始めるにあたって多額の投資が必要。 | +| プルーフ・オブ・ステークと比較すると、実装が比較的容易。 | 必要な計算量が増えるため、マイニングプールがマイニングゲームを支配する可能性があり、集中化とセキュリティのリスクにつながる。 | ## プルーフ・オブ・ステークとの比較 {#compared-to-pos} @@ -94,16 +94,16 @@ lang: ja [プルーフ・オブ・ステークの詳細](/developers/docs/consensus-mechanisms/pos/) -## 映像で学びたい人向け {#visual-learner} +## 映像で学びたい場合 {#visual-learner} -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [マジョリティ攻撃](https://en.bitcoin.it/wiki/Majority_attack) -- [ファイナリティ概念について](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [マジョリティアタック(多数派攻撃)](https://en.bitcoin.it/wiki/Majority_attack) +- [決済のファイナリティについて](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) -### ビデオ {#videos} +### 動画 {#videos} - [プルーフ・オブ・ワークプロトコルの技術的な説明](https://youtu.be/9V1bipPkCTU) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/index.md index ffe524c3904..b21b31b9c00 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -1,6 +1,6 @@ --- -title: マイニング -description: マイニングがイーサリアムでどのように機能していたのかの説明 +title: "マイニング" +description: "マイニングがイーサリアムでどのように機能していたのかの説明" lang: ja --- @@ -13,9 +13,9 @@ lang: ja -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをよく理解するためには、まず[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)について読むことをお勧めします。 +このページをより深く理解するために、まず[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)についてお読みいただくことをお勧めします。 ## イーサリアムのマイニングとは {#what-is-ethereum-mining} @@ -31,41 +31,41 @@ Etherのマイニング ＝ ネットワークの保護 イーサリアムのような分散型システムでは、全員がトランザクションに同意する必要があります。 マイナーは多くの計算能力を必要とするパズルを解いてブロックを生成することで、これを実現し、攻撃からネットワークを保護していました。 -[プルーフ・オブ・ワークの詳細](/developers/docs/consensus-mechanisms/pow/) +[プルーフ・オブ・ワークについての詳細](/developers/docs/consensus-mechanisms/pow/) 以前は、コンピュータを使って誰でもイーサリアムネットワークでマイニング可能でしたが、 誰もがETHのマイニングで利益を得られるわけではありませんでした。 多くの場合マイナーは専用のコンピュータハードウェアを購入し、安価なエネルギー源を入手する必要がありました。 平均的なコンピュータでは、マイニングに関連するコストをまかなうのに十分なブロック報酬を得ることはほとんどありませんでした。 -### マイニング・コスト {#cost-of-mining} +### マイニングのコスト {#cost-of-mining} - マイニング装置の構築と維持に必要なハードウェアの潜在的なコスト - マイニング装置に電力を供給するための電気コスト - マイニングプール利用の場合は、プールで生成された各ブロックごとにかかる一律の手数料が発生 - マイニング装置(換気、エネルギー監視、電気配線など)をサポートする設備の潜在的なコスト -さらにマイニングの収益性を詳しく確認するには、[Etherscan](https://etherscan.io/ether-mining-calculator)などが提供するマイニング計算機をご使用ください。 +マイニングの収益性についてさらに詳しく知るには、[Etherscan](https://etherscan.io/ether-mining-calculator)が提供しているようなマイニング計算機を使用してください。 -## イーサリアムトランザクションのマイニング方法 {#how-ethereum-transactions-were-mined} +## イーサリアムのトランザクションはどのようにマイニングされたか {#how-ethereum-transactions-were-mined} -以下に、イーサリアムのプルーフ・オブ・ワークにおいてトランザクションがどのようにミントされていたのかについて概要を説明します。 イーサリアムのプルーフ・オブ・ステークにおけるミントのプロセスについては、[こちら](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos)にも同様の説明があります。 +以下に、イーサリアムのプルーフ・オブ・ワークにおいてトランザクションがどのようにミントされていたのかについて概要を説明します。 イーサリアムのプルーフ・オブ・ステークにおけるこのプロセスの同様の説明は、[こちら](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos)でご覧いただけます。 -1. [アカウント](/developers/docs/accounts/)の秘密鍵を使って、[トランザクション](/developers/docs/transactions/)リクエストを書き込み、署名する。 -2. 次に[ノード](/developers/docs/nodes-and-clients/)からイーサリアムネットワーク全体にトランザクションリクエストをブロードキャストする。 +1. ユーザーが、ある[アカウント](/developers/docs/accounts/)の秘密鍵で[トランザクション](/developers/docs/transactions/)リクエストを作成して署名します。 +2. ユーザーは、ある[ノード](/developers/docs/nodes-and-clients/)からイーサリアムネットワーク全体にトランザクションリクエストをブロードキャストします。 3. 新しいトランザクションリクエストを受けると、イーサリアムネットワークの各ノードがリクエストをローカルのメンプールに追加する(メンプールとはブロックのブロックチェーンにまだコミットされていないすべてのトランザクションリクエストのリスト)。 -4. ある時点で、マイニングノードは数十または数百のトランザクションリクエストを獲得できる[トランザクションフィー](/developers/docs/gas/)を最大化しつつ、ブロックのガスリミットを超えない方法で[ブロック](/developers/docs/blocks/)に集約する。 次に、マイニングノードは下記を実施: - 1. 各トランザクションリクエストの有効性を確認し(つまり、署名を作成していないアカウントからEtherを送信していない、リクエスト形式が正しくないなど)、リクエストのコードを実行して、 EVMのローカルコピーの状態を変更する。 マイナーは、トランザクションリクエストごとにトランザクションフィーを報酬として自分のアカウントに支払う。 +4. ある時点で、マイニングノードは、ブロックのガスリミットを超えない範囲で、獲得する[トランザクションフィー](/developers/docs/gas/)を最大化するような方法で、数十から数百のトランザクションリクエストを候補[ブロック](/developers/docs/blocks/)に集約します。 次に、マイニングノードは下記を実施: + 1. 各トランザクションリクエストの有効性を検証し(すなわち、誰も署名を作成していないアカウントからetherを転送しようとしていないこと、リクエストの形式が不正でないことなど)、リクエストのコードを実行して、EVMのローカルコピーの状態を変更します。 マイナーは、トランザクションリクエストごとにトランザクションフィーを報酬として自分のアカウントに支払う。 2. ブロック内のすべてのトランザクションリクエストが検証され、ローカルのEVMコピー上で実行されると、潜在的なブロックに対するプルーフ・オブ・ワークの「正当性の証明書」の作成プロセスを開始する。 5. 最終的に、マイナーは特定のトランザクションリクエストを含むブロックの証明書の作成を完了する。 その後、マイナーは証明書と新しいEVM状態のチェックサムを含む、完成したブロックをブロードキャストする。 6. 他のノードについては、新しいブロックを受け取り、 証明書を検証し、ブロック自体ですべてのトランザクションを実行する(ユーザーによって最初にブロードキャストされたトランザクションを含む)。 加えて、すべてのトランザクションの実行後の新しいEVM状態のチェックサムが、マイナーのブロックによって要求された状態のチェックサムと一致することを確認する。 その時になって始めて、他のノードがブロックチェーンの末尾にこのブロックを追加し、新しいEVM状態を正規の状態として受け入れる。 7. 各ノードは、条件を満たしていないトランザクションリクエストのローカルのメンプールから、新しいブロック内の全トランザクションを削除する。 8. ネットワークに新たに参加する新規ノードは、このトランザクションを含むブロックを含む、すべてのブロックを順にダウンロードする。 ローカルEVMコピーを初期化し(ブランク状態のEVMとして開始)、ローカルEVMコピーの上でブロックですべてのトランザクションを実行するプロセスを実行し、各ブロックの状態チェックサムを検証する。 -すべてのトランザクションは、マイニング(新しいブロックに追加し、最初に伝播すること)が1回だけ実行され、その後EVMの正規ステートを前進させるプロセスですべての参加者が実行、検証します。 これは、**信頼せず、確認する**というブロックチェーンの中心的な考え方を反映したものです。 +すべてのトランザクションは、マイニング(新しいブロックに追加し、最初に伝播すること)が1回だけ実行され、その後EVMの正規ステートを前進させるプロセスですべての参加者が実行、検証します。 これはブロックチェーンの中心的な信条の一つを強調しています：**信頼するな、検証せよ**。 -## オマー (アンクル) ブロック {#ommer-blocks} +## Ommer (アンクル) ブロック {#ommer-blocks} -プルーフ・オブ・ワークによるブロックのマイニングは、確率論的な作業でした。つまり、ネットワークが遅延すると、2つの有効なブロックが同時に公開される可能性がありました。 この場合、プロトコルは最長の(つまり、「正当性」が最も高い)チェーンを決定するのと同時に、チェーンに含まれなかったが正当である提案されたブロックに対しても部分的な報酬を提供することで、公平性を保証する必要がありました。 これにより、より小規模なマイナー(レイテンシーが大きくなる可能性が高い)も[オマー](/glossary/#ommer)のブロック報酬を通じて収益を得られるため、イーサリアムの分散化に貢献しました。 +プルーフ・オブ・ワークによるブロックのマイニングは、確率論的な作業でした。つまり、ネットワークが遅延すると、2つの有効なブロックが同時に公開される可能性がありました。 この場合、プロトコルは最長の(つまり、「正当性」が最も高い)チェーンを決定するのと同時に、チェーンに含まれなかったが正当である提案されたブロックに対しても部分的な報酬を提供することで、公平性を保証する必要がありました。 これにより、より小規模なマイナー(レイテンシーが大きくなる可能性が高い)も[ommer](/glossary/#ommer)ブロック報酬を通じて収益を得られるため、ネットワークのさらなる分散化が促進されました。 -「オマー」とは、親の同生を示すジェンダーニュートラルの好ましい用語ですが、「アンクル」と呼ばれることもあります。 **イーサリアムがプルーフ・オブ・ステークに移行して以来、各スロットにつき1名の提案者のみが選択されるため**、オマーブロックのマイニングは実行されていません。 この変更については、マイニングされたオマーブロックの[履歴チャート](https://ycharts.com/indicators/ethereum_uncle_rate)で確認できます。 +「オマー」とは、親の同生を示すジェンダーニュートラルの好ましい用語ですが、「アンクル」と呼ばれることもあります。 **イーサリアムがプルーフ・オブ・ステークに移行して以来、各スロットで選出される提案者は1人のみとなったため、ommerブロックはもはやマイニングされていません**。 この変更は、マイニングされたommerブロックの[履歴チャート](https://ycharts.com/indicators/ethereum_uncle_rate)を見ることで確認できます。 ## ビジュアルデモ {#a-visual-demo} @@ -73,14 +73,14 @@ Etherのマイニング ＝ ネットワークの保護 -## マイニングのアルゴリズム {#mining-algorithm} +## マイニングアルゴリズム {#mining-algorithm} -イーサリアムメインネットで唯一使われたアルゴリズムとして [「Ethash」](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/)があります。 Ethashは、 [「ダガーハシモト」](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/)として知られるオリジナルの研究開発アルゴリズムの後継でした。 +イーサリアムメインネットが使用したマイニングアルゴリズムは、['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/)の1つだけです。 Ethashは、['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/)として知られるオリジナルの研究開発アルゴリズムの後継でした。 [マイニングアルゴリズムの詳細](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/) ## 関連トピック {#related-topics} - [ガス](/developers/docs/gas/) -- [EVM(イーサリアム仮想マシン)](/developers/docs/evm/) +- [EVM](/developers/docs/evm/) - [プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md index f90e05eb02c..9c475559d28 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -1,35 +1,35 @@ --- -title: ダガーハシモト -description: ダガーハシモト・アルゴリズムの詳細 +title: "ダガーハシモト" +description: "ダガーハシモト・アルゴリズムの詳細" lang: ja --- -ダガーハシモト(Dagger-Hashimoto)は、イーサリアムのマイニングアルゴリズムの最初の研究実装と仕様でした。 その後、ダガーハシモトから[Ethash](#ethash)に置き換えられました。 マイニングは、2022年9月15日の[マージ](/roadmap/merge/)で完全に廃止されました。 それ以降、イーサリアムには [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)のメカニズムが使われています。 このページについては過去の流れを理解する目的でご覧ください。この情報は、マージ後のイーサリアムには該当しません。 +ダガーハシモト(Dagger-Hashimoto)は、イーサリアムのマイニングアルゴリズムの最初の研究実装と仕様でした。 Dagger-Hashimotoは、[Ethash](#ethash)に取って代わられました。 2022年9月15日の[The Merge](/roadmap/merge/)で、マイニングは完全に停止されました。 それ以来、イーサリアムは代わりに[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)のメカニズムを使用して安全性が確保されています。 このページについては過去の流れを理解する目的でご覧ください。この情報は、マージ後のイーサリアムには該当しません。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをより理解するために、まず[プルーフ・オブ・ワーク・コンセンサス](/developers/docs/consensus-mechanisms/pow)、[マイニング](/developers/docs/consensus-mechanisms/pow/mining)、[マイニングアルゴリズム](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms)を読むことをお勧めします。 +このページをより深く理解するには、まず[プルーフ・オブ・ワークのコンセンサス](/developers/docs/consensus-mechanisms/pow)、[マイニング](/developers/docs/consensus-mechanisms/pow/mining)、[マイニングアルゴリズム](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms)について読むことをお勧めします。 -## ダガーハシモト {#dagger-hashimoto} +## Dagger-Hashimoto {#dagger-hashimoto} ダガーハシモトは、次の2つの目的を達成することを目指しています。 -1. **ASIC耐性**: アルゴリズム専用ハードウェアの製作によって得られる利益を、最小限にすること。 -2. **ライトクライアントの検証可能性**: ライトクライアントがブロックを効率的に検証可能であること。 +1. **ASIC耐性**: アルゴリズム専用のハードウェアを作成することで得られるメリットを、可能な限り小さくすること。 +2. **ライトクライアントの検証可能性**: ライトクライアントがブロックを効率的に検証できること。 追加の修正により、ご希望に応じて、3つ目の目標を達成する方法も記載しますが、複雑になります。 -**フルチェーンストレージ**: マイニングでは、完全なブロックチェーンの状態の保管を必要にすること(イーサリアムのステートツリーの不規則な構造により、特によく使われるいくつかのコントラクトは、ある程度のプルーニングが可能だと予想されます。しかし、これを最小限に抑えたいと考えています)。 +**フルチェーンストレージ**: マイニングには、完全なブロックチェーンの状態のストレージが必要であること（イーサリアムのステートツリーの不規則な構造のため、特に頻繁に使用される一部のコントラクトでは、ある程度のプルーニングが可能だと予想されますが、これを最小限に抑えたいと考えています）。 -## 有向非巡回グラフ(DAG)の生成 {#dag-generation} +## DAGの生成 {#dag-generation} -Pythonを使って、このアルゴリズムのコードを以下に定義します。 最初に、指定された精度の符号なし整数型を、マーシャリングして文字列にするため `encode_int`を用意します。 変換された値を戻す関数もまた用意します。 +Pythonを使って、このアルゴリズムのコードを以下に定義します。 まず、指定された精度の符号なし整数を文字列にマーシャリングするための `encode_int` を示します。 変換された値を戻す関数もまた用意します。 ```python NUM_BITS = 512 def encode_int(x): - "Encode an integer x as a string of 64 characters using a big-endian scheme" + "ビッグエンディアン方式を使用して、整数xを64文字の文字列としてエンコードする" o = '' for _ in range(NUM_BITS / 8): o = chr(x % 256) + o @@ -37,7 +37,7 @@ def encode_int(x): return o def decode_int(s): - "Unencode an integer x from a string using a big-endian scheme" + "ビッグエンディアン方式を使用して、文字列から整数xをデコードする" x = 0 for c in s: x *= 256 @@ -45,7 +45,7 @@ def decode_int(s): return x ``` -次に`sha3`は、整数を引数に取り、整数を出力する関数とします。`dbl_sha3`は、倍精度浮動小数点数型のsha3関数とします。このレファレンスのコードを、実装する場合は次のように使います。 +次に、`sha3`が整数を受け取って整数を出力する関数であり、`dbl_sha3`が2重のsha3関数であると仮定します。このリファレンスコードを実装に変換する場合は、以下を使用してください。 ```python from pyethereum import utils @@ -65,26 +65,25 @@ def dbl_sha3(x): アルゴリズムに使用されるパラメータは次のとおりです。 ```python -SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512 +SAFE_PRIME_512 = 2**512 - 38117 # 2**512未満の最大の安全素数 params = { - "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536 - "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536 - # with epochtime=20000 gives 882 MB growth per year - "cache_size": 2500, # Size of the light client's cache (can be chosen by light - # client; not part of the algo spec) - "diff": 2**14, # Difficulty (adjusted during block evaluation) - "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated) - "k": 1, # Number of parents of a node - "w": w, # Used for modular exponentiation hashing - "accesses": 200, # Number of dataset accesses during hashimoto - "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation + "n": 4000055296 * 8 // NUM_BITS, # データセットのサイズ（4ギガバイト）、65536の倍数である必要があります + "n_inc": 65536, # 期間ごとのnの値の増分、65536の倍数である必要があります + # epochtime=20000の場合、年間882MB増加 + "cache_size": 2500, # ライトクライアントのキャッシュのサイズ（ライトクライアントが選択可能、アルゴリズムの仕様には含まれない） + "diff": 2**14, # 難易度（ブロック評価中に調整） + "epochtime": 100000, # ブロック単位でのエポックの長さ（データセットの更新頻度） + "k": 1, # ノードの親の数 + "w": w, # 冪剰余ハッシュに使用 + "accesses": 200, # hashimoto中のデータセットアクセス数 + "P": SAFE_PRIME_512 # ハッシュおよび乱数生成用の安全素数 } ``` -この場合、`P`は、`log₂(P)`によって512よりわずかに小さくなるように選ばれた素数です。これは、数値を表すために使用している512ビットに対応します。 実際に格納される必要があるのは、DAGの後半部分です。事実上のRAM要件は、1GBから始まり毎年441MBずつ増加します。 +この場合、`P` は `log₂(P)` が512よりわずかに小さくなるように選ばれた素数であり、これは数値を表現するために使用している512ビットに対応します。 実際に格納される必要があるのは、DAGの後半部分です。事実上のRAM要件は、1GBから始まり毎年441MBずつ増加します。 -### ダガーグラフの構築 {#dagger-graph-building} +### Daggerグラフの構築 {#dagger-graph-building} 原始的なダガーグラフの構築は、以下のように定義できます。 @@ -101,7 +100,7 @@ def produce_dag(params, seed, length): return o ``` -基本的には、単一ノードである`sha3(seed)`として、グラフをスタートします。そこから、ランダムな前のノードに基づいて、他のノードを順次追加し始めます。 新しいノードが作成されると、シードの冪剰余が計算され、`i`より小さいいくつかのインデックスがランダムに選択されます (上記の`x % i`を使用) 。それらのインデックスのノードの値は、計算で使用され、`x`の新しい値を生成します。この値は、 (排他的論理和に基づいた) 小さなプルール・オブ・ワーク関数に送られ、最終的にはインデックス`i`のブラフの値を生成します。 この特有の設計の背後にある理論的根拠は、DAGのシーケンシャルアクセスを強制することです。アクセスされるDAGの次の値は、現在の値が判明するまで決定できません。 最後に、冪剰余で結果をさらにハッシュ化します。 +本質的に、グラフは単一のノード `sha3(seed)` として開始され、そこからランダムな以前のノードに基づいて他のノードを順次追加し始めます。 新しいノードが作成されると、シードの冪剰余が計算され、`i` より小さいインデックスがいくつかランダムに選択されます（上記の `x % i` を使用）。それらのインデックスにあるノードの値が計算に使用されて`x`の新しい値が生成され、その値が小規模なプルーフ・オブ・ワーク関数（XORベース）に送られて、最終的にインデックス `i` のグラフの値を生成します。 この特有の設計の背後にある理論的根拠は、DAGのシーケンシャルアクセスを強制することです。アクセスされるDAGの次の値は、現在の値が判明するまで決定できません。 最後に、冪剰余で結果をさらにハッシュ化します。 このアルゴリズムは、数論から得られたいくつかの結果に依存しています。 考察については、ページ下部にある付録を参照してください。 @@ -131,11 +130,11 @@ def quick_calc(params, seed, p): return quick_calc_cached(p) ``` -基本的に、上記のアルゴリズムを単純に書き直し、DAG全体の値を計算するループが除かれ、以前のノード検索から、再帰呼び出しまたはキャッシュ検索に置き換えられています。 `k=1`の場合、キャッシュは不要となることに注意してください。しかし、さらなる最適化において、DAGの最初の数千の値が事前に計算され、計算用の静的キャッシュとして保持されます。これのコード実装は、付録を参照してください。 +基本的に、上記のアルゴリズムを単純に書き直し、DAG全体の値を計算するループが除かれ、以前のノード検索から、再帰呼び出しまたはキャッシュ検索に置き換えられています。 `k=1` の場合、キャッシュは不要ですが、さらなる最適化では、実際にはDAGの最初の数千の値を事前計算し、それを計算用の静的キャッシュとして保持することに注意してください。これに関するコード実装については、付録を参照してください。 -## 有向非巡回グラフ(DAG)のダブルバッファ {#double-buffer} +## DAGのダブルバッファ {#double-buffer} -フルクライアントでは、上記の式で生成した2つのDAGの[_ダブルバッファ_](https://wikipedia.org/wiki/Multiple_buffering)が使われます。 このアイデアは、DAGが上記のパラメータに従い、ブロックの`epochtime`数ごとに生成されるというものです。 クライアントは、最新の生成されたDAGを使うのではなく、1つ前のDAGを使います。 この利点としては、マイナーが突然すべてのデータを再計算するステップを取り入れる必要がなく、DAGを時間の経過とともに置き換えられることです。 そうでなければ、チェーンを処理する一定間隔で突然一時的に遅くなり、集中化が劇的に増加する可能性があります。 これにより、すべてのデータが再計算される前の数分間以内に、51%攻撃のリスクが発生します。 +フルクライアントでは、上記の式で生成された2つのDAGの[_ダブルバッファ_](https://wikipedia.org/wiki/Multiple_buffering)が使用されます。 これは、上記のパラメータに従って、`epochtime`ブロック数ごとにDAGが生成されるという考え方です。 クライアントは、最新の生成されたDAGを使うのではなく、1つ前のDAGを使います。 この利点としては、マイナーが突然すべてのデータを再計算するステップを取り入れる必要がなく、DAGを時間の経過とともに置き換えられることです。 そうでなければ、チェーンを処理する一定間隔で突然一時的に遅くなり、集中化が劇的に増加する可能性があります。 これにより、すべてのデータが再計算される前の数分間以内に、51%攻撃のリスクが発生します。 ブロックのワークを計算するために使われるDAGセットを生成するために使用するアルゴリズムは、次のようになります。 @@ -164,7 +163,7 @@ def get_daggerset(params, block): dagsz = get_dagsize(params, block) seedset = get_seedset(params, block) if seedset["front_hash"] <= 0: - # No back buffer is possible, just make front buffer + # バックバッファは作成できないため、フロントバッファのみを作成します return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), "block_number": 0}} else: @@ -174,7 +173,7 @@ def get_daggerset(params, block): "block_number": seedset["back_number"]}} ``` -## ハシモト {#hashimoto} +## Hashimoto {#hashimoto} オリジナルのハシモトの背景にあるアイデアは、ブロックチェーンをデータセットとして使用することです。ブロックチェーンからN個のインデックスを選択して計算を実行し、これらのインデックスでトランザクションを収集し、このデータの排他的論理和(XOR)を実行して、結果のハッシュ値を返します。 Thaddeus Dryjaのオリジナルのアルゴリズムは、次のように一貫性のためにPythonでも書かれています。 @@ -254,54 +253,50 @@ def light_verify(params, header, nonce): - 2層検証が機能するためには、ブロックヘッダーに、ノンス (nonce)と、前にsha3だった中間値の両方が含まれている必要がある。 - ブロックヘッダーのどこかに、現在のシードセットのsha3が格納されている必要がある。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立つコミュニティリソースをご存知の場合は、 このページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 付録 {#appendix} -前述のように、DAGの生成で使われる乱数発生器(RNG)は、数論から得られた次の結果に依存しています。 最初に`picker`変数のもととなるレーマー乱数発生器の周期が広いことを断言しておきます。 次に、`pow(x,3,P)`は、 `x ∈ [2,P-2]`を開始条件として、`x`を`1`または`P-1`にマップしないことを示します。 最後に、 `pow(x,3,P)`を、ハッシュ関数として扱うと、衝突率が低くなることを示します。 +前述のように、DAGの生成で使われる乱数発生器(RNG)は、数論から得られた次の結果に依存しています。 まず、`picker` 変数の基礎となるレーマー乱数生成器が長い周期を持つことを保証します。 次に、`x ∈ [2,P-2]` で始まる場合、`pow(x,3,P)` が `x` を `1` または `P-1` にマッピングしないことを示します。 最後に、`pow(x,3,P)` がハッシュ関数として扱われた場合に、低い衝突率を持つことを示します。 -### レーマー 乱数発生器 {#lehmer-random-number} +### レーマー乱数生成器 {#lehmer-random-number} -`produce_dag`関数は、無作為の乱数を生成する必要がない一方で、潜在的な脅威として`seed**i % P`が一握りの値しか取れません。 このため、このパターンを認識しているマイナーは、そうでないマイナーに比べて有利になる可能性があります。 +`produce_dag` 関数は偏りのない乱数を生成する必要はありませんが、`seed**i % P` がごく少数の値しか取らないという潜在的な脅威があります。 このため、このパターンを認識しているマイナーは、そうでないマイナーに比べて有利になる可能性があります。 -これを避けるために、数論による結果を使う必要があります。 [_安全素数_](https://en.wikipedia.org/wiki/Safe_prime)とは、 `(P-1)/2`も素数であるような素数`P`と定義されています。 [乗法群](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n)のメンバー `x`の_次数_ `ℤ/nℤ`は、次の公式にある小さい字の`m`で定義されています。 
xᵐ mod P ≡ 1
-これらの定義から、次のようになります。 +これを避けるために、数論による結果を使う必要があります。 [_安全素数_](https://en.wikipedia.org/wiki/Safe_prime)は、`(P-1)/2` もまた素数であるような素数 `P` として定義されます。 [乗法群](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` のメンバー `x` の_位数_は、
xᵐ mod P ≡ 1
となる最小の `m` として定義されます。 +これらの定義を前提として、以下が成り立ちます。 -> 見解1. `x`を安全素数`P`の乗法群`ℤ/Pℤ`のメンバーとします。 `x mod P ≠ 1 mod P`かつ`x mod P ≠ P-1 mod P`の場合は、`x`の次数は、`P-1`または`(P-1)/2`となります。 +> 見解1. 安全素数 `P` について、`x` を乗法群 `ℤ/Pℤ` の元とします。 `x mod P ≠ 1 mod P` かつ `x mod P ≠ P-1 mod P` の場合、`x` の位数は `P-1` または `(P-1)/2` のいずれかです。 -_証明_. `P`は安全素数なので、\[ラグランジュの定理\]\[lagrange\]により、`x`の次数は`1`、`2`、`(P-1)/2`、または`P-1`のいずれかになります。 +_証明_。 `P` は安全素数であるため、[ラグランジュの定理][lagrange]により、`x` の位数は `1`、`2`、`(P-1)/2`、または `P-1` のいずれかになります。 -`x`の次数は`1`になることはできません。フェルマーの小定理により、次を満たすためです。 +フェルマーの小定理により次式が成り立つため、`x` の位数が `1` になることはありません。 
xP-1 mod P ≡ 1
-したがって、`x`は`ℤ/nℤ`の乗法的単位元でなければならず、一意です。 前提で`x≠1`としたので、これはありえません。 +したがって、`x` は `ℤ/nℤ` の乗法単位元でなければなりませんが、これは一意です。 前提として `x ≠ 1` と仮定しているため、これはありえません。 -`x = P-1`でない限り、`x`の次数を`2`にすることはできません。これは、`P`が素数であることに違反するためです。 +`x = P-1` でない限り、`x` の位数が `2` になることはありません。なぜなら、これは `P` が素数であることに反するためです。 -上記の命題から、`(picker * init) % P`の繰り返しは、少なくとも`(P-1)/2`の周期になることがわかります。 これは、`P`を2以上の累乗にほぼ等しい安全素数として選択し、`init`が`[2,2**256+1]`の間隔にあるためです。 `P`の大きさを考えると、冪剰余から周期を予想することはできません。 +上記の命題から、`(picker * init) % P` を繰り返すと、少なくとも `(P-1)/2` の周期長を持つことがわかります。 これは、`P` を2の大きなべき乗にほぼ等しい安全素数として選択し、`init` が区間 `[2,2**256+1]` にあるためです。 `P` の大きさを考えると、冪剰余からサイクルが生じることは予期すべきではありません。 -DAGの最初のセルを割り当てるとき (`init`というラベルの付いた変数) 、`pow(sha3(seed) + 2, 3, P)`を計算します。 一見すると、これは結果が`1`でも`P-1`でもないことを保証しません。 しかし、`P-1`は、安全素数であるため、見解1の帰結となる次の追加の保証があります。 +DAGの最初のセル（`init`というラベルの変数）を割り当てる際、`pow(sha3(seed) + 2, 3, P)` を計算します。 一見したところ、これは結果が `1` でも `P-1` でもないことを保証するものではありません。 しかし、`P-1` は安全素数であるため、観察1の系である以下の追加の保証があります。 -> 見解2. `x`を安全素数`P`の乗法群`ℤ/Pℤ`のメンバーとし、`w`を自然数とします。 `x mod P ≠ 1 mod P`かつ`x mod P ≠ P-1 mod P`および`w mod P ≠ P-1 mod P`かつ`w mod P ≠ 0 mod P`の場合、`xʷ mod P ≠ 1 mod P`かつ`xʷ mod P ≠ P-1 mod P` +> 見解2. 安全素数 `P` について、`x` を乗法群 `ℤ/Pℤ` の元とし、`w` を自然数とします。 `x mod P ≠ 1 mod P` かつ `x mod P ≠ P-1 mod P`、そして `w mod P ≠ P-1 mod P` かつ `w mod P ≠ 0 mod P` の場合、`xʷ mod P ≠ 1 mod P` かつ `xʷ mod P ≠ P-1 mod P` となります。 -### ハッシュ関数としての冪乗余 {#modular-exponentiation} +### ハッシュ関数としての冪剰余 {#modular-exponentiation} -`P`と`w`の特定の値に対して、関数`pow(x,w,P)`は、多くの衝突を起こす可能性があります。 たとえば、`pow(x,9,19) `は値`{1,18}`のみを取ります。 +`P` と `w` の特定の値に対して、関数 `pow(x, w, P)` は多くの衝突を起こす可能性があります。 例えば、`pow(x,9,19)` は値 `{1,18}` のみを取ります。 -`P`が素数であるとすると、累積余剰ハッシュ関数の適切な`w`は、次の結果を使用して選択できます。 +`P` が素数である場合、冪剰余ハッシュ関数に対する適切な `w` は、次の結果を用いて選択できます。 -> 見解3. `P`を素数とし、`ℤ/Pℤ`のすべての`a`かつ`b`において、そのときに限り`w`かつ`P-1`が互いに素であることが成り立ち、これは次のようになります。 -> ->
-> `a mod P ≡ b mod P` のとき、そのときに限り `aʷ mod P ≡ bʷ mod P` ->
+> 見解3. `P` を素数とします。`w` と `P-1` が互いに素であることは、`ℤ/Pℤ` 内のすべての `a` と `b` について、次の条件が成り立つことと同値です。
`aʷ mod P ≡ bʷ mod P` であることと `a mod P ≡ b mod P` であることは同値である
-したがって、`P`が素数でかつ`w`が`P-1`に対して互いに素であるとすると、`|{pow(x, w, P) : x ∈ ℤ}| = P `が得られます。考えられるハッシュ関数の衝突率が最小であることを意味します。 +したがって、`P` が素数であり、`w` が `P-1` と互いに素である場合、`|{pow(x, w, P) : x ∈ ℤ}| = P` となり、これはハッシュ関数が実現可能な最小の衝突率を持つことを意味します。 -選択したように`P`が安全素数であるという特殊なケースでは、`P-1`が1、2、`(P-1)/2`、および`P-1`の因数のみを持ちます。 `P`>7であるため、3は、`P-1`に対して互いに素であることがわかります。したがって、`w=3`は、上記の命題を満たします。 +私たちが選択したように `P` が安全素数である特殊なケースでは、`P-1` は `1`、`2`、`(P-1)/2`、`P-1` のみを因数として持ちます。 `P` > 7 なので、3は `P-1` と互いに素であることがわかり、したがって `w=3` は上記の命題を満たします。 ## より効率的なキャッシュベースの評価アルゴリズム {#cache-based-evaluation} diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md index 6a122f48b8e..9a41bb85bc2 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -1,6 +1,6 @@ --- title: Ethash -description: Ethashアルゴリズムの詳細 +description: "Ethashアルゴリズムの詳細" lang: ja --- @@ -8,12 +8,12 @@ lang: ja - Ethashは、イーサリアムのプルーフ・オブ・ワークのマイニングアルゴリズムでした。 プルーフ・オブ・ワークは、今『完全に廃止』されており、イーサリアムは現在[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)により安全が確保されています。 詳細については、[マージ](/roadmap/merge/)、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)および[ステーキング](/staking/)を参照してください。 このページについては、これまでのイーサリアムの歩みを学ぶための参考としてお読みください。 + Ethashは、イーサリアムのプルーフ・オブ・ワークのマイニングアルゴリズムでした。 プルーフ・オブ・ワークは、現在『完全に停止』となっています。イーサリアムは今、代わりに[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)によって安全が確保されています。 [マージ](/roadmap/merge/)、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/) 、[ステーキング](/staking/)について詳しく読む。 このページについては、これまでのイーサリアムの歩みを学ぶための参考としてお読みください。 -Ethashは、[ダガーハシモト](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto)アルゴリズムを部分的に修正したバージョンです。 Ethashプルーフ・オブ・ワークは、[メモリハード](https://wikipedia.org/wiki/Memory-hard_function)になっており、アルゴリズムでASIC耐性が高まると考えられました。 最終的には、Ethash ASICが開発されましたが、GPUマイニングは、プルーフ・オブ・ワークが停止されるまでが実行可能なオプションでした。 Ethashは現在でも、イーサリアム以外のプルール・オブ・ワーク・ネットワークで他のコインのマイニングに使われています。 +Ethashは[Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto)アルゴリズムの修正版です。 Ethashのプルーフ・オブ・ワークは[メモリハード](https://wikipedia.org/wiki/Memory-hard_function)であり、このアルゴリズムはASIC耐性があると考えられていました。 最終的には、Ethash ASICが開発されましたが、GPUマイニングは、プルーフ・オブ・ワークが停止されるまでが実行可能なオプションでした。 Ethashは現在でも、イーサリアム以外のプルール・オブ・ワーク・ネットワークで他のコインのマイニングに使われています。 ## Ethashの仕組み {#how-does-ethash-work} @@ -21,9 +21,9 @@ Ethashは、[ダガーハシモト](/developers/docs/consensus-mechanisms/pow/mi アルゴリズムが取る一般的なルートは以下のとおりです。 -1. **シード**が存在し、その時点までブロックヘッダーをスキャンすることで、ブロックごとに計算できる。 -2. シードから**16MBの疑似乱数キャッシュ**を計算できる。 ライトクライアントは、キャッシュを保存する。 -3. キャッシュから各アイテムがキャッシュの少数のアイテムのみに依存するプロパティを持つ**1GB データセット**を生成できる。 フルクライアントとマイナーは、データセットを保存する。 データセットは時間とともに線形的に増加する。 +1. 各ブロックについて、その時点までのブロックヘッダーをスキャンすることで計算できる**シード**が存在します。 +2. シードから、**16MBの疑似ランダムキャッシュ**を計算できます。 ライトクライアントは、キャッシュを保存する。 +3. キャッシュから、データセット内の各アイテムがキャッシュ内の少数のアイテムのみに依存するという特性を持つ、**1GBのデータセット**を生成できます。 フルクライアントとマイナーは、データセットを保存する。 データセットは時間とともに線形的に増加する。 4. マイニングは、データセットのランダムなスライスを取得し、それらを結合してハッシュ化する。 検証はキャッシュを使用して必要なデータセットの特定の部分を再生成するため、少ないメモリで実行できる(そのためキャッシュの保存だけ必要)。 大きなデータセットでは、30000ブロックごとに一度更新されます。マイナーの労力の大部分は、データセットを読み込むことであり、データセットに変更を加えることではありません。 @@ -33,23 +33,23 @@ Ethashは、[ダガーハシモト](/developers/docs/consensus-mechanisms/pow/mi 以下の定義を採用しています。 ``` -WORD_BYTES = 4 # bytes in word -DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis -DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch -CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis -CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch -CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache -EPOCH_LENGTH = 30000 # blocks per epoch -MIX_BYTES = 128 # width of mix -HASH_BYTES = 64 # hash length in bytes -DATASET_PARENTS = 256 # number of parents of each dataset element -CACHE_ROUNDS = 3 # number of rounds in cache production -ACCESSES = 64 # number of accesses in hashimoto loop +WORD_BYTES = 4 # ワード内のバイト数 +DATASET_BYTES_INIT = 2**30 # ジェネシス時のデータセットのバイト数 +DATASET_BYTES_GROWTH = 2**23 # エポックごとのデータセットの増加量 +CACHE_BYTES_INIT = 2**24 # ジェネシス時のキャッシュのバイト数 +CACHE_BYTES_GROWTH = 2**17 # エポックごとのキャッシュの増加量 +CACHE_MULTIPLIER=1024 # キャッシュに対するDAGのサイズ +EPOCH_LENGTH = 30000 # エポックごとのブロック数 +MIX_BYTES = 128 # mixの幅 +HASH_BYTES = 64 # ハッシュの長さ (バイト単位) +DATASET_PARENTS = 256 # 各データセット要素の親の数 +CACHE_ROUNDS = 3 # キャッシュ生成におけるラウンド数 +ACCESSES = 64 # hashimotoループ内のアクセス数 ``` ### 「SHA3」の使用 {#sha3} -イーサリアムの開発は、SHA3標準の開発と同時期に起こりました。標準プロセスは、最終決定したハッシュアルゴリズムのパディングが遅れて変更されたため、イーサリアムの「sha3_256」および「sha3_512」ハッシュは、標準のsha3ハッシュではありません。他の文脈の多くでは、変異型として「Keccak-256」および「Keccak-512」と呼ばれています。 [こちら](https://eips.ethereum.org/EIPS/eip-1803)、[こちら](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)、 または[こちら](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)の議論をご覧ください。 +イーサリアムの開発は、SHA3標準の開発と同時期に起こりました。標準プロセスは、最終決定したハッシュアルゴリズムのパディングが遅れて変更されたため、イーサリアムの「sha3_256」および「sha3_512」ハッシュは、標準のsha3ハッシュではありません。他の文脈の多くでは、変異型として「Keccak-256」および「Keccak-512」と呼ばれています。 議論については、例えば[こちら](https://eips.ethereum.org/EIPS/eip-1803)、[こちら](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)、または[こちら](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)を参照してください。 以下のアルゴリズムの説明では、「sha3」ハッシュが参照されることを覚えておいてください。 @@ -83,12 +83,12 @@ def get_full_size(block_number): def mkcache(cache_size, seed): n = cache_size // HASH_BYTES - # Sequentially produce the initial dataset + # 初期データセットを順番に生成 o = [sha3_512(seed)] for i in range(1, n): o.append(sha3_512(o[-1])) - # Use a low-round version of randmemohash + # randmemohashの低ラウンド版を使用 for _ in range(CACHE_ROUNDS): for i in range(n): v = o[i][0] % n @@ -97,11 +97,11 @@ def mkcache(cache_size, seed): return o ``` -キャッシュ生成プロセスは、最初に32MBのメモリを順番に埋め、次に、[_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf)に掲載されているSergio Demian Lerner氏の_RandMemoHash_アルゴリズムを2パス実行します。 出力は、524288個の64バイトの値のセットです。 +キャッシュ生成プロセスでは、まず32MBのメモリを順番に埋め、次にSergio Demian Lernerの[_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf)にある_RandMemoHash_アルゴリズムの2パスを実行します。 出力は、524288個の64バイトの値のセットです。 ## データ集約関数 {#date-aggregation-function} -いくつかのケースにおいて、排他的論理和の非結合的代替として[FNV hash](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function)から発想を得たアルゴリズムを使用します。 素数を1バイト(オクテット)ずつ順番に乗算するFNV-1の仕様ではなく、素数を全32ビットの入力で乗算することに注意してください。 +[FNVハッシュ](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function)に触発されたアルゴリズムを、XORの非結合的な代替として使用する場合があります。 素数を1バイト(オクテット)ずつ順番に乗算するFNV-1の仕様ではなく、素数を全32ビットの入力で乗算することに注意してください。 ```python FNV_PRIME = 0x01000193 @@ -110,7 +110,7 @@ def fnv(v1, v2): return ((v1 * FNV_PRIME) ^ v2) % 2**32 ``` -イエローペーパーでは、FNVをv1*(FNV_PRIME ^ v2)と指定していますが、現在の実装ではすべて上記の定義で統一しています。 +イエローペーパーでは、FNVをv1\*(FNV_PRIME ^ v2)と指定していますが、現在の実装ではすべて上記の定義で統一しています。 ## フルデータセットの計算 {#full-dataset-calculation} @@ -120,11 +120,11 @@ def fnv(v1, v2): def calc_dataset_item(cache, i): n = len(cache) r = HASH_BYTES // WORD_BYTES - # initialize the mix + # mixを初期化 mix = copy.copy(cache[i % n]) mix[0] ^= i mix = sha3_512(mix) - # fnv it with a lot of random cache nodes based on i + # iに基づいて多数のランダムなキャッシュノードでfnvを適用 for j in range(DATASET_PARENTS): cache_index = fnv(i ^ j, mix[j % r]) mix = map(fnv, mix, cache[cache_index % n]) @@ -140,27 +140,27 @@ def calc_dataset(full_size, cache): ## メインループ {#main-loop} -ここでは、メインのハシモトに似たループを記述します。特定のヘッダーとノンス (nonce)の最終的な値を生成するために、フルデータセットからデータを集約します。 以下のコードでは、`header`は_切り捨てられた_ブロックヘッダー(すなわち、フィールド**mixHash**と**nonce**を除外したヘッダー)のRLP表現のSHA3-256_ハッシュ_を表します。 `nonce`は、ビッグエンディアンオーダーの64ビット符号なし整数8バイトです。 したがって、`nonce[::-1]`は、その値の8バイトのリトルエンディアン表現です。 +ここでは、メインのハシモトに似たループを記述します。特定のヘッダーとノンス (nonce)の最終的な値を生成するために、フルデータセットからデータを集約します。 以下のコードでは、`header`は、_切り捨てられた_ブロックヘッダー、つまり**mixHash**と**nonce**フィールドを除いたヘッダーのRLP表現のSHA3-256_ハッシュ_を表します。 `nonce`は、ビッグエンディアンオーダーの64ビット符号なし整数の8バイトです。 したがって、`nonce[::-1]`は、その値の8バイトのリトルエンディアン表現です： ```python def hashimoto(header, nonce, full_size, dataset_lookup): n = full_size / HASH_BYTES w = MIX_BYTES // WORD_BYTES mixhashes = MIX_BYTES / HASH_BYTES - # combine header+nonce into a 64 byte seed + # headerとnonceを結合して64バイトのシードにする s = sha3_512(header + nonce[::-1]) - # start the mix with replicated s + # 複製されたsでmixを開始 mix = [] for _ in range(MIX_BYTES / HASH_BYTES): mix.extend(s) - # mix in random dataset nodes + # ランダムなデータセットノードをmix for i in range(ACCESSES): p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes newdata = [] for j in range(MIX_BYTES / HASH_BYTES): newdata.extend(dataset_lookup(p + j)) mix = map(fnv, mix, newdata) - # compress mix + # mixを圧縮 cmix = [] for i in range(0, len(mix), 4): cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) @@ -176,9 +176,9 @@ def hashimoto_full(full_size, dataset, header, nonce): return hashimoto(header, nonce, full_size, lambda x: dataset[x]) ``` -基本的に、128バイト幅の「mix」を維持し、フルデータセットから128バイトを繰り返し順番にフェッチし、`fnv`関数を使って、それをmixと結合します。 128バイトのシーケンシャルアクセス が使用されており、アルゴリズムの各ラウンドは、常にRAMから完全なページをフェッチし、理論的にASICが回避できるトランスレーション・ルックアサイド・バッファのミスを最小限にします。 +基本的に、幅128バイトの\"mix\"を維持し、フルデータセットから128バイトを繰り返しシーケンシャルにフェッチし、`fnv`関数を使用してそれをmixと結合します。 128バイトのシーケンシャルアクセス が使用されており、アルゴリズムの各ラウンドは、常にRAMから完全なページをフェッチし、理論的にASICが回避できるトランスレーション・ルックアサイド・バッファのミスを最小限にします。 -アルゴリズムの出力が目標値を下回っている場合は、ノンス (nonce)は有効です。 `sha3_256`を最後に追加適用することで、ノンス (nonce)が必ず存在することになります。これは、少なくとも少量のワークが行われたことを証明するために提供でき、このクイックアウタ・ープルーフ・オブ・ワーク(PoW)検証は、DDoS対策に利用できます。 また、その結果が不偏の256ビットの数であることを統計的に保証する役割もあります。 +アルゴリズムの出力が目標値を下回っている場合は、ノンス (nonce)は有効です。 最後に`sha3_256`を追加適用することで、少なくとも少量の作業が行われたことを証明するために提供できる中間ノンスが存在することが保証されることに注意してください。この迅速な外部PoW検証は、DDoS対策に利用できます。 また、その結果が不偏の256ビットの数であることを統計的に保証する役割もあります。 ## マイニング {#mining} @@ -186,7 +186,7 @@ def hashimoto_full(full_size, dataset, header, nonce): ```python def mine(full_size, dataset, header, difficulty): - # zero-pad target to compare with hash on the same digit + # 同じ桁でハッシュと比較するためにターゲットをゼロパディングする target = zpad(encode_int(2**256 // difficulty), 64)[::-1] from random import randint nonce = randint(0, 2**64) @@ -209,9 +209,9 @@ def mine(full_size, dataset, header, difficulty): スムーズなマイニングと検証のために、別々のスレッドで将来のシードハッシュとデータセットを事前計算することを推奨します。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立つコミュニティリソースをご存知の場合は、 このページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 付録 {#appendix} @@ -220,7 +220,7 @@ _役に立つコミュニティリソースをご存知の場合は、 このペ ```python import sha3, copy -# Assumes little endian bit ordering (same as Intel architectures) +# リトルエンディアンのビット順を想定 (Intelアーキテクチャと同じ) def decode_int(s): return int(s[::-1].encode('hex'), 16) if s else 0 @@ -248,7 +248,7 @@ def serialize_cache(ds): serialize_dataset = serialize_cache -# sha3 hash function, outputs 64 bytes +# sha3ハッシュ関数、64バイトを出力 def sha3_512(x): return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md index 166f93debdb..92e066328d9 100644 --- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md +++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -1,6 +1,6 @@ --- -title: マイニングアルゴリズム -description: イーサリアムのマイニングで使われたアルゴリズムの詳細 +title: "マイニング・アルゴリズム" +description: "イーサリアムのマイニングで使われたアルゴリズムの詳細" lang: ja --- @@ -15,28 +15,28 @@ lang: ja イーサリアムのマイニングでは、Ethashと呼ばれるアルゴリズムを使っていました。 このアルゴリズムの基本的なアイデアは、マイナーがしらみつぶしに計算を行い、ノンス (nonce)の入力を探し、その結果のハッシュ値が、計算された難易度によって決められたしきい値より小さくなるように試みるというものです。 この難易度は動的に調整することが可能で、一定間隔でブロック生成を行うことができます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをより理解するために、事前に[プルーフ・オブ・ワーク・コンセンサス](/developers/docs/consensus-mechanisms/pow)と[マイニング](/developers/docs/consensus-mechanisms/pow/mining)をお読みになることをお勧めします。 +このページをより深く理解するために、まずは[プルーフ・オブ・ワーク・コンセンサス](/developers/docs/consensus-mechanisms/pow)と[マイニング](/developers/docs/consensus-mechanisms/pow/mining)についてお読みになることをお勧めします。 -## ダガーハシモト {#dagger-hashimoto} +## ダガー・ハシモト {#dagger-hashimoto} ダガーハシモト(Dagger-Hashimoto)は、イーサリアムのマイニングアルゴリズムの前身となる研究アルゴリズムで、後にEthashに取って代わられました。 ダガーハシモトは、ダガー(Dagger)とハシモト(Hashimoto)という、2つの異なるアルゴリズムを組み合わせたものです。 研究実装のみを目的としており、イーサリアムメインネットが開始されるまでには、Ethashに引き継がれています。 -[ダガー](http://www.hashcash.org/papers/dagger.html)は、[有向非巡回グラフ(Directed Acyclic Graph)](https://en.wikipedia.org/wiki/Directed_acyclic_graph)の生成を伴い、それのランダムなスライスを合わせてハッシュ化します。 コアとなる原則として、各ノンス (nonce)が必要とするのは巨大な全データツリーのごく一部のみであるということです。 各ノンス (nonce)のサブツリーを再計算することは、マイニングでは禁止されているため、ツリーを保存する必要があります(ただし、単一ノンス相当の検証では、サブツリーの再計算は可能)。 ダガーは、Scryptのような既存のアルゴリズムの代替となるように設計されています。Scryptはメモリハードですが、実際に安全なレベルのメモリハードまで増加すると検証が難しくなります。 一方、ダガーは共有メモリ・ハードウェア・アクセラレーションに対して脆弱であり、他の研究手段を優先し、取り下げられました。 +[Dagger](http://www.hashcash.org/papers/dagger.html)では、[有向非巡回グラフ](https://en.wikipedia.org/wiki/Directed_acyclic_graph)が生成され、そのランダムなスライスが一緒にハッシュ化されます。 コアとなる原則として、各ノンス (nonce)が必要とするのは巨大な全データツリーのごく一部のみであるということです。 各ノンス (nonce)のサブツリーを再計算することは、マイニングでは禁止されているため、ツリーを保存する必要があります(ただし、単一ノンス相当の検証では、サブツリーの再計算は可能)。 ダガーは、Scryptのような既存のアルゴリズムの代替となるように設計されています。Scryptはメモリハードですが、実際に安全なレベルのメモリハードまで増加すると検証が難しくなります。 一方、ダガーは共有メモリ・ハードウェア・アクセラレーションに対して脆弱であり、他の研究手段を優先し、取り下げられました。 -[ハシモト](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf)は、入出力バウンドであること(メモリの読込みがマイニングプロセスの制限要因)により、ASIC耐性を付加するアルゴリズムです。 この理論は、RAMは計算資源よりも利用可能であるということです。数十億ドル相当かけて、異なるユースケースでのRAMの最適化について研究がすでになされています。これらのユースケースの多くには、ほぼランダムなアクセスパターン(そのためRAM「ランダム・アクセス・メモリ」と呼ばれる)が含まれています。 その結果、既存のRAMはアルゴリズムを評価する上で、ほぼ最適に近い可能性があります。 ハシモトは、データのソースとしてブロックチェーンを使い、上記の(1)と(3)を同時に満たします。 +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf)は、I/Oバウンド(すなわち、マイニングプロセスにおいてメモリの読み込みが制限要因となること)であることによってASIC耐性を付加するアルゴリズムです。 この理論は、RAMは計算資源よりも利用可能であるということです。数十億ドル相当かけて、異なるユースケースでのRAMの最適化について研究がすでになされています。これらのユースケースの多くには、ほぼランダムなアクセスパターン(そのためRAM「ランダム・アクセス・メモリ」と呼ばれる)が含まれています。 その結果、既存のRAMはアルゴリズムを評価する上で、ほぼ最適に近い可能性があります。 ハシモトは、データのソースとしてブロックチェーンを使い、上記の(1)と(3)を同時に満たします。 -ダガーハシモトは、ダガーとハシモトアルゴリズムを修正したものです。 ダガーハシモトとハシモトの違いとしては、ブロックチェーンデータをソースとして使わず、ダガーハシモトは、カスタム生成のデータセットを使い、Nブロックごとにブロックデータを基にして更新します。 このデータセットは、ダガーアルゴリズムを使って生成され、ライトクライアント検証アルゴリズムのための、各ノンス (nonce)に特有なサブセットで効率的な計算を可能にします。 ダガーハシモトとダガーの違いとしては、オリジナルのダガーとは異なり、ブロックのクエリーとして使われるデータセットは、半永続的で、周期的な間隔で更新(例: 1週間に一回)されるだけということです。 データセットを生成する労力の割合はゼロに近く、共有メモリの高速化に関するSergio Lernerの主張は、無視できるようになります。 +ダガーハシモトは、ダガーとハシモトアルゴリズムを修正したものです。 ダガーハシモトとハシモトの違いとしては、ブロックチェーンデータをソースとして使わず、ダガーハシモトは、カスタム生成のデータセットを使い、Nブロックごとにブロックデータを基にして更新します。 このデータセットは、ダガーアルゴリズムを使って生成され、ライトクライアント検証アルゴリズムのための、各ノンス (nonce)に特有なサブセットで効率的な計算を可能にします。 ダガー・ハシモトとダガーの違いは、オリジナルのダガーとは異なり、ブロックのクエリに使用されるデータセットが半永続的で、一定の間隔(例: 週に一度)でしか更新されない点です。 データセットを生成する労力の割合はゼロに近く、共有メモリの高速化に関するSergio Lernerの主張は、無視できるようになります。 -[ダガーハシモト](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto)の詳細 +[ダガー・ハシモト](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto)についての詳細。 ## Ethash {#ethash} -Ethashは、現在は廃止となっているプルーフ・オブ・ワークのアーキテクチャの下で、実際にイーサリアムメインネットで使われたマイニングアルゴリズムです。 Ethashは、ダガーハシモトのアルゴリズムが大幅に更新された後に、特定のダガーハシモトのバージョンに事実上付けられたた新しい名前です。なので、前バージョンの基本理念を継承しています。 イーサリアムメインネットで使われてきたのはEthashのみです。ダガーハシモトは、研究開発バージョンのマイニングアルゴリズムで、イーサリアムメインネットでマイニングが開始される前にEthashに引き継がれました。 +Ethashは、現在は廃止となっているプルーフ・オブ・ワークのアーキテクチャの下で、実際にイーサリアムメインネットで使われたマイニングアルゴリズムです。 Ethashは、ダガーハシモトのアルゴリズムが大幅に更新された後に、特定のダガーハシモトのバージョンに事実上付けられたた新しい名前です。なので、前バージョンの基本理念を継承しています。 イーサリアムメインネットではEthashのみが使用されました。ダガー・ハシモトはマイニングアルゴリズムの研究開発版であり、イーサリアムメインネットでマイニングが開始される前に取って代わられました。 -[Ethashの詳細](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash) +[Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash)についての詳細。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立つコミュニティリソースをご存知の場合は、 このページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/dapps/index.md b/public/content/translations/ja/developers/docs/dapps/index.md index a8772673f42..d1620383d47 100644 --- a/public/content/translations/ja/developers/docs/dapps/index.md +++ b/public/content/translations/ja/developers/docs/dapps/index.md @@ -1,96 +1,96 @@ --- -title: 分散型アプリケーション(Dapp)入門 +title: "DApps技術入門" description: lang: ja --- -分散型アプリケーション(Dapp)とは、 [スマートコントラクト](/developers/docs/smart-contracts/) とフロントエンドのユーザーインターフェイスを組み合わせた、分散型ネットワーク上に構築されたアプリケーションのことです。 イーサリアムでは、スマートコントラクトはオープンAPIのようにアクセス可能で透明性があるため、他の人が書いたスマートコントラクトを含めることもできます。 +分散型アプリケーション(dapp)とは、[スマートコントラクト](/developers/docs/smart-contracts/)とフロントエンドのユーザーインターフェイスを組み合わせ、分散型ネットワーク上に構築されたアプリケーションです。 イーサリアムでは、スマートコントラクトはオープンAPIのようにアクセス可能で透明性があるため、他の人が書いたスマートコントラクトを含めることもできます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -分散型アプリ(Dapp)について学ぶ前に、 [ブロックチェーンの基本](/developers/docs/intro-to-ethereum/)を網羅し、イーサリアムネットワークとネットワークの分散化についてお読みください。 +dappsについて学ぶ前に、[ブロックチェーンの基本](/developers/docs/intro-to-ethereum/)を学び、イーサリアムネットワークとその分散化の仕組みについて読む必要があります。 -## 分散型アプリケーション(Dapp)の定義 {#definition-of-a-dapp} +## dappの定義 {#definition-of-a-dapp} 分散型アプリ(Dapp)は、分散型ピアツーピアネットワーク上で稼働するバックエンドコードを内包しています。 これはバックエンドコードが中央集権的なサーバ上で実行されているアプリとは対照的です。 -分散型アプリ(Dapp)は、普通のアプリと同様に、任意の言語で書かれたフロントエンドコードとユーザーインターフェースを持ち、バックエンドを呼び出します。 さらに、そのフロントエンド部分を[IPFS](https://ipfs.io/)などの分散型ストレージにホストすることができます。 +分散型アプリ(Dapp)は、普通のアプリと同様に、任意の言語で書かれたフロントエンドコードとユーザーインターフェースを持ち、バックエンドを呼び出します。 さらに、フロントエンドは[IPFS](https://ipfs.io/)のような分散型ストレージでホストすることも可能です。 -- **分散型** - 分散型アプリ(Dapp)はイーサリアム上で動作する。イーサリアムはオープンでパブリックな分散型プラットフォームで、特定の個人やグループがコントロールすることはない。 -- **確定性** - 分散型アプリ(Dapp)は実行される環境に依存せず、同じ機能を実行する。 -- **チューリング完全** - 分散型アプリ(Dapp)は必要なリソースがあれば、あらゆるアクションを実行可能。 -- **隔離性** - 分散型アプリ(Dapp)は、イーサリアム仮想マシンと呼ばれる仮想環境で実行されるため、スマートコントラクトにバグがあっても、ブロックチェーンネットワーク自身の正常な機能を妨げることがない。 +- **分散型** - dappsは、特定の個人やグループが管理することのない、オープンでパブリックな分散型プラットフォームであるイーサリアム上で動作します +- **決定的** - dappsは、実行される環境に関係なく、同じ機能を実行します +- **チューリング完全** - dappsは、必要なリソースがあれば、あらゆるアクションを実行できます +- **分離性** - dappsはイーサリアム仮想マシンとして知られる仮想環境で実行されるため、スマートコントラクトにバグがあっても、ブロックチェーンネットワークの正常な機能を妨げることはありません -### スマートコントラクト {#on-smart-contracts} +### スマートコントラクトについて {#on-smart-contracts} -分散型アプリ(Dapp)の説明をするには、まずスマートコントラクトから始める必要があります。適当な言葉が見つからないため、スマートコントラクトは分散型アプリのバックエンドと考えてください。 詳細については、 [スマートコントラクト](/developers/docs/smart-contracts/)のセクションをご覧ください。 +分散型アプリ(Dapp)の説明をするには、まずスマートコントラクトから始める必要があります。適当な言葉が見つからないため、スマートコントラクトは分散型アプリのバックエンドと考えてください。 詳細な概要については、[スマートコントラクト](/developers/docs/smart-contracts/)に関するセクションを参照してください。 スマートコントラクトは、イーサリアムブロックチェーン上に存在し、プログラムされた通りに実行されるコードのことです。 一度ネットワークにデプロイされたスマートコントラクトを変更することはできません。 分散型アプリ(Dapp)は、個人や企業ではなく、コントラクトに書かれたロジックのみによって制御されるため、分散化することができます。 これはまた、スマートコントラクトを非常に慎重に設計し、徹底的にテストしなければならないことも意味しています。 -## 分散型アプリ(Dapp)のメリット {#benefits-of-dapp-development} +## dapp開発のメリット {#benefits-of-dapp-development} -- **ゼロダウンタイム** - スマートコントラクトがブロックチェーンにデプロイされると、ネットワーク全体が常にスマートコントラクトとのやり取りを求めるクライアントにサービスを提供できるようになる。 そのため、個々の分散型アプリを対象としたサービス拒否攻撃を行えない。 -- **プライバシー** - 分散型アプリ(Dapp)の展開や利用には、現実世界の身分証明書の提供は必要ない。 -- **検閲耐性** - ネットワーク上のどの存在もトランザクション、分散型アプリ(Dapp)のデプロイ、またはブロックチェーンからのデータの読み込みを阻止できない。 -- **完全なデータの整合性** - 暗号プリミティブにより、ブロックチェーン上に保存されたデータは、変更不可能で明白。 トランザクションやすでに公開されているその他のデータを偽造することはできない。 -- **トラストレスな計算/検証可能な動作** - スマートコントラクトは分析でき、中央集権的な機関を信頼する必要なく、予測可能な方法で実行される。 従来のモデルではトラストレスではなく、例えばオンラインバンキングシステムを使う場合などは、金融機関が個人の財務データを悪用したり、記録を改ざんしたり、ハッキングの被害に合わないと信頼しなくてはならない。 +- **ゼロダウンタイム** – スマートコントラクトがブロックチェーンにデプロイされると、ネットワーク全体で、コントラクトと対話しようとするクライアントに常にサービスを提供できるようになります。 そのため、個々の分散型アプリを対象としたサービス拒否攻撃を行えない。 +- **プライバシー** – dappをデプロイしたり、dappと対話したりするために、実社会の身元情報を提供する必要はありません。 +- **検閲耐性** – ネットワーク上の単一の主体が、ユーザーによるトランザクションの送信、dappsのデプロイ、ブロックチェーンからのデータの読み取りをブロックすることはできません。 +- **完全なデータ整合性** – 暗号プリミティブにより、ブロックチェーンに保存されたデータは不変であり、議論の余地がありません。 トランザクションやすでに公開されているその他のデータを偽造することはできない。 +- **トラストレスな計算/検証可能な動作** – スマートコントラクトは分析可能で、中央機関を信頼する必要なく、予測可能な方法で実行されることが保証されています。 従来のモデルではトラストレスではなく、例えばオンラインバンキングシステムを使う場合などは、金融機関が個人の財務データを悪用したり、記録を改ざんしたり、ハッキングの被害に合わないと信頼しなくてはならない。 -## 分散型アプリ(Dapp)のデメリット {#drawbacks-of-dapp-development} +## dapp開発の欠点 {#drawbacks-of-dapp-development} -- **メンテナンス** - ブロックチェーンに公開されたコードやデータが修正されにくいため、メンテナンスが困難となる場合がある。 古いバージョンでバグやセキュリティ上のリスクが特定されている場合でも、デベロッパーがデプロイされた分散型アプリ(または分散型アプリが保存する基盤となるデータ)を更新することは困難。 -- **性能オーバーヘッド** - 膨大な性能オーバーヘッドがあり、スケーリングが非常に困難。 イーサリアムが目指すセキュリティ、完全性、透明性、信頼性のレベルを達成するために、すべてのノードが全トランザクションを実行および保存する。 これに加えて、プルーフ・オブ・ステークのコンセンサスにも時間がかかる。 -- **ネットワーク輻輳** - 1つの分散型アプリ(Dapp)が多くの計算リソースを使用すると、ネットワーク全体が滞る。 現在、1秒間に約10～15件のトランザクションのみ処理可能だが、それ以上のスピードでトランザクションが送られてくると、未確認のトランザクション数がすぐに膨らむ。 -- **ユーザーエクスペリエンス** - 平均的なエンドユーザーにとっては、真に安全な方法でブロックチェーンと対話する必要なツールスタックをセットアップすることが困難であるため、ユーザーにとって使いやすいユーザーエクスペリエンスを作り込む事は困難な場合がある。 -- **中央集中化** - イーサリアムのベースレイヤーの上に構築されたユーザーとデベロッパーに使い勝手の良いソリューションは、最終的には集中型サービスのようになってしまう場合がある。 例えば、鍵やその他の機密情報をサーバ側に保存したり、集中管理されたサーバを使ってフロントエンドを提供したり、重要なビジネスロジックをブロックチェーンに書き込む前にサーバで実行することになるため、中央集権化されたアプリと類似してしまう場合がある。 中央集権では、従来のモデルに対するブロックチェーンのメリットの多くを失ってしまう。 +- **メンテナンス** – ブロックチェーンに公開されたコードやデータは修正が困難なため、dappsのメンテナンスは難しくなることがあります。 古いバージョンでバグやセキュリティ上のリスクが特定されている場合でも、デベロッパーがデプロイされた分散型アプリ(または分散型アプリが保存する基盤となるデータ)を更新することは困難。 +- **パフォーマンスのオーバーヘッド** – パフォーマンスに大きなオーバーヘッドがあり、スケーリングが非常に困難です。 イーサリアムが目指すセキュリティ、完全性、透明性、信頼性のレベルを達成するために、すべてのノードが全トランザクションを実行および保存する。 これに加えて、プルーフ・オブ・ステークのコンセンサスにも時間がかかる。 +- **ネットワークの混雑** – 1つのdappが計算リソースを使いすぎると、ネットワーク全体が滞ってしまいます。 現在、1秒間に約10～15件のトランザクションのみ処理可能だが、それ以上のスピードでトランザクションが送られてくると、未確認のトランザクション数がすぐに膨らむ。 +- **ユーザーエクスペリエンス** – 平均的なエンドユーザーにとって、真に安全な方法でブロックチェーンと対話するために必要なツールスタックを設定することは難しすぎる場合があるため、ユーザーフレンドリーなエクスペリエンスを設計するのはより困難になる可能性があります。 +- **中央集権化** – イーサリアムのベースレイヤー上に構築された、ユーザーフレンドリーで開発者フレンドリーなソリューションは、結局のところ中央集権的なサービスのように見えてしまう可能性があります。 例えば、鍵やその他の機密情報をサーバ側に保存したり、集中管理されたサーバを使ってフロントエンドを提供したり、重要なビジネスロジックをブロックチェーンに書き込む前にサーバで実行することになるため、中央集権化されたアプリと類似してしまう場合がある。 中央集権では、従来のモデルに対するブロックチェーンのメリットの多くを失ってしまう。 -## 映像で学びたい人向け {#visual-learner} +## 映像で学びたい場合 {#visual-learner} -## 分散型アプリ(Dapp)の作成ツール {#dapp-tools} +## dappsを作成するためのツール {#dapp-tools} -**Scaffold-ETH _ - 自分のスマートコントラクトに適応するフロントエンドを使用して、Solidityを手軽に試す。_** +**Scaffold-ETH _- スマートコントラクトに適応するフロントエンドを使用して、Solidityを素早く試せます。_** - [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -- [分散型アプリ(Dapp)の例](https://punkwallet.io/) +- [dappの例](https://punkwallet.io/) -**Create Eth App _-1つのコマンドでイーサリアムアプリを作成_** +**Create Eth App _- 1つのコマンドでイーサリアム搭載アプリを作成します。_** - [GitHub](https://github.com/paulrberg/create-eth-app) -**One Click Dapp _- [ABI](/glossary/#abi)から分散型アプリ(Dapp)フロントエンドを生成するFOSSツール_** +**One Click Dapp _- [ABI](/glossary/#abi)からdappのフロントエンドを生成するFOSSツールです。_** - [oneclickdapp.com](https://oneclickdapp.com) - [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) -**Etherflow _- イーサリアムデベロッパー向けのFOSSツール。ノードをテストし、ブラウザからRPC呼び出しの作成・デバッグするツール。_** +**Etherflow _- イーサリアムデベロッパーがノードをテストし、ブラウザからRPCコールを作成・デバッグするためのFOSSツールです。_** - [etherflow.quiknode.io](https://etherflow.quiknode.io/) - [GitHub](https://github.com/abunsen/etherflow) -**thirdweb _- Web3開発用の各言語のSDK、スマートコントラクト、ツール、インフラストラクチャ。_** +**thirdweb _- あらゆる言語のSDK、スマートコントラクト、ツール、web3開発のためのインフラストラクチャです。_** - [ホームページ](https://thirdweb.com/) - [ドキュメント](https://portal.thirdweb.com/) - [GitHub](https://github.com/thirdweb-dev/) -**Crossmint _- エンタープライズグレードのweb3開発プラットフォームで、スマートコントラクトのデプロイ、クレジットカードの有効化、クロスチェーン支払いが可能です。また、NFTの作成、配布、売却、保存では、APIが使用可能です。_** +**Crossmint _- スマートコントラクトのデプロイ、クレジットカード決済やクロスチェーン決済の有効化、APIを使用したNFTの作成、配布、販売、保管、編集を行うための、エンタープライズグレードのweb3開発プラットフォームです。_** - [crossmint.com](https://www.crossmint.com) - [ドキュメント](https://docs.crossmint.com) - [Discord](https://discord.com/invite/crossmint) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [dapps を探す](/apps) +- [dappsを探索する](/apps) - [Web 3.0アプリケーションのアーキテクチャ](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ -- [分散型アプリケーションに関するガイド(2021年)](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ -- [分散型アプリとは](https://www.gemini.com/cryptopedia/decentralized-applications-defi-Dapps) - _Gemini_ -- [人気のあるdApp](https://www.alchemy.com/dapps) - _Alchemy_ +- [分散型アプリケーションへの2021年ガイド](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [分散型アプリとは？](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [人気のdapps](https://www.alchemy.com/dapps) - _Alchemy_ -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} -- [イーサリアムスタック](/developers/docs/ethereum-stack/) +- [イーサリアムスタック入門](/developers/docs/ethereum-stack/) - [開発フレームワーク](/developers/docs/frameworks/) diff --git a/public/content/translations/ja/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/ja/developers/docs/data-and-analytics/block-explorers/index.md index ef3ee76260d..3bfa24f0781 100644 --- a/public/content/translations/ja/developers/docs/data-and-analytics/block-explorers/index.md +++ b/public/content/translations/ja/developers/docs/data-and-analytics/block-explorers/index.md @@ -1,31 +1,30 @@ --- -title: ブロックエクスプローラー -description: ブロックエクスプローラー (トランザクション、アカウント、コントラクトなどの情報のクエリを実行できる、ブロックチェーンデータのポータル) の紹介 +title: "ブロックエクスプローラー" +description: "ブロックエクスプローラー (トランザクション、アカウント、コントラクトなどの情報のクエリを実行できる、ブロックチェーンデータのポータル) の紹介" lang: ja sidebarDepth: 3 --- -ブロックエクスプローラーは、イーサリアムデータのポータルとして機能します。 これらを使用して、ブロック、トランザクション、バリデータ、アカウント、その他のオンチェーン活動に関するリアルタイムデータを確認できます。 +ブロックエクスプローラーは、イーサリアムデータのポータルとして機能します。 これらを使用して、ブロック、トランザクション、バリデーター、アカウント、その他のオンチェーンアクティビティのリアルタイムデータを確認できます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -ブロックエクスプローラーから提供されるデータを理解するためには、イーサリアムの基本的な概念を理解する必要があります。 [イーサリアム入門](/developers/docs/intro-to-ethereum/)から始めましょう。 +ブロックエクスプローラーから提供されるデータを理解するためには、イーサリアムの基本的な概念を理解する必要があります。 「[イーサリアム入門](/developers/docs/intro-to-ethereum/)」から始めましょう。 ## サービス {#services} -- [Etherscan](https://etherscan.io/) –_中国語、韓国語、ロシア語、日本語でも利用できます_ +- [Etherscan](https://etherscan.io/) -_中国語、韓国語、ロシア語、日本語にも対応_ - [3xpl](https://3xpl.com/ethereum) - [Beaconcha.in](https://beaconcha.in/) -- [blockchair](https://blockchair.com/ethereum) –_スペイン語、フランス語、イタリア語、オランダ語、ポルトガル語、ロシア語、中国語、ペルシア語でも利用できます_ +- [Blockchair](https://blockchair.com/ethereum) -_スペイン語、フランス語、イタリア語、オランダ語、ポルトガル語、ロシア語、中国語、ペルシア語にも対応_ - [Blockscout](https://eth.blockscout.com/) - [Chainlens](https://www.chainlens.com/) - [DexGuruブロックエクスプローラー](https://ethereum.dex.guru/) - [Etherchain](https://www.etherchain.org/) -- [Ethernow](https://www.ethernow.xyz/) -- [Ethplorer](https://ethplorer.io/) –_中国語、スペイン語、フランス語、トルコ語、ロシア語、韓国語、ベトナム語でも利用できます_ +- [Ethplorer](https://ethplorer.io/) -_中国語、スペイン語、フランス語、トルコ語、ロシア語、韓国語、ベトナム語にも対応_ - [EthVM](https://www.ethvm.com/) - [OKLink](https://www.oklink.com/eth) -- [Rantom](https://rantom.app/) +- [Ethseer](https://ethseer.io) ## オープンソースツール {#open-source-tools} @@ -94,7 +93,7 @@ sidebarDepth: 3 - Gas limit (ガスリミット) - このトランザクションで消費できるガス単位の最大値 - Gas used (ガス使用量) - トランザクションで消費された実際のガス量 - Gas price (ガス価格) - ガス単位あたりの設定価格 -- Nonce (ノンス) - `from`のアドレスのトランザクション番号 (この番号は0から始まります。そのため、この値が`100`の場合、このアカウントから送信された101番目のトランザクションとなることに留意する必要があります) +- ノンス - `from`アドレスのトランザクション番号 (0から始まるため、`100` のノンスは実際にはこのアカウントによって送信された101番目のトランザクションであることに注意してください) - Input data (入力情報) - トランザクションで必要とされる追加情報 ### アカウント {#accounts} @@ -144,7 +143,7 @@ sidebarDepth: 3 - Total ETH supply (総ETH供給量) - 流通しているETHの数。ETHは、ブロックが作成されるごとにブロック報酬というかたちで新規に作成される - Market cap (時価総額) - 計算式: 価格\*供給量 -## コンセンサスレイヤーのデータ {#consensus-layer-data} +## コンセンサスレイヤーデータ {#consensus-layer-data} ### エポック {#epoch} @@ -173,7 +172,7 @@ sidebarDepth: 3 - Block root (ブロックルート) - ビーコンブロックのハッシュツリーのルート - Parent root (親ルート) - 直前のブロックのハッシュ - State root (状態ルート) - ビーコン状態のハッシュツリーのルート -- Signature (署名) +- 署名 - Randao reveal (RanDAO公開) - Graffiti (グラフィティ) - ブロック提案者は、32バイト長のメッセージをブロック提案に含めることができる - Execution Data (実行データ) @@ -183,7 +182,7 @@ sidebarDepth: 3 - Attestations (アテステーション) - スロット内のブロックのアテステーションの数 - Deposits (デポジット) - このスロットでのデポジットの数 - Voluntary exits (自主退出) - スロット中に退出したバリデータの数 -- Slashings (スラッシング) - ブロックの提案者またはアテスターに対するペナルティの数 +- Slashings (スラッシング) - ブロック提案者またはアテスターに対するペナルティの数 - Votes (投票数) - このスロットのブロックに投票したバリデータの数 ### ブロック {#blocks-1} @@ -222,7 +221,7 @@ sidebarDepth: 3 - Beacon block root (ビーコンブロックルート) - バリデータが証明しているブロックをポイントする - Source (ソース) - 最新の正当化されたエポックをポイントする - Target (ターゲット) - 最新のエポック境界をポイントする -- Signature (署名) +- 署名 ### ネットワーク {#network-1} @@ -237,19 +236,16 @@ sidebarDepth: 3 ## ブロックエクスプローラー {#block-explorers} -- [Etherscan](https://etherscan.io/) - イーサリアムメインネット、Sepoliaテストネットのデータを取得するために使用できるブロックエクスプローラー -- [3xpl](https://3xpl.com/ethereum) - 広告無しのオープンソース・イーサリアム・エクスプローラでデータセットのダウンロードが可能 -- [Beaconcha.in](https://beaconcha.in/) - イーサリアムメインネットとSepoliaテストネットのオープンソースブロックエクスプローラー +- [Etherscan](https://etherscan.io/) - イーサリアムメインネットとテストネットのデータを取得するために使用できるブロックエクスプローラー +- [3xpl](https://3xpl.com/ethereum) - データセットのダウンロードが可能な、広告なしのオープンソースのイーサリアムエクスプローラー +- [Beaconcha.in](https://beaconcha.in/) - イーサリアムメインネットとテストネット向けのオープンソースブロックエクスプローラー - [Blockchair](https://blockchair.com/ethereum) - 最もプライベートなイーサリアムエクスプローラー。 データのソートやフィルタリング(メンプール)も可能 -- [Etherchain](https://www.etherchain.org/) - イーサリアムメインネットのブロックエクスプローラー -- [Ethplorer](https://ethplorer.io/) - イーサリアムメインネットとSepoliaテストネットのトークンを中心としたブロックエクスプローラー -- [Rantom](https://rantom.app/) - ユーザーフレンドリーで、DeFi&NFTトランザクションを詳細に把握できるオープンソースのビューア -- [Ethernow](https://www.ethernow.xyz/) - リアルタイムのトランザクションエクスプローラーで、イーサリアムメインネットのプリチェーンレイヤーを確認可能 -- [Otterscan](https://otterscan.io/) - イーサリアム用のオープンソースの代替ブロックエクスプローラー +- [Etherchain](https://www.etherchain.org/) - イーサリアムメインネット向けのブロックエクスプローラー +- [Ethplorer](https://ethplorer.io/) - イーサリアムメインネットおよびKovanテストネットのトークンに焦点を当てたブロックエクスプローラー -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/data-and-analytics/index.md b/public/content/translations/ja/developers/docs/data-and-analytics/index.md index 0a8503f68a5..6490ce7bbb4 100644 --- a/public/content/translations/ja/developers/docs/data-and-analytics/index.md +++ b/public/content/translations/ja/developers/docs/data-and-analytics/index.md @@ -1,55 +1,72 @@ --- -title: データと分析 -description: オンチェーン分析およびDappで使用するデータを取得する方法 +title: "データと分析" +description: "dappsで使用するオンチェーンの分析とデータを取得する方法" lang: ja --- ## はじめに {#Introduction} -ネットワークの活用が拡大するにつれて、オンチェーンデータには高価値の情報がますます増えています。 データ量の急増に伴い、こうした情報を計算して集約し、レポートを作成したり、dappを動作させたりするためには、多大な時間と労力が必要になってきています。 +ネットワークの利用が拡大し続けるにつれて、オンチェーンデータにはますます多くの貴重な情報が存在するようになります。 データ量の急増に伴い、こうした情報を計算して集約し、レポートを作成したり、dappを動作させたりするためには、多大な時間と労力が必要になってきています。 既存のデータプロバイダを活用することで、開発を迅速化し、より正確な結果を生み出し、維持のための労力を削減できます。 これにより、チームはプロジェクトが提供しようとしているコア機能に集中することができます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -データ分析の文脈における[ブロックエクスプローラー](/developers/docs/data-and-analytics/block-explorers/)の使用方法をより深く理解するためには、その基本的な概念を把握しておく必要があります。 また、[インデックス](/glossary/#index)の概念について熟知していると、システム設計に追加されたメリットについても理解できます。 +データ分析の文脈で[ブロックエクスプローラー](/developers/docs/data-and-analytics/block-explorers/)の使用をより深く理解するためには、その基本的な概念を理解しておく必要があります。 さらに、システム設計にもたらすメリットを理解するために、[インデックス](/glossary/#index)の概念をよく理解しておきましょう。 -アーキテクチャの基礎としては、[API](https://www.wikipedia.org/wiki/API)および[REST](https://www.wikipedia.org/wiki/Representational_state_transfer)の概念について、少なくとも理論として把握している必要があります。 +アーキテクチャの基礎という点では、たとえ理論上であっても[API](https://www.wikipedia.org/wiki/API)や[REST](https://www.wikipedia.org/wiki/Representational_state_transfer)が何であるかを理解しておくことです。 ## ブロックエクスプローラー {#block-explorers} -多くの[ブロックエクスプローラー](/developers/docs/data-and-analytics/block-explorers/)は、[RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer)な[API](https://www.wikipedia.org/wiki/API)ゲートウェイを提供しており、デベロッパーはブロック、トランザクション、バリデータ、アカウント、その他のオンチェーン活動に関するリアルタイムデータを確認できます。 +多くの[ブロックエクスプローラー](/developers/docs/data-and-analytics/block-explorers/)は、ブロック、トランザクション、バリデータ、アカウント、その他のオンチェーンアクティビティに関するリアルタイムデータへの可視性をデベロッパーに提供する[RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API)ゲートウェイを提供しています。 -デベロッパーはこうしたデータを処理して変換することで、[ブロックチェーン](/glossary/#blockchain)についての独自のインサイトおよびやり取りをユーザーに提供できます。 たとえば、[Etherscan](https://etherscan.io)は、12秒のスロットごとに実行データとコンセンサスデータを提供します。 +デベロッパーは、このデータを処理および変換して、ユーザーに[ブロックチェーン](/glossary/#blockchain)とのユニークなインサイトやインタラクションを提供することができます。 例えば、[Etherscan](https://etherscan.io)や[Blockscout](https://eth.blockscout.com)は、12秒のスロットごとに実行とコンセンサスのデータを提供しています。 ## The Graph {#the-graph} -[Graphネットワーク](https://thegraph.com/)は、ブロックチェーンデータを編成するための分散型インデックスプロトコルです。 The Graphでは、オンチェーンデータを集約するためにオフチェーンの中央データストアの構築と管理を行う必要はありません。デベロッパーは、完全にパブリックインフラストラクチャで実行できるサーバレスアプリケーションを構築できます。 +[The Graph](https://thegraph.com/)は、サブグラフとして知られるオープンAPIを通じてブロックチェーンデータを簡単にクエリできるインデックス作成プロトコルです。 -[GraphQL](https://graphql.org/)を使用することにより、デベロッパーはサブグラフと呼ばれるキュレートされた任意のオープンAPIのクエリを実行して、dappの動作に必要な情報を取得できます。 このインデックス化されたサブグラフへのクエリを実行することで、レポートとdappについて、パフォーマンスやスケーラビリティ面でのメリットを得られるだけでなく、ネットワークコンセンサスによって本質的な精度も向上します。 新たな機能改善やサブグラフがネットワークに追加されることでプロジェクトの反復処理が迅速化し、こうした機能強化をさらに活用できるようになります。 +The Graphを利用することで、デベロッパーは以下のメリットを得ることができます。 -## クライアントの多様性 +- 分散型インデックス作成: 複数のインデクサーを通じてブロックチェーンデータのインデックス作成を可能にし、単一障害点を排除します +- GraphQLクエリ: インデックス化されたデータをクエリするための強力なGraphQLインターフェースを提供し、データ取得を非常に簡単にします +- カスタマイズ: ブロックチェーンデータを変換・保存するための独自のロジックを定義し、The Graphネットワーク上の他のデベロッパーが公開したサブグラフを再利用できます -[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity/)は、バグや脆弱性に対する回復力を提供します。そのため、イーサリアムネットワーク全体の健全性にとって重要です。 現在、[clientdiversity.org](https://clientdiversity.org/)、[rated.network](https://www.rated.network)、[supermajority.info](https://supermajority.info//)、[Ethernodes](https://ethernodes.org/)など、いくつかのクライアント多様性ダッシュボードが存在します。 +この[クイックスタート](https://thegraph.com/docs/en/quick-start/)ガイドに従って、5分以内にサブグラフを作成、デプロイ、クエリしましょう。 + +## クライアントの多様性 {#client-diversity} + +[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity/)は、バグやエクスプロイトに対する回復力を提供するため、イーサリアムネットワーク全体の健全性にとって重要です。 現在、[clientdiversity.org](https://clientdiversity.org/)、[rated.network](https://www.rated.network)、[supermajority.info](https://supermajority.info//)、[Ethernodes](https://ethernodes.org/)など、いくつかのクライアント多様性ダッシュボードがあります。 ## Dune Analytics {#dune-analytics} -[Dune Analytics](https://dune.com/)は、リレーショナルデータベース(DuneSQL)テーブルのために、ブロックチェーンデータの前処理を行います。 これにより、ユーザーはSQLを使用してブロックチェーンデータのクエリを実行し、クエリ結果に基づいてダッシュボードを構築できるようになります。 オンチェーンデータは、`blocks`、`transactions`、(event) `logs`、(call) `traces`という、4つの未加工テーブルに編成されます。 一般的なコントラクトやプロトコルはデコードされており、それぞれにイベントと呼び出しのテーブルのセットがあります。 これらのイベントと呼び出しのテーブルはさらに処理され、DEX、レンディング、ステーブルコインなどのプロトコルの種類によって抽象テーブルに編成されます。 +[Dune Analytics](https://dune.com/)は、ブロックチェーンデータをリレーショナルデータベース (DuneSQL) テーブルに前処理し、ユーザーがSQLを使用してブロックチェーンデータをクエリし、クエリ結果に基づいてダッシュボードを構築できるようにします。 オンチェーンデータは、`blocks`、`transactions`、(イベント) `logs`、(コール) `traces`の4つの生テーブルに整理されています。 一般的なコントラクトやプロトコルはデコードされており、それぞれにイベントと呼び出しのテーブルのセットがあります。 これらのイベントと呼び出しのテーブルはさらに処理され、DEX、レンディング、ステーブルコインなどのプロトコルの種類によって抽象テーブルに編成されます。 + +## SQD {#sqd} + +[SQD](https://sqd.dev/)は、大量のデータへの効率的でパーミッションレスなアクセスを提供するために最適化された、分散型のハイパースケーラブルなデータプラットフォームです。 現在、イベントログ、トランザクションレシート、トレース、トランザクションごとの状態差分など、過去のオンチェーンデータを提供しています。 SQDは、カスタムデータ抽出および処理パイプラインを作成するための強力なツールキットを提供し、毎秒最大15万ブロックのインデックス作成速度を達成します。 + +始めるには、[ドキュメント](https://docs.sqd.dev/)にアクセスするか、SQDで構築できるものの[EVMの例](https://github.com/subsquid-labs/squid-evm-examples)をご覧ください。 ## SubQueryネットワーク {#subquery-network} -[SubQuery](https://subquery.network/)は、優れたデータインデクサーでデベロッパーにWeb3プロジェクト用の高速で信頼性の高い分散型にカスタマイズされたAPIを提供します。 SubQueryでは、165以上のエコシステム(イーサリアムを含む)で豊富なインデックスされたデータを用いてデベロッパーがユーザーへ直観的で没入型のエクスペリエンスを構築できるようにします。 SubQueryネットワークは、回復力があり分散型のインフラストラクチャネットワークを用いて止まらないアプリにします。 SubQueryのブロックチェーン・デベロッパー・ツールキットを用いてweb3アプリケーションの未来を構築しましょう。データ処理を行うカスタムバックエンドの構築に時間を費やす必要はありません。 +[SubQuery](https://subquery.network/)は、Web3プロジェクト向けに高速で信頼性が高く、分散化されたカスタマイズAPIをデベロッパーに提供する、主要なデータインデクサーです。 SubQueryでは、165以上のエコシステム(イーサリアムを含む)で豊富なインデックスされたデータを用いてデベロッパーがユーザーへ直観的で没入型のエクスペリエンスを構築できるようにします。 SubQueryネットワークは、回復力があり分散型のインフラストラクチャネットワークを用いて止まらないアプリにします。 SubQueryのブロックチェーン・デベロッパー・ツールキットを用いてweb3アプリケーションの未来を構築しましょう。データ処理を行うカスタムバックエンドの構築に時間を費やす必要はありません。 + +始めるには、[イーサリアムクイックスタートガイド](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html)にアクセスし、[SubQueryのマネージドサービス](https://managedservice.subquery.network/)または[SubQueryの分散型ネットワーク](https://app.subquery.network/dashboard)で公開する前に、ローカルのDocker環境でテストするために数分でイーサリアムブロックチェーンデータのインデックス作成を開始してください。 -開始するには、[イーサリアム・クイック・スタートガイド](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html)を参照し、ローカルDocker環境で数分でイーサリアムブロックチェーンデータをインデックス化してテストを行い、その後、 稼働している[SubQueryのマネージドサービス](https://managedservice.subquery.network/)か[SubQueryの分散型ネットワーク](https://app.subquery.network/dashboard)を使用してみましょう。 +## EVMクエリ言語 {#evm-query-language} -## Ethernow - メンプール・データ・プログラム {#ethernow} -[Blocknative](https://www.blocknative.com/)は、イーサリアムの履歴[メンプール・データ・アーカイブ](https://www.ethernow.xyz/mempool-data-archive)へのオープンアクセスを提供しています。 これにより、研究者やコミュニティグッドプロジェクトはイーサリアムメインネットのプレチェーンレイヤーを探索できます。 データセットはアクティブに維持されており、イーサリアムのエコシステム内のメンプールのトランザクションイベントの、最も包括的な履歴レコードを表します。 詳細は[Ethernow](https://www.ethernow.xyz/)をご覧ください。 +EVMクエリ言語 (EQL) は、EVM (イーサリアム仮想マシン) チェーンをクエリするために設計されたSQLのような言語です。 EQLの最終的な目標は、EVMチェーンのファーストクラスシチズン (ブロック、アカウント、トランザクション) に対する複雑なリレーショナルクエリをサポートし、同時にデベロッパーや研究者に日常的に使用できる人間工学に基づいた構文を提供することです。 EQLを使用すると、デベロッパーはおなじみのSQLのような構文を使用してブロックチェーンデータを取得でき、複雑な定型コードの必要性を排除できます。 EQLは、標準的なブロックチェーンデータリクエスト (例：イーサリアム上のアカウントのノンスと残高の取得、現在のブロックサイズとタイムスタンプの取得) をサポートしており、より複雑なリクエストや機能セットのサポートを継続的に追加しています。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} +- [暗号データの探求 I: データフローアーキテクチャ](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) - [Graphネットワークの概要](https://thegraph.com/docs/en/about/) -- [Graph Query Playground](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) -- [EtherScanのAPIコードの例](https://etherscan.io/apis#contracts) +- [Graphクエリプレイグラウンド](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [EtherScan上のAPIコード例](https://etherscan.io/apis#contracts) +- [BlockscoutのAPIドキュメント](https://docs.blockscout.com/devs/apis) - [Beaconcha.inビーコンチェーンエクスプローラー](https://beaconcha.in) - [Duneの基礎](https://docs.dune.com/#dune-basics) -- [SubQueryイーサリアム・クイックスタートガイド](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [SubQuery イーサリアム クイックスタートガイド](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [SQDネットワークの概要](https://docs.sqd.dev/) +- [EVMクエリ言語](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/ja/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/ja/developers/docs/data-availability/blockchain-data-storage-strategies/index.md index 27e7ca6be92..fd2827c39eb 100644 --- a/public/content/translations/ja/developers/docs/data-availability/blockchain-data-storage-strategies/index.md +++ b/public/content/translations/ja/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -1,6 +1,6 @@ --- -title: ブロックチェーン・データ・ストレージ戦略 -description: ブロックチェーンを使ってデータを保存する方法はいくつかあります。 この記事では、さまざまな戦略、そのコストとトレードオフ、そして安全に使用するための要件を比較します。 +title: "ブロックチェーン・データ・ストレージ戦略" +description: "ブロックチェーンを使ってデータを保存する方法はいくつかあります。 この記事では、さまざまな戦略、そのコストとトレードオフ、そして安全に使用するための要件を比較します。" lang: ja --- @@ -16,12 +16,12 @@ lang: ja どの方法を使用するかは、いくつかの基準に基づいて決まります。 - 情報のソース。 コールデータに含まれる情報は、ブロックチェーンそのものから直接取得することはできません。 -- 情報の行き先。 コールデータは、それが開始するトランザクション内でのみ利用可能です。 イベントはオンチェーンでアクセスすることはできません。 +- 情報の行き先。 コールデータは、それが含まれるトランザクション内でのみ利用可能です。 イベントはオンチェーンでアクセスすることはできません。 - 許容できる手間の量。 フルノードを実行するコンピュータは、ブラウザで動作するライトクライアントよりも多くの処理を行うことができます。 - 全てのノードからの情報への容易なアクセスが必要かどうか。 - セキュリティ要件。 -## セキュリティ要件{#security-requirements} +## セキュリティ要件 {#security-requirements} 一般的に、情報セキュリティは以下の3つの属性で構成されます。 @@ -33,7 +33,7 @@ lang: ja ここでの異なるソリューションはすべて、L1にハッシュが投稿されるため、優れた完全性を持っています。 しかし、可用性に関しては異なる保証があります。 -## 前提条件{#prerequisites} +## 前提条件 {#prerequisites} [ブロックチェーンの基礎](/developers/docs/intro-to-ethereum/) を十分に理解していることが前提です。 また、このページでは、読者が [ブロック](/developers/docs/blocks/) 、 [トランザクション](/developers/docs/transactions/) 、その他関連するトピックに精通していることを前提としています。 @@ -63,7 +63,7 @@ EIP-4844ブロブの主な利用ケースは、ロールアップによるトラ これは、ブロックチェーンにデータを永続的に保存する最も安価な方法です。 1バイトあたりのコストは、バイトがゼロの場合は4ガス、それ以外の値の場合は16ガスです。 データが圧縮されると（これは一般的な手法です）、すべてのバイト値が等しく出現する可能性があるため、平均コストは1バイトあたり約15.95ガスとなります。 -執筆時点では、ガス価格が12 gwei/gas、ETHの価格が2,300ドル/ETHであるため、1キロバイトあたりのコストは約45セントです。 EIP-4844以前はこれが最も安価な方法であったため、ロールアップはトランザクション情報を保存するためにこの方法を使用していました。これらの情報は [フォールトチャレンジ](https://docs.optimism.io/stack/protocol/overview#fault-proofs) のために利用可能である必要がありますが、直接オンチェーンでアクセス可能である必要はありません。 +現在（この記事の執筆時点）の価格は、ガス代が12 gwei、ETHが2300ドルです。これは、1キロバイトあたり約45セントのコストに相当します。 EIP-4844以前はこれが最も安価な方法であったため、ロールアップはトランザクション情報を保存するためにこの方法を使用していました。これらの情報は [フォールトチャレンジ](https://docs.optimism.io/stack/protocol/overview#fault-proofs) のために利用可能である必要がありますが、直接オンチェーンでアクセス可能である必要はありません。 以下は、有名なロールアップによって投稿されたトランザクションを確認できるアドレスです。 diff --git a/public/content/translations/ja/developers/docs/data-availability/index.md b/public/content/translations/ja/developers/docs/data-availability/index.md index 6af8faad589..a79cfc297f5 100644 --- a/public/content/translations/ja/developers/docs/data-availability/index.md +++ b/public/content/translations/ja/developers/docs/data-availability/index.md @@ -1,84 +1,84 @@ --- -title: データ可用性 -description: イーサリアムにおけるデータ可用性に関する問題および解決策の概要 +title: "データ可用性" +description: "イーサリアムにおけるデータ可用性に関する問題および解決策の概要" lang: ja --- 「信頼するな、検証せよ」は、イーサリアムでよく使われる格言です。 この考え方は、あなたのノードで独自に検証できることを指しています。情報が正しいのかどうかをピアから受け取ったブロックのトランザクションを全て実行することで、提案された変更がノードによって個別に計算された変更と正確に一致することを保証することが可能です。 これにより、ノードがブロックの送信者が正直であると信頼する必要がないことを意味します。 データが欠落している場合は、信頼することができまません。 -**データ可用性**は、ユーザーがブロックを検証するために必要なデータがすべてのネットワーク参加者で実際に利用可能であるという確実性を指しています。 イーサリアムのレイヤー1にあるフルノードの場合は比較的シンプルです。 フルノードは、各ブロック内のすべてのデータのコピーをダウンロードします。ダウンロードが可能であるには、 データが入手可能であることが_必要_です。 データが欠落しているブロックは、ブロックチェーンに加えられることはなく、破棄されます。 これは「オンチェーンにおけるデータ可用性」であり、モノリシックブロックチェーンの機能です。 フルノードでは、すべてのトランザクションを自分でダウンロードして実行するため、だまされて無効なトランザクションを受け入れることはありません。 ただし、モジュラー型のブロックチェーン、レイヤー2ロールアップ、ライトノードの場合では、データ可用性の状勢がより複雑になり、より高度な検証手順が必要になります。 +**データ可用性**とは、ユーザーがブロックを検証するために必要なデータが、すべてのネットワーク参加者にとって実際に利用可能であるという確信度を指します。 イーサリアムのレイヤー1上のフルノードの場合、これは比較的シンプルです。フルノードは各ブロックの全データのコピーをダウンロードしますが、このダウンロードを可能にするためには、データが利用可能で_なければなりません_。 データが欠落しているブロックは、ブロックチェーンに加えられることはなく、破棄されます。 これは「オンチェーンデータ可用性」であり、モノリシックブロックチェーンの機能です。 フルノードでは、すべてのトランザクションを自分でダウンロードして実行するため、だまされて無効なトランザクションを受け入れることはありません。 ただし、モジュラー型のブロックチェーン、レイヤー2ロールアップ、ライトノードの場合では、データ可用性の状勢がより複雑になり、より高度な検証手順が必要になります。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[ブロックチェーンの基礎](/developers/docs/intro-to-ethereum/)、特に[コンセンサス・メカニズム](/developers/docs/consensus-mechanisms/)をよく理解している必要があります。 さらに、[ブロック](/developers/docs/blocks/)、[トランザクション](/developers/docs/transactions/)、[ノード](/developers/docs/nodes-and-clients/)、[スケーリングソリューション](/developers/docs/scaling/)、およびその他の関連トピックについての知識が必要です。 +[ブロックチェーンの基礎](/developers/docs/intro-to-ethereum/)、特に[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)について、十分に理解しておく必要があります。 また、このページでは、読者が[ブロック](/developers/docs/blocks/)、[トランザクション](/developers/docs/transactions/)、[ノード](/developers/docs/nodes-and-clients/)、[スケーリングソリューション](/developers/docs/scaling/)、その他の関連トピックに精通していることを前提としています。 -## データ可用性問題 {#the-data-availability-problem} +## データ可用性の問題 {#the-data-availability-problem} データ可用性問題とは、すべてのノードがすべてのデータをダウンロードすることなく、有効なトランザクションのセットを表すブロックチェーンが追加されたことを要約された形式のいくつかのトランザクションデータからネットワーク全体を証明する必要があることを指します。 ブロックを個別に検証するには完全なトランザクションデータが必要になりますが、すべてのノードがすべてのトランザクションデータをダウンロードする必要があると、スケーリングの障壁になります。 データ可用性問題に対する解決策としては、自分自身でデータをダウンロードして保存しないネットワーク参加者に対して、完全なトランザクションデータが検証のために利用可能であることを十分に保証する状態を目指すことです。 -ネットワーク参加者が強力なデータ可用性保証を必要としているものの、自分自身でダウンロードやトランザクションデータを処理することができない重要な例としては、[ライトノード](/developers/docs/nodes-and-clients/light-clients)や[レイヤー2ロールアップ](/developers/docs/scaling)があります。 トランザクションデータのダウンロードを避けることでライトノードは軽量になり、ロールアップは効果的なスケーリングソリューションになることができます。 +[ライトノード](/developers/docs/nodes-and-clients/light-clients)と[レイヤー2ロールアップ](/developers/docs/scaling)は、強力なデータ可用性の保証を必要としながらも、トランザクションデータを自身でダウンロードして処理することができないネットワーク参加者の重要な例です。 トランザクションデータのダウンロードを避けることでライトノードは軽量になり、ロールアップは効果的なスケーリングソリューションになることができます。 -データ可用性は、ブロックを検証するために状態データをダウンロードして保存する必要のない今後の[「ステートレス」](/roadmap/statelessness)イーサリアムクライアントにとっても重要な課題事項になっています。 ステートレスクライアントでは、データが_どこか_で入手可能であることおよびデータが正しく処理されていることを依然として確認する必要があります。 +データ可用性は、ブロックを検証するために状態データをダウンロードして保存する必要のない、将来の[「ステートレス」](/roadmap/statelessness)なイーサリアムクライアントにとっても重要な懸念事項です。 ステートレスクライアントは、データが_どこかで_利用可能であり、かつ正しく処理されていることを、依然として確認する必要があります。 -## データ可用性ソリューション {#data-availability-solutions} +## データ可用性のソリューション {#data-availability-solutions} -### データ可用性サンプリング（DAS） {#data-availability-sampling} +### データ可用性サンプリング(DAS) {#data-availability-sampling} -データ可用性サンプリング (DAS) は、各ノードに過度な負担をかけずに、ネットワークでデータが取得可能であることを確認する方法です。 各ノード (非ステーキングノードを含む) は、すべてのデータからランダムに選択された小さなサブセットをダウンロードします。 サンプルのダウンロードが成功することで、すべてのデータが取得可能であることを高い信頼性をもって確認できます。 これは、データイレイジャーディングコーディングに依存しています。データイレイジャーコーディングとは、指定された冗長な情報を展開します (_多項式_として知られる関数をデータに当てはめ、追加の点において、その多項式を評価する方法をとります) 。 これにより、必要に応じて冗長データから元のデータを復元できます。 このデータ作成の結果、元のデータの_いずれか_が取得できない場合、 展開されたデータの_半分_が行方不明になります！ 各ノードによってダウンロードされるデータサンプリングの量が、実際に取得可能なデータの半分未満である_場合_では、各クライアントからサンプリングされた少なくとも1つのデータフラグメントが欠落している可能性が_極めて_高くなるように調整されています。 +データ可用性サンプリング (DAS) は、各ノードに過度な負担をかけずに、ネットワークでデータが取得可能であることを確認する方法です。 各ノード (非ステーキングノードを含む) は、すべてのデータからランダムに選択された小さなサブセットをダウンロードします。 サンプルのダウンロードが成功することで、すべてのデータが取得可能であることを高い信頼性をもって確認できます。 これは、データセットに冗長な情報を加えて拡張するデータイレイジャーコーディングに依存しています(これは、データに対して_多項式_として知られる関数を適合させ、追加の点でその多項式を評価することによって行われます)。 これにより、必要に応じて冗長データから元のデータを復元できます。 このデータ作成の結果、元のデータが_いずれかでも_利用できなくなると、拡張されたデータの_半分_が失われてしまいます! 各ノードがダウンロードするデータサンプルの量は、実際に利用可能なデータが半分未満の_場合に_、各クライアントがサンプリングしたデータフラグメントの少なくとも1つが欠落している可能性が_極めて_高くなるように調整できます。 -DASは、[完全なダンクシャーディング](/roadmap/danksharding/#what-is-danksharding)が実装された後、ロールアップオペレータがトランザクションデータを取得できることを確実にするために使われます。 イーサリアムノードでは、上述した冗長性スキームを使い、ブロブで提供されるトランザクションデータをランダムにサンプリングし、すべてのデータが存在することを確認します。 同じ手法を採用することで、ブロック生成者がすべてのデータをライトノードへ使用可能にしていることを保証できます。 同様に、[プロポーザー/ビルダーセパレーション(PBS)](/roadmap/pbs)では、ブロックビルダーはブロック全体を処理することのみが求められ、他のバリデータはデータ可用性サンプリングを用いて検証します。 +DASは、[完全なダンクシャーディング](/roadmap/danksharding/#what-is-danksharding)が実装された後、ロールアップオペレーターがトランザクションデータを利用可能にすることを保証するために使用されます。 イーサリアムノードでは、上述した冗長性スキームを使い、ブロブで提供されるトランザクションデータをランダムにサンプリングし、すべてのデータが存在することを確認します。 同じ手法を採用することで、ブロック生成者がすべてのデータをライトノードへ使用可能にしていることを保証できます。 同様に、[プロポーザー/ビルダー分離(PBS)](/roadmap/pbs)の下では、ブロック全体を処理する必要があるのはブロックビルダーだけで、他のバリデータはデータ可用性サンプリングを使用して検証します。 -### データ可用性委員会（DAC） {#data-availability-committees} +### データ可用性委員会 {#data-availability-committees} -データ可用性委員会 (DAC) は、データ可用性を提供もしくは証明する信頼できる当事者です。 DACは、DASの代わりに使うことができたり、DASと[組み合わせること](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS)ができます。 この委員会が持つ安全性の保証は、具体的な設定によって異なります。 例えばイーサリアムでは、ランダムにサンプリングされたバリデータのサブセットを使い、ライトノードのデータ可用性を証明します。 +データ可用性委員会 (DAC) は、データ可用性を提供もしくは証明する信頼できる当事者です。 DACは、DASの代わり、[またはDASと組み合わせて](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS)使用することができます。 この委員会が持つ安全性の保証は、具体的な設定によって異なります。 例えばイーサリアムでは、ランダムにサンプリングされたバリデータのサブセットを使い、ライトノードのデータ可用性を証明します。 -DACは一部のバリディアムでも使われています。 DACは、データのコピーをオフラインに保存する信頼できるノードの集合です。 紛争が発生した場合、データを取得可能にすることがDACに求めらます。 DACのメンバーはさらに、当該データが実際に提供可能であることを証明するために、オンチェーン上で誓約を公開します。 一部のバリディアムでは、DACの代わりに、プルーフ・オブ・ステーク（PoS）のバリデータシステムを導入しています。 このシステムでは、すべてのユーザーがバリデータとなり、オフチェーンでデータを保存することが可能になります。 ただし、バリデータとなるためには、スマートコントラクトに対して担保となる「ボンド」を預け入れる必要があります。 バリデータがデータを秘匿するなどの悪意の行為が発生した場合、預け入れられたボンドを没収することができます。 プルーフ・オブ・ステークのデータ可用性委員会は、正直な行動に直接インセンティブが働くため、通常のDACよりもさらに安全になっています。 +DACは一部のバリディアムでも使われています。 DACは、データのコピーをオフラインに保存する信頼できるノードの集合です。 紛争が発生した場合、データを取得可能にすることがDACに求めらます。 DACのメンバーはまた、当該データが実際に利用可能であることを証明するために、オンチェーンでアテステーションを公開します。 一部のバリディアムでは、DACの代わりに、プルーフ・オブ・ステーク（PoS）のバリデータシステムを導入しています。 ここでは、誰でもバリデータになって、オフチェーンでデータを保存できます。 ただし、バリデータとなるためには、スマートコントラクトに対して担保となる「ボンド」を預け入れる必要があります。 バリデータがデータを秘匿するなどの悪意の行為が発生した場合、預け入れられたボンドを没収することができます。 プルーフ・オブ・ステークのデータ可用性委員会は、正直な行動に直接インセンティブが働くため、通常のDACよりもさらに安全になっています。 ## データ可用性とライトノード {#data-availability-and-light-nodes} -[ライトノード](/developers/docs/nodes-and-clients/light-clients)では、ブロックデータをダウンロードせずに、受信したブロックヘッダーの正確性を検証しなければなりません。 この軽量であることの代償として、フルノードのようにローカルでトランザクションを再実行してブロックヘッダーを独自に検証できないことがあります。 +[ライトノード](/developers/docs/nodes-and-clients/light-clients)は、ブロックデータをダウンロードすることなく、受信したブロックヘッダーの正当性を検証する必要があります。 この軽量であることの代償として、フルノードのようにローカルでトランザクションを再実行してブロックヘッダーを独自に検証できないことがあります。 -イーサリアムのライトノードでは、_同期委員会_に割り当てられたバリデータのランダムなセットである512台を信頼します。 同期委員会は、暗号署名を使用してヘッダー内のデータが正しいことをライトノードに通知するデータ可用性員会(DAC)として振る舞います。 同期委員会は毎日更新されます。 同期委員会は、暗号署名を使用してヘッダー内のデータが正しいことをライトノードに通知するデータ可用性員会(DAC)として振る舞います。 +イーサリアムのライトノードは、_同期委員会_に割り当てられた512人のバリデータからなるランダムなセットを信頼します。 同期委員会は、暗号署名を使用してヘッダー内のデータが正しいことをライトノードに通知するデータ可用性員会(DAC)として振る舞います。 同期委員会は毎日更新されます。 各ブロックヘッダーは、_次の_ブロックに署名することが期待されるバリデータがどれであるかをライトノードに警告するため、ライトノードが本物の同期委員会になりすました悪意のあるグループを信用するように騙されることはありません。 -しかし、攻撃者が何らかの方法で悪意のあるブロックヘッダーをライトノードに渡し、それが正直な同期委員会によって承認されたブロックヘッダーであると信じ込ませることが_できた_場合に何が起こるでしょうか？ このケースでは、攻撃者は無効なトランザクションを含め、ライトクライアントはブロック ヘッダーに要約されているすべての状態変更を個別にチェックしないため、それらを盲目的に受け入れてしまう可能性があります。 これを防ぐために、ライトノードでは、不正証明を使うことができます。 +しかし、攻撃者が何らかの方法で悪意のあるブロックヘッダーをライトクライアントに渡し、それが誠実な同期委員会によって署名されたものだと信じ込ませることに_成功した_場合はどうなるでしょうか？ このケースでは、攻撃者は無効なトランザクションを含め、ライトクライアントはブロック ヘッダーに要約されているすべての状態変更を個別にチェックしないため、それらを盲目的に受け入れてしまう可能性があります。 これを防ぐために、ライトノードでは、不正証明を使うことができます。 この不正証明は、次のように機能します。ネットワーク上でゴシップされている無効な状態遷移を認識したフルノードは、提案された状態遷移が特定のトランザクションのセットにおいて発生する可能性がありえないことを明示した小さなデータを素早く生成し、データをピアにブロードキャストします。 ライトノードでは、これらの不正証明を取得して無効なブロックヘッダーを破棄するために使用します。これにより、フルノードと同じ正直なチェーン上に確実に存在することができます。 これは、完全なトランザクションデータにアクセスできるフルノードに依存しています。 無向なブロックヘッダーをブロードキャストし、そのトランザクションデータ使用させることに失敗した攻撃者は、フルノードが不正証明を生成することを阻止する可能性もありえます。 フルノードは無効なブロックに対して警告を出せるかもしれませんが、証明を生成するためのデータが使用可能になっていないため、その警告を証明で裏付けることができません！ -このデータ可用性問題の解決策がDASです。 ライトノードは、すべての状態データに対する非常に少量なチャンクをランダムにダウンロードして、そのサンプルを検証することで全てのデータセットが使用可能であることを確認します。 N個のチャンクをランダムにダウンロードした後にフルデータの可用性を誤って推測してしまう実際の可能性を計算できます ([100個のチャンクでは、確率は10のマイナス30乗](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)であり、非常に低い確率です) 。 +このデータ可用性問題の解決策がDASです。 ライトノードは、すべての状態データに対する非常に少量なチャンクをランダムにダウンロードして、そのサンプルを検証することで全てのデータセットが使用可能であることを確認します。 N個のランダムなチャンクをダウンロードした後に、完全なデータ可用性を誤って仮定してしまう実際の確率は計算できます([100個のチャンクの場合、その確率は10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)であり、つまり信じられないほど低い確率です)。 このシナリオでさえも、ほんの数バイトを保留する攻撃において、ランダムにデータリクエストを行うクライアントでは、気付くことが出来ない可能性があります。 イレイジャーコーディングでは、提案された状態変化をチェックするために使用するデータの小さな欠落を再構築することで解決します。 その後、再構築されたデータを使い不正証明を構築し、ライトノードが不正なヘッダーを受け入れるのを防ぎます。 -**注意:** DASと不正証明は、プルーフ・オブ・ステークにおけるイーサリアムのライトクライアントでは未実装ですが、ロードマップには含まれています。これは、ZK- SNARKベースの証明形式をとる可能性が最も高くなっています。 現在のライトクライアントでは、DAC形式に依存しています。このDAC形式では、同期委員会のIDを検証し、受信した署名付きブロックヘッダーを信頼します。 +**注:** DASと不正証明は、プルーフオブステークのイーサリアム・ライトクライアントにはまだ実装されていませんが、ロードマップには含まれており、ZK-SNARKベースの証明という形をとる可能性が最も高いです。 現在のライトクライアントでは、DAC形式に依存しています。このDAC形式では、同期委員会のIDを検証し、受信した署名付きブロックヘッダーを信頼します。 ## データ可用性とレイヤー2ロールアップ {#data-availability-and-layer-2-rollups} -[ロールアップ](/glossary/#rollups)などの[レイヤー2スケーリングソリューション](/layer-2/)では、トランザクションコストを削減したり、トランザクションをオフチェーンで処理することによりイーサリアムのスループットを向上させています。 ロールアップトランザクションは圧縮され、イーサリアムへバッチでポストされます。 バッチは、イーサリアム上の一つのトランザクション内にある数千の個々のオフチェーントランザクションに相当します。 この圧縮により、ベースレイヤーの混雑状態が軽減され、ユーザーの料金が削減されます。 +[ロールアップ](/glossary/#rollups)などの[レイヤー2スケーリングソリューション](/layer-2/)は、トランザクションをオフチェーンで処理することで、トランザクションコストを削減し、イーサリアムのスループットを向上させます。 ロールアップトランザクションは圧縮され、イーサリアムへバッチでポストされます。 バッチは、イーサリアム上の一つのトランザクション内で、数千もの個別のオフチェーントランザクションを表します。 この圧縮により、ベースレイヤーの混雑状態が軽減され、ユーザーの料金が削減されます。 -ただし、イーサリアムにポストされた「要約」トランザクションを信頼できるのは、提案された状態変更を自律的に検証することができ、すべての個別のオフチェーントランザクションを適用した結果を確認できる場合においてのみです。 ロールアップオペレータがこの検証に対してトランザクションデータを入手可能にしていなければ、ロールアップオペレータは、不正なデータを送信することができます。 +しかし、イーサリアムに投稿された「要約」トランザクションを信頼できるのは、提案された状態変更が独立して検証でき、すべての個別のオフチェーントランザクションを適用した結果であることが確認できる場合に限られます。 ロールアップオペレータがこの検証に対してトランザクションデータを入手可能にしていなければ、ロールアップオペレータは、不正なデータを送信することができます。 -[オプティミスティックロールアップ](/developers/docs/scaling/optimistic-rollups/)では、圧縮されたトランザクションデータをイーサリアムにポストし、独立した検証者がデータをチェックできるよう一定期間 (通常は7日間) 待機します。 検証者が問題を特定した場合、不正証明を生成し、それを使用してロールアップに対して異議申立ができます。 これにより、チェーンがロールバックされ、無効なブロックが除外されます。 これは、データが入手可能でないとできません。 現在、オプティミスティック・ロールアップがトランザクションをL1に投稿する方法は2つあります。 一部のロールアップは、永続的にオンチェーンに存在する`CALLDATA`として、データを永続利用可能なものにしています。 EIP-4844の実装に伴い、一部のロールアップはトランザクションデータをより安価なブロブストレージに投稿しています。 これは永続ストレージではありません。 独立した検証者は、データがイーサリアムレイヤー1から削除される約18日前までにブロブへクエリを実行し、異議申立を提起しなければなりません。 データ可用性は、イーサリアムプロトコルによって、その短い一定の窓口期間内においてのみ保証されます。 それ以降は、イーサリアムエコシステム内の他のエンティティの責任になります。 どのノードでもDASを使い (すなわち、ブロブデータのランダムなサンプルをダウンロードすることによって) データ可用性を検証することができます。 +[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)は、圧縮されたトランザクションデータをイーサリアムに投稿し、独立した検証者がデータを確認できるように一定期間(通常は7日間)待機します。 検証者が問題を特定した場合、不正証明を生成し、それを使用してロールアップに対して異議申立ができます。 これにより、チェーンがロールバックされ、無効なブロックが除外されます。 これは、データが入手可能でないとできません。 現在、オプティミスティック・ロールアップがトランザクションをL1に投稿する方法は2つあります。 一部のロールアップは、オンチェーンに永続的に存在する`CALLDATA`として、データを永続的に利用可能にします。 EIP-4844の実装に伴い、一部のロールアップはトランザクションデータをより安価なブロブストレージに投稿しています。 これは永続ストレージではありません。 独立した検証者は、データがイーサリアムレイヤー1から削除される約18日前までにブロブへクエリを実行し、異議申立を提起しなければなりません。 データ可用性は、イーサリアムプロトコルによって、その短い一定の窓口期間内においてのみ保証されます。 それ以降は、イーサリアムエコシステム内の他のエンティティの責任になります。 どのノードでもDAS、すなわちブロブデータの小さなランダムサンプルをダウンロードすることで、データ可用性を検証できます。 -[ゼロ知識 (ZK) ロールアップ](/developers/docs/scaling/zk-rollups)では、[ゼロ知識有効性証明](/glossary/#zk-proof)を用いて状態遷移の正当性を保証できるため、トランザクションデータを投稿する必要はありません。 ただし、データ可用性に対して依然として問題があります。なぜなら、状態データにアクセスできない場合、ゼロ知識ロールアップの機能（またはロールアップとのやりとり）を保証することができないからです。 具体的には、オペレータがロールアップの状態に関する詳細を公開しない場合、ユーザーは自分の残高を確認できません。 さらに、新たに追加されたブロックに含まれる情報を用いて、状態アップデートを実行することもできません。 +[ゼロ知識(ZK)ロールアップ](/developers/docs/scaling/zk-rollups)は、[ゼロ知識有効性証明](/glossary/#zk-proof)が状態遷移の正当性を保証するため、トランザクションデータを投稿する必要がありません。 ただし、データ可用性に対して依然として問題があります。なぜなら、状態データにアクセスできない場合、ゼロ知識ロールアップの機能（またはロールアップとのやりとり）を保証することができないからです。 具体的には、オペレータがロールアップの状態に関する詳細を公開しない場合、ユーザーは自分の残高を確認できません。 さらに、新たに追加されたブロックに含まれる情報を用いて、状態アップデートを実行することもできません。 -## データ可用性と取り出し可能性の違いとは？ {#data-availability-vs-data-retrievability} +## データ可用性とデータ検索可能性 {#data-availability-vs-data-retrievability} データ可用性は、データの取り出し可能性とは異なる概念です。 フルノードが特定のブロックに関連付けられたトランザクションの完全なセットにアクセスし、検証できることを保証するのがデータ可用性です。 データが永久にアクセス可能である必要はありません。 -一方、データの取り出し可能性とは、ブロックチェーンにおける_過去の情報_をノードが取り出すことができる機能を指します。 この履歴データは、新しいブロックの検証には不要です。ジェネシスブロックからフルノードを同期する場合、または特定の履歴に対するリクエストを処理する場合にのみ必要になります。 +データ検索可能性とは、ノードがブロックチェーンから_過去の情報_を取得する能力のことです。 この履歴データは、新しいブロックの検証には不要です。ジェネシスブロックからフルノードを同期する場合、または特定の履歴に対するリクエストを処理する場合にのみ必要になります。 -イーサリアムのコアプロトコルでは、主に、データの取り出し可能性についてではなく、可用性について取り上げています。 データ取り出し可能性については、サードパーティが運用する少数のアーカイブノードによって提供したり、[ポータルネットワーク](https://www.ethportal.net/)等の分散ファイルストレージを使ってネットワーク全体に分配することができます。 +イーサリアムのコアプロトコルでは、主に、データの取り出し可能性についてではなく、可用性について取り上げています。 データ検索可能性は、サードパーティが運営する少数のアーカイブノードによって提供されるか、[Portal Network](https://www.ethportal.net/)などの分散型ファイルストレージを使用してネットワーク全体に分散させることができます。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [データ可用性とは一体何ですか？](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) -- [データ可用性とは？](https://coinmarketcap.com/alexandria/article/what-is-data-availability) -- [イーサリアムにおけるオフチェーンのデータ可用性に関する現況](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/) -- [データ可用性チェックの入門](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) -- [シャーディング+ DAS提案とは何か？](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) -- [データ可用性とイレイジャーコードディングの注意事項](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) -- [データ可用性委員会（DAC）](https://medium.com/starkware/data-availability-e5564c416424) -- [プルーフ・オブ・ステークを用いたデータ可用性委員会.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) -- [データの取り出し可能性問題の解決策](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) -- [データ可用性か、あるいは： ロールアップで心配することを止めてイーサリアムを愛するようになった仕組み](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) +- [データ可用性とは一体何か？](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [データ可用性とは？](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [データ可用性チェック入門](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [シャーディング+DAS提案の解説](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [データ可用性とイレイジャーコーディングに関する注記](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [データ可用性委員会](https://medium.com/starkware/data-availability-e5564c416424) +- [プルーフオブステークのデータ可用性委員会](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [データ検索可能性問題の解決策](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [データ可用性、またはロールアップはいかにして心配するのをやめイーサリアムを愛するようになったか](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: Calldataコストの引き上げ](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/ja/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/ja/developers/docs/data-structures-and-encoding/index.md index aeb7c9b79a7..30995bbb546 100644 --- a/public/content/translations/ja/developers/docs/data-structures-and-encoding/index.md +++ b/public/content/translations/ja/developers/docs/data-structures-and-encoding/index.md @@ -1,32 +1,32 @@ --- -title: データ構造とエンコード -description: イーサリアムの基本的なデータ構造の概要 +title: "データ構造とエンコード" +description: "イーサリアムの基本的なデータ構造の概要" lang: ja sidebarDepth: 2 --- -イーサリアムは大量のデータを作成、保存、転送します。 この大量のデータは、標準化されメモリ効率の良い方法でフォーマットされ、誰でも比較的それなりのコンシューマーグレードのハードウェアで[ノードを実行](/run-a-node/)できる必要があります。 このため、イーサリアムスタックでは、いくつかの特定のデータ構造が使用されています。 +イーサリアムは大量のデータを作成、保存、転送します。 このデータは、誰でも比較的低スペックの一般向けハードウェアで[ノードを実行](/run-a-node/)できるように、標準化され、メモリ効率の良い方法でフォーマットされる必要があります。 このため、イーサリアムスタックでは、いくつかの特定のデータ構造が使用されています。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -イーサリアムと[クライアントソフトウェア](/developers/docs/nodes-and-clients/)の基礎を理解する必要があります。 ネットワークレイヤーと[イーサリアムホワイトペーパー](/whitepaper/)についての知識を身に着けることをお勧めします。 +イーサリアムと[クライアントソフトウェア](/developers/docs/nodes-and-clients/)の基礎を理解している必要があります。 ネットワークレイヤーと[イーサリアムホワイトペーパー](/whitepaper/)についての知識を身につけておくことをお勧めします。 ## データ構造 {#data-structures} -### パトリシア・マークル・ツリー {#patricia-merkle-tries} +### パトリシアマークルトライ {#patricia-merkle-tries} パトリシア・マークル・ツリーは、キー・バリュー(key-value)ペアを決定的かつ暗号的に認証されたツリーにエンコードする構造体です。 イーサリアムの実行レイヤー全体で広く使われています。 -[パトリシア・マークル・ツリーの詳細](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) +[パトリシアマークルトライの詳細](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) -### 再帰的長さのプレフィックス(RLP) {#recursive-length-prefix} +### 再帰長プレフィックス (RLP) {#recursive-length-prefix} 再帰的長さのプレフィックス(RLP)は、イーサリアム実行レイヤー全体で広く使われているシリアライゼーション方法です。 -[再帰的長さのプレフィックス(RLP)の詳細](/developers/docs/data-structures-and-encoding/rlp) +[RLPの詳細](/developers/docs/data-structures-and-encoding/rlp) -### シンプル・シリアライゼーション(SSZ) {#simple-serialize} +### シンプルシリアライズ (SSZ) {#simple-serialize} シンプル・シリアライゼーション(SSZ)は、マークライゼーションと互換性があるため、イーサリアムのコンセンサスレイヤーで主流のシリアライゼーション形式です。 -[シンプル・シリアライゼーション(SSZ)の詳細](/developers/docs/data-structures-and-encoding/ssz) +[SSZの詳細](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index cda2c97883b..f46e8cc9a92 100644 --- a/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -1,23 +1,23 @@ --- -title: マークル・パトリシア・ツリー -description: マークル・パトリシア・ツリー入門 +title: "マークル・パトリシア・ツリー" +description: "マークル・パトリシア・ツリー入門" lang: ja sidebarDepth: 2 --- -イーサリアムの状態 (あらゆるアカウント、残高、スマートコントラクトの全体) は、コンピューターサイエンスでマークルツリーとして一般的に知られている特殊なバージョンのデータ構造にエンコードされます。 この構造は、暗号技術の多くのアプリケーションにおいて有用です。なぜなら、ツリー内で関わるすべてのデータのそれぞれの部分間で検証可能な関係が作成され、データに関することを証明をするのに使用できる単一の**ルート**値が得られるからです。 +イーサリアムの状態 (あらゆるアカウント、残高、スマートコントラクトの全体) は、コンピューターサイエンスでマークルツリーとして一般的に知られている特殊なバージョンのデータ構造にエンコードされます。 この構造は、ツリー内のすべての個々のデータ間に検証可能な関係を構築し、そのデータに関する事柄を証明するために使用できる単一の**ルート**値が結果として得られるため、多くの暗号技術アプリケーションで有用です。 -イーサリアムのデータ構造は、「修正マークル・パトリシア・ツリー」です。PATRICIA (the Practical Algorithm To Retrieve Information Coded in Alphanumeric) の機能の一部を借用しており、イーサリアムの状態を構成するアイテムから成るデータの効率的な**再検索**ができるように設計されているため、そのように名付けられました。 +イーサリアムのデータ構造は「修正版マークル・パトリシア・トライ」です。これは、PATRICIA (The Practical Algorithm To Retrieve Information Coded in Alphanumeric) のいくつかの機能を借用し、イーサリアムの状態を構成するアイテムを効率的にデータ取得(re**trie**val)できるよう設計されていることから、そのように名付けられました。 -マークル・パトリシア・ツリーは、決定論的で暗号的に検証可能です。状態ルートを生成する唯一の方法は、状態のそれぞれの部分で計算することです。2つの状態が同一であることは、ルートハッシュとその計算から導かれたハッシュを比較することで簡単に証明できます (_マークルプルーフ_) 。 反対に、同じルートハッシュで2つの異なる状態を生成することはあり得ません。また、異なる値で状態を変更しようとすると、異なる状態のルートハッシュになります。 理論的には、この構造により、挿入、検索、削除で`O(log(n))`による効率の「ホーリー・グレイル」を提供します。 +マークル・パトリシア・トライは決定的かつ暗号学的に検証可能です。状態ルートを生成する唯一の方法は、状態の個々の部分から計算することであり、2つの状態が同一であることは、ルートハッシュとそれに至るハッシュ(_マークルプルーフ_)を比較することで容易に証明できます。 反対に、同じルートハッシュで2つの異なる状態を生成することはあり得ません。また、異なる値で状態を変更しようとすると、異なる状態のルートハッシュになります。 理論上、この構造は挿入、検索、削除において`O(log(n))`という効率性の「聖杯」を提供します。 -今後、イーサリアムでは[バークルツリー](/roadmap/verkle-trees)構造への移行を計画しています。これにより、将来のプロトコルの改善において、さまざまな新しい可能性が開かれます。 +近い将来、イーサリアムは[バークルツリー](/roadmap/verkle-trees)構造に移行する計画です。これにより、将来のプロトコル改善に向けた多くの新たな可能性が開かれるでしょう。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページを理解するには、[ハッシュ](https://en.wikipedia.org/wiki/Hash_function)、[マークル ツリー](https://en.wikipedia.org/wiki/Merkle_tree)、[ツリー](https://en.wikipedia.org/wiki/Trie)、[シリアライゼーション](https://en.wikipedia.org/wiki/Serialization)に関する基本的な知識が必要です。 この記事では、基本的な[基数ツリー](https://en.wikipedia.org/wiki/Radix_tree)の説明から開始します。その後、イーサリアムで最適化されたデータ構造として必要とされた変更について順を追って説明します。 +このページをよりよく理解するためには、[ハッシュ](https://en.wikipedia.org/wiki/Hash_function)、[マークルツリー](https://en.wikipedia.org/wiki/Merkle_tree)、[トライ](https://en.wikipedia.org/wiki/Trie)、[シリアライゼーション](https://en.wikipedia.org/wiki/Serialization)に関する基本的な知識があると役立ちます。 この記事では、まず基本的な[基数ツリー](https://en.wikipedia.org/wiki/Radix_tree)について説明し、次にイーサリアムのより最適化されたデータ構造に必要な変更点を段階的に紹介します。 -## 基本的な基数ツリー {#basic-radix-tries} +## 基本的な基数トライ {#basic-radix-tries} 基本的な基数ツリーでは、すべてのノードは次のようになります。 @@ -25,146 +25,149 @@ sidebarDepth: 2 [i_0, i_1 ... i_n, value] ``` -`i_0 ... i_n`は、アルファベットの記号列(通常は2進数または16進数)を表し、`value`はノードの最終値、スロット `i_0, i_1 ... i_n`の値は、`NULL`または他のノードへのポインタ(イーサリアムの場合はハッシュ値)です。 これにより、基本的な`(key, value)`型ストアが形成されます。 +ここで`i_0 ...` `i_n` はアルファベット(通常はバイナリまたは16進数)の記号を表し、`value` はノードの終端値で、`i_0, i_1 ...` の中の値は `i_n`スロットは、`NULL`か、他のノードへのポインタ(この場合はハッシュ)です。 これにより、基本的な`(key, value)`ストアが形成されます。 -キーバリューセットに対する順序を永続化するために、基数ツリーのデータ構造を使用するとします。 ツリーで現在`dog`に対応する値を知るには、最初に`dog`のアルファベットの文字を変換します(`64 6f 67`)。次に、値が見つかるまで64 6f 67のパスをたどってツリーを下ります。 つまり、ツリーのルートノードを見つけるために、フラットなキーバリューDBのルートハッシュを調べることから始めます。 これは、他のノードを指すキーの配列として表現されます。 インデックス`6`の値をキーとして使用し、フラットなキーバリューDBで検索し、ノードを1レベル下げます。 次にインデックス`4`を選択して次の値を検索し、次にインデックス`6`を選択します。 `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`のパスをたどり、ノードの値を参照して結果を返します。 +キーバリューセットに対する順序を永続化するために、基数ツリーのデータ構造を使用するとします。 トライ内でキー`dog`に現在マップされている値を見つけるには、まず`dog`をアルファベット文字に変換し(`64 6f 67`が得られる)、次に値が見つかるまでそのパスをたどってトライを下降します。 つまり、ツリーのルートノードを見つけるために、フラットなキーバリューDBのルートハッシュを調べることから始めます。 これは、他のノードを指すキーの配列として表現されます。 インデックス`6`の値をキーとして使い、フラットなkey/value DBでそれを検索して、1レベル下のノードを取得します。 次にインデックス`4`を選んで次の値を検索し、次にインデックス`6`、というように続けます。パス`root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`をたどったら、ノードの値を参照して結果を返します。 -「ツリー」で何かを検索することと、下層のフラットなキーバリュー型「データベース」で検索することには、違いがあります。 どちらもキーバリューの配列を定義しますが、下層のデータベースは従来の1ステップのキー検索が実行できます。 ツリーでキーを検索するには、複数のデータベースを検索して上記の最終値を得る必要があります。 あいまいさをなくすために、後者を`path`としましょう。 +「ツリー」で何かを検索することと、下層のフラットなキーバリュー型「データベース」で検索することには、違いがあります。 どちらもキーバリューの配列を定義しますが、下層のデータベースは従来の1ステップのキー検索が実行できます。 ツリーでキーを検索するには、複数のデータベースを検索して上記の最終値を得る必要があります。 曖昧さをなくすために、後者を`path`と呼ぶことにします。 基数ツリーの更新操作と削除操作は、次のように定義できます。 -``` - def update(node,path,value): - curnode = db.get(node) if node else [ NULL ] * 17 +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = value else: - newindex = update(curnode[path[0]],path[1:],value) + newindex = update(curnode[path[0]], path[1:], value) newnode[path[0]] = newindex - db.put(hash(newnode),newnode) + db.put(hash(newnode), newnode) return hash(newnode) - def delete(node,path): - if node is NULL: + def delete(node_hash, path): + if node_hash is NULL: return NULL else: - curnode = db.get(node) + curnode = db.get(node_hash) newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = NULL else: - newindex = delete(curnode[path[0]],path[1:]) + newindex = delete(curnode[path[0]], path[1:]) newnode[path[0]] = newindex if all(x is NULL for x in newnode): return NULL else: - db.put(hash(newnode),newnode) + db.put(hash(newnode), newnode) return hash(newnode) ``` -「マークル」基数ツリーは、決定論的に生成された暗号ハッシュダイジェストを使用してノードをリンクすることによって構築されます。 このコンテンツアドレッシング(キーバリューDBで`key == keccak256(rlp(value))`)は、格納されたデータの暗号完全性保証を提供します。 特定のツリーのルートハッシュが公に知られている場合、特定の値をツリールートに結合する各ノードのハッシュ値を提供することで、ツリーの内部にあるリーフデータにアクセスして、特定のパスに特定の値が存在していることを証明できます。 +「マークル」基数ツリーは、決定論的に生成された暗号ハッシュダイジェストを使用してノードをリンクすることによって構築されます。 このコンテンツアドレッシング(key/value DBにおいて`key == keccak256(rlp(value))`)は、保存されているデータの暗号学的な完全性を保証します。 特定のツリーのルートハッシュが公に知られている場合、特定の値をツリールートに結合する各ノードのハッシュ値を提供することで、ツリーの内部にあるリーフデータにアクセスして、特定のパスに特定の値が存在していることを証明できます。 -攻撃者は、存在しない`(path, value)`のペアの証明を提供することは不可能です。これはルートハッシュは、結局のところその下のにあるすべてのハッシュ値に基づいているためです。 下層の変更はルートハッシュを変更します。 ハッシュについては、データの構造情報を圧縮して表現し、ハッシュ関数の事前イメージによって保護されていると考えることができます。 +ルートハッシュは最終的にその下にあるすべてのハッシュに基づいているため、攻撃者が存在しない`(path, value)`ペアの証明を提供することは不可能です。 下層の変更はルートハッシュを変更します。 ハッシュについては、データの構造情報を圧縮して表現し、ハッシュ関数の事前イメージによって保護されていると考えることができます。 -基数ツリーの最小単位(1つの16 進数文字、すなわち4ビットの2進数)を「ニブル」と呼びます。 上記のように一度に1つのニブルでパスを横断している間、ノードは最大で16の子を参照することができますが`value`要素を含んでいます。 そのため、ノードは長さ17の配列として表されます。 これらの17要素配列を「ブランチノード」と呼びます。 +基数ツリーの原子単位(例: 1つの16進文字、または4ビットの2進数)を「ニブル」と呼ぶことにします。 上記のように、一度に1ニブルずつパスをたどる場合、ノードは最大16個の子を参照できますが、`value`要素も含むことができます。 そのため、ノードは長さ17の配列として表されます。 これらの17要素配列を「ブランチノード」と呼びます。 -## マークル・パトリシア・ツリー {#merkle-patricia-trees} +## マークル・パトリシア・トライ {#merkle-patricia-trees} -基数ツリーには、1つの大きな制限があります。それは、非効率的であることです。 イーサリアムのようにパスが64文字長 (`bytes32`単位のニブル数)の1つの`(path, value)`のバインディングを格納する場合、1文字を格納する1レベルに、1キロバイト以上のスペースが必要となり、また、それぞれの検索または削除には、64ステップが必要です。 次に紹介するパトリシア・ツリーは、この問題を解決します。 +基数ツリーには、1つの大きな制限があります。それは、非効率的であることです。 イーサリアムのようにパスが64文字長(`bytes32`のニブル数)である1つの`(path, value)`バインディングを保存したい場合、文字ごとに1レベルを保存するために1キロバイト以上の余分なスペースが必要になり、各検索または削除には64ステップすべてを要します。 次に紹介するパトリシア・ツリーは、この問題を解決します。 ### 最適化 {#optimization} マークル・パトリシア・ツリーのノードは、以下のいずれかです。 -1. `NULL` (空文字列を表す) -2. `branch` 17アイテムのノード `[ v0 ... v15, vt ]` -3. `leaf` 2アイテムのノード `[ encodedPath, value ]` -4. `extension` 2アイテムのノード `[ encodedPath, key ]` +1. `NULL` (空文字列として表現) +2. `branch` 17項目のノード `[ v0 ...` `v15, vt ]` +3. `leaf` 2項目のノード `[ encodedPath, value ]` +4. `extension` 2項目のノード `[ encodedPath, key ]` -64文字のパスでは、ツリーの最初のいくつかのレイヤーを横断した後、少なくとも下方の一部に分岐パスが存在しないノードに到達することは避けらません。 パスに沿って最大15の`NULL`のスパースノードを作成する必要性を回避するために、`[ encodedPath, key ]`フォームの`extension`ノードを設定することで下りへショートカットをします。この`encodedPath`は、次へスキップするための「部分パス」を含みます(後述のコンパクトエンコーディングを使用)。そして、`key` は、次のDBルックアップ用です。 +64文字のパスでは、ツリーの最初のいくつかのレイヤーを横断した後、少なくとも下方の一部に分岐パスが存在しないノードに到達することは避けらません。 パスに沿って最大15個のスパースな`NULL`ノードを作成しなくて済むように、`[ encodedPath, key ]`形式の`extension`ノードを設定して、下降をショートカットします。ここで、`encodedPath`はスキップする「部分パス」(後述のコンパクトエンコーディングを使用)を含み、`key`は次のDB検索のためのものです。 -`leaf`ノードは、`encodedPath`の最初のニブルのフラグでマークできます。パスは、前のノードのすべてのパスのフラグメントをエンコードし、`value`を直接調べることができます。 +`encodedPath`の最初のニブルにあるフラグでマークできる`leaf`ノードの場合、パスは先行するすべてのノードのパスフラグメントをエンコードしており、`value`を直接検索できます。 しかし、上記の最適化は、次の問題があります。 -パスをニブルで横断する場合、すべてのデータが`bytes`形式で格納されているため、ニブルの数が奇数になる場合があります。 例えば、ニブル`1`とニブル`01`を区別することはできません(両方とも`<01>`として格納される必要があります)。 奇数の長さを指定するには、部分パスの前にフラグをつけます。 +パスをニブル単位でたどる際、たどるべきニブルの数が奇数になることがありますが、すべてのデータは`bytes`形式で保存されるため、 例えば、ニブル`1`とニブル`01`を区別することができません(両方とも`<01>`として保存されなければならないため)。 奇数の長さを指定するには、部分パスの前にフラグをつけます。 -### 仕様: オプショナルターミネーターを使用した16進数シーケンスのコンパクトエンコーディング {#specification} +### 仕様: オプショナルターミネーター付き16進数シーケンスのコンパクトエンコーディング {#specification} -上記の_残りの部分パス長が偶数または奇数_かと、_リーフまたは拡張ノード_かを表すフラグは両方、あらゆる「2アイテムのノード」の部分パスの最初のニブルにあります。 結果は、次の通りになります。 +上述した_残りの部分パス長が奇数か偶数か_と、_リーフノードか拡張ノードか_の両方を示すフラグは、任意の2項目ノードの部分パスの最初のニブルに格納されます。 結果は、次の通りになります。 - hex char bits | node type partial path length - ---------------------------------------------------------- - 0 0000 | extension even - 1 0001 | extension odd - 2 0010 | terminating (leaf) even - 3 0011 | terminating (leaf) odd +| 16進数文字 | ビット | ノードタイプ部分 | パス長 | +| ------ | ---- | -------- | --- | +| 0 | 0000 | 拡張子 | 偶数 | +| 1 | 0001 | 拡張子 | 奇数 | +| 2 | 0010 | 終端 （リーフ） | 偶数 | +| 3 | 0011 | 終端 （リーフ） | 奇数 | -偶数の残りのパス長 (`0`または`2`)の場合 、もう一つの`0`の「パディング」のニブルが常に続きます。 +残りのパス長が偶数(`0`または`2`)の場合、常に別の`0`の「パディング」ニブルが続きます。 -``` +```python def compact_encode(hexarray): term = 1 if hexarray[-1] == 16 else 0 - if term: hexarray = hexarray[:-1] + if term: + hexarray = hexarray[:-1] oddlen = len(hexarray) % 2 flags = 2 * term + oddlen if oddlen: hexarray = [flags] + hexarray else: hexarray = [flags] + [0] + hexarray - // hexarray now has an even length whose first nibble is the flags. - o = '' - for i in range(0,len(hexarray),2): - o += chr(16 * hexarray[i] + hexarray[i+1]) + # hexarrayは、最初のニブルがフラグである偶数の長さを持ちます。 + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) return o ``` 例： -``` - > [ 1, 2, 3, 4, 5, ...] +```python + > [1, 2, 3, 4, 5, ...] '11 23 45' - > [ 0, 1, 2, 3, 4, 5, ...] + > [0, 1, 2, 3, 4, 5, ...] '00 01 23 45' - > [ 0, f, 1, c, b, 8, 10] + > [0, f, 1, c, b, 8, 10] '20 0f 1c b8' - > [ f, 1, c, b, 8, 10] + > [f, 1, c, b, 8, 10] '3f 1c b8' ``` 以下は、パトリシア・マークル・ツリーでノードを取得する拡張コードです。 -``` - def get_helper(node,path): - if path == []: return node - if node = '': return '' - curnode = rlp.decode(node if len(node) < 32 else db.get(node)) +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) if len(curnode) == 2: (k2, v2) = curnode k2 = compact_decode(k2) - if k2 == path[:len(k2)]: - return get(v2, path[len(k2):]) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) else: - return '' + return "" elif len(curnode) == 17: - return get_helper(curnode[path[0]],path[1:]) + return get_helper(curnode[path[0]], path[1:]) - def get(node,path): + def get(node_hash, path): path2 = [] for i in range(len(path)): path2.push(int(ord(path[i]) / 16)) path2.push(ord(path[i]) % 16) path2.push(16) - return get_helper(node,path2) + return get_helper(node_hash, path2) ``` -### ツリーの例 {#example-trie} +### トライの例 {#example-trie} -次の4つのパス／バリューのペアを含むツリーが必要だとします。 `('do', 'verb')`、`('dog', 'puppy')`、`('doge', 'coins')`、`('horse', 'stallion')`。 +`('do', 'verb')`、`('dog', 'puppy')`、`('doge', 'coins')`、`('horse', 'stallion')`という4つのパス/値のペアを含むトライが必要だとします。 -まず、パスと値(バリュー)の両方を`bytes`に変換します。 以下では、_paths_を実際のバイト表現 `<>`によって表示しています。しかし、 _values_は、分かりやすいように文字列として`''`で表示しています(実際は`bytes`) 。 +まず、パスと値の両方を`bytes`に変換します。 以下では、_パス_の実際のバイト表現は`<>`で示しますが、_値_は理解しやすいように`''`で示される文字列として表示されています(これらも実際には`bytes`になります): ``` <64 6f> : 'verb' @@ -183,38 +186,38 @@ sidebarDepth: 2 hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] ``` -1つのノードが内部の別のノードから参照されるとき、含まれているのは、`H(rlp.encode(node))`であり、`H(x) = keccak256(x) if len(x) >= 32 else x`と`rlp.encode`は、[RLP](/developers/docs/data-structures-and-encoding/rlp)エンコーディング関数です。 +あるノードが別のノード内で参照される場合、含まれるのは`len(rlp.encode(node)) >= 32`であれば`keccak256(rlp.encode(node))`、そうでなければ`node`です。ここで`rlp.encode`は[RLP](/developers/docs/data-structures-and-encoding/rlp)エンコーディング関数です。 -ツリーを更新するとき、新しく作成されたノードの長さが32以上の_場合_、キーバリューのペア`(keccak256(x), x)`を永続的なルックアップテーブルに格納する必要があることに注意してください。 ただし、ノードがそれよりも短い場合、関数 function f(x) = x は可逆であるため、何も格納する必要はありません。 +トライを更新する際、新しく作成されたノードの長さが32以上である_場合_、キー/値のペア`(keccak256(x), x)`を永続的なルックアップテーブルに格納する必要があることに注意してください。 ただし、ノードがそれよりも短い場合、関数 function f(x) = x は可逆であるため、何も格納する必要はありません。 -## イーサリアムのツリー {#tries-in-ethereum} +## イーサリアムにおけるトライ {#tries-in-ethereum} イーサリアムの実行レイヤーのすべてのマークルツリーは、マークル・パトリシア・ツリーを使用しています。 ブロックヘッダーに、これらのツリーの3つから、3つのルートがあります。 -1. stateRoot (ステートルート) -2. transactionsRoot (トランザクションルート) -3. receiptsRoot (レシートルート) +1. stateRoot (ステートルート) +2. transactionsRoot (トランザクションルート) +3. receiptsRoot (レシートルート) -### ステート(状態)ツリー {#state-trie} +### 状態トライ {#state-trie} -グローバルの状態ツリーが1つあり、クライアントがブロックを処理するたびに更新されます。 その中では、 `path`は常に`keccak256(ethereumAddress)`であり、`value`は常に`rlp(ethereumAccount)`です。 より具体的には、イーサリアムの`account`は、4つのアイテムの配列`[nonce,balance,storageRoot,codeHash]`です。 この点において、この`storageRoot`が、もう一つのパトリシア・ツリーであることは非常に重要です。 +グローバルの状態ツリーが1つあり、クライアントがブロックを処理するたびに更新されます。 ここでは、`path`は常に`keccak256(ethereumAddress)`であり、`value`は常に`rlp(ethereumAccount)`です。 具体的には、イーサリアムの`account`は`[nonce,balance,storageRoot,codeHash]`の4項目からなる配列です。 この時点で、この`storageRoot`が別のパトリシア・トライのルートであることは注目に値します。 -### ストレージツリー {#storage-trie} +### ストレージ・トライ {#storage-trie} -ストレージツリーは、 _すべて_のコントラクトデータが存在する場所です。 アカウントごとに個別のストレージツリーがあります。 与えられたアドレスにある、特定のストレージポジションの値を取得するには、ストレージアドレスであるストレージに格納されたデータの整数のポジションと、ブロックIDが必要です。 これらは、JSON-RPC APIで定義されている`eth_getStorageAt`に引数として渡すことができます。アドレス`0x295a70b2de5e3953354a6a8344e616ed314d7251`ストレージスロット0のデータを取得する例は、次のようになります。 +ストレージ・トライは、_すべて_のコントラクトデータが格納される場所です。 アカウントごとに個別のストレージツリーがあります。 与えられたアドレスにある、特定のストレージポジションの値を取得するには、ストレージアドレスであるストレージに格納されたデータの整数のポジションと、ブロックIDが必要です。 これらは、JSON-RPC APIで定義されている`eth_getStorageAt`に引数として渡すことができます。例えば、アドレス`0x295a70b2de5e3953354a6a8344e616ed314d7251`のストレージスロット0のデータを取得するには、次のようにします。 -``` +```bash curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} ``` -ストレージの他の要素を取得するのは、ストレージツリーのポジションを最初に計算する必要があるため、より複雑になります。 ポジションは、アドレスとストレージポジションの`keccak256`ハッシュとして計算され、両方とも長さ32バイト長になるように左からゼロが足されます。 例えば、アドレス `0x391694e7e0b0cce554cb130d723a9d27458f9298`のストレージスロット1のデータの位置は、次のようになります。 +ストレージの他の要素を取得するのは、ストレージツリーのポジションを最初に計算する必要があるため、より複雑になります。 この位置は、アドレスとストレージの位置の`keccak256`ハッシュとして計算され、両方とも長さが32バイトになるようにゼロで左詰めされます。 例えば、アドレス`0x391694e7e0b0cce554cb130d723a9d27458f9298`のストレージスロット1のデータの位置は次のようになります。 -``` +```python keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) ``` @@ -227,37 +230,37 @@ undefined "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" ``` -よって、`path`は`keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`となります。 これを使用して、前と同様にストレージツリーからデータを取得できます。 +したがって、`path`は`keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`となります。 これを使用して、前と同様にストレージツリーからデータを取得できます。 -``` +```bash curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} ``` -注: イーサリアムアカウントの`storageRoot`は、コントラクトアカウントでなければ、デフォルトで空になります。 +注: イーサリアムアカウントの`storageRoot`は、それがコントラクトアカウントでない場合、デフォルトで空になります。 -### トランザクションツリー {#transaction-trie} +### トランザクション・トライ {#transaction-trie} -ブロックごとに個別のトランザクションツリーがあり、ここでも`(key, value)`ペアが格納されます。 パスは、ここでは`rlp(transactionIndex)`で、以下によって決定される値に対応するキーを表します。 +ブロックごとに個別のトランザクション・トライがあり、これも`(key, value)`ペアを格納します。 ここでのパスは`rlp(transactionIndex)`で、これは次によって決定される値に対応するキーを表します。 -``` +```python if legacyTx: value = rlp(tx) else: value = TxType | encode(tx) ``` -詳細については、[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718)のドキュメントを参照してください。 +これに関する詳細は、[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718)のドキュメントに記載されています。 -### レシートツリー {#receipts-trie} +### レシート・トライ {#receipts-trie} -すべてのブロックは、それぞれのレシートツリーを持っています。 ここでの`path`は、`rlp(transactionIndex)`です。 `transactionIndex`は、そのトランザクションが含まれたブロック内でのインデックスです。 レシートツリーは更新されることはありません。 トランザクションと同様に、現在のレシートとレガシーのレシートがあります。 レシートツリーで特定のレシートをクエリーするには、ブロックのトランザクションのインデックス、レシートのペイロード、トランザクションタイプが必要となります。 返されるレシートは、`TransactionType`と`ReceiptPayload`の集まったものとして定義される`Receipt`タイプまたは、`rlp([status, cumulativeGasUsed, logsBloom, logs])`として定義される`LegacyReceipt`タイプとなります。 +すべてのブロックは、それぞれのレシートツリーを持っています。 ここでの`path`は`rlp(transactionIndex)`です。 `transactionIndex`は、それが含まれていたブロック内でのインデックスです。 レシートツリーは更新されることはありません。 トランザクションと同様に、現在のレシートとレガシーのレシートがあります。 レシートツリーで特定のレシートをクエリーするには、ブロックのトランザクションのインデックス、レシートのペイロード、トランザクションタイプが必要となります。 返されるレシートは、`TransactionType`と`ReceiptPayload`を連結したものとして定義される`Receipt`型、または`rlp([status, cumulativeGasUsed, logsBloom, logs])`として定義される`LegacyReceipt`型のいずれかになります。 -詳細については、[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718)のドキュメントを参照してください。 +これに関する詳細は、[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718)のドキュメントに記載されています。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [変更されたマークル・パトリシア・ツリー — イーサリアムにおける状態の保存方法](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) -- [イーサリアムのマークリング](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) -- [イーサリアムツリーの理解](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) +- [修正版マークル・パトリシア・トライ — イーサリアムはどのように状態を保存するか](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [イーサリアムにおけるマークル化](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [イーサリアム・トライを理解する](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/ja/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/ja/developers/docs/data-structures-and-encoding/rlp/index.md index 59368bf5594..a11fc9a2d67 100644 --- a/public/content/translations/ja/developers/docs/data-structures-and-encoding/rlp/index.md +++ b/public/content/translations/ja/developers/docs/data-structures-and-encoding/rlp/index.md @@ -1,24 +1,24 @@ --- -title: 再帰的な長さのプレフィックス(RLP)シリアライゼーション -description: イーサリアムの実行レイヤーのRLPエンコーディングの定義。 +title: "再帰的な長さのプレフィックス(RLP)シリアライゼーション" +description: "イーサリアムの実行レイヤーのRLPエンコーディングの定義。" lang: ja sidebarDepth: 2 --- 再帰的な長さのプレフィックス(RLP)シリアライゼーションは、イーサリアムの実行クライアントで広く使われています。 RLPはスペース効率に優れたフォーマットで、ノード間のデータ転送を標準化します。 RLPの目的は、任意のネストされたバイナリデータの配列をエンコード(符号化)することです。また、RLPはイーサリアムの実行レイヤーのオブジェクトのシリアライズに用いられる主要なエンコーディング方式です。 RLPの主な目的は、構造をエンコードすることです。正の整数を除いて、RLPは特定のデータ型(例: 文字列、浮動小数点など)のエンコードを上位のプロトコルに任せます。 正の整数は、先頭にゼロのないビックエンディアンのバイナリ形式で表現する必要があります(そのため、整数値のゼロは空のバイト配列と等価です)。 RLPを使う上位のプロトコルは、デシリアライズ化された先頭がゼロの正の整数を無効として扱わなければなりません。 -詳細については、[イーサリアムイエローペーパー (付録B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19)を参照してください。 +詳細は[イーサリアム・イエローペーパー（付録B）](https://ethereum.github.io/yellowpaper/paper.pdf#page=19)をご覧ください。 RLPを使用して辞書をエンコードするのに、次の2つの正規の方法があります。 -- `[[k1,v1],[k2,v2]...]`のように辞書順にキーを並べて使用する +- キーを辞書順にして `[[k1,v1],[k2,v2]...]` を使用します。 - イーサリアムのように上位レベルのパトリシア・ツリー・エンコーディングを使用する ## 定義 {#definition} RLPエンコーディング関数は、アイテムを取ります。 アイテムは次のように定義されます。 -- 文字列型(すなわちバイト配列) はアイテム +- 文字列 (すなわちバイト配列) はアイテムです。 - アイテムのリストはアイテム - 正の整数はアイテム @@ -27,20 +27,20 @@ RLPエンコーディング関数は、アイテムを取ります。 アイテ - 空文字列 - 「cat」という単語を含む文字列 - 任意の数の文字列を含むリスト -- 次のような、より複雑なデータ構造 `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]` -- 数字の`100` +- および `[\ +- 数値 `100` 本ページのこれ以降では、「文字列」は「あるバイト数のバイナリデータ」を意味することに注意してください。特別なエンコーディングは使用されておらず、文字列が何を指すのかの知識は必要ありません(最小でない正の整数に対する規則で要求されていない場合を除く)。 RLPエンコーディングは以下のように定義されます。 - 正の整数では、ビックエンディアンを整数として解釈した最短のバイト配列に変換されます。そして、次に以下の規則に従って文字列としてエンコードします。 -- `[0x00, 0x7f]`(10進数`[0, 127]`)の範囲にある1バイトは、そのバイト自体がRLPエンコーディングとなる。 -- その他、文字列が0～55バイトの場合、RLPエンコーディングは値が**0x80**(10進数128)に、文字列の長さを足した1バイト、続いて文字列で構成される。 したがって、最初の1バイトの範囲は`[0x80, 0xb7]`(10進数`[128, 183]`)となる。 -- 文字列の長さが55バイトを超える場合、RLPエンコーディングは、**0xb7**(10進数 183)にバイナリ形式の文字列長をバイト数を加えた1バイト、続けて文字列の長さ、次に文字列で構成される。 例えば、1024バイトの長さの文字列は、`\xb9\x04\x00` (10進数`185, 4, 0`)にエンコードされ、その後文字列となる。 ここでは、最初の1バイトとして`0xb9` (183 + 2 = 185)、次に実際の文字列の長さを示す2バイトの`0x0400` (10進数1024)が続く。 したがって、最初の1バイトの範囲は、`[0xb8, 0xbf]` (10進数`[184, 191]`)となる。 +- 値が`[0x00, 0x7f]`(10進数で`[0, 127]`)の範囲にある単一バイトの場合、そのバイト自体がRLPエンコーディングになります。 +- それ以外の場合で、文字列が0〜55バイト長の場合、RLPエンコーディングは、**0x80**(10進数で128)に文字列の長さを加算した値を持つ単一バイトと、その後に続く文字列で構成されます。 したがって、最初のバイトの範囲は `[0x80, 0xb7]`(10進数で`[128, 183]`)です。 +- 文字列が55バイトより長い場合、RLPエンコーディングは、**0xb7**(10進数183)に文字列の長さ(バイナリ形式)のバイト数を加えた値を持つ単一バイト、その後に文字列の長さ、さらにその後に文字列自体が続く構成となります。 例えば、長さ1024バイトの文字列は `\xb9\x04\x00` (10進数で `185, 4, 0`) とエンコードされ、その後に文字列が続きます。 ここで、最初のバイトは `0xb9` (183 + 2 = 185) となり、その後に実際の文字列の長さを示す2バイト `0x0400` (10進数で1024) が続きます。 したがって、最初のバイトの範囲は `[0xb8, 0xbf]` (10進数で `[184, 191]`) となります。 - 文字列が2^64バイト長以上の場合、エンコードされない可能性があります。 -- リストの全ペイロード(例えば、RLPエンコードされるすべてのアイテムを合わせた長さ)が0～55バイトである場合、RLPエンコーディングは、**0xc0**にペイロードの長さを加えた1バイト、続けてアイテムをRLPエンコーディングして続けたもので構成される。 したがって、最初のバイトの範囲は`[0xc0, 0xf7]` (10進数`[192, 247]`)となる。 -- リストの全ペイロードが、55バイトを超える場合、RLPエンコーディングは、**0xf7**にバイナリ形式のペイロードの長さのバイト数を加えた1バイト、次にペイロードの長さ、アイテムのRLPエンコーディングしたものを続けたもので構成される。 したがって、最初のバイトの範囲は、`[0xf8, 0xff]` (10進数`[248, 255]`)となる 。 +- リストの合計ペイロード(すなわち、RLPエンコードされた全アイテムの合計長)が0〜55バイト長の場合、RLPエンコーディングは、**0xc0**にペイロード長を加算した値を持つ単一バイトと、その後に続く各アイテムのRLPエンコーディングの連結で構成されます。 したがって、最初のバイトの範囲は `[0xc0, 0xf7]`(10進数で`[192, 247]`)となります。 +- リストの合計ペイロードが55バイトを超える場合、RLPエンコーディングは、**0xf7**にペイロードの長さ(バイナリ形式)のバイト数を加えた値を持つ単一バイト、その後にペイロードの長さ、さらにその後に各アイテムのRLPエンコーディングの連結が続く構成となります。 したがって、最初のバイトの範囲は `[0xf8, 0xff]`(10進数で `[248, 255]`)となります。 コードでは、これは次のようになります。 @@ -62,7 +62,7 @@ def encode_length(L, offset): elif L < 256**8: BL = to_binary(L) return chr(len(BL) + offset + 55) + BL - raise Exception("input too long") + raise Exception("input too long") def to_binary(x): if x == 0: @@ -70,40 +70,40 @@ def to_binary(x): return to_binary(int(x / 256)) + chr(x % 256) ``` -## いくつかの例 {#examples} +## 実例 {#examples} - 文字列「dog」= [ 0x83, 'd', 'o', 'g' ] -- リスト [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` -- 空文字列 ('null') = `[ 0x80 ]` -- 空リスト = `[ 0xc0 ]` -- 整数0 = `[ 0x80 ]` -- バイト '\\x00' = `[ 0x00 ]` -- バイト '\\x0f' = `[ 0x0f ]` -- バイト '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` -- 3の[集合論的表現](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` -- 文字列「Lorem ipsum dolor sit amet, consectetur adipisicing elit」= `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` +- リスト `[ \ +- 空の文字列 ('null') = `[ 0x80 ]` +- 空のリスト = `[ 0xc0 ]` +- 整数 0 = `[ 0x80 ]` +- バイト `\\x00` = `[ 0x00 ]` +- バイト `\\x0f` = `[ 0x0f ]` +- バイト `\\x04\\x00` = `[ 0x82, 0x04, 0x00 ]` +- 3の[集合論的表現](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers)、`[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- 文字列 \ `, 'e', 'l', 'i', 't' ]` ## RLPデコーディング {#rlp-decoding} RLPエンコーディング規則とプロセスに従って、RLPデコードの入力は、バイナリデータ配列とみなされます。 RLPのデコーディングプロセスは、次のようになります。 -1. 入力データの最初のバイト(プレフィックス) とデコーディングするデータ型に従った実際のデータ長とオフセット +1. 入力データの最初のバイト(すなわち、プレフィックス)に従ってデータ型、実際のデータ長、オフセットをデコードします; -2. データのタイプおよびオフセットに応じて、正の整数に関する最小エンコード規則に従って、対応するデータをデコードします。 +2. データのタイプおよびオフセットに応じて、正の整数に関する最小エンコード規則に従って、対応するデータをデコードします。 -3. 残りの入力のデコードを続行 +3. 残りの入力のデコードを続行 その中で、データ型とオフセットのデコード規則は次のようになります。 -1. 最初の1バイト(プレフィックス)の範囲が [0x00, 0x7f]の場合は、データは文字列型で、文字列はそのバイトそのもの。 +1. 最初のバイト(すなわちプレフィックス)の範囲が `[0x00, 0x7f]` の場合、データは文字列であり、その文字列はまさに最初のバイトそのものです; -2. 最初の1バイトの範囲が[0x80, 0xb7]の場合、データは文字列型。最初の1バイト、続いて最初の1バイトから 0x80 を引いた長さの文字列となる。 +2. 最初の1バイトの範囲が[0x80, 0xb7]の場合、データは文字列型。最初の1バイト、続いて最初の1バイトから 0x80 を引いた長さの文字列となる。 -3. 最初の1バイトの範囲が[0xb8, 0xbf]の場合は、データは文字列型。最初の1バイト、続いて最初の1バイトから0xb7を引いた文字列長(バイトで表す)、最後に文字列となる。 +3. 最初の1バイトの範囲が[0xb8, 0xbf]の場合は、データは文字列型。最初の1バイト、続いて最初の1バイトから0xb7を引いた文字列長(バイトで表す)、最後に文字列となる。 -4. 最初の1バイトの範囲が[0xc0, 0xf7]の場合は、データはリスト型。最初の1バイト、続いて全ペイロードが最初のバイトから0xc0を引いたものに等しい、リストの全アイテムをRLPエンコーディングして続けたものとなる。 +4. 最初の1バイトの範囲が[0xc0, 0xf7]の場合は、データはリスト型。最初の1バイト、続いて全ペイロードが最初のバイトから0xc0を引いたものに等しい、リストの全アイテムをRLPエンコーディングして続けたものとなる。 -5. 最初の1バイトの範囲が[0xf8, 0xff]の場合は、データはリスト型。最初の1バイト、続いてリストの長さが最初の1バイトから0xf7を引いたリストの全ペイロード、最後にリストのすべてのアイテムをRLPエンコーディングして続けたものとなる。 +5. 最初の1バイトの範囲が[0xf8, 0xff]の場合は、データはリスト型。最初の1バイト、続いてリストの長さが最初の1バイトから0xf7を引いたリストの全ペイロード、最後にリストのすべてのアイテムをRLPエンコーディングして続けたものとなる。 コードでは、これは次のようになります。 @@ -152,12 +152,12 @@ def to_integer(b): return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 ``` -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムのRLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) -- [イーサリアムの内部: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) -- [Coglio, A. (2020). ACL2のイーサリアムの再帰的な長さのプレフィックス arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) +- [イーサリアムにおけるRLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [イーサリアムの内部構造: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). ACL2のイーサリアムの再帰的な長さのプレフィックス arXivプレプリント arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) ## 関連トピック {#related-topics} -- [パトリシア・マークル・ツリー](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) +- [パトリシア・マークル・トライ](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/ja/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/ja/developers/docs/data-structures-and-encoding/ssz/index.md index 78f09c33af8..60042a37288 100644 --- a/public/content/translations/ja/developers/docs/data-structures-and-encoding/ssz/index.md +++ b/public/content/translations/ja/developers/docs/data-structures-and-encoding/ssz/index.md @@ -1,11 +1,11 @@ --- -title: シンプル・シリアライゼーション(SSZ) -description: イーサリアムのSSZフォーマットの説明 +title: "シンプル・シリアライゼーション(SSZ)" +description: "イーサリアムのSSZフォーマットの説明" lang: ja sidebarDepth: 2 --- -**シンプル・シリアライゼーション(SSZ)**とは、ビーコンチェーンで使用されているシリアライゼーション方法です。 これは、ピア検出プロトコルを除くコンセンサスレイヤー全体の実行レイヤーで使われたRLPシリアライゼーションに取って代わるものです。 SSZは決定的であり、効率的にマークル化するように設計されています。 SSZには、次の2つのコンポーネントがあると見なすことができます。シリアライゼーション・スキームと、シリアル化されたデータ構造を効率的に処理するように設計されたマークライゼーション・スキームです。 +**シンプル・シリアライゼーション(SSZ)**は、ビーコンチェーンで使用されているシリアライゼーション方法です。 これは、ピア検出プロトコルを除くコンセンサスレイヤー全体の実行レイヤーで使われたRLPシリアライゼーションに取って代わるものです。 RLPシリアライゼーションについての詳細は、[Recursive-length prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp/)をご覧ください。 SSZは決定的であり、効率的にマークル化するように設計されています。 SSZには、次の2つのコンポーネントがあると見なすことができます。シリアライゼーション・スキームと、シリアル化されたデータ構造を効率的に処理するように設計されたマークライゼーション・スキームです。 ## シンプル・シリアライゼーション(SSZ) {#how-does-ssz-work} @@ -16,7 +16,7 @@ sidebarDepth: 2 - 符号なし整数型 - ブール型 -複雑な「複合型」の場合は、異なる型やサイズ、その両方を持つ可能性のある複数の要素を含むため、シリアライゼーションがより煩雑になります。 これらのオブジェクトがすべて固定長(すなわち、要素のサイズは実際の値に関係なく常に一定)である場合、シリアライゼーションは単に、複合型の各要素をリトルエンディアンのバイト文字列に変換することで、 これらのバイト文字列が結合されます。 シリアル化されたオブジェクトは、デシリアル化されたオブジェクトに現れるのと同じ順序で、固定長の要素がバイトリストで表現された内容になっています。 +複雑な「複合型」の場合は、異なる型やサイズ、その両方を持つ可能性のある複数の要素を含むため、シリアライゼーションがより煩雑になります。 これらのオブジェクトがすべて固定長(つまり、要素のサイズが実際の値に関わらず常に一定)である場合、シリアライゼーションとは、複合型の各要素をリトルエンディアンのバイト文字列に変換して並べるだけの単純なものです。 これらのバイト文字列が結合されます。 シリアル化されたオブジェクトは、デシリアル化されたオブジェクトに現れるのと同じ順序で、固定長の要素がバイトリストで表現された内容になっています。 可変長の型では、実データは、シリアル化されたオブジェクトの要素の位置である「オフセット」値によって置き換えます。 実データは、シリアル化されたオブジェクトの最後のヒープに追加されます。 オフセット値は、ヒープ内の実データの開始を示すインデックスであり、関連するバイトへのポインターとして機能します。 @@ -44,14 +44,14 @@ sidebarDepth: 2 ``` -`serialized`は、次のような構造になります。 ここでは、4ビットにしていますが、実際は32ビットに付け足されます。また、分かりやすくするために `int`(整数型)で表しています。 +`serialized`は次のような構造になります(ここでは4ビットにパディングされていますが、実際には32ビットにパディングされ、分かりやすくするために`int`表現を維持しています): ``` [37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] ------------ ----------- ----------- ----------- ---------- | | | | | - number1 number2 offset for number 3 value for - vector vector + number1 number2 vectorの number 3 vectorの + オフセット 値 ``` @@ -59,11 +59,11 @@ sidebarDepth: 2 ``` [ - 37, 0, 0, 0, # little-endian encoding of `number1`. - 55, 0, 0, 0, # little-endian encoding of `number2`. - 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 22, 0, 0, 0, # little-endian encoding of `number3`. - 1, 2, 3, 4, # The actual values in `vector`. + 37, 0, 0, 0, # `number1`のリトルエンディアンエンコーディング。 + 55, 0, 0, 0, # `number2`のリトルエンディアンエンコーディング。 + 16, 0, 0, 0, # `vector`の値が始まる場所を示す「オフセット」(リトルエンディアン16)。 + 22, 0, 0, 0, # `number3`のリトルエンディアンエンコーディング。 + 1, 2, 3, 4, # `vector`の実際の値。 ] ``` @@ -71,40 +71,39 @@ sidebarDepth: 2 ``` [ - 10100101000000000000000000000000 # little-endian encoding of `number1` - 10110111000000000000000000000000 # little-endian encoding of `number2`. - 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 10010110000000000000000000000000 # little-endian encoding of `number3`. - 10000001100000101000001110000100 # The actual value of the `bytes` field. + 10100101000000000000000000000000 # `number1`のリトルエンディアンエンコーディング + 10110111000000000000000000000000 # `number2`のリトルエンディアンエンコーディング。 + 10010000000000000000000000000000 # `vector`の値が始まる場所を示す「オフセット」(リトルエンディアン16)。 + 10010110000000000000000000000000 # `number3`のリトルエンディアンエンコーディング。 + 10000001100000101000001110000100 # `bytes`フィールドの実際の値。 ] ``` 可変長型の実際の値は、シリアル化されたオブジェクトの末尾にあるヒープに格納され、オフセット値はフィールドの順序付けられたリストの正しい位置に格納されます。 -また、特別な対応が必要となる特殊ケースもあります。例えば、`BitList`型のように、シリアル化時に長さの上限を追加し、デシリアル化時に削除する必要があるような型です。 詳細については、[SSZの仕様](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)を参照してください。 +また、特別な対応が必要となる特殊ケースもあります。例えば、`BitList`型のように、シリアル化時に長さの上限を追加し、デシリアル化時に削除する必要があるような型です。 詳細は[SSZ仕様](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)でご覧いただけます。 ### デシリアライゼーション {#deserialization} このオブジェクトをデシリアライズするには、スキーマが必要になります。 スキーマに、シリアル化されたデータの正確なレイアウトを定義することで、特定の各要素をバイトのブロブ(blob)から適切な型、値、サイズ、位置を持つ意味のあるオブジェクトにデシリアル化できるようにします。 どれがオフセット値でどれが実際の値であるか伝えるのは、デシリアライザーです。 全フィールド名は、オブジェクトがシリアル化されたときに消えますが、スキーマによりデシリアライゼーション時に再インスタンス化されます。 -SSZに関するインタラクティブな説明については、[ssz.dev](https://www.ssz.dev/overview)を参照してください。 +これに関するインタラクティブな説明については、[ssz.dev](https://www.ssz.dev/overview)をご覧ください。 -## マークライゼーション(Merkleization) {#merkleization} +## マークル化 {#merkleization} このSSZでシリアル化されたオブジェクトは、次にマークル化でき、つまり同データをマークルツリー表現に変換できます。 最初に、シリアル化されたオブジェクトの32バイトのチャンク数が決定されます。 これらは、ツリー (木) の「リーフ (葉) 」です。 リーフの合計数が、2の冪乗でなければなりません。これにより、リーフをまとめてハッシュ化すると、最終的に単一のハッシュ・ツリー・ルートが生成されます。 2の冪乗にならない場合は、32バイトのゼロを持つリーフが追加されます。 図式化すると次のようになります。 ``` - hash tree root + ハッシュツリールート / \ / \ / \ / \ - hash of leaves hash of leaves - 1 and 2 3 and 4 + リーフ1と2のハッシュ リーフ3と4のハッシュ / \ / \ / \ / \ / \ / \ - leaf1 leaf2 leaf3 leaf4 + リーフ1 リーフ2 リーフ3 リーフ4 ``` また、上の例のように自然にツリーのリーフが均等とならない場合があります。 例えば、リーフ4 (leaf4)が複数の要素を持ちマークルツリーに「深さ」を追加する必要があるコンテナだとすると、不均一なツリーになる場合があります。 @@ -113,7 +112,7 @@ SSZに関するインタラクティブな説明については、[ssz.dev](http ## 一般化インデックス {#generalized-indices} -一般化インデックスは、各ノードが`2 ** depth + index in row`に一般化したインデックスを持つ二分マークルツリーのノードを表す整数です。 +一般化インデックスとは、二分マークルツリー内のノードを表す整数であり、各ノードは`2 ** depth + index in row`という一般化インデックスを持ちます。 ``` 1 --depth = 0 2**0 + 0 = 1 @@ -128,10 +127,11 @@ SSZに関するインタラクティブな説明については、[ssz.dev](http 特定の要素を表す一般化インデックスのリストを提供することで、ハッシュ・ツリー・ルートに対して検証することができます。 このルートは、受け入れられた真実のバージョンです。 提供されたすべてのデータは、(一般化インデックスによって決定された)マークルツリー内の適切な場所に挿入し、ルートが一定のままであることを確認することで、真実性に対して検証することができます。 [こちら](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)の仕様書に、一般化インデックスの特定のセットの内容を検証するために必要なノードの最小セットを計算する方法として、関数が示されています。 -例えば、下記のツリーのインデックス9のデータを検証する場合、インデックス8、9、5、3、1のデータのハッシュが必要です。 (8,9)のハッシュは、(4)のハッシュと等しい必要があり、これは5とハッシュして2を生成し、3とハッシュしてツリールート1を生成します。 もし、9に誤ったデータが提供された場合、ルートが変更されることになります。これを検知し、ブランチの検証が失敗します。 +例えば、下記のツリーのインデックス9のデータを検証する場合、インデックス8、9、5、3、1のデータのハッシュが必要です。 +(8,9)のハッシュは、(4)のハッシュと等しい必要があり、これは5とハッシュして2を生成し、3とハッシュしてツリールート1を生成します。 もし、9に誤ったデータが提供された場合、ルートが変更されることになります。これを検知し、ブランチの検証が失敗します。 ``` -* = data required to generate proof +* = プルーフの生成に必要なデータ 1* 2 3* @@ -140,10 +140,10 @@ SSZに関するインタラクティブな説明については、[ssz.dev](http ``` -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [イーサリアムのアップグレード: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) -- [イーサリアムのアップグレード: マークライゼーション](https://eth2book.info/altair/part2/building_blocks/merkleization) -- [SSZの実装](https://github.com/ethereum/consensus-specs/issues/2138) -- [SSZ計算器](https://simpleserialize.com/) +- [イーサリアムのアップグレード: マークル化](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [SSZ実装](https://github.com/ethereum/consensus-specs/issues/2138) +- [SSZ計算機](https://simpleserialize.com/) - [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/ja/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/ja/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md index d96a9f05263..591f91c7c58 100644 --- a/public/content/translations/ja/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md +++ b/public/content/translations/ja/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md @@ -1,6 +1,6 @@ --- -title: Web3シークレットストレージの定義 -description: Web3シークレットストレージの正式な定義 +title: "Web3シークレットストレージの定義" +description: "Web3シークレットストレージの正式な定義" lang: ja sidebarDepth: 2 --- diff --git a/public/content/translations/ja/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/ja/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md new file mode 100644 index 00000000000..53a43fdc78a --- /dev/null +++ b/public/content/translations/ja/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -0,0 +1,195 @@ +--- +title: "Web3シークレットストレージの定義" +description: "Web3シークレットストレージの正式な定義" +lang: ja +sidebarDepth: 2 +--- + +アプリをイーサリアムで動作させるために、web3.jsライブラリが提供するWeb3オブジェクトを使用できます。 これは、内部でRPC呼び出しを介してローカルノードと通信します。 [web3](https://github.com/ethereum/web3.js/)は、RPCレイヤーを公開しているイーサリアムノードと連携します。 + +`web3`には、`eth`オブジェクト - web3.ethが含まれています。 + +```js +var fs = require("fs") +var recognizer = require("ethereum-keyfile-recognizer") + +fs.readFile("keyfile.json", (err, data) => { + var json = JSON.parse(data) + var result = recognizer(json) +}) + +/** 結果 + * [ 'web3', 3 ] web3 (v3) キーファイル + * [ 'ethersale', undefined ] Ethersale キーファイル + * null 無効なキーファイル + */ +``` + +この文書は、Web3 Secret Storage Definitionの**バージョン3**を記述したものです。 + +## 定義 {#definition} + +ファイルのエンコードとデコードは、暗号化アルゴリズムがAES-128-CBCに固定されなくなったことを除いて(AES-128-CTR が最小要件になりました)、実際にはバージョン1からほとんど変更されていません 。 ほとんどの意味/アルゴリズムはバージョン1と似ていますが、`mac`は例外です。`mac`は、導出鍵の左から2番目の16バイトと完全な`ciphertext`を連結したもののSHA3 (keccak-256)として与えられます。 + +秘密鍵ファイルは、`~/.web3/keystore`（Unix系システムの場合）と`~/AppData/Web3/keystore`（Windowsの場合）に直接保存されます。 ファイル名は任意に設定できますが、`.json`という命名規則が推奨されます。ここで``は、秘密鍵に付与された128ビットのUUID（秘密鍵のアドレスのプライバシーを保護するプロキシ）です。 + +これらのファイルはすべて、関連付けられたパスワードを持っています。 所定の`.json`ファイルの秘密鍵を導出するには、まずファイルの暗号化鍵を導出します。これは、ファイルのパスワードを取得し、それを`kdf`鍵で記述されている鍵導出関数に渡すことによって行われます。 KDF関数へのKDF依存の静的パラメータおよび動的パラメータは、`kdfparams`鍵に記述されています。 + +次に示されるPBKDF2は、最小限に準拠したすべての実装でサポートされている必要があります。 + +- `kdf`: `pbkdf2` + +PBKDF2の場合、kdfparamsは次を含みます。 + +- `prf`: `hmac-sha256`でなければなりません（将来的に拡張される可能性があります）； +- `c`: 反復回数; +- `salt`: PBKDFに渡されるソルト; +- `dklen`: 導出鍵の長さ。 32以上である必要があります。 + +ファイルの鍵が導出されたら、MACの導出によってそれを検証する必要があります。 MACは、導出鍵の左から2番目の16バイトと`ciphertext`鍵の内容を連結して形成されるバイト配列のSHA3 (keccak-256) ハッシュとして計算される必要があります。すなわち、次のようになります： + +```js +KECCAK(DK[16..31] ++ ) +``` + +（`++`は連結演算子） + +この値は`mac`鍵の内容と比較する必要があります。もし値が異なる場合は、別のパスワードを要求する（あるいは操作をキャンセルする）必要があります。 + +ファイルの鍵が検証された後、暗号文（ファイル内の`ciphertext`鍵）は、`cipher`鍵で指定され、`cipherparams`鍵を通じてパラメータ化された対称暗号アルゴリズムを使用して復号できます。 導出鍵のサイズとアルゴリズムの鍵のサイズが一致しない場合、ゼロが付け足され、導出鍵の右端のバイトをアルゴリズムのキーとして使用する必要があります。 + +最小限の準拠をしたすべての実装は、次に示されるAES-128-CTRアルゴリズムをサポートする必要があります。 + +- `cipher: aes-128-ctr` + +この暗号は、cipherparams鍵への鍵として与えられる次のパラメーターを取ります。 + +- `iv`: 暗号の128ビット初期化ベクトル。 + +暗号の鍵は、導出鍵の左端16バイト、すなわち`DK[0..15]`です。 + +秘密鍵の作成/暗号化は、本質的にはこれらの命令の逆であるべきです。 `uuid`、`salt`、`iv`が実際にランダムであることを確認してください。 + +バージョンの「ハードな」識別子として機能する`version`フィールドに加えて、実装では`minorversion`を使用して、フォーマットへのより小さな、破壊的変更を伴わない変更を追跡することもできます。 + +## テストベクトル {#test-vectors} + +詳細: + +- `アドレス`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `パスワード`: `testpassword` +- `シークレット`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +`AES-128-CTR`と`PBKDF2-SHA-256`を使用したテストベクトル： + +`~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`のファイル内容： + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "6087dab2f9fdbbfaddc31a909735c1e6" + }, + "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", + "kdf": "pbkdf2", + "kdfparams": { + "c": 262144, + "dklen": 32, + "prf": "hmac-sha256", + "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" + }, + "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**中間値**: + +`導出鍵`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` +`MACボディ`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` +`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` +`暗号鍵`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +AES-128-CTRとスクリプトを使用したテストベクトル + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "740770fce12ce862af21264dab25f1da" + }, + "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" + }, + "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**中間値**: + +`導出鍵`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` +`MACボディ`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` +`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` +`暗号鍵`: `7446f59ecc301d2d79bc3302650d8a5c` + +## バージョン1からの変更点 {#alterations-from-v2} + +このバージョンでは、[こちら](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst)で公開されたバージョン1との間のいくつかの矛盾点を修正しています。 簡単には次のとおりです。 + +- 大文字の使用が正当化されていなく、一貫性がない(scryptの小文字、Kdfの大文字と小文字の混合、MACの大文字) 。 +- 不必要な対処とプライバシーの侵害。 +- `Salt`は本質的に鍵導出関数のパラメータであり、暗号全般ではなく、鍵導出関数に関連付けられるべきです。 +- _SaltLen_は不要です（Saltから導出するだけです）。 +- 鍵導出関数が与えられているが、暗号アルゴリズムは厳密に指定されている。 +- `Version`は本質的には数値ですが、文字列です（文字列でも構造化されたバージョン管理は可能ですが、めったに変更されない設定ファイル形式の範囲外とみなすことができます）。 +- `KDF`と`cipher`は概念的には兄弟関係にある概念ですが、異なる構成になっています。 +- `MAC`は、空白を無視するデータ（!）から計算されます。 + +次のフォーマットのファイルを提供するように変更。以前リンクされいたページに示されている例と機能的に同等。 + +```json +{ + "crypto": { + "cipher": "aes-128-cbc", + "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", + "cipherparams": { + "iv": "16d67ba0ce5a339ff2f07951253e6ba8" + }, + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" + }, + "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", + "version": 1 + }, + "id": "0498f19a-59db-4d54-ac95-33901b4f1870", + "version": 2 +} +``` + +## バージョン2からの変更点 {#alterations-from-v2} + +バージョン2は、初期のC++実装で多くのバグがありました。 すべての必須機能は、バージョン2から変更ありません。 diff --git a/public/content/translations/ja/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/ja/developers/docs/design-and-ux/dex-design-best-practice/index.md index df9ee52e5e8..cafc481682e 100644 --- a/public/content/translations/ja/developers/docs/design-and-ux/dex-design-best-practice/index.md +++ b/public/content/translations/ja/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -1,11 +1,11 @@ --- -title: 分散型取引所 (DEX) のデザインベストプラクティス -description: トークンをスワップする際のUX/UIの意思決定を解説するガイド +title: "分散型取引所 (DEX) のデザインベストプラクティス" +description: "トークンをスワップする際のUX/UIの意思決定を解説するガイド" lang: ja --- 2018年にUniswapが登場して以来、数十の異なるチェーンで数百の分散型取引所が立ち上げられてきました。 -多くのDEXは新しい要素を導入したり、自分たち独自の工夫を加えたりしていますが、インターフェースは基本的に同じままです。 +それらの多くは新しい要素を導入したり、独自のひねりを加えたりしましたが、インターフェースは概ね同じままでした。 この理由の1つが[Jakobの法則](https://lawsofux.com/jakobs-law/)です。 @@ -204,7 +204,7 @@ DeFi初期の頃は、法定通貨換算の価値表示がしばしば欠けて ![Error message shown within the main CTA](./17.png) -### Figmaファイルで自作する {#build-your-own-with-this-figma-file} +## Figmaファイルで自作する {#build-your-own-with-this-figma-file} 複数のプロトコルの尽力により、DEXのデザインは大幅に改善されました。 私たちは、ユーザーが必要とする情報や、その表示方法、そしてできるだけスムーズなフローの作り方を理解しています。 この記事がUXの基本原則についてのしっかりとした概要を提供できていれば幸いです。 diff --git a/public/content/translations/ja/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/ja/developers/docs/design-and-ux/heuristics-for-web3/index.md index f0f9ddd4b21..455618ee6b0 100644 --- a/public/content/translations/ja/developers/docs/design-and-ux/heuristics-for-web3/index.md +++ b/public/content/translations/ja/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -1,11 +1,11 @@ --- -title: Web3インターフェースデザインのための7つのヒューリスティック -description: Web3のユーザビリティを向上させるための原則 +title: "Web3インターフェースデザインのための7つのヒューリスティック" +description: "Web3のユーザビリティを向上させるための原則" lang: ja --- ユーザビリティヒューリスティックとは、サイトの使いやすさを評価するために使用できる広範な「経験則」です。 -これらのヒューリスティックは、特にWeb3に合わせて調整されており、Jakob Nielsenの[インタラクションデザインに関する10の一般原則](https://www.nngroup.com/articles/ten-usability-heuristics/)と併せて使用するべきものです。 +ここでは、ジャコブ・ニールセンの[インタラクションデザインのための10の一般的な原則](https://www.nngroup.com/articles/ten-usability-heuristics/)と合わせて、特にWeb3向けに調整された7つのヒューリスティクスを用いるべきです。 ## Web3のための7つのユーザビリティヒューリスティック {#seven-usability-heuristics-for-web3} @@ -52,7 +52,7 @@ lang: ja 例: フッターに目立つサイズで監査結果を掲載します。 -![Audits referenced in the website footer](./Image2.png) +![ウェブサイトのフッターで参照されている監査](./Image2.png) ### 3. 最も重要な情報が明確である {#the-most-important-info-is-obvious} diff --git a/public/content/translations/ja/developers/docs/design-and-ux/index.md b/public/content/translations/ja/developers/docs/design-and-ux/index.md index 975ebeb4f33..ce973df0762 100644 --- a/public/content/translations/ja/developers/docs/design-and-ux/index.md +++ b/public/content/translations/ja/developers/docs/design-and-ux/index.md @@ -1,79 +1,80 @@ --- -title: Web3のデザインとUX -description: Web3におけるUXデザインおよびリサーチの紹介とイーサリアム +title: "Web3のデザインとUX" +description: "Web3におけるUXデザインおよびリサーチの紹介とイーサリアム" lang: ja --- イーサリアムを使ったデザインは初めてでしょうか？ そうならば、ここはあなたに適した場所です。 イーサリアムコミュニティでは、Web3のデザインとリサーチの基礎を紹介するためのリソースを作っています。 ここでは、あなたがよく知っている他のアプリのデザインとは異なる可能性があるコア・コンセプトについて学びます。 -それより前に、Web3の基礎を理解したいでしょうか？ でしたら[**学習ハブ**](/learn/)を参照ください。 +それより前に、Web3の基礎を理解したいでしょうか？ 「[**ラーニングハブ**](/learn/)」をご覧ください。 -## ユーザーリサーチを始める {#start-with-user-research} +## ユーザーリサーチから始める {#start-with-user-research} -効果的なデザインは、視覚的に魅力的なユーザーインターフェイスを作成するだけにとどまりません。 ユーザーのニーズ、目的、推進要因などを深く理解することが伴います。 そのため、すべてのデザイナーが[**ダイヤモンドプロセス**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model))などのデザインプロセスを採用することをお勧めします。これは、仕事が意図的であることを確実にします。 +効果的なデザインは、視覚的に魅力的なユーザーインターフェイスを作成するだけにとどまりません。 ユーザーのニーズ、目的、推進要因などを深く理解することが伴います。 そのため、すべてのデザイナーが、その作業を慎重かつ意図的に行えるように、[**ダブルダイヤモンドプロセス**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\))のようなデザインプロセスを採用することを強く推奨します。 -- [Web3では、より多くのUXリサーチャーとデザイナーが必要](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - 現在のデザイン成熟度の概要 -- [web3におけるUXリサーチの簡単なガイド](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - リサーチ方法の簡単なガイド -- [Web3におけるUXデザインのアプローチ方法](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - 定量的リサーチと定性的リサーチの概要とその2つの違い (6分間のビデオ) -- [Web3のUXリサーチャーになること](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Web3のUXリサーチャーがどのようなものかついての個人的な見解 +- [Web3にはより多くのUXリサーチャーとデザイナーが必要](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - 現在のデザイン成熟度の概要 +- [Web3におけるUXリサーチの簡単なガイド](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - リサーチ方法の簡単なガイド +- [Web3におけるUXの意思決定へのアプローチ方法](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - 定量的リサーチと定性的リサーチの概要とその2つの違いについての簡単な解説 (動画、6分) +- [Web3のUXリサーチャーであること](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Web3のUXリサーチャーであることについての私見 -## Web3の調査研究 {#research-in-web3} +## Web3における調査研究 {#research-in-web3} ここにあるのは、Web3の分野で行われたユーザー調査についての収集したリストです。デザインや製品の決定に役立てることができます。もしくは、独自調査におけるインスピレーションとして役立ちます。 -| フォーカス分野 | 名前 | -|:---------------------------------------------------- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 暗号通過へのオンボーディング | [CRADL: 暗号通貨のUX](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | -| 暗号通過へのオンボーディング | [CRADL: 暗号通貨の勉強会](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | -| 暗号通過へのオンボーディング | [ビットコインUXレポート](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | -| 暗号通過へのオンボーディング | [ConSensys: 2023年の世界におけるWeb3への認識に関する状態](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | -| 暗号通過へのオンボーディング | [NEAR: 導入へのプロセスを加速](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | -| ステーキング | [ステーキング: 主要なトレンド、要点、予測 - ETHステーカー](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | -| ステーキング | [複数のアプリのステーキング](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | -| 自律分散型組織 | [2022年DAOリサーチのアップデート: DAOビルダーが必要なことは何か？](https://blog.aragon.org/2022-dao-research-update/) | -| 分散型金融(DeFi) | [2024年のDefiの状態](https://stateofdefi.org/) (調査中) | -| 分散型金融(DeFi) | [カバレッジプール](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | -| 分散型金融(DeFi) | [ConSensys: 2022年DeFiユーザーリサーチレポート](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | -| メタバース | [メタバース: ユーザーリサーチレポート](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | -| メタバース | [Going on Safari: メタバースでのユーザリサーチ](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (27分間のビデオ) | -| Ethereum.org UXの状況 | [ユーザビリティとユーザ満足度調査ダッシュボード - Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) | - -## Web3のデザイン {#design-for-web3} - -- 「[Web3 UXデザインハンドブック](https://web3ux.design/)」 - Web3アプリを設計するための実践的ガイド -- [Web3デザイン原則](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - ブロックチェーンベースのDappsにおけるUXルールのフレームワーク -- [ブロックチェーンデザイン原則](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - IBMのブロックチェーン設計チームが学んだ教訓 -- [Web3デザインパターン](https://www.web3designpatterns.io/)- 実際のWeb3製品から収集されたデザインパターンのライブラリ -- [W3design.io](https://w3design.io/) - エコシステム内のさまざまなプロジェクトのUIフローを収集したライブラリ +| フォーカス分野 | 名前 | +| :-------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 暗号通貨のオンボーディング | [The Reown Pulse 2024: Crypto Consumer Sentiment & Usage](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | +| 暗号通貨のオンボーディング | [CRADL: 暗号通貨におけるUX](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | +| 暗号通貨のオンボーディング | [CRADL: 暗号通貨へのオンボーディング](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | +| 暗号通貨のオンボーディング | [ビットコインUXレポート](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | +| 暗号通貨のオンボーディング | [ConSensys: 2023年 世界のWeb3に対する認識の現状](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | +| 暗号通貨のオンボーディング | [NEAR: 普及への道のりを加速する](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| ステーキング | [OpenUX: Rocket PoolノードオペレーターのUX](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | +| ステーキング | [ステーキング: 主なトレンド、要点、予測 - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | +| ステーキング | [マルチアプリステーキング](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | +| DAO | [2022年DAOリサーチアップデート: DAOビルダーが必要とするものとは?](https://blog.aragon.org/2022-dao-research-update/) | +| DeFi | [カバレッジプール](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| DeFi | [ConSensys: 2022年DeFiユーザーリサーチレポート](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | +| メタバース | [メタバース: ユーザーリサーチレポート](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | +| メタバース | [サファリに行く: メタバースでのユーザーリサーチ](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (動画、27分) | + +## Web3のためのデザイン {#design-for-web3} + +- [Web3 UXデザインハンドブック](https://web3ux.design/) - Web3アプリ設計のための実践的ガイド +- [Web3デザイン原則](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - ブロックチェーンベースのdappsのためのUXルールのフレームワーク +- [ブロックチェーンデザイン原則](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - IBMのブロックチェーンデザインチームから得られた教訓 - [Neueux.com](https://neueux.com/apps) - 多様なフィルタリングオプションを備えたユーザーフローのUIライブラリ -- [Web3ユーザビリティの危機：知っておくべきこととは](https://www.youtube.com/watch?v=oBSXT_6YDzg) - デベロッパー中心のプロジェクト構築の落とし穴に関するパネルディスカッション (34分のビデオ) +- [Web3のユーザビリティ危機: あなたが知るべきこと!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - デベロッパー中心のプロジェクト構築の落とし穴に関するパネルディスカッション (動画、34分) -## Web3デザインのケーススタディ {#design-case-studies} +## はじめに {#getting-started} -- [Deep Work Studio](https://deepwork.studio/case-studies/) -- [Crypto UXハンドブック](https://www.cryptouxhandbook.com/) -- [OpenSeaでのNFT販売方法](https://builtformars.com/case-studies/opensea) -- [ウォレットのUX分析: ウォレットをどのように展開させるべきか](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (20分間のビデオ) +- [Web3のヒューリスティック](/developers/docs/design-and-ux/heuristics-for-web3/) - Web3インターフェースデザインのための7つのヒューリスティック +- [DEXデザインのベストプラクティス](/developers/docs/design-and-ux/dex-design-best-practice/) - 分散型取引所を設計するためのガイド -## デザイン報奨金 {#bounties} +## Web3デザインケーススタディ {#design-case-studies} + +- [Deep Work Studio](https://www.deepwork.studio/case-studies) +- [OpenSeaでNFTを販売する](https://builtformars.com/case-studies/opensea) +- [ウォレットUXの徹底分析: ウォレットはどのように変わる必要があるか](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (動画、20分) + +## デザインバウンティ {#bounties} - [Dework](https://app.dework.xyz/bounties) - [Buildboxハッカソン](https://app.buidlbox.io/) - [ETHGlobalハッカソン](https://ethglobal.com/) -## DAOとコミュニティのデザイン {#design-daos-and-communities} +## デザインDAOとコミュニティ {#design-daos-and-communities} プロフェッショナルによるコミュニティ主導の組織に参加したり、デザイングループに参加して、他のメンバーとデザインについて話し合ったり、関連するトピックやトレンドについて研究したりしましょう。 - [Vectordao.com](https://vectordao.com/) - [Deepwork.studio](https://www.deepwork.studio/) -- [Designer-dao.xyz](https://www.designer-dao.xyz/) - [We3.co](https://we3.co/) - [Openux.xyz](https://openux.xyz/) -## デザインシステム {#design-systems} +## デザインシステムとその他のデザインリソース {#design-systems-and-resources} -- [オプティミズムデザイン](https://www.figma.com/@optimism) (Figma) +- [Optimismデザイン](https://www.figma.com/@optimism) (Figma) - [Ethereum.orgデザインシステム](https://www.figma.com/@ethdotorg) (Figma) - [Finity、Polygonによるデザインシステム](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) - [Klerosデザインシステム](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) @@ -81,4 +82,5 @@ lang: ja - [ENSデザインシステム](https://thorin.ens.domains/) - [Mirrorデザインシステム](https://degen-xyz.vercel.app/) -**このページに掲載されている記事の内容やプロジェクトを公式に推薦しているわけではありません**。情報提供のみを目的としています。 [掲載ポリシー](/contributing/design/adding-design-resources)の基準に基づいて、このページにリンクを追加しています。 プロジェクトおよび記事を追加したい場合は、[GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md)にあるこのページを編集してください。 +**このページに掲載されている記事やプロジェクトは、公式に推奨するものではなく**、情報提供のみを目的としています。 +このページへのリンクは、[掲載ポリシー](/contributing/design/adding-design-resources)の基準に基づいて追加しています。 プロジェクトや記事の追加をご希望の場合は、[GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md)でこのページを編集してください。 diff --git a/public/content/translations/ja/developers/docs/development-networks/index.md b/public/content/translations/ja/developers/docs/development-networks/index.md index 999f26a91f7..53ca4eab809 100644 --- a/public/content/translations/ja/developers/docs/development-networks/index.md +++ b/public/content/translations/ja/developers/docs/development-networks/index.md @@ -1,6 +1,6 @@ --- -title: 開発用ネットワーク -description: 開発用ネットワークとイーサリアムアプリケーションの構築に役立つツールの概要。 +title: "開発用ネットワーク" +description: "開発用ネットワークとイーサリアムアプリケーションの構築に役立つツールの概要。" lang: ja --- @@ -8,34 +8,34 @@ lang: ja ウェブ開発において自分のコンピュータ上でローカルサーバを実行する場合と同様に、開発用ネットワークを使用してローカルブロックチェーンのインスタンスを作成し、dappをテストできます。 このイーサリアムの開発用ネットワークには、パブリックテストネットワークと比較して反復処理を大幅に迅速化する機能があります (たとえば、テストネットフォーセットからETHを取得する必要がありません)。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -開発用ネットワークについて学ぶ前に、[イーサリアムスタック](/developers/docs/ethereum-stack/)と[イーサリアムネットワーク](/developers/docs/networks/)の基本を理解する必要があります。 +開発ネットワークについて学ぶ前に、[イーサリアムスタックの基本](/developers/docs/ethereum-stack/)と[イーサリアムネットワーク](/developers/docs/networks/)を理解しておく必要があります。 ## 開発用ネットワークとは {#what-is-a-development-network} 開発用ネットワークは、基本的にはローカル開発のために設計された専用のイーサリアムクライアント (イーサリアムの実装) です。 -**標準的なイーサリアムノードをローカルで実行してみましょう。** +**標準のイーサリアムノードをローカルで実行するだけでは不十分なのはなぜか？** -そのまま[ノードの実行](/developers/docs/nodes-and-clients/#running-your-own-node)に進むことも_可能_ですが、開発用ネットワークは開発用に構築されているため、多くの場合に以下のような便利な機能が搭載されています。 +[ノードを実行する](/developers/docs/nodes-and-clients/#running-your-own-node)ことも_可能_ですが、開発ネットワークは開発専用に作られているため、多くの場合、次のような便利な機能が搭載されています。 -- ローカルブロックチェーンにデータを確定的にシードする (ETH残高を持つアカウントなど) 機能 +- ローカルブロックチェーンへのデータの決定論的なシード（例：ETH残高を持つアカウント） - 受け取ったトランザクションごとに、順序どおり遅延なく即時にブロックを生成する機能 - デバッグとロギングの拡張機能 ## 利用可能なツール {#available-projects} -**注**: ほとんどの[開発フレームワーク](/developers/docs/frameworks/)には、組み込みの開発用ネットワークが含まれています。 フレームワークの[ローカル開発環境のセットアップ](/developers/local-environment/)から始めることをお勧めします。 +**注**：ほとんどの[開発フレームワーク](/developers/docs/frameworks/)には、組み込みの開発ネットワークが含まれています。 フレームワークを使って[ローカル開発環境をセットアップする](/developers/local-environment/)ことから始めることをお勧めします。 -### Hardhat Network {#hardhat-network} +### Hardhatネットワーク {#hardhat-network} 開発用に設計されたローカルイーサリアムネットワークです。 コントラクトのデプロイ、テストの実行、コードのデバッグを可能にします。 Hardhat Networkには、プロフェッショナルのためのイーサリアム開発環境であるHardhatが組み込まれています。 - [ウェブサイト](https://hardhat.org/) -- [GitHub](https://github.com/nomiclabs/hardhat) +- [GitHub](https://github.com/NomicFoundation/hardhat) ### ローカルビーコンチェーン {#local-beacon-chains} @@ -44,13 +44,11 @@ Hardhat Networkには、プロフェッショナルのためのイーサリア - [Lodestarを使用したローカルテストネット](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) - [Lighthouseを使用したローカルテストネット](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) -### 公開イーサリアムテストチェーン {#public-beacon-testchains} +### パブリックイーサリアムテストチェーン {#public-beacon-testchains} -また、イーサリアムにはSepoliaとHoodiという、2つの維持されている公開テスト環境の実装もあります。 Sepoliaは、アプリケーション開発のための推奨される標準テストネットで、高速な同期のための閉じたバリデータセットを持っています。 Hoodiは、検証とステーキングのためのテストネットで、オープンなバリデータセットを使用し、誰でも検証できる可能性があります。 +また、イーサリアムの維持されている2つのパブリックテスト実装もあります：SepoliaとHoodiです。 長期サポートが推奨されるテストネットはHoodiで、誰でも自由にバリデートできます。 Sepoliaは許可制のバリデーターセットを使用しており、このテストネット上では新しいバリデーターへの一般的なアクセスがありません。 -- [Hoodiステーキングランチパッド](https://hoodi.launchpad.ethereum.org/en/) -- [Sepoliaウェブサイト](https://sepolia.dev/) -- [Hoodiウェブサイト](https://hoodi.ethpandaops.io/) +- [Hoodiステーキングランチパッド](https://hoodi.launchpad.ethereum.org/) ### Kurtosisイーサリアムパッケージ {#kurtosis} @@ -63,11 +61,11 @@ Kurtosisは、マルチコンテナテスト環境のビルドシステムで、 - [GitHub](https://github.com/kurtosis-tech/kurtosis) - [ドキュメント](https://docs.kurtosis.com/) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} - [開発フレームワーク](/developers/docs/frameworks/) -- [ローカル開発環境のセットアップ](/developers/local-environment/) +- [ローカル開発環境をセットアップする](/developers/local-environment/) diff --git a/public/content/translations/ja/developers/docs/ethereum-stack/index.md b/public/content/translations/ja/developers/docs/ethereum-stack/index.md index 97fa1c45c95..2254a0f28b5 100644 --- a/public/content/translations/ja/developers/docs/ethereum-stack/index.md +++ b/public/content/translations/ja/developers/docs/ethereum-stack/index.md @@ -1,6 +1,6 @@ --- -title: イーサリアムスタック -description: さまざまなレイヤーのイーサリアムスタックとそれらの関係性 +title: "イーサリアムスタック" +description: "さまざまなレイヤーのイーサリアムスタックとそれらの関係性" lang: ja --- @@ -10,21 +10,21 @@ lang: ja ## レベル1: イーサリアム仮想マシン {#ethereum-virtual-machine} -[イーサリアム仮想マシン(EVM)](/developers/docs/evm/)は、イーサリアムのスマートコントラクトのランタイム環境です。 イーサリアムブロックチェーン上のすべてのスマートコントラクトと状態変更は、[トランザクション](/developers/docs/transactions/)によって実行されます。 全てのイーサリアムネットワーク上のトランザクションはEVMによって処理されます。 +[イーサリアム仮想マシン(EVM)](/developers/docs/evm/)は、イーサリアム上のスマートコントラクトのランタイム環境です。 イーサリアムブロックチェーン上のすべてのスマートコントラクトと状態変更は、[トランザクション](/developers/docs/transactions/)によって実行されます。 全てのイーサリアムネットワーク上のトランザクションはEVMによって処理されます。 他の仮想マシンと同様に、EVMは実行コードと実行マシン (イーサリアムノード) との間に抽象レベルを作成します。 現在、EVMは世界中に分散された数千のノードで動作しています。 -内部では、EVMは一連のオペコードを使用して特定のタスクを実行します。 これらの(140個のユニークな)オペコードにより、EVMを[チューリング完全](https://en.wikipedia.org/wiki/Turing_completeness)にすることができます。 つまり、EVMは十分なリソースがあれば何でも計算できるということです。 +内部では、EVMは一連のオペコードを使用して特定のタスクを実行します。 これら(140個のユニークな)オペコードにより、EVMは[チューリング完全](https://en.wikipedia.org/wiki/Turing_completeness)になることができます。つまり、EVMは十分なリソースがあれば、ほぼ何でも計算できるということです。 dappデベロッパーは、EVMについて詳しく知る必要はありません。イーサリアム上のすべてのアプリケーションをダウンタイムなしで確実に動作させている存在であることを理解していれば十分です。 ## レベル2: スマートコントラクト {#smart-contracts} -[スマートコントラクト](/developers/docs/smart-contracts/) は、イーサリアムブロックチェーン上で実行可能なプログラムです。 +[スマートコントラクト](/developers/docs/smart-contracts/)は、イーサリアムブロックチェーン上で実行されるプログラムです。 -スマートコントラクトは、EVMバイトコード(オペコードと呼ばれる低レベルの機械語)にコンパイルされる、特定の[プログラミング言語](/developers/docs/smart-contracts/languages/)を使用して記述されています。 +スマートコントラクトは、EVMバイトコード(オペコードと呼ばれる低レベルのマシン命令)にコンパイルされる、特定の[プログラミング言語](/developers/docs/smart-contracts/languages/)を使用して記述されます。 -スマートコントラクトは、オープンソースライブラリとして機能するだけではありません。本質的には、ダウンタイムなしで常時稼動しているオープンAPIサービスです。 スマートコントラクトは、ユーザーやアプリケーション ([dapp](/developers/docs/dapps/)) が許可を必要とせずにやり取りできるようにするパブリック機能を提供します。 どんなアプリケーションであっても、デプロイされたスマートコントラクトと統合することで、[データフィード](/developers/docs/oracles/)の追加などの機能の作成やトークンスワップのサポートが可能になります。 誰でも新しいスマートコントラクトをイーサリアムにデプロイして、アプリケーションのニーズを満たす独自の機能を追加できます。 +スマートコントラクトは、オープンソースライブラリとして機能するだけではありません。本質的には、ダウンタイムなしで常時稼動しているオープンAPIサービスです。 スマートコントラクトは、ユーザーやアプリケーション([dapps](/developers/docs/dapps/))が許可を必要とせずにやりとりできるパブリック関数を提供します。 どのようなアプリケーションでも、デプロイ済みのスマートコントラクトと統合して、[データフィード](/developers/docs/oracles/)の追加やトークンスワップのサポートなどの機能を構成できます。 誰でも新しいスマートコントラクトをイーサリアムにデプロイして、アプリケーションのニーズを満たす独自の機能を追加できます。 Dappデベロッパーは、イーサリアムブロックチェーンに独自の機能を追加したい場合にのみ、スマートコントラクトを記述する必要があります。 実際には、既存のスマートコントラクトとの統合でプロジェクトのほとんどのニーズを達成することができます。 たとえば、ステーブルコインで支払いをサポートしたい場合や、トークンの分散型取引を可能にしたい場合などです。 @@ -32,19 +32,19 @@ Dappデベロッパーは、イーサリアムブロックチェーンに独自 アプリケーションがイーサリアムブロックチェーンとやり取りするためには、[イーサリアムノード](/developers/docs/nodes-and-clients/)に接続する必要があります。 ノードに接続すると、ブロックチェーンデータの読み取りやネットワークへのトランザクションの送信が可能になります。 -イーサリアムノードは、ソフトウェアを実行しているコンピュータ、すなわちイーサリアムクライアントです。 クライアントはイーサリアムの実装であり、各ブロック内のすべてのトランザクションを検証し、ネットワークの安全性とデータの正確性を維持します。 **イーサリアムノードはイーサリアムブロックチェーン**です。 イーサリアムブロックチェーンの状態をまとめて保存し、ブロックチェーンの状態を変更するためのトランザクションについてコンセンサスを得ます。 +イーサリアムノードは、ソフトウェアを実行しているコンピュータ、すなわちイーサリアムクライアントです。 クライアントはイーサリアムの実装であり、各ブロック内のすべてのトランザクションを検証し、ネットワークの安全性とデータの正確性を維持します。 **イーサリアムノードはイーサリアムブロックチェーンそのものです**。 イーサリアムブロックチェーンの状態をまとめて保存し、ブロックチェーンの状態を変更するためのトランザクションについてコンセンサスを得ます。 -アプリケーションをイーサリアムノードに ([JSON-RPC API](/developers/docs/apis/json-rpc/)を介して) 接続することで、アプリはブロックチェーンからデータ (ユーザーアカウントの残高など) を読み取ることができ、また新しいトランザクションをネットワークにブロードキャストすることができます (ユーザーアカウント間でETHを送金したり、スマートコントラクトの機能を実行するなど) 。 +アプリケーションを([JSON-RPC API](/developers/docs/apis/json-rpc/)を介して)イーサリアムノードに接続することで、アプリケーションはブロックチェーンからデータ(ユーザーアカウントの残高など)を読み取ったり、新しいトランザクションをネットワークにブロードキャストしたり(ユーザーアカウント間でのETHの送金やスマートコントラクトの機能実行など)できます。 -## レベル 4: イーサリアムクライアントAPI {#ethereum-client-apis} +## レベル4: イーサリアムクライアントAPI {#ethereum-client-apis} 多くの便利なライブラリ (イーサリアムのオープンソースコミュニティによって構築および維持されている) を活用すると、アプリケーションがイーサリアムブロックチェーンに接続して通信できるようになります。 -ユーザー側のアプリケーションがウェブアプリの場合は、フロントエンドに直接、[JavaScript API](/developers/docs/apis/javascript/)を`npm install`できます。 あるいは、[Python](/developers/docs/programming-languages/python/)または[Java](/developers/docs/programming-languages/java/) APIを使用して、この機能をサーバー側に実装することも可能です。 +ユーザー向けのアプリケーションがWebアプリの場合、フロントエンドに直接[JavaScript API](/developers/docs/apis/javascript/)を`npm install`できます。 あるいは、[Python](/developers/docs/programming-languages/python/)や[Java](/developers/docs/programming-languages/java/)のAPIを使用して、この機能をサーバーサイドで実装することもできます。 これらのAPIは、イーサリアムスタックにとって必須ではありませんが、イーサリアムノードと直接やり取りする際の複雑さの多くを抽象化してくれます。 また、こうしたAPIでは、ユーティリティ関数 (ETHをGweiに変換する関数など) も提供されています。そのため、デベロッパーは複雑なイーサリアムクライアントの作業に費やす時間を削減でき、自身のアプリケーションの独自機能の開発作業に専念できます。 -## レベル 5: エンドユーザーアプリケーション {#end-user-applications} +## レベル5: エンドユーザーアプリケーション {#end-user-applications} スタックの最上位レベルには、ユーザー側のアプリケーションがあります。 これらは日常的に使用されている標準的なアプリケーションであり、主にウェブアプリとモバイルアプリです。 @@ -52,10 +52,10 @@ Dappデベロッパーは、イーサリアムブロックチェーンに独自 ## スタックを選ぶ準備ができたら {#ready-to-choose-your-stack} -イーサリアムアプリケーションのための[ローカル開発環境のセットアップ](/developers/local-environment/)ガイドをご覧ください。 +イーサリアムアプリケーションのための[ローカル開発環境をセットアップする](/developers/local-environment/)ガイドをご覧ください。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [Web 3.0 アプリケーションのアーキテクチャ](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ +- [Web 3.0アプリケーションのアーキテクチャ](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ -_役に立つコミュニティリソースをご存知の場合は、 このページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/evm/index.md b/public/content/translations/ja/developers/docs/evm/index.md index f6789ce1dd6..01522a49d01 100644 --- a/public/content/translations/ja/developers/docs/evm/index.md +++ b/public/content/translations/ja/developers/docs/evm/index.md @@ -1,76 +1,86 @@ --- -title: イーサリアム仮想マシン(EVM) -description: イーサリアム仮想マシンと状態、トランザクション、およびスマートコントラクトの関係性の説明 +title: "イーサリアム仮想マシン(EVM)" +description: "イーサリアム仮想マシンと状態、トランザクション、およびスマートコントラクトの関係性の説明" lang: ja --- -イーサリアム仮想マシン(EVM)は、分散型の仮想環境でイーサリアムノードのすべてにわたり一貫して安全にコードを実行します。 ノードでは、スマートコントラクトを実行するためにEVMが動作しており、「[ガス](/gas/)」を使用して[演算](/developers/docs/evm/opcodes/)に必要な計算量を測定します。これにより、効率的なリソースの割り当てとネットワークのセキュリティを確保しています。 +イーサリアム仮想マシン(EVM)は、分散型の仮想環境でイーサリアムノードのすべてにわたり一貫して安全にコードを実行します。 ノードはEVMを実行してスマートコントラクトを実行し、「[ガス](/developers/docs/gas/)」を使用して[オペレーション](/developers/docs/evm/opcodes/)に必要な計算量を測定することで、効率的なリソース割り当てとネットワークセキュリティを確保します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -EVMを理解するためには、[バイト](https://wikipedia.org/wiki/Byte)、[メモリ](https://wikipedia.org/wiki/Computer_memory)、[スタック](https://wikipedia.org/wiki/Stack_(abstract_data_type))など、コンピュータサイエンスの一般的な用語に関する基本知識が必要です。 また、暗号学やブロックチェーンの概念である[ハッシュ関数](https://wikipedia.org/wiki/Cryptographic_hash_function)、[マークルツリー](https://wikipedia.org/wiki/Merkle_tree)などを知っていると理解の手助けになります。 +EVMを理解するためには、[バイト](https://wikipedia.org/wiki/Byte)、[メモリ](https://wikipedia.org/wiki/Computer_memory)、[スタック](https://wikipedia.org/wiki/Stack_\(abstract_data_type\))といった、コンピューターサイエンスの一般的な用語に関する基本的な知識が必要です。 また、[ハッシュ関数](https://wikipedia.org/wiki/Cryptographic_hash_function)や[マークルツリー](https://wikipedia.org/wiki/Merkle_tree)のような暗号技術やブロックチェーンの概念を理解していると役立ちます。 ## 台帳から状態マシンへ {#from-ledger-to-state-machine} 「分散台帳」の例えは、ビットコインのようなブロックチェーンを説明する際によく使用され、暗号技術の基本的なツールを使用して分散型通貨を可能にするものです。 台帳はアクティビティの記録を維持し、アクティビティは台帳を変更する上で、誰かができること・できないことを定める一連の規則に従います。 例えば、あるビットコインアドレスで、以前に受け取ったビットコインよりも多くのビットコインを使用できません。 このルールは、ビットコインをはじめとする多くのブロックチェーンのすべてのトランザクションを支えるものです。 -イーサリアムには、ほぼ同様の直観的なルールに従うイーサリアムのネイティブ暗号通貨(イーサ)に加えて、[スマートコントラクト](/developers/docs/smart-contracts/)というさらに強力な機能があります。 この機能は複雑なため、説明にはより詳しい例が必要になります。 イーサリアムは分散台帳ではなく、分散型の[状態マシン](https://wikipedia.org/wiki/Finite-state_machine)です。 イーサリアムの状態とは、全アカウントとその残高を保持するだけでなく、予め定義されたルールに従ってブロックごとに変化し、任意のマシンコードを実行できる_マシンの状態_を保持する、巨大なデータ構造です。 ブロックごとの状態変化の具体的なルールは、EVMによって定義されています。 +イーサリアムには、ほぼ同じ直感的なルールに従う独自のネイティブ暗号通貨（イーサ）がありますが、さらに強力な機能である[スマートコントラクト](/developers/docs/smart-contracts/)も可能にしています。 この機能は複雑なため、説明にはより詳しい例が必要になります。 イーサリアムは分散台帳ではなく、分散[状態マシン](https://wikipedia.org/wiki/Finite-state_machine)です。 イーサリアムの状態は、すべてのアカウントと残高だけでなく、_マシン状態_も保持する巨大なデータ構造であり、事前に定義された一連のルールに従ってブロックからブロックへと変化し、任意のマシンコードを実行できます。 ブロックごとの状態変化の具体的なルールは、EVMによって定義されています。 -![EVMの構成図](./evm.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +![EVMの構成を示す図](./evm.png) +_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)より引用した図_ ## イーサリアムの状態遷移関数 {#the-ethereum-state-transition-function} -EVMは数学の関数のように動作し、入力に対して決定論的な出力が得られます。 そのため、イーサリアムを**状態遷移関数**を持つと正式に表現することもできます。 +EVMは数学の関数のように動作し、入力に対して決定論的な出力が得られます。 したがって、イーサリアムを**状態遷移関数**を持つものとして、より正式に記述すると非常に分かりやすくなります。 ``` Y(S, T)= S' ``` -古い有効な状態 `(S)`と新しい有効なトランザクションのセット`(T)` により、イーサリアムの状態遷移関数`Y(S, T)`は新しい有効な出力状態 `S'` を生成します。 +古い有効な状態`(S)`と新しい有効なトランザクションのセット`(T)`が与えられると、イーサリアムの状態遷移関数`Y(S, T)`は新しい有効な出力状態`S'`を生成します。 ### 状態 {#state} -イーサリアムにおける「状態」とは、[修正マークルパトリシアツリー](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)と呼ばれる巨大なデータ構造であり、ハッシュでリンクされたすべての[アカウント](/developers/docs/accounts/)を保持し、ブロックチェーンに保存されている単一のルートハッシュにまとめることができます。 +イーサリアムの文脈において、状態とは[修正マークルパトリシアツリー](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)と呼ばれる巨大なデータ構造であり、ハッシュによってリンクされたすべての[アカウント](/developers/docs/accounts/)を保持し、ブロックチェーンに格納された単一のルートハッシュに還元することができます。 ### トランザクション {#transactions} イーサリアムにおける「トランザクション」とは、アカウントから暗号的に署名された一連の指示です。 トランザクションには、メッセージの呼び出しが発生するものと、コントラクトの作成が発生するものの2種類があります。 -スマートコントラクトを作成すると、コンパイルされた[スマートコントラクト](/developers/docs/smart-contracts/anatomy/)バイトコードを含む、新規コントラクトアカウントが作られます。 他のアカウントがスマートコントラクトへメッセージの呼び出しを行うたびに、そのバイトコードが実行されます。 +コントラクトを作成すると、コンパイル済みの[スマートコントラクト](/developers/docs/smart-contracts/anatomy/)・バイトコードを含む新しいコントラクトアカウントが作成されます。 他のアカウントがスマートコントラクトへメッセージの呼び出しを行うたびに、そのバイトコードが実行されます。 -## EVM指示 {#evm-instructions} +## EVMの命令 {#evm-instructions} -EVMは1024項目を含む[スタックマシン](https://wikipedia.org/wiki/Stack_machine)として実行されます。 各項目は256ビットの単語で、これは256ビットの暗号(Keccak-256ハッシュやsecp256k1シグネチャなど)を使いやすいように選択されています。 +EVMは、深さ1024アイテムの[スタックマシン](https://wikipedia.org/wiki/Stack_machine)として実行されます。 各項目は256ビットの単語で、これは256ビットの暗号(Keccak-256ハッシュやsecp256k1シグネチャなど)を使いやすいように選択されています。 -実行中、EVMは一時的な_メモリ_(ワードアドレスによるバイト配列として)を持ちますが、これはトランザクション間には継続されません。 +実行中、EVMは一時的な_メモリ_（ワードアドレス指定バイト配列として）を維持しますが、トランザクションをまたいで永続化されることはありません。 -しかし、スマートコントラクトにはマークルパトリシア_ストレージ_のツリーが(ワードアドレス可能なワードアレイとして)含まれており、当該アカウントに関連付けられ、グローバルな状態の一部となっています。 +### 一時ストレージ -コンパイルされたスマートコントラクトのバイトコードは、`XOR`、`AND`、 `ADD`、 `SUB`のような標準的なスタック操作を行う多数のEVM[オペコード](/developers/docs/evm/opcodes)として実行されます。 また、EVMは`ADDRESS`、`BALANCE`、`BLOCKHASH`など、ブロックチェーン固有のスタック操作を多数実装しています。 +一時ストレージは、`TSTORE`および`TLOAD`オペコードを介してアクセスされる、トランザクションごとのキー・バリューストアです。 同一トランザクション中のすべての内部コールにわたって永続しますが、トランザクションの終了時にクリアされます。 メモリとは異なり、一時ストレージは実行フレームではなくEVM状態の一部としてモデル化されていますが、グローバル状態にはコミットされません。 一時ストレージは、トランザクション中の内部コール間でのガス効率の良い一時的な状態共有を可能にします。 -![EVMを実行にガスが必要な箇所を示す図](../gas/gas.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +### ストレージ + +コントラクトには、問題のアカウントに関連付けられ、グローバル状態の一部であるマークルパトリシア_ストレージ_ツリー（ワードアドレス指定のワード配列として）が含まれています。 この永続ストレージは、単一のトランザクションの期間中のみ利用可能で、アカウントの永続ストレージツリーの一部を形成しない一時ストレージとは異なります。 + +### オペコード + +コンパイルされたスマートコントラクトのバイトコードは、`XOR`、`AND`、`ADD`、`SUB`などの標準的なスタック操作を実行する多数のEVM[オペコード](/developers/docs/evm/opcodes)として実行されます。 またEVMは、`ADDRESS`、`BALANCE`、`BLOCKHASH`など、ブロックチェーンに固有のスタック操作も多数実装しています。 オペコードセットには、一時ストレージへのアクセスを提供する`TSTORE`と`TLOAD`も含まれます。 + +![EVMのオペレーションでガスが必要となる箇所を示す図](../gas/gas.png) +_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)より引用した図_ ## EVMの実装 {#evm-implementations} EVMのすべての実装は、イーサリアムイエローペーパーに記載されている仕様を遵守する必要があります。 -イーサリアムが誕生してから9年間にわたって、EVMは数多くの改訂を受け、様々なプログラミング言語で実装されてきました。 +イーサリアムの10年の歴史の中で、EVMは数度の改訂を経ており、様々なプログラミング言語によるEVMの実装が複数存在します。 -[イーサリアム実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)にはEVMの実装が含まれています。 また、次のようなスタンドアローンの実装も複数あります。 +[イーサリアム実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)には、EVMの実装が含まれています。 また、次のようなスタンドアローンの実装も複数あります。 - [Py-EVM](https://github.com/ethereum/py-evm) - _Python_ - [evmone](https://github.com/ethereum/evmone) - _C++_ - [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ - [revm](https://github.com/bluealloy/revm) - _Rust_ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムイエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf) -- [Jellopaper(別名: KEVM): KにおけるEVMのセマンティクス](https://jellopaper.org/) +- [イーサリアム・イエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Jellopaper(別名 KEVM): KにおけるEVMのセマンティクス](https://jellopaper.org/) - [The Beigepaper](https://github.com/chronaeon/beigepaper) -- [イーサリアム仮想マシンのオペコード](https://www.ethervm.io/) -- [イーサリアム仮想マシンオペコードのインタラクティブリファレンス](https://www.evm.codes/) -- [Solidityドキュメントの簡単な紹介](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) +- [イーサリアム仮想マシンオペコード](https://www.ethervm.io/) +- [イーサリアム仮想マシンオペコード・インタラクティブリファレンス](https://www.evm.codes/) +- [Solidityドキュメント内の簡単な紹介](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) - [マスタリング・イーサリアム - イーサリアム仮想マシン](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/evm/opcodes/index.md b/public/content/translations/ja/developers/docs/evm/opcodes/index.md index 0b03c54dedb..34dc8875531 100644 --- a/public/content/translations/ja/developers/docs/evm/opcodes/index.md +++ b/public/content/translations/ja/developers/docs/evm/opcodes/index.md @@ -1,174 +1,177 @@ --- -title: EVMのオペコード -description: イーサリアム仮想マシンで利用可能な全オペコードのリスト。 +title: "EVMのオペコード" +description: "イーサリアム仮想マシンで利用可能な全オペコードのリスト。" lang: ja --- ## 概要 {#overview} -[wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes)で公開されているEVMリファレンスページの最新版です。 [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)、[Jello Paper](https://jellopaper.org/evm/)、[geth](https://github.com/ethereum/go-ethereum)の実装からも引用されています。 わかりやすいリファレンスを目指していますが、とりわけ厳密なものではありません。 すべてのエッジケースを正確に把握したい場合は、Jello Paperまたはクライアント実装をご利用ください。 +これは[wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes)にあるEVMリファレンスページの更新版です。 +また、[Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)、[Jello Paper](https://jellopaper.org/evm/)、および[geth](https://github.com/ethereum/go-ethereum)の実装からも引用しています。 +わかりやすいリファレンスを目指していますが、とりわけ厳密なものではありません。 +すべてのエッジケースを正確に把握したい場合は、Jello Paperまたはクライアント実装をご利用ください。 -インタラクティブなリファレンスも用意されているので、 [evm.codes](https://www.evm.codes/)をご覧ください。 +インタラクティブなリファレンスも用意されているので、 [evm.codes](https://www.evm.codes/)をチェックしてみてください。 -ダイナミックなガス代の演算については、[gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md)を参照してください。 +動的なガス費用がかかるオペレーションについては、[gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md)を参照してください。 -💡 ヒント: 行全体を表示するには、 `[shift] + スクロール`を使用してデスクトップ上で水平方向にスクロールします。 +💡 ヒント: 行全体を表示するには、デスクトップで`[shift] + scroll`を使用して水平にスクロールしてください。 -| スタック | 名前 | ガス | 初期スタック | 結果スタック | Mem/ストレージ | 注記 | -|:-----:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 00 | STOP | 0 | | | | halt execution | -| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 | -| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 | -| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 | -| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division | -| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division | -| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus | -| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus | -| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N | -| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N | -| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 | -| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes | -| 0C-0F | _invalid_ | | | | | | -| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than | -| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than | -| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than | -| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than | -| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality | -| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | -| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND | -| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR | -| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR | -| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT | -| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left | -| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left | -| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right | -| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right | -| 1E-1F | _invalid_ | | | | | | -| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | -| 21-2F | _invalid_ | | | | | | -| 30 | ADDRESS | 2 | `。` | `address(this)` | | address of executing contract | -| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei | -| 32 | ORIGIN | 2 | `。` | `tx.origin` | | address that originated the tx | -| 33 | CALLER | 2 | `。` | `msg.sender` | | address of msg sender | -| 34 | CALLVALUE | 2 | `。` | `msg.value` | | msg value, in wei | -| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` | -| 36 | CALLDATASIZE | 2 | `。` | `len(msg.data)` | | length of msg data, in bytes | -| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data | -| 38 | CODESIZE | 2 | `。` | `len(this.code)` | | length of executing contract's code, in bytes | -| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode | -| 3A | GASPRICE | 2 | `。` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | -| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes | -| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` | -| 3D | RETURNDATASIZE | 2 | `。` | `size` | | size of returned data from last external call, in bytes | -| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call | -| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `ハッシュ` | | hash = addr.exists ? keccak256(addr.code) : 0 | -| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | -| 41 | COINBASE | 2 | `。` | `block.coinbase` | | 現在のブロックの提案者アドレス | -| 42 | TIMESTAMP | 2 | `。` | `block.timestamp` | | timestamp of current block | -| 43 | NUMBER | 2 | `。` | `block.number` | | number of current block | -| 44 | PREVRANDAO | 2 | `。` | `randomness beacon` | | randomness beacon | -| 45 | GASLIMIT | 2 | `。` | `block.gaslimit` | | gas limit of current block | -| 46 | CHAINID | 2 | `。` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack | -| 47 | SELFBALANCE | 5 | `。` | `address(this).balance` | | balance of executing contract, in wei | -| 48 | BASEFEE | 2 | `。` | `block.basefee` | | base fee of current block | -| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | -| 4A | BLOBBASEFEE | 2 | `。` | `block.blobbasefee` | | 現在のブロックのブロブベースフィー([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | -| 4B-4F | _invalid_ | | | | | | -| 50 | POP | 2 | `_anon` | `。` | | remove item from top of stack and discard it | -| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` | -| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `。` | mem[ost:ost+32] := val | write a word to memory | -| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `。` | mem[ost] := val && 0xFF | write a single byte to memory | -| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage | -| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `。` | storage[key] := val | write word to storage | -| 56 | JUMP | 8 | `dst` | `。` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest | -| 57 | JUMPI | 10 | `dst, condition` | `。` | | `$pc := condition ? dst : $pc + 1` | -| 58 | PC | 2 | `。` | `$pc` | | program counter | -| 59 | MSIZE | 2 | `。` | `len(mem)` | | size of memory in current execution context, in bytes | -| 5A | GAS | 2 | `。` | `gasRemaining` | | | -| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data | -| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | 一時ストレージからワードを読み込む([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5D | TSTORE | 100 | `key, val` | `。` | tstorage[key] := val | 一時ストレージへワードを書き込む ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `。` | mem[dstOst] := mem[ost:ost+len] | メモリをあるエリアから別のエリアへコピーする([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | -| 5E | PUSH0 | 2 | `。` | `uint8` | | スタックへ定数値0をプッシュ | -| 60 | PUSH1 | 3 | `。` | `uint8` | | push 1-byte value onto stack | -| 61 | PUSH2 | 3 | `。` | `uint16` | | push 2-byte value onto stack | -| 62 | PUSH3 | 3 | `。` | `uint24` | | push 3-byte value onto stack | -| 63 | PUSH4 | 3 | `。` | `uint32` | | push 4-byte value onto stack | -| 64 | PUSH5 | 3 | `。` | `uint40` | | push 5-byte value onto stack | -| 65 | PUSH6 | 3 | `。` | `uint48` | | push 6-byte value onto stack | -| 66 | PUSH7 | 3 | `。` | `uint56` | | push 7-byte value onto stack | -| 67 | PUSH8 | 3 | `。` | `uint64` | | push 8-byte value onto stack | -| 68 | PUSH9 | 3 | `。` | `uint72` | | push 9-byte value onto stack | -| 69 | PUSH10 | 3 | `。` | `uint80` | | push 10-byte value onto stack | -| 6A | PUSH11 | 3 | `。` | `uint88` | | push 11-byte value onto stack | -| 6B | PUSH12 | 3 | `。` | `uint96` | | push 12-byte value onto stack | -| 6C | PUSH13 | 3 | `。` | `uint104` | | push 13-byte value onto stack | -| 6D | PUSH14 | 3 | `。` | `uint112` | | push 14-byte value onto stack | -| 6E | PUSH15 | 3 | `。` | `uint120` | | push 15-byte value onto stack | -| 6F | PUSH16 | 3 | `。` | `uint128` | | push 16-byte value onto stack | -| 70 | PUSH17 | 3 | `。` | `uint136` | | push 17-byte value onto stack | -| 71 | PUSH18 | 3 | `。` | `uint144` | | push 18-byte value onto stack | -| 72 | PUSH19 | 3 | `。` | `uint152` | | push 19-byte value onto stack | -| 73 | PUSH20 | 3 | `。` | `uint160` | | push 20-byte value onto stack | -| 74 | PUSH21 | 3 | `。` | `uint168` | | push 21-byte value onto stack | -| 75 | PUSH22 | 3 | `。` | `uint176` | | push 22-byte value onto stack | -| 76 | PUSH23 | 3 | `。` | `uint184` | | push 23-byte value onto stack | -| 77 | PUSH24 | 3 | `。` | `uint192` | | push 24-byte value onto stack | -| 78 | PUSH25 | 3 | `。` | `uint200` | | push 25-byte value onto stack | -| 79 | PUSH26 | 3 | `。` | `uint208` | | push 26-byte value onto stack | -| 7A | PUSH27 | 3 | `。` | `uint216` | | push 27-byte value onto stack | -| 7B | PUSH28 | 3 | `。` | `uint224` | | push 28-byte value onto stack | -| 7C | PUSH29 | 3 | `。` | `uint232` | | push 29-byte value onto stack | -| 7D | PUSH30 | 3 | `。` | `uint240` | | push 30-byte value onto stack | -| 7E | PUSH31 | 3 | `。` | `uint248` | | push 31-byte value onto stack | -| 7F | PUSH32 | 3 | `。` | `uint256` | | push 32-byte value onto stack | -| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack | -| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack | -| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack | -| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack | -| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack | -| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack | -| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack | -| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack | -| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack | -| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack | -| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack | -| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack | -| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack | -| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack | -| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack | -| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack | -| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | -| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | -| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | -| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | -| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | -| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | -| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | -| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | -| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | -| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | -| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `。` | | LOG0(memory[ost:ost+len-1]) | -| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `。` | | LOG1(memory[ost:ost+len-1], topic0) | -| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `。` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | -| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `。` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | -| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `。` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | -| A5-EF | _invalid_ | | | | | | -| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | -| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value | -| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `。` | | return mem[ost:ost+len-1] | -| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | -| F6-F9 | _invalid_ | | | | | | -| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| FB-FC | _invalid_ | | | | | | -| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `。` | | revert(mem[ost:ost+len-1]) | -| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | -| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `。` | | すべてのETHを`addr`へ送信する。コントラクトが作成されたのと同じトランザクションで実行された場合、コントラクトは破壊されます。 | +| スタック | 名前 | ガス | 初期スタック | 結果スタック | Mem/ストレージ | 注記 | | +| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | +| 00 | STOP | 0 | | | | 実行を停止 | | +| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256の加算 (2\*\*256を法とする) | | +| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256の乗算 (2\*\*256を法とする) | | +| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256の減算 (2\*\*256を法とする) | | +| 04 | DIV | 5 | `a, b` | `a // b` | | uint256の除算 | | +| 05 | SDIV | 5 | `a, b` | `a // b` | | int256の除算 | | +| 06 | MOD | 5 | `a, b` | `a % b` | | uint256の剰余 | | +| 07 | SMOD | 5 | `a, b` | `a % b` | | int256の剰余 | | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256の加算 (Nを法とする) | | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256の乗算 (Nを法とする) | | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256のべき乗 (2\*\*256を法とする) | | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | (b+1)バイトから32バイトへの`x`の[符号拡張](https://wikipedia.org/wiki/Sign_extension) | | +| 0C-0F | _無効_ | | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256の比較 (小なり) | | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256の比較 (大なり) | | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256の比較 (小なり) | | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256の比較 (大なり) | | +| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256の比較 (等しい) | | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256がゼロかどうかの判定 | | +| 16 | AND | 3 | `a, b` | `a && b` | | ビット単位のAND | | +| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | ビット単位のOR | | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | ビット単位のXOR | | +| 19 | NOT | 3 | `a` | `~a` | | ビット単位のNOT | | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | (u)int256 `x`の`i`番目のバイト (左から) | | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | 左シフト | | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | 論理右シフト | | +| 1D | SAR | 3 | `shift, val` | `val >> shift` | | 算術右シフト | | +| 1E-1F | _無効_ | | | | | | | +| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | | +| 21-2F | _無効_ | | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | 実行中のコントラクトのアドレス | | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | 残高 (wei単位) | | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | トランザクションを開始したアドレス | | +| 33 | CALLER | 2 | `.` | `msg.sender` | | msg送信者のアドレス | | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msgの値 (wei単位) | | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | インデックス`idx`のmsgデータからワードを読み取る | | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | msgデータの長さ (バイト単位) | | +| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | msgデータのコピー | | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | 実行中のコントラクトのコードの長さ (バイト単位) | | +| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | 実行中のコントラクトのバイトコードをコピーする | +| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | トランザクションのガス価格、単位ガスあたりのwei [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | | +| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | `addr`にあるコードのサイズ (バイト単位) | | +| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | `addr`からコードをコピー | | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | 最後の外部呼び出しからの戻りデータのサイズ (バイト単位) | | +| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | 最後の外部呼び出しからの戻りデータをコピーする | | +| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `ハッシュ` | | ハッシュ = addr.exists ? keccak256(addr.code) : 0 | | +| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | | +| 41 | COINBASE | 2 | `.` | `block.coinbase` | | 現在のブロックの提案者アドレス | | +| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | 現在のブロックのタイムスタンプ | | +| 43 | NUMBER | 2 | `.` | `block.number` | | 現在のブロックの番号 | | +| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | ランダムネスビーコン | | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | 現在のブロックのガスリミット | | +| 46 | CHAINID | 2 | `.` | `chain_id` | | 現在の[チェーンID](https://eips.ethereum.org/EIPS/eip-155)をスタックにプッシュする | | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | 実行中のコントラクトの残高 (wei単位) | | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | 現在のブロックのベースフィー | | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | 現在のブロックのブロブベースフィー ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | | +| 4B-4F | _無効_ | | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | スタックの先頭からアイテムを削除して破棄する | | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | オフセット`ost`のメモリからワードを読み取る | | +| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | メモリにワードを書き込む | | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | メモリに1バイトを書き込む | | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | ストレージからワードを読み取る | | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | ストレージにワードを書き込む | | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` `dst`が有効なjumpdestの場合にのみ`pc`が割り当てられることを示す | | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1` | | +| 58 | PC | 2 | `.` | `$pc` | | プログラムカウンター | | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | 現在の実行コンテキストにおけるメモリのサイズ (バイト単位) | | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | | +| 5B | JUMPDEST | 1 | | | 有効なジャンプ先をマーク | 有効なジャンプ先。例えば、プッシュデータ内にないジャンプ先など | | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | 一時ストレージからワードを読み取る ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | 一時ストレージにワードを書き込む ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | ある領域から別の領域へメモリをコピーする ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | | +| 5E | PUSH0 | 2 | `.` | `uint8` | | スタックへ定数値0をプッシュ | | +| 60 | PUSH1 | 3 | `.` | `uint8` | | 1バイトの値をスタックにプッシュする | | +| 61 | PUSH2 | 3 | `.` | `uint16` | | 2バイトの値をスタックにプッシュする | | +| 62 | PUSH3 | 3 | `.` | `uint24` | | 3バイトの値をスタックにプッシュする | | +| 63 | PUSH4 | 3 | `.` | `uint32` | | 4バイトの値をスタックにプッシュする | | +| 64 | PUSH5 | 3 | `.` | `uint40` | | 5バイトの値をスタックにプッシュする | | +| 65 | PUSH6 | 3 | `.` | `uint48` | | 6バイトの値をスタックにプッシュする | | +| 66 | PUSH7 | 3 | `.` | `uint56` | | 7バイトの値をスタックにプッシュする | | +| 67 | PUSH8 | 3 | `.` | `uint64` | | 8バイトの値をスタックにプッシュする | | +| 68 | PUSH9 | 3 | `.` | `uint72` | | 9バイトの値をスタックにプッシュする | | +| 69 | PUSH10 | 3 | `.` | `uint80` | | 10バイトの値をスタックにプッシュする | | +| 6A | PUSH11 | 3 | `.` | `uint88` | | 11バイトの値をスタックにプッシュする | | +| 6B | PUSH12 | 3 | `.` | `uint96` | | 12バイトの値をスタックにプッシュする | | +| 6C | PUSH13 | 3 | `.` | `uint104` | | 13バイトの値をスタックにプッシュする | | +| 6D | PUSH14 | 3 | `.` | `uint112` | | 14バイトの値をスタックにプッシュする | | +| 6E | PUSH15 | 3 | `.` | `uint120` | | 15バイトの値をスタックにプッシュする | | +| 6F | PUSH16 | 3 | `.` | `uint128` | | 16バイトの値をスタックにプッシュする | | +| 70 | PUSH17 | 3 | `.` | `uint136` | | 17バイトの値をスタックにプッシュする | | +| 71 | PUSH18 | 3 | `.` | `uint144` | | 18バイトの値をスタックにプッシュする | | +| 72 | PUSH19 | 3 | `.` | `uint152` | | 19バイトの値をスタックにプッシュする | | +| 73 | PUSH20 | 3 | `.` | `uint160` | | 20バイトの値をスタックにプッシュする | | +| 74 | PUSH21 | 3 | `.` | `uint168` | | 21バイトの値をスタックにプッシュする | | +| 75 | PUSH22 | 3 | `.` | `uint176` | | 22バイトの値をスタックにプッシュする | | +| 76 | PUSH23 | 3 | `.` | `uint184` | | 23バイトの値をスタックにプッシュする | | +| 77 | PUSH24 | 3 | `.` | `uint192` | | 24バイトの値をスタックにプッシュする | | +| 78 | PUSH25 | 3 | `.` | `uint200` | | 25バイトの値をスタックにプッシュする | | +| 79 | PUSH26 | 3 | `.` | `uint208` | | 26バイトの値をスタックにプッシュする | | +| 7A | PUSH27 | 3 | `.` | `uint216` | | 27バイトの値をスタックにプッシュする | | +| 7B | PUSH28 | 3 | `.` | `uint224` | | 28バイトの値をスタックにプッシュする | | +| 7C | PUSH29 | 3 | `.` | `uint232` | | 29バイトの値をスタックにプッシュする | | +| 7D | PUSH30 | 3 | `.` | `uint240` | | 30バイトの値をスタックにプッシュする | | +| 7E | PUSH31 | 3 | `.` | `uint248` | | 31バイトの値をスタックにプッシュする | | +| 7F | PUSH32 | 3 | `.` | `uint256` | | 32バイトの値をスタックにプッシュする | | +| 80 | DUP1 | 3 | `a` | `a, a` | | スタック上の1番目の値を複製する | | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | スタック上の2番目の値を複製する | | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | スタック上の3番目の値を複製する | | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | スタック上の4番目の値を複製する | | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | スタック上の5番目の値を複製する | | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | スタック上の6番目の値を複製する | | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | スタック上の7番目の値を複製する | | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | スタック上の8番目の値を複製する | | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | スタック上の9番目の値を複製する | | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | スタック上の10番目の値を複製する | | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | スタック上の11番目の値を複製する | | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | スタック上の12番目の値を複製する | | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | スタック上の13番目の値を複製する | | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | スタック上の14番目の値を複製する | | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | スタック上の15番目の値を複製する | | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | スタック上の16番目の値を複製する | | +| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | | +| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | | +| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | | +| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | | +| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | | +| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | | +| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | | +| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | | +| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | | +| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | | +| A5-EF | _無効_ | | | | | | | +| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | | +| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `成功しました` | mem[retOst:retOst+retLen-1] := returndata | | | +| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `成功しました` | mem[retOst:retOst+retLen-1] = returndata | DELEGATECALLと同じですが、元のmsg.senderとmsg.valueは伝播しません | | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | mem[ost:ost+len-1]を返す | | +| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `成功しました` | mem[retOst:retOst+retLen-1] := returndata | | | +| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | | +| F6-F9 | _無効_ | | | | | | | +| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `成功しました` | mem[retOst:retOst+retLen-1] := returndata | | | +| FB-FC | _無効_ | | | | | | | +| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | | +| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | 指定された無効なオペコード - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | | +| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | すべてのETHを`addr`に送信します。コントラクトが作成されたのと同じトランザクションで実行された場合、そのコントラクトは破棄されます。 | | diff --git a/public/content/translations/ja/developers/docs/frameworks/index.md b/public/content/translations/ja/developers/docs/frameworks/index.md index d761d5d42e6..3018cf30898 100644 --- a/public/content/translations/ja/developers/docs/frameworks/index.md +++ b/public/content/translations/ja/developers/docs/frameworks/index.md @@ -1,141 +1,155 @@ --- -title: Dapp開発フレームワーク -description: フレームワークの利点を調査し、利用可能なオプションを比較します。 +title: "Dapp開発フレームワーク" +description: "フレームワークの利点を調査し、利用可能なオプションを比較します。" lang: ja --- ## フレームワーク入門 {#introduction-to-frameworks} -本格的なdappを構築するには、 さまざまな技術が必要になります。 ソフトウェアフレームワークには、必要な機能の多くが含まれています。 あるいは、好きなツールで作業できるように簡単なプラグインシステムが備わっています。 +本格的なdappを構築するには、 +さまざまな技術が必要になります。 ソフトウェアフレームワークには、必要な機能の多くが含まれています。 +あるいは、好きなツールで作業できるように簡単なプラグインシステムが備わっています。 フレームワークには、すぐに使用できる機能が数多く用意されています。例えば、以下のようなものです。 - ローカルブロックチェーンのインスタンスをスピンアップする機能 - スマートコントラクトをコンパイルしてテストするためのユーティリティ -- 同じプロジェクト/リポジトリ内でユーザー側のアプリケーションを構築するために使用できる、クライアント開発アドオン -- イーサリアムネットワーク(ローカルで実行されているインスタンスまたはイーサリアムのパブリックネットワーク)に接続し、コントラクトをデプロイするための設定 -- 分散型アプリケーションの配布 - IPFSなどのストレージオプションとの統合 +- ユーザー向けのアプリケーションを、同じプロジェクト/リポジトリ内で構築するための + クライアント開発アドオン。 +- Ethereumネットワークに接続しコントラクトをデプロイするための設定。 + ローカル実行インスタンス、またはEthereumの + パブリックネットワークのいずれかで使用。 +- 分散型アプリの配布 - IPFSなどのストレージ + オプションとの統合。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -フレームワークの使用を開始する前に、[dapp](/developers/docs/dapps/)と[イーサリアムスタック](/developers/docs/ethereum-stack/)の入門を最初に読むことをお勧めします。 +フレームワークを深く掘り下げる前に、まず[dapps](/developers/docs/dapps/)と[Ethereumスタック](/developers/docs/ethereum-stack/)の入門ガイドに目を通すことをお勧めします。 ## 利用可能なフレームワーク {#available-frameworks} -**Foundry -** **_Foundryは、イーサリアムアプリケーション開発のための、迅速でポータブルなモジュラー型ツールキットです。_** +**Foundry** - **_Foundryは、Ethereumアプリケーション開発のための、超高速でポータブルなモジュラーツールキットです_** -- [Foundryをインストールする](https://book.getfoundry.sh/) +- [Foundryのインストール](https://book.getfoundry.sh/) - [Foundryブック](https://book.getfoundry.sh/) -- [テレグラムのFoundryコミュニティチャット](https://t.me/foundry_support) +- [Foundryコミュニティチャット (Telegram)](https://t.me/foundry_support) - [Awesome Foundry](https://github.com/crisgarner/awesome-foundry) -**Hardhat -** **_プロフェッショナルのためのイーサリアム開発環境_** +**Hardhat -** **_プロフェッショナル向けのEthereum開発環境。_** - [hardhat.org](https://hardhat.org) - [GitHub](https://github.com/nomiclabs/hardhat) -**Ape -** **_パイソニスタ、データサイエンティスト、セキュリティプロフェッショナル向けのスマートコントラクト開発ツール_** +**Ape -** **_Pythonista、データサイエンティスト、セキュリティプロフェッショナル向けのスマートコントラクト開発ツール。_** - [ドキュメント](https://docs.apeworx.io/ape/stable/) - [GitHub](https://github.com/ApeWorX/ape) -**Web3j -** **_JVM上でブロックチェーンアプリケーションを開発するためのプラットフォーム_** +**Web3j -** **_JVM上でブロックチェーンアプリケーションを開発するためのプラットフォーム。_** - [ホームページ](https://www.web3labs.com/web3j-sdk) - [ドキュメント](https://docs.web3j.io) - [GitHub](https://github.com/web3j/web3j) -**ethers-kt -** **_EVMベースのブロックチェーン用の非同期、ハイパフォーマンスのKotlin/Java/Androidライブラリ_** +**ethers-kt -** **_EVMベースのブロックチェーン向けの、非同期で高性能なKotlin/Java/Androidライブラリ。_** - [GitHub](https://github.com/Kr1ptal/ethers-kt) -- [実例：](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [サンプル](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) - [Discord](https://discord.gg/rx35NzQGSb) -**Create Eth App -** **_単一のコマンドで、イーサリアムで稼動するアプリケーションを作成可能。 豊富な選択肢を提供するUIフレームワークとDeFiテンプレートが付属。_** +**Create Eth App -** **_単一のコマンドでEthereumを利用したアプリを作成。 豊富なUIフレームワークとDeFiテンプレートから選択できます。_** - [GitHub](https://github.com/paulrberg/create-eth-app) - [テンプレート](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) -**Scaffold-Eth -** **_Scaffold-Eth - Ethers.js + Hardhat + React components and hooks for web3: スマートコントラクトを利用した分散型アプリケーションの構築を始めるために必要なすべてを網羅。_** +**Scaffold-Eth -** **_Ethers.js + Hardhat + web3用Reactコンポーネントとフック：スマートコントラクトを搭載した分散型アプリケーションの構築を始めるために必要なすべてが揃っています。_** - [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -**Tenderly -** **_ブロックチェーンデベロッパーがスマートコントラクトを構築、テスト、デバッグ、監視、操作し、dApp UXを改善できるWeb3開発プラットフォーム。_** +**Tenderly -** **_ブロックチェーンデベロッパーがスマートコントラクトの構築、テスト、デバッグ、監視、運用を行い、dappのUXを向上させることを可能にするWeb3開発プラットフォーム。_** - [ウェブサイト](https://tenderly.co/) - [ドキュメント](https://docs.tenderly.co/) -**The Graph -** **_ブロックチェーンデータのクエリを効率化。_** +**The Graph -** **_ブロックチェーンデータを効率的にクエリするためのThe Graph。_** - [ウェブサイト](https://thegraph.com/) - [チュートリアル](/developers/tutorials/the-graph-fixing-web3-data-querying/) -**Alchemy -** **_イーサリアム開発プラットフォーム_** +**Alchemy -** **_Ethereum開発プラットフォーム。_** - [alchemy.com](https://www.alchemy.com/) - [GitHub](https://github.com/alchemyplatform) - [Discord](https://discord.com/invite/alchemyplatform) -**NodeReal -** **_イーサリアム開発プラットフォーム。_** +**NodeReal -** **_Ethereum開発プラットフォーム。_** - [Nodereal.io](https://nodereal.io/) - [GitHub](https://github.com/node-real) - [Discord](https://discord.gg/V5k5gsuE) -**サードウェブSDK -** **_強力なSDKとCLIを使ってスマートコントラクトとやり取りするWeb3アプリケーションを構築。_** +**thirdweb SDK -** **_強力なSDKとCLIを使用して、スマートコントラクトと対話できるweb3アプリケーションを構築します。_** - [ドキュメント](https://portal.thirdweb.com/sdk/) - [GitHub](https://github.com/thirdweb-dev/) -**Chainstack -** **_Web3(イーサリアム他)開発プラットフォーム。_** +**Chainstack -** **_Web3 (Ethereumなど) 開発プラットフォーム。_** - [chainstack.com](https://www.chainstack.com/) - [GitHub](https://github.com/chainstack) - [Discord](https://discord.gg/BSb5zfp9AT) -**Crossmint -** **_エンタープライズグレードのweb3開発プラットで、すべての主要なEVMチェーン(および他のチェーン)でNFTアプリケーションをビルドすることができます。_** +**Crossmint -** **_エンタープライズグレードのweb3開発プラットフォームで、すべての主要なEVMチェーン (およびその他) でNFTアプリケーションを構築できます。_** - [ウェブサイト](https://www.crossmint.com) - [ドキュメント](https://docs.crossmint.com) - [Discord](https://discord.com/invite/crossmint) -**Brownie -** **_Pythonベースの開発環境とテストフレームワーク。_** +**Brownie -** **_Pythonベースの開発環境およびテストフレームワーク。_** - [ドキュメント](https://eth-brownie.readthedocs.io/en/latest/) - [GitHub](https://github.com/eth-brownie/brownie) - **Brownieのメンテナンス終了** -**OpenZeppelin SDK -** **_究極のスマートコントラクトツールキット。スマートコントラクトの開発、コンパイル、アップグレード、デプロイ、インタラクションを支援するツール群。_** +**OpenZeppelin SDK -** **_究極のスマートコントラクトツールキット：スマートコントラクトの開発、コンパイル、アップグレード、デプロイ、操作を支援する一連のツール。_** -- [OpenZeppelin SDK](https://openzeppelin.com/sdk/) +- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk) - [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) - [コミュニティフォーラム](https://forum.openzeppelin.com/c/support/17) - **OpenZeppelin SDK開発の終了** -**Catapulta -** **_マルチチェーン・スマートコントラクト・デプロイメントツール、ブロックエクスプローラでの自動検証、デプロイしたスマートコントラクトの追跡、デプロイメントレポートの共有、FoundryやHardhatのプラグ・アンド・プレイ。_** +**Catapulta -** **_マルチチェーンのスマートコントラクトデプロイツール。ブロックエクスプローラーでの検証の自動化、デプロイ済みスマートコントラクトの追跡、デプロイレポートの共有、FoundryおよびHardhatプロジェクトへのプラグアンドプレイに対応。_** - [ウェブサイト](https://catapulta.sh/) - [ドキュメント](https://catapulta.sh/docs) - [GitHub](https://github.com/catapulta-sh) -**Covalent -** **_200以上のチェーンで使えるリッチなブロックチェーンAPI_** +**GoldRush (powered by Covalent) -** **_GoldRushは、デベロッパー、アナリスト、企業向けに、最も包括的なブロックチェーンデータAPIスイートを提供します。 DeFiダッシュボード、ウォレット、取引ボット、AIエージェント、コンプライアンスプラットフォームのいずれを構築している場合でも、データAPIは、必要不可欠なオンチェーンデータへの高速で正確、かつデベロッパーフレンドリーなアクセスを提供します_** -- [covalenthq.com](https://www.covalenthq.com/) -- [ドキュメント](https://www.covalenthq.com/docs/api/) +- [ウェブサイト](https://goldrush.dev/) +- [ドキュメント](https://goldrush.dev/docs/chains/ethereum) - [GitHub](https://github.com/covalenthq) - [Discord](https://www.covalenthq.com/discord/) -**Wake -** **_コントラクトのテスト、ファジング、デプロイ、脆弱性スキャン、コードナビゲーションが可能なオールインワンPythonフレームワーク。_** +**Wake -** **_コントラクトのテスト、ファジング、デプロイ、脆弱性スキャン、コードナビゲーションのためのオールインワンPythonフレームワーク。_** - [ホームページ](https://getwake.io/) - [ドキュメント](https://ackeeblockchain.com/wake/docs/latest/) - [GitHub](https://github.com/Ackee-Blockchain/wake) -- [VS Codeエクステンション](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) +- [VS Code拡張機能](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) -## 参考文献 {#further-reading} +**Veramo -** **_分散型アプリケーションのデベロッパーが、分散型アイデンティティと検証可能なクレデンシャルをアプリケーションに簡単に組み込むことができる、オープンソースでモジュール式の、特定のテクノロジーに依存しないフレームワーク。_** -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +- [ホームページ](https://veramo.io/) +- [ドキュメント](https://veramo.io/docs/basics/introduction) +- [GitHub](https://github.com/uport-project/veramo) +- [Discord](https://discord.com/invite/FRRBdjemHV) +- [NPMパッケージ](https://www.npmjs.com/package/@veramo/core) + +## 参考リンク {#further-reading} + +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} -- [ローカル開発環境のセットアップ](/developers/local-environment/) +- [ローカル開発環境をセットアップする](/developers/local-environment/) diff --git a/public/content/translations/ja/developers/docs/gas/index.md b/public/content/translations/ja/developers/docs/gas/index.md index a56f31e1c80..7f6b35c74c9 100644 --- a/public/content/translations/ja/developers/docs/gas/index.md +++ b/public/content/translations/ja/developers/docs/gas/index.md @@ -1,14 +1,15 @@ --- -title: ガスとフィー(手数料) -description: +title: "ガスとフィー(手数料)" +metaTitle: "イーサリアムのガスと手数料：技術概要" +description: "イーサリアムのガス手数料、その計算方法、そしてネットワークのセキュリティとトランザクション処理における役割について学びます。" lang: ja --- イーサリアムネットワークにとってガスは切り離せないものです。 ガスは車にとってのガソリンのようにイーサリアムを稼働させるための燃料として使われます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをよく理解するためには、まず[トランザクション](/developers/docs/transactions/)、[EVM](/developers/docs/evm/)を読むことをお勧めします。 +このページをよりよく理解するために、まず[トランザクション](/developers/docs/transactions/)と[EVM](/developers/docs/evm/)についてお読みになることをお勧めします。 ## ガスとは {#what-is-gas} @@ -16,25 +17,26 @@ lang: ja イーサリアムでは、トランザクションを実行するには計算リソースが必要です。そのため、そのリソースの対価として料金を支払う必要があります。これにより、イーサリアムはスパム攻撃に対する脆弱性を解消し、無限の計算ループに陥ることを防ぎます。 計算料金は、ガス代として支払われます。 -ガス代は、**操作のガス使用量に、ガス単位当たりのコストを乗じた額**です。 この料金は、トランザクションが成功したか失敗したかに関係なく支払われます。 +ガス手数料とは、**ある操作を行うために使用されるガスの量に、ガス単位あたりのコストを乗じたもの**です。 この料金は、トランザクションが成功したか失敗したかに関係なく支払われます。 -![EVMを実行する際にガスが必要な箇所を示す図](./gas.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +![EVMの操作でガスが必要となる場所を示す図](./gas.png) +_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)を参考に作成_ 実際にはガス代はイーサリアムのネイティブ通貨であるイーサ(ETH)で支払う必要があります。 ガス価格は通常、ETHの単位の1つであるgweiで見積もられます。 gweiは、ETHの10億分の1(0.000000001 ETHすなわち10-9 ETH)に相当します。 例えば、0.000000001 ETHのガス代は、1 gweiとなります。 -「gwai」とは、「10億wei」を意味する「giga-wei」の略語であり、 1 gweiは、10億weiに相当します。 weiは[b-money](https://www.investopedia.com/terms/b/bmoney.asp)の創始者である[Wei Dai](https://wikipedia.org/wiki/Wei_Dai)氏にちなんで名付けられ、ETHの最小単位です。 +「gwai」とは、「10億wei」を意味する「giga-wei」の略語であり、 1 gweiは、10億weiに相当します。 Wei自体([b-money](https://www.investopedia.com/terms/b/bmoney.asp)の作成者である[Wei Dai](https://wikipedia.org/wiki/Wei_Dai)にちなんで名付けられました)は、ETHの最小単位です。 ## ガス代の計算方法 {#how-are-gas-fees-calculated} ガス量を設定してトランザクションを送信できます。 ガス量をいくらか支払うことで、次のブロックに含まれるトランザクションに入札することになります。 ガス量が少なすぎると、バリデータがトランザクションを処理する可能性が低くなります。つまり、トランザクションが遅れて実行されたり、まったく実行されなかったりすることがあります。 一方で、ガス量が多すぎると、ETHを無駄にすることになります。 それでは、どのようにして適切なガス代を決めればよいのでしょうか。その方法について説明します。 -支払うガス代の合計は、`base fee`と`priority fee`(チップ) の2つのコンポーネントに分けられます。 +支払うガスの総額は、`base fee`と`priority fee`(チップ)の2つの要素に分かれています。 -`base fee`は、プロトコルで定められています。トランザクションを有効にするには、必ずこの手数料を支払う必要があります。 `priority fee`は、ベースフィーに追加して支払うチップです。この手数料を支払うことで、バリデータにとって、あなたのトランザクションが魅力的になり、次のブロックに選ばれるようになります。 +`base fee`はプロトコルによって設定されます。トランザクションが有効とみなされるためには、少なくともこの金額を支払う必要があります。 `priority fee`は、バリデータが次のブロックに含めるトランザクションとして選択するよう、トランザクションを魅力的にするために`base fee`に追加するチップです。 -トランザクションにおいて`base fee`のみを支払うことは、技術的には有効であるものの、バリデータにとって他のトランザクションよりも優先させるインセンティブがなく、そのトランザクションが選ばれる可能性は低くなります。 「正確な」`priority fee`は、トランザクション送信時のネットワーク使用状況で決定します。需要が高い場合は、`priority fee`を高めに設定する必要があります。需要が低い場合は、より安く設定できます。 +`base fee`のみを支払うトランザクションは技術的には有効ですが、バリデータが他のトランザクションよりも優先して選択するインセンティブがないため、ブロックに含まれる可能性は低いです。 「適切な」`priority fee`は、トランザクションを送信する時点でのネットワークの使用状況によって決まります。需要が多い場合は`priority fee`を高く設定する必要があるかもしれませんが、需要が少ない場合はより低い料金で済みます。 例えば、JordanがTaylorに1 ETHを支払わなければならない場合、 ガス単位で21,000が必要になります。基本料金は10 gweiですが、 Jordanはチップとして2 gweiを追加します。 @@ -42,54 +44,58 @@ lang: ja `使用されるガス単位 × (ベースフィー + プライオリティフィー)` -この式の`base fee`は、プロトコルで設定された値です。また、`priority fee`は、バリデータへのチップとしてユーザーが設定した値です。 +ここで、`base fee`はプロトコルによって設定される値で、`priority fee`はユーザーがバリデータへのチップとして設定する値です。 -つまり、`21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH) +例: `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH)。 -Jordanが送金すると、Jordanの口座から1.000252 ETHが差し引かれ、 Tayloの口座に1.0000ETHが入金されます。 また、バリデータには0.000042 ETHのチップが支払われ、 `base fee`である0.00021ETHはバーンされます。 +Jordanが送金すると、Jordanの口座から1.000252 ETHが差し引かれ、 Tayloの口座に1.0000ETHが入金されます。 また、バリデータには0.000042 ETHのチップが支払われ、 0.00021 ETHの`base fee`はバーンされます。 ### ベースフィー {#base-fee} -ブロックごとに、最低価格となるベースフィーが設定されています。 トランザクションをブロックに含めるには、ガスあたりの提供価格がベースフィー以上である必要があります。 ベースフィーは、現在のブロックとは別個に計算され、前のブロックによって決定されます。これにより、おおよそのトランザクションフィーを予測できます。 ブロックが作成されると、この**ベースフィーは「バーン」され**、流通から削除されます。 +ブロックごとに、最低価格となるベースフィーが設定されています。 トランザクションをブロックに含めるには、ガスあたりの提供価格がベースフィー以上である必要があります。 ベースフィーは現在のブロックとは無関係に計算され、その前のブロックによって決定されるため、ユーザーはトランザクション手数料をより予測しやすくなります。 ブロックが作成されると、この**ベースフィーは「バーン」**され、流通から削除されます。 -ベースフィーは、前のブロックのサイズ(すべてのトランザクションに使用されるガスの量)とターゲットサイズを比較して計算されます。 ターゲットブロックサイズを超えると、ベースフィーは1ブロックあたり最大12.5%増加します。 この指数的な増加により、ブロックサイズを無制限に高くすることは、経済的に不可能になります。 +ベースフィーは、前のブロックのサイズ(すべてのトランザクションに使用されたガスの量)をターゲットサイズ(ガスリミットの半分)と比較する数式によって計算されます。 ターゲットブロックサイズがターゲットを上回るか下回るかによって、ベースフィーはブロックごとに最大12.5%増減します。 この指数的な増加により、ブロックサイズを無制限に高くすることは、経済的に不可能になります。 -| ブロック数 | 含有ガス | 増加されるフィー | 現在のベースフィー | -| ----- | ----:| --------:| ----------:| -| 1 | 15M | 0% | 100 gwei | -| 2 | 30M | 0% | 100 gwei | -| 3 | 30M | 12.5% | 112.5 gwei | -| 4 | 30M | 12.5% | 126.6 gwei | -| 5 | 30M | 12.5% | 142.4 gwei | -| 6 | 30M | 12.5% | 160.2 gwei | -| 7 | 30M | 12.5% | 180.2 gwei | -| 8 | 30M | 12.5% | 202.7 gwei | +| ブロック数 | 含有ガス | 増加されるフィー | 現在のベースフィー | +| ----- | ---: | --------------------: | -------------------------: | +| 1 | 18M | 0% | 100 gwei | +| 2 | 36M | 0% | 100 gwei | +| 3 | 36M | 12.5% | 112.5 gwei | +| 4 | 36M | 12.5% | 126.6 gwei | +| 5 | 36M | 12.5% | 142.4 gwei | +| 6 | 36M | 12.5% | 160.2 gwei | +| 7 | 36M | 12.5% | 180.2 gwei | +| 8 | 36M | 12.5% | 202.7 gwei | -上の表によると、ブロック数9のトランザクションを行う場合、次のブロックに追加される**最大ベースフィー**は、`current base fee * 112.5%`、つまり`202.7 gwei * 112.5% = 228.1 gwei`となります。この情報がウォレットからユーザーに通知されます。 +上の表では、ガスリミットとして3,600万を使用した例が示されています。 この例に従い、ブロック番号9でトランザクションを作成する場合、ウォレットはユーザーに対し、次のブロックに追加される**最大ベースフィー**が `現在のベースフィー * 112.5%` または `202.7 gwei * 112.5% = 228.1 gwei` であることを確実に通知します。 また、フルブロックの状態になるとベースフィーの上昇速度が上がるため、フルブロックのスパイクが長続きしないことにも注意が必要です。 -| ブロック数 | 含有ガス | 増加されるフィー | 現在のベースフィー | -| ----- | ----:| --------:| ---------------:| -| 30 | 30M | 12.5% | 2705.6 gwei | -| ... | ... | 12.5% | ... | -| 50 | 30M | 12.5% | 28531.3 gwei | -| ... | ... | 12.5% | ... | -| 100 | 30M | 12.5% | 10302608.6 gwei | +| ブロック数 | 含有ガス | 増加されるフィー | 現在のベースフィー | +| --------------------------------------------------- | --------------------------------------------------: | --------------------: | --------------------------------------------------: | +| 30 | 36M | 12.5% | 2705.6 gwei | +| ... | ... | 12.5% | ... | +| 50 | 36M | 12.5% | 28531.3 gwei | +| ... | ... | 12.5% | ... | +| 100 | 36M | 12.5% | 10302608.6 gwei | -### プライオリティフィー(チップ) {#priority-fee} +### 優先手数料(チップ) {#priority-fee} -バリデータは、プライオリティフィー(チップ)を受け取ることで、ブロック内にトランザクションを含めるインセンティブを得ます。 チップがなければ、空のブロックをマイニングした方が、同じブロック報酬を得られるので経済的に有利となります。 チップが少ないと、バリデータにとってトランザクションを含めるインセンティブは小さくなります。 そのため、競合するトランザクションよりも高いチップを支払うことで、同じブロック内の他のトランザクションよりも優先的にトランザクションが実行されるようになります。 +優先手数料(チップ)は、ブロックガスリミットによってのみ制約されるブロック内のトランザクション数を最大化するよう、バリデータにインセンティブを与えます。 チップがなければ、合理的なバリデータは、実行レイヤーやコンセンサスレイヤーからの直接的なペナルティなしに、より少ない、あるいはゼロのトランザクションを含めることができます。これは、ステーキング報酬がブロック内のトランザクション数に依存しないためです。 さらに、チップにより、ユーザーは同じブロック内での優先権を他者より高く入札することができ、事実上の緊急性を示すことができます。 -### 最大フィー {#maxfee} +### 最大手数料 {#maxfee} -ネットワーク上でトランザクションを実行する場合、ユーザーはトランザクション実行に支払うフィーの上限を指定できます。 このオプションのパラメータは、`maxFeePerGas`として知られています。 トランザクションを実行するには、最大フィーがベースフィーとチップの合計額を上回る必要があります。 トランザクションの送信者には、最大フィーからベースフィーとチップの合計額を差し引いた差額が返金されます。 +ネットワーク上でトランザクションを実行する場合、ユーザーはトランザクション実行に支払うフィーの上限を指定できます。 このオプションパラメータは`maxFeePerGas`として知られています。 トランザクションを実行するには、最大フィーがベースフィーとチップの合計額を上回る必要があります。 トランザクションの送信者には、最大フィーからベースフィーとチップの合計額を差し引いた差額が返金されます。 ### ブロックサイズ {#block-size} -各ブロックの目標サイズは3,000万ガスですが、ブロックの上限である6,000万ガス(目標ブロックサイズの2倍)までは、ネットワークの需要に応じてブロックのサイズが増減します。 このプロトコルは、 _tâtonnement_のプロセスを通じて平均1,500万の平衡ブロックサイズを実現します。 つまり、ブロックサイズがターゲットブロックサイズよりも大きい場合、プロトコルは次のブロックのベースフィーを増加させます。 同様に、ブロックサイズがターゲットブロックサイズより小さい場合、プロトコルはベースフィーを減らします。 ベースフィーが調整される金額は、現在のブロックサイズとターゲットまでの差に比例します。 [ブロックの詳細](/developers/docs/blocks/) +各ブロックは現在のガスリミットの半分のターゲットサイズを持ちますが、ブロックのサイズはネットワークの需要に応じて、ブロックリミット(ターゲットブロックサイズの2倍)に達するまで増減します。 プロトコルは、_tâtonnement_ (手探り)のプロセスを通じて、ターゲットで平均ブロックサイズの均衡を達成します。 つまり、ブロックサイズがターゲットブロックサイズよりも大きい場合、プロトコルは次のブロックのベースフィーを増加させます。 同様に、ブロックサイズがターゲットブロックサイズより小さい場合、プロトコルはベースフィーを減らします。 -### ガス代を実際に計算する {#calculating-fees-in-practice} +ベースフィーが調整される金額は、現在のブロックサイズとターゲットまでの差に比例します。 これは、空のブロックで-12.5%、ターゲットサイズで0%、ガスリミットに達したブロックで最大+12.5%という線形計算です。 ガスリミットは、バリデータのシグナリングやネットワークのアップグレードによって、時間とともに変動する可能性があります。 ガスリミットの経時的な変化は[こちらで確認できます](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths)。 + +[ブロックについての詳細](/developers/docs/blocks/) + +### ガス手数料を実際に計算する {#calculating-fees-in-practice} トランザクションを実行するために支払う金額を具体的に指定できますが、 ほとんどのウォレットプロバイダーは、ユーザーへの負担を軽減するため、推奨トランザクションフィー(ベースフィー + 推奨プライオリティフィー)を自動で計算しています。 @@ -97,42 +103,49 @@ Jordanが送金すると、Jordanの口座から1.000252 ETHが差し引かれ 簡単に説明すると、ガス代はイーサリアムネットワークを安全に保つのに役立ちます。 ネットワーク上のそれぞれの計算処理に手数料を課すことで、ネットワークに対する攻撃を防止します。 コード内の偶発的または敵対的な無限ループ、またはその他の過剰計算による損失を防ぐために、 各トランザクションはコード実行の計算ステップ数(1トランザクションにおける計算量)を制限する必要があります。 計算の基本単位は「ガス」になります。 -トランザクションには制限がありますが、トランザクションで使用されなかったガスはユーザーに返却されます(例: `max fee - (base fee + tip)`が返金)。 +トランザクションには上限が含まれますが、トランザクションで使用されなかったガスはユーザーに返還されます(例: `max fee - (base fee + tip)`が返還)。 -![未使用ガスの返金図](../transactions/gas-tx.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +![未使用のガスがどのように返金されるかを示す図](../transactions/gas-tx.png) +_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)を参考に作成_ ## ガスリミットとは {#what-is-gas-limit} -ガスリミットとは、1回のトランザクションで消費できるガスの最大量のことです。 [スマートコントラクト](/developers/docs/smart-contracts/)を含む複雑なトランザクションでは、単純な支払いよりもより多くの計算作業が必要なため、高いガスリミットを必要とします。 標準のETH送金には、21,000ユニットのガスリミットが必要です。 +ガスリミットとは、1回のトランザクションで消費できるガスの最大量のことです。 [スマートコントラクト](/developers/docs/smart-contracts/)を伴うより複雑なトランザクションは、より多くの計算作業を必要とするため、単純な支払いよりも高いガスリミットが必要です。 標準のETH送金には、21,000ユニットのガスリミットが必要です。 -例えば、簡単なETH送金に50,000のガスリミットを設定した場合、EVMは21,000を消費し、残りの29,000が戻されます。 ただしETH送金に、例えば20,000など少なすぎるガスリミットを指定すると、EVMはトランザクションを満たそうとして20,000のガスユニットを消費しますが、完了はしません。 EVMは変更を元に戻しますが、バリデータがすでに20,000ガスユニット分の作業を実施済みのため、その分のガスは消費されます。 +例えば、簡単なETH送金に50,000のガスリミットを設定した場合、EVMは21,000を消費し、残りの29,000が戻されます。 しかし、例えば単純なETH送金に対して20,000のガスリミットのように、指定するガスが少なすぎると、トランザクションは検証フェーズで失敗します。 ブロックに含まれる前に拒否され、ガスは消費されません。 一方、実行中にトランザクションのガスが尽きた場合(例えば、スマートコントラクトが途中でガスをすべて使い果たした場合)、EVMはすべての変更を元に戻しますが、提供されたガスはすべて実行された作業に対して消費されます。 ## ガス代が高い理由 {#why-can-gas-fees-get-so-high} 高いガス代はイーサリアムの人気の高さが原因です。 需要が高すぎると、他のユーザーのトランザクションよりも高いチップをオファーする必要があり、 高いチップを払うほど、トランザクションが次のブロックに入る可能性が高くなります。 また、より複雑なスマートコントラクトアプリは、その機能を維持するために多くの操作を実行し、大量のガスを消費することがあります。 -## ガス代削減への取り組み {#initiatives-to-reduce-gas-costs} +## ガス代を削減するための取り組み {#initiatives-to-reduce-gas-costs} + +イーサリアムの[スケーラビリティアップグレード](/roadmap/)は、最終的にガス手数料の問題の一部を解決するはずです。これにより、プラットフォームは毎秒数千のトランザクションを処理し、世界規模でスケールできるようになります。 -イーサリアムの[スケーラビリティ・アップグレード](/roadmap/)は、最終的にいくつかのガス代の問題を解決し、ひいてはプラットフォームが毎秒数千のトランザクションを処理し、グローバルにスケールアップできるはずです。 +レイヤー2のスケーリングは、ガス代、ユーザーエクスペリエンス、スケーラビリティを大幅に向上させるための主要なイニシアチブです。 -レイヤー2のスケーリングは、ガス代、ユーザーエクスペリエンス、スケーラビリティを大幅に向上させるための主要なイニシアチブです。 [レイヤー2スケーリングの詳細](/developers/docs/scaling/#layer-2-scaling) +[レイヤー2スケーリングについての詳細](/developers/docs/scaling/#layer-2-scaling) -## ガス代のモニタリング {#monitoring-gas-fees} +## ガス手数料のモニタリング {#monitoring-gas-fees} ETHをより安く送れるようにガス代を節約したい場合は、次のような様々なツールを利用できます。 -- [Etherscan](https://etherscan.io/gastracker)_トランザクションガス価格見積もりツール_ -- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _タイプ0のレガシートランザクションとタイプ2のEIP-1559トランザクションの両方をサポートするChrome拡張機能のガス見積もりツール。_ -- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator)_メインネット、Arbitrum、Polygonで異なるトランザクションタイプのガス代をローカル通貨で計算_ +- [Etherscan](https://etherscan.io/gastracker) _トランザクションのガス価格見積りツール_ +- [Blockscout](https://eth.blockscout.com/gas-tracker) _オープンソースのトランザクションガス価格見積もりツール_ +- [ETH Gas Tracker](https://www.ethgastracker.com/) _イーサリアムとL2のガス価格を監視・追跡し、トランザクション手数料を削減してコストを節約_ +- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _タイプ0のレガシートランザクションとタイプ2のEIP-1559トランザクションの両方をサポートするガス見積もりChrome拡張機能。_ +- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _メインネット、Arbitrum、Polygonにおけるさまざまなトランザクションタイプのガス手数料を自国通貨で計算。_ ## 関連ツール {#related-tools} -- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _Blocknativeのグローバルmempoolデータプラットフォームを搭載したガス見積もりAPI_ +- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _Blocknativeのグローバルなメンプールデータプラットフォームを利用したガス見積もりAPI_ +- [Gas Network](https://gas.network) オンチェーンのガスオラクル。 35以上のチェーンをサポート。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムガスの説明](https://defiprime.com/gas) -- [スマートコントラクトのガス消費量の削減](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) -- [デベロッパーのためのガス最適化戦略](https://www.alchemy.com/overviews/solidity-gas-optimization) -- [EIP-1559のドキュメント](https://eips.ethereum.org/EIPS/eip-1559) -- [Tim BeikoによるEIP-1559のリソース](https://hackmd.io/@timbeiko/1559-resources) +- [イーサリアムのガス解説](https://defiprime.com/gas) +- [スマートコントラクトのガス消費量を削減する](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) +- [開発者向けガス最適化戦略](https://www.alchemy.com/overviews/solidity-gas-optimization) +- [EIP-1559のドキュメント](https://eips.ethereum.org/EIPS/eip-1559)。 +- [Tim BeikoのEIP-1559関連資料](https://hackmd.io/@timbeiko/1559-resources) +- [EIP-1559：メカニズムとミームを切り離す](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) diff --git a/public/content/translations/ja/developers/docs/ides/index.md b/public/content/translations/ja/developers/docs/ides/index.md index f14f8f97516..30033e81e88 100644 --- a/public/content/translations/ja/developers/docs/ides/index.md +++ b/public/content/translations/ja/developers/docs/ides/index.md @@ -1,16 +1,16 @@ --- -title: 統合開発環境 (IDE) -description: +title: "統合開発環境 (IDE)" +description: "Remix、VS Code、人気のプラグインなど、イーサリアム開発のためのウェブベース及びデスクトップIDEについて学ぶ。" lang: ja --- -[統合開発環境(IDE)](https://wikipedia.org/wiki/Integrated_development_environment)のセットアップに関して言えば、イーサリアム上のアプリケーションのプログラミングは、他のソフトウェアプロジェクトのプログラミングと類似しています。 多くの選択肢があるので、最終的には自分の好みに合ったIDEやコードエディタを選んでください。 イーサリアムの開発に最適なIDEは、ほとんどの場合、従来のソフトウェア開発ですでに使用しているIDEです。 +[統合開発環境 (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) のセットアップに関して言えば、イーサリアム上のアプリケーションのプログラミングは、他のソフトウェアプロジェクトのプログラミングと類似しています。 多くの選択肢があるので、最終的には自分の好みに合ったIDEやコードエディタを選んでください。 イーサリアムの開発に最適なIDEは、ほとんどの場合、従来のソフトウェア開発ですでに使用しているIDEです。 -## WebベースのIDE {#web-based-ides} +## ウェブベースのIDE {#web-based-ides} -[ローカル開発環境のセットアップ](/developers/local-environment/)を行う前にコードを触りたい場合、以下のウェブアプリがイーサリアムのスマートコントラクト開発用にカスタムビルドされています。 +[ローカル開発環境をセットアップする](/developers/local-environment/)前にコードを試したいのであれば、これらのウェブアプリはイーサリアムのスマートコントラクト開発用にカスタムビルドされています。 -**[Remix](https://remix.ethereum.org/) ** - **_組み込みの静的解析とテストブロックチェーンの仮想マシンを備えた、ウェブベースのIDE_** +**[Remix](https://remix.ethereum.org/)** - **_静的解析機能とテスト用ブロックチェーン仮想マシンを内蔵したウェブベースのIDE_** - [ドキュメント](https://remix-ide.readthedocs.io/en/latest/#) - [Gitter](https://gitter.im/ethereum/remix) @@ -20,7 +20,7 @@ lang: ja - [ドキュメント](https://chainide.gitbook.io/chainide-english-1/) - [ヘルプフォーラム](https://forum.chainide.com/) -**[Replit (Solidityスターター - ベータ版)](https://replit.com/@replit/Solidity-starter-beta)** - **_ホットリロード、エラーチェック、最高級のテストネットサポートを提供する、イーサリアムのためのカスタマイズ可能な開発環境_** +**[Replit (Solidityスターター - ベータ版)](https://replit.com/@replit/Solidity-starter-beta)** - **_ホットリロード、エラーチェック、優れたテストネットサポートを備えた、イーサリアム向けのカスタマイズ可能な開発環境_** - [ドキュメント](https://docs.replit.com/) @@ -30,18 +30,17 @@ lang: ja - [Gitter](https://gitter.im/loomnetwork/ethfiddle) -## デスクトップのIDE {#desktop-ides} +## デスクトップIDE {#desktop-ides} -ほとんどの定番IDEでは、イーサリアムの開発体験を向上させるプラグインが構築されています。 少なくとも、[スマートコントラクト言語](/developers/docs/smart-contracts/languages/)の構文強調表示は使用できます。 +ほとんどの定番IDEでは、イーサリアムの開発体験を向上させるプラグインが構築されています。 最低限、[スマートコントラクト言語](/developers/docs/smart-contracts/languages/)のシンタックスハイライトを提供します。 -**Visual Studio Code -** **_イーサリアムから公式にサポートされている、プロフェッショナルなクロスプラットフォームIDE_** +**Visual Studio Code -** **_イーサリアムの公式サポートを備えた、プロフェッショナルなクロスプラットフォームIDE_** - [Visual Studio Code](https://code.visualstudio.com/) -- [Azure Blockchain Workbench](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-azure-blockchain.azure-blockchain-workbench?tab=Overview) -- [サンプルコード](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) +- [コードサンプル](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) - [GitHub](https://github.com/microsoft/vscode) -**JetBrains IDE (IntelliJ IDEAなど) -** **_ソフトウェアデベロッパーやチームに不可欠なツール_** +**JetBrains IDEs (IntelliJ IDEA, etc.) -** **_ソフトウェアデベロッパーやチームに不可欠なツール_** - [JetBrains](https://www.jetbrains.com/) - [GitHub](https://github.com/JetBrains) @@ -54,12 +53,12 @@ lang: ja ## プラグインと拡張機能 {#plugins-extensions} -- [Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Visual Studio CodeのためのイーサリアムのSolidity言語 -- [VS CodeのためのSolidityとHardhat](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - HardhatチームによるSolidityとHardhatのサポート -- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - Prettierを使用するコードフォーマッター +- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Visual Studio Code向けイーサリアムSolidity言語 +- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - HardhatチームによるSolidityおよびHardhatサポート +- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - Prettierを使用したコードフォーマッター -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- Alchemyのイーサリアム統合開発環境のリスト_ +- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- AlchemyによるイーサリアムIDEのリスト_ -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/index.md b/public/content/translations/ja/developers/docs/index.md index 204575f5275..085d1c83083 100644 --- a/public/content/translations/ja/developers/docs/index.md +++ b/public/content/translations/ja/developers/docs/index.md @@ -1,18 +1,18 @@ --- -title: イーサリアムの開発ドキュメント -description: ethereum.orgのデベロッパー向けドキュメントの紹介 +title: "イーサリアムの開発ドキュメント" +description: "ethereum.orgのデベロッパー向けドキュメントの紹介" lang: ja --- このドキュメントは、イーサリアムでの構築を支援するためのものです。 コンセプトとしてのイーサリアムを紹介し、イーサリアムの技術スタックに加えて、より複雑なアプリケーションやユースケース向けの高度なトピックを説明しています。 -これはオープンソースのコミュニティ活動ですので、役に立つと思われる場合は、新しいトピックの提案、新しいコンテンツの追加、または例を提供してください。 すべてのドキュメントはGitHubで編集できます。編集方法がわからない場合は、[こちらの手順](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md)に従ってください。 +これはオープンソースのコミュニティ活動ですので、役に立つと思われる場合は、新しいトピックの提案、新しいコンテンツの追加、または例を提供してください。 すべてのドキュメントはGitHubで編集できます – 方法がわからない場合は、[こちらの手順に従ってください](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md)。 ## 開発モジュール {#development-modules} 初めてイーサリアムの開発に挑戦される方は、最初から本のように読み進めていくことをお勧めします。 -### 基本的なトピック {#foundational-topics} +### 基礎的なトピック {#foundational-topics} @@ -20,6 +20,6 @@ lang: ja -### 上級者向け {#advanced} +### 上級 {#advanced} diff --git a/public/content/translations/ja/developers/docs/intro-to-ether/index.md b/public/content/translations/ja/developers/docs/intro-to-ether/index.md index 91daeed74e2..fe132ca8780 100644 --- a/public/content/translations/ja/developers/docs/intro-to-ether/index.md +++ b/public/content/translations/ja/developers/docs/intro-to-ether/index.md @@ -1,12 +1,12 @@ --- -title: イーサ入門 -description: デベロッパーによるイーサ暗号通貨の紹介 +title: "イーサ技術入門" +description: "デベロッパーによるイーサ暗号通貨の紹介" lang: ja --- -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをよりよく理解するために、まずは[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 +このページをよりよく理解するために、まず[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 ## 暗号通貨とは {#what-is-a-cryptocurrency} @@ -16,19 +16,19 @@ lang: ja 最初の暗号通貨は、サトシ・ナカモトが作ったビットコインです。 2009年にビットコインがリリースされて以来、多くの異なるブロックチェーンで何千もの暗号通貨が作られました。 -## イーサとは {#what-is-ether} +## Etherとは {#what-is-ether} -**イーサ(ETH)**は、イーサリアムネットワーク上で広く使用されている暗号通貨です。 基本的には、トランザクションフィーの支払いとして唯一認められているもので、[マージ](/roadmap/merge)後は、メインネットでブロックの検証や提案にも必要となっています。 また、イーサは[分散型金融(DeFi)](/defi)融資市場での主要な担保として、NFT市場でのアカウント単位として、サービスの実行や現実世界の商品の販売で得られる支払いとしてなどにも使用されています。 +**イーサ（ETH）**は、イーサリアムネットワーク上で様々なことに使用される暗号通貨です。 基本的には、取引手数料の支払いとして唯一認められているものであり、[The Merge](/roadmap/merge)後は、メインネットでブロックの検証や提案をするためにイーサが必要となります。 イーサはまた、[DeFi](/defi)レンディング市場における主要な担保形態として、NFTマーケットプレイスにおける計算単位として、サービスの実行や現実世界の商品販売によって得られる支払いとしてなど、様々な用途で使われています。 -イーサリアムでは、デベロッパーが[**分散型アプリケーション(Dapp)**](/developers/docs/dapps)を作成でき、すべてのDappは1つの計算能力のプールを共有します。 この共有プールには限りがあるので、誰が使用するかを判断するためのメカニズムを必要とします。 メカニズムがなければ、ある分散型アプリ(Dapp)が偶発的または悪意を持って、すべてのネットワークリソースを消費してしまい、他のユーザーがアクセスできなくなる恐れがあります。 +イーサリアムでは、開発者が[**分散型アプリケーション（dapps）**](/developers/docs/dapps)を作成でき、それらはすべてコンピューティングパワーのプールを共有します。 この共有プールには限りがあるので、誰が使用するかを判断するためのメカニズムを必要とします。 メカニズムがなければ、ある分散型アプリ(Dapp)が偶発的または悪意を持って、すべてのネットワークリソースを消費してしまい、他のユーザーがアクセスできなくなる恐れがあります。 -イーサ暗号通貨は、イーサリアムのコンピューティング能力の価格設定メカニズムに対応しています。 トランザクションを行うには、ブロックチェーン上でトランザクションを認識してもらうためにイーサを支払う必要があります。 これらの使用料は[ガス代](/developers/docs/gas/)として知られており、ガス代は処理を実行するために必要な計算力の量と、その時のネットワーク全体の計算力の需要により決まります。 +イーサ暗号通貨は、イーサリアムのコンピューティング能力の価格設定メカニズムに対応しています。 トランザクションを行うには、ブロックチェーン上でトランザクションを認識してもらうためにイーサを支払う必要があります。 これらの利用コストは[ガス手数料](/developers/docs/gas/)として知られており、ガス手数料は、取引の実行に必要なコンピューティングパワーの量と、その時点でのネットワーク全体のコンピューティングパワーの需要に応じて決まります。 そのため、悪意のある分散型アプリ(Dapp)が無限ループを送信したとしても、最終的には保有しているイーサを使い果たしてトランザクションが終了し、ネットワークが正常に戻ることになります。 -[広く一般的](https://www.reuters.com/article/us-crypto-currencies-lending-insight-idUSKBN25M0GP#:~:text=price%20of%20ethereum)にイーサリアムとイーサが[混同](https://www.cnn.com/2021/03/14/tech/nft-art-buying/index.html#:~:text=price%20of%20ethereum)されますが、「イーサリアムの価格」について話されている時は、イーサの価格を意味します。 +イーサリアムとイーサは[混同されがちです](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845)。人々が「イーサリアムの価格」に言及するとき、それはイーサの価格を表しています。 -## イーサのミント {#minting-ether} +## イーサのミンティング {#minting-ether} ミント(鋳造)とは、イーサリアムのレジャー(台帳)に新しいイーサが作成されるプロセスのことを指します。 イーサリアムの基礎となるプロトコルが新しいイーサを作り出すのであって、ユーザーがイーサを作り出すことはできません。 @@ -38,15 +38,15 @@ lang: ja イーサは、ブロック報酬によって作成することも、「焼却(バーン)」と呼ばれるプロセスによって破壊することもできます。 イーサが焼却されると、永久に流通できなくなります。 -イーサリアムの全トランザクションで、イーサの焼却が発生します。 ユーザーがトランザクションフィー(手数料)を支払うと、トランザクションの需要に応じてネットワークにより設定されたベースガスフィー(基本ガス手数料)が破棄されます。 これは可変ブロックサイズと最大ガスフィーと相まって、イーサリアムでのトランザクションフィーの見積もりを簡素化します。 ネットワーク需要が高い場合は、 [ブロック](https://etherscan.io/block/12965263)がミントされるイーサよりも多くのイーサを焼却させ、イーサの発行を効果的に相殺することができます。 +イーサリアムの全トランザクションで、イーサの焼却が発生します。 ユーザーがトランザクションフィー(手数料)を支払うと、トランザクションの需要に応じてネットワークにより設定されたベースガスフィー(基本ガス手数料)が破棄されます。 これは可変ブロックサイズと最大ガスフィーと相まって、イーサリアムでのトランザクションフィーの見積もりを簡素化します。 ネットワークの需要が高い場合、[ブロック](https://eth.blockscout.com/block/22580057)はミンティングするよりも多くのイーサを焼却することができ、イーサの発行を効果的に相殺します。 -ベースフィーが焼却されると、ブロック生成者のトランザクション操作能力が低下します。 例えば、ブロック生成者がベースフィーを受け取った場合、自分自身のトランザクションを無料にするために、生成するブロックに自分のトランザクションを追加したり、他の人のベースフィーを上げることができます。 もしくは、オフチェーンの一部のユーザーにベースフィーを払い戻すことができ、より不透明で複雑なトランザクションフィー市場につながるおそれがあります。 +ベースフィーを焼却することで、ブロック生産者が取引を操作する能力が妨げられます。 例えば、ブロック生成者がベースフィーを受け取った場合、自分自身のトランザクションを無料にするために、生成するブロックに自分のトランザクションを追加したり、他の人のベースフィーを上げることができます。 あるいは、オフチェーンで一部のユーザーにベースフィーを返金することもでき、これによりより不透明で複雑なトランザクション手数料市場が生まれる可能性があります。 -## イーサの通貨単位 {#denominations} +## イーサの単位 {#denominations} イーサリアムのトランザクションの多くは、小さな金額で行われるため、イーサには、より小さな会計単位として参照できる通貨単位が設定されています。 これらの通貨単位で、特に重要なのがweiとgweiです。 -weiは最小のイーサ通貨単位で、[イーサリアムイエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf)のような多くの技術的な実装では、すべての計算はweiで行われます。 +Weiはイーサの最小単位であり、その結果、[イーサリアム・イエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf)のような多くの技術的実装では、すべての計算がWeiを基準に行われます。 gweiはgiga-weiの略で、イーサリアムのガス代を記述するためによく使用されます。 @@ -57,22 +57,22 @@ gweiはgiga-weiの略で、イーサリアムのガス代を記述するため ## イーサの送金 {#transferring-ether} -イーサリアムの各トランザクションには、送信者のアドレスから受信者のアドレスへのイーサ送金額を指定する`value`フィールドが含まれています(単位はwei)。 +イーサリアムの各取引には`value`フィールドが含まれており、送信者のアドレスから受信者のアドレスに送金されるイーサの量をwei建てで指定します。 -受信者のアドレスが[スマートコントラクト](/developers/docs/smart-contracts/)の場合、この送金されたイーサは、スマートコントラクトがコードを実行する際のガス代の支払いに使用することができます。 +受信者のアドレスが[スマートコントラクト](/developers/docs/smart-contracts/)である場合、送金されたこのイーサは、スマートコントラクトがコードを実行する際のガス代の支払いに使用されることがあります。 -[トランザクションの詳細](/developers/docs/transactions/) +[取引の詳細](/developers/docs/transactions/) ## イーサの照会 {#querying-ether} -[アカウント](/developers/docs/accounts/)の`balance`フィールドを確認すると、すべてのアカウントのイーサ残高を照会することができます(weiを単位とするイーサ保有量が表示)。 +ユーザーは、[アカウント](/developers/docs/accounts/)の`balance`フィールドを調べることで、任意のアカウントのイーサ残高を照会できます。このフィールドは、wei建てのイーサ保有量を示します。 -[Etherscan](https://etherscan.io)は、ウェブベースのアプリを介してアドレスの残高を調べる人気のツールです。 例えば、 [このEtherscanのページ](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae)はイーサリアム・ファウンデーションの残高を表示しています。 アカウント残高は、ウォレットやノードにリクエストすることで確認できます。 +[Etherscan](https://etherscan.io)と[Blockscout](https://eth.blockscout.com)は、ウェブベースのアプリケーションを介してアドレスの残高を調べるための人気のツールです。 例えば、[このBlockscoutページ](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)には、イーサリアム・ファウンデーションの残高が表示されています。 アカウント残高は、ウォレットやノードにリクエストすることで確認できます。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [イーサとイーサリアムの定義](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ -- [イーサリアムホワイトペーパー](/whitepaper/): イーサリアムの当初の提案。 本書はイーサの説明とその作成の背後にある理由について記述。 -- [Gwei Calculator](https://www.alchemy.com/gwei-calculator): wei、gwei、イーサの変換ツール。 wei、Gwei、ETHの任意の数値を入力するだけで、自動変換。 +- [イーサリアム・ホワイトペーパー](/whitepaper/)：イーサリアムの最初の提案書。 本書はイーサの説明とその作成の背後にある理由について記述。 +- [Gwei計算機](https://www.alchemy.com/gwei-calculator)：このGwei計算機を使って、wei、gwei、イーサを簡単に変換できます。 wei、Gwei、ETHの任意の数値を入力するだけで、自動変換。 -_役に立つコミュニティリソースをご存知の場合は、 このページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/intro-to-ethereum/index.md b/public/content/translations/ja/developers/docs/intro-to-ethereum/index.md index f0dce80e393..38ac480037e 100644 --- a/public/content/translations/ja/developers/docs/intro-to-ethereum/index.md +++ b/public/content/translations/ja/developers/docs/intro-to-ethereum/index.md @@ -1,6 +1,6 @@ --- -title: イーサリアム入門 -description: 分散型アプリ(Dapp)デベロッパーによるイーサリアムのコアコンセプトの紹介 +title: "イーサリアム技術入門" +description: "分散型アプリ(Dapp)デベロッパーによるイーサリアムのコアコンセプトの紹介" lang: ja --- @@ -14,9 +14,9 @@ lang: ja ネットワーク上のすべてのコンピュータが、新しいブロックとチェーン全体に合意しなければなりません。 これらのコンピュータのことを「ノード」と呼びます。 ノードはブロックチェーン上で繋がるすべてのノードが、同じデータを保有することを保証します。 この分散化された合意形成を行うために、ブロックチェーンには合意メカニズムが必須となります。 -イーサリアムは現在[プルーフ・オブ・ステーク (PoS)](/developers/docs/consensus-mechanisms/pos/)合意メカニズムを使用しています。 新しいブロックをチェーンに追加するには、イーサリアムのネイティブ通貨であるETHを担保としてステーキングし、バリデータソフトウェアを実行する必要があります。 その後、ランダムに選択されたバリデータがブロックを提案し、他のバリデータが検証してブロックチェーンに追加します。 報酬とペナルティのシステムにより、バリデータは誠実かつ可能な限りオンラインで稼働することにインセンティブを与えられます。 +イーサリアムは[プルーフ・オブ・ステークベースの合意メカニズム](/developers/docs/consensus-mechanisms/pos/)を使用しています。 新しいブロックをチェーンに追加するには、イーサリアムのネイティブ通貨であるETHを担保としてステーキングし、バリデータソフトウェアを実行する必要があります。 その後、ランダムに選択されたバリデータがブロックを提案し、他のバリデータが検証してブロックチェーンに追加します。 報酬とペナルティのシステムにより、バリデータは誠実かつ可能な限りオンラインで稼働することにインセンティブを与えられます。 -ブロックチェーンデータのハッシュ化や、ブロックの履歴の追加方法については、ぜひ[このデモ](https://andersbrownworth.com/blockchain/blockchain)をご覧ください。また、Anders Brownworth氏による、以下のビデオもおすすめです。 +ブロックチェーンデータがどのようにハッシュ化され、その後にブロック参照の履歴に追加されるかをご覧になりたい場合は、Anders Brownworth氏による[こちらのデモ](https://andersbrownworth.com/blockchain/blockchain)をぜひご覧いただき、以下の付属ビデオもご視聴ください。 Anders氏によるブロックチェーンのハッシュに関する説明: @@ -32,7 +32,7 @@ Anders氏によるブロックチェーンのハッシュに関する説明: このような暗号メカニズムは、一度トランザクションが有効であると検証されてブロックチェーンに追加された後は、改ざんができないようにします。 また、このメカニズムにより、すべてのトランザクションが適切な「許可」があって、署名・実行されることが保証されます。(ここでの「許可」とは、例えばAliceのアカウントからデジタル資産を送信するのは、Alice以外の他者にはできないという意味)。 -## イーサとは {#what-is-ether} +## Etherとは {#what-is-ether} **イーサ(ETH)**はイーサリアムのネイティブ暗号通貨です。 ETHの目的は、ブロックチェーンに必要な計算の市場を可能にすることです。 このような市場は、トランザクションリクエストを検証し、実行するための経済的なインセンティブを与え、またネットワークに計算リソースを提供します。 @@ -40,11 +40,11 @@ Anders氏によるブロックチェーンのハッシュに関する説明: 支払われるETHの額は、トランザクションリクエストの計算に必要なリソースに相当します。 計算リソースに応じて報酬を払わなければならないため、これらの報酬は無限に計算したりリソースを大量に消費するスクリプトを実行することで意図的にネットワークを詰まらせる悪意のある参加者からも守ることができます。 -また、ETHは暗号経済的なセキュリティを提供するため、主に次の3つの方法で使用されます。1) ブロックの提案、または他のバリデータの不誠実な行為を指摘したバリデータへの報酬。 2) 不誠実な行為に対する担保(バリデータはETHをステーキングしており、バリデータが不誠実な行為を行った場合、バリデータのETHを破壊)。3) 新しく提案されたブロックに対する「投票」の重み付けに使われ、合意メカニズムのフォーク・チョイスで使用。 +また、ETHは、主に3つの方法でネットワークに暗号経済的なセキュリティを提供するためにも使用されます。1) ブロックを提案したり、他のバリデータの不正行為を指摘したりしたバリデータへの報酬手段として使用される。2) バリデータによってステークされ、不正行為に対する担保として機能する。バリデータが不正行為を試みた場合、そのETHは破棄される可能性がある。3) 新たに提案されたブロックへの「投票」の重み付けに使用され、合意メカニズムのフォーク選択に利用される。 ## スマートコントラクトとは {#what-are-smart-contracts} -参加者はEVMで計算をリクエストするたびに、新たなコードを作成するわけではありません。 アプリケーションデベロッパーがプログラム(再利用可能なコードの一部)をEVMにアップロードし、ユーザーがそのコードをさまざまなパラメータで実行するようにリクエストします。 ブロックチェーン上のネットワークにアップロードされ、実行されるプログラムをスマートコントラクトと呼びます。 +参加者はEVMで計算をリクエストするたびに、新たなコードを作成するわけではありません。 アプリケーションデベロッパーがプログラム(再利用可能なコードの一部)をEVMにアップロードし、ユーザーがそのコードをさまざまなパラメータで実行するようにリクエストします。 ネットワークにアップロードされ、ネットワークによって実行されるプログラムを「スマートコントラクト」と呼びます。 スマートコントラクトは、基本的なレベルでは、自動販売機のようなものだと考えることができます。つまり、特定のパラメータで呼び出され、一定の条件が満たされた場合、何らかのアクションや計算を実行するスクリプトです。 例えば、発信者が特定の受取人にETHを送信すると、スマートコントラクトが単純にデジタル資産の所有権を作成・割り当てるなどです。 @@ -52,7 +52,7 @@ Anders氏によるブロックチェーンのハッシュに関する説明: このように、スマートコントラクトを利用することで、デベロッパーは複雑なユーザー向けアプリや様々なサービス(マーケットプレイス、金融商品、ゲームなど)を構築し、ブロックチェーン上にデプロイできます。 -## 用語集 {#terminology} +## 用語 {#terminology} ### ブロックチェーン {#blockchain} @@ -60,11 +60,11 @@ Anders氏によるブロックチェーンのハッシュに関する説明: ### ETH {#eth} -**イーサ(ETH)**はイーサリアムのネイティブ暗号通貨。 コー​​ド実行リクエストが達成されるには、ユーザーは手数料としてETHを支払う必要がある。 +**イーサ(ETH)**はイーサリアムのネイティブ暗号通貨です。 コー​​ド実行リクエストが達成されるには、ユーザーは手数料としてETHを支払う必要がある。 [ETHの詳細](/developers/docs/intro-to-ether/) -### EVM(イーサリアム仮想マシン) {#evm} +### EVM {#evm} EVM(イーサリアム仮想マシン)とは、イーサリアムネットワーク上のすべてのノードが同じ状態を保存し、同意するグローバルな仮想コンピュータ。 参加者は誰でも、EVMで任意のコードの実行をリクエストすることができ、コードが実行されると、EVMの状態が変更される。 @@ -90,27 +90,35 @@ ETHの保有先。 ユーザーはアカウントを初期化し、アカウン - スマートコントラクトのコードをEVM状態に公開 - EVMのアドレスXで、引数Yを使用してスマートコントラクトのコードを実行 -[トランザクションの詳細](/developers/docs/transactions/) +[取引の詳細](/developers/docs/transactions/) ### ブロック {#blocks} トランザクション量が非常に多いため、トランザクションはバッチまたはブロック単位で「コミット」される。 ブロックには通常、数十から数百のトランザクションが含まれる。 -[ブロックの詳細](/developers/docs/blocks/) +[ブロックについての詳細](/developers/docs/blocks/) ### スマートコントラクト {#smart-contracts} -デベロッパーがEVMの状態に公開する、再利用可能なコード(プログラム)の断片。 トランザクションリクエストを行うことで、誰でもスマートコントラクトコードの実行をリクエスト可能。 デベロッパーはスマートコントラクトを公開して、任意の実行可能なアプリケーション(ゲーム、マーケットプレイス、金融商品など)をEVMに書き込むことができ、これらは[分散型アプリ(Dapp)](/developers/docs/dapps/)と呼ばれる。 +デベロッパーがEVMの状態に公開する、再利用可能なコード(プログラム)の断片。 トランザクションリクエストを行うことで、誰でもスマートコントラクトコードの実行をリクエスト可能。 デベロッパーはEVMに任意の実行可能なアプリケーション(ゲーム、マーケットプレイス、金融商品など)を書き込めるため スマートコントラクトを公開することで、これらは[dapps、または分散型アプリケーション](/developers/docs/dapps/)とも呼ばれることがよくあります。 [スマートコントラクトの詳細](/developers/docs/smart-contracts/) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムホワイトペーパー](/whitepaper/) -- [イーサリアムの仕組みについて](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**注: **このリソースは依然として価値のあるものですが、[マージ](/roadmap/merge)以前の情報であり、イーサリアムのプルーフ・オブ・ワークのメカニズムを参照しています。イーサリアムは現在、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)で保護されています) +- [イーサリアム ホワイトペーパー](/whitepaper/) +- [イーサリアムの仕組みについて](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**注**: このリソースは依然として価値のあるものですが、[マージ](/roadmap/merge)以前の情報であり、イーサリアムのプルーフ・オブ・ワークのメカニズムを参照しています。イーサリアムは現在、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)で保護されています) -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +### 映像で学びたい場合 {#visual-learner} + +このビデオシリーズでは、基礎的なトピックについて徹底的に探求しています： + + + +[イーサリアムの基礎 プレイリスト](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ) + +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連チュートリアル {#related-tutorials} -- [イーサリアムのデベロッパー向けガイド・パート 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Pythonとweb3.pyを使用した初心者向けのイーサリアムガイド_ +- [デベロッパー向けイーサリアムガイド、パート1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Pythonとweb3.pyを使用した、非常に初心者向けのイーサリアムの探求_ diff --git a/public/content/translations/ja/developers/docs/mev/index.md b/public/content/translations/ja/developers/docs/mev/index.md index 84788be1075..59e2d8356e5 100644 --- a/public/content/translations/ja/developers/docs/mev/index.md +++ b/public/content/translations/ja/developers/docs/mev/index.md @@ -1,32 +1,32 @@ --- -title: 最大抽出可能価値（MEV） -description: 最大抽出可能価値（MEV）という概念を紹介する。 +title: "最大抽出可能価値（MEV）" +description: "最大抽出可能価値（MEV）という概念を紹介する。" lang: ja --- 最大抽出可能価値（MEV）とは、特定のブロックにおけるトランザクションの追加、削除、または順序変更により、ブロックの生成時において標準的なブロック報酬やガス代を超過して抽出できる最大の価値を指します。 -## 最大抽出可能価値(MEV) {#maximal-extractable-value} +## 最大抽出可能価値 {#maximal-extractable-value} -最大抽出可能価値（MEV）は、 [プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)に基づき導入された概念であり、当初は「採掘可能価値（MEV）」と呼ばれていました。 プルーフ・オブ・ワークでは、トランザクションの追加、削除、および順序決定をマイナーが管理していたためです。 しかし、[マージ](/roadmap/merge)によるプルーフ・オブ・ステークへの移行後、バリデータがこれらの役割を担うようになり、マイニングはイーサリアムのプロトコルから削除されました。 しかし、価値採掘のための手段は依然として存在するため、現在は「最大抽出可能価値」という用語を用います。 +最大抽出可能価値は、[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)の文脈で初めて適用され、当初は「マイナー抽出可能価値」と呼ばれていました。 プルーフ・オブ・ワークでは、トランザクションの追加、削除、および順序決定をマイナーが管理していたためです。 しかし、[The Merge](/roadmap/merge)によるプルーフ・オブ・ステークへの移行後、バリデータがこれらの役割を担うようになり、マイニングはもはやイーサリアムプロトコルの一部ではありません。 しかし、価値採掘のための手段は依然として存在するため、現在は「最大抽出可能価値」という用語を用います。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[トランザクション](/developers/docs/transactions/) 、[ブロック](/developers/docs/blocks/)、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)、および[ガス](/developers/docs/gas/)について理解している必要があります。 また、[分散アプリケーション（Dapp）](/apps/)や[分散型金融（DeFi）](/defi/)の知識も有用です。 +[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)、[ガス](/developers/docs/gas/)についてよく理解しておきましょう。 また、[dapps](/apps/)や[DeFi](/defi/)に関する知識も役立ちます。 -## MEVの抽出 {#mev-extraction} +## MEV抽出 {#mev-extraction} 理論的に言えば、利益を伴うMEVの抽出の実行を保証できるのはバリデータのみであるため、MEVが蓄積するのはバリデータにおいてのみです。 しかし実際には、抽出されるMEVの大部分は「サーチャー」と呼ばれる独立したネットワーク参加者が獲得しています。 サーチャーは、ブロックチェーンのデータに対して複雑なアルゴリズムを実行して利益を伴うMEVの抽出機会を検出し、ボットを利用してこれらの利益を伴うトランザクションをネットワークに自動的に送信します。 サーチャーは、高額のガス代を（バリデータに）支払ってでも、発見した利益が期待できるトランザクションがブロックに追加される可能性を高めたいと考えるため、バリデータは発生したMEV全体からその一部を獲得することができます。 サーチャーが経済的に合理的に行動すると仮定した場合、サーチャーが支払いたいと考えるガス代は、サーチャーが獲得できるMEVの100%までになります（ガス代がMEVの100%を越えれば、サーチャーは赤字になるため）。 -ただし、[分散型取引所（DEX）の裁定取引](#mev-examples-dex-arbitrage)のように競争が激しいMEVの抽出機会の場合、非常に多くのユーザーが利益を伴う裁定取引を実行したいと考えるため、サーチャーは、このMEVにおける全収益の90%あるいはそれ以上をバリデータに支払う必要がある場合があります。 裁定取引が実行できる唯一の保証は、最も高いガス代を持つトランザクションを送信することだからです。 +そのため、[DEXアービトラージ](#mev-examples-dex-arbitrage)のような競争の激しい一部のMEV機会では、同じ収益性の高いアービトラージ取引を実行したいと考える人が多いため、サーチャーはMEVによる総収益の90%以上をガス代としてバリデータに支払わなければならない場合があります。 裁定取引が実行できる唯一の保証は、最も高いガス代を持つトランザクションを送信することだからです。 ### ガスゴルフ {#mev-extraction-gas-golfing} 上記の力学に基づき、「ガス・ゴルフ（gas golfing）」（ガス代が最も安価になるようにトランザクションをプログラミングすること）の能力が競合上の優位性として確立されています。ガス・ゴルフにより、サーチャーはより高価なガス代を設定しつつ、ガス代の合計額を一定に抑えられるためです（ガス代＝ガス価格×使用ガス量）。 -よく知られているガス・ゴルフのテクニックとしては、以下があります：多くのゼロを持つ文字列で始まるアドレス (例: [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://etherscan.io/address/0x0000000000c521824eaff97eac7b73b084ef9306)) を使う方法では、保存スペースが小さくなるためガス代も低くなります。あるいは、少額の[ERC-20](/developers/docs/standards/tokens/erc-20/) トークン残高をコントラクトに残しておく方法もありますが、これは（残高が0の場合に）ストレージスロットを初期化すると、 ストレージスロットを更新する場合よりも多くのガスが消費される点を利用したものです。 サーチャーのコミュニティでは、ガスの使用量を減らすためのテクニックが活発に研究されています。 +よく知られているガスゴルフのテクニックとしては、以下があります：多くのゼロを持つ文字列で始まるアドレス（例：[0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)）を使う方法では、保存スペースが小さくなるためガス代も低くなります。あるいは、少額の[ERC-20](/developers/docs/standards/tokens/erc-20/)トークン残高をコントラクトに残しておく方法もありますが、これは（残高が0の場合に）ストレージスロットを初期化すると、ストレージスロットを更新する場合よりも多くのガスが消費される点を利用したものです。 サーチャーのコミュニティでは、ガスの使用量を減らすためのテクニックが活発に研究されています。 ### 一般化されたフロントランナー {#mev-extraction-generalized-frontrunners} @@ -36,27 +36,27 @@ lang: ja フラッシュボットは、実行クライアントを拡張する独立したプロジェクトであり、サーチャーに対して、パブリックのメモリプールに公開することなく、MEVトランザクションをバリデータに送信できるサービスを提供します。 このサービスを使用すれば、汎用フロントランナーを用いたトランザクションに実行を先回りされることを防ぐことができます。 -## MEVの実例 {#mev-examples} +## MEVの例 {#mev-examples} ブロックチェーンにおいてMEVが発生するケースは、いくつかの種類があります。 -### DEX裁定取引 {#mev-examples-dex-arbitrage} +### DEXアービトラージ {#mev-examples-dex-arbitrage} -[分散型取引所 (DEX) ](/glossary/#dex)における裁定取引は、最もシンプルでよく知られているMEVの機会です。 このため、ユーザー間の競争も最も激しくなっています。 +[分散型取引所](/glossary/#dex)(DEX)でのアービトラージは、最もシンプルで最もよく知られたMEVの機会です。 このため、ユーザー間の競争も最も激しくなっています。 具体的には、以下のように発生します：2カ所のDEXが同じトークンを異なる価格で提供している場合、より安価に設定したDEXでトークンを購入し、より高価に設定したDEXで売却すれば、1回の不可分な取引で利益を得ることができます。 ブロックチェーンの仕組みにより、全くリスクを伴わない裁定取引が可能になります。 -[これは](https://etherscan.io/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4)、UniswapおよびSushiswapにおけるETH/DAIペアの価格差を利用して、サーチャーが1,000ETHを1,045ETHに変換して収益を得た裁定取引の例です。 +これは、サーチャーがUniswapとSushiswapでのETH/DAIペアの価格差を利用して、1,000 ETHを1,045 ETHに換えた収益性の高いアービトラージ取引の[一例です](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4)。 -### 流動化 {#mev-examples-liquidations} +### 清算 {#mev-examples-liquidations} 貸出プロトコルによる精算も、よく知られたMEV獲得機会のひとつです。 -MakerやAaveのような貸出プロトコルでは、ユーザーは何らかの担保（例: ETH）を預入しなければなりません。 預け入れられた担保は、他のユーザーに貸し出されます。 +MakerやAaveのようなレンディングプロトコルでは、ユーザーは何らかの担保（例：ETH）を預け入れる必要があります。 この預け入れられた担保は、その後、他のユーザーに貸し出されます。 ユーザーは、この仕組みを活用して、預け入れた担保に対する一定の上限額まで、自らの必要に応じて他のユーザーから資産やトークンを借り入れることができます（例: MakerDAOのガバナンス提案に投票するために、MKRを借り入れる場合）。 例えば、借入可能額が預け入れた担保の30%までの場合、プロトコルに100 DAIを預け入れれば、30 DAIの価値を持つ他の資産を借り入れることができます。 貸出プロトコルは、具体的な借入能力（担保に対する割合）を決定します。 -借り手の担保価値が変動すれば、借入能力も上下します。 具体的には、市場の変動により借入資産の価値が担保価値の（例えば）30%を越えた場合（上述したように、実際の借入可能な割合は貸出プロトコルが決定します）、貸出プロトコルは通常、あらゆるユーザーに対してこの担保を精算し、瞬時に貸し手に払い戻すことを許可します（これは、伝統的な金融市場における[マージンコール](https://www.investopedia.com/terms/m/margincall.asp)の仕組みと同様です）。 一般に、担保が精算される場合に借り手は高額の精算手数料を支払う必要があり、この手数料の一部は清算人に支払われるため、MEVを獲得する機会が発生するのです。 +借り手の担保価値が変動すれば、借入能力も上下します。 市場の変動により、借入資産の価値が担保価値の例えば30%を超えた場合(繰り返しますが、正確な割合はプロトコルによって決定されます)、プロトコルは通常、誰でもその担保を清算し、貸し手に即座に返済することを許可します(これは、伝統的な金融における[マージンコール](https://www.investopedia.com/terms/m/margincall.asp)の仕組みと似ています)。 一般に、担保が精算される場合に借り手は高額の精算手数料を支払う必要があり、この手数料の一部は清算人に支払われるため、MEVを獲得する機会が発生するのです。 サーチャーは、可能なかぎり高速にブロックチェーンのデータを分析することで、精算の対象となりうる借り手を特定し、精算トランザクションを他に先がけて送信し、精算手数料を回収するための競争を行っています。 @@ -66,9 +66,9 @@ MakerやAaveのような貸出プロトコルでは、ユーザーは何らか サーチャーは、サンドイッチ取引を念頭に置いてDEXにおける大型取引のメモリプールを監視します。 例えば、あるユーザーがUniswapで、DAIを使って10000 UNIを購入したい場合を考えてみましょう。 これほど大きな取引は、UNI/DAIペアの為替レートに有意な影響を与えるものであり、対DAIのUNI価格を大きく上昇させる可能性があります。 -サーチャーは、この大口取引によるUNI/DAIペアに対する大まかな価格効果を計算し、大口取引の_直前に_最適な買い注文を実行してUNIを安価で購入した上で、大口取引の_直後に_ 売り注文を実行し、大口注文により値上がりした価格で売却することができます。 +サーチャーは、この大口取引によるUNI/DAIペアに対する大まかな価格効果を計算し、大口取引の直前に最適な買い注文を実行してUNIを安価で購入した上で、大口取引の直後に売り注文を実行し、大口注文により値上がりした価格で売却することができます。 -しかし、サンドイッチ取引は1回で完結できない取引であるため（この点が、上述のDEXにおける裁定取引とは異なります）よりリスクが大きく、[サルモネラ攻撃](https://github.com/Defi-Cartel/salmonella)の対象となりやすい欠点を持ちます。 +しかし、サンドイッチングはアトミックではないため(前述のDEXアービトラージとは異なります)、よりリスクが高く、[サルモネラ攻撃](https://github.com/Defi-Cartel/salmonella)を受けやすくなっています。 ### NFT MEV {#mev-examples-nfts} @@ -76,75 +76,75 @@ NFTを用いたMEVの抽出は、最近発生しつつある現象であり、 しかし、NFTのトランザクションは、その他すべてのイーサリアムのトランザクションと同一のブロックチェーン上で実行されるため、サーチャーは上記で紹介した従来のMEV獲得のためのテクニックをNFT市場でも応用することができます。 -例えば、人気が高いNFTドロップが実行され、サーチャーが特定のNFTあるいは複数のNFTを持つセットを獲得したい場合、このNFTの購入リストの先頭になるようにトランザクションをプログラミングしたり、1回のトランザクションで当該NFTのセット全体を購入したりすることができます。 また、NFTが [ミスにより低価格で出品](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent)されている場合、サーチャーは他の購入者を先回りして取引を実行し、安価で手に入れることができます。 +例えば、人気が高いNFTドロップが実行され、サーチャーが特定のNFTあるいは複数のNFTを持つセットを獲得したい場合、このNFTの購入リストの先頭になるようにトランザクションをプログラミングしたり、1回のトランザクションで当該NFTのセット全体を購入したりすることができます。 あるいは、NFTが[誤って低価格で出品された](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent)場合、サーチャーは他の購入者をフロントランニングして、安価に手に入れることができます。 -NFTを使ったMEV抽出の顕著な事例としては、あるサーチャーが700万ドルを投じて、Cryptopunkを底値ですべて[購入した](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5)ケースがあります。 この事例については、買い手がMEVプロバイダーと連携してどのようにこの購入を秘匿したかについて、あるブロックチェーン研究者が[ツイッター](https://twitter.com/IvanBogatyy/status/1422232184493121538)上で説明しています。 +NFT MEVの顕著な例として、あるサーチャーが700万ドルを費やして、フロアプライスですべてのCryptopunkを[購入した](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs)ケースがあります。 この事例については、買い手がMEVプロバイダーと連携してどのようにこの購入を秘匿したかについて、あるブロックチェーン研究者が[Twitterで説明しています](https://twitter.com/IvanBogatyy/status/1422232184493121538)。 ### ロングテール {#mev-examples-long-tail} DEXにおける裁定取引、精算、およびサンドイッチ取引はいずれも、よく知られたMEVの獲得機会であり、新規参入のサーチャーが利益を得られる可能性は低いです。 しかし、数は少ないものの、まだ一般的でないMEVの獲得機会も存在します（NFTによるMEV獲得も、そのひとつだと言えるかもしれません）。 -サーチャーの分野に新たに参入したい方は、このロングテールの部分に焦点を当てることで、MEVを獲得できる可能性が高まるかもしれません。 フラッシュボットの[MEV求人板](https://github.com/flashbots/mev-job-board)には、最近発生しつつある新たなMEV獲得機会が掲載されています。 +サーチャーの分野に新たに参入したい方は、このロングテールの部分に焦点を当てることで、MEVを獲得できる可能性が高まるかもしれません。 Flashbotsの[MEVジョブボード](https://github.com/flashbots/mev-job-board)には、新たな機会がいくつかリストアップされています。 ## MEVの影響 {#effects-of-mev} MEVは必ずしも絶対悪ではなく、イーサリアムにとってはよい影響と悪い影響の両方を持ちます。 -### 善者 {#effects-of-mev-the-good} +### メリット {#effects-of-mev-the-good} 多くの分散型金融（DeFi）プロジェクトは、プロトコルの有用性と安定性を確保するために、経済的合理性に基づいて行動するユーザーに依存しています。 DEXにおける裁定取引は、ユーザーが各自のトークンに対して最善かつ最も適切な価格を得られることを保証するメカニズムであり、貸出プロトコルは、借入可能な比率を超過した借り手にただちに精算を迫ることで、貸し手に対する返済を保証しています。 経済合理性に基づき行動するサーチャーが、経済的な非効率性を発見し、それを修正することで、当該プロトコルにおける経済的なインセンティブを獲得することができなければ、DeFiのプロトコルやDappは現在実現されている強じん性を維持できないでしょう。 -### 悪者 {#effects-of-mev-the-bad} +### デメリット {#effects-of-mev-the-bad} アプリケーションレイヤーにおいては、サンドイッチ取引をはじめとする一部のMEV獲得方法はユーザーの利用体験を明らかに低下させます。 サンドイッチ取引に巻き込まれたユーザーは、スリッページの被害を受け、取引条件が悪化するでしょう。 ネットワークレイヤーにおいては、汎用フロントランナーやガス価格のオークションが頻繁に用いられるため（複数のフロントランナーが、次のブロックに追加されるトランザクションのガス代を吊り上げる競争を行う場合）、ネットワークの混雑が悪化するだけでなく、通常のトランザクションを実行したい他のすべてのユーザーにとってもガス代が上昇してしまいます。 -MEVは、ブロック _内部_における影響に加えて、複数のブロック_間_においても悪影響をもたらす場合があります。 特定のブロック内において獲得できるMEVが標準的なブロック報酬を大きく上回る場合、バリデータにとっては、ブロックを再編成し、バリデータ自身がMEVを獲得しようというインセンティブが発生しうるため、ブロックチェーンの再編成を促し、コンセンサスの安定性が損なわれる可能性があります。 +ブロックの_内部_で起こっていることだけでなく、MEVはブロック_間_でも有害な影響を及ぼす可能性があります。 特定のブロック内において獲得できるMEVが標準的なブロック報酬を大きく上回る場合、バリデータにとっては、ブロックを再編成し、バリデータ自身がMEVを獲得しようというインセンティブが発生しうるため、ブロックチェーンの再編成を促し、コンセンサスの安定性が損なわれる可能性があります。 -このブロックチェーンが再編成される可能性は、 [すでにビットコインのブロックチェーンにおいて発生しています](https://dl.acm.org/doi/10.1145/2976749.2978408)。 ビットコインのブロック報酬が半減し、ブロック報酬においてトランザクション手数料が占める割合がますます大きくなると、マイナーにとっては、次のブロックで得られる報酬よりも、より高額な手数料が期待できる過去のブロックを再採掘する方が経済的に合理的である状況が発生します。 MEVの抽出が一般化した場合、イーサリアムにおいても類似の状況が発生し、イーサリアム・ブロックチェーンの健全性が損なわれる可能性があります。 +このブロックチェーン再編成の可能性は、[以前にBitcoinブロックチェーンで調査されています](https://dl.acm.org/doi/10.1145/2976749.2978408)。 ビットコインのブロック報酬が半減し、ブロック報酬においてトランザクション手数料が占める割合がますます大きくなると、マイナーにとっては、次のブロックで得られる報酬よりも、より高額な手数料が期待できる過去のブロックを再採掘する方が経済的に合理的である状況が発生します。 MEVの抽出が一般化した場合、イーサリアムにおいても類似の状況が発生し、イーサリアム・ブロックチェーンの健全性が損なわれる可能性があります。 -## MEVの現況 {#state-of-mev} +## MEVの現状 {#state-of-mev} -MEVの抽出は、2021年初頭から爆発的に増加し、同年1月から数ヶ月にわたりガス価格が大きく高騰しました。 しかし、フラッシュボットのMEVリレーが登場した結果、汎用フロントランナーの効果が薄れ、ガス代のオークションがオフチェーンで実行されるようになったため、通常のユーザーが支払うガス価格は低下しました。 +MEVの抽出は、2021年初頭から爆発的に増加し、同年1月から数ヶ月にわたりガス価格が大きく高騰しました。 FlashbotsのMEVリレーの登場は、汎用的なフロントランナーの効果を低下させ、ガス価格のオークションをオフチェーンに移行させました。これにより、一般ユーザーのガス代は下がりました。 現在も多くのサーチャーがMEVにより充分な利益を得ているものの、MEVの抽出機会に対する認知度が高まり、同じ機会により多くのサーチャーが参加するようになるにつれ、MEVの総収益のうちバリデータの利益が占める割合はますます大きくなるでしょう（と言うのも、上記で説明したガス代のオークションと同様の状況は、非公開の取引を通じてフラッシュボットでも発生するため、その結果発生するガス収益はバリデータが獲得するためです）。 また、MEVが発生するのはイーサリアムに限りません。イーサリアムにおけるMEVの獲得機会に対する競争が激化するにつれ、サーチャーは、同じような機会が存在し、より競争相手が少ないバイナンス・スマートチェーンなどの他のブロックチェーンに移行する傾向を強めています。 -一方、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行や、ロールアップを活用してイーサリアムのスケーリングを実現するための継続的な取り組みなどはいずれも、MEVを取り巻く環境を一変させるものですが、それらがどのような影響を及ぼすかは現時点では明確ではありません。 プルーフ・オブ・ワークの確率論的モデルとの比較において、保証済みのブロック提案者に対してやや事前に通知することがMEV抽出の力学をどのように変化させるのか、あるいは、[1名のシークレットリーダー選挙](https://ethresear.ch/t/secret-non-single-leader-election/11789)および[分散型バリデータ技術](/staking/dvt/)が実装された場合に、この環境がどのような影響を被るのかは、現在のところはっきりしていません。 同様に、大部分のユーザーアクティビティがイーサリアムの外部に移行し、L2におけるロールアップやシャードで実行される場合、どのようなMEVの抽出機会が残存するのかも不明です。 +一方、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行や、ロールアップを活用してイーサリアムのスケーリングを実現するための継続的な取り組みなどはいずれも、MEVを取り巻く環境を一変させるものですが、それらがどのような影響を及ぼすかは現時点では明確ではありません。 保証されたブロック提案者を少し前に知ることが、プルーフ・オブ・ワークの確率論的モデルと比較してMEV抽出のダイナミクスをどのように変化させるのか、また[単一秘密リーダー選出](https://ethresear.ch/t/secret-non-single-leader-election/11789)や[分散型バリデータ技術](/staking/dvt/)が実装されたときにこれがどのように覆されるのかは、まだよくわかっていません。 同様に、大部分のユーザーアクティビティがイーサリアムの外部に移行し、L2におけるロールアップやシャードで実行される場合、どのようなMEVの抽出機会が残存するのかも不明です。 -## イーサリアムのプルーフ・オブ・ステーク（PoS）におけるMEV {#mev-in-ethereum-proof-of-stake} +## イーサリアムのプルーフ・オブ・ステーク(PoS)におけるMEV {#mev-in-ethereum-proof-of-stake} 上述したように、MEVは全般的なユーザー体験やコンセンサスレイヤーのセキュリティに悪影響を及ぼします。 しかし、イーサリアムにおけるプルーフ・オブ・ステークへの移行（「マージ」と呼ぶ）に伴い、MEVに関連して以下のような新たなリスクが発生する可能性があります： -### バリデータの集中 {#validator-centralization} +### バリデータの中央集権化 {#validator-centralization} -マージ後のイーサリアムにおいては、バリデータ（32 ETHのセキュリティ・デポジットを行ったユーザー）は、ビーコンチェーンに追加されたブロックの検証に対するコンセンサスに参加します。 多くのユーザーにとっては、32 ETHの負担は大きすぎるため、[ステーキングプールへの参加](/staking/pools/)がより現実的なオプションとなるかもしれません。 しかし、特定のユーザーのみにバリデータが集中することを回避し、イーサリアムのセキュリティを向上させるには、[ソロステーカー](/staking/solo/)の割合を健全に保つことが望ましいと言えます。 +マージ後のイーサリアムにおいては、バリデータ（32 ETHのセキュリティ・デポジットを行ったユーザー）は、ビーコンチェーンに追加されたブロックの検証に対するコンセンサスに参加します。 32 ETHは多くの人にとって手の届かない額であるため、[ステーキングプールに参加する](/staking/pools/)ことが、より現実的な選択肢となるかもしれません。 しかし、特定のユーザーのみにバリデータが集中することを回避し、イーサリアムのセキュリティを向上させるには、[ソロステーカー](/staking/solo/)の割合を健全に保つことが望ましいと言えます。 -しかし、MEVの抽出機会により、特定のユーザーのみがバリデータとなる傾向が強まると考えられています。 この原因の1つは、バリデータが[ブロック提案で得る報酬](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply)が以前のマイナーより少なくなったため、マージ以降、MEVの抽出が[バリデータの収益に大きな影響を与えている](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb)からです。 +しかし、MEVの抽出機会により、特定のユーザーのみがバリデータとなる傾向が強まると考えられています。 これは、[The Merge](/roadmap/merge/)以降、バリデータが[ブロック提案で得る収益](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply)が以前のマイナーよりも少なくなったため、MEV抽出がバリデータの収益に大きく[影響を与える](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb)ようになったことも一因です。 -ステーキングプールの規模が大きくなればなるほど、MEVの抽出機会を活用するために必要な最適化に対してより多くのリソースを投じる傾向が高まるでしょう。 これらのプールから抽出できるMEVが大きくなればなるほど、バリデータはMEVの抽出能力を向上させるためにより多くのリソースを投じ、（さらに全体的な収益増を実現する）ことになるため、結果的に[規模の経済](https://www.investopedia.com/terms/e/economiesofscale.asp#)が実現されます。 +ステーキングプールの規模が大きくなればなるほど、MEVの抽出機会を活用するために必要な最適化に対してより多くのリソースを投じる傾向が高まるでしょう。 これらのプールが抽出するMEVが多ければ多いほど、MEV抽出能力を向上させるためのリソースが増え(そして全体の収益も増加し)、本質的に[規模の経済](https://www.investopedia.com/terms/e/economiesofscale.asp#)を生み出します。 ソロステーカーは、利用できるリソースが少ないために、MEVの機会から利益を得られなくなるかもしれません。 これにより、独立系のバリデータが収益を高めるために大規模なステーキングプールに参加する傾向が強まり、イーサリアムにおける分散化が損なわれる可能性があります。 -### 許可済みのメモリプール {#permissioned-mempools} +### パーミッション型メンプール {#permissioned-mempools} -サンドイッチ取引やフロントランナー攻撃に対処するため、取引を行うユーザーは、トランザクションのプライバシーを維持するためにバリデータを伴う取引をオフチェーンで実行するようになるかもしれません。 MEV抽出の可能性があるトランザクションを公開メモリプールに送信するのではなく、バリデータにトランザクションを直接送信する方法では、ブロックへの追加を担うバリデータと利益を共有することができます。 +サンドイッチ攻撃やフロントランニング攻撃に対抗するため、トレーダーは取引のプライバシーを確保するために、バリデーターとオフチェーンでの取引を始めようとするかもしれません。 MEV抽出の可能性があるトランザクションを公開メモリプールに送信するのではなく、バリデータにトランザクションを直接送信する方法では、ブロックへの追加を担うバリデータと利益を共有することができます。 このような取り決めをより大規模にしたものが「ダークプール」であり、一定の手数料を支払う意思があるユーザーのみが参加する、許可済みでアクセスのみ可能なメモリプールとして機能します。 このようなメモリプールを活用する傾向が強まれば、イーサリアムにおけるパーミッションレス、トラストレスの特性が失われ、ブロックチェーンが最高額入札者にとって有利な「ペイ・トゥ・プレイ」のメカニズムに変質してしまう可能性があります。 さらに、許可済みのメモリプールは、上述したようにユーザーの集中化というリスクを強めます。 複数のバリデータが大規模なプールを実行する場合、取引者およびユーザーにとってはトランザクションのプライバシーを維持できるという利益が発生するため、MEVの収益が増加するでしょう。 -マージ後のイーサリアムにおいては、これらのMEV関連の問題にどう対処するかがリサーチコミュニティにおける核心的な課題となっています。 現在のところ、マージ後のイーサリアムにおいてMEVが及ぼす分散化およびセキュリティへの悪影響を軽減するためのソリューションとしては、**提案者と作成者の分離（PBS）**および**ビルダーAPI**が提案されています。 +マージ後のイーサリアムにおいては、これらのMEV関連の問題にどう対処するかがリサーチコミュニティにおける核心的な課題となっています。 現在、The Merge後のイーサリアムの分散化とセキュリティに対するMEVの悪影響を軽減するために提案されている2つのソリューションは、[**提案者・ビルダー分離(PBS)**](/roadmap/pbs/)と[**ビルダーAPI**](https://github.com/ethereum/builder-specs)です。 -### 提案者と作成者の分離（PBS） {#proposer-builder-separation} +### 提案者・ビルダー分離 {#proposer-builder-separation} プルーフ・オブ・ワークであれプルーフ・オブ・ステークであれ、ブロックを作成するノードは、作成したブロックをチェーンに追加することをコンセンサスに参加する他のノードに提案します。 新しいブロックは、プルーフ・オブ・ワーク (PoW) では他のマイナーがその上に新たなブロックを構築することで、プルーフ・オブ・ステーク (PoS) ではバリデータの過半数からアテステーションを受けることで、正当なチェーンに組み込まれます。 -この記事で紹介したMEVに関する問題点の多くは、ブロックの作成者と提案者の役割が分離されていないことに由来しています。 例えば、コンセンサスに参加しているノードは、MEVによる収益を最大化するために、タイムバンディット攻撃を使ってチェーンの再編成をトリガーするインセンティブを持っています。 +この記事で紹介したMEVに関する問題点の多くは、ブロックの作成者と提案者の役割が分離されていないことに由来しています。 例えば、コンセンサスノードは、MEVの収益を最大化するために、[タイムバンディット攻撃](https://www.mev.wiki/attack-examples/time-bandit-attack)でチェーンの再編成を誘発するインセンティブを持っています。 -[提案者と作成者の分離（PBS）](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) は、特にコンセンサスレイヤーにおけるMEVの影響を軽減するように設計されています。 PBSの主な機能は、ブロックの作成者と提案者に対するルールを分離することです。 バリデータがブロックの提案と投票に責任を負う点は変わりませんが、**ブロックビルダー**と呼ばれる専門の新たなエンティティ・クラスが導入され、トランザクションの順番付けと構築を担当することになります。 +[提案者・ビルダー分離](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)(PBS)は、特にコンセンサスレイヤーにおけるMEVの影響を緩和するように設計されています。 PBSの主な機能は、ブロックの作成者と提案者に対するルールを分離することです。 バリデータがブロックの提案と投票に責任を負う点は変わりませんが、**ブロックビルダー**と呼ばれる専門の新たなエンティティ・クラスが導入され、トランザクションの順番付けと構築を担当することになります。 PBSでは、ブロックビルダーがトランザクションバンドルを作成し、ビーコンチェーン・ブロックへの追加に対して（「実行ペイロード」として）入札を行います。 次のブロック提案者として選択されたバリデータは、これを受けて、様々な入札をチェックし、最も高額な手数料のバンドルを選択します。 つまりPBSは、ブロックスペースの販売価格についてビルダーとバリデーターが交渉するオークション市場を構築するものです。 @@ -156,13 +156,13 @@ PBSでは、ブロックビルダーがトランザクションバンドルを ただし、ブロックビルダーはバリデータによる承認を得るために入札額を高くしなければならないため、バリデータにとってもMEVに伴う収益がまったくゼロになるわけではありません。 しかし、バリデータはMEVによる収益増を直接的な目標として行動しなくなるため、タイムバンディット攻撃の脅威を低下させることができます。 -PBSはさらに、MEVによる集中化のリスクを引き下げます。 例えば、コミット＝公開スキームにより、ブロックビルダーは、バリデータがMEVの抽出機会を奪い取ったり、他の構築者に公開することを行わないユーザーである信頼する必要がなくなります。 これにより、ソロステーカーがMEV抽出による利益を得る上での障壁が低くなります。そうでなければ、ブロックビルダーはオフチェーンでの評判が高い大規模なプールを選好し、オフチェーンでの取引が増加するトレンドが発生するでしょう。 +PBSはさらに、MEVによる集中化のリスクを引き下げます。 例えば、コミット＝公開スキームにより、ブロックビルダーは、バリデータがMEVの抽出機会を奪い取ったり、他の構築者に公開することを行わないユーザーである信頼する必要がなくなります。 これにより、ソロステーキングを行う人々がMEV（最大抽出可能価値）から恩恵を受ける上での障壁が下がります。そうでなければ、ビルダー（ブロック構築者）は、オフチェーンでの評判を持つ大規模なプールを優遇し、彼らとオフチェーン取引を行う傾向が強まるでしょう。 同じように、バリデータの側も、支払いが必須であるため、ブロックビルダーがブロックボディを秘匿したり、無効なブロックを公開しないユーザーである信頼する必要がなくなります。 つまり、提案されたブロックが参照できない場合や、他のバリデータにより無効と宣言された場合でも、当初のバリデータの手数料は処理されるのです。 他のバリデータが無効と宣言した場合、当該ブロックは単に破棄され、ブロックビルダーはすべての取引手数料およびMEV収益を失うことになります。 ### ビルダーAPI {#builder-api} -PBS（提案者と作成者の分離）は、MEVの抽出に伴う悪影響を減らす効果が期待される一方で、実装にはコンセンサス・プロトコルの変更が必要です。 具体的には、ビーコンチェーンにおける[分岐の選択](/developers/docs/consensus-mechanisms/pos/#fork-choice)ルールを変更する必要があります。 [ビルダーAPI](https://github.com/ethereum/builder-specs)は、信頼性の前提がより高くなるものの、提案者と作成者を実務的に分離するための一時的なソリューションです。 +PBS（提案者と作成者の分離）は、MEVの抽出に伴う悪影響を減らす効果が期待される一方で、実装にはコンセンサス・プロトコルの変更が必要です。 具体的には、ビーコンチェーンの[フォークチョイス](/developers/docs/consensus-mechanisms/pos/#fork-choice)ルールを更新する必要があります。 [ビルダーAPI](https://github.com/ethereum/builder-specs)は、より高い信頼性の仮定を伴うものの、提案者・ビルダー分離の実用的な実装を提供することを目的とした一時的なソリューションです。 ビルダーAPIは、コンセンサスレイヤーのクライアントが実行レイヤーのクライアントに対して実行ペイロードを請求する際に用いられる[エンジンAPI](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)の修正バージョンです。 [正直なバリデータの仕様](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md)に概要が記述されている通り、ブロック提案に関する職責のために選択されたバリデータは、接続された実行クライアントにトランザクションバンドルを要求し、そのバンドルを提案されたビーコンチェーンのブロックに追加します。 @@ -178,15 +178,16 @@ PBS（提案者と作成者の分離）は、MEVの抽出に伴う悪影響を 4. ビルダーAPIを実行しているビルダーは、ブラインドのブロック提案を確認した上で、完全な実行ペイロードで対応すると想定されています。 これにより、バリデータは「署名済み」のビーコンブロックを作成し、ネットワークに拡散することができます。 -5. ビルダーAPIを使用するバリデータの場合でも、ブロックビルダーが迅速に対応しない場合にブロック提案に伴う報酬が受け取れない場合を避けるために、ローカルでブロックを構築する必要があります。 しかしバリデータは、この時点で公開されたトランザクションあるいは他のセットを用いて別のブロックを作成することはできません。これは_曖昧化_（同じスロット内の2つのブロックに署名すること）を発生させるため、スラッシングの対象である違反行為です。 +5. ビルダーAPIを使用するバリデータの場合でも、ブロックビルダーが迅速に対応しない場合にブロック提案に伴う報酬が受け取れない場合を避けるために、ローカルでブロックを構築する必要があります。 しかし、バリデータは、公開されたトランザクションや別のセットを使って別のブロックを作成することはできません。これは_二重署名_(同じスロット内で2つのブロックに署名すること)に相当し、スラッシング対象の違反行為だからです。 -ビルダーAPIの実装例としては、イーサリアムに対するMEVの悪影響を軽減するように[フラッシュボットのオークション機能](https://docs.flashbots.net/Flashbots-auction/overview/)を改善した[MEV Boost](https://github.com/flashbots/mev-boost)があります。 フラッシュボットのオークションは、プルーフ・オブ・ステークにおいて、バリデータが利益を生むブロックの構築作業を、**サーチャー**と呼ばれる専門のパーティーに委託できる仕組みです。 +ビルダーAPIの実装例として、イーサリアムに対するMEVの悪影響を抑制するために設計された[Flashbotsオークションメカニズム](https://docs.flashbots.net/Flashbots-auction/overview)の改良版である[MEV Boost](https://github.com/flashbots/mev-boost)があります。 フラッシュボットのオークションは、プルーフ・オブ・ステークにおいて、バリデータが利益を生むブロックの構築作業を、**サーチャー**と呼ばれる専門のパーティーに委託できる仕組みです。 +![MEVフローを詳細に示す図](./mev.png) -サーチャーは、利益を生むMEVの機会を探し、ブロック提案者に対して、ブロックに含めてもらうための[シールドプライス入札](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction)と共にトランザクションバンドルを送ります。 MEV-gethを実行しているバリデータは、go-ethereum (Geth) クライアントのフォーク版で、最も利益の高いバンドルを選び、それを新しいブロックに含めるだけで済みます。 ブロック提案者 (バリデータ) をスパムや無効なトランザクションから保護するため、トランザクションバンドルは提案者に届く前に、**リレイヤー**を通じて検証されます。 +サーチャーは、利益を生むMEVの機会を探し、ブロック提案者に対して、ブロックに含めてもらうための[シールドプライス入札](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction)と共にトランザクションバンドルを送ります。 MEV-gethを実行しているバリデータは、go-ethereum (Geth) クライアントのフォーク版で、最も利益の高いバンドルを選び、それを新しいブロックに含めるだけで済みます。 ブロック提案者(バリデータ)をスパムや無効なトランザクションから保護するため、トランザクションバンドルは提案者に届く前に**リレイヤー**を通過して検証されます。 MEV Boostは、フラッシュボットにおける従来のオークションと同一の仕組みを採用していますが、イーサリアムにおけるプルーフ・オブ・ステークへの移行に対応した新機能が追加されています。 サーチャーが利益を伴うMEVトランザクションをブロックに追加しようとする点は同じですが、**ビルダー**と呼ばれる新たな専門ユーザーがトランザクションおよびバンドルをブロックにまとめる役割を担います。 ビルダーは、サーチャーから送信された非公開の入札価格を受け入れ、最適化を実行することで最も利益性が高い注文を決定します。 -ここでもリレイヤーは、提案者に送信する事前にトランザクションを検証する責任を負う点は変わりません。 しかしMEV Boostでは、ビルダーから送信されたブロックボディおよびバリデータから送信されたブロックヘッダーを保存することで、[データの可用性](/developers/docs/data-availability/)を提供する仕組みである**エスクロー**が導入されています。 エスクローでは、リレーに接続されたバリデータが利用可能な実行ペイロードを要求し、MEV Boostの注文アルゴリズムを用いて、入札価格およびMEVチップが最も高いペイロードヘッダーを選択します。 +ここでもリレイヤーは、提案者に送信する事前にトランザクションを検証する責任を負う点は変わりません。 しかしMEV Boostでは、ビルダーから送信されたブロックボディおよびバリデータから送信されたブロックヘッダーを保存することで[データの可用性](/developers/docs/data-availability/)を提供する仕組みである**エスクロー**が導入されています。 エスクローでは、リレーに接続されたバリデータが利用可能な実行ペイロードを要求し、MEV Boostの注文アルゴリズムを用いて、入札価格およびMEVチップが最も高いペイロードヘッダーを選択します。 #### ビルダーAPIは、どのようにMEVの悪影響を軽減するのか？ {#how-does-builder-api-curb-mev-impact} @@ -202,19 +203,19 @@ MEV Boostをはじめとするいくつかのプロジェクトでは、フロ ## 関連リソース {#related-resources} -- [フラッシュボット関連文書](https://docs.flashbots.net/) -- [フラッシュボットのGitHub](https://github.com/flashbots/pm) +- [Flashbotsドキュメント](https://docs.flashbots.net/) +- [Flashbots GitHub](https://github.com/flashbots/pm) - [mevboost.org](https://www.mevboost.org/) - _MEV-Boostリレーとブロックビルダーに関するリアルタイムの統計を提供するトラッカー_ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [採掘可能価値（MEV）とは何か？](https://blog.chain.link/what-is-miner-extractable-value-mev/) +- [マイナー抽出可能価値(MEV)とは何か？](https://blog.chain.link/what-is-miner-extractable-value-mev/) - [MEVと私](https://www.paradigm.xyz/2021/02/mev-and-me) -- [イーサリアムはダークな森である](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) -- [ダークな森から抜け出すには](https://samczsun.com/escaping-the-dark-forest/) -- [フラッシュボッツ: MEV危機をフロントランニングするには](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) -- [@bertcmillerのMEV関連スレッド](https://twitter.com/bertcmiller/status/1402665992422047747) -- [MEV-Boost: マージに対応したFlashbotsのアーキテクチャ](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) +- [イーサリアムは暗い森](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) +- [暗い森からの脱出](https://samczsun.com/escaping-the-dark-forest/) +- [Flashbots: MEVクライシスのフロントランニング](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) +- [@bertcmillerのMEVスレッド](https://twitter.com/bertcmiller/status/1402665992422047747) +- [MEV-Boost: マージ対応のFlashbotsアーキテクチャ](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) - [MEV Boostとは](https://www.alchemy.com/overviews/mev-boost) -- [mev-boostを実行する理由](https://writings.flashbots.net/writings/why-run-mevboost/) -- [イーサリアムへのヒッチハイク・ガイド](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) +- [なぜmev-boostを実行するのか？](https://writings.flashbots.net/writings/why-run-mevboost/) +- [イーサリアムヒッチハイク・ガイド](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/ja/developers/docs/networking-layer/index.md b/public/content/translations/ja/developers/docs/networking-layer/index.md index 9e51d590960..b32ac125909 100644 --- a/public/content/translations/ja/developers/docs/networking-layer/index.md +++ b/public/content/translations/ja/developers/docs/networking-layer/index.md @@ -1,6 +1,6 @@ --- -title: ネットワークレイヤー -description: イーサリアムネットワークレイヤー入門 +title: "ネットワークレイヤー" +description: "イーサリアムネットワークレイヤー入門" lang: ja sidebarDepth: 2 --- @@ -11,9 +11,9 @@ sidebarDepth: 2 実行クライアントは、実行レイヤーのピアツーピアネットワーク上でトランザクションをゴシップします。 これには、認証されたピア同士の暗号化通信が必要です。 ブロックを提案するバリデータが選ばれると、そのノードのローカルトランザクションプールからトランザクションがローカルRPC接続を介してコンセンサスクライアントに渡され、ビーコンブロックにパッケージ化されます。 コンセンサスクライアントはその後、ピアツーピアネットワーク上でビーコンブロックをゴシップします。 これは2つの別々のピアツーピアネットワークを必要とします。1つはトランザクションゴシップのための実行クライアントを接続するもので、もう1つはブロックゴシップのためのコンセンサスクライアントを接続するものです。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページを理解する上で、あらかじめ、イーサリアム [ノードとクライアント](/developers/docs/nodes-and-clients/) についてある程度理解を深めておくと良いでしょう。 +このページを理解するには、Ethereumの[ノードとクライアント](/developers/docs/nodes-and-clients/)に関する知識が役立ちます。 ## 実行レイヤー {#execution-layer} @@ -25,27 +25,27 @@ sidebarDepth: 2 両スタックは、並列的に動作します。 ディスカバリースタックは新しいネットワーク参加者をネットワークに送り込み、DevP2Pスタックによって相互通信が可能になります。 -### ディスカバリー(Discovery) {#discovery} +### ディスカバリー {#discovery} -ディスカバリーとは、ネットワークの他のノードを見つけるプロセスです。 これは、小規模なブートノード(クライアントをすぐに見つけピアに接続できるように、アドレスがクライアントに [ハードコードされている](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)ノード)を使用してブートストラップされています。 これらのブートノードは、新しいノードをピアのセットに追加するためにのみ存在します。これが唯一の目的で、チェーンの同期などの通常のクライアントタスクには参加せず、クライアントが初回起動した時にのみ使用されます。 +ディスカバリーとは、ネットワークの他のノードを見つけるプロセスです。 これは、少数のブートノード(アドレスがクライアントに[ハードコード](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)されているため、クライアントがすぐに見つけてピアに接続できるノード)のセットを使用してブートストラップされます。 これらのブートノードは、新しいノードをピアのセットに追加するためにのみ存在します。これが唯一の目的で、チェーンの同期などの通常のクライアントタスクには参加せず、クライアントが初回起動した時にのみ使用されます。 -ノードとブートノードとのやり取りに使用されるプロトコルは、[Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f)が修正された形式です。これは、[分散ハッシュテーブル](https://en.wikipedia.org/wiki/Distributed_hash_table)を使用してノードのリストを共有します。 各ノードには、最も近いピアに接続するために必要な情報を含む、分散ハッシュテーブルのバージョンがあります。 この「近さ」とは地理的なものではありません。ここでの距離はノードのIDの類似性によって定義されるものです。 各ノードのテーブルは、セキュリティ機能として定期的に更新されます。 例えば、 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5)では、ディスカバリープロトコルのノードは、クライアントがサポートするサブプロトコルを表示する「広告」を送信することもでき、ピアは両者が通信に使用できるプロトコルについて取り決めることができます。 +ノードとブートノード間のインタラクションに使用されるプロトコルは、[Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f)の修正版であり、[分散ハッシュテーブル](https://en.wikipedia.org/wiki/Distributed_hash_table)を使用してノードのリストを共有します。 各ノードには、最も近いピアに接続するために必要な情報を含む、分散ハッシュテーブルのバージョンがあります。 この「近さ」とは地理的なものではありません。ここでの距離はノードのIDの類似性によって定義されるものです。 各ノードのテーブルは、セキュリティ機能として定期的に更新されます。 例えば、[Discv5](https://github.com/ethereum/devp2p/tree/master/discv5)では、ディスカバリープロトコルのノードは、クライアントがサポートするサブプロトコルを表示する「広告」を送信することもでき、ピアは両者が通信に使用できるプロトコルについて取り決めることができます。 -ディスカバリーは、PING-PONGから始まります。 ピンポンが成功すると、新しいノードはブートノードに「結合」されます。 ネットワークに入る新しいノードの存在をブートノードに通知する最初のメッセージは `PING` です。 この`PING`には、新しいノード、ブートノード、および期限切れのタイムスタンプに関するハッシュ化された情報が含まれています。 ブートノードは`PING`を受信し、 `PING` のハッシュを含む`PONG`を返します。 `PING`と`PONG`のハッシュが一致すると、新しいノードとブートノードの接続が確認され、「結合」されたと言うことになります。 +ディスカバリーは、PING-PONGから始まります。 ピンポンが成功すると、新しいノードはブートノードに「結合」されます。 ネットワークに入る新しいノードの存在をブートノードに通知する最初のメッセージは`PING`です。 この`PING`には、新しいノード、ブートノード、および有効期限のタイムスタンプに関するハッシュ化された情報が含まれています。 ブートノードは`PING`を受信し、`PING`のハッシュを含む`PONG`を返します。 `PING`と`PONG`のハッシュが一致すると、新しいノードとブートノードの間の接続が検証され、両者は「ボンディングされた」と言われます。 -一度結合されると、新しいノードはブートノードに`FIND-NEIGHBOURS`リクエストを送信できるようになります。 ブートノードから返されるデータには、新しいノードが接続できるピアのリストが含まれています。 ノードが結合されていない場合、`FIND-NEIGHBOURS`リクエストは失敗となるため、新しいノードはネットワークに入ることができません。 +一度ボンディングされると、新しいノードは`FIND-NEIGHBOURS`リクエストをブートノードに送信できます。 ブートノードから返されるデータには、新しいノードが接続できるピアのリストが含まれています。 ノードがボンディングされていない場合、`FIND-NEIGHBOURS`リクエストは失敗するため、新しいノードはネットワークに参加できません。 新しいノードは、ブートノードから近隣ノードのリストを受け取ると、それぞれのノードとPING-PONGを開始します。 PING-PONGが成功すると、新しいノードとその隣接ノードが結合され、メッセージの交換が可能になります。 ``` -start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours +クライアント起動 --> ブートノードに接続 --> ブートノードにボンディング --> 隣接ノードを発見 --> 隣接ノードにボンディング ``` -実行クライアントは、現在[Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md)ディスカバリープロトコルを使っています。[Discv5](https://github.com/ethereum/devp2p/tree/master/discv5)プロトコルに移行するための積極的に取り組んでいます。 +実行クライアントは現在、[Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md)ディスカバリープロトコルを使用しており、[Discv5](https://github.com/ethereum/devp2p/tree/master/discv5)プロトコルへの移行が活発に行われています。 -#### ENR: イーサリアムノードレコード(Ethereum Node Record) {#enr} +#### ENR: イーサリアムノードレコード {#enr} -[イーサリアムノードレコード (ENR)](/developers/docs/networking-layer/network-addresses/) とは、署名(合意された 認証スキームに従って作成されたレコード内容のハッシュ)、レコードへの変更を追跡するシーケンス番号、およびキーと値のペアの任意のリストという3つの基本要素を含むオブジェクトのことです。 これは、新しいピア間で識別情報の交換を容易にする、将来性のあるフォーマットで、イーサリアムノードの[ネットワークアドレス](/developers/docs/networking-layer/network-addresses)の優先フォーマットです。 +[イーサリアムノードレコード(ENR)](/developers/docs/networking-layer/network-addresses/)は、署名(合意されたアイデンティティスキームに従って作成されたレコードコンテンツのハッシュ)、レコードへの変更を追跡するシーケンス番号、そしてキー:値ペアの任意のリスト、という3つの基本要素を含むオブジェクトです。 これは、新しいピア間で識別情報を容易に交換できる将来性のあるフォーマットであり、Ethereumノードで推奨される[ネットワークアドレス](/developers/docs/networking-layer/network-addresses/)フォーマットです。 #### ディスカバリーがUDPで構築されている理由 {#why-udp} @@ -53,7 +53,7 @@ UDPはエラーチェック、失敗したパケットの再送、接続の動 ### DevP2P {#devp2p} -DevP2Pは、それ自体がピアツーピアネットワークの確立と維持するためにイーサリアムが実装しているプロトコルのスタックをすべてを包括しています。 新しいノードがネットワークに参加した後、その相互通信は[DevP2P](https://github.com/ethereum/devp2p)スタックのプロトコルによって制御されます。 これらはすべてTCP上にあり、RLPxトランスポートプロトコル、ワイヤプロトコル、およびいくつかのサブプロトコルが含まれています。 [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md)は、ノード間のセッションを開始、認証、維持するためのプロトコルです。 RLPxはデータをノード間で送信するための最小限の構造にエンコードする非常にスペース効率の良いRLP (再帰的な長さのプレフィックス)を使ってメッセージをエンコードします。 +DevP2Pは、それ自体がピアツーピアネットワークの確立と維持するためにイーサリアムが実装しているプロトコルのスタックをすべてを包括しています。 新しいノードがネットワークに参加した後、その相互作用は[DevP2P](https://github.com/ethereum/devp2p)スタックのプロトコルによって規定されます。 これらはすべてTCP上にあり、RLPxトランスポートプロトコル、ワイヤプロトコル、およびいくつかのサブプロトコルが含まれています。 [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md)は、ノード間のセッションを開始、認証、維持するためのプロトコルです。 RLPxはデータをノード間で送信するための最小限の構造にエンコードする非常にスペース効率の良いRLP (再帰的な長さのプレフィックス)を使ってメッセージをエンコードします。 2つのノード間のRLPxセッションは、最初の暗号化ハンドシェイクで始まります。 このプロセスには、ノードがauthメッセージを送信し、ピアによって検証されることが含まれます。 検証に成功すると、ピアはauth-acknowledgementメッセージを生成し、イニシエーター・ノードに返します。 これは、ノードが非公開で安全に通信できるようにするための鍵交換プロセスです。 暗号化ハンドシェイクが成功すると、両ノードに「Hello」メッセージを互いに「ワイヤ上」で送信するようにトリガーします。 Helloメッセージの交換に成功すると、ワイヤプロトコルが開始されます。 @@ -71,47 +71,47 @@ Helloメッセージには以下が含まれます。 ### サブプロトコル {#sub-protocols} -#### ワイヤプロトコル {#wire-protocol} +#### ワイヤープロトコル {#wire-protocol} -ピアが接続され、RLPxセッションが開始されると、ワイヤプロトコルはピアがどのように通信するかを定義します。 当初、ワイヤプロトコルは、チェーンの同期、ブロックの伝搬、トランザクションの交換という3つの主要なタスクを定義していました。 しかし、イーサリアムがプルーフ・オブ・ステーク(PoS)に移行すると、ブロック伝搬とチェーン同期はコンセンサスレイヤーの一部となりました。 トランザクションの交換は、依然として実行クライアントの範疇にあります。 トランザクション交換とは、ノード間で保留中のトランザクションを交換し、ブロックビルダーが次のブロックに含めるためにそれらの一部を選択できるようにすることを指します。 これらのタスクの詳細については、[こちら](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)をご覧ください。 これらのサブプロトコルをサポートするクライアントは、[JSON-RPC](/developers/docs/apis/json-rpc/)を介してそれらを公開します。 +ピアが接続され、RLPxセッションが開始されると、ワイヤプロトコルはピアがどのように通信するかを定義します。 当初、ワイヤプロトコルは、チェーンの同期、ブロックの伝搬、トランザクションの交換という3つの主要なタスクを定義していました。 しかし、イーサリアムがプルーフ・オブ・ステーク(PoS)に移行すると、ブロック伝搬とチェーン同期はコンセンサスレイヤーの一部となりました。 トランザクションの交換は、依然として実行クライアントの範疇にあります。 トランザクション交換とは、ノード間で保留中のトランザクションを交換し、ブロックビルダーが次のブロックに含めるためにそれらの一部を選択できるようにすることを指します。 これらのタスクに関する詳細情報は、[こちら](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)でご覧いただけます。 これらのサブプロトコルをサポートするクライアントは、[JSON-RPC](/developers/docs/apis/json-rpc/)を介してそれらを公開します。 -#### ライト・イーサリアム・サブプロトコル(les) {#les} +#### les (ライトイーサリアムサブプロトコル) {#les} -これは、ライトクライアントの同期用の最小限のプロトコルです。 フルノードはインセンティブなしにライトクライアントにデータを提供する必要があるため、従来このプロトコルはほとんど使用されてきませんでした。 実行クライアントのデフォルトの動作は、lesでライトクライアントのデータを提供しないようになっています。 詳細については、les [仕様](https://github.com/ethereum/devp2p/blob/master/caps/les.md)をご確認ください。 +これは、ライトクライアントの同期用の最小限のプロトコルです。 フルノードはインセンティブなしにライトクライアントにデータを提供する必要があるため、従来このプロトコルはほとんど使用されてきませんでした。 実行クライアントのデフォルトの動作では、lesを介してライトクライアントデータを提供しません。 詳細は、lesの[仕様](https://github.com/ethereum/devp2p/blob/master/caps/les.md)でご覧いただけます。 -#### スナップ(Snap) {#snap} +#### Snap {#snap} -[スナッププロトコル](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap)は、ピアが最近の状態のスナップショットを交換できるようにするオプションの拡張機能で、ピアがマークルツリーの中間ノードをダウンロードせずにアカウントとストレージデータを検証できるようにするものです。 +[snapプロトコル](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap)は、ピアが最近の状態のスナップショットを交換できるようにするオプションの拡張機能で、ピアがマークルツリーの中間ノードをダウンロードすることなくアカウントとストレージのデータを検証できるようにします。 -#### ウィットネスプロトコル(Wit) {#wit} +#### Wit (ウィットネスプロトコル) {#wit} -[ウィットネスプロトコル](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) は、ピア間で状態のウィットネスを交換できるようにするオプションの拡張機能で、クライアントをチェーンの先頭に同期させるのに役立ちます。 +[ウィットネスプロトコル](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit)は、ピア間で状態のウィットネスを交換できるオプションの拡張機能で、クライアントをチェーンの先端に同期させるのに役立ちます。 -#### ウィスパー(Whisper) {#whisper} +#### Whisper {#whisper} -ウィスパーは、ブロックチェーンに情報を書き込むことなくピア間で安全なメッセージングを提供することを目的としたプロトコルです。 DevP2Pワイヤープロトコルの一部でしたが、現在は非推奨となっています。 他にも同様の目的を持つ[関連プロジェクト](https://wakunetwork.com/)があります。 +ウィスパーは、ブロックチェーンに情報を書き込むことなくピア間で安全なメッセージングを提供することを目的としたプロトコルです。 DevP2Pワイヤープロトコルの一部でしたが、現在は非推奨となっています。 同様の目的を持つ、その他の[関連プロジェクト](https://wakunetwork.com/)も存在します。 -## コンセンサスレイヤー(consensus layer) {#consensus-layer} +## コンセンサスレイヤー {#consensus-layer} コンセンサスクライアントは、仕様が異なる別のピアツーピアネットワークに参加します。 コンセンサスクライアントは、ピアから新しいブロックを受け取り、自分がブロックを提案する番が来たらブロードキャストできるよう、ブロック・ゴシップに参加する必要があります。 実行レイヤーと同様に、ノードがピアを見つけてブロックや認証などを取引するための安全なセッションを確立できるよう、まずディスカバリー・プロトコルが必要です。 -### ディスカバリ {#consensus-discovery} +### ディスカバリー {#consensus-discovery} -実行クライアントと同様に、コンセンサスクライアントもピアを見つけるためにUDP上の [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) を使用します。 コンセンサスレイヤーのdiscv5の実装は、discv5を[libP2P](https://libp2p.io/)スタックに接続するアダプターを含んでおり、DevP2Pを非推奨としている点のみ、実行クライアントの実装と異なります。 実行レイヤーのRLPxセッションは廃止され、libP2Pのノイズセキュアチャネル・ハンドシェイクが採用されています。 +実行クライアントと同様に、コンセンサスクライアントはピアを見つけるために、UDP上で[discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5)を使用します。 コンセンサスレイヤーにおけるdiscv5の実装は、discv5を[libP2P](https://libp2p.io/)スタックに接続するアダプターを含み、DevP2Pを非推奨にしているという点でのみ、実行クライアントの実装と異なります。 実行レイヤーのRLPxセッションは廃止され、libP2Pのノイズセキュアチャネル・ハンドシェイクが採用されています。 ### ENR {#consensus-enr} -コンセンサスノードのENRには、ノードの公開鍵、IPアドレス、UDPおよび TCP ポート、コンセンサス特有の2つのフィールド(認証サブネットビットフィールドと`eth2`)が含まれます。 前者は、ノードが特定の認証ゴシップ・サブネットワークに参加しているピアを見つけやすくします。 `eth2`キーには、ノードが使用しているイーサリアムフォークのバージョンに関する情報が含まれており、ピアが正しいイーサリアムに接続していることを確認できます。 +コンセンサスノードのENRには、ノードの公開鍵、IPアドレス、UDPポートおよびTCPポート、そして2つのコンセンサス固有のフィールド(アテステーションサブネットビットフィールドと`eth2`キー)が含まれます。 前者は、ノードが特定の認証ゴシップ・サブネットワークに参加しているピアを見つけやすくします。 `eth2`キーには、ノードが使用しているEthereumのフォークバージョンに関する情報が含まれており、ピアが正しいEthereumに接続していることを保証します。 ### libP2P {#libp2p} libP2Pスタックは、ディスカバリー後のすべての通信をサポートします。 クライアントは、ENRで定義されたIPv4および/またはIPv6でダイヤルおよびリッスンできます。 libP2Pレイヤーのプロトコルは、ゴシップとリクエスト/レスポンスのドメインに細分化されます。 -### ゴシップ(Gossip) {#gossip} +### ゴシップ {#gossip} -ゴシップドメインは、ネットワーク全体に直ぐに広まる必要のあるすべての情報を含みます。 これには、ビーコンブロック、証明、アテステーション、イグジット、スラッシングが含まれます。 これはlibP2Pゴシップサブ v1を使って送信され、受信・送信するゴシップペイロードの最大サイズなどの各ノードにローカルに保存されている様々なメタデータに依存します。 ゴシップドメインに関する詳細な情報は、[こちら](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)をご覧ください。 +ゴシップドメインは、ネットワーク全体に直ぐに広まる必要のあるすべての情報を含みます。 これには、ビーコンブロック、証明、アテステーション、イグジット、スラッシングが含まれます。 これはlibP2Pゴシップサブ v1を使って送信され、受信・送信するゴシップペイロードの最大サイズなどの各ノードにローカルに保存されている様々なメタデータに依存します。 ゴシップドメインに関する詳細情報は、[こちら](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)でご覧いただけます。 -### リクエスト/レスポンス(Request-response) {#request-response} +### リクエスト/レスポンス {#request-response} リクエスト/レスポンス・ドメインには、クライアントがピアに特定の情報を要求するためのプロトコルが含まれます。 例えば、あるルートハッシュに一致する特定のビーコンブロックや、スロット範囲内のビーコンブロックのリクエストなどがあります。 レスポンスは常にsnappy(圧縮アルゴリズムの一つ)圧縮されたSSZエンコードバイトとして返されます。 @@ -121,23 +121,23 @@ SSZは、シンプル・シリアライゼーションの略です。 SSZは、 ## 実行クライアントとコンセンサスクライアントの接続 {#connecting-clients} -コンセンサスクライアントと実行クライアントは、並列に動作します。 コンセンサスクライアントが実行クライアントに指示を出し、実行クライアントがコンセンサスクライアントにトランザクション・バンドルを渡してビーコンブロックに含めることができるように、両者は接続されている必要があります。 両クライアント間の通信は、ローカルRPC接続を使用して実現することができます。 [「エンジンAPI」](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) と呼ばれるAPIが、両クライアント間で送信される命令を定義します。 両クライアントは単一のネットワークIDの背後に位置するため、各クライアントの個別のキー(eth1キーとeth2キー)を含むENR(イーサリアムノードレコード)を共有します。 +コンセンサスクライアントと実行クライアントは、並列に動作します。 コンセンサスクライアントが実行クライアントに指示を出し、実行クライアントがコンセンサスクライアントにトランザクション・バンドルを渡してビーコンブロックに含めることができるように、両者は接続されている必要があります。 両クライアント間の通信は、ローカルRPC接続を使用して実現することができます。 ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)として知られるAPIは、2つのクライアント間で送信される命令を定義します。 両クライアントは単一のネットワークIDの背後に位置するため、各クライアントの個別のキー(eth1キーとeth2キー)を含むENR(イーサリアムノードレコード)を共有します。 制御フローの概要を以下に示します。括弧内は関連するネットワークスタックです。 -### コンセンサスクライアントがブロック生成者でない場合: {#when-consensus-client-is-not-block-producer} +### コンセンサスクライアントがブロックプロデューサーではない場合: {#when-consensus-client-is-not-block-producer} - コンセンサスクライアントがブロック・ゴシップ・プロトコル(コンセンサスp2p)を介してブロックを受信する -- コンセンサスクライアントはブロックを事前に検証し、確正しいメタデータを持つ有効な送信者からのものであることを確実にする +- コンセンサスクライアントはブロックを事前検証します。つまり、ブロックが正しいメタデータを持つ有効な送信者から送られてきたことを確認します。 - ブロックのトランザクションが実行ペイロードとして実行レイヤーに送信される(ローカルRPC接続) -- 実行レイヤーはトランザクションを実行し、ブロックヘッダーの状態を検証する(ハッシュ値の一致をチェックする) +- 実行レイヤーはトランザクションを実行し、ブロックヘッダーの状態を検証します (つまり、ハッシュが一致するかをチェックします)。 - 実行レイヤーは検証データをコンセンサスレイヤーに返し、ブロックは検証済みとみなされる(ローカルRPC接続) - コンセンサスレイヤーはブロックを自分のブロックチェーンの先頭に追加して証明し、そのアテステーション(証明)をネットワーク上にブロードキャストする(コンセンサスp2p) -### コンセンサスクライアントがブロック生成者の場合: {#when-consensus-client-is-block-producer} +### コンセンサスクライアントがブロックプロデューサーである場合: {#when-consensus-client-is-block-producer} - コンセンサスクライアントが次のブロック生成者であることを通知される(consensus p2p) -- コンセンサスレイヤーが実行クライアントの`create block`メソッドを呼び出す(ローカルRPC) +- コンセンサスレイヤーが実行クライアントの`create block`メソッドを呼び出す (ローカルRPC) - 実行レイヤーは、トランザクション・ゴシップ・プロトコルによって生成されたトランザクション・メンプールにアクセスする(実行p2p) - 実行クライアントはトランザクションをブロックにまとめ、トランザクションを実行し、ブロックハッシュを生成する - コンセンサスクライアントは実行クライアントからトランザクションとブロックハッシュを取得し、ビーコンブロックに追加する(ローカルRPC) @@ -146,10 +146,18 @@ SSZは、シンプル・シリアライゼーションの略です。 SSZは、 十分な数のバリデータによってブロックが認証されると、チェーンの先頭に追加され、正当性が確認された後、最終的に確定(ファイナライズ)される。 -![](cons_client_net_layer.png) ![](exe_client_net_layer.png) +![](cons_client_net_layer.png) +![](exe_client_net_layer.png) -コンセンサスクライアントと実行クライアントのネットワークレイヤー概略図( [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) より) +[ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)より、コンセンサスクライアントと実行クライアントのネットワークレイヤー概略図 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [コンセンサスレイヤーネットワークの仕様](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [カデムリアからdiscv5](https://vac.dev/kademlia-to-discv5) [カデムリアペーパー](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [Ethereumピアツーピア入門](https://p2p.paris/en/talks/intro-ethereum-networking/) [eth1eth2の関係](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [マージとeth2クライアントの詳細に関するビデオ](https://www.youtube.com/watch?v=zNIrIninMgg) +[DevP2P](https://github.com/ethereum/devp2p) +[LibP2p](https://github.com/libp2p/specs) +[コンセンサスレイヤーのネットワーク仕様](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) +[KademliaからDiscv5へ](https://vac.dev/kademlia-to-discv5) +[Kademliaに関する論文](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) +[Ethereum P2P入門](https://p2p.paris/en/talks/intro-ethereum-networking/) +[eth1とeth2の関係](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) +[マージとeth2クライアント詳細に関するビデオ](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/ja/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/ja/developers/docs/networking-layer/network-addresses/index.md index 7cae98de21e..8d4c8cbd819 100644 --- a/public/content/translations/ja/developers/docs/networking-layer/network-addresses/index.md +++ b/public/content/translations/ja/developers/docs/networking-layer/network-addresses/index.md @@ -1,17 +1,17 @@ --- -title: ネットワークアドレス -description: ネットワークアドレス入門 +title: "ネットワークアドレス" +description: "ネットワークアドレス入門" lang: ja sidebarDepth: 2 --- イーサリアムノードがピアに接続するには、いくつかの基本情報で自分自身を識別する必要があります。 潜在的なピアがこの情報を解釈できるようにするため、イーサリアムノードが理解できる3つの標準化されたフォーマット(multiaddr、enode、イーサリアム・ノード・レコード(ENR))のいずれかで伝えられます。 なお、イーサリアム・ノード・レコード(ENR)はイーサリアム・ネットワークアドレスの現在の標準です。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページを理解するためには、イーサリアムの [ネットワークレイヤー](/developers/docs/networking-layer/) についてある程度理解している必要があります。 +このページを理解するためには、イーサリアムの[ネットワーキングレイヤー](/developers/docs/networking-layer/)についてある程度理解している必要があります。 -## マルチアドレス(Multiaddr) {#multiaddr} +## Multiaddr {#multiaddr} 元々、イーサリアムノードのアドレス形式は「multiaddr」(マルチアドレスの略)でした。 Multiaddrは、ピアツーピアネットワーク用に設計された汎用フォーマットです。 アドレスは、キーと値をスラッシュで区切ったkey-valueのペアで表現されます。 例えば、IPv4アドレス`192.168.22.27`でTCPポート`33000`をリッスンしているノードのmultiaddrは、次のようになります。 @@ -21,19 +21,19 @@ sidebarDepth: 2 `/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` -## enode {#enode} +## Enode {#enode} enodeとは、URLアドレス形式を用いたイーサリアムノードの識別方法です。 16進数のノードIDは、URLのユーザーネーム部分がエンコードされ、@記号を用いてホストと区切られます。 ホスト名にはIPアドレスのみを指定することができ、DNS名は指定できません。 ホスト名セクションのポートは、TCPリスニングポートです。 TCPポートとUDP(ディスカバリー)ポートが異なる場合は、UDPポートをクエリパラメータ 「discport 」で指定します。 -次の例では、ノードURLはIPアドレス`10.3.58.6`、TCPポート`30303`、UDPディスカバリーポート `30301`のノードを記述しています。 +次の例では、ノードURLはIPアドレス`10.3.58.6`、TCPポート`30303`、UDPディスカバリーポート`30301`のノードを記述しています。 `enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` ## イーサリアム・ノード・レコード(ENR) {#enr} -イーサリアム・ノード・レコード(ENR) は、イーサリアム 上のネットワークアドレス用に標準化されたフォーマットです。 ENRは、multiaddrとenodeに取って代わるものです。 ENRはノード間でより大きな情報交換を可能にするため、特に有用です。 ENRには署名、シーケンス番号、および署名の生成と検証に使用されるIDスキームの詳細を示すフィールドが含まれます。 ENRには、key-valueペアとして編成された任意のデータを入力することも可能です。 これらのkey-valueペアには、ノードのIPアドレスと、ノードが使用できるサブプロトコルの情報が含まれています。 コンセンサスクライアントは、ブートノードを特定するために [固有のENR構造](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)を使用し、現在のイーサリアムフォークとアテステーション(認証)ゴシップサブネットに関する情報を含む`eth2`フィールドを含みます(これにより、アテステーションが集約されている特定のピアセットにノードを接続します)。 +イーサリアム・ノード・レコード(ENR) は、イーサリアム 上のネットワークアドレス用に標準化されたフォーマットです。 ENRは、multiaddrとenodeに取って代わるものです。 ENRはノード間でより大きな情報交換を可能にするため、特に有用です。 ENRには署名、シーケンス番号、および署名の生成と検証に使用されるIDスキームの詳細を示すフィールドが含まれます。 ENRには、key-valueペアとして編成された任意のデータを入力することも可能です。 これらのkey-valueペアには、ノードのIPアドレスと、ノードが使用できるサブプロトコルの情報が含まれています。 コンセンサスクライアントは、ブートノードを特定するために[特定のENR構造](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)を使用し、現在のイーサリアムフォークとアテステーションゴシップサブネットに関する情報を含む`eth2`フィールドも持ちます（これによりノードは、アテステーションが集約される特定のピアのセットに接続されます）。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [EIP-778: イーサリアム・ノード・レコード(ENR)](https://eips.ethereum.org/EIPS/eip-778) - [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/ja/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/ja/developers/docs/networking-layer/portal-network/index.md index 920f7b9a3f0..72963d394c5 100644 --- a/public/content/translations/ja/developers/docs/networking-layer/portal-network/index.md +++ b/public/content/translations/ja/developers/docs/networking-layer/portal-network/index.md @@ -1,6 +1,6 @@ --- -title: ポータルネットワーク -description: リソースが少ないクライアントをサポートするように設計され、現在開発中のネットワークである「ポータルネットワーク」の概要 +title: "ポータルネットワーク" +description: "リソースが少ないクライアントをサポートするように設計され、現在開発中のネットワークである「ポータルネットワーク」の概要" lang: ja --- @@ -10,25 +10,25 @@ lang: ja ポータルネットワークは、イーサリアムにおける新たなネットワーク設計です。フルノードを信頼することなく、余計な負担をかけずに、必要なデータをネットワーク全体で小さな塊に分けて共有することで、「ライト」ノードのデータ可用性問題を解決することを目指しています。 -[ノードとクライアントの詳細](/developers/docs/nodes-and-clients/) +[ノードとクライアント](/developers/docs/nodes-and-clients/)に関する詳細 ## ポータルネットワークが必要な理由 {#why-do-we-need-portal-network} イーサリアムノードは、イーサリアムブロックチェーンの全部または一部のコピーを保存します。 このローカルコピーを使って、トランザクションを検証し、ノードが正しいチェーンに進むよう徹底します。 また、このローカルに保存したデータにより、受信データが有効かつ正当であることを、他のエンティティを信頼せずに独立して検証できます。 -ブロックチェーンのローカルコピーや、それに関連付いた状態およびレシートデータなどは、ノードのハードディスク容量を大量に消費します。 例えば、コンセンサスクライアントをペアにした[Geth](https://geth.ethereum.org)ノードを立ち上げるには、2 TBのハードディスクが推奨されています。 スナップ同期を使用すると、比較的最近のブロックのセットがもつチェーンデータのみを保存しますが、Gethでは一般的に、約650 GBのディスク容量を使います。また、一週間で約14 GB増加します(ノードを定期的に650 GBへプルーニングできます)。 +ブロックチェーンのローカルコピーや、それに関連付いた状態およびレシートデータなどは、ノードのハードディスク容量を大量に消費します。 例えば、コンセンサスクライアントとペアリングした[Geth](https://geth.ethereum.org)を使用してノードを実行するには、2TBのハードディスクが推奨されます。 スナップ同期を使用すると、比較的最近のブロックのセットがもつチェーンデータのみを保存しますが、Gethでは一般的に、約650 GBのディスク容量を使います。また、一週間で約14 GB増加します(ノードを定期的に650 GBへプルーニングできます)。 -イーサリアムでは大容量のディスクスペースを必要とするため、ノードを立ち上げるには高額な費用がかかる可能性があります。 一方、[履歴の有効期限](/roadmap/statelessness/#history-expiry)、[状態の有効期限](/roadmap/statelessness/#state-expiry)、[ステートレス](/roadmap/statelessness/)など、この問題に対するいくつかの解決策がイーサリアムのロードマップに記載されています。 しかし、これらの解決策の実装には数年を要すると考えられています。 また、チェーンデータのコピーを自身で保存せず、必要なデータをフルノードへリクエストする[ライトノード](/developers/docs/nodes-and-clients/light-clients/)があります。 ただし、ライトノードは正直なデータを提供するためにフルノードを信頼する必要があり、フルノードはライトノードが必要とするデータを提供しなければならないため負荷がかかります。 +イーサリアムでは大容量のディスクスペースを必要とするため、ノードを立ち上げるには高額な費用がかかる可能性があります。 この問題に対しては、イーサリアムのロードマップ上に、[履歴の有効期限切れ](/roadmap/statelessness/#history-expiry)、[ステートの有効期限切れ](/roadmap/statelessness/#state-expiry)、[ステートレス性](/roadmap/statelessness/)など、いくつかの解決策があります。 しかし、これらの解決策の実装には数年を要すると考えられています。 また、自身のチェーンデータのコピーを保存せず、フルノードから必要なデータを要求する[ライトノード](/developers/docs/nodes-and-clients/light-clients/)もあります。 ただし、ライトノードは正直なデータを提供するためにフルノードを信頼する必要があり、フルノードはライトノードが必要とするデータを提供しなければならないため負荷がかかります。 ポータルネットワークは、ライトノードがデータを取得する代替方法を提供することを目指しています。この方法では、フルノードを信頼する必要がなく、フルノードで実行する処理を大幅に追加する必要もありません。 イーサリアムノードがネットワーク全体でデータを共有する新たな方法を導入することで、これを実現します。 ## ポータルネットワークの仕組み {#how-does-portal-network-work} -厳密なプロトコルによって、イーサリアムノードが相互に通信する方法が定義されています。 実行クライアントは、[DevP2P](/developers/docs/networking-layer/#devp2p)と呼ばれるサブプロトコルのセットを使用して通信します。一方、コンセンサスクライアントは、[libP2P](/developers/docs/networking-layer/#libp2p)と呼ばれる別のサブプロトコルのスタックを使用します。 これらのプロトコルは、ノード間で受け渡せるデータのタイプを定義します。 +厳密なプロトコルによって、イーサリアムノードが相互に通信する方法が定義されています。 実行クライアントは[DevP2P](/developers/docs/networking-layer/#devp2p)として知られるサブプロトコルのセットを使用して通信する一方、コンセンサスクライアントは[libP2P](/developers/docs/networking-layer/#libp2p)と呼ばれるサブプロトコルの異なるスタックを使用します。 これらのプロトコルは、ノード間で受け渡せるデータのタイプを定義します。 -![devP2PおよびlibP2P](portal-network-devp2p-libp2p.png) +![devP2PとlibP2P](portal-network-devp2p-libp2p.png) -ノードは、[JSON-RPC API](/developers/docs/apis/json-rpc/)を通して特定のデータを提供することもできます。このAPIにより、アプリやウォレットは、イーサリアムノードと情報を交換できます。 しかし、ライトクライアントへデータを提供する理想的なプロトコルは存在していません。 +ノードは[JSON-RPC API](/developers/docs/apis/json-rpc/)を介して特定のデータを提供することもでき、これによってアプリやウォレットはイーサリアムノードと情報を交換します。 しかし、ライトクライアントへデータを提供する理想的なプロトコルは存在していません。 現状では、ライトクライアントは、DevP2PまたはlibP2pを使って、特定のチェーンデータの一部分をリクエストすることができません。これらのプロトコルは、チェーンの同期、ブロックとトランザクションのゴシップのみを目的に設計されているからです。 ライトクライアントがこの情報をダウンロードすると、クライアントが「ライト」でなくなるため、適切ではありません。 @@ -36,7 +36,7 @@ JSON-RPC APIは、ライトクライアントのデータリクエストに理 ポータルネットワークのポイントとしては、既存のイーサリアムクライアントの設計制約を除き、全体を再設計し、軽量化に焦点を合わせて構築することです。 -ポータルネットワークのコアとなるアイデアは、現在のネットワークスタックの最良の部分を活用することです。これを実現するには、[DHT](https://en.wikipedia.org/wiki/Distributed_hash_table)(Bittorrentと類似)を使って、履歴データや現在のチェーンヘッドのアイデンティティを軽量のDevP2P形式のピアツーピア分散型ネットワークを介して提供し、ライトクライアントによって必要とされる情報を有効化します。 +ポータルネットワークの核となるアイデアは、[DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (Bittorrentに類似) を使用した軽量なDevP2Pスタイルのピアツーピア分散型ネットワークを介して、履歴データや現在のチェーンのヘッドのアイデンティティなど、ライトクライアントが必要とする情報を提供できるようにすることで、現在のネットワーキングスタックの最良の部分を取り入れることです。 このアイデアは、各ノードにイーサリアム全体の履歴データの一部を割り当て、特定の具体的な役割を追加することです。 その結果、リクエストされた特定のデータが保存されているノードを探し出し、そのデータを取得して提供することができます。 @@ -48,36 +48,42 @@ JSON-RPC APIは、ライトクライアントのデータリクエストに理 - 直近と過去のチェーンデータの同期 - 状態データの検索 - トランザクションのブロードキャスト -- [EVM](/developers/docs/evm/)を使ったトランザクションの実行 +- [EVM](/developers/docs/evm/)を使用してトランザクションを実行 このネットワーク設計による利点は、次の通りです。 - 集中化したプロバイダーへの依存が減る - インターネット帯域使用量が減る - 同期が短くなる、または同期が不要になる -- リソースが限られたデバイス (1GB未満のRAM、100MB未満のディスクスペース、1つのCPU) でもアクセス可能です。 +- リソースに制約のあるデバイス (<1 GB RAM、<100 MB ディスク容量、1 CPU) でアクセス可能 -以下の図は、ポータルネットワークでやり取りできる現行のクライアントの機能を示しています。ユーザーは、非常に少ないリソースのデバイスでも、これらの機能にアクセスできます。 +以下の表は、ポータルネットワークによって提供される既存クライアントの機能を示しており、ユーザーは非常にリソースの少ないデバイスでこれらの機能にアクセスできます。 -![ポータルネットワークテーブル](portal-network-table2.png) +### ポータルネットワーク -## デフォルトのクライアント多様性 {#client-diversity-as-default} +| ビーコンライトクライアント | 状態ネットワーク | トランザクションゴシップ | ヒストリーネットワーク | +| ------------- | ------------------- | ------------ | ----------- | +| ビーコンチェーンライト | アカウントおよびコントラクトストレージ | 軽量メンプール | ヘッダー | +| プロトコルデータ | | | ブロックボディ | +| | | | レシート | -ポータルネットワークのデベロッパーは、最初から3種類のポータルネットワーククライアントを構築することを決めていました。 +## デフォルトでのクライアントの多様性 {#client-diversity-as-default} + +ポータルネットワークの開発者はまた、初日から4つの個別のポータルネットワーククライアントを構築するという設計上の選択をしました。 ポータルネットワークのクライアントは、以下の通りです。 -- [Trin](https://github.com/ethereum/trin): Rustで開発 -- [Fluffy](https://nimbus.team/docs/fluffy.html): Nimで開発 -- [Ultralight](https://github.com/ethereumjs/ultralight): Typescriptで開発 -- [Shisui](https://github.com/GrapeBaBa/shisui): Go言語で開発 +- [Trin](https://github.com/ethereum/trin): Rustで記述 +- [Fluffy](https://fluffy.guide): Nimで記述 +- [Ultralight](https://github.com/ethereumjs/ultralight): Typescriptで記述 +- [Shisui](https://github.com/zen-eth/shisui): Goで記述 依存しないクライアント実装が複数存在することで、イーサリアムネットワークの回復力と分散化が強化されます。 1つのクライアントに問題や脆弱性が生じても、他のクライアントは通常通り運用を続けられるため、単一障害点を防ぐことができます。 また、多様なクライアントの実装により、イノベーションと競争が促進されるだけでなく、エコシステム内の改善が促進され、単一文化によるリスクが軽減されます。 -## 参考文献 {#futher-reading} +## 参考リンク {#further-reading} -- [ポータルネットワーク(ボゴタ開発者会議でのPiper Merriamによる発表)](https://www.youtube.com/watch?v=0stc9jnQLXA) +- [ポータルネットワーク (Devcon BogotaでのPiper Merriam氏による講演)](https://www.youtube.com/watch?v=0stc9jnQLXA)。 - [ポータルネットワークのDiscord](https://discord.gg/CFFnmE7Hbs) - [ポータルネットワークのウェブサイト](https://www.ethportal.net/) diff --git a/public/content/translations/ja/developers/docs/networks/index.md b/public/content/translations/ja/developers/docs/networks/index.md index 0ef8b4aecf2..a2e03f03b15 100644 --- a/public/content/translations/ja/developers/docs/networks/index.md +++ b/public/content/translations/ja/developers/docs/networks/index.md @@ -1,6 +1,6 @@ --- -title: ネットワーク -description: イーサリアムネットワーク概要、およびアプリケーションテスト用のテストネットのイーサ(ETH)の取得場所 +title: "ネットワーク" +description: "イーサリアムネットワーク概要、およびアプリケーションテスト用のテストネットのイーサ(ETH)の取得場所" lang: ja --- @@ -8,9 +8,9 @@ lang: ja イーサリアムアカウントは異なるネットワークすべてで使用できますが、アカウント残高とトランザクション履歴はメインネットから継承されません。 テスト目的に利用可能なネットワークと、テストネットのETHを取得する方法を知っておくと有用です。 セキュリティの観点から、一般にはメインネットのアカウントをテストネットで再利用すること(またはその逆)は推奨されません。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -テストネットワークは試用目的として、安価で安全なイーサリアムを提供します。それぞれのネットワークを読み進める前に、[イーサリアムの基本](/developers/docs/intro-to-ethereum/)を理解する必要があります。 +さまざまなネットワークについて学ぶ前に、[イーサリアムの基本](/developers/docs/intro-to-ethereum/)を理解しておく必要があります。テストネットワークは、安価で安全なバージョンのイーサリアムを試用できるようにしてくれます。 ## パブリックネットワーク {#public-networks} @@ -34,15 +34,11 @@ lang: ja #### 推奨テストネット -現在クライアントデベロッパーによってメンテナンスされているパブリックのテストネットは、SepoliaとHoodiの2つです。 Sepoliaは、コントラクトやアプリケーションのデベロッパーのためのネットワークで、アプリケーションのテストに使用されます。 Hoodiは、プロトコルのデベロッパーがネットワークのアップグレードをテストしたり、ステーカーがバリデータの実行をテストしたりするために使用されるネットワークです。 +現在クライアント開発者がメンテナンスしている2つのパブリックテストネットは、SepoliaとHoodiです。 Sepoliaは、コントラクトやアプリケーションのデベロッパーのためのネットワークで、アプリケーションのテストに使用されます。 Hoodiネットワークでは、プロトコル開発者はネットワークのアップグレードをテストでき、ステーカーはバリデータの実行をテストできます。 -#### Sepolia(セポリア) {#sepolia} +#### Sepolia {#sepolia} -**Sepoliaはアプリケーション開発に推奨されるデフォルトのテストネットです。** Sepoliaネットワークは、許可型のバリデータセットを使用しています。 また、まだ新しいものであるため、ステートや履歴などデータ量が少ないことも特徴です。 そのため、ネットワークを素早く同期でき、ノードを実行するのに必要なストレージ容量が少なくて済みます。 これは、ノードを素早く起動してネットワークと直接やり取りしたい場合に便利です。 - -- クライアントとテストチームが管理する非公開のバリデータセット -- 他のテストネットに比べてアプリケーションのデプロイが少ない、新しいテストネット -- 同期が速く、ノードを実行するには最小限のディスク容量が必要 +**Sepoliaは、アプリケーション開発に推奨されるデフォルトのテストネットです**。 Sepoliaネットワークは、クライアントチームとテストチームによって管理される、パーミッション制のバリデータセットを使用しています。 ##### リソース @@ -54,19 +50,19 @@ lang: ja ##### フォーセット -- [QuickNode Sepolia Faucet](https://faucet.quicknode.com/drip) +- [Alchemy Sepoliaフォーセット](https://www.alchemy.com/faucets/ethereum-sepolia) +- [Chain Platform Sepoliaフォーセット](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) +- [Chainstack Sepoliaフォーセット](https://faucet.chainstack.com/sepolia-testnet-faucet) +- [Ethereum Ecosystemフォーセット](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [ethfaucet.com Sepoliaフォーセット](https://ethfaucet.com/networks/ethereum) +- [Google Cloud Web3 Sepoliaフォーセット](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) - [Grabteeth](https://grabteeth.xyz/) -- [PoW faucet](https://sepolia-faucet.pk910.de/) -- [Coinbase Wallet Faucet | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet) -- [Alchemy Sepolia faucet](https://sepoliafaucet.com/) -- [Infura Sepolia faucet](https://www.infura.io/faucet) -- [Chainstack Sepolia faucet](https://faucet.chainstack.com/sepolia-testnet-faucet) -- [Ethereum Ecosystem faucet](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [Infura Sepoliaフォーセット](https://www.infura.io/faucet) +- [PoWフォーセット](https://sepolia-faucet.pk910.de/) +- [QuickNode Sepoliaフォーセット](https://faucet.quicknode.com/ethereum/sepolia) #### Hoodi {#hoodi} -_注: [Goerliテストネットは廃止されており](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17)、Hoodiに置き換えられました。 アプリケーションのSepoliaへの移行をご検討ください。_ - Hoodiは、バリデーションやステーキングのテストを行うためのテストネットです。 Hoodiネットワークは、テストネットバリデータを実行したいユーザーのために公開されています。 メインネットにデプロイする前にプロトコルのアップグレードをテストしたいステーカーは、Hoodiを使用する必要があります。 - オープンなバリデータセット。ステーカーはネットワークのアップグレードをテスト可能。 @@ -77,54 +73,108 @@ Hoodiは、バリデーションやステーキングのテストを行うため - [ウェブサイト](https://hoodi.ethpandaops.io/) - [GitHub](https://github.com/eth-clients/hoodi) -- [Explorer](https://explorer.hoodi.ethpandaops.io/) -- [Checkpoint Sync](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [エクスプローラー](https://explorer.hoodi.ethpandaops.io/) +- [チェックポイント同期](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [Otterscan](https://hoodi.otterscan.io/) +- [Etherscan](https://hoodi.etherscan.io/) ##### フォーセット +- [Chain Platform Hoodiフォーセット](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) - [Hoodiフォーセット](https://hoodi.ethpandaops.io/) +- [PoWフォーセット](https://hoodi-faucet.pk910.de/) + +#### Ephemery {#ephemery} + +Ephemeryは、毎月完全にリセットされるユニークなテストネットです。 実行状態とコンセンサス状態は28日ごとにジェネシス(初期状態)に戻ります。つまり、テストネット上で起こることはすべて一時的なものです。 このため、永続性を必要としない短期的なテストや、高速なノードのブートストラップ、「hello world」のような種類のアプリケーションに最適です。 + +- 常に新しい状態、バリデータやアプリの短期テスト +- 基本的なコントラクトセットのみを含む +- オープンなバリデータセットで、多額の資金に簡単にアクセス可能 +- 最小のノード要件と最速の同期、平均5GB未満 + +##### リソース + +- [ウェブサイト](https://ephemery.dev/) +- [Github](https://github.com/ephemery-testnet/ephemery-resources) +- [コミュニティチャット](https://matrix.to/#/#staker-testnet:matrix.org) +- [Blockscout](https://explorer.ephemery.dev/) +- [Otterscan](https://otter.bordel.wtf/) +- [Beaconエクスプローラー](https://beaconlight.ephemery.dev/) +- [チェックポイント同期](https://checkpoint-sync.ephemery.ethpandaops.io) +- [Launchpad](https://launchpad.ephemery.dev/) -Hoodiテストネットでバリデータを起動するには、[Hoodi launchpad](https://hoodi.launchpad.ethereum.org/en/)を使用してください。 +#### フォーセット + +- [Bordelフォーセット](https://faucet.bordel.wtf/) +- [Pk910 PoWフォーセット](https://ephemery-faucet.pk910.de/) + +#### Holesky (非推奨) {#holesky} + +Holeskyテストネットは2025年9月をもって非推奨となります。 ステーキングオペレーターとインフラプロバイダーは、代わりにHoodiをバリデータテストに使用すべきです。 + +- [Holeskyテストネットのシャットダウンに関するお知らせ](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _EFブログ、2025年9月1日_ +- [HoleskyおよびHoodiテストネットのアップデート](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) - _EFブログ、2025年3月18日_ ### レイヤー2テストネット {#layer-2-testnets} -[レイヤー2(L2)](/layer-2/)は、イーサリアムのスケーリングソリューションの総称であり、 レイヤー2はイーサリアムを拡張し、またイーサリアムのセキュリティ保証を継承する独立したブロックチェーンです。 レイヤー2のテストネットは、通常、パブリックイーサリアムのテストネットと対になっています。 +[レイヤー2(L2)](/layer-2/)は、特定の一群のイーサリアムスケーリングソリューションを説明するための総称です。 レイヤー2はイーサリアムを拡張し、またイーサリアムのセキュリティ保証を継承する独立したブロックチェーンです。 レイヤー2のテストネットは、通常、パブリックイーサリアムのテストネットと対になっています。 #### Arbitrum Sepolia {#arbitrum-sepolia} -[Arbitrum](https://arbitrum.io/)のテストネット。 +[Arbitrum](https://arbitrum.io/)用のテストネットです。 + +##### リソース + +- [Etherscan](https://sepolia.arbiscan.io/) +- [Blockscout](https://sepolia-explorer.arbitrum.io/) ##### フォーセット -- [Chainlinkフォーセット](https://faucets.chain.link/arbitrum-sepolia) -- [Alchemyフォーセット](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Alchemy Arbitrum Sepoliaフォーセット](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Chainlink Arbitrum Sepoliaフォーセット](https://faucets.chain.link/arbitrum-sepolia) +- [ethfaucet.com Arbitrum Sepoliaフォーセット](https://ethfaucet.com/networks/arbitrum) +- [QuickNode Arbitrum Sepoliaフォーセット](https://faucet.quicknode.com/arbitrum/sepolia) #### Optimistic Sepolia {#optimistic-sepolia} -[Optimism](https://www.optimism.io/)のテストネット。 +[Optimism](https://www.optimism.io/)用のテストネットです。 + +##### リソース + +- [Etherscan](https://sepolia-optimistic.etherscan.io/) +- [Blockscout](https://optimism-sepolia.blockscout.com/) ##### フォーセット -- [Chainlinkフォーセット](https://faucets.chain.link/optimism-sepolia) - [Alchemyフォーセット](https://www.alchemy.com/faucets/optimism-sepolia) +- [Chainlinkフォーセット](https://faucets.chain.link/optimism-sepolia) +- [ethfaucet.com Optimism Sepoliaフォーセット](https://ethfaucet.com/networks/optimism) +- [テストネットフォーセット](https://docs.optimism.io/builders/tools/build/faucets) #### Starknet Sepolia {#starknet-sepolia} -[Starknet](https://www.starknet.io)のテストネット +[Starknet](https://www.starknet.io)用のテストネットです。 + +##### リソース + +- [Starkscan](https://sepolia.starkscan.co/) ##### フォーセット - [Alchemyフォーセット](https://www.alchemy.com/faucets/starknet-sepolia) +- [Blast Starknet Sepoliaフォーセット](https://blastapi.io/faucets/starknet-sepolia-eth) +- [Starknetフォーセット](https://starknet-faucet.vercel.app/) ## プライベートネットワーク {#private-networks} -イーサリアムネットワークは、ノードがパブリックネットワーク(メインネットやテストネット) に接続されていない場合は、プライベートネットワークとなります。 ここでのプライベートとは、保護されており安全という意味ではなく、他のネットワークから分離されているという意味です。 +イーサリアムネットワークのノードがパブリックネットワーク(つまり、メインネットやテストネット)に接続されていない場合、そのネットワークはプライベートネットワークです。 ここでのプライベートとは、保護されており安全という意味ではなく、他のネットワークから分離されているという意味です。 -### 開発フレームワーク {#development-networks} +### 開発ネットワーク {#development-networks} イーサリアムアプリケーションを構築する場合は、プライベートネットワークで実行して、デプロイする前に動作確認をすることをお勧めします。 自身のコンピュータ上でローカルサーバを作成し、Web開発するのと同様に、ローカルのブロックチェーンインスタンスを作成し、開発中の分散型アプリ(Dapp)をテストできます。 プライベートネットワークでのテストは、パブリックテストネットよりもはるかに高速に反復処理を行うことができます。 -これをサポートするためのプロジェクトやツールがあります。 [開発ネットワーク](/developers/docs/development-networks/)の詳細をご覧ください。 +これをサポートするためのプロジェクトやツールがあります。 [開発ネットワーク](/developers/docs/development-networks/)に関する詳細はこちら。 ### コンソーシアムネットワーク {#consortium-networks} @@ -132,12 +182,35 @@ Hoodiテストネットでバリデータを起動するには、[Hoodi launchpa パブリックイーサリアムネットワークがパブリックなインターネットだとすると、コンソーシアムネットワークはプライベートなイントラネットと考えることができます。 +## なぜイーサリアムのテストネットは地下鉄の駅名にちなんで名付けられているのですか？ {#why-naming} + +多くのイーサリアムテストネットは、実在する地下鉄や鉄道の駅名にちなんで名付けられています。 この命名の伝統は初期に始まり、コントリビューターが住んでいた、あるいは働いていた世界中の都市を反映しています。 それは象徴的で、覚えやすく、実用的です。 テストネットがイーサリアムメインネットから隔離されているように、地下鉄の路線も地上の交通とは別に運行されています。 + +### 一般的に使用されるテストネットとレガシーテストネット {#common-and-legacy-testnets} + +- **Sepolia** - ギリシャのアテネにある、地下鉄で結ばれた地区。 現在、スマートコントラクトとdAppのテストに使用されています。 +- **Hoodi** - インドのベンガルールにあるフーディ地下鉄駅にちなんで命名。 バリデータとプロトコルのアップグレードテストに使用されます。 +- **Goerli** _(非推奨)_ - ドイツのベルリンにあるゲルリッツァー駅にちなんで命名。 +- **Rinkeby** _(非推奨)_ - ストックホルムの地下鉄駅がある郊外の地名にちなんで命名。 +- **Ropsten** _(非推奨)_ - ストックホルムのかつてのフェリー/地下鉄ターミナルがあった地域を指します。 +- **Kovan** _(非推奨)_ - シンガポールのMRT駅にちなんで命名。 +- **Morden** _(非推奨)_ - ロンドン地下鉄の駅にちなんで命名。 イーサリアム初のパブリックテストネット。 + +### その他の専門テストネット {#other-testnets} + +一部のテストネットは、短期またはアップグレード固有のテストのために作成されたものであり、必ずしも地下鉄をテーマにしているわけではありません。 + +- **Holesky** _(非推奨)_ - プラハのホレショヴィツェ駅にちなんで命名。 バリデータのテストに使用。2025年に非推奨となりました。 +- **Kiln**、**Zhejiang**、**Shandong**、**Prater**、**Pyrmont**、**Olympic** _(すべて非推奨)_ および **Ephemery** - マージ、Shanghai、バリデータの実験といったアップグレードシミュレーションのために専用に構築されました。 いくつかの名前は、地下鉄ベースではなく、地域やテーマに基づいています。 + +地下鉄の駅名を使用することで、開発者は数値のチェーンIDに頼ることなく、テストネットを迅速に識別し、記憶することができます。 また、実用的、グローバル、人間中心というイーサリアムの文化も反映しています。 + ## 関連ツール {#related-tools} -- [Chainlist](https://chainlist.org/) _ウォレットとプロバイダを適切なチェーンIDとネットワークIDに接続するEVMネットワークのリスト_ -- [EVMベースのチェーン](https://github.com/ethereum-lists/chains) _Chainlist_を動かすチェーンメタデータのGitHubリポジトリ +- [Chainlist](https://chainlist.org/) _ウォレットとプロバイダを適切なチェーンIDとネットワークIDに接続するためのEVMネットワークのリスト_ +- [EVMベースのチェーン](https://github.com/ethereum-lists/chains) _Chainlistを動かすチェーンメタデータのGitHubリポジトリ_ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [提案: 予測可能なイーサリアムテストネットのライフサイクル](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) - [イーサリアムテストネットの進化](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/archive-nodes/index.md index 9ad055cfbcb..6be861a01b6 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/archive-nodes/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -1,15 +1,15 @@ --- -title: イーサリアム・アーカイブノード -description: アーカイブノードの概要 +title: "イーサリアム・アーカイブノード" +description: "アーカイブノードの概要" lang: ja sidebarDepth: 2 --- アーカイブノードは、すべての状態の履歴をもつアーカイブをビルドするように構成されたイーサリアムクライアントのインスタンスです。 特定のユースケースにおいて、アーカイブノードは便利なツールですが、フルノードよりも実行する難易度が高くなっています。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[イーサリアムノード](/developers/docs/nodes-and-clients/)のコンセプト、 [アーキテクチャ](/developers/docs/nodes-and-clients/node-architecture/)、[同期戦略](/developers/docs/nodes-and-clients/#sync-modes)、[実行](/developers/docs/nodes-and-clients/run-a-node/)の経験、[ノードの使用](/developers/docs/apis/json-rpc/)などの知識があることを前提にしています。 +[イーサリアムノード](/developers/docs/nodes-and-clients/)の概念、[そのアーキテクチャ](/developers/docs/nodes-and-clients/node-architecture/)、[同期戦略](/developers/docs/nodes-and-clients/#sync-modes)、[ノードの実行](/developers/docs/nodes-and-clients/run-a-node/)方法、そして[その使用方法](/developers/docs/apis/json-rpc/)を理解しておく必要があります。 ## アーカイブノードとは @@ -17,13 +17,13 @@ sidebarDepth: 2 - アカウント残高とノンス - コントラクトコードとストレージ -- コンセンサス関連のデータ(例: ステーキングデポジットコントラクト) +- コンセンサス関連のデータ、例: ステーキングデポジットコントラクト -イーサリアムクライアントでは、ネットワークとやり取りし、新しいブロックを検証・生成するために、常に最新の状態である「最新の変更(チェーンの先端)」を把握している必要があります。 フルノードとして構成された実行レイヤークライアントは、ネットワークの最新の状態を検証・追跡しますが、一部の過去の状態のみをキャッシュします。例えば、 最後の128ブロックに関連付けられた状態では、チェーンの再編成を処理して、最新のデータに素早くアクセスすることができます。 この最新の状態は、すべてのクライアントにおいて受信したトランザクションを検証するのに必要であり、ネットワークで使用されます。 +イーサリアムクライアントでは、ネットワークとやり取りし、新しいブロックを検証・生成するために、常に最新の状態である「最新の変更(チェーンの先端)」を把握している必要があります。 フルノードとして設定された実行レイヤークライアントは、ネットワークの最新状態を検証・追跡しますが、過去のいくつかの状態(例: 最後の128ブロックに関連する状態)のみをキャッシュするため、チェーンの再編成を処理し、最近のデータへの高速アクセスを提供できます。 この最新の状態は、すべてのクライアントにおいて受信したトランザクションを検証するのに必要であり、ネットワークで使用されます。 状態は、特定のブロックにおけるネットワークの状態を瞬間的に記録したスナップショットであり、アーカイブは、ネットワークの状態の履歴を再生したものと考えることができます。 -状態の履歴は、安全に取り除くことができます。これは、ネットワークの動作には関係なく、クライアントが古いデータをすべて保持しても意味がないためです。 最近のブロック(例: 先頭から128ブロック)より前の状態は、事実上破棄されます。 フルノードは、ブロックチェーンの履歴データ(ブロックとトランザクション)と、リクエストに応じて古い状態を再生成するのに使用する予備のスナップショットの履歴のみを保存しています。 再生成は、EVMで過去のトランザクションを再実行することによって行われます。取得したい状態が最も近いスナップショットからか遠く離れている場合、計算負荷が高くなる傾向があります。 +状態の履歴は、安全に取り除くことができます。これは、ネットワークの動作には関係なく、クライアントが古いデータをすべて保持しても意味がないためです。 最近のブロック(例: 先頭から128ブロック前)より前に存在した状態は、事実上破棄されます。 フルノードは、ブロックチェーンの履歴データ(ブロックとトランザクション)と、リクエストに応じて古い状態を再生成するのに使用する予備のスナップショットの履歴のみを保存しています。 再生成は、EVMで過去のトランザクションを再実行することによって行われます。取得したい状態が最も近いスナップショットからか遠く離れている場合、計算負荷が高くなる傾向があります。 フルノードで状態の履歴にアクセスするには、大量の計算が必要です。 クライアントでは、過去のトランザクションをすべて実行して、ジェネシスから1つの状態の履歴を計算する必要があるかもしれません。 アーカイブノードは、最新の状態だけでなく、各ブロックの後に作成されたすべての状態の履歴を保存することで、計算負荷の問題を解決します。 ただし、ディスク容量が大きくなってしまうというデメリットもあります。 @@ -35,8 +35,8 @@ sidebarDepth: 2 状態のアーカイブによる主なメリットは、状態の履歴に関するクエリに素早くアクセスできることです。 例えば、アーカイブノードは、次の結果を即座に返します。 -- _ブロック15537393におけるアカウント 0x1337... が持っているETHの残高はいくらか？_ -- _ブロック1920000におけるコントラクト0xのトークン0xの残高はいくらか？_ +- _アカウント0x1337...のETH残高はいくらか... ブロック15537393において?_ +- _ブロック1920000におけるコントラクト0xのトークン0xの残高はいくらか?_ 上述したように、フルノードでは、EVMを実行してこのデータを生成する必要があります。これはCPUを使用し、処理に時間がかかります。 一方、アーカイブノードでは、ディスク上のデータにアクセスするため、即座に応答を返すことができます。 これは、インフラストラクチャの側面において、以下の役割を担う人に役立ちます。 @@ -46,35 +46,36 @@ sidebarDepth: 2 - Dappデベロッパー - 監査とコンプライアンス -履歴データにアクセスできる無料の[サービス](/developers/docs/nodes-and-clients/nodes-as-a-service/)がいくつかあります。 アーカイブノードは実行時に要求事項が多く、その大半にアクセス制限があるため、頻度の低いアクセスには適していますが、 履歴データに常時アクセスが必要なプロジェクトにおいては、独自で実行することを検討してください。 +履歴データへのアクセスを可能にする、さまざまな無料の[サービス](/developers/docs/nodes-and-clients/nodes-as-a-service/)もあります。 アーカイブノードは実行時に要求事項が多く、その大半にアクセス制限があるため、頻度の低いアクセスには適していますが、 履歴データに常時アクセスが必要なプロジェクトにおいては、独自で実行することを検討してください。 ## 実装と利用方法 この文脈でのアーカイブノードとは、状態データベースを処理してJSON-RPCエンドポイントを提供する、ユーザー向けの実行レイヤークライアントによって提供されるデータを指します。 設定オプション、同期時間、データベースサイズなどは、クライアントによって異なる場合があります。 詳細は、クライアントのドキュメントを参照してください。 -独自にアーカイブノードを立ち上げる前に、各クライアントの[ハードウェア要件](/developers/docs/nodes-and-clients/run-a-node/#requirements)などの違いを把握しておきましょう。 ほとんどのクライアントにおいて、アーカイブ機能は最適化されていないため、12TB以上のスペースが必要になります。 その一方で、エリゴンのような実装では、同じデータを3TB未満に保存できるため、アーカイブノードを実行するのに最適な方法となります。 +独自のアーカイブノードを起動する前に、クライアント間の違い、特にさまざまな[ハードウェア要件](/developers/docs/nodes-and-clients/run-a-node/#requirements)について学んでください。 ほとんどのクライアントにおいて、アーカイブ機能は最適化されていないため、12TB以上のスペースが必要になります。 その一方で、エリゴンのような実装では、同じデータを3TB未満に保存できるため、アーカイブノードを実行するのに最適な方法となります。 ## 推奨実行環境 -アーカイブノードは、[ノードの実行における一般的な推奨事項](/developers/docs/nodes-and-clients/run-a-node/)とは異なり、ハードウェアとメンテナンスの要件がより厳しくなっています。 そのため、エリゴンの[主要な機能](https://github.com/ledgerwatch/erigon#key-features)を考慮すると、[エリゴン](/developers/docs/nodes-and-clients/#erigon)のクライアント実装を使うのが最も実用的であると言えます。 +一般的な[ノード実行の推奨事項](/developers/docs/nodes-and-clients/run-a-node/)とは別に、アーカイブノードはハードウェアとメンテナンスの要件がより厳しくなる場合があります。 Erigonの[主な機能](https://github.com/ledgerwatch/erigon#key-features)を考慮すると、最も実用的なアプローチは[Erigon](/developers/docs/nodes-and-clients/#erigon)クライアント実装を使用することです。 ### ハードウェア -クライアントのドキュメントで、所定のモードの要件を必ず確認するようにしてください。 アーカイブノードでは、ディスクスペースが最大の要件となります。 クライアントにもよりますが、3TBから12TBが必要になります。 HDDは、大容量データの保存には適しているかもしれませんが、同期して常にチェーンの先頭を更新するには、SSDドライブが必要です。 [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html)ドライブでも十分ですが、最低でも [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences)以上の品質のものを選びましょう。 ディスクは、十分なスロットがあるデスクトップコンピュータまたはサーバーが適しています。 このような専用デバイスは、稼働時間の長いノードに最適です。 ノートパソコンで実行しても全く問題ありませんが、移植性の面で追加コストがかかります。 +クライアントのドキュメントで、所定のモードの要件を必ず確認するようにしてください。 +アーカイブノードでは、ディスクスペースが最大の要件となります。 クライアントにもよりますが、3TBから12TBが必要になります。 HDDは、大容量データの保存には適しているかもしれませんが、同期して常にチェーンの先頭を更新するには、SSDドライブが必要です。 [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html)ドライブで十分ですが、信頼できる品質のものである必要があり、少なくとも[TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences)であるべきです。 ディスクは、十分なスロットがあるデスクトップコンピュータまたはサーバーが適しています。 このような専用デバイスは、稼働時間の長いノードに最適です。 ノートパソコンで実行しても全く問題ありませんが、移植性の面で追加コストがかかります。 -全データを1つのボリュームに収めるため、複数のディスクを [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0)やLVMを使って結合する必要があります。 [ZFS](https://en.wikipedia.org/wiki/ZFS)では、低レベルのエラーの影響を受けずに正しいデータを確実に書き込む「コピーオンライト」をサポートしているため、検討する価値があるかもしれません。 +全てのデータは1つのボリュームに収まる必要があるため、ディスクは例えば[RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0)やLVMで結合する必要があります。 [ZFS](https://en.wikipedia.org/wiki/ZFS)は、低レベルのエラーなしでデータがディスクに正しく書き込まれることを保証する「Copy-on-write」をサポートしているため、使用を検討する価値があるかもしれません。 -特に専門的なセットアップにおいては、さらなる安定性とセキュリティのために、偶発的なデータベースの破損を防ぐ[ECCメモリ](https://en.wikipedia.org/wiki/ECC_memory)の使用を検討してください。 RAMのサイズは通常、フルノードと同等のサイズにすることが推奨されますが、RAMのサイズが大きいほど、同期の速度は向上します。 +偶発的なデータベースの破損を防ぎ、安定性とセキュリティを向上させるために、特にプロフェッショナルなセットアップでは、システムがサポートしている場合は[ECCメモリ](https://en.wikipedia.org/wiki/ECC_memory)の使用を検討してください。 RAMのサイズは通常、フルノードと同等のサイズにすることが推奨されますが、RAMのサイズが大きいほど、同期の速度は向上します。 アーカイブモードのクライアントは、最初の同期中に、ジェネシス以降のすべてのトランザクションを実行します。 CPUによって実行速度が異なるため、CPUが高速であれば、最初の同期にかかる時間を短くすることができます。 通常のコンシューマー向けのコンピューターでは、最初の同期に最大1か月程度かかる場合があります。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムフルノードとアーカイブノードの比較](https://www.quicknode.com/guides/infrastructure/node-setup/ethereum-full-node-vs-archive-node) - *QuickNode、2022年9月* -- [自分のイーサリアムアーカイブノードを構築する](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush、2021年8月_ -- [エリゴン、エリゴンのRPC、TrueBlocks(スクレイピングとAPI)をサービスとしてセットアップする方法](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _ – Magnus Hansson、2022年9月更新_ +- [イーサリアムフルノード vs アーカイブノード](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode、2022年9月_ +- [独自のイーサリアムアーカイブノードの構築](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _Thomas Jay Rush、2021年8月_ +- [Erigon、ErigonのRPC、TrueBlocks(スクレイプとAPI)をサービスとしてセットアップする方法](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson、2022年9月更新_ ## 関連トピック {#related-topics} -- [ ノードとクライアント](/developers/docs/nodes-and-clients/) -- [ノードの運用](/developers/docs/nodes-and-clients/run-a-node/) +- [ノードとクライアント](/developers/docs/nodes-and-clients/) +- [ノードの実行](/developers/docs/nodes-and-clients/run-a-node/) diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/bootnodes/index.md index 9953360a995..d7fd5304de6 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/bootnodes/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/bootnodes/index.md @@ -1,31 +1,31 @@ --- -title: イーサリアムブートノードの概要 -description: ブートノードを理解するための基礎知識。 +title: "イーサリアムブートノードの概要" +description: "ブートノードを理解するための基礎知識。" lang: ja --- 新しいノードがイーサリアムのネットワークに参加する際には、既存のノードに接続して、新しいピアを検出しなければなりません。 イーサリアムネットワークへのエントリポイントとなるこれらのノードをブートノードと呼びます。 クライアントは通常、ブートノードのリストをハードコードしています。 これらのブートノードは通常、イーサリアム・ファウンデーションのDevopsチームまたはクライアントチームによって実行されています。 ブートノードは、静的ノードとは異なるという点に注意してください。 静的ノードは何度も呼び出されますが、ブートノードは、接続するピアが十分にない場合や、ノードが自力で新しい接続をする必要がある場合にのみ呼び出されます。 -## ブートノードへの接続 {#connect-to-a-bootnode} +## ブートノードに接続する {#connect-to-a-bootnode} -クライアントには、ほとんどブートノードのリストが組み込まれていますが、自分のブートノードを実行したり、クライアントにハードコードされているリストに載っていないブートノードも使用することができます。 そのような場合は、クライアントの起動時に、以下のように指定します。これはGethの例です。各クライアントのドキュメントを確認してください 。 +ほとんどのクライアントにはブートノードのリストが組み込まれていますが、独自のブートノードを実行したり、クライアントにハードコードされているリストに含まれていないブートノードを使用することもできます。 そのような場合は、クライアントの起動時に、以下のように指定します。これはGethの例です。各クライアントのドキュメントを確認してください 。 ``` geth --bootnodes "enode://@:" ``` -## ブートノードの起動 {#run-a-bootnode} +## ブートノードを実行する {#run-a-bootnode} -ブートノードとは、NAT([ネットワークアドレス変換](https://www.geeksforgeeks.org/network-address-translation-nat/))の背後にないフルノードのことを指します。 公開されているフルノードは、すべてブートノードとして動作します。 +ブートノードは、NAT ([ネットワークアドレス変換](https://www.geeksforgeeks.org/network-address-translation-nat/)) の背後にないフルノードです。 公開されているフルノードは、すべてブートノードとして動作します。 -ノードを起動すると、[enode](/developers/docs/networking-layer/network-addresses/#enode)がログに記録されます。これは、他のユーザーがあなたのノードに接続するための公開識別子です。 +ノードを起動すると、[enode](/developers/docs/networking-layer/network-addresses/#enode) がログに記録されます。これは、他のユーザーがあなたのノードに接続するために使用できる公開識別子です。 通常、enodeは再起動するたびに再び生成されます。ブートノードで永続的なenodeを生成する方法については、クライアントのドキュメントを必ず参照してください。 ブートノードの性能を高めるには、接続可能なピアの最大数を増やすことをお勧めします。 多数のピアでブートノードを実行すると、必要な帯域幅が大幅に増加することに注意してください。 -## 使用可能なブートノード {#available-bootnodes} +## 利用可能なブートノード {#available-bootnodes} -go-ethereum内にある組み込みブートノードのリストは、[こちら](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23)で確認できます。 これらのブートノードは、イーサリアム・ファウンデーションとgo-ethereumチームによってメンテナンスされています。 +go-ethereum 内の組み込みブートノードのリストは、[こちら](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) で確認できます。 これらのブートノードは、イーサリアム・ファウンデーションとgo-ethereumチームによってメンテナンスされています。 ボランティアによって管理されている、他のブートノードのリストもあります。 少なくとも1つの公式ブートノードを必ず含めるようにしてください。公式ブートノードを含めないと、イクリプス攻撃を受ける可能性があります。 diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/client-diversity/index.md index 8d8bc573504..0e00251c202 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/client-diversity/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/client-diversity/index.md @@ -1,15 +1,15 @@ --- -title: クライアントの多様性 -description: イーサリアムクライアントの多様性の重要性についての概説 +title: "クライアントの多様性" +description: "イーサリアムクライアントの多様性の重要性についての概説" lang: ja sidebarDepth: 2 --- イーサリアムノードの動作は、ノードが実行するクライアントソフトウェアによって制御されています。 プロダクションレベルのイーサリアムクライアントは複数存在しており、それぞれ別のチームにより、異なるプログラミング言語で開発され、保守されています。 これらのクライアントは共通の仕様に基づいて構築されており、クライアント間のシームレスな連携、共通する機能、同等のユーザーエクスペリエンスを提供しています。 しかしながら、現時点ではクライアントの占有率は偏ってしまっており、ネットワークの安全性が最大限にまで高められていません。 クライアントの多様性を可能な限り高めるには、クライアント別の利用者数は同程度になることが望ましいです。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -ノードやクライアントが何かについてご存知ではない場合、[ノードとクライアント](/developers/docs/nodes-and-clients/)を参照してください。 [実行レイヤー](/glossary/#execution-layer)と[コンセンサスレイヤー](/glossary/#consensus-layer)は用語集に定義が記載されています。 +ノードやクライアントについてまだ理解していない場合は、[ノードとクライアント](/developers/docs/nodes-and-clients/)をご覧ください。 [実行](/glossary/#execution-layer)レイヤーと[コンセンサス](/glossary/#consensus-layer)レイヤーは、用語集で定義されています。 ## クライアントが複数ある理由 {#why-multiple-clients} @@ -25,85 +25,108 @@ sidebarDepth: 2 ### 攻撃耐性 {#resilience} -クライアントの多様性は、攻撃に対する耐性も同時にもたらします。 例えば、[特定のクライアントに対する攻撃](https://twitter.com/vdWijden/status/1437712249926393858)で不正なチェーンへと改ざんしようとする試みが成功する可能性は低くなります。これは、他のクライアントに同じような攻撃ができる可能性は低く、正規のチェーンは壊れないためです。 クライアントの多様性が低いほど、多数派のクライアントへの攻撃に関するリスクが高まります。 クライアントの多様性がネットワーク上の悪意のある攻撃に対する重要な防御となることは、既に証明されています。例えば、2016年の上海DOS攻撃の事例は、多数派のクライアント(Geth)に対して、ブロックごとに何万回も遅いディスクi/o操作を実行したため起こりました。 この脆弱性を持たない他のクライアントもオンラインであったため、イーサリアムはGethの脆弱性が修正されている間も攻撃に耐え、稼働を続けることができました。 +クライアントの多様性は、攻撃に対する耐性も同時にもたらします。 例えば、[特定のクライアントを騙して](https://twitter.com/vdWijden/status/1437712249926393858)特定のチェーンブランチに誘導する攻撃は、他のクライアントが同様の方法で悪用される可能性が低く、正規のチェーンは破損しないままであるため、成功する可能性は低いです。 クライアントの多様性が低いほど、多数派のクライアントへの攻撃に関するリスクが高まります。 クライアントの多様性がネットワーク上の悪意のある攻撃に対する重要な防御となることは、すでに証明されています。例えば、2016年の上海でのサービス拒否攻撃は、攻撃者が支配的なクライアント(Geth)を騙して、ブロックごとに何万回も遅いディスクi/o操作を実行させることができたために可能でした。 この脆弱性を持たない他のクライアントもオンラインであったため、イーサリアムはGethの脆弱性が修正されている間も攻撃に耐え、稼働を続けることができました。 -### プルーフ・オブ・ステークにおけるファイナリティ {#finality} +### プルーフ・オブ・ステークのファイナリティ {#finality} イーサリアムノードの33%以上を占めるコンセンサスクライアントのバグがあると、コンセンサスレイヤーのファイナライズを妨げる可能性があります。つまり、トランザクションの取り消しや改ざんが発生するおそれがあります。 これはイーサリアム上に構築された多くのアプリ、特に分散型金融(DeFi)にとって非常に大きな問題となります。 - さらに、3分の2のマジョリティを占めるクライアントの重大なバグにより、チェーンが誤って スプリットし、ファイナライズされ、大量のバリデータが無効なチェーン上で立ち往生する可能性があります。 これらのバリデータが正しいチェーンに再び参加しようとする場合、スラッシングのペナルティを受けるか、時間がかかり高額となる任意退出後に、再度アクティベーションを行います。 スラッシングの規模は過失のあるノードの数に比例し、3分の2のマジョリティが最大のスラッシング(32 ETH)を受けます。 + さらに悪いことに、3分の2の多数を占めるクライアントの重大なバグにより、チェーンが誤って分割されファイナライズされることで、多数のバリデータが無効なチェーン上で立ち往生する可能性があります。 これらのバリデータが正しいチェーンに再び参加しようとする場合、スラッシングのペナルティを受けるか、時間がかかり高額となる任意退出後に、再度アクティベーションを行います。 スラッシングの規模は過失のあるノードの数に比例し、3分の2のマジョリティが最大のスラッシング(32 ETH)を受けます。 これらは可能性が低いシナリオですが、アクティブなノードにクライアントを均等に分散することで、イーサリアムのエコシステムはリスクを軽減することが出来ます。 特定のコンセンサスクライアントが、全ノードの33%のシェアを占めないことが理想です。 -### 責任の共有 {#responsibility} +### 共同責任 {#responsibility} マジョリティクライアントを維持するためには人件費もかかります。 小規模な開発チームは過剰な負担と責任を負わなければなりません。 クライアントの多様性が低いほど、マジョリティクライアントを保守するデベロッパーの責任が大きくなります。 この責任を複数のチームに分散させることは、イーサリアムのノードネットワークの健全性と、人々の繋がりの両方にとって望ましいことです。 ## 現在のクライアントの多様性 {#current-client-diversity} -![クライアントの多様性を示す円グラフ](./client-diversity.png) _図のデータは[ethernodes.org](https://ethernodes.org)と[clientdiversity.org](https://clientdiversity.org/)から引用_ +### 実行クライアント {#execution-clients-breakdown} -上の2つの円グラフは、実行レイヤーとコンセンサスレイヤーの現在(2022年1月の執筆時点)のクライアントの多様性のスナップショットを示しています。 実行レイヤーの大多数は[Geth](https://geth.ethereum.org/)が占めており、1位と大差をつけて[Open Ethereum](https://openethereum.github.io/)が2位、次に[Erigon](https://github.com/ledgerwatch/erigon)、[Nethermind](https://nethermind.io/)と続きますが、その他のクライアントはネットワークの1%未満に過ぎません。 コンセンサスレイヤーで最も一般的に使用されている[Prysm](https://prysmaticlabs.com/#projects)は、Gethほど独占しているわけではありませんが、それでもネットワークの60%以上を占めています。 [Lighthouse](https://lighthouse.sigmaprime.io/)と[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)がそれぞれ約20%と約14%を占め、他のクライアントはほとんど使われていません。 + -実行レイヤーのデータは、2022年1月23日に[Ethernodes](https://ethernodes.org)から、 コンセンサスクライアントのデータは[Michael Sproul](https://github.com/sigp/blockprint)から取得しました。 コンセンサスレイヤーのクライアントは、コンセンサスクライアントを識別するための明確な痕跡を常に持っているわけではないため、コンセンサスクライアントのデータを取得することが難しい場合があります。 データはマイノリティクライアントの一部を混同する場合がある分類アルゴリズムを用いて生成されました(詳細は[こちら](https://twitter.com/sproulM_/status/1440512518242197516)を参照)。 上の図では、これらの曖昧な分類は、どちらか一方のラベル(Nimbus/Tekuなど)で記載されています。 いずれにせよ、ネットワークのマジョリティがPrysmを実行していることは明白です。 データは固定されたブロック群(この場合はスロット2048001から2164916) のスナップショットです。Prysmの占める割合が高まり、68%を超えることもありました。 これはスナップショットに過ぎませんが、図中の値は、クライアントの多様性の現状をよく表すものです。 +### コンセンサスクライアント {#consensus-clients-breakdown} -コンセンサスレイヤーのクライアントの多様性についての最新のデータは、[clientdiversity.org](https://clientdiversity.org/)から入手できます。 + -## 実行レイヤー {#execution-layer} - -これまでクライアントの多様性に関する議論は、主にコンセンサスレイヤーに焦点が当てられていました。 しかし、実行クライアント[Geth](https://geth.ethereum.org)は現在、すべてのノードの 85%を占めています。 この高い占有率は、コンセンサスクライアントと同じ理由で問題になります。 例えば、トランザクション処理や実行ペイロードの構築に影響を与えるバグがGethにあると、コンセンサスクライアントが問題や不具合のあるトランザクションをファイナライズする可能性があります。 そのため、使われる実行クライアントがより均一に分散されると、イーサリアムの健全性が高まります。ネットワークの33%以上を占めるクライアントが存在しないことが理想です。 - -## マイノリティクライアントの使用 {#use-minority-client} +この図は古い可能性があります。最新情報については、[ethernodes.org](https://ethernodes.org)および[clientdiversity.org](https://clientdiversity.org)をご覧ください。 -クライアントの多様性に対応するには、個々のユーザーがマイノリティクライアントを選ぶだけでなく、マイニング/バリデータプールや、メジャーな分散型アプリ(Dapp)や取引所などの機関がクライアントを切り替えることも必要です。 しかし、すべてのユーザーは現在の不均衡を是正し、利用可能なすべてのイーサリアムソフトウェアの使用の正常化に向けて貢献することができます。 マージ後はすべてのノードオペレーターは、実行クライアントとコンセンサスクライアントの両方を実行する必要があります。 以下に示すクライアントの組み合わせを選ぶことは、クライアントの多様性の向上につながります。 +上記の2つの円グラフは、実行レイヤーとコンセンサスレイヤーの現在のクライアントの多様性のスナップショットを示しています(2025年10月執筆時点)。 クライアントの多様性は年々改善されており、実行レイヤーでは[Geth](https://geth.ethereum.org/)による支配が減少し、[Nethermind](https://www.nethermind.io/nethermind-client)が僅差で2位、[Besu](https://besu.hyperledger.org/)が3位、[Erigon](https://github.com/ledgerwatch/erigon)が4位となり、その他のクライアントがネットワークの3%未満を占めています。 コンセンサスレイヤーで最も一般的に使用されているクライアントである[Lighthouse](https://lighthouse.sigmaprime.io/)は、2番目に多く使用されているクライアントとかなり僅差です。 [Prysm](https://prysmaticlabs.com/#projects)と[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)がそれぞれ約31%と約14%を占め、その他のクライアントはほとんど使用されていません。 -### 実行クライアント {#execution-clients} +実行レイヤーのデータは、2025年10月26日に[supermajority.info](https://supermajority.info/)から取得したものです。 コンセンサスクライアントのデータは[Michael Sproul](https://github.com/sigp/blockprint)から取得しました。 コンセンサスレイヤーのクライアントは、コンセンサスクライアントを識別するための明確な痕跡を常に持っているわけではないため、コンセンサスクライアントのデータを取得することが難しい場合があります。 このデータは、マイノリティクライアントの一部を時々混同する分類アルゴリズムを使用して生成されました(詳細は[こちら](https://twitter.com/sproulM_/status/1440512518242197516)を参照)。 上の図では、これらの曖昧な分類は、どちらか一方のラベル(例: Nimbus/Teku)で記載されています。 いずれにせよ、ネットワークのマジョリティがPrysmを実行していることは明白です。 これはスナップショットに過ぎませんが、図中の値は、クライアントの多様性の現状をよく表すものです。 -[Besu](https://www.hyperledger.org/use/besu) +コンセンサスレイヤーに関する最新のクライアント多様性データは、[clientdiversity.org](https://clientdiversity.org/)で入手できます。 -[Nethermind](https://downloads.nethermind.io/) +## 実行レイヤー {#execution-layer} -[Erigon](https://github.com/ledgerwatch/erigon) +これまでクライアントの多様性に関する議論は、主にコンセンサスレイヤーに焦点が当てられていました。 しかし、実行クライアントの[Geth](https://geth.ethereum.org)は現在、全ノードの約85%を占めています。 この高い占有率は、コンセンサスクライアントと同じ理由で問題になります。 例えば、トランザクション処理や実行ペイロードの構築に影響を与えるバグがGethにあると、コンセンサスクライアントが問題や不具合のあるトランザクションをファイナライズする可能性があります。 そのため、使われる実行クライアントがより均一に分散されると、イーサリアムの健全性が高まります。ネットワークの33%以上を占めるクライアントが存在しないことが理想です。 -[Go-Ethereum](https://geth.ethereum.org/) +## マイノリティクライアントを使用する {#use-minority-client} -### コンセンサスクライアント {#consensus-clients} +クライアントの多様性に対応するには、個々のユーザーがマイノリティクライアントを選ぶだけでなく、バリデータプールや、メジャーな分散型アプリ(Dapp)や取引所などの機関がクライアントを切り替えることも必要です。 しかし、すべてのユーザーは現在の不均衡を是正し、利用可能なすべてのイーサリアムソフトウェアの使用の正常化に向けて貢献することができます。 マージ後はすべてのノードオペレーターは、実行クライアントとコンセンサスクライアントの両方を実行する必要があります。 以下に示すクライアントの組み合わせを選ぶことは、クライアントの多様性の向上につながります。 -[Nimbus](https://nimbus.team/) - -[Lighthouse](https://github.com/sigp/lighthouse) +### 実行クライアント {#execution-clients} -[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) +- [Besu](https://www.hyperledger.org/use/besu) +- [Nethermind](https://downloads.nethermind.io/) +- [Erigon](https://github.com/ledgerwatch/erigon) +- [Go-Ethereum](https://geth.ethereum.org/) +- [Reth](https://reth.rs/) -[ロードスター](https://github.com/ChainSafe/lodestar) +### コンセンサスクライアント {#consensus-clients} -[プリズム](https://prysm.offchainlabs.com/docs/) +- [Nimbus](https://nimbus.team/) +- [Lighthouse](https://github.com/sigp/lighthouse) +- [Teku](https://consensys.io/teku) +- [Lodestar](https://github.com/ChainSafe/lodestar) +- [Prysm](https://prysm.offchainlabs.com/docs/) +- [Grandine](https://docs.grandine.io/) -ノードオペレーターを大多数を占めるクライアントからの移行を奨励し、移行プロセスを加速できるよう、技術系のユーザーはマイノリティクライアント向けのチュートリアルやドキュメントの作成にご協力ください。 マイノリティコンセンサスクライアントへの移行に関するガイドは、 [clientdiversity.org](https://clientdiversity.org/)から入手できます。 +ノードオペレーターを大多数を占めるクライアントからの移行を奨励し、移行プロセスを加速できるよう、技術系のユーザーはマイノリティクライアント向けのチュートリアルやドキュメントの作成にご協力ください。 マイノリティのコンセンサスクライアントに切り替えるためのガイドは、[clientdiversity.org](https://clientdiversity.org/)で入手できます。 -## クライアントの多様性のダッシュボード {#client-diversity-dashboards} +## クライアントの多様性ダッシュボード {#client-diversity-dashboards} 実行レイヤーとコンセンサスレイヤーのクライアントの多様性に関するリアルタイムの統計情報を提供しているダッシュボードがいくつかあります。 **コンセンサスレイヤー:** - [Rated.network](https://www.rated.network/) -- [clientdiversity.org](https://clientdiversity.org/) **実行レイヤー:** +- [clientdiversity.org](https://clientdiversity.org/) + +**実行レイヤ:** - [supermajority.info](https://supermajority.info//) - [Ethernodes](https://ethernodes.org/) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムのコンセンサスレイヤーにおけるクライアントの多様性について](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) -- [イーサリアムマージ: マジョリティクライアントは自己責任での実行](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest、2022年3月24日_ +- [イーサリアムのコンセンサスレイヤーにおけるクライアントの多様性](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [イーサリアムマージ：多数派クライアントの実行は自己責任で！](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest、2022年3月24日_ - [クライアントの多様性の重要性](https://our.status.im/the-importance-of-client-diversity/) -- [イーサリアムノードサービスのリスト](https://ethereumnodes.com/) -- [クライアントの多様性問題の「5つの理由」](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) -- [イーサリアムの多様性と解決方法(YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [イーサリアムノードサービス一覧](https://ethereumnodes.com/) +- [クライアント多様性問題の「5つのなぜ」](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [イーサリアムの多様性とその解決策(YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) - [clientdiversity.org](https://clientdiversity.org/) ## 関連トピック {#related-topics} -- [イーサリアムノードの運用](/run-a-node/) +- [イーサリアムノードを運用する](/run-a-node/) - [ノードとクライアント](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/index.md index 41fcc332d16..727cff687ae 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/index.md @@ -1,17 +1,17 @@ --- -title: ノードとクライアント -description: イーサリアムノードとクライアントソフトの概要、ノードを設定する方法とその必要性 +title: "ノードとクライアント" +description: "イーサリアムノードとクライアントソフトの概要、ノードを設定する方法とその必要性" lang: ja sidebarDepth: 2 --- イーサリアムは、「ノード」と呼ばれるコンピュータの分散型ネットワークです。ノードで実行されているソフトウェアが、ブロックとトランザクションデータを検証します。 このソフトウェアは、コンピュータをイーサリアムノードにするために、必ず実行する必要があります。 ノードを構成するには、 別々のソフトウェア (「クライアント」と呼ばれる) が2つ必要です。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -イーサリアムクライアントの詳細を学び、自分で動かすには、P2Pネットワークの概念と[EVMの基本](/developers/docs/evm/)を理解する必要があります。 まずは[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読んでください。 +イーサリアムクライアントの独自のインスタンスを実行し、より深く掘り下げる前に、ピアツーピアネットワークの概念と[EVMの基礎](/developers/docs/evm/)を理解する必要があります。 [イーサリアムの紹介](/developers/docs/intro-to-ethereum/)をご覧ください。 -ノード運用初心者の方は、まず[イーサリアムノードの運用](/run-a-node)というユーザーフレンドリーな導入方法をチェックすることをお勧めします。 +ノードのトピックに慣れていない場合は、まず[イーサリアムノードの実行](/run-a-node)に関するユーザーフレンドリーな紹介をご覧ください。 ## ノードとクライアントとは {#what-are-nodes-and-clients} @@ -20,40 +20,44 @@ sidebarDepth: 2 - 実行クライアント(ELクライアントや実行エンジンとも呼ばれ、過去の名称はEth1クライアント)は、ネットワークでブロードキャストされた新たなトランザクションを受け取り、EVM(イーサリアム仮想マシン)でトランザクションを実行し、すべての現在のイーサリアムデータの最新の状態とデータベースを保持します。 - コンセンサスクライアント(ビーコンノードやCLクライアントとも呼ばれ、過去の名称はETh2クライアント)は、プルーフ・オブ・ステークのコンセンサスアルゴリズムを実行し、実行クライアントからの検証されたデータに基づき、ネットワークの合意を形成します。 「バリデータ」と呼ばれる3つ目のソフトウェアもあります。バリデータをコンセンサスクライアントに追加することで、ネットワークのセキュリティの確保にノードを参加させることができます。 -これらのクライアントは、連携してイーサリアムチェーンのヘッドを追跡し、ユーザーがイーサリアムネットワークとやり取りできるようにします。 複数のソフトウェアを組み合わせたモジュラー型設計は、[カプセル化された複雑性](https://vitalik.eth.limo/general/2022/02/28/complexity.html)と呼ばれます。 このアプローチにより、[マージ](/roadmap/merge)をシームレスに実行できるようになりました。また、クライアントソフトウェアの保守や開発が容易になり、[レイヤー2エコシステム](/layer-2/)などの各クライアントを再利用できるようになりました。 +これらのクライアントは、連携してイーサリアムチェーンのヘッドを追跡し、ユーザーがイーサリアムネットワークとやり取りできるようにします。 複数のソフトウェアが連携して動作するモジュラー設計は、[カプセル化された複雑性](https://vitalik.eth.limo/general/2022/02/28/complexity.html)と呼ばれます。 このアプローチにより、[The Merge](/roadmap/merge)をシームレスに実行しやすくなり、クライアントソフトウェアの保守と開発が容易になり、例えば[レイヤー2エコシステム](/layer-2/)での個々のクライアントの再利用が可能になります。 -![実行クライアントとコンセンサスクライアントの連結](./eth1eth2client.png) 実行クライアントとコンセンサスクライアントの統合の簡略図 +![結合された実行クライアントとコンセンサスクライアント](./eth1eth2client.png) +結合された実行クライアントとコンセンサスクライアントの簡易図です。 ### クライアントの多様性 {#client-diversity} -[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)は、それぞれ異なるチームが、さまざまなプログラミング言語を使って開発しています。 +[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)はどちらも、さまざまなチームによって開発された多様なプログラミング言語で存在します。 -複数のクライアント実装が、単一のコードベースへの依存を減らし、ネットワークをより強固にします。 理想は、どのクライアントもネットワークの大多数を占めることなく、多様性を実現し、単一障害点を減らすことです。 また、多様な言語を揃えることで、デベロッパーコミュニティがより広範になり、デベロッパーの希望言語で開発できるようになります。 +複数のクライアント実装が、単一のコードベースへの依存を減らし、ネットワークをより強固にします。 理想は、どのクライアントもネットワークの大多数を占めることなく、多様性を実現し、単一障害点を減らすことです。 +また、多様な言語を揃えることで、デベロッパーコミュニティがより広範になり、デベロッパーの希望言語で開発できるようになります。 -[クライアントの多様性についての詳細](/developers/docs/nodes-and-clients/client-diversity/) +[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity/)についての詳細はこちら。 これらのクライアント実装は、すべて同じ仕様に従っています。 仕様はイーサリアムネットワークとブロックチェーンの機能や技術的な詳細を定義しており、 下記で確認することができます。 -- 元々は[イーサリアムイエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf) -- [実行クライアントの仕様](https://github.com/ethereum/execution-specs/) -- [コンセンサスクライアントの仕様](https://github.com/ethereum/consensus-specs) -- さまざまな[ネットワーク・アップグレード](/ethereum-forks/)で実装された[EIP](https://eips.ethereum.org/) +- 元々は、[イーサリアム・イエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf) +- [実行仕様](https://github.com/ethereum/execution-specs/) +- [コンセンサス仕様](https://github.com/ethereum/consensus-specs) +- さまざまな[ネットワークアップグレード](/ethereum-forks/)で実装された[EIP](https://eips.ethereum.org/) -### ネットワークのノードの追跡 {#network-overview} +### ネットワーク内のノードの追跡 {#network-overview} イーサリアムネットワークのノードの概要をリアルタイムで提供しているトラッカーが複数あります。 しかし、分散型ネットワークの性質上、これらのクローラーはネットワークの一部しか把握できず、異なる結果を報告する可能性があることに注意してください。 - Etherscanによる[ノードのマップ](https://etherscan.io/nodetracker) - Bitflyによる[Ethernodes](https://ethernodes.org/) -- [Nodewatch](https://www.nodewatch.io/): Chainsafeによるコンセンサスノードのクローリング +- Chainsafeによる[Nodewatch](https://www.nodewatch.io/)、コンセンサスノードをクロール +- [Monitoreth](https://monitoreth.io/) - MigaLabsによる、分散型ネットワーク監視ツール +- [Weekly Network Health Reports](https://probelab.io) - ProbeLabによる、[Nebula crawler](https://github.com/dennis-tra/nebula)やその他のツールを使用 -## ノードの類型 {#node-types} +## ノードのタイプ {#node-types} -[自分でノードを実行](/developers/docs/nodes-and-clients/run-a-node/)したい場合、ノードの種類を選ぶ必要があります。ノードにはいくつかの種類があり、それぞれデータの扱い方が異なります。 実際に、クライアントが実行できるノードには、ライトノード、フルノード、アーカイブノードの3種類があります。 また、同期時間を短縮する同期戦略のオプションを選ぶこともできます。 同期とは、イーサリアムの状態についての最新情報をどれだけ迅速に取得できるかを意味します。 +[自身のノードを実行](/developers/docs/nodes-and-clients/run-a-node/)したい場合、データを異なる方法で消費するさまざまなタイプのノードがあることを理解する必要があります。 実際に、クライアントが実行できるノードには、ライトノード、フルノード、アーカイブノードの3種類があります。 また、同期時間を短縮する同期戦略のオプションを選ぶこともできます。 同期とは、イーサリアムの状態についての最新情報をどれだけ迅速に取得できるかを意味します。 ### フルノード {#full-node} -フルノードは、各ブロックごとのブロックボディーと状態データのダウンロードおよび検証に加え、ブロックチェーンの各ブロックの検証を行います。 フルノードにはさまざまな種類があります。ジェネシスブロックから開始してブロックチェーンの履歴にあるすべてのブロックを1つずつ検証するものや、 直近のブロックで有効性が信頼できるものから検証を開始するものがあります(例: Gethの「スナップ同期」) 。 ディスク領域を節約するため、フルノードは検証の開始位置に関係なく、比較的最近のデータ(通常は直近の128ブロック)のローカルコピーのみを保存し、古いデータを削除できるようにしています。 古いデータは、必要に応じて再生成されます。 +フルノードは、各ブロックごとのブロックボディーと状態データのダウンロードおよび検証に加え、ブロックチェーンの各ブロックの検証を行います。 フルノードにはさまざまな種類があります。ジェネシスブロックから開始してブロックチェーンの履歴にあるすべてのブロックを1つずつ検証するものや、 その他は、有効であると信頼するより最近のブロックで検証を開始します(例：Gethの「スナップ同期」)。 ディスク領域を節約するため、フルノードは検証の開始位置に関係なく、比較的最近のデータ(通常は直近の128ブロック)のローカルコピーのみを保存し、古いデータを削除できるようにしています。 古いデータは、必要に応じて再生成されます。 - 完全なブロックチェーンデータを保存(ただし、フルノードは定期的にプルーニングされており、最初のジェネシス(誕生)までさかのぼる状態は保存されていない) - ブロック検証に参加し、すべてのブロックと状態を検証する @@ -64,60 +68,61 @@ sidebarDepth: 2 アーカイブノードは、ジェネシスからすべてのブロックを検証し、ダウンロードしたデータを永久に保存するフルノードです。 -- フルノードに保存されているすべてを保持し、過去の状態のアーカイブを構築する。 例えば、ブロック4,000,000のアカウント残高をクエリしたい場合、または簡単にかつ確実にトレースを使用してマイニングを行うことなく、自分のトランザクションセットをテストしたい場合などに必要。 +- フルノードに保存されているすべてを保持し、過去の状態のアーカイブを構築する。 例えば、ブロック4,000,000のアカウント残高をクエリしたい場合や、トレースを使用して検証せずに、簡単にかつ確実に自分のトランザクションセットをテストしたい場合などに必要。 - データがテラバイト単位になるため、平均的なユーザーにとってアーカイブノードは魅力的なものではないが、ブロックエクスプローラー、ウォレットベンダー、チェーン分析などのサービスに有用。 アーカイブ以外の任意のモードでクライアントを同期すると、ブロックチェーンデータがプルーニングされます。 つまり、すべての過去の状態を保存するアーカイブは存在しませんが、フルノードは必要に応じて構築できます。 -[アーカイブノードの詳細](/developers/docs/nodes-and-clients/archive-nodes) +[アーカイブノード](/developers/docs/nodes-and-clients/archive-nodes)についての詳細はこちら。 ### ライトノード {#light-node} -ライトノードは、すべてのブロックをダウンロードする代わりに、ブロックヘッダーのみをダウンロードします。 ブロックヘッダーには、ブロックの内容に関するサマリー情報が含まれています。 ライトノードは、必要に応じて、フルノードからブロックヘッダー以外の情報を取得します。 また、受信したデータをブロックヘッダーの状態ルートに対して個別に検証できます。 ライトノードでは、フルノードを実行するために必要な強力なハードウェアや高帯域幅がなくても、イーサリアムネットワークに参加できます。 最終的には、ライトノードは携帯電話や組み込み機器で動作できるようになる可能性があります。 ライトノードはコンセンサスには参加せず、マイナーやバリデータにはなれませんが、フルノードと同じ機能とセキュリティ保証でイーサリアムブロックチェーンにアクセスできます。 +ライトノードは、すべてのブロックをダウンロードする代わりに、ブロックヘッダーのみをダウンロードします。 ブロックヘッダーには、ブロックの内容に関するサマリー情報が含まれています。 ライトノードは、必要に応じて、フルノードからブロックヘッダー以外の情報を取得します。 また、受信したデータをブロックヘッダーの状態ルートに対して個別に検証できます。 ライトノードでは、フルノードを実行するために必要な強力なハードウェアや高帯域幅がなくても、イーサリアムネットワークに参加できます。 最終的には、ライトノードは携帯電話や組み込み機器で動作できるようになる可能性があります。 ライトノードはコンセンサスには参加しません(つまり、バリデーターにはなれません)が、フルノードと同じ機能とセキュリティ保証でイーサリアムブロックチェーンにアクセスできます。 -イーサリアムでは、ライトクライアントの開発が活発に行われています。コンセンサスレイヤーと実行レイヤーの新しいライトクライアントが、まもなくリリースされる予定です。 また、[ゴシップネットワーク](https://www.ethportal.net/)を介して、ライトクライアントデータを提供する方法もあります。 ゴシップネットワークは、フルノードがリクエストに応答することなくライトノードのネットワークをサポートできるため効率的です。 +イーサリアムでは、ライトクライアントの開発が活発に行われています。コンセンサスレイヤーと実行レイヤーの新しいライトクライアントが、まもなくリリースされる予定です。 +[ゴシップネットワーク](https://www.ethportal.net/)を介してライトクライアントデータを提供する潜在的なルートもあります。 ゴシップネットワークは、フルノードがリクエストに応答することなくライトノードのネットワークをサポートできるため効率的です。 -イーサリアムでは現在、ライトノードは多数サポートされていませんが、今後急速に普及していくと考えられています。 特に、[Nimbus](https://nimbus.team/)、[Helios](https://github.com/a16z/helios)、[LodeStar](https://lodestar.chainsafe.io/)などのクライアントは、現在ライトノードを重点的に開発しています。 +イーサリアムでは現在、ライトノードは多数サポートされていませんが、今後急速に普及していくと考えられています。 特に、[Nimbus](https://nimbus.team/)、[Helios](https://github.com/a16z/helios)、[LodeStar](https://lodestar.chainsafe.io/)のようなクライアントは現在、ライトノードに重点を置いています。 ## イーサリアムノードを運用する必要性 {#why-should-i-run-an-ethereum-node} ノードを実行することで、イーサリアムを直接、トラストレスかつプライベートに利用することができます。また、イーサリアムのネットワークをより強固にし、分散化の促進に貢献することができます。 -### メリット {#benefits-to-you} +### あなたにとってのメリット {#benefits-to-you} 自分のノードを実行すると、プライベートで自己完結したトラストレスな形でイーサリアムを利用することができます。 クライアントを使って自分でデータを検証できるので、ネットワークを信頼する必要はありません。 「信頼するな、検証せよ」はブロックチェーンで頻繁に唱えられるマントラです。 - ノードはすべてのトランザクションとブロックをコンセンサスルールに対して検証する。 つまり、ネットワークの他のノードに依存したり、完全に信頼する必要がない。 -- 自分のノードでイーサリアムウォレットを使用可能。 仲介業者に自分のアドレスや残高情報を渡す必要がないため、より安全かつプライベートに分散型アプリ(Dapp)を利用できる。 自身のクライアントですべてをチェックできる。 [MetaMask](https://metamask.io)、[Frame](https://frame.sh/)、[他の多くのウォレット](/wallets/find-wallet/)はRPCインポート機能を提供し、自分のノードを使用できる。 +- 自分のノードでイーサリアムウォレットを使用可能。 仲介業者に自分のアドレスや残高情報を渡す必要がないため、より安全かつプライベートに分散型アプリ(Dapp)を利用できる。 自身のクライアントですべてをチェックできる。 [MetaMask](https://metamask.io)、[Frame](https://frame.sh/)、そして[その他多くのウォレット](/wallets/find-wallet/)はRPCインポートを提供しており、あなたのノードを使用できます。 - イーサリアムからのデータに依存する他のサービスを実行および自分でホスト可能 (例えば、ビーコンチェーンのバリデータ、レイヤー2などのソフトウェア、インフラストラクチャ、ブロックエクスプローラー、ペイメントプロセッサーなど)。 -- 独自のカスタム[RPCエンドポイント](/developers/docs/apis/json-rpc/)を提供できる。 このエンドポイントをコミュニティに公開することで、巨大な中央集権型プロバイダーへの依存を減らすことができる。 -- **プロセス間通信(IPC)**を利用してノードに接続、またはノードを書き換えプラグインとしてプログラムの読み込みが可能。 これにより、レイテンシーが低くなり、Web3ライブラリを使用して大量のデータを処理する場合、またはトランザクションをできるだけ早く置き換える必要がある場合に(フロントランニング)、非常に有用。 -- ETHを直接ステーキングでき、ネットワークの安全性に貢献し、同時に報酬を得ることができる。 始めるには[ソロステーキング](/staking/solo/)を参照。 +- 独自のカスタム[RPCエンドポイント](/developers/docs/apis/json-rpc/)を提供できます。 このエンドポイントをコミュニティに公開することで、巨大な中央集権型プロバイダーへの依存を減らすことができる。 +- **プロセス間通信(IPC)**を使用してノードに接続するか、ノードを書き換えてプログラムをプラグインとして読み込むことができます。 これにより低レイテンシが実現され、例えば、web3ライブラリを使用して大量のデータを処理する場合や、トランザクションをできるだけ早く置き換える必要がある場合(フロントランニングなど)に非常に役立ちます。 +- ETHを直接ステーキングでき、ネットワークの安全性に貢献し、同時に報酬を得ることができる。 開始するには[ソロステーキング](/staking/solo/)を参照してください。 -![アプリケーションやノードを介してイーサリアムにアクセスする方法](./nodes.png) +![アプリケーションとノードを介してイーサリアムにアクセスする方法](./nodes.png) ### ネットワークのメリット {#network-benefits} イーサリアムの健全性、セキュリティ、運用レジリエンスにとって、ノードの多様性は重要です。 - フルノードがコンセンサスルールを強制するため、ルールに従わないブロックが受け入れられることはない。 これはネットワークのセキュリティ強化につながる(すべてのノードが完全な検証ができないライトノードの場合では、バリデータがネットワークに対して攻撃できる恐れがあるため)。 -- [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/#what-is-pos)の暗号経済的な防御を上回る攻撃の場合、正しいチェーンを選ぶフルノードによって、社会的回復が行われる。 +- [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/#what-is-pos)の暗号経済的防御を乗り越える攻撃が発生した場合、正直なチェーンに従うことを選択したフルノードによってソーシャルリカバリーを実行できます。 - ネットワークのノード数が増えることで、分散化の究極の目標である多様で堅牢なネットワークとなり、検閲耐性があり、信頼性の高いシステムになる。 -- フルノードからのブロックチェーンデータに依存するライトクライアントに、ブロックチェーンデータへのアクセスを提供する。 ライトノードはブロックチェーンの全データを保持せず、代わりに、[ブロックヘッダーのステートルート](/developers/docs/blocks/#block-anatomy)を利用してデータを検証する。 また、必要に応じて、フルノードから追加情報のリクエストを行う。 +- フルノードからのブロックチェーンデータに依存するライトクライアントに、ブロックチェーンデータへのアクセスを提供する。 ライトノードはブロックチェーン全体を保存せず、代わりに[ブロックヘッダー内のステート・ルート](/developers/docs/blocks/#block-anatomy)を介してデータを検証します。 また、必要に応じて、フルノードから追加情報のリクエストを行う。 フルノードを実行すると、バリデータを実行しなくても、イーサリアムネットワーク全体がそのメリットを享受することができます。 -## 自分のノードの運用 {#running-your-own-node} +## 独自のノードの実行 {#running-your-own-node} 自分のイーサリアムクライアントを運用してみませんか? -初心者向けの導入方法については、[ノードの運用](/run-a-node)ページをご覧ください。 +初心者向けの紹介については、[ノードを実行](/run-a-node)ページで詳細をご覧ください。 -上級者の方は、[自分のノードを立ち上げる](/developers/docs/nodes-and-clients/run-a-node/)を参照し、詳細やオプションを確認してください。 +より技術的なユーザーであれば、[独自のノードを立ち上げる](/developers/docs/nodes-and-clients/run-a-node/)方法に関する詳細とオプションを掘り下げてください。 -## 代替手段 {#alternatives} +## 代替案 {#alternatives} -自分のノードを設定するには、時間とリソースがかかりますが、必ずしも独自のインスタンスを実行する必要はありません。 サードパーティのAPIプロバイダーを利用すれば負担を軽減できます。 これらのサービスの概要については、 [ノード・アズ・ア・サービス(NaaS)](/developers/docs/nodes-and-clients/nodes-as-a-service/)で確認してください。 +自分のノードを設定するには、時間とリソースがかかりますが、必ずしも独自のインスタンスを実行する必要はありません。 サードパーティのAPIプロバイダーを利用すれば負担を軽減できます。 これらのサービスの使用概要については、[サービスとしてのノード](/developers/docs/nodes-and-clients/nodes-as-a-service/)をご覧ください。 コミュニティでパブリックなAPIを持つイーサリアムノードが運用されている場合、カスタムRPCを介してウォレットをコミュニティノードに向けることができ、ランダムなサードパーティを使うよりも、プライバシーを確保することができます。 @@ -125,18 +130,18 @@ sidebarDepth: 2 ## 実行クライアント {#execution-clients} -イーサリアムコミュニティでは、異なるプログラミング言語で、さまざまなチームが開発した、複数のオープンソースの実行クライアント(旧称は「Eth1クライアント」または「イーサリアムクライアント」)を維持しています。 これにより、ネットワークがより強固になり、[多様性](/developers/docs/nodes-and-clients/client-diversity/)を実現しています。 理想は、どのクライアントもネットワークの大部分を占めることなく、多様性を実現し、単一障害点を減らすことです。 +イーサリアムコミュニティでは、異なるプログラミング言語で、さまざまなチームが開発した、複数のオープンソースの実行クライアント(旧称は「Eth1クライアント」または「イーサリアムクライアント」)を維持しています。 これにより、ネットワークはより強力で[多様](/developers/docs/nodes-and-clients/client-diversity/)になります。 理想は、どのクライアントもネットワークの大部分を占めることなく、多様性を実現し、単一障害点を減らすことです。 -この表は、いくつかのクライアントの情報をまとめたものです。 これらのクライアントはすべて、[クライアントテスト](https://github.com/ethereum/tests)に合格しており、ネットワークのアップグレードによって最新の状態に維持されています。 +この表は、いくつかのクライアントの情報をまとめたものです。 それらはすべて[クライアントテスト](https://github.com/ethereum/tests)に合格しており、ネットワークのアップグレードに合わせて最新の状態を保つために積極的に維持されています。 -| クライアント | 言語 | オペレーティングシステム | ネットワーク | 同期戦略 | 状態剪定 | -| ----------------------------------------------------------------------- | ---------- | ------------------- | ------------------------- | -------------------------------------------------------- | ---------- | -| [Geth](https://geth.ethereum.org/) | Go | Linux、Windows、macOS | Mainnet, Sepolia, Holesky | [スナップ](#snap-sync)、[フル](#full-sync) | アーカイブ、プルーン | -| [Nethermind](https://www.nethermind.io/) | C#、.NET | Linux、Windows、macOS | Mainnet, Sepolia, Holesky | [スナップ](#snap-sync) (without serving)、高速、[フル](#full-sync) | アーカイブ、プルーン | -| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux、Windows、macOS | Mainnet, Sepolia, Holesky | [スナップ](#snap-sync)、[高速](#fast-sync)、[フル](#full-sync) | アーカイブ、プルーン | -| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux、Windows、macOS | Mainnet, Sepolia, Holesky | [フル](#full-sync) | アーカイブ、プルーン | -| [Reth](https://reth.rs/) | Rust | Linux、Windows、macOS | Mainnet, Sepolia, Holesky | [フル](#full-sync) | アーカイブ、プルーン | -| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(ベータ)_ | TypeScript | Linux、Windows、macOS | Sepolia, Holesky | [フル](#full-sync) | プルーン | +| クライアント | 言語 | オペレーティングシステム | ネットワーク | 同期戦略 | 状態剪定 | +| ------------------------------------------------------------------------------------------- | ----------------------- | ------------------- | --------------------- | ------------------------------------------------------------------ | ---------- | +| [Geth](https://geth.ethereum.org/) | Go | Linux、Windows、macOS | Mainnet、Sepolia、Hoodi | [スナップ](#snap-sync)、[フル](#full-sync) | アーカイブ、プルーン | +| [Nethermind](https://www.nethermind.io/) | C#、.NET | Linux、Windows、macOS | Mainnet、Sepolia、Hoodi | [スナップ](#snap-sync)(サービングなし)、高速、[フル](#full-sync) | アーカイブ、プルーン | +| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux、Windows、macOS | Mainnet、Sepolia、Hoodi | [スナップ](#snap-sync)、[高速](#fast-sync)、[フル](#full-sync) | アーカイブ、プルーン | +| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux、Windows、macOS | Mainnet、Sepolia、Hoodi | [フル](#full-sync) | アーカイブ、プルーン | +| [Reth](https://reth.rs/) | Rust | Linux、Windows、macOS | Mainnet、Sepolia、Hoodi | [フル](#full-sync) | アーカイブ、プルーン | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(ベータ版)_ | TypeScript | Linux、Windows、macOS | Sepolia、Hoodi | [フル](#full-sync) | プルーン | サポートされているネットワークの詳細については、[イーサリアムネットワーク](/developers/docs/networks/)をご覧ください。 @@ -146,17 +151,17 @@ sidebarDepth: 2 ハイパーレジャーBesuは、パブリックネットワークと許可型ネットワークの両方に対応する、エンタープライズグレードのイーサリアムクライアントです。 イーサリアムメインネットのすべての機能を実行するクライアントは、ConsenSys社によりサポートされています。トレースからGraphQLまで、幅広いモニタリング機能を備えており、公開コミュニティチャンネルと企業向けの商用SLAの両方に対応しています。 また、Javaで実装されており、Apache 2.0ライセンスです。 -機能とセットアップの詳細については、Besuの完全版[ドキュメント](https://besu.hyperledger.org/en/stable/)に記載されています。 +Besuの広範な[ドキュメント](https://besu.hyperledger.org/en/stable/)では、その機能と設定に関するすべての詳細が案内されています。 ### Erigon {#erigon} Erigon(旧称: Turbo-Geth)は、Go Ethereumのフォークから派生したものであり、速度とディスク容量の効率を重視しています。 イーサリアムの完全に再設計された実装であり、現在はGoで書かれていますが、他の言語での実装も開発中です。 Erigonは、より高速で、よりモジュール化されており、より最適化されたイーサリアムの実装を目指しています。 2TB程度のディスク容量があれば、3日以内にフルアーカイブノードの同期が可能です。 -### Go Ethereum(Geth) {#geth} +### Go Ethereum {#geth} Go Ethereum(略してGeth)は、イーサリアムプロトコルのオリジナルの実装の1つです。 現在、最も普及しているクライアントであり、ユーザーやデベロッパー向けのツールの種類も豊富です。 Go言語で実装されており、完全にオープンソースで、GNU LGPL v3ライセンスの下で提供されています。 -Gethの詳細については、[ドキュメント](https://geth.ethereum.org/docs/)を参照してください。 +Gethの詳細については、その[ドキュメント](https://geth.ethereum.org/docs/)をご覧ください。 ### Nethermind {#nethermind} @@ -166,7 +171,7 @@ Nethermindは、C# .NETの技術スタックで開発されたイーサリアム - 状態アクセス - ネットワーキングや、Prometheus/Grafanaダッシュボード、Seqエンタープライズロギングサポート、JSON-RPCトレーシング、分析プラグインなどの豊富な機能 -また、Nethermindは、[詳細なドキュメント](https://docs.nethermind.io)、強力な開発サポート、オンラインコミュニティ、プレミアムユーザー向けの24時間年中無休のサポートなど、充実したサポート体制を整えています。 +Nethermindには[詳細なドキュメント](https://docs.nethermind.io)もあり、強力な開発者サポート、オンラインコミュニティ、プレミアムユーザー向けの24時間365日のサポートが利用可能です。 ### Reth {#reth} @@ -174,7 +179,7 @@ Reth (Rust Ethereumの略) は、使いやすさ、高度なモジュール化 Rethは本番環境での利用が可能で、ステーキングや高稼働サービスなどのミッションクリティカルな環境での使用に適しています。 また、RPC、MEV、インデックス作成、シミュレーション、P2P活動など、高いパフォーマンスと大きなマージンが求められるユースケースでも優れた性能を発揮します。 -詳細は[Reth Book](https://reth.rs/)や[Reth GitHubリポジトリ](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth)をご覧ください。 +[Reth Book](https://reth.rs/)または[Reth GitHubリポジトリ](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth)を確認して詳細をご覧ください。 ### 開発中 {#execution-in-development} @@ -184,51 +189,58 @@ Rethは本番環境での利用が可能で、ステーキングや高稼働サ EthereumJS実行クライアント(EthereumJS)は、TypeScriptで書かれ、いくつかのパッケージで構成されています。ブロック、トランザクション、マークルパトリシアツリークラスで表すコアイーサリアムプリミティブや、イーサリアム仮想マシン(EVM)、ブロックチェーンクラス、DevP2Pネットワークスタックの実装などのコアクライアントコンポーネントを含みます。 -詳細については、EthereumJSの[ドキュメント](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master)を参照してください。 +その[ドキュメント](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master)を読んで詳細をご覧ください ## コンセンサスクライアント {#consensus-clients} -[コンセンサスアップグレード](/roadmap/beacon-chain/)に対応する複数のコンセンサスクライアント(旧称: 「Eth2」クライアント) があります。 コンセンサスクライアントは、フォーク選択アルゴリズム、アテステーションの処理、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)の報酬とペナルティの管理など、コンセンサスに関連するロジックをすべて担っています。 +[コンセンサスのアップグレード](/roadmap/beacon-chain/)をサポートするために、複数のコンセンサスクライアント(以前は「Eth2」クライアントとして知られていました)が存在します。 これらは、フォーク選択アルゴリズム、アテステーションの処理、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)の報酬とペナルティの管理など、コンセンサス関連のすべてのロジックを担当します。 -| クライアント | 言語 | オペレーティングシステム | ネットワーク | -| ------------------------------------------------------------- | ---------- | ------------------- | ------------------------------------------------ | -| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux、Windows、macOS | ビーコンチェーン、Goerli、Pyrmont、Sepolia、Ropstenなど | -| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux、Windows、macOS | ビーコンチェーン、Goerli、Sepolia、Ropstenなど | -| [Nimbus](https://nimbus.team/) | Nim | Linux、Windows、macOS | ビーコンチェーン、Goerli、Sepolia、Ropstenなど | -| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux、Windows、macOS | ビーコンチェーン、Gnosis、Goerli、Pyrmont、Sepolia、Ropstenなど | -| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux、Windows、macOS | ビーコンチェーン、Gnosis、Goerli、Sepolia、Ropstenなど | +| クライアント | 言語 | オペレーティングシステム | ネットワーク | +| ------------------------------------------------------------- | ---------- | ------------------- | ------------------------------------------- | +| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux、Windows、macOS | Beacon Chain、Hoodi、Pyrmont、Sepoliaなど | +| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux、Windows、macOS | Beacon Chain、Hoodi、Sepoliaなど | +| [Nimbus](https://nimbus.team/) | Nim | Linux、Windows、macOS | Beacon Chain、Hoodi、Sepoliaなど | +| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux、Windows、macOS | Beacon Chain、Gnosis、Hoodi、Pyrmont、Sepoliaなど | +| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux、Windows、macOS | Beacon Chain、Gnosis、Hoodi、Sepoliaなど | +| [Grandine](https://docs.grandine.io/) | Rust | Linux、Windows、macOS | Beacon Chain、Hoodi、Sepoliaなど | ### Lighthouse {#lighthouse} Lighthouseは、Apache-2.0ライセンスの下、Rustで書かれたコンセンサスクライアントの実装です。 Sigma Primeによって管理されており、ビーコンチェーン誕生以降、安定したパフォーマンスで稼働しています。 また、さまざまなエンタープライズやステーキングプール、個人からの信頼を得ています。 デスクトップPCから高度な自動デプロイまで、あらゆる環境における安全性、パフォーマンス、相互運用性を目指しています。 -ドキュメントは、[Lighthouse Book](https://lighthouse-book.sigmaprime.io/)で参照できます。 +ドキュメントは[Lighthouse Book](https://lighthouse-book.sigmaprime.io/)にあります ### Lodestar {#lodestar} Lodestarは、LGPL-3.0ライセンスの下、Typescriptで書かれた、本番環境に対応したコンセンサスクライアントの実装です。 ChainSafe Systems社によって管理されており、ソロステーカー、デベロッパー、研究者向けのコンセンサスクライアントの中で最も新しいものです。 Loadstarは、イーサリアムプロトコルをJavaScriptで実装した、ビーコンノードとバリデータクライアントから構成されています。 ライトクライアントでのイーサリアムの使いやすさを向上させ、より多くのデベロッパーグループがアクセスできるようにすることで、エコシステムの多様性にさらに貢献することを目指しています。 -詳細については、[Lodestarのウェブサイト](https://lodestar.chainsafe.io/)をご覧ください。 +詳細は[Lodestarウェブサイト](https://lodestar.chainsafe.io/)でご覧いただけます ### Nimbus {#nimbus} Nimbusは、Apache-2.0ライセンスの下、Nimで書かれたコンセンサスクライアントの実装です。 ソロステーカーやステーキングプールで使用されており、本番環境に対応したクライアントです。 Nimbusはリソース効率を重視して設計されており、リソースに制限のあるデバイスや企業のインフラストラクチャ上でも、安定性や報酬のパフォーマンスを損なわずに簡単に実行できます。 リソース利用量が少ないと、ネットワークに負荷がかかっても、クライアントは安全に動作します。 -詳しくは、[Nimbusのドキュメント](https://nimbus.guide/)をご覧ください。 +[Nimbusドキュメント](https://nimbus.guide/)で詳細をご覧ください ### Prysm {#prysm} Prysmは、GPL-3.0ライセンスの下、Goで書かれたフル機能のオープンソースのコンセンサスクライアントです。 オプションのWebアプリのUIを備え、自宅でステーキングするユーザーと機関ユーザーの両方に向けて、ユーザーエクスペリエンス、ドキュメント、設定可能性を優先しているのが特徴です。 -詳しくは、[Prysmのドキュメント](https://prysm.offchainlabs.com/docs/)をご覧ください。 +[Prysmドキュメント](https://prysm.offchainlabs.com/docs/)にアクセスして詳細をご覧ください。 ### Teku {#teku} Tekuは、オリジナルのビーコンチェーンで誕生したクライアントの1つです。 セキュリティ、堅牢性、安定性、使いやすさ、パフォーマンスなどの基本的な目標に加えて、Tekuはさまざまなコンセンサスクライアント標準に完全に準拠することを特に重視しています。 -Tekuは、非常に柔軟なデプロイメントオプションを提供しています。 ビーコンノードとバリデータクライアントをシングルプロセスとして実行できるので、ソロステーカーにとって非常に便利です。または、高度なステーキング操作を行う場合は、個別にノードを実行することもできます。 さらに、署名キーのセキュリティとスラッシング保護のために、[Web3Signer](https://github.com/ConsenSys/web3signer/)と完全に互換性があります。 +Tekuは、非常に柔軟なデプロイメントオプションを提供しています。 ビーコンノードとバリデータクライアントをシングルプロセスとして実行できるので、ソロステーカーにとって非常に便利です。または、高度なステーキング操作を行う場合は、個別にノードを実行することもできます。 さらに、Tekuは署名キーのセキュリティとスラッシング保護のために[Web3Signer](https://github.com/ConsenSys/web3signer/)と完全に相互運用可能です。 -Tekuは、Javaで実装されており、Apache 2.0でライセンスされています。 BesuやWeb3Signerを手がけるConsenSys社のプロトコルチームによって開発されています。 詳しくは、[Tekuのドキュメント](https://docs.teku.consensys.net/en/latest/)をご覧ください。 +Tekuは、Javaで実装されており、Apache 2.0でライセンスされています。 BesuやWeb3Signerを手がけるConsenSys社のプロトコルチームによって開発されています。 [Tekuドキュメント](https://docs.teku.consensys.net/en/latest/)で詳細をご覧ください。 + +### Grandine {#grandine} + +Grandineは、GPL-3.0ライセンスの下、Rustで書かれたコンセンサスクライアントの実装です。 Gradineコアチームによって管理されており、高速・高性能かつ軽量です。 ラズベリーパイのようなリソースの限られたデバイスで動かすソロステーカーから、数万のバリデータを運用する大規模機関のステーカーまで、幅広く対応することができます。 + +ドキュメントは[Grandine Book](https://docs.grandine.io/)にあります ## 同期モード {#sync-modes} @@ -240,39 +252,39 @@ Tekuは、Javaで実装されており、Apache 2.0でライセンスされて 実行レイヤーは、ブロックチェーンのワールドステートを再実行するモードから、信頼できるチェックポイントからチェーンの最新部分にのみ同期するモードまで、さまざまなユースケースに合わせて異なるモードで実行できます。 -#### フル同期(Full sync) {#full-sync} +#### フル同期 {#full-sync} フル同期では、すべてのブロック (ヘッダーとブロックボディを含む) をダウンロードし、ジェネシスブロックからすべてのブロックを実行することで、ブロックチェーンの状態を段階的に再生成します。 - すべてのトランザクションを検証することにより、信用する必要性を最小限に抑え、最高のセキュリティを提供 - トランザクション数が増えると、全トランザクションを処理するのに数日から数週間かかることがある -[アーカイブノード](#archive-node)は、フル同期を実行して、すべてのブロック内のすべてのトランザクションによって行われた状態変化の完全な履歴を構築し、保持します。 +[アーカイブノード](#archive-node)はフル同期を実行して、すべてのブロックのすべてのトランザクションによる状態変更の完全な履歴を構築(および保持)します。 -#### 高速同期(Fast sync) {#fast-sync} +#### 高速同期 {#fast-sync} フル同期と同様に、高速同期もすべてのブロック (ヘッダー、トランザクション、レシートを含む) をダウンロードします。 しかし、高速同期は過去のトランザクションを再処理する代わりに、レシートに依存し、最新のヘッドに到達するとフルノードを提供するためにブロックのインポートと処理に切り替わります。 - 高速同期戦略 - 帯域幅の使用を優先した処理負荷の軽減 -#### スナップ同期(Snap sync) {#snap-sync} +#### スナップ同期 {#snap-sync} スナップ同期もチェーンをブロックごとに検証します。 ただし、ジェネシスブロックからではなく、「信頼できる」最新のチェックポイントから開始します。このチェックポイントは、正しいブロックチェーンの一部であることが確認されています。 ノードは、一定期間を経過したデータを削除しますが、定期的にチェックポイントを保存します。 これらのスナップショットは、データを永続的に保存するのではなく、必要に応じてステートデータを再生成するために使用されます。 - 最速の同期戦略で、現在のイーサリアムメインネットのデフォルトです。 - セキュリティを犠牲にすることなく、多くのディスク使用量とネットワーク帯域幅を節約できます。 -[スナップ同期の詳細はこちら](https://github.com/ethereum/devp2p/blob/master/caps/snap.md) +[スナップ同期の詳細](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)。 -#### 軽量同期(Light sync) {#light-sync} +#### ライト同期 {#light-sync} ライトクライアントモードでは、すべてのブロックヘッダーとブロックデータをダウンロードし、ランダムに検証を行います。 信頼できるチェックポイントからチェーンの先端までのみを同期します。 - デベロッパーへの信頼と合意メカニズムに依存し、最新の状態のみを取得 - クライアントは数分で現在のネットワーク状態で使用できるようになる -**注: ** 現在、プルーフ・オブ・ステークのイーサリアムでは、軽量同期は利用できません。軽量同期の新しいバージョンが、まもなくリリースされる予定です。 +**注** ライト同期はまだプルーフ・オブ・ステークのイーサリアムでは機能しません。ライト同期の新しいバージョンはまもなくリリースされる予定です！ [ライトクライアントの詳細](/developers/docs/nodes-and-clients/light-clients/) @@ -280,22 +292,22 @@ Tekuは、Javaで実装されており、Apache 2.0でライセンスされて #### オプティミスティック同期 {#optimistic-sync} -オプティミスティック同期はマージ後の同期戦略で、オプトインで下位互換性を備えており、実行ノードが確立された方法で同期できます。 実行エンジンは、ビーコンブロックを完全に検証せず、_オプティミスティックに(楽観的に)_インポートすることができます。そして、最新のブロックの先頭を探し、上記の方法でチェーンの同期を開始します。 次に、実行クライアントが追いつくと、ビーコンチェーンのトランザクションの有効性をコンセンサスクライアントに通知します。 +オプティミスティック同期はマージ後の同期戦略で、オプトインで下位互換性を備えており、実行ノードが確立された方法で同期できます。 実行エンジンは、ビーコンブロックを完全に検証せずに_オプティミスティックに_(楽観的に)インポートし、最新のヘッドを見つけてから、上記の方法でチェーンの同期を開始できます。 次に、実行クライアントが追いつくと、ビーコンチェーンのトランザクションの有効性をコンセンサスクライアントに通知します。 [オプティミスティック同期の詳細](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) #### チェックポイント同期 {#checkpoint-sync} -チェックポイント同期は、弱い主観性の同期とも呼ばれ、ビーコンノードの同期において優れたユーザーエクスペリエンスを提供します。 これは、ジェネシスではなく、最近の弱い主観性チェックポイントからビーコンチェーンを同期できるようにする[弱い主観性](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/)の前提に基づいています。 チェックポイント同期は、[ジェネシス](/glossary/#genesis-block)からの同期と同様の信頼性の前提を保ちながら、初期同期時間を大幅に短縮します。 +チェックポイント同期は、弱い主観性の同期とも呼ばれ、ビーコンノードの同期において優れたユーザーエクスペリエンスを提供します。 これは[弱い主観性](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/)の仮定に基づいており、ジェネシスからではなく最近の弱い主観性のチェックポイントからビーコンチェーンを同期できます。 チェックポイント同期は、[ジェネシス](/glossary/#genesis-block)からの同期と同様の信頼性の仮定で、初期同期時間を大幅に短縮します。 実運用では、ノードがリモートサービスに接続して最新のファイナライズされた状態をダウンロードし、その時点からデータの検証を続けます。 データを提供する第三者は信頼されるべき存在であり、慎重に選ぶ必要があります。 [チェックポイント同期](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)の詳細 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアム101 - パート2 - ノードについての理解](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– 2019年2月13日 - Wil Barnes_ -- [イーサリアムフルノードの運用: 手間を省きたい人向けのガイド](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _2019年11月7日 - Justin Leroux_ +- [イーサリアム 101 - パート 2 - ノードを理解する](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes、2019年2月13日_ +- [イーサリアムフルノードの実行：やる気のない人向けガイド](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux、2019年11月7日_ ## 関連トピック {#related-topics} @@ -304,4 +316,4 @@ Tekuは、Javaで実装されており、Apache 2.0でライセンスされて ## 関連チュートリアル {#related-tutorials} -- [MicroSDカードを挿入するだけで、Raspberry Pi 4をバリデータノードにする – インストールガイド](/developers/tutorials/run-node-raspberry-pi/) _– Raspberry Pi 4をフラッシュし、イーサネットケーブルを接続し、SSDディスクを接続して電源を入れることで、Raspberry Pi 4を、実行レイヤー(メインネット)とコンセンサスレイヤー(ビーコンチェーン/バリデータ)の両方もしくは片方を実行するフルイーサリアムノードにする。_ +- [MicroSDカードを書き込むだけでRaspberry Pi 4をバリデーターノードに変える – インストールガイド](/developers/tutorials/run-node-raspberry-pi/) _– Raspberry Pi 4を書き込み、イーサネットケーブルを差し込み、SSDディスクを接続して電源を入れることで、Raspberry Pi 4を、実行レイヤー(メインネット)および/またはコンセンサスレイヤー(ビーコンチェーン/バリデーター)を実行する完全なイーサリアムノードに変えることができます。_ diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/light-clients/index.md index 587be2b2d34..2664236cbeb 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/light-clients/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/light-clients/index.md @@ -1,6 +1,6 @@ --- -title: ライトクライアント -description: イーサリアムライトクライアントの概要 +title: "ライトクライアント" +description: "イーサリアムライトクライアントの概要" lang: ja --- @@ -12,7 +12,7 @@ lang: ja ## ライトクライアントが動作する仕組み {#how-do-light-clients-work} -イーサリアムがプルーフ・オブ・ステークに基づいたコンセンサスメカニズムを使い始めた当時、ライトクライアントを特別にサポートするための新しいインフラストラクチャが導入されました。 この仕組みは、**同期委員会**として機能する512台あるバリデータのサブセットを1.1日ごとにランダムに選ぶことで機能します。 同期委員会は、最新のブロックのヘッダーに署名します。 すべてのブロックヘッダーには、同期委員会のバリデータによる集約された署名と、どのバリデータが署名し、どのバリデーターが署名しなかったかを示す「ビットフィールド」があります。 また、各ヘッダーには、次のブロックの署名に参加することになっているバリデータのリストもあります。 つまり、ライトクライアントでは、受信したデータの署名が同期委員会のものであることがすぐに確認できます。また、前のブロックから予想したデータと受信したデータを比較することで、同期委員会が本物であることも確認できます。 この方法で、ライトクライアントは、実際にブロック自体をダウンロードせずに、要約された情報を含むヘッダーだけで、最新のイーサリアムのブロックが持つ情報を更新し続けることができます。 +イーサリアムがプルーフ・オブ・ステークに基づいたコンセンサスメカニズムを使い始めた当時、ライトクライアントを特別にサポートするための新しいインフラストラクチャが導入されました。 その仕組みは、1.1日ごとに512のバリデータのサブセットをランダムに選択し、**同期委員会**として機能させるというものです。 同期委員会は、最新のブロックのヘッダーに署名します。 各ブロックヘッダーには、同期委員会のバリデータによる集約された署名と、どのバリデータが署名し、どのバリデータが署名しなかったかを示す「ビットフィールド」が含まれています。 また、各ヘッダーには、次のブロックの署名に参加することになっているバリデータのリストもあります。 つまり、ライトクライアントでは、受信したデータの署名が同期委員会のものであることがすぐに確認できます。また、前のブロックから予想したデータと受信したデータを比較することで、同期委員会が本物であることも確認できます。 この方法で、ライトクライアントは、実際にブロック自体をダウンロードせずに、要約された情報を含むヘッダーだけで、最新のイーサリアムのブロックが持つ情報を更新し続けることができます。 実行レイヤーでは、ライト実行クライアントの仕様が統一されていません。 ライト実行クライアントの範囲は、フル実行クライアントの「ライトモード」とは異なる場合があります。「ライトモード」では、フルノードと同じEVMとネットワーク機能をすべて備えています。しかし、関連するデータをダウンロードせずにブロックヘッダーのみを検証するか、イーサリアムとのやり取りにおいてリクエストをRPCプロバイダーへ転送することに依存した、よりシンプルなクライアントになるかもしれません。 @@ -32,7 +32,7 @@ lang: ja ストレージやメモリ、処理能力が小さいデバイスでも、イーサリアムノードを実行できるようになることは、ライトクライアントによって実現される重要なイノベーションひとつです。 現在のイーサリアムノードは、大量のコンピューティングリソースを必要としますが、ライトクライアントはブラウザに埋め込むことができ、携帯電話、さらにはスマートウォッチなどの小型デバイスでも実行できる可能性があります。 つまり、携帯電話でイーサリアムウォレットと組み込みクライアントを実行できるということです。 その結果、モバイルウォレットはデータに関して中央集権的なデータプロバイダーに依存する必要がなくなり、より分散化された運用が可能になります。 -この拡張により、**IoT(モノのインターネット)**デバイスでもライトクライアントを実行できるようになります。 ライトクライアントでは、同期委員会によって提供されるセキュリティ保証を活用して、トークンの残高やNFTの所有権を即座に証明できます。これは、IoTネットワーク上でのさまざまな用途につながります。 例えば、[自転車のレンタルサービス](https://youtu.be/ZHNrAXf3RDE?t=929)を想像してみてください。ライトクライアントが組み込まれているアプリを使用して、そのレンタルサービスのNFTを所有していることをすぐに確認し、自転車のロックを解除して、乗ることができます。 +この延長線上にあるのが、**モノのインターネット(IoT)**デバイスの有効化です。 ライトクライアントでは、同期委員会によって提供されるセキュリティ保証を活用して、トークンの残高やNFTの所有権を即座に証明できます。これは、IoTネットワーク上でのさまざまな用途につながります。 ライトクライアントが埋め込まれたアプリを使い、あなたがレンタルサービスのNFTを所有していることを素早く確認し、そうであれば自転車のロックを解除して乗れるようにする、そんな[自転車レンタルサービス](https://youtu.be/ZHNrAXf3RDE?t=929)を想像してみてください！ ライトクライアントは、イーサリアムのロールアップにもメリットがあります。 ロールアップの大きな問題のひとつは、イーサリアムメインネットからロールアップに資金を移動するブリッジを標的としたハッキングです。 脆弱性のひとつが、ユーザーがブリッジに入金したことを検出するためにロールアップが使用するオラクルです。 オラクルが不正なデータを提供すると、ロールアップはブリッジに入金があったと誤解し、誤って資金をリリースしてしまう可能性があります。 ロールアップに組み込まれたライトクライアントは、汚染されたオラクルを保護するのに役立ちます。なぜなら、ブリッジへの入金時に、トークンをリリースする前に、ロールアップで検証できる証明を添付できるからです。 このコンセプトは、他のチェーン間ブリッジにも適用できます。 @@ -43,19 +43,19 @@ lang: ja 現在、さまざまなライトクライアントの開発が進められています。ライトクライアントには、実行クライアント、コンセンサスクライアント、実行およびコンセンサスクライアントを結合したものがあります。 本ページの執筆時点で周知となっているライトクライアントの実装は、次の通りです。 - [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): TypeScriptで実装されたコンセンサスライトクライアント -- [Helios](https://github.com/a16z/helios): Rustで実装された実行およびコンセンサスを結合したライトクライアント -- [Geth](https://github.com/ethereum/go-ethereum/tree/master/light): Goで実装された実行クライアントのライトモード(開発中) +- [Helios](https://github.com/a16z/helios): Rustで実装された、実行とコンセンサスを組み合わせたライトクライアント +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): Goで実装された実行クライアント用のライトモード(開発中) - [Nimbus](https://nimbus.guide/el-light-client.html): Nimで実装されたコンセンサスライトクライアント 現時点では、これらはまだ本番環境で使用できるものではありません。 -また、ライトクライアントがイーサリアムのデータにアクセスする方法の改善にも、多くの作業が必要です。 現状、ライトクライアントは、クライアント/サーバーモデルを使用したフルノードへのRPCリクエストが必要ですが、将来的には、[ポータルネットワーク](https://www.ethportal.net/)などのピアツーピアのゴシッププロトコルを使用して、ライトクライアントに対してデータを提供できるようになります。 +また、ライトクライアントがイーサリアムのデータにアクセスする方法の改善にも、多くの作業が必要です。 現在、ライトクライアントはクライアント/サーバーモデルでフルノードへのRPCリクエストに依存していますが、将来的にはピアツーピアのゴシッププロトコルを使用してライトクライアントにデータを供給できる[Portal Network](https://www.ethportal.net/)などの専用ネットワークを使用し、より分散化された方法でデータが要求されるようになる可能性があります。 -[バークルツリー](/roadmap/verkle-trees/)や[ステートレス](/roadmap/statelessness/)などの[ロードマップ](/roadmap/)アイテムの導入により、ライトクライアントのセキュリティ保証もフルクライアントと同等になるでしょう。 +[Verkleツリー](/roadmap/verkle-trees/)や[ステートレス性](/roadmap/statelessness/)といった他の[ロードマップ](/roadmap/)項目の導入により、最終的にライトクライアントのセキュリティ保証はフルクライアントと同等になるでしょう。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [Zsolt FelfodhiによるGethライトクライアントの説明](https://www.youtube.com/watch?v=EPZeFXau-RE) -- [Etan Kisslingによるライトクライアントネットワークの説明](https://www.youtube.com/watch?v=85MeiMA4dD8) -- [Etan Kisslingによるマージ後のライトクライアントの説明](https://www.youtube.com/watch?v=ZHNrAXf3RDE) -- [Piper Merriamによる記事『機能的なライトクライアントを実現するための困難な道のり』](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) +- [Zsolt Felfodhi氏: Gethライトクライアントについて](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [Etan Kissling氏: ライトクライアントのネットワーキングについて](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [Etan Kissling氏: マージ後のライトクライアントについて](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Piper Merriam氏: 機能的なライトクライアントへの曲がりくねった道のり](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/node-architecture/index.md index cf25c719662..85f7640d357 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/node-architecture/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/node-architecture/index.md @@ -1,26 +1,28 @@ --- -title: ノードアーキテクチャ -description: イーサリアムノードの構成についての概要 +title: "ノードアーキテクチャ" +description: "イーサリアムノードの構成についての概要" lang: ja --- -イーサリアムノードは、[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)の2つのクライアントで構成されています。 +イーサリアムのノードは、[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)の2つのクライアントで構成されています。 新しいブロックを提案するノードでは、[バリデータクライアント](#validators)も実行する必要があります。 -イーサリアムが[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)を使っていた時は、フルイーサリアムノードを実行するためには、実行クライアントだけで十分でした。 しかし、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pow/)の実装以降、実行クライアントに加えて、[「コンセンサスクライアント」](/developers/docs/nodes-and-clients/#consensus-clients)と呼ばれる別のソフトウェアも必要になりました。 +イーサリアムが[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)を採用していた頃は、実行クライアントだけで完全なイーサリアムノードを稼働させることができました。 しかし、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pow/)の実装以降、実行クライアントは[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)と呼ばれる別のソフトウェアと併用しなければならなくなりました。 以下の図は、2つのイーサリアムクライアント間の関係を示しています。 それぞれのクライアントは、独自のピアツーピア(P2P)・ネットワークに接続しています。 実行クライアントは、ピアツーピア・ネットワークでトランザクションをゴシップし、ローカルのトランザクションプールを管理することができます。一方、コンセンサスクライアントは、ピアツーピア・ネットワークでブロックをゴシップし、コンセンサスを確立し、チェーンの成長を促進します。そのため、別々のピアツーピア・ネットワークが必要になります。 ![](node-architecture-text-background.png) -この2つのクライアント構造を実現するには、コンセンサスクライアントがトランザクションのバンドルを実行クライアントに渡す必要があります。 実行クライアントは、トランザクションがイーサリアムのルールに違反していないこと、提案されたイーサリアムの状態に対する更新が正しいことを確認するために、トランザクションをローカルで実行します。 同様に、ノードがブロック生成者に選ばれた場合、コンセンサスクライアントは、新しいブロックに含めるトランザクションのバンドルをGethに要求し、それらのトランザクションを実行してグローバル状態を更新する必要があります。 このクライアント間の通信は、[エンジンAPI](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)使ったローカルRPC接続で行われます。 +_実行クライアントには、Erigon、Nethermind、Besuなど、いくつかの選択肢があります_。 + +この2つのクライアント構造を機能させるには、コンセンサスクライアントがトランザクションのバンドルを実行クライアントに渡す必要があります。 実行クライアントは、トランザクションがイーサリアムのルールに違反していないこと、提案されたイーサリアムの状態に対するアップデートが正しいことを検証するために、トランザクションをローカルで実行します。 ノードがブロック生成者に選ばれた場合、そのコンセンサスクライアントのインスタンスは、新しいブロックに含めるトランザクションのバンドルを実行クライアントに要求し、それらのトランザクションを実行してグローバル状態をアップデートします。 コンセンサスクライアントは、[Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)を使用して、ローカルRPC接続を介して実行クライアントを駆動します。 ## 実行クライアントの役割 {#execution-client} -実行クライアントは、トランザクションの処理、トランザクションのゴシップ、状態の管理、イーサリアム仮想マシン([EVM](/developers/docs/evm/))のサポートを行います。 しかし、ブロックの構築、ブロックのゴシップ、またはコンセンサスロジックの処理は、**行いません**。 これらは、コンセンサスクライアントが行います。 +実行クライアントは、トランザクションの検証、処理、ゴシップ、状態管理、そしてイーサリアム仮想マシン ([EVM](/developers/docs/evm/)) のサポートを担当します。 ブロックの構築、ブロックのゴシップ、コンセンサスロジックの処理は担当**しません**。 これらは、コンセンサスクライアントが行います。 -実行クライアントは、トランザクションのリスト、更新された状態ツリー、その他の実行に関わるデータ等の実行ペイロードを作成します。 コンセンサスクライアントは、各ブロックごとに実行ペイロードを取り込みます。 実行クライアントには、新しいブロックでトランザクションを再実行して、トランザクションが有効であることを確認する役割もあります。 [イーサリアム仮想マシン(EVM)](/developers/docs/evm)と呼ばれる、実行クライアントに組み込まれたコンピュータ上でトランザクションが実行されます。 +実行クライアントは、トランザクションのリスト、更新された状態ツリー、その他の実行に関わるデータ等の実行ペイロードを作成します。 コンセンサスクライアントは、各ブロックごとに実行ペイロードを取り込みます。 実行クライアントには、新しいブロックでトランザクションを再実行して、トランザクションが有効であることを確認する役割もあります。 トランザクションの実行は、[イーサリアム仮想マシン(EVM)](/developers/docs/evm)として知られる、実行クライアントに組み込まれたコンピュータ上で行われます。 -また、実行クライアントは、[RPCメソッド](/developers/docs/apis/json-rpc)を通じてイーサリアムへのユーザーインターフェースを提供します。これにより、ユーザーは、イーサリアムブロックチェーンにクエリを実行したり、トランザクションを送信したり、スマートコントラクトをデプロイしたりすることができます。 [Web3js](https://docs.web3js.org/)や[Web3py](https://web3py.readthedocs.io/en/v5/)などのライブラリや、ブラウザウォレットなどのユーザーインターフェースでは、RPC呼び出しを処理するのが一般的です。 +実行クライアントは、[RPCメソッド](/developers/docs/apis/json-rpc)を介してイーサリアムへのユーザーインターフェースも提供します。これにより、ユーザーはイーサリアムブロックチェーンへのクエリ、トランザクションの送信、スマートコントラクトのデプロイが可能になります。 RPCコールは、[Web3js](https://docs.web3js.org/)や[Web3py](https://web3py.readthedocs.io/en/v5/)のようなライブラリ、またはブラウザウォレットなどのユーザーインターフェースによって処理されるのが一般的です。 要約すると、実行クライアントは、以下の役割を担っています。 @@ -35,23 +37,23 @@ lang: ja ## バリデータ {#validators} -ノードオペレーターは、デポジットコントラクトに32ETHを入金することで、コンセンサスクライアントにバリデータを追加することができます。 バリデータクライアントは、コンセンサスクライアントにバンドルされており、いつでもノードに追加することができます。 バリデータは、アテステーションとブロック提案を行います。 ノードがETHで報酬を得たり、ペナルティやスラッシングによってETHを失うのは、バリデータが担う責任です。 バリデータソフトウェアを実行することで、ノードは新しいブロックの提案候補者となることができます。 +ステーキングを行い、バリデータソフトウェアを実行することで、ノードは新しいブロックの提案候補者となることができます。 ノードオペレーターは、デポジットコントラクトに32ETHを入金することで、コンセンサスクライアントにバリデータを追加することができます。 バリデータクライアントは、コンセンサスクライアントにバンドルされており、いつでもノードに追加することができます。 バリデータは、アテステーションとブロック提案を行います。 これにより、ノードが報酬を得られるようになる一方、ペナルティやスラッシングによってETHを失うこともあります。 -[ステーキングの詳細](/staking/) +[ステーキングの詳細](/staking/)。 ## ノードのコンポーネントの比較 {#node-comparison} -| 実行クライアント | コンセンサスクライアント | バリデータ | -| --------------------------------- | ------------------------------- | ----------------- | -| ピアツーピア・ネットワークを介したトランザクションのゴシップを行う | ピアツーピアを介したブロックとアテステーションのゴシップを行う | ブロックの提案を行う | -| トランザクションを実行/再実行する | フォークチョイスアルゴリズムを実行する | 報酬またはペナルティを発生させる | -| 受信した状態の変更を検証する | チェーンの先頭を追跡する | アテステーションを作成する | -| 状態ツリーとレシートツリーを管理する | ビーコン状態(コンセンサス情報や実行情報を含む) を管理する | ステークには32ETHが必要となる | -| 実行ペイロードを作成する | RANDAO内に蓄積しているランダム性を追跡する | スラッシュされる可能性がある | -| イーサリアムとやり取りできるJSON-RPC APIを公開する | 正当化とファイナライズを追跡する | | +| 実行クライアント | コンセンサスクライアント | バリデータ | +| --------------------------------- | ------------------------------------------------------------------------------------------- | ----------------- | +| ピアツーピア・ネットワークを介したトランザクションのゴシップを行う | ピアツーピアを介したブロックとアテステーションのゴシップを行う | ブロックの提案を行う | +| トランザクションを実行/再実行する | フォークチョイスアルゴリズムを実行する | 報酬またはペナルティを発生させる | +| 受信した状態の変更を検証する | チェーンの先頭を追跡する | アテステーションを作成する | +| 状態ツリーとレシートツリーを管理する | ビーコン状態(コンセンサス情報や実行情報を含む) を管理する | ステークには32ETHが必要となる | +| 実行ペイロードを作成する | RANDAO(バリデータの選択やその他のコンセンサスオペレーションに検証可能なランダム性を提供するアルゴリズム)に累積されたランダム性を記録する | スラッシュされる可能性がある | +| イーサリアムとやり取りできるJSON-RPC APIを公開する | 正当化とファイナライズを追跡する | | -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [プルーフオブステーク](/developers/docs/consensus-mechanisms/pos) -- [ブロック提案](/developers/docs/consensus-mechanisms/pos/block-proposal) +- [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos) +- [ブロックの提案](/developers/docs/consensus-mechanisms/pos/block-proposal) - [バリデータの報酬とペナルティ](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/nodes-as-a-service/index.md index b364aec53cf..65adaa8cab2 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/nodes-as-a-service/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -1,23 +1,23 @@ --- -title: ノード運用サービス -description: ノード運用サービス、メリットとデメリット、および人気のプロバイダーの初心者向け概要 +title: "サービスとしてのノード" +description: "ノード運用サービス、メリットとデメリット、および人気のプロバイダーの初心者向け概要" lang: ja sidebarDepth: 2 --- ## はじめに {#Introduction} -自分自身で[イーサリアムノード](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients)を実行するのは、特に始めての場合や、急速にスケーリングするときには難しい場合があります。 既に最適化されたノードインフラストラクチャを実行する[サービス](#popular-node-services)がいくつかあり、利用するとアプリケーションや製品開発に集中できるようになります。 ノード運用サービスがどのように機能するか、それらを使用するメリットとデメリット、またご興味がある方向けにプロバイダーを記載します。 +独自の[イーサリアムノード](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients)を実行することは、特に利用を開始したばかりの時期や、急速にスケーリングしている際には、困難な場合があります。 最適化されたノードインフラストラクチャをユーザーに代わって実行する[サービスが多数あり](#popular-node-services)、ユーザーは代わりにアプリケーションやプロダクトの開発に集中できます。 ノード運用サービスがどのように機能するか、それらを使用するメリットとデメリット、またご興味がある方向けにプロバイダーを記載します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -ノードやクライアントが何かについてご存知ではない場合、[ノードとクライアント](/developers/docs/nodes-and-clients/)を参照してください。 +ノードとクライアントが何であるかをまだ理解していない場合は、[ノードとクライアント](/developers/docs/nodes-and-clients/)のページを確認してください。 ## ステーカー {#stakoooooooooooooors} -ソロステーカーは、サードパーティプロバイダーを使用せず、自分のインフラストラクチャを運用する必要があります。 これは、実行クライアントとコンセンサスクライアントの両方を実行することを意味します。 [マージ](/roadmap/merge)前は、コンセンサスクライアントのみを実行し、実行データは中央集権型のプロバイダーから取得できました。マージ後は、両方のクライアントを実行する必要はありますが、 ステーキングを容易にするサービスが提供されています。 +ソロステーカーは、サードパーティプロバイダーを使用せず、自分のインフラストラクチャを運用する必要があります。 これは、実行クライアントとコンセンサスクライアントの両方を実行することを意味します。 [マージ](/roadmap/merge)以前は、コンセンサスクライアントのみを実行し、実行データには中央集権型のプロバイダーを使用することが可能でした。これは現在では不可能であり、ソロステーカーは両方のクライアントを実行する必要があります。 ステーキングを容易にするサービスが提供されています。 -詳細については、[ノードの運用](/developers/docs/nodes-and-clients/run-a-node/)をご覧ください。 +[ノードの実行に関する詳細はこちら](/developers/docs/nodes-and-clients/run-a-node/)。 このページに記載されているサービスは、ステーキング以外のノードについてです。 @@ -25,34 +25,34 @@ sidebarDepth: 2 ノード運用サービスプロバイダーは、分散ノードクライアントの実行を代行し、利用者の負担を軽減してくれます。 -これらのサービスは通常、ブロックチェーンへの書き込みと読み込みに使用できる APIキーを提供します。 多くの場合、メインネットに加えて [イーサリアムテストネット](/developers/docs/networks/#ethereum-testnets)にもアクセスできます。 +これらのサービスは通常、ブロックチェーンへの書き込みと読み込みに使用できる APIキーを提供します。 多くの場合、メインネットに加えて[イーサリアムテストネット](/developers/docs/networks/#ethereum-testnets)へのアクセスが含まれています。 サービスによっては、自分専用ノードの運用を提供するものもあり、ロードバランサーを使用してノード間のアクティビティを分散するものもあります。 ほとんどのノードサービスとの統合は非常に簡単で、自己ホストノードを交換、またはサービス自体を切り替えるには、コードを1行変更するだけです。 -多くの場合、ノード運用サービスは様々な[ノードクライアント](/developers/docs/nodes-and-clients/#execution-clients)と[型](/developers/docs/nodes-and-clients/#node-types)を実行します。1つのAPI でクライアント固有のメソッドに加えて、フルノードとアーカイブノードにアクセスできます。 +多くの場合、ノードサービスは様々な[ノードクライアント](/developers/docs/nodes-and-clients/#execution-clients)と[種類](/developers/docs/nodes-and-clients/#node-types)を実行するため、1つのAPIでクライアント固有のメソッドに加えて、フルノードとアーカイブノードにアクセスできます。 ノード運用サービスには秘密鍵やあなたの情報を保管してはいけないことにご留意ください。 -## ノード運用サービスを利用するメリット {#benefits-of-using-a-node-service} +## ノードサービスを利用するメリット {#benefits-of-using-a-node-service} ノード運用サービスの利用の主なメリットは、自分でノードの保守と管理に時間を費やす必要がないことです。 これにより、インフラストラクチャのメンテナンスを心配する必要がなくなり、製品の構築に集中することができます。 独自のノードの運用は、ストレージから処理能力、貴重なエンジニアリング時間など、非常に高価になります。 スケーリング時にノードを多数立ち上げたり、最新バージョンにアップグレードしたり、状態の一貫性を確実にするなどの作業は、望んでいるWeb3製品の作成に必要なリソースや時間を削いでしまいます。 -## ノード運用サービス利用のデメリット {#cons-of-using-a-node-service} +## ノードサービスを利用するデメリット {#cons-of-using-a-node-service} ノード運用サービスを利用すると、製品のインフラストラクチャの中央集権化を行うことになります。 この理由から、分散性を重視するプロジェクトでは、サードパーティーにアウトソーシングするのではなく、独自ホスティングのノードが好まれることがあります。 -[自分のノードを実行するメリット](/developers/docs/nodes-and-clients/#benefits-to-you)に関する詳細 +[独自のノードを実行するメリットの詳細はこちら](/developers/docs/nodes-and-clients/#benefits-to-you)。 -## 一般的なノード運用サービス {#popular-node-services} +## 人気のノードサービス {#popular-node-services} 最も一般的なイーサリアムノードプロバイダーのリストです。不足しているものがあれば追加してください。 無料または有料ティアに加えて、各ノードサービスにより提供されるメリットと機能は異なります。ご自身の必要性に応じて、よくリサーチを行ってから最適なものを選択してください。 - [**Alchemy**](https://alchemy.com/) - - [ドキュメント](https://docs.alchemyapi.io/) + - [ドキュメント](https://www.alchemy.com/docs/) - 機能 - 月間3億のコンピュートユニット(約3千万件のgetLatestBlockリクエスト)の最大無料ティア - Polygon、Starknet、Optimism、Arbitrumなどの複数のチェーン対応 @@ -64,6 +64,19 @@ sidebarDepth: 2 - 統合されたテストネットフォーセットのアクセス - 18,000人のアクティブユーザーを持つ開発者のためのDiscordコミュニティ +- [**Allnodes**](https://www.allnodes.com/) + - [ドキュメント](https://docs.allnodes.com/) + - 機能 + - Allnodesポートフォリオページで作成されたPublicNodeトークンでのレート制限なし。 + - [PublicNode](https://www.publicnode.com)でのプライバシーを重視した無料RPCエンドポイント (100以上のブロックチェーン) + - 90以上のブロックチェーン向けレート制限なしの専用ノード + - 30以上のブロックチェーン向け専用アーカイブノード + - 3つの地域で利用可能（米国、欧州、アジア） + - [PublicNode](https://www.publicnode.com/snapshots)上の100以上のブロックチェーンのスナップショット + - 99.90%-99.98%稼働率SLA付き24時間365日テクニカルサポート（プランによる） + - 時間課金制 + - クレジットカード、PayPal、クリプトで支払い + - [**All That Node**](https://allthatnode.com/) - [ドキュメント](https://docs.allthatnode.com/) - 機能 @@ -117,22 +130,22 @@ sidebarDepth: 2 - [**BlockDaemon**](https://blockdaemon.com/) - [ドキュメント](https://ubiquity.docs.blockdaemon.com/) - - 利点 + - メリット - ダッシュボード - - ノード単位ごと + - ノード単位での課金 - 分析 - [**BlockPI**](https://blockpi.io/) - [ドキュメント](https://docs.blockpi.io/) - 機能 - - ロバストで分散型のノード構造 + - 堅牢で分散化されたノード構造 - HTTPSとWSSで最大40までのエンドポイント - 無料の入会パッケージと月額パッケージ - トレースメソッドおよびアーカイブデータのサポート - パッケージの有効期限は最大90日 - カスタムプランおよび従量課金制 - 暗号資産での支払い - - ダイレクトサポートおよび技術サポート + - ダイレクトサポートと技術サポート - [**Chainbase**](https://www.chainbase.com/) - [ドキュメント](https://docs.chainbase.com) @@ -156,20 +169,20 @@ sidebarDepth: 2 - 時間課金制 - 24時間年中無休のダイレクトサポート -- [**DRPC**](https://drpc.org/) - - [ドキュメント](https://docs.drpc.org/) - - 機能 - - 分散型RPCノード - - 15以上のノードプロバイダー - - ノードバランシング - - 無料ティアで毎月無制限のコンピューティングユニット - - データ検証 - - カスタムエンドポイント - - HTTPとWSSエンドポイント - - キー無制限(無料および有料ティア) - - 柔軟なフォールバックオプション - - [公開エンドポイント](https://eth.drpc.org) - - 無料共有アーカイブノード +- [**dRPC**](https://drpc.org/) + - [ドキュメント](https://drpc.org/docs) + - NodeCloud: 10ドル(USD)からのプラグアンドプレイRPCインフラ—フルスピード、無制限 + - NodeCloudの機能： + - 185のネットワークに対するAPIサポート + - 40以上のプロバイダーからなる分散プール + - 9つのジオクラスターによるグローバルカバレッジ + - AIを活用した負荷分散システム + - 従量課金制の定額料金—値上げ、有効期限、ロックインなし + - 無制限のキー、きめ細かいキーの調整、チームの役割、フロントエンド保護 + - メソッドあたり20コンピューティングユニット(CU)のメソッド定額料金 + - [公開エンドポイントチェーンリスト](https://drpc.org/chainlist) + - [料金計算ツール](https://drpc.org/pricing#calculator) + - NodeCore: 完全な制御を求める組織向けのオープンソーススタック - [**GetBlock**](https://getblock.io/) - [ドキュメント](https://getblock.io/docs/get-started/authentication-with-api-key/) @@ -209,18 +222,18 @@ sidebarDepth: 2 - 機能 - 無料スターターティア - イーサリアムノードのワンクリックデプロイ - - カスタマイズ可能なクライアントとアルゴリズム(Geth、Quorum & Besu || PoA、IBFT & Raft) + - カスタマイズ可能なクライアントとアルゴリズム (Geth、Quorum、Besu || PoA、IBFT、Raft) - 500以上の管理APIとサービス API - イーサリアムトランザクション送信のためのRESTfulインターフェイス(Apache Kafkaのサポート) - イベント配信のためのアウトバウンドストリーム(Apache Kafkaのサポート) - - 「オフチェーン」の付随サービスの豊富なコレクション(例: 双方向の暗号化されたメッセージングトランスポート) + - 「オフチェーン」と付随サービスの豊富なコレクション (例: 双方向の暗号化メッセージングトランスポート) - ガバナンスとロールベースのアクセス制御を備えた簡単なネットワーク・オンボーディング - 管理者およびエンドユーザー向けの高度なユーザー管理 - スケーラビリティと回復力に優れたエンタープライズレベルのインフラストラクチャ - Cloud HSM秘密鍵管理 - イーサリアムメインネットテザリング - ISO 27kおよびSOC 2 Type 2認証 - - 動的ランタイム設定(例: クラウド統合の追加、ノードイングレスの変更など) + - 動的ランタイム構成 (例: クラウド統合の追加、ノードイングレスの変更など) - マルチクラウド、マルチリージョン、ハイブリッド・デプロイ・オーケストレーションのサポート - SaaSベースのシンプルな価格設定(時間単位) - SLAと24時間年中無休のサポート @@ -259,7 +272,7 @@ sidebarDepth: 2 - 無料で開始 - [**NOWNodes**](https://nownodes.io/) - - [ドキュメンテーション](https://documenter.getpostman.com/view/13630829/TVmFkLwy) + - [ドキュメント](https://documenter.getpostman.com/view/13630829/TVmFkLwy) - 機能 - 50以上のブロックチェーンノードへのアクセス - APIキー無料 @@ -270,15 +283,15 @@ sidebarDepth: 2 - 共有、アーカイブ、バックアップ、専用ノード - [**Pocket Network**](https://www.pokt.network/) - - [ドキュメンテーション](https://docs.pokt.network/home/) + - [ドキュメント](https://docs.pokt.network/home/) - 機能 - 分散型RPCプロトコルとマーケットプレイス - 1日あたり100万件のリクエストができる無料ティア(エンドポイントあたり最大2件) - - [パブリックエンドポイント](https://docs.pokt.network/developers/public-endpoints) + - [公開エンドポイント](https://docs.pokt.network/developers/public-endpoints) - プレステーク+プログラム(1日に100万件を超えるリクエストが必要な場合) - 15以上のブロックチェーン対応 - アプリケーションへのサービスでPOKTを獲得する6400以上のノード - - アーカイブノード、トレース付きアーカイブノード、テストネットノードサポート + - アーカイブノード、トレース付きアーカイブノード、テストネットノードのサポート - イーサリアムメインネットのノードクライアントの多様性 - 単一障害点なし - ゼロダウンタイム @@ -288,30 +301,30 @@ sidebarDepth: 2 - 1日あたりのリクエスト件数と、1時間あたりのノード数を無限に拡張 - 最もプライベートで検閲耐性のあるオプション - ハンズオンデベロッパーサポート - - [Pocket Portal](https://bit.ly/ETHorg_POKTportal)ダッシュボードと分析 + - [Pocket Portal](https://bit.ly/ETHorg_POKTportal)のダッシュボードと分析 - [**QuickNode**](https://www.quicknode.com) - - [ドキュメンテーション](https://www.quicknode.com/docs/) + - [ドキュメント](https://www.quicknode.com/docs/) - 機能 - - 24時間年中無休の技術サポートとデベロッパーのDiscordコミュニティ + - 24時間年中無休の技術サポートと開発者向けDiscordコミュニティ - 地理的なバランスを考慮した、マルチクラウド/メタルの低遅延ネットワーク - マルチチェーンサーポート(Optimism、Arbitrum、Polygon他11種以上) - - スピードと安定性を考慮したミドルレイヤー(コールルーティング、キャッシュ、インデックス作成) + - 速度と安定性のためのミドルレイヤー(コールルーティング、キャッシュ、インデックス作成) - Webhookによるスマートコントラクト・モニタリング - 直感的なダッシュボード、分析スイート、RPCコンポーザー - 高度なセキュリティ機能(JWT、マスキング、ホワイトリスト) - NFTデータと分析API - - [SOC2認証](https://www.quicknode.com/security) + - [SOC2認証取得](https://www.quicknode.com/security) - デベロッパーからエンタープライズまで幅広く対応 - [**Rivet**](https://rivet.cloud/) - - [ドキュメンテーション](https://rivet.readthedocs.io/en/latest/) + - [ドキュメント](https://rivet.readthedocs.io/en/latest/) - 機能 - 無料ティアオプション - 従量課金制 - [**SenseiNode**](https://senseinode.com) - - [ドキュメンテーション](https://docs.senseinode.com/) + - [ドキュメント](https://docs.senseinode.com/) - 機能 - 専用ノードと共有ノード - ダッシュボード @@ -350,7 +363,7 @@ sidebarDepth: 2 - [**Tokenview**](https://services.tokenview.io/) - [ドキュメント](https://services.tokenview.io/docs?type=nodeService) - 機能 - - 年中無休の技術サポートおよび開発者向けテレグラムコミュニティ + - 24時間年中無休の技術サポートと開発者向けTelegramコミュニティ - マルチチェーンサポート(ビットコイン、イーサリアム、トロン、BNBスマートチェーン、イーサリアムクラシック) - RPCとWSSの両方のエンドポイントが利用可能 - アーカイブデータAPIへの無制限アクセス @@ -384,23 +397,22 @@ sidebarDepth: 2 - [ドキュメント](https://www.zeeve.io/docs/) - 機能 - エンタープライズグレードのノーコード自動化プラットフォームで、デプロイメント、モニタリング、ブロックチェーンノードの管理、ネットワークを提供 - - 30以上のプロトコルと統合をサポート、さらに追加中 + - 30以上の対応プロトコルと統合、さらに追加中 - 実世界のユースケースに合わせた分散型ストレージ、分散型ID、ブロックチェーンレジャーデータAPIなどの付加価値のあるWeb3インフラストラクチャサービス - 年中無休のサポートとプロアクティブなモニタリングにより、ノードの正常性を常に確保 - RPCエンドポイントでは、APIへのアクセス認証、直感的なダッシュボードと分析機能により手間をかけずに管理 - マネージドクラウドおよび、自身のクラウドオプションを持ち込み両方を提供します。メジャーなプロバイダーであるAWS、Azure、Google Cloud、Digital Ocean、およびオンプレミスなどすべてをサポート - 常にユーザーに最も近いノードに接続するために、インテリジェントルーティングを利用 +## 参考リンク {#further-reading} -## 参考文献 {#further-reading} - -- [イーサリアムノードサービスのリスト](https://ethereumnodes.com/) +- [イーサリアムノードサービス一覧](https://ethereumnodes.com/) ## 関連トピック {#related-topics} -- [ ノードとクライアント](/developers/docs/nodes-and-clients/) +- [ノードとクライアント](/developers/docs/nodes-and-clients/) ## 関連チュートリアル {#related-tutorials} -- [Alchemyを使用したイーサリアム開発入門](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) -- [Web3とAlchemyを使用したトランザクションの送信ガイド](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) +- [Alchemyを使ったイーサリアム開発入門](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) +- [web3とAlchemyを使ったトランザクション送信ガイド](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git a/public/content/translations/ja/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/ja/developers/docs/nodes-and-clients/run-a-node/index.md index f05145c9ce6..25474e1c899 100644 --- a/public/content/translations/ja/developers/docs/nodes-and-clients/run-a-node/index.md +++ b/public/content/translations/ja/developers/docs/nodes-and-clients/run-a-node/index.md @@ -1,19 +1,19 @@ --- -title: 自分のイーサリアムノードの立ち上げ -description: イーサリアムクライアントを自分のインスタンスで立ち上げる一般的な手順 +title: "自分のイーサリアムノードの立ち上げ" +description: "イーサリアムクライアントを自分のインスタンスで立ち上げる一般的な手順" lang: ja sidebarDepth: 2 --- 自分自身のノードを立ち上げ、運用することは、さまざまなメリットがあります。新しい可能性が開かれ、エコシステムのサポートへの貢献にもつながります。 このページは、自分のノードを立ち上げ、イーサリアムのトランザクション検証に参加する方法について説明します。 -[マージ](/roadmap/merge)以降、イーサリアムノードの運用には、**実行レイヤー(EL)**クライアントと**コンセンサスレイヤー(CL)**クライアントの2つが必要であることに注意してください。 このページでは、この2つのクライアントをインストール、設定、接続してイーサリアムノードを立ち上げる方法を紹介します。 +注：[The Merge](/roadmap/merge)以降、イーサリアムノードを実行するには、**実行レイヤー (EL)**クライアントと**コンセンサスレイヤー (CL)**クライアントの2つのクライアントが必要です。 このページでは、この2つのクライアントをインストール、設定、接続してイーサリアムノードを立ち上げる方法を紹介します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -イーサリアムノードが何か、なぜクライアントを実行するのかに関する理解が必要です。 これらについては、[ノードとクライアント](/developers/docs/nodes-and-clients/)に記載されています。 +イーサリアムノードが何か、なぜクライアントを実行するのかに関する理解が必要です。 これについては、[ノードとクライアント](/developers/docs/nodes-and-clients/)で説明しています。 -初めてノードを運用する方や、あまり技術的な知識が必要でない方法をお探しの方は、まず[イーサリアムノードの運用](/run-a-node)というユーザーフレンドリーな説明を確認してください。 +ノードの実行が初めての方や、技術的な詳細を省いた手順をお探しの方は、まず[イーサリアムノードの実行](/run-a-node)に関するユーザーフレンドリーな入門ガイドをお読みになることをお勧めします。 ## アプローチの選択 {#choosing-approach} @@ -21,21 +21,22 @@ sidebarDepth: 2 本ページではこれらについて説明し、あなたにとって最適なイーサリアムインスタンスの実行方法を見つけるサポートをします。 -クライアントを選択する上で、メインネット対応している利用可能なすべての[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)を確認し、[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity)について理解を深めてください。 +クライアント実装を選択するには、利用可能なすべてのメインネット対応の[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)、[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)を確認し、[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity)について学んでください。 -クライアントの[要件](#requirements)を確認し、ソフトウェアを[自分のハードウェア、またはクラウド上で実行](#local-vs-cloud)するかを決めます。 +クライアントの[要件](#requirements)を考慮し、ソフトウェアを自身の[ハードウェアで実行するか、クラウドで実行するか](#local-vs-cloud)を決定します。 -環境を整えたら、[初心者向けのインターフェース](#automatized-setup)か、高度なオプションが使用できるターミナルを使った[手動](#manual-setup)かを選び、クライアントをインストールします。 +環境を準備した後、[初心者向けのインターフェース](#automatized-setup)を使用するか、高度なオプションを備えたターミナルを使用して[手動](#manual-setup)で、選択したクライアントをインストールします。 -ノードが実行され同期が完了したら、[使用](#using-the-node)できる状態になりますが、[メンテナンス](#operating-the-node)は常に意識しておく必要があります。 +ノードが実行・同期されると、[使用](#using-the-node)できるようになりますが、その[メンテナンス](#operating-the-node)にも注意を払うようにしてください。 ![クライアントのセットアップ](./diagram.png) ### 環境とハードウェア {#environment-and-hardware} -#### ローカルまたはクラウド {#local-vs-cloud} +#### ローカルかクラウドか {#local-vs-cloud} -イーサリアムクライアントは、コンシューマーグレードのコンピュータで動作します。マイニング専用マシンのような特別なハードウェアは必要ありません。 そのため、ノードのデプロイメントには、ニーズに合わせた様々なオプションがあります。 簡単にするため、ローカルの物理マシンとクラウドサーバの両方でノードを実行することしましょう。 +イーサリアムクライアントは、コンシューマーグレードのコンピュータで動作します。マイニング専用マシンのような特別なハードウェアは必要ありません。 そのため、ノードのデプロイメントには、ニーズに合わせた様々なオプションがあります。 +簡単にするため、ローカルの物理マシンとクラウドサーバの両方でノードを実行することしましょう。 - クラウド - プロバイダーは高可用性のサーバと静的なパブリックIPアドレスを提供 @@ -48,27 +49,27 @@ sidebarDepth: 2 - 事前設定された専用マシンを購入することも可能 - マシンやネットワークの物理的な準備、メンテナンス、トラブルシューティングが必要 -どちらの選択肢も、上記のような異なるメリットがあります。 従来型のクラウドコンピューティングプロバイダーに加えて、クラウドソリューションを探している場合は、ノードのデプロイに焦点を当てたサービスもあります。 ホスティングされたノードのオプションについての詳細は、[ノード・アズ・ア・サービス](/developers/docs/nodes-and-clients/nodes-as-a-service/)を参照してください。 +どちらの選択肢も、上記のような異なるメリットがあります。 従来型のクラウドコンピューティングプロバイダーに加えて、クラウドソリューションを探している場合は、ノードのデプロイに焦点を当てたサービスもあります。 ホストされたノードに関するその他のオプションについては、[ノード・アズ・ア・サービス](/developers/docs/nodes-and-clients/nodes-as-a-service/)をご覧ください。 #### ハードウェア {#hardware} -しかし、検閲耐性を備えた分散型ネットワークは、クラウドプロバイダーに依存すべきではありません。 クラウドではなく、ローカルハードウェア上でノードを実行することが、エコシステムにとってより健全です。 [推計](https://www.ethernodes.org/network-types)によると、クラウド上で動作するノードの割合が多く、単一障害点となる可能性があります。 +しかし、検閲耐性を備えた分散型ネットワークは、クラウドプロバイダーに依存すべきではありません。 クラウドではなく、ローカルハードウェア上でノードを実行することが、エコシステムにとってより健全です。 [推計](https://www.ethernodes.org/networkType/cl/Hosting)によると、ノードの大部分はクラウド上で実行されており、これが単一障害点になる可能性があります。 イーサリアムクライアントは、デスクトップパソコン、ノートパソコン、サーバ、あるいはシングルボードコンピュータ上で動作させることができます。 パーソナルコンピュータでクライアントを実行することも可能ですが、ノード専用マシンを用意することで、プライマリコンピュータへの影響を最小限に抑えながら、パフォーマンスとセキュリティを大幅に向上させることができます。 自分のハードウェアを使うのは非常に簡単です。 シンプルなオプションだけでなく、より技術的な方向けの高度なセットアップ方法も多数用意されています。 それでは、自分のマシンでイーサリアムクライアントを実行するための要件と方法を見ていきましょう。 -#### 必要条件 {#requirements} +#### 要件 {#requirements} ハードウェア要件はクライアントによって異なりますが、ノードは同期を維持する必要があるだけなので、通常はそれほど高くありません。 マイニングとは異なり、ノードは多くの計算能力を必要としないため、混同しないでください。 ただし、より強力なハードウェアでは、同期時間とパフォーマンスは向上します。 クライアントをインストールする前に、コンピュータに十分なリソースがあることを確認してください。 最小システム要件と推奨システム要件は以下のとおりです。 -ハードウェアのボトルネックは、主にディスク容量です。 イーサリアムブロックチェーンの同期は、非常に多くの入出力を必要とし、多くのディスクスペースが必要です。 そのため、同期後も数百GBの空き容量を確保できる、ソリッド・ステート・ドライブ(SSD)を用意することをお勧めします。 +ハードウェアのボトルネックは、主にディスク容量です。 イーサリアムブロックチェーンの同期は、非常に多くの入出力を必要とし、多くのディスクスペースが必要です。 同期後も数百GBの空き容量を確保できる、**ソリッドステートドライブ(SSD)**を用意することをお勧めします。 -データベースのサイズと初期同期の速度は、選択したクライアント、設定、[同期戦略](/developers/docs/nodes-and-clients/#sync-modes)によって異なります。 +データベースのサイズと初期同期の速度は、選択したクライアント、その設定、および[同期戦略](/developers/docs/nodes-and-clients/#sync-modes)によって異なります。 -また、インターネット接続が[帯域幅の上限](https://wikipedia.org/wiki/Data_cap)により制限されていないことを確認してください。 ネットワークにブロードキャストされたデータが制限を超える可能性があるため、従量制限のない接続を使用することをお勧めします。 +また、ご使用のインターネット接続が[帯域幅の上限](https://wikipedia.org/wiki/Data_cap)によって制限されていないことを確認してください。 ネットワークにブロードキャストされたデータが制限を超える可能性があるため、従量制限のない接続を使用することをお勧めします。 ##### オペレーティングシステム @@ -91,57 +92,58 @@ sidebarDepth: 2 選択した同期モードとクライアントによって必要容量が変わります。以下に各クライアントに必要なディスク容量の概算を記載します。 | クライアント | ディスクサイズ(スナップ同期) | ディスクサイズ(フルアーカイブ) | -| ---------- | --------------- | ---------------- | -| Besu | 800GB以上 | 12TB以上 | -| Erigon | N/A | 2.5TB以上 | -| Geth | 500GB以上 | 12TB以上 | -| Nethermind | 500GB以上 | 12TB以上 | -| Reth | N/A | 2.2TB以上 | +| ---------- | ---------------------------------- | ----------------------------------- | +| ベス | 800GB以上 | 12TB以上 | +| Erigon | N/A | 2.5TB以上 | +| Geth | 500GB以上 | 12TB以上 | +| Nethermind | 500GB以上 | 12TB以上 | +| Reth | N/A | 2.2TB以上 | - 注意: ErigonとRethはスナップ同期を提供していませんが、フルプルーニングが可能です (Erigonで約2TB、Rethで約1.2TB) 。 -コンセンサスクライアントの必要な容量は、クライアントの実装や有効にした機能(バリデータスラッシャーなど)によって変わりますが、概ねビーコンデータ用にさらに200GB必要です。 また、多数のバリデータを実行すると、帯域幅への負荷も大きくなります。 [この分析を通して、コンセンサスクライアントの要件の詳細](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc)がわかります。 +コンセンサスクライアントの場合、必要な容量はクライアントの実装と有効化された機能(例：バリデータスラッシャー)によっても異なりますが、通常はビーコンデータ用にさらに200GBが必要になると考えてください。 また、多数のバリデータを実行すると、帯域幅への負荷も大きくなります。 [こちらの分析で、コンセンサスクライアントの要件に関する詳細](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc)をご覧いただけます。 -#### プラグ・アンド・プレイ・ソリューション {#plug-and-play} +#### プラグアンドプレイ・ソリューション {#plug-and-play} 自分のハードウェアでノードを実行する最も簡単な方法は、プラグ・アンド・プレイ・ボックスを使用することです。 事前に設定されたマシンを使うと、注文、接続、実行まで、最も簡単に実行することができます。 すべてが事前設定されており、自動実行され、直感的なガイドとダッシュボードでソフトウェアを監視・制御できます。 - [DappNode](https://dappnode.io/) - [Avado](https://ava.do/) -#### シングルボードコンピュータ {#ethereum-on-a-single-board-computer} +#### シングルボードコンピュータ上のイーサリアム {#ethereum-on-a-single-board-computer} -Raspberry PiのようなARMアーキテクチャのシングルボードコンピュータを使用すると、イーサリアムノードを簡単かつ安価に実行できます。 [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)は、Raspberry Piやその他のARMボード向けに、実行クライアントとコンセンサスクライアントが容易に実行できるイメージを複数提供しています。 +Raspberry PiのようなARMアーキテクチャのシングルボードコンピュータを使用すると、イーサリアムノードを簡単かつ安価に実行できます。 [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)は、Raspberry Piやその他のARMボード向けに、複数の実行クライアントとコンセンサスクライアントを簡単に実行できるイメージを提供しています。 これらのデバイスは、小型で価格も手頃、効率も良く、自宅でノードを運用するのに適していますが、性能には限界があることに注意が必要です。 -## ノードの立ち上げ {#spinning-up-node} +## ノードの起動 {#spinning-up-node} 実際のクライアント設定は、自動ランチャーを使うか、または手動で直接設定できます。 上級者でない場合は、ランチャー(インストールをガイドし、クライアントの設定を自動化するソフトウェア)を使用することをお勧めします。 ターミナルの操作に慣れている方は、手動設定も可能です。 -### ガイド付き設定 {#automatized-setup} +### ガイド付きセットアップ {#automatized-setup} 複数のプロジェクトが、クライアント設定のユーザーエクスペリエンスの向上を目指しています。 ランチャーは、クライアントのインストールと設定を自動化します。また、クライアントのガイド付きセットアップと監視用にグラフィック・インターフェースを提供しているランチャーもあります。 数回クリックするだけで、クライアントのインストールや制御ができる便利なプロジェクトを紹介します。 -- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNodeは、ベンダーのマシンだけに付属しているわけではありません。 ノードランチャーやコントロールセンターのソフトウェアは多くの機能があり、任意のハードウェアで使用可能。 -- [eth-docker](https://eth-docker.net/) - Dockerを使った自動設定は、簡単で安全なステーキングに焦点を当てており、ターミナルとDockerの基本的な知識が必要。少し上級のユーザー向け。 -- [Stereum](https://stereum.net/ethereum-node-setup/) - SSH接続でリモートサーバにクライアントをインストールするためのランチャー。GUIセットアップガイド、コントロールセンター、その他多くの機能搭載。 -- [NiceNode](https://www.nicenode.xyz/) - コンピュータ上でノードを実行するためのランチャー。分かりやすいユーザーエクスペリエンスが特徴。 クライアントを選択し、数回クリックするだけで開始可能。 現在、開発中。 -- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - ノードのセットアップツールでCLIのウィザードを使いDocker構成を自動生成。 NethermindによってGoで開発。 +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - DappNodeは、ベンダー提供のマシンに付属しているだけではありません。 ノードランチャーやコントロールセンターのソフトウェアは多くの機能があり、任意のハードウェアで使用可能。 +- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) - フルノードをセットアップする最も迅速で簡単な方法です。 ワンライナーのセットアップツールおよびノード管理TUI。 無料で オープンソースです。 ソロステーカーによるイーサリアムの公共財。 ARM64およびAMD64をサポートしています。 +- [eth-docker](https://eth-docker.net/) - Dockerを使用した自動セットアップで、簡単かつ安全なステーキングに焦点を当てています。ターミナルとDockerの基本的な知識が必要で、やや上級のユーザーに推奨されます。 +- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) - GUIセットアップガイド、コントロールセンター、その他多くの機能を備え、SSH接続を介してリモートサーバーにクライアントをインストールするためのランチャー。 +- [NiceNode](https://www.nicenode.xyz/) - コンピュータでノードを実行するための、分かりやすいユーザーエクスペリエンスを備えたランチャー。 クライアントを選択し、数回クリックするだけで開始可能。 現在、開発中。 +- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - CLIウィザードを使用してDocker構成を自動的に生成するノードセットアップツール。 NethermindによってGoで開発。 -### 手動でのクライアント設定 {#manual-setup} +### 手動でのクライアントセットアップ {#manual-setup} もう1つのオプションは、クライアントソフトウェアを手動でダウンロードして、確認・設定することです。 グラフィック・インターフェースを提供するクライアントもありますが、手動設定にはターミナルの基本的なスキルが必要となります。ただし、より幅広い用途に対応できます。 前述したように、自分のイーサリアムノードを立ち上げるには、コンセンサスクライアントと実行クライアントをペアで実行する必要があります。 一部のクライアントには、他の種類のライトクライアントが含まれているものがあり、それ以外のソフトウェアをインストールする必要なく同期できます。 しかし、完全にトラストレスな検証を行うためには、コンセンサスクライアントと実行クライアントの両方が必要です。 -#### クライアントソフトウェアの取得 {#getting-the-client} +#### クライアントソフトウェアの入手 {#getting-the-client} -まず、希望する[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)ソフトウェアを取得する必要があります。 +まず、お好みの[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサスクライアント](/developers/docs/nodes-and-clients/#consensus-clients)のソフトウェアを入手する必要があります。 オペレーティングシステムとアーキテクチャに適した、実行可能なアプリケーションやインストールパッケージをダウンロードするだけです。 ダウンロードしたパッケージの署名とチェックサムも必ず確認してください。 インストールやアップデートを簡単に行うためのリポジトリやDockerイメージを提供するクライアントもあります。 クライアントはすべてオープンソースなので、ソースからビルドすることもできます。 これはより高度な方法ですが、場合によっては必要になることがあります。 @@ -157,27 +159,27 @@ Raspberry PiのようなARMアーキテクチャのシングルボードコン - [Nethermind](https://downloads.nethermind.io/) - [Reth](https://reth.rs/installation/installation.html) -また、[実行レイヤーにおいても](/developers/docs/nodes-and-clients/client-diversity/#execution-layer)、クライアントの多様性が問題となっていることにも注意が必要です。 マイノリティの実行クライアントの運用を検討することをお勧めします。 +クライアントの多様性が[実行レイヤー上の問題](/developers/docs/nodes-and-clients/client-diversity/#execution-layer)であることも特筆すべき点です。 マイノリティの実行クライアントの運用を検討することをお勧めします。 ##### コンセンサスクライアント - [Lighthouse](https://github.com/sigp/lighthouse/releases/latest) -- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source/)(ビルド済みのバイナリを提供していないため、Dockerイメージを使用またはソースからビルド) +- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source) (ビルド済みバイナリは提供されておらず、Dockerイメージまたはソースからのビルドのみ) - [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest) - [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest) - [Teku](https://github.com/ConsenSys/teku/releases) -バリデータを実行しているコンセンサスノードにとって、[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity/)は重要です。 大多数のバリデータが単一のクライアントを実行していると、ネットワークのセキュリティが危険にさらされます。 そのため、マイノリティクライアントを選択することをお勧めします。 +バリデータを実行するコンセンサスノードにとって、[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity/)は非常に重要です。 大多数のバリデータが単一のクライアントを実行していると、ネットワークのセキュリティが危険にさらされます。 そのため、マイノリティクライアントを選択することをお勧めします。 -[最新のネットワーククライアントの使用状況](https://clientdiversity.org/)を参照し、[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity)についてご覧ください。 +[最新のネットワーククライアントの使用状況](https://clientdiversity.org/)を確認し、[クライアントの多様性](/developers/docs/nodes-and-clients/client-diversity)についてさらに学びましょう。 ##### ソフトウェアの検証 インターネットからソフトウェアをダウンロードする場合は、ダウンロードしたファイルの完全性を検証することをお勧めします。 このステップは任意ですが、特にイーサリアムクライアントのような重要なインフラストラクチャの一部では、潜在的な攻撃ベクトルを認識し、回避することが重要です。 ビルド済みのバイナリをダウンロードした場合、その出所を信頼する必要がありますが、攻撃者が実行ファイルを悪意のあるものにすり替えるというリスクもあります。 -デベロッパーはリリースしたバイナリに、デベロッパーのPGPキーで署名しています。そのため、デベロッパーが作成したソフトウェアそのものを間違いなく実行していることを暗号的に検証できます。 デベロッパーが使用した公開鍵は、クライアントのリリースページやドキュメントに記載されており、そこから入手できます。 リリースされたクライアントと署名をダウンロードしたら、[GnuPG](https://gnupg.org/download/index.html)などのPGP実装を使って、簡単に検証できます。 [Linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/)または[Windows/MacOS](https://freedom.press/training/verifying-open-source-software/)の`gpg`を使って、オープンソースソフトウェアを検証するチュートリアルを確認してください。 +デベロッパーはリリースしたバイナリに、デベロッパーのPGPキーで署名しています。そのため、デベロッパーが作成したソフトウェアそのものを間違いなく実行していることを暗号的に検証できます。 デベロッパーが使用した公開鍵は、クライアントのリリースページやドキュメントに記載されており、そこから入手できます。 クライアントリリースとその署名をダウンロードした後、[GnuPG](https://gnupg.org/download/index.html)などのPGP実装を使用すると、それらを簡単に検証できます。 [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/)または[Windows/MacOS](https://freedom.press/training/verifying-open-source-software/)で `gpg` を使用してオープンソースソフトウェアを検証する方法に関するチュートリアルを確認してください。 -ダウンロードしたソフトウェアを検証するもう1つの方法は、ハッシュが(一意の暗号論的指紋)、デベロッパーによって提供されたものと一致するかどうかを確認することです。 これはPGPを使うよりもさらに簡単で、ハッシュだけを提供するクライアントもあります。 ダウンロードしたソフトウェアに対しハッシュ関数を実行し、リリースページに記載されているものと比較してください。 以下の例を確認してください： +ダウンロードしたソフトウェアを検証するもう1つの方法は、ハッシュが(一意の暗号論的指紋)、デベロッパーによって提供されたものと一致するかどうかを確認することです。 これはPGPを使うよりもさらに簡単で、ハッシュだけを提供するクライアントもあります。 ダウンロードしたソフトウェアに対しハッシュ関数を実行し、リリースページに記載されているものと比較してください。 以下の例をご覧ください： ```sh sha256sum teku-22.6.1.tar.gz @@ -189,15 +191,15 @@ sha256sum teku-22.6.1.tar.gz クライアントソフトウェアのインストール、ダウンロード、またはコンパイルが完了したら、実行する準備が整い、 あとは適切な設定を行うだけです。 クライアントには、さまざまな機能を有効化できる豊富な設定オプションが提供されています。 -まずは、クライアントのパフォーマンスやデータ使用量に大きく影響するオプションから紹介します。 [同期モード](/developers/docs/nodes-and-clients/#sync-modes)とは、ブロックチェーンデータのダウンロードと検証のさまざまな方法のことです。 ノードを開始する前に、使用するネットワークと同期モードを決める必要があります。 考慮すべき最も重要なことは、クライアントに必要なディスク容量と同期にかかる時間です。 クライアントのドキュメントで、デフォルトの同期モードを確認してください。 デフォルトの同期モードが適切でない場合は、セキュリティレベル、利用可能なデータ、コストを考慮して、別の同期モードを選択します。 同期アルゴリズムとは別に、さまざまな種類の古いデータを剪定することもできます。 剪定により古いデータが削除されます。例えば、最近のブロックから到達できない状態のtrieノードを削除します。 +まずは、クライアントのパフォーマンスやデータ使用量に大きく影響するオプションから紹介します。 [同期モード](/developers/docs/nodes-and-clients/#sync-modes)は、ブロックチェーンデータをダウンロードして検証するためのさまざまな方法を表します。 ノードを開始する前に、使用するネットワークと同期モードを決める必要があります。 考慮すべき最も重要なことは、クライアントに必要なディスク容量と同期にかかる時間です。 クライアントのドキュメントで、デフォルトの同期モードを確認してください。 デフォルトの同期モードが適切でない場合は、セキュリティレベル、利用可能なデータ、コストを考慮して、別の同期モードを選択します。 同期アルゴリズムとは別に、さまざまな種類の古いデータをプルーニングすることもできます。 プルーニングにより、古いデータの削除、つまり最近のブロックから到達できないステートトライノードの削除が可能になります。 -その他の基本設定オプションとしては、ネットワークの選択(メインネットまたはテストネット)、HTTPエンドポイント(RPCまたはWebSocketなど)の有効化などがあります。 クライアントのドキュメントには、すべての機能とオプションが記載されています。 CLI(コマンドラインインターフェース)または設定ファイルに直接、対応するフラグを指定してクライアントを実行することで、さまざまなクライアント設定ができます。 ただし、各クライアントによって設定オプションが多少異なるため、詳細については、公式ドキュメントまたはヘルプページを必ず参照してください。 +その他の基本的な設定オプションには、ネットワーク(メインネットまたはテストネット)の選択、RPCまたはWebSocket用のHTTPエンドポイントの有効化などがあります。 クライアントのドキュメントには、すべての機能とオプションが記載されています。 CLI(コマンドラインインターフェース)または設定ファイルに直接、対応するフラグを指定してクライアントを実行することで、さまざまなクライアント設定ができます。 ただし、各クライアントによって設定オプションが多少異なるため、詳細については、公式ドキュメントまたはヘルプページを必ず参照してください。 -テストを行う場合は、テストネットの1つでクライアントを実行することをお勧めします。 詳しくは、[対応ネットワークの概要](/developers/docs/nodes-and-clients/#execution-clients)をご覧ください。 +テストを行う場合は、テストネットの1つでクライアントを実行することをお勧めします。 [サポートされているネットワークの概要を見る](/developers/docs/nodes-and-clients/#execution-clients)。 基本設定による実行クライアントの実行例は、次のセクションに記載されています。 -#### 実行クライアントの開始 {#starting-the-execution-client} +#### 実行クライアントの起動 {#starting-the-execution-client} イーサリアムクライアントソフトウェアを起動する前に、環境が整っていることを最終チェックします。 具体的には、以下の事項などを確認してください。 @@ -211,34 +213,34 @@ sha256sum teku-22.6.1.tar.gz 最初にデフォルトではないクライアントを設定する必要があります。 フラグや設定ファイルを使って、希望の設定に変更できます。 各クライアントにより機能や設定構文が異なるため、 具体的な内容については、お使いのクライアントのドキュメントを確認してください。 -実行クライアントとコンセンサスクライアントは、[エンジンAPI](https://github.com/ethereum/execution-apis/tree/main/src/engine)で指定された認証済みエンドポイントを介して通信します。 実行クライアントはコンセンサスクライアントに接続するために、既知のパスで[`jwtsecret`](https://jwt.io/)を生成する必要があります。 セキュリティと安定性の理由から、両方のクライアントは同じマシン上で実行する必要があり、ローカルRPC接続で相互認証を行うため、両方のクライアントがこのパスを共有していなければなりません。 また、実行クライアントは認証されたAPIのリスニングポートを定義する必要があります。 +実行クライアントとコンセンサスクライアントは、[Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine)で指定された認証済みエンドポイントを介して通信します。 コンセンサスクライアントに接続するためには、実行クライアントが既知のパスに[`jwtsecret`](https://jwt.io/)を生成する必要があります。 セキュリティと安定性の理由から、両方のクライアントは同じマシン上で実行する必要があり、ローカルRPC接続で相互認証を行うため、両方のクライアントがこのパスを共有していなければなりません。 また、実行クライアントは認証されたAPIのリスニングポートを定義する必要があります。 -このトークンは、通常はクライアントソフトウェアによって自動的に生成されます。ただし、自分で作成しなければならないこともあります。その場合は、 [OpenSSL](https://www.openssl.org/)を使用してください。 +このトークンは、通常はクライアントソフトウェアによって自動的に生成されます。ただし、自分で作成しなければならないこともあります。その場合は、 [OpenSSL](https://www.openssl.org/) を使用して生成できます。 ```sh openssl rand -hex 32 > jwtsecret ``` -#### 実行クライアントの開始 {#running-an-execution-client} +#### 実行クライアントの実行 {#running-an-execution-client} このセクションでは、実行クライアントの開始について説明します。 あくまでも基本的な設定例となりますが、以下の設定でクライアントを起動します。 - 接続するネットワークを指定する。例ではメインネットを使用 - - [テストネット](/developers/docs/networks/)のいずれか1つを選択して、セットアップの予備テストも実行可 + - 代わりに、セットアップの予備テスト用に[テストネットのいずれか](/developers/docs/networks/)を選択することもできます - ブロックチェーンを含むすべてのデータが格納されるデータディレクトリを定義 - - パスは必ず実際のものに変更する(例: 外付けドライブのディレクトリの指定など) + - パスを実際のパス(例：外部ドライブを指すパス)に置き換えるようにしてください - クライアントと通信するためのインターフェースを有効化 - コンセンサスクライアントとの通信のために、JSON-RPCおよびエンジンAPIを含む -- API認証で使う`jwtsecret`のパスを定義 - - 例えば、`/tmp/jwtsecret`など、クライアントがアクセス可能な実際のパスにする +- 認証済みAPIの`jwtsecret`へのパスを定義します + - サンプルパスを、クライアントがアクセスできる実際のパス(例: `/tmp/jwtsecret`)に置き換えるようにしてください これは基本的な例であることに注意してください。それ以外の設定はすべてデフォルトになっています。 各クライアントのドキュメントをよく読み、デフォルト、設定、機能について理解しましょう。 バリデータの実行やモニタリングなど、その他の機能の詳細については、各クライアントのドキュメントを参照してください。 -> 注: 例のバックスラッシュ`\`は見やすさのために記載しており、設定フラグは1行で定義できます。 +> 注：例にあるバックスラッシュ `` は書式設定のみを目的としており、設定フラグは1行で定義できます。 ##### Besuの実行 -この例では、Besuをメインネットで起動し、ブロックチェーンデータを`/data/ethereum`にデフォルト形式で保存し、コンセンサスクライアントに接続するためにJSON-RPCおよびエンジンRPCを有効にします。 エンジンAPIは、トークン`jwtsecret`で認証され、`localhost`からの呼び出しのみが許可されます。 +この例では、Besuをメインネットで起動し、ブロックチェーンデータを`/data/ethereum`にデフォルト形式で保存し、コンセンサスクライアントに接続するためにJSON-RPCおよびエンジンRPCを有効にします。 Engine APIは`jwtsecret`トークンで認証され、`localhost`からの呼び出しのみが許可されます。 ```sh besu --network=mainnet \ @@ -256,11 +258,11 @@ Besuには、一連の質問に答えることで設定ファイルを生成で besu --Xlauncher ``` -[Besuのドキュメント](https://besu.hyperledger.org/public-networks/get-started/start-node/)で、追加のオプションと設定の詳細を参照してください。 +[Besuのドキュメント](https://besu.hyperledger.org/public-networks/get-started/start-node/)には、追加のオプションと設定の詳細が含まれています。 ##### Erigonの実行 -この例では、Erigonをメインネットで起動し、ブロックチェーンデータを`/data/ethereum`に保存し、JSON-RPCを有効にして、許可されるネームスペースを定義し、`jwtsecret`パスで定義されたコンセンサスクライアントに接続するための認証を有効にします。 +この例では、Erigonをメインネットで起動し、ブロックチェーンデータを `/data/ethereum` に保存し、JSON-RPCを有効にし、許可されるネームスペースを定義し、`jwtsecret`パスで定義されたコンセンサスクライアント接続用の認証を有効にします。 ```sh erigon --chain mainnet \ @@ -269,11 +271,11 @@ erigon --chain mainnet \ --authrpc.jwtsecret=/path/to/jwtsecret ``` -Erigonは、デフォルトで8GBのHDDでフル同期を行います。アーカイブデータは2TB以上になるので、 `datadir`が十分な空き容量のあるディスクを指していることを確認するか、さまざまな種類のデータを削除する`--prune`フラグを検討してください。 詳細については、Erigonの`--help`オプションを参照してください。 +Erigonは、デフォルトで8GBのHDDでフル同期を行います。アーカイブデータは2TB以上になるので、 `datadir`が十分な空き容量のあるディスクを指していることを確認するか、さまざまな種類のデータを削除できる`--prune`フラグを検討してください。 詳細については、Erigonの`--help`を確認してください。 ##### Gethの実行 -この例では、Gethをメインネットで起動し、ブロックチェーンデータを`/data/ethereum`に保存し、JSON-RPCを有効にして、許可されるネームスペースを定義します。 さらに、コンセンサスクライアントに接続するための認証を有効にし、認証に必要な`jwtsecret`を定義し、許可する接続のオプションも合わせて(この例では`localhost`からのみ)定義しています。 +この例では、Gethをメインネットで起動し、ブロックチェーンデータを`/data/ethereum`に保存し、JSON-RPCを有効にして、許可されるネームスペースを定義します。 また、コンセンサスクライアント接続のための認証も有効にします。これには`jwtsecret`へのパスと、許可する接続を定義するオプション(この例では`localhost`からのみ)が必要です。 ```sh geth --mainnet \ @@ -284,7 +286,7 @@ geth --mainnet \ --authrpc.jwtsecret=/path/to/jwtsecret ``` -[すべての設定オプションのドキュメント](https://geth.ethereum.org/docs/fundamentals/command-line-options)を確認し、[コンセンサスクライアントとGethを実行する方法](https://geth.ethereum.org/docs/getting-started/consensus-clients)についての詳細を参照してください。 +[すべての設定オプションに関するドキュメント](https://geth.ethereum.org/docs/fundamentals/command-line-options)を確認し、[Gethをコンセンサスクライアントと共に実行する](https://geth.ethereum.org/docs/getting-started/consensus-clients)方法についてさらに学びましょう。 ##### Nethermindの実行 @@ -296,13 +298,13 @@ Nethermind.Runner --config mainnet \ --JsonRpc.JwtSecretFile=/path/to/jwtsecret ``` -Nethermindのドキュメントは、Nethermindとコンセンサスクライアントの実行方法をすべて網羅した[完全ガイド](https://docs.nethermind.io/get-started/running-node/)です。 +Nethermindのドキュメントでは、Nethermindをコンセンサスクライアントと共に実行するための[完全なガイド](https://docs.nethermind.io/get-started/running-node/)を提供しています。 実行クライアントは、コア機能と選択したエンドポイントを起動し、ピアを探し始めます。 ピアが見つかったら、同期を開始します。 また、コンセンサスクライアントからの接続を待ちます。 クライアントが正常に現在の状態に同期されると、現在のブロックチェーンデータが利用できるようになります。 ##### Rethの実行 -この例では、Rethをメインネットで起動し、デフォルトのデータ保存場所を使用します。 `jwtsecret`パスで定義されているコンセンサスクライアントに接続するためのJSON-RPCおよびエンジンRPC認証を有効にし、`localhost`からの呼び出しのみを許可します。 +この例では、Rethをメインネットで起動し、デフォルトのデータ保存場所を使用します。 `jwtsecret`パスで定義されたコンセンサスクライアントに接続するためのJSON-RPCおよびEngine RPC認証を有効にし、`localhost`からの呼び出しのみを許可します。 ```sh reth node \ @@ -311,23 +313,23 @@ reth node \ --authrpc.port 8551 ``` -デフォルトのデータディレクトリについては、[Rethの設定](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth)をご覧ください。 [Rethのドキュメント](https://reth.rs/run/mainnet.html)には、その他のオプションや設定の詳細が記載されています。 +デフォルトのデータディレクトリの詳細については、[Rethの設定](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth)を参照してください。 [Rethのドキュメント](https://reth.rs/run/mainnet.html)には、追加のオプションと設定の詳細が含まれています。 -#### コンセンサスクライアントの開始 {#starting-the-consensus-client} +#### コンセンサスクライアントの起動 {#starting-the-consensus-client} 実行クライアントへのローカルRPC接続を確立させるために、コンセンサスクライアントを正しいポート設定で起動する必要があります。 コンセンサスクライアントは、公開した実行クライアントのポートを引数に設定して実行します。 -コンセンサスクライアントは、RPC接続を認証するために実行クライアントの`jwt-secret`へのパスも必要です。 上記の実行例と同様に、各コンセンサスクライアントには、jwtトークンファイルパスを引数とする設定フラグがあります。 このパスは、実行クライアントに使われる`jwtsecret`のパスと一致しなければなりません。 +コンセンサスクライアントは、それらの間のRPC接続を認証するために、実行クライアントの`jwt-secret`へのパスも必要とします。 上記の実行例と同様に、各コンセンサスクライアントには、jwtトークンファイルパスを引数とする設定フラグがあります。 これは、実行クライアントに提供された`jwtsecret`パスと一致している必要があります。 -バリデータを実行する予定がある場合は、フィーを受け取るイーサリアムアドレスを指定する設定フラグを必ず追加してください。 このアドレスは、バリデータのイーサ報酬が蓄積されるアドレスです。 各コンセンサスクライアントは、`--suggested-fee-recipient=0xabcd1`のように、イーサリアムアドレスを引数に取るオプションがあります。 +バリデータを実行する予定がある場合は、フィーを受け取るイーサリアムアドレスを指定する設定フラグを必ず追加してください。 このアドレスは、バリデータのイーサ報酬が蓄積されるアドレスです。 各コンセンサスクライアントには、例えば `--suggested-fee-recipient=0xabcd1` のように、イーサリアムアドレスを引数として取るオプションがあります。 -テストネットでビーコンノードを起動する場合、[チェックポイント同期](https://notes.ethereum.org/@launchpad/checkpoint-sync)にパブリックエンドポイントを使用すると、同期時間が大幅に短縮されます。 +テストネットでビーコンノードを起動する場合、[チェックポイント同期](https://notes.ethereum.org/@launchpad/checkpoint-sync)にパブリックエンドポイントを使用することで、同期時間を大幅に短縮できます。 #### コンセンサスクライアントの実行 {#running-a-consensus-client} ##### Lighthouseの実行 -Lighthouseを実行する前に、[Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html)でインストールと設定方法の詳細を参照してください。 +Lighthouseを実行する前に、[Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html)でインストールと設定の方法について詳しく学んでください。 ```sh lighthouse beacon_node \ @@ -340,11 +342,11 @@ lighthouse beacon_node \ ##### Lodestarの実行 -Lodestarソフトウェアをコンパイルするか、Dockerイメージをダウンロードしてインストールしてください。 詳細については、[ドキュメント](https://chainsafe.github.io/lodestar/)または総合[セットアップガイド](https://hackmd.io/@philknows/rk5cDvKmK)を参照してください。 +Lodestarソフトウェアをコンパイルするか、Dockerイメージをダウンロードしてインストールしてください。 詳細は[ドキュメント](https://chainsafe.github.io/lodestar/)および、より包括的な[セットアップガイド](https://hackmd.io/@philknows/rk5cDvKmK)でご確認ください。 ```sh lodestar beacon \ - --rootDir="/data/ethereum" \ + --dataDir="/data/ethereum" \ --network=mainnet \ --eth1.enabled=true \ --execution.urls="http://127.0.0.1:8551" \ @@ -353,7 +355,8 @@ lodestar beacon \ ##### Nimbusの実行 -Nimbusには、コンセンサスクライアントと実行クライアントの両方を備えています。 計算能力の低いデバイスでも実行可能です。 [必要なものをインストールした後](https://nimbus.guide/quick-start.html)、コンセンサスクライアントを実行できます。 +Nimbusには、コンセンサスクライアントと実行クライアントの両方を備えています。 計算能力の低いデバイスでも実行可能です。 +[依存関係とNimbus自体をインストール](https://nimbus.guide/quick-start.html)した後、そのコンセンサスクライアントを実行できます。 ```sh nimbus_beacon_node \ @@ -365,7 +368,7 @@ nimbus_beacon_node \ ##### Prysmの実行 -Prysmには、簡単に自動インストールできるスクリプトがあります。 詳細については、[Prysmドキュメント](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/)を参照してください。 +Prysmには、簡単に自動インストールできるスクリプトがあります。 詳細は[Prysmのドキュメント](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/)で確認できます。 ```sh ./prysm.sh beacon-chain \ @@ -384,51 +387,51 @@ teku --network mainnet \ --ee-jwt-secret-file "/path/to/jwtsecret" ``` -コンセンサスクライアントが実行クライアントに接続し、デポジットコントラクトを読み込みバリデータを識別します。同時に、他のビーコンノードのピアにも接続し、ジェネシスブロック(最初のブロック)からコンセンサススロットの同期を開始します。 ビーコンノードが現在のエポックに到達すると、バリデータはビーコンAPIを使用できるようになります。 詳細については、[ビーコンノードAPI](https://eth2docs.vercel.app/)を参照してください。 +コンセンサスクライアントが実行クライアントに接続し、デポジットコントラクトを読み込みバリデータを識別します。同時に、他のビーコンノードのピアにも接続し、ジェネシスブロック(最初のブロック)からコンセンサススロットの同期を開始します。 ビーコンノードが現在のエポックに到達すると、バリデータはビーコンAPIを使用できるようになります。 [ビーコンノードAPI](https://eth2docs.vercel.app/)についての詳細はこちら。 ### バリデータの追加 {#adding-validators} コンセンサスクライアントは、バリデータが接続するビーコンノードとして機能します。 各コンセンサスクライアントは、それぞれのバリデータソフトウェアを搭載しています。詳細については、各ドキュメントに記載されています。 -自分でバリデータを実行すると、[ソロステーキング](/staking/solo/)ができます。これはイーサリアムネットワークをサポートする上で、最も影響力があり、トラストレスな方法です。 ただし、32 ETHのデポジットが必要となります。 費用を抑えたい場合は、[Rocket Pool](https://rocketpool.net/node-operators)など、パーミッションレスなノードオペレータの分散型プールに参加することで、少ない費用でバリデータを実行することもできます。 +自身のバリデータを実行することで、イーサリアムネットワークをサポートする最もインパクトがありトラストレスな方法である[ソロステーキング](/staking/solo/)が可能になります。 ただし、32 ETHのデポジットが必要となります。 より少額で自身のノードでバリデータを実行するには、[Rocket Pool](https://rocketpool.net/node-operators)のようなパーミッションレスなノードオペレーターがいる分散型プールがおすすめです。 -ステーキングとバリデーターキーの生成を始める最も簡単な方法は、[Holesky Testnet Staking Launchpad](https://holesky.launchpad.ethereum.org/)を使用することです。これにより、[Holesky上でノードを実行して](https://notes.ethereum.org/@launchpad/holesky)、セットアップをテストすることができます。 メインネットに移行する準備ができたら、今度は[メインネット・ステーキングランチパッド](https://launchpad.ethereum.org/)を使って、同じ手順を繰り返します。 +ステーキングとバリデータキーの生成を始める最も簡単な方法は、[Hoodiテストネットステーキング・ローンチパッド](https://hoodi.launchpad.ethereum.org/)を使用することです。これにより、[Hoodiでノードを実行](https://notes.ethereum.org/@launchpad/hoodi)してセットアップをテストできます。 メインネットの準備ができたら、[メインネット・ステーキング・ローンチパッド](https://launchpad.ethereum.org/)を使用して、これらの手順を繰り返すことができます。 -ステーキングオプションの概要については、[ステーキング](/staking)ページをご覧ください。 +[ステーキングページ](/staking)でステーキングオプションの概要を確認してください。 ### ノードの使用 {#using-the-node} -実行クライアントは、トランザクションの送信や、イーサリアムネットワーク上のスマートコントラクトとの対話やデプロイなど、さまざまな用途で使用可能な[RPC APIエンドポイント](/developers/docs/apis/json-rpc/)を提供します。 +実行クライアントは、さまざまな方法でトランザクションを送信したり、イーサリアムネットワーク上のスマートコントラクトと対話したり、デプロイしたりするために使用できる[RPC APIエンドポイント](/developers/docs/apis/json-rpc/)を提供しています。 -- 適切なプロトコルで手動呼び出し(例: `curl`) -- 指定したコンソールの接続(例: `geth attach`) -- Web3ライブラリを用いたアプリケーションへの実装(例: [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview)、[ethers](https://github.com/ethers-io/ethers.js/)) +- 適切なプロトコル(例：`curl`を使用)で手動で呼び出す +- 提供されているコンソールをアタッチする(例：`geth attach`) +- [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview)や[ethers](https://github.com/ethers-io/ethers.js/)などのWeb3ライブラリを使用してアプリケーションに実装する -クライアントによって、RPCエンドポイントの実装は異なります。 しかし、すべてのクライアントで使用できる標準的なJSON-RPCがあります。 概要については、[JSON-RPCドキュメント](/developers/docs/apis/json-rpc/)を参照してください。 イーサリアムネットワークからの情報を必要とするアプリケーションは、このRPCを使用できます。 例えば、人気のウォレットであるMetaMaskでは、[自分自身のRPCエンドポイントに接続](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node)することができ、プライバシーとセキュリティの向上を実現できます。 +クライアントによって、RPCエンドポイントの実装は異なります。 しかし、すべてのクライアントで使用できる標準的なJSON-RPCがあります。 概要については、[JSON-RPCのドキュメント](/developers/docs/apis/json-rpc/)をお読みください。 イーサリアムネットワークからの情報を必要とするアプリケーションは、このRPCを使用できます。 例えば、人気のウォレットであるMetaMaskでは、[自身のRPCエンドポイントに接続](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node)でき、プライバシーとセキュリティ面で大きなメリットがあります。 -コンセンサスクライアントは、すべて[ビーコンAPI](https://ethereum.github.io/beacon-APIs)を公開しており、これを利用してコンセンサスクライアントの状態を確認したり、[Curl](https://curl.se)などのツールを使ってリクエストを送り、ブロックやコンセンサスデータをダウンロードしたりすることができます。 詳細については、各コンセンサスクライアントのドキュメントを参照してください。 +すべてのコンセンサスクライアントは[Beacon API](https://ethereum.github.io/beacon-APIs)を公開しており、[Curl](https://curl.se)などのツールを使用してリクエストを送信することで、コンセンサスクライアントのステータスを確認したり、ブロックやコンセンサスデータをダウンロードしたりできます。 詳細については、各コンセンサスクライアントのドキュメントを参照してください。 -#### RPCへの接続 {#reaching-rpc} +#### RPCへのアクセス {#reaching-rpc} -実行クライアントのJSON-RPCデフォルトポートは`8545`ですが、設定でローカルエンドポイントのポートを変更することもできます。 デフォルトでは、RPCインターフェースはコンピュータのローカルホストからしかアクセスできません。 リモートからアクセスするには、アドレスを`0.0.0.0`に変更して、パブリックに公開します。 これにより、ローカルネットワーク内だけでなく、パブリックIPアドレスでも接続できるようになります。 また、ほとんどの場合、ルーターでポート転送を設定する必要があります。 +実行クライアントのJSON-RPCのデフォルトポートは`8545`ですが、設定でローカルエンドポイントのポートを変更できます。 デフォルトでは、RPCインターフェースはコンピュータのローカルホストからしかアクセスできません。 リモートからアクセスできるようにするには、アドレスを`0.0.0.0`に変更して公開するとよいでしょう。 これにより、ローカルネットワーク内だけでなく、パブリックIPアドレスでも接続できるようになります。 また、ほとんどの場合、ルーターでポート転送を設定する必要があります。 インターネットにポートを公開するアプローチは、インターネット上の誰でもノードをコントロールできるようになるため、注意が必要です。 悪意のある者がノードにアクセスしてシステムをダウンさせたり、クライアントをウォレットとして使用している場合は、資金が盗まれる可能性があります。 -これを回避するには、危険性のあるRPCメソッドを変更できないようにすることです。 例えば、Gethの場合、フラグで変更可能なメソッドを明示することができます。`--http.api web3,eth,txpool`. +これを回避するには、危険性のあるRPCメソッドを変更できないようにすることです。 例えば、Gethでは、`--http.api web3,eth,txpool`というフラグで変更可能なメソッドを宣言できます。 -RPCインターフェースへのアクセスは、エッジレイヤーAPIの開発、もしくはNginxのようなWebサーバアプリケーションから、クライアントのローカルアドレスやポートに接続することで拡張できます。 デベロッパーは、ミドルレイヤーを活用することで、RPCインターフェースを安全に`https`接続で使えるように、証明書を設定することもできます。 +RPCインターフェースへのアクセスは、エッジレイヤーAPIの開発、もしくはNginxのようなWebサーバアプリケーションから、クライアントのローカルアドレスやポートに接続することで拡張できます。 中間レイヤーを活用することで、開発者はRPCインターフェースへの安全な`https`接続のための証明書を設定することもできます。 -ノードのRPCエンドポイントへのアクセスを付与する方法は、Webサーバやプロキシ、外向けのREST APIを設定するだけではありません。 独自の[Tor](https://www.torproject.org/)オニオンサービス上でノードをホストすれば、プライバシーを保護しつつ、パブリックからアクセス可能なエンドポイントを設定することができます。 これにより、静的なパブリックIPアドレスやオープンポートを使用せずに、ローカルネットワーク外からRPCにアクセスできます。 ただし、Torネットワークはすべてのアプリケーションでサポートされているわけではなく、接続が不安定なネットワーク経由からのみRPCエンドポイントにアクセスできる点に注意してください。 +ノードのRPCエンドポイントへのアクセスを付与する方法は、Webサーバやプロキシ、外向けのREST APIを設定するだけではありません。 プライバシーを保護しながら一般に到達可能なエンドポイントを設定するもう1つの方法は、独自の[Tor](https://www.torproject.org/)オニオンサービスでノードをホストすることです。 これにより、静的なパブリックIPアドレスやオープンポートを使用せずに、ローカルネットワーク外からRPCにアクセスできます。 ただし、Torネットワークはすべてのアプリケーションでサポートされているわけではなく、接続が不安定なネットワーク経由からのみRPCエンドポイントにアクセスできる点に注意してください。 -これを行うには、自身の[オニオンサービス](https://community.torproject.org/onion-services/)を作成する必要があります。 オニオンサービスのセットアップ方法は、[ドキュメント](https://community.torproject.org/onion-services/setup/)を参照してください。 RPCポートへのプロキシを使ってWebサーバを指すか、直接RPCを指すことができます。 +そのためには、独自の[オニオンサービス](https://community.torproject.org/onion-services/)を作成する必要があります。 独自のサービスをホストするには、オニオンサービスのセットアップに関する[ドキュメント](https://community.torproject.org/onion-services/setup/)を確認してください。 RPCポートへのプロキシを使ってWebサーバを指すか、直接RPCを指すことができます。 -最後に、最も一般的なVPNを使って、内部ネットワークへのアクセスを提供することもできます。 ユースケースやノードへのアクセスが必要なユーザーの人数によっては、安全なVPN接続は選択肢の1つとなります。 [OpenVPN](https://openvpn.net/)は、OSIレイヤー2やレイヤー3の安全なネットワーク拡張機能を実装した、フル機能のSSL VPNです。業界標準のSSL/TLSプロトコルを用いており、証明書ベースの認証やスマートカード認証、ユーザ名/パスワード認証など、さまざまな柔軟なクライアント認証方法に対応しています。また、ファイアウォールルールを使って、ユーザーやグループ固有のアクセスコントロールポリシーを設定し、VPNの仮想インターフェースに適用することもできます。 +最後に、最も一般的なVPNを使って、内部ネットワークへのアクセスを提供することもできます。 ユースケースやノードへのアクセスが必要なユーザーの人数によっては、安全なVPN接続は選択肢の1つとなります。 OpenVPNは、OSIレイヤー2やレイヤー3の安全なネットワーク拡張機能を実装した、フル機能のSSL VPNです。業界標準のSSL/TLSプロトコルを用いており、証明書ベースの認証やスマートカード認証、ユーザ名/パスワード認証など、さまざまな柔軟なクライアント認証方法に対応しています。また、ファイアウォールルールを使って、ユーザーやグループ固有のアクセスコントロールポリシーを設定し、VPNの仮想インターフェースに適用することもできます。 ### ノードの運用 {#operating-the-node} ノードが正常に動作するためには、定期的に監視し、 必要に応じてメンテナンスを行う必要があります。 -#### ノードのオンライン状態の維持 {#keeping-node-online} +#### ノードのオンライン状態を維持する {#keeping-node-online} ノードが常時オンラインになっている必要はありませんが、ネットワークと同期させるためにできるだけオンラインにしておく必要があります。 シャットダウンして再起動することもできますが、以下の点に注意してください。 @@ -436,45 +439,46 @@ RPCインターフェースへのアクセスは、エッジレイヤーAPIの - 強制シャットダウンを行うと、データベースに損傷を与え、ノード全体の再同期が必要になることがある。 - クライアントはネットワークとの同期が解除され、再起動時に再同期が必要になる。 ノードは最後にシャットダウンされたところから同期を開始できるが、オフラインになっていた時間に応じて処理時間が増加する。 -_これはコンセンサスレイヤーのバリデータノードには適用されません。_ノードをオフラインにすると、ノードに依存するすべてのサービスに影響を及ぼします。 _ステーキング_目的でノードを実行している場合は、可能な限りダウンタイムを最小限に抑えるようにしてください。 +_これはコンセンサスレイヤーのバリデータノードには適用されません。_ ノードをオフラインにすると、ノードに依存するすべてのサービスに影響を及ぼします。 もし_ステーキング_目的でノードを実行している場合は、ダウンタイムをできるだけ最小限に抑えるようにしてください。 #### クライアントサービスの作成 {#creating-client-services} -起動時にクライアントを自動起動するサービスを作成することを検討してください。 例えば、Linuxサーバでは`systemd`などでサービスを作成し、権限が制限されたユーザーの下で、適切な設定でクライアントを実行し、自動的に再起動するように作成するのがお勧めです。 +起動時にクライアントを自動起動するサービスを作成することを検討してください。 例えば、Linuxサーバでは、`systemd`などでサービスを作成し、権限が制限されたユーザーの下で、適切な設定でクライアントを実行し、自動的に再起動するように作成するのがお勧めです。 #### クライアントの更新 {#updating-clients} -クライアントソフトウェアは、最新のセキュリティパッチ、機能、 [EIP](/eips/)の最新バージョンを常にインストールしておく必要があります。 特に、[ハードフォーク](/ethereum-forks/)が行われる前に、正しいクライアントバージョンを実行していることを確認してください。 +クライアントソフトウェアは、最新のセキュリティパッチ、機能、 [EIP](/eips/)の最新バージョンを常にインストールしておく必要があります。 特に[ハードフォーク](/ethereum-forks/)の前には、正しいクライアントバージョンを実行していることを確認してください。 -> 重要なネットワーク更新の前には、イーサリアム・ファウンデーション(EF)の[ブログ](https://blog.ethereum.org)で投稿されます。 [これらのお知らせを購読する](https://blog.ethereum.org/category/protocol#subscribe)ことで、ノードの更新が必要なときにメールで通知を受け取ることができます。 +> 重要なネットワーク更新の前には、イーサリアム・ファウンデーション(EF)の[ブログ](https://blog.ethereum.org)で投稿されます。 これらのお知らせを[購読](https://blog.ethereum.org/category/protocol#subscribe)することで、ノードの更新が必要なときにメールで通知を受け取ることができます。 クライアントの更新は非常に簡単です。 各クライアントのドキュメントに具体的な手順が記載されていますが、一般的には、最新版をダウンロードし、新しい実行ファイルを使ってクライアントを再起動するだけです。 アップデートが適用され、クライアントは前回終了したところから再開します。 各クライアントは、ピアツーピアプロトコルで使用される、人間が判読できるバージョン文字列を持っており、この文字列はコマンドラインからもアクセスできます。 このバージョン文字列を使って、ユーザーは自分が正しいバージョンを実行していることを確認できるほか、ネットワーク上で特定のクライアントの分散を定量化するために使われるブロックエクスプローラーやその他の分析ツールにも役立ちます。 バージョン文字列の詳細については、個々のクライアントのドキュメントを参照してください。 -#### その他のサービスの実行 {#running-additional-services} +#### 追加サービスの実行 {#running-additional-services} 自分でノードを実行すると、イーサリアムクライアントRPCへの直接アクセスを必要とするサービスを利用できます。 これらは、[レイヤー2ソリューション](/developers/docs/scaling/#layer-2-scaling)、ウォレットのバックエンド、ブロックエクスプローラー、デベロッパーツール、その他のイーサリアムインフラストラクチャのような、イーサリアム上に構築されたサービスです。 #### ノードの監視 {#monitoring-the-node} -ノードを適切に監視するために、メトリクスの収集を検討してください。 クライアントが提供するメトリクスエンドポイントから、ノードに関する包括的なデータを取得できます。 [InfluxDB](https://www.influxdata.com/get-influxdb/)や[Prometheus](https://prometheus.io/)などのツールを使用して、データベースを作成することができます。また、[Grafana](https://grafana.com/)などのソフトウェアを使って、データの視覚化やグラフ化を行うことができます。 このソフトウェアを使用するには、さまざまなセットアップ方法があり、ノードやネットワーク全体を視覚化するためのGrafanaダッシュボードも多種用意されています。 一例として、[Gethの監視に関するチュートリアル](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/)を参照してください。 +ノードを適切に監視するために、メトリクスの収集を検討してください。 クライアントが提供するメトリクスエンドポイントから、ノードに関する包括的なデータを取得できます。 [InfluxDB](https://www.influxdata.com/get-influxdb/)や[Prometheus](https://prometheus.io/)などのツールを使用してデータベースを作成し、[Grafana](https://grafana.com/)などのソフトウェアで視覚化やチャートに変換することができます。 このソフトウェアを使用するには、さまざまなセットアップ方法があり、ノードやネットワーク全体を視覚化するためのGrafanaダッシュボードも多種用意されています。 例として、[Gethの監視に関するチュートリアル](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/)をご覧ください。 モニタリングを行う際は、必ずマシンのパフォーマンスも監視してください。 ノードの初期同期中は、クライアントソフトウェアがCPUとRAMに大きな負荷をかけることがあります。 Grafanaに加えて、OSが提供する`htop`や`uptime`などのツールでも監視できます。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムステーキングガイド](https://github.com/SomerEsat/ethereum-staking-guides) _– Somer Esat、頻繁に更新_ -- [ガイド｜イーサリアムメインネットでステーキングをするためのバリデータのセットアップ方法](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _CoinCashew、定期的に更新_ -- [ETHStakerによるテストネットでのバリデータ運用ガイド](https://github.com/remyroy/ethstaker#guides) - _ETHStaker、定期的に更新_ -- [ノード運用者向けのマージに関するよくある質問](https://notes.ethereum.org/@launchpad/node-faq-merge) - _2022年7月_ -- [イーサリアムのフル検証ノードになるためのハードウェア要件の分析](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau、2018年9月24日_ -- [イーサリアムフルノードの運用: 手間を省きたい人向けのガイド](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _2019年11月7日 - Justin Leroux_ -- [イーサリアムメインネットでハイパーレジャーBesuノードの運用: メリット、要件、セットアップ](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Felipe Faraggi、2020年5月7日_ -- [モニタリングスタックでNethermindイーサリアムクライアントのデプロイ](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth、2020年7月8日_ +- [Ethereum Staking Guides](https://github.com/SomerEsat/ethereum-staking-guides) - _Somer Esat、頻繁に更新_ +- [ガイド | メインネットでイーサリアムステーキングのバリデータを設定する方法](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew、頻繁に更新_ +- [ETHStakerによるテストネットでのバリデータ運用ガイド](https://github.com/remyroy/ethstaker#guides) – _ETHStaker、定期的に更新_ +- [Sample AWS Blockchain Node Runner app for Ethereum Nodes](https://aws-samples.github.io/aws-blockchain-node-runners/docs/Blueprints/Ethereum) - _AWS、頻繁に更新_ +- [ノードオペレーター向けThe Merge FAQ](https://notes.ethereum.org/@launchpad/node-faq-merge) - _2022年7月_ +- [Analyzing the hardware requirements to be an Ethereum full validated node](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau、2018年9月24日_ +- [イーサリアムフルノードの実行：やる気のない人向けガイド](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux、2019年11月7日_ +- [Running a Hyperledger Besu Node on the Ethereum Mainnet: Benefits, Requirements, and Setup](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Felipe Faraggi、2020年5月7日_ +- [Deploying Nethermind Ethereum Client with Monitoring Stack](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth、2020年7月8日_ ## 関連トピック {#related-topics} -- [ ノードとクライアント](/developers/docs/nodes-and-clients/) +- [ノードとクライアント](/developers/docs/nodes-and-clients/) - [ブロック](/developers/docs/blocks/) - [ネットワーク](/developers/docs/networks/) diff --git a/public/content/translations/ja/developers/docs/oracles/index.md b/public/content/translations/ja/developers/docs/oracles/index.md index 1f464fd1f1d..efe48b615e1 100644 --- a/public/content/translations/ja/developers/docs/oracles/index.md +++ b/public/content/translations/ja/developers/docs/oracles/index.md @@ -1,50 +1,51 @@ --- -title: オラクル -description: オラクルを通じて、イーサリアムのスマートコントラクトは現実世界のデータにアクセスすることが可能となるため、ユーザーはより多くのユースケースを活用し、より大きな価値を実現できます。 +title: "オラクル" +description: "オラクルを通じて、イーサリアムのスマートコントラクトは現実世界のデータにアクセスすることが可能となるため、ユーザーはより多くのユースケースを活用し、より大きな価値を実現できます。" lang: ja --- -オラクルは、スマートコントラクト向けに、ブロックチェーンでオフチェーンのデータソースを利用可能にし、データフィードを生成するアプリケーションです。 イーサリアムベースのスマートコントラクトでは、デフォルトでブロックチェーンのネットワークの外に保存されている情報にアクセスできないため必要になります。 +オラクルとは、スマートコントラクト向けにオフチェーンのデータソースをブロックチェーンで利用できるようにするデータフィードを生成するアプリケーションです。 イーサリアムベースのスマートコントラクトでは、デフォルトでブロックチェーンのネットワークの外に保存されている情報にアクセスできないため必要になります。 -オフチェーンのデータを使用してスマートコントラクトを実行できるようにすることで、分散型アプリケーションの実用性と価値を高めることができます。 例えば、オンチェーンの予測市場では、オラクルに依存しており、結果に関する情報を提供することでユーザーの予測を検証します。 アメリカの次期大統領が誰になるかという予測に、アリスさんが20 ETHを賭けたと仮定してみましょう。 このユースケースの場合、予測市場を提供するDappは、選挙結果を確認し、ユーザー（例えば、アリス）が支払対象に含まれるかを確認するためにオラクルが必要になります。 +スマートコントラクトがオフチェーンデータを使用して実行できるようになることで、分散型アプリケーションの有用性と価値が広がります。 例えば、オンチェーンの予測市場は、ユーザーの予測を検証するために使用する結果に関する情報を提供するために、オラクルに依存しています。 アメリカの次期大統領が誰になるかという予測に、アリスさんが20 ETHを賭けたと仮定してみましょう。 このユースケースの場合、予測市場を提供するDappは、選挙結果を確認し、ユーザー（例えば、アリス）が支払対象に含まれるかを確認するためにオラクルが必要になります。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -本ページの内容は、[ノード](/developers/docs/nodes-and-clients/)、[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)、[イーサリアム仮想マシン](/developers/docs/evm/)を含むイーサリアムの基本について理解している読者を対象としています。 また、[スマートコントラクト](/developers/docs/smart-contracts/)、[スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)、特に[イベント](/glossary/#events)について十分に理解している必要があります。 +このページは、読者が[ノード](/developers/docs/nodes-and-clients/)、[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)、[EVM](/developers/docs/evm/)など、イーサリアムの基礎知識に精通していることを前提としています。 また、[スマートコントラクト](/developers/docs/smart-contracts/)と[スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)、特に[イベント](/glossary/#events)について十分に理解している必要があります。 ## ブロックチェーンにおけるオラクルとは何か？ {#what-is-a-blockchain-oracle} -オラクルとは、ブロックチェーン上で実行されるスマートコントラクトに対し、外部情報（チェーン外部に保存された情報）を取得し、検証し、送信するアプリケーションです。 オラクルは、オフチェーンデータを「プル」して、イーサリアムにブロードキャストすることに加え、ブロックチェーンの情報を外部のシステムに「プッシュ」することもできます。例えば、ユーザがイーサリムのトランザクションを経由して料金を送金するとスマートロックを解除するなどです。 +オラクルとは、ブロックチェーン上で実行されるスマートコントラクトに対し、外部情報（つまり、オフチェーンに保存された情報）を取得し、検証し、送信するアプリケーションです。 オラクルは、オフチェーンデータを「プル」してイーサリアムでブロードキャストするだけでなく、ブロックチェーンから外部システムに情報を「プッシュ」することもできます。例えば、ユーザーがイーサリアムのトランザクションを介して料金を支払うと、スマートロックが解除されるといった具合です。 -オラクルが無いと、スマートコントラクトは完全にオンチェーンのデータだけに限定されてしまいます。 +オラクルがなければ、スマートコントラクトは完全にオンチェーンのデータに限定されてしまいます。 -オラクルには、データソースの種類（ソースが1つであるか複数であるか）、信頼モデル（集中型か分散型か）、およびシステムのアーキテクチャ（即時読み取り型、公開／講読型、および要求／対応型）により様々な種類があります。 さらに、オンチェーンのコントラクトで使用するために外部データを取得するタイプ（入力用のオラクル）、ブロックチェーン上の情報をオフチェーンのアプリケーションに送信するタイプ（出力用のオラクル）、あるいはオフチェーンの処理タスクを実行するタイプ（処理用のオラクル）に区別することが可能です。 +オラクルには、データソースの種類（ソースが1つであるか複数であるか）、信頼モデル（集中型か分散型か）、およびシステムのアーキテクチャ（即時読み取り型、公開／講読型、および要求／対応型）により様々な種類があります。 また、オラクルは、オンチェーンコントラクトが使用するために外部データを取得するか (入力オラクル)、ブロックチェーンからオフチェーンアプリケーションに情報を送信するか (出力オラクル)、オフチェーンで計算タスクを実行するか (計算オラクル) によって区別することもできます。 ## スマートコントラクトにオラクルが必要な理由 {#why-do-smart-contracts-need-oracles} -多くの開発者にとって、スマートコントラクトとは、ブロックチェーン上の特定のアドレスで実行されるコードの集合に過ぎません。 しかし、[より一般的なスマートコントラクトの定義](/smart-contracts/)は、「特定の条件を満たすことで、当事者間の合意を強制できる自己実行型のソフトウェアプログラム」というものです。このため、「スマートコントラクト」と呼ばれます。 +多くの開発者にとって、スマートコントラクトとは、ブロックチェーン上の特定のアドレスで実行されるコードの集合に過ぎません。 しかし、[スマートコントラクト](/smart-contracts/)のより一般的な見解は、特定の条件が満たされたときに当事者間の合意を強制することができる自己実行型ソフトウェアプログラムであるということです。それゆえに、「スマートコントラクト」と呼ばれます。 -しかし、イーサリアムは決定論的なシステムであるため、スマートコントラクトを用いてユーザー間の合意を強制するプロセスは簡単には実現できません。 [決定論的なシステム](https://en.wikipedia.org/wiki/Deterministic_algorithm)とは、特定の初期状態と入力を与えられた場合に常に同一の結果を出力するシステムを指し、入力から出力を計算する過程においてランダム性や変化が発生しません。 +しかし、イーサリアムは決定論的なシステムであるため、スマートコントラクトを用いてユーザー間の合意を強制するプロセスは簡単には実現できません。 [決定論的システム](https://en.wikipedia.org/wiki/Deterministic_algorithm)とは、初期状態と特定の入力が与えられた場合に常に同じ結果を生成するシステムのことであり、入力から出力を計算する過程にランダム性やばらつきがないことを意味します。 -ブロックチェーンでは、ユーザーに対して、ブロックチェーン上で保存されたデータ_のみ_に基づく単純な二項対立（真または偽）の質問に基づいてコンセンサスに達するように制限することで、決定論的な実行を実現しています。 このような質問の例としては、以下のようなものがあります： +決定論的な実行を実現するため、ブロックチェーンは、ブロックチェーン自体に保存されているデータ_のみ_を使用して、単純な二者択一（真/偽）の質問についてノードがコンセンサスに達するように制限しています。 このような質問の例としては、以下のようなものがあります： - 「 （公開鍵で特定された) アカウント所有者は、このトランザクションにペアの秘密鍵で署名したか？」 - 「このアカウントは、このトランザクションの実行に必要な十分な資金を持つか？」 -- 「このトランザクションは、このスマートコントラクトの文脈において有効か？」 等々。 +- 「このトランザクションは、このスマートコントラクトの文脈において有効か？」 + 等々。 ブロックチェーンでは、外部ソースからの情報（つまり、現実世界の情報）を参照する場合、決定論的な処理が不可能になり、ブロックチェーンの状態変化が正当であるか否かについて各ノードが合意できなくなります。 価格情報を提供する一般的なAPIを通じて現在のETH/USDの交換レートを取得し、トランザクションを実行するスマートコントラクトの例を考えてみましょう。 この為替レートは頻繁に変化すると予想されるため（このAPI自体が非推奨となったり、ハッキングされる可能性を無視したとしても）、このスマートコントラクトにおける同一のコードを実行するノードが得る出力は常に異なる可能性があります。 イーサリアムのように、世界中に数千ものノードがトランザクションを処理するパブリックブロックチェーンにとっては、決定論的な処理は欠くことができません。 真実性を担保する中心的な権威が存在しないため、同じトランザクションを適用した後に同じ状態に到達するメカニズムがノードに必要になります。 例えば、Aというノードがスマートコントラクトのコードを実行した場合の出力が「3」である一方で、Bというノードの出力が「7」である場合、コンセンサスが崩壊するため、イーサリアムが持つ分散型のコンピューティングプラットフォームとしての価値が損なわれます。 -このシナリオはさらに、外部ソースから情報を引き出すことが可能なブロックチェーンを設計する際の問題点を浮き彫りにします。 オラクルは、オフチェーンのソースから情報を取り出し、ブロックチェーン上で保存してスマートコントラクトで使用できるようにすることで、この問題を解消します。 オンチェーンで保存された情報は改変不能な状態で公開されているため、イーサリアムのノードは、コンセンサスを破壊することなく、安全にオフチェーンのデータを読み込んで状態変化を計算できるのです。 +このシナリオはさらに、外部ソースから情報を引き出すことが可能なブロックチェーンを設計する際の問題点を浮き彫りにします。 しかし、オラクルはオフチェーンソースから情報を取得し、スマートコントラクトが利用できるようにブロックチェーンに保存することで、この問題を解決します。 オンチェーンに保存された情報は変更不可能で公開されているため、イーサリアムのノードは、コンセンサスを破ることなく、オラクルがインポートしたオフチェーンのデータを安全に使用して状態の変更を計算できます。 -通常オラクルは、この機能を提供するために、オンチェーンで実行されるスマートコントラクトと、何らかのオフチェーンのコンポーネントで構成されています。 オンチェーンのスマートコントラクトは、他のスマートコントラクトから提供されるデータリクエストを受け取ると、オラクルノードと呼ばれるオフチェーンのコンポーネントにこのリクエストを引き渡します。 このオラクルノードは、アプリケーション・プログラミング・インターフェース（API）などを用いてデータソースをクエリし、トランザクションを送信することで、リクエストされたデータをスマートコントラクトのストレージに保存することができます。 +このため、オラクルは通常、オンチェーンで実行されるスマートコントラクトと、いくつかのオフチェーンコンポーネントで構成されています。 オンチェーンのコントラクトは、他のスマートコントラクトからデータのリクエストを受け取り、それをオフチェーンのコンポーネント（オラクルノードと呼ばれる）に渡します。 このオラクルノードは、アプリケーション・プログラミング・インターフェース（API）などを用いてデータソースをクエリし、トランザクションを送信することで、リクエストされたデータをスマートコントラクトのストレージに保存することができます。 -つまり、ブロックチェーンにおけるオラクルとは、ブロックチェーンと外部環境の間に存在する情報のギャップを橋渡しする役割を提供することで、「ハイブリッド型のスマートコントラクト」を実現するものです。 ハイブリッド型のスマートコントラクトとは、オンチェーンのコントラクトコードとオフチェーンのインフラを組み合わせて機能するスマートコントラクトです。 分散型の予測市場は、ハイブリッド型のスマートコントラクトの代表例だと言えます。 その他の例としては、複数のオラクルを通じて特定の気候現象が発生したことが確認できた場合に保険金を支払うことができる農作物保険のスマートコントラクトが挙げられるでしょう。 +つまり、ブロックチェーンにおけるオラクルとは、ブロックチェーンと外部環境の間に存在する情報のギャップを橋渡しする役割を提供することで、「ハイブリッド型のスマートコントラクト」を実現するものです。 ハイブリッドスマートコントラクトとは、オンチェーンのコントラクトコードとオフチェーンのインフラストラクチャの組み合わせに基づいて機能するものです。 分散型の予測市場は、ハイブリッド型のスマートコントラクトの代表例だと言えます。 その他の例としては、複数のオラクルを通じて特定の気候現象が発生したことが確認できた場合に保険金を支払うことができる農作物保険のスマートコントラクトが挙げられるでしょう。 -## オラクル問題とは何か？ {#the-oracle-problem} +## オラクル問題とは何か？ オラクルの問題点 {#the-oracle-problem} -オラクルは重要な問題を解決する一方で、次のような複雑な問題も生じます。 +オラクルは重要な問題を解決しますが、次のような複雑な問題も引き起こします。 - コントラクトに読み込まれた情報が、適切なソースから抽出されているかや、改変されていないかを検証するにはどうすればよいか？ @@ -54,11 +55,11 @@ lang: ja さまざまなオラクルが、オラクル問題に対して異なる解決策を用意しています。これについては後ほど説明します。 オラクルは通常、次の課題にどのように対処するかによって評価されます。 -1. **正確性**：オラクルは、オフチェーン上の無効なデータに基づいてスマートコントラクトの状態変化をトリガーしてはなりません。 オラクルは、 データの_真正性_と_整合性_を保証する必要があります。 真正性とは、適切な情報ソースから取得されたことを意味し、完全性とはオンチェーンで送信されるまで取得した状態に手を加えられない（改変されない）ことを意味します。 +1. **正確性**：オラクルは、無効なオフチェーンデータに基づいてスマートコントラクトが状態変更をトリガーする原因となるべきではありません。 オラクルは、データの_真正性_と_完全性_を保証しなければなりません。 真正性とはデータが正しいソースから取得されたことを意味し、完全性とはデータがオンチェーンに送信される前に無傷（つまり、変更されていない）であったことを意味します。 -2. **可用性**：オラクルは、スマートコントラクトがアクションを実行し、状態変化をトリガーするのを遅延させたり、妨害してはなりません。 つまり、オラクル由来のデータは中断することなく_リクエストに応じて利用可能_でなければなりません。 +2. **可用性**：オラクルは、スマートコントラクトがアクションを実行し、状態変化をトリガーするのを遅らせたり、妨げたりしてはなりません。 これは、オラクルからのデータが中断することなく_リクエストに応じて利用可能_でなければならないことを意味します。 -3. **インセンティブとの両立性**：オラクルは、オフチェーンのデータ提供者に対し、スマートコントラクトに正しい情報を提供する意欲を高めるようなインセンティブを提供するものでなければなりません。 インセンティブの両立性には、_アトリビュータビリティ_と _アカウンタビリティ_が含まれます。 アトリビュータビリティとは、当該の外部情報とその提供者を相互に関連付けできる性質を指し、アカウンタビリティとは、データ提供者に対して提供するデータの品質について責任を負わせる性質を指します。そのため、提供された情報の質に基づいて報酬を与えたり、ペナルティを与えたりすることができます。 +3. **インセンティブ整合性**：オラクルは、オフチェーンのデータプロバイダーがスマートコントラクトに正しい情報を提出するようにインセンティブを与えるべきです。 インセンティブ整合性には、_帰属性_と_説明責任_が含まれます。 アトリビュータビリティとは、当該の外部情報とその提供者を相互に関連付けできる性質を指し、アカウンタビリティとは、データ提供者に対して提供するデータの品質について責任を負わせる性質を指します。そのため、提供された情報の質に基づいて報酬を与えたり、ペナルティを与えたりすることができます。 ## ブロックチェーンにおけるオラクルサービスの仕組み {#how-does-a-blockchain-oracle-service-work} @@ -66,7 +67,7 @@ lang: ja ユーザーとは、特定のアクションを実行する上で、ブロックチェーンの外部にある情報を必要とするエンティティ（つまり、スマートコントラクト）を指します。 オラクルサービスの基本的なワークフローでは、まずユーザーが、オラクルであるコントラクトに対してデータリクエストを送信します。 通常、データリクエストは以下の質問のうちいずれか／全部に回答するものです： -1. リクエストされた情報につき、オフチェーンのノードはどの情報ソースを参照できるか？ +1. オフチェーンノードは、要求された情報をどのソースから参照できますか？ 2. レポーターは、データソースから取得した情報をどのように処理し、有益なデータポイントを抽出するか？ @@ -78,39 +79,39 @@ lang: ja ### オラクルコントラクト {#oracle-contract} -オラクルコントラクトは、オラクルサービス用のオンチェーンコンポーネントです。 他のコントラクトからのデータのリクエストをリッスンしており、データクエリーをオラクルーノードへ中継します。そして、オラクルノードから返送されたデータをクライアントコントラクトへブロードキャストします。 さらに、オラクルコントラクトでは、返送されたデータポイントに対して一定の処理を実行し、リクエスト元のスマートコントラクトに集計値を送信することができます。 +オラクルコントラクトは、オラクルサービスのオンチェーンコンポーネントです。 他のコントラクトからのデータのリクエストをリッスンしており、データクエリーをオラクルーノードへ中継します。そして、オラクルノードから返送されたデータをクライアントコントラクトへブロードキャストします。 さらに、オラクルコントラクトでは、返送されたデータポイントに対して一定の処理を実行し、リクエスト元のスマートコントラクトに集計値を送信することができます。 -オラクルコントラクトは、クライアントのコントラクトがデータリクエストを行う際に呼び出す関数の一部を公開します。 新たなクエリを受け取ったスマートコントラクトは、このデータリクエストの詳細を含む[ログイベント](/developers/docs/smart-contracts/anatomy/#events-and-logs)を発行します。 ログイベントが発行されると、このログを講読しているオフチェーンのノードに対して通知が送信され（通常は、JSON-RPC`eth_subscribe`コマンドを用いる）、これらのノードはログイベントで定義されたデータを取得する作業を開始します。 +オラクルコントラクトは、クライアントのコントラクトがデータリクエストを行う際に呼び出す関数の一部を公開します。 新しいクエリを受け取ると、スマートコントラクトはデータリクエストの詳細を含む[ログイベント](/developers/docs/smart-contracts/anatomy/#events-and-logs)を発行します。 これはログを購読しているオフチェーンノード（通常はJSON-RPC `eth_subscribe` コマンドのようなものを使用）に通知し、ログイベントで定義されたデータを取得します。 -以下は、Pedro Costaが作成した[オラクルコントラクトのサンプルコード](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e)です。 このコードは、他のスマートコントラクトからのリクエストに応じて、オフチェーンのAPIをクエリし、リクエストされた情報をブロックチェーンで保存するというシンプルなオラクルサービスを提供します： +以下は、Pedro Costaによる[オラクルコントラクトの例](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e)です。 これは、他のスマートコントラクトからのリクエストに応じてオフチェーンAPIをクエリし、リクエストされた情報をブロックチェーンに保存できるシンプルなオラクルサービスです： ```solidity pragma solidity >=0.4.21 <0.6.0; contract Oracle { - Request[] requests; //list of requests made to the contract - uint currentId = 0; //increasing request id - uint minQuorum = 2; //minimum number of responses to receive before declaring final result - uint totalOracleCount = 3; // Hardcoded oracle count + Request[] requests; // コントラクトに対して行われたリクエストのリスト + uint currentId = 0; // リクエストIDをインクリメント + uint minQuorum = 2; // 最終結果を宣言する前に受け取る最小応答数 + uint totalOracleCount = 3; // ハードコードされたオラクルの数 - // defines a general api request + // 一般的なAPIリクエストを定義 struct Request { - uint id; //request id - string urlToQuery; //API url - string attributeToFetch; //json attribute (key) to retrieve in the response - string agreedValue; //value from key - mapping(uint => string) answers; //answers provided by the oracles - mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted) + uint id; // リクエストID + string urlToQuery; // APIのURL + string attributeToFetch; // レスポンスで取得するJSON属性（キー） + string agreedValue; // キーからの値 + mapping(uint => string) answers; // オラクルから提供された回答 + mapping(address => uint) quorum; // 回答を照会するオラクル（1=オラクルはまだ投票していない、2=オラクルは投票済み） } - //event that triggers oracle outside of the blockchain + // ブロックチェーンの外部でオラクルをトリガーするイベント event NewRequest ( uint id, string urlToQuery, string attributeToFetch ); - //triggered when there's a consensus on the final result + // 最終結果についてコンセンサスが得られたときにトリガーされる event UpdatedRequest ( uint id, string urlToQuery, @@ -127,23 +128,23 @@ contract Oracle { uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); Request storage r = requests[length-1]; - // Hardcoded oracles address + // ハードコードされたオラクルのアドレス r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; - // launch an event to be detected by oracle outside of blockchain + // ブロックチェーンの外部でオラクルによって検出されるイベントを発生させる emit NewRequest ( currentId, _urlToQuery, _attributeToFetch ); - // increase request id + // リクエストIDをインクリメント currentId++; } - //called by the oracle to record its answer + // 回答を記録するためにオラクルから呼び出される function updateRequest ( uint _id, string memory _valueRetrieved @@ -151,18 +152,18 @@ contract Oracle { Request storage currRequest = requests[_id]; - //check if oracle is in the list of trusted oracles - //and if the oracle hasn't voted yet + // オラクルが信頼できるオラクルのリストに含まれているか確認 + // かつ、オラクルがまだ投票していないか確認 if(currRequest.quorum[address(msg.sender)] == 1){ - //marking that this address has voted + // このアドレスが投票済みであることをマーク currRequest.quorum[msg.sender] = 2; - //iterate through "array" of answers until a position if free and save the retrieved value + // 空きポジションが見つかるまで回答の「配列」を反復処理し、取得した値を保存 uint tmpI = 0; bool found = false; while(!found) { - //find first empty slot + // 最初の空きスロットを見つける if(bytes(currRequest.answers[tmpI]).length == 0){ found = true; currRequest.answers[tmpI] = _valueRetrieved; @@ -172,8 +173,8 @@ contract Oracle { uint currentQuorum = 0; - //iterate through oracle list and check if enough oracles(minimum quorum) - //have voted the same answer as the current one + // オラクルのリストを反復処理し、十分なオラクル（最小定足数）があるか確認 + // 現在の回答と同じ回答に投票したか for(uint i = 0; i < totalOracleCount; i++){ bytes memory a = bytes(currRequest.answers[i]); bytes memory b = bytes(_valueRetrieved); @@ -198,57 +199,57 @@ contract Oracle { ### オラクルノード {#oracle-nodes} -オラクルノードは、オラクルサービス用のオフチェーンコンポーネントです。 オラクルノードは、サードパーティのサーバーでホストされているAP などの外部ソースから情報を抽出します。そして、スマートコントラクで使用できるようにオンチェーンへ送信します。 オラクルノードは、オンチェーンのオラクルコントラクトからのイベントをリッスンし、ログに記載されたタスクを実行します。 +オラクルノードは、オラクルサービスのオフチェーンコンポーネントです。 外部ソース（サードパーティのサーバーでホストされているAPIなど）から情報を抽出し、スマートコントラクトが利用できるようにオンチェーンに配置します。 オラクルノードは、オンチェーンのオラクルコントラクトからのイベントをリッスンし、ログに記載されたタスクを完了させます。 -オラクルノードにおける一般的なタスクとしては、APIサービスに対して[HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp)を送信し、レスポンスを解析して適切なデータを抽出した上で、ブロックチェーンが読み取り可能な出力としてフォーマットし、オラクルコントラクトへのトランザクションに含めることでオンチェーンに送信するというものがあります。 オラクルノードはまた、「真正性証明」を用いて、提出された情報の正当性および完全性を証明するように要求される場合がありますが、これについては以下のセクションで説明します。 +オラクルノードの一般的なタスクは、[HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp)リクエストをAPIサービスに送信し、レスポンスを解析して関連データを抽出し、ブロックチェーンで読み取り可能な出力にフォーマットし、オラクルコントラクトへのトランザクションに含めてオンチェーンに送信することです。 オラクルノードはまた、「真正性証明」を用いて、提出された情報の正当性および完全性を証明するように要求される場合がありますが、これについては以下のセクションで説明します。 -計算型のオラクルも、計算タスク（ガス代およびブロックサイズの制限により、オンチェーンでの実行が非現実的であるため）を実行するためにオフチェーンのノードに依存します。 例えば、ランダムであることが検証可能な値を生成するタスク（ブロックチェーンベースのゲームで用いる）につき、オラクルノードが活用される場合があります。 +計算オラクルも、ガス代やブロックサイズの制限からオンチェーンでの実行が非現実的な計算タスクを実行するために、オフチェーンノードに依存します。 例えば、ランダムであることが検証可能な値を生成するタスク（ブロックチェーンベースのゲームで用いる）につき、オラクルノードが活用される場合があります。 ## オラクルの設計パターン {#oracle-design-patterns} -オラクルには、_即時読み取り型_、_出版/講読型_、および_リクエスト/レスポンス型_などの様々な種類があり、イーサリアムのスマートコントラクトでは、出版/講読型およびリクエスト/レスポンス型が広く活用されています。 ここでは、出版/購読型モデルとリクエスト/レスポンス型モデルについて簡単に説明します。 +オラクルには、_即時読み取り_、_パブリッシュ/サブスクライブ_、_リクエスト/レスポンス_などさまざまなタイプがあり、後の2つはイーサリアムのスマートコントラクトで最もよく使われています。 ここでは、出版/購読型モデルとリクエスト/レスポンス型モデルについて簡単に説明します。 -### 出版/購読型のオラクル {#publish-subscribe-oracles} +### パブリッシュ/サブスクライブ型オラクル {#publish-subscribe-oracles} このタイプのオラクルでは、他のコントラクトが定期的に情報を読み込むことが可能な「データフィード」を提供します。 このデータフィードにおけるデータは頻繁に変化すると想定されるため、クライアントであるコントラクトは、オラクルのストレージに含まれるデータが更新されたかどうかをリッスンする必要があります。 例えば、最新の ETH-USDにおける価格情報をユーザーに提供するオラクルがあります。 -### リクエスト/レスポンス型のオラクル {#request-response-oracles} +### リクエスト/レスポンス型オラクル {#request-response-oracles} リクエスト/レスポンス型のメカニズムにおいては、クライアントのコントラクトは出版/購読型のオラクルでは提供されない任意のデータをリクエストできます。 リクエスト/レスポンス型のオラクルは、データセットが大きすぎてスマート コントラクトのストレージに保存できない場合や、ユーザーが常時データのごく一部しか必要としない場合に適しています。 -リクエスト/レスポンス型のオラクルは、出版/購読型よりも複雑ですが、基本的な機能は上記セクションで説明した通りです。 この種類のオラクルは、データリクエストを受け取るオンチェーンのコンポーネントを持ち、オフチェーンのノードによる処理のためにリクエストを転送します。 +リクエスト/レスポンス型のオラクルは、出版/購読型よりも複雑ですが、基本的な機能は上記セクションで説明した通りです。 オラクルは、データリクエストを受信し、それを処理のためにオフチェーンノードに渡すオンチェーンコンポーネントを持ちます。 -データのクエリを開始するユーザーは、オフチェーンの情報ソースから情報を取得するコストを負担しなければなりません。 クライアントのコントラクトはさらに、オラクルコントラクトが当該リクエストで指定されたコールバック機能を通じてレスポンスを提供する際に発生するガス代につき、これを負担するのに十分な資金を持つ必要があります。 +データクエリを開始するユーザーは、オフチェーンソースから情報を取得するためのコストを負担する必要があります。 クライアントのコントラクトはさらに、オラクルコントラクトが当該リクエストで指定されたコールバック機能を通じてレスポンスを提供する際に発生するガス代につき、これを負担するのに十分な資金を持つ必要があります。 -## 集権型オラクルと分散型オラクルの比較 {#types-of-oracles} +## 中央集権型オラクルと分散型オラクルの比較 {#types-of-oracles} -### 集中型のオラクル {#centralized-oracles} +### 中央集権型オラクル {#centralized-oracles} -集中型のオラクルとは、オフチェーンの情報を集約し、リクエストに応じてオラクルコントラクトのデータを更新する作業に責任を負う単一のエンティティによって管理されたオラクルを指します。 集中型のオラクルは、単一の真実ソースを持つため、効率的であると言えます。 集中型のオラクルは、広く承認された署名を持つ所有者が直接、独自のデータセットを公開する場合においてはよく機能します。 しかし、次のような欠点があります。 +中央集権型オラクルは、オフチェーンの情報を集約し、要求に応じてオラクルコントラクトのデータを更新する責任を負う単一のエンティティによって管理されます。 集中型のオラクルは、単一の真実ソースを持つため、効率的であると言えます。 集中型のオラクルは、広く承認された署名を持つ所有者が直接、独自のデータセットを公開する場合においてはよく機能します。 しかし、次のような欠点があります。 -#### 正確性を保証しにくい {#low-correctness-guarantees} +#### 低い正確性の保証 {#low-correctness-guarantees} 集中型のオラクルでは、提供された情報が正しいか否かを確認する方法がありません。 たとえ「評判の良い」プロバイダーであっても、不正が行われたり、ハッキングを受ける可能性はあります。 当該オラクルが改ざんされた場合、スマートコントラクトは不適切なデータに基づいて実行されることになります。 -#### 可用性が低い {#poor-availability} +#### 低い可用性 {#poor-availability} -集中型のオラクルは、他のスマートコントラクトに対してオフチェーンのデータを常に提供することを保証しません。 オラクルの提供者が当該サービスを廃止したり、ハッカーがオラクルのオフチェーン・コンポーネントを乗っ取ってしまった場合、あなたのスマートコントラクトはDos攻撃の被害を受ける可能性があります。 +中央集権型オラクルは、他のスマートコントラクトに対してオフチェーンのデータを常に提供することを保証しません。 プロバイダーがサービスを停止したり、ハッカーがオラクルのオフチェーンコンポーネントを乗っ取ったりすると、あなたのスマートコントラクトはサービス拒否（DoS）攻撃のリスクにさらされます。 -#### インセンティブと両立しにくい {#poor-incentive-compatibility} +#### 低いインセンティブ整合性 {#poor-incentive-compatibility} 集中型のオラクルでは、データ提供者に対して正確／未改変の情報を送信するようにインセンティブを提要する仕組みが存在しないか、設計が不十分な場合が少なくありません。 正確であるがゆえにオラクルに支払っても、必ずしも公正であるとは限りません。 この問題は、スマートコントラクトによって管理される金額が増加するにつれて大きくなります。 -### 分散型のオラクル {#decentralized-oracles} +### 分散型オラクル {#decentralized-oracles} -分散型のオラクルは、障害が発生しうる単一の箇所を除去することで、集中型オラクルにおける様々な欠点を克服するように設計されています。 分散型のオラクルサービスは、オフチェーンのデータをスマートコントラクトに送信する事前に、コンセンサスを形成するピアツーピアのネットワークに参加する複数のユーザーにより構成されています。 +分散型のオラクルは、障害が発生しうる単一の箇所を除去することで、集中型オラクルにおける様々な欠点を克服するように設計されています。 分散型オラクルサービスは、ピアツーピアネットワークの複数の参加者で構成され、スマートコントラクトに送信する前にオフチェーンデータについてコンセンサスを形成します。 分散型のオラクルは、（理想的には）パーミッションレスであり、中央組織による管理が存在しないものでなくてはなりませんが、実際には、分散型オラクルがどの程度分散的であるかは各オラクルにより異なります。 例えば、あらゆるユーザーが参加できるものの、「オーナー」による承認が必要であり、過去の行動に基づき特定のノードを削除できる半分散型のオラクルネットワークも存在します。 その一方で、完全に分散型のオラクルネットワークも存在しており、これらは通常スタンドアロンのブロックチェーンとして実行され、各ノード間の連携や不正行為の処罰のためのコンセンサス・メカニズムが設定されています。 分散型のオラクルは、以下のような利点を持ちます： -### 正確性を保証しやすい {#high-correctness-guarantees} +### 高い正確性の保証 {#high-correctness-guarantees} -分散型のオラクルでは、様々な用いてデータの正しさを確認しようと試みます。 具体的には、リターンされた情報の真正性および完全性を誓約する証明を用いるアプローチや、オフチェーンのデータの正当性について複数のエンティティが集団的に同意することを要求するアプローチがあります。 +分散型のオラクルでは、様々な用いてデータの正しさを確認しようと試みます。 これには、返された情報の真正性と完全性を証明する証明の使用や、複数のエンティティがオフチェーンデータの有効性について集合的に合意することを要求することが含まれます。 #### 真正性の証明 {#authenticity-proofs} @@ -256,17 +257,17 @@ contract Oracle { 真正性の証明には、以下のようなものがあります： -**トランスポートレイヤー・セキュリティ（TLS）証明**：オラクルノードでは、トランスポートレイヤー・セキュリティ（TLS）プロトコルに基づくセキュアなHTTP接続を使用して、外部ソースからデータを取得することが多いです。 一部の分散型オラクルでは、TLSセッションを検証し（つまり、ノードが特定のサーバーとの間で情報を交換したことを確認し）、当該セッションにおける内容が未改変であることを確認するために、真正性証明を利用します。 +**トランスポートレイヤーセキュリティ（TLS）証明**：オラクルノードは、多くの場合、トランスポートレイヤーセキュリティ（TLS）プロトコルに基づく安全なHTTP接続を使用して、外部ソースからデータを取得します。 一部の分散型オラクルでは、TLSセッションを検証し（つまり、ノードが特定のサーバーとの間で情報を交換したことを確認し）、当該セッションにおける内容が未改変であることを確認するために、真正性証明を利用します。 -**信頼された実行環境（TEE）のアテステーション**：[信頼された実行環境](https://en.wikipedia.org/wiki/Trusted_execution_environment)（TEE）とは、ホストシステムの運用プロセスから分離された、サンドボックス化された計算環境です。 TEEでは、当該の計算環境においおて保存／使用されるアプリケーションコードまたはデータの完全性、機密性、および不変性が保証されます。 ユーザーはまた、当該のアプリケーション・インスタンスが信頼された実行環境において実行されていることを証明するアテステーションを生成することもできます。 +**高信頼実行環境（TEE）アテステーション**：[高信頼実行環境](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) は、ホストシステムの運用プロセスから隔離されたサンドボックス化された計算環境です。 TEEでは、当該の計算環境においおて保存／使用されるアプリケーションコードまたはデータの完全性、機密性、および不変性が保証されます。 ユーザーはまた、当該のアプリケーション・インスタンスが信頼された実行環境において実行されていることを証明するアテステーションを生成することもできます。 分散型オラクルの中には、オラクルノードの運用者に対してTEEのアテステーションを要求するものもあります。 このアテステーションは、ノードの運用者がオラクルクライアントのインスタンスを信頼された実行環境で実行していることを、ユーザーに保証するものです。 TEEでは、当該アプリケーションのコードおよびデータを改変したり、読み取るような外部プロセスが実行できないため、このようなアテステーションを通じて、オラクルノードが当該情報を未改変かつ機密の状態に保ったことを証明できます。 -#### コンセンサスに基づく情報の検証 {#consensus-based-validation-of-information} +#### コンセンサスベースの情報検証 {#consensus-based-validation-of-information} -集中型のオラクルでは、スマートコントラクトにデータを提供する際に、単一の真実ソースに依存するため、不正確な情報を公開する可能性が存在します。 分散型のオラクルでは、オフチェーンの情報に対するクエリに複数のオラクルノードを参加させることで、この問題を解決しようとします。 分散型のオラクルでは、複数のソースからのデータを比較することで、オンチェーンのコントラクトに無効な情報を提供するリスクを引き下げるのです。 +集中型のオラクルでは、スマートコントラクトにデータを提供する際に、単一の真実ソースに依存するため、不正確な情報を公開する可能性が存在します。 分散型オラクルは、複数のオラクルノードに依存してオフチェーン情報をクエリすることで、この問題を解決します。 複数のソースからのデータを比較することで、分散型オラクルはオンチェーンコントラクトに無効な情報が渡されるリスクを低減します。 -しかし、分散型のオラクルでは、様々なオフチェーンの情報ソースから取得した情報に含まれる不一致を解消する必要があります。 取得した情報の不一致を最小化し、オラクルコントラクトに提供されるデータが全オラクルノードの集合的な意見を反映したものであることを保証するために、分散型のオラクルでは以下のメカニズムを活用します： +しかし、分散型オラクルは、複数のオフチェーンソースから取得した情報の不一致に対処する必要があります。 取得した情報の不一致を最小化し、オラクルコントラクトに提供されるデータが全オラクルノードの集合的な意見を反映したものであることを保証するために、分散型のオラクルでは以下のメカニズムを活用します： ##### データの正確性に関する投票／ステーキング @@ -274,49 +275,49 @@ contract Oracle { 多数派の回答とは異なる回答を提供したノードは、ペナルティとして、より適切な値を提供したユーザーに保有トークンを奪われることになります。 各ノードに対して、データ提供前に担保の差し出しを義務付けることで、リターン最大化を目指す合理的な経済アクターと想定されるユーザーに対し、正直な行動を取るように誘導するインセンティブを与えることができます。 -ステーキングや投票は、悪意のある者が複数のアイデンティティを作成してコンセンサスシステムを悪用する[シビル攻撃](/glossary/#sybil-attack)から分散型オラクルを保護する役割も果たします。 しかし、ステーキングによっても、「フリーローディング」（他のユーザーから情報をコピーするオラクルノード）や、「怠惰な検証」（自身で検証せずに、多数派の意見に従うオラクルノード）の発生を防ぐことはできません。 +ステーキングや投票は、悪意のあるアクターがコンセンサスシステムを悪用するために複数のIDを作成する[シビル攻撃](/glossary/#sybil-attack)から分散型オラクルを保護します。 しかし、ステーキングによっても、「フリーローディング」（他のユーザーから情報をコピーするオラクルノード）や、「怠惰な検証」（自身で検証せずに、多数派の意見に従うオラクルノード）の発生を防ぐことはできません。 ##### シェリングポイントのメカニズム -[シェリングポイント](https://en.wikipedia.org/wiki/Focal_point_(game_theory))とは、特定の問題につき複数のエンティティ間におけるコミュニケーションが存在しない場合、常に同一のソリューションに回帰するというゲーム理論上の概念です。 シェリングポイントのメカニズムは、分散型のオラクルネットワークにおいて、データリクエストへの回答について各ノードがコンセンサスを得るためにしばしば利用されます。 +[シェリングポイント](https://en.wikipedia.org/wiki/Focal_point_\(game_theory\))とは、複数のエンティティがコミュニケーションなしに問題に対する共通の解決策に常にデフォルトで従うと仮定するゲーム理論の概念です。 シェリングポイントのメカニズムは、分散型のオラクルネットワークにおいて、データリクエストへの回答について各ノードがコンセンサスを得るためにしばしば利用されます。 -シェリングポイントの初期の発想としては、[SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)があります。これは、「スケーラー」質問（「ETHの価格はいくらか」といった大きさで回答できる質問）に対して、参加者がデポジットを入金することで回答できるデータフィードの提案でした。 全体の回答値のうち25%から75%の[パーセンタイル](https://en.wikipedia.org/wiki/Percentile)を提出した回答者に報酬が提供される一方で、中央値から大きく外れた回答を提供したユーザーには罰金が課せられます。 +これに関する初期のアイデアは [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) でした。これは、参加者がデポジットとともに「スカラー」の質問（「ETHの価格は？」など、回答が大きさで記述される質問）への回答を送信する、提案されたデータフィードです。 25パーセンタイルと75[パーセンタイル](https://en.wikipedia.org/wiki/Percentile)の間の値を提供したユーザーは報酬を受け取りますが、中央値から大きく外れた値を提供したユーザーはペナルティを受けます。 -SchellingCoinは現存していませんが、多くの分散型オラクル、特に[Maker Protocolを使用するオラクル](https://docs.makerdao.com/smart-contract-modules/oracle-module)では、シェリングポイントのメカニズムを活用することでオラクルデータの正確性を向上させています。 Makerプロトコルを採用したオラクルは、担保資産の市場価格を提出するノード（「リレイヤー」および「フィード」）で構成されるオフチェーンのP2Pネットワークと、提供された全ての値の中央値を算出するオンチェーンの「メディアナイザー」コントラクトで構成されます。 定められた遅延期間が経過すると、この中央値が当該資産における新たな参照価格になります。 +SchellingCoinは現在存在しませんが、多くの分散型オラクル、特に[Makerプロトコルのオラクル](https://docs.makerdao.com/smart-contract-modules/oracle-module)は、シェリングポイントのメカニズムを使用してオラクルデータの正確性を向上させています。 各Makerオラクルは、担保資産の市場価格を提出するオフチェーンのP2Pネットワークのノード（「リレイヤー」と「フィード」）と、提供されたすべての値の中央値を計算するオンチェーンの「Medianizer」コントラクトで構成されています。 定められた遅延期間が経過すると、この中央値が当該資産における新たな参照価格になります。 -シェリングポイントのメカニズムを採用している他のオラクルの例としては、[Chainlinkオフチェーン報告](https://docs.chain.link/docs/off-chain-reporting/)および[Witnet](https://witnet.io/)があります。 どちらのシステムでも、P2Pネットワークに含まれるオラクルノードからの回答は、平均値あるいは中央値といった単一の値に集約されます。 各ノードは、自らの回答がこの集約値とどれほど一致／乖離しているかに応じて、報酬／罰金を受けます。 +シェリングポイントメカニズムを使用するオラクルの他の例としては、[Chainlinkオフチェーンレポーティング](https://docs.chain.link/architecture-overview/off-chain-reporting)や[Witnet](https://witnet.io/)などがあります。 どちらのシステムでも、P2Pネットワークに含まれるオラクルノードからの回答は、平均値あるいは中央値といった単一の値に集約されます。 各ノードは、自らの回答がこの集約値とどれほど一致／乖離しているかに応じて、報酬／罰金を受けます。 -シェリングポイントのメカニズムは、分散化を保証しつつ、オンチェーンのフットプリントを最小化できる（1つのトランザクションのみ送信すればよい）点が魅力的だと言えます。 このメカニズムで分散化が可能なのは、各ノードに対して、提出済みの回答リストが平均値／中央値を算出するアルゴリズムに投入される事前に、同リストにサインオフすることが要求されるためです。 +シェリングポイントメカニズムは、分散化を保証しつつ、オンチェーンのフットプリントを最小限に抑えるため（送信する必要があるトランザクションは1つだけ）、魅力的です。 このメカニズムで分散化が可能なのは、各ノードに対して、提出済みの回答リストが平均値／中央値を算出するアルゴリズムに投入される事前に、同リストにサインオフすることが要求されるためです。 ### 可用性 {#availability} -分散型のオラクルサービスでは、スマートコントラクトに対するオフチェーンデータの提供可能性が高くなります。 これは、オフチェーンの情報ソースと、この情報をオンチェーンに転送する役割を担うノードの両方を分散化することによって実現されています。 +分散型オラクルサービスは、スマートコントラクトに対するオフチェーンデータの高い可用性を保証します。 これは、オフチェーン情報のソースと、情報をオンチェーンに転送する責任を負うノードの両方を分散化することで達成されます。 -この可用性により、オラクルコントラクトは、他のコントラクトのクエリを実行するために複数のノードに依存でき、これらの複数のノード自体もまた複数のデータソースに依存するため、障害耐性が高まります。 情報ソース_および_ノード＝オペレーターの両方において分散化を実現することが必須であり、同一の情報ソースから取得した情報を複数のオラクルノードが提出するようなネットワークでは、集中型オラクルの場合と同じ問題が発生してしまいます。 +この可用性により、オラクルコントラクトは、他のコントラクトのクエリを実行するために複数のノードに依存でき、これらの複数のノード自体もまた複数のデータソースに依存するため、障害耐性が高まります。 ソースレベル_と_ノードオペレーターレベルでの分散化は非常に重要です。同じソースから取得した情報を提供するオラクルノードのネットワークは、中央集権型オラクルと同じ問題に直面します。 -さらに、ステーキングベースのオラクルでは、データリクエストに迅速に対応しないノードペレーターに対してスラッシングを行うことも可能です。 これにより、オラクルノードに対して障害耐性を持つインフラに投資し、迅速にデータを提供するように促すことができます。 +また、ステークベースのオラクルが、データリクエストに迅速に応答しないノードオペレーターをスラッシュすることも可能です。 これにより、オラクルノードに対して障害耐性を持つインフラに投資し、迅速にデータを提供するように促すことができます。 -### インセンティブと両立しやすい {#good-incentive-compatibility} +### 高いインセンティブ整合性 {#good-incentive-compatibility} -分散型のオラクルでは、オラクルノード間における[ビザンチン将軍問題](https://en.wikipedia.org/wiki/Byzantine_fault)動作を防ぐために、様々なインセンティブの仕組みを導入しています。 具体的には、以下の方法で_アトリビュータビリティ_と_アカウンタビリティ_を実現しています： +分散型オラクルは、オラクルノード間の[ビザンチン](https://en.wikipedia.org/wiki/Byzantine_fault)的な振る舞いを防ぐために、さまざまなインセンティブ設計を実装しています。 具体的には、_帰属性_と_説明責任_を実現します： -1. 分散型オラクルのノードに対しては、データリクエストに対してレスポンスを提供する際に当該データに対する証明が要求される場合が多いです。 この署名情報は、データをリクエストする際に信頼性が低いオラクルノードを排除するなど、オラクルノードの過去の行動を評価する際に有益です。 Witnetの例としては、[アルゴリズミック評判システム](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system)があります。 +1. 分散型オラクルのノードに対しては、データリクエストに対してレスポンスを提供する際に当該データに対する証明が要求される場合が多いです。 この署名情報は、データをリクエストする際に信頼性が低いオラクルノードを排除するなど、オラクルノードの過去の行動を評価する際に有益です。 一例として、Witnetの[アルゴリズム評価システム](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system)が挙げられます。 2. すでに述べたように、分散型のオラクルでは、提出するデータの真実性に対するノード本人の確信に対してステーキングを義務付ける場合があります。 このノードのクレームが確認されれば、このステークは、正直な行動への報酬と共に返却されます。 ただし、提出した情報が正しくない場合には没収される可能性があるため、一定の説明責任を担保する手段となります。 -## スマートコントラクトにおけるオラクルの利用 {#applications-of-oracles-in-smart-contracts} +## スマートコントラクトにおけるオラクルのアプリケーション {#applications-of-oracles-in-smart-contracts} 以下に、イーサリアムにおけるオラクルの一般的なユースケースを紹介します： -### 金融データを取り出す {#retrieving-financial-data} +### 金融データの取得 {#retrieving-financial-data} -[分散型ファイナンス](/defi/)（DeFi）の アプリケーションは、P2Pによる資産の貸出、借入、および取引を可能にするものです。 これらのサービスを提供するには、為替データ（仮想通貨における法定通貨建ての価値を算出するため、あるいはトークンの価格を比較するため）や、資本市場に関するデータ（トークン化された金や米ドル等の資産の価値を算出するため）など、様々な金融情報を取得する必要があります。 +[分散型金融](/defi/)（DeFi）アプリケーションは、資産のピアツーピアの貸し借りや取引を可能にします。 これらのサービスを提供するには、為替データ（仮想通貨における法定通貨建ての価値を算出するため、あるいはトークンの価格を比較するため）や、資本市場に関するデータ（トークン化された金や米ドル等の資産の価値を算出するため）など、様々な金融情報を取得する必要があります。 例えばDeFiの貸出プロトコルでは、担保として預け入れられた様々な資産（例：ETH）の現在の市場価格をクエリできる機能が必要になります。 これは、コントラクトに対して、担保資産の価値を評価し、ユーザーがシステムからどれだけ借入可能かを決定する機能を提供するためです。 -DeFiの分野でよく利用される「価格オラクル」（多くの場合、こう呼ばれます）の例としては、Chainlinの価格フィード、Compound Protocolの[公開価格フィード](https://compound.finance/docs/prices)、Uniswapの[時間加重平均価格（TWAPs）](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles)、および[Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module)が挙げられます。 +DeFiで人気のある「価格オラクル」（しばしばそう呼ばれる）には、Chainlink Price Feeds、Compoundプロトコルの[Open Price Feed](https://compound.finance/docs/prices)、Uniswapの[時間加重平均価格（TWAP）](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles)、[Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module)などがあります。 -ビルダーは、プロジェクトにこれらの価格オラクルを組み込む前に、導入に伴う注意事項についてよく理解しておく必要があります。 この[記事](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/)では、これらの価格オラクルを使用したい場合に検討すべき事項について詳細に分析しています。 +ビルダーは、プロジェクトにこれらの価格オラクルを組み込む前に、導入に伴う注意事項についてよく理解しておく必要があります。 こちらの[記事](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/)では、前述の価格オラクルのいずれかを使用する際に考慮すべき点について、詳細な分析を提供しています。 以下のサンプルコードは、Chainlinkの価格フォードを使用してスマートコントラクト上で最新のETH価格を取得するものです： @@ -354,19 +355,19 @@ contract PriceConsumerV3 { } ``` -### 検証可能なランダム性を生成する {#generating-verifiable-randomness} +### 検証可能なランダム性の生成 {#generating-verifiable-randomness} ブロックチェーンベースのゲームや宝くじなど、一部のブロックチェーン・アプリケーションでは、適切に機能するために高度な予測不可能性およびランダム性が要求されます。 しかし、ブロックチェーンは決定論的な実行という特性を持つため、ランダム性を獲得する手段がありません。 -従来のアプローチは、`blockhash`のような擬似乱数暗号関数を使用するものでしたが、これらはプルーフ・オブ・ワークアルゴリズムを解く[マイナーによって操作される](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.)可能性がありました。 また、イーサリアムが[プルーフ・オブ・ステークへ移行](/roadmap/merge/)したことで、デベロッパーはオンチェーンの乱数生成に`blockhash`を頼ることができなくなりました。 その代わりに、ビーコンチェーンの [RANDAOメカニズム](https://eth2book.info/altair/part2/building_blocks/randomness)が新たな乱数の供給源として提供されています。 +元々のアプローチは`blockhash`のような疑似乱数暗号関数を使用することでしたが、これらは[マイナーによって操作される可能性](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.)がありました。 プルーフ・オブ・ワークアルゴリズムを解決します。 また、イーサリアムの[プルーフ・オブ・ステークへの移行](/roadmap/merge/)により、開発者はオンチェーンのランダム性のために`blockhash`に頼ることができなくなりました。 その代わりに、ビーコンチェーンの[RANDAOメカニズム](https://eth2book.info/altair/part2/building_blocks/randomness)が代替のランダム性のソースを提供します。 -ランダムな値をオフチェーンで生成した上でオンチェーンに送信することは可能ですが、このアプローチではユーザーに対する信頼性の要件が高くなります。 ユーザーは、生成された値が本当に予測不可能なメカニズムによって生成され、転送に伴う改変が生じていないことを信じなければならないためです。 +ランダムな値をオフチェーンで生成してオンチェーンに送信することも可能ですが、そうするとユーザーに高い信頼性が要求されます。 ユーザーは、生成された値が本当に予測不可能なメカニズムによって生成され、転送に伴う改変が生じていないことを信じなければならないためです。 -オフチェーンでの計算を念頭に置いて設計されたオラクルでは、オフチェーンでランダムな値をセキュアに生成した上で、生成プロセスの予測不可能性を確証する暗号化された証明と共にオンチェーンでブロードキャストすることで、この問題を解決します。 このようなアプローチの例としては、[Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) （検証可能なランダム関数）があります。これは、証明可能な形で、公平かつ操作不可の乱数を生成する機能（RNG）であり、予測不可能な計算値を必要とする用途を持つ信頼性が高いスマートコントラクトを開発する上で有益です。 +オフチェーン計算用に設計されたオラクルは、プロセスの予測不可能性を証明する暗号学的証明とともに、オフチェーンで安全に生成したランダムな結果をオンチェーンでブロードキャストすることで、この問題を解決します。 一例として、予測不可能な結果に依存するアプリケーションのための信頼できるスマートコントラクトを構築するのに役立つ、証明可能で公正かつ改ざん防止の乱数生成器（RNG）である[Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/)（検証可能なランダム関数）があります。 ### イベントの結果を取得する {#getting-outcomes-for-events} -オラクルを活用することで、現実世界で発生したイベントに応答できるスマートコントラクトを手軽に開発できます。 オラクルサービスでは、オラクルのオフチェーン・コンポーネントを通じて外部APIと接続し、外部のデータソースから取得した情報を消費することで、現実のイベントへの応答を可能にしています。 例えば、すでに紹介した予測用のDappの場合、信頼できるオフチェーンの情報ソース（例：AP）から選挙結果を取得するようにオラクルに要求することができます。 +オラクルを活用することで、現実世界で発生したイベントに応答できるスマートコントラクトを手軽に開発できます。 オラクルサービスは、コントラクトがオフチェーンコンポーネントを介して外部APIに接続し、それらのデータソースから情報を消費できるようにすることで、これを可能にします。 例えば、前述の予測dappは、信頼できるオフチェーンソース（例：AP通信）から選挙結果を返すようオラクルに要求することがあります。 オラクルを使用して現実世界の結果に基づいてデータを取得することで、斬新なユースケースを可能になります。ユースケースの例として、 分散型保険商品が効果的に機能させることがあります。この分野では、天気、災害などに関する正確な情報を必要としています。 @@ -374,57 +375,60 @@ contract PriceConsumerV3 { スマートコントラクトは、自動的に実行される訳ではありません。正確に言うと、スマートコントラクトのコードを実行するには、外部所有アカウント（EOA）まあたはその他のコントラクトアカウントが適切な関数をトリガーする必要があります。 大部分の場合、スマートコントラクトに含まれる関数の大部分は公開されており、EOAおよびその他のコントラクトにより呼び出すことができます。 -しかしスマートコントラクトには、他のコントラクトからはアクセスできない_プライベート関数_も含まれており、これらはDappの全般的な機能を実現する上で欠かせない関数になっています。 このようなプライベート関数の例としては、新規のNFTを定期的にミントする`mintERC721Token()`関数、予測市場で報酬を支払う関数、あるいはDEXにおいてステーキングされたトークンをアンロックする関数などが想定できるでしょう。 +しかし、コントラクト内には、他のユーザーからはアクセスできない_プライベート関数_も存在します。これらは、dapp全体の機能にとって非常に重要です。 例としては、ユーザーのために定期的に新しいNFTをミントする `mintERC721Token()` 関数、予測市場で支払いを授与する関数、またはDEXでステークされたトークンのロックを解除する関数などが挙げられます。 開発者は、アプリケーションのスムーズな動作を保証するために、これらの関数を一定の間隔でトリガーする必要があります。 しかし、このようなアプローチでは、開発者が反復的なタスクのために費やす時間が増加してしまうため、スマートコントラクトを自動的に実行するアプローチが有益なのです。 -一部の分散型オラクルのネットワークでは、ユーザーが定義したパラメータに従って、オフチェーンのオラクルノードがスマートコントラクトの関数をトリガーできる自動化サービスを提供しています。 このような自動化サービスは通常、ターゲットとなるコントラクトを当該のオラクルサービスに「登録」する必要がある他、オラクルの運用者に対して手数料を支払い、当該コントラクトをトリガーする際の条件または時間を指定する必要があります。 +一部の分散型オラクルネットワークは自動化サービスを提供しており、これによりオフチェーンのオラクルノードがユーザーによって定義されたパラメータに従ってスマートコントラクト関数をトリガーできます。 このような自動化サービスは通常、ターゲットとなるコントラクトを当該のオラクルサービスに「登録」する必要がある他、オラクルの運用者に対して手数料を支払い、当該コントラクトをトリガーする際の条件または時間を指定する必要があります。 -Chainlinkの[Keeper Network](https://chain.link/keepers)では、スマートコントラクトに対して、最小限の信頼性に基づき分散化された手法で定期的な保全タスクを実行するためのオプションが提供されています。 開発中のコントラクトをKeeper互換にしたり、Upkeepサービスを利用したい場合は、Keeperの[公式ドキュメント](https://docs.chain.link/docs/chainlink-keepers/introduction/)を参照してください。 +Chainlinkの[Keeper Network](https://chain.link/keepers)は、スマートコントラクトが定期的なメンテナンス作業を、信頼性を最小限に抑え、分散化された方法で外部委託するためのオプションを提供します。 コントラクトをKeeper互換にし、Upkeepサービスを利用する方法については、公式の[Keeperのドキュメント](https://docs.chain.link/docs/chainlink-keepers/introduction/)をお読みください。 -## ブロックチェーン・オラクルを使用する {#use-blockchain-oracles} +## ブロックチェーンオラクルの使い方 {#use-blockchain-oracles} イーサリアムのDappで使用できるオラクル・アプリケーションとしては、以下があります： -**[Chainlink](https://chain.link/)** - _Chainlinkの分散型オラクルネットワークでは、インプット情報、アウトプット情報、および計算処理における改ざん防止を徹底することで、あらゆるブロックチェーンにおける複雑なスマートコントラクトをサポートしています。_ +**[Chainlink](https://chain.link/)** - _Chainlinkの分散型オラクルネットワークは、改ざん防止の入力、出力、および計算を提供し、あらゆるブロックチェーン上の高度なスマートコントラクトをサポートします。_ + +**[RedStone Oracles](https://redstone.finance/)** - _RedStoneは、ガスを最適化したデータフィードを提供する分散型モジュラー型オラクルです。 リキッドステーキングトークン（LST）、リキッドリステーキングトークン（LRT）、ビットコインステーキングデリバティブなど、新しい資産の価格フィード提供に特化しています。_ **[Chronicle](https://chroniclelabs.org/)** - _Chronicleは、真にスケーラブルでコスト効率の高い、分散型かつ検証可能なオラクルを開発することで、オンチェーンでのデータ転送における現在の制約を克服します。_ -**[Witnet](https://witnet.io/)** - _Witnetは、パーミッションレス性、分散性、および耐検閲性を持つオラクルであり、スマートコントラクトを強力な暗号経済的な保証に基づいて現実世界のイベントに反応できるようにすることができます。_ +**[Witnet](https://witnet.io/)** - _Witnetは、パーミッションレス、分散型、検閲耐性のあるオラクルで、スマートコントラクトが強力な暗号経済学的保証をもって現実世界のイベントに反応するのを助けます。_ + +**[UMA Oracle](https://uma.xyz)** - _UMAのオプティミスティック・オラクルにより、スマートコントラクトは保険、金融デリバティブ、予測市場など、さまざまなアプリケーションのためにあらゆる種類のデータを迅速に受け取ることができます。_ -**[UMAオラクル](https://uma.xyz)** - _UMAのオプティミスティック・オラクルでは、保険、金融派生商品、および予測市場などのさまざまな用途を持つスマートコントラクトに対して、あらゆる種類のデータを迅速に取得する機能を追加することができます。_ +**[Tellor](https://tellor.io/)** - _Tellorは、あなたのスマートコントラクトが必要なときにいつでも簡単にデータを取得できる、透明でパーミッションレスなオラクルプロトコルです。_ -**[Tellor](https://tellor.io/)** - _Tellorは、あなたのスマートコントラクトが必要とする際に、常にどんな種類のデータでも取得可能にするための、透明性が高くパーミッションレスのオラクル・プロトコルです。_ +**[Band Protocol](https://bandprotocol.com/)** - _Band Protocolは、現実世界のデータとAPIを集約し、スマートコントラクトに接続するクロスチェーンデータオラクルプラットフォームです。_ -**[Band Protocol](https://bandprotocol.com/)** - _Band Protocolは、現実世界のデータを集約し、各種APIとスマートコントラクトを接続するための、クロスチェーンデータを対象とするオラクルプラットフォームです。_ +**[Pyth Network](https://pyth.network/)** - _Pyth Networkは、改ざん防止、分散化、自己持続可能な環境で、継続的な実世界のデータをオンチェーンで公開するために設計されたファーストパーティの金融オラクルネットワークです。_ -**[Pyth Network](https://pyth.network/)** - _Pyth Networkは、改ざん不可、分散化、および自己持続可能な特徴を持つ環境において、現実世界のデータを継続的にオンチェーンで公開するために設計された、ファーストパーティの金融オラクルネットワークです。_ +**[API3 DAO](https://www.api3.org/)** - _API3 DAOは、スマートコントラクト向けの分散型ソリューションにおいて、ソースの透明性、セキュリティ、スケーラビリティを向上させるファーストパーティのオラクルソリューションを提供しています。_ -**[API3 DAO](https://www.api3.org/)** - _API3 DAOでは、ファーストパーティのオラクルソリューションを提供しています。スマートコントラクトの分散型ソリューションにより、ソースの透明性、セキュリティ、スケーラビリティを向上させることができます。_ +**[Supra](https://supra.com/)** - すべてのブロックチェーン（パブリック（L1およびL2）またはプライベート（企業））を相互にリンクする、垂直統合されたクロスチェーンソリューションのツールキットで、オンチェーンおよびオフチェーンのユースケースで使用できる分散型オラクル価格フィードを提供します。 -**[Supra](https://supra.com/)** - クロスチェーンソリューションの垂直統合ツールキットで、パブリック(L1やL2)とプライベート(エンタープライズ)のあらゆるブロックチェーンを連結し、オンチェーンおよびオフチェーンのユースケースで使用できる分散型オラクルプライスフィードを提供します。 +**[Gas Network](https://gas.network/)** - ブロックチェーン全体にリアルタイムのガス価格データを提供する分散型オラクルプラットフォームです。 Gas Networkは、主要なガス価格データプロバイダーからのデータをオンチェーンに持ち込むことで、相互運用性の推進を支援しています。 Gas Networkは、イーサリアムメインネットや多くの主要なL2を含む35以上のチェーンのデータをサポートしています。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} **記事** -- [ブロックチェーン・オラクルとは何か？](https://chain.link/education/blockchain-oracles) — _Chainlink_ -- [ブロックチェーン・オラクルとは？](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) — _パトリック・コリンズ作成。_ -- [分散型オラクル：包括的な概要](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _ジュリアン・テヴェナード作成。_ -- [イーサリアムにおける ブロックチェーン・オラクルの実装](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _ペドロ・コスタ作成。_ -- [スマートコントラクトがAPIコールを行えないのはなぜか？](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_ -- [価格オラクルを使用したい場合の検討事項](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_ +- [ブロックチェーンオラクルとは何か？](https://chain.link/education/blockchain-oracles) — _Chainlink_ +- [ブロックチェーンオラクルとは何か？](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Patrick Collins_ +- [分散型オラクル：包括的な概要](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Julien Thevenard_ +- [イーサリアムでブロックチェーンオラクルを実装する](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_ +- [スマートコントラクトはなぜAPIコールができないのか？](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_ +- [価格オラクルを使いたいあなたへ](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_ -**ビデオ** +**動画** -- [オラクルによるブロックチェーンの有用性の拡大](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_ -- [ファーストパーティーオラクルとサードバーティーオラクルの違い](https://blockchainoraclesummit.io/first-party-vs-third-party-oracles/) - _ブロックチェーン・オラクル・サミット_ +- [オラクルとブロックチェーンの有用性の拡大](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_ **チュートリアル** -- [Solidity上でイーサリアムの現在価格を取得する方法](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_ +- [Solidityでイーサリアムの現在価格を取得する方法](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_ - [オラクルデータの利用](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_ **プロジェクト実例** -- [Solidityを用いてイーサリアムにChainlinをフルに導入する際のスタータープロジェクト](https://github.com/hackbg/chainlink-fullstack) — _HackBG_ +- [Solidityによるイーサリアム向けの完全なChainlinkスタータープロジェクト](https://github.com/hackbg/chainlink-fullstack) — _HackBG_ diff --git a/public/content/translations/ja/developers/docs/programming-languages/dart/index.md b/public/content/translations/ja/developers/docs/programming-languages/dart/index.md index 9807fdc4949..2e8ed0c21c7 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/dart/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/dart/index.md @@ -1,28 +1,30 @@ --- -title: Dartデベロッパーのためのイーサリアム -description: Dart言語を使用してイーサリアムを開発する方法を学ぶ +title: "Dartデベロッパーのためのイーサリアム" +description: "Dart言語を使用してイーサリアムを開発する方法を学ぶ" lang: ja incomplete: true --- -## スマートコントラクトとSolidityを使い始める {#getting-started-with-smart-contracts-and-solidity} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-solidity} ## チュートリアル {#tutorials} -- [Flutterとブロックチェーン – Hello World dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/)で、開始手順を段階的に説明しています。 - 1. [Solidity](https://soliditylang.org/)でスマートコントラクトを記述する - 2. Dartでユーザーインターフェースを記述する -- [Flutterを使用したモバイルdappの構築](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a)は、より簡潔な説明となっています。すでに基礎を理解している場合は、こちらを参照することをお勧めします。 -- ビデオでの学習をご希望の場合は、[初めてのブロックチェーンFlutterアプリの構築](https://www.youtube.com/watch?v=3Eeh3pJ6PeA)をご覧いただけます。このビデオは約1時間です。 -- 時間がない場合は、[イーサリアムでのFlutterとDartを使用したブロックチェーンの分散型アプリの構築](https://www.youtube.com/watch?v=jaMFEOCq_1s)をご覧ください。このビデオはわずか20分です。 -- [WalletConnectによるFlutterアプリケーションのMetaMaskとWeb3Modalの統合](https://www.youtube.com/watch?v=v_M2buHCpc4) - この短編ビデオでは、WalletConnectの [Web3Modal](https://pub.dev/packages/web3modal_flutter)ライブラリを使用してMetaMaskをFlutterアプリケーションに統合する手順を説明します。 -- [SolidityとFlutterによるモバイル・ブロックチェーン・デベロッパー・ブートキャンプ・コース](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - フルスタック・モバイル・ブロックチェーン・デベロッパー・コースのプレイリスト +- [Flutterとブロックチェーン – Hello World Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/)では、開発を始めるためのすべての手順を解説しています： + 1. [Solidity](https://soliditylang.org/)でスマートコントラクトを記述する + 2. Dartでユーザーインターフェースを記述する +- [Flutterでモバイルdappを構築する](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a)ははるかに短く、すでに基本を理解している場合に適しているかもしれません +- ビデオを見て学習したい場合は、約1時間の長さの[初めてのブロックチェーンFlutterアプリの構築](https://www.youtube.com/watch?v=3Eeh3pJ6PeA)を視聴できます。 +- 時間がない場合は、わずか20分ほどの[イーサリアムでのFlutterとDartを使用したブロックチェーン分散型アプリの構築](https://www.youtube.com/watch?v=jaMFEOCq_1s)がおすすめです。 +- [WalletConnectのWeb3Modalを使用したFlutterアプリケーションへのMetaMaskの統合](https://www.youtube.com/watch?v=v_M2buHCpc4) - この短いビデオでは、WalletConnectの[Web3Modal](https://pub.dev/packages/web3modal_flutter)ライブラリを使用して、MetaMaskをFlutterアプリケーションに統合する手順を説明します。 +- [SolidityとFlutterによるモバイルブロックチェーンデベロッパーブートキャンプコース](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - フルスタックのモバイルブロックチェーンデベロッパーコースのプレイリスト ## イーサリアムクライアントの操作 {#working-with-ethereum-clients} -イーサリアムを使用して、仮想通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 Dartでイーサリアムの[JSON-RPC API](/developers/docs/apis/json-rpc/)を使用するための、現在維持されているライブラリが少なくとも2つあります。 +イーサリアムを使用して、仮想通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 +Dartでイーサリアムの[JSON-RPC API](/developers/docs/apis/json-rpc/)を使用するための、現在メンテナンスされているライブラリが少なくとも2つあります。 -1. [sionbutler.euのWeb3dart](https://pub.dev/packages/web3dart) -1. [darticulate.comのEthereum 5.0.0](https://pub.dev/packages/ethereum) +1. [pwa.irのWeb3dart](https://pub.dev/packages/web3dart) +2. [darticulate.comのEthereum 5.0.0](https://pub.dev/packages/ethereum) -特定のイーサリアムアドレスの操作やさまざまな仮想通貨の価格の取得を可能にする、追加のライブラリもあります。 完全なリストについては、[こちら](https://pub.dev/dart/packages?q=ethereum)をご覧ください。 +特定のイーサリアムアドレスの操作やさまざまな仮想通貨の価格の取得を可能にする、追加のライブラリもあります。 +[全リストはこちらで確認できます](https://pub.dev/dart/packages?q=ethereum)。 diff --git a/public/content/translations/ja/developers/docs/programming-languages/delphi/index.md b/public/content/translations/ja/developers/docs/programming-languages/delphi/index.md index ee52c24c378..bfa6c79ff09 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/delphi/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/delphi/index.md @@ -1,6 +1,6 @@ --- -title: Delphiデベロッパーのためのイーサリアム -description: Delphiプログラミング言語を使用してイーサリアムを開発する方法を学ぶ +title: "Delphiデベロッパーのためのイーサリアム" +description: "Delphiプログラミング言語を使用してイーサリアムを開発する方法を学ぶ" lang: ja incomplete: true --- @@ -11,46 +11,46 @@ Delphiプログラミング言語を使用してイーサリアムを開発す -イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を利用した分散型アプリケーション (Dapp) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 +イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 分散型アプリケーションをイーサリアム上に構築し、Delphiプログラミング言語を使用してスマートコントラクトとのやり取りを行えます。 -## スマートコントラクトとSolidityを使い始める {#getting-started-with-smart-contracts-and-the-solidity-language} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-the-solidity-language} -**Delphiをイーサリアムに統合するための最初のステップを踏み出してみましょう。** +**Delphiをイーサリアムに統合するための最初のステップを踏み出してみましょう** -先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご確認ください。 +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご覧ください。 -- [ブロックチェーンの説明](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) - [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [初めてのスマートコントラクトを記述する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Solidityのコンパイルとデプロイの方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -## 初級者向けの参考文献とリンク {#beginner-references-and-links} +## 初心者向けの参考資料とリンク {#beginner-references-and-links} **Delphereumライブラリの紹介** -- [Delphereumとは](https://github.com/svanas/delphereum/blob/master/README.md) -- [Delphiをローカル (メモリ内) ブロックチェーンに接続する](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) +- [Delphereumとは？](https://github.com/svanas/delphereum/blob/master/README.md) +- [Delphiをローカル(インメモリ)ブロックチェーンに接続する](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) - [Delphiをイーサリアムメインネットに接続する](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) - [Delphiをスマートコントラクトに接続する](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) -**セットアップをスキップして、そのままサンプルに進みますか？** +**セットアップはスキップして、すぐにサンプルに進みますか？** -- [3分でわかるスマートコントラクトとDelphi - Part 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) -- [3分でわかるスマートコントラクトとDelphi - Part 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) +- [3分でわかるスマートコントラクトとDelphi - パート1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) +- [3分でわかるスマートコントラクトとDelphi - パート2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) ## 中級者向けの記事 {#intermediate-articles} -- [Delphiでイーサリアム署名されたメッセージ署名を生成する](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) -- [Delphiを使用してEtherを送金する](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) -- [Delphiを使用してERC-20トークンを送金する](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) +- [Delphiでイーサリアム署名済みメッセージの署名を生成する](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) +- [DelphiでEtherを送金する](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) +- [DelphiでERC-20トークンを送金する](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) ## 高度な使用パターン {#advanced-use-patterns} -- [Delphiとイーサリアム名サービス (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) +- [Delphiとイーサリアム名サービス(ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) - [QuikNode、イーサリアム、Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) -- [Delphiとイーサリアムの暗い森](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) +- [Delphiとイーサリアムのダークフォレスト](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) - [Delphiでトークンを別のトークンにスワップする](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) -もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご確認ください。 +もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご覧ください。 diff --git a/public/content/translations/ja/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/ja/developers/docs/programming-languages/dot-net/index.md index c7f6a83ceaf..08875f7be29 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/dot-net/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/dot-net/index.md @@ -1,86 +1,86 @@ --- -title: .NETデベロッパーのためのイーサリアム -description: .NETベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +title: ".NETデベロッパーのためのイーサリアム" +description: ".NETベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ" lang: ja incomplete: true --- -.NETベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +.NETベースのプロジェクトとツールを使用してイーサリアムを開発する方法を学びましょう -イーサリアムを使用して、仮想通貨とブロックチェーン技術のメリットを活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 +イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 Microsoftのテクノロジースタックのツールと言語を使用して、イーサリアム上に分散型アプリケーションを構築し、スマートコントラクトとやり取りできます。.NET Framework/.NET Core/.NET Standardにまたがり、VSCodeとVisual Studioなどのツールにより、C#、# Visual Basic、.NET、F#をサポートしています。 Microsoft Azure Blockchainを使用して、Azure上にイーサリアムブロックチェーンを数分でデプロイできます。 イーサリアムに.NETの愛を届けよう！ -## スマートコントラクトとSolidity言語を使い始める {#getting-started-with-smart-contracts-and-the-solidity-language} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-the-solidity-language} -**.NETをイーサリアムに統合するための最初のステップを踏み出してみましょう。** +**.NETをイーサリアムに統合するための最初のステップを踏み出してみましょう** -先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご確認ください。 +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご覧ください。 -- [ブロックチェーンの説明](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) - [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [初めてのスマートコントラクトを記述する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Solidityのコンパイルとデプロイの方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -## 初級者向けの参照文献とリンク {#beginner-references-and-links} +## 初心者向けの参考資料とリンク {#beginner-references-and-links} **NethereumライブラリとVS Code Solidityの紹介** -- [Nethereum入門](https://docs.nethereum.com/en/latest/getting-started/) +- [Nethereum、入門](https://docs.nethereum.com/en/latest/getting-started/) - [VS Code Solidityのインストール](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) -- [イーサリアムスマートコントラクトを作成して呼び出すための.NETデベロッパーのワークフロー](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) -- [Nethereumとのスマートコントラクトの統合](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) -- [.NETおよびイーサリアムブロックチェーンのスマートコントラクトとNethereumとの間のインターフェース](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933) ([中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)も参照) -- [Nethereum - ブロックチェーン用のオープンソース.NET統合ライブラリ](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) -- [Nethereumを使用したSQLデータベースへのイーサリアムトランザクションの記述](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) -- [C#とVisual Studioを使用してイーサリアムスマートコントラクトを簡単にデプロイする方法](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) - -**セットアップをスキップして、そのままサンプルに進みますか？** - -- [Playground](http://playground.nethereum.com/) - ブラウザを介してイーサリアムとやり取りし、Nethereumの使用方法を学ぶ - - アカウント残高のクエリ [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) - - ERC20スマートコントラクトの残高のクエリ [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) +- [.NET開発者によるイーサリアムのスマートコントラクトの作成と呼び出しのワークフロー](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) +- [Nethereumとのスマートコントラクト統合](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) +- [Nethereumを使用した.NETとイーサリアムブロックチェーンスマートコントラクトの連携](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933)、[中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)もあります +- [Nethereum - ブロックチェーン向けのオープンソース.NET統合ライブラリ](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) +- [Nethereumを使用してイーサリアムのトランザクションをSQLデータベースに書き込む](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) +- [C#とVisualStudioを使用してイーサリアムのスマートコントラクトを簡単にデプロイする方法](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) + +**セットアップはスキップして、すぐにサンプルに進みますか？** + +- [Playground](http://playground.nethereum.com/) - ブラウザを介してイーサリアムとやり取りし、Nethereumの使用方法を学びます。 + - アカウント残高の照会 [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) + - ERC20スマートコントラクトの残高照会 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) - アカウントへのEtherの送金 [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003) - ... などなど！ ## 中級者向けの記事 {#intermediate-articles} -- [Nethereumのワークブックとサンプルリスト](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) -- [独自の開発テストチェーンをデプロイする](https://github.com/Nethereum/Testchains) -- [SolidityのためのVS Codeコード生成プラグイン](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) -- [Unityとイーサリアム: なぜ、そして、どうやって？](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) -- [イーサリアムdapp用のASP.NET Core Web APIの作成](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) -- [Nethereum Web3を使用したサプライチェーントラッキングシステムの実装](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) -- [Nethereumのブロック処理](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/)と[C# Playgroundでのサンプル](http://playground.nethereum.com/csharp/id/1025) -- [NethereumのWebsocketストリーミング](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) +- [Nethereum ワークブック/サンプルリスト](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) +- [独自の開発テストチェーンをデプロイ](https://github.com/Nethereum/Testchains) +- [Solidity向けVSCode Codegenプラグイン](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) +- [Unityとイーサリアム: なぜ、どのように](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) +- [イーサリアムdapps向けのASP.NET Core Web APIを作成する](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) +- [Nethereum Web3を使用したサプライチェーン追跡システムの実装](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) +- [Nethereumブロック処理](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/)、[C# Playgroundサンプル](http://playground.nethereum.com/csharp/id/1025)付き +- [Nethereum Websocket ストリーミング](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) - [KaleidoとNethereum](https://kaleido.io/kaleido-and-nethereum/) - [QuorumとNethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) -## 高度なユースケース {#advanced-use-patterns} +## 高度な使用パターン {#advanced-use-patterns} - [Azure Key VaultとNethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) - [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid) -- [Ujo Nethereumのバックエンドリファレンスアーキテクチャ](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) +- [Ujo Nethereumバックエンドリファレンスアーキテクチャ](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) -## .NETプロジェクト、ツール、その他 {#dot-net-projects-tools-and-other-fun-stuff} +## .NETプロジェクト、ツール、その他の楽しいもの {#dot-net-projects-tools-and-other-fun-stuff} -- [Nethereum Playground](http://playground.nethereum.com/) - _ブラウザでのNethereumコードスニペットのコンパイル、作成、実行_ -- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _BlazorのUIを使用したNethereumのコード生成_ -- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _.NET WasmのSPAライトブロックチェーンエクスプローラーとシンプルなウォレット_ -- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _本質的にメタデータ駆動型の (.NETプラットフォームとイーサリアムプラットフォームの両方のための) ビジネスルールエンジン。_ -- [Nethermind](https://github.com/NethermindEth/nethermind) - _Linux、Windows、MacOS用の.NET Coreイーサリアムクライアント_ +- [Nethereum Playground](http://playground.nethereum.com/) - _ブラウザでNethereumコードスニペットをコンパイル、作成、実行_ +- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _BlazorのUIを備えたNethereum codegen_ +- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _.NET Wasm SPAライトブロックチェーンエクスプローラーとシンプルなウォレット_ +- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _本質的にメタデータ駆動型のビジネスルールエンジン(.NETプラットフォームとイーサリアムプラットフォームの両方に対応)_ +- [Nethermind](https://github.com/NethermindEth/nethermind) - _Linux、Windows、MacOS向けの.NET Core イーサリアムクライアント_ - [eth-utils](https://github.com/ethereum/eth-utils/) - _イーサリアム関連のコードベースを操作するためのユーティリティ関数_ -- [TestChains](https://github.com/Nethereum/TestChains) - _高速応答のための事前設定済みの.NET開発チェーン (PoA)_ +- [TestChains](https://github.com/Nethereum/TestChains) - _高速応答のための事前設定済み.NET開発チェーン(PoA)_ -もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご確認ください。 +もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご覧ください。 -## .NETコミュニティコントリビューター {#dot-net-community-contributors} +## .NETコミュニティのコントリビューター {#dot-net-community-contributors} -Nethereumでは、主に[Gitter](https://gitter.im/Nethereum/Nethereum)を活用しています。ここでは誰でも、質問、質問への回答、支援要請などを行えます。単なる雑談も歓迎です。 [NethereumのGithubリポジトリ](https://github.com/Nethereum)では、リクエストのプルや問題のオープンが可能です。参加者のサイドプロジェクトやサンプルプロジェクトを閲覧することもできます。 また、その他に[Discord](https://discord.gg/jQPrR58FxX)もご利用いただけます。 +Nethereumでは、主に[Gitter](https://gitter.im/Nethereum/Nethereum)で活動しています。誰でも質問や回答、ヘルプの入手、あるいはただ雑談することも歓迎です。 [Nethereum GitHubリポジトリ](https://github.com/Nethereum)で、PRの作成やissueのオープンを気軽に行ってください。また、たくさんあるサイド/サンプルプロジェクトを閲覧するだけでも構いません。 [Discord](https://discord.gg/jQPrR58FxX)でも活動しています！ -Nethermindを初めて利用する際に支援が必要な場合は、[Discord](http://discord.gg/PaCMRFdvWT)にご参加ください。 デベロッパーが常駐しており、ご質問に回答します。 また、[Nethermind GitHub リポジトリ](https://github.com/NethermindEth/nethermind)でのリクエストのプルや問題のオープンも、いつでも行えます。 +Nethermindが初めてで、使い始めるのにヘルプが必要な場合は、私たちの[Discord](http://discord.gg/PaCMRFdvWT)に参加してください。 デベロッパーが常駐しており、ご質問に回答します。 [Nethermind GitHubリポジトリ](https://github.com/NethermindEth/nethermind)でPRを作成したり、issueを提起したりすることも、ご自由にどうぞ。 -## その他のリスト {#other-aggregated-lists} +## その他の集約リスト {#other-aggregated-lists} -[Nethereumの公式サイト](https://nethereum.com/) -[Nethermindの公式サイト](https://nethermind.io/) +[Nethereum公式サイト](https://nethereum.com/) +[Nethermind公式サイト](https://nethermind.io/) diff --git a/public/content/translations/ja/developers/docs/programming-languages/elixir/index.md b/public/content/translations/ja/developers/docs/programming-languages/elixir/index.md new file mode 100644 index 00000000000..85b40e47f7d --- /dev/null +++ b/public/content/translations/ja/developers/docs/programming-languages/elixir/index.md @@ -0,0 +1,55 @@ +--- +title: "Elixir開発者のためのイーサリアム" +description: "Elixirベースのプロジェクトとツールを使用して、イーサリアムの開発方法を学びましょう。" +lang: ja +incomplete: false +--- + +Elixirベースのプロジェクトとツールを使用して、イーサリアムの開発方法を学びましょう。 + +イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 + +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-solidity} + +**Elixirをイーサリアムに統合するための最初のステップを踏み出しましょう** + +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご覧ください。 + +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## 初心者向けの記事 {#beginner-articles} + +- [イーサリアムアカウントを完全に理解する](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Ethers — Elixir用の一流のイーサリアムWeb3ライブラリ](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) + +## 中級者向けの記事 {#intermediate-articles} + +- [Elixirで未加工のイーサリアムコントラクトトランザクションに署名する方法](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) +- [イーサリアムのスマートコントラクトとElixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) + +## Elixirのプロジェクトとツール {#elixir-projects-and-tools} + +### アクティブ {#active} + +- [block_keys](https://github.com/ExWeb3/block_keys) - _ElixirでのBIP32 & BIP44の実装 (決定性ウォレットのマルチアカウント階層)_ +- [ethereumex](https://github.com/mana-ethereum/ethereumex) - _イーサリアムブロックチェーンのためのElixir JSON-RPCクライアント_ +- [ethers](https://github.com/ExWeb3/elixir_ethers) - _Elixirを使用してイーサリアム上のスマートコントラクトと対話するための包括的なWeb3ライブラリ_ +- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) - _Ethers用のKMS署名ライブラリ (AWS KMSでトランザクションに署名)_ +- [ex_abi](https://github.com/poanetwork/ex_abi) - _ElixirでのイーサリアムABIパーサー/デコーダー/エンコーダー実装_ +- [ex_keccak](https://github.com/ExWeb3/ex_keccak) - _NIFで構築されたtiny-keccak Rustクレートを使用してKeccak SHA3-256ハッシュを計算するためのElixirライブラリ_ +- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) - _イーサリアムのRLP (再帰的長さプレフィックス) エンコーディングのElixir実装_ + +### アーカイブ済み / メンテナンス終了 {#archived--no-longer-maintained} + +- [eth](https://hex.pm/packages/eth) - _Elixir用のイーサリアムユーティリティ_ +- [exw3](https://github.com/hswick/exw3) - _Elixir用の高レベルなイーサリアムRPCクライアント_ +- [mana](https://github.com/mana-ethereum/mana) - _Elixirで記述されたイーサリアムのフルノード実装_ + +もっとリソースをお探しですか？ [デベロッパーホーム](/developers/)をご覧ください。 + +## Elixirコミュニティのコントリビューター {#elixir-community-contributors} + +[ElixirのSlack #ethereumチャンネル](https://elixir-lang.slack.com/archives/C5RPZ3RJL)は、急速に成長しているコミュニティのホストであり、上記のプロジェクトや関連トピックに関する議論のための専用リソースです。 diff --git a/public/content/translations/ja/developers/docs/programming-languages/golang/index.md b/public/content/translations/ja/developers/docs/programming-languages/golang/index.md index 70cdf4ec1dc..a5c49fe638a 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/golang/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/golang/index.md @@ -1,84 +1,84 @@ --- -title: Goデベロッパーのためのイーサリアム -description: Goベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +title: "Goデベロッパーのためのイーサリアム" +description: "Goベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ" lang: ja incomplete: true --- -Goベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +Goベースのプロジェクトとツールを使用してイーサリアムを開発する方法を学ぶ イーサリアムを使用して分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 分散型であるため、ピアツーピアのネットワーク上で動作します。単一障害点はありません。 単一のエンティティや個人によって制御されず、検閲はほぼ不可能です。 デジタル資産を制御して、新たなタイプのアプリケーションを作成できます。 -## スマートコントラクトとSolidityを使い始める {#getting-started-with-smart-contracts-and-solidity} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-solidity} -**Goをイーサリアムに統合するための最初のステップを踏み出してみましょう。** +**Goをイーサリアムに統合するための最初のステップを踏み出してみましょう** -先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご確認ください。 +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご覧ください。 -- [ブロックチェーンの説明](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) - [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [初めてのスマートコントラクトを記述する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Solidityのコンパイルとデプロイの方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -- [コントラクトのチュートリアル](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [コントラクトチュートリアル](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) ## 初心者向けの記事と書籍 {#beginner-articles-and-books} - [Geth入門](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) -- [Golangを使用してイーサリアムに接続する](https://www.youtube.com/watch?v=-7uChuO_VzM) -- [Golangを使用してイーサリアムスマートコントラクトをデプロイする](https://www.youtube.com/watch?v=pytGqQmDslE) -- [Goでのイーサリアムスマートコントラクトのテストとデプロイのための段階的ガイド](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) -- [eBook: Goを使用したイーサリアム開発](https://goethereumbook.org/) - _Goを使用してイーサリアムアプリケーションを開発する_ +- [Golangを使ってイーサリアムに接続する](https://www.youtube.com/watch?v=-7uChuO_VzM) +- [Golangを使用してイーサリアムのスマートコントラクトをデプロイする](https://www.youtube.com/watch?v=pytGqQmDslE) +- [Goでイーサリアムのスマートコントラクトをテストおよびデプロイするためのステップバイステップガイド](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) +- [eBook: Goによるイーサリアム開発](https://goethereumbook.org/) - _Goでイーサリアムアプリケーションを開発_ ## 中級者向けの記事とドキュメント {#intermediate-articles-and-docs} -- [Goイーサリアムのドキュメント](https://geth.ethereum.org/docs/) - _公式のイーサリアムのGolangについてのドキュメント_ -- [Erigonのプログラマーガイド](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _状態ツリー、マルチプルーフ、トランザクション処理などについて図示したガイド_ -- [Erigonとステートレスイーサリアム](https://youtu.be/3-Mn7OckSus?t=394) - _2020年イーサリアムコミュニティカンファレンス (EthCC 3)_ -- [Erigon：イーサリアムクライアントの最適化](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018年開発者会議4_ -- [Goイーサリアム GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) -- [GoでGethを使用してdappを作成する](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) -- [GolangとGethを使用してイーサリアムプライベートネットワークで作業する](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) -- [Goを使用してイーサリアム上でSolidityコントラクトの単体テストを行う](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) +- [Go Ethereumドキュメント](https://geth.ethereum.org/docs/) - _公式イーサリアムGolangのドキュメント_ +- [Erigonプログラマーガイド](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _ステートツリー、マルチプルーフ、トランザクション処理を含む図解ガイド_ +- [Erigonとステートレスイーサリアム](https://youtu.be/3-Mn7OckSus?t=394) - _2020 イーサリアム・コミュニティ・カンファレンス (EthCC 3)_ +- [Erigon: イーサリアムクライアントの最適化](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_ +- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) +- [GethとGoでdappを作成する](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) +- [GolangとGethでイーサリアムのプライベートネットワークを扱う](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) +- [Goでイーサリアム上のSolidityコントラクトを単体テストする](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) - [Gethをライブラリとして使用するためのクイックリファレンス](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) -## 発展的なユースケース {#advanced-use-patterns} +## 高度な使用パターン {#advanced-use-patterns} -- [Gethのシミュレートされたバックエンド](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) -- [イーサリアムとQuorumを使用したアズ・ア・サービス型のブロックチェーンアプリケーション](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) -- [イーサリアムブロックチェーンアプリケーションにおける分散型ストレージIPFSとSwarm](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) -- [モバイルクライアント: ライブラリとInProcのイーサリアムノード](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) -- [ネイティブdapp: イーサリアムコントラクトへのGoバインディング](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) +- [GETHシミュレーテッドバックエンド](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) +- [イーサリアムとQuorumを使用したBlockchain-as-a-Serviceアプリ](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) +- [イーサリアムブロックチェーンアプリケーションにおける分散ストレージIPFSとSwarm](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) +- [モバイルクライアント: ライブラリとインプロセスイーサリアムノード](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) +- [ネイティブdapps: イーサリアムコントラクトへのGoバインディング](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) ## Goのプロジェクトとツール {#go-projects-and-tools} -- [Geth / Goイーサリアム](https://github.com/ethereum/go-ethereum) - _イーサリアムプロトコルの公式Go実装_ -- [Goイーサリアム コード分析](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go Ethereumのソースコードのレビューと分析_ -- [Erigon](https://github.com/ledgerwatch/erigon) - _Goイーサリアムの派生。アーカイブノードにフォーカスしており、より高速_ -- [Golem](https://github.com/golemfactory/golem) - _Golemはコンピューティングパワーのグローバル市場を創造している_ -- [Quorum](https://github.com/jpmorganchase/quorum) - _データプライバシーをサポートするイーサリアムの許可された実装_ +- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _イーサリアムプロトコルの公式Go実装_ +- [Go Ethereum コード分析](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go Ethereumソースコードのレビューと分析_ +- [Erigon](https://github.com/ledgerwatch/erigon) - _アーカイブノードに重点を置いた、Go Ethereumの高速な派生版_ +- [Golem](https://github.com/golemfactory/golem) - _Golemはコンピューティングパワーのグローバル市場を創造しています_ +- [Quorum](https://github.com/jpmorganchase/quorum) - _データプライバシーをサポートするイーサリアムの許可制実装_ - [Prysm](https://github.com/prysmaticlabs/prysm) - _イーサリアム「Serenity」2.0のGo実装_ -- [Eth Tweet](https://github.com/yep/eth-tweet) - _分散型Twitter: イーサリアムブロックチェーン上で稼動するマイクロブログサービス_ -- [Plasma MVP Golang](https://github.com/kyokan/plasma) - _Minimum Viable Plasma仕様のGolangの実装と拡張_ +- [Eth Tweet](https://github.com/yep/eth-tweet) - _分散型Twitter: イーサリアムブロックチェーン上で稼働するマイクロブログサービス_ +- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Minimum Viable Plasma仕様のGolang実装および拡張_ - [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _オープンソースのイーサリアムマイニングプール_ -- [Ethereum HD Wallet](https://github.com/miguelmota/go-ethereum-hdwallet) - _GoイーサリアムHDウォレットの派生_ +- [イーサリアムHDウォレット](https://github.com/miguelmota/go-ethereum-hdwallet) - _GoによるイーサリアムHDウォレットの派生_ - [Multi Geth](https://github.com/multi-geth/multi-geth) - _多くの種類のイーサリアムネットワークをサポート_ -- [Gethライトクライアント](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _ライトイーサリアムサブプロトコルのGeth実装_ +- [Gethライトクライアント](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Light Ethereum SubprotocolのGeth実装_ - [イーサリアムGolang SDK](https://github.com/everFinance/goether) - _Golangでのシンプルなイーサリアムウォレットの実装とユーティリティ_ -- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _Go SDKを通して200以上のブロックチェーンでブロックチェーンデータへ効率的にアクセス_ +- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _200以上のブロックチェーンに対応したGo SDKで、ブロックチェーンデータに効率的にアクセス_ -もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご確認ください。 +もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をチェックしてください -## Goコミュニティコントリビューター {#go-community-contributors} +## Goコミュニティのコントリビューター {#go-community-contributors} - [Geth Discord](https://discordapp.com/invite/nthXNEv) - [Geth Gist](https://gitter.im/ethereum/go-ethereum) -- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#ethereum channel](https://gophers.slack.com/messages/C9HP1S9V2) +- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#ethereumチャンネル](https://gophers.slack.com/messages/C9HP1S9V2) - [StackExchange - Ethereum](https://ethereum.stackexchange.com/) - [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth) -- [イーサリアムGitter](https://gitter.im/ethereum/home) +- [Ethereum Gitter](https://gitter.im/ethereum/home) - [GethライトクライアントGitter](https://gitter.im/ethereum/light-client) -## その他のリスト {#other-aggregated-lists} +## その他の集約リスト {#other-aggregated-lists} -- [素晴らしいイーサリアム](https://github.com/btomashvili/awesome-ethereum) -- [Consensys: イーサリアムデベロッパーツールの決定版リスト](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHubソース](https://github.com/ConsenSys/ethereum-developer-tools-list) +- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum) +- [Consensys: イーサリアム開発者ツールの完全版リスト](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-215974) | [GitHubソース](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git a/public/content/translations/ja/developers/docs/programming-languages/index.md b/public/content/translations/ja/developers/docs/programming-languages/index.md index a47e1d28c6e..eedf13f87eb 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/index.md @@ -1,10 +1,11 @@ --- -title: プログラミング言語 -description: +title: "プログラミング言語" +description: "JavaScript、Python、Go、Rustなど、さまざまなプログラミング言語のイーサリアム開発リソースを発見する。" lang: ja --- -よくある誤解は、イーサリアム上で構築を行うためには、デベロッパーが[スマートコントラクト](/developers/docs/smart-contracts/)を記述しなくてはならないというものです。 これは間違いです。 イーサリアムのネットワークとコミュニティの素晴らしさの一つは、ほぼどんなプログラミング言語であっても[参加](/community/)できることにあります。 +イーサリアム上で構築を行うためには、デベロッパーが[スマートコントラクト](/developers/docs/smart-contracts/)を記述しなければならないというのは、よくある誤解です。 これは間違いです。 +イーサリアムのネットワークとコミュニティの素晴らしさの一つは、ほぼどんなプログラミング言語であっても[参加](/community/)できることにあります。 イーサリアムとそのコミュニティは、オープンソースを採用しています。 クライアントの実装、API、開発フレームワーク、テストツールなどのコミュニティプロジェクトは、さまざまな言語で記述されています。 @@ -15,6 +16,7 @@ lang: ja - [Dartデベロッパーのためのイーサリアム](/developers/docs/programming-languages/dart/) - [Delphiデベロッパーのためのイーサリアム](/developers/docs/programming-languages/delphi/) - [.NETデベロッパーのためのイーサリアム](/developers/docs/programming-languages/dot-net/) +- [Elixirデベロッパーのためのイーサリアム](/developers/docs/programming-languages/elixir/) - [Goデベロッパーのためのイーサリアム](/developers/docs/programming-languages/golang/) - [Javaデベロッパーのためのイーサリアム](/developers/docs/programming-languages/java/) - [JavaScriptデベロッパーのためのイーサリアム](/developers/docs/programming-languages/javascript/) @@ -24,6 +26,7 @@ lang: ja ### 使いたい言語がサポートされていなかった場合 {#other-lang} -上記以外のプログラミング言語について、リソースや仮想コミュニティへのリンクを追加したい場合は、[問題をオープンする](https://github.com/ethereum/ethereum-org-website/issues/new/choose)ことによって、新しいページをリクエストできます。 +追加のプログラミング言語のリソースやバーチャルコミュニティへのリンクをご希望の場合は、[issueをオープンする](https://github.com/ethereum/ethereum-org-website/issues/new/choose)ことで、新しいページをリクエストできます。 -現在サポートされていない言語でブロックチェーンのインタフェースのコードを記述したい場合は、[JSON-RPCインターフェース](/developers/docs/apis/json-rpc/)を使用してイーサリアムネットワークに接続できます。 このインターフェースは、TCP/IPを使用できるすべての言語で利用可能です。 +現在サポートされていない言語でブロックチェーンのインタフェースのコードを記述したい場合は、 +[JSON-RPCインターフェース](/developers/docs/apis/json-rpc/)を使用してイーサリアムネットワークに接続できます。 このインターフェースは、TCP/IPを使用できるすべての言語で利用可能です。 diff --git a/public/content/translations/ja/developers/docs/programming-languages/java/index.md b/public/content/translations/ja/developers/docs/programming-languages/java/index.md index 1fa482144f4..81f5e557094 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/java/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/java/index.md @@ -1,63 +1,64 @@ --- -title: Javaデベロッパーのためのイーサリアム -description: Javaベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +title: "Javaデベロッパーのためのイーサリアム" +description: "Javaベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ" lang: ja incomplete: true --- -Javaベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +Javaベースのプロジェクトとツールを使ってイーサリアムを開発する方法を学ぶ -イーサリアムを使用して、仮想通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 +イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 -## スマートコントラクトとSolidityを使い始める {#getting-started-with-smart-contracts-and-solidity} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-solidity} -**Javaをイーサリアムに統合するための最初のステップを踏み出してみましょう。** +**Javaをイーサリアムに統合するための最初のステップを踏み出してみましょう** -先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご確認ください。 +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers.](/developers/)をご確認ください。 -- [ブロックチェーンの説明](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) - [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [初めてのスマートコントラクトを記述する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Solidityのコンパイルとデプロイの方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) ## イーサリアムクライアントの操作 {#working-with-ethereum-clients} -2つの主要なJavaイーサリアムクライアントである[Web3j](https://github.com/web3j/web3j)とハイパーレジャーBesuの使用方法を学ぶ +2つの主要なJavaイーサリアムクライアントである[Web3J](https://github.com/web3j/web3j)とHyperledger Besuの使用方法を学びましょう -- [Java、Eclipse、Web3jを使用してイーサリアムクライアントに接続する](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) -- [JavaとWeb3jを使用してイーサリアムアカウントを管理する](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) -- [スマートコントラクトからJava Wrapperを生成する](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) -- [イーサリアムスマートコントラクトとやり取りする](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) -- [イーサリアムスマートコントラクトのイベントをリッスンする](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) -- [LinuxでJavaイーサリアムクライアントであるBesu (Pantheon) を使用する](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) -- [Java統合テストでハイパーレジャーBesu (Pantheon) ノードを実行する](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) -- [Web3jのチートシート](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c) +- [Java、Eclipse、Web3Jでイーサリアムクライアントに接続する](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) +- [JavaとWeb3jでイーサリアムアカウントを管理する](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) +- [スマートコントラクトからJavaラッパーを生成する](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) +- [イーサリアムのスマートコントラクトを操作する](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) +- [イーサリアムのスマートコントラクトイベントをリッスンする](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) +- [LinuxでJavaイーサリアムクライアントのBesu (Pantheon) を使用する](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) +- [Java統合テストでHyperledger Besu (Pantheon)ノードを実行する](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) +- [Web3j チートシート](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c) -EVMベースのブロックチェーンとやり取りするための非同期でハイパフォーマンスのKotlinライブラリである[ethers-kt](https://github.com/Kr1ptal/ethers-kt)の使用方法を学ぶ。 JVMおよびAndroidプラットフォームをターゲットにしています。 -- [ERC20トークンの送信](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) -- [イベントをリッスンしつつUniswapV2でスワップする](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) +EVMベースのブロックチェーンと対話するための非同期で高性能なKotlinライブラリ、[ethers-kt](https://github.com/Kr1ptal/ethers-kt)の使用方法を学びましょう。 JVMおよびAndroidプラットフォームをターゲットにしています。 + +- [ERC20トークンを転送する](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) +- [イベントリッスンを伴うUniswapV2スワップ](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) - [ETH / ERC20残高トラッカー](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) ## 中級者向けの記事 {#intermediate-articles} -- [IPFSを使用してJavaアプリケーションのストレージを管理する](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) +- [IPFSを使用したJavaアプリケーションにおけるストレージ管理](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) - [Web3jを使用してJavaでERC20トークンを管理する](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) - [Web3jトランザクションマネージャー](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) -## 発展的なユースケース {#advanced-use-patterns} +## 高度な使用パターン {#advanced-use-patterns} -- [Eventeumを使用してJavaスマートコントラクトのデータキャッシュを構築する](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) +- [Eventeumを使用してJavaスマートコントラクトデータキャッシュを構築する](https://kauri.io/article/fe81ee9612eb45a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) -## Javaのプロジェクトとツール {#java-projects-and-tools} +## Javaプロジェクトとツール {#java-projects-and-tools} -- [Web3j (イーサリアムクライアントとやり取りするためのライブラリ)](https://github.com/web3j/web3j) -- [ethers-kt (EVMベースのブロックチェーン用の非同期、ハイパフォーマンスのKotlin/Java/Androidライブラリ)](https://github.com/Kr1ptal/ethers-kt) +- [Web3J (イーサリアムクライアントと対話するためのライブラリ)](https://github.com/web3j/web3j) +- [ethers-kt (EVMベースのブロックチェーン用の非同期、高性能なKotlin/Java/Androidライブラリ。)](https://github.com/Kr1ptal/ethers-kt) - [Eventeum (イベントリスナー)](https://github.com/ConsenSys/eventeum) -- [Mahuta (IPFSデベロッパーツール)](https://github.com/ConsenSys/mahuta) +- [Mahuta (IPFS開発ツール)](https://github.com/ConsenSys/mahuta) -もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご確認ください。 +もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をチェックしてください。 -## Javaコミュニティコントリビューター {#java-community-contributors} +## Javaコミュニティのコントリビューター {#java-community-contributors} - [IO Builders](https://io.builders) - [Kauri](https://kauri.io) diff --git a/public/content/translations/ja/developers/docs/programming-languages/javascript/index.md b/public/content/translations/ja/developers/docs/programming-languages/javascript/index.md index aa87150bfae..86765b616fb 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/javascript/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/javascript/index.md @@ -1,42 +1,43 @@ --- -title: JavaScriptデベロッパーのためのイーサリアム -description: JavaScriptベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +title: "JavaScriptデベロッパーのためのイーサリアム" +description: "JavaScriptベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ" lang: ja --- -JavaScriptはイーサリアムのエコシステムで最も人気のある言語の1つです。 実際、できるだけ多くのイーサリアムの機能をJavaScriptで実装することに注力している専門[チーム](https://github.com/ethereumjs)も存在しています。 +JavaScriptはイーサリアムのエコシステムで最も人気のある言語の1つです。 実際、できるだけ多くのイーサリアムの機能をJavaScriptで実装することに注力している[チーム](https://github.com/ethereumjs)も存在しています。 -[スタックのすべてのレベル](/developers/docs/ethereum-stack/)で、JavaScript (または近似の言語) で記述できる機会があります。 +[スタックのすべてのレベル](/developers/docs/ethereum-stack/)で、JavaScript (またはそれに近いもの) を記述する機会があります。 -## イーサリアムとのやりとり {#interact-with-ethereum} +## イーサリアムとの対話 {#interact-with-ethereum} ### JavaScript APIライブラリ {#javascript-api-libraries} -JavaScriptでブロックチェーンへのクエリやトランザクションの送信などを行うための最も便利な方法は、[JavaScript APIライブラリ](/developers/docs/apis/javascript/)を使用することです。 このライブラリのAPIを使用すると、デベロッパーは[イーサリアムネットワークのノード](/developers/docs/nodes-and-clients/)と簡単にやり取りできます。 +ブロックチェーンへのクエリ、トランザクションの送信などをJavaScriptで記述したい場合、最も便利な方法は[JavaScript APIライブラリ](/developers/docs/apis/javascript/)を使用することです。 これらのAPIを使用すると、デベロッパーは[イーサリアムネットワークのノード](/developers/docs/nodes-and-clients/)と簡単にやり取りできます。 このライブラリにより、イーサリアム上のスマートコントラクトとやり取りできるようになります。そのため、JavaScriptのみで既存のコントラクトとやり取りできるdappを構築することが可能になります。 -**以下をご参照ください。** +**チェック** -- [Web3.js](https://web3js.readthedocs.io/) -- [Ethers.js](https://docs.ethers.io/) - _JavaScriptとTypeScriptでの完全なイーサリアムウォレットの実装とユーティリティを含む_ -- [viem](https://viem.sh) – イーサリアム用のTypeScriptインターフェイスで、イーサリアムとやり取りする低レベルのステートレスプリミティブを提供します。 +- [Web3.js](https://web3js.readthedocs.io) +- [Ethers.js](https://ethers.org) – _JavaScriptとTypeScriptにおけるイーサリアムウォレットの実装とユーティリティを含みます。_ +- [viem](https://viem.sh) – _イーサリアムとやり取りするための低レベルのステートレスプリミティブを提供するイーサリアム用TypeScriptインターフェイス。_ +- [Drift](https://ryangoree.github.io/drift/) – _組み込みのキャッシュ、フック、テストモックを備え、複数のweb3ライブラリにわたるイーサリアム開発を容易にするTypeScriptメタライブラリ。_ ### スマートコントラクト {#smart-contracts} -独自のスマートコントラクトを作成したいと考えているJavaScriptデベロッパーは、[Solidity](https://solidity.readthedocs.io)について熟知することをお勧めします。 これは最も人気のあるスマートコントラクト言語であり、構文的にはJavaScriptに似ているため、比較的簡単に習得できる可能性があります。 +ご自身でスマートコントラクトを作成したいJavaScriptデベロッパーの方は、[Solidity](https://solidity.readthedocs.io)に慣れ親しんでおくとよいでしょう。 これは最も人気のあるスマートコントラクト言語であり、構文的にはJavaScriptに似ているため、比較的簡単に習得できる可能性があります。 -詳細については、[スマートコントラクト](/developers/docs/smart-contracts/)をご確認ください。 +[スマートコントラクト](/developers/docs/smart-contracts/)に関する詳細 -## プロトコルの理解 {#understand-the-protocol} +## プロトコルを理解する {#understand-the-protocol} ### イーサリアム仮想マシン {#the-ethereum-virtual-machine} -[イーサリアム仮想マシン](/developers/docs/evm/)のJavaScript実装を利用できます。 これは、最新のフォークルールをサポートしています。 フォークルールとは、計画されたアップグレードの結果としてEVMに加えられた変更のことです。 +[イーサリアム仮想マシン](/developers/docs/evm/)のJavaScript実装があります。 これは、最新のフォークルールをサポートしています。 フォークルールとは、計画されたアップグレードの結果としてEVMに加えられた変更のことです。 イーサリアム仮想マシンは、さまざまなJavaScriptパッケージに分かれています。これらのパッケージを調べることで、以下の項目について理解を深めることができます。 -- アカウント +- 口座 - ブロック - ブロックチェーン自体 - トランザクション @@ -46,28 +47,26 @@ JavaScriptでブロックチェーンへのクエリやトランザクション コードを読みたい場合は、イーサリアムドキュメントを通読するよりも、上記のJavaScriptのほうが役立ちます。 -**モノリポを調べる** -[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm) +**EVMをチェック** +[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) ### ノードとクライアント {#nodes-and-clients} Ethereumjsクライアントは活発に開発されており、JavaScriptで書かれたイーサリアムクライアントの仕組みを詳しく学ぶことができます。 -以前は、スタンドアロンの[`repository`](https://github.com/ethereumjs/ethereumjs-client)に格納されていましたが、後にパッケージとしてEthereumVMモノレポにマージされました。 +**クライアントをチェック** +[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) -**クライアントを調べる** -[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) - -## 他のプロジェクト {#other-projects} +## その他のプロジェクト {#other-projects} イーサリアムのJavaScript界隈では、その他にも、以下を含めた多くのプロジェクトが進められています。 - ウォレットユーティリティのライブラリ - イーサリアムのキーを生成、インポート、エクスポートするためのツール -- `merkle-patricia-tree`の実装 - イーサリアムの技術仕様書で概説されているデータ構造 +- `merkle-patricia-tree`の実装 – イーサリアムのイエローペーパーで概説されているデータ構造。 -[EthereumJSリポジトリ](https://github.com/ethereumjs)で、最も興味があるものについて詳細に調査してみてください。 +[EthereumJSリポジトリ](https://github.com/ethereumjs)で、最も興味があるものについて詳しく調べてみてください。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/programming-languages/python/index.md b/public/content/translations/ja/developers/docs/programming-languages/python/index.md index 1f015531774..25375f5a860 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/python/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/python/index.md @@ -1,90 +1,99 @@ --- -title: Pythonデベロッパーのためのイーサリアム -description: Pythonベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +title: "Pythonデベロッパーのためのイーサリアム" +description: "Pythonベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ" lang: ja incomplete: true --- Pythonベースのプロジェクトとツールを使用してイーサリアムを開発する方法を学ぶ -イーサリアムを使用して、仮想通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 +イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 -## スマートコントラクトとSolidityを使い始める {#getting-started-with-smart-contracts-and-solidity} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-solidity} -**Pythonをイーサリアムに統合するための最初のステップを踏み出してみましょう。** +**Pythonをイーサリアムに統合するための最初のステップを踏み出す** -先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご確認ください。 +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご覧ください。 -- [ブロックチェーンの説明](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) - [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [初めてのスマートコントラクトを記述する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Solidityのコンパイルとデプロイの方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [ブロックチェーンにおけるPythonの現状 2023年レポート](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) ## 初心者向けの記事 {#beginner-articles} -- [Pythonデベロッパー向けのイーサリアムガイド](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) -- [ブロックチェーン2023レポートにおけるPythonの状態](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) -- [Vyperを使ったスマートコントラクト入門](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) -- [PythonとBrownieを使用して独自のERC20トークンをデプロイする](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) -- [PythonのFlaskを使ってイーサリアムコントラクトを開発するには？](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) -- [Web3.py入門 - Python開発者のためのイーサリアム](https://www.dappuniversity.com/articles/web3-py-intro) -- [Pythonとweb3.pyを使ったスマートコントラクト関数の呼び出し方](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) +- [web3.pyの概要](https://web3py.readthedocs.io/en/latest/overview.html) +- [イーサリアムのPythonエコシステムツアー](https://snakecharmers.ethereum.org/python-ecosystem/) +- [イーサリアムに関する(Python)開発者向けガイド](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) +- [受賞を目指して: イーサリアム Pythonハッカソンガイド](https://snakecharmers.ethereum.org/prize-worthy/) +- [Vyperによるスマートコントラクト入門](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) +- [Python Flaskを使ったイーサリアムコントラクトの開発方法](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) +- [Web3.py入門 · Python開発者向けイーサリアム](https://www.dappuniversity.com/articles/web3-py-intro) +- [Pythonとweb3.pyを使ってスマートコントラクト関数を呼び出す方法](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) ## 中級者向けの記事 {#intermediate-articles} +- [web3.pyの仲間たち: Ape入門](https://snakecharmers.ethereum.org/intro-to-ape/) - [Pythonプログラマーのためのdapp開発](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) -- [Pythonのイーサリアムインターフェースを作成する: その1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) -- [Pythonでのイーサリアムスマートコントラクト: 包括的ガイド](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) -- [BrownieとPythonを使用してスマートコントラクトをデプロイする](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) -- [Brownieを使用してOpenSeaでNFTを作成する](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) +- [Pythonイーサリアムインターフェースの作成: パート1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) +- [Pythonによるイーサリアムスマートコントラクト: (ほぼ)完全ガイド](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) -## 発展的なユースケース {#advanced-use-patterns} +## 高度な使用パターン {#advanced-use-patterns} -- [Pythonを使用したイーサリアムスマートコントラクトのコンパイル、デプロイ、呼び出し](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) -- [Slitherを使用したSolidityスマートコントラクトの分析](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) -- [ブロックチェーンのフィンテックチュートリアル: Pythonを使用した貸出と借入](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) +- [web3.pyのパターン: リアルタイムイベントのサブスクリプション](https://snakecharmers.ethereum.org/subscriptions/) +- [web3.pyのパターン: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/) +- [Pythonを使ったイーサリアムスマートコントラクトのコンパイル、デプロイ、呼び出し](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) +- [SlitherでSolidityスマートコントラクトを分析する](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) +- [ブロックチェーンFintechチュートリアル: Pythonによる貸し借り](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) + +## アーカイブされた記事 + +- [PythonとBrownieで独自のERC20トークンをデプロイする](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) +- [BrownieとPythonを使ったスマートコントラクトのデプロイ](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) +- [Brownieを使ってOpenSeaでNFTを作成する](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) ## Pythonのプロジェクトとツール {#python-projects-and-tools} -### 現在でもメンテナンスされているもの {#active} +### アクティブ: {#active} -- [Web3.py](https://github.com/ethereum/web3.py) - _イーサリアムとやり取りするためのPythonライブラリ_ -- [Vyper](https://github.com/ethereum/vyper/) - _EVMのためのPythonライクなスマートコントラクト言語_ -- [Ape](https://github.com/ApeWorX/ape) - _パイソニスタ、データサイエンティスト、セキュリティプロフェッショナル向けのスマートコントラクト開発ツール_ +- [Web3.py](https://github.com/ethereum/web3.py) - _イーサリアムとやりとりするためのPythonライブラリ_ +- [Vyper](https://github.com/ethereum/vyper/) - _EVM向けのPythonicなスマートコントラクト言語_ +- [Ape](https://github.com/ApeWorX/ape) - _Pythonista、データサイエンティスト、セキュリティ専門家向けのスマートコントラクト開発ツール_ - [py-evm](https://github.com/ethereum/py-evm) - _イーサリアム仮想マシンの実装_ - [eth-tester](https://github.com/ethereum/eth-tester) - _イーサリアムベースのアプリケーションをテストするためのツール_ - [eth-utils](https://github.com/ethereum/eth-utils/) - _イーサリアム関連のコードベースを操作するためのユーティリティ関数_ -- [py-solc-x](https://pypi.org/project/py-solc-x/) - _solc SolidityコンパイラのPythonラッパー (Solidity 0.5xをサポート)_ -- [pymaker](https://github.com/makerdao/pymaker) - _MakerコントラクトのためのPython API_ -- [siwe](https://github.com/signinwithethereum/siwe-py) - _Pythonのためのイーサリアムによるサインイン (siwe)_ -- [イーサリアムの統合のためのWeb3 DeFi](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _ERC-20、Uniswap、その他の一般的なプロジェクトのための、すぐに統合を行えるPythonパッケージ_ -- [Wake -](https://getwake.io) _コントラクトのテスト、ファジング、デプロイ、脆弱性スキャン、コードナビゲーションが可能なオールインワンPythonフレームワーク(言語サーバー - [Tools for Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ - -### アーカイブ済み・メンテナンスされていないもの {#archived--no-longer-maintained} - -- [Trinity](https://github.com/ethereum/trinity) - _イーサリアムPythonクライアント_ -- [Mamba](https://github.com/arjunaskykok/mamba) - _Vyper言語で記述された、スマートコントラクトの記述、コンパイル、デプロイのためのフレームワーク_ -- [Brownie](https://github.com/eth-brownie/brownie) - _イーサリアムスマートコントラクトのデプロイ、テスト、やり取りを行うためのPythonフレームワーク_ -- [pydevp2p](https://github.com/ethereum/pydevp2p) - _イーサリアムのP2Pスタックの実装_ +- [py-solc-x](https://pypi.org/project/py-solc-x/) - _0.5.xをサポートするsolc SolidityコンパイラのPythonラッパー_ +- [pymaker](https://github.com/makerdao/pymaker) - _Makerコントラクト用のPython API_ +- [siwe](https://github.com/signinwithethereum/siwe-py) - _Python向けSign in with Ethereum (siwe)_ +- [Web3 DeFi for Ethereum integrations](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _ERC-20、Uniswap、その他の人気プロジェクトとの統合がすぐにできるPythonパッケージ_ +- [Wake](https://getwake.io) - _コントラクトのテスト、ファジング、デプロイ、脆弱性スキャン、コードナビゲーションのためのオールインワンPythonフレームワーク (言語サーバー - [Tools for Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ + +### アーカイブ済み / メンテナンスされていません: {#archived--no-longer-maintained} + +- [Trinity](https://github.com/ethereum/trinity) - _イーサリアムのPythonクライアント_ +- [Mamba](https://github.com/arjunaskykok/mamba) - _Vyper言語で書かれたスマートコントラクトを記述、コンパイル、デプロイするためのフレームワーク_ +- [Brownie](https://github.com/eth-brownie/brownie) - _イーサリアムのスマートコントラクトをデプロイ、テスト、操作するためのPythonフレームワーク_ +- [pydevp2p](https://github.com/ethereum/pydevp2p) - _イーサリアムP2Pスタックの実装_ - [py-wasm](https://github.com/ethereum/py-wasm) - _WebAssemblyインタプリタのPython実装_ -もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご確認ください。 +もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご覧ください。 -## Pythonツールを使用したプロジェクト {#projects-using-python-tooling} +## Pythonツールを使用しているプロジェクト {#projects-using-python-tooling} 以下のイーサリアムベースのプロジェクトでは、このページに記載されているツールを使用しています。 関連するオープンソースのリポジトリは、コード例や最善の方法として参照でき、役立ちます。 -- [Yearn Finance](https://yearn.finance/)と[Yearn Vault Contractsリポジトリ](https://github.com/yearn/yearn-vaults) -- [Curve](https://curve.fi/)と[Curveのスマートコントラクトリポジトリ](https://github.com/curvefi/curve-contract) -- [BadgerDAO](https://badger.com/)と[Brownieツールチェーンを使用したスマートコントラクト](https://github.com/Badger-Finance/badger-system) -- [Sushi](https://sushi.com/)による[Pythonを使用したべスティングコントラクトの管理とデプロイ](https://github.com/sushiswap/sushi-vesting-protocols) -- Alpha Homoraで有名な[Alpha Finance](https://alphafinance.io/)による[Brownieを使用したスマートコントラクトのテストとデプロイ](https://github.com/AlphaFinanceLab/alpha-staking-contract) +- [Yearn Finance](https://yearn.finance/)および[Yearn Vault Contractsリポジトリ](https://github.com/yearn/yearn-vaults) +- [Curve](https://www.curve.finance/)および[Curveスマートコントラクトリポジトリ](https://github.com/curvefi/curve-contract) +- [BadgerDAO](https://badger.com/)および[Brownieツールチェーンを使用したスマートコントラクト](https://github.com/Badger-Finance/badger-system) +- [Sushi](https://sushi.com/)は、[べスティングコントラクトの管理とデプロイにPythonを使用](https://github.com/sushiswap/sushi-vesting-protocols)しています +- Alpha Homoraで有名な[Alpha Finance](https://alphafinance.io/)は、[スマートコントラクトのテストとデプロイにBrownieを使用](https://github.com/AlphaFinanceLab/alpha-staking-contract)しています ## Pythonコミュニティディスカッション {#python-community-contributors} -- [イーサリアムPythonコミュニティのDiscord](https://discord.gg/9zk7snTfWe) Web3.pyやその他のPythonフレームワークについてのディスカッションを行う場所 -- [Vyper Discord](https://discord.gg/SdvKC79cJk) Vyperスマートコントラクトのプログラミングのディスカッション +- Web3.pyやその他のPythonフレームワークについて議論するための[Ethereum PythonコミュニティのDiscord](https://discord.gg/9zk7snTfWe) +- Vyperスマートコントラクトプログラミングについて議論するための[Vyper Discord](https://discord.gg/SdvKC79cJk) -## その他のリスト {#other-aggregated-lists} +## その他の集約リスト {#other-aggregated-lists} -Vyper wikiには、 [Vyperに関する豊富なリソースがあります。](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) \ No newline at end of file +Vyper wikiには[Vyperに関するすばらしいリソースのリスト](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)があります \ No newline at end of file diff --git a/public/content/translations/ja/developers/docs/programming-languages/ruby/index.md b/public/content/translations/ja/developers/docs/programming-languages/ruby/index.md index 72462686867..91d48d61c40 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/ruby/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/ruby/index.md @@ -1,60 +1,60 @@ --- -title: Rubyデベロッパーのためのイーサリアム -description: Rubyベースのプロジェクトとツールを使ってイーサリアムの開発方法を学びます。 +title: "Rubyデベロッパーのためのイーサリアム" +description: "Rubyベースのプロジェクトとツールを使用してイーサリアムの開発方法を学びます。" lang: ja incomplete: false --- -Rubyベースのプロジェクトとツールを使ってイーサリアムの開発方法を学びます。 +Rubyベースのプロジェクトとツールを使って、イーサリアム向けに開発する方法を学びましょう。 -イーサリアムを使用して、仮想通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 +イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 -## スマートコントラクトとSolidityを使い始める {#getting-started-with-smart-contracts-and-solidity} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-solidity} -**Rubyをイーサリアムに統合するための最初のステップを踏み出してみましょう。** +**Rubyをイーサリアムに統合するための最初のステップを踏み出してみましょう** -先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご確認ください。 +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご覧ください。 -- [ブロックチェーンの説明](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) - [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [初めてのスマートコントラクトを記述する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Solidityのコンパイルとデプロイの方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) ## 初心者向けの記事 {#beginner-articles} -- [いよいよイーサリアムアカウントを理解する](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) -- [いよいよMetaMaskを使用してRails Usersを認証する](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) -- [Rubyを使用してイーサリアムネットワークに接続する方法](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) +- [イーサリアムアカウントを完全に理解する](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [MetaMaskでRailsユーザーを認証する](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) +- [Rubyを使ってイーサリアムネットワークに接続する方法](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) - [Rubyで新しいイーサリアムアドレスを生成する方法](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) ## 中級者向けの記事 {#intermediate-articles} -- [Rubyを使用したブロックチェーンアプリケーション](https://www.nopio.com/blog/blockchain-app-ruby/) -- [イーサリアムに接続されたRubyを使用した、スマートコントラクトの実行](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) +- [Rubyによるブロックチェーンアプリ](https://www.nopio.com/blog/blockchain-app-ruby/) +- [イーサリアムに接続したRubyを使ってスマートコントラクトを実行する](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) -## Rubyプロジェクトとツール {#ruby-projects-and-tools} +## Rubyのプロジェクトとツール {#ruby-projects-and-tools} -### 現在でもメンテナンスされているもの {#active} +### アクティブ {#active} -- [eth.rb](https://github.com/q9f/eth.rb) - _イーサリアムアカウント、メッセージ、トランザクションを扱うためのRubyライブラリとRPCクライアント_ -- [keccak.rb](https://github.com/q9f/keccak.rb) - _イーサリアムによって使用されるKeccak (SHA3) ハッシュ_ -- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _イーサリアムによるサインインのRuby実装_ -- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _siweローカルサインインのルートを追加するRails gem_ -- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _カスタムコントローラでRuby on Railsを使用したsiweの例_ -- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _イーサリアムによるサインイン (siwe) のためのOmniAuthストラテジー_ +- [eth.rb](https://github.com/q9f/eth.rb) - _イーサリアムのアカウント、メッセージ、トランザクションを扱うためのRubyライブラリおよびRPCクライアント_ +- [keccak.rb](https://github.com/q9f/keccak.rb) - _イーサリアムで使われているKeccak (SHA3) ハッシュ_ +- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Sign-In with EthereumのRuby実装_ +- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _SIWEのローカルサインインルートを追加するRails gem_ +- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _カスタムコントローラを使用したRuby on RailsでのSIWEの例_ +- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _Sign In With Ethereum (SIWE) のためのOmniAuthストラテジー_ - [omniauth-nft](https://github.com/valthon/omniauth-nft) - _NFT所有権による認証のためのOmniAuthストラテジー_ -- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _MetaMaskをRuby on Railsに接続できるようにする、Railsでのイーサリアムテンプレート_ +- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _MetaMaskとRuby on Railsの接続を可能にするEthereum on Railsテンプレート_ -### アーカイブ済み ・メンテナンスされていないもの {#archived--no-longer-maintained} +### アーカイブ済み / メンテナンス終了 {#archived--no-longer-maintained} -- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _Rubyを使用してイーサリアムノードのRPCメソッドを呼び出す_ -- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _BIP32標準に従って階層決定性ウォレットからETHアドレスを生成するためのRubyライブラリ_ -- [etherlite](https://github.com/budacom/etherlite) - _Ruby on Railsのためのイーサリアム統合_ -- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _JSON-RPCインターフェースを使用するRubyのイーサリアムクライアント。トランザクションの送信、コントラクトの作成、コントラクトとのやり取りを行えるようにするとともに、イーサリアムノードで使用する便利なツールキットも提供する_ -- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _OmniAuthのイーサリアムプロバイダストラテジーを実装する_ +- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _RubyでイーサリアムノードのRPCメソッドを呼び出す_ +- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _BIP32標準に従って、階層的決定性ウォレットからETHアドレスを生成するためのRubyライブラリ_ +- [etherlite](https://github.com/budacom/etherlite) - _Ruby on Rails向けのイーサリアム統合_ +- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _JSON-RPCインターフェースを使用してトランザクションを送信し、コントラクトを作成・操作するRubyイーサリアムクライアント。イーサリアムノードを扱うための便利なツールキットでもあります_ +- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _OmniAuth向けのイーサリアムプロバイダストラテジーを実装します_ -もっとリソースをお探しですか？ [デベロッパーホーム](/developers/)をご確認ください。 +もっとリソースをお探しですか？ [デベロッパーホーム](/developers/)をご覧ください。 -## Rubyコミュニティコントリビューター {#ruby-community-contributors} +## Rubyコミュニティのコントリビューター {#ruby-community-contributors} -[イーサリアムRubyテレグラムグループ](https://t.me/ruby_eth) は急速に成長しているコミュニティのホストであり、上記のプロジェクトや関連するトピックに関するディスカッションのための専用のリソースです。 +[Ethereum Ruby Telegramグループ](https://t.me/ruby_eth)は、急速に成長しているコミュニティの拠点であり、上記のプロジェクトや関連トピックについて議論するための専用リソースです。 diff --git a/public/content/translations/ja/developers/docs/programming-languages/rust/index.md b/public/content/translations/ja/developers/docs/programming-languages/rust/index.md index ad6f19bf064..0c2e06879e9 100644 --- a/public/content/translations/ja/developers/docs/programming-languages/rust/index.md +++ b/public/content/translations/ja/developers/docs/programming-languages/rust/index.md @@ -1,61 +1,63 @@ --- -title: Rustデベロッパーのためのイーサリアム -description: Rustベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ +title: "Rustデベロッパーのためのイーサリアム" +description: "Rustベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ" lang: ja incomplete: true --- Rustベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ -イーサリアムを使用して、仮想通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 +イーサリアムを使用して、暗号通貨とブロックチェーン技術の利点を活用した分散型アプリケーション (「dapp」) を作成します。 dappは、信頼性の高いアプリケーションです。つまり、イーサリアムにデプロイした後は、常にプログラムしたとおりに動作します。 デジタル資産を制御して、新たなタイプの金融アプリケーションを作成できます。 また、分散化できるため、単一のエンティティや個人は制御できず、検閲はほぼ不可能であることを意味します。 -## スマートコントラクトとSolidityを使い始める {#getting-started-with-smart-contracts-and-solidity} +## スマートコントラクトとSolidity言語入門 {#getting-started-with-smart-contracts-and-solidity} -**Rustをイーサリアムに統合するための最初のステップを踏み出してみましょう。** +**Rustをイーサリアムに統合するための最初のステップを踏み出してみましょう** -先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご確認ください。 +先に基礎を学習したい場合は、 [ethereum.org/learn](/learn/)または[ethereum.org/developers](/developers/)をご覧ください。 -- [ブロックチェーンの説明](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [ブロックチェーン解説](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) - [スマートコントラクトを理解する](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [初めてのスマートコントラクトを記述する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Solidityのコンパイルとデプロイの方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [初めてのスマートコントラクトを作成する](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Solidityのコンパイルとデプロイ方法を学ぶ](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) ## 初心者向けの記事 {#beginner-articles} -- [Rustイーサリアムクライアント](https://openethereum.github.io/) \* **OpenEthereumは[すでに廃止されており](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd)、現在は維持されていません。** ご利用には注意が必要です。できれば、他のクライアント実装に切り替えてください。 +- [Rustイーサリアムクライアント](https://openethereum.github.io/) \* **注：OpenEthereumは[廃止された](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd)ため、現在はメンテナンスされていません。** 注意して使用し、できれば別のクライアント実装に切り替えてください。 - [Rustを使用してイーサリアムにトランザクションを送信する](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) -- [Kovan向けRust Wasmでのコントラクトの記述方法についての段階的なチュートリアル](https://github.com/paritytech/pwasm-tutorial) +- [Kovan向けのRust Wasmでコントラクトを作成する方法に関するステップバイステップチュートリアル](https://github.com/paritytech/pwasm-tutorial) ## 中級者向けの記事 {#intermediate-articles} -## 発展的なユースケース {#advanced-use-patterns} +## 高度な使用パターン {#advanced-use-patterns} + +- [イーサリアムのようなネットワークと対話するためのpwasm_ethereum externsライブラリ](https://github.com/openethereum/pwasm-ethereum) -- [pwasm_ethereum イーサリアムライクなネットワークと対話するためのexternライブラリ](https://github.com/openethereum/pwasm-ethereum) - [JavaScriptとRustを使用して分散型チャットを構築する](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) -- [Vue.jsとRustを使用して分散化Todoアプリを構築する](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) + +- [Vue.jsとRustを使用して分散型Todoアプリを構築する](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) - [Rustでブロックチェーンを構築する](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) ## Rustのプロジェクトとツール {#rust-projects-and-tools} -- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _イーサリアムライクのネットワークとやり取りするためのexternのコレクション_ -- [Lighthouse](https://github.com/sigp/lighthouse) - _高速イーサリアムコンセンサスレイヤークライアント_ +- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _イーサリアム系ネットワークとやり取りするためのexternのコレクション_ +- [Lighthouse](https://github.com/sigp/lighthouse) - _高速なイーサリアムコンセンサスレイヤークライアント_ - [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _WebAssemblyの決定論的サブセットを使用して、イーサリアムスマートコントラクト実行レイヤーを再設計する提案_ -- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS APIレファレンス_ -- [Solaris](https://github.com/paritytech/sol-rs) - _ネイティブParityクライアントEVMを使用したSolidityスマートコントラクトのユニットテストハーネス_ -- [SputnikVM](https://github.com/rust-blockchain/evm) - _Rustのイーサリアム仮想マシンの実装_ -- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Rustで書かれたWaveletスマートコントラクト_ -- [Foundry](https://github.com/foundry-rs/foundry) - _イーサリアムアプリケーション開発のためのツールキット_ -- [Alloy](https://alloy.rs) - _イーサリアムおよび他のEVMベースのチェーンとやり取りするための、高性能で、十分にテストされ、文書化されたライブラリ_ -- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _イーサリアムのライブラリとウォレットの実装_ +- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS APIリファレンス_ +- [Solaris](https://github.com/paritytech/sol-rs) - _ネイティブParityクライアントEVMを使用したSolidityスマートコントラクトのユニットテストハーネス。_ +- [SputnikVM](https://github.com/rust-blockchain/evm) - _Rustによるイーサリアム仮想マシンの実装_ +- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _RustでのWaveletスマートコントラクト_ +- [Foundry](https://github.com/foundry-rs/foundry) - _イーサリアムアプリケーション開発用ツールキット_ +- [Alloy](https://alloy.rs) - _イーサリアムおよび他のEVMベースのチェーンとやり取りするための、高性能で、十分にテストされ、文書化されたライブラリ。_ +- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _イーサリアムライブラリとウォレットの実装_ - [SewUp](https://github.com/second-state/SewUp) - _Rustを使用したイーサリアムWebAssemblyコントラクトの構築と、一般的なバックエンドと同様の開発をサポートするライブラリ_ -- [Substreams](https://github.com/streamingfast/substreams) - _並列化ブロックチェーンデータインデックス技術_ -- [Reth](https://github.com/paradigmxyz/reth) - (Rust Ethereumの略) イーサリアムの新しいフルノード実装 -- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Rustで書かれたイーサリアム・エコシステム・プロジェクトの厳選コレクション_ +- [Substreams](https://github.com/streamingfast/substreams) - _並列化ブロックチェーンデータインデックス作成技術_ +- [Reth](https://github.com/paradigmxyz/reth) Reth（Rust Ethereumの略）は、イーサリアムの新しいフルノード実装です +- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Rustで書かれたイーサリアムエコシステムのプロジェクトの厳選コレクション_ -もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をご確認ください。 +もっとリソースをお探しですか？ [ethereum.org/developers](/developers/)をチェックしてください。 -## Rustコミュニティコントリビューター {#rust-community-contributors} +## Rustコミュニティのコントリビューター {#rust-community-contributors} - [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) - [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) diff --git a/public/content/translations/ja/developers/docs/scaling/index.md b/public/content/translations/ja/developers/docs/scaling/index.md index 695f08fb2f9..d7a6faef157 100644 --- a/public/content/translations/ja/developers/docs/scaling/index.md +++ b/public/content/translations/ja/developers/docs/scaling/index.md @@ -1,6 +1,6 @@ --- -title: スケーリング -description: 現在イーサリアムコミュニティにおいて開発中のさまざまなスケーリングのオプションを紹介する。 +title: "スケーリング" +description: "現在イーサリアムコミュニティにおいて開発中のさまざまなスケーリングのオプションを紹介する。" lang: ja sidebarDepth: 3 --- @@ -9,42 +9,42 @@ sidebarDepth: 3 イーサリアムのユーザー規模が拡大するにつれ、イーサリアムブロックチェーンの処理能力は限界に達しつつあります。 これにより、イーサリアムネットワークの使用コストが増加しているため、「スケーリングソリューション」の必要性が高まってきました。 スケーリングを達成するという目標の下で、異なるアプローチを用いた様々なソリューションが研究、テスト、および実装されています。 -スケーラビリティの取り組みにおける主な目標は、分散化やセキュリティを犠牲にすることなく、トランザクション速度の向上（ファイナリティ到達までの時間短縮）ならびにトランザクションスループットの向上（毎秒あたりのトランザクション数の向上）を実現することです（詳細については、[イーサリアムのビジョン](/roadmap/vision/)をご覧ください）。 レイヤー1のイーサリアムブロックチェーンでは、需要が増化するとトランザクションが遅延し、[ガス価格](/developers/docs/gas/)が高騰します。 イーサリアムが有意義かつ大規模に利用されるようになるためには、ネットワークの速度とスループットを改善することが不可欠です。 +スケーラビリティの主な目標は、分散化やセキュリティを損なうことなく、トランザクション速度(ファイナリティの迅速化)とトランザクションスループット(1秒あたりのトランザクション数の増加)を向上させることです。 レイヤー1のイーサリアムブロックチェーンでは、高い需要がトランザクションの遅延と、法外な[ガス価格](/developers/docs/gas/)につながります。 イーサリアムが有意義かつ大規模に利用されるようになるためには、ネットワークの速度とスループットを改善することが不可欠です。 速度とスループットが重要である一方で、スケーリングのソリューションはこれらの目標を、分散化とセキュリティという特性を失わずに実現しなければなりません。 中央集権化およびセキュリティの低下を防ぐためには、どんなユーザーでもノードとして参加できるように参入障壁を低くしておくことが重要です。 -スケーリングの概念では、まずオンチェーンのスケーリングとオフチェーンのスケーリングに分けて考えることができます。 +概念的に、まずスケーリングをオンチェーンスケーリングまたはオフチェーンスケーリングに分類します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} イーサリアムに関する基本的なトピックすべてをよく理解しておく必要があります。 スケーリング技術は、バトルテストの実績が少なく、引き続き研究、開発が続けている状態であるため、スケーリングソリューションの実装は上級者向けのテーマだと言えます。 -## オンチェーンにおけるスケーリング {#on-chain-scaling} +## オンチェーンスケーリング {#onchain-scaling} -オンチェーンスケーリングでは、イーサリアムプロトコル(レイヤー1の[メインネット](/glossary/#mainnet))を変更する必要があります。 長い間、ブロックチェーンのシャーディングによってイーサリアムが拡張されると期待されていました。 シャーディングとは、ブロックチェーンを複数の部分(シャード)に分割する技術であり、バリデータのサブセットによって検証される予定でした。 しかし、主要なスケーリング技術として、レイヤー2ロールアップによるスケーリングが引き継がれており、 より安く新しいデータ形式を追加することでサポートされています。このデータ形式は、ユーザーにとってロールアップを安価にするために特別に設計されています。 +オンチェーンスケーリングには、イーサリアムプロトコル(レイヤー1の[メインネット](/glossary/#mainnet))の変更が必要です。 長い間、ブロックチェーンのシャーディングによってイーサリアムが拡張されると期待されていました。 シャーディングとは、ブロックチェーンを複数の部分(シャード)に分割する技術であり、バリデータのサブセットによって検証される予定でした。 しかし、主要なスケーリング技術として、レイヤー2ロールアップによるスケーリングが引き継がれており、 より安く新しいデータ形式を追加することでサポートされています。このデータ形式は、ユーザーにとってロールアップを安価にするために特別に設計されています。 ### シャーディング {#sharding} -シャーディングは、データベースを分割するプロセスです。 バリデータのサブセットは、イーサリアム全体を追跡するのではなく、個々のシャードに対して責任を持ちます。 シャーディングは、長い間、イーサリアムの[ロードマップ](/roadmap/)に記載されていました。また、かつては、プルーフ・オブ・ステークへ切り替わるマージの前にリリースされる予定でした。 しかし、[レイヤー2ロールアップ](#layer-2-scaling)の急速な開発と、[ダンクシャーディング](/roadmap/danksharding)(バリデータが非常に効率的に検証できるロールアップデータであるブロブをイーサリアムブロックに追加すること)の開発により、イーサリアムコミュニティの関心は、シャーディングによるスケーリングからロールアップ中心のスケーリングへとシフトしました。 これにより、イーサリアムのコンセンサスロジックは比較的シンプルに保たれることになりました。 +シャーディングは、データベースを分割するプロセスです。 バリデータのサブセットは、イーサリアム全体を追跡するのではなく、個々のシャードに対して責任を持ちます。 シャーディングは長い間イーサリアムの[ロードマップ](/roadmap/)に記載されており、かつてはプルーフ・オブ・ステークへの「マージ」の前にリリースされる予定でした。 しかし、[レイヤー2ロールアップ](#layer-2-scaling)の急速な開発と[Danksharding](/roadmap/danksharding)の発明(バリデーターが非常に効率的に検証できるロールアップデータのブロブをイーサリアムブロックに追加する仕組み)により、イーサリアムコミュニティは、シャーディングによるスケーリングではなく、ロールアップ中心のスケーリングを支持するようになりました。 これにより、イーサリアムのコンセンサスロジックは比較的シンプルに保たれることになりました。 -## オフチェーンにおけるスケーリング {#off-chain-scaling} +## オフチェーンスケーリング {#offchain-scaling} -オフチェーンのスケーリングソリューションは、レイヤー1のメインネットとは別個に実装されるため、既存のイーサリアムプロトコルを変更する必要がありません。 「レイヤー2」ソリューションと呼ばれる一部のソリューションでは、[オプティミスティックロールアップ](/developers/docs/scaling/optimistic-rollups/)、[ゼロ知識ロールアップ](/developers/docs/scaling/zk-rollups/)、[ステートチャンネル](/developers/docs/scaling/state-channels/)など、レイヤー1のイーサリアムコンセンサスに依存してセキュリティを保護するものもあります。 一方、[サイドチェーン](#sidechains)、[バリディアム](#validium)、あるいは[プラズマチェーン](#plasma)などのソリューションでは、メインネットとは別に、さまざまな形式の新規チェーンを作成してセキュリティを保証します。 これらのソリューションでは、メインネットとやり取りするものの、各ソリューションの目標に合わせて、セキュリティを維持する方法は異なります。 +オフチェーンソリューションは、レイヤー1メインネットとは別に実装されます - 既存のイーサリアムプロトコルに変更は必要ありません。 「レイヤー2」ソリューションとして知られる一部のソリューションは、[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)、[ゼロ知識ロールアップ](/developers/docs/scaling/zk-rollups/)、[ステートチャネル](/developers/docs/scaling/state-channels/)のように、レイヤー1のイーサリアムのコンセンサスから直接セキュリティを継承しています。 一方、[サイドチェーン](#sidechains)、[バリディウム](#validium)、[プラズマチェーン](#plasma)などのソリューションでは、メインネットとは別に、さまざまな形式の新規チェーンを作成してセキュリティを確保します。 これらのソリューションはメインネットと通信しますが、さまざまな目標を達成するために、異なる方法でセキュリティを確保しています。 -### レイヤー2のスケーリング {#layer-2-scaling} +### レイヤー2スケーリング {#layer-2-scaling} -オフチェーンのソリューションのうち、セキュリティをイーサリアムメインネットに依存するものをレイヤー2のスケーリングソリューションと呼びます。 +このオフチェーンソリューションのカテゴリーは、メインネットイーサリアムからセキュリティを得ています。 レイヤー2とは、メインネットが提供する堅牢かつ分散型のセキュリティモデルを活用しつつ、イーサリアムメインネット(レイヤー1)外でトランザクションを実行することでアプリケーションのスケーラビリティを実現しようとするソリューションの総称です。 ネットワークの混雑によりトランザクション速度が低下すると、一部のDappでは優れたユーザー体験を提供できなくなります。 また、ネットワークが混雑すると、トランザクションの送信者がガス代を高く支払うようになります。そのため、ガス代が上昇し、 イーサリアムの使用コストが非常に高額になる可能性があります。 -ほとんどのレイヤー2ソリューションは、サーバーまたはサーバー群を中心に構成されており、それぞれのサーバーは、ノード、バリデータ、オペレーター、シーケンサー、ブロックプロデューサーなどと呼ばれています。 これらのレイヤー2ノードは、実装方法によって、利用する個人や企業、団体、サードパーティのオペレーター、大規模な個人のグループなどが運営する場合があります(メインネットと同様)。 通常、取引はレイヤー1(メインネット)に直接送信されるのではなく、レイヤー2のノードに送信されます。 ソリューションによっては、レイヤー2のインスタンスがトランザクションをグループ化してレイヤー1に固定します。その後、レイヤー1によって安全性が確保されると、それ以降は変更できなくなります。 このプロセスの具体的な実行方法は、レイヤー2のテクノロジーや実装によって大きく異なります。 +大部分のレイヤー2ソリューションは、1台または複数のサーバークラスタで構成され、各サーバーはノード、バリデータ、オペレーター、シーケンサー、ブロック生成者といった名称で呼ばれます。 これらのレイヤー2ノードは、実装方法によって、利用する個人や企業、団体、サードパーティのオペレーター、大規模な個人のグループなどが運営する場合があります(メインネットと同様)。 通常、取引はレイヤー1(メインネット)に直接送信されるのではなく、レイヤー2のノードに送信されます。 一部のソリューションでは、レイヤー2インスタンスがトランザクションをグループにまとめてからレイヤー1にアンカリングし、その後レイヤー1によって保護され変更不可能になります。 このプロセスの具体的な実行方法は、レイヤー2のテクノロジーや実装によって大きく異なります。 特定のレイヤー2インスタンスは、オープンで多くのアプリケーションが共有するものもあれば、1つのプロジェクトがデプロイし、そのアプリケーションのみをサポートするものもあります。 #### レイヤー2が必要な理由 {#why-is-layer-2-needed} - 毎秒あたりのトランザクション数を増加させることで、ユーザー体験が向上し、イーサリアムメインネットの混雑を軽減できる。 -- 複数のトランザクションを1つのトランザクションにロールアップしてメインネットに送信するため、ガス代が軽減でき、イーサリアムの包摂性が高まり、すべての人が利用できるようになる。 +- トランザクションはイーサリアムメインネットへの単一のトランザクションにロールアップされるため、ユーザーのガス代が削減され、イーサリアムはより包括的で、世界中の人々がアクセスしやすいものになります。 - スケーラビリティを実現するためのアップデートは、分散化やセキュリティを犠牲にしてはならないが、レイヤー2はイーサリアムの基盤に基づくネットワークである。 - アプリケーションごとに特化されたレイヤー2のネットワークでは、大規模な資産を取り扱う際に独自の効率性アップが実現できる。 @@ -56,58 +56,58 @@ sidebarDepth: 3 ロールアップには、異なるセキュリティモデルを採用した以下の2種類があります。 -- **オプティミスティック・ロールアップ**: トランザクションはデフォルトで有効であると仮定し、チャレンジが提起された場合のみ[**不正証明**](/glossary/#fraud-proof)を通じて計算を実行します。 [オプティミスティック・ロールアップの詳細](/developers/docs/scaling/optimistic-rollups/)。 -- **ゼロ知識ロールアップ**: オフチェーンで計算を実行し、[**有効性証明**](/glossary/#validity-proof)をチェーンに送信します。 [ゼロ知識ロールアップの詳細](/developers/docs/scaling/zk-rollups/)。 +- **オプティミスティック・ロールアップ**: トランザクションがデフォルトで有効であると仮定し、異議申し立てがあった場合にのみ、[**不正証明**](/glossary/#fraud-proof)を介して計算を実行します。 [オプティミスティック・ロールアップの詳細](/developers/docs/scaling/optimistic-rollups/) +- **ゼロ知識ロールアップ**: オフチェーンで計算を実行し、チェーンに[**有効性証明**](/glossary/#validity-proof)を提出します。 [ゼロ知識ロールアップの詳細](/developers/docs/scaling/zk-rollups/) -#### ステートチャンネル {#channels} +#### ステートチャネル {#channels} -ステートチャンネルでは、マルチシグのコントラクトを通じて、参加者はオフチェーンで迅速かつ自由に取引を行うことでき、その上でメインネット上でファイナリティを実現します。 これにより、ネットワークの混雑、手数料、遅延を最小限に抑えることができます。 現在利用されているチャンネルは、ステートチャンネルとペイメントチャンネルの2つです。 +ステートチャネルは、マルチシグコントラクトを活用して参加者がオフチェーンで迅速かつ自由にトランザクションを行い、その後メインネットで最終決済を行います。 これにより、ネットワークの混雑、手数料、遅延を最小限に抑えることができます。 現在利用されているチャンネルは、ステートチャンネルとペイメントチャンネルの2つです。 -[ステートチャンネル](/developers/docs/scaling/state-channels/)の詳細 +[ステートチャネル](/developers/docs/scaling/state-channels/)についてさらに詳しく学ぶ ### サイドチェーン {#sidechains} -サイドチェーンは、EVM互換の独立したブロックチェーンであり、メインネットと並行して実行されます。 イーサリアムとの互換性は双方向ブリッジで実現され、トランザクションは独自に選択したコンセンサスルールとブロックパラメータに基づいて実行されます。 +サイドチェーンは、メインネットと並行して実行される、EVM互換の独立したブロックチェーンです。 これらは双方向ブリッジを介してイーサリアムと互換性があり、独自に選択したコンセンサスルールとブロックパラメータの下で実行されます。 -[サイドチェーン](/developers/docs/scaling/sidechains/)の詳細 +[サイドチェーン](/developers/docs/scaling/sidechains/)についてさらに詳しく学ぶ ### プラズマ {#plasma} -プラズマチェーンとは、メインのイーサリアムチェーンにおいて固定された別個のブロックチェーンで、不正証明([オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)など)を用いて紛争を仲裁します。 +プラズマチェーンは、メインのイーサリアムチェーンにアンカーされた独立したブロックチェーンであり、([オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)のような)不正証明を用いて紛争を仲裁します。 -[プラズマ](/developers/docs/scaling/plasma/)の詳細 +[プラズマ](/developers/docs/scaling/plasma/)についてさらに詳しく学ぶ -### バリディアム {#validium} +### バリディウム {#validium} バリディアムチェーンはゼロ知識ロールアップのように有効性証明を使用しますが、メインのレイヤー1イーサリアムチェーン上にデータを保存しません。 そのため、バリディアムチェーンごとに毎秒1万のトランザクションを処理でき、複数のチェーンを並列に実行できます。 -[バリディアム](/developers/docs/scaling/validium/)の詳細 +[バリディウム](/developers/docs/scaling/validium/)についてさらに詳しく学ぶ ## さまざまなスケーリングソリューションが求められる理由 {#why-do-we-need-these} -- さまざまなソリューションは、イーサリアムネットワーク全体の混雑を緩和するだけでなく、単一障害点の発生を防ぐためにも役立ちます。 +- 複数のソリューションによって、ネットワークの特定の部分の全体的な混雑を緩和し、単一障害点を防ぐことができます。 - 複数のソリューションは、その全体においてさらに効力を発揮します。 つまり、多様なソリューションが共存し、調和的に機能することで、トランザクションの速度やスループットを今後爆発的に向上させることが可能になります。 - すべてのソリューションにおいてイーサリアムのコンセンサス・アルゴリズムを直接活用する必要があるわけではなく、さまざまな代替手段によりその他の方法では得にくいメリットを得ることができます。 -- 特定のスケーリング・ソリューションが[イーサリアムのビジョン](/roadmap/vision/)を完全に満たすことは不可能です。 ## 映像で学びたい場合 {#visual-learner} -_この動画の説明では、「レイヤー2」という用語をオフチェーンでのスケーリング・ソリューション全般を指すものとして使用していますが、本記事では、、レイヤー1(メインネット)のコンセンサスに依存してセキュリティを保護するオフチェーンソリューションを指す用語として「レイヤー2」を用いています。_ +_注: 動画の説明では「レイヤー2」という用語をすべてのオフチェーンスケーリングソリューションを指すのに使用していますが、私たちは「レイヤー2」をレイヤー1メインネットコンセンサスを通じてセキュリティを得るオフチェーンソリューションとして区別しています。_ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [ロールアップを重視したイーサリアム・ロードマップ](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _ヴィタリック・ブテリン作成。_ -- [イーサリアムのレイヤー2スケーリング・ソリューションに関する最新のアナリティクス](https://www.l2beat.com/) -- [イーサリアムの様々なレイヤー2のスケーリングソリューションを評価する：比較のフレームワーク](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) -- [ロールアップに関する不完全ガイド](https://vitalik.eth.limo/general/2021/01/05/rollup.html) -- [イーサリアムを活用したゼロ知識ロールアップ：ワールドビーター](https://hackmd.io/@canti/rkUT0BD8K) -- [オプティミスティック・ロールアップ とゼロ知識ロールアップの比較](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) -- [ロールアップとデータシャードを組み合わせる手段が、高スケーラビリティを実現する唯一のサステナブルなソリューションである理由](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) -- [有意義なレイヤー3とはどのようなものか？](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) -- [データ可用性か、あるいは： ロールアップで心配することを止めてイーサリアムを愛するようになった仕組み](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) +- [ロールアップ中心のイーサリアムロードマップ](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ +- [イーサリアムのレイヤー2スケーリングソリューションに関する最新の分析](https://www.l2beat.com/) +- [イーサリアムのレイヤー2スケーリングソリューションの評価: 比較フレームワーク](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +- [ロールアップに関する不完全なガイド](https://vitalik.eth.limo/general/2021/01/05/rollup.html) +- [イーサリアムによるZKロールアップ: ワールドビーター](https://hackmd.io/@canti/rkUT0BD8K) +- [オプティミスティック・ロールアップ vs ZKロールアップ](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) +- [なぜロールアップとデータシャードが高いスケーラビリティのための唯一の持続可能なソリューションなのか](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) +- [どのようなレイヤー3が理にかなっているか](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) +- [データ可用性、またはロールアップはいかにして心配するのをやめイーサリアムを愛するようになったか](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [イーサリアムロールアップ実践ガイド](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/ja/developers/docs/scaling/optimistic-rollups/index.md index c7cd69803be..10b57101178 100644 --- a/public/content/translations/ja/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/ja/developers/docs/scaling/optimistic-rollups/index.md @@ -1,26 +1,26 @@ --- -title: オプティミスティック・ロールアップ -description: イーサリアムにおけるスケーリングの問題に対する解決策であるオプティミスティック・ロールアップの紹介 +title: "オプティミスティック・ロールアップ" +description: "イーサリアムにおけるスケーリングの問題に対する解決策であるオプティミスティック・ロールアップの紹介" lang: ja --- -オプティミスティック・ロールアップは、イーサリアム（ベースレイヤー）のスループットを拡張するために設計されたレイヤー2 (L2) プロトコルです。 トランザクションをオフチェーンで処理することで、イーサリアムメインネットの負荷を軽減するため、処理速度が大幅に改善されます。 オプティミスティック・ロールアップは、[サイドチェーン](/developers/docs/scaling/sidechains/)のような他のスケーリング・ソリューションとは異なり、トランザクションの結果をオンチェーンで公開することによってメインネットからセキュリティを引き出します。プラズマチェーンも、不正証明を使用してイーサリアム上で検証しますが、トランザクションのデータをイーサリアムに保存しない点が異なります。 +オプティミスティック・ロールアップは、イーサリアム（ベースレイヤー）のスループットを拡張するために設計されたレイヤー2 (L2) プロトコルです。 トランザクションをオフチェーンで処理することで、メインのイーサリアムチェーン上の計算量を削減し、処理速度を大幅に向上させます。 [サイドチェーン](/developers/docs/scaling/sidechains/)や、同じく不正証明を用いてイーサリアムでトランザクションを検証するもののトランザクションデータは別の場所に保存する[プラズマチェーン](/developers/docs/scaling/plasma/)といった他のスケーリングソリューションとは異なり、オプティミスティック・ロールアップはトランザクション結果をオンチェーンで公開することでメインネットからセキュリティを派生させます。 -イーサリアムにおける処理は、速度が遅く高価であるという欠点がありますが、オプティミスティック・ロールアップを用いることでスケーラビリティを10〜100倍向上させることができます。 さらに、トランザクションを`calldata`または[ブロブ](/roadmap/danksharding/)としてイーサリアムに書き込むため、ユーザーが負担するガス代を低く抑えることができます。 +イーサリアムにおける処理は、速度が遅く高価であるという欠点がありますが、オプティミスティック・ロールアップを用いることでスケーラビリティを10〜100倍向上させることができます。 オプティミスティック・ロールアップはまた、トランザクションを`calldata`として、または[ブロブ](/roadmap/danksharding/)でイーサリアムに書き込むことで、ユーザーのガス代を削減します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[イーサリアムにおけるスケーリング](/developers/docs/scaling/)と[レイヤー2](/layer-2/) のページを読み、理解しておくことをおすすめします。 +[イーサリアムのスケーリング](/developers/docs/scaling/)と[レイヤー2](/layer-2/)に関するページを読み、理解しておく必要があります。 ## オプティミスティック・ロールアップとは何か？ {#what-is-an-optimistic-rollup} -オプティミスティック・ロールアップとは、計算とステート保存をオフチェーンに移動させることで、スケーリングの問題を解決するアプローチです。 オプティミスティック・ロールアップでは、トランザクションをイーサリアムの外部で実行した上で、トランザクションデータを`calldata`または[ブロブ](/roadmap/danksharding/)としてメインネットに投稿します。 +オプティミスティック・ロールアップとは、計算とステートストレージをオフチェーンに移動させることでイーサリアムをスケーリングするアプローチです。 オプティミスティック・ロールアップはイーサリアムの外部でトランザクションを実行しますが、トランザクションデータを`calldata`として、または[ブロブ](/roadmap/danksharding/)でメインネットに投稿します。 -オプティミスティック・ロールアップのオペレータは、オフチェーンで実行された複数のトランザクションをバンドル化し、より大きなバッチとしてイーサリアムに送信します。 このアプローチでは、固定費を各バッチに含まれる複数のトランザクションに分散できるため、エンドユーザーの費用を軽減することができます。 さらに、データ圧縮技術を用いることで、イーサリアムに送信するデータ量を削減しています。 +オプティミスティック・ロールアップのオペレーターは、イーサリアムに送信する前に、複数のオフチェーントランザクションをまとめて大きなバッチにします。 このアプローチでは、固定費を各バッチに含まれる複数のトランザクションに分散できるため、エンドユーザーの費用を軽減することができます。 さらに、データ圧縮技術を用いることで、イーサリアムに送信するデータ量を削減しています。 -オプティミスティック・ロールアップが「楽観的」と呼ばれる理由は、オフチェーンのトランザクションが「有効」であると想定し、オンチェーンに送信されるバッチに含まれるトランザクションの有効性証明を公開しないからです。 これこそ、オフチェーンのトランザクションに対して暗号による[有効性証明](/glossary/#validity-proof)を発行する[ゼロ知識ロールアップ](/developers/docs/scaling/zk-rollups)と、オプティミスティック・ロールアップが異なるポイントです。 +オプティミスティック・ロールアップが「楽観的」と見なされるのは、オフチェーントランザクションが有効であると想定し、オンチェーンに投稿されるトランザクションバッチの有効性の証明を公開しないためです。 この点が、オフチェーントランザクションに対して暗号論的な[有効性証明](/glossary/#validity-proof)を公開する[ゼロ知識ロールアップ](/developers/docs/scaling/zk-rollups)とオプティミスティック・ロールアップを区別します。 -オプティミスティック・ロールアップでは、暗号による有効性証明の代わりに不正証明のスキームを用いて、正しく計算されていないトランザクションを検出します。 ロールアップされたバッチがイーサリアムに送信される際には、チャレンジ期間と呼ばれる一定の期間が設定されており、その期間内は誰もが[不正証明](/glossary/#fraud-proof)を計算することで、ロールアップされたトランザクションの結果に異議を申し立てることができます。 +オプティミスティック・ロールアップでは、暗号による有効性証明の代わりに不正証明のスキームを用いて、正しく計算されていないトランザクションを検出します。 ロールアップバッチがイーサリアムに送信された後、「チャレンジ期間」と呼ばれる時間枠があり、その間は誰でも[不正証明](/glossary/#fraud-proof)を計算することで、ロールアップトランザクションの結果に異議を申し立てることができます。 不正証明が認められると、ロールアップのプロトコルにより当該のトランザクション（複数の場合あり）が再度計算され、その結果に基づきロールアップのステートが更新されます。 不正証明が認められた場合はさらに、不適切に実行されたトランザクションをブロックに追加したシーケンサーにペナルティが科されます。 @@ -28,35 +28,36 @@ lang: ja ## オプティミスティック・ロールアップは、イーサリアムとどのようなやりとりを行うか？ {#optimistic-rollups-and-Ethereum} -オプティミスティック・ロールアップは、イーサリアム上で動作するように構築された[オフチェーンのスケーリング・ソリューション](/developers/docs/scaling/#off-chain-scaling)です。 個々のオプティミスティック・ロールアップは、イーサリアムメインネット上でデプロイされた一連のスマートコントラクトにより管理されます。 オプティミスティック・ロールアップでは、イーサリアムメインネットの外部でトランザクションを処理しますが、オフチェーンで処理したトランザクションを（バッチ化した上で）オンチェーンのロールアップ・コントラクトに送信します。 イーサリアムブロックチェーンと同様に、このトランザクション記録は改変不可であり、「オプティミスティック・ロールアップ・チェーン」を構築します。 +オプティミスティック・ロールアップは、イーサリアム上で動作するように構築された[オフチェーンスケーリングソリューション](/developers/docs/scaling/#offchain-scaling)です。 個々のオプティミスティック・ロールアップは、イーサリアムメインネット上でデプロイされた一連のスマートコントラクトにより管理されます。 オプティミスティック・ロールアップは、メインのイーサリアムチェーンの外部でトランザクションを処理しますが、オフチェーントランザクションを（バッチで）オンチェーンのロールアップコントラクトに投稿します。 イーサリアムブロックチェーンと同様に、このトランザクション記録は改変不可であり、「オプティミスティック・ロールアップ・チェーン」を構築します。 オプティミスティック・ロールアップのアーキテクチャには、以下の構成要素が含まれています： -**オンチェーンのコントラクト**: オプティミスティック・ロールアップの動作は、イーサリアム上で実行されるスマートコントラクトにより制御されます。 具体的には、ロールアップされたブロックを保存するコントラクト、ロールアップの状態更新を監視するコントラクト、およびユーザーのデポジットを追跡するコントラクトが含まれます。 この意味で、イーサリアムは、オプティミスティック・ロールアップに対するベースレイヤー（つまり、「レイヤー1」）であると言うことができます。 +**オンチェーンコントラクト**: オプティミスティック・ロールアップの運用は、イーサリアム上で実行されるスマートコントラクトによって制御されます。 具体的には、ロールアップされたブロックを保存するコントラクト、ロールアップの状態更新を監視するコントラクト、およびユーザーのデポジットを追跡するコントラクトが含まれます。 この意味で、イーサリアムは、オプティミスティック・ロールアップに対するベースレイヤー（つまり、「レイヤー1」）であると言うことができます。 -**オフチェーンの仮想マシン（VM）**：オプティミスティック・ロールアップのプロトコルを管理するコントラクトはイーサリアム上で実行されますが、ロールアップのプロトコルにおける計算の実行と状態の保存は[イーサリアム仮想マシン](/developers/docs/evm/)とは別の仮想マシン上で行われます。 このオフチェーンのVMは、アプリケーションが稼働し、状態変更が実行される場所であるため、オプティミスティック・ロールアップにおける上位レイヤー（つまり、「レイヤー2」）であると言えます。 +**オフチェーン仮想マシン (VM)**: オプティミスティック・ロールアッププロトコルを管理するコントラクトはイーサリアム上で実行されますが、ロールアッププロトコルは、[イーサリアム仮想マシン](/developers/docs/evm/)とは別の仮想マシン上で計算とステートストレージを実行します。 オフチェーンVMは、アプリケーションが存在し、ステート変更が実行される場所です。これはオプティミスティック・ロールアップにとって上位レイヤー、つまり「レイヤー2」として機能します。 -オプティミスティック・ロールアップは、イーサリアム仮想マシン（EVM）用に開発／コンパイルされたプログラムを実行するように設計されているため、オフチェーンのVMはEVMの設計仕様の多くを踏襲しています。 また、イーサリアムネットワークは、オンチェーンで計算された不正証明を用いて、オフチェーンのVMで計算された状態変更の有効性を強制することができます。 +オプティミスティック・ロールアップは、EVM用に記述またはコンパイルされたプログラムを実行するように設計されているため、オフチェーンVMには多くのEVM設計仕様が組み込まれています。 さらに、オンチェーンで計算された不正証明により、イーサリアムネットワークはオフチェーンVMで計算されたステート変更の有効性を強制することができます。 -オプティミスティック・ロールアップは、イーサリアムとは別個のプロトコルとして存在するものの、そのセキュリティ属性はイーサリアムに依存しているため、「ハイブリッド型のスケーリング・ソリューション」と呼ばれます。 特に、イーサリアムメインネットは、ロールアップにおけるオフチェーンでの計算の正しさと、この計算に用いられたデータの可用性を保証します。 このため、セキュリティをイーサリアムに依存しない、「純粋な」オフチェーンのスケーリング・プロトコル（例：[サイドチェーン](/developers/docs/scaling/sidechains/)）と比較すると、オプティミスティック・ロールアップはよりセキュリティが堅牢であると言えます。 +オプティミスティック・ロールアップは、イーサリアムとは別個のプロトコルとして存在するものの、そのセキュリティ属性はイーサリアムに依存しているため、「ハイブリッド型のスケーリング・ソリューション」と呼ばれます。 とりわけ、イーサリアムはロールアップのオフチェーン計算の正しさと、その計算の背後にあるデータの可用性を保証します。 これにより、オプティミスティック・ロールアップは、セキュリティをイーサリアムに依存しない純粋なオフチェーンスケーリングプロトコル（例：[サイドチェーン](/developers/docs/scaling/sidechains/)）よりも安全になります。 オプティミスティック・ロールアップでは、以下の事項につきイーサリアムメインネットのプロトコルに依存します： ### データ可用性 {#data-availability} -すでに述べたように、オプティミスティック・ロールアップではトランザクションのデータを`calldata`または[ブロブ](/roadmap/danksharding/)としてイーサリアムに送信します。 ロールアップチェーンは送信されたトランザクションに基づき実行されるため、イーサリアムのベースレイヤーに含まれるコールデータの情報を用いて、どのユーザーでもロールアップのステートを実行し、状態遷移の正しさを検証することができます。 +前述のように、オプティミスティック・ロールアップはトランザクションデータを`calldata`として、または[ブロブ](/roadmap/danksharding/)でイーサリアムに投稿します。 ロールアップチェーンは送信されたトランザクションに基づき実行されるため、イーサリアムのベースレイヤーに含まれるコールデータの情報を用いて、どのユーザーでもロールアップのステートを実行し、状態遷移の正しさを検証することができます。 -[データ可用性](/developers/docs/data-availability/)が重要なのは、状態データにアクセスできないと、ロールアップにおける無効な操作に異議を申し立てる際に、必要な不正証明を作成することができたいからです。 イーサリアムがデータ可用性を保証するため、ロールアップのオペレータによる悪意の行動（例：無効なブロックの送信）が見過ごされる可能性が低くなります。 +[データ可用性](/developers/docs/data-availability/)は極めて重要です。なぜなら、ステートデータにアクセスできなければ、チャレンジャーは無効なロールアップ操作に異議を唱えるための不正証明を構築できないからです。 イーサリアムがデータ可用性を保証するため、ロールアップのオペレータによる悪意の行動（例：無効なブロックの送信）が見過ごされる可能性が低くなります。 ### 検閲耐性 {#censorship-resistance} オプティミスティック・ロールアップはさらに、検閲耐性についてもイーサリアムに依存します。 オプティミスティック・ロールアップでは、中央主権型のエンティティ (オペレーター) が、トランザクションの処理とイーサリアムへのロールアップブロックを送信する役割を担います。 これは、以下のような結果をもたらします： -- ロールアップのオペレーターは、自分が完全にオフライン化するか特定のトランザクションを含むブロックの作成を拒否することで、ユーザーを検閲 できる。 +- ロールアップのオペレーターは、自分が完全にオフライン化するか特定のトランザクションを含むブロックの作成を拒否することで、ユーザーを検閲 + できる。 - ロールアップのオペレーターは、所有権のマークル証明に必要な状態データを隠匿することで、ロールアップのコントラクトに入金された資金の引き出しを停止することができる。 さらに、状態データを隠匿することでロールアップの状態を非公開にし、このロールアップとやりとりできないようにさせることができる。 -オプティミスティック・ロールアップでは、オペレーターに対し、状態更新に関連したデータをイーサリアム上で公開するように強制することで、この問題を解消します。 ロールアップのデータをオンチェーンで公開させることで、以下のような利点が実現されます： +オプティミスティック・ロールアップでは、オペレーターに対し、状態更新に関連したデータをイーサリアム上で公開するように強制することで、この問題を解消します。 ロールアップデータをオンチェーンで公開することには、以下の利点があります。 - オプティミスティック・ロールアップのオペレーターがオフラインになったりトランザクションのバッチ作成を停止した場合、他のノードは、利用可能なデータを用いてロールアップの最新状態を復元し、引き続きブロック作成を継続できる。 @@ -68,7 +69,7 @@ lang: ja オプティミスティック・ロールアップにおいてイーサリアムが担うもう一つの役割は、決済レイヤーとしての役割です。 決済レイヤーとは、ブロックチェーンのエコシステム全体の基礎となり、セキュリティを提供すると同時に、他のチェーン（本トピックにおいては、オプティミスティック・ロールアップ）における仲裁が必要な紛争に対して、客観的なファイナリティを提供します。 -イーサリアムメインネットは、オプティミスティック・ロールアップにおいて不正証明を検証し、紛争を解消するハブの役割を担います。 さらに、ロールアップで実行されたトランザクションは、ロールアップのブロックがイーサリアム上で承認された_後_でなければ確定しません。 ロールアップのトランザクションは、イーサリアムのベースレイヤーで確定した後はロールバックできなくなります（チェーンの再編成というまれなケースを除く）。 +イーサリアムメインネットは、オプティミスティック・ロールアップにおいて不正証明を検証し、紛争を解消するハブの役割を担います。 さらに、ロールアップで実行されたトランザクションは、ロールアップブロックがイーサリアム上で承認された_後_にのみ確定します。 ロールアップのトランザクションは、イーサリアムのベースレイヤーで確定した後はロールバックできなくなります（チェーンの再編成というまれなケースを除く）。 ## オプティミスティック・ロールアップは、どのように実行されるのか？ {#how-optimistic-rollups-work} @@ -76,41 +77,41 @@ lang: ja 各ユーザーは、オプティミスティック・ロールアップにおいてトランザクションの実行を担うノードである「オペレーター」にトランザクションを送信します。 オペレーターは、「バリデータ」あるいは「アグリゲータ」と呼ばれる場合もあり、複数のトランザクションを集約し、トランザクションのデータを圧縮した上で、イーサリアム上でブロックを公開します。 -すべてのユーザーがバリデータを務めることができますが、オプティミスティック・ロールアップにおけるバリデータは、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)のシステムと同様に、ブロックを作成する前にボンド（担保）を提供する必要があります。 このボンドは、バリデータが無効なブロックを送信したり、時間が経過しているが無効なブロックの上にブロックを構築した場合、（当該ブロック自体が有効であっても）没収されます。 オプティミスティック・ロールアップでは、このような暗号経済的なインセンティブを通じて、バリデータにおける正直な行動を保証しています。 +誰でもバリデータになることができますが、オプティミスティック・ロールアップのバリデータは、[プルーフ・オブ・ステークシステム](/developers/docs/consensus-mechanisms/pos/)と同様に、ブロックを生成する前にボンドを提供する必要があります。 このボンドは、バリデータが無効なブロックを送信したり、時間が経過しているが無効なブロックの上にブロックを構築した場合、（当該ブロック自体が有効であっても）没収されます。 オプティミスティック・ロールアップでは、このような暗号経済的なインセンティブを通じて、バリデータにおける正直な行動を保証しています。 オプティミスティック・ロールアップチェーン上の他のバリデータは、当該ロールアップの状態に対する各自のコピーを用いて、送信されたトランザクションを実行することが求められます。 バリデータにおける最終的な状態がオペレーターが提案した状態と異なる場合、オペレーターは不正証明の計算を開始することでチャレンジを申し立てることができます。 一部のオプティミスティック・ロールアップでは、パーミッションレスのバリデーター・システムを採用せず、単独の「シーケンサー」がチェーンを実行する場合もあります。 シーケンサーは、バリデータと同様に、トランザクションを処理し、ロールアップのブロックを作成した上で、ロールアップされたトランザクションをL1チェーン（イーサリアムメインネット）に送信します。 -シーケンサーが通常のロールアップオペレーターと異なるのは、トランザクションの順序決定に対する権限がより大きいという点です。 さらに、シーケンサーはロールアップチェーンに対する優先アクセス権を持ち、オンチェーンのコントラクトにトランザクションを送信することができる唯一のエンティティとなります。 シーケンサー以外のノード、あるいは通常のユーザーが送信したトランザクションは、シーケンサーがそれらを新規バッチに追加するまでの間は、別個のインボックス上でキューに置かれた状態になります。 +シーケンサーが通常のロールアップオペレーターと異なるのは、トランザクションの順序決定に対する権限がより大きいという点です。 また、シーケンサはロールアップチェーンへの優先アクセス権を持ち、オンチェーンコントラクトにトランザクションを送信する権限を与えられた唯一のエンティティです。 シーケンサー以外のノード、あるいは通常のユーザーが送信したトランザクションは、シーケンサーがそれらを新規バッチに追加するまでの間は、別個のインボックス上でキューに置かれた状態になります。 -#### ロールアップブロックをイーサリアムに送信する {#submitting-blocks-to-ethereum} +#### ロールアップブロックのイーサリアムへの送信 {#submitting-blocks-to-ethereum} -前述のように、オプティミスティック・ロールアップのオペレーターは、オフチェーンのトランザクションをバッチとしてバンドル化した上で、公証のためにイーサリアムに送信します。 このプロセスには、トランザクションの関連データを圧縮し、`calldata`またはブロブとしてイーサリアム上で公開する作業が含まれます。 +前述のように、オプティミスティック・ロールアップのオペレーターは、オフチェーントランザクションをバッチにバンドルし、公証のためにイーサリアムに送信します。 このプロセスには、トランザクション関連データを圧縮し、`calldata`として、またはブロブでイーサリアム上に公開することが含まれます。 -`calldata`は、スマートコントラクトにおける変更不可で非永続的な領域であり、ほぼ[メモリ](/developers/docs/smart-contracts/anatomy/#memory)と同様に動作します。 `calldata`は、ブロックチェーンの[履歴ログ](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)の一部としてオンチェーンで永続する一方で、イーサリアムの状態の一部としては保存されません。 `calldata`はイーサリアムの状態にまったく干渉しないので、状態よりもオンチェーンでのデータ保存に伴う費用が安価になります。 +`calldata`は、スマートコントラクト内の変更不可能で非永続的な領域であり、ほとんど[メモリ](/developers/docs/smart-contracts/anatomy/#memory)のように動作します。 `calldata`はブロックチェーンの[履歴ログ](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)の一部としてオンチェーンに永続化されますが、イーサリアムのステートの一部としては保存されません。 `calldata`はイーサリアムのステートのどの部分にも触れないため、オンチェーンにデータを保存するのにステートよりも安価です。 -さらに、`calldata`のキーワードは、スマートコントラクトの実行時にSolidity上の関数に引数を渡す際にも用いられます。 `calldata`は、トランザクションにおいて呼び出された関数を特定し、この関数に対する入力を任意のバイト列として保持します。 +`calldata`キーワードは、実行時にスマートコントラクト関数に引数を渡すためにSolidityでも使用されます。 `calldata`は、トランザクション中に呼び出される関数を識別し、その関数への入力を任意のバイトシーケンスの形式で保持します。 -オプティミスティック・ロールアップにおける`calldata`は、オンチェーンのコントラクトにトランザクションの圧縮データを送信するために使用されます。 ロールアップのオペレーターは、ロールアップのコントラクトに含まれる必須の関数を呼び出し、関数の引数として圧縮データを渡す方法によって新規バッチを追加します。 ロールアップに伴うコストの大部分はオンチェーン上でのデータ保存に伴うものであるため、`calldata`の使用はユーザーの手数料を軽減します。 +オプティミスティック・ロールアップの文脈では、`calldata`は圧縮されたトランザクションデータをオンチェーンコントラクトに送信するために使用されます。 ロールアップのオペレーターは、ロールアップのコントラクトに含まれる必須の関数を呼び出し、関数の引数として圧縮データを渡す方法によって新規バッチを追加します。 ロールアップにかかるコストのほとんどはオンチェーンでのデータ保存から生じるため、`calldata`を使用するとユーザー手数料が削減されます。 -この[例](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591)では、ロールアップのバッチ送信においてこのコンセプトがどのように機能するのかを確認できます。 シーケンサーが`appendSequencerBatch()`メソッドを呼び出し、`calldata`を用いて、トランザクションの圧縮データを入力として渡します。 +この概念がどのように機能するかを示すロールアップバッチ送信の[例](https://eth.blockscout.com/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591)を以下に示します。 シーケンサは`appendSequencerBatch()`メソッドを呼び出し、`calldata`を使用して圧縮されたトランザクションデータを入力として渡しました。 一部のロールアップは現在、トランザクションのバッチをイーサリアムへ投稿するのにブロブを使っています。 -ブロブは、変更不可能で非永続的(`calldata`と同様)ですが、約18日後に履歴から削除されます。 ブロブの詳細については、[ダンクシャーディング](/roadmap/danksharding)をご覧ください。 +ブロブは変更不可能で非永続的ですが（`calldata`と同様）、約18日後に履歴からプルーニング（削除）されます。 ブロブに関する詳細は、[ダンクシャーディング](/roadmap/danksharding)をご覧ください。 ### 状態コミットメント {#state-commitments} -オプティミスティック・ロールアップのステート（アカウント、残高、コントラクトのコード等）は常に、「ステートツリー」と呼ばれる[マークルツリー](/whitepaper/#merkle-trees)として構造化されます。 このマークルツリーのルート（ステートルート）は、ロールアップにおける最新の状態を参照しており、ロールアップのコントラクトにおいてハッシュ化されて保存されます。 ロールアップチェーンにおける状態遷移は常に新規のロールアップステートを生成し、オペレーターは新しいステートルートを計算することでこれにコミットします。 +いかなる時点においても、オプティミスティック・ロールアップのステート（アカウント、残高、コントラクトコードなど） は、「ステートツリー」と呼ばれる[マークルツリー](/whitepaper/#merkle-trees)として構成されています。 このマークルツリーのルート（ステートルート）は、ロールアップにおける最新の状態を参照しており、ロールアップのコントラクトにおいてハッシュ化されて保存されます。 ロールアップチェーンにおける状態遷移は常に新規のロールアップステートを生成し、オペレーターは新しいステートルートを計算することでこれにコミットします。 -オペレーターは、バッチ送信時において、新旧両方のステートルートを送信する必要があります。 古い方のステートルートがオンチェーンのコントラクトにおける既存のステートルートと一致する場合、既存のステートルートを破棄し、新しいステートルートで置き換えます。 +オペレーターは、バッチ送信時において、新旧両方のステートルートを送信する必要があります。 古いステートルートがオンチェーンコントラクト内の既存のステートルートと一致する場合、後者は破棄され、新しいステートルートに置き換えられます。 -ロールアップのオペレーターはさらに、トランザクションバッチ自体のマークルルートに対してもコミットする必要があります。 これにより、どのユーザーも、[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)を提示することでL1上のバッチに当該トランザクションが追加されていることを証明することができます。 +ロールアップのオペレーターはさらに、トランザクションバッチ自体のマークルルートに対してもコミットする必要があります。 これにより、誰でも[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)を提示することで、バッチ（L1上）にトランザクションが含まれていることを証明できます。 状態へのコミットメントは、特にステートルートの場合、オプティミスティック・ロールアップにおける状態遷移の正しさを証明するために必要です。 ロールアップのコントラクトは、オペレーターから送信された時点で新規のステートルートを受け入れますが、無効なステートルートを事後に削除し、ロールアップを正しい状態に復元することが可能です。 -### 不正証明 {#fraud-proving} +### 不正の証明 {#fraud-proving} 前述のように、オプティミスティック・ロールアップでは、どのユーザーでも有効性証明を提供せずにブロックを公開することができます。 しかし、ロールアップチェーンの安全性を維持するために、どのユーザーも状態遷移に対する異議申立を行える期間が設定されています。 どのユーザーでもブロックの正当性に対して異議を申し立てられるため、ロールアップブロックは「アサーション」（主張）と呼ばれます。 @@ -118,13 +119,13 @@ lang: ja 1回のやりとりを要求する証明スキームでは、異議申立の対象であるトランザクションをL1上で再生し、無効なアサーションを検出します。 ロールアップのプロトコルでは、異議申立の対象であるトランザクションに対するL1（イーサリアムメインネット）上での再実行につき、検証者のコントラクトを用いてエミュレートし、計算されたステートルートによりこの異議申立における勝者を決定します。 異議申立者によるロールアップの正しい状態についての主張が認められた場合、オペレーターに対してはボンドの没収（スラッシング）によるペナルティが科せられます。 -ただし、不正検出のためにL1上でトランザクションを再実行するには、個別トランザクションに対する状態コミットメントを公開しなければならないため、ロールアップがオンチェーン上で公開しなければならないデータ量が増加します。 さらに、トランザクションの再実行はかなりのガス代を伴います。 これらの理由により、オプティミスティック・ロールアップでは複数回にわたるやりとりを通じた証明に移行中であり、これにより、無効なロールアップ操作を検出するという同じ目的をより効率的に実現できるようになるでしょう。 +しかし、不正を検出するためにL1でトランザクションを再実行するには、個々のトランザクションのステートコミットメントを公開する必要があり、ロールアップがオンチェーンで公開しなければならないデータが増加します。 さらに、トランザクションの再実行はかなりのガス代を伴います。 これらの理由により、オプティミスティック・ロールアップでは複数回にわたるやりとりを通じた証明に移行中であり、これにより、無効なロールアップ操作を検出するという同じ目的をより効率的に実現できるようになるでしょう。 -#### 複数回のやりとりによる証明 {#multi-round-interactive-proving} +#### 複数ラウンドの対話型証明 {#multi-round-interactive-proving} 複数回のやりとりによる証明では、L1上の検証者コントラクトがアサーター／チャレンジャー間のやりとりのプロトコルを監視し、このコントラクトが最終的に虚偽のユーザーを決定します。 L2上のノードが特定のアサーションに対してチャレンジを行うと、このアサーションを行ったアサーターは、異議申立のアサーションを二等分しなければなりません。 これにより、二等分されたアサーションは、それぞれがもう一方のアサーションと同数の計算ステップを含むことになります。 -次にチャレンジャーが、どちらのアサーションに異議を申し立てるかを選択します。 この分割プロセス（「二分割プロトコル」と呼ぶ）は、両当事者による紛争の対象が_単独の_実行ステップに対するアサーションになるまで継続されます。 対象が単独の実行ステップになった時点で、L1上のコントラクトが不正な当事者を発見するための命令（および結果）を判定し、紛争が解決されます。 +次にチャレンジャーが、どちらのアサーションに異議を申し立てるかを選択します。 この分割プロセス（「二分割プロトコル」と呼ばれる）は、両当事者の争点が実行の_単一_ステップに関するアサーションになるまで継続されます。 対象が単独の実行ステップになった時点で、L1上のコントラクトが不正な当事者を発見するための命令（および結果）を判定し、紛争が解決されます。 アサーターは、紛争の対象であるシングルステップ計算の正当性を証明するための「ワンステップ証明」を提供しなければなりません。 アサーターがこのワンステップ証明を提供できない場合、あるいはL1上の検証者により当該証明が無効であると判定された場合、アサーターの申立は棄却されます。 @@ -132,7 +133,7 @@ lang: ja 1. 複数回のやりとりによる不正証明は、L1チェーン上における紛争仲裁の作業量を最小化できるために効率的だと考えられています。 L1チェーン上では、トランザクション全体を再生する必要はなく、ロールアップ実行における特定のステップのみを再実行すればよいからです。 -2. 二分割プロトコルは、オンチェーンに送信するデータ量を軽減します（トランザクションごとに状態コミットメントを送信する必要がないためです）。 さらに、オプティミスティック・ロールアップのトランザクションは、イーサリアムのガス上限による制限を受けません。 反対にトランザクションを再実行するオプティミスティック・ロールアップの場合は、イーサリアムメインネット上の1回のトランザクションで実行をエミュレートできるように、L2のトランザクションにおいてガス上限がより低く設定されていることを確認する必要があります。 +2. 二分割プロトコルは、オンチェーンに投稿されるデータの量を削減します（すべてのトランザクションのステートコミットを公開する必要はありません）。 さらに、オプティミスティック・ロールアップのトランザクションは、イーサリアムのガス上限による制限を受けません。 反対にトランザクションを再実行するオプティミスティック・ロールアップの場合は、イーサリアムメインネット上の1回のトランザクションで実行をエミュレートできるように、L2のトランザクションにおいてガス上限がより低く設定されていることを確認する必要があります。 3. 悪意のアサーターが提供したボンドの一部はチャレンジャーに付与され、残りはバーンされます。 残余のボンドをバーンすることで、バリデータ間の共謀を防ぐことができます。2名のバリデータが共謀して虚偽のチャレンジを開始した場合、彼らがステーキングした資産のうちかなりの部分が没収されるからです。 @@ -140,39 +141,39 @@ lang: ja #### オプティミスティック・ロールアップにおいて不正証明が重要である理由 {#fraud-proof-benefits} -不正証明は、オプティミスティック・ロールアップにおいて_トラストレスなファイナリティ_を強化する上で重要です。 トラストレスなファイナリティとは、有効なトランザクションは最終的に承認されるというオプティミスティック・ロールアップの特性を指す概念です。 +不正証明は、オプティミスティック・ロールアップにおいて_トラストを必要としないファイナリティ_を促進するため重要です。 トラストレスなファイナリティとは、有効なトランザクションは最終的に承認されるというオプティミスティック・ロールアップの特性を指す概念です。 悪意のノードは、正当なロールアップブロックに対して、虚偽のチャレンジを開始することでその正当性確認を遅延させることができます。 しかし最終的に、不正証明によりロールアップブロックの正当性が証明され、有効化されます。 -この点は同時に、正直なノードが少なくとも_1つ_存在しなければロールアップチェーンの正当性を保持できないという、オプティミスティック・ロールアップにおけるもう一つのセキュリティ特性に関連しています。 正直なノードは、有効なアサーションを送信するか、無効なアサーションに対して異議申立を行うことで、チェーンを適切に前進させることができます。 いずれの場合でも、正直なノードに対して異議を申し立てる悪意のノードは、不正証明プロセスを通じてステークを失うことになります。 +このことは、オプティミスティック・ロールアップのもう一つのセキュリティ特性にも関連しています。つまり、チェーンの有効性は_1つ_の正直なノードの存在に依存しているということです。 正直なノードは、有効なアサーションを送信するか、無効なアサーションに対して異議申立を行うことで、チェーンを適切に前進させることができます。 いずれの場合でも、正直なノードに対して異議を申し立てる悪意のノードは、不正証明プロセスを通じてステークを失うことになります。 -### L1とL2の相互運用性 {#l1-l2-interoperability} +### L1/L2の相互運用性 {#l1-l2-interoperability} -オプティミスティック・ロールアップは、イーサリアムメインネットとの相互運用性を念頭において開発されており、ユーザーはメッセージや任意のデータをL1／L2間でやりとりできます。 また、EVMとの互換性も提供されるため、既存の[Dapp](/developers/docs/dapps/)をオプティミスティック・ロールアップに移植したり、イーサリアム開発ツールを用いて新規のDappを開発することができます。 +オプティミスティック・ロールアップは、イーサリアムメインネットとの相互運用性を念頭において開発されており、ユーザーはメッセージや任意のデータをL1／L2間でやりとりできます。 また、EVMとも互換性があるため、既存の[dapps](/developers/docs/dapps/)をオプティミスティック・ロールアップに移植したり、イーサリアム開発ツールを使って新しいdappsを作成したりすることができます。 #### 1. 資産の移動 {#asset-movement} ##### ロールアップに参加する -オプティミスティック・ロールアップの利用を開始するには、当該ロールアップのL1上の[ブリッジ](/developers/docs/bridges/)コントラクトに対して、ETH、ERC-20トークン、あるいはその他の受け入れ可能な資産を入金します。 このブリッジコントラクトは、当該トランザクションをL2にリレーし、L2において同価値の資産をミントした上で、ユーザーがオプティミスティック・ロールアップで指定したアドレスにその資産を送信します。 +オプティミスティック・ロールアップを使用するには、ユーザーはL1上にあるロールアップの[ブリッジ](/developers/docs/bridges/)コントラクトに、ETH、ERC-20トークン、およびその他の承認された資産を入金します。 このブリッジコントラクトは、当該トランザクションをL2にリレーし、L2において同価値の資産をミントした上で、ユーザーがオプティミスティック・ロールアップで指定したアドレスにその資産を送信します。 -ユーザーが作成したトランザクション（L1からL2への入金など）は通常、シーケンサーがロールアップのコントラクトに再提出するまではキュー上で保留されます。 ただし、検閲耐性を維持するために、キュー保留の上限期間を超えて遅延した場合は、トランザクションをオンチェーンのロールアップコントラクトに直接送信することが認められています。 +ユーザーが生成したトランザクション（L1 > L2の入金など）は通常、シーケンサがロールアップコントラクトに再送信するまでキューに入れられます。 しかし、検閲耐性を維持するために、オプティミスティック・ロールアップでは、許可された最大時間を超えて遅延した場合、ユーザーがトランザクションをオンチェーンのロールアップコントラクトに直接送信することが許可されています。 一部のオプティミスティック・ロールアップでは、シーケンサーによるユーザーの検閲を防止するためにより明確なアプローチが採用されています。 このアプローチを採用したロールアップでは、ロールアップチェーン上で処理されたトランザクションに加えて、直前のブロック（例：入金）以降にL1上のコントラクトに送信されたすべてのトランザクションにより、ブロックが定義されます。 シーケンサーがL1上のトランザクションを無視する場合、（おそらく）正しくないステートルートを公開することになるため、シーケンサーは、ユーザーが作成したメッセージをL1に送信した以降にこれを遅延することが不可能になります。 ##### ロールアップから出金する -不正証明スキームが存在するため、オプティミスティック・ロールアップからイーサリアムに出金するプロセスはより複雑になっています。 L1にエスクローされた資金を引き出すためにL2からL1へのトランザクションを開始する場合、ユーザーは約7日間のチャレンジ期間が経過するのを待つ必要があります。 それ以外の点では、出金プロセス自体は非常にシンプルです。 +不正証明スキームが存在するため、オプティミスティック・ロールアップからイーサリアムに出金するプロセスはより複雑になっています。 ユーザーがL1でエスクローされた資金を引き出すためにL2からL1へのトランザクションを開始する場合、約7日間のチャレンジ期間が経過するまで待たなければなりません。 それ以外の点では、出金プロセス自体は非常にシンプルです。 L2上のロールアップで出金リクエストを開始すると、当該トランザクションが次のバッチに追加され、ロールアップ上のユーザー資産がバーンされます。 このバッチがイーサリアム上で公開されると、ユーザーは、ブロックに出金トランザクションが含まれることを証明するマークル証明を計算できるようになります。 その上で、遅延期間の終了と共に、L1上でトランザクションが確定し、メインネットに資金を移動させることができます。 -イーサリアムメインネットへの出金において要求される1週間の待機期間を回避するために、オプティミスティック・ロールアップのユーザーは**流動性プロバイダー**（LP）を利用することもできます。 流動性プロバイダーとは、手数料を代価として、保留されているL2からの出金に対して所有権を引き継ぎ、L1上でユーザーに資金を提供するサービスです。 +イーサリアムへの資金の引き出しに1週間待つのを避けるため、オプティミスティック・ロールアップのユーザーは**流動性プロバイダー**（LP）を利用できます。 流動性プロバイダーとは、手数料を代価として、保留されているL2からの出金に対して所有権を引き継ぎ、L1上でユーザーに資金を提供するサービスです。 流動性プロバイダーは、自ら当該チェーンを実行してユーザーの出金リクエストの正当性を確認した上で、資金を提供します。 これにより、流動性プロバイダーはこのトランザクションが最終的には承認されるとの保証（つまり、トラストレスなファイナリティ）を得ることができます。 -#### 2. EVMとの互換性 {#evm-compatibility} +#### 2. EVM互換性 {#evm-compatibility} -デベロッパーにとってのオプティミスティック・ロールアップの優位性は、[イーサリアム仮想マシン（EVM）](/developers/docs/evm/)との互換性、あるいは等価性にあります。 EVM互換のロールアップは、[イーサリアム・イエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf)の仕様に準拠しており、バイトコードの水準でEVMをサポートします。 +開発者にとって、オプティミスティック・ロールアップの利点は、[イーサリアム仮想マシン（EVM）](/developers/docs/evm/)との互換性、あるいはさらに言えば等価性です。 EVM互換のロールアップは、[イーサリアム・イエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf)の仕様に準拠しており、バイトコードレベルでEVMをサポートします。 オプティミスティック・ロールアップのEVM互換性は、次のような利点を持ちます： @@ -182,7 +183,7 @@ ii. オプティミスティック・ロールアップを使用するデベロ すでに長年にわたり検証やデバッグを通じて改善されてきたこれらのツールを活用できる点は重要です。 さらに、まったく新しい開発スタックを使って開発方法を学ぶ必要もなくなります。 -#### 3. クロスチェーンにおけるコントラクトの呼び出し {#cross-chain-contract-calls} +#### 3. クロスチェーンのコントラクト呼び出し {#cross-chain-contract-calls} ユーザー（外部所有アカウント）がL2上のコントラクトとやりとりを行うには、ロールアップ上のコントラクトにトランザクションを送信するか、あるいはこの作業をシーケンサーまたはバリデータに委任する必要があります。 オプティミスティック・ロールアップの場合はさらに、L1／L2間のメッセージのリレーやデータの受け渡しにブリッジコントラクトを使用して、L2上のコントラクトとのやりとりを行えます。 つまり、イーサリアムメインネット上のL1コントラクトにおいて、L2のオプティミスティック・ロールアップ上のコントラクトに含まれる機能を呼び出せるようにプログラムすることが可能です。 @@ -190,50 +191,50 @@ ii. オプティミスティック・ロールアップを使用するデベロ クロスチェーンのコントラクト呼び出しの例としては、上述したトークンの入金が挙げられます。 L1上のコントラクトは、ユーザーのトークンをエスクローすると共に、L2の対応したコントラクトに対して、ロールアップ上で同額のトークンをミントするように指示するメッセージを送信します。 -クロスチェーンのメッセージ呼び出しはコントラクトの実行を伴いますが、通常は、計算に伴い発生する[ガス代](/developers/docs/gas/)は送信元が負担する必要があります。 ターゲットのチェーンにおいてトランザクションが失敗するのを防ぐために、ガス代の上限を高く設定することが推奨されます。 この点については、トークンをブリッジングするシナリオを想起すればよいでしょう。トランザクションにおけるL1側の作業（トークンの入金）がうまく行っても、L2側の作業（新規トークンのミント）がガス代不足により実行されなければ、入金した資産は回収不能になります。 +クロスチェーンのメッセージ呼び出しはコントラクトの実行を伴うため、通常、送信者は計算にかかる[ガス代](/developers/docs/gas/)を負担する必要があります。 ターゲットのチェーンにおいてトランザクションが失敗するのを防ぐために、ガス代の上限を高く設定することが推奨されます。 この点については、トークンをブリッジングするシナリオを想起すればよいでしょう。トランザクションにおけるL1側の作業（トークンの入金）がうまく行っても、L2側の作業（新規トークンのミント）がガス代不足により実行されなければ、入金した資産は回収不能になります。 -最後に、複数のコントラクト間におけるL2からL1へのメッセージ呼び出しにおいては、遅延の発生を考慮する必要があります（L1からL2への呼び出しは、通常数分後に実行されます）。 オプティミスティック・ロールアップからメインネットに送信されるメッセージは、チャレンジ期間が経過するまで実行できないためです。 +最後に、コントラクト間のL2からL1へのメッセージ呼び出しは遅延を考慮する必要があることに注意してください（L1からL2への呼び出しは通常、数分後に実行されます）。 オプティミスティック・ロールアップからメインネットに送信されるメッセージは、チャレンジ期間が経過するまで実行できないためです。 ## オプティミスティック・ロールアップにおける手数料の仕組み {#how-do-optimistic-rollup-fees-work} -オプティミスティック・ロールアップでは、トランザクション1件ごとのユーザー手数料を表示するために、イーサリアムとほぼ同様のガス料金スキームを採用しています。 オプティミスティック・ロールアップで請求される手数料は、以下の要素により決定されます： +オプティミスティック・ロールアップでは、トランザクション1件ごとのユーザー手数料を表示するために、イーサリアムとほぼ同様のガス料金スキームを採用しています。 オプティミスティック・ロールアップで請求される手数料は、以下の要素によって決まります。 -1. **State write**: オプティミスティック・ロールアップでは、トランザクションデータやブロックヘッダー (前のブロックヘッダーのハッシュ、ステートルート、バッチルートを含む) を、バイナリ大規模オブジェクト、すなわち `ブロブ` としてイーサリアムに公開します。 [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) は、データをオンチェーンに含めるための費用対効果の高い解決策を導入しました。 `ブロブ` は新しいトランザクションフィールドで、ロールアップが圧縮された状態遷移データをイーサリアムL1に送信することを可能にします。 永続的にオンチェーンに残る`calldata`とは異なり、ブロブは短期的なもので、 [4096エポック](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (約18日) 後にはクライアントから削除できます。 圧縮されたトランザクションのバッチを、ブロブを使用して送信することで、オプティミスティック・ロールアップはL1へのトランザクション書き込みコストを大幅に削減することができます。 +1. **ステート書き込み**: オプティミスティック・ロールアップは、トランザクションデータとブロックヘッダー（前のブロックヘッダーのハッシュ、ステートルート、バッチルートで構成）を`blob`、つまり「バイナリラージオブジェクト」としてイーサリアムに公開します。 [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)は、データをオンチェーンに含めるための費用対効果の高い解決策を導入しました。 `blob`は、ロールアップが圧縮された状態遷移データをイーサリアムL1に投稿できるようにする新しいトランザクションフィールドです。 オンチェーンに永続的に残る`calldata`とは異なり、ブロブは短命であり、[4096エポック](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147)（約18日間）が経過するとクライアントから削除（プルーニング）される可能性があります。 圧縮されたトランザクションのバッチを、ブロブを使用して送信することで、オプティミスティック・ロールアップはL1へのトランザクション書き込みコストを大幅に削減することができます。 -2. **Blob gas used**: ブロブを含むトランザクションは、[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)で導入された動的手数料メカニズムに類似した仕組みを採用しています。 タイプ3トランザクションのガス料金は、ブロブのベースフィーを考慮に入れて計算されます。この基本料金は、ブロブスペースの需要と、送信されるトランザクションのブロブスペース使用量に基づいて、ネットワークが決定します。 +2. **ブロブガスの使用量**: ブロブを運ぶトランザクションは、[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)によって導入されたものと同様の動的な手数料メカニズムを採用しています。 タイプ3トランザクションのガス料金は、ブロブのベースフィーを考慮に入れて計算されます。この基本料金は、ブロブスペースの需要と、送信されるトランザクションのブロブスペース使用量に基づいて、ネットワークが決定します。 -3. **L2オペレーターに対する手数料**: イーサリアムにおけるガス代と同様に、トランザクション処理において発生する計算コストの代価としてロールアップのノードに支払われる報酬です。 L2は処理能力が比較的高く、イーサリアムの場合のようにネットワークの混雑によりバリデータが高額な手数料を伴うトランザクションを優先的に処理するという状況が発生していないため、ロールアップのノードが請求するトランザクション手数料は比較的安価になっています。 +3. **L2オペレーター手数料**: これは、イーサリアムのガス代と同様に、トランザクション処理で発生した計算コストの対価としてロールアップノードに支払われる金額です。 L2は処理能力が比較的高く、イーサリアムの場合のようにネットワークの混雑によりバリデータが高額な手数料を伴うトランザクションを優先的に処理するという状況が発生していないため、ロールアップのノードが請求するトランザクション手数料は比較的安価になっています。 -オプティミスティック・ロールアップにおいてユーザー手数料を引き下げるために導入されているメカニズムとしては、トランザクションのバッチ処理や、データ公開コストを軽減するための`calldata`の圧縮などがあります。 [L2手数料トラッカー](https://l2fees.info/)を使えば、イーサリアムベースのオプティミスティック・ロールアップで発生する使用手数料をリアルタイムで確認できます。 +オプティミスティック・ロールアップは、トランザクションのバッチ処理や、データ公開コストを削減するための`calldata`の圧縮など、ユーザーの手数料を削減するためのいくつかのメカニズムを適用しています。 イーサリアムベースのオプティミスティック・ロールアップの利用にかかる費用をリアルタイムで概観するには、[L2手数料トラッカー](https://l2fees.info/)を確認できます。 ## オプティミスティック・ロールアップは、どのようにイーサリアムのスケーラビリティを向上させるのか？ {#scaling-ethereum-with-optimistic-rollups} -上述したように、オプティミスティック・ロールアップでは、圧縮したトランザクションデータをイーサリアムに送信して公開することで、データの可用性を保証します。 オンチェーン上で圧縮データを公開する機能は、オプティミスティック・ロールアップを通じてイーサリアムのスループットを拡大させる上で不可欠なものです。 +上述したように、オプティミスティック・ロールアップでは、圧縮したトランザクションデータをイーサリアムに送信して公開することで、データの可用性を保証します。 オンチェーンで公開されるデータを圧縮する能力は、オプティミスティック・ロールアップでイーサリアムのスループットをスケーリングする上で極めて重要です。 -メインのイーサリアムチェーンは、各ブロックが保持できるデータ量に制限があり、これはガス単位で表示されます（[平均のブロックサイズ](/developers/docs/blocks/#block-size)は1,500万ガスです）。 これは、各トランザクションにおいて使用できるガスに上限があることを意味すると同時に、トランザクションデータの圧縮によりブロックごとに処理されるトランザクションの数を増やし、直接的にスケーラビリティを向上させられることを意味します。 +メインのイーサリアムチェーンは、ブロックが保持できるデータ量にガス単位で制限を設けています（[平均ブロックサイズ](/developers/docs/blocks/#block-size)は1500万ガスです）。 これは、各トランザクションにおいて使用できるガスに上限があることを意味すると同時に、トランザクションデータの圧縮によりブロックごとに処理されるトランザクションの数を増やし、直接的にスケーラビリティを向上させられることを意味します。 -オプティミスティック・ロールアップでは、トランザクションデータを圧縮し、TPSレートを向上させる上で、いくつかの手法を用いています。 例えば この[記事](https://vitalik.eth.limo/general/2021/01/05/rollup.html)では、メインネット上の基本的なユーザートランザクション （Etherの送信）で生成されるデータ量と、ロールアップ上で同一のトランザクションが生成するデータ量を比較しています： +オプティミスティック・ロールアップでは、トランザクションデータを圧縮し、TPSレートを向上させる上で、いくつかの手法を用いています。 例えば、この[記事](https://vitalik.eth.limo/general/2021/01/05/rollup.html)では、基本的なユーザートランザクション（Etherの送信）がメインネットで生成するデータと、同じトランザクションがロールアップで生成するデータ量を比較しています。 -| パラメータ | イーサリアム (L1) | ロールアップ (L2) | -| ------ | ------------ | ----------- | -| ノンス | 〜3 | 0 | -| ガス価格 | 〜8 | 0～0.5 | -| ガス | 3 | 0～0.5 | -| To | 21 | 4 | -| 値 | 9 | 約3 | -| 署名 | 〜68（2+33+33） | 〜0.5 | -| From | 0（署名から復元） | 4 | -| **合計** | **約112バイト** | **約12バイト** | +| パラメータ | イーサリアム (L1) | ロールアップ (L2) | +| ------ | ------------------------------ | ------------------------------ | +| ノンス | 〜3 | 0 | +| ガス価格 | 〜8 | 0～0.5 | +| ガス | 3 | 0～0.5 | +| To | 21 | 4 | +| 値 | 9 | 〜3 | +| 署名 | 〜68（2+33+33） | 〜0.5 | +| From | 0（署名から復元） | 4 | +| **合計** | **~112バイト** | **~12バイト** | これらの数値を基にした大まかな計算により、オプティミスティック・ロールアップがどの程度スケーラビリティに貢献するのかを知ることができます： -1. 各ブロックのターゲットサーイズは1,500万ガスで、1バイトのデータ検証には16ガスが必要です。 平均ブロックサイズを16ガスで割ると (15,000,000/16) 、平均サイズのブロックは**937,500バイトのデータを保持できる**ことになります。 -2. ロールアップにおける基本的なトランザクションが12バイトを使用する場合、イーサリアムの平均的なブロックは**78,125件のロールアップ・トランザクション**あるいは**39件のロールアップバッチ**（各バッチが平均2,000件のトランザクションを持つ場合）を処理できます。 -3. イーサリアムで15秒ごとに新しいブロックが生成されるとすると、ロールアップの処理速度は、**1秒間に約5,208件のトランザクション**に相当します。 これは、イーサリアムにおける1つのブロックが保持できる基本的なロールアップのトランザクション数（**78,125**）を平均のブロック時間（**15秒**）で割ることで算出できます。 +1. 各ブロックのターゲットサーイズは1,500万ガスで、1バイトのデータ検証には16ガスが必要です。 平均ブロックサイズを16ガスで割ると（15,000,000/16）、平均ブロックは**937,500バイトのデータ**を保持できることがわかります。 +2. 基本的なロールアップトランザクションが12バイトを使用する場合、平均的なイーサリアムブロックは**78,125件のロールアップトランザクション**（937,500/12）、または**39件のロールアップバッチ**（各バッチが平均2,000件のトランザクションを保持する場合）を処理できます。 +3. イーサリアムで15秒ごとに新しいブロックが生成されるとすると、ロールアップの処理速度は1秒間に約**5,208件のトランザクション**に相当します。 これは、イーサリアムブロックが保持できる基本的なロールアップトランザクションの数（**78,125**）を平均ブロック時間（**15秒**）で割ることで計算されます。 イーサリアム上のブロック全体がすべてオプティミスティック・ロールアップのトランザクションである可能性はないため、この数値はかなり楽観的な推測です。 しかし、オプティミスティック・ロールアップによってイーサリアムのユーザーどれだけスケーラビリティを獲得できるかについて、おおよその見当をつけることができます（現在の実装では最大2,000TPSを実現しています）。 -イーサリアムに[データシャーディング](/roadmap/danksharding/)が導入されると、オプティミスティック・ロールアップのスケーラビリティも向上すると期待されています。 ロールアップ上のトランザクションは、ロールアップ以外の他のトランザクションとブロックスペースを共有しなければならないため、メインのイーサリアムチェーンにおけるデータのスループットにより処理能力が制限されます。 ダンクシャーディングでは、高価で永続的な`CALLDATA`の代わりに、安価で非永続的な 「ブロブ」 ストレージを使用して、ブロックごとにデータを公開します。そのために、L2チェーンが利用できるスペースを増やします。 +イーサリアムに[データシャーディング](/roadmap/danksharding/)が導入されると、オプティミスティック・ロールアップのスケーラビリティが向上すると期待されています。 ロールアップ上のトランザクションは、ロールアップ以外の他のトランザクションとブロックスペースを共有しなければならないため、メインのイーサリアムチェーンにおけるデータのスループットにより処理能力が制限されます。 ダンクシャーディングは、高価で永続的な`CALLDATA`の代わりに、より安価で非永続的な「ブロブ」ストレージを使用して、ブロックごとにデータを公開するためにL2チェーンが利用できるスペースを増やします。 ### オプティミスティック・ロールアップの長所と短所 {#optimistic-rollups-pros-and-cons} @@ -244,20 +245,22 @@ ii. オプティミスティック・ロールアップを使用するデベロ | 不正証明により、トラストレスなファイナリティが保証され、少数の正直なユーザーによりチェーンのセキュリティを保護できる。 | 正直なノードが存在しない場合、悪意のオペレーターが無効なブロックや状態コミットメントを送信することで資金を盗み取れる。 | | 特別なハードウェアを必要とする有効性証明（ゼロ知識ロールアップで用いる）とは異なり、不正証明の計算はL2上の通常ノードが実行できる。 | 少なくとも1つの正直なノードがロールアップのトランザクションを実行し、不正証明を送信して無効な状態遷移に異議を申し立てるというセキュリティモデルに依存している。 | | トラストレスなライブネスによる利益がある（つまり、どのユーザーでもトランザクションを実行し、アサーションを送信することでチェーンを前に進められる）。 | イーサリアムに資金が出金されるまでに、1週間のチャレンジ期間が必要になる。 | -| チェーンのセキュリティを強化するために、よく設計された暗号経済的なインセンティブを導入している。 | すべてのトランザクションデータをオンチェーンに送信しなければならないため、費用がかさむ可能性がある。 | +| チェーンのセキュリティを強化するために、よく設計された暗号経済的なインセンティブを導入している。 | ロールアップはすべてのトランザクションデータをオンチェーンに投稿する必要があり、これによりコストが増加する可能性があります。 | | EVMおよびSolidityとの互換性により、イーサリアムのネイティブスマートコントラクトをロールアップに移植したり、既存ツールを用いて新たなDappを構築できる。 | | -### オプティミスティック・ロールアップに関する説明動画 {#optimistic-video} +### オプティミスティック・ロールアップの視覚的な説明 {#optimistic-video} -映像で学びたい方は、 Finematicsによるオプティミスティック・ロールアップの説明をご覧ください： +映像で学びたい場合 Finematicsによるオプティミスティック・ロールアップの説明をご覧ください： ## オプティミスティック・ロールアップに関する参考文献 - [オプティミスティック・ロールアップの仕組み（完全ガイド）](https://www.alchemy.com/overviews/optimistic-rollups) -- [ブロックチェーンにおけるロールアップとは何か？ 技術ガイド](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) -- [Arbitrumの基本ガイド](https://www.bankless.com/the-essential-guide-to-arbitrum) -- [Optimismのロールアップはどのように機能するのか？](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) -- [OVMの詳細を学ぶ](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) -- [オプティミスティック仮想マシンとは何か？](https://www.alchemy.com/overviews/optimistic-virtual-machine) +- [ブロックチェーン・ロールアップとは何か？ 技術的な紹介](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) +- [Arbitrumの必須ガイド](https://www.bankless.com/the-essential-guide-to-arbitrum) +- [イーサリアム・ロールアップの実践ガイド](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [イーサリアムL2における不正証明の現状](https://web.archive.org/web/20241124154627/https://research.2077.xyz/the-state-of-fraud-proofs-in-ethereum-l2s) +- [Optimismのロールアップは実際にどのように機能するのか？](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) +- [OVMの詳細解説](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) +- [オプティミスティック仮想マシンとは？](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git a/public/content/translations/ja/developers/docs/scaling/plasma/index.md b/public/content/translations/ja/developers/docs/scaling/plasma/index.md index 9de08249b3c..78d8fb69020 100644 --- a/public/content/translations/ja/developers/docs/scaling/plasma/index.md +++ b/public/content/translations/ja/developers/docs/scaling/plasma/index.md @@ -1,32 +1,32 @@ --- -title: プラズマチェーン -description: 現在、イーサリアムコミュニティで活用されているスケーリング・ソリューションとしてのプラズマチェーンを紹介する。 +title: "プラズマチェーン" +description: "現在、イーサリアムコミュニティで活用されているスケーリング・ソリューションとしてのプラズマチェーンを紹介する。" lang: ja incomplete: true sidebarDepth: 3 --- -プラズマチェーンとは、イーサリアムメインネットに固定されているものの、独自のメカニズムに基づいてブロックを検証し、オフチェーンでトランザクションを実行するメインネットとは別個のブロックチェーンです。 ブラズマチェーンは「子チェーン」と呼ばれる場合もあり、基本的にはイーサリアムメインネットの小規模なコピーだと言えるでしょう。 プラズマチェーンは、（[オプティミスティックロールアップ](/developers/docs/scaling/optimistic-rollups/)をはじめとする）[不正証明](/glossary/#fraud-proof)のメカニズムを用いて、紛争を仲裁します。 +プラズマチェーンとは、イーサリアムメインネットに固定されているものの、独自のメカニズムに基づいてブロックを検証し、オフチェーンでトランザクションを実行するメインネットとは別個のブロックチェーンです。 ブラズマチェーンは「子チェーン」と呼ばれる場合もあり、基本的にはイーサリアムメインネットの小規模なコピーだと言えるでしょう。 プラズマチェーンは、([オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)のように) [不正証明](/glossary/#fraud-proof)を使用して紛争を仲裁します。 マークルツリーは、 (イーサリアムメインネットを含む) 親チェーンから帯域幅をオフロードするために、これらの子チェーンを無限にスタックすることができるものです。 しかし、これらの子チェーンは、セキュリティの一部を（不正証明を通じて）イーサリアムが保証するため、子チェーンにおけるセキュリティおよび効率性はいくつかの設計上の制限により影響を受けます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -イーサリアムに関するすべての基本的なトピックおよび、[イーサリアムにおけるスケーリング](/developers/docs/scaling/)についてよく理解しておく必要があります。 +すべての基礎的なトピックを十分に理解し、[イーサリアムのスケーリング](/developers/docs/scaling/)の概要を理解している必要があります。 ## プラズマチェーンとは何か -プラズマチェーンは、イーサリアムをはじめとするパブリックブロックチェーンにおけるスケーラビリティを向上させるためのフレームワークです。 当初の[プラズマのホワイトペーパー](http://plasma.io/plasma.pdf)で述べられている通り、プラズマのチェーンは、他のブロックチェーン（「ルートチェーン」と呼ぶ）の上に構築されます。 これらの「子チェーン」はそれぞれ、ルートチェーンを拡張するものであり、一般的には親チェーン上でデプロイされたスマートコントラクトによって管理されます。 +プラズマチェーンは、イーサリアムをはじめとするパブリックブロックチェーンにおけるスケーラビリティを向上させるためのフレームワークです。 オリジナルの[プラズマのホワイトペーパー](http://plasma.io/plasma.pdf)で説明されているように、プラズマチェーンは別のブロックチェーン(「ルートチェーン」と呼ばれる)の上に構築されます。 これらの「子チェーン」はそれぞれ、ルートチェーンを拡張するものであり、一般的には親チェーン上でデプロイされたスマートコントラクトによって管理されます。 -プラズマコントラクトの機能とひとつとして、イーサリアムメインネットとプラズマチェーン間の資産移動において[ブリッジ](/developers/docs/bridges/)の役割を果たすことが挙げられます。 この機能は、[サイドチェーン](/developers/docs/scaling/sidechains/)に類似していますが、プラズマチェーンでは、少なくとも部分的にイーサリアムメインネットのセキュリティを利用できるという点が異なります。 一方サイドチェーンでは、セキュリティを単独で担う必要があります。 +プラズマコントラクトは、とりわけ、ユーザーがイーサリアムメインネットとプラズマチェーンの間で資産を移動できるようにする[ブリッジ](/developers/docs/bridges/)として機能します。 この点では[サイドチェーン](/developers/docs/scaling/sidechains/)に似ていますが、プラズマチェーンは、少なくともある程度は、イーサリアムメインネットのセキュリティから恩恵を受けます。 一方サイドチェーンでは、セキュリティを単独で担う必要があります。 ## プラズマはどのように機能するか？ プラズマフレームワークの基本的なコンポーネントには、以下が含まれます： -### オフチェーンでの計算 {#off-chain-computation} +### オフチェーンでの計算 {#offchain-computation} -イーサリアムにおける現在の処理速度は、毎秒15〜20トランザクションが限界であり、短期的により多くのユーザーに対応するためのスケーラビリティが実現できる見通しは低いと言わざるを得ません。 この問題は主に、イーサリアムの[コンセンサス・メカニズム](/developers/docs/consensus-mechanisms/)では、ブロックチェーンの状態更新が発生するたびに、多くのノードがピアツーピアで検証しなければならないためです。 +イーサリアムにおける現在の処理速度は、毎秒15〜20トランザクションが限界であり、短期的により多くのユーザーに対応するためのスケーラビリティが実現できる見通しは低いと言わざるを得ません。 この問題は主に、イーサリアムの[コンセンサス・メカニズム](/developers/docs/consensus-mechanisms/)が、ブロックチェーンの状態が更新されるたびに、多数のピアツーピア・ノードによる検証を必要とするために存在します。 イーサリアムのコンセンサス・メカニズムはセキュリティを維持する上で必要ですが、あらゆるユースケースで必須なわけではありません。 例えば、アリスがボブに対して毎日1杯のコーヒー代を支払うという取引の場合、二人の間には一定の信頼関係があるため、イーサリアムのネットワーク全体でこれを検証する必要はないでしょう。 @@ -34,27 +34,27 @@ sidebarDepth: 3 プラズマチェーンでは、処理速度とコストを最適化するためにオフチェーンでの計算が必須になります。 例えば、大部分のプラズマチェーンでは、トランザクションの順位付けと実行を管理する役割を、1名の「オペレーター」に担わせています。 トランザクションを検証する役割を1つのエンティティのみに負わせることで、プラズマチェーンは処理時間をメインネットよりも短縮できるのです。 -### ステートコミットメント {#state-commitments} +### 状態コミットメント {#state-commitments} -プラズマでは、トランザクションをオフチェーンで実行するものの、その決済はメインのイーサリアム実行レイヤーで行います。後者が存在しなければ、プラズマチェーンはイーサリアムによるセキュリティ保証を活用できないためです。 しかし、プラズマチェーンの状態を把握せずにオフチェーンのトランザクションをファイナライズする場合は、このセキュリティモデルが破綻し、無効なトランザクションが横行してしまうでしょう。 このため、プラズマチェーンにおけるブロック生成の責任を負うエンティティであるオペレーターは、定期的に、イーサリアムに「状態コミットメント」を書き込む必要があります。 +プラズマはオフチェーンでトランザクションを実行しますが、メインのイーサリアム実行レイヤーで決済されます。そうでなければ、プラズマチェーンはイーサリアムのセキュリティ保証から恩恵を受けることはできません。 しかし、プラズマチェーンの状態を把握せずにオフチェーンのトランザクションをファイナライズする場合は、このセキュリティモデルが破綻し、無効なトランザクションが横行してしまうでしょう。 このため、プラズマチェーンにおけるブロック生成の責任を負うエンティティであるオペレーターは、定期的に、イーサリアムに「状態コミットメント」を書き込む必要があります。 -[コミットメント・スキーム](https://en.wikipedia.org/wiki/Commitment_scheme)とは、他の当事者に値やステートメントを提示せずに、それにコミットする暗号学的な技術です。 このようなコミットメントは、コミットした後は値やステートメントが改変できなくなるという意味で「拘束力」を持ちます。 プラズマチェーンにおける状態コミットメントは、「マークルルート」（[マークルツリー](/whitepaper/#merkle-trees)から派生したルート）の形式を用います。オペレーターは、イーサリアムチェーン上のプラズマコントラクトに対し、定期的にこのマークルルートを送信します。 +[コミットメント・スキーム](https://en.wikipedia.org/wiki/Commitment_scheme)とは、値やステートメントを相手に明かすことなく、それにコミットするための暗号技術です。 このようなコミットメントは、コミットした後は値やステートメントが改変できなくなるという意味で「拘束力」を持ちます。 プラズマにおける状態コミットメントは、「マークルルート」([マークルツリー](/whitepaper/#merkle-trees)から派生)の形式を取ります。このマークルルートは、オペレーターがイーサリアムチェーン上のプラズマコントラクトに定期的に送信します。 -マークルルートとは、大容量の情報を圧縮することができる暗号プリミティブです。 マークルルート（この文脈では「ブロックルート」とも呼びます）は、ひとつのブロックに含まれるすべてのトランザクションを表すことができます。 また、マークルルートを用いることで、あるデータセットの小規模な一部分に基づき全体を簡単に検証することができます。 例えばユーザーは、[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content)を生成して、対象のトランザクションが特定のブロックに追加されたことを証明することができます。 +マークルルートとは、大容量の情報を圧縮することができる暗号プリミティブです。 マークルルート（この文脈では「ブロックルート」とも呼びます）は、ひとつのブロックに含まれるすべてのトランザクションを表すことができます。 また、マークルルートを用いることで、あるデータセットの小規模な一部分に基づき全体を簡単に検証することができます。 例えば、ユーザーは特定のブロックにトランザクションが含まれていることを証明するために、[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content)を作成できます。 -マークルルートは、オフチェーンの状態についての情報をイーサリアムに提供する上で重要な役割を果たします。 マークルルートは、「特定の時点で保存したもの」と考えることができます。オペレーターは、「これがＸ時点におけるプラズマチェーンの状態であり、これがその証拠であるマークルルートです」とメインネットに伝えるのです。 オペレーターは、マークルルートによってプラズマチェーンの_現在の状態_にコミットすることになるので、これを「状態コミットメント」と呼びます。 +マークルルートは、オフチェーンの状態についての情報をイーサリアムに提供する上で重要な役割を果たします。 マークルルートは、「特定の時点で保存したもの」と考えることができます。オペレーターは、「これがＸ時点におけるプラズマチェーンの状態であり、これがその証拠であるマークルルートです」とメインネットに伝えるのです。 オペレーターは、マークルルートでプラズマチェーンの_現在の状態_にコミットしています。これが「状態コミットメント」と呼ばれる理由です。 -### プラズマチェーンへの参加と退出 {#entries-and-exits} +### エントリーとエグジット {#entries-and-exits} イーサリアムのユーザーがプラズマを活用するには、メインネットとプラズマチェーン間の資金移動を管理するメカニズムが必要になります。 しかし、プラズマチェーン上の任意のアドレスにイーサを送金することはできません。プラズマチェーンは他のチェーンとの資金移動に対応していないため、トランザクションは失敗するか、資金が失われることになります。 プラズマチェーンでは、ユーザーの参入および退出を処理するために、イーサリアム上で実行されるマスターコントラクトを使用します。 このマスターコントラクトは同時に、（上述の）状態コミットメントを追跡し、不正証明（以下を参照）により悪意の行為を罰する役割も担っています。 -#### プラズマチェーンに参加するには {#entering-the-plasma-chain} +#### プラズマチェーンへのエントリー {#entering-the-plasma-chain} ユーザー（以下では、アリスと呼びます）がプラズマチェーンに参加するには、プラズマコントラクトにETHあるいはその他のERC-20トークンを入金する必要があります。 コントラクトへの入金を監視するプラズマのオペレーターは、アリスが初回に行った入金と同額を作成し、プラズマチェーン上のアリスのアドレスにリリースします。 アリスは、プラズマチェーン（子チェーン）上でこの資金を受け取ったことを確認することが義務付けられており、その上で、他のトランザクションでこの資金を使うことができます。 -#### プラズマチェーンから退出するには {#exiting-the-plasma-chain} +#### プラズマチェーンからのエグジット {#exiting-the-plasma-chain} プラズマチェーンからの退出プロセスは、いくつかの理由により参加時よりも複雑です。 最大の理由は、イーサリアムは当該プラズマチェーンの状態について情報を持つものの、その情報が正しいかどうか検証できないためです。 つまり、悪意のユーザーは、正しくない主張（「私は1,000 ETHを所有している」）と述べて、この主張を裏付けるために虚偽の証明を提出することで詐欺を働くことができるのです。 @@ -62,15 +62,15 @@ sidebarDepth: 3 しかし通常のケースでは、ユーザーは正直に行動し、自分が所有する資金について正しい主張を行います。 この場合、アリスは、プラズマコントラクトにトランザクションを送信することで、ルートチェーン（イーサリアム）に対する出金リクエストを開始します。 -アリスは同時に、プラズマチェーン上で資金を作成するトランザクションが、特定のブロックに追加されていることを証明するマークル証明を提出しなければなりません。 これは、[未使用トランザクションのアウトプット（UTXO）](https://en.wikipedia.org/wiki/Unspent_transaction_output)モデルを採用した[プラズマMVP](https://www.learnplasma.org/en/learn/mvp.html)など、プラズマのさまざまな開発サイクルにおいて必要になります。 +アリスは同時に、プラズマチェーン上で資金を作成するトランザクションが、特定のブロックに追加されていることを証明するマークル証明を提出しなければなりません。 これは、[未使用トランザクションアウトプット(UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output)モデルを使用する[Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html)のような、プラズマのイテレーションに必要です。 -[プラズマキャッシュ](https://www.learnplasma.org/en/learn/cash.html)などその他のプラズマでは、UTXOではなく、[非代替性トークン（NFT）](/developers/docs/standards/tokens/erc-721/)として資金を表示します。 この場合、資金を引き出すには、プラズマチェーン上でトークンを所有していることを証明しなければなりません。 この証明は、当該トークンにおける最新の2回のトランザクションを送信し、同時にこれらのトランザクションがブロックに追加されたことを証明するマークル証明を提出することで行います。 +[Plasma Cash](https://www.learnplasma.org/en/learn/cash.html)のような他のものは、UTXOの代わりに[非代替性トークン](/developers/docs/standards/tokens/erc-721/)として資金を表します。 この場合、資金を引き出すには、プラズマチェーン上でトークンを所有していることを証明しなければなりません。 この証明は、当該トークンにおける最新の2回のトランザクションを送信し、同時にこれらのトランザクションがブロックに追加されたことを証明するマークル証明を提出することで行います。 ユーザーはさらに、自らの正直な行動を保証するために、出金リクエストにボンド（担保）を預け入れる必要があります。 異議申立を通じてアリスの出金リクエストが無効であることが証明された場合、アリスのボンドは没収され、その一部は異議申立を行ったユーザーに報酬として提供されます。 このチャレンジ期間において不正証明が提出されなかった場合、アリスの出金リクエストは正当だと見なされ、アリスはプラズマコントラクト上の資金をイーサリアムに移動することができます。 -### 紛争仲裁のメカニズム {#dispute-arbitration} +### 紛争の仲裁 {#dispute-arbitration} あらゆるブロックチェーンと同様に、プラズマチェーンにおいても、参加ユーザーが悪意で行動した場合（資金の二重支出など）にトランザクションのインテグリティを強制するためのメカニズムが必要になります。 これを実現するために、プラズマチェーンでは不正証明を用いて、状態遷移の正しさに関する紛争を仲裁し、悪意の行動を罰しています。 不正証明は、あるプラズマ子チェーンが親チェーンまたはルートチェーンに対して苦情を申し立てるメカニズムとして用いられます。 @@ -80,17 +80,17 @@ sidebarDepth: 3 ボブの異議申立が認められると、アリスの出金リクエストは却下されます。 しかしこのアプローチでは、ボブは常にチェーン上の出金リクエストを監視しなければなりません。 ボブがオフラインであれば、アリスはチャレンジ期間の終了後に悪意の引き出しを実行できてしまうのです。 -## プラズマチェーンからの大量退出の問題 {#the-mass-exit-problem-in-plasma} +## プラズマにおける集団エグジット問題 {#the-mass-exit-problem-in-plasma} -大量退出の問題とは、特定のプラズマチェーンから大量のユーザーが同時に出金しようとする際に発生する問題を指します。 これがなぜ発生するかは、プラズマにおける最大の問題点のひとつである**データの可用性がない**ことに由来しています。 +大量退出の問題とは、特定のプラズマチェーンから大量のユーザーが同時に出金しようとする際に発生する問題を指します。 この問題が存在する理由は、プラズマの最大の問題点の1つである**データの可用性がないこと**と関係があります。 データの可用性とは、提案されたブロックの情報が実際にブロックチェーンネットワークで公開されていることを検証する能力を指します。 ブロックの生成者が当該ブロック自体を公開しているが、ブロック生成に用いたデータを秘匿する場合、このブロックは「可用性がない」ことになります。 -ノードがブロックをダウンロードし、トランザクションの有効性を検証するためには、ブロックの可用性が必須です。 すべてのブロックチェーンでは、ブロックの生成者に対して、すべてのトランザクションデータをオンチェーンに送信するように強制することでデータの可用性を実現しています。 +ノードがブロックをダウンロードし、トランザクションの有効性を検証するためには、ブロックの可用性が必須です。 ブロックチェーンは、ブロック生産者にすべてのトランザクションデータをオンチェーンに投稿させることで、データの可用性を確保します。 -データの可用性は同時に、イーサリアムのベースレイヤー上で展開されるオフチェーンのスケーリング・プロトコルにおけるセキュリティを保証するためにも有用です。 オフチェーンのオペレーターに対してトランザクションデータをイーサリアム上で公開するように強制することで、どのユーザーも、チェーンの正しい状態を参照した不正証明を作成して無効なブロックに異議を申し立てることができるのです。 +データの可用性は、イーサリアムのベースレイヤー上に構築されるオフチェーンのスケーリング・プロトコルのセキュリティ保護にも役立ちます。 オフチェーンのオペレーターに対してトランザクションデータをイーサリアム上で公開するように強制することで、どのユーザーも、チェーンの正しい状態を参照した不正証明を作成して無効なブロックに異議を申し立てることができるのです。 -プラズマチェーンでは、トランザクションデータの保存は主にオペレーターが実行するため、**メインネット上ではデータは公開されません**（定期的に実行される状態コミットメントは例外です）。 つまりユーザーは、トランザクションが無効であると主張するために不正証明を作成する必要がある場合、オペレーターが提供するブロックデータに依存せざるを得ません。 このシステムが正常に機能すれば、ユーザーは常に不正証明を用いて資金の安全性を維持できます。 +プラズマチェーンは、主にオペレーターがトランザクションデータを保存し、**メインネットには一切データを公開しません**(定期的な状態コミットメントは例外です)。 つまりユーザーは、トランザクションが無効であると主張するために不正証明を作成する必要がある場合、オペレーターが提供するブロックデータに依存せざるを得ません。 このシステムが正常に機能すれば、ユーザーは常に不正証明を用いて資金の安全性を維持できます。 しかし、単なるユーザーではなく、オペレーター自体が悪意の当事者である場合に問題が発生します。 オペレーターは、当該ブロックチェーンに対して単独で管理権を持つため、チェーン上の他のユーザーに帰属する資金を盗み取るなど、より大規模に無効な状態遷移を進めたいと考えるインセンティブがより大きくなるのです。 @@ -98,41 +98,41 @@ sidebarDepth: 3 ですから、最も楽天的な解決策は、当該プラズマチェーンのユーザーを「大量退出」させることでしょう。 大量のユーザーを一挙に退出させることで、悪意のオペレーターにおける資金窃盗の試みを遅延させ、ユーザーに対する一定の保護策を講じることができます。 出金リクエストは、個々のUTXO（またはトークン）が作成された時点に基づいて順番付けられるため、悪意のオペレーターが正直なユーザーのトランザクションを先回りして実行することはできません。 -それでもなお、無効な出金処理に伴う混乱に乗じて利益を得ようとする機会主義的なユーザーの発生を防ぐためには、大量退出時における出金リクエストについても検証できる方法が必要になります。 これは、出金を求める各ユーザーに対して、**有効であるチェーンの最後の状態**を送信することを義務付けるというシンプルな方法で解決できます。 +それでもなお、無効な出金処理に伴う混乱に乗じて利益を得ようとする機会主義的なユーザーの発生を防ぐためには、大量退出時における出金リクエストについても検証できる方法が必要になります。 解決策はシンプルです。ユーザーが出金するには、チェーンの最後の**有効な状態**を投稿することを要求します。 このアプローチでも、すべて問題が解決されたわけではありません。 例えば、あるプラズマチェーンに参加している全ユーザーの退出が必要な場合（オペレーターが悪意の行為を行う場合は発生する可能性があります）、このプラズマチェーンの有効な状態全体を、イーサリアムのベースレイヤーに同時にダンプしなければなりません。 プラズマチェーンのサイズが任意であり（高スループット＝データ量が多い）、イーサリアムでは処理速度に限界があることを考えると、このソリューションは理想的ではありません。 この退出アプローチは理論的には妥当ですが、現実的にはイーサリアムのネットワーク全体における大渋滞を引き起こすでしょう。 イーサリアムの機能が損なわれるばかりか、大規模なユーザー退出がうまく連携されていない場合、各ユーザーが自らの資金を引き出す前に、オペレーターが当該プラズマチェーンのすべてのアカウントにおける残高を奪い取ってしまう可能性があります。 -## プラズマチェーンの長所と短所 {#pros-and-cons-of-plasma} +## プラズマの長所と短所 {#pros-and-cons-of-plasma} -| 長所 | 短所 | -| -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -| 高スループットおよびトランザクションあたりの低コスト。 | 汎用的な計算をサポートしない（スマートコントラクトを実行できない）。 述語論理により、基本的なトークンの転送、スワップ、およびその他数種類のトランザクションタイプのみに対応しています。 | -| 任意のユーザー間の取引に適している（プラズマチェーン上で設定されたユーザーペア間においては、間接費用が発生しない）。 | 資金の安全性を保護するには、ネットワークを定期的に監視する（ライブネス要件）か、この役割を特定のユーザーに委任する必要がある。 | -| メインチェーンとは無関係の具体的なユースケースで活用するために導入できる。 企業を含むあらゆるユーザーが、プラズマ上のスマートコントラクトをカスタマイズすることで、様々な文脈に合わせたスケーラブルなインフラを実現できる。 | データの保存およびリクエストによる提供につき、1名あるいは複数のオペレーターに依存する。 | -| 計算およびストレージをオフチェーンに移動させることで、イーサリアムメインネットの負荷を軽減する。 | チャレンジ期間が設けられているため、出金プロセスは数日を要する。 この遅延は、代替可能資産であれば流動性プロバイダーが軽減できるが、それに伴って資本コストが発生する。 | -| | 大量のユーザーが一気に退出を求める場合、イーサリアムメインネットの混雑が予想される。 | +| 長所 | 短所 | +| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | +| 高スループットおよびトランザクションあたりの低コスト。 | 汎用的な計算はサポートしていません(スマートコントラクトは実行できません)。 述語論理により、基本的なトークンの転送、スワップ、およびその他数種類のトランザクションタイプのみに対応しています。 | +| 任意のユーザー間の取引に適している（プラズマチェーン上で設定されたユーザーペア間においては、間接費用が発生しない）。 | 資金の安全性を保護するには、ネットワークを定期的に監視する（ライブネス要件）か、この役割を特定のユーザーに委任する必要がある。 | +| メインチェーンとは無関係の具体的なユースケースで活用するために導入できる。 企業を含むあらゆるユーザーが、プラズマ上のスマートコントラクトをカスタマイズすることで、様々な文脈に合わせたスケーラブルなインフラを実現できる。 | データの保存およびリクエストによる提供につき、1名あるいは複数のオペレーターに依存する。 | +| 計算およびストレージをオフチェーンに移動させることで、イーサリアムメインネットの負荷を軽減します。 | チャレンジ期間が設けられているため、出金プロセスは数日を要する。 この遅延は、代替可能資産であれば流動性プロバイダーが軽減できるが、それに伴って資本コストが発生する。 | +| | 大量のユーザーが一気に退出を求める場合、イーサリアムメインネットの混雑が予想される。 | -## プラズマチェーンとレイヤー2のスケーリング・プロトコルとの比較 {#plasma-vs-layer-2} +## プラズマとレイヤー2スケーリング・プロトコルの比較 {#plasma-vs-layer-2} -プラズマは、以前はイーサリアムに対する有益なスケーリング・ソリューションだと考えられていましたが、現在では[レイヤー2（L2）のスケーリング・プロトコル](/layer-2/)に取って代わられています。 L2のスケーリング・ソリューションは、プラズマチェーンにおけるいくつかの問題点を解消しています： +プラズマは、以前はイーサリアムに対する有益なスケーリングソリューションだと考えられていましたが、現在では[レイヤー2(L2)スケーリングプロトコル](/layer-2/)に取って代わられています。 L2のスケーリング・ソリューションは、プラズマチェーンにおけるいくつかの問題点を解消しています： ### 効率性 {#efficiency} -[ゼロ知識ロールアップ](/developers/docs/scaling/zk-rollups)では、オフチェーンで処理された各トランザクションバッチを検証するために、暗号学的な証明を生成することができます。 これにより、ユーザー（およびオペレーター）が無効な状態遷移を進めることができなくなるため、チャレンジ期間や退出ゲームを実行する必要がなくなります。 さらにユーザーは、資金の安全性を保護するために定期的にチェーンを監視する必要がなくなります。 +[ゼロ知識ロールアップ](/developers/docs/scaling/zk-rollups)は、オフチェーンで処理されたトランザクションの各バッチの有効性について、暗号学的証明を生成します。 これにより、ユーザー（およびオペレーター）が無効な状態遷移を進めることができなくなるため、チャレンジ期間や退出ゲームを実行する必要がなくなります。 さらにユーザーは、資金の安全性を保護するために定期的にチェーンを監視する必要がなくなります。 -### スマートコントラクトへのサポート {#support-for-smart-contracts} +### スマートコントラクトのサポート {#support-for-smart-contracts} -プラズマのフレームワークにおけるもう一つの問題は、[イーサリアムのスマートコントラクトを実行できない](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4)点にありました。 このため、大部分のプラズマの実装は、単純な決済システムやERC-20トークンのやりとりを目的とするものでした。 +プラズマフレームワークのもう一つの問題は、[イーサリアムのスマートコントラクトの実行をサポートできないこと](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4)でした。 このため、大部分のプラズマの実装は、単純な決済システムやERC-20トークンのやりとりを目的とするものでした。 -一方、オプティミスティック・ロールアップは[イーサリアム仮想マシン](/developers/docs/evm/)との互換性を持ち、イーサリアムネイティブの[スマートコントラクト](/developers/docs/smart-contracts/)を実行できるため、[分散型アプリケーション](/developers/docs/dapps/)のスケーラブルな展開を実現できる有益かつ_セキュア_なソリューションとなっています。 同様に、[EVMのゼロ知識実装（zkEVM）](https://ethresear.ch/t/a-zk-evm-specification/11549)の開発計画も進行中です。ゼロ知識ロールアップが任意のロジックを処理し、スマートコントラクトを実行できるようなります。 +逆に、オプティミスティック・ロールアップは[イーサリアム仮想マシン](/developers/docs/evm/)と互換性があり、イーサリアムネイティブの[スマートコントラクト](/developers/docs/smart-contracts/)を実行できるため、[分散型アプリケーション](/developers/docs/dapps/)をスケーリングするための有用で_安全な_ソリューションとなります。 同様に、ZKロールアップが任意のロジックを処理し、スマートコントラクトを実行できるようにする[EVMのゼロ知識実装(zkEVM)を作成する](https://ethresear.ch/t/a-zk-evm-specification/11549)計画が進行中です。 -### データの可用性がない {#data-unavailability} +### データの非可用性 {#data-unavailability} すでに述べたように、プラズマチェーンではデータの可用性が提供されないという問題があります。 悪意のオペレーターがチェーン上で無効な状態遷移を進める場合、オペレーターは不正証明を作成するのに必要なデータを秘匿できるため、ユーザーが異議を申し立てることができなくなります。 ロールアップでは、オペレーターに対してトランザクションデータをイーサリアム上で公開するように強制することで、この問題を回避できます。これにより、どのユーザーでもチェーンの状態を検証し、必要に応じて不正証明を作成することが可能になります。 -### 大量退出の問題 {#mass-exit-problem} +### 集団エグジット問題 {#mass-exit-problem} プラズマチェーンにおける大量退出の問題に対しては、ゼロ知識ロールアップやオプティミスティック・ロールアップでは様々な解決策を提案しています。 ゼロ知識ロールアップの場合、いかなるシナリオでもオペレーターが他のユーザーの資金を窃盗できないことを保証するための暗号メカニズムを採用しています。 @@ -142,13 +142,14 @@ sidebarDepth: 3 プラズマチェーン、サイドチェーン、およびシャーディングは、いずれも何らかの方法でイーサリアムメインネットに接続されており、かなりの程度類似した技術だと言えます。 しかし、メインネットとの接続の水準や強度は異なっているため、これらのスケーリング・ソリューションにおけるセキュリティ特性が異なります。 -### サイドチェーンとの比較 {#plasma-vs-sidechains} +### プラズマとサイドチェーンの比較 {#plasma-vs-sidechains} -[サイドチェーン](/developers/docs/scaling/sidechains/)とは、双方向のブリッジを介してイーサリアムメインネットと接続された、独立して運用されるブロックチェーンを指します。 [ブリッジ](/bridges/)は、サイドチェーン上でトランザクションを実行するために、メインネットとサイドチェーンとの間でトークンを交換する機能を提供するため、メインネットの混雑を解消し、スケーラビリティを向上させます。 サイドチェーンはメインネットとは別個のコンセンサス・メカニズムを採用しており、通常はメインネットよりもはるかに小規模なネットワークです。 このため、ブリッジを介してサイドチェーンに資産を転送できる状態はリスクを高めます。サイドチェーンに対しては、イーサリアムメインネットによるセキュリティの保証が提供されないため、サイドチェーンへの攻撃が発生した際には資産を喪失するリスクがあります。 +[サイドチェーン](/developers/docs/scaling/sidechains/)は、双方向のブリッジを介してイーサリアムメインネットに接続された、独立して運用されるブロックチェーンです。 [ブリッジ](/bridges/)は、ユーザーが2つのブロックチェーン間でトークンを交換してサイドチェーン上で取引できるようにすることで、イーサリアムメインネットの混雑を緩和し、スケーラビリティを向上させます。 +サイドチェーンはメインネットとは別個のコンセンサス・メカニズムを採用しており、通常はメインネットよりもはるかに小規模なネットワークです。 このため、ブリッジを介してサイドチェーンに資産を転送できる状態はリスクを高めます。サイドチェーンに対しては、イーサリアムメインネットによるセキュリティの保証が提供されないため、サイドチェーンへの攻撃が発生した際には資産を喪失するリスクがあります。 一方プラズマチェーンでは、メインネットによりセキュリティが保証されます。 このため、サイドチェーンと比較した場合はセキュリティがはるかに堅牢であると言えます。 サイドチェーンとプラズマチェーンはいずれも様々なコンセンサス・プロトコルを採用できますが、プラズマチェーンの場合は、各ブロックに対するマークルルートがメインネット上で公開される点が異なります。 ブロックルートとは、プラズマチェーン上のトランザクションに関する情報を検証するために用いることができる、情報の一部分を指します。 プラズマチェーンへの攻撃が発生した場合、適切な証明を用いることで、資金を安全にメインネットに戻すことができます。 -### シャーディングとの比較 {#plasma-vs-sharding} +### プラズマとシャーディングの比較 {#plasma-vs-sharding} プラズマチェーンとシャードチェーンは、どちらもイーサリアムメインネット上で定期的に暗号学的な証明を公開しています。 しかし、そのセキュリティ特性は異なります。 @@ -156,20 +157,20 @@ sidebarDepth: 3 一方プラズマチェーンでは、子チェーンの状態について最小限の情報しかメインネットに提供されない点が異なります。 つまり、メインネットでは子チェーンで実行されたトランザクションを事実上検証できないため、プラズマチェーンの方がセキュリティが低くなります。 -**注**: イーサリアムブロックチェーンのシャーディングは、現在ロードマップに含まれていません。 代わりに、ロールアップと[ダンクシャーディング](/roadmap/danksharding)によるスケーリングが採用されています。 +**注**: イーサリアムブロックチェーンのシャーディングは、もはやロードマップにはありません。 これは、ロールアップと[Danksharding](/roadmap/danksharding)によるスケーリングに取って代わられました。 -### プラズマの使用 {#use-plasma} +### Plasmaを使用する {#use-plasma} 複数のプロジェクトにおいて、Dappで活用できるプラズマの実装が提供されています。 -- [Polygon](https://polygon.technology/)(旧Matic Network) +- [Polygon](https://polygon.technology/) (旧Matic Network) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [プラズマについて学ぶ](https://www.learnplasma.org/en/) -- [「共有セキュリティ」の意味と重要性についての簡単な復習](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) +- [プラズマを学ぶ](https://www.learnplasma.org/en/) +- [「共有セキュリティ」が何を意味し、なぜそれが非常に重要なのかについての簡単なリマインダー](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) - [サイドチェーン、プラズマ、シャーディングの比較](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) -- [プラズマを理解する（その1：基本事項）](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) -- [プラズマの生と死](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) +- [プラズマを理解する、パート1: 基礎](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) +- [プラズマの誕生と終焉](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/scaling/sidechains/index.md b/public/content/translations/ja/developers/docs/scaling/sidechains/index.md index 868eb4c4798..303ee4d1651 100644 --- a/public/content/translations/ja/developers/docs/scaling/sidechains/index.md +++ b/public/content/translations/ja/developers/docs/scaling/sidechains/index.md @@ -1,53 +1,53 @@ --- -title: サイドチェーン -description: 現在、イーサリアムコミュニティで活用されているスケーリングソリューションとして、サイドチェーンを紹介する。 +title: "サイドチェーン" +description: "現在、イーサリアムコミュニティで活用されているスケーリングソリューションとして、サイドチェーンを紹介する。" lang: ja sidebarDepth: 3 --- -サイドチェーンとは、イーサリアムから独立して実行され、双方向のブリッジによりイーサリアムメインネットに接続されている別個のブロックチェーンです。 サイドチェーンは、メインネットとは異なるブロックのパラメータおよび[コンセンサス・アルゴリズム](/developers/docs/consensus-mechanisms/)を持つことができ、多くの場合トランザクションの効率的な処理のために設計されています。 しかし、イーサリアムのセキュリティ特性を活用できないため、トレードオフが発生します。 [レイヤー2のスケーリングソリューション](/layer-2/)とは異なり、サイドチェーンは状態変化やトンラザクションデータをイーサリアムメインネットに送信しません。 +サイドチェーンとは、イーサリアムから独立して実行され、双方向のブリッジによりイーサリアムメインネットに接続されている別個のブロックチェーンです。 サイドチェーンは、個別のブロックパラメータと[コンセンサスアルゴリズム](/developers/docs/consensus-mechanisms/)を持つことができ、これらは多くの場合、トランザクションの効率的な処理のために設計されています。 しかし、イーサリアムのセキュリティ特性を活用できないため、トレードオフが発生します。 [レイヤー2スケーリングソリューション](/layer-2/)とは異なり、サイドチェーンは状態変更やトランザクションデータをイーサリアムメインネットに書き戻しません。 -サイドチェーンではさらに、高スループットを実現するために、分散性やセキュリティが低下します（[スケーラビリティのトリレンマ](https://vitalik.eth.limo/general/2021/05/23/scaling.html)）。 一方イーサリアムは、アップグレードに関する[ビジョン・ステートメント](/roadmap/vision/)で述べられているように、分散性およびセキュリティを犠牲にすることなくスケーリングを実現することを目指しています。 +サイドチェーンはまた、高いスループットを達成するために、ある程度の分散性やセキュリティを犠牲にします([スケーラビリティのトリレンマ](https://vitalik.eth.limo/general/2021/05/23/scaling.html))。 しかし、イーサリアムは分散性とセキュリティを損なうことなくスケーリングすることにコミットしています。 ## サイドチェーンはどのように機能するのか？ {#how-do-sidechains-work} 各サイドチェーンは、それぞれが独自の開発履歴、ロードマップ、および設計上の検討事項を持つ独立したブロックチェーンです。 サイドチェーンは、表面的にはイーサリアムに類似した部分があったとしても、いくつか独自の特徴を持っています。 -### コンセンサス・アルゴリズム {#consensus-algorithms} +### コンセンサスアルゴリズム {#consensus-algorithms} サイドチェーンの独自性（イーサリアムとの相違点）のひとつとしては、採用されているコンセンサス・アルゴリズムが挙げられます。 サイドチェーンでは、コンセンサスをイーサリアムに依存せず、各サイドチェーンのニーズに合わせて別のコンセンサス・プロトコルを選択することができます。 サイドチェーンで用いられているコンセンサス・アルゴリズムの例としては、以下が挙げられます： - [プルーフ・オブ・オーソリティ](/developers/docs/consensus-mechanisms/poa/) -- [プルーフ・オブ・ステークの委任](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) -- [ビザンチン・フォールトトレランス](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained) +- [デリゲーテッド・プルーフ・オブ・ステーク](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) +- [ビザンチン障害耐性](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained)。 サイドチェーンは、イーサリアムと同様に、トランザクションを検証、処理し、ブロックを生成し、ブロックチェーンの状態を保存する検証ノード（バリデータ）を持ちます。 バリデータはさらに、サイドチェーンネットワーク全体におけるコンセンサスを維持し、悪意の攻撃から防御する責任を負います。 -#### ブロックのパラメータ {#block-parameters} +#### ブロックパラメータ {#block-parameters} -イーサリアムでは、[ブロック生成時間](/developers/docs/blocks/#block-time) (新規ブロックの生成に必要な時間) と [ブロックサイズ](/developers/docs/blocks/#block-size) (ガス単位で表示されるブロックあたりのデータ量) に上限が設定されています。 反対に多くのサイドチェーンでは、より短いブロック生成時間やより高いガス上限などの異なるパラメータを設定することで、高スループット、迅速なトランザクション、および低い手数料を実現しています。 +イーサリアムは、[ブロックタイム](/developers/docs/blocks/#block-time) (新しいブロックを生成するのにかかる時間) と[ブロックサイズ](/developers/docs/blocks/#block-size) (ブロックあたりに含まれるガス建てのデータ量) に制限を設けています。 反対に多くのサイドチェーンでは、より短いブロック生成時間やより高いガス上限などの異なるパラメータを設定することで、高スループット、迅速なトランザクション、および低い手数料を実現しています。 このようなアプローチにはいくつかの利点がありますが、ネットワークの分散化およびセキュリティ保護に対して重大な影響が生じます。 短いブロック生成時間や大きなブロックサイズといったブロックのパラメータは、フルノードの実行を困難にするものであり、いくつかの「スーパーノード」のみがチェーンのセキュリティ保護に責任を負うことになってしまいます。 これにより、バリデータが共謀したり、悪意によるチェーンの乗っ取りが発生する可能性が高まるのです。 -ブロックチェーンにおいて、分散性を犠牲にせずにスケーラビリティを実現するには、特殊なハードウェアを持つユーザーに限らず、すべてのユーザーがノードを実行できるように開放されていなければなりません。 これこそ、イーサリアムネットワークにおいて、誰もが[フルノードを実行](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node)できるように保証する取り組みが続けられている理由です。 +ブロックチェーンにおいて、分散性を犠牲にせずにスケーラビリティを実現するには、特殊なハードウェアを持つユーザーに限らず、すべてのユーザーがノードを実行できるように開放されていなければなりません。 このため、イーサリアムネットワーク上で誰もが[フルノードを運用](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node)できるようにするための取り組みが進められています。 -### EVMとの互換性 {#evm-compatibility} +### EVM互換性 {#evm-compatibility} -一部のサイドチェーンはEVM互換であるため、[イーサリアム仮想マシン（EVM）](/developers/docs/evm/)向けに開発されたスマートコントラクトを実行することができます。 EVM互換のサイドチェーンは、[Solidity](/developers/docs/smart-contracts/languages/)やその他のEVMスマートコントラクト言語で書かれたスマートコントラクトをサポートするため、イーサリアムメインネット向けに開発されたスマートコントラクトはEVM互換のサイドチェーンでも実行することができます。 +一部のサイドチェーンはEVM互換であり、[イーサリアム仮想マシン(EVM)](/developers/docs/evm/)向けに開発されたスマートコントラクトを実行できます。 EVM互換のサイドチェーンは、[Solidityで書かれた](/developers/docs/smart-contracts/languages/)スマートコントラクトやその他のEVMスマートコントラクト言語をサポートしています。これは、イーサリアムメインネット用に書かれたスマートコントラクトが、EVM互換のサイドチェーンでも動作することを意味します。 -つまり、あなたが作成した[Dapp](/developers/docs/dapps/)をサイドチェーンで使用したい場合、あなたの[スマートコントラクト](/developers/docs/smart-contracts/)を当該のサイドチェーンでデプロイするだけでよいです。 サイドチェーンにおけるDappの外観、感触、および動作はメインネットの場合とまったく同じです。Solidity上でコントラクトを作成し、サイドチェーンのRPCを介してチェーンとのやりとりを行います。 +つまり、自分の[dapp](/developers/docs/dapps/)をサイドチェーンで使いたい場合、そのサイドチェーンに[スマートコントラクト](/developers/docs/smart-contracts/)をデプロイするだけでよいのです。 サイドチェーンにおけるDappの外観、感触、および動作はメインネットの場合とまったく同じです。Solidity上でコントラクトを作成し、サイドチェーンのRPCを介してチェーンとのやりとりを行います。 -サイドチェーンがEVM互換であるため、イーサリアムネイティブのDappにとっては有益な[スケーリングソリューション](/developers/docs/scaling/)であると言えるでしょう。 Dappをサイドチェーンでデプロイすることにより、ユーザーは、特にメインネットが混雑している場合に、低いガス代と迅速なトランザクション実行という利点を享受できます。 +サイドチェーンはEVM互換であるため、イーサリアムネイティブのdappsにとって有用な[スケーリングソリューション](/developers/docs/scaling/)と見なされています。 Dappをサイドチェーンでデプロイすることにより、ユーザーは、特にメインネットが混雑している場合に、低いガス代と迅速なトランザクション実行という利点を享受できます。 ただし、すでに述べた通り、サイドチェーンの使用は大きなトレードオフを伴います。 個別のサイドチェーンはそれ自体でセキュリティ保護の責任を負い、イーサリアムのセキュリティ特性を継承しないためです。 これは、ユーザーに悪影響を及ぼしたり、資金をリスクにさらす悪意の行動を防止できないことを意味します。 ### 資産の移動 {#asset-movement} -独立したブロックチェーンがイーサリアムメインネットのサイドチェーンとなるためには、イーサリアムメインネットとの間の資産の出し入れが容易に実行できる機能が必要です。 このイーサリアムとの相互運用性は、ブロックチェーン・ブリッジにより提供されます。 [ブリッジ](/bridges/)は、イーサリアムメインネット上でデプロイされたスマートコントラクトとサイドチェーンを用いて、メインネットとサイドチェーン間の資金移動を管理します。 +独立したブロックチェーンがイーサリアムメインネットのサイドチェーンとなるためには、イーサリアムメインネットとの間の資産の出し入れが容易に実行できる機能が必要です。 このイーサリアムとの相互運用性は、ブロックチェーン・ブリッジにより提供されます。 [ブリッジ](/bridges/)は、イーサリアムメインネットとサイドチェーンにデプロイされたスマートコントラクトを使用して、両者間の資金のブリッジングを制御します。 -ブリッジはイーサリアムとサイドチェーン間の資金移動を手助けしますが、すでに発行された資産が実際に2つのチェーン間を移動する訳ではありません。 むしろ通常は、コインのミントおよびバーンを用いたメカニズムにより、複数のチェーン間で価値を移転します。 詳しくは、[ブリッジの仕組み](/developers/docs/bridges/#how-do-bridges-work)をご覧ください。 +ブリッジはイーサリアムとサイドチェーン間の資金移動を手助けしますが、すでに発行された資産が実際に2つのチェーン間を移動する訳ではありません。 むしろ通常は、コインのミントおよびバーンを用いたメカニズムにより、複数のチェーン間で価値を移転します。 [ブリッジの仕組み](/developers/docs/bridges/#how-do-bridges-work)に関する詳細。 -## サイドチェーンの長所と短所 {#pros-and-cons-of-sidechains} +## サイドチェーンのメリットとデメリット {#pros-and-cons-of-sidechains} | 長所 | 短所 | | ------------------------------------------------------------------------- | ----------------------------------------------------------------------- | @@ -62,12 +62,12 @@ sidebarDepth: 3 - [Polygon PoS](https://polygon.technology/solutions/polygon-pos) - [Skale](https://skale.network/) -- [Gnosis Chain（旧 xDai）](https://www.gnosischain.com/) +- [Gnosis Chain (旧xDai)](https://www.gnosischain.com/) - [Loom Network](https://loomx.io/) - [Metis Andromeda](https://www.metis.io/) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [サイドチェーンを用いてイーサリアムのDappにおけるスケーラビリティを実現する](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _2018年2月8日、ジョルジオス・コンスタントプロス作成。_ +- [サイドチェーンによるイーサリアムdappsのスケーリング](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _2018年2月8日 - Georgios Konstantopoulos_ -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/scaling/state-channels/index.md b/public/content/translations/ja/developers/docs/scaling/state-channels/index.md new file mode 100644 index 00000000000..e10fade9c55 --- /dev/null +++ b/public/content/translations/ja/developers/docs/scaling/state-channels/index.md @@ -0,0 +1,261 @@ +--- +title: "ステートチャネル" +description: "現在、イーサリアムコミュニティで活用されているスケーリング・ソリューションであるステートチャネルおよびペイメントチャネルの紹介。" +lang: ja +sidebarDepth: 3 +--- + +ステートチャネルは、参加者がイーサリアムメインネットとのやり取りを最小限に抑えながら、オフチェーンで安全に取引できるようにします。 チャネルピアは、チャネルを開閉するために2つのオンチェーントランザクションを送信するだけで、任意の数のオフチェーントランザクションを実行できます。 これにより、トランザクションのスループットが大きく改善され、ユーザーの手数料が軽減できます。 + +## 前提条件 {#prerequisites} + +[イーサリアムのスケーリング](/developers/docs/scaling/)と[レイヤー2](/layer-2/)に関するページを読み、理解しておく必要があります。 + +## チャネルとは何か？ {#what-are-channels} + +イーサリアムなどのパブリックブロックチェーンは、分散型アーキテクチャのため、スケーラビリティの課題に直面しています。オンチェーントランザクションはすべてのノードで実行されなければなりません。 各ノードは、一般的なハードウェアを用いて各ブロックに含まれるトランザクションを処理しなければならないため、ネットワークの分散性を維持する上で、トランザクションのスループットには一定の限界が発生します。 ブロックチェーンチャネルは、最終的な決済のセキュリティをメインチェーンに依存しつつ、ユーザーがオフチェーンでやりとりできるようにすることで、この問題を解決します。 + +単純なピアツーピアのプロトコルであるチャネルを利用することで、チャネルに参加する2つのノードは、数多くのトランザクションを実行した上で、最終的な結果のみをブロックチェーンに送信するだけでよくなります。 チャネルは、暗号技術を用いることで、メインネットに送信されるサマリーデータがノード間で実行された一連の有効なトランザクションの真の結果であることを証明することができます。 [「マルチシグ」](/developers/docs/smart-contracts/#multisig)スマートコントラクトは、トランザクションが適切な当事者によって署名されることを保証します。 + +チャネルにおける状態変化は参加ノードにより実行、検証されるため、実行レイヤーにおける計算を最低限に抑えることができます。 これにより、イーサリアムの混雑が解消され、ユーザーにとってはトランザクションの処理速度が改善されます。 + +各チャネルは、イーサリアム上で実行される[マルチシグスマートコントラクト](/developers/docs/smart-contracts/#multisig)によって管理されます。 チャネルを開くには、参加者はチャネルコントラクトをオンチェーンでデプロイし、そこに資金を預け入れます。 両当事者は共同で状態更新に署名してチャネルの状態を初期化し、その後、オフチェーンで迅速かつ自由に取引できます。 + +チャネルを閉じるには、参加者はチャネルの最後に合意された状態をオンチェーンに送信します。 これを受けて、マルチシグのスマートコントラクトは、チャネルの最終状態における各ノードの残高に従って、ロックされた資金を分配します。 + +ピアツーピアのチャネルは、特に事前に定義された参加者が処理速度の明らかな低下をもたらすことなく高頻度でトランザクションを行いたい場合に有益です。 ブロックチェーンチャネルは、**ペイメントチャネル**と**ステートチャネル**の2つのカテゴリに分類されます。 + +## ペイメントチャネル {#payment-channels} + +ペイメントチャネルは、2つのノードが共同で管理する「双方向の台帳」と呼べるでしょう。 台帳の初期残高は、チャネル開設フェーズ中にオンチェーンコントラクトにロックされた預託金の合計額です。 ペイメントチャネルでの送金は、最初の1回限りのオンチェーン作成と最終的なチャネルの閉鎖を除き、実際のブロックチェーン自体を介さずに瞬時に実行できます。 + +チャネルの台帳における残高（つまり、ペイメントチャネルの状態）が変更される場合、チャネルに参加する全ユーザーの承認が必要になります。 イーサリアムにおけるトランザクションの場合と同じように、チャネルの更新は、参加ユーザー全員の署名によりファイナライズされたと見なされます。 + +ペイメントチャネルは、単純なユーザーインタラクション（例：ETH送金、アトミックスワップ、マイクロペイメント）の高価なオンチェーンアクティビティを最小限に抑えるために設計された、最も初期のスケーリングソリューションの1つでした。 チャネルの参加ユーザーは、送金の合計額がデポジットされたトークンの合計を超えない限り、ユーザー間のトランザクションを瞬時に何回でも無料で実行することができます。 + +## ステートチャネル {#state-channels} + +オフチェーン決済のサポートは別として、ペイメントチャネルは一般的な状態遷移ロジックの処理には役立たないことが証明されています。 ステートチャネルは、このペイメントチャネルの欠点を解消するために開発されたもので、汎用的な計算におけるスケーラビリティを実現するためのチャネルだと言えます。 + +ただし、ステートチャネルはペイメントチャネルと多くの点が共通しています。 例えばどちらのチャネルでも、ユーザーが他のチャネル参加者とやりとりを行う際には、チャネルの全参加ユーザーが暗号学的に署名されたメッセージ（トランザクション）に署名しなければなりません。 提案された状態更新が全参加ユーザーによって署名されていなければ、更新は無効とされます。 + +一方で、ステートチャネルでは、ユーザーの残高情報を保持するだけでなく、当該コントラクトのストレージの現在状態（つまり、コントラクトに含まれる各変数の値）を追跡することができます。 + +これにより、2人のユーザー間でスマートコントラクトをオフチェーンで実行することが可能になります。 この場合、スマートコントラクトの初期状態を変更するには、チャネルを開設した両ユーザー（ピア）の承認のみが必要になります。 + +これは、先ほど挙げたスケーラビリティの問題を解消する一方で、セキュリティが低下する可能性をもたらします。 イーサリアムでは、状態遷移の有効性は、ネットワークのコンセンサスプロトコルによって強制されます。 これにより、スマートコントラクトの状態に対して無効な更新を提案したり、スマートコントラクトの実行を改変することは不可能になっているのです。 + +ステートチャネルでは、このようなセキュリティの保証が提供されません。 ステートチャネルは、言わばメインネットのミニチュア版と考えることができます。 ルールを強制する参加者の数が限定されるため、悪意の行為（つまり、無効な状態更新の提案）が発生する可能性が大きくなります。 ステートチャネルのセキュリティは、[不正証明](/glossary/#fraud-proof)に基づく紛争仲裁システムに由来します。 + +## ステートチャネルの仕組み {#how-state-channels-work} + +ステートチャネルにおけるアクティビティは、基本的に、ユーザーとブロックチェーンによる相互のやりとりのセッションだと考えることができます。 ユーザーは主にオフチェーンで相互に通信し、チャネルの開設、閉鎖、または参加者間の潜在的な紛争を解決するためにのみ、基盤となるブロックチェーンと対話します。 + +次のセクションでは、ステートチャネルの基本的なワークフローについて説明します： + +### チャネルの開設 {#opening-the-channel} + +チャネルを開設するには、参加ユーザーがメインネット上のスマートコントラクトにおいて資金をコミットする必要があります。 このデポジットは仮想的な請求書（タブ）として機能するため、参加ユーザーはただちに決済することなく、自由に取引を実行することができます。 チャネルがオンチェーンでファイナライズされた時に初めて、当事者は互いに決済を行い、各自の残高から残りの資金を引き出します。 + +このデポジットは同時に、参加ユーザーが正直に行動することを保証する担保金の役割も担います。 デポジットを提供したユーザーが紛争解決フェーズにおいて悪意の行為を実行したと決定された場合、スマートコントラクトはデポジットを没収します。 + +チャネルに参加する各ピアは、全員が同意したチャネルの初期状態に署名する必要があります。 これによりステートチャネルが開設され、参加ユーザー間でトランザクションを実行できるようになります。 + +### チャネルの使用 {#using-the-channel} + +チャネルの状態が初期化されると、各ピアは、自らが署名したトランザクションを他のピアに送信し、承認を求めることで、やりとりを行います。 参加ユーザーは、このようなトランザクションを通じて、自らが状態更新を開始したり、他のユーザーからの状態更新に署名したりします。 チャネルにおけるトランザクションは、以下の要素で構成されます： + +- **ナンス**。トランザクションの一意のIDとして機能し、リプレイ攻撃を防ぎます。 同時に、状態更新の発生順序を特定します（これは、紛争解決フェーズにおいて重要です）。 + +- チャネルの古い状態。 + +- チャネルの新しい状態。 + +- 状態遷移をトリガーするトランザクション（例：アリスがボブに5 ETHを送信するトランザクション）。 + +チャネルの状態更新は、ユーザーがメインネットで対話する場合のように通常オンチェーンでブロードキャストされません。これは、オンチェーンのフットプリントを最小限に抑えるというステートチャネルの目標と一致しています。 参加ユーザーが同意する限り、状態更新はイーサリアムのトランザクションと同様のファイナリティを持ちます。 参加者がメインネットのコンセンサスに依存するのは、紛争が発生した場合のみです。 + +### チャネルのクローズ {#closing-the-channel} + +ステートチャネルを閉じるには、チャネルの最終的な合意済み状態をオンチェーンのスマートコントラクトに送信する必要があります。 状態更新における参照情報には、各参加ユーザーが実行したアクションの数および承認済みトランザクションのリストが含まれます。 + +当該の状態更新が有効である（つまり、全参加ユーザーにより署名済みである）ことが検証されると、スマートコントラクトが当該チャネルをファイナライズし、ロックされた資金をチャネルの最終状態に基づき分配します。 オフチェーンで行われた支払いはイーサリアムの状態に適用され、各参加者はロックされた資金の残りの部分を受け取ります。 + +上記の流れは、あくまでも問題が発生しない幸せな場合です。 各ユーザーが同意に達することができず、チャネルをファイナライズできない場合（残念なケース）もあります。 具体的には、以下のような可能性があります： + +- 参加ユーザーがオフラインになっために、状態遷移が提案できない。 + +- 参加ユーザーが、有効な状態更新の共同署名を拒否する。 + +- 参加者は、古い状態更新をオンチェーンコントラクトに提案することで、チャネルのファイナライズを試みます。 + +- 参加ユーザーが、無効な状態遷移を提案し、他のユーザーに署名させようとする。 + +チャネルの参加ユーザー間のコンセンサスが維持できなくなった場合の最後のオプションは、メインネットのコンセンサスを用いて、チャネルの最後に有効な状態を強制することです。 この場合、ステートチャネルを閉鎖するには、オンチェーンでの紛争解決が必要です。 + +### 紛争の解決 {#settling-disputes} + +通常、チャネルの参加ユーザーは、事前にチャネルの廃止に同意し、最後の状態遷移に共同署名した上で、スマートコントラクトに送信します。 更新がオンチェーンで承認されると、オフチェーンのスマートコントラクトの実行が終了し、参加者は資金を持ってチャネルを退出します。 + +しかし、一方の当事者は、相手の承認を待たずに、スマートコントラクトの実行を終了してチャネルをファイナライズするようオンチェーンでリクエストを送信できます。 前述のコンセンサスを破るような状況が発生した場合、いずれかの当事者はオンチェーンコントラクトをトリガーしてチャネルを閉じ、資金を分配させることができます。 これにより**トラストレス性**が提供され、誠実な当事者は、相手方の行動に関係なく、いつでもデポジットを引き出すことができるようになります。 + +チャネルの退出を処理するために、ユーザーはアプリケーションの最後の有効な状態更新をオンチェーンコントラクトに送信する必要があります。 この最後の有効な状態更新が正しければ（つまり、全参加ユーザーの署名を含んでいれば）、資金は各ユーザーに再分配されます。 + +ただし、1名のユーザーによる廃止リクエストに対しては、実行までの保留期間が発生します。 チャネルを閉鎖するリクエストが満場一致で承認された場合、オンチェーンの退出トランザクションは即座に実行されます。 + +1名のユーザーによる廃止リクエストについて保留期間が発生するのは、不正行為の可能性を防止するためです。 例えば、あるチャネル参加者が、古い状態更新をオンチェーンで送信することにより、イーサリアム上でチャネルをファイナライズしようとすることがあります。 + +対抗策として、ステートチャネルでは、誠実なユーザーがチャネルの最新の有効な状態をオンチェーンで送信することで、無効な状態更新に異議を唱えることができます。 ステートチャネルは、より新しい同意済みの状態更新が、より古い状態更新よりも優先されるように設計されています。 + +あるピアがオンチェーンの紛争解決システムをトリガーすると、相手方は制限時間内（チャレンジ期間と呼ばれる）に応答する必要があります。 このメカニズムを通じて、各ユーザーは、特に相手方のピアが状態更新を要求する場合に、廃止トランザクションに異議を申し立てることができます。 + +どのような場合であれ、チャネルユーザーは常に強力なファイナリティ保証を得られます。もし所有する状態遷移がすべてのメンバーによって署名され、かつ最新の更新であるならば、それは通常のオンチェーントランザクションと同等のファイナリティを持ちます。 彼らは依然として相手方に対してオンチェーンで異議を申し立てる必要がありますが、唯一可能な結果は、彼らが保持する最後の有効な状態をファイナライズすることです。 + +### ステートチャネルは、イーサリアムとどのようなやりとりを行うか？ ステートチャネルとイーサリアムの連携方法 {#how-do-state-channels-interact-with-ethereum} + +ステートチャネルはオフチェーンプロトコルとして存在しますが、オンチェーンの構成要素、つまりチャネル開設時にイーサリアム上でデプロイされたスマートコントラクトを持ちます。 このコントラクトは、ステートチャネルにデポジットされた資産を管理し、状態更新を検証し、参加ユーザー間の紛争を仲裁する機能を持ちます。 + +ステートチャネルは、[レイヤー2](/layer-2/)スケーリングソリューションとは異なり、トランザクションデータやステートコミットメントをメインネットに公開しません。 しかし、例えば[サイドチェーン](/developers/docs/scaling/sidechains/)と比較してメインネットとの接続性が高いため、いくらか安全性が高いと言えます。 + +ステートチャネルは、以下の事項につきメインのイーサリアムプロトコルに依存します： + +#### 1. 生存性 {#liveness} + +チャネル開設時にデプロイされるオンチェーンコントラクトが、チャネルの機能に責任を持ちます。 このコントラクトがイーサリアムで稼働中であれば、このチャネルは常に利用できることになります。 一方、サイドチェーンの場合、メインネットが稼働している場合でも機能が停止される可能性があるため、ユーザーの資金に対してリスクが発生します。 + +#### 2. セキュリティ {#security} + +ステートチャネルでは、セキュリティを維持し、悪意のピアから善意のピアを保護するために、ある程度イーサリアムに依存しています。 以下のセクションで説明するように、ステートチャネルでは、無効な／古い状態更新でチャネルをファイナライズしようとするユーザーに異議を申し立てることが可能な不正証明メカニズムを採用しています。 + +この場合、誠実な当事者は、検証のためにチャネルの最新の有効な状態を不正証明としてオンチェーンコントラクトに提供します。 不正証明により、相互に信頼しない当事者同士が、その過程で資金を危険にさらすことなく、オフチェーントランザクションを実行できるようになります。 + +#### 3. ファイナリティ {#finality} + +チャネルユーザーによって集合的に署名された状態更新は、オンチェーントランザクションと同等と見なされます。 とはいえ、チャネル内のすべてのアクティビティが真のファイナリティを達成するのは、チャネルがイーサリアム上で廃止された時点においてです。 + +楽観的なケースでは、両当事者が協力して最終的な状態更新に署名し、オンチェーンに送信してチャネルを閉じ、その後、チャネルの最終状態に応じて資金が分配されます。 悲観的なケースでは、誰かが不正な状態更新をオンチェーンに投稿して不正を働こうとした場合、そのトランザクションはチャレンジ期間が経過するまでファイナライズされません。 + +## 仮想ステートチャネル {#virtual-state-channels} + +ステートチャネルの単純な実装は、2人のユーザーがオフチェーンでアプリケーションを実行したい場合に新しいコントラクトをデプロイすることです。 これは実行不可能であるだけでなく、ステートチャネルの費用対効果を無効にします（オンチェーントランザクションのコストはすぐに加算される可能性があります）。 + +この問題点を解消するために、「仮想チャネル」が開発されました。 開設と終了にオンチェーントランザクションを必要とする通常のチャネルとは異なり、仮想チャネルはメインチェーンと対話することなく、開設、実行、ファイナライズが可能です。 この方法を使えば、オフチェーンで紛争を解決することも可能です。 + +このシステムは、オンチェーンで資金提供されている、いわゆる「台帳チャネル」の存在に依存しています。 これは、既存の台帳チャネルの上に2名のユーザー間の仮想チャネルを構築し、台帳チャネルの所有ユーザー（複数可）が仲介者の役割を果たすというモデルです。 + +各仮想チャネルに参加するユーザーは、当該コントラクトの新規インスタンスを通じてやりとりを行い、台帳チャネルが複数のインスタンスをサポートします。 台帳チャネルの状態には複数のコントラクトストレージ状態も含まれており、異なるユーザー間でアプリケーションをオフチェーンで並列実行できます。 + +この場合も、通常のチャネルと同様に、ユーザーは状態更新を相互に交換することで状態マシンを前に進めることができます。 紛争が発生しない限り、仲介者との連絡はチャネルの開設時または終了時にのみ必要です。 + +### 仮想ペイメントチャネル {#virtual-payment-channels} + +仮想ペイメントチャネルは仮想ステートチャネルと同じ考え方で動作します。同じネットワークに接続された参加者は、オンチェーンで新しいチャネルを開く必要なくメッセージを渡すことができます。 仮想ペイメントチャネルでは、送金は1名または複数の仲介者を介して実行されるため、意図した受取人のみが資金を受け取ることが保証されます。 + +## ステートチャネルのアプリケーション {#applications-of-state-channels} + +### 支払い {#payments} + +初期のブロックチェーンチャネルは、2人の参加者がメインネットで高いトランザクション手数料を支払うことなく、オフチェーンで迅速かつ低料金の送金を行えるようにするシンプルなプロトコルでした。 ペイメントチャネルは現在でも、イーサ（ETH）やその他のトークンの交換や預入を行う目的において有益だと言えます。 + +チャネルを活用した決済には、以下の利点があります： + +1. **スループット**: チャネルあたりのオフチェーントランザクションの量は、ブロックサイズやブロック時間など様々な要因に影響されるイーサリアムのスループットとは無関係です。 オフチェーンでトランザクションを実行することで、ブロックチェーンチャネルはより高いスループットを達成できます。 + +2. **プライバシー**: チャネルはオフチェーンに存在するため、参加者間の対話の詳細はイーサリアムのパブリックブロックチェーンには記録されません。 チャネルユーザーは、チャネルへの資金提供や閉鎖、または紛争解決時にのみオンチェーンで対話する必要があります。 このため、トランザクションのプライバシーを重視するユーザーにとってチャネルは有益だと言えます。 + +3. **レイテンシー**: チャネル参加者間で行われるオフチェーントランザクションは、両当事者が協力すれば即座に決済でき、遅延を減らすことができます。 対照的に、メインネットでのトランザクションの場合、各ノードがトランザクションを処理し、トランザクションを含む新規ブロックを生成した上で、コンセンサスを達成するまでの時間が必要になります。 さらに、トランザクションがファイナライズされる前に、より多くのブロックが確認されるまで待たなければならない場合もあります。 + +4. **コスト**: ステートチャネルは、参加者の集まりが長期間にわたって多くの状態更新を交換する状況で特に有用です。 発生する唯一のコストは、ステートチャネルのスマートコントラクトの開始／終了に伴う費用のみです。決済コストは、チャネルの最終状態に従って配分されるため、チャネルの開設から廃止に至るまでの各状態変化のコストは最後の状態変化のコストよりも安価になります。 + +[ロールアップ](/developers/docs/scaling/#rollups)などのレイヤー2ソリューションにステートチャネルを実装することで、支払いにとってさらに魅力的なものになる可能性があります。 チャネルは安価な支払いを提供しますが、開設フェーズでメインネットにオンチェーンコントラクトを設定するコストは高くなる可能性があります。特にガス料金が急騰した場合はなおさらです。 イーサリアムベースのロールアップは[より低いトランザクション手数料](https://l2fees.info/)を提供し、設定手数料を下げることでチャネル参加者のオーバーヘッドを削減できます。 + +### マイクロトランザクション {#microtransactions} + +マイクロトランザクションとは、企業にとって損失が発生するような微少な価値（例：1ドル未満）の決済を指します。 これらの事業体は、決済サービスプロバイダーに手数料を支払う必要がありますが、顧客売上の利益率が低すぎる場合には損失が発生する可能性があるためです。 + +ペイメントチャネルは、マイクロトランザクションにおける間接費用を縮小することでこの問題を解消します。 例えばインターネットサービスプロバイダー（ISP）であれば、顧客が自社サービスを利用するごとに少額の支払いがストリーミングされるペイメントチャネルを開設することができます。 + +チャネルの参加ユーザーは、チャネルの開設／廃止時における費用を負担すれば、実際のマイクロトランザクションにおいて費用を発生させずに済むのです（ガス代がかかりません）。 顧客は受け取るサービスに対してより柔軟に支払うことができ、企業は収益性を持つマイクロトランザクションを放棄する必要がなくなるので、双方にとって有益なサービスになります。 + +### 分散型アプリケーション {#decentralized-applications} + +ステートチャネルでは、ペイメントチャネルと同様に、ステートマシンの最終状態に従って条件付きの決済を行うことができます。 ステートチャネルは任意の状態遷移ロジックもサポートできるため、汎用アプリをオフチェーンで実行するのに役立ちます。 + +ステートチャネルは、オンチェーンコントラクトにコミットされた資金の管理を容易にするため、単純なターンベースのアプリケーションに限定されることがよくあります。 また、限られた数の当事者が一定間隔でオフチェーンアプリケーションの状態を更新するため、不正行為の処罰は比較的簡単です。 + +また、ステートチャネルを用いたアプリケーションの効率性は、その設計により異なります。 例えば、開発者はアプリチャネルコントラクトを一度オンチェーンでデプロイし、他のプレイヤーがオンチェーンにアクセスすることなくアプリを再利用できるようにすることができます。 この場合、最初のアプリチャネルは複数の仮想チャネルをサポートする台帳チャネルとして機能し、各仮想チャネルはアプリのスマートコントラクトの新しいインスタンスをオフチェーンで実行します。 + +ステートチャネルを用いたアプリケーションのユースケースとしては、ゲームの結果に基づいて資金が分配される2人対戦型のゲームが想定できるでしょう。 ここでの利点は、プレイヤーが互いを信頼する必要がなく（トラストレス性）、プレイヤーではなくオンチェーンコントラクトが資金の配分と紛争の解決を制御することです（分散化）。 + +ステートチャネルを用いたアプリケーションにおけるその他のユースケースとしては、ENSの名前解決サービスやNFT台帳など、様々な可能性があります。 + +### アトミック送金 {#atomic-transfers} + +初期のペイメントチャネルでは、2名のユーザー間の送金のみが可能だったため、用途が限られていました。 しかし、仮想チャネルの導入により、個人はオンチェーンで新しいチャネルを開設することなく、仲介者（つまり複数のP2Pチャネル）を介して送金をルーティングできるようになりました。 + +転送を伴う支払いは一般的に「マルチホップ送金」と呼ばれ、アトミックな性質を持ちます（つまり、トランザクションに含まれるすべての部分が成功しない限り、全体が無効になります）。 アトミック送金では、[ハッシュ化されたタイムロック・コントラクト（HTLC）](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts)を使用して、特定の条件が満たされた場合にのみ支払いがリリースされるようにし、それによってカウンターパーティリスクを軽減します。 + +## ステートチャネルを使用する際の欠点 {#drawbacks-of-state-channels} + +### 生存性の仮定 {#liveness-assumptions} + +ステートチャネルでは、効率性を維持するために、チャネルの参加ユーザーにおける紛争対応能力に時間的な制限を設けています。 このルールは、各ピアが常にオンラインでチャネルのアクティビティを監視でき、必要に応じて異議申立に対応できることを想定しています。 + +実際には、ユーザーは各自の責任ではない理由でオフラインになる可能性があります（インターネットの接続不良や機器の不調など）。 このため、悪意のユーザーは、正直なユーザーがオフラインである間に仲裁者コントラクトに古い中間状態を送信し、コミットされた資金を窃盗することが可能です。 + +一部のチャネルでは、「監視塔（ウォッチタワー）」、つまり他者に代わってオンチェーンの紛争イベントを監視し、関係者への警告など必要な措置を講じる責任を負うエンティティを使用します。 ただしこのアプローチでは、ステートチャネルの利用コストが上昇する可能性があります。 + +### データの非可用性 {#data-unavailability} + +すでに述べたように、紛争が無効であるとして異議を申し立てるためには、ステートチャネルの最終有効状態を送信する必要があります。 これも、各ユーザーがチャネルの最新状態にアクセス可能であるという想定に基づいたルールだと言えます。 + +チャネルユーザーにオフチェーンアプリケーションの状態のコピーを保存するよう期待することは合理的ですが、このデータはエラーや機械的故障により失われる可能性があります。 ユーザーが当該データのバックアップを作成していない場合、相手方のユーザーが所持している古い状態遷移を用いて無効な終了リクエストをファイナライズしないように祈るしかありません。 + +イーサリアムにおいてこの問題が発生しないのは、イーサリアムネットワークによりデータの可用性に関するルールが強制されるためです。 トランザクションデータはすべてのノードが保存し、伝播されるため、ユーザーは必要に応じて常にダウンロードすることができます。 + +### 流動性の問題 {#liquidity-issues} + +ブロックチェーンチャネルを確立するには、参加者はチャネルのライフサイクル中、オンチェーンのスマートコントラクトに資金をロックする必要があります。 これにより、チャネルに参加するユーザーの流動性に関する問題が軽減されますが、メインネットに資金をロックできるユーザー以外はチャネルに参加できなくなります。 + +しかし、オフチェーンサービスプロバイダー（OSP）によって運営される台帳チャネルは、ユーザーの流動性の問題を軽減できます。 台帳チャネルに接続された2つのピアは仮想チャネルを作成でき、いつでも完全にオフチェーンで開設およびファイナライズできます。 + +オフチェーンサービスプロバイダーは、複数のピアとチャネルを開くこともでき、支払いのルーティングに役立ちます。 もちろん、このようなサービスを利用するユーザーはOSPに手数料を支払う必要があるため、好ましくないと思うユーザーもいるでしょう。 + +### グリーフィング攻撃 {#griefing-attacks} + +一般に、不正証明ベースのシステムにはグリーフィング攻撃がつきものです。 グリーフィング攻撃とは、攻撃者に直接的な利益をもたらすものではないものの、被害者に苦痛（＝損害）を与えることを目的とするもので、苦痛付与攻撃とも言えます。 + +不正証明においてグリーフィング攻撃が発生してしまうのは、正直なユーザーが無効な紛争を含むすべての紛争に対応しなければならず、それを怠った場合には資金を失うリスクが発生してしまうためです。 悪意のある参加者は、古い状態遷移を繰り返しオンチェーンに投稿し、誠実な当事者に有効な状態で応答させることを決定する可能性があります。 これらのオンチェーントランザクションのコストはすぐに積み重なり、その過程で誠実な当事者が損をする原因となります。 + +### 事前定義された参加者セット {#predefined-participant-sets} + +ステートチャネルでは、その設計に基づき、チャネルの存続期間を通じた参加ユーザー数が固定されています。 これは、特にチャネルへの資金供給や紛争の解決などにおいて、参加できるユーザー数を変更するとチャネルの運用が複雑化するためです。 参加者の追加や削除には追加のオンチェーンアクティビティも必要となり、ユーザーのオーバーヘッドが増加します。 + +これらの理由により、ステートチャネルが定義済みの参加者セットを導入するのは理にかなっているものの、アプリケーションのデベロッパーにとってはチャネルの設計における有用性を低めるものでもあります。 この点は、ロールアップなどその他のスケーリング・ソリューションと比較して、ステートチャネルの利用度が下がっている原因のひとつだと言えます。 + +### トランザクションの並列処理 {#parallel-transaction-processing} + +ステートチャネルの参加ユーザーは状態更新を交互に送信しあうため、「順番ベースのアプリケーション」（例：対戦型のチェスゲーム）に最も適しています。 これにより、同時状態更新を処理する必要がなくなり、古い更新の投稿者を罰するためにオンチェーンコントラクトが行わなければならない作業が削減されます。 ただしこの設計の副作用として、トランザクションが相手方のアクションに依存するため、レイテンシーが増化し、全般的なユーザー体験の質が損なわれる可能性があります。 + +一部のステートチャネルは、オフチェーンの状態を2つの単方向の「シンプレックス」状態に分離する「全二重」設計を使用することでこの問題を解決し、同時状態更新を可能にします。 このような設計は、オフチェーンのスループットを向上させ、トランザクションの遅延を減少させます。 + +## ステートチャネルを使用する {#use-state-channels} + +複数のプロジェクトにおいて、Dappに統合できるステートチャネルの実装が提供されています： + +- [Connext](https://connext.network/) +- [Kchannels](https://www.kchannels.io/) +- [Perun](https://perun.network/) +- [Raiden](https://raiden.network/) +- [Statechannels.org](https://statechannels.org/) + +## 参考リンク {#further-reading} + +**ステートチャンネル** + +- [イーサリアムのレイヤー2スケーリングソリューションを理解する：ステートチャネル、Plasma、Truebit](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark、2018年2月12日_ +- [ステートチャネル - 解説](https://www.jeffcoleman.ca/state-channels/) _2015年11月6日 - Jeff Coleman_ +- [ステートチャネルの基礎](https://education.district0x.io/general-topics/understanding-ethereum/basics-state-channels/) _District0x_ +- [ブロックチェーンステートチャネル：最新技術](https://ieeexplore.ieee.org/document/9627997) + +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/scaling/validium/index.md b/public/content/translations/ja/developers/docs/scaling/validium/index.md index 480f57f9fb5..012b3d6d2e2 100644 --- a/public/content/translations/ja/developers/docs/scaling/validium/index.md +++ b/public/content/translations/ja/developers/docs/scaling/validium/index.md @@ -1,165 +1,166 @@ --- -title: バリディアム -description: 現在、イーサリアム・コミュニティで活用されているスケーリングのソリューションとしてのバリディアムを紹介する +title: "バリディアム" +description: "現在、イーサリアム・コミュニティで活用されているスケーリングのソリューションとしてのバリディアムを紹介する" lang: ja sidebarDepth: 3 --- -バリディアムは、 [ゼロ知識ロールアップ](/developers/docs/scaling/zk-rollups/)のような有効性証明を使用してトランザクションの完全性を強化する[スケーリングソリューション](/developers/docs/scaling/)ですが、トランザクションのデータはイーサリアムメインネットに保存されません。 オフチェーンにおけるデータの可用性が低下するというトレードオフが存在する一方で、スケーラビリティが大幅に向上します（バリディアムでは、[1秒間に9,000件以上のトランザクションが実行可能です](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)）。 +Validiumは、[ZKロールアップ](/developers/docs/scaling/zk-rollups/)のような有効性証明を使用してトランザクションの完全性を強化する[スケーリングソリューション](/developers/docs/scaling/)ですが、トランザクションデータをイーサリアムメインネットに保存しません。 オフチェーンのデータ可用性にはトレードオフが伴いますが、スケーラビリティの大幅な向上につながる可能性があります(Validiumは[毎秒9,000件以上のトランザクション](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)を処理できます)。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[イーサリアムのスケーリング](/developers/docs/scaling/)と[レイヤー2](/layer-2) のページを読んで理解しておくことをおすすめします。 +[イーサリアムのスケーリング](/developers/docs/scaling/)と[レイヤー2](/layer-2)に関するページを読んで理解しておく必要があります。 ## バリディアムとは何か？ {#what-is-validium} -バリディアムは、オフチェーンにおけるデータの可用性および処理能力を用いてイーサリアムメインネット外でトランザクションを処理することでスループットの向上を目指すスケーリング・ソリューションです。 ゼロ知識ロールアップ（ZKロールアップ）と同様に、バリディアムでは[ゼロ知識証明](/glossary/#zk-proof)を発行することで、オフチェーンのトランザクションをイーサリアム上で検証します。 これにより無効な状態遷移の発生を防ぐことができるため、バリディアムチェーンのセキュリティが強化されます。 +Validiumは、イーサリアムメインネット外でトランザクションを処理してスループットを向上させるように設計された、オフチェーンのデータ可用性と計算を使用するスケーリングソリューションです。 [ゼロ知識ロールアップ](/glossary/#zk-proof) (ZKロールアップ)と同様に、Validiumはイーサリアム上でオフチェーントランザクションを検証するために[ゼロ知識証明](/glossary/#zk-proof)を公開します。 これにより無効な状態遷移の発生を防ぐことができるため、バリディアムチェーンのセキュリティが強化されます。 -ゼロ知識証明をはじめとする「有効性証明」は、ZK-SNARK（ゼロ知識であり、簡潔かつ非双方向の知識アーギュメント）またはZK-STARK（ゼロ知識であり、スケーラブルかつ透明性が高い知識アーギュメント）のいずれかに分類されます。 詳細については、[ゼロ知識証明](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)をご覧ください。 +ゼロ知識証明をはじめとする「有効性証明」は、ZK-SNARK（ゼロ知識であり、簡潔かつ非双方向の知識アーギュメント）またはZK-STARK（ゼロ知識であり、スケーラブルかつ透明性が高い知識アーギュメント）のいずれかに分類されます。 [ゼロ知識証明](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)の詳細。 -バリディアムでは、ユーザーの資金はイーサリアム上のスマートコントラクトで管理されます。 バリディアムは、ゼロ知識ロールアップの場合とよく似たほぼ瞬時の出金が可能です。出金リクエストに対する有効性証明がメインネット上で検証されると、ユーザーは[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)を提供することで資金を引き出せるようになります。 マークル証明は、ユーザーの出金トランザクションが検証済みのトランザクション・バッチに含まれることを確認するもので、オンチェーンのコントラクトが当該の出金を処理することを許可します。 +バリディアムでは、ユーザーの資金はイーサリアム上のスマートコントラクトで管理されます。 Validiumは、ZKロールアップと同様に、ほぼ瞬時の引き出しが可能です。引き出しリクエストの有効性証明がメインネットで検証されると、ユーザーは[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)を提供することで資金を引き出すことができます。 マークル証明は、ユーザーの引き出しトランザクションが検証済みのトランザクションバッチに含まれていることを検証し、オンチェーンコントラクトが引き出しを処理できるようにします。 -一方で、バリディアムでは、ユーザーの資金を凍結し、引き出しを制限することも可能です。 バリディアムチェーンでデータの可用性を管理するマネージャーが、他のユーザーにオフチェーンの状態データを提供できなくすることができるためです。 トランザクションデータにアクセスできないユーザーは、資金の所有権を証明し、出金を実行するのに必要なマークル証明を計算できません。 +一方で、バリディアムでは、ユーザーの資金を凍結し、引き出しを制限することも可能です。 これは、Validiumチェーンのデータ可用性管理者が、ユーザーからオフチェーンの状態データを差し控えた場合に発生する可能性があります。 トランザクションデータにアクセスできないユーザーは、資金の所有権を証明し、出金を実行するのに必要なマークル証明を計算できません。 つまり、データの可用性に関する姿勢が、バリディアムとゼロ知識ロールアップとの最大の違いだと言えます。 これらのソリューションは、データストレージに対して異なるアプローチを採用しているため、セキュリティやトラストレス性にも影響があります。 -## バリディアムは、どのようにイーサリアムメインネットとやりとりするのか？ {#how-do-validiums-interact-with-ethereum} +## Validiumはイーサリアムとどのように相互作用するのか？ {#how-do-validiums-interact-with-ethereum} -バリディアムは、既存のイーサリアムチェーン上で構築されたスケーリング用のプロトコルです。 バリディアムチェーンは、オフチェーンでトランザクションを実行する一方で、メインネット上でデプロイされた以下をはじめとする一連のスマートコントラクトで管理されます。 +バリディアムは、既存のイーサリアムチェーン上で構築されたスケーリング用のプロトコルです。 Validiumチェーンはオフチェーンでトランザクションを実行しますが、メインネットにデプロイされた次のようなスマートコントラクトの集まりによって管理されます。 -1. **検証者コントラクト**: 検証者コントラクトは、バリディアムチェーンが状態更新を行う際に、バリディアムのオペレーターから受信した有効性証明を検証します。 これには、オフチェーンのトランザクションの正しさを証明する有効性証明と、オフチェーンにおいてトランザクションデータが存在することを証明するデータ可用性証明があります。 +1. **検証者コントラクト**：検証者コントラクトは、状態更新を行う際に、Validiumのオペレーターによって提出された証明の有効性を検証します。 これには、オフチェーントランザクションの正しさを証明する有効性証明と、オフチェーントランザクションデータの存在を検証するデータ可用性証明が含まれます。 -2. **メインコントラクト**: メインコントラクトは、ブロック生成者が送信したステートコミットメント (マークルルート) を保存し、有効性証明がオンチェーンで確認された時点でバリディアムの状態を更新します。 メインコントラクトはさらに、バリディアムチェーンからの入金／出金を処理します。 +2. **メインコントラクト**：メインコントラクトは、ブロック生成者から提出された状態コミットメント（マークルルート）を保存し、有効性証明がオンチェーンで検証されるとValidiumの状態を更新します。 メインコントラクトはさらに、バリディアムチェーンからの入金／出金を処理します。 バリディアムでは、さらに以下の機能についてメインのイーサリアムチェーンに依存します： ### 決済 {#settlement} -バリディアム上で実行されたトランザクションは、親チェーンが当該トランザクションの有効性を検証するまでは、完全に確定しません。 バリディアム上で実行されたすべての処理は、最終的にメインネットで決済される必要があります。 また、イーサリアムブロックチェーンはバリディアムのユーザーに対して「決済保証」を提供するため、オンチェーンでコミットされたオフチェーンのトランザクションは取消／改変が不可能になります。 +バリディアム上で実行されたトランザクションは、親チェーンが当該トランザクションの有効性を検証するまでは、完全に確定しません。 バリディアム上で実行されたすべての処理は、最終的にメインネットで決済される必要があります。 イーサリアムブロックチェーンは、Validiumユーザーに「決済保証」も提供します。つまり、オンチェーンにコミットされると、オフチェーントランザクションを覆したり変更したりすることはできません。 ### セキュリティ {#security} -イーサリアムはさらに、決済レイヤーとして動作することで、バリディアムの状態遷移についてもその有効性を保証します。 バリディアムチェーン上で実行されたオフチェーンのトランザクションは、イーサリアムのベースレイヤー上のスマートコントラクトによって検証されます。 +イーサリアムはさらに、決済レイヤーとして動作することで、バリディアムの状態遷移についてもその有効性を保証します。 Validiumチェーンで実行されるオフチェーントランザクションは、イーサリアムのベースレイヤー上のスマートコントラクトを介して検証されます。 -オンチェーンの検証者コントラクトにより、当該の証明が無効だと判断された場合、トランザクションは却下されます。 つまり、バリディアムのオペレーターは、バリディアムの状態を更新する事前に、イーサリアムのプロトコルが要求する有効性の条件を満たす必要があります。 +オンチェーンの検証者コントラクトが証明を無効と判断した場合、トランザクションは拒否されます。 つまり、バリディアムのオペレーターは、バリディアムの状態を更新する事前に、イーサリアムのプロトコルが要求する有効性の条件を満たす必要があります。 ## バリディアムはどのように機能するのか？ {#how-does-validium-work} ### トランザクション {#transactions} -各ユーザーは、バリディアムチェーンにおいてトランザクションの実行に責任を負うノードであるオペレーターにトランザクションを送信します。 バリディアムの実装により、バリディアムチェーンの実行を単独のオペレーターが担う場合と、[プルーフ・オブ・ステーク（PoS）](/developers/docs/consensus-mechanisms/pos/)のメカニズムを用いてオペレーターをローテーションする場合があります。 +各ユーザーは、バリディアムチェーンにおいてトランザクションの実行に責任を負うノードであるオペレーターにトランザクションを送信します。 Validiumによっては、単独のオペレーターを使用してチェーンを実行する場合や、[プルーフ・オブ・ステーク(PoS)](/developers/docs/consensus-mechanisms/pos/)メカニズムに依存してオペレーターをローテーションさせる場合があります。 オペレーターは、複数のトランザクションをバッチ化した上で、検証のために証明サーキットに送信します。 証明サーキットは、このトランザクションバッチ（およびその他の関連データ）をインプットとして受け取り、操作が正しく実行されたことを検証する有効性証明をアウトプットとして出力します。 -### ステート・コミットメント {#state-commitments} +### 状態コミットメント {#state-commitments} バリディアムの状態は、ルートがイーサリアムのメインコントラクトに保存されたマークルツリーとしてハッシュ化されます。 マークルルート（ステートルートとも呼ぶ）は、バリディアムチェーンにおける各アカウントおよび残高の現在状態に対する暗号コミットメントの役割を担います。 -オペレーターが状態を更新するには、（トランザクションを実行した後で）新規の状態ルートを計算し、これをオンチェーンのコントラクトに送信する必要があります。 有効性証明が確認されると、提案された状態が承認され、バリディアムが新たな状態ルートに移行します。 +状態更新を実行するには、オペレーターは（トランザクションを実行した後に）新しい状態ルートを計算し、それをオンチェーンコントラクトに提出する必要があります。 有効性証明が確認されると、提案された状態が承認され、バリディアムが新たな状態ルートに移行します。 -### 入金と出金 {#deposits-and-withdrawals} +### 預け入れと引き出し {#deposits-and-withdrawals} -各ユーザーは、オンチェーンのコントラクトにETH（またはその他のERC互換トークン）を預け入れることで、イーサリアムからバリディアムに資金を移動できます。 当該コントラクトが入金イベントをオフチェーンのバリディアムにリレーし、入金額と同じ額がバリディアムチェーン上のユーザーアドレスに追加されます。 オペレーターは同時に、入金トランザクションを新規バッチに追加します。 +ユーザーは、オンチェーンコントラクトにETH（または任意のERC互換トークン）を預け入れることで、イーサリアムからValidiumに資金を移動します。 コントラクトは、入金イベントをオフチェーンのValidiumに中継し、ユーザーのアドレスに預け入れ額と同額が貸方記入されます。 オペレーターは同時に、入金トランザクションを新規バッチに追加します。 資金をメインネットに戻したい場合は、バリディアム上で出金トランザクションを開始し、オペレーターに送信します。オペレーターは、この出金リクエストに対して検証を行った上で、次のバッチに追加します。 また、バリディアムチェーン上のユーザー資産は、ユーザーがバリディアムチェーンから退出する事前に破壊されます。 当該バッチに関連付けられた有効性証明が確認だれると、ユーザーはメインのコントラクトを呼び出し、初回のデポジットの残余分を引き出すことができます。 バリディアムのプロトコルでは、検閲耐性のメカニズムとして、ユーザーはオペレーターを介さずに直接バリディアム上のコントラクトから資産を引き出すことが可能です。 この場合、ユーザーは、アカウントが状態ルートに含まれることを示すマークル証明を検証者コントラクトに提供する必要があります。 この証明が承認されれば、ユーザーはメインのコントラクトにおける引き出し関数を呼び出し、バリディアムから資金を退出させることができます。 -### バッチの送信 {#batch-submission} +### バッチ送信 {#batch-submission} オペレーターは、複数のトランザクションからなるバッチを実行した後、それに関連した有効性証明を検証者コントラクトに送信し、メインのコントラクトに新規のステートルートを提案します。 この証明が有効であれば、メインのコントラクトはバリディアムの状態を更新し、当該バッチに含まれるトランザクションの処理を確定します。 -ゼロ知識ロールアップとは異なり、バリディアム上のブロック生成者は、トランザクションを含むバッチのトランザクションデータを公開する必要がありません（ブロックヘッダーのみ公開すればよいです）。 これによりバリディアムは、メインのイーサリアムチェーンに状態データを`calldata`として公開する「ハイブリッド型」のスケーリング・プロトコル（つまり、[レイヤー2](/layer-2/)）ではなく、純粋にオフチェーンのスケーリング・プロトコルであると言えます。 +ゼロ知識ロールアップとは異なり、バリディアム上のブロック生成者は、トランザクションを含むバッチのトランザクションデータを公開する必要がありません（ブロックヘッダーのみ公開すればよいです）。 これにより、Validiumは純粋なオフチェーンスケーリングプロトコルとなります。これは、ブロブデータや`calldata`、あるいはその両方の組み合わせを使用して、メインのイーサリアムチェーンに状態データを公開する「ハイブリッド」スケーリングプロトコル（すなわち、[レイヤー2](/layer-2/)）とは対照的です。 ### データ可用性 {#data-availability} -前述のように、バリディアムでは、オペレーターがすべてのトランザクションデータをイーサリアムメインネット外で保存するというオフチェーンのデータ可用性モデルを採用しています。 バリディアムでは、オンチェーンにおけるデータ消費量が少ないため、スケーラビリティが向上し（イーサリアムのデータ処理能力によりスループットが制限されない）、ユーザー手数料が軽減されます（`calldata`を公開する費用が抑えられる）。 +前述の通り、Validiumはオフチェーンのデータ可用性モデルを利用しており、オペレーターはすべてのトランザクションデータをイーサリアムメインネット外に保存します。 Validiumのオンチェーンデータフットプリントが小さいことで、スケーラビリティが向上し（スループットはイーサリアムのデータ処理能力に制限されない）、ユーザー手数料が削減されます（オンチェーンでデータを公開するコストが低い）。 -ただし、オフチェーンのデータ可用性においては、マークル証明の作成／検証に必要なデータが参照できない可能性があるという問題があります。 つまり、オペレーターが悪意で行動する場合、ユーザーはオンチェーンのコントラクトから資金を引き出せない可能性があります。 +しかし、オフチェーンのデータ可用性は、マークル証明の作成や検証に必要なデータが利用できない可能性があるという問題をもたらします。 これは、オペレーターが悪意を持って行動した場合、ユーザーがオンチェーンコントラクトから資金を引き出せなくなる可能性があることを意味します。 -様々なバリディアムのソリューションでは、状態データの保存を分散化することでこの問題を解消しようとします。 具体的には、ブロック生成者は、オフチェーンでデータを保存し、リクエストに応じてユーザーに提供する作業に責任を負う「データ可用性の管理者」に対して、裏付けとなるデータを送信しなければなりません。 +様々なバリディアムのソリューションでは、状態データの保存を分散化することでこの問題を解消しようとします。 これには、ブロック生成者に、オフチェーンデータを保存し、リクエストに応じてユーザーが利用できるようにする責任を負う「データ可用性管理者」に基礎となるデータを送信させることを強制することが含まれます。 -バリディアムにおけるデータ可用性の管理者は、バリディアム上の各バッチに署名することで、オフチェーンのトランザクションに関連したデータの可用性を保証します。 この署名は、オンチェーンの検証者コントラクトが状態更新を承認する事前に確認する「可用性証明」の形を取ります。 +Validiumのデータ可用性管理者は、すべてのValidiumバッチに署名することで、オフチェーントランザクションのデータの可用性を証明します。 これらの署名は「可用性証明」の一形態を構成し、オンチェーンの検証者コントラクトは状態更新を承認する前にこれをチェックします。 さまざまなバリディアムの実装により、データ可用性の管理アプローチは異なります。 具体的には、信頼できる当事者のみに状態データを保存させる方法と、無作為に指定したバリデータにこのタスクを委任する方法があります。 -#### データ可用性委員会（DAC） {#data-availability-committee} +#### データ可用性委員会(DAC) {#data-availability-committee} -一部のバリディアム・ソリューションでは、オフチェーンにおけるデータの可用性を保証するために、状態コピーの保存およびデータ可用性証明の提供を担う信頼されるエンティティの集団を指名します（これらのエンティティを総称して「データ可用性委員会」（DAC）と呼びます）。 DACは、メンバーであるユーザーの数が限定されるため、導入やメンバー間の連携が容易になります。 +オフチェーンデータの可用性を保証するため、一部のValidiumソリューションでは、データ可用性委員会(DAC)として総称される信頼できるエンティティのグループを任命し、状態のコピーを保存し、データ可用性の証明を提供します。 DACは、メンバーであるユーザーの数が限定されるため、導入やメンバー間の連携が容易になります。 -その一方で、通常ユーザーは、データを必要とする際に（例：マークル証明を生成するため）、その可用性についてDACを信頼しなければならなくなります。 また、DACのメンバーが[悪意のアクターに侵入され](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view)、オフチェーンのデータを秘匿してしまう可能性があります。 +その一方で、通常ユーザーは、データを必要とする際に（例：マークル証明を生成するため）、その可用性についてDACを信頼しなければならなくなります。 データ可用性委員会のメンバーが[悪意のあるアクターによって侵害され](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view)、オフチェーンデータを差し控える可能性があります。 -[バリディアムにおけるデータ可用性委員会の詳細](https://medium.com/starkware/data-availability-e5564c416424)をご覧ください。 +[Validiumにおけるデータ可用性委員会の詳細](https://medium.com/starkware/data-availability-e5564c416424)。 -#### ボンド提供を伴うデータの可用性 {#bonded-data-availability} +#### ボンド提供型データ可用性 {#bonded-data-availability} その他のバリディアム実装では、オフラインでのデータ保存を担うユーザーに対し、その役割を引き受ける事前にスマートコントラクト上でトークンをステークする（つまり、ロックアップする）ことを要求しています。 このステークは、データ可用性の管理者における正直な行動を保証するための「ボンド」（担保）として機能するため、信頼性の要求を軽減することができます。 これらの参加者がデータの可用性を証明できない場合、預け入れたボンドは没収されます。 -ボンド提供型のデータ可用性スキームでは、要求されるステークを提供すればどのユーザーでもオフチェーンのデータ保存の役割を担うことができます。 これにより、データ可用性の管理者を担えるユーザーの層が拡大するため、データ可用性委員会（DAC）に伴う分散性の低下を抑えることができます。 さらに重要なのは、この暗号経済的なインセンティブにより悪意の行為を抑制するアプローチは、バリディアムにおけるオフラインデータのセキュリティを保証する上で、信頼できるユーザーを指定するアプローチよりもはるかに安全だという点です。 +ボンド提供型データ可用性スキームでは、必要なステークを提供すれば、誰でもオフチェーンデータを保持する役割を割り当てられることができます。 これにより、データ可用性の管理者を担えるユーザーの層が拡大するため、データ可用性委員会（DAC）に伴う分散性の低下を抑えることができます。 さらに重要なのは、この暗号経済的なインセンティブにより悪意の行為を抑制するアプローチは、バリディアムにおけるオフラインデータのセキュリティを保証する上で、信頼できるユーザーを指定するアプローチよりもはるかに安全だという点です。 -[バリディアムにおけるボンド提供型のデータ可用性の詳細](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)をご覧ください。 +[Validiumにおけるボンド提供型データ可用性の詳細](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)。 -## Volitionsとバリディアム {#volitions-and-validium} +## VolitionとValidium {#volitions-and-validium} バリディアムは様々な利点を提供する一方で、トレードオフ（特に、データの可用性）も存在します。 他の多くのスケーリング・ソリューションと同様に、バリディアムの様々な実装は具体的なユースケースに合わせて開発されており、そのひとつとしてVolitionsが挙げられます。 -Volitionsは、ゼロ知識ロールアップとバリディアムチェーンを組み合わせたサービスであるため、これら2つのスケーリング・ソリューションを使い分けることが可能です。 Volitionsを使えば、一部のトランザクションについてはバリディアムによるオフチェーンのデータ可用性を活用しつつ、必要に応じてオンデータのデータ可用性（ゼロ知識ロールアップ）も利用できる自由度を確保できるのです。 これにより、ユースケースごとの要請に応じて、どのトレードオフを選択するのかをユーザーが決定できます。 +Volitionsは、ゼロ知識ロールアップとバリディアムチェーンを組み合わせたサービスであるため、これら2つのスケーリング・ソリューションを使い分けることが可能です。 Volitionを使えば、ユーザーは特定のトランザクションに対してValidiumのオフチェーンデータ可用性を利用しつつ、必要に応じてオンチェーンのデータ可用性ソリューション（ZKロールアップ）に切り替える自由を保持できます。 これにより、ユースケースごとの要請に応じて、どのトレードオフを選択するのかをユーザーが決定できます。 分散型取引所（DEX）の場合、高価値の取引に対してスケーラブルかつプライベートなインフラを提供するバリディアムが適しているかも知れません。 しかし同時に、より高いセキュリティ保証とトラストレス性を望むユーザーのために、ゼロ知識ロールアップを使用することもできます。 -## バリディアムにおけるEVMとの互換性 {#validiums-and-evm-compatibility} +## ValidiumとEVM互換性 {#validiums-and-evm-compatibility} -バリディアムは主に、ゼロ知識ロールアップと同じくトークンのスワップや決済といったシンプルな用途に適しています。 ゼロ知識の証明サーキットで[EVM](/developers/docs/evm/)の命令を証明しようとすると大きな間接費用が発生するため、バリディアムの実装において一般的な計算処理やスマートコントラクトの実行をサポートするのは困難です。 +バリディアムは主に、ゼロ知識ロールアップと同じくトークンのスワップや決済といったシンプルな用途に適しています。 [EVM](/developers/docs/evm/)命令をゼロ知識証明回路で証明するには相当なオーバーヘッドがかかるため、Validium間で一般的な計算やスマートコントラクトの実行をサポートすることは実装が困難です。 一部のバリディアムのプロジェクトでは、効率的な証明のために最適化されたカスタムのバイトコードをコンパイルする際にEVM互換の言語（例：Solidity、Vyper）を用いることで、この問題を回避しようとしています。 このアプローチは、ゼロ知識証明に対応したより新しいVMの場合に重要なEVMオペコードをサポートしていない可能性があるため、デベロッパは最善の利用体験を提供するために高レベル言語で直接コーディングしなければならないという欠点があります。 これにより、デベロッパはまったく新しい開発スタックを用いてDappを開発しなければならなくなり、現在のイーサリアム・インフラとの互換性が失われてしまうため、問題がさらに悪化します。 -しかし一部の開発チームでは、既存のEVMオペコードをゼロ知識証明サーキットのために最適化する作業を進めています。 この取り組みを通じて、プログラムの正確な実行を証明するEVM互換のVMとしてのゼロ知識イーサリアム仮想マシン（zkEVM）の開発が期待されています。 ZkEVMが実現した場合、バリディアムチェーンはオフチェーンでスマートコントラクトを実行し、有効性証明を送信することで、オフチェーンにおける計算をイーサリアム上で（再実行せずに）証明することができます。 +しかし一部の開発チームでは、既存のEVMオペコードをゼロ知識証明サーキットのために最適化する作業を進めています。 この取り組みを通じて、プログラムの正確な実行を証明するEVM互換のVMとしてのゼロ知識イーサリアム仮想マシン（zkEVM）の開発が期待されています。 zkEVMを使用すると、Validiumチェーンはオフチェーンでスマートコントラクトを実行し、有効性証明を提出してイーサリアム上でオフチェーンの計算を（再実行することなく）検証できます。 -[zkEVMの詳細](https://www.alchemy.com/overviews/zkevm)をご覧ください。 +[zkEVMの詳細](https://www.alchemy.com/overviews/zkevm)。 -## バリディアムは、イーサリアムのスケーラビリティをどのように向上させるのか？ {#scaling-ethereum-with-validiums} +## Validiumによるイーサリアムのスケーリング {#scaling-ethereum-with-validiums} -### 1. オフチェーンにおけるデータ保存 {#off-chain-data-storage} +### 1. オフチェーンデータストレージ {#offchain-data-storage} -オプティミスティック・ロールアップやゼロ知識ロールアップといったレイヤー2のスケーリングプロジェクトでは、純粋にオフチェーンのみを活用したスケーリング・プロトコル(例：[プラズマ](/developers/docs/scaling/plasma/))の場合に実現可能な無限のスケーラビリティを犠牲にする代わりに、トランザクションデータの一部をL1上で公開することでセキュリティを強化しています。 しかし同時に、ロールアップのスケーラビリティに関する特性は、イーサリアムメインネットのデータ帯域により制限されます([データシャーディング](/roadmap/danksharding/)では、この理由により、イーサリアムのデータストレージ容量の向上を提案しています)。 +レイヤー2スケーリングプロジェクト(オプティミスティック・ロールアップやZKロールアップなど)では、純粋なオフチェーンスケーリングプロトコル（例：[Plasma](/developers/docs/scaling/plasma/)）の無限のスケーラビリティを犠牲にする代わりに、L1上で一部のトランザクションデータを公開することでセキュリティを確保しています。 しかしこれは、ロールアップのスケーラビリティ特性がイーサリアムメインネットのデータ帯域幅によって制限されることを意味します（このため、[データシャーディング](/roadmap/danksharding/)はイーサリアムのデータストレージ容量を改善することを提案しています）。 -バリディアムでは、すべてのトランザクションデータをオフチェーンで保存し、状態アップデートをメインのイーサリアムチェーンにリレーする際にのみ状態コミットメント（および有効性証明）を送信することでスケーラビリティを達成しています。 しかしバリディアムは、有効性証明を用いることで、その他の純粋にオフチェーンのスケーリングソリューション（プラズマや[サイドチェーン](/developers/docs/scaling/sidechains/)）よりも高いセキュリティ保証を提供しています。 バリディアムでは、イーサリアムがオフチェーンのトランザクションを検証する前に処理しなければならないデータ量が軽減されるため、メインネットのスループットを大きく改善できる設計を実現しています。 +Validiumは、すべてのトランザクションデータをオフチェーンに保持し、状態更新をメインのイーサリアムチェーンに中継する際に状態コミットメント（と有効性証明）のみを投稿することで、スケーラビリティを実現します。 しかし、有効性証明の存在により、ValidiumはPlasmaや[サイドチェーン](/developers/docs/scaling/sidechains/)を含む他の純粋なオフチェーンスケーリングソリューションよりも高いセキュリティ保証を提供します。 オフチェーントランザクションを検証する前にイーサリアムが処理しなければならないデータ量を減らすことで、Validiumの設計はメインネットのスループットを大幅に拡張します。 ### 2. 再帰的証明 {#recursive-proofs} 再帰的な証明とは、他の証明の有効性を証明する有効性証明です。 このような「証明に対する証明」は、最終的にこれまで作成されたすべての証明を証明できる1つの最終証明が作成されるまで、複数の証明を再帰的に集約することで実行されます。 再帰的証明は、1件の有効性証明で検証できるトランザクションの数を増やすため、ブロックチェーンの処理速度におけるスケーラビリティ向上を実現します。 -通常、バリディアムのオペレーターがイーサリアムに提出する有効性証明は、単一のブロック全体を検証します。 これに対し、再帰的証明では、1件の再帰的証明を用いてバリディアム上の複数のブロックの有効性を同時に確認することができます。これは、再帰的証明のサーキットにおいては、複数のブロック証明を1件の最終証明に再帰的に集約できるためです。 オンチェーンの検証者コントラクトがこの再帰的証明を承認すると、その対象である裏付けのブロックすべてがただちに確定します。 +通常、バリディアムのオペレーターがイーサリアムに提出する有効性証明は、単一のブロック全体を検証します。 これに対し、再帰的証明では、1件の再帰的証明を用いてバリディアム上の複数のブロックの有効性を同時に確認することができます。これは、再帰的証明のサーキットにおいては、複数のブロック証明を1件の最終証明に再帰的に集約できるためです。 オンチェーンの検証者コントラクトが再帰的証明を受け入れた場合、基礎となるすべてのブロックは直ちにファイナライズされます。 -## バリディアムの長所と短所 {#pros-and-cons-of-validium} +## Validiumの長所と短所 {#pros-and-cons-of-validium} -| 長所 | 短所 | -| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | -| 有効性証明により、オフチェーンにおけるトランザクションの完全性が確保でき、オペレーターが無効な状態アップデートをファイナライズできなくなる。 | 有効性証明を生成するには特別なハードウェアが必要なため、分散化が低下するリスクがある。 | -| ユーザーがより効率的に資金を利用できる（イーサリアムへの資金引き出しにおいて、遅延が発生しない）。 | 汎用的な計算／スマートコントラクトに対するサポートが限定的であり、開発には特殊な言語が必要である。 | -| 高価値の取引用に用いられる不正証明ベースのシステムを標的とする一部の経済的攻撃に対する脆弱性がない。 | ゼロ知識証明を生成するには高い処理能力が必要であり、低スループットの用途においてはコスト効率が悪い。 | -| calldataをイーサリアムメインネットに送信しないため、ユーザーのガス代が軽減される。 | ユーザーの主観ではファイナリティを得るまでの時間が長い（ゼロ知識証明を生成するのに10〜30分が必要）が、紛争による遅延が生じないため、完全なファイナリティはより迅速に得られる。 | -| トランザクションにおけるプライバシーやスケーラビリティが重視される資金取引やブロックチェーンゲームなど、特定のユースケースに適している。 | 所有権に対するマークル証明を生成するには常にオフチェーンのデータが利用可能でなければならないため、ユーザーの資金引き出しが妨害される可能性がある。 | -| オフチェーンにおけるデータの可用性により、より高いスループットとスケーラビリティが実現できる。 | 純粋に暗号論的なセキュリティメカニズムに依存しているゼロ知識ロールアップとは異なり、信頼性の前提と暗号経済的なインセンティブに依存したセキュリティモデルである。 | +| 長所 | 短所 | +| -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | +| 有効性証明は、オフチェーントランザクションの完全性を強制し、オペレーターが無効な状態更新をファイナライズするのを防ぎます。 | 有効性証明を生成するには特別なハードウェアが必要なため、分散化が低下するリスクがある。 | +| ユーザーがより効率的に資金を利用できる（イーサリアムへの資金引き出しにおいて、遅延が発生しない）。 | 汎用的な計算／スマートコントラクトに対するサポートが限定的であり、開発には特殊な言語が必要である。 | +| 高価値の取引用に用いられる不正証明ベースのシステムを標的とする一部の経済的攻撃に対する脆弱性がない。 | ゼロ知識証明を生成するには高い処理能力が必要であり、低スループットの用途においてはコスト効率が悪い。 | +| calldataをイーサリアムメインネットに送信しないため、ユーザーのガス代が軽減される。 | ユーザーの主観ではファイナリティを得るまでの時間が長い（ゼロ知識証明を生成するのに10〜30分が必要）が、紛争による遅延が生じないため、完全なファイナリティはより迅速に得られる。 | +| トランザクションにおけるプライバシーやスケーラビリティが重視される資金取引やブロックチェーンゲームなど、特定のユースケースに適している。 | 所有権のマークル証明を生成するには、オフチェーンデータが常に利用可能である必要があるため、ユーザーは資金の引き出しを妨げられる可能性があります。 | +| オフチェーンのデータ可用性は、より高いレベルのスループットを提供し、スケーラビリティを向上させます。 | 純粋に暗号論的なセキュリティメカニズムに依存しているゼロ知識ロールアップとは異なり、信頼性の前提と暗号経済的なインセンティブに依存したセキュリティモデルである。 | -### バリディアム／Volitionsの活用 {#use-validium-and-volitions} +### Validium/Volitionの使用 {#use-validium-and-volitions} 複数のプロジェクトにより、Dappに組み込み可能なバリディアムおよびVolitionsの実装が提供されています。 -**StarkWare StarkEx** - _StarkExは、有効性証明ベースのイーサリアムレイヤー2（(L2）の スケーリング・ソリューションです。 ゼロ知識ロールアップあるいはバリディアムのいずれかを用いたデータ可用性モードを選択できます。_ +**StarkWare StarkEx** - _StarkExは、有効性証明に基づくイーサリアムのレイヤー2 (L2) スケーラビリティソリューションです。_ ZKロールアップまたはValidiumのデータ可用性モードのいずれかで動作できます。_ - [ドキュメント](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) - [ウェブサイト](https://starkware.co/starkex/) -**Matter Labs zkPorter**- _zkPorterは、ゼロ知識ロールアップとシャーディングを結合したハイブリッド型のアプローチによりデータ化要請を追跡する、レイヤー2のスケーリング・プロトコルです。 任意の数のシャードをサポートしており、シャードごとに異なるデータ可用性ポリシーを定めることができます。_ +**Matter Labs zkPorter**- _zkPorterは、zkRollupとシャーディングのアイデアを組み合わせたハイブリッドアプローチでデータ可用性に取り組むレイヤー2スケーリングプロトコルです。_ 任意の数のシャードをサポートでき、それぞれが独自のデータ可用性ポリシーを持っています。_ - [ブログ](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) - [ドキュメント](https://docs.zksync.io/zksync-protocol/rollup/data-availability) - [ウェブサイト](https://zksync.io/) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [バリディアムとレイヤー2のツー・バイ・ツー：第99号](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) -- [ゼロ知識ロールアップとバリディアムの比較](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) -- [Volitionおよび新たなデータ可用性のアプローチ](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) -- [ロールアップ、バリディアム、そしてVolitions：イーサリアムにおける最新のスケーリングソリューションについて知る](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [Validiumとレイヤー2 Two-By-Two — 第99号](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) +- [ZKロールアップ vs Validium](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) +- [Volitionと新たなデータ可用性スペクトラム](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) +- [ロールアップ、Validium、Volition：最新のイーサリアムスケーリングソリューションについて学ぶ](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [イーサリアムロールアップ実践ガイド](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) diff --git a/public/content/translations/ja/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/ja/developers/docs/scaling/zk-rollups/index.md index 5011a270aaf..0f69e4cace0 100644 --- a/public/content/translations/ja/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/ja/developers/docs/scaling/zk-rollups/index.md @@ -1,46 +1,46 @@ --- -title: ゼロ知識ロールアップ -description: イーサリアムコミュニティで利用されるスケーリングソリューションであるゼロ知識ロールアップについて紹介する。 +title: "ゼロ知識ロールアップ" +description: "イーサリアムコミュニティで利用されるスケーリングソリューションであるゼロ知識ロールアップについて紹介する。" lang: ja --- -ゼロ知識ロールアップ（ZKロールアップ）とは、計算および状態保存をオフチェーンで実行することで、イーサリアムメインネットのスループットを向上するための、レイヤー2の[スケーリングソリューション](/developers/docs/scaling/)です。 ZKロールアップは、数千件のトランザクションをバッチ処理した上で、最低限のサマリーデータのみをメインネットに書き込みます。 このサマリーデータには、イーサリアムの状態に対して変更すべき事項の定義と、それらの変更が正しいことを示す暗号学的証明が含まれます。 +ゼロ知識ロールアップ (ZKロールアップ) は、計算と状態ストレージをオフチェーンに移動させることでイーサリアムメインネットのスループットを向上させるレイヤー2の[スケーリングソリューション](/developers/docs/scaling/)です。 ZKロールアップは、数千件のトランザクションをバッチ処理した上で、最低限のサマリーデータのみをメインネットに書き込みます。 このサマリーデータには、イーサリアムの状態に対して変更すべき事項の定義と、それらの変更が正しいことを示す暗号学的証明が含まれます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[イーサリアムのスケーリング](/developers/docs/scaling/)と[レイヤー2](/layer-2)のページを読んで理解しておくことをお勧めします。 +[イーサリアムのスケーリング](/developers/docs/scaling/)と[レイヤー2](/layer-2)に関するページを読んで理解しておく必要があります。 ## ゼロ知識ロールアップとは何か？ {#what-are-zk-rollups} -**ゼロ知識ロールアップ（ZKロールアップ）**は、複数のトランザクションをひとつのバッチにまとめて（ロールアップする）、このバッチをオフチェーンで実行します。 計算をオフチェーンで実行することで、ブロックチェーンに書き込む必要があるデータの量を削減することができます。 ZKロールアップのオペレーターは、個別のトランザクションを送信する代わりに、バッチに含まれるすべてのトランザクションを実行するのに必要な変更のサマリーのみを送信します。 同時に、これらの変更の正しさを証明するために、[有効性証明](/glossary/#validity-proof)を生成します。 +**ゼロ知識ロールアップ (ZKロールアップ)**は、トランザクションを束ねて (あるいは「ロールアップ」して) オフチェーンで実行されるバッチにします。 オフチェーン計算により、ブロックチェーンに投稿する必要があるデータ量が削減されます。 ZKロールアップのオペレーターは、個別のトランザクションを送信する代わりに、バッチに含まれるすべてのトランザクションを実行するのに必要な変更のサマリーのみを送信します。 また、変更の正しさを証明するために[有効性証明](/glossary/#validity-proof)も生成します。 -ZKロールアップの状態は、イーサリアムネットワーク上でデプロイされたスマートコントラクトにより管理されます。 ZKロールアップの状態を更新するために、ZKロールアップのノードは検証のための有効性証明を送信する必要があります。 前述したように、この有効性証明は、ロールアップにより提案された状態の変更が、バッチに含まれるトランザクションを実行した結果と同一であることを暗号論的に保証します。 つまり、ZKロールアップを用いる場合、[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)の場合のようにすべてのトランザクションデータをイーサリアムに書き込む必要はなく、有効性証明を提要するだけでイーサリアム上のトランザクションをファイナライズすることができます。 +ZKロールアップの状態は、イーサリアムネットワーク上でデプロイされたスマートコントラクトにより管理されます。 ZKロールアップの状態を更新するために、ZKロールアップのノードは検証のための有効性証明を送信する必要があります。 前述したように、この有効性証明は、ロールアップにより提案された状態の変更が、バッチに含まれるトランザクションを実行した結果と同一であることを暗号論的に保証します。 これは、ZKロールアップが[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)のようにすべてのトランザクションデータをオンチェーンに投稿するのではなく、イーサリアムでトランザクションをファイナライズするために有効性証明を提供するだけでよいことを意味します。 -ZKロールアップのコントラクトが有効性証明が正しいことを確認した時点で出金トランザクションが実行されるため、ZKロールアップからイーサリアムの資金移動において遅延が発生しません。 一方、オプティミスティック・ロールアップからの資金の引き出しの場合、すべてのユーザーが[不正証明](/glossary/#fraud-proof)を用いて出金トランザクションに対してチャレンジできるようにするための遅延期間が必要になります。 +ZKロールアップのコントラクトが有効性証明が正しいことを確認した時点で出金トランザクションが実行されるため、ZKロールアップからイーサリアムの資金移動において遅延が発生しません。 逆に、オプティミスティック・ロールアップからの資金の引き出しには、誰でも[不正証明](/glossary/#fraud-proof)で出金トランザクションに異議を申し立てることができるように、遅延が伴います。 -ZKロールアップでは、トランザクションを`calldata`としてイーサリアムに書き込みます。 `calldata` とは、スマートコントラクトの関数を外部から呼び出す際に含まれるデータが格納される場所を指します。 `calldata` に含まれる情報はブロックチェーン上で公開されるため、すべてのユーザーが独自にロールアップの状態を再構築することができます。 ZKロールアップでは、圧縮技術を用いてトランザクションデータのサイズを縮小します。例えば、アカウントはアドレスではなくインデックスで表されるため、28バイト分のデータが節約できます。 ロールアップにおいては、オンチェーンへのデータ公開が大きなコストとなるため、データ圧縮はユーザー費用を引き下げる効果を持ちます。 +ZKロールアップは、トランザクションを`calldata`としてイーサリアムに書き込みます。 `calldata`は、スマートコントラクトの関数への外部呼び出しに含まれるデータが保存される場所です。 `calldata`内の情報はブロックチェーン上で公開されるため、誰でも独自にロールアップの状態を再構築できます。 ZKロールアップでは、圧縮技術を用いてトランザクションデータのサイズを縮小します。例えば、アカウントはアドレスではなくインデックスで表されるため、28バイト分のデータが節約できます。 オンチェーンでのデータ公開はロールアップにとって大きなコストとなるため、データ圧縮によってユーザーの手数料を削減できます。 -## ZKロールアップは、イーサリアムとどのようにやりとりするか？ {#zk-rollups-and-ethereum} +## ZKロールアップとイーサリアム {#zk-rollups-and-ethereum} -ZKロールアップのチェーンは、イーサリアムブロックチェーン上で動作するオフチェーンのプロトコルであり、イーサリアムのオンチェーンのスマートコントラクトにより管理されます。 ZKロールアップでは、メインネット外でトランザクションを実行しますが、オフチェーンのトランザクションをまとめたバッチをオンチェーンのロールアップコントラクトに定期的に書き込みます。 このトランザクション記録は、イーサリアムブロックチェーンの場合と同様に改変不可であり、ZKロールアップのチェーンを形成します。 +ZKロールアップチェーンは、イーサリアムブロックチェーン上で動作するオフチェーンプロトコルであり、オンチェーンのイーサリアムスマートコントラクトによって管理されます。 ZKロールアップはメインネットの外部でトランザクションを実行しますが、オフチェーンのトランザクションバッチをオンチェーンのロールアップコントラクトに定期的にコミットします。 このトランザクション記録は、イーサリアムブロックチェーンの場合と同様に改変不可であり、ZKロールアップのチェーンを形成します。 ZKロールアップのコアアーキテクチャは、以下のコンポーネントで構成されます： -1. **オンチェーンのコントラクト**: 前述した通り、ZKロールアップのプロトコルはイーサリアム上で実行されるスマートコントラクトにより管理されます。 これには、ロールアップの各ブロックを保存し、入金状態を追跡し、状態更新を監視するメインのコントラクトが含まれます。 オンチェーンにおけるもう一つのコントラクト（検証者コントラクト）は、ブロック生成者が送信したゼロ知識証明を検証します。 つまり、イーサリアムはZKロールアップにおけるベースレイヤー（「レイヤー1」）の役割を果たします。 +1. **オンチェーンコントラクト**：前述のとおり、ZKロールアッププロトコルはイーサリアム上で実行されるスマートコントラクトによって制御されます。 これには、ロールアップの各ブロックを保存し、入金状態を追跡し、状態更新を監視するメインのコントラクトが含まれます。 別のオンチェーンコントラクト (検証者コントラクト) は、ブロックプロデューサーによって提出されたゼロ知識証明を検証します。 つまり、イーサリアムはZKロールアップにおけるベースレイヤー（「レイヤー1」）の役割を果たします。 -2. **オフチェーンの仮想マシン（VM）**: ZKロールアップのプロトコルはイーサリアム上に置かれますが、トランザクションの実行および状態保存は、[EVM](/developers/docs/evm/)とは独立した別個の仮想マシン上で行われます。 このオフチェーンの仮想マシンは、ZKロールアップ上のトランザクションに対する実行環境であり、ZKロールアップのプロトコルにおける第2層（つまり、「レイヤー2」）の役割を果たします。 イーサリアムメインネット上で検証された有効性証明により、オフチェーンのVMにおける状態遷移の正しさが保証されます。 +2. **オフチェーン仮想マシン (VM)**：ZKロールアッププロトコルはイーサリアム上に存在しますが、トランザクションの実行と状態保存は、[EVM](/developers/docs/evm/)とは独立した別の仮想マシンで行われます。 このオフチェーンVMは、ZKロールアップ上のトランザクションの実行環境であり、ZKロールアッププロトコルのセカンダリレイヤー、つまり「レイヤー2」として機能します。 イーサリアムメインネットで検証された有効性証明は、オフチェーンVMにおける状態遷移の正しさを保証します。 -ZKロールアップは、イーサリアムとは別個に実行されるもののセキュリティについてはイーサリアムに依存するオフチェーンのプロトコルであるため、「ハイブリッド型のスケーリング・ソリューション」であると言えます。 具体的には、イーサリアムネットワークがZKロールアップにおける状態更新が有効であることを強制し、ロールアップの状態更新の裏付けとなるデータの可用性を保証します。 この結果、ZKロールアップは、それ自体がセキュリティ特性の維持に責任を負う[サイドチェーン](/developers/docs/scaling/sidechains/)や、[バリディアム](/developers/docs/scaling/validium/)のように、有効性証明によりイーサリアム上でトランザクションを検証する点は共通しているもののトランザクションデータを別の場所に保存する、純粋にオフチェーンのみを活用したスケーリング・ソリューションと比較すると、大幅に安全性が高いと言えます。 +ZKロールアップは「ハイブリッドスケーリングソリューション」、つまり独立して動作するもののイーサリアムからセキュリティを継承するオフチェーンプロトコルです。 具体的には、イーサリアムネットワークがZKロールアップにおける状態更新が有効であることを強制し、ロールアップの状態更新の裏付けとなるデータの可用性を保証します。 その結果、ZKロールアップは、自身のセキュリティ特性に責任を持つ[サイドチェーン](/developers/docs/scaling/sidechains/)や、同じく有効性証明を用いてイーサリアム上のトランザクションを検証するもののトランザクションデータを別の場所に保存する[validiums](/developers/docs/scaling/validium/)のような、純粋なオフチェーンスケーリングソリューションよりもかなり安全です。 ZKロールアップでは、以下の事項につきメインのイーサリアムプロトコルに依存します： ### データ可用性 {#data-availability} -ZKロールアップでは、オフチェーンで処理されたすべてのトランザクションの状態データをイーサリアムに書き込みます。 個人または企業のユーザーは、このデータを用いてロールアップの状態を再現し、チェーン自体を検証することができます。 イーサリアムでは、ネットワークのすべての参加者に対し、このデータを`calldata`として提供します。 +ZKロールアップは、オフチェーンで処理されたすべてのトランザクションの状態データをイーサリアムに公開します。 個人または企業のユーザーは、このデータを用いてロールアップの状態を再現し、チェーン自体を検証することができます。 イーサリアムは、このデータを`calldata`としてネットワークのすべての参加者が利用できるようにします。 -ZKロールアップでは、状態遷移の正しさがすでに有効性証明により検証済みであるため、オンチェーンに書き込む必要があるトランザクションデータの量は多くありません。 それにも関わらず、データをオンチェーンで保存するのが重要である理由は、これによりLCチェーンの状態をパーミッションレスかつ独立して検証できるようになるからであり、これにより、トランザクションをバッチ化して送信するすべてのユーザーは、悪意のオペレーターがチェーンを検閲したり、凍結したりするのを防ぐことができます。 +有効性証明がすでに状態遷移の信憑性を検証しているため、ZKロールアップは多くのトランザクションデータをオンチェーンで公開する必要はありません。 それでも、データをオンチェーンで保存することは重要です。なぜなら、それによりL2チェーンの状態をパーミッションレスかつ独立して検証でき、ひいては誰もがトランザクションのバッチを提出できるようになり、悪意のあるオペレーターがチェーンを検閲したり凍結したりするのを防ぐことができるからです。 -ユーザーは、ロールアップとのやりとりを実行する場合にオンチェーンでなければなりません。 状態データへのアクセス権限を持たないユーザーは、各自のアカウント残高を照会したり、状態情報に依存する取引（例：出金）を開始することができません。 +ユーザーがロールアップと対話するためにはオンチェーンであることが必要です。 状態データへのアクセス権限を持たないユーザーは、各自のアカウント残高を照会したり、状態情報に依存する取引（例：出金）を開始することができません。 ### トランザクションのファイナリティ {#transaction-finality} @@ -58,49 +58,49 @@ ZKロールアップでは、セキュリティ対策として、ユーザーが ZKロールアップのユーザーは、トランザクションに署名した上で、トランザクションの処理および次のバッチへの追加のためにL2オペレーターに送信します。 場合により、このオペレーターは、トランザクションを実行し、バッチ化した上でL1に送信する中央集権的なエンティティ（シーケンサーと呼ぶ）の場合があります。 このシステムにおけるシーケンサーは、L2のブロックを生成し、ロールアップのトランザクションをZKロールアップのコントラクトに追加できる唯一のエンティティです。 -このアプローチを採用しないZKロールアップでは、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)による複数のバリデータがオペレーターの役割をローテーションで担います。 オペレーターに立候補するユーザーは、ロールアップのコントラクトに資金を入金し（ステーキング）、このステークの規模に応じて、次のロールアップ・バッチを生成する役割を与えられる可能性が増減します。 悪意の行動を行ったオペレーターのステークは没収されるため、有効なブロックの送信を促すインセンティブとして機能します。 +他のZKロールアップは、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)のバリデータセットを使用して、オペレーターの役割をローテーションさせることがあります。 オペレーターに立候補するユーザーは、ロールアップのコントラクトに資金を入金し（ステーキング）、このステークの規模に応じて、次のロールアップ・バッチを生成する役割を与えられる可能性が増減します。 悪意の行動を行ったオペレーターのステークは没収されるため、有効なブロックの送信を促すインセンティブとして機能します。 -#### ZKロールアップにおいてトランザクションデータをイーサリアムに書き込む方法 {#how-zk-rollups-publish-transaction-data-on-ethereum} +#### ZKロールアップがイーサリアム上でトランザクションデータを公開する方法 {#how-zk-rollups-publish-transaction-data-on-ethereum} -すでに述べた通り、トランザクションデータは`calldata`としてイーサリアムに書き込まれます。 `calldata`とは、スマートコントラクトにおいて関数に引数を渡すためのデータ領域であり、[メモリ](/developers/docs/smart-contracts/anatomy/#memory)と同様に動作します。 `calldata` はイーサリアムの状態として保存されませんが、イーサリアムチェーンの[履歴ログ](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)としてオンチェーン上で永続します。 `calldata` はイーサリアムの状態を変化させないため、オンチェーン上でのデータ保存が安価に実行できます。 +説明したように、トランザクションデータは`calldata`としてイーサリアムに公開されます。 `calldata`は、関数に引数を渡すために使用されるスマートコントラクト内のデータ領域であり、[メモリ](/developers/docs/smart-contracts/anatomy/#memory)と同様に動作します。 `calldata`はイーサリアムの状態の一部として保存されませんが、イーサリアムチェーンの[履歴ログ](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs)の一部としてオンチェーンで永続化されます。 `calldata`はイーサリアムの状態に影響を与えないため、データをオンチェーンで安価に保存する方法となります。 -多くの場合、`calldata`におけるキーワードがトランザクションで呼び出されるスマートコントラクトのメソッドを決定し、当該メソッドへの入力を任意のバイト列として保持します。 ZKロールアップでは、`calldata`を用いて圧縮されたトランザクションデータをオンチェーンに書き込みます。ロールアップのオペレーターの役割は、ロールアップのコントラクトにおいて要求される関数を呼び出し、関数の引数として圧縮データを渡すことにより新規バッチを追加することだけです。 このため、ロールアップにおける手数料の大半はトランザクションデータのオンチェーンの保存において発生するため、ユーザー手数料が軽減されます。 +`calldata`キーワードは、トランザクションによって呼び出されるスマートコントラクトのメソッドを識別し、そのメソッドへの入力を任意のバイトシーケンスの形で保持することがよくあります。 ZKロールアップは`calldata`を使用して圧縮されたトランザクションデータをオンチェーンで公開します。ロールアップオペレーターは、ロールアップコントラクトで必要な関数を呼び出して新しいバッチを追加し、圧縮データを関数引数として渡すだけです。 これにより、ロールアップ手数料の大部分がトランザクションデータのオンチェーン保存に使われるため、ユーザーのコスト削減に役立ちます。 -### ステートコミットメント {#state-commitments} +### 状態コミットメント {#state-commitments} -L2のアカウントおよび残高が含まれるZKロールアップの状態は、[マークルツリー](/whitepaper/#merkle-trees)として表示されます。 マークルツリーのルート（マークルルート）の暗号ハッシュがオンチェーンのコントラクトに保存されるため、ロールアップのプロトコルによりZKロールアップの状態変化を追跡することができます。 +L2のアカウントと残高を含むZKロールアップの状態は、[マークルツリー](/whitepaper/#merkle-trees)として表されます。 マークルツリーのルート (マークルルート) の暗号ハッシュがオンチェーンコントラクトに保存され、ロールアッププロトコルがZKロールアップの状態の変化を追跡できるようになります。 -ロールアップは、一連の新たなトランザクションを実行することで、新しい状態に遷移します。 この状態遷移を開始したオペレーターは、新しい状態ルートを計算し、オンチェーンのコントラクトに送信しなければなりません。 当該バッチの有効性証明が検証者コントラクトにより承認されると、新たなマークルルートがZKロールアップにおける正規の状態ルートになります。 +ロールアップは、一連の新たなトランザクションを実行することで、新しい状態に遷移します。 状態遷移を開始したオペレーターは、新しい状態ルートを計算し、オンチェーンコントラクトに提出する必要があります。 当該バッチの有効性証明が検証者コントラクトにより承認されると、新たなマークルルートがZKロールアップにおける正規の状態ルートになります。 -ZKロールアップのオペレーターは、状態ルートを計算するだけでなく、バッチに含まれるすべてのトランザクションで構成されるマークルツリーのルートであるバッチルートも作成します。 新規バッチが送信されると、ロールアップのコントラクトがバッチルートを保存するため、ユーザーは当該バッチに特定のトランザクション（例：出金リクエスト）が含まれていたかを証明できます。 この場合ユーザーは、トランザクションの詳細、バッチルート、および追加パスを表示する[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)を提供しなければなりません。 +ZKロールアップのオペレーターは、状態ルートを計算するだけでなく、バッチに含まれるすべてのトランザクションで構成されるマークルツリーのルートであるバッチルートも作成します。 新規バッチが送信されると、ロールアップのコントラクトがバッチルートを保存するため、ユーザーは当該バッチに特定のトランザクション（例：出金リクエスト）が含まれていたかを証明できます。 ユーザーは、トランザクションの詳細、バッチルート、およびインクルージョンパスを示す[マークル証明](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)を提供する必要があります。 ### 有効性証明 {#validity-proofs} -ZKロールアップのオペレーターがL1のコントラクトに送信する新しい状態ルートは、ロールアップにおける状態更新の結果です。 例えば、アリスがボブに10トークンを送信する場合、オペレーターは単にアリスの残高を10減らし、ボブの残高を10増やします。 オペレーターはその上で、残高変更後のアカウントデータをハッシュ化し、ロールアップのマークルツリーを再構築した上で、新しいマークルルートをオンチェーンのコントラクトに送信します。 +ZKロールアップのオペレーターがL1のコントラクトに送信する新しい状態ルートは、ロールアップにおける状態更新の結果です。 例えば、アリスがボブに10トークンを送信する場合、オペレーターは単にアリスの残高を10減らし、ボブの残高を10増やします。 その後、オペレーターは更新されたアカウントデータをハッシュ化し、ロールアップのマークルツリーを再構築して、新しいマークルルートをオンチェーンコントラクトに提出します。 しかし、ロールアップのコントラクトは、オペレーターがこの新しいマークルルートがロールアップの状態に対する正しい更新によって生成されたことを証明するまでは、提案された状態コミットメントを自動的に承認しません。 ZKロールアップのオペレーターは、バッチ化されたトランザクションの正しさを証明する簡潔な暗号学的コミットメントである有効性証明を生成することで、これを証明します。 -有効性証明は、ステートメント自体を示さずにその正しさを証明するものであるため、ゼロ知識証明とも呼ばれます。 ZKロールアップでは、有効性証明を用いることで、トランザクションをイーサリアム上で再実行することなく、オフチェーンの状態遷移の正しさを確認することができるのです。 この有効性証明には、[ZK-SNARK](https://arxiv.org/abs/2202.06877)（ゼロ知識の簡潔かつ非双方向の知識アーギュメント）または[ZK-STARK](https://eprint.iacr.org/2018/046)（ゼロ知識のスケーラブルかつ透明性を持った知識アーギュメント）の2種類があります。 +有効性証明は、ステートメント自体を示さずにその正しさを証明するものであるため、ゼロ知識証明とも呼ばれます。 ZKロールアップは、イーサリアム上でトランザクションを再実行することなく、オフチェーンの状態遷移の正しさを確認するために有効性証明を使用します。 これらの証明は、[ZK-SNARK](https://arxiv.org/abs/2202.06877) (ゼロ知識の簡潔な非対話的知識アーギュメント) または[ZK-STARK](https://eprint.iacr.org/2018/046) (ゼロ知識のスケーラブルな透明知識アーギュメント) の形式をとることができます。 -SNARKおよびSTARKのいずれもZKロールアップにおけるオフチェーンの計算処理の完全性を証明するのに有益ですが、それぞれが独自の機能を持ちます。 +SNARKとSTARKはどちらも、ZKロールアップにおけるオフチェーン計算の完全性を証明するのに役立ちますが、それぞれの証明タイプには独自の特徴があります。 -**ZK-SNARK** +**ZK-SNARKs** ZK-SNARKのプロトコルが機能するには、共通参照文字列（CRS）を生成する必要があります。このCRSは、有効性証明を証明、検証するための公開パラメータを提供します。 証明システムのセキュリティは、このCRSの設定に依存しています。つまり、公開パラメータが悪意のアクターに所有された場合、虚偽の有効性証明が生成可能になります。 -一部のZKロールアップでは、ZK-SNARKの証明サーキットに対する公開パラメータの生成を信頼された個人ユーザーが参加する[複数当事者による計算セレモニー（MPC）](https://zkproof.org/2021/06/30/setup-ceremonies/amp/)で実行することで、この問題を解消しようとします。 MPCでは、各参加者がCRSを構築する際に一定のランダム性（「毒性廃棄物」と呼ぶ）を提供した上で、そのランダム性をただちに破壊しなければなりません。 +一部のZKロールアップでは、信頼できる個人が参加する[マルチパーティ計算セレモニー (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) を使用してZK-SNARK回路の公開パラメータを生成することで、この問題を解決しようとします。 MPCでは、各参加者がCRSを構築する際に一定のランダム性（「毒性廃棄物」と呼ぶ）を提供した上で、そのランダム性をただちに破壊しなければなりません。 このような信頼されたユーザーによる関与は、CRS設定のセキュリティを高めるためのものです。 参加者のうち少なくとも1名が正直にインプットを破壊すれば、ZK-SNARKのシステムにおけるセキュリティが保証できます。 しかしこのアプローチでも、システムのセキュリティ保証を毀損しないためには、「参加者は提供したランダム性を消去するはずだ」という信頼が必要になる点は変わりがありません。 ZK-SNARKは、このような信頼の前提という問題を抱えているものの、証明の規模が小さく、一定時間による検証が可能なために広く用いられています。 ZKロールアップの運用コストの大部分はL1における有効性証明の検証において発生するため、L2では、ZK-SNARKを用いることで、メインネット上で迅速かつ安価に検証可能な有効性証明を生成できるのです。 -**ZK-STARK** +**ZK-STARKs** -ZK-STARKは、オフチェーンにおける計算につき、そのインプットを示すことなく正しさを証明できるという点ではZK-SNARKと同じです。 しかし、スケーラビリティおよび透明性において、ZK-STARKはZK-SNARKよりも優れていると評価されています。 +ZK-SNARKと同様に、ZK-STARKは入力を明らかにすることなくオフチェーン計算の有効性を証明します。 しかし、スケーラビリティおよび透明性において、ZK-STARKはZK-SNARKよりも優れていると評価されています。 ZK-STARKでは、共通参照文字列（CRS）の信頼できる設定を必要としないため、「透明性」を持ちます。 ZK-STARKでは、有効性証明の生成および検証につき、CRSの代わりに公開的に検証可能なランダム性を用いてパラメータを設定します。 -ZK-STARKではさらに、有効性証明を証明、検証するのに必要な時間が、証明を要する計算処理の複雑さに応じて_ほぼ線形的に_増化するため、ZK-SNARKよりもスケーラビリティが高いと言えます。 つまりZK-SNARKでは、証明を要する計算処理の規模に応じて、証明および検証に必要な時間が_線形的_に変化します。 このためZK-STARKでは、大規模なデータセットの証明、検証をZK-SNARKよりも短時間で完了できるため、大規模なアプリケーションにとってより有益なのです。 +ZK-STARKは、有効性証明の証明と検証に必要な時間が、基礎となる計算の複雑さに対して_準線形_に増加するため、より高いスケーラビリティも提供します。 ZK-SNARKでは、証明と検証の時間は、基礎となる計算のサイズに対して_線形_にスケールします。 このためZK-STARKでは、大規模なデータセットの証明、検証をZK-SNARKよりも短時間で完了できるため、大規模なアプリケーションにとってより有益なのです。 ZK-STARKはさらに量子コンピュータに対してもセキュリティを防御できます。一方、ZK-SNARKで用いられている楕円曲線暗号（ECC）は、量子コンピュータによる攻撃に対して脆弱性を持つという意見が支配的です。 ZK-STARKの欠点としては、生成される有効性証明のサイズが大きくなるため、イーサリアム上での検証コストが高くなります。 @@ -136,23 +136,23 @@ ZKロールアップのノードは、トランザクションが一定数に達 証明サーキットにおいて状態更新の正しさが検証されると、L2のオペレーターは、計算された有効性証明をL1上の検証者コントラクトに送信します。 検証者コントラクトの検証サーキットでは、この有効性証明の正しさを検証すると同時に、有効性証明の一部である公開インプットについても確認します。 -- **事前のステートルート**: ZKロールアップの古い状態（つまり、当該バッチに含まれるトランザクションの実行前）を反映した、L2チェーンにおいて有効である最後の既知のステートルートです。 +- **実行前状態ルート**：バッチ化されたトランザクションが実行される前のZKロールアップの古い状態ルート。L2チェーンの最後の既知の有効な状態を反映します。 -- **事後のステートルート**: ZKロールアップの新しい状態（つまり、当該バッチに含まれるトランザクションの実行後）を反映し、L2チェーンの最新状態であるルートです。 事後のステートルートは、証明サーキットに状態更新を適用することで得られた最終的なルートです。 +- **実行後状態ルート**：バッチ化されたトランザクションの実行後のZKロールアップの新しい状態ルート。L2チェーンの最新の状態を反映します。 事後のステートルートは、証明サーキットに状態更新を適用することで得られた最終的なルートです。 -- **バッチルート**: 当該バッチのマークルルートであり、バッチに_マークル化_を施し、マークルツリーのルートをハッシュ化することで得られます。 +- **バッチルート**：バッチのマークルルート。バッチ内のトランザクションをマークル化し、ツリーのルートをハッシュ化することによって導出されます。 -- **トランザクションにおけるインプット**: 提出されたバッチにおいて実行されたトランザクションに含まれるデータ。 +- **トランザクション入力**：提出されたバッチの一部として実行されたトランザクションに関連するデータ。 この有効性証明が証明サーキットに合格した場合（つまり、有効性証明が有効である場合）、ロールアップを古い状態（事前のステートルートにより暗号学的にフィンガープリントされる）から新しい状態（事後のステートルートにより暗号学的にフィンガープリントされる）に移行させる、有効なトランザクションのシーケンスが存在することになります。 事前のステートルートがロールアップのコントラクトに保存されたルートと一致し、有効性証明が有効であれば、ロールアップのコントラクトは有効性証明から事後のステートルートを取り出し、ロールアップの変更後の状態を反映するようにステートツリーを更新します。 -### 参加と退出 {#entries-and-exits} +### エントリーとエグジット {#entries-and-exits} ユーザーがZKロールアップに参加するには、L1チェーン上でデプロイされたロールアップのコントラクトにトークンを入金する必要があります。 ロールアップのコントラクトにトランザクションを送信できるのはオペレーターのみであるため、このトランザクションはキュー上で保留されます。 キューに含まれる保留中の入金件数が一定数に達すると、ZKロールアップのオペレーターが入金トランザクションをロールアップのコントラクトに送信します。 ユーザーの資金がロールアップに入金された時点で、ユーザーはトランザクションをオペレーターに送信し、処理させることで、取引を開始できます。 ユーザーは、各自のアカウントデータをハッシュ化し、ハッシュをロールアップのコントラクトに送信し、さらに現在のステートルートを検証するためのマークル証明を提供することで、ロールアップにおける自らの残高を確認できます。 -ZKロールアップからL1への出金は、簡単に実行できます。 出金トランザクションでは、まずロールアップ上の各自の資金をバーン用の特定のアカウントに送信します。 オペレーターがこのトランザクションを次のバッチに追加した時点で、ユーザーは出金リクエストをオンチェーンのコントラクトに送信できます。 この出金リストには、以下を含める必要があります： +ZKロールアップからL1への出金は、簡単に実行できます。 出金トランザクションでは、まずロールアップ上の各自の資金をバーン用の特定のアカウントに送信します。 オペレーターが次のバッチにトランザクションを含めると、ユーザーはオンチェーンコントラクトに出金要求を提出できます。 この出金リストには、以下を含める必要があります： - ユーザーのバーンアカウントへの送金トランザクションが当該バッチに含まれることを証明するマークル証明。 @@ -166,9 +166,9 @@ ZKロールアップからL1への出金は、簡単に実行できます。 出 ## ZKロールアップとEVMの互換性 {#zk-rollups-and-evm-compatibility} -オプティミスティック・ロールアップと異なり、ゼロ知識ロールアップはそれ自体が [イーサリアム仮想マシン (EVM)](/developers/docs/evm/) と互換であるわけではありません。 ゼロ知識の証明サーキットにおいて汎用的なEVMの計算を証明するのは、（上記のトークン転送例のような）単純な計算を証明する場合よりも困難であり、多くのリソースが必要になります。 +オプティミスティック・ロールアップとは異なり、ZKロールアップは[イーサリアム仮想マシン (EVM)](/developers/docs/evm/) とすぐに互換性があるわけではありません。 ゼロ知識の証明サーキットにおいて汎用的なEVMの計算を証明するのは、（上記のトークン転送例のような）単純な計算を証明する場合よりも困難であり、多くのリソースが必要になります。 -しかし、 [ゼロ知識技術の進歩](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) により、EVMの計算にゼロ知識証明を用いるアプローチに対する関心が再び高まっています。 これらの取り組みは、ゼロ知識EVM（zkEVM）の実装を実現することで、プログラム実行の正しさをより効率的に検証できるようにするものです。 ZkEVMは、証明サーキットにおける証明／検証のためにEVMの既存オペコードを再作成するもので、これによりスマートコントラクトの実行が可能になります。 +しかし、[ゼロ知識技術の進歩](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now)により、EVMの計算をゼロ知識証明でラップすることへの関心が再び高まっています。 これらの取り組みは、ゼロ知識EVM（zkEVM）の実装を実現することで、プログラム実行の正しさをより効率的に検証できるようにするものです。 ZkEVMは、証明サーキットにおける証明／検証のためにEVMの既存オペコードを再作成するもので、これによりスマートコントラクトの実行が可能になります。 zkEVMでは、EVMと同様に、インプットに対する計算を実行した時点で状態が遷移します。 しかしzkEVMでは、プログラム実行の各ステップの正しさを検証するためにゼロ知識証明が生成されるという点が異なります。 有効性証明は、仮想マシンの状態（メモリ、スタック、およびストレージ）に関連した操作ならびに計算自体の正しさを検証することができます（つまり、この操作は適切なオペコードを呼び出し、適切に実行されたかを確認できます）。 @@ -178,25 +178,25 @@ EVM互換のZKロールアップを活用することで、デベロッパはゼ ZKロールアップにおけるトランザクション手数料は、イーサリアムメインネットと同じようにガス料金に応じて変化します。 ただしL2においては、ガス料金の仕組みが異なっており、以下のコストの影響を受けます： -1. **ステートへの書き込み**: イーサリアムのステートに書き込む（つまり、イーサリアムブロックチェーンにトランザクションを送信する）場合、固定コストが発生します。 ZKロールアップでは、トランザクションをバッチ化し、固定コストを複数のユーザーに分散させることで、ユーザーあたりのコストを引き下げています。 +1. **状態の書き込み**：イーサリアムの状態に書き込む（つまり、イーサリアムブロックチェーン上でトランザクションを提出する）には固定コストがかかります。 ZKロールアップでは、トランザクションをバッチ化し、固定コストを複数のユーザーに分散させることで、ユーザーあたりのコストを引き下げています。 -2. **データの公開**: ZKロールアップでは、各トランザクションの状態データを`calldata`としてイーサリアムに送信します。 現在、`calldata`のコストは [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) によって管理されています。 `calldata` の非ゼロバイトに対しては16ガス、ゼロバイトに対しては4ガスのコストが、それぞれ規定されています。 各トランザクションに対して支払われるコストは、オンチェーンで公開される`calldata`の規模に応じて決定されます。 +2. **データ公開**：ZKロールアップは、すべてのトランザクションの状態データを`calldata`としてイーサリアムに公開します。 `calldata`のコストは現在[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)によって管理されており、`calldata`の非ゼロバイトには16ガス、ゼロバイトには4ガスのコストがそれぞれ規定されています。 各トランザクションで支払われるコストは、そのためにどれだけの`calldata`をオンチェーンに投稿する必要があるかに影響されます。 -3. **L2オペレーター手数料**：これは、トランザクション処理にかかる計算コストに対する補償としてロールアップオペレーターに支払われる金額で、イーサリアムメインネットにおける[トランザクションの「優先手数料 (チップ) 」](/developers/docs/gas/#how-are-gas-fees-calculated)に似ています。 +3. **L2オペレーター手数料**：これは、イーサリアムメインネット上の[トランザクションの「優先手数料 (チップ)」](/developers/docs/gas/#how-are-gas-fees-calculated)のように、トランザクションの処理で発生した計算コストの補償としてロールアップオペレーターに支払われる金額です。 -4. **有効性証明の生成と検証**: ZKロールアップのオペレーターは、多くのリソースを用いてトランザクションバッチに対する有効性証明を生成しなければなりません。 メインネットにおけるゼロ知識証明の検証にもガス代が発生します（最大50万ガス）。 +4. **証明の生成と検証**：ZKロールアップオペレーターは、トランザクションバッチの有効性証明を生成する必要があり、これはリソースを大量に消費します。 メインネットにおけるゼロ知識証明の検証にもガス代が発生します（最大50万ガス）。 -ZKロールアップでは、トランザクションのバッチ化に加えて、トランザクションデータを圧縮することでユーザー手数料を引き下げています。 イーサリアムのZKロールアップにおける利用コストは、[リアルタイムで確認できます](https://l2fees.info/)。 +ZKロールアップでは、トランザクションのバッチ化に加えて、トランザクションデータを圧縮することでユーザー手数料を引き下げています。 イーサリアムのZKロールアップを使用するのにかかるコストの[リアルタイムの概要を確認](https://l2fees.info/)できます。 -## ZKロールアップは、どのようにイーサリアムのスケーラビリティを向上させるか？ {#scaling-ethereum-with-zk-rollups} +## ZKロールアップによるイーサリアムのスケーリング {#scaling-ethereum-with-zk-rollups} ### トランザクションデータの圧縮 {#transaction-data-compression} -ZKロールアップでは、オフチェーンでの計算を通じてイーサリアム・ベースレイヤーのスループットを向上させますが、実際にスケーラビリティを向上させるのはトランザクションデータを圧縮することによってです。 イーサリアムの [ブロックサイズ](/developers/docs/blocks/#block-size) は、各ブロックが保持できるデータ量を制限しているため、必然的に各ブロックが処理できるトランザクションの数も制限されます。 ZKロールアップでは、トランザクション関連データを圧縮することで、各ブロックで処理されるトランザクションの数が大きく増えるのです。 +ZKロールアップは計算をオフチェーンに移行することでイーサリアムのベースレイヤーのスループットを拡張しますが、スケーリングの真の向上はトランザクションデータの圧縮からもたらされます。 イーサリアムの[ブロックサイズ](/developers/docs/blocks/#block-size)は、各ブロックが保持できるデータを制限し、ひいてはブロックごとに処理されるトランザクションの数も制限します。 ZKロールアップでは、トランザクション関連データを圧縮することで、各ブロックで処理されるトランザクションの数が大きく増えるのです。 ZKロールアップでは、各トランザクションを検証するためにすべての関連データを書き込む必要がないため、オプティミスティック・ロールアップよりもデータの圧縮度が高いと言えます。 ロールアップにおけるアカウントおよび残高の最新状態を再構築する上で、必要最小限のデータのみを送信すればよいのです。 -### 再帰的プルーフ {#recursive-proofs} +### 再帰的証明 {#recursive-proofs} ゼロ知識証明の優位性のひとつとして、他の種類の証明を検証するためにも使用できる点が挙げられます。 例えば、あるZK-SNARKを用いて他の複数のZK-SNARKを検証することができます。 このような「プルーフに対するプルーフ」を再帰的プルーフと呼び、ZKロールアップのスループットを劇的に向上させます。 @@ -206,48 +206,52 @@ ZKロールアップでは、各トランザクションを検証するために ### ZKロールアップの長所と短所 {#zk-rollups-pros-and-cons} -| 長所 | 短所 | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | -| 有効性証明により、オフチェーンのトランザクションの正しさが保証でき、オペレーターが無効な状態遷移を実行するのを防ぐことができる。 | 有効性証明を計算、検証する際にかなりのコストが発生し、ロールアップにおけるユーザー手数料がかさむ可能性がある。 | -| 有効性証明がL1上で検証されれば状態更新が承認されるため、トランザクションのファイナリティをより迅速に実現できる。 | ゼロ知識は複雑な関連技術を要するため、EVM互換のZKロールアップ構築は容易ではない。 | -| [オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons)とは異なり、インセンティブに基づく正直なアクターに依存するのではなく、トラストレス性を持つ暗号学的なメカニズムを通じてセキュリティを確保できる。 | 有効性証明の生成には特殊なハードウェアを必要とするため、少数のユーザーがチェーンを中央集権的に管理する傾向が強まる可能性がある。 | -| L1上でオフチェーンの状態を復元するために必要なデータを保存できるため、セキュリティ、検閲耐性、および分散化が保証される。 | 中央集権的なオペレーター（シーケンサー）がトランザクションの実行順位に影響を及ぼしうる。 | -| ユーザーはL2からの出金を遅延なく行えるため、資本の効率性が高まる。 | 厳格なハードウェア要件によりチェーンを強制的に進められる参加者数が限定されることで、悪意のオペレーターがロールアップの状態を凍結し、ユーザーを検閲するリスクが高まる。 | -| 生存性の前提に依存しないため、ユーザーは資金を保護するためにチェーンを検証する必要がない。 | 一部の証明システム（ZK-SNARKなど）は信頼性に基づく設定が必要であるため、不適切な利用によりZKロールアップのセキュリティモデルが悪用される可能性がある。 | -| 優れたデータ圧縮機能により、イーサリアム上で`calldata`を公開する費用が軽減され、ユーザーのロールアップ手数料を最小限に抑えられる。 | | +| 長所 | 短所 | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | +| 有効性証明はオフチェーンのトランザクションの正しさを保証し、オペレーターが無効な状態遷移を実行するのを防ぎます。 | 有効性証明を計算、検証する際にかなりのコストが発生し、ロールアップにおけるユーザー手数料がかさむ可能性がある。 | +| 有効性証明がL1上で検証されれば状態更新が承認されるため、トランザクションのファイナリティをより迅速に実現できる。 | ゼロ知識は複雑な関連技術を要するため、EVM互換のZKロールアップ構築は容易ではない。 | +| [オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons)のようにインセンティブを与えられたアクターの誠実さに頼るのではなく、セキュリティのためにトラストレスな暗号メカニズムに依存します。 | 有効性証明の生成には特殊なハードウェアを必要とするため、少数のユーザーがチェーンを中央集権的に管理する傾向が強まる可能性がある。 | +| L1にオフチェーンの状態を回復するために必要なデータを保存し、セキュリティ、検閲耐性、分散化を保証します。 | 中央集権的なオペレーター（シーケンサー）がトランザクションの実行順位に影響を及ぼしうる。 | +| ユーザーはL2からの出金を遅延なく行えるため、資本の効率性が高まる。 | 厳格なハードウェア要件によりチェーンを強制的に進められる参加者数が限定されることで、悪意のオペレーターがロールアップの状態を凍結し、ユーザーを検閲するリスクが高まる。 | +| 生存性の前提に依存しないため、ユーザーは資金を保護するためにチェーンを検証する必要がない。 | 一部の証明システム（ZK-SNARKなど）は信頼性に基づく設定が必要であるため、不適切な利用によりZKロールアップのセキュリティモデルが悪用される可能性がある。 | +| より優れたデータ圧縮は、イーサリアム上で`calldata`を公開するコストを削減し、ユーザーのロールアップ手数料を最小限に抑えるのに役立ちます。 | | -### ZKロールアップに関する動画による説明 {#zk-video} +### ZKロールアップの視覚的な説明 {#zk-video} FinematicsによるZKロールアップの説明動画をご覧ください： -## zkEVMの開発プロジェクト {#zkevm-projects} +## zkEVMプロジェクト {#zkevm-projects} 現在、zkEVMの開発に取り組んでいるプロジェクトとしては、以下が挙げられます： -- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVMは、イーサリアム・ファウンデーションによる資金提供に基づき、EVM互換のZKロールアップならびにイーサリアムブロックに対する有効性証明を生成するメカニズムを開発するプロジェクトです。_ +- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVMは、イーサリアム・ファウンデーションから資金提供を受けているプロジェクトで、EVM互換のZKロールアップとイーサリアムブロックの有効性証明を生成するメカニズムを開発しています。_ -- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _イーサリアムメインネット上の分散型ゼロ知識ロールアップであり、ゼロ知識証明による検証が可能なスマートコントラクトなど、イーサリアムのトランザクションを透明性が高い方法で実行するゼロ知識イーサリアム仮想マシン(zkEVM)の開発に取り組んでいます。_ +- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _は、イーサリアムメインネット上の分散型ZKロールアップであり、ゼロ知識イーサリアム仮想マシン (zkEVM) 上で動作します。ゼロ知識証明による検証を伴うスマートコントラクトを含め、イーサリアムのトランザクションを透過的に実行します。_ -- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scrollは、ネイティブのzkEVMを搭載したイーサリアムのレイヤー2ソリューションを開発中のテクノロジー企業です。_ +- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scrollは、イーサリアム向けのネイティブzkEVMレイヤー2ソリューションを構築しているテクノロジー主導の企業です。_ -- **[Taiko](https://taiko.xyz)** - _Taiko は分散型のイーサリアム等価のゼロ知識ロールアップです ([タイプ1のZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))_。 +- **[Taiko](https://taiko.xyz)** - _Taikoは、分散型のイーサリアム等価なZKロールアップ ([タイプ1 ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html)) です。_ -- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Eraは、Matter Labsによって構築されたEVM互換のZKロールアップであり、自社開発のzkEVMを基盤としています。_ +- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Eraは、Matter Labsによって構築されたEVM互換のZKロールアップで、独自のzkEVMを搭載しています。_ -- **[Starknet](https://starkware.co/starknet/)** - _StarkNetは、StarkWareによって開発されたEVM互換のレイヤー2スケーリングソリューションです。_ +- **[Starknet](https://starkware.co/starknet/)** - _StarkNetは、StarkWareによって構築されたEVM互換のレイヤー2スケーリングソリューションです。_ -- **[Morph](https://www.morphl2.io/)** - _Morphは、ハイブリッドのロールアップ・スケーリング・ソリューションで、レイヤー2の状態における異議申し立て問題の対処にゼロ知識証明を利用します。_ +- **[Morph](https://www.morphl2.io/)** - _Morphは、レイヤー2の状態の異議申し立て問題に対処するためにゼロ知識証明を利用するハイブリッドロールアップスケーリングソリューションです。_ -## ZKロールアップの参考文献 {#further-reading-on-zk-rollups} +- **[Linea](https://linea.build)** - _LineaはConsensysによって構築されたイーサリアム等価のzkEVMレイヤー2であり、イーサリアムエコシステムと完全に連携しています。_ -- [ゼロ知識ロールアップとは何か？](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) +## ZKロールアップに関する参考資料 {#further-reading-on-zk-rollups} + +- [ゼロ知識ロールアップとは？](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) - [ゼロ知識ロールアップとは？](https://alchemy.com/blog/zero-knowledge-rollups) -- [STARKとSNARKの相違点](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) -- [zkEVMとは何か？](https://www.alchemy.com/overviews/zkevm) -- [ZK-EVMの種類: イーサリアム等価、EVM等価、タイプ1、タイプ4、他のクリプトバズワード](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) -- [zkEVMのイントロダクション](https://hackmd.io/@yezhang/S1_KMMbGt) -- [有益なzkEVM関連リソース](https://github.com/LuozhuZhang/awesome-zkevm) +- [イーサリアム・ロールアップの実践ガイド](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [STARKs vs SNARKs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) +- [zkEVMとは？](https://www.alchemy.com/overviews/zkevm) +- [ZK-EVMのタイプ：イーサリアム等価、EVM等価、タイプ1、タイプ4、その他の難解なバズワード](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) +- [zkEVM入門](https://hackmd.io/@yezhang/S1_KMMbGt) +- [ZK-EVM L2とは？](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M) +- [Awesome-zkEVMリソース](https://github.com/LuozhuZhang/awesome-zkevm) - [ZK-SNARKの仕組み](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) -- [SNARKはどのように実現されているのか？](https://vitalik.eth.limo/general/2021/01/26/snarks.html) +- [SNARKはどのようにして可能なのか？](https://vitalik.eth.limo/general/2021/01/26/snarks.html) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/ja/developers/docs/smart-contracts/anatomy/index.md index fe879612944..264b6d46556 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/anatomy/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/anatomy/index.md @@ -1,39 +1,39 @@ --- -title: スマートコントラクトの解剖学 -description: スマートコンタクトの構造、すなわち機能、データ、変数について詳しく調べます。 +title: "スマートコントラクトの解剖学" +description: "スマートコンタクトの構造、すなわち機能、データ、変数について詳しく調べます。" lang: ja --- スマートコントラクトは、イーサリアム上のアドレスで実行されるプログラムです。 それらはトランザクションの受信時に実行できるデータと関数で構成されています。 ここでは、スマートコントラクトの構成要素の概要を説明します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -最初に、[スマートコントラクト](/developers/docs/smart-contracts/)を必ずお読みください。 このドキュメントは、JavaScriptやPythonなどのプログラミング言語に精通していることを前提としています。 +まず「[スマートコントラクト](/developers/docs/smart-contracts/)」についてお読みください。 このドキュメントは、JavaScriptやPythonなどのプログラミング言語に精通していることを前提としています。 ## データ {#data} -すべてのコントラクトのデータは、`storage`または`memory`のいずれかのロケーションに割り当てる必要があります。 スマートコントラクトのストレージの変更にはコストがかかりますので、データをどこに格納するかを考える必要があります。 +すべてのコントラクトデータは、`storage`または`memory`のいずれかの場所に割り当てる必要があります。 スマートコントラクトのストレージの変更にはコストがかかりますので、データをどこに格納するかを考える必要があります。 -### ストレージ {#storage} +### EVMストレージ {#storage} 永続データはストレージと呼ばれ、状態変数で表されます。 これらの値は、ブロックチェーンに永続的に保存されます。 コントラクトがコンパイル時に必要なブロックチェーンのストレージ容量を追跡できるように、型を宣言する必要があります。 ```solidity -// Solidity example +// Solidityの例 contract SimpleStorage { - uint storedData; // State variable + uint storedData; // 状態変数 // ... } ``` ```python -# Vyper example +# Vyperの例 storedData: int128 ``` オブジェクト指向言語でのプログラミングの経験がある場合は、ほとんどの型になじみがあるでしょう。 しかし、イーサリアムの開発が初めての場合、`address`は目新しいかもしれません。 -`address`型は、20バイトまたは160ビットに相当するイーサリアムアドレスを保持します。 先頭が0xの16進数を返します。 +`address`型は、20バイトまたは160ビットに相当するイーサリアムアドレスを保持できます。 先頭が0xの16進数を返します。 その他の型には次のものがあります。 @@ -49,24 +49,24 @@ storedData: int128 詳細については、以下のドキュメントをご覧ください。 -- [Vyperの型を見る](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types) -- [Solidityの型を見る](https://solidity.readthedocs.io/en/latest/types.html#value-types) +- [Vyperの型を参照](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types) +- [Solidityの型を参照](https://docs.soliditylang.org/en/latest/types.html#value-types) ### メモリ {#memory} コントラクト関数の実行期間にのみ保存される値は、メモリ変数と呼ばれます。 これらはブロックチェーンに永続的に保存されることはないため、低コストで使用できます -EVMがデータ(ストレージ、メモリ、スタック)を格納する方法の詳細については、[Solidityのドキュメント](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack)をご覧ください。 +EVMがどのようにデータを格納するか（ストレージ、メモリ、スタック）についての詳細は、[Solidityドキュメント](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack)を参照してください。 ### 環境変数 {#environment-variables} コントラクトで定義した変数に加え、特別なグローバル変数がいくつかあります。 これらは主にブロックチェーンや現在のトランザクションに関する情報を提供するために使用されます。 -例: +例： -| **プロパティ** | **状態変数** | **説明** | -| ----------------- | -------- | ------------------ | -| `block.timestamp` | uint256 | 現在のブロックエポックタイムスタンプ | +| **プロパティ** | **状態変数** | **説明** | +| ----------------- | -------- | ------------------------------------- | +| `block.timestamp` | uint256 | 現在のブロックエポックタイムスタンプ | | `msg.sender` | address | メッセージの送信者(現在の呼び出し) | ## 関数 {#functions} @@ -75,28 +75,28 @@ EVMがデータ(ストレージ、メモリ、スタック)を格納する方法 関数呼び出しには、以下の2種類があります。 -- `internal` - これらはEVM呼び出しを作成しません。 - - internal関数と状態変数は、内部(つまり、現在のコントラクト内またはそれから派生したコントラクト内)からのみアクセスできます。 -- `external` - これらはEVM呼び出しを作成します。 - - external関数はコントラクトインターフェイスの一部であり、他のコントラクトから呼び出したり、トランザクションを介して呼び出したりすることができます。 external関数`f`を内部で呼び出すことはできません(つまり、`f()`は動作しませんが、`this.f()`は動作します)。 +- `internal` – これらはEVMコールを作成しません + - Internal関数と状態変数は、内部(つまり、現在のコントラクトまたはそこから派生したコントラクト内)からのみアクセスできます。 +- `external` – これらはEVMコールを作成します + - external関数はコントラクトインターフェイスの一部であり、他のコントラクトから呼び出したり、トランザクションを介して呼び出したりすることができます。 external関数`f`は内部では呼び出せません(つまり、`f()`は機能しませんが、`this.f()`は機能します)。 -`public`または`private`にすることもできます。 +`public`または`private`にすることもできます -- `public`関数は、コントラクト内から内部で呼び出すことも、メッセージを介して外部から呼び出すこともできます。 -- `private`関数は、それらが定義されているコントラクトからのみ参照できます。派生したコントラクトからは参照できません。 +- `public`関数は、コントラクト内から内部的に呼び出すことも、メッセージを介して外部から呼び出すこともできます。 +- `private`関数は、それらが定義されたコントラクトからのみ参照でき、派生コントラクトからは参照できません。 関数と状態変数はどちらもpublicまたはprivateにすることができます。 コントラクトの状態変数を更新するための関数は次のとおりです。 ```solidity -// Solidity example +// Solidityの例 function update_name(string value) public { dapp_name = value; } ``` -- `string`型のパラメータ`value`が`update_name`関数に渡されます。 +- `string`型の`value`が、関数`update_name`に渡されます。 - `public`と宣言されており、誰でもアクセスできます。 - `view`が宣言されていないため、コントラクトの状態を変更できます。 @@ -105,7 +105,7 @@ function update_name(string value) public { これらの関数によって、コントラクトのデータの状態を変更しないことを指定します。 一般的な例としては、「getter」関数があります。例えば、これを使用してユーザーの残高を受け取ることができます。 ```solidity -// Solidity example +// Solidityの例 function balanceOf(address _owner) public view returns (uint256 _balance) { return ownerPizzaCount[_owner]; } @@ -123,11 +123,11 @@ def readName() -> string: 状態の変更と見なされるものは、以下のとおりです。 1. 状態変数への書き込み。 -2. [イベントの発行](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events)。 -3. [他のコントラクトの作成](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts)。 +2. [イベントの発行](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events)。 +3. [他のコントラクトの作成](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts)。 4. `selfdestruct`の使用。 5. 呼び出しによるイーサ(ETH)の送信。 -6. `view`や`pure`が指定されていない関数の呼び出し。 +6. `view`または`pure`が指定されていない関数の呼び出し。 7. 低レベル呼び出しの使用。 8. 特定のオペコードを含むインラインアセンブリの使用。 @@ -136,20 +136,20 @@ def readName() -> string: `constructor`関数は、コントラクトが最初にデプロイされたときに1回だけ実行されます。 多くのクラスベースのプログラミング言語の`constructor`と同様に、これらの関数はしばしば、指定された値に状態変数を初期化します。 ```solidity -// Solidity example -// Initializes the contract's data, setting the `owner` -// to the address of the contract creator. +// Solidityの例 +// コントラクトのデータを初期化し、`owner`を +// コントラクト作成者のアドレスに設定します。 constructor() public { - // All smart contracts rely on external transactions to trigger its functions. - // `msg` is a global variable that includes relevant data on the given transaction, - // such as the address of the sender and the ETH value included in the transaction. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + // すべてのスマートコントラクトは、その関数をトリガーするために外部トランザクションに依存します。 + // `msg`は、送信者のアドレスやトランザクションに含まれるETHの量など、 + // 特定のトランザクションに関する関連データを含むグローバル変数です。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties owner = msg.sender; } ``` ```python -# Vyper example +# Vyperの例 @external def __init__(_beneficiary: address, _bidding_time: uint256): @@ -167,7 +167,7 @@ def __init__(_beneficiary: address, _bidding_time: uint256): これらの関数により、コントラクトは他のアカウントにETHを送信することができます。 -## 関数を書く {#writing-functions} +## 関数の記述 {#writing-functions} 関数には以下のものが必要です。 @@ -180,19 +180,19 @@ def __init__(_beneficiary: address, _bidding_time: uint256): pragma solidity >=0.4.0 <=0.6.0; contract ExampleDapp { - string dapp_name; // state variable + string dapp_name; // 状態変数 - // Called when the contract is deployed and initializes the value + // コントラクトがデプロイされたときに呼び出され、値を初期化します constructor() public { dapp_name = "My Example dapp"; } - // Get Function + // Get関数 function read_name() public view returns(string) { return dapp_name; } - // Set Function + // Set関数 function update_name(string value) public { dapp_name = value; } @@ -207,39 +207,39 @@ contract ExampleDapp { ## 注釈付きの例 {#annotated-examples} -Solidityで書かれた例を以下に示します。 コードを実行したい場合は、[Remix](http://remix.ethereum.org)で操作できます。 +Solidityで書かれた例を以下に示します。 コードを試したい場合は、[Remix](http://remix.ethereum.org)で操作できます。 -### Hello World {#hello-world} +### Hello world {#hello-world} ```solidity -// Specifies the version of Solidity, using semantic versioning. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// セマンティックバージョニングを使用して、Solidityのバージョンを指定します。 +// 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity ^0.5.10; -// Defines a contract named `HelloWorld`. -// A contract is a collection of functions and data (its state). -// Once deployed, a contract resides at a specific address on the Ethereum blockchain. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// `HelloWorld`という名前のコントラクトを定義します。 +// コントラクトは、関数とデータ(その状態)のコレクションです。 +// デプロイされると、コントラクトはイーサリアムブロックチェーン上の特定のアドレスに配置されます。 +// 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html contract HelloWorld { - // Declares a state variable `message` of type `string`. - // State variables are variables whose values are permanently stored in contract storage. - // The keyword `public` makes variables accessible from outside a contract - // and creates a function that other contracts or clients can call to access the value. + // `string`型の状態変数`message`を宣言します。 + // 状態変数は、その値がコントラクトのストレージに永続的に保存される変数です。 + // `public`キーワードは、変数をコントラクトの外部からアクセス可能にし、 + // 他のコントラクトやクライアントが値をアクセスするために呼び出すことができる関数を作成します。 string public message; - // Similar to many class-based object-oriented languages, a constructor is - // a special function that is only executed upon contract creation. - // Constructors are used to initialize the contract's data. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // 多くのクラスベースのオブジェクト指向言語と同様に、コンストラクタは + // コントラクトの作成時にのみ実行される特別な関数です。 + // コンストラクタは、コントラクトのデータを初期化するために使用されます。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors constructor(string memory initMessage) public { - // Accepts a string argument `initMessage` and sets the value - // into the contract's `message` storage variable). + // 文字列引数`initMessage`を受け入れ、その値を + // コントラクトの`message`ストレージ変数に設定します)。 message = initMessage; } - // A public function that accepts a string argument - // and updates the `message` storage variable. + // 文字列引数を受け入れ、 + // `message`ストレージ変数を更新するpublic関数です。 function update(string memory newMessage) public { message = newMessage; } @@ -252,136 +252,136 @@ contract HelloWorld { pragma solidity ^0.5.10; contract Token { - // An `address` is comparable to an email address - it's used to identify an account on Ethereum. - // Addresses can represent a smart contract or an external (user) accounts. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#address + // `address`はEメールアドレスに似ています - イーサリアム上のアカウントを識別するために使用されます。 + // アドレスは、スマートコントラクトまたは外部(ユーザー)アカウントを表すことができます。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/types.html#address address public owner; - // A `mapping` is essentially a hash table data structure. - // This `mapping` assigns an unsigned integer (the token balance) to an address (the token holder). - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types - mapping (address => uint) public balances; + // `mapping`は、本質的にハッシュテーブルのデータ構造です。 + // この`mapping`は、符号なし整数(トークン残高)をアドレス(トークン保有者)に割り当てます。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types + mapping (address => uint) balances; - // Events allow for logging of activity on the blockchain. - // Ethereum clients can listen for events in order to react to contract state changes. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events + // イベントにより、ブロックチェーン上のアクティビティをログに記録できます。 + // イーサリアムクライアントは、コントラクトの状態変更に反応するためにイベントをリッスンできます。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events event Transfer(address from, address to, uint amount); - // Initializes the contract's data, setting the `owner` - // to the address of the contract creator. + // コントラクトのデータを初期化し、`owner`を + // コントラクト作成者のアドレスに設定します。 constructor() public { - // All smart contracts rely on external transactions to trigger its functions. - // `msg` is a global variable that includes relevant data on the given transaction, - // such as the address of the sender and the ETH value included in the transaction. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + // すべてのスマートコントラクトは、その関数をトリガーするために外部トランザクションに依存します。 + // `msg`は、送信者のアドレスやトランザクションに含まれるETHの量など、 + // 特定のトランザクションに関する関連データを含むグローバル変数です。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties owner = msg.sender; } - // Creates an amount of new tokens and sends them to an address. + // 新しいトークンを作成し、アドレスに送信します。 function mint(address receiver, uint amount) public { - // `require` is a control structure used to enforce certain conditions. - // If a `require` statement evaluates to `false`, an exception is triggered, - // which reverts all changes made to the state during the current call. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + // `require`は、特定の条件を強制するために使用される制御構造です。 + // `require`ステートメントが`false`と評価された場合、例外がトリガーされ、 + // 現在の呼び出し中に行われた状態へのすべての変更が元に戻されます。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - // Only the contract owner can call this function + // コントラクトのオーナーのみがこの関数を呼び出すことができます require(msg.sender == owner, "You are not the owner."); - // Enforces a maximum amount of tokens + // トークンの最大量を強制します require(amount < 1e60, "Maximum issuance exceeded"); - // Increases the balance of `receiver` by `amount` + // `receiver`の残高を`amount`だけ増やします balances[receiver] += amount; } - // Sends an amount of existing tokens from any caller to an address. + // 任意の呼び出し元からアドレスに既存のトークンを送信します。 function transfer(address receiver, uint amount) public { - // The sender must have enough tokens to send + // 送信者は送信するのに十分なトークンを持っている必要があります require(amount <= balances[msg.sender], "Insufficient balance."); - // Adjusts token balances of the two addresses + // 2つのアドレスのトークン残高を調整します balances[msg.sender] -= amount; balances[receiver] += amount; - // Emits the event defined earlier + // 先に定義されたイベントを発行します emit Transfer(msg.sender, receiver, amount); } } ``` -### 固有のデジタル資産 {#unique-digital-asset} +### ユニークなデジタル資産 {#unique-digital-asset} ```solidity pragma solidity ^0.5.10; -// Imports symbols from other files into the current contract. -// In this case, a series of helper contracts from OpenZeppelin. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files +// 他のファイルから現在のコントラクトにシンボルをインポートします。 +// このケースでは、OpenZeppelinの一連のヘルパーコントラクトです。 +// 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol"; import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol"; import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol"; -// The `is` keyword is used to inherit functions and keywords from external contracts. -// In this case, `CryptoPizza` inherits from the `IERC721` and `ERC165` contracts. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance +// `is`キーワードは、外部コントラクトから関数とキーワードを継承するために使用されます。 +// このケースでは、`CryptoPizza`は`IERC721`と`ERC165`コントラクトから継承します。 +// 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance contract CryptoPizza is IERC721, ERC165 { - // Uses OpenZeppelin's SafeMath library to perform arithmetic operations safely. - // Learn more: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath + // OpenZeppelinのSafeMathライブラリを使用して、算術演算を安全に実行します。 + // 詳細はこちら: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath using SafeMath for uint256; - // Constant state variables in Solidity are similar to other languages - // but you must assign from an expression which is constant at compile time. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables + // Solidityの定数状態変数は他の言語に似ていますが、 + // コンパイル時に定数である式から代入する必要があります。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables uint256 constant dnaDigits = 10; uint256 constant dnaModulus = 10 ** dnaDigits; bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; - // Struct types let you define your own type - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs + // Struct型を使用すると、独自の型を定義できます + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs struct Pizza { string name; uint256 dna; } - // Creates an empty array of Pizza structs + // Pizza構造体の空の配列を作成します Pizza[] public pizzas; - // Mapping from pizza ID to its owner's address + // ピザIDからそのオーナーのアドレスへのマッピング mapping(uint256 => address) public pizzaToOwner; - // Mapping from owner's address to number of owned token + // オーナーのアドレスから所有トークン数へのマッピング mapping(address => uint256) public ownerPizzaCount; - // Mapping from token ID to approved address + // トークンIDから承認済みアドレスへのマッピング mapping(uint256 => address) pizzaApprovals; - // You can nest mappings, this example maps owner to operator approvals + // マッピングをネストすることができます。この例では、オーナーをオペレーターの承認にマッピングします mapping(address => mapping(address => bool)) private operatorApprovals; - // Internal function to create a random Pizza from string (name) and DNA + // 文字列(名前)とDNAからランダムなピザを作成する内部関数 function _createPizza(string memory _name, uint256 _dna) - // The `internal` keyword means this function is only visible - // within this contract and contracts that derive this contract - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters + // `internal`キーワードは、この関数がこのコントラクトおよび + // このコントラクトを派生するコントラクト内でのみ参照可能であることを意味します + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters internal - // `isUnique` is a function modifier that checks if the pizza already exists - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers + // `isUnique`は、ピザがすでに存在するかどうかをチェックする関数修飾子です + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers isUnique(_name, _dna) { - // Adds Pizza to array of Pizzas and get id + // ピザをピザ配列に追加し、IDを取得します uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1); - // Checks that Pizza owner is the same as current user - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + // ピザのオーナーが現在のユーザーと同じであることを確認します + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - // note that address(0) is the zero address, - // indicating that pizza[id] is not yet allocated to a particular user. + // address(0)はゼロアドレスであり、 + // pizza[id]がまだ特定のユーザーに割り当てられていないことを示します。 assert(pizzaToOwner[id] == address(0)); - // Maps the Pizza to the owner + // ピザをオーナーにマッピングします pizzaToOwner[id] = msg.sender; ownerPizzaCount[msg.sender] = SafeMath.add( ownerPizzaCount[msg.sender], @@ -389,38 +389,38 @@ contract CryptoPizza is IERC721, ERC165 { ); } - // Creates a random Pizza from string (name) + // 文字列(名前)からランダムなピザを作成します function createRandomPizza(string memory _name) public { uint256 randDna = generateRandomDna(_name, msg.sender); _createPizza(_name, randDna); } - // Generates random DNA from string (name) and address of the owner (creator) + // 文字列(名前)とオーナーのアドレス(作成者)からランダムなDNAを生成します function generateRandomDna(string memory _str, address _owner) public - // Functions marked as `pure` promise not to read from or modify the state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions + // `pure`とマークされた関数は、状態の読み取りや変更を行わないことを約束します + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions pure returns (uint256) { - // Generates random uint from string (name) + address (owner) + // 文字列(名前) + アドレス(オーナー)からランダムなuintを生成します uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + uint256(_owner); rand = rand % dnaModulus; return rand; } - // Returns array of Pizzas found by owner + // オーナーによって見つかったピザの配列を返します function getPizzasByOwner(address _owner) public - // Functions marked as `view` promise not to modify state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions + // `view`とマークされた関数は、状態を変更しないことを約束します + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions view returns (uint256[] memory) { - // Uses the `memory` storage location to store values only for the - // lifecycle of this function call. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack + // `memory`ストレージの場所を使用して、この関数呼び出しの + // ライフサイクル中のみ値を格納します。 + // 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack uint256[] memory result = new uint256[](ownerPizzaCount[_owner]); uint256 counter = 0; for (uint256 i = 0; i < pizzas.length; i++) { @@ -432,7 +432,7 @@ contract CryptoPizza is IERC721, ERC165 { return result; } - // Transfers Pizza and ownership to other address + // ピザと所有権を他のアドレスに転送します function transferFrom(address _from, address _to, uint256 _pizzaId) public { require(_from != address(0) && _to != address(0), "Invalid address."); require(_exists(_pizzaId), "Pizza does not exist."); @@ -443,17 +443,17 @@ contract CryptoPizza is IERC721, ERC165 { ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1); pizzaToOwner[_pizzaId] = _to; - // Emits event defined in the imported IERC721 contract + // インポートされたIERC721コントラクトで定義されたイベントを発行します emit Transfer(_from, _to, _pizzaId); _clearApproval(_to, _pizzaId); } /** - * Safely transfers the ownership of a given token ID to another address - * If the target address is a contract, it must implement `onERC721Received`, - * which is called upon a safe transfer, and return the magic value + * 指定されたトークンIDの所有権を別のアドレスに安全に転送します + * ターゲットアドレスがコントラクトの場合、`onERC721Received`を実装する必要があります。 + * これは安全な転送時に呼び出され、マジック値を返します * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * otherwise, the transfer is reverted. + * そうでない場合、転送は取り消されます。 */ function safeTransferFrom(address from, address to, uint256 pizzaId) public @@ -463,11 +463,11 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * Safely transfers the ownership of a given token ID to another address - * If the target address is a contract, it must implement `onERC721Received`, - * which is called upon a safe transfer, and return the magic value + * 指定されたトークンIDの所有権を別のアドレスに安全に転送します + * ターゲットアドレスがコントラクトの場合、`onERC721Received`を実装する必要があります。 + * これは安全な転送時に呼び出され、マジック値を返します * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * otherwise, the transfer is reverted. + * そうでない場合、転送は取り消されます。 */ function safeTransferFrom( address from, @@ -480,8 +480,8 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * Internal function to invoke `onERC721Received` on a target address - * The call is not executed if the target address is not a contract + * ターゲットアドレスで`onERC721Received`を呼び出す内部関数 + * ターゲットアドレスがコントラクトでない場合、呼び出しは実行されません */ function _checkOnERC721Received( address from, @@ -502,9 +502,9 @@ contract CryptoPizza is IERC721, ERC165 { return (retval == _ERC721_RECEIVED); } - // Burns a Pizza - destroys Token completely - // The `external` function modifier means this function is - // part of the contract interface and other contracts can call it + // ピザを燃やす - トークンを完全に破壊する + // `external`関数修飾子は、この関数が + // コントラクトインターフェースの一部であり、他のコントラクトがそれを呼び出すことができることを意味します function burn(uint256 _pizzaId) external { require(msg.sender != address(0), "Invalid address."); require(_exists(_pizzaId), "Pizza does not exist."); @@ -517,26 +517,26 @@ contract CryptoPizza is IERC721, ERC165 { pizzaToOwner[_pizzaId] = address(0); } - // Returns count of Pizzas by address + // アドレスごとのピザの数を返します function balanceOf(address _owner) public view returns (uint256 _balance) { return ownerPizzaCount[_owner]; } - // Returns owner of the Pizza found by id + // IDで見つかったピザのオーナーを返します function ownerOf(uint256 _pizzaId) public view returns (address _owner) { address owner = pizzaToOwner[_pizzaId]; require(owner != address(0), "Invalid Pizza ID."); return owner; } - // Approves other address to transfer ownership of Pizza + // 他のアドレスがピザの所有権を転送することを承認します function approve(address _to, uint256 _pizzaId) public { require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); pizzaApprovals[_pizzaId] = _to; emit Approval(msg.sender, _to, _pizzaId); } - // Returns approved address for specific Pizza + // 特定のピザの承認済みアドレスを返します function getApproved(uint256 _pizzaId) public view @@ -547,8 +547,8 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * Private function to clear current approval of a given token ID - * Reverts if the given address is not indeed the owner of the token + * 指定されたトークンIDの現在の承認をクリアするプライベート関数 + * 指定されたアドレスがトークンのオーナーでない場合、取り消されます */ function _clearApproval(address owner, uint256 _pizzaId) private { require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); @@ -559,8 +559,8 @@ contract CryptoPizza is IERC721, ERC165 { } /* - * Sets or unsets the approval of a given operator - * An operator is allowed to transfer all tokens of the sender on their behalf + * 指定されたオペレーターの承認を設定または解除します + * オペレーターは、送信者に代わってすべてのトークンを転送することが許可されます */ function setApprovalForAll(address to, bool approved) public { require(to != msg.sender, "Cannot approve own address"); @@ -568,7 +568,7 @@ contract CryptoPizza is IERC721, ERC165 { emit ApprovalForAll(msg.sender, to, approved); } - // Tells whether an operator is approved by a given owner + // オペレーターが指定されたオーナーによって承認されているかどうかを通知します function isApprovedForAll(address owner, address operator) public view @@ -577,27 +577,27 @@ contract CryptoPizza is IERC721, ERC165 { return operatorApprovals[owner][operator]; } - // Takes ownership of Pizza - only for approved users + // ピザの所有権を取得する - 承認されたユーザーのみ function takeOwnership(uint256 _pizzaId) public { require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); address owner = this.ownerOf(_pizzaId); this.transferFrom(owner, msg.sender, _pizzaId); } - // Checks if Pizza exists + // ピザが存在するかどうかを確認します function _exists(uint256 pizzaId) internal view returns (bool) { address owner = pizzaToOwner[pizzaId]; return owner != address(0); } - // Checks if address is owner or is approved to transfer Pizza + // アドレスがオーナーであるか、ピザの転送が承認されているかを確認します function _isApprovedOrOwner(address spender, uint256 pizzaId) internal view returns (bool) { address owner = pizzaToOwner[pizzaId]; - // Disable solium check because of + // 以下によるソリウムチェックの無効化 // https://github.com/duaraghav8/Solium/issues/175 // solium-disable-next-line operator-whitespace return (spender == owner || @@ -605,7 +605,7 @@ contract CryptoPizza is IERC721, ERC165 { this.isApprovedForAll(owner, spender)); } - // Check if Pizza is unique and doesn't exist yet + // ピザがユニークでまだ存在しないかを確認します modifier isUnique(string memory _name, uint256 _dna) { bool result = true; for (uint256 i = 0; i < pizzas.length; i++) { @@ -621,15 +621,15 @@ contract CryptoPizza is IERC721, ERC165 { _; } - // Returns whether the target address is a contract + // ターゲットアドレスがコントラクトであるかどうかを返します function isContract(address account) internal view returns (bool) { uint256 size; - // Currently there is no better way to check if there is a contract in an address - // than to check the size of the code at that address. - // どのように動くかの詳細は、 - // https://ethereum.stackexchange.com/a/14016/36603 を確認する。 - // TODO すべてのアドレスが縮小されるので、 - // セレニティリリースの前に、ここをもう一度確認する。 + // 現在、アドレスにコントラクトがあるかどうかを確認するのに、 + // そのアドレスのコードのサイズを確認するより良い方法はありません。 + // これがどのように機能するかについての詳細は、https://ethereum.stackexchange.com/a/14016/36603 + // を参照してください。 + // TODO Serenityリリースの前にこれを再確認してください。すべての + // アドレスがコントラクトになるためです。 // solium-disable-next-line security/no-inline-assembly assembly { size := extcodesize(account) @@ -639,20 +639,20 @@ contract CryptoPizza is IERC721, ERC165 { } ``` -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} スマートコントラクトの全体的な概要については、SolidityとVyperのドキュメントをご確認ください。 -- [Solidity](https://solidity.readthedocs.io/) -- [Vyper](https://vyper.readthedocs.io/) +- [Solidity](https://docs.soliditylang.org/) +- [Vyper](https://docs.vyperlang.org/en/stable/) ## 関連トピック {#related-topics} - [スマートコントラクト](/developers/docs/smart-contracts/) -- [イーサリアム仮想マシン(EVM)](/developers/docs/evm/) +- [イーサリアム仮想マシン](/developers/docs/evm/) ## 関連チュートリアル {#related-tutorials} -- [コントラクトのサイズ制限に対処するためのコントラクトのサイズ縮小](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- スマートコントラクトのサイズを小さくするための実用的なヒント_ -- [イベントを使用してスマートコントラクトからデータをログに記録](/developers/tutorials/logging-events-smart-contracts/) _- スマートコントラクトのイベントの紹介と、それを使ってデータをログに記録する方法_ -- [Solidityを使用した他のコントラクトとの連携](/developers/tutorials/interact-with-other-contracts-from-solidity/) _- 既存のコントラクトからスマートコントラクトをデプロイし、それを扱う方法_ +- [コントラクトサイズ制限と戦うためのコントラクトの縮小](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– スマートコントラクトのサイズを縮小するための実践的なヒント。_ +- [イベントを使用してスマートコントラクトからデータをログに記録する](/developers/tutorials/logging-events-smart-contracts/) _– スマートコントラクトのイベントの紹介と、それらを使用してデータをログに記録する方法。_ +- [Solidityから他のコントラクトと対話する](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 既存のコントラクトからスマートコントラクトをデプロイし、それと対話する方法。_ diff --git a/public/content/translations/ja/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/ja/developers/docs/smart-contracts/compiling/index.md index 7e8269d7cf5..6f6bda12a7d 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/compiling/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/compiling/index.md @@ -1,17 +1,17 @@ --- -title: スマートコントラクトのコンパイル -description: スマートコントラクトをコンパイルする必要がある理由と、コンパイルを実際にどのように行うかの説明します。 +title: "スマートコントラクトのコンパイル" +description: "スマートコントラクトをコンパイルする必要がある理由と、コンパイルを実際にどのように行うかの説明します。" lang: ja incomplete: true --- Webアプリとイーサリアム仮想マシン(EVM)が理解できるように、コントラクトをコンパイルする必要があります。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} コンパイルについて読む前に、[スマートコントラクト](/developers/docs/smart-contracts/)と[イーサリアム仮想マシン](/developers/docs/evm/)の概要を読んでおくと役立ちます。 -## EVM (イーサリアム仮想マシン) {#the-evm} +## EVM {#the-evm} [EVM](/developers/docs/evm/)がコントラクトを実行できるようにするには、**バイトコード**にする必要があります。 以下はコンパイルするコントラクトです。 @@ -20,14 +20,14 @@ pragma solidity 0.4.24; contract Greeter { - function greet() public constant returns (string) { + function greet() public view returns (string memory) { return "Hello"; } } ``` -**上記は次のように変換されます。** +**が、以下になります** ``` PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900 @@ -37,9 +37,9 @@ PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x [オペコードの詳細](/developers/docs/evm/opcodes/) -## Webアプリ {#web-applications} +## ウェブアプリケーション {#web-applications} -コンパイラは、アプリケーションがコントラクトを理解し、コントラクトの関数を呼び出すために必要な**アプリケーションバイナリインターフェイス(ABI)**も生成します。 +コンパイラは、アプリケーションがコントラクトを理解し、コントラクトの関数を呼び出すために必要な**アプリケーションバイナリインターフェース (ABI)** も生成します。 ABIは、デプロイされたコントラクトとそのスマートコントラクト関数を記述するJSONファイルです。 これにより、Web2とWeb3のギャップを埋めることができます。 @@ -272,11 +272,11 @@ ABIは、デプロイされたコントラクトとそのスマートコント ] ``` -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [ABI仕様](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ ## 関連トピック {#related-topics} - [JavaScriptクライアントライブラリ](/developers/docs/apis/javascript/) -- [イーサリアム仮想マシン(EVM)](/developers/docs/evm/) +- [イーサリアム仮想マシン](/developers/docs/evm/) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/composability/index.md b/public/content/translations/ja/developers/docs/smart-contracts/composability/index.md index 40653d850ca..071a16d8530 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/composability/index.md @@ -1,13 +1,13 @@ --- -title: スマートコントラクトの構成可能性 -description: +title: "スマートコントラクトの構成可能性" +description: "スマートコントラクトが、既存のコンポーネントを再利用することで、レゴブロックのように組み合わされ、複雑なdAppsを構築できる仕組みを学びましょう。" lang: ja incomplete: true --- -## 簡単な紹介 {#a-brief-introduction} +## はじめに {#a-brief-introduction} -スマートコントラクトはイーサリアム上で公開されており、オープンAPIと考えることができます。 Dappデベロッパーになるために、独自のスマートコントラクトを書く必要はありません。スマートコントラクトとやり取りする方法を理解するだけで済みます。 例えば、アプリ内のすべてのトークンスワップロジックを処理するために、分散型取引所である[Uniswap](https://uniswap.exchange/swap)の既存のスマートコントラクトを使用できます。ゼロから始める必要はありません。 [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts)と[v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts)のコントラクトをいくつか確認してみてください。 +スマートコントラクトはイーサリアム上で公開されており、オープンAPIと考えることができます。 Dappデベロッパーになるために、独自のスマートコントラクトを書く必要はありません。スマートコントラクトとやり取りする方法を理解するだけで済みます。 例えば、分散型取引所である[Uniswap](https://uniswap.exchange/swap)の既存のスマートコントラクトを使用して、アプリ内のすべてのトークンスワップロジックを処理できます。ゼロから始める必要はありません。 [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts)と[v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts)のコントラクトをご覧ください。 ## 構成可能性とは {#what-is-composability} @@ -19,37 +19,37 @@ incomplete: true イーサリアムのスマートコントラクトはパブリックAPIのようなものなので、誰でもコントラクトとやり取りしたり、それらをDappに統合して機能を追加したりすることができます。 スマートコントラクトの構成は一般的に、モジュール性、自律性、発見性の3つの原則に基づいています。 -**1. モジュール性**: 個々のコンポーネントが特定のタスクを実行する能力です。 イーサリアムでは、すべてのスマートコントラクトに特定のユースケースがあります(Uniswapの例に見ることができます)。 +**1. **モジュール性**: 個々のコンポーネントが特定のタスクを実行する能力です。 イーサリアムでは、すべてのスマートコントラクトに特定のユースケースがあります(Uniswapの例に見ることができます)。 -**2. 自律性**: 構成可能なコンポーネントには、独立して動作できることが求められます。 イーサリアムの各スマートコントラクトは自己実行形式であり、システムの他の部分に依存することなく機能することができます。 +**2. **自律性**: 構成可能なコンポーネントは、独立して動作できなければなりません。 イーサリアムの各スマートコントラクトは自己実行形式であり、システムの他の部分に依存することなく機能することができます。 -**3. 発見性**: 公開されていない外部コントラクトを呼び出したり、公開されていないソフトウェアライブラリをアプリケーションに統合したりすることはできません。 設計上、スマートコントラクトはオープンソースであり、誰でもスマートコントラクトを呼び出したり、コードベースをフォークしたりすることができます。 +**3. **発見可能性**: 開発者は、公開されていない外部コントラクトを呼び出したり、ソフトウェアライブラリをアプリケーションに統合したりすることはできません。 設計上、スマートコントラクトはオープンソースであり、誰でもスマートコントラクトを呼び出したり、コードベースをフォークしたりすることができます。 -## 構成可能性のメリット {#benefits-of-composability} +## コンポーザビリティの利点 {#benefits-of-composability} ### 開発サイクルの短縮 {#shorter-development-cycle} -構成可能性は、[Dapp](/apps/#what-are-dapps)を作成する際にデベロッパーが行うべき作業を減らします。 [Naval Ravikant 氏が言うように、](https://twitter.com/naval/status/1444366754650656770)「オープンソースは、すべての問題を一度だけ解決すればよいということを意味する」ということです。 +コンポーザビリティによって、開発者が[dapps](/apps/#what-are-dapps)を作成する際の作業が軽減されます。 [Naval Ravikantが言うように:](https://twitter.com/naval/status/1444366754650656770) 「オープンソースとは、あらゆる問題は一度解決すればよいということです。」 一つの問題を解決するスマートコントラクトがある場合、他のデベロッパーはそれを再利用できるため、同じ問題を解決する必要はありません。 このようにして、デベロッパーは既存のソフトウェアライブラリを利用し、更なる機能を追加して新しいDappを作成することができます。 -### イノベーションの加速 {#greater-innovation} +### さらなるイノベーション {#greater-innovation} 構成可能性があると、デベロッパーが自由にオープンソースコードを再利用、修正、複製、または統合して望ましい結果を生み出せるため、イノベーションや検証作業が促進されます。 その結果、開発チームは基本的な機能に時間を費やすことが少なくなり、新機能の検証作業に多くの時間を費やすことができます。 -### ユーザーエクスペリエンスの向上 {#better-user-experience} +### より良いユーザーエクスペリエンス {#better-user-experience} イーサリアムエコシステムのコンポーネント間の相互運用性は、ユーザーエクスペリエンスを向上させます。 アプリケーション間で通信できない分断されたエコシステムよりも、外部のスマートコントラクトを統合しているDappの方が、ユーザーに高い機能性を提供できます。 ここでは、裁定取引の例を使用して、相互運用性のメリットを説明します。 -トークンが`取引所A`で`取引所B`よりも高く取引されている場合、この価格差を利用して利益を上げることができます。 ただし、それができるのは、トランザクション(つまり、`取引所B`からトークンを購入し、`取引所A`でそれを売却すること)に資金を提供するだけの十分な資金がある場合に限ります。 +あるトークンが`exchange B`よりも`exchange A`で高く取引されている場合、その価格差を利用して利益を上げることができます。 ただし、それができるのは、トランザクション (つまり、`exchange B`からトークンを購入し、`exchange A`で売却すること) に資金を提供するだけの十分な資金がある場合に限られます。 -取引を行うのに十分な資金を持っていないシナリオでは、フラッシュローンが理想的かもしれません。 [フラッシュローン](/defi/#flash-loans)は非常に専門的ですが、基本的な考え方は、_一つ_のトランザクション内で(担保なしに)資産を借りて同じだけ返すということです。 +取引を行うのに十分な資金を持っていないシナリオでは、フラッシュローンが理想的かもしれません。 [フラッシュローン](/defi/#flash-loans)は高度に専門的ですが、基本的な考え方としては、(担保なしで) 資産を借り入れ、_1つ_のトランザクション内で同額を返済できるというものです。 -当初の例に戻りましょう。制定取引業者は多額のフラッシュローンを利用して`取引所B`からトークンを購入し、それらを`取引所A`に売却し、資金と利息の払い戻しを受け、利益を確保するまでを同一のトランザクションの中で行うことができます。 この複雑なロジックでは、複数のコントラクトへの呼び出しを組み合わせる必要がありますが、スマートコントラクトに相互運用性がない場合は不可能です。 +最初の例に戻ると、裁定取引者は多額のフラッシュローンを借り、同一のトランザクション内で`exchange B`からトークンを購入し、`exchange A`で売却し、元本+利子を返済して利益を確保することができます。 この複雑なロジックでは、複数のコントラクトへの呼び出しを組み合わせる必要がありますが、スマートコントラクトに相互運用性がない場合は不可能です。 -## イーサリアムの構成可能性の例 {#composability-in-ethereum} +## イーサリアムにおけるコンポーザビリティの例 {#composability-in-ethereum} ### トークンスワップ {#token-swaps} @@ -57,20 +57,20 @@ ETHでトランザクションフィーを支払う必要があるDappを作成 ### ガバナンス {#governance} -[DAO](/dao/)向けにカスタマイズしたガバナンスシステムの構築には、コストと時間がかかることがあります。 代わりに、[Aragon Client](https://client.aragon.org/)のようなオープンソースのガバナンスツールキットを使用して、ガバナンスフレームワークをすばやく作成してDAOを立ち上げることができます。 +[DAO](/dao/)向けにカスタマイズされたガバナンスシステムを構築するには、費用と時間がかかる場合があります。 代わりに、[Aragon Client](https://client.aragon.org/)のようなオープンソースのガバナンスツールキットを使用して、DAOを立ち上げ、ガバナンスのフレームワークを迅速に作成することができます。 -### ID管理 {#identity-management} +### アイデンティティ管理 {#identity-management} -カスタム認証システムを構築したり、集中型プロバイダーに依存したりしなくても、ユーザーの認証を管理する分散型アイデンティティ(DID)ツールを統合できます。 例えば、オープンソースツールキットの[SpluceID](https://www.spruceid.com/)などがあります。このツールキットは「イーサリアムでサインイン」機能を提供し、ユーザーはイーサリアムウォレットを使用してアイデンティティを認証できます。 +カスタム認証システムを構築したり、集中型プロバイダーに依存したりしなくても、ユーザーの認証を管理する分散型アイデンティティ(DID)ツールを統合できます。 一例として、[SpruceID](https://www.spruceid.com/)というオープンソースのツールキットがあります。これは「イーサリアムでサインイン」機能を提供するもので、ユーザーはイーサリアムウォレットでIDを認証することができます。 -## 関連トピック {#related-tutorials} +## 関連チュートリアル {#related-tutorials} -- [create-eth-appを使用したDappフロントエンド開発の始動](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _- create-eth-appを使用して、一般的なスマートコントラクトを組み込んだ、すぐに利用可能なアプリを作成する方法の概要_ +- [create-eth-appでdappのフロントエンド開発を始める](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– create-eth-appを使用して、人気のスマートコントラクトを組み込んだ、すぐに利用可能なアプリを作成する方法の概要。_ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_イーサリアムを学ぶために利用したコミュニティリソースはありますか？ もしあればページを編集して追加してください！_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ -- [構成可能性はイノベーションである](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/) -- [構成可能性がWeb3にとって重要な理由](https://hackernoon.com/why-composability-matters-for-web3) -- [構成可能性とは](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) +- [コンポーザビリティはイノベーションである](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/) +- [Web3においてコンポーザビリティが重要な理由](https://hackernoon.com/why-composability-matters-for-web3) +- [コンポーザビリティとは何か](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/ja/developers/docs/smart-contracts/deploying/index.md index 5127307dda0..fed82b143c0 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/deploying/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/deploying/index.md @@ -1,6 +1,6 @@ --- -title: スマートコントラクトの導入 -description: +title: "スマートコントラクトの導入" +description: "スマートコントラクトをイーサリアムネットワークにデプロイする方法を学びましょう。前提条件、必要なツール、そしてデプロイの手順について解説します。" lang: ja --- @@ -8,52 +8,52 @@ lang: ja ブロックチェーン上でのスマートコントラクトのデプロイとは、要するにスマートコントラクトのコンパイル済みのコードが格納されたイーサリアムトランザクションを、受信者を指定せずに送信するということです。 -## 事前に {#prerequisites} +## 前提条件 {#prerequisites} -スマートコントラクトをデプロイする前に、[イーサリアムネットワーク](/developers/docs/networks/)、[トランザクション](/developers/docs/transactions/)、[スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)を理解する必要があります。 +スマートコントラクトをデプロイする前に、[イーサリアムネットワーク](/developers/docs/networks/)、[トランザクション](/developers/docs/transactions/)、[スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)について理解しておく必要があります。 -コントラクトはブロックチェーンに保存されているため、デプロイする際にイーサ(ETH)もかかります。そのため、イーサリアムの[ガスと手数料](/developers/docs/gas/)を熟知しておく必要があります。 +コントラクトはブロックチェーンに保存されるため、デプロイにはイーサ (ETH) のコストがかかります。そのため、イーサリアムの[ガスと手数料](/developers/docs/gas/)に精通しておく必要があります。 -最後に、デプロイする前にコントラクトをコンパイルする必要がありますので、 [スマートコントラクトのコンパイル](/developers/docs/smart-contracts/compiling/)を必ずお読みください。 +最後に、コントラクトをデプロイする前にコンパイルする必要があるため、必ず[スマートコントラクトのコンパイル](/developers/docs/smart-contracts/compiling/)についてお読みください。 -## スマートコントラクトのデプロイ方法 {#how-to-deploy-a-smart-contract} +## スマートコントラクトをデプロイする方法 {#how-to-deploy-a-smart-contract} ### 必要なもの {#what-youll-need} -- コントラクトのバイトコード - これは[コンパイル](/developers/docs/smart-contracts/compiling/)によって生成されます。 +- コントラクトのバイトコード – これは[コンパイル](/developers/docs/smart-contracts/compiling/)によって生成されます。 - ガス用のETH - 他のトランザクションと同様にガスリミットを設定しますので、コントラクトのデプロイには、単純なETHの送金よりも多くのガスが必要であることに注意してください。 - デプロイメントのためのスクリプトやプラグイン。 -- [イーサリアムノード](/developers/docs/nodes-and-clients/)へのアクセス。これは、自身のノードを実行するか、公開ノードに接続するか、[ノードサービス](/developers/docs/nodes-and-clients/nodes-as-a-service/)を使用してAPIキーを介するかのいずれかの方法で行います。 +- [イーサリアムノード](/developers/docs/nodes-and-clients/)へのアクセス。自身でノードを稼働させるか、パブリックノードに接続するか、[ノードサービス](/developers/docs/nodes-and-clients/nodes-as-a-service/)を使用して API キーを介してアクセスします。 ### スマートコントラクトをデプロイする手順 {#steps-to-deploy} -具体的な手順は、使っている開発フレームワークによって異なります。 実例は、[コントラクトのデプロイに関するHardhatのドキュメント](https://hardhat.org/docs/tutorial/deploying)または [スマートコントラクトのデプロイと検証に関するFoundryのドキュメント](https://book.getfoundry.sh/forge/deploying)をご確認ください。 デプロイされると、他の [アカウント](/developers/docs/accounts/)と同様に、コントラクトには、イーサリアムアドレスが設定されます。また、[ソースコード検証ツール](/developers/docs/smart-contracts/verifying/#source-code-verification-tools)を使って検証することができます。 +具体的な手順は、使っている開発フレームワークによって異なります。 例えば、[コントラクトのデプロイに関するHardhatのドキュメント](https://hardhat.org/docs/tutorial/deploying)や[スマートコントラクトのデプロイと検証に関するFoundryのドキュメント](https://book.getfoundry.sh/forge/deploying)を参照できます。 デプロイされると、コントラクトは他の[アカウント](/developers/docs/accounts/)と同様にイーサリアムアドレスを持つようになり、[ソースコード検証ツール](/developers/docs/smart-contracts/verifying/#source-code-verification-tools)を使用して検証できます。 ## 関連ツール {#related-tools} -**Remix - _Remix IDEでは、イーサリアムのようなブロックチェーン上のスマートコントラクトの開発、デプロイ、管理を行うことができます。_** +**Remix - _Remix IDE を使用すると、イーサリアムのようなブロックチェーンのスマートコントラクトを開発、デプロイ、管理できます_** - [Remix](https://remix.ethereum.org) -**Tenderly - _スマートコントラクトの開発、テスト、監視、運用のためのデバッグ、オブザーバビリティ、インフラストラクチャ・ビルディング・ブロックを提供するWeb3開発プラットフォーム_** +**Tenderly - _スマートコントラクトの開発、テスト、監視、運用を目的として、デバッグ、可観測性、インフラストラクチャのビルディングブロックを提供する Web3 開発プラットフォーム_** - [tenderly.co](https://tenderly.co/) - [ドキュメント](https://docs.tenderly.co/) - [GitHub](https://github.com/Tenderly) - [Discord](https://discord.gg/eCWjuvt) -**Hardhat - _イーサリアムソフトウェアのコンパイル、デプロイ、テスト、デバッグができる開発環境。_** +**Hardhat - _イーサリアムソフトウェアのコンパイル、デプロイ、テスト、デバッグを行うための開発環境_** - [hardhat.org](https://hardhat.org/getting-started/) -- [コントラクトのデプロイについてのドキュメント](https://hardhat.org/docs/tutorial/deploying) +- [コントラクトのデプロイに関するドキュメント](https://hardhat.org/docs/tutorial/deploying) - [GitHub](https://github.com/nomiclabs/hardhat) - [Discord](https://discord.com/invite/TETZs2KK4k) -**サードウェブ - _単一のコマンドを使い、任意のコントラクトを任意のEVM互換チェーンに容易にデプロイ_** +**thirdweb - _単一のコマンドを使用して、あらゆるコントラクトをあらゆる EVM 互換チェーンに簡単にデプロイ_** - [ドキュメント](https://portal.thirdweb.com/deploy/) -**Crossmint - _エンタープライズグレードのweb3開発プラットフォームで、スマートコントラクトのデプロイ、クレジットカードの有効化、クロスチェーン支払いが可能です。また、NFTの作成、配布、売却、保存、編集では、APIが使用可能です。_** +**Crossmint - _スマートコントラクトをデプロイし、クレジットカード決済とクロスチェーン決済を有効にし、API を使用して NFT の作成、配布、販売、保管、編集を可能にする、エンタープライズグレードの Web3 開発プラットフォームです。_** - [crossmint.com](https://www.crossmint.com) - [ドキュメント](https://docs.crossmint.com) @@ -62,20 +62,20 @@ lang: ja ## 関連チュートリアル {#related-tutorials} -- [最初のスマートコントラクトのデプロイ](/developers/tutorials/deploying-your-first-smart-contract/) _- イーサリアムテストネットワークに最初のスマートコントラクトをデプロイする方法の紹介_ -- [Hello World | スマートコントラクトチュートリアル](/developers/tutorials/hello-world-smart-contract/) _– 基本的なスマートコントラクトの作成と、イーサリアムへのデプロイ方法を学ぶための、わかりやすいチュートリアル_ -- [Solidityを使用した他のコントラクトとの連携](/developers/tutorials/interact-with-other-contracts-from-solidity/) _- 既存のコントラクトからスマートコントラクトをデプロイし、それを扱う方法_ -- [コントラクトのサイズを小さくする方法](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- コントラクトコードのサイズをリミットよりも下げて、ガスを節約する方法_ +- [最初のスマートコントラクトをデプロイする](/developers/tutorials/deploying-your-first-smart-contract/) _– イーサリアムのテストネットワークに最初のスマートコントラクトをデプロイするための入門ガイド。_ +- [Hello World | スマートコントラクトチュートリアル](/developers/tutorials/hello-world-smart-contract/) _– イーサリアム上で基本的なスマートコントラクトを作成およびデプロイするための、分かりやすいチュートリアル。_ +- [Solidityから他のコントラクトと対話する](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– 既存のコントラクトからスマートコントラクトをデプロイし、それと対話する方法。_ +- [コントラクトサイズを縮小する方法](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- コントラクトのサイズを制限内に収め、ガスを節約するためにサイズを縮小する方法_ -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_ -- [Hardhatを使用したコントラクトのデプロイ](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ +- [Hardhat を使用したコントラクトのデプロイ](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} - [開発フレームワーク](/developers/docs/frameworks/) -- [イーサリアムノードの運用](/developers/docs/nodes-and-clients/run-a-node/) -- [Nodes-as-a-service(サービスとしてのノード)](/developers/docs/nodes-and-clients/nodes-as-a-service) +- [イーサリアムノードの実行](/developers/docs/nodes-and-clients/run-a-node/) +- [サービスとしてのノード (Nodes-as-a-service)](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/ja/developers/docs/smart-contracts/formal-verification/index.md index c5e372848f2..804346901a3 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/formal-verification/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/formal-verification/index.md @@ -1,12 +1,12 @@ --- -title: スマートコントラクトの形式的検証 -description: イーサリアムのスマートコントラクトのための形式的検証の概要 +title: "スマートコントラクトの形式的検証" +description: "イーサリアムのスマートコントラクトのための形式的検証の概要" lang: ja --- -[スマートコントラクト](/developers/docs/smart-contracts/) は分散型でトラストレスかつ堅牢なアプリケーションの作成を可能とし、それによってユーザーに対して新しいユースケースを導入し、さらなる価値を引き出します。 スマートコントラクトが取り扱うものには巨額の価値があるため、デベロッパーにとってセキュリティは極めて重要です。 +[スマートコントラクト](/developers/docs/smart-contracts/)は、分散型でトラストレス、かつ堅牢なアプリケーションの作成を可能にし、ユーザーに新しいユースケースを導入し、価値を解き放ちます。 スマートコントラクトが取り扱うものには巨額の価値があるため、デベロッパーにとってセキュリティは極めて重要です。 -形式的検証は[スマートコントラクトのセキュリティ](/developers/docs/smart-contracts/security/)を向上させるために推奨される技術のひとつです。 形式的検証は、[形式手法](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/)によってプログラムの仕様記述、設計および検証を行うもので、極めて重要性の高いハードウェアやソフトウェアシステムの正しさを保証するのに以前から使われてきました。 +形式的検証は、[スマートコントラクトのセキュリティ](/developers/docs/smart-contracts/security/)を向上させるために推奨される手法の1つです。 プログラムの仕様記述、設計、検証に[形式手法](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/)を用いる形式的検証は、クリティカルなハードウェアやソフトウェアシステムの正当性を保証するために、長年用いられてきました。 スマートコントラクトに形式的検証を実施することで、スマートコントラクトの挙動があらかじめ規定された仕様を満たすことが証明できます。 スマートコントラクトのコードの正しさを査定する他の手法(テスト技法など)と比べて、形式的検証はスマートコントラクトが機能的に正しいことをより強力に保証します。 @@ -18,81 +18,81 @@ lang: ja ### 形式モデルとは何か {#what-is-a-formal-model} -計算機科学において、 [計算の形式モデル](https://en.wikipedia.org/wiki/Model_of_computation)は計算プロセスを数学的に記述するものです。 プログラムは数学的な関数(方程式)によって抽象化され、関数の入力に対して出力をどう計算するかが形式モデルによって記述されます。 +コンピューターサイエンスでは、[形式モデル](https://en.wikipedia.org/wiki/Model_of_computation)は、計算プロセスを数学的に記述したものです。 プログラムは数学的な関数(方程式)によって抽象化され、関数の入力に対して出力をどう計算するかが形式モデルによって記述されます。 -形式モデルは、プログラムの挙動の分析を評価できる水準での抽象化を可能とします。 形式モデルがあることで_形式仕様_が作成でき、それによって、問題となっているモデルの持つべき望ましいプロパティが記述されます。 +形式モデルは、プログラムの挙動の分析を評価できる水準での抽象化を可能とします。 形式モデルがあることで_形式仕様_を作成でき、それによって、対象のモデルの持つべき望ましいプロパティが記述されます。 形式的検証のためのスマートコントラクトのモデル化には、さまざまな技法が用いられます。 たとえば、スマートコントラクトの高水準な挙動を論証するために用いられるモデルがあります。 そのようなモデル化技法では、スマートコントラクトを与えられた入力に基いて計算を実行するブラックボックスとみなします。 高水準なモデルでは、スマートコントラクトと外部エージェント(外部所有アカウント(EOA)、コントラクトアカウントもしくはブロックチェーン環境)との関係に重点が置かれます。 このようなモデルは、スマートコントラクトが特定のユーザーインタラクションにどう応じるべきかを記述するのに有用です。 -逆に、スマートコントラクトの低水準な挙動に重点を置く形式モデルもあります。 高水準なモデルはスマートコントラクトの機能について論証するのに役立ちますが、その反面、実装の内部動作の詳細が上手く掴めないこともあります。 低水準なモデルのプログラム解析ではプログラムをホワイトボックスとみなし、スマートコントラクトの実行に関連するプロパティの論証では、プログラムトレースや[制御フローグラフ](https://en.wikipedia.org/wiki/Control-flow_graph)など、スマートコントラクトアプリケーションの低水準な表現を利用します。 +逆に、スマートコントラクトの低水準な挙動に重点を置く形式モデルもあります。 高水準なモデルはスマートコントラクトの機能について論証するのに役立ちますが、その反面、実装の内部動作の詳細が上手く掴めないこともあります。 低レベルモデルはプログラム分析にホワイトボックスビューを適用し、プログラムトレースや[制御フローグラフ](https://en.wikipedia.org/wiki/Control-flow_graph)といったスマートコントラクトアプリケーションの低レベルな表現を利用して、コントラクトの実行に関連するプロパティを推論します。 -低水準なモデルはイーサリアムの実行環境([EVM](/developers/docs/evm/))における実際の実行を表すため、理想的であると考えられています。 低水準なモデリング技法は、スマートコントラクトの重要な安全性の確立と潜在的な脆弱性の検出に特に有用です。 +低レベルモデルは、イーサリアムの実行環境(すなわち[EVM](/developers/docs/evm/))におけるスマートコントラクトの実際の実行を表すため、理想的であると考えられています。 低水準なモデリング技法は、スマートコントラクトの重要な安全性の確立と潜在的な脆弱性の検出に特に有用です。 ### 形式仕様記述とは何か {#what-is-a-formal-specification} 仕様とは、特定のシステムが満たすべき技術的要件のことです。 プログラミングにおいては、仕様はプログラムの実行についてのおおまかな狙い(すなわち、プログラムが何をすべきか)を表します。 -スマートコントラクトの文脈では、形式仕様記述はスマートコントラクトが満たさなければならない要件を形式的に記述したものであり、これを_プロパティ_と呼びます。 プロパティはスマートコントラクトの実行を通しての「不変条件」として記述され、例外なしにあらゆる状況下で真であるべき論理アサーションを表現するものです。 +スマートコントラクトの文脈において、形式仕様とは、コントラクトが満たさなければならない要件を形式的に記述した_プロパティ_を指します。 プロパティはスマートコントラクトの実行を通しての「不変条件」として記述され、例外なしにあらゆる状況下で真であるべき論理アサーションを表現するものです。 したがって、形式仕様記述はスマートコントラクトのしかるべき挙動を形式言語で記述したものの集まりである、と考えることができます。 仕様が対象とするのはスマートコントラクトのプロパティで、スマートコントラクトがさまざまな状況下でどのように動作すべきかを表します。 スマートコントラクトがそれらのプロパティ(不変条件) を実行中に破らないことを見極めるのが、 形式的検証の目的です。 形式仕様記述は、スマートコントラクトのセキュアな実装をする上で極めて重要です。 求められた不変条件を満たさなかったり、実行中にプロパティを破るスマートコントラクトには、その機能を害したり悪用を許してしまう脆弱性があるおそれがあります。 -## スマートコントラクトの形式仕様記述の種類 {#formal-specifications-for-smart-contracts} +## スマートコントラクトの形式仕様の種類 {#formal-specifications-for-smart-contracts} 形式的仕様記述により、プログラム実行の正しさを数学的に論証することが可能となります。 形式モデルと同様、形式仕様記述は高水準のプロパティもしくはスマートコントラクトの実装の低水準の挙動をとらえることができます。 -形式仕様記述はプログラム論理を用いて導出され、それによってプログラムのプロパティが形式的に論証できるようになります。 プログラム論理が備えている形式規則により、プログラムのしかるべき挙動が(数学的に)表現されます。 [到達可能性論理](https://en.wikipedia.org/wiki/Reachability_problem)、[時相論理](https://en.wikipedia.org/wiki/Temporal_logic)、[ホーア論理](https://en.wikipedia.org/wiki/Hoare_logic)を含む様々なプログラム論理が形式仕様記述に用いられます。 +形式仕様は、[プログラム論理](https://en.wikipedia.org/wiki/Logic_programming)の要素を用いて導出され、プログラムのプロパティについて形式的に推論することを可能にします。 プログラム論理が備えている形式規則により、プログラムのしかるべき挙動が(数学的に)表現されます。 形式仕様の作成には、[到達可能性論理](https://en.wikipedia.org/wiki/Reachability_problem)、[時相論理](https://en.wikipedia.org/wiki/Temporal_logic)、[ホーア論理](https://en.wikipedia.org/wiki/Hoare_logic)など、さまざまなプログラム論理が使用されます。 -スマートコントラクトの形式仕様記述は**高水準**な仕様記述と**低水準**な仕様記述に大別されます。 いずれの場合でも、分析対象のシステムのプロパティを適切かつ一義的に記述できなければなりません。 +スマートコントラクトの形式仕様は、**高水準**仕様と**低水準**仕様に大別できます。 いずれの場合でも、分析対象のシステムのプロパティを適切かつ一義的に記述できなければなりません。 -### 高水準な仕様記述 {#high-level-specifications} +### 高水準仕様 {#high-level-specifications} -その名のとおり、高水準な仕様記述(「モデル指向仕様記述」とも呼ばれます) はプログラムの高水準な挙動を記述するためのものです。 高水準な仕様記述においてスマートコントラクトは[有限状態機械](https://en.wikipedia.org/wiki/Finite-state_machine)(FSM)としてモデル化されます。スマートコントラクトの挙動は処理の実行を伴う状態遷移で表され、モデルの形式的プロパティは時相論理で記述されます。 +その名のとおり、高水準な仕様記述(「モデル指向仕様記述」とも呼ばれます) はプログラムの高水準な挙動を記述するためのものです。 高水準仕様では、スマートコントラクトを[有限状態機械](https://en.wikipedia.org/wiki/Finite-state_machine)(FSM)としてモデル化します。FSMは操作を実行することで状態間を遷移し、そのFSMモデルの形式的プロパティの定義には時相論理が用いられます。 -[時相論理](https://en.wikipedia.org/wiki/Temporal_logic)は時間という条件の付いた命題(たとえば、「私は_いつも_空腹だ」や「私は_いずれ_空腹になる」)を論証するための規則の集まりです。 形式的検証での時相論理は、状態遷移機械でモデル化されたシステムの正しい挙動に関するアサーションを記述するために使われます。 具体的には、スマートコントラクトがある将来の時点でモデルのどの状態にあるのか、そしてどのように状態間で遷移するのかを時相論理で記述できます。 +[時相論理](https://en.wikipedia.org/wiki/Temporal_logic)とは、「時間という観点から修飾された命題(例：「私は_いつも_空腹である」または「私は_いずれ_空腹になる」)について推論するためのルール」です。 形式的検証での時相論理は、状態遷移機械でモデル化されたシステムの正しい挙動に関するアサーションを記述するために使われます。 具体的には、スマートコントラクトがある将来の時点でモデルのどの状態にあるのか、そしてどのように状態間で遷移するのかを時相論理で記述できます。 -高水準な仕様記述は一般に**安全性 (safety)**と**活性 (liveness)**という、スマートコントラクトの時相に関する重要な2つのプロパティを捕えることができます。 安全性とはすなわち「何も悪いことが起こらない」ということで、通常は不変条件によって表されます。 安全性は、[デッドロック](https://www.techtarget.com/whatis/definition/deadlock)が起こらないことといった一般的なソフトウェア要件を意味することもあれば、スマートコントラクトのドメイン固有なプロパティ(たとえば関数に対するアクセス制御の不変条件、状態変数の許容値、トークン転送の条件など)を意味することもあります。 +高水準仕様は一般に、スマートコントラクトの2つの重要な時相プロパティ、すなわち**安全性**と**活性**を捉えます。 安全性とはすなわち「何も悪いことが起こらない」ということで、通常は不変条件によって表されます。 安全性プロパティは、[デッドロック](https://www.techtarget.com/whatis/definition/deadlock)フリーなどの一般的なソフトウェア要件を定義することもあれば、コントラクトのドメイン固有のプロパティ(例：関数のアクセス制御の不変量、状態変数の許容値、トークン送金の条件)を表現することもあります。 -例として、_「送金しようとしているトークンの量に対し、送金元の口座残高に不足があってはならない」_という、 ERC-20トークンのスマートコントラクトで`transfer()`や`transferFrom()`を呼び出す際の安全性の要求仕様を考えます。 この自然言語で書かれたスマートコントラクトの不変条件は数学的な形式仕様記述に翻訳され、その妥当性が厳密に検査されます。 +ERC-20トークンコントラクトで`transfer()`または`transferFrom()`を使用する条件をカバーする、この安全性要件を例にとってみましょう：_「送信者の残高は、送信要求されたトークンの量を下回ってはならない」_。 この自然言語で書かれたスマートコントラクトの不変条件は数学的な形式仕様記述に翻訳され、その妥当性が厳密に検査されます。 -活性は「何らかの良いことがいずれは起こる」ということを意味し、スマートコントラクトに関しては、するべき処理を滞りなく進められることを示します。 活性の一例として「流動性」が挙げられ、これは、要求に応じてスマートコントラクトが残高を他ユーザーに譲渡できることを意味します。 このプロパティが破られると、[パリティウォレット事件](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html)で起こったように、あるはずの資産が引き出せなくなります。 +活性は「何らかの良いことがいずれは起こる」ということを意味し、スマートコントラクトに関しては、するべき処理を滞りなく進められることを示します。 活性の一例として「流動性」が挙げられ、これは、要求に応じてスマートコントラクトが残高を他ユーザーに譲渡できることを意味します。 このプロパティに違反した場合、[Parityウォレット事件](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html)で起こったように、ユーザーはコントラクトに保管されている資産を引き出すことができなくなります。 -### 低水準な仕様記述 {#low-level-specifications} +### 低水準仕様 {#low-level-specifications} 高水準な仕様記述では、有限状態モデルから出発してモデルの望ましいプロパティを記述しました。 一方で、低水準な仕様記述(プロパティ指向仕様記述とも呼ばれます)では、プログラム(すなわちスマートコントラクト)を数学的な関数の集まりからなるシステムとしてモデル化し、そのシステムの正しい挙動を記述します。 -簡単に言うと、低水準な仕様記述では_プログラムのトレース_ を解析し、それに基づいてスマートコントラクトのプロパティを記述することを目指します。 トレースとは、スマートコントラクトの状態変化を伴った関数の実行シーケンスを指します。したがって、低水準な仕様記述ではスマートコントラクト内部の実行の様子についての要求仕様まで記述できます。 +簡単に言うと、低水準仕様ではプログラムの_トレース_を解析し、それに基づいてスマートコントラクトのプロパティを定義しようと試みます。 トレースとは、スマートコントラクトの状態変化を伴った関数の実行シーケンスを指します。したがって、低水準な仕様記述ではスマートコントラクト内部の実行の様子についての要求仕様まで記述できます。 低水準な仕様記述は、ホーア型のプロパティもしくはプログラムの実行フローによって与えられます。 -### ホーア型のプロパティ {#hoare-style-properties} +### ホーア式プロパティ {#hoare-style-properties} -[ホーア論理](https://en.wikipedia.org/wiki/Hoare_logic)は、スマートコントラクトなどのプログラムの正当性を論証するための形式規則を提供します。 ホーア型のプロパティは、ホーアトリプルと呼ばれる`{P}c{Q}`という形の式で与えられます。`c`はプログラムで、`P`と`Q`はそれぞれ正式には_事前条件_、_事後条件_と呼ばれる、cの状態についての述語です。 +[ホーア論理](https://en.wikipedia.org/wiki/Hoare_logic)は、スマートコントラクトなどのプログラムの正当性を論証するための形式規則のセットを提供します。 ホーア式プロパティは、ホーアトリプル`{P}c{Q}`で表されます。`c`はプログラムで、`P`と`Q`は`c`(つまりプログラム)の状態に関する述語であり、それぞれ_事前条件_と_事後条件_として正式に記述されます。 -事前条件は関数を正しく実行するために求められる条件を表しています。スマートコントラクトを呼び出す際には、この事前条件が満たされている必要があります。 事後条件は、関数が正しく実行された場合に成立する条件を表しています。関数呼び出しの後はこの事後条件が真となることが期待されます。 ホーア論理の_不変条件_は、関数の実行中は常に維持されます(すなわち、変化しません)。 +事前条件は関数を正しく実行するために求められる条件を表しています。スマートコントラクトを呼び出す際には、この事前条件が満たされている必要があります。 事後条件は、関数が正しく実行された場合に成立する条件を表しています。関数呼び出しの後はこの事後条件が真となることが期待されます。 ホーア論理の_不変条件_は、関数の実行によって維持される(つまり変化しない)述語です。 -ホーア型の仕様記述により、_部分正当性_もしくは_完全正当性_が保証されます。 事前条件が関数実行前に真であり、実行が停止した場合には事後条件も真であるとき、スマートコントラクト関数の実装は「部分正当性を満たし」ます。 完全正当性を証明するには、関数の実行前に事前条件が真であること、実行が終了すること、その際に事後条件が真であることの三つが必要です。 +ホーア式の仕様では、_部分的正当性_または_完全な正当性_のいずれかが保証されます。 事前条件が関数実行前に真であり、実行が停止した場合には事後条件も真であるとき、スマートコントラクト関数の実装は「部分正当性を満たし」ます。 完全正当性を証明するには、関数の実行前に事前条件が真であること、実行が終了すること、その際に事後条件が真であることの三つが必要です。 プログラムによっては実行が終わるのに時間がかかったり、そもそも終わらなかったりするので、完全正当性の証明は困難となります。 とはいえ、イーサリアムのガスメカニズムが無限ループを防ぐので、実行が終了するかどうかは議論の余地はあれども理論上の問題点です(実行は正常に終了するか、'ガス不足'のエラーで打ち切られます)。 ホーア論理で作成されたスマートコントラクトの仕様記述は、スマートコントラクト内部の関数やループを実行するために述べられた事前条件、事後条件、不変条件を含みます。 事前条件が関数への誤った入力を許容する場合もあり、その際は事後条件でそのような誤った入力があった場合の応答(例外を発生させるなど)が記述されます。 このようにして、ホーア型のプロパティはスマートコントラクト実装の正当性を保証する際に効果を発揮します。 -多くの形式的検証のフレームワークで、関数の意味的正当性を証明するためにホーア型の仕様記述が使われています。 Solidityの`require`と`assert`ステートメントを使えば、スマートコントラクトのコードにホーア型のプロパティを(アサーションとして) 直接書くこともできます。 +多くの形式的検証のフレームワークで、関数の意味的正当性を証明するためにホーア型の仕様記述が使われています。 また、Solidity の `require` および `assert` 文を使用することで、ホーア式プロパティを(アサーションとして)コントラクトコードに直接追加することも可能です。 -`require`ステートメントは事前条件もしくは不変条件を書くのに用いられ、ユーザーから与えられた入力の有効性を確認するのに使われることが多く、その一方で`assert`ステートメントは安全性のために必要な事後条件を書くのに使われます。 たとえば、 関数への適切なアクセス制御(安全性プロパティの一例) は、`require`ステートメントを使用して、該当する関数を呼び出そうとしているアカウントの識別情報を前提条件チェックすることで実現できます。 同様に、`assert`ステートメントで実行後のスマートコントラクトの状態を確認することで、コントラクト内部の状態変数(たとえば、流通しているトークンの総数など)が許容される値であることを示す不変条件を違反しないが保護することがであることを示す不変条件の違反を防ぐことができます。 +`require`文は事前条件または不変条件を表現し、多くの場合ユーザー入力の検証に使用されます。一方、`assert`は安全性に必要な事後条件を捕捉します。 例えば、関数の適切なアクセス制御(安全性プロパティの一例)は、呼び出しアカウントのIDに対する事前条件チェックとして `require` を使用することで実現できます。 同様に、コントラクト内の状態変数の許容値に関する不変条件(例：流通しているトークンの総数)は、関数実行後に `assert` を使用してコントラクトの状態を確認することで、違反から保護することができます。 ### トレースレベルのプロパティ {#trace-level-properties} トレースベースの仕様記述では、スマートコントラクトの状態を遷移する操作や、操作間にある関係を定義します。 前述したように、トレースは特定の方法でスマートコントラクトの状態を変化させる操作シーケンスです。 -このアプローチは、スマートコントラクトのモデルがいくつかの定義済みの状態(状態変数で表されます) および遷移(スマートコントラクトの関数で表されます) を備えた状態遷移系で与えられていることを前提としています。 さらに、 スマートコントラクトの操作的意味論を記述するには、プログラムの実行の流れを図示する[制御フローグラフ](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG) がよく用いられます。 ここで、各トレースは制御フローグラフ上のパスで表されます。 +このアプローチは、スマートコントラクトのモデルがいくつかの定義済みの状態(状態変数で表されます) および遷移(スマートコントラクトの関数で表されます) を備えた状態遷移系で与えられていることを前提としています。 さらに、プログラムの実行フローをグラフで表現した[制御フローグラフ](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/)(CFG)が、コントラクトの操作的意味論を記述するためによく使用されます。 ここで、各トレースは制御フローグラフ上のパスで表されます。 主に、トレースレベルの仕様記述は、スマートコントラクトの内部の実行のパターンを論じる際に用いられます。 トレースレベルでの仕様記述を作成することで、スマートコントラクトに許容される実行パス(すなわち、状態遷移)をアサートできます。 シンボリック実行などの手法を用いれば、形式的モデルで定義されていないパスには実行が進まないことを形式的に検証することができます。 -例として、公開されている関数でトレースレベルのプロパティの記述ができる[DAO](/dao/)コントラクトを見てみましょう。 ここでは、DAOコントラクトによってユーザーが以下の操作を実行できることとします。 +トレースレベルのプロパティを説明するために、パブリックにアクセス可能な関数を持つ[DAO](/dao/)コントラクトの例を使用してみましょう。 ここでは、DAOコントラクトによってユーザーが以下の操作を実行できることとします。 - 入金 @@ -100,19 +100,19 @@ lang: ja - 提案への投票をしなかった者は返金を要求する -トレースレベルのプロパティの例として、 _「資金を入金しないユーザーは、提案に投票できない」_ または _「提案に投票しないユーザーは、いつでも返金を要求できる」_などが考えられます。 どちらのプロパティも望ましい実行シーケンスをアサートします(入金する_前_に投票することはできず、提案に投票した_後_に払い戻しの要求はできません)。 +トレースレベルのプロパティの例としては、_「資金を入金しないユーザーは、提案に投票できない」_または_「提案に投票しないユーザーは、いつでも返金を要求できる」_などが考えられます。 どちらのプロパティも望ましい実行シーケンスを表明します(入金する_前_に投票することはできず、提案に投票した_後_に払い戻しを要求することはできません)。 -## スマートコントラクトの形式的検証の技法 {#formal-verification-techniques} +## スマートコントラクトの形式的検証の手法 {#formal-verification-techniques} ### モデル検査 {#model-checking} モデル検査は、仕様記述に対し、アルゴリズムによってスマートコントラクトの形式的モデルの検査を行う形式的検証の技法です。 モデル検査では通常、スマートコントラクトは状態遷移システムとして表され、許容されるコントラクトの状態のプロパティは時相論理を用いて定義されます。 -モデル検査では、システム(すなわち、スマートコントラクト)を抽象的かつ数学的に表すことと、システムが満たすべきプロパティを[命題論理](https://www.baeldung.com/cs/propositional-logic)に根差した論理式で表すことが求められます。 これにより、モデル検査アルゴリズムの目的は、数学的モデルが与えられた論理式を充足することの証明、と単純化されます。 +モデル検査では、システム(すなわちコントラクト)の抽象的な数学的表現を作成し、そのシステムのプロパティを[命題論理](https://www.baeldung.com/cs/propositional-logic)に根差した式を用いて表現する必要があります。 これにより、モデル検査アルゴリズムの目的は、数学的モデルが与えられた論理式を充足することの証明、と単純化されます。 -形式的検証におけるモデル検査は主として、スマートコントラクトの挙動を時間経過を加味して記述する時間的プロパティの評価に用いられます。 そのような、時間が関係するスマートコントラクトのプロパティには、先に説明した_安全性_と_活性_が含まれます。 +形式的検証におけるモデル検査は主として、スマートコントラクトの挙動を時間経過を加味して記述する時間的プロパティの評価に用いられます。 スマートコントラクトの時相プロパティには、先に説明した_安全性_と_活性_が含まれます。 -たとえば、アクセス制御(たとえば、 _スマートコントラクトの所有者に限り`selfdestruct`_を呼び出すことができます)に関するセキュリティプロパティが形式論理で記述できます。 その後、モデル検査のアルゴリズムはスマートコントラクトがこの形式的仕様を満たしているかどうかを検証することができます。 +例えば、アクセス制御に関連するセキュリティプロパティ(例：_コントラクトの所有者のみが `selfdestruct` を呼び出せる_)は、形式論理で記述できます。 その後、モデル検査のアルゴリズムはスマートコントラクトがこの形式的仕様を満たしているかどうかを検証することができます。 モデル検査では、スマートコントラクトのすべての起こりうる状態を正確に描き、そのうちの到達可能な状態を見つけだそうと試みることで、状態空間の探索をします。 しかし、これは無限の状態数につながる可能性があります(「状態爆発問題」として知られています)。そのため、モデル検査器は抽象化技法によってスマートコントラクトの分析を効率化します。 @@ -120,7 +120,7 @@ lang: ja 定理証明は、スマートコントラクトなどのプログラムの正しさを数学的に論証する手法です。 スマートコントラクトのシステムとその仕様記述を数式(論理式)で書き下す必要があります。 -定理証明で目指すのは、それらの数式が論理的に等価であると検証することです。 「論理的な等価性」(「論理的な双含意」とも呼ばれます)は二つのステートメント間の関係の一種で、片方が真の_時かつその時に限り_もう片方も真となることです。 +定理証明で目指すのは、それらの数式が論理的に等価であると検証することです。 「論理的同値」(「論理的双含意」とも呼ばれます)は、2つの文間の関係の一種で、第1の文が真である場合_に限り_、第2の文も真となります。 スマートコントラクトのモデルに関するステートメントとそのプロパティのステートメントとの間に要求された関係性(論理的等価性)は、証明可能なステートメント(定理と呼ばれます)として定式化されます。 形式的な推論システムにより、自動定理証明器は定理の妥当性を検証することができます。 言い換えれば、定理証明器はスマートコントラクトのモデルが仕様記述に正確に適合していることを、疑いの余地のない形で証明することができます。 @@ -130,13 +130,13 @@ lang: ja ### シンボリック実行 {#symbolic-execution} -シンボリック実行は、関数の実行にあたって_具体的な値_(例えば`x == 5`)の代わりに_シンボリックな値_(例えば`x > 5`)を用いることで、スマートコントラクトの分析を行う手法です。 形式的検証の手法として、シンボリック実行によってスマートコントラクトのコード中のトレースレベルのプロパティを形式的に論証することができます。 +シンボリック実行は、_具体的値_(例：`x == 5`)の代わりに_シンボリック値_(例：`x > 5`)を用いて関数を実行することで、スマートコントラクトを分析する手法です。 形式的検証の手法として、シンボリック実行によってスマートコントラクトのコード中のトレースレベルのプロパティを形式的に論証することができます。 -シンボリック実行では、実行トレースはシンボリックな入力値を含む数式で表され、これを_パス述語_と呼びます。 [SMTソルバー](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories)はパス述語が「充足可能」(すなわち、論理式を満たす値が存在する)かどうかを検査するのに用いられます。 脆弱性のあるパスが充足可能であれば、SMTソルバーはそのようなパスへと実行を進めてしまう具体的な値を生成します。 +シンボリック実行では、実行トレースをシンボリック入力値に関する数式、別名_パス述語_として表現します。 [SMTソルバー](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories)は、パス述語が「充足可能」(すなわち、式を満たす値が存在する)かどうかを検査するために用いられます。 脆弱性のあるパスが充足可能であれば、SMTソルバーはそのようなパスへと実行を進めてしまう具体的な値を生成します。 -入力として`uint`の値(`x`)を取り、`x`が`5`より大きく、`10`より小さい場合にリバートするスマートコントラクトの関数を考えます。 通常のテストの手順では、エラーとなる`x`の値を求めるのに、実際にそのような値が見つかる確信のないまま数十(もしくはそれ以上の)テストケースを実行することになります。 +あるスマートコントラクトの関数が `uint` 値 (`x`) を入力として受け取り、`x` が `5` より大きく、かつ `10` より小さい場合にリバートするとします。 通常のテスト手順でエラーをトリガーする `x` の値を見つけるには、実際にエラーを引き起こす入力を見つけられるという保証なしに、数十(あるいはそれ以上)のテストケースを実行する必要があります。 -逆に、シンボリック実行のツールは`X > 5 ∧ X < 10`(つまり、`x`は5より大きく、かつ、`x`は10より小さい)といったシンボリックな値を用いて関数を実行します。 関連するパス述語`x = X > 5 X < 10`は、これを解くためにSMTソルバーに渡されます。 ある値が論理式`x = X > 5 ∧ X < 10`を満たすのであれば、SMTソルバーはそのような値を計算します。たとえば、`x`の値として`7`を出してくるかもしれません。 +逆に、シンボリック実行ツールは、シンボリック値 `X > 5 ∧ X < 10` (すなわち、`x` は5より大きく、かつ`x` は10より小さい) を用いて関数を実行します。 関連するパス述語 `x = X > 5 ∧ X < 10` は、それを解くためにSMTソルバーに渡されます。 ある特定の値が `x = X > 5 ∧ X < 10` という式を満たす場合、SMTソルバーはそれを計算します。例えば、ソルバーは `x` の値として `7` を生成するかもしれません。 シンボリック実行はプログラムへの入力によって行うもので、到達可能なあらゆる状態を探索するための入力集合は潜在的に無限となるため、これは依然としてテスト技法の一形態です。 ただし、例に示すように、プロパティに反する入力を見付けることについては、シンボリック実行は通常のテスト技法より効果的です。 @@ -152,43 +152,44 @@ function safe_add(uint x, uint y) returns(uint z){ require(z>=y); return z; +} ``` -整数のオーバーフローを起こす実行トレースは、`z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)`という論理式を満たす必要があります。そのような論理式は解けそうにもなく、`safe_add`関数が決してオーバーフローしないことの数学的証明としての役目を果たします。 +整数オーバーフローを発生させる実行トレースは、`z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)`という式を満たす必要があります。このような式は解ける可能性が低いため、`safe_add`関数がオーバーフローしないことの数学的証明となります。 ### なぜスマートコントラクトを形式的に検証するのか {#benefits-of-formal-verification} #### 信頼性の必要性 {#need-for-reliability} -形式的検証は、システム障害によって死傷者を出したり金融破綻を引きおこすなどの破滅的な結果となりうる、セーフティークリティカル・システムの正しさを評価するのに使用されます。 スマートコントラクトは膨大な価値を管理するアプリケーションであり、設計上の単純なエラーが[回復不可能な損失](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/)を引き起こすことになります。 デプロイする前にスマートコントラクトの形式的検証をすることで、ブロックチェーン上で期待通りに動作する保証が高まります。 +形式的検証は、システム障害によって死傷者を出したり金融破綻を引きおこすなどの破滅的な結果となりうる、セーフティークリティカル・システムの正しさを評価するのに使用されます。 スマートコントラクトは膨大な価値を管理する高価値アプリケーションであり、設計上の単純なミスが[ユーザーにとって回復不能な損失](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/)につながる可能性があります。 デプロイする前にスマートコントラクトの形式的検証をすることで、ブロックチェーン上で期待通りに動作する保証が高まります。 特にイーサリアム仮想マシン(EVM)にデプロイされたコードは通常は変更不能であるため、あらゆるスマートコントラクトにおいて信頼性は非常に望ましいことです。 スマートコントラクトは起動後は容易にアップグレードできないので、信頼性の保証の需要により形式的検証が必要とされています。 整数のアンダーフローやオーバーフロー、リエントランスや不十分なガス最適化など、過去に監査担当者やテスターを躓かせてきた扱いにくい問題であっても、形式的検証で検出することができます。 -#### 機能的正確性の証明 {#prove-functional-correctness} +#### 機能的正当性の証明 {#prove-functional-correctness} プログラムテスト技法は、スマートコントラクトがある要求を満たしていることを証明する最も一般的な方法です。 プログラムテストでは、スマートコントラクトに正常に動作することが期待されるサンプルデータを与えて実行し、そのときの挙動を分析します。 期待通りの結果であれば、それが正しさの客観的な証明となります。 -しかし、このアプローチではサンプルに含まれない入力値に関しては正しさを証明することができません。 そのため、スマートコントラクトをテストすることでバグを検出できますが(すなわち、あるコードパスが実行中に望まれる結果を返さないならば)、**バグがないことを疑いの余地のない形で証明することはできません**。 +しかし、このアプローチではサンプルに含まれない入力値に関しては正しさを証明することができません。 したがって、コントラクトのテストはバグの検出に役立ちますが(すなわち、一部のコードパスが実行中に期待される結果を返さない場合)、**バグが存在しないことを決定的に証明することはできません**。 -逆に、形式的検証によって、スマートコントラクトが実行範囲が無限となるような要求を満たすことを、実行すること_なし_に、形式的に証明することができます。 そのためには、スマートコントラクトの正しい挙動の詳細な形式仕様記述を作成し、スマートコントラクトのシステムの形式的(数学的)モデルを開発する必要があります。 そうすれば、形式的な証明手続きによって、スマートコントラクトのモデルとその仕様記述の間に矛盾がないことを確認することができます。 +逆に、形式的検証は、コントラクトを一切実行すること_なく_、スマートコントラクトが無限の実行範囲に対する要件を満たすことを形式的に証明できます。 そのためには、スマートコントラクトの正しい挙動の詳細な形式仕様記述を作成し、スマートコントラクトのシステムの形式的(数学的)モデルを開発する必要があります。 そうすれば、形式的な証明手続きによって、スマートコントラクトのモデルとその仕様記述の間に矛盾がないことを確認することができます。 形式的検証により、スマートコントラクトのビジネスロジックが要件を満たしているかどうかを検証するという問題は、証明もしくは反証できる数学的命題となります。 形式的に命題を証明することで、無限にあるテストケースが有限の手順で検証できるようになります。 形式的検証には、スマートコントラクトが仕様記述に対して機能的に正しいこと証明することの、より良い将来性が見込まれます。 -#### 検証の理想的な対象 {#ideal-verification-targets} +#### 理想的な検証対象 {#ideal-verification-targets} 検証の対象は、形式的に検証すべきシステムを記述します。 形式的検証は、「組み込みシステム」(大きなシステムの一部を形成する小さく単純なソフトウェア)で最もよく使用されます。 また、少数の規則のみを扱うドメインであれば、ドメイン固有のプロパティを検証するためにツールを変更することも容易であるため、形式的検証が適しています。 スマートコントラクトは、少なくともある程度は両方の要件を満たしています。 たとえば、イーサリアムのスマートコントラクトはサイズが小さいため、形式的検証が適しています。 同様に、EVMは単純なルールに従っているため、EVMで実行されるプログラムの意味論的なプロパティの仕様記述とその検証も容易になります。 -### 開発サイクルの短縮 {#faster-development-cycle} +### 開発サイクルの高速化 {#faster-development-cycle} -モデル検査やシンボリック実行などの形式的検証の技法は、一般的にスマートコントラクトのコードの定期的な分析よりも効率的です(テストや監査中に実行されます)。 これは、形式的検証ではアサーションをテストするためにシンボリックな値を用いるからで(「ユーザーが _n_ eth引き出そうとした場合はどうなりますか?」)、 具体的な値を用いる場合(「ユーザーが5 ethを引き出そうとした場合はどうでしょう？」)とは異なります。 +モデル検査やシンボリック実行などの形式的検証の技法は、一般的にスマートコントラクトのコードの定期的な分析よりも効率的です(テストや監査中に実行されます)。 これは、形式的検証がアサーションのテストにシンボリックな値(「ユーザーが _n_ etherを引き出そうとした場合はどうなりますか？」)を用いるためです。 具体的な値を用いる場合(「ユーザーが5 ethを引き出そうとした場合はどうでしょう？」)とは異なります。 シンボリックな入力変数は複数クラスの具体的値をカバーできるため、形式的検証のアプローチでは、より短い時間でより多くのコードカバレッジが期待されます。 形式的検証を効果的に使用することで、開発サイクルを加速させることができます。 形式的検証は、コストのかかる設計エラーを減らすことで、分散型アプリケーション(dapps)を構築するプロセスも改善します。 脆弱性を修正するためにスマートコントラクトをアップグレードするには、コードベースの広範な書き換えと多くの労力が必要です。 形式的検証は、過去にテスターや監査担当者をつまずかせてきたスマートコントラクト実装のエラーを検出することができ、スマートコントラクトのデプロイ前に問題を修正する十分な機会を用意します。 -## 形式的検証の難点 {#drawbacks-of-formal-verification} +## 形式的検証の欠点 {#drawbacks-of-formal-verification} ### 手作業のコスト {#cost-of-manual-labor} @@ -206,78 +207,78 @@ function safe_add(uint x, uint y) returns(uint z){ 形式的検証はパフォーマンス上の問題になります。 例えば、モデル検査とシンボル検査中に発生する状態爆発問題とパス爆発問題により、検証手順に悪影響がありえます。 また、形式的検証ツールは多くの場合にSMTソルバーやその他の制約ソルバーを内部的に使用しており、多量の計算処理を要します。 -プログラムが停止しない可能性([decidability problem](https://en.wikipedia.org/wiki/Decision_problem))もあるため、要求されるプロパティ(論理式として定義される)が満たされるのかどうかも一般には判断できません。 スマートコントラクトのプロパティが正しく記述されていたとしても、証明することが不可能なことがあります。 +また、プログラムが決して停止しない可能性があるため、プログラム検証者がプロパティ(論理式として記述される)が満たされるかどうかを判断することが常に可能であるとは限りません(「[決定可能性問題](https://en.wikipedia.org/wiki/Decision_problem)」)。 スマートコントラクトのプロパティが正しく記述されていたとしても、証明することが不可能なことがあります。 -## イーサリアムのスマートコントラクトのための形式的検証ツール {#formal-verification-tools} +## イーサリアムスマートコントラクトのための形式的検証ツール {#formal-verification-tools} -### 形式的仕様記述のための言語 {#specification-languages} +### 形式仕様を作成するための仕様言語 {#specification-languages} -**Act**: _*ストレージの更新、事前条件・事後条件、スマートコントラクトの不変条件を仕様として記述できます。 Actツールスイートには、Coq、SMTソルバー、hevmを介してプロパティを証明するための、証明バックエンドが含まれます。** +**Act**: __Actは、ストレージの更新、事前/事後条件、コントラクトの不変量の仕様を可能にします。 そのツールスイートには、Coq、SMTソルバー、またはhevmを介して多くのプロパティを証明できる証明バックエンドもあります。__ - [GitHub](https://github.com/ethereum/act) -- [ドキュメント](https://ethereum.github.io/act/) +- [ドキュメント](https://github.com/argotorg/act) -**Scribble** - _*Scribbleは、Scribble仕様言語のコードアノテーションを具体的なアサーションに変換し、仕様記述を検査することができます。** +**Scribble** - __Scribbleは、Scribble仕様言語のコードアノテーションを、仕様をチェックする具体的なアサーションに変換します。__ - [ドキュメント](https://docs.scribble.codes/) -**Dafny** _*Dafnyはプログラム検証との親和性が高いプログラミング言語で、その高水準なアノテーションを用いることでコードの正しさを論証したり証明したりすることができます。** +**Dafny** - __Dafnyは検証対応のプログラミング言語で、高レベルのアノテーションに依存してコードの正当性について推論し、証明します。__ - [GitHub](https://github.com/dafny-lang/dafny) -### 正しさを確認するためのプログラム検証器 {#program-verifiers} +### 正当性をチェックするためのプログラム検証器 {#program-verifiers} -**Certora Prover** _Certora Proverは、スマートコントラクトのコードの正しさを検査するための自動形式的検証ツールです。 仕様記述はCVL(Certora Verification Language)で行い、静的解析と制約解析の組み合わせでプロパティ違反を検出します。_ +**Certora Prover** - _Certora Proverは、スマートコントラクトのコードの正当性をチェックするための自動形式的検証ツールです。 仕様はCVL(Certora Verification Language)で記述され、静的解析と制約解消を組み合わせてプロパティ違反が検出されます。_ - [ウェブサイト](https://www.certora.com/) - [ドキュメント](https://docs.certora.com/en/latest/index.html) -**Solidity SMTChecker** _*Solidity SMTCheckerは、SMT(Satisfiability Modulo Theories)とホーン節の充足問題に基づく組み込みのモデルチェッカーです。 コンパイル中にスマートコントラクトのソースコードが仕様記述に適合することを確認し、安全性プロパティの違反があるかどうかを静的にチェックします。** +**Solidity SMTChecker** - __SolidityのSMTCheckerは、SMT (Satisfiability Modulo Theories) とホーン解決に基づく組み込みのモデルチェッカーです。 コンパイル中にコントラクトのソースコードが仕様と一致するかどうかを確認し、安全性プロパティの違反を静的にチェックします。__ - [GitHub](https://github.com/ethereum/solidity) -**solc-verify** _*solc-verifyはSolidityコンパイラの拡張で、アノテーションとモジュラー型のプログラム検証によって自動的に形式的検証を行います。** +**solc-verify** - __solc-verifyはSolidityコンパイラの拡張版で、アノテーションとモジュラープログラム検証を使用してSolidityコードの自動形式的検証を実行できます。__ - [GitHub](https://github.com/SRI-CSL/solidity) -**KEVM** _*KEVMは、K frameworkで書かれたイーサリアム仮想マシン(EVM)の形式的な意味論です。 KEVMは実行可能であり、到達可能性論理によってある種のプロパティ関連のアサーションの証明に利用できます。** +**KEVM** - __KEVMは、Kフレームワークで書かれたイーサリアム仮想マシン(EVM)の形式的意味論です。 KEVMは実行可能であり、到達可能性論理を用いて特定のプロパティ関連のアサーションを証明できます。__ - [GitHub](https://github.com/runtimeverification/evm-semantics) - [ドキュメント](https://jellopaper.org/) -### 定理証明のための論理枠組み {#theorem-provers} +### 定理証明のための論理フレームワーク {#theorem-provers} -**Isabelle** _証明支援ソフトウェアIsabelle/HOLは、数式を形式言語で表現したり、それらを証明するためのツールで構成されます。 主に数学における証明の形式化とある種の形式的検証に用いられ、コンピュータハードウェアやソフトウェアの正しさの証明やコンピュータ言語やプロトコルの性質の証明などに応用されています。_ +**Isabelle** - _Isabelle/HOLは、数式を形式言語で表現し、それらの式を証明するためのツールを提供する証明支援ツールです。 主な応用分野は、数学的証明の形式化、特に形式的検証であり、これにはコンピュータのハードウェアやソフトウェアの正当性の証明、コンピュータ言語やプロトコルのプロパティの証明が含まれます。_ - [GitHub](https://github.com/isabelle-prover) - [ドキュメント](https://isabelle.in.tum.de/documentation.html) -**Coq** _Coqは対話型の定理証明器で、機械的に検査されたプログラムの正しさの証明を対話的に作成することができます。_ +**Rocq** - _Rocqは対話型の定理証明器で、定理を用いてプログラムを定義し、機械チェックされた正当性の証明を対話的に生成できます。_ -- [GitHub](https://github.com/coq/coq) -- [ドキュメント](https://coq.github.io/doc/v8.13/refman/index.html) +- [GitHub](https://github.com/rocq-prover/rocq) +- [ドキュメント](https://rocq-prover.org/docs) -### シンボリック実行に基いてスマートコントラクトが脆弱となるパターンを検出するツール {#symbolic-execution-tools} +### スマートコントラクトの脆弱なパターンを検出するためのシンボリック実行ベースのツール {#symbolic-execution-tools} -**Manticore** _*シンボリック実行に基づいたEVMバイトコードの解析ツールです。** +**Manticore** - __シンボリック実行に基づくEVMバイトコード分析ツール_。_ - [GitHub](https://github.com/trailofbits/manticore) - [ドキュメント](https://github.com/trailofbits/manticore/wiki) -**hevm** _*hevmはシンボリック実行のエンジンで、EVMバイトコードの同等性を検査することができます。** +**hevm** - __hevmは、EVMバイトコード用のシンボリック実行エンジン兼等価性チェッカーです。__ - [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm) -**Mythril** _イーサリアムスマートコントラクトの脆弱性を検出するシンボリック実行のツールです。_ +**Mythril** - _イーサリアムスマートコントラクトの脆弱性を検出するためのシンボリック実行ツール_ - [GitHub](https://github.com/ConsenSys/mythril-classic) - [ドキュメント](https://mythril-classic.readthedocs.io/en/develop/) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [スマートコントラクトの形式的検証方法](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) -- [形式的検証で完璧なスマートコントラクトを実現する方法](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) -- [イーサリアム・エコシステムにおける形式的検証プロジェクトの概要](https://github.com/leonardoalt/ethereum_formal_verification_overview) -- [イーサリアム2.0の入金スマートコントラクトのエンドツーエンドな形式的検証](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) -- [世界一有名なスマートコントラクトの形式的検証](https://www.zellic.io/blog/formal-verification-weth) +- [スマートコントラクトの形式的検証の仕組み](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) +- [形式的検証が完璧なスマートコントラクトを保証する方法](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) +- [イーサリアムエコシステムにおける形式的検証プロジェクトの概要](https://github.com/leonardoalt/ethereum_formal_verification_overview) +- [イーサリアム2.0デポジットスマートコントラクトのエンドツーエンド形式的検証](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) +- [世界で最も人気のあるスマートコントラクトの形式的検証](https://www.zellic.io/blog/formal-verification-weth) - [SMTCheckerと形式的検証](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/index.md b/public/content/translations/ja/developers/docs/smart-contracts/index.md index f8de276bef9..d9d5b17a704 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/index.md @@ -1,6 +1,6 @@ --- -title: スマートコントラクト入門 -description: 独自の特性と制限に焦点を当てたスマートコントラクトの概要 +title: "スマートコントラクト入門" +description: "独自の特性と制限に焦点を当てたスマートコントラクトの概要" lang: ja --- @@ -10,15 +10,15 @@ lang: ja スマートコントラクトは[イーサリアムアカウント](/developers/docs/accounts/)の一種です。 つまり、残高があり、トランザクションの対象とすることができます。 しかし、スマートコントラクトはユーザーによって制御されるものではなく、ネットワークにデプロイされ、プログラムされた通りに実行されます。 ユーザーアカウントは、スマートコントラクトで定義されている機能を実行するトランザクションを送信することで、スマートコントラクトとやり取りできます。 スマートコントラクトはビジネスにおける契約と同じように、ルールを定めて、そのルールをコードによって自動的に適用することができます。 スマートコントラクトは、デフォルトで削除できないようになっており、スマートコントラクトとのやり取りを取り消すことはできません。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -イーサリアムを使い始めたばかりの方や、あまり技術的ではない入門ドキュメントをお探しの方は、[スマートコントラクト入門](/smart-contracts/)をご覧になることをお勧めします。 +始めたばかりの方や、技術的すぎない入門ガイドをお探しの方には、[スマートコントラクト入門](/smart-contracts/)をお勧めします。 -スマートコントラクトを使い始める前に、[アカウント](/developers/docs/accounts/)、[トランザクション](/developers/docs/transactions/)、[イーサリアム仮想マシン](/developers/docs/evm/)を読んでおいてください。 +スマートコントラクトの世界に飛び込む前に、[アカウント](/developers/docs/accounts/)、[トランザクション](/developers/docs/transactions/)、[イーサリアム仮想マシン](/developers/docs/evm/)について必ず読んでおいてください。 ## デジタル自動販売機 {#a-digital-vending-machine} -スマートコントラクトは、[Nick Szabo](https://unenumerated.blogspot.com/)が説明したように、自動販売機に例えるのが最も適切かもしれません。 適切な入力では、特定の出力が保証されます。 +スマートコントラクトの最も良い例えは、[Nick Szabo](https://unenumerated.blogspot.com/)が説明している自動販売機かもしれません。 適切な入力では、特定の出力が保証されます。 自動販売機でスナックを取得する場合、以下のロジックになります。 @@ -35,27 +35,28 @@ pragma solidity 0.8.7; contract VendingMachine { - // Declare state variables of the contract + // コントラクトの状態変数を宣言 address public owner; mapping (address => uint) public cupcakeBalances; - // When 'VendingMachine' contract is deployed: - // 1. 　 // 2. コントラクトの所有者としてデプロイアドレスを設定 set the deployed smart contract's cupcake balance to 100 + // 'VendingMachine'コントラクトがデプロイされた時: + // 1. デプロイしたアドレスをコントラクトの所有者としてセット + // 2. デプロイされたスマートコントラクトのカップケーキの残高を100にセット constructor() { owner = msg.sender; cupcakeBalances[address(this)] = 100; } - // Allow the owner to increase the smart contract's cupcake balance + // 所有者がスマートコントラクトのカップケーキの残高を増やせるようにする function refill(uint amount) public { - require(msg.sender == owner, "Only the owner can refill."); + require(msg.sender == owner, "補充できるのは所有者のみです。"); cupcakeBalances[address(this)] += amount; } - // Allow anyone to purchase cupcakes + // 誰でもカップケーキを購入できるようにする function purchase(uint amount) public payable { - require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); - require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); + require(msg.value >= amount * 1 ether, "カップケーキ1個あたり少なくとも1ETHを支払う必要があります"); + require(cupcakeBalances[address(this)] >= amount, "この購入を完了するのに十分なカップケーキの在庫がありません"); cupcakeBalances[address(this)] -= amount; cupcakeBalances[msg.sender] += amount; } @@ -66,36 +67,36 @@ contract VendingMachine { ## パーミッションレス {#permissionless} -誰でもスマートコントラクトを作成してネットワークにデプロイできます。 [スマートコントラクト言語](/developers/docs/smart-contracts/languages/)でのコーディング方法を学び、コントラクトをデプロイするのに十分なETHを持っていればよいのです。 スマートコントラクトのデプロイは技術的にはトランザクションなので、単純なETH送金に[ガス](/developers/docs/gas/)を支払う必要があるのと同じように、ガスを支払う必要があります。 ただし、コントラクトのデプロイにかかるガス代は、はるかに高くなります。 +誰でもスマートコントラクトを作成してネットワークにデプロイできます。 [スマートコントラクト言語](/developers/docs/smart-contracts/languages/)でのコーディング方法を学び、コントラクトをデプロイするのに十分なETHを持っているだけでよいのです。 スマートコントラクトのデプロイは技術的にはトランザクションなので、単純なETHの送金でガスを支払う必要があるのと同様に、[ガス](/developers/docs/gas/)を支払う必要があります。 ただし、コントラクトのデプロイにかかるガス代は、はるかに高くなります。 イーサリアムには以下のような、スマートコントラクトを作成するためのデベロッパーフレンドリーな言語があります。 - Solidity - Vyper -[開発言語についての詳細](/developers/docs/smart-contracts/languages/) +[言語についての詳細](/developers/docs/smart-contracts/languages/) -ただし、イーサリアムの仮想マシンがコントラクトコードを解釈して保存できるようするためには、コントラクトをデプロイする前にコンパイルが必要です。 [コンパイルの詳細](/developers/docs/smart-contracts/compiling/) +ただし、イーサリアムの仮想マシンがコントラクトコードを解釈して保存できるようするためには、コントラクトをデプロイする前にコンパイルが必要です。 [コンパイルについての詳細](/developers/docs/smart-contracts/compiling/) ## コンポーザビリティ {#composability} スマートコントラクトはイーサリアム上で公開されており、オープンAPIと考えることができます。 つまり、自分のスマートコントラクトの中で他のスマートコントラクトを呼び出し、自分のスマートコントラクトでできることを大幅に拡張することができるのです。 スマートコントラクトは他のスマートコントラクトをデプロイすることもできます。 -[スマートコントラクトのコンポーザビリティ](/developers/docs/smart-contracts/composability/)についてもっと詳しく知る +[スマートコントラクトのコンポーザビリティ](/developers/docs/smart-contracts/composability/)の詳細はこちら。 -## 制限事項 {#limitations} +## 制約事項 {#limitations} スマートコントラクトだけでは、オフチェーンソースからデータを取得できないため、実世界のイベントに関する情報を得ることはできません。 そのため、実世界のイベントに反応することはできません。 これは、スマートコントラクトの仕様です。 外部の情報に頼ると、セキュリティや分散化のために重要なコンセンサスが損なわれる可能性があるためです。 -しかし、ブロックチェーンアプリケーションにとって、オフチェーンデータが使えることは重要です。 そのためソリューションとして、オフチェーンデータを取り込んでスマートコントラクトで利用できるようにするツールである[オラクル](/developers/docs/oracles/)があります。 +しかし、ブロックチェーンアプリケーションにとって、オフチェーンデータが使えることは重要です。 そのための解決策は、オフチェーンデータを取り込んでスマートコントラクトで利用できるようにするツールである[オラクル](/developers/docs/oracles/)です。 -スマートコントラクトのもう一つの制約は、コントラクトの最大サイズです。 スマートコントラクトの最大サイズは24KBです。それ以上の場合はガス不足になります。 これは、[ダイヤモンドパターン](https://eips.ethereum.org/EIPS/eip-2535)を使用して回避することができます。 +スマートコントラクトのもう一つの制約は、コントラクトの最大サイズです。 スマートコントラクトの最大サイズは24KBです。それ以上の場合はガス不足になります。 これは[The Diamond Pattern](https://eips.ethereum.org/EIPS/eip-2535)を使用することで回避できます。 ## マルチシグコントラクト {#multisig} -マルチシグ(複数署名)コントラクトは、トランザクションを実行するために複数の有効な署名を必要とするスマートコントラクトアカウントです。 これは、相当量のイーサやトークンを保持するコントラクトで単一障害点を回避するのに特に便利です。 マルチシグはまた、コントラクトの実行と鍵の管理の責任を複数の当事者間で分担し、取返しのつかない資金損失につながる秘密鍵の紛失を防ぎます。 これらの理由から、簡単なDAOガバナンスのためにマルチシグコントラクトを利用することができます。 マルチシグでは実行に、許容可能なM個の署名の内のN個の署名(N ≤ M、M > 1)が必要です。 `N = 3, M = 5`と`N = 4, M = 7`が一般的に使用されます。 4/7マルチシグでは、7つの有効な署名のうちの4つが必要です。 これは、3つの署名が失われても資金が回収可能であることを意味します。 この場合、コントラクトを実行するためには、鍵の保有者の過半数の同意と署名が必要であることも意味します。 +マルチシグ(複数署名)コントラクトは、トランザクションを実行するために複数の有効な署名を必要とするスマートコントラクトアカウントです。 これは、相当量のイーサやトークンを保持するコントラクトで単一障害点を回避するのに特に便利です。 マルチシグはまた、コントラクトの実行と鍵の管理の責任を複数の当事者間で分担し、取返しのつかない資金損失につながる秘密鍵の紛失を防ぎます。 これらの理由から、簡単なDAOガバナンスのためにマルチシグコントラクトを利用することができます。 マルチシグは、実行するために、承認可能なM個の署名のうちN個の署名を必要とします(N ≤ M、かつ M > 1)。 `N = 3, M = 5` と `N = 4, M = 7` が一般的に使用されます。 4/7マルチシグでは、7つの有効な署名のうちの4つが必要です。 これは、3つの署名が失われても資金が回収可能であることを意味します。 この場合、コントラクトを実行するためには、鍵の保有者の過半数の同意と署名が必要であることも意味します。 -## スマートコントラクト関連情報 {#smart-contract-resources} +## スマートコントラクト関連リソース {#smart-contract-resources} **OpenZeppelin Contracts -** **_安全なスマートコントラクト開発のためのライブラリ。_** @@ -103,9 +104,9 @@ contract VendingMachine { - [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) - [コミュニティフォーラム](https://forum.openzeppelin.com/c/general/16) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [Coinbase: スマートコントラクトとは何か](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) -- [Chainlink: スマートコントラクトとは何か](https://chain.link/education/smart-contracts) -- [スマートコントラクトの概要を説明するビデオ](https://youtu.be/ZE2HxTmxfrI) -- [Cyfrin Updraft: Web3学習および監査プラットフォーム](https://updraft.cyfrin.io) +- [Coinbase: スマートコントラクトとは](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) +- [Chainlink: スマートコントラクトとは](https://chain.link/education/smart-contracts) +- [ビデオ: スマートコントラクトの簡単な説明](https://youtu.be/ZE2HxTmxfrI) +- [Cyfrin Updraft: Web3学習・監査プラットフォーム](https://updraft.cyfrin.io) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md b/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md index 093d869dbcf..121a788b1d3 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md @@ -1,25 +1,25 @@ --- -title: スマートコントラクト言語 -description: 2つの主要なスマートコントラクト言語であるSolidityとVyperの概要と比較 +title: "スマートコントラクト言語" +description: "2つの主要なスマートコントラクト言語であるSolidityとVyperの概要と比較" lang: ja --- -イーサリアムの長所は、比較的デベロッパーフレンドリーな言語を使ってスマートコントラクトを記述できることです。 Pythonや[中括弧を使ってブロックを表現する言語](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages)を使用している方は、見慣れたような構文を持つ言語を使うことができます。 +イーサリアムの長所は、比較的デベロッパーフレンドリーな言語を使ってスマートコントラクトを記述できることです。 Pythonまたは[波括弧言語](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages)の経験がある場合は、使い慣れた構文の言語を見つけることができます。 最も活発にメンテナンスされている言語は、以下の2つです。 - Solidity - Vyper -Remix IDEは、SolidityとVyperの両方でコントラクトを作成およびテストするための包括的な開発環境を提供します。 [ブラウザ内で動作するRemix IDEを試して](https://remix.ethereum.org)、コーディングを始めましょう。 +Remix IDEは、SolidityとVyperの両方でコントラクトを作成およびテストするための包括的な開発環境を提供します。 [ブラウザ内で動作するRemix IDE](https://remix.ethereum.org)を試して、コーディングを始めましょう。 また、経験豊富なデベロッパーであれば、[イーサリアム仮想マシン](/developers/docs/evm/)用の中間言語であるYulや、Yulを拡張したYul+を使うのもよいでしょう。 開発中の新しい言語に興味があり、テストに協力したいとお考えの場合は、Feというまだ登場したばかりのスマートコントラクト言語を試してみることができます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -プログラミング言語、特にJavaScriptやPythonの知識は、スマートコントラクト言語の違いを理解するのに役立ちます。 また、スマートコントラクトをコンセプトとして理解し、言語比較を深く掘り下げることをお勧めします。 [スマートコントラクトの紹介](/developers/docs/smart-contracts/) +プログラミング言語、特にJavaScriptやPythonの知識は、スマートコントラクト言語の違いを理解するのに役立ちます。 また、スマートコントラクトをコンセプトとして理解し、言語比較を深く掘り下げることをお勧めします。 [スマートコントラクト入門](/developers/docs/smart-contracts/) ## Solidity {#solidity} @@ -31,51 +31,51 @@ Remix IDEは、SolidityとVyperの両方でコントラクトを作成および - ライブラリ(他のオブジェクト指向言語における静的クラスで定義された静的関数のように、さまざまなコントラクトから呼び出すことができる再利用可能なコードを作成できる) - 複雑なユーザー定義型 -### 参照すべきリンク {#important-links} +### 重要なリンク {#important-links} - [ドキュメント](https://docs.soliditylang.org/en/latest/) - [Solidity言語ポータル](https://soliditylang.org/) - [Solidity by Example](https://docs.soliditylang.org/en/latest/solidity-by-example.html) - [GitHub](https://github.com/ethereum/solidity/) -- [Solidity Gitterチャットルーム](https://gitter.im/ethereum/solidity)は、[Solidity Matrixチャットルーム](https://matrix.to/#/#ethereum_solidity:gitter.im)へブリッジされました。 +- [Solidity Gitterチャットルーム](https://gitter.im/ethereum/solidity) ([Solidity Matrixチャットルーム](https://matrix.to/#/#ethereum_solidity:gitter.im)にブリッジ接続) - [チートシート](https://reference.auditless.com/cheatsheet) - [Solidityブログ](https://blog.soliditylang.org/) -- [Solidity Twitter](https://twitter.com/solidity_lang) +- [SolidityのTwitter](https://twitter.com/solidity_lang) -### コントラクトのコード例 {#example-contract} +### コントラクトの例 {#example-contract} ```solidity // SPDX-License-Identifier: GPL-3.0 pragma solidity >= 0.7.0; contract Coin { - // The keyword "public" makes variables - // accessible from other contracts + // 「public」というキーワードにより、変数は + // 他のコントラクトからアクセス可能になります address public minter; mapping (address => uint) public balances; - // Events allow clients to react to specific - // contract changes you declare + // イベントにより、クライアントは + // 宣言された特定のコントラクトの変更に対応できます event Sent(address from, address to, uint amount); - // Constructor code is only run when the contract - // is created + // コンストラクタのコードは、コントラクトが + // 作成されたときにのみ実行されます constructor() { minter = msg.sender; } - // Sends an amount of newly created coins to an address - // Can only be called by the contract creator + // 新たに作成されたコインをアドレスに送金します + // コントラクトの作成者のみが呼び出すことができます function mint(address receiver, uint amount) public { require(msg.sender == minter); require(amount < 1e60); balances[receiver] += amount; } - // Sends an amount of existing coins - // from any caller to an address + // 既存のコインを + // 任意の呼び出し元からアドレスに送金します function send(address receiver, uint amount) public { - require(amount <= balances[msg.sender], "Insufficient balance."); + require(amount <= balances[msg.sender], "残高が不足しています。"); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); @@ -83,7 +83,7 @@ contract Coin { } ``` -この例は、Solidityのコントラクト構文がどのようなものか理解するのに役立つでしょう。 関数と変数のより詳細な説明については、[ドキュメント](https://docs.soliditylang.org/en/latest/contracts.html)を参照してください。 +この例は、Solidityのコントラクト構文がどのようなものか理解するのに役立つでしょう。 関数と変数の詳細な説明については、[ドキュメントをご覧ください](https://docs.soliditylang.org/en/latest/contracts.html)。 ## Vyper {#vyper} @@ -101,9 +101,9 @@ contract Coin { - 無限ループ - 2進固定小数点 -詳細については、[Vyperのドキュメント](https://vyper.readthedocs.io/en/latest/index.html)を参照してください。 +詳細については、[Vyperの理論的根拠をお読みください](https://vyper.readthedocs.io/en/latest/index.html)。 -### 参照すべきリンク {#important-links-1} +### 重要なリンク {#important-links-1} - [ドキュメント](https://vyper.readthedocs.io) - [Vyper by Example](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) @@ -111,100 +111,117 @@ contract Coin { - [GitHub](https://github.com/vyperlang/vyper) - [VyperコミュニティのDiscordチャット](https://discord.gg/SdvKC79cJk) - [チートシート](https://reference.auditless.com/cheatsheet) -- [スマートコントラクト開発フレームワークとVyper用ツール](/developers/docs/programming-languages/python/) -- [VyperPunk - Vyperスマートコントラクトのセキュリティとハッキングを学ぶ](https://github.com/SupremacyTeam/VyperPunk) -- [開発用Vyper Hub](https://github.com/zcor/vyper-dev) -- [人気を博しているVyperのスマートコントラクトの例](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) -- [素晴らしいVyperの厳選されたリソース](https://github.com/spadebuilders/awesome-vyper) +- [Vyper用スマートコントラクト開発フレームワークおよびツール](/developers/docs/programming-languages/python/) +- [VyperPunk - Vyperスマートコントラクトを保護しハッキングする方法を学ぶ](https://github.com/SupremacyTeam/VyperPunk) +- [開発用Vyperハブ](https://github.com/zcor/vyper-dev) +- [Vyperの優れたスマートコントラクトの例](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) +- [Awesome Vyper厳選リソース](https://github.com/spadebuilders/awesome-vyper) ### 例 {#example} ```python -# Open Auction +# オープンオークション + +# オークションのパラメータ + +# 受取人は最高額入札者から資金を受け取ります -# Auction params -# Beneficiary receives money from the highest bidder beneficiary: public(address) auctionStart: public(uint256) auctionEnd: public(uint256) -# Current state of auction +# オークションの現在の状態 + highestBidder: public(address) highestBid: public(uint256) -# Set to true at the end, disallows any change +# 終了時にtrueに設定され、いかなる変更も許可しません + ended: public(bool) -# Keep track of refunded bids so we can follow the withdraw pattern +# 払い戻された入札を追跡し、引き出しパターンに従うことができるようにします + pendingReturns: public(HashMap[address, uint256]) -# Create a simple auction with `_bidding_time` -# seconds bidding time on behalf of the -# beneficiary address `_beneficiary`. +# 受取人アドレス `_beneficiary` のために、 `_bidding_time` 秒の + +# 入札時間を持つ簡単なオークションを作成します。 + @external def __init__(_beneficiary: address, _bidding_time: uint256): self.beneficiary = _beneficiary self.auctionStart = block.timestamp self.auctionEnd = self.auctionStart + _bidding_time -# Bid on the auction with the value sent -# together with this transaction. -# The value will only be refunded if the -# auction is not won. +# このトランザクションと一緒に送信された + +# 金額でオークションに入札します。 + +# この金額は、オークションで落札 + +# できなかった場合にのみ返金されます。 + @external @payable def bid(): - # Check if bidding period is over. + # 入札期間が終了したかどうかを確認します。 assert block.timestamp < self.auctionEnd - # Check if bid is high enough + # 入札額が十分に高いかを確認します assert msg.value > self.highestBid - # Track the refund for the previous high bidder + # 前の最高額入札者の払い戻しを追跡します self.pendingReturns[self.highestBidder] += self.highestBid - # Track new high bid + # 新しい最高額入札を追跡します self.highestBidder = msg.sender self.highestBid = msg.value -# Withdraw a previously refunded bid. The withdraw pattern is -# used here to avoid a security issue. If refunds were directly -# sent as part of bid(), a malicious bidding contract could block -# those refunds and thus block new higher bids from coming in. +# 以前に払い戻された入札を引き出します。ここではセキュリティ上の + +# 問題を避けるために、引き出しパターンが使用されています。 + +# bid()の一部として払い戻しが直接送信された場合、 + +# 悪意のある入札コントラクトがそれらの払い戻しをブロックし、 + +# それによって新しい高額の入札を妨げる可能性があります。 + @external def withdraw(): pending_amount: uint256 = self.pendingReturns[msg.sender] self.pendingReturns[msg.sender] = 0 send(msg.sender, pending_amount) -# End the auction and send the highest bid -# to the beneficiary. +# オークションを終了し、最高入札額を + +# 受取人に送信します。 + @external def endAuction(): - # It is a good guideline to structure functions that interact - # with other contracts (i.e., they call functions or send ether) - # into three phases: - # 1. checking conditions - # 2. performing actions (potentially changing conditions) - # 3. interacting with other contracts - # If these phases are mixed up, the other contract could call - # back into the current contract and modify the state or cause - # effects (ether payout) to be performed multiple times. - # If functions called internally include interaction with external - # contracts, they also have to be considered interaction with - # external contracts. - - # 1. Conditions - # Check if auction endtime has been reached + # 他のコントラクトとやり取りする関数（つまり、関数を呼び出したりetherを送信したりする関数）は、 + # 次の3つのフェーズに構造化するのが良いガイドラインです： + # 1. 条件の確認 + # 2. アクションの実行（条件が変更される可能性あり） + # 3. 他のコントラクトとのやり取り + # これらのフェーズが混在していると、他のコントラクトが現在の + # コントラクトをコールバックして状態を変更したり、 + # （etherの支払いなどの）効果を複数回実行させたりする可能性があります。 + # 内部で呼び出される関数に外部コントラクトとの + # やり取りが含まれる場合、それらも外部コントラクトとの + # やり取りと見なされなければなりません。 + + # 1. 条件 + # オークション終了時刻に達したか確認 assert block.timestamp >= self.auctionEnd - # Check if this function has already been called + # この関数が既に呼ばれたか確認 assert not self.ended - # 2. Effects + # 2. 効果 self.ended = True - # 3. Interaction + # 3. やり取り send(self.beneficiary, self.highestBid) ``` -この例は、Vyperのコントラクト構文がどのようなものか理解するのに役立つでしょう。 関数と変数のより詳細な説明については、[ドキュメント](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction)を参照してください。 +この例は、Vyperのコントラクト構文がどのようなものか理解するのに役立つでしょう。 関数と変数の詳細な説明については、[ドキュメントをご覧ください](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction)。 ## YulとYul+ {#yul} @@ -213,24 +230,24 @@ def endAuction(): **Yul** - イーサリアムのための中間言語 -- [EVM](/developers/docs/evm)および[Ewasm](https://github.com/ewasm)というイーサリアム向けのWebAssemblyをサポートしており、両方のプラットフォームで使用可能な共通部分として設計されている +- [EVM](/developers/docs/evm)および[Ewasm](https://github.com/ewasm)というイーサリアム向けのWebAssemblyをサポートしており、両方のプラットフォームで使用可能な共通部分として設計されています。 - EVMとeWASMの両方のプラットフォームに同程度のメリットをもたらす、高度な最適化段階を経る対象となる **Yul+** - Yulに高効率な拡張機能を施した低レベル言語 -- コントラクトの[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)のために設計された +- 当初は[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)のコントラクト向けに設計されました。 - Yulに新しい機能を追加した実験的なアップグレード案として捉えることができる -### 参照すべきリンク {#important-links-2} +### 重要なリンク {#important-links-2} -- [Yulのドキュメント](https://docs.soliditylang.org/en/latest/yul.html) -- [Yul+のドキュメント](https://github.com/fuellabs/yulp) -- [Yul+の紹介記事](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) +- [Yulドキュメント](https://docs.soliditylang.org/en/latest/yul.html) +- [Yul+ドキュメント](https://github.com/fuellabs/yulp) +- [Yul+紹介記事](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) -### コントラクトのコード例 {#example-contract-2} +### コントラクトの例 {#example-contract-2} -以下の簡単な例では、べき乗関数を実装しています。 `solc --strict-assembly --bin input.yul`を使用してコンパイルすることができます。 この例は、input.yulに記述されます。 +以下の簡単な例では、べき乗関数を実装しています。 `solc --strict-assembly --bin input.yul`を使用してコンパイルできます。 この例は、input.yulに記述されます。 ``` { @@ -251,7 +268,7 @@ def endAuction(): } ``` -スマートコントラクトの経験が豊富な場合は、Yulによる[ERC20の完全な実装](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example)をご覧ください。 +スマートコントラクトに精通している場合、Yulでの完全なERC20実装は[こちら](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example)でご覧いただけます。 ## Fe {#fe} @@ -260,15 +277,15 @@ def endAuction(): - イーサリアムのエコシステムに不慣れなデベロッパーでも簡単に学習できる言語であることを目標としている - Feの開発は未だ初期段階にあり、2021年1月にアルファ版がリリースされた -### 参照すべきリンク {#important-links-3} +### 重要なリンク {#important-links-3} - [GitHub](https://github.com/ethereum/fe) -- [Feに関するアナウンス](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) -- [2021年のFeのロードマップ](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) +- [Feの発表](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) +- [Fe 2021ロードマップ](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) - [FeのDiscordチャット](https://discord.com/invite/ywpkAXFjZH) -- [Twitter](https://twitter.com/official_fe) +- [FeのTwitter](https://twitter.com/official_fe) -### コントラクトのコード例 {#example-contract-3} +### コントラクトの例 {#example-contract-3} Feで実装されたシンプルなコントラクトのコード例を以下に示します。 @@ -291,7 +308,7 @@ contract GuestBook: ``` -## 選択方法 {#how-to-choose} +## 選び方 {#how-to-choose} 他のプログラミング言語と同様に、個人的な好みだけでなく、行いたいことに最適なツールを選択することが重要です。 @@ -299,7 +316,7 @@ contract GuestBook: ### Solidityの長所 {#solidity-advantages} -- 初心者向けに、多くのチュートリアルや学習ツールが用意されている。 詳細については、[コーディングで学ぶ](/developers/learning-tools/)セクションを参照 +- 初心者向けに、多くのチュートリアルや学習ツールが用意されている。 詳細については、[コーディングによる学習](/developers/learning-tools/)のセクションをご覧ください。 - 優れた開発ツールが利用可能 - Solidityには大きなデベロッパーコミュニティがあり、質問に対する答えをすぐに見つけることができる @@ -314,11 +331,11 @@ contract GuestBook: - シンプルで機能的な低レベル言語 - 生のEVMに近づくことができ、コントラクトのガス使用量を最適化するのに役立つ -## 言語比較 {#language-comparisons} +## 言語の比較 {#language-comparisons} -コントラクトのライフサイクル、インターフェイス、演算子、データ構造、関数、制御フローなどの基本的な構文の比較については、 [Auditlessによるチートシート](https://reference.auditless.com/cheatsheet/)を参照してください。 +基本的な構文、コントラクトのライフサイクル、インターフェース、演算子、データ構造、関数、制御フローなどの比較については、この[Auditlessによるチートシート](https://reference.auditless.com/cheatsheet/)をご覧ください。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} - [OpenZeppelinによるSolidityコントラクトライブラリ](https://docs.openzeppelin.com/contracts/5.x/) - [Solidity by Example](https://solidity-by-example.org) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/ja/developers/docs/smart-contracts/libraries/index.md index 11e2e16fcd6..4e246e195d8 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/libraries/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/libraries/index.md @@ -1,26 +1,26 @@ --- -title: スマートコントラクトライブラリ -description: +title: "スマートコントラクトライブラリ" +description: "再利用可能なスマートコントラクトのライブラリやビルディングブロックを見つけて、あなたのイーサリアム開発プロジェクトを加速させましょう。" lang: ja --- プロジェクト内のすべてのスマートコントラクトを一から書く必要はありません。 利用可能なオープンソースのスマートコントラクトライブラリが多数あり、プロジェクトに再利用可能なビルディングブロックが提供されています。これにより、一からやり直す必要がなくなります。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -スマートコントラクトライブラリを使用する前に、スマートコントラクトの構造をよく理解しておくことをお勧めします。 まだ理解していない場合は、[スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)を確認してください。 +スマートコントラクトライブラリを使用する前に、スマートコントラクトの構造をよく理解しておくことをお勧めします。 [スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)をまだご覧になっていない方は、そちらへお進みください。 -## ライブラリの中身 {#whats-in-a-library} +## ライブラリの内容 {#whats-in-a-library} スマートコントラクトライブラリには、通常、2種類のビルディングブロックがあります。コントラクトに追加できる再利用可能な振る舞いと、さまざまな標準の実装です。 -### 振る舞い {#behaviors} +### 動作 {#behaviors} -スマートコントラクトを記述していると、コントラクト内の保護された操作を行うために_管理者_アドレスを割り当てたり、予期せぬ問題が発生した場合に緊急用の_一時停止_ボタンを追加したりと、似たようなパターンを何度も書くことになる可能性があります。 +スマートコントラクトを記述していると、コントラクト内の保護された操作を行うために_admin_アドレスを割り当てたり、予期せぬ問題が発生した場合に緊急用の_pause_ボタンを追加したりと、似たようなパターンを何度も書いていることに気づくことが多いでしょう。 -スマートコントラクトライブラリは通常、Solidityで[ライブラリ](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries)または[継承](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance)を介して、これらの振る舞いを再利用できる実装を提供します。 +スマートコントラクトライブラリは通常、これらの動作の再利用可能な実装を、Solidityの[ライブラリ](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries)として、または[継承](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance)を介して提供します。 -例として、[OpenZeppelinのコントラクトライブラリ](https://github.com/OpenZeppelin/openzeppelin-contracts)の[`Ownable contract`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol)を簡易にしたバージョンを以下に示します。これは、あるアドレスをコントラクトの所有者として指定し、その所有者のみにメソッドへのアクセスを制限するmodifierを提供するコードです。 +例として、以下に[OpenZeppelin Contractsライブラリ](https://github.com/OpenZeppelin/openzeppelin-contracts)の[`Ownable`コントラクト](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol)の簡易版を示します。これは、アドレスをコントラクトの所有者として指定し、その所有者のみにメソッドへのアクセスを制限するための修飾子を提供するものです。 ```solidity contract Ownable { @@ -31,41 +31,41 @@ contract Ownable { } modifier onlyOwner() { - require(owner == msg.sender, "Ownable: caller is not the owner"); + require(owner == msg.sender, "Ownable: 呼び出し元は所有者ではありません"); _; } } ``` -コントラクトでこのようなビルディングブロックを使用するには、最初にインポートしてから自身のコントラクトの中で拡張します。 これにより、元になった`Ownable`コントラクトによって提供される修飾子を使用して、独自の関数を保護することができます。 +コントラクトでこのようなビルディングブロックを使用するには、最初にインポートしてから自身のコントラクトの中で拡張します。 これにより、元になったOwnableコントラクトによって提供される修飾子を使用して、独自の関数を保護することができます。 ```solidity -import ".../Ownable.sol"; // Path to the imported library +import ".../Ownable.sol"; // インポートされたライブラリへのパス contract MyContract is Ownable { - // The following function can only be called by the owner + // 次の関数は所有者のみが呼び出せます function secured() onlyOwner public { msg.sender.transfer(1 ether); } } ``` -もう一つの一般的な例は、[SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math)または[DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html)です。 これらは (ベースコントラクトとは対照的に) 言語で提供されていないオーバーフローチェック付きの算術関数を提供するライブラリです。 ネイティブの算術演算の代わりに、これらのライブラリのいずれかを使用することで、悲惨な結果をもたらすオーバーフローからコントラクトを守ることをお勧めします。 +もう一つの一般的な例は、[SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math)や[DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html)です。 これらは (ベースコントラクトとは対照的に) 言語で提供されていないオーバーフローチェック付きの算術関数を提供するライブラリです。 ネイティブの算術演算の代わりに、これらのライブラリのいずれかを使用することで、悲惨な結果をもたらすオーバーフローからコントラクトを守ることをお勧めします。 ### 標準 {#standards} -[構成可能性と相互運用性](/developers/docs/smart-contracts/composability/)を促進するために、イーサリアムコミュニティは**ERC**の形式でいくつかの標準を定義しました。 詳細については、 [標準](/developers/docs/standards/)セクションを参照してください。 +[構成可能性と相互運用性](/developers/docs/smart-contracts/composability/)を促進するために、イーサリアムコミュニティは**ERCs**の形式でいくつかの標準を定義しています。 それらについての詳細は、[標準](/developers/docs/standards/)セクションで読むことができます。 -ERCをコントラクトの一部として組み込む場合、独自のERCをロールアウトするよりも、標準の実装を探すことをお勧めします。 最も一般的なERCの実装は、多くのスマートコントラクトライブラリに含まれています。 例えば、どこにでもある[ERC20代替可能トークン標準](/developers/tutorials/understand-the-erc-20-token-smart-contract/)は[HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md)、[DappSys](https://github.com/dapphub/ds-token/)と[OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20)で見つかります。 さらに、ERCによってはERC自体の一部として標準実装を提供することもあります。 +ERCをコントラクトの一部として組み込む場合、独自のERCをロールアウトするよりも、標準の実装を探すことをお勧めします。 最も一般的なERCの実装は、多くのスマートコントラクトライブラリに含まれています。 例えば、広く普及している[ERC20代替可能トークン標準](/developers/tutorials/understand-the-erc-20-token-smart-contract/)は、[HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md)、[DappSys](https://github.com/dapphub/ds-token/)、[OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20)にあります。 さらに、ERCによってはERC自体の一部として標準実装を提供することもあります。 -特筆すべきは、一部のERCはスタンドアロンではなく、他のERCに機能を追加するものであるということです。 例えば、 [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) はユーザビリティを向上させるためにERC20に拡張機能を追加します。 +特筆すべきは、一部のERCはスタンドアロンではなく、他のERCに機能を追加するものであるということです。 例えば、[ERC2612](https://eips.ethereum.org/EIPS/eip-2612)は、そのユーザビリティを向上させるためにERC20に拡張機能を追加するものです。 ## ライブラリの追加方法 {#how-to} -プロジェクトにライブラリを含める具体的な手順については、必ずそのライブラリのドキュメントを参照してください。 複数のSolidityコントラクトライブラリは`npm`を使用してパッケージ化されていますので、`npm install`を実行するだけで済みます。 コントラクトを[コンパイル](/developers/docs/smart-contracts/compiling/)するためのほとんどのツールは、`node_modules`でスマートコントラクトライブラリを調べます。そのため、以下のように指定できます。 +プロジェクトにライブラリを含める具体的な手順については、必ずそのライブラリのドキュメントを参照してください。 いくつかのSolidityコントラクトライブラリは`npm`を使用してパッケージ化されているため、`npm install`でインストールするだけです。 コントラクトを[コンパイル](/developers/docs/smart-contracts/compiling/)するためのほとんどのツールは、`node_modules`でスマートコントラクトライブラリを検索しますので、次のようにできます: ```solidity -// This will load the @openzeppelin/contracts library from your node_modules +// これにより、node_modulesから@openzeppelin/contractsライブラリが読み込まれます import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; contract MyNFT is ERC721 { @@ -73,13 +73,13 @@ contract MyNFT is ERC721 { } ``` -使用するメソッドに関係なく、ライブラリを含む場合は[言語](/developers/docs/smart-contracts/languages/)のバージョンを常に気に留めておくようにしてください。 たとえば、Solidity 0.5でコントラクトを書いている場合は、Solidity 0.6のライブラリを使用することはできません。 +使用するメソッドに関わらず、ライブラリを含める際には、常に[言語](/developers/docs/smart-contracts/languages/)のバージョンに注意してください。 たとえば、Solidity 0.5でコントラクトを書いている場合は、Solidity 0.6のライブラリを使用することはできません。 -## ライブラリの利用時 {#when-to-use} +## 使用する場面 {#when-to-use} プロジェクトにスマートコントラクトライブラリを使用すると、いくつかの利点があります。 まず第一に、自分でコーディングしなくても、すぐに利用可能でシステムに含めることができるビルディングブロックが提供されるため、作業時間を短縮できます。 -セキュリティも大きなプラスです。 また、オープンソースのスマートコントラクトライブラリは、頻繁かつ詳細に調査されます。 多くのプロジェクトがそれらのライブラリに依存していることを考えると、コミュニティには継続的な見直しを行おうとする強い動機があります。 再利用可能なコントラクトライブラリ内よりも、アプリケーションコード内の方が、はるかに高い確率でエラーが見つかります。 ライブラリのいくつかは、更なるセキュリティ強化で[外部監査](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits)を受けます。 +セキュリティも大きなプラスです。 また、オープンソースのスマートコントラクトライブラリは、頻繁かつ詳細に調査されます。 多くのプロジェクトがそれらのライブラリに依存していることを考えると、コミュニティには継続的な見直しを行おうとする強い動機があります。 再利用可能なコントラクトライブラリ内よりも、アプリケーションコード内の方が、はるかに高い確率でエラーが見つかります。 ライブラリの中には、セキュリティをさらに強化するために[外部監査](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits)を受けているものもあります。 ただし、スマートコントラクトライブラリを使用すると、馴染みのないコードをプロジェクトに組み込むリスクが生じます。 コントラクトをインポートして直接プロジェクトに組み込みたいと思うかもしれませんが、そのコントラクトが何をするものなのかをよく理解していないと、気付かないうちにシステム内で予期せぬ動作による問題を生じさせてしまう恐れがあります。 必ずインポートするコードのドキュメントを読んで、そのコード自体を確認してからプロジェクトの一部にするようにしてください。 @@ -87,31 +87,31 @@ contract MyNFT is ERC721 { ## 関連ツール {#related-tools} -**OpenZeppelin Contracts -** **_安全なスマートコントラクト開発のための広く普及しているライブラリ。_** +**OpenZeppelin Contracts -** **_安全なスマートコントラクト開発のための最も人気のあるライブラリ。_** - [ドキュメント](https://docs.openzeppelin.com/contracts/) - [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) - [コミュニティフォーラム](https://forum.openzeppelin.com/c/general/16) -**DappSys -** **_スマートコントラクトのための安全でシンプルで柔軟なビルディングブロック。_** +**DappSys -** **_スマートコントラクトのための、安全、シンプル、柔軟なビルディングブロック。_** - [ドキュメント](https://dappsys.readthedocs.io/) - [GitHub](https://github.com/dapphub/dappsys) -**HQ20 - ****_実世界向けの完全な機能を備えた分散アプリケーションの構築を支援する、コントラクト、ライブラリ、サンプルを含むSolidityプロジェクト。_** +**HQ20 -** **_実世界向けの完全な機能を備えた分散アプリケーションの構築を支援する、コントラクト、ライブラリ、サンプルを含むSolidityプロジェクト。_** - [GitHub](https://github.com/HQ20/contracts) -**サードウェブSolidity SDK -** **_カスタムスマートコントラクトを効率的に構築するために必要なツールを提供_** +**thirdweb Solidity SDK -** **_カスタムスマートコントラクトを効率的に構築するために必要なツールを提供します_** - [ドキュメント](https://portal.thirdweb.com/contracts/build/overview) - [GitHub](https://github.com/thirdweb-dev/contracts) -## 関連トピック {#related-tutorials} +## 関連チュートリアル {#related-tutorials} -- [イーサリアムデベロッパーのためのセキュリティに関する考慮事項](/developers/docs/smart-contracts/security/) _- スマートコントラクト構築時のセキュリティに関する考慮事項(ライブラリの使用を含む)_ -- [ERC-20トークンスマートコントラクトを理解する](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- 複数のライブラリで提供されるERC20標準のチュートリアル_ +- [イーサリアム開発者のためのセキュリティに関する考慮事項](/developers/docs/smart-contracts/security/) _– ライブラリの使用を含め、スマートコントラクトを構築する際のセキュリティに関する考慮事項についてのチュートリアル。_ +- [ERC-20トークンスマートコントラクトを理解する](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _-複数のライブラリで提供されている、ERC20標準に関するチュートリアル。_ -## さらに学びたい方へ {#further-reading} +## 参考リンク {#further-reading} -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/smart-contracts/naming/index.md b/public/content/translations/ja/developers/docs/smart-contracts/naming/index.md new file mode 100644 index 00000000000..ae4a47c819e --- /dev/null +++ b/public/content/translations/ja/developers/docs/smart-contracts/naming/index.md @@ -0,0 +1,101 @@ +--- +title: "スマートコントラクトの命名" +description: "ENSを使ったイーサリアムスマートコントラクトの命名に関するベストプラクティス" +lang: ja +--- + +スマートコントラクトはイーサリアムの分散型インフラストラクチャの礎であり、自律的なアプリケーションやプロトコルを可能にします。 しかし、コントラクトの機能が進化しても、ユーザーやデベロッパーは依然として生の16進数アドレスに依存してこれらのコントラクトを識別・参照しています。 + +[Ethereum Name Service (ENS)](https://ens.domains/)でスマートコントラクトに名前を付けることで、16進数のコントラクトアドレスが不要になり、ユーザーエクスペリエンスが向上します。また、アドレス汚染やなりすまし攻撃などの攻撃によるリスクも低減します。 このガイドでは、スマートコントラクトの命名がなぜ重要なのか、どのように実装できるのか、そしてプロセスを簡素化し、デベロッパーがこの慣行を採用するのに役立つ[Enscribe](https://www.enscribe.xyz)のような利用可能なツールについて説明します。 + +## なぜスマートコントラクトに名前を付けるのか？ {#why-name-contracts} + +### 人間が読める識別子 {#human-readable-identifiers} + +デベロッパーとユーザーは、`0x8f8e...f9e3`のような分かりにくいコントラクトアドレスと対話する代わりに、`v2.myapp.eth`のような人間が読める名前を使用できます。 これにより、スマートコントラクトの対話が簡素化されます。 + +これは、イーサリアムアドレスに分散型の命名サービスを提供する[Ethereum Name Service](https://ens.domains/)によって可能になります。 これは、ドメインネームサービス(DNS)によって、インターネットのユーザーが`104.18.176.152`などのIPアドレスではなく、ethereum.orgのような名前を使用してネットワークアドレスにアクセスできるのと似ています。 + +### セキュリティと信頼性の向上 {#improved-security-and-trust} + +名前付きのコントラクトは、間違ったアドレスへの誤ったトランザクションを減らすのに役立ちます。 また、ユーザーが特定のアプリやブランドに関連付けられたコントラクトを特定するのにも役立ちます。 これにより、評判による信頼のレイヤーが追加されます。特に`uniswap.eth`のような有名な親ドメインに名前が付けられている場合にそうなります。 + +イーサリアムアドレスは42文字の長さであるため、数文字が変更された場合にユーザーがアドレスのわずかな変更を識別することは非常に困難です。 例えば、`0x58068646C148E313CB414E85d2Fe89dDc3426870`のようなアドレスは、ウォレットなどのユーザー向けアプリケーションによって、通常`0x580...870`に短縮されて表示されます。 ユーザーは、数文字が変更された悪意のあるアドレスに気づく可能性は低いでしょう。 + +この種の手法は、アドレスのなりすましや汚染攻撃で用いられます。これらの攻撃では、実際には正しいアドレスに似ているだけで同一ではないにもかかわらず、ユーザーは正しいアドレスと対話したり資金を送ったりしていると信じ込まされてしまいます。 + +ウォレットやコントラクトのENS名は、これらのタイプの攻撃から保護します。 DNSのなりすまし攻撃と同様、ENSのなりすまし攻撃も行われる可能性があります。しかし、ユーザーは16進数アドレスのわずかな変更よりも、ENS名のスペルミスに気づく可能性の方が高いでしょう。 + +### ウォレットとエクスプローラーのUX向上 {#better-ux} + +スマートコントラクトにENS名が設定されている場合、ウォレットやブロックチェーンエクスプローラーなどのアプリは、16進数アドレスの代わりにスマートコントラクトのENS名を表示できます。 これはユーザーにとって、ユーザーエクスペリエンス(UX)を大幅に向上させます。 + +例えば、Uniswapのようなアプリと対話する際、ユーザーは通常、対話しているアプリがウェブサイト`uniswap.org`でホストされていることを確認しますが、UniswapがスマートコントラクトにENSで名前を付けていない場合、16進数のコントラクトアドレスが表示されることになります。 コントラクトに名前が付けられていれば、代わりに`v4.contracts.uniswap.eth`と表示され、はるかに便利です。 + +## デプロイ時の命名とデプロイ後の命名 {#when-to-name} + +スマートコントラクトに名前を付けることができる時点は2つあります。 + +- **デプロイ時**: コントラクトがデプロイされる際に、ENS名を割り当てます。 +- **デプロイ後**: 既存のコントラクトアドレスを新しいENS名にマッピングします。 + +どちらのアプローチも、ENSレコードを作成および設定できるように、ENSドメインへの所有者または管理者アクセス権を持っている必要があります。 + +## コントラクトに対するENS命名の仕組み {#how-ens-naming-works} + +ENS名はオンチェーンで保存され、ENSリゾルバを介してイーサリアムアドレスに解決されます。 スマートコントラクトに名前を付けるには、次のようにします。 + +1. 親ENSドメイン(例: `myapp.eth`)を登録または管理する +2. サブドメイン(例: `v1.myapp.eth`)を作成する +3. サブドメインの`address`レコードをコントラクトアドレスに設定する +4. コントラクトの逆引きレコードをENSに設定して、そのアドレスから名前を検索できるようにする + +ENS名は階層的であり、無制限のサブネームをサポートしています。 これらのレコードを設定するには、通常、ENSレジストリおよびパブリックリゾルバコントラクトとの対話が必要です。 + +## コントラクト命名のためのツール {#tools} + +スマートコントラクトに名前を付けるには2つのアプローチがあります。 [ENSアプリ](https://app.ens.domains)をいくつかの手動手順で使用するか、[Enscribe](https://www.enscribe.xyz)を使用します。 これらについて以下に概説します。 + +### 手動でのENS設定 {#manual-ens-setup} + +[ENSアプリ](https://app.ens.domains)を使用すると、デベロッパーは手動でサブネームを作成し、正引きアドレスレコードを設定できます。 しかし、ENSアプリを介して名前の逆引きレコードを設定することによって、スマートコントラクトのプライマリ名を設定することはできません。 [ENSドキュメント](https://docs.ens.domains/web/naming-contracts/)で説明されている手動の手順を実行する必要があります。 + +### Enscribe {#enscribe} + +[Enscribe](https://www.enscribe.xyz)は、ENSによるスマートコントラクトの命名を簡素化し、スマートコントラクトに対するユーザーの信頼を高めます。 次の機能を提供します。 + +- **アトミックなデプロイと命名**: 新しいコントラクトをデプロイする際にENS名を割り当てます +- **デプロイ後の命名**: すでにデプロイ済みのコントラクトに名前を付けます +- **マルチチェーン対応**: ENSがサポートされているイーサリアムおよびL2ネットワークで動作します +- **コントラクト検証データ**: 複数のソースから取得したコントラクト検証データを含み、ユーザーの信頼を高めます + +Enscribeは、ユーザーが提供するENS名、またはユーザーがENS名を持っていない場合は独自のドメインをサポートします。 + +[Enscribeアプリ](https://app.enscribe.xyz)にアクセスして、スマートコントラクトの命名と表示を開始できます。 + +## ベストプラクティス {#best-practices} + +- **明確でバージョン管理された名前を使用する**: `v1.myapp.eth`のような名前を使い、コントラクトのアップグレードを透過的にします +- **逆引きレコードを設定する**: コントラクトをENS名にリンクし、ウォレットやブロックチェーンエクスプローラーなどのアプリで表示されるようにします。 +- **有効期限を注意深く監視する**: 意図しない所有権の変更を防ぎたい場合は、有効期限を注意深く監視します +- **コントラクトのソースを検証する**: ユーザーが、名前の付けられたコントラクトが期待どおりに動作することを信頼できるようにします + +## リスク {#risks} + +スマートコントラクトの命名はイーサリアムのユーザーに大きなメリットをもたらしますが、ENSドメインの所有者はその管理に注意を払う必要があります。 注目すべきリスクは次のとおりです。 + +- **有効期限**: DNS名と同様に、ENS名の登録には有効期間があります。 したがって、所有者はドメインの有効期限を監視し、有効期限が切れるかなり前に更新することが不可欠です。 ENSアプリとEnscribeの両方で、有効期限が近づくとドメイン所有者に視覚的なインジケータが表示されます。 +- **所有権の変更**: ENSレコードはイーサリアム上でNFTとして表され、特定の`.eth`ドメインの所有者は関連するNFTを所有しています。 したがって、別のアカウントがこのNFTの所有権を取得した場合、新しい所有者は、必要に応じて任意のENSレコードを変更できます。 + +このようなリスクを軽減するために、`.eth`の第2レベルドメイン(2LD)の所有者アカウントは、マルチシグウォレットを介して安全に保護し、コントラクトの命名を管理するためのサブドメインを作成する必要があります。 そうすることで、サブドメインレベルで所有権の偶発的または悪意のある変更があった場合でも、2LD所有者が上書きできます。 + +## コントラクト命名の未来 {#future} + +コントラクトの命名は、Web上でドメイン名がIPアドレスに取って代わったのと同様に、dapp開発のベストプラクティスになりつつあります。 ウォレット、エクスプローラー、ダッシュボードなどのインフラストラクチャがコントラクトのENS解決を統合するにつれて、名前付きコントラクトはエコシステム全体の安全性を向上させ、エラーを減らすでしょう。 + +スマートコントラクトを認識しやすく、推論しやすくすることで、命名はイーサリアム上のユーザーとアプリの間のギャップを埋めるのに役立ち、ユーザーの安全性とUXの両方を向上させます。 + +## 参考リンク {#further-reading} + +- [ENSによるスマートコントラクトの命名](https://docs.ens.domains/web/naming-contracts/) +- [Enscribeによるスマートコントラクトの命名](https://www.enscribe.xyz/docs)。 diff --git a/public/content/translations/ja/developers/docs/smart-contracts/security/index.md b/public/content/translations/ja/developers/docs/smart-contracts/security/index.md index e35a7828560..84e92fcff2f 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/security/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/security/index.md @@ -1,6 +1,6 @@ --- -title: スマートコントラクトのセキュリティ -description: 安全なイーサリアムスマートコントラクトを構築するためのガイドラインの概要 +title: "スマートコントラクトのセキュリティ" +description: "安全なイーサリアムスマートコントラクトを構築するためのガイドラインの概要" lang: ja --- @@ -8,47 +8,47 @@ lang: ja イーサリアムのようなパブリックブロックチェーンは、スマートコントラクトのセキュリティ確保の問題をさらに複雑にします。 デプロイされたコントラクトのコードは_通常_、セキュリティ上の欠陥にパッチを当てるために変更することはできません。一方、スマートコントラクトから盗まれた資産は追跡が非常に難しく、その不変性により、大抵回収できません。 -数値は一様ではありませんが、スマートコントラクトのセキュリティ上の欠陥が原因で盗まれたり失われたりした価値の総額は、10億ドルを超えると推定されています。 これには、[The DAOハック](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)(現行価格10億ドル相当以上の360万ETHの盗難)、[パリティ(Parity)マルチシグウォレットハック](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) (ハッカーによる3000万ドルの盗難)、[パリティ(Parity)凍結ウォレット問題](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether)(3億ドル以上のETHを永遠にロック)などの有名な事件も含まれています。 +数値は一様ではありませんが、スマートコントラクトのセキュリティ上の欠陥が原因で盗まれたり失われたりした価値の総額は、10億ドルを超えると推定されています。 これには、[DAOハック](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)(現在の価格で10億ドル以上に相当する360万ETHが盗難)、[Parityマルチシグウォレットハック](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach)(ハッカーにより3,000万ドルが失われる)、[Parityウォレット凍結問題](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether)(3億ドル以上のETHが永久にロックされる)などの注目を集めた事件が含まれます。 前述の問題は、デベロッパーに安全で堅牢な回復力のあるスマートコントラクトの構築に労力を費やすことを不可欠にしました。 スマートコントラクトのセキュリティは深刻な課題であり、全てのデベロッパーが学ぶべきことです。 このガイドでは、イーサリアムデベロッパーのためのセキュリティの考慮事項について説明します。さらに、スマートコントラクトのセキュリティ向上に役立つリソースもご紹介します。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -セキュリティに取り組む前に、[スマートコントラクト開発の基礎](/developers/docs/smart-contracts/)に精通しておいてください。 +セキュリティに取り組む前に、[スマートコントラクト開発の基礎](/developers/docs/smart-contracts/)に精通していることを確認してください。 ## 安全なイーサリアムスマートコントラクトを構築するためのガイドライン {#smart-contract-security-guidelines} -### 1. 適切なアクセス制御設計 {#design-proper-access-controls} +### 1. 適切なアクセス制御の設計 {#design-proper-access-controls} -スマートコントラクトでは、`public`または`external`が記述されている関数は、どの外部所有アカウント (EOA) もしくはコントラクトアカウントからでも呼び出すことができます。 他のコントラクトが自分のコントラクトとやり取りできるようにするには、関数にpublicの可視性を指定する必要があります。 一方で`private`と記述されている関数は、外部アカウントで呼び出すことはできず、スマートコントラクト内の関数でしか呼び出すことはできません。 全てのネットワーク参加者にコントラクト関数へのアクセスを許可してしまうと、特に、細心の注意が求められる操作(例: 新しいトークンのミントなど)を誰でも実行できる場合に、さまざまな問題を引き起こす可能性があります。 +スマートコントラクトでは、`public`または`external`とマークされた関数は、どの外部所有アカウント(EOA)またはコントラクトアカウントからでも呼び出すことができます。 他のコントラクトが自分のコントラクトとやり取りできるようにするには、関数にpublicの可視性を指定する必要があります。 ただし、`private`とマークされた関数は、スマートコントラクト内の関数からのみ呼び出すことができ、外部アカウントからは呼び出せません。 全てのネットワーク参加者にコントラクト関数へのアクセスを許可してしまうと、特に、細心の注意が求められる操作(例: 新しいトークンのミントなど)を誰でも実行できる場合に、さまざまな問題を引き起こす可能性があります。 -スマートコントラクト関数の無許可での使用を防ぐために、安全なアクセス制御の実装が必要です。 アクセス制御メカニズムは、スマートコントラクトの特定の関数を、コントラクトを管理する責任を負うアカウントなどの承認されたエンティティだけが使用できるように制限します。 **Ownableパターン**と**ロールベースアクセス制御**は、スマートコントラクトでアクセス制御を実装する際に有用なパターンです +スマートコントラクト関数の無許可での使用を防ぐために、安全なアクセス制御の実装が必要です。 アクセス制御メカニズムは、スマートコントラクトの特定の関数を、コントラクトを管理する責任を負うアカウントなどの承認されたエンティティだけが使用できるように制限します。 **Ownableパターン**と**ロールベースのアクセス制御**は、スマートコントラクトでアクセス制御を実装するのに役立つ2つのパターンです: #### Ownableパターン {#ownable-pattern} -Ownableパターンでは、コントラクト作成プロセスでアドレスがコントラクトの「オーナー(所有者)」として設定されます。 保護される関数には、`OnlyOwner`修飾子が指定されます。これにより、関数を実行する前にコントラクトが呼び出し元のアドレスのアイデンティティを認証するようになります。 保護された関数に対するコントラクトの所有者以外のアドレスからの呼び出しは、常に取り消されます。これにより、不正なアクセスが防止されます。 +Ownableパターンでは、コントラクト作成プロセスでアドレスがコントラクトの「オーナー(所有者)」として設定されます。 保護された関数には`OnlyOwner`修飾子が割り当てられ、これによりコントラクトは、関数を実行する前に呼び出し元のアドレスのアイデンティティを認証します。 保護された関数に対するコントラクトの所有者以外のアドレスからの呼び出しは、常に取り消されます。これにより、不正なアクセスが防止されます。 -#### ロールベースアクセス制御 {#role-based-access-control} +#### ロールベースのアクセス制御 {#role-based-access-control} -スマートコントラクトに単一のアドレスを`Owner`として登録すると、集中化のリスクをもたらし、単一障害点となります。 所有者のアカウントキーが侵害された場合、攻撃者はその所有者のコントラクトを攻撃できます。 これが、複数の管理アカウントを使用するロールベースアクセス制御パターンを採用した方が良い理由です。 +スマートコントラクトで単一のアドレスを`Owner`として登録すると、中央集権化のリスクが生じ、単一障害点となります。 所有者のアカウントキーが侵害された場合、攻撃者はその所有者のコントラクトを攻撃できます。 これが、複数の管理アカウントを使用するロールベースアクセス制御パターンを採用した方が良い理由です。 ロールベースアクセス制御では、細心の注意が求められる関数へのアクセスは、信頼できる一連の参加者の間で分散されます。 例えば、あるアカウントがトークンをミントする役割を担い、別のアカウントがアップグレードもしくはコントラクトの一時停止を実行する役割を担います。 このようにアクセス制御を分散化することで、単一障害点を取り除き、ユーザーの信頼の前提を減らします。 ##### マルチシグウォレットの使用 -安全なアクセス制御を実装するもう一つのアプローチとして、[マルチシグ(複数署名)アカウント](/developers/docs/smart-contracts/#multisig)でコントラクトを管理することもできます。 通常のEOAと異なり、マルチシグアカウントは複数のエンティティに所有されます。また、トランザクションの実行には最低数のアカウントの署名 (例: 5つのうち3つの署名など) が必要です。 +安全なアクセス制御を実装するためのもう1つのアプローチは、[マルチシグ(複数署名)アカウント](/developers/docs/smart-contracts/#multisig)を使用してコントラクトを管理することです。 通常のEOAと異なり、マルチシグアカウントは複数のエンティティに所有されます。また、トランザクションの実行には最低数のアカウントの署名 (例: 5つのうち3つの署名など) が必要です。 アクセス制御でマルチシグ (複数署名) を使用すると、追加のセキュリティレイヤーを導入できます。なぜなら、目的のコントラクトを動作させるには複数の当事者からの同意が必要になるためです。 これはOwnableパターンを使う必要がある場合に特に有用です。これにより、攻撃者や不正な内部関係者が、細心の注意が求められるコントラクト関数を悪意のある目的で操作することをより困難にするためです。 -### 2. コントラクト操作の保護にrequire()、assert()、revert() ステートメントを使用 {#use-require-assert-revert} +### 2. `require()`、`assert()`、`revert()`ステートメントを使用してコントラクト操作を保護する {#use-require-assert-revert} -前述のように、スマートコントラクトをいったんブロックチェーンにデプロイすると、誰でもその中のpublic関数を呼び出すことができます。 外部アカウントがどのようにコントラクトとやり取りするかを事前に知ることはできないため、デプロイする前に、問題のある操作に対して内部的な防御策を講じることが理想的です。 実行する際、特定の要件を満たさない場合は、`require()`、`assert()`、および`revert()`ステートメントを使用して例外をトリガーし、状態変更を元に戻すことにより、スマートコントラクトで正しい動作を強制できます。 +前述のように、スマートコントラクトをいったんブロックチェーンにデプロイすると、誰でもその中のpublic関数を呼び出すことができます。 外部アカウントがどのようにコントラクトとやり取りするかを事前に知ることはできないため、デプロイする前に、問題のある操作に対して内部的な防御策を講じることが理想的です。 実行が特定の要件を満たさない場合、`require()`、`assert()`、および`revert()`ステートメントを使用して例外を発生させ、状態変更を元に戻すことで、スマートコントラクトで正しい動作を強制することができます。 -**`require()`**: `require`は、関数の開始時に定義され、呼び出された関数が実行される前に、事前に定義された条件を確実に満たすようにします。 `require`ステートメントは、ユーザーの入力の検証、状態変数のチェック、または関数を実行する前に呼び出し元のアカウントのアイデンティティを認証するために使用することができます。 +**`require()`**: `require`は関数の冒頭で定義され、呼び出された関数が実行される前に所定の条件が満たされていることを保証します。 `require`ステートメントは、関数の処理を進める前に、ユーザー入力の検証、状態変数のチェック、呼び出し元アカウントのアイデンティティ認証に使用することができます。 -**`assert()`**: `assert()`は、内部エラーの検出や、コード内の「不変条件」の違反をチェックするために使用されます。 不変条件とは、コントラクトの状態に関する論理アサーションであり、すべての関数の実行に対して真 (true) となるべきものです。 不変条件の例としては、トークンコントラクトの最大供給量や残高があげられます。 `assert()` を使用することで、コントラクトが脆弱な状態にならないようにします。もしそうなった場合は、状態変数へのすべての変更がロールバックされます。 +**`assert()`**: `assert()`は、内部エラーの検出や、コード内の「不変条件」違反のチェックに使用されます。 不変条件とは、コントラクトの状態に関する論理アサーションであり、すべての関数の実行に対して真 (true) となるべきものです。 不変条件の例としては、トークンコントラクトの最大供給量や残高があげられます。 `assert()`を使用することで、コントラクトが脆弱な状態になることを防ぎ、万が一脆弱な状態になった場合は、状態変数へのすべての変更がロールバックされます。 -**`revert()`**: `revert()` if-else文の中で使用することができ、必要な条件を満たさない場合に例外を発生させます。 以下のサンプルコントラクトでは、`revert()`によって関数の実行を保護しています。 +**`revert()`**: `revert()`はif-else文で使用でき、必要な条件が満たされない場合に例外をトリガーします。 以下のサンプルコントラクトは、`revert()`を使用して関数の実行を保護しています: ``` pragma solidity ^0.8.4; @@ -58,7 +58,7 @@ contract VendingMachine { error Unauthorized(); function buy(uint amount) public payable { if (amount > msg.value / 2 ether) - revert("Not enough Ether provided."); + revert("提供されたイーサが不足しています。"); // Perform the purchase. } function withdraw() public { @@ -70,19 +70,19 @@ contract VendingMachine { } ``` -### 3. スマートコントラクトのテストとコードの正確性の検証 {#test-smart-contracts-and-verify-code-correctness} +### 3. スマートコントラクトのテストとコードの正しさの検証 {#test-smart-contracts-and-verify-code-correctness} [イーサリアム仮想マシン](/developers/docs/evm/)で実行されるコードの不変性は、スマートコントラクトの開発段階において、より高いレベルの品質評価が要求されることを意味しています。 コントラクトを広範にテストし、予期しない結果を観察することでセキュリティは大幅に向上し、長期的にはユーザーを保護することができます。 -通常の方法としては、小さな単体テストを作成します。これには、コントラクトがユーザーから受け取ることが予想されるモックデータを使います。 [単体テスト](/developers/docs/smart-contracts/testing/#unit-testing)は、特定の関数の機能をテストしたり、スマートコントラクトが期待通りに動作することを確認したりするのに適しています。 +通常の方法としては、小さな単体テストを作成します。これには、コントラクトがユーザーから受け取ることが予想されるモックデータを使います。 [単体テスト](/developers/docs/smart-contracts/testing/#unit-testing)は、特定の関数の機能をテストし、スマートコントラクトが期待どおりに動作することを確認するのに適しています。 残念ながら、単体テストを単独で行った場合は、スマートコントラクトのセキュリティを向上させるのに最小限の効果しかありません。 単体テストは、関数がモックデータに対して正しく実行されていることを証明するかもしれませんが、作成されたテストに対してのみ有効であるにすぎません。 これは、見落としたエッジケースや脆弱性の検出を難しくするので、スマートコントラクトの安全性を損なう可能性があります。 -より良い方法としては、単体テストと[静的・動的解析](/developers/docs/smart-contracts/testing/#static-dynamic-analysis)を用いて実施するプロパティベースのテストを組み合わせることです。 静的解析は、[制御フローグラフ](https://en.wikipedia.org/wiki/Control-flow_graph)や[抽象構文木](https://deepsource.io/glossary/ast/)といった低レベルな表現を頼りに到達可能なプログラムの状態や実行経路を解析します。 一方、[スマートコントラクトファジング](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)などの動的解析手法は、ランダムな入力値でコントラクトコードを実行し、セキュリティプロパティに違反する操作を検出します。 +より良いアプローチは、単体テストと[静的および動的分析](/developers/docs/smart-contracts/testing/#static-dynamic-analysis)を使用して実行されるプロパティベースのテストを組み合わせることです。 静的分析は、[制御フローグラフ](https://en.wikipedia.org/wiki/Control-flow_graph)や[抽象構文木](https://deepsource.io/glossary/ast/)などの低レベルの表現に依存して、到達可能なプログラムの状態と実行パスを分析します。 一方、[スマートコントラクトファジング](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)などの動的分析技術は、ランダムな入力値でコントラクトコードを実行し、セキュリティプロパティに違反する操作を検出します。 -[形式検証](/developers/docs/smart-contracts/formal-verification)は、スマートコントラクトのセキュリティプロパティを検証するためのもう一つの手法です。 通常のテストとは異なり、形式検証はスマートコントラクトにエラーがないことを決定的に証明することができます。 これは、望ましいセキュリティプロパティをとらえた形式仕様記述を作成し、コントラクトの形式的モデルがこの仕様に準拠していることを証明することで実現されます。 +[形式検証](/developers/docs/smart-contracts/formal-verification)は、スマートコントラクトのセキュリティプロパティを検証するためのもう1つの手法です。 通常のテストとは異なり、形式検証はスマートコントラクトにエラーがないことを決定的に証明することができます。 これは、望ましいセキュリティプロパティをとらえた形式仕様記述を作成し、コントラクトの形式的モデルがこの仕様に準拠していることを証明することで実現されます。 -### 4. 第三者コードレビューの依頼 {#get-independent-code-reviews} +### 4. コードの独立したレビューを依頼する {#get-independent-code-reviews} コントラクトのテスト後、セキュリティ上の問題がないか、他者にソースコードの確認を依頼する方法もあります。 テストによってスマートコントラクトのすべての欠陥を発見できるわけではありませんが、第三者によるレビューを受けることで、脆弱性を発見できる可能性が高まります。 @@ -99,11 +99,11 @@ contract VendingMachine { バグ報奨金プログラムを設けることは、外部コードレビューを実施するためのもう一つのアプローチです。 バク報奨金とは、アプリケーション内の脆弱性を発見した個人 (通常はホワイトハットハッカー) に与えられる金銭的な報酬です。 -バグ報奨金プログラムが適切に機能すれば、ハッカーコミュニティのメンバーは重大な欠陥がないかコードを検査することでインセンティブを得ることができます。 実例としては、「無限貨幣バグ」があります。このバグにより、イーサリアム上で動作している[オプティミズム](https://www.optimism.io/)という[レイヤー2プロトコル](/layer-2/)で、攻撃者が無限にイーサ(Ether)を発行できてしまうというものでした。 幸運なことに、ホワイトハットハッカーは[その欠陥](https://www.saurik.com/optimism.html)を発見しチームに通知したため、[その過程で多額の報酬を得ました](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/)。 +バグ報奨金プログラムが適切に機能すれば、ハッカーコミュニティのメンバーは重大な欠陥がないかコードを検査することでインセンティブを得ることができます。 実例としては、攻撃者がイーサリアム上で実行される[レイヤー2](/layer-2/)プロトコルである[Optimism](https://www.optimism.io/)上で無制限の量のイーサを作成できてしまう「無限マネーバグ」があります。 幸いなことに、ホワイトハットハッカーが[その欠陥を発見し](https://www.saurik.com/optimism.html)、チームに通知したことで、[その過程で多額の報酬を得ました](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/) -バグ報奨金プログラムの報酬額を、危機にさらされている資金の額に比例して設定すると、有効な戦略となります。 「[バグ報奨金スケール](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)」と呼ばれるこのアプローチは、脆弱性を悪用するのではなく、責任をもって開示するように、個人に金銭的なインセンティブを与えるものです。 +バグ報奨金プログラムの報酬額を、危機にさらされている資金の額に比例して設定すると、有効な戦略となります。 「[スケーリングバグ報奨金](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)」と説明されるこのアプローチは、個人が脆弱性を悪用するのではなく、責任を持って開示するための金銭的なインセンティブを提供します。 -### 5. スマートコントラクト開発の最善の方法への準拠 {#follow-smart-contract-development-best-practices} +### 5. スマートコントラクト開発におけるベストプラクティスに従う {#follow-smart-contract-development-best-practices} 監査やバグ報奨金の制度があるからといって、高品質なコードを書くという責任がなくなるわけではありません。 優れたスマートコントラクトセキュリティは、次の適切な設計と開発プロセスに従うことから始まります。 @@ -113,15 +113,15 @@ contract VendingMachine { - プルリクエストでは、少なくとも1人の第三者レビュアーを確保する。プロジェクトを1人で進めている場合は、他のデベロッパーを見つけて互いのコードをレビューすることを検討する -- スマートコントラクトのテスト、コンパイル、デプロイに[開発環境](/developers/docs/frameworks/)を使用する +- スマートコントラクトのテスト、コンパイル、デプロイには[開発環境](/developers/docs/frameworks/)を使用する -- [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn)、Mythril、Slitherなど、基本的なコード解析ツールを使用してコードを実行する。 これは、各プルリクエストがマージされる前に実行し、出力の違いを比較しておくのが理想的である +- [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn)、Mythril、Slitherなどの基本的なコード分析ツールでコードを実行する。 これは、各プルリクエストがマージされる前に実行し、出力の違いを比較しておくのが理想的である - コードがエラーなくコンパイルされ、Solidityコンパイラが警告を発していないことを確認する -- [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)を使用してコードを適切に文書化し、コントラクトのアーキテクチャの詳細を理解しやすい言葉で記述する。 これにより、第三者によるコードの監査やレビューが容易になる +- ([NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)を使用して)コードを適切に文書化し、コントラクトのアーキテクチャに関する詳細をわかりやすい言葉で説明する。 これにより、第三者によるコードの監査やレビューが容易になる -### 6. 堅牢な災害復旧計画の実装 {#implement-disaster-recovery-plans} +### 6. 堅牢なディザスタリカバリ計画を実装する {#implement-disaster-recovery-plans} 安全なアクセス制御の設計、関数修飾子の実装、その他の提案等は、スマートコントラクトのセキュリティを向上させる可能性はありますが、悪意のある攻撃が行われる可能性を完全に排除することはできません。 安全なスマートコントラクトを構築するには、「失敗に備える」ことと攻撃に効果的に対応するための予備計画を持つことが必要になります。 適切な災害復旧計画には、次の構成要素のうち一部またはすべてが組み込まれます。 @@ -129,13 +129,13 @@ contract VendingMachine { イーサリアムスマートコントラクトは、デフォルトではイミュータブル (不変) ですが、アップグレードパターンを用いることで可変性をある程度獲得することが可能です。 コントラクトのアップグレードは、重大な欠陥によって古いコントラクトが使用できなくなり、新しいロジックをデプロイすることが最も現実的な選択肢となる場合に必要になります。 -コントラクトのアップグレードのメカニズムは様々ですが、「プロキシパターン」はスマートコントラクトのアップグレードでより一般的なアプローチの一つです。 [プロキシパターン](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern)は、アプリケーションを「状態」と「ロジック」の_2つの_コントラクトに分割します。 最初のコントラクト (「プロキシコントラクト」と呼ばれる) は、状態変数 (例: ユーザーの残高など) を格納します。一方、2つ目のコントラクトは (「ロジックコントラクト」と呼ばれる) は、コントラクトの関数を実行するためのコードを保持します。 +コントラクトのアップグレードのメカニズムは様々ですが、「プロキシパターン」はスマートコントラクトのアップグレードでより一般的なアプローチの一つです。 [プロキシパターン](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern)は、アプリケーションの状態とロジックを_2つ_のコントラクトに分割します。 最初のコントラクト (「プロキシコントラクト」と呼ばれる) は、状態変数 (例: ユーザーの残高など) を格納します。一方、2つ目のコントラクトは (「ロジックコントラクト」と呼ばれる) は、コントラクトの関数を実行するためのコードを保持します。 -アカウントは、プロキシコントラクトとやり取りを行います。プロキシコントラクトは、すべての関数の呼び出しを低レベル呼び出しである[`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries)を使ってロジックコントラクトへディスパッチします。 通常のメッセージ呼び出しとは異なり、`delegatecall()`は、 ロジックコントラクトのアドレスで実行されるコードが、呼び出し元コントラクトのコンテキスト内で実行されるようにします。 つまり、ロジックコントラクトは、ロジックのストレージではなく、常にプロキシのストレージに書き込みを行い、元の`msg.sender`や`msg.value`の値は保持されるということです。 +アカウントはプロキシコントラクトと対話し、プロキシコントラクトは[`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries)の低レベル呼び出しを使用して、すべての関数呼び出しをロジックコントラクトにディスパッチします。 通常のメッセージ呼び出しとは異なり、`delegatecall()`はロジックコントラクトのアドレスで実行されるコードが、呼び出し元のコントラクトのコンテキストで実行されることを保証します。 これは、ロジックコントラクトが(自身のストレージではなく)常にプロキシのストレージに書き込み、`msg.sender`と`msg.value`の元の値が保持されることを意味します。 ロジックコントラクトに呼び出しを委任するには、プロキシコントラクトのストレージにロジックコントラクトのアドレスを格納する必要があります。 したがって、コントラクトのロジックをアップグレードするには、別のロジックコントラクトをデプロイし、プロキシコントラクトに新しいロジックコントラクトのアドレスを格納するだけでよいのです。 プロキシコントラクトに対するその後の呼び出しは、自動的に新しいロジックコントラクトにルーティングされるため、実際にコードを修正することなく、コントラクトを「アップグレード」したことになります。 -[コントラクトのアップグレードの詳細](/developers/docs/smart-contracts/upgrading/) +[コントラクトのアップグレードに関する詳細](/developers/docs/smart-contracts/upgrading/) #### 緊急停止 {#emergency-stops} @@ -143,16 +143,16 @@ contract VendingMachine { 最終手段は、コントラクト内の脆弱な関数の呼び出しをブロックする「緊急停止」関数を実装することです。 通常、緊急停止は以下のコンポーネントで構成されています。 -1. スマートコントラクトが停止状態かどうかを示す、グローバルなブール型変数。 この変数は、コントラクトを設定するときに`false`に設定されますが、コントラクトが停止すると`true`に戻ります。 +1. スマートコントラクトが停止状態かどうかを示す、グローバルなブール型変数。 この変数は、コントラクトのセットアップ時には`false`に設定されますが、コントラクトが停止されると`true`に戻ります。 2. 実行時に上記ブール型変数を参照する関数。 これらの関数には、スマートコントラクトが停止していない場合はアクセスでき、緊急停止機能がトリガーされるとアクセスできなくなります。 -3. 上記ブール型変数を`true`に設定する緊急停止関数へのアクセス権を持つエンティティ。 悪意のある行為を防ぐために、この関数への呼び出しを信頼できるアドレス (例: コントラクトの所有者など) に制限できます。 +3. 緊急停止関数にアクセスできるエンティティ。この関数は、ブール値変数を`true`に設定します。 悪意のある行為を防ぐために、この関数への呼び出しを信頼できるアドレス (例: コントラクトの所有者など) に制限できます。 -コントラクトが緊急停止を作動させると、特定の関数は呼び出せなくなります。 これは、グローバル変数を参照するmodifierを使って、選択対象の関数をラップすることで実現されます。 下記は、コントラクトへのこのパターンの実装を記述した[例](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol)です。 +コントラクトが緊急停止を作動させると、特定の関数は呼び出せなくなります。 これは、グローバル変数を参照するmodifierを使って、選択対象の関数をラップすることで実現されます。 以下は、このパターンをコントラクトで実装した[例](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol)です: ```solidity -// このコードは、専門的な監査を受けておらず、安全性や正確性を約束するものではありません。 自己責任で利用してくだささい。 +// このコードは専門家による監査を受けておらず、安全性や正確性について何の約束もするものではありません。ご自身の責任でご使用ください。 contract EmergencyStop { @@ -193,15 +193,15 @@ contract EmergencyStop { この例では、緊急停止の基本機能を示しています。 -- `isStopped`はブール値で、最初は評価が`false`になっており、コントラクトが緊急モードに入ると、評価が`true`になります。 +- `isStopped`はブール値で、最初は`false`、コントラクトが緊急モードに入ると`true`と評価されます。 -- 関数修飾子 (modifier)である、`onlyWhenStopped`および `stoppedInEmergency`は、`isStopped`変数をチェックします。 `stoppedInEmergency`は、コントラクトが脆弱な場合にアクセスできないようにする必要がある関数の制御に使用されます(例: `deposit()`など) 。 これらの関数への呼び出しは取り消されます。 +- 関数修飾子 (modifier)である、`onlyWhenStopped`および `stoppedInEmergency`は、`isStopped`変数をチェックします。 `stoppedInEmergency`は、コントラクトが脆弱な場合にアクセスできないようにする必要がある関数の制御に使用されます(例: `deposit()`)。 これらの関数への呼び出しは取り消されます。 `onlyWhenStopped`は、緊急時に呼び出し可能でなければならない関数に使用されます(例: `emergencyWithdraw()`) 。 このような関数は事態の解決に役立つため、「制限されている関数」のリストから除外されます。 緊急停止機能を使用すると、スマートコントラクトの深刻な脆弱性に対処する際に効果的な応急処置を施すことができます。 しかし、デベロッパーが利己的な理由で起動しないように、ユーザーがデベロッパーを信頼する必要性が高まります。 これに対し、オンチェーン投票メカニズムを採用したり、タイムロック、マルチシグウォレットからの承認など、さまざまな方法で緊急停止を分散管理することが解決策として考えられます。 -#### イベント監視 {#event-monitoring} +#### イベントの監視 {#event-monitoring} [イベント](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events)で、スマートコントラクト関数への呼び出しを追跡し、状態変数の変更を監視できます。 ある当事者が、セーフティクリティカルな行為(例: 資金の引き出しなど)を行うたびに、イベントを発行するようにスマートコントラクトをプログラムするのが理想的です。 @@ -215,30 +215,30 @@ contract EmergencyStop { 分散型ガバナンスは、特にデベロッパーとエンドユーザーの利害が一致することもあり、有益なものになり得ます。 それでもなお、スマートコントラクトのガバナンスメカニズムは、誤って実装された場合に新しいリスクをもたらすことがあります。 起こり得るシナリオは、攻撃者が[フラッシュローン](/defi/#flash-loans)を利用して膨大な投票力(保有トークン数で測定)を獲得し、悪意のある提案を押し通すというものです。 -オンチェーンガバナンスに関連する問題を防ぐ方法の一つとして、[タイムロックの使用](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/)が挙げられます。 タイムロックは、特定の時間が経過するまでスマートコントラクトが特定のアクションを実行できないようにするものです。 その他の戦略としては、各トークンがロックされている期間に応じて「投票の重み」を割り当てることや、現在のブロックの代わりに過去の期間 (例: 2～3ブロック前) でアドレスの投票力を測定することなどがあります。 どちらの方法も、オンチェーンの投票を思い通りに動かす投票力を短期間で獲得する可能性を減らすことができます。 +オンチェーンガバナンスに関連する問題を回避する方法の1つは、[タイムロックを使用する](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/)ことです。 タイムロックは、特定の時間が経過するまでスマートコントラクトが特定のアクションを実行できないようにするものです。 その他の戦略としては、各トークンがロックされている期間に応じて「投票の重み」を割り当てることや、現在のブロックの代わりに過去の期間 (例: 2～3ブロック前) でアドレスの投票力を測定することなどがあります。 どちらの方法も、オンチェーンの投票を思い通りに動かす投票力を短期間で獲得する可能性を減らすことができます。 -[安全なガバナンスシステムの設計](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)、[DAOのさまざまな投票メカニズム](https://hackernoon.com/governance-is-the-holy-grail-for-daos)、[DeFiを悪用した一般的なDAOの攻撃ベクトル](https://dacian.me/dao-governance-defi-attacks)の詳細については、共有のリンクをご覧ください。 +共有リンクでは、[安全なガバナンスシステムの設計](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)、[DAOにおけるさまざまな投票メカニズム](https://hackernoon.com/governance-is-the-holy-grail-for-daos)、[DeFiを活用した一般的なDAOの攻撃ベクトル](https://dacian.me/dao-governance-defi-attacks)について詳しく説明しています。 -### 8. コードの複雑さの最小化 {#reduce-code-complexity} +### 8. コードの複雑さを最小限に抑える {#reduce-code-complexity} 従来のソフトウェアデベロッパーは、ソフトウェア設計に不必要な複雑さを持ち込まないようにするというKISS (Keep It Simple, Stupid) 原則に慣れ親しんでいます。 これは、「複雑なシステムには複雑な障害が発生する」、さらに複雑さによりコストのかかるエラーが発生しやすいという長年の考え方に従ったものです。 -スマートコントラクトが高額の価値を制御する可能性があることを考えると、シンプルさを保ってスマートコントラクトを記述することが特に重要になります。 スマートコントラクトをシンプルに記述するコツは、可能な限り[OpenZeppelinコントラクト](https://docs.openzeppelin.com/contracts/5.x/)のような既存のライブラリを再利用することです。 これらのライブラリは、デベロッパーによって広範な監査とテストが行われているため、新しい機能をゼロから書くことでバグを発生させる可能性を減らすことができます。 +スマートコントラクトが高額の価値を制御する可能性があることを考えると、シンプルさを保ってスマートコントラクトを記述することが特に重要になります。 スマートコントラクトを記述する際にシンプルさを実現するためのヒントは、可能な限り[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)などの既存のライブラリを再利用することです。 これらのライブラリは、デベロッパーによって広範な監査とテストが行われているため、新しい機能をゼロから書くことでバグを発生させる可能性を減らすことができます。 別の一般的なアドバイスとしては、小さな関数を記述すること、さらにビジネスロジックを複数のコントラクトに分割してコントラクトをモジュラー型にすることがあります。 よりシンプルなコードを書くことで、スマートコントラクトへの攻撃面を減らすだけでなく、システム全体の正確性を推論しやすくなり、設計エラーの可能性を早期に検出できるようになります。 -### 9. 一般的なスマートコントラクトの脆弱性からの保護 {#mitigate-common-smart-contract-vulnerabilities} +### 9. 一般的なスマートコントラクトの脆弱性に対する防御 {#mitigate-common-smart-contract-vulnerabilities} -#### 再入可能 (リエントランシー) {#reentrancy} +#### 再入可能攻撃(リエントランシー) {#reentrancy} EVMは同時実行を許可していません。つまり、メッセージ呼び出しに関わる2つのコントラクトは同時に実行できません。 外部呼び出しは、呼び出しが戻るまで呼び出し元のコントラクトの実行とメモリを一時停止させます。その時点で外部呼び出しの実行が正常に進みます。 このプロセスは、別のコントラクトへの[制御フロー](https://www.computerhope.com/jargon/c/contflow.htm)の移動として形式的に記述することが可能です。 ほとんど場合問題は発生しませんが、信頼できないコントラクトに制御フローを移した場合には、再入可能(リエントランシー)などの問題を引き起こす可能性があります。 元の関数の呼び出しが完了する前に、悪意のあるコントラクトが再び脆弱なコントラクトを呼び出す場合に、再入可能(リエントランシー)攻撃が発生します。 例とともに、このタイプの攻撃を詳しく説明します。 -誰でもイーサ (Ether) を入出金できるシンプルなスマートコントラクト (「Victim」) を考えてみましょう。 +誰でもイーサ (ether) を入出金できるシンプルなスマートコントラクト (「Victim」) を考えてみましょう。 ```solidity -// このコントラクトには、脆弱性があります。 プロダクションでは使用しないでください。 +// このコントラクトには脆弱性があります。本番環境では使用しないでください。 contract Victim { mapping (address => uint256) public balances; @@ -262,9 +262,9 @@ contract Victim { 2. 呼び出し元のアドレスへ資金を送金します。 3. 残高を0にリセットし、ユーザーからの追加の引き出しを防止します。 -`Victim`コントラクトの`withdraw()`関数は、「checks-interactions-effects」パターンに従っています。 実行に必要な条件 (つまり、ユーザーのETH残高がプラスになっているか) が満たされているかどうかを_確認 (checks) _し、呼び出し元のアドレスにETHを送金するという_相互作用 (interactions) _を行った後、トランザクションの_結果 (effects) _ (つまり、ユーザーの残高を減らす) を適用しているのです。 +`Victim`コントラクトの`withdraw()`関数は、「checks-interactions-effects」パターンに従っています。 実行に必要な条件(つまり、ユーザーのETH残高がプラスになっているか)が満たされているかどうかを_チェックし_、呼び出し元のアドレスにETHを送金するという_相互作用_を行った後、トランザクションの_結果_(つまり、ユーザーの残高を減らす)を適用しています。 -`withdraw()`が外部所有口座 (EOA) から呼び出された場合、この関数は期待どおりに実行されます。つまり、`msg.sender.call.value()`は呼び出し元にETHを送金します。 しかし、`msg.sender`が`withdraw()`を呼び出すスマートコントラクトアカウントの場合、`msg.sender.call.value()`を使用して資金を送金すると、そのアドレスに保存されているコードの実行もトリガーすることになります。 +`withdraw()`が外部所有口座(EOA)から呼び出された場合、この関数は期待どおりに実行されます。つまり、`msg.sender.call.value()`は呼び出し元にETHを送金します。 しかし、`msg.sender`が`withdraw()`を呼び出すスマートコントラクトアカウントの場合、`msg.sender.call.value()`を使用して資金を送金すると、そのアドレスに保存されているコードの実行もトリガーすることになります。 以下がそのコントラクトアドレスにデプロイされているコードだと想像してみてください。 @@ -289,7 +289,7 @@ contract Victim { 2. Victimコントラクトへ1 ETHを入金します。 3. スマートコントラクトに格納された1 ETHを引き出します。 -`Attacker`には、入力となる`msg.sender.call.value`からの残りのガスが4万以上なら`Victim`内の`withdraw()`を再度呼び出すもう一つの関数があることを除き問題はありません。 これにより、`Attacker`は`Victim`に再入可能になり、最初の`withdraw`の呼び出しが完了する前に、多くの資金を引き出すことができます。 次のようなサイクルになります。 +`Attacker`には、入力となる`msg.sender.call.value`からの残りのガスが4万以上なら`Victim`内の`withdraw()`を再度呼び出すもう一つの関数があることを除き問題はありません。 これにより、`Attacker`は`Victim`に再入可能になり、`withdraw`の最初の呼び出しが完了する_前_に、より多くの資金を引き出すことができます。 次のようなサイクルになります。 ```solidity - 攻撃者のEOAが、1 ETHで「Attacker.beginAttack()」関数を呼び出します。 @@ -304,11 +304,11 @@ contract Victim { - 「Victim」は、最終的に最初のトランザクション(および後続のトランザクション)の結果をステート(状態)に適用するので、「Attacker」の残高は0に設定されます。 ``` -要約すると、関数の実行が完了するまで呼び出し元の残高が0にならないため、その後の呼び出しが成功し、呼び出し元が何度も残高を引き出せるようになります。 この種の攻撃は、[2016年のDAOハック](https://www.coindesk.com/learn/understanding-the-dao-attack)で行われたように、スマートコントラクトから資金を流出させるために使用されます。 [再入可能(リエントランシー)エクスプロイトの公開リスト](https://github.com/pcaversaccio/reentrancy-attacks)が示すように、再入可能攻撃は今日でもスマートコントラクトにとって深刻な問題になっています。 +要約すると、関数の実行が完了するまで呼び出し元の残高が0にならないため、その後の呼び出しが成功し、呼び出し元が何度も残高を引き出せるようになります。 この種の攻撃は、[2016年のDAOハック](https://www.coindesk.com/learn/understanding-the-dao-attack)で起きたように、スマートコントラクトから資金を流出させるために使用される可能性があります。 [再入可能(リエントランシー)エクスプロイトの公開リスト](https://github.com/pcaversaccio/reentrancy-attacks)が示すように、再入可能攻撃は今日でもスマートコントラクトにとって深刻な問題になっています。 ##### 再入可能 (リエントランシー) 攻撃を防ぐ方法 -再入可能に対処するアプローチとして、[checks-effects-interactionsパターン](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern)に従うことが挙げられます。 このパターンは、次のように関数の実行を順序付けるものです。最初に、実行を進める前に必要な確認を行うコードが来ます。次に、コントラクトの状態を操作するコードが来ます。最後に、他のコントラクトやEOAとやり取りをするコードが来ます。 +再入可能攻撃に対処するアプローチとして、[checks-effects-interactionsパターン](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern)に従う方法があります。 このパターンは、次のように関数の実行を順序付けるものです。最初に、実行を進める前に必要な確認を行うコードが来ます。次に、コントラクトの状態を操作するコードが来ます。最後に、他のコントラクトやEOAとやり取りをするコードが来ます。 checks-effect-interactionパターンは、以下に示している`Victim`コントラクトの改訂版で使用しています。 @@ -323,9 +323,9 @@ contract NoLongerAVictim { } ``` -このコントラクトは、ユーザーの残高を_確認 (check)_ し、`withdraw()`関数の_結果 (effects) _を (ユーザーの残高を0にすることで) 適用し、_相互作用 (interaction) _ (ユーザーのアドレスにETHを送金) の実行へと進みます。 これにより、外部呼び出しの前に、コントラクトがストレージを確実にアップデートするようになり、最初の攻撃を可能にする再入可能の条件が排除されます。 `Attacker`コントラクトは依然として、`NoLongerAVictim`を再び呼び出すことができますが、`balances[msg.sender]`が0にセットされているので、さらなる引き出しをしてもエラーがスローされます。 +このコントラクトは、ユーザーの残高を_確認し_、`withdraw()`関数の_結果_を(ユーザーの残高を0にすることで)適用し、_相互作用_(ユーザーのアドレスにETHを送金)の実行へと進みます。 これにより、外部呼び出しの前に、コントラクトがストレージを確実にアップデートするようになり、最初の攻撃を可能にする再入可能の条件が排除されます。 `Attacker`コントラクトは依然として、`NoLongerAVictim`を再び呼び出すことができますが、`balances[msg.sender]`が0にセットされているので、さらなる引き出しをしてもエラーがスローされます。 -もう一つのオプションは、関数の呼び出しが完了するまで、コントラクトの状態の一部をロックする相互排他ロック (一般的に「ミューテックス」と呼ばれる) を使用することです。 これは、ブール型変数を使って実装されます。関数が実行される前に`true`に設定し、呼び出しが完了した後に`false`に戻します。 以下の例で見られるように、元の呼び出しがまだ処理中であっても、ミューテックスを使うことで再帰的な呼び出しから関数を守ることができます。これにより、効果的に再入可能を防ぐことができます。 +もう一つのオプションは、関数の呼び出しが完了するまで、コントラクトの状態の一部をロックする相互排他ロック (一般的に「ミューテックス」と呼ばれる) を使用することです。 これは、ブール値変数を使って実装されます。関数が実行される前に`true`に設定し、呼び出しが完了した後に`false`に戻します。 以下の例で見られるように、元の呼び出しがまだ処理中であっても、ミューテックスを使うことで再帰的な呼び出しから関数を守ることができます。これにより、効果的に再入可能を防ぐことができます。 ```solidity pragma solidity ^0.7.0; @@ -341,12 +341,12 @@ contract MutexPattern { locked = false; } // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again. - // `return`ステートメントは、`true`と評価しますが、まだmodifierのステートメントでは`locked = false`と評価します。 + // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier function withdraw(uint _amount) public payable noReentrancy returns(bool) { require(balances[msg.sender] >= _amount, "No balance to withdraw."); balances[msg.sender] -= _amount; - bool (success, ) = msg.sender.call{value: _amount}(""); + (bool success, ) = msg.sender.call{value: _amount}(""); require(success); return true; @@ -354,30 +354,30 @@ contract MutexPattern { } ``` -また、アカウントに資金を送る「プッシュ型決済」システムではなく、ユーザーがスマートコントラクトから資金を引き出す必要がある[「プル型決済」](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment)システムを利用することでも防止可能です。 これにより、不明なアドレスで不注意にコードをトリガーする可能性を取り除けます (特定のDoS攻撃も防げます) 。 +アカウントに資金を送る「プッシュ型決済」システムではなく、ユーザーがスマートコントラクトから資金を引き出す必要がある「[プル型決済](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment)」システムを利用することもできます。 これにより、不明なアドレスで不注意にコードをトリガーする可能性を取り除けます (特定のDoS攻撃も防げます) 。 -#### 整数のアンダーフローとオーバーフロー {#integer-underflows-and-overflows} +#### 整数アンダーフローとオーバーフロー {#integer-underflows-and-overflows} -算術演算の結果が許容値の範囲外になると、整数のオーバーフローが発生します。これにより、表現可能な最小値に「ロールオーバー」します。 例えば、`uint8`は、2^8-1=255までの値だけを格納できます。 `255`を超える値の算術演算の結果はオーバーフローし、`uint`を`0`にリセットします。これは、車のオドメーターが最大走行距離 (999999) に達すると0にリセットされるのと同じです。 +算術演算の結果が許容値の範囲外になると、整数のオーバーフローが発生します。これにより、表現可能な最小値に「ロールオーバー」します。 例えば、`uint8`は、2^8-1=255までの値だけを格納できます。 255を超える値の算術演算の結果はオーバーフローし、`uint`を`0`にリセットします。これは、車のオドメーターが最大走行距離(999999)に達すると0にリセットされるのと同じです。 -整数のアンダーフローも同様の理由で発生します。それは算術演算の結果が許容値の範囲を下回った場合です。 例えば、`uint8`で`0`をデクリメントしようと試みると、結果は単純に表現可能な最大値 (`255`) にロールオーバーします。 +整数のアンダーフローも同様の理由で発生します。それは算術演算の結果が許容値の範囲を下回った場合です。 例えば、`uint8`で0をデクリメントしようと試みると、結果は単純に表現可能な最大値(`255`)にロールオーバーします。 整数のオーバーフローとアンダーフローのどちらも、コントラクトの状態変数に予期せぬ変更をもたらし、予定外の実行につながる可能性があります。 以下は、攻撃者がスマートコントラクトの算術オーバーフローを悪用して、不正な操作を行う方法を示した例です。 ``` pragma solidity ^0.7.6; -// このコントラクトはタイムボールトとして動作するように設計されています。 -// ユーザーは、このコントラクトへ入金できますが、最低一週間は引き出しができません。 -// ユーザーは、一週間よりも長い待機期間になるように待ち時間を延長することもできます。 +// このコントラクトは、タイムボールトとして機能するように設計されています。 +// ユーザーはこのコントラクトに入金できますが、少なくとも1週間は引き出しできません。 +// ユーザーは、1週間の待機期間を超えて待機時間を延長することもできます。 /* -1. TimeLockをデプロイします -2. TimeLockのアドレスでAttackをデプロイします -3. Attack.attackを呼び出し、1 ETHを送金します 即座にETHが引き出せるようになります。 +1. TimeLockをデプロイ +2. TimeLockのアドレスでAttackをデプロイ +3. 1イーサを送信してAttack.attackを呼び出します。すぐにイーサを引き出すことができます。 -何が起きたのでしょうか？ -AttackがTimeLock.lockTimeのオーバーフローを引き起こしたため、設定された一週間の待機期間より前に引き出しが可能になりました。 +何が起きたか？ +AttackによってTimeLock.lockTimeがオーバーフローし、1週間の待機期間前に引き出すことができました。 */ contract TimeLock { @@ -394,14 +394,14 @@ contract TimeLock { } function withdraw() public { - require(balances[msg.sender] > 0, "Insufficient funds"); - require(block.timestamp > lockTime[msg.sender], "Lock time not expired"); + require(balances[msg.sender] > 0, "資金が不足しています"); + require(block.timestamp > lockTime[msg.sender], "ロック期間が満了していません"); uint amount = balances[msg.sender]; balances[msg.sender] = 0; (bool sent, ) = msg.sender.call{value: amount}(""); - require(sent, "Failed to send Ether"); + require(sent, "イーサの送信に失敗しました"); } } @@ -433,11 +433,11 @@ contract Attack { ##### 整数のアンダーフローとオーバーフローを防ぐ方法 -バージョン0.8.0以降のSolidityコンパイラは、整数のアンダーフローとオーバーフローを引き起こすコードを拒否します。 しかし、それよりも低いバージョンのコンパイラでコンパイルされたコントラクトでは、算術演算を実行する関数でチェックを行うか、アンダーフローとオーバーフローをチェックするライブラリ (例: [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) を使用する必要があります。 +バージョン0.8.0以降のSolidityコンパイラは、整数のアンダーフローとオーバーフローを引き起こすコードを拒否します。 しかし、より低いコンパイラバージョンでコンパイルされたコントラクトは、算術演算を含む関数でチェックを実行するか、アンダーフロー/オーバーフローをチェックするライブラリ(例: [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math))を使用する必要があります。 -#### オラクル(Oracle)の改ざん {#oracle-manipulation} +#### オラクルの改ざん {#oracle-manipulation} -[オラクル(Oracles)](/developers/docs/oracles/)は、オフチェーン情報を取得し、スマートコントラクトが使用できるようにオンチェーンに送信します。 オラクルを使用すると、資本市場などのオフチェーンシステムと相互運用するスマートコントラクトを設計して、アプリケーションを大幅に拡張できます。 +[オラクル](/developers/docs/oracles/)は、オフチェーン情報を取得し、スマートコントラクトが使用できるようにオンチェーンに送信します。 オラクルを使用すると、資本市場などのオフチェーンシステムと相互運用するスマートコントラクトを設計して、アプリケーションを大幅に拡張できます。 しかし、オラクルに間違いが含まれており、誤った情報をオンチェーンに送信した場合、スマートコントラクトが誤った入力に基づいて実行され、問題が発生する可能性があります。 これが「オラクルの問題」の根拠であり、ブロックチェーンのオラクルからの情報を確実に正確かつ最新で、タイムリーなものにするということが重要になってきます。 @@ -449,17 +449,17 @@ DEXの価格は正確であることが多く、これは市場の均衡を取 ##### オラクルの改ざんを防ぐ方法 -[オラクルの改ざん](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples)を回避するための最小要件としては、単一障害点を避けるために複数のソースから情報を照会する分散型オラクルネットワークを使用することです。 ほとんどの場合、分散型オラクルにはオラクルノードに正しい情報を報告するよう促す暗号経済的なインセンティブが組み込まれており、集中型オラクルよりも安全性が高くなっています。 +[オラクルの改ざんを回避する](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples)ための最小要件としては、単一障害点を避けるために複数のソースから情報を照会する分散型オラクルネットワークを使用することです。 ほとんどの場合、分散型オラクルにはオラクルノードに正しい情報を報告するよう促す暗号経済的なインセンティブが組み込まれており、集中型オラクルよりも安全性が高くなっています。 オンチェーンオラクルに資産価格を照会する場合は、時間加重平均価格(TWAP)メカニズムを実装しているものを使用することを検討してください。 [TWAPオラクル](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles)は、ある資産の価格を2つの異なる時点(修正可能)で照会し、得られた平均値に基づいて現在価格を計算します。 長い期間を選択することで、直前に行われた大量の注文が資産価格に影響を与えることができないため、価格の不正操作からプロトコルを保護します。 -## デペロッパー向けスマートコントラクト・セキュリティリソース {#smart-contract-security-resources-for-developers} +## デベロッパー向けのスマートコントラクトセキュリティリソース {#smart-contract-security-resources-for-developers} ### スマートコントラクト分析とコードの正確性検証ツール {#code-analysis-tools} - **[テストツールとライブラリ](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _スマートコントラクトの単体テスト、静的解析、動的解析を行うための業界標準ツールやライブラリのコレクション。_ -- **[形式検証ツール](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _スマートコントラクトの機能的な正しさを検証し、不変条件をチェックするためのツール。_ +- **[形式検証ツール](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _スマートコントラクトの機能の正しさを検証し、不変条件をチェックするためのツール。_ - **[スマートコントラクト監査サービス](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _イーサリアム開発プロジェクト向けのスマートコントラクト監査サービスを提供する企業のリスト。_ @@ -469,21 +469,21 @@ DEXの価格は正確であることが多く、これは市場の均衡を取 - **[ABI Encoder](https://abi.hashex.org/)** - _Solidityコントラクトの関数とコンストラクタの引数をエンコードするための無料のオンラインサービス。_ -- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _Solidity静的アナライザーです。抽象構文木 (AST) を横断し、疑わしい脆弱性を正確に特定し、問題を扱いやすいマークダウン形式で出力します。_ +- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _Solidity静的アナライザーです。抽象構文木(AST)を横断し、疑わしい脆弱性を正確に特定し、問題を扱いやすいマークダウン形式で出力します。_ ### スマートコントラクト監視ツール {#smart-contract-monitoring-tools} -- **[Tenderlyリアルタイムアラート](https://tenderly.co/alerting/)** - _スマートコントラクトやウォレットに異常なイベントや予期せぬイベントが発生した場合に、通知をリアルタイムに受けとるためのツール。_ +- **[Tenderly Real-Time Alerting](https://tenderly.co/monitoring)** - _スマートコントラクトやウォレットに異常なイベントや予期せぬイベントが発生した場合に、通知をリアルタイムに受けとるためのツール。_ -### スマートコントラクトのセキュリティ管理ツール {#smart-contract-administration-tools} +### スマートコントラクトの安全な管理ツール {#smart-contract-administration-tools} - **[Safe](https://safe.global/)** - _イーサリアム上で動作し、トランザクションが発生する前に最低人数(N人中のM人)の承認が必要なスマートコントラクトウォレット。_ -- **[OpenZeppelinコントラクト](https://docs.openzeppelin.com/contracts/5.x/)** - _コントラクトの所有権、アップグレード、アクセス制御、ガバナンス、一時停止機能など、管理機能を実装するためのコントラクトライブラリ。_ +- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _コントラクトの所有権、アップグレード、アクセス制御、ガバナンス、一時停止機能など、管理機能を実装するためのコントラクトライブラリ。_ ### スマートコントラクト監査サービス {#smart-contract-auditing-services} -- **[ConsenSys Diligence](https://consensys.net/diligence/)** - _ブロックチェーンエコシステム全体のプロジェクトについて、プロトコルがローンチに適した状態にあり、ユーザーを保護するように構築されていることを確認するスマートコントラクト監査サービス。_ +- **[ConsenSys Diligence](https://diligence.consensys.io/)** - _ブロックチェーンエコシステム全体のプロジェクトについて、プロトコルがローンチに適した状態にあり、ユーザーを保護するように構築されていることを確認するスマートコントラクト監査サービス。_ - **[CertiK](https://www.certik.com/)** - _スマートコントラクトとブロックチェーンネットワークに最先端の形式検証技術を使用する先駆的なブロックチェーンセキュリティ企業_ @@ -495,80 +495,80 @@ DEXの価格は正確であることが多く、これは市場の均衡を取 - **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _分散型システムのセキュリティ監査を提供するスマートコントラクトセキュリティ企業。_ -- **[Runtime Verification](https://runtimeverification.com/)** - _スマートコントラクトと形式モデルを専門としたセキュリティ企業。_ +- **[Runtime Verification](https://runtimeverification.com/)** - _スマートコントラクトの形式モデリングと検証を専門とするセキュリティ企業。_ -- **[Hacken](https://hacken.io)** - _ブロックチェーンセキュリティへの360度アプローチをもたらすサイバーセキュリティ監査人。_ +- **[Hacken](https://hacken.io)** - _ブロックチェーンセキュリティへの360度アプローチをもたらすWeb3サイバーセキュリティ監査人。_ -- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** - _ SolidityとCairoの監査サービスにより、イーサリアムとStarknet全体でスマートコントラクトの整合性とユーザーの安全を確保。_ +- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** - _SolidityとCairoの監査サービスにより、イーサリアムとStarknet全体でスマートコントラクトの整合性とユーザーの安全を確保。_ -- **[HashEx](https://hashex.org/)** - _HashExは、ブロックチェーンとスマート コントラクトの監査に焦点を当てており、暗号通貨のセキュリティを確保するためのスマートコントラクト開発、侵入テスト、ブロックチェーンコンサルティングなどのサービスを提供。_ +- **[HashEx](https://hashex.org/)** - _HashExは、ブロックチェーンとスマートコントラクトの監査に焦点を当てており、暗号通貨のセキュリティを確保するためのスマートコントラクト開発、侵入テスト、ブロックチェーンコンサルティングなどのサービスを提供。_ - **[Code4rena](https://code4rena.com/)** - _スマートコントラクトセキュリティの専門家へ脆弱性の発見にインセンティブを与え、web3をより安全にすることを支援する競争的な監査プラットフォーム。_ - **[CodeHawks](https://codehawks.com/)** - _優位性のある監査プラットフォームで、セキュリティリサーチャーのスマートコントラクト監査コンペを主催している。_ -- **[Cyfrin](https://cyfrin.io)** - _Web3セキュリティの有力企業であり、製品やスマート コントラクト監査サービスを通じて暗号セキュリティを推進している。_ +- **[Cyfrin](https://cyfrin.io)** - _製品とスマートコントラクト監査サービスを通じて暗号セキュリティをインキュベートする、Web3セキュリティの有力企業。_ -- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _Web3セキュリティファームで、経験豊富な監査人と最高クラスのツールを通じてブロックチェーンシステムのセキュリティ監査を提供している。_ +- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _経験豊富な監査人とクラス最高のツールからなるチームを通じて、ブロックチェーンシステムにセキュリティ監査を提供するWeb3セキュリティファーム。_ -- **[Oxorio](https://oxor.io/)** - _クリプト会社およびDeFiプロジェクト向けのEVM、Solidity、ゼロ知識、クロスチェーン技術を専門としたスマートコントラクト監査およびブロックチェーンセキュリティサービス。_ +- **[Oxorio](https://oxor.io/)** - _暗号資産会社およびDeFiプロジェクト向けのEVM、Solidity、ZK、クロスチェーン技術を専門としたスマートコントラクト監査およびブロックチェーンセキュリティサービス。_ - **[Inference](https://inference.ag/)** - _EVMベースのブロックチェーンのスマートコントラクト監査に特化したセキュリティ監査会社。 専門的な監査人が、潜在的な問題を特定し、実行可能なソリューションを提案してデプロイ前に修正することが可能。_ -### バグ報奨プログラムプラットフォーム {#bug-bounty-platforms} +### バグ報奨金プラットフォーム {#bug-bounty-platforms} - **[Immunefi](https://immunefi.com/)** - _スマートコントラクトとDeFiプロジェクトのバグ報奨プログラムのプラットフォーム。セキュリティ研究者がコードをレビューし、脆弱性を開示し、報酬を得て、暗号資産の安全性を強化。_ - **[HackerOne](https://www.hackerone.com/)** - _企業とペネトレーションテスターやサイバーセキュリティ研究者をつなぐ、脆弱性調整とバグ報奨プログラムのプラットフォーム_ -- **[HackenProof](https://hackenproof.com/)** - _ 暗号プロジェクト(DeFi、スマート コントラクト、ウォレット、CEXなど)のエキスパートのバグ報奨金プラットフォーム。セキュリティプロフェッショナルはトリアージサービスを提供し、研究者は検証済みの関連バグレポートに対して報酬を獲得。_ +- **[HackenProof](https://hackenproof.com/)** - _暗号プロジェクト(DeFi、スマートコントラクト、ウォレット、CEXなど)のエキスパートのバグ報奨金プラットフォーム。セキュリティプロフェッショナルはトリアージサービスを提供し、研究者は検証済みの関連バグレポートに対して報酬を獲得。_ -- **[Sherlock](https://www.sherlock.xyz/)** - _スマートコントラクトセキュリティのためのWeb3の引受人。監査人への支払いはスマートコントラクトを介して管理され、バグの関連性に応じて公平に支払われることを保証。_ +- **[Sherlock](https://www.sherlock.xyz/)** - _スマートコントラクトセキュリティのためのWeb3の引受人。監査人への支払いはスマートコントラクトを介して管理され、バグの関連性に応じて公平に支払われることを保証。_ -- **[CodeHawks](https://www.codehawks.com/)** - _競争力のあるバグ報奨金プラットフォームで、監査人がセキュリティコンテストやチャレンジに参加できる。また、独自のプライベート監査も（間もなく）開催する予定。_ +- **[CodeHawks](https://www.codehawks.com/)** - _競争力のあるバグ報奨金プラットフォームで、監査人がセキュリティコンテストやチャレンジに参加できる。また、独自のプライベート監査も（間もなく）開催する予定。_ -### 既知のスマートコントラクトの脆弱性とエクスプロイトの公開 {#common-smart-contract-vulnerabilities-and-exploits} +### スマートコントラクトの既知の脆弱性・悪用事例の公開情報 {#common-smart-contract-vulnerabilities-and-exploits} - **[ConsenSys: スマートコントラクトの既知の攻撃](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _コントラクトの最も重要な脆弱性を、ほとんどのケースでサンプルコード付きで初心者にもわかりやすく解説。_ -- **[SWCレジストリ](https://swcregistry.io/)** - _イーサリアムスマートコントラクトに該当する共通の脆弱性(CWE)項目の厳選リスト。_ +- **[SWCレジストリ](https://swcregistry.io/)** - _イーサリアムスマートコントラクトに該当する共通脆弱性タイプ一覧(CWE)項目の厳選リスト。_ - **[Rekt](https://rekt.news/)** - _注目の暗号ハッキングやエクスプロイトを、詳細な事後分析レポートとともに定期的に更新して公開。_ -### スマートコントラクトのセキュリティ学習課題 {#challenges-for-learning-smart-contract-security} +### スマートコントラクトのセキュリティを学ぶための課題 {#challenges-for-learning-smart-contract-security} -- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _ブロックチェーンセキュリティの机上演習、課題、[Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/)コンペやソリューション記事の厳選リスト。_ +- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _ブロックチェーンセキュリティのウォーゲーム、チャレンジ、[キャプチャー・ザ・フラッグ](https://www.webopedia.com/definitions/ctf-event/amp/)コンペティション、およびソリューションのライトアップの厳選リスト。_ - **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _DeFiスマートコントラクトの攻撃的なセキュリティを学び、バグハンティングやセキュリティ監査のスキルを身につけるための机上演習。_ -- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _各レベルでスマートコントラクトのハッキングが必要なWeb3/Solidityベースの机上演習_ +- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _各レベルでスマートコントラクトの「ハッキング」が必要なWeb3/Solidityベースのウォーゲーム_ - **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _ファンタジーアドベンチャーを舞台にしたスマートコントラクトハッキングチャレンジ。 チャレンジに成功すれば、非公開のバグ報奨金プログラムにアクセスできる。_ -### スマートコントラクトのセキュリティのベストプラクティス {#smart-contract-security-best-practices} +### スマートコントラクトを保護するためのベストプラクティス {#smart-contract-security-best-practices} - **[ConsenSys: イーサリアムスマートコントラクトのセキュリティのベストプラクティス](https://consensys.github.io/smart-contract-best-practices/)** - _イーサリアムスマートコントラクトのセキュリティのガイドラインの包括的リスト。_ - **[Nascent: シンプルセキュリティツールキット](https://github.com/nascentxyz/simple-security-toolkit)** - _スマートコントラクト開発のための、セキュリティを重視した実践的なガイドとチェックリスト集。_ -- **[Solidityパターン](https://fravoll.github.io/solidity-patterns/)** - _スマート コントラクトプログラミング言語「Solidity」の安全なパターンとベストプラクティスの有用情報のまとめ。_ +- **[Solidityパターン](https://fravoll.github.io/solidity-patterns/)** - _スマートコントラクトプログラミング言語「Solidity」の安全なパターンとベストプラクティスの有用情報のまとめ。_ -- **[Solidityドキュメント: セキュリティ考慮事項](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _Solidityで安全なスマートコントラクトを記述するためのガイドライン。_ +- **[Solidity Docs: セキュリティに関する考慮事項](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _Solidityで安全なスマートコントラクトを記述するためのガイドライン。_ - **[スマートコントラクトセキュリティ検証スタンダード](https://github.com/securing/SCSVS)** - _デベロッパー、アーキテクト、セキュリティ評価者、ベンダー向けにスマートコントラクトのセキュリティを標準化するために作成された14部構成のチェックリスト。_ -- **[スマートコントラクトセキュリティと監査の学習](https://updraft.cyfrin.io/courses/security) - _究極のスマート コントラクトセキュリティと監査コース。セキュリティのベストプラクティスのレベルアップおよびセキュリティ研究者になりたいと考えているスマートコントラクトデベロッパー向け。_ +- **[スマートコントラクトのセキュリティと監査について学ぶ](https://updraft.cyfrin.io/courses/security)** - _究極のスマートコントラクトのセキュリティと監査コース。セキュリティのベストプラクティスをレベルアップさせ、セキュリティ研究者になることを目指すスマートコントラクト開発者向けに作成されました。_ -### スマートコントラクトのセキュリティに関するチュートリアル {#tutorials-on-smart-contract-security} +### スマートコントラクトセキュリティに関するチュートリアル {#tutorials-on-smart-contract-security} -- [安全なスマートコントラクトコードの記述方法](/developers/tutorials/secure-development-workflow/) +- [安全なスマートコントラクトの書き方](/developers/tutorials/secure-development-workflow/) -- [Slitherを使用してスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [Slither を使ってスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) -- [Manticoreを使用してスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [Manticore を使ってスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) -- [スマートコントラクトのセキュリティガイドライン](/developers/tutorials/smart-contract-security-guidelines/) +- [スマートコントラクトセキュリティガイドライン](/developers/tutorials/smart-contract-security-guidelines/) -- [トークンコントラクトと任意のトークンを安全に統合する方法](/developers/tutorials/token-integration-checklist/) +- [トークンコントラクトを任意のトークンと安全に統合する方法](/developers/tutorials/token-integration-checklist/) - [Cyfrin Updraft - スマートコントラクトセキュリティおよび監査のフルコース](https://updraft.cyfrin.io/courses/security) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/testing/index.md b/public/content/translations/ja/developers/docs/smart-contracts/testing/index.md index 38d5f3c8674..cbeaaec6017 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/testing/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/testing/index.md @@ -1,38 +1,38 @@ --- -title: スマートコントラクトのテスト -description: イーサリアムスマートコントラクトのテスト方法と考察の概要 +title: "スマートコントラクトのテスト" +description: "イーサリアムスマートコントラクトのテスト方法と考察の概要" lang: ja --- -イーサリアムなどのパブリックブロックチェーンは不変で、一度デプロイされたスマートコントラクトのコードを変更するのは困難です。 「バーチャルアップデート」を実行するための[スマートコントラクトアップグレードのパターン](/developers/docs/smart-contracts/upgrading/)が存在するものの、実装は困難で、かつ社会的コンセンサスも必要です。 さらに、アップグレードは、発見された_後に_エラーを修正できるものにすぎません。攻撃者が先に脆弱性を発見した場合、スマートコントラクトは悪用される可能性があります。 +イーサリアムなどのパブリックブロックチェーンは不変で、一度デプロイされたスマートコントラクトのコードを変更するのは困難です。 「仮想アップグレード」を実行するための[コントラクトアップグレードのパターン](/developers/docs/smart-contracts/upgrading/)は存在しますが、これらは実装が難しく、社会的なコンセンサスが必要です。 さらに、アップグレードは、発見された後にエラーを修正できるものにすぎません。攻撃者が先に脆弱性を発見した場合、スマートコントラクトは悪用される可能性があります。 -これらの理由から、メインネットに[デプロイする](/developers/docs/smart-contracts/deploying/)前にスマートコントラクトをテストすることは、 [セキュリティ](/developers/docs/smart-contracts/security/)の最小要件です。 テストでは、さまざまな技術を活用してコードの正確性を評価しますが、必要な機能や目的に合わせて選択しなければなりません。 それでも、さまざまなツールとアプローチを組み合わせたテストスイートを使えば、スマートコントラクトコード深刻度にかかわらず、セキュリティ欠陥を見つけることができます。 +これらの理由から、スマートコントラクトをメインネットに[デプロイ](/developers/docs/smart-contracts/deploying/)する前にテストすることは、[セキュリティ](/developers/docs/smart-contracts/security/)上の最低要件です。 テストでは、さまざまな技術を活用してコードの正確性を評価しますが、必要な機能や目的に合わせて選択しなければなりません。 それでも、さまざまなツールとアプローチを組み合わせたテストスイートを使えば、スマートコントラクトコード深刻度にかかわらず、セキュリティ欠陥を見つけることができます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページでは、イーサリアムネットワークにデプロイする前に、スマートコントラクトをテストする方法について説明します。 [スマートコントラクト](/developers/docs/smart-contracts/)の知識があることを前提としています。 +このページでは、イーサリアムネットワークにデプロイする前に、スマートコントラクトをテストする方法について説明します。 [スマートコントラクト](/developers/docs/smart-contracts/)に精通していることを前提としています。 ## スマートコントラクトのテストとは {#what-is-smart-contract-testing} スマートコントラクトのテストとは、スマートコントラクトのコードが意図したとおりに動作することを検証するプロセスです。 テストによって、スマートコントラクトの信頼性、使いやすさ、セキュリティ要件を満たしているかどうかを確認することができます。 -テストにはさまざまなアプローチがありますが、一般的には、処理することが予想されるデータの小さなサンプルを用いてスマートコントラクトを実行する必要があります。 コントラクトがサンプルデータに対して正しい結果を生成する場合、コントラクトは適切に機能していると判断できます。 テストツールのほとんどは、コントラクトの実行が期待通りであるかどうかを検証するための[テストケース](https://en.m.wikipedia.org/wiki/Test_case)を作成したり実行したりするためのリソースを提供しています。 +テストにはさまざまなアプローチがありますが、一般的には、処理することが予想されるデータの小さなサンプルを用いてスマートコントラクトを実行する必要があります。 コントラクトがサンプルデータに対して正しい結果を生成する場合、コントラクトは適切に機能していると判断できます。 ほとんどのテストツールは、コントラクトの実行が期待される結果と一致するかどうかをチェックするための[テストケース](https://en.m.wikipedia.org/wiki/Test_case)を作成および実行するためのリソースを提供します。 -### スマートコントラクトのテストの重要性 {#importance-of-testing-smart-contracts} +### スマートコントラクトのテストの重要性 スマートコントラクトをテストする重要性 {#importance-of-testing-smart-contracts} -スマートコントラクトでは、高価値の金融資産を管理することが多いため、小さなプログラミングの間違いが[ユーザーに大損失](https://rekt.news/leaderboard/)を与える可能性があります。実際に、そのような事例は度々発生しています。 ただし、厳密なテストを行うことで、スマートコントラクトのコードの欠陥と問題点を早期に発見し、メインネットにリリースする前に修正することができます。 +スマートコントラクトは高価値の金融資産を管理することが多いため、ささいなプログラミングエラーが[ユーザーへの莫大な損失](https://rekt.news/leaderboard/)につながる可能性があり、実際にそうなることもよくあります。 ただし、厳密なテストを行うことで、スマートコントラクトのコードの欠陥と問題点を早期に発見し、メインネットにリリースする前に修正することができます。 -バグが発見された場合、コントラクトをアップグレードすることは可能ですが、アップグレードは複雑で、誤った処理をすると[エラー](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)が発生する可能性があります。 また、アップグレードによって、コントラクトの不変性の原則が損なわれ、ユーザーにさらなる信頼が求められることになります。 一方で、統合的なテスト計画を立てることで、スマートコントラクトのセキュリティリスクを軽減し、デプロイ後に複雑なロジックのアップグレードを実行する必要性を減らすことができます。 +バグが発見された場合にコントラクトをアップグレードすることは可能ですが、アップグレードは複雑であり、不適切に処理されると[エラーが発生する](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)可能性があります。 また、アップグレードによって、コントラクトの不変性の原則が損なわれ、ユーザーにさらなる信頼が求められることになります。 一方で、統合的なテスト計画を立てることで、スマートコントラクトのセキュリティリスクを軽減し、デプロイ後に複雑なロジックのアップグレードを実行する必要性を減らすことができます。 ## スマートコントラクトのテスト方法 {#methods-for-testing-smart-contracts} -イーサリアムのスマートコントラクトのテスト方法は、大きく分けて**自動テスト**と**手動テスト**の2つがあります。 自動テストと手動テストには、それぞれに長所と短所があります。両方を組み合わせることで、コントラクトを解析するための堅牢な計画を立てることができます。 +イーサリアムのスマートコントラクトのテスト方法は、**自動テスト**と**手動テスト**の2つの大きなカテゴリーに分類されます。 自動テストと手動テストには、それぞれに長所と短所があります。両方を組み合わせることで、コントラクトを解析するための堅牢な計画を立てることができます。 ### 自動テスト {#automated-testing} -自動テストでは、スマートコントラクトのコードを実行して、エラーがないか自動的にチェックするツールを使用します。 自動テストの利点は、[スクリプト](https://www.techtarget.com/whatis/definition/script?amp=1)を使用してコントラクトの機能を評価できることです。 スクリプト化されたテストは、人間の介入を最小限に抑え、繰り返し実行するようにスケジュールできるので、手動によるテストよりも効率的です。 +自動テストでは、スマートコントラクトのコードを実行して、エラーがないか自動的にチェックするツールを使用します。 自動テストの利点は、[スクリプト](https://www.techtarget.com/whatis/definition/script?amp=1)を使用してコントラクトの機能を評価できる点にあります。 スクリプト化されたテストは、人間の介入を最小限に抑え、繰り返し実行するようにスケジュールできるので、手動によるテストよりも効率的です。 -自動テストは、テストが反復的で時間がかかる、手動で実行するのが難しい、人的ミスの影響を受けやすい、重要なコントラクト関数の評価を伴う、などの場合に特に役立ちます。 ただし、自動テストツールには、欠点もあります。例えば、特定のバグを検出できなかったり、多くの[誤検知](https://www.contrastsecurity.com/glossary/false-positive)をしてしまうことがあります。 そのため、スマートコントラクトのテストには、自動テストと手動テストを組み合わせることが望ましいと言えます。 +自動テストは、テストが反復的で時間がかかる、手動で実行するのが難しい、人的ミスの影響を受けやすい、重要なコントラクト関数の評価を伴う、などの場合に特に役立ちます。 しかし、自動テストツールには欠点もあります。特定のバグを見逃したり、多くの[偽陽性](https://www.contrastsecurity.com/glossary/false-positive)を生成したりする可能性があります。 そのため、スマートコントラクトのテストには、自動テストと手動テストを組み合わせることが望ましいと言えます。 ### 手動テスト {#manual-testing} @@ -50,13 +50,13 @@ lang: ja 単体テストは、期待する値が返されるかどうかと、関数の実行後にコントラクトのストレージが適切に更新されるかどうかを確認するのに効果的です。 また、コントラクトのコードベースに変更を加えた後に単体テストを実行し、新しいロジックの追加によってエラーが発生しないことを確認します。 以下は、効果的な単体テストを実行するためのガイドラインです。 -#### スマートコントラクト単体テストのガイドライン {#unit-testing-guidelines} +#### スマートコントラクトの単体テストのガイドライン {#unit-testing-guidelines} ##### 1. コントラクトのビジネスロジックとワークフローを理解する -スマートコントラクトが提供する機能を理解し、ユーザーがどのように関数にアクセスして使用しているかを把握しておくと、単体テストを作成しやすくなります。 [ハッピーパステスト](https://en.m.wikipedia.org/wiki/Happy_path)を実行する場合に特に有用です。これは、 コントラクト内の関数が有効なユーザーの入力に対して正しい出力を返すかどうかを判断します。 [オークションコントラクト](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)の(要約された)例を用いて、このコンセプトを説明します。 +スマートコントラクトが提供する機能を理解し、ユーザーがどのように関数にアクセスして使用しているかを把握しておくと、単体テストを作成しやすくなります。 これは、コントラクト内の関数が有効なユーザー入力に対して正しい出力を返すかどうかを判断する[ハッピーパステスト](https://en.m.wikipedia.org/wiki/Happy_path)を実行するのに特に便利です。 この概念を、[オークションコントラクト](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)のこの（要約された）例を使って説明します。 -``` +```solidity constructor( uint biddingTime, address payable beneficiaryAddress @@ -126,11 +126,11 @@ function auctionEnd() external { - 落札に失敗したユーザーの資金が確実に戻ること。 -**注**: 前提をテストする別の方法としては、特に`require`、`assert`、`if…else`ステートメントなど、コントラクト内の[関数修飾子](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers)をトリガーするテストを作成することです。 +**注**: 前提条件をテストするもう一つの方法は、コントラクト内の[関数修飾子](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers)をトリガーするテスト、特に`require`、`assert`、`if…else`文を記述することです。 ##### 3. コードカバレッジを計測する -[コードカバレッジ](https://en.m.wikipedia.org/wiki/Code_coverage)は、テストで実行されたコード内の分岐、行、ステートメントの数を追跡する指標です。 テストには、適切なコードカバレッジが必要です。コードカバレッジが不十分だと、「偽陰性」を引き起こす可能性があります。つまり、コントラクトがすべてのテストに合格しても、依然としてコードに脆弱性が存在する可能性が残ってしまいます。 しかし、高いコードカバレッジを記録していれば、スマートコントラクト内のすべてのステートメントや関数が正確であることを十分に検証することができます。 +[コードカバレッジ](https://en.m.wikipedia.org/wiki/Code_coverage)は、テスト中に実行されたコード内の分岐、行、ステートメントの数を追跡するテスト指標です。 そのため、テストされていない脆弱性のリクスを最小化するのに望ましいコードカバレッジにする必要があります。 コードカバレッジが不十分な場合、テストされていないコードパスに脆弱性が残っていても、テストを通過してしまい、コントラクトが安全であると誤って仮定してしう可能性があります。 しかし、高いコードカバレッジを記録していれば、スマートコントラクト内のすべてのステートメントや関数が正確であることを十分に検証することができます。 ##### 4. 完成度の高いテストフレームワークを使用する @@ -148,9 +148,9 @@ Solidityスマートコントラクト用の単体テストフレームワーク ### 統合テスト {#integration-testing-for-smart-contracts} -単体テストでは、コントラクトの関数を個別にデバッグしましたが、統合テストでは、スマートコントラクトのコンポーネント全体を評価します。 統合テストでは、スマートコントラクト間の呼び出しで発生する問題や、同じスマートコントラクト内の異なる関数間のやり取りで発生する問題を検出できます。 例えば、[継承](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance)や依存性注入などの機能が正しく動作するかどうかを確認するのに役立ちます。 +単体テストでは、コントラクトの関数を個別にデバッグしましたが、統合テストでは、スマートコントラクトのコンポーネント全体を評価します。 統合テストでは、スマートコントラクト間の呼び出しで発生する問題や、同じスマートコントラクト内の異なる関数間のやり取りで発生する問題を検出できます。 例えば、統合テストは、[継承](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance)や依存性の注入といったものが正しく機能するかどうかを確認するのに役立ちます。 -統合テストは、コントラクトがモジュラー型アーキテクチャを採用していたり、実行中に他のオンチェーンコントラクトと接続する場合に有用です。 統合テストを実行する方法の1つは、([Forge](https://book.getfoundry.sh/forge/fork-testing)や[Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks)などのツールを使用して)ブロックチェーンの特定のブロックの高さで[フォーク](/glossary/#fork)することです。そして、デプロイされたコントラクトと作成したコントラクトのやり取りをシミュレートします。 +統合テストは、コントラクトがモジュラー型アーキテクチャを採用していたり、実行中に他のオンチェーンコントラクトと接続する場合に有用です。 統合テストを実行する一つの方法は、特定の高さで[ブロックチェーンをフォーク](/glossary/#fork)し（[Forge](https://book.getfoundry.sh/forge/fork-testing)や[Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks)のようなツールを使用）、あなたのコントラクトとデプロイ済みのコントラクトとの間の相互作用をシミュレートすることです。 フォークされたブロックチェーンは、メインネットと同様の仕組みで動作し、アカウントに状態と残高が関連付けられています。 しかし、サンドボックス化されたローカル開発環境としてのみ機能します。例えば、トランザクションに実際のETHは必要なく、変更しても実際のイーサリアムプロトコルに影響することはありません。 @@ -158,38 +158,38 @@ Solidityスマートコントラクト用の単体テストフレームワーク プロパティベースのテストは、スマートコントラクトが定義されたプロパティを満たしていることを確認するプロセスです。 プロパティは、コントラクトの行動に関する事実をアサーションします。この事実は、さまざまなシナリオにおいて真であることが期待されるものです。スマートコントラクトプロパティの例としては、「コントラクト内の算術演算は、オーバーフローもアンダーフローもしない」などがあります。 -プロパティベースのテストを実行する方法には、**静的分析**と**動的分析**の2つの一般的な手法があります。どちらの手法でも、 プログラムのコード(この場合は、スマートコントラクト)が、事前に定義されたプロパティを満たしていることを検証できます。 プロパティベースのテストツールには、予期されるコントラクトプロパティに対する事前定義されたルールが備えてあり、コードがそれらのルールに違反しているかチェックするものや、スマートコントラクトのカスタムプロパティを作成できるものがあります。 +**静的解析**と**動的解析**は、プロパティベースのテストを実行するための2つの一般的な手法であり、どちらもプログラムのコード（この場合はスマートコントラクト）が、事前に定義されたプロパティを満たしていることを検証できます。 プロパティベースのテストツールには、予期されるコントラクトプロパティに対する事前定義されたルールが備えてあり、コードがそれらのルールに違反しているかチェックするものや、スマートコントラクトのカスタムプロパティを作成できるものがあります。 #### 静的解析 {#static-analysis} 静的アナライザーは、スマートコントラクトのソースコードを受け取って解析し、コントラクトがプロパティを満たしているかどうかを判断します。 動的解析とは異なり、静的解析では、コントラクトを実行して正確性の解析を行うことはありません。 静的解析は、スマートコントラクトが実行中にたどる可能性のあるすべてのパスを推論します。つまり、ソースコードの構造を調べて、コントラクトの操作がランタイムで何を意味するかを決定します。 -コントラクトで静的解析を実行する一般的な手法として、[リンティング](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important)と[静的テスト](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis)があります。 どちらの手法も、コンパイラによって出力された[抽象構文木](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree)や[制御フローグラフ](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/)など、コントラクト実行における低レベル表現の解析が必要です。 +[リンティング](https://www.perforce.com/blog/qac/what-is-linting)と[静的テスト](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis)は、コントラクトに対して静的解析を実行するための一般的な手法です。 どちらも、コンパイラによって出力される[抽象構文木](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree)や[制御フローグラフ](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/)のような、コントラクトの実行に関する低レベルの表現を分析する必要があります。 静的解析は、安全でない構造の使用や構文エラー、コントラクトコード内のコーディング規約違反などの安全性の問題を検出するには有効です。 しかし、より深い脆弱性の検出が不得意であることが知られており、過剰な誤検出が生じる可能性があります。 #### 動的解析 {#dynamic-analysis} -動的解析では、シンボリックな入力(例: [シンボリック実行](https://en.m.wikipedia.org/wiki/Symbolic_execution))または具体的な入力(例: [ファジング](https://owasp.org/www-community/Fuzzing))をスマートコントラクトの関数に生成して、実行トレースが特定のプロパティに違反していないかどうかを確認します。 この方式によるプロパティベースのテストでは、単体テストとは異なり、複数のシナリオのテストケースをカバーし、プログラムがテストケースを生成します。 +動的解析では、スマートコントラクトの関数にシンボリック入力（例：[シンボリック実行](https://en.m.wikipedia.org/wiki/Symbolic_execution)）や具象入力（例：[ファジング](https://owasp.org/www-community/Fuzzing)）を生成し、いずれかの実行トレースが特定のプロパティに違反するかどうかを確認します。 この方式によるプロパティベースのテストでは、単体テストとは異なり、複数のシナリオのテストケースをカバーし、プログラムがテストケースを生成します。 -[ファジング](https://halborn.com/what-is-fuzz-testing-fuzzing/)は、動的解析手法の例の1つでスマートコントラクトの任意のプロパティを検証します。 ファザー(fuzzer)は、定義されたランダムまたは不正なバリエーションの入力値で、ターゲットコントラクト内の関数を呼び出します。 スマートコントラクトがエラー状態 (例: アサーションが失敗した状態など) になると、問題に対してフラグが立てられ、実行によって脆弱なパスに向かう入力がレポートに作成されます。 +[ファジング](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing)は、スマートコントラクトの任意のプロパティを検証するための動的解析技術の一例です。 ファザー(fuzzer)は、定義されたランダムまたは不正なバリエーションの入力値で、ターゲットコントラクト内の関数を呼び出します。 スマートコントラクトがエラー状態 (例: アサーションが失敗した状態など) になると、問題に対してフラグが立てられ、実行によって脆弱なパスに向かう入力がレポートに作成されます。 ファジングは、スマートコントラクトの入力検証メカニズムを評価するのに効果的です。なぜなら、予期しない入力を適切に処理しないと、意図しない動作が発生し、悪影響が生じる可能性があるからです。 この方式によるプロパティベースのテストは、以下のような理由から理想的です。 -1. **さまざまなシナリオをカバーするテストケースを書くことは難しい**。 プロパティテストでは、振る舞いとその振る舞いをテストするためのデータ範囲を定義するだけです。プログラムは、定義されたプロパティに基づいてテストケースを自動的に生成します。 +1. **さまざまなシナリオをカバーするテストケースを書くことは難しい。** プロパティテストでは、振る舞いとその振る舞いをテストするためのデータ範囲を定義するだけです。プログラムは、定義されたプロパティに基づいてテストケースを自動的に生成します。 -2. **テストスイートがプログラム内のすべての実行パスを十分にカバーしていないことがある。**100%のカバレッジであっても、エッジケースを見逃す可能性があります。 +2. **テストスイートがプログラム内のすべての実行パスを十分にカバーしていないことがある。** 100%のカバレッジであっても、エッジケースを見逃す可能性があります。 -3. **単体テストでは、コントラクトがサンプルデータに対して正しく実行されることを証明できるが、サンプル外の入力に対して正しく実行されるかどうかは未確認のままである。**プロパティテストでは、ターゲットコントラクトを複数のバリエーションで実行します。 指定された入力値を使用して、アサーションの失敗を引き起こす実行トレースを見つけます。 そのため、プロパティテストでは、広範なクラスの入力データに対してコントラクトが正しく実行されることを、より確実に保証することができます。 +3. **単体テストでは、コントラクトがサンプルデータに対して正しく実行されることを証明できるが、サンプル外の入力に対して正しく実行されるかどうかは未確認のままである。** プロパティテストでは、アサーションの失敗を引き起こす実行トレースを見つけるため、指定された入力値の複数のバリエーションでターゲットコントラクトを実行します。 そのため、プロパティテストでは、広範なクラスの入力データに対してコントラクトが正しく実行されることを、より確実に保証することができます。 -### スマートコントラクトでプロパティベースのテストを実行する際のガイドライン {#running-property-based-tests} +### スマートコントラクトでプロパティベースのテストを実行するためのガイドライン {#running-property-based-tests} -プロパティベースのテストの実行では通常、プロパティの定義(例: [整数オーバーフロー](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)がないこと)、またはスマートコントラクト検証を行う必要のあるプロパティのコレクションを定義することから始めます。 プロパティテストを作成するときに、プログラムがトランザクションの入力データを生成するために、その値の範囲の定義が必要になることもあります。 +プロパティベースのテストの実行では通常、スマートコントラクトで検証したいプロパティ（例：[整数オーバーフロー](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)がないこと）やプロパティの集合を定義することから始めます。 プロパティテストを作成するときに、プログラムがトランザクションの入力データを生成するために、その値の範囲の定義が必要になることもあります。 プロパティテストツールは、適切に構成することで、ランダムに生成された入力値を使ってスマートコントラクトの関数を実行することができます。 アサーション違反が発生した場合、評価対象のプロパティに違反する具体的な入力データがレポートに含まれます。 プロパティベースのテストを実行するには、以下のさまざまなツールのガイドを参照してください。 -- **[Slitherを使ったスマートコントラクト静的解析](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)** -- **[Wakeを使ったスマートコントラクト静的解析](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** +- **[Slitherを使ったスマートコントラクトの静的解析](https://github.com/crytic/slither)** +- **[Wakeを使ったスマートコントラクトの静的解析](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - **[Brownieを使ったプロパティベースのテスト](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** - **[Foundryを使ったコントラクトのファジング](https://book.getfoundry.sh/forge/fuzz-testing)** - **[Echidnaを使ったコントラクトのファジング](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** @@ -205,43 +205,43 @@ Solidityスマートコントラクト用の単体テストフレームワーク ローカルの開発環境で実行される自動テストは、有用なデバッグ情報を提供しますが、実際の環境でスマートコントラクトがどのように動作するかを確認したい場合もあります。 しかし、実際のイーサリアムチェーンにデプロイするとガス代が発生します。また、スマートコントラクトにバグがある場合、ユーザーが実際にお金を失う可能性があることは言うまでもありません。 -メインネットでテストする代わりに、ローカルのブロックチェーン([開発ネットワーク](/developers/docs/development-networks/)とも呼ばれます)でコントラクトをテストすることをお勧めします。 ローカルブロックチェーンは、イーサリアムブロックチェーンのコピーで、自分のコンピュータのローカル環境で実行できるものです。これにより、イーサリアムの実行レイヤーの動作をシミュレートすることができます。 そのため、トランザクションをプログラムしてコントラクトとやり取りする際に、多額のコストが発生することはありません。 +Mainnetでテストする代わりに、ローカルのブロックチェーン（[開発ネットワーク](/developers/docs/development-networks/)とも呼ばれる）でコントラクトをテストすることが推奨されます。 ローカルブロックチェーンは、イーサリアムブロックチェーンのコピーで、自分のコンピュータのローカル環境で実行できるものです。これにより、イーサリアムの実行レイヤーの動作をシミュレートすることができます。 そのため、トランザクションをプログラムしてコントラクトとやり取りする際に、多額のコストが発生することはありません。 -ローカルのブロックチェーン上でコントラクトを実行するのは、手動で統合テストを行うのに効果的な方法です。 [スマートコントラクトは、柔軟に構成できるようになっています](/developers/docs/smart-contracts/composability/)。これにより、既存のプロトコルと統合できるようになりましたが、複雑なオンチェーンでの相互作用が正しい結果を生み出すかどうかについては、依然として確認する必要があります。 +ローカルのブロックチェーン上でコントラクトを実行するのは、手動で統合テストを行うのに効果的な方法です。 [スマートコントラクトは高い構成可能性を持ち](/developers/docs/smart-contracts/composability/)、既存のプロトコルと統合できます。しかし、そのような複雑なオンチェーンでの相互作用が正しい結果を生むことは、依然として確認する必要があります。 -[開発用ネットワークの詳細](/developers/docs/development-networks/) +[開発ネットワークの詳細。](/developers/docs/development-networks/) -### テストネットでのスマートコントラクトのテスト {#testing-contracts-on-testnets} +### テストネットでのコントラクトのテスト {#testing-contracts-on-testnets} -テストネットワークすなわちテストネットは、イーサリアムメインネットとまったく同じ仕様で動作するネットワークです。ただし、テストネットで使用されるイーサ(ETH)は、現実世界で価値がありません。 コントラクトを[テストネット](/developers/docs/networks/#ethereum-testnets)にデプロイすると、資金を失うリスクはありません。また、Dappのフロントエンドなどを介して、誰でもコントラクトとやり取りできるようになります。 +テストネットワークすなわちテストネットは、イーサリアムメインネットとまったく同じ仕様で動作するネットワークです。ただし、テストネットで使用されるイーサ(ETH)は、現実世界で価値がありません。 コントラクトを[テストネット](/developers/docs/networks/#ethereum-testnets)にデプロイすると、(例えばdappのフロントエンドを介して)誰もが資金をリスクにさらすことなくコントラクトと対話できます。 この方式の手動テストでは、ユーザーの視点からアプリケーションのエンドツーエンドのフローを評価することができます。 テストネットでは、ベータテスターが試験運用を行い、コントラクトのビジネスロジックや全体的な機能に関する問題を報告することもできます。 テストネットの方がイーサリアム仮想マシンの動作に近いため、ローカルブロックチェーンでテストした後にテストネットにデプロイすることが理想です。 そのため、多くのイーサリアムを使うプロジェクトでは、テストネットにDappをデプロイし、現実世界の条件下でスマートコントラクトの操作を評価するのが一般的です。 -[イーサリアムテストネットの詳細](/developers/docs/development-networks/#public-beacon-testchains) +[イーサリアムのテストネットの詳細。](/developers/docs/development-networks/#public-beacon-testchains) -## テストと形式検証の比較 {#testing-vs-formal-verification} +## テストと形式的検証の比較 {#testing-vs-formal-verification} -テストは、あるデータの入力に対して、コントラクトが期待通りの結果を返すことを確認するのに役立ちますが、テストで使用されていない入力に対して、同じことを確実に証明できるわけではありません。 したがって、スマートコントラクトのテストでは、「機能的な正しさ」を保証できません。つまり、入力値の_すべての_セットに対して、プログラムが要求通りに動作することを保証することはできません。 +テストは、あるデータの入力に対して、コントラクトが期待通りの結果を返すことを確認するのに役立ちますが、テストで使用されていない入力に対して、同じことを確実に証明できるわけではありません。 したがって、スマートコントラクトのテストでは「機能的な正しさ」を保証することはできません（つまり、プログラムが入力値の_すべての_セットに対して要求どおりに動作することを示すことはできません）。 形式検証は、プログラムの形式モデルが形式仕様と一致するかどうかを確認することでソフトウェアの正確さを評価するアプローチです。 プログラムを抽象的かつ数学的に表現したものが形式モデルで、プログラムのプロパティ(つまり、プログラムの実行に関する論理的アサーション)を定義したものが形式仕様です。 プロパティは、数学用語で記述されるため、システムの形式(数学)モデルが仕様を満たしていることを、論理的な推論規則を使用して検証することができます。 したがって、形式検証ツールは、システムの正確さを「数学的に証明」できると言われています。 -テストとは異なり、形式検証は、サンプルデータを使わずにスマートコントラクトが_どのような_実行においても、形式仕様を満たしていること(バグがないこと)を検証できます。 これにより、数十の単体テストの実行時間が短縮され、背後にある脆弱性をより効率的に発見できるようになります。 ただし、形式検証手法では、実装の難易度や有用性が多岐に渡ります。 +テストとは異なり、形式的検証は、スマートコントラクトの実行が_すべての_実行において形式的な仕様を満たしていること（つまり、バグがないこと）を、サンプルデータで実行する必要なく検証するために使用できます。 これにより、数十の単体テストの実行時間が短縮され、背後にある脆弱性をより効率的に発見できるようになります。 ただし、形式検証手法では、実装の難易度や有用性が多岐に渡ります。 -[スマートコントラクトの形式検証の詳細](/developers/docs/smart-contracts/formal-verification) +[スマートコントラクトの形式的検証の詳細。](/developers/docs/smart-contracts/formal-verification) ## テストと監査およびバグ報奨金の比較 {#testing-vs-audits-bug-bounties} 上記のように、厳密なテストをしても、コントラクトにバグがないとは言い切れません。 形式検証によるアプローチは、正確性をより強力に保証できますが、現時点では使用が難しく、かなりのコストがかかります。 -第三者によるコードレビューを受ければ、コントラクトの脆弱性を発見できる可能性が高くなります。 第三者にコントラクトを分析してもらうには、[スマートコントラクトの監査](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/)および[バグ報奨金](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)のいずれかの方法があります。 +第三者によるコードレビューを受ければ、コントラクトの脆弱性を発見できる可能性が高くなります。 [スマートコントラクト監査](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/)と[バグ報奨金](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)は、他者にあなたのコントラクトを分析してもらうための2つの方法です。 監査は、スマートコントラクトのセキュリティ上の欠陥や不健全な開発プラクティスを探し出す経験豊かな監査人が行います。 監査では、コードベース全体の手動レビューだけでなく、テストや形式検証も行われるのが一般的です。 -一方で、バグ報奨金プログラムでは通常、スマートコントラクトの脆弱性を発見してデベロッパーへ公開する([ホワイトハットハッカー](https://en.wikipedia.org/wiki/White_hat_(computer_security))と呼ばれる)個人に対して、金銭的な報酬が支払われます。 バグ報奨金は、スマートコントラクトの不具合の発見を他の人に依頼するもので、監査に似ています。 +逆に、バグ報奨金プログラムは通常、スマートコントラクトの脆弱性を発見し、それを開発者に開示した個人（一般的に[ホワイトハットハッカー](https://en.wikipedia.org/wiki/White_hat_\(computer_security\))と呼ばれる）に金銭的な報酬を提供することを含みます。 バグ報奨金は、スマートコントラクトの不具合の発見を他の人に依頼するもので、監査に似ています。 主な違いとしては、バグ報奨金プログラムは、より広範なデベロッパーやハッカーコミュニティを対象としているため、ユニークなスキルや経験を持つ幅広いクラスの倫理的なハッカーや独立したセキュリティ専門家を引きつけることができます。 これは、限られた専門知識を持つチームに依存するスマートコントラクト監査では得られない利点と言えるでしょう。 @@ -249,60 +249,62 @@ Solidityスマートコントラクト用の単体テストフレームワーク ### 単体テストツール {#unit-testing-tools} -- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Solidityで書かれたスマートコントラクトのコードカバレッジツール_ +- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Solidityで書かれたスマートコントラクトのためのコードカバレッジツール。_ -- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _高度なスマートコントラクトの開発とテストのためのフレームワーク(ethers.jsベース)_ +- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _高度なスマートコントラクト開発およびテストのためのフレームワーク（ethers.jsベース）。_ -- **[Remixテスト](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidityスマートコントラクトのテストツール。 Remix IDEの「Solidity Unit Testing」プラグインで動作します。このプラグインは、コントラクトのテストケースの作成と実行に使用します。_ +- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidityスマートコントラクトをテストするためのツール。 コントラクトのテストケースを記述・実行するために使用されるRemix IDE「Solidity Unit Testing」プラグインの下で動作します。_ -- **[OpenZeppelinテストヘルパー](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _イーサリアムスマートコントラクトのテストに使用できるアサーションライブラリ。 コントラクトが期待通りに動作していることを確認してください。_ +- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _イーサリアムのスマートコントラクトテスト用のアサーションライブラリ。 あなたの契約コードが期待どおりに動作することを確認してください!_ -- **[Brownieユニットテストフレームワーク](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _最小限のコードで小さなテストを作成可能。また、大規模なプロジェクトにも対応するスケーラビリティも持ち合わせており、機能豊富なテストフレームワークであるPytestを利用しています。_ +- **[Brownie単体テストフレームワーク](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownieは、豊富な機能を備えたテストフレームワークであるPytestを利用しています。これにより、最小限のコードで小さなテストを記述でき、大規模なプロジェクトにもうまくスケールし、高い拡張性を持ちます。_ -- **[Foundryテスト](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry社は、シンプルな単体テスト、ガス最適化チェック、コントラクトファジングを実行でき、高速で柔軟なイーサリアムテストフレームワークであるForgeを提供しています。_ +- **[Foundryテスト](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundryは、高速で柔軟なイーサリアムのテストフレームワークであるForgeを提供します。シンプルな単体テスト、ガス最適化チェック、コントラクトのファジングを実行できます。_ -- **[Hardhatテスト](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _ethers.js、Mocha、Chaiをベースとしたスマートコントラクトテストにおけるフレームワーク_。 +- **[Hardhatテスト](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _ethers.js、Mocha、Chaiをベースにしたスマートコントラクトのテストフレームワーク。_ -- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _イーサリアム仮想マシン用のスマートコントラクトでPythonベースの開発およびテストのためのフレームワーク_。 +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _イーサリアム仮想マシンをターゲットとするスマートコントラクトのための、Pythonベースの開発・テストフレームワーク。_ -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _Pythonベースの単体テストとファジングのフレームワークで、強力なデバック機能とクロスチェーンテストをサポートしており、pytestおよびAnvilを生かした最高のユーザーエクスペリエンスとパフォーマンスを実現。_ +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _pytestとAnvilを活用して最高のユーザーエクスペリエンスとパフォーマンスを実現する、強力なデバッグ機能とクロスチェーンテストをサポートするPythonベースの単体テストおよびファジングのフレームワーク。_ ### プロパティベースのテストツール {#property-based-testing-tools} #### 静的解析ツール {#static-analysis-tools} -- **[Slither](https://github.com/crytic/slither)** - _PythonベースのSolidity静的解析フレームワークで、脆弱性の発見、コード理解の強化、スマートコントラクトのカスタム解析の記述で使用_。 +- **[Slither](https://github.com/crytic/slither)** - _脆弱性の発見、コードの理解の向上、スマートコントラクトのカスタム解析の記述のための、PythonベースのSolidity静的解析フレームワーク。_ + +- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Solidityスマートコントラクトプログラミング言語のスタイルとセキュリティのベストプラクティスを強制するためのリンター。_ -- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _スマートコントラクトのプログラミング言語であるSolidityのスタイルとセキュリティのベストプラクティスを適用するためのリンター_。 +- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Web3スマートコントラクトのセキュリティと開発に特化して設計された、Rustベースの静的アナライザー。_ -- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Rustベースの静的解析ツールで、特にWeb3スマートコントラクトのセキュリティと開発のために設計されています。_ +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _脆弱性とコード品質の検出器、コードから有用な情報を抽出するためのプリンター、カスタムサブモジュールの記述のサポートを備えた、Pythonベースの静的解析フレームワーク。_ -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _Pythonベースの静的解析フレームワークで、脆弱性とコード品質の検出器、コードから有用な情報を抽出するプリンター、カスタムサブモジュールの作成をサポート。_ +- **[Slippy](https://github.com/fvictorio/slippy)** - _Solidityのためのシンプルで強力なリンター。_ #### 動的解析ツール {#dynamic-analysis-tools} -- **[Echidna](https://github.com/crytic/echidna/)** - _プロパティベースのテストによりスマートコントラクトの脆弱性を検出する高速なコントラクトファザー_。 +- **[Echidna](https://github.com/crytic/echidna/)** - _プロパティベースのテストを通じてスマートコントラクトの脆弱性を検出するための高速なコントラクトファザー。_ -- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _スマートコントラクトのコードのプロパティ違反を検出するのに便利な自動ファジングツール_。 +- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _スマートコントラクトコードのプロパティ違反を検出するのに役立つ自動ファジングツール。_ -- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _EVMバイトコード解析のための動的シンボリック実行フレームワーク_。 +- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _EVMバイトコードを解析するための動的シンボリック実行フレームワーク。_ -- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _Taint解析、Concolic解析、制御フローチェックを用いてコントラクトの脆弱性を検出するEVMバイトコード評価ツール_。 +- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _テイント解析、コンコリック解析、制御フローチェックを使用してコントラクトの脆弱性を検出するEVMバイトコード評価ツール。_ -- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribbleは、仕様記述言語およびランタイム検証ツールでスマートコントラクトのプロパティにアノテーションを付けることができます。これにより、Diligence FuzzingやMythXなどのツールを使用してコントラクトを自動的にテストできます。_ +- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribbleは、Diligence FuzzingやMythXなどのツールでコントラクトを自動的にテストできるプロパティでスマートコントラクトを注釈付けできる仕様言語およびランタイム検証ツールです。_ ## 関連チュートリアル {#related-tutorials} -- [さまざまな製品テストの概要と比較](/developers/tutorials/guide-to-smart-contract-security-tools/) \_ -- [スマートコントラクトのテストにEchidnaを使用する方法](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) -- [Manticoreを使用してスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) -- [Slitherを使用してスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) -- [Solidityコントラクトのテスト用モックの作成方法](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) -- [Foundryを使ったSolidityの単体テストの実行方法](https://www.rareskills.io/post/foundry-testing-solidity) +- [さまざまなテスト製品の概要と比較](/developers/tutorials/guide-to-smart-contract-security-tools/) \_ +- [Echidnaを使用してスマートコントラクトをテストする方法](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) +- [Manticore を使ってスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [Slither を使ってスマートコントラクトのバグを見つける方法](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [テストのためにSolidityコントラクトをモックする方法](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) +- [Foundryを使用してSolidityで単体テストを実行する方法](https://www.rareskills.io/post/foundry-testing-solidity) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアムスマートコントラクトのテストに関する詳細ガイド](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) -- [イーサリアムスマートコントラクトのテスト方法](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) -- [デベロッパー向けMolochDAOのユニットテストガイド](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) +- [イーサリアムのスマートコントラクトのテストに関する詳細ガイド](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) +- [イーサリアムのスマートコントラクトをテストする方法](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) +- [開発者向けMolochDAO単体テストガイド](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) - [ロックスターのようにスマートコントラクトをテストする方法](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/ja/developers/docs/smart-contracts/upgrading/index.md index 771d3f4b6cf..536fb9dc302 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/upgrading/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/upgrading/index.md @@ -1,6 +1,6 @@ --- -title: スマートコントラクトのアップグレード -description: イーサリアムスマートコントラクトのアップグレードパターンの概要 +title: "スマートコントラクトのアップグレード" +description: "イーサリアムスマートコントラクトのアップグレードパターンの概要" lang: ja --- @@ -10,9 +10,9 @@ lang: ja しかし、スマートコントラクトの改善に向けた研究が進み、いくつかのアップグレードパターンが開発されました。 これらのアップグレードでは、デベロッパーが別のコントラクトにビジネスロジックを配置することで、スマートコントラクトを(不変性を維持しつつ)アップグレードすることができます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -[スマートコントラクト](/developers/docs/smart-contracts/)、[スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)、 [イーサリアム仮想マシン(EVM)](/developers/docs/evm/)について十分に理解している必要があります。 さらに、このガイドでは、読者がスマートコントラクトのプログラミングを理解していることを前提としています。 +「[スマートコントラクト](/developers/docs/smart-contracts/)」、「[スマートコントラクトの構造](/developers/docs/smart-contracts/anatomy/)」、「[イーサリアム仮想マシン(EVM)](/developers/docs/evm/)」について、十分に理解しておく必要があります。 さらに、このガイドでは、読者がスマートコントラクトのプログラミングを理解していることを前提としています。 ## スマートコントラクトのアップグレードとは {#what-is-a-smart-contract-upgrade} @@ -70,13 +70,13 @@ lang: ja 3. 呼び出しがロジックコントラクトに転送された後、ロジックコントラクトから返されたデータを取得し、ユーザーに戻します。 -プロキシパターンを使うには、**delegatecall**関数を理解する必要があります。 基本的に、`delegatecall`は、コントラクトが別のコントラクトを呼び出すことができるオペコードですが、実際のコードは呼び出し元のコントラクトのコンテキストで行われます。 プロキシパターンで`delegatecall`を使用すると、プロキシコントラクトがストレージの読み取りと書き込みを行い、まるで内部関数を呼び出しているかのように、ロジックコントラクトのロジックを実行することになります。 +プロキシパターンを使用するには、**delegatecall**関数を理解する必要があります。 基本的に、`delegatecall`はコントラクトが別のコントラクトを呼び出すことを可能にするオペコードですが、実際のコード実行は呼び出し元コントラクトのコンテキストで行われます。 プロキシパターンで`delegatecall`を使用すると、プロキシコントラクトがストレージの読み取りと書き込みを行い、まるで内部関数を呼び出しているかのように、ロジックコントラクトのロジックを実行することになります。 -[Solidityのドキュメント](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)の引用: +[Solidityドキュメント](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)より: -> _**delegatecall**という特別な可変メッセージ呼び出しがあります。delegatecallは、ターゲットアドレスのコードが、呼び出し側コントラクトのコンテキスト(例: アドレス)で実行されることを除けば、メッセージ呼び出しと同一です。また、`msg.sender`と`msg.value`の値は変わりません。__これは、コントラクトが実行時に、別のアドレスからコードを動的にロードできることを意味します。 つまり、ストレージ、現在のアドレス、残高は呼び出し元のコントラクトを参照しており、 コードのみが呼び出し先のアドレスから取得されます_。 +> _**delegatecall**という、メッセージコールの特別な亜種が存在します。これは、ターゲットアドレスのコードが呼び出し元コントラクトのコンテキスト(すなわちアドレス)で実行され、`msg.sender`と`msg.value`の値が変わらない点を除けば、メッセージコールと同一です。_ _これは、コントラクトが実行時に異なるアドレスからコードを動的にロードできることを意味します。_ ストレージ、現在のアドレス、残高は呼び出し元のコントラクトを参照しており、コードのみが呼び出し先のアドレスから取得されます。_ -プロキシコントラクトには、`fallback`関数が組み込まれているため、ユーザーが関数を呼び出すたびに`delegatecall`をが呼び出されていることがわかります。 Solidityプログラミングでは、コントラクトの関数呼び出しが指定した関数と一致しない場合、[フォールバック関数](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function)が実行されます。 +プロキシコントラクトには`fallback`関数が組み込まれているため、ユーザーが関数を呼び出すと、常に`delegatecall`が呼び出されます。 Solidityプログラミングでは、関数呼び出しがコントラクトで指定された関数と一致しない場合に[フォールバック関数](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function)が実行されます。 プロキシパターンを機能させるには、プロキシコントラクトがサポートしていない関数の呼び出しを処理する方法を指定したカスタムフォールバック関数を作成する必要があります。 この場合、プロキシのフォールバック関数は、delegatecallを起動し、ユーザーのリクエストを現在のロジックコントラクト実装に切り替えるようにプログラムされます。 @@ -84,17 +84,17 @@ lang: ja プロキシコントラクトが新しいロジックコントラクトを参照するように変更することで、ユーザーがプロキシコントラクトの関数を呼び出すときに実行されるコードを変更することができます。 これにより、ユーザーは新しいコントラクトとやり取りする必要がなくなり、コントラクトのロジックをアップグレードすることができます。 -プロキシパターンは、コントラクトのマイグレーションを容易にすることから、アップグレードで広く普及している方法です。 ただし、プロキシパターンの使用は、より複雑なため、不適切に扱うと[関数セレクタークラッシュ](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)などの重大な欠陥を引き起こす可能性があります。 +プロキシパターンは、コントラクトのマイグレーションを容易にすることから、アップグレードで広く普及している方法です。 しかし、プロキシパターンは使用がより複雑であり、不適切に使用されると[関数セレクタの衝突](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)などの重大な欠陥を引き起こす可能性があります。 [プロキシパターンの詳細](https://blog.openzeppelin.com/proxy-patterns/) -### アップグレードメカニズム #4: ストラテジパターン {#strategy-pattern} +### アップグレードメカニズム #4: ストラテジーパターン {#strategy-pattern} -このテクニックは、[ストラテジパターン](https://en.wikipedia.org/wiki/Strategy_pattern)に基づいています。ストラテジパターンとは、特定の機能を実装するために、他のプログラムとインターフェースするソフトウェアプログラムを作成するよう奨励するものです。 ストラテジパターンをイーサリアム開発に適用すると、他のコントラクトから関数を呼び出すスマートコントラクトを構築することになります。 +このテクニックは[ストラテジーパターン](https://en.wikipedia.org/wiki/Strategy_pattern)の影響を受けています。これは、特定の機能を実装するために他のプログラムとインターフェースするソフトウェアプログラムを作成することを推奨するものです。 ストラテジパターンをイーサリアム開発に適用すると、他のコントラクトから関数を呼び出すスマートコントラクトを構築することになります。 この場合、メインコントラクトはコアとなるビジネスロジックを持ちますが、他のスマートコントラクト(「サテライトコントラクト」) のインターフェースで、特定の機能を実行します。 このメインコントラクトには、各サテライトコントラクトのアドレスが格納されており、サテライトコントラクトの実装を切り替えることができます。 -新しいサテライトコントラクトを構築して、メインコントラクトにその新しいコントラクトアドレスを設定することで、 スマートコントラクトの_ストラテジ_を変更(つまり、新しいロジックを実装)することができます。 +新しいサテライトコントラクトを構築して、メインコントラクトにその新しいコントラクトアドレスを設定することで、 これにより、スマートコントラクトの_ストラテジー_(すなわち、新しいロジックの実装)を変更できます。 先ほどのプロキシパターンと似ていますが、ストラテジパターンでは、ユーザーがやり取りするメインコントラクトがビジネスロジックを持っています。これは、プロキシパターンと異なる点です。 このパターンを使用すると、コアインフラストラクチャに影響を与えることなく、スマートコントラクトに限定的な変更を加えることができます。 @@ -104,9 +104,9 @@ lang: ja ダイヤモンドパターンは、プロキシパターンの改良版と言えます。 ダイヤモンドパターンでは、ダイヤモンドプロキシコントラクトが、関数呼び出しを複数のロジックコントラクトに委任できることができます。これは、プロキシパターンではできなかったことです。 -ダイヤモンドパターンのロジックコントラクトを_ファセット_と呼びます。 ダイヤモンドパターンを機能させるには、各ファセットアドレスに[関数セレクタ](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector)をマップするマッピングを、プロキシコントラクト内に作成する必要があります。 +ダイヤモンドパターンのロジックコントラクトは、_ファセット_として知られています。 ダイヤモンドパターンを機能させるには、プロキシコントラクト内で[関数セレクタ](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector)をさまざまなファセットアドレスにマッピングするマッピングを作成する必要があります。 -ユーザーが関数を呼び出すと、プロキシコントラクトはマッピングをチェックして、その関数の実行を担当するファセットを見つけます。 次に、(フォールバック関数を使って)`delegatecall`を呼び出します。この呼び出しは、適切なロジックコントラクトにリダイレクトされます。 +ユーザーが関数を呼び出すと、プロキシコントラクトはマッピングをチェックして、その関数の実行を担当するファセットを見つけます。 次に、(`fallback`関数を使用して)`delegatecall`を呼び出し、その呼び出しを適切なロジックコントラクトにリダイレクトします。 このダイヤモンドアップグレードパターンは、従来のプロキシアップグレードパターンに比べて、以下の利点があります。 @@ -114,13 +114,13 @@ lang: ja 2. すべてのスマートコントラクト(プロキシパターンで使用されるロジックコントラクトを含む)には、24KBのサイズ制限がある。この制限は、特に、多くの機能を必要とする複雑なコントラクトで適用されます。 ダイヤモンドパターンを使えば、関数を複数のロジックコントラクトに分割できるため、この問題を簡単に解決できます。 -3. プロキシパターンは、アクセス制御に対して、一括管理するアプローチを採用。 アップグレード機能にアクセスできるエンティティは、 コントラクト_全体_を変更することができます。 一方、ダイヤモンドパターンを使用することで、モジュールごとにアクセス許可を設定することができます。これにより、エンティティがスマートコントラクト内の特定の機能をアップグレードすることを制限できます。 +3. プロキシパターンは、アクセス制御に対して、一括管理するアプローチを採用。 アップグレード機能にアクセスできるエンティティは、コントラクト_全体_を変更できます。 一方、ダイヤモンドパターンを使用することで、モジュールごとにアクセス許可を設定することができます。これにより、エンティティがスマートコントラクト内の特定の機能をアップグレードすることを制限できます。 [ダイヤモンドパターンの詳細](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w) -## スマートコントラクトのアップグレードにおけるメリットとデメリット {#pros-and-cons-of-upgrading-smart-contracts} +## スマートコントラクトをアップグレードする際の長所と短所 {#pros-and-cons-of-upgrading-smart-contracts} -| メリット | デメリット | +| 長所 | 短所 | | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | スマートコントラクトのアップグレードにより、デプロイ後に発見された脆弱性を修正しやすくなります。 | スマートコントラクトをアップブレードすると、コードの不変性が失われ、分散化とセキュリティに悪影響を与える可能性があります。 | | デベロッパーは、ロジックのアップグレードを使い、分散アプリケーションに新しい機能を追加できます。 | ユーザーは、デベロッパーがスマートコントラクトを勝手に変更しないことを信頼しなければなりません。 | @@ -128,38 +128,38 @@ lang: ja | コントラクトのアップグレードにより、デベロッパーは、さまざまな機能を試したり、時間とともにDappを改良したりすることができます。 | スマートコントラクトをアップグレードできるため、デベロッパーは、開発段階でデューデリジェンスを行わずに、プロジェクトを早く開始してしまうかもしれません。 | | | スマートコントラクトがセキュリティが低下したアクセスコントロールや集中化のリスクにさらされることで、悪意のある攻撃者が、認可されていないアップグレードを実行しやすくなる可能性があります。 | -## スマートコントラクトのアップグレードにおける考慮事項 {#considerations-for-upgrading-smart-contracts} +## スマートコントラクトをアップグレードする際の考慮事項 {#considerations-for-upgrading-smart-contracts} 1. 特にプロキシパターン、ストラテジパターン、データセパレーションを使う場合、安全なアクセスコントロール/認可メカニズムを用いて、認可されていないスマートコントラクトへのアップグレードを防止します。 例えば、コントラクトの所有者のみがアップグレード関数を呼び出せるように、アップグレード関数へのアクセスを限定します。 2. スマートコントラクトのアップグレードは複雑な作業です。また、脆弱性の侵入を防ぐためには、細心の注意が必要です。 -3. アップグレードを実行するプロセスを分散化することで、信頼の仮定を軽減します。 可能な戦略としては、[マルチシグウォレットコントラクト](/developers/docs/smart-contracts/#multisig)を用いてアップグレードをコントロールしたり、[DAOメンバー](/dao/)の投票によってアップグレードを承認したりするなどの方法があります。 +3. アップグレードを実行するプロセスを分散化することで、信頼の仮定を軽減します。 考えられる戦略としては、[マルチシグウォレットコントラクト](/developers/docs/smart-contracts/#multisig)を使用してアップグレードを管理したり、アップグレードの承認について[DAOのメンバー](/dao/)に投票を求めたりする方法があります。 4. コントラクトのアップグレードにコストがかかることに注意します。 例えば、コントラクトのマイグレーション中に、古いコントラクトから新しいコントラクトへ状態(例: ユーザーの残高)をコピーするには、複数のトランザクションが必要になる場合があります。これにより、ガス代が高くなります。 -5. ユーザーの保護に**タイムロック**の実装を検討します。 タイムロックによって、システムへの変更を強制的に遅延させることができます。 タイムロックとマルチシグによるガバナンスシステムを組み合わせることで、アップグレードをコントロールすることができます。これにより、提案されたアクションが承認に必要なしきい値に達しても、タイムロックで事前に定めた遅延期間が経過するまでは実行されません。 +5. ユーザーを保護するために**タイムロック**の実装を検討してください。 タイムロックによって、システムへの変更を強制的に遅延させることができます。 タイムロックとマルチシグによるガバナンスシステムを組み合わせることで、アップグレードをコントロールすることができます。これにより、提案されたアクションが承認に必要なしきい値に達しても、タイムロックで事前に定めた遅延期間が経過するまでは実行されません。 タイムロックは、ユーザーが提案された変更(例: ロジックのアップグレードや新しい料金体系など)に同意しない場合、ユーザーに対してシステムから離脱する猶予期間を与える機能です。 タイムロックがないと、ユーザーは、デベロッパーが事前通知なしでスマートコントラクトを勝手に変更しないという信頼に頼らざるを得ません。 タイムロックの欠点としては、脆弱性に対するパッチの適用が遅れる可能性があることです。 -## リソース {#resources} +## 参考リソース {#resources} -**OpenZeppelinアップグレードプラグイン - _アップグレード可能なスマートコントラクトのデプロイおよび保護するためのツールスイート_** +**OpenZeppelin Upgrades Plugins - _アップグレード可能なスマートコントラクトをデプロイし、安全性を確保するためのツールスイート。_** - [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades) - [ドキュメント](https://docs.openzeppelin.com/upgrades) ## チュートリアル {#tutorials} -- [スマートコントラクトのアップグレード | Patrick CollinsによるYouTubeチュートリアル](https://www.youtube.com/watch?v=bdXJmWajZRY) -- Austin Griffithによる[イーサリアム・スマートコントラクト・マイグレーション・チュートリアル](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) -- Pranesh A.Sによる[UUPSプロキシパターンを使ったスマートコントラクトのアップグレード](https://blog.logrocket.com/author/praneshas/) -- fangjun.ethによる[Web3チュートリアル: OpenZeppelinを使用したアップグレード可能なスマートコントラクト(プロキシ)の作成](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) +- [スマートコントラクトのアップグレード | YouTubeチュートリアル](https://www.youtube.com/watch?v=bdXJmWajZRY) (Patrick Collins氏) +- [イーサリアムスマートコントラクトの移行チュートリアル](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) (Austin Griffith氏) +- [UUPSプロキシパターンを使用したスマートコントラクトのアップグレード](https://blog.logrocket.com/author/praneshas/) (Pranesh A.S氏) +- [Web3チュートリアル: OpenZeppelinを使用してアップグレード可能なスマートコントラクト(プロキシ)を作成](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) (fangjun.eth氏) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [スマートコントラクトの状態のアップグレード](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) | Santiago Palladino -- [Solidityスマートコントラクトのさまざまなアップグレード方法](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Poolのブログ -- [スマートコントラクトのアップグレードの学習](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelinドキュメント -- [Solidityコントラクトのアップグレード可能なプロキシパターン: 透過プロキシとUUPSプロキシの比較](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) | Naveen Sahu -- [ダイヤモンドアップグレードの動作原理](https://dev.to/mudgen/how-diamond-upgrades-work-417j) | Nick Mudge +- [スマートコントラクトアップグレードの現状](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) (Santiago Palladino氏) +- [Solidityスマートコントラクトをアップグレードする複数の方法](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Poolブログ +- [学習: スマートコントラクトのアップグレード](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelinドキュメント +- [Solidityコントラクトのアップグレード可能性のためのプロキシパターン: トランスペアレントプロキシ vs UUPSプロキシ](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) (Naveen Sahu氏) +- [ダイヤモンドアップグレードの仕組み](https://dev.to/mudgen/how-diamond-upgrades-work-417j) (Nick Mudge氏) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/ja/developers/docs/smart-contracts/verifying/index.md index 1c063dcf571..0eb28fa8d05 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/verifying/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/verifying/index.md @@ -1,16 +1,16 @@ --- -title: スマートコントラクトの検証 -description: イーサリアムのスマートコントラクトのソースコード検証の概要 +title: "スマートコントラクトの検証" +description: "イーサリアムのスマートコントラクトのソースコード検証の概要" lang: ja --- -[スマートコントラクト](/developers/docs/smart-contracts/) は「トラストレス」なものとして設計されています。つまり、ユーザーはスマートコントラクトとやりとりをする前に、第三者(デベロッパーや企業など)を信頼する必要はありません。 トラストレスであることを確保するためには、ユーザーやその他のデベロッパーがスマートコントラクトのソースコードを検証できるようにする必要があります。 ソースコード検証により、ユーザーとデベロッパーは、公開されたコントラクトコードが、イーサリアムブロックチェーン上のコントラクトアドレスで実行されているのと同じコードであることを確認できます。 +[スマートコントラクト](/developers/docs/smart-contracts/)は「トラストレス」なものとして設計されています。つまり、ユーザーはスマートコントラクトとやりとりをする前に、第三者(デベロッパーや企業など)を信頼する必要はありません。 トラストレスであることを確保するためには、ユーザーやその他のデベロッパーがスマートコントラクトのソースコードを検証できるようにする必要があります。 ソースコード検証により、ユーザーとデベロッパーは、公開されたコントラクトコードが、イーサリアムブロックチェーン上のコントラクトアドレスで実行されているのと同じコードであることを確認できます。 -「ソースコード検証」と「[形式的検証](/developers/docs/smart-contracts/formal-verification/)」を区別することは重要です。 以下で詳述するソースコード検証とは、高級言語(Solidityなど)で書かれたスマートコントラクトのソースコードをコンパイルしたものが、コントラクトアドレスで実行されるバイトコードと一致するかどうかを検証する手法ですが、 形式的検証は、スマートコントラクトの正しさ、つまり、スマートコントラクトが意図したとおりに動作することを検証するものです。 コントラクト検証とは、文脈にもよりますが、一般的にはソースコード検証を指します。 +「ソースコード検証」と「[形式的検証](/developers/docs/smart-contracts/formal-verification/)」を区別することは重要です。 ソースコード検証とは、以下で詳しく説明するように、高級言語（例：Solidity）で記述されたスマートコントラクトの特定のソースコードが、コントラクトアドレスで実行されるバイトコードと同じものにコンパイルされることを検証することを指します。 形式的検証は、スマートコントラクトの正しさ、つまり、スマートコントラクトが意図したとおりに動作することを検証するものです。 コントラクト検証とは、文脈にもよりますが、一般的にはソースコード検証を指します。 ## ソースコード検証とは {#what-is-source-code-verification} -スマートコントラクトを[イーサリアム仮想マシン(EVM)](/developers/docs/evm/)にデプロイする前に、デベロッパーはスマートコントラクトのソースコード([Solidity](/developers/docs/smart-contracts/languages/)もしくは他の高級プログラミング言語で書かれた命令)をバイトコードに[コンパイル](/developers/docs/smart-contracts/compiling/)します。 EVMは高級言語による命令を解釈できないため、EVM内でスマートコントラクトのビジネスロジックを実行するには、ソースコードをバイトコード(すなわち低級のマシン命令)にコンパイルする必要があります。 +[イーサリアム仮想マシン (EVM)](/developers/docs/evm/)にスマートコントラクトをデプロイする前に、デベロッパーはコントラクトのソースコード（[Solidity](/developers/docs/smart-contracts/languages/)または別の高級プログラミング言語で書かれた命令）をバイトコードに[コンパイル](/developers/docs/smart-contracts/compiling/)します。 EVMは高級言語による命令を解釈できないため、EVM内でスマートコントラクトのビジネスロジックを実行するには、ソースコードをバイトコード(すなわち低級のマシン命令)にコンパイルする必要があります。 ソースコード検証とは、スマートコントラクトの作成時に使用したソースコードと、実行時にコンパイルされたバイトコードを比較して、違いを検出することです。 公表されたスマートコントラクトのコードと、ブロックチェーン上で実行されるコードが異なる可能性があるため、スマートコントラクトの検証は重要な作業となります。 @@ -20,17 +20,17 @@ lang: ja ソースコードには、コメントや変数名など、コンパイル後のバイトコードに影響しない部分があります。 そのため、変数名やコメントが異なるソースコードでも、同じスマートコントラクトを検証することができます。 これを悪用して、ソースコードに嘘のコメントや誤解を招く変数名を与えて、元のソースコードとは別のコードでスマートコントラクトを検証することができます。 -ソースコードと正確に一致していることを_暗号学的に保証_したり、コンパイル情報の_フィンガープリント_をバイトコードに追加したりすることで、この問題を回避できます。 必要な情報は、[Solidityのコントラクトメタデータ](https://docs.soliditylang.org/en/v0.8.15/metadata.html)に含まれており、このファイルのハッシュは、コントラクトのバイトコードに追加されます。 この動作は、[メタデータのプレイグラウンド](https://playground.sourcify.dev)で確認できます。 +ソースコードの正確性に対する_暗号学的な保証_として、またコンパイル情報の_フィンガープリント_として機能する追加データをバイトコードに付加することで、これを回避することが可能です。 必要な情報は、[Solidityのコントラクトメタデータ](https://docs.soliditylang.org/en/v0.8.15/metadata.html)に含まれており、このファイルのハッシュは、コントラクトのバイトコードに追加されます。 その動作は[メタデータプレイグラウンド](https://playground.sourcify.dev)で確認できます。 メタデータファイルには、ソースファイルとそのハッシュを含む、スマートコントラクトのコンパイルに関する情報が含まれています。 コンパイル設定やソースファイルの1つが1バイトでも変更されると、メタデータファイルも変更されます。 そのため、バイトコードに付加されるメタデータファイルのハッシュも変更されます。 つまり、スマートコントラクトのバイトコードと付加されたメタデータハッシュが、指定されたソースコードおよびコンパイル設定と一致する場合、このソースコードは元のコンパイルで使われたものと完全に一致しており、1バイト単位で変更されていないことを確認できるのです。 -メタデータハッシュを活用するこのタイプの検証は、**"[全検証](https://docs.sourcify.dev/docs/full-vs-partial-match/)"**(または「完全検証」)と呼ばれます。 一方、メタデータハッシュが一致しない、または検証で考慮されていない場合は「部分一致」と呼ばれ、現在ではこれがより一般的なスマートコントラクト検証の方法です。 全検証をしない場合は、検証されたソースコードに表れない[悪意のあるコードを挿入](https://samczsun.com/hiding-in-plain-sight/)することが可能です。 しかし、ほとんどのデベロッパーは全検証を知らないうえに、コンパイルのメタデータファイルを保持していないため、現実的には部分検証がスマートコントラクト検証の主流となっています。 +メタデータハッシュを活用するこのタイプの検証は**「[完全検証](https://docs.sourcify.dev/docs/full-vs-partial-match/)」**（「完璧な検証」とも言います）と呼ばれます。 一方、メタデータハッシュが一致しない、または検証で考慮されていない場合は「部分一致」と呼ばれ、現在ではこれがより一般的なスマートコントラクト検証の方法です。 完全検証を行わなければ、検証済みのソースコードには反映されない[悪意のあるコードを挿入する](https://samczsun.com/hiding-in-plain-sight/)ことが可能です。 しかし、ほとんどのデベロッパーは全検証を知らないうえに、コンパイルのメタデータファイルを保持していないため、現実的には部分検証がスマートコントラクト検証の主流となっています。 ## ソースコード検証が重要な理由 {#importance-of-source-code-verification} ### トラストレス性 {#trustlessness} -トラストレス性は、スマートコントラクトと[分散型アプリケーション(dapps)](/developers/docs/dapps/)の最も重要な前提条件です。 スマートコントラクトは「不変」で、変更することはできません。そのため、スマートコントラクトは、デプロイ時にコードで定義されているビジネスロジックのみを実行します。 つまり、デベロッパーや企業は、イーサリアムにデプロイした後に、スマートコントラクトのコードを改ざんすることはできません。 +トラストレス性は、スマートコントラクトと[分散型アプリケーション (dapps)](/developers/docs/dapps/)にとって、間違いなく最大の前提条件です。 スマートコントラクトは「不変」で、変更することはできません。そのため、スマートコントラクトは、デプロイ時にコードで定義されているビジネスロジックのみを実行します。 つまり、デベロッパーや企業は、イーサリアムにデプロイした後に、スマートコントラクトのコードを改ざんすることはできません。 スマートコントラクトがトラストレスとなるためには、そのコードが独立した検証のために公開されている必要があります。 しかし、ブロックチェーン上で公開されているスマートコントラクトのコンパイル済みバイトコードは、デベロッパーやユーザーにとって理解するのが難しい低水準言語で書かれています。 @@ -40,15 +40,15 @@ lang: ja ### ユーザーの安全性 {#user-safety} -スマートコントラクトには、通常、高額のコストがかかります。 そのため、より高いセキュリティが求められ、使用前のスマートコントラクトのロジックの検証が必須となります。 問題は、悪意のある開発者がスマートコントラクトに悪意のあるコードを混ぜて、ユーザーを騙す可能性があることです。 検証を行わないと、悪意のあるスマートコントラクトには、ユーザーの安全性を脅かす問題が潜んだままの状態になります。例えば、[バックドア](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)や、物議をかもすようなアクセスコントロール機構、悪用されうる脆弱性などです。 +スマートコントラクトには、通常、高額のコストがかかります。 そのため、より高いセキュリティが求められ、使用前のスマートコントラクトのロジックの検証が必須となります。 問題は、悪意のある開発者がスマートコントラクトに悪意のあるコードを混ぜて、ユーザーを騙す可能性があることです。 検証を行わないと、悪意のあるスマートコントラクトには、[バックドア](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)、物議を醸すアクセスコントロールメカニズム、悪用可能な脆弱性など、ユーザーの安全性を損なうものが検出されないまま含まれている可能性があります。 スマートコントラクトのソースコードファイルを公開すると、監査役など、潜在的な攻撃媒介を評価する者は、スマートコントラクトの評価を容易に行うことができます。 複数の当事者が独自にスマートコントラクトを検証することで、ユーザーはより強力なセキュリティの保証を得ることができます。 -## イーサリアムのスマートコントラクトコードの検証方法 {#source-code-verification-for-ethereum-smart-contracts} +## イーサリアムのスマートコントラクトのソースコードを検証する方法 {#source-code-verification-for-ethereum-smart-contracts} -[イーサリアムにスマートコントラクトをデプロイする](/developers/docs/smart-contracts/deploying/)には、データペイロード(コンパイル済みバイトコード)を含むトランザクションを、特別なアドレスに送信する必要があります。 データペイロードは、トランザクション内のデータペイロードに付加されるコントラクトインスタンスの[コンストラクタ引数](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor)に加えて、ソースコードをコンパイルすることによって生成されます。 コンパイルは決定論的です。つまり、ソースファイルとコンパイル設定(コンパイラのバージョンや最適化など)が同じであれば、常に同じ結果(スマートコントラクトのバイトコード)を生成します。 +[イーサリアムにスマートコントラクトをデプロイする](/developers/docs/smart-contracts/deploying/)には、データペイロード（コンパイル済みのバイトコード）を含むトランザクションを特別なアドレスに送信する必要があります。 データペイロードは、ソースコードをコンパイルすることで生成されます。それに加えて、コントラクトインスタンスの[コンストラクタ引数](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor)が、トランザクションのデータペイロードの末尾に追加されます。 コンパイルは決定論的です。つまり、同じソースファイルとコンパイル設定（例：コンパイラのバージョン、オプティマイザ）が使用されていれば、常に同じ出力（コントラクトのバイトコード）を生成します。 -![スマートコントラクトソースコードの検証を説明する図](./source-code-verification.png) +![スマートコントラクトのソースコード検証を示す図](./source-code-verification.png) スマートコントラクトの検証は、大きく分けて次の手順で行われます。 @@ -62,7 +62,7 @@ lang: ja 5. さらに、バイトコード末尾のメタデータハッシュが一致すれば、完全一致となります。 -これは検証の単純化された記述であり、 [イミュータブル変数](https://docs.sourcify.dev/docs/immutables/)を持つ場合など、検証できない例外が多いことに注意してください。 +これは検証の単純化された記述であり、[イミュータブル変数](https://docs.sourcify.dev/docs/immutables/)を持つ場合など、この方法では機能しない例外が多いことに注意してください。 ## ソースコード検証ツール {#source-code-verification-tools} @@ -70,38 +70,44 @@ lang: ja ### Etherscan {#etherscan} -主に[イーサリアムのブロックチェーンエクスプローラー](/developers/docs/data-and-analytics/block-explorers/)として知られているEtherscanは、スマートコントラクトのデベロッパーやユーザー向けに、[ソースコード検証サービス](https://etherscan.io/verifyContract)も提供しています。 +主に[イーサリアムのブロックチェーンエクスプローラー](/developers/docs/data-and-analytics/block-explorers/)として知られていますが、Etherscanはスマートコントラクトの開発者やユーザー向けに[ソースコード検証サービス](https://etherscan.io/verifyContract)も提供しています。 -Etherscanを使用すると、元のデータペイロード(ソースコード、ライブラリのアドレス、コンパイラの設定、スマートコントラクトのアドレスなど)から、スマートコントラクトのバイトコードを再コンパイルできます。 再コンパイルされたバイトコードがチェーン上のスマートコントラクトのバイトコード(およびコンストラクタのパラメータ)に結び付くと、 [コントラクトが検証されます](https://info.etherscan.com/types-of-contract-verification/)。 +Etherscanを使用すると、元のデータペイロード(ソースコード、ライブラリのアドレス、コンパイラの設定、スマートコントラクトのアドレスなど)から、スマートコントラクトのバイトコードを再コンパイルできます。 再コンパイルされたバイトコードが、オンチェーンコントラクトのバイトコード（およびコンストラクタのパラメータ）と関連付けられると、[コントラクトは検証済み](https://info.etherscan.com/types-of-contract-verification/)となります。 -検証が完了すると、スマートコントラクトのソースコードは「検証済み」のラベルを受け取り、他の人が監査できるようにEtherscanで公開されます。 また、検証済みソースコードを備えたスマートコントラクトのリポジトリである[検証済みコントラクト](https://etherscan.io/contractsVerified/)のセクションにも追加されます。 +検証が完了すると、スマートコントラクトのソースコードは「検証済み」のラベルを受け取り、他の人が監査できるようにEtherscanで公開されます。 また、[検証済みコントラクト](https://etherscan.io/contractsVerified/)のセクションにも追加されます。これは、検証済みのソースコードを持つスマートコントラクトのリポジトリです。 -Etherscanはスマートコントラクトを検証するのに最もよく使用されるツールです。 しかし、Etherscanのコントラクト検証には欠点があります。チェーン上のバイトコードの**メタデータハッシュ**と再コンパイルされたバイトコードを比較することができないため、 部分一致しか得られません。 +Etherscanはスマートコントラクトを検証するのに最もよく使用されるツールです。 しかし、Etherscanのコントラクト検証には欠点があります。オンチェーンのバイトコードと再コンパイルされたバイトコードの**メタデータハッシュ**を比較できないことです。 部分一致しか得られません。 -[Etherscanでスマートコントラクトを検証する方法の詳細](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327) +[Etherscanでのコントラクト検証についての詳細](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327)。 + +### Blockscout {#blockscout} + +[Blockscout](https://blockscout.com/)は、オープンソースのブロックチェーンエクスプローラーで、スマートコントラクトの開発者やユーザーに[コントラクト検証サービス](https://eth.blockscout.com/contract-verification)も提供しています。 オープンソースの代替サービスとして、Blockscoutでは、検証の実行方法に透明性があり、コミュニティーのコントリビューションにより検証プロセスの向上を可能にしています。 + +他の検証サービスと同様に、Blockscoutでは、バイトコードを再コンパイルしてコントラクトのソースコードの検証が可能です。また、デプロイされたコントラクトと比較することもできます。 一度検証されると、そのコントラクトは検証済みステータスになります。ソースコードが公開され、監査や相互利用で使用可能です。 検証済みのコントラクトは、簡単に閲覧したり見つけたりできるように、Blockscoutの[検証済みコントラクトリポジトリ](https://eth.blockscout.com/verified-contracts)にもリストされます。 ### Sourcify {#sourcify} -[Sourcify](https://sourcify.dev/#/verifier)は、オープンソースで分散化された、スマートコントラクトを検証するためのツールです。 ブロックエクスプローラーではなく、 [異なるEVMベースのネットワーク](https://docs.sourcify.dev/docs/chains)でスマートコントラクトを検証するためのものです。 このツールは、他のツールを構築するためのパブリックインフラストラクチャとして機能します。[ABI](/developers/docs/smart-contracts/compiling/#web-applications)やメタデータファイル内で見つけた[NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html)コメントを使い、よりヒューマンフレンドリーにコントラクトとやり取りできるようにすることを目指しています。 +[Sourcify](https://sourcify.dev/#/verifier)は、オープンソースで分散化された、コントラクトを検証するための別のツールです。 これはブロックエクスプローラーではなく、[さまざまなEVMベースのネットワーク](https://docs.sourcify.dev/docs/chains)上のコントラクトのみを検証します。 これは、他のツールがその上で構築するためのパブリックインフラとして機能し、メタデータファイルにある[ABI](/developers/docs/smart-contracts/compiling/#web-applications)や[NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html)のコメントを使って、より人間が使いやすいコントラクトの対話を可能にすることを目指しています。 -Etherscanと違って、Sourcifyでは、メタデータハッシュとの完全一致をサポートしています。 検証されたコントラクトは、Sourcifyの[パブリックリポジトリ](https://docs.sourcify.dev/docs/repository/)によりHTTPおよび[IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs)で提供されます。IPFSは、分散化された[コンテンツアドレス付](https://web3.storage/docs/concepts/content-addressing/)ストレージです。 添付されたメタデータハッシュがIPFSハッシュであるため、IPFSを通してコントラクトファイルのメタデータを取り出すことができます。 +Etherscanと違って、Sourcifyでは、メタデータハッシュとの完全一致をサポートしています。 検証済みコントラクトは、HTTPおよび[IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs)上の[公開リポジトリ](https://docs.sourcify.dev/docs/repository/)で提供されます。IPFSは、分散型の[コンテンツアドレス指定](https://docs.storacha.network/concepts/content-addressing/)ストレージです。 添付されたメタデータハッシュがIPFSハッシュであるため、IPFSを通してコントラクトファイルのメタデータを取り出すことができます。 -さらに、ソースコードファイルのIPFSハッシュもメタデータ内にあるため、IPFSを通してソースコードファイルを取得することもできます。 APIもしくは[UI](https://sourcify.dev/#/verifier)を通して、またはプラグインを使って、メタデータファイルとソースファイルを提供することでコントラクトを検証できます。 また、Sourcifyのモニタリングツールは、新しいブロックでコントラクトの作成をリッスンし、メタデータとソースファイルがIPFSで公開されている場合にコントラクトを検証しようとします。 +さらに、ソースコードファイルのIPFSハッシュもメタデータ内にあるため、IPFSを通してソースコードファイルを取得することもできます。 コントラクトは、APIまたは[UI](https://sourcify.dev/#/verifier)経由でメタデータファイルとソースファイルを提供するか、プラグインを使用することで検証できます。 また、Sourcifyのモニタリングツールは、新しいブロックでコントラクトの作成をリッスンし、メタデータとソースファイルがIPFSで公開されている場合にコントラクトを検証しようとします。 -[Sourcifyのコントラクト検証の詳細](https://blog.soliditylang.org/2020/06/25/sourcify-faq/) +[Sourcifyでのコントラクト検証についての詳細](https://soliditylang.org/blog/2020/06/25/sourcify-faq/)。 ### Tenderly {#tenderly} -[Tenderlyプラットフォーム](https://tenderly.co/)は、Web3デベロッパー向けにスマートコントラクトのビルド、テスト、モニタリング、操作を提供します。 Tenderlyでは、オブザーバビリティおよびインフラストラクチャのビルディングブロックを持つデバックツールを組み合わせることで、デベロッパーがスマートコントラクトの開発をより迅速に行えるようサポートします。 Tenderlyの機能を完全に有効にするには、デベロッパーはいくつかの方法で[ソースコード検証を実行](https://docs.tenderly.co/monitoring/contract-verification)する必要があります。 +[Tenderlyプラットフォーム](https://tenderly.co/)により、Web3開発者はスマートコントラクトを構築、テスト、監視、運用できます。 Tenderlyでは、オブザーバビリティおよびインフラストラクチャのビルディングブロックを持つデバックツールを組み合わせることで、デベロッパーがスマートコントラクトの開発をより迅速に行えるようサポートします。 Tenderlyの機能を完全に有効にするには、開発者はいくつかの方法で[ソースコードの検証を行う](https://docs.tenderly.co/monitoring/contract-verification)必要があります。 コントラクトは、公開または非公開で検証できます。 非公開で検証する場合、スマートコントラクトは、作成者(もしくはプロジェクト内の他のメンバー)のみに公開されます。 公開で検証する場合、Tenderlyプラットフォームを使用するすべての人に公開されます。 -[ダッシュボード](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract)、[Tenderly Hardhatプラグイン](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin)、[CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli)を使ってコントラクトを検証することができます。 +[ダッシュボード](https://docs.tenderly.co/contract-verification)、[Tenderly Hardhatプラグイン](https://docs.tenderly.co/contract-verification/hardhat)、または[CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli)を使用して、コントラクトを検証できます。 ダッシュボードを通してコントラクトを検証する場合、Solidityコンパイラによって生成されたソースファイルもしくはメタデータファイル、アドレス/ネットワーク、コンパイラー設定をインポートする必要があります。 Tenderly Hardhatプラグインを使うと、少ない労力で検証プロセスをより細かく制御できます。また、自動(コードなし)検証と手動(コードベース)検証のいずれかを選択できます。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [コントラクトソースコードの検証](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) +- [コントラクトのソースコードを検証する](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/ja/developers/docs/standards/index.md b/public/content/translations/ja/developers/docs/standards/index.md index f7f0a4bcf2c..d272967f85e 100644 --- a/public/content/translations/ja/developers/docs/standards/index.md +++ b/public/content/translations/ja/developers/docs/standards/index.md @@ -1,59 +1,59 @@ --- -title: イーサリアム開発規格 -description: +title: "イーサリアム開発規格" +description: "イーサリアムの標準規格について学びましょう。EIP（イーサリアム改善提案）、ERC-20やERC-721のようなトークン標準、そして開発における慣例などが含まれます。" lang: ja incomplete: true --- -## 開発規格の概要 {#standards-overview} +## 規格の概要 {#standards-overview} -イーサリアムコミュニティでは、（[イーサリアムクライアント](/developers/docs/nodes-and-clients/)やウォレットなどの）各種プロジェクトにおける様々な実装間での相互運用性を維持し、スマートコントラクトやDappに対してコンポーザビリティを提供するために、多くの規格を定めています。 +イーサリアムコミュニティは、([イーサリアムクライアント](/developers/docs/nodes-and-clients/)やウォレットなどの) プロジェクトの実装間での相互運用性を維持し、スマートコントラクトとdappsの構成可能性を確保するために、多くの規格を採用しています。 -これらの規格は通常、[イーサリアム改善提案](/eips/)（EIP）として提出された後、コミュニティにおいて[標準プロセス](https://eips.ethereum.org/EIPS/eip-1)に従って議論されます。 +通常、規格は[イーサリアム改善提案](/eips/)(EIP)として導入され、[標準プロセス](https://eips.ethereum.org/EIPS/eip-1)を通じてコミュニティメンバーによって議論されます。 -- [EIPとは何か？](/eips/) -- [EIPリスト](https://eips.ethereum.org/) -- [GitHubのEIPレポジトリ](https://github.com/ethereum/EIPs) +- [EIP入門](/eips/) +- [EIPの一覧](https://eips.ethereum.org/) +- [EIPのGitHubリポジトリ](https://github.com/ethereum/EIPs) - [EIPディスカッションボード](https://ethereum-magicians.org/c/eips) -- [イーサリアムにおけるガバナンス入門](/governance/) -- [イーサリアムにおけるガバナンスの概説](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019年3月31日、ボリス・マン作成。_ -- [イーサリアムにおけるプロトコル開発のガバナンスならびにネットワークアップグレードの調整](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020年3月23日、ハドソン・ジェイムソン作成。_ -- [イーサリアムコア開発ミーティングのすべてのプレイリスト](https://www.youtube.com/@EthereumProtocol) _(YouTubeプレイリスト)_ +- [イーサリアムのガバナンス入門](/governance/) +- [イーサリアムのガバナンスの概要](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019年3月31日 - Boris Mann_ +- [イーサリアムプロトコル開発ガバナンスおよびネットワークアップグレードのコーディネーション](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020年3月23日 - Hudson Jameson_ +- [すべてのイーサリアム・コア開発者会議のプレイリスト](https://www.youtube.com/@EthereumProtocol) _(YouTubeプレイリスト)_ -## 標準規格の種類 {#types-of-standards} +## 規格の種類 {#types-of-standards} EIPは、以下の3種類に分類されます: - スタンダードトラック：すべて／大部分のイーサリアム実装に影響を及ぼす変更について記述します。 -- [メタトラック](https://eips.ethereum.org/meta)：イーサリアムに関するプロセスについて記述するか、プロセスの変更を提案します。 -- [情報トラック](https://eips.ethereum.org/informational)：イーサリアムの設計に関する問題点について記述するか、イーサリアムコミュニティに対する全般的なガイドラインや情報を提供します。 +- [メタトラック](https://eips.ethereum.org/meta): イーサリアムに関するプロセスについて記述するか、プロセスの変更を提案します。 +- [情報トラック](https://eips.ethereum.org/informational): イーサリアムの設計上の問題について記述したり、イーサリアムコミュニティに一般的なガイドラインや情報を提供したりします。 標準トラックはさらに、以下の4つのカテゴリーに分類されます： -- [コア](https://eips.ethereum.org/core)：コンセンサスフォークを必要とする改善。 -- [ネットワーク](https://eips.ethereum.org/networking)：devp2pならびにライトイーサリアムのサブプロトコルに関する改善や、WhisperおよびSwarmネットワークプロトコル仕様に対する改善提案。 -- [インターフェース](https://eips.ethereum.org/interface)：クライアント向けAPI/RPCの仕様／規格の改善と、メソッドの名称やコントラクトのABIなど、一部の言語レベルにおける規格の改善。 -- [ERC](https://eips.ethereum.org/erc)：アプリケーションレベルにおける規格および慣例。 +- [コア](https://eips.ethereum.org/core): コンセンサスフォークを必要とする改善 +- [ネットワーキング](https://eips.ethereum.org/networking): devp2pおよびライト・イーサリアム・サブプロトコルに関する改善、ならびにWhisperおよびSwarmのネットワークプロトコル仕様に対する改善提案。 +- [インターフェイス](https://eips.ethereum.org/interface): クライアントAPI/RPCの仕様と規格の改善、およびメソッド名やコントラクトABIのような、特定の言語レベルの規格の改善。 +- [ERC](https://eips.ethereum.org/erc): アプリケーションレベルの規格と規約 -これらの種類やカテゴリーの詳細については、[EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types)を参照してください。 +これらの種類やカテゴリに関する詳細については、[EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types)を参照してください。 ### トークン規格 {#token-standards} -- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 投票トークン、ステーキングトークン、通貨トークンなど、代替性トークン (FT) のための標準インタフェースです。 - - [ERC-223](/developers/docs/standards/tokens/erc-223/) - トークンをEtherと同じように動作させ、受信者側でのトークン送金処理をサポートする代替性トークン規格です。 - - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - transferまたはtransferFromを受信した後の受信者側におけるコードの実行や、承認後におけるspenderコードをサポートする、ERC-20トークンのトークンインターフェイスを定義します。 -- [ERC-721](/developers/docs/standards/tokens/erc-721/) - アートや楽曲のための証書など、非代替性トークン (NFT) を対象とする標準的なインタフェースです。 - - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - ひとつのNFTあるいは連続するトークン識別子を用いた複数のNFTを作成／転送する際に発行される標準イベント。 - - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721コンシューマーロール向けのインターフェース拡張機能。 - - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - ERC-721トークンに対して、制限付き許可を伴う時間限定ロールを追加します。 -- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **（推奨せず）** ERC-20を改善したトークン規格です。 -- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - 代替可能および非代替性の両方のトークンに用いることができるトークン規格です。 -- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - 利回りボールト（保管庫）における技術的なパラメータを最適化、統一することを目指して設計された、トークン化ボールト用の規格です。 +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 投票トークン、ステーキングトークン、または仮想通貨のような、ファンジブル(代替可能)トークンのための標準インターフェイスです。 + - [ERC-223](/developers/docs/standards/tokens/erc-223/) - トークンがEtherと同様に動作し、受信者側でのトークン転送処理をサポートするようにするファンジブルトークン規格。 + - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - 単一のトランザクションで受信者コントラクトのコールバックを実行することをサポートする、ERC-20トークンの拡張インターフェイス。 +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - アート作品や歌の権利証のような、非代替性トークン(NFT)の標準インターフェイスです。 + - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - 1つ、または連続したトークン識別子を使用する多数の非代替性トークンを作成・転送する際に発行される、標準化されたイベント。 + - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721のコンシューマーロールのためのインターフェイス拡張。 + - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - ERC-721トークンに、権限が制限された期限付きの役割を追加します。 +- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(非推奨)** ERC-20を改善するトークン規格。 +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ファンジブル資産とノンファンジブル資産の両方を含むことができるトークン規格。 +- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - 利回りをもたらすボールト(vault)の技術的パラメータを最適化し、統一するために設計されたトークン化ボールトの規格。 -[トークン規格](/developers/docs/standards/tokens/)に関する詳細情報。 +[トークン規格](/developers/docs/standards/tokens/)について、さらに詳しく知る。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [イーサリアム改善提案 (EIP)](/eips/) +- [イーサリアム改善提案(EIP)](/eips/) -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-1155/index.md index 2aeea8ad77f..cc86318ee30 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/erc-1155/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-1155/index.md @@ -1,35 +1,35 @@ --- -title: ERC-1155 マルチトークン規格 -description: +title: "ERC-1155 マルチトークン規格" +description: "単一のコントラクトで、代替可能トークンと非代替性トークンを組み合わせるマルチトークン標準であるERC-1155について学びましょう。" lang: ja --- ## はじめに {#introduction} -さまざまな種類のトークンを管理するコントラクトにおける標準的なインターフェイスです。 デプロイされたひとつのコントラクトには、代替性トークン、非代替性トークン、あるいはその他の種類のトークン（例：半代替性トークン）を含めることができます。 +さまざまな種類のトークンを管理するコントラクトにおける標準的なインターフェイスです。 デプロイされた単一のコントラクトには、代替可能トークン、非代替性トークン、またはその他の構成（例：半代替性トークン）の任意の組み合わせを含めることができます。 -**マルチトークン規格とは何か？** +**マルチトークン標準とは？** -この規格は、代替性か非代替性かを問わず、あらゆる種類のトークンを表現し、管理できるスマートコントラクトのインターフェイスを開発するというシンプルな発想に基づいて策定されたものです。 このため、ERC-1155規格に基づくトークンは、[ERC-20](/developers/docs/standards/tokens/erc-20/)および[ERC-721](/developers/docs/standards/tokens/erc-721/)トークンと同一の機能を提供し、この両方を同時に提供することすら可能です。 このため、ERC-20およびERC-721の両規格における機能や効率性が向上し、明らかな実装エラーを訂正することができます。 +この規格は、代替性か非代替性かを問わず、あらゆる種類のトークンを表現し、管理できるスマートコントラクトのインターフェイスを開発するというシンプルな発想に基づいて策定されたものです。 このようにして、ERC-1155トークンは、[ERC-20](/developers/docs/standards/tokens/erc-20/)トークンおよび[ERC-721](/developers/docs/standards/tokens/erc-721/)トークンと同じ機能を、さらに両方を同時に実行することができます。 このため、ERC-20およびERC-721の両規格における機能や効率性が向上し、明らかな実装エラーを訂正することができます。 -ERC-1155トークンの詳細な説明については、[EIP-1155](https://eips.ethereum.org/EIPS/eip-1155)を参照してください。 +ERC-1155トークンは、[EIP-1155](https://eips.ethereum.org/EIPS/eip-1155)で詳しく説明されています。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページをよく理解するには、まず[トークン規格](/developers/docs/standards/tokens/)、[ERC-20](/developers/docs/standards/tokens/erc-20/)、[ERC-721](/developers/docs/standards/tokens/erc-721/)について理解しておく必要があります。 +このページをよりよく理解するために、まず[トークン標準](/developers/docs/standards/tokens/)、[ERC-20](/developers/docs/standards/tokens/erc-20/)、および[ERC-721](/developers/docs/standards/tokens/erc-721/)についてお読みになることをお勧めします。 -## ERC-1155の機能と特長: {#body} +## ERC-1155の機能と特徴: {#body} -- [バッチ転送](#batch_transfers)：1回の呼び出しで複数のアセットを転送します。 -- [バッチ残高](#batch_balance)：1回の呼び出しで、複数の資産の残高を取得します。 -- [バッチ承認](#batch_approval)：ひとつのアドレスに対するすべてのトークンを承認します。 -- [フック](#receive_hook)：トークンのフックを受け取ります。 -- [NFTに対応](#nft_support)：供給トークンの数が1の場合、NFTとして扱います。 -- [安全な転送ルール](#safe_transfer_rule)：セキュアな転送のためのルールセットです。 +- [バッチ転送](#batch_transfers): 1回の呼び出しで複数のアセットを転送します。 +- [バッチ残高](#batch_balance): 1回の呼び出しで複数のアセットの残高を取得します。 +- [バッチ承認](#batch_approval): 1つのアドレスに対するすべてのトークンを承認します。 +- [フック](#receive_hook): トークン受信フック。 +- [NFTサポート](#nft_support): 供給量が1の場合、NFTとして扱います。 +- [安全な転送ルール](#safe_transfer_rule): 安全な転送のためのルールセットです。 ### バッチ転送 {#batch-transfers} -この規格におけるバッチ転送は、通常のERC-20の場合とほぼ同様です。 まず、通常のERC-20規格における`transferFrom`関数を確認しておきましょう: +この規格におけるバッチ転送は、通常のERC-20の場合とほぼ同様です。 通常のERC-20 `transferFrom`関数を見てみましょう。 ```solidity // ERC-20 @@ -47,15 +47,15 @@ function safeBatchTransferFrom( ERC-1155における唯一の違いは、値を配列として渡し、さらにIDの配列も渡す点です。 例えば、`ids=[3, 6, 13]`、`values=[100, 200, 5]`と指定した場合、以下のような転送が実行されます。 -1. id3では、`_from`から`_to`に100トークンを転送。 -2. id6では、`_from`から`_to`に200トークンを転送。 -3. id13では、`_from`から`_to`にi5トークンを転送。 +1. ID 3のトークン100個を`_from`から`_to`へ転送します。 +2. ID 6のトークン200個を`_from`から`_to`へ転送します。 +3. ID 13のトークン5個を`_from`から`_to`へ転送します。 -ERC-1155では、`transfer`は存在せず、`transferFrom`のみ利用できます。 通常の`transfer`のように使用するには、 関数を呼び出すアドレスをfrom addressとして設定すればよいです。 +ERC-1155では、`transfer`は存在せず、`transferFrom`のみ利用できます。 通常の`transfer`のように使用するには、fromアドレスを、関数を呼び出しているアドレスに設定します。 ### バッチ残高 {#batch-balance} -同様に、ERC-20における`balanceOf`の呼び出しも、バッチ処理に対応した機能が追加されています。 確認のために、まずERC-20の関数を見ておきましょう: +同様に、ERC-20の`balanceOf`呼び出しにも、バッチ処理に対応する関数があります。 確認のために、まずERC-20の関数を見ておきましょう: ```solidity // ERC-20 @@ -70,7 +70,7 @@ function balanceOfBatch( 残高の呼び出しがよりシンプルになり、1回の呼び出しで複数の残高を取得できるようになりました。 所有者の配列と、その後にトークンIDの配列を指定すればよいです。 -例えば、`_ids=[3, 6, 13]`と`_owners=[0xbeef..., 0x1337..., 0x111111...]`を与えると、戻り値は次のようになります: +例えば、`_ids=[3, 6, 13]`と`_owners=[0xbeef..., 0x1337..., 0x1111...]`が与えられた場合、戻り値は次のようになります。 ```solidity [ @@ -95,9 +95,9 @@ function isApprovedForAll( ) external view returns (bool); ``` -承認プロセスは、ERC-20とは若干異なります。 特定の金額を承認するのではなく、`setApprovalForAll`の関数を通じて承認／非承認を決定するオペレーターを指定します。 +承認プロセスは、ERC-20とは若干異なります。 特定の数量を承認するのではなく、`setApprovalForAll`を使って、オペレーターを承認済みまたは未承認に設定します。 -`isApprovedForAll`の関数を使って、現在の承認状態を読み込むことができます。 推測されたとおり、これはAll or Nothing型の操作です。 承認するトークンの数やトークンの種類を指定することはできません。 +現在の状態は`isApprovedForAll`を介して読み取ることができます。 推測されたとおり、これはAll or Nothing型の操作です。 承認するトークンの数やトークンの種類を指定することはできません。 これは、シンプルさを実現するために敢えて採用された設計です。 ひとつのアドレスに対し、すべて承認することだけが可能です。 @@ -113,7 +113,7 @@ function onERC1155BatchReceived( ) external returns(bytes4); ``` -ERC-1155は、[EIP-165](https://eips.ethereum.org/EIPS/eip-165)に対応しているため、スマートコントラクトに対する受信フックのみ対応しています。 このフック関数は、合い言葉として事前に定義されたbytes4の値（以下の形式を持つ）を返す必要があります。 +[EIP-165](https://eips.ethereum.org/EIPS/eip-165)がサポートされているため、ERC-1155はスマートコントラクトの受信フックのみをサポートします。 このフック関数は、合い言葉として事前に定義されたbytes4の値（以下の形式を持つ）を返す必要があります。 ```solidity bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) @@ -121,26 +121,26 @@ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],byt 受信側のコントラクトがこの値を返すと、コントラクトがこの転送を受け入れ、ERC-1155のトークンに対する処理方法を理解していると見なされます。 これにより、コントラクト内部で未処理のトークンが溜まっていくことがなくなります！ -### NFTのサポート {#nft-support} +### NFTサポート {#nft-support} -供給されるトークンの数が1である場合、このトークンは事実上非代替性トークン（NFT）だと言えます。 ERC-721規格と同じように、メタデータのURLを定義することが可能です。 このURLは、クライアントによる読み取り／変更が可能です。[こちら](https://eips.ethereum.org/EIPS/eip-1155#metadata)をご覧ください。 +供給されるトークンの数が1である場合、このトークンは事実上非代替性トークン（NFT）だと言えます。 ERC-721規格と同じように、メタデータのURLを定義することが可能です。 URLはクライアントによって読み取り、変更が可能です。詳細は[こちら](https://eips.ethereum.org/EIPS/eip-1155#metadata)をご覧ください。 -### 安全転送ルール {#safe-transfer-rule} +### 安全な転送ルール {#safe-transfer-rule} すでに他の記事において、いくつかの安全転送ルールについて紹介しました。 ここでは、最も重要なルールについて確認しておきましょう: -1. 発信者は、`_from`のトークンを支払う行為に対して承認を受けているか、`_from`と同一でなければなりません。 +1. 呼び出し元は、`_from`アドレスのトークンを使用することが承認されているか、または`_from`と等しくなければなりません。 2. 以下に該当する場合、転送の呼び出しは取り消されます: - 1. `_to`のアドレスが0である。 - 2. `_ids`の長さが`_values`の長さと一致しない。 - 3. `_ids`におけるトークン（複数可）の保有者（複数可）における残高（複数可）のいずれかが、受信者に送信された`_values`における当該の額（複数可）よりも少ない。 + 1. `_to`アドレスが0であること。 + 2. `_ids`の長さが`_values`の長さと一致しないこと。 + 3. `_ids`内のいずれかのトークンの保有者の残高が、受信者に送られる`_values`内のそれぞれの量よりも少ないこと。 4. その他のエラーが発生した。 -_注記_：フックを含むすべてのバッチ関数は、バッチ処理ではない通常バージョンの関数としても存在します。 これは、実際にはひとつの資産のみを転送するケースが最も一般的になると予想されるために、ガスの効率性を考慮した設計上の選択です。 この記事では、安全転送ルールの場合も含めて、簡潔な説明のためにバッチ関数のみを取り上げました。 各関数の名称は、「Batch」を削除すれば同一です。 +_注_: フックを含むすべてのバッチ関数は、バッチではないバージョンとしても存在します。 これは、実際にはひとつの資産のみを転送するケースが最も一般的になると予想されるために、ガスの効率性を考慮した設計上の選択です。 この記事では、安全転送ルールの場合も含めて、簡潔な説明のためにバッチ関数のみを取り上げました。 各関数の名称は、「Batch」を削除すれば同一です。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [ERC-1155：マルチトークン規格](https://eips.ethereum.org/EIPS/eip-1155) -- [ERC-1155：Openzeppelinのドキュメンテーション](https://docs.openzeppelin.com/contracts/3.x/erc1155) -- [ERC-1155：Githubリポジトリ](https://github.com/enjin/erc-1155) -- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) +- [EIP-1155: マルチトークン標準](https://eips.ethereum.org/EIPS/eip-1155) +- [ERC-1155: OpenZeppelinドキュメント](https://docs.openzeppelin.com/contracts/5.x/erc1155) +- [ERC-1155: GitHubリポジトリ](https://github.com/enjin/erc-1155) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-1363/index.md new file mode 100644 index 00000000000..d06eebbe6b9 --- /dev/null +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-1363/index.md @@ -0,0 +1,210 @@ +--- +title: "ERC-1363 支払い可能トークン標準" +description: "ERC-1363はERC-20トークンの拡張インターフェースであり、送金後に受信者コントラクトで、または承認後にスペンダーコントラクトでカスタムロジックを実行することを、すべて単一のトランザクション内でサポートします。" +lang: ja +--- + +## はじめに {#introduction} + +### ERC-1363とは何か？ {#what-is-erc1363} + +ERC-1363はERC-20トークンの拡張インターフェースであり、送金後に受信者コントラクトで、または承認後にスペンダーコントラクトでカスタムロジックを実行することを、すべて単一のトランザクション内でサポートします。 + +### ERC-20との違い {#erc20-differences} + +`transfer`、`transferFrom`、`approve`などの標準的なERC-20の操作では、別のトランザクションなしで受信者またはスペンダーコントラクト上でコードを実行することはできません。 +これによりUI開発が複雑化し、導入の障壁となります。ユーザーは最初のトランザクションの実行を待ってから2つ目を送信する必要があるためです。 +また、ガスも2回支払わなければなりません。 + +ERC-1363は、代替可能トークンがより簡単にアクションを実行し、オフチェーンリスナーを使用せずに動作できるようにします。 +これにより、単一のトランザクションで、送金または承認後に、受信者またはスペンダーコントラクトへのコールバックが可能になります。 + +## 前提条件 {#prerequisites} + +このページをよりよく理解するために、まず以下について読むことをお勧めします。 + +- [トークン規格](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## 規格の概要 {#body} + +ERC-1363は、`transfer`、`transferFrom`または`approve`の後にERC-20トークンがスマートコントラクトと対話するための標準APIを導入します。 + +この標準は、トークンを送金する基本的な機能を提供します。また、トークンを承認して別のオンチェーンの第三者が使用できるようにし、その後、受信者またはスペンダーコントラクトでコールバックを実行することも可能です。 + +ERC-20のコールバックを受け入れることができるスマートコントラクトには、多くの使用法が提案されています。 + +例としては: + +- **クラウドセール**：送信されたトークンが、即時の報酬割り当てをトリガーします。 +- **サービス**：支払いがワンステップでサービスアクセスを有効化します。 +- **請求書**：トークンが請求書を自動的に決済します。 +- **サブスクリプション**：年間レートを承認すると、最初の月の支払いでサブスクリプションが有効になります。 + +これらの理由から、元々は**「Payable Token」**と名付けられました。 + +コールバックの動作はその有用性をさらに広げ、以下のようなシームレスなインタラクションを可能にします。 + +- **ステーキング**：送金されたトークンが、ステーキングコントラクトでの自動ロックをトリガーします。 +- **投票**：受け取ったトークンが、ガバナンスシステムで投票を登録します。 +- **スワッピング**：トークンの承認が、ワンステップでスワップロジックを有効化します。 + +ERC-1363トークンは、送金または承認を受けた後にコールバックを実行する必要があるすべてのケースで、特定のユーティリティに使用できます。 +ERC-1363は、受信者がトークンを処理できる能力があるか検証することで、スマートコントラクトでのトークンの紛失やロックを回避するのにも役立ちます。 + +他のERC-20拡張提案とは異なり、ERC-1363はERC-20の`transfer`および`transferFrom`メソッドを上書きせず、ERC-20との後方互換性を維持しながら実装すべきインターフェースIDを定義します。 + +[EIP-1363](https://eips.ethereum.org/EIPS/eip-1363) から引用： + +### メソッド {#methods} + +ERC-1363標準を実装するスマートコントラクトは、`ERC1363`インターフェース、ならびに`ERC20`および`ERC165`インターフェースのすべての関数を**必ず**実装しなければなりません。 + +```solidity +pragma solidity ^0.8.0; + +/** + * @title ERC1363 + * @dev `transfer`または`transferFrom`の後、受信者コントラクト上でコードを実行するか、または`approve`の後、スペンダーコントラクト上でコードを実行することを単一のトランザクションでサポートする、ERC-20トークンの拡張インターフェースです。 + */ +interface ERC1363 is ERC20, ERC165 { + /* + * 注：このインターフェースのERC-165識別子は0xb0202a11です。 + * 0xb0202a11 === + * bytes4(keccak256('transferAndCall(address,uint256)')) ^ + * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) + */ + + /** + * @dev 呼び出し元のアカウントから`to`に`value`量のトークンを移動させ、 + * その後、`to`で`ERC1363Receiver::onTransferReceived`を呼び出します。 + * @param to トークンの転送先アドレス。 + * @param value 転送するトークンの量。 + * @return スローされない限り、操作が成功したことを示すブール値。 + */ + function transferAndCall(address to, uint256 value) external returns (bool); + + /** + * @dev 呼び出し元のアカウントから`to`に`value`量のトークンを移動させ、 + * その後、`to`で`ERC1363Receiver::onTransferReceived`を呼び出します。 + * @param to トークンの転送先アドレス。 + * @param value 転送するトークンの量。 + * @param data 指定されたフォーマットのない追加データで、`to`への呼び出しで送信されます。 + * @return スローされない限り、操作が成功したことを示すブール値。 + */ + function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev アローワンスメカニズムを使用して`from`から`to`に`value`量のトークンを移動させ、 + * その後、`to`で`ERC1363Receiver::onTransferReceived`を呼び出します。 + * @param from トークンを送信するアドレス。 + * @param to トークンの転送先アドレス。 + * @param value 転送するトークンの量。 + * @return スローされない限り、操作が成功したことを示すブール値。 + */ + function transferFromAndCall(address from, address to, uint256 value) external returns (bool); + + /** + * @dev アローワンスメカニズムを使用して`from`から`to`に`value`量のトークンを移動させ、 + * その後、`to`で`ERC1363Receiver::onTransferReceived`を呼び出します。 + * @param from トークンを送信するアドレス。 + * @param to トークンの転送先アドレス。 + * @param value 転送するトークンの量。 + * @param data 指定されたフォーマットのない追加データで、`to`への呼び出しで送信されます。 + * @return スローされない限り、操作が成功したことを示すブール値。 + */ + function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev 呼び出し元のトークンに対する`spender`のアローワンスとして、`value`量のトークンを設定し、 + * その後、`spender`で`ERC1363Spender::onApprovalReceived`を呼び出します。 + * @param spender 資金を使用するアドレス。 + * @param value 使用されるトークンの量。 + * @return スローされない限り、操作が成功したことを示すブール値。 + */ + function approveAndCall(address spender, uint256 value) external returns (bool); + + /** + * @dev 呼び出し元のトークンに対する`spender`のアローワンスとして、`value`量のトークンを設定し、 + * その後、`spender`で`ERC1363Spender::onApprovalReceived`を呼び出します。 + * @param spender 資金を使用するアドレス。 + * @param value 使用されるトークンの量。 + * @param data 指定されたフォーマットのない追加データで、`spender`への呼び出しで送信されます。 + * @return スローされない限り、操作が成功したことを示すブール値。 + */ + function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); +} + +interface ERC20 { + event Transfer(address indexed from, address indexed to, uint256 value); + event Approval(address indexed owner, address indexed spender, uint256 value); + function transfer(address to, uint256 value) external returns (bool); + function transferFrom(address from, address to, uint256 value) external returns (bool); + function approve(address spender, uint256 value) external returns (bool); + function totalSupply() external view returns (uint256); + function balanceOf(address account) external view returns (uint256); + function allowance(address owner, address spender) external view returns (uint256); +} + +interface ERC165 { + function supportsInterface(bytes4 interfaceId) external view returns (bool); +} +``` + +`transferAndCall`または`transferFromAndCall`を介してERC-1363トークンを受け入れたいスマートコントラクトは、`ERC1363Receiver`インターフェースを**必ず**実装しなければなりません： + +```solidity +/** + * @title ERC1363Receiver + * @dev ERC-1363トークンコントラクトからの`transferAndCall`または`transferFromAndCall`をサポートしたいすべてのコントラクトのためのインターフェースです。 + */ +interface ERC1363Receiver { + /** + * @dev ERC-1363トークンが、`operator`によって`from`からこのコントラクトに`ERC1363::transferAndCall`または`ERC1363::transferFromAndCall`を介して転送されるたびに、この関数が呼び出されます。 + * + * 注：転送を受け入れるには、この関数は + * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` + * (つまり0x88a7ca5c、またはそれ自身の関数セレクター) を返さなければなりません。 + * + * @param operator `transferAndCall`または`transferFromAndCall`関数を呼び出したアドレス。 + * @param from トークンが転送された元のアドレス。 + * @param value 転送されたトークンの量。 + * @param data 指定されたフォーマットのない追加データ。 + * @return スローされない限り、転送が許可されている場合は`bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))`。 + */ + function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +`approveAndCall`を介してERC-1363トークンを受け入れたいスマートコントラクトは、`ERC1363Spender`インターフェースを**必ず**実装しなければなりません： + +```solidity +/** + * @title ERC1363Spender + * @dev ERC-1363トークンコントラクトからの`approveAndCall`をサポートしたいすべてのコントラクトのためのインターフェースです。 + */ +interface ERC1363Spender { + /** + * @dev ERC-1363トークンの`owner`が、自身のトークンを使用するために`ERC1363::approveAndCall`を介してこのコントラクトを承認するたびに、この関数が呼び出されます。 + * + * 注：承認を受け入れるには、この関数は + * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` + * (つまり0x7b04a2d0、またはそれ自身の関数セレクター) を返さなければなりません。 + * + * @param owner `approveAndCall`関数を呼び出し、以前はトークンを所有していたアドレス。 + * @param value 使用されるトークンの量。 + * @param data 指定されたフォーマットのない追加データ。 + * @return スローされない限り、承認が許可されている場合は`bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))`。 + */ + function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +## 参考リンク {#further-reading} + +- [ERC-1363: 支払い可能トークン標準](https://eips.ethereum.org/EIPS/eip-1363) +- [ERC-1363: GitHubリポジトリ](https://github.com/vittominacori/erc1363-payable-token) diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-20/index.md index 4e34bb3c672..51c6de25a8c 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/erc-20/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-20/index.md @@ -1,6 +1,6 @@ --- -title: ERC-20トークン規格 -description: +title: "ERC-20トークン規格" +description: "イーサリアム上で相互運用可能なトークンアプリケーションを可能にする代替可能トークンの標準であるERC-20について学びましょう。" lang: ja --- @@ -17,17 +17,17 @@ lang: ja - 金（ゴールド）1オンス。 - 等々。 -イーサリアムにおいてこれほどの威力を持つ機能に対しては、必然的に堅牢な規格が必要です。 これこそ、ERC-20規格が果たすべき役割なのです！ この規格を用いることで、イーサリアム外の製品やサービスと相互運用できるトークンアプリを構築することが可能になります。 ERC-20規格は、[Ether](/glossary/#ether)へ追加機能を提供するのにも使われています。 +イーサリアムにおいてこれほどの威力を持つ機能に対しては、必然的に堅牢な規格が必要です。 これこそ、ERC-20規格が果たすべき役割なのです！ この規格を用いることで、イーサリアム外の製品やサービスと相互運用できるトークンアプリを構築することが可能になります。 ERC-20規格は、[ether](/glossary/#ether)に追加機能を提供するのにも使われています。 **ERC-20とは何か？** ERC-20規格は、代替性トークンを扱うための標準規格です。つまりこの規格では、ひとつのトークンが、その種類および値において他のトークンとまったく同じであるというプロパティを持たせることができます。 例えば、ERC-20トークンはETHとまったく同様に動作します。つまり、1トークンは、現在および将来において常に、他のひとつのトークンと同等になります。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} - [アカウント](/developers/docs/accounts) - [スマートコントラクト](/developers/docs/smart-contracts/) -- [トークンの基準](/developers/docs/standards/tokens/) +- [トークン規格](/developers/docs/standards/tokens/) ## 規格の概要 {#body} @@ -42,7 +42,7 @@ ERC-20は、以下のような機能を提供します: 以下のメソッドおよびイベントを実装しているスマートコントラクトはERC-20トークンコントラクトと呼ぶことができ、デプロイされると、イーサリアム上で発行されたトークンの状況を追跡する責任を負います。 -[EIP-20](https://eips.ethereum.org/EIPS/eip-20)から引用： +[EIP-20](https://eips.ethereum.org/EIPS/eip-20) から引用： ### メソッド {#methods} @@ -65,13 +65,14 @@ event Transfer(address indexed _from, address indexed _to, uint256 _value) event Approval(address indexed _owner, address indexed _spender, uint256 _value) ``` -### 実例： {#web3py-example} +### 実例 {#web3py-example} -イーサリアムのERC-20トークンコントラクトのコードを詳しく見ることで、これらの規格がイーサリアムのシンプルさを保証する上でどれだけ重要なのかを理解しておきましょう。 ERC-20トークンを扱うインターフェイスを開発するには、当該コントラクトのアプリケーション・バイナリー・インターフェイス（ABI）を用いればよいです。 理解しやすいように、以下では簡略化したABIを用いています。 +イーサリアムのERC-20トークンコントラクトのコードを詳しく見ることで、これらの規格がイーサリアムのシンプルさを保証する上でどれだけ重要なのかを理解しておきましょう。 +ERC-20トークンを扱うインターフェイスを開発するには、当該コントラクトのアプリケーション・バイナリー・インターフェイス（ABI）を用いればよいです。 理解しやすいように、以下では簡略化したABIを用いています。 -#### Web3.pyの実例： {#web3py-example} +#### Web3.pyの例 {#web3py-example} -まず、 Pythonのライブラリから[Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation)をインストール済みであることを確認してください: +まず、[Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Pythonライブラリがインストールされていることを確認してください: ``` pip install web3 @@ -88,8 +89,8 @@ weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ethe acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 -# これはERC-20トークンのコントラクトのアプリケーション・バイナリ・インターフェース（ABI）を簡略化したものです。 -# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply() +# これは、ERC-20トークンコントラクトの簡易版コントラクトアプリケーションバイナリインターフェース (ABI) です。 +# balanceOf(address)、decimals()、symbol()、totalSupply()のメソッドのみを公開します。 simplified_abi = [ { 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], @@ -142,32 +143,44 @@ print("Addr Balance:", addr_balance) ## 既知の問題 {#erc20-issues} -### ERC-20トークン受信問題 {#reception-issue} +### ERC-20トークンの受信に関する問題 {#reception-issue} + +**2024年6月20日現在、この問題により少なくとも83,656,418ドル相当のERC-20トークンが失われました。 純粋なERC-20実装は、下記にリストされているような標準への追加制限を実装しない限り、この問題が発生しやすくなりますのでご注意ください。** ERC-20トークンを扱えるように設計されていないスマートコントラクトにERC-20トークンが送信されると、送信されたトークンが永久的に失われる可能性があります。 これは、トークンを受け取るコントラクトに送られてきたトークンを認識したり応答する機能がないためです。また、ERC-20標準には、送られてきたトークンを、受け取るコントラクトに通知するメカニズムがありません。 これが問題となる主要な状態は、次になります。 -1. トークン送信メカニズム - - ERC-20トークンは、transfer関数かtransferFrom関数を使って送信されます。 - - ユーザーがこれらの関数を使ってコントラクトアドレスにトークンを送信すると、受け取るコントラクトがトークンを扱えるように設計されているかにどうかに関わらずトークンが送信されてしまいます。 -2. 通知の欠如 - - トークンを受け取るコントラクトは、トークンが送られてきたことに関して通知やコールバックを受け取りません。 - - 受け取るコントラクトにトークンを扱うメカニズム(例: フォールバック関数またはトークンを受信する専用の関数)が無い場合、トークンは実質的にコントラクトアドレスにスタックされます。 -3. 組み込まれた処理が無い - - ERC-20標準では、受け取るコントラクが実装する必須関数が含まれていません。そのため、多くのコントラクトでは、送られてくるトークンを適切に扱うことができない状態が生じています。 +1. トークン送信メカニズム -この問題から、[ERC-223](/developers/docs/standards/tokens/erc-223) [ERC-1363](/developers/docs/standards/tokens/erc-1363) などの代替規格が登場しています。 +- ERC-20トークンは、transfer関数かtransferFrom関数を使って送信されます。 + - ユーザーがこれらの関数を使ってコントラクトアドレスにトークンを送信すると、受け取るコントラクトがトークンを扱えるように設計されているかにどうかに関わらずトークンが送信されてしまいます。 -## 参考文献 {#further-reading} +2. 通知の欠如 + - トークンを受け取るコントラクトは、トークンが送られてきたことに関して通知やコールバックを受け取りません。 + - 受け取るコントラクトにトークンを扱うメカニズム(例: フォールバック関数またはトークンを受信する専用の関数)が無い場合、トークンは実質的にコントラクトアドレスにスタックされます。 +3. 組み込まれた処理が無い + - ERC-20標準では、受け取るコントラクが実装する必須関数が含まれていません。そのため、多くのコントラクトでは、送られてくるトークンを適切に扱うことができない状態が生じています。 -- [EIP-20：ERC-20トークン規格](https://eips.ethereum.org/EIPS/eip-20) -- [OpenZeppelin - トークン](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) -- [OpenZeppelin - ERC-20の実装](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) -- [Alchemy - SolidityにおけるERC20トークンのガイド](https://www.alchemy.com/overviews/erc20-solidity) +**考えられる解決策** + +ERC-20でこの問題を完全に防ぐことはできませんが、エンドユーザーにとってトークンを失う可能性を大幅に減らすことができる方法があります: + +- 最も一般的な問題は、ユーザーがトークンをトークンコントラクトアドレス自体に送信してしまうことです (例: USDTがUSDTトークンコントラクトのアドレスに入金される)。 このような送金を試みた場合に元に戻すように `transfer(..)` 関数を制限することが推奨されます。 `transfer(..)` 関数の実装内に `require(_to != address(this));` のチェックを追加することを検討してください。 +- `transfer(..)` 関数は、一般的にコントラクトにトークンを入金するようには設計されていません。 `approve(..)` & transferFrom(..)`のパターンが、代わりにERC-20トークンをコントラクトに入金するために使用されます。`transfer`関数を制限して、それを使ったコントラクトへのトークンの入金を不許可にすることは可能ですが、`trasnfer(..)`関数でコントラクトにトークンを入金できると想定しているコントラクト (例: Uniswapの流動性プール) との互換性が損なわれる可能性があります。 +- コントラクトがトークンを受け取ることを想定していない場合でも、ERC-20トークンがコントラクトに送られてくる可能性があることを常に想定してください。 受信者側で、誤った入金を防いだり拒否したりする方法はありません。 誤って入金されたERC-20トークンを抽出できる関数を実装することが推奨されます。 +- 代替のトークン標準の使用を検討してください。 +この問題から、[ERC-223](/developers/docs/standards/tokens/erc-223)や[ERC-1363](/developers/docs/standards/tokens/erc-1363)などのいくつかの代替標準が生まれました。 + +## 参考リンク {#further-reading} + +- [EIP-20: ERC-20トークン規格](https://eips.ethereum.org/EIPS/eip-20) +- [OpenZeppelin - トークン](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) +- [OpenZeppelin - ERC-20実装](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) +- [Alchemy - Solidity ERC20トークンガイド](https://www.alchemy.com/overviews/erc20-solidity) -## その他の代替性トークン {#fungible-token-standards} +## その他の代替可能トークン標準 {#fungible-token-standards} - [ERC-223](/developers/docs/standards/tokens/erc-223) - [ERC-1363](/developers/docs/standards/tokens/erc-1363) - [ERC-777](/developers/docs/standards/tokens/erc-777) -- [ERC-4626 - トークン化ボールト](/developers/docs/standards/tokens/erc-4626) \ No newline at end of file +- [ERC-4626 - トークン化された保管庫](/developers/docs/standards/tokens/erc-4626) diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md index 499ea17ea2e..5e627bb0a54 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md @@ -1,6 +1,6 @@ --- -title: ERC-223 トークン規格 -description: ERC-223 ファンジブルトークン規格の概要、その仕組み、およびERC-20との比較。 +title: "ERC-223 トークン規格" +description: "ERC-223 ファンジブルトークン規格の概要、その仕組み、およびERC-20との比較。" lang: ja --- @@ -18,7 +18,7 @@ ERC-223は、ERC-20のいくつかの制限を解決し、トークンコント - 誤って送信されたトークンの拒否：ユーザーがトークンを受け取るべきではないコントラクトにERC-223トークンを送信した場合、そのコントラクトはトランザクションを拒否し、トークンの損失を防ぐことができます。 - 転送時のメタデータ：ERC-223トークンはメタデータを含めることができ、トークントランザクションに任意の情報を添付することが可能です。 -## 前提条件{#prerequisites} +## 前提条件 {#prerequisites} - [アカウント](/developers/docs/accounts) - [スマートコントラクト](/developers/docs/smart-contracts/) @@ -128,7 +128,7 @@ contract RecipientContract is IERC223Recipient { { // この関数内で理解するべき重要な点： // msg.senderは、受け取っているトークンのアドレスです。 - // msg.valueは常に0です。なぜなら、通常トークンコントラクトはEtherを保有したり送信したりしないためです。 + // msg.valueは常に0です。なぜなら、通常トークンコントラクトはetherを保有したり送信したりしないためです。 // _from はトークン転送の送信者です。 // _value は預け入れられたトークンの量です。 require(msg.sender == tokenA); @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -`RecipientContract` がERC-223トークンを受け取ると、そのコントラクトはトークントランザクションの `_data` パラメータにエンコードされた関数を実行します。これはイーサのトランザクションが関数呼び出しをトランザクションの `data` としてエンコードするのと同じです。 詳細については [dataフィールド](/developers/docs/transactions/#the-data-field) を参照してください。 +`RecipientContract`がERC-223トークンを受け取ると、そのコントラクトは、トークン取引の`_data`ラメーターとしてエンコードされた関数を実行します。これは、イーサリアムの取引が、取引の`data`として関数呼び出しをエンコードするのと全く同じです。 詳細については [dataフィールド](/developers/docs/transactions/#the-data-field) を参照してください。 上記の例では、ERC-223トークンは `transfer(address,uin256,bytes calldata _data)` 関数を使用して `RecipientContract` のアドレスに転送される必要があります。 dataパラメータが `0xc2985578` （ `foo()` 関数のシグネチャ）である場合、トークンデポジットが完了した後にfoo()関数が呼び出され、Foo()イベントが発行されます。 @@ -191,7 +191,7 @@ ERC-223は、ERC-20規格で見られるいくつかの問題に対処してい - 後方互換性：ERC-223はERC-20と後方互換性がないため、既存のERC-20コントラクトやツールは、修正なしではERC-223トークンと連携できません。 - ガス代：ERC-223の転送には追加のチェックや機能が含まれるため、ERC-20トランザクションに比べてガス代が高くなる可能性があります。 -## 参考リンク{#further-reading} +## 参考リンク {#further-reading} - [EIP-223: ERC-223トークン規格](https://eips.ethereum.org/EIPS/eip-223) - [初期のERC-223提案](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-4626/index.md index cc552ff1be0..0f9fa0662df 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/erc-4626/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-4626/index.md @@ -1,6 +1,6 @@ --- -title: ERC-4626 トークン化ボールト規格 -description: 利回りボールトを対象とする規格。 +title: "ERC-4626 トークン化ボールト規格" +description: "利回りボールトを対象とする規格。" lang: ja --- @@ -14,13 +14,29 @@ ERC-4626は、利回りボールトの技術的なパラメータを最適化し 利回りボールトのデベロッパーは、ERC-4626を活用することで、より一貫性が高く堅牢な実装パターンを実現できるため、アプリケーションとの統合にかかる作業を軽減し、様々なアプリケーションにおいて利回りを獲得できるようにするための別途の取り組みを削減することができます。 -ERC-4626トークンの詳細については、[EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)をご覧ください。 +ERC-4626トークンは、[EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)で詳しく説明されています。 -## 前提知識 {#prerequisites} +**非同期ボールト拡張(ERC-7540)** -この記事をよく理解するには、まず[トークン規格](/developers/docs/standards/tokens/)および[ERC-20](/developers/docs/standards/tokens/erc-20/)に目を通すことをおすすめします。 +ERC-4626は、上限までのアトミックな預け入れと償還に最適化されています。 上限に達した場合、新しい預け入れや償還は送信できません。 この制限は、ボールトとのインターフェースの前提条件として非同期アクションや遅延を伴うスマートコントラクトシステム(実世界資産プロトコル、担保不足貸付プロトコル、クロスチェーン貸付プロトコル、リキッドステーキングトークン、保険セーフティモジュールなど)ではうまく機能しません。 -## ERC-4626の機能と特長: {#body} +ERC-7540は、非同期ユースケース向けにERC-4626ボールトの有用性を拡張します。 既存のボールトインターフェース(`deposit`/`withdraw`/`mint`/`redeem`)は、非同期リクエストを要求するために完全に利用されます。 + +ERC-7540拡張は、[ERC-7540](https://eips.ethereum.org/EIPS/eip-7540)で詳しく説明されています。 + +**マルチアセットボールト拡張 (ERC-7575)** + +ERC-4626でサポートされていないユースケースの1つは、流動性プロバイダー(LP)トークンなどの複数の資産またはエントリーポイントを持つボールトです。 これらは、ERC-4626自体がERC-20であるという要件のために、一般的に扱いにくかったり、非準拠であったりします。 + +ERC-7575は、ERC-20トークンの実装をERC-4626の実装から外部化することにより、複数の資産を持つボールトのサポートを追加します。 + +ERC-7575拡張は、[ERC-7575](https://eips.ethereum.org/EIPS/eip-7575)で詳しく説明されています。 + +## 前提条件 {#prerequisites} + +このページをよりよく理解するために、まず[トークン標準](/developers/docs/standards/tokens/)と[ERC-20](/developers/docs/standards/tokens/erc-20/)について読むことをお勧めします。 + +## ERC-4626の関数と機能: {#body} ### メソッド {#methods} @@ -46,7 +62,7 @@ function totalAssets() public view returns (uint256) function convertToShares(uint256 assets) public view returns (uint256 shares) ``` -この関数は、当該ボールトに提供された`assets`の量に対して交換される`shares`の量を返します。 +この関数は、提供された`assets`の量に対して、ボールトによって交換される`shares`の量を返します。 #### convertToAssets {#convertoassets} @@ -54,7 +70,7 @@ function convertToShares(uint256 assets) public view returns (uint256 shares) function convertToAssets(uint256 shares) public view returns (uint256 assets) ``` -この関数は、当該ボールトに提供された`shares`の量に対して交換される`assets`の量を返します。 +この関数は、提供された`shares`の量に対して、ボールトによって交換される`assets`の量を返します。 #### maxDeposit {#maxdeposit} @@ -62,7 +78,7 @@ function convertToAssets(uint256 shares) public view returns (uint256 assets) function maxDeposit(address receiver) public view returns (uint256 maxAssets) ``` -この関数は、`receiver`が1回の[`deposit`](#deposit)呼び出しで入金できる原資産の上限を返します。 +この関数は、`receiver`にシェアをミントする1回の[`deposit`](#deposit)呼び出しで預け入れできる、原資産の最大量を返します。 #### previewDeposit {#previewdeposit} @@ -72,13 +88,13 @@ function previewDeposit(uint256 assets) public view returns (uint256 shares) この関数は、入金が現在のブロックに対してどのような影響をもたらすかをシミュレーションします。 -#### 入金 {#deposit} +#### deposit {#deposit} ```solidity function deposit(uint256 assets, address receiver) public returns (uint256 shares) ``` -この関数は、原資産トークンの`assets`をボールトに入金し、受信者に`shares`の所有権を付与します。 +この関数は、`assets`量の原資産トークンをボールトに預け入れ、`receiver`に`shares`の所有権を付与します。 #### maxMint {#maxmint} @@ -86,7 +102,7 @@ function deposit(uint256 assets, address receiver) public returns (uint256 share function maxMint(address receiver) public view returns (uint256 maxShares) ``` -この関数は、`receiver`による1回の[`mint`](#mint)の呼び出しにより、ミント可能なシェア数の上限を返します。 +この関数は、`receiver`にシェアをミントする1回の[`mint`](#mint)呼び出しでミントできる、シェアの最大量を返します。 #### previewMint {#previewmint} @@ -96,13 +112,13 @@ function previewMint(uint256 shares) public view returns (uint256 assets) この関数は、現在のブロックにおける当該ミントの影響をシミュレーションします。 -#### mint(ミント) {#mint} +#### mint {#mint} ```solidity function mint(uint256 shares, address receiver) public returns (uint256 assets) ``` -この関数は、原資産トークンの`assets`を預け入れることで、`recevier`のボールトに対して特定の量の`shares`をミントします。 +この関数は、`assets`量の原資産トークンを預け入れることによって、`receiver`に正確に`shares`量のボールトシェアをミントします。 #### maxWithdraw {#maxwithdraw} @@ -110,7 +126,7 @@ function mint(uint256 shares, address receiver) public returns (uint256 assets) function maxWithdraw(address owner) public view returns (uint256 maxAssets) ``` -この関数は、1回の[`withdraw`](#withdraw)呼び出しにより、`owner`残高から引き出し可能な原資産アセットの上限を返します。 +この関数は、1回の[`withdraw`](#withdraw)呼び出しで`owner`の残高から引き出すことができる原資産の最大量を返します。 #### previewWithdraw {#previewwithdraw} @@ -120,13 +136,13 @@ function previewWithdraw(uint256 assets) public view returns (uint256 shares) この関数は、当該引き出しが現在のブロックに与える影響をシミュレーションします。 -#### 引き出し {#withdraw} +#### withdraw {#withdraw} ```solidity function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) ``` -この関数は、`owner`が所有する`shares`をバーンし、正確に一致した`assets`トークンをボールトから`receiver`に送信します。 +この関数は、`owner`から`shares`をバーンし、ボールトから`receiver`へ正確に`assets`量のトークンを送信します。 #### maxRedeem {#maxredeem} @@ -134,7 +150,7 @@ function withdraw(uint256 assets, address receiver, address owner) public return function maxRedeem(address owner) public view returns (uint256 maxShares) ``` -この関数は、[`redeem`](#redeem)の呼び出しにより、`owner`の残高から受け取ることができるシェアの上限を返します。 +この関数は、[`redeem`](#redeem)呼び出しを通じて`owner`の残高から償還できるシェアの最大量を返します。 #### previewRedeem {#previewredeem} @@ -150,7 +166,7 @@ function previewRedeem(uint256 shares) public view returns (uint256 assets) function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) ``` -この関数は、一定量の`shares`を`owner`から回収し、原資トークンの`assets`をボールトから`receiver`に送信します。 +この関数は、`owner`から特定の`shares`量を償還し、ボールトから`receiver`に`assets`量の原資産トークンを送信します。 #### totalSupply {#totalsupply} @@ -166,7 +182,7 @@ function totalSupply() public view returns (uint256) function balanceOf(address owner) public view returns (uint256) ``` -`owner`が現在ボールトで所有しているシェアの総数を返します。 +`owner`が現在保有しているボールトシェアの合計量を返します。 ### インターフェースのマップ {#mapOfTheInterface} @@ -176,7 +192,7 @@ function balanceOf(address owner) public view returns (uint256) #### 入金イベント -[`mint`](#mint)あるいは[`deposit`](#deposit)メソッドによりトークンをボールトに入金する際に、**必ず**発行しなければなりません。 +[`mint`](#mint)および[`deposit`](#deposit)メソッドを介してトークンがボールトに預け入れられる際に、**MUST**発行されなければなりません。 ```solidity event Deposit( @@ -187,11 +203,11 @@ event Deposit( ) ``` -このコードにおける`sender`とは、 `assets`を`shares`に交換して、`shares`を`owner`に転送するユーザーです。 +ここで`sender`は`assets`を`shares`に交換し、それらの`shares`を`owner`に転送したユーザーです。 #### 出金イベント -[`redeem`](#redeem) あるいは [`withdraw`](#withdraw)メソッドにより、預金者がボールトからシェアを引き出す際に、**必ず**発行しなければなりません。 +預金者が[`redeem`](#redeem)または[`withdraw`](#withdraw)メソッドでボールトからシェアを引き出す際に、**MUST**発行されなければなりません。 ```solidity event Withdraw( @@ -203,9 +219,9 @@ event Withdraw( ) ``` -このコードにおける`sender`とは、出金をトリガーし、`owner`が所有する`shares`を`assets`と交換するユーザーです。 `receiver`は、出金された`assets`を受け取ったユーザーです。 +ここで`sender`は、引き出しをトリガーし、`owner`が所有する`shares`を`assets`と交換したユーザーです。 `receiver`は、引き出された`assets`を受け取ったユーザーです。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [EIP-4626: トークン化ボールト規格](https://eips.ethereum.org/EIPS/eip-4626) +- [EIP-4626: トークン化されたボールト標準](https://eips.ethereum.org/EIPS/eip-4626) - [ERC-4626: GitHubリポジトリ](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-721/index.md index f6e83ac5b1f..50a48aca2c7 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/erc-721/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-721/index.md @@ -1,22 +1,24 @@ --- -title: ERC-721 非代替性トークン（NFT）規格 -description: +title: "ERC-721 非代替性トークン（NFT）規格" +description: "ERC-721は、イーサリアム上のユニークなデジタル資産を表現するための、非代替性トークン（NFT）の標準規格です。これについて学びましょう。" lang: ja --- ## はじめに {#introduction} -**非代替性トークン（NFT）とは** +**非代替性トークン(NFT)とは？** 非代替性トークン（NFT）は、固有の方法で、人や物を識別するために使われます。 この種類のトークンは、収集用のアイテム、アクセスキー、宝くじ、コンサートやスポーツ試合におけるシート番号付チケットなどを発行するプラットフォームに最も適しています。 この特殊なタイプのトークンはすばらしい可能性を秘めているため、専用の規格としてERC-721を策定しました。 -**ERC-721とは何か？** +**ERC-721とは？** -ERC-721は、NFTに対する標準規格です。つまり、この種類のトークンはそれぞれがユニークな存在であり、発行日、希少性、および外見などの点で、同一のスマートコントラクトで発行される他のトークンとは異なる値を持つことができます。 外見が違うとはどういう意味でしょう？ +ERC-721は、NFTに対する標準規格です。つまり、この種類のトークンはそれぞれがユニークな存在であり、発行日、希少性、および外見などの点で、同一のスマートコントラクトで発行される他のトークンとは異なる値を持つことができます。 +外見が違うとはどういう意味でしょう？ -はい！ すべてのNFTは、`tokenid`と呼ばれる`unit256`変数を持つため、ERC-721を伴うコントラクトでは、`contract adress, unit 256 tokenid`のペアはグローバルに固有でなければなりません。 その上で、各Dappでは、`tokenid`の入力から、ゾンビ、武器、スキル、あるいは可愛い子猫といったクールな画像を出力する「コンバーター」を搭載することができます。 +はい！ すべてのNFTは`tokenId`と呼ばれる`uint256`変数を持っています。そのため、どのERC-721コントラクトでも、ペアである +`contract address, uint256 tokenId`はグローバルに一意でなければなりません。 とはいえ、dappは`tokenId`を入力として使用し、ゾンビ、武器、スキル、あるいは素晴らしい子猫のようなクールな画像を出力する「コンバーター」を持つことができます。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} - [アカウント](/developers/docs/accounts/) - [スマートコントラクト](/developers/docs/smart-contracts/) @@ -26,11 +28,12 @@ ERC-721は、NFTに対する標準規格です。つまり、この種類のト ERC-721（Ethereum Request for Comments 721）は、ウィリアム・エントリケン氏、ディーター・シャーリー氏、ジェイコブ・エバンス氏、ナスタシア・サックス氏により2018年1月に提案された、スマートコントラクト内で非代替性トークン（NFT）を取り扱うためのAPIを実装するための規格です。 -この規格により、複数アカウント間のトークンの転送、アカウントにおける現在のトークン残高の取得、トークン所有者の取得、およびネットワーク上で供給されているトークン総数の取得といった機能が提供されます。 さらに、特定のアカウントが所有するトークン残高のうち、サードパーティのアカウントが転送可能な上限の設定を承認するなど、その他の機能も提供されています。 +この規格により、複数アカウント間のトークンの転送、アカウントにおける現在のトークン残高の取得、トークン所有者の取得、およびネットワーク上で供給されているトークン総数の取得といった機能が提供されます。 +さらに、特定のアカウントが所有するトークン残高のうち、サードパーティのアカウントが転送可能な上限の設定を承認するなど、その他の機能も提供されています。 以下のメソッドおよびイベントを実装したスマートコントラクトはERC-721非代替性トークン（NFT）コントラクトと呼ばれ、デプロイされると、イーサリアム上で作成されたトークンの状況を追跡する機能を提供します。 -[EIP-721](https://eips.ethereum.org/EIPS/eip-721)から引用： +[EIP-721](https://eips.ethereum.org/EIPS/eip-721) から引用： ### メソッド {#methods} @@ -54,13 +57,14 @@ ERC-721（Ethereum Request for Comments 721）は、ウィリアム・エント event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); ``` -### 実例： {#web3py-example} +### 実例 {#web3py-example} -イーサリアムネットワークにおけるERC-721トークンコントラクトを詳しく検討することで、ネットワークをシンプルにする上でこれらの規格がいかに重要であるかが理解できるでしょう。 ERC-721トークンを対象とするインターフェイスを開発するには、コントラクトのアブリケーション・バイナリ・インターフェイス（ABI）があれば十分です。 これからつまずかないように簡略化されたABIを使用した例をお見せします。 +イーサリアムネットワークにおけるERC-721トークンコントラクトを詳しく検討することで、ネットワークをシンプルにする上でこれらの規格がいかに重要であるかが理解できるでしょう。 +ERC-721トークンを対象とするインターフェイスを開発するには、コントラクトのアブリケーション・バイナリ・インターフェイス（ABI）があれば十分です。 理解しやすいように、以下では簡略化したABIを用いています。 -#### Web3.pyの実例： {#web3py-example} +#### Web3.pyの例 {#web3py-example} -最初に、 Pythonライブラリの[Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation)がインストールされていることを確認してください: +まず、[Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Pythonライブラリがインストールされていることを確認してください: ``` pip install web3 @@ -73,12 +77,12 @@ from web3._utils.events import get_event_data w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) -ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract +ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKittiesコントラクト -acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction +acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKittiesセールスオークション -# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract. -# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() +# これはERC-721 NFTコントラクトの簡易版コントラクト・アプリケーション・バイナリ・インターフェース(ABI)です。 +# balanceOf(address)、name()、ownerOf(tokenId)、symbol()、totalSupply()メソッドのみを公開します。 simplified_abi = [ { 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}], @@ -136,7 +140,7 @@ print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") pregnant_kitties = ck_contract.functions.pregnantKitties().call() print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") -# Using the Transfer Event ABI to get info about transferred Kitties. +# TransferイベントABIを使用して、送金されたKittiesに関する情報を取得します。 tx_event_abi = { 'anonymous': False, 'inputs': [ @@ -147,7 +151,7 @@ tx_event_abi = { 'type': 'event' } -# We need the event's signature to filter the logs +# ログをフィルタリングするためにイベントの署名が必要です。 event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() logs = w3.eth.get_logs({ @@ -156,25 +160,25 @@ logs = w3.eth.get_logs({ "topics": [event_signature] }) -# Notes: -# - Increase the number of blocks up from 120 if no Transfer event is returned. -# - If you didn't find any Transfer event you can also try to get a tokenId at: +# 注: +# - Transferイベントが返されない場合は、ブロック数を120から増やしてください。 +# - Transferイベントが見つからなかった場合は、次の場所でtokenIdを取得することもできます: # https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events -# Click to expand the event's logs and copy its "tokenId" argument +# イベントのログを展開して、その「tokenId」引数をコピーしてください recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] if recent_tx: - kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above + kitty_id = recent_tx[0]['tokenId'] # 上記のリンクから「tokenId」をここに貼り付けます is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") ``` CryptoKittiesのコントラクトには、標準的なイベント以外にもいくつか興味深いイベントが含まれています。 -特に、`Pregnant`と `Birth`のイベントについて見てみましょう。 +そのうちの2つ、`Pregnant`と`Birth`をチェックしてみましょう。 ```python -# 妊娠・出産イベントABIを利用して、新しいキティーの情報を得る。 +# PregnantおよびBirthイベントABIを使用して、新しいKittiesに関する情報を取得します。 ck_extra_events_abi = [ { 'anonymous': False, @@ -198,13 +202,13 @@ ck_extra_events_abi = [ 'type': 'event' }] -# We need the event's signature to filter the logs +# ログをフィルタリングするためにイベントの署名が必要です。 ck_event_signatures = [ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(), w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), ] -# Here is a Pregnant Event: +# これはPregnantイベントです: # - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog pregnant_logs = w3.eth.get_logs({ "fromBlock": w3.eth.block_number - 120, @@ -214,7 +218,7 @@ pregnant_logs = w3.eth.get_logs({ recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] -# Here is a Birth Event: +# これはBirthイベントです: # - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a birth_logs = w3.eth.get_logs({ "fromBlock": w3.eth.block_number - 120, @@ -225,20 +229,20 @@ birth_logs = w3.eth.get_logs({ recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs] ``` -## 人気が高いNFTの実例： {#popular-nfts} +## 人気のNFT {#popular-nfts} -- [イーサスキャンNFTトラッカー](https://etherscan.io/tokens-nft)は、イーサリアムにおけるNFTの取引量ランキングです。 -- [クリプトキティーズ](https://www.cryptokitties.co/)は、クリプトキティーと呼ばれる愛らしい生物を育て、収集するゲームです。 -- [ソラーレ](https://sorare.com/)は、グローバルなファンタジーフットボールゲームで、限定アイテムの収集、チームの管理、および試合を通じて賞品を獲得できます。 -- [ ENS（イーサリアムネームサービス）](https://ens.domains/)は、安全かつ分散型の方法により、ブロックチェーン内外のリソースにシンプルかつ人間が読み取り可能な名称を付与できるサービスです。 -- [POAP](https://poap.xyz)は、イベント参加や特定アクションの実行を行ったユーザーに対し、無料でNFTを提供できます。 POAPは自由に作成し、配布できます。 -- [アンストッパブル・ドメインズ](https://unstoppabledomains.com/)は、 サンフランシスコに本社を置く企業で、ブロックチェーン上のドメイン作成業務を行っています。 ブロックチェーン上のドメインは、暗号通貨のアドレスを人間が読み取り可能な名称に置き換えるもので、ウェブサイトに検閲耐性を持たせるために使用できます。 -- [ゴッズ・アンチェインド・カード](https://godsunchained.com/)は、イーサリアムブロックチェーン上のTCGで、NFTを使ってゲーム内アセットに真の所有権を提供しています。 -- [ボアード・エイプ・ヨット・クラブ](https://boredapeyachtclub.com)は、10,000個の固有NFTのコレクションであると同時にいわゆるレアな美術作品であり、同クラブの会員証であるトークンでもあります。会員は、初回特典に加えて、コミュニティ活動を行うことでより多くの特典を受け取ることができます。 +- [Etherscan NFTトラッカー](https://etherscan.io/nft-top-contracts)は、送金量別にイーサリアムのトップNFTをリストアップします。 +- [CryptoKitties](https://www.cryptokitties.co/)は、繁殖可能で、収集可能で、そしてとても愛らしい、私たちがCryptoKittiesと呼ぶ生き物を中心としたゲームです。 +- [Sorare](https://sorare.com/)は、限定版のコレクティブルを収集し、チームを管理し、賞品を獲得するために競い合うグローバルなファンタジーフットボールゲームです。 +- [イーサリアム・ネーム・サービス(ENS)](https://ens.domains/)は、安全かつ分散型の方法により、ブロックチェーン内外のリソースにシンプルかつ人間が読み取り可能な名前を使用してアドレスを付与します。 +- [POAP](https://poap.xyz)は、イベントに参加したり、特定のアクションを完了した人々に無料のNFTを配布します。 POAPは自由に作成し、配布できます。 +- [Unstoppable Domains](https://unstoppabledomains.com/)は、サンフランシスコを拠点とし、ブロックチェーン上にドメインを構築している会社です。 ブロックチェーンドメインは、暗号通貨アドレスを人間が読める名前に置き換え、検閲耐性のあるウェブサイトを可能にするために使用できます。 +- [Gods Unchained Cards](https://godsunchained.com/)はイーサリアムブロックチェーン上のトレーディングカードゲーム(TCG)で、NFTを使用してゲーム内アセットに真の所有権をもたらします。 +- [Bored Ape Yacht Club](https://boredapeyachtclub.com)は10,000個のユニークなNFTのコレクションで、証明可能な希少なアート作品であると同時に、クラブへの会員トークンとしても機能し、コミュニティの取り組みの結果として時間とともに増える会員特典や利益を提供します。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [EIP-721：ERC-721 非代替性トークン（NFT）規格](https://eips.ethereum.org/EIPS/eip-721) -- [OpenZeppelin - ERC-721のドキュメンテーション](https://docs.openzeppelin.com/contracts/3.x/erc721) -- [OpenZeppelin - ERC-721の実装](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) -- [AlchemyのNFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) +- [EIP-721: ERC-721 非代替性トークン標準](https://eips.ethereum.org/EIPS/eip-721) +- [OpenZeppelin - ERC-721ドキュメント](https://docs.openzeppelin.com/contracts/3.x/erc721) +- [OpenZeppelin - ERC-721実装](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-777/index.md index 3045cc8bd47..4258ae77977 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/erc-777/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-777/index.md @@ -1,45 +1,45 @@ --- -title: ERC-777 トークン規格 -description: ERC-777について学びましょう。フック機能を備えた改良型の代替可能トークン規格ですが、セキュリティの観点からはERC-20の使用が推奨されています。 +title: "ERC-777 トークン規格" +description: "フック機能を備え、改良された代替性トークン標準であるERC-777について学びます。ただし、セキュリティ上の理由からERC-20の使用が推奨されています。" lang: ja --- ## 警告 {#warning} -**ERC-777は[様々な形式の攻撃に対して脆弱](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620)であるため、正しく実装することが困難です。代わりに[ERC-20](/developers/docs/standards/tokens/erc-20/)の使用を推奨します。** このページは歴史的なアーカイブとして残されています。 +**ERC-777は[さまざまな形態の攻撃に対する脆弱性](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620)があるため、適切に実装することが困難です。 代わりに[ERC-20](/developers/docs/standards/tokens/erc-20/)を使用することが推奨されます。**このページは、歴史的なアーカイブとして残されています。 ## はじめに {#introduction} -ERC-777は、既存の[ERC-20](/developers/docs/standards/tokens/erc-20/)規格を改善した代替可能トークン規格です。 +ERC-777は、既存の[ERC-20](/developers/docs/standards/tokens/erc-20/)標準を改良した代替性トークン標準です。 ## 前提条件 {#prerequisites} -このページをより良く理解するために、まず[ERC-20](/developers/docs/standards/tokens/erc-20/)について読むことをお勧めします。 +このページをよりよく理解するために、まず[ERC-20](/developers/docs/standards/tokens/erc-20/)についてお読みになることをお勧めします。 -## ERC-777はERC-20に対してどのような改善を提案していますか？ {#-erc-777-vs-erc-20} +## ERC-777は、ERC-20に対してどのような改善を提案しているか？ {#-erc-777-vs-erc-20} -ERC-777はERC-20に対して以下の改善を提供します。 +ERC-777は、ERC-20に対して以下の改善を提案します。 ### フック {#hooks} -フックは、スマートコントラクトのコードで記述された関数です。フックは、コントラクトを通じてトークンが送信または受信されるときに呼び出されます。これにより、スマートコントラクトは入出金されるトークンに反応することができます。 +フックとは、スマートコントラクトのコードで記述された関数です。 フックは、コントラクトによりトークンが送受信される際に呼び出されます。 これにより、スマートコントラクトはトークンの受信／送信に対応できるようになります。 -フックは[ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)規格を使用して登録および検出されます。 +フックは、[ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)標準を使用して登録・検出されます。 -#### フックが優れている理由 {#why-are-hooks-great} +#### フックの利点： {#why-are-hooks-great} -1. フックを使用すると、トークンをコントラクトに送信し、1回のトランザクションでコントラクトに通知することができます。一方、[ERC-20](https://eips.ethereum.org/EIPS/eip-20)では、これを実現するために二重呼び出し（`approve`/`transferFrom`）が必要です。 -2. フックを登録していないコントラクトは、ERC-777と互換性がありません。受信コントラクトがフックを登録していない場合、送信コントラクトはトランザクションを中止します。これにより、非ERC-777スマートコントラクトへの誤送信を防ぐことができます。 -3. フックはトランザクションを拒否することができます。 +1. この操作に二重呼び出し(`approve`/`transferFrom`)を必要とする[ERC-20](https://eips.ethereum.org/EIPS/eip-20)とは異なり、フックでは単一のトランザクションでコントラクトへのトークン送信とコントラクトへの通知が可能です。 +2. 登録フックを持たないコントラクトは、ERC-777を利用できません。 受信コントラクトがフックを登録していない場合、送信コントラクトはトランザクションを中止します。 これにより、ERC-777非互換のスマートコントラクトに対する誤転送を防ぐことができます。 +3. フックは、トランザクションを却下することができます。 -### 小数点 {#decimals} +### 小数点以下の桁数 {#decimals} -この規格は、ERC-20で生じた`decimals`に関する混乱も解決します。この明確化により、開発者の体験が向上します。 +この標準は、ERC-20で引き起こされた`decimals`をめぐる混乱も解決します。 この混乱を解消することで、デベロッパーの利用体験が向上します。 ### ERC-20との後方互換性 {#backwards-compatibility-with-erc-20} -ERC-777コントラクトは、ERC-20コントラクトであるかのように操作することができます。 +ERC-777コントラクトとの間は、ERC-20コントラクトに対する場合と同様のやりとりが可能です。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -[EIP-777：トークン規格](https://eips.ethereum.org/EIPS/eip-777) +[EIP-777: トークン標準](https://eips.ethereum.org/EIPS/eip-777) diff --git a/public/content/translations/ja/developers/docs/standards/tokens/index.md b/public/content/translations/ja/developers/docs/standards/tokens/index.md index 6c1e46c1b15..294753e9c03 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/index.md @@ -1,39 +1,41 @@ --- -title: トークン規格 -description: +title: "トークン規格" +description: "ERC-20、ERC-721、ERC-1155を含むイーサリアムのトークン標準について探求しましょう。これらの標準は、代替可能トークンおよび非代替性トークンに利用されます。" lang: ja incomplete: true --- ## はじめに {#introduction} -イーサリアムにおける開発規格の多くは、トークンのインターフェイスを対象としています。 これらの規格は、スマートコントラクトにコンポーザビリティを提供するため、新規プロジェクトで発行されたトークンも既存の分散型取引所で取り扱えるようになります。 +イーサリアムにおける開発規格の多くは、トークンのインターフェイスを対象としています。 これらの標準は、スマートコントラクトが構成可能であり続けることを保証するのに役立ちます。そのため、新しいプロジェクトがトークンを発行した際にも、既存の分散型取引所やアプリケーションとの互換性が維持されます。 -## 前提知識 {#prerequisites} +トークン標準は、イーサリアムエコシステム全体でトークンがどのように動作し、相互作用するかを定義します。 これにより、開発者は車輪の再発明をすることなく容易に構築でき、トークンがウォレット、取引所、DeFiプラットフォームとシームレスに連携することが保証されます。 ゲーミング、ガバナンス、その他のユースケースにかかわらず、これらの標準は一貫性をもたらし、イーサリアムの相互接続性を高めます。 -- [イーサリアム開発規格](/developers/docs/standards/) +## 前提条件 {#prerequisites} + +- [イーサリアム開発標準](/developers/docs/standards/) - [スマートコントラクト](/developers/docs/smart-contracts/) -## トークン標準 {#token-standards} +## トークン規格 {#token-standards} 以下では、イーサリアムにおける最も一般的なトークン規格を説明します: -- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 投票用やステーキング用のトークンあるいは仮想通貨など、代替性を持つ（相互に代替可能な）トークンを対象とする標準的なインターフェイスです。 +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - 投票トークン、ステーキングトークン、または仮想通貨のような、ファンジブル(代替可能)トークンのための標準インターフェイスです。 -### NFT規格 {#nft-standards} +### NFT標準 {#nft-standards} -- [ERC-721](/developers/docs/standards/tokens/erc-721/) - アートや楽曲のための証書など、非代替性トークン (NFT) を対象とする標準的なインタフェースです。 -- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - より効率的な取引や、トランザクションのバンドル化によるコスト軽減を実現できる規格です。 ユーティリティトークン（$BNBや$BATなど）および非代替性トークン（CryptoPunksなど）の両方の作成に使用できます。 +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - アート作品や歌の権利証のような、非代替性トークン(NFT)の標準インターフェイスです。 +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155は、より効率的な取引とトランザクションのバンドル化を可能にし、コストを節約します。 ユーティリティトークン（$BNBや$BATなど）および非代替性トークン（CryptoPunksなど）の両方の作成に使用できます。 -[ERC](https://eips.ethereum.org/erc)提案の全リスト +[ERC](https://eips.ethereum.org/erc)提案の全リスト。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ -## 関連トピック {#related-tutorials} +## 関連チュートリアル {#related-tutorials} -- [トークンの統合作業に関するチェックリスト](/developers/tutorials/token-integration-checklist/) _– トークンのやりとりを統合する際に検討すべき事項が列挙されています。_ -- [ERC20トークンを利用するスマートコントラクトを理解する](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- イーサリアムのテストネットワーク上ではじめてスマートコントラクトをデプロイする初心者向けの入門ガイドです。_ -- [SolidityのスマートコントラクトでERC20トークンを転送、承認する方法](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Solidity言語を用いてトークンのやりとりを行うスマートコントラクトを使用する方法について説明しています。_ -- [ERC721マーケットの実装に関するハウツーガイド](/developers/tutorials/how-to-implement-an-erc721-market/) _– 分散型の掲示板でトークン化アイテムを出品する方法について説明しています。_ +- [トークン統合チェックリスト](/developers/tutorials/token-integration-checklist/) _– トークンを扱う際に考慮すべき項目のチェックリストです。_ +- [ERC20トークンのスマートコントラクトを理解する](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– イーサリアムのテストネットワークに初めてのスマートコントラクトをデプロイするための入門ガイドです。_ +- [SolidityスマートコントラクトからのERC20トークンの転送と承認](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Solidity言語を使用して、スマートコントラクトでトークンとやり取りする方法です。_ +- [ERC721マーケットの実装[ハウツーガイド]](/developers/tutorials/how-to-implement-an-erc721-market/) _– 分散型掲示板でトークン化アイテムを出品する方法です。_ diff --git a/public/content/translations/ja/developers/docs/storage/index.md b/public/content/translations/ja/developers/docs/storage/index.md index 888db65221c..d9dce4f3fd1 100644 --- a/public/content/translations/ja/developers/docs/storage/index.md +++ b/public/content/translations/ja/developers/docs/storage/index.md @@ -1,12 +1,12 @@ --- -title: 分散型ストレージ -description: 分散型ストレージとは何であるか、さらに、分散型ストレージをDappに統合するために利用できるツールの概要 +title: "分散型ストレージ" +description: "分散型ストレージとは何であるか、さらに、分散型ストレージをDappに統合するために利用できるツールの概要" lang: ja --- 単一の企業ないしは組織に運営されている中央集権型サーバーとは異なり、分散型ストレージシステムは、データ全体の一部を保持するユーザーや事業者のピアツーピアネットワークで構成されます。これにより、耐障害性のあるファイルストレージ共有システムを構築することができます。 これらの分散型ストレージシステムは、ブロックチェーン上のアプリケーションやピアツーピアをベースとしたネットワークに取り入れることができます。 -イーサリアム自体を分散型ストレージシステムとして使用することができ、全てのスマートコントラクトのコードストレージがまさにそれにあてはまります。 しかしながら、イーサリアムは大量のデータの保存に適した設計にはなっていません。 チェーンは着実に大きくなっていっており、執筆時点でのイーサリアムチェーンの容量は、([クライアントによって異なりますが、](https://etherscan.io/chartsync/chaindefault))およそ500GB - 1TBにもなっています。ネットワーク上の全てのノードは、これだけのデータを保存できる必要があります。 チェーンのデータサイズが巨大になってしまった場合(たとえば5TB)、全てのノードが実行を続けることはとても現実的ではありません。 しかも、これほどのデータをメインネットにデプロイするために必要なコストは、[ガス](/developers/docs/gas)代のために法外なほどに高価なものとなります。 +イーサリアム自体を分散型ストレージシステムとして使用することができ、全てのスマートコントラクトのコードストレージがまさにそれにあてはまります。 しかしながら、イーサリアムは大量のデータの保存に適した設計にはなっていません。 チェーンは着実に増大していますが、本稿執筆時点ではイーサリアムチェーンは約500GB～1TB（[クライアントによって異なります](https://etherscan.io/chartsync/chaindefault)）あり、ネットワーク上のすべてのノードが全データを保存できる必要があります。 チェーンのデータサイズが巨大になってしまった場合(たとえば5TB)、全てのノードが実行を続けることはとても現実的ではありません。 また、これほどのデータをメインネットにデプロイするコストは、[ガス](/developers/docs/gas)代のため、法外に高額になります。 これらの制限のために、大量のデータを分散型の手法で保存するには異なるチェーンか方法が必要になります。 @@ -17,15 +17,15 @@ lang: ja - 分散性 - コンセンサスの方法 -## 永続化メカニズム/インセンティブ構造 {#persistence-mechanism} +## 永続化メカニズム / インセンティブ構造 {#persistence-mechanism} ### ブロックチェーンベース {#blockchain-based} データの一部を永続的に保存するためには、なんらかの永続化メカニズムを利用する必要があります。 たとえば、イーサリアムでは1つのノードを実行する際にチェーン全体で処理を行う必要があるという永続化メカニズムがあります。 新しいデータがチェーンの終わりに追加され、そのデータは増大を続けます。これに伴い、すべてのノードは埋め込まれたすべてのデータを複製する必要があります。 -これは、**ブロックチェーンベースの**永続性として知られています。 +これは **ブロックチェーンベース** の永続化として知られています。 -ブロックチェーンベースの永続性には、チェーンがあまりにも大きくなりすぎると、すべてのデータを維持・保存することが難しくなるという問題があります(例: [多くの資料](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/)がインターネットには40ゼタバイト以上のストレージ容量が必要だと見積もっています)。 +ブロックチェーンベースの永続性には、チェーンが巨大になりすぎてすべてのデータを現実的に維持・保存できなくなるという問題があります（例えば、[多くの情報源](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/)は、インターネットには40ゼタバイト以上のストレージ容量が必要だと見積もっています）。 ブロックチェーンには、なんらかの形でインセンティブを発生させる構造が必要です。 ブロックチェーンベースの永続化には、バリデータへの支払いというインセンティブがあります。 データがチェーンに追加されると、バリデータはそのデータを追加することで支払いを受けます。 @@ -36,14 +36,14 @@ lang: ja ### コントラクトベース {#contract-based} -**コントラクトベース**の永続性では、すべてのノードでデータを複製し永遠に保存することはできないということが分かります。そのため、代わりにコントラクトによる合意で維持しなければなりません。 これらの合意は、複数台のノード間で結ばれる、一定期間データを保持することを約束するものです。 データを保持するためには、コントラクトの期間が切れるたびに払い戻しまたは更新が行われなければなりません。 +**コントラクトベース**の永続性は、データはすべてのノードで複製されて永久に保存されるわけではなく、コントラクトの合意によって維持されなければならない、という考え方です。 これらの合意は、複数台のノード間で結ばれる、一定期間データを保持することを約束するものです。 データを保持するためには、コントラクトの期間が切れるたびに払い戻しまたは更新が行われなければなりません。 -ほとんどの場合、オンチェーンにすべてのデータを保存する代わりに、チェーン上でデータが保存されている場所のハッシュが保存されます。 こうすることで、すべてのデータを保持するためにチェーン全体を拡張する必要がなくなります。 +ほとんどの場合、すべてのデータをオンチェーンに保存する代わりに、データがチェーン上のどこにあるかを示すハッシュが保存されます。 こうすることで、すべてのデータを保持するためにチェーン全体を拡張する必要がなくなります。 コントラクトベースの永続性を持つプラットフォーム -- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/) -- [Skynet](https://siasky.net/) +- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin) +- [Skynet](https://sia.tech/) - [Storj](https://storj.io/) - [Züs](https://zus.network/) - [Crust Network](https://crust.network) @@ -52,20 +52,20 @@ lang: ja ### その他の考慮事項 {#additional-consideration} -IPFSは、ファイル、ウェブサイト、アプリケーション、データの保存とアクセスのための分散型システムです。 インセンティブスキームは組み込まれていませんが、上記のいずれかのコントラクトベースのインセンティブソリューションとともに、データの長期保持に使用できます。 IPFSでデータを保持するもう一つの方法は、ピンニングサービスというデータを「固定化」してくれるサービスと連携することです。 独自のIPFSノードを実行して自分のデータや他のユーザーのデータを無料で保持し、ネットワークに貢献することもできます。 +IPFSは、ファイル、ウェブサイト、アプリケーション、データの保存とアクセスのための分散型システムです。 インセンティブスキームは組み込まれていませんが、上記のいずれかのコントラクトベースのインセンティブソリューションとともに、データの長期保持に使用できます。 IPFSでデータを保存するもう一つの方法は、ピンニングサービスというデータを「固定化」してくれるサービスと連携することです。 独自のIPFSノードを実行して自分のデータや他のユーザーのデータを無料で保持し、ネットワークに貢献することもできます。 -- [IPFS(ピアツーピア分散ファイルシステム)](https://docs.ipfs.io/concepts/what-is-ipfs/) -- [Pinata](https://www.pinata.cloud/)_(IPFSピンニングサービス)_ -- [web3.storage](https://web3.storage/)_(IPFS/Filecoinピンニングサービス)_ -- [Infura](https://infura.io/product/ipfs)_(IPFSピンニングサービス)_ -- [IPFS Scan](https://ipfs-scan.io) _(IPFSピンニングエクスプローラー)_ -- [4EVERLAND](https://www.4everland.org/)_(IPFSピンニングサービス)_ -- [Filebase](https://filebase.com)_(IPFSピンニングサービス)_ -- [Spheron Network](https://spheron.network/) _(IPFS/Filecoinピンニングサービス)_ +- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/) +- [Pinata](https://www.pinata.cloud/) _(IPFSピニングサービス)_ +- [web3.storage](https://web3.storage/) _(IPFS/Filecoinピニングサービス)_ +- [Infura](https://infura.io/product/ipfs) _(IPFSピニングサービス)_ +- [IPFS Scan](https://ipfs-scan.io) _(IPFSピニングエクスプローラー)_ +- [4EVERLAND](https://www.4everland.org/)_（IPFSピニングサービス）_ +- [Filebase](https://filebase.com) _(IPFSピニングサービス)_ +- [Spheron Network](https://spheron.network/) _(IPFS/Filecoinピニングサービス)_ SWARMは、ストレージインセンティブシステムとストレージレンタル価格オラクルを備えた分散型データストレージおよび分配テクノロジーです。 -## データの保持 {#data-retention} +## データ保持 {#data-retention} データを保持するには、データが保持されていることを確認するためのメカニズムをシステムに搭載する必要があります。 @@ -88,18 +88,17 @@ SWARMは、ストレージインセンティブシステムとストレージレ KYCなしの分散型ツール -- Züs(KYCなし版を実装) - Skynet - Arweave - Filecoin -- IPFS (ピアツーピア分散ファイルシステム) +- IPFS(ピアツーピア分散ファイルシステム) - イーサリアム - Crust Network - 4EVERLAND -### コンセンサスの方法 {#consensus} +### コンセンサス {#consensus} -これらのツールのほとんどは、独自のバージョンの[合意メカニズム](/developers/docs/consensus-mechanisms/)を持っていますが、通常は、[**プルーフ・オブ・ワーク(PoW)**](/developers/docs/consensus-mechanisms/pow/)または[**プルーフ・オブ・ステーク(PoS)**](/developers/docs/consensus-mechanisms/pos/)に基づいています。 +これらのツールのほとんどは、独自のバージョンの[合意メカニズム](/developers/docs/consensus-mechanisms/)を持っていますが、一般的には[**プルーフ・オブ・ワーク(PoW)**](/developers/docs/consensus-mechanisms/pow/)か[**プルーフ・オブ・ステーク(PoS)**](/developers/docs/consensus-mechanisms/pos/)のいずれかに基づいています。 プルーフ・オブ・ワーク方式: @@ -115,79 +114,79 @@ KYCなしの分散型ツール ## 関連ツール {#related-tools} -**IPFS - _IPFS (InterPlanetary File System)は、イーサリアムのための分散ストレージとファイル参照システムです。_** +**IPFS - _InterPlanetary File Systemは、イーサリアムのための分散型ストレージおよびファイル参照システムです。_** - [Ipfs.io](https://ipfs.io/) - [ドキュメント](https://docs.ipfs.io/) - [GitHub](https://github.com/ipfs/ipfs) -**Storj DCS - _デベロッパー向けの安全でプライベートなS3互換の分散型クラウド・オブジェクト・ストレージです。_** +**Storj DCS - _開発者向けの、安全でプライベートなS3互換の分散型クラウドオブジェクトストレージです。_** - [Storj.io](https://storj.io/) - [ドキュメント](https://docs.storj.io/) - [GitHub](https://github.com/storj/storj) -**Skynet - _Skynetは、分散型Web専用の分散型PoWチェーンです。_** +**Sia - _暗号技術を活用してトラストレスなクラウドストレージマーケットプレイスを作成し、買い手と売り手が直接取引できるようにします。_** -- [Skynet.net](https://siasky.net/) -- [ドキュメント](https://siasky.net/docs/) -- [GitHub](https://github.com/SkynetLabs/) +- [Skynet.net](https://sia.tech/) +- [ドキュメント](https://docs.sia.tech/) +- [GitHub](https://github.com/SiaFoundation/) -**Filecoin - _Filecoinは、IPFSの開発チームによって作成されたものです。 IPFSの理想形をベースとしたインセンティブレイヤーです。_** +**Filecoin - _FilecoinはIPFSの開発チームによって作成されました。 IPFSの理想形をベースとしたインセンティブレイヤーです。_** - [Filecoin.io](https://filecoin.io/) - [ドキュメント](https://docs.filecoin.io/) - [GitHub](https://github.com/filecoin-project/) -**Arweave - _Arweaveは、データを保存するための分散型ストレージ(dStorage)プラットフォームです。_** +**Arweave - _Arweaveは、データを保存するためのdStorageプラットフォームです。_** - [Arweave.org](https://www.arweave.org/) - [ドキュメント](https://docs.arweave.org/info/) - [Arweave](https://github.com/ArweaveTeam/arweave/) -**Züs - _Züsは、シャーディングとブロバーを備えたプルーフ・オブ・ステークの分散型ストレージ(dStorage)プラットフォームです。_** +**Züs - _Züsは、シャーディングとブロバーを備えたプルーフ・オブ・ステークのdStorageプラットフォームです。_** - [zus.network](https://zus.network/) -- [ドキュメント](https://0chaindocs.gitbook.io/zus-docs) +- [ドキュメント](https://docs.zus.network/zus-docs/) - [GitHub](https://github.com/0chain/) -**Crust Network - _Crustは、IPFSベースの分散型ストレージ(dStorage)プラットフォームです。_** +**Crust Network - _Crustは、IPFS上に構築されたdStorageプラットフォームです。_** - [Crust.network](https://crust.network) - [ドキュメント](https://wiki.crust.network) - [GitHub](https://github.com/crustio) -**Swarm - _イーサリアムWeb3スタックのための分散型ストレージプラットフォームとコンテンツ配信サービスです。_** +**Swarm - _イーサリアムのWeb3スタック向けの分散型ストレージプラットフォームおよびコンテンツ配信サービスです。_** - [EthSwarm.org](https://www.ethswarm.org/) -- [ドキュメント](https://docs.ethswarm.org/docs/) +- [ドキュメント](https://docs.ethswarm.org/) - [GitHub](https://github.com/ethersphere/) -**OrbitDB - _IPFSベースの分散型ピアツーピアのデータベースです。_** +**OrbitDB - _IPFSを基盤とした分散型ピアツーピアデータベースです。_** - [OrbitDB.org](https://orbitdb.org/) - [ドキュメント](https://github.com/orbitdb/field-manual/) - [GitHub](https://github.com/orbitdb/orbit-db/) -**Aleph.im - _分散型クラウドプロジェクト(データベース、ファイルストレージ、コンピューティング、DID)です。 オフチェーンとオンチェーンをうまく組み合わせたピアツーピア技術。 IPFSとマルチチェーン互換性。_** +**Aleph.im - _分散型クラウドプロジェクト(データベース、ファイルストレージ、コンピューティング、DID)です。 オフチェーンとオンチェーンをうまく組み合わせたピアツーピア技術。 IPFSおよびマルチチェーンに対応しています。_** -- [Aleph.im](https://aleph.im/) -- [ドキュメント](https://aleph.im/#/developers/) +- [Aleph.im](https://aleph.cloud/) +- [ドキュメント](https://docs.aleph.cloud/) - [GitHub](https://github.com/aleph-im/) -**Ceramic - _データリッチで魅力的なアプリケーションのためのユーザー制御IPFSデータベースストレージです。_** +**Ceramic - _データリッチで魅力的なアプリケーション向けの、ユーザー制御型IPFSデータベースストレージです。_** - [Ceramic.network](https://ceramic.network/) -- [ドキュメント](https://developers.ceramic.network/learn/welcome/) +- [ドキュメント](https://developers.ceramic.network/) - [GitHub](https://github.com/ceramicnetwork/js-ceramic/) -**Filebase - _S3互換の分散型ストレージと地理冗長なIPFSピンニングサービスです。 Filebase経由でIPFSにアップロードされたすべてのファイルは、世界中で3か所にレプリケーションされてFilebaseインフラストラクチャへ自動的にピンされます。_** +**Filebase - _S3互換の分散型ストレージと地理冗長なIPFSピニングサービスです。 Filebase経由でIPFSにアップロードされたすべてのファイルは、世界中で3か所にレプリケーションされてFilebaseインフラストラクチャへ自動的にピン留めされます。_** - [Filebase.com](https://filebase.com/) - [ドキュメント](https://docs.filebase.com/) - [GitHub](https://github.com/filebase) -**4EVERLAND - _ストレージ、コンピューティング、ネットワークのコア機能を統合するWeb 3.0クラウドコンピューティング・プラットフォームで、S3と互換性があり、IPFSやArweaveなどの分散型ストレージネットワークで同期データストレージを提供します。_** +**4EVERLAND - _ストレージ、コンピューティング、ネットワークのコア機能を統合するWeb 3.0クラウドコンピューティングプラットフォームで、S3と互換性があり、IPFSやArweaveなどの分散型ストレージネットワーク上で同期データストレージを提供します。_** - [4everland.org](https://www.4everland.org/) - [ドキュメント](https://docs.4everland.org/) @@ -199,18 +198,18 @@ KYCなしの分散型ツール - [ドキュメント](https://docs.kaleido.io/kaleido-services/ipfs/) - [GitHub](https://github.com/kaleido-io) -**Spheron Network - _Spheronは、プラットフォーム・アズ・ア・サービス(Paas)で、アプリケーションを最高のパフォーマンスを持つ分散型インフラでリリースすることを期待するdApp向けに設計されています。 革新的な、計算環境、分散型ストレージ、CDN、ウェブホスティングを提供しています。_** +**Spheron Network - _Spheronは、最高のパフォーマンスを持つ分散型インフラ上でアプリケーションを立ち上げたいdAppsのために設計された、プラットフォーム・アズ・ア・サービス(PaaS)です。 コンピューティング、分散型ストレージ、CDN、Webホスティングを標準で提供します。_** - [spheron.network](https://spheron.network/) - [ドキュメント](https://docs.spheron.network/) - [GitHub](https://github.com/spheronFdn) -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [分散型ストレージとは](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_ -- [分散型ストレージに関する5つの一般的な通念を覆す](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_ +- [分散型ストレージとは？](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_ +- [分散型ストレージに関する5つのよくある誤解を解く](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_ -_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_ +_Know of a community resource that helped you? Edit this page and add it!_ ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/transactions/index.md b/public/content/translations/ja/developers/docs/transactions/index.md index b009c1192fb..a12d0cf80f4 100644 --- a/public/content/translations/ja/developers/docs/transactions/index.md +++ b/public/content/translations/ja/developers/docs/transactions/index.md @@ -1,20 +1,21 @@ --- -title: トランザクション -description: イーサリアムトランザクションの概要 - 仕組み、データ構造、およびアプリケーションを介したトランザクションの送信方法 +title: "トランザクション" +description: "イーサリアムトランザクションの概要 - 仕組み、データ構造、およびアプリケーションを介したトランザクションの送信方法" lang: ja --- -トランザクションは、アカウントから暗号的に署名された命令のことを意味します。 アカウントはトランザクションを開始し、イーサリアムネットワークの状態を更新します。 最も単純なトランザクションは、あるアカウントから別のアカウントにETHを転送することです。 +イーサリアムにおける「トランザクション」とは、アカウントから暗号的に署名された一連の指示です。 アカウントはトランザクションを開始し、イーサリアムネットワークの状態を更新します。 最も単純なトランザクションは、あるアカウントから別のアカウントにETHを転送することです。 -## 前提知識 {#prerequisites} +## 前提条件 {#prerequisites} -このページの理解を深めるために、事前に[アカウント](/developers/docs/accounts/)と[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 +このページをより良く理解するために、まず[アカウント](/developers/docs/accounts/)と[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。 ## トランザクションとは {#whats-a-transaction} イーサリアムトランザクションとは、コントラクトではなく人間によって管理されたアカウントである外部所有アカウント(EOA)によって開始されたアクションを指します。 例えば、BobがAliceに1 ETHを送信するとしましょう。Bobのアカウントから1 ETH引き落とされ、Aliceのアカウントに振り込みされなければなりません。 この状態の変更はトランザクション内で実行されます。 -![状態の変化を起こすトランザクション図](./tx.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +![トランザクションによる状態変化を示す図](./tx.png) +_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)より引用_ EVMの状態を変更するトランザクションは、ネットワーク全体にブロードキャストされる必要があります。 すべてのノードは、EVMで実行されるトランザクションのリクエストをブロードキャストできます。 この後、バリデータがトランザクションを実行し、結果の状態の変更をネットワークに伝播します。 @@ -22,17 +23,17 @@ EVMの状態を変更するトランザクションは、ネットワーク全 送信されたトランザクションには次の情報が含まれます。 -- `from` – 送信者のアドレス。送信者はトランザクションに署名します。 コントラクトアカウントは、トランザクションを送信できません。そのため、外部所有のアカウントとなります。 +- `from` – 送信者のアドレス。トランザクションに署名します。 コントラクトアカウントはトランザクションを送信できないため、これは外部所有アカウントになります - `to` – 受信アドレス(外部所有アカウントの場合、トランザクションは値を転送します。 コントラクトアカウントの場合、トランザクションはコントラクトコードを実行します。) - `signature` – 送信者の識別子。 送信者の秘密鍵がトランザクションに署名し、送信者がこのトランザクションを承認したときに生成されます。 -- `nonce` - 連続的に増加するカウンターで、アカウントから送信されるトランザクション番号を示します。 -- `value` – 送信者から受信者に送金するETHの量(WEI単位: 1ETHは1e+18weiと等価)。 -- `input data` – 任意のデータを含むオプションのフィールド。 -- `gasLimit` – トランザクションで消費できるガスユニットの最大量。 [EVM](/developers/docs/evm/opcodes)が各計算ステップで必要なガス単位を指定します。 -- `maxPriorityFeePerGas` - バリデータへのチップとして含める際に消費されるガス代の上限。 +- `nonce` - アカウントからのトランザクション番号を示す、連続的にインクリメントされるカウンター +- `value` – 送信者から受信者へ転送するETHの量(WEI単位、1ETHは1e+18weiに相当します) +- `input data` – 任意のデータを含めるためのオプションフィールド +- `gasLimit` – トランザクションで消費できるガスユニットの最大量。 [EVM](/developers/docs/evm/opcodes)は、各計算ステップで必要とされるガスユニットを指定します +- `maxPriorityFeePerGas` - バリデータへのチップとして含めるために消費されるガスの最大価格 - `maxFeePerGas` - トランザクションに対して支払う用意があるガス単位あたりの最大手数料(`baseFeePerGas`と`maxPriorityFeePerGas`を含む) -ガスとは、バリデータのトランザクションに必要な計算を意味します。 ユーザーはこの計算に手数料を支払う必要があります。 `gasLimit`と`maxPriorityFeePerGas` はバリデータに支払われるトランザクションフィーの上限を決定します。 [ガスの詳細](/developers/docs/gas/) +ガスとは、バリデータのトランザクションに必要な計算を意味します。 ユーザーはこの計算に手数料を支払う必要があります。 `gasLimit`と`maxPriorityFeePerGas`は、バリデータに支払われる最大トランザクション手数料を決定します。 [ガスに関する詳細](/developers/docs/gas/)。 トランザクションオブジェクトは次のようになります。 @@ -52,7 +53,7 @@ EVMの状態を変更するトランザクションは、ネットワーク全 Gethのようなイーサリアムクライアントは、この署名プロセスを処理します。 -[JSON-RPC](/developers/docs/apis/json-rpc)呼び出しの例: +[JSON-RPC](/developers/docs/apis/json-rpc)コールの例： ```json { @@ -99,22 +100,26 @@ Gethのようなイーサリアムクライアントは、この署名プロセ } ``` -- `raw`は、[再帰長プレフィックス(RLP)](/developers/docs/data-structures-and-encoding/rlp)エンコード形式の署名されたトランザクション -- `tx`はJSON形式の署名されたトランザクション +- `raw`は、[再帰長プレフィックス(RLP)](/developers/docs/data-structures-and-encoding/rlp)でエンコードされた署名済みトランザクションです +- `tx`はJSON形式の署名済みトランザクションです 署名ハッシュでトランザクションが送信者から送信され、ネットワークに送信されたことを暗号的に証明することができます。 -### データ(data)フィールド {#the-data-field} +### データフィールド {#the-data-field} -大多数のトランザクションは、外部所有アカウント(EOA)からコントラクトにアクセスします。 コントラクトの多くはSolidityで書かれ、 [アプリケーションバイナリインターフェイス (ABI)](/glossary/#abi)に従ってデータフィールドを解釈します。 +大多数のトランザクションは、外部所有アカウントからコントラクトにアクセスします。 +ほとんどのコントラクトはSolidityで記述されており、[アプリケーションバイナリインターフェース(ABI)](/glossary/#abi)に従ってデータフィールドを解釈します。 -最初の4バイトは、関数の名前と引数のハッシュを使用して、どの関数を呼び出すかを指定します。 [このデータベース](https://www.4byte.directory/signatures/)を使用して、セレクターから関数を識別することができます。 +最初の4バイトは、関数の名前と引数のハッシュを使用して、どの関数を呼び出すかを指定します。 +[このデータベース](https://www.4byte.directory/signatures/)を使用して、セレクターから関数を特定できる場合があります。 -残りのコールデータ(calldata)は [ABI仕様でエンコードされた](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding)引数です。 +calldataの残りの部分は引数であり、[ABI仕様で規定されている通りにエンコード](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding)されています。 -例えば、[このトランザクション](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1)を見てみましょう。 **詳細をクリック**して、コールデータ (calldata)を表示します。 +例えば、[このトランザクション](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1)を見てみましょう。 +**詳細をクリック**してcalldataを表示します。 -関数セレクタは`0xa9059cbb`です。 [この署名を持つ既知の関数](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb)がいくつかあります。 この場合は、[コントラクトのソース コード](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code)がイーサリアムにアップロードされているため、`transfer(address,uint256)`関数であることがわかります。 +関数セレクターは`0xa9059cbb`です。 [このシグネチャを持つ既知の関数](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb)がいくつかあります。 +この場合、[コントラクトのソースコード](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code)がEtherscanにアップロードされているため、関数が`transfer(address,uint256)`であることがわかります。 残りのデータは以下の通りです。 @@ -123,9 +128,11 @@ Gethのようなイーサリアムクライアントは、この署名プロセ 000000000000000000000000000000000000000000000000000000003b0559f4 ``` -ABIの仕様により、整数値(20バイトの整数であるアドレスなど)が、ABIに32バイトのワードとして表示され、先頭はゼロで埋めらます。 これから、`to`のアドレスが [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279)であることが解ります。 `value`は、0x3b0559f4 = 990206452です。 +ABIの仕様により、整数値(20バイトの整数であるアドレスなど)が、ABIに32バイトのワードとして表示され、先頭はゼロで埋めらます。 +したがって、`to`アドレスは[`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279)であることがわかります。 +`value`は0x3b0559f4 = 990206452です。 -## トランザクションの形式 {#types-of-transactions} +## トランザクションの種類 {#types-of-transactions} イーサリアムでは、いくつかの異なる形式のトランザクションがあります。 @@ -133,11 +140,11 @@ ABIの仕様により、整数値(20バイトの整数であるアドレスな - コントラクト・デプロイ・トランザクション: 「to」のないトランザクションで、データフィールドがコントラクトコードに使用されているもの。 - コントラクトの実行: デプロイされたスマートコントラクトと相互作用するトランザクション。 この場合、「to」アドレスはスマートコントラクトアドレス。 -### ガス {#on-gas} +### ガスについて {#on-gas} -前述のように、トランザクションを実行するのに[ガス](/developers/docs/gas/)が必要です。 単純な送金トランザクションには、21,000ユニットのガスが必要です。 +前述のように、トランザクションの実行には[ガス](/developers/docs/gas/)がかかります。 単純な送金トランザクションには、21,000ユニットのガスが必要です。 -つまり、BobがAliceに1 ETHを`baseFeePerGas`が190 gwei、`maxPriorityFeePerGas`が10 gweiで送るためには、Bobは次のフィー(手数料)を支払う必要があります。 +したがって、BobがAliceに1 ETHを`baseFeePerGas` 190 gwei、`maxPriorityFeePerGas` 10 gweiで送信するには、Bobは次の手数料を支払う必要があります。 ``` (190 + 10) * 21000 = 4,200,000 gwei @@ -145,35 +152,36 @@ ABIの仕様により、整数値(20バイトの整数であるアドレスな 0.0042 ETH ``` -Bobのアカウントから、**-1.0042 ETH** (Aliceへの送金 1 ETH + ガス代 0.0042 ETH)引き落とされます。 +Bobのアカウントから**-1.0042 ETH**（Aliceへの1 ETH + ガス手数料0.0042 ETH）が引き落とされます。 -Aliceのアカウントに **+1.0 ETH**振り込み +Aliceのアカウントに**+1.0 ETH**が加算されます。 -ベースフィーは**-0.00399 ETH**を消費 +ベースフィーは**-0.00399 ETH**がバーン（焼却）されます。 -バリデータは **+0.000210 ETH** のチップを獲得 +バリデータはチップとして**+0.000210 ETH**を受け取ります。 - -![未使用ガスの返金図](./gas-tx.png) _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_ +![未使用のガスが返金される仕組みを示す図](./gas-tx.png) +_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)より引用_ トランザクションで使用されなかったガス代は、ユーザーアカウントに返金されます。 -### スマートコントラクトの操作 {#smart-contract-interactions} +### スマートコントラクトのインタラクション {#smart-contract-interactions} スマートコントラクトが関わるトランザクションにはガスが必要です。 -スマートコントラクトには、コントラクトの状態を変更しない[`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions)や[`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions)と呼ばれる関数が含まれる場合もあります。 そのため、EOAからこれらの関数を呼び出す際にはガスは不要です。 このシナリオに対応するRPCコールは[`eth_call`](/developers/docs/apis/json-rpc#eth_call)です。 +スマートコントラクトには、コントラクトの状態を変更しない[`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions)関数や[`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions)関数として知られる関数も含まれることがあります。 そのため、EOAからこれらの関数を呼び出す際にはガスは不要です。 このシナリオの基礎となるRPCコールは[`eth_call`](/developers/docs/apis/json-rpc#eth_call)です。 -ただし、`eth_call`を使用してアクセスする場合とは異なり、`view`や`pure`関数が内部的に (つまり、コントラクト自身や他のコントラクトから) 呼び出されることも多く、この場合にはガスがかかります。 +`eth_call`を使用してアクセスする場合とは異なり、これらの`view`または`pure`関数は内部的にも（つまり、コントラクト自体や別のコントラクトから）一般的に呼び出され、その場合はガスがかかります。 ## トランザクションのライフサイクル {#transaction-lifecycle} トランザクションが送信されると、次のことが実行されます。 -1. トランザクションハッシュが暗号化によって生成される: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017` +1. トランザクションハッシュは暗号学的に生成されます： + `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017` 2. 次に、トランザクションはネットワークにブロードキャストされ、保留している他のすべてのネットワークトランザクションで構成されるトランザクションプールに追加される。 3. バリデータはトランザクションを検証し、それを「成功」とみなすには、トランザクションをブロックに追加する必要がある。 -4. 時間と経過とともに、トランザクションを含むブロックは「正当 (justified)」にアップグレードされ、その後「ファイナライズ (finalized) 」になる。 これらのアップグレードにより、トランザクションの成功と非改ざん性がかなり確実になる。 一度ファイナライズされたブロックは、数十億ドルの費用がかかるネットワークレベルの攻撃によってのみでしか変更できない。 +4. 時間と経過とともに、トランザクションを含むブロックは「正当 (justified)」にアップグレードされ、その後「ファイナライズ (finalized) 」になる。 これらのアップグレードにより、トランザクションが成功し、決して変更されないことがより確実になります。 ブロックが「ファイナライズ」されると、数十億ドルものコストがかかるネットワークレベルの攻撃によってのみ変更可能となります。 ## ビジュアルデモ {#a-visual-demo} @@ -181,38 +189,40 @@ Aliceのアカウントに **+1.0 ETH**振り込み -## 型付トランザクションエンベロープ(Typed Transaction Envelope) {#typed-transaction-envelope} +## 型付きトランザクションエンベロープ {#typed-transaction-envelope} -イーサリアムは当初、トランザクション形式は1つのみでした。 各トランザクションには、ノンス (nonce)、ガス代、ガスリミット、toアドレス、値、データ、v、r、sがあります。 これらのフィールドは、以下のように[RLPエンコード](/developers/docs/data-structures-and-encoding/rlp/)されています。 +イーサリアムは当初、トランザクション形式は1つのみでした。 各トランザクションには、ノンス (nonce)、ガス代、ガスリミット、toアドレス、値、データ、v、r、sがあります。 これらのフィールドは[RLPエンコード](/developers/docs/data-structures-and-encoding/rlp/)されており、次のようになります： `RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` -イーサリアムは、アクセスリストや[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)などの新機能を、レガシーなトランザクション形式に影響を与えずに実装できるよう、複数の種類のトランザクションをサポートするように進化してきました。 +イーサリアムは、レガシーなトランザクション形式に影響を与えることなく、アクセスリストや[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)などの新機能を実装できるように、複数のトランザクションタイプをサポートするように進化してきました。 -[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)では、このトランザクション様式をサポートしています。 これらのトランザクションは、次のように解釈されます。 +これを可能にするのが[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)です。 これらのトランザクションは、次のように解釈されます。 `TransactionType || TransactionPayload` フィールドは次のように定義されます。 -- `TransactionType`は、0～0x7fの数字で、合計128種類のトランザクションタイプが可能 -- `TransactionPayload` - トランザクション型式で定義された任意のバイト配列 +- `TransactionType` - 0から0x7fまでの数値で、合計128種類のトランザクションタイプが可能です。 +- `TransactionPayload` - トランザクションタイプによって定義される任意のバイト配列。 -`TransactionType`の値に基づいて、トランザクションは次のように分類されます。 +`TransactionType`の値に基づいて、トランザクションは次のように分類されます： -1. **Type 0 (レガシー) トランザクション：** イーサリアムのローンチ以来使用されている元のトランザクション形式です。 これらには、[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)の動的ガス料金計算やスマートコントラクトのアクセスリストなどの機能は含まれていません。 レガシートランザクションには、[Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp)エンコーディングを使用した場合にバイト`0xf8`から始まる、シリアル化された形式で種類を示す特定のプレフィックスがありません。 これらのトランザクションのTransactionType値は`0x0`です。 +1. **タイプ0 (レガシー) トランザクション:** イーサリアムのローンチ以来使用されているオリジナルのトランザクション形式です。 これらには、動的なガス料金計算やスマートコントラクトのアクセスリストなど、[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)の機能は含まれていません。 レガシートランザクションには、[再帰長プレフィックス(RLP)](/developers/docs/data-structures-and-encoding/rlp)エンコーディングを使用した場合に`0xf8`バイトで始まる、シリアル化された形式でそのタイプを示す特定のプレフィックスがありません。 これらのトランザクションのTransactionType値は`0x0`です。 -2. **Type 1 トランザクション：** イーサリアムの[ベルリンアップグレード](/ethereum-forks/#berlin)の一環として[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930)で導入されたトランザクションです。これらのトランザクションには`accessList`パラメータが含まれています。 このリストは、トランザクションがアクセスする予定のアドレスとストレージキーを指定し、スマートコントラクトを含む複雑なトランザクションにおける[ガス](/developers/docs/gas/)コストを削減する可能性があります。 EIP-1559の料金市場の変更はType 1トランザクションには含まれていません。 Type 1トランザクションには`yParity`パラメータも含まれており、これは`0x0`または`0x1`のどちらかであり、secp256k1署名のy値のパリティを示します。 これらはバイト`0x01`で始まることで識別され、そのTransactionType値は`0x1`です。 +2. **タイプ1トランザクション:** イーサリアムの[ベルリン・アップグレード](/ethereum-forks/#berlin)の一環として[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930)で導入されたこれらのトランザクションには、`accessList`パラメータが含まれています。 このリストは、トランザクションがアクセスすると想定されるアドレスとストレージキーを指定しており、スマートコントラクトが関わる複雑なトランザクションの[ガス](/developers/docs/gas/)コストを削減できる可能性があります。 EIP-1559の料金市場の変更はType 1トランザクションには含まれていません。 タイプ1トランザクションには`yParity`パラメータも含まれており、これは`0x0`または`0x1`のいずれかを取ることができ、secp256k1署名のy値のパリティを示します。 これらはバイト`0x01`で始まり、そのTransactionType値は`0x1`です。 -3. **Type 2 トランザクション：** 一般的にEIP-1559トランザクションと呼ばれるこれらのトランザクションは、イーサリアムの[ロンドンアップグレード](/ethereum-forks/#london)における[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)により導入されました。 これらはイーサリアムネットワークで標準のトランザクションタイプとなっています。 これらのトランザクションは、トランザクションフィーをベースフィーとプライオリティフィーに分けることで予測可能性を向上させる新しい料金市場メカニズムを導入しています。 バイト`0x02`で始まり、`maxPriorityFeePerGas`や`maxFeePerGas`などのフィールドを含んでいます。 Type 2トランザクションは、その柔軟性と効率性から現在のデフォルトであり、特にネットワークが混雑している期間中に、ユーザーがトランザクションフィーをより予測可能に管理できる点で好まれています。 これらのトランザクションのTransactionType値は`0x2`です。 +3. **タイプ2トランザクション**は、一般にEIP-1559トランザクションと呼ばれ、イーサリアムの[ロンドン・アップグレード](/ethereum-forks/#london)で[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)によって導入されたトランザクションです。 これらはイーサリアムネットワークで標準のトランザクションタイプとなっています。 これらのトランザクションは、トランザクションフィーをベースフィーとプライオリティフィーに分けることで予測可能性を向上させる新しい料金市場メカニズムを導入しています。 これらはバイト`0x02`で始まり、`maxPriorityFeePerGas`や`maxFeePerGas`などのフィールドを含んでいます。 Type 2トランザクションは、その柔軟性と効率性から現在のデフォルトであり、特にネットワークが混雑している期間中に、ユーザーがトランザクションフィーをより予測可能に管理できる点で好まれています。 これらのトランザクションのTransactionType値は`0x2`です。 +4. **タイプ3(Blob)トランザクション**は、イーサリアムの[Dencunアップグレード](/ethereum-forks/#dencun)の一環として[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)で導入されました。 これらのトランザクションは、「blob」データ(Binary Large Objects)をより効率的に処理するように設計されており、特にレイヤー2ロールアップがより低いコストでイーサリアムネットワークにデータを投稿する方法を提供することで、恩恵をもたらします。 Blobトランザクションには、`blobVersionedHashes`、`maxFeePerBlobGas`、`blobGasPrice`などの追加フィールドが含まれます。 これらはバイト`0x03`で始まり、そのTransactionType値は`0x3`です。 Blobトランザクションは、イーサリアムのデータ可用性とスケーリング能力における大幅な改善を表しています。 +5. **タイプ4トランザクション**は、イーサリアムの[Pectraアップグレード](/roadmap/pectra/)の一環として[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)で導入されました。 これらのトランザクションは、アカウントの抽象化と前方互換性を持つように設計されています。 これにより、EOAは元の機能を損なうことなく、一時的にスマートコントラクトアカウントのように振る舞うことができます。 これらには`authorization_list`パラメータが含まれており、EOAが権限を委任するスマートコントラクトを指定します。 トランザクション後、EOAのコードフィールドには、委任されたスマートコントラクトのアドレスが格納されます。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [EIP-2718: 型付トランザクションエンベロープ(Typed Transaction Envelope)](https://eips.ethereum.org/EIPS/eip-2718) +- [EIP-2718：型付きトランザクションエンベロープ](https://eips.ethereum.org/EIPS/eip-2718) -_イーサリアムを学ぶために利用したコミュニティリソースはありますか？ もしあればページを編集して追加してください！_ +_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_ ## 関連トピック {#related-topics} diff --git a/public/content/translations/ja/developers/docs/web2-vs-web3/index.md b/public/content/translations/ja/developers/docs/web2-vs-web3/index.md index 37d754c1e0e..ef07c8f5a88 100644 --- a/public/content/translations/ja/developers/docs/web2-vs-web3/index.md +++ b/public/content/translations/ja/developers/docs/web2-vs-web3/index.md @@ -1,6 +1,6 @@ --- -title: Web2とWeb3の比較 -description: +title: "Web2とWeb3の比較" +description: "中央集権的なWeb2サービスと、イーサリアムブロックチェーン技術上に構築された分散型Web3アプリケーションを比較。" lang: ja --- @@ -17,17 +17,17 @@ Web2とは、多くの人たちが知っている現在のインターネット - 支払いはネイティブトークンであるイーサ(ETH) を介して行われる - イーサリアムは「チューリング完全」で、コンピュータ上で出来ることであればなんでもプログラミング可能 -## 実際の比較 {#practical-comparisons} +## 実践的な比較 {#practical-comparisons} -| Web2 | Web3 | -| ------------------------------------------------------ | ------------------------------------------------------ | -| Twitterはアカウントやツイートを検閲可能 | コントロールが分散化されているため、Web3のツイートは検閲不可 | +| Web2 | Web3 | +| ------------------------------------------------------ | ------------------------------------------------------------------------- | +| Twitterはアカウントやツイートを検閲可能 | コントロールが分散化されているため、Web3のツイートは検閲不可 | | 支払いサービス提供者が、特定の業種の支払いを許可しないことがある | Web3ネイティブの支払いサービスは、個人情報を必要とせず、業種も問わない(業種などを理由にブロックしない） | -| サーバがダウンすることがあり、Uberのようなギグエコノミーに従事する労働者の収入に影響を与える可能性がある | イーサリアム上にある数千個のコンピュータと分散的に接続しているため、Web3サーバはダウンタイムなし | +| サーバがダウンすることがあり、Uberのようなギグエコノミーに従事する労働者の収入に影響を与える可能性がある | イーサリアム上にある数千個のコンピュータと分散的に接続しているため、Web3サーバはダウンタイムなし | これは、すべてのサービスが分散型アプリ(Dapp)に移行する必要があると示唆しているものではなく、 Web2と Web3サービスの主な違いを示すための例示です。 -## Web3の制限 {#web3-limitations} +## Web3の制約事項 {#web3-limitations} Web3にはいくつかの制限があります。 @@ -36,27 +36,27 @@ Web3にはいくつかの制限があります。 - アクセシビリティ – 現在のWebブラウザはWeb3の統合が十分でないため、多くのユーザーにとってWeb3は利用しにくい。 - コスト - 成功を収めている分散型アプリ(Dapp)の多くは、コストがかかっているため、コードのごく一部のみをブロックチェーンに配置。 -## 中央集権型と分散型 {#centralization-vs-decentralization} +## 中央集権化と分散化 {#centralization-vs-decentralization} 下記の表は、「中央集権型」と「分散型デジタルネットワーク」の大まかなメリットとデメリットをまとめたものです。 | 中央集権型システム | 分散型システム | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | すべてのコンピュータが、一つの中心のコンピュータに接続しているため、情報の伝播が比較的早い。 | ネットワーク上の最も遠い参加者は、多くのエッジ分離れていることがある。 ネットワークの片側から送信された情報は、反対側に到達するまでに時間がかかることがある。 | -| 通常、高パフォーマンス(スループットが高く、消費される計算リソースが少ない)、実装が容易。 | 通常、低パフォーマンス(スループットが低く、高い計算リソースが消費)、実装が複雑。 | -| データが競合する場合、解決は明確で簡単(正しいデータは中央権威に存在)。 | 参加者が同期するデータの状態について矛盾を主張をする場合、解決にはしばしば複雑なプロトコルが必要。 | -| 単一障害点: 悪意のある実行者が、中央権威をターゲットにし、ネットワークをダウンさせるおそれがある。 | 単一障害点なし: 参加者の大部分が攻撃されたり障害を受けても、ネットワークは機能できる。 | +| 通常、高パフォーマンス(スループットが高く、消費される計算リソースが少ない)、実装が容易。 | 通常、低パフォーマンス(スループットが低く、高い計算リソースが消費)、実装が複雑。 | +| データが競合する場合、解決は明確で簡単(正しいデータは中央権威に存在)。 | 参加者が同期するデータの状態について矛盾を主張をする場合、解決にはしばしば複雑なプロトコルが必要。 | +| 単一障害点: 悪意のある実行者が、中央権威をターゲットにし、ネットワークをダウンさせるおそれがある。 | 単一障害点なし: 参加者の大部分が攻撃されたり障害を受けても、ネットワークは機能できる。 | | ネットワーク参加者間の調整は、はるかに容易であり、中央権威により処理。 中央権威は、ネットワーク参加者にアップグレード、プロトコルの更新など、ほぼ摩擦を生じさせず適用させることができる。 | ネットワークレベルの意思決定、プロトコルのアップグレードなど、単一のエージェントが最終的な意思決定を行わないため、調整はしばしば困難。 最悪の場合、プロトコルの変更について意見の相違がある場合、ネットワークが分裂することがある。 | | 中央権威はデータを検閲でき、ネットワークの一部を他のネットワークと相互作用しないように切断する可能性がある。 | 情報がネットワーク全体に伝播する多くの方法があるため、検閲は非常に困難。 | | ネットワークへの参加は中央権威により制御。 | 誰でもネットワークに参加でき、いわゆる「ゲートキーパー」は存在しない。 理想的には、参加費用は非常に低い。 | これらは、すべてのネットワークに当てはまるわけではないことにご留意ください。 さらに、実際にはネットワークの中央集権化・分散化の度合いはあいまいであり、完全に中央集権化されたネットワークや完全に分散化されたネットワークは存在しません。 -## 参考文献 {#further-reading} +## 参考リンク {#further-reading} -- [Web3とは](/web3/) - _ethereum.org_ +- [Web3とは？](/web3/) - _ethereum.org_ - [Web 3.0アプリケーションのアーキテクチャ](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ - [分散化の意味](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _2017年2月6日 - Vitalik Buterin_ -- [非中央集権化が重要な理由](https://medium.com/s/story/why-decentralization-matters-5e3f79f7638e) - _2018年2月18日 - Chris Dixon_ -- [Web 3.0 とは、またWeb 3.0が重要な理由](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _2019年12月31日 - Max Mersch and Richard Muirhead_ -- [Web3.0が必要な理由](https://medium.com/@gavofyork/why-we-need-web-3-0-5da4f2bf95ab) _2018年9月12日 - Gavin Wood_ +- [なぜ分散化が重要なのか](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) _2018年2月18日 - Chris Dixon_ +- [Web 3.0とは何か、そしてなぜそれが重要なのか](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _2019年12月31日 - Max MerschとRichard Muirhead_ +- [なぜWeb 3.0が必要なのか](https://gavofyork.medium.com/why-we-need-web-3-0-5da4f2bf95ab) _2018年9月12日 - Gavin Wood_ diff --git a/public/content/translations/ja/developers/docs/wrapped-eth/index.md b/public/content/translations/ja/developers/docs/wrapped-eth/index.md index f673075c406..2105b954004 100644 --- a/public/content/translations/ja/developers/docs/wrapped-eth/index.md +++ b/public/content/translations/ja/developers/docs/wrapped-eth/index.md @@ -1,12 +1,12 @@ --- -title: ラップドイーサ(WETH) とは -description: ラップドイーサ(WETH) — Ether (ETH) のERC-20互換ラッパーの紹介。 +title: "ラップドイーサ(WETH) とは" +description: "ラップドイーサ(WETH) — Ether (ETH) のERC-20互換ラッパーの紹介。" lang: ja --- # ラップドイーサ(WETH) {#intro-to-weth} -Ether (ETH) はイーサリアムのネイティブ暗号通貨です。 ステーキングや通貨としての使用、計算のためのガス料金の支払いなど、さまざまな目的で使用されます。 \*\*WETHはETHの機能を拡張したもので、多くのアプリケーションやイーサリアム上の他のデジタル資産である [ERC-20トークン](/glossary/#erc-20) \*\* で必要とされる追加機能を持っています。 ERC-20トークンと連携するためには、ETHも同じERC-20規格に従う必要があります。 +Ether (ETH) はイーサリアムのネイティブ暗号通貨です。 ステーキングや通貨としての使用、計算のためのガス料金の支払いなど、さまざまな目的で使用されます。 **WETHはETHの機能を拡張したもので、多くのアプリケーションやイーサリアム上の他のデジタル資産である [ERC-20トークン](/glossary/#erc-20) ** で必要とされる追加機能を持っています。 ERC-20トークンと連携するためには、ETHも同じERC-20規格に従う必要があります。 このギャップを埋めるために作られたのが、ラップドイーサ (WETH) です。 **WETHはスマートコントラクトであり、任意の量のETHを預けることで、ERC-20トークン標準に準拠した同量のWETH** を受け取ることができます。 WETHはETHを表現したもので、ネイティブアセットのETHとしてではなくERC-20トークンとして扱うことが可能です。 ただし、ガス料金の支払いにはネイティブのETHが必要なので、預ける際には一部を残しておくようにしましょう。 @@ -35,19 +35,16 @@ WETHをETHに戻すには、WETHスマートコントラクトを使用します ETHをWETHにラップする、またはWETHをETHにアンラップする際には、WETHコントラクトを使用してガス料金を支払います。 - WETHは、シンプルで実践テスト済みのスマートコントラクトに基づいているため、一般的に安全と考えられています。 WETHコントラクトは、イーサリアム上のスマートコントラクトにおける最高のセキュリティ基準である形式的検証も受けています。 - このページで説明している [WETHの標準的な実装](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) 以外にも、他のバリエーションが存在します。 これらはアプリデベロッパーによって作成されたカスタムトークンや、他のブロックチェーン上で発行されたバージョンであり、異なる動作をしたり、異なるセキュリティ特性を持つ可能性があります。 **どのWETH実装とやり取りしているかを確認するために、必ずトークン情報を再確認してください。** - @@ -55,7 +52,6 @@ WETHは、シンプルで実践テスト済みのスマートコントラクト - [Ethereum Mainnet](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) - [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) - [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006) - ## 参考リンク{#further-reading} diff --git a/public/content/translations/ja/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md b/public/content/translations/ja/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md index fc714c9ba56..dd40e850228 100644 --- a/public/content/translations/ja/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md +++ b/public/content/translations/ja/developers/tutorials/a-developers-guide-to-ethereum-part-one/index.md @@ -1,33 +1,32 @@ --- -title: Pythonデベロッパーのためのイーサリアム入門、パート1 -description: イーサリアム開発の概要。特に、プログラミング言語であるPythonの知識があるデベロッパーに役立つ情報 +title: "Pythonデベロッパーのためのイーサリアム入門、パート1" +description: "イーサリアム開発の概要。特に、プログラミング言語であるPythonの知識があるデベロッパーに役立つ情報" author: Marc Garreau lang: ja -tags: - - "python" - - "web3.py" +tags: [ "Python", "web3.py" ] skill: beginner published: 2020-09-08 source: Snake charmers sourceUrl: https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/ --- -これまで耳にしてきたイーサリアムの世界へ飛び込む準備はできましたか? この投稿では、ブロックチェーンの基礎について簡単に説明し、次に、シミュレートされたイーサリアムノードと対話(ブロックデータの読み取り、アカウント残高の確認、トランザクションの送信)する方法について説明します。 その過程で、アプリを構築する従来の方法とこの新しい分散型パラダイムの違いに焦点を当てます。 +これまで耳にしてきたイーサリアムの世界へ飛び込む準備はできましたか？ この投稿では、ブロックチェーンの基礎について簡単に説明し、次に、シミュレートされたイーサリアムノードとの対話（ブロックデータの読み取り、アカウント残高の確認、トランザクションの送信）の方法について説明します。 その過程で、アプリを構築する従来の方法とこの新しい分散型パラダイムの違いに焦点を当てます。 -## 前提条件(ソフト) {#soft-prerequisites} +## （ソフトな）前提条件 {#soft-prerequisites} -この投稿は、幅広いデベロッパーに参照していただきたいと考えています。 [ Pythonツール](/developers/docs/programming-languages/python/)を使用しますが、これらは概念を伝える手段にすぎませんので、Pythonデベロッパーでなくても問題ありません。 しかし、ここでは皆さんがPythonについての知識があることを前提に話を進めますので、すぐにイーサリアムに特化した部分の説明に移ります。 +この投稿は、幅広いデベロッパーに参照していただきたいと考えています。 [Pythonツール](/developers/docs/programming-languages/python/)を使用しますが、これらは概念を伝える手段にすぎませんので、Pythonデベロッパーでなくても問題ありません。 しかし、ここでは皆さんがすでに知っていることを前提に話を進めますので、すぐにイーサリアムに特化した部分の説明に移ります。 -前提知識: +前提知識： -- ターミナルを操作できる。 -- Pythonで数行のコードを書いたことがある。 -- Pythonバージョン3.6以降がマシンにインストールされている([仮想環境](https://realpython.com/effective-python-environment/#virtual-environments)の使用を強くお勧めします)。 -- Pythonのパッケージインストーラーである`pip`を使用したことがある。 これらのうちあてはまらないものがある方、あるいはこの記事にあるコードを実行することがない方でも十分に理解できる内容です。 +- ターミナルを操作できる、 +- Pythonで数行のコードを書いたことがある、 +- お使いのマシンにPythonバージョン3.6以降がインストールされていること（[仮想環境](https://realpython.com/effective-python-environment/#virtual-environments)の使用を強く推奨します）、そして +- Pythonのパッケージインストーラーである`pip`を使用したことがある。 + もしこれらのいずれかに当てはまらない場合や、この記事のコードを再現する予定がない場合でも、問題なく読み進めることができるでしょう。 -## ブロックチェーンについて {#blockchains-briefly} +## ブロックチェーンの概要 {#blockchains-briefly} -イーサリアムを説明する方法はたくさんありますが、その中心となるのはブロックチェーンです。 ブロックチェーンは一連のブロックで構成されています。まずはその説明から始めましょう。 簡単に言うと、イーサリアムブロックチェーンの各ブロックは、数値などのメタデータとトランザクションのリストにすぎません。 JSON形式では、次のようになります。 +イーサリアムを説明する方法はたくさんありますが、その中心となるのはブロックチェーンです。 ブロックチェーンは一連のブロックで構成されています。まずはその説明から始めましょう。 簡単に言うと、イーサリアムブロックチェーンの各ブロックは、いくつかのメタデータとトランザクションのリストにすぎません。 JSON形式では、次のようになります。 ```json { @@ -39,81 +38,85 @@ sourceUrl: https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt- } ``` -各[ブロック](/developers/docs/blocks/)は、その前のブロックを参照します。`parentHash`は、単に前のブロックのハッシュ値です。 +各[ブロック](/developers/docs/blocks/)は、その前のブロックへの参照を持ちます。`parentHash`は、単に前のブロックのハッシュです。 -注: イーサリアムは ハッシュ関数を定期的に使用して、固定サイズの値(ハッシュ)を生成します。 イーサリアムではハッシュ値が重要な役割を果たしますが、今のところは固有のIDと考えておくとよいでしょう。 +注: イーサリアムはハッシュ関数を定期的に使用して、固定サイズの値（「ハッシュ」）を生成します。 ハッシュはイーサリアムで重要な役割を果たしますが、今のところはユニークIDとして考えて差し支えありません。 -![ブロックチェーンと各ブロック内のデータを表す図](./blockchain-diagram.png) +![ブロックチェーンと各ブロック内のデータを描いた図](./blockchain-diagram.png) -_ブロックチェーンは基本的にはリンクリストであり、各ブロックは前のブロックを参照します。_ +_ブロックチェーンは本質的にリンクリストであり、各ブロックは前のブロックへの参照を持ちます。_ -このデータ構造は目新しいものではありませんが、ネットワークを管理するルール(つまり、ピアツーピアプロトコル)は目新しいものです。 中央集権型ではないため、ピアのネットワークは連携してネットワークを維持する必要がありますが、次のブロックに含めるトランザクションを決定する際には競い合うことになります。 例えば、友人に送金する場合、トランザクションをネットワークにブロードキャストして、そのトランザクションが次のブロックに含まれるのを待つ必要があります。 +このデータ構造は新しいものではありませんが、ネットワークを統制するルール（ピアツーピアプロトコル）は新しいものです。 中央機関は存在しません。ピアのネットワークは、ネットワークを維持するために協調しなければならず、次のブロックにどのトランザクションを含めるかを決定するために競争しなければなりません。 ですから、友人に送金したいときは、そのトランザクションをネットワークにブロードキャストし、それが次のブロックに含まれるのを待つ必要があります。 -ブロックチェーンにおいて、あるユーザーから別のユーザーに本当に送金されたのかを検証するための唯一の手段は、そのブロックチェーンに固有の(そのブロックチェーンで作成され管理される)通貨を使用することです。 イーサリアムでは、この通貨は「イーサ(ETH)」と呼ばれます。イーサリアムブロックチェーンには、アカウント残高に関する唯一の公式な記録が含まれています。 +ブロックチェーンがあるユーザーから別のユーザーへのお金が本当に送金されたことを検証する唯一の方法は、そのブロックチェーンに固有の（つまり、そのブロックチェーンによって作成され、管理される）通貨を使用することです。 イーサリアムでは、この通貨はイーサと呼ばれ、イーサリアムブロックチェーンにはアカウント残高の唯一の公式記録が含まれています。 ## 新しいパラダイム {#a-new-paradigm} -この新しい分散型技術スタックは、新しいデベロッパーツールを生み出しました。 このようなツールは多くのプログラミング言語に存在しますが、今回はPythonを例にとって説明します。 繰り返しになりますが、Python以外の言語をご使用の場合でも、内容を理解するのはそれほど難しいことではありません。 +この新しい分散型技術スタックは、新しいデベロッパーツールを生み出しました。 このようなツールは多くのプログラミング言語に存在しますが、今回はPythonを例にとって説明します。 繰り返しになりますが、Pythonがあなたの選んだ言語でなくても、ついていくのにそれほど問題はないはずです。 -イーサリアムと対話する必要があるPythonデベロッパーは、[Web3.py](https://web3py.readthedocs.io/)にアクセスしてください。 Web3.pyは、イーサリアムノードへの接続と、そのノードとのデータの送受信を簡単に行えるようにするライブラリです。注: 「イーサリアムノード」と「イーサリアムクライアント」は同じ意味で使用されます。 どちらもイーサリアムネットワークの参加者が実行するソフトウェアを指します。 このソフトウェアは、ブロックデータの読み取り、新しいブロックがチェーンに追加されたときの更新データの受信、新しいトランザクションのブロードキャストなどを行います。 技術的には、クライアントはソフトウェアを意味し、ノードはソフトウェアを実行しているコンピュータを意味します。 +イーサリアムと対話したいPythonデベロッパーは、[Web3.py](https://web3py.readthedocs.io/)に手を伸ばすことになるでしょう。 Web3.pyは、イーサリアムノードへの接続、およびノードとのデータの送受信を大幅に簡素化するライブラリです。 -[イーサリアムクライアント](/developers/docs/nodes-and-clients/) は、[プロセス間通信(IPC)](https://wikipedia.org/wiki/Inter-process_communication)、HTTP、またはWebSocketで接続するように設定できるため、Web3.pyでも同じ設定にする必要があります。 Web3.pyは、これらの接続オプションを**プロバイダー**として参照します。 Web3.pyインスタンスをノードに接続するために、3つのプロバイダーのいずれかを選択する必要があります。 +注: 「イーサリアムノード」と「イーサリアムクライアント」は同じ意味で使用されます。 いずれの場合も、イーサリアムネットワークの参加者が実行するソフトウェアを指します。 このソフトウェアは、ブロックデータを読み取り、新しいブロックがチェーンに追加されたときに更新情報を受信し、新しいトランザクションをブロードキャストするなどの機能を持ちます。 技術的には、クライアントはソフトウェアであり、ノードはソフトウェアを実行しているコンピュータです。 -![Web3.pyがIPCを使用してアプリケーションをイーサリアムノードに接続する方法を表す図](./web3py-and-nodes.png) +[イーサリアムクライアント](/developers/docs/nodes-and-clients/)は、[IPC](https://wikipedia.org/wiki/Inter-process_communication)、HTTP、またはWebsocketsで到達可能に設定できるため、Web3.pyはこの設定を反映させる必要があります。 Web3.pyはこれらの接続オプションを**プロバイダー**と呼びます。 Web3.pyインスタンスをノードにリンクさせるには、3つのプロバイダーの中から1つを選択します。 -_同じプロトコル(この図ではプロセス間通信(IPC))を介して通信するようにイーサリアムノードとWeb3.pyを設定します。_ +![web3.pyがIPCを使用してアプリケーションをイーサリアムノードに接続する方法を示す図](./web3py-and-nodes.png) -Web3.pyが正しく設定できたら、ブロックチェーンとの対話を開始できます。 参考までに、Web3.pyの使用例をいくつか示します。 +_この図のIPCのように、イーサリアムノードとWeb3.pyが同じプロトコルで通信するように設定します。_ + +Web3.pyが正しく設定されると、ブロックチェーンとの対話を開始できます。 今後のプレビューとして、Web3.pyの使用例をいくつか紹介します。 ```python -# read block data: +# ブロックデータを読み込む: w3.eth.get_block('latest') -# send a transaction: +# トランザクションを送信する: w3.eth.send_transaction({'from': ..., 'to': ..., 'value': ...}) ``` ## インストール {#installation} -このチュートリアルでは、Pythonインタプリタ内で作業します。 ディレクトリ、ファイル、クラス、関数は作成しません。注: 以下の例では、「$」で始まるコマンドはターミナルで実行することを意味しています。 (「$」を入力しないでください。「$」は単に行の始まりを意味します。) +このウォークスルーでは、Pythonインタプリタ内でのみ作業します。 ディレクトリ、ファイル、クラス、関数は作成しません。 + +注: 以下の例では、`$`で始まるコマンドはターミナルで実行するためのものです。 （`$`は入力しないでください。行の始まりを示しているだけです。） -まず、使いやすい環境となるように[IPython](https://ipython.org/)をインストールしてください。 IPythonには、数ある機能の中でも特に便利なタブ補完機能があり、Web3.pyでの補完の候補を簡単に確認できます。 +まず、探索のためのユーザーフレンドリーな環境として、[IPython](https://ipython.org/)をインストールします。 IPythonは、タブ補完などの機能を提供しており、Web3.pyで何が可能かを確認するのが非常に簡単になります。 ```bash pip install ipython ``` -Web3.pyは`web3`という名前で公開されています。 次のようにしてインストールします。 +Web3.pyは`web3`という名前で公開されています。 次のようにインストールします。 ```bash pip install web3 ``` -あと1つ操作が必要です。後でブロックチェーンのシミュレーションを行いますが、それにはさらに数個の依存関係が必要となります。 それらは以下のコマンドでインストールできます。 +もう一つ、後でブロックチェーンをシミュレートしますが、それにはさらにいくつかの依存関係が必要です。 それらは次のようにインストールできます。 ```bash pip install 'web3[tester]' ``` -これで準備完了です。 +これで準備完了です！ -注: `web3[tester]`パッケージは、Python 3.10.xxまで対応しています。 +注：`web3[tester]`パッケージは Python 3.10.xx まで動作します。 ## サンドボックスの起動 {#spin-up-a-sandbox} -ターミナルで`ipython`を実行し、新しいPython環境を開きます。 これは、`python`を実行するのと同じですが、より多くの機能を使用できます。 +ターミナルで`ipython`を実行して、新しいPython環境を開きます。 これは`python`の実行に似ていますが、より多くの追加機能が付属しています。 ```bash ipython ``` -実行しているPythonとIPythonのバージョンに関する情報が出力され、次のような入力待ちの状態になります。 +これにより、実行中のPythonとIPythonのバージョンに関する情報が出力され、入力を待つプロンプトが表示されます。 ```python In [1]: ``` -これは対話型のPythonシェルであり、 実質的には、さまざまなものを実行できるサンドボックスです。 ここまで完了したら、いよいよWeb3.pyをインポートします。 +現在、対話型のPythonシェルが表示されています。 基本的には、自由に試せるサンドボックスです。 ここまで来たら、Web3.pyをインポートしましょう。 ```python In [1]: from web3 import Web3 @@ -121,22 +124,22 @@ In [1]: from web3 import Web3 ## Web3モジュールの紹介 {#introducing-the-web3-module} -[Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api)モジュールは、イーサリアムへの入り口であるだけでなく、便利な関数も提供しています。 その一部をご紹介します。 +イーサリアムへのゲートウェイであることに加えて、[Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api)モジュールはいくつかの便利な機能を提供します。 いくつか見てみましょう。 -イーサリアムのアプリケーションでは、通常、通貨の単位を変換する必要があります。 Web3のモジュールには、この変換のためだけの[fromWei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei)や[toWei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei)のようなヘルパーメソッドがあります。 +イーサリアムアプリケーションでは、通貨の単位を変換する必要がよくあります。 Web3モジュールは、まさにこのためにいくつかのヘルパーメソッドを提供しています：[from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei)と[to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei)です。 -注: コンピュータは小数の計算処理が苦手です。 小数点以下を含む計算を避けるため、デベロッパーはしばしばドルをセントに換算して格納します。 例えば、価格が $5.99の商品は、599としてデータベースに保存されます。 +注：コンピュータは小数の計算が苦手なことで有名です。 これを回避するために、デベロッパーはドル額をセント単位で保存することがよくあります。 例えば、$5.99の価格のアイテムは、データベースに599として保存されることがあります。 -イーサ(ETH)でトランザクションを処理する場合も、同様のパターンが使用されます。 ただし、ETHの小数点は2桁ではなく、18桁です! ETHの最小単位はweiと呼ばれます。これが、トランザクションを送信するときに指定される値です。 +イーサでの取引を処理する際にも同様のパターンが使われます。 しかし、小数点以下2桁ではなく、イーサは18桁です！ イーサの最小単位はweiと呼ばれ、それがトランザクション送信時に指定される値です。 -1 ETH = 1000000000000000000 wei +1 ether = 1000000000000000000 wei -1 wei = 0.000000000000000001 ETH +1 wei = 0.000000000000000001 ether -好きな数字でweiとETH(ether)を変換してみてください。 なお、ETHとweiの間には、[さまざまな単位の名称があります](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations)。 その中でよく使われているのは、**gwei**です。これは基本的に手数料を意味します。 +いくつかの値をweiとの間で変換してみましょう。 イーサとweiの間には[多くの単位に名前がある](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations)ことに注意してください。 その中でよく知られているものの一つが**gwei**です。トランザクション手数料がgweiで表されることが多いためです。 ```python In [2]: Web3.to_wei(1, 'ether') @@ -146,49 +149,50 @@ In [3]: Web3.from_wei(500000000, 'gwei') Out[3]: Decimal('0.5') ``` -Web3モジュールのその他のユーティリティメソッドとしては、データ形式のコンバータ(例: [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)) 、アドレスヘルパー(例: [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)) 、ハッシュ関数(例: [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak))が挙げられます。 これらについては、この連載の後半で取り上げます。 利用可能なすべてのメソッドとプロパティを表示するには、`Web3`と入力して、 ピリオドの後にタブキーを2回押してください。これにより、IPythonの自動補完機能が起動します。 +Web3モジュールの他のユーティリティメソッドには、データ形式コンバータ（例：[`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)）、アドレスヘルパー（例：[`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)）、ハッシュ関数（例：[`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak)）などがあります。 これらの多くは、このシリーズの後半で取り上げます。 利用可能なすべてのメソッドとプロパティを表示するには、IPythonのオートコンプリート機能を利用して`Web3.`と入力し、 ピリオドの後にTabキーを2回押します。 -## チェーンとの通信 {#talk-to-the-chain} +## チェーンと対話する {#talk-to-the-chain} -便利な手法も素晴らしいですが、ブロックチェーンの話に移りましょう。 次のステップでは、Web3.pyがイーサリアムノードと通信できるように設定します。 ここでは、IPC、HTTP、またはWebSocketプロバイダーを使用することができます。 +便利なメソッドも素晴らしいですが、ブロックチェーンに移りましょう。 次のステップは、イーサリアムノードと通信するようにWeb3.pyを設定することです。 ここでは、IPC、HTTP、またはWebsocketプロバイダーを使用するオプションがあります。 -HTTPプロバイダーを使用した場合の完全なワークフローの例としては、次のようなものがあります(ここでは、この手順は実行しません)。 +この道筋はたどりませんが、HTTPプロバイダーを使用した完全なワークフローの例は次のようになります。 -- イーサリアムノード([Geth](https://geth.ethereum.org/)など)をダウンロードします。 -- 1つのターミナルでGethを起動し、ネットワークの同期を待ちます。 デフォルトのHTTPポートは`8545`ですが、設定可能です。 -- 次のように`localhost:8545`で、Web3.pyを使用してHTTP経由でノードに接続します。 `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))` +- [Geth](https://geth.ethereum.org/)などのイーサリアムノードをダウンロードします。 +- 一つのターミナルウィンドウでGethを開始し、ネットワークが同期するのを待ちます。 デフォルトのHTTPポートは`8545`ですが、設定可能です。 +- `localhost:8545`で、Web3.pyにHTTP経由でノードに接続するように指示します。 + `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))` - `w3`インスタンスを使用してノードと対話します。 -これは「実際に行われている」方法ですが、同期プロセスに時間がかかるため、開発環境でのみ使用する場合は不要です。 Web3.pyは、開発環境でのみ使用するデベロッパー向けに、第4のプロバイダーとして**EthereumTesterProvider**を提供しています。 このテストプロバイダーは、制約の少ない権限が適用された、偽の通貨でさまざまなことを試せるようになっている、シミュレートされたイーサリアムノードにつながります。 +これは「実際の」方法の一つですが、同期プロセスには数時間かかり、開発環境が欲しいだけの場合は不要です。 Web3.pyはこの目的のために4番目のプロバイダー、**EthereumTesterProvider**を公開しています。 このテスタープロバイダーは、緩和された権限と自由に使える偽の通貨を持つシミュレートされたイーサリアムノードにリンクします。 -![シミュレートされたイーサリアムノードにWeb3.pyアプリケーションをつなげるEthereumTesterProviderを表す図](./ethereumtesterprovider.png) +![EthereumTesterProviderがweb3.pyアプリケーションをシミュレートされたイーサリアムノードにリンクする図](./ethereumtesterprovider.png) -_EthereumTesterProviderはシミュレートされたノードに接続します。これは、簡単な開発環境で使用する場合に便利です。_ +_EthereumTesterProviderはシミュレートされたノードに接続し、迅速な開発環境に便利です。_ -このシミュレートされたノードは[eth-tester](https://github.com/ethereum/eth-tester)と呼ばれ、前述の`pip install web3[tester]`コマンドでインストールされています。 以下のコマンドで、テストプロバイダーを使用するようWeb3.pyを簡単に設定できます。 +そのシミュレートされたノードは[eth-tester](https://github.com/ethereum/eth-tester)と呼ばれ、`pip install web3[tester]`コマンドの一部としてインストールしました。 Web3.pyをこのテスタープロバイダーを使用するように設定するのは、次のように簡単です。 ```python In [4]: w3 = Web3(Web3.EthereumTesterProvider()) ``` -これで「チェーンサーフィン」をする準備ができました。 そのような呼び方をする人はいないと思いますが、 そう呼ぶことにしました。 さあ、クイックツアーを始めましょう。 +これでチェーンをサーフィンする準備ができました！ そんなことを言う人はいませんが。 私が今作った言葉です。 簡単なツアーを始めましょう。 ## クイックツアー {#the-quick-tour} -最初に、正常に接続できているかサニティチェックをします。 +まず最初に、サニティチェックです。 ```python In [5]: w3.is_connected() Out[5]: True ``` -テスタープロバイダーを使用しているため、このテストはあまり有用ではありません。失敗した場合は、`w3`変数をインスタンス化するときに入力ミスをした可能性があります。 内側の括弧、つまり`Web3.EthereumTesterProvider()`が含まれていることを再確認してください。 +テスタープロバイダーを使用しているので、これはあまり価値のあるテストではありませんが、もし失敗した場合、`w3`変数をインスタンス化する際に何かを間違って入力した可能性があります。 内側の括弧、つまり`Web3.EthereumTesterProvider()`を含めたか再確認してください。 -## ツアー #1: [アカウント](/developers/docs/accounts/) {#tour-stop-1-accounts} +## ツアーの立ち寄り先#1：[アカウント](/developers/docs/accounts/) {#tour-stop-1-accounts} -テスタープロバイダーでは便宜上、複数のアカウントが作成されており、テスト用のETHが入金されています。 +便宜上、テスタープロバイダーはいくつかのアカウントを作成し、テスト用のイーサをプリロードしています。 -まず、これらのアカウントの一覧を表示しましょう。 +まず、それらのアカウントのリストを見てみましょう。 ```python In [6]: w3.eth.accounts @@ -197,27 +201,27 @@ Out[6]: ['0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf', '0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69', ...] ``` -このコマンドを実行すると、`0x`で始まる10個の文字列のリストが表示されます。 それぞれが**パブリックアドレス**であり、これらはある意味、当座預金の口座番号のようなものです。 あなた宛てにETHを送金する人に、これらのアドレスを教えることになります。 +このコマンドを実行すると、`0x`で始まる10個の文字列のリストが表示されるはずです。 それぞれが**公開アドレス**であり、ある意味では当座預金口座の口座番号に似ています。 あなたにイーサを送りたい人にこのアドレスを提供します。 -前述のとおり、テスタープロバイダーでは、これらの各アカウントにテスト用のETHがあらかじめ入金されています。 では、最初のアカウントの残高を確認しましょう。 +前述のように、テスタープロバイダーはこれらの各アカウントにテスト用のイーサをプリロードしています。 最初のアカウントにいくら入っているか見てみましょう。 ```python In [7]: w3.eth.get_balance(w3.eth.accounts[0]) Out[7]: 1000000000000000000000000 ``` -この0の数を見てください! 満面の笑みで偽の銀行に駆け込む前に、前述した通貨の単位の説明を思い出してください。 ETHの値は、最小単位であるweiで表されます。 ETH(ether)に変換すると次のようになります。 +たくさんのゼロですね！ 偽の銀行に笑いながら行く前に、先ほどの通貨単位に関する教訓を思い出してください。 イーサの値は最小単位であるweiで表されます。 それをイーサに変換します。 ```python In [8]: w3.from_wei(1000000000000000000000000, 'ether') Out[8]: Decimal('1000000') ``` -テスト用とはいえ、100万ETHは依然としてすごい額です。 +100万テストイーサ――悪くないですね。 -## ツアー #2: ブロックデータ {#tour-stop-2-block-data} +## ツアーの立ち寄り先#2：ブロックデータ {#tour-stop-2-block-data} -このシミュレートされたブロックチェーンの状態を見てみましょう。 +このシミュレートされたブロックチェーンの状態を覗いてみましょう。 ```python In [9]: w3.eth.get_block('latest') @@ -230,15 +234,15 @@ Out[9]: AttributeDict({ }) ``` -ブロックに関する多くの情報が返されますが、いくつか注意すべき点があります。 +ブロックに関して多くの情報が返されますが、ここで指摘すべき点はいくつかあります。 -- テスタープロバイダーを設定した時期がいつであっても、ブロック番号はゼロになります。 実際のイーサリアムネットワーク(新しいブロックが12秒ごとに追加される)とは異なり、このシミュレーションは、作業を行うまで待機します。 -- まだ何も作業を行っていないため、同じ理由で、`transactions`は空のリストになります。 最初のブロックは**空のブロック**であり、チェーンを開始するためだけに使用されています。 -- `parentHash`は、単なる一連の空バイトである点に注意してください。 これは、**始まりのブロック**とも呼ばれる、チェーンの最初のブロックであることを意味します。 +- ブロック番号はゼロです――テスタープロバイダーをいつ設定したかに関係なく。 12秒ごとに新しいブロックを追加する実際のイーサリアムネットワークとは異なり、このシミュレーションは何か仕事を与えるまで待ちます。 +- `transactions`は空のリストです。同じ理由で、私たちはまだ何もしていません。 この最初のブロックは、チェーンを開始するための**空のブロック**です。 +- `parentHash`がただの空のバイトの束であることに注意してください。 これは、チェーンの最初のブロック、**ジェネシスブロック**としても知られていることを示しています。 -## ツアー #3: [トランザクション](/developers/docs/transactions/) {#tour-stop-3-transactions} +## ツアーの立ち寄り先#3：[トランザクション](/developers/docs/transactions/) {#tour-stop-3-transactions} -保留中のトランザクションが存在するまで、ゼロのブロックで止まっているので、トランザクションを作成してみましょう。 あるアカウントから別のアカウントに、テスト用のETH(ether)を少し送金します。 +保留中のトランザクションがあるまでブロックゼロで止まっているので、一つ与えてみましょう。 あるアカウントから別のアカウントに、数テストイーサを送金します。 ```python In [10]: tx_hash = w3.eth.send_transaction({ @@ -249,13 +253,16 @@ In [10]: tx_hash = w3.eth.send_transaction({ }) ``` -通常はここで、自分のトランザクションが新しいブロックに含まれるまで数秒間待つことになります。 全体のプロセスは次のようになります。 +これは通常、トランザクションが新しいブロックに含まれるのを数秒待つ時点です。 完全なプロセスは次のようになります。 -1. トランザクションを送信し、トランザクションハッシュを保持します。 トランザクションを含むブロックが作成され、ブロードキャストされるまで、トランザクションは「保留中(pending)」になります。 `tx_hash = w3.eth.send_transaction({ … })` -2. トランザクションがブロックに含まれるのを待ちます。 `w3.eth.wait_for_transaction_receipt(tx_hash)` -3. アプリケーションロジックが続行されます。 成功したトランザクションを表示します。 `w3.eth.get_transaction(tx_hash)` +1. トランザクションを送信し、トランザクションハッシュを保持します。 トランザクションを含むブロックが作成されブロードキャストされるまで、トランザクションは「保留中」です。 + `tx_hash = w3.eth.send_transaction({ … })` +2. トランザクションがブロックに含まれるのを待ちます： + `w3.eth.wait_for_transaction_receipt(tx_hash)` +3. アプリケーションロジックを続行します。 成功したトランザクションを表示するには： + `w3.eth.get_transaction(tx_hash)` -このシミュレーション環境では、トランザクションが新しいブロックに瞬時に追加されるので、そのトランザクションをすぐに確認できます。 +私たちのシミュレートされた環境は、トランザクションを新しいブロックに即座に追加するため、すぐにトランザクションを表示できます。 ```python In [11]: w3.eth.get_transaction(tx_hash) @@ -270,9 +277,9 @@ Out[11]: AttributeDict({ }) ``` -`from`、`to`、`value`の各フィールドは、`send_transaction`呼び出し時の入力と一致しなければなりません。 このトランザクションが、ブロック番号1の最初のトランザクション(`'transactionIndex': 0`)として含まれていることを確認できることも心強い点です。 +ここには見慣れた詳細がいくつかあります。`from`、`to`、`value`フィールドは、`send_transaction`呼び出しの入力と一致するはずです。 もう一つの安心できる点は、このトランザクションがブロック番号1内の最初のトランザクション（`'transactionIndex': 0`）として含まれていることです。 -さらに、関係する2つのアカウントの残高を確認することで、このトランザクションが成功していることを簡単に検証できます。 1つ目のアカウントから2つ目のアカウントへ、3 ETHが移動しているはずです。 +また、関与した2つのアカウントの残高を確認することで、このトランザクションの成功を簡単に確認できます。 3イーサが一方から他方へ移動したはずです。 ```python In [12]: w3.eth.get_balance(w3.eth.accounts[0]) @@ -282,13 +289,12 @@ In [13]: w3.eth.get_balance(w3.eth.accounts[1]) Out[13]: 1000003000000000000000000 ``` -2つ目のアカウントの残高は、 1,000,000 ETHから1,000,003 ETHに増えているので、正しいようです。 1つ目のアカウントはどうなったのでしょうか? 3 ETHより少し多い金額が失われたようです。 残念ながら、人生にはタダというものはなく、イーサリアムのパブリックネットワークを利用するには、そのサポート役であるピアに対価を支払う必要があります。 トランザクションを送信したアカウントから、少額のトランザクションフィーが差し引かれました。このフィーは、消費されたガスの量(ETH送金では21000単位のガス)にベースフィーを掛けたものです。ベースフィーは、ネットワークのアクティビティに加えて、ブロック内にトランザクションを含めるバリデータに送信されるチップによって異なります。 +後者は良さそうですね！ 残高は1,000,000イーサから1,000,003イーサに増えました。 しかし、最初のアカウントはどうなったのでしょうか？ 3イーサよりわずかに多く失われたようです。 残念ながら、人生に無料のものはありません。イーサリアムのパブリックネットワークを使用するには、その支援的な役割に対してピアに補償する必要があります。 トランザクションを送信したアカウントから少額のトランザクション手数料が差し引かれました。この手数料は、消費されたガスの量（ETH転送の場合は21000単位のガス）に、ネットワークのアクティビティに応じて変動するベースフィーと、トランザクションをブロックに含めるバリデータへのチップを加えたものを掛けたものです。 -[ガスの詳細](/developers/docs/gas/#post-london) +[ガス](/developers/docs/gas/#post-london)についての詳細 -注: パブリックネットワークにおいてトランザクションフィーは、ネットワークの需要やどれだけ迅速にトランザクションを処理する必要があるのかによって変動します。 フィー(手数料)の計算方法の内訳に興味がある場合は、 -ブロックに含まれるトランザクションの仕組みに関する以前の投稿をご覧ください。 +注：パブリックネットワークでは、トランザクション手数料はネットワークの需要とトランザクションをどれだけ早く処理したいかに基づいて変動します。 手数料がどのように計算されるかの内訳に興味がある場合は、トランザクションがどのようにブロックに含まれるかについての私の以前の投稿を参照してください。 -## ちょっと一息 {#and-breathe} +## 一息つきましょう {#and-breathe} -しばらく続けたので、ここで一息つきたいところです。 イーサリアムの世界はまだまだ広く、この連載の第2回ではさらに深く掘り下げていきます。 今後のコンセプトは、実際のノードへの接続、スマートコントラクト、トークンです。 何かご質問があれば、 ぜひお聞かせください。 皆様からのご意見は、今後の活動に反映させていきます。 [Twitter](https://twitter.com/wolovim)でリクエストを受け付けています。 +しばらくこれに取り組んできたので、一休みするには良い場所のようです。 ウサギの穴はまだ続きます。このシリーズのパート2で探求を続けます。 今後のコンセプト：実際のノードへの接続、スマートコントラクト、トークン。 フォローアップの質問はありますか？ お知らせください！ あなたのフィードバックが、ここからどこへ向かうかに影響します。 [Twitter](https://twitter.com/wolovim)経由でリクエストを歓迎します。 diff --git a/public/content/translations/ja/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/ja/developers/tutorials/all-you-can-cache/index.md new file mode 100644 index 00000000000..e03556275ef --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/all-you-can-cache/index.md @@ -0,0 +1,866 @@ +--- +title: "キャッシュでできること" +description: "ロールアップのトランザクションをより安くするキャッシュコントラクトの作成と使い方を学びます。" +author: Ori Pomerantz +tags: [ "レイヤー2", "キャッシュ", "ストレージ" ] +skill: intermediate +published: 2022-09-15 +lang: ja +--- + +ロールアップを使うと、トランザクションのバイトあたりのコストは、ストレージスロットのコストよりもはるかに高くなってしまいます。 そのため、オンチェーンに可能な限り多くの情報をキャッシュするほうが合理的です。 + +この記事では、複数回使用される可能性のあるパラメータの値をキャッシュして、(初回以降では) はるかに少ないバイト数で使えるようにするキャッシュコントラクトの作成および使用方法を学びます。また、このキャッシュを使用するオフチェーンコードの書き方についても説明します。 + +記事をスキップしてソースコードだけを見たい場合は、[こちら](https://github.com/qbzzt/20220915-all-you-can-cache)をご覧ください。 開発スタックは[Foundry](https://getfoundry.sh/introduction/installation/)です。 + +## 全体設計 {#overall-design} + +わかりやすくするために、すべてのトランザクションのパラメータは`uint256`、32バイト長であると仮定します。 トランザクションを受け取ると、次のように各パラメータをパースします。 + +1. 先頭のバイトが`0xFF`の場合、次の32バイトをパラメータの値として取得し、キャッシュに書き込みます。 + +2. 先頭のバイトが`0xFE`の場合、次の32バイトをパラメータの値として取得しますが、キャッシュには書き込み_ません_。 + +3. その他の値の場合、上位4ビットを追加のバイト数として、下位4ビットをキャッシュキーの最上位ビットとして取得します。 以下に、いくつかの例を示します。 + + | calldataのバイト | キャッシュキー | + | :-------------- | -------: | + | 0x0F | 0x0F | + | 0x10,0x10 | 0x10 | + | 0x12,0xAC | 0x02AC | + | 0x2D,0xEA, 0xD6 | 0x0DEAD6 | + +## キャッシュ操作 {#cache-manipulation} + +キャッシュは[`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol)に実装されています。 一行ずつ見ていきましょう。 + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; + + +contract Cache { + + bytes1 public constant INTO_CACHE = 0xFF; + bytes1 public constant DONT_CACHE = 0xFE; +``` + +これらの定数は、すべての情報を提供し、それをキャッシュに書き込むかどうかの特殊なケースを解釈するために使用されます。 キャッシュへの書き込みには、以前は使用されていなかったストレージスロットに対して2回の[`SSTORE`](https://www.evm.codes/#55)操作が必要で、それぞれ22100ガスがかかるため、オプションとしています。 + +```solidity + + mapping(uint => uint) public val2key; +``` + +値とそのキーの間の[マッピング](https://www.geeksforgeeks.org/solidity/solidity-mappings/)です。 この情報は、トランザクションを送信する前に値をエンコードするために必要です。 + +```solidity + // 位置nにはキーn+1の値があります。なぜなら、 + // ゼロを「キャッシュにない」状態として保持する必要があるためです。 + uint[] public key2val; +``` + +キーを割り当て、簡単にするために順次行うため、キーから値へのマッピングには配列を使用できます。 + +```solidity + function cacheRead(uint _key) public view returns (uint) { + require(_key <= key2val.length, "初期化されていないキャッシュエントリを読み込んでいます"); + return key2val[_key-1]; + } // cacheRead +``` + +キャッシュから値を読み取ります。 + +```solidity + // 値がまだキャッシュにない場合に書き込む + // テストを機能させるためにのみpublicに設定 + function cacheWrite(uint _value) public returns (uint) { + // 値がすでにキャッシュにある場合は、現在のキーを返す + if (val2key[_value] != 0) { + return val2key[_value]; + } +``` + +同じ値をキャッシュに複数回入れる意味はありません。 値がすでに存在する場合は、既存のキーを返します。 + +```solidity + // 0xFEは特殊なケースであるため、キャッシュが保持できる + // 最大のキーは、0x0Dの後に15個の0xFFが続くものです。キャッシュ長がすでに + // その大きさになっている場合は失敗します。 + // 1 2 3 4 5 6 7 8 9 A B C D E F + require(key2val.length+1 < 0x0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, + "キャッシュオーバーフロー"); +``` + +これほど大きなキャッシュを得ることはないでしょう (約1.8\*1037エントリで、保存には約1027TBが必要です)。 しかし、私は["640kBあれば常に十分"](https://quoteinvestigator.com/2011/09/08/640k-enough/)という言葉を覚えているほどには年をとっています。 このテストは非常に安価です。 + +```solidity + // 次のキーを使用して値を書き込む + val2key[_value] = key2val.length+1; +``` + +逆引き参照 (値からキーへ) を追加します。 + +```solidity + key2val.push(_value); +``` + +順引き参照 (キーから値へ) を追加します。 値を順次割り当てるため、最後の配列値の後に追加するだけです。 + +```solidity + return key2val.length; + } // cacheWrite +``` + +新しい値が格納されているセルである`key2val`の新しい長さを返します。 + +```solidity + function _calldataVal(uint startByte, uint length) + private pure returns (uint) +``` + +この関数は、任意の長さ (最大32バイト、ワードサイズ) のcalldataから値を読み取ります。 + +```solidity + { + uint _retVal; + + require(length < 0x21, + "_calldataValの長さ制限は32バイトです"); + require(length + startByte <= msg.data.length, + "_calldataValがcalldatasizeを超えて読み取ろうとしています"); +``` + +この関数は内部関数であるため、コードの残りの部分が正しく書かれていれば、これらのテストは不要です。 しかし、大してコストがかからないので、あってもよいでしょう。 + +```solidity + assembly { + _retVal := calldataload(startByte) + } +``` + +このコードは[Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html)で書かれています。 calldataから32バイトの値を読み取ります。 `startByte+32`より前にcalldataが停止しても、EVMでは初期化されていない領域はゼロとみなされるため、これは機能します。 + +```solidity + _retVal = _retVal >> (256-length*8); +``` + +必ずしも32バイトの値が必要というわけではありません。 これにより、余分なバイトが取り除かれます。 + +```solidity + } // _calldataVal + + + // calldataから_fromByteを開始位置として単一のパラメータを読み取る + function _readParam(uint _fromByte) internal + returns (uint _nextByte, uint _parameterValue) + { +``` + +calldataから単一のパラメータを読み取ります。 パラメータは1バイトから33バイトの範囲になる可能性があるため、読み取った値だけでなく、次のバイトの位置も返す必要があることに注意してください。 + +```solidity + // 最初のバイトで残りの解釈方法がわかる + uint8 _firstByte; + + _firstByte = uint8(_calldataVal(_fromByte, 1)); +``` + +Solidityは、危険な可能性のある[暗黙の型変換](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions)を禁止することで、バグの数を減らそうとします。 ダウングレード、たとえば256ビットから8ビットへの変換は、明示的に行う必要があります。 + +```solidity + + // 値を読み取るが、キャッシュには書き込まない + if (_firstByte == uint8(DONT_CACHE)) + return(_fromByte+33, _calldataVal(_fromByte+1, 32)); + + // 値を読み取り、キャッシュに書き込む + if (_firstByte == uint8(INTO_CACHE)) { + uint _param = _calldataVal(_fromByte+1, 32); + cacheWrite(_param); + return(_fromByte+33, _param); + } + + // ここまで来たということは、キャッシュから読み取る必要があるということ + + // 読み取る追加バイト数 + uint8 _extraBytes = _firstByte / 16; +``` + +下位[ニブル](https://en.wikipedia.org/wiki/Nibble)を取り、それを他のバイトと組み合わせてキャッシュから値を読み取ります。 + +```solidity + uint _key = (uint256(_firstByte & 0x0F) << (8*_extraBytes)) + + _calldataVal(_fromByte+1, _extraBytes); + + return (_fromByte+_extraBytes+1, cacheRead(_key)); + + } // _readParam + + + // n個のパラメータを読み取る (関数は期待するパラメータ数を知っている) + function _readParams(uint _paramNum) internal returns (uint[] memory) { +``` + +パラメータ数はcalldata自体から取得できますが、私たちを呼び出す関数は期待するパラメータ数を知っています。 それらの関数に教えてもらう方が簡単です。 + +```solidity + // 読み取ったパラメータ + uint[] memory params = new uint[](_paramNum); + + // パラメータは4バイト目から始まります。それより前は関数シグネチャです + uint _atByte = 4; + + for(uint i=0; i<_paramNum; i++) { + (_atByte, params[i]) = _readParam(_atByte); + } +``` + +必要な数になるまでパラメータを読み取ります。 calldataの末尾を超えた場合、`_readParams`は呼び出しをリバートします。 + +```solidity + + return(params); + } // readParams + + // _readParamsのテストのため、4つのパラメータの読み取りをテストする + function fourParam() public + returns (uint256,uint256,uint256,uint256) + { + uint[] memory params; + params = _readParams(4); + return (params[0], params[1], params[2], params[3]); + } // fourParam +``` + +Foundryの大きな利点の1つは、Solidityでテストを書くことができる点です([下記の「キャッシュのテスト」を参照](#testing-the-cache))。 これにより、単体テストが非常に簡単になります。 これは4つのパラメータを読み取って返し、テストでそれらが正しいことを検証できるようにする関数です。 + +```solidity + // 値を取得し、それをエンコードするバイト列を返す (可能であればキャッシュを使用) + function encodeVal(uint _val) public view returns(bytes memory) { +``` + +`encodeVal`は、オフチェーンコードがキャッシュを使用するcalldataの作成を支援するために呼び出す関数です。 単一の値を受け取り、それをエンコードするバイト列を返します。 この関数は`view`なので、トランザクションを必要とせず、外部から呼び出してもガスはかかりません。 + +```solidity + uint _key = val2key[_val]; + + // 値はまだキャッシュにないので、追加する + if (_key == 0) + return bytes.concat(INTO_CACHE, bytes32(_val)); +``` + +[EVM](/developers/docs/evm/)では、初期化されていないストレージはすべてゼロであるとみなされます。 そのため、存在しない値のキーを探すと、ゼロが返されます。 その場合、それをエンコードするバイト列は`INTO_CACHE` (次回キャッシュされるように) となり、その後に実際の値が続きます。 + +```solidity + // キーが0x10未満の場合、単一バイトとして返す + if (_key < 0x10) + return bytes.concat(bytes1(uint8(_key))); +``` + +単一バイトが最も簡単です。 [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat)を使用して、`bytes`型を任意の長さのバイト配列に変換するだけです。 その名前にもかかわらず、引数が1つだけ提供された場合でも正常に動作します。 + +```solidity + // 2バイト値、0x1vvvとしてエンコード + if (_key < 0x1000) + return bytes.concat(bytes2(uint16(_key) | 0x1000)); +``` + +163未満のキーがある場合、それを2バイトで表現できます。 まず、256ビットの値である`_key`を16ビットの値に変換し、論理和を使用して最初のバイトに追加バイト数を加えます。 次に、それを`bytes`に変換できる`bytes2`の値に入れます。 + +```solidity + // 以降の行をループとして実行する賢い方法があるかもしれませんが、 + // これはview関数なので、プログラマの時間と + // 単純さを最適化しています。 + + if (_key < 16*256**2) + return bytes.concat(bytes3(uint24(_key) | (0x2 * 16 * 256**2))); + if (_key < 16*256**3) + return bytes.concat(bytes4(uint32(_key) | (0x3 * 16 * 256**3))); + . + . + . + if (_key < 16*256**14) + return bytes.concat(bytes15(uint120(_key) | (0xE * 16 * 256**14))); + if (_key < 16*256**15) + return bytes.concat(bytes16(uint128(_key) | (0xF * 16 * 256**15))); +``` + +その他の値 (3バイト、4バイトなど) は、フィールドサイズが異なるだけで、同じように処理されます。 + +```solidity + // ここに到達した場合、何かが間違っています。 + revert("encodeValのエラー、発生するはずがありません"); +``` + +ここに到達するということは、16\*25615以上のキーを取得したということです。 しかし、`cacheWrite`はキーを制限するため、14\*25616 (最初のバイトが0xFEとなり、`DONT_CACHE`のように見える) に達することさえありません。 しかし、将来のプログラマーがバグを混入させる場合に備えてテストを追加しても、大したコストはかかりません。 + +```solidity + } // encodeVal + +} // Cache +``` + +### キャッシュのテスト {#testing-the-cache} + +Foundryの利点の1つは、[Solidityでテストを書くことができる](https://getfoundry.sh/forge/tests/overview/)ことで、これにより単体テストが書きやすくなります。 `Cache`クラスのテストは[こちら](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol)にあります。 テストコードは繰り返しが多くなりがちなので、この記事では興味深い部分のみを説明します。 + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; + +import "forge-std/Test.sol"; + + +// consoleを使用するには、`forge test -vv`を実行する必要があります。 +import "forge-std/console.sol"; +``` + +これは、テストパッケージと`console.log`を使用するために必要な、単なる定型コードです。 + +```solidity +import "src/Cache.sol"; +``` + +テスト対象のコントラクトをインポートする必要があります。 + +```solidity +contract CacheTest is Test { + Cache cache; + + function setUp() public { + cache = new Cache(); + } +``` + +`setUp`関数は各テストの前に呼び出されます。 この場合、新しいキャッシュを作成するだけなので、テストが互いに影響することはありません。 + +```solidity + function testCaching() public { +``` + +テストは`test`で始まる名前の関数です。 この関数は、値を書き込んで再度読み取ることにより、基本的なキャッシュ機能を確認します。 + +```solidity + for(uint i=1; i<5000; i++) { + cache.cacheWrite(i*i); + } + + for(uint i=1; i<5000; i++) { + assertEq(cache.cacheRead(i), i*i); +``` + +これは、[`assert...` 関数](https://getfoundry.sh/reference/forge-std/std-assertions/)を使用して実際のテストを行う方法です。 この場合、書き込んだ値が読み取った値と等しいことを確認します。 `cache.cacheWrite`の結果は、キャッシュキーが線形に割り当てられることがわかっているので、破棄できます。 + +```solidity + } + } // testCaching + + + // 同じ値を複数回キャッシュし、キーが + // 同じままであることを確認する + function testRepeatCaching() public { + for(uint i=1; i<100; i++) { + uint _key1 = cache.cacheWrite(i); + uint _key2 = cache.cacheWrite(i); + assertEq(_key1, _key2); + } +``` + +まず、各値をキャッシュに2回書き込み、キーが同じであることを確認します (つまり、2回目の書き込みは実際には行われなかったということです)。 + +```solidity + for(uint i=1; i<100; i+=3) { + uint _key = cache.cacheWrite(i); + assertEq(_key, i); + } + } // testRepeatCaching +``` + +理論上は、連続したキャッシュ書き込みに影響しないバグが存在する可能性があります。 そのため、ここでは連続していない書き込みをいくつか行い、値がまだ書き換えられていないことを確認します。 + +```solidity + // メモリバッファからuintを読み取る (送信したパラメータが + // 返ってくることを確認するため) + function toUint256(bytes memory _bytes, uint256 _start) internal pure + returns (uint256) +``` + +`bytes memory`バッファから256ビットのワードを読み取ります。 このユーティリティ関数を使用すると、キャッシュを使用する関数呼び出しを実行したときに、正しい結果を受け取ったことを確認できます。 + +```solidity + { + require(_bytes.length >= _start + 32, "toUint256_outOfBounds"); + uint256 tempUint; + + assembly { + tempUint := mload(add(add(_bytes, 0x20), _start)) + } +``` + +Yulは`uint256`を超えるデータ構造をサポートしていないため、メモリバッファ`_bytes`のような、より高度なデータ構造を参照すると、その構造のアドレスが取得されます。 Solidityは`bytes memory`の値を、長さを含む32バイトのワードとして格納し、その後に実際のバイトが続くため、`_start`番目のバイトを取得するには`_bytes+32+_start`を計算する必要があります。 + +```solidity + + return tempUint; + } // toUint256 + + // fourParams()の関数シグネチャ、提供元: + // https://www.4byte.directory/signatures/?bytes4_signature=0x3edc1e6d + bytes4 constant FOUR_PARAMS = 0x3edc1e6d; + + // 正しい値が返ってくることを確認するための定数値 + uint256 constant VAL_A = 0xDEAD60A7; + uint256 constant VAL_B = 0xBEEF; + uint256 constant VAL_C = 0x600D; + uint256 constant VAL_D = 0x600D60A7; +``` + +テストに必要な定数です。 + +```solidity + function testReadParam() public { +``` + +`readParams`を使用する関数`fourParams()`を呼び出し、パラメータを正しく読み取れることをテストします。 + +```solidity + address _cacheAddr = address(cache); + bool _success; + bytes memory _callInput; + bytes memory _callOutput; +``` + +キャッシュを使用する関数を呼び出すには、通常のABIメカニズムが使用できないため、低レベルの[`
.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses)メカニズムを使用する必要があります。 このメカニズムは、入力として`bytes memory`を受け取り、それを出力として(ブール値と同様に)返します。 + +```solidity + // 最初の呼び出し、キャッシュは空 + _callInput = bytes.concat( + FOUR_PARAMS, +``` + +同じコントラクトが、キャッシュされた関数(トランザクションからの直接呼び出し用)とキャッシュされていない関数(他のスマートコントラクトからの呼び出し用)の両方をサポートすると便利です。 そのためには、すべてを[フォールバック関数](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function)に置くのではなく、引き続きSolidityのメカニズムに頼って正しい関数を呼び出す必要があります。 これにより、構成可能性が大幅に向上します。 ほとんどの場合、関数を識別するには1バイトで十分なため、3バイト(16\*3=48ガス)を無駄にしています。 しかし、この記事を書いている時点では、その48ガスのコストは0.07セントであり、これはより単純でバグが発生しにくいコードのための妥当なコストです。 + +```solidity + // 最初の値、キャッシュに追加する + cache.INTO_CACHE(), + bytes32(VAL_A), +``` + +最初の値: キャッシュに書き込む必要がある完全な値であることを示すフラグで、その後に32バイトの値が続きます。 他の3つの値も同様ですが、`VAL_B`はキャッシュに書き込まれず、`VAL_C`は3番目と4番目の両方のパラメータである点が異なります。 + +```solidity + . + . + . + ); + (_success, _callOutput) = _cacheAddr.call(_callInput); +``` + +ここで実際に`Cache`コントラクトを呼び出します。 + +```solidity + assertEq(_success, true); +``` + +呼び出しが成功することを期待します。 + +```solidity + assertEq(cache.cacheRead(1), VAL_A); + assertEq(cache.cacheRead(2), VAL_C); +``` + +空のキャッシュから始めて、`VAL_A`の後に`VAL_C`を追加します。 最初のキーが1で、2番目のキーが2であることを期待します。 + +``` + assertEq(toUint256(_callOutput,0), VAL_A); + assertEq(toUint256(_callOutput,32), VAL_B); + assertEq(toUint256(_callOutput,64), VAL_C); + assertEq(toUint256(_callOutput,96), VAL_C); +``` + +出力は4つのパラメータです。 ここで、それが正しいことを検証します。 + +```solidity + // 2回目の呼び出し、キャッシュを使用できる + _callInput = bytes.concat( + FOUR_PARAMS, + + // キャッシュ内の最初の値 + bytes1(0x01), +``` + +16未満のキャッシュキーは、ちょうど1バイトになります。 + +```solidity + // 2番目の値、キャッシュに追加しない + cache.DONT_CACHE(), + bytes32(VAL_B), + + // 3番目と4番目の値、同じ値 + bytes1(0x02), + bytes1(0x02) + ); + . + . + . + } // testReadParam +``` + +呼び出し後のテストは、最初の呼び出し後のテストと同一です。 + +```solidity + function testEncodeVal() public { +``` + +この関数は`testReadParam`に似ていますが、パラメータを明示的に書き込む代わりに`encodeVal()`を使用する点が異なります。 + +```solidity + . + . + . + _callInput = bytes.concat( + FOUR_PARAMS, + cache.encodeVal(VAL_A), + cache.encodeVal(VAL_B), + cache.encodeVal(VAL_C), + cache.encodeVal(VAL_D) + ); + . + . + . + assertEq(_callInput.length, 4+1*4); + } // testEncodeVal +``` + +`testEncodeVal()`での唯一の追加テストは、`_callInput`の長さが正しいかを確認することです。 最初の呼び出しでは、4+33\*4となります。 2回目では、すべての値がすでにキャッシュ内にあるため、4+1\*4となります。 + +```solidity + // キーが1バイト以上の場合のencodeValのテスト + // 4バイトまでキャッシュを埋めるのは + // 時間がかかりすぎるため、最大3バイトとする。 + function testEncodeValBig() public { + // いくつかの値をキャッシュに入れる。 + // 簡単にするため、値nにキーnを使用する。 + for(uint i=1; i<0x1FFF; i++) { + cache.cacheWrite(i); + } +``` + +上記の`testEncodeVal`関数は4つの値しかキャッシュに書き込まないため、[マルチバイト値を扱う関数の部分](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171)はチェックされません。 しかし、そのコードは複雑でエラーが発生しやすくなっています。 + +この関数の最初の部分は、1から0x1FFFまでのすべての値を順番にキャッシュに書き込むループなので、これらの値をエンコードして、どこに行くのかを知ることができます。 + +```solidity + . + . + . + + _callInput = bytes.concat( + FOUR_PARAMS, + cache.encodeVal(0x000F), // 1バイト 0x0F + cache.encodeVal(0x0010), // 2バイト 0x1010 + cache.encodeVal(0x0100), // 2バイト 0x1100 + cache.encodeVal(0x1000) // 3バイト 0x201000 + ); +``` + +1バイト、2バイト、3バイトの値をテストします。 十分なスタックエントリ (少なくとも0x10000000、約2億5千万) を書き込むには時間がかかりすぎるため、それ以上のテストは行いません。 + +```solidity + . + . + . + . + } // testEncodeValBig + + + // 短すぎるバッファでリバートされることをテストする + function testShortCalldata() public { +``` + +パラメータが不十分な異常ケースで何が起こるかをテストします。 + +```solidity + . + . + . + (_success, _callOutput) = _cacheAddr.call(_callInput); + assertEq(_success, false); + } // testShortCalldata +``` + +リバートされるので、得られる結果は`false`になるはずです。 + +``` + // 存在しないキャッシュキーで呼び出す + function testNoCacheKey() public { + . + . + . + _callInput = bytes.concat( + FOUR_PARAMS, + + // 最初の値、キャッシュに追加する + cache.INTO_CACHE(), + bytes32(VAL_A), + + // 2番目の値 + bytes1(0x0F), + bytes2(0x1234), + bytes11(0xA10102030405060708090A) + ); +``` + +この関数は、キャッシュが空で読み込む値がないことを除けば、4つの完全に正当なパラメータを取得します。 + +```solidity + . + . + . + // 長すぎるバッファでもすべてがうまくいくことをテストする + function testLongCalldata() public { + address _cacheAddr = address(cache); + bool _success; + bytes memory _callInput; + bytes memory _callOutput; + + // 最初の呼び出し、キャッシュは空 + _callInput = bytes.concat( + FOUR_PARAMS, + + // 最初の値、キャッシュに追加する + cache.INTO_CACHE(), bytes32(VAL_A), + + // 2番目の値、キャッシュに追加する + cache.INTO_CACHE(), bytes32(VAL_B), + + // 3番目の値、キャッシュに追加する + cache.INTO_CACHE(), bytes32(VAL_C), + + // 4番目の値、キャッシュに追加する + cache.INTO_CACHE(), bytes32(VAL_D), + + // 「幸運を祈って」もう1つの値 + bytes4(0x31112233) + ); +``` + +この関数は5つの値を送信します。 5番目の値は有効なキャッシュエントリではないため無視されることがわかります。もし含まれていなければリバートを引き起こしていたでしょう。 + +```solidity + (_success, _callOutput) = _cacheAddr.call(_callInput); + assertEq(_success, true); + . + . + . + } // testLongCalldata + +} // CacheTest + +``` + +## サンプルアプリケーション {#a-sample-app} + +Solidityでテストを書くのは非常に良いことですが、結局のところ、dappが役立つためにはチェーンの外部からのリクエストを処理できる必要があります。 この記事では、「Write Once, Read Many (一度書き込み、多数回読み取り)」を意味する`WORM`を使用して、dappでキャッシングを使用する方法を実演します。 キーがまだ書き込まれていない場合は、値を書き込むことができます。 キーがすでに書き込まれている場合は、リバートされます。 + +### コントラクト {#the-contract} + +[こちらがコントラクト](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol)です。 これは主に`Cache`と`CacheTest`で既に行ったことを繰り返しているので、興味深い部分のみを取り上げます。 + +```solidity +import "./Cache.sol"; + +contract WORM is Cache { +``` + +`Cache`を使用する最も簡単な方法は、自分のコントラクトでそれを継承することです。 + +```solidity + function writeEntryCached() external { + uint[] memory params = _readParams(2); + writeEntry(params[0], params[1]); + } // writeEntryCached +``` + +この関数は、上記の`CacheTest`の`fourParam`に似ています。 ABI仕様に従っていないため、関数にパラメータを宣言しないのが最善です。 + +```solidity + // 呼び出しを容易にする + // writeEntryCached()の関数シグネチャ、提供元: + // https://www.4byte.directory/signatures/?bytes4_signature=0xe4e4f2d3 + bytes4 constant public WRITE_ENTRY_CACHED = 0xe4e4f2d3; +``` + +ABI仕様に従っていないため、`writeEntryCached`を呼び出す外部コードは、`worm.writeEntryCached`を使用する代わりに、手動でcalldataを構築する必要があります。 この定数値があると、その記述が楽になります。 + +`WRITE_ENTRY_CACHED`を状態変数として定義しても、それを外部から読み取るには、そのゲッター関数である`worm.WRITE_ENTRY_CACHED()`を使用する必要があることに注意してください。 + +```solidity + function readEntry(uint key) public view + returns (uint _value, address _writtenBy, uint _writtenAtBlock) +``` + +読み取り関数は`view`なので、トランザクションを必要とせず、ガスもかかりません。 結果として、パラメータにキャッシュを使うメリットはありません。 ビュー関数では、より単純な標準メカニズムを使う方が最善です。 + +### テストコード {#the-testing-code} + +[こちらがコントラクトのテストコード](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol)です。 繰り返しになりますが、興味深い部分のみを見ていきましょう。 + +```solidity + function testWReadWrite() public { + worm.writeEntry(0xDEAD, 0x60A7); + + vm.expectRevert(bytes("entry already written")); + worm.writeEntry(0xDEAD, 0xBEEF); +``` + +[これ (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert)は、Foundryテストで次の呼び出しが失敗すること、および失敗の報告理由を指定する方法です。 これは、`.`構文を使用する場合に適用されます。これは、calldataを構築して低レベルインターフェース (`.call()`など) を使用してコントラクトを呼び出すのとは異なります。 + +```solidity + function testReadWriteCached() public { + uint cacheGoat = worm.cacheWrite(0x60A7); +``` + +ここでは、`cacheWrite`がキャッシュキーを返すという事実を利用します。 これは本番環境での使用を想定していません。`cacheWrite`は状態を変更するため、トランザクション中にしか呼び出せません。 トランザクションには戻り値がありません。結果がある場合、その結果はイベントとして発行されることになっています。 そのため、`cacheWrite`の戻り値はオンチェーンコードからのみアクセスでき、オンチェーンコードはパラメータのキャッシュを必要としません。 + +```solidity + (_success,) = address(worm).call(_callInput); +``` + +これは、`.call()`には2つの戻り値があるが、最初の値しか気にしないことをSolidityに伝える方法です。 + +```solidity + (_success,) = address(worm).call(_callInput); + assertEq(_success, false); +``` + +低レベルの`
.call()`関数を使用しているため、`vm.expectRevert()`を使用できず、呼び出しから得られるブール値の成功値を見る必要があります。 + +```solidity + event EntryWritten(uint indexed key, uint indexed value); + + . + . + . + + _callInput = bytes.concat( + worm.WRITE_ENTRY_CACHED(), worm.encodeVal(a), worm.encodeVal(b)); + vm.expectEmit(true, true, false, false); + emit EntryWritten(a, b); + (_success,) = address(worm).call(_callInput); +``` + +これは、Foundryでコードが[イベントを正しく発行する](https://getfoundry.sh/reference/cheatcodes/expect-emit/)ことを検証する方法です。 + +### クライアント {#the-client} + +Solidityのテストでは得られないものの1つは、自分のアプリケーションにコピー＆ペーストできるJavaScriptコードです。 そのコードを書くために、WORMを[Optimism](https://www.optimism.io/)の新しいテストネットである[Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli)にデプロイしました。 アドレスは[`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a)です。 + +[クライアントのJavaScriptコードはこちらで確認できます](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js)。 使用方法は次のとおりです。 + +1. gitリポジトリをクローンします。 + + ```sh + git clone https://github.com/qbzzt/20220915-all-you-can-cache.git + ``` + +2. 必要なパッケージをインストールします。 + + ```sh + cd javascript + yarn + ``` + +3. 設定ファイルをコピーします。 + + ```sh + cp .env.example .env + ``` + +4. `.env`を編集して設定を行います。 + + | パラメータ | 値 | + | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | + | MNEMONIC | トランザクションの支払いに十分なETHを持っているアカウントのニーモニック。 [こちらでOptimismのGoerliネットワークの無料ETHを手に入れられます](https://optimismfaucet.xyz/)。 | + | OPTIMISM_GOERLI_URL | Optimism GoerliのURL。 公開エンドポイント`https://goerli.optimism.io`は、レート制限がありますが、ここで必要な用途には十分です。 | + +5. `index.js`を実行します。 + + ```sh + node index.js + ``` + + このサンプルアプリケーションは、まずWORMにエントリを書き込み、calldataとEtherscan上のトランザクションへのリンクを表示します。 次に、そのエントリを読み返し、使用するキーとエントリ内の値 (値、ブロック番号、作成者) を表示します。 + +クライアントのほとんどは通常のDapp JavaScriptです。 そのため、ここでも興味深い部分のみを取り上げます。 + +```javascript +. +. +. +const main = async () => { + const func = await worm.WRITE_ENTRY_CACHED() + + // 毎回新しいキーが必要 + const key = await worm.encodeVal(Number(new Date())) +``` + +特定のスロットには一度しか書き込めないため、タイムスタンプを使用してスロットを再利用しないようにします。 + +```javascript +const val = await worm.encodeVal("0x600D") + +// エントリを書き込む +const calldata = func + key.slice(2) + val.slice(2) +``` + +Ethersは、コールデータが16進文字列、つまり`0x`の後に偶数個の16進数が続くことを期待します。 `key`と`val`は両方とも`0x`で始まるため、これらのヘッダーを削除する必要があります。 + +```javascript +const tx = await worm.populateTransaction.writeEntryCached() +tx.data = calldata + +sentTx = await wallet.sendTransaction(tx) +``` + +Solidityのテストコードと同様に、キャッシュされた関数を通常の方法で呼び出すことはできません。 代わりに、より低レベルのメカニズムを使用する必要があります。 + +```javascript + . + . + . + // 書き込んだばかりのエントリを読み取る + const realKey = '0x' + key.slice(4) // FFフラグを削除する + const entryRead = await worm.readEntry(realKey) + . + . + . +``` + +エントリの読み取りには、通常のメカニズムを使用できます。 `view`関数では、パラメータのキャッシュを使う必要はありません。 + +## 結論 {#conclusion} + +この記事のコードは概念実証 (プルーフ・オブ・コンセプト) であり、アイデアを理解しやすくすることを目的としています。 本番環境のシステムでは、いくつかの追加機能を実装することをお勧めします。 + +- `uint256`ではない値を処理します。 例えば、文字列です。 +- グローバルキャッシュの代わりに、ユーザーとキャッシュの間のマッピングを持つことを検討します。 異なるユーザーは異なる値を使用します。 +- アドレスに使用される値は、他の目的で使用される値とは異なります。 アドレス専用の個別のキャッシュを持つことが合理的かもしれません。 +- 現在、キャッシュキーは「先着、最小キー」アルゴリズムに基づいています。 最初の16個の値は、単一バイトとして送信できます。 次の4080個の値は、2バイトとして送信できます。 次の約100万個の値は3バイト、などとなります。 本番システムでは、キャッシュエントリの使用カウンタを保持し、最も_一般的な_16個の値が1バイト、次に一般的な4080個の値が2バイトになるように再編成する必要があります。 + + ただし、これは潜在的に危険な操作です。 次の一連のイベントを想像してみてください。 + + 1. Noam Naiveが`encodeVal`を呼び出して、トークンを送りたいアドレスをエンコードします。 そのアドレスはアプリケーションで最初に使用されたアドレスの1つなので、エンコードされた値は0x06です。 これはトランザクションではなく`view`関数なので、Noamと彼が使用するノード間のやり取りであり、他の誰も知りません。 + + 2. Owen Ownerがキャッシュの並べ替え操作を実行します。 そのアドレスを実際に使用する人はほとんどいないため、現在は0x201122としてエンコードされています。 別の値である1018に、0x06が割り当てられます。 + + 3. Noam Naiveは自分のトークンを0x06に送信します。 トークンはアドレス`0x0000000000000000000000000de0b6b3a7640000`に送られますが、そのアドレスの秘密鍵を誰も知らないため、そこにスタックしてしまいます。 Noamは_不満_です。 + + この問題、およびキャッシュの再順序付け中にメモリプール内にあるトランザクションの関連問題を解決する方法はありますが、その存在を認識しておく必要があります。 + +私はOptimismの従業員であり、これが最もよく知っているロールアップなので、ここではOptimismを使ってキャッシュを実演しました。 しかし、これは内部処理に最小限のコストしかかからないどのロールアップでも機能するはずです。そのため、比較するとL1へのトランザクションデータの書き込みが主な費用となります。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). + diff --git a/public/content/translations/ja/developers/tutorials/app-plasma/index.md b/public/content/translations/ja/developers/tutorials/app-plasma/index.md new file mode 100644 index 00000000000..2235da21e4e --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/app-plasma/index.md @@ -0,0 +1,1255 @@ +--- +title: "プライバシーを保護するアプリ固有のPlasmaを作成する" +description: "このチュートリアルでは、預金用の半秘密の銀行を構築します。 銀行は中央集権的なコンポーネントであり、各ユーザーの残高を把握しています。 しかし、この情報はオンチェーンには保存されません。 代わりに、銀行は状態のハッシュをポストします。 トランザクションが発生するたびに、銀行は新しいハッシュと、ハッシュの状態を新しいものに変更する署名済みトランザクションを持っているというゼロ知識証明をポストします。 このチュートリアルを読むと、ゼロ知識証明の使用方法だけでなく、なぜそれを使用するのか、そしてどのように安全に使用するのかを理解できるようになります。" +author: Ori Pomerantz +tags: [ "ゼロ知識", "サーバー", "オフチェーン", "プライバシー" ] +skill: advanced +lang: ja +published: 2025-10-15 +--- + +## はじめに {#introduction} + +[ロールアップ](/developers/docs/scaling/zk-rollups/)とは対照的に、[Plasma](/developers/docs/scaling/plasma)は完全性のためにイーサリアムメインネットを使用しますが、可用性のためには使用しません。 この記事では、Plasmaのように動作するアプリケーションを作成します。イーサリアムは完全性(不正な変更がないこと)を保証しますが、可用性(中央集権的なコンポーネントがダウンしてシステム全体が無効になる可能性があること)は保証しません。 + +ここで作成するアプリケーションは、プライバシーを保護する銀行です。 異なるアドレスは残高を持つアカウントを所有し、他のアカウントにお金(ETH)を送ることができます。 銀行は状態(アカウントとその残高)とトランザクションのハッシュをポストしますが、実際の残高はプライベートに保つことができるオフチェーンに保持します。 + +## 設計 {#design} + +これは本番環境対応のシステムではなく、教育用ツールです。 そのため、いくつかの単純化された仮定のもとに書かれています。 + +- 固定アカウントプール。 特定のアカウント数があり、各アカウントはあらかじめ決められたアドレスに属します。 ゼロ知識証明では可変サイズのデータ構造を扱うのが難しいため、これによりシステムが大幅に簡素化されます。 本番環境対応のシステムでは、状態ハッシュとして[Merkleルート](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)を使用し、必要な残高のためにMerkle証明を提供できます。 + +- メモリストレージ。 本番システムでは、再起動に備えてすべてのアカウント残高をディスクに書き込む必要があります。 ここでは、情報が単に失われても問題ありません。 + +- 送金のみ。 本番システムでは、資産を銀行に預け入れたり引き出したりする方法が必要になります。 しかし、ここでの目的は概念を説明することだけなので、この銀行は送金に限定されています。 + +### ゼロ知識証明 {#zero-knowledge-proofs} + +根本的なレベルでは、ゼロ知識証明は、証明者が何らかの公開データ_Datapublic_と_Dataprivate_の間に_Relationship_という関係が存在するような、何らかのデータ_Dataprivate_を知っていることを示します。 検証者は、_Relationship_と_Datapublic_を知っています。 + +プライバシーを保護するためには、状態とトランザクションがプライベートである必要があります。 しかし、完全性を確保するためには、状態の[暗号論的ハッシュ](https://en.wikipedia.org/wiki/Cryptographic_hash_function)が公開されている必要があります。 トランザクションを送信する人々に、そのトランザクションが実際に発生したことを証明するために、トランザクションハッシュをポストする必要もあります。 + +ほとんどの場合、_Dataprivate_はゼロ知識証明プログラムへの入力であり、_Datapublic_は出力です。 + +_Dataprivate_のこれらのフィールド： + +- _Staten_、古い状態 +- _Staten+1_、新しい状態 +- _Transaction_、古い状態から新しい状態へ変更するトランザクション。 このトランザクションには、以下のフィールドが含まれている必要があります。 + - 送金を受け取る_宛先アドレス_ + - 送金される_金額_ + - 各トランザクションが一度しか処理されないようにするための_ノンス (nonce)_。 + 送信元アドレスは署名から復元できるため、トランザクションに含める必要はありません。 +- トランザクションを実行する権限を持つ_署名_。 このケースでは、トランザクションを実行する権限を持つアドレスは送信元アドレスのみです。 ゼロ知識システムはこのように動作するため、イーサリアムの署名に加えて、アカウントの公開鍵も必要です。 + +_Datapublic_のフィールドは次のとおりです。 + +- _Hash(Staten)_ 古い状態のハッシュ +- _Hash(Staten+1)_ 新しい状態のハッシュ +- _Hash(Transaction)_ 状態を_Staten_から_Staten+1_へ変更するトランザクションのハッシュ。 + +この関係は、いくつかの条件をチェックします。 + +- 公開ハッシュが、実際にプライベートフィールドの正しいハッシュであること。 +- トランザクションが古い状態に適用されると、新しい状態になること。 +- 署名がトランザクションの送信元アドレスからのものであること。 + +暗号論的ハッシュ関数の特性により、これらの条件を証明するだけで完全性を確保できます。 + +### データ構造 {#data-structures} + +主要なデータ構造は、サーバーが保持する状態です。 すべてのアカウントについて、サーバーはアカウントの残高と[ノンス (nonce)](https://en.wikipedia.org/wiki/Cryptographic_nonce)を追跡し、[リプレイ攻撃](https://en.wikipedia.org/wiki/Replay_attack)を防止するために使用します。 + +### コンポーネント {#components} + +このシステムには2つのコンポーネントが必要です。 + +- トランザクションを受信し、処理し、ゼロ知識証明とともにハッシュをチェーンにポストする_サーバー_。 +- ハッシュを保存し、ゼロ知識証明を検証して状態遷移が正当であることを保証する_スマートコントラクト_。 + +### データと制御フロー {#flows} + +これらは、さまざまなコンポーネントが通信して、あるアカウントから別のアカウントに送金する方法です。 + +1. ウェブブラウザは、署名者のアカウントから別のアカウントへの送金を要求する署名済みトランザクションを送信します。 + +2. サーバーはトランザクションが有効であることを検証します。 + + - 署名者は銀行に十分な残高のあるアカウントを持っている。 + - 受信者は銀行にアカウントを持っている。 + +3. サーバーは、送金された金額を署名者の残高から差し引き、受信者の残高に加算することで、新しい状態を計算します。 + +4. サーバーは、状態の変更が有効であることを示すゼロ知識証明を計算します。 + +5. サーバーは、以下を含むトランザクションをイーサリアムに送信します。 + + - 新しい状態ハッシュ + - トランザクションハッシュ (トランザクションの送信者が処理されたことを知るため) + - 新しい状態への移行が有効であることを証明するゼロ知識証明 + +6. スマートコントラクトはゼロ知識証明を検証します。 + +7. ゼロ知識証明が確認された場合、スマートコントラクトは次のアクションを実行します。 + - 現在の状態ハッシュを新しい状態ハッシュに更新する + - 新しい状態ハッシュとトランザクションハッシュを含むログエントリを出力する + +### ツール {#tools} + +クライアント側のコードには、[Vite](https://vite.dev/)、[React](https://react.dev/)、[Viem](https://viem.sh/)、[Wagmi](https://wagmi.sh/)を使用します。 これらは業界標準のツールです。もし馴染みがない場合は、[このチュートリアル](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)を使用できます。 + +サーバーの大部分は、[Node](https://nodejs.org/en)を使用したJavaScriptで書かれています。 ゼロ知識の部分は[Noir](https://noir-lang.org/)で書かれています。 バージョン`1.0.0-beta.10`が必要なので、[指示に従ってNoirをインストール](https://noir-lang.org/docs/getting_started/quick_start)した後、次を実行してください。 + +``` +noirup -v 1.0.0-beta.10 +``` + +使用するブロックチェーンは、[Foundry](https://getfoundry.sh/introduction/installation)の一部であるローカルテスト用ブロックチェーンの`anvil`です。 + +## 実装 {#implementation} + +これは複雑なシステムなので、段階的に実装していきます。 + +### ステージ1 - 手動のゼロ知識 {#stage-1} + +最初のステージでは、ブラウザでトランザクションに署名し、その情報を手動でゼロ知識証明に提供します。 ゼロ知識コードは、その情報を`server/noir/Prover.toml`で受け取ることを想定しています([こちら](https://noir-lang.org/docs/getting_started/project_breakdown#provertoml-1)にドキュメントがあります)。 + +動作を確認するには： + +1. [Node](https://nodejs.org/en/download)と[Noir](https://noir-lang.org/install)がインストールされていることを確認してください。 できれば、macOS、Linux、[WSL](https://learn.microsoft.com/en-us/windows/wsl/install)などのUNIXシステムにインストールしてください。 + +2. ステージ1のコードをダウンロードし、Webサーバーを起動してクライアントコードを提供します。 + + ```sh + git clone https://github.com/qbzzt/250911-zk-bank.git -b 01-manual-zk + cd 250911-zk-bank + cd client + npm install + npm run dev + ``` + + ここでWebサーバーが必要な理由は、特定の種類の不正行為を防ぐため、多くのウォレット(MetaMaskなど)がディスクから直接提供されるファイルを受け入れないためです。 + +3. ウォレットでブラウザを開きます。 + +4. ウォレットで新しいパスフレーズを入力します。 これにより既存のパスフレーズが削除されるため、_必ずバックアップを取っておいてください_。 + + パスフレーズは`test test test test test test test test test test test junk`で、これは`anvil`のデフォルトのテスト用パスフレーズです。 + +5. [クライアント側のコード](http://localhost:5173/)にアクセスします。 + +6. ウォレットに接続し、宛先アカウントと金額を選択します。 + +7. **「Sign (署名)」** をクリックし、トランザクションに署名します。 + +8. **Prover.toml**の見出しの下にテキストがあります。 `server/noir/Prover.toml`をそのテキストに置き換えます。 + +9. ゼロ知識証明を実行します。 + + ```sh + cd ../server/noir + nargo execute + ``` + + 出力は以下のようになります + + ``` + ori@CryptoDocGuy:~/noir/250911-zk-bank/server/noir$ nargo execute + + [zkBank] Circuit witness successfully solved + [zkBank] Witness saved to target/zkBank.gz + [zkBank] Circuit output: (0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b, 0x0cfc0a67cb7308e4e9b254026b54204e34f6c8b041be207e64c5db77d95dd82d, 0x450cf9da6e180d6159290554ae3d8787, 0x6d8bc5a15b9037e52fb59b6b98722a85) + ``` + +10. 最後の2つの値をウェブブラウザに表示されるハッシュと比較して、メッセージが正しくハッシュ化されているかを確認します。 + +#### `server/noir/Prover.toml` {#server-noir-prover-toml} + +[このファイル](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml)は、Noirが期待する情報形式を示しています。 + +```toml +message="send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 500 finney (milliEth) 0 " +``` + +メッセージはテキスト形式であり、ユーザーが理解しやすく(署名時に必要)、Noirコードが解析しやすくなっています。 金額はfinneyで表記されており、一方では分割送金を可能にし、他方では読みやすくしています。 最後の数字は[ノンス (nonce)](https://en.wikipedia.org/wiki/Cryptographic_nonce)です。 + +文字列の長さは100文字です。 ゼロ知識証明は可変長データをうまく扱えないため、データをパディングすることがしばしば必要になります。 + +```toml +pubKeyX=["0x83",...,"0x75"] +pubKeyY=["0x35",...,"0xa5"] +signature=["0xb1",...,"0x0d"] +``` + +これら3つのパラメータは固定サイズのバイト配列です。 + +```toml +[[accounts]] +address="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266" +balance=100_000 +nonce=0 + +[[accounts]] +address="0x70997970C51812dc3A010C7d01b50e0d17dc79C8" +balance=100_000 +nonce=0 +``` + +これは構造体の配列を指定する方法です。 各エントリについて、アドレス、残高(milliETH、別名)を指定します。 [finney](https://cryptovalleyjournal.com/glossary/finney/))、および次のノンス (nonce)値を指定します。 + +#### `client/src/Transfer.tsx` {#client-src-transfer-tsx} + +[このファイル](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/client/src/Transfer.tsx)は、クライアント側の処理を実装し、`server/noir/Prover.toml`ファイル(ゼロ知識パラメータを含むファイル)を生成します。 + +ここでは、より興味深い部分について説明します。 + +```tsx +export default attrs => { +``` + +この関数は`Transfer` Reactコンポーネントを作成し、他のファイルからインポートできます。 + +```tsx + const accounts = [ + "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + "0x70997970C51812dc3A010C7d01b50e0d17dc79C8", + "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC", + "0x90F79bf6EB2c4f870365E785982E1f101E93b906", + "0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65", + ] +``` + +これらはアカウントのアドレスで、`test ...`によって作成されたアドレスです。 test junk`パスフレーズです。 独自のアドレスを使用したい場合は、この定義を変更してください。 + +```tsx + const account = useAccount() + const wallet = createWalletClient({ + transport: custom(window.ethereum!) + }) +``` + +これらの[Wagmiフック](https://wagmi.sh/react/api/hooks)により、[viem](https://viem.sh/)ライブラリとウォレットにアクセスできます。 + +```tsx + const message = `send ${toAccount} ${ethAmount*1000} finney (milliEth) ${nonce}`.padEnd(100, " ") +``` + +これは、スペースでパディングされたメッセージです。 [`useState`](https://react.dev/reference/react/useState)変数のいずれかが変更されるたびに、コンポーネントが再描画され、`message`が更新されます。 + +```tsx + const sign = async () => { +``` + +この関数は、ユーザーが**「Sign (署名)」**ボタンをクリックしたときに呼び出されます。 メッセージは自動的に更新されますが、署名にはウォレットでのユーザーの承認が必要であり、必要でない限りは要求したくありません。 + +```tsx + const signature = await wallet.signMessage({ + account: fromAccount, + message, + }) +``` + +ウォレットに[メッセージへの署名](https://viem.sh/docs/accounts/local/signMessage)を依頼します。 + +```tsx + const hash = hashMessage(message) +``` + +メッセージハッシュを取得します。 (Noirコードの)デバッグのためにユーザーに提供すると便利です。 + +```tsx + const pubKey = await recoverPublicKey({ + hash, + signature + }) +``` + +[公開鍵を取得](https://viem.sh/docs/utilities/recoverPublicKey)します。 これは[Noir `ecrecover`](https://github.com/colinnielsen/ecrecover-noir)関数に必要です。 + +```tsx + setSignature(signature) + setHash(hash) + setPubKey(pubKey) +``` + +状態変数を設定します。 これにより、コンポーネントが再描画され(`sign`関数が終了した後)、ユーザーに更新された値が表示されます。 + +```tsx + let proverToml = ` +``` + +`Prover.toml`のテキストです。 + +```tsx +message="${message}" + +pubKeyX=${hexToArray(pubKey.slice(4,4+2*32))} +pubKeyY=${hexToArray(pubKey.slice(4+2*32))} +``` + +Viemは公開鍵を65バイトの16進数文字列として提供します。 最初のバイトはバージョンマーカーである`0x04`です。 これに続いて、公開鍵の`x`に32バイト、公開鍵の`y`に32バイトが続きます。 + +しかし、Noirはこの情報を`x`と`y`の2つのバイト配列として受け取ることを想定しています。 ゼロ知識証明の一部としてではなく、ここでクライアント上で解析する方が簡単です。 + +これは一般的にゼロ知識の良い実践であることに注意してください。 ゼロ知識証明内のコードは高価であるため、ゼロ知識証明の外で実行できる処理は、ゼロ知識証明の外で_実行されるべき_です。 + +```tsx +signature=${hexToArray(signature.slice(2,-2))} +``` + +署名も65バイトの16進数文字列として提供されます。 しかし、最後のバイトは公開鍵を復元するためにのみ必要です。 公開鍵はすでにNoirコードに提供されるため、署名を検証するために必要ではなく、Noirコードもそれを要求しません。 + +```tsx +${accounts.map(accountInProverToml).reduce((a,b) => a+b, "")} +` +``` + +アカウントを提供します。 + +```tsx + setProverToml(proverToml) + } + + return ( + <> +

Transfer

+``` + +これはコンポーネントのHTML(より正確には、[JSX](https://react.dev/learn/writing-markup-with-jsx))形式です。 + +#### `server/noir/src/main.nr` {#server-noir-src-main-nr} + +[このファイル](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/src/main.nr)は、実際のゼロ知識コードです。 + +``` +use std::hash::pedersen_hash; +``` + +[Pedersenハッシュ](https://rya-sge.github.io/access-denied/2024/05/07/pedersen-hash-function/)は、[Noir標準ライブラリ](https://noir-lang.org/docs/noir/standard_library/cryptographic_primitives/hashes#pedersen_hash)で提供されています。 ゼロ知識証明では、このハッシュ関数が一般的に使用されます。 標準のハッシュ関数と比較して、[算術回路](https://rareskills.io/post/arithmetic-circuit)内で計算するのがはるかに簡単です。 + +``` +use keccak256::keccak256; +use dep::ecrecover; +``` + +これら2つの関数は外部ライブラリで、[`Nargo.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Nargo.toml)で定義されています。 これらはその名の通り、[keccak256ハッシュ](https://emn178.github.io/online-tools/keccak_256.html)を計算する関数と、イーサリアム署名を検証して署名者のイーサリアムアドレスを復元する関数です。 + +``` +global ACCOUNT_NUMBER : u32 = 5; +``` + +Noirは[Rust](https://www.rust-lang.org/)に触発されています。 変数は、デフォルトで定数です。 これがグローバルな設定定数を定義する方法です。 具体的には、`ACCOUNT_NUMBER`は私たちが保存するアカウントの数です。 + +`u`という名前のデータ型は、そのビット数の符号なし整数です。 サポートされている型は`u8`、`u16`、`u32`、`u64`、`u128`のみです。 + +``` +global FLAT_ACCOUNT_FIELDS : u32 = 2; +``` + +この変数は、後述するように、アカウントのPedersenハッシュに使用されます。 + +``` +global MESSAGE_LENGTH : u32 = 100; +``` + +上述のように、メッセージの長さは固定です。 ここで指定されています。 + +``` +global ASCII_MESSAGE_LENGTH : [u8; 3] = [0x31, 0x30, 0x30]; +global HASH_BUFFER_SIZE : u32 = 26+3+MESSAGE_LENGTH; +``` + +[EIP-191署名](https://eips.ethereum.org/EIPS/eip-191)には、26バイトのプレフィックス、その後にASCIIでのメッセージ長、最後にメッセージ自体を含むバッファが必要です。 + +``` +struct Account { + balance: u128, + address: Field, + nonce: u32, +} +``` + +アカウントについて保存する情報。 [`Field`](https://noir-lang.org/docs/noir/concepts/data_types/fields)は、通常最大253ビットの数値で、ゼロ知識証明を実装する[算術回路](https://rareskills.io/post/arithmetic-circuit)で直接使用できます。 ここでは`Field`を使用して160ビットのイーサリアムアドレスを保存します。 + +``` +struct TransferTxn { + from: Field, + to: Field, + amount: u128, + nonce: u32 +} +``` + +送金トランザクションで保存する情報です。 + +``` +fn flatten_account(account: Account) -> [Field; FLAT_ACCOUNT_FIELDS] { +``` + +関数定義です。 パラメータは`Account`情報です。 結果は`Field`変数の配列で、その長さは`FLAT_ACCOUNT_FIELDS`です。 + +``` + let flat = [ + account.address, + ((account.balance << 32) + account.nonce.into()).into(), + ]; +``` + +配列の最初の値はアカウントアドレスです。 2番目の値には、残高とノンス (nonce)の両方が含まれています。 `.into()`の呼び出しは、数値を必要なデータ型に変更します。 `account.nonce`は`u32`値ですが、`u128`値である`account.balance « 32`に加算するには、`u128`である必要があります。 それが最初の`.into()`です。 2番目のものは、`u128`の結果を`Field`に変換して、配列に収まるようにします。 + +``` + flat +} +``` + +Noirでは、関数は最後にのみ値を返すことができます(早期リターンはありません)。 戻り値を指定するには、関数の閉じ括弧の直前で評価します。 + +``` +fn flatten_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] { +``` + +この関数は、アカウント配列を`Field`配列に変換し、Petersenハッシュの入力として使用できます。 + +``` + let mut flat: [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] = [0; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER]; +``` + +これは、可変変数、つまり定数では_ない_変数を指定する方法です。 Noirの変数は常に値を持つ必要があるため、この変数をすべてゼロに初期化します。 + +``` + for i in 0..ACCOUNT_NUMBER { +``` + +`for`ループです。 境界が定数であることに注意してください。 Noirのループは、コンパイル時に境界がわかっている必要があります。 その理由は、算術回路がフロー制御をサポートしていないためです。 `for`ループを処理するとき、コンパイラは単にその中のコードを、各反復ごとに複数回配置します。 + +``` + let fields = flatten_account(accounts[i]); + for j in 0..FLAT_ACCOUNT_FIELDS { + flat[i*FLAT_ACCOUNT_FIELDS + j] = fields[j]; + } + } + + flat +} + +fn hash_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> Field { + pedersen_hash(flatten_accounts(accounts)) +} +``` + +最後に、アカウント配列をハッシュ化する関数にたどり着きました。 + +``` +fn find_account(accounts: [Account; ACCOUNT_NUMBER], address: Field) -> u32 { + let mut account : u32 = ACCOUNT_NUMBER; + + for i in 0..ACCOUNT_NUMBER { + if accounts[i].address == address { + account = i; + } + } +``` + +この関数は、特定のアドレスを持つアカウントを検索します。 この関数は、アドレスを見つけた後でもすべてのアカウントを反復処理するため、標準的なコードでは非常に非効率的です。 + +しかし、ゼロ知識証明ではフロー制御はありません。 条件をチェックする必要がある場合は、毎回チェックする必要があります。 + +`if`文でも同様のことが起こります。 上記のループの`if`文は、これらの数式に変換されます。 + +_conditionresult = accounts[i].address == address_ // 等しい場合は1、そうでない場合は0 + +_accountnew = conditionresult\*i + (1-conditionresult)\*accountold_ + +```rust + assert (account < ACCOUNT_NUMBER, f"{address} does not have an account"); + + account +} +``` + +[`assert`](https://noir-lang.org/docs/dev/noir/concepts/assert)関数は、アサーションが偽の場合にゼロ知識証明をクラッシュさせます。 この場合、関連するアドレスを持つアカウントが見つからない場合です。 アドレスを報告するには、[フォーマット文字列](https://noir-lang.org/docs/noir/concepts/data_types/strings#format-strings)を使用します。 + +```rust +fn apply_transfer_txn(accounts: [Account; ACCOUNT_NUMBER], txn: TransferTxn) -> [Account; ACCOUNT_NUMBER] { +``` + +この関数は送金トランザクションを適用し、新しいアカウント配列を返します。 + +```rust + let from = find_account(accounts, txn.from); + let to = find_account(accounts, txn.to); + + let (txnFrom, txnAmount, txnNonce, accountNonce) = + (txn.from, txn.amount, txn.nonce, accounts[from].nonce); +``` + +Noirのフォーマット文字列内で構造体要素にアクセスできないため、使用可能なコピーを作成します。 + +```rust + assert (accounts[from].balance >= txn.amount, + f"{txnFrom} does not have {txnAmount} finney"); + + assert (accounts[from].nonce == txn.nonce, + f"Transaction has nonce {txnNonce}, but the account is expected to use {accountNonce}"); +``` + +これらは、トランザクションを無効にする可能性のある2つの条件です。 + +```rust + let mut newAccounts = accounts; + + newAccounts[from].balance -= txn.amount; + newAccounts[from].nonce += 1; + newAccounts[to].balance += txn.amount; + + newAccounts +} +``` + +新しいアカウント配列を作成して返します。 + +```rust +fn readAddress(messageBytes: [u8; MESSAGE_LENGTH]) -> Field +``` + +この関数は、メッセージからアドレスを読み取ります。 + +```rust +{ + let mut result : Field = 0; + + for i in 7..47 { +``` + +アドレスは常に20バイト(別名 40桁の16進数)で、7文字目から始まります。 + +```rust + result *= 0x10; + if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9 + result += (messageBytes[i]-48).into(); + } + if messageBytes[i] >= 65 & messageBytes[i] <= 70 { // A-F + result += (messageBytes[i]-65+10).into() + } + if messageBytes[i] >= 97 & messageBytes[i] <= 102 { // a-f + result += (messageBytes[i]-97+10).into() + } + } + + result +} + +fn readAmountAndNonce(messageBytes: [u8; MESSAGE_LENGTH]) -> (u128, u32) +``` + +メッセージから金額とノンス (nonce)を読み取ります。 + +```rust +{ + let mut amount : u128 = 0; + let mut nonce: u32 = 0; + let mut stillReadingAmount: bool = true; + let mut lookingForNonce: bool = false; + let mut stillReadingNonce: bool = false; +``` + +メッセージでは、アドレスの後の最初の数字は、送金するfinney(別名 ETHの1000分の1)の量です。 2番目の数字はノンス (nonce)です。 それらの間のテキストは無視されます。 + +```rust + for i in 48..MESSAGE_LENGTH { + if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9 + let digit = (messageBytes[i]-48); + + if stillReadingAmount { + amount = amount*10 + digit.into(); + } + + if lookingForNonce { // We just found it + stillReadingNonce = true; + lookingForNonce = false; + } + + if stillReadingNonce { + nonce = nonce*10 + digit.into(); + } + } else { + if stillReadingAmount { + stillReadingAmount = false; + lookingForNonce = true; + } + if stillReadingNonce { + stillReadingNonce = false; + } + } + } + + (amount, nonce) +} +``` + +[タプル](https://noir-lang.org/docs/noir/concepts/data_types/tuples)を返すことは、Noirで関数から複数の値を返す方法です。 + +```rust +fn readTransferTxn(message: str) -> TransferTxn +{ + let mut txn: TransferTxn = TransferTxn { from: 0, to: 0, amount:0, nonce:0 }; + let messageBytes = message.as_bytes(); + + txn.to = readAddress(messageBytes); + let (amount, nonce) = readAmountAndNonce(messageBytes); + txn.amount = amount; + txn.nonce = nonce; + + txn +} +``` + +この関数はメッセージをバイトに変換し、次に金額を`TransferTxn`に変換します。 + +```rust +// ViemのhashMessageと同等 +// https://viem.sh/docs/utilities/hashMessage#hashmessage +fn hashMessage(message: str) -> [u8;32] { +``` + +アカウントはゼロ知識証明の内部でのみハッシュ化されるため、Pedersenハッシュを使用することができました。 しかし、このコードでは、ブラウザによって生成されたメッセージの署名をチェックする必要があります。 そのためには、[EIP 191](https://eips.ethereum.org/EIPS/eip-191)のイーサリアム署名形式に従う必要があります。 これは、標準のプレフィックス、ASCIIでのメッセージ長、およびメッセージ自体を含む結合されたバッファを作成し、それをハッシュ化するためにイーサリアム標準のkeccak256を使用する必要があることを意味します。 + +```rust + // ASCII prefix + let prefix_bytes = [ + 0x19, // \x19 + 0x45, // 'E' + 0x74, // 't' + 0x68, // 'h' + 0x65, // 'e' + 0x72, // 'r' + 0x65, // 'e' + 0x75, // 'u' + 0x6D, // 'm' + 0x20, // ' ' + 0x53, // 'S' + 0x69, // 'i' + 0x67, // 'g' + 0x6E, // 'n' + 0x65, // 'e' + 0x64, // 'd' + 0x20, // ' ' + 0x4D, // 'M' + 0x65, // 'e' + 0x73, // 's' + 0x73, // 's' + 0x61, // 'a' + 0x67, // 'g' + 0x65, // 'e' + 0x3A, // ':' + 0x0A // '\n' + ]; +``` + +アプリケーションがユーザーにトランザクションやその他の目的で使用できるメッセージへの署名を要求するケースを避けるため、EIP 191では、すべての署名済みメッセージは、文字0x19(有効なASCII文字ではない)で始まり、その後に`Ethereum Signed Message:`と改行が続くことを指定しています。 + +```rust + let mut buffer: [u8; HASH_BUFFER_SIZE] = [0u8; HASH_BUFFER_SIZE]; + for i in 0..26 { + buffer[i] = prefix_bytes[i]; + } + + let messageBytes : [u8; MESSAGE_LENGTH] = message.as_bytes(); + + if MESSAGE_LENGTH <= 9 { + for i in 0..1 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+1] = messageBytes[i]; + } + } + + if MESSAGE_LENGTH >= 10 & MESSAGE_LENGTH <= 99 { + for i in 0..2 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+2] = messageBytes[i]; + } + } + + if MESSAGE_LENGTH >= 100 { + for i in 0..3 { + buffer[i+26] = ASCII_MESSAGE_LENGTH[i]; + } + + for i in 0..MESSAGE_LENGTH { + buffer[i+26+3] = messageBytes[i]; + } + } + + assert(MESSAGE_LENGTH < 1000, "Messages whose length is over three digits are not supported"); +``` + +メッセージ長が999までを処理し、それより大きい場合は失敗させます。 メッセージの長さは定数ですが、変更しやすくするためにこのコードを追加しました。 本番システムでは、パフォーマンスを向上させるために`MESSAGE_LENGTH`は変更されないと仮定するでしょう。 + +```rust + keccak256::keccak256(buffer, HASH_BUFFER_SIZE) +} +``` + +イーサリアム標準の`keccak256`関数を使用します。 + +```rust +fn signatureToAddressAndHash( + message: str, + pubKeyX: [u8; 32], + pubKeyY: [u8; 32], + signature: [u8; 64] + ) -> (Field, Field, Field) // address, first 16 bytes of hash, last 16 bytes of hash +{ +``` + +この関数は署名を検証し、それにはメッセージハッシュが必要です。 そして、署名したアドレスとメッセージハッシュを提供してくれます。 メッセージハッシュは2つの`Field`値で提供されます。これは、バイト配列よりもプログラムの残りの部分で使いやすいためです。 + +フィールドの計算は大きな数を[法](https://en.wikipedia.org/wiki/Modulo)として行われますが、その数は通常256ビット未満であるため(そうでなければEVMでこれらの計算を実行するのが難しくなるため)、2つの`Field`値を使用する必要があります。 + +```rust + let hash = hashMessage(message); + + let mut (hash1, hash2) = (0,0); + + for i in 0..16 { + hash1 = hash1*256 + hash[31-i].into(); + hash2 = hash2*256 + hash[15-i].into(); + } +``` + +`hash1`と`hash2`を可変変数として指定し、ハッシュをバイトごとに書き込みます。 + +```rust + ( + ecrecover::ecrecover(pubKeyX, pubKeyY, signature, hash), +``` + +これは[Solidityの`ecrecover`](https://docs.soliditylang.org/en/v0.8.30/cheatsheet.html#mathematical-and-cryptographic-functions)に似ていますが、2つの重要な違いがあります。 + +- 署名が有効でない場合、呼び出しは`assert`に失敗し、プログラムは中止されます。 +- 公開鍵は署名とハッシュから復元できますが、これは外部で実行できる処理であり、したがってゼロ知識証明の内部で行う価値はありません。 ここで誰かが私たちをだまそうとすると、署名の検証は失敗します。 + +```rust + hash1, + hash2 + ) +} + +fn main( + accounts: [Account; ACCOUNT_NUMBER], + message: str, + pubKeyX: [u8; 32], + pubKeyY: [u8; 32], + signature: [u8; 64], + ) -> pub ( + Field, // Hash of old accounts array + Field, // Hash of new accounts array + Field, // First 16 bytes of message hash + Field, // Last 16 bytes of message hash + ) +``` + +最後に、`main`関数に到達します。 アカウントのハッシュが古い値から新しい値に正当に変更されるトランザクションがあることを証明する必要があります。 また、特定のトランザクションハッシュを持っていることを証明する必要もあります。そうすることで、送信した人が自分のトランザクションが処理されたことを知ることができます。 + +```rust +{ + let mut txn = readTransferTxn(message); +``` + +`txn`は可変である必要があります。なぜなら、fromアドレスはメッセージからではなく、署名から読み取るからです。 + +```rust + let (fromAddress, txnHash1, txnHash2) = signatureToAddressAndHash( + message, + pubKeyX, + pubKeyY, + signature); + + txn.from = fromAddress; + + let newAccounts = apply_transfer_txn(accounts, txn); + + ( + hash_accounts(accounts), + hash_accounts(newAccounts), + txnHash1, + txnHash2 + ) +} +``` + +### ステージ2 - サーバーの追加 {#stage-2} + +第2ステージでは、ブラウザからの送金トランザクションを受信して実装するサーバーを追加します。 + +動作を確認するには： + +1. Viteが実行中の場合は停止します。 + +2. サーバーを含むブランチをダウンロードし、必要なモジュールがすべて揃っていることを確認します。 + + ```sh + git checkout 02-add-server + cd client + npm install + cd ../server + npm install + ``` + + Noirコードをコンパイルする必要はありません。ステージ1で使用したコードと同じです。 + +3. サーバーを起動します。 + + ```sh + npm run start + ``` + +4. 別のコマンドラインウィンドウでViteを実行して、ブラウザコードを提供します。 + + ```sh + cd client + npm run dev + ``` + +5. クライアントコード([http://localhost:5173](http://localhost:5173))にアクセスします + +6. トランザクションを発行する前に、ノンス (nonce)と送信できる金額を知る必要があります。 この情報を取得するには、**「Update account data (アカウントデータを更新)」**をクリックしてメッセージに署名します。 + + ここでジレンマがあります。 一方で、再利用可能なメッセージ([リプレイ攻撃](https://en.wikipedia.org/wiki/Replay_attack))に署名したくないため、そもそもノンス (nonce)が必要です。 しかし、まだノンス (nonce)がありません。 解決策は、一度しか使用できず、両側で既に持っているノンス (nonce)、例えば現在時刻などを選択することです。 + + この解決策の問題は、時刻が完全に同期していない可能性があることです。 そこで代わりに、毎分変わる値に署名します。 これは、リプレイ攻撃に対する脆弱性のウィンドウが最大1分であることを意味します。 本番環境では署名されたリクエストがTLSで保護されること、またトンネルの反対側であるサーバーは既に残高とノンス (nonce)を開示できる(動作するためにそれらを知る必要がある)ことを考えると、これは許容できるリスクです。 + +7. ブラウザが残高とノンス (nonce)を取得すると、送金フォームが表示されます。 宛先アドレスと金額を選択し、**「Transfer (送金)」**をクリックします。 このリクエストに署名します。 + +8. 送金を確認するには、**「Update account data (アカウントデータを更新)」**するか、サーバーを実行しているウィンドウを確認します。 サーバーは状態が変更されるたびにログを記録します。 + + ``` + ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start + + > server@1.0.0 start + > node --experimental-json-modules index.mjs + + Listening on port 3000 + Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 36000 finney (milliEth) 0 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 64000 (1) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 100000 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + Txn send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 7200 finney (milliEth) 1 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 56800 (2) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 3000 finney (milliEth) 2 processed + New state: + 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 53800 (3) + 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0) + 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0) + 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 139000 (0) + 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0) + ``` + +#### `server/index.mjs` {#server-index-mjs-1} + +[このファイル](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/index.mjs)はサーバープロセスを含み、[`main.nr`](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/noir/src/main.nr)のNoirコードと相互作用します。 興味深い部分を説明します。 + +```js +import { Noir } from '@noir-lang/noir_js' +``` + +[noir.js](https://www.npmjs.com/package/@noir-lang/noir_js)ライブラリは、JavaScriptコードとNoirコードの間のインターフェースです。 + +```js +const circuit = JSON.parse(await fs.readFile("./noir/target/zkBank.json")) +const noir = new Noir(circuit) +``` + +算術回路(前の段階で作成したコンパイル済みのNoirプログラム)をロードし、実行準備をします。 + +```js +// We only provide account information in return to a signed request +const accountInformation = async signature => { + const fromAddress = await recoverAddress({ + hash: hashMessage("Get account data " + Math.floor((new Date().getTime())/60000)), + signature + }) +``` + +アカウント情報を提供するには、署名のみが必要です。 その理由は、メッセージがどうなるかを既に知っており、したがってメッセージハッシュも知っているからです。 + +```js +const processMessage = async (message, signature) => { +``` + +メッセージを処理し、エンコードされたトランザクションを実行します。 + +```js + // Get the public key + const pubKey = await recoverPublicKey({ + hash, + signature + }) +``` + +サーバーでJavaScriptを実行するようになったので、クライアントではなくサーバーで公開鍵を取得できます。 + +```js + let noirResult + try { + noirResult = await noir.execute({ + message, + signature: signature.slice(2,-2).match(/.{2}/g).map(x => `0x${x}`), + pubKeyX, + pubKeyY, + accounts: Accounts + }) +``` + +`noir.execute`はNoirプログラムを実行します。 パラメータは、[`Prover.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml)で提供されるものと同等です。 Viemが行うように、長い値は単一の16進数値(`0x60A7`)ではなく、16進文字列の配列(`["0x60", "0xA7"]`)として提供されることに注意してください。 + +```js + } catch (err) { + console.log(`Noir error: ${err}`) + throw Error("Invalid transaction, not processed") + } +``` + +エラーが発生した場合は、それをキャッチし、簡略化されたバージョンをクライアントにリレーします。 + +```js + Accounts[fromAccountNumber].nonce++ + Accounts[fromAccountNumber].balance -= amount + Accounts[toAccountNumber].balance += amount +``` + +トランザクションを適用します。 Noirコードでは既に実行しましたが、そこから結果を抽出するよりもここで再度実行する方が簡単です。 + +```js +let Accounts = [ + { + address: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + balance: 5000, + nonce: 0, + }, +``` + +初期の`Accounts`構造体。 + +### ステージ3 - イーサリアムスマートコントラクト {#stage-3} + +1. サーバーとクライアントプロセスを停止します。 + +2. スマートコントラクトを含むブランチをダウンロードし、必要なモジュールがすべて揃っていることを確認します。 + + ```sh + git checkout 03-smart-contracts + cd client + npm install + cd ../server + npm install + ``` + +3. 別のコマンドラインウィンドウで`anvil`を実行します。 + +4. 検証キーとSolidityベリファイアを生成し、ベリファイアコードをSolidityプロジェクトにコピーします。 + + ```sh + cd noir + bb write_vk -b ./target/zkBank.json -o ./target --oracle_hash keccak + bb write_solidity_verifier -k ./target/vk -o ./target/Verifier.sol + cp target/Verifier.sol ../../smart-contracts/src + ``` + +5. スマートコントラクトに移動し、`anvil`ブロックチェーンを使用するように環境変数を設定します。 + + ```sh + cd ../../smart-contracts + export ETH_RPC_URL=http://localhost:8545 + ETH_PRIVATE_KEY=ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 + ``` + +6. `Verifier.sol`をデプロイし、アドレスを環境変数に保存します。 + + ```sh + VERIFIER_ADDRESS=`forge create src/Verifier.sol:HonkVerifier --private-key $ETH_PRIVATE_KEY --optimize --broadcast | awk '/Deployed to:/ {print $3}'` + echo $VERIFIER_ADDRESS + ``` + +7. `ZkBank`コントラクトをデプロイします。 + + ```sh + ZKBANK_ADDRESS=`forge create ZkBank --private-key $ETH_PRIVATE_KEY --broadcast --constructor-args $VERIFIER_ADDRESS 0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b | awk '/Deployed to:/ {print $3}'` + echo $ZKBANK_ADDRESS + ``` + + `0x199..67b`の値は、`Accounts`の初期状態のPedersonハッシュです。 `server/index.mjs`でこの初期状態を変更した場合、トランザクションを実行してゼロ知識証明によって報告される初期ハッシュを確認できます。 + +8. サーバーを実行します。 + + ```sh + cd ../server + npm run start + ``` + +9. 別のコマンドラインウィンドウでクライアントを実行します。 + + ```sh + cd client + npm run dev + ``` + +10. いくつかのトランザクションを実行します。 + +11. 状態がオンチェーンで変更されたことを確認するには、サーバープロセスを再起動します。 トランザクションの元のハッシュ値がオンチェーンに保存されているハッシュ値と異なるため、`ZkBank`がトランザクションを受け入れなくなったことを確認してください。 + + これは予想されるエラーの種類です。 + + ``` + ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start + + > server@1.0.0 start + > node --experimental-json-modules index.mjs + + Listening on port 3000 + Verification error: ContractFunctionExecutionError: The contract function "processTransaction" reverted with the following reason: + Wrong old state hash + + Contract Call: + address: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512 + function: processTransaction(bytes _proof, bytes32[] _publicInputs) + args: (0x0000000000000000000000000000000000000000000000042ab5d6d1986846cf00000000000000000000000000000000000000000000000b75c020998797da7800000000000000000000000000000000000000000000000) + ``` + +#### `server/index.mjs` {#server-index-mjs-2} + +このファイルの変更点は、主に実際の証明を作成し、オンチェーンで送信することに関連しています。 + +```js +import { exec } from 'child_process' +import util from 'util' + +const execPromise = util.promisify(exec) +``` + +オンチェーンで送信する実際の証明を作成するには、[Barretenbergパッケージ](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg)を使用する必要があります。 このパッケージは、コマンドラインインターフェイス(`bb`)を実行するか、[JavaScriptライブラリ、`bb.js`](https://www.npmjs.com/package/@aztec/bb.js)を使用して使用できます。 JavaScriptライブラリはネイティブでコードを実行するよりもはるかに遅いため、ここではコマンドラインを使用するために[`exec`](https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback)を使用します。 + +`bb.js`を使用することにした場合、使用しているNoirのバージョンと互換性のあるバージョンを使用する必要があることに注意してください。 執筆時点では、現在のNoirバージョン(1.0.0-beta.11)は`bb.js`バージョン0.87を使用しています。 + +```js +const zkBankAddress = process.env.ZKBANK_ADDRESS || "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512" +``` + +ここでのアドレスは、クリーンな`anvil`で開始し、上記の手順に従ったときに取得するものです。 + +```js +const walletClient = createWalletClient({ + chain: anvil, + transport: http(), + account: privateKeyToAccount("0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6") +}) +``` + +この秘密鍵は、`anvil`のデフォルトの事前資金提供アカウントの1つです。 + +```js +const generateProof = async (witness, fileID) => { +``` + +`bb`実行可能ファイルを使用して証明を生成します。 + +```js + const fname = `witness-${fileID}.gz` + await fs.writeFile(fname, witness) +``` + +ウィットネスをファイルに書き込みます。 + +```js + await execPromise(`bb prove -b ./noir/target/zkBank.json -w ${fname} -o ${fileID} --oracle_hash keccak --output_format fields`) +``` + +実際に証明を作成します。 このステップでは、公開変数を持つファイルも作成しますが、それは必要ありません。 これらの変数は既に`noir.execute`から取得しています。 + +```js + const proof = "0x" + JSON.parse(await fs.readFile(`./${fileID}/proof_fields.json`)).reduce((a,b) => a+b, "").replace(/0x/g, "") +``` + +証明は`Field`値のJSON配列であり、それぞれが16進数値として表されます。 ただし、トランザクションでは単一の`bytes`値として送信する必要があり、Viemはこれを大きな16進数文字列で表します。 ここでは、すべての値を連結し、すべての`0x`を削除し、最後に1つ追加することで形式を変更します。 + +```js + await execPromise(`rm -r ${fname} ${fileID}`) + + return proof +} +``` + +クリーンアップして証明を返します。 + +```js +const processMessage = async (message, signature) => { + . + . + . + + const publicFields = noirResult.returnValue.map(x=>'0x' + x.slice(2).padStart(64, "0")) +``` + +公開フィールドは32バイト値の配列である必要があります。 ただし、トランザクションハッシュを2つの`Field`値に分割する必要があったため、16バイト値として表示されます。 ここでは、Viemが実際には32バイトであることを理解できるようにゼロを追加します。 + +```js + const proof = await generateProof(noirResult.witness, `${fromAddress}-${nonce}`) +``` + +各アドレスは各ノンス (nonce)を一度しか使用しないため、`fromAddress`と`nonce`の組み合わせをウィットネスファイルと出力ディレクトリの一意の識別子として使用できます。 + +```js + try { + await zkBank.write.processTransaction([ + proof, publicFields]) + } catch (err) { + console.log(`Verification error: ${err}`) + throw Error("Can't verify the transaction onchain") + } + . + . + . +} +``` + +トランザクションをチェーンに送信します。 + +#### `smart-contracts/src/ZkBank.sol` {#smart-contracts-src-zkbank-sol} + +これは、トランザクションを受け取るオンチェーンコードです。 + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity >=0.8.21; + +import {HonkVerifier} from "./Verifier.sol"; + +contract ZkBank { + HonkVerifier immutable myVerifier; + bytes32 currentStateHash; + + constructor(address _verifierAddress, bytes32 _initialStateHash) { + currentStateHash = _initialStateHash; + myVerifier = HonkVerifier(_verifierAddress); + } +``` + +オンチェーンコードは、2つの変数を追跡する必要があります。ベリファイア(`nargo`によって作成される別のコントラクト)と現在の状態ハッシュです。 + +```solidity + event TransactionProcessed( + bytes32 indexed transactionHash, + bytes32 oldStateHash, + bytes32 newStateHash + ); +``` + +状態が変更されるたびに、`TransactionProcessed`イベントを発行します。 + +```solidity + function processTransaction( + bytes calldata _proof, + bytes32[] calldata _publicFields + ) public { +``` + +この関数はトランザクションを処理します。 証明(`bytes`として)と公開入力(`bytes32`配列として)を、ベリファイアが必要とする形式で取得します(オンチェーン処理を最小限に抑え、したがってガスコストを削減するため)。 + +```solidity + require(_publicInputs[0] == currentStateHash, + "Wrong old state hash"); +``` + +ゼロ知識証明は、トランザクションが現在のハッシュから新しいハッシュに変更されることである必要があります。 + +```solidity + myVerifier.verify(_proof, _publicFields); +``` + +ベリファイアコントラクトを呼び出して、ゼロ知識証明を検証します。 このステップは、ゼロ知識証明が間違っている場合にトランザクションをリバートします。 + +```solidity + currentStateHash = _publicFields[1]; + + emit TransactionProcessed( + _publicFields[2]<<128 | _publicFields[3], + _publicFields[0], + _publicFields[1] + ); + } +} +``` + +すべてが問題なければ、状態ハッシュを新しい値に更新し、`TransactionProcessed`イベントを発行します。 + +## 中央集権型コンポーネントによる悪用 {#abuses} + +情報セキュリティは、3つの属性で構成されます。 + +- _機密性_、ユーザーは読む権限のない情報を読むことができません。 +- _完全性_、情報は、許可されたユーザーによって、許可された方法でのみ変更できます。 +- _可用性_、承認されたユーザーはシステムを使用できます。 + +このシステムでは、ゼロ知識証明を通じて完全性が提供されます。 可用性の保証ははるかに困難であり、銀行は各アカウントの残高とすべてのトランザクションを知る必要があるため、機密性は不可能です。 情報を持っているエンティティがその情報を共有するのを防ぐ方法はありません。 + +[ステルスアドレス](https://vitalik.eth.limo/general/2023/01/20/stealth.html)を使用して真に機密性の高い銀行を作成することは可能かもしれませんが、それはこの記事の範囲を超えています。 + +### 偽情報 {#false-info} + +サーバーが完全性を侵害する方法の1つは、[データが要求された](https://github.com/qbzzt/250911-zk-bank/blob/03-smart-contracts/server/index.mjs#L278-L291)ときに偽の情報を提供することです。 + +これを解決するために、アカウントをプライベート入力として受け取り、情報が要求されたアドレスをパブリック入力として受け取る2番目のNoirプログラムを作成できます。 出力は、そのアドレスの残高とノンス (nonce)、およびアカウントのハッシュです。 + +もちろん、ノンス (nonce)と残高をオンチェーンにポストしたくないため、この証明はオンチェーンで検証できません。 しかし、ブラウザで実行されているクライアントコードで検証することはできます。 + +### 強制トランザクション {#forced-txns} + +L2での可用性を確保し、検閲を防ぐための通常のメカニズムは、[強制トランザクション](https://docs.optimism.io/stack/transactions/forced-transaction)です。 しかし、強制トランザクションはゼロ知識証明と組み合わせられません。 サーバーは、トランザクションを検証できる唯一のエンティティです。 + +`smart-contracts/src/ZkBank.sol`を変更して、強制トランザクションを受け入れ、処理されるまでサーバーが状態を変更するのを防ぐことができます。 しかし、これにより、単純なサービス拒否攻撃にさらされることになります。 強制トランザクションが無効で処理できない場合はどうなるでしょうか？ + +解決策は、強制トランザクションが無効であることを示すゼロ知識証明を持つことです。 これにより、サーバーには3つのオプションが与えられます。 + +- 強制トランザクションを処理し、処理されたことと新しい状態ハッシュを示すゼロ知識証明を提供する。 +- 強制トランザクションを拒否し、トランザクションが無効であること(不明なアドレス、不正なノンス (nonce)、または不十分な残高)をコントラクトにゼロ知識証明で提供する。 +- 強制トランザクションを無視する。 サーバーに実際にトランザクションを処理させる方法はありませんが、それはシステム全体が利用できなくなることを意味します。 + +#### 可用性ボンド {#avail-bonds} + +実際の導入では、サーバーを稼働させ続けるための何らかの利益動機があるでしょう。 このインセンティブを強化するには、サーバーに可用性ボンドをポストさせ、強制トランザクションが一定期間内に処理されない場合に誰でもそれをバーンできるようにします。 + +### 不正なNoirコード {#bad-noir-code} + +通常、人々にスマートコントラクトを信頼してもらうには、ソースコードを[ブロックエクスプローラー](https://eth.blockscout.com/address/0x7D16d2c4e96BCFC8f815E15b771aC847EcbDB48b?tab=contract)にアップロードします。 しかし、ゼロ知識証明の場合は、それだけでは不十分です。 + +`Verifier.sol`には検証キーが含まれており、これはNoirプログラムの関数です。 しかし、そのキーはNoirプログラムが何であったかを教えてくれません。 実際に信頼できるソリューションを持つには、Noirプログラム(とそれを作成したバージョン)をアップロードする必要があります。 そうしないと、ゼロ知識証明は、バックドアを持つ別のプログラムを反映する可能性があります。 + +ブロックエクスプローラーがNoirプログラムのアップロードと検証を許可するようになるまで、自分でそれを行う必要があります(できれば[IPFS](/developers/tutorials/ipfs-decentralized-ui/)に)。 そうすれば、高度なユーザーはソースコードをダウンロードし、自分でコンパイルし、`Verifier.sol`を作成し、それがオンチェーンのものと同一であることを検証できます。 + +## 結論 {#conclusion} + +Plasmaタイプのアプリケーションには、情報ストレージとして中央集権的なコンポーネントが必要です。 これにより、潜在的な脆弱性が生じますが、その見返りとして、ブロックチェーン自体では利用できない方法でプライバシーを保護できます。 ゼロ知識証明を使用することで、完全性を確保し、中央集権型コンポーネントを運営している人が可用性を維持することが経済的に有利になる可能性があります。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). + +## 謝辞 {#acknowledgements} + +- Josh Critesはこの記事の草稿を読み、厄介なNoirの問題を手伝ってくれました。 + +残りの誤りは私の責任です。 diff --git a/public/content/translations/ja/developers/tutorials/calling-a-smart-contract-from-javascript/index.md b/public/content/translations/ja/developers/tutorials/calling-a-smart-contract-from-javascript/index.md index 037235d134c..ff0e19a72a3 100644 --- a/public/content/translations/ja/developers/tutorials/calling-a-smart-contract-from-javascript/index.md +++ b/public/content/translations/ja/developers/tutorials/calling-a-smart-contract-from-javascript/index.md @@ -1,12 +1,8 @@ --- -title: JavaScriptからスマートコントラクトを呼び出す -description: Daiトークンを使ってJavaScriptでスマートコントラクトを呼び出す方法 +title: "JavaScriptからスマートコントラクトを呼び出す" +description: "Daiトークンを例に、JavaScriptでスマートコントラクトの関数を呼び出す方法" author: jdourlens -tags: - - "トランザクション" - - "フロントエンド" - - "JavaScript" - - "web3.js" +tags: [ "トランザクション", "フロントエンド", "JavaScript", "web3.js" ] skill: beginner lang: ja published: 2020-04-19 @@ -15,15 +11,15 @@ sourceUrl: https://ethereumdev.io/calling-a-smart-contract-from-javascript/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -このチュートリアルでは、JavaScriptから[スマートコントラクト](/developers/docs/smart-contracts/)関数を呼び出す方法を見ていきます。 最初はスマートコントラクトの状態(ERC20保有者の残高など)を読み取り、次にトークンの送金を行うことでブロックチェーンの状態を変更します。 [JS環境を設定して](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/)ブロックチェーンと対話することにはすでに慣れているはずです。 +このチュートリアルでは、JavaScriptから[スマートコントラクト](/developers/docs/smart-contracts/)関数を呼び出す方法を見ていきます。 最初はスマートコントラクトの状態(ERC20保有者の残高など)を読み取り、次にトークンの送金を行うことでブロックチェーンの状態を変更します。 すでに[ブロックチェーンとやり取りするためのJS環境の設定](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/)に精通している必要があります。 -今回の例では、DAIトークンを使います。テストのために、ganache-cliを使ってブロックチェーンをフォークし、すでに大量のDAIを持っているアドレスをアンロックします。 +今回の例では、DAIトークンを使います。テストのために、ganache-cliを使ってブロックチェーンをフォークし、すでに大量のDAIを持っているアドレスのロックを解除します。 ```bash ganache-cli -f https://mainnet.infura.io/v3/[YOUR INFURA KEY] -d -i 66 1 --unlock 0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81 ``` -スマートコントラクトと対話するのに必要なアドレスとABI: +スマートコントラクトとやり取りするには、そのアドレスとABIが必要です。 ```js const ERC20TransferABI = [ @@ -74,7 +70,7 @@ const ERC20TransferABI = [ const DAI_ADDRESS = "0x6b175474e89094c44da98b954eedeac495271d0f" ``` -今回は、完全なERC20 ABIではなく、簡略化して`balanceOf`と`transfer`関数だけを残しました。ERC20 ABIの完全版は[こちら](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/)でご覧いただけます。 +このプロジェクトでは、完全なERC20 ABIから`balanceOf`関数と`transfer`関数のみを残しました。完全なERC20のABIは[こちら](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/)で確認できます。 次に、スマートコントラクトをインスタンス化する必要があります。 @@ -84,52 +80,52 @@ const web3 = new Web3("http://localhost:8545") const daiToken = new web3.eth.Contract(ERC20TransferABI, DAI_ADDRESS) ``` -次の2つのアドレスも設定します： +また、2つのアドレスを設定します。 -- 送金先アドレス -- アンロック済みの送金元アドレス +- 送金先のアドレス +- ロック解除済みの送金元アドレス: ```js const senderAddress = "0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81" const receiverAddress = "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" ``` -次のパートでは、両方のアドレスが保有している現在のトークンの量を取得するために`balanceOf`関数を呼び出します。 +次のパートでは、`balanceOf`関数を呼び出して、両方のアドレスが保有している現在のトークン量を取得します。 -## Call: スマートコントラクトから値を読み込む {#call-reading-value-from-a-smart-contract} +## コール：スマートコントラクトからの値の読み取り {#call-reading-value-from-a-smart-contract} -最初の例では、トランザクションを送信することなく、「constant」メソッドを呼び出し、スマートコントラクトメソッドをEVMで実行します。 そのために、まずはアドレスのERC20の残高を読み込みます。 [ERC20トークンに関する記事](/developers/tutorials/understand-the-erc-20-token-smart-contract/)をご覧ください。 +最初の例では、「constant」メソッドを呼び出し、トランザクションを送信することなく、EVMでスマートコントラクトメソッドを実行します。 そのために、アドレスのERC20残高を読み取ります。 [ERC20トークンに関する記事をお読みください](/developers/tutorials/understand-the-erc-20-token-smart-contract/) -ABIを提供した、インスタンス化されたスマートコントラクトのメソッドには、`yourContract.methods.methodname`でアクセスできます。 `call`関数を使用して、関数を実行した結果を受け取ることができます。 +ABIを提供してインスタンス化されたスマートコントラクトのメソッドには、`yourContract.methods.methodname`のようにアクセスできます。 `call`関数を使用することで、関数を実行した結果を受け取ることができます。 ```js daiToken.methods.balanceOf(senderAddress).call(function (err, res) { if (err) { - console.log("An error occurred", err) + console.log("エラーが発生しました", err) return } - console.log("The balance is: ", res) + console.log("残高は: ", res) }) ``` -ERC20のDAIには18桁の0があり、正しい数値を得るためには18桁の0を削除する必要があります。 Javascriptは大きな数値を扱えないため、uint256は文字列で返されます。 JavaScriptで大きな数字を扱う方法がご不明の場合、[JavaScriptで大きな数字を扱うbignumber.jsのチュートリアルをご覧ください。](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/) +DAI ERC20は18桁の小数位を持つことを覚えておいてください。これは、正しい量を得るには、値から18個のゼロを削除する必要があることを意味します。 JavaScriptは大きな数値を扱えないため、uint256は文字列として返されます。 JSで大きな数値を扱う方法がわからない場合は、[bignumber.jsに関するチュートリアル](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/)をご覧ください。 -## send: スマートコントラクト関数にトランザクションを送信する {#send-sending-a-transaction-to-a-smart-contract-function} +## センド：スマートコントラクト関数へのトランザクションの送信 {#send-sending-a-transaction-to-a-smart-contract-function} -2番目の例では、DAIスマートコントラクトのtransfer関数を呼び出し、2番目のアドレスに10DAIを送信します。 このtransfer関数では、受取人のアドレスと送金するトークン数の2つのパラメータが必要です。 +2番目の例では、DAIスマートコントラクトの`transfer`関数を呼び出して、2つ目のアドレスに10 DAIを送信します。 `transfer`関数は2つのパラメータを受け取ります。送金先のアドレスと送金するトークンの量です。 ```js daiToken.methods .transfer(receiverAddress, "100000000000000000000") .send({ from: senderAddress }, function (err, res) { if (err) { - console.log("An error occurred", err) + console.log("エラーが発生しました", err) return } - console.log("Hash of the transaction: " + res) + console.log("トランザクションのハッシュ: " + res) }) ``` -また、call関数は、ブロックチェーンに組み込まれるトランザクションのハッシュを返します。 イーサリアムではトランザクションハッシュを予測できるため、トランザクションが実行される前にハッシュを取得することができます([ここでハッシュの計算方法を学びます](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction))。 +`send`関数は、ブロックチェーンにマイニングされるトランザクションのハッシュを返します。 イーサリアムでは、トランザクションハッシュは予測可能です。そのため、トランザクションが実行される前にハッシュを取得できます([ハッシュの計算方法はこちら](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction)をご覧ください)。 -関数はブロックチェーンにトランザクションを送るだけなので、マイニングされてブロックチェーンに組み込まれるまで結果は分かりません。 次のチュートリアルでは、[ハッシュ](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/)を使用してブロックチェーンでトランザクションが実行されるのを待つ方法を学びます。 +この関数はトランザクションをブロックチェーンに送信するだけなので、それがマイニングされブロックチェーンに含まれるまでは結果を確認できません。 次のチュートリアルでは、[ハッシュを使って、トランザクションがブロックチェーン上で実行されるのを待つ方法](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/)を学びます。 diff --git a/public/content/translations/ja/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/translations/ja/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md new file mode 100644 index 00000000000..df3b0483af7 --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md @@ -0,0 +1,585 @@ +--- +title: "コントラクトのユーザーインターフェースを構築する" +description: "TypeScript、React、Vite、Wagmiといった最新のコンポーネントを使用して、モダンでありながら最小限のユーザーインターフェースをレビューし、ウォレットをユーザーインターフェースに接続する方法、スマートコントラクトを呼び出して情報を読み取る方法、スマートコントラクトにトランザクションを送信する方法、スマートコントラクトからのイベントを監視して変更を特定する方法を学びます。" +author: Ori Pomerantz +tags: [ "TypeScript", "react", "vite", "wagmi", "フロントエンド" ] +skill: beginner +published: 2023-11-01 +lang: ja +sidebarDepth: 3 +--- + +Ethereumエコシステムに必要な機能を見つけました。 それを実装するためにスマートコントラクトを作成し、オフチェーンで実行される関連コードもいくつか作成したかもしれません。 素晴らしいことです！ 残念ながら、ユーザーインターフェースがなければユーザーはつきませんし、前回ウェブサイトを作成したときは、人々はダイヤルアップモデムを使い、JavaScriptはまだ新しいものでした。 + +この記事は、そんなあなたのためのものです。 プログラミングの知識があり、JavaScriptやHTMLについても少しは知っているけれど、ユーザーインターフェースのスキルは錆びついて時代遅れだと想定しています。 一緒にシンプルな最新のアプリケーションをレビューし、最近ではどのように行われているかを見ていきましょう。 + +## なぜこれが重要なのか {#why-important} + +[Etherscan](https://holesky.etherscan.io/address/0x432d810484add7454ddb3b5311f0ac2e95cecea8#writeContract)や[Blockscout](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=write_contract)を使って、人々にコントラクトを操作してもらうことも理論上は可能です。 経験豊富なEthereanにとっては、それで十分でしょう。 しかし、私たちは[さらに10億人の人々](https://blog.ethereum.org/2021/05/07/ethereum-for-the-next-billion)にサービスを提供しようとしています。 これは優れたユーザーエクスペリエンスなしには実現できません。そして、フレンドリーなユーザーインターフェースはその大きな部分を占めています。 + +## Greeterアプリケーション {#greeter-app} + +モダンなUIの仕組みの背景には多くの理論があり、[それを説明する](https://wagmi.sh/core/getting-started)[優れたサイトもたくさんあります](https://react.dev/learn/thinking-in-react)。 これらのサイトで行われている素晴らしい作業を繰り返す代わりに、実際に触って学べるアプリケーションから始めることを好むと仮定します。 物事を進めるにはまだ理論が必要で、それにも触れます。ただ、ソースファイルごとに進め、それらに到達するたびに物事を議論していきます。 + +### インストール {#installation} + +1. 必要に応じて、[Holeskyブロックチェーン](https://chainlist.org/?search=holesky&testnets=true)をウォレットに追加し、[テストETHを入手](https://www.holeskyfaucet.io/)してください。 + +2. GitHubリポジトリをクローンします。 + + ```sh + git clone https://github.com/qbzzt/20230801-modern-ui.git + ``` + +3. 必要なパッケージをインストールします。 + + ```sh + cd 20230801-modern-ui + pnpm install + ``` + +4. アプリケーションを起動します。 + + ```sh + pnpm dev + ``` + +5. アプリケーションによって表示されたURLに移動します。 ほとんどの場合、それは[http://localhost:5173/](http://localhost:5173/)です。 + +6. HardhatのGreeterを少し修正したコントラクトのソースコードを、[ブロックチェーンエクスプローラー](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contract)で確認できます。 + +### ファイルのウォークスルー {#file-walk-through} + +#### `index.html` {#index-html} + +このファイルは、スクリプトファイルをインポートするこの行を除いて、標準的なHTMLの定型文です。 + +```html + +``` + +#### `src/main.tsx` {#main-tsx} + +このファイル拡張子は、このファイルが[TypeScript](https://www.typescriptlang.org/)で書かれた[Reactコンポーネント](https://www.w3schools.com/react/react_components.asp)であることを示しています。TypeScriptは、[型チェック](https://en.wikipedia.org/wiki/Type_system#Type_checking)をサポートするJavaScriptの拡張機能です。 TypeScriptはJavaScriptにコンパイルされるため、クライアントサイドでの実行に使用できます。 + +```tsx +import '@rainbow-me/rainbowkit/styles.css' +import { RainbowKitProvider } from '@rainbow-me/rainbowkit' +import * as React from 'react' +import * as ReactDOM from 'react-dom/client' +import { WagmiConfig } from 'wagmi' +import { chains, config } from './wagmi' +``` + +必要なライブラリコードをインポートします。 + +```tsx +import { App } from './App' +``` + +アプリケーションを実装するReactコンポーネントをインポートします(下記参照)。 + +```tsx +ReactDOM.createRoot(document.getElementById('root')!).render( +``` + +ルートのReactコンポーネントを作成します。 `render`のパラメータは[JSX](https://www.w3schools.com/react/react_jsx.asp)です。これはHTMLとJavaScript/TypeScriptの両方を使用する拡張言語です。 ここでの感嘆符は、TypeScriptコンポーネントに「`document.getElementById('root')`が`ReactDOM.createRoot`の有効なパラメータになるかどうかはわからないでしょうが、心配しないでください。私は開発者であり、そうなることを保証します」と伝えています。 + +```tsx + +``` + +アプリケーションは[`React.StrictMode`コンポーネント](https://react.dev/reference/react/StrictMode)の中に入ります。 このコンポーネントは、Reactライブラリに追加のデバッグチェックを挿入するように指示します。これは開発中に役立ちます。 + +```tsx + +``` + +アプリケーションは[`WagmiConfig`コンポーネント](https://wagmi.sh/react/api/WagmiProvider)の中にもあります。 [wagmi (we are going to make it) ライブラリ](https://wagmi.sh/)は、ReactのUI定義を[viemライブラリ](https://viem.sh/)に接続し、イーサリアムの分散型アプリケーションを作成します。 + +```tsx + +``` + +そして最後に、[`RainbowKitProvider`コンポーネント](https://www.rainbowkit.com/)です。 このコンポーネントは、ログインとウォレットとアプリケーション間の通信を処理します。 + +```tsx + +``` + +これで、実際にUIを実装するアプリケーション用のコンポーネントを持つことができます。 コンポーネントの最後にある`/>`は、XML標準に従い、このコンポーネント内に定義がないことをReactに伝えます。 + +```tsx + + + , +) +``` + +もちろん、他のコンポーネントも閉じる必要があります。 + +#### `src/App.tsx` {#app-tsx} + +```tsx +import { ConnectButton } from '@rainbow-me/rainbowkit' +import { useAccount } from 'wagmi' +import { Greeter } from './components/Greeter' + +export function App() { +``` + +これはReactコンポーネントを作成する標準的な方法です。レンダリングが必要になるたびに呼び出される関数を定義します。 この関数は通常、上部にTypeScriptまたはJavaScriptコードがあり、その後にJSXコードを返す`return`ステートメントが続きます。 + +```tsx + const { isConnected } = useAccount() +``` + +ここで[`useAccount`](https://wagmi.sh/react/api/hooks/useAccount)を使用して、ウォレットを介してブロックチェーンに接続されているかどうかを確認します。 + +慣例として、Reactでは`use...`という名前の関数は、何らかのデータを返す[フック](https://www.w3schools.com/react/react_hooks.asp)です。 このようなフックを使用すると、コンポーネントがデータを取得するだけでなく、そのデータが変更されると、コンポーネントは更新された情報で再レンダリングされます。 + +```tsx + return ( + <> +``` + +ReactコンポーネントのJSXは、1つのコンポーネントを返す_必要_があります。 複数のコンポーネントがあり、「自然に」まとめるものがない場合は、空のコンポーネント(`<> ... `)を使用して、それらを1つのコンポーネントにまとめます。 + +```tsx +

Greeter

+ +``` + +[`ConnectButton`コンポーネント](https://www.rainbowkit.com/docs/connect-button)はRainbowKitから取得します。 接続されていない場合は、`Connect Wallet`ボタンが表示され、ウォレットについて説明し、使用するウォレットを選択できるモーダルが開きます。 接続されると、使用しているブロックチェーン、アカウントアドレス、ETH残高が表示されます。 これらの表示を使用して、ネットワークを切り替えたり、切断したりできます。 + +```tsx + {isConnected && ( +``` + +実際のJavaScript(またはJavaScriptにコンパイルされるTypeScript)をJSXに挿入する必要がある場合は、括弧(`{}`)を使用します。 + +`a && b`という構文は、[`a ?`の短縮形です。 `b : a`](https://www.w3schools.com/react/react_es6_ternary.asp)。 つまり、`a`が真の場合、`b`に評価され、それ以外の場合は`a`(`false`、`0`など)に評価されます。 これは、特定の条件が満たされた場合にのみコンポーネントを表示するようにReactに指示する簡単な方法です。 + +この場合、ユーザーがブロックチェーンに接続されている場合にのみ、ユーザーに`Greeter`を表示したいと考えています。 + +```tsx + + )} + + ) +} +``` + +#### `src/components/Greeter.tsx` {#greeter-tsx} + +このファイルには、UI機能のほとんどが含まれています。 これには通常、複数のファイルに含まれる定義が含まれていますが、これはチュートリアルであるため、プログラムはパフォーマンスやメンテナンスの容易さよりも、初回で理解しやすいように最適化されています。 + +```tsx +import { useState, ChangeEventHandler } from 'react' +import { useNetwork, + useReadContract, + usePrepareContractWrite, + useContractWrite, + useContractEvent + } from 'wagmi' +``` + +これらのライブラリ関数を使用します。 繰り返しになりますが、これらは使用される場所で以下に説明されています。 + +```tsx +import { AddressType } from 'abitype' +``` + +[`abitype`ライブラリ](https://abitype.dev/)は、[`AddressType`](https://abitype.dev/config#addresstype)など、さまざまなイーサリアムのデータ型に対するTypeScriptの定義を提供します。 + +```tsx +let greeterABI = [ + . + . + . +] as const // greeterABI +``` + +`Greeter`コントラクトのABIです。 +コントラクトとUIを同時に開発している場合、通常はそれらを同じリポジトリに配置し、Solidityコンパイラによって生成されたABIをアプリケーション内のファイルとして使用します。 ただし、コントラクトはすでに開発済みで変更されないため、ここではその必要はありません。 + +```tsx +type AddressPerBlockchainType = { + [key: number]: AddressType +} +``` + +TypeScriptは静的型付け言語です。 この定義を使用して、`Greeter`コントラクトが異なるチェーンにデプロイされているアドレスを指定します。 キーは数値(chainId)で、値は`AddressType`(アドレス)です。 + +```tsx +const contractAddrs: AddressPerBlockchainType = { + // Holesky + 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8', + + // Sepolia + 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0' +} +``` + +サポートされている2つのネットワーク、[Holesky](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contact_code)と[Sepolia](https://eth-sepolia.blockscout.com/address/0x7143d5c190F048C8d19fe325b748b081903E3BF0?tab=contact_code)上のコントラクトのアドレスです。 + +注意: 実際にはRedstone Holesky用に3番目の定義がありますが、これについては後ほど説明します。 + +```tsx +type ShowObjectAttrsType = { + name: string, + object: any +} +``` + +この型は、`ShowObject`コンポーネント(後述)へのパラメータとして使用されます。 これには、デバッグ目的で表示されるオブジェクトの名前とその値が含まれます。 + +```tsx +type ShowGreetingAttrsType = { + greeting: string | undefined +} +``` + +どの時点でも、あいさつの内容を知っているか(ブロックチェーンから読み取ったため)、知らないか(まだ受信していないため)のどちらかです。 したがって、文字列または何もないかのどちらかになりうる型があると便利です。 + +##### `Greeter`コンポーネント {#greeter-component} + +```tsx +const Greeter = () => { +``` + +最後に、コンポーネントを定義します。 + +```tsx + const { chain } = useNetwork() +``` + +使用しているチェーンに関する情報は、[wagmi](https://wagmi.sh/react/hooks/useNetwork)から提供されます。 +これはフック(`use...`)なので、この情報が変更されるたびにコンポーネントが再描画されます。 + +```tsx + const greeterAddr = chain && contractAddrs[chain.id] +``` + +Greeterコントラクトのアドレスはチェーンによって異なり、チェーン情報がない場合や、そのコントラクトが存在しないチェーン上にある場合は`undefined`になります。 + +```tsx + const readResults = useReadContract({ + address: greeterAddr, + abi: greeterABI, + functionName: "greet" , // No arguments + watch: true + }) +``` + +[`useReadContract`フック](https://wagmi.sh/react/api/hooks/useReadContract)は、コントラクトから情報を読み取ります。 UIで`readResults`を展開すると、それが返す情報を正確に確認できます。 この場合、あいさつが変更されたときに通知されるように、監視を続けたいと考えています。 + +**注意:** [`setGreeting`イベント](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=logs)をリッスンして、あいさつが変更されたことを知り、そのように更新することもできます。 ただし、より効率的かもしれませんが、すべての場合に適用できるわけではありません。 ユーザーが異なるチェーンに切り替えると、あいさつも変更されますが、その変更にはイベントが伴いません。 イベントをリッスンするコード部分と、チェーンの変更を識別する部分を分けることもできますが、それは単に[`watch`パラメータ](https://wagmi.sh/react/api/hooks/useReadContract#watch-optional)を設定するよりも複雑になります。 + +```tsx + const [ newGreeting, setNewGreeting ] = useState("") +``` + +Reactの[`useState`フック](https://www.w3schools.com/react/react_usestate.asp)を使用すると、コンポーネントのレンダリング間で値が持続する状態変数を指定できます。 初期値はパラメータであり、この場合は空の文字列です。 + +`useState`フックは、2つの値を持つリストを返します。 + +1. 状態変数の現在の値。 +2. 必要に応じて状態変数を変更する関数。 これはフックなので、呼び出されるたびにコンポーネントが再レンダリングされます。 + +この場合、ユーザーが設定したい新しいあいさつのために状態変数を使用しています。 + +```tsx + const greetingChange : ChangeEventHandler = (evt) => + setNewGreeting(evt.target.value) +``` + +これは、新しいあいさつ入力フィールドが変更されたときのイベントハンドラです。 型[`ChangeEventHandler`](https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/forms_and_events/)は、これがHTML入力要素の値の変更に対するハンドラであることを指定します。 この``の部分は、これが[ジェネリック型](https://www.w3schools.com/typescript/typescript_basic_generics.php)であるために使用されます。 + +```tsx + const preparedTx = usePrepareContractWrite({ + address: greeterAddr, + abi: greeterABI, + functionName: 'setGreeting', + args: [ newGreeting ] + }) + const workingTx = useContractWrite(preparedTx.config) +``` + +これは、クライアント側からブロックチェーントランザクションを送信するプロセスです。 + +1. [`eth_estimateGas`](https://docs.alchemy.com/reference/eth-estimategas)を使用して、ブロックチェーン上のノードにトランザクションを送信します。 +2. ノードからの応答を待ちます。 +3. 応答が受信されたら、ウォレットを介してユーザーにトランザクションへの署名を求めます。 このステップは、ノードの応答が受信された後に行う_必要_があります。なぜなら、ユーザーは署名する前にトランザクションのガス代を表示されるからです。 +4. ユーザーが承認するのを待ちます。 +5. 今度は[`eth_sendRawTransaction`](https://docs.alchemy.com/reference/eth-sendrawtransaction)を使用して、トランザクションを再度送信します。 + +ステップ2は、体感できるほどの時間がかかる可能性があり、その間、ユーザーは自分のコマンドがユーザーインターフェースで本当に受信されたのか、なぜまだトランザクションへの署名を求められないのか、疑問に思うでしょう。 それは、悪いユーザーエクスペリエンス(UX)につながります。 + +解決策は、[prepareフック](https://wagmi.sh/react/prepare-hooks)を使用することです。 パラメータが変更されるたびに、すぐにノードに`eth_estimateGas`リクエストを送信します。 そして、ユーザーが実際にトランザクションを送信したいとき(この場合は**あいさつの更新**を押す)、ガス代が既知であるため、ユーザーはすぐにウォレットページを見ることができます。 + +```tsx + return ( +``` + +これで、ついに返す実際のHTMLを作成できます。 + +```tsx + <> +

Greeter

+ { + !readResults.isError && !readResults.isLoading && + + } +
+``` + +`ShowGreeting`コンポーネント(後述)を作成しますが、あいさつがブロックチェーンから正常に読み取られた場合に限ります。 + +```tsx + +``` + +これは、ユーザーが新しいあいさつを設定できる入力テキストフィールドです。 ユーザーがキーを押すたびに、`greetingChange`が呼び出され、それが`setNewGreeting`を呼び出します。 `setNewGreeting`は`useState`フックから来ているので、これにより`Greeter`コンポーネントが再びレンダリングされます。 このことは、次のことを意味します。 + +- 新しいあいさつの値を保持するために`value`を指定する必要があります。そうしないと、デフォルトの空の文字列に戻ってしまいます。 +- `usePrepareContractWrite`は`newGreeting`が変更されるたびに呼び出されるため、準備されたトランザクションには常に最新の`newGreeting`が含まれます。 + +```tsx + +``` + +`workingTx.write`がない場合は、あいさつの更新を送信するために必要な情報をまだ待っているため、ボタンは無効になります。 `workingTx.write`の値がある場合、それがトランザクションを送信するために呼び出す関数です。 + +```tsx +
+ + + + + ) +} +``` + +最後に、何をしているかを確認しやすくするために、使用する3つのオブジェクトを表示します。 + +- `readResults` +- `preparedTx` +- `workingTx` + +##### `ShowGreeting`コンポーネント {#showgreeting-component} + +このコンポーネントは、 + +```tsx +const ShowGreeting = (attrs : ShowGreetingAttrsType) => { +``` + +コンポーネント関数は、コンポーネントのすべての属性を持つパラメータを受け取ります。 + +```tsx + return {attrs.greeting} +} +``` + +##### `ShowObject`コンポーネント {#showobject-component} + +情報提供を目的として、`ShowObject`コンポーネントを使用して、重要なオブジェクト(あいさつを読み取るための`readResults`と、作成するトランザクションのための`preparedTx`および`workingTx`)を表示します。 + +```tsx +const ShowObject = (attrs: ShowObjectAttrsType ) => { + const keys = Object.keys(attrs.object) + const funs = keys.filter(k => typeof attrs.object[k] == "function") + return <> +
+``` + +すべての情報でUIが乱雑にならないように、表示したり閉じたりできるようにするために、[`details`](https://www.w3schools.com/tags/tag_details.asp)タグを使用します。 + +```tsx + {attrs.name} + 
+        {JSON.stringify(attrs.object, null, 2)}
+```
+
+ほとんどのフィールドは、[`JSON.stringify`](https://www.w3schools.com/js/js_json_stringify.asp)を使用して表示されます。
+
+```tsx
+
+ { funs.length > 0 && + <> + Functions: +
    +``` + +例外は関数で、[JSON標準](https://www.json.org/json-en.html)の一部ではないため、別々に表示する必要があります。 + +```tsx + {funs.map((f, i) => +``` + +JSX内では、`{`中括弧`}`内のコードはJavaScriptとして解釈されます。 そして、`(`丸括弧`)`内のコードは、再びJSXとして解釈されます。 + +```tsx + (
  • {f}
    • ) + )} +``` + +Reactは、[DOMツリー](https://www.w3schools.com/js/js_htmldom.asp)内のタグに一意の識別子を必要とします。 これは、同じタグの子(この場合は、[順序なしリスト](https://www.w3schools.com/tags/tag_ul.asp))が、異なる`key`属性を必要とすることを意味します。 + +```tsx +
+ + } +
+ +} +``` + +様々なHTMLタグを閉じます。 + +##### 最後の`export` {#the-final-export} + +```tsx +export { Greeter } +``` + +`Greeter`コンポーネントは、アプリケーションにエクスポートする必要があるものです。 + +#### `src/wagmi.ts` {#wagmi-ts} + +最後に、WAGMIに関連するさまざまな定義が`src/wagmi.ts`にあります。 ほとんどが変更する必要のない定型文であるため、ここではすべてを説明するつもりはありません。 + +ここでのコードは、記事の後半で別のチェーン([Redstone Holesky](https://redstone.xyz/docs/network-info))を追加するため、[GitHub上のもの](https://github.com/qbzzt/20230801-modern-ui/blob/main/src/wagmi.ts)と完全に同じではありません。 + +```ts +import { getDefaultWallets } from '@rainbow-me/rainbowkit' +import { configureChains, createConfig } from 'wagmi' +import { holesky, sepolia } from 'wagmi/chains' +``` + +アプリケーションがサポートするブロックチェーンをインポートします。 サポートされているチェーンのリストは、[viemのGitHub](https://github.com/wagmi-dev/viem/tree/main/src/chains/definitions)で確認できます。 + +```ts +import { publicProvider } from 'wagmi/providers/public' + +const walletConnectProjectId = 'c96e690bb92b6311e8e9b2a6a22df575' +``` + +[WalletConnect](https://walletconnect.com/)を使用するには、アプリケーションのプロジェクトIDが必要です。 これは[cloud.walletconnect.com](https://cloud.walletconnect.com/sign-in)で取得できます。 + +```ts +const { chains, publicClient, webSocketPublicClient } = configureChains( + [ holesky, sepolia ], + [ + publicProvider(), + ], +) + +const { connectors } = getDefaultWallets({ + appName: 'My wagmi + RainbowKit App', + chains, + projectId: walletConnectProjectId, +}) + +export const config = createConfig({ + autoConnect: true, + connectors, + publicClient, + webSocketPublicClient, +}) + +export { chains } +``` + +### 別のブロックチェーンの追加 {#add-blockchain} + +最近では多くの[L2スケーリングソリューション](/layer-2/)があり、viemがまだサポートしていないものをサポートしたいと思うかもしれません。 そのためには、`src/wagmi.ts`を修正します。 これらの手順は、[Redstone Holesky](https://redstone.xyz/docs/network-info)を追加する方法を説明しています。 + +1. viemから`defineChain`型をインポートします。 + + ```ts + import { defineChain } from 'viem' + ``` + +2. ネットワーク定義を追加します。 + + ```ts + const redstoneHolesky = defineChain({ + id: 17_001, + name: 'Redstone Holesky', + network: 'redstone-holesky', + nativeCurrency: { + decimals: 18, + name: 'Ether', + symbol: 'ETH', + }, + rpcUrls: { + default: { + http: ['https://rpc.holesky.redstone.xyz'], + webSocket: ['wss://rpc.holesky.redstone.xyz/ws'], + }, + public: { + http: ['https://rpc.holesky.redstone.xyz'], + webSocket: ['wss://rpc.holesky.redstone.xyz/ws'], + }, + }, + blockExplorers: { + default: { name: 'Explorer', url: 'https://explorer.holesky.redstone.xyz' }, + }, + }) + ``` + +3. `configureChains`呼び出しに新しいチェーンを追加します。 + + ```ts + const { chains, publicClient, webSocketPublicClient } = configureChains( + [ holesky, sepolia, redstoneHolesky ], + [ publicProvider(), ], + ) + ``` + +4. アプリケーションが新しいネットワーク上のコントラクトのアドレスを認識していることを確認します。 この場合、`src/components/Greeter.tsx`を次のように変更します。 + + ```ts + const contractAddrs : AddressPerBlockchainType = { + // Holesky + 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8', + + // Redstone Holesky + 17001: '0x4919517f82a1B89a32392E1BF72ec827ba9986D3', + + // Sepolia + 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0' + } + ``` + +## 結論 {#conclusion} + +もちろん、`Greeter`のユーザーインターフェースを提供することには、実際には関心がないでしょう。 独自のコントラクト用のユーザーインターフェースを作成したいはずです。 独自のアプリケーションを作成するには、次の手順を実行します。 + +1. wagmiアプリケーションを作成するよう指定します。 + + ```sh copy + pnpm create wagmi + ``` + +2. アプリケーションに名前を付けます。 + +3. **React**フレームワークを選択します。 + +4. **Vite**バリアントを選択します。 + +5. [Rainbow kitを追加](https://www.rainbowkit.com/docs/installation#manual-setup)できます。 + +さあ、あなたのコントラクトを世界中の人々が使えるようにしましょう。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). + diff --git a/public/content/translations/ja/developers/tutorials/deploying-your-first-smart-contract/index.md b/public/content/translations/ja/developers/tutorials/deploying-your-first-smart-contract/index.md index d16956e8b7c..7b958798aff 100644 --- a/public/content/translations/ja/developers/tutorials/deploying-your-first-smart-contract/index.md +++ b/public/content/translations/ja/developers/tutorials/deploying-your-first-smart-contract/index.md @@ -1,12 +1,8 @@ --- -title: はじめてスマートコントラクトをデプロイする -description: はじめてイーサリアムのテスト用ネットワークにスマートコントラクトをデプロイするユーザー向けのイントロダクション +title: "はじめてスマートコントラクトをデプロイする" +description: "初めてイーサリアムのテストネットにスマートコントラクトをデプロイするためのイントロダクション" author: "jdourlens" -tags: - - "スマートコントラクト" - - "Remix" - - "Solidity" - - "デプロイ" +tags: [ "スマートコントラクト", "Remix", "Solidity", "デプロイ" ] skill: beginner lang: ja published: 2020-04-03 @@ -15,15 +11,15 @@ sourceUrl: https://ethereumdev.io/deploying-your-first-smart-contract/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -皆さんも、私たちと同じように、はじめて[スマートコントラクト](/developers/docs/smart-contracts/)をイーサリアムのブロックチェーン上で[デプロイ](/developers/docs/smart-contracts/deploying/)し、やり取りを行うことにドキドキしていることでしょう。 +皆さんも私たちと同じように、イーサリアムのブロックチェーン上で初めての[スマートコントラクト](/developers/docs/smart-contracts/)を[デプロイ](/developers/docs/smart-contracts/deploying/)し、操作することにワクワクしていることでしょう。 -最初のスマートコントラクトは、 [ローカルテストネットワーク](/developers/docs/networks/) にデプロイするので心配は要りません。コストはまったくかからず、好きなだけ楽しむことができます。 +心配はいりません。初めてのスマートコントラクトなので、[ローカルテストネットワーク](/developers/docs/networks/)にデプロイします。デプロイしたり、好きなだけ試したりするのに費用はかかりません。 -## コントラクトの記述 {#writing-our-contract} +## コントラクトの作成 {#writing-our-contract} -まずはじめに、[Remix](https://remix.ethereum.org/)にアクセスし、新規ファイルを作成してください。 Remix画面の左上にあるアイコンから新規ファイルを追加し、適当なファイル名を付けてください。 +まず、[Remix](https://remix.ethereum.org/)にアクセスし、新規ファイルを作成します。 Remixインターフェースの左上で新規ファイルを追加し、好きなファイル名を入力します。 -![Remixインターフェースに新規ファイルを追加する](./remix.png) +![Remixインターフェースで新規ファイルを追加する](./remix.png) 作成したファイルに、以下のコードをペーストします。 @@ -33,15 +29,15 @@ pragma solidity >=0.5.17; contract Counter { - // Public variable of type unsigned int to keep the number of counts + // カウント数を保持するための符号なし整数のパブリック変数 uint256 public count = 0; - // Function that increments our counter + // カウンターをインクリメントする関数 function increment() public { count += 1; } - // Not necessary getter to get the count value + // カウント値を取得するためのゲッター(必須ではない) function getCount() public view returns (uint256) { return count; } @@ -49,51 +45,51 @@ contract Counter { } ``` -プログラミングの経験があれば、このプログラムの内容はすぐに推測できるでしょう。 以下は、各行ごとの説明です。 +プログラミングの経験があれば、このプログラムが何をするものか簡単に推測できるでしょう。 以下に各行を説明します: -- 4行目： `Counter`という名前のコントラクトを定義します。 -- 7行目：このコントラクトでは、`count`という名称を持つ、符号なしの0から始まる整数を保存します。 -- 10行目：最初の関数は、コントラクトの状態（ステート）を変更し、変数`の値`を`1増やします`。 -- 15行目：次の関数は、このスマートコントラクトに含まれない`count`変数の値を読み取るためのゲッターです。 ただし、このプログラムでは`count`変数をpublicで定義しているため、実際にはこの関数は必要ありません。例として挙げている点に注意してください。 +- 4行目: `Counter`という名前のコントラクトを定義します。 +- 7行目: このコントラクトは、0から始まる`count`という名前の符号なし整数を1つ保存します。 +- 10行目: 最初の関数はコントラクトの状態 (ステート) を変更し、`increment()`で変数`count`の値を1増やします。 +- 15行目: 2番目の関数は、スマートコントラクトの外部から`count`変数の値を読み取ることができるようにするための、単なるゲッターです。 `count`変数はpublicとして定義されているため、この関数は必須ではありませんが、例として示しています。 -皆さんがはじめて作成するシンプルなスマートコントラクトは、これですべてです。 ご覧のように、JavaやC++のようなオブジェクト指向のプログラミング言語のクラスに似ていますね。 それではさっそく、このコントラクトを使ってみましょう。 +初めてのシンプルなスマートコントラクトについては以上です。 ご存知かもしれませんが、これはJavaやC++のようなOOP (オブジェクト指向プログラミング) 言語のクラスに似ています。 それではさっそく、このコントラクトを使ってみましょう。 -## コントラクトをデプロイする {#deploying-our-contract} +## コントラクトのデプロイ {#deploying-our-contract} -最初のスマートコントラクトが作成できたので、ブロックチェーン上でデプロイして使用してみましょう。 +最初のスマートコントラクトが作成できたので、ブロックチェーン上でデプロイして使ってみましょう。 -[ブロックチェーン上でスマートコントラクトをデプロイする](/developers/docs/smart-contracts/deploying/)とは、実際のところ、受取人を指定せずに、コンパイルしたスマートコントラクトのコードを含むトランザクションを送信することです。 +[ブロックチェーン上でスマートコントラクトをデプロイする](/developers/docs/smart-contracts/deploying/)とは、実際には、受取人を指定せずに、コンパイルしたスマートコントラクトのコードを含むトランザクションを送信することです。 -コントラクトをコンパイルするには、まず、画面左側にある「compile（コンパイル）」のアイコンをクリックして[コントラクトをコンパイルします](/developers/docs/smart-contracts/compiling/)。 +まず、左側にあるコンパイルアイコンをクリックして[コントラクトをコンパイル](/developers/docs/smart-contracts/compiling/)します: -![Remixツールバー上の「compile」アイコン](./remix-compile-button.png) +![Remixツールバーのコンパイルアイコン](./remix-compile-button.png) -次に、「Compile（コンパイル）」ボタンをクリックします： +次に、コンパイルボタンをクリックします: -![Remix solidityコンパイラ上の「compile」ボタン](./remix-compile.png) +![Remix Solidityコンパイラのコンパイルボタン](./remix-compile.png) -「Auto compile（自動コンパイル）」のオプションを選択すると、テキストエディタ上で内容を保存するたびにコントラクトがコンパイルされるようになります。 +「Auto compile」オプションを選択すると、テキストエディタで内容を保存するたびにコントラクトが自動でコンパイルされるようになります。 -次に、「Deploy and run transactions（トランザクションのデプロイおよび実行」画面に移動します： +次に、「Deploy and run transactions」(トランザクションのデプロイと実行) 画面に移動します: -![Remixツールバー上の「deploy」アイコン](./remix-deploy.png) +![Remixツールバーのデプロイアイコン](./remix-deploy.png) -「Deploy and run transactions（トランザクションをデプロイし、実行する） 」の画面に移動したら、作成したコントラクト名が表示されていることをダブルチェックしてから、「Deploy（デプロイ）」をクリックします。 画面の上部から、現在の環境が「JavaScript VM」であると表示されているのを確認してください。これにより、作成したスマートコントラクトをローカルのテスト用ブロックチェーン上でデプロイし、やりとりを行うため、より高速なテストを無料で行うことができます。 +「Deploy and run transactions」画面で、ご自身のコントラクト名が表示されていることを再確認し、「Deploy」をクリックします。 ページ上部にあるように、現在の環境は「JavaScript VM」です。これは、スマートコントラクトをローカルのテスト用ブロックチェーン上にデプロイして操作することを意味し、より速く、手数料なしでテストができます。 -![Remix solidityコンパイラ上の「deploy」ボタン](./remix-deploy-button.png) +![Remix Solidityコンパイラのデプロイボタン](./remix-deploy-button.png) -「Deploy」ボタンをクリックすると、画面下部に作成したコントラクトが表示されます。 画面左側にある矢印をクリックすると、コントラクトの内容が表示されます。 これが、このコントラクトにおける`counter`変数、`increment()`関数、およびゲッター`getCounter()`です。 +「Deploy」ボタンをクリックすると、画面下部にコントラクトが表示されます。 左側の矢印をクリックして展開すると、コントラクトの内容が表示されます。 これが、変数`counter`、`increment()`関数、そしてゲッターの`getCounter()`です。 -`count`もしくは`getCount`ボタンをクリックすると、このコントラクトの`count`変数の内容を取得して表示します。 この時点では`increment` 関数を呼び出していないので、「0」が表示されます。 +`count`または`getCount`ボタンをクリックすると、コントラクトの`count`変数の内容が取得、表示されます。 まだ`increment`関数を呼び出していないため、0が表示されるはずです。 -![Remix solidityコンパイラ上の「function」ボタン](./remix-function-button.png) +![Remix Solidityコンパイラの関数ボタン](./remix-function-button.png) -次に、 `increment`ボタンをクリックして、increment関数を呼び出しましょう。 ご覧のように、実行したトランザクションのログは、ウィンドウの下部に表示されます。 `increment`ボタンではなくデータ取得のボタンをクリックした場合、ログが変化することが分かると思います。 これは、ブロックチェーン上のデータを読み込む際には、トランザクション（書き込み）や手数料が必要ないためです。 つまり、トランザクションが必要となるのは、ブロックチェーンの状態を変更する場合のみです。 +では、ボタンをクリックして`increment`関数を呼び出してみましょう。 ウィンドウ下部に、実行されたトランザクションのログが表示されます。 `increment`ボタンではなくデータ取得のボタンを押した場合、ログが異なることがわかります。 これは、ブロックチェーン上のデータを読み込む際には、トランザクション (書き込み) や手数料が必要ないためです。 トランザクションが必要となるのは、ブロックチェーンの状態を変更する場合のみだからです: -![トランザクションログ](./transaction-log.png) +![トランザクションのログ](./transaction-log.png) -`increment()`機能を呼び出すトランザクションを作成する「increment」ボタンをクリックしてから「count」または「getCount」ボタンを再度クリックすると、count変数が「0」以上である更新後の状態のスマートコントラクトが読み込まれます。 +`increment()`関数を呼び出すトランザクションを生成するincrementボタンを押した後、`count`または`getCount`ボタンをもう一度クリックすると、`count`変数が0より大きくなった、スマートコントラクトの更新された状態を読み取ることができます。 -![更新後のスマートコントラクトの状態](./updated-state.png) +![スマートコントラクトの更新された状態](./updated-state.png) -次のチュートリアルでは、[スマートコントラクトにイベントを追加する方法](/developers/tutorials/logging-events-smart-contracts/)を学びます。 イベントログは、スマートコントラクトをデバッグし、関数の呼び出し中に何が起こっているかを理解するのに便利な方法です。 +次のチュートリアルでは、[スマートコントラクトにイベントを追加する方法](/developers/tutorials/logging-events-smart-contracts/)について説明します。 イベントをロギングすることは、スマートコントラクトをデバッグし、関数の呼び出し中に何が起きているかを理解するのに便利な方法です。 diff --git a/public/content/translations/ja/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md b/public/content/translations/ja/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md new file mode 100644 index 00000000000..f521255bb66 --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md @@ -0,0 +1,372 @@ +--- +title: "ローカルのマルチクライアントテストネットでdAppを開発・テストする方法" +description: "このガイドでは、まずマルチクライアントのローカルイーサリアムテストネットをインスタンス化して設定する方法を説明し、次にそのテストネットを使用してdAppをデプロイ&テストします。" +author: "Tedi Mitiku" +tags: + [ + "クライアント", + "ノード", + "スマートコントラクト", + "構成可能性", + "コンセンサスレイヤー", + "実行レイヤー", + "テスト" + ] +skill: intermediate +lang: ja +published: 2023-04-11 +--- + +## はじめに {#introduction} + +このガイドでは、設定可能なローカルイーサリアムテストネットのインスタンス化、そこへのスマートコントラクトのデプロイ、およびdAppに対するテストを実行するためのテストネットの使用というプロセスを順を追って説明します。 このガイドは、ライブのテストネットやメインネットにデプロイする前に、さまざまなネットワーク構成に対してdAppをローカルで開発・テストしたいdApp開発者向けに設計されています。 + +このガイドでは、次のことを行います。 + +- [Kurtosis](https://www.kurtosis.com/)を使用して、[`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package)でローカルイーサリアムテストネットをインスタンス化する +- Hardhat dApp開発環境をローカルテストネットに接続し、dAppをコンパイル、デプロイ、テストする、そして +- ノード数や特定のEL/CLクライアントのペアリングなどのパラメータを含むローカルテストネットを設定し、さまざまなネットワーク構成に対する開発およびテストのワークフローを可能にする。 + +### Kurtosisとは？ {#what-is-kurtosis} + +[Kurtosis](https://www.kurtosis.com/)は、マルチコンテナのテスト環境を構成するために設計された、構成可能なビルドシステムです。 これにより、開発者は、ブロックチェーンテストネットなどの動的なセットアップロジックを必要とする再現可能な環境を作成できます。 + +このガイドでは、Kurtosis eth-network-packageが、[`geth`](https://geth.ethereum.org/)実行レイヤー(EL)クライアント、および[`teku`](https://consensys.io/teku)、[`lighthouse`](https://lighthouse.sigmaprime.io/)、[`lodestar`](https://lodestar.chainsafe.io/)コンセンサスレイヤー(CL)クライアントをサポートするローカルイーサリアムテストネットを起動します。 このパッケージは、Hardhat Network、Ganache、Anvilのようなフレームワークのネットワークに代わる、設定可能で構成可能な代替手段として機能します。 Kurtosisは、開発者が使用するテストネットに対してより優れた制御と柔軟性を提供します。これは、[イーサリアム・ファウンデーションがマージのテストにKurtosisを使用した](https://www.kurtosis.com/blog/testing-the-ethereum-merge)主な理由であり、ネットワークのアップグレードをテストするためにKurtosisを使い続けている理由でもあります。 + +## Kurtosisのセットアップ {#setting-up-kurtosis} + +続行する前に、次のものがあることを確認してください。 + +- ローカルマシンに[Dockerエンジンをインストールして起動](https://docs.kurtosis.com/install/#i-install--start-docker)していること +- [Kurtosis CLIをインストール](https://docs.kurtosis.com/install#ii-install-the-cli)していること(CLIがすでにインストールされている場合は、最新リリースにアップグレードしていること) +- [Node.js](https://nodejs.org/en)、[yarn](https://classic.yarnpkg.com/lang/en/docs/install/#mac-stable)、および[npx](https://www.npmjs.com/package/npx) (dApp環境用) をインストールしていること + +## ローカルイーサリアムテストネットのインスタンス化 {#instantiate-testnet} + +ローカルイーサリアムテストネットを起動するには、次を実行します。 + +```python +kurtosis --enclave local-eth-testnet run github.com/kurtosis-tech/eth-network-package +``` + +注: このコマンドは、`--enclave`フラグを使用して、ネットワークに「local-eth-testnet」という名前を付けます。 + +Kurtosisは、指示を解釈、検証、そして実行する際に、内部で行われている手順を出力します。 最後に、次のような出力が表示されるはずです。 + +```python +INFO[2023-04-04T18:09:44-04:00] ====================================================== +INFO[2023-04-04T18:09:44-04:00] || Created enclave: local-eth-testnet || +INFO[2023-04-04T18:09:44-04:00] ====================================================== +Name: local-eth-testnet +UUID: 39372d756ae8 +Status: RUNNING +Creation Time: Tue, 04 Apr 2023 18:09:03 EDT + +========================================= Files Artifacts ========================================= +UUID Name +d4085a064230 cl-genesis-data +1c62cb792e4c el-genesis-data +bd60489b73a7 genesis-generation-config-cl +b2e593fe5228 genesis-generation-config-el +d552a54acf78 geth-prefunded-keys +5f7e661eb838 prysm-password +054e7338bb59 validator-keystore-0 + +========================================== User Services ========================================== +UUID Name Ports Status +e20f129ee0c5 cl-client-0-beacon http: 4000/tcp -> RUNNING + metrics: 5054/tcp -> + tcp-discovery: 9000/tcp -> 127.0.0.1:54263 + udp-discovery: 9000/udp -> 127.0.0.1:60470 +a8b6c926cdb4 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:54267 RUNNING + metrics: 5064/tcp -> +d7b802f623e8 el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:54253 RUNNING + rpc: 8545/tcp -> 127.0.0.1:54251 + tcp-discovery: 30303/tcp -> 127.0.0.1:54254 + udp-discovery: 30303/udp -> 127.0.0.1:53834 + ws: 8546/tcp -> 127.0.0.1:54252 +514a829c0a84 prelaunch-data-generator-1680646157905431468 STOPPED +62bd62d0aa7a prelaunch-data-generator-1680646157915424301 STOPPED +05e9619e0e90 prelaunch-data-generator-1680646157922872635 STOPPED + +``` + +おめでとうございます！ Kurtosisを使用して、CL (`lighthouse`)とELクライアント(`geth`)を持つローカルイーサリアムテストネットをDocker経由でインスタンス化しました。 + +### レビュー {#review-instantiate-testnet} + +このセクションでは、Kurtosisに[GitHubでリモートホストされている`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package)を使用して、Kurtosis [Enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/)内にローカルイーサリアムテストネットを起動するよう指示するコマンドを実行しました。 エンクレーブ内には、「ファイルアーティファクト」と「ユーザーサービス」の両方があります。 + +エンクレーブ内の[ファイルアーティファクト](https://docs.kurtosis.com/advanced-concepts/files-artifacts/)には、ELおよびCLクライアントをブートストラップするために生成および利用されたすべてのデータが含まれます。 データは、この[Dockerイメージ](https://github.com/ethpandaops/ethereum-genesis-generator)から構築された `prelaunch-data-generator` サービスを使用して作成されました。 + +ユーザーサービスには、エンクレーブで動作しているすべてのコンテナ化されたサービスが表示されます。 ELクライアントとCLクライアントの両方を備えた単一のノードが作成されていることがわかります。 + +## dApp開発環境をローカルイーサリアムテストネットに接続する {#connect-your-dapp} + +### dApp開発環境のセットアップ {#set-up-dapp-env} + +実行中のローカルテストネットができたので、dApp開発環境を接続してローカルテストネットを使用できます。 このガイドでは、Hardhatフレームワークを使用して、ブラックジャックdAppをローカルテストネットにデプロイします。 + +dApp開発環境をセットアップするには、サンプルdAppを含むリポジトリをクローンし、その依存関係をインストールして、次を実行します。 + +```python +git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-kurtosis/smart-contract-example && yarn +``` + +ここで使用する[smart-contract-example](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example)フォルダには、[Hardhat](https://hardhat.org/)フレームワークを使用するdApp開発者のための一般的なセットアップが含まれています。 + +- [`contracts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/contracts) には、Blackjack dApp用のいくつかのシンプルなスマートコントラクトが含まれています +- [`scripts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/scripts) には、ローカルのイーサリアムネットワークにトークンコントラクトをデプロイするためのスクリプトが含まれています +- [`test/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/test) には、Blackjack dAppの各プレイヤーに1000がミントされていることを確認するための、トークンコントラクト用の簡単な .js テストが含まれています +- [`hardhat.config.ts`](https://github.com/kurtosis-tech/awesome-kurtosis/blob/main/smart-contract-example/hardhat.config.ts) はHardhatセットアップを構成します + +### Hardhatがローカルテストネットを使用するように設定する {#configure-hardhat} + +dApp開発環境がセットアップされたので、今度はHardhatを接続して、Kurtosisを使用して生成されたローカルイーサリアムテストネットを使用します。 これを実現するには、`hardhat.config.ts`設定ファイルの`localnet`構造体にある`<$YOUR_PORT>`を、任意の`el-client-`サービスから出力されたrpc uriのポートに置き換えます。 このサンプルケースでは、ポートは`64248`になります。 ポートは異なります。 + +`hardhat.config.ts`での例: + +```js +localnet: { +url: 'http://127.0.0.1:<$YOUR_PORT>',// TODO: $YOUR_PORTを、ETH NETWORK KURTOSIS PACKAGEによって生成されたノードURIのポートに置き換えてください + +// これらはeth-network-packageによって作成された、事前に入金済みのテストアカウントに関連付けられた秘密鍵です +// +accounts: [ + "ef5177cd0b6b21c87db5a0bf35d4084a8a57a9d6a064f86d51ac85f2b873a4e2", + "48fcc39ae27a0e8bf0274021ae6ebd8fe4a0e12623d61464c498900b28feb567", + "7988b3a148716ff800414935b305436493e1f25237a2a03e5eebc343735e2f31", + "b3c409b6b0b3aa5e65ab2dc1930534608239a478106acf6f3d9178e9f9b00b35", + "df9bb6de5d3dc59595bcaa676397d837ff49441d211878c024eabda2cd067c9f", + "7da08f856b5956d40a72968f93396f6acff17193f013e8053f6fbb6c08c194d6", + ], +}, +``` + +ファイルを保存すると、Hardhat dApp開発環境がローカルイーサリアムテストネットに接続されます。 次を実行して、テストネットが機能していることを確認できます。 + +```python +npx hardhat balances --network localnet +``` + +出力は次のようになります。 + +```python +0x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766 has balance 10000000000000000000000000 +0x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A has balance 10000000000000000000000000 +0xdF8466f277964Bb7a0FFD819403302C34DCD530A has balance 10000000000000000000000000 +0x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50 has balance 10000000000000000000000000 +0x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc has balance 10000000000000000000000000 +0x1F6298457C5d76270325B724Da5d1953923a6B88 has balance 10000000000000000000000000 +``` + +これにより、Hardhatがローカルテストネットを使用しており、`eth-network-package`によって作成された事前に入金されたアカウントを検出していることが確認できます。 + +### dAppをローカルでデプロイしてテストする {#deploy-and-test-dapp} + +dApp開発環境がローカルイーサリアムテストネットに完全に接続されたので、ローカルテストネットを使用してdAppに対する開発およびテストワークフローを実行できます。 + +ローカルでのプロトタイピングと開発のために`ChipToken.sol`スマートコントラクトをコンパイルしてデプロイするには、次を実行します。 + +```python +npx hardhat compile +npx hardhat run scripts/deploy.ts --network localnet +``` + +出力は次のようになります。 + +```python +ChipTokenのデプロイ先: 0xAb2A01BC351770D09611Ac80f1DE076D56E0487d +``` + +次に、ローカルdAppに対して`simple.js`テストを実行し、Blackjack dAppの各プレイヤーに1000がミントされていることを確認します。 + +出力は次のようになります。 + +```python +npx hardhat test --network localnet +``` + +出力は次のようになります。 + +```python +ChipToken + mint + ✔ PLAYER ONEに1000チップがミントされるべき + + 1件合格 (654ms) +``` + +### レビュー {#review-dapp-workflows} + +この時点で、dApp開発環境をセットアップし、Kurtosisによって作成されたローカルイーサリアムネットワークに接続し、dAppに対してコンパイル、デプロイ、および簡単なテストを実行しました。 + +次に、さまざまなネットワーク構成でdAppをテストするために、基盤となるネットワークをどのように構成できるかを見ていきましょう。 + +## ローカルイーサリアムテストネットの設定 {#configure-testnet} + +### クライアント構成とノード数の変更 {#configure-client-config-and-num-nodes} + +ローカルイーサリアムテストネットは、開発またはテストしたいシナリオや特定のネットワーク構成に応じて、異なるELおよびCLクライアントペア、ならびにさまざまな数のノードを使用するように構成できます。 これは、一度セットアップすれば、カスタマイズされたローカルテストネットを起動し、それを使用して同じワークフロー(デプロイ、テストなど)を実行できることを意味します。 さまざまなネットワーク構成の下で、すべてが期待どおりに機能することを確認します。 変更できる他のパラメータの詳細については、このリンクをご覧ください。 + +試してみましょう。 JSONファイルを介して、さまざまな構成オプションを `eth-network-package` に渡すことができます。 このネットワークパラメータJSONファイルは、Kurtosisがローカルイーサリアムネットワークをセットアップするために使用する特定の設定を提供します。 + +デフォルトの設定ファイルを取得し、それを編集して、異なるEL/CLペアを持つ2つのノードを起動します。 + +- ノード1：`geth`/`lighthouse` +- ノード2：`geth`/`lodestar` +- ノード3：`geth`/`teku` + +この構成により、dAppをテストするためのイーサリアムノード実装の異種ネットワークが作成されます。 設定ファイルは次のようになります。 + +```yaml +{ + "participants": + [ + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "lighthouse", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "lodestar", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + { + "el_client_type": "geth", + "el_client_image": "", + "el_client_log_level": "", + "cl_client_type": "teku", + "cl_client_image": "", + "cl_client_log_level": "", + "beacon_extra_params": [], + "el_extra_params": [], + "validator_extra_params": [], + "builder_network_params": null, + }, + ], + "network_params": + { + "preregistered_validator_keys_mnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete", + "num_validator_keys_per_node": 64, + "network_id": "3151908", + "deposit_contract_address": "0x4242424242424242424242424242424242424242", + "seconds_per_slot": 12, + "genesis_delay": 120, + "capella_fork_epoch": 5, + }, +} +``` + +各`participants`構造体はネットワーク内のノードにマッピングされるため、3つの`participants`構造体はKurtosisにネットワーク内で3つのノードを起動するように指示します。 各`participants`構造体では、その特定のノードに使用されるELとCLのペアを指定できます。 + +`network_params`構造体は、各ノードのジェネシスファイルを作成するために使用されるネットワーク設定や、ネットワークのスロットごとの秒数などの他の設定を構成します。 + +編集したパラメータファイルを任意のディレクトリに保存し(以下の例ではデスクトップに保存)、次を実行してKurtosisパッケージを実行します。 + +```python +kurtosis clean -a && kurtosis run --enclave local-eth-testnet github.com/kurtosis-tech/eth-network-package "$(cat ~/eth-network-params.json)" +``` + +注: ここでは、`kurtosis clean -a`コマンドを使用して、新しいテストネットを開始する前に古いテストネットとその内容を破棄するようにKurtosisに指示します。 + +再び、Kurtosisは少しの間動作し、実行されている個々のステップを出力します。 最終的に、出力は次のようになります。 + +```python +Starlark code successfully run. No output was returned. +INFO[2023-04-07T11:43:16-04:00] ========================================================== +INFO[2023-04-07T11:43:16-04:00] || Created enclave: local-eth-testnet || +INFO[2023-04-07T11:43:16-04:00] ========================================================== +Name: local-eth-testnet +UUID: bef8c192008e +Status: RUNNING +Creation Time: Fri, 07 Apr 2023 11:41:58 EDT + +========================================= Files Artifacts ========================================= +UUID Name +cc495a8e364a cl-genesis-data +7033fcdb5471 el-genesis-data +a3aef43fc738 genesis-generation-config-cl +8e968005fc9d genesis-generation-config-el +3182cca9d3cd geth-prefunded-keys +8421166e234f prysm-password +d9e6e8d44d99 validator-keystore-0 +23f5ba517394 validator-keystore-1 +4d28dea40b5c validator-keystore-2 + +========================================== User Services ========================================== +UUID Name Ports Status +485e6fde55ae cl-client-0-beacon http: 4000/tcp -> http://127.0.0.1:65010 RUNNING + metrics: 5054/tcp -> http://127.0.0.1:65011 + tcp-discovery: 9000/tcp -> 127.0.0.1:65012 + udp-discovery: 9000/udp -> 127.0.0.1:54455 +73739bd158b2 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:65016 RUNNING + metrics: 5064/tcp -> http://127.0.0.1:65017 +1b0a233cd011 cl-client-1-beacon http: 4000/tcp -> 127.0.0.1:65021 RUNNING + metrics: 8008/tcp -> 127.0.0.1:65023 + tcp-discovery: 9000/tcp -> 127.0.0.1:65024 + udp-discovery: 9000/udp -> 127.0.0.1:56031 + validator-metrics: 5064/tcp -> 127.0.0.1:65022 +949b8220cd53 cl-client-1-validator http: 4000/tcp -> 127.0.0.1:65028 RUNNING + metrics: 8008/tcp -> 127.0.0.1:65030 + tcp-discovery: 9000/tcp -> 127.0.0.1:65031 + udp-discovery: 9000/udp -> 127.0.0.1:60784 + validator-metrics: 5064/tcp -> 127.0.0.1:65029 +c34417bea5fa cl-client-2 http: 4000/tcp -> 127.0.0.1:65037 RUNNING + metrics: 8008/tcp -> 127.0.0.1:65035 + tcp-discovery: 9000/tcp -> 127.0.0.1:65036 + udp-discovery: 9000/udp -> 127.0.0.1:63581 +e19738e6329d el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:64986 RUNNING + rpc: 8545/tcp -> 127.0.0.1:64988 + tcp-discovery: 30303/tcp -> 127.0.0.1:64987 + udp-discovery: 30303/udp -> 127.0.0.1:55706 + ws: 8546/tcp -> 127.0.0.1:64989 +e904687449d9 el-client-1 engine-rpc: 8551/tcp -> 127.0.0.1:64993 RUNNING + rpc: 8545/tcp -> 127.0.0.1:64995 + tcp-discovery: 30303/tcp -> 127.0.0.1:64994 + udp-discovery: 30303/udp -> 127.0.0.1:58096 + ws: 8546/tcp -> 127.0.0.1:64996 +ad6f401126fa el-client-2 engine-rpc: 8551/tcp -> 127.0.0.1:65003 RUNNING + rpc: 8545/tcp -> 127.0.0.1:65001 + tcp-discovery: 30303/tcp -> 127.0.0.1:65000 + udp-discovery: 30303/udp -> 127.0.0.1:57269 + ws: 8546/tcp -> 127.0.0.1:65002 +12d04a9dbb69 prelaunch-data-generator-1680882122181135513 STOPPED +5b45f9c0504b prelaunch-data-generator-1680882122192182847 STOPPED +3d4aaa75e218 prelaunch-data-generator-1680882122201668972 STOPPED +``` + +おめでとうございます！ ローカルテストネットを1つではなく3つのノードを持つように正常に設定しました。 dAppに対して以前と同じワークフロー(デプロイ＆テスト)を実行するには、新しい3ノードのローカルテストネットの`el-client-`サービスから出力されたrpc uriのポートで、`hardhat.config.ts`構成ファイルの`localnet`構造体にある`<$YOUR_PORT>`を置き換えることで、以前と同じ操作を実行します。 + +## 結論 {#conclusion} + +完成です！ この短いガイドを要約すると、次のことを行いました。 + +- Kurtosisを使用してDocker上にローカルイーサリアムテストネットを作成 +- ローカルdApp開発環境をローカルイーサリアムネットワークに接続 +- dAppをデプロイし、ローカルイーサリアムネットワーク上で簡単なテストを実行 +- 基盤となるイーサリアムネットワークを3つのノードを持つように構成 + +何がうまくいったか、何を改善できるか、また質問への回答など、ご意見をお聞かせください。 [GitHub](https://github.com/kurtosis-tech/kurtosis/issues/new/choose)または[メール](mailto:feedback@kurtosistech.com)でお気軽にご連絡ください。 + +### その他の例とガイド {#other-examples-guides} + +[クイックスタート](https://docs.kurtosis.com/quickstart)(PostgresデータベースとAPIを構築します)や、[awesome-kurtosisリポジトリ](https://github.com/kurtosis-tech/awesome-kurtosis)にあるその他の例を確認することをお勧めします。そこには、次のようなパッケージを含む素晴らしい例があります。 + +- [同じローカルイーサリアムテストネットを起動](https://github.com/kurtosis-tech/eth2-package)しますが、トランザクションスパマー(トランザクションをシミュレートするため)、フォークモニター、接続されたGrafanaおよびPrometheusインスタンスなどの追加サービスも接続します +- 同じローカルイーサリアムネットワークに対して[サブネットワーキングテスト](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/ethereum-network-partition-test)を実行する diff --git a/public/content/translations/ja/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md b/public/content/translations/ja/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md index fea349f4956..3dff5af33c7 100644 --- a/public/content/translations/ja/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md +++ b/public/content/translations/ja/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md @@ -1,60 +1,55 @@ --- title: "コントラクトのサイズ制限に対処するためのコントラクトのサイズ削減" -description: スマートコントラクトが大きくなりすぎるのを防ぐためにできること +description: "スマートコントラクトが大きくなりすぎるのを防ぐためにできること" author: Markus Waas lang: ja -tags: - - "Solidity" - - "スマートコントラクト" - - "ストレージ" +tags: [ "Solidity", "スマートコントラクト", "ストレージ" ] skill: intermediate published: 2020-06-26 source: soliditydeveloper.com sourceUrl: https://soliditydeveloper.com/max-contract-size --- -## 制限がある理由 {#why-is-there-a-limit} +## なぜ制限があるのですか？ {#why-is-there-a-limit} -[2016年11月22日](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/)、Spurious Dragonのハードフォークで[EIP-170](https://eips.ethereum.org/EIPS/eip-170)が導入され、24.576 KBのスマートコントラクトのサイズ制限が追加されました。 Solidityデベロッパーにとって、これはコントラクトに機能をどんどん追加していくうちに、ある時点でサイズ制限に達し、デプロイした際に以下のエラーが表示されてしまうということを意味します。 +2016年11月22日の[Spurious Dragonハードフォーク](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/)で、[EIP-170](https://eips.ethereum.org/EIPS/eip-170)が導入され、24.576kbのスマートコントラクトサイズ制限が追加されました。 Solidityデベロッパーにとって、これはコントラクトに機能をどんどん追加していくうちに、ある時点でサイズ制限に達し、デプロイした際に以下のエラーが表示されてしまうということを意味します。 -`Warning: Contract code size exceeds 24576 bytes (a limit introduced in Spurious Dragon). This contract may not be deployable on Mainnet. Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.` +`Warning: Contract code size exceeds 24576 bytes (Spurious Dragonで導入された制限)。 このコントラクトはメインネットではデプロイできない可能性があります。 オプティマイザを有効にする(低い\"runs\"値で！)、revert文字列をオフにする、またはライブラリを使用することを検討してください。` -この制限は、サービス拒否(DOS)攻撃を防ぐために導入されました。 コントラクトの呼び出しは、ガスの観点では比較的安価です。 しかし、イーサリアムノードのコントラクト呼び出しの影響は、(ディスクからのコードの読み込み、コードの前処理、マークルプルーフへのデータの追加の対象となる)呼び出されたコントラクトコードのサイズによっては、過度に増加することになります。 攻撃者がリソースをほとんど必要とせずに、他のノードでの大量の処理を生じさせるそうした状況では、DOS攻撃を受ける可能性が常に存在します。 +この制限は、サービス拒否(DOS)攻撃を防ぐために導入されました。 コントラクトの呼び出しは、ガスの観点では比較的安価です。 しかし、イーサリアムノードにとってコントラクト呼び出しの影響は、呼び出されるコントラクトコードのサイズ（ディスクからのコードの読み取り、コードの前処理、マークルプルーフへのデータの追加）に応じて不釣り合いに大きくなります。 攻撃者がリソースをほとんど必要とせずに、他のノードでの大量の処理を生じさせるそうした状況では、DOS攻撃を受ける可能性が常に存在します。 -コントラクトコードの固有のサイズ制限が、ブロックのガスリミットとなるため、本来これは問題ではありませんでした。 コントラクトは、コントラクトのバイトコードをすべて含むトランザクション内でデプロイされる必要があることは言うまでもありません。 ブロックに1つのトランザクションのみを含めると、そのガスのすべてを使うことができますが、無限ではありません。 [ロンドンアップグレード](/ethereum-forks/#london)以降、ブロックのガスリミットは、ネットワークの需要に応じて15M～30M間で変えられるようになりました。 +元々、これはそれほど問題ではありませんでした。なぜなら、ブロックのガスリミットが、コントラクトサイズの自然な制限となっていたからです。 言うまでもなく、コントラクトは、コントラクトのバイトコードをすべて含むトランザクション内でデプロイされる必要があります。 ブロックに1つのトランザクションのみを含めると、そのガスのすべてを使うことができますが、無限ではありません。 [ロンドンアップグレード](/ethereum-forks/#london)以降、ブロックのガスリミットはネットワークの需要に応じて15M～30Mユニットの間で変動可能になりました。 -次に、いくつかの方法を、効果が大きいものから順に見ていきます。 減量の観点から考えてみましょう。 目標体重(この場合は24 KB)を達成するための最良の戦略は、まず効果が大きい方法に集中して取り組むことです。 ほとんどの場合、食生活を改善するだけで解決しますが、もう少し何かが必要な場合もあります。 その場合は、運動(中程度の効果)やサプリメント(小さな効果)を加えるとよいでしょう。 +以下では、いくつかの方法を、その影響の大きい順に見ていきます。 減量の観点から考えてみましょう。 目標体重(この場合は24kb)を達成するための最良の戦略は、まず影響の大きい方法に集中することです。 ほとんどの場合、食生活を改善するだけで解決しますが、もう少し何かが必要な場合もあります。 その場合は、運動(中程度の影響)やサプリメント(小程度の影響)を追加することになるでしょう。 -## サイズ削減効果: 大 {#big-impact} +## 大きな影響 {#big-impact} -### コントラクトの分割 {#separate-your-contracts} +### コントラクトを分割する {#separate-your-contracts} -これは常に最初のアプローチであるべきです。 コントラクトを複数の小さなまとまりに分割するにはどうすればよいでしょうか? 一般的には、コントラクトのための良いアーキテクチャを考えなければなりません。 コードの読みやすさの観点からは、常に、小さなコントラクトコードが好まれます。 コントラクトの分割については、以下の質問を自問してください。 +これは常に最初のアプローチであるべきです。 コントラクトを複数の小さなまとまりに分割するにはどうすればよいでしょうか? 一般的には、コントラクトのための良いアーキテクチャを考えなければなりません。 コードの可読性の観点からは、より小さなコントラクトが常に好まれます。 コントラクトを分割するには、自問してみてください: -- どの関数がセットになっていますか? 関数の各セットは、そのコントラクト内にあることが最善策となる場合があります。 +- どの関数がセットになっていますか? それぞれの関数セットは、独自のコントラクトにまとめるのが最善かもしれません。 - コントラクトの状態や、状態の特定のサブセットのみの読み取りを必要としないのは、どの関数ですか? - ストレージと機能を分けることはできますか? ### ライブラリ {#libraries} -機能コードをストレージから移動させる簡単な方法としては、[ライブラリ](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries)の使用が挙げられます。 コンパイル中に直接[コントラクトに追加](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking)されるので、ライブラリ関数をinternalで宣言しないでください。 しかし、public関数を使用する場合、それらは実際には別のライブラリコントラクトに含まれることになります。 ライブラリをより便利に利用するには、[using for](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for)の使用を検討してください。 +機能に関するコードをストレージから分離する簡単な方法の1つは、[ライブラリ](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries)を使用することです。 ライブラリ関数をinternalとして宣言しないでください。internal関数はコンパイル時にコントラクトに直接[追加される](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking)ためです。 しかし、public関数を使用する場合、それらは実際には別のライブラリコントラクトに含まれることになります。 ライブラリをより便利に使うために、[`using for`](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for)の使用を検討してください。 ### プロキシ {#proxies} -より高度な戦略としては、プロキシシステムが挙げられます。 このシステムではライブラリが、呼び出し元のコントラクトの状態で単に別のコントラクトの関数を実行する`DELEGATECALL`を裏で使用します。 プロキシシステムの詳細については、[こちらのブログ](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2)をご覧ください。 これで機能性が向上します。例えば、アップグレード可能になりますが、複雑さも増します。 何らかの理由によりプロキシシステムが唯一の選択肢でない限り、コントラクトサイズを減らすためだけにプロキシシステムを追加することはお勧めしません。 +より高度な戦略としては、プロキシシステムが挙げられます。 ライブラリは内部で `DELEGATECALL` を使用します。これは、呼び出し元のコントラクトの状態で、別のコントラクトの関数を実行するものです。 プロキシシステムについてさらに学ぶには、[こちらのブログ記事](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2)をご覧ください。 プロキシは、アップグレード可能性を有効にするなど、より多くの機能を提供しますが、多くの複雑さも加わります。 何らかの理由によりプロキシシステムが唯一の選択肢でない限り、コントラクトサイズを減らすためだけにプロキシシステムを追加することはお勧めしません。 -## サイズ削減効果: 中 {#medium-impact} +## 中程度の影響 {#medium-impact} -### 関数の削除 {#remove-functions} +### 関数を削除する {#remove-functions} -これは当然実行すべきことです。 関数はコントラクトサイズをかなり増大させます。 +これは明白なはずです。 関数はコントラクトサイズをかなり増大させます。 -- **external**: 利便性の理由から、多くのview関数が頻繁に追加されます。 サイズ制限に達するまでは、追加してもかまいません。 その後で、絶対に必要なもの以外のすべての関数を削除することを真剣に検討します。 -- **internal**: internal関数やprivate関数を削除し、関数が一度だけ呼び出される場合に限り、コードを単にインライン化することもできます。 +- **External**: 利便性のために、多くの`view`関数を追加することがよくあります。 サイズ制限に達するまでは、それで全く問題ありません。 その場合は、本当に必要なもの以外はすべて削除することを真剣に検討した方がよいでしょう。 +- **Internal**: `internal`/`private`関数を削除し、関数が一度しか呼び出されない場合は、コードをインライン化することもできます。 -### 変数の追加を回避 {#avoid-additional-variables} - -以下のような簡単な変更をするだけで、 +### 追加の変数を避ける {#avoid-additional-variables} ```solidity function get(uint id) returns (address,address) { @@ -69,24 +64,23 @@ function get(uint id) returns (address,address) { } ``` -**0.28 KB**もの差が出ます。 コントラクトでは類似の状況が多く見られます。結果的に、それらがサイズをかなり増大させています。 +このような簡単な変更で、**0.28kb**の差が生まれます。 コントラクトには同様の状況が数多く見られる可能性があり、それらが積み重なって大きな量になることがあります。 -### エラーメッセージの短縮 {#shorten-error-message} +### エラーメッセージを短縮する {#shorten-error-message} -長いリバート(元に戻す)メッセージ、特に多くの異なるリバートメッセージは、コントラクトを肥大化させる可能性があります。 代わりに、短いエラーコードを使用し、コントラクト内でそれらをデコードします。 そうすると、以下のように、長いメッセージをかなり短くすることができます。 +長いrevertメッセージ、特に多くの異なるrevertメッセージは、コントラクトを肥大化させる可能性があります。 代わりに短いエラーコードを使用し、コントラクト内でデコードしてください。 長いメッセージを、以下のように大幅に短くすることができます: ```solidity -require(msg.sender == owner, "Only the owner of this contract can call this function"); - +require(msg.sender == owner, "このコントラクトのオーナーのみがこの関数を呼び出せます"); ``` ```solidity require(msg.sender == owner, "OW1"); ``` -### エラーメッセージのかわりにカスタムエラーを使用 +### エラーメッセージの代わりにカスタムエラーを使用する -[Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/)で、カスタムエラーが導入されました。 カスタムエラーは、コントラクトのサイズを削減するのに効果的な方法です。なぜなら、(関数と同様に)セレクターとしてABIエンコードされるためです。 +カスタムエラーは[Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/)で導入されました。 カスタムエラーは、コントラクトのサイズを削減するための優れた方法です。なぜなら、（関数と同様に）セレクターとしてABIエンコードされるためです。 ```solidity error Unauthorized(); @@ -96,15 +90,15 @@ if (msg.sender != owner) { } ``` -### オプティマイザでの低い実行値を検討 {#consider-a-low-run-value-in-the-optimizer} +### オプティマイザで低いruns値を検討する {#consider-a-low-run-value-in-the-optimizer} -オプティマイザの設定も変更できます。 デフォルト値の200は、関数が200回呼び出される場合と同様にバイトコードを最適化しようとしていることを意味します。 これを1に変更すると、通常、各関数を1回だけ実行するケースに最適化するよう、オプティマイザに指示します。 1回だけ実行するように最適化された関数とは、その関数自体のデプロイのために最適化されていることを意味します。 ただし、**1に設定すると関数の実行にかかる[ガス代](/developers/docs/gas/)が高くなる**ことに注意してください。 +オプティマイザの設定を変更することもできます。 デフォルト値の200は、関数が200回呼び出されるかのようにバイトコードを最適化しようとすることを意味します。 これを1に変更すると、基本的には、各関数を一度だけ実行する場合に最適化するようにオプティマイザに指示することになります。 一度しか実行されないように最適化された関数は、デプロイ自体に対して最適化されていることを意味します。 **これにより関数の実行にかかる[ガス代](/developers/docs/gas/)が増加する**ため、望ましくない場合があることに注意してください。 -## サイズ削減効果: 小 {#small-impact} +## 小さな影響 {#small-impact} -### 関数への構造体渡しを回避 {#avoid-passing-structs-to-functions} +### 関数に構造体を渡すのを避ける {#avoid-passing-structs-to-functions} -[ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2)を使用している場合は、関数に構造体を渡さないようにすることができます。 以下のように、パラメータを構造体として渡す代わりに、 +[ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2)を使用している場合、関数に構造体を渡さないようにすることが有効です。 パラメータを構造体として渡す代わりに、必要なパラメータを直接渡します。 この例では、さらに**0.1kb**を節約しました。 ```solidity function get(uint id) returns (address,address) { @@ -126,16 +120,14 @@ function _get(address addr1, address addr2) private view returns(address,address } ``` -必要なパラメータを直接渡すようにします。 この例では、さらに**0.1 KB**を節約しました。 - -### 関数と変数の正しい可視性の宣言 {#declare-correct-visibility-for-functions-and-variables} +### 関数と変数に正しい可視性を宣言する {#declare-correct-visibility-for-functions-and-variables} -- 外部からのみ呼び出される関数や変数ですか? その場合は、`public`ではなく`external`として宣言します。 -- コントラクト内からのみ呼び出される関数または変数ですか? その場合は、`public`ではなく`private`あるいは`internal`として宣言します。 +- 外部からのみ呼び出される関数や変数ですか？ `public`ではなく`external`として宣言します。 +- コントラクト内部からのみ呼び出される関数や変数ですか？ `public`ではなく`private`または`internal`として宣言します。 -### modifierの削除 {#remove-modifiers} +### 修飾子を削除する {#remove-modifiers} -modifier修飾子を過剰に使用すると、コントラクトのサイズに大きな影響を与える可能性があります。 そのため、modifierの代わりに関数を使用することを検討してください。 +修飾子は、特に多用されると、コントラクトのサイズに大きな影響を与える可能性があります。 修飾子を削除し、代わりに関数を使用することを検討してください。 ```solidity modifier checkStuff() {} @@ -149,4 +141,4 @@ function checkStuff() private {} function doSomething() { checkStuff(); } ``` -これらのヒントを実践することで、コントラクトのサイズを大幅に削減することができます。 繰り返しになりますが、最大の効果を得るためには、可能な限りコントラクトを分割することが重要です。 +これらのヒントは、コントラクトのサイズを大幅に削減するのに役立つはずです。 繰り返しになりますが、最大の影響を得るためには、可能であれば常にコントラクトの分割に注力してください。 diff --git a/public/content/translations/ja/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/translations/ja/developers/tutorials/eip-1271-smart-contract-signatures/index.md index f01f894f8a3..e9d038ae9e9 100644 --- a/public/content/translations/ja/developers/tutorials/eip-1271-smart-contract-signatures/index.md +++ b/public/content/translations/ja/developers/tutorials/eip-1271-smart-contract-signatures/index.md @@ -1,20 +1,16 @@ --- title: "EIP-1271: スマートコントラクト署名に対する署名と検証" -description: EIP-1271を使ったスマートコントラクト署名の生成および検証の概要。 スマートコントラクト・デベロッパーが構築できるように具体的な例としてSafe (旧 Gnosis Safe) で使用される EIP-1271実装についても説明します。 +description: "EIP-1271を使ったスマートコントラクト署名の生成および検証の概要。 スマートコントラクト・デベロッパーが構築できるように具体的な例としてSafe (旧 Gnosis Safe) で使用される EIP-1271実装についても説明します。" author: Nathan H. Leung lang: ja -tags: - - "eip-1271" - - "スマートコントラクト" - - "検証" - - "署名(signing)" +tags: [ "eip-1271", "スマートコントラクト", "検証", "署名(signing)" ] skill: intermediate published: 2023-01-12 --- -[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271)標準は、スマートコントラクトで署名の検証を可能にします。 +[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271)標準は、スマートコントラクトによる署名の検証を可能にします。 -このチュートリアルでは、デジタル署名、EIP-1271の背景、EIP-1271の具体的な実装である[Safe](https://safe.global/) (旧Gnosis Safe) の概要を説明します。 このチュートリアル全体を通して、EIP-1271を自身のコントラクトへ実装するための出発点として使うことができます。 +このチュートリアルでは、デジタル署名、EIP-1271の背景、および[Safe](https://safe.global/) (旧Gnosis Safe) が使用するEIP-1271の特定の実装の概要を説明します。 このチュートリアル全体を通して、EIP-1271を自身のコントラクトへ実装するための出発点として使うことができます。 ## 「署名」とは何か @@ -23,8 +19,8 @@ published: 2023-01-12 具体的には、デジタル署名は次のようなものです。 1. メッセージ: 「イーサリアムウォレットを使用してこのWebサイトにログインしたい」 -2. 署名者: 私のアドレスは、`0x000…`です。 -3. 証拠: ここに、私「`0x000…`」がこのメッセージ全体を実際に作成したという証拠 (これは通常暗号化される) があります。 +2. 署名者: 私のアドレスは`0x000…`です。 +3. 証拠: 私(`0x000…`)が、このメッセージ全体を実際に作成したという証拠がこちらです(これは通常、暗号化されたものです)。 デジタル署名には、「メッセージ」と「署名」の両方が含まれていることが重要です。 @@ -36,11 +32,11 @@ published: 2023-01-12 イーサリアムベースのブロックチェーン上でデジタル署名を作成するには、通常、他の人が知らない秘密鍵が必要になります。 秘密鍵により、あなたの署名が自身のものになります (誰も秘密鍵を知らない限り、同じ署名を作成できません) 。 -イーサリアムアカウント (すなわち、外部所有アカウント/EOA) には、アカウントに紐づいた秘密鍵があります。この秘密鍵が、通常、ウェブサイトやDappで求められる署名に使われます (例:「イーサリアムでログイン」) 。 +イーサリアムアカウント(i.e.、外部所有アカウント/EOA)には秘密鍵が関連付けられています。この秘密鍵は、ウェブサイトやdappが署名(例: 「イーサリアムでログイン」)を求める際に通常使用されるものです。 -アプリでは、ethers.jsのようなサードパーティライブラリを使って[秘密鍵を知らせることなく](https://en.wikipedia.org/wiki/Public-key_cryptography)、作成した[署名を検証でき](https://docs.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum)、署名を作成したのは_あなた_であると確信することができます。 +アプリは、ethers.jsのようなサードパーティのライブラリを使い、あなたが作成した署名を[検証](https://www.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum)し、[あなたの秘密鍵を知ることなく](https://en.wikipedia.org/wiki/Public-key_cryptography)、_あなた_がその署名を作成したと確信できます。 -> 事実として、EOA (外部所有アカウント) のデジタル署名は公開鍵暗号技術を使っているため、**オフチェーン**で生成および検証できます。 これは、ガスレスDAO投票の仕組みです。オンチェーンで投票を送信する代わりに、暗号化ライブラリを使用してオフチェーンでデジタル署名を作成し、検証可能です。 +> 事実、EOAのデジタル署名は公開鍵暗号を使用するため、**オフチェーン**で生成・検証できます。 これは、ガスレスDAO投票の仕組みです。オンチェーンで投票を送信する代わりに、暗号ライブラリを使用してオフチェーンでデジタル署名を作成し、検証できます。 EOAの各アカウントには秘密鍵がありますが、スマートコントラクトアカウントにはいかなる種類の共通鍵も秘密鍵もありません (そのため、「イーサリアムでログイン」などはスマートコントラクトのアカウントにおいては、ネイティブで機能しません) 。 @@ -50,17 +46,17 @@ EIP-1271は、スマートコントラクトで署名に使う「秘密鍵」が スマートコントラクトには、メッセージの署名に使用する秘密鍵がありません。 署名が本物かどうかをどのようにして判断するのでしょうか？ -アイデアの一つとして、署名が本物かどうかをスマートコントラクトに_尋ねる_ことがあります。 +そこで考えられるのが、署名が本物かどうかをスマートコントラクトに直接_問い合わせて_みることです。 EIP-1271が行っているのは、与えられた署名が有効かどうかをスマートコントラクトに「尋ねる」アイデアを標準化です。 -EIP-1271を実装するコントラクトでは、メッセージと署名を受け取る`isValidSignature`という関数が必要になります。 次にコントラクトは、いくつかの検証ロジックを実行し (仕様書では、具体的なことを何も強制していません) 、署名が有効かどうかを示す値を返します。 +EIP-1271を実装するコントラクトは、メッセージと署名を受け取る`isValidSignature`という名前の関数を持つ必要があります。 次にコントラクトは、いくつかの検証ロジックを実行し (仕様書では、具体的なことを何も強制していません) 、署名が有効かどうかを示す値を返します。 -`isValidSignature`が有効な結果を返せば、そのコントラクトが「はい、この署名とメッセージを承認します！」と言っているのと、ほぼ同じこととなります。 +`isValidSignature`が有効な結果を返した場合、それはコントラクトが「はい、この署名とメッセージを承認します！」と言っているのとほぼ同じです。 ### インターフェース -EIP-1271仕様の正確なインターフェイスは、次のようになります。`_hash`パラメータについては、後ほど説明しますので、ここでは検証されるメッセージであると考えてください。 +以下がEIP-1271仕様の正確なインターフェイスです(`_hash`パラメータについては後述しますが、ここでは検証対象のメッセージだと考えてください): ```jsx pragma solidity ^0.5.0; @@ -71,13 +67,13 @@ contract ERC1271 { bytes4 constant internal MAGICVALUE = 0x1626ba7e; /** - * @dev Should return whether the signature provided is valid for the provided hash - * @param _hash Hash of the data to be signed - * @param _signature Signature byte array associated with _hash + * @dev 提供されたハッシュに対して、提供された署名が有効かどうかを返すべきです + * @param _hash 署名されるデータのハッシュ + * @param _signature _hashに関連付けられた署名バイト配列 * - * MUST return the bytes4 magic value 0x1626ba7e when function passes. - * MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5) - * MUST allow external calls + * 関数が成功した場合、bytes4のマジック値0x1626ba7eを返さなければなりません(MUST)。 + * 状態を変更してはいけません(MUST NOT)。(solc < 0.5の場合はSTATICCALLを使用、solc > 0.5の場合はview修飾子を使用) + * 外部呼び出しを許可しなければなりません(MUST)。 */ function isValidSignature( bytes32 _hash, @@ -90,28 +86,28 @@ contract ERC1271 { ## EIP-1271実装の例: Safe -さまざまな方法で`isValidSignature`をコントラクトに実装することができます。仕様では、正確な実装についてあまり触れていません。 +コントラクトはさまざまな方法で`isValidSignature`を実装できます。仕様では、正確な実装についてはあまり言及されていません。 EIP-1271を実装した有名なコントラクトの1つにSafe (旧Gnosis Safe) があります。 -Safeのコードでは、署名の作成および検証において、次の[2つの方法](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support)を取れるように`isValidSignature`が[実装されています](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol)。 +Safeのコードでは、`isValidSignature`は、署名が[2つの方法](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support)で作成・検証できるように[実装](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol)されています: 1. オンチェーンメッセージ - 1. 作成: Safeの所有者は、メッセージに「署名」するための新しいSafeのトランザクションを作成し、メッセージをデータとしてトランザクションに渡します。 十分な数の所有者がトランザクションに署名してマルチシグのしきい値に達すると、トランザクションがブロードキャストされて実行されます。 このトランザクションでは、「承認された」メッセージのリストに追加するSafe関数が呼び出されます。 - 2. 検証: Safeコントラクトでは、`isValidSignature`を呼び出し、検証するメッセージをメッセージパラメータとして、[署名パラメータを空の値](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (すなわち、`0x`) にして渡します。 Safeは、署名パラメータが空であることを確認し、署名を暗号的に検証する代わりに、メッセージが「承認された」メッセージのリストに存在するかのみを確認します。 -2. オフチェーンメッセージ - 1. 作成: Safeの所有者は、オフチェーンでメッセージを作成し、他のSafeの所有者に、マルチシグの承認のしきい値を超えるのに十分な署名が得られるまでメッセージに対して個別に署名してもらいます。 - 2. 検証: `isValidSignature`を呼び出します。 メッセージパラメータの中に、検証するメッセージを渡します。 署名パラメーターでは、Safe所有者各自の署名をすべて連結して、一斉に渡します。 Safeでは、しきい値を満たすのに十分な署名があること**および**各署名が有効であることをチェックします。 有効であれば、署名の検証が成功したことを示す値を返します。 + 1. 作成: Safeの所有者は、メッセージに「署名」するための新しいSafeのトランザクションを作成し、メッセージをデータとしてトランザクションに渡します。 十分な数の所有者がトランザクションに署名してマルチシグのしきい値に達すると、トランザクションがブロードキャストされて実行されます。 トランザクションには、メッセージを「承認済み」メッセージのリストに追加する (`signMessage(bytes calldata _data)`) というSafe関数があります。 + 2. 検証: Safeコントラクトで`isValidSignature`を呼び出し、検証するメッセージをメッセージパラメータとして、[署名パラメータには空の値](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (i.e.、`0x`) を渡します。 Safeは、署名パラメータが空であることを確認し、署名を暗号的に検証する代わりに、メッセージが「承認された」メッセージのリストに存在するかのみを確認します。 +2. オフチェーンメッセージ: + 1. 作成: Safeの所有者はオフチェーンでメッセージを作成し、マルチシグの承認しきい値を超えるのに十分な署名が集まるまで、他のSafe所有者に個別にメッセージへ署名してもらいます。 + 2. 検証: `isValidSignature`を呼び出します。 メッセージパラメータの中に、検証するメッセージを渡します。 署名パラメーターでは、Safe所有者各自の署名をすべて連結して、一斉に渡します。 Safeは、しきい値を満たすのに十分な署名があること、**かつ**各署名が有効であることをチェックします。 有効であれば、署名の検証が成功したことを示す値を返します。 -## `_hash`パラメータは、正確には何なのか およびメッセージ全体を渡さない理由 +## `_hash`パラメータとは正確には何ですか? およびメッセージ全体を渡さない理由 -あなたは、[EIP-1271インターフェース](https://eips.ethereum.org/EIPS/eip-1271)の`isValidSignature`関数がメッセージ自体を取らない代わりに `_hash`パラメーターを取ることに気付いたかもしれません。 これは、任意の長さのメッセージ全体を `isValidSignature`に渡す代わりに、そのメッセージの32バイトのハッシュ (通常はkeccak256) を渡しています。 +[EIP-1271インターフェイス](https://eips.ethereum.org/EIPS/eip-1271)の`isValidSignature`関数が、メッセージ自体ではなく`_hash`パラメータを受け取ることに気づいたかもしれません。 これは、任意の長さのメッセージ全体を`isValidSignature`に渡す代わりに、メッセージの32バイトのハッシュ(通常はkeccak256)を渡すことを意味します。 -コールデータの各バイト、すなわち、スマートコントラクトへ渡される関数パラメータのデータには、[16ガスのコストがかかります](https://eips.ethereum.org/EIPS/eip-2028)(0バイトの場合は4ガス) 。 そのため、メッセージが長ければガスを大幅に節約できます。 +コールデータの各バイト、すなわちスマートコントラクト関数に渡される関数パラメータデータは、[16ガス(ゼロバイトの場合は4ガス)のコストがかかる](https://eips.ethereum.org/EIPS/eip-2028)ため、メッセージが長い場合は多くのガスを節約できます。 ### 以前のEIP-1271仕様 -すでに出回っているEIP-1271仕様に、最初のパラメータでパラメータ名が`message`で、`bytes`型 (固定長の`bytes32`ではなく、任意の長さ) の`isValidSignature`関数があります。 これは、[古いバージョン](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206)のEIP-1271標準です。 +実際には、最初のパラメータが`bytes`型(固定長の`bytes32`ではなく任意長)で、パラメータ名が`message`である`isValidSignature`関数を持つEIP-1271仕様が存在します。 これは、EIP-1271標準の[古いバージョン](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206)です。 ## EIP-1271を各自のコントラクトにどのように実装すべきか @@ -124,4 +120,4 @@ Safeのコードでは、署名の作成および検証において、次の[2 ## まとめ -[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271)は、スマートコントラクトによる署名の検証を可能する標準で、多くの用途があります。 EIP-1271により、スマートコントラクトをEOAのように動作させることができます。例えば、「イーサリアムでログイン」をスマートコントラクトで動作させる方法を提供できます。また、さまざまな方法で実装できます (考慮するのに興味深い重要な実装としてSafeがあります) 。 +[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271)は、スマートコントラクトが署名を検証できるようにする汎用性の高い標準です。 EIP-1271により、スマートコントラクトをEOAのように動作させることができます。例えば、「イーサリアムでログイン」をスマートコントラクトで動作させる方法を提供できます。また、さまざまな方法で実装できます (考慮するのに興味深い重要な実装としてSafeがあります) 。 diff --git a/public/content/translations/ja/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/erc-721-vyper-annotated-code/index.md index 8a073d19f70..bd402e34a03 100644 --- a/public/content/translations/ja/developers/tutorials/erc-721-vyper-annotated-code/index.md +++ b/public/content/translations/ja/developers/tutorials/erc-721-vyper-annotated-code/index.md @@ -1,31 +1,33 @@ --- -title: "Vyperで作成したERC-721コントラクトの紹介" -description: 中村龍矢氏のERC-721コントラクトとその仕組み +title: "Vyper ERC-721コントラクトウォークスルー" +description: "中村龍矢氏のERC-721コントラクトとその仕組み" author: Ori Pomerantz lang: ja -tags: - - "Vyper" - - "ERC-721" - - "Python" +tags: [ "Vyper", "ERC-721", "Python" ] skill: beginner published: 2021-04-01 --- ## はじめに {#introduction} -[ERC-721](/developers/docs/standards/tokens/erc-721/)標準規格は、非代替性トークン（NFT）の所有権を保持するために使用されます。 [ERC-20](/developers/docs/standards/tokens/erc-20/)トークンは代替性を持つため、コモディティとして機能します。 一方、ERC-721トークンは、様々な[猫のイラスト](https://www.cryptokitties.co/)や不動産物件の各部分に対する権原など、同じ種類ではあるが異なるアセットを対象として設計されたものです。 +[ERC-721](/developers/docs/standards/tokens/erc-721/)標準は、非代替性トークン(NFT)の所有権を保持するために使用されます。 +[ERC-20](/developers/docs/standards/tokens/erc-20/)トークンは、個々のトークンに違いがないため、コモディティのように振る舞います。 +対照的に、ERC-721トークンは、さまざまな猫の +漫画や、異なる不動産の所有権など、似ているが同一ではない資産のために設計されています。 -本記事では、[中村龍矢氏のERC-721コントラクト](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy)を分析します。 このコントラクトは、[Vyper](https://vyper.readthedocs.io/en/latest/index.html)で作成されました。Vyperは、Pythonに似たコントラクト開発言語であり、Solidityと比較するとセキュリティが低いコードを作成しにくくなっています。 +この記事では、[中村龍矢氏のERC-721コントラクト](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy)を分析します。 +このコントラクトは、Pythonに似たコントラクト言語である[Vyper](https://vyper.readthedocs.io/en/latest/index.html)で書かれています。Vyperは、Solidityよりも安全でないコードを書くのが難しくなるように設計されています。 -## コントラクトの内容 {#contract} +## コントラクト {#contract} ```python -# @dev Implementation of ERC-721 non-fungible token standard. +# @dev ERC-721非代替性トークン標準の実装。 # @author Ryuya Nakamura (@nrryuya) -# Modified from: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy +# 変更元: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy ``` -Pythonの場合と同様に、Vyperのコメントはハッシュ（`@/code>）で開始し、行末まで続けます。 @`を含むコメントは、 [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) を通じて人間が読みやすいドキュメントに変換されます。 +Vyperのコメントは、Pythonと同様に、ハッシュ記号(`＃`)で始まり、行末まで続きます。 `@<キーワード>`を含むコメントは、[NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html)によって、人間が読める +ドキュメントを生成するために使用されます。 ```python from vyper.interfaces import ERC721 @@ -33,176 +35,206 @@ from vyper.interfaces import ERC721 implements: ERC721 ``` -ERC-721インターフェイスは、Vyper言語に組み込まれています。 [コードの定義はこちら](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py)をご覧ください。 インターフェイスの定義は、VyperではなくPythonで書かれています。これは、インターフェイスがブロックチェーン内だけでなく、Pythonで書かれた外部クライアントからブロックチェーンにトランザクションを送る際にも使われるからです。 +ERC-721インターフェイスはVyper言語に組み込まれています。 +[コードの定義はこちらで確認できます](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py)。 +インターフェイスの定義はVyperではなくPythonで書かれています。なぜなら、インターフェイスはブロックチェーン内で使用されるだけでなく、Pythonで書かれている可能性のある外部クライアントからブロックチェーンにトランザクションを送信する際にも使用されるからです。 -第1行はインターフェイスをインポートし、第2行はここで実装することを指示します。 +最初の行でインターフェイスをインポートし、2行目でここで実装することを指定しています。 -### ERC-721のReceiverインターフェイス {#receiver-interface} +### ERC721Receiverインターフェイス {#receiver-interface} ```python -# Interface for the contract called by safeTransferFrom() +# safeTransferFrom()によって呼び出されるコントラクトのインターフェイス interface ERC721Receiver: def onERC721Received( ``` -ERC-721は、2つの送信方法をサポートしています。 +ERC-721は2種類の送金をサポートしています。 -- `transferFrom`は、送信者が任意の送信先アドレスを指定するもので、送信の責任は送信者が担います。 このため無効なアドレスにも送信できますが、その場合はNFTは永遠に失われます。 -- `safeTransferFrom`は、送信先アドレスがコントラクトかどうかを確認します。 送信先アドレスがコントラクトであることを確認すると、ERC-721コントラクトが受信側のコントラクトにNFTを受け取りたいかどうかを尋ねます。 +- `transferFrom`: 送信者が任意の宛先アドレスを指定でき、 + 送金の責任は送信者にあります。 これは、無効なアドレスに送金できることを意味し、その場合 + NFTは永久に失われます。 +- `safeTransferFrom`: 宛先アドレスがコントラクトであるかどうかをチェックします。 もしそうであれば、ERC-721コントラクトは + 受信側のコントラクトにNFTを受け取りたいかどうかを尋ねます。 -`safeTransferFrom`リクエストに応答するには、受信側コントラクトが`ERC721Receiver`を実装していなければなりません。 +`safeTransferFrom`リクエストに応答するには、受信側コントラクトが`ERC721Receiver`を実装する必要があります。 ```python _operator: address, _from: address, ``` -`_from`のアドレスは、トークンの現在の所有者のアドレスです。 `_operator`のアドレスは、 送信を要求したアドレスです（アローワンスにより、これらの 2 つが同一でない場合があります）。 +`_from`アドレスは、トークンの現在の所有者です。 `_operator`アドレスは、 +送金をリクエストしたアドレスです(アローワンスのため、この2つは同じでない場合があります)。 ```python _tokenId: uint256, ``` -ERC-721トークンのIDは、256ビットです。 通常トークンIDは、トークンの内容をハッシュ化して生成されます。 +ERC-721トークンIDは256ビットです。 通常、トークンIDはトークンが表すものの説明を +ハッシュ化して作成されます。 ```python _data: Bytes[1024] ``` -このリクエストには、最大1024バイトのユーザーデータを含めることができます。 +リクエストには最大1024バイトのユーザーデータを含めることができます。 ```python ) -> bytes32: view ``` -コントラクトが誤送信を受け入れるケースを防止するため、戻り値はブール値ではなく、256ビットの特定の値になっています。 +コントラクトが誤って送金を受け入れるケースを防ぐため、戻り値はブール値ではなく、 +特定の価を持つ256ビットです。 -この関数は`view`関数であるため、ブロックチェーンの状態を読み取るだけで、変更はできません。 +この関数は`view`であり、ブロックチェーンの状態を読み取ることはできますが、変更することはできません。 ### イベント {#events} -[イベント](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e)は、ブロックチェーン外のユーザーおよびサーバーにイベントを通知するために発行されます。 イベントの内容は、ブロックチェーン上のコントラクトでは利用できないことに注意してください。 +[イベント](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e)は、ブロックチェーン外のユーザーやサーバーにイベントを通知するために発行されます。 イベントの内容は、ブロックチェーン上のコントラクトからは +利用できないことに注意してください。 ```python -# @dev Emits when ownership of any NFT changes by any mechanism. This event emits when NFTs are -# created (`from` == 0) and destroyed (`to` == 0). Exception: during contract creation, any -# number of NFTs may be created and assigned without emitting Transfer. At the time of any -# transfer, the approved address for that NFT (if any) is reset to none. -# @param _from Sender of NFT (if address is zero address it indicates token creation). -# @param _to Receiver of NFT (if address is zero address it indicates token destruction). -# @param _tokenId The NFT that got transferred. +# @dev 何らかのメカニズムによってNFTの所有権が変更されたときに発行されます。このイベントは、NFTが作成 +# (`from` == 0)および破棄(`to` == 0)されたときに発行されます。例外：コントラクト作成中、任意の +# 数のNFTがTransferを発行せずに作成および割り当てられる場合があります。任意の +# 送金時、そのNFTの承認済みアドレス(もしあれば)はnoneにリセットされます。 +# @param _from NFTの送信者(アドレスがゼロアドレスの場合、トークンの作成を示します)。 +# @param _to NFTの受信者(アドレスがゼロアドレスの場合、トークンの破棄を示します)。 +# @param _tokenId 送金されたNFT。 event Transfer: sender: indexed(address) receiver: indexed(address) tokenId: indexed(uint256) ``` -これは、金額の代わりに`tokenId`を伝える点を除くとERC-20のTransferイベントと類似しています。 アドレスを所有しないユーザーはいないので、慣習的に、このイベントを使ってトークンの発行と破壊を報告しています。 +これは、金額の代わりに`tokenId`を報告する点を除けば、ERC-20のTransferイベントと似ています。 +ゼロアドレスを所有する者はいないため、慣例的にトークンの作成と破棄を報告するために使用します。 ```python -# @dev This emits when the approved address for an NFT is changed or reaffirmed. The zero -# address indicates there is no approved address. When a Transfer event emits, this also -# indicates that the approved address for that NFT (if any) is reset to none. -# @param _owner Owner of NFT. -# @param _approved Address that we are approving. -# @param _tokenId NFT which we are approving. +# @dev NFTの承認済みアドレスが変更または再確認されたときに発行されます。ゼロ +# アドレスは、承認済みアドレスがないことを示します。Transferイベントが発行されると、これも +# そのNFTの承認済みアドレス(もしあれば)がnoneにリセットされることを示します。 +# @param _owner NFTの所有者。 +# @param _approved 承認するアドレス。 +# @param _tokenId 承認するNFT。 event Approval: owner: indexed(address) approved: indexed(address) tokenId: indexed(uint256) ``` -ERC-721の承認は、ERC-20におけるアローワンスに類似した機能です。 特定のアドレスから、特定のトークンを送信することが可能です。 これにより、コントラクトがトークンを受け入れる際に対応するためのメカニズムが実現します。 コントラクトは、イベントをリッスンできないため、トークンが送信されてもそれを「把握」できないのです。 つまり、所有者はまず承認を提出してから、コントラクトに対して「私はあなたがトークンXを送信することを承認しましたので、〜を実行してください」というリクエストを送信するわけです。 +ERC-721の承認はERC-20のアローワンスに似ています。 特定のアドレスが特定の +トークンを送金することが許可されます。 これにより、コントラクトがトークンを受け入れる際に応答するためのメカニズムが提供されます。 コントラクトは +イベントをリッスンできないため、トークンを送金しただけでは、コントラクトはそのことを「知り」ません。 この方法では、 +所有者はまず承認を送信し、次にコントラクトに「トークン +Xの送金を承認しました。どうぞ...」というリクエストを送信します。 -これは、ERC-721標準をERC-20と類似の標準にするための設計上の選択によるものです。 ERC-721トークンは非代替性であるため、コントラクトは、トークンの所有権を調べて特定のトークンを受け取ったかどうかを確認できます。 +これは、ERC-721標準をERC-20標準と類似させるための設計上の選択です。 ERC-721トークンは非代替性であるため、 +コントラクトはトークンの所有権を見ることで、特定のトークンを受け取ったことを +識別することもできます。 ```python -# @dev This emits when an operator is enabled or disabled for an owner. The operator can manage -# all NFTs of the owner. -# @param _owner Owner of NFT. -# @param _operator Address to which we are setting operator rights. -# @param _approved Status of operator rights(true if operator rights are given and false if -# revoked). +# @dev 所有者のオペレーターが有効または無効になったときに発行されます。オペレーターは +# 所有者のすべてのNFTを管理できます。 +# @param _owner NFTの所有者。 +# @param _operator オペレーター権限を設定するアドレス。 +# @param _approved オペレーター権限のステータス(権限が付与された場合はtrue、 +# 取り消された場合はfalse)。 event ApprovalForAll: owner: indexed(address) operator: indexed(address) approved: bool ``` -場合によっては、委任状の機能のように、アカウントが所有する特定タイプのトークン（特定のコントラクトが管理するトークン）をすべて管理できる_オペレーター_ を持つことが便利な場合もあります。 例えば、私がコントラクトに対して、6カ月にわたりそのコントラクトとのやりとりを行っていないかどうかを確認する権限を与え、もしやりとりがない場合には、私のアセットを相続人に分配するように設定したいとします（相続人の一人が遺産分配を求めても、トランザクションによって呼び出されない限りコントラクトは何も実行できません）。 ERC-20では、継承コントラクトに対して大きなアローワンスを設定できますが、ERC-721の場合、非代替性を持つために不可能です。 そこで、オペレーターが同等の機能を提供します。 +委任状のように、特定タイプの(特定のコントラクトによって管理される)アカウントの全トークンを管理できる_オペレーター_がいると便利な場合があります。 例えば、私が6ヶ月間連絡を取っていないかどうかをチェックし、もしそうであれば私の資産を相続人に分配する権限をコントラクトに与えたいかもしれません(相続人の一人が要求した場合、コントラクトはトランザクションによって呼び出されない限り何もできません)。 ERC-20では、継承コントラクトに高いアローワンスを与えることができますが、 +ERC-721ではトークンが非代替性であるため、これは機能しません。 これが同等の機能です。 -`approved`の値を通じて、当該イベントが承認を求めるものか、承認を取り消したものかを確認することができます。 +`approved`の値は、イベントが承認のためのものか、承認の取り消しのためのものかを示します。 ### 状態変数 {#state-vars} -状態変数には、トークンの現在の状態、つまりどのトークンが存在し、誰が所有するかの情報が含まれます。 大部分の状態変数は`HashMap`オブジェクトであり、[2つのタイプ間に存在する一方向のマッピング](https://vyper.readthedocs.io/en/latest/types.html#mappings)です。 +これらの変数には、トークンの現在の状態、つまりどのトークンが利用可能で誰が所有しているかの情報が含まれています。 これらのほとんどは`HashMap`オブジェクトであり、[2つの型間に存在する一方向のマッピング](https://vyper.readthedocs.io/en/latest/types.html#mappings)です。 ```python -# @dev Mapping from NFT ID to the address that owns it. +# @dev NFT IDからそれを所有するアドレスへのマッピング。 idToOwner: HashMap[uint256, address] -# @dev Mapping from NFT ID to approved address. +# @dev NFT IDから承認済みアドレスへのマッピング。 idToApprovals: HashMap[uint256, address] ``` -イーサリアムにおいて、ユーザーおよびコントラクトのIDは160ビットのアドレスで表示されます。 これら2つの変数は、トークンIDから、所有者および送信することを承認された者（それぞれにつき最大1つの変数）がマッピングされます。 イーサリアムでは、未初期化データは常にゼロであるため、所有者または承認済み送信者が存在しなければ、トークンの値はゼロになります。 +イーサリアムでは、ユーザーとコントラクトのIDは160ビットのアドレスで表されます。 これら2つの変数は、トークンIDから、 +その所有者と送金を承認された者(それぞれ最大1つ)にマッピングします。 イーサリアムでは、未初期化データは常にゼロであるため、 +所有者または承認済み送金者がいない場合、そのトークンの値はゼロになります。 ```python -# @dev Mapping from owner address to count of his tokens. +# @dev 所有者アドレスからそのトークン数へのマッピング。 ownerToNFTokenCount: HashMap[address, uint256] ``` -この変数は、各所有者ごとのトークン数を保持します。 所有者とトークンはマッピングされないため、特定の所有者が持つトークンを特定するには、ブロックチェーンのイベント履歴を過去に遡って確認し、当該の`Transfer`イベントを確認するしかありません。 この変数を使用して、すべてのNFTでいつ取得したか知ることができ、それ以上調べる必要がありません。 +この変数は、各所有者のトークン数を保持します。 所有者からトークンへのマッピングはないため、 +特定の所有者が所有するトークンを識別する唯一の方法は、ブロックチェーンのイベント履歴を遡り、 +適切な`Transfer`イベントを見ることです。 この変数を使用して、すべてのNFTをいつ取得したかを知ることができ、 +それ以上調べる必要がありません。 -ただし、このアルゴリズムはユーザーインターフェイスおよび外部サーバーのみを対象とする点に注意してください。 ブロックチェーン上で実行されるコード自体は、過去イベントを読み込むことができません。 +このアルゴリズムは、ユーザーインターフェイスと外部サーバーに対してのみ機能することに注意してください。 ブロックチェーン上で実行されるコード +自体は、過去のイベントを読み取ることはできません。 ```python -# @dev Mapping from owner address to mapping of operator addresses. +# @dev 所有者アドレスからオペレーターアドレスのマッピングへのマッピング。 ownerToOperators: HashMap[address, HashMap[address, bool]] ``` -1つのアカウントには、複数のオペレーターを含めることができます。 しかし、単純な`HashMap`では、各キーごとに単一の値を持つため、複数のオペレーターを追跡するのに十分ではありません。 その代わりに、`HashMap[address, bool]`を値として使用します。 デフォルトでは、各アドレスの値は`False`になっていますが、これはオペレーターでないことを示します。 オペレーターに設定するには、値を`True`に変更してください。 +1つのアカウントに複数のオペレーターがいる場合があります。 単純な`HashMap`では、各キーが単一の値につながるため、 +それらを追跡するには不十分です。 代わりに、値として +`HashMap[address, bool]`を使用できます。 デフォルトでは、各アドレスの値は`False`であり、 +オペレーターではないことを意味します。 必要に応じて値を`True`に設定できます。 ```python -# @dev Address of minter, who can mint a token +# @dev トークンをミントできるミンターのアドレス minter: address ``` -何らかの方法で、新規トークンを作成する必要があります。 このコントラクトでは、新規トークンを作成する権限を持つ唯一のエンティティは`minter`です。 使用事例がゲームなどの場合は、これで十分でしょう。 その他の目的の場合、より複雑なビジネスロジックを作成する必要があるでしょう。 +新しいトークンは何らかの方法で作成されなければなりません。 このコントラクトには、それを許可された単一のエンティティ、 +`minter`が存在します。 例えば、ゲームにとってはこれで十分でしょう。 他の目的のためには、 +より複雑なビジネスロジックを作成する必要があるかもしれません。 ```python -# @dev Mapping of interface id to bool about whether or not it's supported +# @dev インターフェイスIDから、それがサポートされているかどうかを示すbool値へのマッピング supportedInterfaces: HashMap[bytes32, bool] -# @dev ERC165 interface ID of ERC165 +# @dev ERC165のERC165インターフェイスID ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a7 -# @dev ERC165 interface ID of ERC721 +# @dev ERC721のERC165インターフェイスID ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cd ``` -[ERC-165](https://eips.ethereum.org/EIPS/eip-165)では、コントラクトにおいてアプリケーションがどのようなやりとりを行うか、およびどのERC規格に準拠するのかを開示するメカニズムの仕様が規定されています。 このコントラクトの場合、ERC-165とERC-721に準拠しています。 +[ERC-165](https://eips.ethereum.org/EIPS/eip-165)は、コントラクトがアプリケーションと +通信する方法、つまりどのERCに準拠しているかを公開するためのメカニズムを指定します。 この場合、コントラクトはERC-165とERC-721に準拠しています。 ### 関数 {#functions} -以下は、実際にERC-721で実装できる関数です。 +これらは、実際にERC-721を実装する関数です。 -#### コンストラクタ関数 {#constructor} +#### コンストラクタ {#constructor} ```python @external def __init__(): ``` -Pythonの場合と同様に、Vyperでもコンストラクタ関数は`__init__`で呼び出します。 +Vyperでは、Pythonと同様に、コンストラクタ関数は`__init__`と呼ばれます。 ```python """ - @dev Contract constructor. + @dev コントラクトコンストラクタ。 """ ``` -PythonおよびVyperでは、複数行の文字列（文頭および文末を`"""`に付ける）を指定し、この文字列を利用しないことでもコメントを作成できます。 これらのコメントには、 [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html)を含めることも可能です。 +PythonやVyperでは、複数行の文字列(`"""`で始まり終わる)を指定し、それを一切使用しないことでコメントを作成することもできます。 これらのコメントには、 +[NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html)も含まれる場合があります。 ```python self.supportedInterfaces[ERC165_INTERFACE_ID] = True @@ -210,57 +242,64 @@ PythonおよびVyperでは、複数行の文字列（文頭および文末を`"" self.minter = msg.sender ``` -状態変数にアクセスするには、`self.`を使用します（これも、Pythonと同様です）。 +状態変数にアクセスするには`self.<変数名>`を使用します(これもPythonと同じです)。 #### ビュー関数 {#views} -ビュー関数は、ブロックチェーンの状態を変更しない関数であり、外部から呼び出されると無料で実行されます。 一方、コントラクトがビュー関数を呼び出す場合は全ノードで実行する必要があるため、ガス代が発生します。 +これらはブロックチェーンの状態を変更しない関数であり、したがって外部から +呼び出された場合は無料で実行できます。 ビュー関数がコントラクトによって呼び出された場合でも、 +すべてのノードで実行する必要があるため、ガス代がかかります。 ```python @view @external ``` -アットマーク （`@`）で始まる関数定義の前に置かれたこれらのキーワードを、_デコレータ_と呼びます。 デコレータは、関数を呼び出せる状況を特定します。 +関数定義の前にある、アットマーク(`@`)で始まるこれらのキーワードは、_デコレータ_と呼ばれます。 これらは +関数を呼び出すことができる状況を指定します。 -- `@view`は、関数がビューであることを規定します。 -- `@external`は、関数がトランザクションおよび他のコントラクトで呼び出し可能であることを規定します。 +- `@view`は、この関数がビューであることを指定します。 +- `@external`は、この特定の関数がトランザクションや他のコントラクトによって呼び出されることを指定します。 ```python def supportsInterface(_interfaceID: bytes32) -> bool: ``` -Pythonとは異なり、Vyperは[静的型付け言語](https://wikipedia.org/wiki/Type_system#Static_type_checking)です。 つまり、[データ型](https://vyper.readthedocs.io/en/latest/types.html)を指定しないと変数、つまり関数のパラメータを宣言できません。 この場合では、入力パラメータは、256ビット値の`bytes32`です (256ビットは、[イーサリアム仮想マシン](/developers/docs/evm/)のネイティブワードサイズです) 。 出力は、ブール値です。 慣習により、関数におけるパラメータの名称はアンダースコア (`_`) で開始します。 +Pythonとは対照的に、Vyperは[静的型付け言語](https://wikipedia.org/wiki/Type_system#Static_type_checking)です。 +[データ型](https://vyper.readthedocs.io/en/latest/types.html)を特定せずに、変数や関数パラメータを宣言することはできません。 この場合、入力パラメータは`bytes32`、つまり256ビット値です +(256ビットは[イーサリアム仮想マシン](/developers/docs/evm/)のネイティブワードサイズです)。 出力はブール +値です。 慣例により、関数パラメータの名前はアンダースコア(`_`)で始まります。 ```python """ - @dev Interface identification is specified in ERC-165. - @param _interfaceID Id of the interface + @dev インターフェイスの識別はERC-165で指定されています。 + @param _interfaceID インターフェイスのID """ return self.supportedInterfaces[_interfaceID] ``` -コンストラクタ（`__init__`）で設定した`self.supportedInterfaces`ハッシュマップが値を返します。 +コンストラクタ(`__init__`)で設定された`self.supportedInterfaces` HashMapから値を返します。 ```python -### VIEW FUNCTIONS ### +### ビュー関数 ### + ``` -これらは、ユーザーや他のコントラクトが利用できるトークンについての情報を提供するビュー関数です。 +これらは、トークンに関する情報をユーザーや他のコントラクトが利用できるようにするビュー関数です。 ```python @view @external def balanceOf(_owner: address) -> uint256: """ - @dev Returns the number of NFTs owned by `_owner`. - Throws if `_owner` is the zero address. NFTs assigned to the zero address are considered invalid. - @param _owner Address for whom to query the balance. + @dev `_owner`が所有するNFTの数を返します。 + `_owner`がゼロアドレスの場合はスローします。ゼロアドレスに割り当てられたNFTは無効と見なされます。 + @param _owner 残高を照会するアドレス。 """ assert _owner != ZERO_ADDRESS ``` -この行は、`_owner`値がゼロでないことを[宣言](https://vyper.readthedocs.io/en/latest/statements.html#assert)します。 値がゼロの場合、エラーが発生し操作が元に戻されます。 +この行は、`_owner`がゼロでないことを[アサート](https://vyper.readthedocs.io/en/latest/statements.html#assert)します。 もしゼロであれば、エラーが発生し、操作は取り消されます。 ```python return self.ownerToNFTokenCount[_owner] @@ -269,70 +308,74 @@ def balanceOf(_owner: address) -> uint256: @external def ownerOf(_tokenId: uint256) -> address: """ - @dev Returns the address of the owner of the NFT. - Throws if `_tokenId` is not a valid NFT. - @param _tokenId The identifier for an NFT. + @dev NFTの所有者のアドレスを返します。 + `_tokenId`が有効なNFTでない場合はスローします。 + @param _tokenId NFTの識別子。 """ owner: address = self.idToOwner[_tokenId] - # Throws if `_tokenId` is not a valid NFT + # `_tokenId`が有効なNFTでない場合はスローします assert owner != ZERO_ADDRESS return owner ``` -イーサリアム仮想マシン（EVM）では、値が格納されていないストレージはゼロになります。 `_tokenId`にトークンが含まれない場合、`self.idToOwner[_tokenId]`の値はゼロになります。 その場合、関数は元に戻されます。 +イーサリアム仮想マシン(EVM)では、値が格納されていないストレージはゼロになります。 +`_tokenId`にトークンがない場合、`self.idToOwner[_tokenId]`の値はゼロになります。 その場合、 +関数は元に戻されます。 ```python @view @external def getApproved(_tokenId: uint256) -> address: """ - @dev Get the approved address for a single NFT. - Throws if `_tokenId` is not a valid NFT. - @param _tokenId ID of the NFT to query the approval of. + @dev 単一のNFTの承認済みアドレスを取得します。 + `_tokenId`が有効なNFTでない場合はスローします。 + @param _tokenId 承認を照会するNFTのID。 """ - # Throws if `_tokenId` is not a valid NFT + # `_tokenId`が有効なNFTでない場合はスローします assert self.idToOwner[_tokenId] != ZERO_ADDRESS return self.idToApprovals[_tokenId] ``` -`getApproved`は、ゼロの値を返す_可能性_がある点に注意してください。 有効なトークンが存在する場合、`self.idToApprovals[_tokenId]`の値が返されます。 承認者が存在しない場合、値はゼロになります。 +`getApproved`はゼロを返す_可能性がある_ことに注意してください。 トークンが有効な場合、`self.idToApprovals[_tokenId]`を返します。 +承認者がいない場合、その値はゼロです。 ```python @view @external def isApprovedForAll(_owner: address, _operator: address) -> bool: """ - @dev Checks if `_operator` is an approved operator for `_owner`. - @param _owner The address that owns the NFTs. - @param _operator The address that acts on behalf of the owner. + @dev `_operator`が`_owner`の承認済みオペレーターであるかどうかをチェックします。 + @param _owner NFTを所有するアドレス。 + @param _operator 所有者の代わりに機能するアドレス。 """ return (self.ownerToOperators[_owner])[_operator] ``` -この関数は、「`_operator`」がこのコントラクト内の「`_owner`」のトークンをすべて管理できるかどうかをチェックします。 複数のオペレーターが存在する可能性があるため、ハッシュマップも2つのレベルが存在します。 +この関数は、`_operator`がこのコントラクト内の`_owner`のすべてのトークンを管理できるかどうかをチェックします。 +複数のオペレーターが存在する可能性があるため、これは2レベルのHashMapです。 -#### 送信ヘルパー関数 {#transfer-helpers} +#### 送金ヘルパー関数 {#transfer-helpers} -これらの関数は、トークンの送信またはトークン管理の一部のオペレーションを実装しています。 +これらの関数は、トークンの送金または管理の一部である操作を実装します。 ```python -### TRANSFER FUNCTION HELPERS ### +### 送金関数ヘルパー ### @view @internal ``` -`@internal`のデコレータは、関数が同一コントラクト内の他の関数からのみアクセス可能であることを意味します。 これらの関数も、慣習によりアンダースコア (`_`) で開始します。 +このデコレータ`@internal`は、この関数が同じコントラクト内の他の関数からのみアクセス可能であることを意味します。 慣例により、これらの関数名もアンダースコア(`_`)で始まります。 ```python def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool: """ - @dev Returns whether the given spender can transfer a given token ID - @param spender address of the spender to query - @param tokenId uint256 ID of the token to be transferred - @return bool whether the msg.sender is approved for the given token ID, - is an operator of the owner, or is the owner of the token + @dev 指定されたスペンダーが指定されたトークンIDを送金できるかどうかを返します + @param spender 照会するスペンダーのアドレス + @param tokenId 送金されるトークンのuint256 ID + @return bool msg.senderが指定されたトークンIDに対して承認されているか、 + 所有者のオペレーターであるか、トークンの所有者であるかどうか """ owner: address = self.idToOwner[_tokenId] spenderIsOwner: bool = owner == _spender @@ -341,117 +384,122 @@ def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool: return (spenderIsOwner or spenderIsApproved) or spenderIsApprovedForAll ``` -アドレスからトークンを送信できるようにするには、次の3通りの方法があります： +アドレスがトークンを送金できるようにするには、3つの方法があります。 -1. アドレスが、トークンの所有者であること -2. アドレスが、トークンの使用を承認されていること -3. アドレスが、トークンの所有者のオペレーターであること +1. アドレスがトークンの所有者である +2. アドレスがそのトークンを使用することを承認されている +3. アドレスがトークンの所有者のオペレーターである -上記の機能は、状態を変更しないためビュー機能とすることもできます。 オペレーションコストを軽減するには、ビュー機能と_指定できる_関数はビュー機能に_するべき_です。 +上記の関数は状態を変更しないため、ビューにすることができます。 運用コストを削減するために、ビューに_できる_関数は +すべてビューに_すべき_です。 ```python @internal def _addTokenTo(_to: address, _tokenId: uint256): """ - @dev Add a NFT to a given address - Throws if `_tokenId` is owned by someone. + @dev 指定されたアドレスにNFTを追加します + `_tokenId`が誰かによって所有されている場合はスローします。 """ - # Throws if `_tokenId` is owned by someone + # `_tokenId`が誰かによって所有されている場合はスローします assert self.idToOwner[_tokenId] == ZERO_ADDRESS - # Change the owner + # 所有者を変更 self.idToOwner[_tokenId] = _to - # Change count tracking + # カウント追跡を変更 self.ownerToNFTokenCount[_to] += 1 @internal def _removeTokenFrom(_from: address, _tokenId: uint256): """ - @dev Remove a NFT from a given address - Throws if `_from` is not the current owner. + @dev 指定されたアドレスからNFTを削除します + `_from`が現在の所有者でない場合はスローします。 """ - # Throws if `_from` is not the current owner + # `_from`が現在の所有者でない場合はスローします assert self.idToOwner[_tokenId] == _from - # Change the owner + # 所有者を変更 self.idToOwner[_tokenId] = ZERO_ADDRESS - # Change count tracking + # カウント追跡を変更 self.ownerToNFTokenCount[_from] -= 1 ``` -送信に問題が発生した場合、呼び出しは取り消されます。 +送金に問題がある場合、呼び出しを元に戻します。 ```python @internal def _clearApproval(_owner: address, _tokenId: uint256): """ - @dev Clear an approval of a given address - Throws if `_owner` is not the current owner. + @dev 指定されたアドレスの承認をクリアします + `_owner`が現在の所有者でない場合はスローします。 """ - # Throws if `_owner` is not the current owner + # `_owner`が現在の所有者でない場合はスローします assert self.idToOwner[_tokenId] == _owner if self.idToApprovals[_tokenId] != ZERO_ADDRESS: - # Reset approvals + # 承認をリセット self.idToApprovals[_tokenId] = ZERO_ADDRESS ``` -必要な場合のみ、値を変更してください。 状態変数は、ストレージ上に保存されます。 ストレージへの書き込みは、EVM（イーサリアム仮想マシン）において[ガス代](/developers/docs/gas/)が最も高価なオペレーションの1つです。 既存の値の書き込みもコストが高いため、ストレージへの書き込みは最低限に抑えることをお勧めします。 +必要な場合のみ、値を変更してください。 状態変数はストレージに存在します。 ストレージへの書き込みは、 +EVM (イーサリアム仮想マシン) が行う最も高価な操作の1つです([ガス](/developers/docs/gas/)の観点から)。 したがって、既存の値を書き込むだけでも +コストが高いため、これを最小限に抑えることをお勧めします。 ```python @internal def _transferFrom(_from: address, _to: address, _tokenId: uint256, _sender: address): """ - @dev Execute transfer of a NFT. - Throws unless `msg.sender` is the current owner, an authorized operator, or the approved - address for this NFT. (NOTE: `msg.sender` not allowed in private function so pass `_sender`.) - Throws if `_to` is the zero address. - Throws if `_from` is not the current owner. - Throws if `_tokenId` is not a valid NFT. + @dev NFTの送金を実行します。 + `msg.sender`が現在の所有者、承認されたオペレーター、またはこのNFTの承認 + 済みアドレスでない限り、スローします。(注：`msg.sender`はプライベート関数では許可されていないため、`_sender`を渡します。) + `_to`がゼロアドレスの場合はスローします。 + `_from`が現在の所有者でない場合はスローします。 + `_tokenId`が有効なNFTでない場合はスローします。 """ ``` -トークンの送信には2つの方法（通常モードと安全モード）が存在するため、この内部関数が提供されていますが、監査を容易にするために、コード内で送信するロケーションは1つだけにする必要があります。 +トークンを送金するには2つの方法(通常と安全)があるため、この内部関数がありますが、 +監査を容易にするために、コード内の1つの場所でのみ実行するようにしています。 ```python - # Check requirements + # 要件をチェック assert self._isApprovedOrOwner(_sender, _tokenId) - # Throws if `_to` is the zero address + # `_to`がゼロアドレスの場合はスローします assert _to != ZERO_ADDRESS - # Clear approval. Throws if `_from` is not the current owner + # 承認をクリアします。`_from`が現在の所有者でない場合はスローします self._clearApproval(_from, _tokenId) - # Remove NFT. Throws if `_tokenId` is not a valid NFT + # NFTを削除します。`_tokenId`が有効なNFTでない場合はスローします self._removeTokenFrom(_from, _tokenId) - # Add NFT + # NFTを追加 self._addTokenTo(_to, _tokenId) - # Log the transfer + # 送金をログに記録 log Transfer(_from, _to, _tokenId) ``` -Vyper上でイベントを発行するには、`log`ステートメントを使用します（詳細は、[こちら](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging)をご覧ください）。 +Vyperでイベントを発行するには、`log`ステートメントを使用します([詳細はこちら](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging))。 -#### 送信関数 {#transfer-funs} +#### 送金関数 {#transfer-funs} ```python -### TRANSFER FUNCTIONS ### +### 送金関数 ### @external def transferFrom(_from: address, _to: address, _tokenId: uint256): """ - @dev Throws unless `msg.sender` is the current owner, an authorized operator, or the approved - address for this NFT. - Throws if `_from` is not the current owner. - Throws if `_to` is the zero address. - Throws if `_tokenId` is not a valid NFT. - @notice The caller is responsible to confirm that `_to` is capable of receiving NFTs or else - they maybe be permanently lost. - @param _from The current owner of the NFT. - @param _to The new owner. - @param _tokenId The NFT to transfer. + @dev `msg.sender`が現在の所有者、承認されたオペレーター、またはこのNFTの承認 + 済みアドレスでない限り、スローします。 + `_from`が現在の所有者でない場合はスローします。 + `_to`がゼロアドレスの場合はスローします。 + `_tokenId`が有効なNFTでない場合はスローします。 + @notice 呼び出し元は、`_to`がNFTを受信できることを確認する責任があります。さもないと、 + 永久に失われる可能性があります。 + @param _from NFTの現在の所有者。 + @param _to 新しい所有者。 + @param _tokenId 送金するNFT。 """ self._transferFrom(_from, _to, _tokenId, msg.sender) ``` -この関数は、任意のアドレスに送信する機能を提供します。 送信先のアドレスがユーザーであるか、トークンの送信方法が分かっているコントラクトでない場合、送信するトークンはそのアドレスに置かれたまま利用できない状態になります。 +この関数を使用すると、任意のアドレスに送金できます。 アドレスがユーザーであるか、トークンの送金方法を知っているコントラクトでない限り、 +送金したトークンはそのアドレスでスタックし、使用できなくなります。 ```python @external @@ -462,75 +510,80 @@ def safeTransferFrom( _data: Bytes[1024]=b"" ): """ - @dev Transfers the ownership of an NFT from one address to another address. - Throws unless `msg.sender` is the current owner, an authorized operator, or the - approved address for this NFT. - Throws if `_from` is not the current owner. - Throws if `_to` is the zero address. - Throws if `_tokenId` is not a valid NFT. - If `_to` is a smart contract, it calls `onERC721Received` on `_to` and throws if - the return value is not `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`. - NOTE: bytes4 is represented by bytes32 with padding - @param _from The current owner of the NFT. - @param _to The new owner. - @param _tokenId The NFT to transfer. - @param _data Additional data with no specified format, sent in call to `_to`. + @dev NFTの所有権をあるアドレスから別のアドレスに送金します。 + `msg.sender`が現在の所有者、承認されたオペレーター、またはこの + NFTの承認済みアドレスでない限り、スローします。 + `_from`が現在の所有者でない場合はスローします。 + `_to`がゼロアドレスの場合はスローします。 + `_tokenId`が有効なNFTでない場合はスローします。 + `_to`がスマートコントラクトの場合、`_to`で`onERC721Received`を呼び出し、 + 戻り値が`bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`でない場合にスローします。 + 注：bytes4はパディング付きのbytes32で表されます + @param _from NFTの現在の所有者。 + @param _to 新しい所有者。 + @param _tokenId 送金するNFT。 + @param _data 指定されたフォーマットのない追加データで、`_to`への呼び出しで送信されます。 """ self._transferFrom(_from, _to, _tokenId, msg.sender) ``` -問題が発生した場合にはトランザクションが元に戻され、コールに含まれるすべての事項が取り消されるため、先に送信を行っても構いません。 +問題が発生した場合はとにかく元に戻すので、先に送金しても問題ありません。 +呼び出しで行われたことはすべてキャンセルされます。 ```python - if _to.is_contract: # check if `_to` is a contract address + if _to.is_contract: # `_to`がコントラクトアドレスかどうかをチェック ``` -まず、アドレスがコントラクトであるか（コードを持つか）を確認してください。 アドレスがコントラクトでない場合、ユーザーのアドレスであれば、そのトークンを使用／送信できるようになります。 しかし、これがセキュリティを強化すると考えるべきではありません。 `safeTransferFrom`を使用した場合でも、秘密鍵が不明なアドレスに送信したトークンは失われる場合があります。 +まず、アドレスがコントラクト(コードがある場合)かどうかを確認します。 そうでない場合は、それがユーザーアドレスであり、ユーザーが +トークンを使用または送金できると想定します。 しかし、それで +安心しきってはいけません。 `safeTransferFrom`を使用しても、誰も秘密鍵を知らないアドレスに +送金すると、トークンを失う可能性があります。 ```python returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data) ``` -ERC-721トークンを受信できるかどうかを確認するには、送信先のコントラクトを呼び出します。 +ターゲットコントラクトを呼び出して、ERC-721トークンを受信できるかどうかを確認します。 ```python - # Throws if transfer destination is a contract which does not implement 'onERC721Received' + # 送金先が'onERC721Received'を実装していないコントラクトの場合はスローします assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32) ``` -送信先がコントラクトであるが、ERC-721トークンを受け付けない場合（または、この特定の送信を受け付けないと選択した場合）、操作を取り消してください。 +宛先がコントラクトであっても、ERC-721トークンを受け付けない(またはこの特定の +送金を受け付けないと決定した)場合は、元に戻します。 ```python @external def approve(_approved: address, _tokenId: uint256): """ - @dev Set or reaffirm the approved address for an NFT. The zero address indicates there is no approved address. - Throws unless `msg.sender` is the current NFT owner, or an authorized operator of the current owner. - Throws if `_tokenId` is not a valid NFT. (NOTE: This is not written the EIP) - Throws if `_approved` is the current owner. (NOTE: This is not written the EIP) - @param _approved Address to be approved for the given NFT ID. - @param _tokenId ID of the token to be approved. + @dev NFTの承認済みアドレスを設定または再確認します。ゼロアドレスは、承認済みアドレスがないことを示します。 + `msg.sender`が現在のNFT所有者または現在の所有者の承認済みオペレーターでない限り、スローします。 + `_tokenId`が有効なNFTでない場合はスローします。(注：これはEIPには書かれていません) + `_approved`が現在の所有者である場合はスローします。(注：これはEIPには書かれていません) + @param _approved 指定されたNFT IDに対して承認されるアドレス。 + @param _tokenId 承認されるトークンのID。 """ owner: address = self.idToOwner[_tokenId] - # Throws if `_tokenId` is not a valid NFT + # `_tokenId`が有効なNFTでない場合はスローします assert owner != ZERO_ADDRESS - # Throws if `_approved` is the current owner + # `_approved`が現在の所有者である場合はスローします assert _approved != owner ``` -慣習により、承認者を設定したくない場合、自分のアドレスではなく、ゼロのアドレスを指定してください。 +慣例により、承認者を設定したくない場合は、自分自身ではなくゼロアドレスを指定します。 ```python - # Check requirements + # 要件をチェック senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender] assert (senderIsOwner or senderIsApprovedForAll) ``` -承認を設定するには、所有者であるか、所有者が承認したオペレーターである必要があります。 +承認を設定するには、所有者であるか、所有者によって承認されたオペレーターである必要があります。 ```python - # Set the approval + # 承認を設定 self.idToApprovals[_tokenId] = _approved log Approval(owner, _approved, _tokenId) @@ -538,95 +591,110 @@ def approve(_approved: address, _tokenId: uint256): @external def setApprovalForAll(_operator: address, _approved: bool): """ - @dev Enables or disables approval for a third party ("operator") to manage all of - `msg.sender`'s assets. It also emits the ApprovalForAll event. - Throws if `_operator` is the `msg.sender`. (NOTE: This is not written the EIP) - @notice This works even if sender doesn't own any tokens at the time. - @param _operator Address to add to the set of authorized operators. - @param _approved True if the operators is approved, false to revoke approval. + @dev サードパーティ(「オペレーター」)が`msg.sender`の + すべての資産を管理するための承認を有効または無効にします。また、ApprovalForAllイベントも発行します。 + `_operator`が`msg.sender`である場合はスローします。(注：これはEIPには書かれていません) + @notice これは、送信者がその時点でトークンを所有していなくても機能します。 + @param _operator 承認済みオペレーターのセットに追加するアドレス。 + @param _approved オペレーターが承認されている場合はTrue、承認を取り消す場合はfalse。 """ - # Throws if `_operator` is the `msg.sender` + # `_operator`が`msg.sender`である場合はスローします assert _operator != msg.sender self.ownerToOperators[msg.sender][_operator] = _approved log ApprovalForAll(msg.sender, _operator, _approved) ``` -#### 新しいトークンのミントと既存トークンの破壊 {#mint-burn} +#### 新しいトークンのミントと既存トークンの破棄 {#mint-burn} -コントラクトを作成したアカウントは`minter`となり、新規のNFTをミントする承認を受けたスーパーユーザーとなります。 ただし、ミンターは既存トークンをバーンすることはできません。 バーンできるのは、所有者および所有者の承認を受けたエンティティのみです。 +コントラクトを作成したアカウントは`minter`であり、新しいNFTをミントする権限を持つ +スーパーユーザーです。 ただし、既存のトークンをバーンすることは許可されていません。 所有者、または所有者によって承認された +エンティティのみがそれを行うことができます。 ```python -### MINT & BURN FUNCTIONS ### +### ミント＆バーン関数 ### @external def mint(_to: address, _tokenId: uint256) -> bool: ``` -操作が実行されない場合は常に元に戻されるため、この関数は常に`True`の値が返されます。 +操作が失敗した場合は元に戻されるため、この関数は常に`True`を返します。 ```python """ - @dev Function to mint tokens - Throws if `msg.sender` is not the minter. - Throws if `_to` is zero address. - Throws if `_tokenId` is owned by someone. - @param _to The address that will receive the minted tokens. - @param _tokenId The token id to mint. - @return A boolean that indicates if the operation was successful. + @dev トークンをミントする関数 + `msg.sender`がミンターでない場合はスローします。 + `_to`がゼロアドレスの場合はスローします。 + `_tokenId`が誰かによって所有されている場合はスローします。 + @param _to ミントされたトークンを受け取るアドレス。 + @param _tokenId ミントするトークンID。 + @return 操作が成功したかどうかを示すブール値。 """ - # Throws if `msg.sender` is not the minter + # `msg.sender`がミンターでない場合はスローします assert msg.sender == self.minter ``` -新たなトークンをミントできるのは、このミンター（この ERC-721コントラクトを作成したアカウント）のみです。 ミンターの身元を変更したい場合、この点は将来的に問題になる可能性があります。 本番環境のコントラクトでは、ミンターがミンター特権を他のユーザーに譲渡できる機能が必要になるでしょう。 +ミンター(ERC-721コントラクトを作成したアカウント)のみが新しいトークンをミントできます。 これは、将来ミンターの +IDを変更したい場合に問題になる可能性があります。 本番環境のコントラクトでは、ミンターが +ミンター権限を他の誰かに譲渡できる関数が必要になるでしょう。 ```python - # Throws if `_to` is zero address + # `_to`がゼロアドレスの場合はスローします assert _to != ZERO_ADDRESS - # Add NFT. Throws if `_tokenId` is owned by someone + # NFTを追加します。`_tokenId`が誰かによって所有されている場合はスローします self._addTokenTo(_to, _tokenId) log Transfer(ZERO_ADDRESS, _to, _tokenId) return True ``` -慣習により、新規トークンのミントは、ゼロアドレスからの送信としてカウントされます。 +慣例により、新しいトークンのミントはゼロアドレスからの送金としてカウントされます。 ```python @external def burn(_tokenId: uint256): """ - @dev Burns a specific ERC721 token. - Throws unless `msg.sender` is the current owner, an authorized operator, or the approved - address for this NFT. - Throws if `_tokenId` is not a valid NFT. - @param _tokenId uint256 id of the ERC721 token to be burned. + @dev 特定のERC721トークンをバーンします。 + `msg.sender`が現在の所有者、承認されたオペレーター、またはこのNFTの承認 + 済みアドレスでない限り、スローします。 + `_tokenId`が有効なNFTでない場合はスローします。 + @param _tokenId バーンされるERC721トークンのuint256 ID。 """ - # Check requirements + # 要件をチェック assert self._isApprovedOrOwner(msg.sender, _tokenId) owner: address = self.idToOwner[_tokenId] - # Throws if `_tokenId` is not a valid NFT + # `_tokenId`が有効なNFTでない場合はスローします assert owner != ZERO_ADDRESS self._clearApproval(owner, _tokenId) self._removeTokenFrom(owner, _tokenId) log Transfer(owner, ZERO_ADDRESS, _tokenId) ``` -トークンの送信が許可されているユーザーは、そのトークンをバーンすることができます。 バーンは、ゼロアドレスへの送信と同じ外見を持ちますが、このゼロアドレスは実際にはこのトークンを受け取りません。 バーンを通じて、このトークンに使用されたすべてのストレージを解放できるため、トランザクションのガス代を軽減することができます。 +トークンの送金を許可されている人は誰でも、それをバーンすることが許可されています。 バーンはゼロアドレスへの送金と +同等に見えますが、ゼロアドレスは実際にはトークンを受け取りません。 これにより、トークンに使用されていたすべてのストレージを +解放でき、トランザクションのガス代を削減できます。 + +## このコントラクトの使用 {#using-contract} + +Solidityとは対照的に、Vyperには継承がありません。 これは、コードをより明確にし、 +したがってセキュリティを確保しやすくするための意図的な設計上の選択です。 したがって、独自のVyper ERC-721コントラクトを作成するには、この +コントラクトを取得し、 +必要なビジネスロジックを実装するように変更します。 -## コントラクトの使用方法 {#using-contract} +## 結論 {#conclusion} -Solidityとは異なり、Viperは相続機能を提供しません。 これは、コードをより明確にし、セキュリティを確保しやすくするための意図的な設計上の選択によるものです。 このため、あなた自身がVyperでERC-721コントラクトを作成する際は、[このコントラクト](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy)を用いて修正し、必要なビジネスロジックを実装してください。 +復習のために、このコントラクトの最も重要なアイデアをいくつか紹介します。 -### まとめ {#conclusion} +- 安全な送金でERC-721トークンを受信するには、コントラクトは`ERC721Receiver`インターフェイスを実装する必要があります。 +- 安全な送金を使用しても、秘密鍵が不明なアドレスに送信すると、 + トークンがスタックする可能性があります。 +- 操作に問題がある場合は、単に失敗値を返すのではなく、 + 呼び出しを`revert`することをお勧めします。 +- ERC-721トークンは、所有者がいる場合に存在します。 +- NFTの送金を承認するには、3つの方法があります。 所有者であるか、特定のトークンに対して承認されているか、 + または所有者のすべてのトークンのオペレーターであることができます。 +- 過去のイベントはブロックチェーンの外部からのみ表示されます。 ブロックチェーン内で実行されるコードは、それらを表示できません。 -このコントラクトにつき、最も重要なポイントを以下にまとめました： +では、セキュアなVyperコントラクトを実装してみましょう。 -- 安全モードの送信を使ってERC-721トークンを受け取るには、コントラクトに`ERC721Receiver`インターフェイスを実装する必要があります。 -- 安全モードの送信を実行した場合でも、秘密鍵が不明なアドレスに送信したトークンは行方不明になる可能性があります。 -- 操作に問題が発生した場合、単に失敗値をリターンするのではなく、コール自体を`取り消す`ことをお勧めします。 -- ERC-721トークンには、必ず所有者が必要です。 -- NFTの送信を承認するには、3通りの方法があります。 承認できるのは、所有者であるか、特定トークンの送信を承認されているか、所有者のトークンすべてに対するオペレーターであるユーザーのみです。 -- 過去のイベントは、ブロックチェーン外でのみ表示されます。 ブロックチェーン内で実行されるコードは、表示できません。 +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). -それではさっそく、セキュアなVyperコントラクトを実装してみましょう。 diff --git a/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md index 56cf9b6b772..1f647c1bdba 100644 --- a/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md @@ -1,30 +1,28 @@ --- -title: "ERC-20コントラクトの詳細" -description: OpenZeppelinのERC-20コントラクトの内容とそれが存在する理由 +title: "ERC-20コントラクトのウォークスルー" +description: "OpenZeppelinのERC-20コントラクトには何が含まれており、それはなぜ存在するのでしょうか?" author: Ori Pomerantz lang: ja -tags: - - "Solidity" - - "erc-20" +tags: [ "Solidity", "ERC-20" ] skill: beginner published: 2021-03-09 --- ## はじめに {#introduction} -イーサリアムの最も一般的な用途の1つは、グループが取引可能なトークン、いわば独自の通貨を作ることです。 これらのトークンは通常、[ERC-20](/developers/docs/standards/tokens/erc-20/)という規格に準拠しています。 この規格により、流動性プールやウォレットなど、すべてのERC-20トークンで利用できるツールの作成が可能になります。 今回は、[OpenZeppelin Solidity ERC-20の実装](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)と、[インターフェース定義](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)について分析していきます。 +イーサリアムの最も一般的な用途の1つは、グループが取引可能なトークン、いわば独自の通貨を作ることです。 これらのトークンは、通常[ERC-20](/developers/docs/standards/tokens/erc-20/)という規格に従います。 この規格により、流動性プールやウォレットなど、すべてのERC-20トークンで利用できるツールの作成が可能になります。 この記事では、[OpenZeppelinのSolidityによるERC20実装](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)と、[インターフェース定義](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)を分析します。 -ここではアノテーション付きのソースコードを見ていきます。 ERC-20を実装する場合は、[こちらのチュートリアル](https://docs.openzeppelin.com/contracts/2.x/erc20-supply)をご覧ください。 +ここではアノテーション付きのソースコードを見ていきます。 ERC-20を実装したい場合は、[このチュートリアル](https://docs.openzeppelin.com/contracts/2.x/erc20-supply)をお読みください。 ## インターフェース {#the-interface} -ERC-20のような規格の目的は、ウォレットや分散型取引所のようなアプリケーション間で相互運用可能な多くのトークンの実装を可能にすることです。 しかしその実現には[インターフェース](https://www.geeksforgeeks.org/solidity-basics-of-interface/)が必要です。 トークンコントラクトを使用する必要があるすべてのコードは、インターフェースで同じ定義を使用することができ、その定義を使用するすべてのトークンコントラクトと互換性があります。それらにはMetaMaskなどのウォレット、etherscan.ioなどの分散型アプリケーション(Dapp)、流動性プールなどの異なるコントラクトが含まれます。 +ERC-20のような規格の目的は、ウォレットや分散型取引所のようなアプリケーション間で相互運用可能な多くのトークンの実装を可能にすることです。 それを実現するために、[インターフェース](https://www.geeksforgeeks.org/solidity/solidity-basics-of-interface/)を作成します。 トークンコントラクトを使用する必要があるコードは、それがMetaMaskのようなウォレット、etherscan.ioのようなdapp、または流動性プールのような別のコントラクトであっても、インターフェースで同じ定義を使用でき、そのインターフェースを使用するすべてのトークンコントラクトと互換性があります。 ![ERC-20インターフェースの図](erc20_interface.png) -経験豊富なプログラマーであれば、[Java](https://www.w3schools.com/java/java_interface.asp)や[C言語のヘッダーファイル](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html)で同様の構造を見たことがあるのではないでしょうか。 +経験豊富なプログラマーであれば、[Java](https://www.w3schools.com/java/java_interface.asp)や[Cのヘッダーファイル](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html)で同様の構造を見たことがあるかもしれません。 -これはOpenZeppelinによる[ERC-20インターフェースの定義](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)です。 [人間が読めるように](https://eips.ethereum.org/EIPS/eip-20)Solidityのコードにしています。 もちろん、インターフェースそのものは、_何をするか_を定義していません。 これは後述のコントラクトのソースコードで説明されています。 +これはOpenZeppelinによる[ERC-20インターフェース](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)の定義です。 これは、[人間が読める標準規格](https://eips.ethereum.org/EIPS/eip-20)をSolidityコードに変換したものです。 もちろん、インターフェース自体は、何かを行う_方法_を定義するものではありません。 これは後述のコントラクトのソースコードで説明されています。   @@ -32,7 +30,7 @@ ERC-20のような規格の目的は、ウォレットや分散型取引所の // SPDX-License-Identifier: MIT ``` -Solidityのファイルには、ライセンス識別子が含まれているはずです。 ライセンス一覧は[こちら](https://spdx.org/licenses/)でご覧いただけます。 別のライセンスが必要な場合は、コメントしてください。 +Solidityのファイルには、ライセンス識別子が含まれているはずです。 [ライセンスのリストはこちら](https://spdx.org/licenses/)で確認できます。 別のライセンスが必要な場合は、コメントでその旨を説明してください。   @@ -40,13 +38,13 @@ Solidityのファイルには、ライセンス識別子が含まれているは pragma solidity >=0.6.0 <0.8.0; ``` -Solidity言語は現在も急速に進化しており、新しいバージョンは古いコードと互換性がない場合があります(詳しくは[こちら](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html))。 そのため、この言語の最小バージョンだけでなく、コードをテストした最新バージョンも指定することをお勧めします。 +Solidity言語は現在も急速に進化しており、新しいバージョンは古いコードと互換性がない場合があります([詳しくはこちら](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html))。 そのため、言語の最小バージョンだけでなく、最大バージョン、つまりコードをテストした最新のバージョンも指定することをお勧めします。   ```solidity /** - * @dev Interface of the ERC20 standard as defined in the EIP. + * @dev EIPで定義されているERC20標準のインターフェース。 */ ``` @@ -58,135 +56,135 @@ Solidity言語は現在も急速に進化しており、新しいバージョン interface IERC20 { ``` -慣例では、インターフェース名は「`I`」で始まります。 +慣例では、インターフェース名は`I`で始まります。   ```solidity /** - * @dev Returns the amount of tokens in existence. + * @dev 存在するトークンの総量を返します。 */ function totalSupply() external view returns (uint256); ``` -この関数は`external`です。つまり、[コントラクトの外部からのみ呼び出すことができます](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2)。 コントラクト内のトークンの総供給量を返します。 この値は、イーサリアムで最も一般的な型である符号なし256ビット(イーサリアム仮想マシン(EVM)のネイティブワードサイズ)で返されます。 この関数も`view`であり、状態を変更しないため、ブロックチェーンのすべてのノードで実行するのではなく、単一のノードで実行できます。 このような関数はトランザクションを発生させず、[ガス代](/developers/docs/)もかかりません。 +この関数は`external`であり、[コントラクトの外部からのみ呼び出すことができる](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2)ことを意味します。 +コントラクト内のトークンの総供給量を返します。 この値は、イーサリアムで最も一般的な型である符号なし256ビット(256ビットはEVMのネイティブワードサイズ)で返されます。 この関数も`view`であり、状態を変更しないため、ブロックチェーンのすべてのノードで実行するのではなく、単一のノードで実行できます。 このような関数はトランザクションを生成せず、[ガス](/developers/docs/gas/)代もかかりません。 -**注:** 理論的には、コントラクト作成者が、実際の値よりも少ない総供給量を返し、各トークンを実際の価格よりも高価に見せることで、不正を行うことが出来るように思えるかもしれません。 しかし、そのような心配をするということは、ブロックチェーンの本質を忘れているということになります。 ブロックチェーン上で起こるすべてのことは、すべてのノードで検証できます。 検証をするためのすべてのコントラクトの機械語コードとストレージは、全ノードで入手可能です。 コントラクトのSolidityコードを公開する必要はありませんが、ソースコードとコンパイルに使用したSolidityのバージョンを公開しない限り、不正への懸念を真剣に受け止めてもらうことはできません。その場合は、提供した機械語コードで検証することができます。 例えば、[このコントラクト](https://etherscan.io/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD#code)をご覧ください。 +**注:** 理論的には、コントラクト作成者が、実際の値よりも少ない総供給量を返し、各トークンを実際の価格よりも高価に見せることで、不正を行うことが出来るように思えるかもしれません。 しかし、そのような心配をするということは、ブロックチェーンの本質を忘れているということになります。 ブロックチェーン上で起こるすべてのことは、すべてのノードで検証できます。 これを実現するため、すべてのコントラクトの機械語コードとストレージは、全ノードで入手可能です。 コントラクトのSolidityコードを公開する必要はありませんが、提供した機械語コードと照合して検証できるように、ソースコードとそれをコンパイルしたSolidityのバージョンを公開しない限り、誰もあなたのコントラクトを本気で相手にしないでしょう。 +例えば、[このコントラクト](https://eth.blockscout.com/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD?tab=contract)をご覧ください。   ```solidity /** - * @dev Returns the amount of tokens owned by `account`. + * @dev `account`が所有するトークンの量を返します。 */ function balanceOf(address account) external view returns (uint256); ``` -その名の通り、`balanceOf`はアカウントの残高を返します。 Solidityでは、イーサリアムアカウントは160ビットを保持する`address`型で識別されます。 また、`external`や`view`もあります。 +その名の通り、`balanceOf`はアカウントの残高を返します。 Solidityでは、イーサリアムアカウントは160ビットを保持する`address`型で識別されます。 +この関数も`external`かつ`view`です。   ```solidity /** - * @dev Moves `amount` tokens from the caller's account to `recipient`. + * @dev `amount`のトークンを呼び出し元のアカウントから`recipient`に移動させます。 * - * Returns a boolean value indicating whether the operation succeeded. + * 操作が成功したかどうかを示すブール値を返します。 * - * Emits a {Transfer} event. + * {Transfer}イベントを発行します。 */ function transfer(address recipient, uint256 amount) external returns (bool); ``` -`transfer`関数は、呼び出し元から別のアドレスにトークンを転送します。 これは状態の変化を伴うので、`view`ではありません。 ユーザーがこの関数を呼び出すと、トランザクションが作成され、ガス代がかかります。 さらに、`Transfer`というイベントが発行され、ブロックチェーン上の全ノードにそのイベントが通知されます。 +`transfer`関数は、呼び出し元から別のアドレスにトークンを転送します。 これは状態の変化を伴うので、`view`ではありません。 +ユーザーがこの関数を呼び出すと、トランザクションが作成され、ガス代がかかります。 さらに、`Transfer`というイベントが発行され、ブロックチェーン上の全員にそのイベントが通知されます。 この関数には、2つの異なる呼び出し元のタイプに応じて、2つのタイプの出力があります。 -- ユーザーがユーザーインターフェースから関数を直接呼び出す場合。 通常、トランザクションを送信したユーザーは、その応答を待ちません。応答にどれくらいの時間がかかるか分からないからです。 ユーザーは、トランザクションレシート(トランザクションハッシュによって識別可能)を探すか、`Transfer`イベントを探すことで状況を把握できます。 -- 他のコントラクトがトランザクション全体の一部として関数を呼び出す場合。 これらのコントラクトは、すぐに結果を得ることができます。関数が同じトランザクション内で実行されるため、関数の戻り値を使用できるからです。 +- ユーザーがユーザーインターフェースから関数を直接呼び出す場合。 通常、ユーザーはトランザクションを送信すると、応答を待ちません。応答には不確定な時間がかかる可能性があるためです。 ユーザーは、トランザクションレシート(トランザクションハッシュによって識別される)を探すか、`Transfer`イベントを探すことで状況を把握できます。 +- 他のコントラクトが、全体的なトランザクションの一部として関数を呼び出す場合。 これらのコントラクトは、同じトランザクション内で実行されるため、関数の戻り値を使用でき、すぐに結果を得ることができます。 同じタイプの出力は、コントラクトの状態を変更する他の関数によって作成されます。   -割当量(allowance)を設定すると、あるアカウントが別の所有者に属しているトークンの一部を使えるようになります。 これは、コントラクトが売り手として機能する場合などに役立ちます。 コントラクトはイベントを監視できないため、買い手が売り手のコントラクトにトークンを直接転送した場合、売り手のコントラクトはその支払いを認識できません。 代わりに、買い手が売り手のコントラクトに一定量の使用を許可し、売り手がその量を転送するようにします。 この処理は売り手のコントラクトが呼び出した関数を通して行われるため、売り手のコントラクトは処理が成功したかどうかを確認できます。 +割当量(`allowance`)により、あるアカウントが別の所有者に属しているトークンの一部を使えるようになります。 +これは、例えば、コントラクトが売り手として機能する場合などに役立ちます。 コントラクトはイベントを監視できないため、買い手が売り手のコントラクトにトークンを直接転送した場合、売り手のコントラクトはその支払いを認識できません。 代わりに、買い手が売り手のコントラクトに一定量の使用を許可し、売り手がその量を転送します。 +この処理は売り手のコントラクトが呼び出す関数を通して行われるため、売り手のコントラクトは処理が成功したかどうかを確認できます。 ```solidity /** - * @dev Returns the remaining number of tokens that `spender` will be - * allowed to spend on behalf of `owner` through {transferFrom}. これは - * デフォルトでゼロです。 + * @dev {transferFrom}を通じて`spender`が`owner`に代わって使用できる、残りのトークン数を返します。これは + * デフォルトではゼロです。 * - * This value changes when {approve} or {transferFrom} are called. + * この値は、{approve}または{transferFrom}が呼び出されると変化します。 */ function allowance(address owner, address spender) external view returns (uint256); ``` -`allowance`関数を使用すると、誰でも、あるアドレス(`owner`)が別のアドレス(`spender`)に使用を許可している割当量(allowance)を照会できます。 +`allowance`関数により、誰でも、あるアドレス(`owner`)が別のアドレス(`spender`)に使用を許可している割当量を照会できます。   ```solidity /** - * @dev Sets `amount` as the allowance of `spender` over the caller's tokens. + * @dev `spender`が呼び出し元のトークンに対して持つ割当量を`amount`に設定します。 * - * Returns a boolean value indicating whether the operation succeeded. + * 操作が成功したかを示すブール値を返します。 * - * IMPORTANT: Beware that changing an allowance with this method brings the risk - * that someone may use both the old and the new allowance by unfortunate - * transaction ordering. One possible solution to mitigate this race - * condition is to first reduce the spender's allowance to 0 and set the - * desired value afterwards: + * 重要: このメソッドで割当量を変更すると、不運なトランザクションの順序によって、誰かが古い割当量と新しい割当量の両方を使用するリスクがあります。 + * この競合状態を緩和するための一つの解決策は、まずspenderの割当量を0に減らしてから、目的の値を設定することです。 * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 * - * Emits an {Approval} event. + * {Approval}イベントを発行します。 */ function approve(address spender, uint256 amount) external returns (bool); ``` -`approve`関数は、割当量を作成します。 これがどのように悪用される可能性があるのかについて、該当のメッセージを必ず読んでください。 イーサリアムでは、自分のトランザクションの順序は制御できますが、他のユーザーのトランザクションが発生したことを確認してからトランザクションを送信しない限り、他のユーザーのトランザクションが実行される順序を制御することはできません。 +`approve`関数は、割当量を作成します。 これがどのように悪用される可能性があるのかについて、該当のメッセージを必ず読んでください。 イーサリアムでは、自分のトランザクションの順序は制御できますが、相手方のトランザクションが発生したことを確認してから自分のトランザクションを送信しない限り、他のユーザーのトランザクションが実行される順序を制御することはできません。   ```solidity /** - * @dev Moves `amount` tokens from `sender` to `recipient` using the - * allowance mechanism. `amount` is then deducted from the caller's - * allowance. + * @dev 割当メカニズムを使用して、`amount`のトークンを`sender`から`recipient`に移動させます。`amount`は呼び出し元の割当量から差し引かれます。 * - * Returns a boolean value indicating whether the operation succeeded. + * 操作が成功したかを示すブール値を返します。 * - * Emits a {Transfer} event. + * {Transfer}イベントを発行します。 */ function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); ``` -最後に、使用者(spender)が`transferFrom`を使用して、割当量 (allowance)を実際に使用します。 +最後に、使用者(`spender`)が`transferFrom`を使用して、割当量(`allowance`)を実際に使用します。   ```solidity /** - * @dev Emitted when `value` tokens are moved from one account (`from`) to - * another (`to`). + * @dev `value`のトークンがあるアカウント(`from`)から + * 別のアカウント(`to`)に移動したときに発行されます。 * - * Note that `value` may be zero. + * `value`はゼロになる場合があることに注意してください。 */ event Transfer(address indexed from, address indexed to, uint256 value); /** - * @dev Emitted when the allowance of a `spender` for an `owner` is set by - * a call to {approve}. `value` is the new allowance. + * @dev {approve}の呼び出しによって`owner`に対する`spender`の割当量が設定されたときに発行されます。`value`は新しい割当量です。 */ event Approval(address indexed owner, address indexed spender, uint256 value); } ``` -これらのイベントは、ERC-20コントラクトの状態が変更されるタイミングで発行されます。 +これらのイベントは、ERC-20コントラクトの状態が変更されると発行されます。 ## 実際のコントラクト {#the-actual-contract} -以下は、[こちらから取得した](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)、ERC-20規格を採用している実際のコントラクトです。 そのまま使うためのものではありませんが、[継承](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm)することで使用可能なコントラクトに拡張することができます。 +これはERC-20規格を実装した実際のコントラクトで、[こちら](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)から引用しました。 +これはそのまま使用するためのものではありませんが、それから[継承](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm)して、使えるものに拡張することができます。 ```solidity // SPDX-License-Identifier: MIT @@ -195,7 +193,7 @@ pragma solidity >=0.6.0 <0.8.0;   -### インポートステートメント {#import-statements} +### インポート文 {#import-statements} コントラクト定義では、上記のインターフェース定義に加え、別の2つのファイルをインポートします。 @@ -206,48 +204,43 @@ import "./IERC20.sol"; import "../../math/SafeMath.sol"; ``` -- `GSN/Context.sol`は、イーサ(ETH)を持たないユーザーがブロックチェーンを使用できるようにするシステムである、[OpenGSN](https://www.opengsn.org/)を使用するために必要な定義です。 これは古いバージョンであることに注意してください。OpenGSNと統合する場合は、[こちらのチュートリアルをご覧ください](https://docs.opengsn.org/javascript-client/tutorial.html)。 -- [ SafeMathライブラリ](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/)は、オーバーフローを起こさずに加算と減算を実行できるようにするために使用されます。 このライブラリが必要な理由は、これがないと、1つのトークンを持っているユーザーが何らかの方法で2つのトークンを使用した場合、2^256-1のトークンを持ってしまう可能性があるためです。 +- `GSN/Context.sol`は、etherを持たないユーザーがブロックチェーンを使用できるようにするシステムである[OpenGSN](https://www.opengsn.org/)を使用するために必要な定義です。 これは古いバージョンであることに注意してください。OpenGSNと統合する場合は、[このチュートリアル](https://docs.opengsn.org/javascript-client/tutorial.html)を使用してください。 +- [SafeMathライブラリ](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/)は、Solidityバージョン**<0.8.0**の算術オーバーフロー/アンダーフローを防ぎます。 Solidity ≥0.8.0では、算術演算はオーバーフロー/アンダーフローで自動的にリバートするため、SafeMathは不要です。 このコントラクトは、古いコンパイラバージョンとの後方互換性のためにSafeMathを使用しています。   -以下のコメントは、コントラクトの目的を説明しています。 +このコメントは、コントラクトの目的を説明しています。 ```solidity /** - * @dev Implementation of the {IERC20} interface. + * @dev {IERC20}インターフェースの実装。 * - * This implementation is agnostic to the way tokens are created. This means - * that a supply mechanism has to be added in a derived contract using {_mint}. - * For a generic mechanism see {ERC20PresetMinterPauser}. + * この実装は、トークンが作成される方法には依存しません。これは + * 供給メカニズムを、{_mint}を使用して派生コントラクトに追加する必要があることを意味します。 + * 一般的なメカニズムについては、{ERC20PresetMinterPauser}を参照してください。 * - * TIP: For a detailed writeup see our guide - * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How - * to implement supply mechanisms]. + * ヒント: 詳細な解説については、ガイド + * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[供給メカニズムの実装方法]を参照してください。 * - * We have followed general OpenZeppelin guidelines: functions revert instead - * of returning `false` on failure. This behavior is nonetheless conventional - * and does not conflict with the expectations of ERC20 applications. + * OpenZeppelinの一般的なガイドラインに従っています。関数は失敗時に`false`を返すのではなく、リバートします。この動作は慣例的であり、ERC20アプリケーションの期待と矛盾しません。 * - * Additionally, an {Approval} event is emitted on calls to {transferFrom}. - * This allows applications to reconstruct the allowance for all accounts just - * by listening to said events. Other implementations of the EIP may not emit - * these events, as it isn't required by the specification. + * さらに、{transferFrom}の呼び出し時に{Approval}イベントが発行されます。 + * これにより、アプリケーションは、これらのイベントをリッスンするだけで、すべてのアカウントの割当量を再構築できます。EIPの他の実装では、 + * 仕様で要求されていないため、これらのイベントを発行しない場合があります。 * - * Finally, the non-standard {decreaseAllowance} and {increaseAllowance} - * functions have been added to mitigate the well-known issues around setting - * allowances. See {IERC20-approve}. + * 最後に、割当量設定に関する既知の問題を緩和するために、非標準の{decreaseAllowance}および{increaseAllowance}関数が追加されています。 + * {IERC20-approve}を参照してください。 */ ``` -### コントラクトの定義 {#contract-definition} +### コントラクト定義 {#contract-definition} ```solidity contract ERC20 is Context, IERC20 { ``` -この行では、継承を指定しています。ここでは、`IERC20`とOpenGSNのための`Context`を継承しています。 +この行では、継承を指定しています。ここでは、上記の`IERC20`と、OpenGSNのための`Context`を継承しています。   @@ -257,19 +250,19 @@ contract ERC20 is Context, IERC20 { ``` -この行では、`SafeMath`ライブラリを`uint256`型にアタッチしています。 このライブラリの詳細については、[こちら](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol)をご覧ください。 +この行では、`SafeMath`ライブラリを`uint256`型にアタッチしています。 このライブラリは[こちら](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol)で確認できます。 -### 変数の定義 {#variable-definitions} +### 変数定義 {#variable-definitions} -これらの定義では、コントラクトの状態変数を指定します。 変数には、`private`で宣言しているものがありますが、ブロックチェーン上の他のコントラクトから読み取れないというだけです。 _ブロックチェーンに秘密はありません_。すべてのノードのソフトウェアは、すべてのブロックのすべてのコントラクトの状態を保持します。 状態変数は、慣例として`_`のように命名されます。 +これらの定義では、コントラクトの状態変数を指定します。 これらの変数は`private`で宣言されていますが、これはブロックチェーン上の他のコントラクトから読み取れないというだけです。 _ブロックチェーンに秘密はありません_。すべてのノードのソフトウェアは、すべてのブロックですべてのコントラクトの状態を保持します。 慣例として、状態変数は`_`と命名されます。 -最初の2つの変数は、[マッピング](https://www.tutorialspoint.com/solidity/solidity_mappings.htm)であり、キーが数値であることを除いて、[連想配列](https://wikipedia.org/wiki/Associative_array)とほぼ同じような振る舞いをします。 ストレージは、デフォルト(ゼロ)とは異なる値を持つエントリのみに割り当てられます。 +最初の2つの変数は[マッピング](https://www.tutorialspoint.com/solidity/solidity_mappings.htm)であり、キーが数値である点を除けば、おおよそ[連想配列](https://wikipedia.org/wiki/Associative_array)と同じように動作します。 ストレージは、デフォルト(ゼロ)とは異なる値を持つエントリにのみ割り当てられます。 ```solidity mapping (address => uint256) private _balances; ``` -最初のマッピングである`_balances`は、トークンを保持しているアドレスとそれぞれの残高です。 残高にアクセスするには、`_balances[
]`という構文を使用します。 +最初のマッピングである`_balances`は、アドレスとそれぞれのこのトークンの残高です。 残高にアクセスするには、`_balances[
]`という構文を使用します。   @@ -277,7 +270,7 @@ contract ERC20 is Context, IERC20 { mapping (address => mapping (address => uint256)) private _allowances; ``` -この変数`_allowances`には、前述の割当量(allowance)が格納されます。 最初のインデックスは、トークンの所有者であり、2番目のインデックスは割当量(allowance)を使用するコントラクトです。 アドレスAが、アドレスBのアカウントから使える量にアクセスするには、`_allowances[B][A]`のようにします。 +この変数`_allowances`には、前述の割当量が格納されます。 最初のインデックスはトークンの所有者であり、2番目のインデックスは割当量を持つコントラクトです。 アドレスAがアドレスBのアカウントから使える量にアクセスするには、`_allowances[B][A]`を使用します。   @@ -297,78 +290,77 @@ contract ERC20 is Context, IERC20 { この3つの変数は、可読性を向上させるために使用されます。 最初の2つの変数は自明ですが、`_decimals`はそうではありません。 -イーサリアムには浮動小数点変数も小数変数もない一方で、 ユーザーはトークンの分割を好みます。 人々が金を通貨にすると決めた理由の一つとして、誰かがアヒル一羽の値段の分だけ牛を買おうとしたときに、お金を崩すのが難しかったことが挙げられます。 +一方で、イーサリアムには浮動小数点変数も小数変数もありません。 他方で、人間はトークンを分割できることを好みます。 人々が金を通貨に決めた理由の一つは、誰かが牛の価値のアヒル分を買おうとしたときに、お釣りを作るのが難しかったからです。 -これを解決するには整数で追跡すればよいのですが、実際のトークンの代わりに、価値が非常に小さな小数トークンで計算します。 イーサ(ETH)の場合、小数トークンはウェイ(wei)と呼ばれており、10^18 weiが 1 ETHと等価です。 執筆時点では、10,000,000,000,000 weiが、約1米ドルまたは約1ユーロセントです。 +解決策は、整数で追跡し、実際のトークンの代わりに、ほとんど価値のない小数トークンを数えることです。 etherの場合、小数トークンはweiと呼ばれ、10^18 weiが1 ETHと等価です。 執筆時点で、10,000,000,000,000 weiは、約1米ドルまたは1ユーロセントです。 -アプリケーションには、トークンの残高を表示する方法が必要です。 ユーザーが3,14,000,000,000,000,000,000,000weiを持っている場合、それは3.14 ETHでしょうか? それとも、31.41 ETHでしょうか? 3,141 ETHでしょうか? イーサ (ETH) の場合、1 ETHが10^18 weiと定義されていますが、トークンでは別の値を選択可能です。 トークンを分割する必要がなければ、値がゼロの`_decimals`を使用できます。 ETHと同じ基準を使用したい場合は、**18**の値を指定してください。 +アプリケーションは、トークンの残高を表示する方法を知る必要があります。 ユーザーが3,141,000,000,000,000,000 weiを持っている場合、それは3.14 ETHでしょうか? 31.41 ETHでしょうか? 3,141 ETHでしょうか? etherの場合、10^18 weiが1 ETHと定義されていますが、あなたのトークンでは別の値を選択できます。 トークンを分割する必要がなければ、値がゼロの`_decimals`を使用できます。 ETHと同じ基準を使用したい場合は、値**18**を使用してください。 ### コンストラクタ {#the-constructor} ```solidity /** - * @dev Sets the values for {name} and {symbol}, initializes {decimals} with - * a default value of 18. + * @dev {name}と{symbol}の値を設定し、{decimals}を + * デフォルト値の18で初期化します。 * - * To select a different value for {decimals}, use {_setupDecimals}. + * {decimals}に別の値を選択するには、{_setupDecimals}を使用します。 * - * All three of these values are immutable: they can only be set once during - * construction. + * これら3つの値はすべて不変です。構築時に一度しか設定できません。 */ constructor (string memory name_, string memory symbol_) public { + // Solidity ≥0.7.0では、'public'は暗黙的であり、省略できます。 + _name = name_; _symbol = symbol_; _decimals = 18; } ``` -コンストラクタは、コントラクトが最初に作成されたときに呼び出されます。 慣例として関数パラメータは、 `_`のように命名されます。 +コンストラクタは、コントラクトが最初に作成されたときに呼び出されます。 慣例として関数パラメータは、`_`のように命名されます。 ### ユーザーインターフェース関数 {#user-interface-functions} ```solidity /** - * @dev Returns the name of the token. + * @dev トークンの名前を返します。 */ function name() public view returns (string memory) { return _name; } /** - * @dev Returns the symbol of the token, usually a shorter version of the - * name. + * @dev トークンのシンボルを返します。通常は名前の短いバージョンです。 + * 名前です。 */ function symbol() public view returns (string memory) { return _symbol; } /** - * @dev Returns the number of decimals used to get its user representation. - * For example, if `decimals` equals `2`, a balance of `505` tokens should - * be displayed to a user as `5,05` (`505 / 10 ** 2`). + * @dev ユーザー表現を取得するために使用される小数点以下の桁数を返します。 + * 例えば、`decimals`が`2`の場合、`505`トークンの残高は + * `5,05` (`505 / 10 ** 2`)としてユーザーに表示されるべきです。 * - * Tokens usually opt for a value of 18, imitating the relationship between - * ether and wei. This is the value {ERC20} uses, unless {_setupDecimals} is - * called. + * トークンは通常、etherとweiの関係を模倣して、値18を選択します。これは、{_setupDecimals}が呼び出されない限り、{ERC20}が使用する値です。 * - * NOTE: This information is only used for _display_ purposes: it in - * no way affects any of the arithmetic of the contract, including - * {IERC20-balanceOf} and {IERC20-transfer}. + * 注: この情報は_表示_目的でのみ使用されます。これは + * {IERC20-balanceOf}や{IERC20-transfer}を含む、コントラクトのどの算術にも + * 影響を与えません。 */ function decimals() public view returns (uint8) { return _decimals; } ``` -これらの関数(`name`、`symbol`、`decimals`)は、ユーザーインターフェースがコントラクトの情報を入手できるようするため、ユーザーインターフェースにコントラクトの情報が正しく表示されるようになります。 +これらの関数`name`、`symbol`、`decimals`は、ユーザーインターフェースがあなたのコントラクトについて知り、正しく表示できるようにするのに役立ちます。 -戻り値の型は、 `string memory`です。メモリに格納されている文字列が返されることを意味します。 文字列などの変数は、以下の3つの場所に格納できます。 +戻り値の型は`string memory`で、メモリに格納されている文字列を返すことを意味します。 文字列などの変数は、3つの場所に格納できます。 -| | 存続期間 | コントラクトアドレス | ガス代 | -| ------ | -------- | ---------- | ------------------------ | -| メモリ | 関数呼び出しの間 | 読み取り/書き込み | 数十または数百(上位のロケーションほど高い) | -| コールデータ | 関数呼び出しの間 | 読み取り専用 | 戻り値型としては使用できず、関数パラメータ型のみ | -| ストレージ | 変更されるまで | 読み取り/書き込み | 高額(読み取りに800、書き込みに20 k) | +| | 存続期間 | コントラクトアクセス | ガス代 | +| ------ | ------- | ---------- | ----------------------------------------- | +| Memory | 関数呼び出し中 | 読み取り/書き込み | 数十または数百(上位のロケーションほど高い) | +| コールデータ | 関数呼び出し中 | 読み取り専用 | 戻り値型としては使用できず、関数パラメータ型のみ | +| ストレージ | 変更されるまで | 読み取り/書き込み | 高額(読み取りに800、書き込みに20k) | このケースでは、`memory`の使用が最善の選択肢です。 @@ -378,7 +370,7 @@ contract ERC20 is Context, IERC20 { ```solidity /** - * @dev See {IERC20-totalSupply}. + * @dev {IERC20-totalSupply}を参照してください。 */ function totalSupply() public view override returns (uint256) { return _totalSupply; @@ -391,30 +383,30 @@ contract ERC20 is Context, IERC20 { ```solidity /** - * @dev See {IERC20-balanceOf}. + * @dev {IERC20-balanceOf}を参照してください。 */ function balanceOf(address account) public view override returns (uint256) { return _balances[account]; } ``` -アカウントの残高を読み取ります。 誰でも他のユーザーのアカウント残高を取得できることに注意してください。 どのノードでも取得可能な情報であるため、隠そうとしても無駄です。 _ブロックチェーンに秘密はありません_。 +アカウントの残高を読み取ります。 誰でも他の人のアカウント残高を取得できることに注意してください。 この情報はどのノードでも入手可能であるため、隠そうとしても無駄です。 _ブロックチェーンに秘密はありません。_ ### トークンの転送 {#transfer-tokens} ```solidity /** - * @dev See {IERC20-transfer}. + * @dev {IERC20-transfer}を参照してください。 * - * Requirements: + * 要件: * - * - `recipient` cannot be the zero address. - * - the caller must have a balance of at least `amount`. + * - `recipient`はゼロアドレスであってはなりません。 + * - 呼び出し元は少なくとも`amount`の残高を持っている必要があります。 */ function transfer(address recipient, uint256 amount) public virtual override returns (bool) { ``` -`transfer`関数は、送信者のアカウントから別のアカウントにトークンを転送するために呼び出します。 戻り値がブール値になっていますが、この値は常に**true**を返すことに注意してください。 転送が失敗した場合、コントラクトは、呼び出しを取り消します。 +`transfer`関数は、送信者のアカウントから別のアカウントにトークンを転送するために呼び出します。 戻り値がブール値ですが、その値は常に**true**であることに注意してください。 転送が失敗した場合、コントラクトは呼び出しをリバートします。   @@ -424,44 +416,44 @@ contract ERC20 is Context, IERC20 { } ``` -`_transfer`関数は、実際の作業を行います。 これはprivate関数であり、他のコントラクト関数からのみ呼び出せます。 慣例として、private関数は状態変数と同様に、`_`のように命名されます。 +`_transfer`関数が実際の作業を行います。 これはprivate関数であり、他のコントラクト関数からのみ呼び出せます。 慣例として、private関数は状態変数と同様に`_`と命名されます。 -通常、Solidityでは、メッセージ送信者に`msg.sender`を使用します。 しかし、[OpenGSN](http://opengsn.org/)では使えません。 イーサ(ETH)無しのトークンのトランザクションを許可したい場合は、`_msgSender()`を使用しなければなりません。 通常のトランザクションでは、`msg.sender`を返しますが、イーサ(ETH)無しのトランザクションの場合は、メッセージを中継したコントラクトではなく、元の署名者を返します。 +通常、Solidityでは、メッセージ送信者に`msg.sender`を使用します。 しかし、それでは[OpenGSN](http://opengsn.org/)が機能しません。 トークンでetherレスのトランザクションを許可したい場合は、`_msgSender()`を使用する必要があります。 通常のトランザクションでは`msg.sender`を返しますが、etherレスのトランザクションの場合は、メッセージを中継したコントラクトではなく、元の署名者を返します。 -### 割当量(allowance)関連の関数 {#allowance-functions} +### 割当量関数 {#allowance-functions} -割当量機能を実装した関数には、`allowance`、`approve`、 `transferFrom`、`_approve`があります。 さらに、OpenZeppelin実装には、基本的な標準に加えてセキュリティを向上させる `increaseAllowance`や`decreaseAllowance`などの複数の機能が含まれます。 +これらは割当量機能を実装する関数です: `allowance`、`approve`、`transferFrom`、`_approve`。 さらに、OpenZeppelin実装は、セキュリティを向上させる機能である`increaseAllowance`と`decreaseAllowance`を含むように、基本的な標準を超えています。 #### allowance関数 {#allowance} ```solidity /** - * @dev See {IERC20-allowance}. + * @dev {IERC20-allowance}を参照してください。 */ function allowance(address owner, address spender) public view virtual override returns (uint256) { return _allowances[owner][spender]; } ``` -`allowance`関数を使用すると、誰でも割当量を確認することができます。 +`allowance`関数を使用すると、誰でも任意の割当量を確認することができます。 #### approve関数 {#approve} ```solidity /** - * @dev See {IERC20-approve}. + * @dev {IERC20-approve}を参照してください。 * - * Requirements: + * 要件: * - * - `spender` cannot be the zero address. + * - `spender`はゼロアドレスであってはなりません。 */ function approve(address spender, uint256 amount) public virtual override returns (bool) { ``` -この関数は、割当量を作成するときに呼び出します。 上述の`transfer`関数と似ています。 +この関数は、割当量を作成するときに呼び出します。 上記の`transfer`関数と似ています。 -- この関数は、単に実際に作業を行うinternal関数(この場合は`_approve`)を呼び出します。 -- この関数は、成功した場合は`true`を返し、失敗した場合は取り消します。 +- この関数は、単に実際に作業を行う内部関数(この場合は`_approve`)を呼び出します。 +- この関数は、成功した場合は`true`を返し、失敗した場合はリバートします。   @@ -471,25 +463,25 @@ contract ERC20 is Context, IERC20 { } ``` -internal関数を使用して、状態変更が起こる場所の数を最小限にしています。 状態を変更する_すべての_関数には、潜在的なセキュリティリスクがあり、セキュリティ監査が必要です。 このような方法で、間違いを犯す可能性を下げています。 +内部関数を使用して、状態変更が起こる場所の数を最小限にしています。 状態を変更する_すべての_関数には潜在的なセキュリティリスクがあり、セキュリティ監査が必要です。 この方法で、間違いを犯す可能性を下げています。 #### transferFrom関数 {#transferFrom} -これは、使用者(spender)が割当量(allowance)を使用するために呼び出す関数です。 これには、使う量の転送操作と、その量を割当量(allowance)から減らす操作の、2つの操作が必要になります。 +これは、使用者(`spender`)が割当量を使用するために呼び出す関数です。 これには、使用される量を転送し、その量だけ割当量を減らすという2つの操作が必要です。 ```solidity /** - * @dev See {IERC20-transferFrom}. + * @dev {IERC20-transferFrom}を参照してください。 * - * Emits an {Approval} event indicating the updated allowance. これは - * EIPでは必要ありません。 {ERC20}の最初にある注意事項を参照してください。 + * 更新された割当量を示す{Approval}イベントを発行します。これは + * EIPでは要求されていません。{ERC20}の冒頭の注記を参照してください。 * - * Requirements: + * 要件: * - * - `sender` and `recipient` cannot be the zero address. - * - `sender` must have a balance of at least `amount`. - * - the caller must have allowance for ``sender``'s tokens of at least - * `amount`. + * - `sender`と`recipient`はゼロアドレスであってはなりません。 + * - `sender`は少なくとも`amount`の残高を持っている必要があります。 + * - 呼び出し元は、`sender`のトークンに対して少なくとも + * `amount`の割当量を持っている必要があります。 */ function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) { @@ -498,7 +490,8 @@ internal関数を使用して、状態変更が起こる場所の数を最小限   -`a.sub(b, "message")`関数の呼び出しでは、次の2つのことを行います。 まず、`a-b`を計算します。これが新しい割当量になります。 次に、この結果が負の数になっていないかをチェックします。 負になっている場合、提供されているメッセージを表示して、呼び出しが取り消されます。 呼び出しが取り消されると、呼び出し中に実行されたすべての処理が無効になるため、`_transfer`を元に戻す必要がないことに注意してください。 +`a.sub(b, "message")`関数の呼び出しでは、次の2つのことを行います。 まず、`a-b`を計算します。これが新しい割当量になります。 +次に、この結果が負の数になっていないかをチェックします。 負になっている場合、提供されているメッセージを表示して呼び出しがリバートされます。 呼び出しがリバートされると、その呼び出し中に以前に実行されたすべての処理は無視されるため、`_transfer`を元に戻す必要はありません。 ```solidity _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, @@ -507,50 +500,49 @@ internal関数を使用して、状態変更が起こる場所の数を最小限 } ``` -#### OpenZeppelinによる安全性の向上 {#openzeppelin-safety-additions} +#### OpenZeppelinの安全追加機能 {#openzeppelin-safety-additions} -ゼロ以外の割当量を別のゼロ以外の値に設定することには、リスクが伴います。自分が制御できるのは自分のトランザクションの順序のみであり、他のユーザーのトランザクションの順序を制御することはできないからです。 アリスという初心者ユーザーと、ビルという誠実さに欠けるユーザーがいるとします。 アリスは、ビルが提供しているサービスを購入することにしました。購入には5トークンの費用がかかるため、アリスは5トークンの割当量(allowance)をビルに付与しました。 +ゼロ以外の割当量を別のゼロ以外の値に設定することにはリスクが伴います。なぜなら、自分が制御できるのは自分のトランザクションの順序のみであり、他のユーザーのトランザクションの順序は制御できないからです。 経験の浅いアリスと、不誠実なビルという2人のユーザーがいるとします。 アリスはビルからサービスを受けたいと考えており、その費用は5トークンだと思っています。そこで、彼女はビルに5トークンの割当量を与えます。 -その後、ビルの設定した価格が何らかの理由で10トークンに上がりました。 アリスは依然としてそのサービスの購入を希望しており、ビルへの割当量を10に設定したトランザクションを送信しました。 ビルは、トランザクションプールでこの新しいトランザクションを確認した瞬間に、より早くマイニングされるようにかなり高いガス代を設定した、アリスの5トークンを使うトランザクションを送信します。 この方法で、ビルは5トークンを使います。その後、アリスが送信した新しい割当量がマイニングされたら、さらに10トークンを使います。こうして、アリスが承認するつもりだった量を超える、合計15トークンを使えることになります。 この手法は、[フロントランニング](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running)と呼ばれます。 +その後、何かが変わり、ビルの価格は10トークンに上がりました。 まだサービスを受けたいアリスは、ビルの割当量を10に設定するトランザクションを送信します。 ビルはこの新しいトランザクションをトランザクションプールで確認した瞬間に、アリスの5トークンを使うトランザクションを送信し、より早くマイニングされるように非常に高いガス価格を設定します。 この方法で、ビルは最初に5トークンを使い、アリスの新しい割当量がマイニングされたら、さらに10トークンを使って合計15トークンを得ることができます。これはアリスが承認するつもりだった額よりも多いです。 このテクニックは[フロントランニング](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running)と呼ばれます。 -| アリスのトランザクション | アリスのノンス | ビルのトランザクション | ビルのノンス | ビルの割当量 | ビルのアリスからの総収入 | -| ----------------- | ------- | ----------------------------- | ------ | ------ | ------------ | -| approve(Bill, 5) | 10 | | | 5 | 0 | -| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 | -| approve(Bill, 10) | 11 | | | 10 | 5 | -| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 15 | +| アリスのトランザクション | アリスのノンス | ビルのトランザクション | ビルのノンス | ビルの割当量 | ビルのアリスからの総収入 | +| ------------------------------------ | ------- | ------------------------------------------------ | ------ | ------ | ------------ | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 | +| approve(Bill, 10) | 11 | | | 10 | 5 | +| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 15 | -この問題を回避するには、割当量を特定の量に変更できる2つの関数(`increaseAllowance`と`decreaseAllowance`)を使用します。 これらの関数を使用すれば、ビルがすでに5トークンを使用していた場合、その後に使用できるのは残りの5トークンのみとなります。 タイミングに応じて、次のような2つの動作が考えられますが、いずれの場合でもビルが取得するのは10トークンのみです。 +この問題を回避するには、2つの関数(`increaseAllowance`と`decreaseAllowance`)を使用して、割当量を特定の量だけ変更します。 これにより、ビルがすでに5トークンを使用していた場合でも、その後に使用できるのは追加の5トークンのみとなります。 タイミングに応じて、次のような2つの動作が考えられますが、いずれの場合でもビルが取得するのは10トークンのみです。 A: -| アリスのトランザクション | アリスのノンス | ビルのトランザクション | ビルのノンス | ビルの割当量 | ビルのアリスからの総収入 | -| -------------------------- | -------:| ---------------------------- | ------:| -------:| ------------ | -| approve(Bill, 5) | 10 | | | 5 | 0 | -| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 | -| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 | -| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 | +| アリスのトランザクション | アリスのノンス | ビルのトランザクション | ビルのノンス | ビルの割当量 | ビルのアリスからの総収入 | +| --------------------------------------------- | ------: | ----------------------------------------------- | -----: | ------: | ------------ | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 | +| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 | +| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 | B: -| アリスのトランザクション | アリスのノンス | ビルのトランザクション | ビルのノンス | ビルの割当量 | ビルのアリスからの総収入 | -| -------------------------- | -------:| ----------------------------- | ------:| --------:| ------------:| -| approve(Bill, 5) | 10 | | | 5 | 0 | -| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 | -| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 | +| アリスのトランザクション | アリスのノンス | ビルのトランザクション | ビルのノンス | ビルの割当量 | ビルのアリスからの総収入 | +| --------------------------------------------- | ------: | ------------------------------------------------ | -----: | -------: | -----------: | +| approve(Bill, 5) | 10 | | | 5 | 0 | +| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 | +| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 | ```solidity /** - * @dev Atomically increases the allowance granted to `spender` by the caller. + * @dev 呼び出し元によって付与された`spender`への割当量をアトミックに増加させます。 * - * This is an alternative to {approve} that can be used as a mitigation for - * problems described in {IERC20-approve}. + * これは{approve}の代替手段であり、{IERC20-approve}で説明されている問題を緩和するために使用できます。 * - * Emits an {Approval} event indicating the updated allowance. + * 更新された割当量を示す{Approval}イベントを発行します。 * - * Requirements: + * 要件: * - * - `spender` cannot be the zero address. + * - `spender`はゼロアドレスであってはなりません。 */ function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) { _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue)); @@ -558,23 +550,22 @@ B: } ``` -`a.add(b)`関数は、安全な加算です。 万が一、`a`+`b`>=`2^256`のような計算が行われても、通常の加算で発生してしまうオーバー(アンダー)フローが発生しません。 +`a.add(b)`関数は、安全な加算です。 万が一`a`+`b`>=`2^256`となっても、通常の加算のようにラップアラウンドしません。 ```solidity /** - * @dev Atomically decreases the allowance granted to `spender` by the caller. + * @dev 呼び出し元によって付与された`spender`への割当量をアトミックに減少させます。 * - * This is an alternative to {approve} that can be used as a mitigation for - * problems described in {IERC20-approve}. + * これは{approve}の代替手段であり、{IERC20-approve}で説明されている問題を緩和するために使用できます。 * - * Emits an {Approval} event indicating the updated allowance. + * 更新された割当量を示す{Approval}イベントを発行します。 * - * Requirements: + * 要件: * - * - `spender` cannot be the zero address. - * - `spender` must have allowance for the caller of at least - * `subtractedValue`. + * - `spender`はゼロアドレスであってはなりません。 + * - `spender`は呼び出し元に対して、少なくとも + * `subtractedValue`の割当量を持っている必要があります。 */ function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) { _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, @@ -587,27 +578,27 @@ B: 次の4つの関数(`_transfer`、`_mint`、`_burn`、`_approve`)は、実際の処理を行います。 -#### \_transfer関数 {#_transfer} +#### _transfer関数 {#_transfer} ```solidity /** - * @dev Moves tokens `amount` from `sender` to `recipient`. + * @dev トークン`amount`を`sender`から`recipient`に移動させます。 * - * This is internal function is equivalent to {transfer}, and can be used to - * e.g., implement automatic token fees, slashing mechanisms, etc. + * この内部関数は{transfer}と同等であり、 + * 例えば、自動的なトークン手数料やスラッシングメカニズムなどを実装するために使用できます。 * - * Emits a {Transfer} event. + * {Transfer}イベントを発行します。 * - * Requirements: + * 要件: * - * - `sender` cannot be the zero address. - * - `recipient` cannot be the zero address. - * - `sender` must have a balance of at least `amount`. + * - `sender`はゼロアドレスであってはなりません。 + * - `recipient`はゼロアドレスであってはなりません。 + * - `sender`は少なくとも`amount`の残高を持っている必要があります。 */ function _transfer(address sender, address recipient, uint256 amount) internal virtual { ``` -`_transfer`関数は、トークンをあるアカウントから別のアカウントへ転送します。 この関数は、(送信者自身のアカウントから転送する)`transfer`と、(割当量を使用するために他のユーザーのアカウントから転送する)`transferFrom`の両方から呼び出されます。 +この`_transfer`関数は、トークンをあるアカウントから別のアカウントへ転送します。 この関数は、`transfer`(送信者自身のアカウントからの転送)と`transferFrom`(割当量を使用して他のユーザーのアカウントから転送)の両方から呼び出されます。   @@ -628,11 +619,11 @@ B: このコントラクトを使用するには2つの方法があります。 1. 自分のコードのテンプレートとして使う -1. [このコントラクトを継承](https://www.bitdegree.org/learn/solidity-inheritance)し、変更する必要がある関数のみをオーバーライドする +2. [コントラクトから継承](https://www.bitdegree.org/learn/solidity-inheritance)し、修正が必要な関数のみをオーバーライドする -OpenZeppelin ERC-20のコードはすでに監査を受けており、安全であることが知られているため、2つ目の方法をお勧めします。 継承を使用すると、変更した関数が明らかになります。他のユーザーは、変更された特定の関数を監査するだけで、そのコントラクトを信頼することができます。 +OpenZeppelinのERC-20コードはすでに監査を受けており、安全であることが示されているため、2つ目の方法がはるかに優れています。 継承を使用すると、変更した関数が明らかになり、人々はコントラクトを信頼するためにそれらの特定の関数のみを監査すればよくなります。 -多くの場合、トークンの所有者が変わるたびに関数を実行すると便利です。 ただし、`_transfer`は非常に重要な関数ですが、安全でない書き込みをしてしまう可能性があるため(下記参照)、オーバーライドしないことをお勧めします。 この解決策として、`_beforeTokenTransfer`という[フック関数](https://wikipedia.org/wiki/Hooking)があります。 この関数をオーバライドすれば、転送のたびに呼び出されるようになります。 +多くの場合、トークンの所有者が変わるたびに関数を実行すると便利です。 しかし、`_transfer`は非常に重要な関数であり、安全でない書き方をしてしまう可能性があるため(下記参照)、オーバーライドしないことをお勧めします。 解決策は、[フック関数](https://wikipedia.org/wiki/Hooking)である`_beforeTokenTransfer`です。 この関数をオーバーライドすれば、転送のたびに呼び出されるようになります。   @@ -641,7 +632,7 @@ OpenZeppelin ERC-20のコードはすでに監査を受けており、安全で _balances[recipient] = _balances[recipient].add(amount); ``` -この2行で、実際に転送を行っています。 この2行の間に**何もない**ことと、転送する量を送信者から減算してから、その量を受取人に加算していることに注意してください。 この2行の間に別のコントラクトへの呼び出しがある場合、このコントラクトで不正を行うために使用される可能性があるため、このことは非常に重要になります。 こうすることで、転送がアトミックになる(他の操作に割り込まれないようになる)ため、転送の途中で何かが発生することはなくなります。 +この2行で、実際に転送を行っています。 この2行の間には**何も**なく、受取人に加算する前に送信者から転送額を減算していることに注意してください。 この2行の間に別のコントラクトへの呼び出しがある場合、このコントラクトで不正を行うために使用される可能性があるため、このことは非常に重要になります。 こうすることで、転送がアトミックになり、その途中で何も起こらなくなります。   @@ -650,23 +641,25 @@ OpenZeppelin ERC-20のコードはすでに監査を受けており、安全で } ``` -最後に、`Transfer`イベントを発行します。 イベントは、スマートコントラクトからアクセスできません。しかし、ブロックチェーンの外で実行されているコードは、イベントをリッスンして対応することができます。 例えば、ウォレットで所有者がより多くのトークンを得た時期を追跡できます。 +最後に、`Transfer`イベントを発行します。 イベントはスマートコントラクトからアクセスできませんが、ブロックチェーンの外で実行されているコードは、イベントをリッスンして対応することができます。 例えば、ウォレットは所有者がより多くのトークンを得た時期を追跡できます。 -#### \_mint関数と\_burn関数 {#_mint-and-_burn} +#### _mint関数と_burn関数 {#_mint-and-_burn} -この2つの関数(`_mint`と`_burn`)は、トークンの総供給量を変更します。 これらはinternalであり、このコントラクト内にこれらを呼び出す関数はありません。そのため、コントラクトを継承し、新しいトークンのミントや既存のトークンのバーンを実行する条件を決定する独自のロジックを追加する場合にのみ役立ちます。 +この2つの関数(`_mint`と`_burn`)は、トークンの総供給量を変更します。 +これらは内部関数であり、このコントラクト内にこれらを呼び出す関数はありません。そのため、コントラクトを継承し、どのような条件下で新しいトークンをミントし、既存のトークンをバーンするかを決定する独自のロジックを追加する場合にのみ役立ちます。 -**注:** すべてのERC-20トークンには、トークン管理を規定している独自のビジネスロジックがあります。 例えば、固定した供給量のコントラクトでは、コンストラクタ内で `_mint`のみを呼び出す可能性があり、`_burn`を呼び出すことはありません。 トークンを販売するコントラクトは、支払いが行われたタイミングで`_mint`を呼び出し、天井知らずのインフレを避けるために、ある時点で`_burn`を呼び出すことが考えられます。 +**注:** すべてのERC-20トークンには、トークン管理を規定する独自のビジネスロジックがあります。 +例えば、固定供給量のコントラクトでは、コンストラクタ内で`_mint`のみを呼び出し、`_burn`を呼び出すことはありません。 トークンを販売するコントラクトは、支払いが行われたタイミングで`_mint`を呼び出し、おそらく、天井知らずのインフレを避けるためにある時点で`_burn`を呼び出します。 ```solidity - /** @dev Creates `amount` tokens and assigns them to `account`, increasing - * the total supply. + /** @dev `amount`のトークンを作成して`account`に割り当て、 + * 総供給量を増やします。 * - * Emits a {Transfer} event with `from` set to the zero address. + * `from`がゼロアドレスに設定された{Transfer}イベントを発行します。 * - * Requirements: + * 要件: * - * - `to` cannot be the zero address. + * - `to`はゼロアドレスであってはなりません。 */ function _mint(address account, uint256 amount) internal virtual { require(account != address(0), "ERC20: mint to the zero address"); @@ -677,21 +670,21 @@ OpenZeppelin ERC-20のコードはすでに監査を受けており、安全で } ``` -トークンの総額が変更された場合は、`_totalSupply`を必ずアップデートしてください。 +トークンの総数が変更された場合は、`_totalSupply`を必ずアップデートしてください。   -``` +```solidity /** - * @dev Destroys `amount` tokens from `account`, reducing the - * total supply. + * @dev `account`から`amount`のトークンを破棄し、 + * 総供給量を減らします。 * - * Emits a {Transfer} event with `to` set to the zero address. + * `to`がゼロアドレスに設定された{Transfer}イベントを発行します。 * - * Requirements: + * 要件: * - * - `account` cannot be the zero address. - * - `account` must have at least `amount` tokens. + * - `account`はゼロアドレスであってはなりません。 + * - `account`は少なくとも`amount`のトークンを持っている必要があります。 */ function _burn(address account, uint256 amount) internal virtual { require(account != address(0), "ERC20: burn from the zero address"); @@ -706,23 +699,23 @@ OpenZeppelin ERC-20のコードはすでに監査を受けており、安全で `_burn`関数は、方向が逆であることを除き`_mint`とほぼ同じです。 -#### \_approve関数 {#_approve} +#### _approve関数 {#_approve} -これは、実際の割当量(allowance)を指定する関数です。 所有者は自身の現在の残高よりも高い割当量を指定できることに注意してください。 残高は転送時にチェックされるため、割当量の作成時の残高と異なっていても問題ありません。 +これは、実際に割当量を指定する関数です。 所有者は自身の現在の残高よりも高い割当量を指定できることに注意してください。 残高は転送時にチェックされ、割当量の作成時の残高と異なる可能性があるため、これは問題ありません。 ```solidity /** - * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. + * @dev `owner`のトークンに対する`spender`の割当量を`amount`に設定します。 * - * This internal function is equivalent to `approve`, and can be used to - * e.g., set automatic allowances for certain subsystems, etc. + * この内部関数は`approve`と同等であり、 + * 例えば、特定のサブシステムに対する自動的な割当量などを設定するために使用できます。 * - * Emits an {Approval} event. + * {Approval}イベントを発行します。 * - * Requirements: + * 要件: * - * - `owner` cannot be the zero address. - * - `spender` cannot be the zero address. + * - `owner`はゼロアドレスであってはなりません。 + * - `spender`はゼロアドレスであってはなりません。 */ function _approve(address owner, address spender, uint256 amount) internal virtual { require(owner != address(0), "ERC20: approve from the zero address"); @@ -733,7 +726,7 @@ OpenZeppelin ERC-20のコードはすでに監査を受けており、安全で   -`Approval`イベントを発行します。 アプリケーションがどのように書かれているかによって異なりますが、使用者(spender)のコントラクトには、所有者またはこれらのイベントをリッスンしているサーバーのいずれかによって承認(Approval)が通知されます。 +`Approval`イベントを発行します。 アプリケーションがどのように書かれているかによって異なりますが、使用者(`spender`)のコントラクトには、所有者またはこれらのイベントをリッスンしているサーバーのいずれかによって承認が通知されます。 ```solidity emit Approval(owner, spender, amount); @@ -741,57 +734,61 @@ OpenZeppelin ERC-20のコードはすでに監査を受けており、安全で ``` -### 小数変数の変更 {#modify-the-decimals-variable} +### decimals変数の変更 {#modify-the-decimals-variable} ```solidity /** - * @dev Sets {decimals} to a value other than the default one of 18. + * @dev {decimals}をデフォルト値の18以外の値に設定します。 * - * WARNING: This function should only be called from the constructor. Most - * applications that interact with token contracts will not expect - * {decimals} to ever change, and may work incorrectly if it does. + * 警告: この関数はコンストラクタからのみ呼び出すべきです。ほとんどの + * トークンコントラクトと対話するアプリケーションは、 + * {decimals}が変更されることを想定しておらず、変更されると誤動作する可能性があります。 */ function _setupDecimals(uint8 decimals_) internal { _decimals = decimals_; } ``` -この関数は、`_decimals`変数を変更します。`_decimals`変数は、量(金額)の解釈方法をユーザーインターフェースに伝えるのに使用されます。 コンストラクタから呼び出される必要があります。 その後のどの時点においても、この関数を呼び出すと不正になります。アプリケーションは、このような処理をするようには設計されていません。 +この関数は`_decimals`変数を変更します。この変数は、量の解釈方法をユーザーインターフェースに伝えるのに使用されます。 +コンストラクタから呼び出すべきです。 その後のどの時点においてもこの関数を呼び出すと不正になり、アプリケーションはこのような処理をするようには設計されていません。 ### フック {#hooks} ```solidity /** - * @dev Hook that is called before any transfer of tokens. これには + * @dev トークンのあらゆる転送の前に呼び出されるフック。これには * ミントとバーンが含まれます。 * - * Calling conditions: + * 呼び出し条件: * - * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens - * will be to transferred to `to`. - * - when `from` is zero, `amount` tokens will be minted for `to`. - * - when `to` is zero, `amount` of ``from``'s tokens will be burned. - * - `from` and `to` are never both zero. + * - `from`と`to`が両方ともゼロでない場合、`from`のトークンの`amount`が + * `to`に転送されます。 + * - `from`がゼロの場合、`amount`のトークンが`to`のためにミントされます。 + * - `to`がゼロの場合、`from`のトークンの`amount`がバーンされます。 + * - `from`と`to`が両方ともゼロになることはありません。 * - * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]. + * フックについてさらに学ぶには、xref:ROOT:extending-contracts.adoc#using-hooks[フックの使用]を参照してください。 */ function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { } } ``` -このフック関数は、転送中に呼び出されます。 空になっていますが、何かを実行するのにこの関数が必要な場合は、オーバーライドしてください。 +このフック関数は、転送中に呼び出されます。 ここでは空になっていますが、何かを実行するのにこの関数が必要な場合は、オーバーライドしてください。 -## まとめ {#conclusion} +## 結論 {#conclusion} 確認のため、このコントラクトの最も重要な点を以下にまとめています(個人的な意見のため、他者にとって重要な点とは異なる場合があります) 。 -- _ブロックチェーンに秘密はありません_。 スマートコントラクトがアクセスできる情報は、世界中で利用可能であることを意味します。 -- 自分のトランザクションの順序は自分で制御できますが、他のユーザーのトランザクションが発生するタイミングは制御できません。 これが、割当量(allowance)の変更に伴うリスクになります。変更により、使用者(spender)が変更前と変更後の両方の割当量を使用できてしまうためです。 -- `uint256`型の値がオーバー(アンダー)フローします。 つまり、例えば_0-1=2^256-1_です。 これが望ましい動作ではない場合、プログラムで確認する必要があります(または、それを行うSafeMathライブラリを使用します)。 この仕様は、[Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html)で変更されていることに注意してください。 -- 監査を容易にするため、特定の場所で特定の型のすべての状態変更を行います。 例えば、`_approve`が、`approve`、`transferFrom`、`increaseAllowance`、`decreaseAllowance`などによって呼び出されるのは、この理由です。 -- (`_transfer`で見られるように)状態変更は、処理の途中で他の操作に割り込まれることがないアトミックである必要があります。 これは状態変更中に、一貫性のない状態が存在するためです。 例えば、送信者の残高からトークンを差し引いた時点から、受取人の残高にそのトークンを加えるまでの間は、存在すべき数よりも少ない数のトークンが存在することになります。 この2つの処理の間に別の操作(特に、異なるコントラクトの呼び出しなど)がある場合、このトークンの状態が悪用される可能性があります。 +- ブロックチェーンには秘密はありません。 スマートコントラクトがアクセスできる情報は、全世界で利用可能です。 +- 自分のトランザクションの順序は自分で制御できますが、他のユーザーのトランザクションが発生するタイミングは制御できません。 これが、割当量の変更が危険となりうる理由です。変更により、使用者(`spender`)が両方の割当量の合計を使用できてしまうためです。 +- `uint256`型の値はラップアラウンドします。 言い換えると、_0-1=2^256-1_となります。 これが望ましい動作ではない場合、プログラムで確認する必要があります(または、それを行うSafeMathライブラリを使用します)。 これは[Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html)で変更されたことに注意してください。 +- 監査を容易にするため、特定の場所で特定の型のすべての状態変更を行います。 + これが、例えば`approve`、`transferFrom`、`increaseAllowance`、`decreaseAllowance`によって呼び出される`_approve`が存在する理由です。 +- 状態変更は、(`_transfer`で見られるように)処理の途中で他のアクションに割り込まれることがないアトミックである必要があります。 これは状態変更中に、一貫性のない状態が存在するためです。 例えば、送信者の残高から差し引いた時点から、受取人の残高に加えるまでの間は、存在するべき数よりも少ないトークンが存在することになります。 この2つの処理の間に別の操作(特に、異なるコントラクトの呼び出しなど)がある場合、このトークンの状態が悪用される可能性があります。 + +ここまで、OpenZeppelin ERC-20コントラクトがどのように書かれているか、特に、より安全に記述する方法を学びました。是非自分でも安全なコントラクトとアプリケーションを作成してみてください。 -ここまで、OpenZeppelin ERC-20コントラクトがどのように書かれているかについて見てきました。特に、より安全に記述する方法を学びました。是非自分でも安全なコントラクトとアプリケーションを作成してみてください。 +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/erc20-with-safety-rails/index.md b/public/content/translations/ja/developers/tutorials/erc20-with-safety-rails/index.md index ed97fc06bfd..26fabbd4847 100644 --- a/public/content/translations/ja/developers/tutorials/erc20-with-safety-rails/index.md +++ b/public/content/translations/ja/developers/tutorials/erc20-with-safety-rails/index.md @@ -1,10 +1,9 @@ --- -title: ERC-20の安全策 -description: つまらないミスをするのを避ける方法 +title: "安全策を備えたERC-20" +description: "ユーザーのうっかりミスを防ぐ方法" author: Ori Pomerantz lang: ja -tags: - - "ERC-20" +tags: [ "ERC-20" ] skill: beginner published: 2022-08-15 --- @@ -13,48 +12,51 @@ published: 2022-08-15 イーサリアムの素晴らしい点の1つとして、トランザクションを変更したり取り消したりできる中央機関が存在しないことがあります。 反対に、イーサリアムでは、ユーザーの間違いや不正なトランザクションを取り消す権限を持つ中央機関が存在しないことがデメリットになりえます。 この記事では、[ERC-20](/developers/docs/standards/tokens/erc-20/)トークンでユーザーがしてしまうよくあるミスや、そのミスを防ぐトークンの作成方法について説明します。また、中央機関に権限を与えることについても説明します (例えば、アカウントの凍結など) 。 -注意: [OpenZeppelin ERC-20トークンコントラクト](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20)を使いますが、このコントラクト自体について詳しくは説明しません。 ERC-20トークンコントラクトの詳細については、[こちら](/developers/tutorials/erc20-annotated-code)をご覧ください。 +この記事では[OpenZeppelin ERC-20トークンコントラクト](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20)を使用しますが、その詳細については説明しませんのでご注意ください。 この情報については、[こちら](/developers/tutorials/erc20-annotated-code)をご覧ください。 -全てのソースコードを表示したい場合は、次のようにします。 +完全なソースコードを確認したい場合は、以下を参照してください。 1. [Remix IDE](https://remix.ethereum.org/)を開きます。 -2. クローンGitHubアイコン (![clone github icon](icon-clone.png)) をクリックします。 +2. GitHubのクローンアイコン(![GitHubのクローンアイコン](icon-clone.png))をクリックします。 3. GitHubリポジトリ`https://github.com/qbzzt/20220815-erc20-safety-rails`をクローンします。 -4. 「**contracts > erc20-safety-rails.sol**」を開きます。 +4. **contracts > erc20-safety-rails.sol**を開きます。 ## ERC-20コントラクトの作成 {#creating-an-erc-20-contract} -安全策を講じるための機能を追加する前に、ERC-20コントラクトが必要になります。 この記事では、[OpenZeppelin Contracts Wizard](https://docs.openzeppelin.com/contracts/5.x/wizard)を使って加えます。 もう一つブラウザで開いて、次の手順に従ってください。 +安全策を講じるための機能を追加する前に、ERC-20コントラクトが必要になります。 この記事では、[OpenZeppelin Contracts Wizard](https://docs.openzeppelin.com/contracts/5.x/wizard)を使用します。 別のブラウザで開き、以下の手順に従ってください。 + +1. **ERC20**を選択します。 -1. **ERC20**を選びます。 2. 次の設定値を入力します。 | パラメータ | 値 | | -------------- | ---------------- | | 名前 | SafetyRailsToken | - | Symbol | SAFE | + | 記号 | SAFE | | Premint | 1000 | | 機能 | なし | | Access Control | Ownable | | Upgradability | なし | -3. 上にスクロールして (Remixを使う場合は) **Open in Remix**をクリックしてください。別の環境を使う場合は、**ダウンロード**をクリックしてください。 ここでは、Remixを使用していることとします。他の環境を使用する場合は、適宜変更してください。 -4. これで完全なERC-20コントラクトがあります。 「`.deps` > `npm`」でインポートしたコードを展開して確認できます。 -5. コントラクトをコンパイル、デプロイ、そして操作してERC-20 コントラクトとして機能していることを確認します。 Remixの使用方法を学びたいならば、[このチュートリアルが役立ちます](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth)。 +3. 上にスクロールして、(Remixの場合は) **Open in Remix** を、別の環境を使用する場合は **Download** をクリックします。 ここでは、Remixを使用していることとします。他の環境を使用する場合は、適宜変更してください。 + +4. これで完全に機能するERC-20コントラクトができました。 `.deps` > `npm` を展開すると、インポートされたコードを確認できます。 -## よくあるミス {#common-mistakes} +5. コントラクトをコンパイル、デプロイ、そして操作して、ERC-20コントラクトとして機能していることを確認します。 Remixの使い方を学ぶ必要がある場合は、[このチュートリアル](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth)を使用してください。 -### ミスのタイプ {#the-mistakes} +## よくある間違い {#common-mistakes} -ユーザーは、間違ったアドレスへトークンを送信してしまうことがあります。 なぜ間違って送ってしまった理由を知ることはできませんが、よく発生するミスのタイプで頻繁に検出できる次のものがあります。 +### 間違い {#the-mistakes} -1. トークンをコントラクト自身のアドレスに送信する。 例えば、[OptimismのOPトークン](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c)では、[12万](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000042#tokentxns)を超えるOPトークンが2か月もしないうちに累積していることがわかります。 これは、人々の膨大な資産がただ単に失われていることを表しています。 +ユーザーは、間違ったアドレスへトークンを送信してしまうことがあります。 ユーザーが何を意図していたかを知ることはできませんが、頻繁に発生し、かつ検出しやすいエラーには2つのタイプがあります。 -2. トークンを[外部所有アカウント](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs)や[スマートコントラクト](/developers/docs/smart-contracts)に相当しない空アドレスへ送信する。 このミスがどのくらいの頻度で発生するかについての統計はありません。[1件のインシデントで2千万トークンを失っているものもあります](https://gov.optimism.io/t/message-to-optimism-community-from-Wintermute/2595)。 +1. トークンをコントラクト自身のアドレスに送信する。 例えば、[OptimismのOPトークン](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c)は、2か月足らずで[120,000](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000042)以上のOPトークンを蓄積してしまいました。 これは、おそらく人々が失ってしまったであろう、かなりの額の資産に相当します。 -### 送金を防止する {#preventing-transfers} +2. トークンを空のアドレス、つまり[外部所有アカウント](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs)や[スマートコントラクト](/developers/docs/smart-contracts)ではないアドレスに送信してしまうこと。 これがどのくらいの頻度で発生するかについての統計はありませんが、[あるインシデントでは20,000,000トークンが失われる可能性がありました](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595)。 -OpenZeppelinのERC-20コントラクトには、[`_beforeTokenTransfer`というフック](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368)があり、トークンを送金する前に呼び出されます。 デフォルトでは、このフックは何も行いません。しかし、独自の機能をフックに掛けることで、問題がある場合に元に戻すなどのチェックが可能です。 +### 送金の防止 {#preventing-transfers} + +OpenZeppelinのERC-20コントラクトには、トークンが送金される前に呼び出される[`_beforeTokenTransfer`というフック](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368)が含まれています。 デフォルトでは、このフックは何も行いませんが、問題がある場合にトランザクションをリバートするチェックなど、独自の機能を実装するために利用できます。 このフックを使用するには、コンストラクタの後に次の関数を加えます。 @@ -67,42 +69,42 @@ OpenZeppelinのERC-20コントラクトには、[`_beforeTokenTransfer`という } ``` -Solidityにあまり詳しくない人ならば、次の関数の箇所は馴染みがないかもしれません。 +Solidityにあまり詳しくない方には、この関数の一部の要素は目新しいかもしれません。 ```solidity internal virtual ``` -上記の`virtual`キーワードでは、`ERC20`から機能を継承し、関数をオーバーライドして、他のコントラクトも同様にこのコントラクトの機能を継承して、この関数をオーバーライドできるようにしています。 +`virtual`キーワードは、私たちが`ERC20`から機能を継承してこの関数をオーバーライドしたのと同じように、他のコントラクトが私たちのコントラクトから継承してこの関数をオーバーライドできることを意味します。 ```solidity override(ERC20) ``` -ERC20トークンの`_beforeTokenTransfer`の定義を[オーバーライド](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding)することを明示的に指定しなければなりません。 一般的なセキュリティの観点において、暗黙的な定義よりも明示的な定義の方がはるかに良いとされています。記述されていれば、それが実行されることを忘れないからです。 オーバーライドするスーパークラスの `_beforeTokenTransfer`を指定しなければならないのも同様の理由です。 +`_beforeTokenTransfer`のERC20トークン定義を[オーバーライド](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding)していることを明示的に指定する必要があります。 一般的に、セキュリティの観点からは、暗黙的な定義よりも明示的な定義の方がはるかに優れています。目の前にあれば、何かをしたことを忘れることはありません。 これが、どのスーパークラスの`_beforeTokenTransfer`をオーバーライドしているかを指定する必要がある理由でもあります。 ```solidity super._beforeTokenTransfer(from, to, amount); ``` -上記は、継承しているコントラクトから継承元のコントラクトの `_beforeTokenTransfer`関数を呼び出しています。 この場合は、`ERC20`のみであり、`Ownable`にはこのフックがありません。 現時点では、`ERC20._beforeTokenTransfer`は何も行いません。コントラクトはデプロイ後に変更できないため、再デプロイによって将来に機能が追加された場合に備えて呼び出しています。 +この行は、継承元のコントラクトのうち、`_beforeTokenTransfer`関数を持つものの関数を呼び出します。 この場合、それは`ERC20`のみです。`Ownable`にはこのフックはありません。 現在`ERC20._beforeTokenTransfer`は何も行いませんが、将来機能が追加された場合に備えて呼び出します (コントラクトはデプロイ後に変更できないため、その場合はコントラクトを再デプロイすることになります)。 ### 要件のコーディング {#coding-the-requirements} -次の要件を関数に対して加えたいと思います。 +この関数に以下の要件を追加します。 -- `to`アドレスをERC-20コントラクト自体のアドレスである`address(this)`と等しくできないようにすること。 -- `to`アドレスを空にすることができないこと。また、次のいずれかであること。 - - 外部所有アカウント (EOA) 。 アドレスがEOAであるかどうかを直接確認することはできませんが、アドレスのETH残高を確認することはできます。 EOAは、たとえ使用されなくなったとしても、ほとんどの場合、残高が残っています。これは、最後のweiまで使うのは困難だからです。 - - スマートコントラクト。 アドレスがスマートコントラクトであるかどうかのテストは少し大変です。 [`EXTCODESIZE`](https://www.evm.codes/#3b)という外部コードの長さをチェックするオペコードがありますが、Solidityでは直接使用することはできません。 これには、[Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html)というEVMアセンブリを使う必要があります。 Solidityから使用できる他の値 ([ `
.code`および `
.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)) もありますが、コストがそれよりも高くなります。 +- `to`アドレスは、ERC-20コントラクト自体のアドレスである`address(this)`であってはならない。 +- `to`アドレスは空であってはならず、以下のいずれかでなければならない。 + - 外部所有アカウント (EOA)。 アドレスがEOAであるかどうかを直接確認することはできませんが、アドレスのETH残高は確認できます。 EOAは、使用されなくなった後でもほとんどの場合、残高が残っています。最後のweiまで使い切るのは困難だからです。 + - スマートコントラクト。 アドレスがスマートコントラクトであるかどうかのテストは、少し難しくなります。 外部コード長をチェックする[`EXTCODESIZE`](https://www.evm.codes/#3b)というオペコードがありますが、Solidityで直接利用することはできません。 そのためには、EVMアセンブリである[Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html)を使用する必要があります。 Solidityから使用できる他の値 ([`
.code` や `
.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)) もありますが、それらはより多くのコストがかかります。 -新しいコードを1行ずつ見てみましょう。 +新しいコードを1行ずつ見ていきましょう。 ```solidity - require(to != address(this), "Can't send tokens to the contract address"); + require(to != address(this), "コントラクトアドレスにトークンを送信することはできません"); ``` -これが最初の要件です。`to`と`this(address)`が等しくないことを確認しています。 +これが最初の要件で、`to`と`address(this)`が同じでないことを確認します。 ```solidity bool isToContract; @@ -111,53 +113,53 @@ ERC20トークンの`_beforeTokenTransfer`の定義を[オーバーライド](ht } ``` -上記は、アドレスがコントラクトかどうかを確認する方法です。 Yulから出力を直接受け取ることはできません。そのため、代わりに結果を保持する変数を定義しています (この場合は `isToContract`) 。 Yulでは、すべてのオペコードが関数として動作します。 したがって、最初に[`EXTCODESIZE`](https://www.evm.codes/#3b)を呼び出してコントラクトサイズを取得し、次に[`GT`](https://www.evm.codes/#11)でゼロでないことを確認します (符号なし整数を扱っているため、当然、負の値にすることはできません) 。 その後、結果を`isToContract`に書き込んでいます。 +このようにして、アドレスがコントラクトであるかどうかを確認します。 Yulから直接出力を受け取ることはできないので、代わりに結果を保持する変数(この場合は`isToContract`)を定義します。 Yulは、すべてのオペコードが関数としてみなされる仕組みになっています。 そこで、まず[`EXTCODESIZE`](https://www.evm.codes/#3b)を呼び出してコントラクトのサイズを取得し、次に[`GT`](https://www.evm.codes/#11)を使ってそれがゼロでないことを確認します(符号なし整数を扱っているので、もちろん負になることはありません)。 そして、その結果を`isToContract`に書き込みます。 ```solidity - require(to.balance != 0 || isToContract, "Can't send tokens to an empty address"); + require(to.balance != 0 || isToContract, "空のアドレスにトークンを送信することはできません"); ``` -最後に、空アドレスのチェックをしています。 +そして最後に、空のアドレスに対する実際のチェックを行います。 ## 管理者アクセス {#admin-access} -間違いを取り消せる管理者がいると、便利なことがあります。 悪用される可能性を減らすには、管理者を[マルチシグ](https://blog.logrocket.com/security-choices-multi-signature-wallets/)にして、各アクションに対する複数人の同意を必要にします。 この記事では、次の2つの管理機能を持つものとします。 +間違いを取り消せる管理者がいると、便利なことがあります。 悪用の可能性を減らすため、この管理者を[マルチシグ](https://blog.logrocket.com/security-choices-multi-signature-wallets/)にして、あるアクションに対して複数の人が合意しなければならないようにすることができます。 この記事では、2つの管理機能について説明します。 -1. アカウントの凍結と解凍。 これは、アカウントが侵害された可能性がある場合などに役立ちます。 +1. アカウントの凍結と凍結解除。 これは、例えば、アカウントが侵害された可能性がある場合に便利です。 2. アセットのクリーンアップ。 - 時には、詐欺師が正当であると思わせるために、本物のトークンコントラクトに偽物のトークンを送信することがあります。 [こちら](https://optimistic.etherscan.io/token/0x2348b1a1228ddcd2db668c3d30207c3e1852fbbe?a=0x4200000000000000000000000000000000000042)に、その例があります。 正当なERC-20コントラクトは、[0x4200....0042](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000042)です。 装っているスキャムは、[0x234....bbe](https://optimistic.etherscan.io/address/0x2348b1a1228ddcd2db668c3d30207c3e1852fbbe)です。 + 詐欺師が正当性を装うために、本物のトークンコントラクトに偽のトークンを送ることがあります。 例えば、[こちら](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe?tab=holders)をご覧ください。 正規のERC-20コントラクトは [0x4200....0042](https://optimism.blockscout.com/token/0x4200000000000000000000000000000000000042) です。 それになりすました詐欺コントラクトは [0x234....bbe](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe) です。 - また、正当なERC-20トークンを誤ってコントラクト自体に送信してしまう可能性もあります。これが、アセットのクリーンアップ方法が必要になるもう1つの理由です。 + また、ユーザーが正規のERC-20トークンを誤って私たちのコントラクトに送ってしまう可能性もあります。これも、それらを取り出す方法が必要となるもう一つの理由です。 -OpenZeppelinでは、管理者アクセスを可能にする次の2つのメカニズムを提供しています。 +OpenZeppelinは、管理者アクセスを可能にする2つのメカニズムを提供しています。 -- [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable)コントラクトでは、所有者は1人です。 `onlyOwner` [modifier](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm)のある関数は、その所有者のみしか呼び出せません。 所有者は、所有権を他の人に譲渡することも、完全に放棄することもできます。 通常、それ以外のアカウントの権限は変わりません。 -- [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control)コントラクトでは、[ロールベースのアクセス制御 (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control)機能があります。 +- [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable)コントラクトには、単一の所有者がいます。 `onlyOwner` [修飾子](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm)を持つ関数は、その所有者のみが呼び出すことができます。 所有者は、所有権を他の誰かに譲渡したり、完全に放棄したりすることができます。 他のすべてのアカウントの権限は、通常は同一です。 +- [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control)コントラクトには、[ロールベースのアクセス制御(RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control)があります。 -この記事では、簡潔にするために`Ownable`を使っています。 +この記事では、簡潔にするために`Ownable`を使用します。 -### コントラクトの凍結および解凍 {#freezing-and-thawing-contracts} +### コントラクトの凍結と凍結解除 {#freezing-and-thawing-contracts} -コントラクトの凍結と解凍において、次のいくつかの変更が必要になります。 +コントラクトの凍結と凍結解除には、いくつかの変更が必要です。 -- どのアドレスが凍結されているかを追跡するために、アドレスを[ブール値](https://en.wikipedia.org/wiki/Boolean_data_type)で[マッピング](https://www.tutorialspoint.com/solidity/solidity_mappings.htm)します。 すべての値の初期値はゼロです。これは、ブール値でfalseとして解釈されます。 デフォルトでは、アカウントを凍結しないため、このようにしています。 +- どのアドレスが凍結されているかを追跡するための、アドレスから[ブール値](https://en.wikipedia.org/wiki/Boolean_data_type)への[マッピング](https://www.tutorialspoint.com/solidity/solidity_mappings.htm)。 すべての値は最初はゼロで、ブール値の場合はfalseと解釈されます。 デフォルトではアカウントは凍結されていないので、これは望ましい動作です。 ```solidity mapping(address => bool) public frozenAccounts; ``` -- アカウントが凍結または解除されたときに、関係者に対して[イベント](https://www.tutorialspoint.com/solidity/solidity_events.htm)で通知します。 技術的観点では、アカウントの凍結および解除におけるアクションでは、イベントは必要ありません。しかし、オフチェーンのコードで、これらのイベントをリッスンして何が起こっているかわかると便利です。 関係者に対して何かが発生したときに、スマートコントラクトでイベントを発行することは、良いマナーであるとされています。 +- アカウントが凍結または凍結解除されたときに関係者に通知するための[イベント](https://www.tutorialspoint.com/solidity/solidity_events.htm)。 技術的には、これらのアクションにイベントは必須ではありませんが、オフチェーンのコードがこれらのイベントをリッスンして何が起こっているかを知るのに役立ちます。 他の誰かに関連する可能性のあることが起こったときに、スマートコントラクトがイベントを発行することは、良いマナーとされています。 - どのタイミングでアカウントの凍結または解除されたかを検索できるように、イベントにインデックスを付けています。 + イベントにはインデックスが付けられるため、あるアカウントが凍結または凍結解除されたすべての回を検索できるようになります。 ```solidity - // When accounts are frozen or unfrozen + // アカウントが凍結または凍結解除されたとき event AccountFrozen(address indexed _addr); event AccountThawed(address indexed _addr); ``` -- アカウントを凍結および解凍するための関数。 これらの2つの関数は、ほぼ同一であるため凍結する関数についてのみ説明します。 +- アカウントを凍結および凍結解除するための関数。 これらの2つの関数はほぼ同一なので、ここでは凍結関数についてのみ説明します。 ```solidity function freezeAccount(address addr) @@ -165,27 +167,27 @@ OpenZeppelinでは、管理者アクセスを可能にする次の2つのメカ onlyOwner ``` - [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm)が付けられた関数では、他のスマートコントラクトまたはトランザクションから直接呼び出すことができます。 + [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm)とマークされた関数は、他のスマートコントラクトから、またはトランザクションによって直接呼び出すことができます。 ```solidity { - require(!frozenAccounts[addr], "Account already frozen"); + require(!frozenAccounts[addr], "アカウントはすでに凍結されています"); frozenAccounts[addr] = true; emit AccountFrozen(addr); } // freezeAccount ``` - アカウントがすでに凍結されている場合は、処理を取消します。 それ以外の場合は、凍結してイベントを`emit`します。 + アカウントがすでに凍結されている場合は、リバートします。 そうでなければ、アカウントを凍結し、イベントを`emit`します。 -- `_beforeTokenTransfer`を凍結されたアカウントから資金が移動されないよう変更します。 凍結されたアカウントへの送金は、引き続き可能であることに注意してください。 +- 凍結されたアカウントから資金が移動されないように`_beforeTokenTransfer`を変更します。 凍結されたアカウントへの送金は、引き続き可能であることに注意してください。 ```solidity - require(!frozenAccounts[from], "The account is frozen"); + require(!frozenAccounts[from], "アカウントは凍結されています"); ``` ### アセットのクリーンアップ {#asset-cleanup} -コントラクト自体が保持しているERC-20トークンを解放するには、それに属しているトークンコントラクトの関数である[`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer)または[`approve`](https://eips.ethereum.org/EIPS/eip-20#approve)を呼び出す必要があります。 この場合、Allowanceで無駄にガスを消費するのはもったいないため、直接送金 (transfer) の方がよいでしょう。 +このコントラクトが保有するERC-20トークンを解放するには、それらが属するトークンコントラクトの[`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer)または[`approve`](https://eips.ethereum.org/EIPS/eip-20#approve)のいずれかの関数を呼び出す必要があります。 この場合、Allowanceでガスを無駄にする意味はないので、直接送金した方が良いでしょう。 ```solidity function cleanupERC20( @@ -198,7 +200,7 @@ OpenZeppelinでは、管理者アクセスを可能にする次の2つのメカ IERC20 token = IERC20(erc20); ``` -これは、アドレスがトークンを受け取った場合に、コントラクトにオブジェクトを作成するための構文です。 ERC20トークンがソースコード (4行目を参照) の一部として定義されており、OpenZeppelinのERC-20コントラクトのインターフェースである[IERC20の定義](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)がそのファイルに含まれているためこれが可能です。 +これは、アドレスを受け取ったときにコントラクトのオブジェクトを作成するための構文です。 これが可能なのは、ソースコードの一部としてERC20トークンの定義があり(4行目を参照)、そのファイルにはOpenZeppelinのERC-20コントラクトのインターフェースである[IERC20の定義](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)が含まれているためです。 ```solidity uint balance = token.balanceOf(address(this)); @@ -206,8 +208,10 @@ OpenZeppelinでは、管理者アクセスを可能にする次の2つのメカ } ``` -上記は、すべてのトークンをクリーンアップする関数です。 このプロセスを自動化することで、ユーザーから手動で残高を取得するよりも効率化できます。 +これはクリーンアップ関数なので、トークンを残さないようにします。 ユーザーから手動で残高を取得する代わりに、プロセスを自動化した方が良いでしょう。 + +## 結論 {#conclusion} -## まとめ {#conclusion} +これは完璧な解決策ではありません。「ユーザーの間違い」によって発生する問題に完璧な解決策はないのです。 しかし、この種のチェックを使用することで、少なくともいくつかの間違いを防ぐことができます。 アカウントを凍結する機能は危険を伴いますが、ハッカーから盗まれた資金を奪うことで、特定のハッキングによる被害を限定するために使用できます。 -「ユーザーの間違い」によって発生する問題に完璧な解決策はないため、これらは完全な解決策ではありません。 しかしながら、この記事のようなチェックをすることで、少なくともいくつかのミスを防止できます。 アカウントの凍結機能は危険を伴うものの、ハッカーが資金を盗むことを防ぎ、ハッキングによる被害を特定の範囲内におさめるために使うことができます。 +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/ethereum-for-web2-auth/index.md b/public/content/translations/ja/developers/tutorials/ethereum-for-web2-auth/index.md new file mode 100644 index 00000000000..d5bb7ed4da2 --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/ethereum-for-web2-auth/index.md @@ -0,0 +1,886 @@ +--- +title: "Web2認証にイーサリアムを使用する" +description: "このチュートリアルを読むことで、デベロッパーはイーサリアムログイン (Web3) をSAMLログインと統合できるようになります。SAMLは、Web2でシングルサインオンやその他の関連サービスを提供するために使用される標準です。 これにより、Web2リソースへのアクセスをイーサリアム署名を通じて認証できるようになり、ユーザー属性はアテステーションから取得されます。" +author: Ori Pomerantz +tags: [ "web2", "認証", "eas" ] +skill: beginner +lang: ja +published: 2025-04-30 +--- + +## はじめに + +[SAML](https://www.onelogin.com/learn/saml)は、Web2で[IDプロバイダー (IdP)](https://en.wikipedia.org/wiki/Identity_provider#SAML_identity_provider) が[サービスプロバイダー (SP)](https://en.wikipedia.org/wiki/Service_provider_\(SAML\))にユーザー情報を提供するために使用される標準です。 + +このチュートリアルでは、イーサリアム署名をSAMLと統合し、まだイーサリアムをネイティブにサポートしていないWeb2サービスに対して、ユーザーがイーサリアムウォレットを使用して認証できるようにする方法を学びます。 + +このチュートリアルは、2つの異なる読者を対象に書かれていることに注意してください。 + +- イーサリアムを理解していて、SAMLを学ぶ必要があるイーサリアム関係者 +- SAMLとWeb2認証を理解していて、イーサリアムを学ぶ必要があるWeb2関係者 + +そのため、すでにご存知の入門的な内容が多く含まれています。 適宜読み飛ばしてください。 + +### イーサリアム関係者向けのSAML + +SAMLは中央集権型のプロトコルです。 サービスプロバイダー (SP) は、IDプロバイダー (IdP) との間、またはそのIdPの証明書に署名した[証明書認証局](https://www.ssl.com/article/what-is-a-certificate-authority-ca/)との間に、既存の信頼関係がある場合にのみ、IdPからのアサーション (「これは私のユーザーJohnで、A、B、Cを行う権限を持つべきである」など) を受け入れます。 + +たとえば、SPは企業に旅行サービスを提供する旅行代理店、IdPは企業の社内ウェブサイトであるとします。 従業員が出張の予約をする際、旅行代理店は、実際に旅行の予約を許可する前に、従業員を会社の認証に送ります。 + +![SAMLプロセスのステップバイステップ](./fig-01-saml.png) + +これが、ブラウザ、SP、IdPの3つのエンティティがアクセスを交渉する方法です。 SPは、ブラウザを使用しているユーザーについて事前に何も知る必要はなく、IdPを信頼するだけで済みます。 + +### SAML関係者向けのイーサリアム + +イーサリアムは分散型システムです。 + +![イーサリアムのログオン](./fig-02-eth-logon.png) + +ユーザーは秘密鍵を持っています (通常はブラウザ拡張機能に保存されています)。 秘密鍵から公開鍵を導出し、そこから20バイトのアドレスを導出できます。 ユーザーがシステムにログインする必要がある場合、ノンス (1回限りの値) を持つメッセージに署名するよう要求されます。 サーバーは、署名がそのアドレスによって作成されたことを検証できます。 + +![アテステーションから追加データを取得](./fig-03-eas-data.png) + +署名はイーサリアムアドレスを検証するだけです。 他のユーザー属性を取得するには、通常[アテステーション](https://attest.org/)を使用します。 アテステーションには通常、以下のフィールドがあります。 + +- **証明者**、アテステーションを行ったアドレス +- **受取人**、アテステーションが適用されるアドレス +- **データ**、名前や権限など、証明されるデータ +- **スキーマ**、データの解釈に使用されるスキーマのID。 + +イーサリアムの分散型の性質により、どのユーザーでもアテステーションを作成できます。 どのアテステーションが信頼できるかを判断するには、証明者のIDが重要です。 + +## セットアップ + +最初のステップは、SAML SPとSAML IdPが互いに通信できるようにすることです。 + +1. ソフトウェアをダウンロードします。 この記事のサンプルソフトウェアは、[github](https://github.com/qbzzt/250420-saml-ethereum)にあります。 異なるステージは異なるブランチに保存されています。このステージでは `saml-only` を使用します。 + + ```sh + git clone https://github.com/qbzzt/250420-saml-ethereum -b saml-only + cd 250420-saml-ethereum + pnpm install + ``` + +2. 自己署名証明書でキーを作成します。 これは、キーがそれ自体の証明書認証局であることを意味し、サービスプロバイダーに手動でインポートする必要があります。 詳細については、[OpenSSLのドキュメント](https://docs.openssl.org/master/man1/openssl-req/)を参照してください。 + + ```sh + mkdir keys + cd keys + openssl req -new -x509 -days 365 -nodes -sha256 -out saml-sp.crt -keyout saml-sp.pem -subj /CN=sp/ + openssl req -new -x509 -days 365 -nodes -sha256 -out saml-idp.crt -keyout saml-idp.pem -subj /CN=idp/ + cd .. + ``` + +3. サーバー (SPとIdPの両方) を起動します。 + + ```sh + pnpm start + ``` + +4. URL [http://localhost:3000/](http://localhost:3000/)でSPにアクセスし、ボタンをクリックしてIdP (ポート3001) にリダイレクトします。 + +5. IdPにメールアドレスを入力し、**サービスプロバイダーにログイン**をクリックします。 サービスプロバイダー (ポート3000) にリダイレクトされ、メールアドレスで認識されていることを確認します。 + +### 詳細な説明 + +ステップバイステップで起こることは次のとおりです。 + +![イーサリアムを使用しない通常のSAMLログオン](./fig-04-saml-no-eth.png) + +#### src/config.mts + +このファイルには、IDプロバイダーとサービスプロバイダー両方の設定が含まれています。 通常、これら2つは異なるエンティティですが、ここでは簡潔にするためにコードを共有します。 + +```typescript +const fs = await import("fs") + +const protocol="http" +``` + +今のところテストだけなので、HTTPを使用して問題ありません。 + +```typescript +export const spCert = fs.readFileSync("keys/saml-sp.crt").toString() +export const idpCert = fs.readFileSync("keys/saml-idp.crt").toString() +``` + +通常は両方のコンポーネントで利用可能な公開鍵 (直接信頼されるか、信頼された証明書認証局によって署名される) を読み取ります。 + +```typescript +export const spPort = 3000 +export const spHostname = "localhost" +export const spDir = "sp" + +export const idpPort = 3001 +export const idpHostname = "localhost" +export const idpDir = "idp" + +export const spUrl = `${protocol}://${spHostname}:${spPort}/${spDir}` +export const idpUrl = `${protocol}://${idpHostname}:${idpPort}/${idpDir}` +``` + +両コンポーネントのURLです。 + +```typescript +export const spPublicData = { +``` + +サービスプロバイダーの公開データです。 + +```typescript + entityID: `${spUrl}/metadata`, +``` + +慣例的に、SAMLでは`entityID`はエンティティのメタデータが利用可能なURLです。 このメタデータはここの公開データに対応しますが、XML形式である点が異なります。 + +```typescript + wantAssertionsSigned: true, + authnRequestsSigned: false, + signingCert: spCert, + allowCreate: true, + assertionConsumerService: [{ + Binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST', + Location: `${spUrl}/assertion`, + }] + } +``` + +私たちの目的にとって最も重要な定義は `assertionConsumerServer` です。 これは、サービスプロバイダーに何かをアサートする (例えば、「この情報を送信するユーザーは somebody@example.com です」) ためには、URL `http://localhost:3000/sp/assertion` に [HTTP POST](https://www.w3schools.com/tags/ref_httpmethods.asp) を使用する必要があることを意味します。 + +```typescript +export const idpPublicData = { + entityID: `${idpUrl}/metadata`, + signingCert: idpCert, + wantAuthnRequestsSigned: false, + singleSignOnService: [{ + Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST", + Location: `${idpUrl}/login` + }], + singleLogoutService: [{ + Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST", + Location: `${idpUrl}/logout` + }], + } +``` + +IDプロバイダーの公開データも同様です。 これは、ユーザーをログインさせるには `http://localhost:3001/idp/login` にPOSTし、ユーザーをログアウトさせるには `http://localhost:3001/idp/logout` にPOSTすることを指定しています。 + +#### src/sp.mts + +これはサービスプロバイダーを実装するコードです。 + +```typescript +import * as config from "./config.mts" +const fs = await import("fs") +const saml = await import("samlify") +``` + +SAMLを実装するために [`samlify`](https://www.npmjs.com/package/samlify) ライブラリを使用します。 + +```typescript +import * as validator from "@authenio/samlify-node-xmllint" +saml.setSchemaValidator(validator) +``` + +`samlify` ライブラリは、XMLが正しいこと、期待される公開鍵で署名されていることなどを検証するパッケージを必要とします。 この目的のために [`@authenio/samlify-node-xmllint`](https://www.npmjs.com/package/@authenio/samlify-node-xmllint) を使用します。 + +```typescript +const express = (await import("express")).default +const spRouter = express.Router() +const app = express() +``` + +[`express`](https://expressjs.com/)の [`Router`](https://expressjs.com/en/5x/api.html#router)は、ウェブサイト内にマウントできる「ミニウェブサイト」です。 この場合、すべてのサービスプロバイダーの定義をグループ化するために使用します。 + +```typescript +const spPrivateKey = fs.readFileSync("keys/saml-sp.pem").toString() + +const sp = saml.ServiceProvider({ + privateKey: spPrivateKey, + ...config.spPublicData +}) +``` + +サービスプロバイダー自身の表現は、すべての公開データと、情報に署名するために使用する秘密鍵です。 + +```typescript +const idp = saml.IdentityProvider(config.idpPublicData); +``` + +公開データには、サービスプロバイダーがIDプロバイダーについて知る必要があるすべてのものが含まれています。 + +```typescript +spRouter.get(`/metadata`, + (req, res) => res.header("Content-Type", "text/xml").send(sp.getMetadata()) +) +``` + +他のSAMLコンポーネントとの相互運用性を確保するため、サービスプロバイダーとIDプロバイダーは、公開データ (メタデータと呼ばれる) をXML形式で `/metadata` にて利用可能にする必要があります。 + +```typescript +spRouter.post(`/assertion`, +``` + +これは、ブラウザが自身を識別するためにアクセスするページです。 アサーションにはユーザー識別子 (ここではメールアドレスを使用) が含まれ、追加の属性を含めることもできます。 これは、上記のシーケンス図のステップ7のハンドラです。 + +```typescript + async (req, res) => { + // console.log(`SAML response:\n${Buffer.from(req.body.SAMLResponse, 'base64').toString('utf-8')}`) +``` + +コメントアウトされたコマンドを使用して、アサーションで提供されるXMLデータを確認できます。 これは[base64でエンコード](https://en.wikipedia.org/wiki/Base64)されています。 + +```typescript + try { + const loginResponse = await sp.parseLoginResponse(idp, 'post', req); +``` + +IDサーバーからのログインリクエストを解析します。 + +```typescript + res.send(` + + +

Hello ${loginResponse.extract.nameID}

+ + + `) + res.send(); +``` + +ユーザーにログインが成功したことを示すために、HTMLレスポンスを送信します。 + +```typescript + } catch (err) { + console.error('Error processing SAML response:', err); + res.status(400).send('SAML authentication failed'); + } + } +) +``` + +失敗した場合は、ユーザーに通知します。 + +```typescript +spRouter.get('/login', +``` + +ブラウザがこのページを取得しようとするときに、ログインリクエストを作成します。 これは、上記のシーケンス図のステップ1のハンドラです。 + +```typescript + async (req, res) => { + const loginRequest = await sp.createLoginRequest(idp, "post") +``` + +ログインリクエストをPOSTするための情報を取得します。 + +```typescript + res.send(` + + + +``` + +このページは、フォーム (下記参照) を自動的に送信します。 これにより、ユーザーはリダイレクトされるために何もする必要がありません。 これは、上記のシーケンス図のステップ2です。 + +```typescript +
+``` + +`loginRequest.entityEndpoint` (IDプロバイダーエンドポイントのURL) にPOSTします。 + +```typescript + +``` + +入力名は `loginRequest.type` (`SAMLRequest`) です。 そのフィールドのコンテンツは `loginRequest.context` で、これもbase64エンコードされたXMLです。 + +```typescript +
+ + + `) + } +) + +app.use(express.urlencoded({extended: true})) +``` + +[このミドルウェア](https://expressjs.com/en/5x/api.html#express.urlencoded) は [HTTPリクエスト](https://www.tutorialspoint.com/http/http_requests.htm)のボディを読み取ります。 ほとんどのリクエストはそれを必要としないため、Expressはデフォルトでそれを無視します。 POSTはボディを使用するため、これが必要です。 + +```typescript +app.use(`/${config.spDir}`, spRouter) +``` + +サービスプロバイダーディレクトリ (`/sp`) にルーターをマウントします。 + +```typescript +app.get("/", (req, res) => { + res.send(` + + + + + + `) +}) +``` + +ブラウザがルートディレクトリを取得しようとした場合は、ログインページへのリンクを提供します。 + +```typescript +app.listen(config.spPort, () => { + console.log(`service provider is running on http://${config.spHostname}:${config.spPort}`) +}) +``` + +このExpressアプリケーションで `spPort` をリッスンします。 + +#### src/idp.mts + +これはIDプロバイダーです。 これはサービスプロバイダーと非常によく似ており、以下の説明は異なる部分についてです。 + +```typescript +const xmlParser = new (await import("fast-xml-parser")).XMLParser( + { + ignoreAttributes: false, // Preserve attributes + attributeNamePrefix: "@_", // Prefix for attributes + } +) +``` + +サービスプロバイダーから受け取ったXMLリクエストを読み取り、理解する必要があります。 + +```typescript +const getLoginPage = requestId => ` +``` + +この関数は、上記のシーケンス図のステップ4で返される、自動送信フォーム付きのページを作成します。 + +```typescript + + + ログインページ + + +

ログインページ

+
+ + メールアドレス: +
+ +``` + +サービスプロバイダーに送信するフィールドは2つあります。 + +1. 応答する `requestId`。 +2. ユーザー識別子 (ここではユーザーが提供するメールアドレスを使用)。 + +```typescript +
+ + + +const idpRouter = express.Router() + +idpRouter.post("/loginSubmitted", async (req, res) => { + const loginResponse = await idp.createLoginResponse( +``` + +これは、上記のシーケンス図のステップ5のハンドラです。 [`idp.createLoginResponse`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L73-L125)はログインレスポンスを作成します。 + +```typescript + sp, + { + authnContextClassRef: 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport', + audience: sp.entityID, +``` + +オーディエンスはサービスプロバイダーです。 + +```typescript + extract: { + request: { + id: req.body.requestId + } + }, +``` + +リクエストから抽出された情報です。 リクエストで重要なパラメータはrequestIdで、これによりサービスプロバイダーはリクエストとそのレスポンスを一致させることができます。 + +```typescript + signingKey: { privateKey: idpPrivateKey, publicKey: config.idpCert } // Ensure signing +``` + +レスポンスに署名するためのデータを持つために `signingKey` が必要です。 サービスプロバイダーは署名されていないリクエストを信頼しません。 + +```typescript + }, + "post", + { + email: req.body.email +``` + +これは、サービスプロバイダーに送り返すユーザー情報を持つフィールドです。 + +```typescript + } + ); + + res.send(` + + + + +
+ +
+ + + `) +}) +``` + +ここでも、自動送信フォームを使用します。 これは、上記のシーケンス図のステップ6です。 + +```typescript + +// ログインリクエスト用のIdPエンドポイント +idpRouter.post(`/login`, +``` + +これはサービスプロバイダーからログインリクエストを受け取るエンドポイントです。 これは、上記のシーケンス図のステップ3のハンドラです。 + +```typescript + async (req, res) => { + try { + // parseLoginRequestが動作しなかったための回避策 + // const loginRequest = await idp.parseLoginRequest(sp, 'post', req) + const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8')) + res.send(getLoginPage(samlRequest["samlp:AuthnRequest"]["@_ID"])) +``` + +[`idp.parseLoginRequest`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L127-L144)を使用して認証リクエストのIDを読み取ることができるはずです。 しかし、動作させることができず、それに多くの時間を費やす価値もなかったので、[汎用XMLパーサー](https://www.npmjs.com/package/fast-xml-parser)を使用します。 必要な情報は、XMLのトップレベルにある `` タグ内の `ID` 属性です。 + +## イーサリアム署名の使用 + +ユーザーIDをサービスプロバイダーに送信できるようになったので、次のステップは信頼できる方法でユーザーIDを取得することです。 Viemを使用すると、ウォレットにユーザーアドレスを尋ねるだけで済みますが、これはブラウザに情報を要求することを意味します。 私たちはブラウザを制御していないため、そこから得られる応答を自動的に信頼することはできません。 + +代わりに、IdPはブラウザに署名するための文字列を送信します。 ブラウザのウォレットがこの文字列に署名すれば、それが本当にそのアドレスであること (つまり、そのアドレスに対応する秘密鍵を知っていること) を意味します。 + +これを実際に確認するには、既存のIdPとSPを停止し、次のコマンドを実行します。 + +```sh +git checkout eth-signatures +pnpm install +pnpm start +``` + +次に、[SP](http://localhost:3000)にアクセスし、指示に従ってください。 + +この時点では、イーサリアムアドレスからメールアドレスを取得する方法がわからないため、代わりに `<イーサリアムアドレス>@bad.email.address` をSPに報告します。 + +### 詳細な説明 + +変更点は、前の図のステップ4-5にあります。 + +![イーサリアム署名付きSAML](./fig-05-saml-w-signature.png) + +変更したファイルは `idp.mts` だけです。 以下が変更された部分です。 + +```typescript +import { v4 as uuidv4 } from 'uuid' +import { verifyMessage } from 'viem' +``` + +これら2つの追加ライブラリが必要です。 [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce)値を作成するために [`uuid`](https://www.npmjs.com/package/uuid) を使用します。 値自体は問題ではなく、一度しか使用されないという事実が重要です。 + +[`viem`](https://viem.sh/) ライブラリを使用すると、イーサリアムの定義を使用できます。 ここでは、署名が実際に有効であることを検証するためにこれが必要です。 + +```typescript +const loginPrompt = "サービスプロバイダーにアクセスするには、このノンスに署名してください: " +``` + +ウォレットは、ユーザーにメッセージに署名する許可を求めます。 ノンスだけのメッセージはユーザーを混乱させる可能性があるため、このプロンプトを含めます。 + +```typescript +// ここにrequestIDを保持する +let nonces = {} +``` + +応答するためには、リクエスト情報が必要です。 リクエストと一緒に送信し (ステップ4)、それを受け取る (ステップ5) こともできます。 しかし、潜在的に敵対的なユーザーの制御下にあるブラウザから得られる情報は信頼できません。 したがって、ノンスをキーとしてここに保存する方が良いでしょう。 + +簡潔さのために、ここでは変数としてこれを行っていることに注意してください。 ただし、これにはいくつかの欠点があります。 + +- サービス拒否攻撃に対して脆弱です。 悪意のあるユーザーが複数回ログオンを試み、メモリを使い果たす可能性があります。 +- IdPプロセスを再起動する必要がある場合、既存の値を失います。 +- 各プロセスが独自の変数を持つため、複数のプロセス間で負荷分散を行うことはできません。 + +本番システムでは、データベースを使用し、何らかの有効期限メカニズムを実装します。 + +```typescript +const getSignaturePage = requestId => { + const nonce = uuidv4() + nonces[nonce] = requestId +``` + +ノンスを作成し、後で使用するために `requestId` を保存します。 + +```typescript + return ` + + + + + +

署名してください

+ +
+ + + +` +} +``` + +残りは標準のHTMLです。 + +```typescript +idpRouter.get("/signature/:nonce/:account/:signature", async (req, res) => { +``` + +これはシーケンス図のステップ5のハンドラです。 + +```typescript + const requestId = nonces[req.params.nonce] + if (requestId === undefined) { + res.send("Bad nonce") + return ; + } + + nonces[req.params.nonce] = undefined +``` + +リクエストIDを取得し、再利用されないように `nonces` からノンスを削除します。 + +```typescript + try { +``` + +署名が無効になる方法が非常に多いため、これを `try ...` でラップします。 catch`ブロックで、スローされたエラーをキャッチします。 + +```typescript + const validSignature = await verifyMessage({ + address: req.params.account, + message: `${loginPrompt}${req.params.nonce}`, + signature: req.params.signature + }) +``` + +シーケンス図のステップ5.5を実装するには、[`verifyMessage`](https://viem.sh/docs/actions/public/verifyMessage#verifymessage) を使用します。 + +```typescript + if (!validSignature) + throw("Bad signature") + } catch (err) { + res.send("Error:" + err) + return ; + } +``` + +ハンドラの残りの部分は、1つの小さな変更を除いて、以前に `/loginSubmitted` ハンドラで行ったことと同等です。 + +```typescript + const loginResponse = await idp.createLoginResponse( + . + . + . + { + email: req.params.account + "@bad.email.address" + } + ); +``` + +実際のメールアドレスは持っていないので (次のセクションで取得します)、今のところはイーサリアムアドレスを返し、それがメールアドレスではないことを明確にマークします。 + +```typescript +// ログインリクエスト用のIdPエンドポイント +idpRouter.post(`/login`, + async (req, res) => { + try { + // parseLoginRequestが動作しなかったための回避策 + // const loginRequest = await idp.parseLoginRequest(sp, 'post', req) + const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8')) + res.send(getSignaturePage(samlRequest["samlp:AuthnRequest"]["@_ID"])) + } catch (err) { + console.error('SAMLレスポンスの処理中にエラーが発生しました:', err); + res.status(400).send('SAML認証に失敗しました'); + } + } +) +``` + +ステップ3のハンドラでは、`getLoginPage` の代わりに `getSignaturePage` を使用します。 + +## メールアドレスの取得 + +次のステップは、サービスプロバイダーによって要求された識別子であるメールアドレスを取得することです。 そのためには、[Ethereum Attestation Service (EAS)](https://attest.org/) を使用します。 + +アテステーションを取得する最も簡単な方法は、[GraphQL API](https://docs.attest.org/docs/developer-tools/api)を使用することです。 このクエリを使用します。 + +``` +query GetAttestationsByRecipient { + attestations( + where: { + recipient: { equals: "${getAddress(ethAddr)}" } + schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" } + } + take: 1 + ) { + data + id + attester + } +} +``` + +この[`schemaId`](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977)には、メールアドレスのみが含まれます。 このクエリは、このスキーマのアテステーションを要求します。 アテステーションのサブジェクトは `recipient` と呼ばれます。 これは常にイーサリアムアドレスです。 + +警告：ここでアテステーションを取得する方法には、2つのセキュリティ上の問題があります。 + +- 中央集権的なコンポーネントであるAPIエンドポイント `https://optimism.easscan.org/graphql` にアクセスしています。 `id`属性を取得し、オンチェーンでルックアップしてアテステーションが本物であることを確認できますが、APIエンドポイントは、アテステーションについて通知しないことで、依然としてアテステーションを検閲できます。 + + この問題は解決不可能ではありません。独自のGraphQLエンドポイントを実行し、チェーンログからアテステーションを取得できますが、私たちの目的には過剰です。 + +- 私たちは証明者のIDを見ていません。 誰でも偽の情報を私たちに与えることができます。 実際の環境では、信頼できる証明者のセットを持ち、彼らのアテステーションのみを参照します。 + +これを実際に確認するには、既存のIdPとSPを停止し、次のコマンドを実行します。 + +```sh +git checkout email-address +pnpm install +pnpm start +``` + +次に、メールアドレスを入力します。 これを行うには2つの方法があります。 + +- 秘密鍵を使用してウォレットをインポートし、テスト用の秘密鍵 `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80` を使用します。 + +- 自分のメールアドレスにアテステーションを追加します。 + + 1. アテステーションエクスプローラーの[スキーマ](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977)に移動します。 + + 2. **スキーマで証明**をクリックします。 + + 3. 受信者としてイーサリアムアドレスを入力し、メールアドレスとしてメールアドレスを入力し、**オンチェーン**を選択します。 次に、**アテステーションを作成**をクリックします。 + + 4. ウォレットでトランザクションを承認します。 ガスを支払うために、[Optimism Blockchain](https://app.optimism.io/bridge/deposit)にETHが必要です。 + +どちらの場合も、これを行った後、[http://localhost:3000](http://localhost:3000) にアクセスして指示に従ってください。 テスト用の秘密鍵をインポートした場合、受け取るメールは `test_addr_0@example.com` です。 独自のアドレスを使用した場合は、証明した内容になります。 + +### 詳細な説明 + +![イーサリアムアドレスからメールアドレスへの変換](./fig-06-saml-sig-n-email.png) + +新しいステップはGraphQL通信、ステップ5.6と5.7です。 + +再度、`idp.mts`の変更部分を示します。 + +```typescript +import { GraphQLClient } from 'graphql-request' +import { SchemaEncoder } from '@ethereum-attestation-service/eas-sdk' +``` + +必要なライブラリをインポートします。 + +```typescript +const graphqlEndpointUrl = "https://optimism.easscan.org/graphql" +``` + +[各ブロックチェーンに個別のエンドポイント](https://docs.attest.org/docs/developer-tools/api)があります。 + +```typescript +const graphqlClient = new GraphQLClient(graphqlEndpointUrl, { fetch }) +``` + +エンドポイントのクエリに使用できる新しい`GraphQLClient`クライアントを作成します。 + +```typescript +const graphqlSchema = 'string emailAddress' +const graphqlEncoder = new SchemaEncoder(graphqlSchema) +``` + +GraphQLは、バイトを持つ不透明なデータオブジェクトのみを提供します。 それを理解するためにはスキーマが必要です。 + +```typescript +const ethereumAddressToEmail = async ethAddr => { +``` + +イーサリアムアドレスからメールアドレスを取得する関数です。 + +```typescript + const query = ` + query GetAttestationsByRecipient { +``` + +これはGraphQLクエリです。 + +```typescript + アテステーション( +``` + +アテステーションを探しています。 + +```typescript + where: { + recipient: { equals: "${getAddress(ethAddr)}" } + schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" } + } +``` + +必要なアテステーションは、私たちのスキーマにあり、受信者が`getAddress(ethAddr)`であるものです。 [`getAddress`](https://viem.sh/docs/utilities/getAddress#getaddress)関数は、アドレスが正しい[チェックサム](https://github.com/ethereum/ercs/blob/master/ERCS/erc-55.md)を持つことを保証します。 GraphQLは大文字と小文字を区別するため、これは必要です。 「0xBAD060A7」、「0xBad060A7」、および「0xbad060a7」は異なる値です。 + +```typescript + take: 1 +``` + +見つかったアテステーションの数に関係なく、最初のものだけが必要です。 + +```typescript + ) { + data + id + attester + } + }` +``` + +受け取りたいフィールドです。 + +- `attester`: アテステーションを送信したアドレス。 通常、これはアテステーションを信頼するかどうかを決定するために使用されます。 +- `id`: アテステーションID。 この値を使用して、[アテステーションをオンチェーンで読み取り](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000021?tab=read_proxy&source_address=0x4E0275Ea5a89e7a3c1B58411379D1a0eDdc5b088#0xa3112a64)、GraphQLクエリからの情報が正しいことを確認できます。 +- `data`: スキーマデータ (この場合はメールアドレス)。 + +```typescript + const queryResult = await graphqlClient.request(query) + + if (queryResult.attestations.length == 0) + return "no_address@available.is" +``` + +アテステーションがない場合は、明らかに不正であるが、サービスプロバイダーには有効に見える値を返します。 + +```typescript + const attestationDataFields = graphqlEncoder.decodeData(queryResult.attestations[0].data) + return attestationDataFields[0].value.value +} +``` + +値がある場合は、`decodeData`を使用してデータをデコードします。 提供されるメタデータは不要で、値自体のみが必要です。 + +```typescript + const loginResponse = await idp.createLoginResponse( + sp, + { + . + . + . + }, + "post", + { + email: await ethereumAddressToEmail(req.params.account) + } + ); +``` + +新しい関数を使用してメールアドレスを取得します。 + +## 分散化については？ + +この構成では、イーサリアムとメールアドレスのマッピングに信頼できる証明者に依存している限り、ユーザーは他人になりすますことはできません。 しかし、私たちのIDプロバイダーは依然として中央集権的なコンポーネントです。 IDプロバイダーの秘密鍵を持っている人は誰でも、サービスプロバイダーに偽の情報を送信できます。 + +[マルチパーティ計算 (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) を使用した解決策があるかもしれません。 将来のチュートリアルでそれについて書きたいと思っています。 + +## まとめ + +イーサリアム署名のようなログオン標準の採用は、鶏が先か卵が先かの問題に直面します。 サービスプロバイダーは、可能な限り広い市場にアピールしたいと考えています。 ユーザーは、ログオン標準のサポートを心配することなく、サービスにアクセスできることを望んでいます。 +イーサリアムIdPなどのアダプターを作成することは、このハードルを乗り越えるのに役立ちます。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/ja/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md index 119b5ca92b0..cd1a675c8e6 100644 --- a/public/content/translations/ja/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md +++ b/public/content/translations/ja/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md @@ -1,13 +1,8 @@ --- -title: イーサリアム開発入門 +title: "イーサリアム開発入門" description: "この文書は、はじめてイーサリアム開発を行う初心者用のガイドです。 APIエンドポイントの立ち上げ、コマンドライン・リクエストの作成、さらにweb3スクリプトの作成までをステップごとに説明します。 ブロックチェーンの開発経験は必要ありません！" author: "Elan Halpern" -tags: - - "JavaScript" - - "ethers.js" - - "ノード" - - "クエリ" - - "Alchemy" +tags: [ "JavaScript", "ethers.js", "ノード", "クエリ", "Alchemy" ] skill: beginner lang: ja published: 2020-10-30 @@ -15,46 +10,46 @@ source: Medium sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f --- -![イーサリアムおよび Alchemyのロゴ](./ethereum-alchemy.png) +![イーサリアムとAlchemyのロゴ](./ethereum-alchemy.png) -この記事は、はじめてイーサリアム開発を行う初心者向けのガイドです。 このチュートリアルでは、[Alchemy](https://alchemyapi.io/)を使用します。Alchemyは、何百万人ものユーザーを持つ代表的なブロックチェーン開発者向けプラットフォームで、最も人気が高いブロックチェーンアプリ（ Maker、0x、MyEtherWallet、Dharma、Kyberなど）のうち7割がAlchemyを使用しています。 Alchemyを使用するとイーサリアムチェーン上でAPIエンドポイントにアクセスできるため、トランザクションの読み書きが可能になります。 +この記事は、はじめてイーサリアム開発を行う初心者向けのガイドです。 このチュートリアルでは、[Alchemy](https://alchemyapi.io/)を使用します。これは、Maker、0x、MyEtherWallet、Dharma、Kyberといったトップクラスのブロックチェーンアプリの70%に採用され、数百万人のユーザーを支える、業界をリードするブロックチェーン開発者プラットフォームです。 Alchemyを使用するとイーサリアムチェーン上でAPIエンドポイントにアクセスできるため、トランザクションの読み書きが可能になります。 -このチュートリアルでは、Alchemyにサインアップする方法から、最初のweb3 スクリプトを作成するまでを学習します。 ブロックチェーンの開発経験は必要ありません！ +Alchemyへのサインアップから、最初のWeb3スクリプト作成までご案内します！ ブロックチェーンの開発経験は必要ありません！ ## 1. 無料のAlchemyアカウントにサインアップする {#sign-up-for-a-free-alchemy-account} -Alchemyのアカウントを作成するのは簡単です。 [こちら](https://auth.alchemyapi.io/signup)から無料でサインアップしてください。 +Alchemyのアカウント作成は簡単です。[こちらから無料でサインアップしてください](https://auth.alchemy.com/)。 -## 2. Alchemy アプリを作成する {#create-an-alchemy-app} +## 2. Alchemyアプリを作成する {#create-an-alchemy-app} イーサリアムチェーンと通信し、Alchemy製品を使用するには、あなたのリクエストを認証するためのAPIキーが必要になります。 -APIキーは、[ダッシュボード](http://dashboard.alchemyapi.io/)で作成できます。 新規キーを作成するには、以下の手順で「Create App」に移動します。 +APIキーは[ダッシュボードから作成](https://dashboard.alchemy.com/)できます。 新しいキーを作成するには、以下のように「Create App」に移動してください: -ダッシュボードの表示を許可していただいた[_ShapeShift_](https://shapeshift.com/) _に感謝します！_ +_ダッシュボードの表示を許可していただいた[_ShapeShift_](https://shapeshift.com/)に、心より感謝申し上げます！_ -![Alchemyダッシュボード](./alchemy-dashboard.png) +![Alchemyのダッシュボード](./alchemy-dashboard.png) -「Create App」の下にある詳細情報に記入して、新規キーを取得してください。 ここでは、あなたが以前に作成したアプリや、あなたのチームが作成したアプリも確認できます。 どのアプリについても、「View Key（キーを表示）」をクリックすると既存のキーを取得できます。 +「Create App」の下にある詳細情報に記入して、新しいキーを取得してください。 ここでは、あなたが以前に作成したアプリや、あなたのチームが作成したアプリも確認できます。 どのアプリについても、「View Key」をクリックすると既存のキーを取得できます。 -![Alchemyのスクリーンショットでアプリを作成する](./create-app.png) +![Alchemyでアプリを作成するスクリーンショット](./create-app.png) -あるいは、カーソルを「Apps（アプリ）」の部分に移動させ、希望するアプリを選択する方法でも既存のAPIキーを取得することができます。 ここでは、「View Key（キーを表示）」できる他、「Edit App（アプリを編集）」して、特定のドメインをホワイトリストに追加したり、開発者ツールを参照したり、アナリティクスを確認することができます。 +「Apps」にカーソルを合わせていずれかを選択することでも、既存のAPIキーを取得できます。 ここでは「View Key」の表示に加え、「Edit App」で特定のドメインをホワイトリストに登録したり、複数の開発者ツールを閲覧したり、アナリティクスを確認したりすることができます。 -![APIキーの取得方法をユーザーに表示するGIF画像](./pull-api-keys.gif) +![ユーザーへのAPIキー取得方法を示すGIF](./pull-api-keys.gif) -## 3. コマンドラインでリクエストを作成する {#make-a-request-from-the-command-line} +## 3. コマンドラインからリクエストを行う {#make-a-request-from-the-command-line} -JSON-RPCとcurlを使用して、Alchemy経由でイーサリアムブロックチェーンとのやり取りを行います。 +JSON-RPCとcurlを使用して、Alchemy経由でイーサリアムブロックチェーンとやり取りをします。 -マニュアルでリクエストを作成する場合は、`JSON-RPC`の`POST`リクエストを使ってやりとりすることをお勧めします。 `Content-Type: application/json`のヘッダーと、クエリの`POST`本文に、以下のフィールドを入力してください： +手動リクエストの場合は、`POST`リクエストを介して`JSON-RPC`とやり取りすることをお勧めします。 `Content-Type: application/json`ヘッダーと、以下のフィールドを含むクエリを`POST`ボディとして渡すだけです: -- `jsonrpc`：JSON-RPC のバージョン - 現在対応しているのは バージョン`2.0` のみです。 -- `method`：ETH APIメソッド。 [APIリファレンスを参照してください。](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc) +- `jsonrpc`: JSON-RPCのバージョン — 現在は`2.0`のみがサポートされています。 +- `method`: ETH APIメソッド。 [APIリファレンスを参照](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc) - `params`: メソッドに渡すパラメータのリストです。 -- `id`: このリクエストのIDです。 この値は応答によって返されるため、どのリクエストに対する応答なのかを追跡できます。 +- `id`: リクエストのIDです。 この値はレスポンスによって返されるため、どのリクエストに対するレスポンスなのかを追跡できます。 -以下の例は、コマンドラインから現在のガス代の情報を取得するコードです。 +以下は、コマンドラインから現在のガス価格を取得するために実行できる一例です: ```bash curl https://eth-mainnet.alchemyapi.io/v2/demo \ @@ -63,37 +58,37 @@ curl https://eth-mainnet.alchemyapi.io/v2/demo \ -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' ``` -_**注意：** [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo)は、`https://eth-mainnet.alchemyapi.io/v2/**your-api-key` など、あなた自身のAPIキーと置き換えてください。_ +_**注：** [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) を、ご自身のAPIキー `https://eth-mainnet.alchemyapi.io/v2/**your-api-key` に置き換えてください。_ -**出力：** +**結果:** ```json { "id": 73,"jsonrpc": "2.0","result": "0x09184e72a000" // 10000000000000 } ``` -## 4. Web3 クライアントを設定する {#set-up-your-web3-client} +## 4. Web3クライアントのセットアップ {#set-up-your-web3-client} -**すでにクライアントをインストール済みの場合は、** 現在のノードプロバイダーのURLを、APIキーを含むAlchemyのURL（ `"https://eth-mainnet.alchemyapi.io/v2/your-api-key"`など）に変更します。 +**既存のクライアントをお持ちの場合：** 現在のノードプロバイダーのURLを、ご自身のAPIキーを含むAlchemyのURL `“https://eth-mainnet.alchemyapi.io/v2/your-api-key\"` に変更してください。 -**_注意：_** 以下のスクリプトは、 コマンドラインで実行するのではなく、**ノードコンテキスト**または**ファイルに保存した形で**実行する必要があります。 Nodeまたはnpmがインストールされていない場合は、[Mac用設定ガイド](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs) をご覧ください。 +**_注：_** 以下のスクリプトは、コマンドラインから実行するのではなく、**nodeコンテキスト**で実行するか、**ファイルに保存する**必要があります。 まだNodeまたはnpmをインストールしていない場合は、こちらの[Mac用クイックセットアップガイド](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs)をご覧ください。 -Alchemyと統合可能な[Web3ライブラリ](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries)は無数に存在しますが、このチュートリアルでは、Alchemyとシームレスに動作するように構築・設定されたweb3.jsの完全互換版である[Alchemy Web3](https://docs.alchemy.com/reference/api-overview)をお勧めします。 Alchemy Web3は、自動リトライや WebScoket に対する充実したサポートなどの利点を持っています。 +Alchemyと統合できる[Web3ライブラリ](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries)はたくさんありますが、web3.jsのドロップインリプレースメントとして、Alchemyとシームレスに動作するように構築・設定された[Alchemy Web3](https://docs.alchemy.com/reference/api-overview)の使用をお勧めします。 これにより、自動リトライや堅牢なWebSocketサポートなど、複数の利点が得られます。 -Alchemy Web3.jsをインストールするには、 **プロジェクトディレクトリに移動して**、以下を実行します。 +AlchemyWeb3.jsをインストールするには、**プロジェクトディレクトリに移動し**、以下を実行してください: -**Yarnの場合：** +**Yarnの場合:** ``` yarn add @alch/alchemy-web3 ``` -**NPMの場合：** +**NPMの場合:** ``` npm install @alch/alchemy-web3 ``` -Alchemyのノードインフラとやり取りするには、Node.jsで実行するか、JavaScriptファイルに以下の行を追加します： +Alchemyのノードインフラストラクチャとやり取りするには、NodeJSで実行するか、このコードをJavaScriptファイルに追加してください: ```js const { createAlchemyWeb3 } = require("@alch/alchemy-web3") @@ -102,26 +97,26 @@ const web3 = createAlchemyWeb3( ) ``` -## 5. はじめてのWeb3スクリプトを作成しましょう！ {#write-your-first-web3-script} +## 5. 最初のWeb3スクリプトを書きましょう！ {#write-your-first-web3-script} -それではさっそく、実際にweb3のプログラミングを始めましょう。まずは、イーサリアム・メインネットにおける最新のブロック番号を出力する簡単なスクリプトを作成します。 +それでは、少しWeb3プログラミングを試してみましょう。イーサリアムメインネットから最新のブロック番号を出力する簡単なスクリプトを作成します。 -**1. すでに実行していない場合、ターミナルで新規のプロジェクトディレクトリを作成し、cdコマンドで移動します。** +**1. **まだ作成していない場合は、ターミナルで新しいプロジェクトディレクトリを作成し、そこにcdで移動してください:** ``` mkdir web3-example cd web3-example ``` -**2. まだ実行していない場合、Alchemy web3（または任意の web3）の依存関係をプロジェクトにインストールします。** +**2. **まだインストールしていない場合は、Alchemy Web3(または任意のWeb3)の依存関係をプロジェクトにインストールしてください:** ``` npm install @alch/alchemy-web3 ``` -**3. `index.js`という名称のファイルを作成し、以下の内容を追加します：** +**3. **`index.js`という名前のファイルを作成し、次の内容を追加してください:** -> 最終的には、`demo`をあなたのAlchemy HTTP API keyに置き換える必要があります。 +> 最終的には`demo`をご自身のAlchemy HTTP APIキーに置き換える必要があります。 ```js async function main() { @@ -133,22 +128,22 @@ async function main() { main() ``` -非同期関数についてよく理解していない場合は、 この[Mediumの記事](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c)を参照してください。 +async（非同期処理）に慣れていませんか？ こちらの[Mediumの投稿](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c)をご確認ください。 -**4. ノードを使用して、ターミナルで実行します。** +**4. **nodeを使ってターミナルで実行します** ``` node index.js ``` -**5. コンソールに、最新のブロック番号が出力されるはずです。** +**5. **コンソールに最新のブロック番号が出力されているはずです！** ``` The latest block number is 11043912 ``` -**よくできました！ おめでとうございます！ Alchemyを使用した最初のweb3スクリプトが完成しました 🎉** +**素晴らしい！** おめでとうございます！ **これでAlchemyを使って最初のWeb3スクリプトが書けました 🎉** -次は何を学べば良いのかわからない場合は、 [「ハローワールド・スマートコントラクトガイド」](https://docs.alchemyapi.io/tutorials/hello-world-smart-contract)を使って、はじめてのスマートコントラクトのデプロイとSolidityプログラミングに挑戦するか、[ダッシュボード・デモアプリ](https://docs.alchemyapi.io/tutorials/demo-app)でダッシュボードに関するあなたの知識をテストしてみましょう！ +次に何をすればいいかわからないですか？ [Hello Worldスマートコントラクトガイド](https://www.alchemy.com/docs/hello-world-smart-contract)で最初のスマートコントラクトをデプロイしてSolidityプログラミングを試すか、[ダッシュボードデモアプリ](https://docs.alchemyapi.io/tutorials/demo-app)でダッシュボードの知識を試してみてください！ -_[Alchemyに無料登録し](https://auth.alchemyapi.io/signup)、[ドキュメンテーション](https://docs.alchemyapi.io/)を確認してください。また、[Twitter](https://twitter.com/AlchemyPlatform)_をフォローして、最新ニュースをチェックしてください。 +_[Alchemyに無料でサインアップ](https://auth.alchemy.com/)し、[ドキュメント](https://www.alchemy.com/docs/)をチェックして、最新ニュースは[Twitter](https://twitter.com/AlchemyPlatform)でフォローしてください。_ diff --git a/public/content/translations/ja/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/ja/developers/tutorials/guide-to-smart-contract-security-tools/index.md index 9a1ae545f7a..f576f959d91 100644 --- a/public/content/translations/ja/developers/tutorials/guide-to-smart-contract-security-tools/index.md +++ b/public/content/translations/ja/developers/tutorials/guide-to-smart-contract-security-tools/index.md @@ -1,105 +1,102 @@ --- -title: スマートコントラクト関連セキュリティツールのガイド -description: テストおよびプログラム分析に関する3種類のテクニックの概要 +title: "スマートコントラクトセキュリティツールのガイド" +description: "3つの異なるテストおよびプログラム分析手法の概要" author: "Trailofbits" lang: ja -tags: - - "Solidity" - - "スマートコントラクト" - - "セキュリティ" +tags: [ "Solidity", "スマートコントラクト", "セキュリティ" ] skill: intermediate published: 2020-09-07 -source: セキュアなコントラクトの開発 +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis --- -このチュートリアルでは、以下の3種類のテスト／プログラム分析テクニックを取り上げます： +ここでは、3つの特徴的なテストおよびプログラム分析の手法を使用します。 -- **[Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)を用いた静的解析**では、プログラムのすべてのパスにつき、様々なプログラム表示（例：制御フローグラフ）を通じて同時に近似値を求め、分析します。 -- **[Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)を用いたファジング**では、疑似乱数に基づいて生成したトランザクションを用いてコードを実行します。 ファザーは、特定のプロパティに違反する一連のトランザクションを見つけようとします。 -- **[Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)を用いたシンボリック実行**は、各実行パスを数式に変換した上で、制約条件をチェックできるフォーマルな検証テクニックです。 +- **[Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)による静的解析。** プログラムのすべてのパスが、異なるプログラム表示(例：制御フローグラフ)を通じて、同時に近似、分析されます。 +- **[Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)によるファジング。** コードは、トランザクションの疑似ランダム生成によって実行されます。 ファザーは、特定のプロパティに違反する一連のトランザクションを見つけようとします。 +- **[Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)によるシンボリック実行。** 各実行パスを数式に変換し、その上で制約をチェックできる形式的検証テクニックです。 -上記の手法はそれぞれの利点と欠点を持つため、[特定の用途](#determining-security-properties)に合わせて選択すべきです。 +各テクニックには長所と短所があり、[特定のケース](#determining-security-properties)で役立ちます： -| 手法 | ツール | 用途 | 速度 | バグを見落とす可能性 | 偽陽性の可能性 | -| -------- | --------- | ------------------------ | --- | ---------- | ------- | -| 静的解析 | Slither | CLI およびスクリプト | 数秒 | 中程度 | 低い | -| ファジング | Echidna | Solidityのプロパティ | 数分間 | 低い | なし | -| シンボリック実行 | Manticore | Solidity のプロパティおよび スクリプト | 数時間 | なし* | なし | +| テクニック | ツール | 使用法 | 速度 | 見逃されるバグ | 誤検知 | +| -------- | --------- | -------------------- | --- | ------- | --- | +| 静的解析 | Slither | CLIとスクリプト | 数秒 | 中 | 低 | +| ファジング | Echidna | Solidityのプロパティ | 数分間 | 低 | なし | +| シンボリック実行 | Manticore | Solidityのプロパティとスクリプト | 数時間 | なし\* | なし | -* すべてのパスをタイムアウトなしで検証した場合 +- すべてのパスがタイムアウトなしで探索された場合 -**Slither**は、コントラクトを数秒間で分析できますが、 静的解析は誤検知を伴う場合があり、複雑なチェック作業（例：算術演算の検査）にはあまり適していません。 Slitherは、APIを通じてプッシュボタンによりビルトインの検知器にアクセスするか、ユーザー定義のチェック作業用のAPIを通じて実行します。 +**Slither**は数秒でコントラクトを分析しますが、静的解析は誤検知につながる可能性があり、複雑なチェック(算術チェックなど)にはあまり適していません。 Slitherは、API経由で実行し、組み込みの検出器にプッシュボタンでアクセスするか、ユーザー定義のチェックを行います。 -**Echidna**では、検出に数分間を要しますが、偽陽性は検出しません。 Echidnaでは、Solidityで作成され、ユーザーが提供したセキュリティ属性をチェックします。 ただし、ランダムな検索に基づくため、すべてのバグを検出するとは限りません。 +**Echidna**は、実行に数分を要しますが、生成するのは真陽性のみです。 Echidnaは、ユーザーが提供した、Solidityで記述されたセキュリティプロパティをチェックします。 ランダムな探索に基づいているため、バグを見逃す可能性があります。 -**Manticore**は、「最も徹底的な」分析を行います。 Echidnaの場合と同様に、ユーザーが提供した属性を検証します。 検出時間はさらに長くなりますが、特定のプロパティを検証でき、偽陽性を検出することもありません。 +**Manticore**は、"最もヘビー級"の分析を実行します。 Echidnaと同様に、Manticoreはユーザーが提供したプロパティを検証します。 実行にはより時間がかかりますが、プロパティの有効性を証明でき、誤検知を報告しません。 -## 推奨するワークフロー {#suggested-workflow} +## 推奨ワークフロー {#suggested-workflow} -まず、Slitherに内蔵されている検出機能で開始し、現時点において単純なバグが存在せず、今後も紛れ込む可能性がないことを確認しましょう。 Slither を使って、継承、変数の依存関係、および構造的な問題についてチェックします。 コードベースの規模が拡大するのに伴い、Echidnaを使って、ステートマシンにおけるより複雑なプロパティをテストします。 また、上書きされる機能に対する保護などのSolidityでは提供されない保護については、Slitherを使ってカスタムチェックを作成してください。 最後にManticoreを使用して、セキュリティに関する最重要のプロパティ（例：算術演算）のみに対象を絞った検証を行います。 +まずSlitherの組み込み検出器から始めて、単純なバグが現在存在しないこと、そして後で入り込まないことを確認します。 Slitherを使用して、継承、変数の依存関係、構造上の問題に関連するプロパティをチェックします。 コードベースが大きくなるにつれて、Echidnaを使用してステートマシンのより複雑なプロパティをテストします。 Solidityでは利用できない保護(関数のオーバーライドに対する保護など)のために、Slitherを再検討してカスタムチェックを開発します。 最後に、Manticoreを使用して、重要なセキュリティプロパティ(算術演算など)の的を絞った検証を実行します。 -- SlitherのCLIを使って、よくある問題を検出する -- Echidnaを使って、スマートコントラクトにおける高度なセキュリティ関連プロパティをテストする -- Slitherを使って、カスタムの静的解析を作成する -- 最重要なセキュリティ属性について詳細な保証が必要になったら、Manticoreを使用する +- SlitherのCLIを使用して、一般的な問題を検出する +- Echidnaを使用して、コントラクトの高レベルのセキュリティプロパティをテストする +- Slitherを使用して、カスタムの静的チェックを作成する +- 重要なセキュリティプロパティの詳細な保証が必要になったら、Manticoreを使用する -**単体テストに関する注意事項**： 高品質のソフトウェア開発には、単体テストが必須です。 一方で、セキュリティ欠陥を検出する上で、単体テストは最善の方法とは言えません。 通常、単体テストはコードの望ましい動作を確認するため（つまり、通常の環境において予想通りに動作するかどうか）に用いられますが、セキュリティ上の欠陥は、デベロッパが見落としていた周縁的なケースで発生する場合が多いのです。 スマートコントラクトを対象とする数十件のセキュリティレビューを調査した結果、[単体テストのカバレッジは、クライアントのコード上で特定されたセキュリティ上の欠陥の数や重大性には影響を与えていないことが分かりました](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/)。 +**単体テストに関する注記**。 高品質のソフトウェアを構築するには、単体テストが必要です。 しかし、これらのテクニックはセキュリティ上の欠陥を見つけるのに最適というわけではありません。 単体テストは通常、コードの正常な動作(つまり、通常のコンテキストで期待どおりにコードが機能すること)をテストするために使用されますが、セキュリティ上の欠陥は、開発者が考慮しなかったエッジケースに存在する傾向があります。 数十件のスマートコントラクトのセキュリティレビューに関する我々の調査では、クライアントのコードで発見されたセキュリティ上の欠陥の数や重大度に対して、[単体テストのカバレッジは影響を与えませんでした](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/)。 -## 対象とするセキュリティ属性を決定する {#determining-security-properties} +## セキュリティプロパティの決定 {#determining-security-properties} -コードを効果的にテスト、検証するには、まず、対象とすべき分野を特定する必要があります。 セキュリティのためのリソースには限りがありますから、コードベースにおける脆弱な部分や高価値の部分に注力して、この取り組みを最適化することが重要です。 これには、脅威モデリングの手法を用いるとよいでしょう。 以下の事項をレビューしてください： +コードを効果的にテストおよび検証するには、注意が必要な領域を特定する必要があります。 セキュリティに費やすリソースは限られているため、労力を最適化するには、コードベースの脆弱な部分や価値の高い部分を特定することが重要です。 脅威モデリングが役立ちます。 以下をレビューすることを検討してください： -- [迅速リスク評価](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html)（短時間に完了しなければならない場合に推奨するアプローチです） -- [データ中心システムにおける脅威モデル作成ガイド](https://csrc.nist.gov/publications/detail/sp/800-154/draft)（別名：NIST 800-154） -- [Shostackスレッド・モデリング](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998) -- [STRIDE](https://wikipedia.org/wiki/STRIDE_(security)) / [DREAD](https://wikipedia.org/wiki/DREAD_(risk_assessment_model)) +- [迅速なリスク評価](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (時間がない場合に推奨されるアプローチ) +- [データ中心システム脅威モデリングガイド](https://csrc.nist.gov/pubs/sp/800/154/ipd)(別名NIST 800-154) +- [Shostack脅威モデリング](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998) +- [STRIDE](https://wikipedia.org/wiki/STRIDE_\(security\)) / [DREAD](https://wikipedia.org/wiki/DREAD_\(risk_assessment_model\)) - [PASTA](https://wikipedia.org/wiki/Threat_model#P.A.S.T.A.) -- [アサーションを活用する](https://blog.regehr.org/archives/1091) +- [アサーションの使用](https://blog.regehr.org/archives/1091) -### 構成要素 {#components} +### コンポーネント {#components} -どの事項をチェックしたいのかを把握しておくと、適切なツール選択に役立ちます。 +何をチェックしたいかを知ることも、適切なツールを選ぶのに役立ちます。 -スマートコントラクトにおいて問題となる可能性が高い分野としては、以下が挙げられます： +スマートコントラクトに頻繁に関連する幅広い分野には、以下が含まれます： -- **状態マシン** ほとんどのコントラクトは、状態マシンとして表示することが可能です。 ですから、（1）無効な状態に達していないか、（2）状態が有効かつ到達しうるか、および（3）コントラクトをトラップする状態が存在しないか、についてチェックするとよいでしょう。 +- **ステートマシン。** ほとんどのコントラクトはステートマシンとして表現できます。 (1) 無効なステートに到達できないこと、(2) ステートが有効である場合に到達可能であること、(3) コントラクトをトラップするステートがないこと、を確認することを検討してください。 - - 状態マシンの仕様をテストするのに適しているのは、EchidnaとManticoreです。 + - EchidnaとManticoreは、ステートマシンの仕様をテストするのに適したツールです。 -- **アクセス管理。** あなたのシステムに特権ユーザー（例：所有者、管理者など）が含まれる場合、（1）各ユーザーが、権限を持つアクションのみ実行可能であること、および（2）権限レベルがより上のユーザーによるアクションをブロックできる下位ユーザーが存在しないこと、を確認してください。 +- **アクセス制御。** システムに特権ユーザー(例：オーナー、コントローラーなど)がいる場合 (1) 各ユーザーが許可されたアクションのみを実行できること、(2) より特権的なユーザーからのアクションをブロックできるユーザーがいないこと、を保証する必要があります。 - - アクセス管理については、Slither、Echidna、およびManticoreのいずれも適切なチェックを実行できます。 例えばSlitherでは、ホワイトリストに登録された関数のうち、onlyOwner修飾子を持たない関数のみをチェックすることができます。 一方、EchidnaおよびManticoreは、コントラクトが特定のステートに達した場合のみに権限が付与される場合など、より複雑なアクセス管理を確認するのに適しています。 + - Slither、Echidna、Manticoreは、正しいアクセス制御をチェックできます。 例えばSlitherは、`onlyOwner`修飾子を欠く関数がホワイトリスト登録済みのものだけであることをチェックできます。 EchidnaとManticoreは、コントラクトが特定のステートに達した場合にのみ許可が与えられるなど、より複雑なアクセス制御に役立ちます。 -- **算術演算。** 算術演算が正しく実行されるかを確認することは、非常に重要です。 オーバーフロー／アンダーフローを防止するには、`SafeMath`を常に利用することを推奨しますが、同時に、端数処理に関する問題やコントラクトをトラップしてしまうような欠陥など、その他の演算上の欠陥についても確認する必要があります。 +- **算術演算。** 算術演算の健全性をチェックすることは非常に重要です。 あらゆる場所で`SafeMath`を使用することは、オーバーフロー/アンダーフローを防ぐための良い一歩ですが、丸め誤差の問題やコントラクトをトラップする欠陥など、他の算術的な欠陥も考慮する必要があります。 - - この分野では、Manticoreを使用するのがよいでしょう。 当該の算術演算がSMTソルバーの対象範囲外である場合は、Echidnaを選択してもよいです。 + - ここではManticoreが最良の選択です。 算術がSMTソルバーの範囲外である場合は、Echidnaを使用できます。 -- **継承の正確性。** Solidityで作成したコントラクトは、複数の継承に大きく依存しています。 シャドーイング関数において`super`コールが含まれていない場合や、C3 linearizationの順序の誤解釈などのミスは、容易に発生する可能性があります。 +- **継承の正確性。** Solidityコントラクトは多重継承に大きく依存しています。 `super`呼び出しを欠いたシャドウイング関数や、誤って解釈されたC3線形化の順序などの間違いは、簡単に発生し得ます。 - - これらの問題を検出するには、Slitherが最適です。 + - Slitherは、これらの問題を確実に検出するためのツールです。 -- **外部とのやりとり。** コントラクトは相互にやりとりを行いますが、外部のコントラクトの中には信用すべきでないものもあります。 例えば、あなたのコントラクトが外部オラクルに依存する場合、利用可能なオラクルの半分が汚染されていれば、あなたのコントラクトはセキュアであるとは言えないでしょう。 +- **外部とのやりとり。** コントラクトは相互にやりとりしますが、一部の外部コントラクトは信頼すべきではありません。 例えば、コントラクトが外部のオラクルに依存している場合、利用可能なオラクルの半分が侵害されても、そのコントラクトは安全なままでしょうか？ - - コントラクトにおける外部とのやりとりをテストするには、ManticoreおよびEchidnaが最適です。 Manticoreには、外部のコントラクトをスタブするためのメカニズムが内蔵されています。 + - ManticoreとEchidnaは、コントラクトと外部とのやりとりをテストするための最良の選択です。 Manticoreには、外部コントラクトをスタブするための組み込みメカニズムがあります。 -- **規格適合性。** イーサリアムの標準（例：ERC-20）には、これまで様々な設計ミスが含まれていました。 ですから、作成するコントラクトの規格上の制約に十分注意してください。 - - Slither、Echidna、およびManticoreはいずれも、特定の規格に対する非遵守を検知するのに役立ちます。 +- **標準準拠。** イーサリアムの標準(例：ERC20)には、その設計に欠陥があった歴史があります。 構築の基盤となる標準の制限に注意してください。 + - Slither、Echidna、Manticoreは、特定の標準からの逸脱を検出するのに役立ちます。 -### ツール選択の早見表 {#tool-selection-cheatsheet} +### ツール選択のチートシート {#tool-selection-cheatsheet} -| 構成要素 | ツール | 具体例 | -| -------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 状態マシン | Echidna、Manticore | | -| アクセス管理 | Slither、Echidna、Manticore | [Slither エクササイズ2](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md)、[Echidna エクササイズ2](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) | -| 算術演算 | Manticore、Echidna | [Echidna エクササイズ1](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md)、[Manticore エクササイズ1～3](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) | -| 継承の正確さ | Slither | [Slither エクササイズ1](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) | -| 外部とのやりとり | Manticore、Echidna | | -| 規格の遵守 | Slither、Echidna、Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) | +| コンポーネント | ツール | 実例： | +| -------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ステートマシン | Echidna、Manticore | | +| アクセス制御 | Slither、Echidna、Manticore | [Slither 演習 2](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md)、[Echidna 演習 2](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) | +| 算術演算 | Manticore、Echidna | [Echidna 演習 1](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md)、[Manticore 演習 1～3](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) | +| 継承の正確性 | Slither | [Slither 演習 1](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) | +| 外部とのやりとり | Manticore、Echidna | | +| 標準準拠 | Slither、Echidna、Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) | -コントラクトの目的に応じて他の分野についてもチェックする必要がありますが、あらゆるスマートコントラクトにおいて、上記の大まかな注力分野から確認することをお勧めします。 +目標によっては他の領域もチェックする必要がありますが、これらの大まかな重点領域は、あらゆるスマートコントラクトシステムにとって良い出発点となります。 -本サイトのパブリック監査には、検証／テスト済みのプロパティの具体例が含まれています。 実際のセキュリティ関連プロパティについてレビューしたい場合は、以下のレポートの`Automated Testing and Verification（自動テスト／検証）`セクションを参照してください。 +我々の公開監査には、検証またはテストされたプロパティの例が含まれています。 実際のセキュリティプロパティをレビューするには、以下のレポートの`Automated Testing and Verification`のセクションを読むことを検討してください： - [0x](https://github.com/trailofbits/publications/blob/master/reviews/0x-protocol.pdf) - [Balancer](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf) diff --git a/public/content/translations/ja/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/translations/ja/developers/tutorials/hello-world-smart-contract-fullstack/index.md index e57b51fa783..af8028cd846 100644 --- a/public/content/translations/ja/developers/tutorials/hello-world-smart-contract-fullstack/index.md +++ b/public/content/translations/ja/developers/tutorials/hello-world-smart-contract-fullstack/index.md @@ -1,87 +1,90 @@ --- -title: 初心者向けのHello Worldスマートコントラクト - フルスタック -description: イーサリアムでの簡単なスマートコントラクトの作成とデプロイに関する入門チュートリアル +title: "初心者向けのHello Worldスマートコントラクト - フルスタック" +description: "イーサリアムでの簡単なスマートコントラクトの作成とデプロイに関する入門チュートリアル。" author: "nstrike2" tags: - - "Solidity" - - "Hardhat" - - "Alchemy" - - "スマートコントラクト" - - "デプロイ" - - "ブロックエクスプローラ" - - "フロントエンド" - - "トランザクション" + [ + "Solidity", + "Hardhat", + "Alchemy", + "スマートコントラクト", + "デプロイ", + "ブロックエクスプローラー", + "フロントエンド", + "トランザクション" + ] skill: beginner lang: ja published: 2021-10-25 --- -このガイドはブロックチェーンの開発の初心者で、どこから始めたらよいか分からなかったり、スマートコントラクトのデプロイやインタラクト方法について分からない方向けのものです。 これから一緒に、Goerliテストネットワーク上で簡単なスマートコントラクトを作成してデプロイする方法を順を追ってたどりましょう。その際、[MetaMask](https://metamask.io)、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org)と[Alchemy](https://alchemyapi.io/eth)を使用します。 +このガイドは、ブロックチェーン開発の初心者で、どこから始めればよいか、スマートコントラクトのデプロイやインタラクトの方法がわからない方を対象としています。 [MetaMask](https://metamask.io)、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org)、[Alchemy](https://alchemy.com/eth) を使って、Goerliテストネットワークでシンプルなスマートコントラクトを作成し、デプロイする手順を説明します。 -このチュートリアルを完了するためにはAlchemyのアカウントが必要です。 [無料でアカウント登録する](https://www.alchemy.com/). +このチュートリアルを完了するには、Alchemyのアカウントが必要です。 [無料アカウントにサインアップ](https://www.alchemy.com/) -質問がある場合は、いつでもお気軽に[Alchemy Discord](https://discord.gg/gWuC7zB)でお問い合わせください。 +ご不明な点がありましたら、[Alchemy Discord](https://discord.gg/gWuC7zB) までお気軽にお問い合わせください。 -## パート1: Hardhatを利用してスマートコントラクトを作りデプロイする {#part-1} +## パート1 - Hardhatを使用してスマートコントラクトを作成・デプロイする {#part-1} -### イーサリアムネットワークに接続する {#connect-to-the-ethereum-network} +### Ethereumネットワークに接続する {#connect-to-the-ethereum-network} -イーサリアムチェーンにリクエストを行う方法はたくさんあります。 簡略化のため、ここではAlchemyの無料アカウントを使用します。このブロックチェーンのデベロッパープラットフォームとAPIにより、独自のノードを実行することなく、イーサリアムチェーンとの通信が可能になります。 Alchemyには、スマートコントラクトのデプロイメントにおいて内部で何が起こっているのかを把握するためにこのチュートリアルで利用する、監視と分析のためのデベロッパーツールも備わっています。 +イーサリアムチェーンにリクエストを行う方法はたくさんあります。 簡潔にするため、ブロックチェーン開発者プラットフォームであり、APIでもあるAlchemyの無料アカウントを使用します。これにより、自分でノードを実行することなく、Ethereumチェーンと通信できます。 Alchemyには、モニタリングと分析のための開発者ツールもあります。このチュートリアルでは、これらのツールを利用して、スマートコントラクトのデプロイで内部的に何が起こっているかを理解します。 -### アプリのAPIキーの作成 {#create-your-app-and-api-key} +### アプリとAPIキーを作成する {#create-your-app-and-api-key} -Alchemyのアカウントを作成した後、アプリを作成することでAPIキーを生成することができます。 これにより、Goerliテストネットへのリクエストが可能になります。 テストネットに詳しくない場合は、[Alchemyのネットワークの選択ガイド](https://docs.alchemyapi.io/guides/choosing-a-network)をお読みください。 +Alchemyのアカウントを作成したら、アプリを作成してAPIキーを生成できます。 これにより、Goerliテストネットにリクエストを送信できるようになります。 テストネットに馴染みがない場合は、[Alchemyのネットワーク選択ガイド](https://www.alchemy.com/docs/choosing-a-web3-network) をお読みください。 -Alchemyダッシュボード上にあるナビゲーションバーで**Apps**ドロップダウンがあります。そこで、**Create App**をクリックします。 +Alchemyのダッシュボードで、ナビゲーションバーにある **Apps** ドロップダウンを見つけ、**Create App** をクリックします。 -![Hello WorldのCreate App](./hello-world-create-app.png) +![Hello worldアプリ作成](./hello-world-create-app.png) -アプリに「_Hello World_」という名前を付けて、短い説明を書きます。 環境は、**Staging**を選択します。ネットワークは、**Goerli**を選択します。 +アプリに「_Hello World_」という名前を付け、簡単な説明を記述します。 環境として **Staging** を、ネットワークとして **Goerli** を選択します。 -![Hello WorldのCreate App画面](./create-app-view-hello-world.png) +![アプリ作成ビュー hello world](./create-app-view-hello-world.png) -_注意: 必ず**Goerli**を選択してください。そうしないと、このチュートリアルどおり行きません。_ +_注: 必ず **Goerli** を選択してください。選択しないと、このチュートリアルは機能しません。_ -**Create app**をクリックしてください。 アプリが下の表に表示されます。 +**Create app** をクリックします。 作成したアプリが下の表に表示されます。 -### イーサリアムアカウントの作成 {#create-an-ethereum-account} +### Ethereumアカウントを作成する {#create-an-ethereum-account} -トランザクションの送受信には、イーサリアムアカウントが必要です。 ここでは、MetaMaskを使います。MataMaskは、ユーザーがイーサリアムのアカウントアドレスを管理できるブラウザーの仮想ウォレットです。 +トランザクションを送受信するには、Ethereumアカウントが必要です。 ここでは、ユーザーがEthereumアカウントアドレスを管理できる、ブラウザ上の仮想ウォレットであるMetaMaskを使用します。 -Metamaskのアカウントは[こちら](https://metamask.io/download)から無料でダウンロード、作成できます。 アカウントを作成後、またはすでにアカウントをお持ちの場合は(実際に支払いが発生しないように)右上の「Goerli Test Network」に切り替えてください。 +MetaMaskアカウントは、[こちら](https://metamask.io/download)から無料でダウンロードして作成できます。 アカウントを作成するとき、またはすでにアカウントをお持ちの場合は、右上の「Goerli Test Network」に必ず切り替えてください (実在の通貨を扱わないようにするため)。 -### ステップ4: フォーセットからイーサリアムを追加する {#step-4-add-ether-from-a-faucet} +### ステップ4: フォーセットからイーサを追加する {#step-4-add-ether-from-a-faucet} -テストネットワークにスマートコントラクトをデプロイするには、偽のETHが複数必要になります。 GoerliネットワークでETHを取得するには、Goerliフォーセットに移動し、あなたのGoerliのアカウントアドレスを入力します。 Goerliフォーセットは最近、不安定になることがあります。試せるオプションのリストは、[テストネットワークのページ](/developers/docs/networks/#goerli)を参照してください。 +スマートコントラクトをテストネットワークにデプロイするには、偽のETHが必要です。 GoerliネットワークでETHを取得するには、Goerliフォーセットにアクセスし、Goerliアカウントアドレスを入力します。 Goerliフォーセットは最近、少し信頼性が低い場合があります。試せるオプションの一覧については、[テストネットワークのページ](/developers/docs/networks/#goerli) を参照してください: -_注意: ネットワークの混雑状況によっては、時間がかかる場合があります。_ +_注: ネットワークの混雑により、しばらく時間がかかる場合があります。_ +`` ### ステップ5: 残高を確認する {#step-5-check-your-balance} -あなたのウォレットにETHがあることをダブルチェックし、[eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)リクエストを[Alchemyのコンポーザーツール](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)を使って出してみましょう。 リクエストすると、ウォレット内のETHの量が返却されます。 詳細については、[Alchemyの短いチュートリアルにあるコンポーザーツールの使用方法](https://youtu.be/r6sjRxBZJuU)をご覧ください。 +ウォレットにETHが入っていることを再確認するために、[Alchemyのcomposerツール](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D) を使って [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) リクエストを実行してみましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 詳細については、[composerツールの使用方法に関するAlchemyの短いチュートリアル](https://youtu.be/r6sjRxBZJuU) をご覧ください。 -MetaMaskアカウントのアドレスを入力し、**Send Request**をクリックします。 以下のコードスニペットのようなレスポンスが来ます。 +MetaMaskアカウントのアドレスを入力し、**Send Request** をクリックします。 以下のようなコードスニペットのレスポンスが表示されます。 ```json { "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" } ``` -> _注意: この結果の単位はweiであり、ETHではありません。 weiはETHの最小単位として使われています。_ +> _注: この結果はETHではなく、wei単位です。_ _Weiはetherの最小単位として使用されます。_ -ご安心ください。 私たちの偽物のお金はすべてそこにあります。 +ふう! 私たちの偽物のお金はすべてそこにあります。 ### ステップ6: プロジェクトを初期化する {#step-6-initialize-our-project} -まず、プロジェクトのフォルダを作成する必要があります。 コマンドラインに移動し、次のように入力します。 +まず、プロジェクト用のフォルダを作成する必要があります。 コマンドラインに移動し、次のように入力します。 ``` mkdir hello-world cd hello-world ``` -プロジェクトフォルダ内に入ったら、`npm init`を使用してプロジェクトを初期化します。 +プロジェクトフォルダに入ったので、`npm init`を使用してプロジェクトを初期化します。 -> npmをまだインストールしていない場合は、[こちら](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm)の手順に従いNode.jsとnpmをインストールします。 +> まだnpmがインストールされていない場合は、[Node.jsとnpmをインストールするための指示](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm)に従ってください。 このチュートリアルでは、初期化における質問にどのように答えるかには重点を置いていません。 参考までに、私たちは次のように行いました。 @@ -111,29 +114,29 @@ About to write to /Users/.../.../.../hello-world/package.json: } ``` -package.jsonを承認すれば完了です。 +package.jsonを承認すれば完了です！ -### ステップ7: Hardhatのダウンロード {#step-7-download-hardhat} +### ステップ7: Hardhatをダウンロードする {#step-7-download-hardhat} Hardhatは、イーサリアムのソフトウェアをコンパイル、デプロイ、テスト、デバッグするための開発環境です。 デベロッパーがライブチェーンにデプロイする前に、スマートコントラクトや分散型アプリケーション(Dapp)をローカルに構築する際に役立ちます。 -先ほど作成した`hello-world`プロジェクト内で、以下を実行します。 +`hello-world`プロジェクト内で次を実行します。 ``` npm install --save-dev hardhat ``` -[インストール手順](https://hardhat.org/getting-started/#overview)の詳細については、こちらのページをご覧ください。 +[インストール手順](https://hardhat.org/getting-started/#overview)の詳細については、このページをご覧ください。 ### ステップ8: Hardhatプロジェクトを作成する {#step-8-create-hardhat-project} -先ほど作成した`hello-world`プロジェクトフォルダ内で、以下を実行します。 +`hello-world`プロジェクトフォルダ内で、以下を実行します: ``` npx hardhat ``` -ウェルカムメッセージと、次に何をするのかを選択できるオプションが表示されます。 「Create an empty hardhat.config.js」を選択します。 +ウェルカムメッセージと、次に何をするのかを選択できるオプションが表示されます。 「create an empty hardhat.config.js」を選択してください。 ``` 888 888 888 888 888 @@ -153,57 +156,57 @@ Create a sample project Quit ``` -これで、プロジェクト内に`hardhat.config.js`ファイルが生成されます。 プロジェクトの設定を明記するのにチュートリアルの後半でこれを使用します。 +これにより、プロジェクトに `hardhat.config.js` ファイルが生成されます。 チュートリアルの後半で、これを使用してプロジェクトのセットアップを指定します。 ### ステップ9: プロジェクトフォルダを追加する {#step-9-add-project-folders} -プロジェクトを整理するために、2つの新しいフォルダを作成します。 コマンドラインで、`hello-world`プロジェクトのルートディレクトリに移動し、次のように入力します。 +プロジェクトを整理するために、2つの新しいフォルダを作成しましょう。 コマンドラインで、`hello-world` プロジェクトのルートディレクトリに移動し、次のように入力します: ``` mkdir contracts mkdir scripts ``` -- `contracts/`は、Hello Worldスマートコントラクトのコードファイルを格納する場所です。 -- `scripts/`は、コントラクトをデプロイして対話するスクリプトを保持する場所です。 +- `contracts/` には、hello worldスマートコントラクトのコードファイルを保存します +- `scripts/` には、コントラクトをデプロイして対話するためのスクリプトを保存します ### ステップ10: コントラクトを作成する {#step-10-write-our-contract} -一体いつになったらコードを書くのだろうと疑問をお持ちではないでしょうか 。 まさに、その時です! +「いつになったらコードを書くのだろう？」と思っているかもしれませんね。 その時が来ました！ -あなたのお気に入りのエディターでhello-worldプロジェクトを開きます。 スマートコントラクトは、最も一般的にはSolidityで書かれています。そのため、Solidityでスマートコントラクトを作成します。 +お好きなエディタでhello-worldプロジェクトを開いてください。 スマートコントラクトは、最も一般的にはSolidityで記述されており、今回もSolidityを使ってスマートコントラクトを作成します。 -1. `contracts`フォルダに移動し、`HelloWorld.sol`という名前の新規ファイルを作成します。 -2. 以下は、このチュートリアルで使用するHello Worldスマートコントラクトのサンプルです。 以下の内容を`HelloWorld.sol`ファイルにコピーします。 +1. `contracts` フォルダに移動し、`HelloWorld.sol` という名前の新しいファイルを作成します。 +2. 以下は、このチュートリアルで使用するHello Worldスマートコントラクトのサンプルです。 以下の内容を `HelloWorld.sol` ファイルにコピーしてください。 -_注意: 必ずコメントを読み、このコントラクトの処理内容を理解してください。_ +_注: このコントラクトが何をするのかを理解するために、必ずコメントをお読みください。_ ``` -// Specifies the version of Solidity, using semantic versioning. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// Solidityのバージョンをセマンティックバージョニングで指定します。 +// 詳細: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity >=0.7.3; -// Defines a contract named `HelloWorld`. -// A contract is a collection of functions and data (its state). Once deployed, a contract resides at a specific address on the Ethereum blockchain. Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// `HelloWorld` という名前のコントラクトを定義します。 +// コントラクトは関数とデータ (その状態) の集合です。一度デプロイされると、コントラクトはEthereumブロックチェーン上の特定のアドレスに存在します。詳細: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html contract HelloWorld { - //Emitted when update function is called - //Smart contract events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. + // update関数が呼び出されたときに発行されます + //スマートコントラクトのイベントは、ブロックチェーン上で何かが起こったことをコントラクトがアプリのフロントエンドに伝える方法です。フロントエンドは特定のイベントを「リッスン」し、それが起こったときに行動を起こすことができます。 event UpdatedMessages(string oldStr, string newStr); - // Declares a state variable `message` of type `string`. - // State variables are variables whose values are permanently stored in contract storage. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value. + // `string` 型の状態変数 `message` を宣言します。 + // 状態変数は、その値がコントラクトのストレージに永続的に保存される変数です。`public` キーワードにより、変数はコントラクトの外部からアクセス可能になり、他のコントラクトやクライアントが値をアクセスするために呼び出せる関数が作成されます。 string public message; - // Similar to many class-based object-oriented languages, a constructor is a special function that is only executed upon contract creation. - // Constructors are used to initialize the contract's data. Learn more:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // 多くのクラスベースのオブジェクト指向言語と同様に、コンストラクタはコントラクト作成時に一度だけ実行される特別な関数です。 + // コンストラクタはコントラクトのデータを初期化するために使用されます。詳細:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors constructor(string memory initMessage) { - // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable). + // 文字列引数 `initMessage` を受け取り、その値をコントラクトの `message` ストレージ変数に設定します)。 message = initMessage; } - // A public function that accepts a string argument and updates the `message` storage variable. + // 文字列引数を受け取り、 `message` ストレージ変数を更新する公開関数です。 function update(string memory newMessage) public { string memory oldMsg = message; message = newMessage; @@ -212,15 +215,15 @@ contract HelloWorld { } ``` -これは、作成時にメッセージを保存する基本的なスマートコントラクトです。 `update`関数を呼び出すことで更新できます。 +これは、作成時にメッセージを保存する基本的なスマートコントラクトです。 `update` 関数を呼び出すことで更新できます。 ### ステップ11: MetaMaskとAlchemyをプロジェクトに接続する {#step-11-connect-metamask-alchemy-to-your-project} -ここまでで、MetaMaskウォレットとAlchemyアカウントを作成し、スマートコントラクトも作成しました。次はこの3つを接続しましょう。 +MetaMaskウォレットとAlchemyアカウントを作成し、スマートコントラクトも作成しました。次はこの3つを接続しましょう。 -ウォレットから送信されるすべてのトランザクションには、固有の秘密鍵を使用した署名が必要です。 この許可をプログラムに与えるために、秘密鍵を環境ファイルに安全に格納する作業を行います。 AlchemyのAPIキーもここに保存します。 +ウォレットから送信されるすべてのトランザクションには、一意の秘密鍵を使用した署名が必要です。 プログラムにこの許可を与えるために、秘密鍵を環境ファイルに安全に保存することができます。 AlchemyのAPIキーもここに保存します。 -> トランザクションの送信の詳細については、[こちらのチュートリアル](https://docs.alchemyapi.io/alchemy/tutorials/sending-transactions-using-web3-and-alchemy)のweb3使ったトランザクションの送信に関する内容をご覧ください。 +> トランザクションの送信についてさらに詳しく知るには、web3を使用したトランザクションの送信に関する[このチュートリアル](https://www.alchemy.com/docs/hello-world-smart-contract#step-11-connect-metamask--alchemy-to-your-project) を確認してください。 まず、プロジェクトディレクトリにdotenvパッケージをインストールします。 @@ -228,31 +231,31 @@ contract HelloWorld { npm install dotenv --save ``` -次に、プロジェクトのルートディレクトリに`.env`ファイルを作成します。 MetaMask秘密鍵とHTTP Alchemy API URLをファイルに加えます。 +次に、プロジェクトのルートディレクトリに `.env` ファイルを作成します。 そのファイルに、MetaMaskの秘密鍵とHTTP Alchemy APIのURLを追加します。 -環境ファイルの名前は、必ず`.env`にしてください。そうしないと環境ファイルとして認識されません。 +環境ファイルは `.env` という名前にする必要があります。そうしないと、環境ファイルとして認識されません。 -`process.env`や`.env-custom`などの名前を付けないでください。 +`process.env` や `.env-custom` など、他の名前にしないでください。 -- 秘密鍵をエクスポートするには、[こちらの手順](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)に従ってください。 -- HTTP Alchemy APIのURLを取得するには、以下を参照してください。 +- 秘密鍵をエクスポートするための[これらの手順](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)に従ってください +- HTTP Alchemy API URLを取得するには、以下を参照してください ![](./get-alchemy-api-key.gif) -`.env`ファイルは次のようになります。 +`.env`は次のようになります: ``` API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" PRIVATE_KEY = "your-metamask-private-key" ``` -これらの変数を実際にコードに接続するために、ステップ13でこれらの変数を`hardhat.config.js`ファイル内で参照します。 +これらをコードに実際に接続するために、ステップ13で`hardhat.config.js`ファイル内のこれらの変数を参照します。 ### ステップ12: Ethers.jsをインストールする {#step-12-install-ethersjs} -Ethers.jsは、よりユーザーフレンドリーなメソッドで[標準のJSON-RPCメソッド](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc)をラップすることにより、イーサリアムとの対話やリクエストを簡単に行うためのライブラリです。 +Ethers.jsは、[標準的なJSON-RPCメソッド](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc)をよりユーザーフレンドリーなメソッドでラップすることにより、Ethereumとのインタラクションやリクエストを容易にするライブラリです。 -Hardhatを使用すると、追加のツールと拡張機能のための[プラグイン](https://hardhat.org/plugins/)を統合できます。 コントラクトのデプロイでは、[Ethersプラグイン](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers)を利用します。 +Hardhatでは、追加のツールや拡張機能のために[プラグイン](https://hardhat.org/plugins/)を統合することができます。 コントラクトのデプロイには[Ethersプラグイン](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers)を利用します。 プロジェクトのホームディレクトリで以下を実行します。 @@ -260,11 +263,11 @@ Hardhatを使用すると、追加のツールと拡張機能のための[プラ npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0" ``` -### ステップ13: hardhat.config.jsをアップデートする {#step-13-update-hardhat-configjs} +### ステップ13: hardhat.config.jsを更新する {#step-13-update-hardhat-configjs} -ここまでで、いくつかの依存関係とプラグインを追加しました。次に、`hardhat.config.js`を更新して、プロジェクトがそれらすべてについて認識できるようにする必要があります。 +ここまでで、いくつかの依存関係とプラグインを追加しました。次に、プロジェクトがそれらすべてを認識できるように、`hardhat.config.js`を更新する必要があります。 -`hardhat.config.js`を以下のように更新します。 +`hardhat.config.js`を次のように更新します: ```javascript /** @@ -291,7 +294,7 @@ module.exports = { ### ステップ14: コントラクトをコンパイルする {#step-14-compile-our-contract} -ここまででしっかりと動作していることを確認するため、コントラクトをコンパイルしてみましょう。 `compile`タスクは、組み込みのHardhatタスクの1つです。 +ここまでの作業がうまくいっていることを確認するために、コントラクトをコンパイルしてみましょう。 `compile`タスクは、組み込みのHardhatタスクの1つです。 コマンドラインで以下を実行します。 @@ -299,19 +302,19 @@ module.exports = { npx hardhat compile ``` -`SPDX license identifier not provided in source file`という警告が表示される場合がありますが、心配する必要はありません。警告が表示されないのがベストですが、 表示された場合は、いつでも[Alchemy discord](https://discord.gg/u72VCg3)でメッセージを送信できます。 +`SPDX license identifier not provided in source file` という警告が表示されるかもしれませんが、心配する必要はありません。それ以外はすべて問題ないはずです！ うまくいかない場合は、いつでも[Alchemy Discord](https://discord.gg/u72VCg3)でメッセージを送ることができます。 -### ステップ15: デプロイスクリプトを書く {#step-15-write-our-deploy-script} +### ステップ15: デプロイスクリプトを作成する {#step-15-write-our-deploy-script} コントラクトの作成と設定ファイルの作成が完了したら、いよいよコントラクトのデプロイのためのスクリプトを作成します。 -`scripts/`フォルダに移動して、`deploy.js`という名前のファイルを新規に作成し、以下の内容を追加します。 +`scripts/`フォルダに移動して`deploy.js`という名前の新しいファイルを作成し、次の内容を追加します: ```javascript async function main() { const HelloWorld = await ethers.getContractFactory("HelloWorld") - // Start deployment, returning a promise that resolves to a contract object + // デプロイを開始し、コントラクトオブジェクトに解決されるpromiseを返す const hello_world = await HelloWorld.deploy("Hello World!") console.log("Contract deployed to address:", hello_world.address) } @@ -324,23 +327,23 @@ main() }) ``` -Hardhatがコードの各行で行っている驚くべき内容については、Hardhatの[コントラクトチュートリアル](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)で説明されています。以下では、その説明を採用しています。 +Hardhatは、[コントラクトのチュートリアル](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)で、これらのコードの各行が何をするかを非常にうまく説明しています。ここではその説明を採用しました。 ```javascript const HelloWorld = await ethers.getContractFactory("HelloWorld") ``` -ethers.jsの`ContractFactory`は新しいスマートコントラクトをデプロイするための抽象化であり、ここでの`HelloWorld`はhello worldコントラクトのインスタンスのための[ファクトリ](https://en.wikipedia.org/wiki/Factory_(object-oriented_programming))です。 `hardhat-ethers`プラグインを使用する場合、`ContractFactory`および`Contract`インスタンスはデフォルトで最初の署名者 (所有者) に接続されます。 +ethers.jsの `ContractFactory` は、新しいスマートコントラクトをデプロイするために使用される抽象化です。したがって、ここでの `HelloWorld` は、私たちのhello worldコントラクトのインスタンスのための[ファクトリ](https://en.wikipedia.org/wiki/Factory_\(object-oriented_programming\))です。 `hardhat-ethers`プラグインを使用する場合、`ContractFactory`と`Contract`のインスタンスは、デフォルトで最初の署名者 (所有者) に接続されます。 ```javascript const hello_world = await HelloWorld.deploy() ``` -`ContractFactory`で`deploy()`を呼び出すとデプロイメントが開始され、`Contract`オブジェクトに解決すべき`Promise`が返されます。 これは、スマートコントラクトの各関数に対するメソッドを持つオブジェクトです。 +`ContractFactory`で`deploy()`を呼び出すとデプロイが開始され、`Contract`オブジェクトに解決される`Promise`が返されます。 これは、スマートコントラクトの各関数に対するメソッドを持つオブジェクトです。 ### ステップ16: コントラクトをデプロイする {#step-16-deploy-our-contract} -ようやく、スマートコントラクトをデプロイする準備が整いました。 コマンドラインに移動し、以下を実行します。 +ようやく、スマートコントラクトをデプロイする準備が整いました。 コマンドラインに移動し、次を実行します: ```bash npx hardhat run scripts/deploy.js --network goerli @@ -349,34 +352,34 @@ npx hardhat run scripts/deploy.js --network goerli 次のような画面が表示されるはずです。 ```bash -Contract deployed to address: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 +コントラクトがデプロイされたアドレス: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 ``` -**このアドレスを保存してください**。 このアドレスをチュートリアルの後半で使用します。 +**このアドレスを保存してください**。 このアドレスはチュートリアルの後半で使用します。 -[Goerli etherscan](https://goerli.etherscan.io)に移動し、コントラクトアドレスを検索すると、コントラクトが正常にデプロイされていることを確認できるはずです。 トランザクションは以下のようなものになります。 +[Goerli etherscan](https://goerli.etherscan.io) にアクセスしてコントラクトアドレスを検索すると、正常にデプロイされたことを確認できるはずです。 トランザクションは以下のようなものになります。 ![](./etherscan-contract.png) -`From`アドレスはMetaMaskアカウントのアドレスと一致し、`To`アドレスは「**Contract Creation**」と表示されます。 トランザクション内容をクリックすると、`To`フィールドにコントラクトアドレスが表示されます. +`From`アドレスはMetaMaskアカウントのアドレスと一致し、`To`アドレスには**Contract Creation**と表示されます。 トランザクションをクリックすると、`To`フィールドにコントラクトアドレスが表示されます。 ![](./etherscan-transaction.png) -おめでとうございます！ イーサリアムのテストネットにスマートコントラクトをデプロイできました. +おめでとうございます！ Ethereumテストネットにスマートコントラクトをデプロイできました。 -内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemyのアプリが複数ある場合は、必ずアプリでフィルタリングし、「**Hello World**」を選択してください。 +内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemy.com/explorer)のExplorerタブに移動してみましょう。 複数のAlchemyアプリをお持ちの場合は、必ずアプリでフィルタリングし、**Hello World**を選択してください。 ![](./hello-world-explorer.png) -ここでは、`.deploy()`関数を呼び出した際に、HardhatもしくはEthersが内部で行ったJSON-RPCメソッドを見ることができます。 ここで2つの重要なメソッドがあります。まずは、[`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction)です。これは、Goerliチェーンにコントラクトを書き込むリクエストです。次に[`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash)は、ハッシュを指定してトランザクションに関する情報を読み取るリクエストです。 トランザクションの送信の詳細については、[こちら](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)のチュートリアルにあるWeb3を使用したトランザクションの送信をご覧ください。 +ここでは、`.deploy()`関数を呼び出した際に、Hardhat/Ethersが内部で行ったいくつかのJSON-RPCメソッドを見ることができます。 ここでの2つの重要なメソッドは、コントラクトをGoerliチェーンに書き込むリクエストである [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) と、ハッシュが与えられたトランザクションに関する情報を読み取るリクエストである [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash) です。 トランザクションの送信についてさらに詳しく知るには、[Web3を使用したトランザクション送信に関するチュートリアル](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)を確認してください。 -## パート2: スマートコントラクトとのやり取り {#part-2-interact-with-your-smart-contract} +## パート2: スマートコントラクトとインタラクトする {#part-2-interact-with-your-smart-contract} スマートコントラクトをGoerliネットワークに正常にデプロイできました。それでは、スマートコントラクトとやり取りする方法について学びましょう。 -### interact.jsファイルの作成 {#create-a-interactjs-file} +### interact.jsファイルを作成する {#create-a-interactjs-file} -このファイルに、やり取りするスクリプトを記述します。 パート1でインストールしたEthers.jsライブラリを使用します。 +このファイルに、インタラクトするスクリプトを記述します。 パート1でインストールしたEthers.jsライブラリを使用します。 `scripts/`フォルダ内に、`interact.js`という名前の新しいファイルを作成し、次のコードを追加します。 @@ -388,9 +391,9 @@ const PRIVATE_KEY = process.env.PRIVATE_KEY const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS ``` -### .envファイルの更新 {#update-your-env-file} +### .envファイルを更新する {#update-your-env-file} -新しい環境変数を使用します。そのため、[以前に作成した](#step-11-connect-metamask-&-alchemy-to-your-project)`.env`ファイルに定義する必要があります。 +新しい環境変数を使用するため、[以前に作成した](#step-11-connect-metamask-&-alchemy-to-your-project)`.env`ファイルに定義する必要があります。 Alchemyの`API_KEY`とスマートコントラクトがデプロイされている`CONTRACT_ADDRESS`の定義を加える必要があります。 @@ -407,14 +410,14 @@ CONTRACT_ADDRESS = "0x" ### コントラクトABIを取得する {#grab-your-contract-ABI} -コントラクト[ABI(アプリケーションバイナリインターフェイス)](/glossary/#abi)は、スマートコントラクトと対話するためのインターフェイスです。 Hardhatは自動的にABIを生成して、`HelloWorld.json`ファイルに保存します。 ABIを使うには、`interact.js`ファイルに次のコードを追加して、コンテンツをパースする必要があります。 +コントラクトの[ABI (アプリケーションバイナリインターフェイス)](/glossary/#abi)は、スマートコントラクトとインタラクトするためのインターフェイスです。 Hardhatは自動的にABIを生成して、`HelloWorld.json`ファイルに保存します。 ABIを使うには、`interact.js`ファイルに次のコードを追加して、コンテンツをパースする必要があります。 ```javascript // interact.js const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json") ``` -ABIを表示したい場合は、次のコードを追加することでコンソールに出力できます: +ABIを確認したい場合は、コンソールに出力できます: ```javascript console.log(JSON.stringify(contract.abi)) @@ -428,13 +431,13 @@ npx hardhat run scripts/interact.js ### コントラクトのインスタンスを作成する {#create-an-instance-of-your-contract} -コントラクトを操作するには、コード内にコントラクトのインスタンスを作成する必要があります。 Ethers.jsでこれを行うには、次の3つのコンセプトを機能させる必要があります。 +コントラクトを操作するには、コード内にコントラクトのインスタンスを作成する必要があります。 Ethers.jsでこれを行うには、次の3つのコンセプトを扱う必要があります。 1. Provider - ブロックチェーンへの読み取りおよび書き込みアクセスを提供するノードプロバイダです。 -2. Signer - トランザクションに署名するイーサリアムアカウントを表します。 +2. Signer - トランザクションに署名するEthereumアカウントを表します。 3. Contract - オンチェーンにデプロイされた特定のコントラクトを表すEthers.jsのオブジェクトです。 -前の手順で取得したコントラクABIを使って、コントラクトのインスタンスを作成します。 +前の手順で取得したコントラクトABIを使って、コントラクトのインスタンスを作成します。 ```javascript // interact.js @@ -458,11 +461,11 @@ const helloWorldContract = new ethers.Contract( Provider、Signer、Contractの詳細については、[ethers.jsドキュメント](https://docs.ethers.io/v5/)をご覧ください。 -### initメッセージの読み取り {#read-the-init-message} +### initメッセージを読み込む {#read-the-init-message} -`initMessage = "Hello world!"`を使用してコントラクトをデプロイしたことを思い出せますでしょうか？ ここでは、スマートコントラクトに保存されているメッセージを読み取り、コンソールに出力します。 +`initMessage = "Hello world!"`を使用してコントラクトをデプロイしたことを覚えていますか？ ここでは、スマートコントラクトに保存されているメッセージを読み取り、コンソールに出力します。 -JavaScriptでは、ネットワークとのやり取りで非同期関数を使います。 非同期関数の詳細については、[この記事の中ほど](https://blog.bitsrc.io/Understanding-asynchronous-javascript-the-event-loop-74cd408419ff)をご覧ください。 +JavaScriptでは、ネットワークとのインタラクトで非同期関数を使います。 非同期関数についてさらに詳しく知るには、[このmediumの記事](https://blog.bitsrc.io/understanding-asynchronous-javascript-the-event-loop-74cd408419ff)をお読みください。 以下のコードを使用して、スマートコントラクトの`message`関数を呼び出し、initメッセージを読み取ります。 @@ -478,19 +481,19 @@ async function main() { main() ``` -ターミナルで`npx hardware run scripts/interact.js`を入力してファイルを実行すると、次のレスポンスが表示されるはずです。 +ターミナルで `npx hardhat run scripts/interact.js` を使用してファイルを実行すると、次のようなレスポンスが表示されます。 ``` The message is: Hello world! ``` -おめでとうございます！ イーサリアムブロックチェーンからスマートコントラクトのデータを正常に読み取ることができました。 +おめでとうございます！ Ethereumブロックチェーンからスマートコントラクトのデータを正常に読み取ることができました。お見事！ -### メッセージの更新 {#update-the-message} +### メッセージを更新する {#update-the-message} -メッセージを読み取るだけでなく、`update`関数を使ってスマートコントラクトに保存されたメッセージを更新することもできます。 かなりイケてますよね？ +メッセージを読み取るだけでなく、`update`関数を使ってスマートコントラクトに保存されたメッセージを更新することもできます。 かなりクールでしょう？ -メッセージを更新するには、インスタンス化されたコントラクトのオブジェクトで`update`関数を直接呼び出します。 +メッセージを更新するには、インスタンス化されたContractオブジェクトで`update`関数を直接呼び出します。 ```javascript // interact.js @@ -508,13 +511,13 @@ async function main() { main() ``` -11行目で、返されたトランザクションのオブジェクトに対して `.wait()`を呼び出していることに注目してください。 これにより、スクリプトが関数を終了する前に、トランザクションがブロックチェーン上でマイニングされるまで待機することを確実にします。 `.wait()`を呼び出しを含めなかった場合、スクリプトは、コントラクト内で更新された`message`の値を表示しないことがあります。 +11行目で、返されたトランザクションオブジェクトに対して `.wait()` を呼び出していることに注目してください。 これにより、スクリプトが関数を終了する前に、トランザクションがブロックチェーン上でマイニングされるまで待機することが保証されます。 `.wait()` の呼び出しを含めなかった場合、スクリプトは、コントラクト内で更新された `message` の値を表示しないことがあります。 -### 新しいメッセージの読み取り {#read-the-new-message} +### 新しいメッセージを読み込む {#read-the-new-message} -[前の手順](#read-the-init-message)を繰り返して、更新された`message`の値を読み取ることができるのに違いありません。 その新しい値を出力するために必要となる変更を、少し考えてみましょう！ +[前の手順](#read-the-init-message)を繰り返して、更新された `message` の値を読み取ることができるはずです。 少し時間を取って、新しい値を表示するために必要な変更を加えられるか試してみましょう！ -ヒントが必要ですか？この時点で、あなたの`interact.js`ファイルは次のようになるはずです。 +ヒントが必要な場合は、この時点で`interact.js`ファイルがどのようになるかを示します。 ```javascript // interact.js @@ -556,7 +559,7 @@ async function main() { main() ``` -このスクリプトを実行するだけで、古いメッセージ、更新ステータス、および新しいメッセージがコンソールに出力されるのを確認できるはずです。 +このスクリプトを実行するだけで、古いメッセージ、更新ステータス、および新しいメッセージがターミナルに出力されるのを確認できるはずです。 `npx hardhat run scripts/interact.js --network goerli` @@ -566,29 +569,29 @@ Updating the message... The new message is: This is the new message. ``` -このスクリプトの実行中、新しいメッセージが読み込まれる前に、 `Updating the message...`のステップの読み込みにしばらく時間がかかることに気づくかもしれません。 これはマイニングプロセスによるものです。マイニング中のトランザクションの追跡に興味があるならば、[Alchemy mempool](https://dashboard.alchemyapi.io/mempool)にアクセスしてトランザクションのステータスを確認できます。 トランザクションがドロップされた場合は、[Goerli Etherscan](https://goerli.etherscan.io)を確認してトランザクションのハッシュを検索することもできます。 +このスクリプトの実行中、新しいメッセージが読み込まれる前に、 `Updating the message...` のステップの読み込みにしばらく時間がかかることに気づくかもしれません。 これはマイニングプロセスによるものです。マイニング中のトランザクションの追跡に興味があるならば、[Alchemyメンプール](https://dashboard.alchemyapi.io/mempool)にアクセスしてトランザクションのステータスを確認できます。 トランザクションがドロップされた場合は、[Goerli Etherscan](https://goerli.etherscan.io) を確認してトランザクションハッシュを検索することも役立ちます。 ## パート3: スマートコントラクトをEtherscanに公開する {#part-3-publish-your-smart-contract-to-etherscan} -あなたは、スマートコントラクトに命を吹き込むことに大変な努力をしました。それでは、その努力を世界に共有しましょう！ +あなたは、スマートコントラクトに命を吹き込むために大変な努力をしました。さあ、その成果を世界に共有しましょう！ -Etherscanでスマートコントラクトを検証すると、誰でもソースコードを表示して、あなたのスマートコントラクトとやり取りできるようになります。 さあ、始めましょう！ +Etherscanでスマートコントラクトを検証すると、誰でもソースコードを表示して、あなたのスマートコントラクトとインタラクトできるようになります。 さあ、始めましょう！ ### ステップ1: EtherscanアカウントでAPIキーを生成する {#step-1-generate-an-api-key-on-your-etherscan-account} EtherscanのAPIキーは、公開しようとしているスマートコントラクトを所有していることを確認するために必要になります。 -Etherscanアカウントをお持ちでない場合は、[アカウントの登録](https://etherscan.io/register)をしてください。 +Etherscanアカウントをお持ちでない場合は、[アカウントにサインアップ](https://etherscan.io/register)してください。 -ログインしたら、ナビゲーションバーでユーザー名を見つけ、その上にマウスを移動して、「**My profile**」ボタンを選択します。 +ログインしたら、ナビゲーションバーでユーザー名を見つけ、その上にカーソルを合わせて **My profile** ボタンを選択します。 -プロフィールページにサイドナビゲーションバーが表示されます。 サイドナビゲーションバーで、**API Keys**を選択します。 次に、「Add」ボタンを押して新しいAPIキーを作成し、アプリに**hello-world**という名前を付けて、「**Create New API**」ボタンを押します。 +プロフィールページにサイドナビゲーションバーが表示されます。 サイドナビゲーションバーで、**API Keys**を選択します。 次に、「Add」ボタンを押して新しいAPIキーを作成し、アプリに **hello-world** という名前を付けて、「**Create New API Key**」ボタンを押します。 新しいAPIキーがAPIキーテーブルに表示されるはずです。 APIキーをクリップボードにコピーします。 次に、EtherscanのAPIキーを`.env`ファイルに加える必要があります。 -そうすると、`.env`ファイルは次のようになります。 +追加した後、`.env`ファイルは次のようになります。 ```javascript API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" @@ -598,17 +601,17 @@ CONTRACT_ADDRESS = "your-contract-address" ETHERSCAN_API_KEY = "your-etherscan-key" ``` -### Hardhatにデプロイされたスマートコントラクト {#hardhat-deployed-smart-contracts} +### Hardhatでデプロイされたスマートコントラクト {#hardhat-deployed-smart-contracts} -#### hardhat-etherscanのインストール {#install-hardhat-etherscan} +#### hardhat-etherscanをインストールする {#install-hardhat-etherscan} -あなたのコントラクトをEtherscanへ公開するのは、Hardhatを使って簡単にできます。 はじめに、まず`hardhat-etherscan`プラグインをインストールしてください。 `hardhat-etherscan`は、スマートコントラクトのソースコードとEtherscan上のABIを自動的に検証します。 インストールするには、`hello-world`ディレクトリで次のコマンドを実行します。 +Hardhatを使ってコントラクトをEtherscanへ公開するのは簡単です。 まず、`hardhat-etherscan`プラグインをインストールする必要があります。 `hardhat-etherscan`は、スマートコントラクトのソースコードとEtherscan上のABIを自動的に検証します。 インストールするには、`hello-world`ディレクトリで次のコマンドを実行します。 ```text npm install --save-dev @nomiclabs/hardhat-etherscan ``` -インストールをしたら、`hardhat.config.js`の先頭に次のステートメントを含んだEtherscan構成オプションを追加します。 +インストールしたら、`hardhat.config.js`の先頭に次のステートメントを含め、Etherscanの構成オプションを追加します。 ```javascript // hardhat.config.js @@ -630,14 +633,14 @@ module.exports = { }, }, etherscan: { - // Your API key for Etherscan - // Obtain one at https://etherscan.io/ + // Etherscan用のAPIキー + // https://etherscan.io/ で取得 apiKey: ETHERSCAN_API_KEY, }, } ``` -#### Etherscan上でスマートコントラクトを検証する {#verify-your-smart-contract-on-etherscan} +#### Etherscanでスマートコントラクトを検証する {#verify-your-smart-contract-on-etherscan} すべてのファイルが保存され、すべての`.env`変数が正しく構成されていることを確認してください。 @@ -647,9 +650,9 @@ module.exports = { npx hardhat verify --network goerli DEPLOYED_CONTRACT_ADDRESS 'Hello World!' ``` -`DEPLOYED_CONTRACT_ADDRESS`がGoerliテストネットワーク上にデプロイされたスマートコントラクトのアドレスであることを確認してください。 また、最後の引数 (`'Hello World!'`) は、 [パート1のデプロイ手順](#write-our-deploy-script)で使われたの文字列値と同じでなければなりません。 +`DEPLOYED_CONTRACT_ADDRESS`がGoerliテストネットワーク上にデプロイされたスマートコントラクトのアドレスであることを確認してください。 また、最後の引数(`'Hello World!'`)は、[パート1のデプロイスクリプト作成手順](#write-our-deploy-script)で使用した文字列値と同じでなければなりません。 -順調に行けば、コンソールに次のメッセージが表示されます。 +すべてが順調に進めば、ターミナルに次のメッセージが表示されます。 ```text Successfully submitted source code for contract @@ -661,69 +664,69 @@ Successfully verified contract HelloWorld on Etherscan. https://goerli.etherscan.io/address/#contracts ``` -おめでとうございます！ これで、あなたのスマートコントラクトコードは、Etherscan上にあります。 +おめでとうございます！ これで、あなたのスマートコントラクトコードはEtherscan上にあります。 -### Etherscanであなたのスマートコントラクトを確認する {#check-out-your-smart-contract-on-etherscan} +### Etherscanであなたのスマートコントラクトを確認しましょう！ {#check-out-your-smart-contract-on-etherscan} -コンソールに表示されているリンクに移動すると、Etherscanで公開されているスマートコントラクトコードとABIが表示されます。 +ターミナルに表示されているリンクに移動すると、Etherscanで公開されているスマートコントラクトコードとABIが表示されます。 -**ヤッホー！栄冠を手にしました。 これで、誰でもスマートコントラクトを呼び出したり、書き込んだりできるようになりました。 次にあなたが何を構築するか楽しみにしています。** +**ヤッター！やりましたね！ これで、誰でもスマートコントラクトを呼び出したり、書き込んだりできるようになりました。 次にあなたが何を構築するか楽しみにしています。** -## パート4: フロントエンドとスマートコントラクトの統合 {#part-4-integrating-your-smart-contract-with-the-frontend} +## パート4 - スマートコントラクトをフロントエンドと統合する {#part-4-integrating-your-smart-contract-with-the-frontend} このチュートリアルを終えると、次の方法がわかるようになります。 - MetaMaskウォレットをdappに接続する -- [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) APIを使用してスマートコントラクトからデータを読み取る。 -- MetaMaskを使用してイーサリアムトランザクションに署名する +- [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) APIを使用してスマートコントラクトからデータを読み取る +- MetaMaskを使用してEthereumトランザクションに署名する -このdappでは、フロントエンドフレームワークで[React](https://reactjs.org/)を使っていますが、Web3の機能をプロジェクトに導入することに焦点を当てているので、Reactの基本を説明することに多くの時間を費やさないことに注意してください。 +このdappでは、フロントエンドフレームワークとして[React](https://react.dev/)を使用します。ただし、このプロジェクトではWeb3機能を導入することに主に焦点を当てているため、Reactの基礎を詳しく説明する時間はあまりかけない点に注意してください。 -前提条件として、Reactについて初心者レベルの理解をしている必要があります。 知らなければ、公式の[React入門チュートリアル](https://reactjs.org/tutorial/tutorial.html)を読むことをお勧めします。 +前提条件として、Reactについて初心者レベルの理解をしている必要があります。 そうでない場合は、公式の[React入門チュートリアル](https://react.dev/learn)を完了することをお勧めします。 -### スターターファイルのクローン {#clone-the-starter-files} +### スターターファイルをクローンする {#clone-the-starter-files} -まず、このプロジェクトの開始ファイルを取得するために[「hello-world-part-four」GitHubリポジトリ](https://github.com/alchemyplatform/hello-world-part-four-tutorial)に行き、このリポジトリのクローンをローカルマシンに作成します。 +まず、[hello-world-part-four GitHubリポジトリ](https://github.com/alchemyplatform/hello-world-part-four-tutorial)にアクセスして、このプロジェクトのスターターファイルを取得し、このリポジトリをローカルマシンにクローンします。 -クローンしたリポジトリをローカルで開きます。 `starter-files`と`completed`の2つのフォルダが含まれています。 +クローンしたリポジトリをローカルで開きます。 `starter-files`と`completed`の2つのフォルダが含まれていることに注意してください。 -- `starter-files` - **このディレクトリで作業します**。UIをイーサリアムウォレットおよび[パート3](#part-3)でEtherscanに公開したスマートコントラクトに接続します。 +- `starter-files` - **このディレクトリで作業します**。UIをEthereumウォレットおよび[パート3](#part-3)でEtherscanに公開したスマートコントラクトに接続します。 - `completed`には、チュートリアル全体が完了したものが入っています。行き詰まった場合にのみ、参考として使ってください。 次に、`starter-files`のコピーをお気に入りのコードエディタで開き、`src`フォルダに移動します。 -これから作成するすべてのコードは、`src`フォルダに保存されます。 `HelloWorld.js`コンポーネントと JavaScriptファイルである`util/interact.js`を編集して、プロジェクトにWeb3の機能を追加していきます。 +私たちが書くコードはすべて`src`フォルダの下に置かれます。 `HelloWorld.js`コンポーネントと`util/interact.js`JavaScriptファイルを編集して、プロジェクトにWeb3機能を追加します。 -### スターターファイルの確認 {#check-out-the-starter-files} +### スターターファイルを確認する {#check-out-the-starter-files} コーディングを開始する前に、スターターファイルで提供されるものを探索してみましょう。 -#### Reactプロジェクトの実行 {#get-your-react-project-running} +#### Reactプロジェクトを実行する {#get-your-react-project-running} まずは、ブラウザでReactプロジェクトを実行しましょう。 Reactの素晴らしいところは、一度ブラウザでプロジェクトを実行すると、保存した変更がブラウザでも同時に更新されることです。 -プロジェクトを実行するには、次のようにターミナルで`starter-files`フォルダのルートディレクトリに移動し、`npm install`を実行してプロジェクトの依存関係をインストールします。 +プロジェクトを実行するには、`starter-files`フォルダのルートディレクトリに移動し、ターミナルで`npm install`を実行してプロジェクトの依存関係をインストールします。 ```bash cd starter-files npm install ``` -インストールが完了したら、ターミナルで`npm start`を実行します。 +インストールが完了したら、ターミナルで`npm start`を実行します: ```bash npm start ``` -これにより、ブラウザで[http://localhost:3000/](http://localhost:3000/)を開くと、プロジェクトのフロントエンドが表示されます。 これは、1つのフィールド \(スマートコントラクトに保存されているメッセージを更新する場所\) である「Connect Wallet」ボタン、および「Update」ボタンで構成されています。 +これにより、ブラウザで[http://localhost:3000/](http://localhost:3000/)が開かれ、プロジェクトのフロントエンドが表示されます。 これは、1つのフィールド \(スマートコントラクトに保存されているメッセージを更新する場所\)、「Connect Wallet」ボタン、および「Update」ボタンで構成されています。 -どちらのボタンをクリックしても、機能しないことがわかります。この機能をプログラムする必要があるためです。 +どちらのボタンをクリックしても機能しないことに気づくでしょう。これは、まだその機能をプログラムする必要があるためです。 #### `HelloWorld.js`コンポーネント {#the-helloworld-js-component} エディタの`src`フォルダに戻り、`HelloWorld.js`ファイルを開きましょう。 このファイルには、これから作業を進めていく主要なReactコンポーネントが含まれています。すべての内容を理解することが非常に重要です。 -このファイルの先頭には、いくつかの重要なステートメントがあるこに気が付くでしょう。Reactライブラリ、useEffectフックとuseStateフック、`./util/interact.js`のいくつかのアイテムなど、プロジェクトを実行するために必要になります (これらについては、すぐに詳しく説明します！) 。また、Alchemyのロゴがあります +このファイルの先頭には、プロジェクトを実行するために必要な、Reactライブラリ、useEffectフックとuseStateフック、`./util/interact.js`からのいくつかのアイテム (これらについては、すぐに詳しく説明します！)、そしてAlchemyのロゴなど、いくつかのimport文があることに気づくでしょう。 ```javascript // HelloWorld.js @@ -753,14 +756,14 @@ const [message, setMessage] = useState("No connection to the network.") const [newMessage, setNewMessage] = useState("") ``` -それぞれの変数は以下の用途で使われます。 +それぞれの変数は以下の内容を表します。 - `walletAddress` - ユーザーのウォレットアドレスを格納する文字列 -- `status` - ユーザーにdappの操作方法を案内する補助メッセージを文字列として格納する +- `status`- ユーザーにdappのインタラクト方法を案内する補助メッセージを格納する文字列 - `message` - スマートコントラクトの現在のメッセージを格納する文字列 - `newMessage` - スマートコントラクトに書き込まれる新しいメッセージを格納する文字列 -ステート変数の後に、`useEffect` 、`addSmartContractListener`、 `addWalletListener`、 `connectWalletPressed`、`onUpdatePressed`の未実装の5つの関数があります。 次に、それらが何をするのかを説明します。 +ステート変数の後に、`useEffect`、`addSmartContractListener`、`addWalletListener`、`connectWalletPressed`、`onUpdatePressed`の5つの未実装の関数があります。 次に、それらが何をするのかを説明します。 ```javascript // HelloWorld.js @@ -787,10 +790,10 @@ const onUpdatePressed = async () => { } ``` -- [`useEffect`](https://reactjs.org/docs/hooks-effect.html)- コンポーネントがレンダリングされた後に呼び出されるReactフックです。 空の配列`[]`のプロップが渡されているため \(4行目を参照\)、コンポーネントの_最初_のレンダリングでのみ呼び出されます。 ここでは、スマートコントラクトに保存されている現在のメッセージのロード、スマートコントラクトとウォレットリスナーの呼び出し、ウォレットが既に接続されているかどうかを反映してUIを更新するのに使います。 +- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html) - これは、コンポーネントがレンダリングされた後に呼び出されるReactフックです。 空の配列`[]`のプロップが渡されているため \(4行目を参照\)、コンポーネントの_最初の_レンダリングでのみ呼び出されます。 ここでは、スマートコントラクトに保存されている現在のメッセージをロードし、スマートコントラクトとウォレットリスナーを呼び出し、ウォレットが既に接続されているかどうかを反映してUIを更新します。 - `addSmartContractListener` - この関数では、HelloWorldコントラクトの`UpdatedMessages`イベントを監視し、スマートコントラクトでメッセージが変更されたときにUIを更新するリスナーを設定します。 - `addWalletListener` - この関数では、ユーザーがウォレットを切断したときやアドレスを切り替えたときなど、ユーザーのMetaMaskウォレットのステートの変化を検出するリスナーを設定します。 -- `connectWalletPressed` - この関数は、ユーザーのMetaMaskウォレットをdappに接続するのに呼び出されます。 +- `connectWalletPressed`- この関数は、ユーザーのMetaMaskウォレットをdappに接続するのに呼び出されます。 - `onUpdatePressed` - この関数は、ユーザーがスマートコントラクトに保存されているメッセージを更新したいときに呼び出されます。 このファイルの終盤には、コンポーネントのUIがあります。 @@ -830,32 +833,33 @@ return ( - - + + + ) ``` このコードを注意深く読むと、さまざまなステート変数がUIのどの場所で使用されているかがわかります。 -- 6～12行目では、ユーザーのウォレットが接続されている場合 \(すなわち、`walletAddress.length > 0`\)、 ID「walletButton;」に省略されたユーザーの`walletAddress`がボタンに表示されます。 それ以外の場合は、単に「Connect Wallet」と表示されます。 +- 6～12行目では、ユーザーのウォレットが接続されている場合 \(すなわち`walletAddress.length > 0`\)、ID「walletButton」のボタンに省略されたユーザーの`walletAddress`が表示されます。それ以外の場合は、単に「Connect Wallet」と表示されます。 - 17行目では、`message`文字列でキャプチャされたスマートコントラクトに保存されている現在のメッセージを表示します。 -- 23～26行目では、テキストフィールドの入力が変化したときに[制御コンポーネント](https://reactjs.org/docs/forms.html#controlled-components)を使用して `newMessage`ステート変数を更新します。 +- 23～26行目では、[制御されたコンポーネント](https://legacy.reactjs.org/docs/forms.html#controlled-components)を使用して、テキストフィールドの入力が変化したときに`newMessage`ステート変数を更新します。 -ステート変数に加えて、IDが`publishButton`と`walletButton`である、それぞれがクリックされると`connectWalletPressed`および`onUpdatePressed`関数が呼び出されることがわります。 +ステート変数に加えて、IDが`publishButton`と`walletButton`であるボタンがそれぞれクリックされると、`connectWalletPressed`および`onUpdatePressed`関数が呼び出されることがわかります。 最後に、この`HelloWorld.js`コンポーネントがどこに加えられるかについて説明します。 -他のすべてのコンポーネントのコンテナとして機能する、Reactのメインコンポーネントである`App.js`ファイルを表示すると、`HelloWorld.js`コンポーネントが7行目に挿入されていることが分かります。 +`App.js`ファイルは、他のすべてのコンポーネントのコンテナとして機能するReactのメインコンポーネントですが、このファイルを表示すると、`HelloWorld.js`コンポーネントが7行目に挿入されていることが分かります。 -最後の最後となりますが、提供されているもう1つのファイル、`interact.js`ファイルを確認してみましょう。 +最後に、提供されているもう1つのファイル、`interact.js`ファイルを確認してみましょう。 #### `interact.js`ファイル {#the-interact-js-file} -[M-V-C](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)のパラダイムを実践したいので、dappのロジック、データ、ルールを管理するすべての関数を含んだファイルを分割し、これらの関数をフロントエンド \(`HelloWorld.js`コンポーネント\) にエクスポートできるようにします。 +[M-V-C](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)パラダイムに従うため、dappのロジック、データ、ルールを管理するすべての関数を含む個別のファイルを作成し、それらの関数をフロントエンド \(私たちの`HelloWorld.js`コンポーネント\) にエクスポートできるようにします。 -👆🏽まさにこれが`interact.js`ファイルの目的です。 +👆🏽まさにこれが`interact.js`ファイルの目的です！ -`src`ディレクトリの`util`フォルダに移動すると、`interact.js`というファイルが含まれていることがわかります。これには、スマートコントラクトとのやり取り、ウォレット関数と変数が含まれています。 +`src`ディレクトリの`util`フォルダに移動すると、`interact.js`というファイルが含まれていることがわかります。これには、すべてのスマートコントラクトとのインタラクション、ウォレット関数、変数が含まれています。 ```javascript // interact.js @@ -875,35 +879,35 @@ export const updateMessage = async (message) => {} `helloWorldContract`オブジェクトの後の4つの未実装の関数は、次のことを行います。 -- `loadCurrentMessage` - この関数は、スマートコントラクトに保存されている現在のメッセージをロードするロジックを扱います。 [Alchemy Web3 API](https://github.com/alchemyplatform/alchemy-web3)を使ってHello Worldスマートコントラクトの_read_の呼び出しを行います。 -- `connectWallet` - この関数は、私たちのdappをユーザーのMetaMaskに接続します。 -- `getCurrentWalletConnected` - この関数は、ページの読み込み時にイーサリアムアカウントが既にdappに接続されているかどうかを確認し、それに応じてUIを更新します。 -- `updateMessage` - この関数は、スマートコントラクトに保存されているメッセージを更新します。 Hello Worldスマートコントラクトで_write_の呼び出しが行われるため、ユーザーのMetaMaskウォレットでは、メッセージを更新するためにイーサリアムトランザクションに署名する必要があります。 +- `loadCurrentMessage` - この関数は、スマートコントラクトに保存されている現在のメッセージをロードするロジックを扱います。 [Alchemy Web3 API](https://github.com/alchemyplatform/alchemy-web3)を使用して、Hello Worldスマートコントラクトへの_読み取り_呼び出しを行います。 +- `connectWallet` - この関数は、ユーザーのMetaMaskをdappに接続します。 +- `getCurrentWalletConnected` - この関数は、ページの読み込み時にEthereumアカウントが既にdappに接続されているかどうかを確認し、それに応じてUIを更新します。 +- `updateMessage` - この関数は、スマートコントラクトに保存されているメッセージを更新します。 Hello Worldスマートコントラクトで_書き込み_呼び出しが行われるため、ユーザーのMetaMaskウォレットでは、メッセージを更新するためにEthereumトランザクションに署名する必要があります。 何をするか理解したので、スマートコントラクトから読み取る方法を解明していきましょう。 -### ステップ3: スマートコントラクトからの読み込み {#step-3-read-from-your-smart-contract} +### ステップ3: スマートコントラクトから読み取る {#step-3-read-from-your-smart-contract} スマートコントラクトから読み取るには、次の設定を正しく行う必要があります。 -- イーサリアムチェーンへのAPI接続 -- あなたのスマートコントラクトがロードされたインスタンス +- EthereumチェーンへのAPI接続 +- スマートコントラクトのロードされたインスタンス - スマートコントラクトの関数を呼び出す関数 - スマートコントラクトから読み取っているデータが変更されたときの更新を監視するリスナー -手順がたくさんあるように感じますが、心配しないでください！ それぞれの方法を1つずつ説明していきます。 :\) +手順がたくさんあるように感じますが、心配しないでください！ それぞれの方法を1つずつ説明していきます。 :​) -#### イーサリアムチェーンへのAPI接続を確立する {#establish-an-api-connection-to-the-ethereum-chain} +#### EthereumチェーンへのAPI接続を確立する {#establish-an-api-connection-to-the-ethereum-chain} -チュートリアルのパート2で私たちは、[Alchemy Web3キーを使ってスマートコントラクトから読み込みました](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract/interacting-with-a-smart-contract#step-1-install-web3-library)。 チェーンから読み取るには、あなたのdappでAlchemy Web3キーがまた必要になります。 +このチュートリアルのパート2で、[Alchemy Web3キーを使用してスマートコントラクトから読み取った](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract/interacting-with-a-smart-contract#step-1-install-web3-library)ことを覚えていますか？ チェーンから読み取るには、dappでAlchemy Web3キーも必要になります。 -もしなければ、最初に、 `starter-files`のルートディレクトリへ移動して、次のコマンドをコンソールで実行して[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)をインストールしてください。 +まだインストールしていない場合は、まず`starter-files`のルートディレクトリに移動し、ターミナルで次のコマンドを実行して[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)をインストールしてください。 ```text npm install @alch/alchemy-web3 ``` -[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)は、[Web3.js](https://docs.web3js.org/)のラッパーであり、強化されたAPIメソッドや重要なメリットを提供し、Web3デベロッパーの負担を軽減します。 最小限の設定で使えるように設計されているので、アプリですぐに使用可能です。 +[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)は[Web3.js](https://docs.web3js.org/)のラッパーであり、強化されたAPIメソッドやその他の重要なメリットを提供し、web3開発者としての作業を容易にします。 最小限の設定で使えるように設計されているので、アプリですぐに使用可能です。 次に、[dotenv](https://www.npmjs.com/package/dotenv)パッケージをプロジェクトディレクトリにインストールします。これにより、APIキーを取得した後に安全な場所に保管できるようになります。 @@ -911,15 +915,15 @@ npm install @alch/alchemy-web3 npm install dotenv --save ``` -dappでは、HTTP API キーの代わりに**Websockets APIキー**を使用します。これにより、スマートコントラクトに保存されたメッセージが変更されたときに検出するリスナーを設定できます。 +dappでは、HTTP APIキーの代わりに**Websockets APIキーを使用します**。これにより、スマートコントラクトに保存されたメッセージが変更されたときに検出するリスナーを設定できます。 -APIキーを取得したら、ルートディレクトリに `.env`ファイルを作成し、Alchemy Websocketsの URLを.envファイルに加えます。 `.env`ファイルは次のようになります。 +APIキーを取得したら、ルートディレクトリに `.env`ファイルを作成し、Alchemy Websocketsの URLをそのファイルに追加します。 その後、`.env`ファイルは次のようになります。 ```javascript REACT_APP_ALCHEMY_KEY = wss://eth-goerli.ws.alchemyapi.io/v2/ ``` -これで、私たちのdappにAlchemy Web3エンドポイントを設定する準備が整いました。 `util`フォルダー内に入っている`interact.js`に戻り、ファイルの先頭に次のコードを加えてください。 +これで、dappにAlchemy Web3エンドポイントを設定する準備が整いました。 `util`フォルダー内に入っている`interact.js`に戻り、ファイルの先頭に次のコードを加えてください。 ```javascript // interact.js @@ -932,23 +936,23 @@ const web3 = createAlchemyWeb3(alchemyKey) //export const helloWorldContract; ``` -上記のコードでは、まず`.env`ファイルから Alchemyキーをインポートし、次に`alchemyKey`を`createAlchemyWeb3`に渡してAlchemy Web3エンドポイントへ確立しています。 +上記のコードでは、まず`.env`ファイルから Alchemyキーをインポートし、次に`alchemyKey`を`createAlchemyWeb3`に渡してAlchemy Web3エンドポイントを確立しています。 エンドポイントの準備できたので、スマートコントラクトをロードするときです！ #### Hello Worldスマートコントラクトをロードする {#loading-your-hello-world-smart-contract} -Hello Worldスマートコントラクトをロードするには、そのコントラクトアドレスとABIが必要です。[このチュートリアルのパート3](/developers/tutorials/hello-world-smart-contract-fullstack/#part-3-publish-your-smart-contract-to-etherscan-part-3-publish-your-smart-contract-to-etherscan)を終了していれば、両方ともEtherscanから入手できます。 +Hello Worldスマートコントラクトをロードするには、そのコントラクトアドレスとABIが必要です。これらは、[このチュートリアルのパート3](/developers/tutorials/hello-world-smart-contract-fullstack/#part-3-publish-your-smart-contract-to-etherscan-part-3-publish-your-smart-contract-to-etherscan)を完了していれば、Etherscanで見つけることができます。 -#### EtherscanからコントラクトABIを入手する方法 {#how-to-get-your-contract-abi-from-etherscan} +#### EtherscanからコントラクトABIを取得する方法 {#how-to-get-your-contract-abi-from-etherscan} -このチュートリアルのパート3を飛ばした場合は、アドレス[0x6f3f635A9762B47954229Ea479b4541eAF402A6A](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code)にあるHelloWorldコントラクトを使ってください。 ABIは、[こちら](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code)にあります。 +このチュートリアルのパート3を飛ばした場合は、アドレス[0x6f3f635A9762B47954229Ea479b4541eAF402A6A](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code)のHelloWorldコントラクトを使用できます。 そのABIは[こちら](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code)で見つけることができます。 -コントラクトのABIは、コントラクトが呼び出す関数を指定し、関数が確実に意図しているフォーマットでデータを返すようにするために必要です。 コントラクトABIをコピーしたら、それを`contract-abi.json`という名前のJSONファイルとして`src`ディレクトリに保存しましょう。 +コントラクトのABIは、コントラクトが呼び出す関数を指定し、関数が期待するフォーマットでデータを確実に返すようにするために必要です。 コントラクトABIをコピーしたら、それを`contract-abi.json`という名前のJSONファイルとして`src`ディレクトリに保存しましょう。 contract-abi.jsonは、srcフォルダーに格納されている必要があります。 -コントラクトアドレス、ABI、Alchemy Web3エンドポイントを用意することで、[コントラクトメソッド](https://docs.web3js.org/api/web3-eth-contract/class/Contract)を使ってスマートコントラクトのインスタンスをロードすることができます。 コントラクトABIを`interact.js`ファイルにインポートし、コントラクトアドレスを加えます。 +コントラクトアドレス、ABI、Alchemy Web3エンドポイントを用意したので、[contractメソッド](https://docs.web3js.org/api/web3-eth-contract/class/Contract)を使ってスマートコントラクトのインスタンスをロードすることができます。 コントラクトABIを`interact.js`ファイルにインポートし、コントラクトアドレスを加えます。 ```javascript // interact.js @@ -986,11 +990,11 @@ export const helloWorldContract = new web3.eth.Contract( ) ``` -私たちのコントラクトがロードされたので、`loadCurrentMessage`関数を実装できます！ +コントラクトがロードされたので、`loadCurrentMessage`関数を実装できます！ #### `interact.js`ファイルに`loadCurrentMessage`を実装する {#implementing-loadCurrentMessage-in-your-interact-js-file} -これは非常にシンプルな関数です。 私たちのコントラクトから読み取るのに、単純な非同期のWeb3の呼び出しを作成します。 この関数では、スマートコントラクトに保存されているメッセージを返します。 +これは非常にシンプルな関数です。 コントラクトから読み取るために、単純な非同期のweb3呼び出しを作成します。 この関数では、スマートコントラクトに保存されているメッセージを返します。 `interact.js`ファイルの `loadCurrentMessage`を次のように更新してください。 @@ -1015,48 +1019,48 @@ useEffect(async () => { }, []) ``` -`loadCurrentMessage`は、コンポーネントの最初のレンダリングで1回だけ呼び出されることに注目してください。 この後、`addSmartContractListener`を実装して、スマートコントラクト内のメッセージが変更された後にUIを自動的に更新できるようにします。 +注: `loadCurrentMessage`は、コンポーネントの最初のレンダリング時に1回だけ呼び出されるようにします。 この後、`addSmartContractListener`を実装して、スマートコントラクト内のメッセージが変更された後にUIを自動的に更新できるようにします。 -リスナーについて詳しく説明する前に、これまでの内容を確認してみましょう！ `HelloWorld.js`ファイルと`interact.js`ファイルを保存し、[http://localhost: 3000/](http://localhost:3000/)へアクセスしてください。 +リスナーについて詳しく説明する前に、これまでの内容を確認してみましょう！ `HelloWorld.js`ファイルと`interact.js`ファイルを保存し、[http://localhost:3000/](http://localhost:3000/)にアクセスしてください。 -現在、「ネットワークに接続されていません」というメッセージが表示されなくなっていることがわかります。 代わりに、スマート コントラクトに保存されているメッセージが反映されます。 カッコイイ！ +現在、「ネットワークに接続されていません」というメッセージが表示されなくなっていることがわかります。 代わりに、スマートコントラクトに保存されているメッセージが反映されます。 カッコイイ！ -#### 今や、UIにスマートコントラクトに保存されたメッセージが反映されるようになりました。 {#your-UI-should-now-reflect-the-message-stored-in-the-smart-contract} +#### UIにスマートコントラクトに保存されたメッセージが反映されるはずです {#your-UI-should-now-reflect-the-message-stored-in-the-smart-contract} それでは、リスナーについて説明していきます。 #### `addSmartContractListener`を実装する {#implement-addsmartcontractlistener} -[このチュートリアルのパート1](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract#step-10-write-our-contract)で記述した`HelloWorld.sol`ファイルについて振り返ると、`UpdatedMessages`というスマートコントラクトのイベントがあったと思います。このイベントは、スマートコントラクトの`update`関数が呼び出された後に発行されます \(9 行目と27行目を参照\)。 +このチュートリアルシリーズの[パート1で作成した`HelloWorld.sol`ファイル](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract#step-10-write-our-contract)を思い出すと、スマートコントラクトの`update`関数が呼び出された後に`UpdatedMessages`というスマートコントラクトイベントが発行されることを思い出すでしょう（9行目と27行目を参照）。 ```javascript // HelloWorld.sol -// Specifies the version of Solidity, using semantic versioning. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// Solidityのバージョンをセマンティックバージョニングで指定します。 +// 詳細: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity ^0.7.3; -// Defines a contract named `HelloWorld`. -// A contract is a collection of functions and data (its state). Once deployed, a contract resides at a specific address on the Ethereum blockchain. Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// `HelloWorld` という名前のコントラクトを定義します。 +// コントラクトは関数とデータ (その状態) の集合です。一度デプロイされると、コントラクトはEthereumブロックチェーン上の特定のアドレスに存在します。詳細: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html contract HelloWorld { - //Emitted when update function is called - //Smart contract events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. + // update関数が呼び出されたときに発行されます + //スマートコントラクトのイベントは、ブロックチェーン上で何かが起こったことをコントラクトがアプリのフロントエンドに伝える方法です。フロントエンドは特定のイベントを「リッスン」し、それが起こったときに行動を起こすことができます。 event UpdatedMessages(string oldStr, string newStr); - // Declares a state variable `message` of type `string`. - // State variables are variables whose values are permanently stored in contract storage. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value. + // `string` 型の状態変数 `message` を宣言します。 + // 状態変数は、その値がコントラクトのストレージに永続的に保存される変数です。`public` キーワードにより、変数はコントラクトの外部からアクセス可能になり、他のコントラクトやクライアントが値をアクセスするために呼び出せる関数が作成されます。 string public message; - // Similar to many class-based object-oriented languages, a constructor is a special function that is only executed upon contract creation. - // Constructors are used to initialize the contract's data. Learn more:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // 多くのクラスベースのオブジェクト指向言語と同様に、コンストラクタはコントラクト作成時に一度だけ実行される特別な関数です。 + // コンストラクタはコントラクトのデータを初期化するために使用されます。詳細:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors constructor(string memory initMessage) { - // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable). + // 文字列引数 `initMessage` を受け取り、その値をコントラクトの `message` ストレージ変数に設定します)。 message = initMessage; } - // A public function that accepts a string argument and updates the `message` storage variable. + // 文字列引数を受け取り、 `message` ストレージ変数を更新する公開関数です。 function update(string memory newMessage) public { string memory oldMsg = message; message = newMessage; @@ -1065,9 +1069,9 @@ contract HelloWorld { } ``` -スマートコントラクトイベントは、ブロックチェーンで何かが起こったこと \(すなわち、_イベント_の発生 \) をフロントエンドアプリケーションに伝える方法です。特定のイベントを「リスニング」して、それが起きた時にアクションを実行します。 +スマートコントラクトイベントは、ブロックチェーンで何かが起こったこと \(すなわち、_イベント_の発生\) をフロントエンドアプリケーションに伝える方法です。フロントエンドは特定のイベントを「リスニング」して、それが起きた時にアクションを実行します。 -具体的には、`addSmartContractListener`関数がHello Worldスマートコントラクトの`UpdatedMessages`イベントをリッスンしており、新しいメッセージを表示するようにUIの更新をします。 +`addSmartContractListener`関数は、具体的にはHello Worldスマートコントラクトの`UpdatedMessages`イベントをリッスンし、新しいメッセージを表示するようにUIを更新します。 `addSmartContractListener`を次のように変更します。 @@ -1081,7 +1085,7 @@ function addSmartContractListener() { } else { setMessage(data.returnValues[1]) setNewMessage("") - setStatus("🎉 Your message has been updated!") + setStatus("🎉 メッセージが更新されました！") } }) } @@ -1089,10 +1093,10 @@ function addSmartContractListener() { リスナーがイベントを検出したときに何が起こるかを詳しく解説します。 -- イベントの発行時にエラーが発生した場合、そのエラーは`status`ステート変数を介してUIに反映する。 -- それ以外の場合は、返された`data`オブジェクトを使う。 `data.returnValues`は、配列にある最初のエレメントがインデックスの0に格納されている配列です。配列の最初のエレメントには前のメッセージが格納され、2番目のエレメントには更新されたメッセージが格納されます。 つまり、イベントが成功すると、`message`文字列を更新されたメッセージに設定し、`newMessage`文字列をクリアし、`status`ステート変数を更新します。 これにより、新しいメッセージがスマートコントラクトに公開されたことを反映しています。 +- イベントの発行時にエラーが発生した場合、そのエラーは`status`ステート変数を介してUIに反映されます。 +- それ以外の場合は、返された`data`オブジェクトを使います。 `data.returnValues`は、0からインデックス付けされた配列で、配列の最初の要素には前のメッセージが格納され、2番目の要素には更新されたメッセージが格納されます。 つまり、イベントが成功すると、`message`文字列を更新されたメッセージに設定し、`newMessage`文字列をクリアし、`status`ステート変数を更新して、新しいメッセージがスマートコントラクトに公開されたことを反映させます。 -最後に、`useEffect`関数でリスナーを呼び出して、`HelloWorld.js`コンポーネントの最初のレンダリング時にリスナーが初期化されるようにしましょう。 あなたの`useEffect`関数全体は、次のようになります。 +最後に、`useEffect`関数でリスナーを呼び出して、`HelloWorld.js`コンポーネントの最初のレンダリング時にリスナーが初期化されるようにしましょう。 全体として、`useEffect`関数は次のようになります。 ```javascript // HelloWorld.js @@ -1104,43 +1108,43 @@ useEffect(async () => { }, []) ``` -スマートコントラクトから読み取れるようになったので、スマートコントラクトに書き込む方法も理解できるとなおよいでしょう！ ただし、dappに書き込むには、まずイーサリアムウォレットをdappに接続する必要があります。 +スマートコントラクトから読み取れるようになったので、スマートコントラクトに書き込む方法も理解できると素晴らしいですね！ ただし、dappに書き込むには、まずEthereumウォレットをdappに接続する必要があります。 -それでは、次にイーサリアムウォレット \(MetaMask\) を設定し、それをdappに接続することに取り組んでいきましょう！ +それでは、次にEthereumウォレット \(MetaMask\) を設定し、それをdappに接続することに取り組みましょう！ -### ステップ4: イーサリアムウォレットのセットアップ {#step-4-set-up-your-ethereum-wallet} +### ステップ4: Ethereumウォレットを設定する {#step-4-set-up-your-ethereum-wallet} -イーサリアムチェーンに何かを書き込むには、ユーザーは仮想ウォレットの秘密鍵を使ってトランザクションに署名しなければなりません。 このチュートリアルでは、イーサリアムアカウントアドレスの管理に使用されるブラウザの仮想ウォレットである[MetaMask](https://metamask.io/)を使用します。これにより、エンドユーザーは、このランザクションの署名がとても簡単になります。 +Ethereumチェーンに何かを書き込むには、ユーザーは仮想ウォレットの秘密鍵を使ってトランザクションに署名しなければなりません。 このチュートリアルでは、Ethereumアカウントアドレスの管理に使用されるブラウザの仮想ウォレットである[MetaMask](https://metamask.io/)を使用します。これにより、エンドユーザーは、このトランザクションの署名が非常に簡単になります。 -イーサリアムのトランザクションの仕組みの詳細については、イーサリアム・ファウンデーションの[こちらのページ](/developers/docs/transactions/)をご覧ください。 +イーサリアム上のトランザクションの仕組みについてさらに詳しく知りたい場合は、イーサリアム・ファウンデーションの[こちらのページ](/developers/docs/transactions/)をご覧ください。 -#### MetaMaskをダウンロード {#download-metamask} +#### MetaMaskをダウンロードする {#download-metamask} -Metamaskのアカウントは[こちら](https://metamask.io/download)から無料でダウンロード、作成できます。 アカウントを作成後、またはすでにアカウントをお持ちの場合は\( 実際に支払いが発生しないように \)右上の「Goerli Test Network」に切り替えてください。 +MetaMaskアカウントは、[こちら](https://metamask.io/download)から無料でダウンロードして作成できます。 アカウントを作成するとき、またはすでにアカウントをお持ちの場合は、右上の「Goerli Test Network」に必ず切り替えてください \(実在の通貨を扱わないようにするため\)。 -#### フォーセットからイーサ(ETH)を追加 {#add-ether-from-a-faucet} +#### フォーセットからetherを追加する {#add-ether-from-a-faucet} -イーサリアムブロックチェーンでトランザクションに署名するには、偽のETHが必要になります。 ETHを取得するには、 [FaucETH](https://fauceth.komputing.org)にアクセスしてGoerliアカウントアドレスを入力し、「Request funds」をクリックしてください。 そしてドロップダウンで「Ethereum Testnet Goerli」を選択し、最後に「Request funds」ボタンを再度クリックします。 MetamaskアカウントにETHが表示されるはずです。 +Ethereumブロックチェーンでトランザクションに署名するには、偽のEthが必要です。 Ethを取得するには、[FaucETH](https://fauceth.komputing.org)にアクセスしてGoerliアカウントアドレスを入力し、「Request funds」をクリックし、ドロップダウンで「Ethereum Testnet Goerli」を選択し、最後に「Request funds」ボタンを再度クリックします。 MetamaskアカウントにETHが表示されるはずです。 -#### 残高の確認 {#check-your-balance} +#### 残高を確認する {#check-your-balance} -残高を再確認するために、[Alchemyのコンポーザーツール](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)を使用して[eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)をリクエストしてみましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 Metamaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 +残高を確認するために、[Alchemyのcomposerツール](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)を使用して[eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)リクエストを行いましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 MetaMaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 ```text {"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"} ``` -**注:** この結果の単位は、ETHではなくweiです。 weiはETHの最小単位として使われています。 weiからETHへ変換すると、1 eth = 10¹⁸ weiになります。 つまり、0xde0b6b3a7640000を10進数に変換すると、1\*10¹⁸となり、1 ETHに相当します。 +**注:** この結果はethではなくwei単位です。 weiはETHの最小単位として使われています。 weiからETHへ変換すると、1 eth = 10¹⁸ weiになります。 つまり、0xde0b6b3a7640000を10進数に変換すると、1\*10¹⁸となり、1 ETHに相当します。 -ご安心ください。 これで、偽のお金を手に入れました。 🤑 +ふう! これで、偽のお金を手に入れました。 🤑 -### ステップ5: メタマスクをUIへ接続する {#step-5-connect-metamask-to-your-UI} +### ステップ5: MetaMaskをUIに接続する {#step-5-connect-metamask-to-your-UI} MetaMaskウォレットが設定されたので、分散型アプリケーション(Dapp)を接続しましょう。 #### `connectWallet`関数 {#the-connectWallet-function} -`interact.js`ファイルの`connectWallet`関数を実装します。この関数は、`HelloWorld.js`コンポーネントで呼び出します。 +`interact.js`ファイルで`connectWallet`関数を実装します。この関数は、`HelloWorld.js`コンポーネントで呼び出します。 `connectWallet`を次のように変更しましょう。 @@ -1154,7 +1158,7 @@ export const connectWallet = async () => { method: "eth_requestAccounts", }) const obj = { - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 上のテキストフィールドにメッセージを書き込んでください。", address: addressArray[0], } return obj @@ -1172,8 +1176,7 @@ export const connectWallet = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + ブラウザに仮想EthereumウォレットであるMetaMaskをインストールする必要があります。

@@ -1187,20 +1190,20 @@ export const connectWallet = async () => { まず、ブラウザで`window.ethereum`が有効になっているかどうかをチェックしています。 -`window.ethereum`は、MetaMaskおよび他のウォレットプロバイダーによって挿入されるグローバルAPIであり、ウェブサイトがユーザーのイーサリアムアカウントを要求できるようにするものです。 承認されると、ユーザーが接続しているブロックチェーンからデータを読み取ったり、メッセージやトランザクションへの署名をユーザーに提案したりできるようになります。 詳細については、[MetaMaskのドキュメント](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)を参照してください。 +`window.ethereum`は、MetaMaskやその他のウォレットプロバイダーによって挿入されるグローバルAPIで、WebサイトがユーザーのEthereumアカウントを要求できるようにするものです。 承認されると、ユーザーが接続しているブロックチェーンからデータを読み取ったり、メッセージやトランザクションへの署名をユーザーに提案したりできるようになります。 詳細については[MetaMaskのドキュメント](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)をご覧ください。 -`window.ethereum`が_存在しない_場合は、MeTaMaskがインストールされていないことを意味します。 その結果、空の文字列に設定された、返される`address`と、ユーザーがMetaMaskをインストールする必要があることを伝える`status`JSXオブジェクトが入ったJSONオブジェクトが返されます。 +`window.ethereum`が_存在しない_場合、それはMetaMaskがインストールされていないことを意味します。 これにより、返される`address`が空の文字列で、`status` JSXオブジェクトがユーザーにMetaMaskをインストールするよう促すJSONオブジェクトが返されます。 -`window.ethereum`が_存在_する場合、興味深いことが起こります。 +さて、`window.ethereum`が_存在する_場合、ここからが面白くなります。 -try/catch ループを使用して、[`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts)を呼び出すことでMetaMaskに接続しようとしています。 この関数を呼び出すと、ブラウザでMetaMaskが開き、ユーザーはウォレットを分散型アプリケーション(Dapp)に接続するように求められます。 +try/catchループを使用して、[`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts)を呼び出してMetaMaskへの接続を試みます。 この関数を呼び出すと、ブラウザでMetaMaskが開き、ユーザーはウォレットを分散型アプリケーション(Dapp)に接続するように求められます。 -- ユーザーが接続を選んだ場合、`method: "eth_requestAccounts"`は、分散型アプリケーション(Dapp)に接続されているすべてのユーザーのアカウントアドレスを含む配列を返します。 `connectWallet`関数は、配列内の_最初の_`address`と\(9 行目参照\)、ユーザーにスマートコントラクトにメッセージを書き込むように促す`status`メッセージが入ったJSONオブジェクトを返します。 -- ユーザーが接続を拒否した場合、JSONオブジェクトには、返される`address`に入る空の文字列と、ユーザーが接続を拒否したことを示す`status`メッセージが入ることになります。 +- ユーザーが接続を選んだ場合、`method: "eth_requestAccounts"`は、dappに接続されているすべてのユーザーのアカウントアドレスを含む配列を返します。 まとめると、`connectWallet`関数は、この配列の_最初の_`address`（9行目参照）と、ユーザーにスマートコントラクトへのメッセージを書き込むよう促す`status`メッセージを含むJSONオブジェクトを返します。 +- ユーザーが接続を拒否した場合、JSONオブジェクトには返される`address`の空文字列と、ユーザーが接続を拒否したことを示す`status`メッセージが含まれます。 これで、`connectWallet`関数を作成できたので、次のステップでは、この関数を`HelloWorld.js`コンポーネントに呼び出します。 -#### `connect Wallet`関数を`Hello World.js`UIコンポーネントに加える {#add-the-connectWallet-function-to-your-HelloWorld-js-ui-component} +#### `connectWallet`関数を`HelloWorld.js`UIコンポーネントに追加する {#add-the-connectWallet-function-to-your-HelloWorld-js-ui-component} `HelloWorld.js`にある `connectWalletPressed`関数に移動し、次のように更新します。 @@ -1216,19 +1219,19 @@ const connectWalletPressed = async () => { `interact.js`ファイルによって、機能の大部分が`HelloWorld.js`コンポーネントからどのように抽象化されているかに注目してください。 これは、モデルビューコントローラ(M-V-C)パラダイムに準拠しているためです。 -`connectWalletPressed`では、単にインポートされた`connectWallet`関数のawait呼び出しを行っています。さらに、そのレスポンスを使用し、`status`と`walletAddress`変数を状態フックを介して更新しています。 +`connectWalletPressed`では、インポートした`connectWallet`関数をawaitで呼び出し、そのレスポンスを使って状態フックを介して`status`と`walletAddress`変数を更新します。 それでは、両方のファイル \(`HelloWorld.js`と`interact.js`\) を保存して、これまでのUIをテストしてみましょう。 -[http://localhost:3000/](http://localhost:3000/)でブラウザを開き、ページ右上にある「Connect Wallet」ボタンを押します。 +[http://localhost:3000/](http://localhost:3000/)ページでブラウザを開き、ページ右上にある「Connect Wallet」ボタンを押します。 MetaMaskがインストールされている場合は、ウォレットを分散型アプリケーション(Dapp)に接続するように求められます。 接続リクエストを承認します。 -ウォレットボタンに、接続した自分のアドレスが表示されているはずです。 やりましたね🔥 +ウォレットボタンに、接続した自分のアドレスが表示されているはずです！ やった！🔥 -次に、ページを更新してみてください。変ですね。 ウォレットボタンによって、すでに接続しているにもかかわらずMetaMaskに接続するよう求められます。 +次に、ページを再読み込みしてみてください... これは奇妙です。 ウォレットボタンによって、すでに接続しているにもかかわらずMetaMaskに接続するよう求められます。 -しかし、恐れるに足りません。 `getCurrentWalletConnected`を実装することで、簡単にこれを修正できます。この関数は、アドレスが分散型アプリケーション(Dapp) にすでに接続されているかどうかを確認し、それに応じてUIを更新します。 +しかし、恐れることはありません！ これを簡単に修正できます（分かりましたか？） `getCurrentWalletConnected`を実装することで、アドレスがすでにdappに接続されているかどうかを確認し、それに応じてUIを更新できます！ #### `getCurrentWalletConnected`関数 {#the-getcurrentwalletconnected-function} @@ -1246,12 +1249,12 @@ export const getCurrentWalletConnected = async () => { if (addressArray.length > 0) { return { address: addressArray[0], - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 上のテキストフィールドにメッセージを書き込んでください。", } } else { return { address: "", - status: "🦊 Connect to MetaMask using the top right button.", + status: "🦊 右上のボタンを使ってMetaMaskに接続してください。", } } } catch (err) { @@ -1268,8 +1271,7 @@ export const getCurrentWalletConnected = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + ブラウザに仮想EthereumウォレットであるMetaMaskをインストールする必要があります。

@@ -1279,9 +1281,9 @@ export const getCurrentWalletConnected = async () => { } ``` -このコードは、前述の`connectWallet`関数に_非常に_似ています。 +このコードは、前のステップで作成した`connectWallet`関数に非常に似ています。 -主な違いとしては、ユーザーがウォレットに接続するためにMetaMaskを開く`eth_requestAccounts`メソッドを呼び出す代わりに、 ここでは`eth_accounts`メソッドを呼び出しています。これは、現在、分散型アプリケーション(Dapp)に接続されているMetaMaskのアドレスを含む配列を単に返すだけです。 +主な違いは、ユーザーがウォレットを接続するためにMetaMaskを開く`eth_requestAccounts`メソッドを呼び出す代わりに、ここでは`eth_accounts`メソッドを呼び出している点です。これは、現在dappに接続されているMetaMaskのアドレスを含む配列を単に返すだけです。 この関数を動作させるため、`HelloWorld.js`コンポーネントの`useEffect`関数で呼び出しましょう。 @@ -1299,13 +1301,13 @@ useEffect(async () => { }, []) ``` -`walletAddress`状態変数と`status`状態変数を更新するのに、呼び出した`getCurrentWalletConnected`のレスポンスを使用していることに注目してください。 +`walletAddress`と`status`の状態変数を更新するのに、`getCurrentWalletConnected`の呼び出しのレスポンスを使用していることに注目してください。 このコードを加えたら、ブラウザウィンドウを更新してみてください。 素晴らしい！ リフレッシュ後も、ボタンには接続されていることが示されており、接続されたウォレットのアドレスのプレビューが表示されているはずです。 -#### `addWalletListener`の実装 {#implement-addwalletlistener} +#### `addWalletListener`を実装する {#implement-addwalletlistener} 分散型アプリケーション(Dapp)ウォレットの設定の最終ステップは、ウォレットリスナーを実装することです。これにより、ユーザーが接続を切断したり、アカウントを切り替えたりした場合など、ウォレットの状態が変更されたときにUIが更新されます。 @@ -1319,10 +1321,10 @@ function addWalletListener() { window.ethereum.on("accountsChanged", (accounts) => { if (accounts.length > 0) { setWallet(accounts[0]) - setStatus("👆🏽 Write a message in the text-field above.") + setStatus("👆🏽 上のテキストフィールドにメッセージを書き込んでください。") } else { setWallet("") - setStatus("🦊 Connect to MetaMask using the top right button.") + setStatus("🦊 右上のボタンを使ってMetaMaskに接続してください。") } }) } else { @@ -1330,7 +1332,7 @@ function addWalletListener() {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your browser. + ブラウザに仮想EthereumウォレットであるMetaMaskをインストールする必要があります。

) @@ -1338,11 +1340,11 @@ function addWalletListener() { } ``` -この時点で何が起こっているかを理解するのに私たちの助けは必要ないと思いますが、完璧な理解を目指しているので簡単に説明します。 +この時点で何が起こっているかを理解するのに私たちの助けは必要ないと思いますが、念のため、簡単に説明します。 -- まず、ブラウザで`window.ethereum`が有効になっているか\(すなわち MetaMaskがインストールされているか\)を関数がチェックしています。 - - 有効になっていない場合、ユーザーにMetaMaskのインストールを求めるJSX文字列を`status`状態変数に設定します。 - - 有効になっている場合、MetaMaskウォレットの状態変更をリッスンしている3行目の`window.ethereum.on("accountsChanged")`リスナーを設定します。この状態変更には、ユーザーが追加のアカウントを分散型アプリケーション(Dapp)に接続した場合、アカウントを切り替えた場合、アカウントを切断した場合が含まれます。 少なくとも1つのアカウントが接続されていれば、`accounts`配列の最初のアカウントがリスナーから返されたときに、`walletAddress`状態変数が更新されます。 それ以外の場合は、`walletAddress`に空の文字列が設定されます。 +- まず、この関数は`window.ethereum`が有効になっているか（つまり、MetaMaskがインストールされているか）をチェックします。 + - 有効でない場合、`status`状態変数を、ユーザーにMetaMaskのインストールを促すJSX文字列に設定するだけです。 + - 有効になっている場合、3行目のリスナー`window.ethereum.on("accountsChanged")`を設定します。これはMetaMaskウォレットの状態変更をリッスンします。これには、ユーザーがdappに追加のアカウントを接続した場合、アカウントを切り替えた場合、アカウントを切断した場合が含まれます。 少なくとも1つのアカウントが接続されていれば、`walletAddress`状態変数は、リスナーから返された`accounts`配列の最初のアカウントとして更新されます。 それ以外の場合、`walletAddress`には空の文字列が設定されます。 最後に、`useEffect`関数で次のように呼び出す必要があります。 @@ -1364,21 +1366,21 @@ useEffect(async () => { 完成です！ ウォレットのすべての機能をプログラミングしました。 次は最後のタスクです。スマートコントラクトに保存されているメッセージを更新します。 -### ステップ6: `updateMessage`関数の実装する {#step-6-implement-the-updateMessage-function} +### ステップ6: `updateMessage`関数を実装する {#step-6-implement-the-updateMessage-function} -友よ！最終段階にたどり着きました。 `interact.js`ファイルの`updateMessage`で、次のことを実行します。 +さあ、最終段階にたどり着きました。 `interact.js`ファイルの`updateMessage`で、次のことを実行します。 -1. スマートコンタクトに公開したいメッセージが有効であることを確認する。 +1. スマートコントラクトに公開したいメッセージが有効であることを確認する。 2. MetaMaskを使用してトランザクションに署名する 3. `HelloWorld.js`フロントエンドコンポーネントでこの関数を呼び出す。 -これには、それほど時間を要しません。dappを完成させましょう！ +これには、それほど時間はかかりません。dappを完成させましょう！ #### 入力エラー処理 {#input-error-handling} 当然ながら、関数の開始時に何らかの入力エラー処理を行うことは理にかなっています。 -MetaMaskエクステンションがインストールされていない場合や接続されているウォレットがない場合 \(つまり、渡された `address`が空の文字列\) 、 `message`は空の文字列になります。 次のエラー処理を`updateMessage`に追加しましょう。 +MetaMaskエクステンションがインストールされていない場合、接続されているウォレットがない場合 \(つまり、渡された `address`が空の文字列の場合\) 、または`message`が空の文字列の場合は、関数が早期にリターンするようにします。 次のエラー処理を`updateMessage`に追加しましょう。 ```javascript // interact.js @@ -1387,13 +1389,13 @@ export const updateMessage = async (address, message) => { if (!window.ethereum || address === null) { return { status: - "💡 Connect your MetaMask wallet to update the message on the blockchain.", + "💡 ブロックチェーン上のメッセージを更新するには、MetaMaskウォレットを接続してください。", } } if (message.trim() === "") { return { - status: "❌ Your message cannot be an empty string.", + status: "❌ メッセージを空の文字列にすることはできません。", } } } @@ -1401,21 +1403,21 @@ export const updateMessage = async (address, message) => { 入力エラーを適切に処理できるようなりました。それでは、MetaMaskを介してトランザクションに署名をします。 -#### トランザクションへ署名する {#signing-our-transaction} +#### トランザクションに署名する {#signing-our-transaction} -従来のWeb3イーサリアムトランザクションにすでに慣れている場合は、次に記述するコードは非常に馴染みのあるものになるでしょう。 入力エラー処理コードの下に、次の`updateMessage`を加えます。 +従来のweb3 Ethereumトランザクションにすでに慣れている場合は、次に記述するコードは非常に馴染みのあるものになるでしょう。 入力エラー処理コードの下に、次の`updateMessage`を加えます。 ```javascript // interact.js -//set up transaction parameters +//トランザクションパラメータを設定する const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: address, // must match user's active address. + to: contractAddress, // コントラクト公開時以外は必須。 + from: address, // ユーザーのアクティブなアドレスと一致する必要がある。 data: helloWorldContract.methods.update(message).encodeABI(), } -//sign the transaction +//トランザクションに署名する try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -1426,11 +1428,10 @@ try { ✅{" "} - View the status of your transaction on Etherscan! + Etherscanでトランザクションのステータスを表示してください！
- ℹ️ Once the transaction is verified by the network, the message will be - updated automatically. + ℹ️ トランザクションがネットワークによって検証されると、メッセージは自動的に更新されます。 ), } @@ -1443,45 +1444,45 @@ try { 何をしているか、説明していきましょう。 まず、次のようにトランザクションパラメータを設定します。 -- `to`に受取人のアドレス\(スマートコントラクト\)を設定します 。 -- `from`では、関数に渡した`address`変数であるトランザクションの署名者を指定します。 -- `data`には、Hello Worldスマートコントラクトの `update`メソッドへの呼び出しが含まれており、`message`文字列変数を入力として受け取っています。 +- `to`は受信者アドレス（スマートコントラクト）を指定します +- `from`はトランザクションの署名者を指定します。これは関数に渡した`address`変数です。 +- `data`には、Hello Worldスマートコントラクトの`update`メソッドへの呼び出しが含まれており、`message`文字列変数を入力として受け取っています。 -次に、`window.ethereum.request`をawaitで呼び出して、MetaMaskにトランザクションの署名を依頼します。 11行目と12行目で、ethメソッド `eth_sendTransaction`を指定し、`transactionParameters`を渡していることに注目してください。 +次に、`window.ethereum.request`をawaitで呼び出して、MetaMaskにトランザクションの署名を依頼します。 11行目と12行目で、ethメソッド`eth_sendTransaction`を指定し、`transactionParameters`を渡していることに注目してください。 この時点で、ブラウザでMetaMaskが開かれ、ユーザーにトランザクションの署名または拒否を求めます。 -- トランザクションが成功した場合、この関数は、Etherscanでトランザクションについての詳細を確認するようユーザーに求める`status`JSX文字列が入ったJSONオブジェクトを返します。 +- トランザクションが成功した場合、この関数は、`status` JSX文字列がEtherscanでトランザクションについての詳細を確認するようユーザーに促すJSONオブジェクトを返します。 - トランザクションが失敗した場合、この関数は、エラーメッセージを伝える`status`文字列が入ったJSONオブジェクトを返します。 -全体では、`updateMessage`関数は次のようになります。 +全体として、`updateMessage`関数は次のようになります。 ```javascript // interact.js export const updateMessage = async (address, message) => { - //input error handling + //入力エラー処理 if (!window.ethereum || address === null) { return { status: - "💡 Connect your MetaMask wallet to update the message on the blockchain.", + "💡 ブロックチェーン上のメッセージを更新するには、MetaMaskウォレットを接続してください。", } } if (message.trim() === "") { return { - status: "❌ Your message cannot be an empty string.", + status: "❌ メッセージを空の文字列にすることはできません。", } } - //set up transaction parameters + //トランザクションパラメータを設定する const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: address, // must match user's active address. + to: contractAddress, // コントラクト公開時以外は必須。 + from: address, // ユーザーのアクティブなアドレスと一致する必要がある。 data: helloWorldContract.methods.update(message).encodeABI(), } - //sign the transaction + //トランザクションに署名する try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -1492,11 +1493,10 @@ export const updateMessage = async (address, message) => { ✅{" "} - View the status of your transaction on Etherscan! + Etherscanでトランザクションのステータスを表示してください！
- ℹ️ Once the transaction is verified by the network, the message will - be updated automatically. + ℹ️ トランザクションがネットワークによって検証されると、メッセージは自動的に更新されます。 ), } @@ -1523,18 +1523,18 @@ const onUpdatePressed = async () => { } ``` -とても綺麗ででシンプルです。 そして、なんということでしょう。 dappの完成です。 +とてもクリーンでシンプルです。 そして、なんと... dappの完成です！！！ -**更新**ボタンを試してみてください！ +**Update**ボタンを試してみてください！ -### 自分自身でカスタムdappを作る {#make-your-own-custom-dapp} +### 独自のカスタムdappを作成する {#make-your-own-custom-dapp} -おめでとう！あなたは、このチュートリアルを最後までやりきりました! おさらいすると、以下の方法を学びました。 +おめでとうございます！チュートリアルの最後までたどり着きました！ おさらいすると、以下の方法を学びました。 - MetaMaskウォレットをdappプロジェクトに接続する -- [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) APIを使用してスマートコントラクトからデータを読み取る。 -- MetaMaskを使用してイーサリアムトランザクションに署名する +- [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) APIを使用してスマートコントラクトからデータを読み取る +- MetaMaskを使用してEthereumトランザクションに署名する -これで、このチュートリアルのスキルを応用して独自のカスタムdappプロジェクトを構築するための準備が整いました。 何かご質問がございましたら、[Alchemy Discord](https://discord.gg/gWuC7zB)でいつでもお気軽にお問い合わせください。 🧙‍♂️ +これで、このチュートリアルのスキルを応用して独自のカスタムdappプロジェクトを構築するための準備が整いました。 いつものように、ご質問があれば、[Alchemy Discord](https://discord.gg/gWuC7zB)でお気軽にお問い合わせください。 🧙‍♂️ -このチュートリアルを通して体験したことやフィードバックがあれば、Twitter[@alchemyplatform](https://twitter.com/AlchemyPlatform)でタグ付けしてお知らせください。 +このチュートリアルを完了したら、Twitterで[@alchemyplatform](https://twitter.com/AlchemyPlatform)にタグ付けして、感想やフィードバックをお知らせください！ diff --git a/public/content/translations/ja/developers/tutorials/hello-world-smart-contract/index.md b/public/content/translations/ja/developers/tutorials/hello-world-smart-contract/index.md index 7cef5459340..b24c0b917d0 100644 --- a/public/content/translations/ja/developers/tutorials/hello-world-smart-contract/index.md +++ b/public/content/translations/ja/developers/tutorials/hello-world-smart-contract/index.md @@ -1,73 +1,62 @@ --- -title: 初心者向けのHello Worldスマートコントラクト -description: イーサリアムでの簡単なスマートコントラクトの作成とデプロイに関する入門チュートリアル +title: "初心者向けのHello Worldスマートコントラクト" +description: "イーサリアムでの簡単なスマートコントラクトの作成とデプロイに関する入門チュートリアル。" author: "elanh" -tags: - - "Solidity" - - "Hardhat" - - "alchemy" - - "スマートコントラクト" - - "デプロイ" +tags: [ "Solidity", "Hardhat", "Alchemy", "スマートコントラクト", "デプロイ" ] skill: beginner lang: ja published: 2021-03-31 --- -このチュートリアルは、ブロックチェーンの開発が初めてで、どこから始めたらよいのか分からない場合や、 スマートコントラクトをデプロイしてやり取りする方法を理解したいだけの場合に、最適なガイドとなります。 このチュートリアルでは、仮想ウォレット([MetaMask](https://metamask.io/))、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org/)、[Alchemy](https://alchemyapi.io/eth)を使用して、Goerliテストネットワーク上で簡単なスマートコントラクトを作成してデプロイする方法を順を追って説明します(現時点でしっかりと理解できていなくても、心配はご無用です。後ほど説明します)。 +このガイドは、ブロックチェーンの開発が初めてでどこから始めたらよいのか分からない方や、スマートコントラクトをデプロイして対話する方法を理解したいだけの方に最適です。 このチュートリアルでは、仮想ウォレット([MetaMask](https://metamask.io/))、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org/)、[Alchemy](https://www.alchemy.com/)を使用して、Sepoliaテストネットワーク上で簡単なスマートコントラクトを作成してデプロイする方法を順を追って説明します(現時点でしっかりと理解できていなくても、心配はご無用です。後ほど説明します)。 -> **警告** -> -> 🚧 非推奨の通知 -> -> このガイドでは、Goerliテストネットワークをスマートコントラクトの作成とデプロイに使用しています。 ただし、イーサリアム・ファウンデーションにより、[Goerliが間もなく廃止予定](https://www.alchemy.com/blog/goerli-faucet-deprecation)であることが発表されました。 -> -> このチュートリアルでは、[Sepolia](https://www.alchemy.com/overviews/sepolia-testnet)および[Sepoliaフォーセット](https://sepoliafaucet.com/)の利用を推奨します。 +このチュートリアルの[パート2](https://docs.alchemy.com/docs/interacting-with-a-smart-contract)では、デプロイ後のスマートコントラクトとの対話方法について、[パート3](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan)ではEtherscanで公開する方法について説明します。 -このチュートリアルの[パート2](https://docs.alchemy.com/docs/interacting-with-a-smart-contract)では、ここでデプロイしたスマートコントラクトとやり取りする方法について説明します。[パート3](https://docs.alchemy.com/docs/submitting-your-smart-contract-to-etherscan)では、そのスマートコントラクトをEtherscanで公開する方法について説明します。 - -質問がある場合は、いつでも[Alchemy Discord](https://discord.gg/gWuC7zB)でお問い合わせください。 +ご不明な点がございましたら、[Alchemy Discord](https://discord.gg/gWuC7zB)までお気軽にお問い合わせください！ ## ステップ1: イーサリアムネットワークに接続する {#step-1} -イーサリアムチェーンにリクエストを行う方法はたくさんあります。 簡略化のため、ここではAlchemyの無料アカウントを使用します。これは独自のノードを実行することなく、イーサリアムチェーンとの通信を可能にするブロックチェーンのデベロッパープラットフォームとAPIです。 このプラットフォームには、スマートコントラクトのデプロイメントにおいて内部で何が起こっているのかを把握するためにこのチュートリアルで利用する、監視と分析のためのデベロッパーツールも備わっています。 Alchemyのアカウントをお持ちでない場合は、[こちら](https://dashboard.alchemyapi.io/signup)から無料で登録できます。 +イーサリアムチェーンにリクエストを行う方法はたくさんあります。 簡略化のため、ここではAlchemyの無料アカウントを使用します。これは独自のノードを実行することなく、イーサリアムチェーンとの通信を可能にするブロックチェーンのデベロッパープラットフォームとAPIです。 このプラットフォームには、スマートコントラクトのデプロイメントにおいて内部で何が起こっているのかを把握するためにこのチュートリアルで利用する、監視と分析のためのデベロッパーツールも備わっています。 Alchemyアカウントをお持ちでない場合は、[こちらから無料で登録](https://dashboard.alchemy.com/signup)できます。 -## ステップ2: アプリ(およびAPI キー)を作成する {#step-2} +## ステップ2: アプリ(およびAPIキー)を作成する {#step-2} -Alchemyのアカウントを作成すると、アプリを作成することでAPIキーを生成できるようになります。 これにより、Goerliテストネットワークへのリクエストが可能になります。 テストネットに詳しくない場合は、[こちらのページ](/developers/docs/networks/)をご覧ください。 +Alchemyのアカウントを作成した後、アプリを作成することでAPIキーを生成することができます。 これにより、Sepoliaテストネットワークへのリクエストが可能になります。 テストネットに詳しくない場合は、[こちらのページ](/developers/docs/networks/)をご覧ください。 -1. ナビゲーションバーの「Apps」にマウスを合わせて、「Create App」をクリックし、Alchemyダッシュボードの「Create App」ページに移動してください。 +1. Alchemyダッシュボードのナビゲーションバーで「Select an app」を選択し、「Create new app」をクリックして、「Create new app」ページに移動します。 -![Hello WorldのCreate App](./hello-world-create-app.png) +![Hello worldアプリ作成](./hello-world-create-app.png) -2. アプリに「Hello World」という名前を付け、簡単な説明を記述し、環境に「Staging」を選択(アプリのブックキーピングに使用)し、ネットワークに「Goerli」を選択します。 +2. アプリに「Hello World」という名前を付け、簡単な説明を提示し、「Infra & Tooling」などのユースケースを選択します。 次に、「Ethereum」を検索してネットワークを選択します。 -![Hello WorldのCreate App画面](./create-app-view-hello-world.png) +![アプリ作成ビュー hello world](./create-app-view-hello-world.png) -3. 「Create app」をクリックして完了です。 アプリが下の表に表示されます。 +3. 「Next」をクリックして続行し、次に「Create app」をクリックすれば完了です！ ナビゲーションバーのドロップダウンメニューにアプリが表示され、APIキーをコピーできるようになります。 ## ステップ3: イーサリアムアカウント(アドレス)を作成する {#step-3} -トランザクションの送受信には、イーサリアムアカウントが必要です。 このチュートリアルでは、イーサリアムアカウントアドレスを管理するためにブラウザの仮想ウォレットであるMetamaskを使用します。 [トランザクション](/developers/docs/transactions/)の詳細。 +トランザクションの送受信には、イーサリアムアカウントが必要です。 このチュートリアルでは、イーサリアムアカウントアドレスを管理するためにブラウザの仮想ウォレットであるMetamaskを使用します。 [トランザクション](/developers/docs/transactions/)に関する詳細はこちら。 + +MetaMaskは[こちら](https://metamask.io/download)からダウンロードして、無料でイーサリアムアカウントを作成できます。 アカウントを作成するとき、またはすでにアカウントをお持ちの場合は、(実際のお金を使わないように)ネットワークのドロップダウンメニューを使用して「Sepolia」テストネットワークに切り替えてください。 -Metamaskのアカウントは[こちら](https://metamask.io/download)から無料でダウンロード、作成できます。 アカウントを作成後、またはすでにアカウントをお持ちの場合は(実際に支払いが発生しないように)右上の「Goerli Test Network」に切り替えてください。 +Sepoliaがリストに表示されない場合は、メニューから「高度な設定」に進み、下にスクロールして「テストネットワークを表示」をオンに切り替えます。 ネットワーク選択メニューで、「カスタム」タブを選択してテストネットのリストを見つけ、「Sepolia」を選択します。 -![MetaMask Ropstenの例](./metamask-ropsten-example.png) +![metamask sepolia の例](./metamask-sepolia-example.png) -## ステップ4: フォーセットからイーサ(ETH)を追加する {#step-4} +## ステップ4: フォーセットからイーサを追加する {#step-4} -テストネットワークにスマートコントラクトをデプロイするには、偽のETHが必要になります。 ETHを取得するには、[Goerliフォーセット](https://goerlifaucet.com/)にアクセスし、Alchemyアカウントでログインしてウォレットアドレスを入力し、「Send Me ETH」をクリックしてください。 ネットワークトラフィックのために偽のETHを受け取るのに時間がかかる場合があります。 (この記事の執筆時点では、30分ほどかかりました。) MetaMaskアカウントにETHが表示されるはずです! +テストネットワークにスマートコントラクトをデプロイするには、偽のEthが必要になります。 Sepolia ETHを入手するには、[Sepoliaネットワーク詳細](/developers/docs/networks/#sepolia)にアクセスして、さまざまなフォーセットのリストを表示します。 1つが機能しない場合は、別のものを試してください。枯渇している場合があります。 ネットワークのトラフィックにより、偽のETHの受信に時間がかかる場合があります。 その後すぐに、MetaMaskアカウントにETHが表示されるはずです！ ## ステップ5: 残高を確認する {#step-5} -残高を再確認するために、[eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)を[Alchemyのコンポーザーツール](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)を使用してリクエストしてみましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 MetaMaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 +残高があることを再確認するために、[Alchemyのcomposerツール](https://sandbox.alchemy.com/?network=ETH_SEPOLIA&method=eth_getBalance&body.id=1&body.jsonrpc=2.0&body.method=eth_getBalance&body.params%5B0%5D=&body.params%5B1%5D=latest)を使用して[eth_getBalance](/developers/docs/apis/json-rpc/#eth_getbalance)リクエストを作成しましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 MetaMaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 ```json { "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" } ``` -> **注:** この結果の単位は、ETHではなくweiです。 weiはETHの最小単位として使われています。 weiからETHへ変換すると、1 eth = 1018 weiになります。 つまり、0x2B5E3AF16B1880000を10進数に変換すると、5\*10¹⁸となり、5 ETHに相当します。 +> **注：**この結果の単位はETHではなくweiです。 weiはETHの最小単位として使われています。 weiからETHへの変換は、1 eth = 1018 weiです。 したがって、0x2B5E3AF16B1880000を10進数に変換すると5\*10¹⁸になり、これは5 ETHに相当します。 > -> ご安心ください。 偽のお金はすべてそこにあります。 +> ふう! 偽のお金がすべて揃いました。 ## ステップ6: プロジェクトを初期化する {#step-6} @@ -78,18 +67,18 @@ mkdir hello-world cd hello-world ``` -プロジェクトフォルダ内に入ったら、`npm init`を使用してプロジェクトを初期化します。 まだnpmがインストールされていない場合は、[こちらの手順](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm)に従ってください(Node.jsも必要となりますので、こちらもダウンロードしてください。) +プロジェクトフォルダに入ったので、`npm init`を使用してプロジェクトを初期化します。 npmをまだインストールしていない場合は、[これらの手順](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm)に従ってください(Node.jsも必要なので、それもダウンロードしてください！)。 ``` npm init ``` -インストール時の質問についてはどのように回答してもかまいませんが、参考までに以前行った回答を以下に示します。 +インストールの質問にどう答えるかは重要ではありませんが、参考までに私たちの回答方法を次に示します。 ``` package name: (hello-world) version: (1.0.0) -description: hello world smart contract +description: hello world スマートコントラクト entry point: (index.js) test command: git repository: @@ -101,7 +90,7 @@ About to write to /Users/.../.../.../hello-world/package.json: { "name": "hello-world", "version": "1.0.0", - "description": "hello world smart contract", + "description": "hello world スマートコントラクト", "main": "index.js", "scripts": { "test": "echo \\"Error: no test specified\\" && exit 1" @@ -111,19 +100,19 @@ About to write to /Users/.../.../.../hello-world/package.json: } ``` -package.jsonを承認すれば完了です。 +package.jsonを承認すれば完了です！ ## ステップ7: [Hardhat](https://hardhat.org/getting-started/#overview)をダウンロードする {#step-7} Hardhatは、イーサリアムのソフトウェアをコンパイル、デプロイ、テスト、デバッグするための開発環境です。 デベロッパーがライブチェーンにデプロイする前に、スマートコントラクトや分散型アプリケーション(Dapp)をローカルに構築する際に役立ちます。 -先ほど作成した`hello-world`プロジェクト内で、以下を実行します。 +`hello-world`プロジェクト内で次を実行します。 ``` npm install --save-dev hardhat ``` -[インストール手順](https://hardhat.org/getting-started/#overview)の詳細については、こちらのページをご覧ください。 +[インストール手順](https://hardhat.org/getting-started/#overview)の詳細については、このページをご覧ください。 ## ステップ8: Hardhatプロジェクトを作成する {#step-8} @@ -133,7 +122,7 @@ npm install --save-dev hardhat npx hardhat ``` -ウェルカムメッセージと、次に何をするのかを選択できるオプションが表示されます。 「Create an empty hardhat.config.js」を選択します。 +ウェルカムメッセージと、次に何をするのかを選択できるオプションが表示されます。 「create an empty hardhat.config.js」を選択してください。 ``` 888 888 888 888 888 @@ -153,7 +142,7 @@ Create a sample project Quit ``` -`hardhat.config.js`ファイルが生成されます。このファイルでプロジェクトのすべての設定を行います(ステップ13で行います)。 +これにより `hardhat.config.js` ファイルが生成されます。ここでプロジェクトのすべてのセットアップを指定します(ステップ13)。 ## ステップ9: プロジェクトフォルダを追加する {#step-9} @@ -164,55 +153,55 @@ mkdir contracts mkdir scripts ``` -- `contracts/`は、Hello Worldスマートコントラクトのコードファイルを格納する場所です。 -- `scripts/`は、コントラクトをデプロイして対話するスクリプトを保持する場所です。 +- `contracts/` には、hello worldスマートコントラクトのコードファイルを保存します +- `scripts/` には、コントラクトをデプロイして対話するためのスクリプトを保存します ## ステップ10: コントラクトを作成する {#step-10} -一体いつになったらコードを書くのだろうと疑問をお持ちではないでしょうか 。 このステップ10でコードを書いていきましょう。 +一体いつになったらコードを書くのだろう、と思っているかもしれませんね。 さあ、このステップ10でコードを書き始めましょう。 -お気に入りのエディタでhello-worldプロジェクトを開きます(通常は[VScode](https://code.visualstudio.com/)を使用しています)。 スマートコントラクトは、Solidityと呼ばれる言語で記述されています。HelloWorld.solスマートコントラクトの作成にこの言語を使用します。 +お気に入りのエディタでhello-worldプロジェクトを開きます([VSCode](https://code.visualstudio.com/)がおすすめです)。 スマートコントラクトはSolidityという言語で書かれており、これを使ってHelloWorld.solスマートコントラクトを作成します。‌ -1. 「contracts」フォルダに移動し、HelloWorld.solという名前の新規ファイルを作成します。 -2. 以下は、このチュートリアルで使用するイーサリアム・ファウンデーションのHello Worldスマートコントラクトのサンプルです。 以下の内容をコピーして、HelloWorld.solファイルに貼り付けます。コメントを読んで、このコントラクトが何を行うのかを理解してください。 +1. 「contracts」フォルダに移動し、HelloWorld.solという名前の新規ファイルを作成します。 +2. 以下は、このチュートリアルで使用するイーサリアム・ファウンデーションのHello Worldスマートコントラクトのサンプルです。 以下の内容をHelloWorld.solファイルにコピー&ペーストし、コメントを読んでこのコントラクトが何をするのかを理解してください。 ```solidity -// Specifies the version of Solidity, using semantic versioning. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// セマンティックバージョニングを使用して、Solidityのバージョンを指定します。 +// 詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma pragma solidity ^0.7.0; -// Defines a contract named `HelloWorld`. -// A contract is a collection of functions and data (its state). Once deployed, a contract resides at a specific address on the Ethereum blockchain. Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// `HelloWorld`という名前のコントラクトを定義します。 +// コントラクトは関数とデータ(その状態)の集合です。デプロイされると、コントラクトはイーサリアムのブロックチェーン上の特定のアドレスに配置されます。詳細はこちら: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html contract HelloWorld { - // Declares a state variable `message` of type `string`. - // State variables are variables whose values are permanently stored in contract storage. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value. + // `string`型の状態変数`message`を宣言します。 + // 状態変数は、その値がコントラクトストレージに永続的に保存される変数です。`public`キーワードは、変数をコントラクトの外部からアクセス可能にし、他のコントラクトやクライアントがその値をアクセスするために呼び出せる関数を作成します。 string public message; - // Similar to many class-based object-oriented languages, a constructor is a special function that is only executed upon contract creation. - // Constructors are used to initialize the contract's data. Learn more:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // 多くのクラスベースのオブジェクト指向言語と同様に、コンストラクタはコントラクト作成時にのみ実行される特別な関数です。 + // コンストラクタは、コントラクトのデータを初期化するために使用されます。詳細はこちら:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors constructor(string memory initMessage) { - // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable). + // 文字列引数`initMessage`を受け入れ、その値をコントラクトの`message`ストレージ変数に設定します。 message = initMessage; } - // A public function that accepts a string argument and updates the `message` storage variable. + // 文字列引数を受け入れ、`message`ストレージ変数を更新する公開関数です。 function update(string memory newMessage) public { message = newMessage; } } ``` -これは、作成時にメッセージを保存し、`update`関数を呼び出すことで更新できる非常にシンプルなスマートコントラクトです。 +これは、作成時にメッセージを保存し、`update`関数を呼び出すことで更新できる、非常にシンプルなスマートコントラクトです。 ## ステップ11: MetaMaskとAlchemyをプロジェクトに接続する {#step-11} -ここまでで、MetaMaskウォレットとAlchemyアカウントを作成し、スマートコントラクトも作成しました。次はこの3つを接続しましょう。 +MetaMaskウォレットとAlchemyアカウントを作成し、スマートコントラクトも作成しました。次はこの3つを接続しましょう。 -仮想ウォレットから送信されるすべてのトランザクションには、固有の秘密鍵を使用した署名が必要です。 この権限をプログラムに提供するため、秘密鍵(およびAlchemy APIキー)を環境ファイルに安全に保存できます。 +仮想ウォレットから送信されるすべてのトランザクションには、固有の秘密鍵を使用した署名が必要です。 この許可をプログラムに与えるために、秘密鍵(とAlchemyのAPIキー)を環境ファイルに安全に格納する作業を行います。 -> トランザクションの送信の詳細については、web3を使用したトランザクションの送信に関する[こちらのチュートリアル](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)をご覧ください。 +> トランザクションの送信について詳しく知るには、web3を使用したトランザクション送信に関する[このチュートリアル](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)をご覧ください。 まず、プロジェクトディレクトリにdotenvパッケージをインストールします。 @@ -220,37 +209,37 @@ contract HelloWorld { npm install dotenv --save ``` -次に、 `.env`ファイルをプロジェクトのルートディレクトリに作成し、そのファイルにMetamaskの秘密鍵とHTTP Alchemy APIのURLを追加します。 +次に、プロジェクトのルートディレクトリに`.env`ファイルを作成し、MetaMaskの秘密鍵とHTTP Alchemy API URLを追加します。 -- 秘密鍵をエクスポートするには、[こちらの手順](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)に従ってください。 -- HTTP Alchemy APIのURLを取得するには、以下を参照してください。 +- [これらの手順](https://support.metamask.io/configure/accounts/how-to-export-an-accounts-private-key/)に従って秘密鍵をエクスポートします +- HTTP Alchemy API URLを取得するには、以下を参照してください -![Alchemy APIキーの取得](./get-alchemy-api-key.gif) +![alchemy apiキーの取得](./get-alchemy-api-key.png) -Alchemy APIのURLをコピーします。 +Alchemy API URLをコピーする -`.env`ファイルは次のようになります。 +`.env`は次のようになります: ``` -API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key" +API_URL = "https://eth-sepolia.g.alchemy.com/v2/your-api-key" PRIVATE_KEY = "your-metamask-private-key" ``` -これらの変数を実際にコードに接続するために、ステップ13でこれらの変数を`hardhat.config.js`ファイル内で参照します。 +これらをコードに実際に接続するために、ステップ13で`hardhat.config.js`ファイル内のこれらの変数を参照します。 -.envファイルをコミットしないでください! .envファイルを誰かと共有したり公開したりしないようにしてください。秘密が漏洩する可能性があります。 バージョン管理ツールを使用している場合は、.envをgitignoreファイルに追加します。 +.envはコミットしないでください！ .envは決して他人と共有したり、公開したりしないように注意してください。共有することで、あなたのアカウント情報が漏洩する可能性があります。 バージョンを管理する場合は、.envをgitignoreファイルに追加してください。 ## ステップ12: Ethers.jsをインストールする {#step-12-install-ethersjs} -Ethers.jsは、よりユーザーフレンドリーなメソッドで[標準のJSON-RPCメソッド](/developers/docs/apis/json-rpc/)をラップすることにより、イーサリアムとの対話やリクエストを簡単にするライブラリです。 +Ethers.jsは、[標準のJSON-RPCメソッド](/developers/docs/apis/json-rpc/)をよりユーザーフレンドリーなメソッドでラップすることで、イーサリアムとの対話やリクエストを容易にするライブラリです。 -Hardhatは、追加のツールと拡張機能のための[プラグイン](https://hardhat.org/plugins/)の統合を非常に簡単にしてくれます。 コントラクトのデプロイメントに[Ethersプラグイン](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers)を利用します([Ethers.js](https://github.com/ethers-io/ethers.js/)には、複数の非常にクリーンなコントラクトのデプロイメント方法があります)。 +Hardhatでは、追加のツールや拡張機能のための[プラグイン](https://hardhat.org/plugins/)を非常に簡単に統合できます。 コントラクトのデプロイには[Ethersプラグイン](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers)を活用します([Ethers.js](https://github.com/ethers-io/ethers.js/)には非常にクリーンなコントラクトデプロイメントメソッドがあります)。 プロジェクトのホームディレクトリで以下を実行します。 @@ -258,13 +247,13 @@ Hardhatは、追加のツールと拡張機能のための[プラグイン](http npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0" ``` -次のステップの`hardhat.config.js`でもEthers(.js)が必要になります。 +次のステップで、`hardhat.config.js`にethersもrequireします。 ## ステップ13: hardhat.config.jsを更新する {#step-13-update-hardhatconfigjs} -ここまでで、いくつかの依存関係とプラグインを追加しました。次に、`hardhat.config.js`を更新して、プロジェクトがそれらすべてについて認識できるようにする必要があります。 +ここまでで、いくつかの依存関係とプラグインを追加しました。次に、プロジェクトがそれらすべてを認識できるように、`hardhat.config.js`を更新する必要があります。 -`hardhat.config.js`を以下のように更新します。 +`hardhat.config.js`を次のように更新します: ``` require('dotenv').config(); @@ -277,10 +266,10 @@ const { API_URL, PRIVATE_KEY } = process.env; */ module.exports = { solidity: "0.7.3", - defaultNetwork: "goerli", + defaultNetwork: "sepolia", networks: { hardhat: {}, - goerli: { + sepolia: { url: API_URL, accounts: [`0x${PRIVATE_KEY}`] } @@ -290,7 +279,7 @@ module.exports = { ## ステップ14: コントラクトをコンパイルする {#step-14-compile-our-contracts} -ここまででしっかりと動作していることを確認するため、コントラクトをコンパイルしてみましょう。 `compile`タスクは、組み込みのHardhatタスクの1つです。 +ここまでの作業がうまくいっていることを確認するために、コントラクトをコンパイルしてみましょう。 `compile`タスクは、組み込みのHardhatタスクの1つです。 コマンドラインで以下を実行します。 @@ -298,19 +287,19 @@ module.exports = { npx hardhat compile ``` -`SPDX license identifier not provided in source file`という警告が表示される場合がありますが、心配する必要はありません。警告が表示されないのがベストですが、 表示された場合は、いつでも[Alchemy discord](https://discord.gg/u72VCg3)でメッセージを送信できます。 +`SPDX license identifier not provided in source file`という警告が表示されるかもしれませんが、心配する必要はありません。それ以外は問題ないはずです！ うまくいかない場合は、いつでも[Alchemy Discord](https://discord.gg/u72VCg3)でメッセージを送ることができます。 -## ステップ15: デプロイスクリプトを書く {#step-15-write-our-deploy-scripts} +## ステップ15: デプロイスクリプトを作成する {#step-15-write-our-deploy-scripts} コントラクトの作成と設定ファイルの作成が完了したら、いよいよコントラクトのデプロイのためのスクリプトを作成します。 -`scripts/`フォルダに移動して、`deploy.js`という名前のファイルを新規に作成し、以下の内容を追加します。 +`scripts/`フォルダに移動して`deploy.js`という名前の新しいファイルを作成し、次の内容を追加します: ``` async function main() { const HelloWorld = await ethers.getContractFactory("HelloWorld"); - // Start deployment, returning a promise that resolves to a contract object + // デプロイを開始し、コントラクトオブジェクトに解決されるpromiseを返します const hello_world = await HelloWorld.deploy("Hello World!"); console.log("Contract deployed to address:", hello_world.address);} @@ -322,48 +311,49 @@ main() }); ``` -Hardhatがコードの各行で行っている驚くべき内容については、Hardhatの[コントラクトチュートリアル](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)で説明されています。以下では、その説明を採用しています。 +Hardhatは、[コントラクトのチュートリアル](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)で、これらのコードの各行が何をするかを非常にうまく説明しています。ここではその説明を採用しました。 ``` const HelloWorld = await ethers.getContractFactory("HelloWorld"); ``` -ethers.jsの`ContractFactory`は新しいスマートコントラクトをデプロイするための抽象化であり、ここでの`HelloWorld`はhello worldコントラクトのインスタンスのためのファクトリです。 `hardhat-ethers`プラグインを使用する場合、`ContractFactory`および`Contract`インスタンスはデフォルトで最初の署名者に接続されます。 +ethers.jsの`ContractFactory`は、新しいスマートコントラクトをデプロイするために使用される抽象化です。したがって、ここでの`HelloWorld`は、私たちのhello worldコントラクトのインスタンスのためのファクトリです。 `hardhat-ethers`プラグインを使用する場合、`ContractFactory`および`Contract`インスタンスはデフォルトで最初の署名者に接続されます。 ``` const hello_world = await HelloWorld.deploy(); ``` -`ContractFactory`で`deploy()`を呼び出すとデプロイメントが開始され、`Contract`に解決すべき`Promise`が返されます。 これは、スマートコントラクトの各関数に対するメソッドを持つオブジェクトです。 +`ContractFactory`で`deploy()`を呼び出すとデプロイメントが開始され、`Contract`に解決される`Promise`が返されます。 これは、スマートコントラクトの各関数に対するメソッドを持つオブジェクトです。 ## ステップ16: コントラクトをデプロイする {#step-16-deploy-our-contract} -ようやく、スマートコントラクトをデプロイする準備が整いました。 コマンドラインに移動し、以下を実行します。 +ようやく、スマートコントラクトをデプロイする準備が整いました。 コマンドラインに移動し、次を実行します: ``` -npx hardhat run scripts/deploy.js --network goerli +npx hardhat run scripts/deploy.js --network sepolia ``` 次のような画面が表示されるはずです。 ``` -Contract deployed to address: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 +コントラクトがデプロイされたアドレス: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570 ``` -[Goerli etherscan](https://goerli.etherscan.io/)に移動し、コントラクトアドレスを検索すると、コントラクトが正常にデプロイされていることを確認できるはずです。 トランザクションは以下のようなものになります。 +[Sepolia etherscan](https://sepolia.etherscan.io/)にアクセスし、コントラクトアドレスを検索すると、正常にデプロイされたことが確認できるはずです。 トランザクションは以下のようなものになります。 -![EtherscanのContract](./etherscan-contract.png) +![etherscanコントラクト](./etherscan-contract.png) -`From`アドレスはMetaMaskアカウントアドレスと一致する必要があります。Toアドレスには「Contract Creation」と表示されますが、トランザクションをクリックすると、`To`フィールドにコントラクトアドレスが表示されます。 +`From`アドレスはMetaMaskアカウントのアドレスと一致し、`To`アドレスは「Contract Creation」と表示されますが、トランザクションをクリックすると`To`フィールドにコントラクトアドレスが表示されます。 -![EtherscanのTransaction](./etherscan-transaction.png) +![etherscanトランザクション](./etherscan-transaction.png) -おめでとうございます! イーサリアムチェーンにスマートコントラクトをデプロイできました 🎉 +おめでとうございます！ イーサリアムチェーンにスマートコントラクトをデプロイできました 🎉 -内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemyのアプリが複数ある場合は、必ずアプリでフィルタリングし、「Hello World」を選択してください。 ![Hello WorldのExplorer](./hello-world-explorer.png) +内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemyアプリが複数ある場合は、必ずアプリでフィルタリングし、「Hello World」を選択してください。 +![hello worldエクスプローラー](./hello-world-explorer.png) -ここでは、`.deploy()`関数を呼び出した際に、Hardhat/Ethersが内部で行ったJSON-RPCの呼び出しを見ることができます。 ここで呼び出している2つの重要なJSON-RPCは、実際にGoerliチェーン上でコントラクトを書き込むリクエストの[`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction)と、(トランザクションの際の典型的なパターンである)ハッシュを与えられているトランザクションに関する情報を読み取るリクエストの[`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash)です。 トランザクションの送信の詳細については、こちらのチュートリアルの[Web3を使用したトランザクションの送信](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)をご覧ください。 +ここでは、`.deploy()`関数を呼び出したときにHardhat/Ethersが内部で行ったいくつかのJSON-RPCコールを確認できます。 ここで注目すべき重要なコールは2つあります。1つは、コントラクトをSepoliaチェーンに実際に書き込むためのリクエストである[`eth_sendRawTransaction`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-send-raw-transaction)で、もう1つはハッシュが与えられたトランザクションに関する情報を読み取るためのリクエストである[`eth_getTransactionByHash`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-get-transaction-by-hash)です(これはトランザクションにおける典型的なパターンです)。 トランザクションの送信についてさらに詳しく知りたい場合は、[Web3を使用したトランザクションの送信](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)に関するチュートリアルをご覧ください。 -こちらのチュートリアルのパート1は以上となります。パート2では初期メッセージの更新による[スマートコントラクトとの実際のやり取り](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#part-2-interact-with-your-smart-contract)を、パート3では[Etherscanへのスマートコントラクトの公開](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#optional-part-3-publish-your-smart-contract-to-etherscan)を行い、やり取りする方法を学びます。 +このチュートリアルのパート1は以上です。パート2では、最初のメッセージを更新して[スマートコントラクトと実際に対話](https://www.alchemy.com/docs/interacting-with-a-smart-contract)し、パート3では[スマートコントラクトをEtherscanに公開](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan)して、誰もがその対話方法を知ることができるようにします。 -**Alchemyの詳細については、 [ウェブサイト](https://alchemyapi.io/eth)をご覧ください。 アップデートを見逃したくない場合は、 [こちら](https://www.alchemyapi.io/newsletter)でニュースレターを購読してください。 [Twitter](https://twitter.com/alchemyplatform)もあわせてフォローし、[Discord](https://discord.com/invite/u72VCg3)**にもご参加ください。 +**Alchemyについてもっと知りたいですか？ 私たちの[ウェブサイト](https://www.alchemy.com/eth)をご覧ください。 アップデートを見逃したくないですか？ [こちら](https://www.alchemy.com/newsletter)でニュースレターに登録してください！ 私たちの[Discord](https://discord.gg/u72VCg3)にもぜひご参加ください。** diff --git a/public/content/translations/ja/developers/tutorials/how-to-implement-an-erc721-market/index.md b/public/content/translations/ja/developers/tutorials/how-to-implement-an-erc721-market/index.md index b77db2aa191..d59ac9aabaf 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-implement-an-erc721-market/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-implement-an-erc721-market/index.md @@ -1,12 +1,8 @@ --- -title: ERC-721マーケットを実装する方法 -description: 分散型のクラシファイドボード（掲示板）に、トークン化されたアイテムを出品する方法 +title: "ERC-721マーケットを実装する方法" +description: "分散型のクラシファイドボード（掲示板）に、トークン化されたアイテムを出品する方法" author: "Alberto Cuesta Cañada" -tags: - - "スマートコントラクト" - - "erc-721" - - "Solidity" - - "トークン" +tags: [ "スマートコントラクト", "ERC-721", "Solidity", "トークン" ] skill: intermediate lang: ja published: 2020-03-19 @@ -22,17 +18,17 @@ Gumtree、Ebay、Craigslistといったインターネット掲示板が登場 ブロックチェーン技術は、この掲示板市場をさらに変革するものです。以下では、その方法について紹介します。 -## マネタイゼーション（収益化） {#monetization} +## 収益化 {#monetization} パブリックブロックチェーンにおける掲示板のビジネスモデルは、Ebayなどの企業のビジネスモデルとは異なります。 -まず第一に、 [脱中心化](/developers/docs/web2-vs-web3/)されている点を指摘すべきでしょう。 既存の掲示板プラットフォームは、自社サーバーを運用する必要があります。 しかし、分散型プラットフォームの運営はユーザーが実行するため、プラットフォーム所有者はコア・プラットフォームを稼働させるコストを負担する必要がありません。 +まず、[分散化という観点](/developers/docs/web2-vs-web3/)があります。 既存の掲示板プラットフォームは、自社サーバーを運用する必要があります。 しかし、分散型プラットフォームの運営はユーザーが実行するため、プラットフォーム所有者はコア・プラットフォームを稼働させるコストを負担する必要がありません。 -次に、プラットフォームにアクセスする機能を提供するウェブサイトまたはインターフェイスといったフロントエンドがあります。 フロントエンドには、いくつかのオプションがあります。 プラットフォーム所有者は、ユーザーのアクセス権限を制限し、インターフェイスを有料で使わせることができます。 一方で、プラットフォーム所有者がアクセス権限を開放し（人々に力を！）、ユーザーが自由にインターフェイスを開発できるようにすることもできます。 あるいは、これら2つの極端なアプローチの中間を選択することもできます。 +次に、プラットフォームにアクセスする機能を提供するウェブサイトまたはインターフェイスといったフロントエンドがあります。 フロントエンドには、いくつかのオプションがあります。 プラットフォーム所有者は、ユーザーのアクセス権限を制限し、インターフェイスを有料で使わせることができます。 プラットフォームの所有者は、アクセスを開放することも決定できます (Power to the People!) そして、誰でもプラットフォームへのインターフェースを構築できるようにします。 あるいは、これら2つの極端なアプローチの中間を選択することもできます。 -_私よりもビジネス感覚に優れている方は、これをどのように収益化すべきかについてよくご存じでしょう。 分散型のクラシファイドについて私が言えるのは、既存の掲示板プラットフォームとは異なっており、おそらく収益化が可能だということです。_ +_私よりも先見の明のあるビジネスリーダーは、これを収益化する方法を知っているでしょう。 私にわかるのは、これが現状とは異なり、おそらく利益になるだろうということだけです。_ -掲示板プラットフォームについては、自動化や支払い方法の視点からも考えることができます。 一部の商品は、[トークン化を非常に効果的に実行でき](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com) 、掲示板での取引に適しています。 トークン化されたアセットは、ブロックチェーン上で簡単に移転できます。 また、ブロックチェーンでは、非常に複雑な支払い方法も簡単に実装できます。 +掲示板プラットフォームについては、自動化や支払い方法の視点からも考えることができます。 一部のものは、非常に[効果的にトークン化](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com)され、クラシファイドボードで取引できます。 トークン化されたアセットは、ブロックチェーン上で簡単に移転できます。 また、ブロックチェーンでは、非常に複雑な支払い方法も簡単に実装できます。 私はここに、ビジネスチャンスがあると感じているわけです。 トランザクションごとに複雑な支払経路を設定しつつ、運用コストが発生しない掲示板を、簡単に実装できるからです。 私は、ブロックチェーン・コミュニティから必ず、これを活用するアイディアが生まれてくると考えています。 @@ -40,9 +36,9 @@ _私よりもビジネス感覚に優れている方は、これをどのよう ## 実装 {#implementation} -私たちは少し前に、具体的なビジネスケースに基づく実装やその他のリソースを提供する [オープンソースのリポジトリ](https://github.com/HQ20/contracts?ref=hackernoon.com)を立ち上げました。ぜひアクセスしてください。 +少し前に、ビジネスケースのサンプル実装やその他の特典を含む[オープンソースリポジトリ](https://github.com/HQ20/contracts?ref=hackernoon.com)を開始しました。ぜひご覧ください。 -この [イーサリアム・クラシファイド掲示板](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) のコードもレポジトリから入手できますので、自由に活用してください。 ただし、このコードは監査を経ていないため、お金を伴う取引を開始する前に、各自でデューデリジェンスを行う必要があります。 +この[Ethereumクラシファイドボード](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com)のコードはそこにあります。どうぞご自由にお使いください。 ただし、このコードは監査を経ていないため、お金を伴う取引を開始する前に、各自でデューデリジェンスを行う必要があります。 掲示板における基本的な機能はシンプルなものです。 掲示板におけるすべての投稿は、いくつかのフィールドを含む構造体に過ぎません： @@ -67,9 +63,9 @@ mapping(uint256 => Trade) public trades; 次に、どのようなアイテムを扱う必要があり、取引の支払いにはどの通貨を使うかについて考える必要があります。 -取扱アイテムについては、[ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com)インターフェイスを実装すればよいです。このインターフェイスは、[デジタル資産と最も相性がよいのは事実ですが](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com)、現実に存在するアイテムをブロックチェーン上で表現するための手段に過ぎません。 この掲示板用の ERC-721コントラクトはコンストラクタで指定するため、掲示板に含まれるアセットは前もってトークン化しておく必要があります。 +アイテムについては、[ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com)インターフェースを実装することだけを求めます。これは現実世界のアイテムをブロックチェーンで表現する方法にすぎませんが、[デジタルアセットで最も効果的に機能します](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com)。 この掲示板用の ERC-721コントラクトはコンストラクタで指定するため、掲示板に含まれるアセットは前もってトークン化しておく必要があります。 -支払い機能についても、ほぼ同じです。 大部分のブロックチェーン・プロジェクトでは、独自の [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com)暗号通貨を定義しています。 DAIのように、著名な暗号通貨を採用する場合もあります。 このクラシファイド掲示板では、コンストラクタにおいて通貨を指定する必要があるだけです。 簡単ですね。 +支払い機能についても、ほぼ同じです。 ほとんどのブロックチェーンプロジェクトは、独自の[ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com)暗号通貨を定義しています。 DAIのように、著名な暗号通貨を採用する場合もあります。 このクラシファイド掲示板では、コンストラクタにおいて通貨を指定する必要があるだけです。 簡単ですね。 ```solidity constructor ( @@ -127,18 +123,18 @@ function cancelTrade(uint256 _trade) Trade memory trade = trades[_trade]; require( msg.sender == trade.poster, - "Trade can be cancelled only by poster." + "取引は投稿者のみがキャンセルできます。" ); - require(trade.status == "Open", "Trade is not Open."); + require(trade.status == "Open", "取引はオープン状態ではありません。"); itemToken.transferFrom(address(this), trade.poster, trade.item); trades[_trade].status = "Cancelled"; emit TradeStatusChange(_trade, "Cancelled"); } ``` -以上です！ これで、実装が完了しました。 この掲示板もそうですが、ビジネスコンセプトをコードで表現すると、驚くほど簡潔であることが少なくありません。 私たちのレポジトリから、[完成したコントラクト](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol)を入手できます。 +以上です！ これで、実装が完了しました。 この掲示板もそうですが、ビジネスコンセプトをコードで表現すると、驚くほど簡潔であることが少なくありません。 完全なコントラクトは[私たちのリポジトリ](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol)で確認してください。 -## まとめ {#conclusion} +## 結論 {#conclusion} クラシファイド掲示板は、インターネットの普及に伴い爆発的に規模を拡大した一般的な市場構成であり、非常に人気のあるビジネスモデルを大手数社が独占している状態です。 @@ -146,4 +142,4 @@ function cancelTrade(uint256 _trade) この記事は、実際の掲示板ビジネスと、技術的な実装との間にあるギャップを埋めるための試みです。 この記事に記載された知識を基に、適切なスキルを持つユーザーであれば、掲示板ビジネスのビジョンと実装ロードマップを生み出すことができるでしょう。 -いつものように、面白いプロジェクトを進行中で助言が必要な場合は、[ぜひご連絡ください](https://albertocuesta.es/)！ いつでも喜んでお手伝いします。 +いつものように、面白いプロジェクトを進行中で助言が必要な場合は、ぜひ[ご連絡ください](https://albertocuesta.es/)！ いつでも喜んでお手伝いします。 diff --git a/public/content/translations/ja/developers/tutorials/how-to-mint-an-nft/index.md b/public/content/translations/ja/developers/tutorials/how-to-mint-an-nft/index.md index ef610e4373a..e3578671782 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-mint-an-nft/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-mint-an-nft/index.md @@ -1,28 +1,26 @@ --- -title: NFTのミント方法(NFTチュートリアルシリーズの2/3) -description: このチュートリアルでは、スマートコントラクトとWeb3を使用してEthereumブロックチェーン上でNFTをミントする方法を説明します。 +title: "NFTのミント方法(NFTチュートリアルシリーズの2/3)" +description: "このチュートリアルでは、スマートコントラクトとWeb3を使用してイーサリアムブロックチェーン上でNFTをミントする方法を説明します。" author: "Sumi Mudgil" -tags: - - "ERC-721" - - "alchemy" - - "Solidity" - - "スマートコントラクト" +tags: [ "ERC-721", "Alchemy", "Solidity", "スマートコントラクト" ] skill: beginner lang: ja published: 2021-04-22 --- -[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): $69,000,000 [3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): $11,000,000 [Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): $6,000,000 +[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): 6900万ドル +[3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): 1100万ドル +[Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): 600万ドル -いずれもAlchemyの強力なAPIを使ってNFTをミントしています。 このチュートリアルでは、\<10分以内でNFTをミントする方法を説明します。 +いずれもAlchemyの強力なAPIを使ってNFTをミントしています。 このチュートリアルでは、\<10分で同じことを行う方法を説明します。 -「NFTのミント」とは、ブロックチェーン上にERC-721トークンのユニークなインスタンスを公開することです。 [NFTチュートリアルシリーズのパート1](/developers/tutorials/how-to-write-and-deploy-an-nft/)で作成したスマートコントラクトを使って、Web3のスキルを駆使し、NFTをミントしてみましょう。 このチュートリアルが終わるころには、あなた(とウォレット) の望むがままにNFTをミントできるようになります。 +「NFTのミント」とは、ブロックチェーン上にERC-721トークンのユニークなインスタンスを公開することです。 この[NFTチュートリアルシリーズのパート1](/developers/tutorials/how-to-write-and-deploy-an-nft/)で作成したスマートコントラクトを使って、Web3のスキルを駆使し、NFTをミントしてみましょう。 このチュートリアルが終わるころには、あなた(とウォレット)が望むだけNFTをミントできるようになります。 さあ、始めましょう。 ## ステップ1: Web3をインストールする {#install-web3} -NFTスマートコントラクトの作成に関する最初のチュートリアルに沿って進めている場合、すでにEthers.jsを使用していることと思います。 Web3はEthersと同様、イーサリアムブロックチェーンへのリクエストを簡単に作成するために使用されるライブラリです。 このチュートリアルでは、自動再試行と堅牢なWebSocketサポートを提供する拡張Web3ライブラリ、[Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3)を使用します。 +NFTスマートコントラクトの作成に関する最初のチュートリアルに沿って進めている場合、すでにEthers.jsを使用した経験があるはずです。 Web3はEthersと同様、イーサリアムブロックチェーンへのリクエストを簡単に作成するために使用されるライブラリです。 このチュートリアルでは、自動再試行と堅牢なWebSocketサポートを提供する拡張Web3ライブラリである[Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3)を使用します。 プロジェクトのホームディレクトリで以下を実行します。 @@ -32,7 +30,7 @@ npm install @alch/alchemy-web3 ## ステップ2: `mint-nft.js`ファイルを作成する {#create-mintnftjs} -scriptsディレクトリ内に`mint-nft.js`ファイルを作成し、以下のコード行を追加します。 +`scripts`ディレクトリ内に`mint-nft.js`ファイルを作成し、以下のコード行を追加してください。 ```js require("dotenv").config() @@ -43,19 +41,19 @@ const web3 = createAlchemyWeb3(API_URL) ## ステップ3: コントラクトABIを取得する {#contract-abi} -コントラクトABI(アプリケーションバイナリインターフェイス)は、スマートコントラクトと対話するためのインターフェイスです。 コントラクトABIの詳細については、[こちら](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is)をご覧ください。 Hardhatは自動的にABIを生成して、`MyNFT.json`ファイルに保存します。 このABIを使用するには、`mint-nft.js`に次のコードを追加して、ABIをパースする必要があります。 +コントラクトABI (Application Binary Interface) は、スマートコントラクトと対話するためのインターフェイスです。 コントラクトABIの詳細は[こちら](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is)をご覧ください。 Hardhatは自動的にABIを生成し、`MyNFT.json`ファイルに保存します。 これを使用するには、`mint-nft.js`ファイルに以下のコード行を追加してコンテンツを解析する必要があります。 ```js const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json") ``` -ABIを表示したい場合は、次のコードを追加することでコンソールに出力できます: +ABIを確認したい場合は、コンソールに出力できます: ```js console.log(JSON.stringify(contract.abi)) ``` -`mint-nft.js`を実行し、コンソールに出力されたABIを表示するには、ターミナルに移動して次のコードを実行します。 +`mint-nft.js`を実行し、コンソールに出力されたABIを確認するには、ターミナルに移動して以下を実行します。 ```js node scripts/mint-nft.js @@ -63,61 +61,61 @@ node scripts/mint-nft.js ## ステップ4: IPFSを使用してNFTのメタデータを設定する {#config-meta} -パート1のチュートリアルを思い出してください。スマートコントラクトの`mintNFT`関数は、NFTのメタデータを記述したJSONドキュメントで解決すべきtokenURIパラメータを取り込みます。その結果、NFTが生成され、名前、記述、画像、その他の属性などの設定可能なプロパティを実装することができます。 +パート1のチュートリアルで触れたように、`mintNFT`スマートコントラクト関数は、`tokenURI`パラメータを受け取ります。このパラメータは、NFTのメタデータを記述したJSONドキュメントに解決される必要があります。このメタデータこそがNFTに命を吹き込み、名前、説明、画像、その他の属性などの設定可能なプロパティを持たせることを可能にするのです。 -> _Interplanetary File System(IPFS)は、分散型ファイルシステムでデータを格納、共有するための分散プロトコルであり、ピアツーピアネットワークです。_ +> _Interplanetary File System (IPFS) は、分散ファイルシステムでデータを保存・共有するための、分散型プロトコルでありピアツーピアネットワークです。_ -私たちは、NFTアセットとメタデータを保存してNFTを真に分散化するために、便利なIPFS APIとツールキットであるPinataを使用します。 Pinataアカウントをお持ちでない場合は、[こちら](https://app.pinata.cloud)から無料アカウントにサインアップし、メールアドレスの認証手順を完了してください。 +NFTが真に分散化されるように、便利なIPFS APIおよびツールキットであるPinataを使用して、NFTのアセットとメタデータを保存します。 Pinataのアカウントをお持ちでない場合は、[こちら](https://app.pinata.cloud)から無料アカウントにサインアップし、メールアドレスの認証手続きを完了してください。 -アカウント作成後の手順: +アカウントを作成したら: -- 「Files」ページに移動し、ページの左上にある青色の「Upload」ボタンをクリックします。 +- 「Files」ページに移動し、ページの左上にある青い「Upload」ボタンをクリックします。 -- Pinataに画像をアップロードします。これがNFTの画像アセットになります。 アセットに好きな名前を付けてください。 +- 画像をPinataにアップロードします。これがあなたのNFTの画像アセットになります。 アセットには自由に名前を付けてかまいません。 -- アップロード後、「Files」ページのテーブルにファイル情報が表示されます。 また、CID列も表示されます。 隣のコピーボタンをクリックするとCIDをコピーできます。 アップロードは`https://gateway.pinata.cloud/ipfs/`で確認できます。 例えば、IPFSで使われている画像は、[こちら](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5)です。 +- アップロード後、「Files」ページのテーブルにファイル情報が表示されます。 CID列も表示されます。 隣にあるコピーボタンをクリックすると、CIDをコピーできます。 アップロードしたファイルは `https://gateway.pinata.cloud/ipfs/` で確認できます。 例えば、私たちが使用した画像はIPFS上の[こちら](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5)にあります。 -視覚型学習者のために、上記の手順を要約します。 +視覚的に学習したい方のために、上記の手順を以下にまとめます。 ![Pinataに画像をアップロードする方法](./instructionsPinata.gif) -次に、Pinataにもう1件ドキュメントをアップロードしますが、 その前にドキュメントを作成する必要があります。 +さて、Pinataにもう一つドキュメントをアップロードします。 しかしその前に、それを作成する必要があります。 -ルートディレクトリに`nft-metadata.json`というファイルを新規作成し、以下のjsonコードを追加してください。 +ルートディレクトリに `nft-metadata.json` という新しいファイルを作成し、以下のJSONコードを追加してください。 ```json { "attributes": [ { - "trait_type": "Breed", - "value": "Maltipoo" + "trait_type": "品種", + "value": "マルプー" }, { - "trait_type": "Eye color", - "value": "Mocha" + "trait_type": "目の色", + "value": "モカ" } ], - "description": "The world's most adorable and sensitive pup.", + "description": "世界で最も愛らしくて繊細な子犬です。", "image": "ipfs://QmWmvTJmJU3pozR9ZHFmQC2DNDwi2XJtf3QGyYiiagFSWb", - "name": "Ramses" + "name": "ラムセス" } ``` -json内のデータは自由に変更できます。 属性セクションを削除または追加できます。 最も重要なことは、画像フィールドがIPFS画像の位置を指していることを確認することです。そうしないと、NFTに(とても可愛い)犬の写真が含まれます。 +JSON内のデータは自由に変更してかまいません。 `attributes`セクションは削除したり、追加したりできます。 最も重要なのは、`image`フィールドがあなたのIPFS画像の場所を指していることを確認することです。さもなければ、あなたのNFTには(とてもかわいい!) 犬の写真が含まれてしまいます。 -JSONファイルの編集が終わったら、保存して、画像のアップロードと同じ手順でPinataにアップロードしてください。 +JSONファイルの編集が終わったら保存し、画像をアップロードしたのと同じ手順でPinataにアップロードしてください。 -![nft-metadata.jsonを Pinataにアップロードする方法](./uploadPinata.gif) +![nft-metadata.jsonをPinataにアップロードする方法](./uploadPinata.gif) ## ステップ5: コントラクトのインスタンスを作成する {#instance-contract} -ここで、私たちのコントラクトと対話するには、コード内でインスタンスを作成する必要があります インスタンスの作成には、コントラクトアドレスが必要になります。コントラクトをデプロイする際に使用したアドレスを検索することで、デプロイメントまたは[Etherscan](https://sepolia.etherscan.io/)から取得できます。 +さて、コントラクトとやりとりするには、コード内でそのインスタンスを作成する必要があります。 そのためにはコントラクトアドレスが必要ですが、これはデプロイメントから取得するか、コントラクトのデプロイに使用したアドレスを[Blockscout](https://eth-sepolia.blockscout.com/)で検索することで取得できます。 -![Etherscanでコントラクトアドレスを表示する](./view-contract-etherscan.png) +![Etherscanでコントラクトアドレスを表示](./view-contract-etherscan.png) -上記の例では、コントラクトのアドレスは、0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778です。 +上記の例では、コントラクトアドレスは`0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778`です。 -次に、Web3の[コントラクトメソッド](https://docs.web3js.org/api/web3-eth-contract/class/Contract)を活用して、ABIとアドレスを使用したコントラクトを作成します。 `mint-nft.js`ファイルに以下を追加します。 +次に、ABIとアドレスを使い、Web3の[contractメソッド](https://docs.web3js.org/api/web3-eth-contract/class/Contract)でコントラクトを作成します。 `mint-nft.js`ファイルに、以下を追加します。 ```js const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" @@ -125,39 +123,39 @@ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778" const nftContract = new web3.eth.Contract(contract.abi, contractAddress) ``` -## ステップ6: `.env`ファイルをアップデートする {#update-env} +## ステップ6: `.env`ファイルを更新する {#update-env} -それでは、イーサリアムチェーンにトランザクションを作成して送信するために、公開されているイーサリアムのアカウントアドレスを使用してアカウントのノンスを取得します(以下で説明します)。 +さて、イーサリアムチェーンにトランザクションを作成して送信するために、あなたの公開イーサリアムアカウントアドレスを使用してアカウントのノンス(後述)を取得します。 -`.env`ファイルにあなたの公開鍵を追加します。チュートリアルのパート1を完了している場合、`.env`ファイルは次のようになっているはずです。 +あなたの公開鍵を`.env`ファイルに追加してください。チュートリアルのパート1を完了している場合、`.env`ファイルは次のようになっているはずです: ```js -API_URL = "https://eth-sepolia.g.alchemy.com/v2/your-api-key" -PRIVATE_KEY = "your-private-account-address" -PUBLIC_KEY = "your-public-account-address" +API_URL = "https://eth-sepolia.g.alchemy.com/v2/あなたのAPIキー" +PRIVATE_KEY = "あなたのプライベートアカウントアドレス" +PUBLIC_KEY = "あなたのパブリックアカウントアドレス" ``` ## ステップ7: トランザクションを作成する {#create-txn} -まず、`mintNFT(tokenData)`という名前の関数を定義し、次のようにトランザクションを作成してみましょう。 +まず、`mintNFT(tokenData)`という名前の関数を定義し、以下のようにトランザクションを作成します。 -1. _PRIVATE_KEY_と_PUBLIC_KEY_を`.env`ファイルから取得します。 +1. `.env`ファイルから_PRIVATE_KEY_と_PUBLIC_KEY_を取得します。 -1. 次に、アカウントのノンスを確認します。 ノンスの指定は、あなたのアドレスから送信されたトランザクションの数を追跡するために使用されます。これは、セキュリティ目的で、[リプレイ攻撃](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce)を防ぐために必要となります。 あなたのアドレスから送信されたトランザクションの数を取得するには、 [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount)を使用します。 +2. 次に、アカウントのノンスを確認する必要があります。 ノンスの仕様は、あなたのアドレスから送信されたトランザクション数を追跡するために使用されます。これは、セキュリティ上の目的と、[リプレイ攻撃](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce)を防ぐために必要です。 あなたのアドレスから送信されたトランザクション数を取得するには、[getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount)を使用します。 -1. 最後に、以下の情報を使用してトランザクションを設定します。 +3. 最後に、以下の情報でトランザクションをセットアップします。 -- `'from': PUBLIC_KEY` — トランザクションの発信元は公開アドレス +- `'from': PUBLIC_KEY` — トランザクションの発信元である、私たちの公開アドレス -- `'to': contractAddress` — 対話し、トランザクションを送信したいコントラクト +- `'to': contractAddress` — やりとりを行い、トランザクションを送信したいコントラクト -- `'nonce': nonce` — アドレスから送信されたトランザクションの数を持つアカウントのノンス +- `'nonce': nonce` — 私たちのアドレスから送信されたトランザクション数を含むアカウントのノンス -- `'gas': estimatedGas` —トランザクションを完了するために必要な推定ガス +- `'gas': estimatedGas` — トランザクションを完了するために必要な推定ガス量 -- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` — このトランザクションで実行したい計算。今回の場合は、NFTを発行すること。 +- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` — このトランザクションで実行したい計算、この場合はNFTのミント -`mint-nft.js`ファイルは、現在このような状態になっているはずです。 +`mint-nft.js`ファイルは次のようになっているはずです: ```js require('dotenv').config(); @@ -175,7 +173,7 @@ PUBLIC_KEY = "your-public-account-address" async function mintNFT(tokenURI) { const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); //get latest nonce - //the transaction + //トランザクション const tx = { 'from': PUBLIC_KEY, 'to': contractAddress, @@ -188,9 +186,9 @@ PUBLIC_KEY = "your-public-account-address" ## ステップ8: トランザクションに署名する {#sign-txn} -さて、トランザクションを作成したら、それを送信するために署名する必要があります。 ここで秘密鍵を使用します。 +トランザクションを作成したので、次に送信するために署名する必要があります。 ここで秘密鍵を使用します。 -`web3.eth.sendSignedTransaction`はトランザクションハッシュを提供することで、トランザクションがきちんとマイニングされ、ネットワークによってドロップされていないことを確認できます。 トランザクション署名のセクションにいくつかエラーチェックを追加することで、トランザクションが正常に完了したかどうかを確認できるようにしておきます。 +`web3.eth.sendSignedTransaction`はトランザクションハッシュを返します。これを使用して、トランザクションがマイニングされ、ネットワークによってドロップされなかったことを確認できます。 トランザクション署名のセクションでは、トランザクションが正常に実行されたかどうかを知るために、エラーチェックを追加していることにお気づきでしょう。 ```js require("dotenv").config() @@ -208,7 +206,7 @@ const nftContract = new web3.eth.Contract(contract.abi, contractAddress) async function mintNFT(tokenURI) { const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //get latest nonce - //the transaction + //トランザクション const tx = { from: PUBLIC_KEY, to: contractAddress, @@ -225,13 +223,13 @@ async function mintNFT(tokenURI) { function (err, hash) { if (!err) { console.log( - "The hash of your transaction is: ", + "トランザクションのハッシュ: ", hash, - "\nCheck Alchemy's Mempool to view the status of your transaction!" + "\nAlchemyのメンプールでトランザクションのステータスを確認してください!" ) } else { console.log( - "Something went wrong when submitting your transaction:", + "トランザクションの送信中に問題が発生しました:", err ) } @@ -239,24 +237,24 @@ async function mintNFT(tokenURI) { ) }) .catch((err) => { - console.log(" Promise failed:", err) + console.log(" Promiseが失敗しました:", err) }) } ``` -## ステップ9: `mintNFT`を呼び出し、ノード`mint-nft.js`を実行する {#call-mintnft-fn} +## ステップ9: `mintNFT`を呼び出し、`node mint-nft.js`を実行する {#call-mintnft-fn} -Pinataにアップロードした`metadata.json`を覚えているでしょうか。 Pinataからそのハッシュコードを取得し、`https://gateway.pinata.cloud/ipfs/`をパラメータとして、関数`mintNFT`に渡します。 +Pinataにアップロードした`metadata.json`を覚えていますか？ Pinataからそのハッシュコードを取得し、`https://gateway.pinata.cloud/ipfs/`をパラメータとして`mintNFT`関数に渡します。 -ハッシュコードを取得する方法をこちらにご紹介します。 +ハッシュコードを取得する方法は次のとおりです。 -![Pinataでnftメタデータハッシュコードを取得する方法](./metadataPinata.gif)_Pinataでnftメタデータハッシュコードを取得する方法_ +![PinataでNFTメタデータのハッシュコードを取得する方法](./metadataPinata.gif)_PinataでNFTメタデータのハッシュコードを取得する方法_ -> 別のウィンドウで`https://gateway.pinata.cloud/ipfs/`を読み込んでみて、コピーしたハッシュコードが**metadata.json**にリンクしているか確認します。 以下のスクリーンショットと類似したページが表示されるはずです。 +> 別のウィンドウで `https://gateway.pinata.cloud/ipfs/` を読み込み、コピーしたハッシュコードがあなたの**metadata.json**にリンクしていることを再確認してください。 ページは下のスクリーンショットのようになっているはずです。 -![ページにjsonメタデータが表示されるはずです](./metadataJSON.png)_ページにjsonメタデータが表示されるはずです_ +![ページにJSONメタデータが表示されるはずです](./metadataJSON.png)_ページにJSONメタデータが表示されるはずです_ -最終的には、次のようなコードになっているはずです。 +すべてをまとめると、コードは次のようになります。 ```js require("dotenv").config() @@ -274,7 +272,7 @@ const nftContract = new web3.eth.Contract(contract.abi, contractAddress) async function mintNFT(tokenURI) { const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //get latest nonce - //the transaction + //トランザクション const tx = { from: PUBLIC_KEY, to: contractAddress, @@ -291,13 +289,13 @@ async function mintNFT(tokenURI) { function (err, hash) { if (!err) { console.log( - "The hash of your transaction is: ", + "トランザクションのハッシュ: ", hash, - "\nCheck Alchemy's Mempool to view the status of your transaction!" + "\nAlchemyのメンプールでトランザクションのステータスを確認してください!" ) } else { console.log( - "Something went wrong when submitting your transaction:", + "トランザクションの送信中に問題が発生しました:", err ) } @@ -305,25 +303,27 @@ async function mintNFT(tokenURI) { ) }) .catch((err) => { - console.log("Promise failed:", err) + console.log("Promiseが失敗しました:", err) }) } mintNFT("ipfs://QmYueiuRNmL4MiA2GwtVMm6ZagknXnSpQnB3z2gWbz36hP") ``` -次に、`node scripts/mint-nft.js`を実行してNFTをデプロイします。 数秒後にターミナル上に次のようなレスポンスが表示されるはずです。 +さて、`node scripts/mint-nft.js`を実行して、NFTをミントしましょう。 数秒後、ターミナルに次のような応答が表示されるはずです。 - The hash of your transaction is: 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8 + ``` + トランザクションのハッシュ: 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8 - Alchemyのメンプールをチェックし、あなたのトランザクションのステータスを確認しましょう。 + Alchemyのメンプールでトランザクションのステータスを確認してください! + ``` -[Alchemy mempool](https://dashboard.alchemyapi.io/mempool)にアクセスして、トランザクションのステータス(保留中、マイニング中、ネットワークによってドロップされたかどうか)を確認します。 トランザクションが削除された場合は、 [Sepolia Etherscan](https://sepolia.etherscan.io/)を確認してトランザクションハッシュを検索することもできます。 +次に、[Alchemyメンプール](https://dashboard.alchemyapi.io/mempool)にアクセスして、トランザクションのステータス(ペンディング、マイニング済み、またはネットワークによるドロップ)を確認します。 トランザクションがドロップされた場合は、[Blockscout](https://eth-sepolia.blockscout.com/)でトランザクションハッシュを検索して確認することも役立ちます。 -![EtherscanでNFTトランザクションハッシュを表示する](./view-nft-etherscan.png)_EtherscanでNFTトランザクションハッシュを表示します_ +![EtherscanでNFTトランザクションハッシュを表示](./view-nft-etherscan.png)_EtherscanでNFTトランザクションハッシュを表示_ -以上で完了です。 イーサリアムブロックチェーン上にデプロイしてNFTをミントしました。 +以上です。 これで、イーサリアムブロックチェーン上でNFTをデプロイし、ミントしました -`mint-nft.js`を使えば、あなたの心(ウォレット)が望むだけ、NFTをミントすることができます。 NFTのメタデータを記述した新しいtokenURIを必ず渡してください(この作業を怠ると、異なるIDを備えた同一のものを大量に作成してしまいます)。 +`mint-nft.js`を使えば、あなた(とウォレット)が望むだけNFTをミントできます。 必ずNFTのメタデータを記述した新しい`tokenURI`を渡すようにしてください(そうしないと、IDが違うだけで同一のものを大量に作ってしまうことになります)。 -ウォレットにNFTを表示する方法については、[パート3: ウォレットにNFTを表示する方法](/developers/tutorials/how-to-view-nft-in-metamask/)をご覧ください。 +おそらく、ウォレットで自分のNFTを披露したいと思うでしょう。そのために、ぜひ[パート3: ウォレットでNFTを表示する方法](/developers/tutorials/how-to-view-nft-in-metamask/)もチェックしてください。 diff --git a/public/content/translations/ja/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md b/public/content/translations/ja/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md index af2a8e5f252..c264704dcbf 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md @@ -1,30 +1,26 @@ --- -title: Solidity で、スマートコントラクトのテスト用モックアップを作成する方法 -description: テストでは、コントラクトのモックアップを使用すべき理由 +title: "Solidity で、スマートコントラクトのテスト用モックアップを作成する方法" +description: "テストでは、コントラクトのモックアップを使用すべき理由" author: Markus Waas lang: ja -tags: - - "Solidity" - - "スマートコントラクト" - - "テスト" - - "モック" +tags: [ "Solidity", "スマートコントラクト", "テスト", "モックアップ作成" ] skill: intermediate published: 2020-05-02 source: soliditydeveloper.com sourceUrl: https://soliditydeveloper.com/mocking-contracts --- -[モック・オブジェクト](https://wikipedia.org/wiki/Mock_object) は、オブジェクト指向プログラミングにおいて一般的なデザインパターンです。 「モック」という言葉は、古フランス語で「からかう」という意味を持つ「mocquer」が由来で、「本物を模倣する」という意味に発展しました。これこそ、プログラミングにで「モックアップ」を作成する作業です。 あなたが作成したスマートコントラクトについて「からかう」必要はありませんが、「モックアップ」の作成はできる限り必ず行ってください。 後々、楽になります。 +「[モックオブジェクト](https://wikipedia.org/wiki/Mock_object)」は、オブジェクト指向プログラミングにおいて一般的なデザインパターンです。 「モック」という言葉は、古フランス語で「からかう」という意味を持つ「mocquer」が由来で、「本物を模倣する」という意味に発展しました。これこそ、プログラミングにで「モックアップ」を作成する作業です。 あなたが作成したスマートコントラクトについて「からかう」必要はありませんが、「モックアップ」の作成はできる限り必ず行ってください。 後々、楽になります。 -## コントラクトのモックアップを使った単体テスト {#unit-testing-contracts-with-mocks} +## モックを使ったコントラクトの単体テスト {#unit-testing-contracts-with-mocks} -コントラクトのモックアップを作成するとは、究極的に、オリジナルとほぼ同様に動作するものの、デベロッパが簡単に管理できる第2のバージョンを作成することです。 複雑なコントラクトを開発すると、[コントラクト全体の一部のみを単体テストする](/developers/docs/smart-contracts/testing/)必要が発生する場合が少なくありません。 問題となるのは、この一部分をテストする上で、非常に具体的なコントラクトの状態を再現する必要があるものの、再現するのが難しい場合です。 +コントラクトのモックアップを作成するとは、究極的に、オリジナルとほぼ同様に動作するものの、デベロッパが簡単に管理できる第2のバージョンを作成することです。 複雑なコントラクトを扱うことになると、[コントラクトのごく一部だけを単体テスト](/developers/docs/smart-contracts/testing/)したい場合がよくあります。 問題となるのは、この一部分をテストする上で、非常に具体的なコントラクトの状態を再現する必要があるものの、再現するのが難しい場合です。 テストに求められる状態を再現するために、テストを設定するための複雑なロジックを作成する代わりに、モックアップを作成すればよいのです。 コントラクトのモックアップは、継承を使って簡単に作成できます。 オリジナル版を継承したモックアップのコントラクトを作成するだけです。 モックアップでは、機能をオーバーライドすることができます。 この点については、具体例で見てみましょう。 -## 例：プライベートのERC-20コントラクト {#example-private-erc20} +## 例: Private ERC20 {#example-private-erc20} -ここでは、当初にプライベート期間が設定された ERC-20 コントラクトを使って説明します。 トークン所有者はプライベートユーザーを管理でき、当初トークンを受け取ることができるのはプライベートユーザーのみになります。 設定した時間が経過した後は、すべてのユーザーがトークンを使用できるようになります。 参考までに、この例では新しいOpenZeppelinコントラクトv3に含まれている[`_beforeTokenTransfer`](https://docs.openzeppelin.com/contracts/5.x/extending-contracts#using-hooks)フックを使用しています。 +ここでは、当初にプライベート期間が設定された ERC-20 コントラクトを使って説明します。 トークン所有者はプライベートユーザーを管理でき、当初トークンを受け取ることができるのはプライベートユーザーのみになります。 設定した時間が経過した後は、すべてのユーザーがトークンを使用できるようになります。 ちなみに、新しいOpenZeppelin contracts v3の[`_beforeTokenTransfer`](https://docs.openzeppelin.com/contracts/5.x/extending-contracts#using-hooks)フックを使用しています。 ```solidity pragma solidity ^0.6.0; @@ -90,17 +86,17 @@ contract PrivateERC20Mock is PrivateERC20 { - `PrivateERC20Mock.sol: TypeError: Overriding function is missing "override" specifier.` - `PrivateERC20.sol: TypeError: Trying to override non-virtual function. Did you forget to add "virtual"?.` -Solidityの新しいバージョン（0.6）を使用しているため、オーバーライド可能な関数については`virtual`のキーワードを追加して、オーバーライド関数をオーバーライドする必要があります。 このため、両方の`isPublic`関数にこのキーワードを追加します。 +新しいSolidityバージョン0.6を使用しているため、オーバーライドされる関数には`virtual`キーワードを、オーバーライドする関数には`override`を追加する必要があります。 では、両方の`isPublic`関数にそれらを追加しましょう。 -これで、単体テストで`PrivateERC20Mock`を使えるようになりました。 プライベート利用期間中の動作をテストしたい場合は、`setIsPublic(false)`を使用し、パブリック利用期間については`setIsPublic(true)`を使ってテストしてください。 もちろん、[time helpers](https://docs.openzeppelin.com/test-helpers/0.5/api#increase)を使って、対象時間を変更することもできます。 しかし、すでにモックアップの有用性について理解できたでしょう。単に時間を進めるよりも、モックアップを利用した方が望ましいシナリオがすぐに思い浮かぶはずです。 +これで、単体テストで代わりに`PrivateERC20Mock`を使用できます。 プライベート利用期間中の動作をテストしたい場合は`setIsPublic(false)`を、同様にパブリック利用期間のテストには`setIsPublic(true)`を使用します。 もちろん、この例では[タイムヘルパー](https://docs.openzeppelin.com/test-helpers/0.5/api#increase)を使って、時間も同様に変更することもできます。 しかし、すでにモックアップの有用性について理解できたでしょう。単に時間を進めるよりも、モックアップを利用した方が望ましいシナリオがすぐに思い浮かぶはずです。 -## 複数のコントラクトに対してモックアップを作成する場合 {#mocking-many-contracts} +## 多数のコントラクトのモック {#mocking-many-contracts} -モックアップごとに新たなコントラクトを作成するのは煩雑な作業ですね。 これを避けたい場合は、[MockContract](https://github.com/gnosis/mock-contract)ライブラリを参照してください。 このライブラリを用いることで、コントラクトの動作をその場でオーバーライドし、変更することができます。 ただしこのライブラリは、別のコントラクトに対する呼び出しのみに対応していますので、今回は使用できません。 +モックアップごとに新たなコントラクトを作成するのは煩雑な作業ですね。 これが気になる場合は、[MockContract](https://github.com/gnosis/mock-contract)ライブラリをご覧ください。 これにより、コントラクトの動作をその場でオーバーライドして変更できます。 ただしこのライブラリは、別のコントラクトに対する呼び出しのみに対応していますので、今回は使用できません。 -## モックアップは、その他にも利点があります {#mocking-can-be-even-more-powerful} +## モックはさらに強力になりうる {#mocking-can-be-even-more-powerful} モックアップ作成のメリットは、他にもあります。 -- 関数の追加：特定の関数をオーバーライドする機能だけでなく、関数を追加できることも有益です。 トークンを対象とする場合のよい例としては、`ミント`機能を追加することで、ユーザーが新規トークンを無料で手に入れられるようにすることができます。 +- 関数の追加：特定の関数をオーバーライドする機能だけでなく、関数を追加できることも有益です。 トークンの良い例として、追加の`mint`関数を持たせることで、どのユーザーでも新しいトークンを無料で取得できるようにすることが挙げられます。 - テストネットでの使用：Dapp と共に、テストネット上でコントラクトをデプロイ、テストする際は、モックアップの活用を検討すべきです。 本当に必要な場合を除き、関数をオーバーライドすることは避けるべきです。 結局のところ、実際のロジックをテストする必要があるからです。 しかし例えば、コントラクトのステートを、新たにデプロイする必要なしで開始時点にリセットするだけのリセット機能は、有益な場合があるでしょう。 言うまでもなく、メインネット用のコントラクトにはこのようなリセット機能を含めてはなりません。 diff --git a/public/content/translations/ja/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/translations/ja/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md index e481f540dfb..717f159151b 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md @@ -1,17 +1,12 @@ --- -title: スマートコントラクトのテストにEchidnaを使用する方法 -description: Echidnaを使用して、スマートコントラクトを自動でテストする方法 +title: "Echidnaを使用してスマートコントラクトをテストする方法" +description: "Echidnaを使用してスマートコントラクトを自動テストする方法" author: "Trailofbits" lang: ja -tags: - - "Solidity" - - "スマートコントラクト" - - "セキュリティ" - - "テスト" - - "ファジング" +tags: [ "Solidity", "スマートコントラクト", "セキュリティ", "テスト", "ファジング" ] skill: advanced published: 2020-04-10 -source: セキュアなコントラクトの構築 +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna --- @@ -19,53 +14,53 @@ sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/progr Echidnaは、Dockerまたはコンパイル済みのバイナリを使用してインストールします。 -### DockerからEchidnaをインストールする {#echidna-through-docker} +### DockerによるEchidna {#echidna-through-docker} ```bash docker pull trailofbits/eth-security-toolbox docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox ``` -_最後のコマンドは、現在のディレクトリにアクセスできるdockerでeth-security-toolboxを実行します。 ホストからファイルを変更し、dockerからファイル上のツールを実行できます。_ +_最後のコマンドは、現在のディレクトリにアクセスできるDockerでeth-security-toolboxを実行します。 ホストからファイルを変更し、Dockerからファイル上のツールを実行できます。_ -dockerで、以下を実行します： +Docker内で次を実行します： ```bash solc-select 0.5.11 cd /home/training ``` -### バイナリの入手先 {#binary} +### バイナリ {#binary} [https://github.com/crytic/echidna/releases/tag/v1.4.0.0](https://github.com/crytic/echidna/releases/tag/v1.4.0.0) -## プロパティベースのファジングとは {#introduction-to-property-based-fuzzing} +## プロパティベースファジング入門 {#introduction-to-property-based-fuzzing} -Echidnaは、プロパティベースのファザーです。これについては、以前のブログ投稿（[1](https://blog.trailofbits.com/2018/03/09/echidna-a-smart-fuzzer-for-ethereum/)、[2](https://blog.trailofbits.com/2018/05/03/state-machine-testing-with-echidna/)、[3](https://blog.trailofbits.com/2020/03/30/an-echidna-for-all-seasons/)）を参照してください。 +Echidnaはプロパティベースのファザーであり、以前のブログ投稿([1](https://blog.trailofbits.com/2018/03/09/echidna-a-smart-fuzzer-for-ethereum/)、[2](https://blog.trailofbits.com/2018/05/03/state-machine-testing-with-echidna/)、[3](https://blog.trailofbits.com/2020/03/30/an-echidna-for-all-seasons/))で説明しています。 ### ファジング {#fuzzing} -[ファジング ](https://wikipedia.org/wiki/Fuzzing)は、セキュリティコミュニティでよく知られているテクニックです。 ファジングでは、プログラム内のバグを見つけるために、大小のランダムな入力を生成することを行います。 通常のソフトウェアを対象とするファザー（[AFL](http://lcamtuf.coredump.cx/afl/)や[LibFuzzer](https://llvm.org/docs/LibFuzzer.html)など）は、効率的にバグを特定できるツールであると評価されています。 +[ファジング](https://wikipedia.org/wiki/Fuzzing)は、セキュリティコミュニティでよく知られているテクニックです。 プログラム内のバグを見つけるために、ある程度ランダムな入力を生成するものです。 従来のソフトウェア用のファザー（[AFL](http://lcamtuf.coredump.cx/afl/)や[LibFuzzer](https://llvm.org/docs/LibFuzzer.html)など）は、バグを見つけるための効率的なツールとして知られています。 -入力をまったくランダムに生成するだけでなく、適切な入力を生成するための多くのテクニックや戦略を活用できます： +純粋にランダムな入力生成以外に、適切な入力を生成するための多くのテクニックや戦略があります。以下に例を挙げます。 -- 各実行から取得したフィードバックに基づき、入力を生成する。 例えば、新しく生成された入力値が新しいパスの発見を導いている場合、それに近い新しい入力値を生成することは理にかなっています。 -- 構造上の制約を考慮した入力を生成する。 例えば、入力にチェックサム付のヘッダーが含まれている場合、ファザーにチェックサムを検証する入力を生成させることも有益です。 -- 既知の入力に基づいて新たな入力を生成する。大規模な有効な入力のデータセットにアクセスできる場合、まったくランダムに生成するのではなく、それらに基づいて新たな入力を生成することができます。 この場合、参照するデータを_シード_と呼びます。 +- 各実行からフィードバックを取得し、それを使用して生成をガイドします。 例えば、新しく生成された入力が新しいパスの発見につながる場合、それに近い新しい入力を生成することは理にかなっています。 +- 構造的制約を尊重して入力を生成する。 例えば、入力にチェックサム付きのヘッダーが含まれている場合、ファザーにチェックサムを検証する入力を生成させるのは理にかなっています。 +- 既知の入力を使用して新しい入力を生成する：有効な入力の大規模なデータセットにアクセスできる場合、ファザーはゼロから生成を開始するのではなく、それらから新しい入力を生成できます。 これらは通常、_シード_と呼ばれます。 -### プロパティベースのファジング {#property-based-fuzzing} +### プロパティベースファジング {#property-based-fuzzing} -Echidnaは、プロパティに基づくファジングを実行するファザーであり、[QuickCheck](https://wikipedia.org/wiki/QuickCheck)の影響を強く受けたプログラムです。 クラッシュを監視する従来のファザーとは異なり、Echidnaでは、ユーザー定義の不変条件を壊そうとします。 +Echidnaは、[QuickCheck](https://wikipedia.org/wiki/QuickCheck)に強くインスパイアされたプロパティベースファジングという、ファザーの特定の種類に属します。 クラッシュを見つけようとする従来のファザーとは対照的に、Echidnaはユーザー定義の不変条件を破ろうとします。 -スマートコントラクトにおける不変条件とは、コントラクトにおいて不適切または無効な状態が発生しうるSolidityの関数を意味します。具体的には、以下が挙げられます： +スマートコントラクトにおける不変条件とは、コントラクトが到達しうる不正または無効な状態を表すSolidity関数であり、次のようなものが含まれます。 -- 不適切なアクセス制御：攻撃者がコントラクトの所有者になる場合。 -- 不適切な状態マシン：コントラクトの一次停止中に、トークンを送信できる。 -- 不適切な計算: ユーザーは残高をアンダーフローし無制限に無料トークンを取得できる。 +- 不正なアクセス制御：攻撃者がコントラクトの所有者になる。 +- 不正な状態マシン：コントラクトが一時停止している間にトークンを転送できる。 +- 不正な算術演算：ユーザーが残高をアンダーフローさせ、無制限の無料トークンを取得できる。 -### Echidnaを使って、プロパティをテストする {#testing-a-property-with-echidna} +### Echidnaでプロパティをテストする {#testing-a-property-with-echidna} -それでは、Echidnaを使ってスマートコントラクトをテストする方法を見てみましょう。 対象は、[ `token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol)のスマートコントラクトです。 +Echidnaを使ってスマートコントラクトをテストする方法を見ていきましょう。 対象は、次のスマートコントラクト[`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol)です。 ```solidity contract Token{ @@ -83,26 +78,26 @@ contract Token{ } ``` -このトークンは、以下のプロパティを持つと想定します： +このトークンは、以下のプロパティを持つと想定します。 -- ユーザーは、最大1000トークンを所持できる -- このトークン（ERC-20トークンではない）は、送信不可である +- 誰でも最大1000トークンを保有できます +- このトークンは転送できません（ERC20トークンではありません） ### プロパティを記述する {#write-a-property} -Echidnaのプロパティは、Solidityの関数です。 プロパティは、以下の条件を満たす必要があります： +Echidnaのプロパティは、Solidityの関数です。 プロパティは、以下の条件を満たす必要があります。 - 引数を持たない -- 実行に成功した場合、 `true` を返す -- `echidna`で始まる名前を持つ +- 成功した場合に`true`を返す +- 名前が`echidna`で始まる -Echidnaは、以下を実行します： +Echidnaは、以下を実行します。 -- このプロパティをテストするためのランダムなトランザクションを自動で生成する。 -- プロパティが `false`またはエラーを返すすべてのトランザクションを報告する。 -- プロパティの呼び出しに伴う副作用を無視する（つまり、プロパティが状態変数を変更した場合、テスト後にこの変更を破棄する） +- プロパティをテストするために、任意のトランザクションを自動的に生成します。 +- プロパティが`false`を返すか、エラーをスローするトランザクションを報告します。 +- プロパティ呼び出し時の副作用を破棄する（つまり、プロパティが状態変数を変更した場合、テスト後にその変更は破棄されます） -以下のプロパティは、呼び出し元のユーザーが所持するトークンが1000以下であることを確認します。 +以下のプロパティは、呼び出し元が1000トークンを超えて保有していないことをチェックします。 ```solidity function echidna_balance_under_1000() public view returns(bool){ @@ -120,36 +115,36 @@ contract TestToken is Token{ } ``` -[`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol)は、プロパティを実装し、このトークンを継承します。 +[`token.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/token.sol)はプロパティを実装し、トークンを継承します。 -### コントラクトを開始する {#initiate-a-contract} +### コントラクトの初期化 {#initiate-a-contract} -Echidnaでは、引数なしの[コンストラクタ](/developers/docs/smart-contracts/anatomy/#constructor-functions)が必要です。 コントラクトにおいて特定の初期化が必要な場合、コンストラクタ上で実行する必要があります。 +Echidnaには、引数のない[コンストラクタ](/developers/docs/smart-contracts/anatomy/#constructor-functions)が必要です。 コントラクトに特定の初期化が必要な場合、コンストラクタで行う必要があります。 -Echidnaには、いくつかの特定のアドレスが含まれます： +Echidnaには、いくつかの特定のアドレスが含まれます。 -- `0x00a329c0648769A73afAc7F9381E08FB43dBEA72`：コンストラクタを呼び出すアドレスです。 -- `0x10000`、`0x20000`、`0x00a329C0648769a73afAC7F9381e08fb43DBEA70`：他の関数をランダムに呼び出すアドレスです。 +- `0x00a329c0648769A73afAc7F9381E08FB43dBEA72`はコンストラクタを呼び出します。 +- `0x10000`、`0x20000`、および`0x00a329C0648769a73afAC7F9381e08fb43DBEA70`は、他の関数をランダムに呼び出します。 -このチュートリアルでは特定の初期化を実行する必要がないため、コンストラクタは空になります。 +この例では特定の初期化は必要ないため、コンストラクタは空になります。 -### Echidnaを実行する {#run-echidna} +### Echidnaの実行 {#run-echidna} -以下のコードで、Echidnaを起動します： +Echidnaは次のように起動します。 ```bash echidna-test contract.sol ``` -contract.solに複数のコントラクトが含まれる場合、実行したいコントラクトを指定できます： +contract.solに複数のコントラクトが含まれる場合、対象を指定できます。 ```bash echidna-test contract.sol --contract MyContract ``` -### プロパティテストのまとめ {#summary-testing-a-property} +### まとめ：プロパティのテスト {#summary-testing-a-property} -以下は、このチュートリアルにおけるEchidnaの実行をまとめたものです。 +以下は、この例におけるEchidnaの実行をまとめたものです。 ```solidity contract TestToken is Token{ @@ -172,11 +167,12 @@ echidna_balance_under_1000: failed!💥 ... ``` -Echidnaは、 `backdoor`が呼び出された場合、このプロパティが侵害されることを確認しました。 +Echidnaは、`backdoor`が呼び出された場合にプロパティが違反することを発見しました。 -## ファジング中に呼び出す関数を絞り込む {#filtering-functions-to-call-during-a-fuzzing-campaign} +## ファジングキャンペーン中に呼び出す関数をフィルタリングする {#filtering-functions-to-call-during-a-fuzzing-campaign} -ファジングの対象となる関数を絞り込む方法を見ていきましょう。 以下のスマートコントラクトを対象とします： +ファジング対象となる関数をフィルタリングする方法を見ていきましょう。 +対象は、次のスマートコントラクトです。 ```solidity contract C { @@ -227,7 +223,9 @@ contract C { } ``` -この簡単な例は、状態変数を変更する特定のトランザクションのシーケンスをEchidnaに見つけさせるものです。 これは、ファザーにとって容易ではありません（[Manticore](https://github.com/trailofbits/manticore)のようなシンボリック実行ツールを使用することをお勧めします）。 Echidnaで、以下のように検証を実行します： +この簡単な例は、状態変数を変更する特定のトランザクションのシーケンスをEchidnaに見つけさせるものです。 +これはファザーにとって困難です（[Manticore](https://github.com/trailofbits/manticore)のようなシンボリック実行ツールの使用が推奨されます）。 +Echidnaを実行して、これを確認できます。 ```bash echidna-test multi.sol @@ -236,30 +234,32 @@ echidna_state4: passed! 🎉 Seed: -3684648582249875403 ``` -### 対象の関数を絞り込む {#filtering-functions} +### 関数のフィルタリング {#filtering-functions} -2つのリセット関数（`reset1`と`reset2`）がすべての状態変数を`false`に設定するため、Echidnaはこのコントラクトをテストするための正しいシーケンスを見つけられません。 しかしEchidnaでは、リセット関数をブラックリストに含めるか、 `f`、`g`、 `h`、および `i`の関数のみをホワイトリストに含める特別の機能が利用できます。 +2つのリセット関数（`reset1`と`reset2`）がすべての状態変数を`false`に設定するため、Echidnaがこのコントラクトをテストするための正しいシーケンスを見つけるのは困難です。 +しかし、Echidnaの特別な機能を使用して、リセット関数をブラックリストに登録するか、`f`、`g`、 +`h`、`i`関数のみをホワイトリストに登録することができます。 -関数をブラックリストに登録するには、設定ファイルを以下のように指定します： +関数をブラックリストに登録するには、この設定ファイルを使用します。 ```yaml filterBlacklist: true filterFunctions: ["reset1", "reset2"] ``` -関数を絞り込むもう一つの方法は、ホワイトリストに含まれる関数を列挙することです。 これには、設定ファイルを以下のように指定します： +関数をフィルタリングするもう1つのアプローチは、ホワイトリストに登録された関数をリストアップすることです。 そのためには、この設定ファイルを使用します。 ```yaml filterBlacklist: false filterFunctions: ["f", "g", "h", "i"] ``` -- `filterBlacklist`の初期値は`true`です。 -- 絞り込みは、名前のみ（パラメータなし）で実行されます。 `f()`と`f(uint256)`の両方が含まれる場合、`"f"`で絞り込むと両方の関数がヒットします。 +- `filterBlacklist`のデフォルト値は`true`です。 +- フィルタリングは、名前のみ（パラメータなし）で実行されます。 `f()`と`f(uint256)`の両方がある場合、フィルタ`"f"`は両方の関数にマッチします。 -### Echidnaを実行する {#run-echidna-1} +### Echidnaの実行 {#run-echidna-1} -設定ファイル `blacklist.yaml` に従ってEchidnaを実行するには、以下のようにします： +Echidnaを構成ファイル`blacklist.yaml`で実行するには、次のようにします。 ```bash echidna-test multi.sol --config blacklist.yaml @@ -272,11 +272,11 @@ echidna_state4: failed!💥 i() ``` -Echidnaは、プロパティをfalseにするトランザクションのシーケンスを瞬時に特定します。 +Echidnaは、プロパティを偽にするトランザクションのシーケンスをほぼ瞬時に見つけます。 -### 対象の関数を絞り込む作業のまとめ {#summary-filtering-functions} +### まとめ：関数のフィルタリング {#summary-filtering-functions} -Echidnaでは、ファジングで呼び出す機能を絞り込むために、ブラックリストあるいはホワイトリストの関数を使用します： +Echidnaは、ファジングキャンペーン中に呼び出す関数を、以下を使用してブラックリストまたはホワイトリストに登録できます。 ```yaml filterBlacklist: true @@ -288,11 +288,11 @@ echidna-test contract.sol --config config.yaml ... ``` -Echidnaは、`filterBlacklist`のブール値に基づき、`f1`、`f2`、および `f3`の関数をブラックリストに含めるか、これらの関数のみを呼び出してファジングを実行します。 +Echidnaは、`filterBlacklist`ブール値の値に応じて、`f1`、`f2`、`f3`をブラックリストに登録するか、これらのみを呼び出すファジングキャンペーンを開始します。 ## EchidnaでSolidityのアサーションをテストする方法 {#how-to-test-soliditys-assert-with-echidna} -次の短いチュートリアルでは、Echidnaを使って、コントラクトに含まれるアサーションをテストします。 以下のようなコントラクトを想定します： +この短いチュートリアルでは、Echidnaを使用してコントラクトのアサーションチェックをテストする方法を説明します。 以下のようなコントラクトを想定します。 ```solidity contract Incrementor { @@ -309,7 +309,7 @@ contract Incrementor { ### アサーションを記述する {#write-an-assertion} -引き算を実行した後に、`tmp`の値が`counter`の値以下であることを確認したいとします。 Echidnaのプロパティで記述することもできますが、`tmp`値をどこかに格納する必要があります。 これには、以下のようなアサーションを用いることができます： +その差を返した後に、`tmp`が`counter`以下であることを確認したいと思います。 Echidnaのプロパティを記述することもできますが、`tmp`の値をどこかに保存する必要があります。 代わりに、このようなアサーションを使用できます。 ```solidity contract Incrementor { @@ -324,15 +324,15 @@ contract Incrementor { } ``` -### Echidnaを実行する {#run-echidna-2} +### Echidnaの実行 {#run-echidna-2} -アサーションの失敗をテストできるようにするには、[Echidnaの設定ファイル](https://github.com/crytic/echidna/wiki/Config)として `config.yaml` を作成します： +アサーション失敗テストを有効にするには、[Echidna設定ファイル](https://github.com/crytic/echidna/wiki/Config) `config.yaml`を作成します。 ```yaml checkAsserts: true ``` -このコントラクトをEchidnaで実行すると、次のような期待通りの結果が得られます： +このコントラクトをEchidnaで実行すると、期待通りの結果が得られます。 ```bash echidna-test assert.sol --config config.yaml @@ -346,11 +346,11 @@ assertion in inc: failed!💥 Seed: 1806480648350826486 ``` -このように、Echidnaでは、アサーション違反の一部を`inc`関数で報告します。 1つの関数に対し複数のアサーションを含めることは可能ですが、どのアサーションが失敗したのか区別できなくなります。 +ご覧のとおり、Echidnaは`inc`関数でのアサーションの失敗を報告します。 1つの関数に複数のアサーションを追加することは可能ですが、Echidnaはどのアサーションが失敗したかを特定できません。 -### アサーションをいつ、どのように使用すべきか {#when-and-how-use-assertions} +### アサーションを使用する状況とその方法 {#when-and-how-use-assertions} -アサーションは、特にチェックしたい条件が`f`という特定の操作を適切に用いることと直接関係する場合に、プロパティを明示しない代替手段として用いることができます。 コードにアサーションを追加することで、このコードを実行した直後に強制的にチェックが実行されます。 +アサーションは、特にチェック対象の条件が何らかの操作`f`の正しい使用に直接関連する場合、明示的なプロパティの代替として使用できます。 コードの後にアサーションを追加すると、そのコードが実行された直後にチェックが強制的に行われます。 ```solidity function f(..) public { @@ -362,7 +362,7 @@ function f(..) public { ``` -反対に、Echidnaのプロパティを明示的に使用する場合、トランザクションがランダムに実行されるため、チェックをどの時点で強制的に実行させるかを決定しにくくなります。 この場合、以下のような回避策を用いることもできます： +対照的に、明示的なEchidnaプロパティを使用すると、トランザクションがランダムに実行され、いつチェックされるかを正確に強制する簡単な方法はありません。 この回避策を行うことは依然として可能です。 ```solidity function echidna_assert_after_f() public returns (bool) { @@ -371,22 +371,22 @@ function echidna_assert_after_f() public returns (bool) { } ``` -しかし、以下の問題点が残ります： +しかし、いくつかの問題があります。 -- `f`が`internal`あるいは`external`と宣言されている場合、違反になる。 -- どの引数を使って`f`を呼び出すべきかが不明確である。 -- `f`が元に戻された場合、このプロパティは違反になる。 +- `f`が`internal`または`external`として宣言されている場合は失敗します。 +- `f`を呼び出すのにどの引数を使用すべきかが不明確です。 +- `f`がリバートされると、プロパティは失敗します。 -全般的なアサーションの使用については、この[John Regehrの提案](https://blog.regehr.org/archives/1091)に従うことを推奨します： +一般に、アサーションの使用方法については、[John Regehr氏の推奨事項](https://blog.regehr.org/archives/1091)に従うことをお勧めします。 -- アサーションチェック中には、副作用を強制しない。 例：`assert(ChangeStateAndReturn() == 1)` -- 明らかなステートメントは、アサートしない。 例：`var`を`uint`と宣言している場合、`assert(var >= 0)`は必要ない。 +- アサーションチェック中に副作用を強制しないでください。 例：`assert(ChangeStateAndReturn() == 1)` +- 明らかなステートメントをアサートしないでください。 例えば、`var`が`uint`として宣言されている場合の`assert(var >= 0)`などです。 -最後に、`assert`の代わりに`require`を用いるのは**避けてください**。Echidnaではrequireを検出できません。（ただしこの場合でも、コントラクトは元に戻されます）。 +最後に、`assert`の代わりに`require`を**使用しないでください**。Echidnaはそれを検出できません（ただし、コントラクトはいずれにしてもリバートします）。 -### アサーションチェックのまとめ {#summary-assertion-checking} +### まとめ：アサーションチェック {#summary-assertion-checking} -以下は、この例におけるEchidnaの実行をまとめたものです： +以下は、この例におけるEchidnaの実行をまとめたものです。 ```solidity contract Incrementor { @@ -413,11 +413,11 @@ assertion in inc: failed!💥 Seed: 1806480648350826486 ``` -Echidnaは、`inc`のアサーションにつき、この関数が大きな引数で複数回呼び出された場合に違反となりうることを発見しました。 +Echidnaは、`inc`のアサーションが、この関数が大きな引数で複数回呼び出された場合に失敗する可能性があることを見つけました。 -## Echidnaコーパスを収集、修正する {#collecting-and-modifying-an-echidna-corpus} +## Echidnaコーパスの収集と変更 {#collecting-and-modifying-an-echidna-corpus} -次に、Echidnaを使ってトランザクションのコーパスを収集し、これを利用する方法について見ていきましょう。 対象は、[`magic.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/magic.sol)のスマートコントラクトです。 +Echidnaを使ってトランザクションのコーパスを収集し、利用する方法について見ていきましょう。 対象は、次のスマートコントラクト[`magic.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/example/magic.sol)です。 ```solidity contract C { @@ -437,7 +437,9 @@ contract C { } ``` -以下の短いコードは、状態変数を変更する特定の値をEchidnaに発見させます。 これは、ファザーにとって容易ではありません（[Manticore](https://github.com/trailofbits/manticore)のようなシンボリック実行ツールを使用することをお勧めします）。 Echidnaで、以下のように検証を実行します： +この簡単な例では、状態変数を変更するために、Echidnaに特定の値を探索させます。 これはファザーにとって困難です +（[Manticore](https://github.com/trailofbits/manticore)のようなシンボリック実行ツールの使用が推奨されます）。 +Echidnaを実行して、これを確認できます。 ```bash echidna-test magic.sol @@ -448,30 +450,31 @@ echidna_magic_values: passed! 🎉 Seed: 2221503356319272685 ``` -ただしEchidnaでは、ファジングの実行中もコーパスを収集することができます。 +しかし、このファジングキャンペーンの実行中にEchidnaを使用してコーパスを収集することは依然として可能です。 -### コーパスを収集する {#collecting-a-corpus} +### コーパスの収集 {#collecting-a-corpus} -コーパスを収集するには、まずコーパスのディレクトリを作成します： +コーパス収集を有効にするには、コーパスディレクトリを作成します。 ```bash mkdir corpus-magic ``` -さらに、[Echidnaの設定ファイル](https://github.com/crytic/echidna/wiki/Config)である `config.yaml` を作成します： +そして、[Echidna設定ファイル](https://github.com/crytic/echidna/wiki/Config)である`config.yaml`を作成します。 ```yaml coverage: true corpusDir: "corpus-magic" ``` -これで、ツールを実行しながら収集したコーパスをチェックできるようになりました： +これでツールを実行し、収集したコーパスを確認できます。 ```bash echidna-test magic.sol --config config.yaml ``` -この段階ではEchidnaはまだ適切なmagic値を特定できませんが、収集したコーパスを確認することはできます。 例えば、以下のようなファイルが収集されました： +Echidnaはまだ正しいマジック値を見つけることができませんが、収集したコーパスを見ることができます。 +例えば、これらのファイルの1つは次のとおりでした。 ```json [ @@ -516,17 +519,18 @@ echidna-test magic.sol --config config.yaml ] ``` -言うまでもなく、この入力はプロパティ違反をトリガーしません。 しかし、次のステップでこれを修正することができます。 +明らかに、この入力はプロパティの失敗をトリガーしません。 しかし、次のステップでは、そのためにこれを変更する方法を見ていきます。 -### コーパスをシードする {#seeding-a-corpus} +### コーパスのシーディング {#seeding-a-corpus} -Echidnaを`magic`関数に対応するように設定する必要があります。 この入力が適切なパラメータを使用できるように、コピーし、変更します。 +`magic`関数を扱うために、Echidnaには少し助けが必要です。 入力をコピーして変更し、適切な +パラメータを使用するようにします。 ```bash cp corpus/2712688662897926208.txt corpus/new.txt ``` -`magic(42,129,333,0)`を呼び出せるように`new.txt`を変更します。 その上で、Echidnaを再実行します： +`new.txt`を`magic(42,129,333,0)`を呼び出すように変更します。 これでEchidnaを再実行できます。 ```bash echidna-test magic.sol --config config.yaml @@ -542,11 +546,11 @@ Seed: -7293830866560616537 ``` -今回は、プロパティ違反がただちに検出されました。 +今回は、プロパティが即座に違反していることがわかりました。 -## ガス消費量が多いトンラザクションを見つける {#finding-transactions-with-high-gas-consumption} +## ガス消費量の多いトランザクションの発見 {#finding-transactions-with-high-gas-consumption} -ガス消費量が多いトランザクションを特定するために、Echidnaを使用する方法について見ていきましょう。 対象は、次のスマートコントラクトです： +Echidnaを使用してガス消費量が多いトランザクションを見つける方法を見ていきましょう。 対象は、次のスマートコントラクトです。 ```solidity contract C { @@ -571,9 +575,10 @@ contract C { } ``` -ここでは、`expensive`でガス消費量が高くなる可能性があります。 +ここで`expensive`は大きなガス消費量を持つ可能性があります。 -この時点では、Echidna上で常にテストすべきプロパティを設定する必要があり、`echidna_test`は常に`true`を返します。 Echidnaを実行して、これを確認します： +現在、Echidnaは常にテスト対象のプロパティを必要とします。ここでは`echidna_test`が常に`true`を返します。 +Echidnaを実行して、これを確認できます。 ``` echidna-test gas.sol @@ -583,24 +588,24 @@ echidna_test: passed! 🎉 Seed: 2320549945714142710 ``` -### ガス消費量を測定する {#measuring-gas-consumption} +### ガス消費量の測定 {#measuring-gas-consumption} -Ethidnaでガスの消費量を確認できるようにするには、 `config.yaml`を以下のように設定します： +Echidnaでガス消費を有効にするには、設定ファイル`config.yaml`を作成します。 ```yaml estimateGas: true ``` -この例では、結果を分かりやすくするために、次のようにトランザクションシーケンスのサイズを減らしています。 +この例では、結果を理解しやすくするために、トランザクションシーケンスのサイズも小さくします。 ```yaml seqLen: 2 estimateGas: true ``` -### Echidnaを実行する {#run-echidna-3} +### Echidnaの実行 {#run-echidna-3} -設定が完了したら、次のようにEchidnaを実行します： +設定ファイルが作成されたら、次のようにEchidnaを実行できます。 ```bash echidna-test gas.sol --config config.yaml @@ -617,12 +622,13 @@ Seed: -325611019680165325 ``` -- 表示されたガス量は、[HEVM](https://github.com/dapphub/dapptools/tree/master/src/hevm#hevm-)による見積もりです。 +- 表示されるガスは、[HEVM](https://github.com/dapphub/dapptools/tree/master/src/hevm#hevm-)によって提供される推定値です。 -### ガス量を削減する呼び出しを対象外にする {#filtering-out-gas-reducing-calls} +### ガスを削減する呼び出しの除外 {#filtering-out-gas-reducing-calls} -**ファジング実行時に呼び出す関数を絞り込む方法**のチュートリアルでは、特定の関数をテストの対象外にする方法を示しました。 -この作業は、ガス量を正確に見積もる上で非常に重要です。 以下の例を検討してみましょう： +上記の「**ファジングキャンペーン中に呼び出す関数のフィルタリング**」のチュートリアルでは、テストからいくつかの関数を削除する方法を示しています。 +これは、正確なガス見積もりを得るために重要となる場合があります。 +次の例を考えてみましょう。 ```solidity contract C { @@ -648,7 +654,7 @@ contract C { } ``` -Echidnaがすべての関数を呼び出せる場合、ガス代が高いトランザクションを見つけることは困難になるでしょう。 +Echidnaがすべての関数を呼び出せる場合、ガス代が高いトランザクションを簡単に見つけることはできません。 ``` echidna-test pushpop.sol --config config.yaml @@ -662,7 +668,8 @@ clear used a maximum of 35916 gas push used a maximum of 40839 gas ``` -なぜかと言えば、ガス代は`addrs`のサイズに依存しており、ランダムに呼び出した場合は配列がほぼ空になるためです。 このような場合、 `pop`と`clear`をブラックリストに追加することで、より正確な結果を得ることができます。 +これは、コストが`addrs`のサイズに依存し、ランダムな呼び出しでは配列がほとんど空のままになる傾向があるためです。 +しかし、`pop`と`clear`をブラックリストに登録すると、はるかに良い結果が得られます。 ```yaml filterBlacklist: true @@ -677,9 +684,9 @@ push used a maximum of 40839 gas check used a maximum of 1484472 gas ``` -### ガス消費量が高いトランザクションを見つける作業のまとめ {#summary-finding-transactions-with-high-gas-consumption} +### まとめ：ガス消費量の多いトランザクションの発見 {#summary-finding-transactions-with-high-gas-consumption} -Echidnaでは、`estimateGas`の設定オプションを使用してガス消費量の多いトランザクションを特定することができます： +Echidnaは、`estimateGas`設定オプションを使用して、ガス消費量の多いトランザクションを見つけることができます。 ```yaml estimateGas: true @@ -690,4 +697,4 @@ echidna-test contract.sol --config config.yaml ... ``` -Echidnaは、ファジングを実行した後、各関数ごとにガス消費量が最大となるシーケンスを報告します。 +ファジングキャンペーンが終了すると、Echidnaは各関数の最大ガス消費量を持つシーケンスを報告します。 diff --git a/public/content/translations/ja/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md b/public/content/translations/ja/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md index baa9cab81c5..ee62b3aec76 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md @@ -1,17 +1,12 @@ --- -title: Manticoreを使ってスマートコントラクトのバグを特定する方法 -description: Manticoreを使って、自動でスマートコントラクト上のバグを特定する +title: "Manticoreを使ってスマートコントラクトのバグを特定する方法" +description: "Manticoreを使って、自動でスマートコントラクト上のバグを特定する方法" author: Trailofbits lang: ja -tags: - - "Solidity" - - "スマートコントラクト" - - "セキュリティ" - - "テスト" - - "フォーマルな検証" +tags: [ "Solidity", "スマートコントラクト", "セキュリティ", "テスト", "形式的検証" ] skill: advanced published: 2020-01-13 -source: セキュアなコントラクトの構築 +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore --- @@ -19,25 +14,25 @@ sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/progr ## インストール {#installation} -Manticoreを使用するには、Python 3.6 が必要です。 pipでインストールすることも、Dockerを使用してインストールすることもできます。 +Manticoreには、Python 3.6以上が必要です。 pipでインストールすることも、Dockerを使用してインストールすることもできます。 -### DockerでManticoreをインストールする場合 {#manticore-through-docker} +### Docker経由のManticore {#manticore-through-docker} ```bash docker pull trailofbits/eth-security-toolbox docker run -it -v "$PWD":/home/training trailofbits/eth-security-toolbox ``` -_最後のコマンドは、現在のディレクトリにアクセスできるdockerでeth-security-toolboxを実行します。 ホストからファイルを変更し、dockerからファイル上のツールを実行することができます。_ +_最後のコマンドは、現在のディレクトリにアクセスできるDockerでeth-security-toolboxを実行します。 ホストからファイルを変更し、Dockerからファイル上のツールを実行できます。_ -Dockerで、以下を実行します： +Docker内で、以下を実行します。 ```bash solc-select 0.5.11 cd /home/trufflecon/ ``` -### pipでManticoreをインストールする場合 {#manticore-through-pip} +### pip経由のManticore {#manticore-through-pip} ```bash pip3 install --user manticore @@ -45,9 +40,9 @@ pip3 install --user manticore solc 0.5.11を推奨します。 -### スクリプトを実行する {#running-a-script} +### スクリプトの実行 {#running-a-script} -Python 3では、以下のPythonスクリプトを実行します： +Python 3でPythonスクリプトを実行するには: ```bash python3 script.py @@ -55,60 +50,60 @@ python3 script.py ## 動的シンボリック実行の概要 {#introduction-to-dynamic-symbolic-execution} -### 動的シンボリック実行とは何か {#dynamic-symbolic-execution-in-a-nutshell} +### 動的シンボリック実行の簡単な説明 {#dynamic-symbolic-execution-in-a-nutshell} -動的シンボリック実行（DSE）は、高度な意味認識に基づき状態空間を探索するプログラム解析手法です。 この手法は、`path predicates`と呼ばれる数式で表される「プログラム・パス」を発見するものです。 概念的には、この手法は2つのステップによりパス述語を操作します： +動的シンボリック実行(DSE)は、高度な意味認識に基づき状態空間を探索するプログラム解析手法です。 この手法は、`パス述語`と呼ばれる数式で表される「プログラムパス」の発見に基づいています。 概念的には、この手法は2つのステップでパス述語を操作します: -1. プログラムの入力に対する制約を参照して、プログラム・パスを構築します。 -2. プログラム・パスは、関連パスを実行させるプログラムの入力を生成します。 +1. パス述語は、プログラムの入力に対する制約を使用して構築されます。 +2. パス述語は、関連するパスを実行させるプログラム入力を生成するために使用されます。 -このアプローチでは、具体値で実行する際に、特定されたすべてのプログラムの状態をトリガーしうるという意味で誤検出が発生しません。 例えば、解析において整数のオーバーフローが特定された場合、このオーバーフローは確実に再現可能です。 +このアプローチでは、特定されたすべてのプログラム状態が具体的な実行中にトリガーされうるという意味で、誤検出(偽陽性)は発生しません。 例えば、解析で整数オーバーフローが発見された場合、その再現性が保証されます。 -### パス述語の具体例 {#path-predicate-example} +### パス述語の例 {#path-predicate-example} -DSEの仕組みを理解するために、以下の例を考えてみましょう。 +DSEがどのように機能するかを理解するために、次の例を考えてみましょう。 ```solidity function f(uint a){ if (a == 65) { - // A bug is present + // バグが存在します } } ``` -`f()`には2つのパスが含まれているため、DSEにより、2つの異なるパス述語が構築されます。 +`f()`には2つのパスが含まれているため、DSEは2つの異なるパス述語を構築します。 -- 第1のパス： `a == 65` -- 第2のパス： `Not (a == 65)` +- パス1: `a == 65` +- パス2: `Not (a == 65)` -それぞれのパス述語は、いわゆる[SMTソルバー](https://wikipedia.org/wiki/Satisfiability_modulo_theories)に投入できる数式であり、SMTソルバーはこの等式を解決しようとします。 `第1のパス`では、ソルバーは、このパスが`a = 65`で探索可能だと返します。 `第2のパス`では、ソルバーは、`a`に対し、65以外の任意の値を与えることができます（例： `a = 0`）。 +各パス述語は、いわゆる[SMTソルバー](https://wikipedia.org/wiki/Satisfiability_modulo_theories)に与えることができる数式であり、ソルバーはその方程式を解こうとします。 `パス1`では、ソルバーは `a = 65` でパスを探索できると応答します。 `パス2`では、ソルバーは `a` に65以外の任意の値、例えば `a = 0` を与えることができます。 -### プロパティを検証する {#verifying-properties} +### プロパティの検証 {#verifying-properties} -Manticoreでは、各パスの実行全体を完全に制御できます。 このため、ほぼすべての事項に対して任意の制限を加えることができます。 この制御を通じて、コントラクトのプロパティを作成することができます。 +Manticoreでは、各パスのすべての実行を完全に制御できます。 その結果、ほとんどすべてのものに任意の制約を追加できます。 この制御により、コントラクトに関するプロパティを作成できます。 -次の例を考えてみましょう： +次の例を考えてみましょう。 ```solidity function unsafe_add(uint a, uint b) returns(uint c){ - c = a + b; // no overflow protection + c = a + b; // オーバーフロー保護なし return c; } ``` -この関数を探索するには、1つのパスしか存在しません。 +この関数には、探索するパスが1つしかありません。 -- パス1： `c = a + b` +- パス1: `c = a + b` -Manticoreを使用することで、オーバーフローの有無を確認し、パス述語に制限を加えられます。 +Manticoreを使用すると、オーバーフローをチェックし、パス述語に制約を追加できます。 - `c = a + b AND (c < a OR c < b)` -上記の述語パスが実行可能となる`a`および`b`の値を見つけられる場合、オーバーフローが特定できたことになります。 例えば、ソルバーは、`a = 10 , b = MAXUINT256`という入力を生成できます。 +上記のパス述語が実行可能になるような `a` と `b` の評価を見つけることができれば、オーバーフローを発見したことになります。 例えば、ソルバーは `a = 10 , b = MAXUINT256` という入力を生成できます。 -次に、上記を修正したコードを見てみましょう： +修正版を考えてみましょう。 ```solidity function safe_add(uint a, uint b) returns(uint c){ @@ -119,17 +114,17 @@ function safe_add(uint a, uint b) returns(uint c){ } ``` -オーバーフローを確認するために数式は、以下のようになるでしょう： +オーバーフローチェックに関連する数式は次のようになります。 -- `c = a + b AND (c >= a) AND (c=>b) AND (c < a OR c < b)` +- `c = a + b AND (c >= a) AND (c >= b) AND (c < a OR c < b)` -この数式は解くことができません。言い換えれば、`safe_add`において、`c`の値が常に増加することを**証明**しています。 +この数式は解けません。言い換えれば、これは `safe_add` において `c` が常に増加することの**証明**です。 -このように、DSEはコード上の任意の制限について検証できるパワフルなツールです。 +したがって、DSEはコード上の任意の制約を検証できる強力なツールです。 -## Manticoreで実行する {#running-under-manticore} +## Manticoreでの実行 {#running-under-manticore} -以下に、Manticore APIを用いて、スマートコントラクトを探索する方法を紹介します。 対象となるスマートコントラクトは、[`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol)です。 +ここでは、Manticore APIを使ってスマートコントラクトを探索する方法を見ていきます。 対象は、次のスマートコントラクト [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol) です。 ```solidity pragma solidity >=0.4.24 <0.6.0; @@ -143,15 +138,15 @@ contract Simple { } ``` -### スタンドアロンの探索を実行する {#run-a-standalone-exploration} +### スタンドアロン探索の実行 {#run-a-standalone-exploration} -以下のコマンドから、スマートコントラクト上で直接Manticoreを実行できます（`project`は、Solidityファイルでもプロジェクトディレクトリでも構いません）。 +次のコマンドで、スマートコントラクト上で直接Manticoreを実行できます(`project`はSolidityファイル、またはプロジェクトディレクトリです): ```bash $ manticore project ``` -実行すると、以下のようなテストケースが出力されます（順番は異なる可能性があります）： +次のようなテストケースの出力が得られます(順序は変わる可能性があります): ``` ... @@ -166,39 +161,40 @@ $ manticore project ... ``` -Manticoreは、追加情報が提供されない限り、新規のシンボリック・トランザクションを使って、コントラクト上で新規パスが発見されるまでコントラクトを探索します。 Manticoreでは、トランザクションが失敗した場合（例：状態が元に戻された後）は、新規のトランザクションを実行しません。 +追加情報がない場合、Manticoreはコントラクト上で新しいパスを探索しなくなるまで、新しいシンボリック +トランザクションでコントラクトを探索します。 Manticoreは、失敗したトランザクションの後(例: revertの後)には、新しいトランザクションを実行しません。 -Manticoreでは、 `mcore_*`ディレクトリに情報を出力します。 このディレクトリには、以下が含まれます： +Manticoreは、`mcore_*`ディレクトリに情報を出力します。 このディレクトリには、とりわけ次のものが含まれます。 -- `global.summary`：カバレッジとコンパイラに関する警告 -- `test_XXXXX.summary`：テストケースごとのカバレッジ、最後の命令、およびアカウント残高 -- `test_XXXXX.tx`：テストケースごとの詳細なトランザクションリスト +- `global.summary`: カバレッジとコンパイラの警告 +- `test_XXXXX.summary`: カバレッジ、最後の命令、テストケースごとのアカウント残高 +- `test_XXXXX.tx`: テストケースごとのトランザクションの詳細リスト -この例では、以下に該当する7つのテストケースが特定されました（ファイル名の順番は異なるかもしれません）： +ここでは、Manticoreは7つのテストケースを見つけます。これらは以下に対応します(ファイル名の順序は変わる可能性があります): -| | トランザクション 0 | トランザクション 1 | トランザクション 2 | 結果 | -|:--------------------:|:----------:|:----------:| ---------- |:------:| -| **test_00000000.tx** | コントラクトの作成 | f(!=65) | f(!=65) | STOP | -| **test_00000001.tx** | コントラクトの作成 | フォールバック関数 | | REVERT | -| **test_00000002.tx** | コントラクトの作成 | | | RETURN | -| **test_00000003.tx** | コントラクトの作成 | f(65) | | REVERT | -| **test_00000004.tx** | コントラクトの作成 | f(!=65) | | STOP | -| **test_00000005.tx** | コントラクトの作成 | f(!=65) | f(65) | REVERT | -| **test_00000006.tx** | コントラクトの作成 | f(!=65) | フォールバック関数 | REVERT | +| | トランザクション0 | トランザクション1 | トランザクション2 | 結果 | +| :-------------------------------------------------------: | :-------: | :------------------------: | -------------------------- | :----: | +| **test_00000000.tx** | コントラクト作成 | f(!=65) | f(!=65) | STOP | +| **test_00000001.tx** | コントラクト作成 | フォールバック関数 | | REVERT | +| **test_00000002.tx** | コントラクト作成 | | | RETURN | +| **test_00000003.tx** | コントラクト作成 | f(65) | | REVERT | +| **test_00000004.tx** | コントラクト作成 | f(!=65) | | STOP | +| **test_00000005.tx** | コントラクト作成 | f(!=65) | f(65) | REVERT | +| **test_00000006.tx** | コントラクト作成 | f(!=65) | フォールバック関数 | REVERT | _探索サマリーにおける「f(!=65)」は、f が 65 以外の値で呼び出されたことを意味します。_ -ご覧のように、Manticoreでは、すべての成功した／元に戻されたトランザクションにつき、固有のテストケースを生成します。 +お気づきのように、Manticoreは成功したトランザクションやrevertされたトランザクションごとに、一意のテストケースを生成します。 -高速な探索を行いたい場合は、`--quick-mode`フラグを使用してください（バグ検出、ガス代計算等が省略されます）。 +高速なコード探索を行いたい場合は `--quick-mode` フラグを使用してください(バグ検出器、ガス計算などを無効にします)。 -### Manticore APIを使ってスマートコントラクトを操作する {#manipulate-a-smart-contract-through-the-api} +### APIによるスマートコントラクトの操作 {#manipulate-a-smart-contract-through-the-api} -このセクションでは、Manticore Python APIを使ってスマートコントラクトを操作する方法について詳しく説明します。 Pythonの拡張子である`*.py`を持つ新規ファイルを作成し、APIコマンド（基本知識については以下で説明します）をファイルに追加して必要なコードを書いてから、`$ python3 *.py`コマンドで実行します。 また、Pythonのコンソールから直接コマンドを実行することもできます。コンソールを起動する際のコマンドは、`$ python3`です。 +このセクションでは、Manticore Python APIを介してスマートコントラクトを操作する方法について詳しく説明します。 Pythonの拡張子である\*.pyを持つ新規ファイルを作成し、APIコマンド（基本知識については以下で説明します）をファイルに追加して必要なコードを書いてから、$ python3 \*.pyコマンドで実行します。 また、Pythonのコンソールから直接コマンドを実行することもできます。コンソールを起動する際のコマンドは、$ python3です。 -### アカウントを作成する {#creating-accounts} +### アカウントの作成 {#creating-accounts} -まず、以下のコマンドを持つ新規のブロックチェーンを立ち上げる必要があります。 +最初に行うべきことは、次のコマンドで新しいブロックチェーンを開始することです。 ```python from manticore.ethereum import ManticoreEVM @@ -206,13 +202,13 @@ from manticore.ethereum import ManticoreEVM m = ManticoreEVM() ``` -[m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account)により、コントラクトではないアカウントが作成されます。 +非コントラクトアカウントは [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) を使用して作成されます。 ```python user_account = m.create_account(balance=1000) ``` -Solidityで作成したコントラクトについては、[m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract)でデプロイします。 +Solidityコントラクトは [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract) を使用してデプロイできます。 ```solidity source_code = ''' @@ -225,24 +221,24 @@ contract Simple { } } ''' -# Initiate the contract +# コントラクトを初期化する contract_account = m.solidity_create_contract(source_code, owner=user_account) ``` #### まとめ {#summary} -- [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account)と[m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract)を使用して、ユーザーアカウントとコントラクトアカウントを作成できます。 +- [m.create_account](https://manticore.readthedocs.io/en/latest/evm.html?highlight=create_account#manticore.ethereum.ManticoreEVM.create_account) と [m.solidity_create_contract](https://manticore.readthedocs.io/en/latest/evm.html?highlight=solidity_create#manticore.ethereum.ManticoreEVM.create_contract) でユーザーアカウントとコントラクトアカウントを作成できます。 -### トランザクションを実行する {#executing-transactions} +### トランザクションの実行 {#executing-transactions} -Manticoreは、2種類のトランザクションに対応しています： +Manticoreは2種類のトランザクションをサポートしています。 -- 生トランザクション：すべての関数を探索します。 -- 名前付きトランザクション：1つの関数だけを探索します。 +- Rawトランザクション: すべての関数が探索されます +- 名前付きトランザクション: 1つの関数のみが探索されます -#### 生トランザクション {#raw-transaction} +#### Rawトランザクション {#raw-transaction} -生トランザクションは、[m.transaction](https://manticore.readthedocs.io/en/latest/evm.html?highlight=transaction#manticore.ethereum.ManticoreEVM.transaction)で実行されます。 +Rawトランザクションは [m.transaction](https://manticore.readthedocs.io/en/latest/evm.html?highlight=transaction#manticore.ethereum.ManticoreEVM.transaction) を使用して実行されます。 ```python m.transaction(caller=user_account, @@ -251,12 +247,12 @@ m.transaction(caller=user_account, value=value) ``` -呼び出し元、アドレス、データ、トランザクションの値は、具体値あるいはシンボリック値のどちらでも構いません： +トランザクションの呼び出し元、アドレス、データ、または値は、具象値またはシンボリック値のいずれかです。 -- [m.make_symbolic_value](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_value#manticore.ethereum.ManticoreEVM.make_symbolic_value)は、シンボリック値を生成します。 -- [m.make_symbolic_buffer(size)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_buffer#manticore.ethereum.ManticoreEVM.make_symbolic_buffer)は、シンボリックなバイト配列を生成します。 +- [m.make_symbolic_value](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_value#manticore.ethereum.ManticoreEVM.make_symbolic_value) はシンボリック値を生成します。 +- [m.make_symbolic_buffer(size)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=make_symbolic_buffer#manticore.ethereum.ManticoreEVM.make_symbolic_buffer) はシンボリックバイト配列を生成します。 -以下の例を確認してください： +以下の例をご覧ください： ```python symbolic_value = m.make_symbolic_value() @@ -267,40 +263,41 @@ m.transaction(caller=user_account, value=symbolic_value) ``` -データがシンボリック値の場合、Manticoreは、トランザクションの実行時にコントラクトに含まれるすべての関数を探索します。 関数がどのように選択されるかを理解するには、[Hands on the Ethernaut CTF](https://blog.trailofbits.com/2017/11/06/hands-on-the-ethernaut-ctf/)の記事におけるフォールバック関数についての説明を参照してください。 +データがシンボリックの場合、Manticoreはトランザクションの実行中にコントラクトのすべての関数を探索します。 関数の選択がどのように機能するかを理解するには、[Hands on the Ethernaut CTF](https://blog.trailofbits.com/2017/11/06/hands-on-the-ethernaut-ctf/)の記事にあるフォールバック関数の説明を参照すると役立ちます。 #### 名前付きトランザクション {#named-transaction} -関数は、名前から実行できます。 `f(uint var)`につき、シンボリック値を用いて、user_accountから、0 etherで実行する場合、以下を使用します： +関数は名前で実行できます。 +`f(uint var)` をシンボリック値で、user_accountから、0 etherで実行するには、次のようにします。 ```python symbolic_var = m.make_symbolic_value() contract_account.f(symbolic_var, caller=user_account, value=0) ``` -トランザクションの`value`を指定しない場合、デフォルトでは0になります。 +トランザクションの `value` が指定されていない場合、デフォルトで0になります。 #### まとめ {#summary-1} -- トランザクションの引数は、具体値またはシンボリック値のどちらでもよい。 -- 生トランザクションは、すべての関数を探索する。 -- 関数は、名前で呼び出すことができる。 +- トランザクションの引数は具象値またはシンボリック値にできます +- Rawトランザクションはすべての関数を探索します +- 関数は名前で呼び出すことができます ### ワークスペース {#workspace} -`m.workspace`は、生成されたすべてのファイルにおける出力ディレクトリとして使用されるディレクトリです。 +`m.workspace` は、生成されたすべてのファイルの出力ディレクトリとして使用されるディレクトリです。 ```python print("Results are in {}".format(m.workspace)) ``` -### 探索を終了する {#terminate-the-exploration} +### 探索の終了 {#terminate-the-exploration} -探索を停止するには、[m.finalize()](https://manticore.readthedocs.io/en/latest/evm.html?highlight=finalize#manticore.ethereum.ManticoreEVM.finalize)を使用します。 このメソッドが呼び出された時点で、さらにトランザクションは送信されなくなり、Manticoreは探索済みの各パスにつきテストケースを生成します。 +探索を停止するには [m.finalize()](https://manticore.readthedocs.io/en/latest/evm.html?highlight=finalize#manticore.ethereum.ManticoreEVM.finalize) を使用します。 このメソッドが呼び出されると、それ以上のトランザクションは送信されなくなり、Manticoreは探索された各パスのテストケースを生成します。 -### Manticoreを使った実行のまとめ {#summary-running-under-manticore} +### まとめ: Manticoreでの実行 {#summary-running-under-manticore} -上記のステップをまとめると、以下のようになります： +これまでのすべてのステップをまとめると、次のようになります。 ```python from manticore.ethereum import ManticoreEVM @@ -317,14 +314,14 @@ symbolic_var = m.make_symbolic_value() contract_account.f(symbolic_var) print("Results are in {}".format(m.workspace)) -m.finalize() # stop the exploration +m.finalize() # 探索を停止 ``` -紹介したすべてのコードは、[`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py)でアクセスできます。 +上記のすべてのコードは [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) にあります。 -## スローイングパスを取得する {#getting-throwing-paths} +## 例外をスローするパスの取得 {#getting-throwing-paths} -次に、 `f()`において例外を発生させるパスに対する、特定のインプットを生成します。 ここでも、対象となるスマートコントラクトは[`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol)です。 +次に、`f()`で例外を発生させるパスの特定の入力を生成します。 対象は、引き続き次のスマートコントラクト [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol) です。 ```solidity pragma solidity >=0.4.24 <0.6.0; @@ -337,26 +334,26 @@ contract Simple { } ``` -### 状態情報を使用する {#using-state-information} +### 状態情報の使用 {#using-state-information} -実行された各パスには、それぞれのブロックチェーンの状態が含まれています。 状態は、readyまたはkilledのどちらかです。killedは、THROWまたはREVERTに達したことを意味します。 +実行された各パスには、それぞれのブロックチェーンの状態があります。 状態はready(準備完了)かkilled(強制終了)のいずれかです。killedはTHROWまたはREVERT命令に到達したことを意味します。 -- [m.ready_states](https://manticore.readthedocs.io/en/latest/states.html#accessing)：readyに該当する状態のリスト（REVERT/INVALIDを実行しなかった状態） -- [m.killed_states](https://manticore.readthedocs.io/en/latest/states.html#accessings)：killedに該当する状態のリスト -- [m.all_states](https://manticore.readthedocs.io/en/latest/states.html#accessings)：すべての状態 +- [m.ready_states](https://manticore.readthedocs.io/en/latest/states.html#accessing): 準備完了状態のリスト(REVERT/INVALIDを実行していない状態) +- [m.killed_states](https://manticore.readthedocs.io/en/latest/states.html#accessings): 強制終了された状態のリスト +- [m.all_states](https://manticore.readthedocs.io/en/latest/states.html#accessings): すべての状態 ```python for state in m.all_states: - # do something with state + # stateで何かを行う ``` -状態情報は、アクセス可能です。 以下の例をご覧ください： +状態情報にアクセスできます。 以下の例をご覧ください： -- `state.platform.get_balance(account.address)`：アカウント残高 -- `state.platform.transactions`：トランザクションのリスト -- `state.platform.transactions[-1].return_data`：最後のトランザクションで返されたデータ +- `state.platform.get_balance(account.address)`: アカウントの残高 +- `state.platform.transactions`: トランザクションのリスト +- `state.platform.transactions[-1].return_data`: 最後のトランザクションによって返されたデータ -最後のトランザクションによって返されるデータは配列ですが、以下のようにABI.deserializeで値に変換できます： +最後のトランザクションによって返されたデータは配列であり、ABI.deserializeで値に変換できます。例: ```python data = state.platform.transactions[0].return_data @@ -365,7 +362,7 @@ data = ABI.deserialize("uint", data) ### テストケースの生成方法 {#how-to-generate-testcase} -テストケースを生成するには、「[m.generate_testcase(state, name)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=generate_testcase#manticore.ethereum.ManticoreEVM.generate_testcase)」を使用します。 +テストケースを生成するには [m.generate_testcase(state, name)](https://manticore.readthedocs.io/en/latest/evm.html?highlight=generate_testcase#manticore.ethereum.ManticoreEVM.generate_testcase) を使用します。 ```python m.generate_testcase(state, 'BugFound') @@ -373,13 +370,13 @@ m.generate_testcase(state, 'BugFound') ### まとめ {#summary-2} -- 状態は、m.all_statesでイテレートできる -- `state.platform.get_balance(account.address)`は、アカウント残高を返す -- `state.platform.transactions`は、トランザクションのリストを返す -- `transaction.return_data`は、返されたデータを示す -- `m.generate_testcase(state, name)`は、状態に対する入力を生成する +- m.all_statesで状態をイテレートできます +- `state.platform.get_balance(account.address)`はアカウントの残高を返します +- `state.platform.transactions`はトランザクションのリストを返します +- `transaction.return_data`は返されたデータです +- `m.generate_testcase(state, name)`は状態の入力を生成します -### スローイングパス取得のまとめ {#summary-getting-throwing-path} +### まとめ: 例外をスローするパスの取得 {#summary-getting-throwing-path} ```python from manticore.ethereum import ManticoreEVM @@ -395,7 +392,8 @@ contract_account = m.solidity_create_contract(source_code, owner=user_account) symbolic_var = m.make_symbolic_value() contract_account.f(symbolic_var) -## Check if an execution ends with a REVERT or INVALID +## 実行がREVERTまたはINVALIDで終了するかどうかを確認します + for state in m.terminated_states: last_tx = state.platform.transactions[-1] if last_tx.result in ['REVERT', 'INVALID']: @@ -403,13 +401,14 @@ for state in m.terminated_states: m.generate_testcase(state, 'ThrowFound') ``` -紹介したすべてのコードは、[`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py)でアクセスできます。 +上記のすべてのコードは [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) にあります。 -_terminated_stateが返したすべての状態は結果の値がREVERTまたはINVALIDであるため、上記よりも簡略なスクリプトを作成することもできました。上記のスクリプト例は、Manticore APIの操作方法を説明することを目的としたものです。_ +_terminated_stateによって返されるすべての状態は結果としてREVERTまたはINVALIDを持つため、もっと単純なスクリプトを生成することもできましたが、この例はAPIの操作方法を実証するためだけのものです。_ -## 制約を追加する {#adding-constraints} +## 制約の追加 {#adding-constraints} -次に、探索を制限する方法について確認しましょう。 ここでは、`f()`のドキュメンテーションにおいて、この関数は決して`a == 65`で呼び出されることはないと記載されていると想定します。このため、`a == 65`のバグは、実際にはバグではありません。 ここでも、対象のスマートコントラクトは[`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol)です。 +探索を制約する方法を見ていきます。 `f()`のドキュメントには、この関数が`a == 65`で呼び出されることはないと +記載されていると仮定します。したがって、`a == 65`のバグは実際のバグではありません。 対象は、引き続き次のスマートコントラクト [`example.sol`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example.sol) です。 ```solidity pragma solidity >=0.4.24 <0.6.0; @@ -424,22 +423,22 @@ contract Simple { ### 演算子 {#operators} -[演算子](https://github.com/trailofbits/manticore/blob/master/manticore/core/smtlib/operators.py)モジュールは、制約を容易に操作する上で役立ちます。特に、以下の操作を提供します： +[Operators](https://github.com/trailofbits/manticore/blob/master/manticore/core/smtlib/operators.py)モジュールは制約の操作を容易にし、とりわけ以下を提供します。 -- Operators.AND -- Operators.OR -- Operators.UGT（符号なし大なり） -- Operators.UGE（符号なし以上） -- Operators.ULT（符号なし小なり） -- Operators.ULE（符号なし、以下） +- Operators.AND, +- Operators.OR, +- Operators.UGT (符号なしでより大きい), +- Operators.UGE (符号なしで以上), +- Operators.ULT (符号なしでより小さい), +- Operators.ULE (符号なしで以下)。 -このモジュールをインポートするには、以下を使用します： +モジュールをインポートするには、次を使用します。 ```python from manticore.core.smtlib import Operators ``` -`Operators.CONCAT`は、配列に値を連結するために使用します。 例えば、トランザクションのreturn_dataは、他の値に対して検証可能な値に変更する必要があります： +`Operators.CONCAT`は、配列を値に連結するために使用されます。 例えば、トランザクションのreturn_dataは、別の値と比較チェックするために値に変更する必要があります。 ```python last_return = Operators.CONCAT(256, *last_return) @@ -447,11 +446,12 @@ last_return = Operators.CONCAT(256, *last_return) ### 制約 {#state-constraint} -制約の対象は、グローバルあるいは特定の状態のみのどちらでも構いません。 +制約は、グローバルまたは特定の状態に対して使用できます。 #### グローバル制約 {#state-constraint} -グローバル制約を追加するには、`m.constraint(constraint)`を使用します。 例えば以下のように、シンボリックアドレスからコントラクトを呼び出し、このアドレスを特定の値に制限することができます： +グローバル制約を追加するには `m.constrain(constraint)` を使用します。 +例えば、シンボリックアドレスからコントラクトを呼び出し、このアドレスを特定の値に制限することができます。 ```python symbolic_address = m.make_symbolic_value() @@ -462,23 +462,25 @@ m.transaction(caller=user_account, value=0) ``` -#### 状態に対する制約 {#state-constraint} +#### 状態制約 {#state-constraint} -特定の状態に対して制約を追加するには、[state.constrain(constraint)](https://manticore.readthedocs.io/en/latest/states.html?highlight=StateBase#manticore.core.state.StateBase.constrain)を使用します。 特定の状態における一部のプロパティをチェックしてから、状態に制限を追加することができます。 +[state.constrain(constraint)](https://manticore.readthedocs.io/en/latest/states.html?highlight=StateBase#manticore.core.state.StateBase.constrain) を使用して、特定の状態に制約を追加します。 +これは、探索後に状態を制約して、そのプロパティをチェックするために使用できます。 -### 制約を確認する {#checking-constraint} +### 制約のチェック {#checking-constraint} -制約が実行可能かどうかを確認するには、`solver.check(state.constraints)`を使用します。 例えば以下では、symbolic_valueが「65」以外の値でなければならないという制約を追加した上で、状態が実行可能かどうかをチェックします。 +`solver.check(state.constraints)`を使用して、制約がまだ実行可能かどうかを確認します。 +例えば、次はsymbolic_valueを65とは異なる値に制約し、状態がまだ実行可能かどうかをチェックします。 ```python state.constrain(symbolic_var != 65) if solver.check(state.constraints): - # state is feasible + # 状態は実行可能です ``` -### 制約追加のまとめ {#summary-adding-constraints} +### まとめ: 制約の追加 {#summary-adding-constraints} -これまでのコードに制約を追加すると、以下のようになります： +前のコードに制約を追加すると、次のようになります。 ```python from manticore.ethereum import ManticoreEVM @@ -499,11 +501,12 @@ contract_account.f(symbolic_var) no_bug_found = True -## Check if an execution ends with a REVERT or INVALID +## 実行がREVERTまたはINVALIDで終了するかどうかを確認します + for state in m.terminated_states: last_tx = state.platform.transactions[-1] if last_tx.result in ['REVERT', 'INVALID']: - # we do not consider the path were a == 65 + # a == 65のパスは考慮しません condition = symbolic_var != 65 if m.generate_testcase(state, name="BugFound", only_if=condition): print(f'Bug found, results are in {m.workspace}') @@ -513,4 +516,4 @@ if no_bug_found: print(f'No bug found') ``` -ここで紹介したすべてのコードは、[`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py)からアクセスできます。 +上記のすべてのコードは [`example_run.py`](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/manticore/examples/example_run.py) にあります。 diff --git a/public/content/translations/ja/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md b/public/content/translations/ja/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md index 2196e56b178..2931f5de6a3 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md @@ -1,34 +1,29 @@ --- -title: Slitherを使用してスマートコントラクトのバグを見つける方法 -description: Slitherを使用してスマートコントラクトのバグを自動的に見つける方法 +title: "Slitherを使用してスマートコントラクトのバグを見つける方法" +description: "Slitherを使用してスマートコントラクトのバグを自動的に見つける方法" author: Trailofbits lang: ja -tags: - - "Solidity" - - "スマートコントラクト" - - "セキュリティ" - - "テスト" - - "静的解析" +tags: [ "Solidity", "スマートコントラクト", "セキュリティ", "テスト" ] skill: advanced published: 2020-06-09 -source: セキュアなコントラクトの構築 +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither --- -## Slitherの使い方 {#how-to-use-slither} +## Slitherの使用方法 {#how-to-use-slither} このチュートリアルでは、Slitherを使って、スマートコントラクトのバグを自動で検出する方法を学びます。 - [インストール](#installation) -- [コマンドラインの使い方](#command-line) -- [静的解析入門](#static-analysis)：静的解析の簡単な紹介 -- [API](#api-basics)：Python APIの説明 +- [コマンドラインの使用方法](#command-line) +- [静的解析入門](#static-analysis): 静的解析の簡単な紹介 +- [API](#api-basics): Python APIの説明 ## インストール {#installation} -Slitherには、Python 3.6以上が必要です。 pipでインストールすることも、Dockerを使用してインストールすることもできます。 +SlitherにはPython 3.6以上が必要です。 pipでインストールすることも、Dockerを使用してインストールすることもできます。 -pipによるSlitherのインストール +pipによるSlitherのインストール: ```bash pip3 install --user slither-analyzer @@ -41,18 +36,18 @@ docker pull trailofbits/eth-security-toolbox docker run -it -v "$PWD":/home/trufflecon trailofbits/eth-security-toolbox ``` -_最後のコマンドは、現在のディレクトリにアクセスできるDockerでeth-security-toolboxを実行します。 ホストからファイルを変更し、Dockerからファイル上のツールを実行することができます。_ +_最後のコマンドは、現在のディレクトリにアクセスできるDockerでeth-security-toolboxを実行します。 ホストからファイルを変更し、Dockerからファイル上のツールを実行できます。_ -Docker内で実行する： +Docker内で、以下を実行します。 ```bash solc-select 0.5.11 cd /home/trufflecon/ ``` -### スクリプトを実行する {#running-a-script} +### スクリプトの実行 {#running-a-script} -Python3でPythonスクリプトを実行するには、以下を実行します： +Python 3でPythonスクリプトを実行するには: ```bash python3 script.py @@ -60,23 +55,23 @@ python3 script.py ### コマンドライン {#command-line} -**コマンドラインとユーザー定義スクリプトの比較**：Slitherには、多くの一般的なバグを見つけるための事前定義された検出器のセットが付属しています。 コマンドラインでSlitherを呼び出すとすべての検出器が実行されますので、静的解析の詳しい知識は必要ありません： +**コマンドラインとユーザー定義スクリプト。** Slitherには、多くの一般的なバグを見つけるための事前定義された検出器のセットが付属しています。 コマンドラインからSlitherを呼び出すとすべての検出器が実行されるため、静的解析に関する詳細な知識は必要ありません。 ```bash slither project_paths ``` -Slitherでは、検出器に加えて、[プリンター](https://github.com/crytic/slither#printers)と[ツール](https://github.com/crytic/slither#tools)によるコードレビュー機能も利用できます。 +検出器に加えて、Slitherにはその[printers](https://github.com/crytic/slither#printers)と[tools](https://github.com/crytic/slither#tools)を介したコードレビュー機能があります。 -プライベート検出器およびGitHubでの統合にアクセスするには、[crytic.io](https://github.com/crytic)を使用します。 +[crytic.io](https://github.com/crytic)を使用すると、プライベートな検出器やGitHubとの統合にアクセスできます。 ## 静的解析 {#static-analysis} -Slither静的解析フレームワークの機能と設計は、ブログ投稿 ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/)、[2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) と[学術論文](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf)で説明されています。 +Slither静的解析フレームワークの機能と設計については、ブログ投稿 ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/), [2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) や [学術論文](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf)で説明されています。 -静的解析には、さまざまな種類があります。 静的解析の技法は、[clang](https://clang-analyzer.llvm.org/)や[gcc](https://lwn.net/Articles/806099/)といったコンパイラで採用されているだけでなく、[Infer](https://fbinfer.com/)、[CodeClimate](https://codeclimate.com/)、および[FindBugs](http://findbugs.sourceforge.net/)、ならびに[Frama-C](https://frama-c.com/)や[Polyspace](https://www.mathworks.com/products/polyspace.html)といったフォーマルなメソッドに基づくツールの基盤でもあります。 +静的解析には、さまざまな種類があります。 おそらくご存じのように、[clang](https://clang-analyzer.llvm.org/)や[gcc](https://lwn.net/Articles/806099/)などのコンパイラはこれらの研究技術に依存していますが、それはまた、([Infer](https://fbinfer.com/)、[CodeClimate](https://codeclimate.com/)、[FindBugs](http://findbugs.sourceforge.net/)、そして[Frama-C](https://frama-c.com/)や[Polyspace](https://www.mathworks.com/products/polyspace.html)のような形式的手法に基づくツール) の基礎ともなっています。 -ここでは、静的解析の手法や研究者について網羅的に取り上げる余裕はありません。 その代わりに、皆さんがバグを特定し、コードを理解する上で効果的に静的解析の手法を利用できるように、Slitherの仕組みを理解する上で必要な事項のみに焦点を当てます。 +ここでは、静的解析の技術と研究者を網羅的に検討するわけではありません。 その代わり、皆さんがバグを発見しコードを理解するためにSlitherをより効果的に使えるよう、Slitherがどのように機能するかを理解するために必要なことに焦点を当てます。 - [コード表現](#code-representation) - [コード解析](#analysis) @@ -84,13 +79,13 @@ Slither静的解析フレームワークの機能と設計は、ブログ投稿 ### コード表現 {#code-representation} -単一の実行パスについて推論する動的解析とは対照的に、静的解析では一度にすべてのパスを対象として推論します。 これには、別のコード表現が必要です。 最も一般的なコード表現は、抽象構文木（AST）および制御フローグラフ（CFG）の2つです。 +単一の実行パスについて推論する動的解析とは対照的に、静的解析では一度にすべてのパスを対象として推論します。 そのために、異なるコード表現に依存しています。 最も一般的なものは、抽象構文木 (AST) と制御フローグラフ (CFG) の2つです。 -### 抽象構文木（AST） {#abstract-syntax-trees-ast} +### 抽象構文木 (AST) {#abstract-syntax-trees-ast} -ASTは、コンパイラがコードを解析するたびに用いられます。 おそらく、静的解析を実行できる最も基本的な構造だと言えるでしょう。 +ASTは、コンパイラがコードを解析するたびに使用されます。 これは、おそらく静的解析を実行できる最も基本的な構造です。 -一言で言えば、ASTは構造化されたツリーであり、通常、各リーフに変数または定数が含まれ、内部ノードはオペランドまたは制御フロー操作です。 次のコードを検討してみましょう： +要するに、ASTは構造化された木であり、通常、各リーフには変数または定数が含まれ、内部ノードはオペランドまたは制御フロー操作です。 次のコードを考えてみましょう。 ```solidity function safeAdd(uint a, uint b) pure internal returns(uint){ @@ -101,15 +96,15 @@ function safeAdd(uint a, uint b) pure internal returns(uint){ } ``` -対応するASTは、次のとおりです： +対応するASTは以下の通りです。 ![AST](./ast.png) -Slitherでは、solcがエクスポートしたASTを使用します。 +SlitherはsolcによってエクスポートされたASTを使用します。 -ASTは簡単に構築できますが、入れ子構造を持ちます。 このため、解析が簡単でない場合があります。 例えば、`a + b <= a`の式で使用される操作を識別するには、まず`<=`を解析し、次に`+`を解析する必要があります。 一般的なアプローチは、ツリーを再帰的に移動するいわゆるVisitorパターンを使用することです。 Slitherには、[`ExpressionVisitor`](https://github.com/crytic/slither/blob/master/slither/visitors/expression/expression.py)という汎用的なVisitorが含まれています。 +ASTは簡単に構築できますが、入れ子構造になっています。 そのため、解析が必ずしも簡単ではない場合があります。 例えば、`a + b <= a`という式で使われる演算を特定するには、まず`<=`を解析し、次に`+`を解析しなければなりません。 一般的なアプローチは、木構造を再帰的に走査する、いわゆるビジターパターンを使用することです。 Slitherには、[`ExpressionVisitor`](https://github.com/crytic/slither/blob/master/slither/visitors/expression/expression.py)に汎用的なビジターが含まれています。 -次のコードは、`ExpressionVisitor`を使用して式に加算が含まれているかどうかを検出します： +次のコードは`ExpressionVisitor`を使用して、式に加算が含まれているかどうかを検出します。 ```python from slither.visitors.expression.expression import ExpressionVisitor @@ -124,58 +119,58 @@ class HasAddition(ExpressionVisitor): if expression.type == BinaryOperationType.ADDITION: self._result = True -visitor = HasAddition(expression) # expression is the expression to be tested +visitor = HasAddition(expression) # expression はテスト対象の式です print(f'The expression {expression} has a addition: {visitor.result()}') ``` -### 制御フローグラフ（CFG） {#control-flow-graph-cfg} +### 制御フローグラフ (CFG) {#control-flow-graph-cfg} -2番目によく用いられるコード表現は、制御フローグラフ（CFG）です。 名前が示すように、すべての実行パスを可視化するグラフベースの表現です。 各ノードには、1つまたは複数の命令が含まれます。 グラフのエッジ部分は、制御フロー操作（if/then/else、ループなど）を表します。 先ほどの例をCFGで表すと、次のようになります： +2番目に一般的なコード表現は、制御フローグラフ (CFG) です。 その名の通り、すべての実行パスを公開するグラフベースの表現です。 各ノードには、1つまたは複数の命令が含まれます。 グラフのエッジは、制御フロー操作 (if/then/else、ループなど) を表します。 前の例のCFGは次のようになります。 ![CFG](./cfg.png) -CFGは、大部分の解析の土台となる表現です。 +CFGは、ほとんどの解析がその上に構築される表現です。 -他にも、様々なコード表現が存在します。 それぞれの表現には、実行したい解析に応じて長所と短所があります。 +他にも多くのコード表現が存在します。 それぞれの表現には、実行したい解析に応じて長所と短所があります。 ### 解析 {#analysis} -Slitherで実行できる最もシンプルな解析タイプは、構文解析です。 +Slitherで実行できる最も簡単な種類の解析は、構文解析です。 ### 構文解析 {#syntax-analysis} -Slitherは、コードおよび表現に含まれるさまざまな構成要素を移動しながら、パターンマッチングに類似したアプローチで矛盾や欠陥を発見します。 +Slitherは、パターンマッチングのようなアプローチを用いて、コードのさまざまな構成要素とその表現を走査し、矛盾や欠陥を見つけることができます。 -例えば、以下の検出器は構文関連の問題を探します： +例えば、以下の検出器は構文関連の問題を探します。 -- [状態変数のシャドーイング](https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing)：すべての状態変数でイテレートし、継承されたコントラクトから変数がシャドーされているかを確認します（[state.py#L51-L62](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/shadowing/state.py#L51-L62)）。 +- [状態変数のシャドーイング](https://github.com/crytic/slither/wiki/Detector-Documentation#state-variable-shadowing): すべての状態変数を反復処理し、継承されたコントラクトの変数をシャドーイングしているものがないかチェックします ([state.py#L51-L62](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/shadowing/state.py#L51-L62)) -- [不適切なERC-20インターフェース](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-erc20-interface)：不適切なERC-20関数の署名を探します（[incorrect_erc20_interface.py#L34-L55](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/erc/incorrect_erc20_interface.py#L34-L55)）。 +- [不正確なERC20インターフェース](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-erc20-interface): 不正確なERC20関数のシグネチャを探します ([incorrect_erc20_interface.py#L34-L55](https://github.com/crytic/slither/blob/0441338e055ab7151b30ca69258561a5a793f8ba/slither/detectors/erc/incorrect_erc20_interface.py#L34-L55)) ### 意味解析 {#semantic-analysis} -構文解析とは対照的に、意味解析は、より深くコードの「意味」を解析します。 この解析手法は、いくつかの種類に大別できます。 意味解析は、より強力で有益な結果を得られますが、より複雑なコードを書く必要があります。 +構文解析とは対照的に、意味解析はより深く掘り下げ、コードの「意味」を解析します。 この系統には、いくつかの広範な種類の解析が含まれます。 それらはより強力で有用な結果につながりますが、記述もより複雑になります。 -意味解析は、最も高度な脆弱性検出に用いられています。 +意味解析は、最も高度な脆弱性検出に使用されます。 -#### データ依存解析 {#fixed-point-computation} +#### データ依存性解析 {#fixed-point-computation} -`variable_a`の値が`variable_b`の影響を受けるパスが存在する場合、`variable_a`の変数は`variable_b`に対して依存関係を持ちます。 +`variable_a`の値が`variable_b`に影響されるパスが存在する場合、変数`variable_a`は`variable_b`にデータ依存していると言われます。 -次のコードでは、`variable_a`は`variable_b`に依存しています： +次のコードでは、`variable_a`は`variable_b`に依存しています。 ```solidity // ... variable_a = variable_b + 1; ``` -Slitherでは、中間表現（以下を参照）を利用して、[データの依存関係](https://github.com/crytic/slither/wiki/data-dependency)を解析する機能が搭載されています。 +Slitherには、その中間表現 (後のセクションで説明) のおかげで、組み込みの[データ依存性](https://github.com/crytic/slither/wiki/data-dependency)機能が備わっています。 -データ依存関係を解析する具体例としては、[危険をもたらす厳密な等値の検出器](https://github.com/crytic/slither/wiki/Detector-Documentation#dangerous-strict-equalities)を参照してください。 ここで、Slitherは、ある危険な値に対する厳密な等値比較を発見しようと試みます（[incorrect_strict_equality.py#L86-L87](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L86-L87)）。その上で、攻撃者がコントラクトをトラップできる状態を防止するために、`==`ではなく、`>=`または`<=`を使用するようにユーザーに警告します。 検出器はまず、`balanceOf(address)`の呼び出しにおける戻り値を危険な値だと見なし（[incorrect_strict_equality.py#L63-L64](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L63-L64)）、データ依存関係エンジンを使用してその使用状況を追跡します。 +データ依存性の使用例は、[危険な厳密等価性検出器](https://github.com/crytic/slither/wiki/Detector-Documentation#dangerous-strict-equalities)にあります。 ここでは、Slitherは危険な値との厳密な等価比較を探し ([incorrect_strict_equality.py#L86-L87](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L86-L87))、攻撃者がコントラクトを罠にかけるのを防ぐために、`==`ではなく`>=`または`<=`を使用すべきであるとユーザーに通知します。 とりわけ、検出器は `balanceOf(address)` の呼び出しの戻り値を危険とみなし ([incorrect_strict_equality.py#L63-L64](https://github.com/crytic/slither/blob/6d86220a53603476f9567c3358524ea4db07fb25/slither/detectors/statements/incorrect_strict_equality.py#L63-L64))、その使用状況を追跡するためにデータ依存性エンジンを使用します。 -#### 不動点の計算 {#fixed-point-computation} +#### 不動点計算 {#fixed-point-computation} -解析がエッジを辿ってCFG全体を移動する場合、すでに訪問済みのノードを発見する可能性が高いでしょう。 例えば、以下のようなループがある場合です： +解析がCFGを走査してエッジをたどる場合、すでに訪れたノードに遭遇する可能性があります。 例えば、以下のようにループが存在する場合です。 ```solidity for(uint i; i < range; ++){ @@ -183,23 +178,23 @@ for(uint i; i < range; ++){ } ``` -この場合、解析をいつ停止するかを指定する必要があります。 それには、（1）ノードごとにイテレートする上限回数を設定するか、（2）いわゆる_不動点_を計算する、という2つの戦略があります。 不動点とは、当該ノードをさらに解析しても有益な情報が得られない点を意味します。 +解析はいつ停止すべきかを知る必要があります。 ここには2つの主要な戦略があります。(1) 各ノードを有限回反復する、(2) いわゆる_不動点_を計算する。 不動点とは、基本的に、そのノードを解析しても、もはや有意義な情報が得られないことを意味します。 -不動点を使用する実例としては、リエントランシー検出器が挙げられます。Slitherでは、当該のノードを探索し、外部からの呼び出しを見つけて、ストレージへの書き込み／読み取りを行います。 この処理を通じて不動点に到達すると（[reentrancy.py#L125-L131](https://github.com/crytic/slither/blob/master/slither/detectors/reentrancy/reentrancy.py#L125-L131)）、探索を停止し、様々なリエントランシーのパターン（[reentrancy_beign.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_benign.py)）、（[reentrancy_read_before_write.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_read_before_write.py)）、（[reentrancy_eth.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_eth.py)）に基づき、結果を解析してリエントランシーが存在するか否かを判定します。 +不動点の使用例は、リエントランシー検出器に見られます。Slitherはノードを探索し、外部呼び出し、ストレージへの書き込みと読み込みを探します。 不動点に達すると ([reentrancy.py#L125-L131](https://github.com/crytic/slither/blob/master/slither/detectors/reentrancy/reentrancy.py#L125-L131))、探索を停止し、さまざまなリエントランシーパターン ([reentrancy_benign.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_benign.py), [reentrancy_read_before_write.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_read_before_write.py), [reentrancy_eth.py](https://github.com/crytic/slither/blob/b275bcc824b1b932310cf03b6bfb1a1fef0ebae1/slither/detectors/reentrancy/reentrancy_eth.py)) を通じて結果を解析し、リエントランシーが存在するかどうかを確認します。 -効率的な不動点計算を用いた解析を作成するには、解析において情報がどのように拡散するかをよく理解しておく必要があります。 +効率的な不動点計算を用いた解析を書くには、解析がどのように情報を伝播させるかをよく理解する必要があります。 ### 中間表現 {#intermediate-representation} -中間表現（IR）は、オリジナルのコードよりも静的解析を実行しやすくした言語です。 Slitherでは、SolidityをSlither独自のIRである[SlithIR](https://github.com/crytic/slither/wiki/SlithIR)に変換します。 +中間表現 (IR) とは、元の言語よりも静的解析に適した言語のことです。 Slitherは、Solidityを独自の中間表現である [SlithIR](https://github.com/crytic/slither/wiki/SlithIR) に変換します。 -基本的なチェックを作成したいだけの場合は、SlithIRを理解する必要はありません。 ただし、より高度な意味解析を作成したい場合は、SlithIRの知識が有益になるでしょう。 [SlithIR](https://github.com/crytic/slither/wiki/Printer-documentation#slithir)および[SSA](https://github.com/crytic/slither/wiki/Printer-documentation#slithir-ssa)のプリンターは、コードがどのように変換されるかを理解する上で役立ちます。 +基本的なチェックを書きたいだけなら、SlithIRを理解する必要はありません。 しかし、高度な意味解析を書く予定がある場合は、役立つでしょう。 [SlithIR](https://github.com/crytic/slither/wiki/Printer-documentation#slithir) および [SSA](https://github.com/crytic/slither/wiki/Printer-documentation#slithir-ssa) プリンターは、コードがどのように変換されるかを理解するのに役立ちます。 ## APIの基本 {#api-basics} -Slitherには、コントラクトの基本的な属性や関数について探索できるAPIが含まれています。 +Slitherには、コントラクトとその関数の基本的な属性を探索できるAPIがあります。 -コードベースを読み込むには、以下を実行します： +コードベースを読み込むには、次のようにします。 ```python from slither import Slither @@ -207,32 +202,32 @@ slither = Slither('/path/to/project') ``` -### コントラクトや関数を探索する {#exploring-contracts-and-functions} +### コントラクトと関数の探索 {#exploring-contracts-and-functions} -`Slither`オブジェクトは、以下を持ちます： +`Slither`オブジェクトには以下のものがあります。 -- `contracts (list(Contract)`：コントラクトのリスト -- `contracts_derived (list(Contract)`：他のコントラクトに継承されていないコントラクトのリスト（コントラクトのサブセット） -- `get_contract_from_name (str)`：名前でコントラクトを返します +- `contracts (list(Contract))`: コントラクトのリスト +- `contracts_derived (list(Contract))`: 他のコントラクトによって継承されていないコントラクトのリスト (コントラクトのサブセット) +- `get_contract_from_name (str)`: 名前からコントラクトを返します -`Contract`オブジェクトには、以下のものがあります。 +`Contract`オブジェクトには以下のものがあります。 -- `name (str)`：コントラクトの名前 -- `functions (list(Function))`：関数のリスト -- `modifiers (list(Modifier))`：修飾子のリスト -- `all_functions_called (list(Function/Modifier))`：コントラクトがリーチできるすべての内部関数のリスト -- `inheritance (list(Contract))`：継承されたコントラクトのリスト -- `get_function_from_signature (str)`：署名から関数を返します -- `get_modifier_from_signature (str)`：署名から修飾子を返します -- `get_state_variable_from_name (str)`：名前から状態変数を返します +- `name (str)`: コントラクトの名前 +- `functions (list(Function))`: 関数のリスト +- `modifiers (list(Modifier))`: 修飾子のリスト +- `all_functions_called (list(Function/Modifier))`: コントラクトから到達可能なすべての内部関数のリスト +- `inheritance (list(Contract))`: 継承されたコントラクトのリスト +- `get_function_from_signature (str)`: シグネチャからFunctionを返します +- `get_modifier_from_signature (str)`: シグネチャからModifierを返します +- `get_state_variable_from_name (str)`: 名前からStateVariableを返します -`Function`オブジェクトまたは`Modifier`オブジェクトは、以下を持ちます： +`Function`または`Modifier`オブジェクトには以下のものがあります。 -- `name (str)`：関数の名前 -- `contract (contract)`：この関数を宣言したコントラクト -- `nodes (list(Node))`：この関数／修飾子のCFGを攻勢するノードのリスト -- `entry_point (Node)`: CFG (制御フローグラフ) のエントリポイント -- `variables_read (list(Variable))`: 読み込まれた変数のリスト +- `name (str)`: 関数の名前 +- `contract (contract)`: 関数が宣言されているコントラクト +- `nodes (list(Node))`: 関数/修飾子のCFGを構成するノードのリスト +- `entry_point (Node)`: CFGのエントリポイント +- `variables_read (list(Variable))`: 読み取られた変数のリスト - `variables_written (list(Variable))`: 書き込まれた変数のリスト -- `state_variables_read (list(StateVariable))`: 読み込まれた状態変数のリスト (読み込まれた変数のサブセット) -- `state_variables_written (list(StateVariable))`: 書き込まれた状態変数のリスト (書き込まれた変数のサブセット) +- `state_variables_read (list(StateVariable))`: 読み取られた状態変数のリスト (variables`readのサブセット) +- `state_variables_written (list(StateVariable))`: 書き込まれた状態変数のリスト (variables`writtenのサブセット) diff --git a/public/content/translations/ja/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/ja/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md index 8c4d3d5f70e..5ae9977cda8 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md @@ -1,12 +1,9 @@ --- -title: Tellorをオラクルとしてセットアップする方法 -description: プロトコルにTellorオラクルを統合する作業を開始するためのガイド +title: "Tellorをオラクルとしてセットアップする方法" +description: "プロトコルにTellorオラクルを統合する作業を開始するためのガイド" author: "Tellor" lang: ja -tags: - - "Solidity" - - "スマートコントラクト" - - "オラクル" +tags: [ "Solidity", "スマートコントラクト", "オラクル" ] skill: beginner published: 2021-06-29 source: Tellor Docs @@ -15,11 +12,11 @@ sourceUrl: https://docs.tellor.io/tellor/ 確認クイズ：あなたのプロトコルはもうすぐ完成しますが、オフチェーンのデータにアクセスするにはオラクルが必要です。何をすればよいでしょうか？ -## （ソフトな）前提知識 {#soft-prerequisites} +## (緩やかな) 前提条件 {#soft-prerequisites} この投稿は、なるべくシンプルかつ明快に、オラクルフィードにアクセスする方法を説明するものです。 ただし、オラクルについて理解するには以下のプログラミングスキルが必要です。 -前提条件： +前提知識： - ターミナルを操作できる - npmがインストール済みである @@ -29,17 +26,17 @@ Tellorは、実装可能かつ開発継続中のオープンソースのオラ ## 概要 {#overview} -Tellorは、オフチェーンのデータポイントの値（例：BTC/USD）を請求できるオラクルシステムです。報告者は、イーサリアムの全スマートコントラクトがアクセスできるオンチェーンのデータバンクに対してこの値を追加するために競います。 このデータバンクへの入力は、ステーキング済みの報告者で構成されるネットワークにより保護されています。 Tellorは、暗号資産経済におけるインセンティブの仕組みを活用し、Tellorのトークン、トリビュート（TRB）、および紛争メカニズムに基づき、正直なデータを提出した報告者に報酬を与え、悪意のユーザーを処罰します。 +Tellorは、オフチェーンのデータポイントの値（例：BTC/USD）を請求できるオラクルシステムです。報告者は、イーサリアムの全スマートコントラクトがアクセスできるオンチェーンのデータバンクに対してこの値を追加するために競います。 このデータバンクへの入力は、ステーキング済みの報告者で構成されるネットワークにより保護されています。 Tellorは暗号経済的なインセンティブの仕組みを活用し、TellorのトークンであるTributes（TRB）の発行と紛争メカニズムを通じて、誠実なデータを提出したレポーターに報酬を与え、悪意のあるアクタを罰します。 このチュートリアルでは、以下について説明します： - 導入および稼働に必要な初回ツールキットの設定方法 - 簡単な実例に基づくステップごとの説明 -- 現在Tellorをテストできるネットワークのアドレスリスト +- 現在Tellorをテストできるテストネットのネットワークアドレス一覧 -## Tellorを使うには {#usingtellor} +## UsingTellorの使用 {#usingtellor} -まず、Tellorをオラクルとして使用するために必要な基本ツールをインストールします。 Tellorのユーザーコントラクトをインストールするには、[このパッケージ](https://github.com/tellor-io/usingtellor)を使ってください。 +まず、Tellorをオラクルとして使用するために必要な基本ツールをインストールします。 Tellor User Contractsをインストールするには、[このパッケージ](https://github.com/tellor-io/usingtellor)を使用します： `npm install usingtellor` @@ -49,7 +46,7 @@ Tellorは、オフチェーンのデータポイントの値（例：BTC/USD） ### BTC/USDの例 {#btcusd-example} -この「UsingTellor」コントラクトを継承し、Tellorのアドレスをコントラクタの引数として渡します： +この「UsingTellor」コントラクトを継承し、Tellorのアドレスをコンストラクタの引数として渡します： 具体的なコードは、以下のようになります： @@ -59,7 +56,7 @@ import "usingtellor/contracts/UsingTellor.sol"; contract PriceContract is UsingTellor { uint256 public btcPrice; - //This Contract now has access to all functions in UsingTellor + //このコントラクトは、UsingTellor のすべての関数にアクセスできるようになりました constructor(address payable _tellorAddress) UsingTellor(_tellorAddress) public {} @@ -77,8 +74,8 @@ function setBtcPrice() public { } ``` -コントラクトアドレスの完全なリストについては、[こちら](https://docs.tellor.io/tellor/the-basics/contracts-reference)を参照してください。 +コントラクトアドレスの完全なリストは、[こちら](https://docs.tellor.io/tellor/the-basics/contracts-reference)を参照してください。 -利便性のために、UsingTellorのリポジトリには簡単な統合を目的としたバージョンである[Tellor Playground](https://github.com/tellor-io/TellorPlayground)コントラクトが含まれています。 有益な関数のリストについては、 [こちら](https://github.com/tellor-io/sampleUsingTellor#tellor-playground)を参照してください。 +利便性のために、UsingTellorのリポジトリには簡単な統合を目的としたバージョンである[Tellor Playground](https://github.com/tellor-io/TellorPlayground)コントラクトが含まれています。 便利な関数の一覧は[こちら](https://github.com/tellor-io/sampleUsingTellor#tellor-playground)をご覧ください。 -Tellorオラクルをより堅牢に実装したい場合は、[こちらで](https://github.com/tellor-io/usingtellor/blob/master/README.md)利用可能な関数の全リストを確認してください。 +Tellorオラクルのより堅牢な実装については、利用可能な関数の完全なリストを[こちら](https://github.com/tellor-io/usingtellor/blob/master/README.md)で確認してください。 diff --git a/public/content/translations/ja/developers/tutorials/how-to-view-nft-in-metamask/index.md b/public/content/translations/ja/developers/tutorials/how-to-view-nft-in-metamask/index.md index 21fdf826cb0..4bb6d8afa0e 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-view-nft-in-metamask/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-view-nft-in-metamask/index.md @@ -1,36 +1,33 @@ --- -title: ウォレットでNFTを表示する方法(NFTチュートリアルシリーズのパート3/3) -description: このチュートリアルでは、既存のMetaMask上にNFTを表示する方法について説明します。 +title: "ウォレットでNFTを表示する方法(NFTチュートリアルシリーズ パート3/3)" +description: "このチュートリアルでは、MetaMaskで既存のNFTを表示する方法について説明します。" author: "Sumi Mudgil" -tags: - - "ERC-721" - - "Alchemy" - - "Solidity" +tags: [ "ERC-721", "Alchemy", "Solidity" ] skill: beginner lang: ja published: 2021-04-22 --- -このチュートリアルは、NFTチュートリアルシリーズのパート3/3です。ここでは、新しくミントされたNFTを見ていきますが、 MetaMaskを使用して、メインネットや任意のテストネットなど、ERC-721トークンの一般的なチュートリアルを使用することができます。 イーサリアム上でNFTをミントする方法については、[パート1のNFTスマートコントラクトの作成&デプロイ方法](/developers/tutorials/how-to-write-and-deploy-an-nft)をご覧ください。 +このチュートリアルは、NFTチュートリアルシリーズのパート3/3で、新しくミントしたNFTを表示します。 ただし、この一般的なチュートリアルは、メインネットや任意のテストネットを含め、MetaMaskを使用するあらゆるERC-721トークンに利用できます。 Ethereumで独自のNFTをミントする方法を学びたい場合は、[パート1「NFTスマートコントラクトの作成とデプロイ方法」](/developers/tutorials/how-to-write-and-deploy-an-nft)をご覧ください。 -朗報です。 これからご説明する仮想ウォレットで新しくミントされたNFTを表示する方法は、NFTチュートリアルシリーズの中で最短かつ最も簡単なパートです。 この例では、前の2つのパートで使用していたMetaMaskを使用します。 +おめでとうございます！ NFTチュートリアルシリーズの中で最も短く、最も簡単なパートにたどり着きました。それは、仮想ウォレットで新しくミントしたNFTを表示する方法です。 この例では、前の2つのパートで使用したMetaMaskを使用します。 -前提条件として、モバイルにMetaMaskをインストールしておく必要があり、NFTを割り当てたアカウントも必要となります。[iOS](https://apps.apple.com/us/app/metamask-blockchain-wallet/id1438144202)または[Android](https://play.google.com/store/apps/details?id=io.metamask&hl=en_US&gl=US)から無料でアプリを入手できます。 +前提条件として、モバイル版MetaMaskをインストールし、NFTをミントしたアカウントを含めておく必要があります。アプリは[iOS](https://apps.apple.com/us/app/metamask-blockchain-wallet/id1438144202)または[Android](https://play.google.com/store/apps/details?id=io.metamask&hl=en_US&gl=US)で無料で入手できます。 ## ステップ1: ネットワークをSepoliaに設定する {#set-network-to-sepolia} -アプリの上部にある「Wallet」ボタンを押すと、ネットワークを選択するよう指示されます。 Sepoliaネットワーク上でNFTをミントしたので、ネットワークとしてSepoliaを選択します。 +アプリの上部にある「ウォレット」ボタンを押すと、ネットワークを選択するよう促されます。 NFTはSepoliaネットワークでミントしたため、ネットワークとしてSepoliaを選択します。 ![MetaMaskモバイルでSepoliaをネットワークとして設定する方法](./goerliMetamask.gif) -## ステップ2: 収集品をMetaMaskに追加する {#add-nft-to-metamask} +## ステップ2: コレクティブルをMetaMaskに追加する {#add-nft-to-metamask} -Sepoliaネットワークに接続後、右側の「Collectibles」タブを選択し、NFTスマートコントラクトアドレスとNFTのERC-721トークンIDを追加します。そうすることで、チュートリアルのパートIIでデプロイしたNFTからのトランザクションハッシュに基づいてEtherscanで見つけることができます。 +Sepoliaネットワークに接続したら、右側にある「コレクティブル」タブを選択し、NFTのスマートコントラクトアドレスとERC-721トークンIDを追加します。これらは、チュートリアルのパートIIでデプロイしたNFTのトランザクションハッシュを基に、Etherscanで確認できます。 ![トランザクションハッシュとERC-721トークンIDを見つける方法](./findNFTEtherscan.png) -何度か再読込をしないと表示されないこともありますが、NFTはそこに存在しています 。 +NFTを表示するために数回更新が必要な場合がありますが、最終的には表示されます! ![NFTをMetaMaskにアップロードする方法](./findNFTMetamask.gif) -おめでとうございます。 NFTのミントに成功しました。NFTを表示することもできます。 あなたがNFTの世界で新たな旋風を巻き起こすのを楽しみにしています。 +おめでとうございます！ NFTのミントに成功し、表示できるようになりました。 あなたがNFTの世界で新たな旋風を巻き起こすのを楽しみにしています。 diff --git a/public/content/translations/ja/developers/tutorials/how-to-write-and-deploy-an-nft/index.md b/public/content/translations/ja/developers/tutorials/how-to-write-and-deploy-an-nft/index.md index e1bb40929f2..01c09af8750 100644 --- a/public/content/translations/ja/developers/tutorials/how-to-write-and-deploy-an-nft/index.md +++ b/public/content/translations/ja/developers/tutorials/how-to-write-and-deploy-an-nft/index.md @@ -1,12 +1,8 @@ --- -title: NFTの作成&デプロイ方法(NFTチュートリアルシリーズの1/3) -description: このチュートリアルは、イーサリアムとInterPlanetary File System(IPFS)を使用して、非代替性トークン(ERC-721トークン)のスマートコントラクトを作成、デプロイする方法について、段階的に学ぶNFTシリーズのパート1です +title: "NFTの作成とデプロイ方法(NFTチュートリアルシリーズ 1/3)" +description: "このチュートリアルは、イーサリアムとInterPlanetary File System(IPFS)を使用して、非代替性トークン(ERC-721トークン)のスマートコントラクトを作成、デプロイする方法について、段階的に学ぶNFTシリーズのパート1です" author: "Sumi Mudgil" -tags: - - "ERC-721" - - "Alchemy" - - "Solidity" - - "スマートコントラクト" +tags: [ "ERC-721", "Alchemy", "Solidity", "スマートコントラクト" ] skill: beginner lang: ja published: 2021-04-22 @@ -14,72 +10,79 @@ published: 2021-04-22 NFTによってブロックチェーンが世間の目に触れるようになった今、イーサリアムブロックチェーン上に自分のNFTコントラクト(ERC-721トークン)を公開することで、自身のモチベーションを高める絶好の機会となります。 -Alchemyは、Makersplace(直近では、Christie'sでレコードデジタルアートワークが$69Mで落札され、記録を更新)、 Dapper Labs(NBA Top Shot&Crypto Kittiesのクリエイター)、OpenSea(世界最大のNFTマーケットプレイス)、Zora、Super Rare、NFTFi、Foundation、Enjin、Origin Protocol、Immutableなど、NFTスペースで著名人の力になれることを非常に誇りに思っています。 +Alchemyは、Makersplace (最近、クリスティーズで6900万ドルの記録的なデジタルアート作品の販売を達成)、Dapper Labs (NBA Top Shot & Crypto Kittiesの制作者)、OpenSea (世界最大のNFTマーケットプレイス)、Zora、Super Rare、NFTfi、Foundation、Enjin、Origin Protocol、Immutableなど、NFT分野のビッグネームを支えていることを非常に誇りに思っています。 -このチュートリアルでは、[MetaMask](https://metamask.io/)、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org/)、[Pinata](https://pinata.cloud/)、[Alchemy](https://alchemy.com/signup/eth)を使用してSepoliaテストネットワーク上でERC-721スマートコントラクトの作成とデプロイのウォークスルーを行います(現時点でしっかりと理解できていなくても、心配はご無用です。後ほどご説明します) 。 +このチュートリアルでは、[MetaMask](https://metamask.io/)、[Solidity](https://docs.soliditylang.org/en/v0.8.0/)、[Hardhat](https://hardhat.org/)、[Pinata](https://pinata.cloud/)、[Alchemy](https://alchemy.com/signup/eth)を使用して、Sepoliaテストネット上でERC-721スマートコントラクトを作成し、デプロイする手順を説明します (これらの意味がまだ分からなくても心配はいりません — これから説明します！)。 チュートリアルのパート2では、スマートコントラクトを使用してNFTをミントする方法について、パート3では、MetaMaskでNFTを表示する方法について説明します。 -ご質問があれば[Alchemy Discord](https://discord.gg/gWuC7zB)にお問い合わせいただくか、 [AlchemyのNFT API docs](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)をご覧ください。 +もちろん、いつでも質問があれば、[Alchemy Discord](https://discord.gg/gWuC7zB)でお気軽にお問い合わせいただくか、[AlchemyのNFT APIドキュメント](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)をご覧ください！ ## ステップ1: イーサリアムネットワークに接続する {#connect-to-ethereum} -イーサリアムのブロックチェーンにリクエストを行う方法はたくさんありますが、ここでは分かりやすくするため、[Alchemy](https://alchemy.com/signup/eth)の無料アカウントを使用します。このアカウントはブロックチェーンの開発者プラットフォームとAPIで、独自のノードを実行せずにイーサリアムチェーンと通信できるものです。 +イーサリアムのブロックチェーンにリクエストを送信する方法はいくつかありますが、簡単にするために、[Alchemy](https://alchemy.com/signup/eth)の無料アカウントを使用します。Alchemyは、独自のノードを実行することなくイーサリアムチェーンと通信できる、ブロックチェーン開発者向けのプラットフォームおよびAPIです。 -このチュートリアルでは、スマートコントラクトのデプロイメントの仕組みを理解するために、Alchemyの開発者用ツールも活用します。 Alchemyアカウントをお持ちでない場合は、 [こちら](https://alchemy.com/signup/eth)から無料で登録できます。 +このチュートリアルでは、スマートコントラクトのデプロイメントの仕組みを理解するために、Alchemyの開発者用ツールも活用します。 まだAlchemyアカウントをお持ちでない場合は、[こちら](https://alchemy.com/signup/eth)から無料で登録できます。 -## ステップ2: アプリ(およびAPIキー)を作成する {#make-api-key} +## ステップ2: アプリ (およびAPIキー) を作成する {#make-api-key} -Alchemyのアカウントを作成すると、アプリを作成することでAPIキーを生成できます。 これにより、Sepoliaテストネットワークへのリクエストが可能になります。 テストネットワークの詳細については、[こちらのガイド](https://docs.alchemyapi.io/guides/choosing-a-network)をご覧ください。 +Alchemyのアカウントを作成した後、アプリを作成することでAPIキーを生成することができます。 これにより、Sepoliaテストネットワークへのリクエストが可能になります。 テストネットについてさらに詳しく知りたい場合は、[こちらのガイド](https://docs.alchemyapi.io/guides/choosing-a-network)をご覧ください。 1. ナビゲーションバーの「Apps」にマウスを合わせて、「Create App)」をクリックし、Alchemyダッシュボードの「Create App」ページに移動してください。 -![アプリを作成する](./create-your-app.png) +![アプリを作成](./create-your-app.png) 2. アプリに名前を付け(私たちは「My First NFT!」にしました)、簡単な説明を記述し、「Ethereum」チェーンを選択して、ネットワークに「Sepolia」を設定します。 マージ以降、他のテストネットは非推奨となっています。 ![アプリを設定して公開する](./alchemy-explorer-sepolia.png) -3. 「Create app」をクリックして完了です。 下記のテーブルにアプリが表示されます。 +3. 「Create app」をクリックします。 アプリが下の表に表示されます。 -## ステップ 3: イーサリアムアカウント(アドレス)を作成する {#create-eth-address} +## ステップ3: イーサリアムアカウント (アドレス) を作成する {#create-eth-address} -トランザクションの送受信には、イーサリアムアカウントが必要です。 このチュートリアルでは、イーサリアムアカウントアドレスを管理するためにブラウザの仮想ウォレットであるMetamaskを使用します。 イーサリアムのトランザクションの仕組みの詳細については、イーサリアム・ファウンデーションの[こちらのページ](/developers/docs/transactions/)をご覧ください。 +トランザクションの送受信には、イーサリアムアカウントが必要です。 このチュートリアルでは、イーサリアムアカウントアドレスを管理するためにブラウザの仮想ウォレットであるMetamaskを使用します。 イーサリアム上のトランザクションの仕組みについてさらに詳しく知りたい場合は、イーサリアム・ファウンデーションの[こちらのページ](/developers/docs/transactions/)をご覧ください。 -Metamaskのアカウントは[こちら](https://metamask.io/download)から無料でダウンロード、作成できます。 アカウントを作成後、またはすでにアカウントをお持ちの場合は(実際に支払いが発生しないように)右上の「Sepolia Test Network」に切り替えてください。 +MetaMaskアカウントは、[こちら](https://metamask.io/download)から無料でダウンロードして作成できます。 アカウントを作成後、またはすでにアカウントをお持ちの場合は(実際に支払いが発生しないように)右上の「Sepolia Test Network」に切り替えてください。 -![Sepoliaをネットワークとして設定する](./metamask-goerli.png) +![Sepoliaをネットワークとして設定](./metamask-goerli.png) -## ステップ4: フォーセットからイーサリアムを追加する {#step-4-add-ether-from-a-faucet} +## ステップ4: フォーセットからイーサを追加する {#step-4-add-ether-from-a-faucet} -テストネットワークにスマートコントラクトをデプロイするには、偽のETHが複数必要になります。 ETHを取得するには、Alchemyがホストする[Sepoliaフォーセット](https://sepoliafaucet.com/)へ行き、ログインしてアカウントアドレスを入力し、「Send Me ETH」をクリックしてください。 MetamaskアカウントにETHが表示されるはずです。 +テストネットワークにスマートコントラクトをデプロイするには、偽のETHが複数必要になります。 ETHを入手するには、Alchemyがホストする[Sepoliaフォーセット](https://sepoliafaucet.com/)にアクセスし、ログインしてアカウントアドレスを入力し、「Send Me ETH」をクリックします。 MetamaskアカウントにETHが表示されるはずです。 ## ステップ5: 残高を確認する {#check-balance} -残高を再度確認するには、 [Alchemy CHAINS APIS](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)を使用して [eth_getBalance](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)をリクエストしてみましょう。 リクエストすると、ウォレット内のETHの量が返却されます。 Metamaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 +残高があることを再確認するために、[Alchemyのcomposerツール](https://composer.alchemyapi.io?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)を使用して[eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)リクエストを実行してみましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 MetaMaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 - `{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}` + ``` + {"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"} + ``` -> **注:** この結果の単位はweiであり、ETHではありません。 weiはETHの最小単位として使われています。 「wei」 から「ETH」への変換は次の通りです: 1 eth = 1018 wei 。 例えば、0xde0b6b3a7640000を10進数に変換すると1*1018 weiとなり、1ETHに相当します。 +> **注** この結果はETHではなく、wei単位です。 weiはETHの最小単位として使われています。 「wei」 から「ETH」への変換は次の通りです: 1 eth = 1018 wei 。 例えば、0xde0b6b3a7640000を10進数に変換すると1\*1018 weiとなり、1ETHに相当します。 -ご安心ください。 私たちの偽物のお金はすべてそこにあります。 +ふう! 私たちの偽物のお金はすべてそこにあります。 ## ステップ6: プロジェクトを初期化する {#initialize-project} まず、プロジェクトのフォルダを作成する必要があります。 コマンドラインに移動し、次のように入力します。 + ``` mkdir my-nft cd my-nft + ``` -プロジェクトフォルダに入ったら、 npm initを使用してプロジェクトを初期化します。 npmがインストールされていない場合は、[こちらの手順](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm)に従ってください。([Node.js](https://nodejs.org/en/download/)も必要となりますので、こちらもダウンロードしてください。) +プロジェクトフォルダに入ったら、 npm initを使用してプロジェクトを初期化します。 まだnpmをインストールしていない場合は、[これらの手順](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm)に従ってください ([Node.js](https://nodejs.org/en/download/)も必要なので、そちらもダウンロードしてください！)。 + ``` npm init + ``` インストール時の質問に対する回答方法は自由です。参考までに過去の回答方法は次のとおりです。 + ```json package name: (my-nft) version: (1.0.0) - description: My first NFT! + description: 初めてのNFT！ entry point: (index.js) test command: git repository: @@ -91,7 +94,7 @@ Metamaskのアカウントは[こちら](https://metamask.io/download)から無 { "name": "my-nft", "version": "1.0.0", - "description": "My first NFT!", + "description": "初めてのNFT！", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" @@ -100,26 +103,32 @@ Metamaskのアカウントは[こちら](https://metamask.io/download)から無 "license": "ISC" } ``` + 「package.json」を承認してください。これで準備が完了しました。 ## ステップ7: [Hardhat](https://hardhat.org/getting-started/#overview)をインストールする {#install-hardhat} -Hardhatは、イーサリアムのソフトウェアをコンパイル、デプロイ、テスト、デバッグするための開発環境です。 開発者がライブチェーンにデプロイする前に、スマートコントラクトやDappsをローカルに構築する際に役立ちます。 +Hardhatは、イーサリアムのソフトウェアをコンパイル、デプロイ、テスト、デバッグするための開発環境です。 デベロッパーがライブチェーンにデプロイする前に、スマートコントラクトや分散型アプリケーション(Dapp)をローカルに構築する際に役立ちます。 「my-nft」プロジェクトの中で実行してください。 + ``` npm install --save-dev hardhat + ``` -[インストール手順](https://hardhat.org/getting-started/#overview)の詳細については、こちらのページをご覧ください。 +[インストール手順](https://hardhat.org/getting-started/#overview)の詳細については、このページをご覧ください。 ## ステップ8: Hardhatプロジェクトを作成する {#create-hardhat-project} -プロジェクトフォルダ内で実行してください。 +プロジェクトフォルダ内で以下を実行します。 + ``` npx hardhat + ``` -次に、ウェルカムメッセージと選択肢が表示されます。 「create an empty hardhat.config.js」を選択してください。 +ウェルカムメッセージと、次に何をするのかを選択できるオプションが表示されます。 「create an empty hardhat.config.js」を選択してください。 + ``` 888 888 888 888 888 888 888 888 888 888 888 888 888 888 888 @@ -128,11 +137,12 @@ Hardhatは、イーサリアムのソフトウェアをコンパイル、デプ 888 888 .d888888 888 888 888 888 888 .d888888 888 888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. 888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 - 👷 Welcome to Hardhat v2.0.11 👷‍ - ? What do you want to do? … - Create a sample project - ❯ Create an empty hardhat.config.js - Quit + 👷 Hardhat v2.0.11へようこそ 👷‍ + ? 何を行いますか？ … + サンプルプロジェクトを作成する + ❯ 空のhardhat.config.jsを作成する + 終了 + ``` 「hardhat.config.js」というファイルが生成され、ここでプロジェクトのセットアップの全てを指定します (ステップ13)。 @@ -140,8 +150,10 @@ Hardhatは、イーサリアムのソフトウェアをコンパイル、デプ プロジェクトを整理するために、2つの新しいフォルダを作成します。 コマンドラインでプロジェクトのルートディレクトリに移動し、次のように入力します。 + ``` mkdir contracts mkdir scripts + ``` - 「contracts/」は、NFT スマートコントラクトコードを保持する場所です。 @@ -149,16 +161,16 @@ Hardhatは、イーサリアムのソフトウェアをコンパイル、デプ ## ステップ10: コントラクトを作成する {#write-contract} -さて、環境が整ったところで、もっと面白いことをやりましょう。_スマートコントラクトのコードの作成です。_ +環境が整ったので、もっと面白いこと、つまり_スマートコントラクトのコード作成_に取り掛かりましょう！ -お気に入りのエディタでmy-nftプロジェクトを開きます(通常は[VScode](https://code.visualstudio.com/)を使用しています)。 スマートコントラクトは、Solidityと呼ばれる言語で記述されています。MyNFT.solスマートコントラクトの作成にこの言語を使用します。 +お気に入りのエディタ (私たちは[VSCode](https://code.visualstudio.com/)が好きです) でmy-nftプロジェクトを開いてください。 スマートコントラクトは、Solidityと呼ばれる言語で記述されています。MyNFT.solスマートコントラクトの作成にこの言語を使用します。 -1. `contracts`フォルダに移動し、MyNFT.solという名前の新規ファイルを作成します。 +1. `contracts`フォルダに移動し、MyNFT.solという名前の新しいファイルを作成します -2. 以下は、 NFTスマートコントラクトコードです。これは[OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc721)ライブラリのERC-721実装に基づいています。 以下の内容をコピーして、MyNFT.solファイルに貼り付けます。 +2. 以下は、[OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc721)ライブラリのERC-721実装をベースにした、私たちのNFTスマートコントラクトのコードです。 以下の内容をコピーして、MyNFT.solファイルに貼り付けます。 ```solidity - //Contract based on [https://docs.openzeppelin.com/contracts/3.x/erc721](https://docs.openzeppelin.com/contracts/3.x/erc721) + //[https://docs.openzeppelin.com/contracts/3.x/erc721](https://docs.openzeppelin.com/contracts/3.x/erc721) をベースにしたコントラクト // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; @@ -188,29 +200,29 @@ Hardhatは、イーサリアムのソフトウェアをコンパイル、デプ } ``` -3. OpenZeppelinのコントラクトライブラリからクラスを継承しているので、コマンドラインで`npm install @openzeppelin/contracts`を実行して、ライブラリをフォルダにインストールします。 +3. OpenZeppelinのコントラクトライブラリからクラスを継承しているため、コマンドラインで`npm install @openzeppelin/contracts^4.0.0`を実行して、ライブラリをフォルダにインストールします。 -では、このコードの_役割_は一体何でしょうか。 一行ずつ分解してみましょう。 +では、このコードは一体何を_している_のでしょうか？ 一行ずつ分解してみましょう。 -スマートコントラクトの先頭で、3つの[OpenZeppelin](https://openzeppelin.com/)スマートコントラクトのクラスをインポートしています。 +スマートコントラクトの冒頭で、3つの[OpenZeppelin](https://openzeppelin.com/)スマートコントラクトクラスをインポートします: -- @openzeppelin/contracts/token/ERC721/ERC721.solには、ERC-721標準の実装が含まれており、NFTスマートコントラクトはこれを継承しています。 (有効なNFTであるためには、スマートコントラクトはERC-721標準のすべてのメソッドを実装する必要があります。) 継承されたERC-721関数の詳細については、[こちら](https://eips.ethereum.org/EIPS/eip-721)のインターフェイス定義をご覧ください。 +- @openzeppelin/contracts/token/ERC721/ERC721.solには、ERC-721標準の実装が含まれており、NFTスマートコントラクトはこれを継承しています。 (有効なNFTであるためには、スマートコントラクトはERC-721標準のすべてのメソッドを実装する必要があります。) 継承されたERC-721関数の詳細については、[こちら](https://eips.ethereum.org/EIPS/eip-721)のインターフェース定義をご確認ください。 - @openzeppelin/contracts/utils/Counters.solは、1つずつ増減するカウンタを提供しており、 私たちのスマートコントラクトは、ミントされたNFTの合計数を追跡し、新しいNFTにユニークなIDを設定するためにカウンタを使用しています。 (スマートコントラクトを使用してミントされた各NFTには、ユニークなIDが割り当てられている必要があります。ここでは、ユニークIDは、存在するNFTの合計数によって決定されます。 例えば、スマートコントラクトでミントした最初のNFTには「1」のIDが付与され、2番目のNFTには「2」のIDが付与されます。) -- @openzeppelin/contracts/access/Ownable.solは[アクセスコントロール](https://docs.openzeppelin.com/contracts/3.x/access-control)をスマートコントラクトに設定するため、スマートコントラクトの所有者(あなた)だけがNFTをミントできます。 (注: アクセス制御の実装は完全に任意です。 スマートコントラクトを使って誰でもNFTをミントできるようにしたい場合は、10行目の「Ownable」、17行目の「onlyOwner」を削除します。) +- @openzeppelin/contracts/access/Ownable.solは、スマートコントラクトに[アクセス制御](https://docs.openzeppelin.com/contracts/3.x/access-control)を設定するので、スマートコントラクトの所有者 (あなた) のみがNFTをミントできます。 (注: アクセス制御の実装は完全に任意です。 スマートコントラクトを使って誰でもNFTをミントできるようにしたい場合は、10行目の「Ownable」、17行目の「onlyOwner」を削除します。) -インポートステートメントの後にカスタムNFTスマートコントラクトがありますが、非常に短いもので、カウンタ、コンストラクタ、単一の関数しか含まれていません。 これは、NFTの所有者を返す`ownerOf`とNFTの所有権を他のアカウントに転送する`transferFrom`など、NFTを作成するために必要な大部分のメソッドを実装しているOpenZeppelinコントラクトを継承したおかげです。 +インポートステートメントの後にカスタムNFTスマートコントラクトがありますが、非常に短いもので、カウンタ、コンストラクタ、単一の関数しか含まれていません。 これは、継承したOpenZeppelinコントラクトのおかげです。このコントラクトには、NFTの所有者を返す`ownerOf`や、NFTの所有権をあるアカウントから別のアカウントに移転する`transferFrom`など、NFTの作成に必要なメソッドのほとんどが実装されています。 ERC-721コンストラクタでは、「MyNFT」と「NFT」の2つの文字列を渡すことに気づくでしょう。 最初の変数はスマートコントラクトの名前で、2番目の変数はそのシンボルです。 これらの変数にはそれぞれに自由に名前を付けることができます。 -最後に、`mintNFT(address recipient, string memory tokenURI)`という関数で、NFTをミントすることできます。 この関数には2つの変数が必要です。 +最後に、NFTをミントできる`mintNFT(address recipient, string memory tokenURI)`関数があります！ この関数には2つの変数が必要です。 -- `address recipient`は、新しくミントされたNFTを受け取るアドレスを指定します。 +- `address recipient`は、新しくミントされたNFTを受け取るアドレスを指定します -- `string memory tokenURI`は、NFTのメタデータを記述したJSONドキュメントに解決される必要がある文字列です。 NFTのメタデータは、名前、説明、画像、その他の属性など、設定可能なプロパティを持つことができます。 チュートリアルのパート2では、このメタデータの設定方法について説明します。 +- `string memory tokenURI`は、NFTのメタデータを記述するJSONドキュメントに解決されるべき文字列です。 NFTのメタデータは、名前、説明、画像、その他の属性など、設定可能なプロパティを持つことができます。 チュートリアルのパート2では、このメタデータの設定方法について説明します。 -`mintNFT`は継承されたERC-721ライブラリから複数のメソッドを呼び出し、最終的にミントされたばかりのNFTのIDを示す数値を返します。 +`mintNFT`は、継承されたERC-721ライブラリからいくつかのメソッドを呼び出し、最終的に新しくミントされたNFTのIDを表す数値を返します。 ## ステップ11: MetaMaskとAlchemyをプロジェクトに接続する {#connect-metamask-and-alchemy} @@ -218,24 +230,28 @@ ERC-721コンストラクタでは、「MyNFT」と「NFT」の2つの文字列 仮想ウォレットから送信されるすべてのトランザクションには、固有の秘密鍵を使用した署名が必要です。 この許可をプログラムに与えるために、秘密鍵(とAlchemyのAPIキー)を環境ファイルに安全に格納する作業を行います。 -トランザクションの送信の詳細については、web3を使用したトランザクションの送信に関する[こちらのチュートリアル](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)をご覧ください。 +トランザクションの送信について詳しく知るには、web3を使用したトランザクション送信に関する[このチュートリアル](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)をご覧ください。 まず、プロジェクトディレクトリにdotenvパッケージをインストールします。 + ``` npm install dotenv --save + ``` -次に、 `.env`ファイルをプロジェクトのルートディレクトリに作成し、そのファイルにMetamaskの秘密鍵とHTTP Alchemy APIのURLを追加します。 +次に、プロジェクトのルートディレクトリに`.env`ファイルを作成し、MetaMaskの秘密鍵とHTTP Alchemy API URLを追加します。 -- MetaMaskから秘密鍵をエクスポートするには、 [こちらの手順](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)に従ってください。 +- MetaMaskから秘密鍵をエクスポートするには、[これらの手順](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key)に従ってください - HTTP Alchemy API URLを取得し、クリップボードにコピーするには、以下を参照してください。 -![Alchemy API URLをコピーする](./copy-alchemy-api-url.gif) +![Alchemy API URLをコピー](./copy-alchemy-api-url.gif) -`.env`ファイルは次のようになります。 +これで、`.env`は次のようになります: + ``` API_URL="https://eth-sepolia.g.alchemy.com/v2/your-api-key" PRIVATE_KEY="your-metamask-private-key" + ``` これらの変数を実際にコードに接続するために、ステップ13で hardhat.config.jsファイル内のこれらの変数を参照します。 @@ -243,21 +259,23 @@ ERC-721コンストラクタでは、「MyNFT」と「NFT」の2つの文字列 ## ステップ12: Ethers.jsをインストールする {#install-ethers} -Ethers.jsは、よりユーザーフレンドリーなメソッドで[標準のJSON-RPCメソッド](/developers/docs/apis/json-rpc/)をラップすることにより、イーサリアムとの対話やリクエストを簡単にするライブラリです。 +Ethers.jsは、[標準のJSON-RPCメソッド](/developers/docs/apis/json-rpc/)をよりユーザーフレンドリーなメソッドでラップすることで、イーサリアムとの対話やリクエストを容易にするライブラリです。 -Hardhatは、追加のツールと拡張機能のための[プラグイン](https://hardhat.org/plugins/)の統合を非常に簡単にしてくれます。 コントラクトのデプロイメントに[Ethersプラグイン](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers)を利用します([Ethers.js](https://github.com/ethers-io/ethers.js/)には、複数の非常にクリーンなコントラクトのデプロイメント方法があります)。 +Hardhatでは、追加のツールや拡張機能のための[プラグイン](https://hardhat.org/plugins/)を非常に簡単に統合できます。 コントラクトのデプロイには[Ethersプラグイン](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers)を活用します([Ethers.js](https://github.com/ethers-io/ethers.js/)には非常にクリーンなコントラクトデプロイメントメソッドがあります)。 プロジェクトのホームディレクトリで以下を実行します。 + ``` npm install --save-dev @nomiclabs/hardhat-ethers ethers@^5.0.0 + ``` -次のステップでは、 hardhat.config.js でもイーサリアムが必要になります。 +次のステップのhardhat.config.jsでもEthers(.js)が必要になります。 -## ステップ13: hardhat.config.jsをアップデートする {#update-hardhat-config} +## ステップ13: hardhat.config.jsを更新する {#update-hardhat-config} -これまでにいくつかの依存関係とプラグインを追加しました。プロジェクトがそれらすべてを知るように、 hardhat.config.js を更新する必要があります。 +ここまでで、いくつかの依存関係とプラグインを追加しました。次に、プロジェクトがそれらすべてを認識できるように、hardhat.config.jsをアップデートする必要があります。 -「hardhat.config.js」を以下のように更新してください: +hardhat.config.jsを以下のようにアップデートします。 ```js /** @@ -281,28 +299,30 @@ Hardhatは、追加のツールと拡張機能のための[プラグイン](http ## ステップ14: コントラクトをコンパイルする {#compile-contract} -ここまででしっかりと動作していることを確認するため、コントラクトをコンパイルしてみましょう。 コンパイルは、Hardhat の組み込まれた機能の1つです。 +ここまでの作業がうまくいっていることを確認するために、コントラクトをコンパイルしてみましょう。 コンパイルは、組み込みのHardhatタスクの1つです。 コマンドラインで以下を実行します。 + ``` npx hardhat compile + ``` -SPDX license identifier not provided in source file という警告が表示されるかもしれません。しかし、それについて心配する必要はありません — うまくいけば、他のすべてが良く見えるでしょう！ 表示された場合は、いつでも[Alchemy discord](https://discord.gg/u72VCg3)でメッセージを送信できます。 +SPDXライセンス識別子がソースファイルで提供されていないという警告が表示される場合がありますが、心配する必要はありません。警告が表示されないのがベストですが、 うまくいかない場合は、いつでも[Alchemy Discord](https://discord.gg/u72VCg3)でメッセージを送ることができます。 -## ステップ15: デプロイスクリプトを書く {#write-deploy} +## ステップ15: デプロイスクリプトを作成する {#write-deploy} コントラクトの作成と設定ファイルの作成が完了したら、いよいよコントラクトのデプロイのためのスクリプトを作成します。 -`scripts/` フォルダに移動し、 `deploy.js` という名前の新しいファイルを作成し、以下の内容を追加します: +`scripts/`フォルダに移動して`deploy.js`という名前の新しいファイルを作成し、以下の内容を追加します: ```js async function main() { const MyNFT = await ethers.getContractFactory("MyNFT") - // Start deployment, returning a promise that resolves to a contract object + // デプロイを開始し、コントラクトオブジェクトに解決されるプロミスを返す const myNFT = await MyNFT.deploy() await myNFT.deployed() - console.log("Contract deployed to address:", myNFT.address) + console.log("コントラクトがデプロイされたアドレス:", myNFT.address) } main() @@ -313,40 +333,48 @@ main() }) ``` -Hardhatがコードの各行で行っている驚くべき内容については、Hardhatの[コントラクトチュートリアル](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)で説明されています。以下では、その説明を採用しています。 +Hardhatは、[コントラクトのチュートリアル](https://hardhat.org/tutorial/testing-contracts.html#writing-tests)で、これらのコードの各行が何をするかを非常にうまく説明しています。ここではその説明を採用しました。 + ``` const MyNFT = await ethers.getContractFactory("MyNFT"); + ``` -ethers.js の中の ContractFactory は新しいスマートコントラクトを作成するための抽象化です。ここでの MyNFT は NFT コントラクトのインスタンスのためのファクトリです。 hardhat-ethers プラグインを使用する場合、 ContractFactory および Contract インスタンスはデフォルトで最初の署名者に接続されます。 +ethers.jsのContractFactoryは新しいスマートコントラクトをデプロイするための抽象化であり、ここでのMyNFTはNFTコントラクトのインスタンスのためのファクトリです。 hardhat-ethersプラグインを使用する場合、 ContractFactoryおよびContractインスタンスはデフォルトで最初の署名者に接続されます。 + ``` const myNFT = await MyNFT.deploy(); + ``` -ContractFactory の deploy() を呼び出すとデプロイメントが開始し、 Contract を解決するための Promise が返されます。 これは、スマートコントラクトの各関数に対するメソッドを持つオブジェクトです。 +ContractFactoryのdeploy()を呼び出すとデプロイメントが開始し、 Contractを解決するためのPromiseが返されます。 これは、スマートコントラクトの各関数に対するメソッドを持つオブジェクトです。 ## ステップ16: コントラクトをデプロイする {#deploy-contract} -ようやく、スマートコントラクトをデプロイする準備が整いました。 プロジェクトディレクトリのルートに戻り、コマンドラインで以下を実行します: +ようやく、スマートコントラクトをデプロイする準備が整いました。 プロジェクトディレクトリのルートに戻り、コマンドラインで以下を実行します。 + ``` npx hardhat --network sepolia run scripts/deploy.js + ``` 次のような画面が表示されるはずです。 + ``` Contract deployed to address: 0x4C5266cCc4b3F426965d2f51b6D910325a0E7650 + ``` -[Sepolia etherscan](https://sepolia.etherscan.io/)に移動し、コントラクトアドレスを検索すると、正常にデプロイされたことが確認できるはずです。 すぐに見られない場合は、しばらくお待ちください。 トランザクションは以下のようなものになります。 +[Sepolia etherscan](https://sepolia.etherscan.io/)にアクセスし、コントラクトアドレスを検索すると、正常にデプロイされたことを確認できるはずです。 すぐに表示されない場合は、しばらくお待ちください。 トランザクションは以下のようなものになります。 -![Etherscan でトランザクションアドレスを表示する](./etherscan-sepoila-contract-creation.png) +![Etherscanでトランザクションアドレスを表示](./etherscan-sepoila-contract-creation.png) -From アドレスは MetaMask アカウントアドレスと一致し、To アドレスは「Contract Creation」となります。 トランザクション内容をクリックすると、To フィールドにコントラクトアドレスが表示されます: +FromアドレスはあなたのMetaMaskアカウントのアドレスと一致し、Toアドレスには「Contract Creation」と表示されます。 このトランザクションをクリックすると、Toフィールドにコントラクトアドレスが表示されます。 -![Etherscanでコントラクトアドレスを表示する](./etherscan-sepolia-tx-details.png) +![Etherscanでコントラクトアドレスを表示](./etherscan-sepolia-tx-details.png) -Yassss！ イーサリアム(テストネット)チェーンにNFTスマートコントラクトをデプロイできました。 +おめでとうございます。 イーサリアム(テストネット)チェーンにNFTスマートコントラクトをデプロイできました。 -内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemy のアプリが複数ある場合は、必ずアプリでフィルタリングし、「MyNFT」を選択してください。 +内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemyのアプリが複数ある場合は、必ずアプリでフィルタリングして、「MyNFT」を選択してください。 -![Alchemy のエクスプローラーダッシュボードで「内部」で行われた通話を表示する](./alchemy-explorer-goerli.png) +![AlchemyのExplorerダッシュボードで「内部」で行われた呼び出しを表示](./alchemy-explorer-goerli.png) -ここでは、 .deploy() 関数を呼び出した際に、Hardhat/Ethers が内部で作った JSON-RPC の呼び出しをいくつか見ることができます。 ここで呼び出している2つの重要なJSON-RPCは、実際にSepoliaチェーン上でコントラクトを書き込むリクエストの[eth_sendRawTransaction](/developers/docs/apis/json-rpc/#eth_sendrawtransaction)と、(トランザクションを送信する際の典型的なパターンである) ハッシュを与えられたトランザクションに関する情報を読み取るリクエスト[eth_getTransactionByHash](/developers/docs/apis/json-rpc/#eth_gettransactionbyhash)です。 トランザクションの送信の詳細については、このチュートリアルの [Web3 を使用したトランザクションの送信](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) をご覧ください。 +ここでは、Hardhat/Ethersが.deploy()関数を呼び出した際に、内部で行ったJSON-RPCの呼び出しを見ることができます。 ここで特筆すべき重要な2つのリクエストは、実際にSepoliaチェーンにスマートコントラクトを書き込むためのリクエストである[eth_sendRawTransaction](/developers/docs/apis/json-rpc/#eth_sendrawtransaction)と、ハッシュが与えられたトランザクションに関する情報を読み取るためのリクエスト (トランザクション送信時の典型的なパターン) である[eth_getTransactionByHash](/developers/docs/apis/json-rpc/#eth_gettransactionbyhash)です。 トランザクションの送信についてさらに詳しく知るには、[Web3を使用したトランザクション送信](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)に関するこのチュートリアルをご覧ください。 -以上がこのチュートリアルのパート1です。 [パート2](/developers/tutorials/how-to-mint-an-nft/) では、NFT を発行することで実際にスマートコントラクトとやりとりをします。そして、[パート3](/developers/tutorials/how-to-view-nft-in-metamask/) では、Etherreum ウォレット内の NFT を確認する方法を示します！ +チュートリアルのパート1は以上です。 [パート2では、NFTをミントしてスマートコントラクトと実際にやり取りし](/developers/tutorials/how-to-mint-an-nft/)、[パート3ではイーサリアムウォレットでNFTを表示する方法](/developers/tutorials/how-to-view-nft-in-metamask/)をご紹介します！ diff --git a/public/content/translations/ja/developers/tutorials/interact-with-other-contracts-from-solidity/index.md b/public/content/translations/ja/developers/tutorials/interact-with-other-contracts-from-solidity/index.md index de8baa117fa..5c95191a15c 100644 --- a/public/content/translations/ja/developers/tutorials/interact-with-other-contracts-from-solidity/index.md +++ b/public/content/translations/ja/developers/tutorials/interact-with-other-contracts-from-solidity/index.md @@ -1,13 +1,8 @@ --- -title: Solidityを使用した他のコントラクトの活用 -description: 既存のコントラクトからスマートコントラクトをデプロイし、それを活用する方法 +title: "Solidityから他のコントラクトとやり取りする" +description: "既存のコントラクトからスマートコントラクトをデプロイし、それとやり取りする方法" author: "jdourlens" -tags: - - "スマートコントラクト" - - "Solidity" - - "Remix" - - "デプロイ" - - "構成可能性" +tags: [ "スマートコントラクト", "Solidity", "Remix", "デプロイ", "構成可能性" ] skill: advanced lang: ja published: 2020-04-05 @@ -16,9 +11,9 @@ sourceUrl: https://ethereumdev.io/interact-with-other-contracts-from-solidity/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -これまでのチュートリアルでは、[最初のスマートコントラクトをデプロイする方法](/developers/tutorials/deploying-your-first-smart-contract/)と、[修飾子によるアクセス制御](https://ethereumdev.io/organize-your-code-and-control-access-to-your-smart-contract-with-modifiers/)や[Solidityでのエラー処理](https://ethereumdev.io/handle-errors-in-solidity-with-require-and-revert/)といったいくつかの機能を追加する方法について学びました。 このチュートリアルでは、既存のコントラクトからスマートコントラクトをデプロイし、それを活用する方法について説明します。 +これまでのチュートリアルでは、[最初のスマートコントラクトのデプロイ方法](/developers/tutorials/deploying-your-first-smart-contract/)や、[修飾子(modifier)を使ったアクセス制御](https://ethereumdev.io/organize-your-code-and-control-access-to-your-smart-contract-with-modifiers/)、[Solidityでのエラー処理](https://ethereumdev.io/handle-errors-in-solidity-with-require-and-revert/)といった機能の追加など、多くのことを学びました。 このチュートリアルでは、既存のコントラクトからスマートコントラクトをデプロイし、それとやり取りする方法を学びます。 -ここでは、`CounterFactory`という名前のファクトリーを作成することで、誰でも自分の`Counter`スマートコントラクトを所有できるようにするコントラクトを作成します。 初めに、これが`Counter`スマートコントラクトの初期コードです。 +ここでは、`CounterFactory`という名前のファクトリーを作成することで、誰もが自分自身の`Counter`スマートコントラクトを持てるようにするコントラクトを作成します。 まず、これが最初の`Counter`スマートコントラクトのコードです。 ```solidity pragma solidity 0.5.17; @@ -31,12 +26,12 @@ contract Counter { modifier onlyOwner(address caller) { - require(caller == _owner, "You're not the owner of the contract"); + require(caller == _owner, "あなたはこのコントラクトの所有者ではありません"); _; } modifier onlyFactory() { - require(msg.sender == _factory, "You need to use the factory"); + require(msg.sender == _factory, "ファクトリーを使用する必要があります"); _; } @@ -56,19 +51,19 @@ contract Counter { } ``` -ファクトリーのアドレスとコントラクト所有者のアドレスを追跡するために、コントラクトコードを少し変更していることに注意してください。 他のコントラクトからコントラクトコードを呼び出した場合、msg.senderはコントラクトファクトリーのアドレスを参照します。 コントラクトを使用して他のコントラクトとやり取りすることはよくあることなので、これは**理解しておくべき非常に重要なポイント**です。 したがって、複雑なケースでは誰が送信者なのかに注意を払う必要があります。 +ファクトリーのアドレスとコントラクト所有者のアドレスを追跡するために、コントラクトコードを少し変更したことに注意してください。 他のコントラクトからコントラクトコードを呼び出すと、`msg.sender`は私たちのコントラクトファクトリーのアドレスを参照します。 コントラクトを使って他のコントラクトとやり取りするのは一般的な方法であるため、これは**理解しておくべき、本当に重要な点**です。 したがって、複雑なケースでは誰が送信者(`sender`)なのかに注意する必要があります。 -このために、`onlyFactory`という修飾子も追加しました。この修飾子は、元の呼び出し元をパラメータとして渡すファクトリーのみが、状態変更関数を呼び出せるようにします。 +このため、元の呼び出し元をパラメータとして渡すファクトリーによってのみ状態変更関数が呼び出されるように、`onlyFactory`修飾子も追加しました。 -他のすべてのカウンターを管理する新しい`CounterFactory`内で、所有者をカウンターコントラクトのアドレスに関連付けるマッピングを追加します。 +他のすべての`Counter`を管理する新しい`CounterFactory`の中に、所有者とそのカウンターコントラクトのアドレスを関連付けるマッピングを追加します。 ```solidity mapping(address => Counter) _counters; ``` -イーサリアムでは、マッピングはJavaScriptのオブジェクトに相当します。これは、型Aのキーを型Bの値にマッピングできます。ここでは、所有者のアドレスをそのカウンターのインスタンスにマッピングしています。 +イーサリアムでは、マッピングはJavaScriptのオブジェクトに相当し、型Aのキーを型Bの値にマッピングできます。このケースでは、所有者のアドレスをその`Counter`のインスタンスにマッピングします。 -ユーザーのために新しいカウンターをインスタンス化する場合は、次のようになります。 +誰かのために新しい`Counter`をインスタンス化するには、次のようになります。 ```solidity function createCounter() public { @@ -77,9 +72,9 @@ mapping(address => Counter) _counters; } ``` -まず、そのユーザーがすでにカウンターを所有しているかどうかを確認します。 もしカウンターを所有していなければ(カウンターの数が0ならば)、そのアドレスを`Counter`コンストラクタに渡して新しいカウンターをインスタンス化し、新しく作成したインスタンスをマッピングに割り当てます。 +まず、その人がすでにカウンターを所有しているかどうかをチェックします。 その人がカウンターを所有していない場合、その人のアドレスを`Counter`のコンストラクタに渡して新しいカウンターをインスタンス化し、新しく作成されたインスタンスをマッピングに割り当てます。 -特定のカウンターの数を取得する場合は、次のようになります。 +特定の`Counter`のカウント数を取得するには、次のようになります。 ```solidity function getCount(address account) public view returns (uint256) { @@ -92,9 +87,9 @@ function getMyCount() public view returns (uint256) { } ``` -最初の関数は、指定されたアドレスにCounterコントラクトが存在するかどうかをチェックし、存在する場合にインスタンスから`getCount`メソッドを呼び出します。 2番目の関数`getMyCount`は、msg.senderを直接`getCount`関数に渡す短い関数です。 +最初の関数は、指定されたアドレスに対して`Counter`コントラクトが存在するかどうかをチェックし、その後インスタンスから`getCount`メソッドを呼び出します。 2番目の関数`getMyCount`は、`msg.sender`を直接`getCount`関数に渡すための、ただのショートカットです。 -`increment`関数もかなり類似していますが、`Counter`コントラクトに元のトランザクション送信者を渡します。 +`increment`関数も非常によく似ていますが、元のトランザクションの送信者(`sender`)を`Counter`コントラクトに渡します。 ```solidity function increment() public { @@ -103,11 +98,11 @@ function increment() public { } ``` -この関数を何度も呼び出すと、カウンターがオーバーフローする可能性がありますので注意してください。 オーバーフローが発生しないように、できる限り[SafeMathライブラリ](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/)を使用してください。 +何度も呼び出されると、カウンターがオーバーフローを起こす可能性があることに注意してください。 この可能性から保護するために、[SafeMathライブラリ](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/)をできるだけ使用すべきです。 -このコントラクトをデプロイするためには、`CounterFactory`と`Counter`の両方のコードが必要です。 例えばRemixでデプロイする場合、CounterFactoryを選択する必要があります。 +このコントラクトをデプロイするには、`CounterFactory`と`Counter`の両方のコードを提供する必要があります。 例えばRemixでデプロイする場合、`CounterFactory`を選択する必要があります。 -これが完成したコードです。 +こちらが全コードです。 ```solidity pragma solidity 0.5.17; @@ -120,12 +115,12 @@ contract Counter { modifier onlyOwner(address caller) { - require(caller == _owner, "You're not the owner of the contract"); + require(caller == _owner, "あなたはこのコントラクトの所有者ではありません"); _; } modifier onlyFactory() { - require(msg.sender == _factory, "You need to use the factory"); + require(msg.sender == _factory, "ファクトリーを使用する必要があります"); _; } @@ -172,6 +167,6 @@ contract CounterFactory { コンパイル後、Remixのデプロイセクションで、デプロイするファクトリーを選択します。 -![Remixにデプロイするファクトリーの選択](./counterfactory-deploy.png) +![Remixでデプロイするファクトリーの選択](./counterfactory-deploy.png) -コントラクトファクトリーを使うと、値の変化を確認できます。 もし、別のアドレスからスマートコントラクトを呼び出したい場合は、Remixのアカウントの選択で別のアドレスに変更する必要があります。 +その後、コントラクトファクトリーを操作して、値が変化することを確認できます。 もし、異なるアドレスからスマートコントラクトを呼び出したい場合は、Remixのアカウント選択でアドレスを変更する必要があります。 diff --git a/public/content/translations/ja/developers/tutorials/ipfs-decentralized-ui/index.md b/public/content/translations/ja/developers/tutorials/ipfs-decentralized-ui/index.md new file mode 100644 index 00000000000..720e7681bad --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/ipfs-decentralized-ui/index.md @@ -0,0 +1,73 @@ +--- +title: "IPFSを利用した分散型ユーザーインターフェース" +description: "このチュートリアルでは、dappのユーザーインターフェースを保存するためにIPFSを使用する方法を学びます。 アプリケーションのデータとビジネスロジックは分散化されていますが、検閲耐性のあるユーザーインターフェースがなければ、ユーザーはいずれにせよそれにアクセスできなくなる可能性があります。" +author: Ori Pomerantz +tags: [ "ipfs" ] +skill: beginner +lang: ja +published: 2024-06-29 +--- + +あなたは素晴らしい新しいdappを作成しました。 そのための[ユーザーインターフェース](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)も作成しました。 しかし、あなたのユーザーインターフェースはクラウド上の1つのサーバーにすぎず、誰かがそれを停止させて検閲しようとすることを恐れています。 このチュートリアルでは、ユーザーインターフェースを**[Interplanetary File System (IPFS)](https://ipfs.tech/developers/)**上に置くことで検閲を回避する方法を学びます。そうすれば、関心のある誰もが将来のアクセスのためにサーバーにそれをピン留めできるようになります。 + +[Fleek](https://resources.fleek.xyz/docs/)などのサードパーティサービスを使用して、すべての作業を行うこともできます。 このチュートリアルは、たとえ作業量が増えても、自分たちが何をしているのかを十分に理解したい人向けです。 + +## ローカルでの開始 {#getting-started-locally} + +複数の[サードパーティIPFSプロバイダー](https://docs.ipfs.tech/how-to/work-with-pinning-services/#use-a-third-party-pinning-service)がありますが、テストのためにローカルでIPFSを実行することから始めるのが最善です。 + +1. [IPFSユーザーインターフェース](https://docs.ipfs.tech/install/ipfs-desktop/#install-instructions)をインストールします。 + +2. Webサイトのディレクトリを作成します。 [Vite](https://vite.dev/)を使用している場合は、次のコマンドを使用します。 + + ```sh + pnpm vite build + ``` + +3. IPFS Desktopで、**[インポート] > [フォルダー]** をクリックし、前の手順で作成したディレクトリを選択します。 + +4. アップロードしたばかりのフォルダを選択し、**[名前の変更]** をクリックします。 より意味のある名前を付けます。 + +5. もう一度選択し、**[リンクを共有]** をクリックします。 URLをクリップボードにコピーします。 `https://ipfs.io/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ` のようなリンクになります。 + +6. **[ステータス]** をクリックします。 **[詳細設定]** タブを展開してゲートウェイアドレスを表示します。 例えば、私のシステムではアドレスは `http://127.0.0.1:8080` です。 + +7. リンク手順のパスとゲートウェイアドレスを組み合わせて、あなたのアドレスを見つけます。 例えば、上記の例では、URLは `http://127.0.0.1:8080/ipfs/QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ` です。 そのURLをブラウザで開いて、あなたのサイトを表示します。 + +## アップロード {#uploading} + +これでIPFSを使ってローカルでファイルを提供できるようになりましたが、これはあまりエキサイティングなことではありません。 次のステップは、あなたがオフラインのときに世界中から利用できるようにすることです。 + +よく知られている[ピニングサービス](https://docs.ipfs.tech/concepts/persistence/#pinning-services)がいくつかあります。 そのうちの1つを選びます。 どのサービスを使用するにしても、アカウントを作成し、IPFSデスクトップの**コンテンツ識別子 (CID)** を提供する必要があります。 + +個人的には、[4EVERLAND](https://docs.4everland.org/storage/4ever-pin/guides) が最も使いやすいと思いました。 その手順は次のとおりです。 + +1. [ダッシュボード](https://dashboard.4everland.org/overview)にアクセスし、ウォレットでログインします。 + +2. 左のサイドバーで **[ストレージ] > [4EVER Pin]** をクリックします。 + +3. **[アップロード] > [Selected CID]** をクリックします。 コンテンツに名前を付け、IPFSデスクトップからCIDを提供します。 現在、CIDは`Qm`で始まり、`QmaCuQ7yN6iyBjLmLGe8YiFuCwnePoKfVu6ue8vLBsLJQJ`のように[base-58でエンコード](https://medium.com/bootdotdev/base64-vs-base58-encoding-c25553ff4524)されたハッシュを表す44文字の英数字が続く文字列ですが、[これは変更される可能性](https://docs.ipfs.tech/concepts/content-addressing/#version-1-v1)があります。 + +4. 初期ステータスは**Queued**です。 **Pinned**に変わるまでリロードします。 + +5. CIDをクリックしてリンクを取得します。 私のアプリケーションは[こちら](https://bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im/)でご覧いただけます。 + +6. 1か月以上ピン留めするには、アカウントを有効化する必要があるかもしれません。 アカウントの有効化には約1ドルかかります。 閉じてしまった場合は、ログアウトしてから再度ログインすると、再び有効化を求められます。 + +## IPFSからの使用 {#using-from-ipfs} + +この時点で、あなたはIPFSコンテンツを提供する中央集権型のゲートウェイへのリンクを持っています。 要するに、あなたのユーザーインターフェースは少し安全になったかもしれませんが、まだ検閲耐性はありません。 真の検閲耐性を得るには、ユーザーはIPFSを[ブラウザから直接](https://docs.ipfs.tech/install/ipfs-companion/#prerequisites)使用する必要があります。 + +それがインストールされ(そしてデスクトップIPFSが動作していれば)、任意のサイトで[/ipfs/``](https://any.site/ipfs/bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im)にアクセスすると、そのコンテンツが分散型の方法で提供されます。 + +## 欠点 {#drawbacks} + +IPFSファイルを確実に削除することはできないため、ユーザーインターフェースを変更している間は、中央集権型のままにするか、IPFS上で可変性を提供するシステムである[Interplanetary Name System (IPNS)](https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs)を使用するのがおそらく最善です。 もちろん、可変なものは検閲される可能性があります。IPNSの場合は、それに対応する秘密鍵を持つ人物に圧力をかけることで検閲されます。 + +さらに、一部のパッケージはIPFSとの間に問題を抱えているため、あなたのWebサイトが非常に複雑な場合、これは良い解決策ではないかもしれません。 そしてもちろん、サーバーとの統合に依存するものは、クライアントサイドをIPFSに置くだけでは分散化できません。 + +## 結論 {#conclusion} + +イーサリアムがdappのデータベースとビジネスロジックの側面を分散化できるように、IPFSはユーザーインターフェースを分散化できるようにします。 これにより、あなたのdappに対するもう一つの攻撃ベクトルを遮断できます。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md b/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md index 416e46b50bc..ed7ec7e198a 100644 --- a/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md +++ b/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md @@ -1,17 +1,15 @@ --- -title: create-eth-appでDappのフロントエンド開発をはじめましょう -description: create-eth-appの使い方と機能の概要 +title: "create-eth-appでdappのフロントエンド開発を始めましょう" +description: "create-eth-appの使い方と機能の概要" author: "Markus Waas" tags: - - "create-eth-app" - - "フロントエンド" - - "JavaScript" - - "ethers.js" - - "The Graph" - - "Aave" - - "Compound" - - "Uniswap" - - "Sablier" + [ + "フロントエンド", + "JavaScript", + "ethers.js", + "the graph", + "DeFi" + ] skill: beginner lang: ja published: 2020-04-27 @@ -19,11 +17,11 @@ source: soliditydeveloper.com sourceUrl: https://soliditydeveloper.com/create-eth-app --- -[create-eth-app](https://github.com/PaulRBerg/create-eth-app)については、前回の記事（[Solidity の全体像](https://soliditydeveloper.com/solidity-overview-2020)）で紹介しました。 今回は、create-eth-app をどのように使うか、どのような機能が統合されているか、およびさらに拡張する方法について学びます。 create-eth-app は、[ Sablier ](http://sablier.com/)の創業者である Paul Razvan Berg が立ち上げたプロジェクトで、フロントエンド開発をすばやく開始できるだけでなく、さまざまなオプションの統合機能も活用できます。 +前回は[Solidityの全体像](https://soliditydeveloper.com/solidity-overview-2020)を確認し、すでに[create-eth-app](https://github.com/PaulRBerg/create-eth-app)についても言及しました。 今回は、その使い方、統合されている機能、そしてそれを拡張するための追加のアイデアについて解説します。 [Sablier](http://sablier.com/)の創業者であるPaul Razvan Bergによって始められたこのアプリは、フロントエンド開発をすぐに開始でき、いくつかのオプションの統合機能から選択することができます。 ## インストール {#installation} -インストールには、Yarn 0.25 以上が必要です（`npm install yarn --global`）。 とても簡単です！ +インストールには、Yarn 0.25以上が必要です (`npm install yarn --global`)。 次のように実行するだけで簡単です: ```bash yarn create eth-app my-eth-app @@ -31,44 +29,44 @@ cd my-eth-app yarn react-app:start ``` -このアプリでは、 [create-react-app](https://github.com/facebook/create-react-app)を利用しています。 アプリを表示するには、ブラウザで `http://localhost:3000/` を開きます。 本番環境にデプロイする準備ができたら、yarn build を実行してソースコードをまとめたファイルを作成します。 このアプリを手軽にホスティングするには、 [Netlify](https://www.netlify.com/)を利用すると良いでしょう。 GitHub リポジトリを作成して Netlify に登録し、ビルドコマンドをセットアップすれば完了です！ あなたのアプリはインターネットに公開され、誰でも利用できるようになります。 これらはすべて無料です。 +内部で[create-react-app](https://github.com/facebook/create-react-app)を使用しています。 アプリを表示するには、`http://localhost:3000/`を開きます。 本番環境にデプロイする準備ができたら、`yarn build`で最小化されたバンドルを作成します。 これを簡単にホストする方法の一つとして、[Netlify](https://www.netlify.com/)があります。 GitHubリポジトリを作成し、それをNetlifyに追加し、ビルドコマンドをセットアップすれば完了です！ あなたのアプリはホストされ、誰でも利用できるようになります。 そして、そのすべてが無料です。 ## 機能 {#features} -### React と create-react-app {#react--create-react-app} +### Reactとcreate-react-app {#react--create-react-app} -まずは、このアプリの核心である React と、*create-react-app*で提供される追加の機能すべてについて説明します。 イーサリアムとの統合を希望しない場合は、このアプリだけを使うのも良い方法です。 [React](https://reactjs.org/)を使えば、インタラクティブな UI を簡単に作成できます。 React は、[Vue](https://vuejs.org/)ほど初心者向けではありませんが、広く使われており、より多くの機能が提供されているだけでなく、何千ものライブラリを利用して機能を追加できます。 *create-react-app*も UI 開発を手軽に開始するのに役立つアプリで、以下の機能が含まれています。 +まず、このアプリの心臓部であるReactと、_create-react-app_に付属するすべての追加機能です。 Ethereumとの統合を望まない場合は、これだけを使用するのも良い選択肢です。 [React](https://react.dev/)を使えば、インタラクティブなUIをとても簡単に構築できます。 [Vue](https://vuejs.org/)ほど初心者向けではないかもしれませんが、依然として広く使われており、より多くの機能を持ち、そして最も重要なことに、何千もの追加のライブラリから選択することができます。 _create-react-app_を使えば、非常に簡単に始めることができ、次のものが含まれています： -- React、JSX、ES6、TypeScript、および Flow の構文に対応 -- スプレッド構文などの ES6 に含まれない言語拡張 -- オートプレフィックス CSS により、-webkit- などの接頭辞が不必要 -- カバレッジレポート機能を搭載した、高速でインタラクティブな単体テストランナー -- よくある間違いをリアルタイムで警告する開発環境用サーバ -- 本番環境用に、JS、CSS、および画像ファイルをハッシュやソースマップとバンドルできるビルドスクリプト +- React、JSX、ES6、TypeScript、Flow構文のサポート。 +- オブジェクトスプレッド演算子のようなES6を超える言語拡張。 +- 自動で接頭辞が付加されるCSS。-webkit-やその他の接頭辞は不要です。 +- カバレッジレポート機能を搭載した、高速でインタラクティブな単体テストランナー。 +- よくある間違いについて警告するライブ開発サーバー。 +- ハッシュとソースマップを使用して、本番用にJS、CSS、画像をバンドルするビルドスクリプト。 -特に*create-eth-app* は、新しい[副作用フック](https://reactjs.org/docs/hooks-effect.html)を利用しています。 これは、強力かつとてもコンパクトな、いわゆる関数コンポーネントを書くための方法です。 副作用フックを*create-eth-app*で活用する方法については、以下の Apollo に関するセクションを参照してください。 +特に_create-eth-app_は、新しい[副作用フック](https://legacy.reactjs.org/docs/hooks-effect.html)を利用しています。 強力でありながら非常に小さい、いわゆる関数コンポーネントを記述するためのメソッドです。 副作用フックをcreate-eth-appで活用する方法については、以下のApolloに関するセクションを参照してください。 ### Yarn Workspaces {#yarn-workspaces} -[Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/)では、複数のパッケージをひとつのルートフォルダで管理することができ、`yarn install`を使って依存関係を一度にインストールすることができます。 このアプローチは、スマートコントラクトのアドレスや ABI 管理（スマートコントラクトをどこにデプロイしたか、スマートコントラクトとどのようなやり取りを行うか）などの小さなパッケージを追加したり、The Graph との統合において特に有益であり、どちらの機能も`create-eth-app`に含まれています。 +[Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/)では、複数のパッケージをひとつのルートフォルダで管理することができ、`yarn install`を使って依存関係を一度にインストールすることができます。 このアプローチは、スマートコントラクトのアドレスやABI管理（スマートコントラクトをどこにデプロイしたか、スマートコントラクトとどのようなやり取りを行うか）などの小さなパッケージを追加したり、The Graphとの統合において特に有益であり、どちらの機能もcreate-eth-appに含まれています。 ### ethers.js {#ethersjs} -大部分のユーザーは現在でも[Web3.js](https://docs.web3js.org/)を使用していますが、昨年は[ethers.js](https://docs.ethers.io/)を Web3.js の代替として利用するユーザーが増加したため、*create-eth-app*には ethers.js が統合されています。 このライブラリで作業してもよいですし、Web3 に切り替えてもよいです。あるいは、もうすくベータが外れる[ethers.js v5](https://docs.ethers.org/v5/)にアップグレードするのもよいでしょう。 +[Web3](https://docs.web3js.org/)がまだ主流で使われていますが、[ethers.js](https://docs.ethers.io/)は昨年、代替として多くの注目を集めており、_create-eth-app_に統合されているものです。 これを使用するか、Web3に変更するか、またはベータ版がもうすぐ終了する[ethers.js v5](https://docs.ethers.org/v5/)へのアップグレードを検討することができます。 ### The Graph {#the-graph} -[GraphQL](https://graphql.org/)は、[RESTful API](https://restfulapi.net/)とは違う方法でデータを扱います。 特に分散型ブロックチェーンのデータを扱う場合、RESTful API よりもいくつかの利点があります。 その理由に興味がある方は、[GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a)をご覧ください。 +[GraphQL](https://graphql.org/)は、[Restful API](https://restfulapi.net/)と比較して、データを処理するための代替方法です。 特に分散型ブロックチェーンデータにとって、Restful APIよりもいくつかの利点があります。 この背後にある理由に興味がある場合は、[GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a)をご覧ください。 -通常、スマートコントラクトからは直接データを取得することができます。 最後に行った取引の時間を取得したい場合は、 `MyContract.methods.latestTradeTime().call()`を呼び出すだけで、infura のようなイーサリアムノードからデータを取得し、あなたの Dapp で使うことができます。 しかし、何百もの異なる種類のデータが必要な場合は事情が異なります。 ノードからのデータ取得が何百回も発生し、その都度[RTT](https://wikipedia.org/wiki/Round-trip_delay_time)が必要となるため、Dapp の処理速度が低下し、非効率になってしまいます。 ひとつの回避策としては、一度に複数のデータを返すデータ取得用の関数をスマートコントラクト側で用意する方法があるでしょう。 しかし、これは常に最善の方法とは言えません。 +通常、スマートコントラクトから直接データを取得します。 最新の取引の時刻を読み取りたいですか？ `MyContract.methods.latestTradeTime().call()`を呼び出すだけで、Ethereumノードからdappにデータを取得します。 しかし、何百もの異なるデータポイントが必要な場合はどうでしょうか？ そうなると、ノードへのデータフェッチが何百回も発生し、そのたびに[RTT](https://wikipedia.org/wiki/Round-trip_delay_time)が必要になり、dappが遅く非効率になります。 一つの回避策として、一度に複数のデータを返すフェッチャーコール関数をコントラクト内に設けることが考えられます。 しかし、これは必ずしも理想的ではありません。 -また、過去のデータが必要な場合もあるでしょう。 最後の取引の時間だけではなく、今まで自分が行った全ての取引の時間が知りたいかもしれません。 このような場合は、*create-eth-app*にある subgraph パッケージを活用できます。[ドキュメンテーション](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph)を参照して、あなたのニーズに合うように調整してください。 人気が高いスマートコントラクトの場合、すでに subgraph が含まれているかもしれません。 [subgraph explorer](https://thegraph.com/explorer/)をチェックしてみてください。 +そして、履歴データにも興味があるかもしれません。 最後の取引時間だけでなく、これまでに自分が行ったすべての取引の時間も知りたくなるでしょう。 _create-eth-app_のサブグラフパッケージを使用し、[ドキュメント](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph)を読んで、それを自分のコントラクトに適合させてください。 人気のあるスマートコントラクトを探している場合、すでにサブグラフが存在するかもしれません。 [サブグラフエクスプローラー](https://thegraph.com/explorer/)をチェックしてください。 -subgraph があれば、Dapp にシンプルなクエリをひとつ追加するだけで、過去のデータも含めた全てのブロックチェーンのデータを 1 回のフェッチ処理で取得することができます。 +サブグラフがあれば、dappで簡単なクエリを1つ書くだけで、必要な履歴データを含むすべての重要なブロックチェーンデータを取得でき、必要なフェッチは1回だけです。 ### Apollo {#apollo} -[Apollo Boost](https://www.apollographql.com/docs/react/get-started/)との統合により、React で作成した Dapp に The Graph を簡単に搭載できるようになりました。 特に[React hooks と Apollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks)を使えば、コンポーネントに GraphQL のクエリをひとつ追加するだけで、簡単にデータ取得が可能になります： +[Apollo Boost](https://www.apollographql.com/docs/react/get-started/)の統合のおかげで、React dappにグラフを簡単に統合できます。 特に[ReactフックとApollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks)を使用する場合、データのフェッチはコンポーネントに単一のGraphQlクエリを記述するのと同じくらい簡単です： ```js const { loading, error, data } = useQuery(myGraphQlQuery) @@ -82,32 +80,32 @@ React.useEffect(() => { ## テンプレート {#templates} -さらに、Dapp 用にさまざまなテンプレートが用意されています。 今のところ、Aave、Compound、UniSwap、および Sablier 用のテンプレートがあります。 これらのテンプレートはすべて、すでに subgraph と統合されており、スマートコントラクトのアドレスに対して重要なサービスを追加します。 `yarn create eth-app my-eth-app --with-template aave`などの作成コマンドを、テンプレートに追加するだけでよいです。 +さらに、いくつかの異なるテンプレートから選択できます。 これまでのところ、Aave、Compound、UniSwap、またはsablierの統合を使用できます。 それらはすべて、あらかじめ作成されたサブグラフ統合とともに、重要なサービススマートコントラクトのアドレスを追加します。 `yarn create eth-app my-eth-app --with-template aave`のように、作成コマンドにテンプレートを追加するだけです。 ### Aave {#aave} -[Aave](https://aave.com/)は、分散型の通貨レンディングプラットフォームです。 預金者は、市場に流動性を提供することで金利収入を獲得でき、借主は担保を提供して借り入れることができます。 Aave のユニークな特徴のひとつは、1 回のトランザクション内で返済する限り無担保で通貨を借入できる[フラッシュローン](https://docs.aave.com/developers/guides/flash-loans)という仕組みです。 この機能は、裁定取引で余分のキャッシュが必要になる場合などに有効でしょう。 +[Aave](https://aave.com/)は、分散型の金融市場です。 預金者は市場に流動性を提供して受動的収入を得る一方、借手は担保を使って借り入れることができます。 Aaveのユニークな特徴の1つは、[フラッシュローン](https://aave.com/docs/developers/flash-loans)です。これは、1つのトランザクション内でローンを返済する限り、担保なしでお金を借りることを可能にします。 これは、例えば裁定取引で追加の現金を得るのに役立ちます。 -利子が付与される取引中のトークンは、*aToken*と呼ばれます。 +利子を得るために取引されるトークンは、_aTokens_と呼ばれます。 -Aave と*create-eth-app*を統合すると、[Aave 用の subgraph](https://docs.aave.com/developers/getting-started/using-graphql)が使えるようになります。 Aave は The Graph を採用しており、[Ropsten](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten)および[メインネット](https://thegraph.com/explorer/subgraph/aave/protocol)上では、すぐに導入できる subgraph を[raw](https://thegraph.com/explorer/subgraph/aave/protocol-raw)または[formatted](https://thegraph.com/explorer/subgraph/aave/protocol)形式で提供しています。 +_create-eth-app_とAaveを統合することを選択すると、[サブグラフ統合](https://docs.aave.com/developers/getting-started/using-graphql)が得られます。 AaveはThe Graphを使用しており、[Ropsten](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten)と[メインネット](https://thegraph.com/explorer/subgraph/aave/protocol)上で、[raw](https://thegraph.com/explorer/subgraph/aave/protocol-raw)または[フォーマット済み](https://thegraph.com/explorer/subgraph/aave/protocol)形式で、すぐに使えるいくつかのサブグラフをすでに提供しています。 -![Aaveフラッシュローンのミーム - 「あ〜、フラッシュローンを1トランザクション以上に延長できれば、最高なんだけどなあ」](./flashloan-meme.png) +![Aaveフラッシュローンのミーム – 「ああ、もしフラッシュローンを1トランザクション以上保持できたら、最高なんだけどな」](./flashloan-meme.png) ### Compound {#compound} -[Compound](https://compound.finance/)は、Aave に類似したサービスです。 create-eth-app ではすでに、[Compound v2 の subgraph](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195)が利用可能です。 驚くべきことに、Compound では利子が付与されるトークンを*cToken*と呼んでいます。 +[Compound](https://compound.finance/)はAaveに似ています。 この統合には、新しい[Compound v2 Subgraph](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195)がすでに含まれています。 ここでの利息獲得トークンは、驚くべきことに_cTokens_と呼ばれています。 ### Uniswap {#uniswap} -[Uniswap](https://uniswap.exchange/)は、分散型取引所 (DEX) です。 流動性を供給するユーザーは、取引の売主／買主の両方に対して、必要なトークンや ether を提供して手数料を獲得することができます。 Uniswap は広く利用されているため、多種多様なトークンに最大規模の流動性を提供する取引所のひとつです。 あなたの Dapp に Uniswap を組み込むことで、ETH を DAI とスワップする機能などが簡単に実現できます。 +[Uniswap](https://uniswap.exchange/)は分散型取引所（DEX）です。 流動性供給者は、取引の両側に必要なトークンやEtherを提供することで手数料を得ることができます。 広く利用されているため、非常に広範囲のトークンに対して最も高い流動性の1つを持っています。 例えば、ユーザーがETHをDAIにスワップできるように、dappに簡単に統合できます。 -残念ながら、この記事の執筆時点で利用可能なのは Uniswap v1 のみとなっており、[最新リリースの v2](https://uniswap.org/blog/uniswap-v2/)は利用できません。 +残念ながら、この記事の執筆時点では、統合はUniswap v1のみで、[リリースされたばかりのv2](https://uniswap.org/blog/uniswap-v2/)には対応していません。 ### Sablier {#sablier} -[ Sablier](https://sablier.com/)は、ストリーミング決済を可能にする分散型アプリです。 Sablier をセットアップすれば、その後の管理を必要とせずに、1 回の支払日の代わりに常にお金を受け取ることができるようになります。 create-eth-app では、[独自の subgraph](https://thegraph.com/explorer/subgraph/sablierhq/sablier)が利用できます。 +[Sablier](https://sablier.com/)は、ユーザーがお金をストリーミングで支払うことを可能にします。 一度の給料日ではなく、初期設定後は追加の管理なしに継続的にお金を受け取ることができます。 この統合には、[独自のサブグラフ](https://thegraph.com/explorer/subgraph/sablierhq/sablier)が含まれています。 ## 次のステップ {#whats-next} -*create-eth-app*について質問がある場合は、[Sablier コミュニティーのサーバー](https://discord.gg/bsS8T47)にアクセスして、 *create-eth-app*の開発者に問い合わせることができます。 次のステップとしては、[Material UI](https://material-ui.com/)のような UI フレームワークの導入、あなたが実際に必要とするデータを取得するための GraphQL クエリの作成、およびデプロイのセットアップなどが考えられます。 +_create-eth-app_について質問がある場合は、[Sablierコミュニティサーバー](https://discord.gg/bsS8T47)にアクセスしてください。そこで_create-eth-app_の作成者と連絡を取ることができます。 最初の次のステップとして、[Material UI](https://mui.com/material-ui/)のようなUIフレームワークを統合し、実際に必要なデータのためにGraphQLクエリを書き、デプロイをセットアップすることをお勧めします。 diff --git a/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md b/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md index 0f0ab41e76d..6cade4dfe88 100644 --- a/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md +++ b/public/content/translations/ja/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md @@ -1,6 +1,6 @@ --- -title: create-eth-appでDappのフロントエンド開発をはじめましょう -description: create-eth-appの使い方と機能の概要 +title: "create-eth-appでDappのフロントエンド開発をはじめましょう" +description: "create-eth-appの使い方と機能の概要" author: "Markus Waas" tags: - "create-eth-app" diff --git a/public/content/translations/ja/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md b/public/content/translations/ja/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md index d2d4dc2fd2a..bbb909695df 100644 --- a/public/content/translations/ja/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md +++ b/public/content/translations/ja/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md @@ -1,11 +1,8 @@ --- -title: SQLでイーサリアムの基礎的なトピックについて学ぶ -description: このチュートリアルは、SQL（Structured Query Language）を使用してブロックチェーン上のデータに対するクエリを実行することで、トランザクション、ブロック、ガスといったイーサリアムの基本的な概念についての理解を深めるものです。 +title: "SQLでイーサリアムの基礎的なトピックについて学ぶ" +description: "このチュートリアルは、SQL（Structured Query Language）を使用してオンチェーンデータにクエリを実行することで、トランザクション、ブロック、ガスといったイーサリアムの基本的な概念についての理解を深めるものです。" author: "Paul Apivat" -tags: - - "SQL" - - "クエリ" - - "トランザクション" +tags: [ "SQL", "クエリ", "トランザクション" ] skill: beginner lang: ja published: 2021-05-11 @@ -13,27 +10,27 @@ source: paulapivat.com sourceUrl: https://paulapivat.com/post/query_ethereum/ --- -イーサリアムに関するチュートリアルの多くはデベロッパ向けのものですが、データアナリストや、クライアント／ノードを実行することなくオンチェーンのデータを確認したい人々を対象とする学習リソースは多くありません。 +イーサリアムに関するチュートリアルの多くはデベロッパー向けのものですが、データアナリストや、クライアント／ノードを実行することなくオンチェーンのデータを確認したい人々を対象とする学習リソースは多くありません。 -このチュートリアルは、[Dune Analytics](https://dune.xyz/home)が提供するインターフェースを用いて、オンチェーンのデータに対してSQL（Structured Query Language）のクエリを実行することで、トランザクション、ブロック、ガスといったイーサリアムの基本的なコンセプトについての理解を深めるものです。 +このチュートリアルは、[Dune Analytics](https://dune.com/)が提供するインターフェースを用いて、オンチェーンのデータに対して構造化問い合わせ言語（SQL）のクエリを実行することで、トランザクション、ブロック、ガスといったイーサリアムの基本的なコンセプトについての理解を深めるものです。 オンチェーンのデータは、イーサリアムやイーサリアム・ネットワークに関する理解を深めるのに役立つだけでなく、コンピュータ処理能力の経済学といった現在のイーサリアムが直面している課題（例：ガス代の上昇）や、より重要性が高いスケーリング・ソリューションに関する議論について、基本的な事項を理解する土台となるものです。 ### トランザクション {#transactions} -イーサリアムの新規ユーザーはまず、ETH残高を持つエンティティであるユーザー管理アカウントを初期化する必要があります。 イーサリアムのアカウントには、ユーザー管理アカウントとスマートコントラクトの2種類があります（[ethereum.org](/developers/docs/accounts/)を参照)してください）。 +イーサリアムのユーザーの体験は、ユーザーが管理するアカウント、またはETH残高を持つエンティティを初期化することから始まります。 アカウントには、ユーザー管理アカウントとスマートコントラクトの2種類があります（[ethereum.org](/developers/docs/accounts/)を参照）。 -すべてのアカウントは、[Etherscan](https://etherscan.io/)のようなブロックエクスプローラーで表示できます。 ブロックエクスプローラーは、イーサリアム上のデータポータルです。 このポータルから、ブロックのデータ、トランザクション、マイナー、アカウント、および他のオンチェーンのアクティビティをリアルタイムで確認できます（[こちら](/developers/docs/data-and-analytics/block-explorers/)をご覧ください）。 +どのアカウントも、[Etherscan](https://etherscan.io/)や[Blockscout](https://eth.blockscout.com/)のようなブロックエクスプローラーで表示できます。 ブロックエクスプローラーは、イーサリアム上のデータポータルです。 このポータルから、ブロックのデータ、トランザクション、マイナー、アカウント、および他のオンチェーンのアクティビティをリアルタイムで確認できます（[こちら](/developers/docs/data-and-analytics/block-explorers/)をご覧ください）。 -しかし、外部のブロックエスプローラーが提供する情報と直接照合したい場合は、オンチェーンのデータに対するクエリを実行したいと思うかもしれません。 [Dune Analytics](https://duneanalytics.com/)は、SQLに関する一定の知識を前提として、あらゆるユーザーにこのクエリ機能を提供します。 +しかし、外部のブロックエクスプローラーが提供する情報と直接照合したい場合は、オンチェーンのデータに対するクエリを実行したいと思うかもしれません。 [Dune Analytics](https://dune.com/)は、SQLに関する一定の知識を持つ人なら誰でもこの機能を利用できるようにします。 -参考までに、イーサリアム・ファウンデーション (EF) のスマートコントラクトアカウントは[Etherscan](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae)で表示することができます。 +参考までに、イーサリアム財団(EF)のスマートコントラクトアカウントは[Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)で閲覧できます。 -EFのアカウントを含むすべてのアカウントは、トランザクションの送受信に使用できる公開アドレスを持つ点に留意してください。 +注意すべき点として、EFのアカウントを含むすべてのアカウントは、トランザクションの送受信に使用できる公開アドレスを持つということが挙げられます。 -Etherscanのアカウント残高は、通常のトランザクションと内部トランザクションで構成されています。 内部トランザクションは誤解を招きやすい名前ですが、チェーンの状態を変更する _実際の_トランザクションではありません。 内部トランザクションとは、コントラクト（[ソース](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions)）を実行することで開始される「値の移転」を意味します。 内部トランザクションは署名を持たないためブロックチェーンには **含まれず**、Dune Analyticsでクエリを実行することができません。 +Etherscanのアカウント残高は、通常のトランザクションと内部トランザクションで構成されています。 内部トランザクションは、その名前とは裏腹に、チェーンの状態を変更する_実際の_トランザクションではありません。 これらは、コントラクトの実行によって開始される値の転送です([ソース](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions))。 内部トランザクションは署名を持たないためブロックチェーンには**含まれず**、Dune Analyticsでクエリを実行することができません。 -従って、このチュートリアルでは通常のトランザクションのみを取り上げます。 通常のトランザクションに対しては、以下のようにクエリを実行します： +したがって、このチュートリアルでは通常のトランザクションのみを取り上げます。 通常のトランザクションに対しては、以下のようにクエリを実行します。 ```sql WITH temp_table AS ( @@ -61,33 +58,33 @@ SELECT FROM temp_table ``` -これにより、Etherscanのトランザクションページで提供されるのと同一の情報が返されます。 これら2つのソースを比較してみましょう： +これにより、Etherscanのトランザクションページで提供されるのと同一の情報が返されます。 比較のために、2つのソースを以下に示します。 #### Etherscan {#etherscan} ![](./etherscan_view.png) -[Etherscan上のEFのコントラクトのページ](https://etherscan.io/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) +[Blockscout上のEFのコントラクトページ。](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) #### Dune Analytics {#dune-analytics} ![](./dune_view.png) -ダッシュボードは、[こちら](https://duneanalytics.com/paulapivat/Learn-Ethereum)からアクセスしてください。 テーブルをクリックすると、クエリを確認できます（上記も参照してください）。 +ダッシュボードは[こちら](https://dune.com/paulapivat/Learn-Ethereum)にあります。 テーブルをクリックすると、クエリを確認できます（上記も参照してください）。 -### トランザクションの内容を見る {#breaking_down_transactions} +### トランザクションの内訳 {#breaking_down_transactions} -送信されたトランザクションには、（[ソース](/developers/docs/transactions/)）を含むいくつかの情報が含まれています。 +送信されたトランザクションには、以下のようないくつかの情報が含まれています([ソース](/developers/docs/transactions/)): -- **Recipient**：受信者のアドレス（「to」のクエリに該当したアドレス）。 -- **Signature**：トランザクションに署名するのは送信者の秘密鍵ですが、SQLでクエリできるのは送信者の公開アドレス（「from」）です。 -- **Value**：送信されたETHの量 （`ether`列を参照してください）。 -- **Data**：ハッシュ化した任意のデータ（`data`列を参照してください）。 -- **gasLimit**：トランザクションで消費できるガスユニットの上限。 ガスユニットは、計算ステップを示します。 -- **maxPriorityFeePerGas**：マイナーへのチップとして提供できるガス量の上限。 -- **maxFeePerGas**：トランザクションに対して支払い可能であるガス代の上限（baseFeePerGasとmaxPriorityFeePerGasを含む） 。 +- **受信者**: 受信アドレス(クエリでは「to」) +- **署名**: 送信者の秘密鍵がトランザクションに署名しますが、SQLでクエリできるのは送信者の公開アドレス(「from」)です。 +- **値**: これは転送されたETHの量です(`ether`の列を参照)。 +- **データ**: ハッシュ化された任意のデータです(`data`列を参照) +- **ガスリミット** – トランザクションで消費できるガスユニットの最大量。 ガスユニットは、計算ステップを示します +- **maxPriorityFeePerGas** - マイナーへのチップとして含めることができるガスの最大量 +- **maxFeePerGas** - トランザクションに支払う意思のあるガスの最大額(baseFeePerGasとmaxPriorityFeePerGasを含む) -イーサリアムファウンデーションのパブリックアドレスへのトランザクションにつき、これらの具体的な情報をクエリしたい場合は以下を実行します： +イーサリアム財団の公開アドレスへのトランザクションについて、これらの具体的な情報を次のようにクエリできます: ```sql SELECT @@ -106,15 +103,15 @@ ORDER BY block_time DESC ### ブロック {#blocks} -各トランザクションは、イーサリアム仮想マシン（[EVM](/developers/docs/evm/)）の状態を変更します（[ソース](/developers/docs/transactions/)）。 トランザクションは、ネットワークにブロードキャストされ、検証を経てブロックに追加されます。 トランザクションごとに、ブロック番号が割り振られます。 データを見るには、特定のブロック番号でクエリすることができます。ブロック番号: 12396854は、執筆時点である2021年11月5日のイーサリアム・ファウンデーション内のトランザクションで最も最新のブロックです。 +各トランザクションは、イーサリアム仮想マシン([EVM](/developers/docs/evm/))の状態を変更します([ソース](/developers/docs/transactions/))。 トランザクションは、ネットワークにブロードキャストされ、検証を経てブロックに追加されます。 各トランザクションには、ブロック番号が関連付けられています。 データを見るには、特定のブロック番号でクエリすることができます。ブロック番号: 12396854は、執筆時点(2021/11/5)でイーサリアム財団のトランザクションの中で最も新しいブロックです。 さらに、次の2つのブロックに対してクエリを実行すると、各ブロックが1つ前のブロックのハッシュ（親ハッシュ）を含んでいることが確認でき、ブロックチェーンがどのように形成されるかを理解できます。 -各ブロックには、親ブロックに対する参照情報が含まれています。 これは、`hash`列と`parent_hash`列の間に表示されます（[ソース](/developers/docs/blocks/)）。 +各ブロックには、親ブロックへの参照が含まれています。 これは、以下の`hash`列と`parent_hash`列の間に示されます([ソース](/developers/docs/blocks/)): ![parent_hash](./parent_hash.png) -Dune Analyticsでは、[クエリ](https://duneanalytics.com/queries/44856/88292)は以下のように表示されます： +Dune Analyticsでの[クエリ](https://dune.com/queries/44856/88292)はこちらです: ```sql SELECT @@ -128,18 +125,18 @@ WHERE "number" = 12396854 OR "number" = 12396855 OR "number" = 12396856 LIMIT 10 ``` -ブロックを調べるには、時間、ブロック番号、難易度、ハッシュ、親ハッシュ、およびノンスに対してクエリを実行します。 +時間、ブロック番号、難易度、ハッシュ、親ハッシュ、およびノンスをクエリすることでブロックを調べることができます。 -このクエリでは、_トランザクションのリスト_だけは調べることができません。このためトランザクションのリストについては、_state root_を使って後述する別のクエリを実行します。 フルノードまたはアーカイブノードは、すべてのトランザクションと状態遷移を保存しますので、クライアントはいつでもチェーンの状態をクエリすることができます。 これには大容量のストレージが必要になりますので、チェーンデータと状態データを分離することができます： +このクエリがカバーしていないのは、_トランザクションのリスト_と_ステート・ルート_のみで、これらには以下の別のクエリが必要です。 フルノードまたはアーカイブノードは、すべてのトランザクションと状態遷移を保存しますので、クライアントはいつでもチェーンの状態をクエリすることができます。 これには大容量のストレージが必要になりますので、チェーンデータと状態データを分離することができます: - チェーンデータ（ブロックおよびトランザクションのリスト） - 状態データ（各トランザクションによる状態遷移の結果） -状態ルートは後者（状態データ）であり、_暗黙的な_データである（オンチェーンで保存されない）のに対し、チェーンデータは明示的なデータであり、チェーン自体に保存されます（[ソース](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored)）。 +ステート・ルートは後者に分類され_暗黙的_なデータ（オンチェーンで保存されない）ですが、チェーンデータは明示的であり、チェーン自体に保存されます([ソース](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored))。 -このチュートリアルでは、Dune Analyticsを使ってSQLで_クエリ可能_であるオンチェーンのデータを取り上げます。 +このチュートリアルでは、Dune Analyticsを使ってSQLでクエリ_できる_オンチェーンのデータに焦点を当てます。 -すでに述べたように、各ブロックにはトランザクションのリストが含まれているので、特定のブロックに絞り込んでクエリを実行できます。 さっそく、最新ブロック「12396854」を試してみましょう。 +すでに述べたように、各ブロックにはトランザクションのリストが含まれているので、特定のブロックに絞り込んでクエリを実行できます。 最新ブロック「12396854」を試してみましょう: ```sql SELECT * FROM ethereum."transactions" @@ -147,13 +144,13 @@ WHERE block_number = 12396854 ORDER BY block_time DESC` ``` -Duneでは、このようなSQL出力が得られます： +DuneでのSQL出力はこちらです: ![](./list_of_txn.png) -ブロックチェーンにこの1つのブロックが追加されると、イーサリアム仮想マシン （[EVM](/developers/docs/evm/)）の状態が変化します。 ブロックチェーンでは、一度に数十、時には数百ものトランザクションが検証されます。 このブロックの場合、222件のトランザクションが含まれていました。 +この1つのブロックがチェーンに追加されると、イーサリアム仮想マシン([EVM](/developers/docs/evm/))の状態が変化します。 一度に数十、時には数百ものトランザクションが検証されます。 このブロックの場合、222件のトランザクションが含まれていました。 -実際にトランザクションが成功した件数を調べるには、成功したトランザクションのみを絞り込むフィルターを追加します： +実際に成功した件数を調べるには、成功したトランザクションをカウントするフィルターを追加します。 ```sql WITH temp_table AS ( @@ -166,26 +163,26 @@ SELECT FROM temp_table ``` -ブロック12396854では、計222件のトランザクションのうち、204件が正常に検証されました： +ブロック12396854では、計222件のトランザクションのうち、204件が正常に検証されました: ![](./successful_txn.png) -トランザクションリクエストは、毎秒あたり数十回発生しますが、ブロックがコミットされるのはおよそ15秒に1回です（[ソース](/developers/docs/blocks/)）。 +トランザクションリクエストは毎秒数十回発生しますが、ブロックがコミットされるのはおよそ15秒に1回です([ソース](/developers/docs/blocks/))。 -約15秒ごとに1つのブロックが生成されることを確認するには、1日に含まれる合計の秒数（86,400秒）を15で割ることで、1日に生成される平均ブロック数（およそ5,760）が分かります。 +約15秒ごとに1つのブロックが生成されることを確認するには、1日に含まれる合計の秒数（86400秒）を15で割ることで、1日に生成される平均ブロック数（およそ5760）が分かります。 -2016年から現在までに、イーサリアムで生成された1日あたりのブロック数については、この表を参照してください： +イーサリアムで1日あたりに生成されたブロック数（2016年〜現在）のグラフはこちらです: ![](./daily_blocks.png) -この期間に毎日生成されたブロックの平均数は、約5,874 です。 +この期間に毎日生成されたブロックの平均数は約5,874です: ![](./avg_daily_blocks.png) -クエリは、次のように行います： +クエリは、次のように行います。 ```sql -# query to visualize number of blocks produced daily since 2016 +# 2016年以降に毎日生成されたブロック数を可視化するクエリ SELECT DATE_TRUNC('day', time) AS dt, @@ -194,7 +191,7 @@ FROM ethereum."blocks" GROUP BY dt OFFSET 1 -# average number of blocks produced per day +# 1日あたりの平均ブロック生成数 WITH temp_table AS ( SELECT @@ -209,13 +206,13 @@ SELECT FROM temp_table ``` -2016年から現在までに1日に生成されたブロック数の平均は、5,874をわずかに上回っています。 反対に、86,400秒を平均ブロック数である5,874で割ると14.7となるため、およそ15秒に1回の頻度でブロックが生成されたことが分かります。 +2016年から現在までに1日に生成されたブロック数の平均は、この数字をわずかに上回る5,874です。 あるいは、86,400秒を平均ブロック数5,874で割ると14.7秒となり、およそ15秒に1つのブロックが生成されていることになります。 ### ガス {#gas} -ブロックのサイズは、制限されています。 ブロックの最大サイズは、ネットワーク需要に応じて12,500,000ユニットから25,000,000ユニットの間で動的に変化します。 ブロックのサイズを制限する理由は、フルノードに対してディスク容量や処理速度の要件（[ソース](/developers/docs/blocks/)）が過剰な負担となるのを防ぐために、無駄に大きなサイズのブロックが発生することを防ぐためです。 +ブロックのサイズは制限されています。 ブロックの最大サイズは動的で、ネットワーク需要に応じて12,500,000から25,000,000ユニットの間で変動します。 ブロックサイズが任意に大きくなることで、フルノードのディスクスペースや処理速度に負荷がかかることを防ぐため、制限が必要となります([ソース](/developers/docs/blocks/))。 -ブロックに対するガス上限という概念を理解するには、トランザクションをバッチ処理するために利用できるブロックのスペースをどれだけ**供給**できるか、と考えるとよいでしょう。 ブロックのガス上限に対してもクエリを実行できるので、2016年から現在までのグラフは以下のようになります： +ブロックのガスリミットを理解する一つの方法として、トランザクションをバッチ処理するために利用できるブロックスペースの**供給**量と考えることができます。 ブロックのガスリミットは、クエリを実行して2016年から現在までを可視化できます: ![](./avg_gas_limit.png) @@ -228,7 +225,7 @@ GROUP BY dt OFFSET 1 ``` -さらに、イーサリアム・ブロックチェーン上で実行された処理（トランザクションの送信、スマートコントラクトの呼び出し、NFTのミント）のために実際に支払われた1日あたりのガスを調べることもできます。 これは、利用可能なイーサリアムのブロックスペースに対する**需要**を示します： +そして、イーサリアムチェーン上での計算(トランザクションの送信、スマートコントラクトの呼び出し、NFTのミントなど)の支払いに毎日使用される実際のガスがあります。 これは、利用可能なイーサリアムのブロックスペースに対する**需要**です: ![](./daily_gas_used.png) @@ -241,17 +238,17 @@ GROUP BY dt OFFSET 1 ``` -これら2つのグラフを比較することで、 **需要と供給**の関係を確認することができます： +また、これら2つのグラフを並べて比較することで、**需要と供給**がどのように一致するかを確認できます。 ![gas_demand_supply](./gas_demand_supply.png) -ここから、ブロックスペースが十分に供給されている場合、ガス価格はブロックスペースへの需要に応じて上下することが分かります。 +したがって、利用可能な供給量を前提として、ガス価格はイーサリアムのブロックスペースへの需要の関数として理解できます。 -最後に、イーサリアムチェーンにおける1日のガス価格の平均値を調べたい場合、クエリ時間が非常に長くなるため、イーサリアム・ファウンデーションがトランザクション1件あたりに支払ったガス代の平均値を調べるようにクエリを絞り込みます。 +最後に、イーサリアムチェーンの1日あたりの平均ガス価格をクエリすることもできますが、クエリ時間が非常に長くなるため、イーサリアム財団によってトランザクションごとに支払われた平均ガス量にクエリを絞り込みます。 ![](./ef_daily_gas.png) -2016年から現在までに、イーサリアム・ファウンデーションのアドレスに対して実行されたすべてのトランザクションにおいて支払われたガス価格を確認することができます。 クエリは、以下のように実行します： +長年にわたるイーサリアム財団のアドレスへのすべてのトランザクションで支払われたガス価格を見ることができます。 クエリは、次のとおりです。 ```sql SELECT @@ -265,8 +262,8 @@ ORDER BY block_time DESC ### まとめ {#summary} -このチュートリアルでは、クエリを実行し、オンチェーンのデータを確認することで、イーサリアムの基本的な概念やイーサリアム・ブロックチェーンの仕組みについて学びました。 +このチュートリアルでは、オンチェーンのデータをクエリして理解することで、イーサリアムの基本的な概念とイーサリアムブロックチェーンの仕組みを理解します。 -このチュートリアルで使用したすべてのコードをまとめたダッシュボードは、[こちら](https://duneanalytics.com/paulapivat/Learn-Ethereum)からアクセスしてください。 +このチュートリアルで使用されたすべてのコードを含むダッシュボードは[こちら](https://dune.com/paulapivat/Learn-Ethereum)にあります。 -データを通じてWeb3の知識をさらに深めたい方は、[私をTwitterでフォローしてください](https://twitter.com/paulapivat)。 +データを使ってWeb3をさらに探求したい方は、[Twitterで私を見つけてください](https://twitter.com/paulapivat)。 diff --git a/public/content/translations/ja/developers/tutorials/logging-events-smart-contracts/index.md b/public/content/translations/ja/developers/tutorials/logging-events-smart-contracts/index.md index adb43255f91..1cbe7a7cec9 100644 --- a/public/content/translations/ja/developers/tutorials/logging-events-smart-contracts/index.md +++ b/public/content/translations/ja/developers/tutorials/logging-events-smart-contracts/index.md @@ -1,12 +1,8 @@ --- -title: イベントを使用して、スマートコントラクトのデータをログに記録する -description: スマートコントラクトにおけるイベントを紹介し、データのログを取るためにイベントを使用する方法を学ぶ +title: "イベントを使用して、スマートコントラクトのデータをログに記録する" +description: "スマートコントラクトにおけるイベントを紹介し、データのログを取るためにイベントを使用する方法を学ぶ" author: "jdourlens" -tags: - - "スマートコントラクト" - - "Remix" - - "Solidity" - - "イベント" +tags: [ "スマートコントラクト", "Remix", "Solidity", "イベント" ] skill: intermediate lang: ja published: 2020-04-03 @@ -15,7 +11,7 @@ sourceUrl: https://ethereumdev.io/logging-data-with-events/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -Solidityでは、スマートコントラクトがトリガーすることで送信される信号を[イベント](/developers/docs/smart-contracts/anatomy/#events-and-logs)と呼びます。 Dappだけでなく、イーサリアムのJSON-RPC APIに接続されたすべてのプログラムは、これらのイベントをリッスンし、それに応じて動作します。 イベントをインデックス化すれば、後でイベント履歴を参照することができます。 +Solidityでは、[イベント](/developers/docs/smart-contracts/anatomy/#events-and-logs)はスマートコントラクトが発行できるディスパッチされたシグナルです。 Dapps、またはイーサリアムのJSON-RPC APIに接続されたあらゆるものは、これらのイベントをリッスンして、それに応じて動作することができます。 イベントにインデックスを付けることで、後でイベント履歴を検索できるようになります。 ## イベント {#events} @@ -25,9 +21,9 @@ Solidityでは、スマートコントラクトがトリガーすることで送 event Transfer(address indexed from, address indexed to, uint256 value); ``` -イベントの署名はコントラクトのコード内で宣言され、emitキーワードと共に発行されます。 例えば、送信イベントでは、この送信における送信元（_from_）、送信先（_to_）、および送信したトークン量（_value_）のログが記録されます。 +イベントの署名はコントラクトのコード内で宣言され、emitキーワードと共に発行されます。 例えば、転送イベントでは、この転送における送信元(_from_)、送信先(_to_)、および送信したトークン量(_value_)のログが記録されます。 -Counterのスマートコントラクトに戻り、値が変更されるたびにログを取ることにしたと仮定しましょう。 このコントラクトは、デプロイを目的とせず、別のコントラクトを拡張する土台の役割を担うため、抽象コントラクトと呼びます。 カウンターのスマートコントラクトでは、以下のようになります： +Counterスマートコントラクトに戻り、値が変更されるたびにログを記録することにしたと仮定しましょう。 このコントラクトは、デプロイを目的とせず、別のコントラクトを拡張する土台の役割を担うため、抽象コントラクトと呼びます。 カウンターの例では、このようになります： ```solidity pragma solidity 0.5.17; @@ -36,16 +32,16 @@ contract Counter { event ValueChanged(uint oldValue, uint256 newValue); - // Private variable of type unsigned int to keep the number of counts + // カウント数を保持するための符号なし整数のプライベート変数 uint256 private count = 0; - // Function that increments our counter + // カウンターをインクリメントする関数 function increment() public { count += 1; emit ValueChanged(count - 1, count); } - // Getter to get the count value + // カウント値を取得するためのゲッター function getCount() public view returns (uint256) { return count; } @@ -53,11 +49,11 @@ contract Counter { } ``` -注意: +注意： -- **5行目**：イベントを宣言し、イベントに含まれる古い値と新しい値を宣言します。 +- **5行目**: イベントと、それに含まれる古い値および新しい値を宣言します。 -- **13行目**：カウントの変数が1増えるごとに、イベントが発行されます。 +- **13行目**: count変数をインクリメントするときに、イベントを発行します。 このコントラクトをデプロイしてインクリメント関数を呼び出し、ログという名前の配列にある新しいトランザクションをクリックすると、Remixが自動的にこのイベントを表示します。 diff --git a/public/content/translations/ja/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/ja/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md index cfb8d93b96c..b68f2080b81 100644 --- a/public/content/translations/ja/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md +++ b/public/content/translations/ja/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md @@ -1,9 +1,8 @@ --- -title: オフラインデータの完全性のためのマークルプルーフ -description: オフチェーンに大部分が保存されているデータに対し、オンチェーンでのデータの完全性の確保 +title: "オフラインデータの完全性のためのマークルプルーフ" +description: "オフチェーンに大部分が保存されているデータに対し、オンチェーンでのデータの完全性の確保" author: Ori Pomerantz -tags: - - "ストレージ" +tags: [ "ストレージ" ] skill: advanced lang: ja published: 2021-12-30 @@ -13,29 +12,31 @@ published: 2021-12-30 すべてのデータは、イーサリアムストレージに保存することが理想的です。このストレージは、数千ものコンピューターに保存され、非常に高い可用性(データは検閲されない)と完全性(データは不正に変更されない)を備えていますが、32バイトワードを保存するのに通常2万ガスがかかります。 執筆時点で、そのコストは$6.60に相当します。 1バイトごとに21セントかかるため、多くの用途には高すぎます。 -この問題を解決するために、イーサリアムのエコシステムでは[データを保存する多くの分散型の方法](/developers/docs/storage/)が開発されました。 通常、これらは可用性と価格のトレードオフを伴います。 しかしながら、一般に完全性は保証されます。 +この問題を解決するために、イーサリアムのエコシステムはデータを分散型の +方法で保存するための多くの代替手段を開発しました。 通常、これらは可用性と価格のトレードオフを伴います。 しかしながら、一般に完全性は保証されます。 -この記事では、ブロックチェーンにデータを保存することなくデータ完全性を確保する**方法**として[マークルプルーフ](https://computersciencewiki.org/index.php/Merkle_proof)を使用する方法を学びます。 +この記事では、[マークルプルーフ](https://computersciencewiki.org/index.php/Merkle_proof)を使用して、 +ブロックチェーンにデータを保存せずにデータの完全性を確保する**方法**を学びます。 ## 仕組み {#how-does-it-work} -理論上、チェーン上にデータのハッシュだけを保存し、トランザクション内で必要なすべてのデータを送信することができます。 しかし、これでもまだ高すぎます。 1バイトのデータのトランザクションのコストは約16ガスで、現時点では0.5セントです。つまり、1キロバイトあたり約 $5になります。 1メガバイトでは $5000になり、データをハッシュ化するコストを差し引いても、多くの用途にはまだ高すぎます。 +理論上は、データのハッシュのみをオンチェーンに保存し、それを必要とするトランザクションですべてのデータを送信できます。 しかし、これでもまだ高すぎます。 1バイトのデータのトランザクションのコストは約16ガスで、現時点では0.5セントです。つまり、1キロバイトあたり約 $5になります。 1メガバイトでは $5000になり、データをハッシュ化するコストを差し引いても、多くの用途にはまだ高すぎます。 これを解決するには、異なるデータのサブセットを繰り返しハッシュ化します。そうすることで、データを送信する必要が無い場合は、ハッシュを送信するだけで済むようになります。 これを行うには、次のようなマークルツリーを使用します。このツリーは、それぞれのノードがその下のノードのハッシュとなるデータ構造を持ちます。 ![マークルツリー](tree.png) -チェーン上に保存する必要があるのは、ルートハッシュのみとなります。 特定の値を証明するには、ルートのハッシュを得るために、その値と結合させる必要があるハッシュをすべて提供します。 例えば、`C`を証明するには、`D`、`H(A-B)`、`H(E-H)`を提供します。 +オンチェーンに保存する必要があるのはルートハッシュのみです。 特定の値を証明するには、ルートのハッシュを得るために、その値と結合させる必要があるハッシュをすべて提供します。 例えば、`C`を証明するには、`D`、`H(A-B)`、`H(E-H)`を提供します。 ![Cの値の証明](proof-c.png) ## 実装 {#implementation} -[サンプルコードはこちらで入手できます](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity)。 +[サンプルコードはこちらで提供されています](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity)。 -### オフチェーンコード {#off-chain-code} +### オフチェーンコード {#offchain-code} -この記事では、オフチェーン計算にJavaScriptを使用します。 ほとんどの分散型アプリケーションには、JavaScriptのオフチェーンコンポーネントがあります。 +この記事では、オフチェーンの計算にJavaScriptを使用します。 ほとんどの分散型アプリケーションには、JavaScriptのオフチェーンコンポーネントがあります。 #### マークルルートの作成 {#creating-the-merkle-root} @@ -48,58 +49,60 @@ const ethers = require("ethers") [ethersパッケージのハッシュ関数を使用します](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256)。 ```javascript -// The raw data whose integrity we have to verify. The first two bytes a -// are a user identifier, and the last two bytes the amount of tokens the -// user owns at present. +// 完全性を検証する必要がある生データです。最初の2バイトは +// ユーザー識別子、最後の2バイトはユーザーが +// 現在所有しているトークンの量です。 const dataArray = [ 0x0bad0010, 0x60a70020, 0xbeef0030, 0xdead0040, 0xca110050, 0x0e660060, 0xface0070, 0xbad00080, 0x060d0091, ] ``` -各エントリを単一の256ビット整数にエンコードすると、JSONを使用した場合などよりも読みにくいコードになります。 しかし、これによりコントラクト内のデータを取得するための処理量が大幅に削減され、ガス代も大幅に削減されます。 [チェーン上でJSONを読み取ることができますが](https://github.com/chrisdotn/jsmnSol)、回避できるのであれば避けるべきです。 +各エントリを単一の256ビット整数にエンコードすると、JSONを使用した場合などよりも読みにくいコードになります。 しかし、これによりコントラクト内のデータを取得するための処理量が大幅に削減され、ガス代も大幅に削減されます。 [オンチェーンでJSONを読み込むことはできますが](https://github.com/chrisdotn/jsmnSol)、回避できるのであれば良いアイデアではありません。 ```javascript -// The array of hash values, as BigInts +// BigIntとしてのハッシュ値の配列 const hashArray = dataArray ``` ここでは、256ビット値のデータで始めるので、処理は必要ありません。 文字列型のようなより複雑なデータ構造を使用する場合は、まずデータをハッシュ化してハッシュ配列を取得する必要があります。 これは、ユーザーが他のユーザーの情報を知っていても知らなくても構わないことを前提にしているためでもあります。 さもなければ、ユーザー1がユーザー0の値がわからないように、ユーザー2がユーザー3の値がわからないように、というようなハッシュ化をしなければならなくなります。 ```javascript -// Convert between the string the hash function expects and the -// BigInt we use everywhere else. +// ハッシュ関数が期待する文字列と +// 他の場所で使用するBigIntを相互に変換します。 const hash = (x) => BigInt(ethers.utils.keccak256("0x" + x.toString(16).padStart(64, 0))) ``` -ethersのハッシュ関数は、`0x60A7`などの16進数のJavaScript文字列を受け取ることを想定しており、同じ構造の別の文字列で応答します。 ただし、コードの他の部分では、`BigInt`を使う方が簡単なため、16進数文字列に変換してから、もう一度`BigInt`に戻します。 +ethersのハッシュ関数は、`0x60A7`などの16進数のJavaScript文字列を受け取ることを想定しており、同じ構造の別の文字列で応答します。 ただし、コードの残りの部分では`BigInt`を使用する方が簡単なので、16進数の文字列に変換して、また元に戻します。 ```javascript -// ペアの対称ハッシュのため、順序が逆でも構いません。 +// 順序が逆でも気にしなくていいように、ペアを対称的にハッシュ化します。 const pairHash = (a, b) => hash(hash(a) ^ hash(b)) ``` -この関数は対称(a [xor](https://en.wikipedia.org/wiki/Exclusive_or) bのハッシュ)です。 そのため、マークルプルーフを確認するときに、計算された値の前と後のどちらにプルーフの値を配置すべきかについて考慮する必要はありません。 マークルプルーフの確認はオンチェーンで行われるので、必要な処理が少ないほど良いとされます。 +この関数は対称的です(a [xor](https://en.wikipedia.org/wiki/Exclusive_or) b のハッシュ)。 そのため、マークルプルーフを確認するときに、計算された値の前と後のどちらにプルーフの値を配置すべきかについて考慮する必要はありません。 マークルプルーフの確認はオンチェーンで行われるので、必要な処理が少ないほど良いとされます。 -警告: 暗号技術は見た目以上に難解です。 この記事の最初のバージョンでは、ハッシュ関数`hash(a^b)`を使用していました。 これは、**好ましくない**手法でした。`a`と`b`の正しい値を知っていれば、`b' = a^b^a'`を使用して目的の`a'`の値を証明できるからです。 この関数では、`hash(a') ^ hash(b')`が既知の値(ルートに向かう経路上の隣のブランチ)と等しくなるように`b'`を計算する必要があり、これは非常に困難です。 +警告: 暗号技術は見た目以上に難解です。 +この記事の初版では、ハッシュ関数`hash(a^b)`を使用していました。 +これは**悪い**アイデアでした。なぜなら、`a`と`b`の正当な値を知っていれば、`b' = a^b^a'`を使って任意の`a'`の値を証明できてしまうからです。 +この関数では、`hash(a') ^ hash(b')`が既知の値(ルートに向かう途中の次のブランチ)と等しくなるように`b'`を計算する必要があり、これははるかに困難です。 ```javascript -// The value to denote that a certain branch is empty, doesn't -// have a value +// あるブランチが空で、値を +// 持たないことを示すための値です。 const empty = 0n ``` 値の数が2の整数乗ではない時は、空のブランチを処理する必要があります。 このプログラムでは、ゼロをプレースホルダーとして配置する方法を使っています。 -![ブランチが欠けているマークルツリー](merkle-empty-hash.png) +![ブランチが欠落しているマークルツリー](merkle-empty-hash.png) ```javascript -// Calculate one level up the tree of a hash array by taking the hash of -// each pair in sequence +// 各ペアを順番にハッシュ化することで、ハッシュ配列のツリーを1レベル上に計算します。 const oneLevelUp = (inputArray) => { var result = [] - var inp = [...inputArray] // To avoid over writing the input // Add an empty value if necessary (we need all the leaves to be // paired) + var inp = [...inputArray] // 入力の上書きを避けるため // 必要であれば空の値を追加します (すべてのリーフが // ペアになるようにする必要があります) if (inp.length % 2 === 1) inp.push(empty) @@ -110,13 +113,13 @@ const oneLevelUp = (inputArray) => { } // oneLevelUp ``` -この関数は、現在のレイヤーで値のペアをハッシュ化すると、マークルツリーを1レベル「登り」ます。 これは効率性を追求した実装ではないことに留意してください。入力のコピーを避け、ループ内で適切なタイミングで単に`hashEmpty`を加えることもできますが、このコードは読みやすさを重視して最適化されています。 +この関数は、現在のレイヤーで値のペアをハッシュ化すると、マークルツリーを1レベル「登り」ます。 これは最も効率的な実装ではないことに注意してください。入力のコピーを避け、ループ内で適切なときに`hashEmpty`を追加することもできましたが、このコードは読みやすさを重視して最適化されています。 ```javascript const getMerkleRoot = (inputArray) => { var result - result = [...inputArray] // Climb up the tree until there is only one value, that is the // root. // // If a layer has an odd number of entries the // code in oneLevelUp adds an empty value, so if we have, for example, // 10 leaves we'll have 5 branches in the second layer, 3 // branches in the third, 2 in the fourth and the root is the fifth + result = [...inputArray] // 値が1つだけになるまでツリーを登ります。それが // ルートです。 // // レイヤーのエントリ数が奇数の場合、 // oneLevelUpのコードが空の値を追加するため、例えば、 // 10個のリーフがあれば、第2レイヤーには5個のブランチ、 // 第3レイヤーには3個のブランチ、第4レイヤーには2個、そしてルートが5番目になります。 while (result.length > 1) result = oneLevelUp(result) @@ -131,30 +134,30 @@ const getMerkleRoot = (inputArray) => { マークルプルーフは、マークルルートを得るために、証明される値と一緒にハッシュ化する値です。 証明する値は、他のデータから入手することが多いため、コードの一部としてではなく、別に提供することをお勧めします。 ```javascript -// A merkle proof consists of the value of the list of entries to -// hash with. Because we use a symmetrical hash function, we don't -// need the item's location to verify the proof, only to create it +// マークルプルーフは、一緒にハッシュ化するエントリのリストの値で +// 構成されます。対称的なハッシュ関数を使用しているため、プルーフの検証に +// アイテムの位置は不要で、作成時にのみ必要です。 const getMerkleProof = (inputArray, n) => {     var result = [], currentLayer = [...inputArray], currentN = n -    // Until we reach the top +    // トップに到達するまで     while (currentLayer.length > 1) { -        // No odd length layers +        // レイヤーの長さが奇数にならないようにする         if (currentLayer.length % 2)             currentLayer.push(empty)         result.push(currentN % 2 -               // If currentN is odd, add with the value before it to the proof +               // currentNが奇数の場合、その前の値をプルーフに追加します             ? currentLayer[currentN-1] -               // If it is even, add the value after it +               // 偶数の場合、その後の値を追加します             : currentLayer[currentN+1]) ``` -ハッシュ化は、`(v[0],v[1])`、`(v[2],v[3])`のように行っていきます。 したがって、偶数の値の場合はその次の値、基数の値の場合は1つ前の値が必要です。 +`(v[0],v[1])`、`(v[2],v[3])`などをハッシュ化します。 したがって、偶数の値の場合はその次の値、基数の値の場合は1つ前の値が必要です。 ```javascript -        // Move to the next layer up +        // 上のレイヤーに移動します         currentN = Math.floor(currentN/2)         currentLayer = oneLevelUp(currentLayer)     }   // while currentLayer.length > 1 @@ -163,9 +166,9 @@ const getMerkleProof = (inputArray, n) => { }   // getMerkleProof ``` -### オンチェーンコード {#on-chain-code} +### オンチェーンコード {#onchain-code} -最後は、証明を確認するコードです。 オンチェーンコードは、[Solidity](https://docs.soliditylang.org/en/v0.8.11/)で書かれています。 ガス代が比較的高価なため、ここでは最適化がかなり重要になります。 +最後は、証明を確認するコードです。 オンチェーンコードは[Solidity](https://docs.soliditylang.org/en/v0.8.11/)で記述されています。 ガス代が比較的高価なため、ここでは最適化がかなり重要になります。 ```solidity //SPDX-License-Identifier: Public Domain @@ -174,7 +177,7 @@ pragma solidity ^0.8.0; import "hardhat/console.sol"; ``` -コードの作成には、[Hardhat開発環境](https://hardhat.org/)を使用しました。この環境では、開発している間も[Solidityからコンソール出力](https://hardhat.org/docs/cookbook/debug-logs)を得ることができます。 +これは[Hardhat開発環境](https://hardhat.org/)を使用して作成しました。これにより、開発中に[Solidityからのコンソール出力](https://hardhat.org/docs/cookbook/debug-logs)が可能になります。 ```solidity @@ -185,15 +188,15 @@ contract MerkleProof {       return merkleRoot;     } -    // Extremely insecure, in production code access to -    // this function MUST BE strictly limited, probably to an -    // owner +    // 非常に安全性が低い。本番コードでは、この関数への +    // アクセスを、おそらくオーナーに +    // 限定するなど、厳しく制限する必要があります。     function setRoot(uint _merkleRoot) external {       merkleRoot = _merkleRoot;     }   // setRoot ``` -マークルルート用のset関数とget関数が書かれています。 プロダクションシステムにおいて、誰でもマークルルートを更新できるようにすることは、_非常に好ましくない手法_です。 ここでは、サンプルコードをシンプルにするために、あえて行っています。 **データの完全性が重要なシステムでは、行わないでください**。 +マークルルート用のset関数とget関数が書かれています。 本番システムで誰でもマークルルートを更新できるようにすることは、_極めて悪いアイデア_です。 ここでは、サンプルコードをシンプルにするために、あえて行っています。 **データの完全性が実際に重要となるシステムでは、これを行わないでください**。 ```solidity     function hash(uint _a) internal pure returns(uint) { @@ -205,12 +208,12 @@ contract MerkleProof {     } ``` -この関数は、ペアのハッシュを生成します。 JavaScripコードの`hash`と`pairHash`をSolidityコードに変換したものです。 +この関数は、ペアのハッシュを生成します。 これは、`hash`と`pairHash`のJavaScriptコードをSolidityに変換したものです。 -**注:** これも読みやすさを重視して最適化されています。 [関数定義](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm)によると、データを[`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays)の値として保存することで、変換を回避できる場合があります。 +**注：**これも読みやすさを優先して最適化された例です。 [関数の定義](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm)に基づけば、データを[`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays)値として保存し、変換を回避できる可能性があります。 ```solidity -    // Verify a Merkle proof +    // マークルプルーフを検証します     function verifyProof(uint _value, uint[] calldata _proof)         public view returns (bool) {       uint temp = _value; @@ -226,16 +229,18 @@ contract MerkleProof { }  // MarkleProof ``` -数学的表記では、マークルプルーフの検証は次のようになります。 `H(proof_n, H(proof_n-1, H(proof_n-2, .. H(proof_1, H(proof_0, value))...)))`. これをこのコードで実装しています。 +数学的記法では、マークルプルーフの検証は次のようになります: `H(proof_n, H(proof_n-1, H(proof_n-2, ...` `H(proof_1, H(proof_0, value))...)))`。 これをこのコードで実装しています。 -## マークルプルーフとロールアップを混在させない {#merkle-proofs-and-rollups} +## マークルプルーフとロールアップの相性 {#merkle-proofs-and-rollups} -マークルプルーフは、[ロールアップ](/developers/docs/scaling/#rollups)では、うまく機能しません。 ロールアップでは、すべてのトランザクションデータはL1(レイヤー1)に書き込まれ、処理はL2(レイヤー2)で行われるためです。 マークルプルーフをトランザクションで送信するのにかかるコストは、1レイヤーあたり平均638ガスです(現在のコールデータ1バイトは、ゼロでなければ16ガス、ゼロであれば4ガスかかります)。 1024ワードのデータがある場合、マークルプルーフには10レイヤー、つまり合計で6380ガスが必要になります。 +マークルプルーフは[ロールアップ](/developers/docs/scaling/#rollups)とうまく機能しません。 ロールアップでは、すべてのトランザクションデータはL1(レイヤー1)に書き込まれ、処理はL2(レイヤー2)で行われるためです。 マークルプルーフをトランザクションで送信するのにかかるコストは、1レイヤーあたり平均638ガスです(現在のコールデータ1バイトは、ゼロでなければ16ガス、ゼロであれば4ガスかかります)。 1024ワードのデータがある場合、マークルプルーフには10レイヤー、つまり合計で6380ガスが必要になります。 -[Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m)の例を見ると、L1への書き込みには約100gweiのガス代がかかり、L2では0.001gweiのガス代がかかります(これは通常の価格であり、混雑とともに上昇する可能性があります) 。 したがって、L1の1回分のガス代で、L2では10万ガスを処理に使えることになります。 ストレージを上書きしないと仮定すると、L1の1回のガス代でL2のストレージに約5ワード書き込めるということになります。 単一のマークルプルーフの場合、1024ワードすべてをストレージに書き込むことができ(トランザクションで提供されるのではなく、最初からチェーン上で計算できると仮定した場合)、依然としてほとんどのガスが残ります。 +例えば[Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m)を見ると、L1への書き込みのガス代は約100 gwei、L2のガス代は0.001 gweiです(これは通常の価格で、混雑状況によって上昇する可能性があります)。 したがって、L1の1回分のガス代で、L2では10万ガスを処理に使えることになります。 ストレージを上書きしないと仮定すると、L1の1回のガス代でL2のストレージに約5ワード書き込めるということになります。 単一のマークルプルーフの場合、(トランザクションで提供されるのではなく、最初からオンチェーンで計算できると仮定して)1024ワードすべてをストレージに書き込んでも、まだガスのほとんどが残ります。 -## まとめ {#conclusion} +## 結論 {#conclusion} 実際に、マークルツリーを自身で実装することはないかもしれません。 よく知られている監査済みのライブラリを使用できるため、基本的には独自の暗号論的プリミティブを実装しないことをお勧めします。 しかし、マークルプルーフをよく理解し、使いどころを判断できるようになっていただければと思います。 -マークルプルーフは、_完全性_を保持しますが、_可用性_は保持しないことに注意してください。 データストレージにアクセスを拒否され、データストレージにアクセスするためのマークルツリーを構築することもできない場合でも、誰も自分の資産を奪うことはできないということを知っていると、ささやかな慰めとなります。 この特性により、マークルツリーは、IPFSなどの分散型ストレージで最もよく使用されています。 +マークルプルーフは_完全性_を維持しますが、_可用性_は維持しないことに注意してください。 データストレージにアクセスを拒否され、データストレージにアクセスするためのマークルツリーを構築することもできない場合でも、誰も自分の資産を奪うことはできないということを知っていると、ささやかな慰めとなります。 この特性により、マークルツリーは、IPFSなどの分散型ストレージで最もよく使用されています。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md b/public/content/translations/ja/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md index b279859cd9e..3e1a62a595b 100644 --- a/public/content/translations/ja/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md +++ b/public/content/translations/ja/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md @@ -1,41 +1,40 @@ --- -title: InfluxDBとGrafanaを使って、Gethを監視する -description: +title: "InfluxDBとGrafanaを使ったGethの監視" +description: "InfluxDBとGrafanaを使用してGethノードの監視を設定し、パフォーマンスを追跡して問題を特定します。" author: "Mario Havel" -tags: - - "クライアント" - - "ノード" +tags: [ "クライアント", "ノード" ] skill: intermediate lang: ja published: 2021-01-13 --- -このチュートリアルでは、Gethノードのモニタリングを設定する方法について説明します。これにより、モニタリングのパフォーマンスについて理解を深め、どのような問題が発生しうるかを理解することができます。 +このチュートリアルでは、Gethノードの監視を設定することで、パフォーマンスをよりよく理解し、潜在的な問題を特定する方法を説明します。 -## 事前に必要な環境 {#prerequisites} +## 前提条件 {#prerequisites} -- Gethのインスタンスを実行していること。 -- 大部分の作業ステップ／具体例はLinuxを用いていますので、基本的なターミナルの知識が必要でしょう。 -- Gethにおける一連のモニタリング指標については、以下の動画を参考にしてください：[イーサリアムのインフラをモニタリングする（Péter Szilágyi）](https://www.youtube.com/watch?v=cOBab8IJMYI)。 +- Gethのインスタンスがすでに実行されている必要があります。 +- 手順と例のほとんどはLinux環境向けであり、ターミナルの基本的な知識があると役立ちます。 +- Gethの一連のメトリクスの概要については、こちらの動画をご覧ください: [Péter Szilágyi氏によるイーサリアムインフラストラクチャの監視](https://www.youtube.com/watch?v=cOBab8IJMYI)。 -## モニタリング用のスタック {#monitoring-stack} +## 監視スタック {#monitoring-stack} -イーサリアムのクライアントは、時系列データベースの形式で読み取り可能な多くのデータを収集します。 このデータをデータ可視化ソフトウェアにフィードすることで、モニタリング作業を容易にすることができます。 利用できるデータ可視化ソフトウェアには、以下があります： +イーサリアムクライアントは、時系列データベースの形式で読み取り可能な多くのデータを収集します。 監視を容易にするため、このデータをデータ可視化ソフトウェアに入力することができます。 利用可能なオプションは複数あります: -- [Prometheus](https://prometheus.io/) （プル型） -- [InfluxDB](https://www.influxdata.com/get-influxdb/)（プッシュ型） +- [Prometheus](https://prometheus.io/) (プルモデル) +- [InfluxDB](https://www.influxdata.com/get-influxdb/) (プッシュモデル) - [Telegraf](https://www.influxdata.com/get-influxdb/) - [Grafana](https://www.grafana.com/) - [Datadog](https://www.datadoghq.com/) - [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/) -さらに、[Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter)がありますが、これはInfluxDBおよびGrafana上ですでに設定済みのオプションです。 +また、InfluxDBとGrafanaで事前設定されたオプションである[Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter)もあります。 -このチュートリアルでは、InfluxDBにデータをプッシュするように Gethクライアントを設定し、さらに、Grafanaがこのデータをグラフ化するように設定します。 この設定を手動で行うことで、設定プロセスについての理解を深めることができ、設定を変更したり、異なる環境でデプロイする方法を学ぶことができます。 +このチュートリアルでは、GethクライアントがInfluxDBにデータをプッシュしてデータベースを作成し、Grafanaがそのデータをグラフで可視化するように設定します。 手動で行うことで、プロセスをよりよく理解し、変更を加え、さまざまな環境にデプロイできるようになります。 -## InfluxDBを設定する {#setting-up-influxdb} +## InfluxDBの設定 {#setting-up-influxdb} -まず、InfluxDBをダウンロードしてインストールします。 [Influxdataのリリースページ](https://portal.influxdata.com/downloads/)では、さまざまなダウンロードのオプションが提供されています。 あなたの環境に合わせて選択してください。 また、[リポジトリ](https://repos.influxdata.com/)からインストールすることもできます。 例えば、Debianベースのディストリビューションの場合、以下のように実行します： +まず、InfluxDBをダウンロードしてインストールします。 さまざまなダウンロードオプションは[Influxdataのリリースぺージ](https://portal.influxdata.com/downloads/)で確認できます。 あなたの環境に合わせて選択してください。 +[リポジトリ](https://repos.influxdata.com/)からインストールすることもできます。 例えば、Debianベースのディストリビューションの場合は、以下のようになります: ``` curl -tlsv1.3 --proto =https -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add @@ -48,26 +47,27 @@ sudo systemctl start influxdb sudo apt install influxdb-client ``` -InfluxDB を正常にインストールしたら、バックグラウンドで実行されていることを確認してください。 デフォルトでは、`localhost:8086`からアクセス可能です。 `influx`クライアントを使用する前に、管理者権限を持つ新規ユーザーを作成する必要があります。 管理者ユーザーは、データベースおよびユーザーを作成し、高レベルの管理を行うユーザーです。 +InfluxDB を正常にインストールしたら、バックグラウンドで実行されていることを確認してください。 デフォルトでは、`localhost:8086`でアクセスできます。 +`influx`クライアントを使用する前に、管理者権限を持つ新しいユーザーを作成する必要があります。 このユーザーは、高度な管理、データベースの作成、ユーザーの作成に使用します。 ``` curl -XPOST "http://localhost:8086/query" --data-urlencode "q=CREATE USER username WITH PASSWORD 'password' WITH ALL PRIVILEGES" ``` -管理者ユーザーを作成すると、Influxクライアントから、[InfluxDBシェル](https://docs.influxdata.com/influxdb/v1.8/tools/shell/)にアクセスできるようになります。 +これで、このユーザーで`influx`クライアントを使用して[InfluxDBシェル](https://docs.influxdata.com/influxdb/v1.8/tools/shell/)に入ることができます。 ``` influx -username 'username' -password 'password' ``` -このシェルから InfluxDBと直接やりとりを行うことで、データベースとユーザーを作成し、Gethのモニタリング指標を取得することができます。 +シェル内でInfluxDBと直接通信することで、gethメトリクス用のデータベースとユーザーを作成できます。 ``` create database geth create user geth with password choosepassword ``` -作成したデータベース／ユーザーを、以下で確認します： +作成したエントリを以下で確認します: ``` show databases @@ -80,28 +80,30 @@ InfluxDBシェルを終了します。 exit ``` -InfluxDBはバックグラウンドで実行しており、Gethから送信される数値を保存するように設定されています。 +InfluxDBは実行中で、Gethからのメトリクスを保存するように設定されています。 -## Geth側の設定 {#preparing-geth} +## Gethの準備 {#preparing-geth} -データベースを設定したら、Geth上でのデータ収集を有効化する必要があります。 geth-helpの`geth --help`の`METRICS AND STATS OPTIONS`を確認してください。 複数のオプションが提供されていますが、ここでは、Gethが InfluxDBにデータをプッシュするように設定する必要があります。 基本的な設定では、InfluxDBがリーチ可能なエンドポイントと、当該データベースに対する認証について設定します。 +データベースを設定したら、Gethでのメトリクス収集を有効にする必要があります。 `geth --help`の`METRICS AND STATS OPTIONS`に注意してください。 そこには複数のオプションがありますが、このケースではGethがInfluxDBにデータをプッシュするようにします。 +基本設定では、InfluxDBがアクセスできるエンドポイントと、データベースの認証を指定します。 ``` geth --metrics --metrics.influxdb --metrics.influxdb.endpoint "http://0.0.0.0:8086" --metrics.influxdb.username "geth" --metrics.influxdb.password "chosenpassword" ``` -このフラグは、クライアントを起動するコマンドに追加するか、設定ファイル上で保存することが可能です。 +これらのフラグは、クライアントを起動するコマンドに追加するか、設定ファイルに保存できます。 -データベースに含まれる数値をリストアップするなどの方法で、Gethが実際にデータをプッシュしているかどうかを確認できます。 InfluxDBのシェルで、以下を入力してください： +例えば、データベース内のメトリクスを一覧表示することで、Gethが正常にデータをプッシュしていることを確認できます。 InfluxDBのシェルで、以下を入力してください: ``` use geth show measurements ``` -## Grafanaを設定する {#setting-up-grafana} +## Grafanaの設定 {#setting-up-grafana} -次に、データをグラフィック表示するためにGrafanaをインストールします。 Grafanaのドキュメンテーションを参照して、お使いの環境におけるインストール作業を実行してください。 特別な理由がない限り、OSSバージョンをインストールしてください。 レポジトリを利用してDebianのディストリビューションをインストールするステップは、以下の通りです： +次に、データをグラフィック表示するためにGrafanaをインストールします。 Grafanaのドキュメントで、お使いの環境に合わせたインストールプロセスに従ってください。 特別な理由がない限り、OSSバージョンをインストールしてください。 +リポジトリを使用したDebianディストリビューションへのインストール手順の例: ``` curl -tlsv1.3 --proto =https -sL https://packages.grafana.com/gpg.key | sudo apt-key add - @@ -112,36 +114,38 @@ sudo systemctl enable grafana-server sudo systemctl start grafana-server ``` -Grafanaが実行されている場合、`localhost:3000`でアクセスできるはずです。 お好みのブラウザからこのパスにアクセスして、デフォルトの認証情報（ユーザー：`admin`、パスワード：`admin`）でログインします。 プロンプトが表示されたら、デフォルトのパスワードを変更して保存してください。 +Grafanaが実行されたら、`localhost:3000`でアクセスできるはずです。 +お好みのブラウザでこのパスにアクセスし、デフォルトの認証情報(ユーザー: `admin`、パスワード: `admin`)でログインしてください。 プロンプトが表示されたら、デフォルトのパスワードを変更して保存してください。 ![](./grafana1.png) -Grafanaのホームページに転送されます。 まず、ソースデータを設定します。 左のバーにあるConfigurationアイコンをクリックし、「Data sources」を選択します。 +Grafanaのホームページに転送されます。 まず、ソースデータを設定します。 左のバーにある設定アイコンをクリックし、「Data sources」を選択します。 ![](./grafana2.png) -データソースを作成していないので、「Add data source」をクリックしてデータソースを定義します。 +まだデータソースは作成されていません。「Add data source」をクリックして定義します。 ![](./grafana3.png) -今回の設定では、「InfluxDB」を選択して、次に進みます。 +この設定では、「InfluxDB」を選択して続行します。 ![](./grafana4.png) -同一のマシンでツールを実行している場合、データソースの設定は非常に簡単です。 データベースにアクセスするには、InfluxDBのアドレスと詳細を設定する必要があります。 以下の画像を参照してください。 +同じマシンでツールを実行している場合、データソースの設定は非常に簡単です。 データベースにアクセスするには、InfluxDBのアドレスと詳細を設定する必要があります。 以下の画像を参照してください。 ![](./grafana5.png) -設定が完了し、InfluxDBがアクセス可能になったら、「Save and test」をクリックして、確認のポップアップ画面が表示されるまで待ってください。 +すべてが完了し、InfluxDBにアクセスできるようになったら、「Save and test」をクリックし、確認のポップアップが表示されるのを待ちます。 ![](./grafana6.png) -Grafanaの設定が完了し、InfluxDBのデータを読み込めるようになりました。 次に、データを分析して表示するダッシュボードを作成します。 ダッシュボードの属性はJSONファイルでエンコードされますので、誰でも簡単に作成し、インポートすることが可能です。 左のバーで、「Create and Import」をクリックしてください。 +GrafanaがInfluxDBからデータを読み取るように設定されました。 次に、データを解釈して表示するダッシュボードを作成する必要があります。 ダッシュボードのプロパティはJSONファイルにエンコードされており、誰でも簡単に作成してインポートできます。 左のバーで、「Create and Import」をクリックしてください。 ![](./grafana7.png) -Gethのモニタリング用ダッシュボードの場合、[このダッシュボード](https://grafana.com/grafana/dashboards/13877/)のIDをコピーして、Grafanaの「Import page」にペーストしてください。 ダッシュボードを保存すると、以下のような状態になっているはずです： +Gethのモニタリングダッシュボードには、[このダッシュボード](https://grafana.com/grafana/dashboards/13877/)のIDをコピーして、Grafanaの「Import page」に貼り付けてください。 ダッシュボードを保存すると、次のようになります: ![](./grafana8.png) -ダッシュボードの表示は変更可能です。 各パネルは、編集、移動、削除、追加が可能です。 各自の好みに合わせて、ダッシュボードの設定を変更してください。 あなた次第です！ ダッシュボードの詳細な仕組みについては、 [Grafanaのドキュメンテーション](https://grafana.com/docs/grafana/latest/dashboards/)を参照してください。 また、[アラート機能](https://grafana.com/docs/grafana/latest/alerting/)も参照するとよいでしょう。 これは、各指標において一定の値に達した場合、アラート通知を受け取るように設定するものです。 アラート通知は、様々な通信チャネルに対応しています。 +ダッシュボードは変更できます。 各パネルは、編集、移動、削除、追加が可能です。 設定は変更できます。 あなた次第です！ ダッシュボードの仕組みについて詳しくは、[Grafanaのドキュメント](https://grafana.com/docs/grafana/latest/dashboards/)を参照してください。 +[アラート](https://grafana.com/docs/grafana/latest/alerting/)にも興味があるかもしれません。 これにより、メトリクスが特定の値に達したときにアラート通知を設定できます。 さまざまな通信チャネルがサポートされています。 diff --git a/public/content/translations/ja/developers/tutorials/nft-minter/index.md b/public/content/translations/ja/developers/tutorials/nft-minter/index.md index b54dc60b215..1025b5da7f3 100644 --- a/public/content/translations/ja/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/ja/developers/tutorials/nft-minter/index.md @@ -1,14 +1,16 @@ --- -title: 非代替性トークン(NFT)ミンターチュートリアル -description: このチュートリアルでは、非代替性トークン(NFT)ミンターを構築します。さらに、スマートコントラクトをMetaMaskやWeb3ツールを使用して、Reactフロントエンドへ接続することでフルスタック分散型アプリケーション(Dapp)を作成する方法を学びます。 +title: "非代替性トークン(NFT)ミンターチュートリアル" +description: "このチュートリアルでは、非代替性トークン(NFT)ミンターを構築します。さらに、スマートコントラクトをMetaMaskやWeb3ツールを使用して、Reactフロントエンドへ接続することでフルスタック分散型アプリケーション(Dapp)を作成する方法を学びます。" author: "smudgil" tags: - - "Solidity" - - "NFT" - - "alchemy" - - "スマートコントラクト" - - "フロントエンド" - - "Pinata" + [ + "Solidity", + "NFT", + "Alchemy", + "スマートコントラクト", + "フロントエンド", + "Pinata" + ] skill: intermediate lang: ja published: 2021-10-06 @@ -22,63 +24,63 @@ Web2のバックグラウンドを持つデベロッパーの最大の課題の1 - フロントエンドからスマートコントラクトメソッドを呼び出す - MetaMaskを使用してトランザクションに署名する -このチュートリアルでは、[React](https://reactjs.org/)をフロントエンドフレームワークとして使用します。 このチュートリアルはWeb3開発に焦点を当てているので、Reactの基礎についての説明に多くの時間を費やせません。 代わりに、プロジェクトの機能性を高めることに注力します。 +このチュートリアルでは、[React](https://react.dev/)をフロントエンドフレームワークとして使用します。 このチュートリアルはWeb3開発に焦点を当てているので、Reactの基礎についての説明に多くの時間を費やせません。 代わりに、プロジェクトの機能性を高めることに注力します。 -前提条件として、Reactに関する初級レベルの知識を有している必要があります。つまり、コンポーネント、プロパティ(props)、useStateおよびuseEffect、基本関数の呼び出しなどの仕組みを理解している必要があります。 これらの中に初めて耳にする用語がある場合は、[Reactの入門チュートリアル](https://reactjs.org/tutorial/tutorial.html)をご覧ください。 より視覚的な学習を好む方には、Net Ninjaによる素晴らしい[フルモダンReactチュートリアル](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d)のビデオシリーズをお勧めします。 +前提条件として、Reactに関する初級レベルの知識を有している必要があります。つまり、コンポーネント、プロパティ(props)、useStateおよびuseEffect、基本関数の呼び出しなどの仕組みを理解している必要があります。 これらの用語をこれまで聞いたことがない場合は、こちらの[React入門チュートリアル](https://react.dev/learn/tutorial-tic-tac-toe)をご覧ください。 視覚的な学習を好む方には、Net Ninjaによるこの素晴らしい[フルモダンReactチュートリアル](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d)のビデオシリーズを強くお勧めします。 -まだAlchemyアカウントをお持ちでない場合、このチュートリアルを完了したり、ブロックチェーンで何かを構築したりするために必ず必要になりますので、 [こちらから](https://alchemy.com/)無料アカウントに登録してください。 +まだAlchemyアカウントをお持ちでない場合、このチュートリアルを完了したり、ブロックチェーンで何かを構築したりするために必ず必要になりますので、 [こちら](https://alchemy.com/)から無料アカウントにサインアップしてください。 それでは、さっそく始めましょう！ -## 非代替性トークン(NFT)作成入門 {#making-nfts-101} +## NFT作成の基礎 {#making-nfts-101} コードを見始める前に、非代替性トークン(NFT)作成の仕組みを理解することが重要です。 それには、次の2つのステップがあります。 -### イーサリアムブロックチェーン上で非代替性トークン(NFT)スマートコントラクトを公開 {#publish-nft} +### Ethereumブロックチェーン上にNFTスマートコントラクトを公開する {#publish-nft} ERC-1155とERC-721の2つのスマートコントラクト規格の最大の違いは、ERC-1155はマルチトークン規格でありバッチ機能を備えているのに対し、ERC-721はシングルトークン規格であり一度に1つのトークンの送信しかサポートしていないことです。 -### ミント関数の呼び出し {#minting-function} +### ミント関数を呼び出す {#minting-function} -通常、このミント関数は、パラメータとして2つの変数を渡す必要があります。1つ目は、新しくミントされた非代替性トークン(NFT)を受け取るアドレスを指定する`recipient`です。2つ目は、非代替性トークン(NFT)のメタデータを記述するJSONドキュメントに解決される文字列である非代替性トークン(NFT)の`tokenURI`です。 +通常、このミント関数では、パラメータとして2つの変数を渡す必要があります。1つ目は、新しくミントされたNFTを受け取るアドレスを指定する`recipient`で、2つ目は、NFTのメタデータを記述するJSONドキュメントに解決される文字列であるNFTの`tokenURI`です。 -非代替性トークン(NFT)のメタデータは、非代替性トークン(NFT)に名前、説明、画像(または別のデジタル資産)、その他の属性などのプロパティを持たせ、非代替性トークン(NFT)を利用できるようにします。 非代替性トークン(NFT)のメタデータが含まれている[tokenURIの例](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2)をご覧ください。 +非代替性トークン(NFT)のメタデータは、非代替性トークン(NFT)に名前、説明、画像(または別のデジタル資産)、その他の属性などのプロパティを持たせ、非代替性トークン(NFT)を利用できるようにします。 NFTのメタデータを含む[tokenURIの例](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2)はこちらです。 このチュートリアルでは、React UIを使用して既存の非代替性トークン(NFT)のスマートコントラクトのミント関数を呼び出すパート2(後半)の方に焦点を当てています。 -このチュートリアルで呼び出すERC-721非代替性トークン(NFT)スマートコントラクトへのリンクは、[こちら](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE)です。 この作成方法について知りたい場合は、[非代替性トークン(NFT)の作り方](https://docs.alchemyapi.io/alchemy/tutorials/how-to-create-an-nft)という別のチュートリアルを確認することを強くお勧めします。 +このチュートリアルで呼び出すERC-721 NFTスマートコントラクトへの[リンクはこちら](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE)です。 その作成方法を学びたい場合は、もう一つのチュートリアル["NFTの作成方法"](https://www.alchemy.com/docs/how-to-create-an-nft)をご覧になることを強くお勧めします。 非代替性トークン(NFT)作成の仕組みを理解したところで、スターターファイルをクローンしましょう。 -## スターターファイルのクローン {#clone-the-starter-files} +## スターターファイルをクローンする {#clone-the-starter-files} -最初に、[非代替性トークン(NFT)ミンターチュートリアル(nft-minter-tutorial)のGitHubリポジトリ](https://github.com/alchemyplatform/nft-minter-tutorial)にアクセスし、このプロジェクトのスターターファイルを取得します。 リポジトリをローカル環境にクローンします。 +まず、[nft-minter-tutorialのGitHubリポジトリ](https://github.com/alchemyplatform/nft-minter-tutorial)にアクセスして、このプロジェクトのスターターファイルを入手します。 このリポジトリをローカル環境にクローンします。 -クローンされた`nft-minter-tutorial`リポジトリを開くと、`minter-starter-files`と`nft-minter`という2つのフォルダが含まれています。 +このクローンされた`nft-minter-tutorial`リポジトリを開くと、`minter-starter-files`と`nft-minter`という2つのフォルダが含まれていることがわかります。 -- `minter-starter-files`には、このプロジェクトのスターターファイル(基本的にはReact UI)が含まれています。 このチュートリアルでは、イーサリアムウォレットと非代替性トークン(NFT)スマートコントラクトに接続することで、このUIを利用できるようにする方法を学ぶ際に、**こちらのディレクトリで作業します**。 -- `nft-minter`には、完成したチュートリアル全体が含まれており、**困ったときに****リファレンス**として利用できます。 +- `minter-starter-files`には、このプロジェクトのスターターファイル(本質的にはReactのUI)が含まれています。 このチュートリアルでは、EthereumウォレットとNFTスマートコントラクトに接続してこのUIを有効にする方法を学ぶため、**このディレクトリで作業します**。 +- `nft-minter`には完成したチュートリアル全体が含まれており、行き詰まった場合に**参照**として利用できます。 次に、コードエディタで`minter-starter-files`のコピーを開き、`src`フォルダに移動します。 -これから作成するすべてのコードは、`src`フォルダに保存されます。 後ほど`Minter.js`コンポーネントを編集し、追加のjavascriptファイルを書くことで、このプロジェクトにWeb3機能を追加します。 +私たちが書くコードはすべて`src`フォルダの下に置かれます。 `Minter.js`コンポーネントを編集し、追加のjavascriptファイルを記述して、プロジェクトにWeb3機能を与えます。 -## ステップ2: スターターファイルの確認 {#step-2-check-out-our-starter-files} +## ステップ2: スターターファイルを確認する {#step-2-check-out-our-starter-files} コーディングを始める前に、スターターファイルで既に提供されるものを確認することが重要です。 -### Reactプロジェクトの実行 {#get-your-react-project-running} +### Reactプロジェクトを実行する {#get-your-react-project-running} まずは、ブラウザでReactプロジェクトを実行しましょう。 Reactの素晴らしいところは、一度ブラウザでプロジェクトを実行すると、保存した変更がブラウザでも同時に更新されることです。 -プロジェクトを実行するには、次のようにターミナルで`minter-starter-files`フォルダのルートディレクトリに移動し、`npm install`を実行してプロジェクトの依存関係をインストールします。 +プロジェクトを実行するには、`minter-starter-files`フォルダのルートディレクトリに移動し、ターミナルで`npm install`を実行してプロジェクトの依存関係をインストールします: ```bash cd minter-starter-files npm install ``` -インストールが完了したら、ターミナルで`npm start`を実行します。 +インストールが完了したら、ターミナルで`npm start`を実行します: ```bash npm start @@ -86,18 +88,18 @@ npm start これにより、ブラウザでhttp://localhost:3000/が開き、プロジェクトのフロントエンドが表示されます。 フロントエンドは3つのフィールドで構成されており、それぞれ、非代替性トークン(NFT)資産へのリンク、非代替性トークン(NFT)の名前、非代替性トークン(NFT)の説明を入力する場所になっています。 -「Connect Wallet」や「Mint NFT」ボタンをクリックしても、動作しません。これらの機能は、これからプログラムする必要があります。 :\) +「Connect Wallet」や「Mint NFT」ボタンをクリックしても、動作しません。これらの機能は、これからプログラムする必要があります。 :​) ### Minter.jsコンポーネント {#minter-js} -**注:** `minter-starter-files`フォルダにいることを確認してください。`nft-minter`フォルダではないことを確認します。 +**注:** `nft-minter`フォルダではなく、`minter-starter-files`フォルダにいることを確認してください。 -エディタの`src`フォルダに戻り、`Minter.js`ファイルを開きましょう。 このファイルには、これから作業を進めていく主要なReactコンポーネントが含まれています。すべての内容を理解することが非常に重要です。 +エディタで`src`フォルダに戻り、`Minter.js`ファイルを開きましょう。 このファイルには、これから作業を進めていく主要なReactコンポーネントが含まれています。すべての内容を理解することが非常に重要です。 このファイルの上部には、特定のイベントの後に更新される状態変数(State Variable)があります。 ```javascript -//State variables +//状態変数 const [walletAddress, setWallet] = useState("") const [status, setStatus] = useState("") const [name, setName] = useState("") @@ -105,135 +107,135 @@ const [description, setDescription] = useState("") const [url, setURL] = useState("") ``` -Reactの状態変数や状態フック(State Hook)を聞いたことがない場合は、 [こちらの](https://reactjs.org/docs/hooks-state.html)ドキュメントをご覧ください。 +Reactの状態変数や状態フック(State Hook)を聞いたことがない場合は、 [こちらの](https://legacy.reactjs.org/docs/hooks-state.html)ドキュメントをご覧ください。 それぞれの変数は以下を示します。 - `walletAddress` - ユーザーのウォレットアドレスを格納する文字列 - `status` - UIの下部に表示するメッセージを含む文字列 -- `name` - 非代替性トークン(NFT)の名前を格納する文字列 -- `description` - 非代替性トークン(NFT)の説明を格納する文字列 -- `url` - 非代替性トークン(NFT)のデジタル資産へのリンクを含んだ文字列 +- `name` - NFTの名前を格納する文字列 +- `description` - NFTの説明を格納する文字列 +- `url` - NFTのデジタル資産へのリンクである文字列 -状態変数(State Variable)の後に、`useEffect`、`connectWalletPressed`、`onMintPressed`という3つの未実装の関数があります。 これらの関数は、すべて`async`になっています。これは、それぞれの関数で非同期API呼び出しを行うためです。 それぞれの関数の名前は、その機能を示しています。 +状態変数の後には、`useEffect`、`connectWalletPressed`、`onMintPressed`という3つの未実装の関数があります。 これらの関数はすべて`async`であることにお気づきでしょう。これは、これらの関数内で非同期API呼び出しを行うためです。 それぞれの関数の名前は、その機能を示しています。 ```javascript useEffect(async () => { - //TODO: implement + //TODO: 実装 }, []) const connectWalletPressed = async () => { - //TODO: implement + //TODO: 実装 } const onMintPressed = async () => { - //TODO: implement + //TODO: 実装 } ``` -- [`useEffect`](https://reactjs.org/docs/hooks-effect.html) - コンポーネントがレンダリングされた後に呼び出されるReactフックです。 空の配列`[]`のpropが渡される(3行目を参照)ため、コンポーネントの_最初_のレンダリングでのみ呼び出されます。 ここでは、ウォレットリスナーと別のウォレット関数を呼び出し、ウォレットが接続されているかどうかに応じたUIの更新をします。 -- `connectWalletPressed` - この関数は、ユーザーのMataMaskウォレットを分散型アプリケーション(Dapp)に接続するために呼び出されます。 -- `onMintPressed` - この関数は、ユーザーの非代替性トークン(NFT)をミントするために呼び出されます。 +- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html) - コンポーネントがレンダリングされた後に呼び出されるReactフックです。 空の配列`[]`のpropが渡されるため(3行目を参照)、コンポーネントの_最初の_レンダリングでのみ呼び出されます。 ここでは、ウォレットリスナーと別のウォレット関数を呼び出し、ウォレットが接続されているかどうかに応じたUIの更新をします。 +- `connectWalletPressed` - この関数は、ユーザーのMetaMaskウォレットをdappに接続するために呼び出されます。 +- `onMintPressed` - この関数は、ユーザーのNFTをミントするために呼び出されます。 -このファイルの終盤には、コンポーネントのUIがあります。 このコードを注意深く読んでいくと、状態変数の`url`、`name`、`description`に対応するテキストフィールドの入力が変更された場合、これらの変数を更新していることが分かります。 +このファイルの終盤には、コンポーネントのUIがあります。 このコードを注意深く見ると、対応するテキストフィールドの入力が変更されたときに、`url`、`name`、`description`の状態変数が更新されることがわかります。 -さらに、`walletButton`または`mintButton`というIDを持つボタンがクリックされると、それぞれ`connectWalletPressed`または`onMintPressed`が呼び出されることも分かります。 +また、`mintButton`と`walletButton`のIDを持つボタンがクリックされると、それぞれ`connectWalletPressed`と`onMintPressed`が呼び出されることもわかります。 ```javascript -//the UI of our component +//コンポーネントのUI return (


-

🧙‍♂️ Alchemy NFT Minter

+

🧙‍♂️ Alchemy NFTミンター

- Simply add your asset's link, name, and description, then press "Mint." + アセットのリンク、名前、説明を追加し、「ミント」を押すだけです。

-

🖼 Link to asset:

+

🖼 アセットへのリンク:

setURL(event.target.value)} /> -

🤔 Name:

+

🤔 名前:

setName(event.target.value)} /> -

✍️ Description:

+

✍️ 説明:

setDescription(event.target.value)} />

{status}

-
+ ) ``` 最後に、このミンター(Minter)コンポーネントがどこに加えられるかについて説明します。 -他のすべてのコンポーネントのコンテナとして機能する、Reactのメインコンポーネントである`App.js`ファイルを表示すると、ミンター(Minter)コンポーネントが7行目に挿入されていることが分かります。 +Reactのメインコンポーネントであり、他のすべてのコンポーネントのコンテナとして機能する`App.js`ファイルを見ると、7行目にMinterコンポーネントが挿入されていることがわかります。 -**このチュートリアルでは、`Minter.js`ファイルの編集と、`src`フォルダへのファイルの追加のみを行います。** +**このチュートリアルでは、`Minter.js`ファイルの編集と`src`フォルダへのファイルの追加のみを行います。** これから取り組む内容を理解したところで、イーサリアムウォレットを設定しましょう。 -## イーサリアムウォレットの設定 {#set-up-your-ethereum-wallet} +## Ethereumウォレットを設定する {#set-up-your-ethereum-wallet} ユーザーがスマートコントラクトとやり取りできるようにするには、自分のイーサリアムウォレットを分散型アプリケーション(Dapp)に接続する必要があります。 -### MetaMaskをダウンロード {#download-metamask} +### MetaMaskをダウンロードする {#download-metamask} -このチュートリアルでは、イーサリアムアカウントアドレスを管理するためにブラウザの仮想ウォレットであるMetamaskを使用します。 イーサリアムのトランザクションの仕組みの詳細については、[こちらのページ](/developers/docs/transactions/)をご覧ください。 +このチュートリアルでは、イーサリアムアカウントアドレスを管理するためにブラウザの仮想ウォレットであるMetamaskを使用します。 Ethereumでのトランザクションの仕組みについて詳しく知りたい場合は、[こちらのページ](/developers/docs/transactions/)をご覧ください。 -Metamaskのアカウントは[こちら](https://metamask.io/download)から無料でダウンロード、作成できます。 アカウントを作成後、またはすでにアカウントをお持ちの場合は、(実際に支払いが発生しないように)右上の「Ropsten Test Network」に切り替えてください。 +MetaMaskアカウントは、[こちら](https://metamask.io/download)から無料でダウンロードして作成できます。 アカウントを作成後、またはすでにアカウントをお持ちの場合は、(実際に支払いが発生しないように)右上の「Ropsten Test Network」に切り替えてください。 -### フォーセットからイーサ(ETH)を追加 {#add-ether-from-faucet} +### フォーセットからEtherを追加する {#add-ether-from-faucet} -非代替性トークン(NFT)をミントする(または、イーサリアムのブロックチェーンのトランザクションに署名する)には、偽のETHが必要です。 ETHを取得するには、[Ropstenフォーセット](https://faucet.ropsten.be/)にアクセスして、Ropstenアカウントアドレスを入力し、「Send Ropsten ETH」をクリックします。 MetamaskアカウントにETHが表示されるはずです。 +非代替性トークン(NFT)をミントする(または、イーサリアムのブロックチェーンのトランザクションに署名する)には、偽のETHが必要です。 Ethを取得するには、[Ropstenフォーセット](https://faucet.ropsten.be/)にアクセスしてRopstenのアカウントアドレスを入力し、「Send Ropsten Eth」をクリックします。 MetamaskアカウントにETHが表示されるはずです。 -### 残高の確認 {#check-your-balance} +### 残高を確認する {#check-your-balance} -残高を再確認するために、[Alchemyのコンポーザーツール](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)を使用して[eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)をリクエストしてみましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 MetaMaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 +残高を確認するために、[Alchemyのcomposerツール](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D)を使用して[eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance)リクエストを行いましょう。 このリクエストをすると、ウォレット内のETHの額が返されます。 MetaMaskアカウントアドレスを入力して「Send Request」をクリックすると、次のようなレスポンスが表示されます。 ```text {"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"} ``` -**注:** この結果の単位は、ETHではなくweiです。 weiはETHの最小単位として使われています。 weiからETHへ変換すると、1 eth = 10¹⁸ weiになります。 つまり、0xde0b6b3a7640000を10進数に変換すると、1\*10¹⁸となり、1 ETHに相当します。 +**注:** この結果はethではなくwei単位です。 weiはETHの最小単位として使われています。 weiからETHへ変換すると、1 eth = 10¹⁸ weiになります。 つまり、0xde0b6b3a7640000を10進数に変換すると、1\*10¹⁸となり、1 ETHに相当します。 -ふう! これで、偽のお金を手に入れました。 +ご安心ください。 これで、偽のお金を手に入れました。 -## MetaMaskをUIに接続 {#connect-metamask-to-your-UI} +## MetaMaskをUIに接続する {#connect-metamask-to-your-UI} MetaMaskウォレットが設定されたので、分散型アプリケーション(Dapp)を接続しましょう。 -[モデルビューコントローラ(MVC)](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)パラダイムを実践したいので、別のファイルを作成し、分散型アプリケーション(Dapp)のロジック、データ、ルールを管理する関数を含めます。次に、それらの関数をフロントエンド(Minter.jsコンポーネント)に渡します。 +[MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)パラダイムに従うため、dappのロジック、データ、ルールを管理する関数を含む別のファイルを作成し、それらの関数をフロントエンド(Minter.jsコンポーネント)に渡します。 ### `connectWallet`関数 {#connect-wallet-function} -これを行うには、`src`ディレクトリに`utils`という新しいフォルダを作成して、そこに`interact.js`というファイルを追加します。このファイルには、ウォレットとスマートコントラクトがやり取りする関数がすべて含まれます。 +そのためには、`src`ディレクトリに`utils`という新しいフォルダを作成し、その中に`interact.js`というファイルを追加します。このファイルには、ウォレットとスマートコントラクトのすべての対話関数が含まれます。 -`interact.js`ファイルに`connectWallet`関数を記述し、この関数を`Minter.js`コンポーネントにインポートして呼び出します。 +`interact.js`ファイルに`connectWallet`関数を記述し、それを`Minter.js`コンポーネントでインポートして呼び出します。 -`interact.js`ファイルに以下を追加します。 +`interact.js`ファイルに以下を追加します ```javascript export const connectWallet = async () => { @@ -243,7 +245,7 @@ export const connectWallet = async () => { method: "eth_requestAccounts", }) const obj = { - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 上のテキストフィールドにメッセージを書いてください。", address: addressArray[0], } return obj @@ -261,8 +263,7 @@ export const connectWallet = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + ブラウザに仮想EthereumウォレットであるMetaMaskをインストールする必要があります。

@@ -274,26 +275,26 @@ export const connectWallet = async () => { このコードが何をしているのか見てみましょう。 -まず、ブラウザで`window.ethereum`が有効になっているかどうかを関数がチェックしています。 +まず、この関数はブラウザで`window.ethereum`が有効になっているかどうかをチェックします。 -`window.ethereum`は、MetaMaskおよび他のウォレットプロバイダーによって挿入されるグローバルAPIであり、ウェブサイトがユーザーのイーサリアムアカウントを要求できるようにするものです。 承認されると、ユーザーが接続しているブロックチェーンからデータを読み取ったり、メッセージやトランザクションへの署名をユーザーに提案したりできるようになります。 詳細については、[MetaMaskのドキュメント](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)を参照してください。 +`window.ethereum`は、MetaMaskやその他のウォレットプロバイダーによって挿入されるグローバルAPIで、WebサイトがユーザーのEthereumアカウントを要求できるようにするものです。 承認されると、ユーザーが接続しているブロックチェーンからデータを読み取ったり、メッセージやトランザクションへの署名をユーザーに提案したりできるようになります。 詳細については[MetaMaskのドキュメント](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)をご覧ください。 -`window.ethereum`が_存在しない_場合は、MeTaMaskがインストールされていないことを意味します。 その結果、空の文字列に設定された、返される`address`と、ユーザーがMetaMaskをインストールする必要があることを伝える`status`JSXオブジェクトが入ったJSONオブジェクトが返されます。 +`window.ethereum`が_存在しない_場合、それはMetaMaskがインストールされていないことを意味します。 これにより、返される`address`が空の文字列で、`status` JSXオブジェクトがユーザーにMetaMaskをインストールするよう促すJSONオブジェクトが返されます。 -**これから記述するほとんどの関数は、状態変数(State Variable)とUIの更新に使用できるJSONオブジェクトを返します。** +**私たちが書く関数のほとんどは、状態変数とUIを更新するために使用できるJSONオブジェクトを返します。** -`window.ethereum`が_存在_する場合、興味深いことが起こります。 +さて、`window.ethereum`が_存在する_場合、ここからが面白くなります。 -try/catchループを使用して、`[window.ethereum.request({ method: "eth_requestAccounts" });](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts)`を呼び出すことで、MetaMaskへの接続を試みます。 この関数を呼び出すと、ブラウザでMetaMaskが開き、ユーザーはウォレットを分散型アプリケーション(Dapp)に接続するように求められます。 +try/catchループを使用して、[`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts)を呼び出してMetaMaskへの接続を試みます。 この関数を呼び出すと、ブラウザでMetaMaskが開き、ユーザーはウォレットを分散型アプリケーション(Dapp)に接続するように求められます。 -- ユーザーが接続を選んだ場合、`method: "eth_requestAccounts"`は、分散型アプリケーション(Dapp)に接続されているすべてのユーザーのアカウントアドレスを含む配列を返します。 `connectWallet`関数は、配列内の_最初の_`address`と\(9 行目参照\)、ユーザーにスマートコントラクトにメッセージを書き込むように促す`status`メッセージが入ったJSONオブジェクトを返します。 -- ユーザーが接続を拒否した場合、JSONオブジェクトには、返される`address`に入る空の文字列と、ユーザーが接続を拒否したことを示す`status`メッセージが入ることになります。 +- ユーザーが接続を選択した場合、`method: "eth_requestAccounts"`は、dappに接続されているすべてのユーザーのアカウントアドレスを含む配列を返します。 まとめると、`connectWallet`関数は、この配列の_最初の_`address`（9行目参照）と、ユーザーにスマートコントラクトへのメッセージを書き込むよう促す`status`メッセージを含むJSONオブジェクトを返します。 +- ユーザーが接続を拒否した場合、JSONオブジェクトには返される`address`の空文字列と、ユーザーが接続を拒否したことを示す`status`メッセージが含まれます。 -### Minter.js UIコンポーネントにconnectWallet関数を追加 {#add-connect-wallet} +### connectWallet関数をMinter.js UIコンポーネントに追加する {#add-connect-wallet} -`connectWallet`関数を記述したので、 `Minter.js`コンポーネントに接続しましょう。 +この`connectWallet`関数を書いたので、`Minter.js`コンポーネントに接続しましょう。 -まず、`Minter.js`ファイルの上部に`import { connectWallet } from "./utils/interact.js";`を追加して、`Minter.js`ファイルに関数をインポートする必要があります。 `Minter.js`の最初の11行は、次のようになります。 +まず、`Minter.js`ファイルの先頭に`import { connectWallet } from "./utils/interact.js";`を追加して、この関数を`Minter.js`ファイルにインポートする必要があります。 `Minter.js`の最初の11行は次のようになります。 ```javascript import { useEffect, useState } from "react"; @@ -301,7 +302,7 @@ import { connectWallet } from "./utils/interact.js"; const Minter = (props) => { - //State variables + //状態変数 const [walletAddress, setWallet] = useState(""); const [status, setStatus] = useState(""); const [name, setName] = useState(""); @@ -309,7 +310,7 @@ const Minter = (props) => { const [url, setURL] = useState(""); ``` -次に、`connectWalletPressed`関数の中で、インポートされた`connectWallet`関数を、以下のように呼び出します。 +次に、`connectWalletPressed`関数の中で、インポートした`connectWallet`関数を次のように呼び出します。 ```javascript const connectWalletPressed = async () => { @@ -321,9 +322,9 @@ const connectWalletPressed = async () => { `interact.js`ファイルによって、機能の大部分が`Minter.js`コンポーネントからどのように抽象化されているかに注目してください。 これは、モデルビューコントローラ(M-V-C)パラダイムに準拠しているためです。 -`connectWalletPressed`では、単にインポートされた`connectWallet`関数のawait呼び出しを行っています。さらに、そのレスポンスを使用し、`status`と`walletAddress`変数を状態フックを介して更新しています。 +`connectWalletPressed`では、インポートした`connectWallet`関数をawaitで呼び出し、そのレスポンスを使って状態フックを介して`status`と`walletAddress`変数を更新します。 -それでは、 `Minter.js`と `interact.js`の両方のファイルを保存して、これまでのUIをテストしてみましょう。 +それでは、`Minter.js`と`interact.js`の両方のファイルを保存して、これまでのUIをテストしてみましょう。 localhost:3000でブラウザを開き、ページ右上にある「Connect Wallet」ボタンを押します。 @@ -331,9 +332,9 @@ MetaMaskがインストールされている場合は、ウォレットを分散 ウォレットボタンに、接続した自分のアドレスが表示されているはずです。 -次に、ページを更新してみてください。変ですね。 ウォレットボタンによって、すでに接続しているにもかかわらずMetaMaskに接続するよう求められます。 +次に、ページを再読み込みしてみてください... これは奇妙です。 ウォレットボタンによって、すでに接続しているにもかかわらずMetaMaskに接続するよう求められます。 -でも心配しないでください。 `getCurrentWalletConnected`という関数を実装することで、簡単にこれを修正できます。この関数は、アドレスが分散型アプリケーション(Dapp)にすでに接続されているかどうかを確認し、それに応じてUIを更新します。 +でも心配しないでください。 `getCurrentWalletConnected`という関数を実装することで、これを簡単に修正できます。この関数は、アドレスがすでにdappに接続されているかどうかを確認し、それに応じてUIを更新します。 ### getCurrentWalletConnected関数 {#get-current-wallet} @@ -349,12 +350,12 @@ export const getCurrentWalletConnected = async () => { if (addressArray.length > 0) { return { address: addressArray[0], - status: "👆🏽 Write a message in the text-field above.", + status: "👆🏽 上のテキストフィールドにメッセージを書いてください。", } } else { return { address: "", - status: "🦊 Connect to MetaMask using the top right button.", + status: "🦊 右上のボタンを使ってMetaMaskに接続してください。", } } } catch (err) { @@ -371,8 +372,7 @@ export const getCurrentWalletConnected = async () => {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your - browser. + ブラウザに仮想EthereumウォレットであるMetaMaskをインストールする必要があります。

@@ -382,19 +382,19 @@ export const getCurrentWalletConnected = async () => { } ``` -このコードは、_非常に_前述の`connectWallet`関数に似ています。 +このコードは、先ほど書いた`connectWallet`関数と_非常によく似ています_。 -主な違いとしては、ユーザーがウォレットに接続するためにMetaMaskを開く`eth_requestAccounts`メソッドを呼び出す代わりに、 ここでは`eth_accounts`メソッドを呼び出しています。これは、現在、分散型アプリケーション(Dapp)に接続されているMetaMaskのアドレスを含む配列を単に返すだけです。 +主な違いは、ユーザーがウォレットを接続するためにMetaMaskを開く`eth_requestAccounts`メソッドを呼び出す代わりに、ここでは`eth_accounts`メソッドを呼び出している点です。これは、現在dappに接続されているMetaMaskのアドレスを含む配列を単に返すだけです。 この関数を動作させるため、`Minter.js`コンポーネントの`useEffect`関数で呼び出しましょう。 -`connectWallet`で行ったのと同様に、この関数を`interact.js`ファイルから `Minter.js`ファイルへ次のようにインポートする必要があります。 +`connectWallet`で行ったのと同様に、この関数を`interact.js`ファイルから`Minter.js`ファイルへ次のようにインポートする必要があります。 ```javascript import { useEffect, useState } from "react" import { connectWallet, - getCurrentWalletConnected, //import here + getCurrentWalletConnected, //ここでインポート } from "./utils/interact.js" ``` @@ -408,11 +408,11 @@ useEffect(async () => { }, []) ``` -`walletAddress`状態変数と`status`状態変数を更新するのに、呼び出した`getCurrentWalletConnected`のレスポンスを使用していることに注目してください。 +`walletAddress`と`status`の状態変数を更新するのに、`getCurrentWalletConnected`の呼び出しのレスポンスを使用していることに注目してください。 このコードを追加したら、ブラウザウィンドウを更新してみてください。 リフレッシュ後も、ボタンには接続されていることが示されており、接続されたウォレットのアドレスのプレビューが表示されているはずです。 -### addWalletListenerの実装 {#implement-add-wallet-listener} +### addWalletListenerを実装する {#implement-add-wallet-listener} 分散型アプリケーション(Dapp)ウォレットの設定の最終ステップは、ウォレットリスナーを実装することです。これにより、ユーザーが接続を切断したり、アカウントを切り替えたりした場合など、ウォレットの状態が変更されたときにUIが更新されます。 @@ -424,10 +424,10 @@ function addWalletListener() { window.ethereum.on("accountsChanged", (accounts) => { if (accounts.length > 0) { setWallet(accounts[0]) - setStatus("👆🏽 Write a message in the text-field above.") + setStatus("👆🏽 上のテキストフィールドにメッセージを書いてください。") } else { setWallet("") - setStatus("🦊 Connect to MetaMask using the top right button.") + setStatus("🦊 右上のボタンを使ってMetaMaskに接続してください。") } }) } else { @@ -435,7 +435,7 @@ function addWalletListener() {

{" "} 🦊 - You must install MetaMask, a virtual Ethereum wallet, in your browser. + ブラウザに仮想EthereumウォレットであるMetaMaskをインストールする必要があります。

) @@ -445,9 +445,9 @@ function addWalletListener() { ここで何が起きているか、簡単に見ていきましょう。 -- まず、ブラウザで`window.ethereum`が有効になっているか\(すなわち MetaMaskがインストールされているか\)を関数がチェックしています。 - - 有効になっていない場合、ユーザーにMetaMaskのインストールを求めるJSX文字列を`status`状態変数に設定します。 - - 有効になっている場合、MetaMaskウォレットの状態変更をリッスンしている3行目の`window.ethereum.on("accountsChanged")`リスナーを設定します。この状態変更には、ユーザーが追加のアカウントを分散型アプリケーション(Dapp)に接続した場合、アカウントを切り替えた場合、アカウントを切断した場合が含まれます。 少なくとも1つのアカウントが接続されていれば、`accounts`配列の最初のアカウントがリスナーから返されたときに、`walletAddress`状態変数が更新されます。 それ以外の場合は、`walletAddress`に空の文字列が設定されます。 +- まず、この関数は`window.ethereum`が有効になっているか（つまり、MetaMaskがインストールされているか）をチェックします。 + - 有効でない場合、`status`状態変数を、ユーザーにMetaMaskのインストールを促すJSX文字列に設定するだけです。 + - 有効になっている場合、3行目のリスナー`window.ethereum.on("accountsChanged")`を設定します。これはMetaMaskウォレットの状態変更をリッスンします。これには、ユーザーがdappに追加のアカウントを接続した場合、アカウントを切り替えた場合、アカウントを切断した場合が含まれます。 少なくとも1つのアカウントが接続されていれば、`walletAddress`状態変数は、リスナーから返された`accounts`配列の最初のアカウントとして更新されます。 それ以外の場合、`walletAddress`には空の文字列が設定されます。 最後に、`useEffect`関数で次のように呼び出す必要があります。 @@ -463,11 +463,11 @@ useEffect(async () => { これで完了です。 ウォレットのすべての機能をプログラミングしました。 ウォレットが設定されたので、非代替性トークン(NFT)をミントする方法を理解しましょう! -## 非代替性トークン(NFT)メタデータ入門 {#nft-metadata-101} +## NFTメタデータの基礎 {#nft-metadata-101} このチュートリアルの最初の方で説明した非代替性トークン(NFT)のメタデータを思い出してください。非代替性トークン(NFT)メタデータは、非代替性トークン(NFT)にデジタル資産、名前、説明、その他の属性などのプロパティーを持たせ、非代替性トークン(NFT)を利用できるようにします。 -JSONオブジェクトとしてメタデータを設定し、保存する必要があります。これで、スマートコントラクトの`mintNFT`関数呼び出すときに`tokenURI`パラメータとして渡すことができます。 +このメタデータをJSONオブジェクトとして設定して保存し、スマートコントラクトの`mintNFT`関数を呼び出すときに`tokenURI`パラメータとして渡せるようにする必要があります。 「Link to Asset」、「Name」、「Description」フィールドのテキストは、非代替性トークン(NFT)のメタデータで別々のプロパティになります。 メタデータをJSONオブジェクトとしてフォーマットしますが、このJSONオブジェクトの格納には、以下のような複数のオプションがあります。 @@ -475,25 +475,25 @@ JSONオブジェクトとしてメタデータを設定し、保存する必要 - AWSやFirebaseなどの中央集権型サーバーに保存できます。 しかし、これは分散化の信念に反するものです。 - 惑星間ファイルシステム(IPFS)という、分散型ファイルシステムでデータを保存、共有するための、分散型プロトコルおよびピアツーピア・ネットワークを使用できます。 このプロトコルは、分散化されており無料のため、最良のオプションです。 -惑星間ファイルシステム(IPFS)にメタデータを保存するには、[Pinata](https://pinata.cloud/)という便利な惑星間ファイルシステム(IPFS) APIとツールキットを使用します。 次のステップでは、この方法を具体的に説明します。 +メタデータをIPFSに保存するには、便利なIPFS APIおよびツールキットである[Pinata](https://pinata.cloud/)を使用します。 次のステップでは、この方法を具体的に説明します。 -## Pinataを使用してメタデータをIPFSに固定化 {#use-pinata-to-pin-your-metadata-to-IPFS} +## Pinataを使ってメタデータをIPFSにピン留めする {#use-pinata-to-pin-your-metadata-to-IPFS} -[Pinata](https://pinata.cloud/)アカウントをお持ちでない場合は、[こちら](https://app.pinata.cloud/auth/signup)から無料のアカウントにサインアップし、メールアドレスとアカウントの認証手順を完了してください。 +[Pinata](https://pinata.cloud/)アカウントをお持ちでない場合は、[こちら](https://app.pinata.cloud/auth/signup)から無料アカウントにサインアップし、メールアドレスとアカウントの認証手順を完了してください。 -### Pinata APIキーの作成 {#create-pinata-api-key} +### Pinata APIキーを作成する {#create-pinata-api-key} -[https://pinata.cloud/keys](https://pinata.cloud/keys)ページに移動して、上部にある「New Key」ボタンを選択し、Adminウィジェットを有効(Enabled)に設定してからキーに名前を付けます。 +[https://pinata.cloud/keys](https://pinata.cloud/keys)ページに移動して、上部にある「New Key」ボタンを選択し、Adminウィジェットを有効に設定してからキーに名前を付けます。 API情報を含むポップアップが表示されます。 この情報は、必ず安全な場所に保存してください。 キーの設定が完了したので、プロジェクトに追加して使用できるようにしましょう。 -### .envファイルの作成 {#create-a-env} +### .envファイルを作成する {#create-a-env} -環境ファイルにPinataキーとシークレットを安全に保存できます。 [dotenvパッケージ](https://www.npmjs.com/package/dotenv)をプロジェクトディレクトリにインストールしましょう。 +環境ファイルにPinataキーとシークレットを安全に保存できます。 プロジェクトディレクトリに[dotenvパッケージ](https://www.npmjs.com/package/dotenv)をインストールしましょう。 -ターミナルで\(ローカルホストを実行しているタブとは別の\)新しいタブを開き、`minter-starter-files`フォルダにいることを確認してください。次に、ターミナルで以下のコマンドを実行します。 +ターミナルで新しいタブを開き（ローカルホストを実行しているタブとは別のタブ）、`minter-starter-files`フォルダにいることを確認してから、ターミナルで次のコマンドを実行します。 ```text npm install dotenv --save @@ -505,7 +505,7 @@ npm install dotenv --save vim.env ``` -vim\(テキストエディタ\)で `.env`ファイルが開きます。 保存するには、キーボードで「esc」+「:」+「q」をこの順序で押します。 +これにより、vim（テキストエディタ）で`.env`ファイルが開きます。 保存するには、キーボードで「esc」+「:」+「q」をこの順序で押します。 次に、VSCodeで`.env`ファイルに移動し、次のようにしてPinata APIキーとAPIシークレットを追加します。 @@ -516,11 +516,11 @@ REACT_APP_PINATA_SECRET = ファイルを保存します。これで、JSONメタデータを惑星間ファイルシステム(IPFS)にアップロードする関数を書き始める準備が整いました。 -### pinJSONToIPFSの実装 {#pin-json-to-ipfs} +### pinJSONToIPFSを実装する {#pin-json-to-ipfs} -幸いにもPinataでは、[惑星間ファイルシステム(IPFS)へのJSONデータのアップロードに特化したAPI](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json)と、少しの変更を加えるだけで使用できるaxiosのサンプルを備えた便利なJavaScriptを使用できます。 +幸いにもPinataには、[JSONデータをIPFSにアップロードするための専用API](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json)と、少しの変更で使えるaxiosを使った便利なJavaScriptのサンプルがあります。 -`utils`フォルダーに`pinata.js`という別のファイルを作成し、.envファイルからPinataのシークレットとキーをインポートしましょう。 +`utils`フォルダーに`pinata.js`という別のファイルを作成し、.envファイルからPinataのシークレットとキーを次のようにインポートしましょう。 ```javascript require("dotenv").config() @@ -528,7 +528,7 @@ const key = process.env.REACT_APP_PINATA_KEY const secret = process.env.REACT_APP_PINATA_SECRET ``` -次に、`pinata.js`ファイルに以下の追加コードを貼り付けます。 コードの意味はこれから説明しますので、心配する必要はありません。 +次に、pinata.jsファイルに以下の追加コードを貼り付けます。 コードの意味はこれから説明しますので、心配する必要はありません。 ```javascript require("dotenv").config() @@ -539,7 +539,7 @@ const axios = require("axios") export const pinJSONToIPFS = async (JSONBody) => { const url = `https://api.pinata.cloud/pinning/pinJSONToIPFS` - //making axios POST request to Pinata ⬇️ + //Pinataへのaxios POSTリクエストを作成 ⬇️ return axios .post(url, JSONBody, { headers: { @@ -568,30 +568,30 @@ export const pinJSONToIPFS = async (JSONBody) => { 最初に、ブラウザとnode.jsのためのPromiseベースのHTTPクライアントである[axios](https://www.npmjs.com/package/axios)をインポートしています。axiosは、Pinataへのリクエストで使用します。 -その下に、`pinJSONToIPFS`非同期関数があります。この関数は、`pinJSONToIPFS` APIへのPOSTリクエストを行うために、`JSONBody`を入力として取り、PinataのAPIキーとシークレットをヘッダーに入れます。 +その下に、`pinJSONToIPFS`非同期関数があります。この関数は、`JSONBody`を入力として取り、PinataのAPIキーとシークレットをヘッダーに入れて、`pinJSONToIPFS` APIへのPOSTリクエストを行います。 -- POSTリクエストが成功した場合、この関数は、trueに設定された`success`ブール値と、メタデータがピン留めされた`pinataUrl`が入ったJSONオブジェクトを返します。 ここで返された`pinataUrl`は、スマートコントラクトのmint関数の`tokenURI`の入力として使用されます。 -- POSTリクエストが失敗した場合、この関数は、falseに設定された`success`ブール値と、エラーを伝える`message`文字列が入ったJSONオブジェクトを返します。 +- このPOSTリクエストが成功した場合、この関数は、`success`ブール値がtrueで、メタデータがピン留めされた`pinataUrl`が入ったJSONオブジェクトを返します。 ここで返された`pinataUrl`は、スマートコントラクトのmint関数の`tokenURI`の入力として使用されます。 +- このPOSTリクエストが失敗した場合、この関数は、`success`ブール値がfalseで、エラーを伝える`message`文字列が入ったJSONオブジェクトを返します。 `connectWallet`関数の戻り値の型と同様に、JSONオブジェクトが返されるので、そのパラメータを状態変数とUIの更新に使用できます。 -## スマートコントラクトのロード {#load-your-smart-contract} +## スマートコントラクトを読み込む {#load-your-smart-contract} -これで、`pinJSONToIPFS`関数を介して非代替性トークン(NFT)メタデータを惑星間ファイルシステム(IPFS)にアップロードする手段を手に入れました。次は、`mintNFT`関数を呼び出せるように、スマートコントラクトのインスタンスをロードする手段が必要です。 +`pinJSONToIPFS`関数を介してNFTメタデータをIPFSにアップロードする手段を手に入れたので、次は`mintNFT`関数を呼び出せるように、スマートコントラクトのインスタンスを読み込む手段が必要です。 -前述したように、このチュートリアルでは、[こちらの既存の非代替性トークン(NFT)スマートコントラクト](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE)を使用します。ただし、この作成方法を学びたい、もしくは自分で作成したい場合は、[「非代替性トークン(NFT)の作り方」](https://docs.alchemyapi.io/alchemy/tutorials/how-to-create-an-nft)という別のチュートリアルを確認することを強くお勧めします。 +前述したように、このチュートリアルでは[こちらの既存のNFTスマートコントラクト](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE)を使用します。しかし、その作成方法を学びたい、もしくは自分で作成したい場合は、もう一つのチュートリアル["NFTの作成方法"](https://www.alchemy.com/docs/how-to-create-an-nft)をご覧になることを強くお勧めします。 -### コントラクトアプリケーションバイナリインターフェース(ABI) {#contract-abi} +### コントラクトABI {#contract-abi} ファイルを詳しく調べてみると、`src`ディレクトリに`contract-abi.json`ファイルがあることが分かります。 アプリケーションバイナリインターフェース(ABI)は、コントラクトが呼び出す関数を指定し、関数が確実に意図しているフォーマットでデータを返すようにするために必要です。 さらに、イーサリアムブロックチェーンに接続してスマートコントラクトをロードするための、Alchemy APIキーとAlchemy Web3 APIも必要になります。 -### Alchemy APIキーの作成 {#create-alchemy-api} +### Alchemy APIキーを作成する {#create-alchemy-api} -Alchemyのアカウントをお持ちでない場合は、[こちら](https://alchemy.com/?a=eth-org-nft-minter)から無料で登録できます。 +まだAlchemyアカウントをお持ちでない場合は、[こちらから無料でサインアップしてください](https://alchemy.com/?a=eth-org-nft-minter)。 -Alchemyのアカウントを作成した後、アプリを作成することでAPIキーを生成することができます。 これにより、Ropstenテストネットワークへのリクエストが可能になります。 +Alchemyのアカウントを作成した後、アプリを作成することでAPIキーを生成することができます。 これにより、Ropsten テストネットワークへのリクエストが可能になります。 ナビゲーションバーの「Apps」にマウスを合わせて、「Create App」をクリックし、Alchemyダッシュボードの「Create App」ページに移動してください。 @@ -601,7 +601,7 @@ Alchemyのアカウントを作成した後、アプリを作成することでA HTTP Alchemy API URLを作成したので、クリップボードにコピーします。 -それを`.env`ファイルに追加してみましょう。 これで.envファイル全体は、次のようになります。 +…そして、それを`.env`ファイルに追加しましょう。 これで.envファイル全体は、次のようになります。 ```text REACT_APP_PINATA_KEY = @@ -609,11 +609,11 @@ REACT_APP_PINATA_SECRET = REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/ ``` -コントラクトアプリケーションバイナリインターフェース(ABI)とAlchemy APIキーが用意できたので、[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)を使用してスマートコントラクトをロードする準備ができました。 +コントラクトABIとAlchemy APIキーが用意できたので、[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)を使用してスマートコントラクトを読み込む準備ができました。 -### Alchemy Web3エンドポイントとコントラクトの設定 {#setup-alchemy-endpoint} +### Alchemy Web3エンドポイントとコントラクトを設定する {#setup-alchemy-endpoint} -まず、[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)がインストールされていない場合は、ターミナルで次のようにホームディレクトリである`nft-minter-tutorial`に移動してインストールする必要があります。 +まず、[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)がまだインストールされていない場合は、ターミナルでホームディレクトリ`nft-minter-tutorial`に移動してインストールする必要があります: ```text cd .. @@ -629,7 +629,7 @@ const { createAlchemyWeb3 } = require("@alch/alchemy-web3") const web3 = createAlchemyWeb3(alchemyKey) ``` -[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)は、[Web3.js](https://docs.web3js.org/)のラッパーであり、強化されたAPIメソッドや重要なメリットを提供し、Web3デベロッパーの負担を軽減します。 最小限の設定で使えるように設計されているので、アプリですぐに使用可能です。 +[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3)は[Web3.js](https://docs.web3js.org/)のラッパーであり、強化されたAPIメソッドやその他の重要なメリットを提供し、web3開発者としての作業を容易にします。 最小限の設定で使えるように設計されているので、アプリですぐに使用可能です。 次に、コントラクトアプリケーションバイナリインターフェース(ABI)とコントラクトアドレスをファイルに追加しましょう。 @@ -645,9 +645,9 @@ const contractAddress = "0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE" これで両方を追加できたので、mint関数のコーディングを始める準備ができました。 -## mintNFT関数の実装 {#implement-the-mintnft-function} +## mintNFT関数を実装する {#implement-the-mintnft-function} -`interact.js`ファイル内に、`mintNFT`関数を定義しましょう。この関数は、名前が示すとおりに非代替性トークン(NFT)をミントします。 +`interact.js`ファイル内に、`mintNFT`関数を定義しましょう。この関数は、その名の通りNFTをミントします。 多数の非同期呼び出しを\(メタデータをIPFSにピン留めするためにPinataに対して、スマートコントラクトをロードするためにAlchemy Web3に対して、トランザクションに署名するためにMetaMaskに対して\)行うため、この関数もまた非同期になります。 @@ -663,21 +663,21 @@ export const mintNFT = async (url, name, description) => {} ```javascript export const mintNFT = async (url, name, description) => { - //error handling + //エラー処理 if (url.trim() == "" || name.trim() == "" || description.trim() == "") { return { success: false, - status: "❗Please make sure all fields are completed before minting.", + status: "❗ミントする前にすべてのフィールドに入力してください。", } } } ``` -基本的に、入力パラメーターのいずれかが空の文字列である場合、falseに設定された`success`ブール値と、UIのすべてのフィールドに入力する必要があることを伝える`status`文字列が入ったJSONオブジェクトを返します。 +基本的に、入力パラメータのいずれかが空の文字列である場合、`success`ブール値がfalseで、UIのすべてのフィールドに入力する必要があることを伝える`status`文字列が入ったJSONオブジェクトを返します。 -### IPFSにメタデータをアップロード {#upload-metadata-to-ipfs} +### メタデータをIPFSにアップロードする {#upload-metadata-to-ipfs} -メタデータが適切にフォーマットされていることを確認したら、次のステップは、それをJSONオブジェクトにラップし、作成した`pinJSONToIPFS`を介して惑星間ファイルシステム(IPFS)にアップロードすることです。 +メタデータが適切にフォーマットされていることを確認したら、次のステップは、それをJSONオブジェクトにラップし、作成した`pinJSONToIPFS`を介してIPFSにアップロードすることです。 そのためにはまず、`pinJSONToIPFS`関数を`interact.js`ファイルにインポートする必要があります。 `interact.js`の最上部に、次の行を追加してください。 @@ -685,32 +685,32 @@ export const mintNFT = async (url, name, description) => { import { pinJSONToIPFS } from "./pinata.js" ``` -`pinJSONToIPFS`が、JSON本体を取ることを思い出してください。 そのため、呼び出す前に`url`、`name`、`description`パラメータをJSONオブジェクトにフォーマットする必要があります。 +`pinJSONToIPFS`がJSON本体を入力として取ることを思い出してください。 そのため、呼び出す前に`url`、`name`、`description`パラメータをJSONオブジェクトにフォーマットする必要があります。 次のようにコードを更新して、`metadata`というJSONオブジェクトを作成し、この`metadata`パラメータを使用して`pinJSONToIPFS`を呼び出します。 ```javascript export const mintNFT = async (url, name, description) => { - //error handling + //エラー処理 if (url.trim() == "" || name.trim() == "" || description.trim() == "") { return { success: false, - status: "❗Please make sure all fields are completed before minting.", + status: "❗ミントする前にすべてのフィールドに入力してください。", } } - //make metadata + //メタデータを作成 const metadata = new Object() metadata.name = name metadata.image = url metadata.description = description - //make pinata call + //pinata呼び出しを作成 const pinataResponse = await pinJSONToIPFS(metadata) if (!pinataResponse.success) { return { success: false, - status: "😢 Something went wrong while uploading your tokenURI.", + status: "😢 tokenURIのアップロード中に問題が発生しました。", } } const tokenURI = pinataResponse.pinataUrl @@ -719,7 +719,7 @@ export const mintNFT = async (url, name, description) => { `pinJSONToIPFS(metadata)`の呼び出しのレスポンスを、`pinataResponse`オブジェクトに格納していることに注目してください。 次に、このオブジェクトにエラーがないか解析します。 -エラーがある場合、falseに設定された`success`ブール値と、呼び出しが失敗したことを伝える`status`文字列が入ったJSONオブジェクトを返します。 それ以外の場合は、`pinataURL`を`pinataResponse`から抽出し、それを`tokenURI`変数として格納します。 +エラーがある場合、`success`ブール値がfalseで、呼び出しが失敗したことを伝える`status`文字列が入ったJSONオブジェクトを返します。 それ以外の場合は、`pinataURL`を`pinataResponse`から抽出し、それを`tokenURI`変数として格納します。 では、ファイルの先頭で初期化したAlchemy Web3 APIを使用して、スマートコントラクトをロードしてみましょう。 `mintNFT`関数の下部に次のコードの行を追加して、`window.contract`グローバル変数にコントラクトを設定します。 @@ -727,19 +727,19 @@ export const mintNFT = async (url, name, description) => { window.contract = await new web3.eth.Contract(contractABI, contractAddress) ``` -`mintNFT`関数に最後に追加するのは、イーサリアムのトランザクションです。 +`mintNFT`関数に最後に追加するのは、Ethereumのトランザクションです。 ```javascript -//set up your Ethereum transaction +//Ethereumトランザクションを設定 const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: window.ethereum.selectedAddress, // must match user's active address. + to: contractAddress, // コントラクト公開時以外は必須 + from: window.ethereum.selectedAddress, // ユーザーのアクティブなアドレスと一致する必要あり data: window.contract.methods .mintNFT(window.ethereum.selectedAddress, tokenURI) - .encodeABI(), //make call to NFT smart contract + .encodeABI(), //NFTスマートコントラクトを呼び出し } -//sign the transaction via MetaMask +//MetaMask経由でトランザクションに署名 try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -748,13 +748,13 @@ try { return { success: true, status: - "✅ Check out your transaction on Etherscan: https://ropsten.etherscan.io/tx/" + + "✅ Etherscanでトランザクションを確認: https://ropsten.etherscan.io/tx/" + txHash, } } catch (error) { return { success: false, - status: "😥 Something went wrong: " + error.message, + status: "😥 問題が発生しました: " + error.message, } } ``` @@ -762,54 +762,54 @@ try { イーサリアムトランザクションをすでによくご存知ならば、構造が今まで見てきたものとかなり似ていることに気付くでしょう。 - まず、トランザクションパラメータを設定します。 - - `to`に受取人のアドレス\(スマートコントラクト\)を設定します 。 - - `from`にトランザクションの署名者\(MetaMaskに接続されているユーザーのアドレス: `window.ethereum.selectedAddress`\)を指定します。 - - `data`には、スマートコントラクトの`mintNFT`メソッド呼び出しが含まれ、`tokenURI`とユーザーのウォレットのアドレス`window.ethereum.selectedAddress`を入力として受け取ります。 -- 次に、`window.ethereum.request`をawaitで呼び出して、MetaMaskにトランザクションの署名を依頼します。 このリクエストで、ethメソッド\(eth_sendTransaction\)を指定し、`transactionParameters`を渡していることに注目してください。 この時点で、ブラウザでMetaMaskが開かれ、ユーザーにトランザクションの署名または拒否を求めます。 - - トランザクションが成功した場合、この関数は、trueに設定された`success`ブール値と、Etherscanでトランザクションについての詳細を確認するようユーザーに求める`status`文字列が入ったJSONオブジェクトを返します。 - - トランザクションが失敗した場合、この関数は、falseに設定された`success`ブール値と、エラーメッセージを伝える`status`文字列が入ったJSONオブジェクトを返します。 + - `to`は受信者アドレス（スマートコントラクト）を指定します + - `from`はトランザクションの署名者を指定します（ユーザーのMetaMaskに接続されたアドレス: `window.ethereum.selectedAddress`） + - `data`には、スマートコントラクトの`mintNFT`メソッドへの呼び出しが含まれ、入力として`tokenURI`とユーザーのウォレットアドレス`window.ethereum.selectedAddress`を受け取ります +- 次に、`window.ethereum.request`をawaitで呼び出して、MetaMaskにトランザクションの署名を依頼します。 このリクエストで、ethメソッド（`eth_sendTransaction`）を指定し、`transactionParameters`を渡していることに注目してください。 この時点で、ブラウザでMetaMaskが開かれ、ユーザーにトランザクションの署名または拒否を求めます。 + - トランザクションが成功した場合、この関数は、ブール値`success`がtrueに設定され、`status`文字列がユーザーにトランザクションの詳細についてEtherscanを確認するよう促すJSONオブジェクトを返します。 + - トランザクションが失敗した場合、この関数は、`success`ブール値がfalseに設定され、`status`文字列がエラーメッセージを伝えるJSONオブジェクトを返します。 `mintNFT`関数全体は、次のようになります。 ```javascript export const mintNFT = async (url, name, description) => { - //error handling + //エラー処理 if (url.trim() == "" || name.trim() == "" || description.trim() == "") { return { success: false, - status: "❗Please make sure all fields are completed before minting.", + status: "❗ミントする前にすべてのフィールドに入力してください。", } } - //make metadata + //メタデータを作成 const metadata = new Object() metadata.name = name metadata.image = url metadata.description = description - //pinata pin request + //pinataピン留めリクエスト const pinataResponse = await pinJSONToIPFS(metadata) if (!pinataResponse.success) { return { success: false, - status: "😢 Something went wrong while uploading your tokenURI.", + status: "😢 tokenURIのアップロード中に問題が発生しました。", } } const tokenURI = pinataResponse.pinataUrl - //load smart contract + //スマートコントラクトを読み込む window.contract = await new web3.eth.Contract(contractABI, contractAddress) //loadContract(); - //set up your Ethereum transaction + //Ethereumトランザクションを設定 const transactionParameters = { - to: contractAddress, // Required except during contract publications. - from: window.ethereum.selectedAddress, // must match user's active address. + to: contractAddress, // コントラクト公開時以外は必須 + from: window.ethereum.selectedAddress, // ユーザーのアクティブなアドレスと一致する必要あり data: window.contract.methods .mintNFT(window.ethereum.selectedAddress, tokenURI) - .encodeABI(), //make call to NFT smart contract + .encodeABI(), //NFTスマートコントラクトを呼び出す } - //sign transaction via MetaMask + //MetaMask経由でトランザクションに署名 try { const txHash = await window.ethereum.request({ method: "eth_sendTransaction", @@ -818,13 +818,13 @@ export const mintNFT = async (url, name, description) => { return { success: true, status: - "✅ Check out your transaction on Etherscan: https://ropsten.etherscan.io/tx/" + + "✅ Etherscanでトランザクションを確認: https://ropsten.etherscan.io/tx/" + txHash, } } catch (error) { return { success: false, - status: "😥 Something went wrong: " + error.message, + status: "😥 問題が発生しました: " + error.message, } } } @@ -832,7 +832,7 @@ export const mintNFT = async (url, name, description) => { 巨大な関数でしたね! あとは、`mintNFT`関数を`Minter.js`コンポーネントに接続するだけです。 -## mintNFTをMinter.jsフロントエンドに接続 {#connect-our-frontend} +## mintNFTをMinter.jsフロントエンドに接続する {#connect-our-frontend} `Minter.js`ファイルを開いて、上部の`import { connectWallet, getCurrentWalletConnected } from "./utils/interact.js";`の行を次のように更新してください。 @@ -844,7 +844,7 @@ import { } from "./utils/interact.js" ``` -最後に、次のように`onMintPressed`関数を実装し、インポートした`mintNFT`関数をawaitで呼び出します。さらに、`status`状態変数を更新し、トランザクションが成功したか失敗したかを反映させるようにします。 +最後に、`onMintPressed`関数を実装してインポートした`mintNFT`関数をawaitで呼び出し、`status`状態変数を更新してトランザクションが成功したか失敗したかを反映させます。 ```javascript const onMintPressed = async () => { @@ -853,22 +853,22 @@ const onMintPressed = async () => { } ``` -## 稼働中のウェブサイトに非代替性トークン(NFT)をデプロイ {#deploy-your-NFT} +## NFTを稼働中のWebサイトにデプロイする {#deploy-your-NFT} -プロジェクトを稼働させてユーザーが使える準備ができましたでしょうか？ 稼働しているウェブサイトへMinterをデプロイする[チュートリアル](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online)をご覧ください。 +プロジェクトを稼働させてユーザーが使える準備ができましたでしょうか？ ミンターを稼働中のWebサイトにデプロイする方法については、[こちらのチュートリアル](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online)をご覧ください。 次は最後のステップです。 -## ブロックチェーンの世界を席巻しよう! {#take-the-blockchain-world-by-storm} +## ブロックチェーンの世界に旋風を巻き起こす {#take-the-blockchain-world-by-storm} これは冗談です。あなたは、このチュートリアルを最後までやりきりました! 要約すると、非代替性トークン(NFT)ミンターを構築することで次の方法を学ぶことが出来ました。 -- フロントエンドのプロジェクト経由でMetaMaskへアクセス -- フロントエンドからスマートコントラクトメソッドの呼び出し -- MetaMaskを使ったトランザクションの署名 +- フロントエンドのプロジェクト経由でMetaMaskに接続する +- フロントエンドからスマートコントラクトメソッドを呼び出す +- MetaMaskを使用してトランザクションに署名する -ウォレットに分散型アプリケーション(Dapp)を介してミントされた非代替性トークン(NFT)を表示する方法については、[ウォレットに非代替性トークン(NFT)を表示する方法](https://docs.alchemyapi.io/alchemy/tutorials/how-to-write-and-deploy-a-nft-smart-contract/how-to-view-your-nft-in-your-wallet)という簡単なチュートリアルをご覧ください。 +おそらく、dappを介してミントされたNFTをウォレットで披露したいと思うでしょうから、簡単なチュートリアル[ウォレットでNFTを表示する方法](https://www.alchemy.com/docs/how-to-view-your-nft-in-your-mobile-wallet)をぜひご覧ください。 -ご不明な点がありましたら、いつでも[Alchemy Discord](https://discord.gg/gWuC7zB)でお問い合わせください。 このチュートリアルのコンセプトが、今後のプロジェクトでどのように応用されるのか楽しみでなりません。 +そして、いつものように、何か質問があれば、[Alchemy Discord](https://discord.gg/gWuC7zB)でお手伝いします。 このチュートリアルのコンセプトが、今後のプロジェクトでどのように応用されるのか楽しみでなりません。 diff --git a/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md index d1b9c3ffae4..4388b37ec0b 100644 --- a/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -1,84 +1,89 @@ --- -title: "Optimismの標準ブリッジコントラクトを紹介します" -description: Optimismの標準ブリッジは、どのように機能するか。 および、その理由。 +title: "Optimism標準ブリッジコントラクトのウォークスルー" +description: "Optimismの標準ブリッジはどのように機能するのでしょうか？ なぜこのように機能するのでしょうか？" author: Ori Pomerantz -tags: - - "Solidity" - - "ブリッジ" - - "レイヤー2" +tags: [ "Solidity", "ブリッジ", "レイヤー2" ] skill: intermediate published: 2022-03-30 lang: ja --- -[Optimism](https://www.optimism.io/)は、[Optimisitc ロールアップ](/developers/docs/scaling/optimistic-rollups/)を行うメカニズムのひとつです。 Optimistic ロールアップでは、ネットワークに含まれるすべてノードではなく一部のノードのみを対象としてトランザクションが処理されるため、イーサリアム・メインネット（「レイヤー1」または「L1」とも呼ばれます）よりも手数料が低くなります。 一部のノードのみを対象として処理されるものの、すべてのデータはL1に書き込まれるため、あらゆる事項につき、メインネットにおける完全性および可用性についての保証に基づいて証明、再構築することが可能です。 +[Optimism](https://www.optimism.io/)は[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups/)です。 +オプティミスティック・ロールアップは、ネットワーク上のすべてのノードではなく一部のノードのみでトランザクションが処理されるため、イーサリアムメインネット(レイヤー1またはL1とも呼ばれる)よりもはるかに低い価格でトランザクションを処理できます。 +同時に、すべてのデータがL1に書き込まれるため、メインネットの完全性と可用性の保証の元で、すべてを証明、再構築することが可能です。 -Optimism（またはその他のL2）上でL1のアセットを使用するには、当該アセットを[ブリッジ](/bridges/#prerequisites)する必要があります。 アセットをブリッジする方法のひとつとして、アセット（最も一般的なのは、ETHや[ERC-20 トークン](/developers/docs/standards/tokens/erc-20/)です）をL1上でロックし、L2上で同等のアセットを受け取る方法があります。 最終的に、これらのアセットを所持するユーザーは、再度L1にブリッジする必要があるでしょう。 L1にアセットをブリッジすると、L2上のアセットはバーンされ、L1上のアセットがユーザーに戻されます。 +Optimism（またはその他のL2）でL1アセットを使用するには、アセットを[ブリッジ](/bridges/#prerequisites)する必要があります。 +これを実現する一つの方法は、ユーザーがL1でアセット(最も一般的なのはETHと[ERC-20トークン](/developers/docs/standards/tokens/erc-20/)です)をロックし、L2で使用する同等のアセットを受け取ることです。 +最終的に、それらのアセットを手にした人は、L1にブリッジして戻したいと思うかもしれません。 +このとき、L2のアセットはバーンされ、L1でユーザーに返還されます。 -以上が、[Optimismにおける標準ブリッジ](https://docs.optimism.io/app-developers/bridging/standard-bridge)の仕組みです。 この記事では、このブリッジ機能についてSolidity上で適切に作成したソースコードを確認しながら、その仕組みを学びます。 +これが、[Optimism標準ブリッジ](https://docs.optimism.io/app-developers/bridging/standard-bridge)の仕組みです。 +この記事では、そのブリッジのソースコードをレビューし、その仕組みを確認し、適切に記述されたSolidityコードの例として学習します。 ## 制御フロー {#control-flows} -ブリッジは、2つのメインフローで構成されます： +ブリッジには、2つの主要なフローがあります: -- L1からL2への入金 -- L2からL1への出金 +- デポジット (L1からL2へ) +- 引き出し (L2からL1へ) -### 入金フロー {#deposit-flow} +### デポジットフロー {#deposit-flow} -#### L1 {#deposit-flow-layer-1} +#### レイヤー1 {#deposit-flow-layer-1} -1. ERC-20を入金する場合、入金者はブリッジに対し、入金額を使用するためのアローワンスを与えます。 -2. 入金者は、L1ブリッジ（`depositERC20`、`depositERC20To`、 `depositETH`あるいは `depositETHTo`）を呼び出します。 -3. L1ブリッジが、ブリッジされたアセットを保持します。 - - ETHの場合：アセットは、呼び出しを通じて入金者に送信されます。 - - ERC-20トークンの場合：アセットは、入金者が提供するアローワンスを使用して、ブリッジ自体に送信されます。 -4. L1のブリッジが、クロスドメインのメッセージメカニズムを通じて、L2のブリッジ上で`finalizeDeposit`を呼び出します。 +1. ERC-20をデポジットする場合、デポジットする人は、デポジットされる金額を使用する権限をブリッジに与えます。 +2. デポジットする人はL1ブリッジを呼び出します(`depositERC20`、`depositERC20To`、`depositETH`、または`depositETHTo`) +3. L1ブリッジは、ブリッジされた資産の所有権を取得します。 + - ETH: アセットは呼び出しの一部として、デポジットする人によって転送されます。 + - ERC-20: アセットは、デポジットする人から提供された権限を使用して、ブリッジによってそれ自体に転送されます。 +4. L1ブリッジは、クロスドメインメッセージメカニズムを使用して、L2ブリッジの`finalizeDeposit`を呼び出します。 -#### L2 {#deposit-flow-layer-2} +#### レイヤー2 {#deposit-flow-layer-2} -5. L2のブリッジは、`finalizeDeposit`の呼び出しにつき、以下が適切であることを確認します： - - クロスドメインのメッセージ・コントラクトからの呼び出しであること。 - - ブリッジがL1上で作成されたものであること。 -6. L2のブリッジはさらに、L2上のERC-20トークンコントラクトにつき、以下が適切であることを確認します： - - L2のコントラクトにおいて、L1における対応するコントラクトが、L1上で送信されたトークンと同一であると報告していること。 - - L2のコントラクトが、（[ERC-165を使用した](https://eips.ethereum.org/EIPS/eip-165)）適切なインターフェイスをサポートすると報告していること。 -7. L2のコントラクトが適切であると確認できた場合は、適切なアドレスに対して希望する量のトークンをミントするために、そのコントラクトを呼び出してください。 そうでない場合は、出金プロセスを開始して、ユーザーがL1上のトークンを請求できるようにします。 +5. L2ブリッジは`finalizeDeposit`への呼び出しが正当なものであることを検証します: + - クロスドメインメッセージコントラクトからの呼び出しであること + - もともとL1のブリッジからの呼び出しであること +6. L2ブリッジは、L2上のERC-20トークンコントラクトが正しいものであるかを確認します: + - L2コントラクトは、そのL1の対応物がL1から来たトークンと同じものであることを報告します。 + - L2コントラクトは正しいインターフェースをサポートしていることを報告します([ERC-165を使用](https://eips.ethereum.org/EIPS/eip-165))。 +7. L2コントラクトが正しい場合、それを呼び出して適切な数のトークンを適切なアドレスにミントします。 そうでない場合、ユーザーがL1でトークンを要求できるように、引き出しプロセスを開始します。 -### 出金フロー {#withdrawal-flow} +### 引き出しフロー {#withdrawal-flow} #### レイヤー2 {#withdrawal-flow-layer-2} -1. 出金者は、L2のブリッジ（`withdraw`または`withdrawTo`）を呼び出します 。 -2. L2のブリッジは、`msg.sender`が所有する適切な数のトークンをバーンします。 -3. L2のブリッジは、クロスドメインのメッセージ・メカニズムを利用して、L1のブリッジ上で、 `finalizeETHWithdrawal`または`finalizeERC20Withdrawal`を呼び出します。 +1. 引き出す人はL2ブリッジを呼び出します(`withdraw`または`withdrawTo`) +2. L2ブリッジは、`msg.sender`に属する適切な数のトークンをバーンします。 +3. L2ブリッジは、クロスドメインメッセージメカニズムを使用して、L1ブリッジで`finalizeETHWithdrawal`または`finalizeERC20Withdrawal`を呼び出します。 -#### L1 {#withdrawal-flow-layer-1} +#### レイヤー1 {#withdrawal-flow-layer-1} -4. L1のブリッジは、`finalizeETHWithdraw`または`finalizeERC20Withdral`の呼び出しにつき、以下が適切であるかを確認します： - - クロスドメインのメッセージ・メカニズムを経由していること。 - - L2のブリッジで作成されていること。 -5. L1のブリッジは、適切な資産（ETHまたはERC-20）を適切なアドレスに送信します。 +4. L1ブリッジは、`finalizeETHWithdrawal`または`finalizeERC20Withdrawal`への呼び出しが正当であることを検証します: + - クロスドメインメッセージメカニズムからの呼び出しであること + - もともとL2のブリッジからの呼び出しであること +5. L1ブリッジは、適切な資産(ETHまたはERC-20)を適切なアドレスに転送します。 -## レイヤー1のコード {#layer-1-code} +## レイヤー1コード {#layer-1-code} -以下は、イーサリアム・メインネット（L1）で実行されるコードです。 +これは、L1であるイーサリアムメインネットで実行されるコードです。 ### IL1ERC20Bridge {#IL1ERC20Bridge} -このインターフェイスは、[こちら](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol)で定義されています。 このインターフェイスには、ERC-20トークンをブリッジするために必要な機能と定義が含まれます。 +[このインターフェースはここで定義されています](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol)。 +これには、ERC-20トークンのブリッジングに必要な関数と定義が含まれています。 ```solidity // SPDX-License-Identifier: MIT ``` -Optimismのコードの大部分は、[MITライセンス](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-)に基づいています。 +[OptimismのコードのほとんどはMITライセンスの下でリリースされています](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-)。 ```solidity pragma solidity >0.5.0 <0.9.0; ``` -本記事の執筆時点で、Solidityの最新バージョンは0.8.12です。 バージョン0.9.0においてこのコードが利用できるかは、同バージョンがリリースされるまで不明です。 +執筆時点で、Solidityの最新バージョンは0.8.12です。 +バージョン0.9.0がリリースされるまで、このコードに互換性があるかどうかはわかりません。 ```solidity /** @@ -86,20 +91,23 @@ pragma solidity >0.5.0 <0.9.0; */ interface IL1ERC20Bridge { /********** - * Events * + * イベント * **********/ event ERC20DepositInitiated( ``` -Optimismのブリッジ関連用語において、_入金_とは、L1からL2に送金することを意味し、_出金_とは、L2からL1へ送金することを意味します。 +Optimismのブリッジ用語では、「デポジット」はL1からL2への転送を意味し、「引き出し」はL2からL1への転送を意味します。 ```solidity address indexed _l1Token, address indexed _l2Token, ``` -ほとんどの場合、L1上のERC-20のアドレスは、L2上で対応するERC-20のアドレスとは異なります。 トークンアドレスのリストは、[こちら](https://static.optimism.io/optimism.tokenlist.json)を参照してください。 `chainId`が1のアドレスであれば、L1 (メインネット) 上のトークンであり、`chainId`が10のアドレスでれば、L2（Optimism）上のトークンです。 残りの2つの`chainId`の値は、Kovanテストネットワーク（42）とOptimistic Kovanテストネットワーク（69）のためのものです。 +ほとんどの場合、L1上のERC-20のアドレスは、L2上の同等のERC-20のアドレスとは異なります。 +[トークンアドレスのリストはこちらで確認できます](https://static.optimism.io/optimism.tokenlist.json)。 +`chainId`が1のアドレスはL1 (メインネット) 上にあり、`chainId`が10のアドレスはL2 (Optimism) 上にあります。 +他の2つの`chainId`の値は、Kovanテストネットワーク(42)とOptimistic Kovanテストネットワーク(69)のものです。 ```solidity address indexed _from, @@ -109,7 +117,7 @@ Optimismのブリッジ関連用語において、_入金_とは、L1からL2に ); ``` -転送にはメモを追加することができ、メモは転送を報告するイベントに追加されます。 +転送にメモを追加することが可能で、その場合、それらを報告するイベントに追加されます。 ```solidity event ERC20WithdrawalFinalized( @@ -122,33 +130,34 @@ Optimismのブリッジ関連用語において、_入金_とは、L1からL2に ); ``` -入金と出金の両方向につき、同じブリッジのコントラクトが処理します。 つまり、L1のブリッジでは入金を初期化し、出金を確定します。 +同じブリッジコントラクトが、両方向の転送を処理します。 +L1ブリッジの場合、これはデポジットの開始と引き出しの完了を意味します。 ```solidity /******************** - * Public Functions * + * 公開関数 * ********************/ /** - * @dev get the address of the corresponding L2 bridge contract. - * @return Address of the corresponding L2 bridge contract. + * @dev 対応するL2ブリッジコントラクトのアドレスを取得します。 + * @return 対応するL2ブリッジコントラクトのアドレス。 */ function l2TokenBridge() external returns (address); ``` -実際には、L2のブリッジは事前にデプロイされており、常に「`0x42000000000000000000000000000000000000000010`」のアドレスとなるため、この機能は必要ではありません。 この機能は、L2上のブリッジとの対称性を確保するためのものです。というのも、L1ブリッジのアドレスを確認することは無意味とは_言えない_ためです。 +この関数は、L2では事前にデプロイされたコントラクトであるため、実際には必要ありません。したがって、常にアドレス`0x4200000000000000000000000000000000000010`にあります。 +これはL2ブリッジとの対称性のためにあります。なぜなら、L1ブリッジのアドレスは簡単にはわからないからです。 ```solidity /** - * @dev deposit an amount of the ERC20 to the caller's balance on L2. - * @param _l1Token Address of the L1 ERC20 we are depositing - * @param _l2Token Address of the L1 respective L2 ERC20 - * @param _amount Amount of the ERC20 to deposit - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev L2の呼び出し元残高にERC20の金額をデポジットします。 + * @param _l1Token デポジットするL1 ERC20のアドレス + * @param _l2Token L1の各L2 ERC20のアドレス + * @param _amount デポジットするERC20の金額 + * @param _l2Gas L2でデポジットを完了するために必要なガスリミット。 + * @param _data L2に転送するオプションのデータ。このデータは、外部コントラクトの便宜のためにのみ提供されます。 + * 最大長を強制する以外、これらのコントラクトはその内容について何の保証も提供しません。 */ function depositERC20( address _l1Token, @@ -159,19 +168,20 @@ Optimismのブリッジ関連用語において、_入金_とは、L1からL2に ) external; ``` -`_l2Gas`のパラメータは、このトランザクションが使用できるL2上のガス量です。 この値は、[一定の（高い）上限まで無料であるため](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2)、ミント時にERC-20がコントラクトが特に異常な動作を行わない限り、問題は発生しません。 以下の関数は、異なるブロックチェーンにおける同一アドレスにアセットをブリッジしたいという一般的なシナリオで用いることができます。 +`_l2Gas`パラメータは、トランザクションが使用できるL2ガスの量です。 +[一定の(高い)制限まで、これは無料です](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2)。そのため、ミント時にERC-20コントラクトが本当に奇妙なことをしない限り、問題にはならないはずです。 +この関数は、ユーザーが異なるブロックチェーン上の同じアドレスに資産をブリッジするという、一般的なシナリオに対応します。 ```solidity /** - * @dev deposit an amount of ERC20 to a recipient's balance on L2. - * @param _l1Token Address of the L1 ERC20 we are depositing - * @param _l2Token Address of the L1 respective L2 ERC20 - * @param _to L2 address to credit the withdrawal to. - * @param _amount Amount of the ERC20 to deposit. - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev L2の受取人の残高にERC20の金額をデポジットします。 + * @param _l1Token デポジットするL1 ERC20のアドレス + * @param _l2Token L1の各L2 ERC20のアドレス + * @param _to 引き出しの入金先L2アドレス。 + * @param _amount デポジットするERC20の金額。 + * @param _l2Gas L2でデポジットを完了するために必要なガスリミット。 + * @param _data L2に転送するオプションのデータ。このデータは、外部コントラクトの便宜のためにのみ提供されます。 + * 最大長を強制する以外、これらのコントラクトはその内容について何の保証も提供しません。 */ function depositERC20To( address _l1Token, @@ -183,26 +193,24 @@ Optimismのブリッジ関連用語において、_入金_とは、L1からL2に ) external; ``` -次のコードは`depositERC20`とほぼ同一の関数ですが、ERC-20トークンを異なるアドレスに送信することができます。 +この関数は`depositERC20`とほぼ同じですが、ERC-20を異なるアドレスに送信できます。 ```solidity /************************* - * Cross-chain Functions * + * クロスチェーン関数 * *************************/ /** - * @dev Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the - * L1 ERC20 token. - * This call will fail if the initialized withdrawal from L2 has not been finalized. + * @dev L2からL1への引き出しを完了し、受取人のL1 ERC20トークン残高に資金を入金します。 + * この呼び出しは、L2からの初期化された引き出しが完了していない場合、失敗します。 * - * @param _l1Token Address of L1 token to finalizeWithdrawal for. - * @param _l2Token Address of L2 token where withdrawal was initiated. - * @param _from L2 address initiating the transfer. - * @param _to L1 address to credit the withdrawal to. - * @param _amount Amount of the ERC20 to deposit. - * @param _data Data provided by the sender on L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @param _l1Token finalizeWithdrawalの対象となるL1トークンのアドレス。 + * @param _l2Token 引き出しが開始されたL2トークンのアドレス。 + * @param _from 転送を開始するL2アドレス。 + * @param _to 引き出しの入金先L1アドレス。 + * @param _amount デポジットするERC20の金額。 + * @param _data L2の送信者から提供されたデータ。このデータは、外部コントラクトの便宜のためにのみ提供されます。 + * 最大長を強制する以外、これらのコントラクトはその内容について何の保証も提供しません。 */ function finalizeERC20Withdrawal( address _l1Token, @@ -215,16 +223,20 @@ Optimismのブリッジ関連用語において、_入金_とは、L1からL2に } ``` -Optimismにおける出金（および、他のL2からL1へのメッセージ送信）は、2つのステップで実行されます： +Optimismでの引き出し(およびL2からL1への他のメッセージ)は、2段階のプロセスです: -1. L2でトランザクションを開始する。 -2. L1で、トランザクションを確定／クレームする。 L1でのトランザクションは、L2でのトランザクションに対する[異議申し立て期間](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) が終了した後で実行可能になります。 +1. L2での開始トランザクション。 +2. L1での完了または請求トランザクション。 + このトランザクションは、L2トランザクションの[フォールトチャレンジ期間](https://community.optimism.io/docs/how-optimism-works/#fault-proofs)が終了した後に実行される必要があります。 ### IL1StandardBridge {#il1standardbridge} -このインターフェイスは、[こちら](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol)で定義されています。 このブリッジには、ETHを対象とするイベントおよび関数の定義が含まれています。 これらの定義は、ERC-20トークンを対象とする`IL1ERC20Bridge`の定義とほぼ同一です。 +[このインターフェースはここで定義されています](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol)。 +このファイルには、ETHのイベントと関数の定義が含まれています。 +これらの定義は、上記の`IL1ERC20Bridge`で定義されたERC-20のものと非常によく似ています。 -一部のERC-20トークンは、標準ブリッジでは処理できず、カスタム処理が必要となるため、このブリッジのインターフェイスは2つのファイルで構成されています。 これにより、カスタム処理が必要なトークンを取り扱うブリッジについては`IL1ERC20Bridge`を実装すればよく、ETHのブリッジ機能を実装する必要はありません。 +ブリッジインターフェースは2つのファイルに分かれています。なぜなら、一部のERC-20トークンはカスタム処理が必要で、標準ブリッジでは処理できないからです。 +これにより、そのようなトークンを処理するカスタムブリッジは、`IL1ERC20Bridge`を実装でき、ETHもブリッジする必要がありません。 ```solidity // SPDX-License-Identifier: MIT @@ -237,7 +249,7 @@ import "./IL1ERC20Bridge.sol"; */ interface IL1StandardBridge is IL1ERC20Bridge { /********** - * Events * + * イベント * **********/ event ETHDepositInitiated( address indexed _from, @@ -247,32 +259,33 @@ interface IL1StandardBridge is IL1ERC20Bridge { ); ``` -このイベントは、ERC-20トークン用のイベント（`ERC20DepositInitiated`）とほぼ同一ですが、L1およびL2上のトークンアドレスが含まれていない点が異なります。 他のイベントおよび関数についても、この点が異なります。 +このイベントは、ERC-20バージョン(`ERC20DepositInitiated`)とほぼ同じですが、L1とL2のトークンアドレスがない点が異なります。 +他のイベントや関数についても同様です。 ```solidity event ETHWithdrawalFinalized( . - 。 - 。 + . + . ); /******************** - * Public Functions * + * 公開関数 * ********************/ /** - * @dev Deposit an amount of the ETH to the caller's balance on L2. - 。 - 。 - 。 + * @dev L2の呼び出し元残高にETHの金額をデポジットします。 + . + . + . */ function depositETH(uint32 _l2Gas, bytes calldata _data) external payable; /** - * @dev Deposit an amount of ETH to a recipient's balance on L2. - 。 - 。 - 。 + * @dev L2の受取人の残高にETHの金額をデポジットします。 + . + . + . */ function depositETHTo( address _to, @@ -281,16 +294,15 @@ interface IL1StandardBridge is IL1ERC20Bridge { ) external payable; /************************* - * Cross-chain Functions * + * クロスチェーン関数 * *************************/ /** - * @dev Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the - * L1 ETH token. Since only the xDomainMessenger can call this function, it will never be called - * before the withdrawal is finalized. - 。 - 。 - 。 + * @dev L2からL1への引き出しを完了し、受取人のL1 ETHトークン残高に資金を入金します。 + * この関数はxDomainMessengerのみが呼び出せるため、引き出しが完了する前に呼び出されることはありません。 + . + . + . */ function finalizeETHWithdrawal( address _from, @@ -303,7 +315,7 @@ interface IL1StandardBridge is IL1ERC20Bridge { ### CrossDomainEnabled {#crossdomainenabled} -[このコントラクト](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol)は、[L1](#the-l1-bridge-contract)および[L2](#the-l2-bridge-contract)の両方のブリッジにおいて継承され、相手のレイヤーに対してメッセージを送信します。 +[このコントラクト](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol)は、両方のブリッジ([L1](#the-l1-bridge-contract)と[L2](#the-l2-bridge-contract))によって継承され、他のレイヤーにメッセージを送信します。 ```solidity // SPDX-License-Identifier: MIT @@ -313,52 +325,54 @@ pragma solidity >0.5.0 <0.9.0; import { ICrossDomainMessenger } from "./ICrossDomainMessenger.sol"; ``` -[このインターフェース](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol)は、クロスドメインのメッセンジャーを用いて、相手のレイヤーに対するメッセージの送信方法をコントラクトに通知するものです。 このクロスドメインのメッセンジャーは完全に別個のシステムであるため、今後改めて記事を執筆したいと考えています。 +[このインターフェース](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol)は、クロスドメインメッセンジャーを使用して、他のレイヤーにメッセージを送信する方法をコントラクトに伝えます。 +このクロスドメインメッセンジャーはまったく別のシステムであり、それ自体で記事にする価値があるため、将来的に書きたいと思っています。 ```solidity /** * @title CrossDomainEnabled - * @dev Helper contract for contracts performing cross-domain communications + * @dev クロスドメイン通信を実行するコントラクトのヘルパーコントラクト * - * Compiler used: defined by inheriting contract + * 使用されるコンパイラ: 継承するコントラクトによって定義 */ contract CrossDomainEnabled { /************* - * Variables * + * 変数 * *************/ - // Messenger contract used to send and receive messages from the other domain. + // 他のドメインからメッセージを送受信するために使用されるメッセンジャーコントラクト address public messenger; /*************** - * Constructor * + * コンストラクタ * ***************/ /** - * @param _messenger Address of the CrossDomainMessenger on the current layer. + * @param _messenger 現在のレイヤー上のCrossDomainMessengerのアドレス */ constructor(address _messenger) { messenger = _messenger; } ``` -このコントラクトが知る必要がある唯一のパラメータは、当該レイヤーにおけるクロスドメイン・メッセンジャーのアドレスです。 このパラメータは、コンストラクタ上で設定された後は変更されません。 +コントラクトが知る必要がある唯一のパラメータは、このレイヤー上のクロスドメインメッセンジャーのアドレスです。 +このパラメータはコンストラクタで一度設定され、変更されることはありません。 ```solidity /********************** - * Function Modifiers * + * 関数修飾子 * **********************/ /** - * Enforces that the modified function is only callable by a specific cross-domain account. - * @param _sourceDomainAccount The only account on the originating domain which is - * authenticated to call this function. + * 変更された関数が特定のクロスドメインアカウントによってのみ呼び出し可能であることを強制します。 + * @param _sourceDomainAccount この関数を呼び出すことが認証されている、発信元ドメインの唯一のアカウント。 */ modifier onlyFromCrossDomainAccount(address _sourceDomainAccount) { ``` -クロスドメインのメッセージング機能は、ブロックチェーン（イーサリアム・メインネットまたはOptimism）上で実行されているあらゆるコントラクトからアクセス可能です。 ただし、相手方のブリッジから送信された特定のメッセージ_のみ_を信頼するためには、双方のブリッジが必要になります。 +クロスドメインメッセージングは、実行されているブロックチェーン(イーサリアムメインネットまたはOptimism)上のどのコントラクトからもアクセスできます。 +しかし、各側のブリッジが、他の側のブリッジから来た場合にのみ特定のメッセージを信頼するようにする必要があります。 ```solidity require( @@ -367,7 +381,7 @@ contract CrossDomainEnabled { ); ``` -適切なクロスドメイン・メッセンジャー （以下の`messenger`を参照）から送信されたメッセージのみ、信頼できます。 +適切なクロスドメインメッセンジャー(以下で見るように`messenger`)からのメッセージのみが信頼できます。 ```solidity @@ -377,9 +391,10 @@ contract CrossDomainEnabled { ); ``` -クロスドメイン・メッセンジャーでは、[the `.xDomainMessageSender()` 関数](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128)を用いて、相手方のレイヤーにメッセージを送信するアドレスを提供します。 当該メッセージで開始されたトランザクションで呼び出す場合に限り、メッセージの送信元アドレスを表示することができます。 +クロスドメインメッセンジャーが、他のレイヤーでメッセージを送信したアドレスを提供する方法は、[`.xDomainMessageSender()`関数](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128)です。 +メッセージによって開始されたトランザクションで呼び出される限り、この情報を提供できます。 -このメッセージにつき、相手方のブリッジから送信されたものであることを確認する必要があります。 +受け取ったメッセージが他のブリッジから来たことを確認する必要があります。 ```solidity @@ -387,29 +402,28 @@ contract CrossDomainEnabled { } /********************** - * Internal Functions * + * 内部関数 * **********************/ /** - * Gets the messenger, usually from storage. This function is exposed in case a child contract - * needs to override. - * @return The address of the cross-domain messenger contract which should be used. + * 通常はストレージからメッセンジャーを取得します。この関数は、子コントラクトがオーバーライドする必要がある場合に公開されます。 + * @return 使用すべきクロスドメインメッセンジャーコントラクトのアドレス。 */ function getCrossDomainMessenger() internal virtual returns (ICrossDomainMessenger) { return ICrossDomainMessenger(messenger); } ``` -この機能は、クロスドメイン・メッセンジャーを返します。 `messenger`の変数ではなく関数を使うのは、この値を継承するコントラクトに対し、どのクロスドメイン・メッセンジャーを使用するかを特定するアルゴリズムを使用できるようにするためです。 +この関数は、クロスドメインメッセンジャーを返します。 +変数`messenger`ではなく関数を使用するのは、これから継承するコントラクトが、どのクロスドメインメッセンジャーを使用するかを指定するアルゴリズムを使用できるようにするためです。 ```solidity /** - * Sends a message to an account on another domain - * @param _crossDomainTarget The intended recipient on the destination domain - * @param _message The data to send to the target (usually calldata to a function with - * `onlyFromCrossDomainAccount()`) - * @param _gasLimit The gasLimit for the receipt of the message on the target domain. + * 他のドメインのアカウントにメッセージを送信します。 + * @param _crossDomainTarget 宛先ドメインの意図した受信者 + * @param _message ターゲットに送信するデータ(通常は`onlyFromCrossDomainAccount()`を持つ関数へのcalldata) + * @param _gasLimit ターゲットドメインでのメッセージのレシートのgasLimit。 */ function sendCrossDomainMessage( address _crossDomainTarget, @@ -417,17 +431,18 @@ contract CrossDomainEnabled { bytes memory _message ``` -最後に、次の関数は相手方のレイヤーにメッセージを送信するものです。 +最後に、他のレイヤーにメッセージを送信する関数です。 ```solidity ) internal { // slither-disable-next-line reentrancy-events, reentrancy-benign ``` -[Slither](https://github.com/crytic/slither)は、Optimismにおいて、すべてのコントラクトの脆弱性やその他の潜在的な問題箇所を特定するために実行される静的解析ツールです。 ここでは、以下の行により2つの脆弱性がトリガーされます。 +[Slither](https://github.com/crytic/slither)は、Optimismがすべてのコントラクトで実行し、脆弱性やその他の潜在的な問題を検出するための静的アナライザーです。 +この場合、次の行は2つの脆弱性を引き起こします: -1. [リエントランシーのイベント](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-3) -2. [無害のリエントランシー](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2) +1. [再入可能性イベント](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-3) +2. [良性の再入可能性](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2) ```solidity getCrossDomainMessenger().sendMessage(_crossDomainTarget, _message, _gasLimit); @@ -435,18 +450,19 @@ contract CrossDomainEnabled { } ``` -このケースでは、Slitherが当該情報を把握する方法を持たない場合でも、`getCrossDomainMessenger()`が信頼できるアドレスを返すと分かっているため、リエントランシーについて心配する必要はありません。 +この場合、`getCrossDomainMessenger()`が信頼できるアドレスを返すことがわかっているため、再入可能性について心配する必要はありません。たとえSlitherがそれを知る方法がなくてもです。 -### L1上のブリッジコントラクト {#the-l1-bridge-contract} +### L1ブリッジコントラクト {#the-l1-bridge-contract} -このコントラクトのソースコードは、[こちら](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol)で入手してください。 +[このコントラクトのソースコードはこちらです](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol)。 ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.9; ``` -このインターフェイスは、他のコントラクトにも含まれる場合があるため、Solidityのさまざまなバージョンをサポートする必要があります。 しかしここでは、ブリッジ自体がコントラクトであるため、使用できるSolidityのバージョンを限定することが可能です。 +インターフェースは他のコントラクトの一部になる可能性があるため、幅広いSolidityバージョンをサポートする必要があります。 +しかし、ブリッジ自体は私たちのコントラクトであり、使用するSolidityバージョンについて厳密にすることができます。 ```solidity /* Interface Imports */ @@ -454,124 +470,139 @@ import { IL1StandardBridge } from "./IL1StandardBridge.sol"; import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol"; ``` -[IL1ERC20Bridge](#IL1ERC20Bridge)と[IL1StandardBridge](#IL1StandardBridge)については、すでに説明しました。 +[IL1ERC20Bridge](#IL1ERC20Bridge)と[IL1StandardBridge](#IL1StandardBridge)については、上記で説明しました。 ```solidity import { IL2ERC20Bridge } from "../../L2/messaging/IL2ERC20Bridge.sol"; ``` -[このインターフェイス](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol)では、L2上で標準ブリッジを制御するためのメッセージを作成します。 +[このインターフェース](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol)により、L2の標準ブリッジを制御するためのメッセージを作成できます。 ```solidity import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; ``` -[このインターフェイス](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)は、ERC-20のコントラクトを制御するために使用します。 詳細については、[こちら](/developers/tutorials/erc20-annotated-code/#the-interface)をご覧ください。 +[このインターフェース](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)により、ERC-20コントラクトを制御できます。 +[詳細はこちらで読むことができます](/developers/tutorials/erc20-annotated-code/#the-interface)。 ```solidity /* Library Imports */ import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol"; ``` -[上記](#crossdomainenabled)で説明したように、このコントラクトはレイヤー間のメッセージングに使用します。 +[上で説明したように](#crossdomainenabled)、このコントラクトはレイヤー間メッセージングに使用されます。 ```solidity import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol"; ``` -[`Lib_PredeployAddresses`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol)には、常に同じアドレスを持つL2上のコントラクトのアドレスが含まれています。 これには、L2上の標準ブリッジが含まれます。 +`Lib_PredeployAddresses`には、常に同じアドレスを持つL2コントラクトのアドレスが含まれています。 これにはL2の標準ブリッジが含まれます。 ```solidity import { Address } from "@openzeppelin/contracts/utils/Address.sol"; ``` -[OpenZeppelinのアドレス・ユーティリティ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol)です。 これは、コントラクト上のアドレスと外部所有アカウント（EOA）に含まれるアドレスを区別するために使われます。 +[OpenZeppelinのアドレスユーティリティ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol)。 これは、コントラクトアドレスと外部所有アカウント(EOA)に属するアドレスを区別するために使用されます。 -これは、直接の呼び出しとコントラクトのコンストラクタで作成した呼び出しを区別できないため完全なソリューションとは言えませんが、少なくとも、よくあるユーザーエラーを特定、防止することは可能です。 +これは、直接の呼び出しとコントラクトのコンストラクタからの呼び出しを区別する方法がないため、完璧な解決策ではないことに注意してください。しかし、少なくともこれにより、一般的なユーザーエラーを特定し、防ぐことができます。 ```solidity import { SafeERC20 } from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol"; ``` -[ERC-20標準](https://eips.ethereum.org/EIPS/eip-20)では、コントラクトが実行失敗を報告する手段として以下の2つがあります： +[ERC-20標準](https://eips.ethereum.org/EIPS/eip-20)は、コントラクトが失敗を報告する2つの方法をサポートしています: 1. 元に戻す 2. `false`を返す -両方のケースに対応するとコードがより複雑になるため、代わりに[OpenZeppelinの`SafeERC20`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol)を使用します。これにより、[失敗した場合は常に元に戻されます](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96)。 +両方のケースを処理するとコードが複雑になるため、代わりにOpenZeppelinの[`SafeERC20`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol)を使用します。これにより、[すべての失敗が revert になる](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96)ことが保証されます。 ```solidity /** * @title L1StandardBridge - * @dev The L1 ETH and ERC20 Bridge is a contract which stores deposited L1 funds and standard - * tokens that are in use on L2. It synchronizes a corresponding L2 Bridge, informing it of deposits - * and listening to it for newly finalized withdrawals. + * @dev L1 ETHおよびERC20ブリッジは、デポジットされたL1資金と、L2で使用されている標準トークンを保存するコントラクトです。 + * 対応するL2ブリッジと同期し、デポジットを通知し、新しく完了した引き出しをリッスンします。 * */ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { using SafeERC20 for IERC20; ``` -この行は、`IERC20`インターフェイスを使用する際に、常に`IERC20`ラッパーを用いることを指定するものです。 +この行は、`IERC20`インターフェースを使用するたびに`SafeERC20`ラッパーを使用するように指定する方法です。 ```solidity /******************************** - * External Contract References * + * 外部コントラクト参照 * ********************************/ address public l2TokenBridge; ``` -[L2StandardBridge](#the-l2-bridge-contract)のアドレスです。 +[L2StandardBridge](#the-l2-bridge-contract)のアドレス。 ```solidity - // Maps L1 token to L2 token to balance of the L1 token deposited + // L1トークンをL2トークンにマッピングし、デポジットされたL1トークンの残高にマッピングします。 mapping(address => mapping(address => uint256)) public deposits; ``` -[2次元スパース配列](https://en.wikipedia.org/wiki/Sparse_matrix)を定義するには、このようなダブル[マッピング](https://www.tutorialspoint.com/solidity/solidity_mappings.htm)を用います。 このデータ構造の値は、`deposit[L1 token addr][L2 token addr]`として識別されます。 初期値はゼロになります。 ゼロ以外の値が設定されたセルのみが、ストレージに書き込まれます。 +このような二重の[マッピング](https://www.tutorialspoint.com/solidity/solidity_mappings.htm)は、[2次元スパース配列](https://en.wikipedia.org/wiki/Sparse_matrix)を定義する方法です。 +このデータ構造の値は、`deposit[L1トークンアドレス][L2トークンアドレス]`として識別されます。 +デフォルト値はゼロです。 +異なる値に設定されたセルのみがストレージに書き込まれます。 ```solidity /*************** - * Constructor * + * コンストラクタ * ***************/ - // This contract lives behind a proxy, so the constructor parameters will go unused. + // このコントラクトはプロキシの背後にあるため、コンストラクタのパラメータは使用されません。 constructor() CrossDomainEnabled(address(0)) {} ``` -ストレージ内のすべての変数をコピーせずに、このコントラクトを更新するには、 [`プロキシ`](https://docs.openzeppelin.com/contracts/3.x/api/proxy)を使用します。プロキシは、[`delegatecall`](https://solidity-by-example.org/delegatecall/)を用いて、プロキシのコントラクトにおいてアドレスが保存された別個のコントラクトに対して呼び出しを転送するものです（コントラクトを更新する際に、プロキシに対してこのアドレスを変更するように指示することになります）。 「`delegatecall`」を使用すると、ストレージは、_呼び出し元の_コントラクトのストレージのままになるため、すべてのコントラクト状態変数の値は影響を受けません。 +ストレージ内のすべての変数をコピーすることなく、このコントラクトをアップグレードできるようにしたいです。 +そのためには、[`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy)を使用します。これは、[`delegatecall`](https://solidity-by-example.org/delegatecall/)を使用して、プロキシコントラクトによってアドレスが保存されている別のコントラクトに呼び出しを転送するコントラクトです(アップグレード時に、プロキシにそのアドレスを変更するように指示します)。 +`delegatecall`を使用すると、ストレージは呼び出し元コントラクトのストレージのままになるため、すべてのコントラクトの状態変数の値は影響を受けません。 -このパターンを用いる効果のひとつとして、`delegatecall`の_呼び出し先_であるコントラクトのストレージが使用されないため、送信されたコンストラクタの値が意味を持たない点が挙げられます。 これこそ、`CrossDomainEnabled`のコンストラクタに対して無意味な値を入力できる理由です。 同時に、以下の初期化がコンストラクタとは別個に存在するである理由でもあります。 +このパターンの1つの効果は、`delegatecall`の呼び出し先であるコントラクトのストレージが使用されないため、それに渡されるコンストラクタの値は重要ではないということです。 +これが、`CrossDomainEnabled`コンストラクタに無意味な値を提供できる理由です。 +また、以下の初期化がコンストラクタから分離されている理由でもあります。 ```solidity /****************** - * Initialization * + * 初期化 * ******************/ /** - * @param _l1messenger L1 Messenger address being used for cross-chain communications. - * @param _l2TokenBridge L2 standard bridge address. + * @param _l1messenger クロスチェーン通信に使用されるL1メッセンジャーアドレス。 + * @param _l2TokenBridge L2標準ブリッジアドレス。 */ // slither-disable-next-line external-function ``` -この[Slitherのテスト](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external)は、コントラクトのコードにより呼び出される関数以外の関数であり、`public`ではなく、`external`と宣言される関数を特定するものです。 `external`関数のガス代は、コールデータに含まれるパラメータで指定できるため、安価に抑えることができます。 `public`と宣言された関数は、コントラクト内でアクセス可能である必要があります。 コントラクトはそれ自体のコールデータを変更できないため、パラメータはメモリに保存する必要があります。 このような関数を外部から呼び出す場合、コールデータをメモリにコピーする必要があるため、ガス代が発生します。 今回は関数を1回のみ呼び出すため、コスト上の非効率性は度外視できます。 +この[Slitherテスト](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external)は、コントラクトコードから呼び出されず、したがって`public`ではなく`external`として宣言できる関数を特定します。 +`external`関数のガス代は、calldataでパラメータを提供できるため、低くなる可能性があります。 +`public`と宣言された関数は、コントラクト内からアクセス可能である必要があります。 +コントラクトは自身のcalldataを変更できないため、パラメータはメモリに保存する必要があります。 +そのような関数が外部から呼び出される場合、calldataをメモリにコピーする必要があり、ガス代がかかります。 +この場合、関数は一度しか呼び出されないため、非効率性は問題になりません。 ```solidity function initialize(address _l1messenger, address _l2TokenBridge) public { require(messenger == address(0), "Contract has already been initialized."); ``` -`initialize`関数は、1回だけ呼び出す必要があります。 L1のクロスドメイン・メッセンジャーまたは L2のトークンブリッジのいずれかのアドレスが変更されると、新しいプロキシとそれを呼び出す新しいブリッジが作成されます。 これは、システム全体がアップグレードされた場合を除いて発生する可能性は低く、非常にまれです。 +`initialize`関数は、一度だけ呼び出す必要があります。 +L1クロスドメインメッセンジャーまたはL2トークンブリッジのアドレスが変更された場合、新しいプロキシとそれを呼び出す新しいブリッジを作成します。 +これは、システム全体がアップグレードされる場合を除き、起こる可能性は低く、非常にまれな出来事です。 -この関数には、呼び出し可能な_アカウント_を制限するメカニズムが含まれない点に注意してください。 つまり理論的には、ネットワークに対する攻撃者は、プロキシとブリッジの最初のバージョンがデプロイされるまで待機し、正当なユーザーが`initialize`関数にアクセスできる前に[フロントラン](https://solidity-by-example.org/hacks/front-running/)を実行することが可能です。 これを防ぐには、以下の2つの方法があります： +この関数には、誰が呼び出せるかを制限するメカニズムがないことに注意してください。 +つまり理論的には、攻撃者はプロキシとブリッジの最初のバージョンがデプロイされるのを待ち、正当なユーザーが`initialize`関数にアクセスする前に[フロントラン](https://solidity-by-example.org/hacks/front-running/)を実行することができます。 しかし、これを防ぐ方法は2つあります: -1. コントラクトがEOAにより直接デプロイされるのではなく、[別のコントラクトが作成したトランザクションにおいて](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595)デプロイされる場合、全体のプロセスがアトミックになり、他のトランザクションが実行される前に終了する場合があります。 -2. 正当な`initialize`呼び出しが失敗した場合、常に、新たに作成されたプロキシおよびブリッジを無視し、さらに新しいものを作成することが可能です。 +1. コントラクトがEOAによって直接デプロイされるのではなく、[別のコントラクトがそれらを作成するトランザクション](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595)でデプロイされる場合、プロセス全体がアトミックになり、他のトランザクションが実行される前に完了することができます。 +2. `initialize`への正当な呼び出しが失敗した場合、新しく作成されたプロキシとブリッジを無視して、新しいものを作成することは常に可能です。 ```solidity messenger = _l1messenger; @@ -584,34 +615,33 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { ```solidity /************** - * Depositing * + * デポジット * **************/ - /** @dev Modifier requiring sender to be EOA. This check could be bypassed by a malicious - * contract via initcode, but it takes care of the user error we want to avoid. + /** @dev 送信者がEOAであることを要求する修飾子。このチェックは、悪意のあるコントラクトによって + * initcode経由で回避される可能性がありますが、私たちが避けたいユーザーエラーに対応します。 */ modifier onlyEOA() { - // Used to stop deposits from contracts (avoid accidentally lost tokens) + // コントラクトからのデポジットを停止するために使用(誤って失われたトークンを避けるため) require(!Address.isContract(msg.sender), "Account not EOA"); _; } ``` -これは、OpenZeppelinの`Address`ユーティリティが必要となる理由です。 +これが、OpenZeppelinの`Address`ユーティリティが必要だった理由です。 ```solidity /** - * @dev This function can be called with no data - * to deposit an amount of ETH to the caller's balance on L2. - * Since the receive function doesn't take data, a conservative - * default amount is forwarded to L2. + * @dev この関数は、データを指定せずに呼び出すことができ、L2の呼び出し元残高にETHの金額をデポジットします。 + * receive関数はデータを取らないため、保守的なデフォルト金額がL2に転送されます。 */ receive() external payable onlyEOA { _initiateETHDeposit(msg.sender, msg.sender, 200_000, bytes("")); } ``` -この関数は、テスト用のものです。 通常の使用を目的とするものではないため、インターフェイスの定義には含まれない点に注意してください。 +この関数は、テスト目的で存在します。 +インターフェース定義には表示されないことに注意してください。通常の使用のためではありません。 ```solidity /** @@ -633,18 +663,16 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { } ``` -これら2つの関数は、実際のETH入金を処理する関数である`_initiateETHDeposit`に関連したラッパーです。 +これら2つの関数は、実際のETHデポジットを処理する関数である`_initiateETHDeposit`のラッパーです。 ```solidity /** - * @dev Performs the logic for deposits by storing the ETH and informing the L2 ETH Gateway of - * the deposit. - * @param _from Account to pull the deposit from on L1. - * @param _to Account to give the deposit to on L2. - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev ETHを保存し、L2 ETHゲートウェイにデポジットを通知することで、デポジットのロジックを実行します。 + * @param _from L1でデポジットを引き出すアカウント。 + * @param _to L2でデポジットを与えるアカウント。 + * @param _l2Gas L2でデポジットを完了するために必要なガスリミット。 + * @param _data L2に転送するオプションのデータ。このデータは、外部コントラクトの便宜のためにのみ提供されます。 + * 最大長を強制する以外、これらのコントラクトはその内容について何の保証も提供しません。 */ function _initiateETHDeposit( address _from, @@ -652,11 +680,13 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { uint32 _l2Gas, bytes memory _data ) internal { - // Construct calldata for finalizeDeposit call + // finalizeDeposit呼び出しのcalldataを構築 bytes memory message = abi.encodeWithSelector( ``` -クロスドメインのメッセージは、メッセージをコールデータとして宛先のコントラクトを呼び出す仕組みとして機能します。 Solidityのコントラクトは常に、コールデータを[ABI仕様](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html)に従って解釈します。 Solidityの[`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions)は、このコールデータを作成するものです。 +クロスドメインメッセージの仕組みは、宛先コントラクトがメッセージをcalldataとして呼び出されることです。 +Solidityコントラクトは、常に[ABI仕様](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html)に従ってcalldataを解釈します。 +Solidity関数[`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions)は、そのcalldataを作成します。 ```solidity IL2ERC20Bridge.finalizeDeposit.selector, @@ -669,24 +699,24 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { ); ``` -ここでのメッセージは、[ `finalizeDeposit`関数](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148)を以下のパラメータで呼び出すことです。 +ここでのメッセージは、これらのパラメータで[`finalizeDeposit`関数](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148)を呼び出すことです: -| パラメータ | 値 | 説明 | -| ----------- | -------------------------------- | --------------------------------------------------------------------------------------------------- | -| \_l1Token | address(0) | L1上のETH (ERC-20トークンではない) を表す特別な値 | -| \_l2Token | Lib_PredeployAddresses.OVM_ETH | Optimism上でETHを管理するL2のコントラクト`0xDeadDeAddeAddEAddeadDEaDDeaDDeAD0000` （このコントラクトは、Optimism内部でのみ使用されます） | -| \_from | \_from | L1上のETH送信元アドレス | -| \_to | \_to | L2上のETH受領用アドレス | -| amount | msg.value | 送信されたwei額（すでにブリッジに送信済みの額） | -| \_data | \_data | 入金に添付する追加の日付 | +| パラメータ | 値 | 意味 | +| ------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | +| \_l1Token | address(0) | L1上のETH(ERC-20トークンではない)を表す特別な値 | +| \_l2Token | Lib_PredeployAddresses.OVM_ETH | OptimismでETHを管理するL2コントラクト、`0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000`(このコントラクトはOptimism内部でのみ使用されます) | +| \_from | \_from | L1でETHを送信するアドレス | +| \_to | \_to | L2でETHを受信するアドレス | +| 金額 | msg.value | 送信されたweiの量(すでにブリッジに送信済み) | +| \_data | \_data | デポジットに添付する追加データ | ```solidity - // Send calldata into L2 + // calldataをL2に送信 // slither-disable-next-line reentrancy-events sendCrossDomainMessage(l2TokenBridge, _l2Gas, message); ``` -クロスドメイン・メッセンジャーを通じて、メッセージを送信します。 +クロスドメインメッセンジャーを介してメッセージを送信します。 ```solidity // slither-disable-next-line reentrancy-events @@ -694,16 +724,16 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { } ``` -この送信をリッスンするすべての分散型アプリケーションに対し、通知イベントを発行します。 +この転送をリッスンしている分散型アプリケーションに通知するためにイベントを発行します。 ```solidity /** * @inheritdoc IL1ERC20Bridge */ function depositERC20( - . - 。 - 。 + . + . + . ) external virtual onlyEOA { _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, msg.sender, _amount, _l2Gas, _data); } @@ -712,30 +742,28 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { * @inheritdoc IL1ERC20Bridge */ function depositERC20To( - . - 。 - 。 + . + . + . ) external virtual { _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, _to, _amount, _l2Gas, _data); } ``` -これら2つの関数は、実際のERC-20トークンの入金を処理する関数である`_initiateERC20Deposit`に関連したラッパーです。 +これら2つの関数は、実際のERC-20デポジットを処理する`_initiateERC20Deposit`関数のラッパーです。 ```solidity /** - * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) + * @dev L2デポジットトークンコントラクトにデポジットを通知し、ハンドラを呼び出してL1資金をロックするロジックを実行します。(例: transferFrom) * - * @param _l1Token Address of the L1 ERC20 we are depositing - * @param _l2Token Address of the L1 respective L2 ERC20 - * @param _from Account to pull the deposit from on L1 - * @param _to Account to give the deposit to on L2 - * @param _amount Amount of the ERC20 to deposit. - * @param _l2Gas Gas limit required to complete the deposit on L2. - * @param _data Optional data to forward to L2. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @param _l1Token デポジットするL1 ERC20のアドレス + * @param _l2Token L1の各L2 ERC20のアドレス + * @param _from L1でデポジットを引き出すアカウント + * @param _to L2でデポジットを与えるアカウント + * @param _amount デポジットするERC20の金額。 + * @param _l2Gas L2でデポジットを完了するために必要なガスリミット。 + * @param _data L2に転送するオプションのデータ。このデータは、外部コントラクトの便宜のためにのみ提供されます。 + * 最大長を強制する以外、これらのコントラクトはその内容について何の保証も提供しません。 */ function _initiateERC20Deposit( address _l1Token, @@ -748,26 +776,28 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { ) internal { ``` -この関数は、上記の`_initiateETHDeposit`に似ていますが、いくつかの重要な点が異なります。 最大の違いは、この関数では、トークンのアドレスおよび送信額をパラメータとして受け取るという点です。 ETHの場合、ブリッジへの呼び出しにはすでに、ブリッジアカウントへの資産の移転（`msg.value`）が含まれています。 +この関数は上記の`_initiateETHDeposit`に似ていますが、いくつかの重要な違いがあります。 +最初の違いは、この関数がトークンアドレスと転送量をパラメータとして受け取ることです。 +ETHの場合、ブリッジへの呼び出しには、すでにブリッジアカウントへの資産の移転(`msg.value`)が含まれています。 ```solidity - // When a deposit is initiated on L1, the L1 Bridge transfers the funds to itself for future - // withdrawals. safeTransferFrom also checks if the contract has code, so this will fail if - // _from is an EOA or address(0). + // L1でデポジットが開始されると、L1ブリッジは将来の引き出しのために資金を自身に転送します。 + // safeTransferFromは、コントラクトにコードがあるかどうかもチェックするため、_fromがEOAまたはaddress(0)の場合、これは失敗します。 // slither-disable-next-line reentrancy-events, reentrancy-benign IERC20(_l1Token).safeTransferFrom(_from, address(this), _amount); ``` -ERC-20トークンについては、ETHの場合とは異なる送信プロセスが実行されます： +ERC-20トークンの転送は、ETHとは異なるプロセスに従います: -1. ユーザー（`_from`）は、ブリッジに対し、送信したいトークン量に見合ったアローワンスを与えます。 -2. 次に、トークンコントラクトのアドレスや金額等で、ブリッジを呼び出します。 -3. ブリッジは、入金プロセスの一環として、トークンをブリッジ自体に送信します。 +1. ユーザー(`_from`)は、適切なトークンを転送するための権限をブリッジに与えます。 +2. ユーザーは、トークンコントラクトのアドレス、金額などでブリッジを呼び出します。 +3. ブリッジは、デポジットプロセスの一環として、トークンを(自身に)転送します。 -最初のステップは、第2、3のステップとは別のトランザクションで実行しても構いません。 ただし、`_initiateERC20Deposit`を呼び出す 2 つの関数 （`depositERC20`と`depositERC20To`）は、`_from`をパラメータとして`msg.sender`を含むこの関数を呼び出すだけなので、フロントランニングの問題は発生しません。 +最初のステップは、最後の2つのステップとは別のトランザクションで行われる場合があります。 +ただし、`_initiateERC20Deposit`を呼び出す2つの関数(`depositERC20`と`depositERC20To`)は、`_from`パラメータとして`msg.sender`を使用してこの関数を呼び出すだけなので、フロントランニングは問題になりません。 ```solidity - // Construct calldata for _l2Token.finalizeDeposit(_to, _amount) + // _l2Token.finalizeDeposit(_to, _amount)のcalldataを構築 bytes memory message = abi.encodeWithSelector( IL2ERC20Bridge.finalizeDeposit.selector, _l1Token, @@ -778,7 +808,7 @@ ERC-20トークンについては、ETHの場合とは異なる送信プロセ _data ); - // Send calldata into L2 + // calldataをL2に送信 // slither-disable-next-line reentrancy-events, reentrancy-benign sendCrossDomainMessage(l2TokenBridge, _l2Gas, message); @@ -786,7 +816,8 @@ ERC-20トークンについては、ETHの場合とは異なる送信プロセ deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] + _amount; ``` -`deposits`のデータ構造に、トークンの入金額を追加します。 L2上には、L1上にある同一のERC-20トークンに対応した複数のアドレスが存在する場合があるため、入金の推移を追跡するには、L1上のERC-20トークンに関するブリッジ上の残高を参照するだけでは不十分です。 +デポジットされたトークンの量を`deposits`データ構造に追加します。 +L2には同じL1 ERC-20トークンに対応する複数のアドレスが存在する可能性があるため、ブリッジのL1 ERC-20トークン残高を使用してデポジットを追跡するだけでは不十分です。 ```solidity @@ -795,7 +826,7 @@ ERC-20トークンについては、ETHの場合とは異なる送信プロセ } /************************* - * Cross-chain Functions * + * クロスチェーン関数 * *************************/ /** @@ -808,20 +839,21 @@ ERC-20トークンについては、ETHの場合とは異なる送信プロセ bytes calldata _data ``` -L2のブリッジは、L2のクロスドメイン・メッセンジャーに対して、L1のクロスドメイン・メッセンジャーがこの関数を呼び出すことを指示するメッセージを送信します（もちろん、L1上で、[このメッセージを確定するトランザクション](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions)が送信された後においてです）。 +L2ブリッジはL2クロスドメインメッセンジャーにメッセージを送信し、これによりL1クロスドメインメッセンジャーがこの関数を呼び出します(もちろん、[メッセージを完了するトランザクション](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions)がL1で送信された後)。 ```solidity ) external onlyFromCrossDomainAccount(l2TokenBridge) { ``` -このメッセージにつき、L2のトークン・ブリッジで作成され、クロスドメイン・メッセンジャーを経由して送信された_正当な_メッセージであることを確認してください。 この関数は、ブリッジからETHを出金するために使用するため、承認された呼び出し元だけが呼び出したことを確認する必要があります。 +これが、クロスドメインメッセンジャーから来て、L2トークンブリッジから発信された正当なメッセージであることを確認してください。 +この関数はブリッジからETHを引き出すために使用されるため、承認された呼び出し元によってのみ呼び出されることを確認する必要があります。 ```solidity // slither-disable-next-line reentrancy-events (bool success, ) = _to.call{ value: _amount }(new bytes(0)); ``` -ETHを送信するには、`msg.value`でwei金額を指定して、受領者を呼び出します。 +ETHを転送する方法は、`msg.value`にweiの量を指定して受信者を呼び出すことです。 ```solidity require(success, "TransferHelper::safeTransferETH: ETH transfer failed"); @@ -830,7 +862,7 @@ ETHを送信するには、`msg.value`でwei金額を指定して、受領者を emit ETHWithdrawalFinalized(_from, _to, _amount, _data); ``` -出金イベントを発行します。 +引き出しに関するイベントを発行します。 ```solidity } @@ -848,17 +880,16 @@ ETHを送信するには、`msg.value`でwei金額を指定して、受領者を ) external onlyFromCrossDomainAccount(l2TokenBridge) { ``` -この関数は、上記の `finalizeETHWithdrawal`関数に類似していますが、ERC-20トークンに関する事項が異なります。 +この関数は上記の`finalizeETHWithdrawal`に似ていますが、ERC-20トークンに必要な変更が加えられています。 ```solidity deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] - _amount; ``` -`deposits`のデータ構造を更新します。 +`deposits`データ構造を更新します。 ```solidity - - // When a withdrawal is finalized on L1, the L1 Bridge transfers the funds to the withdrawer + // L1で引き出しが完了すると、L1ブリッジは資金を引き出し人に転送します。 // slither-disable-next-line reentrancy-events IERC20(_l1Token).safeTransfer(_to, _amount); @@ -868,28 +899,33 @@ ETHを送信するには、`msg.value`でwei金額を指定して、受領者を /***************************** - * Temporary - Migrating ETH * + * 一時的 - ETHの移行 * *****************************/ /** - * @dev Adds ETH balance to the account. This is meant to allow for ETH - * to be migrated from an old gateway to a new gateway. - * NOTE: This is left for one upgrade only so we are able to receive the migrated ETH from the - * old contract + * @dev アカウントにETH残高を追加します。これは、古いゲートウェイから新しいゲートウェイにETHを移行できるようにすることを目的としています。 + * 注意: これは、古いコントラクトから移行されたETHを受け取ることができるように、1回のアップグレードのみに残されます。 */ function donateETH() external payable {} } ``` -このブリッジは、従来の実装から変更されています。 以前の実装から現在の実装に移行した際に、すべての資産を移転させる必要がありました。 ERC-20トークンについては、移転のみが可能でした。 一方、ETHをコントラクトに移転するには、そのコントラクトの承認が必要であり、これは`donateETH`で実行できます。 +ブリッジの以前の実装がありました。 +その実装からこの実装に移行したとき、すべての資産を移動する必要がありました。 +ERC-20トークンは移動するだけです。 +ただし、ETHをコントラクトに転送するには、そのコントラクトの承認が必要であり、それが`donateETH`が提供するものです。 ## L2上のERC-20トークン {#erc-20-tokens-on-l2} -ERC-20トークンを標準ブリッジに適合させるためには、標準ブリッジ_のみが_トークンをミントできるようにする必要があります。 これが必要になるのは、各ブリッジにおいて、Optimism上で流通するトークンの数がL1のブリッジコントラクト内でロックされたトークンの数と一致することを保証する必要があるためです。 L2上のトークンが多すぎる場合、L2上のアセットL1にブリッジして戻すことができないユーザーが発生します。 この場合、信頼できるブリッジが存在せず、事実上、[部分準備銀行制度](https://www.investopedia.com/terms/f/fractionalreservebanking.asp)を生み出すことになってしまいます。 一方、L1上でのトークンが多くなりすぎると、L2トークンをバーンしない限りトークンをリリースできなくなるため、ブリッジコントラクト内の一部のトークンは永遠にロックされた状態になってしまいます。 +ERC-20トークンが標準ブリッジに適合するためには、標準ブリッジ、そして標準ブリッジのみがトークンをミントできるようにする必要があります。 +これは、Optimismで流通しているトークンの数が、L1ブリッジコントラクト内にロックされているトークンの数と等しいことをブリッジが保証する必要があるためです。 +L2にトークンが多すぎると、一部のユーザーは資産をL1に戻すことができなくなります。 +信頼できるブリッジの代わりに、私たちは本質的に[部分準備銀行制度](https://www.investopedia.com/terms/f/fractionalreservebanking.asp)を再現することになります。 +L1にトークンが多すぎると、L2トークンをバーンしない限り解放する方法がないため、それらのトークンの一部はブリッジコントラクト内に永久にロックされたままになります。 ### IL2StandardERC20 {#il2standarderc20} -標準ブリッジを使用するL2上のすべてのERC-20トークンは、標準ブリッジが必要とする関数およびイベントが搭載された[このインターフェイス](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol)を提供する必要があります。 +標準ブリッジを使用するL2上のすべてのERC-20トークンは、[このインターフェース](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol)を提供する必要があります。これには、標準ブリッジが必要とする関数とイベントが含まれています。 ```solidity // SPDX-License-Identifier: MIT @@ -898,20 +934,24 @@ pragma solidity ^0.8.9; import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; ``` -[ERC-20に対する標準インターフェイス](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)には、`mint`および`burn`関数が含まれません。 これらのメソッドは、[ERC-20標準](https://eips.ethereum.org/EIPS/eip-20)において必須でないため、トークンを作成、破壊するメカニズムは指定されていないのです。 +[標準のERC-20インターフェース](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)には、`mint`および`burn`関数は含まれていません。 +これらのメソッドは、[ERC-20標準](https://eips.ethereum.org/EIPS/eip-20)では要求されておらず、トークンを作成および破棄するメカニズムは指定されていません。 ```solidity import { IERC165 } from "@openzeppelin/contracts/utils/introspection/IERC165.sol"; ``` -[ERC-165インターフェイス](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol)は、コントラクトが提供する機能を特定するために用います。 [この標準については、こちらで読むことができます](https://eips.ethereum.org/EIPS/eip-165)。 +[ERC-165インターフェース](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol)は、コントラクトが提供する関数を指定するために使用されます。 +[こちらで標準を読むことができます](https://eips.ethereum.org/EIPS/eip-165)。 ```solidity interface IL2StandardERC20 is IERC20, IERC165 { function l1Token() external returns (address); ``` -この関数は、このコントラクトに対してブリッジされた L1上のトークンアドレスを提供するものです。 同じ機能の逆方向の関数が存在しない点に注意してください。 L1上のトークンについては、L2のサポートが計画されていたか、あるいはいつ実装されたかを問わず、常にブリッジ可能である必要があります。 +この関数は、このコントラクトにブリッジされたL1トークンのアドレスを提供します。 +逆方向の同様の関数がないことに注意してください。 +L2サポートが実装時に計画されていたかどうかに関係なく、任意のL1トークンをブリッジできる必要があります。 ```solidity @@ -924,11 +964,13 @@ interface IL2StandardERC20 is IERC20, IERC165 { } ``` -トークンをミント (作成) およびバーン (破棄) するための関数とイベントです。 トークン数が適切である（L1上でロックされたトークン数と一致する）ことを保証するため、これらの関数を実行できるのはこのブリッジのみである必要があります。 +トークンをミント(作成)およびバーン(破棄)するための関数とイベント。 +トークンの数が正しいこと(L1にロックされているトークンの数と等しいこと)を保証するため、ブリッジはこれらの関数を実行できる唯一のエンティティである必要があります。 ### L2StandardERC20 {#L2StandardERC20} -[これは](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol)、`IL2StandardERC20`インターフェイスの実装です。 カスタムロジックが必要ない場合は、常にこの関数を用いてください。 +[これは`IL2StandardERC20`インターフェースの実装です](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol)。 +何らかのカスタムロジックが必要でない限り、これを使用する必要があります。 ```solidity // SPDX-License-Identifier: MIT @@ -937,7 +979,8 @@ pragma solidity ^0.8.9; import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; ``` -[OpenZeppelinで作成したERC-20コントラクト](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)です。 Optimismでは、既存の機能がよく監査され、資産を保持する上で十分信頼できる場合は、新たな機能を追加すべきではないと考えています。 +[OpenZeppelin ERC-20コントラクト](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)。 +Optimismは、特に車輪が十分に監査され、資産を保持するのに十分信頼できる必要がある場合に、車輪を再発明することを信じていません。 ```solidity import "./IL2StandardERC20.sol"; @@ -947,15 +990,15 @@ contract L2StandardERC20 is IL2StandardERC20, ERC20 { address public l2Bridge; ``` -これらは、通常ERC-20では必要になりませんが、ここでは追加で必要となる2つの設定パラメータです。 +これらは、私たちが要求し、通常ERC-20が必要としない2つの追加の設定パラメータです。 ```solidity /** - * @param _l2Bridge Address of the L2 standard bridge. - * @param _l1Token Address of the corresponding L1 token. - * @param _name ERC20 name. - * @param _symbol ERC20 symbol. + * @param _l2Bridge L2標準ブリッジのアドレス。 + * @param _l1Token 対応するL1トークンのアドレス。 + * @param _name ERC20名。 + * @param _symbol ERC20シンボル。 */ constructor( address _l2Bridge, @@ -968,7 +1011,7 @@ contract L2StandardERC20 is IL2StandardERC20, ERC20 { } ``` -まず、`ERC20(_name, _symbol)`で継承したコントラクトのコンストラクタを呼び出し、新たに変数を設定します。 +まず、継承元のコントラクトのコンストラクタ(`ERC20(_name, _symbol)`)を呼び出し、次に独自の変数を設定します。 ```solidity @@ -988,11 +1031,12 @@ contract L2StandardERC20 is IL2StandardERC20, ERC20 { } ``` -[ERC-165](https://eips.ethereum.org/EIPS/eip-165)は、このように動作します。 各インターフェイスは、サポートする一連の関数を含んでおり、これらの機能の[exclusive](https://en.wikipedia.org/wiki/Exclusive_or)または[ABI関数セレクタ](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector)として特定されます。 +これが[ERC-165](https://eips.ethereum.org/EIPS/eip-165)の仕組みです。 +すべてのインターフェースは、サポートされている関数の数であり、それらの関数の[ABI関数セレクタ](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector)の[排他的論理和](https://en.wikipedia.org/wiki/Exclusive_or)として識別されます。 -L2のブリッジは、ERC-165を健全性チェックとして用いて、資産を送信するのに用いるERC-20コントラクトが `IL2StandardERC20`であるか確認します。 +L2ブリッジは、ERC-165をサニティチェックとして使用して、資産を送信するERC-20コントラクトが`IL2StandardERC20`であることを確認します。 -**注意：不正なコントラクトが`supportsInterface`に対して虚偽の値を返すことを防ぐメカニズムは含まれていないため、これはセキュリティ保護のメカニズム_ではなく_、健全性チェックのメカニズムです。 +**注:** 不正なコントラクトが`supportsInterface`に偽の回答を提供することを防ぐものはないため、これはサニティチェックメカニズムであり、セキュリティメカニズムではありません。 ```solidity // slither-disable-next-line external-function @@ -1011,13 +1055,15 @@ L2のブリッジは、ERC-165を健全性チェックとして用いて、資 } ``` -資産をミント／バーンできるのは、L2のブリッジのみです。 +資産をミントおよびバーンできるのは、L2ブリッジのみです。 -`_mint`および`_burn`は、実際には、[OpenZeppelinで作成したERC-20コントラクト](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn)で定義されています。 トークンをミント／バーンできる条件は、ERC-20を使用する方法と同じように多種多様であるため、このコントラクトは単純に外部に露出していないのです。 +`_mint`と`_burn`は、実際には[OpenZeppelin ERC-20コントラクト](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn)で定義されています。 +そのコントラクトは、トークンをミントおよびバーンする条件がERC-20の使用方法と同じくらい多様であるため、それらを外部に公開しないだけです。 -## L2ブリッジのコード {#l2-bridge-code} +## L2ブリッジコード {#l2-bridge-code} -これは、Optimismでブリッジを実行するコードです。 このコントラクトのソースコードは、[こちら](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol)から入手できます。 +これは、Optimismでブリッジを実行するコードです。 +[このコントラクトのソースはこちらです](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol)。 ```solidity // SPDX-License-Identifier: MIT @@ -1029,48 +1075,50 @@ import { IL1ERC20Bridge } from "../../L1/messaging/IL1ERC20Bridge.sol"; import { IL2ERC20Bridge } from "./IL2ERC20Bridge.sol"; ``` -[IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol)のインターフェースは、上述した[L1用のインターフェイス](#IL1ERC20Bridge)とほぼ同様ですが、 以下の2点が大きく異なります。 +[IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol)インターフェースは、上で見た[L1の同等のもの](#IL1ERC20Bridge)と非常に似ています。 +2つの大きな違いがあります: -1. L1では、あなたが入金を開始し、出金を確定します。 L2の場合、あなたは出金を開始し、入金を確定します。 -2. L1では、ETHとERC-20トークンを区別する必要があります。 L2では、Optimism上のETH残高は内部で、アドレス「[0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://optimistic.etherscan.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000)」のERC-20トークンとして処理されるため、両方で同じ関数を使います。 +1. L1では、デポジットを開始し、引き出しを完了します。 + ここでは、引き出しを開始し、デポジットを完了します。 +2. L1では、ETHとERC-20トークンを区別する必要があります。 + L2では、Optimismの内部ETH残高はアドレス[0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000)のERC-20トークンとして処理されるため、両方に同じ関数を使用できます。 ```solidity -/* Library Imports */ +/* ライブラリのインポート */ import { ERC165Checker } from "@openzeppelin/contracts/utils/introspection/ERC165Checker.sol"; import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol"; import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol"; -/* Contract Imports */ +/* コントラクトのインポート */ import { IL2StandardERC20 } from "../../standards/IL2StandardERC20.sol"; /** * @title L2StandardBridge - * @dev The L2 Standard bridge is a contract which works together with the L1 Standard bridge to - * enable ETH and ERC20 transitions between L1 and L2. - * This contract acts as a minter for new tokens when it hears about deposits into the L1 Standard - * bridge. - * This contract also acts as a burner of the tokens intended for withdrawal, informing the L1 - * bridge to release L1 funds. + * @dev L2標準ブリッジは、L1標準ブリッジと連携して、L1とL2間のETHおよびERC20の移行を可能にするコントラクトです。 + * このコントラクトは、L1標準ブリッジへのデポジットを聞くと、新しいトークンのミンターとして機能します。 + * このコントラクトは、引き出しを意図したトークンのバーナーとしても機能し、L1ブリッジにL1資金を解放するように通知します。 */ contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled { /******************************** - * External Contract References * + * 外部コントラクト参照 * ********************************/ address public l1TokenBridge; ``` -これは、L1ブリッジのアドレスを追跡する関数です。 L1用のブリッジの場合とは異なり、この変数は_必須_です。 L1ブリッジのアドレスは、事前に知ることはできません。 +L1ブリッジのアドレスを追跡します。 +L1の同等のものとは対照的に、ここではこの変数が必要であることに注意してください。 +L1ブリッジのアドレスは事前にわかりません。 ```solidity /*************** - * Constructor * + * コンストラクタ * ***************/ /** - * @param _l2CrossDomainMessenger Cross-domain messenger used by this contract. - * @param _l1TokenBridge Address of the L1 bridge deployed to the main chain. + * @param _l2CrossDomainMessenger このコントラクトで使用されるクロスドメインメッセンジャー。 + * @param _l1TokenBridge メインチェーンにデプロイされたL1ブリッジのアドレス。 */ constructor(address _l2CrossDomainMessenger, address _l1TokenBridge) CrossDomainEnabled(_l2CrossDomainMessenger) @@ -1079,7 +1127,7 @@ contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled { } /*************** - * Withdrawing * + * 引き出し * ***************/ /** @@ -1108,21 +1156,21 @@ contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled { } ``` -これら2つの関数は、出金を開始するものです。 L1上のトークンアドレスを指定する必要がない点に注意してください。 L1上で対応するトークンのアドレスは、L2トークンが伝達するからです。 +これら2つの関数は、引き出しを開始します。 +L1トークンアドレスを指定する必要はないことに注意してください。 +L2トークンは、L1の同等のアドレスを教えてくれることが期待されています。 ```solidity /** - * @dev Performs the logic for withdrawals by burning the token and informing - * the L1 token Gateway of the withdrawal. - * @param _l2Token Address of L2 token where withdrawal is initiated. - * @param _from Account to pull the withdrawal from on L2. - * @param _to Account to give the withdrawal to on L1. - * @param _amount Amount of the token to withdraw. - * @param _l1Gas Unused, but included for potential forward compatibility considerations. - * @param _data Optional data to forward to L1. This data is provided - * solely as a convenience for external contracts. Aside from enforcing a maximum - * length, these contracts provide no guarantees about its content. + * @dev トークンをバーンし、L1トークンゲートウェイに引き出しを通知することで、引き出しのロジックを実行します。 + * @param _l2Token 引き出しが開始されたL2トークンのアドレス。 + * @param _from L2で引き出しを引き出すアカウント。 + * @param _to L1で引き出しを与えるアカウント。 + * @param _amount 引き出すトークンの量。 + * @param _l1Gas 未使用ですが、将来の互換性の考慮事項のために含まれています。 + * @param _data L1に転送するオプションのデータ。このデータは、外部コントラクトの便宜のためにのみ提供されます。 + * 最大長を強制する以外、これらのコントラクトはその内容について何の保証も提供しません。 */ function _initiateWithdrawal( address _l2Token, @@ -1132,17 +1180,16 @@ contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled { uint32 _l1Gas, bytes calldata _data ) internal { - // When a withdrawal is initiated, we burn the withdrawer's funds to prevent subsequent L2 - // usage + // 引き出しが開始されると、その後のL2での使用を防ぐために、引き出し人の資金をバーンします。 // slither-disable-next-line reentrancy-events IL2StandardERC20(_l2Token).burn(msg.sender, _amount); ``` -`_from`パラメータに依存_するのではなく_、`msg.sender`を使用する点に注意してください。これにより、偽造がより困難になります（私の知る限り、不可能です）。 +`_from`パラメータに依存するのではなく、偽造するのがはるかに難しい(私の知る限り不可能) `msg.sender`に依存していることに注意してください。 ```solidity - // Construct calldata for l1TokenBridge.finalizeERC20Withdrawal(_to, _amount) + // l1TokenBridge.finalizeERC20Withdrawal(_to, _amount)のcalldataを構築 // slither-disable-next-line reentrancy-events address l1Token = IL2StandardERC20(_l2Token).l1Token(); bytes memory message; @@ -1150,7 +1197,7 @@ contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled { if (_l2Token == Lib_PredeployAddresses.OVM_ETH) { ``` -L1では、ETHとERC-20トークンを区別する必要があります。 +L1では、ETHとERC-20を区別する必要があります。 ```solidity message = abi.encodeWithSelector( @@ -1172,7 +1219,7 @@ L1では、ETHとERC-20トークンを区別する必要があります。 ); } - // Send message up to L1 bridge + // メッセージをL1ブリッジに送信 // slither-disable-next-line reentrancy-events sendCrossDomainMessage(l1TokenBridge, _l1Gas, message); @@ -1181,7 +1228,7 @@ L1では、ETHとERC-20トークンを区別する必要があります。 } /************************************ - * Cross-chain Function: Depositing * + * クロスチェーン関数: デポジット * ************************************/ /** @@ -1196,69 +1243,66 @@ L1では、ETHとERC-20トークンを区別する必要があります。 bytes calldata _data ``` -この関数は、`L1StandardBridge`が呼び出します。 +この関数は`L1StandardBridge`によって呼び出されます。 ```solidity ) external virtual onlyFromCrossDomainAccount(l1TokenBridge) { ``` -メッセージの発信元が適切であることを確認します。 この関数は、`_mint`を呼び出すものであり、L1上でブリッジが所有するトークンに含まれないトークンを提供するために使用できるため、重要です。 +メッセージのソースが正当であることを確認してください。 +この関数は`_mint`を呼び出し、ブリッジがL1で所有するトークンでカバーされていないトークンを与えるために使用できるため、これは重要です。 ```solidity - // Check the target token is compliant and - // verify the deposited token on L1 matches the L2 deposited token representation here + // ターゲットトークンが準拠していることを確認し、 + // L1でデポジットされたトークンがここのL2デポジットトークン表現と一致することを検証します。 if ( // slither-disable-next-line reentrancy-events ERC165Checker.supportsInterface(_l2Token, 0x1d1d8b63) && _l1Token == IL2StandardERC20(_l2Token).l1Token() ``` -以下の健全性チェックを実行してください： +サニティチェック: -1. 正しいインターフェースがサポートされていること。 -2. L2上のERC-20コントラクトにおけるL1アドレスが、L1上のトークンソースと一致すること。 +1. 正しいインターフェースがサポートされていること +2. L2 ERC-20コントラクトのL1アドレスが、トークンのL1ソースと一致すること ```solidity ) { - // When a deposit is finalized, we credit the account on L2 with the same amount of - // tokens. + // デポジットが完了すると、L2のアカウントに同額のトークンを入金します。 // slither-disable-next-line reentrancy-events IL2StandardERC20(_l2Token).mint(_to, _amount); // slither-disable-next-line reentrancy-events emit DepositFinalized(_l1Token, _l2Token, _from, _to, _amount, _data); ``` -健全性チェックに合格したら、入金を確定します。 +サニティチェックに合格した場合、デポジットを完了します: 1. トークンをミントします。 2. 適切なイベントを発行します。 ```solidity } else { - // Either the L2 token which is being deposited-into disagrees about the correct address - // of its L1 token, or does not support the correct interface. - // This should only happen if there is a malicious L2 token, or if a user somehow - // specified the wrong L2 token address to deposit into. - // In either case, we stop the process here and construct a withdrawal - // message so that users can get their funds out in some cases. - // There is no way to prevent malicious token contracts altogether, but this does limit - // user error and mitigate some forms of malicious contract behavior. + // デポジット先のL2トークンが、そのL1トークンの正しいアドレスについて同意しないか、正しいインターフェースをサポートしていないかのいずれかです。 + // これは、悪意のあるL2トークンがある場合、またはユーザーが何らかの方法でデポジット先の間違ったL2トークンアドレスを指定した場合にのみ発生するはずです。 + // いずれの場合も、ここでプロセスを停止し、引き出しメッセージを構築して、ユーザーが場合によっては資金を取り出せるようにします。 + // 悪意のあるトークンコントラクトを完全に防ぐ方法はありませんが、これによりユーザーエラーが制限され、悪意のあるコントラクトの動作のいくつかの形態が軽減されます。 ``` -L2のトークンアドレスが間違っており、検知可能なエラーが発生した場合、入金をキャンセルし、トークンをL1に返却する必要があります。 これをL2から実行する唯一の方法は、不正申し立て期間が経過してからメッセージを送信することですが、それでも、トークンを永遠に失うよりは、ユーザーにとってははるかにベターな選択でしょう。 +ユーザーが間違ったL2トークンアドレスを使用して検出可能なエラーを犯した場合、デポジットをキャンセルしてL1でトークンを返したいです。 +これをL2から行う唯一の方法は、フォールトチャレンジ期間を待つ必要があるメッセージを送信することですが、それはユーザーがトークンを永久に失うよりもはるかに良いです。 ```solidity bytes memory message = abi.encodeWithSelector( IL1ERC20Bridge.finalizeERC20Withdrawal.selector, _l1Token, _l2Token, - _to, // switched the _to and _from here to bounce back the deposit to the sender + _to, // ここで_toと_fromを切り替えて、デポジットを送信者に跳ね返す _from, _amount, _data ); - // Send message up to L1 bridge + // メッセージをL1ブリッジに送信 // slither-disable-next-line reentrancy-events sendCrossDomainMessage(l1TokenBridge, 0, message); // slither-disable-next-line reentrancy-events @@ -1268,10 +1312,15 @@ L2のトークンアドレスが間違っており、検知可能なエラーが } ``` -## まとめ {#conclusion} +## 結論 {#conclusion} + +標準ブリッジは、資産転送のための最も柔軟なメカニズムです。 +しかし、非常に汎用的であるため、必ずしも最も使いやすいメカニズムではありません。 +特に、出金に関しては、ほとんどのユーザーが、チャレンジ期間を待つ必要がなく、出金をファイナライズするためにマークル証明を必要としない[サードパーティ製ブリッジ](https://optimism.io/apps#bridge)を使用することを好みます。 -標準ブリッジは、アセットを移転する上で最も柔軟なメカニズムです。 しかし、汎用性が高いため、必ずしも使いやすいメカニズムではない場合もあります。 特に出金については、大部分のユーザーは、異議申し立て期間が存在せず、出金を最終確認するためにMerkleプルーフを必要としない[サードパーティーのブリッジ](https://optimism.io/apps#bridge)を使いたいと考えるでしょう。 +これらのブリッジは通常、L1に資産を持ち、それを少額の手数料(多くの場合、標準ブリッジの引き出しのガス代よりも安い)ですぐに提供することで機能します。 +ブリッジ(またはそれを運営する人々)がL1の資産が不足すると予想する場合、L2から十分な資産を転送します。 これらは非常に大きな引き出しであるため、引き出しコストは多額にわたって償却され、はるかに小さい割合になります。 -サードパーティのブリッジは通常、少額の手数料（標準ブリッジの出金にかかるガス代よりも安価な場合が多いです）で、L1上でアセットを保持する機能を提供します。 ブリッジ（または、ブリッジを稼働するスタッフ）がL1上での資産不足を予想する場合、L2から必要な資産が移転されます。 これらは非常に大規模な出金になるため、出金コストは高額を対象として償却され、手数料が全体に占める割合が非常に低くなります。 +この記事が、レイヤー2の仕組みと、明確で安全なSolidityコードの書き方について、より理解を深めるのに役立ったことを願っています。 -この記事が、レイヤー2の仕組みと、明確で安全なSolidityコードの書き方について、より理解を深めることに役立つことを願っています。 +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/ja/developers/tutorials/reverse-engineering-a-contract/index.md index 3b8dd029780..dcb7f836a86 100644 --- a/public/content/translations/ja/developers/tutorials/reverse-engineering-a-contract/index.md +++ b/public/content/translations/ja/developers/tutorials/reverse-engineering-a-contract/index.md @@ -1,40 +1,38 @@ --- title: "コントラクトのリバースエンジニアリング" -description: ソースコードがない場合にコントラクトを理解する方法 +description: "ソースコードがない場合にコントラクトを理解する方法" author: Ori Pomerantz lang: ja -tags: - - "イーサリアム仮想マシン(EVM)" - - "オペコード" +tags: [ "evm", "オペコード" ] skill: advanced published: 2021-12-30 --- ## はじめに {#introduction} -_ブロックチェーン上に秘密はありません。_ブロックチェーン上で起こる全てのことは、一貫性があり、検証可能で、公開されています。 理想的には、[コントラクトはEtherscanで公開され、検証されたソースコードであるべきです](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code)。 しかし、[必ずしもそうとは限りません](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code)。 この記事では、ソースコード([`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f))を見ることなくコントラクトをリバースエンジニアリングする方法を学びます。 +_ブロックチェーン上に秘密はありません_。ブロックチェーン上で起こる全てのことは、一貫性があり、検証可能で、公開されています。 理想的には、[コントラクトのソースコードはEtherscanで公開・検証されるべきです](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code)。 しかし、[必ずしもそうとは限りません](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code)。 この記事では、ソースコードがないコントラクト[`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f)を調べることで、コントラクトをリバースエンジニアリングする方法を学びます。 -リバースコンパイラを使用しても、必ず[利用可能な結果](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f)が生成されるわけではありません。 この記事では、手動でリバースエンジニアリングを実行し、[オペコード](https://github.com/wolflo/evm-opcodes)からコントラクトを理解する方法を学びます。また、デコンパイラによる結果を理解する方法も学びます。 +逆コンパイラは存在しますが、必ずしも[利用可能な結果](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f)が得られるとは限りません。 この記事では、手動でリバースエンジニアリングを行い、[オペコード](https://github.com/wolflo/evm-opcodes)からコントラクトを理解する方法と、デコンパイラの結果を解釈する方法を学びます。 -この記事を理解するには、イーサリアム仮想マシン(EVM)の基礎を理解しており、イーサリアム仮想マシン(EVM)アセンブラにある程度精通している必要があります。 [イーサリアム仮想マシン(EVM)に関するトピックについてはこちら](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e)をご覧ください。 +この記事を理解するには、イーサリアム仮想マシン(EVM)の基礎を理解しており、EVMアセンブラにある程度精通している必要があります。 [これらのトピックについてはこちらをお読みください](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e)。 ## 実行可能コードの準備 {#prepare-the-executable-code} -Etherscanにアクセスするとコントラクトのオペコードを入手できます。「**Contract**」タブをクリックし、次に「**Switch to Opcodes View**」をクリックしてください。 これで一行ずつオペコートが表示されます。 +コントラクトのEtherscanページにアクセスし、**Contract**タブをクリックしてから**Switch to Opcodes View**をクリックすると、オペコードを取得できます。 1行に1つのオペコードが表示されるビューになります。 -![Etherscanでのオペコードの表示](opcode-view.png) +![Etherscanのオペコードビュー](opcode-view.png) -ジャンプ (JUMP) を理解するには、コード内のオペコードの場所を理解する必要があります。 そのための1つの方法は、Googleスプレッドシートを開き、オペコードをC列に貼り付けることです。[既に準備されているこのスプレッドシートをコピーすれば、次のステップをスキップできます](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing)。 +ただし、ジャンプを理解するには、コード内の各オペコードの場所を知る必要があります。 そのためには、Googleスプレッドシートを開き、オペコードをC列に貼り付けるという方法があります。[こちらの準備済みのスプレッドシートのコピーを作成すれば、次の手順をスキップできます](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing)。 -次のステップは、正しいコードの位置を取得することです。これで、ジャンプを理解できるようになります。 オペコードのサイズをB列に、場所(16進数)をA列に配置します。`B1`セルに以下の関数を入力し、それをB列の残りの部分にコードの最終行までコピーアンドペーストします。 これを行った後、B列を非表示にできます。 +次のステップでは、ジャンプを理解できるように、正しいコードのロケーションを取得します。 B列にオペコードサイズを、A列に(16進数の)ロケーションを入れます。セル`B1`にこの関数を入力し、コードの最後までB列の残りのセルにコピー＆ペーストします。 これを行った後、B列を非表示にできます。 ``` =1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0) ``` -この関数は、まず1バイトをオペコード自体に追加し、次に`PUSH`を探します。 PUSHは特殊なオペコードであり、プッシュされる値用に追加のバイトを保持する必要があります。 オペコードが`PUSH`の場合、バイト数を抽出して加算します。 +まず、この関数はオペコード自体のために1バイトを追加し、次に`PUSH`を探します。 プッシュオペコードは特殊で、プッシュされる値用に追加のバイトを保持する必要があります。 オペコードが`PUSH`の場合、バイト数を抽出して加算します。 -`A1`に最初のオフセットである0を配置します。 次に`A2`に下記の関数を配置し、A列の残りの部分にコピーアンドペーストします。 +`A1`に最初のオフセットであるゼロを配置します。 次に、`A2`にこの関数を配置し、A列の残りの部分にコピーアンドペーストします。 ``` =dec2hex(hex2dec(A1)+B1) @@ -42,112 +40,112 @@ Etherscanにアクセスするとコントラクトのオペコードを入手 ジャンプ(`JUMP`と`JUMPI`)の前にプッシュされる値は16進数で渡されるため、この関数で16進数の値を得る必要があります。 -## エントリーポイント(0x00) {#the-entry-point-0x00} +## エントリーポイント (0x00) {#the-entry-point-0x00} コントラクトは、必ず最初のバイトから実行されます。 以下は、コードの冒頭部分です。 -| オフセット | オペコード | スタック(オペコードの後) | -| -----:| ------------ | ------------------- | -| 0 | PUSH1 0x80 | 0x80 | -| 2 | PUSH1 0x40 | 0x40, 0x80 | -| 4 | MSTORE | なし | -| 5 | PUSH1 0x04 | 0x04 | -| 7 | CALLDATASIZE | CALLDATASIZE 0x04 | -| 8 | LT | CALLDATASIZE\<4 | -| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 | -| C | JUMPI | なし | +| オフセット | オペコード | スタック(オペコードの後) | +| ----: | ------------ | -------------------------------------------- | +| 0 | PUSH1 0x80 | 0x80 | +| 2 | PUSH1 0x40 | 0x40, 0x80 | +| 4 | MSTORE | なし | +| 5 | PUSH1 0x04 | 0x04 | +| 7 | CALLDATASIZE | CALLDATASIZE 0x04 | +| 8 | LT | CALLDATASIZE<4 | +| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE<4 | +| C | JUMPI | なし | このコードは、次の2つのことをしています。 -1. メモリロケーションの0x40~0x5Fへ、32バイト値として0x80を書き込みます(0x5Fに0x80が格納され、0x40～0x5Eはすべてゼロになります)。 -2. コールデータサイズ(CALLDATASIZE)を読み取ります。 通常、イーサリアムコントラクトのコールデータは、[アプリケーションバイナリインターフェース(ABI)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html)に従います。アプリケーションバイナリインターフェース(ABI)では、最低でも4バイトが関数セレクタに必要です。 コールデータのサイズが4未満の場合、0x5Eへジャンプします。 +1. メモリロケーションの0x40～0x5Fへ、32バイト値として0x80を書き込みます(0x5Fに0x80が格納され、0x40～0x5Eはすべてゼロになります)。 +2. コールデータサイズを読み取ります。 通常、イーサリアムコントラクトのコールデータは[ABI (アプリケーションバイナリインターフェース)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html)に従います。これには、関数セレクタ用に最低4バイトが必要です。 コールデータのサイズが4未満の場合、0x5Eへジャンプします。 ![この部分のフローチャート](flowchart-entry.png) -### 0x5Eのハンドラ(非アプリケーションバイナリインターフェース(ABI)コールデータの処理) {#the-handler-at-0x5e-for-non-abi-call-data} +### 0x5Eのハンドラ (非ABIコールデータ用) {#the-handler-at-0x5e-for-non-abi-call-data} | オフセット | オペコード | -| -----:| ------------ | +| ----: | ------------ | | 5E | JUMPDEST | -| 5F | CALLDATASIZE | +| 5E | CALLDATASIZE | | 60 | PUSH2 0x007c | | 63 | JUMPI | -このスニペットは、`JUMPDEST`で始まります。 イーサリアム仮想マシン(EVM)プログラムは、`JUMPDEST`ではないオペコードにジャンプした場合に例外を投げます。 次に、CALLDATASIZEを確認し、それが「true」の場合(ゼロではない場合)、0x7Cにジャンプします。 これについては後述します。 +このスニペットは、JUMPDESTで始まります。 イーサリアム仮想マシン(EVM)プログラムは、`JUMPDEST`ではないオペコードにジャンプした場合に例外を投げます。 次に、CALLDATASIZEを確認し、それが「true」の場合(ゼロではない場合)、0x7Cにジャンプします。 これについては後述します。 -| オフセット | オペコード | スタック(オペコードの後) | -| -----:| ---------- | --------------------------------------------------------------------- | -| 64 | CALLVALUE | 呼び出しによって[Wei](/glossary/#wei)が提供されます。 Solidityでは、`msg.value`が呼び出されます。 | -| 65 | PUSH1 0x06 | 6 CALLVALUE | -| 67 | PUSH1 0x00 | 0 6 CALLVALUE | -| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE | -| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE | -| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE | +| オフセット | オペコード | スタック(オペコードの後) | +| ----: | ---------- | -------------------------------------------------------------------------------------- | +| 64 | CALLVALUE | 呼び出しによって提供された[Wei](/glossary/#wei)。 Solidityでは`msg.value`と呼ばれます | +| 65 | PUSH1 0x06 | 6 CALLVALUE | +| 67 | PUSH1 0x00 | 0 6 CALLVALUE | +| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE | +| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE | +| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE | -コールデータがない場合、Storage[6]の値を読み取ります。 このStorage[6] の値はまだわかりませんが、コールデータなしで受信したコントラクトのトランザクションを探すことはできます。 コールデータなしで(つまりメソッドなしで)ETHを送金するだけのトランザクションの場合、Etherscanに`Transfer`メソッドがあります。 実際、[コントラクトが受信した最初のトランザクション](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7)は、送金(transfer)です。 +コールデータがない場合、Storage[6]の値を読み取ります。 このStorage[6]の値はまだわかりませんが、コールデータなしで受信したコントラクトのトランザクションを探すことはできます。 コールデータなしで(つまりメソッドなしで)ETHを送金するだけのトランザクションの場合、Etherscanに`Transfer`メソッドがあります。 実際、[コントラクトが受け取った最初のトランザクション](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7)は送金です。 -このトランザクションを調べるには、「**Click to show more**」をクリックします。コールデータ(Input Dataと表示される)が実際に空(`0x`)であることが分かります。 また、値が1.559ETHであることに留意してください。これに関しては、後述します。 +このトランザクションを調べ、「**Click to see More**」をクリックすると、コールデータ(インプットデータ)が実際に空(`0x`)であることが分かります。 また、値が1.559ETHであることに留意してください。これに関しては、後述します。 -![コールデータが空](calldata-empty.png) +![コールデータが空である](calldata-empty.png) -次に「**State**」タブをクリックし、リバースエンジニアリングしているコントラクト(0x2510...)を展開します。 トランザクション中に `Storage[6]` が変更されたことが分かります。「Hex」から「**Number**」に変更すると、次のコントラクトの値に応じてweiに変換された値、1,559,000,000,000,000,000になります(分かりやすくするためにコンマを追加しています) 。 +次に、**State**タブをクリックし、リバースエンジニアリングしているコントラクト(0x2510...)を展開します。 トランザクション中に`Storage[6]`が変更されたことが分かります。「Hex」から**Number**に変更すると、次のコントラクトの値に応じてweiに変換された値、1,559,000,000,000,000,000になります(分かりやすくするためにコンマを追加しています)。 ![Storage[6]の変化](storage6.png) -[同時期の他の`Transfer`トランザクション](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange)によって引き起こされた状態変更を確認すると、`Storage[6]`がしばらくの間、コントラクトの値を追跡していたことが分かります。 これを今から`Value*`と呼びます。 アスタリスク (`*`) は、この変数が何をするかまだ_分からない_ことを思い起こさせます。しかし、コントラクトの値を追跡するだけのものではありません。`ADDRESS BALANCE`を使用してアカウント残高を取得できる場合には、非常に高価なストレージを使う必要がないからです。 最初のオペコードは、コントラクト自体のアドレスをプッシュ(PUSH)します。 2番目のオペコードは、スタックの上部にあるアドレスを読み込み、そのアドレスの残高で置き換えます。 +[同期間の他の`Transfer`トランザクション](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange)によるステートの変更を見ると、`Storage[6]`がしばらくの間コントラクトの値を追跡していたことがわかります。 これを今から`Value*`と呼びます。 アスタリスク(`*`)は、この変数がまだ何をするかわからないことを示しています。しかし、これは単にコントラクトの値を追跡するためだけのものではありません。なぜなら、`ADDRESS BALANCE`を使ってアカウントの残高を取得できるのに、非常に高価なストレージを使う必要はないからです。 最初のオペコードは、コントラクト自体のアドレスをプッシュします。 2番目のオペコードは、スタックの上部にあるアドレスを読み込み、そのアドレスの残高で置き換えます。 -| オフセット | オペコード | スタック | -| -----:| ------------ | --------------------------------------------- | +| オフセット | オペコード | スタック | +| ----: | ------------ | ------------------------------------------- | | 6C | PUSH2 0x0075 | 0x75 Value\* CALLVALUE 0 6 CALLVALUE | | 6F | SWAP2 | CALLVALUE Value\* 0x75 0 6 CALLVALUE | | 70 | SWAP1 | Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 71 | PUSH2 0x01a7 | 0x01A7 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 74 | JUMP | | +| 74 | JUMP | | -ジャンプ先(JUMPDEST)でも、このコードのトレースを続けます。 +ジャンプ先でも、このコードのトレースを続けます。 -| オフセット | オペコード | スタック | -| -----:| ---------- | ------------------------------------------------------------- | +| オフセット | オペコード | スタック | +| ----: | ---------- | ----------------------------------------------------------- | | 1A7 | JUMPDEST | Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 1A8 | PUSH1 0x00 | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 1AA | DUP3 | CALLVALUE 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 1AB | NOT | 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -`NOT`は、ビットごとのNOTであるため、コール値内の全てのビット値を反転します。 +`NOT`はビットごとの演算であるため、コール値内の全てのビット値を反転します。 -| オフセット | オペコード | スタック | -| -----:| ------------ | ------------------------------------------------------------------------------- | -| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| オフセット | オペコード | スタック | +| ----: | ------------ | ---------------------------------------------------------------------------------------------------- | +| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | +| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 1AE | ISZERO | Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 1AF | PUSH2 0x01df | 0x01DF Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | -| 1B2 | JUMPI | | +| 1B2 | JUMPI | | -`Value*`の値が、2^256-CALLVALUE-1以下の場合にジャンプ(JUMP)します。 これは、オーバーフローを防ぐためのロジックに見えます。 実際に、オフセット0X01DEでいくつかの無意味な操作(例: 削除される寸前にメモリへの書き込み)をした後、オーバーフローが検出されると、標準の動作としてコントラクトが元に戻されます。 +`Value*`の値が、2^256-CALLVALUE-1以下の場合にジャンプします。 これは、オーバーフローを防ぐためのロジックに見えます。 実際に、オフセット0x01DEでいくつかの無意味な操作(例: 削除される寸前にメモリへの書き込み)をした後、オーバーフローが検出されると、標準の動作としてコントラクトが元に戻されます。 このようなオーバーフローが発生する可能性は、非常に低いことに留意してください。これは、コール値に`Value*`を加えたものが、2^256 wei(約10^59 ETH)と同等になる必要があるためです。 [ETHの総供給量は、この記事の執筆時点で2億未満です](https://etherscan.io/stat/supply)。 -| オフセット | オペコード | スタック | -| -----:| -------- | ------------------------------------------- | +| オフセット | オペコード | スタック | +| ----: | -------- | ----------------------------------------- | | 1DF | JUMPDEST | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 1E0 | POP | Value\* CALLVALUE 0x75 0 6 CALLVALUE | | 1E1 | ADD | Value\*+CALLVALUE 0x75 0 6 CALLVALUE | | 1E2 | SWAP1 | 0x75 Value\*+CALLVALUE 0 6 CALLVALUE | -| 1E3 | JUMP | | +| 1E3 | JUMP | | ここに到達した場合、`Value* + CALLVALUE`を取得して、オフセット0x75へジャンプします。 -| オフセット | オペコード | スタック | -| -----:| -------- | --------------------------------- | +| オフセット | オペコード | スタック | +| ----: | -------- | ------------------------------- | | 75 | JUMPDEST | Value\*+CALLVALUE 0 6 CALLVALUE | | 76 | SWAP1 | 0 Value\*+CALLVALUE 6 CALLVALUE | | 77 | SWAP2 | 6 Value\*+CALLVALUE 0 CALLVALUE | -| 78 | SSTORE | 0 CALLVALUE | +| 78 | SSTORE | 0 CALLVALUE | ここに到達した場合(コールデータが空である必要があります)、`Value*`にコール値を加えます。 これは、`Transfer`トランザクションが行うことと一致しています。 | オフセット | オペコード | -| -----:| ----- | +| ----: | ----- | | 79 | POP | | 7A | POP | | 7B | STOP | @@ -156,7 +154,7 @@ Etherscanにアクセスするとコントラクトのオペコードを入手 まとめると、最初のコードのフローチャートは次のようになります。 -![エントリポイントフローチャート](flowchart-entry.png) +![エントリーポイントのフローチャート](flowchart-entry.png) ## 0x7Cのハンドラ {#the-handler-at-0x7c} @@ -164,71 +162,71 @@ Etherscanにアクセスするとコントラクトのオペコードを入手 ここへ到達するのは、次のような場合です。 -- (オフセット0x63から)1バイト、2バイトまたは3バイトのコールデータががある場合 +- (オフセット0x63から)1バイト、2バイトまたは3バイトのコールデータがある場合 - (オフセット0x42と0x5Dから)メソッドのシグネチャが不明な場合 -| オフセット | オペコード | スタック | -| -----:| ------------ | -------------------- | -| 7C | JUMPDEST | | -| 7D | PUSH1 0x00 | 0x00 | -| 7F | PUSH2 0x009d | 0x9D 0x00 | -| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 | +| オフセット | オペコード | スタック | +| ----: | ------------ | ------------------------------------------------------------------------ | +| 7C | JUMPDEST | | +| 7D | PUSH1 0x00 | 0x00 | +| 7F | PUSH2 0x009d | 0x9D 0x00 | +| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 | | 84 | SLOAD | Storage[3] 0x9D 0x00 | これは別のストレージセルです。このセルはどのトランザクションにも見つからなかったので、これが何を意味しているのか理解するのは困難です。 しかし、以下のコードがこれを明確にします。 -| オフセット | オペコード | スタック | -| -----:| ------------------------------------------------- | ------------------------------- | +| オフセット | オペコード | スタック | +| ----: | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | 85 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xff....ff Storage[3] 0x9D 0x00 | -| 9A | AND | Storage[3]-as-address 0x9D 0x00 | +| 9A | AND | Storage[3]-as-address 0x9D 0x00 | これらのオペコードは、Storage[3]から読み取った値を160ビットに切り捨てています。これは、イーサリアムアドレスの長さです。 -| オフセット | オペコード | スタック | -| -----:| ----- | ------------------------------- | +| オフセット | オペコード | スタック | +| ----: | ----- | ----------------------------------------------------------------------------------- | | 9B | SWAP1 | 0x9D Storage[3]-as-address 0x00 | | 9C | JUMP | Storage[3]-as-address 0x00 | -次のオペコードに進むため、このジャンプ(JUMP)は不要です。 このコードは、ガス効率が良くありません。 +次のオペコードに進むため、このジャンプは不要です。 このコードは、ガス効率が良くありません。 -| オフセット | オペコード | スタック | -| -----:| ---------- | ------------------------------- | -| 9D | JUMPDEST | Storage[3]-as-address 0x00 | -| 9E | SWAP1 | 0x00 Storage[3]-as-address | -| 9F | POP | Storage[3]-as-address | -| A0 | PUSH1 0x40 | 0x40 Storage[3]-as-address | +| オフセット | オペコード | スタック | +| ----: | ---------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| 9D | JUMPDEST | Storage[3]-as-address 0x00 | +| 9E | SWAP1 | 0x00 Storage[3]-as-address | +| 9F | POP | Storage[3]-as-address | +| A0 | PUSH1 0x40 | 0x40 Storage[3]-as-address | | A2 | MLOAD | Mem[0x40] Storage[3]-as-address | コードの最初で、Mem[0x40]を0x80に設定しました。 その後の0x40を確かめると変更していないことが分かります。つまり、これは0x80であると推測できます。 -| オフセット | オペコード | スタック | -| -----:| ------------ | ------------------------------------------------- | +| オフセット | オペコード | スタック | +| ----: | ------------ | ----------------------------------------------------------------------------------------------------- | | A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-as-address | | A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-as-address | | A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-as-address | | A7 | CALLDATACOPY | 0x80 Storage[3]-as-address | -0x80から始まるすべてのコールデータ(CALLDATA)をメモリにコピーします。 +0x80から始まるすべてのコールデータをメモリにコピーします。 -| オフセット | オペコード | スタック | -| -----:| ------------- | -------------------------------------------------------------------------------- | -| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-as-address | -| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-as-address | -| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AD | DUP6 | Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AE | GAS | GAS Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | -| AF | DELEGATE_CALL | | +| オフセット | オペコード | スタック | +| ----: | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-as-address | +| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-as-address | +| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | +| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | +| AD | DUP6 | Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | +| AE | GAS | GAS Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address | +| AF | DELEGATE_CALL | | -これで、かなり明確になりました。 このコントラクトは、[プロキシ](https://blog.openzeppelin.com/proxy-patterns/)として機能しており、Storage[3] 内のアドレスを呼び出して、実際の作業をしています。 `DELEGATE_CALL`は、別のコントラクトを呼び出しますが、同じストレージ内に留まります。 つまり、委任されたコントラクト(現在のコントラクトがこのコントラクトのプロキシとなります)が、同じストレージスペースにアクセスします。 コール(呼び出し)のパラメータは次の通りです。 +これで、かなり明確になりました。 このコントラクトは[プロキシ](https://blog.openzeppelin.com/proxy-patterns/)として機能しており、Storage[3] 内のアドレスを呼び出して、実際の作業をしています。 `DELEGATE_CALL`は、別のコントラクトを呼び出しますが、同じストレージ内に留まります。 つまり、委任されたコントラクト(現在のコントラクトがこのコントラクトのプロキシとなります)が、同じストレージスペースにアクセスします。 コール(呼び出し)のパラメータは次の通りです。 -- _ガス_: 残りのガス -- _呼び出されたアドレス_: Storage[3]-as-address +- _ガス_: 残りの全ガス +- _呼び出し先アドレス_: Storage[3]-as-address - _コールデータ_: 元のコールデータを配置する、0x80から始まるCALLDATASIZEバイト - _リターンデータ_: なし(0x00 - 0x00)。リターンデータは他の方法で取得(以下を参照) -| オフセット | オペコード | スタック | -| -----:| -------------- | --------------------------------------------------------------------------------------------- | +| オフセット | オペコード | スタック | +| ----: | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | B0 | RETURNDATASIZE | RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | | B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | | B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | @@ -237,73 +235,73 @@ Etherscanにアクセスするとコントラクトのオペコードを入手 ここでは、すべてのリターンデータを0x80から始まるメモリバッファにコピーします。 -| オフセット | オペコード | スタック | -| -----:| ------------ | ---------------------------------------------------------------------------------------------------------------------------- | -| B6 | DUP2 | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | +| オフセット | オペコード | スタック | +| ----: | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| B6 | DUP2 | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | | B7 | DUP1 | (((call success/failure))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | | B8 | ISZERO | (((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | | B9 | PUSH2 0x00c0 | 0xC0 (((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BC | JUMPI | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BD | DUP2 | RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BE | DUP5 | 0x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| BF | RETURN | | +| BC | JUMPI | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | +| BD | DUP2 | RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | +| BE | DUP5 | 0x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | +| BF | RETURN | | -リターンデータをバッファ(0x80～0x80+RETURNDATASIZE)にコピーする呼び出しの後、その呼び出しが成功した場合は、そのバッファを正確に返します(`RETURN`します)。 +リターンデータをバッファ(0x80～0x80+RETURNDATASIZE)にコピーする呼び出しの後、その呼び出しが成功した場合は、そのバッファを正確に返します。 -### DELEGATECALLの失敗 {#delegatecall-failed} +### DELEGATECALL失敗 {#delegatecall-failed} 0xC0に到達した場合は、現在のコントラクトが呼び出したコントラクトが、元に戻された(REVERTされた)ことを意味します。 現在のコントラクトはこのコントラクトの単なるプロキシであるため、現在のコントラクトも同じデータを返して、元に戻す(REVERTする)必要があります。 -| オフセット | オペコード | スタック | -| -----:| -------- | ------------------------------------------------------------------------------------------------------------------- | +| オフセット | オペコード | スタック | +| ----: | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | C0 | JUMPDEST | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | | C1 | DUP2 | RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | | C2 | DUP5 | 0x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address | -| C3 | REVERT | | +| C3 | REVERT | | -そのため、前に`RETURN`で使用した同じバッファ(0x80～0x80+RETURNDATASIZE)を元に戻します(`REVERT`します)。 +そのため、前に`RETURN`で使用した同じバッファ(0x80～0x80+RETURNDATASIZE)を元に戻します(REVERTします)。 -![プロキシするための呼び出しのフローチャート](flowchart-proxy.png) +![プロキシへのコールに関するフローチャート](flowchart-proxy.png) -## アプリケーションバイナリインターフェース(ABI)呼び出し {#abi-calls} +## ABIコール {#abi-calls} -コールデータのサイズが4バイト以上である場合、有効なアプリケーションバイナリインターフェース(ABI)呼び出しである可能性があります。 +コールデータのサイズが4バイト以上である場合、有効なABIコールである可能性があります。 -| オフセット | オペコード | スタック | -| -----:| ------------ | ------------------------------------------------- | -| D | PUSH1 0x00 | 0x00 | -| F | CALLDATALOAD | (((First word (256 bits) of the call data))) | -| 10 | PUSH1 0xe0 | 0xE0 (((First word (256 bits) of the call data))) | -| 12 | SHR | (((first 32 bits (4 bytes) of the call data))) | +| オフセット | オペコード | スタック | +| ----: | ------------ | ------------------------------------------------------------------------------------------------------------- | +| D | PUSH1 0x00 | 0x00 | +| F | CALLDATALOAD | (((コールデータの最初のワード (256ビット)))) | +| 10 | PUSH1 0xe0 | 0xE0 (((コールデータの最初のワード (256ビット)))) | +| 12 | SHR | (((コールデータの最初の32ビット (4バイト)))) | -Etherscanでは、`1C`が未知のオペコードとなっていますが、これは[Etherscanでこの機能が作成された後に追加された](https://eips.ethereum.org/EIPS/eip-145)ため、まだ反映がされていないのが理由です。 [最新のオペコードテーブル](https://github.com/wolflo/evm-opcodes)では、これが右シフトであることが示されています +Etherscanによると`1C`は未知のオペコードですが、これは[Etherscanがこの機能を実装した後に追加された](https://eips.ethereum.org/EIPS/eip-145)もので、まだ更新されていないためです。 [最新のオペコード表](https://github.com/wolflo/evm-opcodes)を見ると、これが右シフトであることがわかります -| オフセット | オペコード | スタック | -| -----:| ---------------- | -------------------------------------------------------------------------------------------------------- | -| 13 | DUP1 | (((first 32 bits (4 bytes) of the call data))) (((first 32 bits (4 bytes) of the call data))) | -| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((first 32 bits (4 bytes) of the call data))) (((first 32 bits (4 bytes) of the call data))) | -| 19 | GT | 0x3CD8045E>first-32-bits-of-the-call-data (((first 32 bits (4 bytes) of the call data))) | -| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>first-32-bits-of-the-call-data (((first 32 bits (4 bytes) of the call data))) | -| 1D | JUMPI | (((first 32 bits (4 bytes) of the call data))) | +| オフセット | オペコード | スタック | +| ----: | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 13 | DUP1 | (((コールデータの最初の32ビット (4バイト)))) (((コールデータの最初の32ビット (4バイト)))) | +| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((コールデータの最初の32ビット (4バイト)))) (((コールデータの最初の32ビット (4バイト)))) | +| 19 | GT | 0x3CD8045E>コールデータの最初の32ビット (((コールデータの最初の32ビット (4バイト)))) | +| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>コールデータの最初の32ビット (((コールデータの最初の32ビット (4バイト)))) | +| 1D | JUMPI | (((コールデータの最初の32ビット (4バイト)))) | -このようにメソッドシグネチャのマッチングテストを2つに分割することで、平均的にテストの半分を節約できます。 その直後のコードと0x43のコードは、コールデータの最初の32ビットの複製(`DUP1`)、プッシュ(`PUSH4 (((method signature>`)、`EQ`を実行し等式を判定、メソッドシグネチャがマッチした場合は`JUMPI`、という同じパターンをたどります。 以下に、メソッドシグネチャ、そのアドレス、既知の場合は[対応するメソッド定義](https://www.4byte.directory/)を示します。 +このようにメソッドシグネチャのマッチングテストを2つに分割することで、平均的にテストの半分を節約できます。 その直後のコードと0x43のコードは、コールデータの最初の32ビットの複製(`DUP1`)、プッシュ(`PUSH4 (((method signature)`)、`EQ`を実行し等式を判定、メソッドシグネチャがマッチした場合は`JUMPI`、という同じパターンをたどります。 以下に、メソッドシグネチャ、そのアドレス、既知の場合は[対応するメソッド定義](https://www.4byte.directory/)を示します。 -| メソッド | メソッドシグネチャ | ジャンプ先のオフセット | -| -------------------------------------------------------------------------------------- | ---------- | ----------- | +| メソッド | メソッドシグネチャ | ジャンプ先のオフセット | +| --------------------------------------------------------------------------------------------------------- | ---------- | ----------- | | [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 | -| ??? | 0x81e580d3 | 0x0138 | +| ??? | 0x81e580d3 | 0x0138 | | [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 | -| ??? | 0x1f135823 | 0x00C4 | +| ??? | 0x1f135823 | 0x00C4 | | [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED | 一致するものが見つからない場合、そのコードは、現在のコントラクトがプロキシとなっているコントラクトに一致するものがあることを期待して、[0x7Cのプロキシハンドラ](#the-handler-at-0x7c)へジャンプします。 -![アプリケーションバイナリインターフェース(ABI)呼び出しのフローチャート](flowchart-abi.png) +![ABIコールのフローチャート](flowchart-abi.png) ## splitter() {#splitter} | オフセット | オペコード | スタック | -| -----:| ------------ | ----------------------------- | +| ----: | ------------ | ----------------------------- | | 103 | JUMPDEST | | | 104 | CALLVALUE | CALLVALUE | | 105 | DUP1 | CALLVALUE CALLVALUE | @@ -314,38 +312,38 @@ Etherscanでは、`1C`が未知のオペコードとなっていますが、こ | 10D | DUP1 | 0x00 0x00 CALLVALUE | | 10E | REVERT | | -この関数が最初に行うことは、呼び出しがETHを送金していないことを確認することです。 この関数は、[`payable`](https://solidity-by-example.org/payable/)ではありません。 誰かがETHを送金してきた場合は、何かの間違いです。ETHを戻せなくなる前に元に戻す(`REVERT`する)必要があります。 - -| オフセット | オペコード | スタック | -| -----:| ------------------------------------------------- | --------------------------------------------------------------------------- | -| 10F | JUMPDEST | | -| 110 | POP | | -| 111 | PUSH1 0x03 | 0x03 | -| 113 | SLOAD | (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 114 | PUSH1 0x40 | 0x40 (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 116 | MLOAD | 0x80 (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] a.k.a the contract for which we are a proxy))) | -| 12D | SWAP2 | (((Storage[3] a.k.a the contract for which we are a proxy))) 0xFF...FF 0x80 | -| 12E | AND | ProxyAddr 0x80 | -| 12F | DUP2 | 0x80 ProxyAddr 0x80 | -| 130 | MSTORE | 0x80 | - -0x80にはプロキシアドレスが含まれるようになりました。 +この関数が最初に行うことは、呼び出しがETHを送金していないことを確認することです。 この関数は[`payable`](https://solidity-by-example.org/payable/)ではありません。 誰かがETHを送金してきた場合は、何かの間違いです。ETHを戻せなくなる前に`REVERT`して回避する必要があります。 + +| オフセット | オペコード | スタック | +| ----: | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 10F | JUMPDEST | | +| 110 | POP | | +| 111 | PUSH1 0x03 | 0x03 | +| 113 | SLOAD | (((Storage[3]、別名、このコントラクトがプロキシとなっているコントラクト))) | +| 114 | PUSH1 0x40 | 0x40 (((Storage[3]、別名、このコントラクトがプロキシとなっているコントラクト))) | +| 116 | MLOAD | 0x80 (((Storage[3]、別名、このコントラクトがプロキシとなっているコントラクト))) | +| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3]、別名、このコントラクトがプロキシとなっているコントラクト))) | +| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3]、別名、このコントラクトがプロキシとなっているコントラクト))) | +| 12D | SWAP2 | (((Storage[3]、別名、このコントラクトがプロキシとなっているコントラクト))) 0xFF...FF 0x80 | +| 12E | AND | ProxyAddr 0x80 | +| 12F | DUP2 | 0x80 ProxyAddr 0x80 | +| 130 | MSTORE | 0x80 | + +そして0x80にはプロキシアドレスが含まれるようになりました | オフセット | オペコード | スタック | -| -----:| ------------ | --------- | +| ----: | ------------ | --------- | | 131 | PUSH1 0x20 | 0x20 0x80 | | 133 | ADD | 0xA0 | | 134 | PUSH2 0x00e4 | 0xE4 0xA0 | | 137 | JUMP | 0xA0 | -### E4のコード {#the-e4-code} +### E4コード {#the-e4-code} -これらの行を見るのは初めてですが、他のメソッドと共有されています(以下を参照)。 スタックXの値を呼び出します。`splitter()`で、このXの値が0xA0であることを覚えておいてください。 +これらの行を見るのは初めてですが、他のメソッドと共有されています(以下を参照)。 スタックの値をXと呼びます。`splitter()`で、このXの値が0xA0であることを覚えておいてください。 | オフセット | オペコード | スタック | -| -----:| ---------- | ----------- | +| ----: | ---------- | ----------- | | E4 | JUMPDEST | X | | E5 | PUSH1 0x40 | 0x40 X | | E7 | MLOAD | 0x80 X | @@ -355,7 +353,7 @@ Etherscanでは、`1C`が未知のオペコードとなっていますが、こ | EB | SWAP1 | 0x80 X-0x80 | | EC | RETURN | | -したがって、このコードは、スタック(X)内のメモリのポインターを受け取ります。これにより、コントラクトが0x80～Xまでのバッファを返します(`RETURN`します)。 +したがって、このコードは、スタック(X)内のメモリのポインターを受け取ります。これにより、コントラクトが0x80～Xまでのバッファを`RETURN`します。 `splitter()`の場合、これは現在のコントラクトがプロキシとなっているアドレスを返します。 `RETURN`は、0x80～0x9Fのバッファを返します。これは、このデータを書き込んだ場所です(上記のオフセット0x130)。 @@ -363,22 +361,22 @@ Etherscanでは、`1C`が未知のオペコードとなっていますが、こ オフセット0x158～0x163のコードは、`splitter()`の0x103～0x10Eで見たものと(`JUMPI`の宛先以外は)同一であるため、`currentWindow()`も同様に`payable`ではないことが分かります。 -| オフセット | オペコード | スタック | -| -----:| ------------ | -------------------- | -| 164 | JUMPDEST | | -| 165 | POP | | -| 166 | PUSH2 0x00da | 0xDA | -| 169 | PUSH1 0x01 | 0x01 0xDA | +| オフセット | オペコード | スタック | +| ----: | ------------ | ------------------------------------------------------------------------ | +| 164 | JUMPDEST | | +| 165 | POP | | +| 166 | PUSH2 0x00da | 0xDA | +| 169 | PUSH1 0x01 | 0x01 0xDA | | 16B | SLOAD | Storage[1] 0xDA | | 16C | DUP2 | 0xDA Storage[1] 0xDA | | 16D | JUMP | Storage[1] 0xDA | -### DAのコード {#the-da-code} +### DAコード {#the-da-code} -このコードもまた他のメソッドと共有されます。 スタックYの値を呼び出します。`currentWindow()`で、このYの値がStorage[1]であることを覚えておいてください。 +このコードもまた他のメソッドと共有されます。 スタックの値をYと呼びます。`currentWindow()`で、このYの値がStorage[1]であることを覚えておいてください。 | オフセット | オペコード | スタック | -| -----:| ---------- | ---------------- | +| ----: | ---------- | ---------------- | | DA | JUMPDEST | Y 0xDA | | DB | PUSH1 0x40 | 0x40 Y 0xDA | | DD | MLOAD | 0x80 Y 0xDA | @@ -389,7 +387,7 @@ Etherscanでは、`1C`が未知のオペコードとなっていますが、こ 0x80～0x9FにYを書き込みます。 | オフセット | オペコード | スタック | -| -----:| ---------- | -------------- | +| ----: | ---------- | -------------- | | E1 | PUSH1 0x20 | 0x20 0x80 0xDA | | E3 | ADD | 0xA0 0xDA | @@ -399,184 +397,184 @@ Etherscanでは、`1C`が未知のオペコードとなっていますが、こ オフセット0xED～0xF8のコードは、`splitter()`の0x103～0x10Eで見たものと(`JUMPI`の宛先以外は)同一であるため、`merkleRoot()`も同様に`payable`ではないことが分かります。 -| オフセット | オペコード | スタック | -| -----:| ------------ | -------------------- | -| F9 | JUMPDEST | | -| FA | POP | | -| FB | PUSH2 0x00da | 0xDA | -| FE | PUSH1 0x00 | 0x00 0xDA | +| オフセット | オペコード | スタック | +| ----: | ------------ | ------------------------------------------------------------------------ | +| F9 | JUMPDEST | | +| FA | POP | | +| FB | PUSH2 0x00da | 0xDA | +| FE | PUSH1 0x00 | 0x00 0xDA | | 100 | SLOAD | Storage[0] 0xDA | | 101 | DUP2 | 0xDA Storage[0] 0xDA | | 102 | JUMP | Storage[0] 0xDA | -ジャンプ(JUMP)の後に何が起こるかは、[すでに分かっています](#the-da-code)。 つまり、`merkleRoot()`は、Storage[0]を返します。 +ジャンプの後に何が起こるかは、[すでに分かっています](#the-da-code)。 つまり、`merkleRoot()`は、Storage[0]を返します。 ## 0x81e580d3 {#0x81e580d3} -オフセット0x138～0x143のコードは、`splitter()`の0x103～0x10Eで見たものと(`JUMPI`の宛先以外は)同一であるため、この関数も同様に`payable`ではないことが分かりります。 - -| オフセット | オペコード | スタック | -| -----:| ------------ | ------------------------------------------------------------ | -| 144 | JUMPDEST | | -| 145 | POP | | -| 146 | PUSH2 0x00da | 0xDA | -| 149 | PUSH2 0x0153 | 0x0153 0xDA | -| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA | -| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA | -| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA | -| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA | -| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA | -| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +オフセット0x138～0x143のコードは、`splitter()`の0x103～0x10Eで見たものと(`JUMPI`の宛先以外は)同一であるため、この関数も同様に`payable`ではないことが分かります。 + +| オフセット | オペコード | スタック | +| ----: | ------------ | ----------------------------------------------------------------------------- | +| 144 | JUMPDEST | | +| 145 | POP | | +| 146 | PUSH2 0x00da | 0xDA | +| 149 | PUSH2 0x0153 | 0x0153 0xDA | +| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA | +| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA | +| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA | +| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA | +| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA | +| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 197 | SLT | CALLDATASIZE-4<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | この関数は、コールデータに少なくとも32バイト(1ワード)を必要とするようです。 | オフセット | オペコード | スタック | -| -----:| ------ | -------------------------------------------- | +| ----: | ------ | -------------------------------------------- | | 19D | DUP1 | 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA | | 19E | DUP2 | 0x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA | | 19F | REVERT | | コールデータを取得しなかった場合、トランザクションはリターンデータなしで元に戻されます。 -この関数が、必要なコールデータを_取得した_場合、何が起こるか見ていきましょう。 +この関数が、必要なコールデータを取得した場合、何が起こるか見ていきましょう。 -| オフセット | オペコード | スタック | -| -----:| ------------ | ---------------------------------------- | -| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | -| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA | +| オフセット | オペコード | スタック | +| ----: | ------------ | ----------------------------------------------------------- | +| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA | +| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA | | 1A2 | CALLDATALOAD | calldataload(4) CALLDATASIZE 0x0153 0xDA | -`calldataload(4)`は、メソッドシグネチャの_後にある_コールデータの最初のワードです。 - -| オフセット | オペコード | スタック | -| -----:| ------------ | ---------------------------------------------------------------------------- | -| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA | -| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA | -| 1A5 | POP | 0x0153 calldataload(4) 0xDA | -| 1A6 | JUMP | calldataload(4) 0xDA | -| 153 | JUMPDEST | calldataload(4) 0xDA | -| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA | -| 157 | JUMP | calldataload(4) 0xDA | -| 16E | JUMPDEST | calldataload(4) 0xDA | -| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA | -| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA | -| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA | -| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | -| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | +`calldataload(4)`は、メソッドシグネチャの_後_にあるコールデータの最初のワードです + +| オフセット | オペコード | スタック | +| ----: | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA | +| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA | +| 1A5 | POP | 0x0153 calldataload(4) 0xDA | +| 1A6 | JUMP | calldataload(4) 0xDA | +| 153 | JUMPDEST | calldataload(4) 0xDA | +| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA | +| 157 | JUMP | calldataload(4) 0xDA | +| 16E | JUMPDEST | calldataload(4) 0xDA | +| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA | +| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA | +| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA | +| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | +| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA | | 175 | LT | calldataload(4)\)`、もう一つが`isClaimed()`であり、エアドロップコントラクトのように見えます。 ここからは、オペコードごとに調べる代わりに、[デコンパイラ](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761)を使用します。デコンパイラは、このコントラクトの3つの関数について利用可能な結果を生成します。 他の関数のリバースエンジニアリングは、読者の演習として残しておきます。 @@ -585,160 +583,80 @@ calldataload(4)がStorage[4]より小さい場合、次のコードになりま この関数についてデコンパイラが提供した内容は、次のとおりです。 ```python -def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable: - require calldata.size - 4 >=′ 64 - if _param1 and _param2 > -1 / _param1: - revert with 0, 17 - return (_param1 * _param2 / 100 * 10^6) +def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:\n require calldata.size - 4 >=′ 64\n if _param1 and _param2 > -1 / _param1:\n revert with 0, 17\n return (_param1 * _param2 / 100 * 10^6) ``` 最初の`require`では、コールデータ内に2つのパラメータにとって十分なサイズ、つまり関数シグネチャの4バイトに加え少なくとも64バイトあるかどうかをテストしています。 そうでない場合、問題があるのは明らかです。 -`if`文は、`_param1`がゼロでないこと、さらに`_param1 * _param2`が負でないことを確認していると思われます。 これは、オーバー(アンダー)フローを防止している可能性があります。 +`if`文は、`_param1`がゼロでないこと、さらに`_param1 * _param2`が負でないことを確認していると思われます。 これは、ラップアラウンドを防ぐためでしょう。 最後に、この関数はスケーリング値を返します。 ### claim {#claim} -デコンパイラが作成するコードは複雑であり、すべてが重要なわけではありません。 役立つ情報を提供していると思われる行に焦点を当てるので、ある程度スキップします。 +デコンパイラが作成するコードは複雑であり、すべてが重要なわけではありません。 役立つ情報を提供していると思われる行に焦点を当てるので、一部をスキップします。 ```python -def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable: - ... - require _param2 == addr(_param2) - ... - if currentWindow <= _param1: - revert with 0, 'cannot claim for a future window' +def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:\n ...\n require _param2 == addr(_param2)\n ...\n if currentWindow <= _param1:\n revert with 0, '将来のウィンドウに対して請求することはできません' ``` ここでは、重要事項が2つあります。 -- `_param2`は、`uint256`として宣言されているが、実際にはアドレスである -- `_param1`は、請求対象のウィンドウであり、`currentWindow`であるか、前のウィンドウである必要がある +- `_param2`は、`uint256`として宣言されていますが、実際にはアドレスです +- `_param1`は、請求対象のウィンドウであり、`currentWindow`であるか、それ以前のウィンドウである必要があります。 ```python - ... - if stor5[_claimWindow][addr(_claimFor)]: - revert with 0, 'Account already claimed the given window' + ...\n if stor5[_claimWindow][addr(_claimFor)]:\n revert with 0, 'アカウントはすでに指定されたウィンドウで請求済みです' ``` そのため、Storage[5]はウィンドウとアドレスの配列であり、アドレスがウィンドウの報酬を請求したかどうかが分かります。 ```python - ... - idx = 0 - s = 0 - while idx < _param4.length: - ... - if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]: - mem[mem[64] + 32] = mem[(32 * idx) + 296] - ... - s = sha3(mem[_62 + 32 len mem[_62]]) - continue - ... - s = sha3(mem[_66 + 32 len mem[_66]]) - continue - if unknown2eb4a7ab != s: - revert with 0, 'Invalid proof' + ...\n idx = 0\n s = 0\n while idx < _param4.length:\n ...\n if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:\n mem[mem[64] + 32] = mem[(32 * idx) + 296]\n ...\n s = sha3(mem[_62 + 32 len mem[_62]])\n continue\n ...\n s = sha3(mem[_66 + 32 len mem[_66]])\n continue\n if unknown2eb4a7ab != s:\n revert with 0, '無効な証明です' ``` -`unknown2eb4a7ab`は、実際には`merkleRoot()`関数であることが分かっています。したがって、このコードは[マークルプルーフ](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5)を検証していると思われます。 これは、`_param4`がマークルプルーフであることを意味します。 +`unknown2eb4a7ab`は実際には`merkleRoot()`関数であることがわかっているので、このコードは[マークル証明](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5)を検証しているようです。 これは、`_param4`がマークル証明であることを意味します。 ```python - call addr(_param2) with: - value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei - gas 30000 wei + call addr(_param2) with:\n value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei\n gas 30000 wei ``` -これは、コントラクトが自身のETHを別のアドレス(コントラクトまたは外部所有アカウント)に送金する方法です。 送金する金額の値で呼び出します。 これはETHのエアドロップであると思われます。 +これは、コントラクトが自身のETHを別のアドレス(コントラクトまたは外部所有)に送金する方法です。 送金する金額の値で呼び出します。 これはETHのエアドロップであると思われます。 ```python - if not return_data.size: - if not ext_call.success: - require ext_code.size(stor2) - call stor2.deposit() with: - value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei + if not return_data.size:\n if not ext_call.success:\n require ext_code.size(stor2)\n call stor2.deposit() with:\n value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei ``` -下の2行は、Storage[2] も呼び出すコントラクトであることを示しています。 [コンストラクタのトランザクションを見ると](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange)、このコントラクトは[0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)であり、[ソースコードがEtherscanにアップロードされている](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code)ラップドイーサ(WETH)コントラクトであることが分かります。 +下の2行は、Storage[2]も呼び出すコントラクトであることを示しています。 [コンストラクタのトランザクション](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange)を見ると、このコントラクトが[0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) (Wrapped Etherコントラクトで、[そのソースコードはEtherscanにアップロードされています](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code)) であることがわかります。 -このコントラクトは、`_param2`にETHを送金しようとしていると思われます。 送金できれば問題ありません。 送金できない場合は、[ラップドイーサ(WETH)](https://weth.io/)を送金しようとします。 `_param2`が外部所有アカウント(EOA)である場合、必ずETHを受け取ることができますが、コントラクトはETHの受け取りを拒否することができます。 しかし、ラップドイーサ(WETH)はERC-20であるため、コントラクトは受け取りを拒否できません。 +このコントラクトは、`_param2`にETHを送金しようとしていると思われます。 送金できれば問題ありません。 そうでなければ、[WETH](https://weth.tkn.eth.limo/)を送ろうと試みます。 `_param2`が外部所有アカウント (EOA)である場合、必ずETHを受け取ることができますが、コントラクトはETHの受け取りを拒否することができます。 しかし、WETHはERC-20であるため、コントラクトは受け取りを拒否できません。 ```python - ... - log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success) + ...\n log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success) ``` -関数の最後に、ログエントリが生成されていることがわかります。 [生成されたログエントリを確認し](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events)、`0xdbd5...`で始まるトピックでフィルタリングします。 [そのようなエントリを生成したトランザクションの1つをクリックすると](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274)、実際に請求のように見えることがわかります。アカウントは、リバースエンジニアリングしているコントラクトにメッセージを送信し、代わりにETHを取得しています。 +関数の最後に、ログエントリが生成されていることがわかります。 [生成されたログエントリ](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events)を確認し、`0xdbd5...`で始まるトピックでフィルタリングします。 [そのようなエントリを生成したトランザクションの1つをクリックすると](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274)、実際に請求のように見えることがわかります。アカウントは、リバースエンジニアリングしているコントラクトにメッセージを送信し、代わりにETHを取得しています。 ![請求トランザクション](claim-tx.png) ### 1e7df9d3 {#1e7df9d3} -この関数は、上記の[`claim`](#claim)と非常に似ています。 この関数はマークルプルーフも同様に確認し、ETHを最初に送金しようと試み、同じタイプのログエントリを生成します。 +この関数は、上記の[`claim`](#claim)と非常に類似しています。 この関数はマークル証明も同様に確認し、ETHを最初に送金しようと試み、同じタイプのログエントリを生成します。 ```python -def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable: - ... - idx = 0 - s = 0 - while idx < _param3.length: - if idx >= mem[96]: - revert with 0, 50 - _55 = mem[(32 * idx) + 128] - if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]: - ... - s = sha3(mem[_58 + 32 len mem[_58]]) - continue - mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) - ... - if unknown2eb4a7ab != s: - revert with 0, 'Invalid proof' - ... - call addr(_param1) with: - value s wei - gas 30000 wei - if not return_data.size: - if not ext_call.success: - require ext_code.size(stor2) - call stor2.deposit() with: - value s wei - gas gas_remaining wei - ... - log 0xdbd5389f: addr(_param1), s, bool(ext_call.success) +def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:\n ...\n idx = 0\n s = 0\n while idx < _param3.length:\n if idx >= mem[96]:\n revert with 0, 50\n _55 = mem[(32 * idx) + 128]\n if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:\n ...\n s = sha3(mem[_58 + 32 len mem[_58]])\n continue\n mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])\n ...\n if unknown2eb4a7ab != s:\n revert with 0, '無効な証明です'\n ...\n call addr(_param1) with:\n value s wei\n gas 30000 wei\n if not return_data.size:\n if not ext_call.success:\n require ext_code.size(stor2)\n call stor2.deposit() with:\n value s wei\n gas gas_remaining wei\n ...\n log 0xdbd5389f: addr(_param1), s, bool(ext_call.success) ``` -主な違いは、最初のパラメータです。引き出しを行うためのウィンドウがありません。 代わりに、請求対象となるすべてのウィンドウについてのループがあります。 +主な違いは、最初のパラメータである引き出しを行うためのウィンドウがないことです。 代わりに、請求対象となるすべてのウィンドウについてのループがあります。 ```python - idx = 0 - s = 0 - while idx < currentWindow: - ... - if stor5[mem[0]]: - if idx == -1: - revert with 0, 17 - idx = idx + 1 - s = s - continue - ... - stor5[idx][addr(_param1)] = 1 - if idx >= unknown81e580d3.length: - revert with 0, 50 - mem[0] = 4 - if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]: - revert with 0, 17 - if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6): - revert with 0, 17 - if idx == -1: - revert with 0, 17 - idx = idx + 1 - s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6) - continue + idx = 0\n s = 0\n while idx < currentWindow:\n ...\n if stor5[mem[0]]:\n if idx == -1:\n revert with 0, 17\n idx = idx + 1\n s = s\n continue\n ...\n stor5[idx][addr(_param1)] = 1\n if idx >= unknown81e580d3.length:\n revert with 0, 50\n mem[0] = 4\n if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:\n revert with 0, 17\n if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):\n revert with 0, 17\n if idx == -1:\n revert with 0, 17\n idx = idx + 1\n s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)\n continue ``` -そのため、すべてのウィンドウについて請求する`claim`を少し変えたもののように思われます。 +そのため、すべてのウィンドウについて請求する`claim`の変種のようです。 -## まとめ {#conclusion} +## 結論 {#conclusion} ここまでで、オペコードまたは(動作する場合は)デコンパイラを使用して、ソースコードが入手できないコントラクトを理解する方法を身に付けられたはずです。 この記事の長さが示しているように、コントラクトのリバースエンジニアリングは簡単ではありません。しかしながら、セキュリティが不可欠なシステムでは、コントラクトが想定した通りに動作しているかを検証できることは、非常に重要なスキルです。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/ja/developers/tutorials/run-node-raspberry-pi/index.md index e45b9dfffcb..f4d0dd0b0c1 100644 --- a/public/content/translations/ja/developers/tutorials/run-node-raspberry-pi/index.md +++ b/public/content/translations/ja/developers/tutorials/run-node-raspberry-pi/index.md @@ -1,12 +1,8 @@ --- -title: マイクロSDカードに書き込んでRaspberry Pi 4をノードにする方法 -description: Raspberry Pi 4に書き込み、イーサネットケーブル、SSDをそれぞれ接続してから電源を入れるとRaspberry Pi 4がフルイーサリアムノードとバリデータになります。 +title: "Raspberry Pi 4でイーサリアムノードを実行する" +description: "Raspberry Pi 4に書き込み、イーサネットケーブル、SSDをそれぞれ接続してから電源を入れるとRaspberry Pi 4がフルイーサリアムノードとバリデータになります。" author: "EthereumOnArm" -tags: - - "クライアント" - - "実行レイヤ" - - "コンセンサスレイヤー" - - "ノード" +tags: [ "クライアント", "実行レイヤー", "コンセンサスレイヤー", "ノード" ] lang: ja skill: intermediate published: 2022-06-10 @@ -20,18 +16,18 @@ Ethereum on Armを使用してRaspberry Piをイーサリアムノードにす - Raspberry 4 (モデル B 8 GB)、Odroid M1またはRock 5B (8 GB / 16 GB RAM)ボード - マイクロSDカード(最小構成: 16 GB、クラス10) -- 2 TB SSD最小USB 3.0ディスクまたはUSB-SATAケース付きSSD +- 最低2TBのUSB 3.0 SSD、またはUSB-SATAケース付きSSD。 - 電源 - イーサネットケーブル -- ポートフォワーディング機能(詳細はクライアントを参照してください) +- ポートフォワーディング(詳細はクライアントを参照してください) - ヒートシンクとファンが付属しているケース - USBキーボード、モニター、HDMIケーブル(マイクロHDMI) (オプション) -## Ethereum on Armを実行する理由 {#why-run-ethereum-on-arm} +## ARM上でイーサリアムを実行する理由 {#why-run-ethereum-on-arm} ARMボードは価格が非常に手頃で、柔軟性の高い、小型のコンピュータです。 このボードは、イーサリアムノードを実行するのに適しています。手ごろな価格で、ノードだけにリソースを使うように設定が可能であり、効率的で電力消費量が少なく、物理的にも小さいので家に置いても邪魔にならないからです。 また、ノードを立ち上げるのも簡単です。Raspberry PiのマイクロSDカードは、ビルド済みイメージを簡単に書き込めるので、ソフトウェアのダウンロードやビルドが不要です。 -## 動作方法 {#how-does-it-work} +## 仕組み {#how-does-it-work} ビルド済みイメージをRaspberry Piのメモリーカードに書き込みます。 このイメージには、イーサリアムノードを実行するために必要なすべてが含まれています。 この書き込まれたカードがあれば、ユーザーはRaspberry Piの電源を入れるだけで済みます。 ノードを実行するのに必要なすべてのプロセスは自動で開始します。 メモリーカードにLinuxベースのオペレーティングシステム(OS)が含まれており、その上でシステムレベルのプロセスが自動的に実行され、ARMボードがイーサリアムノードになります。 @@ -39,97 +35,97 @@ ARMボードは価格が非常に手頃で、柔軟性の高い、小型のコ **このイメージは、必要なステップのすべてを行います**。環境のセットアップ、SSDディスクのフォーマット、イーサリアムソフトウェアのインストールと実行だけでなくブロックチェーンの同期も開始します。 -## 実行クライアントとコンセンサスクライアントに関する注意事項 {#note-on-execution-and-consensus-clients} +## 実行クライアントとコンセンサスクライアントに関する注意 {#note-on-execution-and-consensus-clients} -Ethereum on Armのイメージには、ビルド済みの実行クライアントとコンセンサスクライアントがサービスとして組み込まれています。 イーサリアムノードでは、両方のクライアントが同期されて実行される必要があります。 ここでユーザーがすべきことは、イメージをダウンロードして書き込んだ後、サービスを開始するだけです。 イメージには、次の実行クライアントが入っています。 +Ethereum on Armのイメージには、ビルド済みの実行クライアントとコンセンサスクライアントがサービスとして組み込まれています。 イーサリアムノードでは、両方のクライアントが同期されて実行される必要があります。 ユーザーがすべきことは、イメージをダウンロードして書き込んだ後、サービスを開始するだけです。 イメージには、次の実行クライアントが入っています。 - Geth - Nethermind - Besu -コンセンサスクライアントは、次のものが入っています。 +そして、以下のコンセンサスクライアント： -- ライトハウス -- ニンバス -- プリズム -- テク +- Lighthouse +- Nimbus +- Prysm +- Teku -使いたい実行クライアントとコンセンサスクライアントを各1つずつ選びます。すべての実行クライアントは、すべてのコンセンサスクライアントと連携可能です。 クライアントを選択しなかった場合、デフォルトでGethとライトハウスになります。ボードに電源を入れると、これらのクライアントが自動的に実行されます。 Gethがピアを見つけて接続できるように、ルーターで30303ポートを開く必要があります。 +使いたい実行クライアントとコンセンサスクライアントを各1つずつ選びます。すべての実行クライアントは、すべてのコンセンサスクライアントと連携可能です。 クライアントを明示的に選択しなかった場合、ノードはデフォルトのGethとLighthouseにフォールバックし、ボードに電源を入れると自動的に実行されます。 Gethがピアを見つけて接続できるように、ルーターで30303ポートを開く必要があります。 ## イメージのダウンロード {#downloading-the-image} Raspberry Pi 4のイーサリアムイメージは、「プラグ・アンド・プレイ」イメージです。実行クライアントとコンセンサスクライアントのインストールとセットアップが自動的に行われ、それらが互いに通信し、イーサリアムネットワークに接続するように設定されます。 ユーザーがすべきことは、単純なコマンドを使用してプロセスを開始するだけです。 -[Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1)からRaspberry Piイメージをダウンロードし、次のようにSHA256ハッシュを確認してください。 +[Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1)からRaspberry Piのイメージをダウンロードし、SHA256ハッシュを検証します： ```sh -# From directory containing the downloaded image +# ダウンロードしたイメージがあるディレクトリから shasum -a 256 ethonarm_22.04.00.img.zip -# Hash should output: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f +# ハッシュ出力は次のようになります: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f ``` -Rock 5BとOdroid M1ボードのイメージは、Ethereum-on-Armの[ダウンロードページ](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html)から入手可能です。 +Rock 5BおよびOdroid M1ボード用のイメージは、Ethereum-on-Armの[ダウンロードページ](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html)で入手できます。 -## マイクロSDへの書き込み {#flashing-the-microsd} +## MicroSDへの書き込み {#flashing-the-microsd} Raspberry Piで使用するマイクロSDカードは、まずデスクトップパソコンかノートパソコンに挿入して書き込む必要があります。 以下のターミナルコマンドで、ダウンロードしたイメージをSDカードに書き込みます。 ```shell -# check the MicroSD card name +# MicroSDカード名を確認 sudo fdisk -l >> sdxxx ``` -SDカード名を正しく取得することは、非常に重要です。次に使うコマンドに`dd`があり、これはイメージを書き込む前にカードの内容を完全に削除するからです。 zipイメージがあるディレクトリに移動して続行します。 +次のコマンドには `dd` が含まれており、これはイメージを書き込む前にカードの既存のコンテンツを完全に消去するため、名前を正しく入力することが非常に重要です。 続行するには、zipイメージが含まれているディレクトリに移動します。 ```shell -# unzip and flash image +# イメージを解凍して書き込み unzip ethonarm_22.04.00.img.zip sudo dd bs=1M if=ethonarm_22.04.00.img of=/dev/ conv=fdatasync status=progress ``` これでカードに書きこまれたので、Raspberry Piに挿入できます。 -## ノードの開始 {#start-the-node} +## ノードの起動 {#start-the-node} -SDカードを挿入したRaspberry Piに、SSDとイーサネットケーブルを接続し、電源を入れてください。 OSが起動し、クライアントソフトウェアのインストールやビルドなど、Raspberry Piをイーサリアムノードにする事前設定処理が自動的に開始します。 この処理には10～15分を要します。 +SDカードを挿入したRaspberry Piに、イーサネットケーブルとSSDを接続し、電源を入れてください。 OSが起動し、クライアントソフトウェアのインストールやビルドなど、Raspberry Piをイーサリアムノードにする事前設定処理が自動的に開始します。 この処理には10～15分を要します。 -自動インストールおよび設定が完了したら、モニターとキーボードがボードに接続されているならば直接ターミナルを使うか、SSH接続でデバイスへログインしてください。 `ethereum`アカウントを使用してログインします。このアカウントは、ノードの開始に必要なパーミッションを持っています。 +すべてがインストールおよび設定されたら、ssh接続でデバイスにログインするか、モニターとキーボードがボードに接続されている場合はターミナルを直接使用します。 ノードの開始に必要な権限を持つ `ethereum` アカウントを使用してログインします。 ```shell -User: ethereum -Password: ethereum +ユーザー: ethereum +パスワード: ethereum ``` -デフォルトの実行クライアントであるGethが自動的に開始します。 次のターミナルコマンドを使用してログをチェックすることで、開始を確認できます。 +デフォルトの実行クライアントであるGethが自動的に開始します。 次のターミナルコマンドを使用してログをチェックすることで、これを確認できます。 ```sh sudo journalctl -u geth -f ``` -コンセンサスクライアントは、明示的に開始する必要があります。 開始するには、まずルーターの9000ポートを開き、ライトハウスがピアを見つけて接続できるようにします。 次にライトハウスサービスを有効にして開始します。 +コンセンサスクライアントは明示的に起動する必要があります。 これを行うには、まずルーターのポート9000を開き、Lighthouseがピアを見つけて接続できるようにします。 次にLighthouseサービスを有効にして開始します。 ```sh sudo systemctl enable lighthouse-beacon sudo systemctl start lighthouse-beacon ``` -ログでクライアントの状態を確認してください。 +ログを使ってクライアントを確認してください。 ```sh sudo journalctl -u lighthouse-beacon ``` -チェックポイント同期を使用するため、コンセンサスクライアントは数分で同期されることに注意してください。 実行クライアントは、同期により時間がかかります。数時間かかる場合もあります。さらに、コンセンサスクライアントの同期が完了するまで、同期を開始しません(これは、実行クライアントが、同期されたコンセンサスクライアントが提供する同期先のターゲットを必要とするためです)。 +コンセンサスクライアントはチェックポイント同期を使用するため、数分で同期されることに注意してください。 実行クライアントは、同期により時間がかかります。数時間かかる場合もあります。さらに、コンセンサスクライアントの同期が完了するまで、同期を開始しません(これは、実行クライアントが、同期されたコンセンサスクライアントが提供する同期先のターゲットを必要とするためです)。 -Gethとライトハウスのサービスが開始し同期されると、Raspberry Piがイーサリアムノードになります。 イーサリアムネットワークとのやり取りを行うには、8545ポートでGethクライアントに接続し、GethのJavascriptコンソールを使うことが最も一般的な方法です。 また、Curlなどのリクエストツールを使用して、JSONオブジェクトとしてフォーマットされたコマンドを送信することもできます。 詳細は、[Gethのドキュメント](https://geth.ethereum.org/)をご覧ください。 +GethとLighthouseのサービスが開始し同期されると、Raspberry Piがイーサリアムノードになります。 イーサリアムネットワークとのやり取りを行うには、8545ポートでGethクライアントに接続し、GethのJavascriptコンソールを使うことが最も一般的な方法です。 また、Curlなどのリクエストツールを使用して、JSONオブジェクトとしてフォーマットされたコマンドを送信することもできます。 詳細は[Gethドキュメント](https://geth.ethereum.org/)をご覧ください。 -Gethは、ブラウザで表示できるGrafanaダッシュボードに、メトリクスをレポートするように事前設定されています。 この機能を使用してノードの健全性を監視したい上級ユーザーは、`ipaddress:3000`にアクセスして`user: admin`と`passwd: ethereum`を入力してください。 +Gethは、ブラウザで表示できるGrafanaダッシュボードに、メトリクスをレポートするように事前設定されています。 上級ユーザーは、この機能を使用して`ipaddress:3000`にアクセスし、`user: admin`と`passwd: ethereum`を渡してノードの状態を監視することができます。 ## バリデータ {#validators} -バリデータは、コンセンサスクライアントにオプションで追加することもできます。 バリデータソフトウェアを使用すると、ノードが積極的にコンセンサスに参加し、暗号経済のセキュリティをネットワークに提供できるようになります。 この作業の報酬としてETHを受け取れます。 バリデータを実行するには、まず32 ETHを持っている必要があり、これをデポジットコントラクトに預け入れる必要があります。 **長期的なコミットメントとなるため、このETHはまだ引き出すことはできません。** 預け入れは、[ランチパッド](https://launchpad.ethereum.org/)のステップバイステップガイドに従って行うことができます。 この作業は、デスクトップパソコンまたはノートパソコンで行いますが、キーは生成しないでください。キーはRaspberry Piで直接生成します。 +バリデータは、コンセンサスクライアントにオプションで追加することもできます。 バリデータソフトウェアを使用すると、ノードが積極的にコンセンサスに参加し、暗号経済のセキュリティをネットワークに提供できるようになります。 この作業の報酬としてETHを受け取れます。 バリデータを実行するには、まず32 ETHを持っている必要があり、これをデポジットコントラクトに預け入れる必要があります。 預け入れは、[Launchpad](https://launchpad.ethereum.org/)のステップバイステップガイドに従って行うことができます。 この作業はデスクトップ/ラップトップで行いますが、キーは生成しないでください — これはRaspberry Piで直接行うことができます。 Raspberry Piのターミナルを開き、以下のコマンドを実行して、デポジットキーを生成してください。 @@ -139,34 +135,37 @@ sudo apt-get install staking-deposit-cli cd && deposit new-mnemonic --num_validators 1 ``` -ニーモニックフレーズを安全に保管してください。 上記コマンドで、ノードのキーストアに2つのファイルが生成されました。これらは、バリデータキーとデポジットデータファイルです。 デポジットデータは、ランチパッドにアップロードする必要があるため、Raspberry Piからデスクトップパソコンまたはノートパソコンにコピーする必要があります。 これは、ssh接続や他のコピー/ペーストの手法を用いて行えます。 +(または、[staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli)をダウンロードしてエアギャップマシンで実行し、`deposit new-mnemnonic`コマンドを実行します) -ランチパッドを実行しているコンピューターでデポジットデータファイルが利用可能になったら、これをランチパッド画面の「`+`」にドラッグ・アンド・ドロップすることができます。 画面の指示に従って、デポジットコントラクトにトランザクションを送信してください。 +ニーモニックフレーズを安全に保管してください。 上記コマンドで、ノードのキーストアに2つのファイル(バリデータキーとデポジットデータファイル)が生成されました。 デポジットデータは、Launchpadにアップロードする必要があるため、Raspberry Piからデスクトップまたはラップトップにコピーする必要があります。 これは、ssh接続や他のコピー/ペーストの手法を用いて行えます。 -Raspberry Piに戻ると、バリデータが開始可能になります。 これには、バリデータキーのインポート、報酬を受け取るためのアドレスの設定、事前設定されたバリデータプロセスの開始が必要になります。 以下は、ライトハウス向けの例です。その他のコンセンサス クライアント向けの手順については、[Ethereum on Armのドキュメント](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)を参照してください。 +Launchpadを実行しているコンピューターでデポジットデータファイルが利用可能になったら、これをLaunchpad画面の「+」にドラッグ・アンド・ドロップすることができます。 画面の指示に従って、デポジットコントラクトにトランザクションを送信してください。 + +Raspberry Piに戻ると、バリデータが開始可能になります。 これには、バリデータキーのインポート、報酬を受け取るためのアドレスの設定、事前設定されたバリデータプロセスの開始が必要になります。 以下の例はLighthouseのものです。他のコンセンサスクライアント向けの手順は、[Ethereum on Armドキュメント](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)で参照できます： ```shell -# import the validator keys +# バリデータキーのインポート lighthouse account validator import --directory=/home/ethereum/validator_keys -# set the reward address +# 報酬受取アドレスの設定 sudo sed -i 's/' /etc/ethereum/lighthouse-validator.conf -# start the validator +# バリデータの開始 sudo systemctl start lighthouse-validator ``` おめでとうございます。これでフルイーサリアムノードとバリデータが、Raspberry Piで実行されました。 -## 詳細情報 {#more-details} +## 詳細 {#more-details} -このページでは、Raspberry Piを使用してGethおよびライトハウスのノードとバリデータを設定する方法の概要について説明しました。 さらに詳細な手順は、[Ethereum on Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html)のウェブサイトでご覧いただけます。 +このページでは、Raspberry Piを使用してGeth-Lighthouseノードとバリデータを設定する方法の概要について説明しました。 より詳細な手順は、[Ethereum-on-Armウェブサイト](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html)で入手できます。 -## フィードバックご協力のお願い {#feedback-appreciated} +## フィードバックのお願い {#feedback-appreciated} -Raspberry Piは多くのユーザーが利用しており、イーサリアムネットワークの健全性に非常に良い影響を与えてきました。 このチュートリアルを深く掘り下げていき、テストネットで実行してみてください。また、Ethereum on ArmのGitHubページの確認、フィードバックの提供、問題提起、プルリクエストの作成による、テクノロジーの進歩とドキュメント化推進へのご協力をお願いします。 +Raspberry Piには膨大なユーザーベースがあり、イーサリアムネットワークの健全性に非常に良い影響を与える可能性があります。 +このチュートリアルを深く掘り下げていき、テストネットで実行してみてください。また、Ethereum on ArmのGitHubページの確認、フィードバックの提供、問題提起、プルリクエストの作成による、テクノロジーの進歩とドキュメント化推進へのご協力をお願いします。 -## 参考文献 {#references} +## 参考資料 {#references} 1. https://ubuntu.com/download/raspberry-pi 2. https://wikipedia.org/wiki/Port_forwarding diff --git a/public/content/translations/ja/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/ja/developers/tutorials/scam-token-tricks/index.md new file mode 100644 index 00000000000..adaeee17fa2 --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/scam-token-tricks/index.md @@ -0,0 +1,470 @@ +--- +title: "詐欺トークンで使われる手口と、その見分け方" +description: "このチュートリアルでは、詐欺トークンを分析し、詐欺師が使う手口、その実装方法、そしてそれを検出する方法を解説します。" +author: Ori Pomerantz +tags: + [ + "詐欺", + "Solidity", + "ERC-20", + "JavaScript", + "TypeScript" + ] +skill: intermediate +published: 2023-09-15 +lang: ja +--- + +このチュートリアルでは、[ある詐欺トークン](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code)を分析し、詐欺師が使う手口やその実装方法について見ていきます。 このチュートリアルを終える頃には、ERC-20トークンコントラクト、その機能、そしてなぜ懐疑的な見方が必要なのかについて、より包括的な見解を得られるでしょう。 次に、その詐欺トークンが発行するイベントを見て、それが正当なものでないことを自動的に特定する方法を見ていきます。 + +## 詐欺トークン - それは何であり、なぜ人々はそれを行い、どうすればそれを回避できるか {#scam-tokens} + +イーサリアムの最も一般的な用途の1つは、グループが取引可能なトークン、いわば独自の通貨を作ることです。 価値をもたらす正当なユースケースを提供するトークンがある一方、その価値をトークン発行元が独占するようなトークンも存在します。 + +この件については、[ethereum.org の別の場所で](/guides/how-to-id-scam-tokens/)、ユーザーの視点から詳しく読むことができます。 このチュートリアルでは、詐欺トークンを分析し、それがどのように行われ、どのように検出できるかを見ていくことに焦点を当てます。 + +### wARBが詐欺だとどうしてわかるのか？ {#warb-scam} + +私たちが分析するトークンは[wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code)で、正当な[ARBトークン](https://etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1)と同等であるかのように装っています。 + +どちらが正当なトークンであるかを知る最も簡単な方法は、発行元の組織である[Arbitrum](https://arbitrum.foundation/)を見ることです。 正当なアドレスは、[彼らのドキュメント](https://docs.arbitrum.foundation/deployment-addresses#token)に明記されています。 + +### なぜソースコードは利用できるのですか？ {#why-source} + +通常、他人を騙そうとする人々は秘密主義であると予想され、実際に多くの詐欺トークンはコードを公開していません（例えば、[これ](https://optimistic.etherscan.io/token/0x15992f382d8c46d667b10dc8456dc36651af1452#code)や[これ](https://optimistic.etherscan.io/token/0x026b623eb4aada7de37ef25256854f9235207178#code)など）。 + +しかし、正当なトークンは通常ソースコードを公開するため、詐欺トークンの作者も正当に見せかけるために、同じことをすることがあります。 [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code)は、ソースコードが公開されているトークンの一つであり、そのため理解しやすくなっています。 + +コントラクトのデプロイ者はソースコードを公開するかどうかを選択できますが、間違ったソースコードを公開することは_できません_。 ブロックエクスプローラーは提供されたソースコードを独自にコンパイルし、全く同じバイトコードが得られなければ、そのソースコードを拒否します。 [これについてはEtherscanのサイトで詳しく読むことができます](https://etherscan.io/verifyContract)。 + +## 正当なERC-20トークンとの比較 {#compare-legit-erc20} + +このトークンを正当なERC-20トークンと比較します。 正当なERC-20トークンが通常どのように書かれているかについて詳しくない場合は、[このチュートリアル](/developers/tutorials/erc20-annotated-code/)をご覧ください。 + +### 特権アドレスの定数 {#constants-for-privileged-addresses} + +コントラクトには、特権アドレスが必要な場合があります。 長期的な使用を目的として設計されたコントラクトでは、一部の特権アドレスがそれらのアドレスを変更することを許可します。例えば、新しいマルチシグコントラクトの使用を可能にするためです。 これにはいくつかの方法があります。 + +[`HOP`トークンコントラクト](https://etherscan.io/address/0xc5102fe9359fd9a28f877a67e36b0f050d81a3cc#code)は、[`Ownable`](https://docs.openzeppelin.com/contracts/2.x/access-control#ownership-and-ownable)パターンを使用しています。 特権アドレスは、`_owner`と呼ばれるフィールドのストレージに保持されます（3番目のファイル`Ownable.sol`を参照）。 + +```solidity +abstract contract Ownable is Context { + address private _owner; + . + . + . +} +``` + +[`ARB`トークンコントラクト](https://etherscan.io/address/0xad0c361ef902a7d9851ca7dcc85535da2d3c6fc7#code)には、直接的な特権アドレスはありません。 しかし、それは必要ありません。 それは、[アドレス`0xb50721bcf8d664c30412cfbc6cf7a15145234ad1`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1#code)にある[`proxy`](https://docs.openzeppelin.com/contracts/5.x/api/proxy)の背後にあります。 そのコントラクトには、アップグレードに使用できる特権アドレスがあります（4番目のファイル、`ERC1967Upgrade.sol`を参照）。 + +```solidity + /** + * @dev EIP1967の管理者スロットに新しいアドレスを格納します。 + */ + function _setAdmin(address newAdmin) private { + require(newAdmin != address(0), "ERC1967: 新しい管理者はゼロアドレスです"); + StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin; + } +``` + +対照的に、`wARB`コントラクトにはハードコーディングされた`contract_owner`があります。 + +```solidity +contract WrappedArbitrum is Context, IERC20 { + . + . + . + address deployer = 0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1; + address public contract_owner = 0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33; + . + . + . +} +``` + +このコントラクトオーナーは、異なる時点で異なるアカウントによって制御されうるコントラクトではなく、[外部所有アカウント](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs)です。 これは、価値を維持し続けるERC-20を管理するための長期的なソリューションとしてではなく、個人による短期的な使用のために設計されている可能性が高いことを意味します。 + +そして実際にEtherscanを見ると、詐欺師がこのコントラクトを使用したのは2023年5月19日のわずか12時間（[最初のトランザクション](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2)から[最後のトランザクション](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b)まで）だけであったことがわかります。 + +### 偽の`_transfer`関数 {#the-fake-transfer-function} + +実際の送金は、[内部`_transfer`関数](/developers/tutorials/erc20-annotated-code/#the-_transfer-function-_transfer)を使用して行われるのが標準です。 + +`wARB`では、この関数はほとんど正当に見えます： + +```solidity + function _transfer(address sender, address recipient, uint256 amount) internal virtual{ + require(sender != address(0), "ERC20: ゼロアドレスからの送金"); + require(recipient != address(0), "ERC20: ゼロアドレスへの送金"); + + _beforeTokenTransfer(sender, recipient, amount); + + _balances[sender] = _balances[sender].sub(amount, "ERC20: 送金額が残高を超えています"); + _balances[recipient] = _balances[recipient].add(amount); + if (sender == contract_owner){ + sender = deployer; + } + emit Transfer(sender, recipient, amount); + } +``` + +疑わしい部分は次のとおりです： + +```solidity + if (sender == contract_owner){ + sender = deployer; + } + emit Transfer(sender, recipient, amount); +``` + +コントラクトオーナーがトークンを送金した場合、なぜ`Transfer`イベントでは`deployer`から送金されたと表示されるのでしょうか？ + +しかし、もっと重要な問題があります。 誰がこの`_transfer`関数を呼び出すのでしょうか？ これは外部からは呼び出せず、`internal`とマークされています。 そして、私たちが持っているコードには`_transfer`への呼び出しは含まれていません。 明らかに、これはおとりとしてここにあります。 + +```solidity + function transfer(address recipient, uint256 amount) public virtual override returns (bool) { + _f_(_msgSender(), recipient, amount); + return true; + } + + function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) { + _f_(sender, recipient, amount); + _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: 送金額が許容量を超えています")); + return true; + } +``` + +トークンを転送するために呼び出される関数`transfer`と`transferFrom`を見ると、それらが全く異なる関数`_f_`を呼び出していることがわかります。 + +### 本当の`_f_`関数 {#the-real-f-function} + +```solidity + function _f_(address sender, address recipient, uint256 amount) internal _mod_(sender,recipient,amount) virtual { + require(sender != address(0), "ERC20: ゼロアドレスからの送金"); + require(recipient != address(0), "ERC20: ゼロアドレスへの送金"); + + _beforeTokenTransfer(sender, recipient, amount); + + _balances[sender] = _balances[sender].sub(amount, "ERC20: 送金額が残高を超えています"); + _balances[recipient] = _balances[recipient].add(amount); + if (sender == contract_owner){ + + sender = deployer; + } + emit Transfer(sender, recipient, amount); + } +``` + +この関数には2つの潜在的な危険信号があります。 + +- [関数修飾子](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `_mod_`の使用。 しかし、ソースコードを調べてみると、`_mod_`は実際には無害であることがわかります。 + + ```solidity + modifier _mod_(address sender, address recipient, uint256 amount){ + _; + } + ``` + +- `_transfer`で見たのと同じ問題で、`contract_owner`がトークンを送金すると、それらが`deployer`から来たように見えることです。 + +### 偽のイベント関数 `dropNewTokens` {#the-fake-events-function-dropNewTokens} + +ここで、実際の詐欺のように見えるものにたどり着きます。 読みやすくするために少し関数を編集しましたが、機能的には同等です。 + +```solidity +function dropNewTokens(address uPool, + address[] memory eReceiver, + uint256[] memory eAmounts) public auth() +``` + +この関数には`auth()`修飾子があり、これはコントラクトオーナーによってのみ呼び出されることを意味します。 + +```solidity +modifier auth() { + require(msg.sender == contract_owner, "対話は許可されていません"); + _; +} +``` + +この制限は完全に理にかなっています。なぜなら、私たちはランダムなアカウントがトークンを配布することを望まないからです。 しかし、関数の残りの部分は疑わしいです。 + +```solidity +{ + for (uint256 i = 0; i < eReceiver.length; i++) { + emit Transfer(uPool, eReceiver[i], eAmounts[i]); + } +} +``` + +プールアカウントから受信者の配列へ金額の配列を送金する関数は、完全に理にかなっています。 給与支払い、エアドロップなど、単一のソースから複数の宛先にトークンを配布したいユースケースはたくさんあります。 複数のトランザクションを発行したり、同じトランザクションの一部として別のコントラクトからERC-20を複数回呼び出したりする代わりに、単一のトランザクションで行う方が（ガス代が）安くなります。 + +しかし、`dropNewTokens`はそれをしません。 これは[`Transfer`イベント](https://eips.ethereum.org/EIPS/eip-20#transfer-1)を発行しますが、実際にはトークンを転送しません。 実際には起こらなかった送金をオフチェーンアプリケーションに伝えることで混乱させる正当な理由はありません。 + +### `Approve`関数を燃やす {#the-burning-approve-function} + +ERC-20コントラクトは、許容量のために[an `approve` function](/developers/tutorials/erc20-annotated-code/#approve)を持つことになっており、実際、私たちの詐欺トークンにはそのような関数があり、しかも正しいものです。 しかし、SolidityはC言語から派生しているため、大文字と小文字が区別されます。 「Approve」と「approve」は異なる文字列です。 + +また、その機能は`approve`とは関係ありません。 + +```solidity + function Approve( + address[] memory holders) +``` + +この関数は、トークン保有者のアドレスの配列で呼び出されます。 + +```solidity + public approver() { +``` + +`approver()` 修飾子は、`contract_owner` だけがこの関数を呼び出すことを許可するようにします（下記参照）。 + +```solidity + for (uint256 i = 0; i < holders.length; i++) { + uint256 amount = _balances[holders[i]]; + _beforeTokenTransfer(holders[i], 0x0000000000000000000000000000000000000001, amount); + _balances[holders[i]] = _balances[holders[i]].sub(amount, + "ERC20: burn amount exceeds balance"); + _balances[0x0000000000000000000000000000000000000001] = + _balances[0x0000000000000000000000000000000000000001].add(amount); + } + } + +``` + +ホルダーアドレスごとに、この関数はホルダーの残高全体を`0x00...01`アドレスに移動させ、事実上それをバーン（焼却）します（標準の実際の`burn`は総供給量も変更し、トークンを`0x00...00`に送金します）。 これは、`contract_owner`がどのユーザーの資産でも削除できることを意味します。 これは、ガバナンストークンに求める機能とは思えません。 + +### コード品質の問題 {#code-quality-issues} + +これらのコード品質の問題は、このコードが詐欺であると_証明する_ものではありませんが、疑わしいものに見せます。 Arbitrumのような組織化された企業は、通常このような質の悪いコードをリリースしません。 + +#### `mount`関数 {#the-mount-function} + +[標準](https://eips.ethereum.org/EIPS/eip-20)には明記されていませんが、一般的に新しいトークンを作成する関数は[`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn)と呼ばれます。 + +`wARB`のコンストラクタを見ると、ミント関数が何らかの理由で`mount`に改名されており、効率化のために全額を一度にではなく、初期供給の5分の1で5回呼び出されていることがわかります。 + +```solidity + constructor () public { + + _name = "Wrapped Arbitrum"; + _symbol = "wARB"; + _decimals = 18; + uint256 initialSupply = 1000000000000; + + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + mount(deployer, initialSupply*(10**18)/5); + } +``` + +`mount`関数自体も疑わしいです。 + +```solidity + function mount(address account, uint256 amount) public { + require(msg.sender == contract_owner, "ERC20: mint to the zero address"); +``` + +`require`を見ると、コントラクトオーナーだけがミントすることを許可されていることがわかります。 これは正当です。 しかし、エラーメッセージは_only owner is allowed to mint_（オーナーのみミント可能）などであるべきです。 代わりに、それは無関係な_ERC20: mint to the zero address_です。 ゼロアドレスへのミントを正しくテストするには `require(account != address(0), "<エラーメッセージ>")` としますが、コントラクトはこれをチェックする手間をかけていません。 + +```solidity + _totalSupply = _totalSupply.add(amount); + _balances[contract_owner] = _balances[contract_owner].add(amount); + emit Transfer(address(0), account, amount); + } +``` + +さらに2つ、直接ミントに関連する疑わしい事実があります。 + +- `account`パラメータがあり、これはミントされた量を受け取るべきアカウントであると推測されます。 しかし、実際に増加する残高は`contract_owner`のものです。 + +- 増加した残高は`contract_owner`のものですが、発行されたイベントは`account`への送金を示しています。 + +### なぜ `auth` と `approver` の両方があるのか？ なぜ何もしない`mod`があるのか？ {#why-both-autho-and-approver-why-the-mod-that-does-nothing} + +このコントラクトには `_mod_`、`auth`、`approver` の3つの修飾子が含まれています。 + +```solidity + modifier _mod_(address sender, address recipient, uint256 amount){ + _; + } +``` + +`_mod_`は3つのパラメータを取り、それらで何もしません。 なぜそれがあるのでしょうか？ + +```solidity + modifier auth() { + require(msg.sender == contract_owner, "対話は許可されていません"); + _; + } + + modifier approver() { + require(msg.sender == contract_owner, "対話は許可されていません"); + _; + } +``` + +`auth` と `approver` は、コントラクトが `contract_owner` によって呼び出されたことを確認するため、より理にかなっています。 ミントなどの特定の特権的なアクションは、そのアカウントに限定されることを期待します。 しかし、_全く同じこと_をする2つの別々の関数を持つことに何の意味があるのでしょうか？ + +## 何を自動的に検出できるか？ {#what-can-we-detect-automatically} + +Etherscanを見ることで、`wARB`が詐欺トークンであることがわかります。 しかし、それは中央集権的な解決策です。 理論的には、Etherscanは転覆されたりハッキングされたりする可能性があります。 トークンが正当なものかどうかを独自に判断できる方が良いです。 + +発行するイベントを見ることで、ERC-20トークンが疑わしい（詐欺か、非常に плохоく書かれているか）ことを特定するためのいくつかのトリックがあります。 + +## 疑わしい`Approval`イベント {#suspicious-approval-events} + +[`Approval`イベント](https://eips.ethereum.org/EIPS/eip-20#approval)は、直接のリクエストによってのみ発生すべきです（許容量の結果として発生する可能性のある[`Transfer`イベント](https://eips.ethereum.org/EIPS/eip-20#transfer-1)とは対照的です）。 この問題の詳細な説明と、なぜリクエストがコントラクトによって仲介されるのではなく直接である必要があるのかについては、[Solidityのドキュメント](https://docs.soliditylang.org/en/v0.8.20/security-considerations.html#tx-origin)を参照してください。 + +これは、[外部所有アカウント](/developers/docs/accounts/#types-of-account)からの支出を承認する`Approval`イベントは、そのアカウントから発生し、宛先がERC-20コントラクトであるトランザクションからでなければならないことを意味します。 外部所有アカウントからのその他の種類の承認は疑わしいです。 + +[viem](https://viem.sh/)と、型安全性を備えたJavaScriptの派生言語である[TypeScript](https://www.typescriptlang.org/docs/)を使用して、[この種のイベントを特定するプログラム](https://github.com/qbzzt/20230915-scam-token-detection)がここにあります。 実行方法： + +1. `.env.example` を `.env` にコピーします。 +2. `.env` を編集して、イーサリアムメインネットノードへのURLを提供します。 +3. `pnpm install` を実行して、必要なパッケージをインストールします。 +4. `pnpm susApproval` を実行して、疑わしい承認を検索します。 + +以下に一行ずつの説明を示します： + +```typescript +import { + Address, + TransactionReceipt, + createPublicClient, + http, + parseAbiItem, +} from "viem" +import { mainnet } from "viem/chains" +``` + +`viem`から型定義、関数、チェーン定義をインポートします。 + +```typescript +import { config } from "dotenv" +config() +``` + +`.env`を読み込んでURLを取得します。 + +```typescript +const client = createPublicClient({ + chain: mainnet, + transport: http(process.env.URL), +}) +``` + +Viemクライアントを作成します。 ブロックチェーンから読み取るだけなので、このクライアントには秘密鍵は必要ありません。 + +```typescript +const testedAddress = "0xb047c8032b99841713b8e3872f06cf32beb27b82" +const fromBlock = 16859812n +const toBlock = 16873372n +``` + +疑わしいERC-20コントラクトのアドレスと、イベントを検索するブロックの範囲です。 ノードプロバイダーは通常、帯域幅が高価になる可能性があるため、イベントを読み取る能力を制限します。 幸いなことに、`wARB`は18時間使用されていなかったので、すべてのイベント（合計でわずか13件）を調べることができます。 + +```typescript +const approvalEvents = await client.getLogs({ + address: testedAddress, + fromBlock, + toBlock, + event: parseAbiItem( + "event Approval(address indexed _owner, address indexed _spender, uint256 _value)" + ), +}) +``` + +これはViemにイベント情報を要求する方法です。 フィールド名を含む正確なイベントシグネチャを提供すると、イベントが解析されます。 + +```typescript +const isContract = async (addr: Address): boolean => + await client.getBytecode({ address: addr }) +``` + +私たちのアルゴリズムは、外部所有アカウントにのみ適用されます。 `client.getBytecode`によってバイトコードが返された場合、それはこれがコントラクトであることを意味し、スキップすべきです。 + +これまでにTypeScriptを使用したことがない場合、関数定義は少し奇妙に見えるかもしれません。 最初の（そして唯一の）パラメータが`addr`と呼ばれるだけでなく、それが`Address`型であることも伝えます。 同様に、`: boolean`の部分は、関数の戻り値がブール値であることをTypeScriptに伝えます。 + +```typescript +const getEventTxn = async (ev: Event): TransactionReceipt => + await client.getTransactionReceipt({ hash: ev.transactionHash }) +``` + +この関数は、イベントからトランザクションレシートを取得します。 トランザクションの宛先が何であったかを確認するために、レシートが必要です。 + +```typescript +const suspiciousApprovalEvent = async (ev : Event) : (Event | null) => { +``` + +これは最も重要な関数で、イベントが疑わしいかどうかを実際に判断するものです。 戻り値の型 `(Event | null)` は、この関数が `Event` または `null` のいずれかを返すことができることを TypeScript に伝えます。 イベントが疑わしくない場合は`null`を返します。 + +```typescript +const owner = ev.args._owner +``` + +Viemはフィールド名を持っているので、イベントを解析してくれました。 `_owner`は、使用されるトークンの所有者です。 + +```typescript +// コントラクトによる承認は疑わしくない +if (await isContract(owner)) return null +``` + +所有者がコントラクトである場合、この承認は疑わしくないと仮定します。 コントラクトの承認が疑わしいかどうかを確認するには、トランザクションの完全な実行を追跡して、それが所有者コントラクトに到達したかどうか、そしてそのコントラクトがERC-20コントラクトを直接呼び出したかどうかを確認する必要があります。 それは、私たちが望むよりもはるかにリソースを消費します。 + +```typescript +const txn = await getEventTxn(ev) +``` + +承認が外部所有アカウントからのものである場合、それを引き起こしたトランザクションを取得します。 + +```typescript +// 承認は、トランザクションの`from`ではないEOA所有者からのものである場合、疑わしい +if (owner.toLowerCase() != txn.from.toLowerCase()) return ev +``` + +アドレスは16進数なので文字が含まれているため、単純に文字列の等価性をチェックすることはできません。 例えば、`txn.from`では、それらの文字はすべて小文字です。 `ev.args._owner`のような他のケースでは、アドレスは[エラー識別のために大文字と小文字が混在しています](https://eips.ethereum.org/EIPS/eip-55)。 + +しかし、トランザクションが所有者からのものではなく、その所有者が外部所有である場合、それは疑わしいトランザクションです。 + +```typescript +// トランザクションの宛先が調査中のERC-20コントラクトでない場合も +// 疑わしいです +if (txn.to.toLowerCase() != testedAddress) return ev +``` + +同様に、トランザクションの`to`アドレス、つまり最初に呼び出されたコントラクトが、調査対象のERC-20コントラクトでない場合も疑わしいです。 + +```typescript + // 疑わしい理由がない場合は、nullを返します。 + return null +} +``` + +どちらの条件も真でない場合、`Approval`イベントは疑わしくありません。 + +```typescript +const testPromises = approvalEvents.map((ev) => suspiciousApprovalEvent(ev)) +const testResults = (await Promise.all(testPromises)).filter((x) => x != null) + +console.log(testResults) +``` + +[`async`関数](https://www.w3schools.com/js/js_async.asp)は`Promise`オブジェクトを返します。 一般的な構文 `await x()` を使用すると、その `Promise` が満たされるまで待ってから処理を続行します。 これはプログラムしやすく、追いやすいですが、非効率的でもあります。 特定のイベントの`Promise`が満たされるのを待っている間に、次のイベントの作業にすでに取りかかることができます。 + +ここでは[`map`](https://www.w3schools.com/jsref/jsref_map.asp)を使用して`Promise`オブジェクトの配列を作成します。 次に、[`Promise.all`](https://www.javascripttutorial.net/es6/javascript-promise-all/)を使用して、それらのすべてのプロミスが解決されるのを待ちます。 その後、それらの結果を[`filter`](https://www.w3schools.com/jsref/jsref_filter.asp)して、疑わしくないイベントを削除します。 + +### 疑わしい`Transfer`イベント {#suspicious-transfer-events} + +詐欺トークンを特定するもう一つの可能性のある方法は、疑わしい送金があるかどうかを確認することです。 例えば、それほど多くのトークンを持っていないアカウントからの送金などです。 [このテストの実装方法](https://github.com/qbzzt/20230915-scam-token-detection/blob/main/susTransfer.ts)を見ることができますが、`wARB`にはこの問題はありません。 + +## 結論 {#conclusion} + +詐欺が完全に正常なERC-20トークンコントラクトを使用し、それが何も実体を表していないだけの場合があるため、ERC-20詐欺の自動検出は[偽陰性](https://en.wikipedia.org/wiki/False_positives_and_false_negatives#False_negative_error)に悩まされます。 したがって、常に_信頼できる情報源からトークンアドレスを取得する_ように努めるべきです。 + +自動検出は、DeFiピースのような、多くのトークンがあり、それらを自動的に処理する必要がある特定のケースで役立ちます。 しかし、いつものように[caveat emptor](https://www.investopedia.com/terms/c/caveatemptor.asp)（買い手注意）、自分で調査し、ユーザーにも同様に行うよう奨励してください。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). diff --git a/public/content/translations/ja/developers/tutorials/secret-state/index.md b/public/content/translations/ja/developers/tutorials/secret-state/index.md new file mode 100644 index 00000000000..d878fac89c8 --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/secret-state/index.md @@ -0,0 +1,741 @@ +--- +title: "秘密のステートにゼロ知識を使用する" +description: "オンチェーンゲームは隠された情報を保持できないため、制限があります。 このチュートリアルを読むと、読者はゼロ知識証明とサーバーコンポーネントを組み合わせて、オフチェーンコンポーネントで秘密のステートを持つ検証可能なゲームを作成できるようになります。 これを行うための手法は、マインスイーパゲームを作成することで実証されます。" +author: Ori Pomerantz +tags: + [ + "サーバー", + "オフチェーン", + "中央集権型", + "ゼロ知識", + "zokrates", + "mud" + ] +skill: advanced +lang: ja +published: 2025-03-15 +--- + +ブロックチェーンには秘密はありません。 ブロックチェーンに投稿されたものはすべて、誰でも読むことができます。 ブロックチェーンは誰でも検証できることに基づいているため、これが必要です。 しかし、ゲームはしばしば秘密のステートに依存します。 例えば、[マインスイーパ](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\))というゲームは、ブロックチェーンエクスプローラーでマップを見ることができれば、まったく意味がありません。 + +最も簡単な解決策は、[サーバーコンポーネント](/developers/tutorials/server-components/)を使用して秘密のステートを保持することです。 しかし、私たちがブロックチェーンを使用する理由は、ゲームデベロッパーによる不正行為を防ぐためです。 サーバーコンポーネントの誠実性を確保する必要があります。 サーバーはステートのハッシュを提供し、[ゼロ知識証明](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important)を使用して、動きの結果を計算するために使用されたステートが正しいものであることを証明できます。 + +この記事を読んだ後、あなたはこの種の秘密のステートを保持するサーバー、ステートを表示するためのクライアント、そして両者間の通信のためのオンチェーンコンポーネントを作成する方法を知るでしょう。 使用する主なツールは次のとおりです。 + +| ツール | 目的 | 検証済みバージョン | +| --------------------------------------------- | --------------------------- | --------------------------------------: | +| [Zokrates](https://zokrates.github.io/) | ゼロ知識証明とその検証 | 1.1.9 | +| [Typescript](https://www.typescriptlang.org/) | サーバーとクライアントの両方のためのプログラミング言語 | 5.4.2 | +| [Node](https://nodejs.org/en) | サーバーの実行 | 20.18.2 | +| [Viem](https://viem.sh/) | ブロックチェーンとの通信 | 2.9.20 | +| [MUD](https://mud.dev/) | オンチェーンデータ管理 | 2.0.12 | +| [React](https://react.dev/) | クライアントのユーザーインターフェース | 18.2.0 | +| [Vite](https://vitejs.dev/) | クライアントコードの提供 | 4.2.1 | + +## マインスイーパの例 {#minesweeper} + +[マインスイーパ](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\))は、地雷原のある秘密のマップを含むゲームです。 プレイヤーは特定の場所を掘ることを選択します。 その場所に地雷があれば、ゲームオーバーです。 そうでなければ、プレイヤーはその場所を囲む8つのマスにある地雷の数を取得します。 + +このアプリケーションは、[key-valueデータベース](https://aws.amazon.com/nosql/key-value/)を使用してデータをオンチェーンに保存し、そのデータをオフチェーンコンポーネントと自動的に同期させるフレームワークである[MUD](https://mud.dev/)を使用して書かれています。 同期に加えて、MUDはアクセス制御を容易にし、他のユーザーが私たちのアプリケーションをパーミッションレスで[拡張](https://mud.dev/guides/extending-a-world)できるようにします。 + +### マインスイーパの例の実行 {#running-minesweeper-example} + +マインスイーパの例を実行するには： + +1. [前提条件がインストールされている](https://mud.dev/quickstart#prerequisites)ことを確認してください：[Node](https://mud.dev/quickstart#prerequisites)、[Foundry](https://book.getfoundry.sh/getting-started/installation)、[`git`](https://git-scm.com/downloads)、[`pnpm`](https://git-scm.com/downloads)、そして[`mprocs`](https://github.com/pvolok/mprocs)。 + +2. リポジトリをクローンします。 + + ```sh copy + git clone https://github.com/qbzzt/20240901-secret-state.git + ``` + +3. パッケージをインストールします。 + + ```sh copy + cd 20240901-secret-state/ + pnpm install + npm install -g mprocs + ``` + + `pnpm install`の一部としてFoundryがインストールされた場合は、コマンドラインシェルを再起動する必要があります。 + +4. コントラクトをコンパイルする + + ```sh copy + cd packages/contracts + forge build + cd ../.. + ``` + +5. プログラム（[anvil](https://book.getfoundry.sh/anvil/)ブロックチェーンを含む）を起動し、待ちます。 + + ```sh copy + mprocs + ``` + + 起動には時間がかかることに注意してください。 進捗を確認するには、まず下矢印を使用して _contracts_ タブまでスクロールし、MUDコントラクトがデプロイされていることを確認します。 「_Waiting for file changes…_」というメッセージが表示されたら、コントラクトはデプロイされ、さらなる進捗は _server_ タブで行われます。 そこで、「_Verifier address: 0x...._」というメッセージが表示されるまで待ちます。 + + このステップが成功すると、`mprocs`画面が表示され、左側に異なるプロセス、右側に現在選択されているプロセスのコンソール出力が表示されます。 + + ![mprocs画面](./mprocs.png) + + `mprocs`に問題がある場合は、4つのプロセスをそれぞれ独自のコマンドラインウィンドウで手動で実行できます： + + - **Anvil** + + ```sh + cd packages/contracts + anvil --base-fee 0 --block-time 2 + ``` + + - **コントラクト** + + ```sh + cd packages/contracts + pnpm mud dev-contracts --rpc http://127.0.0.1:8545 + ``` + + - **サーバー** + + ```sh + cd packages/server + pnpm start + ``` + + - **クライアント** + + ```sh + cd packages/client + pnpm run dev + ``` + +6. これで[クライアント](http://localhost:3000)にアクセスし、**New Game**をクリックしてプレイを開始できます。 + +### テーブル {#tables} + +オンチェーンには[いくつかのテーブル](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts)が必要です。 + +- `Configuration`: このテーブルはシングルトンであり、キーはなく、単一のレコードを持ちます。 ゲームの構成情報を保持するために使用されます： + - `height`：地雷原の高さ + - `width`：地雷原の幅 + - `numberOfBombs`：各地雷原の爆弾の数 + +- `VerifierAddress`: このテーブルもシングルトンです。 構成の一部である、検証者コントラクトのアドレス(`verifier`)を保持するために使用されます。 この情報を`Configuration`テーブルに入れることもできましたが、サーバーという別のコンポーネントによって設定されるため、別のテーブルに入れる方が簡単です。 + +- `PlayerGame`: キーはプレイヤーのアドレスです。 データは次のとおりです： + + - `gameId`：プレイヤーがプレイしているマップのハッシュである32バイトの値（ゲーム識別子）。 + - `win`：プレイヤーがゲームに勝ったかどうかを示すブール値。 + - `lose`：プレイヤーがゲームに負けたかどうかを示すブール値。 + - `digNumber`：ゲームでの成功した採掘の数。 + +- `GamePlayer`: このテーブルは、`gameId`からプレイヤーアドレスへの逆マッピングを保持します。 + +- `Map`: キーは3つの値のタプルです： + + - `gameId`：プレイヤーがプレイしているマップのハッシュである32バイトの値（ゲーム識別子）。 + - `x` 座標 + - `y` 座標 + + 値は単一の数値です。 爆弾が検出された場合は255です。 それ以外の場合は、その場所の周りの爆弾の数に1を加えたものです。 爆弾の数だけを使用することはできません。なぜなら、デフォルトではEVM内のすべてのストレージとMUD内のすべての行の値がゼロだからです。 「プレイヤーはまだここを掘っていない」と「プレイヤーはここを掘って、周りに爆弾がゼロであることを見つけた」とを区別する必要があります。 + +さらに、クライアントとサーバー間の通信はオンチェーンコンポーネントを介して行われます。 これもテーブルを使用して実装されています。 + +- `PendingGame`: 新しいゲームを開始するための未処理のリクエスト。 +- `PendingDig`: 特定のゲームの特定の場所で掘るための未処理のリクエスト。 これは[オフチェーンテーブル](https://mud.dev/store/tables#types-of-tables)であり、EVMストレージには書き込まれず、イベントを使用してオフチェーンでのみ読み取り可能です。 + +### 実行とデータフロー {#execution-data-flows} + +これらのフローは、クライアント、オンチェーンコンポーネント、サーバー間の実行を調整します。 + +#### 初期化 {#initialization-flow} + +`mprocs`を実行すると、次のステップが実行されます： + +1. [`mprocs`](https://github.com/pvolok/mprocs)は4つのコンポーネントを実行します： + + - [Anvil](https://book.getfoundry.sh/anvil/)、ローカルブロックチェーンを実行します + - [Contracts](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/contracts)、MUDのコントラクトをコンパイル(必要に応じて)し、デプロイします + - [Client](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/client)、UIとクライアントコードをWebブラウザに提供するために[Vite](https://vitejs.dev/)を実行します。 + - [Server](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/server)、サーバーアクションを実行します + +2. `contracts`パッケージはMUDコントラクトをデプロイし、その後[ `PostDeploy.s.sol` スクリプト](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol)を実行します。 このスクリプトは構成を設定します。 githubのコードは[10x5の地雷原に8つの地雷があること](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol#L23)を指定しています。 + +3. [サーバー](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts)は[MUDの設定](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L6)から始まります。 とりわけ、これによりデータ同期が有効になり、関連するテーブルのコピーがサーバーのメモリに存在することになります。 + +4. サーバーは、[`Configuration`テーブルが変更されたときに](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L23)実行される関数をサブスクライブします。 [この関数](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L24-L168)は、`PostDeploy.s.sol`が実行されてテーブルを変更した後に呼び出されます。 + +5. サーバーの初期化関数が構成を取得すると、[サーバーのゼロ知識部分](#using-zokrates-from-typescript)を初期化するために[`zkFunctions`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L34-L35)を呼び出します。 ゼロ知識関数は地雷原の幅と高さを定数として持つ必要があるため、構成を取得するまでこれは実行できません。 + +6. サーバーのゼロ知識部分が初期化された後、次のステップは[ゼロ知識検証コントラクトをブロックチェーンにデプロイ](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L42-L53)し、MUDで検証対象のアドレスを設定することです。 + +7. 最後に、プレイヤーが[新しいゲームの開始](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71)または[既存のゲームでの採掘](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73-L108)をリクエストしたときに表示されるように、アップデートをサブスクライブします。 + +#### 新しいゲーム {#new-game-flow} + +これはプレイヤーが新しいゲームをリクエストしたときに起こることです。 + +1. このプレイヤーに進行中のゲームがない場合、またはゲームIDがゼロのゲームがある場合、クライアントは[新しいゲームボタン](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175)を表示します。 ユーザーがこのボタンを押すと、[Reactは`newGame`関数を実行します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L96)。 + +2. [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L43-L46)は`System`コールです。 MUDでは、すべての呼び出しは`World`コントラクトを経由し、ほとんどの場合、`__`を呼び出します。 この場合、呼び出しは`app__newGame`であり、MUDはそれを[`GameSystem`の`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L16-L22)にルーティングします。 + +3. オンチェーン関数は、プレイヤーが進行中のゲームを持っていないことを確認し、持っていない場合は[`PendingGame`テーブルにリクエストを追加します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L21)。 + +4. サーバーは`PendingGame`の変更を検出し、[サブスクライブされた関数を実行します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71)。 この関数は[`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L110-L114)を呼び出し、それがさらに[`createGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L116-L144)を呼び出します。 + +5. `createGame`が最初に行うことは、[適切な数の地雷を持つランダムなマップを作成することです](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L120-L135)。 次に、Zokratesに必要な、空白の境界線を持つマップを作成するために[`makeMapBorders`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L147-L166)を呼び出します。 最後に、`createGame`は[`calculateMapHash`](#calculateMapHash)を呼び出して、ゲームIDとして使用されるマップのハッシュを取得します。 + +6. `newGame`関数は新しいゲームを`gamesInProgress`に追加します。 + +7. サーバーが最後に行うことは、オンチェーンにある[`app__newGameResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L38-L43)を呼び出すことです。 この関数は、アクセス制御を有効にするために、別の`System`、[`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol)にあります。 アクセス制御は、[MUD構成ファイル](https://mud.dev/config)、[`mud.config.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts#L67-L72)で定義されています。 + + アクセスリストは、単一のアドレスのみが`System`を呼び出すことを許可します。 これにより、サーバー関数へのアクセスが単一のアドレスに制限されるため、誰もサーバーになりすますことはできません。 + +8. オンチェーンコンポーネントは関連するテーブルを更新します： + + - `PlayerGame`でゲームを作成します。 + - `GamePlayer`で逆マッピングを設定します。 + - `PendingGame`からリクエストを削除します。 + +9. サーバーは`PendingGame`の変更を識別しますが、[`wantsGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L58-L60)がfalseであるため、何もしません。 + +10. クライアントでは、[`gameRecord`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L143-L148)はプレイヤーのアドレスの`PlayerGame`エントリに設定されます。 `PlayerGame`が変更されると、`gameRecord`も変更されます。 + +11. `gameRecord`に値があり、ゲームが勝利または敗北していない場合、クライアントは[マップを表示します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190)。 + +#### 採掘 {#dig-flow} + +1. プレイヤーは[マップセルのボタンをクリックし](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L188)、[ `dig` 関数](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L33-L36)を呼び出します。 この関数は[オンチェーンで `dig` を呼び出します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L24-L32)。 + +2. オンチェーンコンポーネントは[いくつかのサニティチェックを実行し](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L25-L30)、成功した場合、採掘リクエストを[`PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L31)に追加します。 + +3. サーバーは[`PendingDig`の変更を検出します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73)。 [それが有効な場合](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L75-L84)、結果とそれが有効であることの証明の両方を生成するために[ゼロ知識コードを呼び出します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L86-L95)（後述）。 + +4. [サーバー](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L97-L107)はオンチェーンで[`digResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L45-L64)を呼び出します。 + +5. `digResponse`は2つのことを行います。 まず、[ゼロ知識証明をチェックします](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L47-L61)。 次に、証明がチェックアウトされた場合、実際に結果を処理するために[`processDigResult`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L67-L86)を呼び出します。 + +6. `processDigResult`は、ゲームが[負けた](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L76-L78)か[勝った](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L83-L86)かを確認し、[オンチェーンマップである`Map`を更新します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L80)。 + +7. クライアントはアップデートを自動的に取得し、[プレイヤーに表示されるマップを更新し](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190)、該当する場合は勝ちか負けかをプレイヤーに伝えます。 + +## Zokratesの使用 {#using-zokrates} + +上記で説明したフローでは、ゼロ知識の部分をブラックボックスとして扱い、スキップしました。 では、それを開いて、そのコードがどのように書かれているかを見てみましょう。 + +### マップのハッシュ化 {#hashing-map} + +使用するZokratesハッシュ関数である[Poseidon](https://www.poseidon-hash.info)を実装するために、[このJavaScriptコード](https://github.com/ZK-Plus/ICBC24_Tutorial_Compute-Offchain-Verify-onchain/tree/solutions/exercise)を使用できます。 しかし、これは高速ですが、Zokratesハッシュ関数を使用して行うよりも複雑になります。 これはチュートリアルなので、コードはパフォーマンスではなく、シンプルさのために最適化されています。 したがって、2つの異なるZokratesプログラムが必要です。1つはマップのハッシュを計算するためだけのもので（`hash`）、もう1つは実際にマップ上の場所での採掘結果のゼロ知識証明を作成するためのものです（`dig`）。 + +### ハッシュ関数 {#hash-function} + +これはマップのハッシュを計算する関数です。 このコードを一行ずつ見ていきましょう。 + +``` +import "hashes/poseidon/poseidon.zok" as poseidon; +import "utils/pack/bool/pack128.zok" as pack128; +``` + +これら2行は、[Zokrates標準ライブラリ](https://zokrates.github.io/toolbox/stdlib.html)から2つの関数をインポートします。 [最初の関数](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/hashes/poseidon/poseidon.zok)は[Poseidonハッシュ](https://www.poseidon-hash.info/)です。 これは[`field`要素](https://zokrates.github.io/language/types.html#field)の配列を受け取り、`field`を返します。 + +Zokratesのフィールド要素は通常256ビット未満ですが、それほど短くはありません。 コードを簡略化するために、マップを最大512ビットに制限し、4つのフィールドの配列をハッシュ化し、各フィールドでは128ビットのみを使用します。 [`pack128`関数](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/utils/pack/bool/pack128.zok)は、この目的のために128ビットの配列を`field`に変更します。 + +``` + def hashMap(bool[${width+2}][${height+2}] map) -> field { +``` + +この行は関数定義を開始します。 `hashMap`は、`map`という単一のパラメータ、2次元の`bool`(ean)配列を取得します。 マップのサイズは、[後で説明する](#why-map-border)理由により、`width+2` x `height+2`です。 + +Zokratesプログラムはこのアプリケーションで[テンプレート文字列](https://www.w3schools.com/js/js_string_templates.asp)として保存されているため、`${width+2}`と`${height+2}`を使用できます。 `${`と`}`の間のコードはJavaScriptによって評価され、この方法でプログラムは異なるマップサイズに使用できます。 マップパラメータには、爆弾のない1つの場所幅の境界線が周囲にあり、これが幅と高さに2を加える必要がある理由です。 + +戻り値はハッシュを含む`field`です。 + +``` + bool[512] mut map1d = [false; 512]; +``` + +マップは2次元です。 しかし、`pack128`関数は2次元配列では機能しません。 そこで、まず`map1d`を使用してマップを512バイトの配列にフラット化します。 デフォルトではZokratesの変数は定数ですが、ループ内でこの配列に値を代入する必要があるため、[`mut`](https://zokrates.github.io/language/variables.html#mutability)として定義します。 + +Zokratesには`undefined`がないため、配列を初期化する必要があります。 `[false; 512]`という式は、[512個の`false`値の配列](https://zokrates.github.io/language/types.html#declaration-and-initialization)を意味します。 + +``` + u32 mut counter = 0; +``` + +また、`map1d`に既に埋め込まれたビットとそうでないビットを区別するためにカウンターも必要です。 + +``` + for u32 x in 0..${width+2} { +``` + +これはZokratesで[`for`ループ](https://zokrates.github.io/language/control_flow.html#for-loops)を宣言する方法です。 Zokratesの`for`ループは固定の境界を持つ必要があります。なぜなら、ループのように見えますが、コンパイラは実際にはそれを「展開」するからです。 `width`はTypeScriptコードがコンパイラを呼び出す前に設定されるため、式`${width+2}`はコンパイル時定数です。 + +``` + for u32 y in 0..${height+2} { + map1d[counter] = map[x][y]; + counter = counter+1; + } + } +``` + +マップ内のすべての場所について、その値を`map1d`配列に入れ、カウンターをインクリメントします。 + +``` + field[4] hashMe = [ + pack128(map1d[0..128]), + pack128(map1d[128..256]), + pack128(map1d[256..384]), + pack128(map1d[384..512]) + ]; +``` + +`pack128`は`map1d`から4つの`field`値の配列を作成します。 Zokratesでは`array[a..b]`は`a`で始まり`b-1`で終わる配列のスライスを意味します。 + +``` + return poseidon(hashMe); +} +``` + +`poseidon`を使用してこの配列をハッシュに変換します。 + +### ハッシュプログラム {#hash-program} + +サーバーはゲーム識別子を作成するために`hashMap`を直接呼び出す必要があります。 しかし、Zokratesはプログラムを開始するために`main`関数しか呼び出せないため、ハッシュ関数を呼び出す`main`を持つプログラムを作成します。 + +``` +${hashFragment} + +def main(bool[${width+2}][${height+2}] map) -> field { + return hashMap(map); +} +``` + +### digプログラム {#dig-program} + +これはアプリケーションのゼロ知識部分の中心であり、採掘結果を検証するために使用される証明を生成します。 + +``` +${hashFragment} + +// (x,y)の位置にある地雷の数 +def map2mineCount(bool[${width+2}][${height+2}] map, u32 x, u32 y) -> u8 { + return if map[x+1][y+1] { 1 } else { 0 }; +} +``` + +#### なぜマップの境界線が必要なのか {#why-map-border} + +ゼロ知識証明は、`if`文に簡単な同等のものがない[算術回路](https://medium.com/web3studio/simple-explanations-of-arithmetic-circuits-and-zero-knowledge-proofs-806e59a79785)を使用します。 代わりに、[条件演算子](https://en.wikipedia.org/wiki/Ternary_conditional_operator)の同等のものを使用します。 `a`がゼロか1のいずれかである場合、`if a { b } else { c }`は`ab+(1-a)c`として計算できます。 + +このため、Zokratesの`if`文は常に両方の分岐を評価します。 たとえば、次のコードがあるとします。 + +``` +bool[5] arr = [false; 5]; +u32 index=10; +return if index>4 { 0 } else { arr[index] } +``` + +後でその値がゼロで乗算されるにもかかわらず、`arr[10]`を計算する必要があるため、エラーが発生します。 + +これが、マップの周囲に1つの場所幅の境界線が必要な理由です。 場所の周りの地雷の総数を計算する必要があり、それは、採掘している場所の上下、左右の場所を見る必要があることを意味します。 つまり、これらの場所はZokratesに提供されるマップ配列に存在する必要があります。 + +``` +def main(private bool[${width+2}][${height+2}] map, u32 x, u32 y) -> (field, u8) { +``` + +デフォルトでは、Zokratesの証明にはその入力が含まれています。 あるスポットの周りに5つの地雷があると知っていても、実際にどのスポットかがわからなければ意味がありません（また、自分のリクエストと照合するだけではダメです。なぜなら、証明者は異なる値を使用して、それについて教えない可能性があるからです）。 しかし、マップを秘密にしておく必要がありますが、Zokratesに提供する必要もあります。 解決策は、証明によって_明らかにされない_`private`パラメータを使用することです。 + +これにより、別の悪用の機会が開かれます。 証明者は正しい座標を使用するかもしれませんが、場所の周りや場所自体に任意の数の地雷を持つマップを作成する可能性があります。 この悪用を防ぐために、ゼロ知識証明にゲーム識別子であるマップのハッシュを含めます。 + +``` + return (hashMap(map), +``` + +ここでの戻り値は、採掘結果だけでなく、マップのハッシュ配列も含むタプルです。 + +``` + if map2mineCount(map, x, y) > 0 { 0xFF } else { +``` + +場所自体に爆弾がある場合、特別な値として255を使用します。 + +``` + map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) + + map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) + + map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1) + } + ); +} +``` + +プレイヤーが地雷を踏んでいない場合、その場所の周りの地雷の数を合計して返します。 + +### TypeScriptからZokratesを使用する {#using-zokrates-from-typescript} + +Zokratesにはコマンドラインインターフェースがありますが、このプログラムでは[TypeScriptコード](https://zokrates.github.io/toolbox/zokrates_js.html)で使用します。 + +Zokratesの定義を含むライブラリは[`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts)と呼ばれます。 + +```typescript +import { initialize as zokratesInitialize } from "zokrates-js" +``` + +[Zokrates JavaScriptバインディング](https://zokrates.github.io/toolbox/zokrates_js.html)をインポートします。 Zokratesのすべての定義に解決されるプロミスを返すため、[`initialize`](https://zokrates.github.io/toolbox/zokrates_js.html#initialize)関数のみが必要です。 + +```typescript +export const zkFunctions = async (width: number, height: number) : Promise => { +``` + +Zokrates自体と同様に、1つの関数のみをエクスポートします。これも[非同期](https://www.w3schools.com/js/js_async.asp)です。 最終的に返されるとき、以下で見るようにいくつかの関数を提供します。 + +```typescript +const zokrates = await zokratesInitialize() +``` + +Zokratesを初期化し、ライブラリから必要なものをすべて取得します。 + +```typescript +const hashFragment = ` + import "utils/pack/bool/pack128.zok" as pack128; + import "hashes/poseidon/poseidon.zok" as poseidon; + . + . + . + } + ` + +const hashProgram = ` + ${hashFragment} + . + . + . + ` + +const digProgram = ` + ${hashFragment} + . + . + . + ` +``` + +次に、上記で見たハッシュ関数と2つのZokratesプログラムがあります。 + +```typescript +const digCompiled = zokrates.compile(digProgram) +const hashCompiled = zokrates.compile(hashProgram) +``` + +ここでこれらのプログラムをコンパイルします。 + +```typescript +// ゼロ知識検証用のキーを作成します。 +// 本番システムでは、セットアップセレモニーを使用することをお勧めします。 +// (https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony)。 +const keySetupResults = zokrates.setup(digCompiled.program, "") +const verifierKey = keySetupResults.vk +const proverKey = keySetupResults.pk +``` + +本番システムでは、より複雑な[セットアップセレモニー](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony)を使用するかもしれませんが、デモンストレーションにはこれで十分です。 ユーザーが証明者キーを知っていても問題ありません。それが真実でない限り、それを使って物事を証明することはできません。 エントロピー（2番目のパラメータ、`""`）を指定しているため、結果は常に同じになります。 + +**注：** Zokratesプログラムのコンパイルとキーの作成は遅いプロセスです。 毎回繰り返す必要はなく、マップサイズが変更されたときだけです。 本番システムでは、一度実行し、出力を保存します。 ここでそれをしていない唯一の理由は、単純さのためです。 + +#### `calculateMapHash` {#calculateMapHash} + +```typescript +const calculateMapHash = function (hashMe: boolean[][]): string { + return ( + "0x" + + BigInt(zokrates.computeWitness(hashCompiled, [hashMe]).output.slice(1, -1)) + .toString(16) + .padStart(64, "0") + ) +} +``` + +`computeWitness`関数(https://zokrates.github.io/toolbox/zokrates_js.html#computewitnessartifacts-args-options)は実際にZokratesプログラムを実行します。 これは2つのフィールドを持つ構造体を返します：JSON文字列としてのプログラムの出力である`output`、および結果のゼロ知識証明を作成するために必要な情報である`witness`です。 ここでは出力のみが必要です。 + +出力は`"31337"`の形式の文字列で、引用符で囲まれた10進数です。 しかし、`viem`に必要な出力は`0x60A7`の形式の16進数です。 そこで、`.slice(1,-1)`を使用して引用符を削除し、次に`BigInt`を使用して残りの文字列（10進数）を[`BigInt`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt)に変換します。 `.toString(16)`はこの`BigInt`を16進文字列に変換し、`"0x"+`は16進数のマーカーを追加します。 + +```typescript +// 採掘し、結果のゼロ知識証明を返します +// (サーバーサイドコード) +``` + +ゼロ知識証明には、公開入力（`x`と`y`）と結果（マップのハッシュと爆弾の数）が含まれます。 + +```typescript + const zkDig = function(map: boolean[][], x: number, y: number) : any { + if (x<0 || x>=width || y<0 || y>=height) + throw new Error("Trying to dig outside the map") +``` + +Zokratesでインデックスが範囲外かどうかを確認するのは問題なので、ここで行います。 + +```typescript +const runResults = zokrates.computeWitness(digCompiled, [map, `${x}`, `${y}`]) +``` + +digプログラムを実行します。 + +```typescript + const proof = zokrates.generateProof( + digCompiled.program, + runResults.witness, + proverKey) + + return proof + } +``` + +[`generateProof`](https://zokrates.github.io/toolbox/zokrates_js.html#generateproofprogram-witness-provingkey-entropy)を使用して証明を返し、それを返します。 + +```typescript +const solidityVerifier = ` + // マップサイズ: ${width} x ${height} + \n${zokrates.exportSolidityVerifier(verifierKey)} + ` +``` + +Solidity検証者、ブロックチェーンにデプロイして`digCompiled.program`によって生成された証明を検証するために使用できるスマートコントラクト。 + +```typescript + return { + zkDig, + calculateMapHash, + solidityVerifier, + } +} +``` + +最後に、他のコードが必要とする可能性のあるすべてを返します。 + +## セキュリティテスト {#security-tests} + +機能のバグはいずれ明らかになるため、セキュリティテストは重要です。 しかし、アプリケーションが安全でない場合、誰かが不正行為をして他人のリソースを手に入れてしまうまで、それが長期間隠されたままである可能性が高いです。 + +### パーミッション {#permissions} + +このゲームには特権を持つエンティティが1つ、サーバーがあります。 これは、[`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol)の関数を呼び出すことを許可された唯一のユーザーです。 [`cast`](https://book.getfoundry.sh/cast/)を使用して、許可された関数への呼び出しがサーバーアカウントとしてのみ許可されていることを確認できます。 + +[サーバーの秘密鍵は`setupNetwork.ts`にあります](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/mud/setupNetwork.ts#L52)。 + +1. `anvil`（ブロックチェーン）を実行するコンピュータで、これらの環境変数を設定します。 + + ```sh copy + WORLD_ADDRESS=0x8d8b6b8414e1e3dcfd4168561b9be6bd3bf6ec4b + UNAUTHORIZED_KEY=0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a + AUTHORIZED_KEY=0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d + ``` + +2. `cast`を使用して、検証者アドレスを未承認のアドレスとして設定しようとします。 + + ```sh copy + cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $UNAUTHORIZED_KEY + ``` + + `cast`が失敗を報告するだけでなく、ブラウザのゲームで**MUD Dev Tools**を開き、**Tables**をクリックして、**app\_\_VerifierAddress**を選択することもできます。 アドレスがゼロでないことを確認してください。 + +3. 検証者アドレスをサーバーのアドレスとして設定します。 + + ```sh copy + cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $AUTHORIZED_KEY + ``` + + **app\_\_VerifiedAddress**のアドレスはゼロになるはずです。 + +同じ`System`内のすべてのMUD関数は同じアクセス制御を通過するため、このテストで十分だと考えます。 そうでない場合は、[`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol)の他の関数を確認できます。 + +### ゼロ知識の悪用 {#zero-knowledge-abuses} + +Zokratesを検証するための数学は、このチュートリアル（そして私の能力）の範囲を超えています。 しかし、ゼロ知識コードに対してさまざまなチェックを実行して、正しく行われていない場合に失敗することを確認できます。 これらのテストはすべて、[`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts)を変更し、アプリケーション全体を再起動する必要があります。 サーバープロセスを再起動するだけでは不十分です。なぜなら、アプリケーションが不可能な状態になるからです（プレイヤーは進行中のゲームを持っていますが、そのゲームはサーバーにとって利用できなくなっています）。 + +#### 間違った答え {#wrong-answer} + +最も単純な可能性は、ゼロ知識証明で間違った答えを提供することです。 そのためには、`zkDig`の内部に入り、[91行目を変更します](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L91)： + +```ts +proof.inputs[3] = "0x" + "1".padStart(64, "0") +``` + +これは、正しい答えに関係なく、常に1つの爆弾があると主張することを意味します。 このバージョンでプレイしてみてください。`pnpm dev`画面の**server**タブに次のエラーが表示されます： + +``` + cause: { + code: 3, + message: 'execution reverted: revert: Zero knowledge verification fail', + data: '0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000 +000000000000000000000000000000000000000000000000205a65726f206b6e6f776c6564676520766572696669636174696f6 +e206661696c' + }, +``` + +したがって、この種の不正行為は失敗します。 + +#### 間違った証明 {#wrong-proof} + +正しい情報を提供するが、証明データが間違っている場合はどうなりますか？ では、91行目を次のように置き換えます。 + +```ts +proof.proof = { + a: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + b: [ + ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], + ], + c: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")], +} +``` + +それでも失敗しますが、今回は検証者呼び出し中に発生するため、理由なしで失敗します。 + +### ユーザーはどのようにしてゼロトラストコードを検証できますか？ {#user-verify-zero-trust} + +スマートコントラクトは比較的簡単に検証できます。 通常、デベロッパーはソースコードをブロックエクスプローラーに公開し、ブロックエクスプローラーはソースコードが[コントラクトデプロイメントトランザクション](/developers/docs/smart-contracts/deploying/)のコードにコンパイルされることを確認します。 MUD `System`sの場合、これは[少し複雑です](https://mud.dev/cli/verify)が、それほどではありません。 + +ゼロ知識ではこれはより困難です。 検証者はいくつかの定数を含み、それらに対していくつかの計算を実行します。 これは、何が証明されているかを教えてくれません。 + +```solidity + function verifyingKey() pure internal returns (VerifyingKey memory vk) { + vk.alpha = Pairing.G1Point(uint256(0x0f43f4fe7b5c2326fed4ac6ed2f4003ab9ab4ea6f667c2bdd77afb068617ee16), uint256(0x25a77832283f9726935219b5f4678842cda465631e72dbb24708a97ba5d0ce6f)); + vk.beta = Pairing.G2Point([uint256(0x2cebd0fbd21aca01910581537b21ae4fed46bc0e524c055059aa164ba0a6b62b), uint256(0x18fd4a7bc386cf03a95af7163d5359165acc4e7961cb46519e6d9ee4a1e2b7e9)], [uint256(0x11449dee0199ef6d8eebfe43b548e875c69e7ce37705ee9a00c81fe52f11a009), uint256(0x066d0c83b32800d3f335bb9e8ed5e2924cf00e77e6ec28178592eac9898e1a00)]); +``` + +解決策は、少なくともブロックエクスプローラーがユーザーインターフェースにZokrates検証を追加するまでは、アプリケーション開発者がZokratesプログラムを利用可能にし、少なくとも一部のユーザーが適切な検証キーを使用して自分でコンパイルすることです。 + +そのためには： + +1. [Zokratesをインストールします](https://zokrates.github.io/gettingstarted.html)。 + +2. Zokratesプログラムを含む`dig.zok`というファイルを作成します。 以下のコードは、元のマップサイズ10x5を維持していることを前提としています。 + + ```zokrates + import "utils/pack/bool/pack128.zok" as pack128; + import "hashes/poseidon/poseidon.zok" as poseidon; + + def hashMap(bool[12][7] map) -> field { + bool[512] mut map1d = [false; 512]; + u32 mut counter = 0; + + for u32 x in 0..12 { + for u32 y in 0..7 { + map1d[counter] = map[x][y]; + counter = counter+1; + } + } + + field[4] hashMe = [ + pack128(map1d[0..128]), + pack128(map1d[128..256]), + pack128(map1d[256..384]), + pack128(map1d[384..512]) + ]; + + return poseidon(hashMe); + } + + + // (x,y)の位置にある地雷の数 + def map2mineCount(bool[12][7] map, u32 x, u32 y) -> u8 { + return if map[x+1][y+1] { 1 } else { 0 }; + } + + def main(private bool[12][7] map, u32 x, u32 y) -> (field, u8) { + return (hashMap(map) , + if map2mineCount(map, x, y) > 0 { 0xFF } else { + map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) + + map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) + + map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1) + } + ); + } + ``` + +3. Zokratesコードをコンパイルし、検証キーを作成します。 検証キーは、元のサーバーで使用されたのと同じエントロピーで作成する必要があります。[この場合は空の文字列です](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L67)。 + + ```sh copy + zokrates compile --input dig.zok + zokrates setup -e "" + ``` + +4. 自分でSolidity検証者を作成し、ブロックチェーン上のものと機能的に同一であることを確認します（サーバーはコメントを追加しますが、それは重要ではありません）。 + + ```sh copy + zokrates export-verifier + diff verifier.sol ~/20240901-secret-state/packages/contracts/src/verifier.sol + ``` + +## 設計上の決定 {#design} + +十分に複雑なアプリケーションでは、トレードオフを必要とする競合する設計目標があります。 いくつかのトレードオフと、現在の解決策が他の選択肢よりも好ましい理由を見てみましょう。 + +### なぜゼロ知識なのか {#why-zero-knowledge} + +マインスイーパには、実際にはゼロ知識は必要ありません。 サーバーは常にマップを保持し、ゲームが終了したときにすべてを明らかにすることができます。 その後、ゲームの終わりに、スマートコントラクトはマップのハッシュを計算し、それが一致することを確認し、一致しない場合はサーバーにペナルティを課すか、ゲームを完全に無視することができます。 + +このより単純な解決策を使用しなかったのは、明確な終了ステートを持つ短いゲームでのみ機能するためです。 ゲームが潜在的に無限である場合（[自律的な世界](https://0xparc.org/blog/autonomous-worlds)の場合など）、ステートを明らかに_せずに_証明する解決策が必要です。 + +チュートリアルとして、この記事は理解しやすい短いゲームを必要としていましたが、このテクニックはより長いゲームに最も役立ちます。 + +### なぜZokratesなのか？ {#why-zokrates} + +[Zokrates](https://zokrates.github.io/)は利用可能な唯一のゼロ知識ライブラリではありませんが、通常の[命令型](https://en.wikipedia.org/wiki/Imperative_programming)プログラミング言語に類似しており、ブール変数をサポートしています。 + +あなたのアプリケーションでは、要件が異なるため、[Circum](https://docs.circom.io/getting-started/installation/)または[Cairo](https://www.cairo-lang.org/tutorials/getting-started-with-cairo/)を使用することを好むかもしれません。 + +### Zokratesをいつコンパイルするか {#when-compile-zokrates} + +このプログラムでは、[サーバーが起動するたびに](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L60-L61)Zokratesプログラムをコンパイルします。 これは明らかにリソースの無駄ですが、これはチュートリアルであり、単純さのために最適化されています。 + +本番レベルのアプリケーションを書いていたとしたら、この地雷原サイズのコンパイル済みZokratesプログラムのファイルがあるかどうかを確認し、もしあればそれを使用するでしょう。 オンチェーンで検証者コントラクトをデプロイする場合も同様です。 + +### 検証者キーと証明者キーの作成 {#key-creation} + +[キーの作成](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L63-L69)は、特定の地雷原サイズに対して一度以上行う必要のない純粋な計算です。 繰り返しますが、単純さのために一度だけ行われます。 + +さらに、[セットアップセレモニー](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony)を使用することもできます。 セットアップセレモニーの利点は、ゼロ知識証明で不正行為をするためには、各参加者からのエントロピーまたはいくつかの中間結果が必要であることです。 少なくとも1人のセレモニー参加者が正直で、その情報を削除すれば、ゼロ知識証明は特定の攻撃から安全です。 しかし、情報がどこからでも削除されたことを確認する_メカニズムはありません_。 ゼロ知識証明が非常に重要な場合は、セットアップセレモニーに参加することをお勧めします。 + +ここでは、数十人の参加者がいた[perpetual powers of tau](https://github.com/privacy-scaling-explorations/perpetualpowersoftau)に依存しています。 おそらく十分に安全で、はるかに単純です。 また、キー作成中にエントロピーを追加しないため、ユーザーが[ゼロ知識構成を検証](#user-verify-zero-trust)しやすくなります。 + +### どこで検証するか {#where-verification} + +ゼロ知識証明はオンチェーン（ガスがかかる）またはクライアント（[`verify`](https://zokrates.github.io/toolbox/zokrates_js.html#verifyverificationkey-proof)を使用）で検証できます。 私が前者を選んだのは、これにより[検証者を一度検証](#user-verify-zero-trust)し、コントラクトアドレスが同じままである限り変更されないと信頼できるからです。 検証がクライアントで行われた場合、クライアントをダウンロードするたびに受け取るコードを検証する必要があります。 + +また、このゲームはシングルプレイヤーですが、多くのブロックチェーンゲームはマルチプレイヤーです。 オンチェーン検証は、ゼロ知識証明を一度だけ検証することを意味します。 クライアントでそれを行うには、各クライアントが独立して検証する必要があります。 + +### マップをTypeScriptまたはZokratesでフラット化するか？ {#where-flatten} + +一般に、処理がTypeScriptまたはZokratesのいずれかで行える場合、はるかに高速で、ゼロ知識証明を必要としないTypeScriptで行う方が優れています。 これが、例えば、Zokratesにハッシュを提供して、それが正しいことを検証させない理由です。 ハッシュ化はZokrates内部で行う必要がありますが、返されたハッシュとオンチェーンのハッシュとの照合は外部で行うことができます。 + +しかし、TypeScriptでできたにもかかわらず、私たちはまだ[Zokratesでマップをフラット化しています](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L15-L20)。 その理由は、私の意見では、他の選択肢がもっと悪いからです。 + +- Zokratesコードに1次元のブール値配列を提供し、`x*(height+2) + +y`のような式を使用して2次元マップを取得します。 これにより[コード](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L44-L47)が多少複雑になるため、チュートリアルにはパフォーマンスの向上が価値がないと判断しました。 + +- Zokratesに1次元配列と2次元配列の両方を送信します。 しかし、この解決策では何も得られません。 Zokratesコードは、提供された1次元配列が本当に2次元配列の正しい表現であることを検証する必要があります。 したがって、パフォーマンスの向上はありません。 + +- Zokratesで2次元配列をフラット化します。 これが最も簡単な選択肢なので、私はそれを選びました。 + +### マップの保存場所 {#where-store-maps} + +このアプリケーションでは、[`gamesInProgress`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L20)は単にメモリ内の変数です。 これは、サーバーがダウンして再起動する必要がある場合、保存されていたすべての情報が失われることを意味します。 プレイヤーはゲームを続行できないだけでなく、オンチェーンコンポーネントがまだゲームが進行中であると考えているため、新しいゲームを開始することさえできません。 + +これは、この情報をデータベースに保存する本番システムにとっては明らかに悪い設計です。 ここで変数を使用した唯一の理由は、これがチュートリアルであり、単純さが主な考慮事項であるためです。 + +## 結論：どのような条件下でこれが適切なテクニックですか？ {#conclusion} + +これで、オンチェーンに属さない秘密のステートを保存するサーバーでゲームを書く方法がわかりました。 しかし、どのような場合にそれを行うべきでしょうか？ 主な考慮事項は2つあります。 + +- _長期間実行されるゲーム_：[上で述べたように](#why-zero-knowledge)、短いゲームでは、ゲームが終了したらステートを公開し、すべてを検証させることができます。 しかし、ゲームが長い時間または無期限にかかり、ステートを秘密にしておく必要がある場合、それは選択肢ではありません。 + +- _ある程度の中央集権化が許容される_：ゼロ知識証明は、エンティティが結果を偽造していないという整合性を検証できます。 彼らができないことは、エンティティがまだ利用可能であり、メッセージに応答することを保証することです。 可用性も分散化する必要がある状況では、ゼロ知識証明は十分な解決策ではなく、[マルチパーティ計算](https://en.wikipedia.org/wiki/Secure_multi-party_computation)が必要です。 + +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). + +### 謝辞 {#acknowledgements} + +- Alvaro Alonsoがこの記事の草稿を読み、Zokratesに関する私の誤解のいくつかを明らかにしてくれました。 + +残りの誤りは私の責任です。 diff --git a/public/content/translations/ja/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/ja/developers/tutorials/secure-development-workflow/index.md index a8c2f9e347f..e0d4d1c2b20 100644 --- a/public/content/translations/ja/developers/tutorials/secure-development-workflow/index.md +++ b/public/content/translations/ja/developers/tutorials/secure-development-workflow/index.md @@ -1,45 +1,42 @@ --- -title: スマートコントラクトのセキュリティ・チェックリスト -description: セキュアなスマートコントラクトを作成するための推奨ワークフロー +title: "スマートコントラクトのセキュリティ・チェックリスト" +description: "セキュアなスマートコントラクトを作成するための推奨ワークフロー" author: "Trailofbits" -tags: - - "スマートコントラクト" - - "セキュリティ" - - "Solidity" +tags: [ "スマートコントラクト", "セキュリティ", "Solidity" ] skill: intermediate lang: ja published: 2020-09-07 -source: セキュアなコントラクトの開発 +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md --- -## スマートコントラクトの開発チェックリスト {#smart-contract-development-checklist} +## スマートコントラクト開発チェックリスト {#smart-contract-development-checklist} スマートコントラクトを作成する際には、以下に挙げる大まかなプロセスに従って行うことをお勧めします。 既知のセキュリティ関連の問題点について確認します： -- [Slither](https://github.com/crytic/slither)で、コントラクトをレビューする。 Slitherには、40種類以上のよくある脆弱性を対象とする検出機能が搭載されています。 新しいコードが追加されるたびにレビューを実行して、クリーンな報告になるようにします（特定の問題を無視する必要がある場合は、トリアージモードを使用します）。 -- [Crytic](https://crytic.io/)で、コントラクトをレビューする。 Cryticでは、Slitherでは検出できな50種類の問題点を確認できます。 さらに、GitHubのプルリクエストに含まれるセキュリティ関連の問題点を簡単に発見できるので、チーム内の問題把握に役立ちます。 +- [Slither](https://github.com/crytic/slither)でコントラクトをレビューする。 Slitherには、40種類以上のよくある脆弱性を対象とする検出機能が搭載されています。 新しいコードが追加されるたびにレビューを実行して、クリーンな報告になるようにします（特定の問題を無視する必要がある場合は、トリアージモードを使用します）。 +- [Crytic](https://crytic.io/)でコントラクトをレビューする。 Cryticでは、Slitherでは検出できな50種類の問題点を確認できます。 さらに、GitHubのプルリクエストに含まれるセキュリティ関連の問題点を簡単に発見できるので、チーム内の問題把握に役立ちます。 あなたのコントラクトに含まれる特別な機能について検討する： -- コントラクトがアップグレード可能かどうか： [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks)または[Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/)を使って、アップグレード可能性に関するコードに欠陥がないか確認します。 当チームでは、アップグレードの失敗につながる17のケースを文書化しています。 -- コントラクトは、ERC準拠を謳っていますか？ [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance)で確認してください。 このツールでは、6種類の一般的な仕様に準拠していない場合、ただちに指摘されます。 -- サードパーティのトークンと統合予定ですか？ 外部コントラクトを利用する事前に、この[トークン統合チェックリスト](/developers/tutorials/token-integration-checklist/)でレビューしてください。 +- コントラクトがアップグレード可能かどうか： [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks)または[Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/)で、アップグレード可能性コードの欠陥をレビューする。 当チームでは、アップグレードの失敗につながる17のケースを文書化しています。 +- コントラクトは、ERC準拠を謳っていますか？ [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance)でそれらをチェックする。 このツールでは、6種類の一般的な仕様に準拠していない場合、ただちに指摘されます。 +- サードパーティのトークンと統合予定ですか？ 外部コントラクトに依存する前に、[トークン統合チェックリスト](/developers/tutorials/token-integration-checklist/)をレビューする。 コードにおける重要なセキュリティ関連の機能を、視覚的にチェックします。 -- Slitherの[inheritance-graph ](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph)プリンターをレビューします。 不注意によるシャドーイングやC3 linearizationにまつわる問題を回避してください。 -- Slitherで、[機能サマリー](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary)のプリンター（表示）をレビューします。 機能の可視性およびアクセス管理のレポートが作成されます。 -- Slitherの[vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization)プリンタをレビューします。 状態変数に対するアクセス管理のレポートが作成されます。 +- Slitherの[inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph)プリンターをレビューする。 不注意によるシャドーイングやC3 linearizationにまつわる問題を回避してください。 +- Slitherの[function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary)プリンターをレビューする。 機能の可視性およびアクセス管理のレポートが作成されます。 +- Slitherの[vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization)プリンターをレビューする。 状態変数に対するアクセス管理のレポートが作成されます。 セキュリティ関連の重要な属性を文書化し、自動化されたテスト生成機能を用いて評価します： -- [コードにおけるセキュリティ属性を文書化する](/developers/tutorials/guide-to-smart-contract-security-tools/)方法について学びます。 最初は大変ですが、最良の結果を得る上で最も重要な作業です。 また、このチュートリアルのより高度なテクニックを活用する上でも、必須の作業です。 -- [Echidna](https://github.com/crytic/echidna)および[Manticore](https://manticore.readthedocs.io/en/latest/verifier.html)で使用するために、Solidityでセキュリティ関連の属性を定義します。 状態マシン、アクセス管理、算術演算、外部とのやりとり、および標準の遵守に焦点を当ててください。 -- [SlitherのPython API](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)で、セキュリティ関連のプロパティを定義します。 継承、変数の依存関係、アクセス管理、およびその他の構造上の問題に焦点を当ててください。 -- [Crytic](https://crytic.io)を使用して、コミットごとにプロパティテストを実行します。 Cryticでは、セキュリティ属性に関するテストを実行、評価できるため、チーム全員がGitHubで合格したかどうか簡単に確認できます。 テストが不合格だった場合、コミットをブロックできます。 +- [コードのセキュリティプロパティを文書化する](/developers/tutorials/guide-to-smart-contract-security-tools/)方法を学ぶ。 最初は大変ですが、最良の結果を得る上で最も重要な作業です。 また、このチュートリアルのより高度なテクニックを活用する上でも、必須の作業です。 +- [Echidna](https://github.com/crytic/echidna)および[Manticore](https://manticore.readthedocs.io/en/latest/verifier.html)で使用するために、Solidityでセキュリティプロパティを定義する。 状態マシン、アクセス管理、算術演算、外部とのやりとり、および標準の遵守に焦点を当ててください。 +- [SlitherのPython API](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)でセキュリティプロパティを定義する。 継承、変数の依存関係、アクセス管理、およびその他の構造上の問題に焦点を当ててください。 +- [Crytic](https://crytic.io)で、コミットごとにプロパティテストを実行する。 Cryticでは、セキュリティ属性に関するテストを実行、評価できるため、チーム全員がGitHubで合格したかどうか簡単に確認できます。 テストが不合格だった場合、コミットをブロックできます。 最後に、自動化ツールでは容易に特定できない以下のような問題についても注意してください： @@ -48,8 +45,8 @@ sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/devel - 秘匿化された操作 - 外部DeFiコンポーネントとの危険なやりとり -## ヘルプを求めましょう {#ask-for-help} +## ヘルプを求める {#ask-for-help} -毎週火曜日の午後に、[イーサリアム・オフィス・アワー](https://calendly.com/dan-trailofbits/office-hours)が開かれています。 この1対1の1時間のセッションで、セキュリティに関する質問をしたり、ツールを使ってトラブルシューティングをしたり、現在のアプローチについて専門家からフィードバックを得ることができます。 私たちが、このガイドに基づいてサポートします。 +[イーサリアムオフィスアワー](https://calendly.com/dan-trailofbits/office-hours)は毎週火曜日の午後に開催されます。 この1対1の1時間のセッションで、セキュリティに関する質問をしたり、ツールを使ってトラブルシューティングをしたり、現在のアプローチについて専門家からフィードバックを得ることができます。 私たちが、このガイドに基づいてサポートします。 -ぜひ、私たちのスタックである[Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw)に参加してください。 質問があれば、いつでも#cryticチャンネルと#ethereumチャンネルにお問い合わせください。 +Slackに参加する：[Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw)。 質問があれば、いつでも#cryticチャンネルと#ethereumチャンネルにお問い合わせください。 diff --git a/public/content/translations/ja/developers/tutorials/send-token-etherjs/index.md b/public/content/translations/ja/developers/tutorials/send-token-etherjs/index.md index c160a581043..8047ed3dae4 100644 --- a/public/content/translations/ja/developers/tutorials/send-token-etherjs/index.md +++ b/public/content/translations/ja/developers/tutorials/send-token-etherjs/index.md @@ -1,6 +1,6 @@ --- -title: ethers.jsを使用したトークンの送信 -description: ethers.jsを使用してトークンを送信するための初心者向けのガイド +title: "ethers.jsを使用したトークンの送信" +description: "ethers.jsを使用してトークンを送信するための初心者向けのガイド" author: Kim YongJun tags: - "ETHERS.JS" diff --git a/public/content/translations/ja/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/ja/developers/tutorials/send-token-ethersjs/index.md index d55ad00cb25..66525f44a3d 100644 --- a/public/content/translations/ja/developers/tutorials/send-token-ethersjs/index.md +++ b/public/content/translations/ja/developers/tutorials/send-token-ethersjs/index.md @@ -1,11 +1,8 @@ --- -title: ethers.jsを使用したトークンの送信 -description: ethers.jsを使用してトークンを送信するための初心者向けのガイド +title: "ethers.jsを使用してトークンを送信する" +description: "ethers.jsを使用してトークンを送信するための初心者向けガイド。" author: Kim YongJun -tags: - - "ETHERS.JS" - - "ERC-20" - - "トークン" +tags: [ "ETHERS.JS", "ERC-20", "トークン" ] skill: beginner lang: ja published: 2021-04-06 @@ -13,15 +10,16 @@ published: 2021-04-06 ## ethers.js(5.0)を使用したトークンの送信 {#send-token} -### このチュートリアルでは、次の処理を行う方法について学びます。 {#you-learn-about} +### このチュートリアルで学ぶこと {#you-learn-about} -- ethers.js のインポート +- ethers.jsのインポート - トークンの転送 - ネットワークの混雑状況に応じたガス代の設定 ### はじめに {#to-get-started} -まず、ethers.js というライブラリを javascript にインポートする必要があります。これには、ethers.js 5.0 も含まれます。 +始めるには、まずethers.jsライブラリをJavaScriptにインポートする必要があります。 +ethers.js(5.0)をインクルードします。 ### インストール {#install-ethersjs} @@ -29,16 +27,16 @@ published: 2021-04-06 /home/ricmoo> npm install --save ethers ``` -ブラウザで ES6 を使用するには次のようにします。 +ブラウザでES6を使用するには次のようにします。 ```html ``` -ブラウザで ES3(UMD)を使用するには次のようにします。 +ブラウザでES3(UMD)を使用するには次のようにします。 ```html ``` -バックエンドで使用するライブラリをインストールしたい場合や、ビルドが必要なフロントエンドのプロジェクトの場合は、 次のようにnpmを使用してインストールします。 +バックエンドやビルドを要するフロントエンドプロジェクトで使うためにライブラリをインストールする場合は、npmを使ってインストールできます： ```bash npm install web3 --save ``` -次に、Node.jsのスクリプトやBrowserifyのフロントエンド・プロジェクトにWeb3.jsをインポートするには、以下のJavaScriptコードを使用します： +次に、Node.jsのスクリプトやBrowserifyのフロントエンドプロジェクトにWeb3.jsをインポートするには、以下のJavaScriptの行を使用します： ```js const Web3 = require("web3") ``` -プロジェクトにライブラリを追加したので、初期化する必要があります。 プロジェクトは、ブロックチェーンと通信できなければなりません。 イーサリアムのほとんどのライブラリは、リモートプロシージャーコール（RPC）を使って[ノード](/developers/docs/nodes-and-clients/)と通信します。 Web3プロバイダを開始するには、プロバイダのURLをコンストラクタとして橋渡しするWeb3のインスタンスを生成します。 お使いのコンピュータで、ノードあるいは[Ganacheインスタンス](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/)を実行中の場合は、以下のようになります： +プロジェクトにライブラリを組み込んだので、次に初期化が必要です。 プロジェクトは、ブロックチェーンと通信できる必要があります。 ほとんどのイーサリアムライブラリは、RPCコールを介して[ノード](/developers/docs/nodes-and-clients/)と通信します。 Web3プロバイダーを初期化するには、プロバイダーのURLをコンストラクタに渡してWeb3インスタンスを生成します。 お使いのコンピュータでノードまたは[ganacheインスタンスを実行](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/)している場合は、次のようになります： ```js const web3 = new Web3("http://localhost:8545") ``` -ホストされているノードに直接アクセスしたい場合は、[ノード・アズ・ア・サービス](/developers/docs/nodes-and-clients/nodes-as-a-service)の一覧から見つけることができます。 +ホストされているノードに直接アクセスしたい場合は、[サービスとしてのノード](/developers/docs/nodes-and-clients/nodes-as-a-service)でオプションを見つけることができます。 ```js const web3 = new Web3("https://cloudflare-eth.com") ``` -Web3インスタンスが正しく設定されたかをテストするために、 `getBlockNumber`関数を使用して、最新のブロック番号を取得してみましょう。 この関数は、コールバックをパラメータとして受け取り、ブロック番号を整数として返します。 +Web3インスタンスが正しく設定されたかテストするために、`getBlockNumber`関数を使って最新のブロック番号を取得してみましょう。 この関数は、コールバックをパラメータとして受け取り、ブロック番号を整数として返します。 ```js var Web3 = require("web3") @@ -56,7 +54,7 @@ web3.eth.getBlockNumber(function (error, result) { }) ``` -このプログラムを実行すると、最新のブロック番号（ブロックチェーンの最上部） が表示されます。 また、`await/async`の関数呼び出しを使用することで、コードにおける入れ子状の呼び出しを回避することができます。 +このプログラムを実行すると、最新のブロック番号、つまりブロックチェーンの最上部が、シンプルに表示されます。 また、`await/async`関数呼び出しを使うと、コード内でのコールバックのネストを避けることができます： ```js async function getBlockNumber() { @@ -68,27 +66,27 @@ async function getBlockNumber() { getBlockNumber() ``` -Web3インスタンス上で利用可能なすべての関数は、 [web3.jsの公式ドキュメンテーション](https://docs.web3js.org/)をご覧ください。 +Web3インスタンスで利用可能なすべての関数は、[web3.jsの公式ドキュメント](https://docs.web3js.org/)で確認できます。 -ほとんどのWeb3ライブラリでは、結果を送り返すノードに対してバックグラウンドでJSON RPCを呼び出すため、非同期で処理を行います。 +ほとんどのWeb3ライブラリは非同期です。これは、バックグラウンドでライブラリがノードにJSON-RPCコールを行い、ノードが結果を返すためです。 -ブラウザで作業している場合、一部のウォレットは、Web3インスタンスを直接注入します。トランザクションを行うためにユーザーのイーサリアムアドレスとやり取りを行う予定がある場合は特に、可能な限り`await/async`関数呼び出しを使用するようにしてください。 +ブラウザで作業している場合、一部のウォレットはWeb3インスタンスを直接インジェクトします。特にユーザーのイーサリアムアドレスとやり取りしてトランザクションを行う予定がある場合は、可能な限りそのインスタンスを使用するようにしてください。 -以下のコードスニペットは、MetaMaskウォレットが利用可能か確認し、利用できる場合は有効化するものです。 その後、あなたはユーザーの残高を確認できるようになり、各ユーザーは、あなたが彼らにイーサリアムブロックチェーン上で実行させたいトランザクションを各自で検証できるようになります： +これは、MetaMaskウォレットが利用可能かどうかを検出し、利用可能であれば有効化を試みるスニペットです。 これにより、後でユーザーの残高を読み取ったり、イーサリアムブロックチェーン上で実行させたいトランザクションをユーザーが検証できるようになります： ```js if (window.ethereum != null) { state.web3 = new Web3(window.ethereum) try { - // Request account access if needed + // 必要に応じてアカウントへのアクセスを要求 await window.ethereum.enable() - // Accounts now exposed + // アカウントが公開されました } catch (error) { - // User denied account access... + // ユーザーがアカウントアクセスを拒否しました... } } ``` -他にも[Ethers.js](https://docs.ethers.io/) など、 web3.js のようにイーサリアム・ブロックチェーンとやりとりするライブラリがあります。 次のチュートリアルでは、[ブロックチェーンに新たに追加されたブロックを簡単にリッスンし、その内容を確認する方法](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/)を紹介します。 +[Ethers.js](https://docs.ethers.io/)のようなweb3.jsの代替ライブラリも存在し、同様に広く使われています。 次のチュートリアルでは、[ブロックチェーン上で新たに着信するブロックを簡単にリッスンし、その内容を確認する方法](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/)を見ていきます。 diff --git a/public/content/translations/ja/developers/tutorials/short-abi/index.md b/public/content/translations/ja/developers/tutorials/short-abi/index.md index fd9cb3f38ea..72540ab722b 100644 --- a/public/content/translations/ja/developers/tutorials/short-abi/index.md +++ b/public/content/translations/ja/developers/tutorials/short-abi/index.md @@ -1,85 +1,106 @@ --- title: "コールデータを最適化するための簡潔なABI" -description: オプティミスティック・ロールアップのためのスマートコントラクトの最適化 +description: "オプティミスティック・ロールアップのためのスマートコントラクトの最適化" author: Ori Pomerantz lang: ja -tags: - - "レイヤー2" +tags: [ "レイヤー2" ] skill: intermediate published: 2022-04-01 --- ## はじめに {#introduction} -この記事では、[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups)とは何か、オプティミスティック・ロールアップにおけるトランザクションコスト、および、様々なコスト構造に応じてイーサリアム・メインネット上の様々な事項をいかに最適化すべきかについて学びます。 さらに、この最適化の実装方法についても紹介します。 +この記事では、[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups)やそのトランザクションコスト、そしてその異なるコスト構造が、Ethereumメインネットとは異なるものの最適化をどのように要求するかについて学びます。 +また、この最適化を実装する方法についても学びます。 -### 開示情報 {#full-disclosure} +### 完全な情報開示 {#full-disclosure} -筆者は、[Optimism](https://www.optimism.io/)のフルタイム従業員であり、この記事に含まれる実例はすべてOptimismで実行されます。 ただし、紹介するテクニックは他のロールアップでも問題なく実行できます。 +筆者は[Optimism](https://www.optimism.io/)のフルタイム従業員であるため、この記事の例はOptimismで実行されます。 +ただし、ここで説明するテクニックは、他のロールアップでも同様に機能するはずです。 ### 用語 {#terminology} -ロールアップの議論において、「レイヤー1」は、イーサリアムネットワークの本番環境であるメインネットを指します。 「レイヤー2」(L2)という用語は、ロールアップまたはセキュリティのためにL1に依存しているが、そのほとんどをオフチェーンで処理する他のシステムに使用されます。 +ロールアップについて議論する際、「レイヤー1」(L1) という用語は、本番のEthereumネットワークであるメインネットを指すために使用されます。 +「レイヤー2」(L2) という用語は、ロールアップ、またはセキュリティをL1に依存しつつ、処理のほとんどをオフチェーンで行うその他のシステムに使用されます。 -## L2上のトランザクションコストをさらに引き下げる方法 {#how-can-we-further-reduce-the-cost-of-L2-transactions} +## L2トランザクションのコストをさらに削減するには {#how-can-we-further-reduce-the-cost-of-L2-transactions} -[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups)では、すべてのユーザーが過去のトランザクションを参照し、現在の状態が正しいことを検証できるように、過去のすべてのトランザクション記録を保存する必要があります。 イーサリアムメインネットにデータを書き込む最も安価な方法は、コールデータとして書き込む方法です。 [Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-)と[Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups)はいずれも、コールデータのソリューションを採用しています。 +[オプティミスティック・ロールアップ](/developers/docs/scaling/optimistic-rollups)は、誰もがそれらを参照して現在の状態が正しいことを検証できるように、すべての過去のトランザクションの記録を保存する必要があります。 +Ethereumメインネットにデータを取り込む最も安価な方法は、コールデータとして書き込むことです。 +このソリューションは、[Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-)と[Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups)の両方で採用されました。 ### L2トランザクションのコスト {#cost-of-l2-transactions} -L2トランザクションのコストは、以下の2つの要素で構成されます： +L2トランザクションのコストは、2つの要素で構成されています。 -1. L2上の処理コスト。通常、非常に安価です。 -2. L1上のストレージコスト。これは、メインネットのガス代と連動します。 +1. L2処理。通常は極めて安価です。 +2. L1ストレージ。メインネットのガス代に連動します。 -この記事の執筆時点のOptimismで、L2ガス代は、0.001[Gwei](/developers/docs/gas/#pre-london)です。 一方、L1のガス代は約40Gweiです。 リアルタイムの価格は[こちら](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m)で確認できます。 +これを書いている時点では、OptimismでのL2のガス代は0.001 [Gwei](/developers/docs/gas/#pre-london)です。 +一方、L1のガス代は、約40 gweiです。 +[現在の価格はこちらで確認できます](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m)。 -1バイトのコールデータのコストは、4ガス (0バイトの場合) または16ガス (それ以外) のいずれかです。 EVMで最も費用が高い操作のひとつは、ストレージへの書き込みです。 L2上で32バイトのワードを書き込む場合、最大コストは22100ガスです。 現在のレートでは、22.1 gweiになります。 したがって、1つのコールデータをゼロバイトに節約できれば、約200バイトをストレージに書き込むことができ、まだお釣りが来ます。 +コールデータの1バイトは、それがゼロの場合は4ガス、その他の値の場合は16ガスのコストがかかります。 +EVMで最も高価な操作の1つは、ストレージへの書き込みです。 +L2でストレージに32バイトのワードを書き込む最大コストは22100ガスです。 現在、これは22.1 gweiです。 +したがって、コールデータのゼロ値のバイトを1つでも節約できれば、ストレージに約200バイトを書き込んでも、まだ利益が出ます。 ### ABI {#the-abi} -大多数のトランザクションは、外部所有アカウントからコントラクトにアクセスします。 ほとんどのコントラクトはSolidityで書かれており、データフィールドは[アプリケーション・バイナリ・インターフェイス（ABI） ](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding)で解釈されます。 +大多数のトランザクションは、外部所有アカウントからコントラクトにアクセスします。 +ほとんどのコントラクトはSolidityで書かれており、[アプリケーションバイナリインターフェース(ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding)に従ってデータフィールドを解釈します。 -ただしABIは、1バイトのコールデータがほぼ4回の算術演算のコストと同じになるL1を念頭に置いて設計されていますが、L2では、1バイトのコールデータのコストで算術演算を1000回以上実行することができます。 例えば、[このERC-20の送信トランザクション](https://kovan-optimistic.etherscan.io/tx/0x7ce4c144ebfce157b4de99d8ad53a352ae91b57b3fa06d8a1c79439df6bfa998)を見てみましょう。 コールデータは、以下のように分割されます： +しかし、ABIはL1向けに設計されており、そこではコールデータの1バイトのコストが約4回の算術演算に相当しますが、L2では1バイトのコストが1000回以上の算術演算に相当します。 +コールデータは次のように分割されます。 | セクション | 長さ | バイト | 浪費バイト | 浪費ガス | 必須バイト | 必須ガス | -| ------- | --:| -----:| -----:| ----:| -----:| ----:| -| 関数セレクタ | 4 | 0～3 | 3 | 48 | 1 | 16 | -| ゼロ値 | 12 | 4～15 | 12 | 48 | 0 | 0 | -| 送信先アドレス | 20 | 16～35 | 0 | 0 | 20 | 320 | -| 金額 | 32 | 36～67 | 17 | 64 | 15 | 240 | +| ------- | -: | ----: | ----: | ---: | ----: | ---: | +| 関数セレクタ | 4 | 0-3 | 3 | 48 | 1 | 16 | +| ゼロ | 12 | 4-15 | 12 | 48 | 0 | 0 | +| 送信先アドレス | 20 | 16-35 | 0 | 0 | 20 | 320 | +| 金額 | 32 | 36-67 | 17 | 64 | 15 | 240 | | 合計 | 68 | | | 160 | | 576 | -説明： +説明: -- **関数セレクター**: このコントラクトに含まれる関数は256未満であるため、1バイトで区別できます。 これらのバイトは通常0バイトではないので、[16ガス](https://eips.ethereum.org/EIPS/eip-2028)がかかります。 -- **0バイト **：これらのバイトは常にゼロです。と言うのも、20バイトのアドレスを保持するためには32バイトのワードを必要としないからです。 0バイトのコストは、4ガスです（[イエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf)の27ページにあるAppendix Gで、`G``txdatazero`の値について確認してください）。 -- **金額**：このコントラクトの`decimals`が18（通常値）であり、送信できるトークンの上限が1018だとすると、金額の上限は1036になります。 25615 > 1036のため、必要なバイト数は15になります。 +- **関数セレクタ**：このコントラクトには256未満の関数しかないため、1バイトで区別できます。 + これらのバイトは通常ゼロ以外であるため、[16ガスのコストがかかります](https://eips.ethereum.org/EIPS/eip-2028)。 +- **ゼロ**：20バイトのアドレスを保持するのに32バイトのワードは必要ないため、これらのバイトは常にゼロです。 + ゼロを保持するバイトのコストは4ガスです([イエローペーパー](https://ethereum.github.io/yellowpaper/paper.pdf)の付録G、 + 27ページの `G``txdatazero` の値参照)。 +- **金額**：このコントラクトで `decimals` が18 (通常値) であり、送金するトークンの最大量が1018であると仮定すると、最大量は1036になります。 + 25615 > 1036なので、15バイトで十分です。 -通常、L1上で160ガスを浪費するのは無視できる範囲です。 1件のトランザクションには最低でも[21,000ガス](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed)が必要であるため、追加の0.8%はほとんど問題になりません。 しかし、L2では問題になります。 L2におけるほぼすべてのコストは、L1への書き込みで発生します。 トランザクションのコールデータに加えて、トランザクションのヘッダー（送信先アドレス、署名など）で109バイトが必要になります。 従って、L2おける総コストは`109*16+576+160=2480`となり、浪費分が全体の6.5%に達するのです。 +L1上での160ガスの浪費は、通常は無視できます。 トランザクションには少なくとも[21,000ガス](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed)がかかるため、0.8%の追加は問題になりません。 +しかし、L2では事情が異なります。 トランザクションのコストのほぼ全体が、L1への書き込みによるものです。 +トランザクションのコールデータに加えて、109バイトのトランザクションヘッダー (送信先アドレス、署名など) があります。 +したがって、総コストは `109*16+576+160=2480` となり、その約6.5%を浪費していることになります。 -## 送信先を限定しない場合のコスト削減方法 {#reducing-costs-when-you-dont-control-the-destination} +## 送信先を制御できない場合のコスト削減 {#reducing-costs-when-you-dont-control-the-destination} -送信先のコントラクトを制御できない場合でも、[こちら](https://github.com/qbzzt/ethereum.org-20220330-shortABI)のようなソリューションを活用できます。 関連するファイルを確認しておきましょう。 +送信先コントラクトを制御できない場合でも、[こちら](https://github.com/qbzzt/ethereum.org-20220330-shortABI)のようなソリューションを利用できます。 +関連ファイルを見ていきましょう。 ### Token.sol {#token-sol} -[これ](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol)は、送信先のコントラクトです。 標準的なERC-20コントラクトですが、機能が1つ追加されています。 `faucet`関数により、すべてのユーザーがトークンを取得できるようになっています。 本番環境のERC-20コントラクトでは使えませんが、テスト環境では有益でしょう。 +[こちらが送信先コントラクトです](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol)。 +これは標準的なERC-20コントラクトですが、1つ機能が追加されています。 +この `faucet` 関数により、どのユーザーも使用するためのトークンを取得できます。 +これにより、本番のERC-20コントラクトは役に立たなくなりますが、ERC-20がテストを容易にするためだけに存在する場合、作業が楽になります。 ```solidity /** - * @dev Gives the caller 1000 tokens to play with + * @dev 呼び出し元に試用のための1000トークンを与えます */ function faucet() external { _mint(msg.sender, 1000); } // function faucet ``` -[こちら](https://kovan-optimistic.etherscan.io/address/0x950c753c0edbde44a74d3793db738a318e9c8ce8)で、このコントラクトのデプロイ実例を確認できます。 - ### CalldataInterpreter.sol {#calldatainterpreter-sol} -[これ](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol)は、より短いコールデータでトランザクションを呼び出すことが想定されているコントラクトです。 一行ずつ見ていきましょう。 +[これは、トランザクションがより短いコールデータで呼び出すことになっているコントラクトです](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol)。 +一行ずつ見ていきましょう。 ```solidity //SPDX-License-Identifier: Unlicense @@ -89,7 +110,7 @@ pragma solidity ^0.8.0; import { OrisUselessToken } from "./Token.sol"; ``` -呼び出し方法を知るには、トークン関数が必要です。 +それを呼び出す方法を知るには、トークン関数が必要です。 ```solidity contract CalldataInterpreter { @@ -100,10 +121,9 @@ contract CalldataInterpreter { 私たちがプロキシとなるトークンのアドレスです。 ```solidity - /** - * @dev Specify the token address - * @param tokenAddr_ ERC-20 contract address + * @dev トークンアドレスを指定します + * @param tokenAddr_ ERC-20コントラクトアドレス */ constructor( address tokenAddr_ @@ -131,7 +151,9 @@ contract CalldataInterpreter { "calldataVal trying to read beyond calldatasize"); ``` -32バイト（256ビット）を持つ1つのワードをメモリにロードして、必要なフィールドに含まれない部分のバイトを削除します。 このアルゴリズムは、32バイト以上の値に対しては機能せず、コールデータの末尾を越えたデータを読むこともできません。 L1では、ガスを節約するためにこれらのテストを省略すべきかもしれませんが、L2のガス代はとても安価なので、あらゆるサニティチェックを実行することができます。 +単一の32バイト (256ビット) ワードをメモリにロードし、目的のフィールドの一部でないバイトを削除します。 +このアルゴリズムは、32バイトより長い値には機能せず、もちろんコールデータの末尾を超えて読み取ることはできません。 +L1ではガスを節約するためにこれらのテストをスキップする必要があるかもしれませんが、L2ではガスが非常に安いため、考えられるあらゆるサニティチェックが可能です。 ```solidity assembly { @@ -139,16 +161,18 @@ contract CalldataInterpreter { } ``` -`fallback()`への呼び出しからデータをコピーしてもよいのですが（以下を参照） 、EVMのアセンブリ言語である[Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html)を使用する方が楽でしょう。 +`fallback()`への呼び出しからデータをコピーすることもできましたが (下記参照)、EVMのアセンブリ言語である[Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html)を使用する方が簡単です。 -ここでは、[CALLDATALOADのオペコード](https://www.evm.codes/#35)を使用して、`startByte`から `startByte+31`までのバイトをスタックへ読み込みます。 一般に、Yulのオペコードの構文は`(,...`となります。 +ここでは、[CALLDATALOADオペコード](https://www.evm.codes/#35)を使用して、`startByte`から`startByte+31`までのバイトをスタックに読み込みます。 +一般に、Yulでのオペコードの構文は`(,...)`です。 ```solidity _retVal = _retVal >> (256-length*8); ``` -このフィールドに含まれるのは最も重要な`length`のバイトだけなので、[右シフトクリック](https://en.wikipedia.org/wiki/Logical_shift)で他の値を削除します。 この方法は、値をフィールドの右側に移動するという追加の利点があるので、256xを掛けた値ではなく、値そのものになります。 +最上位の `length` バイトのみがフィールドの一部であるため、[右シフト](https://en.wikipedia.org/wiki/Logical_shift)して他の値を取り除きます。 +これには、値をフィールドの右側に移動させるという追加の利点があり、値自体が256somethingを掛けたものではなく、値そのものになります。 ```solidity @@ -159,7 +183,8 @@ contract CalldataInterpreter { fallback() external { ``` -Solidityコントラクトへの呼び出しがどの関数の署名とも一致しない場合、 [`fallback()`関数](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function)を呼び出します（存在する場合）。 `CalldataInterpreter`の場合、他の`external`または`public`の関数がないため、すべての呼び出しがここに到達します。 +Solidityコントラクトへの呼び出しがどの関数シグネチャとも一致しない場合、[`fallback()`関数](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function)を呼び出します (存在する場合)。 +`CalldataInterpreter`の場合、他の`external`や`public`関数がないため、_どんな_呼び出しもここに到達します。 ```solidity uint _func; @@ -167,23 +192,27 @@ Solidityコントラクトへの呼び出しがどの関数の署名とも一致 _func = calldataVal(0, 1); ``` -この関数を返すコールデータの最初の1バイトを読み取ります。 ここで関数が取得できないのには、2つの理由があります： +コールデータの最初のバイトを読み取ります。これにより関数がわかります。 +ここで関数が利用できない理由は2つあります。 -1. `pure`または`view`の関数の場合。これらの関数は状態を変更しないため、ガスが発生しません（オフチェーンで呼び出す場合）。 ですから、ガス代を節約する必要がありません。 -2. [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties)に依存した関数。 `msg.sender`の値は、呼び出し元のアドレスではなく、`CalldataInterpreter`のアドレスになります。 +1. `pure`または`view`の関数は状態を変更せず、ガス代もかかりません (オフチェーンで呼び出された場合)。 + これらのガス代を削減しようとしても意味がありません。 +2. [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties)に依存する関数。 + `msg.sender`の値は、呼び出し元ではなく`CalldataInterpreter`のアドレスになります。 -残念ながら、[ERC-20の仕様](https://eips.ethereum.org/EIPS/eip-20)を確認すると、残りの関数は`transfer`のみです。 つまり、呼び出し可能な関数は、`transfer` （`transferFrom`を呼び出す）と、`faucet` （呼び出し元のアドレスにトークンを送信する）になります。 +残念ながら、[ERC-20の仕様](https://eips.ethereum.org/EIPS/eip-20)を見ると、残っている関数は`transfer`のみです。 +これにより、残る関数は`transfer` (`transferFrom`を呼び出せるため)と`faucet` (`transferFrom`を呼び出せるため)の2つだけになります。 ```solidity - // Call the state changing methods of token using - // information from the calldata + // コールデータの情報を使用して + // トークンの状態変更メソッドを呼び出します // faucet if (_func == 1) { ``` -次は、パラメータを持たない`faucet()`を呼び出すコードです。 +パラメータのない`faucet()`の呼び出しです。 ```solidity token.faucet(); @@ -192,46 +221,49 @@ Solidityコントラクトへの呼び出しがどの関数の署名とも一致 } ``` -`token.faucet()`を呼び出すと、トークンを取得します。 しかし、プロキシのコントラクトにおいてトークンは**必要ありません**。 トークンが必要なのは、外部所有アカウント（EOA）あるいは呼び出し元のコントラクトです。 ですから、所有するトークンをすべて呼び出し元アドレスに送信します。 +`token.faucet()`を呼び出すと、トークンを取得します。 しかし、プロキシコントラクトとして、私たちはトークンを**必要**としません。 +私たちを呼び出したEOA (外部所有アカウント) やコントラクトは、それを必要とします。 +したがって、所有するすべてのトークンを、私たちを呼び出した誰にでも送金します。 ```solidity - // transfer (assume we have an allowance for it) + // transfer (そのためのアローワンスがあると仮定します) if (_func == 2) { ``` -トークンを送信する場合、送信先アドレスと金額という2つのパラメータが必要です。 +トークンを送金するには、送信先アドレスと金額の2つのパラメータが必要です。 ```solidity token.transferFrom( msg.sender, ``` -送信できるトークンは、呼び出し元が所有するトークンのみです。 +呼び出し元が所有するトークンの送金のみを許可します ```solidity address(uint160(calldataVal(1, 20))), ``` -送信先アドレスは、#1のバイトから始まります（#0のバイトは、関数が使用します）。 アドレスの長さは、20バイトです。 +送信先アドレスはバイト#1から始まります (バイト#0は関数です)。 +アドレスとして、その長さは20バイトです。 ```solidity calldataVal(21, 2) ``` -このコントラクトでは、送信可能なトークンの最大数が2バイト以内（65536未満）に収まると想定します。 +この特定のコントラクトでは、誰もが送金したいと思うトークンの最大数は2バイト (65536未満) に収まると想定します。 ```solidity ); } ``` -1件の送信につき、35バイトのコールデータが発生します。 +全体として、1回の送金には35バイトのコールデータが必要です。 | セクション | 長さ | バイト | -| ------- | --:| -----:| +| ------- | -: | ----: | | 関数セレクタ | 1 | 0 | -| 送信先アドレス | 32 | 1～32 | -| 金額 | 2 | 33～34 | +| 送信先アドレス | 32 | 1-32 | +| 金額 | 2 | 33-34 | ```solidity } // fallback @@ -241,7 +273,8 @@ Solidityコントラクトへの呼び出しがどの関数の署名とも一致 ### test.js {#test-js} -[このJavaScriptによる単体テスト](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js)では、このメカニズムを使用する方法（および、メカニズムが適切に動作していることをを確認する方法）を示します。 ここでは、[Chai](https://www.chaijs.com/)および[Ethers](https://docs.ethers.io/v5/)についてよく理解しているという前提に基づき、特にコントラクトに関連する部分のみを説明します。 +[このJavaScriptユニットテスト](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js)は、このメカニズムの使用方法 (およびそれが正しく機能することを確認する方法) を示しています。 +[chai](https://www.chaijs.com/)と[ethers](https://docs.ethers.io/v5/)を理解していることを前提とし、コントラクトに特に関連する部分のみを説明します。 ```js const { expect } = require("chai"); @@ -264,21 +297,24 @@ describe("CalldataInterpreter", function () { まず、両方のコントラクトをデプロイします。 ```javascript - // Get tokens to play with + // 試用のためのトークンを取得 const faucetTx = { ``` -ここではABIを使用しないため、トランザクションを作成するために通常用いる高度な関数（`token.faucet()`など）を使用できません。 その代わりに、トランザクションをマニュアルで作成し、送信する必要があります。 +通常使用する高レベルの関数 (例： `token.faucet()`) は、ABIに従っていないため、トランザクションの作成には使用できません。 +代わりに、自分でトランザクションを作成してから送信する必要があります。 ```javascript to: cdi.address, data: "0x01" ``` -トランザクションには、次の2つのパラメータが必要です： +トランザクションには、次の2つのパラメータが必要です。 -1. `to`：送信先のアドレスです。 これは、コールデータのインタープリタのアドレスです。 -2. `data`：送信するコールデータです。 フォーセットを呼び出す場合、データは1バイト（`0x01`）です。 +1. `to`、送信先アドレスです。 + これは、コールデータのインタープリタコントラクトです。 +2. `data`、送信するコールデータです。 + フォーセットを呼び出す場合、データは1バイトの`0x01`です。 ```javascript @@ -286,26 +322,27 @@ describe("CalldataInterpreter", function () { await (await signer.sendTransaction(faucetTx)).wait() ``` -すでに送信先（`faucetTx.to`）を指定しており、トランザクションに対して署名を得る必要があるため、[署名者の`sendTransaction`メソッド](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction)を呼び出します。 +送信先 (`faucetTx.to`) をすでに指定しており、トランザクションに署名が必要なため、[署名者の `sendTransaction` メソッド](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction)を呼び出します。 ```javascript -// Check the faucet provides the tokens correctly +// フォーセットがトークンを正しく提供することを確認 expect(await token.balanceOf(signer.address)).to.equal(1000) ``` -ここでは、残高を確認します。 `view`関数ではガスを節約する必要がないので、単純に実行します。 +ここで残高を確認します。 +`view`関数ではガスを節約する必要がないので、通常どおり実行します。 ```javascript -// Give the CDI an allowance (approvals cannot be proxied) +// CDIにアローワンスを与える (承認はプロキシできません) const approveTX = await token.approve(cdi.address, 10000) await approveTX.wait() expect(await token.allowance(signer.address, cdi.address)).to.equal(10000) ``` -コールデータのインタープリタが送信できるように、アローワンスを設定します。 +コールデータのインタープリタに送金できるようにアローワンスを与えます。 ```javascript -// Transfer tokens +// トークンを送金 const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d" const transferTx = { to: cdi.address, @@ -313,53 +350,50 @@ const transferTx = { } ``` -送信トランザクションを作成します。 最初のバイトは「0x02」で、次に送信先アドレスを置き、最後に金額（10進法で256である0x0100）を置きます。 +送金トランザクションを作成します。 最初のバイトは「0x02」で、次に送信先アドレス、最後に金額 (0x0100、10進数で256) が続きます。 ```javascript await (await signer.sendTransaction(transferTx)).wait() - // Check that we have 256 tokens less + // 256トークン少なくなっていることを確認 expect (await token.balanceOf(signer.address)).to.equal(1000-256) - // And that our destination got them + // そして、送信先がそれらを受け取ったことを確認 expect (await token.balanceOf(destAddr)).to.equal(256) }) // it }) // describe ``` -### 例 {#example} - -これらのファイルにつき、自ら実行せず、どのように動作するのか確認したい場合は、以下のリンクにアクセスしてください： +## 送信先コントラクトを制御できる場合のコスト削減 {#reducing-the-cost-when-you-do-control-the-destination-contract} -1. アドレス[`0x950c753c0edbde44a74d3793db738a318e9c8ce8`](https://kovan-optimistic.etherscan.io/address/0x950c753c0edbde44a74d3793db738a318e9c8ce8)に対する[ `OrisUselessToken`](https://kovan-optimistic.etherscan.io/tx/1410744)のデプロイメント。 -2. アドレス[`0x16617fea670aefe3b9051096c0eb4aeb4b3a5f55`](https://kovan-optimistic.etherscan.io/address/0x16617fea670aefe3b9051096c0eb4aeb4b3a5f55)に対する[`CalldataInterpreter`](https://kovan-optimistic.etherscan.io/tx/1410745)のデプロイメント。 -3. [`faucet()`](https://kovan-optimistic.etherscan.io/tx/1410746)の呼び出し。 -4. [`OrisUselessToken.approve()`](https://kovan-optimistic.etherscan.io/tx/1410747)の呼び出し。 処理が`msg.sender`に依存しているため、この呼び出しは、直接トークンコントラクトで行う必要があります。 -5. [`transfer()`](https://kovan-optimistic.etherscan.io/tx/1410748)の呼び出し。 +送信先コントラクトを制御できる場合、コールデータのインタープリタを信頼するため、`msg.sender`チェックをバイパスする関数を作成できます。 +[`control-contract`ブランチで、これがどのように機能するかの例をこちらで確認できます](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract)。 -## 送信先コントラクトを制限する場合にコストを削減する方法 {#reducing-the-cost-when-you-do-control-the-destination-contract} - -送信先コントラクトを制限できる場合、コールデータのインタープリタが信頼されるため、`msg.sender`チェックを省略する関数を作成することができます。 [`control-contract`のブランチから、動作例を確認できます](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract)。 - -コントラクトが外部のトランザクションのみに応答する場合、1つのコントラクトのみで対応することができます。 しかし、この方法では[コンポーザビリティ](/developers/docs/smart-contracts/composability/)が失われます。 通常のERC-20の呼び出しに応答するコントラクトと、短いコールデータを持つトランザクションに応答するコントラクトを共に用意する方が優れた方法だと言えます。 +コントラクトが外部トランザクションにのみ応答する場合、1つのコントラクトだけで済みます。 +しかし、それでは[構成可能性](/developers/docs/smart-contracts/composability/)が損なわれます。 +通常のERC-20の呼び出しに応答するコントラクトと、短いコールデータを持つトランザクションに応答する別のコントラクトを持つ方がはるかに優れています。 ### Token.sol {#token-sol-2} -この例では、`Token.sol`を修正します。 これにより、このプロキシだけが呼び出せる一連の関数を設定することができます。 以下は、追加の関数です： +この例では、`Token.sol`を修正できます。 +これにより、プロキシだけが呼び出せる多数の関数を持つことができます。 +新しい部分は次のとおりです。 ```solidity - // The only address allowed to specify the CalldataInterpreter address + // CalldataInterpreterアドレスを指定できる唯一のアドレス address owner; - // The CalldataInterpreter address + // CalldataInterpreterアドレス address proxy = address(0); ``` -ERC-20コントラクトは、許可されたプロキシの身元を知る必要があります。 しかし、この時点では値が不明なため、コンストラクタで変数を設定できません。 プロキシは、コンストラクタにおいてトークンのアドレスを要求するため、まずこのコントラクトのインスタンスが実行されます。 +ERC-20コントラクトは、承認されたプロキシのIDを知る必要があります。 +しかし、まだ値がわからないため、コンストラクタでこの変数を設定することはできません。 +このコントラクトは、プロキシがコンストラクタでトークンのアドレスを期待するため、最初にインスタンス化されます。 ```solidity /** - * @dev Calls the ERC20 constructor. + * @dev ERC20コンストラクタを呼び出します。 */ constructor( ) ERC20("Oris useless token-2", "OUT-2") { @@ -367,12 +401,12 @@ ERC-20コントラクトは、許可されたプロキシの身元を知る必 } ``` -作成者（`オーナー`と呼ぶ）のアドレスは、プロキシを設定することが許可された唯一のアドレスであるため、ここに保存されます。 +作成者 (「owner」と呼ばれる) のアドレスは、プロキシを設定できる唯一のアドレスであるため、ここに保存されます。 ```solidity /** - * @dev set the address for the proxy (the CalldataInterpreter). - * Can only be called once by the owner + * @dev プロキシ (CalldataInterpreter) のアドレスを設定します。 + * オーナーが1回だけ呼び出し可能 */ function setProxy(address _proxy) external { require(msg.sender == owner, "Can only be called by owner"); @@ -382,32 +416,35 @@ ERC-20コントラクトは、許可されたプロキシの身元を知る必 } // function setProxy ``` -プロキシは特権アクセスを持つため、セキュリティチェックが省略されます。 このプロキシが信頼できることを確認するには、`オーナー`に対し、1回のみこの関数を呼び出すことを許可します。 `proxy`が （ゼロではない）実際の値を持つと同時に、この値は変更不可となるため、オーナーが悪意のユーザーになった場合やそのニーモニックが明らかになった場合でも、安全性が維持されます。 +プロキシはセキュリティチェックをバイパスできるため、特権アクセスを持ちます。 +プロキシを信頼できることを確認するために、`owner`だけがこの関数を1回だけ呼び出せるようにします。 +一度 `proxy` が実際の値 (ゼロではない) を持つと、その値は変更できないため、オーナーが悪意を持ったり、そのニーモニックが漏洩したりしても、安全です。 ```solidity /** - * @dev Some functions may only be called by the proxy. + * @dev 一部の関数はプロキシによってのみ呼び出し可能です。 */ modifier onlyProxy { ``` -これは、他の関数の動作を修正する[`modifier`関数](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm)です。 +これは[`modifier`関数](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm)であり、他の関数の動作を変更します。 ```solidity require(msg.sender == proxy); ``` -まず、呼び出し元がプロキシであり、その他のユーザーではないことを確認します。 プロキシ以外から呼び出された場合は、 `revert`します。 +まず、プロキシによって呼び出され、他の誰にも呼び出されていないことを確認します。 +そうでなければ、`revert`します。 ```solidity _; } ``` -プロキシからの呼び出しであれば、修正する関数を実行します。 +もしそうなら、修正する関数を実行します。 ```solidity - /* Functions that allow the proxy to actually proxy for accounts */ + /* プロキシが実際にアカウントのプロキシとして機能できるようにする関数 */ function transferProxy(address from, address to, uint256 amount) public virtual onlyProxy() returns (bool) @@ -436,17 +473,18 @@ ERC-20コントラクトは、許可されたプロキシの身元を知る必 } ``` -以下は、トークンを送信する／アローワンスを承認するエンティティから直接メッセージを受信する際に通常必要となる3つの操作です。 ここでは、以下の特徴を持つプロキシバージョンを使います： +これらは通常、トークンを送金したり、アローワンスを承認したりするエンティティから直接メッセージが送信される必要がある3つの操作です。 +ここでは、これらの操作のプロキシバージョンがあります。 -1. `onlyProxy()`で修正されており、他のユーザーが管理権限を持たない。 -2. 追加のパラメータとして、通常`msg.sender`であるアドレスを取得する。 +1. `onlyProxy()`によって変更されているため、他の誰もそれらを制御することはできません。 +2. 通常`msg.sender`であるアドレスを、追加パラメータとして取得します。 ### CalldataInterpreter.sol {#calldatainterpreter-sol-2} -コールデータのインタープリタは、送信先を限定しない場合とほぼ同一ですが、プロキシの関数では`msg.sender`パラメータを受け取るため、`transfer`のアローワンスが必要ない点が異なります。 +コールデータのインタープリタは、プロキシされた関数が`msg.sender`パラメータを受け取り、`transfer`にアローワンスが不要である点を除いて、上記のインタープリタとほぼ同じです。 ```solidity - // transfer (no need for allowance) + // transfer (アローワンスは不要) if (_func == 2) { token.transferProxy( msg.sender, @@ -477,7 +515,7 @@ ERC-20コントラクトは、許可されたプロキシの身元を知る必 ### Test.js {#test-js-2} -送信先を限定しない場合とは、いくつかの点が異なります。 +以前のテストコードとこのコードにはいくつかの変更点があります。 ```js const Cdi = await ethers.getContractFactory("CalldataInterpreter") @@ -486,21 +524,22 @@ await cdi.deployed() await token.setProxy(cdi.address) ``` -ERC-20コントラクトに対し、どのプロキシを信頼するかを伝える必要があります。 +ERC-20コントラクトに、どのプロキシを信頼するかを伝える必要があります。 ```js console.log("CalldataInterpreter addr:", cdi.address) -// Need two signers to verify allowances +// アローワンスを確認するには2つの署名者が必要 const signers = await ethers.getSigners() const signer = signers[0] const poorSigner = signers[1] ``` -`approve()`と`transferFrom()`を確認するには、第2の署名者が必要です。 第2の署名者は、トークンを受け取らないため（もちろん、ETHを所有する必要はあります）に`poorSigner`と呼びます。 +`approve()`と`transferFrom()`を確認するには、2人目の署名者が必要です。 +これは私たちのトークンを一切受け取らないため、`poorSigner`と呼びます (もちろん、ETHは持っている必要があります)。 ```js -// Transfer tokens +// トークンを送金 const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d" const transferTx = { to: cdi.address, @@ -509,10 +548,10 @@ const transferTx = { await (await signer.sendTransaction(transferTx)).wait() ``` -ERC-20コントラクトは、プロキシ (`cdi`) を信頼するため、送信をリレーするためのアローワンスは必要ありません。 +ERC-20コントラクトはプロキシ (`cdi`) を信頼するため、送金を中継するためのアローワンスは必要ありません。 ```js -// approval and transferFrom +// 承認とtransferFrom const approveTx = { to: cdi.address, data: "0x03" + poorSigner.address.slice(2, 42) + "00FF", @@ -527,28 +566,19 @@ const transferFromTx = { } await (await poorSigner.sendTransaction(transferFromTx)).wait() -// Check the approve / transferFrom combo was done correctly +// approve / transferFrom の組み合わせが正しく行われたことを確認 expect(await token.balanceOf(destAddr2)).to.equal(255) - -No key -Text -XPath: /pre[38]/code ``` -新たに追加した2つの関数をテストします。 `transferFromTx`のアドレスには、アローワンスの提供元と受領者という2つパラメータが要求される点に注意してください。 - -### 実例 {#example-2} +2つの新しい関数をテストします。 +`transferFromTx`には、アローワンスの提供者と受領者の2つのアドレスパラメータが必要であることに注意してください。 -これらのファイルにつき、自ら実行せず、どのように動作するのか確認したい場合は、以下のリンクにアクセスしてください： +## 結論 {#conclusion} -1. [`0xb47c1f550d8af70b339970c673bbdb2594011696`](https://kovan-optimistic.etherscan.io/address/0xb47c1f550d8af70b339970c673bbdb2594011696)のアドレスに対する[`OrisUselessToken-2`のデプロイメント](https://kovan-optimistic.etherscan.io/tx/1475397)。 -2. [`0x0dccfd03e3aaba2f8c4ea4008487fd0380815892`](https://kovan-optimistic.etherscan.io/address/0x0dccfd03e3aaba2f8c4ea4008487fd0380815892)のアドレスに対する[ `CalldataInterpreter`のデプロイメント](https://kovan-optimistic.etherscan.io/tx/1475400)。 -3. [`setProxy()`の呼び出し](https://kovan-optimistic.etherscan.io/tx/1475402)。 -4. [`faucet()`の呼び出し](https://kovan-optimistic.etherscan.io/tx/1475409)。 -5. [`transferProxy()`の呼び出し](https://kovan-optimistic.etherscan.io/tx/1475416)。 -6. [`approveProxy()`の呼び出し](https://kovan-optimistic.etherscan.io/tx/1475419)。 -7. [`transferFromProxy()`の呼び出し](https://kovan-optimistic.etherscan.io/tx/1475421)。 この呼び出しは、他のアドレスとは異なるアドレスからのものであることに注意してください (`signer`の代わりに`poorSigner`) 。 +[Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92)と[Arbitrum](https://developer.offchainlabs.com/docs/special_features)はどちらも、L1に書き込まれるコールデータのサイズ、ひいてはトランザクションのコストを削減する方法を模索しています。 +しかし、汎用的なソリューションを探しているインフラプロバイダーとして、私たちの能力には限界があります。 +dapp開発者であるあなたは、アプリケーション固有の知識を持っているため、汎用的なソリューションよりもはるかに優れた方法でコールデータを最適化できます。 +この記事が、あなたのニーズに合った理想的なソリューションを見つけるのに役立つことを願っています。 -## まとめ {#conclusion} +[私の他の作品はこちらでご覧いただけます](https://cryptodocguy.pro/). -[Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92)と[Arbitrum](https://developer.offchainlabs.com/docs/special_features)はどちらも、L1に書き込まれるコールデータのサイズを削減し、トランザクションコストを抑える方法を提供することを目指しています。 インフラプロバイダーが汎用性が高いソリューションを追求する一方で、デベロッパの能力には限界があります。 Dappのデベロッパーは、開発するアプリケーションについて具体的な知識を持つため、汎用性のソリューションよりも効率的にコールデータの最適化を実現できるのです。 この記事が、皆さんのニーズに合わせた理想的なソリューションを見出す上で役立つことを願っています。 diff --git a/public/content/translations/ja/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/ja/developers/tutorials/smart-contract-security-guidelines/index.md index 81636f3cf98..9f8ae3bbe94 100644 --- a/public/content/translations/ja/developers/tutorials/smart-contract-security-guidelines/index.md +++ b/public/content/translations/ja/developers/tutorials/smart-contract-security-guidelines/index.md @@ -1,15 +1,12 @@ --- -title: スマートコントラクトに対するセキュリティ・ガイドライン -description: Dapp開発時に参照すべきセキュリティ・ガイドラインのチェックリスト +title: "スマートコントラクトに対するセキュリティ・ガイドライン" +description: "Dapp開発時に参照すべきセキュリティ・ガイドラインのチェックリスト" author: "Trailofbits" -tags: - - "Solidity" - - "スマートコントラクト" - - "セキュリティ" +tags: [ "Solidity", "スマートコントラクト", "セキュリティ" ] skill: intermediate lang: ja published: 2020-09-06 -source: セキュアなコントラクトの構築 +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md --- @@ -19,76 +16,76 @@ sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/devel まず、コードを書く前に、コントラクトの設計について十分に議論を深める必要があります。 -### ドキュメンテーションおよび使用 {#documentation-and-specifications} +### ドキュメントと仕様 {#documentation-and-specifications} ドキュメンテーションは様々な水準で作成でき、コントラクトの実装時に内容を修正する必要があります。 -- **平易な英語で書かれたシステムの説明**では、コントラクトが実行する内容を説明し、コードベースの前提条件を記述します。 -- **スキーマとアーキテクチャのダイアグラム**では、コントラクトで実行されるやりとりや、システムの状態マシンについて記述します。 [Slitherのプリンター機能](https://github.com/crytic/slither/wiki/Printer-documentation)は、スキーマを生成する上で有益です。 -- **コード内容を徹底的に文書化する。** Solidityの場合、[Natspecフォーマット](https://solidity.readthedocs.io/en/develop/natspec-format.html)を使用できます。 +- **システムの平易な英語による説明**。コントラクトが何を行い、コードベースにどのような前提条件があるかを記述します。 +- **スキーマとアーキテクチャ図**。コントラクト間の相互作用やシステムの状態マシンを含みます。 [Slitherプリンター](https://github.com/crytic/slither/wiki/Printer-documentation)は、これらのスキーマの生成に役立ちます。 +- **徹底的なコードドキュメント**。Solidityでは[Natspec形式](https://docs.soliditylang.org/en/develop/natspec-format.html)が使用できます。 -### オンチェーン処理とオフチェーン処理の比較 {#on-chain-vs-off-chain-computation} +### オンチェーン計算とオフチェーン計算 {#onchain-vs-offchain-computation} -- **できるだけ多くのコードを、オフチェーンで処理するようにします。**オンチェーンのレイヤーに含まれるコードは、小規模になるようにしてください。 オンチェーンでの検証がシンプルに実行できるように、オフチェーンのコードでデータを前処理します。 順序付きリストが必要か確認します。 必要な場合は、オフチェーンでリストをソートしてから、オンチェーンでは順序のみをチェックするようにします。 +- **できるだけ多くのコードをオフチェーンに置いてください。**オンチェーンレイヤーは小さく保ちます。 オンチェーンでの検証がシンプルになるように、オフチェーンのコードでデータを前処理します。 順序付きリストが必要か確認します。 必要な場合は、オフチェーンでリストをソートしてから、オンチェーンでは順序のみをチェックするようにします。 ### アップグレード可能性 {#upgradeability} -アップグレードに関する様々なソリューションについては、[こちらのブログ投稿](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)で検討しています。 コード開発を開始する事前に、アップグレードに対応するか否かをはっきり決定してください。 この決定により、どのような構造のコードを開発するべきかが変わってきます。 一般論として、以下を推奨します： +[私たちのブログ投稿](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/)で、さまざまなアップグレード可能性のソリューションについて説明しました。 コード開発を開始する事前に、アップグレードに対応するか否かをはっきり決定してください。 この決定により、どのような構造のコードを開発するべきかが変わってきます。 一般論として、以下を推奨します： -- **アップグレード可能性よりも、[コントラクトのマイグレーション](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)を優先すること**。システムのマイグレーションは、アップグレード可能性が提供する利点の多くを有し、アップグレード可能性の欠点がありません。 -- **委任呼び出しプロキシのパターンよりも、データ分離のパターンを使用すること**。あなたのプロジェクトに明確な抽象化による分離が含まれる場合、データ分離をわずかに修正するだけでアップグレードが可能になります。 委任呼び出しのプロキシ は、EVMの知識が必要であり、エラー発生の頻度が高まります。 -- **デプロイする前に、マイグレーション／アップグレードの手順を文書化すること**。ガイドラインが設定されていない場合、ストレスを受けながら作業する必要があるため、ミスを犯しやすくなります。 遵守すべき手順を前もって策定しておきましょう。 具体的には、以下を定めます： +- **アップグレード可能性よりも[コントラクトのマイグレーション](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)を優先すること。**マイグレーションシステムはアップグレード可能なシステムと同じ利点の多くを持ちながら、その欠点はありません。 +- **delegatecallproxyパターンよりもデータ分離パターンを使用すること。** プロジェクトに明確な抽象化分離がある場合、データ分離を使用したアップグレードは、わずかな調整しか必要ありません。 委任呼び出しのプロキシ は、EVMの知識が必要であり、エラー発生の頻度が高まります。 +- **デプロイ前に、移行/アップグレードの手順を文書化すること。** ガイドラインがない状態でストレス下で対応しなければならない場合、ミスを犯すでしょう。 遵守すべき手順を前もって策定しておきましょう。 具体的には、以下を定めます： - 新たなコントラクトを開始する呼び出し。 - キーの保存場所と、アクセス方法。 - デプロイの確認方法。 デプロイ後のスクリプトを開発、テストしておきます。 -## 実装に関するガイドライン {#implementation-guidelines} +## 実装ガイドライン {#implementation-guidelines} -**シンプルさを追求する**。常に、目的を達成する上で最もシンプルなソリューションを使用してください。 あなたのソリューションは、チーム全員が理解できるものでなければなりません。 +**シンプルさを追求すること。**常に目的に合った最もシンプルなソリューションを使用してください。 あなたのソリューションは、チーム全員が理解できるものでなければなりません。 ### 関数の構成 {#function-composition} コードベースのアーキテクチャは、レビューしやすいものでなければなりません。 コードの正確性を判定しにくくするようなアーキテクチャ関連の決定は避けてください。 -- **システムのロジックを分割する**。複数のコントラクトに分割するか、類似の関数（認証、算術塩酸など）をグループ化しましょう。 -- **明確な目的を持つ小規模の関数を書く**。レビュー作業が容易になり、コンポーネントごとのテストが可能になります。 +- **システムのロジックを分割すること。**複数のコントラクトに分けるか、類似した関数(例: 認証、算術演算など)をグループ化します。 +- **明確な目的を持つ小さな関数を書くこと。** これにより、レビューが容易になり、個々のコンポーネントのテストが可能になります。 ### 継承 {#inheritance} -- **継承を管理可能な水準に抑える**。ロジックを分割するために継承を活用すべきですが、プロジェクト全体における継承ツリーの深さと広さをなるべく小さくするように努めてください。 -- **Slitherの[継承プリンター](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph)でコントラクトの階層を確認する**。継承プリンターは、階層の規模を確認する上で役立ちます。 +- **継承を管理可能なものに保つこと。**継承はロジックを分割するために使用すべきですが、プロジェクトでは継承ツリーの深さと幅を最小限に抑えることを目指すべきです。 +- **Slitherの[継承プリンター](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph)を使用してコントラクトの階層を確認してください。** 継承プリンターは、階層のサイズを確認するのに役立ちます。 ### イベント {#events} -- **すべての重要操作をロギングする**。イベントログは、開発時におけるコントラクトのデバッグやデプロイ後の監視に役立ちます。 +- **すべての重要な操作をログに記録してください。** イベントは、開発中のコントラクトのデバッグやデプロイ後の監視に役立ちます。 -### 既知の落とし穴を回避する {#avoid-known-pitfalls} +### 既知の落とし穴を避ける {#avoid-known-pitfalls} -- **最も一般的なセキュリティの問題に注意します**。よくある問題点については、[Ethernaut CTF](https://ethernaut.openzeppelin.com/)、[Capture the Ether](https://capturetheether.com/)、[Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/)などの様々なオンラインリソースを活用してください。 -- **[Solidityドキュメント](https://solidity.readthedocs.io/en/latest/)の警告セクションに注意する**。警告セクションを通じて、言語における把握しにくい振る舞いを把握することができます。 +- **最も一般的なセキュリティ問題に注意してください。** [Ethernaut CTF](https://ethernaut.openzeppelin.com/)、[Capture the Ether](https://capturetheether.com/)、[Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/)など、一般的な問題について学ぶためのオンラインリソースはたくさんあります。 +- **[Solidityドキュメント](https://docs.soliditylang.org/en/latest/)の警告セクションに注意してください。** 警告セクションは、言語の自明でない挙動について知らせてくれます。 ### 依存関係 {#dependencies} -- **実証済みのライブラリを使用する**。実証済みのライブラリからコードをインポートすることで、バグが多いコードを書く可能性が低くなります。 ERC-20コントラクトを作成する場合は、 [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20)を使用してください。 -- **依存性マネージャーを使用し、コードのコピーアンドペーストを避ける**。外部ソースに依存する場合は、元ソースに基づき最新状態を保つ必要があります。 +- **十分にテストされたライブラリを使用すること。** 十分にテストされたライブラリからコードをインポートすることで、バグの多いコードを書く可能性が低くなります。 ERC20コントラクトを書きたい場合は、[OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20)を使用してください。 +- **依存関係マネージャーを使用し、コードのコピー＆ペーストは避けてください。** 外部ソースに依存する場合は、元のソースに合わせて最新の状態に保つ必要があります。 ### テストと検証 {#testing-and-verification} -- **完全な単体テストを作成する**。質の高いソフトウェアを開発するには、包括的なテスト一式が不可欠です。 -- **[Slither](https://github.com/crytic/slither)、[Echidna](https://github.com/crytic/echidna)、および[Manticore](https://github.com/trailofbits/manticore)用のカスタムチェックとプロパティを作成する**。自動化ツールを通じて、コントラクトのセキュリティを高めることができます。 効率的なチェックおよびプロパティを作成するには、本ガイドの該当記事を参照してください。 -- **[crytic.io](https://crytic.io/)を使用する**。Cryticは、GitHubと統合されており、Slitherのプライベート検出器にアクセスできる他、Echidnaからカスタムのプロパティチェックを実行することができます。 +- **徹底的な単体テストを書くこと。** 広範なテストスイートは、高品質なソフトウェアを構築するために不可欠です。 +- **[Slither](https://github.com/crytic/slither)、[Echidna](https://github.com/crytic/echidna)、[Manticore](https://github.com/trailofbits/manticore)のカスタムチェックとプロパティを記述すること。** 自動化ツールは、コントラクトの安全性を確保するのに役立ちます。 効率的なチェックおよびプロパティを作成するには、本ガイドの該当記事を参照してください。 +- **[crytic.io](https://crytic.io/)を使用してください。**CryticはGitHubと統合されており、プライベートなSlither検出器へのアクセスを提供し、Echidnaからカスタムプロパティチェックを実行します。 ### Solidity {#solidity} -- **Solidityのバージョンは、0.4や0.6ではなく0.5を使用する**。現在のところ、Solidity 0.5が最もセキュアなバージョンであり、0.4よりもビルトインプラクティスが優れています。 一方、0.6は現時点において本番環境の使用に耐えうる安定性を持たず、さらなるアップデートが必要な状態です。 -- **安定したバージョンでコンパイルし、最新リリースで警告をチェックする。**最新バージョンのコンパイラを使って、コードの問題が報告されないことを確認してください。 ただし、Solidityはリリース間隔が短く、過去においてもコンパイラにバグが含まれていた場合が多いため、デプロイに最新バージョンを用いることは推奨しません（Slitherの[推奨solcバージョン](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33)を参照）。 -- **インラインアセンブラを使用しない**。アセンブラを使用するには、EVMの専門知識が必要です。 イエローペーパーを_マスターしていない場合_、EVMコードを書かないでください。 +- **Solidityは0.4や0.6よりも0.5を優先すること。** 私たちの意見では、Solidity 0.5は0.4よりも安全で、より優れた組み込みプラクティスを備えています。 一方、0.6は現時点において本番環境の使用に耐えうる安定性を持たず、さらなるアップデートが必要な状態です。 +- **コンパイルには安定版リリースを使用し、警告のチェックには最新リリースを使用すること。** 最新のコンパイラバージョンでコードに問題が報告されないことを確認してください。 しかし、Solidityはリリースサイクルが速く、コンパイラのバグの履歴があるため、デプロイに最新バージョンを使用することはお勧めしません（Slitherの[solcバージョン推奨](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33)を参照）。 +- **インラインアセンブリは使用しないこと。** アセンブリにはEVMの専門知識が必要です。 イエローペーパーを_マスター_していない場合は、EVMコードを書かないでください。 -## デプロイに関するガイドライン {#deployment-guidelines} +## デプロイガイドライン {#deployment-guidelines} コントラクトの開発が完了し、デプロイしたら、以下を確認します： -- **コントラクトの動作を監視する**。ログを監視し、コントラクトやウォレットが不正利用された場合はただちに対応できる状態を保ってください。 -- **あなたの連絡先情報を[blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts)に追加する**。このリストに登録することで、プロジェクトにおけるセキュリティ上の欠陥が発見された場合に、サードパーティから連絡を受けやすくなります。 -- **特権ユーザーのウォレットを保護する**。キーをハードウェアウォレットに保管する場合は、この[ベストプラクティス](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/)に従ってください。 -- **事故対応計画を策定する**。スマートコントラクトは、不正利用される可能性があります。 開発したコントラクトにバグが含まれていない場合でも、攻撃者はコントラクト所有者の鍵を悪用しようとする可能性があります。 +- **コントラクトを監視してください。** ログを監視し、コントラクトやウォレットが不正利用された場合に備えて、対応できるようにしておきましょう。 +- **連絡先情報を[blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts)に追加してください。** このリストは、セキュリティ上の欠陥が発見された場合に第三者があなたに連絡するのに役立ちます。 +- **権限のあるユーザーのウォレットを保護すること。** ハードウェアウォレットにキーを保管する場合は、[私たちのベストプラクティス](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/)に従ってください。 +- **インシデント対応計画を準備しておくこと。** スマートコントラクトが侵害される可能性があることを考慮してください。 開発したコントラクトにバグが含まれていない場合でも、攻撃者はコントラクト所有者の鍵を悪用しようとする可能性があります。 diff --git a/public/content/translations/ja/developers/tutorials/stealth-addr/index.md b/public/content/translations/ja/developers/tutorials/stealth-addr/index.md new file mode 100644 index 00000000000..921742bd41d --- /dev/null +++ b/public/content/translations/ja/developers/tutorials/stealth-addr/index.md @@ -0,0 +1,436 @@ +--- +title: "ステルスアドレスの使用" +description: "ステルスアドレスを使用すると、ユーザーは匿名で資産を送金できます。 この記事を読むと、ステルスアドレスとは何か、またその仕組みを説明し、匿名性を保つ方法でステルスアドレスを使用する方法を理解し、ステルスアドレスを使用するウェブベースのアプリケーションを作成できるようになります。" +author: Ori Pomerantz +tags: [ "ステルスアドレス", "プライバシー", "暗号技術", "Rust", "wasm" ] +skill: intermediate +published: 2025-11-30 +lang: ja +sidebarDepth: 3 +--- + +あなたはBillです。 理由は省きますが、あなたは「世界女王アリス」キャンペーンに寄付をして、アリスに寄付したことを知らせ、彼女が勝った場合に報酬を得たいと考えています。 残念ながら、彼女の勝利は保証されていません。 「太陽系女帝キャロル」という競合キャンペーンがあります。 もしキャロルが勝ち、あなたがアリスに寄付したことを彼女が知ったら、あなたは面倒なことになります。 そのため、自分のアカウントからアリスのアカウントに200 ETHを単純に送金することはできません。 + +[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564)がその解決策です。 このERCは、匿名での送金に[ステルスアドレス](https://nerolation.github.io/stealth-utils)を使用する方法を説明しています。 + +**警告**: ステルスアドレスの背後にある暗号技術は、私たちが知る限り、健全です。 しかし、潜在的なサイドチャネル攻撃が存在します。 [以下](#go-wrong)では、このリスクを軽減するために何ができるかを見ていきます。 + +## ステルスアドレスの仕組み {#how} + +この記事では、ステルスアドレスを2つの方法で説明します。 1つ目は[その使用方法](#how-use)です。 この記事の残りの部分を理解するには、このパートで十分です。 次に、[その背後にある数学的な説明](#how-math)があります。 暗号技術に興味がある場合は、この部分もお読みください。 + +### 簡易版 (ステルスアドレスの使い方) {#how-use} + +アリスは2つの秘密鍵を作成し、対応する公開鍵を公開します (これらを組み合わせて単一の倍長のメタアドレスにすることができます)。 ビルも秘密鍵を作成し、対応する公開鍵を公開します。 + +一方の当事者の公開鍵と他方の秘密鍵を使用することで、アリスとビルだけが知っている共有シークレットを導き出すことができます (公開鍵だけからは導き出すことはできません)。 この共有シークレットを使用して、ビルはステルスアドレスを取得し、そこに資産を送ることができます。 + +アリスも共有シークレットからアドレスを取得しますが、公開した公開鍵の秘密鍵を知っているため、そのアドレスから引き出すことができる秘密鍵も取得できます。 + +### 数学的な仕組み (なぜステルスアドレスがこのように機能するのか) {#how-math} + +標準的なステルスアドレスでは、[楕円曲線暗号 (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor) を使用して、より少ない鍵ビットでより優れたパフォーマンスを得ながら、同じレベルのセキュリティを維持します。 しかし、ほとんどの場合、それを無視して通常の算術を使用していると見なすことができます。 + +誰もが知っている数字、_G_ があります。 _G_ を掛けることができます。 しかし、ECCの性質上、_G_ で割ることは事実上不可能です。 イーサリアムにおける公開鍵暗号技術の一般的な仕組みは、秘密鍵 _Ppriv_ を使用してトランザクションに署名し、それが公開鍵 _Ppub = GPpriv_ によって検証されるというものです。 + +アリスは2つの秘密鍵、_Kpriv_ と _Vpriv_ を作成します。 _Kpriv_ はステルスアドレスから資金を使用するために、_Vpriv_ はアリスに属するアドレスを表示するために使用されます。 アリスは次に公開鍵 _Kpub = GKpriv_ と _Vpub = GVpriv_ を公開します。 + +ビルは3番目の秘密鍵 _Rpriv_ を作成し、_Rpub = GRpriv_ を中央レジストリに公開します (ビルはアリスに送ることもできましたが、ここではキャロルが聞き耳を立てていると仮定します)。 + +ビルは _RprivVpub = GRprivVpriv_ を計算し、アリスもこれを知っていると期待します (下記で説明)。 この値は _S_ (共有シークレット) と呼ばれます。 これにより、ビルは公開鍵 _Ppub = Kpub+G\*hash(S)_ を得ます。 この公開鍵から、彼はアドレスを計算し、好きなリソースをそこに送ることができます。 将来、アリスが勝った場合、ビルは彼女に _Rpriv_ を伝えて、リソースが自分からのものであることを証明できます。 + +アリスは _RpubVpriv = GRprivVpriv_ を計算します。 これにより、彼女も同じ共有シークレット _S_ を得ます。 彼女は秘密鍵 _Kpriv_ を知っているので、_Ppriv = Kpriv+hash(S)_ を計算できます。 この鍵により、彼女は _Ppub = GPpriv = GKpriv+G\*hash(S) = Kpub+G\*hash(S)_ から得られるアドレスの資産にアクセスできます。 + +アリスがDaveの「世界征服キャンペーンサービス」に業務を委託できるように、別の閲覧用鍵があります。 アリスは、デイブに公開アドレスを知らせて、より多くの資金が利用可能になったときに通知してもらうことには前向きですが、デイブにキャンペーン資金を使われることは望んでいません。 + +閲覧と使用は別の鍵を使うため、アリスはデイブに _Vpriv_ を渡すことができます。 するとデイブは _S = RpubVpriv = GRprivVpriv_ を計算でき、それによって公開鍵 (_Ppub = Kpub+G\*hash(S)_) を得ることができます。 しかし、_Kpriv_ がなければ、デイブは秘密鍵を取得できません。 + +まとめると、これらが異なる参加者によって知られている値です。 + +| アリス | 公開済み | ビル | デイブ | | +| ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------- | +| G | G | G | G | | +| _Kpriv_ | - | - | - | | +| _Vpriv_ | - | - | _Vpriv_ | | +| _Kpub = GKpriv_ | _Kpub_ | _Kpub_ | _Kpub_ | | +| _Vpub = GVpriv_ | _Vpub_ | _Vpub_ | _Vpub_ | | +| - | - | _Rpriv_ | - | | +| _Rpub_ | _Rpub_ | _Rpub = GRpriv_ | _Rpub_ | | +| _S = RpubVpriv = GRprivVpriv_ | - | _S = RprivVpub = GRprivVpriv_ | _S = _RpubVpriv_ = GRprivVpriv_ | | +| _Ppub = Kpub+G\*hash(S)_ | - | _Ppub = Kpub+G\*hash(S)_ | _Ppub = Kpub+G\*hash(S)_ | | +| _Address=f(Ppub)_ | - | _Address=f(Ppub)_ | _Address=f(Ppub)_ | _Address=f(Ppub)_ | +| _Ppriv = Kpriv+hash(S)_ | - | - | - | | + +## ステルスアドレスがうまくいかない場合 {#go-wrong} + +_ブロックチェーン上に秘密はありません_。 ステルスアドレスはプライバシーを提供できますが、そのプライバシーはトラフィック分析に対して脆弱です。 簡単な例を挙げると、ビルがあるアドレスに資金を供給し、すぐにトランザクションを送信して _Rpub_ 値を公開するとします。 アリスの _Vpriv_ がなければ、これがステルスアドレスであると確信することはできませんが、そうである可能性が高いです。 次に、そのアドレスからアリスのキャンペーン資金アドレスにすべてのETHを送金する別のトランザクションが見られます。 証明はできないかもしれませんが、ビルがアリスのキャンペーンに寄付した可能性が高いです。 キャロルは間違いなくそう思うでしょう。 + +ビルにとって、_Rpub_ の公開とステルスアドレスへの資金供給を分離することは簡単です (異なる時間に、異なるアドレスから行います)。 しかし、それだけでは不十分です。 キャロルが探すパターンは、ビルがあるアドレスに資金を提供し、その後アリスのキャンペーン資金がそこから引き出すというものです。 + +1つの解決策は、アリスのキャンペーンが直接資金を引き出すのではなく、第三者への支払いに使用することです。 アリスのキャンペーンがデイブの世界征服キャンペーンサービスに10 ETHを送金した場合、キャロルはビルがデイブの顧客の1人に寄付したことしか知りません。 デイブに十分な顧客がいれば、キャロルはビルが彼女と競合するアリスに寄付したのか、それともキャロルが気にしていないアダム、アルバート、アビゲイルに寄付したのかを知ることはできません。 アリスは支払いにハッシュ化された値を含め、その後デイブにプリイメージを提供することで、それが自分の寄付であることを証明できます。 あるいは、前述のように、アリスがデイブに彼女の _Vpriv_ を渡せば、彼はすでに支払いが誰からのものかを知っています。 + +この解決策の主な問題は、その秘密がビルに利益をもたらす場合に、アリスが秘密を守ることを気にしなければならないという点です。 アリスは、ビルの友人であるボブも彼女に寄付するように、自分の評判を維持したいかもしれません。 しかし、彼女がビルを暴露することを気にしない可能性もあります。なぜなら、そうすれば彼はキャロルが勝った場合に何が起こるかを恐れるからです。 ビルは結果的にアリスをさらに支援することになるかもしれません。 + +### 複数のステルスレイヤーの使用 {#multi-layer} + +ビルのプライバシーを保護するためにアリスに頼る代わりに、ビル自身がそれを行うことができます。 彼は架空の人物、ボブとベラのために複数のメタアドレスを生成できます。 ビルは次にETHをボブに送り、「ボブ」(実際にはビル) がそれをベラに送ります。 「ベラ」(これもビル) がそれをアリスに送ります。 + +キャロルは依然としてトラフィック分析を行い、ビルからボブ、ベラ、アリスへのパイプラインを見ることができます。 しかし、「ボブ」と「ベラ」が他の目的でETHを使用している場合、アリスがステルスアドレスから既知のキャンペーンアドレスにすぐに引き出したとしても、ビルがアリスに何かを転送したようには見えません。 + +## ステルスアドレスアプリケーションの作成 {#write-app} + +この記事では、[GitHub](https://github.com/qbzzt/251022-stealth-addresses.git) で入手可能なステルスアドレスアプリケーションについて説明します。 + +### ツール {#tools} + +使用できる[TypeScriptのステルスアドレスライブラリ](https://github.com/ScopeLift/stealth-address-sdk)があります。 しかし、暗号操作はCPUを集中的に使用することがあります。 私はそれらを[Rust](https://rust-lang.org/)のようなコンパイル言語で実装し、[WASM](https://webassembly.org/)を使用してブラウザでコードを実行することを好みます。 + +[Vite](https://vite.dev/)と[React](https://react.dev/)を使用します。 これらは業界標準のツールです。もし馴染みがない場合は、[このチュートリアル](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)を使用できます。 Viteを使用するには、Nodeが必要です。 + +### ステルスアドレスの動作を見る {#in-action} + +1. 必要なツールをインストールします: [Rust](https://rust-lang.org/tools/install/) と [Node](https://nodejs.org/en/download)。 + +2. GitHubリポジトリをクローンします。 + + ```sh + git clone https://github.com/qbzzt/251022-stealth-addresses.git + cd 251022-stealth-addresses + ``` + +3. 前提条件をインストールし、Rustコードをコンパイルします。 + + ```sh + cd src/rust-wasm + rustup target add wasm32-unknown-unknown + cargo install wasm-pack + wasm-pack build --target web + ``` + +4. Webサーバーを起動します。 + + ```sh + cd ../.. + npm install + npm run dev + ``` + +5. [アプリケーション](http://localhost:5173/)にアクセスします。 このアプリケーションページには2つのフレームがあります。1つはアリスのユーザーインターフェース用、もう1つはビルのユーザーインターフェース用です。 2つのフレームは通信しません。便宜上、同じページにあるだけです。 + +6. アリスとして、**ステルス・メタアドレスを生成**をクリックします。 これにより、新しいステルスアドレスと対応する秘密鍵が表示されます。 ステルス・メタアドレスをクリップボードにコピーします。 + +7. ビルとして、新しいステルス・メタアドレスを貼り付け、**アドレスを生成**をクリックします。 これにより、アリスに資金を送るためのアドレスが表示されます。 + +8. アドレスとビルの公開鍵をコピーし、アリスのユーザーインターフェースの「ビルによって生成されたアドレスの秘密鍵」エリアに貼り付けます。 これらのフィールドに入力すると、そのアドレスの資産にアクセスするための秘密鍵が表示されます。 + +9. [オンライン計算機](https://iancoleman.net/ethereum-private-key-to-address/)を使用して、秘密鍵がアドレスに対応していることを確認できます。 + +### プログラムの仕組み {#how-the-program-works} + +#### WASMコンポーネント {#wasm} + +WASMにコンパイルされるソースコードは[Rust](https://rust-lang.org/)で書かれています。 [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs)で確認できます。 このコードは主に、JavaScriptコードと[`eth-stealth-addresses`ライブラリ](https://github.com/kassandraoftroy/eth-stealth-addresses)間のインターフェースです。 + +**`Cargo.toml`** + +Rustにおける[`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html)は、JavaScriptの[`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json)に類似しています。 パッケージ情報、依存関係の宣言などが含まれています。 + +```toml +[package] +name = "rust-wasm" +version = "0.1.0" +edition = "2024" + +[dependencies] +eth-stealth-addresses = "0.1.0" +hex = "0.4.3" +wasm-bindgen = "0.2.104" +getrandom = { version = "0.2", features = ["js"] } +``` + +[`getrandom`](https://docs.rs/getrandom/latest/getrandom/)パッケージは、乱数を生成する必要があります。 それは純粋なアルゴリズム的手法では実行できません。エントロピーの源として物理的なプロセスへのアクセスが必要です。 この定義は、実行中のブラウザに問い合わせることで、そのエントロピーを取得することを指定します。 + +```toml +console_error_panic_hook = "0.1.7" +``` + +[このライブラリ](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/)は、WASMコードがパニックを起こして続行できなくなったときに、より意味のあるエラーメッセージを提供します。 + +```toml +[lib] +crate-type = ["cdylib", "rlib"] +``` + +WASMコードを生成するために必要な出力タイプです。 + +**`lib.rs`** + +これが実際のRustコードです。 + +```rust +use wasm_bindgen::prelude::*; +``` + +RustからWASMパッケージを作成するための定義です。 それらは[ここ](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html)で文書化されています。 + +```rust +use eth_stealth_addresses::{ + generate_stealth_meta_address, + generate_stealth_address, + compute_stealth_key +}; +``` + +[`eth-stealth-addresses` ライブラリ](https://github.com/kassandraoftroy/eth-stealth-addresses)から必要な関数です。 + +```rust +use hex::{decode,encode}; +``` + +Rustは通常、値にバイト[配列](https://doc.rust-lang.org/std/primitive.array.html) (`[u8; ]`) を使用します。 しかし、JavaScriptでは、通常16進数文字列を使用します。 [`hex`ライブラリ](https://docs.rs/hex/latest/hex/)は、ある表現から別の表現へと変換してくれます。 + +```rust +#[wasm_bindgen] +``` + +JavaScriptからこの関数を呼び出すことができるように、WASMバインディングを生成します。 + +```rust +pub fn wasm_generate_stealth_meta_address() -> String { +``` + +複数のフィールドを持つオブジェクトを返す最も簡単な方法は、JSON文字列を返すことです。 + +```rust + let (address, spend_private_key, view_private_key) = + generate_stealth_meta_address(); +``` + +[`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html)は3つのフィールドを返します： + +- メタアドレス(_Kpub_ と _Vpub_) +- 閲覧用秘密鍵(_Vpriv_) +- 支払い用秘密鍵(_Kpriv_) + +[タプル](https://doc.rust-lang.org/std/primitive.tuple.html)構文を使用すると、これらの値を再度分離できます。 + +```rust + format!("{{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}}", + encode(address), + encode(view_private_key), + encode(spend_private_key) + ) +} +``` + +[`format!`](https://doc.rust-lang.org/std/fmt/index.html)マクロを使用して、JSONエンコードされた文字列を生成します。 [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html)を使用して、配列を16進数文字列に変更します。 + +```rust +fn str_to_array(s: &str) -> Option<[u8; N]> { +``` + +この関数は、(JavaScriptから提供された) 16進数文字列をバイト配列に変換します。 JavaScriptコードから提供された値を解析するために使用します。 この関数は、Rustが配列とベクターをどのように扱うかによって複雑になっています。 + +``という式は[ジェネリック](https://doc.rust-lang.org/book/ch10-01-syntax.html)と呼ばれます。 `N` は返される配列の長さを制御するパラメータです。 この関数は実際には`str_to_array::`として呼び出され、`n`は配列の長さです。 + +戻り値は `Option<[u8; N]>` であり、これは返される配列が[オプショナル](https://doc.rust-lang.org/std/option/)であることを意味します。 これは、失敗する可能性のある関数に対するRustの典型的なパターンです。 + +例えば、`str_to_array::10("bad060a7")`を呼び出すと、関数は10個の値を持つ配列を返すはずですが、入力は4バイトしかありません。 関数は失敗する必要があり、`None`を返すことでそれを行います。 `str_to_array::4("bad060a7")`の戻り値は `Some<[0xba, 0xd0, 0x60, 0xa7]>` になります。 + +```rust + // decodeはResult, _>を返す + let vec = decode(s).ok()?; +``` + +[`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html)関数は`Result, FromHexError>`を返します。 [`Result`](https://doc.rust-lang.org/std/result/)型には、成功した結果 (`Ok(value)`) またはエラー (`Err(error)`) のいずれかが含まれます。 + +`.ok()`メソッドは`Result`を`Option`に変換し、その値は成功した場合は`Ok()`の値、そうでなければ`None`になります。 最後に、[疑問符演算子](https://doc.rust-lang.org/std/option/#the-question-mark-operator-)は、`Option`が空の場合に現在の関数を中止し、`None`を返します。 そうでなければ、値をアンラップしてそれを返します (この場合、`vec`に値を割り当てます)。 + +これは奇妙で複雑なエラー処理方法に見えるかもしれませんが、`Result`と`Option`は、すべてのエラーが何らかの方法で処理されることを保証します。 + +```rust + if vec.len() != N { return None; } +``` + +バイト数が正しくない場合は失敗であり、`None`を返します。 + +```rust + // try_intoはvecを消費し、[u8; N]を作成しようと試みる + let array: [u8; N] = vec.try_into().ok()?; +``` + +Rustには2つの配列型があります。 [配列](https://doc.rust-lang.org/std/primitive.array.html)は固定サイズです。 [ベクター](https://doc.rust-lang.org/std/vec/index.html)は大きくなったり小さくなったりできます。 `hex::decode`はベクターを返しますが、`eth_stealth_addresses`ライブラリは配列を受け取ることを期待しています。 [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods)は、値を別の型、たとえばベクターを配列に変換します。 + +```rust + Some(array) +} +``` + +Rustでは、関数の最後で値を返す際に[`return`](https://doc.rust-lang.org/std/keyword.return.html)キーワードを使用する必要はありません。 + +```rust +#[wasm_bindgen] +pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option { +``` + +この関数は、_Vpub_ と _Kpub_ の両方を含む公開メタアドレスを受け取ります。 これは、ステルスアドレス、公開する公開鍵 (_Rpub_)、および公開されたアドレスのうちどれがアリスに属する可能性があるかを特定する速度を上げる1バイトのスキャン値を返します。 + +スキャン値は共有シークレット (_S = GRprivVpriv_) の一部です。 この値はアリスが利用でき、これを確認する方が _f(Kpub+G\*hash(S))_ が公開されたアドレスと等しいかどうかを確認するよりもはるかに高速です。 + +```rust + let (address, r_pub, scan) = + generate_stealth_address(&str_to_array::<66>(stealth_address)?); +``` + +ライブラリの[`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html)を使用します。 + +```rust + format!("{{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}}", + encode(address), + encode(r_pub), + encode(&[scan]) + ).into() +} +``` + +JSONエンコードされた出力文字列を準備します。 + +```rust +#[wasm_bindgen] +pub fn wasm_compute_stealth_key( + address: &str, + bill_pub_key: &str, + view_private_key: &str, + spend_private_key: &str +) -> Option { + . + . + . +} +``` + +この関数は、ライブラリの[`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html)を使用して、アドレスから引き出すための秘密鍵(_Rpriv_)を計算します。 この計算には以下の値が必要です： + +- アドレス (_Address=f(Ppub)_) +- ビルによって生成された公開鍵(_Rpub_) +- 閲覧用秘密鍵(_Vpriv_) +- 支払い用秘密鍵(_Kpriv_) + +```rust +#[wasm_bindgen(start)] +``` + +[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html)は、WASMコードが初期化されるときに関数が実行されることを指定します。 + +```rust +pub fn main() { + console_error_panic_hook::set_once(); +} +``` + +このコードは、パニック出力をJavaScriptコンソールに送信することを指定します。 動作を確認するには、アプリケーションを使用し、ビルに無効なメタアドレスを与えます (16進数の1桁を変更するだけ)。 JavaScriptコンソールに次のエラーが表示されます： + +``` +rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9: +assertion `left == right` failed + left: 0 + right: 1 +``` + +続いてスタックトレースが表示されます。 次に、ビルに有効なメタアドレスを与え、アリスには無効なアドレスまたは無効な公開鍵のいずれかを与えます。 次のエラーが表示されます： + +``` +rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9: +keys do not generate stealth address +``` + +再び、スタックトレースが続きます。 + +#### ユーザーインターフェース {#ui} + +ユーザーインターフェースは[React](https://react.dev/)を使用して書かれ、[Vite](https://vite.dev/)によって提供されます。 これらについては、[このチュートリアル](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/)で学ぶことができます。 ここでは、ブロックチェーンやウォレットと直接対話しないため、[WAGMI](https://wagmi.sh/)は必要ありません。 + +ユーザーインターフェースで唯一自明でない部分は、WASMの接続性です。 その仕組みは次のとおりです。 + +**`vite.config.js`** + +このファイルには[Viteの設定](https://vite.dev/config/)が含まれています。 + +```js +import { defineConfig } from 'vite' +import react from '@vitejs/plugin-react' +import wasm from "vite-plugin-wasm"; + +// https://vite.dev/config/ +export default defineConfig({ + plugins: [react(), wasm()], +}) +``` + +2つのViteプラグインが必要です: [react](https://www.npmjs.com/package/@vitejs/plugin-react)と[wasm](https://github.com/Menci/vite-plugin-wasm#readme)。 + +**`App.jsx`** + +このファイルは、アプリケーションのメインコンポーネントです。 これは、`Alice`と`Bill`という2つのコンポーネントを含むコンテナで、これらのユーザーのユーザーインターフェースです。 WASMに関連する部分は初期化コードです。 + +```jsx +import init from './rust-wasm/pkg/rust_wasm.js' +``` + +[`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/)を使用すると、ここで使用する2つのファイルが作成されます。1つは実際のコードを含むwasmファイル (ここでは`src/rust-wasm/pkg/rust_wasm_bg.wasm`)、もう1つはそれを使用するための定義を含むJavaScriptファイル (ここでは`src/rust_wasm/pkg/rust_wasm.js`)です。 そのJavaScriptファイルのデフォルトエクスポートは、WASMを初期化するために実行する必要があるコードです。 + +```jsx +function App() { + . + . + . + useEffect(() => { + const loadWasm = async () => { + try { + await init(); + setWasmReady(true) + } catch (err) { + console.error('Error loading wasm:', err) + alert("Wasm error: " + err) + } + } + + loadWasm() + }, [] + ) +``` + +[`useEffect`フック](https://react.dev/reference/react/useEffect)を使用すると、状態変数が変更されたときに実行される関数を指定できます。 ここでは、状態変数のリストが空 (`[]`) なので、この関数はページが読み込まれたときに一度だけ実行されます。 + +エフェクト関数はすぐに戻る必要があります。 WASM `init` (これは`.wasm`ファイルをロードする必要があるため時間がかかります) のような非同期コードを使用するために、内部で[`async`](https://en.wikipedia.org/wiki/Async/await)関数を定義し、`await`なしで実行します。 + +**`Bill.jsx`** + +これはビルのユーザーインターフェースです。 アリスから提供されたステルス・メタアドレスに基づいてアドレスを作成するという単一のアクションがあります。 + +```jsx +import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js' +``` + +デフォルトのエクスポートに加えて、`wasm-pack`によって生成されたJavaScriptコードは、WASMコードのすべての関数に対応する関数をエクスポートします。 + +```jsx +