`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..8ffbf3f879d 100644
--- a/public/content/translations/ja/dao/index.md
+++ b/public/content/translations/ja/dao/index.md
@@ -1,15 +1,16 @@
---
-title: 分散型自律組織(DAO)
-description: イーサリアムにおける分散型自律組織(DAO)の概要
+title: "DAOとは何ですか?"
+metaTitle: "DAOとは何ですか? | 分散型自律組織"
+description: "イーサリアムにおける分散型自律組織(DAO)の概要"
lang: ja
template: use-cases
emoji: ":handshake:"
sidebarDepth: 2
image: /images/use-cases/dao-2.png
-alt: 提案に対する分散型自律組織(DAO)投票
-summaryPoint1: 中央集権的な制御がない、メンバー所有のコミュニティ
-summaryPoint2: インターネットの見知らぬ人と協力する安全な方法
-summaryPoint3: 特定の目的に資金を委ねるのに安全な場所
+alt: "提案に対する分散型自律組織(DAO)投票"
+summaryPoint1: "中央集権的な制御がない、メンバー所有のコミュニティ"
+summaryPoint2: "インターネットの見知らぬ人と協力する安全な方法"
+summaryPoint3: "特定の目的に資金を委ねるのに安全な場所"
---
## 自律分散組織(DAO)とは {#what-are-daos}
@@ -18,41 +19,41 @@ DAOは、共通の目的のために行動する、集団所有された組織
分散型自律組織(DAO)は資金や運営の管理において、誰かを信用することなく、世界中の同じ志を持つ人々と共に働くことを可能します。 気まぐれに資金を使い込むCEOはいませんし、帳簿を操作できるCFOもいません。 誰かを依存・信用するのではなく、ブロックチェーンベースのルールがコード化され、組織の運営や資金の使われ方を定義しています。
-グループの承認なしには誰もアクセスできない資金が組み込まれています。 意思決定は、提案と投票によって行われ、組織内の誰しもが発言権を持つことが保障されています。また、全て[オンチェーン](/glossary/#on-chain)で行われるため、透明性も確保されています。
+グループの承認なしには誰もアクセスできない資金が組み込まれています。 決定は提案と投票によって管理され、組織内の全員が発言権を持ち、すべてが透明に[オンチェーン](/glossary/#onchain)で行われることが保証されています。
## 分散型自律組織(DAO)が必要な理由 {#why-dao}
-組織を誰かと一緒に組織を立ち上げるには、資金やお金が関わるため、相手との信頼関係が必要になります。 しかし、インターネット上でしか交流のない人を信用するのは難しいと思います。 分散型自律組織(DAO)では、グループ内の他の誰かを信用する必要はなく、100%透明で誰でも検証可能なコードだけを信用すれば大丈夫です。
+資金や金銭が関わる組織を誰かと一緒に立ち上げるには、一緒に働く人々との間に多くの信頼が必要になります。 しかし、インターネット上でしか交流のない人を信用するのは難しいと思います。 分散型自律組織(DAO)では、グループ内の他の誰かを信用する必要はなく、100%透明で誰でも検証可能なコードだけを信用すれば大丈夫です。
これにより、グローバルなコラボレーションやコーディネーションに新たな可能性が広がりました。
### 比較 {#dao-comparison}
-| 分散型自律組織(DAO) | 従来の組織 |
-| ----------------------------------------- | ----------------------------------------------- |
-| 通常はフラットな組織で、完全に民主化 | 通常は階層的 |
-| 変更を実行するには、メンバーによる投票が必要 | 組織構造によっては、単独の当事者から変更が要求されることがあり、または投票が行われる場合がある |
-| 投票は集計され、結果は信頼できる仲介者なしに自動的に実行される | 投票が可能な場合、投票は内部で集計され、投票結果は手動での処理が必要 |
+| 自律分散型組織 | 従来の組織 |
+| ------------------------------------------------------------ | ----------------------------------------------- |
+| 通常はフラットな組織で、完全に民主化 | 通常は階層的 |
+| 変更を実行するには、メンバーによる投票が必要 | 組織構造によっては、単独の当事者から変更が要求されることがあり、または投票が行われる場合がある |
+| 投票は集計され、結果は信頼できる仲介者なしに自動的に実行される | 投票が可能な場合、投票は内部で集計され、投票結果は手動での処理が必要 |
| 提供されるサービスは、自動的に分散化された方法で処理される(例えば慈善資金の分配) | 人間による処理、または集中管理された自動化を必要とし、改ざんされるおそれがある |
-| すべてのアクティビティは透明で完全に公開 | 通常、アクティビティは非公開で、一般には非公開 |
+| すべてのアクティビティは透明で完全に公開 | 通常、アクティビティは非公開で、一般には非公開 |
-### 分散型自律組織(DAO)の事例 {#dao-examples}
+### DAOの例 {#dao-examples}
もう少し理解を深められるように、分散型自律組織(DAO)の使用方法についていくつか例をご紹介します。
- **慈善事業** – 世界中の誰からでも寄付を受け付け、資金の使い道を投票にて決定可能。
-- **共同所有**– 物理的またはデジタル資産を購入し、メンバーは資産の活用方法について投票できる。
-- **ベンチャーキャピタルと助成金** - 投資資金をプールし、投票により支援先ベンチャーを選択する、ベンチャーファンドを作成可能。 返済金は後に分散型自律組織(DAO)のメンバー間で再配分できる。
+- **共同所有** – 物理的またはデジタル資産を購入し、メンバーは資産の活用方法について投票できる。
+- **ベンチャーキャピタルと助成** – 投資資金をプールし、投票により支援先ベンチャーを選択、ベンチャーファンドを作成可能。 返済金は後に分散型自律組織(DAO)のメンバー間で再配分できる。
## 分散型自律組織(DAO)の仕組み {#how-daos-work}
-組織のルールを定義し、その組織の資産を保持している[スマートコントラクト](/glossary/#smart-contract)が、分散型自律組織(DAO) のバックボーンです。 このスマートコントラクトがイーサリアム上で稼働し始めると、投票以外では誰もルールを変更できません。 もし誰かがコードのルールやロジックでカバーされていないことを試みても失敗に終わります。 また、資産はスマートコントラクトによって定義されているため、グループの承認なしには誰も組織の資金を使うことができません。 つまり、分散型自律組織(DAO)は中央集権を必要とせず、 グループが集合的に決定を下し、投票が可決されると支払いが自動的に承認されます。
+DAOのバックボーンは、組織のルールを定義し、グループの財源を保持する[スマートコントラクト](/glossary/#smart-contract)です。 このスマートコントラクトがイーサリアム上で稼働し始めると、投票以外では誰もルールを変更できません。 もし誰かがコードのルールやロジックでカバーされていないことを試みても失敗に終わります。 また、資産はスマートコントラクトによって定義されているため、グループの承認なしには誰も組織の資金を使うことができません。 つまり、分散型自律組織(DAO)は中央集権を必要とせず、 グループが集合的に決定を下し、投票が可決されると支払いが自動的に承認されます。
これが可能なのは、スマートコントラクトがイーサリアム上で稼働すると、改ざんができないためです。 すべてが公開されているので、コード(分散型自律組織のルール)を誰にも気づかれずに、変更することはできません。
-## イーサリアムと分散型自律組織(DAO) {#ethereum-and-daos}
+## イーサリアムとDAO {#ethereum-and-daos}
イーサリアムは、次の理由から分散型自律組織(DAO)の完璧な基盤となります。
@@ -61,105 +62,105 @@ DAOは、共通の目的のために行動する、集団所有された組織
- スマートコントラクトは、資金の送受信が可能。 これができないと、グループ資金を管理する信頼できる仲介者が必要となる。
- イーサリアムのコミュニティは、競争的なものではなく、むしろ協調的であることが証明されており、最善の方法やサポートシステムが迅速に生みだされている。
-## 分散型自律組織(DAO)ガバナンス {#dao-governance}
+## DAOのガバナンス {#dao-governance}
分散型自律組織(DAO)のガバナンスには、投票や提案の仕組みなど様々な考慮事項があります。
-### デリゲーション(委任) {#governance-delegation}
+### 委任 {#governance-delegation}
デリゲーション(委任)とは、分散型自律組織版の議会制民主主義のようなものです。 トークン保有者は、プロトコルを管理し、最新情報を入手することにコミットする立候補者に投票権を委任します。
-#### 有名な事例 {#governance-example}
+#### 有名な例 {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – ENS保有者は、自分たちの代表として、熱心なコミュニティメンバーに投票を委任できます。
-[ENS](https://claim.ens.domains/delegate-ranking) – ENS保有者は、自分たちの代表として、コミュニティメンバーに投票を委任できます。
-
-### 自動トランザクションガバナンス {#governance-example}
+### 自動取引ガバナンス {#governance-example}
多くの分散型自律組織(DAO)では、メンバーの賛成票が定足数を満たせば自動的にトランザクションが実行されます。
-#### 有名な事例 {#governance-example}
+#### 有名な例 {#governance-example}
[Nouns](https://nouns.wtf) – Nouns DAOでは、定足数を満たし、過半数が賛成票であれば、創設者が拒否権を行使しない限り、トランザクションは自動的に実行されます。
-### マルチシグガバナンス {#governance-example}
+### マルチシグ・ガバナンス {#governance-example}
-分散型自律組織(DAO)には投票権のあるメンバーが何千人も在籍するかもしれませんが、資金は5~20人のアクティブなメンバーが共有する[ウォレット](/glossary/#wallet)に保有されている場合があります。これらのメンバーは信用されており、通常は個人情報が公開されています(コミュニティに公的な身元が公開)。 投票の結果をもって、[マルチシグ](/glossary/#multisig)の署名者はコミュニティの意思を実施します。
+DAOには何千人もの投票メンバーがいる場合がありますが、資金は信頼され、通常はdoxxed(コミュニティに身元が公開されている)状態の5~20人のアクティブなコミュニティメンバーが共有する[ウォレット](/glossary/#wallet)に存在することがあります。 投票後、[multisig](/glossary/#multisig)署名者はコミュニティの意思を実行します。
-## 分散型自律組織(DAO)法 {#dao-laws}
+## DAOの法律 {#dao-laws}
1977年にワイオミング州は、起業家を保護し、責任を有限にする合同会社(LLC)を制定しました。 近年では、ワイオミング州は分散型自律組織(DAO)の法的地位を確立する法律を制定し、パイオニアとなっています。 現在、ワイオミング州、バーモント州、ヴァージン諸島に、何らかの形の分散型自律組織(DAO)法があります。
-### 有名な事例 {#law-example}
+### 有名な例 {#law-example}
-[CityDAO](https://citizen.citydao.io/) – CityDAOは、ワイオミング州の分散型自律組織(DAO)法を利用して、イエローストーン国立公園近くの40エーカーの土地を購入しました。
+[CityDAO](https://citizen.citydao.io/) – CityDAOはワイオミング州のDAO法を利用して、イエローストーン国立公園の近くにある40エーカーの土地を購入しました。
-## 分散型自律組織(DAO)のメンバーシップ {#dao-membership}
+## DAOのメンバーシップ {#dao-membership}
分散型自律組織(DAO)のメンバーシップにはいくつかのモデルがあります。 メンバーシップにより、投票の仕組みやDAOの他の重要な部分を決定することができます。
### トークンベースのメンバーシップ {#token-based-membership}
-使用されるトークンにもよりますが、通常は完全に[パーミッションレス](/glossary/#permissionless)です。 ほとんどの場合、これらのガバナンストークンは、[分散型取引所](/glossary/#dex)でパーミッションレスで取引できます。 それ以外のトークンは、流動性もしくはその他の「プルーフ・オブ・ワーク」を提供することで獲得する必要があります。 いずれにせよ、トークンの保持により投票権が付与されます。
+使用されるトークンによりますが、通常は完全に[パーミッションレス](/glossary/#permissionless)です。 ほとんどの場合、これらのガバナンストークンは、[分散型取引所](/glossary/#dex)でパーミッションレスに取引できます。 それ以外のトークンは、流動性もしくはその他の「プルーフ・オブ・ワーク」を提供することで獲得する必要があります。 いずれにせよ、トークンの保持により投票権が付与されます。
_一般的には、広範な分散型プロトコルやトークン自体を管理するために使用されます。_
-#### 有名な事例 {#token-example}
+#### 有名な例 {#token-example}
[MakerDAO](https://makerdao.com) – MakerDAOのトークンであるMKRは分散型取引所で広く入手可能で、購入することにより、誰でもMakerプロトコルの将来についての投票権を得ることができます。
-### シェアベースのメンバーシップ {#share-based-membership}
+### 株式ベースのメンバーシップ {#share-based-membership}
シェアベースの分散型自律組織(DAO)は、よりパーミッション型ではありますが、かなりオープンです。 分散型自律組織(DAO)への参加希望者は、トークンや作品といった何らかの価値のある物を提供することで、自分自身の参加を提案します。 シェアは、直接投票権と所有権を表します。 メンバーはいつでも、自分の保有する資産の持分を持って退会できます。
-_一般的には、慈善団体やワーカーズ・コレクティブ、投資クラブなど、より密接な関係を持つ人間が中心となる組織に使われています。 また、プロトコルやトークンも管理できます。_
+_一般的には、慈善団体やワーカーズ・コレクティブ、投資クラブなど、より密接な関係を持つ人間が中心となる組織に使われています。_ _また、プロトコルやトークンも管理できます。_
-#### 有名な事例 {#share-example}
+#### 有名な例 {#share-example}
-[MolochDAO](http://molochdao.com/) - MolochDAOは主にイーサリアムプロジェクトの資金調達を行っています。 メンバーになるには、提案が必要となります。この提案によって、あなたが助成先候補に関して、十分な情報に基づいて判断できるだけの必要な専門知識と資本を持っているかどうかが評価されます。 オープン市場で権利を購入するだけでは、この分散型自律組織(DAO)に参加することはできません。
+[MolochDAO](http://molochdao.com/) – MolochDAOは、イーサリアムプロジェクトへの資金提供に重点を置いています。 メンバーになるには、提案が必要となります。この提案によって、あなたが助成先候補に関して、十分な情報に基づいて判断できるだけの必要な専門知識と資本を持っているかどうかが評価されます。 オープン市場で権利を購入するだけでは、この分散型自律組織(DAO)に参加することはできません。
-### レピュテーション(評価・評判)ベースのメンバーシップ {#reputation-based-membership}
+### 評判ベースのメンバーシップ {#reputation-based-membership}
-レピュテーション(評価・評判)とは、分散型自律組織(DAO)における参加証明と投票権の付与を表します。 トークンやシェアベースのメンバーシップとは異なり、レピュテーションベースの分散型自律組織(DAO)は所有権をコントリビューターに譲渡しません。 レピュテーションは購入、移管、または委任できず、分散型自律組織メンバーは参加を通じてレピュテーションを構築する必要があります。 オンチェーン投票はパーミッションレスで、メンバー候補は分散型自律組織(DAO)への参加を自由に提案でき、貢献の対価としてレピュテーションやトークンを受け取ることを要求することができます。
+レピュテーション(評価・評判)とは、分散型自律組織(DAO)における参加証明と投票権の付与を表します。 トークンやシェアベースのメンバーシップとは異なり、レピュテーションベースの分散型自律組織(DAO)は所有権をコントリビューターに譲渡しません。 レピュテーションは購入、移管、または委任できず、分散型自律組織メンバーは参加を通じてレピュテーションを構築する必要があります。 オンチェーン投票は許可不要で、将来のメンバーは自由にDAOへの参加提案を提出し、貢献の対価として報酬として評判とトークンを受け取ることを要求できます。
-_主にプロトコルや[分散型アプリ(Dapp)](/glossary/#dapp)の分散型開発や分散型ガバナンスに利用されていますが、慈善団体、ワーカーズ・コレクティブ、投資クラブなど、多様な組織にも向いています。_
+_主にプロトコルや[dapps](/glossary/#dapp)の分散型開発とガバナンスに利用されますが、慈善団体、ワーカーズコレクティブ、投資クラブといった多様な組織にもよく適しています。_
-#### 有名な事例 {#reputation-example}
+#### 有名な例 {#reputation-example}
-[DXdao](https://DXdao.eth.limo) - DXdaoは、2019年から分散型プロトコルやアプリケーションを構築し統治するグローバル・ソブリン団体でした。 レピュテーションに基づくガバナンスと[ホログラフィック・コンセンサス](/glossary/#holographic-consensus)を活用して資金を調整・管理することで、誰かが金銭的な手段を使って、DXdaoの今後に影響をおよぼしたり、支配したりすることはできませんでした。
+[DXdao](https://DXdao.eth.limo) – DXdaoは、2019年から分散型プロトコルやアプリケーションを構築・管理する、世界的な主権を持つコレクティブでした。 評判に基づくガバナンスと[ホログラフィック・コンセンサス](/glossary/#holographic-consensus)を活用して資金を調整・管理することで、誰も金銭的な手段を使ってその将来やガバナンスに影響を及ぼすことはできませんでした。
-## DAOに参加する/DAOを立ち上げる {#join-start-a-dao}
+## DAOへの参加/DAOの設立 {#join-start-a-dao}
-### 分散型自律組織(DAO)への参加 {#join-a-dao}
+### DAOに参加する {#join-a-dao}
-- [イーサリアムコミュニティ分散型自律組織(DAO)](/community/get-involved/#decentralized-autonomous-organizations-daos)
-- [DAOHausの分散型自律組織(DAO)リスト](https://app.daohaus.club/explore)
-- [Tally.xyzの分散型自律組織(DAO)リスト](https://www.tally.xyz)
+- [イーサリアムコミュニティのDAO](/community/get-involved/#decentralized-autonomous-organizations-daos)
+- [DAOHausのDAOリスト](https://app.daohaus.club/explore)
+- [Tally.xyzのDAOリスト](https://www.tally.xyz/explore)
+- [DeGov.AIのDAOリスト](https://apps.degov.ai/)
-### 分散型自律組織(DAO)を始める {#start-a-dao}
+### DAOを始める {#start-a-dao}
-- [DAOHausで分散型自律組織(DAO)を招集](https://app.daohaus.club/summon)
-- [TallyでGovernor DAOを始める](https://www.tally.xyz/add-a-dao)
-- [Aragonによる分散型自律組織(DAO)を作成](https://aragon.org/product)
+- [DAOHausでDAOを召喚する](https://app.daohaus.club/summon)
+- [TallyでGovernor DAOを始める](https://www.tally.xyz/get-started)
+- [Aragonを利用してDAOを作成する](https://aragon.org/product)
- [コロニーを始める](https://colony.io/)
-- [DAOstackのホログラフィック・コンセンサスでDAOを作成](https://alchemy.daostack.io/daos/create)
+- [DAOstackのホログラフィック・コンセンサスでDAOを作成する](https://alchemy.daostack.io/daos/create)
+- [DeGov LauncherでDAOを立ち上げる](https://docs.degov.ai/integration/deploy)
-## 参考文献 {#further-reading}
+## 参考リンク {#further-reading}
-### 分散型自律組織(DAO)の関連記事 {#dao-articles}
+### DAO関連の記事 {#dao-articles}
-- [分散型自律組織(DAO)とは](https://aragon.org/dao) – [Aragon](https://aragon.org/)
-- [分散型自律組織(DAO)](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
-- [分散型自律組織(DAO)とは、およびその目的](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
-- [分散型自律組織(DAO)のデジタルコミュニティの作成方法](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
-- [分散型自律組織(DAO)とは](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
-- [ホログラフィック・コンセンサスとは](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
-- [分散型自律組織(DAO)とは企業ではなく、分散型の自律組織 – Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html)
-- [分散型自律組織(DAO)、分散型自律企業(DAC)、分散型アプリケーション(DA)など: 不完全な用語集](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [イーサリアムブログ](https://blog.ethereum.org)
+- [DAOとは?](https://aragon.org/dao) – [Aragon](https://aragon.org/)
+- [House of DAOs](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
+- [DAOとは何か、何のためのものか?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
+- [DAOを活用したデジタルコミュニティの始め方](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
+- [DAOとは?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
+- [ホログラフィック・コンセンサスとは?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
+- [DAOは企業ではない:自律的組織における分散化の重要性 (ヴィタリック筆)](https://vitalik.eth.limo/general/2022/09/20/daos.html)
+- [DAO、DAC、DAなど:不完全な用語ガイド](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [イーサリアムブログ](https://blog.ethereum.org)
-### ビデオ {#videos}
+### 動画 {#videos}
-- [仮想通貨における分散型自律組織(DAO)とは](https://youtu.be/KHm0uUPqmVE)
-- [分散型自律組織(DAO)で街はつくれるのか?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/)
+- [暗号資産におけるDAOとは?](https://youtu.be/KHm0uUPqmVE)
+- [DAOは都市を建設できるか?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/)
diff --git a/public/content/translations/ja/decentralized-identity/index.md b/public/content/translations/ja/decentralized-identity/index.md
index 9818baaf876..12f60ee812f 100644
--- a/public/content/translations/ja/decentralized-identity/index.md
+++ b/public/content/translations/ja/decentralized-identity/index.md
@@ -1,25 +1,25 @@
---
-title: 分散型アイデンティティ
-description: 分散型アイデンティティとは、またこれが重要な理由
+title: "分散型アイデンティティ"
+description: "分散型アイデンティティとは、またこれが重要な理由"
lang: ja
template: use-cases
emoji: ":id:"
sidebarDepth: 2
image: /images/eth-gif-cat.png
-summaryPoint1: 身元を証明するIDは中央集権的に発行、更新、管理されてきた従来のアイデンティティ制度
-summaryPoint2: 分散型アイデンティティにより、中央集権的なサードパーティへの依存から脱却
-summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテステーションを発行、保持、管理することが可能
+summaryPoint1: "身元を証明するIDは中央集権的に発行、更新、管理されてきた従来のアイデンティティ制度"
+summaryPoint2: "分散型アイデンティティにより、中央集権的なサードパーティへの依存から脱却"
+summaryPoint3: "暗号技術により、今や再び自分自身のIDとアテステーションを発行、保持、管理することが可能"
---
身分を証明するアイデンティティは、今日の生活のほぼすべての側面の基盤となっています。 オンラインサービスの利用、銀行口座の開設、選挙での投票、不動産の購入、雇用の確保、これらすべてにおいて身分証明が必要です。
-しかし、従来の身分証明書管理システムは、IDと[アテステーション](/glossary/#attestation)を発行、保有、管理する中央管理型の仲介機関に長く依存してきました。 つまり、自分の身元証明に関する情報を自分自身で管理したり、誰が個人を特定できる情報(PII)にアクセスできるか、またこれらの機関がどのくらいアクセス権を持っているかを決めることはできないということです。
+しかし、従来のID管理システムは、IDと[アテステーション](/glossary/#attestation)を発行、保有、管理する中央集権型の仲介機関に長く依存してきました。 つまり、自分の身元証明に関する情報を自分自身で管理したり、誰が個人を特定できる情報(PII)にアクセスできるか、またこれらの機関がどのくらいアクセス権を持っているかを決めることはできないということです。
-こうした問題を解決するために、イーサリアムのようなパブリックブロックチェーン上に分散型アイデンティティシステムを構築しています。 分散型アイデンティティでは、自分の身元証明に関する情報を管理することができます。 サービスプロバイダーや政府などの中央機関に依存することなく、_自分自身で_身分証明を作成し、本人であるというアテステーションを主張・保持することができます。
+こうした問題を解決するために、イーサリアムのようなパブリックブロックチェーン上に分散型アイデンティティシステムを構築しています。 分散型アイデンティティでは、自分の身元証明に関する情報を管理することができます。 分散型IDソリューションを使えば、サービスプロバイダーや政府のような中央機関に頼ることなく、_あなた_がIDを作成し、自分のアテステーションを請求・保持できます。
## アイデンティティとは? {#what-is-identity}
-アイデンティティとは、自分が自分であるという自覚で、その人が誰であるかということを表す性質や特徴により定義されます。 アイデンティティとは、_個_であること、すなわち一人の確たる人間存在であることを意味します。 またアイデンティティは、組織や行政機関などのように人間ではない存在を指すこともあります。
+アイデンティティとは、自分が自分であるという自覚で、その人が誰であるかということを表す性質や特徴により定義されます。 「アイデンティティ」とは、_個人_であること、すなわち、個別の人間存在であることを指します。 またアイデンティティは、組織や行政機関などのように人間ではない存在を指すこともあります。
@@ -35,67 +35,93 @@ summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテス
上記のような例では、IDは中央機関や組織により発行、保持、管理されています。 氏名の変更には政府からの、ユーザー名の変更にはソーシャルメディアからの承認が必要です。
-## 分散型アイデンティティの利点 {#benefits-of-decentralized-identity}
+## 分散型IDのメリット {#benefits-of-decentralized-identity}
1. 分散型アイデンティティは、自分自身のID情報をより管理することができます。 中央集権機関やサードパーティのサービスに依存することなく、分散型IDとアテステーションを検証することができます。
-2. 分散型アイデンティティのソリューションは、信頼性が高く、シームレスで、プライバシーを保護しつつ、ユーザーのアイデンティティの検証と管理を容易にします。
+2. 分散型IDソリューションは、ユーザーのIDを検証・管理するための、信頼を必要としない (トラストレスな) 、シームレスでプライバシーを保護する方法を容易にします。
3. 分散型アイデンティティは、ブロックチェーン技術を活用し、異なる当事者間の信頼関係を構築し、暗号的にアテステーションの正当性を証明することができます。
-4. 分散型アイデンティティは、アイデンティティデータのポータブル化を実現します。 ユーザーは、アテステーションとIDをモバイルウォレットに保存し、任意の相手と共有することができます。 分散型IDとアテステーションは、発行組織のデータベースに保管されることはありません。
+4. 分散型アイデンティティは、アイデンティティデータのポータブル化を実現します。 ユーザーは、アテステーションとIDをモバイルウォレットに保存し、任意の相手と共有できます。 分散型IDとアテステーションは、発行組織のデータベースに保管されることはありません。
-5. 分散型アイデンティティは、新しい[ゼロ知識証明](/glossary/#zk-proof)技術とうまく機能すると考えられています。ゼロ知識証明とは、個人の所有または何かを行ったことを、それが何であるかを明かすことなく証明できるものです。 これは、投票などのアプリケーションでの応用において、信頼性とプライバシーを両立させる強力な方法となる可能性を秘めています。
+5. 分散型IDは、個人がそれが何であるかを明かすことなく、何かを所有している、あるいは何かを成し遂げたことを証明できる、新しい[ゼロ知識](/glossary/#zk-proof)技術とうまく連携するはずです。 これは、投票などのアプリケーションでの応用において、信頼性とプライバシーを両立させる強力な方法となる可能性を秘めています。
-6. 分散型アイデンティティは、[耐シビル](/glossary/#anti-sybil)メカニズムを実現するため、一人の人間が複数の人間になりすました操作やスパムを防ぐことができます。
+6. 分散型IDは、[アンチシビル](/glossary/#anti-sybil)メカニズムを可能にし、一個人がシステムを悪用したりスパム行為をしたりするために複数の人間になりすましているのを識別します。
-## 分散型アイデンティティのユースケース {#decentralized-identity-use-cases}
+## 分散型IDのユースケース {#decentralized-identity-use-cases}
分散型アイデンティティには、多くの潜在的なユースケースがあります。
### 1. ユニバーサルログイン {#universal-dapp-logins}
-分散型アイデンティティは、パスワードベースのログインを分散型認証に置き換えるのに役立ちます。 サービスプロバイダーは、アテステーションを発行することができ、ユーザーはそれをイーサリアムのウォレットに保存できます。 アテステーションの例としては、[非代替性トークン(NFT)](/glossary/#nft)保有者にオンラインコミュニティへのアクセスを許可することなどが挙げられます。
+分散型アイデンティティは、パスワードベースのログインを分散型認証に置き換えるのに役立ちます。 サービスプロバイダーは、アテステーションを発行することができ、ユーザーはそれをイーサリアムのウォレットに保存できます。 アテステーションの例として、保有者にオンラインコミュニティへのアクセスを許可する[NFT](/glossary/#nft)が挙げられます。
-[イーサリアムでサインイン](https://siwe.xyz/)機能を使うと、サーバはユーザーのイーサリアムアカウントを確認し、アカウントアドレスから必要なアテステーションを取得することができます。 これにより、ユーザーは長いパスワードを記憶することなくプラットフォームやウェブサイトにアクセスでき、オンライン・エクスペリエンスを向上させることができます。
+[Sign-In with Ethereum](https://siwe.xyz/)機能により、サーバーはユーザーのEthereumアカウントを確認し、そのアカウントアドレスから必要なアテステーションを取得できるようになります。 これにより、ユーザーは長いパスワードを記憶することなくプラットフォームやウェブサイトにアクセスでき、オンライン・エクスペリエンスを向上させることができます。
### 2. KYC認証 {#kyc-authentication}
オンラインサービスの多くを利用するには、運転免許証やパスポートなどのアテステーションを提出する必要があります。 しかし、この方法では、ユーザーの個人情報が漏洩するおそれがあり、サービスプロバイダーはアテステーションの正当性を確認できないという問題があります。
-分散型アイデンティティにより、企業は従来の[本人確認(KYC)](https://en.wikipedia.org/wiki/Know_your_customer)プロセスを省略し、検証可能な資格情報を利用してユーザーのアイデンティティを認証することができます。 これにより、ID管理のコストを削減し、偽造文書の使用を防ぐことができます。
+分散型IDにより、企業は従来の[顧客確認 (KYC)](https://en.wikipedia.org/wiki/Know_your_customer)プロセスを省略し、検証可能な資格情報を使ってユーザーIDを認証できます。 これにより、ID管理のコストを削減し、偽造文書の使用を防ぐことができます。
### 3. 投票とオンラインコミュニティ {#voting-and-online-communities}
-オンライン投票とソーシャルメディアは、分散型アイデンティティの新しい適用です。 オンライン投票の仕組みでは、悪意ある者が偽のIDを作成し投票することで、改ざんされるおそれがあります。 個人に対してオンチェーン・アテステーションを求めることで、オンライン投票プロセスの信頼性を向上できます。
+オンライン投票とソーシャルメディアは、分散型アイデンティティの新しい適用です。 オンライン投票の仕組みでは、悪意ある者が偽のIDを作成し投票することで、改ざんされるおそれがあります。 個人にオンチェーンのアテステーションの提示を求めることで、オンライン投票プロセスの健全性を向上させることができます。
-分散型アイデンティティは、偽アカウントのないオンラインコミュニティの構築に役立ちます。 例えば、ENS(イーサリアム・ネーム・サービス)のようなオンチェーンのアイデンティティシステムを使って認証させることで、ボットを減らすことができる可能性があります。
+分散型アイデンティティは、偽アカウントのないオンラインコミュニティの構築に役立ちます。 例えば、各ユーザーがEthereum Name ServiceのようなオンチェーンのIDシステムを使って本人認証を行うことで、ボットの可能性を減らせるかもしれません。
-### 4. シビル攻撃の防御 {#sybil-protection}
+### 4. アンチシビル対策 {#sybil-protection}
-[クアドラティック・ボーティング](/glossary/#quadratic-voting)を用いた助成金授与アプリケーションでは、より多くの投票が集まることで助成金の価値が上がり、多くのIDを使って寄付するというインセンティブが働くため、[シビル攻撃](/glossary/#sybil-attack)を受けやすくなっています。 分散型アイデンティティは、多くの場合、特定の個人情報を明らかにすることなく、各参加者自身が機械ではなく本当に人間であることを証明するという負担を高めることで、シビル攻撃の防止に役立ちます。
+[クアドラティック・ボーティング](/glossary/#quadratic-voting)を使用する助成金提供アプリケーションは、[シビル攻撃](/glossary/#sybil-attack)に対して脆弱です。なぜなら、より多くの個人が投票すると助成金の価値が上がり、ユーザーが多くのIDに貢献を分割するインセンティブが働くからです。 分散型アイデンティティは、多くの場合、特定の個人情報を明らかにすることなく、各参加者自身が機械ではなく本当に人間であることを証明するという負担を高めることで、シビル攻撃の防止に役立ちます。
+
+### 5. 国および政府のID {#national-and-government-id}
+
+政府は、分散型IDの原則を用いて、国民ID、パスポート、運転免許証などの基本的な身分証明書をEthereum上の検証可能な資格情報として発行し、オンラインでの本人確認における詐欺や偽造を減らすための強力な暗号学的真正性保証を提供できます。 市民はこれらのアテステーションを個人の[ウォレット](/wallets/)に保存し、身元、年齢、または投票権を証明するために使用できます。
+
+このモデルは、特に[ゼロ知識証明 (ZKP)](/zero-knowledge-proofs/) プライバシー技術と組み合わせることで、選択的開示を可能にします。 例えば、市民は、従来のIDよりも高いプライバシーを提供し、正確な生年月日を明かすことなく、年齢制限のあるサービスにアクセスするために18歳以上であることを暗号技術によって証明できます。
+
+#### 💡ケーススタディ: Ethereum上のブータン国民デジタルID (NDI) {#case-study-bhutan-ndi}
+
+- ブータンの約80万人の国民に、検証可能なID資格情報へのアクセスを提供
+- 2025年10月にPolygonネットワークから[Ethereumメインネット](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878)に移行
+- 2025年3月時点で[234,000件以上](https://www.blockchain-council.org/blockchain/bhutan-uses-blockchain-in-digital-id-project/)のデジタルIDを発行
+
+ブータン王国は、2025年10月に[国民デジタルID (NDI) システムをEthereumに移行しました](https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878)。 分散型IDと自己主権型IDの原則に基づいて構築されたブータンのNDIシステムは、分散型IDと検証可能な資格情報を使用して、デジタル署名された資格情報を市民の個人ウォレットに直接発行します。 これらの資格情報の暗号学的証明をEthereum上に固定することで、システムはそれらが本物で改ざん不可能であり、中央機関に問い合わせることなくどの当事者でも検証できることを保証します。
+
+このシステムのアーキテクチャは、[ゼロ知識証明 (ZKP)](/zero-knowledge-proofs/) 技術の使用を通じてプライバシーを重視しています。 この「選択的開示」の実装により、市民は完全なID番号や正確な生年月日などの基礎となる個人データを明かすことなく、サービスにアクセスするために特定の事実 (例:「私は18歳以上です」または「私は国民です」) を証明できます。 これは、安全でユーザー中心、かつプライバシーを保護する国民IDシステムのための、Ethereumの強力な実世界での使用例を示しています。
+
+#### 💡ケーススタディ: Ethereumの[レイヤー2](/layer-2/)であるZKSync Era上のブエノスアイレス市のQuarkID {#case-study-buenos-aires-quarkid}
+
+- ローンチ時に[360万人以上のユーザー](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)に分散型ID資格情報を発行
+- QuarkIDは、国連の持続可能な開発目標の下で[デジタル公共財](https://www.digitalpublicgoods.net/r/quarkid)として認識されているオープンソースプロトコルです
+- 市がプロトコルを所有せず、市民に完全なデータ所有権とプライバシーを与える「[ユーザーとしての政府](https://buenosaires.gob.ar/innovacionytransformaciondigital/miba-con-tecnologia-quarkid-la-ciudad-de-buenos-aires-incorporo)」モデルを強調
+
+2024年、ブエノスアイレス市政府 (GCBA) は、GCBAのイノベーション・デジタル変革事務局が構築したオープンソースの「デジタル信頼フレームワーク」であるQuarkIDを、住民が政府サービスや公式文書にアクセスするための市の公式アプリであるmiBAに統合しました。 ローンチ時、miBAの360万人以上の全ユーザーに分散型デジタルIDが発行され、市民権の証明書、出生、結婚、死亡証明書、納税記録、ワクチン接種記録など、検証可能なデジタル文書や証明書をオンチェーンで管理・共有できるようになりました。
+
+Ethereumの[レイヤー2](/layer-2/)ネットワークであるZKSync Era上に構築されたQuarkIDシステムは、ZKP技術を使用して、市民が不必要な個人データを公開することなく、モバイルデバイスを通じてピアツーピアで個人の資格情報を検証できるようにします。 このプログラムは、GCBAが中央集権的な所有者としてではなく、オープンソースで相互運用可能なQuarkIDプロトコルの1ユーザーとして機能する「ユーザーとしての政府」モデルを強調しています。 このZKP対応アーキテクチャは、重要なプライバシー機能を提供します。第三者、GCBAでさえも、市民がいつ、どこで、なぜ資格情報を使用したかを追跡することはできません。 この成功したプログラムは、市民に完全な自己主権型IDと機密データに対する管理権を提供し、そのすべてがEthereumの世界的に分散したネットワークによって保護されています。
## アテステーションとは {#what-are-attestations}
アテステーションとは、ある存在が別の存在に対して行われる証明を意味します。 例えばアメリカに住んでいる場合、車両管理局(ある存在)が、あなた(別の存在)が合法的に車の運転を許可されているということを証明するために運転免許証を発行します。
-アテステーションは身分を証明するIDとは異なります。 アテステーションには、_特定のアイデンティティを参照するためのIDを含み_、また当該アイデンティティに関連する属性についても証します。 つまり、運転免許証には身分を証明するID(氏名、生年月日、住所)が含まれ、同時に、運転できるという法的権利(属性)に関しても証明します。
+アテステーションは身分を証明するIDとは異なります。 アテステーションは、特定のアイデンティティを参照するためのIDを_含み_、このアイデンティティに関連する属性についての主張を行います。 つまり、運転免許証には身分を証明するID(氏名、生年月日、住所)が含まれ、同時に、運転できるという法的権利(属性)に関しても証明します。
### 分散型IDとは {#what-are-decentralized-identifiers}
氏名やメールアドレスといった従来のIDは、政府やメールプロバイダーといったサードパーティに依存します。 分散型ID (DID)は、中央集権組織により発行、管理、制御されないという点で異なります。
-分散型IDは、自分自身で発行、保有、管理することができます。 [イーサリアムアカウント](/glossary/#account)は、分散型IDの一例です。 誰からの許可も不要で、また中央台帳に保存する必要もなく、好きなだけアカウントを作成することができます。
+分散型IDは、自分自身で発行、保有、管理することができます。 [Ethereumアカウント](/glossary/#account)は、分散型IDの一例です。 誰からの許可も不要で、また中央台帳に保存する必要もなく、好きなだけアカウントを作成することができます。
-分散型IDは、分散型台帳([ブロックチェーン](/glossary/#blockchain))や[ピアツーピアネットワーク](/glossary/#peer-to-peer-network)に格納されるため、 分散型IDは[世界的に一意で、高い可用性で解決可能で、暗号技術で検証可能](https://w3c-ccg.github.io/did-primer/)なものです。 分散型IDは、人、組織、政府機関など、さまざまなエンティティに関連付けることができます。
+分散型IDは、分散型台帳 ([ブロックチェーン](/glossary/#blockchain)) や[ピアツーピア・ネットワーク](/glossary/#peer-to-peer-network)に保存されます。 これにより、DIDは[世界的に一意で、高い可用性で解決可能で、暗号技術によって検証可能](https://w3c-ccg.github.io/did-primer/)になります。 分散型IDは、人、組織、政府機関など、さまざまなエンティティに関連付けることができます。
-## 分散型IDを実現する技術 {#what-makes-decentralized-identifiers-possible}
+## 分散型IDを実現する技術 分散型IDを可能にするもの {#what-makes-decentralized-identifiers-possible}
### 1. 公開鍵暗号 {#public-key-cryptography}
-公開鍵暗号とは、あるエンティティに対して[公開鍵](/glossary/#public-key)と[秘密鍵](/glossary/#private-key)を生成する情報セキュリティのことです。 公開鍵の[暗号技術](/glossary/#cryptography)は、ブロックチェーンネットワークにおいて、ユーザーの身分を認証し、デジタル資産の所有権を証明するために使用されます。
+公開鍵暗号は、エンティティに対して[公開鍵](/glossary/#public-key)と[秘密鍵](/glossary/#private-key)を生成する情報セキュリティ対策です。 公開鍵[暗号](/glossary/#cryptography)は、ブロックチェーンネットワークにおいて、ユーザーIDを認証し、デジタル資産の所有権を証明するために使用されます。
-イーサリアムアカウントなどの分散型IDには、公開鍵と秘密鍵があるものがあります。 公開鍵はアカウントのコントローラを識別し、秘密鍵はこのアカウントのメッセージに署名および復号化します。 公開鍵暗号は、[暗号署名](https://andersbrownworth.com/blockchain/public-private-keys/)を使用してすべての主張を検証することにより、エンティティを認証し、なりすましや偽のIDの使用を防ぎます。
+イーサリアムアカウントなどの分散型IDには、公開鍵と秘密鍵があるものがあります。 公開鍵はアカウントのコントローラを識別し、秘密鍵はこのアカウントのメッセージに署名および復号化します。 公開鍵暗号は、[暗号署名](https://andersbrownworth.com/blockchain/public-private-keys/)を使用してすべての主張を検証することで、エンティティを認証し、なりすましや偽のIDの使用を防ぐために必要な証明を提供します。
### 2. 分散型データストア {#decentralized-datastores}
@@ -107,7 +133,7 @@ summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテス
分散型アイデンティティとは、アイデンティティに関連する情報は自己管理され、プライベートでポータブルであるべきという考え方であり、分散型IDとアテステーションにより成り立っています。
-分散型アイデンティティの文脈では、アテステーション([検証可能な資格情報](https://www.w3.org/TR/vc-data-model/))とは、改ざんできず、暗号学的に検証できる発行者の主張です。 エンティティ(組織など)が発行するすべてのアテステーション、すなわち検証可能な資格情報は、その分散型ID (DID)と紐づけられます。
+分散型IDの文脈において、アテステーション (別名[検証可能な資格情報](https://www.w3.org/TR/vc-data-model/)) は、発行者によってなされる、改ざん不可能で暗号技術によって検証可能な主張です。 エンティティ(組織など)が発行するすべてのアテステーション、すなわち検証可能な資格情報は、その分散型ID (DID)と紐づけられます。
分散型ID (DID)はブロックチェーンに保存されるため、発行者のDIDをイーサリアム上で照合すれば、誰でもアテステーションの正当性を確認することができます。 基本的に、イーサリアムのブロックチェーンは、特定のエンティティに関連する分散型IDの検証を可能にするグローバルディレクトリのように機能します。
@@ -115,77 +141,78 @@ summaryPoint3: 暗号技術により、今や再び自分自身のIDとアテス
また、分散型IDは個人情報のプライバシーを保護する上でも非常に重要になります。 例えば、個人がアテステーション(運転免許証)を提出する場合、検証者は証明書の情報の正当性を確認する必要はありません。 検証者は、アテステーションの正当性の暗号学的な保証と、発行組織のアイデンティティだけで証明書の正当性を判断できます。
-## 分散型アイデンティティにおけるアテステーションの種類 {#types-of-attestations-in-decentralized-identity}
+## 分散型IDにおけるアテステーションの種類 {#types-of-attestations-in-decentralized-identity}
イーサリアムベースの分散型アイデンティティにおいては、アテステーション情報をどのように保存し、取得するかは、従来のアイデンティティ管理とは異なります。 ここでは、分散型IDシステムにおけるアテステーションの発行、保管、検証のためのさまざまなアプローチの概要を説明します。
-### オフチェーン・アテステーション {#off-chain-attestations}
+### オフチェーンアテステーション {#offchain-attestations}
-アテステーションをオンチェーンで保存する場合の懸念点として、個人が秘密にしたい情報が含まれている可能性があることが挙げられます。 イーサリアムのブロックチェーンはパブリックな性質を持っているため、個人情報が含まれるアテステーションを保存することは望ましくありません。
+アテステーションをオンチェーンで保存する際の懸念の1つは、個人が非公開にしておきたい情報が含まれている可能性があることです。 イーサリアムのブロックチェーンはパブリックな性質を持っているため、個人情報が含まれるアテステーションを保存することは望ましくありません。
-解決策としては、ユーザーがオフチェーンでデジタルウォレットに保有し、オンチェーンで保存されている発行者の分散型ID (DID)で署名されたアテステーションを発行することです。 これらのアテステーションは[JSONウェブトークン](https://en.wikipedia.org/wiki/JSON_Web_Token)としてエンコードされ、発行者のデジタル署名を含んでいるため、オフチェーンでの主張を簡単に検証することができます。
+解決策は、ユーザーがオフチェーンのデジタルウォレットで保持し、発行者のオンチェーンに保存されたDIDで署名されたアテステーションを発行することです。 これらのアテステーションは、[JSON Web Token](https://en.wikipedia.org/wiki/JSON_Web_Token)としてエンコードされ、発行者のデジタル署名を含んでいるため、オフチェーンでの主張を簡単に検証できます。
-ここで、仮想シナリオを用いてオフチェーン・アテステーションの説明します。
+オフチェーンアテステーションを説明するための、仮説のシナリオを以下に示します:
1. 大学(発行者)は証明書(デジタル学術証明書)を生成し、大学の鍵で署名し、ボブ(アイデンティティ所有者)に発行します。
2. ボブは就職活動で、自分の学歴を雇用主に証明するため、モバイルウォレットからアテステーションを共有します。 企業(検証者)は、発行者の分散型ID (イーサリアム上の公開鍵)を確認することで、アテステーションの正当性を確認することができます。
-### 永続的なアクセスによるオフチェーン・アテステーション {#offchain-attestations-with-persistent-access}
+### 永続的アクセスが可能なオフチェーンアテステーション {#offchain-attestations-with-persistent-access}
-この方式のアテステーションでは、JSONファイルに変換され、オフチェーンに保存されます(理想的には、IPFSやSwarmなどの [分散型クラウドストレージ](/developers/docs/storage/) プラットフォーム上)。 ただし、JSONファイルの[ハッシュ](/glossary/#hash)はオンチェーンに保存され、オンチェーンレジストリ経由で分散型IDにリンクされています。 紐づけられる分散型IDは、アテステーションの発行者または受取人のどちらかのものであることがあります。
+この方式では、アテステーションはJSONファイルに変換され、オフチェーン (理想的にはIPFSやSwarmなどの[分散型クラウドストレージ](/developers/docs/storage/)プラットフォーム) に保存されます。 しかし、JSONファイルの[ハッシュ](/glossary/#hash)はオンチェーンに保存され、オンチェーンレジストリを介してDIDにリンクされます。 紐づけられる分散型IDは、アテステーションの発行者または受取人のどちらかのものであることがあります。
このアプローチにより、アテステーションはブロックチェーンベースの永続性を得て、主張する情報を暗号化し検証可能な状態に保つことができます。 また、秘密鍵の保有者は情報を復号化できるため、選択的に開示することも可能です。
-### オフチェーン・アテステーション {#onchain-attestations}
+### オンチェーンアテステーション {#onchain-attestations}
-オンチェーン・アテステーションは、イーサリアムのブロックチェーン上の[スマートコントラクト](/glossary/#smart-contract)に保持されます。 スマートコントラクト(レジストリとして機能)は、アテステーションを該当するオンチェーン分散型ID公開鍵)にマッピングします。
+オンチェーンアテステーションは、Ethereumブロックチェーン上の[スマートコントラクト](/glossary/#smart-contract)で保持されます。 スマートコントラクト (レジストリとして機能) は、アテステーションを対応するオンチェーンの分散型ID (公開鍵) にマッピングします。
-ここでは、オンチェーン・アテステーションがどのように機能するか例を紹介します。
+オンチェーンアテステーションが実際にどのように機能するかの例を以下に示します:
1. ある企業(XYZ Corp)は、スマートコントラクトを使用して所有権の株式を売却することを計画していますが、バックグラウンドチェックを通った買手のみを求めています。
-2. XYZ Corpは、バックグラウンドチェックを行う会社に、イーサリアム上でオンチェーン・アテステーションを発行してもらうことができます。 このアテステーションは、個人情報を明かすことなくバックグラウンドチェックに通ったことを証明するものです。
+2. XYZ社は、身元調査を行う会社に、Ethereum上でオンチェーンアテステーションを発行させることができます。 このアテステーションは、個人情報を明かすことなくバックグラウンドチェックに通ったことを証明するものです。
3. 株式を売却するスマートコントラクトは、レジストリコントラクトで審査した買い手の身元を確認し、株式の買手を判断することができます。
-### ソウルバウンド・トークンとアイデンティティ {#soulbound}
+### ソウルバウンドトークンとID {#soulbound}
-[ソウルバウンドトークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)([譲渡不可の非代替性トークン](/glossary/#nft))は、特定のウォレットに固有の情報の収集に使用される可能性があります。 これは、特定のイーサリアムアドレスに結びついた一意のオンチェーンアイデンティティを効果的に作成し、業績(例えば、特定のオンラインコースの修了や、ゲームで閾値のスコアの通過など)やコミュニティへの参加を表すトークンを含むことができます。
+[ソウルバウンドトークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([譲渡不可能なNFT](/glossary/#nft)) は、特定のウォレットに固有の情報を収集するために使用できます。 これにより、特定のEthereumアドレスに紐付けられた一意のオンチェーンIDが効果的に作成されます。これには、実績 (例: 特定のオンラインコースの修了、ゲームでのしきい値スコアの達成) やコミュニティへの参加を表すトークンを含めることができます。
-## 分散型アイデンティティの利用 {#use-decentralized-identity}
+## 分散型IDを使用する {#use-decentralized-identity}
分散型アイデンティティソリューションの基盤としてイーサリアムを使用する、大掛かりなプロジェクトが数多くあります。
-- **[イーサリアム・ネーム・サービス(ENS)](https://ens.domains/)** - _イーサリアムウォレットアドレス、コンテンツハッシュ、メタデータなどのオンチェーン、機械読み取り可能なIDの分散型ネーミングシステム_
-- **[SpruceID](https://www.spruceid.com/)** - _サードパーティーのサービスに頼らず、イーサリアムアカウントとENSプロファイルでデジタルアイデンティティを管理できるようにする分散型アイデンティティプロジェクト_
-- **[イーサリアム・アテステーション・サービス (EAS)](https://attest.sh/)** - _あらゆるものについてオンチェーンまたはオフチェーンのアテステーションを作成するための分散型台帳/プロトコル_
-- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (PoH)は、イーサリアム上に構築されたソーシャルID認証システム_
-- **[BrightID](https://www.brightid.org/)** - _ソーシャルグラフの作成と分析を通じて、本人確認の改革を目指す分散型オープンソース・ソーシャルアイデンティティネットワーク_
-- **[walt.id](https://walt.id)** — _オープンソースの分散型アイデンティティとウォレットのインフラストラクチャです。これにより、デベロッパーや組織は、自己主権型アイデンティティとNFT/SBTを活用可能にします。_
-- **[Veramo](https://veramo.io/)** - _JavaScriptフレームワークで、暗号学的に検証可能なデータを誰でも簡単にアプリケーションで利用することができます。_
+- **[Ethereum Name Service (ENS)](https://ens.domains/)** - _Ethereumウォレットアドレス、コンテンツハッシュ、メタデータなどのオンチェーンで機械可読なIDのための分散型ネーミングシステム。_
+- **[Sign in with Ethereum (SIWE)](https://siwe.xyz/)** - _Ethereumアカウントによる認証のためのオープンスタンダード。_
+- **[SpruceID](https://www.spruceid.com/)** - _サードパーティのサービスに依存せず、EthereumアカウントとENSプロファイルでデジタルIDを管理できる分散型IDプロジェクト。_
+- **[Ethereum Attestation Service (EAS)](https://attest.org/)** - _あらゆるものについてオンチェーンまたはオフチェーンのアテステーションを行うための分散型台帳/プロトコル。_
+- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (またはPoH) は、Ethereum上に構築されたソーシャルID認証システムです。_
+- **[BrightID](https://www.brightid.org/)** - _ソーシャルグラフの作成と分析を通じて、ID認証の改革を目指す、分散型のオープンソース・ソーシャルIDネットワーク。_
+- **[walt.id](https://walt.id)** — _開発者や組織が自己主権型IDとNFT/SBTを活用できるようにする、オープンソースの分散型IDおよびウォレットインフラストラクチャ。_
+- **[Veramo](https://veramo.io/)** - _誰でもアプリケーションで暗号技術によって検証可能なデータを簡単に使用できるようにするJavaScriptフレームワーク。_
-## 参考文献 {#further-reading}
+## 参考リンク {#further-reading}
### 記事 {#articles}
-- [ブロックチェーンの活用事例: デジタルIDにおけるブロックチェーン](https://consensys.net/blockchain-use-cases/digital-identity/) —_ConsenSys_
-- [イーサリアムERC725とは ブロックチェーン上の自己主権型ID管理](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_
-- [ブロックチェーンはデジタルID問題をどのように解決するか](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_
-- [分散型アイデンティティとは、注目に値する理由](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_
-- [分散型アイデンティティの紹介](https://walt.id/white-paper/digital-identity) — _Dominik Beron_
+- [ブロックチェーンのユースケース: デジタルIDにおけるブロックチェーン](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_
+- [イーサリアムERC725とは? ブロックチェーン上での自己主権型ID管理](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_
+- [ブロックチェーンはデジタルIDの問題をどのように解決できるか](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_
+- [分散型IDとは何か、そしてなぜ気にかけるべきか?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_
+- [分散型ID入門](https://walt.id/white-paper/digital-identity) — _Dominik Beron_
-### ビデオ {#videos}
+### 動画 {#videos}
-- [分散型アイデンティティ(ボーナスライブストリームセッション)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Andreas Antonopolousによる分散型アイデンティティに関する秀逸な解説ビデオ_
-- [イーサリアムでサインインし、Ceramic、IDX、React、および 3ID Connectを使用した分散型ID](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Nader Dabitによるイーサリアムウォレットを使用したユーザープロファイルの作成、読み取り、更新のID管理システムの構築に関するYouTubeチュートリアルビデオ_
-- [BrightID - イーサリアム上の分散型アイデンティティ](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _イーサリアムの分散型IDソリューション「BrightID」に関するBanklessポッドキャスト_
-- [オフ・チェーン・インターネット: 分散型アイデンティティと検証可能な資格情報](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Evin McMullenによるEthDenver 2022のプレゼンテーション
-- [検証可能な資格情報の説明](https://www.youtube.com/watch?v=ce1IdSr-Kig) - Tamino Baumannによるデモを含んだYouTubeの説明ビデオ
+- [分散型ID (ボーナスライブストリームセッション)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Andreas Antonopolousによる分散型IDに関する秀逸な解説動画_
+- [Ceramic、IDX、React、3ID Connectを使ったイーサリアムでのサインインと分散型ID](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Nader Dabitによる、Ethereumウォレットを使用してユーザーのプロファイルを作成、読み取り、更新するためのID管理システムを構築するYouTubeチュートリアル_
+- [BrightID - Ethereum上の分散型ID](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Ethereum向けの分散型IDソリューションであるBrightIDについて議論するBanklessポッドキャストエピソード_
+- [オフチェーンインターネット: 分散型IDと検証可能な資格情報](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Evin McMullenによるEthDenver 2022でのプレゼンテーション
+- [検証可能な資格情報の説明](https://www.youtube.com/watch?v=ce1IdSr-Kig) - Tamino Baumannによるデモ付きYouTube解説動画
### コミュニティ {#communities}
-- [GitHub上のERC-725アライアンス](https://github.com/erc725alliance) — _イーサリアムのブロックチェーン上でIDを管理するための規格「ERC725」のサポーターコミュニティ_
-- [EthID Discordサーバ](https://discord.com/invite/ZUyG3mSXFD) — _「イーサリアムでサインイン」に取り組むファンやデベロッパーのためのコミュニティ_
-- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _アプリケーション向けの検証可能なデータのフレームワークの構築に貢献するデベロッパーのコミュニティ_
-- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _さまざまな業界にわたる分散型IDのユースケースに取り組むデベロッパーおよびビルダーのコミュニティ_
+- [GitHubのERC-725アライアンス](https://github.com/erc725alliance) — _Ethereumブロックチェーン上でIDを管理するためのERC725標準の支持者_
+- [EthID Discordサーバー](https://discord.com/invite/ZUyG3mSXFD) — _Sign-in with EthereumおよびEthereum Follow Protocolに取り組む愛好家と開発者のためのコミュニティ_
+- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _アプリケーション向けの検証可能データのためのフレームワーク構築に貢献する開発者のコミュニティ_
+- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _さまざまな業界にわたる分散型IDのユースケースに取り組む開発者とビルダーのコミュニティ_
diff --git a/public/content/translations/ja/defi/index.md b/public/content/translations/ja/defi/index.md
index fb74ec963bb..9d68d98127d 100644
--- a/public/content/translations/ja/defi/index.md
+++ b/public/content/translations/ja/defi/index.md
@@ -1,15 +1,16 @@
---
-title: 分散型金融(DeFi)
-description: イーサリアムにおける分散型金融(DeFi)の概要
+title: "分散型金融(DeFi)"
+metaTitle: "分散型金融(DeFi)とは | 分散型金融の利点と使用法"
+description: "イーサリアムにおける分散型金融(DeFi)の概要"
lang: ja
template: use-cases
emoji: ":money_with_wings:"
image: /images/use-cases/defi.png
-alt: レゴブロックで作られたETHのロゴ
+alt: "レゴブロックで作られたETHのロゴ"
sidebarDepth: 2
-summaryPoint1: 現在の金融システムに変わる、グローバルで開かれた分散型金融。
-summaryPoint2: 借りる、貯蓄、投資、取引などを実現する製品。
-summaryPoint3: オープンソース技術に基づき、誰でもプログラミング可能。
+summaryPoint1: "現在の金融システムに変わる、グローバルで開かれた分散型金融。"
+summaryPoint2: "借りる、貯蓄、投資、取引などを実現する製品。"
+summaryPoint3: "オープンソース技術に基づき、誰でもプログラミング可能。"
---
分散型金融(DeFi)は、インターネット時代に対応したオープンでグローバルな金融システムであり、不透明で厳しく管理された、何十年も前のインフラやプロセスのシステムを置き換えるものです。 自分のお金をコントロールし、可視化することができます。 グローバル市場に入ることができ、自国の通貨や銀行の選択肢の代替となります。 分散型金融(DeFi)製品は、インターネットの接続がある人であれば誰でも金融サービスを受けることができ、ほとんどがユーザーによって所有・維持されています。 これまでに数百億ドル相当の暗号資産が、分散型金融(DeFi)アプリケーションを経由しており、その額は日々増加しています。
@@ -22,7 +23,7 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ
-## 分散型金融(DeFi)と従来の金融システムとの比較 {#defi-vs-tradfi}
+## DeFi 対 従来の金融 {#defi-vs-tradfi}
分散型金融(DeFi)の可能性を知るための最良の方法の一つは、現在ある問題を理解することです。
@@ -31,24 +32,24 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ
- 金融サービスは、あなたをブロックし、支払いを受けることができないようにすることができます。
- 金融サービスへの隠された料金には、利用者の個人情報があります。
- 政府や中央集権機関が自由に市場を閉鎖することができます。
-- 取引時間は、大抵特定の営業時間帯に限定されます。
+- 取引時間は、多くの場合、特定のタイムゾーンの営業時間内に限定されます。
- 内部の人的なプロセスにより、送金には数日かかる場合があります。
- 仲介機関への分け前が必要なため、金融サービスには手数料が必要です。
### 比較 {#defi-comparison}
-| 分散型金融(DeFi) | 従来の金融システム |
+| 分散型金融(DeFi) | 従来の金融システム |
| ----------------------------------------------------- | --------------------------------------------------- |
| 自分でお金を保有します。 | 企業があなたのお金を保有します。 |
| 自分のお金がどこに行くか、どのように使われるかをコントロールすることができます。 | リスクの高い借り手に貸し出す等、企業があなたのお金を煩雑に管理していないことを信用する必要があります。 |
| 資金の移動は数分で完了します。 | 支払いには手動の作業プロセスのために数日かかることがあります。 |
| トランザクションは仮名で行われます。 | 金融活動は、利用者の個人情報と密接に結びついています。 |
-| 分散型金融(DeFi)は誰でも利用できます。 | 金融サービスの利用申請が必要です。 |
+| 分散型金融(DeFi)は誰でも利用できます。 | 金融サービスの利用申請が必要です。 |
| 市場は常にオープンしています。 | 従業員の休息のため、市場が閉じる時間があります。 |
| 誰もが製品データを見て、システムがどのように機能しているかを調べることができる、透明性の高いシステムです。 | 金融機関はクローズド・ブックであり、融資の履歴や運用資産の記録などを見せてもらうことはできません。 |
- 分散型金融(DeFi)アプリを探す
+ DeFiアプリを探す
## 始まりはビットコイン... {#bitcoin}
@@ -59,16 +60,16 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ
-## プログラム可能な通貨 {#programmable-money}
+## プログラム可能なお金 {#programmable-money}
-これは一見奇妙なことのように聞こえます。「なぜ自分のお金をプログラムする必要があるのでしょうか?」 しかし、これはむしろイーサリアムのトークンのデフォルト機能に過ぎません。 誰でも支払いに論理をプログラムすることができます。 プログラミングにより、金融機関が提供するサービスに、ビットコインのコントロールとセキュリティを混在させることができます。 貸し借りや支払いのスケジューリング、インデックスファンドへの投資など、ビットコインではできないことを暗号通貨で行うことができます。
+奇妙に聞こえるかもしれませんが… 「なぜ自分のお金をプログラムする必要があるのでしょうか?」 しかし、これはむしろイーサリアムのトークンのデフォルト機能に過ぎません。 誰でも支払いに論理をプログラムすることができます。 プログラミングにより、金融機関が提供するサービスに、ビットコインのコントロールとセキュリティを混在させることができます。 貸し借りや支払いのスケジューリング、インデックスファンドへの投資など、ビットコインではできないことを暗号通貨で行うことができます。
-
+
イーサリアムを初めて使う方にお勧めの分散型金融(DeFi)アプリケーション
- 分散型金融(DeFi)アプリを探す
+ DeFiアプリを探す
@@ -77,49 +78,49 @@ summaryPoint3: オープンソース技術に基づき、誰でもプログラ
ほとんどの金融サービスには、分散型の代替手段があります。 しかし、イーサリアムは、次のようなまったく新しい金融商品を生み出す機会も与えてくれます。 リストは増え続けていきます。
-- [世界中への送金](#send-money)
-- [世界中へのお金の流通](#stream-money)
-- [安定した通貨へのアクセス](#stablecoins)
-- [担保から資金の借り入れ](#lending)
-- [担保なしの借り入れ](#flash-loans)
-- [暗号資産の預金口座の開設](#saving)
-- [トークンのトランザクション](#swaps)
-- [ポートフォリオの拡大](#investing)
-- [アイデアへの資金供給](#crowdfunding)
-- [保険の購入](#insurance)
-- [ポートフォリオ管理](#aggregators)
+- [世界中に送金する](#send-money)
+- [世界中にお金をストリーミングする](#stream-money)
+- [ステーブルコインにアクセスする](#stablecoins)
+- [担保付きで資金を借りる](#lending)
+- [担保なしで借りる](#flash-loans)
+- [暗号資産で貯蓄を始める](#saving)
+- [トークンを取引する](#swaps)
+- [ポートフォリオを拡大する](#investing)
+- [アイデアの資金を調達する](#crowdfunding)
+- [保険に加入する](#insurance)
+- [ポートフォリオを管理する](#aggregators)
-### 世界中に素早く送金 {#send-money}
+### 世界中に素早く送金する {#send-money}
-イーサリアムはブロックチェーンとして、安全かつグローバルな方法でトランザクションを行うために設計されています。 ビットコイン同様、イーサリアムは世界中にお金を送ることが、メールを送るように簡単にできます。 受信者の[イーサリアム・ネーム・サービス(ENS)名](/glossary/#ens) (例: bob.eth)またはウォレットのアカウントアドレスを入力するだけで、通常、数分後には支払いが直接相手に届きます。 支払いの送受信には、 [ウォレット](/wallets/)が必要です。
+イーサリアムはブロックチェーンとして、安全かつグローバルな方法でトランザクションを行うために設計されています。 ビットコイン同様、イーサリアムは世界中にお金を送ることが、メールを送るように簡単にできます。 受信者の[ENS名](/glossary/#ens)(bob.ethなど)またはウォレットのアカウントアドレスを入力するだけで、通常は数分で支払いが直接相手に届きます。 支払いの送受信には、[ウォレット](/wallets/)が必要です。
- 支払いの分散型アプリ(Dapp)を見る
+ 決済dappsを見る
#### 世界中へのお金の流通... {#stream-money}
また、イーサリアムでお金を流通させることもできます。 これにより、誰かに給料を秒単位で支払うことができ、受取人は必要なときにいつでもお金にアクセスすることができます。 また、コインロッカーや電動自転車など、秒単位でレンタルすることもできます。
-また、[ETH](/glossary/#ether)の価値がどれだけ変わるかわからないので、送金や流通はしたくないという方には、イーサリアムの代替通貨である[ステーブルコイン](/glossary/#stablecoin)があります。
+また、価値の変動が大きいため[ETH](/glossary/#ether)の送金やストリーミングをしたくない場合でも、イーサリアムには代替通貨である[ステーブルコイン](/glossary/#stablecoin)があります。
-### 安定した通貨へのアクセス {#stablecoins}
+### ステーブルコインへのアクセス {#stablecoins}
暗号通貨の変動性は、多くの金融商品や一般歳出にとっては問題となります。 分散型金融(DeFi)コミュニティはこれをステーブルコインで解決しました。 ステーブルコインの価値は、別の資産、通常はドルのような一般的な通貨を担保にしています。
DaiやUSDCのようなコインの価値変動は、1ドルで数セントの範囲内です。 そのため、給与や小売業に最適です。 中南米では、政府が発行する通貨に大きな不安があるため、自分の貯蓄を守る手段として、多くの人々がステーブルコインを利用しています。
- ステーブルコインの詳細
+ステーブルコインの詳細はこちら
-### 融資 {#lending}
+### 借り入れ {#lending}
分散型プロバイダーからお金を借りるには、大きく分けて2種類あります。
@@ -127,24 +128,24 @@ DaiやUSDCのようなコインの価値変動は、1ドルで数セントの範
- プールベース: 借り手が借り入れることができるプールに、貸し手が資金(流動性)を提供する方法です。
- 融資分散型アプリ(Dapp)を見る
+ 借り入れdappsを見る
分散型貸付業者の利用には、多くの利点があります。
-#### プライバシーを守りながらの借り入れ {#borrowing-privacy}
+#### プライバシーを確保した借り入れ {#borrowing-privacy}
現在、お金の貸し借りは、すべて個人が中心となって行われています。 銀行は融資をする前に、借り手に返済する見込みがあるかどうかを見極める必要があります。
-分散型融資は、どちらも自分の名前を名乗る必要がありません。 その代わり、借り手は担保を提供する必要があり、その担保は融資が返済されない場合に貸し手が自動的に受け取ることになります。 一部の貸し手では、[非代替性トークン(NFT)](/glossary/#nft)を担保として受け入れています。 非代替性トークン(NFT)とは、美術絵画のような唯一無二の資産に対する証明です。 [非代替性トークン(NFT)の詳細](/nft/)
+分散型融資は、どちらも自分の名前を名乗る必要がありません。 その代わり、借り手は担保を提供する必要があり、その担保は融資が返済されない場合に貸し手が自動的に受け取ることになります。 貸し手の中には、[NFT](/glossary/#nft)を担保として受け入れるところもあります。 非代替性トークン(NFT)とは、美術絵画のような唯一無二の資産に対する証明です。 [NFTの詳細](/nft/)
これにより、クレジットチェックや個人情報を開示せずにお金を借りることができます。
-#### グローバル資金へのアクセス {#access-global-funds}
+#### グローバルな資金へのアクセス {#access-global-funds}
-分散型金融機関を利用すると、あなたが選んだ銀行や金融機関に預けている資金だけでなく、世界中から入金された資金にアクセスすることができます。 これにより、ローンがより利用しやすくなり、金利も改善されます。
+分散型金融機関を利用すると、あなたが選んだ銀行や金融機関に預けている資金だけでなく、世界中から入金された資金にアクセスすることができます。 これによりローンがより利用しやすくなり、金利が改善されます。
-#### 課税効率 {#tax-efficiencies}
+#### 税効率 {#tax-efficiencies}
ETHを売却(課税対象)することなく、必要な資金を借り入れることができます。 その代わり、ETHを担保にステーブルコインを借りることができます。 これにより、必要なキャッシュフローを得ることができ、ETHをそのまま保有しておくことができます。 ステーブルコインは、ETHのように価値が変動しないので、現金が必要な時にはより適しているトークンです。 [ステーブルコインの詳細](#stablecoins)
@@ -177,22 +178,22 @@ ETHを売却(課税対象)することなく、必要な資金を借り入れる
-### 暗号資産で預金を始める {#saving}
+### 暗号資産で貯蓄を始める {#saving}
-#### 貸付 {#lending}
+#### 貸し出し {#lending}
-暗号通貨を貸すことで利息を得ることができ、資金が増えていく様子をリアルタイムで見ることができます。 現在の利息は、地元の銀行で得られる金利よりもはるかに高いです(運良く銀行を利用できた場合)。 次に例を示します。
+暗号通貨を貸すことで利息を得ることができ、資金が増えていく様子をリアルタイムで見ることができます。 現在の利息は、地元の銀行で得られる金利よりもはるかに高いです(運良く銀行を利用できた場合)。 具体的なコードは、以下のようになります:
-- [ステーブルコイン](/stablecoins/)である100 DaiをAaveのようなサービスに貸し付けます。
+- [ステーブルコイン](/stablecoins/)である100 Daiを、Aaveのようなプロダクトに貸し付けます。
- 貸したDaiを表すトークンである100 Aave Dai (aDai)を受領します。
-- aDaiは金利に基づいて増加し、あなたのウォレットで残高が増えていくのを見ることができます。 [年換算利回り(APR)](/glossary/#apr)に応じて、数日後、あるいは数時間後にウォレットの残高が100.1234のように表示されます。
+- aDaiは金利に基づいて増加し、あなたのウォレットで残高が増えていくのを見ることができます。 [APR](/glossary/#apr)(年換算利回り)に応じて、数日後、あるいは数時間後にはウォレットの残高が100.1234のように表示されます。
- aDai残高と同額の通常のDaiをいつでも引き出すことができます。
- 貸付サービスの分散型アプリ(Dapp)を見る
+ レンディングdappsを見る
-#### 損失がない宝くじ {#no-loss-lotteries}
+#### 損失のでない宝くじ {#no-loss-lotteries}
PoolTogetherのような損失のない宝くじは、楽しく革新的な新しい貯蓄方法です。
@@ -210,14 +211,14 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
-### トークンの交換 {#swaps}
+### トークンを交換する {#swaps}
イーサリアムには何千ものトークンがあります。 分散型取引所(DEX)でいつでも異なるトークンを取引できます。 ご自身の資産の管理をあきらめる必要はありません。 これは、外国に行ったときに両替所を利用するようなものです。 しかし、分散型金融(DeFi)では両替所は閉じることはありません。 市場は365日24時間体制で、テクノロジーにより、取引を受け付ける人が常にいます。
-例えば、上述の損失のない宝くじPoolTogetherを利用したい場合、DaiやUSDCなどのトークンが必要になります。 これらの分散型取引所では、自分のETHをそれらのトークンと交換し、終了後またETHに戻すことができます。
+例えば、上述の損失のない宝くじPoolTogetherを利用したい場合、DaiやUSDCなどのトークンが必要になります。 これらの分散型取引所では、自分のETHをそれらのトークンと取引し、終了後またETHに戻すことができます。
- トークン交換所を見る
+ トークン取引所を見る
@@ -229,24 +230,24 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
中央集権的な取引所を利用する場合は、取引を行う前に資産を預けて、その資産の管理を任せなければなりません。 中央の取引所はハッカーにとって魅力的なターゲットであるため、資産が預けられている間はリスクがあります。
- トレード分散型アプリ(Dapp)を見る
+ トレーディングdappsを見る
-### ポートフォリオの拡大 {#investing}
+### ポートフォリオを拡大する {#investing}
イーサリアムには、自分が選んだ戦略に基づいてポートフォリオを拡大を図るファンドマネジメント商品があります。 これは、自動的、誰にでも開かれていて、かつ管理者に利益の一部を取られる必要はありません。
-その良い例が、[分散型金融Pulseインデックスファンド(DPI)](https://defipulse.com/blog/defi-pulse-index/)です。 これは、あなたのポートフォリオが常に時価総額上位のDeFiトークンを含むように自動的にリバランスするファンドです。 細かい管理をする必要がなく、好きな時にファンドから引き出すことができます。
+良い例として、[DeFi Pulse Indexファンド(DPI)](https://defipulse.com/blog/defi-pulse-index/)が挙げられます。 これは、あなたのポートフォリオが常に時価総額上位のDeFiトークンを含むように自動的にリバランスするファンドです。 細かい管理をする必要がなく、好きな時にファンドから引き出すことができます。
- 投資分散型アプリ(Dapp)を見る
+ 投資dappsを見る
-### アイデアへの資金供給 {#crowdfunding}
+### アイデアの資金を調達する {#crowdfunding}
イーサリアムはクラウドファンディングに理想的なプラットフォームです。
@@ -255,14 +256,14 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
- 出資者は、例えば、特定の期限や最低金額が達成されなかった場合、自動的に返金されるように設定することができます。
- クラウドファンディング分散型アプリ(Dapp)を見る
+ クラウドファンディングdappsを見る
-#### クオドラティック・ファンディング {#quadratic-funding}
+#### クアドラティック・ファンディング {#quadratic-funding}
-イーサリアムはオープンソースソフトウェアであり、これまでの作業の多くはコミュニティの資金提供を受けてきました。 これにより、クオドラティック・ファンディングという興味深い新しい資金調達モデルが成長しました。 将来的に、私達が公共財のすべてのタイプに資金を供給する方法を改善する可能性があるファンディングです。
+イーサリアムはオープンソースソフトウェアであり、これまでの作業の多くはコミュニティの資金提供を受けてきました。 これにより、クオドラティック・ファンディングという興味深い新しい資金調達モデルが成長しました。 クアドラティック・ファンディングは、将来的にすべての種類の公共財の資金供給方法を改善できる可能性を秘めており、
-クオドラティック・ファンディングでは、最もユニークな必要性があるプロジェクトが、最も多くの資金を受け取るようになっています。 つまり、ほとんどの人々の生活を向上させるためのプロジェクトです。 その仕組みは次のとおりです。
+最もユニークな必要性があるプロジェクトが、最多の資金を受け取るようになっています。 つまり、最も多くの人々が必要なものに資金が渡り、人々の生活の向上につながるプロジェクトです。 その仕組みは次のとおりです。
1. 寄付を集めて供与先を決めるためのマッチングプールがあります。
2. 資金供与のラウンドが始まります。
@@ -272,7 +273,7 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
つまり、1ドルの寄付が100件集まったプロジェクトAの方が、1つの1万ドルの寄付に支援されたプロジェクトBよりも多くの資金を得られる可能性があるということです(マッチングプールの大きさによります)。
- クオドラティック・ファンディングの詳細
+ クアドラティック・ファンディングの詳細
@@ -281,10 +282,10 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
分散型保険は、保険料をより安く、より早く、より透明にすることを目指しています。 自動化が進めば、保険料はより手頃になり、支払いもより迅速になります。 保険請求を決定するために使用されるデータには、完全に透明性があります。
-他のソフトウェアと同様、イーサリアム製品は、バグや不正搾取の問題があります。 そのため、現在のところ、この分野の保険商品の多くは、ユーザーが資金を失うことを防ぐことに重点を置いています。 しかし、起こりうるあらゆることをカバーするプロジェクトも存在しています。 その良い例が、[ケニアの零細農家を干ばつや洪水から守ることを目的とした](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)Etheriscの生産物保証です。 分散型の保険は、従来の保険では値段が高過ぎて手がでないことが多い農民に、より安価な保険を提供することができます。
+Ethereum製品は、他のソフトウェアと同様に、バグや不正搾取に悩まされることがあります。 そのため、現在のところ、この分野の保険商品の多くは、ユーザーが資金を失うことを防ぐことに重点を置いています。 しかし、起こりうるあらゆることをカバーするプロジェクトも存在しています。 この良い例は、[ケニアの小規模農家を干ばつや洪水から守る](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc)ことを目的としたEtheriscのCrop coverです。 分散型の保険は、従来の保険では値段が高過ぎて手がでないことが多い農民に、より安価な保険を提供することができます。
- 保険分散型アプリ(Dapp)見る
+ 保険dappsを見る
@@ -294,7 +295,7 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
多くのことが行われているため、すべての投資、ローン、取引を記録する方法が必要になります。 すべての分散型金融(DeFi)アクティビティを1つの場所で管理できる製品が多数あります。 これが分散型金融(DeFi)のオープンアーキテクチャーの魅力です。 製品すべての残高を確認できるだけでなく、その機能を利用できるインターフェースを構築することができます。 分散型金融(DeFi)をより深く知るための参考にしてみてください。
- ポートフォリオ分散型アプリ(Dapp)を見る
+ ポートフォリオdappsを見る
@@ -311,53 +312,54 @@ PoolTogetherのような損失のない宝くじは、楽しく革新的な新
これは、現在のところ、コードを解読できるイーサリアムコミュニティの技術的なメンバーを信頼する必要があることを意味しています。 オープンソースベースのコミュニティは、デベロッパーをチェックするのに役立っていますが、スマートコントラクトが解読しやすくなり、コードの信頼性を証明する他の方法が開発されるにつれて、この必要性は時間とともに減少していくでしょう。
-## イーサリアムと分散型金融(DeFi) {#ethereum-and-defi}
+## イーサリアムとDeFi {#ethereum-and-defi}
イーサリアムは、さまざまな理由から分散型金融(DeFi)の基盤として最適です。
- イーサリアムやスマートコントラクトは誰かの所有物ではないため、誰もが分散型金融(DeFi)を利用することができます。 これはまた、誰もあなたに関するルールを変更できないことを意味します。
-- 分散型金融(DeFi)製品はすべて、舞台裏で同じ言語を話しており、その言語はイーサリアムです。 このため、多くの製品がシームレスに連携します。 あるプラットフォームでトークンを貸し出し、その利息付きトークンを全く別のアプリケーションで別の市場で交換することができます。 これは、銀行でポイントを現金化できるようなものです。
+- 分散型金融(DeFi)製品はすべて、舞台裏で同じ言語を話しており、その言語はイーサリアムです。 このため、多くの製品がシームレスに連携します。 あるプラットフォームでトークンを貸し出し、その利息付きトークンを全く別のアプリケーションで別の市場で取引することができます。 これは、銀行でポイントを現金化できるようなものです。
- トークンと暗号通貨は、共有台帳であるイーサリアムに組み込まれています。トランザクションや所有権を追跡することは、イーサリアムの得意とするところです。
- イーサリアムは完全な経済的自由を可能にします。ほとんどの製品はあなたの資金を管理することはなく、自分の資金を自分でコントロールすることができます。
分散型金融(DeFi)をレイヤーで考えてみましょう。
1. ブロックチェーン - イーサリアムには、トランザクション履歴やアカウント状態が記録されています。
-2. 資産 - [ETH](/what-is-ether/)とその他のトークン(通貨)
-3. プロトコル - 機能を提供する[スマートコントラクト](/glossary/#smart-contract)は、例えば資産の分散型レンディングを可能にするサービスなどを提供します。
-4. [アプリ](/apps/) - プロトコルの管理やアクセスのために使用する製品
+2. 資産 – [ETH](/what-is-ether/)およびその他のトークン(通貨)のことです。
+3. プロトコル – 機能を提供する[スマートコントラクト](/glossary/#smart-contract)のことで、例えば資産の分散型貸付を可能にするサービスなどです。
+4. [アプリケーション](/apps/) – プロトコルを管理し、アクセスするために使用するプロダクトのことです。
-注意: DeFiの多くは、[ERC-20規格](/glossary/#erc-20)を使っています。 DeFiのアプリケーションでは、ラップドイーサ(WETH)というラップされたETHを使うことになります。 [ラップドイーサの詳細](/wrapped-eth)。
+注:DeFiの多くは[ERC-20規格](/glossary/#erc-20)を利用しています。 DeFiのアプリケーションでは、Wrapped ether(WETH)と呼ばれるETHのラッパーを使用します。 [ラップされたEtherの詳細はこちら](/wrapped-eth)。
-## 分散型金融(DeFi)の構築 {#build-defi}
+## DeFiを構築する {#build-defi}
分散型金融(DeFi)はオープンソースのムーブメントです。 分散型金融(DeFi)のプロトコルとアプリケーションはすべて公開されており、ユーザーが検査、フォーク(分岐)、改変を行うことができます。 このようにレイヤー状になっているため(ベースとなるブロックチェーンや資産はすべて共通)、プロトコルを組み合わせ、ユニークな組み合わせでのチャンスを生み出すことができます。
- 分散型アプリ(Dapp)構築の詳細
+ dapps構築の詳細
-## 参考文献 {#further-reading}
+## 参考リンク {#further-reading}
-### 分散型金融(DeFi)データ {#defi-data}
+### DeFiデータ {#defi-data}
- [DeFi Prime](https://defiprime.com/)
- [DeFi Llama](https://defillama.com/)
-### 分散型金融(DeFi)に関する記事 {#defi-articles}
+### DeFi関連記事 {#defi-articles}
-- [DeFi初心者ガイド](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu (2020年1月6日)_
+- [DeFi初心者ガイド](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu、2020年1月6日_
+- [EEA DeFiリスク評価ガイドライン](https://entethalliance.org/specs/defi-risks/) – DeFiプロトコルの主要なリスクを特定・評価する方法について、業界が支援する概要。
-### ビデオ {#videos}
+### 動画 {#videos}
-- [Finematics - 分散型金融に関する教育](https://finematics.com/) – _分散型金融(DeFi)に関するビデオ_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _分散型金融(DeFi)の基本: 時に不可解な分散型金融を始めるために学ぶべきことすべて。_
-- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _分散型金融(DeFi)とは_
+- [Finematics - 分散型金融の教育](https://finematics.com/) – _DeFiに関するビデオ_
+- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _DeFiの基礎: 時には難解なこの分野を始めるために知っておくべきことのすべて。_
+- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _DeFiとは?_
### コミュニティ {#communities}
-- [DeFi Pulse Discord server](https://discord.defillama.com/)
-- [DeFi Pulse Discord server](https://discord.gg/Gx4TCTk)
+- [DeFi LlamaのDiscordサーバー](https://discord.defillama.com/)
+- [DeFi PulseのDiscordサーバー](https://discord.gg/Gx4TCTk)
diff --git a/public/content/translations/ja/desci/index.md b/public/content/translations/ja/desci/index.md
index 2096652408c..e12a7708586 100644
--- a/public/content/translations/ja/desci/index.md
+++ b/public/content/translations/ja/desci/index.md
@@ -1,43 +1,43 @@
---
-title: 分散型科学 (DeSci)
-description: イーサリアム上の分散型科学の概要
+title: "分散型サイエンス(DeSci)"
+description: "イーサリアム上の分散型科学の概要"
lang: ja
template: use-cases
emoji: ":microscope:"
sidebarDepth: 2
image: /images/future_transparent.png
alt: ""
-summaryPoint1: 現在の科学に代わる、グローバルで開かれたシステム。
-summaryPoint2: 科学者が資金を調達し、実験を行い、データーを共有し、得られた見識を広めることなどを可能にする技術。
-summaryPoint3: オープンサイエンス運動の上に構築。
+summaryPoint1: "現在の科学に代わる、グローバルで開かれたシステム。"
+summaryPoint2: "科学者が資金を調達し、実験を行い、データーを共有し、得られた見識を広めることなどを可能にする技術。"
+summaryPoint3: "オープンサイエンス運動の上に構築。"
---
## 分散型科学(DeSci)とは何か {#what-is-desci}
-分散型科学(DeSci)は[Web3](/glossary/#web3)スタックを用いることで、科学的知見に対する財政支援、そして科学的知見の創造、審査、認定、保管、普及のための、公平公正な公的インフラストラクチャの形成を目指す運動です。
+分散型科学(DeSci)は、[Web3](/glossary/#web3)スタックを使用して、科学的知識の資金調達、創造、レビュー、単位認定、保存、普及を公正かつ公平に行うための公共インフラの構築を目指す運動です。
DeSciは、科学者が自身の研究を公然と共有することにインセンティブを与えられ、そしてその仕事に対する名声を得られ、一方で誰もが簡単にその研究にアクセスし、さらに研究に貢献できるようなエコシステムの形成を目指しています。 DeSciは、科学的知識は誰にでもアクセス可能であり、科学研究のプロセスは透明であるべきという考えに則っています。 DeSciはより非中央集権的で分散型の科学研究モデルを形成することで、中央当局による検閲と管理に対する抵抗力を高めます。 DeSciは、資金調達、科学的ツール、コミュニケーション手段へのアクセスを分散化することによって、慣習にとらわれない新しいアイデアが繁栄する環境を作りたいと考えています。
-分散型科学により、多様な資金調達方法([分散型自律組織](/glossary/#dao)、[クアドラティックドネーション](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、クラウドファンディングなど)が可能となることで、データや科学的手法へのアクセスが容易になり、さらに再現性へのインセンティブを付与することができます。
+分散型科学は、[DAO](/glossary/#dao)や[クアドラティックドネーション](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)からクラウドファンディングなど、より多様な資金源を可能にし、データや手法へのアクセスを容易にし、再現性へのインセンティブも提供します。
### Juan Benet - DeSci運動
-## いかにしてDeSciが科学を向上させるのか {#desci-improves-science}
+## DeSciが科学をいかに改善するか {#desci-improves-science}
科学の主要な問題点と、分散型科学でどのような解決が可能かをまとめた現時点におけるリストです。
-| **分散型科学** | **従来の科学** |
-| --------------------------------------------------------------- | ------------------------------------------------------------- |
-| 資金分配は、クアドラティックドネーションやDAOなどのメカニズムを用いて、**大衆によって決定されます**。 | 小規模で閉鎖的な**中央集権化されたグループ**が、資金分配をコントロールします。 |
-| **世界中の誰とでも**、動的なチームを形成して研究ができます。 | 資金提供団体や科学者の所属機関により、共同研究が**制限**されます。 |
-| 資金調達の決定は、オンラインかつ**透明性**をもって実行されます。 新しい資金調達のメカニズムが検討されます。 | 資金調達の決定には長い時間がかかり、**限られた透明性**の中で実行しています。 資金調達のメカニズムはほぼ存在しません。 |
-| [Web3](/glossary/#web3)技術を利用することで、研究所のサービスをより簡単かつ透明性をもって共有できます。 | 研究所のリソースを共有できるまでに**時間がかかることが多く、その手続きも不透明**です。 |
-| Web3プリミティブによって、信頼性と透明性が高く、かつ普遍的アクセスを実現する**新たな出版モデル**の開発が可能です。 | **非効率的でバイアスがあり、悪用されうる**旧来の手続きによって研究成果が出版されます。 |
-| **論文を査読することでトークンや評価を得ることができます**。 | 研究者が**無報酬で査読**し、営利目的の出版社に利益を提供します。 |
-| 科学者が自身の生み出した**知的財産(IP)を所有し**、透明性のある条件に従って配布します。 | 科学者が生み出した**知的財産は所属機関が所有**します。 知的財産へのアクセスは不透明です。 |
-| 全手順をオンチェーンにすることで、失敗した作業のデータも含めて、**すべての研究を共有できます**。 | **出版バイアス**とは、成功した実験ほど共有する傾向が強いというバイアスです。 |
+| **分散型科学** | **従来の科学** |
+| -------------------------------------------------------------- | ------------------------------------------------------------ |
+| 資金の分配は、クアドラティックドネーションやDAOなどのメカニズムを用いて**一般の人々によって決定されます**。 | 小規模で閉鎖的な**中央集権化されたグループ**が、資金の分配をコントロールします。 |
+| ダイナミックなチームで**世界中の**仲間と共同作業ができます。 | 資金提供団体や所属機関によって、共同研究が**制限されます**。 |
+| 資金調達の決定は、オンラインかつ**透明性をもって**実行されます。 新しい資金調達のメカニズムが検討されます。 | 資金調達の決定には長い時間がかかり、**限られた透明性**の中で実行されます。 資金調達のメカニズムはほぼ存在しません。 |
+| [Web3](/glossary/#web3)技術を利用することで、研究室サービスの共有がより簡単かつ透明になります。 | 研究室リソースの共有は、しばしば**遅くて不透明です**。 |
+| 信頼、透明性、普遍的なアクセスのためにWeb3プリミティブを使用する**新しい出版モデル**を開発することができます。 | しばしば**非効率的、偏向的、搾取的**と見なされる既存の経路を通して出版されます。 |
+| **査読作業でトークンと評価を得る**ことができます。 | **査読作業は無報酬**で、営利目的の出版社に利益をもたらします。 |
+| **あなたが生成した知的財産(IP)を所有**し、透明性のある条件に従って配布します。 | **あなたが生成したIPは、所属機関が所有します**。 知的財産へのアクセスは不透明です。 |
+| すべてのステップをオンチェーンにすることで、失敗した取り組みのデータを含む**すべての研究を共有**します。 | **出版バイアス**とは、研究者が成功した結果の実験を共有する可能性が高いことを意味します。 |
## イーサリアムとDeSci {#ethereum-and-desci}
@@ -49,89 +49,91 @@ DeSciは、従来の学術界をデジタルの世界にオンボーディング
### 出版 {#publishing}
-科学論文の出版は顕著な問題を抱えており、その背景には、論文の作成にあたり、科学者、査読者、編集者を無報酬で働かせ、法外な出版料を請求する出版社の存在があります。 一般市民は税金という形で科学者の活動費と出版費を間接的に支払っていますが、通常は、出版社に対して追加で支払いを行わないと、出版物を閲覧することはできません。 個々の科学論文の出版にかかる総額は、通常米ドルで5桁に上り、[公共財](/glossary/#public-goods)としての科学的知識の概念が損なわれる一方で、少数の出版社に莫大な利益がもたらされています。
+科学論文の出版は顕著な問題を抱えており、その背景には、論文の作成にあたり、科学者、査読者、編集者を無報酬で働かせ、法外な出版料を請求する出版社の存在があります。 一般市民は税金という形で科学者の活動費と出版費を間接的に支払っていますが、通常は、出版社に対して追加で支払いを行わないと、出版物を閲覧することはできません。 個々の科学論文を出版するための総費用は、しばしば5桁(米ドル)に上り、科学的知識を[公共財](/glossary/#public-goods)とみなす概念を損なう一方で、少数の出版社に莫大な利益がもたらされています。
-無料のオープンアクセスプラットフォームは、[ArXiv](https://arxiv.org/)などのプリントサーバーという形で存在します。 しかし、こうしたプラットフォームは品質管理や[シビル攻撃を防ぐメカニズム](/glossary/#anti-sybil)が不足しているうえに、通常は個々の論文の評価も追跡しません。つまり、従来の出版社に投稿する前に研究を発表するためだけに利用されています。 SciHubでは出版された論文に自由にアクセスできますが、合法ではありません。自由なアクセスは、出版社が料金を受け取った後、厳格に著作権法に則って提供されるべきものです。 科学論文やデーターをアクセスしやすい形で、かつ合法性が担保された枠組みで提供することについては、大きな改善の余地があります。 Web3には、このようなシステムを構築するためのツールが存在します。
+無料のオープンアクセスプラットフォームは、[ArXiv](https://arxiv.org/)などのプレプリントサーバーの形で存在します。 しかし、これらのプラットフォームは品質管理や[アンチシビルメカニズム](/glossary/#anti-sybil)に欠けており、通常、記事レベルの指標を追跡しません。つまり、従来の出版社に投稿する前に研究を公表するためにのみ使用されているのが普通です。 SciHubでは出版された論文に自由にアクセスできますが、合法ではありません。自由なアクセスは、出版社が料金を受け取った後、厳格に著作権法に則って提供されるべきものです。 科学論文やデーターをアクセスしやすい形で、かつ合法性が担保された枠組みで提供することについては、大きな改善の余地があります。 Web3には、このようなシステムを構築するためのツールが存在します。
-### 再現可能性と再生可能性 {#reproducibility-and-replicability}
+### 再現性と複製可能性 {#reproducibility-and-replicability}
再現可能性と再生可能性は価値ある科学的発見の基礎となるものです。
- 再現可能な結果とは、同一の研究グループが同じ手法を用いて、繰り返し連続で得られるものです。
- 再生可能な結果とは、別の研究グループが、同一の実験設定の下で得られるものです。
-新しいWeb3ネイティブなツールによって、再現性と複製性が発見の基礎であることが保証できるようになります。 アカデミアの技術的な構造に優れた科学を織り込むことができます。 Web3によって、生データ、計算エンジン、アプリケーションの結果などの解析コンポーネントに関する[アテステーション](/glossary/#attestation)を作成できるようになります。 コンセンサスシステムの素晴らしいところは、信頼できるネットワークを作成してそれらのコンポーネントを維持する場合に、ネットワークの各参加者が計算の再現と結果の検証に貢献できることにあります。
+新しいWeb3ネイティブなツールによって、再現性と複製性が発見の基礎であることが保証できるようになります。 アカデミアの技術的な構造に優れた科学を織り込むことができます。 Web3により、生データ、計算エンジン、アプリケーションの結果といった各分析コンポーネントの[アテステーション](/glossary/#attestation)を作成できます。 コンセンサスシステムの素晴らしいところは、信頼できるネットワークを作成してそれらのコンポーネントを維持する場合に、ネットワークの各参加者が計算の再現と結果の検証に貢献できることにあります。
### 資金調達 {#funding}
-科学への資金提供における現在の標準モデルでは、個人や科学者のグループが資金配分機関に書面にて申請する手順となっています。 信頼できる少数の識者が申請書を採点し、その後候補者の面接を経て、評価の高かった一部の候補者に資金が提供されます。 助成金の申請から受領まで、時に**年単位で待つ**ことになるボトルネックを生み出すだけでなく、このモデルは、審査委員会による**偏見、私欲、権力闘争に対して非常に脆弱である**と言われています。
+科学への資金提供における現在の標準モデルでは、個人や科学者のグループが資金配分機関に書面にて申請する手順となっています。 信頼できる少数の識者が申請書を採点し、その後候補者の面接を経て、評価の高かった一部の候補者に資金が提供されます。 助成金の申請から受領までの間に時に**年単位の待ち時間**が生じるボトルネックを生み出すだけでなく、このモデルは審査委員会の**偏見、私利私欲、政治に対して非常に脆弱である**ことが知られています。
同じ提案であっても同委員会の担当者によって結果が大きく異なることがあり、優れた提案を選択するうえで助成金審査委員会は責務を果たしていないことが研究によって示されています。 資金調達が厳しくなる中で、資金の行く先は保守的なプロジェクトを行う少人数の上席研究者へと集中してきました。 その結果、非常に競争の激しい資金調達環境が生み出され、歪んだインセンティブを根付かせ、イノベーションを妨げることになりました。
-DAOとWeb3によって培われた各種インセンティブモデルを広く試すことで、現在の破綻した資金調達モデルを食い止めることができるかもしれません。 [遡及的な公共財の資金調達](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)、[クオドラティック・ファンディング](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、[DAOガバナンス](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead)、[トークン化されたインセンティブ構造](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)などのWeb3ツールには、科学の資金調達に大変革をもたらす可能性があります。
+DAOとWeb3によって培われた各種インセンティブモデルを広く試すことで、現在の破綻した資金調達モデルを食い止めることができるかもしれません。 [遡及的な公共財ファンディング](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)、[クアドラティックファンディング](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)、[DAOガバナンス](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead)、[トークン化されたインセンティブ構造](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design)は、科学の資金調達に革命を起こしうるWeb3ツールの一部です。
### IPの所有権と開発 {#ip-ownership}
-従来の科学において知的財産(IP)は大きな問題となっています。大学で身動きが取れない状況に陥っていたり、バイオテクノロジー業界で応用されていなかったり、評価ができない状態になってしまっています。 しかし、Web3が[非代替性トークン(NFT)](/glossary/#nft)を活用することで、デジタル資産(科学的データや論文など)を真に所有できるようになります。
+従来の科学において知的財産(IP)は大きな問題となっています。大学で身動きが取れない状況に陥っていたり、バイオテクノロジー業界で応用されていなかったり、評価ができない状態になってしまっています。 しかし、Web3は[非代替性トークン(NFT)](/glossary/#nft)を使用することで、デジタル資産(科学データや記事など)の所有権を非常にうまく扱うことができます。
NFTが将来の取引の収益を元の作成者に還元できるように、透明性のある価値の帰属チェーンを確立することができます。これにより、研究者やDAOのような管理団体、そしてデータの収集元となった被験者へも報酬を与えることができます。
-[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6)もまた、進行中の研究実験の分散データレポジトリにアクセスするための鍵として機能し、NFTや[DeFi](/glossary/#defi)の金融化(資産の分散、融資プールと価値評価) へとつながります。 また、[VitaDAO](https://www.vitadao.com/)のようなネイティブにチェーン上に存在するDAOを使用することで、研究活動を直接オンチェーンで行うことができます。 譲渡不可の[「ソウルバウンド」トークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)の出現により、イーサリアムアドレスにリンクされた経験や経歴を個人が証明できるようになるため、DeSciで重要な役割を果たす可能性があります。
+[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6)は、実施されている研究実験の分散型データリポジトリへの鍵として機能し、NFTや[DeFi](/glossary/#defi)の金融化(フラクショナル化からレンディングプール、価値評価まで)に接続することも可能です。 また、[VitaDAO](https://www.vitadao.com/)のようなDAOなど、ネイティブにオンチェーンのエンティティが、研究を直接オンチェーンで実施することも可能になります。
+譲渡不可能な["ソウルバウンド"トークン](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)の登場は、個人が自身のイーサリアムアドレスに紐づいた経験や信用情報を証明することを可能にするため、DeSciにおいて重要な役割を果たす可能性があります。
### データストレージ、アクセス、アーキテクチャ {#data-storage}
Web3の様式を活用することで科学データへのアクセスが大幅に向上し、分散ストレージによって研究成果を大災害から守ることができます。
-起点となるシステムは、適切かつ検証可能な認証情報を備えた分散型アイデンティティでアクセスできる必要があります。 そうすることで、冗長性や検閲耐性、結果の再現を可能にし、さらには複数の関係者が協力してデータセットに新しいデータを追加できるようになり、信頼のおける関係者によって機密データを安全に再生することができます。 [compute-to-data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol)のような機密コンピューティング方法は、生データの再生への代替アクセス機構を提供し、極めて機密性の高いデータに対して「信頼できる研究環境」を生成します。 [NHS](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb)は、信頼できる研究環境について、データプライバシーとコラボレーションにおいて将来的な解決策であると言及しています。これは、研究者がデータを安全に扱い、コードやプラクティスを共有するための標準化された環境を利用してオンサイトで作業できるエコシステムの構築を意味します。
+起点となるシステムは、適切かつ検証可能な認証情報を備えた分散型アイデンティティでアクセスできる必要があります。 そうすることで、冗長性や検閲耐性、結果の再現を可能にし、さらには複数の関係者が協力してデータセットに新しいデータを追加できるようになり、信頼のおける関係者によって機密データを安全に再生することができます。 [コンピュート・トゥ・データ](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol)のような秘匿コンピューティング手法は、生データの複製に代わるアクセスメカニズムを提供し、最も機密性の高いデータのために信頼できる研究環境を創出します。 信頼できる研究環境は、研究者がコードやプラクティスを共有するための標準化された環境を使用してオンサイトで安全にデータと連携できるエコシステムを作成することで、データプライバシーとコラボレーションの将来を見据えたソリューションとして、[NHSによって言及されています](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb)。
柔軟なWeb3データソリューションは、上記のシナリオをサポートし、研究者がアクセス許可や手数料なしで公共財を作成できる真のオープンサイエンスの基盤を提供します。 IPFS、Arweave、FilecoinなどのWeb3パブリックデータソリューションは、分散化のために最適化されています。 たとえば、dClimateは、気象観測所や予測気候モデルなどを含む、気候や気象データへの普遍的なアクセスを提供しています。
-## 参加 {#get-involved}
+## 参加する {#get-involved}
プロジェクトを探索し、DeSciコミュニティに参加してください。
-- [DeSci.Global: グローバルなイベントとオフ会カレンダー](https://desci.global)
-- [サイエンステレグラムのためのブロックチェーン](https://t.me/BlockchainForScience)
-- [Molecule: 研究プロジェクトのための資金提供と資金獲得](https://www.molecule.xyz/)
-- [VitaDAO: 長寿研究のための研究スポンサー契約を通じた資金獲得](https://www.vitadao.com/)
+- [DeSci.Global: 世界的なイベントとミートアップカレンダー](https://desci.global)
+- [Blockchain for Science Telegram](https://t.me/BlockchainForScience)
+- [Molecule: 研究プロジェクトへの資金提供と資金調達](https://www.molecule.xyz/)
+- [VitaDAO: 長寿研究のためのスポンサー付き研究契約を通じて資金提供を受ける](https://www.vitadao.com/)
- [ResearchHub: 科学的成果を投稿し、仲間と会話する](https://www.researchhub.com/)
-- [dClimate API: 分散型コミュニティに収集された気候データのクエリ](https://www.dclimate.net/)
-- [DeSci財団: DeSci出版ツールビルダー](https://descifoundation.org/)
-- [DeSci.World: ユーザーが閲覧して参加できる分散型科学のワンストップショップ](https://desci.world)
-- [OceanDAO: データ関連科学のための、DAOに統制された資金調達](https://oceanprotocol.com/)
-- [Opsciana: オープン分散型サイエンスワークフロー](https://opsci.io/research/)
-- [Bio.xyz: バイオテクノロジーDAOや分散型サイエンスプロジェクトのための資金獲得](https://www.bio.xyz/)
-- [Flemingプロトコル: 共同のバイオメディカルの発見を促進するオープンソースのデータエコノミー](http://flemingprotocol.io/)
+- [dClimate API: 分散型コミュニティによって収集された気候データをクエリする](https://www.dclimate.net/)
+- [DeSci Foundation: DeSci出版ツールビルダー](https://descifoundation.org/)
+- [DeSci.World: ユーザーが分散型科学を閲覧し、関与するためのワンストップショップ](https://desci.world)
+- [OceanDAO: データ関連科学のためのDAOによる資金調達](https://oceanprotocol.com/)
+- [Opscientia: オープンな分散型科学ワークフロー](https://opsci.io/research/)
+- [Bio.xyz: バイオテクノロジーDAOまたはDeSciプロジェクトのための資金調達](https://www.bio.xyz/)
+- [Fleming Protocol: 協調的な生物医学的発見を促進するオープンソースのデータエコノミー](http://flemingprotocol.io/)
- [Active Inference Institute](https://www.activeinference.org/)
-- [IdeaMarkets: 分散型科学の信ぴょう性の有効化](https://ideamarket.io/)
+- [IdeaMarkets: 分散型科学の信頼性を実現](https://ideamarket.io/)
- [DeSci Labs](https://www.desci.com/)
-- [ValleyDAO: オープンなグローバルコミュニティで合成生物学研究のファンディングおよび翻訳に関するサポートを提供](https://www.valleydao.bio)
-- [Cerebrum DAO: 脳の健康と神経変性を防ぐためのソリューションの調達と育成](https://www.cerebrumdao.com/)
-- [CryoDAO: 冷凍保存分野におけるムーンショット型研究へのファンディング](https://www.cryodao.org)
-
-新しいプロジェクトを提案する際には[ポリシー一覧](/contributing/adding-desci-projects/)をご覧ください。
-
-## 参考文献 {#further-reading}
-
-- [Jocelynn PearlとUltraareによるDeSci Wiki](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
-- [Jocelynn Pearlによるa16zの未来のための分散型バイオテックのガイド](https://future.a16z.com/a-guide-to-decentralized-biotech/)
-- [DeSciのケース](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
-- [DeSciのガイド](https://future.com/what-is-decentralized-science-aka-desci/)
-- [分散型科学のリソース](https://www.vincentweisser.com/desci)
-- [MoleculeのBiopharma IP-NFTs - 技術説明](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
-- [Jon Starrによるトラストレスな科学システムの構築](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
-- [Paul Kohlaas - DeSci: 分散型科学の未来(ポッドキャスト)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
-- [分散型サイエンスのための活発な推論オントロジー: 状況感覚から知識コモンズへ](https://zenodo.org/record/6320575)
-- [DeSci: Samuel Akinoshoによる研究の未来](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
-- [サイエンスファンディング(エピローグ: DeSciと新しい暗号プリミティブ) by Nadia](https://nadia.xyz/science-funding)
-- [分散化は薬物開発を妨害する](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
-- [DeSci - 分散型科学とは何か?](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
+- [ValleyDAO: 合成生物学研究に資金提供とトランスレーショナルサポートを提供するオープンなグローバルコミュニティ](https://www.valleydao.bio)
+- [Cerebrum DAO: 脳の健康を促進し、神経変性を予防するためのソリューションのソーシングと育成](https://www.cerebrumdao.com/)
+- [CryoDAO: 人体冷凍保存分野のムーンショット研究への資金提供](https://www.cryodao.org)
+- [Elata: 精神医学の未来に発言権を持つ](https://www.elata.bio/)
+
+新しいプロジェクトの掲載提案を歓迎します。まずは[掲載ポリシー](/contributing/adding-desci-projects/)をご覧ください。
+
+## 参考リンク {#further-reading}
+
+- [Jocelynn PearlとUltrarareによるDeSci Wiki](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
+- [Jocelynn Pearlによる分散型バイオテクノロジーのガイド(a16z future)](https://future.a16z.com/a-guide-to-decentralized-biotech/)
+- [DeSciの事例](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
+- [DeSciガイド](https://future.com/what-is-decentralized-science-aka-desci/)
+- [分散型科学リソース](https://www.vincentweisser.com/desci)
+- [Moleculeのバイオ医薬品IP-NFT - 技術的説明](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
+- [Jon Starr著『トラストが不要な科学のシステムの構築』](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
+- [Paul Kohlhaas - DeSci: 分散型科学の未来(ポッドキャスト)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
+- [分散型科学のための能動的推論オントロジー: 状況的意味形成から認識論的コモンズまで](https://zenodo.org/record/6320575)
+- [Samuel Akinosho著『DeSci: 研究の未来』](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
+- [Nadia著『科学への資金提供(エピローグ: DeSciと新しい暗号プリミティブ)』](https://nadia.xyz/science-funding)
+- [分散化が医薬品開発を破壊する](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
+- [DeSci(分散型科学)とは何か](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
### 動画 {#videos}
- [分散型科学とは何か](https://www.youtube.com/watch?v=-DeMklVWNdA)
-- [長寿研究と暗号の交点についてのVitalik Buterinと科学者Aubrey de Greyの会話](https://www.youtube.com/watch?v=x9TSJK1widA)
-- [破綻している科学出版業界を Web3で救えるか?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
-- [Juan Benet - DeSci、Independent Labs、及び大規模データサイエンス](https://www.youtube.com/watch?v=zkXM9H90g_E)
-- [Sebastian Brunemeier - DeSciによる生体医学研究 & ベンチャーキャピタルの転換](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
-- [Paige Donner - Web3とブロックチェーンによるオープンサイエンスのツール化](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s)
+- [Vitalik Buterinと科学者Aubrey de Greyの対談: 長寿研究と暗号通貨の交差点](https://www.youtube.com/watch?v=x9TSJK1widA)
+- 科学出版は破綻している。 Web3はそれを修正できるか?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
+- [Juan Benet - DeSci、独立研究室、大規模データサイエンス](https://www.youtube.com/watch?v=zkXM9H90g_E)
+- [Sebastian Brunemeier - DeSciはいかにして生物医学研究とベンチャーキャピタルを変革できるか](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
+- [Paige Donner - Web3とブロックチェーンによるオープンサイエンスのツーリング](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s)
diff --git a/public/content/translations/ja/developers/docs/accounts/index.md b/public/content/translations/ja/developers/docs/accounts/index.md
index e638d0c0488..5e7a041ee2d 100644
--- a/public/content/translations/ja/developers/docs/accounts/index.md
+++ b/public/content/translations/ja/developers/docs/accounts/index.md
@@ -1,28 +1,28 @@
---
-title: イーサリアムアカウント
-description: イーサリアムアカウントの説明 - データ構造、鍵ペア暗号技術との関係
+title: "イーサリアムアカウント"
+description: "イーサリアムアカウントの説明 - データ構造、鍵ペア暗号技術との関係"
lang: ja
---
-イーサリアムアカウントとは、イーサリアム上でトランザクションを送信できるEther(ETH)残高を持つエンティティです。 アカウントはユーザーが管理し、スマートコントラクトとしてデプロイすることができます。
+イーサリアムアカウントは、イーサ(ETH)残高を持ち、イーサリアム上でメッセージを送信できるエンティティです。 アカウントはユーザーが管理し、スマートコントラクトとしてデプロイすることができます。
-## 前提知識 {#prerequisites}
+## 前提条件 {#prerequisites}
-このページをよりよく理解するためには、[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。
+このページをよりよく理解するために、まず[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。
## アカウントの種類 {#types-of-account}
イーサリアムには2種類のアカウントがあります。
- 外部所有アカウント(EOA) – 秘密鍵の保有者により管理
-- コントラクトアカウント – ネットワークにデプロイされたスマートコントラクトでコードにより制御される。 [スマートコントラクト](/developers/docs/smart-contracts/)の詳細
+- コントラクトアカウント – ネットワークにデプロイされたスマートコントラクトでコードにより制御される。 [スマートコントラクト](/developers/docs/smart-contracts/)について学ぶ
両方のアカウントで次のことができます。
- ETHやトークンの受信、保有、送信
- 展開されたスマートコントラクトとのやりとり
-### 主な相違点 {#key-differences}
+### 主な違い {#key-differences}
**外部所有アカウント**
@@ -31,10 +31,10 @@ lang: ja
- 外部所有アカウント間のトランザクションは、ETHやトークンの送金のみ可能
- アカウントの活動をコントロールする公開鍵と秘密鍵という暗号鍵のペアで構成
-**コントラクトアカウント**
+**コントラクト**
- コントラクト作成は有償(ネットワークストレージを使用するため)
-- トランザクションの受信に応じてのみ、トランザクションを送信可能
+- トランザクションを受信することに対してのみメッセージを送信可能
- 外部アカウントからコントラクトアカウントへのトランザクションは、トークンの転送や新しいコントラクト作成まで、さまざまなアクションを実行するコードをトリガー可能
- コントラクトアカウントには秘密鍵がなく スマートコントラクトのコードのロジックによって制御される
@@ -42,14 +42,15 @@ lang: ja
イーサリアムアカウントには4つのフィールドがあります。
-- `nonce` – カウンターで、外部所有アカウントから送信されたトランザクションの数、あるいはコントラクトアカウントによって作成されたコントラクトの数を表します。 各アカウントは、既定のnonceを持つトランザクションを1回だけ実行するように設計されています。これにより、署名済みのトランザクションが繰り返しブロードキャスト、再実行されるリプレイ攻撃を防いでいます。
-- `balance` - アドレスが所有するwei額。 weiはETHの最小単位で、1ETHは1e+18wei。
-- `codeHash` - このハッシュは、イーサリアム仮想マシン(EVM)のアカウントの_コード_を指す。 コントラクトアカウントには、さまざまな操作を行えるコードの断片がプログラムされており、 このEVMコードはアカウントにメッセージ呼び出しがあった場合に実行される。 他のアカウントのフィールドとは異なり、変更することはできない。 このようなコードの断片はすべて、対応するハッシュの状態データベースに含まれ、後で取得可能。 このハッシュ値がcodeHashとして知られている。 外部所有アカウントの場合、codeHashフィールドは空の文字列のハッシュとなる。
-- `storageRoot` – ストレージハッシュとも呼ばれる。 アカウントのストレージ内容をコード化するMerkle Patriciaツリーのルートノードの256ビットハッシュ(256ビット整数値間のマッピング)で、256ビット整数キーのKeccak 256ビットハッシュからRLPエンコードされた256ビット整数値へのマッピングとしてデジタルツリーの中へコード化される。 このツリーは、このアカウントのストレージコンテンツのハッシュであり、デフォルトは空です。
+- `nonce` – 外部所有アカウントから送信されたトランザクションの数、またはコントラクトアカウントによって作成されたコントラクトの数を示すカウンター。 各アカウントは、既定のnonceを持つトランザクションを1回だけ実行するように設計されています。これにより、署名済みのトランザクションが繰り返しブロードキャスト、再実行されるリプレイ攻撃を防いでいます。
+- `balance` – このアドレスが所有するweiの数。 weiはETHの最小単位で、1ETHは1e+18wei。
+- `codeHash` – このハッシュは、イーサリアム仮想マシン(EVM)のアカウントの_コード_を指します。 コントラクトアカウントには、さまざまな操作を行えるコードの断片がプログラムされており、 このEVMコードはアカウントにメッセージ呼び出しがあった場合に実行される。 他のアカウントのフィールドとは異なり、変更することはできない。 このようなコードの断片はすべて、対応するハッシュの状態データベースに含まれ、後で取得可能。 このハッシュ値がcodeHashとして知られている。 外部所有アカウントの場合、codeHashフィールドは空の文字列のハッシュとなる。
+- `storageRoot` – ストレージハッシュとも呼ばれます。 アカウントのストレージ内容(256ビット整数値間のマッピング)をエンコードする[マークルパトリシアトライ](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)のルートノードの256ビットハッシュであり、256ビット整数キーのKeccak-256ハッシュからRLPエンコードされた256ビット整数値へのマッピングとしてトライにエンコードされます。 このツリーは、このアカウントのストレージコンテンツのハッシュであり、デフォルトは空です。
- _ [イーサリアムEVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)からの図解_
+
+_図は[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)を参考に作成_
-## 外部所有アカウントと鍵のペア {#externally-owned-accounts-and-key-pairs}
+## 外部所有アカウントと鍵ペア {#externally-owned-accounts-and-key-pairs}
アカウントは、公開鍵と秘密鍵の暗号鍵のペアで構成されています。 トランザクションが送信者によって実際に署名されていることを証明し、偽造を防ぐためです。 秘密鍵はトランザクションの署名に使用されるもので、アカウントに紐づく資金を管理する権限を与えます。 暗号通貨を実際に保有することはなく、秘密鍵を保有するだけで、資金は常にイーサリアム台帳にあります。
@@ -63,36 +64,36 @@ lang: ja
秘密鍵は64文字で構成されており、パスワードで暗号化することができます。
-例:
+例:
`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f`
-公開鍵は、秘密鍵から[楕円曲線DSA](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)を用いて生成されます。 公開鍵のkeccak-256ハッシュの末尾20バイトに`0x` を先頭に追加することで、アカウントの公開アドレスを取得できます。
+公開鍵は、[楕円曲線デジタル署名アルゴリズム](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)を用いて秘密鍵から生成されます。 アカウントの公開アドレスは、公開鍵のKeccak-256ハッシュの最後の20バイトを取り出し、先頭に「0x」を付加することで得られます。
-これにより、外部所有アカウント (EOA) は42文字のアドレスを持ちます (20バイトのセグメントの40文字の16進数と `0x` のプレフィックスから成ります) 。
+これは、外部所有アカウント(EOA)のアドレスが42文字(20バイトのセグメントである40の16進文字に、プレフィックス「0x」を加えたもの)であることを意味します。
-例:
+例:
`0x5e97870f263700f46aa00d967821199b9bc5a120`
-次の例は、[Clef](https://geth.ethereum.org/docs/tools/clef/introduction) というサインツールで、新しいアカウントを生成する方法です。 Clefは、イーサリアムクライアントの[Geth](https://geth.ethereum.org)に含まれる、アカウント管理および署名ツールです。 `clef newaccount`コマンドは、新しい鍵ペアを作成して、暗号化された鍵ストアに保存します。
+以下の例では、[Clef](https://geth.ethereum.org/docs/tools/clef/introduction)という署名ツールを使って新しいアカウントを生成する方法を説明します。 Clefは、イーサリアムクライアントである[Geth](https://geth.ethereum.org)にバンドルされているアカウント管理・署名ツールです。 `clef newaccount`コマンドは、新しい鍵ペアを作成し、暗号化されたキーストアに保存します。
```
> clef newaccount --keystore
-Please enter a password for the new account to be created:
+作成する新しいアカウントのパスワードを入力してください:
>
------------
-INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please remember your password!
-Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
+INFO [10-28|16:19:09.156] 新しい鍵が生成されました address=0x5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] 鍵ファイルをバックアップしてください path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] パスワードを忘れないでください!
+生成されたアカウント 0x5e97870f263700f46aa00d967821199b9bc5a120
```
-[GETHのドキュメント](https://geth.ethereum.org/docs)
+[Gethドキュメンテーション](https://geth.ethereum.org/docs)
-秘密鍵から新しい公開鍵を生成することは可能ですが、公開鍵から秘密鍵を生成することはできません。 秘密鍵を安全に保つことは非常に重要であり、その名の通り**秘密**にしておくべきです。
+秘密鍵から新しい公開鍵を生成することは可能ですが、公開鍵から秘密鍵を生成することはできません。 秘密鍵を安全に保管し、その名の通り**秘密**にしておくことが極めて重要です。
署名を出力するメッセージとトランザクションに署名するには秘密鍵が必要です。 他者はそのメッセージの発信者を証明するための署名を取り出すことができます。 アプリケーション内では、JavaScriptライブラリを使用してネットワークにトランザクションを送信できます。
@@ -100,19 +101,19 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
コントラクトアカウントも、 42文字の16進数のアドレスを持っています。
-例:
+例:
`0x06012c8cf97bead5deae237070f9587f8e7a266d`
通常、コントラクトアドレスは、コントラクトがイーサリアムブロックチェーンにデプロイされるときに与えられます。 アドレスは作成者のアドレスとそのアドレスから送信されたトランザクション数(nonce)から作られます。
-## バリデータ鍵 {#validators-keys}
+## バリデータキー {#validators-keys}
イーサリアムにはもう1種類の鍵があり、これはイーサリアムがプルーフ・オブ・ワークからプルーフ・オブ・ステークに基づくコンセンサスに切り替えた際に導入されたものです。 「BLS」鍵で、バリデータを識別するために使用されます。 これらの鍵は効率的に集約され、ネットワークがコンセンサスに至るまでに必要な帯域幅を削減できます。 この鍵集約がなければ、バリデータの最小ステーク額ははるかに高くなってしまいます。
-[バリデータ鍵の詳細](/developers/docs/consensus-mechanisms/pos/keys/)
+[バリデータキーの詳細](/developers/docs/consensus-mechanisms/pos/keys/)
-## ウォレットについて {#a-note-on-wallets}
+## ウォレットに関する注記 {#a-note-on-wallets}
アカウントはウォレットではありません。 ウォレットは、イーサリアムのアカウント(外部所有アカウントまたはコントラクトアカウント)とやり取りするためのインターフェースやアプリケーションです。
@@ -124,11 +125,11 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
-## 参考文献 {#further-reading}
+## 参考リンク {#further-reading}
-- [イーサリアムアカウントについて理解する](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan
+- [イーサリアムアカウントの理解](https://info.etherscan.com/understanding-ethereum-accounts/) - Etherscan
-_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_
+_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_
## 関連トピック {#related-topics}
diff --git a/public/content/translations/ja/developers/docs/apis/backend/index.md b/public/content/translations/ja/developers/docs/apis/backend/index.md
index 4183389e222..fd8a2ee761a 100644
--- a/public/content/translations/ja/developers/docs/apis/backend/index.md
+++ b/public/content/translations/ja/developers/docs/apis/backend/index.md
@@ -1,66 +1,71 @@
---
-title: バックエンドAPIライブラリ
-description: アプリケーションからブロックチェーンへやりとりできるイーサリアムクライアントAPIの紹介。
+title: "バックエンドAPIライブラリ"
+description: "アプリケーションからブロックチェーンへやりとりできるイーサリアムクライアントAPIの紹介。"
lang: ja
---
-ソフトウェアアプリケーションがイーサリアムブロックチェーンとやりとりを行うには (例: ブロックチェーンデータの読み込み、トランザクションの送信など) 、イーサリアムノードに接続する必要があります。
+ソフトウェアアプリケーションがイーサリアムブロックチェーンとやりとりを行うには(つまり、ブロックチェーンデータの読み込みやネットワークへのトランザクションの送信)、イーサリアムノードに接続する必要があります。
-この目的のために、すべてのイーサリアムクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)の仕様を実装しています。そのため、アプリケーションは統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットを使用できます。
+この目的のために、すべてのイーサリアムクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)仕様を実装しているため、アプリケーションが信頼して利用できる統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットが用意されています。
もし特定のプログラミング言語を使用してイーサリアムノードに接続したい場合には、独自のソリューションのほかに公開されている既存のライブライを使用することでより簡単に実装できます。 これらのライブラリにより、デベロッパーは直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを (内部的に) 初期化できるようになります。
-## 前提知識 {#prerequisites}
+## 前提条件 {#prerequisites}
-[イーサリアムスタック](/developers/docs/ethereum-stack/) と [イーサリアムクライアント](/developers/docs/nodes-and-clients/)も内容を理解するのに役立ちます。
+[イーサリアムスタック](/developers/docs/ethereum-stack/)と[イーサリアムクライアント](/developers/docs/nodes-and-clients/)を理解しておくと、役立つでしょう。
## ライブラリの利点 {#why-use-a-library}
-これらのライブラリは、イーサリアムノードと直接やり取りする複雑な大部分を抽象化します。 また、ユーティリティ関数 (ETHをGweiに変換する関数など) も提供されています。そのため、デベロッパーは複雑なイーサリアムクライアントの作業に費やす時間を削減でき、自身のアプリケーションの独自機能の開発作業に専念できます。
+これらのライブラリにより、イーサリアムノードと直接やり取りする際の複雑さが抽象化されます。 また、ユーティリティ関数(例: ETHからGweiへの変換)も提供されているため、開発者はイーサリアムクライアントの複雑な処理に費やす時間を減らし、アプリケーション独自の機能に集中できます。
## 利用可能なライブラリ {#available-libraries}
### インフラストラクチャとノードサービス {#infrastructure-and-node-services}
-**Alchemy -** **_イーサリアム開発プラットフォーム_**
+**Alchemy -** **_Ethereum開発プラットフォーム。_**
- [alchemy.com](https://www.alchemy.com/)
-- [ドキュメント](https://docs.alchemy.com/)
+- [ドキュメント](https://www.alchemy.com/docs/)
- [GitHub](https://github.com/alchemyplatform)
- [Discord](https://discord.com/invite/alchemyplatform)
-**All That Node -** **_ノード・アズ・ア・サービス_**
+**All That Node -** **_サービスとしてのノード。_**
- [All That Node.com](https://www.allthatnode.com/)
- [ドキュメント](https://docs.allthatnode.com)
- [Discord](https://discord.gg/GmcdVEUbJM)
-**Blast by Bware Labs -** **_イーサリアムメインネットとテストネットのための分散型API_**
+**Blast by Bware Labs -** **_イーサリアムメインネットおよびテストネット用の分散型API。_**
- [blastapi.io](https://blastapi.io/)
- [ドキュメント](https://docs.blastapi.io)
-- [Discord](https://discord.gg/bwarelabs)
+- [Discord](https://discord.gg/SaRqmRUjjQ)
-**BlockPi -** **_より効率的かつ高速なRPCサービスを提供_**
+**BlockPi -** **_より効率的で高速なRPCサービスを提供_**
- [blockpi.io](https://blockpi.io/)
- [ドキュメント](https://docs.blockpi.io/)
- [GitHub](https://github.com/BlockPILabs)
- [Discord](https://discord.com/invite/xTvGVrGVZv)
-**Cloudflareのイーサリアムゲートウェイ**
+**Cloudflareイーサリアムゲートウェイ。**
- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/)
**Etherscan - ブロックエクスプローラーおよびトランザクションAPI**
+
- [ドキュメント](https://docs.etherscan.io/)
-**GetBlock-** **_Web3開発用のBlockchain-as-a-service_**
+**Blockscout - オープンソースブロックエクスプローラー**
+
+- [ドキュメント](https://docs.blockscout.com/)
+
+**GetBlock -** **_Web3開発向けのサービスとしてのブロックチェーン_**
- [GetBlock.io](https://getblock.io/)
-- [ドキュメント](https://getblock.io/docs/)
+- [ドキュメント](https://docs.getblock.io/)
-**Infura -** **_アズ・ア・サービス型のイーサリアムAPI_**
+**Infura -** **_サービスとしてのイーサリアムAPI。_**
- [infura.io](https://infura.io)
- [ドキュメント](https://docs.infura.io/api)
@@ -71,24 +76,24 @@ lang: ja
- [noderpc.xyz](https://www.noderpc.xyz/)
- [ドキュメント](https://docs.noderpc.xyz/node-rpc)
-**NOWNodes - _フルノードとブロックエクスプローラー_**
+**NOWNodes - _フルノードとブロックエクスプローラー。_**
- [NOWNodes.io](https://nownodes.io/)
-- [ドキュメント](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro)
+- [ドキュメント](https://nownodes.gitbook.io/documentation)
-**QuickNode -** **_アズ・ア・サービス型のブロックチェーンインフラストラクチャ_**
+**QuickNode -** **_サービスとしてのブロックチェーンインフラストラクチャ。_**
- [quicknode.com](https://quicknode.com)
- [ドキュメント](https://www.quicknode.com/docs/welcome)
- [Discord](https://discord.gg/quicknode)
-**Rivet -** **_オープンソースソフトウェアを搭載した、アズ・ア・サービス型のイーサリアムとイーサリアムクラシックのAPI_**
+**Rivet -** **_オープンソースソフトウェアを搭載した、サービスとしてのイーサリアムおよびイーサリアムクラシックAPI。_**
- [rivet.cloud](https://rivet.cloud)
- [ドキュメント](https://rivet.cloud/docs/)
- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment)
-**Zmok -** **_JSON-RPC/WebSocket APIとしてのスピード重視のイーサリアムノード_**
+**Zmok -** **_速度を重視した、JSON-RPC/WebSockets APIとしてのイーサリアムノード。_**
- [zmok.io](https://zmok.io/)
- [GitHub](https://github.com/zmok-io)
@@ -97,32 +102,32 @@ lang: ja
### 開発ツール {#development-tools}
-**ethers-kt -** **_EVMベースのブロックチェーン用の非同期、ハイパフォーマンスのKotlin/Java/Androidライブラリ_**
+**ethers-kt -** **_EVMベースのブロックチェーン向けの、非同期で高性能なKotlin/Java/Androidライブラリ。_**
- [GitHub](https://github.com/Kr1ptal/ethers-kt)
-- [実例:](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
+- [サンプル](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
- [Discord](https://discord.gg/rx35NzQGSb)
-**Nethereum -** **_オープンソースのブロックチェーン用.NET統合ライブラリ_**
+**Nethereum -** **_ブロックチェーン向けのオープンソース.NET統合ライブラリ。_**
- [GitHub](https://github.com/Nethereum/Nethereum)
- [ドキュメント](http://docs.nethereum.com/en/latest/)
- [Discord](https://discord.com/invite/jQPrR58FxX)
-**Python Tooling -** **_Pythonでイーサリアムとやり取りするための各種ライブラリ_**
+**Python Tooling -** **_Pythonでイーサリアムと対話するための各種ライブラリ。_**
-- [py.ethereum.org](https://python.ethereum.org/)
+- [py.ethereum.org](https://snakecharmers.ethereum.org/)
- [web3.py GitHub](https://github.com/ethereum/web3.py)
-- [web3.pyチャット](https://gitter.im/ethereum/web3.py)
+- [web3.py Chat](https://gitter.im/ethereum/web3.py)
-**Tatum -** **_究極のブロックチェーン開発プラットフォーム_**
+**Tatum -** **_究極のブロックチェーン開発プラットフォーム。_**
- [Tatum](https://tatum.io/)
- [GitHub](https://github.com/tatumio/)
- [ドキュメント](https://docs.tatum.io/)
- [Discord](https://discord.gg/EDmW3kjTC9)
-**web3j -** **_イーサリアム用のJava/Android/Kotlin/Scalaの統合ライブラリ_**
+**web3j -** **_イーサリアム向けのJava/Android/Kotlin/Scala統合ライブラリ。_**
- [GitHub](https://github.com/web3j/web3j)
- [ドキュメント](https://docs.web3j.io/)
@@ -130,34 +135,34 @@ lang: ja
### ブロックチェーンサービス {#blockchain-services}
-**BlockCypher -** **_イーサリアム Web API_**
+**BlockCypher -** **_イーサリアムWeb API。_**
- [blockcypher.com](https://www.blockcypher.com/)
- [ドキュメント](https://www.blockcypher.com/dev/ethereum/)
-**Chainbase -** **_イーサリアム向けのオールインワンWeb3データインフラストラクチャ_**
+**Chainbase -** **_イーサリアム向けのオールインワンWeb3データインフラストラクチャ。_**
- [chainbase.com](https://chainbase.com/)
- [ドキュメント](https://docs.chainbase.com/)
- [Discord](https://discord.gg/Wx6qpqz4AF)
-**Chainstack -** **_柔軟性の高い、専用のアズ・ア・サービス型イーサリアムノード_**
+**Chainstack -** **_柔軟で専用の、サービスとしてのイーサリアムノード。_**
- [chainstack.com](https://chainstack.com)
-- [ドキュメンテーション](https://docs.chainbase.com/docs)
+- [ドキュメント](https://docs.chainstack.com/)
- [イーサリアムAPIリファレンス](https://docs.chainstack.com/reference/ethereum-getting-started)
-**Coinbase Cloud Node -** **_ブロックチェーンインフラストラクチャAPI_**
+**Coinbase Cloud Node -** **_ブロックチェーンインフラストラクチャAPI。_**
-- [Coinbase Cloud Node](https://www.coinbase.com/cloud)
-- [ドキュメンテーション](https://docs.cloud.coinbase.com/)
+- [Coinbase Cloud Node](https://www.coinbase.com/developer-platform)
+- [ドキュメント](https://docs.cdp.coinbase.com/)
-**Figment社が提供するDataHub -** **_イーサリアムプロトコル(メインネットとテストネット)を使用したWeb3 APIサービス_**
+**DataHub by Figment -** **_イーサリアムメインネットおよびテストネット対応のWeb3 APIサービス。_**
- [DataHub](https://www.figment.io/)
- [ドキュメント](https://docs.figment.io/)
-**Moralis -** **_エンタープライズグレードのEVM APIプロバイダ_**
+**Moralis -** **_エンタープライズグレードのEVM APIプロバイダー。_**
- [moralis.io](https://moralis.io)
- [ドキュメント](https://docs.moralis.io/)
@@ -165,43 +170,42 @@ lang: ja
- [Discord](https://moralis.io/joindiscord/)
- [フォーラム](https://forum.moralis.io/)
-**NFTPort -** **_イーサリアムデータとミントAPI_**
+**NFTPort -** **_イーサリアムのデータおよびミントAPI。_**
- [nftport.xyz](https://www.nftport.xyz/)
- [ドキュメント](https://docs.nftport.xyz/)
- [GitHub](https://github.com/nftport/)
- [Discord](https://discord.com/invite/K8nNrEgqhE)
-**Tokenview -** **_ジェネラルなマルチクリプトブロックチェーンAPIプラットフォーム_**
+**Tokenview -** **_汎用マルチクリプト・ブロックチェーンAPIプラットフォーム。_**
- [services.tokenview.io](https://services.tokenview.io/)
- [ドキュメント](https://services.tokenview.io/docs?type=api)
- [GitHub](https://github.com/Tokenview)
-**Watchdata -** **_イーサリアムブロックチェーンへのシンプルで信頼性の高いAPIアクセス_**
+**Watchdata -** **_イーサリアムブロックチェーンへの、シンプルで信頼性の高いAPIアクセスを提供。_**
- [Watchdata](https://watchdata.io/)
- [ドキュメント](https://docs.watchdata.io/)
- [Discord](https://discord.com/invite/TZRJbZ6bdn)
-**Covalent -** **_200以上のチェーンで使えるリッチなブロックチェーンAPI_**
+**Covalent -** **_200以上のチェーンに対応した、豊富なブロックチェーンAPI。_**
- [covalenthq.com](https://www.covalenthq.com/)
- [ドキュメント](https://www.covalenthq.com/docs/api/)
- [GitHub](https://github.com/covalenthq)
- [Discord](https://www.covalenthq.com/discord/)
+## 参考リンク {#further-reading}
-## 参考文献 {#further-reading}
-
-_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_
+_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_
## 関連トピック {#related-topics}
-- [ ノードとクライアント](/developers/docs/nodes-and-clients/)
+- [ノードとクライアント](/developers/docs/nodes-and-clients/)
- [開発フレームワーク](/developers/docs/frameworks/)
## 関連チュートリアル {#related-tutorials}
-- [Javascriptでイーサリアムブロックチェーンを使用するためのWeb3jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップするための手順。_
-- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使って、JavaScriptからスマートコントラクトを呼び出す方法を確認する。_
+- [JavaScriptでイーサリアムブロックチェーンを使用するためのWeb3.jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップする手順。_
+- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使用して、JavaScriptからコントラクト関数を呼び出す方法を説明します。_
diff --git a/public/content/translations/ja/developers/docs/apis/javascript/index.md b/public/content/translations/ja/developers/docs/apis/javascript/index.md
index 5c282bdc3db..e767afdc115 100644
--- a/public/content/translations/ja/developers/docs/apis/javascript/index.md
+++ b/public/content/translations/ja/developers/docs/apis/javascript/index.md
@@ -1,41 +1,43 @@
---
-title: JavaScript APIライブラリ
-description: アプリケーションからブロックチェーンへやり取りできるJavaScriptクライアントライブラリの紹介。
+title: "JavaScript APIライブラリ"
+description: "アプリケーションからブロックチェーンへやり取りできるJavaScriptクライアントライブラリの紹介。"
lang: ja
---
-Webアプリはイーサリアムブロックチェーンとやりとりを行うために(例えば、ブロックチェーンデータの読み込みやトランザクションの送信など) 、イーサリアムノードに接続する必要があります。
+ウェブアプリがEthereumブロックチェーンと対話する(すなわち、ブロックチェーンデータの読み取りやネットワークへのトランザクション送信)には、Ethereumノードに接続する必要があります。
-この目的のために、すべてのイーサリアムクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)の仕様を実装しています。そのため、アプリケーションは統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットを使用できます。
+この目的のために、すべてのEthereumクライアントは[JSON-RPC](/developers/docs/apis/json-rpc/)仕様を実装しており、アプリケーションが利用できる統一された[メソッド](/developers/docs/apis/json-rpc/#json-rpc-methods)のセットが用意されています。
JavaScriptでイーサリアムノードに接続する場合、通常のJavaScriptを使用することは可能です。しかし、エコシステム内には、作業をより簡単にするいくつかの便利なライブラリがあります。 これらのライブラリにより、デベロッパーは直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを (内部的に) 初期化できるようになります。
-[マージ](/roadmap/merge/)以降は、ノードの実行には、実行クライアントとコンセンサスクライアントという2つのつながったイーサリアムソフトウェアが必要になることに注意してください。 必ず、ノードに実行クライアントとコンセンサスクライアントの両方が含まれるようにしてください。 ノードがローカルマシン上にない(ノードがAWSインスタンス上で動作しているなど)場合は、適宜、チュートリアルのIPアドレスをアップデートしてください。 詳細については、[ノードの実行](/developers/docs/nodes-and-clients/run-a-node/)ページをご覧ください。
+[マージ](/roadmap/merge/)以降は、ノードの実行には、実行クライアントとコンセンサスクライアントという2つの接続されたEthereumソフトウェアが必要になることに注意してください。 必ず、ノードに実行クライアントとコンセンサスクライアントの両方が含まれるようにしてください。 ご使用のノードがローカルマシン上にない場合(例:ノードがAWSインスタンス上で実行されている)、チュートリアルのIPアドレスを適宜更新してください。 詳細については、[ノードの実行](/developers/docs/nodes-and-clients/run-a-node/)に関するページをご覧ください。
-## 前提知識 {#prerequisites}
+## 前提条件 {#prerequisites}
-JavaScriptを理解している必要があります。また、[イーサリアムスタック](/developers/docs/ethereum-stack/)と[イーサリアムクライアント](/developers/docs/nodes-and-clients/)についても理解していることが推奨されます。
+JavaScriptを理解することに加えて、[Ethereumスタック](/developers/docs/ethereum-stack/)と[Ethereumクライアント](/developers/docs/nodes-and-clients/)を理解しておくと役立つでしょう。
## ライブラリの利点 {#why-use-a-library}
-これらのライブラリにより、イーサリアムノードと直接やり取りする際の複雑さが抽象化されます。 また、ユーティリティ関数 (ETHをGweiに変換する関数など) も提供されています。そのため、デベロッパーは複雑なイーサリアムクライアントの作業に費やす時間を削減でき、自身のアプリケーションの独自機能の開発作業に専念できます。
+これらのライブラリにより、イーサリアムノードと直接やり取りする際の複雑さが抽象化されます。 また、ユーティリティ関数(例: ETHからGweiへの変換)も提供されているため、開発者はイーサリアムクライアントの複雑な処理に費やす時間を減らし、アプリケーション独自の機能に集中できます。
## ライブラリの機能 {#library-features}
-### イーサリアムノードに接続 {#connect-to-ethereum-nodes}
+### Ethereumノードへの接続 {#connect-to-ethereum-nodes}
-providersライブラリを使用することで、JSON-RPC、INFURA、Etherscan、AlchemyまたはMetaMaskであっても、イーサリアムに接続してデータを読み取ることができます。
+providersライブラリを使用することで、JSON-RPC、INFURA、Etherscan、AlchemyまたはMetaMaskに関係なく、イーサリアムに接続してデータを読み取ることができます。
+
+> **警告:** Web3.jsは2025年3月4日にアーカイブされました。 [発表を読む](https://blog.chainsafe.io/web3-js-sunset/)。 新しいプロジェクトでは、[ethers.js](https://ethers.org)や[viem](https://viem.sh)のような代替ライブラリの使用を検討してください。
**Ethers.jsを使った例**
```js
-// A BrowserProvider wraps a standard Web3 provider, which is
-// what MetaMask injects as window.ethereum into each page
+// BrowserProviderは標準のWeb3プロバイダをラップしたもので、
+// MetaMaskが各ページにwindow.ethereumとしてインジェクトするものです
const provider = new ethers.BrowserProvider(window.ethereum)
-// The MetaMask plugin also allows signing transactions to
-// send ether and pay to change state within the blockchain.
-// For this, we need the account signer...
+// MetaMaskプラグインは、トランザクションに署名して
+// イーサを送信し、ブロックチェーン内の状態を変更するための支払いを行うこともできます。
+// そのためには、アカウントの署名者が必要です...
const signer = provider.getSigner()
```
@@ -68,41 +70,41 @@ var web3 = new Web3(
- ガスの推定値
- スマートコントラクトのイベント
- ネットワークID
-- その他
+- 等々。
-### ウォレットの機能 {#wallet-functionality}
+### ウォレット機能 {#wallet-functionality}
これらのライブラリは、ウォレットの作成、キーの管理、トランザクションへ署名を行います。
Ethers.jsを使った例
```js
-// Create a wallet instance from a mnemonic...
+// ニーモニックからウォレットインスタンスを作成...
mnemonic =
"announce room limb pattern dry unit scale effort smooth jazz weasel alcohol"
walletMnemonic = Wallet.fromPhrase(mnemonic)
-// ...or from a private key
+// ...または秘密鍵から
walletPrivateKey = new Wallet(walletMnemonic.privateKey)
walletMnemonic.address === walletPrivateKey.address
// true
-// The address as a Promise per the Signer API
+// Signer APIごとのPromiseとしてのアドレス
walletMnemonic.getAddress()
// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' }
-// A Wallet address is also available synchronously
+// ウォレットアドレスは同期的に利用することもできます
walletMnemonic.address
// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1'
-// The internal cryptographic components
+// 内部の暗号コンポーネント
walletMnemonic.privateKey
// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db'
walletMnemonic.publicKey
// '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64'
-// The wallet mnemonic
+// ウォレットのニーモニック
walletMnemonic.mnemonic
// {
// locale: 'en',
@@ -110,12 +112,12 @@ walletMnemonic.mnemonic
// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol'
// }
-// Note: A wallet created with a private key does not
-// have a mnemonic (the derivation prevents it)
+// 注: 秘密鍵で作成されたウォレットには
+// ニーモニックがありません (派生によりこれが妨げられるため)
walletPrivateKey.mnemonic
// null
-// Signing a message
+// メッセージへの署名
walletMnemonic.signMessage("Hello World")
// { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' }
@@ -124,34 +126,34 @@ tx = {
value: utils.parseEther("1.0"),
}
-// Signing a transaction
+// トランザクションへの署名
walletMnemonic.signTransaction(tx)
// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' }
-// The connect method returns a new instance of the
-// Wallet connected to a provider
+// connectメソッドは、プロバイダに接続された
+// ウォレットの新しいインスタンスを返します
wallet = walletMnemonic.connect(provider)
-// Querying the network
+// ネットワークへのクエリ
wallet.getBalance()
// { Promise: { BigNumber: "42" } }
wallet.getTransactionCount()
// { Promise: 0 }
-// Sending ether
+// イーサの送信
wallet.sendTransaction(tx)
```
-[全ドキュメントを読む](https://docs.ethers.io/v5/api/signer/#Wallet)
+[完全なドキュメントを読む](https://docs.ethers.io/v5/api/signer/#Wallet)
セットアップ後、以下が可能になります。
- アカウントの作成
- トランザクションの送信
- トランザクションへの署名
-- 等々...
+- 等々。
-### スマートコントラクト関数とのやり取り {#interact-with-smart-contract-functions}
+### スマートコントラクト関数との対話 {#interact-with-smart-contract-functions}
Javascriptクライアントライブラリを使用すると、コンパイルされたコントラクトのアプリケーションバイナリインタフェース (ABI) を読み取ることによって、アプリからスマートコントラクト関数を呼び出せるようになります。
@@ -164,7 +166,7 @@ contract Test {
uint a;
address d = 0x12345678901234567890123456789012;
- function Test(uint testInt) { a = testInt;}
+ constructor(uint testInt) { a = testInt;}
event Event(uint indexed b, bytes32 c);
@@ -211,13 +213,13 @@ contract Test {
- スマートコントラクトにトランザクションを送信し、メソッドを実行
- EVMでメソッド実行時にかかるガス代を見積もるためにコール
- コントラクトのデプロイ
-- 等々...
+- その他
### ユーティリティ関数 {#utility-functions}
ユーティリティ関数は、イーサリアムでの構築を少し簡単にする便利なショートカットです。
-ETHの値は、デフォルトでweiに設定されています。 1 ETHは、1,000,000,000,000,000,000,000,000,000,000,000,000 wei です。つまり、非常に巨大な数値を扱っているということです。 Etherは`web3.utils.toWei`によって、weiに変換されます。
+ETHの値は、デフォルトでweiに設定されています。 1 ETHは、1,000,000,000,000,000,000,000,000,000,000,000,000 wei です。つまり、非常に巨大な数値を扱っているということです。 `web3.utils.toWei`は、etherをWeiに変換します。
Ethers.jsで記述した場合は次のようになります:
@@ -232,59 +234,56 @@ ethers.utils.formatEther(balance)
// '2.337132817842795605'
```
-- [Web3jsのユーティリティ関数](https://docs.web3js.org/api/web3-utils)
-- [Ethersのユーティリティ関数](https://docs.ethers.io/v5/api/utils/)
+- [Web3jsユーティリティ関数](https://docs.web3js.org/api/web3-utils)
+- [Ethersユーティリティ関数](https://docs.ethers.org/v6/api/utils/)
## 利用可能なライブラリ {#available-libraries}
-**Web3.js -** **_イーサリアムのJavaScript API_**
+**Web3.js -** **_Ethereum JavaScript API_**
-- [ドキュメント](https://docs.web3js.org/)
-- [GitHub](https://github.com/ethereum/web3.js/)
+- [ドキュメンテーション](https://docs.web3js.org)
+- [GitHub](https://github.com/ethereum/web3.js)
-**Ethers.js -** **_JavaScriptとTypeScriptでの完全なイーサリアムウォレットの実装とユーティリティ_**
+**Ethers.js -** **_JavaScriptとTypeScriptにおける完全なEthereumウォレットの実装とユーティリティ。_**
-- [ドキュメント](https://docs.ethers.io/)
-- [GitHub](https://github.com/ethers-io/ethers.js/)
+- [Ethers.jsホーム](https://ethers.org/)
+- [ドキュメンテーション](https://docs.ethers.io)
+- [GitHub](https://github.com/ethers-io/ethers.js)
-**The Graph -** **_イーサリアムとIPFSのデータをインデックス化し、GraphQLを使用してクエリを実行するためのプロトコル_**
+**The Graph -** **_EthereumとIPFSのデータをインデックス化し、GraphQLを使用してクエリを実行するためのプロトコル。_**
-- [The Graph](https://thegraph.com/)
-- [Graph Explorer](https://thegraph.com/explorer/)
-- [ドキュメント](https://thegraph.com/docs/)
-- [GitHub](https://github.com/graphprotocol/)
+- [The Graph](https://thegraph.com)
+- [Graph Explorer](https://thegraph.com/explorer)
+- [ドキュメンテーション](https://thegraph.com/docs)
+- [GitHub](https://github.com/graphprotocol)
- [Discord](https://thegraph.com/discord)
-**light.js -** **_ライトクライアント向けに最適化された高位のリアクティブJSライブラリ_**
-
-- [GitHub](https://github.com/openethereum/js-libs/tree/master/packages/light.js)
+**Alchemy SDK -** **_強化されたAPIを備えたEthers.jsのラッパー。_**
-**Alchemyweb3 -** **_自動リトライと強化されたAPIを備えた、Web3.jsのラッパー_**
+- [ドキュメンテーション](https://www.alchemy.com/docs)
+- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js)
-- [ドキュメント](https://docs.alchemy.com/reference/api-overview)
-- [GitHub](https://github.com/alchemyplatform/alchemy-web3)
+**viem -** **_EthereumのためのTypeScriptインターフェース。_**
-**Alchemy NFT API -** **_所有権やメタデータ属性などのNFTデータを取得するためのAPI_**
-
-- [ドキュメント](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
-- [GitHub](https://github.com/alchemyplatform/alchemy-web3)
+- [ドキュメンテーション](https://viem.sh)
+- [GitHub](https://github.com/wagmi-dev/viem)
-**viem -** **_イーサリアム用のTypeScriptインターフェース。_**
+**Drift -** **_組み込みのキャッシュ、フック、テストモックを備えたTypeScriptメタライブラリ。_**
-- [ドキュメント](https://viem.sh)
-- [GitHub](https://github.com/wagmi-dev/viem)
+- [ドキュメンテーション](https://ryangoree.github.io/drift/)
+- [GitHub](https://github.com/ryangoree/drift/)
-## 参考文献 {#further-reading}
+## 参考リンク {#further-reading}
-_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_
+_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_
## 関連トピック {#related-topics}
-- [ ノードとクライアント](/developers/docs/nodes-and-clients/)
+- [ノードとクライアント](/developers/docs/nodes-and-clients/)
- [開発フレームワーク](/developers/docs/frameworks/)
## 関連チュートリアル {#related-tutorials}
-- [Javascriptでイーサリアムブロックチェーンを使用するためのWeb3jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップするための手順。_
-- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使って、JavaScriptからスマートコントラクトを呼び出す方法を確認する。_
-- [Web3とAlchemyを使用してトランザクションを送信する](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– バックエンドからトランザクションを送信するための段階的ガイド。_
+- [JavaScriptでイーサリアムブロックチェーンを使用するためのWeb3.jsのセットアップ](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– プロジェクトでweb3.jsをセットアップする手順。_
+- [JavaScriptからスマートコントラクトを呼び出す](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– DAIトークンを使用して、JavaScriptからコントラクト関数を呼び出す方法を説明します。_
+- [web3とAlchemyを使用したトランザクションの送信](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– バックエンドからトランザクションを送信するためのステップバイステップのウォークスルー。_
diff --git a/public/content/translations/ja/developers/docs/apis/json-rpc/index.md b/public/content/translations/ja/developers/docs/apis/json-rpc/index.md
index 54c178cd6a7..a91f6d1a06b 100644
--- a/public/content/translations/ja/developers/docs/apis/json-rpc/index.md
+++ b/public/content/translations/ja/developers/docs/apis/json-rpc/index.md
@@ -1,40 +1,40 @@
---
title: JSON-RPC API
-description: イーサリアムクライアント用のステートレスで軽量なリモートプロシージャコール(RPC)プロトコル。
+description: "イーサリアムクライアント用のステートレスで軽量なリモートプロシージャコール(RPC)プロトコル。"
lang: ja
---
ブロックチェーンデータの読み取りやネットワークへのトランザクションの送信など、ソフトウェアアプリケーションがイーサリアムブロックチェーンとやり取りするには、イーサリアムノードに接続する必要があります。
-そのため、すべての[イーサリアムクライアント](/developers/docs/nodes-and-clients/#execution-clients)は[JSON-RPC仕様](https://github.com/ethereum/execution-apis)を実装しており、ノードやクライアントの実装がどのようなものであっても、アプリケーションは統一されたメソッドのセットを使用できます。
+この目的のために、すべての[Ethereumクライアント](/developers/docs/nodes-and-clients/#execution-clients)は[JSON-RPC仕様](https://github.com/ethereum/execution-apis)を実装しているため、特定のノードやクライアントの実装に関係なく、アプリケーションが依拠できる統一されたメソッドセットが存在します。
[JSON-RPC](https://www.jsonrpc.org/specification)は、ステートレスで軽量なリモートプロシージャコール(RPC)プロトコルです。 いくつかのデータ構造とその処理に関するルールを定義しています。 トランスポートに依存しないため、同じプロセス内だけでなく、ソケット経由、HTTP経由など、さまざまなメッセージパッシング環境で利用できます。 データ形式としては、JSON(RFC 4627)を使用します。
-## クライアントの実装 {#client-implementations}
+## クライアント実装 {#client-implementations}
-各イーサリアムクライアントでは、JSON-RPC仕様を実装する際に異なるプログラミング言語を使用できます。 特定のプログラミング言語に関連する詳細については、各[クライアントのドキュメント](/developers/docs/nodes-and-clients/#execution-clients)を参照してください。 最新のAPIサポート情報についても、各クライアントのドキュメントを確認することをお勧めします。
+各イーサリアムクライアントでは、JSON-RPC仕様を実装する際に異なるプログラミング言語を使用できます。 特定のプログラミング言語に関する詳細については、個々の[クライアントのドキュメント](/developers/docs/nodes-and-clients/#execution-clients)を参照してください。 最新のAPIサポート情報についても、各クライアントのドキュメントを確認することをお勧めします。
## 便利なライブラリ {#convenience-libraries}
-JSON-RPC APIを介してイーサリアムクライアントと直接やり取りすることもできますが、dappデベロッパーの作業が多くの場合に簡単になるオプションもあります。 [JavaScript](/developers/docs/apis/javascript/#available-libraries)と[バックエンドAPI](/developers/docs/apis/backend/#available-libraries)には、JSON-RPC APIの上にラッパーを提供する多くのライブラリが存在します。 これらのライブラリを使用することで、デベロッパーは任意のプログラミング言語による直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを(内部的に)初期化できるようになります。
+JSON-RPC APIを介してイーサリアムクライアントと直接やり取りすることもできますが、dappデベロッパーの作業が多くの場合に簡単になるオプションもあります。 JSON-RPC API上にラッパーを提供する、多くの[JavaScript](/developers/docs/apis/javascript/#available-libraries)ライブラリや[バックエンドAPI](/developers/docs/apis/backend/#available-libraries)ライブラリが存在します。 これらのライブラリを使用することで、デベロッパーは任意のプログラミング言語による直感的な1行のメソッドを作成するだけで、イーサリアムとやり取りするJSON-RPCリクエストを(内部的に)初期化できるようになります。
## コンセンサスクライアントAPI {#consensus-clients}
-このページでは、主にイーサリアムの実行クライアントで使用されるJSON-RPC APIについて説明します。 しかし、コンセンサスクライアントには、ユーザーがノードについての情報のクエリを行えるRPC APIが用意されており、ビーコンブロック、ビーコンの状態、その他のコンセンサス関連の情報を直接ノードにリクエストできます。 このAPIについては 、[ビーコンAPIのウェブページ](https://ethereum.github.io/beacon-APIs/#/)に記載されています。
+このページでは、主にイーサリアムの実行クライアントで使用されるJSON-RPC APIについて説明します。 しかし、コンセンサスクライアントには、ユーザーがノードについての情報のクエリを行えるRPC APIが用意されており、ビーコンブロック、ビーコンの状態、その他のコンセンサス関連の情報を直接ノードにリクエストできます。 このAPIは[Beacon APIウェブページ](https://ethereum.github.io/beacon-APIs/#/)に文書化されています。
-内部APIは、ノード内のクライアント間通信にも使用されます。 つまり、コンセンサスクライアントと実行クライアントとの間のデータ交換を可能にします。 これは「Engine API」と呼ばれており、仕様は[Github](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)で参照できます。
+内部APIは、ノード内のクライアント間通信にも使用されます。 つまり、コンセンサスクライアントと実行クライアントとの間のデータ交換を可能にします。 これは「エンジンAPI」と呼ばれ、仕様は[GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)で入手できます。
-## 実行クライアントの仕様 {#spec}
+## 実行クライアント仕様 {#spec}
-[GitHub上でJSON-RPC APIの全仕様を確認しましょう](https://github.com/ethereum/execution-apis)。 このAPIは[Execution APIウェブページ](https://ethereum.github.io/execution-apis/api-documentation/)でドキュメント化されており、利用可能なすべてのメソッドを試すためのインスペクターも含まれています。
+[GitHubでJSON-RPC APIの全仕様を読む](https://github.com/ethereum/execution-apis)。 このAPIは、[Execution APIウェブページ](https://ethereum.github.io/execution-apis/)に文書化されており、利用可能なすべてのメソッドを試すためのインスペクターが含まれています。
-## 慣例 {#conventions}
+## 規約 {#conventions}
-### 16進数のエンコーディング {#hex-encoding}
+### 16進数値エンコーディング {#hex-encoding}
フォーマットされていないバイト配列とそのバイト数という、2つのキーデータ型がJSONで渡されます。 どちらも16進数エンコーディングで渡されますが、フォーマットの要件は異なります。
-#### バイト数 {#quantities-encoding}
+#### 数量 {#quantities-encoding}
バイト数(整数、数字)をエンコーディングする際は、接頭辞「0x」の16進数でエンコードするのが最も簡潔です。ただし、ゼロは「0x0」と表記する必要があります。
@@ -46,7 +46,7 @@ JSON-RPC APIを介してイーサリアムクライアントと直接やり取
- 誤り: 0x0400(先頭にゼロは入力できません)
- 誤り: ff(接頭辞は0xでなければなりません)
-### フォーマットされていないデータ {#unformatted-data-encoding}
+### 未フォーマットデータ {#unformatted-data-encoding}
フォーマットされていないデータ(バイト配列、アカウントアドレス、ハッシュ、バイトコード配列)をエンコードする場合、16進数としてエンコードし、接頭辞を「0x」とし、1バイトごとに2桁の16進数でエンコードします。
@@ -58,9 +58,9 @@ JSON-RPC APIを介してイーサリアムクライアントと直接やり取
- 誤り: 0xf0f0f(偶数でなければなりません)
- 誤り: 004200(接頭辞が0xでなければなりません)
-### デフォルトのブロックパラメータ {#default-block}
+### ブロックパラメータ {#block-parameter}
-以下のメソッドには、追加のデフォルトブロックパラメータがあります。
+以下のメソッドにはブロックパラメータがあります:
- [eth_getBalance](#eth_getbalance)
- [eth_getCode](#eth_getcode)
@@ -68,26 +68,26 @@ JSON-RPC APIを介してイーサリアムクライアントと直接やり取
- [eth_getStorageAt](#eth_getstorageat)
- [eth_call](#eth_call)
-イーサリアムの状態に作用するリクエストを行う場合は、最後のデフォルトブロックパラメータによってブロックの高さが決定します。
+Ethereumの状態を照会するリクエストが行われる際、指定されたブロックパラメータがブロックの高さを決定します。
-デフォルトブロックパラメータには、以下のオプションがあります。
+ブロックパラメータには、以下のオプションが使用できます:
- `HEX String` - 整数のブロック番号
-- `String "earliest"` - 最も古い/始まりのブロック
-- `String "latest"` - 最も新しい提案されたブロック
-- `String "safe"` - 最も新しい安全な先頭ブロック
-- `String "finalized"` - 最も新しい確定済みブロック
+- `String "earliest"` - 最古/ジェネシスブロック
+- `String "latest"` - 最新の提案されたブロック
+- `String "safe"` - 最新の安全なヘッドブロック
+- `String "finalized"` - 最新のファイナライズされたブロック
- `String "pending"` - 保留中の状態/トランザクション
-## 使用例
+## 実例:
-このページでは、コマンドラインツールである[curl](https://curl.se)を使用した、各JSON-RPC APIエンドポイントの使用方法の例を紹介します。 各エンドポイントの使用例は、[curlの使用例](#curl-examples)セクションで確認できます。 ページの下方には、Gethノード、JSON-RPC API、curlを使用したスマートコントラクトのコンパイルとデプロイの[エンドツーエンドの例](#usage-example)もあります。
+このページでは、コマンドラインツールである[curl](https://curl.se)を使用して、個々のJSON_RPC APIエンドポイントを使用する方法の例を示します。 これらの個々のエンドポイントの例は、以下の[Curlの例](#curl-examples)のセクションにあります。 さらにページの下部では、Gethノード、JSON_RPC API、curlを使用してスマートコントラクトをコンパイルし、デプロイするための[エンドツーエンドの例](#usage-example)も提供しています。
-## Curlの使用例 {#curl-examples}
+## Curlの例 {#curl-examples}
-以下に、[curl](https://curl.se)でイーサリアムノードへのリクエストを行うことによってJSON-RPC APIを使用する例をいくつか示します。 それぞれの例には、エンドポイントの説明、パラメータ、戻り値の型、使用方法の範例が含まれています。
+以下に、[curl](https://curl.se)を使用してEthereumノードにリクエストを行うことでJSON_RPC APIを使用する例を示します。 それぞれの例には、エンドポイントの説明、パラメータ、戻り値の型、使用方法の範例が含まれています。
-curlリクエストは、コンテンツタイプに関するエラーメッセージを返すことがあります。 この理由は、`--data`オプションによって、コンテンツタイプが`application/x-www-form-urlencoded`に設定されるためです。 これによってノードがエラーになる場合は、呼び出しの最初に、手動で`-H "Content-Type: application/json"`と記述してヘッダーを設定してください。 また、使用例には、curlで最後に指定する引数であるURL/IPとポートの組み合わせ(例: `127.0.0.1:8545`)が含まれていません 。 これらの追加データが含まれた完全なcurlリクエストは、次の形式になります。
+curlリクエストは、コンテンツタイプに関するエラーメッセージを返すことがあります。 これは、`--data`オプションがコンテントタイプを`application/x-www-form-urlencoded`に設定するためです。 もしノードがこれについて文句を言う場合は、呼び出しの最初に`-H "Content-Type: application/json"`を配置して、手動でヘッダーを設定してください。 また、この例には、curlに与える最後の引数でなければならないURL/IPとポートの組み合わせ(例: `127.0.0.1:8545`)は含まれていません。 これらの追加データが含まれた完全なcurlリクエストは、次の形式になります。
```shell
curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
@@ -95,7 +95,7 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho
## ゴシップ、状態、履歴 {#gossip-state-history}
-少数のコアJSON-RPCメソッドは、イーサリアムネットワークからのデータを必要とします。該当メソッドは、*ゴシップ、状態、履歴*という、3つの主要カテゴリーに明確に分類できます。 各メソッドは、セクションにあるリンクからジャンプするか、目次でメソッドの全リストを調べることで見つけられます。
+一部のコアJSON-RPCメソッドはEthereumネットワークからのデータを必要とし、_ゴシップ、状態、履歴_の3つの主要なカテゴリにきれいに分類されます。 各メソッドは、セクションにあるリンクからジャンプするか、目次でメソッドの全リストを調べることで見つけられます。
### ゴシップメソッド {#gossip-methods}
@@ -134,7 +134,7 @@ curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","metho
## JSON-RPC APIプレイグラウンド
-APIメソッドの発見と試用に[プレイグラウンドツール](https://ethereum-json-rpc.com)が使えます。 プレイグラウンドツールでは、さまざまなノードプロバイダーによってサポートされているメソッドとネットワークも表示されます。
+[プレイグラウンドツール](https://ethereum-json-rpc.com)を使用して、APIメソッドを発見し、試すことができます。 プレイグラウンドツールでは、さまざまなノードプロバイダーによってサポートされているメソッドとネットワークも表示されます。
## JSON-RPC APIメソッド {#json-rpc-methods}
@@ -148,7 +148,7 @@ APIメソッドの発見と試用に[プレイグラウンドツール](https://
**戻り値**
-`String` - 現在のクライアントのバージョン
+`String` - 現在のクライアントバージョン
**例**
@@ -165,7 +165,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],
### web3_sha3 {#web3_sha3}
-標準のSHA3-256ではなく、指定されたデータのKeccak-256__を返します。
+指定されたデータのKeccak-256 (標準化されたSHA3-256では_ない_)を返します。
**パラメータ**
@@ -177,14 +177,14 @@ params: ["0x68656c6c6f20776f726c64"]
**戻り値**
-`DATA` - 指定された文字列のSHA3結果
+`DATA` - 指定された文字列のSHA3結果。
**例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
-// Result
+// 結果
{
"id":64,
"jsonrpc": "2.0",
@@ -202,20 +202,20 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c
**戻り値**
-`String` - 現在のネットワークID
+`String` - 現在のネットワークID。
現在のネットワークIDの全リストは、[chainlist.org](https://chainlist.org)で入手できます。 よく使われるネットワークIDは、以下の通りです。
-- `1`: イーサリアムメインネット
+- `1`: Ethereumメインネット
- `11155111`: Sepoliaテストネット
-- `17000`: Hoodiテストネット
+- `560048` : Hoodiテストネット
**例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc": "2.0",
@@ -225,7 +225,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67
### net_listening {#net_listening}
-クライアントのネットワーク接続のリッスンがアクティブな場合に、`true`を返します。
+クライアントがネットワーク接続をアクティブにリッスンしている場合は`true`を返します。
**パラメータ**
@@ -233,14 +233,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67
**戻り値**
-`Boolean` - リッスンしている場合は`true`、その他の場合は`false`
+`Boolean` - リッスンしている場合は`true`、それ以外は`false`。
**例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc":"2.0",
@@ -258,14 +258,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":
**戻り値**
-`QUANTITY` - 接続されているピア数(整数)。
+`QUANTITY` - 接続されているピアの数の整数。
**例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
-// Result
+// 結果
{
"id":74,
"jsonrpc": "2.0",
@@ -275,7 +275,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":
### eth_protocolVersion {#eth_protocolversion}
-現在のイーサリアムプロトコルのバージョンを返します。 このメソッドは、[Gethでは利用できないこと](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)に注意してください。
+現在のイーサリアムプロトコルのバージョンを返します。 このメソッドは[Gethでは利用できない](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924)ことに注意してください。
**パラメータ**
@@ -283,14 +283,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":
**戻り値**
-`String` - 現在のイーサリアムプロトコルのバージョン
+`String` - 現在のEthereumプロトコルバージョン
**例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
-// Result
+// 結果
{
"id":67,
"jsonrpc": "2.0",
@@ -300,7 +300,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[]
### eth_syncing {#eth_syncing}
-同期ステータスに関するデータを含むオブジェクトか、`false`を返します。
+同期ステータスに関するデータを含むオブジェクト、または`false`を返します。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
@@ -308,13 +312,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[]
**戻り値**
-クライアント実装によって、厳密にはリターンデータが異なります。 ノードが同期していない場合、すべてのクライアントは`False`を返します。また、すべてのクライアントは次のフィールドを返します。
+クライアント実装によって、厳密にはリターンデータが異なります。 すべてのクライアントは、ノードが同期していない場合に`False`を返し、すべてのクライアントが以下のフィールドを返します。
-`Object|Boolean` - 同期ステータスデータを含むオブジェクト、または同期していない場合は`FALSE`
+`Object|Boolean`、同期ステータスデータを含むオブジェクト、または同期していない場合は`FALSE`:
-- `startingBlock`: `QUANTITY` - インポートを開始したブロック(同期がブロックの先頭に達したときのみリセットされる)
-- `currentBlock`: `QUANTITY` - 現在のブロックであり、eth_blockNumberと同一
-- `highestBlock`: `QUANTITY` - 最大ブロック高の推定値
+- `startingBlock`: `QUANTITY` - インポートが開始されたブロック(同期がヘッドに達した後にのみリセットされます)
+- `currentBlock`: `QUANTITY` - 現在のブロック、eth_blockNumberと同じ
+- `highestBlock`: `QUANTITY` - 推定される最も高いブロック
ただし、クライアントによっては、追加のデータを提供する場合もあります。 例えば、Gethでは以下のデータを返します。
@@ -386,6 +390,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
クライアントのコインベースアドレスを返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
+> **注:** このメソッドは**v1.14.0**で廃止され、サポートされなくなりました。 このメソッドを使用しようとすると、「メソッドはサポートされていません」というエラーが発生します。
+
**パラメータ**
なし
@@ -411,13 +421,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6
リプレイ保護されたトランザクションの署名に使われるチェーンIDを返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
なし
**戻り値**
-`chainId`、16進数の文字列で表された現在のチェーンIDの整数値。
+`chainId`、現在のチェーンIDの整数を表す16進値の文字列。
**例**
@@ -434,7 +448,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67
### eth_mining {#eth_mining}
-クライアントの新規ブロックのマイニングがアクティブな場合に、`true`を返します。 プルーフ・オブ・ワークのネットワークに対してのみ `true`を返します。[マージ](/roadmap/merge/)以降、一部のクライアントでは使用できない場合があります。
+クライアントが新しいブロックをアクティブにマイニングしている場合は`true`を返します。 これはプルーフオブワークのネットワークに対してのみtrueを返し、[マージ](/roadmap/merge/)以降、一部のクライアントでは利用できない場合があります。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
@@ -442,7 +460,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67
**戻り値**
-`Boolean` - クライアントがマイニングしている場合は`true`、その他の場合は`false`
+`Boolean` - クライアントがマイニングしている場合は`true`、それ以外は`false`を返します。
**例**
@@ -459,7 +477,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}
### eth_hashrate {#eth_hashrate}
-ノードがマイニングしている1秒あたりのハッシュの数を返します。 プルーフ・オブ・ワークのネットワークに対してのみ `true`を返します。[マージ](/roadmap/merge/)以降、一部のクライアントでは使用できない場合があります。
+ノードがマイニングしている1秒あたりのハッシュの数を返します。 これはプルーフオブワークのネットワークに対してのみtrueを返し、[マージ](/roadmap/merge/)以降、一部のクライアントでは利用できない場合があります。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
@@ -467,7 +489,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}
**戻り値**
-`QUANTITY` - 1秒あたりのハッシュの数
+`QUANTITY` - 1秒あたりのハッシュ数。
**例**
@@ -486,13 +508,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7
現在のガス価格の見積りをweiで返します。 例えば、Besuクライアントではデフォルトで、最新の100ブロックを検査し、ガスのユニット価格における中央値を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
なし
**戻り値**
-`QUANTITY` - 現在のガス価格(wei単位の整数)
+`QUANTITY` - wei単位での現在のガス価格の整数。
**例**
@@ -511,13 +537,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7
クライアントが所有するアドレスのリストを返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
なし
**戻り値**
-`DATA配列`、20バイト - クライアントが所有するアドレス
+`Array of DATA`、20バイト - クライアントが所有するアドレス。
**例**
@@ -534,7 +564,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1
### eth_blockNumber {#eth_blocknumber}
-最も新しいブロックの番号を返します。
+最新のブロック番号を返します。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
@@ -542,7 +576,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1
**戻り値**
-`QUANTITY` - クライアントの現在のブロックの番号(整数)
+`QUANTITY` - クライアントが現在いるブロック番号の整数。
**例**
@@ -561,10 +595,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id
指定されたアドレスのアカウントの残高を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `DATA`、20バイト - 残高を確認するアドレス
-2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
+1. `DATA`、20バイト - 残高を確認するアドレス。
+2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照
```js
params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
@@ -572,7 +610,7 @@ params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
**戻り値**
-`QUANTITY` - 現在の残高(wei単位の整数)
+`QUANTITY` - wei単位の現在の残高の整数。
**例**
@@ -591,30 +629,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407
指定されたアドレスのストレージの位置の値を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `DATA`、20バイト - ストレージのアドレス
-2. `QUANTITY` - ストレージの位置(整数)
-3. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
+1. `DATA`、20バイト - ストレージのアドレス。
+2. `QUANTITY` - ストレージ内の位置の整数。
+3. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照
**戻り値**
-`DATA` - このストレージの位置の値
+`DATA` - このストレージ位置の値。
-**例: ** 正確な位置計算は、取得するストレージによって変わります。 ここでは、アドレス`0x391694e7e0b0cce554cb130d723a9d27458f9298`で、`0x295a70b2de5e3953354a6a8344e616ed314d7251`にデプロイされているコントラクトについて考えます。
+**例**
+正しい位置の計算は、取得するストレージによって異なります。 アドレス`0x391694e7e0b0cce554cb130d723a9d27458f9298`によって、`0x295a70b2de5e3953354a6a8344e616ed314d7251`にデプロイされた以下のコントラクトについて考えてみましょう。
```
contract Storage {
uint pos0;
mapping(address => uint) pos1;
- function Storage() {
+ constructor() {
pos0 = 1234;
pos1[msg.sender] = 5678;
}
}
```
-pos0の値の取得は簡単です。
+pos0の値の取得は簡単です:
```js
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
@@ -656,12 +699,16 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [
### eth_getTransactionCount {#eth_gettransactioncount}
-アドレスから_送信_されたトランザクションの数を返します。
+アドレスから_送信された_トランザクションの数を返します。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
-1. `DATA`、20バイト - アドレス
-2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
+1. `DATA`、20バイト - アドレス。
+2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照
```js
params: [
@@ -672,7 +719,7 @@ params: [
**戻り値**
-`QUANTITY` - このアドレスから送信されたトランザクションの数(整数)
+`QUANTITY` - このアドレスから送信されたトランザクションの数の整数。
**例**
@@ -691,9 +738,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params
指定されたブロックハッシュに一致するブロック内のトランザクションの数を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `DATA`、32バイト - ブロックハッシュ
+1. `DATA`、32バイト - ブロックのハッシュ
```js
params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
@@ -701,7 +752,7 @@ params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
**戻り値**
-`QUANTITY` - このブロック内のトランザクションの数(整数)
+`QUANTITY` - このブロック内のトランザクションの数の整数。
**例**
@@ -720,9 +771,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa
指定されたブロック番号に一致するブロックのトランザクションの数を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
+1. `QUANTITY|TAG` - ブロック番号の整数、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`または`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。
```js
params: [
@@ -732,7 +787,7 @@ params: [
**戻り値**
-`QUANTITY` - このブロック内のトランザクションの数(整数)
+`QUANTITY` - このブロック内のトランザクションの数の整数。
**例**
@@ -751,9 +806,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu
指定されたブロックハッシュに一致するブロックのアンクルの数を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `DATA`、32バイト - ブロックハッシュ
+1. `DATA`、32バイト - ブロックのハッシュ
```js
params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
@@ -761,7 +820,7 @@ params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
**戻り値**
-`QUANTITY` - このブロック内のアンクルの数(整数)
+`QUANTITY` - このブロック内のアンクルの数の整数。
**例**
@@ -780,9 +839,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p
指定されたブロック番号に一致するブロック内のアンクルの数を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
+1. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照
```js
params: [
@@ -792,7 +855,7 @@ params: [
**戻り値**
-`QUANTITY` - このブロック内のアンクルの数(整数)
+`QUANTITY` - このブロック内のアンクルの数の整数。
**例**
@@ -811,10 +874,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber",
指定されたアドレスのコードを返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
1. `DATA`、20バイト - アドレス
-2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
+2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照
```js
params: [
@@ -825,7 +892,7 @@ params: [
**戻り値**
-`DATA` - 指定されたアドレスからのコード
+`DATA` - 指定されたアドレスからのコード。
**例**
@@ -842,9 +909,9 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA
### eth_sign {#eth_sign}
-この署名メソッドは、イーサリアム固有の署名を次のように計算します。`sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`。
+署名メソッドは、`sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`で、Ethereum固有の署名を計算します。
-メッセージに接頭辞を追加することで、計算された署名がイーサリアム固有の署名として認識されるようになります。 これにより、悪意のあるdappによって任意のデータ(トランザクションなど)が署名され、被害者のなりすましに悪用される被害を防ぐことができます。
+メッセージに接頭辞を追加することで、計算された署名がイーサリアム固有の署名として認識されるようになります。 これにより、悪意のあるdappが任意のデータ(トランザクションなど)に署名し、その署名を利用して被害者になりすますといった不正使用を防ぎます。
注: 署名するアドレスのロックを解除する必要があります。
@@ -872,24 +939,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d37
### eth_signTransaction {#eth_signtransaction}
-[eth_sendRawTransaction](#eth_sendrawtransaction)を使用して、ネットワークに後から送信可能なトランザクションに署名します。
+[eth_sendRawTransaction](#eth_sendrawtransaction)を使用して、後でネットワークに送信できるトランザクションに署名します。
**パラメータ**
1. `Object` - トランザクションオブジェクト
- `type`:
-- `from`: `DATA`、20バイト - トランザクションの送信元アドレス
-- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス
-- `gas`: `QUANTITY` - (オプション、デフォルトは90000)トランザクションを実行するために提供されているガス(整数)で、 使用されなかったガスは返却される
-- `gasPrice`: `QUANTITY` - (オプション、デフォルトは未確定)ガスごとに支払われるガス価格(wei単位の整数)
-- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値(wei単位の整数)
-- `data`: `DATA` - コンパイルされたコントラクトのコード。または呼び出されたメソッドの署名とエンコードされたパラメータのハッシュ
-- `nonce`: `QUANTITY` - (オプション)ノンス(nonce)の整数で、 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる
+- `from`: `DATA`、20バイト - トランザクションの送信元アドレス。
+- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス。
+- `gas`: `QUANTITY` - (オプション、デフォルト: 90000)トランザクションの実行に提供されるガスの整数。 使用されなかったガスは返却される
+- `gasPrice`: `QUANTITY` - (オプション、デフォルト: 未確定)支払われるガスごとに使用されるgasPriceの整数(Wei単位)。
+- `value`: `QUANTITY` - (オプション)このトランザクションで送信される値の整数(Wei単位)。
+- `data`: `DATA` - コントラクトのコンパイル済みコード、または呼び出されたメソッド署名のハッシュとエンコードされたパラメータ。
+- `nonce`: `QUANTITY` - (オプション)ノンスの整数。 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる
**戻り値**
-`DATA`、特定のアカウントによって署名され、RLPエンコードされたトランザクションオブジェクト。
+`DATA`、指定されたアカウントによって署名された、RLPエンコードされたトランザクションオブジェクト。
**例**
@@ -906,19 +973,19 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","
### eth_sendTransaction {#eth_sendtransaction}
-データフィールドにコードが含まれている場合は、新しいメッセージコールトランザクションまたはコントラクト作成を行います。また、`from`で指定されたアカウントを使ってデータフィールドに署名します。
+データフィールドにコードが含まれている場合は、新しいメッセージコールトランザクションまたはコントラクト作成を行い、`from`で指定されたアカウントを使ってそれに署名します。
**パラメータ**
1. `Object` - トランザクションオブジェクト
-- `from`: `DATA`、20バイト - トランザクションの送信元アドレス
-- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス
-- `gas`: `QUANTITY` - (オプション、デフォルトは90000)トランザクションを実行するために提供されているガス(整数)で、 使用されなかったガスは返却される
-- `gasPrice`: `QUANTITY` - (オプション、デフォルトは未確定)ガスの支払いに適用されたガス価格(整数)
-- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値(整数)
-- `input`: `DATA` - コンパイルされたコントラクトのコード。または呼び出されたメソッドの署名とエンコードされたパラメータのハッシュ
-- `nonce`: `QUANTITY` - (オプション)ノンス(nonce)の整数で、 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる
+- `from`: `DATA`、20バイト - トランザクションの送信元アドレス。
+- `to`: `DATA`、20バイト - (新規コントラクトの作成時はオプション)トランザクションの宛先アドレス。
+- `gas`: `QUANTITY` - (オプション、デフォルト: 90000)トランザクションの実行に提供されるガスの整数。 使用されなかったガスは返却される
+- `gasPrice`: `QUANTITY` - (オプション、デフォルト: 未確定)ガスの支払いに適用されるgasPriceの整数。
+- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値の整数。
+- `input`: `DATA` - コントラクトのコンパイル済みコード、または呼び出されたメソッド署名のハッシュとエンコードされたパラメータ。
+- `nonce`: `QUANTITY` - (オプション)ノンスの整数。 同じノンス(nonce)を使用している保留中のトランザクションを上書きできる
```js
params: [
@@ -936,9 +1003,9 @@ params: [
**戻り値**
-`DATA`、32バイト - トランザクションのハッシュ、またはトランザクションがまだ使用可能でない場合はゼロハッシュ
+`DATA`、32バイト - トランザクションハッシュ、またはトランザクションがまだ利用できない場合はゼロハッシュ。
-コントラクトを作成した際、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。
+コントラクトを作成した場合、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。
**例**
@@ -959,7 +1026,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{
**パラメータ**
-1. `DATA` - 署名されたトランザクションのデータ
+1. `DATA`、署名されたトランザクションデータ。
```js
params: [
@@ -969,9 +1036,9 @@ params: [
**戻り値**
-`DATA`、32バイト - トランザクションのハッシュ、またはトランザクションがまだ使用可能でない場合はゼロハッシュ
+`DATA`、32バイト - トランザクションハッシュ、またはトランザクションがまだ利用できない場合はゼロハッシュ。
-コントラクトを作成した際、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。
+コントラクトを作成した場合、トランザクションがブロックに提案された後、[eth_getTransactionReceipt](#eth_gettransactionreceipt)を使用してコントラクトアドレスを取得します。
**例**
@@ -988,24 +1055,28 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params"
### eth_call {#eth_call}
-ブロックチェーン上にトランザクションを作成せずに、即座に新規メッセージ呼び出しを実行できます。 読み取り専用のスマートコントラクト関数を実行するために頻繁に使われます(例えば、ERC-20 コントラクトの`balanceOf`など)。
+ブロックチェーン上にトランザクションを作成せずに、新しいメッセージコールを即座に実行します。 ERC-20コントラクトの`balanceOf`など、読み取り専用のスマートコントラクト関数を実行するためによく使用されます。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
-1. `Object` - トランザクションの呼び出しオブジェクト
+1. `Object` - トランザクションコールオブジェクト
-- `from`: `DATA`、20バイト - (オプション)トランザクションの送信元アドレス
-- `to`: `DATA`、20バイト - トランザクションの宛先アドレス
-- `gas`: `QUANTITY` - (オプション)トランザクションを実行するために提供されているガス(整数) 。 eth_callはガスを消費しませんが、一部の実行ではこのパラメータが必要になる場合があります。
-- `gasPrice`: `QUANTITY` - (オプション)ガスの支払いに適用されるガス価格(整数)
-- `value`: `QUANTITY` - (オプション)このトランザクションで送信された値(整数)
-- `input`: `DATA` - (オプション)メソッド署名とエンコードされたパラメータのハッシュ。 詳細については、[SolidityのドキュメントのイーサリアムコントラクトABI](https://docs.soliditylang.org/en/latest/abi-spec.html)を参照してください。
+- `from`: `DATA`、20バイト - (オプション)トランザクションの送信元アドレス。
+- `to`: `DATA`、20バイト - トランザクションの宛先アドレス。
+- `gas`: `QUANTITY` - (オプション)トランザクションの実行に提供されるガスの整数。 eth_callはガスを消費しませんが、一部の実行ではこのパラメータが必要になる場合があります。
+- `gasPrice`: `QUANTITY` - (オプション)支払われるガスごとに使用されるgasPriceの整数
+- `value`: `QUANTITY` - (オプション)このトランザクションで送信される値の整数
+- `input`: `DATA` - (オプション)メソッド署名とエンコードされたパラメータのハッシュ。 詳細については、[SolidityドキュメントのEthereum Contract ABI](https://docs.soliditylang.org/en/latest/abi-spec.html)を参照してください。
-2. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
+2. `QUANTITY|TAG` - 整数のブロック番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`または`"finalized"`。詳細は[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照
**戻り値**
-`DATA` - 実行されたコントラクトの戻り値
+`DATA` - 実行されたコントラクトの戻り値。
**例**
@@ -1024,13 +1095,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}]
トランザクションの完了に必要なガスの推定値を計算して返します。 このトランザクションはブロックチェーンに追加されません。 推定値は、EVMの仕組みやノードのパフォーマンスなどのさまざまな理由により、トランザクションによって実際に使われるガス量を大幅に上回る可能性があることに注意してください。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-[eth_call](#eth_call)パラメータを参照してください。ただし、すべてのプロパティはオプションです。 ガスリミットが指定されていない場合、Gethでは保留中のブロックのガスリミットが上限値として使用されます。 その結果、保留中のブロックのガスリミットよりガス量が多い場合には、返される推定値の量では、呼び出し/トランザクションを実行するには十分でないことがあります。
+[eth_call](#eth_call)パラメータを参照してください。ただし、すべてのプロパティはオプションです。 ガスリミットが指定されていない場合、Gethでは保留中のブロックのガスリミットが上限値として使用されます。 その結果、ガス量が保留中のブロックのガスリミットより高い場合、返された推定値ではコール/トランザクションの実行に十分でない可能性があります。
**戻り値**
-`QUANTITY` - ガス使用量
+`QUANTITY` - 使用されたガス量。
**例**
@@ -1049,10 +1124,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see
ハッシュを使用して、ブロックに関する情報を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `DATA`、32バイト - ブロックのハッシュ
-2. `Boolean` - `true`の場合は、完全なトランザクションオブジェクトを返します。 `false`の場合は、トランザクションのハッシュのみを返します
+1. `DATA`、32バイト - ブロックのハッシュ。
+2. `Boolean` - `true`の場合は完全なトランザクションオブジェクトを返し、`false`の場合はトランザクションのハッシュのみを返します。
```js
params: [
@@ -1063,39 +1142,38 @@ params: [
**戻り値**
-`Object` - ブロックオブジェクト、またはブロックが見つからなかった場合は`null`
-
-- `number`: `QUANTITY` - ブロック番号。 保留中のブロックの場合は`null`
-- `hash`: `DATA`、32バイト - ブロックのハッシュ。 保留中のブロックの場合は`null`
-- `parentHash`: `DATA`、32バイト - 親ブロックのハッシュ
-- `nonce`: `DATA`、8バイト - 生成されたプルーフ・オブ・ワークのハッシュ。 保留中のブロックの場合は`null`
-- `sha3Uncles`: `DATA`、32バイト - ブロックのアンクルデータのSHA3
-- `logsBloom`: `DATA`、256バイト - ブロックのログのブルームフィルタ。 保留中のブロックの場合は`null`
-- `transactionsRoot`: `DATA`、32バイト - ブロックのトランザクションツリーのルート
-- `stateRoot`: `DATA`、32バイト - ブロックの最終状態ツリーのルート
-- `receiptsRoot`: `DATA`、32バイト - ブロックのレシートツリーのルート
-- `miner`: `DATA`、20バイト - マイニング報酬が支払われる受益者のアドレス
-- `difficulty`: `QUANTITY` - このブロックの難易度(整数)
-- `totalDifficulty`: `QUANTITY` - このブロックまでのチェーンの合計難易度(整数)
-- `extraData`: `DATA` - このブロックの「追加データ」フィールド
-- `size`: `QUANTITY` - このブロックのサイズのバイト数(整数)
-- `gasLimit`: `QUANTITY` - このブロックで許可されているガスの最大量
-- `gasUsed`: `QUANTITY` - このブロックのすべてのトランザクションで使用されたガスの合計量
-- `timestamp`: `QUANTITY` - ブロックが照合されたときのUNIXタイムスタンプ
-- `transactions`: `Array` - 最後に指定したパラメータに応じて、トランザクションオブジェクトの配列、または32バイトのトランザクションハッシュ
-- `uncles`: `Array` - アンクルハッシュの配列
+`Object` - ブロックオブジェクト、またはブロックが見つからなかった場合は`null`:
+
+- `number`: `QUANTITY` - ブロック番号。 保留中のブロックの場合はnull。
+- `hash`: `DATA`、32バイト - ブロックのハッシュ。 保留中のブロックの場合はnull。
+- `parentHash`: `DATA`、32バイト - 親ブロックのハッシュ。
+- `nonce`: `DATA`、8バイト - 生成されたプルーフオブワークのハッシュ。 保留中のブロックの場合は`null`、プルーフオブステークのブロックの場合は`0x0` (マージ以降)
+- `sha3Uncles`: `DATA`、32バイト - ブロック内のアンクルデータのSHA3。
+- `logsBloom`: `DATA`、256バイト - ブロックのログのブルームフィルタ。 保留中のブロックの場合はnull。
+- `transactionsRoot`: `DATA`、32バイト - ブロックのトランザクションツリーのルート。
+- `stateRoot`: `DATA`、32バイト - ブロックの最終状態ツリーのルート。
+- `receiptsRoot`: `DATA`、32バイト - ブロックのレシートツリーのルート。
+- `miner`: `DATA`、20バイト - ブロック報酬が与えられた受益者のアドレス。
+- `difficulty`: `QUANTITY` - このブロックの難易度の整数。
+- `totalDifficulty`: `QUANTITY` - このブロックまでのチェーンの合計難易度の整数。
+- `extraData`: `DATA` - このブロックの「追加データ」フィールド。
+- `size`: `QUANTITY` - このブロックのサイズ(バイト単位)の整数。
+- `gasLimit`: `QUANTITY` - このブロックで許可されているガスの最大量。
+- `gasUsed`: `QUANTITY` - このブロック内のすべてのトランザクションによって使用されたガスの合計量。
+- `timestamp`: `QUANTITY` - ブロックが照合されたときのUNIXタイムスタンプ。
+- `transactions`: `Array` - 最後に与えられたパラメータに応じて、トランザクションオブジェクトの配列、または32バイトのトランザクションハッシュ。
+- `uncles`: `Array` - アンクルハッシュの配列。
**例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
-// Result
-{
+// 結果
{
-"jsonrpc": "2.0",
-"id": 1,
-"result": {
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
"difficulty": "0x4ea3f27bc",
"extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
"gasLimit": "0x1388",
@@ -1118,7 +1196,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
"transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
"uncles": [
]
-}
+ }
}
```
@@ -1126,10 +1204,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
ブロック番号を使用して、ブロックに関する情報を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `QUANTITY|TAG` - ブロックの番号(整数)、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
-2. `Boolean` - `true`の場合は、完全なトランザクションオブジェクトを返します。 `false`の場合は、トランザクションのハッシュのみを返します
+1. `QUANTITY|TAG` - ブロック番号の整数、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`または`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。
+2. `Boolean` - `true`の場合は完全なトランザクションオブジェクトを返し、`false`の場合はトランザクションのハッシュのみを返します。
```js
params: [
@@ -1138,7 +1220,8 @@ params: [
]
```
-**戻り値**については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。
+**戻り値**
+[eth_getBlockByHash](#eth_getblockbyhash)を参照
**例**
@@ -1147,12 +1230,16 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
```
-結果については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。
+結果は[eth_getBlockByHash](#eth_getblockbyhash)を参照
### eth_getTransactionByHash {#eth_gettransactionbyhash}
トランザクションハッシュを使用して、リクエストされたトランザクションに関する情報を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
1. `DATA`、32バイト - トランザクションのハッシュ
@@ -1163,20 +1250,20 @@ params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
**戻り値**
-`Object` - トランザクションオブジェクト、またはトランザクションが見つからなかった場合は`null`
-
-- `blockHash`: `DATA`、32バイト - このトランザクションが組み込まれていたブロックのハッシュ。 保留中の場合は`null`
-- `blockNumber`: `QUANTITY` - このトランザクションが組み込まれていたブロックの番号 保留中の場合は`null`
-- `from`: `DATA`、20バイト - 送信者のアドレス
-- `gas`: `QUANTITY` - 送信者が提供するガス
-- `gasPrice`: `QUANTITY` - 送信者が指定したガス価格(wei単位)
-- `hash`: `DATA`、32バイト - トランザクションのハッシュ
-- `input`: `DATA` - トランザクションと共に送信されるデータ
-- `nonce`: `QUANTITY` - 送信者がこのトランザクションより前に送信したトランザクションの数
-- `to`: `DATA`、20バイト - 受信者のアドレス。 コントラクト作成時のトランザクションは`null`
-- `transactionIndex`: `QUANTITY` - ブロック内のトランザクションのインデックスの位置(整数)。 保留中の場合は`null`
-- `value`: `QUANTITY` - 送金された価値(wei単位)
-- `v`: `QUANTITY` - ECDSAのリカバリID
+`Object` - トランザクションオブジェクト、またはトランザクションが見つからなかった場合は`null`:
+
+- `blockHash`: `DATA`、32バイト - このトランザクションが含まれていたブロックのハッシュ。 保留中の場合はnull。
+- `blockNumber`: `QUANTITY` - このトランザクションが含まれていたブロック番号。 保留中の場合はnull。
+- `from`: `DATA`、20バイト - 送信者のアドレス。
+- `gas`: `QUANTITY` - 送信者によって提供されたガス。
+- `gasPrice`: `QUANTITY` - 送信者によって提供されたガス価格(Wei単位)。
+- `hash`: `DATA`、32バイト - トランザクションのハッシュ。
+- `input`: `DATA` - トランザクションと共に送信されるデータ。
+- `nonce`: `QUANTITY` - これより前に送信者によって行われたトランザクションの数。
+- `to`: `DATA`、20バイト - 受信者のアドレス。 コントラクト作成トランザクションの場合は`null`。
+- `transactionIndex`: `QUANTITY` - ブロック内でのトランザクションのインデックス位置の整数。 保留中の場合はnull。
+- `value`: `QUANTITY` - Wei単位で転送された値。
+- `v`: `QUANTITY` - ECDSAリカバリID
- `r`: `QUANTITY` - ECDSA署名r
- `s`: `QUANTITY` - ECDSA署名s
@@ -1212,10 +1299,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param
ブロックのハッシュとトランザクションのインデックスの位置を使用して、トランザクションに関する情報を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `DATA`、32バイト - ブロックのハッシュ
-2. `QUANTITY` - トランザクションのインデックスの位置(整数)
+1. `DATA`、32バイト - ブロックのハッシュ。
+2. `QUANTITY` - トランザクションのインデックス位置の整数。
```js
params: [
@@ -1224,7 +1315,8 @@ params: [
]
```
-**戻り値**については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。
+**戻り値**
+[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照
**例**
@@ -1233,16 +1325,20 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
```
-結果については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。
+結果は[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照
### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex}
ブロック番号とトランザクションのインデックスの位置を使用して、トランザクションに関する情報を返します。
+
+ プレイグラウンドでエンドポイントを試す
+
+
**パラメータ**
-1. `QUANTITY|TAG` - ブロックの番号、または文字列`"latest"`、`"earliest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください
-2. `QUANTITY` - トランザクションのインデックスの位置
+1. `QUANTITY|TAG` - ブロック番号、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`または`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。
+2. `QUANTITY` - トランザクションのインデックス位置。
```js
params: [
@@ -1251,22 +1347,23 @@ params: [
]
```
-**戻り値**については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。
+**戻り値**
+[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照
**例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
```
-結果については、[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照してください。
+結果は[eth_getTransactionByHash](#eth_gettransactionbyhash)を参照
### eth_getTransactionReceipt {#eth_gettransactionreceipt}
トランザクションのハッシュを使用して、トランザクションのレシートを返します。
-**注** : 保留中のトランザクションでは、レシートは取得できません。
+**注** 保留中のトランザクションではレシートは利用できません。
**パラメータ**
@@ -1276,26 +1373,27 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberA
params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
```
-**戻り値** `Object` - トランザクションレシートのオブジェクト、またはレシートが見つからなかった場合は`null`
+**戻り値**
+`Object` - トランザクションレシートオブジェクト、またはレシートが見つからない場合は`null`:
-- `transactionHash`: `DATA`、32バイト - トランザクションのハッシュ
-- `transactionIndex`: `QUANTITY` - ブロック内のトランザクションのインデックスの位置(整数)。
-- `blockHash`: `DATA`、32バイト - このトランザクションが組み込まれていたブロックのハッシュ。
-- `blockNumber`: `QUANTITY` - このトランザクションが組み込まれていたブロックの番号
-- `from`: `DATA`、20バイト - 送信者のアドレス
+- `transactionHash `: `DATA`、32バイト - トランザクションのハッシュ。
+- `transactionIndex`: `QUANTITY` - ブロック内でのトランザクションのインデックス位置の整数。
+- `blockHash`: `DATA`、32バイト - このトランザクションが含まれていたブロックのハッシュ。
+- `blockNumber`: `QUANTITY` - このトランザクションが含まれていたブロック番号。
+- `from`: `DATA`、20バイト - 送信者のアドレス。
- `to`: `DATA`、20バイト - 受信者のアドレス。 コントラクト作成時のトランザクションはnull
-- `cumulativeGasUsed`: `QUANTITY` - ブロック内でこのトランザクションの実行時に使用されたガスの総量
-- `effectiveGasPrice` : `QUANTITY` - ガスユニットごとに支払われるベースフィーとチップの合計
-- `gasUsed`: `QUANTITY` - この特定のトランザクションのみで使用されたガスの量
-- `contractAddress`: `DATA`、20バイト - コントラクト作成のトランザクションの場合は、作成されたコントラクトのアドレス、その他の場合は`null`
-- `logs`: `Array` - このトランザクションが生成したログオブジェクトの配列
-- `logsBloom`: `DATA`、256バイト - 関連ログを迅速に取得するためのライトクライアント用のブルームフィルター。
-- `type`: `QUANTITY` - トランザクションタイプの整数、`0x0`でレガシートランザクション、 `0x1`でアクセスリストタイプ、`0x2`で動的フィー。
+- `cumulativeGasUsed` : `QUANTITY ` - このトランザクションがブロック内で実行された際に使用されたガスの総量。
+- `effectiveGasPrice` : `QUANTITY` - ガスユニットごとに支払われるベースフィーとチップの合計。
+- `gasUsed `: `QUANTITY ` - この特定のトランザクションだけで使用されたガスの量。
+- `contractAddress `: `DATA`、20バイト - トランザクションがコントラクト作成だった場合に作成されたコントラクトアドレス、それ以外は`null`。
+- `logs`: `Array` - このトランザクションが生成したログオブジェクトの配列。
+- `logsBloom`: `DATA`、256バイト - ライトクライアントが関連ログを迅速に取得するためのブルームフィルター。
+- `type`: `QUANTITY` - トランザクションタイプの整数、`0x0`はレガシートランザクション、`0x1`はアクセスリストタイプ、`0x2`は動的フィー。
-また、以下のうち_いずれか_を返します。
+また、以下のいずれかを返します。
-- `root` : `DATA`、32バイト - トランザクション後の状態ルート(ビザンチウム以前)
-- `status`: `QUANTITY` - `1`(成功)、または`0`(失敗)
+- `root` : `DATA` トランザクション後の状態ルートの32バイト(ビザンチウム以前)
+- `status`: `QUANTITY` `1` (成功) または `0` (失敗) のいずれか
**例**
@@ -1331,12 +1429,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
-ハッシュとアンクルインデックスの位置を使用して、ブロックのアンクルに関する情報を返します。
+ハッシュとアンクルインデックス位置によって、ブロックのアンクルに関する情報を返します。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
-1. `DATA`、32バイト - ブロックのハッシュ
-2. `QUANTITY` - アンクルのインデックスの位置
+1. `DATA`、32バイト - ブロックのハッシュ。
+2. `QUANTITY` - アンクルのインデックス位置。
```js
params: [
@@ -1345,7 +1447,8 @@ params: [
]
```
-**戻り値**については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。
+**戻り値**
+[eth_getBlockByHash](#eth_getblockbyhash)を参照
**例**
@@ -1354,18 +1457,22 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
```
-結果については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。
+結果は[eth_getBlockByHash](#eth_getblockbyhash)を参照
-**注**: アンクルには、個々のトランザクションは含まれていません。
+**注**: アンクルには個別のトランザクションは含まれません。
### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
-ブロック番号とアンクルのインデックスの位置を使用して、ブロックのアンクルに関する情報を返します。
+ブロック番号とアンクルインデックス位置によって、ブロックのアンクルに関する情報を返します。
+
+
+ プレイグラウンドでエンドポイントを試す
+
**パラメータ**
-1. `QUANTITY|TAG` - ブロックの番号、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`、`"finalized"`のいずれか。[デフォルトのブロックパラメータ](/developers/docs/apis/json-rpc/#default-block)を参照してください。
-2. `QUANTITY` - アンクルのインデックスの位置
+1. `QUANTITY|TAG` - ブロック番号、または文字列`"earliest"`、`"latest"`、`"pending"`、`"safe"`、`"finalized"`。[ブロックパラメータ](/developers/docs/apis/json-rpc/#block-parameter)を参照。
+2. `QUANTITY` - アンクルのインデックス位置。
```js
params: [
@@ -1374,9 +1481,10 @@ params: [
]
```
-**戻り値**については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。
+**戻り値**
+[eth_getBlockByHash](#eth_getblockbyhash)を参照
-**注**: アンクルには、個々のトランザクションは含まれていません。
+**注**: アンクルには個別のトランザクションは含まれません。
**例**
@@ -1385,27 +1493,29 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
```
-結果については、[eth_getBlockByHash](#eth_getblockbyhash)を参照してください。
+結果は[eth_getBlockByHash](#eth_getblockbyhash)を参照
### eth_newFilter {#eth_newfilter}
-(ログの)状態変更を通知するために、フィルターオプションに基づいてフィルターオブジェクトを作成します。 状態変更を確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。
+(ログの)状態変更を通知するために、フィルターオプションに基づいてフィルターオブジェクトを作成します。
+状態が変更されたかを確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。
-**トピックフィルターを指定する際の注:** トピックは順序に依存します。 トピック [A, B] を持つログのトランザクションは、下記のトピックフィルターによってマッチングされます。
+**トピックフィルター指定に関する注意:**
+トピックは順序に依存します。 トピック [A, B] を持つログのトランザクションは、下記のトピックフィルターによってマッチングされます。
-- `[]` 「条件なし」
-- `[A]` 「最初の位置がA(その後の位置については条件なし) 」
-- `[null, B]`「最初の位置は条件なし、かつ2番目の位置がB(その後の位置については条件なし) 」
-- `[A, B]`「最初の位置がA、かつ2番目の位置がB(その後の位置については条件なし) 」
-- `[[A, B], [A, B]]`「最初の位置が(AまたはB)、かつ2番目の位置が(AまたはB)(その後の位置については条件なし) 」
+- `[]`「すべて」
+- `[A]`「最初の位置がA(それ以降はすべて)」
+- `[null, B]`「最初の位置はすべて、かつ2番目の位置がB(それ以降はすべて)」
+- `[A, B]`「最初の位置がA、かつ2番目の位置がB(それ以降はすべて)」
+- `[[A, B], [A, B]]`「最初の位置が(AまたはB)、かつ2番目の位置が(AまたはB)(それ以降はすべて)」
- **パラメータ**
-1. `Object` - フィルターオプション
+1. `Object` - フィルターオプション:
-- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。
-- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。
-- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレス、またはアドレスのリスト
-- `topics`: `Array of DATA`、- (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能
+- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。
+- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。
+- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレスまたはアドレスのリスト。
+- `topics`: `Array of DATA` - (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能
```js
params: [
@@ -1425,7 +1535,8 @@ params: [
]
```
-**戻り値** `QUANTITY` - フィルターID
+**戻り値**
+`QUANTITY` - フィルターID。
**例**
@@ -1442,11 +1553,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic
### eth_newBlockFilter {#eth_newblockfilter}
-新しいブロックの到着を通知するために、ノードにフィルターを作成します。 状態変更を確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。
+新しいブロックの到着を通知するために、ノードにフィルターを作成します。
+状態が変更されたかを確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。
-**パラメータ** なし
+**パラメータ**
+なし
-**戻り値** `QUANTITY` - フィルターID
+**戻り値**
+`QUANTITY` - フィルターID。
**例**
@@ -1463,11 +1577,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],
### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
-新しい保留中のトランザクションの到着を通知するために、ノードにフィルターを作成します。 状態変更を確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。
+新しい保留中のトランザクションの到着を通知するために、ノードにフィルターを作成します。
+状態が変更されたかを確認するには、[eth_getFilterChanges](#eth_getfilterchanges)を呼び出します。
-**パラメータ** なし
+**パラメータ**
+なし
-**戻り値** `QUANTITY` - フィルターID
+**戻り値**
+`QUANTITY` - フィルターID。
**例**
@@ -1484,11 +1601,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter"
### eth_uninstallFilter {#eth_uninstallfilter}
-指定されたIDを使用して、フィルターをアンインストールします。 ウォッチが不要になったら、必ず呼び出す必要があります。 また、フィルターは一定期間、[eth_getFilterChanges](#eth_getfilterchanges)を使用してリクエストされなければタイムアウトします。
+指定されたIDを使用して、フィルターをアンインストールします。 ウォッチが不要になったら、必ず呼び出す必要があります。
+また、フィルターは一定期間[eth_getFilterChanges](#eth_getfilterchanges)でリクエストされないとタイムアウトします。
**パラメータ**
-1. `QUANTITY` - フィルターID
+1. `QUANTITY` - フィルターID。
```js
params: [
@@ -1496,7 +1614,8 @@ params: [
]
```
-**戻り値** `Boolean` - フィルターのアンインストールに成功した場合は`true`、その他の場合は`false`
+**戻り値**
+`Boolean` - フィルターが正常にアンインストールされた場合は`true`、それ以外は`false`。
**例**
@@ -1517,7 +1636,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["
**パラメータ**
-1. `QUANTITY` - フィルターID
+1. `QUANTITY` - フィルターID。
```js
params: [
@@ -1525,26 +1644,30 @@ params: [
]
```
-**戻り値** `Array` - ログオブジェクトの配列、または最後のポーリングから変化がない場合は空の配列
-
-- `eth_newBlockFilter`で作成したフィルターでは、ブロックハッシュ(`DATA`、32バイト)が返されます(例: `["0x3454645634534..."]`)
-- `eth_newPendingTransactionFilter`で作成したフィルターでは、トランザクションハッシュ(`DATA`、32バイト)が返されます(例: `["0x6345343454645..."]`)
-- `eth_newFilter`で作成されたフィルターでは、ログは下記のパラメータを持つオブジェクトになります
- - `removed`: `TAG` - チェーンの再編成によってログが削除された場合は`true`。 ログが有効な場合は`false`
- - `logIndex`: `QUANTITY` - ブロック内のログインデックスの位置(整数)。 保留中のログの場合は`null`
- - `transactionIndex`: `QUANTITY` - ログの作成元のトランザクションのインデックスの位置(整数) 。 保留中のログの場合は`null`
- - `transactionHash`: `DATA`、32バイト - このログが作成されたトランザクションのハッシュ。 保留中のログの場合は`null`
- - `blockHash`: `DATA`、32バイト - このログが存在したブロックのハッシュ。 保留中の場合は`null` 保留中のログの場合は`null`
- - `blockNumber`: `QUANTITY` - このログが存在したブロックの番号。 保留中の場合は`null` 保留中のログの場合は`null`
- - `address`: `DATA`、20バイト - このログの作成元のアドレス
- - `data`: `DATA` - ゼロまたは32バイト以上のインデックス付けがされていないログの引数を含む
- - `topics`: `Array of DATA` - 0から4つの32バイトのインデックス付けされたログの引数の`DATA`配列。 (_Solidity_の場合: 最初のトピックはイベント(例: `Deposit(address,bytes32,uint256)`)の署名の_ハッシュ_。ただし、`anonymous`指定子でイベントを宣言した場合を除く)
+**戻り値**
+`Array` - ログオブジェクトの配列、または最後のポーリング以降に変更がない場合は空の配列。
+
+- `eth_newBlockFilter`で作成されたフィルターの場合、戻り値はブロックハッシュ(`DATA`、32バイト)です(例: `["0x3454645634534..."]`)。
+
+- `eth_newPendingTransactionFilter`で作成されたフィルターの場合、戻り値はトランザクションハッシュ(`DATA`、32バイト)です(例: `["0x6345343454645..."]`)。
+
+- `eth_newFilter`で作成されたフィルターの場合、ログは以下のパラメータを持つオブジェクトです:
+ - `removed`: `TAG` - チェーンの再編成によりログが削除された場合は`true`。 有効なログの場合は`false`。
+ - `logIndex`: `QUANTITY` - ブロック内のログインデックス位置の整数。 保留中のログの場合はnull。
+ - `transactionIndex`: `QUANTITY` - ログが作成されたトランザクションのインデックス位置の整数。 保留中のログの場合はnull。
+ - `transactionHash`: `DATA`、32バイト - このログが作成されたトランザクションのハッシュ。 保留中のログの場合はnull。
+ - `blockHash`: `DATA`、32バイト - このログが含まれていたブロックのハッシュ。 保留中の場合はnull。 保留中のログの場合はnull。
+ - `blockNumber`: `QUANTITY` - このログが含まれていたブロック番号。 保留中の場合はnull。 保留中のログの場合はnull。
+ - `address`: `DATA`、20バイト - このログの生成元のアドレス。
+ - `data`: `DATA` - 可変長のインデックスなしログデータ。 (_Solidity_の場合: 0個以上の32バイトのインデックスなしログ引数。)
+ - `topics`: `Array of DATA` - 0から4つの32バイト`DATA`からなる、インデックス付けされたログ引数の配列。 (_Solidity_の場合: 最初のトピックは、イベントの署名の_ハッシュ_です(例: `Deposit(address,bytes32,uint256)`)。ただし、`anonymous`指定子でイベントを宣言した場合を除きます。)
+
- **例**
```js
-// Request
+// リクエスト
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
-// Result
+// 結果
{
"id":1,
"jsonrpc":"2.0",
@@ -1569,7 +1692,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":[
**パラメータ**
-1. `QUANTITY` - フィルターID
+1. `QUANTITY` - フィルターID。
```js
params: [
@@ -1577,7 +1700,8 @@ params: [
]
```
-**戻り値**については、 [eth_getFilterChanges](#eth_getfilterchanges)を参照してください。
+**戻り値**
+[eth_getFilterChanges](#eth_getfilterchanges)を参照
**例**
@@ -1586,7 +1710,7 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
```
-結果については、[eth_getFilterChanges](#eth_getfilterchanges)を参照してください。
+結果は[eth_getFilterChanges](#eth_getfilterchanges)を参照
### eth_getLogs {#eth_getlogs}
@@ -1594,13 +1718,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x
**パラメータ**
-1. `Object` - フィルターオプション
+1. `Object` - フィルターオプション:
-- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。
-- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルトは`"latest"`) 整数のブロック番号、または最後に提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはブロックにまだ含まれていないトランザクションを表す`"pending"`、`"earliest"`を指定できます。
-- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレス、またはアドレスのリスト
-- `topics`: `Array of DATA`、- (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能
-- `blockhash`: `DATA`、32バイト - (オプション、**実装予定**) EIP-234が追加されたことにより、`blockHash`が新たなフィルターオプションになります。これは、返されるログを32バイトのハッシュ`blockHash`を持つ単一のブロックに制限します。 `blockHash`を使用することは、`fromBlock`と`toBlock`に`blockHash`のハッシュのブロック番号を指定することと同等です。 `blockHash`がフィルター条件にある場合、`fromBlock`と`toBlock`は使用できません。
+- `fromBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。
+- `toBlock`: `QUANTITY|TAG` - (オプション、デフォルト: `"latest"`) 整数のブロック番号、または最後の提案されたブロックを表す`"latest"`、最新の安全なブロックを表す`"safe"`、最新のファイナライズされたブロックを表す`"finalized"`、またはまだブロックに含まれていないトランザクションを表す`"pending"`、`"earliest"`。
+- `address`: `DATA|Array`、20バイト - (オプション)ログの生成元となるコントラクトアドレスまたはアドレスのリスト。
+- `topics`: `Array of DATA` - (オプション)32バイトの`DATA`トピックの配列。 トピックは順序に依存します。 各トピックは「or」オプションのDATA配列にすることも可能
+- `blockHash`: `DATA`、32バイト - (オプション、**将来**)EIP-234の追加により、`blockHash`は新しいフィルターオプションとなり、返されるログを32バイトハッシュ`blockHash`を持つ単一ブロックに制限します。 `blockHash`を使用することは、`fromBlock` = `toBlock` = ハッシュ`blockHash`を持つブロック番号と等価です。 フィルター条件に`blockHash`が存在する場合、`fromBlock`も`toBlock`も許可されません。
```js
params: [
@@ -1612,7 +1736,8 @@ params: [
]
```
-**戻り値**については、 [eth_getFilterChanges](#eth_getfilterchanges)を参照してください。
+**戻り値**
+[eth_getFilterChanges](#eth_getfilterchanges)を参照
**例**
@@ -1621,15 +1746,15 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
```
-結果については、[eth_getFilterChanges](#eth_getfilterchanges)を参照してください。
+結果は[eth_getFilterChanges](#eth_getfilterchanges)を参照
## 使用例 {#usage-example}
-### JSON_RPCを使用してコントラクトをデプロイする {#deploying-contract}
+### JSON_RPCを使用したコントラクトのデプロイ {#deploying-contract}
-このセクションでは、RPCインターフェースのみを使用してコントラクトをデプロイする方法について、実例を交えて説明します。 コントラクトをデプロイする際には、複雑さを抽象化できる別の方法があります。例えば、RPCインターフェースを基盤としたライブラリ([web3.js](https://web3js.readthedocs.io/)、[web3.py](https://github.com/ethereum/web3.py)など)を使用できます。 通常、抽象化すると簡単に理解できるようになり、エラーも起こりにくくなります。それでも、内部の仕組みを知っておくことで、理解を深めることができます。
+このセクションでは、RPCインターフェースのみを使用してコントラクトをデプロイする方法について、実例を交えて説明します。 この複雑さが抽象化されている、コントラクトをデプロイするための代替ルートがあります。例えば、[web3.js](https://web3js.readthedocs.io/)や[web3.py](https://github.com/ethereum/web3.py)など、RPCインターフェース上に構築されたライブラリを使用する方法です。 通常、抽象化すると簡単に理解できるようになり、エラーも起こりにくくなります。それでも、内部の仕組みを知っておくことで、理解を深めることができます。
-以下は、JSON-RPCインターフェースを使用してイーサリアムノードにデプロイされる、`Multiply7`と呼ばれる簡単なスマートコントラクトです。 このチュートリアルは、読者がすでにGethノードを実行していることを前提としています。 ノードとクライアントの詳細については、[こちら](/developers/docs/nodes-and-clients/run-a-node)をご覧ください。 また、Gethクライアント以外のHTTP JSON-RPCを起動する方法については、それぞれの[クライアント](/developers/docs/nodes-and-clients/)のドキュメントを参照してください。 ほとんどのクライアントは、デフォルトでは`localhost:8545`で動作します。
+以下は、`Multiply7`という単純なスマートコントラクトで、JSON-RPCインターフェースを使用してEthereumノードにデプロイされます。 このチュートリアルは、読者がすでにGethノードを実行していることを前提としています。 ノードとクライアントに関する詳細情報は、[こちら](/developers/docs/nodes-and-clients/run-a-node)で入手できます。 Geth以外のクライアントでHTTP JSON-RPCを開始する方法については、個々の[クライアント](/developers/docs/nodes-and-clients/)のドキュメントを参照してください。 ほとんどのクライアントは、デフォルトで`localhost:8545`でサービスを提供します。
```javascript
contract Multiply7 {
@@ -1641,18 +1766,18 @@ contract Multiply7 {
}
```
-まず、HTTP RPCインターフェースが有効になっていることを確認します。 つまり、Gethの起動時に`--http`フラグを設定します。 この例では、プライベート開発チェーン上のGethノードを使用します。 このアプローチを使用する際には、本物のネットワーク上のEtherは必要ありません。
+まず、HTTP RPCインターフェースが有効になっていることを確認します。 これは、起動時にGethに`--http`フラグを供給することを意味します。 この例では、プライベート開発チェーン上のGethノードを使用します。 このアプローチを使用する際には、本物のネットワーク上のEtherは必要ありません。
```bash
geth --http --dev console 2>>geth.log
```
-これにより、HTTP RPCインターフェースが`http://localhost:8545`で開始します。
+これにより、HTTP RPCインターフェースが`http://localhost:8545`で開始されます。
-[curl](https://curl.se)を使用してCoinbaseアドレスと残高を取得することにより、インターフェースが実行されていることを確認できます。 例で示されているデータは、ローカルノードによって異なりますのでご注意ください。 これらのコマンドを試す場合は、2番目のcurlリクエストのrequestパラメータの値を、1番目のcurlリクエストから返されたresultパラメータに置き換えてください。
+[curl](https://curl.se)を使用して、コインベースアドレス(アカウントの配列から最初のアドレスを取得)と残高を取得することで、インターフェースが実行中であることを確認できます。 例で示されているデータは、ローカルノードによって異なりますのでご注意ください。 これらのコマンドを試す場合は、2番目のcurlリクエストのrequestパラメータの値を、1番目のcurlリクエストから返されたresultパラメータに置き換えてください。
```bash
-curl --data '{"jsonrpc":"2.0","method":"eth_coinbase", "id":1}' -H "Content-Type: application/json" localhost:8545
+curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545
{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
@@ -1666,9 +1791,9 @@ web3.fromWei("0x1639e49bba16280000", "ether")
// "410"
```
-これで、プライベート開発チェーンにEtherが存在するようになったため、コントラクトをデプロイできるようになりました。 最初のステップは、Multiply7コントラクトをEVMに送信できるバイトコードにコンパイルすることです。 Solidityのコンパイラであるsolcをインストールするには、[Solidityドキュメント](https://docs.soliditylang.org/en/latest/installing-solidity.html)を参照してください ([この例で使用しているコンパイラのバージョン](https://github.com/ethereum/solidity/releases/tag/v0.4.20)に適合するように、古い`solc`リリースを使用することをお勧めします)。
+これで、プライベート開発チェーンにEtherが存在するようになったため、コントラクトをデプロイできるようになりました。 最初のステップは、Multiply7コントラクトをEVMに送信できるバイトコードにコンパイルすることです。 Solidityコンパイラであるsolcをインストールするには、[Solidityドキュメント](https://docs.soliditylang.org/en/latest/installing-solidity.html)に従ってください。 (この例で使用されているコンパイラのバージョンに合わせるために、古い`solc`リリース([v0.4.20](https://github.com/ethereum/solidity/releases/tag/v0.4.20)など)を使用することをお勧めします。)
-次のステップでは、Multiply7コントラクトを、EVMに送信できるバイトコードにコンパイルします。
+次のステップは、Multiply7コントラクトを、EVMに送信できるバイトコードにコンパイルすることです。
```bash
echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
@@ -1678,7 +1803,7 @@ Binary:
6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
```
-これで、コードがコンパイルされました。次に、デプロイに必要なガスの量を特定する必要があります。 RPCインターフェースには、推定値を取得するための`eth_estimateGas`メソッドがあります。
+これで、コードがコンパイルされました。次に、デプロイに必要なガスの量を特定する必要があります。 RPCインターフェースには、推定値を提供する`eth_estimateGas`メソッドがあります。
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
@@ -1692,20 +1817,21 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from
{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
```
-トランザクションがノードによって受け入れられると、トランザクションのハッシュが返されます。 このハッシュはトランザクションの追跡に使用されます。 次のステップは、コントラクトがデプロイされているアドレスを特定することです。 実行された各トランザクションによって、レシートが作成されます。 このレシートには、トランザクションが含まれていたブロックや、EVMによって使用されたガスの量など、トランザクションに関するさまざまな情報が含まれています。 トランザクション でコントラクトが作成される場合は、コントラクトのアドレスも含まれています。 レシートは、`eth_getTransactionReceipt`RPCメソッドで取得できます。
+トランザクションがノードによって受け入れられると、トランザクションのハッシュが返されます。 このハッシュはトランザクションの追跡に使用されます。 次のステップは、コントラクトがデプロイされているアドレスを特定することです。 実行された各トランザクションによって、レシートが作成されます。 このレシートには、トランザクションが含まれていたブロックや、EVMによって使用されたガスの量など、トランザクションに関するさまざまな情報が含まれています。 トランザクション
+でコントラクトが作成される場合は、コントラクトのアドレスも含まれています。 `eth_getTransactionReceipt`RPCメソッドでレシートを取得できます。
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
```
-これで、コントラクトが`0x4d03d617d700cf81935d7f797f4e2ae719648262`に作成されました。 レシートの代わりにnullが返された場合、それはトランザクションがまだブロックに含まれていないことを意味します。 少し待ってから、コンセンサスクライアントが正常に動作しているか確認し、再試行してください。
+コントラクトは`0x4d03d617d700cf81935d7f797f4e2ae719648262`に作成されました。 レシートの代わりにnullが返された場合、それはトランザクションがまだブロックに含まれていないことを意味します。 少し待ってから、コンセンサスクライアントが正常に動作しているか確認し、再試行してください。
-#### スマートコントラクトとのやりとり {#interacting-with-smart-contract}
+#### スマートコントラクトとの対話 {#interacting-with-smart-contract}
この例では、`eth_sendTransaction`を使用して、コントラクトの`multiply`メソッドにトランザクションを送信します。
-`eth_sendTransaction`にはいくつかの引数、具体的には`from`、`to`、`data`が必要です。 `from`は、アカウントの公開アドレスで、`to`はコントラクトアドレスです。 引数`data`には、どのメソッドがどの引数で呼び出されるのかが定義されたペイロードが含まれています。 ここで、[ABI(アプリケーション・バイナリー・インターフェース)](https://docs.soliditylang.org/en/latest/abi-spec.html)を使用します。 ABIは、EVMのためにデータの定義とエンコードの方法を明示したJSONファイルです。
+`eth_sendTransaction`には、`from`、`to`、`data`など、いくつかの引数が必要です。 `From`は私たちのアカウントの公開アドレスで、`to`はコントラクトアドレスです。 `data`引数には、どのメソッドをどの引数で呼び出すかを定義するペイロードが含まれています。 ここで[ABI (アプリケーションバイナリインターフェース)](https://docs.soliditylang.org/en/latest/abi-spec.html)が関係してきます。 ABIは、EVMのためにデータの定義とエンコードの方法を明示したJSONファイルです。
ペイロードのバイトによって、コントラクトのどのメソッドが呼び出されるかが定義されています。 これは、関数名とその引数の型を16進数でエンコードしたKeccakハッシュの最初の4バイトです。 multiply関数はuint256のエイリアスであるuintを受け取ります。 そのため、以下のようになります。
@@ -1716,11 +1842,11 @@ web3.sha3("multiply(uint256)").substring(0, 10)
次のステップでは、引数をエンコードします。 uint256は1つのみです。この例では6とします。 ABIには、uint256型のエンコード方法を指定するセクションがあります。
-`int: enc(X)`は、Xのビッグエンディアンの2の補数表現でのエンコーディングです。長さが32バイトの倍数になるように、Xが負の場合は0xffを使用して、正の場合は0>バイトを使用して左詰めされます。
+`int: enc(X)`は、Xのビッグエンディアン2の補数エンコーディングで、長さが32バイトの倍数になるように、負のXの場合は上位(左)側が0xffで、正のXの場合はゼロバイトでパディングされます。
-これにより、`00000000000000000000000000000000000000000000006`とエンコードされます。
+これは`0000000000000000000000000000000000000000000000000000000000000006`にエンコードされます。
-関数セレクターとエンコードされた引数を組み合わせると、データは `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`になります。
+関数セレクタとエンコードされた引数を組み合わせると、データは`0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`になります。
これを、以下のようにノードに送信します。
@@ -1753,7 +1879,7 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from
}
```
-レシートには、ログが含まれています。 このログは、EVMによってトランザクションの実行時に生成され、レシートに含まれます。 `multiply`関数によって、`Print`イベントが入力の7倍で発生したことが示されています。 `Print`イベントの引数はuint256であるため、ABIルールに従ってデコードできます。これにより、期待される10進数である42が得られます。 このデータのほかに、トピックを使用することでどのイベントによってログが作成されたかを把握することもできます。
+レシートには、ログが含まれています。 このログは、EVMによってトランザクションの実行時に生成され、レシートに含まれます。 `multiply`関数は、`Print`イベントが入力の7倍で発生したことを示しています。 `Print`イベントの引数はuint256であったため、ABIルールに従ってデコードできます。これにより、期待される10進数である42が得られます。 このデータのほかに、トピックを使用することでどのイベントによってログが作成されたかを把握することもできます。
```javascript
web3.sha3("Print(uint256)")
@@ -1764,8 +1890,8 @@ web3.sha3("Print(uint256)")
## 関連トピック {#related-topics}
-- [JSON-RPCの仕様](http://www.jsonrpc.org/specification)
-- [ ノードとクライアント](/developers/docs/nodes-and-clients/)
-- [JavaScript APIs](/developers/docs/apis/javascript/)
+- [JSON-RPC仕様](http://www.jsonrpc.org/specification)
+- [ノードとクライアント](/developers/docs/nodes-and-clients/)
+- [JavaScript API](/developers/docs/apis/javascript/)
- [バックエンドAPI](/developers/docs/apis/backend/)
- [実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)
diff --git a/public/content/translations/ja/developers/docs/blocks/index.md b/public/content/translations/ja/developers/docs/blocks/index.md
index c0a1bfd96db..aacbf459e06 100644
--- a/public/content/translations/ja/developers/docs/blocks/index.md
+++ b/public/content/translations/ja/developers/docs/blocks/index.md
@@ -1,20 +1,21 @@
---
-title: ブロック
-description: イーサリアムブロックチェーンの概要 - データ構造、データ構造の背景と構成
+title: "ブロック"
+description: "イーサリアムブロックチェーンの概要 - データ構造、データ構造の背景と構成"
lang: ja
---
ブロックとは、チェーンの1つ前のハッシュとトランザクションのバッチのことです。 ハッシュはブロックデータから暗号的に生成されるため、チェーンのブロックはお互いに繋がっています。 前のブロックのハッシュを用いるため、どれかのブロックが改ざんされるとデータの整合性が取れなくなるため、ブロックチェーンを実行しているすべての人が改ざんに気づくことになります。
-## 前提知識 {#prerequisites}
+## 前提条件 {#prerequisites}
-この記事は初心者向けに記載していますが、 より理解を深めるために、まず[アカウント](/developers/docs/accounts/)、[トランザクション](/developers/docs/transactions/)そして[イーサリアムの導入](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。
+この記事は初心者向けに記載していますが、 ただし、このページをより深く理解するために、最初に[アカウント](/developers/docs/accounts/)、[トランザクション](/developers/docs/transactions/)、そして[イーサリアムの紹介](/developers/docs/intro-to-ethereum/)をお読みになることをお勧めします。
## ブロックを使用する背景 {#why-blocks}
ブロックはすべてのイーサリアムネットワークへの参加者が同期された状態を維持し、トランザクションの正確な履歴に同意できるように、複数のトランザクションをブロックにバッチとして格納します。 これは、何十件(もしくは数百) ものトランザクションが一度にコミット、合意、同期されることを意味します。
- _ [イーサリアム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,15 +136,15 @@ lang: ja
ブロックタイムとは、ブロックの生成間隔のことです。 イーサリアムでは、12秒単位で時間を分割し、その単位を「スロット」と呼びます。 各スロットでは、1人のバリデータが選ばれ、ブロックを提案します。 すべてのバリデータがオンラインで完全に稼働している場合、すべてのスロットにブロックが1つ生成され、ブロックタイムは12秒となります。 しかし、バリデータがブロックを提案するタイミングでオフラインになっていることがあり、その場合、スロットが空になることがあります。
-この実装は、ブロックタイムが不規則であり、プロトコルがターゲットとして定めるマイニングの難易度によって調整されるプルーフ・オブ・ワークを基としたシステムとは異なります。 イーサリアムの[平均ブロックタイム](https://etherscan.io/chart/blocktime)は、12秒という新しいブロックタイムで安定しており、これは、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行が明確に示される最も良い例です。
+この実装は、ブロックタイムが不規則であり、プロトコルがターゲットとして定めるマイニングの難易度によって調整されるプルーフ・オブ・ワークを基としたシステムとは異なります。 イーサリアムの[平均ブロックタイム](https://etherscan.io/chart/blocktime)は、新しい12秒のブロックタイムの一貫性に基づき、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行が明確に推測できる完璧な例です。
## ブロックサイズ {#block-size}
-最後に重要なのは、ブロックのサイズには制限があるということです。 各ブロックの目標サイズは3,000万ガスですが、ネットワークの需要に合わせて、ブロックの上限である6,000万ガス(目標ブロックサイズの2倍)まで増減します。 ブロックのガスリミットは、前のブロックのガスリミットから1/1024の割合で上下に調整することができます。 したがって、バリデータはコンセンサスによってブロックのガスリミットを変更することができます。 ブロックの全トランザクションで消費されたガスの総量は、ブロックのガスリミットを超えてはいけません。 ブロックが勝手に大きくなりすぎるのを防ぐという点で、この制限は重要です。 ブロックサイズが大きすぎると、スペースと速度の要件により、パフォーマンスの低いフルノードはネットワークに追いつけなくなり、 次のスロットに間に合うように処理するために必要な計算能力も高くなります。 これが中央集権的な力につながってしまうことから、ブロックサイズに上限を設けています。
+最後に重要なのは、ブロックのサイズには制限があるということです。 各ブロックの目標サイズは3000万ガスですが、ネットワークの需要に応じて、ブロックの上限である6000万ガス(目標ブロックサイズの2倍)まで増減します。 ブロックのガスリミットは、前のブロックのガスリミットから1/1024の割合で上下に調整することができます。 したがって、バリデータはコンセンサスによってブロックのガスリミットを変更することができます。 ブロックの全トランザクションで消費されたガスの総量は、ブロックのガスリミットを超えてはいけません。 ブロックが勝手に大きくなりすぎるのを防ぐという点で、この制限は重要です。 ブロックサイズが大きすぎると、スペースと速度の要件により、パフォーマンスの低いフルノードはネットワークに追いつけなくなり、 次のスロットに間に合うように処理するために必要な計算能力も高くなります。 これが中央集権的な力につながってしまうことから、ブロックサイズに上限を設けています。
-## 参考文献 {#further-reading}
+## 参考リンク {#further-reading}
-_役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。_
+_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_
## 関連トピック {#related-topics}
diff --git a/public/content/translations/ja/developers/docs/bridges/index.md b/public/content/translations/ja/developers/docs/bridges/index.md
index e42e20e7088..96ce2dbfd18 100644
--- a/public/content/translations/ja/developers/docs/bridges/index.md
+++ b/public/content/translations/ja/developers/docs/bridges/index.md
@@ -1,20 +1,20 @@
---
-title: ブリッジ
-description: デベロッパー向けのブリッジ概要
+title: "ブリッジ"
+description: "デベロッパー向けのブリッジ概要"
lang: ja
---
-L1のブロックチェーンおよびL2の[スケーリング](/developers/docs/scaling/)ソリューションが一般化し、ますます多くの分散型アプリケーションがクロスチェーンで運用されつつある現在、複数のチェーン間における通信および資産移動を実現する機能がネットワークインフラにおける不可欠な要素となっています。 この機能を提供するために、さまざまな種類のブリッジが開発されています。
+L1ブロックチェーンとL2[スケーリング](/developers/docs/scaling/)ソリューションが普及し、クロスチェーン化する分散型アプリケーションが増え続ける中、チェーンをまたいだ通信と資産移動は、ネットワークインフラに不可欠な要素となっています。 この機能を提供するために、さまざまな種類のブリッジが開発されています。
-## ブリッジがなぜ必要か? {#need-for-bridges}
+## ブリッジの必要性 {#need-for-bridges}
ブリッジは、複数のブロックチェーンネットワークを接続するために開発されました。 これにより、複数のブロックチェーンが接続され、相互運用が可能になります。
ブロックチェーンはサイロ化された環境で存在するため、あるブロックチェーンがそれ自体で他のブロックチェーンと取引したり通信したりすることはできません。 このため、特定のエコシステムにおいて活発なアクティビティやイノベーションが発生していたとしても、他のエコシステムとの接続性や相互運用性が存在しないために、当該エコシステム自体の限界を越えることができません。
-ブリッジは、相互に隔離されているブロックチェーン環境を接続する手段を提供します。 複数のブロックチェーン間における転送ルートを提供することで、トークン、メッセージ、任意のデータ、および[スマートコントラクト](/developers/docs/smart-contracts/)の呼び出しさえも、あるブロックチェーンから他のブロックチェーンに転送することが可能になります。
+ブリッジは、相互に隔離されているブロックチェーン環境を接続する手段を提供します。 ブリッジはブロックチェーン間に転送ルートを確立し、トークン、メッセージ、任意のデータ、さらには[スマートコントラクト](/developers/docs/smart-contracts/)の呼び出しまでもが、あるチェーンから別のチェーンへと転送できるようになります。
-## ブリッジの利点 {#benefits-of-bridges}
+## ブリッジのメリット {#benefits-of-bridges}
ブリッジの有用性は、複数のブロックチェーン間におけるデータの交換や資産の移動を可能にすることで、数多くの新たなユースケースを生み出す可能性を持つ点にあります。
@@ -30,106 +30,109 @@ L1のブロックチェーンおよびL2の[スケーリング](/developers/docs
## ブリッジはどのように機能するのか? {#how-do-bridges-work}
-[ブリッジの設計](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/)には多くの種類がありますが、特に、クロスチェーンで資産を移転する以下の3つの方法が重要です。
+ブリッジの設計には多くの[種類](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/)がありますが、資産のクロスチェーン転送を可能にする方法として、以下の3つが際立っています。
-- **ロックとミント** - ソースチェーン上のアセットをロックした上で、宛先チェーン上でアセットをミントする方式。
-- **バーンとミント** - ソースチェーン上のトークンをバーンした上で、宛先チェーン上で新たにトークンをミントする方式。
-- **アトミックスワップ** - ソースチェーン上の資産と、他のユーザーの宛先チェーン上の資産を直接交換する方式。
+- **ロック・アンド・ミント –** ソースチェーンで資産をロックし、宛先チェーンで資産をミントします。
+- **バーン・アンド・ミント –** ソースチェーンで資産をバーンし、宛先チェーンで資産をミントします。
+- **アトミックスワップ –** 他の当事者と、ソースチェーン上の資産を宛先チェーン上の資産と交換します。
## ブリッジの種類 {#bridge-types}
ブリッジは通常、以下のカテゴリーに分類されます:
-- **ネイティブブリッジ** - 通常、特定のブロックチェーンにおいて流動性を自動供給するための構築されたブリッジであり、当該エコシステムに対する資金の転送を容易にするものです。 例えば、[ Arbitrumブリッジ](https://bridge.arbitrum.io/)は、イーサリアムからArbitrumへの資金転送を容易にするために開発されたブリッジです。 この種類のブリッジとしては、Polygon PoSブリッジや[Optimismゲートウェイ](https://app.optimism.io/bridge)等があります。
-- **バリデータ/オラクルベースのブリッジ** - クロスチェーン間の転送につき、外部のバリデータ群またはオラクルによる検証に依存するブリッジです。 MultichainやAcrossが含まれます。
-- **一般的なメッセージの受け渡しを伴うブリッジ** - チェーン間の資産転送につき、メッセージおよび任意のデータと共に実行するもの。 例: Axelar、LayerZero、Nomad。
-- **流動性ネットワーク** - 主に、アトミック・スワップによるチェーン間の資産転送に焦点をあてたブリッジです。 通常、この種類のブリッジはチェーン間のメッセージの受け渡しには対応しません。 ConextやHopが含まれます。
+- **ネイティブブリッジ –** 通常、特定のブロックチェーンの流動性をブートストラップするために構築され、ユーザーがエコシステムに資金を移動しやすくするためのブリッジです。 例えば、[Arbitrum Bridge](https://bridge.arbitrum.io/)は、ユーザーがイーサリアムメインネットからArbitrumにブリッジするのを便利にするために構築されています。 その他の同様のブリッジには、Polygon PoSブリッジ、[Optimism Gateway](https://app.optimism.io/bridge)などがあります。
+- **バリデータまたはオラクルベースのブリッジ –** これらのブリッジは、クロスチェーン転送を検証するために、外部のバリデータセットまたはオラクルに依存します。 MultichainやAcrossが含まれます。
+- **汎用メッセージパッシングブリッジ –** これらのブリッジは、資産だけでなく、メッセージや任意のデータもチェーン間で転送できます。 例: Axelar、LayerZero、Nomad。
+- **流動性ネットワーク –** これらのブリッジは、主にアトミックスワップを介して、あるチェーンから別のチェーンへ資産を転送することに焦点を当てています。 通常、この種類のブリッジはチェーン間のメッセージの受け渡しには対応しません。 ConextやHopが含まれます。
## 考慮すべきトレードオフ {#trade-offs}
どのブリッジも、完璧なソリューションとは言えません。 むしろ、各ブリッジは特定の目的を実現する一方で、トレードオフがあると考えるべきです。 デベロッパーおよびユーザーは、以下の特性に基づいて各ブリッジを評価するとよいでしょう:
-- **セキュリティ** - システムの検証を誰が担うか? 一般に、外部のバリデータによりセキュリティを保証するブリッジは、当該ブロックチェーンのバリデータがローカル/ネイティブにセキュリティを保証する場合よりもセキュリティが低くなります。
-- **利便性** - トランザクションの実行にかかる時間と、ユーザーが署名する必要があるトランザクションの数はどの程度か? デベロッパーにとっては、ブリッジを組み込むプロセスの時間や複雑さを検討する必要があります。
-- **接続性** - 様々な宛先チェーン(ロールアップ、サイドチェーン、他のL1ブロックチェーン等)にどれだけ接続でき、新規ブロックチェーンとの統合がどの程度難しいかについて検討が必要です。
-- **複雑なデータの伝達能力** - チェーン間におけるメッセージやより複雑な任意データの転送が可能か、あるいは、チェーン間の資産移転のみに対応しているかが問題になります。
-- **コスト効率** - ブリッジによるチェーン間の資産転送において、どの程度コストが発生するかです。 ブリッジは一般に、固定の手数料またはガス代および特定の転送レートの流動性に基づく変動料金を請求します。 さらに、セキュリティを確保するのにどれだけの手数料が必要になるかに基づき、特定のブリッジにおけるコスト効率を評価することが非常に重要です。
+- **セキュリティ –** システムの検証を誰が担うか? 一般に、外部のバリデータによりセキュリティを保証するブリッジは、当該ブロックチェーンのバリデータがローカル/ネイティブにセキュリティを保証する場合よりもセキュリティが低くなります。
+- **利便性 –** トランザクションの完了にかかる時間と、ユーザーが署名する必要があるトランザクションの数はどのくらいか? デベロッパーにとっては、ブリッジを組み込むプロセスの時間や複雑さを検討する必要があります。
+- **接続性 –** ブリッジが接続できる宛先チェーンの種類 (ロールアップ、サイドチェーン、他のレイヤー1ブロックチェーンなど) は何か、また新しいブロックチェーンを統合するのはどれくらい難しいか?
+- **より複雑なデータの転送能力 –** ブリッジは、メッセージやより複雑な任意のデータをチェーン間で転送できるか、それともクロスチェーンの資産転送のみをサポートしているか?
+- **コスト効率 –** ブリッジを介してチェーン間で資産を転送するのに、どれくらいのコストがかかるか? ブリッジは一般に、固定の手数料またはガス代および特定の転送レートの流動性に基づく変動料金を請求します。 さらに、セキュリティを確保するのにどれだけの手数料が必要になるかに基づき、特定のブリッジにおけるコスト効率を評価することが非常に重要です。
より大まかに見れば、ブリッジはトラステッドとトラストレスの2種類に分類できます。
-- **トラステッド** - トラステッドのブリッジとは、外部による検証に依存するブリッジです。 つまり、チェーン間のデータ送信につき、外部の検証者セット(マルチシグによるフェデレーション、マルチパーティの計算システム、オラクルネットワーク)が介在するブリッジを指します。 これにより、接続性に優れ、完全に汎用化されたメッセージをチェーン間でやりとりすることができます。 さらに、速度やコスト効率の面からも優れている場合が多いです。 ただし、ユーザーはブリッジ自体のセキュリティに依存するため、セキュリティが損なわれる可能性があります。
-- **トラストレス** - これらのブリッジは、接続するブロックチェーンならびに転送するメッセージやトークンに対するバリデータに依存しています。 これらのブリッジが「トラストレス」と呼ばれるのは、(ブロックチェーン自体で想定するものを除き)、新たな信頼想定を追加しないためです。 これにより、トラステッドのブリッジと比較してセキュリティが高いと評価されます。
+- **トラステッド –** トラステッドブリッジは外部で検証されます。 つまり、チェーン間のデータ送信につき、外部の検証者セット(マルチシグによるフェデレーション、マルチパーティの計算システム、オラクルネットワーク)が介在するブリッジを指します。 これにより、接続性に優れ、完全に汎用化されたメッセージをチェーン間でやりとりすることができます。 さらに、速度やコスト効率の面からも優れている場合が多いです。 ただし、ユーザーはブリッジ自体のセキュリティに依存するため、セキュリティが損なわれる可能性があります。
+- **トラストレス –** これらのブリッジは、接続しているブロックチェーンとそのバリデータに依存して、メッセージとトークンを転送します。 これらのブリッジが「トラストレス」と呼ばれるのは、(ブロックチェーン自体で想定するものを除き)、新たな信頼想定を追加しないためです。 これにより、トラステッドのブリッジと比較してセキュリティが高いと評価されます。
トラストレスのブリッジを他の要素で評価する場合、汎用型メッセージの受け渡しが可能なブリッジと、流動性ネットワークのブリッジに分けて考える必要があります。
-- **汎用型メッセージを受け渡すブリッジ** - この種類のブリッジは、チェーン間において、より複雑なデータを安全に転送するのに有用です。 また、多くの場合コスト効率性も優れています。 ただし、これらの強みを持つ一方で、ライトクライアントのブリッジ(例: IBC)に接続できない点や、オプティミスティック・ブリッジ(例: Nomad)の場合に速度が低下するなどの欠点があります。
-- **流動性ネットワーク** - この種類のブリッジは、アトミックスワップを用いて資産を転送するもので、ローカルで検証されるシステムです(つまり、トランザクションを検証するために、裏付けとなるブロックチェーンのバリデータを用います)。 このため、セキュリティと実行速度の両方が優れています。 さらに、コスト効率性や接続性も比較的優れていると考えられています。 ただし、チェーン間におけるメッセージの受け渡しが不可能であるため、より複雑なデータを扱えないという大きな欠点があります。
+- **汎用メッセージパッシングブリッジ –** これらのブリッジは、セキュリティと、より複雑なデータをチェーン間で転送する能力に優れています。 また、多くの場合コスト効率性も優れています。 ただし、これらの強みを持つ一方で、ライトクライアントのブリッジ(例: IBC)に接続できない点や、オプティミスティック・ブリッジ(例: Nomad)の場合に速度が低下するなどの欠点があります。
+- **流動性ネットワーク –** これらのブリッジは、資産の転送にアトミックスワップを使用し、ローカルで検証されるシステムです (つまり、トランザクションを検証するために基盤となるブロックチェーンのバリデータを使用します)。 このため、セキュリティと実行速度の両方が優れています。 さらに、コスト効率性や接続性も比較的優れていると考えられています。 ただし、チェーン間におけるメッセージの受け渡しが不可能であるため、より複雑なデータを扱えないという大きな欠点があります。
-## ブリッジに伴うリスク {#risk-with-bridges}
+## ブリッジのリスク {#risk-with-bridges}
-ブリッジは、[DeFiにおける最悪のハッキング事例](https://rekt.news/leaderboard/)上位3位における原因となっており、現在も開発途上の技術です。 ブリッジの利用は、以下のようなリスクを伴います:
+ブリッジは、[DeFiにおける最大のハッキング](https://rekt.news/leaderboard/)のトップ3を占めており、まだ開発の初期段階にあります。 ブリッジの利用は、以下のようなリスクを伴います:
-- **スマートコントラクトのリスク** - 多くのブリッジは監査に合格しているものの、スマートコントラクトに欠陥がひとつでも含まれていれば、資産に対するハッキング攻撃が可能になります(例: [Solanaのワームホールブリッジ](https://rekt.news/wormhole-rekt/))。
-- **システミックな財務リスク** - 多くのブリッジでは、原資産の正規バージョンを新規チェーンでミントするためにラップ資産を用います。 ラップされたトークンが悪用された事例はすでに発生しており、エコシステム全体にシステミックリスクをもたらします。
-- **カウンターパーティリスク** - 一部のブリッジでは、複数のバリデータが共謀してユーザーの資金を奪い取ろうと考えることはないという信頼の想定をユーザーに要求する、信頼ベースの設計を採用しています。 ユーザーは、これらのサードパーティアクターを信頼しなければならないため、ラグプル、検閲、およびその他の悪意の行為が発生するリスクにさらされています。
-- **未解決の問題** - 現在でもブリッジは開発の初期段階にあるため、様々な市場環境(ネットワーク混雑時や、ネットワーク全体への攻撃やステートのロールバックといった予見できないイベントの発生時)においてブリッジがどのように機能するかについては、未確認の事項が多く残っています。 この不確実性は様々なリスクをもたらすものですが、その影響の度合いはまだ不明です。
+- **スマートコントラクトのリスク –** 多くのブリッジは監査に合格していますが、スマートコントラクトに1つの欠陥があるだけで、資産がハッキングにさらされる可能性があります (例: [SolanaのWormholeブリッジ](https://rekt.news/wormhole-rekt/))。
+- **システミックな金融リスク** – 多くのブリッジは、新しいチェーンで元の資産のカノニカルバージョンをミントするために、ラップされた資産を使用します。 ラップされたトークンが悪用された事例はすでに発生しており、エコシステム全体にシステミックリスクをもたらします。
+- **カウンターパーティリスク –** 一部のブリッジは、バリデータが共謀してユーザーの資金を盗むことはないという仮定にユーザーが依存することを要求する、トラステッドな設計を利用しています。 ユーザーは、これらのサードパーティアクターを信頼しなければならないため、ラグプル、検閲、およびその他の悪意の行為が発生するリスクにさらされています。
+- **未解決の問題 –** ブリッジは開発の初期段階にあるため、ネットワークの混雑時や、ネットワークレベルの攻撃やステートのロールバックなどの予期せぬイベントの発生時といった、さまざまな市場状況でブリッジがどのように機能するかについては、多くの未解決の疑問があります。 この不確実性は様々なリスクをもたらすものですが、その影響の度合いはまだ不明です。
## Dappでブリッジを利用する方法 {#how-can-dapps-use-bridges}
以下では、デベロッパがブリッジを活用してDappのクロスチェーン化を検討する際の実践的な応用例について紹介します:
-### ブリッジとの統合 {#integrating-bridges}
+### ブリッジの統合 {#integrating-bridges}
開発中のDappをブリッジに対応させるには、多くの方法が存在します:
-1. **独自のブリッジを構築する** - 安全で信頼性が高いブリッジの開発は、特にトラストレスのアプローチを採用した場合、容易ではありません。 さらに、スケーラビリティや相互運用性に関する豊富な経験や技術的な知識が必要です。 また、ブリッジを管理し、実務上要求される十分な流動性を維持するためには常駐チームが必要です。
+1. **独自のブリッジを構築する –** 安全で信頼性の高いブリッジを構築するのは容易ではありません。特に、より信頼を最小化するアプローチをとる場合はなおさらです。 さらに、スケーラビリティや相互運用性に関する豊富な経験や技術的な知識が必要です。 また、ブリッジを管理し、実務上要求される十分な流動性を維持するためには常駐チームが必要です。
-2. **ユーザーが様々なブリッジから選択できるようにする** - 多くの[Dapp](/developers/docs/dapps/)では、ユーザーに対してネイティブトークンでのやりとりを要求しています。 ユーザーが所有するトークンを利用できるようにするために、Dappのウェブサイトでは様々なブリッジのオプションを提供しています。 しかしこの方法は、自社のDappのインターフェイスだけでプロセスを完結できず、他のDappやブリッジとのやりとりが必要になるため、その場しのぎの対策と言わざるを得ません。 また、ユーザーのオンボーディングが複雑になり、ミスが発生する可能性も高まります。
+2. **ユーザーに複数のブリッジオプションを提示する –** 多くの[dapps](/developers/docs/dapps/)では、それらと対話するためにユーザーがネイティブトークンを持っている必要があります。 ユーザーが所有するトークンを利用できるようにするために、Dappのウェブサイトでは様々なブリッジのオプションを提供しています。 しかしこの方法は、自社のDappのインターフェイスだけでプロセスを完結できず、他のDappやブリッジとのやりとりが必要になるため、その場しのぎの対策と言わざるを得ません。 また、ユーザーのオンボーディングが複雑になり、ミスが発生する可能性も高まります。
-3. **Dapp内にブリッジを組み込む** - このアプローチでは、ユーザーは外部のブリッジやDEXインターフェイスとやりとりする必要がなくなります。 このため、ユーザーのオンボーディング体験が向上します。 しかし、このアプローチにも以下のような制限があります:
+3. **ブリッジを統合する –** このソリューションでは、dappがユーザーを外部のブリッジやDEXインターフェイスに送る必要はありません。 このため、ユーザーのオンボーディング体験が向上します。 しかし、このアプローチにも以下のような制限があります:
- ブリッジに対する評価やメンテナンスは、手間や時間がかかる。
- ひとつのブリッジを選択することで、単一障害点や依存関係が発生する。
- 当該ブリッジの機能により、Dappのサービスが制限される。
- ブリッジだけでは対応できない機能が必要になる場合がある。 チェーン間のスワップなどの機能を追加するには、DEXを含める必要がある場合がある。
-4. **複数のブリッジを組み込む** - このアプローチは、ひとつのブリッジを統合する場合の多くの問題を解消できます。 一方で、複数のブリッジとの統合は多くのリソースを消費し、暗号資産の分野において最も希少性が高いリソースであるデベロッパーにとって、技術面およびコミュニケーション面での負担が増加してしまいます。
+4. **複数のブリッジを統合する –** このソリューションは、単一のブリッジの統合に関連する多くの問題を解決します。 一方で、複数のブリッジとの統合は多くのリソースを消費し、暗号資産の分野において最も希少性が高いリソースであるデベロッパーにとって、技術面およびコミュニケーション面での負担が増加してしまいます。
-5. **ブリッジアグリゲーターを導入する** - 複数のブリッジにアクセスできる、ブリッジアグリゲーションを活用するのもひとつの方法です。 ブリッジアグリゲーターはすべてのブリッジの強みを継承するため、各ブリッジが提供する機能のみに制限されなくなります。 特に、通常はブリッジアグリゲーターがDappとブリッジとの統合を管理するため、Dappのデベロッパー側はブリッジとの統合における技術的/運用的な側面を管理する作業から解放されます。
+5. **ブリッジアグリゲーターを統合する –** dappsのもう一つの選択肢は、複数のブリッジへのアクセスを提供するブリッジアグリゲーションソリューションを統合することです。 ブリッジアグリゲーターはすべてのブリッジの強みを継承するため、各ブリッジが提供する機能のみに制限されなくなります。 特に、通常はブリッジアグリゲーターがDappとブリッジとの統合を管理するため、Dappのデベロッパー側はブリッジとの統合における技術的/運用的な側面を管理する作業から解放されます。
ブリッジアグリゲーターは、このような利点を持つ一方で、欠点もあります。 例えば、より多くのブリッジを活用するオプションを提供することは事実ですが、特定のアグリゲーターのプラットフォームが提供するブリッジよりもさらに多くのブリッジが市場で提供されています。 さらに、ブリッジの場合と同じように、ブリッジアグリゲーターもスマートコントラクトやテクノロジーに由来するリスクにさらされています(対応するコントラクトが多くなれば、リスクも拡大します)。
Dappにブリッジやブリッジアグリゲーターを組み込む場合、統合の度合いに応じて様々なオプションが考えられます。 例えば、ユーザーにおけるオンボーディング体験の向上を目的とするフロントエンドのみの統合では、ウィジェットを搭載すればよいでしょう。 しかし、ステーキングやイールドファーミング等のより複雑なチェーン間のやりとりを実現するには、SDKやAPIを統合する必要があります。
-### 複数のチェーン上でDappをデプロイする {#deploying-a-dapp-on-multiple-chains}
+### 複数のチェーンにdappをデプロイする {#deploying-a-dapp-on-multiple-chains}
-To deploy a dapp on multiple chains, developers can use development platforms like [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/), etc. 一般にこれらのプラットフォームには、Dappのクロスチェーン化を実現するコンポーザブルなプラグインが含まれています。 例えば、 [hardhat-deploy plugin](https://github.com/wighawag/hardhat-deploy)で提供される決定論的なデプロイ用プロキシを活用することができます。
+複数のチェーンにdappをデプロイするために、開発者は[Alchemy](https://www.alchemy.com/)、[Hardhat](https://hardhat.org/)、[Moralis](https://moralis.io/)などの開発プラットフォームを利用できます。 一般にこれらのプラットフォームには、Dappのクロスチェーン化を実現するコンポーザブルなプラグインが含まれています。 例えば、開発者は[hardhat-deployプラグイン](https://github.com/wighawag/hardhat-deploy)によって提供される決定論的デプロイメントプロキシを使用できます。
-#### 例:
+#### 例:
-- [クロスチェーン対応のDappを開発する方法](https://moralis.io/how-to-build-cross-chain-dapps/)
-- [クロスチェーン対応のNFTマーケットプレイスを開発する方法](https://youtu.be/WZWCzsB1xUE)
-- [Moralis: クロスチェーン対応のDAppsを開発する](https://www.youtube.com/watch?v=ehv70kE1QYo)
+- [クロスチェーンdappsの構築方法](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [クロスチェーンNFTマーケットプレイスの構築](https://youtu.be/WZWCzsB1xUE)
+- [Moralis: クロスチェーンNFT dappsの構築](https://www.youtube.com/watch?v=ehv70kE1QYo)
-### コントラクトにおけるチェーン間のやりとりを監視する {#monitoring-contract-activity-across-chains}
+### チェーンをまたいだコントラクトアクティビティの監視 {#monitoring-contract-activity-across-chains}
-コントラクトにおけるチェーン間のやりとりを監視するには、サブグラフや、Tenderly等の開発プラットフォームを用いて、スマートコントラクトの状態をリアルタイムで観察することができます。 これらのプラットフォームにはさらに、[コントラクトが発行したイベント](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events)をチェックするなど、チェーン間のやりとりを対象としてより充実したデータ監視機能を実現できるツールが含まれています。
+コントラクトにおけるチェーン間のやりとりを監視するには、サブグラフや、Tenderly等の開発プラットフォームを用いて、スマートコントラクトの状態をリアルタイムで観察することができます。 このようなプラットフォームには、[コントラクトによって発行されたイベント](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events)のチェックなど、クロスチェーンアクティビティのためのより高度なデータ監視機能を提供するツールも含まれています。
#### ツール
- [The Graph](https://thegraph.com/en/)
- [Tenderly](https://tenderly.co/)
-## さらに学びたい方へ {#further-reading}
+## 参考リンク {#further-reading}
-- [ブロックチェーンにおけるブリッジ](/bridges/) - ethereum.org
-- [ブロックチェーンにおけるブリッジ: クリプトネットワークのネットワーク構築](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 2021年9月8日、ドミトリー・ベレンゾン作成。
-- [相互運用性のトリレンマ](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 2021年10月1日、アルジュン・ブプタニ作成。
-- [クラスタ: 信頼ベースおよび信頼最小化のブリッジは、マルチチェーン環境をどのように変化させるか](https://blog.celestia.org/clusters/) 2021年10月4日、ムスタファ・アル=バッサム作成。
-- [LI.FI: ブリッジの信頼依存度は様々に異なる](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 2022年4月28日 、アルジュン・チャンド作成。
+- [ブロックチェーンブリッジ](/bridges/) – ethereum.org
+- [L2Beatブリッジリスクフレームワーク](https://l2beat.com/bridges/summary)
+- [ブロックチェーンブリッジ: 暗号ネットワークのネットワークを構築する](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 2021年9月8日 – Dmitriy Berenzon
+- [相互運用性のトリレンマ](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 2021年10月1日 – Arjun Bhuptani
+- [クラスター: トラステッドブリッジとトラストミニマイズドブリッジがマルチチェーンのランドスケープをどのように形成するか](https://blog.celestia.org/clusters/) - 2021年10月4日 – Mustafa Al-Bassam
+- [LI.FI: ブリッジにおいて、信頼はスペクトラムである](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 2022年4月28日 – Arjun Chand
+- [ロールアップの相互運用性ソリューションの現状](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 2024年6月20日 – Alex Hook
+- [安全なクロスチェーン相互運用性のための共有セキュリティの活用: ラグランジュステート委員会とその先](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 2024年6月12日 – Emmanuel Awosika
-ブリッジについてさらに理解を深めたい方は、 [ジェイムズ・プレストウィッチ](https://twitter.com/_prestwich)による洞察溢れる講演をご覧ください:
+さらに、ブリッジへの理解を深めるのに役立つ、[James Prestwich](https://twitter.com/_prestwich)による洞察に満ちたプレゼンテーションをいくつか紹介します。
-- [塀に囲まれたガーデンではなく、ブリッジを構築する](https://youtu.be/ZQJWMiX4hT0)
-- [ブリッジを破壊する](https://youtu.be/b0mC-ZqN8Oo)
-- [ブリッジはなぜ燃えているのか](https://youtu.be/c7cm2kd20j8)
+- [壁に囲まれた庭ではなく、ブリッジを築く](https://youtu.be/ZQJWMiX4hT0)
+- [ブリッジの徹底解説](https://youtu.be/b0mC-ZqN8Oo)
+- [なぜブリッジは燃えているのか](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md
index 9c86bda817f..7fdac526177 100644
--- a/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/index.md
@@ -1,14 +1,14 @@
---
-title: 合意メカニズム
-description: 分散システムにおける合意形成プロトコルと、イーサリアムにおける合意形成プロトコルの役割についての解説
+title: "合意メカニズム"
+description: "分散システムにおける合意形成プロトコルと、イーサリアムにおける合意形成プロトコルの役割についての解説"
lang: ja
---
-合意メカニズムという用語は、「プルーフ・オブ・ステーク」、「プルーフ・オブ・ワーク」、「プルーフ・オブ・オーソリティ」といったプロトコルを指すのに使われることがあります。 しかし、これらはあくまで[シビル攻撃](/glossary/#sybil-attack)に対抗するための合意メカニズムの一部に過ぎません。 合意メカニズムは、分散された一連のノードがブロックチェーンの状態に合意できるようにする考え方、プロトコル、およびインセンティブを完全にまとめたメカニズムです。
+合意メカニズムという用語は、「プルーフ・オブ・ステーク」、「プルーフ・オブ・ワーク」、「プルーフ・オブ・オーソリティ」といったプロトコルを指すのに使われることがあります。 しかし、これらは[シビル攻撃](/glossary/#sybil-attack)を防ぐ合意メカニズムの構成要素に過ぎません。 合意メカニズムは、分散された一連のノードがブロックチェーンの状態に合意できるようにする考え方、プロトコル、およびインセンティブを完全にまとめたメカニズムです。
-## 前提知識 {#prerequisites}
+## 前提条件 {#prerequisites}
-このページの理解を深めるために、まずは[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。
+このページをより深く理解するために、まずは[イーサリアム入門](/developers/docs/intro-to-ethereum/)を読むことをお勧めします。
## コンセンサス(合意)とは {#what-is-consensus}
@@ -28,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,21 +68,21 @@ lang: ja
プルーフ・オブ・ワークとプルーフ・オブ・ステークは、それ自体はコンセンサスプロトコルではありませんが、分かりやすくするためにそのように呼ばれることがよくあります。 これらは実際にはシビル耐性メカニズムであり、誰が最新のブロックを作成するかを決めるものです。 もう一つの重要なコンポーネントは、チェーン・チョイス(別名:フォーク選択)アルゴリズムです。これはチェーンの先頭に複数のブロックが存在する場合、正しいブロックをノードが1つ選択するアルゴリズムです。
-**シビル耐性**はシビル攻撃に対するプロトコルの性能を測るものです。 この種の攻撃への耐性は、分散型ブロックチェーンには不可欠であり、この耐性があることにより、投入されたリソースに応じてマイナーとバリデータが平等に報酬を得ることができます。 プルーフ・オブ・ワークやプルーフ・オブ・ステークは、ユーザーに多くのエネルギーを消費させたり、多くの担保を入れさせることで、この問題を解決します。 これらは、シビル攻撃に対する経済的な抑止力となります。
+**シビル耐性**は、プロトコルがシビル攻撃に対してどの程度有効かを測るものです。 この種の攻撃への耐性は、分散型ブロックチェーンには不可欠であり、この耐性があることにより、投入されたリソースに応じてマイナーとバリデータが平等に報酬を得ることができます。 プルーフ・オブ・ワークやプルーフ・オブ・ステークは、ユーザーに多くのエネルギーを消費させたり、多くの担保を入れさせることで、この問題を解決します。 これらは、シビル攻撃に対する経済的な抑止力となります。
-**チェーン・セレクション・ルール**は、どのチェーンが「正しい」チェーンであるかを決定するルールです。 イーサリアムとビットコインは、ブロックチェーンの長さが長い方を、他のノードが有効なものとして受け入れるという「最長のチェーン」ルールを採用しています。 プルーフ・オブ・ワークチェーンの場合、最長のチェーンはチェーンの累積プルーフ・オブ・ワーク難易度によって決定されます。 イーサリアムも以前は「最長チェーン」ルールを採用していましたが、現在のイーサリアムはプルーフ・オブ・ステークで実行されており、チェーンの「重み」を測定する最新のフォーク・チョイス・アルゴリズムを採用しています。 この重みは、バリデータの投票の累計をバリデータがステーキングしたイーサ残高により加重されて決まります。
+**チェーン選択ルール**は、どのチェーンが「正しい」チェーンであるかを決定するために使用されます。 イーサリアムとビットコインは、ブロックチェーンの長さが長い方を、他のノードが有効なものとして受け入れるという「最長のチェーン」ルールを採用しています。 プルーフ・オブ・ワークチェーンの場合、最長のチェーンはチェーンの累積プルーフ・オブ・ワーク難易度によって決定されます。 イーサリアムも以前は「最長チェーン」ルールを採用していました。しかし、現在のイーサリアムはプルーフ・オブ・ステークで実行されており、チェーンの「重み」を測定する最新のフォーク選択アルゴリズムを採用しています。 この重みは、バリデータの投票の累計をバリデータがステーキングしたイーサ残高により加重されて決まります。
-イーサリアムでは、[Casper FFGプルーフ・オブ・ステーク](https://arxiv.org/abs/1710.09437)と[GHOSTフォーク・チョイスルール](https://arxiv.org/abs/2003.03052)を組み合わせた[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)と呼ばれる合意メカニズムが採用されています。
+イーサリアムは、[Casper FFG プルーフ・オブ・ステーク](https://arxiv.org/abs/1710.09437)と[GHOSTフォークチョイスルール](https://arxiv.org/abs/2003.03052)を組み合わせた、[Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)として知られる合意メカニズムを使用しています。
-## 参考文献 {#further-reading}
+## 参考リンク {#further-reading}
-- [ブロックチェーンの合意アルゴリズムとは](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
-- [ナカモトコンセンサスとは 初心者向け完全ガイド](https://blockonomi.com/nakamoto-consensus/)
-- [Casperの仕組み](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
-- [プルーフ・オブ・ワーク・ブロックチェーンのセキュリティと性能について](https://eprint.iacr.org/2016/555.pdf)
+- [ブロックチェーンのコンセンサスアルゴリズムとは?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
+- [ナカモトコンセンサスとは? 完全初心者向けガイド](https://blockonomi.com/nakamoto-consensus/)
+- [Casperはどのように機能するのか?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
+- [プルーフ・オブ・ワーク・ブロックチェーンのセキュリティとパフォーマンスについて](https://eprint.iacr.org/2016/555.pdf)
- [ビザンチン障害](https://en.wikipedia.org/wiki/Byzantine_fault)
-_役に立つコミュニティリソースをご存知の場合は、 ページを編集して追加してください。_
+_役に立つコミュニティリソースを知っていますか? Edit this page and add it!_
## 関連トピック {#related-topics}
diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md
index 964fa0274fc..c5d372b4101 100644
--- a/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md
+++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/poa/index.md
@@ -1,12 +1,12 @@
---
-title: プルーフ・オブ・オーソリティ(PoA)
-description: ブロックチェーンエコシステムにおけるプルーフ・オブ・オーソリティのコンセンサスプロトコルとその役割について
+title: "プルーフ・オブ・オーソリティ(PoA)"
+description: "ブロックチェーンエコシステムにおけるプルーフ・オブ・オーソリティのコンセンサスプロトコルとその役割について"
lang: ja
---
**プルーフ・オブ・オーソリティ(PoA)** は、評判ベースのコンセンサスアルゴリズムで[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)を変更したバージョンです。 主にプライベートチェーン、テストネット、ローカル開発用ネットワークで使われています。 評判ベースのコンセンサスアルゴリズムであるプルーフ・オブ・オーソリティは、ブロックを生成するために、認証された署名者達のセットを信頼することを求めます。この点でステーキングベースのメカニズムであるプルーフ・オブ・ステークと違います。
-## 前提条件{#prerequisites}
+## 前提条件 {#prerequisites}
このページについて深く理解するには、事前に[トランザクション](/developers/docs/transactions/)、[ブロック](/developers/docs/blocks/)、[コンセンサスメカニズム](/developers/docs/consensus-mechanisms/)について読むことをお勧めします。
@@ -18,7 +18,7 @@ lang: ja
プルーフ・オブ・オーソリティには、複数の実装がありますが、イーサリアムの実装の標準は、**Clique**です。これは、[EIP-225](https://eips.ethereum.org/EIPS/eip-225)を実装しています。 Cliqueは、デベロッパーフレンドリーで、簡単に実装できる標準であり、クライアントの同期タイプのすべてをサポートしています。 他の実装としては、[IBFT 2.0](https://besu.hyperledger.org/private-networks/concepts/poa) や[Aura](https://openethereum.github.io/Chain-specification)などがあります。
-## 仕組みの説明{#how-it-works}
+## 仕組みの説明 {#how-it-works}
プルーフ・オブ・オーソリティでは、新しいブロックを作るために、認証された署名者達のセットが選ばれます。 署名者達は、評判ベースで選ばれ、これらの署名者達のみが新しいブロックを作成することを許されます。 ラウンドロビン方式で署名者達が選ばれます。選ばれた各署名者は、特定の時間枠内でブロックを作成することが許されます。 このブロック作成時間は固定されており、署名者達は時間枠内にブロックを作成しなければなりません。
@@ -28,36 +28,36 @@ lang: ja
小さなフォークが起こる状況があり得えます。ブロックの難易度は、署名が順序か順序外かによって違います。 「順序」のブロックの難易度は2、「順序外」のブロックの難易度は1です。 小さなフォークが発生した場合、「順序」ブロックにシールした多数の署名者を持つチェーンに最も多い難易度が累積し、勝利します。
-## 攻撃ベクトル{#attack-vectors}
+## 攻撃ベクトル {#attack-vectors}
-### 悪意のある署名者達{#malicious-signers}
+### 悪意のある署名者達 {#malicious-signers}
署名者リストに悪意のあるユーザーが追加されたり、署名鍵およびマシンが侵害されたりする可能性があります。 このようなシナリオにおいて、プロトコルには、再編成やスパムに対して防御する能力が必要になります。 提案された解決策では、N人の認証された署名者のリストが与えられた場合、各署名者はK回ごとに1つのブロックしかミントできません。これにより、被害が限定され、残りのバリデータが悪意のあるユーザーを排除するための投票を行うことが可能になります。
-### 検閲{#censorship-attack}
+### 検閲 {#censorship-attack}
もう1つの興味深い攻撃ベクトルは、署名者(あるいは署名者のグループ)が、認証者リストからそれらの署名者を削除することに投票したブロックを検閲しようとする場合です。 これに対処する方法は、署名者に許可されるミントの頻度をN/2の中から1に制限することです。 これにより、悪意のある署名者達は、署名するアカウントの最低51%をコントロールする必要があります。51%に達すれば、チェーンの新たな信頼できる情報源になることができます。
-### スパム{#spam-attack}
+### スパム {#spam-attack}
他の小さな攻撃ベクトルは、悪意のある署名者達がミントする各ブロック内において新たな投票提案をすることです。 ノードは、実際の認証された署名者のリストを作成するために、投票のすべてを集計する必要があるため、常に投票のすべてを記録しなければなりません。 投票枠に制限を設けないと、投票はゆっくりと、しかし無制限に増える可能性があります。 これに対する解決策は、Wブロックの _移動_ 枠を設けて、そのWブロック後の投票が古いと見なすことです。 _妥当な枠は1~2エポックでしょう。_
-### 同時発生ブロック{#concurrent-blocks}
+### 同時発生ブロック {#concurrent-blocks}
PoAネットワークでは、N人の認証された署名者がいる場合、各署名者はK回ごとに1つのブロックをミントすることが許可されています。つまり、任意の時点でN-K+1人のバリデータがブロックをミントできることになります。 これらのバリデーターがブロックを競って生成するのを防ぐために、各署名者は新しいブロックをリリースする時間に小さなランダムな「オフセット」を追加する必要があります。 このプロセスにより、小規模なフォークが発生する可能性は低くなりますが、それでも時折フォークが発生することがあります。これはメインネットと同様です。 署名者が権限を悪用したり混乱を引き起こしたりした場合、他の署名者達は投票により排除することができます。
例えば、10人の認証された署名者がいて、各署名者が20回ごとに1つのブロックを作成できる場合、任意の時点で11人のバリデータがブロックを作成できることになります。 マイナー同士のブロック作成の競争を防ぐために、各署名者は
新しいブロックをリリースする時間に、小さなランダムな「オフセット」を追加します。 これにより、小さなフォークの発生を減らすことが出来ますが、イーサリアムのメインネットで見られるように、場合によってはフォークが発生する可能性があります。 署名者が権限を悪用したり、混乱を引き起こした場合、投票によりネットワークから排除することができます。
-## メリットとデメリット{#pros-and-cons}
+## メリットとデメリット {#pros-and-cons}
-| メリット | デメリット |
+| 長所 | 短所 |
| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| ブロック署名者の数を制限することをベースとしているため、他の一般的なメカニズムであるプルーフ・オブ・ステークやプルーフ・オブ・ワークなどよりもスケーラブル。 | プルーフ・オブ・オーソリティのネットワークでは、検証ノードの数が比較的少ない。 これにより、プルーフ・オブ・オーソリティのネットワークは、より集中化する。 |
| プルーフ・オブ・オーソリティは、実行と維持が安価。 | ブロックチェーンは評判の確立したエンティティを要求するため、一般的な人は通常、認証された署名者になることができない。 |
| トランザクションの承認が非常に速い。新しいブロックの検証に必要な署名者の数が限られているため、1秒未満で達成可能。 | 悪意のある署名者達が、ネットワークにおいて再編成、二重支払い、トランザクションの検閲をする可能性がある。これらの攻撃を軽減することはできるが、完全に防止はできない。 |
-## 参考リンク{#further-reading}
+## 参考リンク {#further-reading}
- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique標準_
- [プルーフ・オブ・オーソリティの研究](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_
@@ -74,7 +74,8 @@ PoAネットワークでは、N人の認証された署名者がいる場合、
-## 関連トピック{#related-topics}
+## 関連トピック {#related-topics}
- [プルーフ・オブ・ワーク](/developers/docs/consensus-mechanisms/pow/)
- [プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)
+
diff --git a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
index 6674abbc459..25f756ed887 100644
--- a/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
+++ b/public/content/translations/ja/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
@@ -1,12 +1,12 @@
---
-title: イーサリアムのプルーフ・オブ・ステークにおける攻撃および防御
-description: イーサリアムのプルーフ・オブ・ステークに対する既知の攻撃ベクトルについて知り、防御方法について学ぶ
+title: "イーサリアムのプルーフ・オブ・ステークにおける攻撃および防御"
+description: "イーサリアムのプルーフ・オブ・ステークに対する既知の攻撃ベクトルについて知り、防御方法について学ぶ"
lang: ja
---
イーサリアムのクライアントソフトウェアは、常に窃盗や破壊行為の脅威にさらされています。 このページでは、イーサリアムのコンセンサスレイヤーに対する既知の攻撃ベクトルについて概説し、これらの攻撃をどのように防ぐべきかについて説明します。 このページの内容は、[こちらの長文バージョン](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)を要約したものです。
-## 前提知識 {#prerequisites}
+## 前提条件 {#prerequisites}
[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)の基本的な知識が必要です。 また、イーサリアムの[インセンティブレイヤー](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)とフォーク選択アルゴリズム、[LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper)について基礎的に理解しておくとよいでしょう。
@@ -14,7 +14,7 @@ lang: ja
イーサリアムに対する攻撃については、攻撃が成功した場合に新規のイーサを生成したり、ランダムに選んだアカウントからイーサを盗み取ることが可能だ、と誤解している人が多いです。 実際にはこれらは不可能です。なぜなら、イーサリアムにおけるすべてのトランザクションは、イーサリアム・ネットワークに含まれるすべての実行クライアントにより実行されるからです。 トランザクションが有効であるためには基本的な条件を満たす必要があり(送信者の秘密鍵を使って署名されており、送信者の残高が十分であるなど)、これらの条件を満たさない場合には、トランザクションを実行する前の状態に復元されます。 このため、攻撃者が現実的に望みうるのは、再編成、二重ファイナリティ、またはファイナリティの遅延という3つの結果だけです。
-**「再編成」**とは、ブロックの順番が変更されるようにシャッフルすることであり、正規チェーンに新たなブロックを追加したり、既存のブロックが削除される場合が多いです。 悪意に基づく再編成は特定のブロックを追加/削除することを目的とする場合があり、トランザクションをフロントランニング/バックランニングすることで、二重支出や価値の抜き取りが可能になります。 再編成はまた、特定のトランザクションが正規チェーンに追加されないようにするために用いられる場合もあり、これは一種の検閲を目指すものだと言えます。 再編成攻撃のうち最も極端なものは「ファイナリティの取消」であり、すでにファイナライズされたブロックを除去/置換するものです。 この攻撃では、攻撃者はステーキングされたイーサの合計のうち3分の1以上を破壊しなければなりません。この保証を「経済的なファイナリティ」と呼びますが、詳細については以下で説明します。
+「再編成」とは、ブロックの順番が変更されるようにシャッフルすることであり、正規チェーンに新たなブロックを追加したり、既存のブロックが削除される場合が多いです。 悪意に基づく再編成は特定のブロックを追加/削除することを目的とする場合があり、トランザクションをフロントランニング/バックランニングすることで、二重支出や価値の抜き取りが可能になります。 再編成はまた、特定のトランザクションが正規チェーンに追加されないようにするために用いられる場合もあり、これは一種の検閲を目指すものだと言えます。 再編成攻撃のうち最も極端なものは「ファイナリティの取消」であり、すでにファイナライズされたブロックを除去/置換するものです。 この攻撃では、攻撃者はステーキングされたイーサの合計のうち3分の1以上を破壊しなければなりません。この保証を「経済的なファイナリティ」と呼びますが、詳細については以下で説明します。
**二重ファイナリティ**とは、2つのフォークが同時にファイナライズ可能な状態に置かれ、チェーンに永続的な亀裂が生じるもので、発生確率は低いですが非常に深刻な状況だと言えます。 理論的には、攻撃者がステーキングされたETH全体の34%を失っても構わないと考える場合にこの状態が発生可能になります。 ユーザーコミュニティは、オフチェーンでの議論を通じてどのチェーンに従うかを決定することを迫られますので、ソーシャルレイヤーの強じんさが求められます。
@@ -22,7 +22,7 @@ lang: ja
ソーシャルレイヤーに対する攻撃は、イーサリアムに対する世間の信頼を毀損するため、イーサの価値や利用度を引き下げるため、あるいは、イーサリアム・コミュニティを弱体化させることにより、帯域外の連携を妨害することを目的とするかもしれません。
-以上が、攻撃者がイーサリアムを攻撃する理由として考えられるものです。以下のセクションでは、これらの攻撃を_どのように実行するか_について検討します。
+以上が、攻撃者がイーサリアムを攻撃する理由として考えられるものです。以下のセクションでは、これらの攻撃を _どのように_ 実行するかについて検討します。
## さまざまな攻撃手段 {#methods-of-attack}
@@ -31,10 +31,13 @@ lang: ja
まず、イーサリアム・ネットワークへの積極的な関与(クライアント・ソフトウェアを実行すること)を行わない攻撃者は、ソーシャルレイヤー(レイヤー0)を標的とする攻撃を行う可能性があります。 レイヤー0は、イーサリアム・ネットワークを構築するための土台であり、攻撃対象となった場合はその影響がスタックの他の部分に波及しかねません。 具体的には、以下のような攻撃が考えられます:
- 虚偽情報を流布するキャンペーンを行うことで、ユーザーコミュニティにおけるイーサリアムのロードマップ、開発者チーム、アプリ等に対する信頼を失わせる攻撃。 この攻撃は、イーサリアム・ネットワークのセキュリティを維持するために参加するユーザーの数を減少させることで、分散化および暗号経済的なセキュリティを低下させる意図を持ちます。
+
- 開発者コミュニティに対する標的を絞った攻撃および/または脅迫。 この攻撃により、開発者が自発的にコミュニティから退去し、イーサリアムの開発速度が遅れる可能性があります。
- 必要以上に規制を厳しくすることも、イーサリアムへの参加者数や利用度を大きく引き下げる可能性を持つため、レイヤー0に対する攻撃と見なすことが可能です。
+
- 関連知識を持つ悪意のアクターが開発者コミュニティに侵入する場合。ここでの目的は、些末な議論を繰り広げたり、重要な判断を遅らせたり、スパムを送信するなどの方法により、イーサリアムの開発を遅らせることです。
+
- イーサリアムのエコシステムに含まれるキープレイヤーに対して賄賂を提供して、意思決定に影響を及ぼそうとする行為。
これらの攻撃がとりわけ危険な理由は、ごくわずかな資本あるいは技術的ノウハウしか持たない者でも実行が可能である場合が多いためです。 レイヤー0攻撃は、暗号経済的な攻撃の被害をさらに拡大する可能性があります。 例えば、悪意のある多数派のステークホルダーにより検閲やファイナリティの撤回が達成された場合、ソーシャルレイヤーが弱体化していれば、帯域外においてユーザーコミュニティ全体が団結して対応することが難しくなるかもしれません。
@@ -55,9 +58,9 @@ lang: ja
#### 再編成 {#reorgs}
-ステーキングされたイーサ全体のごく一部を用いて、チェーンの再編成またはファイナリティの遅延を実行するという攻撃については、すでにいくつかのペーパーにより詳説されています。 これらの攻撃は通常、攻撃者以外のバリデータに対して一部の情報を秘匿しておき、特定のニュアンスを持つ方法で、および/または攻撃者にとって有利な時点で、その情報を公開するという手段を用います。 攻撃者は通常、一部の誠実なブロック(複数の場合あり)を正規チェーンから削除することを目的とします。 [ノイダー他(2020年)](https://arxiv.org/pdf/2102.02247.pdf)の論文では、攻撃者であるバリデータが特定のスロット `n+1` に対してブロック(`B`) を作成し、アテステーションを実行しつつ、ネットワークの他のノードへの送信を控える方法について説明しています。 攻撃者は、アテステーションを実行したブロックを次のスロット(`n+2`まで公開せずに残しておきます。 誠実なバリデータは、あるブロック(`C`)を`n+2`スロットに提案します。 攻撃者は、これとほぼ同時に、秘匿していたブロック(`B`)およびこれに対するアテステーションをリリースし、さらに、十分な投票権と共にスロット`n+2`におけるチェーンの先頭が`B`であるというアテステーションを実行することで、誠実なブロック`C`の存在を事実上否定することができます。 誠実なブロック `D` がリリースされると、フォーク選択アルゴリズムにより、ブロック`B`上で構築された`D`の方が、ブロック`C`上で構築されたブロック`D`よりも重みが大きいと判断します。 つまり攻撃者は、1つ後のブロックにおけるチェーンの再編成により、スロット`n+2`における誠実なブロック`C`を正規チェーンから削除することが可能になるのです。 [攻撃者がステーク全体の34%を保有する場合](https://www.youtube.com/watch?v=6vzXwwk12ZE)、[この注記](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)で述べられているように、この攻撃が成功する可能性は非常に高いと言えます。 さらに、理論的にはより少ない割合のステークでもこの攻撃を試みることが可能です。 [ノイダー他(2020年)](https://arxiv.org/pdf/2102.02247.pdf)では、この攻撃は30%ステークでも可能だと述べていますが、その後の研究により、[ステーク全体のわずか2%](https://arxiv.org/pdf/2009.04987.pdf)を保有するだけでこの攻撃が可能であると判明しました。この場合、[単独のバリデータ](https://arxiv.org/abs/2110.10086#)によるバランシングのテクニックが用いられますが、これについては以下のセクションで検証します。
+ステーキングされたイーサ全体のごく一部を用いて、チェーンの再編成またはファイナリティの遅延を実行するという攻撃については、すでにいくつかの論文により詳説されています。 これらの攻撃は通常、攻撃者以外のバリデータに対して一部の情報を秘匿しておき、特定のニュアンスを持つ方法で、および/または攻撃者にとって有利な時点で、その情報を公開するという手段を用います。 攻撃者は通常、一部の誠実なブロック(複数の場合あり)を正規チェーンから削除することを目的とします。 [ノイダー他(2020年)の論文](https://arxiv.org/pdf/2102.02247.pdf)では、攻撃者であるバリデータが特定のスロット `n+1` に対してブロック(`B`) を作成し、アテステーションを実行しつつ、ネットワークの他のノードへの送信を控える方法について説明しています。 攻撃者は、アテステーションを実行したブロックを次のスロット(`n+2`まで公開せずに残しておきます。 誠実なバリデータは、あるブロック(`C`)を`n+2`スロットに提案します。 攻撃者は、これとほぼ同時に、秘匿していたブロック(`B`)およびこれに対するアテステーションをリリースし、さらに、十分な投票権と共にスロット`n+2`におけるチェーンの先頭が`B`であるというアテステーションを実行することで、誠実なブロック`C`の存在を事実上否定することができます。 誠実なブロック`D`がリリースされると、フォーク選択アルゴリズムにより、ブロック`B`上で構築された`D`の方が、ブロック`C`上で構築されたブロック`D`よりも重みが大きいと判断します。 つまり攻撃者は、1つ後のブロックにおけるチェーンの再編成により、スロット`n+2`における誠実なブロック`C`を正規チェーンから削除することが可能になるのです。 [攻撃者がステーク全体の34%を保有する場合](https://www.youtube.com/watch?v=6vzXwwk12ZE) 、[この注記](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)で述べられているように、この攻撃が成功する可能性は非常に高いと言えます。 さらに、理論的にはより少ない割合のステークでもこの攻撃を試みることが可能です。 [ノイダー他(2020年)](https://arxiv.org/pdf/2102.02247.pdf)では、この攻撃は30%ステークでも可能だと述べていますが、その後の研究により、[ステーク全体のわずか2%](https://arxiv.org/pdf/2009.04987.pdf)を保有するだけでこの攻撃が可能であると判明しました。この場合、[単独のバリデータ](https://arxiv.org/abs/2110.10086#) によるバランシングのテクニックが用いられますが、これについては以下のセクションで検証します。
-
+
上記の1ブロック後の再編成攻撃の概念図 (https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair を修正)
@@ -67,7 +70,7 @@ lang: ja
-バランシング攻撃およびバウンス攻撃のいずれも、ネットワークにおけるメッセージ送信のタイミングを攻撃者が非常に細かく制御できなければならず、実際に発生する可能性は高くありません。 攻撃の可能性は低いものの、これらの攻撃に対する防御手段として、プロトコルにおいては迅速なメッセージがよりメッセージよりも重みが大きくなるように設定されています。 これは、[提案者重みブースティング](https://github.com/ethereum/consensus-specs/pull/2730)と呼ばれています。 また、バウンス攻撃を回避するため、正当化された最新のチェックポイントを代替のチェーンに切り替えできる時期が[エポック全体の前半3分の1のスロット](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)のみとなるようにフォーク選択アルゴリズムが修正されました。 この条件により、攻撃者が後で投票するための投票権を蓄積することが不可能になりました。フォーク選択アルゴリズムは、大部分の誠実なバリデータが投票するであろう各エポックの前半3分の1の時間内において選択されたチェックポイントをそのまま選択し続けるからです。
+バランシング攻撃およびバウンス攻撃のいずれも、ネットワークにおけるメッセージ送信のタイミングを攻撃者が非常に細かく制御できなければならず、実際に発生する可能性は高くありません。 攻撃の可能性は低いものの、これらの攻撃に対する防御手段として、プロトコルにおいては迅速なメッセージがよりメッセージよりも重みが大きくなるように設定されています。 これは、[提案者加重ブースティング](https://github.com/ethereum/consensus-specs/pull/2730)と呼ばれています。 また、バウンス攻撃を回避するため、正当化された最新のチェックポイントを代替のチェーンに切り替えできる時期が[エポック全体の前半3分の1のスロット](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)のみとなるようにフォーク選択アルゴリズムが修正されました。 この条件により、攻撃者が後で投票するための投票権を蓄積することが不可能になりました。フォーク選択アルゴリズムは、大部分の誠実なバリデータが投票するであろう各エポックの前半3分の1の時間内において選択されたチェックポイントをそのまま選択し続けるからです。
これらの対策を組み合わせた場合、誠実なブロック提案者が各スロットの開始時点でただちにブロックを送信するが、スロットの前半3分の1(4秒間)においては、新規ブロックの生成によりフォーク選択アルゴリズムを通じて他のチェーンへの切り替えが可能な状態が発生するというシナリオが想定されます。 この締切時間が到来した後は、作業が遅いバリデータから送信されたアテステーションは、作業が早いバリデータからのアテステーションよりも重みが小さくなるのです。 これにより、チェーンの先頭を決定する作業において迅速に行動した提案者およびバリデータが有利になるため、バランシング攻撃やバウンス攻撃が成功する確率を大きく引き下げることができます。
@@ -81,23 +84,23 @@ lang: ja
アバランチ攻撃の脅威は、LMD-GHOSTというフォーク選択アルゴリズムのLMDによって軽減されます。 LMDとは、「最新メッセージ主導型」を意味し、各バリデータが維持し、他のバリデータから受信する最新のメッセージが含まれている表を指しています。 このフィールドが更新されるのは、各バリデータの表においてすでに記入済みであるスロットよりも後のスロットにおいて新規メッセージを受信した場合のみです。 これにより、実際には各スロットにおいて最初に受信されたメッセージが認証され、その後のすべてのメッセージは曖昧化をもたらすものとして却下されます。 つまり、コンセンサス・クライアントは曖昧化をもたらすメッセージを考慮せず、各バリデータから最初に受信したメッセージのみを採用し、その後の曖昧化させるメッセージは単に無視されるため、アバランチ攻撃が不可能になります。
-提案者の重み追加が提供するセキュリティをさらに強めるために、フォーク選択ルールに対しては今後もいくつかのアップデート案が検討されています。 そのうちの1つが [ビュー・マージ](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739)であり、アテステーションを行うユーザーは、各自のフォーク選択のビューが当該スロットが開始される`n`秒前にフリーズされるため、提案者はネットワーク全体にわたるチェーンビューを同期しやすくなります。 もう1つのアップグレード案は、 [シングルスロット・ファイナリティ](https://notes.ethereum.org/@vbuterin/single_slot_finality)であり、1スロット後にチェーンをファイナライズすることにより、メッセージを送信するタイミングに基づいた攻撃を回避するというものです。
+提案者の重み追加が提供するセキュリティをさらに強めるために、フォーク選択ルールに対しては今後もいくつかのアップデート案が検討されています。 そのうちの1つが[ビュー・マージ](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739)であり、アテステーションを行うユーザーは、各自のフォーク選択のビューが当該スロットが開始されるn秒前にフリーズされるため、提案者はネットワーク全体にわたるチェーンビューを同期しやすくなります。 もう1つのアップグレード案は、 [シングルスロット・ファイナリティ](https://notes.ethereum.org/@vbuterin/single_slot_finality)であり、1スロット後にチェーンをファイナライズすることにより、メッセージを送信するタイミングに基づいた攻撃を回避するというものです。
#### ファイナリティ遅延 {#finality-delay}
-低コストで単一ブロックを対象とする再編成攻撃について説明したのと[同じ論文](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf)では、さらに、攻撃者がエポックの境界となるブロックの提案者となることで実行可能になるファイナリティ遅延(「生存性障害」とも呼ばれます)攻撃についても説明されています。 この攻撃が非常に重要であるのは、エポック境界ブロックはキャスパーFFGがチェーンの各部分をファイナライズするために参照するチェックポイントになるためです。 攻撃者は、ひとつ前のエポック境界ブロックを現在のファイナライズ対象にすることを支持する誠実なバリデータによる投票が十分に集まるまで、自分のブロックを保留するだけでよいのです。 攻撃者はその上で、保留してきたブロックをリリースします。 彼らは自らのブロックに対するアテステーションを実行し、攻撃者以外の誠実なバリデータも同様に実行するので、ターゲットのチェックポイントが異なる複数のフォークが作成されてしまうのです。 適切なタイミングで実行された場合、いずれのフォークに対するアテステーションにおいても3分の2のスーパーマジョリティを得られないため、ファイナリティを実現できなくなります。 この場合、ステークの規模が小さければ小さいほど、攻撃が成功する実行のタイミングが狭まります。と言うのも、攻撃者が直接支配するアテステーションの数がより少なくなり、特定のエポック境界ブロックを提案するバリデータを攻撃者が支配する可能性が低くなるからです。
+低コストで単一ブロックを対象とする再編成攻撃について説明したのと[同じ論文](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) では、さらに、攻撃者がエポックの境界となるブロックの提案者となることで実行可能になるファイナリティ遅延(「生存性障害」とも呼ばれます)攻撃についても説明されています。 この攻撃が非常に重要であるのは、エポック境界ブロックはキャスパーFFGがチェーンの各部分をファイナライズするために参照するチェックポイントになるためです。 攻撃者は、ひとつ前のエポック境界ブロックを現在のファイナライズ対象にすることを支持する誠実なバリデータによる投票が十分に集まるまで、自分のブロックを保留するだけでよいのです。 攻撃者はその上で、保留してきたブロックをリリースします。 彼らは自らのブロックに対するアテステーションを実行し、攻撃者以外の誠実なバリデータも同様に実行するので、ターゲットのチェックポイントが異なる複数のフォークが作成されてしまうのです。 適切なタイミングで実行された場合、いずれのフォークに対するアテステーションにおいても3分の2のスーパーマジョリティを得られないため、ファイナリティを実現できなくなります。 この場合、ステークの規模が小さければ小さいほど、攻撃が成功する実行のタイミングが狭まります。と言うのも、攻撃者が直接支配するアテステーションの数がより少なくなり、特定のエポック境界ブロックを提案するバリデータを攻撃者が支配する可能性が低くなるからです。
#### ロングレンジ攻撃 {#long-range-attacks}
プルーフ・オブ・ステークを採用したブロックチェーン特有のもう一つの攻撃カテゴリーとして、ジェネシスブロックの作成に関与したバリデータが誠実なチェーンとは異なる別途のフォークを維持し、最終的に誠実なバリデータ群に対し、かなりの時間を経た適当なタイミングで代替フォークに移行するように説得するという手法があります。 イーサリアムにおいては、ファイナリティ・ガジェットによりすべてのバリデータが誠実なチェーンについて定期的な感覚(「チェックポイント」)において同意する必要があるため、この種の攻撃は実行できません。 このシンプルなメカニズムによりイーサリアムのクライアントにおいてはファイナライズされたブロックの再編成が不可能であり、ロングレンジ攻撃は無効化されます。 イーサリアム・ネットワークに新たに参加するノードは、信頼できる最新状態のハッシュ(「[弱い主観性](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)チェックポイント」)を見つけ、このチェックポイントを疑似的なジェネシスブロックとして、その上に新たなブロックを作成します。 この方法により、新たにネットワークに参加するノードに対して「信頼性ゲートウェイ」が提供され、ノード自身が情報を検証できるようになります。
-#### サービス拒否 (DOS) {#denial-of-service}
+#### サービス拒否 (DOS) {#denial-of-service}
-イーサリアムにおけるプルーフ・オブ・ステークのメカニズムでは、すべてのバリデータの中から、各スロットにおけるブロック提案者として1名のバリデータを選出します。 この選出は公開された関数を用いて計算できるため、攻撃者は、ブロック提案のタイミングをわずかに先立つ時点で次のブロック提案者を特定することが可能です。 攻撃者はこの情報を得ることで、次のブロック提案者にスパムを送信し、他のピアとの情報交換を妨げることができます。 ネットワークの他のユーザーにとっては、次のブロック提案者がオフラインになり、スロットは空のままであるように見えます。 これは、特定のバリデータを対象とする一種の検閲として機能させることができ、それらのユーザーがブロックチェーンに情報を追加するのを妨害することが可能です。 単独非公開リーダー選挙(SSLE)あるいは非単独非公開リーダー選挙を実施する場合、当該のブロック提案者自身のみが提案者に選出されたことを知ることができ、選出を事前に知ることが不可能になるため、DoSリスクを軽減することができます。 このようなメカニズムはまだ実装されていませんが、積極的な[研究開発](https://ethresear.ch/t/secret-non-single-leader-election/11789)が進められています。
+イーサリアムにおけるプルーフ・オブ・ステークのメカニズムでは、すべてのバリデータの中から、各スロットにおけるブロック提案者として1名のバリデータを選出します。 この選出は公開された関数を用いて計算できるため、攻撃者は、ブロック提案のタイミングをわずかに先立つ時点で次のブロック提案者を特定することが可能です。 攻撃者はこの情報を得ることで、次のブロック提案者にスパムを送信し、他のピアとの情報交換を妨げることができます。 ネットワークの他のユーザーにとっては、次のブロック提案者がオフラインになり、スロットは空のままであるように見えます。 これは、特定のバリデータを対象とする一種の検閲として機能させることができ、それらのユーザーがブロックチェーンに情報を追加するのを妨害することが可能です。 単独非公開リーダー選挙(SSLE)あるいは非単独非公開リーダー選挙を実施する場合、当該のブロック提案者自身のみが提案者に選出されたことを知ることができ、選出を事前に知ることが不可能になるため、DoSリスクを軽減することができます。 これはまだ実装されていませんが、活発な[研究開発](https://ethresear.ch/t/secret-non-single-leader-election/11789)分野です。
以上の説明はすべて、ステークが小規模なユーザーがイーサリアムへの攻撃を成功させることが非常に困難であることを示しています。 ここで紹介した実行可能な攻撃はいずれも、理想的なフォーク選択アルゴリズム、非現実的なネットワーク状況、あるいはクライアント・ソフトウェアに対する比較的小規模なパッチ修正によりすでに実行不可能になった攻撃ベクトルを前提としています。 もちろん、ゼロデイ攻撃が発生する可能性を否定することはできませんが、小規模のステークに基づく攻撃が成功するためには、非常に高い水準の技術的な能力、コンセンサスレイヤーに関する知識、および運が要求されることを示しています。 攻撃者の立場で考えた場合、できるだけ多くのイーサを蓄積した上で、ステーク全体に対する支配力を高めることが攻撃の成功率を高める最善の手段だと言うことになるでしょう。
-### >= 33%のステークを用いた攻撃 {#attackers-with-33-stake}
+### ステーク全体の33%以上を支配する攻撃者の場合 {#attackers-with-33-stake}
これまでに紹介したすべての攻撃手段は、攻撃者が投票できるステークの規模を大きくし、各スロットでブロックを提案するバリデータとして選出される可能性が高まるほど、成功する確率が高まります。 従って、悪意のバリデータはできる限り多くのステーキングされたイーサを支配しようとするでしょう。
@@ -107,11 +110,11 @@ lang: ja
イーサリアム・ネットワークが非同期型である(つまり、メッセージの送受信に遅延が生じる)と想定すると、ステーク全体の34%を支配する攻撃者は二重ファイナリティを発生させることができます。 これは、攻撃者がブロック作成者に選出された場合、曖昧化を実行し、支配するバリデータ全員と共に二重投票が可能になるからです。 これは、ブロックチェーンに分岐が発生し、それぞれのフォークに対してステークされたイーサの34%が投票するという事態を招きます。 各フォークがスーパーマジョリティの支持を得るには、残りのバリデータのうち50%の投票を得ればよいので、どちらのチェーンもファイナライズが可能になってしまいます(つまり、攻撃者であるバリデータの34%と、残余のバリデータの66%の半分を足すと、各フォークが67%を達成できます)。 競合するブロックは誠実なバリデータのうちおよそ50%の投票を得る必要があるので、この攻撃が成功するためには、ネットワークにメッセージが伝播される他ミングを攻撃者がある程度管理でき、誠実なバリデータを各チェーンに半分づつ振り分けられなければなりません。 攻撃者がこの二重ファイナリティを達成するには、支配下である34%のバリデータは二重投票を同時に実行する必要があり、これは最大の相関ペナルティが科せられるスラッシング対象の違反行為であるため、攻撃者のステーク全体(現在、バリデータによる合計ステークはおよそ1,000万イーサなので、その34%)を破壊する必要があります。 この攻撃に対する防御策は、ステークされたイーサ全体の34%を破壊することであるため、非常に大きなコストを伴います。 この攻撃から復旧するには、イーサリアム・コミュニティ全体が「帯域外」で連携し、フォークの一方を正当として、もう一方を破棄することに同意する必要があります。
-### ステーク全体の最大50%を支配する攻撃者の場合 {#attackers-with-50-stake}
+### ステーク全体の最大50%を支配する攻撃者の場合 {#attackers-with-50-stake}
悪意のバリデータ集団がステークされたイーサ全体の50%に対する支配力を持つ場合、理論的にはチェーンを同サイズの2つのフォークに分割し、彼らが持つ50%のステーク全体を用いて誠実なバリデータ群とは異なる投票を行うことで、2つのフォークが存在する状態を維持し、ファイナリティの実現を妨げることができます。 最終的には、両方のフォークに対するインアクティブ・リークを実行することで、両方のチェーンがファイナライズされることになるでしょう。 この場合は、ソーシャルリカバリーの力に頼るしかありません。
-誠実なバリデータ数やネットワーク遅延などの値が常に流動的であることを考慮すると、悪意のバリデータ集団がステーク全体に対して正確に50%の支配権を維持できる可能性はきわめて低く、このような攻撃の実行は非常にコストが高く、成功率が低いことを考えると、特にわずかな追加投資により50%_以上_のステークを取得すればさらに大きな攻撃力を得られることを考えると、合理的な攻撃者がこの手段を講じる可能性は少ないと言えるでしょう。
+誠実なバリデータ数やネットワーク遅延などの値が常に流動的であることを考慮すると、悪意のバリデータ集団がステーク全体に対して正確に50%の支配権を維持できる可能性はきわめて低く、このような攻撃の実行は非常にコストが高く、成功率が低いことを考えると、特にわずかな追加投資により _50%以上_ のステークを取得すればさらに大きな攻撃力を得られることを考えると、合理的な攻撃者がこの手段を講じる可能性は少ないと言えるでしょう。
攻撃者がステーク合計の50%以上を支配する場合、フォーク選択アルゴリズムを操作することが可能になります。 この場合、攻撃者は多数派の投票に基づくアテステーションが可能になるため、誠実なクライアントを騙す必要なしに、ショートレンジの再編成攻撃を実行するために十分な支配権を持つことになります。 この場合、誠実なバリデータも、彼らのフォーク選択アルゴリズムが攻撃者の選好チェーンの重みが最も大きいと判断するために攻撃者の支持に従い、チェーンがファイナライズ可能になります。 攻撃者は、このメカニズムを通して特定のトランザクションに対する検閲やショートレンジの再編成攻撃を実行することで、自らが有利になるようにブロックを再編成し、最大限のMEVを抽出することが可能になります。 この攻撃を防ぐには、ソーシャルレイヤーの介入により、誠実な少数派フォークを正当と認識することで、攻撃者のステークが持つ価値を大幅に引き下げる必要がありますが、これは同時に多数派のステーク全体(現時点の価値は190億米ドル弱)を攻撃のリスクに晒すことを意味します。
@@ -127,13 +130,13 @@ lang: ja
さらに、攻撃者に科されるペナルティがどのようなものであれ、ユーザーコミュニティ全体が、イーサリアム・クライアントに搭載されたフォーク選択アルゴリズムにより選好されているが不正であるチェーンにつき、実際にそれが不正なチェーンであり、誠実なチェーン上でのブロック生成に戻るべきだということを決定しなければなりません。 誠実なバリデータ群は、攻撃が開始される前に正規チェーンから分岐した、ユーザーコミュニティが承認したイーサリアム・ブロックチェーンのフォークにおいて今後の開発を継続するか、あるいは、攻撃者の支配下にあるバリデータを強制的に排除するかについて、集団的に同意することが可能でしょう。 誠実なバリデータは、攻撃者のチェーンに対するアテステーションを実行しないという正しい行動に対してペナルティが科せられるのを避けたいと考えるため、この正規チェーンで開発を続行するインセンティブが存在します。 イーサリアム上で開発された取引所、オンランプ、およびアプリケーションは、誠実なチェーン上での利用を望むと予想されるので、誠実なバリデータの決定に従って誠実なブロックチェーンを選択するでしょう。
-しかし、これはガバナンス上の大きな問題をもたらします。 一部のユーザーおよびバリデータは誠実なチェーンへの再移行に伴い確実に自分の資産を失うことになり、攻撃後に確定したブロック内のトランザクションはロールバックされる可能性がありあるため、アプリケーションレイヤーにおいて混乱が発生します。つまり、「コードは法である」という確信が強い一部のユーザーの倫理観が揺らいでしまうのです。 取引所およびアプリケーションにおいては、すでにオフチェーンにおけるアクションをオンチェーンのトランザクションとを関連付けている可能性が高く、オンチェーンのトランザクションをロールバックするとなると、取消や修正が相次ぐことになりますが、特に不正に獲得した利益がすでに正当な利益混合しており、DeFIやその他のデリバティブにおいて入金されている場合、誠実なユーザーに対しても二次的な影響を及ぼすため、公平な方法で元の状態に戻すのは困難になるでしょう。 おそらく組織ユーザーをも含む一部のユーザーは、意図的または偶然によりすでに不正なチェーンから何らかの利益を得ているはずであり、この利益を守るために正規フォークへの再移行に反対するかもしれません。 コミュニティ全体の連携に基づく賢明なリスク軽減策を迅速に実行できる体制を整えておくために、51%攻撃に対するコミュニティ全体の対応をリハーサルするべきだという声も多いです。 ヴィタリクによるethresear.chでの有益な議論については、[こちら](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925)と[こちら](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363)、そしてTwitterの[こちら](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)でご確認ください。 コミュニティ全体が連携したソーシャル対応は、攻撃者を罰し、他のユーザーへの影響を最小化するという具体的な目的に絞り込む必要があります。
+しかし、これはガバナンス上の大きな問題をもたらします。 一部のユーザーおよびバリデータは誠実なチェーンへの再移行に伴い確実に自分の資産を失うことになり、攻撃後に確定したブロック内のトランザクションはロールバックされる可能性がありあるため、アプリケーションレイヤーにおいて混乱が発生します。つまり、「コードは法である」という確信が強い一部のユーザーの倫理観が揺らいでしまうのです。 取引所およびアプリケーションにおいては、すでにオフチェーンにおけるアクションをオンチェーンのトランザクションとを関連付けている可能性が高く、オンチェーンのトランザクションをロールバックするとなると、取消や修正が相次ぐことになりますが、特に不正に獲得した利益がすでに正当な利益混合しており、DeFIやその他のデリバティブにおいて入金されている場合、誠実なユーザーに対しても二次的な影響を及ぼすため、公平な方法で元の状態に戻すのは困難になるでしょう。 おそらく組織ユーザーをも含む一部のユーザーは、意図的または偶然によりすでに不正なチェーンから何らかの利益を得ているはずであり、この利益を守るために正規フォークへの再移行に反対するかもしれません。 コミュニティ全体の連携に基づく賢明なリスク軽減策を迅速に実行できる体制を整えておくために、51%攻撃に対するコミュニティ全体の対応をリハーサルするべきだという声も多いです。 ヴィタリクによるethresear.chでの有益な議論については、[こちら](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) と[こちら](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363)、そしてTwitterの[こちら](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)でご確認ください。 コミュニティ全体が連携したソーシャル対応は、攻撃者を罰し、他のユーザーへの影響を最小化するという具体的な目的に絞り込む必要があります。
-ブロックチェーンのガバナンスは、それ自体が複雑なトピックです。 不正なバリデータがファイナライズしてしまったチェーンに対するレイヤー0の緊急対応をいかに管理するかは、イーサリアムコミュニティにとって間違いなく大きな課題であり、イーサリアムの歴史において、すでに[2回](/ethereum-forks/#dao-fork-summary)[も発生しています](/ethereum-forks/#tangerine-whistle)。
+ブロックチェーンのガバナンスは、それ自体が複雑なトピックです。 不正なバリデータがファイナライズしてしまったチェーンに対するレイヤー0の緊急対応をいかに管理するかは、イーサリアムコミュニティにとって間違いなく大きな課題であり、イーサリアムの歴史において、すでに[2回](/ethereum-forks/#tangerine-whistle)も[発生](/ethereum-forks/#dao-fork-summary)しています。
しかしながら、最悪の事態においても現実世界において解決策を見出せるという事実には、やや安堵感を覚えます。 究極的に、私たちが利用しているこの驚くべきテクノロジースタックにおいても、最悪の事態が発生した場合には、ユーザーである実際の人間たちが議論を通じて解決策を見出すしかないのです。
-## 要約 {#summary}
+## まとめ {#summary}
この記事では、イーサリアムにおけるプルーフ・オブ・ステークのコンセンサス・プロトコルを悪用する攻撃手法のいくつかについて説明しました。 攻撃者のステークがイーサ全体に対してどの程度の割合を占めるかに応じて、再編成攻撃やファイナリティ遅延攻撃がどのように変化するのかについても掘り下げました。 一般論として、資金が潤沢である攻撃者は、より大きな投票権を持ち、以後のブロックの内容に対して影響力を及ぼせるため、攻撃が成功する可能性が高まります。 攻撃者の攻撃能力は、ステークしたイーサの割合が特定のしきい値を越えるに従って増加します:
@@ -151,13 +154,13 @@ lang: ja
一方で、34%攻撃、51%攻撃、あるいは66%攻撃に対しては帯域外のソーシャルな連携による解決が必要になる場合が多いです。 これはユーザーコミュニティにとって痛みを伴うものですが、帯域外での連携による対応が可能だという事実は、攻撃者にとって大きな抑止効果を持ちます。 イーサリアムのソーシャルレイヤーは最終的な防御手段であり、攻撃が技術的に成功した場合でも、コミュニティが誠実なフォークを選択することに同意できれば、攻撃を無力化することができます。 これは、攻撃者とイーサリアム・コミュニティとの間の争いとなるでしょう。つまり、66%攻撃を実行するために数十億ドルもの資金を投じたとしても、ソーシャル連携を通じて反撃を迅速に実行できれば、攻撃者は、イーサリアム・コミュニティにとって無意味である既知の不正チェーンにステークされた、換金不可能なイーサを背負い込むことになるだけだからです。 攻撃者にとってはこの攻撃から利益を上げられる可能性が非常に低くなるため、事実上の効果的な抑止力として機能します。 これこそ、緊密に連携した価値観に基づき、団結力を持つソーシャルレイヤーを維持するために投資することが重要である理由です。
-## さらに学びたい方へ {#further-reading}
+## 参考リンク {#further-reading}
- [本記事の詳細版](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
- [ヴィタリックによる決済のファイナリティに関する説明](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
-- [LMD-GHOSTについての論文](https://arxiv.org/abs/2003.03052)
-- [Casper-FFGについての論文](https://arxiv.org/abs/1710.09437)
-- [ガスパーについての論文](https://arxiv.org/pdf/2003.03052.pdf)
-- [提案者の加重ブーストに関するコンセンサス仕様](https://github.com/ethereum/consensus-specs/pull/2730)
-- [ethresear.chに対するバウンス攻撃](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
-- [SSLEについてのリサーチ](https://ethresear.ch/t/secret-non-single-leader-election/11789)
+- [LMD GHOSTの論文](https://arxiv.org/abs/2003.03052)
+- [Casper-FFG ペーパー](https://arxiv.org/abs/1710.09437)
+- [Gasperの論文](https://arxiv.org/pdf/2003.03052.pdf)
+- [提案者加重ブーストのコンセンサス仕様](https://github.com/ethereum/consensus-specs/pull/2730)
+- [バウンス攻撃(ethresear.ch)](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
+- [SSLEの研究](https://ethresear.ch/t/secret-non-single-leader-election/11789)