知っておくと良いこと
+AIエージェントおよび関連ツールは、まだ開発の初期段階にあり、非常に実験的な段階です——使用には注意が必要です。
+`nonce``
-`` - _コードスニペットの開始タグく_
+`` - _コードスニペットを含む開始タグ_
-nonce - _翻訳しないテキスト_
+nonce - _翻訳対象外のテキスト_
`` - _終了タグ_
@@ -154,13 +160,13 @@ nonce - _翻訳しないテキスト_
ソーステキストに数値のみの短縮タグも含まれている場合があり、そのタグの意味がすぐには分からない場合があります。 これらのタグにカーソルを合わせると、タグの意味や機能を確認できます。
-以下の例では、 \<0> タグにカーソルを合わせると、 ``が表示され、コードスニペットであることが分かります。そのため、これらのタグ内のテキストは翻訳しないでください。
+以下の例では、`<0>`タグにカーソルを合わせると、それが``を表し、コードスニペットを含んでいることがわかります。したがって、これらのタグ内のコンテンツは翻訳しないでください。
-## 短縮語、非短縮語／略語 {#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」と記載)。
-ボタンの翻訳は、書式の不一致を防ぐためにできるだけ短くする必要があります。 さらに、ボタンの翻訳は、コマンドやリクエストを示すものでなければなりません。
+ボタンの翻訳は、書式の不一致を防ぐためにできるだけ短くする必要があります。 さらに、ボタンの翻訳は、命令や要求を表す命令形にする必要があります。
-## 包括性を踏まえた翻訳 {#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..72898377a49 100644
--- a/public/content/translations/ja/dao/index.md
+++ b/public/content/translations/ja/dao/index.md
@@ -1,5 +1,6 @@
---
-title: 分散型自律組織(DAO)
+title: DAOとは何ですか？
+metaTitle: DAOとは何ですか？ | 分散型自律組織
description: イーサリアムにおける分散型自律組織(DAO)の概要
lang: ja
template: use-cases
@@ -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)のメンバー間で再配分できる。
- 分散型金融(DeFi)アプリを探す
+ DeFiアプリを探す
## 始まりはビットコイン... {#bitcoin}
@@ -59,16 +60,16 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ
+
イーサリアムを初めて使う方にお勧めの分散型金融(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)
- 支払いの分散型アプリ(Dapp)を見る
+ 決済dappsを見る
#### 世界中へのお金の流通... {#stream-money}
また、イーサリアムでお金を流通させることもできます。 これにより、誰かに給料を秒単位で支払うことができ、受取人は必要なときにいつでもお金にアクセスすることができます。 また、コインロッカーや電動自転車など、秒単位でレンタルすることもできます。
-また、[ETH](/glossary/#ether)の価値がどれだけ変わるかわからないので、送金や流通はしたくないという方には、イーサリアムの代替通貨である[ステーブルコイン](/glossary/#stablecoin)があります。
+また、価値の変動が大きいため[ETH](/glossary/#ether)の送金やストリーミングをしたくない場合でも、イーサリアムには代替通貨である[ステーブルコイン](/glossary/#stablecoin)があります。
- ステーブルコインの詳細
+ステーブルコインの詳細はこちら
- 融資分散型アプリ(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を売却(課税対象)することなく、必要な資金を借り入れる
- 貸付サービスの分散型アプリ(Dapp)を見る
+ レンディングdappsを見る
-#### 損失がない宝くじ {#no-loss-lotteries}
+#### 損失のでない宝くじ {#no-loss-lotteries}
PoolTogetherのような損失のない宝くじは、楽しく革新的な新しい貯蓄方法です。
@@ -210,14 +211,14 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
- トークン交換所を見る
+ トークン取引所を見る
- トレード分散型アプリ(Dapp)を見る
+ トレーディングdappsを見る
- 投資分散型アプリ(Dapp)を見る
+ 投資dappsを見る
- クラウドファンディング分散型アプリ(Dapp)を見る
+ クラウドファンディングdappsを見る
-#### クオドラティック・ファンディング {#quadratic-funding}
+#### クアドラティック・ファンディング {#quadratic-funding}
-イーサリアムはオープンソースソフトウェアであり、これまでの作業の多くはコミュニティの資金提供を受けてきました。 これにより、クオドラティック・ファンディングという興味深い新しい資金調達モデルが成長しました。 将来的に、私達が公共財のすべてのタイプに資金を供給する方法を改善する可能性があるファンディングです。
+イーサリアムはオープンソースソフトウェアであり、これまでの作業の多くはコミュニティの資金提供を受けてきました。 これにより、クオドラティック・ファンディングという興味深い新しい資金調達モデルが成長しました。 クアドラティック・ファンディングは、将来的にすべての種類の公共財の資金供給方法を改善できる可能性を秘めており、
-クオドラティック・ファンディングでは、最もユニークな必要性があるプロジェクトが、最も多くの資金を受け取るようになっています。 つまり、ほとんどの人々の生活を向上させるためのプロジェクトです。 その仕組みは次のとおりです。
+最もユニークな必要性があるプロジェクトが、最多の資金を受け取るようになっています。 つまり、最も多くの人々が必要なものに資金が渡り、人々の生活の向上につながるプロジェクトです。 その仕組みは次のとおりです。
1. 寄付を集めて供与先を決めるためのマッチングプールがあります。
2. 資金供与のラウンドが始まります。
@@ -272,7 +273,7 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
つまり、1ドルの寄付が100件集まったプロジェクトAの方が、1つの1万ドルの寄付に支援されたプロジェクトBよりも多くの資金を得られる可能性があるということです(マッチングプールの大きさによります)。
- クオドラティック・ファンディングの詳細
+ クアドラティック・ファンディングの詳細
- 保険分散型アプリ(Dapp)見る
+ 保険dappsを見る
- ポートフォリオ分散型アプリ(Dapp)を見る
+ ポートフォリオdappsを見る
- 分散型アプリ(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)
-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,13 +125,13 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
@@ -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)")
@@ -1762,10 +1888,10 @@ web3.sha3("Print(uint256)")
ここまで、最も一般的なタスクをいくつか簡単に紹介し、JSON-RPCを直接使用するための方法を実例を交えて説明しました。
-## 関連トピック {#related-topics}
+## 関連トピック{#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..0691954e229 100644
--- a/public/content/translations/ja/developers/docs/blocks/index.md
+++ b/public/content/translations/ja/developers/docs/blocks/index.md
@@ -6,15 +6,16 @@ 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}
ブロックはすべてのイーサリアムネットワークへの参加者が同期された状態を維持し、トランザクションの正確な履歴に同意できるように、複数のトランザクションをブロックにバッチとして格納します。 これは、何十件(もしくは数百) ものトランザクションが一度にコミット、合意、同期されることを意味します。
- _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_
+
+_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)を参考に作成_
コミットの間隔をあけ、すべてのネットワーク参加者がコンセンサスに至るまでの十分な時間を確保しています。たとえトランザクション要求が毎秒数十回発生したとしても、ブロックはイーサリアム上で12秒に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,17 +136,17 @@ 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}
+## 関連トピック{#related-topics}
- [トランザクション](/developers/docs/transactions/)
- [ガス](/developers/docs/gas/)
diff --git a/public/content/translations/ja/developers/docs/bridges/index.md b/public/content/translations/ja/developers/docs/bridges/index.md
index e42e20e7088..7d40700c891 100644
--- a/public/content/translations/ja/developers/docs/bridges/index.md
+++ b/public/content/translations/ja/developers/docs/bridges/index.md
@@ -4,17 +4,17 @@ 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..d7ed51ec83a 100644
--- a/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md
@@ -4,11 +4,11 @@ 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,11 +28,11 @@ lang: ja
これらの構成要素が一体となって合意メカニズムを形成しています。
-## 合意形成アルゴリズムの種類 {#types-of-consensus-mechanisms}
+## 合意メカニズムの種類 {#types-of-consensus-mechanisms}
-### プルーフ・オブ・ワーク方式 {#proof-of-work}
+### プルーフ・オブ・ワークベース {#proof-of-work}
-ビットコインと同様に、イーサリアムもかつては**プルーフ・オブ・ワーク(PoW)**に基づいたコンセンサスプロトコルを使用していました。
+ビットコインと同様に、イーサリアムもかつては\*\*プルーフ・オブ・ワーク(PoW)\*\*に基づいたコンセンサスプロトコルを使用していました。
#### ブロックの作成 {#pow-block-creation}
@@ -44,9 +44,9 @@ lang: ja
[プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)の詳細
-### プルーフ・オブ・ステーク方式 {#proof-of-stake}
+### プルーフ・オブ・ステークベース {#proof-of-stake}
-イーサリアムは現在、**プルーフ・オブ・ステーク(PoS)**に基づいたコンセンサスプロトコルを使用しています。
+イーサリアムは現在、\*\*プルーフ・オブ・ステーク(PoS)\*\*に基づいたコンセンサスプロトコルを使用しています。
#### ブロックの作成 {#pos-block-creation}
@@ -56,7 +56,7 @@ lang: ja
仮にプルーフ・オブ・ステーク・システムでチェーンを支配しようとすると、攻撃者は大量のETHを破壊しなければならないため、暗号経済的に安全性が保たれています。 報酬システムがステーカーに対して、誠実な行動を取るようにインセンティブを与える一方、ペナルティは悪意のある行動を抑制しています。
-[プルーフ・オブ・ステーク ](/developers/docs/consensus-mechanisms/pos/)の詳細
+[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)の詳細
### ビジュアルガイド {#types-of-consensus-video}
@@ -68,23 +68,23 @@ 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}
+## 関連トピック{#related-topics}
- [プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)
- [マイニング](/developers/docs/consensus-mechanisms/pow/mining/)
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..8b3de41f432 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
@@ -51,7 +51,7 @@ PoAネットワークでは、N人の認証された署名者がいる場合、
## メリットとデメリット{#pros-and-cons}
-| メリット | デメリット |
+| 長所 | 短所 |
| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| ブロック署名者の数を制限することをベースとしているため、他の一般的なメカニズムであるプルーフ・オブ・ステークやプルーフ・オブ・ワークなどよりもスケーラブル。 | プルーフ・オブ・オーソリティのネットワークでは、検証ノードの数が比較的少ない。 これにより、プルーフ・オブ・オーソリティのネットワークは、より集中化する。 |
| プルーフ・オブ・オーソリティは、実行と維持が安価。 | ブロックチェーンは評判の確立したエンティティを要求するため、一般的な人は通常、認証された署名者になることができない。 |
@@ -78,3 +78,4 @@ PoAネットワークでは、N人の認証された署名者がいる場合、
- [プルーフ・オブ・ワーク](/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..5b48ef012f9 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
@@ -6,7 +6,7 @@ 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#) によるバランシングのテクニックが用いられますが、これについては以下のセクションで検証します。
-
+
上記の1ブロック後の再編成攻撃の概念図 (https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair を修正)
@@ -67,7 +70,7 @@ lang: ja
データ`には、以下の情報が含まれます：
+アテステーションを行うバリデータの最初のタスクは、`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
以下の図は、アテステーションのライフサイクルの概略を示したものです。
-
+
## 報酬 {#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..5bab884acf3 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
@@ -6,19 +6,19 @@ lang: ja
ブロックは、ブロックチェーンにおける基本的な単位です。 ブロックとは、各ノード間で受け渡しされ、合意され、各ノードのデータベースに追加される情報を区切った単位です。 このページでは、ブロックがどのように生成されるのかを説明します。
-## 前提知識 {#prerequisites}
+## 前提条件{#prerequisites}
-ブロックの提案は、プルーフ・オブ・ステークのプロトコルの一部です。 このページの内容を理解するためには、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)および[ブロックのアーキテクチャ](/developers/docs/blocks/)を読んでおくとよいでしょう。
+ブロックの提案は、プルーフ・オブ・ステークのプロトコルの一部です。 このページを理解するために、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)と[ブロックの構造](/developers/docs/blocks/)について読むことを推奨します。
-## 誰がブロックを生成するのか？ {#who-produces-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..639bf0cad61 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
@@ -4,11 +4,11 @@ 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)やジャスティン・ドレイクとリン・オールデンとのディベートで、議論の概要がよくまとめられています。
- 現在、プルーフ・オブ・ワークは廃止されています。 イーサリアムの合意メカニズムにはプルーフ・オブ・ワークではなく、 現在はプルーフ・オブ・ステークが採用されています。 詳細については、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)と[ステーキング](/staking/)を参照してください。
+ 現在、プルーフ・オブ・ワークは廃止されています。 イーサリアムの合意メカニズムにはプルーフ・オブ・ワークではなく、 現在はプルーフ・オブ・ステークが採用されています。 [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)と[ステーキング](/staking/)について詳しく読む。
-## 前提条件 {#prerequisites}
+## 前提条件{#prerequisites}
-このページをよく理解するためには、まず[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、および[合意メカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。
+このページについて深く理解するには、事前に[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。
## プルーフ・オブ・ワーク(PoW)とは {#what-is-pow}
-ナカモトコンセンサスはプルーフ・オブ・ワークを利用した旧メカニズムで、分散型のイーサリアムネットワークが、アカウント残高やトランザクションの順序などについてコンセンサス(例: すべてのノードが合意すること)を得ることを可能にしました。 加えてユーザーのコインの「二重支出」を防ぎ、イーサリアムチェーンの攻撃や改ざんを非常に困難なものにしました。 これらのセキュリティは現在、[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)として知られる合意メカニズムを用いたプルーフ・オブ・ステークによりもたらされています。
+プルーフ・オブ・ワークを利用するナカモトコンセンサスは、分散型イーサリアムネットワークがアカウント残高やトランザクションの順序などについてコンセンサス(すなわち、すべてのノードが合意すること)を得ることをかつて可能にしていたメカニズムです。 加えてユーザーのコインの「二重支出」を防ぎ、イーサリアムチェーンの攻撃や改ざんを非常に困難なものにしました。 現在、これらのセキュリティプロパティは、[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)として知られるコンセンサスメカニズムを用いたプルーフ・オブ・ステークによってもたらされています。
## プルーフ・オブ・ワークとマイニング {#pow-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}
+## メリットとデメリット{#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}
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`が互いに素であることが成り立ち、これは次のようになります。 -> ->
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..20574f8781d 100644
--- a/public/content/translations/ja/developers/docs/frameworks/index.md
+++ b/public/content/translations/ja/developers/docs/frameworks/index.md
@@ -6,136 +6,150 @@ 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)
-## 関連トピック {#related-topics}
+## 参考リンク{#further-reading}
-- [ローカル開発環境のセットアップ](/developers/local-environment/)
+_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_
+
+## 関連トピック{#related-topics}
+
+- [ローカル開発環境をセットアップする](/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..5d1a23c7c99 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:
+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](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_
+
+_図は[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)`が返還)。
- _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_
+
+_図は[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..fcab7e5ec6b 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:
+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..4e60e9d114a 100644
--- a/public/content/translations/ja/developers/docs/index.md
+++ b/public/content/translations/ja/developers/docs/index.md
@@ -6,13 +6,13 @@ 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}
+ {JSON.stringify(attrs.object, null, 2)}
+```
+
+ほとんどのフィールドは、[`JSON.stringify`](https://www.w3schools.com/js/js_json_stringify.asp)を使用して表示されます。
+
+```tsx
+
+ { funs.length > 0 &&
+ <>
+ Functions:
+ @`を含むコメントは、 [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,63 @@ 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 +307,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 +383,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 +509,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 +590,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}
+## このコントラクトの使用 {#using-contract}
-Solidityとは異なり、Viperは相続機能を提供しません。 これは、コードをより明確にし、セキュリティを確保しやすくするための意図的な設計上の選択によるものです。 このため、あなた自身がVyperでERC-721コントラクトを作成する際は、[このコントラクト](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy)を用いて修正し、必要なビジネスロジックを実装してください。
+Solidityとは対照的に、Vyperには継承がありません。 これは、コードをより明確にし、
+したがってセキュリティを確保しやすくするための意図的な設計上の選択です。 したがって、独自のVyper ERC-721コントラクトを作成するには、この
+コントラクトを取得し、
+必要なビジネスロジックを実装するように変更します。
-### まとめ {#conclusion}
+## 結論 {#conclusion}
-このコントラクトにつき、最も重要なポイントを以下にまとめました：
+復習のために、このコントラクトの最も重要なアイデアをいくつか紹介します。
-- 安全モードの送信を使ってERC-721トークンを受け取るには、コントラクトに`ERC721Receiver`インターフェイスを実装する必要があります。
-- 安全モードの送信を実行した場合でも、秘密鍵が不明なアドレスに送信したトークンは行方不明になる可能性があります。
-- 操作に問題が発生した場合、単に失敗値をリターンするのではなく、コール自体を`取り消す`ことをお勧めします。
-- ERC-721トークンには、必ず所有者が必要です。
-- NFTの送信を承認するには、3通りの方法があります。 承認できるのは、所有者であるか、特定トークンの送信を承認されているか、所有者のトークンすべてに対するオペレーターであるユーザーのみです。
-- 過去のイベントは、ブロックチェーン外でのみ表示されます。 ブロックチェーン内で実行されるコードは、表示できません。
+- 安全な送金でERC-721トークンを受信するには、コントラクトは`ERC721Receiver`インターフェイスを実装する必要があります。
+- 安全な送金を使用しても、秘密鍵が不明なアドレスに送信すると、
+ トークンがスタックする可能性があります。
+- 操作に問題がある場合は、単に失敗値を返すのではなく、
+ 呼び出しを`revert`することをお勧めします。
+- ERC-721トークンは、所有者がいる場合に存在します。
+- NFTの送金を承認するには、3つの方法があります。 所有者であるか、特定のトークンに対して承認されているか、
+ または所有者のすべてのトークンのオペレーターであることができます。
+- 過去のイベントはブロックチェーンの外部からのみ表示されます。 ブロックチェーン内で実行されるコードは、それらを表示できません。
+
+では、セキュアなVyperコントラクトを実装してみましょう。
+
+[私の他の作品はこちらでご覧いただけます](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..e7b5ce06416 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、または流動性プールのような別のコントラクトであっても、インターフェースで同じ定義を使用でき、そのインターフェースを使用するすべてのトークンコントラクトと互換性があります。
-経験豊富なプログラマーであれば、[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..7cb09d581ac 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アイコン () をクリックします。
+2. GitHubのクローンアイコン()をクリックします。
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..e6990de5671
--- /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は企業の社内ウェブサイトであるとします。 従業員が出張の予約をする際、旅行代理店は、実際に旅行の予約を許可する前に、従業員を会社の認証に送ります。
+
+
+
+これが、ブラウザ、SP、IdPの3つのエンティティがアクセスを交渉する方法です。 SPは、ブラウザを使用しているユーザーについて事前に何も知る必要はなく、IdPを信頼するだけで済みます。
+
+### SAML関係者向けのイーサリアム
+
+イーサリアムは分散型システムです。
+
+
+
+ユーザーは秘密鍵を持っています (通常はブラウザ拡張機能に保存されています)。 秘密鍵から公開鍵を導出し、そこから20バイトのアドレスを導出できます。 ユーザーがシステムにログインする必要がある場合、ノンス (1回限りの値) を持つメッセージに署名するよう要求されます。 サーバーは、署名がそのアドレスによって作成されたことを検証できます。
+
+
+
+署名はイーサリアムアドレスを検証するだけです。 他のユーザー属性を取得するには、通常[アテステーション](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) にリダイレクトされ、メールアドレスで認識されていることを確認します。
+
+### 詳細な説明
+
+ステップバイステップで起こることは次のとおりです。
+
+
+
+#### 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
+
+
+
+ `)
+ }
+)
+
+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
+
+
+ ログインページ
+
+
+ ログインページ
+
+
+
+
+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にあります。
+
+
+
+変更したファイルは `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` です。 独自のアドレスを使用した場合は、証明した内容になります。
+
+### 詳細な説明
+
+
+
+新しいステップは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..032cbed9885 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
@@ -2,59 +2,54 @@
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
-source: Medium
+source: 中
sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f
---
-
+
-この記事は、はじめてイーサリアム開発を行う初心者向けのガイドです。 このチュートリアルでは、[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/)に、心より感謝申し上げます！_
-
+
-「Create App」の下にある詳細情報に記入して、新規キーを取得してください。 ここでは、あなたが以前に作成したアプリや、あなたのチームが作成したアプリも確認できます。 どのアプリについても、「View Key（キーを表示）」をクリックすると既存のキーを取得できます。
+「Create App」の下にある詳細情報に記入して、新しいキーを取得してください。 ここでは、あなたが以前に作成したアプリや、あなたのチームが作成したアプリも確認できます。 どのアプリについても、「View Key」をクリックすると既存のキーを取得できます。
-
+
-あるいは、カーソルを「Apps（アプリ）」の部分に移動させ、希望するアプリを選択する方法でも既存のAPIキーを取得することができます。 ここでは、「View Key（キーを表示）」できる他、「Edit App（アプリを編集）」して、特定のドメインをホワイトリストに追加したり、開発者ツールを参照したり、アナリティクスを確認することができます。
+「Apps」にカーソルを合わせていずれかを選択することでも、既存のAPIキーを取得できます。 ここでは「View Key」の表示に加え、「Edit App」で特定のドメインをホワイトリストに登録したり、複数の開発者ツールを閲覧したり、アナリティクスを確認したりすることができます。
-
+
-## 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..2186d6ebf5f 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: セキュアなコントラクトの開発
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..f487c1201dd 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: イーサリアムでの簡単なスマートコントラクトの作成とデプロイに関する入門チュートリアル
+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_」という名前を付けて、短い説明を書きます。 環境は、**Staging**を選択します。ネットワークは、**Goerli**を選択します。
+アプリに「_Hello World_」という名前を付け、簡単な説明を記述します。 環境として **Staging** を、ネットワークとして **Goerli** を選択します。
-
+
-_注意: 必ず**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を取得するには、以下を参照してください
-`.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) にアクセスしてコントラクトアドレスを検索すると、正常にデプロイされたことを確認できるはずです。 トランザクションは以下のようなものになります。
-`From`アドレスはMetaMaskアカウントのアドレスと一致し、`To`アドレスは「**Contract Creation**」と表示されます。 トランザクション内容をクリックすると、`To`フィールドにコントラクトアドレスが表示されます.
+`From`アドレスはMetaMaskアカウントのアドレスと一致し、`To`アドレスには**Contract Creation**と表示されます。 トランザクションをクリックすると、`To`フィールドにコントラクトアドレスが表示されます。
-おめでとうございます！ イーサリアムのテストネットにスマートコントラクトをデプロイできました.
+おめでとうございます！ Ethereumテストネットにスマートコントラクトをデプロイできました。
-内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemyのアプリが複数ある場合は、必ずアプリでフィルタリングし、「**Hello World**」を選択してください。
+内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemy.com/explorer)のExplorerタブに移動してみましょう。 複数のAlchemyアプリをお持ちの場合は、必ずアプリでフィルタリングし、**Hello World**を選択してください。
-ここでは、`.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があります。
@@ -837,25 +840,25 @@ 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 +878,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 +914,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 +935,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,21 +989,19 @@ export const helloWorldContract = new web3.eth.Contract(
)
```
-私たちのコントラクトがロードされたので、`loadCurrentMessage`関数を実装できます！
+コントラクトがロードされたので、`loadCurrentMessage`関数を実装できます！
#### `interact.js`ファイルに`loadCurrentMessage`を実装する {#implementing-loadCurrentMessage-in-your-interact-js-file}
-これは非常にシンプルな関数です。 私たちのコントラクトから読み取るのに、単純な非同期のWeb3の呼び出しを作成します。 この関数では、スマートコントラクトに保存されているメッセージを返します。
+これは非常にシンプルな関数です。 コントラクトから読み取るために、単純な非同期のweb3呼び出しを作成します。 この関数では、スマートコントラクトに保存されているメッセージを返します。
-`interact.js`ファイルの `loadCurrentMessage`を次のように更新してください。
+// interact.jsexport const loadCurrentMessage = async () => {
+const message = await helloWorldContract.methods.message().call()
+return message
+}
```javascript
-// interact.js
-
-export const loadCurrentMessage = async () => {
- const message = await helloWorldContract.methods.message().call()
- return message
-}
+`interact.js`ファイルの `loadCurrentMessage`を次のように更新してください。
```
このスマートコントラクトをUIに表示したいので、`HelloWorld.js`コンポーネントの `useEffect`関数を次のように更新します。
@@ -1015,48 +1016,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 +1066,9 @@ contract HelloWorld {
}
```
-スマートコントラクトイベントは、ブロックチェーンで何かが起こったこと \(すなわち、_イベント_の発生 \) をフロントエンドアプリケーションに伝える方法です。特定のイベントを「リスニング」して、それが起きた時にアクションを実行します。
+スマートコントラクトイベントは、ブロックチェーンで何かが起こったこと \(すなわち、_イベント_の発生\) をフロントエンドアプリケーションに伝える方法です。フロントエンドは特定のイベントを「リスニング」して、それが起きた時にアクションを実行します。
-具体的には、`addSmartContractListener`関数がHello Worldスマートコントラクトの`UpdatedMessages`イベントをリッスンしており、新しいメッセージを表示するようにUIの更新をします。
+`addSmartContractListener`関数は、具体的にはHello Worldスマートコントラクトの`UpdatedMessages`イベントをリッスンし、新しいメッセージを表示するようにUIを更新します。
`addSmartContractListener`を次のように変更します。
@@ -1081,7 +1082,7 @@ function addSmartContractListener() {
} else {
setMessage(data.returnValues[1])
setNewMessage("")
- setStatus("🎉 Your message has been updated!")
+ setStatus("🎉 メッセージが更新されました！")
}
})
}
@@ -1089,10 +1090,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 +1105,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 +1155,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 +1173,7 @@ export const connectWallet = async () => {
@@ -1187,20 +1187,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 +1216,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 +1246,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 +1268,7 @@ export const getCurrentWalletConnected = async () => {
@@ -1279,9 +1278,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 +1298,13 @@ useEffect(async () => {
}, [])
```
-`walletAddress`状態変数と`status`状態変数を更新するのに、呼び出した`getCurrentWalletConnected`のレスポンスを使用していることに注目してください。
+`walletAddress`と`status`の状態変数を更新するのに、`getCurrentWalletConnected`の呼び出しのレスポンスを使用していることに注目してください。
このコードを加えたら、ブラウザウィンドウを更新してみてください。
素晴らしい！ リフレッシュ後も、ボタンには接続されていることが示されており、接続されたウォレットのアドレスのプレビューが表示されているはずです。
-#### `addWalletListener`の実装 {#implement-addwalletlistener}
+#### `addWalletListener`を実装する {#implement-addwalletlistener}
分散型アプリケーション(Dapp)ウォレットの設定の最終ステップは、ウォレットリスナーを実装することです。これにより、ユーザーが接続を切断したり、アカウントを切り替えたりした場合など、ウォレットの状態が変更されたときにUIが更新されます。
@@ -1319,10 +1318,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 +1329,7 @@ function addWalletListener() {
)
@@ -1338,11 +1337,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 +1363,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 +1386,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 +1400,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 +1425,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 +1441,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 +1490,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 +1520,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..de651b14268 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: イーサリアムでの簡単なスマートコントラクトの作成とデプロイに関する入門チュートリアル
+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」ページに移動します。
-
+
-2. アプリに「Hello World」という名前を付け、簡単な説明を記述し、環境に「Staging」を選択(アプリのブックキーピングに使用)し、ネットワークに「Goerli」を選択します。
+2. アプリに「Hello World」という名前を付け、簡単な説明を提示し、「Infra & Tooling」などのユースケースを選択します。 次に、「Ethereum」を検索してネットワークを選択します。
-
+
-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」を選択します。
-
+
-## ステップ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に相当します。
>
-> ご安心ください。 偽のお金はすべてそこにあります
-.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/)にアクセスし、コントラクトアドレスを検索すると、正常にデプロイされたことが確認できるはずです。 トランザクションは以下のようなものになります。
-
+
-`From`アドレスはMetaMaskアカウントアドレスと一致する必要があります。Toアドレスには「Contract Creation」と表示されますが、トランザクションをクリックすると、`To`フィールドにコントラクトアドレスが表示されます。
+`From`アドレスはMetaMaskアカウントのアドレスと一致し、`To`アドレスは「Contract Creation」と表示されますが、トランザクションをクリックすると`To`フィールドにコントラクトアドレスが表示されます。
-
+
-おめでとうございます! イーサリアムチェーンにスマートコントラクトをデプロイできました 🎉
+おめでとうございます！ イーサリアムチェーンにスマートコントラクトをデプロイできました 🎉
-内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemyのアプリが複数ある場合は、必ずアプリでフィルタリングし、「Hello World」を選択してください。 
+内部で何が起こっているのかを理解するために、[Alchemyダッシュボード](https://dashboard.alchemyapi.io/explorer)のExplorerタブに移動してみましょう。 Alchemyアプリが複数ある場合は、必ずアプリでフィルタリングし、「Hello World」を選択してください。
+
-ここでは、`.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..824207bdf1d 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
@@ -2,11 +2,7 @@
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..9d4ca700d2c 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をミントする方法を説明します。
+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にもう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にアップロードしてください。
-
+
## ステップ5: コントラクトのインスタンスを作成する {#instance-contract}
-ここで、私たちのコントラクトと対話するには、コード内でインスタンスを作成する必要があります インスタンスの作成には、コントラクトアドレスが必要になります。コントラクトをデプロイする際に使用したアドレスを検索することで、デプロイメントまたは[Etherscan](https://sepolia.etherscan.io/)から取得できます。
+さて、コントラクトとやりとりするには、コード内でそのインスタンスを作成する必要があります。 そのためにはコントラクトアドレスが必要ですが、これはデプロイメントから取得するか、コントラクトのデプロイに使用したアドレスを[Blockscout](https://eth-sepolia.blockscout.com/)で検索することで取得できます。
-
+
-上記の例では、コントラクトのアドレスは、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メタデータハッシュコードを取得する方法_
+_PinataでNFTメタデータのハッシュコードを取得する方法_
-> 別のウィンドウで`https://gateway.pinata.cloud/ipfs/`を読み込んでみて、コピーしたハッシュコードが**metadata.json**にリンクしているか確認します。 以下のスクリーンショットと類似したページが表示されるはずです。
+> 別のウィンドウで `https://gateway.pinata.cloud/ipfs/` を読み込み、コピーしたハッシュコードがあなたの**metadata.json**にリンクしていることを再確認してください。 ページは下のスクリーンショットのようになっているはずです。
-_ページにjsonメタデータが表示されるはずです_
+_ページに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トランザクションハッシュを表示します_
+_EtherscanでNFTトランザクションハッシュを表示_
-以上で完了です。 イーサリアムブロックチェーン上にデプロイしてNFTをミントしました。 `](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..64174ec98f2 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のフロントエンド開発をはじめましょう
+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)形式で、すぐに使えるいくつかのサブグラフをすでに提供しています。
-
+
### 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/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..4ced76729fe 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）を使用してブロックチェーン上のデータに対するクエリを実行することで、トランザクション、ブロック、ガスといったイーサリアムの基本的な概念についての理解を深めるものです。
+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上のEFのコントラクトのページ](https://etherscan.io/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)
+[Blockscout上のEFのコントラクトページ。](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)
#### Dune Analytics {#dune-analytics}
-ダッシュボードは、[こちら](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/)):
-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出力はこちらです:
-ブロックチェーンにこの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件が正常に検証されました:
-トランザクションリクエストは、毎秒あたり数十回発生しますが、ブロックがコミットされるのはおよそ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年〜現在）のグラフはこちらです:
-この期間に毎日生成されたブロックの平均数は、約5,874 です。
+この期間に毎日生成されたブロックの平均数は約5,874です:
-クエリは、次のように行います：
+クエリは、次のように行います。
```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年から現在までを可視化できます:
@@ -228,7 +225,7 @@ GROUP BY dt
OFFSET 1
```
-さらに、イーサリアム・ブロックチェーン上で実行された処理（トランザクションの送信、スマートコントラクトの呼び出し、NFTのミント）のために実際に支払われた1日あたりのガスを調べることもできます。 これは、利用可能なイーサリアムのブロックスペースに対する**需要**を示します：
+そして、イーサリアムチェーン上での計算(トランザクションの送信、スマートコントラクトの呼び出し、NFTのミントなど)の支払いに毎日使用される実際のガスがあります。 これは、利用可能なイーサリアムのブロックスペースに対する**需要**です:
@@ -241,17 +238,17 @@ GROUP BY dt
OFFSET 1
```
-これら2つのグラフを比較することで、 **需要と供給**の関係を確認することができます：
+また、これら2つのグラフを並べて比較することで、**需要と供給**がどのように一致するかを確認できます。
-ここから、ブロックスペースが十分に供給されている場合、ガス価格はブロックスペースへの需要に応じて上下することが分かります。
+したがって、利用可能な供給量を前提として、ガス価格はイーサリアムのブロックスペースへの需要の関数として理解できます。
-最後に、イーサリアムチェーンにおける1日のガス価格の平均値を調べたい場合、クエリ時間が非常に長くなるため、イーサリアム・ファウンデーションがトランザクション1件あたりに支払ったガス代の平均値を調べるようにクエリを絞り込みます。
+最後に、イーサリアムチェーンの1日あたりの平均ガス価格をクエリすることもできますが、クエリ時間が非常に長くなるため、イーサリアム財団によってトランザクションごとに支払われた平均ガス量にクエリを絞り込みます。
-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..52019bc5a88 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
@@ -2,11 +2,7 @@
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..dacd863cd4e 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
@@ -2,8 +2,7 @@
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になり、データをハッシュ化するコストを差し引いても、多くの用途にはまだ高すぎます。
これを解決するには、異なるデータのサブセットを繰り返しハッシュ化します。そうすることで、データを送信する必要が無い場合は、ハッシュを送信するだけで済むようになります。 これを行うには、次のようなマークルツリーを使用します。このツリーは、それぞれのノードがその下のノードのハッシュとなるデータ構造を持ちます。
-チェーン上に保存する必要があるのは、ルートハッシュのみとなります。 特定の値を証明するには、ルートのハッシュを得るために、その値と結合させる必要があるハッシュをすべて提供します。 例えば、`C`を証明するには、`D`、`H(A-B)`、`H(E-H)`を提供します。
+オンチェーンに保存する必要があるのはルートハッシュのみです。 特定の値を証明するには、ルートのハッシュを得るために、その値と結合させる必要があるハッシュをすべて提供します。 例えば、`C`を証明するには、`D`、`H(A-B)`、`H(E-H)`を提供します。
## 実装 {#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の整数乗ではない時は、空のブランチを処理する必要があります。 このプログラムでは、ゼロをプレースホルダーとして配置する方法を使っています。
-
+
```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..b9aacf10370 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`)でログインしてください。 プロンプトが表示されたら、デフォルトのパスワードを変更して保存してください。
-Grafanaのホームページに転送されます。 まず、ソースデータを設定します。 左のバーにあるConfigurationアイコンをクリックし、「Data sources」を選択します。
+Grafanaのホームページに転送されます。 まず、ソースデータを設定します。 左のバーにある設定アイコンをクリックし、「Data sources」を選択します。
-データソースを作成していないので、「Add data source」をクリックしてデータソースを定義します。
+まだデータソースは作成されていません。「Add data source」をクリックして定義します。
-今回の設定では、「InfluxDB」を選択して、次に進みます。
+この設定では、「InfluxDB」を選択して続行します。
-同一のマシンでツールを実行している場合、データソースの設定は非常に簡単です。 データベースにアクセスするには、InfluxDBのアドレスと詳細を設定する必要があります。 以下の画像を参照してください。
+同じマシンでツールを実行している場合、データソースの設定は非常に簡単です。 データベースにアクセスするには、InfluxDBのアドレスと詳細を設定する必要があります。 以下の画像を参照してください。
-設定が完了し、InfluxDBがアクセス可能になったら、「Save and test」をクリックして、確認のポップアップ画面が表示されるまで待ってください。
+すべてが完了し、InfluxDBにアクセスできるようになったら、「Save and test」をクリックし、確認のポップアップが表示されるのを待ちます。
-Grafanaの設定が完了し、InfluxDBのデータを読み込めるようになりました。 次に、データを分析して表示するダッシュボードを作成します。 ダッシュボードの属性はJSONファイルでエンコードされますので、誰でも簡単に作成し、インポートすることが可能です。 左のバーで、「Create and Import」をクリックしてください。
+GrafanaがInfluxDBからデータを読み取るように設定されました。 次に、データを解釈して表示するダッシュボードを作成する必要があります。 ダッシュボードのプロパティはJSONファイルにエンコードされており、誰でも簡単に作成してインポートできます。 左のバーで、「Create and Import」をクリックしてください。
-Gethのモニタリング用ダッシュボードの場合、[このダッシュボード](https://grafana.com/grafana/dashboards/13877/)のIDをコピーして、Grafanaの「Import page」にペーストしてください。 ダッシュボードを保存すると、以下のような状態になっているはずです：
+Gethのモニタリングダッシュボードには、[このダッシュボード](https://grafana.com/grafana/dashboards/13877/)のIDをコピーして、Grafanaの「Import page」に貼り付けてください。 ダッシュボードを保存すると、次のようになります:
-ダッシュボードの表示は変更可能です。 各パネルは、編集、移動、削除、追加が可能です。 各自の好みに合わせて、ダッシュボードの設定を変更してください。 あなた次第です！ ダッシュボードの詳細な仕組みについては、 [Grafanaのドキュメンテーション](https://grafana.com/docs/grafana/latest/dashboards/)を参照してください。 また、[アラート機能](https://grafana.com/docs/grafana/latest/alerting/)も参照するとよいでしょう。 これは、各指標において一定の値に達した場合、アラート通知を受け取るように設定するものです。 アラート通知は、様々な通信チャネルに対応しています。
+ダッシュボードは変更できます。 各パネルは、編集、移動、削除、追加が可能です。 設定は変更できます。 あなた次第です！ ダッシュボードの仕組みについて詳しくは、[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..397d82e24d1 100644
--- a/public/content/translations/ja/developers/tutorials/nft-minter/index.md
+++ b/public/content/translations/ja/developers/tutorials/nft-minter/index.md
@@ -3,12 +3,14 @@ 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,82 +107,82 @@ 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."
+ アセットのリンク、名前、説明を追加し、「ミント」を押すだけです。
{status}
@@ -189,51 +191,51 @@ return (
最後に、このミンター(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に相当します。
-ふう! これで、偽のお金を手に入れました。
ファイルを保存します。これで、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..16805c99e1c 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..7f43d57e5f2 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
@@ -3,38 +3,36 @@ title: "コントラクトのリバースエンジニアリング"
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つのオペコードが表示されるビューになります。
-
+
-ジャンプ (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へジャンプします。
-### 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であることに留意してください。これに関しては、後述します。
-
+
-次に「**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 |
-| 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 | |
+| オフセット | オペコード | スタック |
+| ----: | ------------ | ---------------------------------------------------------------------------------------------------- |
+| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AE | ISZERO | Value\*<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AF | PUSH2 0x01df | 0x01DF Value\*<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1B2 | JUMPI | |
-`Value*`の値が、2^256-CALLVALUE-1以下の場合にジャンプ(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にアクセスするとコントラクトのオペコードを入手
まとめると、最初のコードのフローチャートは次のようになります。
-
+
## 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します)。
-
+
-## アプリケーションバイナリインターフェース(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)へジャンプします。
-
+
## 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 |
-| 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を取得しています。
### 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..96c4bebdf08 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をノードにする方法
+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..60137cf9b52
--- /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..87d70ea6562
--- /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`に問題がある場合は、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..82687f55981 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
@@ -2,10 +2,7 @@
title: スマートコントラクトのセキュリティ・チェックリスト
description: セキュアなスマートコントラクトを作成するための推奨ワークフロー
author: "Trailofbits"
-tags:
- - "スマートコントラクト"
- - "セキュリティ"
- - "Solidity"
+tags: [ "スマート契約", "セキュリティ", "Solidity" ]
skill: intermediate
lang: ja
published: 2020-09-07
@@ -13,33 +10,33 @@ source: セキュアなコントラクトの開発
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-ethersjs/index.md b/public/content/translations/ja/developers/tutorials/send-token-ethersjs/index.md
index d55ad00cb25..4386dc6aa93 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コールを行い、ノードが結果を返すためです。
(,...`となります。
+ここでは、[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..9dd0b82ceb4 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
@@ -2,10 +2,7 @@
title: スマートコントラクトに対するセキュリティ・ガイドライン
description: Dapp開発時に参照すべきセキュリティ・ガイドラインのチェックリスト
author: "Trailofbits"
-tags:
- - "Solidity"
- - "スマートコントラクト"
- - "セキュリティ"
+tags: [ "Solidity", "スマート契約", "セキュリティ" ]
skill: intermediate
lang: ja
published: 2020-09-06
@@ -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..37bf51dcb9e
--- /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
+
{status}
-
+
)
```
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 16805c99e1c..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,6 +1,6 @@
---
title: "Optimism標準ブリッジコントラクトのウォークスルー"
-description: Optimismの標準ブリッジはどのように機能するのでしょうか？ なぜこのように機能するのでしょうか？
+description: "Optimismの標準ブリッジはどのように機能するのでしょうか？ なぜこのように機能するのでしょうか？"
author: Ori Pomerantz
tags: [ "Solidity", "ブリッジ", "レイヤー2" ]
skill: intermediate
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 7f43d57e5f2..de70fe292f9 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,6 +1,6 @@
---
title: "コントラクトのリバースエンジニアリング"
-description: ソースコードがない場合にコントラクトを理解する方法
+description: "ソースコードがない場合にコントラクトを理解する方法"
author: Ori Pomerantz
lang: ja
tags: [ "evm", "オペコード" ]
@@ -536,11 +536,11 @@ calldataload(4)がStorage[4]より小さい場合、次のコードになりま
| メソッド | 意味 |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| 送金 | 呼び出しによって提供された値を受け入れ、その額で`Value*`を増やす |
-| [splitter()](#splitter) | Storage[3] (プロキシアドレス)を返す |
+| [splitter()](#splitter) | Storage[3](プロキシアドレス)を返す |
| [currentWindow()](#currentwindow) | Storage[1]を返す |
| [merkleRoot()](#merkleroot) | Storage[0]を返す |
| [0x81e580d3](#0x81e580d3) | パラメータがStorage[4]より小さい場合、ルックアップテーブルにある値を返す |
-| [0x1f135823](#0x1f135823) | Storage[6] (別名、 Value\*) |
+| [0x1f135823](#0x1f135823) | Storage[6](別名、 Value\*) |
しかし、他の機能がStorage[3]のコントラクトによって提供されていることが分かっています。 そのコントラクトについて何か分かれば、手掛かりになるかもしれません。 幸いにも、これはブロックチェーンであり、少なくとも理論的にはすべてが既知です。 Storage[3]を設定するメソッドは何も見られなかったため、コンストラクタによって設定されているはずです。
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 96c4bebdf08..d74af809dbb 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,6 +1,6 @@
---
-title: Raspberry Pi 4でイーサリアムノードを実行する
-description: Raspberry Pi 4に書き込み、イーサネットケーブル、SSDをそれぞれ接続してから電源を入れるとRaspberry Pi 4がフルイーサリアムノードとバリデータになります。
+title: "Raspberry Pi 4でイーサリアムノードを実行する"
+description: "Raspberry Pi 4に書き込み、イーサネットケーブル、SSDをそれぞれ接続してから電源を入れるとRaspberry Pi 4がフルイーサリアムノードとバリデータになります。"
author: "EthereumOnArm"
tags: [ "クライアント", "実行レイヤー", "コンセンサスレイヤー", "ノード" ]
lang: ja
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
index 60137cf9b52..92dfedc20ec 100644
--- a/public/content/translations/ja/developers/tutorials/scam-token-tricks/index.md
+++ b/public/content/translations/ja/developers/tutorials/scam-token-tricks/index.md
@@ -1,6 +1,6 @@
---
title: "詐欺トークンで使われる手口と、その見分け方"
-description: このチュートリアルでは、詐欺トークンを分析し、詐欺師が使う手口、その実装方法、そしてそれを検出する方法を解説します。
+description: "このチュートリアルでは、詐欺トークンを分析し、詐欺師が使う手口、その実装方法、そしてそれを検出する方法を解説します。"
author: Ori Pomerantz
tags:
[
diff --git a/public/content/translations/ja/developers/tutorials/secret-state/index.md b/public/content/translations/ja/developers/tutorials/secret-state/index.md
index 87d70ea6562..d878fac89c8 100644
--- a/public/content/translations/ja/developers/tutorials/secret-state/index.md
+++ b/public/content/translations/ja/developers/tutorials/secret-state/index.md
@@ -1,6 +1,6 @@
---
-title: 秘密のステートにゼロ知識を使用する
-description: オンチェーンゲームは隠された情報を保持できないため、制限があります。 このチュートリアルを読むと、読者はゼロ知識証明とサーバーコンポーネントを組み合わせて、オフチェーンコンポーネントで秘密のステートを持つ検証可能なゲームを作成できるようになります。 これを行うための手法は、マインスイーパゲームを作成することで実証されます。
+title: "秘密のステートにゼロ知識を使用する"
+description: "オンチェーンゲームは隠された情報を保持できないため、制限があります。 このチュートリアルを読むと、読者はゼロ知識証明とサーバーコンポーネントを組み合わせて、オフチェーンコンポーネントで秘密のステートを持つ検証可能なゲームを作成できるようになります。 これを行うための手法は、マインスイーパゲームを作成することで実証されます。"
author: Ori Pomerantz
tags:
[
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 82687f55981..83e2dd08a81 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,12 +1,12 @@
---
-title: スマートコントラクトのセキュリティ・チェックリスト
-description: セキュアなスマートコントラクトを作成するための推奨ワークフロー
+title: "スマートコントラクトのセキュリティ・チェックリスト"
+description: "セキュアなスマートコントラクトを作成するための推奨ワークフロー"
author: "Trailofbits"
tags: [ "スマート契約", "セキュリティ", "Solidity" ]
skill: intermediate
lang: ja
published: 2020-09-07
-source: セキュアなコントラクトの開発
+source: "セキュアなコントラクトの開発"
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md
---
diff --git a/public/content/translations/ja/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/ja/developers/tutorials/send-token-ethersjs/index.md
index 4386dc6aa93..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,6 +1,6 @@
---
-title: ethers.jsを使用してトークンを送信する
-description: ethers.jsを使用してトークンを送信するための初心者向けガイド。
+title: "ethers.jsを使用してトークンを送信する"
+description: "ethers.jsを使用してトークンを送信するための初心者向けガイド。"
author: Kim YongJun
tags: [ "ETHERS.JS", "ERC-20", "トークン" ]
skill: beginner
diff --git a/public/content/translations/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
index 80ba2c7b48a..1db6357b879 100644
--- a/public/content/translations/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
+++ b/public/content/translations/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -1,12 +1,12 @@
---
-title: Web3を使用してトランザクションを送信する
+title: "Web3を使用してトランザクションを送信する"
description: "この初心者向けガイドでは、Web3を使用してイーサリアムトランザクションを送信する方法を説明します。 イーサリアムのブロックチェーンでは、作成、署名、およびブロードキャストという主に3つのステップを通じてトランザクションを送信します。 これら3つをすべて確認します。"
author: "Elan Halpern"
tags: [ "トランザクション", "web3.js", "Alchemy" ]
skill: beginner
lang: ja
published: 2020-11-04
-source: Alchemy ドキュメント
+source: "Alchemy ドキュメント"
sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum
---
diff --git a/public/content/translations/ja/developers/tutorials/server-components/index.md b/public/content/translations/ja/developers/tutorials/server-components/index.md
index 48935592b6e..9cb2d89b913 100644
--- a/public/content/translations/ja/developers/tutorials/server-components/index.md
+++ b/public/content/translations/ja/developers/tutorials/server-components/index.md
@@ -1,6 +1,6 @@
---
title: "Web3アプリ用のサーバーコンポーネントとエージェント"
-description: このチュートリアルを読むと、ブロックチェーン上のイベントをリッスンし、それに応じて独自のトランザクションで応答するTypeScriptサーバーを作成できるようになります。 これにより、(サーバーが単一障害点であるため) 集中型アプリケーションを作成できますが、Web3エンティティと対話できます。 同じ技術は、人間が介在することなくオンチェーンイベントに応答するエージェントを作成するためにも使用できます。
+description: "このチュートリアルを読むと、ブロックチェーン上のイベントをリッスンし、それに応じて独自のトランザクションで応答するTypeScriptサーバーを作成できるようになります。 これにより、(サーバーが単一障害点であるため) 集中型アプリケーションを作成できますが、Web3エンティティと対話できます。 同じ技術は、人間が介在することなくオンチェーンイベントに応答するエージェントを作成するためにも使用できます。"
author: Ori Pomerantz
lang: ja
diff --git a/public/content/translations/ja/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md b/public/content/translations/ja/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
index 712df6de909..8ca9deff4bb 100644
--- a/public/content/translations/ja/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
+++ b/public/content/translations/ja/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
@@ -1,6 +1,6 @@
---
-title: JavaScriptでイーサリアムブロックチェーンを使用するためにweb3.jsをセットアップする
-description: JavaScriptアプリケーションからイーサリアムブロックチェーンと対話するために、web3.jsライブラリをセットアップおよび設定する方法を学びます。
+title: "JavaScriptでイーサリアムブロックチェーンを使用するためにweb3.jsをセットアップする"
+description: "JavaScriptアプリケーションからイーサリアムブロックチェーンと対話するために、web3.jsライブラリをセットアップおよび設定する方法を学びます。"
author: "jdourlens"
tags: [ "web3.js", "JavaScript" ]
skill: beginner
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 d67d1b19467..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,6 +1,6 @@
---
title: "コールデータを最適化するための簡潔なABI"
-description: オプティミスティック・ロールアップのためのスマートコントラクトの最適化
+description: "オプティミスティック・ロールアップのためのスマートコントラクトの最適化"
author: Ori Pomerantz
lang: ja
tags: [ "レイヤー2" ]
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 9dd0b82ceb4..a45857a18c2 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,12 +1,12 @@
---
-title: スマートコントラクトに対するセキュリティ・ガイドライン
-description: Dapp開発時に参照すべきセキュリティ・ガイドラインのチェックリスト
+title: "スマートコントラクトに対するセキュリティ・ガイドライン"
+description: "Dapp開発時に参照すべきセキュリティ・ガイドラインのチェックリスト"
author: "Trailofbits"
tags: [ "Solidity", "スマート契約", "セキュリティ" ]
skill: intermediate
lang: ja
published: 2020-09-06
-source: セキュアなコントラクトの構築
+source: "セキュアなコントラクトの構築"
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
---
diff --git a/public/content/translations/ja/developers/tutorials/the-graph-fixing-web3-data-querying/index.md b/public/content/translations/ja/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
index 8636fc53430..58a4b126ee4 100644
--- a/public/content/translations/ja/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
+++ b/public/content/translations/ja/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
@@ -1,6 +1,6 @@
---
title: "The Graph: Web3データクエリ問題の解決"
-description: ブロックチェーンは、SQLのないデータベースのようなものです。 すべてのデータはありますが、アクセスする方法がありません。 The GraphとGraphQLでこの問題を解決する方法をご紹介します。
+description: "ブロックチェーンは、SQLのないデータベースのようなものです。 すべてのデータはありますが、アクセスする方法がありません。 The GraphとGraphQLでこの問題を解決する方法をご紹介します。"
author: Markus Waas
lang: ja
tags: [ "Solidity", "スマート契約", "クエリ", "the graph", "react" ]
diff --git a/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md
index 3c079a0fc27..9408b8ed064 100644
--- a/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md
+++ b/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md
@@ -1,12 +1,12 @@
---
-title: トークン統合チェックリスト
-description: トークンとやり取りをする際の考慮事項のチェックリスト
+title: "トークン統合チェックリスト"
+description: "トークンとやり取りをする際の考慮事項のチェックリスト"
author: "Trailofbits"
lang: ja
tags: [ "Solidity", "スマート契約", "セキュリティ", "トークン" ]
skill: intermediate
published: 2020-08-13
-source: セキュアなコントラクトの開発
+source: "セキュアなコントラクトの開発"
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md
---
diff --git a/public/content/translations/ja/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md b/public/content/translations/ja/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
index 3fd83fc9382..8b887dbfbaf 100644
--- a/public/content/translations/ja/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
+++ b/public/content/translations/ja/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
@@ -1,6 +1,6 @@
---
-title: SolidityスマートコントラクトによるERC-20トークンの転送と承認
-description: Solidityを使用してERC-20トークンの転送と承認を処理するDEXスマートコントラクトを構築します。
+title: "SolidityスマートコントラクトによるERC-20トークンの転送と承認"
+description: "Solidityを使用してERC-20トークンの転送と承認を処理するDEXスマートコントラクトを構築します。"
author: "jdourlens"
tags: [ "スマート契約", "トークン", "Solidity", "ERC-20" ]
skill: intermediate
diff --git a/public/content/translations/ja/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md b/public/content/translations/ja/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
index 0bdfbe50462..be7b4dc1f7d 100644
--- a/public/content/translations/ja/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
+++ b/public/content/translations/ja/developers/tutorials/understand-the-erc-20-token-smart-contract/index.md
@@ -1,6 +1,6 @@
---
-title: ERC-20トークンのスマートコントラクトを理解する
-description: 完全なSolidityスマートコントラクトの例と解説で、ERC-20トークン標準の実装方法を学びます。
+title: "ERC-20トークンのスマートコントラクトを理解する"
+description: "完全なSolidityスマートコントラクトの例と解説で、ERC-20トークン標準の実装方法を学びます。"
author: "jdourlens"
tags: [ "スマート契約", "トークン", "Solidity", "ERC-20" ]
skill: beginner
diff --git a/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
index 27b93b2a026..37646e25947 100644
--- a/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
+++ b/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
@@ -1,6 +1,6 @@
---
title: "Uniswap-v2コントラクトの詳細解説"
-description: Uniswap-v2コントラクトはどのように機能するのか? なぜそのように記述されているのか?
+description: "Uniswap-v2コントラクトはどのように機能するのか? なぜそのように記述されているのか?"
author: Ori Pomerantz
tags: [ "Solidity" ]
skill: intermediate
diff --git a/public/content/translations/ja/developers/tutorials/using-websockets/index.md b/public/content/translations/ja/developers/tutorials/using-websockets/index.md
index 1e5719a8442..f63eaf04666 100644
--- a/public/content/translations/ja/developers/tutorials/using-websockets/index.md
+++ b/public/content/translations/ja/developers/tutorials/using-websockets/index.md
@@ -1,11 +1,11 @@
---
-title: WebSocketを利用する
-description: WebSocketsとAlchemyを使って、JSON-RPCリクエストを作成し、イベントを講読するためのガイド
+title: "WebSocketを利用する"
+description: "WebSocketsとAlchemyを使って、JSON-RPCリクエストを作成し、イベントを講読するためのガイド"
author: "Elan Halpern"
lang: ja
tags: [ "Alchemy", "WebSockets", "クエリ", "JavaScript" ]
skill: beginner
-source: Alchemy ドキュメント
+source: "Alchemy ドキュメント"
sourceUrl: https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3
published: 2020-12-01
---
diff --git a/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md b/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
index 84b32e88c69..49aee5531c2 100644
--- a/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
+++ b/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
@@ -1,6 +1,6 @@
---
title: "Waffle: 動的モッキングとコントラクト呼び出しのテスト"
-description: 動的モッキングとコントラクト呼び出しのテストのためのWaffle上級チュートリアル
+description: "動的モッキングとコントラクト呼び出しのテストのためのWaffle上級チュートリアル"
author: "Daniel Izdebski"
tags: [ "waffle", "スマート契約", "Solidity", "テスト", "モックアップ作成" ]
skill: intermediate
diff --git a/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md b/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
index 5c3f6305b10..d499f75c2e9 100644
--- a/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
+++ b/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
@@ -1,6 +1,6 @@
---
title: "WaffleでHardhatとethersを使って「Hello world!」と出力するチュートリアル"
-description: Hardhatとethers.jsを使って、はじめてのWaffleプロジェクトを作成する
+description: "Hardhatとethers.jsを使って、はじめてのWaffleプロジェクトを作成する"
author: "MiZiet"
tags:
[
diff --git a/public/content/translations/ja/developers/tutorials/waffle-test-simple-smart-contract/index.md b/public/content/translations/ja/developers/tutorials/waffle-test-simple-smart-contract/index.md
index 4dc17f12d27..f1460168153 100644
--- a/public/content/translations/ja/developers/tutorials/waffle-test-simple-smart-contract/index.md
+++ b/public/content/translations/ja/developers/tutorials/waffle-test-simple-smart-contract/index.md
@@ -1,6 +1,6 @@
---
-title: Waffleライブラリを使用したシンプルなスマートコントラクトのテスト
-description: 初心者用チュートリアル
+title: "Waffleライブラリを使用したシンプルなスマートコントラクトのテスト"
+description: "初心者用チュートリアル"
author: Ewa Kowalska
tags: [ "スマート契約", "Solidity", "Waffle", "テスト" ]
skill: beginner
diff --git a/public/content/translations/ja/developers/tutorials/yellow-paper-evm/index.md b/public/content/translations/ja/developers/tutorials/yellow-paper-evm/index.md
index cce25126e57..00dad7ce13b 100644
--- a/public/content/translations/ja/developers/tutorials/yellow-paper-evm/index.md
+++ b/public/content/translations/ja/developers/tutorials/yellow-paper-evm/index.md
@@ -1,6 +1,6 @@
---
-title: イエローペーパーにおけるEVM仕様の理解
-description: イーサリアムの正式な仕様であるイエローペーパーでのイーサリアム仮想マシン(EVM)についての説明を理解する。
+title: "イエローペーパーにおけるEVM仕様の理解"
+description: "イーサリアムの正式な仕様であるイエローペーパーでのイーサリアム仮想マシン(EVM)についての説明を理解する。"
author: "qbzzt"
tags: [ "evm" ]
skill: intermediate
diff --git a/public/content/translations/ja/eips/index.md b/public/content/translations/ja/eips/index.md
index d8d5866f0c3..0db631eecd3 100644
--- a/public/content/translations/ja/eips/index.md
+++ b/public/content/translations/ja/eips/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアム改善提案(EIP)
-description: EIPを理解するために必要な基本情報
+title: "イーサリアム改善提案(EIP)"
+description: "EIPを理解するために必要な基本情報"
lang: ja
---
diff --git a/public/content/translations/ja/energy-consumption/index.md b/public/content/translations/ja/energy-consumption/index.md
index d8be792251d..17f8523dbc3 100644
--- a/public/content/translations/ja/energy-consumption/index.md
+++ b/public/content/translations/ja/energy-consumption/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアムのエネルギー消費
-description: イーサリアムのエネルギー消費を理解するために必要な基本的な情報
+title: "イーサリアムのエネルギー消費"
+description: "イーサリアムのエネルギー消費を理解するために必要な基本的な情報"
lang: ja
---
diff --git a/public/content/translations/ja/eth/supply/index.md b/public/content/translations/ja/eth/supply/index.md
index d100c480197..45f3c8b9bcc 100644
--- a/public/content/translations/ja/eth/supply/index.md
+++ b/public/content/translations/ja/eth/supply/index.md
@@ -1,6 +1,6 @@
---
-title: ETHの供給と発行の理解
-description: ETHの供給と発行に関する初心者向けのガイドで、EIP、PoS、EIP-1559などの主要な概念を網羅しています。
+title: "ETHの供給と発行の理解"
+description: "ETHの供給と発行に関する初心者向けのガイドで、EIP、PoS、EIP-1559などの主要な概念を網羅しています。"
lang: ja
---
diff --git a/public/content/translations/ja/ethereum-forks/index.md b/public/content/translations/ja/ethereum-forks/index.md
index fecdafb327b..b9e71c30548 100644
--- a/public/content/translations/ja/ethereum-forks/index.md
+++ b/public/content/translations/ja/ethereum-forks/index.md
@@ -1,6 +1,6 @@
---
-title: 全イーサリアムフォークのタイムライン(2014年～現在)
-description: 主要なマイルストーン、リリース、フォークを含むイーサリアムブロックチェーンの歴史。
+title: "全イーサリアムフォークのタイムライン(2014年～現在)"
+description: "主要なマイルストーン、リリース、フォークを含むイーサリアムブロックチェーンの歴史。"
lang: ja
sidebarDepth: 1
---
@@ -16,7 +16,6 @@ sidebarDepth: 1
従来の中央集権型のソフトウェアにおいてアップグレードが必要になった場合、企業はエンドユーザのために新バージョンを公開します。 中央集権型の所有権がないブロックチェーンでは、仕組みが異なります。 [イーサリアムクライアント](/developers/docs/nodes-and-clients/)が新しいフォークルールを実装するには、ソフトウェアのアップデートが必要となります。 さらに、ブロック作成者(プルーフ・オブ・ワークの世界ではマイナー、プルーフ・オブ・ステークの世界ではバリデータ)とノードは、ブロックを作成し、新しいルールに照らし合わせて検証しなければなりません。 [コンセンサスメカニズムに関する詳細](/developers/docs/consensus-mechanisms/)
これらのルール変更は、ネットワークに一時的な分裂を生じさせる可能性があります。 新規ブロックは、新しいルールもしくは古いルールに基づいて生成できます。 フォークは事前に合意されることが一般的で、クライアントが一斉に変更を採用し、アップグレードされたフォークがメインチェーンとなります。 しかし、まれにフォークをめぐる意見の相違がネットワークの永久的な分裂を引き起こしてしまうことがあります。もっとも有名な例が、DAOフォークによるEthereum Classicの誕生です。
-
@@ -62,7 +61,6 @@ Ethereumの基礎となるソフトウェアは二つに分けることができ
| Cancun | Deneb | "Dencun" |
| Prague | Electra | "Pectra" |
| Osaka | Fulu | "Fusaka" |
-
特に重要な過去のアップグレードに関する情報に直接移動する：[The Beacon Chain](/roadmap/beacon-chain/)、[The Merge](/roadmap/merge/)、[EIP-1559](#london)
@@ -116,7 +114,6 @@ Ethereumの基礎となるソフトウェアは二つに分けることができ
EIP-2935 - ステートに過去のブロックハッシュを保存
EIP-7549 - committee indexを署名付きアテステーションの外部へ移動
-
- [Pectra.wtf](https://pectra.wtf)
@@ -148,7 +145,6 @@ Cancunアップグレードには、Denebのコンセンサスアップグレー
EIP-6780 - SELFDESTRUCTの使用を同一のトランザクションに制限
EIP-7516 - オペコードBLOBBASEFEE
-
- [レイヤー2ロールアップ](/layer-2/)
@@ -173,7 +169,6 @@ EIP-7514では、バリデータがネットワークに参加できる「チャ
EIP-7045 - 認証スロットの最大アテステーションを拡張
EIP-7514 - チャーンの最大エポック数の制限
-
- [Denebアップグレードの仕様を読む](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
@@ -200,7 +195,6 @@ EIP-7514では、バリデータがネットワークに参加できる「チャ
EIP-4895 – 操作としてのビーコンチェーンプッシュ引き出し
EIP-6049 - SELFDESTRUCTの廃止
-
- [Shanghaiアップグレードの仕様を読む](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
@@ -236,7 +230,6 @@ Parisアップグレードは、プルーフ・オブ・ワーク・ブロック
EIP-3675 – コンセンサスをアップグレードし、プルーフ・オブ・ステークにする。
EIP-4399 – オペコードDIFFICULTYをPREVRANDAOに置き換える。
-
---
@@ -268,7 +261,6 @@ Gray Glacierネットワークアップグレードは、[ディフィカルテ
- EIP-5133 – 2022年9月まで難易度爆弾を遅らせる。
-
- EIP-4345 – 2022年6月まで難易度爆弾を遅らせる。
-
---
@@ -349,7 +340,6 @@ Londonアップグレードで[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559
EIP-3541 - 0xEFで始まるコントラクトのデプロイを防止。
EIP-3554 – 氷河期を2021年12月まで遅らせる。
-
---
@@ -373,7 +363,6 @@ Londonアップグレードで[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559
EIP-2929 – 状態にアクセスするオペコードのガス代の引き上げ。
EIP-2930 – オプションのアクセスリストの追加。
-
- EIP-2384 – 難易度爆弾をさらに400万ブロック(約611日)遅らせる。
-
EIP-2028 – CallDataのコストを削減し、ブロック内により多くのデータを格納できるようにする提案。これは[レイヤー2スケーリング](/developers/docs/scaling/#layer-2-scaling)に有効
EIP-2200 – その他のオペコードのガス価格の変更。
-
---
@@ -489,7 +476,6 @@ Muir Glacierフォークでは、[ディフィカルティボム](/glossary/#dif
EIP-1052 — 他のコントラクトのコードのハッシュ値を取得するための EXTCODEHASH 命令を導入する。
EIP-1234 – ブロックチェーンがフリーズしないことを確認。また、ブロック報酬を3ETHから2ETHへ減額。
-
EIP-100 – 難易度調整の式を変更。
EIP-649 – [ディフィカルティボム](/glossary/#difficulty-bomb)を1年間延期し、ブロック報酬を5ETHから3ETHに減少させる提案。
-
EIP-161 – DOS攻撃によって加えられた空アカウントの削除を可能に。
EIP-170 – 最大コードサイズの変更。これにより、ブロックチェーンのコントラクトのサイズは、最大24576バイトに。
-
---
@@ -576,7 +560,6 @@ Muir Glacierフォークでは、[ディフィカルティボム](/glossary/#dif
EIP-150 – スパム攻撃に使うことができるオペコードのガス代を引き上げ。
EIP-158 – イーサリアムの以前のバージョンの欠陥により引き起こされた、非常に抵いコストでステートに置かれた大量の空アカウントを削除して、ステートサイズを縮小。
-
---
@@ -614,7 +597,6 @@ DAO事件はプロトコルの不具合によるものではなかったため
EIP-7 – 新しいオペコードDELEGATECALLの追加。
EIP-8 – devp2p前方向互換性要件の導入。
-
- ウォレットはインストールしましたか？
使い方を学びましょう。
+ ウォレットはインストールしましたか？
使い方を学びましょう。
+
ウォレットの使用方法
diff --git a/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md b/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md
index d4996b7a9c4..f1cd1cf77dc 100644
--- a/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md
+++ b/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md
@@ -1,6 +1,6 @@
---
-title: 詐欺トークンの見分け方
-description: 詐欺トークンの概要、正当なトークンに見せかける仕組み、詐欺に遭わない方法について理解を深める。
+title: "詐欺トークンの見分け方"
+description: "詐欺トークンの概要、正当なトークンに見せかける仕組み、詐欺に遭わない方法について理解を深める。"
lang: ja
---
@@ -20,7 +20,6 @@ title="ARBとは？"
contentPreview=''>
Arbitrumは[Optimistic Rollups](/developers/docs/scaling/optimistic-rollups/)を開発・管理する組織です。 当初、営利企業として立ち上げられたArbitrumは、その後、分散型組織に切り替わりました。 そのプロセスの一環として、取引可能な[ガバナンストークン](/dao/#token-based-membership)を発行しました。
-
イーサリアムでは、暗号資産がERC-20に準拠していない場合、「w」から始まる「ラップ」版の暗号資産を作成する慣習があります。 例として、ビットコインに対するwBTCやイーサリアムに対するwETHがあります。
すでにイーサリアム上に存在するERC-20トークンのラップ版を作成するのは無意味なことですが、詐欺師は実際の意味よりも、トークンがいかにもっともらしく見えるかということを重視しています。
-
## 詐欺トークンの仕組み {#how-do-scam-tokens-work}
@@ -42,7 +40,6 @@ title="スマートコントラクトとは？"
contentPreview=''>
[スマートコントラクト](/developers/docs/smart-contracts/)はイーサリアムブロックチェーン上で実行されるプログラムです。 例えば、すべてのERC-20トークンは、スマートコントラクトとして実装できます。
-
具体的には、Arbitrumは`ARB`というシンボルを使用するコントラクトをデプロイしました。 しかしこの方法は、他者による、同じシンボルまたは類似のシンボルを用いたスマートコントラクトのデプロイを防ぐわけではありません。 コントラクトの記述者は誰でも、その内容を設定することができます。
diff --git a/public/content/translations/ja/guides/how-to-revoke-token-access/index.md b/public/content/translations/ja/guides/how-to-revoke-token-access/index.md
index ab1c27f864d..9fb9506ecb6 100644
--- a/public/content/translations/ja/guides/how-to-revoke-token-access/index.md
+++ b/public/content/translations/ja/guides/how-to-revoke-token-access/index.md
@@ -1,6 +1,6 @@
---
-title: 暗号資金へのスマートコントラクトのアクセスを無効にする方法
-description: 悪意のある暗号資産へのスマートコントラクトのアクセスを無効にする方法の解説
+title: "暗号資金へのスマートコントラクトのアクセスを無効にする方法"
+description: "悪意のある暗号資産へのスマートコントラクトのアクセスを無効にする方法の解説"
lang: ja
---
@@ -49,7 +49,8 @@ lang: ja
- さらに詳しく知りたいですか？
+ さらに詳しく知りたいですか？
+
他のガイドを見る
diff --git a/public/content/translations/ja/guides/how-to-swap-tokens/index.md b/public/content/translations/ja/guides/how-to-swap-tokens/index.md
index 976dc03eff9..74d2cc486e3 100644
--- a/public/content/translations/ja/guides/how-to-swap-tokens/index.md
+++ b/public/content/translations/ja/guides/how-to-swap-tokens/index.md
@@ -1,6 +1,6 @@
---
-title: トークンの交換方法
-description: イーサリアムでトークンを交換する方法のガイド
+title: "トークンの交換方法"
+description: "イーサリアムでトークンを交換する方法のガイド"
lang: ja
---
@@ -52,7 +52,8 @@ lang: ja
- さらに詳しく知りたいですか？
+ さらに詳しく知りたいですか？
+
他のガイドを見る
diff --git a/public/content/translations/ja/guides/how-to-use-a-bridge/index.md b/public/content/translations/ja/guides/how-to-use-a-bridge/index.md
index 4a873bf2fa5..2851393345a 100644
--- a/public/content/translations/ja/guides/how-to-use-a-bridge/index.md
+++ b/public/content/translations/ja/guides/how-to-use-a-bridge/index.md
@@ -1,6 +1,6 @@
---
-title: トークンをレイヤー2にブリッジする方法
-description: ブリッジを使用してイーサリアムからレイヤー2にトークンを移動させる方法。
+title: "トークンをレイヤー2にブリッジする方法"
+description: "ブリッジを使用してイーサリアムからレイヤー2にトークンを移動させる方法。"
lang: ja
---
@@ -54,7 +54,8 @@ lang: ja
- さらに詳しく知りたいですか？
+ さらに詳しく知りたいですか？
+
他のガイドを見る
diff --git a/public/content/translations/ja/guides/how-to-use-a-wallet/index.md b/public/content/translations/ja/guides/how-to-use-a-wallet/index.md
index f39bf88e46c..619b5f34e86 100644
--- a/public/content/translations/ja/guides/how-to-use-a-wallet/index.md
+++ b/public/content/translations/ja/guides/how-to-use-a-wallet/index.md
@@ -1,7 +1,7 @@
---
-title: ウォレットの使用方法
-metaTitle: イーサリアムウォレットの使い方 | ステップ・バイ・ステップ
-description: トークンの送信、受信、Web3 プロジェクトへの接続方法を説明するガイド。
+title: "ウォレットの使用方法"
+metaTitle: "イーサリアムウォレットの使い方 | ステップ・バイ・ステップ"
+description: "トークンの送信、受信、Web3 プロジェクトへの接続方法を説明するガイド。"
lang: ja
---
@@ -65,7 +65,8 @@ lang: ja
- さらに詳しく知りたいですか？
+ さらに詳しく知りたいですか？
+
他のガイドを見る
diff --git a/public/content/translations/ja/guides/index.md b/public/content/translations/ja/guides/index.md
index 8c42d707f6a..a0be1fc964d 100644
--- a/public/content/translations/ja/guides/index.md
+++ b/public/content/translations/ja/guides/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアムのガイド
-description: 初心者向けのイーサリアムの基本的な使用方法を解説する実用的なガイド一覧。
+title: "イーサリアムのガイド"
+description: "初心者向けのイーサリアムの基本的な使用方法を解説する実用的なガイド一覧。"
lang: ja
---
diff --git a/public/content/translations/ja/nft/index.md b/public/content/translations/ja/nft/index.md
index 457fa19afe4..cde04763129 100644
--- a/public/content/translations/ja/nft/index.md
+++ b/public/content/translations/ja/nft/index.md
@@ -1,16 +1,16 @@
---
-title: 非代替トークン (NFT)
-metaTitle: NFTとは? | 利点と利用法
-description: イーサリアムにおける非代替性トークン(NFT)の概要
+title: "非代替トークン (NFT)"
+metaTitle: "NFTとは? | 利点と利用法"
+description: "イーサリアムにおける非代替性トークン(NFT)の概要"
lang: ja
template: use-cases
emoji: ":frame_with_picture:"
sidebarDepth: 2
image: /images/infrastructure_transparent.png
-alt: ホログラムを介して表示されているETHロゴ
-summaryPoint1: イーサリアムベースのアセットとして、唯一無二なものをトークンとして表現する方法。
-summaryPoint2: NFTは、これまで以上に多くのコンテンツ・クリエイターを後押ししています。
-summaryPoint3: イーサリアムブロックチェーン上のスマートコントラクトを利用。
+alt: "ホログラムを介して表示されているETHロゴ"
+summaryPoint1: "イーサリアムベースのアセットとして、唯一無二なものをトークンとして表現する方法。"
+summaryPoint2: "NFTは、これまで以上に多くのコンテンツ・クリエイターを後押ししています。"
+summaryPoint3: "イーサリアムブロックチェーン上のスマートコントラクトを利用。"
---
## NFTとは? {#what-are-nfts}
@@ -58,7 +58,8 @@ NFTは以下のような多数の用途に使用されます。
- 非代替性トークン(NFT)アート/コレクティブルを探す、買う、作る
+ 非代替性トークン(NFT)アート/コレクティブルを探す、買う、作る
+
NFTアートを探す
diff --git a/public/content/translations/ja/payments/index.md b/public/content/translations/ja/payments/index.md
index 3acf9130224..e8eb078aba5 100644
--- a/public/content/translations/ja/payments/index.md
+++ b/public/content/translations/ja/payments/index.md
@@ -1,16 +1,16 @@
---
-title: イーサリアム支払い
-metaTitle: イーサリアム上での支払い
-description: イーサリアム上での支払いの概要
+title: "イーサリアム支払い"
+metaTitle: "イーサリアム上での支払い"
+description: "イーサリアム上での支払いの概要"
lang: ja
template: use-cases
emoji: ":frame_with_picture:"
sidebarDepth: 2
image: /images/impact_transparent.png
-alt: Ethのロゴが表示されており、差し出す手が描かれている。
-summaryPoint1: お金が情報のように自由に動く世界
-summaryPoint2: 誰もが利用できる、オープンでグローバルな、国境を越えた取引を可能にする世界
-summaryPoint3: 1分以内に受け取れる支払い
+alt: "Ethのロゴが表示されており、差し出す手が描かれている。"
+summaryPoint1: "お金が情報のように自由に動く世界"
+summaryPoint2: "誰もが利用できる、オープンでグローバルな、国境を越えた取引を可能にする世界"
+summaryPoint3: "1分以内に受け取れる支払い"
---
毎日、何百万人もの人々が同じ課題に直面しています。国境を越えてお金を動かすのは遅く、費用がかかり、しばしば苛立たしいものです。 バリ島のフリーランサーは、ニューヨークのクライアントからの支払いが決済されるまで数日間待っている。 この問題は特に、銀行インフラが限られた地域に住む人々に影響を与えており、彼らがグローバル経済に参加することを困難にしています。
@@ -20,7 +20,6 @@ summaryPoint3: 1分以内に受け取れる支払い
-
## 送金：より安価な国際送金 {#remittances}
@@ -61,7 +60,8 @@ summaryPoint3: 1分以内に受け取れる支払い
- 今日からウォレットアプリであなたのイーサリアムアカウントを作成しましょう。
+ 今日からウォレットアプリであなたのイーサリアムアカウントを作成しましょう。
+
始める
@@ -142,7 +142,6 @@ summaryPoint3: 1分以内に受け取れる支払い
-
## イーサリアム 対 法定通貨 {#ethereum-vs-fiat}
@@ -189,7 +188,6 @@ summaryPoint3: 1分以内に受け取れる支払い
-
法定通貨には広く受け入れられていることや安定性といった利点がありますが、イーサリアムには特定の取引において魅力的な選択肢となる独自の利点があります。
@@ -199,7 +197,8 @@ summaryPoint3: 1分以内に受け取れる支払い
- さあ、自分のイーサリアムアカウントを作成する時です。
+ さあ、自分のイーサリアムアカウントを作成する時です。
+
始めよう！
diff --git a/public/content/translations/ja/prediction-markets/index.md b/public/content/translations/ja/prediction-markets/index.md
index 51c6f67782c..446c44e8374 100644
--- a/public/content/translations/ja/prediction-markets/index.md
+++ b/public/content/translations/ja/prediction-markets/index.md
@@ -1,11 +1,11 @@
---
-title: 予測市場
+title: "予測市場"
lang: ja
template: use-cases
image: /images/use-cases/prediction-markets.png
sidebarDepth: 2
-summaryPoint1: 金融的インセンティブを受け取って正確な予測を実行
-summaryPoint2: 将来のイベントに関する高品質の予測
+summaryPoint1: "金融的インセンティブを受け取って正確な予測を実行"
+summaryPoint2: "将来のイベントに関する高品質の予測"
buttons:
- content: もっと詳しく
toId: how-prediction-markets-work
diff --git a/public/content/translations/ja/privacy/index.md b/public/content/translations/ja/privacy/index.md
index 40371bca86c..074df26c93b 100644
--- a/public/content/translations/ja/privacy/index.md
+++ b/public/content/translations/ja/privacy/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアム上のプライバシー
-description: イーサリアム上でプライバシーを保護するためのツールと技術
+title: "イーサリアム上のプライバシー"
+description: "イーサリアム上でプライバシーを保護するためのツールと技術"
lang: ja
---
diff --git a/public/content/translations/ja/real-world-assets/index.md b/public/content/translations/ja/real-world-assets/index.md
index bed0ccf93e5..e09365b11b2 100644
--- a/public/content/translations/ja/real-world-assets/index.md
+++ b/public/content/translations/ja/real-world-assets/index.md
@@ -1,16 +1,16 @@
---
-title: リアルワールドアセット(RWAs)
-metaTitle: RWAとは何か？ | 実世界資産の利点と用途
-description: イーサリアムにおけるリアルワールドアセットの概要
+title: "リアルワールドアセット(RWAs)"
+metaTitle: "RWAとは何か？ | 実世界資産の利点と用途"
+description: "イーサリアムにおけるリアルワールドアセットの概要"
lang: ja
template: use-cases
emoji: ":house_buildings:"
image: /images/man-and-dog-playing.png
-alt: 男性と犬が遊んでいる様子。
+alt: "男性と犬が遊んでいる様子。"
sidebarDepth: 2
-summaryPoint1: 価値のあるコモディティをデジタルトークンに変換する方法。
-summaryPoint2: 現在、不動産全体やアイテム全体を購入することなく、実際の物や資産の一部を所有できるようになりました。
-summaryPoint3: 伝統的な金融とブロックチェーンエコシステムを結びつけます。
+summaryPoint1: "価値のあるコモディティをデジタルトークンに変換する方法。"
+summaryPoint2: "現在、不動産全体やアイテム全体を購入することなく、実際の物や資産の一部を所有できるようになりました。"
+summaryPoint3: "伝統的な金融とブロックチェーンエコシステムを結びつけます。"
---
リアルワールドアセット（RWAs）とは、不動産、金、株式、美術品、機械、収集品など、既存の形態の富を表すトークンです。 これらのアイテムをトークン化することで、デジタル形式に変換され、複数の所有者の間で分割したり、取引を容易にしたりすることができます。
diff --git a/public/content/translations/ja/refi/index.md b/public/content/translations/ja/refi/index.md
index 30a736e84ad..fe5cf103ad1 100644
--- a/public/content/translations/ja/refi/index.md
+++ b/public/content/translations/ja/refi/index.md
@@ -1,15 +1,15 @@
---
-title: 再生金融(ReFi)
-description: ReFiの概要と現在のユースケース。
+title: "再生金融(ReFi)"
+description: "ReFiの概要と現在のユースケース。"
lang: ja
template: use-cases
emoji: ":recycle:"
sidebarDepth: 2
image: /images/future_transparent.png
alt: ""
-summaryPoint1: 再生原理に基づく代替経済システム
-summaryPoint2: イーサリアムを利用して、気候変動など世界レベルの協調的危機を解決しようとする試み
-summaryPoint3: 検証済み炭素クレジットのような生態系利益資産を飛躍的に拡大するツール
+summaryPoint1: "再生原理に基づく代替経済システム"
+summaryPoint2: "イーサリアムを利用して、気候変動など世界レベルの協調的危機を解決しようとする試み"
+summaryPoint3: "検証済み炭素クレジットのような生態系利益資産を飛躍的に拡大するツール"
---
## ReFiとは {#what-is-refi}
diff --git a/public/content/translations/ja/restaking/index.md b/public/content/translations/ja/restaking/index.md
index 521b5db38e2..9a3818e379a 100644
--- a/public/content/translations/ja/restaking/index.md
+++ b/public/content/translations/ja/restaking/index.md
@@ -1,14 +1,14 @@
---
-title: リステーキング
-metaTitle: リステーキングとは？ | リステーキングのメリットと活用法
-description: ステークされたETHを使用して他の分散型サービスを保護し、追加の報酬を獲得します。
+title: "リステーキング"
+metaTitle: "リステーキングとは？ | リステーキングのメリットと活用法"
+description: "ステークされたETHを使用して他の分散型サービスを保護し、追加の報酬を獲得します。"
lang: ja
template: use-cases
emoji: ":recycle:"
image: /images/use-cases/restaking.png
-alt: イーサリアムにおけるリステーキングの視覚的表現。
+alt: "イーサリアムにおけるリステーキングの視覚的表現。"
sidebarDepth: 2
-summaryPoint1: ステークされたETHを使用して他の分散型サービスを保護し、追加の報酬を獲得します。
+summaryPoint1: "ステークされたETHを使用して他の分散型サービスを保護し、追加の報酬を獲得します。"
buttons:
- content: リステーキングとは？
toId: what-is-restaking
diff --git a/public/content/translations/ja/roadmap/account-abstraction/index.md b/public/content/translations/ja/roadmap/account-abstraction/index.md
index c810eb22483..16791ba8111 100644
--- a/public/content/translations/ja/roadmap/account-abstraction/index.md
+++ b/public/content/translations/ja/roadmap/account-abstraction/index.md
@@ -1,6 +1,6 @@
---
-title: アカウント抽象化
-description: ユーザーアカウントをよりシンプルかつ安全にするためのイーサリアムの計画概要
+title: "アカウント抽象化"
+description: "ユーザーアカウントをよりシンプルかつ安全にするためのイーサリアムの計画概要"
lang: ja
summaryPoints:
- アカウント抽象化により、スマートコントラクトウォレットの構築が大幅に簡素化されます。
diff --git a/public/content/translations/ja/roadmap/beacon-chain/index.md b/public/content/translations/ja/roadmap/beacon-chain/index.md
index 1646c48fb42..338672a68f8 100644
--- a/public/content/translations/ja/roadmap/beacon-chain/index.md
+++ b/public/content/translations/ja/roadmap/beacon-chain/index.md
@@ -1,13 +1,13 @@
---
-title: ビーコンチェーン
-description: ビーコンチェーン - プルーフ・オブ・ステークのイーサリアム導入アップグレード
+title: "ビーコンチェーン"
+description: "ビーコンチェーン - プルーフ・オブ・ステークのイーサリアム導入アップグレード"
lang: ja
template: upgrade
image: /images/upgrades/core.png
alt:
-summaryPoint1: イーサリアムエコシステムにプルーフ・オブ・ステークの導入を可能にしたのが、ビーコンチェーンです。
-summaryPoint2: 2022年9月にプルーフ・オブ・ワーク・チェーンのイーサリアムとマージ(統合)されました。
-summaryPoint3: ビーコンチェーンは、コンセンサスロジックとブロックゴシッププロトコルを導入し、現在はイーサリアムの安全性を保護しています。
+summaryPoint1: "イーサリアムエコシステムにプルーフ・オブ・ステークの導入を可能にしたのが、ビーコンチェーンです。"
+summaryPoint2: "2022年9月にプルーフ・オブ・ワーク・チェーンのイーサリアムとマージ(統合)されました。"
+summaryPoint3: "ビーコンチェーンは、コンセンサスロジックとブロックゴシッププロトコルを導入し、現在はイーサリアムの安全性を保護しています。"
---
diff --git a/public/content/translations/ja/roadmap/danksharding/index.md b/public/content/translations/ja/roadmap/danksharding/index.md
index 7fcaff273be..9537d000086 100644
--- a/public/content/translations/ja/roadmap/danksharding/index.md
+++ b/public/content/translations/ja/roadmap/danksharding/index.md
@@ -1,6 +1,6 @@
---
-title: ダンクシャーディング
-description: イーサリアムをスケーリングするための2段階のアップグレードである、プロトダンクシャーディングとダンクシャーディングについて学びます。
+title: "ダンクシャーディング"
+description: "イーサリアムをスケーリングするための2段階のアップグレードである、プロトダンクシャーディングとダンクシャーディングについて学びます。"
lang: ja
summaryPoints:
- ダンクシャーディングは、イーサリアムのスケーラビリティと容量を向上させるための複数のフェーズを伴うアップグレードです。
@@ -23,13 +23,11 @@ summaryPoints:
ロールアップは、トランザクションをオフチェーンでバッチ処理し、その結果をイーサリアムに投稿することでイーサリアムをスケールする方法です。 ロールアップは、基本的にデータと実行確認の2つの要素で構成されています。 データは、イーサリアムに投稿される状態変更を生成するためにロールアップによって処理されている、トランザクションの完全なシーケンスです。 実行確認では、正直なアクターである証明者が、提案された状態変更が正しいことを確認するために、トランザクションを再度実行します。 実行チェックを行うためには、トランザクションデータが十分長い間利用可能であり、誰でもダウンロードして確認できるようになっている必要があります。 実行確認により、証明者は、ロールアップシーケンサーが行った不正行為を特定でき、異議申立をすることができます。 ただし、このトランザクションデータを永久的に保存する必要はありません。
-
ロールアップは、トランザクションデータのコミットメントをオンチェーンに投稿し、実際のデータをデータブロブで利用可能にします。 証明者はコミットメントが有効であることを確認したり、間違っていると思われるデータに異議を唱えることができます。 ノードレベルでは、データブロブはコンセンサスクライアントに保持されます。 コンセンサスクライアントは、データを確認し、それがネットワーク全体に伝播したことを証明します。 データが永久的に保持される場合、これらのクライアントの容量が大きくなり、ノードの実行に大量のハードウェアが必要になる可能性があります その代わりに、データは18日ごとにノードから自動的に削除されます。 コンセンサスクライアントのアテステーションは、証明者がデータを十分に検証する機会があったことを示しています。 実際のデータは、ロールアップオペレーター、ユーザー、またはその他によってオフチェーンに保存できます。
-
### ブロブデータの検証方法 {#how-are-blobs-verified}
@@ -49,13 +47,11 @@ EIP-4844 KZGセレモニーは公開されており、数万人の人々が参
ロールアップがブロブ内にデータを投稿する際、オンチェーンに投稿する「コミットメント」を提供します。 このコミットメントは、特定の点でデータに適合する多項式を評価した結果です。 この点は、KZGセレモニーで生成された乱数によって定義され、 証明者はデータを検証するために同じ点で多項式を評価できます。同じ値になった場合、データは正しいということになります。
-
コミットメントに使用されるランダムな位置を誰かが知っている場合、その特定の点に適合する新しい多項式(すなわち「コリジョン」)を生成することは容易です。 つまり、ブロブにデータを追加または削除しても、有効な証拠を提供できてしまうのです。 これを防ぐために、秘密の位置をそのまま提供する代わりに、楕円曲線を使用して暗号化された「ブラックボックス」でラップされた位置を証明者に提供します。 こうした値は、元の値をリバースエンジニアリングできないように値を効果的にスクランブルしますが、いくつかの巧妙な代数的操作により、証明者と検証者はそれらが表す点で多項式を評価することができます。
-
@@ -71,13 +67,11 @@ EIP-4844 KZGセレモニーは公開されており、数万人の人々が参
提案者と作成者を分離することで、個々の検証者が32MBのブロブデータに対して、コストのかかるコミットメントや証明を生成するのを防ぐことができます。 提案者と作成者の分離をしないと、自宅でステーキングをしている端末に過度の負担がかかり、より強力なハードウェアへの投資が必要となります。その結果、分散化に悪影響を及ぼします。 代わりに、専門のブロック作成者が、このコストのかかる計算作業を担当します。 そして、ブロック作成者は、ブロック提案者にブロックを提供してブロードキャストします。 ブロック提案者は、最も収益性の高いブロックを選択するだけです。 誰でも、安価かつ迅速にブロブを検証できます。つまり、通常のバリデータであれば、ブロック作成者が誠実な行動をしているかどうかをチェックできます。 この仕組みにより、分散化を犠牲にすることなく、大きなブロブを処理することができます。 不正なブロック作成者を簡単にネットワークから排除してスラッシュすることができます。ブロック作成自体が収益性の高い活動であるため、不正なブロック作成者の代わりに、他の候補者が参加することになります。
-
データ可用性サンプリングは、バリデータがブロブデータを迅速かつ効率的に検証するために必要です。 データ可用性サンプリングによって、バリデータは、ブロブデータが利用可能であり、正しくコミットされていることを確認できます。 具体的には、バリデータは、いくつかのデータ点をランダムにサンプリングして、そのデータがきちんと保存されていることを確認します。つまり、ブロブ全体をチェックする必要はありません。 データが欠落していた場合、すぐに特定してそのブロブを拒否することができます。
-
### 現在の進捗 {#current-progress}
diff --git a/public/content/translations/ja/roadmap/dencun/index.md b/public/content/translations/ja/roadmap/dencun/index.md
index 23defb5b877..7dc8fd75632 100644
--- a/public/content/translations/ja/roadmap/dencun/index.md
+++ b/public/content/translations/ja/roadmap/dencun/index.md
@@ -1,6 +1,6 @@
---
-title: カンクンーデネブ (デンクン) よくある質問
-description: カンクンーデネブ (デンクン) ネットワークアップグレードに関するよくある質問
+title: "カンクンーデネブ (デンクン) よくある質問"
+description: "カンクンーデネブ (デンクン) ネットワークアップグレードに関するよくある質問"
lang: ja
---
@@ -49,7 +49,7 @@ lang: ja
- The Graphのようなサードパーティのインデックスプロトコルは、暗号経済的メカニズムによってインセンティブを受けたノードオペレーターの分散型ネットワークを通じてこのデータを保存します
- BitTorrentは、ボランティアがこのデータを保持し、他の人に配布することができる分散型プロトコルです
-- [イーサリアムポータルネットワーク] (/developers/docs/networking-layer/portal-network/) は、BitTorrentに似た方法で参加者間でデータを分配し、分散型ネットワークのノードオペレーターを通じてイーサリアムの全データにアクセスを提供することを目指しています
+- [イーサリアムポータルネットワーク](/developers/docs/networking-layer/portal-network/) は、BitTorrentに似た方法で参加者間でデータを分配し、分散型ネットワークのノードオペレーターを通じてイーサリアムの全データにアクセスを提供することを目指しています
- 個々のユーザーは、過去の参照のために必要なデータのコピーを自由に保存することができます
- ロールアッププロバイダーは、ロールアップのユーザーエクスペリエンスを向上させるために、このデータを保存するインセンティブを持っています
- ブロックエクスプローラーは通常、この情報を全てインデックス化して保存するアーカイブノードを運用し、ユーザーがウェブインターフェースを通じて簡単に過去のデータを参照できるようにします
diff --git a/public/content/translations/ja/roadmap/fusaka/index.md b/public/content/translations/ja/roadmap/fusaka/index.md
index 3bc23df82ac..5cb3bf9390c 100644
--- a/public/content/translations/ja/roadmap/fusaka/index.md
+++ b/public/content/translations/ja/roadmap/fusaka/index.md
@@ -1,6 +1,6 @@
---
title: Fulu-Osaka (Fusaka)
-description: Fusakaプロトコルアップグレードについて学ぶ
+description: "Fusakaプロトコルアップグレードについて学ぶ"
lang: ja
---
diff --git a/public/content/translations/ja/roadmap/fusaka/peerdas/index.md b/public/content/translations/ja/roadmap/fusaka/peerdas/index.md
index fc4a133c248..b2c8a36ddcf 100644
--- a/public/content/translations/ja/roadmap/fusaka/peerdas/index.md
+++ b/public/content/translations/ja/roadmap/fusaka/peerdas/index.md
@@ -1,6 +1,6 @@
---
title: PeerDAS
-description: Fusakaイーサリアムプロトコルアップグレードの一環としてのPeerDASについて学ぶ
+description: "Fusakaイーサリアムプロトコルアップグレードの一環としてのPeerDASについて学ぶ"
lang: ja
---
diff --git a/public/content/translations/ja/roadmap/future-proofing/index.md b/public/content/translations/ja/roadmap/future-proofing/index.md
index 5546d3154a8..62982402384 100644
--- a/public/content/translations/ja/roadmap/future-proofing/index.md
+++ b/public/content/translations/ja/roadmap/future-proofing/index.md
@@ -1,6 +1,6 @@
---
-title: 将来性のあるイーサリアム
-description: これらのアップグレードにより、イーサリアムは、将来何が起きようとも、回復力のある分散型のベースレイヤーとして確立されます。
+title: "将来性のあるイーサリアム"
+description: "これらのアップグレードにより、イーサリアムは、将来何が起きようとも、回復力のある分散型のベースレイヤーとして確立されます。"
lang: ja
image: /images/roadmap/roadmap-future.png
alt: "イーサリアムロードマップ"
diff --git a/public/content/translations/ja/roadmap/merge/index.md b/public/content/translations/ja/roadmap/merge/index.md
index 91b372d24a4..9b47f622782 100644
--- a/public/content/translations/ja/roadmap/merge/index.md
+++ b/public/content/translations/ja/roadmap/merge/index.md
@@ -1,14 +1,14 @@
---
-title: マージ
-description: マージについて - イーサリアムメインネットへのプルーフ・オブ・ステークの導入
+title: "マージ"
+description: "マージについて - イーサリアムメインネットへのプルーフ・オブ・ステークの導入"
lang: ja
template: upgrade
image: /images/upgrades/merge.png
alt:
-summaryPoint1: イーサリアムメインネットは現在プルーフ・オブ・ステークを使用していますが、これまではそうではありませんでした。
-summaryPoint2: 旧プルーフ・オブ・ワークのメカニズムからプルーフ・オブ・ステークへのアップグレードはマージと呼ばれます。
-summaryPoint3: マージとは、元のイーサリアムメインネットが、ビーコンチェーンとよばれる別のプルーフ・オブ・ステークのブロックチェーンと統合(マージ)し、1つのチェーンになったことを意味します。
-summaryPoint4: マージによりイーサリアムのエネルギー消費が最大99.95%削減されました。
+summaryPoint1: "イーサリアムメインネットは現在プルーフ・オブ・ステークを使用していますが、これまではそうではありませんでした。"
+summaryPoint2: "旧プルーフ・オブ・ワークのメカニズムからプルーフ・オブ・ステークへのアップグレードはマージと呼ばれます。"
+summaryPoint3: "マージとは、元のイーサリアムメインネットが、ビーコンチェーンとよばれる別のプルーフ・オブ・ステークのブロックチェーンと統合(マージ)し、1つのチェーンになったことを意味します。"
+summaryPoint4: "マージによりイーサリアムのエネルギー消費が最大99.95%削減されました。"
---
@@ -70,7 +70,8 @@ id="staking-node-operators">
上記の最初の2つの項目が完了していないと、両方のレイヤーが同期および認証されるまで、ノードが「オフライン」として表示されてしまいます。
-「フィーの受取人」を設定しなくても、バリデータは通常どおり動作しますが、バリデータが提案したブロックの未焼却のフィーのチップや獲得できたはずのMEVを逃すことになります。
+「フィーの受取人」を設定しなくても、バリデータは通常どおり動作しますが、バリデータが提案したブロックの未焼却のフィーのチップや獲得できたはずのMEVを逃すことになります。
+
- 実行クライアントとコンセンサスクライアントが安全に通信できるように、共有のJWTシークレットで両者を認証します。
上記の項目が完了していないと、両方のレイヤーの同期と認証が完了するまで、ノードが「オフライン」のように表示されます。
-
詳細については、Tim Beikoによるブログ投稿マージがイーサリアムのアプリケーションレイヤーに与える影響をご覧ください。
-
## マージとエネルギー消費 {#merge-and-energy}
@@ -134,7 +133,6 @@ contentPreview="誤り。 誰でも自由にイーサリアムの自己検証済
また、誰もが自分自身のノードを運用できることは、イーサリアムネットワークの分散化を維持するために不可欠です。
[自分自身のノードの運用に関する詳細](/run-a-node/)
-
ロールアップ中心のロードマップにより、[レイヤー2](/layer-2/)でのユーザーアクティビティのスケーリングに焦点を当て、一方でレイヤー1メインネットを安全な分散型決済レイヤーとして、ロールアップデータストレージに最適化し、ロールアップトランザクションを飛躍的に安価にすることを可能にしています。 プルーフ・オブ・ステークへの移行は、これを実現するための重要な布石となります。 [ガスと手数料の詳細](/developers/docs/gas/)
-
引き出しアドレスを指定して、超過しているステーキング残高(32ETHを越えた分のプロトコル報酬)の自動支払を受け取れるようになりました。 このアップグレードにより、バリデータがネットワークから抜け出すときに、ロックを解除して残高全体を回収できるようになりました。
[ステーキング出金について詳しく](/staking/withdrawals/)
-
- ステーキングによる正確な発行額は、ステークされたETHの合計量に基づいて変動します。
- **マージ以降は、1日あたり約1,700 ETHのみが残り、新規ETHの総発行量は約88%減少しました**
- バーン：ネットワークの需要に応じて変動します。 とある日に、平均のガス価格が16Gwei以上になると、バリデータによって発行される約1,700ETHが実質的に相殺されるので、その日の純ETHインフレ率はゼロ以下になります。
-
## マージ以前(過去) {#pre-merge}
@@ -61,7 +60,10 @@ ETH総供給量: **約120,520,000 ETH** (2022年9月のマージ時点)
発行額の\*\*約88.7%\*\*は実行レイヤーのマイナーに支払われていました (4.09 / 4.61 \* 100)
-\*\*約11.3%\*\*はコンセンサスレイヤーのステーカーに発行されていました (0.52 / 4.61 \* 100)
+\*\*約11.3%\*\*はコンセンサスレイヤーのステーカーに発行されていました (0.52 / 4.61 \* 100)
+
+
+
## マージ以後(現在) {#post-merge}
@@ -92,7 +94,10 @@ ETH総供給量: **約120,520,000 ETH** (2022年9月のマージ時点)
年間発行率合計: **約0.52%**
-年間ETH発行の純減率: **約88.7%** ((4.61% - 0.52%) / 4.61% \* 100)
+年間ETH発行の純減率: **約88.7%** ((4.61% - 0.52%) / 4.61% \* 100)
+
+
+
##
-手数料のバーンは、2021年8月の[ロンドン・アップグレード](/ethereum-forks/#london)で導入され、マージ以降も変更されていません。
+手数料のバーンは、2021年8月の[ロンドン・アップグレード](/ethereum-forks/#london)で導入され、マージ以降も変更されていません。
+
+
+
ロンドンのアップグレードで実装されたフィーのバーンに加えて、バリデータがオフラインになるとペナルティを課されます。さらに深刻なことに、ネットワークのセキュリティを脅かす特定のルールに違反した場合にはスラッシュされることがあります。 これらのペナルティにより、バリデータの残高からETHが減少し、他のどのアカウントにも直接報酬として支払われず、事実上は流通から消滅することになります。
diff --git a/public/content/translations/ja/roadmap/pbs/index.md b/public/content/translations/ja/roadmap/pbs/index.md
index 0b824c6a57f..e7bb67cbc2e 100644
--- a/public/content/translations/ja/roadmap/pbs/index.md
+++ b/public/content/translations/ja/roadmap/pbs/index.md
@@ -1,5 +1,5 @@
---
-title: プロポーザー/ビルダーセパレーション(PBS)
+title: "プロポーザー/ビルダーセパレーション(PBS)"
description: |
イーサリアムのバリデータがブロックの構築とブロックのブロードキャストの責任を分担する方法とその理由を学びます。
lang: ja
@@ -22,7 +22,6 @@ lang: ja
経済力のある組織は、特定のアドレスのトランザクションをブロックするようにバリデータに圧力をかけてくるかもしれません。 バリデーターは、自分たちのトランザクションプール内のブラックリストに載ったアドレスを検出し、自分たちが提案するブロックからそれらを除外することによって、この圧力に対応します。 PBSを導入すると、ブロック提案者は、自身のブロックでどのトランザクションをブロードキャストしているのか分からなくなるので、この対抗策は使えなくなります。 住んでいる地域で検閲が法律になっている場合、個人やアプリが検閲ルールに準拠しなければならないことがあります。 これらのケースでは、コンプライアンスはアプリケーションレベルで行われ、プロトコルはパーミッションレスで検閲が行われない状態のままです。
-
## PBSとMEV {#pbs-and-mev}
@@ -33,7 +32,8 @@ PBSでは、MEVの経済を再設定することによって、この問題を
-個人でステークするよりも、プールでステークする方が有利になるかもしれません。これは、複雑なMEV戦略によって得られる報酬が増えるからです。 ブロックの構築とブロックの提案を分離することで、抽出されたMEVは、最も使われているMEVサーチャーに集中するのではなく、より多くのバリデータに分散されます。 同時に、専門のブロックビルダーの存在を許可することで、ブロック構築の負担が軽減され、MEVの盗難も防止されます。また、独立したバリデータの数も最大化され、ブロックの正しさをチェックできるようになります。 これは、「証明者と検証者の非対称性」という重要なコンセプトであり、ブロックが誠実であることを証明できる堅牢かつ最大限に分散化された検証者のネットワークが存在する限り、集中的なブロック生成は問題ないという考えを参考にしています。 分散化はあくまでも手段であって、目的ではありません。私たちが本当に望んでいるのは、正しいブロックです。
+個人でステークするよりも、プールでステークする方が有利になるかもしれません。これは、複雑なMEV戦略によって得られる報酬が増えるからです。 ブロックの構築とブロックの提案を分離することで、抽出されたMEVは、最も使われているMEVサーチャーに集中するのではなく、より多くのバリデータに分散されます。 同時に、専門のブロックビルダーの存在を許可することで、ブロック構築の負担が軽減され、MEVの盗難も防止されます。また、独立したバリデータの数も最大化され、ブロックの正しさをチェックできるようになります。 これは、「証明者と検証者の非対称性」という重要なコンセプトであり、ブロックが誠実であることを証明できる堅牢かつ最大限に分散化された検証者のネットワークが存在する限り、集中的なブロック生成は問題ないという考えを参考にしています。 分散化はあくまでも手段であって、目的ではありません。私たちが本当に望んでいるのは、正しいブロックです。
+
## PBSとDanksharding {#pbs-and-danksharding}
diff --git a/public/content/translations/ja/roadmap/pectra/7702/index.md b/public/content/translations/ja/roadmap/pectra/7702/index.md
index 4cbfe4fdb0a..fb8a35fff0d 100644
--- a/public/content/translations/ja/roadmap/pectra/7702/index.md
+++ b/public/content/translations/ja/roadmap/pectra/7702/index.md
@@ -1,6 +1,6 @@
---
-title: Pectra 7702 ガイドライン
-description: Pectraリリースにおける7702の詳細
+title: "Pectra 7702 ガイドライン"
+description: "Pectraリリースにおける7702の詳細"
lang: ja
---
diff --git a/public/content/translations/ja/roadmap/pectra/index.md b/public/content/translations/ja/roadmap/pectra/index.md
index 86a8374d79b..57bdacd922e 100644
--- a/public/content/translations/ja/roadmap/pectra/index.md
+++ b/public/content/translations/ja/roadmap/pectra/index.md
@@ -1,6 +1,6 @@
---
title: Prague-Electra (Pectra)
-description: Pectraプロトコルアップグレードの詳細
+description: "Pectraプロトコルアップグレードの詳細"
lang: ja
---
diff --git a/public/content/translations/ja/roadmap/pectra/maxeb/index.md b/public/content/translations/ja/roadmap/pectra/maxeb/index.md
index f137ea05c7a..30dfb347bd3 100644
--- a/public/content/translations/ja/roadmap/pectra/maxeb/index.md
+++ b/public/content/translations/ja/roadmap/pectra/maxeb/index.md
@@ -1,6 +1,6 @@
---
title: Pectra MaxEB
-description: PectraでリリースされたMaxEBの詳細
+description: "PectraでリリースされたMaxEBの詳細"
lang: ja
---
diff --git a/public/content/translations/ja/roadmap/scaling/index.md b/public/content/translations/ja/roadmap/scaling/index.md
index a139f01a4dc..e1828596c3d 100644
--- a/public/content/translations/ja/roadmap/scaling/index.md
+++ b/public/content/translations/ja/roadmap/scaling/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアムのスケーリング
-description: ロールアップでは、トランザクションをオフチェーンでまとめて処理することで、ユーザーのコスト削減を実現しています。 しかし、現在のロールアップでは、データを使用するコストが高く、トランザクションを安価にすることが難しいという課題があります。 これについては、プロトダンクシャーディングによって解決できます。
+title: "イーサリアムのスケーリング"
+description: "ロールアップでは、トランザクションをオフチェーンでまとめて処理することで、ユーザーのコスト削減を実現しています。 しかし、現在のロールアップでは、データを使用するコストが高く、トランザクションを安価にすることが難しいという課題があります。 これについては、プロトダンクシャーディングによって解決できます。"
lang: ja
image: /images/roadmap/roadmap-transactions.png
alt: "イーサリアムロードマップ"
diff --git a/public/content/translations/ja/roadmap/secret-leader-election/index.md b/public/content/translations/ja/roadmap/secret-leader-election/index.md
index 4219d30a3cf..2de1afb0f70 100644
--- a/public/content/translations/ja/roadmap/secret-leader-election/index.md
+++ b/public/content/translations/ja/roadmap/secret-leader-election/index.md
@@ -1,6 +1,6 @@
---
-title: シークレットリーダー選出
-description: シークレットリーダー選出によりバリデータを攻撃から守る仕組み
+title: "シークレットリーダー選出"
+description: "シークレットリーダー選出によりバリデータを攻撃から守る仕組み"
lang: ja
summaryPoints:
- ブロック提案者のIPアドレスは事前に知ることができるため、攻撃の対象になりやすくなります。
diff --git a/public/content/translations/ja/roadmap/security/index.md b/public/content/translations/ja/roadmap/security/index.md
index 88c4a9b7c70..21151ed429b 100644
--- a/public/content/translations/ja/roadmap/security/index.md
+++ b/public/content/translations/ja/roadmap/security/index.md
@@ -1,6 +1,6 @@
---
-title: より安全なイーサリアム
-description: イーサリアムは、現存するスマートコントラクトプラットフォームの中で、最も安全かつ分散化されています。 しかし、将来にわたってあらゆるレベルの攻撃に対して耐性を維持するためには、改善すべき点がまだあります。
+title: "より安全なイーサリアム"
+description: "イーサリアムは、現存するスマートコントラクトプラットフォームの中で、最も安全かつ分散化されています。 しかし、将来にわたってあらゆるレベルの攻撃に対して耐性を維持するためには、改善すべき点がまだあります。"
lang: ja
image: /images/roadmap/roadmap-security.png
alt: "イーサリアムロードマップ"
diff --git a/public/content/translations/ja/roadmap/single-slot-finality/index.md b/public/content/translations/ja/roadmap/single-slot-finality/index.md
index 17ca65f7ee1..f26528f5a01 100644
--- a/public/content/translations/ja/roadmap/single-slot-finality/index.md
+++ b/public/content/translations/ja/roadmap/single-slot-finality/index.md
@@ -1,6 +1,6 @@
---
-title: シングルスロット・ファイナリティ
-description: シングルスロット・ファイナリティの説明
+title: "シングルスロット・ファイナリティ"
+description: "シングルスロット・ファイナリティの説明"
lang: ja
---
@@ -39,7 +39,8 @@ lang: ja
このプロセスでは、「32スロット × 64の委員会 × 委員会あたり256のバリデータ = エポックあたり524,288のバリデータ」となり、各バリデータが各エポックで投票する十分な容量を提供します。 執筆時点(2023年2月)では、約513,000ものバリデータが存在しています。
-このスキームにおいて、ブロックに投票するには、すべてのバリデータがエポック全体でアテステーションを分配する必要があります。 しかしながら、各バリデータが各スロットで証明できるように、このメカニズムを改善する実現可能な方法があります。
+このスキームにおいて、ブロックに投票するには、すべてのバリデータがエポック全体でアテステーションを分配する必要があります。 しかしながら、各バリデータが各スロットで証明できるように、このメカニズムを改善する実現可能な方法があります。
+
イーサリアムのコンセンサスメカニズムが設計された当初、署名集約スキーム(BLS)のスケーラビリティは懸念されていましたが、その後の研究により、BLSは当初考えられていたよりもはるかにスケーラブルであることがわかりました。また、クライアントにおける署名の処理および検証の処理能力も向上したことで、 バリデータから送られる膨大な数のアテステーションの処理が、現実的に1つのスロット内で可能になりました。 例えば、100万のバリデータが各スロットで2回投票し、スロットの時間を16秒に調節している場合、スロットあたり100万のアテステーションを処理するためには、ノードは1秒に最低125,000もの集約に対して署名を検証する必要があります。 実際には、一般的なコンピュータが1つの署名を検証するのに約500ナノ秒かかるので、125,000の署名の検証は約62.5ミリ秒で完了します。これは、1秒のしきい値をはるかに下回っています。
diff --git a/public/content/translations/ja/roadmap/statelessness/index.md b/public/content/translations/ja/roadmap/statelessness/index.md
index ac44c4b6f19..afd20781d14 100644
--- a/public/content/translations/ja/roadmap/statelessness/index.md
+++ b/public/content/translations/ja/roadmap/statelessness/index.md
@@ -1,6 +1,6 @@
---
-title: ステートレス、状態の有効期限、履歴の有効期限
-description: 履歴の有効期限とステートレスなイーサリアムの説明
+title: "ステートレス、状態の有効期限、履歴の有効期限"
+description: "履歴の有効期限とステートレスなイーサリアムの説明"
lang: ja
---
@@ -72,7 +72,8 @@ EIP-4444は、現在も活発な議論が行われており、まだリリース
ステートレスでは、ブロックの検証に必要なウィットネスを生成するのはブロックビルダーです。ブロックビルダーは、ブロックを検証するために必要なすべての状態データを保持しているため、 他のノードは状態データにアクセスする必要はありません。ブロックを検証するために必要な情報はすべてウィットネスが持っていることから、 ブロックの提案はコストが高く、ブロックの検証はコストが低いという状況になります。そのため、ブロックを提案するノードを実行するオペレーターが減ってしまう可能性があります。 しかし、ブロック提案者の分散化は、できるだけ多くの参加者が、提案されたブロックの有効性を独自で検証できる限り、重要ではありません。
-Dankradのノートで続きを読む
+Dankradのノートで続きを読む
+
ブロックの提案者は、状態データを使用して「ウィットネス」を作成します。これはブロック内のトランザクションによって変更される状態の値を証明する小さなデータセットです。 他のバリデータは状態を保持せず、状態ルート(状態全体のハッシュ)のみを保存します。 バリデータは、ブロックとウィットネスを受け取って、状態ルートを更新します。 こうすることで、バリデータノードは大幅に軽量化されます。
diff --git a/public/content/translations/ja/roadmap/user-experience/index.md b/public/content/translations/ja/roadmap/user-experience/index.md
index 003cd1298d9..67dc96dbd65 100644
--- a/public/content/translations/ja/roadmap/user-experience/index.md
+++ b/public/content/translations/ja/roadmap/user-experience/index.md
@@ -1,6 +1,6 @@
---
-title: ユーザーエクスペリエンスの改善
-description: イーサリアムは、ほとんどの人にとって使いこなすのが難しいものです。 そのため、一般の人にも使ってもらえるように、イーサリアムへの参入障壁を大幅に下げる必要があります。ユーザーは、イーサリアムの分散型、パーミッションレス、検閲耐性といったアクセスのメリットを享受できるだけでなく、従来のWeb2アプリと同じように簡単に使えるようにする必要があります。
+title: "ユーザーエクスペリエンスの改善"
+description: "イーサリアムは、ほとんどの人にとって使いこなすのが難しいものです。 そのため、一般の人にも使ってもらえるように、イーサリアムへの参入障壁を大幅に下げる必要があります。ユーザーは、イーサリアムの分散型、パーミッションレス、検閲耐性といったアクセスのメリットを享受できるだけでなく、従来のWeb2アプリと同じように簡単に使えるようにする必要があります。"
lang: ja
image: /images/roadmap/roadmap-ux.png
alt: "イーサリアムロードマップ"
diff --git a/public/content/translations/ja/roadmap/verkle-trees/index.md b/public/content/translations/ja/roadmap/verkle-trees/index.md
index be46367632a..bdea910cf15 100644
--- a/public/content/translations/ja/roadmap/verkle-trees/index.md
+++ b/public/content/translations/ja/roadmap/verkle-trees/index.md
@@ -1,6 +1,6 @@
---
-title: バークルツリー
-description: バークルツリーがイーサリアムのアップグレードでどのように使われるかを説明します。
+title: "バークルツリー"
+description: "バークルツリーがイーサリアムのアップグレードでどのように使われるかを説明します。"
lang: ja
summaryPoints:
- バークルツリーとは何かを理解する
@@ -18,7 +18,6 @@ summaryPoints:
イーサリアムクライアントは現在、状態データを保存するためにパトリシア・マークル・ツリーと呼ばれるデータ構造を使用しています。 個々のアカウントに関する情報はツリー上のリーフとして保存され、そのリーフのペアが1つのハッシュになるまで繰り返しハッシュ化されます。 この最後のハッシュは、「ルート」と呼ばれます。 イーサリアムクライアントは、ブロック内のすべてのトランザクションを実行し、ローカルにある状態ツリーを更新することで、ブロックを検証します。 ローカルにあるツリーのルートが、ブロック提案者によって提供されたルートと同じであれば、ブロックは有効であると判断されます。なぜなら、ブロック提案者と検証ノードが異なる計算を実行した場合、ルートハッシュが完全に違うものになるためです。 問題は、ブロックチェーンを検証するために、各クライアントがブロックの先頭までの状態ツリー全体と複数の履歴ブロックを保持する必要があることです(Gethのデフォルト設定では、ヘッドから遡って128ブロックの状態データを保持します)。 現在の状態では、クライアントは大容量のディスク領域が必要になり、安価で低電力のハードウェアでフルノードを実行する際の障壁となります。 これに対する解決策は、より効率的な構造(バークルツリー)を持った状態ツリーを更新することです。バークルツリーでは、完全な状態データの代わりに、共有可能なデータである小さな「ウィットネス」を使うことで集約することができます。 状態データをバークルツリーに再フォーマットすることは、ステートレスクライアントへ移行するための足掛かりとなります。
-
## ウィットネスの説明とその必要性 {#what-is-a-witness}
@@ -34,7 +33,6 @@ summaryPoints:
ウィットネスのサイズは、含まれるリーフの数によって変わります。 例えば、1000枚のリーフを扱うウィットネスは、マークルツリーで約3.5MB(ツリーが7レベルと仮定しています)、 バークルツリーでは約150KB(ツリーが4レベルあると仮定します)となり、**約23分の1**に縮小できます。 このウィットネスのサイズ縮小により、ステートレスクライアントでも許容できる大きさになります。 多項式ウィットネスは、使用する具体的な多項式コミットメントに応じて、0.128kBから1kBの範囲です。
-
## バークルツリーの構造 {#what-is-the-structure-of-a-verkle-tree}
diff --git a/public/content/translations/ja/security/index.md b/public/content/translations/ja/security/index.md
index 21989f59f2b..0d646f442f4 100644
--- a/public/content/translations/ja/security/index.md
+++ b/public/content/translations/ja/security/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアムのセキュリティと詐欺対策
-description: イーサリアムにおける安全対策
+title: "イーサリアムのセキュリティと詐欺対策"
+description: "イーサリアムにおける安全対策"
lang: ja
---
diff --git a/public/content/translations/ja/smart-contracts/index.md b/public/content/translations/ja/smart-contracts/index.md
index 3862f29bde6..8e809e40b0f 100644
--- a/public/content/translations/ja/smart-contracts/index.md
+++ b/public/content/translations/ja/smart-contracts/index.md
@@ -1,7 +1,7 @@
---
-title: スマートコントラクト
+title: "スマートコントラクト"
metaTitle: "スマートコントラクト：その概要と利点"
-description: スマートコントラクトの紹介(非テクニカル面)
+description: "スマートコントラクトの紹介(非テクニカル面)"
lang: ja
---
diff --git a/public/content/translations/ja/social-networks/index.md b/public/content/translations/ja/social-networks/index.md
index 8ba50821d9c..77802fbfc93 100644
--- a/public/content/translations/ja/social-networks/index.md
+++ b/public/content/translations/ja/social-networks/index.md
@@ -1,14 +1,14 @@
---
-title: 分散型ソーシャルネットワーク
-description: イーサリアム上の分散型ソーシャルネットワークの概要
+title: "分散型ソーシャルネットワーク"
+description: "イーサリアム上の分散型ソーシャルネットワークの概要"
lang: ja
template: use-cases
emoji: ":mega:"
sidebarDepth: 2
image: /images/ethereum-learn.png
-summaryPoint1: ソーシャル・インタラクションとコンテンツの作成と配信のためのブロックチェーンベースのプラットフォーム
-summaryPoint2: 分散型ソーシャル・メディア・ネットワークは、ユーザーのプライバシーを保護し、データセキュリティを強化
-summaryPoint3: トークンと非代替性トークン(NFT)により、コンテンツを収益化する新しい方法の創出
+summaryPoint1: "ソーシャル・インタラクションとコンテンツの作成と配信のためのブロックチェーンベースのプラットフォーム"
+summaryPoint2: "分散型ソーシャル・メディア・ネットワークは、ユーザーのプライバシーを保護し、データセキュリティを強化"
+summaryPoint3: "トークンと非代替性トークン(NFT)により、コンテンツを収益化する新しい方法の創出"
---
ソーシャルネットワークは、私たちの日常的なコミュニケーションにおいて大きな役割を果たしています。 ただし、これらのプラットフォームが集中管理されると、多くの問題が発生します。データ侵害、サーバの停止、 プラットフォーム解除、検閲、プライバシー侵害は、ソーシャルメディアが度々行うことがあり、トレードオフの一部となります。 これらの問題に対抗するため、デベロッパー達は現在イーサリアム上でソーシャルネットワークを構築しています。 分散型ソーシャルネットワークは、従来のソーシャルネットワーキングのプラットフォームが持つ多くの問題を解決し、ユーザーの全般的なエクスペリエンスの向上につながります。
diff --git a/public/content/translations/ja/staking/dvt/index.md b/public/content/translations/ja/staking/dvt/index.md
index 18a045ea77d..7058bc45fff 100644
--- a/public/content/translations/ja/staking/dvt/index.md
+++ b/public/content/translations/ja/staking/dvt/index.md
@@ -1,6 +1,6 @@
---
-title: 分散型バリデータ技術
-description: 分散型バリデータ技術は、複数の当事者によるイーサリアムバリデータの分散運用を可能にします。
+title: "分散型バリデータ技術"
+description: "分散型バリデータ技術は、複数の当事者によるイーサリアムバリデータの分散運用を可能にします。"
lang: ja
---
diff --git a/public/content/translations/ja/staking/pools/index.md b/public/content/translations/ja/staking/pools/index.md
index 7665151c4d4..e258e25cadc 100644
--- a/public/content/translations/ja/staking/pools/index.md
+++ b/public/content/translations/ja/staking/pools/index.md
@@ -1,11 +1,11 @@
---
-title: ステーキングプール
-description: ステーキングプールについて学ぶ
+title: "ステーキングプール"
+description: "ステーキングプールについて学ぶ"
lang: ja
template: staking
emoji: ":money_with_wings:"
image: /images/staking/leslie-pool.png
-alt: プールで泳ぐサイのレスリー
+alt: "プールで泳ぐサイのレスリー"
sidebarDepth: 2
summaryPoints:
- 他者と協力してETHをステーキングし、報酬を獲得
@@ -68,14 +68,16 @@ summaryPoints:
この代替方法として、ERC-20のステーキングトークンを利用するプールを使用すると、オープンマーケットでトークンを取引でき、ステーキングポジションを売却することができます。実際にステーキングコントラクトからETHを取り除くことなく、効果的に「引き出す」ことができます。
-ステーキングの引き出しについての詳細
+ステーキングの引き出しについての詳細
+
これらのステーキングプールと、中央集権型取引所の間には多くの類似点があります。 例えば、複数の少額のステーキングをまとめて、バリデータを有効にすることなどです。
中央集権型取引所とは異なり、多くのステーキングプールでは、スマートコントラクトおよび/またはステーキングトークンを利用します。このステーキングトークンは、通常はERC-20トークンで、他のトークンと同様に、購入・販売できます。 このトークンは自分自身で制御でき、主権とセキュリティを提供しますが、バックグラウンドで動作するバリデータクライアントを直接制御することはできません。
-これをサポートするノードに関しては、他のものよりも分散化が進んでいるステーキングプールもあります。 ネットワークの健全化と分散化を促進するため、常にパーミッションレスかつ分散化されたノードオペレータを利用するプールサービスを選ぶことが推奨されています。
+これをサポートするノードに関しては、他のものよりも分散化が進んでいるステーキングプールもあります。 ネットワークの健全化と分散化を促進するため、常にパーミッションレスかつ分散化されたノードオペレータを利用するプールサービスを選ぶことが推奨されています。
+
## 参考リンク{#further-reading}
diff --git a/public/content/translations/ja/staking/saas/index.md b/public/content/translations/ja/staking/saas/index.md
index 8696c83ef4b..70f14ec3210 100644
--- a/public/content/translations/ja/staking/saas/index.md
+++ b/public/content/translations/ja/staking/saas/index.md
@@ -1,11 +1,11 @@
---
-title: ステーキング・アズ・ア・サービス
-description: ステーキング・アズ・ア・サービスについて学ぶ
+title: "ステーキング・アズ・ア・サービス"
+description: "ステーキング・アズ・ア・サービスについて学ぶ"
lang: ja
template: staking
emoji: ":money_with_wings:"
image: /images/staking/leslie-saas.png
-alt: 雲に浮かぶサイのレスリー
+alt: "雲に浮かぶサイのレスリー"
sidebarDepth: 2
summaryPoints:
- サードパーティーのノードオペレータが、バリデータクライアントの運用を実施
@@ -17,8 +17,7 @@ summaryPoints:
ステーキング・アズ・ア・サービス(SaaS)は、バリデータになるための32 ETHを預け入れ、ノードの運用については、サードパーティに委任できるステーキングサービスのことです。 このプロセスでは通常、鍵の生成と預け入れを伴う初期セットアップを案内され、署名鍵をオペレータにアップロードします。 これは、通常は月額手数料で、バリデータの運用を代行するサービスです。
-## サービスを使ってステークする利点 サービスを使ってステークする利点 {#why-stake-with-a-service}
-
+## サービスを使ってステークする利点 {#why-stake-with-a-service}
イーサリアムのプロトコルは、ステーキングの委任をネイティブにはサポートしないため、これらのサービスは需要を満たすために作られたものです。 ステーキングする32 ETHはあるものの、ハードウェアを扱うのが苦手な場合、ステーキング・アズ・ア・サービス(SaaS)を利用すると、難しい部分を委任しながらネイティブブロックの報酬を得ることができます。
@@ -70,21 +69,24 @@ BLS引き出し鍵は、ステーキング報酬とステーキングを終了
必ずこのシードフレーズを安全にバックアップしておいてください。忘れてしまうと、引き出せる時が来たときに、引き出し鍵を生成することができません。
-\*最初のデポジットで引き出しアドレスを提供したステーカーは、これを設定する必要はありません。 バリデータを用意する方法に関するサポートについては、SaaSプロバイダーに問い合わせてください。
+\*最初のデポジットで引き出しアドレスを提供したステーカーは、これを設定する必要はありません。 バリデータを用意する方法に関するサポートについては、SaaSプロバイダーに問い合わせてください。
+
最初のデポジット時に引き出しアドレスを提供していないステーカーは、提供する必要があります。また、報酬の支払いは、数日ごとに定期的に自動で分配され始めます。
バリデータは、バリデータとしての役割りを完全に終了することもできます。終了すると、ETH残高がアンロックされ、引き出しできるようになります。 実行引き出しアドレスを提供し、バリデータの終了プロセスを完了したアカウントは、次のバリデータスイープ中に、提供した引き出しアドレスにすべての残高を受け取ることができます。
-ステーキングの引き出しについての詳細
+ステーキングの引き出しについての詳細
+
SaaSプロバイダーを利用することは、ノードの運用を誰かに委ねるということです。 このため、ノードのパフォーマンスが低下するリスクが伴い、このリスクはご自身で制御することはできません。 バリデータがスラッシングされた場合は、自分のバリデータ残高にペナルティが課せられ、バリデータプールから強制的に取り上げられます。
スラッシングおよび退出プロセスが完了すると、これらの資金は、バリデータに指定した引き出しアドレスに転送されます。 これには、有効にするための引き出しアドレスを提供する必要があります。 このアドレスを最初の入金時に提供しているかもしれません。 提供していない場合は、バリデータ引き出し鍵を使用して、引き出しアドレスを宣言するメッセージに署名する必要があります。 引き出しアドレスが提供されていない場合、アドレスが提供されるまで資金はロックされたままになります。
-保証や保険オプションなどの詳細や、引き出しアドレスの提供方法については、それぞれのSaaSプロバイダーにお問い合わせください。 バリデーターのセットアップを完全に自分で管理したい場合は、[ETHのソロステーキング方法について](/staking/solo/)、こちらからさらに学ぶことができます。
+保証や保険オプションなどの詳細や、引き出しアドレスの提供方法については、それぞれのSaaSプロバイダーにお問い合わせください。 バリデーターのセットアップを完全に自分で管理したい場合は、[ETHのソロステーキング方法について](/staking/solo/)、こちらからさらに学ぶことができます。
+
## 参考リンク{#further-reading}
diff --git a/public/content/translations/ja/staking/solo/index.md b/public/content/translations/ja/staking/solo/index.md
index df5f317f8cf..42d340758bb 100644
--- a/public/content/translations/ja/staking/solo/index.md
+++ b/public/content/translations/ja/staking/solo/index.md
@@ -1,11 +1,11 @@
---
-title: ETHのホームステーキング
-description: ETHのホームステーキングする方法の概要
+title: "ETHのホームステーキング"
+description: "ETHのホームステーキングする方法の概要"
lang: ja
template: staking
emoji: ":money_with_wings:"
image: /images/staking/leslie-solo.png
-alt: コンピュータチップ上にサイのレスリー
+alt: "コンピュータチップ上にサイのレスリー"
sidebarDepth: 2
summaryPoints:
- バリデータをオンラインで適切に稼働させ続けることで、プロトコルから直接最大限の報酬を獲得
@@ -43,17 +43,20 @@ summaryPoints:
ご自身のノードを運用する際には、選択したソフトウェアの使用方法を学ぶために時間をかけるべきです。 これには、関連ドキュメントを読み、それらの開発チームのコミュニケーションチャネルに注意を払うことが含まれます。
-実行しているソフトウェアとプルーフ・オブ・ステークの仕組みについて理解を深めるほど、ステーカーとしてのリスクは低くなり、ノードオペレーターとして途中で発生する可能性のある問題を修正するのが容易になります。
+実行しているソフトウェアとプルーフ・オブ・ステークの仕組みについて理解を深めるほど、ステーカーとしてのリスクは低くなり、ノードオペレーターとして途中で発生する可能性のある問題を修正するのが容易になります。
+
新しいツールによって時間とともに簡単になってきていますが、ノードのセットアップには、コンピュータでの作業にある程度の習熟度が求められます。 コマンドラインインターフェースの理解は役立ちますが、もはや厳密に必須ではありません。
-また、非常に基本的なハードウェアのセットアップと、最小推奨スペックに関するある程度の理解も必要です。
+また、非常に基本的なハードウェアのセットアップと、最小推奨スペックに関するある程度の理解も必要です。
+
秘密鍵がイーサリアムアドレスを保護するように、バリデータ専用の鍵を生成する必要があります。 シードフレーズや秘密鍵を安全に保管する方法を理解しなければなりません。{' '}
-[イーサリアムのセキュリティと詐欺対策](/security/)
+[イーサリアムのセキュリティと詐欺対策](/security/)
+
ハードウェアが時折故障したり、ネットワーク接続がエラーになったり、クライアントソフトウェアが時折アップグレードを必要としたりします。 ノードのメンテナンスは避けられず、時折注意を払う必要があります。 予定されているネットワークのアップグレードや、その他の重要なクライアントのアップグレードに常に注意を払うようにしてください。
@@ -66,7 +69,9 @@ summaryPoints:
オフラインであることに対する非アクティビティペナルティとは異なり、スラッシングは悪意のある違反行為のために用意された、はるかに深刻なペナルティです。 マイノリティクライアントを実行し、鍵を一度に1台のマシンにのみロードすることで、スラッシングされるリスクは最小限に抑えられます。 そうは言っても、すべてのステーカーはスラッシングのリスクを認識しなければなりません。
-スラッシングとバリデータのライフサイクルに関する詳細
+スラッシングとバリデータのライフサイクルに関する詳細
+
+
バリデータは、イーサリアム上に存在し、イーサリアムプロトコルのコンセンサスに参加する仮想的なエンティティです。 バリデータは、残高、公開鍵、およびその他のプロパティによって表されます。 バリデータクライアントは、バリデータの秘密鍵を保持および使用することによって、バリデータに代わって機能するソフトウェアです。 単一のバリデータクライアントは多くのキーペアを保持し、多くのバリデータを制御できます。
-
@@ -137,14 +141,16 @@ ETHのホームステーキングを支援するツールやサービスは増
バリデータに関連付けられた各キーペアを有効化するには、少なくとも32 ETHが必要です。 これを超える残高は、このアドレスによって署名されたトランザクションを介して、関連する出金アドレスにいつでも出金できます。 最大有効残高を超える資金は、定期的に自動的に出金されます。
-ホームステーキングが難しすぎると感じる場合は、[ステーキング・アズ・ア・サービス](/staking/saas/)プロバイダーの利用を検討するか、32 ETH未満で作業している場合は、[ステーキングプール](/staking/pools/)をチェックしてください。
+ホームステーキングが難しすぎると感じる場合は、[ステーキング・アズ・ア・サービス](/staking/saas/)プロバイダーの利用を検討するか、32 ETH未満で作業している場合は、[ステーキングプール](/staking/pools/)をチェックしてください。
+
ネットワークが適切にファイナライズされているときにオフラインになっても、スラッシングにはつながりません。 特定のエポック（各6.4分）においてバリデータが証明できない場合、わずかな非アクティビティペナルティが発生しますが、これはスラッシングとは大きく異なります。 これらのペナルティは、バリデータが証明可能であった場合に得られたであろう報酬よりわずかに少なく、損失はほぼ同等の時間オンラインに戻ることで取り戻すことができます。
非アクティビティに対するペナルティは、同時にオフラインになっているバリデータの数に比例することに注意してください。 ネットワークの大部分が一度にすべてオフラインになる場合、これらの各バリデータに対するペナルティは、単一のバリデータが利用できない場合よりも大きくなります。
-極端なケースでは、3分の1を超えるバリデータがオフラインになった結果、ネットワークがファイナライズを停止した場合、これらのユーザーはクアドラティック・イナーアクティビティ・リークとして知られる事態に見舞われます。これは、オフラインのバリデータアカウントからETHが指数関数的に流出することです。 これにより、非アクティブなバリデータの残高が16 ETHに達するまでETHをバーンすることで、最終的にネットワークが自己修復することが可能になり、その時点でバリデータプールから自動的に排出されます。 残りのオンラインのバリデータは、最終的に再びネットワークの3分の2以上を構成し、チェーンを再びファイナライズするために必要なスーパーマジョリティを満たすことになります。
+極端なケースでは、3分の1を超えるバリデータがオフラインになった結果、ネットワークがファイナライズを停止した場合、これらのユーザーはクアドラティック・イナーアクティビティ・リークとして知られる事態に見舞われます。これは、オフラインのバリデータアカウントからETHが指数関数的に流出することです。 これにより、非アクティブなバリデータの残高が16 ETHに達するまでETHをバーンすることで、最終的にネットワークが自己修復することが可能になり、その時点でバリデータプールから自動的に排出されます。 残りのオンラインのバリデータは、最終的に再びネットワークの3分の2以上を構成し、チェーンを再びファイナライズするために必要なスーパーマジョリティを満たすことになります。
+
要するに、これを完全に保証することはできませんが、誠意を持って行動し、マイノリティクライアントを実行し、署名鍵を一度に1台のマシンにのみ保持すれば、スラッシングされるリスクはほぼゼロになります。
@@ -166,14 +172,16 @@ ETHのホームステーキングを支援するツールやサービスは増
すべての製品版クライアントは同じ基本機能を提供するため、現在ネットワーク上のバリデータの大多数によって使用されていないクライアント、つまりマイノリティクライアントを選択することが実際には非常に重要です。 これは直感に反するように聞こえるかもしれませんが、マジョリティまたはスーパーマジョリティのクライアントを実行すると、そのクライアントにバグが発生した場合にスラッシングのリスクが高まります。 マイノリティクライアントを実行すると、これらのリスクが大幅に制限されます。
-クライアントの多様性がなぜ重要なのかについての詳細
+クライアントの多様性がなぜ重要なのかについての詳細
+
仮想プライベートサーバー（VPS）は家庭用ハードウェアの代わりに使用できますが、バリデータクライアントの物理的なアクセスと場所は重要です。 Amazon Web ServicesやDigital Oceanなどの中央集権型クラウドソリューションは、ネットワークの中央集権化を犠牲にして、ハードウェアを入手して運用する必要がないという利便性を提供します。
単一の中央集権型クラウドストレージソリューションで実行されるバリデータクライアントが多ければ多いほど、これらのユーザーにとって危険になります。 攻撃、規制上の要求、または単なる停電/インターネットの停止によるものであっても、これらのプロバイダーをオフラインにするようなイベントが発生すると、このサーバーに依存するすべてのバリデータクライアントが同時にオフラインになります。
-オフラインペナルティは、同時にオフラインになっている他の人の数に比例します。 VPSを使用すると、オフラインペナルティがより厳しくなるリスクが大幅に高まり、停止が十分に大きい場合にはクアドラティックリークやスラッシングのリスクが高まります。 ご自身のリスクとネットワークへのリスクを最小限に抑えるために、ユーザーは独自のハードウェアを入手して運用することを強くお勧めします。
+オフラインペナルティは、同時にオフラインになっている他の人の数に比例します。 VPSを使用すると、オフラインペナルティがより厳しくなるリスクが大幅に高まり、停止が十分に大きい場合にはクアドラティックリークやスラッシングのリスクが高まります。 ご自身のリスクとネットワークへのリスクを最小限に抑えるために、ユーザーは独自のハードウェアを入手して運用することを強くお勧めします。
+
@@ -185,7 +193,8 @@ ETHのホームステーキングを支援するツールやサービスは増
アンロックして残高全体を受け取るには、自分のバリデータを除外する手続きを完了する必要があります。
-ステーキングの引き出しについての詳細
+ステーキングの引き出しについての詳細
+
## 参考リンク{#further-reading}
diff --git a/public/content/translations/ja/staking/withdrawals/index.md b/public/content/translations/ja/staking/withdrawals/index.md
index 543f50e4aa6..1e00167070e 100644
--- a/public/content/translations/ja/staking/withdrawals/index.md
+++ b/public/content/translations/ja/staking/withdrawals/index.md
@@ -1,10 +1,10 @@
---
-title: ステーキングの引き出し
-description: ステーキングの引き出しとその仕組み、そしてステーカーが報酬を獲得するためにすべきことをまとめたページ
+title: "ステーキングの引き出し"
+description: "ステーキングの引き出しとその仕組み、そしてステーカーが報酬を獲得するためにすべきことをまとめたページ"
lang: ja
template: staking
image: /images/staking/leslie-withdrawal.png
-alt: サイのレズリーとそのステーキング報酬
+alt: "サイのレズリーとそのステーキング報酬"
sidebarDepth: 2
summaryPoints:
- 上海/カペラアップグレードによってイーサリアム上でのステーキング引き出しが可能になりました。
@@ -42,7 +42,8 @@ summaryPoints:
-各バリデータアカウントには、出金アドレスを1回のみ、1つだけ割り当てることができます。 アドレスを選択してコンセンサスレイヤーに送信した後は、これを取り消したり、再度変更したりすることはできません。 送信する前に、提供するアドレスの所有権と正確性を再確認してください。
+
+各バリデータアカウントには、出金アドレスを1回のみ、1つだけ割り当てることができます。 アドレスを選択してコンセンサスレイヤーに送信した後は、これを取り消したり、再度変更したりすることはできません。 送信する前に、提供するアドレスの所有権と正確性を再確認してください。
@@ -137,7 +138,8 @@ title="出金アドレスを一度提供したら、別の出金アドレスに
eventCategory="FAQ"
eventAction="Once I have provided a withdrawal address, can I change it to an alternative withdrawal address?"
eventName="read more">
-できません。出金認証情報を提供するプロセスは一度きりであり、送信後は変更できません。
+できません。出金認証情報を提供するプロセスは一度きりであり、送信後は変更できません。
+
引き出しアドレスは、スマートコントラクト(コードによって制御される) もしくは外部所有アカウント(EOA、秘密鍵によって制御される) のどちらかです。 現時点で、これらのアカウントがバリデーター認証情報の変更をコンセンサスレイヤーに伝える方法はありません。また、この機能を追加するとプロトコルが不必要に複雑になります。
-特定のバリデーターの引き出しアドレスを変更する代わりに、 ユーザーは、Safeのような鍵の交換が可能なスマートコントラクトを引き出しアドレスに設定することを選択することができます。 自分のEOAに資金を設定したユーザーは、完全引き出しを行ってステークした全ての資金を引き出し、 新しい認証情報を使って再度ステークすることができます。
+特定のバリデーターの引き出しアドレスを変更する代わりに、 ユーザーは、Safeのような鍵の交換が可能なスマートコントラクトを引き出しアドレスに設定することを選択することができます。 自分のEOAに資金を設定したユーザーは、完全引き出しを行ってステークした全ての資金を引き出し、 新しい認証情報を使って再度ステークすることができます。
+
[ステーキングプール](/staking/pools/)に参加している場合や、ステーキングトークンを保有している場合は、各サービスの運営方法が異なるため、ステーキング出金がどのように処理されるかの詳細について、プロバイダーに確認する必要があります。
一般的に、ユーザーは自由に元金であるステークされたETHを回収したり、利用するステーキングプロバイダーを変更したりできるはずです。 特定のプールが大きくなりすぎた場合は、撤退および償還し、より小さいプロバイダーで再びステーキングできます。 または、十分な量のETHを貯めたのであれば、[自宅からステーキング](/staking/solo/)することも可能です。
-
-はい、バリデータが出金アドレスを提供している限り、自動的に行われます。 これは、最初に引き出しを有効にするために一度だけ設定する必要があります。すると、報酬の支払いは各バリデーターのスイープによって数日ごとに自動的に発生します。
+はい、バリデータが出金アドレスを提供している限り、自動的に行われます。 これは、最初に引き出しを有効にするために一度だけ設定する必要があります。すると、報酬の支払いは各バリデーターのスイープによって数日ごとに自動的に発生します。
+
いいえ、バリデーターがネットワーク上でまだアクティブである場合、完全引き出しは自動的には行われません。 これには自主的な終了を手動で行う必要があります。
バリデーターが終了プロセスを完了し、アカウントが引き出し認証情報に紐づいている場合、残高は次のバリデータースイープの間に引き出されます。
-
出金は自動的にプッシュされるように設計されており、ステークに積極的に貢献していないETHが送金されます。 これには、終了プロセスを完了したアカウントの全残高も含まれてます。
-特定の量のETHの引き出しを手動でリクエストすることはできません。
+特定の量のETHの引き出しを手動でリクエストすることはできません。
+
バリデータのオペレータは、「Staking Launchpad Withdrawals」のページにアクセスすることをお勧めします。このページでは、引き出しのためにバリデータが準備することについて詳細、イベントのタイミング、引き出しの機能に関する詳細が記載されています。
まずテストネットで設定を試すには、Hoodiテストネット・ステーキング・ランチパッドにアクセスして始めましょう。
-
-できません。 一度バリデーターを終了し、残高がすべて引き出されると、そのバリデーターに入金された追加の資金は次のバリデータースイープで引き出しアドレスに自動的に移されます。 そのためETHを再びステークするには、新しいバリデーターを起動する必要があります。
+できません。 一度バリデーターを終了し、残高がすべて引き出されると、そのバリデーターに入金された追加の資金は次のバリデータースイープで引き出しアドレスに自動的に移されます。 そのためETHを再びステークするには、新しいバリデーターを起動する必要があります。
+
## 参考リンク{#further-reading}
diff --git a/public/content/translations/ja/web3/index.md b/public/content/translations/ja/web3/index.md
index 7119b837d02..6aa32fb23f4 100644
--- a/public/content/translations/ja/web3/index.md
+++ b/public/content/translations/ja/web3/index.md
@@ -1,6 +1,6 @@
---
-title: Web3とは、またその重要性
-description: 次世代ワールドワイドウェブであるWeb3の紹介、およびその重要性
+title: "Web3とは、またその重要性"
+description: "次世代ワールドワイドウェブであるWeb3の紹介、およびその重要性"
lang: ja
---
@@ -69,7 +69,8 @@ Web3では、[非代替性トークン(NFT)](/glossary/#nft)を通じて直接
- 非代替性トークン(NFT)について学ぶ
+ 非代替性トークン(NFT)について学ぶ
+
NFTの詳細
@@ -97,7 +98,8 @@ DAOは技術的には、リソース(トークン)のプールに対する分散
- 分散型自律組織(DAO)についてもっと知る
+ 分散型自律組織(DAO)についてもっと知る
+
DAOの詳細
diff --git a/public/content/translations/ja/what-are-apps/index.md b/public/content/translations/ja/what-are-apps/index.md
index 6774f562129..21f44ada6e2 100644
--- a/public/content/translations/ja/what-are-apps/index.md
+++ b/public/content/translations/ja/what-are-apps/index.md
@@ -1,14 +1,14 @@
---
-title: イーサリアムアプリケーション
-metaTitle: イーサリアムアプリケーション | イーサリアム上の分散型アプリケーション
-description: イーサリアム上のアプリは無料で、世界中どこからでも使え、民間企業のサーバーではなくパブリック・ブロックチェーンを利用しています。 つまり、すべてのプロジェクトで同じアカウントを使え、プライバシーを保つことができます。
+title: "イーサリアムアプリケーション"
+metaTitle: "イーサリアムアプリケーション | イーサリアム上の分散型アプリケーション"
+description: "イーサリアム上のアプリは無料で、世界中どこからでも使え、民間企業のサーバーではなくパブリック・ブロックチェーンを利用しています。 つまり、すべてのプロジェクトで同じアカウントを使え、プライバシーを保つことができます。"
lang: ja
template: use-cases
emoji: ":handshake:"
sidebarDepth: 2
showDropdown: false
image: /images/doge-computer.png
-summary: イーサリアム上のアプリは無料で、世界中どこからでも使え、民間企業のサーバーではなくパブリック・ブロックチェーンを利用しています。 つまり、すべてのプロジェクトで同じアカウントを使え、プライバシーを保つことができます。
+summary: "イーサリアム上のアプリは無料で、世界中どこからでも使え、民間企業のサーバーではなくパブリック・ブロックチェーンを利用しています。 つまり、すべてのプロジェクトで同じアカウントを使え、プライバシーを保つことができます。"
---
## 超パワフルなアプリ {#apps-with-superpowers}
@@ -51,7 +51,6 @@ summary: イーサリアム上のアプリは無料で、世界中どこから
-
## イーサリアムアプリはレゴのようなもの {#ethereum-apps-are-like-legos}
diff --git a/public/content/translations/ja/whitepaper/index.md b/public/content/translations/ja/whitepaper/index.md
index c620eba0de1..acd44ca27bb 100644
--- a/public/content/translations/ja/whitepaper/index.md
+++ b/public/content/translations/ja/whitepaper/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアムホワイトペーパー
-description: イーサリアムのローンチに先んじて2013年に公開されたイーサリアムの紹介論文
+title: "イーサリアムホワイトペーパー"
+description: "イーサリアムのローンチに先んじて2013年に公開されたイーサリアムの紹介論文"
lang: ja
sidebarDepth: 2
hideEditButton: true
diff --git a/public/content/translations/ja/wrapped-eth/index.md b/public/content/translations/ja/wrapped-eth/index.md
index 21ede559458..09111842915 100644
--- a/public/content/translations/ja/wrapped-eth/index.md
+++ b/public/content/translations/ja/wrapped-eth/index.md
@@ -1,6 +1,6 @@
---
-title: ラップドイーサ(WETH) とは
-description: ラップドイーサ(WETH) — Ether (ETH) のERC-20互換ラッパーの紹介。
+title: "ラップドイーサ(WETH) とは"
+description: "ラップドイーサ(WETH) — Ether (ETH) のERC-20互換ラッパーの紹介。"
lang: ja
---
@@ -8,7 +8,8 @@ lang: ja
Ether (ETH) はイーサリアムのネイティブ暗号通貨です。 ステーキングや通貨としての使用、計算のためのガス料金の支払いなど、さまざまな目的で使用されます。 \*\*WETHはETHの機能を拡張したもので、多くのアプリケーションやイーサリアム上の他のデジタル資産である [ERC-20トークン](/glossary/#erc-20) \*\* で必要とされる追加機能を持っています。 ERC-20トークンと連携するためには、ETHも同じERC-20規格に従う必要があります。
@@ -40,19 +41,16 @@ WETHをETHに戻すには、WETHスマートコントラクトを使用します
ETHをWETHにラップする、またはWETHをETHにアンラップする際には、WETHコントラクトを使用してガス料金を支払います。
-
WETHは、シンプルで実践テスト済みのスマートコントラクトに基づいているため、一般的に安全と考えられています。 WETHコントラクトは、イーサリアム上のスマートコントラクトにおける最高のセキュリティ基準である形式的検証も受けています。
-
このページで説明している [WETHの標準的な実装](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) 以外にも、他のバリエーションが存在します。 これらはアプリデベロッパーによって作成されたカスタムトークンや、他のブロックチェーン上で発行されたバージョンであり、異なる動作をしたり、異なるセキュリティ特性を持つ可能性があります。 **どのWETH実装とやり取りしているかを確認するために、必ずトークン情報を再確認してください。**
-
@@ -60,7 +58,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/zero-knowledge-proofs/index.md b/public/content/translations/ja/zero-knowledge-proofs/index.md
index 3dace1f9178..6c4e9d51967 100644
--- a/public/content/translations/ja/zero-knowledge-proofs/index.md
+++ b/public/content/translations/ja/zero-knowledge-proofs/index.md
@@ -1,6 +1,6 @@
---
-title: ゼロ知識証明
-description: 初心者向けの、非技術的なゼロ知識証明入門
+title: "ゼロ知識証明"
+description: "初心者向けの、非技術的なゼロ知識証明入門"
lang: ja
---
@@ -59,8 +59,8 @@ lang: ja
ブータンのNDIに関する詳細は、分散型IDのケーススタディをご覧ください。
-
-
+
+
### 人間性の証明 {#proof-of-humanity}
From cb376c217fb820272c4768b01e31052f8ffe7c0c Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 12:39:08 +0000
Subject: [PATCH 04/14] fix(i18n): run sanitizer on ja translations
---
.../translations/ja/ai-agents/index.md | 1 +
.../content/translations/ja/bridges/index.md | 2 +-
.../ja/community/get-involved/index.md | 2 +-
.../translations/ja/community/grants/index.md | 3 +-
.../translations/ja/community/online/index.md | 25 ++++++++--
.../ja/community/research/index.md | 2 +-
.../contributing/design-principles/index.md | 2 +-
.../translatathon/details/index.md | 2 +-
.../translatathon/index.md | 2 +-
public/content/translations/ja/dao/index.md | 6 +--
.../ja/decentralized-identity/index.md | 4 +-
public/content/translations/ja/defi/index.md | 5 +-
public/content/translations/ja/desci/index.md | 2 +-
.../ja/developers/docs/accounts/index.md | 6 +--
.../ja/developers/docs/apis/backend/index.md | 6 +--
.../developers/docs/apis/javascript/index.md | 6 +--
.../ja/developers/docs/apis/json-rpc/index.md | 2 +-
.../ja/developers/docs/blocks/index.md | 6 +--
.../ja/developers/docs/bridges/index.md | 2 +-
.../docs/consensus-mechanisms/index.md | 6 +--
.../docs/consensus-mechanisms/poa/index.md | 20 ++++----
.../pos/attack-and-defense/index.md | 4 +-
.../pos/attestations/index.md | 2 +-
.../pos/block-proposal/index.md | 5 +-
.../consensus-mechanisms/pos/gasper/index.md | 2 +-
.../docs/consensus-mechanisms/pos/index.md | 8 ++--
.../consensus-mechanisms/pos/keys/index.md | 2 +-
.../pos/pos-vs-pow/index.md | 2 +-
.../pos/rewards-and-penalties/index.md | 2 +-
.../pos/weak-subjectivity/index.md | 4 +-
.../docs/consensus-mechanisms/pow/index.md | 6 +--
.../consensus-mechanisms/pow/mining/index.md | 4 +-
.../dagger-hashimoto/index.md | 4 +-
.../mining/mining-algorithms/ethash/index.md | 2 +-
.../pow/mining/mining-algorithms/index.md | 4 +-
.../ja/developers/docs/dapps/index.md | 4 +-
.../block-explorers/index.md | 6 +--
.../docs/data-and-analytics/index.md | 4 +-
.../index.md | 4 +-
.../docs/data-availability/index.md | 4 +-
.../data-structures-and-encoding/index.md | 2 +-
.../patricia-merkle-trie/index.md | 4 +-
.../data-structures-and-encoding/rlp/index.md | 4 +-
.../data-structures-and-encoding/ssz/index.md | 2 +-
.../web3-secret-storage-definition/index.md | 4 +-
.../docs/development-networks/index.md | 6 +--
.../developers/docs/ethereum-stack/index.md | 2 +-
.../ja/developers/docs/evm/index.md | 4 +-
.../ja/developers/docs/frameworks/index.md | 6 +--
.../ja/developers/docs/gas/index.md | 4 +-
.../ja/developers/docs/ides/index.md | 2 +-
.../developers/docs/intro-to-ether/index.md | 4 +-
.../docs/intro-to-ethereum/index.md | 3 +-
.../ja/developers/docs/mev/index.md | 4 +-
.../developers/docs/networking-layer/index.md | 4 +-
.../network-addresses/index.md | 4 +-
.../networking-layer/portal-network/index.md | 2 +-
.../ja/developers/docs/networks/index.md | 4 +-
.../nodes-and-clients/archive-nodes/index.md | 6 +--
.../client-diversity/index.md | 6 +--
.../docs/nodes-and-clients/index.md | 6 +--
.../nodes-and-clients/light-clients/index.md | 2 +-
.../node-architecture/index.md | 2 +-
.../nodes-as-a-service/index.md | 8 ++--
.../nodes-and-clients/run-a-node/index.md | 6 +--
.../ja/developers/docs/oracles/index.md | 6 +--
.../programming-languages/javascript/index.md | 2 +-
.../ja/developers/docs/scaling/index.md | 4 +-
.../docs/scaling/optimistic-rollups/index.md | 2 +-
.../developers/docs/scaling/plasma/index.md | 6 +--
.../docs/scaling/sidechains/index.md | 2 +-
.../docs/scaling/state-channels/index.md | 4 +-
.../developers/docs/scaling/validium/index.md | 4 +-
.../docs/scaling/zk-rollups/index.md | 2 +-
.../docs/smart-contracts/anatomy/index.md | 6 +--
.../docs/smart-contracts/compiling/index.md | 6 +--
.../smart-contracts/composability/index.md | 2 +-
.../docs/smart-contracts/deploying/index.md | 6 +--
.../formal-verification/index.md | 2 +-
.../developers/docs/smart-contracts/index.md | 5 +-
.../docs/smart-contracts/languages/index.md | 22 ++++++++-
.../docs/smart-contracts/libraries/index.md | 4 +-
.../docs/smart-contracts/naming/index.md | 4 +-
.../docs/smart-contracts/security/index.md | 4 +-
.../docs/smart-contracts/testing/index.md | 47 ++++++++++---------
.../docs/smart-contracts/upgrading/index.md | 19 ++++----
.../docs/smart-contracts/verifying/index.md | 2 +-
.../ja/developers/docs/standards/index.md | 2 +-
.../docs/standards/tokens/erc-1155/index.md | 4 +-
.../docs/standards/tokens/erc-1363/index.md | 4 +-
.../docs/standards/tokens/erc-20/index.md | 4 +-
.../docs/standards/tokens/erc-223/index.md | 4 +-
.../docs/standards/tokens/erc-4626/index.md | 4 +-
.../docs/standards/tokens/erc-721/index.md | 4 +-
.../docs/standards/tokens/erc-777/index.md | 4 +-
.../developers/docs/standards/tokens/index.md | 4 +-
.../ja/developers/docs/storage/index.md | 4 +-
.../ja/developers/docs/transactions/index.md | 6 +--
.../ja/developers/docs/web2-vs-web3/index.md | 2 +-
.../ja/developers/docs/wrapped-eth/index.md | 8 +---
.../index.md | 22 ++++-----
.../erc-721-vyper-annotated-code/index.md | 1 +
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 4 +-
.../index.md | 4 +-
.../index.md | 4 +-
.../index.md | 2 +-
.../secure-development-workflow/index.md | 2 +-
.../tutorials/send-token-etherjs/index.md | 4 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 4 +-
.../index.md | 4 +-
.../token-integration-checklist/index.md | 2 +-
.../uniswap-v2-annotated-code/index.md | 3 +-
.../tutorials/using-websockets/index.md | 2 +-
.../ja/energy-consumption/index.md | 4 +-
.../translations/ja/eth/supply/index.md | 2 +-
.../translations/ja/governance/index.md | 4 +-
.../index.md | 3 +-
.../how-to-revoke-token-access/index.md | 3 +-
.../ja/guides/how-to-swap-tokens/index.md | 3 +-
.../ja/guides/how-to-use-a-bridge/index.md | 3 +-
.../ja/guides/how-to-use-a-wallet/index.md | 3 +-
.../index.md | 7 +--
public/content/translations/ja/nft/index.md | 5 +-
.../content/translations/ja/payments/index.md | 16 ++++---
.../ja/prediction-markets/index.md | 4 +-
.../ja/real-world-assets/index.md | 4 +-
.../translations/ja/restaking/index.md | 2 +-
.../ja/roadmap/account-abstraction/index.md | 2 +-
.../ja/roadmap/danksharding/index.md | 2 +-
.../translations/ja/roadmap/dencun/index.md | 2 +-
.../translations/ja/roadmap/fusaka/index.md | 4 +-
.../ja/roadmap/fusaka/peerdas/index.md | 2 +-
.../translations/ja/roadmap/merge/index.md | 2 +-
.../ja/roadmap/merge/issuance/index.md | 8 +++-
.../translations/ja/roadmap/pbs/index.md | 2 +-
.../translations/ja/roadmap/pectra/index.md | 4 +-
.../ja/roadmap/pectra/maxeb/index.md | 2 +-
.../roadmap/secret-leader-election/index.md | 2 +-
.../ja/roadmap/single-slot-finality/index.md | 2 +-
.../ja/roadmap/statelessness/index.md | 2 +-
.../ja/roadmap/verkle-trees/index.md | 2 +-
.../content/translations/ja/security/index.md | 2 +-
.../translations/ja/smart-contracts/index.md | 2 +-
.../translations/ja/social-networks/index.md | 2 +-
.../translations/ja/staking/dvt/index.md | 2 +-
.../translations/ja/staking/pools/index.md | 2 +-
.../translations/ja/staking/saas/index.md | 3 +-
.../translations/ja/staking/solo/index.md | 5 +-
.../ja/staking/withdrawals/index.md | 2 +-
public/content/translations/ja/web3/index.md | 8 ++--
.../translations/ja/what-are-apps/index.md | 2 +-
.../translations/ja/whitepaper/index.md | 2 +-
.../translations/ja/wrapped-eth/index.md | 5 +-
.../ja/zero-knowledge-proofs/index.md | 2 +-
159 files changed, 376 insertions(+), 333 deletions(-)
diff --git a/public/content/translations/ja/ai-agents/index.md b/public/content/translations/ja/ai-agents/index.md
index c2afcfc59fc..fc2be54d839 100644
--- a/public/content/translations/ja/ai-agents/index.md
+++ b/public/content/translations/ja/ai-agents/index.md
@@ -113,6 +113,7 @@ LunaのXでのソーシャルキャンペーン「#LunaMuralChallenge」にお
知っておくと良いこと
AIエージェントおよび関連ツールは、まだ開発の初期段階にあり、非常に実験的な段階です——使用には注意が必要です。
+
## チャットコマンドでウォレットを操作する {#control-your-wallet-using-chat-commands}
diff --git a/public/content/translations/ja/bridges/index.md b/public/content/translations/ja/bridges/index.md
index 0446689b507..19656bcf4d1 100644
--- a/public/content/translations/ja/bridges/index.md
+++ b/public/content/translations/ja/bridges/index.md
@@ -135,7 +135,7 @@ _Web3は、L1ブロックチェーンとL2スケーリングソリューショ
## 広範なイーサリアムエコシステム {#broad-ethereum-ecosystem}
diff --git a/public/content/translations/ja/community/online/index.md b/public/content/translations/ja/community/online/index.md
index 42a0d46984a..ada756af2ad 100644
--- a/public/content/translations/ja/community/online/index.md
+++ b/public/content/translations/ja/community/online/index.md
@@ -34,15 +34,34 @@ lang: ja
## フォーラム {#forums}
-r/ethereum - イーサリアムに関するすべて r/ethfinance - DeFi を含むイーサリアムの金融面 r/ethdev - イーサリアム開発に特化 r/ethtrader - トレンドと市場分析 r/ethstaker - イーサリアムでのステーキングに関心のあるすべての人を歓迎 Fellowship of Ethereum Magicians - イーサリアムの技術標準を中心としたコミュニティ Ethereum Stackexchange - イーサリアムデベロッパーのためのディスカッションとヘルプ Ethereum Research - 暗号経済学研究のための最も影響力のあるメッセージボード
+r/ethereum - イーサリアムに関するすべて
+r/ethfinance - DeFi を含むイーサリアムの金融面
+r/ethdev - イーサリアム開発に特化
+r/ethtrader - トレンドと市場分析
+r/ethstaker - イーサリアムでのステーキングに関心のあるすべての人を歓迎
+Fellowship of Ethereum Magicians - イーサリアムの技術標準を中心としたコミュニティ
+Ethereum Stackexchange - イーサリアムデベロッパーのためのディスカッションとヘルプ
+Ethereum Research - 暗号経済学研究のための最も影響力のあるメッセージボード
## チャットルーム {#chat-rooms}
-Ethereum Cat Herders - イーサリアム開発へのプロジェクト管理サポートの提供を中心としたコミュニティ Ethereum Hackers - ETHGlobalが運営するDiscordチャット: 世界中のイーサリアムハッカーのためのオンラインコミュニティ CryptoDevs - イーサリアム開発に特化したDiscordコミュニティ EthStaker Discord - 既存および潜在的なステーカーのための、コミュニティによるガイダンス、教育、サポート、リソース Ethereum.org website team - チームやコミュニティの人々と一緒にethereum.orgのWeb開発やデザインについてチャットしましょう Matos Discord - ビルダー、業界の重鎮、イーサリアムの愛好家が集まるWeb3クリエイターコミュニティ。 Web3開発、設計、文化に熱心です。 ぜひ一緒に開発しましょう。 Solidity Gitter - Solidity開発のためのチャット (Gitter) Solidity Matrix - Solidity開発のためのチャット (Matrix) Ethereum Stack Exchange - 質問と回答のフォーラム Peera Community Forum - 分散型の質問と回答のフォーラム
+Ethereum Cat Herders - イーサリアム開発へのプロジェクト管理サポートの提供を中心としたコミュニティ
+Ethereum Hackers - ETHGlobalが運営するDiscordチャット: 世界中のイーサリアムハッカーのためのオンラインコミュニティ
+CryptoDevs - イーサリアム開発に特化したDiscordコミュニティ
+EthStaker Discord - 既存および潜在的なステーカーのための、コミュニティによるガイダンス、教育、サポート、リソース
+Ethereum.org website team - チームやコミュニティの人々と一緒にethereum.orgのWeb開発やデザインについてチャットしましょう
+Matos Discord - ビルダー、業界の重鎮、イーサリアムの愛好家が集まるWeb3クリエイターコミュニティ。 Web3開発、設計、文化に熱心です。 ぜひ一緒に開発しましょう。
+Solidity Gitter - Solidity開発のためのチャット (Gitter)
+Solidity Matrix - Solidity開発のためのチャット (Matrix)
+Ethereum Stack Exchange - 質問と回答のフォーラム
+Peera Community Forum - 分散型の質問と回答のフォーラム
## YouTubeとX (旧Twitter) {#youtube-and-twitter}
-Ethereum Foundation - イーサリアム・ファウンデーションからの最新情報を入手 @ethereum - コミュニティ向けの主要なイーサリアムアカウント @ethereumfndn - イーサリアム・ファウンデーションの公式アカウント @ethdotorg - 成長を続けるグローバルコミュニティのために構築された、イーサリアムへのポータル
+Ethereum Foundation - イーサリアム・ファウンデーションからの最新情報を入手
+@ethereum - コミュニティ向けの主要なイーサリアムアカウント
+@ethereumfndn - イーサリアム・ファウンデーションの公式アカウント
+@ethdotorg - 成長を続けるグローバルコミュニティのために構築された、イーサリアムへのポータル
diff --git a/public/content/translations/ja/dao/index.md b/public/content/translations/ja/dao/index.md
index 60a0901a248..8ffbf3f879d 100644
--- a/public/content/translations/ja/dao/index.md
+++ b/public/content/translations/ja/dao/index.md
@@ -70,9 +70,7 @@ DAOのバックボーンは、組織のルールを定義し、グループの
デリゲーション(委任)とは、分散型自律組織版の議会制民主主義のようなものです。 トークン保有者は、プロトコルを管理し、最新情報を入手することにコミットする立候補者に投票権を委任します。
-#### 有名な例 {#governance-example}
-
-[ENS](https://claim.ens.domains/delegate-ranking) – ENS保有者は、自分たちの代表として、熱心なコミュニティメンバーに投票を委任できます。
+#### 有名な例 {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – ENS保有者は、自分たちの代表として、熱心なコミュニティメンバーに投票を委任できます。
### 自動取引ガバナンス {#governance-example}
@@ -146,7 +144,7 @@ _主にプロトコルや[dapps](/glossary/#dapp)の分散型開発とガバナ
- [DAOstackのホログラフィック・コンセンサスでDAOを作成する](https://alchemy.daostack.io/daos/create)
- [DeGov LauncherでDAOを立ち上げる](https://docs.degov.ai/integration/deploy)
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
### DAO関連の記事 {#dao-articles}
diff --git a/public/content/translations/ja/decentralized-identity/index.md b/public/content/translations/ja/decentralized-identity/index.md
index 7f015bcc41c..12f60ee812f 100644
--- a/public/content/translations/ja/decentralized-identity/index.md
+++ b/public/content/translations/ja/decentralized-identity/index.md
@@ -108,6 +108,7 @@ Ethereumの[レイヤー2](/layer-2/)ネットワークであるZKSync Era上に
アテステーションは身分を証明するIDとは異なります。 アテステーションは、特定のアイデンティティを参照するためのIDを_含み_、このアイデンティティに関連する属性についての主張を行います。 つまり、運転免許証には身分を証明するID(氏名、生年月日、住所)が含まれ、同時に、運転できるという法的権利(属性)に関しても証明します。
### 分散型IDとは {#what-are-decentralized-identifiers}
+
氏名やメールアドレスといった従来のIDは、政府やメールプロバイダーといったサードパーティに依存します。 分散型ID (DID)は、中央集権組織により発行、管理、制御されないという点で異なります。
分散型IDは、自分自身で発行、保有、管理することができます。 [Ethereumアカウント](/glossary/#account)は、分散型IDの一例です。 誰からの許可も不要で、また中央台帳に保存する必要もなく、好きなだけアカウントを作成することができます。
@@ -129,6 +130,7 @@ Ethereumの[レイヤー2](/layer-2/)ネットワークであるZKSync Era上に
分散型IDの正当性を確認する必要がある場合は、ブロックチェーンで関連する公開鍵を調べることができます。 ここが、サードパーティによる認証を必要とする従来のIDとは異なる点です。
## 分散型アイデンティティを可能にする分散型IDとアテステーション {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity}
+
分散型アイデンティティとは、アイデンティティに関連する情報は自己管理され、プライベートでポータブルであるべきという考え方であり、分散型IDとアテステーションにより成り立っています。
分散型IDの文脈において、アテステーション (別名[検証可能な資格情報](https://www.w3.org/TR/vc-data-model/)) は、発行者によってなされる、改ざん不可能で暗号技術によって検証可能な主張です。 エンティティ(組織など)が発行するすべてのアテステーション、すなわち検証可能な資格情報は、その分散型ID (DID)と紐づけられます。
@@ -190,7 +192,7 @@ Ethereumの[レイヤー2](/layer-2/)ネットワークであるZKSync Era上に
- **[walt.id](https://walt.id)** — _開発者や組織が自己主権型IDとNFT/SBTを活用できるようにする、オープンソースの分散型IDおよびウォレットインフラストラクチャ。_
- **[Veramo](https://veramo.io/)** - _誰でもアプリケーションで暗号技術によって検証可能なデータを簡単に使用できるようにするJavaScriptフレームワーク。_
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
### 記事 {#articles}
diff --git a/public/content/translations/ja/defi/index.md b/public/content/translations/ja/defi/index.md
index 0a4e11f1299..9d68d98127d 100644
--- a/public/content/translations/ja/defi/index.md
+++ b/public/content/translations/ja/defi/index.md
@@ -67,8 +67,7 @@ summaryPoint3: "オープンソース技術に基づき、誰でもプログラ
- イーサリアムを初めて使う方にお勧めの分散型金融(DeFi)アプリケーション
-
+ イーサリアムを初めて使う方にお勧めの分散型金融(DeFi)アプリケーション
DeFiアプリを探す
@@ -339,7 +338,7 @@ Ethereum製品は、他のソフトウェアと同様に、バグや不正搾取
dapps構築の詳細
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
### DeFiデータ {#defi-data}
diff --git a/public/content/translations/ja/desci/index.md b/public/content/translations/ja/desci/index.md
index fe27447831a..e12a7708586 100644
--- a/public/content/translations/ja/desci/index.md
+++ b/public/content/translations/ja/desci/index.md
@@ -113,7 +113,7 @@ Web3の様式を活用することで科学データへのアクセスが大幅
新しいプロジェクトの掲載提案を歓迎します。まずは[掲載ポリシー](/contributing/adding-desci-projects/)をご覧ください。
-## 参考リンク{#further-reading}
+## 参考リンク {#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/)
diff --git a/public/content/translations/ja/developers/docs/accounts/index.md b/public/content/translations/ja/developers/docs/accounts/index.md
index ab665dc15f2..5e7a041ee2d 100644
--- a/public/content/translations/ja/developers/docs/accounts/index.md
+++ b/public/content/translations/ja/developers/docs/accounts/index.md
@@ -6,7 +6,7 @@ lang: ja
イーサリアムアカウントは、イーサ（ETH）残高を持ち、イーサリアム上でメッセージを送信できるエンティティです。 アカウントはユーザーが管理し、スマートコントラクトとしてデプロイすることができます。
-## 前提条件{#prerequisites}
+## 前提条件 {#prerequisites}
このページをよりよく理解するために、まず[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。
@@ -125,13 +125,13 @@ WARN [10-28|16:19:09.306] パスワードを忘れないでください!
-## 前提条件{#prerequisites}
+## 前提条件 {#prerequisites}
このページについて深く理解するには、事前に[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。
@@ -75,7 +75,7 @@ lang: ja
ネットワークを安全に保つために必要なエネルギー量は、プルーフ・オブ・ワークが批判を受ける大きな要因です。 セキュリティと分散化を維持するために、プルーフ・オブ・ワークのイーサリアムは多量のエネルギーを消費しました。 プルーフ・オブ・ステークへの移行直前、イーサリアムのマイナーは年間合計で約70 TWhを消費していました(2022年7月18日の[digiconomist](https://digiconomist.net/)によると、これはチェコ共和国の消費量とほぼ同じです)。
-## メリットとデメリット{#pros-and-cons}
+## メリットとデメリット {#pros-and-cons}
| 長所 | 短所 |
| ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
@@ -98,7 +98,7 @@ lang: ja
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/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
index 4ec699c04a2..b526d4117d6 100644
--- 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
@@ -33,7 +33,7 @@ published: 2023-04-11
このガイドでは、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}
+## Kurtosisのセットアップ {#setting-up-kurtosis}
続行する前に、次のものがあることを確認してください。
@@ -41,7 +41,7 @@ published: 2023-04-11
- [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}
+## ローカルイーサリアムテストネットのインスタンス化 {#instantiate-testnet}
ローカルイーサリアムテストネットを起動するには、次を実行します。
@@ -93,7 +93,7 @@ d7b802f623e8 el-client-0 engine-rpc: 8551/t
おめでとうございます！ Kurtosisを使用して、CL (`lighthouse`)とELクライアント(`geth`)を持つローカルイーサリアムテストネットをDocker経由でインスタンス化しました。
-### レビュー{#review-instantiate-testnet}
+### レビュー {#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/)内にローカルイーサリアムテストネットを起動するよう指示するコマンドを実行しました。 エンクレーブ内には、「ファイルアーティファクト」と「ユーザーサービス」の両方があります。
@@ -101,9 +101,9 @@ d7b802f623e8 el-client-0 engine-rpc: 8551/t
ユーザーサービスには、エンクレーブで動作しているすべてのコンテナ化されたサービスが表示されます。 ELクライアントとCLクライアントの両方を備えた単一のノードが作成されていることがわかります。
-## dApp開発環境をローカルイーサリアムテストネットに接続する{#connect-your-dapp}
+## dApp開発環境をローカルイーサリアムテストネットに接続する {#connect-your-dapp}
-### dApp開発環境のセットアップ{#set-up-dapp-env}
+### dApp開発環境のセットアップ {#set-up-dapp-env}
実行中のローカルテストネットができたので、dApp開発環境を接続してローカルテストネットを使用できます。 このガイドでは、Hardhatフレームワークを使用して、ブラックジャックdAppをローカルテストネットにデプロイします。
@@ -120,7 +120,7 @@ git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-ku
- [`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}
+### Hardhatがローカルテストネットを使用するように設定する {#configure-hardhat}
dApp開発環境がセットアップされたので、今度はHardhatを接続して、Kurtosisを使用して生成されたローカルイーサリアムテストネットを使用します。 これを実現するには、`hardhat.config.ts`設定ファイルの`localnet`構造体にある`<$YOUR_PORT>`を、任意の`el-client-`サービスから出力されたrpc uriのポートに置き換えます。 このサンプルケースでは、ポートは`64248`になります。 ポートは異なります。
@@ -162,7 +162,7 @@ npx hardhat balances --network localnet
これにより、Hardhatがローカルテストネットを使用しており、`eth-network-package`によって作成された事前に入金されたアカウントを検出していることが確認できます。
-### dAppをローカルでデプロイしてテストする{#deploy-and-test-dapp}
+### dAppをローカルでデプロイしてテストする {#deploy-and-test-dapp}
dApp開発環境がローカルイーサリアムテストネットに完全に接続されたので、ローカルテストネットを使用してdAppに対する開発およびテストワークフローを実行できます。
@@ -197,15 +197,15 @@ ChipToken
1件合格 (654ms)
```
-### レビュー{#review-dapp-workflows}
+### レビュー {#review-dapp-workflows}
この時点で、dApp開発環境をセットアップし、Kurtosisによって作成されたローカルイーサリアムネットワークに接続し、dAppに対してコンパイル、デプロイ、および簡単なテストを実行しました。
次に、さまざまなネットワーク構成でdAppをテストするために、基盤となるネットワークをどのように構成できるかを見ていきましょう。
-## ローカルイーサリアムテストネットの設定{#configure-testnet}
+## ローカルイーサリアムテストネットの設定 {#configure-testnet}
-### クライアント構成とノード数の変更{#configure-client-config-and-num-nodes}
+### クライアント構成とノード数の変更 {#configure-client-config-and-num-nodes}
ローカルイーサリアムテストネットは、開発またはテストしたいシナリオや特定のネットワーク構成に応じて、異なるELおよびCLクライアントペア、ならびにさまざまな数のノードを使用するように構成できます。 これは、一度セットアップすれば、カスタマイズされたローカルテストネットを起動し、それを使用して同じワークフロー(デプロイ、テストなど)を実行できることを意味します。 さまざまなネットワーク構成の下で、すべてが期待どおりに機能することを確認します。 変更できる他のパラメータの詳細については、このリンクをご覧ください。
@@ -364,7 +364,7 @@ ad6f401126fa el-client-2 engine-rpc: 8551/t
何がうまくいったか、何を改善できるか、また質問への回答など、ご意見をお聞かせください。 [GitHub](https://github.com/kurtosis-tech/kurtosis/issues/new/choose)または[メール](mailto:feedback@kurtosistech.com)でお気軽にご連絡ください。
-### その他の例とガイド{#other-examples-guides}
+### その他の例とガイド {#other-examples-guides}
[クイックスタート](https://docs.kurtosis.com/quickstart)(PostgresデータベースとAPIを構築します)や、[awesome-kurtosisリポジトリ](https://github.com/kurtosis-tech/awesome-kurtosis)にあるその他の例を確認することをお勧めします。そこには、次のようなパッケージを含む素晴らしい例があります。
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 97a3068b896..f33129b9ca4 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
@@ -282,6 +282,7 @@ Pythonとは対照的に、Vyperは[静的型付け言語](https://wikipedia.org
```python
### ビュー関数 ###
+
```
これらは、トークンに関する情報をユーザーや他のコントラクトが利用できるようにするビュー関数です。
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 6c591600482..7e34b96fcf2 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
@@ -6,7 +6,7 @@ tags: [ "JavaScript", "ethers.js", "ノード", "クエリ", "Alchemy" ]
skill: beginner
lang: ja
published: 2020-10-30
-source: "中"
+source: Medium
sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f
---
diff --git a/public/content/translations/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 c9011dcae4f..58df2c54541 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
@@ -6,7 +6,7 @@ lang: ja
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
---
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 1b986597754..177724c76a1 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
@@ -6,7 +6,7 @@ lang: ja
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
---
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 4643908580c..7e10233e51b 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
@@ -6,7 +6,7 @@ lang: ja
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
---
@@ -393,6 +393,7 @@ symbolic_var = m.make_symbolic_value()
contract_account.f(symbolic_var)
## 実行がREVERTまたはINVALIDで終了するかどうかを確認します
+
for state in m.terminated_states:
last_tx = state.platform.transactions[-1]
if last_tx.result in ['REVERT', 'INVALID']:
@@ -501,6 +502,7 @@ contract_account.f(symbolic_var)
no_bug_found = True
## 実行がREVERTまたはINVALIDで終了するかどうかを確認します
+
for state in m.terminated_states:
last_tx = state.platform.transactions[-1]
if last_tx.result in ['REVERT', 'INVALID']:
diff --git a/public/content/translations/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 12cee65e603..c881486e9a9 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
@@ -6,7 +6,7 @@ lang: ja
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
---
@@ -65,7 +65,7 @@ slither project_paths
[crytic.io](https://github.com/crytic)を使用すると、プライベートな検出器やGitHubとの統合にアクセスできます。
-## 静的解析{#static-analysis}
+## 静的解析 {#static-analysis}
Slither静的解析フレームワークの機能と設計については、ブログ投稿 ([1](https://blog.trailofbits.com/2018/10/19/slither-a-solidity-static-analysis-framework/), [2](https://blog.trailofbits.com/2019/05/27/slither-the-leading-static-analyzer-for-smart-contracts/)) や [学術論文](https://github.com/trailofbits/publications/blob/master/papers/wetseb19.pdf)で説明されています。
diff --git a/public/content/translations/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/monitoring-geth-with-influxdb-and-grafana/index.md b/public/content/translations/ja/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
index ac107311fc2..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
@@ -10,7 +10,7 @@ published: 2021-01-13
このチュートリアルでは、Gethノードの監視を設定することで、パフォーマンスをよりよく理解し、潜在的な問題を特定する方法を説明します。
-## 前提条件{#prerequisites}
+## 前提条件 {#prerequisites}
- Gethのインスタンスがすでに実行されている必要があります。
- 手順と例のほとんどはLinux環境向けであり、ターミナルの基本的な知識があると役立ちます。
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 83e2dd08a81..a89f823d73f 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
@@ -6,7 +6,7 @@ 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
---
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/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
index 1db6357b879..53244a86a34 100644
--- a/public/content/translations/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
+++ b/public/content/translations/ja/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -6,7 +6,7 @@ tags: [ "トランザクション", "web3.js", "Alchemy" ]
skill: beginner
lang: ja
published: 2020-11-04
-source: "Alchemy ドキュメント"
+source: Alchemy docs
sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum
---
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 a45857a18c2..bf0948e9da9 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
@@ -6,7 +6,7 @@ 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
---
diff --git a/public/content/translations/ja/developers/tutorials/testing-erc-20-tokens-with-waffle/index.md b/public/content/translations/ja/developers/tutorials/testing-erc-20-tokens-with-waffle/index.md
index a9253baaaf6..be94fd1c2f8 100644
--- a/public/content/translations/ja/developers/tutorials/testing-erc-20-tokens-with-waffle/index.md
+++ b/public/content/translations/ja/developers/tutorials/testing-erc-20-tokens-with-waffle/index.md
@@ -1,6 +1,6 @@
---
-title: Waffleを使って、ERC-20トークンをテストする
-description: Waffleを使用して、Solidityで書かれたスマートコントラクトをテストしたり、スマートコントラクトのマッチャーを使用する方法について学ぶ。
+title: "Waffleを使って、ERC-20トークンをテストする"
+description: "Waffleを使用して、Solidityで書かれたスマートコントラクトをテストしたり、スマートコントラクトのマッチャーを使用する方法について学ぶ。"
author: Vladislav Starostenko
tags:
- "Waffle"
diff --git a/public/content/translations/ja/developers/tutorials/testing-smart-contract-with-waffle/index.md b/public/content/translations/ja/developers/tutorials/testing-smart-contract-with-waffle/index.md
index 8d07a69140f..5656f8ad06e 100644
--- a/public/content/translations/ja/developers/tutorials/testing-smart-contract-with-waffle/index.md
+++ b/public/content/translations/ja/developers/tutorials/testing-smart-contract-with-waffle/index.md
@@ -1,6 +1,6 @@
---
-title: WaffleでERC-20トークンをテストする
-description: Waffleを使って、Solidityで作成したスマートコントラクトをテストし、スマートコントラクトのマッチャーを使用する方法について学ぶ
+title: "WaffleでERC-20トークンをテストする"
+description: "Waffleを使って、Solidityで作成したスマートコントラクトをテストし、スマートコントラクトのマッチャーを使用する方法について学ぶ"
author: Vladislav Starostenko
tags:
- "Waffle"
diff --git a/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md
index 9408b8ed064..fd29166b0bf 100644
--- a/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md
+++ b/public/content/translations/ja/developers/tutorials/token-integration-checklist/index.md
@@ -6,7 +6,7 @@ lang: ja
tags: [ "Solidity", "スマート契約", "セキュリティ", "トークン" ]
skill: intermediate
published: 2020-08-13
-source: "セキュアなコントラクトの開発"
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md
---
diff --git a/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
index 37646e25947..35183a5512a 100644
--- a/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
+++ b/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
@@ -56,9 +56,8 @@ Uniswap v2は、コアとペリフェリーの2つのコンポーネントに分
4. パスを反復処理します。 経路上のすべての取引所について、入力トークンを送信し、取引所の`swap`関数を呼び出します。
ほとんどの場合、トークンの宛先アドレスはパス上の次のペア取引所になります。 最後の取引所では、トレーダーが提供したアドレスになります。
-#### コアコントラクト(UniswapV2Pair.sol)にて {#in-the-core-contract-uniswapv2pairsol-2}
+#### コアコントラクト(UniswapV2Pair.sol)にて {#in-the-core-contract-uniswapv2pairsol-2}5. コアコントラクトで不正が行われておらず、スワップ後も十分な流動性を維持できることを検証します。
-5. コアコントラクトで不正が行われておらず、スワップ後も十分な流動性を維持できることを検証します。
6. 既知のリザーブに加えて、どれだけの追加トークンがあるかを確認します。 その量が、交換のために受け取った入力トークンの数です。
7. 出力トークンを宛先に送信します。
8. `_update`を呼び出してリザーブ量を更新します。
diff --git a/public/content/translations/ja/developers/tutorials/using-websockets/index.md b/public/content/translations/ja/developers/tutorials/using-websockets/index.md
index f63eaf04666..6661080d3a7 100644
--- a/public/content/translations/ja/developers/tutorials/using-websockets/index.md
+++ b/public/content/translations/ja/developers/tutorials/using-websockets/index.md
@@ -5,7 +5,7 @@ author: "Elan Halpern"
lang: ja
tags: [ "Alchemy", "WebSockets", "クエリ", "JavaScript" ]
skill: beginner
-source: "Alchemy ドキュメント"
+source: Alchemy docs
sourceUrl: https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3
published: 2020-12-01
---
diff --git a/public/content/translations/ja/energy-consumption/index.md b/public/content/translations/ja/energy-consumption/index.md
index 17f8523dbc3..2ae97ff77c6 100644
--- a/public/content/translations/ja/energy-consumption/index.md
+++ b/public/content/translations/ja/energy-consumption/index.md
@@ -70,7 +70,7 @@ CCRIは、マージによってイーサリアムの年間電力消費量が\*\*
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [ケンブリッジ・ブロックチェーン・ネットワーク・サステナビリティ・インデックス](https://ccaf.io/cbnsi/ethereum)
- [プルーフ・オブ・ワーク・ブロックチェーンに関するホワイトハウス報告書](https://web.archive.org/web/20221109005700/https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf)
@@ -80,7 +80,7 @@ CCRIは、マージによってイーサリアムの年間電力消費量が\*\*
- [マージ - イーサリアムネットワークの電力消費と炭素フットプリントへの影響](https://carbon-ratings.com/eth-report-2022) - _CCRI_
- [イーサリアムのエネルギー消費](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8)
-## 関連トピック{#related-topics}
+## 関連トピック {#related-topics}
- [ビーコンチェーン](/roadmap/beacon-chain)
- [マージ](/roadmap/merge/)
diff --git a/public/content/translations/ja/eth/supply/index.md b/public/content/translations/ja/eth/supply/index.md
index 45f3c8b9bcc..01d294adf8b 100644
--- a/public/content/translations/ja/eth/supply/index.md
+++ b/public/content/translations/ja/eth/supply/index.md
@@ -6,7 +6,7 @@ lang: ja
# ETHの供給と発行 {#eth-supply-and-issuance}
-## 前提条件{#prerequisites}
+## 前提条件 {#prerequisites}
この文書は、事前の知識がない初心者向けに書かれています。 ただし、このトピックを完全に理解するには、[イーサリアム改善提案 (EIPs)](/eips/#introduction-to-ethereum-improvement-proposals)、[プルーフ・オブ・ワーク (PoW)](/developers/docs/consensus-mechanisms/pow/)、[プルーフ・オブ・ステーク (PoS)](/developers/docs/consensus-mechanisms/pos/)、[ロンドンアップグレード](/ethereum-forks/#london)などの概念について基本的な理解があると役立ちます。
diff --git a/public/content/translations/ja/governance/index.md b/public/content/translations/ja/governance/index.md
index 58b7ac95328..449cb875601 100644
--- a/public/content/translations/ja/governance/index.md
+++ b/public/content/translations/ja/governance/index.md
@@ -160,7 +160,7 @@ The DAOハッキング事件をもっと見る
- ウォレットはインストールしましたか？
使い方を学びましょう。
-
+ ウォレットはインストールしましたか？
使い方を学びましょう。
ウォレットの使用方法
diff --git a/public/content/translations/ja/guides/how-to-revoke-token-access/index.md b/public/content/translations/ja/guides/how-to-revoke-token-access/index.md
index 9fb9506ecb6..903fb6ebf80 100644
--- a/public/content/translations/ja/guides/how-to-revoke-token-access/index.md
+++ b/public/content/translations/ja/guides/how-to-revoke-token-access/index.md
@@ -49,8 +49,7 @@ lang: ja
- さらに詳しく知りたいですか？
-
+ さらに詳しく知りたいですか？
他のガイドを見る
diff --git a/public/content/translations/ja/guides/how-to-swap-tokens/index.md b/public/content/translations/ja/guides/how-to-swap-tokens/index.md
index 74d2cc486e3..549a8a7cb44 100644
--- a/public/content/translations/ja/guides/how-to-swap-tokens/index.md
+++ b/public/content/translations/ja/guides/how-to-swap-tokens/index.md
@@ -52,8 +52,7 @@ lang: ja
- さらに詳しく知りたいですか？
-
+ さらに詳しく知りたいですか？
他のガイドを見る
diff --git a/public/content/translations/ja/guides/how-to-use-a-bridge/index.md b/public/content/translations/ja/guides/how-to-use-a-bridge/index.md
index 2851393345a..2f2218f1016 100644
--- a/public/content/translations/ja/guides/how-to-use-a-bridge/index.md
+++ b/public/content/translations/ja/guides/how-to-use-a-bridge/index.md
@@ -54,8 +54,7 @@ lang: ja
- さらに詳しく知りたいですか？
-
+ さらに詳しく知りたいですか？
他のガイドを見る
diff --git a/public/content/translations/ja/guides/how-to-use-a-wallet/index.md b/public/content/translations/ja/guides/how-to-use-a-wallet/index.md
index 619b5f34e86..9b85d928cf9 100644
--- a/public/content/translations/ja/guides/how-to-use-a-wallet/index.md
+++ b/public/content/translations/ja/guides/how-to-use-a-wallet/index.md
@@ -65,8 +65,7 @@ lang: ja
- さらに詳しく知りたいですか？
-
+ さらに詳しく知りたいですか？
他のガイドを見る
diff --git a/public/content/translations/ja/how-to-create-an-ethereum-account/index.md b/public/content/translations/ja/how-to-create-an-ethereum-account/index.md
index d5d242693bf..b1bea399212 100644
--- a/public/content/translations/ja/how-to-create-an-ethereum-account/index.md
+++ b/public/content/translations/ja/how-to-create-an-ethereum-account/index.md
@@ -1,6 +1,6 @@
---
-title: イーサリアムアカウントの「開設」方法
-description: ウォレットを利用してイーサリアムのアカウントを開設する方法のステップバイステップガイド
+title: "イーサリアムアカウントの「開設」方法"
+description: "ウォレットを利用してイーサリアムのアカウントを開設する方法のステップバイステップガイド"
lang: ja
---
@@ -43,7 +43,8 @@ lang: ja
- ウォレットをインストールしましたか？
その使い方を学びましょう。
+ ウォレットをインストールしましたか？
その使い方を学びましょう。
+
ウォレットの使用方法
diff --git a/public/content/translations/ja/nft/index.md b/public/content/translations/ja/nft/index.md
index cde04763129..ab3892172c4 100644
--- a/public/content/translations/ja/nft/index.md
+++ b/public/content/translations/ja/nft/index.md
@@ -58,8 +58,7 @@ NFTは以下のような多数の用途に使用されます。
- 非代替性トークン(NFT)アート/コレクティブルを探す、買う、作る
-
+ 非代替性トークン(NFT)アート/コレクティブルを探す、買う、作る
NFTアートを探す
@@ -102,7 +101,7 @@ NFTに関連するセキュリティの問題の大半は、フィッシング
セキュリティの詳細
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [NFT初心者ガイド](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _Linda Xie、2020年1月_
- [Etherscan NFTトラッカー](https://etherscan.io/nft-top-contracts)
diff --git a/public/content/translations/ja/payments/index.md b/public/content/translations/ja/payments/index.md
index e8eb078aba5..95952dc33e4 100644
--- a/public/content/translations/ja/payments/index.md
+++ b/public/content/translations/ja/payments/index.md
@@ -60,11 +60,12 @@ summaryPoint3: "1分以内に受け取れる支払い"
- 今日からウォレットアプリであなたのイーサリアムアカウントを作成しましょう。
-
+ 今日からウォレットアプリであなたのイーサリアムアカウントを作成しましょう。
-始める
+始める
+
+
## セルフカストディアル暗号資産カードでの支払い {#pay-with-self-custodial-crypto-cards}
@@ -159,7 +160,7 @@ summaryPoint3: "1分以内に受け取れる支払い"
本質的に、イーサリアムは安全で迅速かつ透明な取引を可能にする分散型プラットフォームです。 しかし、イーサリアムには従来の支払い方法とは異なる多くの特徴があります。 では、イーサリアムによる支払いが革新的である理由となる利点を詳しく見ていきましょう：
-### プログラマビリティ{#programmability}
+### プログラマビリティ {#programmability}
イーサリアムの特長のひとつは、スマートコントラクトをサポートできる点です。 スマートコントラクトとは、契約内容がコードとして直接記述され、自動的に実行される契約のことです。 これにより、自動化された条件付き支払いが可能となり、次のような取引を大幅に効率化できます：
@@ -197,9 +198,10 @@ summaryPoint3: "1分以内に受け取れる支払い"
- さあ、自分のイーサリアムアカウントを作成する時です。
-
+ さあ、自分のイーサリアムアカウントを作成する時です。
-始めよう！
+始めよう！
+
+
diff --git a/public/content/translations/ja/prediction-markets/index.md b/public/content/translations/ja/prediction-markets/index.md
index 446c44e8374..6ec9e47242b 100644
--- a/public/content/translations/ja/prediction-markets/index.md
+++ b/public/content/translations/ja/prediction-markets/index.md
@@ -56,7 +56,9 @@ buttons:
リスクにご注意ください
ご自身の許容範囲でのみベッティング（賭け）を行うようにし、潜在的な依存行動にご注意ください。
+
+
## 問題とリスク {#challenges-and-risks}
@@ -77,6 +79,6 @@ buttons:
こうしたイベントの主催者は予測市場の活用により、最大規模のイベントにつながる開催地や、国際的にアクセスしやすい開催地について判断できるようになります。 これらのメリットにより、Devconの主催者は、ビザに関する複数の要件、空港へのアクセス、現地の生活コストなどの確認に求められる時間を短縮できるほか、参加予定者が魅力を感じる訪問先に関するデータの収集が可能となります。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
[From prediction markets to info finance：予測市場から情報金融へ](https://vitalik.eth.limo/general/2024/11/09/infofinance.html) - Vitalik Buterin [Decentralized Prediction Market Development on Ethereum：イーサリアムにおける分散型予測市場の開発](https://blockchain.oodles.io/dev-blog/decentralized-prediction-market-development-ethereum/) [The Augur Project Whitepaper：Augurプロジェクトホワイトペーパー](https://github.com/AugurProject/whitepaper)
\ No newline at end of file
diff --git a/public/content/translations/ja/real-world-assets/index.md b/public/content/translations/ja/real-world-assets/index.md
index e09365b11b2..24ae1806617 100644
--- a/public/content/translations/ja/real-world-assets/index.md
+++ b/public/content/translations/ja/real-world-assets/index.md
@@ -60,7 +60,7 @@ RWAエコシステムの中から、不動産、従来の金融商品、そし
一方、ブロックチェーンベースのデジタルアート登録簿である[Artory](https://www.artory.com/)は、美術品の真正性を検証し、過去の所有権を記録します。
-### 収集品への投資{#investing-in-collectibles}
+### 収集品への投資 {#investing-in-collectibles}
ここまで、これらの例のほとんどは、トークン化が様々な種類の富の部分所有を可能にすることを示しています。 トークン化のもう一つの利点は、収集品のような価値のあるアイテムをグローバル市場で取引できることです。
@@ -82,7 +82,7 @@ Courtyardはまた、一種のロイヤリティ制度も提供しています
[スマートコントラクト](/smart-contracts/)について深く掘り下げたり、異なるトークンクラスである[非代替性トークン (NFT)](/nft/)について詳しく調べたりしてください。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- ブリタニカ百科事典の「資産トークン化とは？」(https://www.britannica.com/money/real-world-asset-tokenization)
- 世界経済フォーラムの[トークン化が世界の金融と投資をどのように変革しているか](https://www.weforum.org/stories/2024/12/tokenization-blockchain-assets-finance/)
diff --git a/public/content/translations/ja/restaking/index.md b/public/content/translations/ja/restaking/index.md
index 9a3818e379a..5932094ff3b 100644
--- a/public/content/translations/ja/restaking/index.md
+++ b/public/content/translations/ja/restaking/index.md
@@ -176,7 +176,7 @@ AVSはさまざまなレートを提供しますが、eETHのようなリキッ
+
## マージ以後(現在) {#post-merge}
@@ -96,7 +98,9 @@ ETH総供給量: **約120,520,000 ETH** (2022年9月のマージ時点)
年間ETH発行の純減率: **約88.7%** ((4.61% - 0.52%) / 4.61% \* 100)
+
+
##
+
ロンドンのアップグレードで実装されたフィーのバーンに加えて、バリデータがオフラインになるとペナルティを課されます。さらに深刻なことに、ネットワークのセキュリティを脅かす特定のルールに違反した場合にはスラッシュされることがあります。 これらのペナルティにより、バリデータの残高からETHが減少し、他のどのアカウントにも直接報酬として支払われず、事実上は流通から消滅することになります。
@@ -142,7 +148,7 @@ ETHの発行とは逆に、イーサリアムではETHがバーンされるレ
したがって、例えば、ステークされたETHの合計に基づいて`X` (1日あたりのETH発行量)が1800に上昇した場合、`f(X)` (すべての発行を相殺するために必要なgwei)は`17 gwei`になります (有効数字2桁を使用)。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [マージ](/roadmap/merge/)
- [Ultrasound.money](https://ultrasound.money/) - _ETHの発行とバーンをリアルタイムで視覚化できるダッシュボード_
diff --git a/public/content/translations/ja/roadmap/pbs/index.md b/public/content/translations/ja/roadmap/pbs/index.md
index e7bb67cbc2e..5cdc385e323 100644
--- a/public/content/translations/ja/roadmap/pbs/index.md
+++ b/public/content/translations/ja/roadmap/pbs/index.md
@@ -43,7 +43,7 @@ Dankshardingは、イーサリアムが毎秒100,000件以上のトランザク
PBSの研究は、順調に進んでいます。しかし、イーサリアムクライアントでプロトタイプを作成するには、まだいくつかの設計上の重大な問題を解決する必要があります。 そのため、仕様の確定に至っていません。 つまり、PBSの実装は1年以上先になる可能性があります。 最新の[研究状況](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)をご確認ください。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [研究状況：PBS下での検閲耐性](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
- [PBSフレンドリーな手数料市場の設計](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)
diff --git a/public/content/translations/ja/roadmap/pectra/index.md b/public/content/translations/ja/roadmap/pectra/index.md
index 57bdacd922e..cb67ab0b801 100644
--- a/public/content/translations/ja/roadmap/pectra/index.md
+++ b/public/content/translations/ja/roadmap/pectra/index.md
@@ -78,7 +78,7 @@ EVMは現在、コントラクトのデベロッパーが実行レイヤーで
[EIP-2935](https://eips.ethereum.org/EIPS/eip-2935)は、最後の8192ブロックハッシュをストレージスロットとして提供できる新しいシステムコントラクトを作成します。 これは、ステートレス実行のためにプロトコルの将来性を確保するのに役立ち、Verkleトライが採用されると、より効率的になります。 しかし、これとは別に、ロールアップはより長い履歴ウィンドウでコントラクトを直接クエリできるため、すぐにこの恩恵を受けることができます。
-### アテステーションの外に委員会インデックスを移動 {#7549}
+### アテステーションの外に委員会インデックスを移動 {#7549}
ビーコンチェーンのコンセンサスは、バリデータが最新のブロックとファイナライズされたエポックに投票することに基づいています。 アテステーションには3つの要素が含まれ、そのうち2つは投票、3つ目は委員会インデックス値です。
@@ -117,7 +117,7 @@ _Pectraアップグレードで何が行われるのか - Christine Kim_
_イーサリアムPectraアップグレード: ステーカーが知っておくべきこと — Blockdaemon_
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [イーサリアムのロードマップ](/roadmap/)
- [Pectra FAQ](https://epf.wiki/#/wiki/pectra-faq)
diff --git a/public/content/translations/ja/roadmap/pectra/maxeb/index.md b/public/content/translations/ja/roadmap/pectra/maxeb/index.md
index 30dfb347bd3..07ffc43781b 100644
--- a/public/content/translations/ja/roadmap/pectra/maxeb/index.md
+++ b/public/content/translations/ja/roadmap/pectra/maxeb/index.md
@@ -45,7 +45,7 @@ maxEBは、バリデータのMAXimum Effective Balance(最大有効残高)を省
| | ❌ Type 2 → Type 1 |
| | ❌ Type 2 → Type 0 |
-### リスク {#risks}
+### リスク {#risks}
MaxEBにより、バリデータはその全残高を別のバリデータに送信できます。 統合リクエストを送信するユーザーは、署名するトランザクションのソースと内容を確認する必要があります。 maxEB機能を利用するための公式ツールはLaunchpadです。 サードパーティ製のツールを使用することにした場合は、以下を確認する必要があります。
diff --git a/public/content/translations/ja/roadmap/secret-leader-election/index.md b/public/content/translations/ja/roadmap/secret-leader-election/index.md
index 2de1afb0f70..40053c8831b 100644
--- a/public/content/translations/ja/roadmap/secret-leader-election/index.md
+++ b/public/content/translations/ja/roadmap/secret-leader-election/index.md
@@ -39,6 +39,6 @@ SSLE(シークレット・シングル・リーダー選出)では、選出さ
SSLEとSnSLEはまだ研究段階にあるため、 仕様が決まっていません。 また、SSLEとSnSLEは競合しているので、両方が実装されるということはありません。 この提案をリリースするには、さらに研究開発を行い、プロトタイピングを作成した上で、公開テストネットで実装する必要があります。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git a/public/content/translations/ja/roadmap/single-slot-finality/index.md b/public/content/translations/ja/roadmap/single-slot-finality/index.md
index f26528f5a01..99ed6f97374 100644
--- a/public/content/translations/ja/roadmap/single-slot-finality/index.md
+++ b/public/content/translations/ja/roadmap/single-slot-finality/index.md
@@ -60,7 +60,7 @@ lang: ja
SSFはまだ研究段階です。 [Verkleツリー](/roadmap/verkle-trees/)や[Danksharding](/roadmap/danksharding/)といった他の大規模なアップグレードの後になる可能性が高く、リリースは数年先になると予想されています。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [EDCON 2022でのSSFに関するヴィタリック氏の講演](https://www.youtube.com/watch?v=nPgUKNPWXNI)
- [ヴィタリック氏のメモ：シングルスロットファイナリティへの道筋](https://notes.ethereum.org/@vbuterin/single_slot_finality)
diff --git a/public/content/translations/ja/roadmap/statelessness/index.md b/public/content/translations/ja/roadmap/statelessness/index.md
index afd20781d14..ab51c839bd5 100644
--- a/public/content/translations/ja/roadmap/statelessness/index.md
+++ b/public/content/translations/ja/roadmap/statelessness/index.md
@@ -89,7 +89,7 @@ EIP-4444は、現在も活発な議論が行われており、まだリリース
弱いステートレス、履歴の有効期限、状態の有効期限は、すべて研究段階にあります。リリースされるのは数年後になる予定ですが、 これらの提案がすべて実装されるわけではありません。例えば、状態の有効期限が最初に実装された場合、履歴の有効期限の実装は不要になるかもしれません。 その他にも、[Verkle ツリー](/roadmap/verkle-trees)や[プロポーザー・ビルダー分離](/roadmap/pbs)など、先に完了させる必要のあるロードマップ項目があります。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [ステートレスイーサリアムとは?](https://stateless.fyi/)
- [Vitalikのステートレスに関するAMA](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/)
diff --git a/public/content/translations/ja/roadmap/verkle-trees/index.md b/public/content/translations/ja/roadmap/verkle-trees/index.md
index bdea910cf15..311d34688d1 100644
--- a/public/content/translations/ja/roadmap/verkle-trees/index.md
+++ b/public/content/translations/ja/roadmap/verkle-trees/index.md
@@ -49,7 +49,7 @@ summaryPoints:
[Guillaume BalletによるCondrieuバークルテストネットの説明を見る](https://www.youtube.com/watch?v=cPLHFBeC0Vg)（Condrieuテストネットはプルーフ・オブ・ワークでしたが、現在はVerkle Gen Devnet 6テストネットに置き換えられていることに注意してください）。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [ステートレス性のためのバークルツリー](https://verkle.info/)
- [PEEPanEIPでのDankrad Feistによるバークルツリーの解説](https://www.youtube.com/watch?v=RGJOQHzg3UQ)
diff --git a/public/content/translations/ja/security/index.md b/public/content/translations/ja/security/index.md
index 0d646f442f4..c6ee3c1f897 100644
--- a/public/content/translations/ja/security/index.md
+++ b/public/content/translations/ja/security/index.md
@@ -278,7 +278,7 @@ Chrome拡張機能やFirefoxのアドオンなどのブラウザ拡張機能は
@@ -88,7 +89,7 @@ SaaSプロバイダーを利用することは、ノードの運用を誰かに
保証や保険オプションなどの詳細や、引き出しアドレスの提供方法については、それぞれのSaaSプロバイダーにお問い合わせください。 バリデーターのセットアップを完全に自分で管理したい場合は、[ETHのソロステーキング方法について](/staking/solo/)、こちらからさらに学ぶことができます。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [イーサリアムステーキングディレクトリ](https://www.staking.directory/) - _Eridian and Spacesider_
- [Evaluating Staking Services](https://www.attestant.io/posts/evaluating-staking-services/) - _Jim McDonald 2020_
diff --git a/public/content/translations/ja/staking/solo/index.md b/public/content/translations/ja/staking/solo/index.md
index 42d340758bb..ef43fc854d1 100644
--- a/public/content/translations/ja/staking/solo/index.md
+++ b/public/content/translations/ja/staking/solo/index.md
@@ -71,11 +71,12 @@ summaryPoints:
スラッシングとバリデータのライフサイクルに関する詳細
+
ステーキングの引き出しについての詳細
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [イーサリアムステーキングディレクトリ](https://www.staking.directory/) - _Eridian and Spacesider_
- [イーサリアムのクライアントの多様性の問題](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_
diff --git a/public/content/translations/ja/staking/withdrawals/index.md b/public/content/translations/ja/staking/withdrawals/index.md
index 1e00167070e..a7ac388d29f 100644
--- a/public/content/translations/ja/staking/withdrawals/index.md
+++ b/public/content/translations/ja/staking/withdrawals/index.md
@@ -211,7 +211,7 @@ eventName="read more">
できません。 一度バリデーターを終了し、残高がすべて引き出されると、そのバリデーターに入金された追加の資金は次のバリデータースイープで引き出しアドレスに自動的に移されます。 そのためETHを再びステークするには、新しいバリデーターを起動する必要があります。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [ステーキング・ランチパッドでの出金](https://launchpad.ethereum.org/withdrawals)
- [EIP-4895: 操作としてのビーコンチェーン・プッシュ出金](https://eips.ethereum.org/EIPS/eip-4895)
diff --git a/public/content/translations/ja/web3/index.md b/public/content/translations/ja/web3/index.md
index 6aa32fb23f4..3b3cbb6daa5 100644
--- a/public/content/translations/ja/web3/index.md
+++ b/public/content/translations/ja/web3/index.md
@@ -69,8 +69,7 @@ Web3では、[非代替性トークン(NFT)](/glossary/#nft)を通じて直接
- 非代替性トークン(NFT)について学ぶ
-
+ 非代替性トークン(NFT)について学ぶ
NFTの詳細
@@ -98,8 +97,7 @@ DAOは技術的には、リソース(トークン)のプールに対する分散
- 分散型自律組織(DAO)についてもっと知る
-
+ 分散型自律組織(DAO)についてもっと知る
DAOの詳細
@@ -157,7 +155,7 @@ Web3によるより良いWebの実現はまだ始まったばかりですが、
- [DAOに参加する](/dao/)
- [Web3で構築する](/developers/)
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
Web3とは何かは、厳密に定義されていません。 さまざまなコミュニティが多様な視点を持っています。 下記にこれらのいくつかをご紹介します。
diff --git a/public/content/translations/ja/what-are-apps/index.md b/public/content/translations/ja/what-are-apps/index.md
index 21f44ada6e2..8b2a28fd70f 100644
--- a/public/content/translations/ja/what-are-apps/index.md
+++ b/public/content/translations/ja/what-are-apps/index.md
@@ -59,7 +59,7 @@ summary: "イーサリアム上のアプリは無料で、世界中どこから
Ether (ETH) はイーサリアムのネイティブ暗号通貨です。 ステーキングや通貨としての使用、計算のためのガス料金の支払いなど、さまざまな目的で使用されます。 \*\*WETHはETHの機能を拡張したもので、多くのアプリケーションやイーサリアム上の他のデジタル資産である [ERC-20トークン](/glossary/#erc-20) \*\* で必要とされる追加機能を持っています。 ERC-20トークンと連携するためには、ETHも同じERC-20規格に従う必要があります。
@@ -60,7 +59,7 @@ WETHは、シンプルで実践テスト済みのスマートコントラクト
- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [WETHとは何か？](https://weth.tkn.eth.limo/)
- [BlockscoutのWETHトークン情報](https://eth.blockscout.com/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
diff --git a/public/content/translations/ja/zero-knowledge-proofs/index.md b/public/content/translations/ja/zero-knowledge-proofs/index.md
index 6c4e9d51967..97fe59e0f45 100644
--- a/public/content/translations/ja/zero-knowledge-proofs/index.md
+++ b/public/content/translations/ja/zero-knowledge-proofs/index.md
@@ -225,7 +225,7 @@ ZK-SNARKは、暗号化に楕円曲線暗号技術を使用しています。
ZK-STARKは、量子コンピューティングの脅威に耐性があると考えられています。そのセキュリティでは、衝突困難性ハッシュ関数のみに依存しているためです。 楕円曲線暗号で使われている公開鍵と秘密鍵のペアリングとは異なり、衝突困難性ハッシュは量子アルゴリズムでも突破するのが困難です。
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [ゼロ知識証明のユースケースの概要](https://pse.dev/projects) — _Privacy and Scaling Explorations Team_
- [SNARK、STARK、再帰的SNARKの比較](https://www.alchemy.com/overviews/snarks-vs-starks) — _Alchemy Overviews_
From 8eefb9be943526480b704dcd3689593f8f582973 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 17:23:35 +0000
Subject: [PATCH 05/14] chore: trigger rebuild
From 2ddf3584579bd3b00c6015a7d558d402b9f13449 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 19:46:00 +0000
Subject: [PATCH 06/14] chore: trigger rebuild
From 71ca755ef022377f1fc0bf3e6c40fa75ba2fd11e Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 19:46:48 +0000
Subject: [PATCH 07/14] chore: trigger rebuild
From 3e87ec17770d021cea3c42b24395860332f4faa7 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Fri, 13 Feb 2026 22:18:22 +0000
Subject: [PATCH 08/14] chore: trigger rebuild
From 0bc77ee8b790e145ab3acb6f472f5263b984e45b Mon Sep 17 00:00:00 2001
From: myelinated-wackerow
<263208946+myelinated-wackerow@users.noreply.github.com>
Date: Tue, 24 Feb 2026 00:43:38 +0000
Subject: [PATCH 09/14] fix(i18n): sanitize and review ja translations for PR
#17132
Re-ran fixed post-import sanitizer (brand tag canonical casing,
orphaned tag removal, MDX escaping) and applied manual review fixes
including typo corrections, structural repairs, and href attribute
cleanup across 31 Japanese translation files.
Co-Authored-By: Claude Opus 4.6
Co-Authored-By: wackerow <54227730+wackerow@users.noreply.github.com>
---
.../translation-program/translators-guide/index.md | 2 +-
.../docs/networking-layer/portal-network/index.md | 2 +-
.../developers/docs/programming-languages/dot-net/index.md | 2 +-
.../a-developers-guide-to-ethereum-part-one/index.md | 2 +-
.../creating-a-wagmi-ui-for-your-contract/index.md | 2 +-
.../tutorials/erc-721-vyper-annotated-code/index.md | 2 +-
.../ja/developers/tutorials/erc20-annotated-code/index.md | 2 +-
.../tutorials/hello-world-smart-contract-fullstack/index.md | 2 +-
.../tutorials/hello-world-smart-contract/index.md | 2 +-
.../ja/developers/tutorials/how-to-mint-an-nft/index.md | 2 +-
.../tutorials/reverse-engineering-a-contract/index.md | 6 +++---
.../ja/developers/tutorials/scam-token-tricks/index.md | 2 +-
.../ja/developers/tutorials/stealth-addr/index.md | 2 +-
.../developers/tutorials/uniswap-v2-annotated-code/index.md | 4 +++-
.../waffle-dynamic-mocking-and-testing-calls/index.md | 2 +-
.../waffle-say-hello-world-with-hardhat-and-ethers/index.md | 4 ++--
.../ja/guides/how-to-create-an-ethereum-account/index.md | 2 +-
.../ja/how-to-create-an-ethereum-account/index.md | 4 ++--
public/content/translations/ja/restaking/index.md | 2 +-
public/content/translations/ja/roadmap/dencun/index.md | 6 +++---
public/content/translations/ja/roadmap/fusaka/index.md | 2 +-
public/content/translations/ja/roadmap/merge/index.md | 2 +-
public/content/translations/ja/roadmap/pectra/index.md | 4 ++--
public/content/translations/ja/security/index.md | 2 +-
public/content/translations/ja/staking/dvt/index.md | 2 +-
public/content/translations/ja/staking/withdrawals/index.md | 2 +-
src/intl/ja/glossary-tooltip.json | 6 +++---
src/intl/ja/glossary.json | 6 +++---
src/intl/ja/learn-quizzes.json | 2 +-
src/intl/ja/page-index.json | 2 +-
src/intl/ja/page-staking.json | 2 +-
31 files changed, 44 insertions(+), 42 deletions(-)
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 349c19692b9..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
@@ -50,7 +50,7 @@ ethereum.orgは多くの言語で利用可能で、ラテンではない翻訳
コンテンツを翻訳する際には、翻訳に一貫性があり、ラテン文字が含まれていないことを意識してください。
-よくある誤解には、イーサリウムを常に「Ethereum」とラテン文字で記載しなければならないというものがあります。 これはほとんどの場合、正しくありません。日本語の「イーサリアム」のように、あなたの言語に固有のスペルを使用してください (例: 中国語では「以太坊」、アラビア語では「إيثيريوم」など)。
+よくある誤解には、イーサリアムを常に「Ethereum」とラテン文字で記載しなければならないというものがあります。 これはほとんどの場合、正しくありません。日本語の「イーサリアム」のように、あなたの言語に固有のスペルを使用してください (例: 中国語では「以太坊」、アラビア語では「إيثيريوم」など)。
**上記は、原則として固有名詞を翻訳すべきではない言語には適用されません。**
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 a7c11e20b26..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
@@ -55,7 +55,7 @@ JSON-RPC APIは、ライトクライアントのデータリクエストに理
- 集中化したプロバイダーへの依存が減る
- インターネット帯域使用量が減る
- 同期が短くなる、または同期が不要になる
-- リソースに制約のあるデバイス (<1 GB RAM、<100 MB ディスク容量、1 CPU) でアクセス可能
+- リソースに制約のあるデバイス (<1 GB RAM、<100 MB ディスク容量、1 CPU) でアクセス可能
以下の表は、ポータルネットワークによって提供される既存クライアントの機能を示しており、ユーザーは非常にリソースの少ないデバイスでこれらの機能にアクセスできます。
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 feff321dac8..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,6 +1,6 @@
---
title: ".NETデベロッパーのためのイーサリアム"
-description: ".NETベースのプロジェクトとツールを使ってイーサリムの開発方法を学ぶ"
+description: ".NETベースのプロジェクトとツールを使ってイーサリアムの開発方法を学ぶ"
lang: ja
incomplete: true
---
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 97cfd4adbd8..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
@@ -3,7 +3,7 @@ title: "Pythonデベロッパーのためのイーサリアム入門、パート
description: "イーサリアム開発の概要。特に、プログラミング言語であるPythonの知識があるデベロッパーに役立つ情報"
author: Marc Garreau
lang: ja
-tags: [ "python", "web3.py" ]
+tags: [ "Python", "web3.py" ]
skill: beginner
published: 2020-09-08
source: Snake charmers
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
index fd9e843697b..adcb7d66013 100644
--- 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
@@ -2,7 +2,7 @@
title: "コントラクトのユーザーインターフェースを構築する"
description: "TypeScript、React、Vite、Wagmiといった最新のコンポーネントを使用して、モダンでありながら最小限のユーザーインターフェースをレビューし、ウォレットをユーザーインターフェースに接続する方法、スマートコントラクトを呼び出して情報を読み取る方法、スマートコントラクトにトランザクションを送信する方法、スマートコントラクトからのイベントを監視して変更を特定する方法を学びます。"
author: Ori Pomerantz
-tags: [ "typescript", "react", "vite", "wagmi", "フロントエンド" ]
+tags: [ "TypeScript", "react", "vite", "wagmi", "フロントエンド" ]
skill: beginner
published: 2023-11-01
lang: ja
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 f33129b9ca4..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
@@ -3,7 +3,7 @@ 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
---
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 98fff8f466d..d1f724b71f6 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
@@ -205,7 +205,7 @@ import "../../math/SafeMath.sol";
```
- `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を使用しています。
+- [SafeMathライブラリ](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/)は、Solidityバージョン\*\*<0.8.0\*\*の算術オーバーフロー/アンダーフローを防ぎます。 Solidity ≥0.8.0では、算術演算はオーバーフロー/アンダーフローで自動的にリバートするため、SafeMathは不要です。 このコントラクトは、古いコンパイラバージョンとの後方互換性のためにSafeMathを使用しています。
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 b5025cc984c..fb6748cf861 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
@@ -5,7 +5,7 @@ author: "nstrike2"
tags:
[
"Solidity",
- "hardhat",
+ "Hardhat",
"Alchemy",
"スマート契約",
"デプロイ",
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 8130177db6e..8ffd54c7e27 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
@@ -2,7 +2,7 @@
title: "初心者向けのHello Worldスマートコントラクト"
description: "イーサリアムでの簡単なスマートコントラクトの作成とデプロイに関する入門チュートリアル。"
author: "elanh"
-tags: [ "Solidity", "hardhat", "Alchemy", "スマート契約", "デプロイ" ]
+tags: [ "Solidity", "Hardhat", "Alchemy", "スマート契約", "デプロイ" ]
skill: beginner
lang: ja
published: 2021-03-31
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 dab2badc296..65f16be985f 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
@@ -12,7 +12,7 @@ published: 2021-04-22
[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分で同じことを行う方法を説明します。
+いずれもAlchemyの強力なAPIを使ってNFTをミントしています。 このチュートリアルでは、\<10分で同じことを行う方法を説明します。
「NFTのミント」とは、ブロックチェーン上にERC-721トークンのユニークなインスタンスを公開することです。 この[NFTチュートリアルシリーズのパート1](/developers/tutorials/how-to-write-and-deploy-an-nft/)で作成したスマートコントラクトを使って、Web3のスキルを駆使し、NFTをミントしてみましょう。 このチュートリアルが終わるころには、あなた(とウォレット)が望むだけNFTをミントできるようになります。
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 de70fe292f9..f3d0c05aed6 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
@@ -51,8 +51,8 @@ _ブロックチェーン上に秘密はありません_。ブロックチェー
| 4 | MSTORE | なし |
| 5 | PUSH1 0x04 | 0x04 |
| 7 | CALLDATASIZE | CALLDATASIZE 0x04 |
-| 8 | LT | CALLDATASIZE<4 |
-| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE<4 |
+| 8 | LT | CALLDATASIZE<4 |
+| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE<4 |
| C | JUMPI | なし |
このコードは、次の2つのことをしています。
@@ -429,7 +429,7 @@ Etherscanによると`1C`は未知のオペコードですが、これは[Ethers
| 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 |
+| 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 |
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
index 92dfedc20ec..adaeee17fa2 100644
--- a/public/content/translations/ja/developers/tutorials/scam-token-tricks/index.md
+++ b/public/content/translations/ja/developers/tutorials/scam-token-tricks/index.md
@@ -8,7 +8,7 @@ tags:
"Solidity",
"ERC-20",
"JavaScript",
- "typescript"
+ "TypeScript"
]
skill: intermediate
published: 2023-09-15
diff --git a/public/content/translations/ja/developers/tutorials/stealth-addr/index.md b/public/content/translations/ja/developers/tutorials/stealth-addr/index.md
index 37bf51dcb9e..921742bd41d 100644
--- a/public/content/translations/ja/developers/tutorials/stealth-addr/index.md
+++ b/public/content/translations/ja/developers/tutorials/stealth-addr/index.md
@@ -2,7 +2,7 @@
title: "ステルスアドレスの使用"
description: "ステルスアドレスを使用すると、ユーザーは匿名で資産を送金できます。 この記事を読むと、ステルスアドレスとは何か、またその仕組みを説明し、匿名性を保つ方法でステルスアドレスを使用する方法を理解し、ステルスアドレスを使用するウェブベースのアプリケーションを作成できるようになります。"
author: Ori Pomerantz
-tags: [ "ステルスアドレス", "プライバシー", "暗号技術", "rust", "wasm" ]
+tags: [ "ステルスアドレス", "プライバシー", "暗号技術", "Rust", "wasm" ]
skill: intermediate
published: 2025-11-30
lang: ja
diff --git a/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
index 35183a5512a..e1fad202f59 100644
--- a/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
+++ b/public/content/translations/ja/developers/tutorials/uniswap-v2-annotated-code/index.md
@@ -56,7 +56,9 @@ Uniswap v2は、コアとペリフェリーの2つのコンポーネントに分
4. パスを反復処理します。 経路上のすべての取引所について、入力トークンを送信し、取引所の`swap`関数を呼び出します。
ほとんどの場合、トークンの宛先アドレスはパス上の次のペア取引所になります。 最後の取引所では、トレーダーが提供したアドレスになります。
-#### コアコントラクト(UniswapV2Pair.sol)にて {#in-the-core-contract-uniswapv2pairsol-2}5. コアコントラクトで不正が行われておらず、スワップ後も十分な流動性を維持できることを検証します。
+#### コアコントラクト(UniswapV2Pair.sol)にて {#in-the-core-contract-uniswapv2pairsol-2}
+
+5. コアコントラクトで不正が行われておらず、スワップ後も十分な流動性を維持できることを検証します。
6. 既知のリザーブに加えて、どれだけの追加トークンがあるかを確認します。 その量が、交換のために受け取った入力トークンの数です。
7. 出力トークンを宛先に送信します。
diff --git a/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md b/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
index 49aee5531c2..107f4a19632 100644
--- a/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
+++ b/public/content/translations/ja/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
@@ -2,7 +2,7 @@
title: "Waffle: 動的モッキングとコントラクト呼び出しのテスト"
description: "動的モッキングとコントラクト呼び出しのテストのためのWaffle上級チュートリアル"
author: "Daniel Izdebski"
-tags: [ "waffle", "スマート契約", "Solidity", "テスト", "モックアップ作成" ]
+tags: [ "Waffle", "スマート契約", "Solidity", "テスト", "モックアップ作成" ]
skill: intermediate
lang: ja
published: 2020-11-14
diff --git a/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md b/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
index d499f75c2e9..e76981a872f 100644
--- a/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
+++ b/public/content/translations/ja/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
@@ -4,11 +4,11 @@ description: "Hardhatとethers.jsを使って、はじめてのWaffleプロジ
author: "MiZiet"
tags:
[
- "waffle",
+ "Waffle",
"スマート契約",
"Solidity",
"テスト",
- "hardhat",
+ "Hardhat",
"ethers.js"
]
skill: beginner
diff --git a/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md
index 7a4203fbfa2..7e73ce5f1c4 100644
--- a/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md
+++ b/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md
@@ -34,7 +34,7 @@ lang: ja
## ステップ 4: リカバリーフレーズを保存する
-一部のアプリでは、秘密の「リカバリーフレーズ」(「シードフレーズ」や「ニーモニック」とも呼ばれることがあります) を保存するよう求められることがあります。 このフレーズを安全に保管することは非常に重要です！ このフレーズはイーサリウムアカウントを生成するために使用され、トランザクションを送信するためにも利用できます。
+一部のアプリでは、秘密の「リカバリーフレーズ」(「シードフレーズ」や「ニーモニック」とも呼ばれることがあります) を保存するよう求められることがあります。 このフレーズを安全に保管することは非常に重要です！ このフレーズはイーサリアムアカウントを生成するために使用され、トランザクションを送信するためにも利用できます。
\*\*このフレーズを知っている人は、誰でもすべての資金を管理できてしまいます。\*\*絶対に誰とも共有しないでください。 このフレーズには、ランダムに生成された12~24個の単語を含めるべきです(単語の並び順も重要です)。
diff --git a/public/content/translations/ja/how-to-create-an-ethereum-account/index.md b/public/content/translations/ja/how-to-create-an-ethereum-account/index.md
index b1bea399212..bf466194b17 100644
--- a/public/content/translations/ja/how-to-create-an-ethereum-account/index.md
+++ b/public/content/translations/ja/how-to-create-an-ethereum-account/index.md
@@ -31,11 +31,11 @@ lang: ja
## ステップ 3: アプリを開いて、イーサリアムアカウントを開設する
-新しいウォレットを初めて開くと、新しいアカウントを開設するか、既存のアカウントをインポートするかを選択するよう求められる場合があります。 新しいアカウントの開設をクリックします。 **このステップで、ウォレットソフトウェアがあなたのイーサリウムアカウントを作成します。**
+新しいウォレットを初めて開くと、新しいアカウントを開設するか、既存のアカウントをインポートするかを選択するよう求められる場合があります。 新しいアカウントの開設をクリックします。 **このステップで、ウォレットソフトウェアがあなたのイーサリアムアカウントを作成します。**
## ステップ 4: リカバリーフレーズを保存する
-一部のアプリでは、秘密の「リカバリーフレーズ」(「シードフレーズ」や「ニーモニック」とも呼ばれることがあります) を保存するよう求められることがあります。 このフレーズを安全に保管することは非常に重要です！ このフレーズはイーサリウムアカウントを生成するために使用され、トランザクションを送信するためにも利用できます。
+一部のアプリでは、秘密の「リカバリーフレーズ」(「シードフレーズ」や「ニーモニック」とも呼ばれることがあります) を保存するよう求められることがあります。 このフレーズを安全に保管することは非常に重要です！ このフレーズはイーサリアムアカウントを生成するために使用され、トランザクションを送信するためにも利用できます。
**このフレーズを知っている人は、全ての資金を管理することができます。**絶対に他人と共有しないでください。 このフレーズには、ランダムに生成された12~24個の単語を含めるべきです(単語の並び順も重要です)。
diff --git a/public/content/translations/ja/restaking/index.md b/public/content/translations/ja/restaking/index.md
index 5932094ff3b..f7cad7afb59 100644
--- a/public/content/translations/ja/restaking/index.md
+++ b/public/content/translations/ja/restaking/index.md
@@ -144,7 +144,7 @@ AVSはさまざまなレートを提供しますが、eETHのようなリキッ
イーサリアムの共同創設者が入力中...
- イーサリアムの共同創設者であるヴィタリックは、2021年のブログ投稿「コンセンサスに過負荷をかけるな」で、リステーキングの潜在的なリスクについて警告しました。
+ イーサリアムの共同創設者であるヴィタリックは、2021年のブログ投稿「コンセンサスに過負荷をかけるな」で、リステーキングの潜在的なリスクについて警告しました。
diff --git a/public/content/translations/ja/roadmap/dencun/index.md b/public/content/translations/ja/roadmap/dencun/index.md
index 13580c6f92d..f1b58ddbb8d 100644
--- a/public/content/translations/ja/roadmap/dencun/index.md
+++ b/public/content/translations/ja/roadmap/dencun/index.md
@@ -18,14 +18,14 @@ lang: ja
- ArbitrumやOptimismなどの主要なロールアッププロバイダーは、アップグレード後すぐにブロブがサポートされることを表明しています。
- 個々のロールアップのサポートタイムラインは、各プロバイダーが新しいブロブスペースを活用するためにシステムを更新する必要があるため、異なる可能性があります。
-## ハードフォーク後にETHはどのように変換されるのでしょうか? {#scam-alert} {#scam-alert}
+## ハードフォーク後にETHはどのように変換されるのでしょうか? {#scam-alert}
- ETHに必要なアクションはありません: イーサリアムのデンクンアップグレード後、ETHを変換またはアップグレードする必要はありません。 あなたのアカウント残高は同じままで、現在保有しているETHはハードフォーク後も既存の形式でアクセス可能です。
- 詐欺に注意してください！
@@ -100,7 +100,7 @@ EVMは現在、コントラクトのデベロッパーが実行レイヤーで
はい、Pectraアップグレードでは、[実行クライアントおよびコンセンサスクライアント](/developers/docs/nodes-and-clients/)両方のアップグレードが必要です。 主要なイーサリアムクライアントのはすべて、高い優先度でハードフォーク対応バージョンをリリースします。 アップグレード後もイーサリアムネットワークと同期を維持するために、ノードオペレーターはサポートされているクライアントバージョンを実行していることを確認する必要があります。 なお、クライアントリリースに関する情報は時間とともに変化するため、ユーザーは現時点の詳細情報を知るために、最新のアップデートを参照すべきです。
-## ハードフォーク後にETHはどのように変換されるのでしょうか? {#scam-alert} {#scam-alert}
+## ハードフォーク後にETHはどのように変換されるのでしょうか? {#scam-alert}
- ETHに必要なアクションはありません: イーサリアムのPectraアップグレード後、ETHを変換またはアップグレードする必要はありません。 あなたのアカウント残高は同じままで、現在保有しているETHはハードフォーク後も既存の形式でアクセス可能です。
- 詐欺に注意してください！
技術的には、トランザクションフィーは、トランザクションで必要になるガス代がいくらになるかに関連しています。
トランザクションフィーの削減は現在、強い関心の対象となっています。 詳細はレイヤー 2をご覧ください。",
"trust-assumptions-term": "信頼の仮定",
diff --git a/src/intl/ja/glossary.json b/src/intl/ja/glossary.json
index 7e61e32bd43..c9d17c7725d 100644
--- a/src/intl/ja/glossary.json
+++ b/src/intl/ja/glossary.json
@@ -102,7 +102,7 @@
"deposit-contract-term": "デポジットコントラクト",
"deposit-contract-definition": "イーサリアムでステーキングをするゲートウェイです。デポジットコントラクトは、イーサリアム上にあるスマートコントラクトでETHで入金を受け付け、バリデータの残高を管理します。ETHをこのコントラクトに入金しないとバリデータをアクティベートできません。このコントラクトには、ETHと入力データが必要になります。入力データには、バリデータの公開鍵、バリデータの秘密鍵で署名された出金用公開鍵を含みます。このデータは、バリデータがプルーフ・オブ・ステークネットワークによって特定および承認されるのに必要になります。",
"defi-term": "分散型金融(DeFi)",
- "defi-definition": "仲介者が不要で、ブロックチェーンに裏付けされた金融サービスを提供すること目的にした幅広いカテゴリーのイーサリアムアプリ。詳細は分散型金融(DeFi)",
+ "defi-definition": "仲介者が不要で、ブロックチェーンに裏付けされた金融サービスを提供すること目的にした幅広いカテゴリーのイーサリアムアプリ。詳細は分散型金融(DeFi)をご覧ください。",
"difficulty-term": "難易度",
"difficulty-definition": "プルーフ・オブ・ワークネットワーク内のネットワーク全体の設定です。有効なノンスを見つけるために必要な平均計算量をコントロールします。難易度は、有効であるとみなされるためのブロックハッシュの結果の先頭からのゼロの数で表されます。プルーフ・オブ・ステークへの移行以来、イーサリアムにおいて、この概念は廃止されました。",
"difficulty-bomb-term": "難易度爆弾",
@@ -344,7 +344,7 @@
"staking-term": "ステーキング",
"staking-definition": "バリデータになり、ネットワークを確保するために大量のEther(ステーク)をデポジットすることです。バリデータは、プルーフ・オブ・ステークによるコンセンサス・モデルに基づいてトランザクションの確認とブロックの提案を行います。ステーキングでは、ネットワークを最善にする動作により経済的なインセンティブを受けることができます。バリデータの責務を実行することで報酬を獲得できますが、実行できなかった場合は状況に応じた量のETHを失います。詳細はイーサリアムのステーキングをご覧ください。",
"staking-pool-term": "ステーキングプール",
- "staking-pool-definition": "複数のイーサリアムステーカーのETHを合わせ、バリデータ鍵のセットをアクティベートさせるのに必要な32ETHにしたものです。ノードオペレータは、コンセンサスに参加するのにこれらの鍵を使い、ブロック報酬を貢献したステーカーに分配します。ステーキングプールやステーキングの委任は、イーサリアムのプロトコルにおいてネイティブなものではなく、多くのソリューションがコミュニティによって構築されています。 詳細はステーキングプールをご覧ください。",
+ "staking-pool-definition": "複数のイーサリアムステーカーのETHを合わせ、バリデータ鍵のセットをアクティベートさせるのに必要な32ETHにしたものです。ノードオペレータは、コンセンサスに参加するのにこれらの鍵を使い、ブロック報酬を貢献したステーカーに分配します。ステーキングプールやステーキングの委任は、イーサリアムのプロトコルにおいてネイティブなものではなく、多くのソリューションがコミュニティによって構築されています。 詳細はステーキングプールをご覧ください。",
"stark-term": "STARK",
"stark-definition": "STARKは、「scalable transparent argument of knowledge」の略で ゼロ知識証明の一種です。詳細はゼロ知識ロールアップをご覧ください。",
"state-term": "状態",
@@ -362,7 +362,7 @@
"szabo-term": "Szabo",
"szabo-definition": "Etherの通貨単位です。 1 Szabo = 1012 weiです。 106 Szabo = 1 Etherです。",
"terminal-total-difficulty-term": "最終合計難易度(TTD)",
- "terminal-total-difficulty-definition": "合計難易度は、ブロックチェーンのある特定の位置までの全ブロックのEthashマイニング難易度の合計です。最終合計難易度は、合計難易度の特定の値で、実行クライアントのトリガーとして使われました。このトリガーにより、ネットワークのトランザクションを有効にするマイニングとブロックゴシップ機能をオフにして、ブルーフ・オブ・ステークに移行しました。現在のイーサリアムは、プルーフ・オブ・ステークに移行したのでもはや重要性はありません。",
+ "terminal-total-difficulty-definition": "合計難易度は、ブロックチェーンのある特定の位置までの全ブロックのEthashマイニング難易度の合計です。最終合計難易度は、合計難易度の特定の値で、実行クライアントのトリガーとして使われました。このトリガーにより、ネットワークのトランザクションを有効にするマイニングとブロックゴシップ機能をオフにして、プルーフ・オブ・ステークに移行しました。現在のイーサリアムは、プルーフ・オブ・ステークに移行したのでもはや重要性はありません。",
"testnet-term": "テストネット",
"testnet-definition": "テストネットワークの略で、イーサリアムのメインネットワークの動作をシミュレートするためのネットワーク。",
"token-term": "トークン",
diff --git a/src/intl/ja/learn-quizzes.json b/src/intl/ja/learn-quizzes.json
index 9172ad6b114..6a058c9994a 100644
--- a/src/intl/ja/learn-quizzes.json
+++ b/src/intl/ja/learn-quizzes.json
@@ -400,7 +400,7 @@
"daos-3-d-explanation": "通常、DAOメンバー全員が変更を提案できます。",
"daos-4-prompt": "DAOにとってスマートコントラクトで重要なことは？",
"daos-4-a-label": "スマートコントラクトのコードが変更できる",
- "daos-4-a-explanation": "コントラクトがイーサリウム上で稼働を開始すると、ルールを変更できるのは投票による場合のみです。これにより、DAOはプログラムされたルールに従って運営されます。",
+ "daos-4-a-explanation": "コントラクトがイーサリアム上で稼働を開始すると、ルールを変更できるのは投票による場合のみです。これにより、DAOはプログラムされたルールに従って運営されます。",
"daos-4-b-label": "個別の所有者が権限を持ち、トレジャリーの変更や送金ができます。",
"daos-4-b-explanation": "トレジャリーはスマートコントラクトで定義されており、資金を使うにはグループの承認が必要です。",
"daos-4-c-label": "基盤となるブロックチェーンの分散型コンセンサスに対する信頼",
diff --git a/src/intl/ja/page-index.json b/src/intl/ja/page-index.json
index 50b973484a1..6199ef9f045 100644
--- a/src/intl/ja/page-index.json
+++ b/src/intl/ja/page-index.json
@@ -112,7 +112,7 @@
"page-index-values-fairness-ethereum-content-0": "私たちは全ての人がグローバルなシステムから恩恵を受けるべきだと考えます。イーサリアムが誰にでも、また居住地や出身地に関わらず、世界中の全ての人に平等なアクセスを付与しているのはそのためです。",
"page-index-values-privacy-legacy-label": "プライバシーなし",
"page-index-values-privacy-legacy-content-0": "政府、企業、その他の顔の見えない大きな組織が、私たちに善意でプライバシーを与えてくれることは期待できません。",
- "page-index-values-privacy-legacy-content-1": "多くのアプリは、あなをオーダーメイドされたマーケティングのターゲットにするため、あなたの個人情報を出来るだけたくさん収集します。",
+ "page-index-values-privacy-legacy-content-1": "多くのアプリは、あなたをオーダーメイドされたマーケティングのターゲットにするため、あなたの個人情報を出来るだけたくさん収集します。",
"page-index-values-privacy-ethereum-label": "プライバシー志向",
"page-index-values-privacy-ethereum-content-0": "イーサリアム・コミュニティはプライバシーを尊重します。あなたには、個人情報や連絡先を開示することなくイーサリアムアプリを使う権利があります。",
"page-index-values-integration-legacy-label": "断片化",
diff --git a/src/intl/ja/page-staking.json b/src/intl/ja/page-staking.json
index e8ae67b4a43..89677fd34e1 100644
--- a/src/intl/ja/page-staking.json
+++ b/src/intl/ja/page-staking.json
@@ -81,7 +81,7 @@
"page-staking-hierarchy-cex-p1": "まだ自分のウォレットにETHを保有したくない場合、多くの中央集権型取引所はステーキングサービスを提供しています。これらのサービスは代替として、最小限の監督や手間で、報酬を得ることができます。",
"page-staking-hierarchy-cex-p2": "ここでのトレードオフは、中央集権型プロバイダが大量のバリデータを実行するためにETHの大規模プールを形成してしまうことです。 これは大きな中央集権型のターゲットと障害点を作成し、ネットワークが攻撃やバグに対して脆弱になるため、ネットワークとそのユーザーにとって危険性が高まります。",
"page-staking-hierarchy-cex-p3": "ご自身で鍵を保有したくない場合、これらのオプションを使うことができるため大丈夫ですが、ウォレットページを参照してみてください。 ご自身の資金に対して真の所有権を得る方法を学ぶことができます。ご自身の準備ができたら、自己所有型のプールステーキングサービスを試して、ステーキングをレベルアップしてください。",
- "page-staking-hierarchy-subtext": "お気づきのように、イーサリアムのステーキングに参加する方法は数多くあります。これらの方法は幅広いユーザーを対象としており、それぞれリスク、報酬、信頼の前提がそれぞれ異なります。より分散化されてたも、実テストされたものや、リスクの高い/低いものもあります。ここでは人気のあるものに関する情報をいくつか提供していますが、ETHを送金する前に、必ず自分自身で調査してください。",
+ "page-staking-hierarchy-subtext": "お気づきのように、イーサリアムのステーキングに参加する方法は数多くあります。これらの方法は幅広いユーザーを対象としており、それぞれリスク、報酬、信頼の前提がそれぞれ異なります。より分散化されたもの、実戦テストされたものや、リスクの高い/低いものもあります。ここでは人気のあるものに関する情報をいくつか提供していますが、ETHを送金する前に、必ず自分自身で調査してください。",
"page-staking-comparison-solo-saas": "ステーキング・アズ・ア・サービス(SaaS)プロバイダーでは、32 ETHの預け入れは必要ですが、ハードウェアを運用する必要はありません。通常、バリデータ鍵へのアクセスは自分自身で保有しますが、プロバイダーがご自身の代理でバリデータとしての役割を果たせるように、署名鍵を共有する必要があります。つまり、これは自分自身のハードウェアを使用する場合には必要ない、プロバイダーへの信頼が必要になります。また自宅でのソロステーキングとは異なり、SaaSはノードの地理的な分布という点では、あまり貢献しません。ハードウェアの運用に不安があり、それでも32 ETHのステーキングを行いたい場合は、SaaSプロバイダーを利用するのが良いかもしれません。",
"page-staking-comparison-solo-pools": "ソロステーキングはプーリングサービスを利用したステーキングよりもかなり複雑ですが、ETH報酬へのフルアクセス、バリデータの設定とセキュリティのフルコントロールというメリットがあります。ステーキングプールではは、参入障壁が大幅に低くなり、少額のETHでステーキングに参加することができ、バリデータ鍵の生成は不要で、標準的なインターネット接続以上のハードウェア要件はありません。流動性トークンにより、ステーキングを辞めることがプロトコルレベルで可能になっています。これらのメリットにご興味がある場合は、ステーキングプールの利用が適しているかもしれません。",
"page-staking-comparison-saas-solo": "類似点としては、資金をプールすることなく独自のバリデータ鍵を保有することですが、SaaSの場合は、悪意ある行動をとるおそれや攻撃や規制の対象になる可能性がある第三者を信頼しなければなりません。このような信頼の前提や中央集権化のリスクが気になる場合は、自己主権型ステーキングのゴールドスタンダードであるソロステーキングをお勧めします。",
From 9b7402e85af101a006005ed995d2bbf04eca1bf0 Mon Sep 17 00:00:00 2001
From: myelinated-wackerow
<263208946+myelinated-wackerow@users.noreply.github.com>
Date: Tue, 24 Feb 2026 00:49:23 +0000
Subject: [PATCH 10/14] docs: add Japanese translation review report for PR
#17132
Documents the full review pipeline execution, lessons learned from
sanitizer bug discovery, and checklist for future translation reviews.
Co-Authored-By: Claude Opus 4.6
Co-Authored-By: wackerow <54227730+wackerow@users.noreply.github.com>
---
...crowdin-import-review-japanese-pr-17132.md | 216 ++++++++++++++++++
1 file changed, 216 insertions(+)
create mode 100644 docs/solutions/translation-review/crowdin-import-review-japanese-pr-17132.md
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
From afbeddc46849a4dd0d0e7d682a02b840729ec2c4 Mon Sep 17 00:00:00 2001
From: myelinated-wackerow
<263208946+myelinated-wackerow@users.noreply.github.com>
Date: Tue, 24 Feb 2026 03:08:24 +0000
Subject: [PATCH 11/14] fix(i18n): fix 4 MDX compilation errors in ja
translations
- patricia-merkle-trie: escape bare <> as `<>` in prose (JSX fragment)
- creating-a-wagmi-ui: fix outside backticks and duplicated sentence
- hello-world-fullstack: restructure misplaced code fence (code was
outside fence, explanation text inside it)
- reverse-engineering: escape \*<= as \*\<= in markdown table (MDX
parsed unescaped < as tag opener)
Co-Authored-By: Claude Opus 4.6
Co-Authored-By: wackerow <54227730+wackerow@users.noreply.github.com>
---
.../patricia-merkle-trie/index.md | 2 +-
.../creating-a-wagmi-ui-for-your-contract/index.md | 2 +-
.../hello-world-smart-contract-fullstack/index.md | 12 +++++++-----
.../reverse-engineering-a-contract/index.md | 4 ++--
4 files changed, 11 insertions(+), 9 deletions(-)
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 251d88b9591..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
@@ -167,7 +167,7 @@ sidebarDepth: 2
`('do', 'verb')`、`('dog', 'puppy')`、`('doge', 'coins')`、`('horse', 'stallion')`という4つのパス/値のペアを含むトライが必要だとします。
-まず、パスと値の両方を`bytes`に変換します。 以下では、_パス_の実際のバイト表現は<>で示しますが、_値_は理解しやすいように''で示される文字列として表示されています(これらも実際には`bytes`になります):
+まず、パスと値の両方を`bytes`に変換します。 以下では、_パス_の実際のバイト表現は`<>`で示しますが、_値_は理解しやすいように`''`で示される文字列として表示されています(これらも実際には`bytes`になります):
```
<64 6f> : 'verb'
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
index adcb7d66013..df3b0483af7 100644
--- 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
@@ -143,7 +143,7 @@ export function App() {
<>
```
-ReactコンポーネントのJSXは、1つのコンポーネントを返す_必要_があります。 複数のコンポーネントがあり、「自然に」まとめるものがない場合は、空のコンポーネント(`<> ...` )を使用して、それらを1つのコンポーネントにまとめます。 )を使用して、それらを1つのコンポーネントにまとめます。
+ReactコンポーネントのJSXは、1つのコンポーネントを返す_必要_があります。 複数のコンポーネントがあり、「自然に」まとめるものがない場合は、空のコンポーネント(`<> ... `)を使用して、それらを1つのコンポーネントにまとめます。
```tsx
Greeter
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 fb6748cf861..69e65e63b00 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
@@ -996,13 +996,15 @@ export const helloWorldContract = new web3.eth.Contract(
これは非常にシンプルな関数です。 コントラクトから読み取るために、単純な非同期のweb3呼び出しを作成します。 この関数では、スマートコントラクトに保存されているメッセージを返します。
-// interact.jsexport const loadCurrentMessage = async () => {
-const message = await helloWorldContract.methods.message().call()
-return message
-}
+`interact.js`ファイルの `loadCurrentMessage`を次のように更新してください。
```javascript
-`interact.js`ファイルの `loadCurrentMessage`を次のように更新してください。
+// interact.js
+
+export const loadCurrentMessage = async () => {
+ const message = await helloWorldContract.methods.message().call()
+ return message
+}
```
このスマートコントラクトをUIに表示したいので、`HelloWorld.js`コンポーネントの `useEffect`関数を次のように更新します。
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 f3d0c05aed6..d73bf25017d 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
@@ -117,8 +117,8 @@ _ブロックチェーン上に秘密はありません_。ブロックチェー
| ----: | ------------ | ---------------------------------------------------------------------------------------------------- |
| 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 |
+| 1AE | ISZERO | Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AF | PUSH2 0x01df | 0x01DF Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
| 1B2 | JUMPI | |
`Value*`の値が、2^256-CALLVALUE-1以下の場合にジャンプします。 これは、オーバーフローを防ぐためのロジックに見えます。 実際に、オフセット0x01DEでいくつかの無意味な操作(例: 削除される寸前にメモリへの書き込み)をした後、オーバーフローが検出されると、標準の動作としてコントラクトが元に戻されます。
From 1a447471181fd09de8347b936d469e51e28f8921 Mon Sep 17 00:00:00 2001
From: myelinated-wackerow
<263208946+myelinated-wackerow@users.noreply.github.com>
Date: Tue, 24 Feb 2026 03:16:27 +0000
Subject: [PATCH 12/14] fix(i18n): escape additional bare < in
reverse-engineering ja translation
Crowdin dropped backslash escape before
Co-Authored-By: wackerow <54227730+wackerow@users.noreply.github.com>
---
.../tutorials/reverse-engineering-a-contract/index.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 d73bf25017d..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
@@ -469,8 +469,8 @@ Etherscanによると`1C`は未知のオペコードですが、これは[Ethers
| 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)
Date: Tue, 24 Feb 2026 05:53:47 +0000
Subject: [PATCH 13/14] fix(i18n): ja translation quality fixes
- Fix critical mistranslations (oracles, zk-rollup, glossary)
- Fix ethash data corruption (dropped digit)
- Fix escaped bold, duplicate headings, broken links
- Fix tag regressions and brand name handling
- Fix garbled text in JSON translation files
Co-Authored-By: Claude Opus 4.6
Co-Authored-By: wackerow <54227730+wackerow@users.noreply.github.com>
---
.../ja/community/events/organizing/index.md | 10 ++--
.../ja/community/get-involved/index.md | 2 +-
.../ja/community/support/index.md | 2 +-
.../ja/contributing/adding-exchanges/index.md | 2 +-
.../contributing/design-principles/index.md | 2 +-
.../docs/consensus-mechanisms/index.md | 4 +-
.../docs/consensus-mechanisms/pos/index.md | 2 +-
.../docs/consensus-mechanisms/pow/index.md | 2 +-
.../mining/mining-algorithms/ethash/index.md | 2 +-
.../data-structures-and-encoding/ssz/index.md | 2 +-
.../ja/developers/docs/gas/index.md | 2 +-
.../developers/docs/intro-to-ether/index.md | 2 +-
.../docs/intro-to-ethereum/index.md | 4 +-
.../docs/nodes-and-clients/index.md | 2 +-
.../nodes-and-clients/light-clients/index.md | 2 +-
.../nodes-as-a-service/index.md | 4 +-
.../nodes-and-clients/run-a-node/index.md | 4 +-
.../ja/developers/docs/oracles/index.md | 2 +-
.../docs/programming-languages/dart/index.md | 2 +-
.../developers/docs/scaling/validium/index.md | 4 +-
.../docs/scaling/zk-rollups/index.md | 8 +--
.../smart-contracts/composability/index.md | 6 +--
.../docs/smart-contracts/verifying/index.md | 2 +-
.../docs/standards/tokens/erc-1363/index.md | 2 +-
.../docs/standards/tokens/erc-777/index.md | 2 +-
.../ja/developers/docs/transactions/index.md | 8 +--
.../ja/developers/docs/wrapped-eth/index.md | 2 +-
.../developers/tutorials/app-plasma/index.md | 8 +--
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../tutorials/erc20-annotated-code/index.md | 2 +-
.../index.md | 10 ++--
.../index.md | 2 +-
.../index.md | 2 +-
.../hello-world-smart-contract/index.md | 4 +-
.../index.md | 2 +-
.../tutorials/how-to-mint-an-nft/index.md | 4 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../how-to-use-tellor-as-your-oracle/index.md | 2 +-
.../how-to-write-and-deploy-an-nft/index.md | 2 +-
.../index.md | 2 +-
.../tutorials/ipfs-decentralized-ui/index.md | 2 +-
.../logging-events-smart-contracts/index.md | 2 +-
.../index.md | 2 +-
.../developers/tutorials/nft-minter/index.md | 2 +-
.../tutorials/run-node-raspberry-pi/index.md | 2 +-
.../secure-development-workflow/index.md | 2 +-
.../index.md | 4 +-
.../index.md | 14 +++---
.../index.md | 2 +-
.../token-integration-checklist/index.md | 50 +++++++++----------
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../index.md | 2 +-
.../ja/energy-consumption/index.md | 2 +-
.../translations/ja/governance/index.md | 4 +-
.../index.md | 4 +-
.../ja/guides/how-to-id-scam-tokens/index.md | 2 +-
public/content/translations/ja/nft/index.md | 4 +-
public/content/translations/ja/refi/index.md | 4 +-
.../ja/roadmap/account-abstraction/index.md | 2 +-
.../ja/roadmap/beacon-chain/index.md | 2 +-
.../translations/ja/roadmap/fusaka/index.md | 2 +-
.../ja/roadmap/fusaka/peerdas/index.md | 6 +--
.../ja/roadmap/future-proofing/index.md | 4 +-
.../translations/ja/roadmap/merge/index.md | 2 +-
.../ja/roadmap/merge/issuance/index.md | 6 +--
.../translations/ja/roadmap/pbs/index.md | 4 +-
.../roadmap/secret-leader-election/index.md | 4 +-
.../translations/ja/roadmap/security/index.md | 2 +-
.../ja/roadmap/single-slot-finality/index.md | 2 +-
.../content/translations/ja/security/index.md | 2 +-
.../translations/ja/social-networks/index.md | 22 ++++----
.../translations/ja/whitepaper/index.md | 2 +-
.../translations/ja/wrapped-eth/index.md | 2 +-
.../ja/zero-knowledge-proofs/index.md | 2 +-
src/intl/ja/glossary.json | 2 +-
src/intl/ja/page-10-year-anniversary.json | 4 +-
src/intl/ja/page-community-events.json | 2 +-
src/intl/ja/page-developers-docs.json | 2 +-
src/intl/ja/page-layer-2.json | 2 +-
src/intl/ja/page-roadmap.json | 4 +-
89 files changed, 169 insertions(+), 169 deletions(-)
diff --git a/public/content/translations/ja/community/events/organizing/index.md b/public/content/translations/ja/community/events/organizing/index.md
index b756db16efd..e4e94a2931a 100644
--- a/public/content/translations/ja/community/events/organizing/index.md
+++ b/public/content/translations/ja/community/events/organizing/index.md
@@ -28,12 +28,12 @@ hideEditButton: true
これらの要素の多くが欠けていることに気づいても、心配しないでください。コミュニティをゼロから構築することは、困難ですが非常にやりがいのあるプロセスです。 強力なイーサリアムコミュニティは一夜にして現れるものではありません。忍耐力、一貫性、そして明確なビジョンが必要です。 始める方法は次のとおりです。
- **コミュニケーションチャネルを設定する** — Telegram、Signal、WhatsApp、WeChat、Discordサーバーなど、お住まいの地域でより人気のあるものを利用して、人々がつながり、質問し、リソースを共有できるようにします。
-- \*\*アーリーアダプターを見つける。\*\*イーサリアムとWeb3に情熱を持つ数人を見つけましょう。 彼らはあなたの中核となる支持者であり、協力者となるでしょう。
-- \*\*小規模で一貫性のあるイベントを主催する。\*\*非公式なミートアップ、勉強会、ワークショップから始めましょう。 一貫性が鍵です — 最初はグループが小さくても、定期的なイベントは信頼と勢いを築きます。
+- **アーリーアダプターを見つける。**イーサリアムとWeb3に情熱を持つ数人を見つけましょう。 彼らはあなたの中核となる支持者であり、協力者となるでしょう。
+- **小規模で一貫性のあるイベントを主催する。**非公式なミートアップ、勉強会、ワークショップから始めましょう。 一貫性が鍵です — 最初はグループが小さくても、定期的なイベントは信頼と勢いを築きます。
- **地元の企業**、教育機関、コワーキングスペースに連絡して、無料でスペースを提供してもらえないか試してみてください。 自国からスピーカーが見つからない場合は、オンラインでスピーカーを招待し、人々を物理的に集めましょう。 聴衆を物理的に1か所に集めておくことが重要です。
-- \*\*既存の技術コミュニティと協力する。\*\*すでにデベロッパーグループ、スタートアップエコシステム、またはブロックチェーンミートアップが確立されている場合は、彼らと提携してイーサリアムのトピックを紹介し、リーチを拡大しましょう。
+- **既存の技術コミュニティと協力する。**すでにデベロッパーグループ、スタートアップエコシステム、またはブロックチェーンミートアップが確立されている場合は、彼らと提携してイーサリアムのトピックを紹介し、リーチを拡大しましょう。
- イーサリアムの可能性に関する**教育コンテンツを共有する**。
-- \*\*グローバルコミュニティに連絡を取る。\*\*世界中の確立されたイーサリアムグループやプロジェクトとつながり、サポート、メンターシップ、潜在的な協力を求めましょう。 世界中のイーサリアムコミュニティには、少なくとも1つの共通点があります。それは、誰もが喜んで手助けをしてくれるということです。
+- **グローバルコミュニティに連絡を取る。**世界中の確立されたイーサリアムグループやプロジェクトとつながり、サポート、メンターシップ、潜在的な協力を求めましょう。 世界中のイーサリアムコミュニティには、少なくとも1つの共通点があります。それは、誰もが喜んで手助けをしてくれるということです。
- 地元のweb3企業から、または[ESP](https://esp.ethereum.foundation/)などの助成金プログラムを通じて、**資金を確保**してみてください。
### ある場合は、どのように維持し、成長させるか {#if-yes-how-to-maintain-and-grow-it}
@@ -92,7 +92,7 @@ hideEditButton: true
すべてのセッション、パネル、ワークショップは、コミュニティに情報を提供し、インスピレーションを与え、関与させるものであるべきです。 オーディエンスの声に耳を傾けましょう。彼らの興味、ニーズ、課題を理解してください。 どのトピックが彼らの心に響きますか？ 同時に、新鮮な視点と革新的な形式を導入して、プログラムをダイナミックに保ちましょう。 おなじみの話題やトレンドのトピックと最先端のアイデアをバランスよく組み合わせ、技術的な深掘りやコミュニティ構築セッションから、ポリシーに関する議論や実践的なワークショップまで、イーサリアムエコシステムのさまざまな側面を網羅する、バランスの取れた議題を確保します。 さらに、カンファレンスの言語も考慮しましょう。ほとんどのイーサリアムイベントでは英語がデフォルトですが、現地の言語でセッションを提供することで、地域のデベロッパーや愛好家にとってイベントがよりアクセスしやすくなります。
-\*\*スピーカーを選ぶ際は、カンファレンスの少なくとも6か月前に公募を開始し、質の高い応募を集め、議題のキュレーションに十分な時間を確保しましょう。\*\*スピーカーの選定を担当する人は、業界でかなりの経験を持ち、エコシステムを深く理解している必要があります。 これにより、彼らが価値のある洞察に満ちた貢献を特定し、高いコンテンツ水準を維持できることが保証されます。
+**スピーカーを選ぶ際は、カンファレンスの少なくとも6か月前に公募を開始し、質の高い応募を集め、議題のキュレーションに十分な時間を確保しましょう。**スピーカーの選定を担当する人は、業界でかなりの経験を持ち、エコシステムを深く理解している必要があります。 これにより、彼らが価値のある洞察に満ちた貢献を特定し、高いコンテンツ水準を維持できることが保証されます。
### 資金援助の見つけ方 {#where-to-find-financial-support}
diff --git a/public/content/translations/ja/community/get-involved/index.md b/public/content/translations/ja/community/get-involved/index.md
index 63e47dc9720..d1c1706dd61 100644
--- a/public/content/translations/ja/community/get-involved/index.md
+++ b/public/content/translations/ja/community/get-involved/index.md
@@ -4,7 +4,7 @@ description: "イーサリアムコミュニティへの参加方法"
lang: ja
---
-# 参加方法 参加する {#get-involved}
+# 参加方法 {#get-involved}
イーサリアムのコミュニティには、デベロッパー、アーティスト、会計士など、さまざまな背景とスキルを持つ人々が集っており、 誰でも参加できます。 コミュニティへの参加を始めるにあたって、下記のリストを参考にしてください。
diff --git a/public/content/translations/ja/community/support/index.md b/public/content/translations/ja/community/support/index.md
index e788bbf77a9..0af78c2d31a 100644
--- a/public/content/translations/ja/community/support/index.md
+++ b/public/content/translations/ja/community/support/index.md
@@ -10,7 +10,7 @@ lang: ja
イーサリアムの公式サポートをお探しの場合は、まず始めに、 イーサリアムは非集中的な分散型であるということをご理解ください。 イーサリアムは、中央組織、団体、または個人により所有されていないため、公式のサポートチャンネルはありません。
-イーサリアムの分散型の性質を理解することは極めて重要です。なぜなら、\*\*イーサリアムの公式サポートを名乗る人は、おそらくあなたを騙そうとしているからです！\*\*詐欺師に対する最良の防御は、自分自身を教育し、セキュリティを真剣に考えることです。
+イーサリアムの分散型の性質を理解することは極めて重要です。なぜなら、**イーサリアムの公式サポートを名乗る人は、おそらくあなたを騙そうとしているからです！**詐欺師に対する最良の防御は、自分自身を教育し、セキュリティを真剣に考えることです。
イーサリアムのセキュリティと詐欺対策
diff --git a/public/content/translations/ja/contributing/adding-exchanges/index.md b/public/content/translations/ja/contributing/adding-exchanges/index.md
index fda8b87193e..e36104e7c2e 100644
--- a/public/content/translations/ja/contributing/adding-exchanges/index.md
+++ b/public/content/translations/ja/contributing/adding-exchanges/index.md
@@ -16,7 +16,7 @@ lang: ja
このため、取引所の掲載の提案時には具体的な情報が必要となります。
-\*\*注：\*\*分散型取引所の掲載をご希望の場合は、[ウォレットとdappsの掲載ポリシー](/contributing/adding-products/)をご参照ください。
+**注：**分散型取引所の掲載をご希望の場合は、[ウォレットとdappsの掲載ポリシー](/contributing/adding-products/)をご参照ください。
## 必要な情報 {#what-we-need}
diff --git a/public/content/translations/ja/contributing/design-principles/index.md b/public/content/translations/ja/contributing/design-principles/index.md
index b776a7eca00..19a736d63f0 100644
--- a/public/content/translations/ja/contributing/design-principles/index.md
+++ b/public/content/translations/ja/contributing/design-principles/index.md
@@ -12,7 +12,7 @@ description: "ethereum.orgのデザインとコンテンツに関する原則"
[ethereum.orgに貢献する](/contributing/)前に、こちらをお読みください。
-## デザイン原則とは 貢献の方法 {#ways-to-contribute}
+## デザイン原則とは {#ways-to-contribute}
とてもシンプルですので、ご心配は無用です! **デザイン原則**とは、何かをデザイン(作成、維持、更新など)する際に参照する一連のガイドラインです。
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 7fdac526177..1c4de03f3c0 100644
--- a/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md
@@ -32,7 +32,7 @@ lang: ja
### プルーフ・オブ・ワークベース {#proof-of-work}
-ビットコインと同様に、イーサリアムもかつては\*\*プルーフ・オブ・ワーク(PoW)\*\*に基づいたコンセンサスプロトコルを使用していました。
+ビットコインと同様に、イーサリアムもかつては**プルーフ・オブ・ワーク(PoW)**に基づいたコンセンサスプロトコルを使用していました。
#### ブロックの作成 {#pow-block-creation}
@@ -46,7 +46,7 @@ lang: ja
### プルーフ・オブ・ステークベース {#proof-of-stake}
-イーサリアムは現在、\*\*プルーフ・オブ・ステーク(PoS)\*\*に基づいたコンセンサスプロトコルを使用しています。
+イーサリアムは現在、**プルーフ・オブ・ステーク(PoS)**に基づいたコンセンサスプロトコルを使用しています。
#### ブロックの作成 {#pos-block-creation}
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 0c2c68b22ee..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
@@ -35,7 +35,7 @@ lang: ja
## ファイナリティ {#finality}
-分散ネットワークにおけるトランザクションのファイナリティとは、ブロックの当該部分を変更するためには大量のイーサをバーンする必要がある場合に達成されます。 イーサリアムのプルーフ・オブ・ステークでは、ファイナリティは「チェックポイント」ブロックを用いて管理されます。 各エポックの最初のブロックがチェックポイントになります。 バリデータは、有効だと見なすチェックポイントのペアに対して投票を行います。 ステーキングされたイーサの合計のうち少なくとも3分の2が当該のチェックポイントのペアに対して投票した場合、これらのチェックポイントは更新されます。 2つの(ターゲットである)チェックポイントのうち、より新しいチェックポイントの方が「正当化」されます。 チェックポイントのペアにおけるより古いチェックポイントは、1つ前のエポックにおいて「ターゲット」のチェックポイントとしてすでに正当化されています。 こうして正当化されたチェックポイントは、「ファイナライズ済み」にアップグレードされます。 このチェックポイントをアップグレードするプロセスは、\*\*[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)\*\*によって処理されます。 Casper-FFGはコンセンサスのためのブロックファイナリティツールです。 ブロックが一度ファイナライズされると、ステーカーの大多数のスラッシングなしには覆したり変更したりすることはできず、経済的に実行不可能になります。
+分散ネットワークにおけるトランザクションのファイナリティとは、ブロックの当該部分を変更するためには大量のイーサをバーンする必要がある場合に達成されます。 イーサリアムのプルーフ・オブ・ステークでは、ファイナリティは「チェックポイント」ブロックを用いて管理されます。 各エポックの最初のブロックがチェックポイントになります。 バリデータは、有効だと見なすチェックポイントのペアに対して投票を行います。 ステーキングされたイーサの合計のうち少なくとも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の過半数を取り戻し、チェーンのファイナライズを完了できるようになります。
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 6b780a97872..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
@@ -4,7 +4,7 @@ description: "イーサリアムにおけるプルーフ・オブ・ワーク (P
lang: ja
---
-イーサリアムネットワークは、\*\*[プルーフ・オブ・ワーク(PoW)](/developers/docs/consensus-mechanisms/pow)\*\*というコンセンサスメカニズムを使用して始まりました。 このメカニズムにより、イーサリアムネットワークのノードは、ブロックチェーンに記録されたすべての情報に関してネットワーク全体で合意を取り、特定の種類の経済的な攻撃を防ぎました。 しかし、イーサリアムは2022年にプルーフ・オブ・ワークを停止し、代わりに[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)を使用し始めました。
+イーサリアムネットワークは、**[プルーフ・オブ・ワーク(PoW)](/developers/docs/consensus-mechanisms/pow)**というコンセンサスメカニズムを使用して始まりました。 このメカニズムにより、イーサリアムネットワークのノードは、ブロックチェーンに記録されたすべての情報に関してネットワーク全体で合意を取り、特定の種類の経済的な攻撃を防ぎました。 しかし、イーサリアムは2022年にプルーフ・オブ・ワークを停止し、代わりに[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos)を使用し始めました。
イーサリアム改善提案(EIP)の詳細
diff --git a/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md
index 7e73ce5f1c4..ea3eff21f72 100644
--- a/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md
+++ b/public/content/translations/ja/guides/how-to-create-an-ethereum-account/index.md
@@ -6,7 +6,7 @@ lang: ja
# イーサリアムアカウントの開設方法
-\*\*イーサリアムアカウントは誰でも無料で作成できます。\*\*暗号通貨ウォレットアプリをインストールするだけです。 ウォレットがイーサリアムアカウントの作成と管理を行います。 ウォレットを使えば、トランザクションの送信、残高確認、イーサリアム上の他のアプリへの接続ができます。
+**イーサリアムアカウントは誰でも無料で作成できます。**暗号通貨ウォレットアプリをインストールするだけです。 ウォレットがイーサリアムアカウントの作成と管理を行います。 ウォレットを使えば、トランザクションの送信、残高確認、イーサリアム上の他のアプリへの接続ができます。
また、ウォレットがあれば、トークン取引所、ゲーム、[NFT](/glossary/#nft)マーケットプレイスに即座にログインできます。 イーサリアム上のアプリでは個別の登録は不要で、1つのアカウントですべてにアクセスできます。
@@ -36,7 +36,7 @@ lang: ja
一部のアプリでは、秘密の「リカバリーフレーズ」(「シードフレーズ」や「ニーモニック」とも呼ばれることがあります) を保存するよう求められることがあります。 このフレーズを安全に保管することは非常に重要です！ このフレーズはイーサリアムアカウントを生成するために使用され、トランザクションを送信するためにも利用できます。
-\*\*このフレーズを知っている人は、誰でもすべての資金を管理できてしまいます。\*\*絶対に誰とも共有しないでください。 このフレーズには、ランダムに生成された12~24個の単語を含めるべきです(単語の並び順も重要です)。
+**このフレーズを知っている人は、誰でもすべての資金を管理できてしまいます。**絶対に誰とも共有しないでください。 このフレーズには、ランダムに生成された12~24個の単語を含めるべきです(単語の並び順も重要です)。
diff --git a/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md b/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md
index f1cd1cf77dc..237a926b38c 100644
--- a/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md
+++ b/public/content/translations/ja/guides/how-to-id-scam-tokens/index.md
@@ -64,7 +64,7 @@ contentPreview=''>
詐欺を避ける最善の方法は、訪問するサイトのURLを入念に確認し、正しいサイトのアドレスをブックマークに保存することです。 こうすれば、スペルミスの心配や外部リンクに頼る必要なく、ブックマーク経由で正しいサイトにアクセスできます。
-## 詐欺から自分を守る方法 身を守る方法 {#protect-yourself}
+## 身を守る方法 {#protect-yourself}
1. **コントラクトアドレスを確認する**。 正当な組織の正当なトークンであることを確認し、同組織のウェブサイト上でコントラクトアドレスを確認します。 例えば、[`ARB`の正当なアドレスはこちらで確認できます](https://docs.arbitrum.foundation/deployment-addresses#token)。
diff --git a/public/content/translations/ja/nft/index.md b/public/content/translations/ja/nft/index.md
index ab3892172c4..14d6d659eaa 100644
--- a/public/content/translations/ja/nft/index.md
+++ b/public/content/translations/ja/nft/index.md
@@ -31,14 +31,14 @@ NFTとイーサリアムによって、現在のインターネットが持つ
| 非代替性トークン(NFT)インターネット | 現在のインターネット |
| --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
-| \*\*あなたが資産の所有者です！\*\*売却やスワップができるのはあなただけです。 | **ある組織から資産を借りている**と、取り上げられる可能性があります。 |
+| **あなたが資産の所有者です！**売却やスワップができるのはあなただけです。 | **ある組織から資産を借りている**と、取り上げられる可能性があります。 |
| NFTは**デジタル上でユニーク**であり、同じNFTは2つと存在しません。 | **コピーは、オリジナルと区別できない**場合が多くあります。 |
| NFTの所有権はブロックチェーンに保存され、誰もが**公に検証**できます。 | デジタルアイテムの所有権記録へのアクセスは**機関によって管理されており**、あなたは彼らの言葉を信じるしかありません。 |
| NFTはイーサリアム上の[スマートコントラクト](/glossary/#smart-contract)です。 これは、イーサリアム上の他のスマートコントラクトやアプリで**簡単に使用できる**ことを意味します！ | デジタルアイテムを扱う企業は通常、**独自の「ウォールドガーデン」型インフラストラクチャを必要とします**。 |
| コンテンツ**クリエイターはどこでも作品を販売でき**、グローバル市場にアクセスできます。 | クリエイターは、使用するプラットフォームのインフラと流通経路に依存する。 これらはしばしば、利用規約や**地理的制限**の対象となります。 |
| NFTクリエイターは自身の作品に対する**所有権を保持し**、ロイヤリティをNFTコントラクトに直接プログラムすることができます。 | 音楽**ストリーミングサービスなどのプラットフォームは、売上からの利益の大部分を保持します**。 |
-## 非代替性トークン(NFT)の使用方法 NFTのユースケース {#nft-use-cases}
+## NFTのユースケース {#nft-use-cases}
NFTは以下のような多数の用途に使用されます。
diff --git a/public/content/translations/ja/refi/index.md b/public/content/translations/ja/refi/index.md
index fe5cf103ad1..f3b3561d481 100644
--- a/public/content/translations/ja/refi/index.md
+++ b/public/content/translations/ja/refi/index.md
@@ -30,7 +30,7 @@ ReFiはまた、[分散型サイエンス (DeSci)](/desci/) のムーブメン
## 炭素クレジットのトークン化 {#tokenization-of-carbon-credits}
-\*\*[自主的炭素市場 (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)\*\*とは、継続的な排出量を削減するか、すでに大気中に放出された温室効果ガスを除去することによって、炭素排出量に検証済みのプラスの影響を与えるプロジェクトに資金を提供する仕組みです。 これらのプロジェクトは、実証された後に「カーボンクレジット」と呼ばれる資産を受け取り、気候変動対策を支援したい個人や組織に対して販売できます。
+**[自主的炭素市場 (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)**とは、継続的な排出量を削減するか、すでに大気中に放出された温室効果ガスを除去することによって、炭素排出量に検証済みのプラスの影響を与えるプロジェクトに資金を提供する仕組みです。 これらのプロジェクトは、実証された後に「カーボンクレジット」と呼ばれる資産を受け取り、気候変動対策を支援したい個人や組織に対して販売できます。
VCMに加え、政府が義務付けた炭素市場 (「コンプライアンス市場」) もいくつかあります。これは、特定の管轄区域 (国や地域など) 内の法律や規制を通じて炭素価格を設定し、配布される許可証の供給を管理することを目的としています。 コンプライアンス市場では、管轄区域内の汚染者に対して排出削減を奨励しますが、すでに排出された温室効果ガスを除去することはできません。
@@ -42,7 +42,7 @@ VCMに加え、政府が義務付けた炭素市場 (「コンプライアンス
4. 取引に非常に時間がかかる
5. スケーラビリティの欠如
-VCMを新しいブロックチェーンベースの\*\*デジタル炭素市場 (DCM)\*\*に移行することは、炭素クレジットの検証、取引、消費のための既存の技術をアップグレードする機会となる可能性があります。 公的に検証可能なデータ、幅広いユーザーのアクセス、より高い流動性がブロックチェーンにより可能になります。
+VCMを新しいブロックチェーンベースの**デジタル炭素市場 (DCM)**に移行することは、炭素クレジットの検証、取引、消費のための既存の技術をアップグレードする機会となる可能性があります。 公的に検証可能なデータ、幅広いユーザーのアクセス、より高い流動性がブロックチェーンにより可能になります。
ReFiプロジェクトでブロックチェーンテクノロジーを採用すると、次のような従来の市場が抱える多くの問題を軽減することができます。
diff --git a/public/content/translations/ja/roadmap/account-abstraction/index.md b/public/content/translations/ja/roadmap/account-abstraction/index.md
index a284de8aff8..c4858240862 100644
--- a/public/content/translations/ja/roadmap/account-abstraction/index.md
+++ b/public/content/translations/ja/roadmap/account-abstraction/index.md
@@ -10,7 +10,7 @@ summaryPoints:
# アカウント抽象化 {#account-abstraction}
-ほとんどの既存ユーザーは、\*\*[外部所有アカウント(EOA)](/glossary/#eoa)\*\*を使用してイーサリアムとやりとりします。 ユーザーとイーサリアムのやり取りは、EOAにより制限されています。 例えば、トランザクションのバッチ処理が困難になり、ユーザーはトランザクションフィーを支払うために常にETH残高を維持する必要があります。
+ほとんどの既存ユーザーは、**[外部所有アカウント(EOA)](/glossary/#eoa)**を使用してイーサリアムとやりとりします。 ユーザーとイーサリアムのやり取りは、EOAにより制限されています。 例えば、トランザクションのバッチ処理が困難になり、ユーザーはトランザクションフィーを支払うために常にETH残高を維持する必要があります。
アカウント抽象化は、ユーザーがアカウントに対してセキュリティを強化したり、ユーザーエクスペリエンスを柔軟にプログラムできるようにすることで、これらの問題を解決する方法です。 これは[EOAをアップグレードする](https://eips.ethereum.org/EIPS/eip-7702) (EIP-7702) ことで可能になり、スマートコントラクトでEOAを制御できるようになります。 また、既存のプロトコルと並行して動作する[第2の独立したトランザクションシステム](https://eips.ethereum.org/EIPS/eip-4337) (EIP-4337) を追加するという方法もあります。 どの方法であっても、結果としてスマートコントラクトウォレットを介してイーサリアムにアクセスします。これは、既存のプロトコルの一部を利用しても、アドオンのトランザクションネットワークを介しても、ネイティブにサポートされます。
diff --git a/public/content/translations/ja/roadmap/beacon-chain/index.md b/public/content/translations/ja/roadmap/beacon-chain/index.md
index 338672a68f8..53615863446 100644
--- a/public/content/translations/ja/roadmap/beacon-chain/index.md
+++ b/public/content/translations/ja/roadmap/beacon-chain/index.md
@@ -18,7 +18,7 @@ summaryPoint3: "ビーコンチェーンは、コンセンサスロジックと
ビーコンチェーンは、2020年に開始されたオリジナルのプルーフ・オブ・ステーク型ブロックチェーンの名称です。 当初は、イーサリアムメインネットに適用する前に、プルーフ・オブ・ステークのコンセンサスロジックが健全で持続可能であることを確認するために作成されました。 そのため、元来のプルーフ・オブ・ワークのイーサリアムと並行して稼働していました。 ビーコンチェーンは「空の」ブロックのチェーンだったので、イーサリアムでプルーフ・オブ・ワークを停止し、プルーフ・オブ・ステークへと切り替えるには、ビーコンチェーンで実行クライアントのトランザクションデータを受け入れ、ブロックにバンドルし、プルーフ・オブ・ステークに基づく合意メカニズムを使ってブロックチェーンに構成する必要がありました。 同時に、オリジナルのイーサリアムのクライアントは、マイニング、ブロック伝播、コンセンサスロジックを停止し、ビーコンチェーンへと継承させました。 このイベントは「[マージ](/roadmap/merge/)」として知られています。 マージによって、2つのブロックチェーンは プルーフ・オブ・ステークに統合され、現在は、ノードごとに2つの異なるクライアントが必要になりました。 ビーコンチェーンは現在、コンセンサスレイヤーであり、ブロックのゴシップとコンセンサスロジックを処理するコンセンサスクライアントのピアツーピアネットワークです。一方、元々のクライアントは実行レイヤーを形成し、トランザクションのゴシップと実行、そしてイーサリアムの状態を管理しています。 2つのレイヤーは、エンジンAPIを使ってお互いに通信することができます。
-## ビーコンチェーンとは ビーコンチェーンの役割 {#what-does-the-beacon-chain-do}
+## ビーコンチェーンの役割 {#what-does-the-beacon-chain-do}
ビーコンチェーンとは、イーサリアムの[ステーカー](/staking/)が実際のイーサリアムブロックの検証を開始する前に、そのステーカーたちのネットワークを運営、調整していたアカウントのレジャーに与えられた名前です。 ただし、ビーコンチェーンでは、トランザクションの処理やスマートコントラクトとのやりとりは行いません。代わりに、実行レイヤーがこれらの処理を行います
ビーコンチェーンでは、ブロックとアテステーションの処理、フォーク選択アルゴリズムの実行、報酬とペナルティの管理などを行います。
diff --git a/public/content/translations/ja/roadmap/fusaka/index.md b/public/content/translations/ja/roadmap/fusaka/index.md
index ffbbd0dae6d..10d2bbd4ea3 100644
--- a/public/content/translations/ja/roadmap/fusaka/index.md
+++ b/public/content/translations/ja/roadmap/fusaka/index.md
@@ -152,7 +152,7 @@ EIP-7917により、ビーコンチェーンは次のエポックの今後のブ
#### 先頭ゼロカウント(CLZ)オペコード {#count-leading-zeros-opcode}
-この機能は、\*\*先頭ゼロカウント(CLZ)\*\*という小さなEVM命令を追加します。 EVM内のほとんどすべては256ビット値として表現されており、この新しいオペコードは先頭にいくつのゼロビットがあるかを返します。 これは多くの命令セットアーキテクチャで一般的な機能であり、より効率的な算術演算を可能にします。 実際には、これにより現在の手動でのビットスキャンが1ステップに圧縮されるため、最初のセットビットを見つけたり、バイトをスキャンしたり、ビットフィールドを解析することがよりシンプルかつ安価になります。 このオペコードは低コストで固定料金となっており、基本的な加算（add）命令と同程度の性能であることがベンチマークによって確認されています。これにより、同じ処理をより短いバイトコードで実行でき、ガスの節約にもつながります。
+この機能は、**先頭ゼロカウント(CLZ)**という小さなEVM命令を追加します。 EVM内のほとんどすべては256ビット値として表現されており、この新しいオペコードは先頭にいくつのゼロビットがあるかを返します。 これは多くの命令セットアーキテクチャで一般的な機能であり、より効率的な算術演算を可能にします。 実際には、これにより現在の手動でのビットスキャンが1ステップに圧縮されるため、最初のセットビットを見つけたり、バイトをスキャンしたり、ビットフィールドを解析することがよりシンプルかつ安価になります。 このオペコードは低コストで固定料金となっており、基本的な加算（add）命令と同程度の性能であることがベンチマークによって確認されています。これにより、同じ処理をより短いバイトコードで実行でき、ガスの節約にもつながります。
**参考リソース**: [EIP-7939 技術仕様](https://eips.ethereum.org/EIPS/eip-7939)
diff --git a/public/content/translations/ja/roadmap/fusaka/peerdas/index.md b/public/content/translations/ja/roadmap/fusaka/peerdas/index.md
index 37ea3cb88fd..039c4dc3c81 100644
--- a/public/content/translations/ja/roadmap/fusaka/peerdas/index.md
+++ b/public/content/translations/ja/roadmap/fusaka/peerdas/index.md
@@ -6,7 +6,7 @@ lang: ja
# PeerDAS {#peer-das}
-イーサリアムプロトコルは、[EIP-4844によるブロブトランザクションの導入](/roadmap/danksharding/)以来、最も重要なスケーリングアップグレードを実施しています。 [Fusakaアップグレード](/roadmap/fusaka/)の一環として、PeerDASはブロブデータを処理する新しい方法を導入し、L2の\*\*[データ可用性（DA）](/developers/docs/data-availability/)\*\*容量を約1桁増加させます。
+イーサリアムプロトコルは、[EIP-4844によるブロブトランザクションの導入](/roadmap/danksharding/)以来、最も重要なスケーリングアップグレードを実施しています。 [Fusakaアップグレード](/roadmap/fusaka/)の一環として、PeerDASはブロブデータを処理する新しい方法を導入し、L2の**[データ可用性（DA）](/developers/docs/data-availability/)**容量を約1桁増加させます。
[ブロブスケーリングのロードマップ詳細](https://blog.ethereum.org/2025/08/22/protocol-update-002)
@@ -32,7 +32,7 @@ L2のスケーリングに向けた最初の大きな一歩は、[プロト・
イーサリアムのブロブは、L2のセキュリティを保証する強力なデータ可用性保証を提供します。 これを行うために、イーサリアムのノードはブロブを完全にダウンロードして保存する必要があります。 しかし、ネットワーク内でブロブをより効率的に分散させ、この制限を回避できたらどうでしょうか？
-データを保存し、その可用性を確保するための異なるアプローチが、\*\*データ可用性サンプリング（DAS）\*\*です。 イーサリアムを実行するすべてのコンピュータがすべてのブロブを完全に保存する代わりに、DASは分散化された分業を導入します。 データの処理負担を、より小さく管理しやすいタスクをノードのネットワーク全体に分散させることで軽減します。 ブロブは断片に分割され、各ノードは全ノードにわたる均一なランダム分布のメカニズムを使用して、いくつかの断片のみをダウンロードします。
+データを保存し、その可用性を確保するための異なるアプローチが、**データ可用性サンプリング（DAS）**です。 イーサリアムを実行するすべてのコンピュータがすべてのブロブを完全に保存する代わりに、DASは分散化された分業を導入します。 データの処理負担を、より小さく管理しやすいタスクをノードのネットワーク全体に分散させることで軽減します。 ブロブは断片に分割され、各ノードは全ノードにわたる均一なランダム分布のメカニズムを使用して、いくつかの断片のみをダウンロードします。
これにより、データの可用性と完全性を証明するという新しい問題が生じます。 個々のノードが小さな断片しか保持していない場合、ネットワークはどのようにしてデータが利用可能であり、すべてが正しいことを保証できるでしょうか？ 悪意のあるノードが偽のデータを提供し、強力なデータ可用性保証を簡単に破る可能性があります！ ここで暗号技術が役立ちます。
@@ -72,7 +72,7 @@ PeerDASでは、拡張されたブロブデータは「列」と呼ばれる128
ネットワークは理論的に8倍多くのブロブを処理できるようになりますが、ブロブの増加は段階的に適切にテストされ、安全に実行される必要がある変更です。 テストネットはメインネットに機能をデプロイするための十分な信頼性を提供しますが、大幅に多い数のブロブを有効にする前に、p2pネットワークの安定性を確保する必要があります。
-ネットワークに過大な負荷をかけることなく、ブロックあたりの目標ブロブ数を段階的に引き上げるために、Fusakaは\*\*[ブロブパラメータのみ（BPO）](https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623)\*\*のフォークを導入します。 広範なエコシステムの調整、合意、ソフトウェアのアップデートが必要な通常のフォークとは異なり、[BPO（EIP-7892）](https://eips.ethereum.org/EIPS/eip-7892)は、介入なしに時間とともに最大ブロブ数を増加させる、事前にプログラムされたアップグレードです。
+ネットワークに過大な負荷をかけることなく、ブロックあたりの目標ブロブ数を段階的に引き上げるために、Fusakaは**[ブロブパラメータのみ（BPO）](https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623)**のフォークを導入します。 広範なエコシステムの調整、合意、ソフトウェアのアップデートが必要な通常のフォークとは異なり、[BPO（EIP-7892）](https://eips.ethereum.org/EIPS/eip-7892)は、介入なしに時間とともに最大ブロブ数を増加させる、事前にプログラムされたアップグレードです。
これは、Fusakaが有効になりPeerDASが稼働した直後、ブロブの数は変わらないことを意味します。 ブロブの数は、最大48に達するまで数週間ごとに倍増し始め、その間デベロッパーはメカニズムが期待どおりに機能しており、ネットワークを実行しているノードに悪影響を及ぼしていないことを監視します。
diff --git a/public/content/translations/ja/roadmap/future-proofing/index.md b/public/content/translations/ja/roadmap/future-proofing/index.md
index 62982402384..afc1e5e8574 100644
--- a/public/content/translations/ja/roadmap/future-proofing/index.md
+++ b/public/content/translations/ja/roadmap/future-proofing/index.md
@@ -27,7 +27,7 @@ template: roadmap
**最近実装された変更点:**
-- **ガス計算の見直し:** [ガス](/glossary/#gas)の計算方法は、\*\*EIP-1559(2021年のロンドン・アップグレードで実装)\*\*で大幅に改善され、より予測可能なトランザクション価格設定のためにベースフィーとバーン(焼却)メカニズムが導入されました。
+- **ガス計算の見直し:** [ガス](/glossary/#gas)の計算方法は、**EIP-1559(2021年のロンドン・アップグレードで実装)**で大幅に改善され、より予測可能なトランザクション価格設定のためにベースフィーとバーン(焼却)メカニズムが導入されました。
- **`SELFDESTRUCT`の制限:** `SELFDESTRUCT`オペコードは、めったに使用されませんが、潜在的なリスクをもたらしました。 その機能は、特にステート管理に関する危険を軽減するため、**EIP-6780によってデンクン・アップグレード(2024年3月)で大幅に制限**されました。
- **トランザクションタイプの近代化:** 新機能のサポートとレガシータイプに対する効率向上のため、新しいトランザクションフォーマットが導入されました(例: デンクン・アップグレードにおけるブロブのための**EIP-2718**および**EIP-4844**経由)。
@@ -44,7 +44,7 @@ template: roadmap
長期的な将来を見据えたアップグレードの多く、特に**コアプロトコルの完全な量子耐性は、まだ研究段階にあり、実装まで数年かかる可能性**があります。
-しかし、**簡素化の取り組みではすでに大きな進歩が見られます。** 例えば、\*\*`SELFDESTRUCT`の制限(EIP-6780)**や**ブロブ搭載トランザクションの導入(EIP-4844)\*\*のような主要な変更は、\*\*デンクン・アップグレード(2024年3月)\*\*で実装されました。 クライアントの圧縮スキームの調和やその他の効率改善に関する作業も継続しています。
+しかし、**簡素化の取り組みではすでに大きな進歩が見られます。** 例えば、**`SELFDESTRUCT`の制限(EIP-6780)**や**ブロブ搭載トランザクションの導入(EIP-4844)**のような主要な変更は、**デンクン・アップグレード(2024年3月)**で実装されました。 クライアントの圧縮スキームの調和やその他の効率改善に関する作業も継続しています。
**参考文献**
diff --git a/public/content/translations/ja/roadmap/merge/index.md b/public/content/translations/ja/roadmap/merge/index.md
index ded661a2ddd..90844ece2e9 100644
--- a/public/content/translations/ja/roadmap/merge/index.md
+++ b/public/content/translations/ja/roadmap/merge/index.md
@@ -49,7 +49,7 @@ summaryPoint4: "マージによりイーサリアムのエネルギー消費が
**マージによって、保有者やユーザーに何かが変わることはありませんでした。**
-_繰り返しになりますが_: ETHやイーサリアム上の他のデジタル資産のユーザーや保有者、またノードを運用していないステイカーは、\*\*マージに伴い、資金やウォレットに何かをする必要はありません。\*\*ETHはETHのままです。 マージ後も、「古いETH」/「新しいETH」や「ETH1」/「ETH2」のようなものはなく、ウォレットは以前とまったく同じように動作します。そうでないと言う人は詐欺師の可能性があります。
+_繰り返しになりますが_: ETHやイーサリアム上の他のデジタル資産のユーザーや保有者、またノードを運用していないステイカーは、**マージに伴い、資金やウォレットに何かをする必要はありません。**ETHはETHのままです。 マージ後も、「古いETH」/「新しいETH」や「ETH1」/「ETH2」のようなものはなく、ウォレットは以前とまったく同じように動作します。そうでないと言う人は詐欺師の可能性があります。
プルーフ・オブ・ワークを停止し、プルーフ・オブ・ステークに移行した後も、イーサリアムの誕生以降の全トランザクション履歴はそのままで、変更されていません。 マージ以前にウォレットに保有されていた資金は、マージ後も引き続きご利用いただけます。 **ユーザー側でアップグレードするための操作は必要ありません。**
diff --git a/public/content/translations/ja/roadmap/merge/issuance/index.md b/public/content/translations/ja/roadmap/merge/issuance/index.md
index fcf32283e73..ab003485ca4 100644
--- a/public/content/translations/ja/roadmap/merge/issuance/index.md
+++ b/public/content/translations/ja/roadmap/merge/issuance/index.md
@@ -51,16 +51,16 @@ ETH総供給量: **約120,520,000 ETH** (2022年9月のマージ時点)
- ステークされたETHが合計14,000,000 ETHの場合、ETH発行率は1日あたり約1700 ETHです([ソースを見る](https://ultrasound.money/))
- 年間で**約620,500** ETHが発行されることになります
-- インフレ率は\*\*約0.52%\*\*になりました (年間62万500 / 合計1億1930万)
+- インフレ率は**約0.52%**になりました (年間62万500 / 合計1億1930万)
**年間発行率合計 (マージ以前): 約4.61%** (4.09% + 0.52%)
-発行額の\*\*約88.7%\*\*は実行レイヤーのマイナーに支払われていました (4.09 / 4.61 \* 100)
+発行額の**約88.7%**は実行レイヤーのマイナーに支払われていました (4.09 / 4.61 \* 100)
-\*\*約11.3%\*\*はコンセンサスレイヤーのステーカーに発行されていました (0.52 / 4.61 \* 100)
+**約11.3%**はコンセンサスレイヤーのステーカーに発行されていました (0.52 / 4.61 \* 100)
diff --git a/public/content/translations/ja/roadmap/pbs/index.md b/public/content/translations/ja/roadmap/pbs/index.md
index 5cdc385e323..18fc8ca6570 100644
--- a/public/content/translations/ja/roadmap/pbs/index.md
+++ b/public/content/translations/ja/roadmap/pbs/index.md
@@ -7,7 +7,7 @@ lang: ja
# プロポーザー・ビルダー分離 {#proposer-builder-separation}
-現在のイーサリアムバリデータは、ブロックの作成_と_ブロードキャストの両方を行います。 バリデータは、ゴシップネットワークを通じて伝達されたトランザクションを1つのブロックにまとめて、イーサリアムネットワーク上のピアに送信します。 \*\*プロポーザー・ビルダー分離 (PBS)\*\*は、これらのタスクを複数のバリデータに分割するものです。 ブロックビルダーは、各スロットのブロックプロポーザーにブロックを提供する責任を負います。 ブロック提案者は、ブロックの内容を事前に知ることができません。ブロックビルダーに料金を支払い、最も報酬の高いものを選び、その後、ブロックをピアに送信します。
+現在のイーサリアムバリデータは、ブロックの作成_と_ブロードキャストの両方を行います。 バリデータは、ゴシップネットワークを通じて伝達されたトランザクションを1つのブロックにまとめて、イーサリアムネットワーク上のピアに送信します。 **プロポーザー・ビルダー分離 (PBS)**は、これらのタスクを複数のバリデータに分割するものです。 ブロックビルダーは、各スロットのブロックプロポーザーにブロックを提供する責任を負います。 ブロック提案者は、ブロックの内容を事前に知ることができません。ブロックビルダーに料金を支払い、最も報酬の高いものを選び、その後、ブロックをピアに送信します。
このアップグレードが重要な理由はいくつかあります。 まず、このアップグレードでプロトコルレベルでトランザクションの検閲を防ぐことができます。 次に、ブロック構築の収益性をより最適化できる機関投資家に個人のバリデータが出し抜かれることを防ぐことができます。 最後に、ダンクシャーディングのアップグレードが有効になると、イーサリアムのスケーリングを補助します。
@@ -26,7 +26,7 @@ lang: ja
## PBSとMEV {#pbs-and-mev}
-\*\*最大抽出可能価値 (MEV)\*\*とは、バリデータがトランザクションを有利に並び替えることで収益性を最大化することを指します。 一般的な例には、分散型取引所でのスワップの裁定取引（例：大規模な売買のフロントランニング）や、DeFiポジションを清算する機会を見つけることなどがあります。 MEVを最大化するには、高度な技術ノウハウと、通常のバリデータに追加するカスタムソフトウェアが必要です。そのためMEV抽出において、組織的なオペレータの方が個人や趣味でバリデータ立てている人物よりも優れたパフォーマンスを発揮する可能性が非常に高くなります。 つまり、集中化されたオペレータは、個人でステーキングするよりも高いリターンを得られる可能性があるため、ホームステークを阻害する力が働いてしまうということです。
+**最大抽出可能価値 (MEV)**とは、バリデータがトランザクションを有利に並び替えることで収益性を最大化することを指します。 一般的な例には、分散型取引所でのスワップの裁定取引（例：大規模な売買のフロントランニング）や、DeFiポジションを清算する機会を見つけることなどがあります。 MEVを最大化するには、高度な技術ノウハウと、通常のバリデータに追加するカスタムソフトウェアが必要です。そのためMEV抽出において、組織的なオペレータの方が個人や趣味でバリデータ立てている人物よりも優れたパフォーマンスを発揮する可能性が非常に高くなります。 つまり、集中化されたオペレータは、個人でステーキングするよりも高いリターンを得られる可能性があるため、ホームステークを阻害する力が働いてしまうということです。
PBSでは、MEVの経済を再設定することによって、この問題を解決します。 ブロック提案者は、MEVを自分で探す代わりに、ブロックビルダーが提案したブロックの中から、適当なブロックを選択します。 ブロックビルダーは、MEVを巧みに抽出しているかもしれませんが、その報酬はブロック提案者に支払われます。 つまり、専門のブロックビルダーが小さなプールを持っていても、MEVの抽出を独占していても、その報酬は、個人のホームステーカーを含む、ネットワーク上のすべてのバリデータに分配される可能性があるということです。
diff --git a/public/content/translations/ja/roadmap/secret-leader-election/index.md b/public/content/translations/ja/roadmap/secret-leader-election/index.md
index 40053c8831b..2892cc72839 100644
--- a/public/content/translations/ja/roadmap/secret-leader-election/index.md
+++ b/public/content/translations/ja/roadmap/secret-leader-election/index.md
@@ -14,7 +14,7 @@ summaryPoints:
この状況は、攻撃者にとって利益を得る機会になる可能性があります。 例えば、スロット`n+1`に選ばれたブロック提案者が、スロット`n`の提案者に対してDoS攻撃を行うことで、ブロックを提案する機会を奪うことができます。 これにより、攻撃側のブロック提案者は、両方のスロットのMEVを抽出したり、2つのブロックに分かれるはずだったすべてのトランザクションを1つのブロックにまとめたりすることで、関連するすべての手数料を独占できます。 この攻撃は、高度な方法を使ってDOS攻撃から防御することができる技術力の高い機関のバリデータよりも、一般的な家庭のバリデータに対して悪影響を与える可能性が高く、結果的にバリデータの集中化につながる可能性があります。
-この問題には、いくつかの解決策があります。 その1つが[分散バリデータ技術](https://github.com/ethereum/distributed-validator-specs)です。これは、バリデータの実行に関連する様々なタスクを、冗長性を持たせて複数のマシンに分散させることで、攻撃者が特定のスロットでブロックが提案されるのを防ぐのをはるかに困難にすることを目的としています。 しかし、最も堅牢な解決策は\*\*シングル・シークレット・リーダー選出(SSLE)\*\*です。
+この問題には、いくつかの解決策があります。 その1つが[分散バリデータ技術](https://github.com/ethereum/distributed-validator-specs)です。これは、バリデータの実行に関連する様々なタスクを、冗長性を持たせて複数のマシンに分散させることで、攻撃者が特定のスロットでブロックが提案されるのを防ぐのをはるかに困難にすることを目的としています。 しかし、最も堅牢な解決策は**シングル・シークレット・リーダー選出(SSLE)**です。
## シングル・シークレット・リーダー選出 {#secret-leader-election}
@@ -33,7 +33,7 @@ SSLE(シークレット・シングル・リーダー選出)では、選出さ
## シークレット・非シングル・リーダー選出(SnSLE) {#secret-non-single-leader-election}
-プルーフ・オブ・ワーク下でのブロック提案の決定方法と同様に、各バリデータがスロットごとにランダムにブロックを提案する機会を得る仕組みを作るという別の提案もあり、\*\*シークレット・非シングル・リーダー選出(SnSLE)\*\*として知られています。 例えば、現在のプロトコルでバリデータをランダムに選択するために使われているRANDAO関数を活用すれば、簡単に実現できます。 RANDAOを使うアイデアとは、多くの独立しているバリデータから送信されたハッシュを混合することで、十分な乱数が生成するというものです。 SnSLEにおいて、これらのハッシュを使って、次のブロック提案者を選ぶことができます。例えば、最小値のハッシュの選択です。 有効なハッシュ値の範囲を設定することで、各スロットでバリデータが選ばれる可能性を調整することができます。 ハッシュが`2^256 * 5 / N` (N = アクティブなバリデータの数) 未満でなければならないとアサートすることで、各スロットで個々のバリデータが選ばれる確率は`5/N`になります。 この例では、少なくとも1人の提案者が各スロットで有効なハッシュを生成する確率は99.3%になります。
+プルーフ・オブ・ワーク下でのブロック提案の決定方法と同様に、各バリデータがスロットごとにランダムにブロックを提案する機会を得る仕組みを作るという別の提案もあり、**シークレット・非シングル・リーダー選出(SnSLE)**として知られています。 例えば、現在のプロトコルでバリデータをランダムに選択するために使われているRANDAO関数を活用すれば、簡単に実現できます。 RANDAOを使うアイデアとは、多くの独立しているバリデータから送信されたハッシュを混合することで、十分な乱数が生成するというものです。 SnSLEにおいて、これらのハッシュを使って、次のブロック提案者を選ぶことができます。例えば、最小値のハッシュの選択です。 有効なハッシュ値の範囲を設定することで、各スロットでバリデータが選ばれる可能性を調整することができます。 ハッシュが`2^256 * 5 / N` (N = アクティブなバリデータの数) 未満でなければならないとアサートすることで、各スロットで個々のバリデータが選ばれる確率は`5/N`になります。 この例では、少なくとも1人の提案者が各スロットで有効なハッシュを生成する確率は99.3%になります。
## 現在の進捗 {#current-progress}
diff --git a/public/content/translations/ja/roadmap/security/index.md b/public/content/translations/ja/roadmap/security/index.md
index 21151ed429b..cd10e5a92ba 100644
--- a/public/content/translations/ja/roadmap/security/index.md
+++ b/public/content/translations/ja/roadmap/security/index.md
@@ -27,7 +27,7 @@ template: roadmap
## 検閲からの防御 {#defending-against-censorship}
-分散化は、個人または少人数の[バリデーター](/glossary/#validator)グループが過大な影響力を持つことを防ぎます。 新たなステーキングの技術は、イーサリアムのバリデータを可能な限り分散化した状態に保ち、ハードウェア、ソフトウェア、ネットワークの障害から保護します。 これには、複数の[ノード](/glossary/#node)間でバリデーターの責任を分担するソフトウェアが含まれます。 これは\*\*分散バリデーター技術 (DVT)\*\*として知られています。 [ステーキングプール](/glossary/#staking-pool)は、DVTを利用するインセンティブがあります。DVTは複数のコンピューターが共同で検証に参加することを可能にし、冗長性とフォールトトレランスを高めるからです。 DVTでは、バリデータ鍵を複数のシステムに分割します。これにより、1つのオペレータが複数のバリデータを実行できなくなり、 不正なオペレータによるイーサリアムへ攻撃が困難になります。 つまり、バリデーターを個人ではなく、_コミュニティ_として実行することで、セキュリティを高めるというアイデアです。
+分散化は、個人または少人数の[バリデーター](/glossary/#validator)グループが過大な影響力を持つことを防ぎます。 新たなステーキングの技術は、イーサリアムのバリデータを可能な限り分散化した状態に保ち、ハードウェア、ソフトウェア、ネットワークの障害から保護します。 これには、複数の[ノード](/glossary/#node)間でバリデーターの責任を分担するソフトウェアが含まれます。 これは**分散バリデーター技術 (DVT)**として知られています。 [ステーキングプール](/glossary/#staking-pool)は、DVTを利用するインセンティブがあります。DVTは複数のコンピューターが共同で検証に参加することを可能にし、冗長性とフォールトトレランスを高めるからです。 DVTでは、バリデータ鍵を複数のシステムに分割します。これにより、1つのオペレータが複数のバリデータを実行できなくなり、 不正なオペレータによるイーサリアムへ攻撃が困難になります。 つまり、バリデーターを個人ではなく、_コミュニティ_として実行することで、セキュリティを高めるというアイデアです。
分散バリデーター技術の詳細を読む
diff --git a/public/content/translations/ja/roadmap/single-slot-finality/index.md b/public/content/translations/ja/roadmap/single-slot-finality/index.md
index 99ed6f97374..043d1b6f72e 100644
--- a/public/content/translations/ja/roadmap/single-slot-finality/index.md
+++ b/public/content/translations/ja/roadmap/single-slot-finality/index.md
@@ -6,7 +6,7 @@ lang: ja
# シングルスロットファイナリティ {#single-slot-finality}
-イーサリアムのブロックが確定するまで、約15分かかります。 しかし、イーサリアムのコンセンサスメカニズムでブロックをより効率的に検証することで、ファイナリティまでの時間を大幅に短縮することができます。 15分間待つ必要はなく、同じスロット内でブロックが提案され、確定することができます。 このコンセプトは、\*\*シングルスロットファイナリティ(SSF)\*\*と呼ばれます。
+イーサリアムのブロックが確定するまで、約15分かかります。 しかし、イーサリアムのコンセンサスメカニズムでブロックをより効率的に検証することで、ファイナリティまでの時間を大幅に短縮することができます。 15分間待つ必要はなく、同じスロット内でブロックが提案され、確定することができます。 このコンセプトは、**シングルスロットファイナリティ(SSF)**と呼ばれます。
## ファイナリティとは {#what-is-finality}
diff --git a/public/content/translations/ja/security/index.md b/public/content/translations/ja/security/index.md
index 352ffc41d4f..1aad90edf39 100644
--- a/public/content/translations/ja/security/index.md
+++ b/public/content/translations/ja/security/index.md
@@ -56,7 +56,7 @@ lang: ja
### 送信する前にトランザクションを再確認する {#double-check-transactions}
-誤ったウォレットアドレスに仮想通貨を送信してしまうことはよくある間違いです。 \*\*イーサリアム上でトランザクションを送ると取り消しができません。\*\*送信先のアドレスの所有者を知っていて、あなたが送金した額を返金してくれるように説得することができなければ、失ったお金を取り戻すことはできません。
+誤ったウォレットアドレスに仮想通貨を送信してしまうことはよくある間違いです。 **イーサリアム上でトランザクションを送ると取り消しができません。**送信先のアドレスの所有者を知っていて、あなたが送金した額を返金してくれるように説得することができなければ、失ったお金を取り戻すことはできません。
トランザクションを送信する前に、送信先アドレスが、意図する受信者のアドレスと正確に一致することを常に確認してください。
また、スマートコントラクトを使ってやり取りする場合にも、署名する前にトランザクションメッセージを読むことが良い方法です。
diff --git a/public/content/translations/ja/social-networks/index.md b/public/content/translations/ja/social-networks/index.md
index 87c00466c06..926843932dc 100644
--- a/public/content/translations/ja/social-networks/index.md
+++ b/public/content/translations/ja/social-networks/index.md
@@ -84,37 +84,37 @@ Mirrorで公開された投稿は、分散型ストレージプラットフォ
### Braveブラウザ {#brave}
-- Braveは、デジタル広告とコンテンツクリエイター支援に革命をもたらすため、Ethereum上に構築されたERC-20トークンである\*\*[Basic Attention Token(BAT)](https://basicattentiontoken.org/)\*\*をそのブラウザエコシステムに統合しました。
+- Braveは、デジタル広告とコンテンツクリエイター支援に革命をもたらすため、Ethereum上に構築されたERC-20トークンである**[Basic Attention Token(BAT)](https://basicattentiontoken.org/)**をそのブラウザエコシステムに統合しました。
-- \*\*[Brave Rewardsプログラム](https://brave.com/brave-rewards/)\*\*では、ユーザーはプライバシーを尊重する広告を閲覧してBATを獲得し、YouTube、Twitter、GitHubなどのさまざまなプラットフォームのウェブサイトやコンテンツクリエイターに、視聴時間に基づいて自動的に貢献できます。
+- **[Brave Rewardsプログラム](https://brave.com/brave-rewards/)**では、ユーザーはプライバシーを尊重する広告を閲覧してBATを獲得し、YouTube、Twitter、GitHubなどのさまざまなプラットフォームのウェブサイトやコンテンツクリエイターに、視聴時間に基づいて自動的に貢献できます。
-- コンテンツクリエイターは\*\*[Brave認証クリエイター](https://creators.brave.com/)\*\*として登録することで、これらの貢献を自身のEthereumウォレットで直接受け取ることができ、従来のウェブプラットフォームとブロックチェーンベースの収益化の間のブリッジを創出します。
+- コンテンツクリエイターは**[Brave認証クリエイター](https://creators.brave.com/)**として登録することで、これらの貢献を自身のEthereumウォレットで直接受け取ることができ、従来のウェブプラットフォームとブロックチェーンベースの収益化の間のブリッジを創出します。
- BATトークンはEthereumブロックチェーン上に独立して存在するため、ユーザーは一度獲得したトークンを個人のウォレットや取引所に送金できます。
### Audius音楽プラットフォーム {#audius}
-- \*\*[Audius](https://audius.co/)\*\*は、Ethereumブロックチェーン技術を利用してアーティストとファンを直接結びつける音楽ストリーミングプラットフォームです。
+- **[Audius](https://audius.co/)**は、Ethereumブロックチェーン技術を利用してアーティストとファンを直接結びつける音楽ストリーミングプラットフォームです。
-- このプラットフォームはハイブリッドな分散型アーキテクチャを特徴としており、コンテンツはIPFSに保存される一方、所有権と\*\*[AUDIOトークン](https://eth.blockscout.com/token/0x18aaa7115705e8be94bffebde57af9bfc265b998)\*\*のためにブロックチェーンが利用されています。
+- このプラットフォームはハイブリッドな分散型アーキテクチャを特徴としており、コンテンツはIPFSに保存される一方、所有権と**[AUDIOトークン](https://eth.blockscout.com/token/0x18aaa7115705e8be94bffebde57af9bfc265b998)**のためにブロックチェーンが利用されています。
-- Audiusは\*\*[TikTokとの提携](https://audius.co/tiktok)\*\*を確立し、主流のオーディエンスにWeb3機能を提供するとともに、アーティストがブロックチェーン技術を通じてコンテンツを収益化できるようにしています。
+- Audiusは**[TikTokとの提携](https://audius.co/tiktok)**を確立し、主流のオーディエンスにWeb3機能を提供するとともに、アーティストがブロックチェーン技術を通じてコンテンツを収益化できるようにしています。
-- プラットフォームの技術的な詳細は\*\*[ホワイトペーパー](https://whitepaper.audius.co/)\*\*で公開されており、Ethereumのインフラストラクチャ上にどのように構築されているかが示されています。
+- プラットフォームの技術的な詳細は**[ホワイトペーパー](https://whitepaper.audius.co/)**で公開されており、Ethereumのインフラストラクチャ上にどのように構築されているかが示されています。
### Sorareファンタジースポーツ {#sorare}
-- \*\*[Sorare](https://sorare.com/)**は、**[Ethereum上に構築されたファンタジースポーツプラットフォーム](https://sorare.com/help/a/4402888626577/what-is-a-sorare-wallet)\*\*で、ユーザーは公式NFT選手カードを収集、取引、プレイすることができます。
+- **[Sorare](https://sorare.com/)**は、**[Ethereum上に構築されたファンタジースポーツプラットフォーム](https://sorare.com/help/a/4402888626577/what-is-a-sorare-wallet)**で、ユーザーは公式NFT選手カードを収集、取引、プレイすることができます。
-- 選手カードはEthereumブロックチェーン上で検証可能なNFTであり、プラットフォームのスマートコントラクトは\*\*[Etherscan](https://eth.blockscout.com/address/0x629a673a8242c2ac4b7b8c5d8735fbeac21a6205?tab=contract)\*\*で閲覧できます。
+- 選手カードはEthereumブロックチェーン上で検証可能なNFTであり、プラットフォームのスマートコントラクトは**[Etherscan](https://eth.blockscout.com/address/0x629a673a8242c2ac4b7b8c5d8735fbeac21a6205?tab=contract)**で閲覧できます。
-- Sorareは、従来のファンタジースポーツのゲームプレイとデジタル資産のブロックチェーン所有権を組み合わせ、主流のスポーツファンに\*\*[Ethereum資金調達](https://sorare.com/help/a/10969733392797/what-network-should-i-use-to-fund-my-eth-wallet)\*\*の機能を提供します。
+- Sorareは、従来のファンタジースポーツのゲームプレイとデジタル資産のブロックチェーン所有権を組み合わせ、主流のスポーツファンに**[Ethereum資金調達](https://sorare.com/help/a/10969733392797/what-network-should-i-use-to-fund-my-eth-wallet)**の機能を提供します。
### Twitter/X(暗号通貨チップ) {#twitter}
**[Twitter](https://x.com)**(現在のX)は、クリエイターの収益化とデジタルID認証を強化するために、ブロックチェーン技術を複数の方法で取り入れています。
-- **暗号通貨チップ**: このプラットフォームは\*\*[Ethereumによるチップ機能](https://help.x.com/en/using-x/tips)\*\*を統合しており、ユーザーはStrikeなどのEthereumベースのウォレットを介して支払いを送信できます。
+- **暗号通貨チップ**: このプラットフォームは**[Ethereumによるチップ機能](https://help.x.com/en/using-x/tips)**を統合しており、ユーザーはStrikeなどのEthereumベースのウォレットを介して支払いを送信できます。
ブロックチェーン機能を統合することで、XはWeb2のソーシャル体験と分散型のデジタル所有権との間のギャップを埋めています。
diff --git a/public/content/translations/ja/whitepaper/index.md b/public/content/translations/ja/whitepaper/index.md
index 0d228e9ee50..27bd49e466a 100644
--- a/public/content/translations/ja/whitepaper/index.md
+++ b/public/content/translations/ja/whitepaper/index.md
@@ -33,7 +33,7 @@ _数年前のものですが、これはEthereumとそのビジョンに関す
技術的な観点から見ると、ビットコインなどの暗号通貨のレジャーは状態遷移システムと捉えることができ、このシステムは既存のすべてのビットコインの所有権ステータスで構成される「状態(ステート)」と、前の状態とトランザクションから新しい状態を出力する「状態遷移関数」からなっています。 通常の銀行システムでは、例えば状態とは貸借対照表です。トランザクションとはAからBへ$Xを移す要求であり、状態遷移関数はAの口座から$Xを減らし、Bの口座に$Xを加えます。 もしAの口座が初めから$X未満であれば、状態遷移関数はエラーを返します。 したがって正式には次のような定義となります。
```
-APPLY(S,TX) -> S' または ERROR
+APPLY(S,TX) -> S' or ERROR
```
上述定義に基づく銀行システム:
diff --git a/public/content/translations/ja/wrapped-eth/index.md b/public/content/translations/ja/wrapped-eth/index.md
index 44bf23428b7..21a8f1ab2fb 100644
--- a/public/content/translations/ja/wrapped-eth/index.md
+++ b/public/content/translations/ja/wrapped-eth/index.md
@@ -11,7 +11,7 @@ lang: ja
[WrapETH.com](https://www.wrapeth.com/)であらゆるチェーンでETHをラップまたはアンラップするためにウォレットを接続
-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が必要なので、預ける際には一部を残しておくようにしましょう。
diff --git a/public/content/translations/ja/zero-knowledge-proofs/index.md b/public/content/translations/ja/zero-knowledge-proofs/index.md
index 97fe59e0f45..f0dbbb3e3a4 100644
--- a/public/content/translations/ja/zero-knowledge-proofs/index.md
+++ b/public/content/translations/ja/zero-knowledge-proofs/index.md
@@ -65,7 +65,7 @@ lang: ja
### 人間性の証明 {#proof-of-humanity}
-現在、実用化されているゼロ知識証明の最も広く使われている例の1つは、[World IDプロトコル](https://world.org/blog/world/world-id-faqs)です。これは、「AI時代のグローバルなデジタルパスポート」と考えることができます。 この仕組みにより、人々は個人情報を開示することなく、自分が唯一の個人であることを証明することができます。 これは「Orb」と呼ばれるデバイスを通じて実現されています。Orbは人の虹彩をスキャンし、そこから虹彩コードを生成します。 虹彩コードは照合・検証され、その人が生物学的に唯一の人間であることを確認します。 検証が完了すると、ユーザーのデバイス上で生成された「アイデンティティ・コミットメント」がブロックチェーン上の安全なリストに追加されます。このコミットメントは生体データとはリンクも派生もしていないため、プライバシーを保護しながら本人確認を行うことができます。 その後、ユーザーがログインや投票などの行動を行う際に、自分が認証済みの人間であることを証明したい場合には、リストへの登録を確認するゼロ知識証明を生成することができます。この証明により、ユーザーは自らの身元や個人情報を明かすことなく、確かに認証された人間であることを安全に示すことができます。 ゼロ知識証明を利用する優れた点は、たった一つの事実──「この人は唯一無二の存在である」──だけが明らかにされるということです。 それ以外のすべての情報は\*\*非公開のまま保護されます。
+現在、実用化されているゼロ知識証明の最も広く使われている例の1つは、[World IDプロトコル](https://world.org/blog/world/world-id-faqs)です。これは、「AI時代のグローバルなデジタルパスポート」と考えることができます。 この仕組みにより、人々は個人情報を開示することなく、自分が唯一の個人であることを証明することができます。 これは「Orb」と呼ばれるデバイスを通じて実現されています。Orbは人の虹彩をスキャンし、そこから虹彩コードを生成します。 虹彩コードは照合・検証され、その人が生物学的に唯一の人間であることを確認します。 検証が完了すると、ユーザーのデバイス上で生成された「アイデンティティ・コミットメント」がブロックチェーン上の安全なリストに追加されます。このコミットメントは生体データとはリンクも派生もしていないため、プライバシーを保護しながら本人確認を行うことができます。 その後、ユーザーがログインや投票などの行動を行う際に、自分が認証済みの人間であることを証明したい場合には、リストへの登録を確認するゼロ知識証明を生成することができます。この証明により、ユーザーは自らの身元や個人情報を明かすことなく、確かに認証された人間であることを安全に示すことができます。 ゼロ知識証明を利用する優れた点は、たった一つの事実──「この人は唯一無二の存在である」──だけが明らかにされるということです。 それ以外のすべての情報は**非公開のまま保護されます。
World IDは、イーサリアム・ファウンデーションの[PSEチーム](https://pse.dev/)によって開発された[Semaphoreプロトコル](https://docs.semaphore.pse.dev/)を利用しています。 Semaphoreは、軽量でありながら強力なゼロ知識証明の生成および検証を行うための仕組みとして設計されています。 Semaphoreは、ユーザーが自分が特定のグループ（この場合は認証済みの人間）に属していることを証明できるようにします。ただし、グループ内のどのメンバーであるかまでは明かさないようになっています。 Semaphoreは非常に柔軟性が高く、本人確認・イベントへの参加・資格情報の保有など、さまざまな基準に基づいてグループを作成することが可能です。
diff --git a/src/intl/ja/glossary.json b/src/intl/ja/glossary.json
index c9d17c7725d..5a605b36da6 100644
--- a/src/intl/ja/glossary.json
+++ b/src/intl/ja/glossary.json
@@ -403,6 +403,6 @@
"zero-address-definition": "全てがゼロで構成されたイーサリアムアドレスです。流通からトークンを削除するのに頻繁に使用されます。burn()メソッドを介してスマートコントラクトのインデックスから正式に削除されたトークンとゼロアドレスに送ったトークンは区別されます。",
"zk-proof-term": "ゼロ知識証明",
"zk-proof-definition": "ゼロ知識証明とは、ある主張が真であることを、追加の情報を伝えることなく証明することができる暗号論的メソッドです。ゼロ知識証明の詳細をご覧ください。",
- "zk-rollup-term": "ゼロ知識糾合",
+ "zk-rollup-term": "ゼロ知識ロールアップ",
"zk-rollup-definition": "トランザクションに有効性証明を使うロールアップです。これにより、メインネット(レイヤー1)によって提供されるセキュリティを使いながら、レイヤー2のトランザクションにおけるスループットを増やすことが出来ます。オプティミスティック・ロールアップのような複雑なトランザクションタイプを扱うことは出来ないものの、トランザクションの送信時に有効であることが証明されるため、遅延に関する問題がありません。 詳細はゼロ知識ロールアップをご覧ください。"
}
diff --git a/src/intl/ja/page-10-year-anniversary.json b/src/intl/ja/page-10-year-anniversary.json
index 95ac3e1cb51..dbd29d4c6ee 100644
--- a/src/intl/ja/page-10-year-anniversary.json
+++ b/src/intl/ja/page-10-year-anniversary.json
@@ -17,7 +17,7 @@
"page-10-year-hero-title": "一度に1ブロックずつ世界を変えてきた10年",
"page-10-year-hero-description": "2015年7月30日、イーサリアムブロックチェーンが誕生しました。始まりのブロックがマイニングされた瞬間、インターネットに新たな可能性がもたらされ、金融、所有権、プログラマビリティに革新的な変化をもたらしました。",
"page-10-year-hero-tagline": "10年を経て、永遠の先へ。",
- "page-10-year-join-party-title": "パーティーに参加しろ",
+ "page-10-year-join-party-title": "パーティーに参加しよう",
"page-10-year-join-party-description": "グローバルコミュニティと共にイーサリアムの10周年を祝いましょう。地域のイベントを探したり、自分たちでお祝いを企画したりできます。",
"page-10-year-events-description-1": "イーサリアムの10周年を記念して、世界中の人々と一緒にトーク、ネットワーキング、お祝いに参加しましょう。",
"page-10-year-events-description-2": "直接参加できませんか？ライブストリームを視聴し、世界中のイベントのアップデートをフォローして、誰もがこのマイルストーンを一緒にお祝いできるようにしましょう。",
@@ -54,7 +54,7 @@
"page-10-year-banner-header": "イーサリアムの10年",
"page-10-year-banner-launch-text": "2015年7月30日午後3時44分（協定世界時）、イーサリアムブロックチェーンの最初のブロックが誕生しました。",
"page-10-year-banner-tagline": "10年を経て、無限の先へ！🚀",
- "page-10-year-banner-cta": "パーティーに参加しろ",
+ "page-10-year-banner-cta": "パーティーに参加しよう",
"page-10-year-stories-read-more": "続きを読む",
"page-10-year-stories-show-original": "原文を表示",
"page-10-year-stories-show-english": "英語を表示",
diff --git a/src/intl/ja/page-community-events.json b/src/intl/ja/page-community-events.json
index 86a18dd5c9d..968e23c8aa5 100644
--- a/src/intl/ja/page-community-events.json
+++ b/src/intl/ja/page-community-events.json
@@ -72,7 +72,7 @@
"page-events-no-upcoming": "現時点で開催予定のイベントはありません",
"page-events-tag-online": "オンライン",
"page-events-tag-conference": "カンファレンス",
- "page-events-tag-hackathon": "ハッカソン画像",
+ "page-events-tag-hackathon": "ハッカソン",
"page-events-tag-meetup": "ミートアップ",
"page-events-tag-popup": "ポップアップ",
"page-events-tag-group": "グループ",
diff --git a/src/intl/ja/page-developers-docs.json b/src/intl/ja/page-developers-docs.json
index 852dd90ee1d..616caf22880 100644
--- a/src/intl/ja/page-developers-docs.json
+++ b/src/intl/ja/page-developers-docs.json
@@ -79,7 +79,7 @@
"docs-nav-bootnodes": "ブートノード",
"docs-nav-light-clients": "ライトクライアント",
"docs-nav-nodes-as-a-service": "サービスとしてのノード",
- "docs-nav-oracles": "神託",
+ "docs-nav-oracles": "オラクル",
"docs-nav-oracles-description": "イーサリアムブロックチェーンに情報がどのように組み込まれるか",
"docs-nav-programming-languages": "プログラミング言語",
"docs-nav-programming-languages-description": "既に知っている言語でイーサリアムを使い始める方法",
diff --git a/src/intl/ja/page-layer-2.json b/src/intl/ja/page-layer-2.json
index 49965877166..2ae98a37019 100644
--- a/src/intl/ja/page-layer-2.json
+++ b/src/intl/ja/page-layer-2.json
@@ -40,7 +40,7 @@
"page-layer-2-faq-ExpandableCard-3-title": "なぜイーサリアムは、これらのネットワークに依存するのではなく、自身のチェーンをスケールできないのでしょうか？",
"page-layer-2-faq-ExpandableCard-3-description": "イーサリアムは、安全性と分散化を維持する必要があるため、メインチェーン自体を簡単にスケールすることができません。メインチェーンを高速化すると、安全性が低下し、より中央集権的になる可能性があります。イーサリアムネットワークは、メインチェーンの外で取引を処理し、その後メインチェーンをセキュリティに利用することで支援し、イーサリアムが安全性や分散化を失うことなく、より多くの取引を処理できるようにします。",
"page-layer-2-faq-ExpandableCard-4-title": "なぜ「公式」イーサリアムネットワークが存在しないのでしょうか？",
- "page-layer-2-faq-ExpandableCard-4-description": "「公式の」イーサリアムクライアントが存在しないように、「公式」イーサリアムレイヤー2もありません。イーサリアムはパーミッションレスであり、技術的には誰でもレイヤー2を作成することができます。複数のチームがそれぞれのバージョンのレイヤー2を実装し、エコシステム全体として、異なるユースケースに最適化された多様な設計アプローチからメリットを得ることができます。ネットワークに多様性を持たせるために、複数のチームが開発した複イーサリアムクライアントが複数あるように、これもまた今後にレイヤー2がどのように発展するかということになるでしょう。",
+ "page-layer-2-faq-ExpandableCard-4-description": "「公式の」イーサリアムクライアントが存在しないように、「公式」イーサリアムレイヤー2もありません。イーサリアムはパーミッションレスであり、技術的には誰でもレイヤー2を作成することができます。複数のチームがそれぞれのバージョンのレイヤー2を実装し、エコシステム全体として、異なるユースケースに最適化された多様な設計アプローチからメリットを得ることができます。ネットワークに多様性を持たせるために、複数のチームが開発した複数のイーサリアムクライアントが複数あるように、これもまた今後にレイヤー2がどのように発展するかということになるでしょう。",
"page-layer-2-callout-1-title": "様々なネットワークを探索する",
"page-layer-2-callout-1-description": "ネットワーク同士がどのように異なり、開発においてどの程度まで進展しているかを学びましょう。",
"page-layer-2-callout-2-title": "より詳しい情報にご興味がありますか？",
diff --git a/src/intl/ja/page-roadmap.json b/src/intl/ja/page-roadmap.json
index 15827b3396e..64c44899beb 100644
--- a/src/intl/ja/page-roadmap.json
+++ b/src/intl/ja/page-roadmap.json
@@ -6,7 +6,7 @@
"page-roadmap-changes-coming-title": "イーサリアムで予定されている変更点は何ですか？",
"page-roadmap-changes-coming-description": "イーサリアムは、すでにグローバルで協調して稼働している強力なプラットフォームですが、さらなる改善が進められています。大胆な改善案が提案されており、イーサリアムは現在の形から、フルスケールで最大の復元力を備えたプラットフォームへとアップグレードされる予定です。",
"page-roadmap-cheaper-transactions-title": "より安価なトランザクション",
- "page-roadmap-cheaper-transactions-description": "ロールアップはコストが高すぎ、かつ中央集権的なコンポーネントに依存しているため、ユーザーはオペレーターを過度に信頼するこのになります。このロードマップにはこれら両方の問題の解決策が含まれています。",
+ "page-roadmap-cheaper-transactions-description": "ロールアップはコストが高すぎ、かつ中央集権的なコンポーネントに依存しているため、ユーザーはオペレーターを過度に信頼することになります。このロードマップにはこれら両方の問題の解決策が含まれています。",
"page-roadmap-cheaper-transactions-button": "手数料の削減の詳細",
"page-roadmap-extra-security-title": "追加のセキュリティ",
"page-roadmap-extra-security-description": "イーサリアムはすでに非常に安全ですが、将来にわたってあらゆる種類の攻撃に耐えれるよう、より強力にすることができます。",
@@ -27,7 +27,7 @@
"page-roadmap-hero-alt": "イーサリアムロードマップ",
"page-roadmap-technical-upgrades-title": "イーサリアムにはどのような技術的アップグレードが予定されていますか？",
"page-roadmap-danksharding-title": "ダンクシャーディング",
- "page-roadmap-danksharding-description": "ダンクシャーディングは、イーサリアムのブロックにデータの「ブロブ」を追加することで、L2ロールアップをユーザーにとってはるかに安価にします。ダンクシャーディングは、イーサリアムのブロックにデータの「ブロブ」を追加することで、L2ロールアップをユーザーにとってはるかに安価にします。",
+ "page-roadmap-danksharding-description": "ダンクシャーディングは、イーサリアムのブロックにデータの「ブロブ」を追加することで、L2ロールアップをユーザーにとってはるかに安価にします。",
"page-roadmap-single-slot-finality-title": "シングルスロット・ファイナリティ",
"page-roadmap-single-slot-finality-description": "待機時間を15分取る代わりに、ブロックを同じスロット内で提案し、最終確定することができます。これはアプリケーションにとってより便利であり、攻撃を仕掛けるのも難しくなります。",
"page-roadmap-account-abstraction-title": "アカウント抽象化",
From 785f4b6d9c087eb08dbc707b27bd773982e1c595 Mon Sep 17 00:00:00 2001
From: myelinated-wackerow
<263208946+myelinated-wackerow@users.noreply.github.com>
Date: Tue, 24 Feb 2026 06:07:12 +0000
Subject: [PATCH 14/14] docs: add ja quality scoring review report
Documents the parallel 13-agent quality scoring review of all
306 Japanese translation files (4.89/5.0), covering 6 critical
fixes, systematic issue patterns, edge cases learned, and
prevention strategies for future imports.
Co-Authored-By: Claude Opus 4.6
Co-Authored-By: wackerow <54227730+wackerow@users.noreply.github.com>
---
...ion-quality-review-fix-process-pr-17132.md | 313 ++++++++++++++++++
1 file changed, 313 insertions(+)
create mode 100644 docs/solutions/translation-review/japanese-translation-quality-review-fix-process-pr-17132.md
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