diff --git a/mkdocs/config/mkdocs.ja.yml b/mkdocs/config/mkdocs.ja.yml index 63e80c621..1128b9e7e 100644 --- a/mkdocs/config/mkdocs.ja.yml +++ b/mkdocs/config/mkdocs.ja.yml @@ -75,4 +75,15 @@ nav: - devbook/reference/whitepaper/index.md - 教科書: - textbook/intro.md + - textbook/cryptography.md + - textbook/accounts.md + - textbook/consensus.md + - textbook/transactions.md + - textbook/transfer_transactions.md + - textbook/mosaics.md + - textbook/namespaces.md + - textbook/blocks.md + - textbook/nodes.md + - textbook/harvesting.md + - textbook/cats.md - textbook/glossary.md diff --git a/mkdocs/pages/ja/index.md b/mkdocs/pages/ja/index.md index 70d9d5d2a..679bacc93 100644 --- a/mkdocs/pages/ja/index.md +++ b/mkdocs/pages/ja/index.md @@ -14,7 +14,7 @@ disable_actions: true

ユーザーマニュアル

-

コーディングなしで何かをすることを学ぶ。

+

コーディングなしで、色々なことをする方法を学びます

 @@ -22,15 +22,15 @@ disable_actions: true

開発者マニュアル

-

コーディングで何かを学ぶ。

+

コーディングして、色々なことをする方法を学びます
-

教科書

-

物の仕組みを学ぶ。

+

テキストブック

+

仕組みを学びます
diff --git a/mkdocs/pages/ja/textbook/accounts.md b/mkdocs/pages/ja/textbook/accounts.md new file mode 100644 index 000000000..e5feaff80 --- /dev/null +++ b/mkdocs/pages/ja/textbook/accounts.md @@ -0,0 +1,201 @@ +# アカウント + +アカウント +: 暗号資産や [NFT](default:NFT) などのデジタル資産を安全に保管する場所です。 + 従来の銀行における貸金庫に似た役割を果たします。 + +ブロックチェーンでは、アカウントは [キーペア](default:キーペア) によって保護されます。秘密鍵を使うことでのみアカウントから資産を **送金** でき、公開鍵を共有することで自由に **受け取る** ことができます。 + +公開鍵は利便性のため通常 [アドレス](default:アドレス) として共有され、「アカウント」と「アドレス」は同義語として使われます。 + +アカウントはデジタル資産を管理するだけでなく、秘密鍵の所有権を表し、デジタルアイデンティティとしての役割も果たします。 +ブロックチェーン上では、アカウントはトランザクションの承認、権限設定、[コンセンサス](default:コンセンサス) への参加が可能です。 + +!!! note "アカウントのライフサイクル" + + アカウントは、たとえば資産を受け取るなど、ブロックチェーンと初めてやり取りした時点で有効になります。 + 有効になる前は、アカウントに関する情報はチェーン上に記録されず、ブロックエクスプローラーにも表示されません。 + + 一度有効化されたアカウントは資産をすべて引き出すことはできますが、ブロックチェーンから削除することはできません。 + +## ニーモニック {: #mnemonics } + +ニーモニックフレーズ +: [秘密鍵](default:秘密鍵) を人間が読みやすい形で表したもので、通常は12個または24個のランダムな単語のリストとして表示されます。 + +一般的に「ニーモニック」とも呼ばれ、[HDウォレット](default:HDウォレット) でアカウントを作成または復元する際によく使用されます。 + +NEM は、24個の英単語を必要とする [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) 標準に準拠しています。 + +!!! warning "ニーモニックは秘密鍵と同様に扱ってください" + + ニーモニックフレーズにアクセスできると、そこから生成されたすべてのアカウントに完全にアクセスできます。 + 決して共有せず、暗号化されていないデジタル形式で保存しないでください。 + +## ウォレット {: #wallets } + +ウォレット +: NEM アカウントを管理し、[トランザクション](default:トランザクション) を開始して署名するためのアプリケーションです。 + +[秘密鍵](default:秘密鍵) または [ニーモニックフレーズ](default:ニーモニックフレーズ) を保管し、それらを使ってトランザクションに署名します。 +より広い意味では、ブロックチェーンを探索して操作するためのツールを提供します。 + +ウォレットには次の種類があります。 + +* :material-application-outline: **ソフトウェアウォレット** + + デスクトップまたはモバイル端末にインストールするアプリケーションです。 + + 通常はすべての機能を提供しますが、セキュリティリスクは高くなります。 + ブロックチェーンとやり取りするにはソフトウェアウォレットがオンラインになっている必要があり、パスワードで保護されていても、保存された秘密鍵が漏えいする可能性があります。 + +* :material-integrated-circuit-chip: **ハードウェアウォレット** + + 鍵をオフラインで保管する外部デバイスです。 + + 主に安全なトランザクション署名を目的としており、操作にはソフトウェアウォレットに接続する必要があります。 + + 内部にある秘密鍵は、明示的にバックアップする場合を除いてデバイス外に出ないため、非常に高い安全性を持ちます。 + +ほとんどのウォレットでは、複数アカウントの管理、QR コードのスキャン（署名やトランザクション署名の要求）、[マルチシグアカウント](default:マルチシグアカウント) の設定が可能です。 +アカウントは [秘密鍵](default:秘密鍵) または [ニーモニックフレーズ](default:ニーモニックフレーズ) を使ってインポートまたはエクスポートすることもできます。 + +## HDウォレット {: #hd-wallets } + +HDウォレット +: 階層的決定性（HD）[ウォレット](default:ウォレット) で、単一のシードから複数の [アカウント](default:アカウント) を生成します。 + 複数の [キーペア](default:キーペア) を管理するより便利です。 + +複数アカウントの管理が簡単になりますが、シードが侵害されるとそこから導出されたすべてのアカウントが侵害されるため、シードの保護には特に注意が必要です。 +シードは通常 [ニーモニックフレーズ](default:ニーモニックフレーズ) です。 + +ほとんどのウォレットは HD ウォレットです。 + +NEM は [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 標準を使用して、シードからアカウントを生成します。 + +## マルチシグアカウント {: #multisignature-accounts } + +マルチシグアカウント +: トランザクションを承認するために複数の当事者（**連署人**）からの署名を必要とする [アカウント](default:アカウント)（**マルチシグ**と呼ばれます）です。 + +マルチシグアカウントは次のように設定します。 + +* 連署人の一覧を定義する。 +* トランザクションの承認に必要な、合計 **N** 人の連署人のうちの **最小人数 M** を設定する。 + これは **M-of-N** マルチシグと呼ばれます。 + **M** を **N** と同じにすると（**N-of-N** マルチシグ）、すべての連署人の署名が必要になります。 + +たとえば、**2-of-3** マルチシグには3人の連署人がおり、そのうち任意の2人が署名してトランザクションを承認する必要があります。 + +```dot +digraph "M-of-N Multisignature" { + rankdir="BT"; + node [fontsize=12]; + "Multisig Account" [label="マルチシグアカウント\n2 of 3"]; + + "Cosignatory 1" [label="連署人1", penwidth=2]; + "Cosignatory 2" [label="連署人2", penwidth=2]; + "Cosignatory 3" [label="連署人3"]; + + "Cosignatory 1" -> "Multisig Account" [penwidth=2 minlen=2]; + "Cosignatory 2" -> "Multisig Account" [penwidth=2 minlen=2]; + "Cosignatory 3" -> "Multisig Account" [style=dashed minlen=2]; +} +``` + +上の図では連署人1と2が署名しており、最小値 `M=2` を満たすため、連署人3の署名がなくてもトランザクションは有効です。 + +### 使用例 {: #use-cases } + +* **資金または機能の共同管理** + + 設定された人数の連署人の承認なしには、アカウント上で操作を実行できません。 + + これにより、アカウントの1つが侵害されるリスクも軽減できます。 + +* **多要素承認** + + セキュリティ対策として、複数のデバイスからトランザクションを承認する必要があるマルチシグを作成できます。 + +* **アカウント所有権の移転** + + 秘密鍵を移転してアカウントの所有権を変更する方法は、受信者が送信者による鍵のコピーの削除を確認できないため、実用的ではありません。 + + この問題を解決するには、送信者が移転対象のアカウントを 1-of-1 マルチシグに設定し、受信者アカウントを唯一の連署人に設定します。 + + 必要に応じて、単一の連署人を何度でも変更することで、アカウントを再び移転できます。 + +### 制約 {: #constraints } + +マルチシグの仕組みを設計するときは、次の点に注意してください。 + +* **アカウントの連署人の最大数** + + マルチシグアカウントの連署人は最大 **32** 人です。 + +* **連署人の削除には特別なルールがあります** + + 連署人を削除するために、その連署人自身の署名は必要ありません。 + たとえば、**3-of-5** マルチシグでの削除には、残り4人の連署人から少なくとも3人の署名が必要ですが、**5-of-5** マルチシグでの削除には残り4人全員の署名が必要です。 + + 1つのトランザクションで削除できる連署人は **最大1人** です。 + 複数人を削除するには、別々のトランザクションが必要です。 + + 最後に残った連署人は自分自身を削除でき、その場合マルチシグは解消されます。 + +* **入れ子のマルチシグはありません** + + NEM では、マルチシグアカウントを別のマルチシグの連署人にすることはできず、連署人アカウントをマルチシグに変換することもできません。 + したがって、マルチシグの階層は **1層の深さ** だけです。 + +## インポータンス {: #importance } + +インポータンス +: [アカウント](default:アカウント) の [ベスティング](default:ベスティング) 済み残高と、他のアカウントへの送金に基づく、ネットワークへの貢献度の指標です。 + このスコアは、アカウントがブロックをハーベストする可能性を決定します。 + +インポータンスは、[PoW](default:PoW) システムのハッシュレートや [PoS](default:PoS) システムのステークと似た役割を果たします。 +値が高いほど、ブロックをハーベストして報酬を得る可能性が高くなります。 + +### ベスティング {: #vesting } + +ベスティング +: アカウントの [XEM](default:XEM) 残高が _未ベスティング_ から _ベスティング済み_ へ徐々に成熟するプロセスです。 + ベスティング済みの部分だけがアカウントのインポータンスに加算されるため、新たに資金を受け取ったアカウントはすぐにはハーベストを開始しません。 + +アカウントが初めて XEM を受け取った時点では、全額が未ベスティングです。 +60秒の目標時間では約1日にあたる1440ブロックごとに、未ベスティング残高の10%がベスティング済みになります。 +同じ処理が毎日繰り返され、残高のより多くがベスティング済みになります。 + +たとえば次のようになります。 + +* 1日後には、元の残高の10%がベスティング済みです。 +* 2日後には、19%がベスティング済みです。 +* 7日後には、半分を少し超える量がベスティング済みです。 +* 残高は漸近的に全額ベスティングへ近づきます。 + +保有量が多いほど、ベスティング済み XEM 10'000 のしきい値を早く超えます。 +たとえば XEM を 100'000 保有するアカウントは、最初のベスティングサイクル（約1日後）で 10'000 XEM をベスティングし、その時点でハーベスティング資格を得ます。 + +??? info "インポータンスの計算" + + ベスティング済み残高が XEM 10'000 以上あるすべてのアカウントは、ハーベストとインポータンス計算への参加資格を持ちます。 + + 資格を持つアカウントのインポータンススコアは、次の要素を組み合わせます。 + + * **ベスティング済み残高**。 + * 転送トランザクションのグラフから計算した **[PageRank](https://en.wikipedia.org/wiki/PageRank) に似たスコア**。 + + 次の両方を満たす送金だけが考慮されます。 + + * 過去43200ブロック（約30日）以内に発生した。 + * 受取人自身に参加資格がある（ベスティング済み XEM が10'000以上）。 + + 条件を満たす送金はそれぞれ金額を寄与しますが、古い送金ほど寄与は小さくなります（1日あたり10%減）。 + 2つのアカウントが互いに XEM を送った場合は差額だけがカウントされます。 + その差額が少なくとも 1'000 XEM でなければ、スコアには寄与しません。 + + 完全なアルゴリズムは、[NEM Technical Reference](../devbook/reference/whitepaper/index.md) の7章で説明される _Proof-of-Importance_（PoI）方式を参照してください。 + +!!! note + インポータンススコアは359ブロックごと（約6時間ごと）に再計算され、再計算値は次の再計算までのすべての後続ブロックに適用されます。 diff --git a/mkdocs/pages/ja/textbook/blocks.md b/mkdocs/pages/ja/textbook/blocks.md new file mode 100644 index 000000000..c4820d35b --- /dev/null +++ b/mkdocs/pages/ja/textbook/blocks.md @@ -0,0 +1,93 @@ +# ブロック + +ブロック +: 特定の時点で承認された [トランザクション](default:トランザクション) の集合を記録します。 + +ブロックにはトランザクションに加えて、タイムスタンプ、ブロック高、各ブロックを前のブロックにリンクする _前ブロックハッシュ_ などのメタデータが含まれます。 +このリンクがチェーンを _ブロックチェーン_ にします。どのブロックでも改ざんすると、それ以降のすべてのブロックが無効になります。 + +NEM ネットワークは平均して60秒ごとに新しいブロックを1つ生成します。 + +## ネメシスブロック {: #the-nemesis-block } + +ネメシスブロック +: NEM ブロックチェーンの最初のブロックです。 + ネットワークのコンセンサスによって作成される他のすべてのブロックと異なり、ネットワークの作成者が手動で生成します。 + +```dot +digraph Blockchain { + rankdir=LR; + node [shape=box fontsize=12]; + + Nemesis [label="ネメシス"]; + B2 [label="ブロック2"]; + B3 [label="ブロック3"]; + B4 [label="ブロック4"]; + B5 [label="..." shape=plaintext] + + Nemesis -> B2 -> B3 -> B4 -> B5; +} +``` + +ネメシスブロックはブロックチェーンの初期状態を定義します。 +これには、[XEM](default:XEM) などのモザイクの特定アカウントへの初期配布、ネームスペースの作成、ネットワークの基盤となるその他の構成パラメーターが含まれます。 + +チェーンの根本であるため、ネメシスブロックには前ブロックハッシュがありません。 +他のすべてのブロックは、直接または間接的にネメシスブロックへリンクします。 + +このブロックは、他のブロックチェーンプロトコルでは一般に _ジェネシスブロック_ と呼ばれます。 + +後続のすべてのブロックは、他のブロックチェーンにおけるマイニングに相当する NEM の [ハーベスティング](default:ハーベスティング) と呼ばれるプロセスで作成されます。 +ハーベスターはトランザクションを検証し、ブロックにまとめてチェーンに追加し、報酬としてトランザクション手数料を受け取ります。 + +## ネットワーク時刻 {: #network-time } + +ネットワーク時刻 +: NEM が最初のブロック（[ネメシスブロック](default:ネメシスブロック)）の作成から経過した秒数として定義する時刻です。 + + すべてのタイムスタンプはこの起点を基準に計算されます。 + +UTC タイムスタンプは、ネットワーク時刻をネメシスブロックの UNIX タイムスタンプに加えることで得られます。 +[メインネット](default:メインネット) では `1427587585`（`2015-03-29T00:06:25Z`）です。 +他のネットワークでは、ネットワークプロパティから取得できます。 + +## ブロック構造 {: #block-structure } + +NEM ブロックチェーンの各ブロックには、メタデータとトランザクションデータの組み合わせが含まれます。 + +| **フィールド** | **説明** | +|-------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **高さ** | [ネメシスブロック](default:ネメシスブロック) の `1` から始まる、チェーン内でのブロックの位置です。新しいブロックの高さは前のブロックより1つ大きくなります。 | +| **タイムスタンプ** | ネメシスブロックから経過した秒数です。各ブロックで厳密に増加します。ブロック間の平均時間は60秒に近く保たれます。 | +| **タイプ** | ネメシスブロックは `-1`、通常のブロックは `1` です。 | +| **バージョン** | ブロック形式のバージョンとネットワークをエンコードします（メインネットでは `1744830465`、テストネットでは `-1744830463`）。 | +| **前ブロックハッシュ** | 前のブロックの [ハッシュ](default:ハッシュ) です。内容が改ざんされるとこのハッシュが変わり、チェーンが破壊されて後続のすべてのブロックが無効になります。 | +| **署名** | ハーベスターがブロックの内容に対して生成する暗号学的署名です。すべてのノードがブロックの完全性を検証するために使用します。 | +| **署名者** | ブロックに署名するアカウントです。 _ハーベスター_ とも呼ばれます。トランザクション手数料はそのアカウントに入金されますが、リモートアカウントによる [リモートハーベスティング](default:リモートハーベスティング) または [委任ハーベスティング](default:委任ハーベスティング) で署名された場合はメインアカウントに入金されます。 | +| **トランザクション** | ブロックに含まれる有効なトランザクションの一覧です。各トランザクションはブロックに受け入れられる前に個別に検証されます。 | + +## 派生フィールド {: #derived-fields } + +上記のフィールドに加え、各ノードは各ブロックについて次の値を保持します。 +これらはブロックペイロードの一部ではなく、各ノードが以前のブロックから計算します。 + +| **フィールド** | **説明** | +|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **生成ハッシュ** | ブロックからブロックへ引き継がれるハッシュです。次のブロックをハーベストする資格を持つアカウントの判定に使用します。前のブロックの生成ハッシュとハーベスターの公開鍵から計算されます。 | +| **難易度** | 次のブロックをハーベストする難しさを表すネットワーク全体の指標です。平均ブロック時間を60秒に近づけるため、最近のブロック履歴から動的に調整されます。 | +| **レンタル元** | リモートアカウントによる [リモートハーベスティング](default:リモートハーベスティング) または [委任ハーベスティング](default:委任ハーベスティング) でブロックが署名された場合、インポータンスの裏付けとなり報酬を受け取るメインアカウントです。チェーンの前の部分に記録されたリモートアカウントの委任状態から解決されます。 | + +## ブロックスコア {: #block-score } + +コンセンサスプロセスを支援するため、各ブロックについて次の量が計算されます。 + +ブロックスコア +: [ハーベスティング](default:ハーベスティング) の難しさを反映する、各ブロックに割り当てられた数値です。 + +$$ +\textit{block score} = difficulty − \textit{time elapsed since last block} +$$ + +チェーンスコア +: チェーン内のすべての [ブロックスコア](default:ブロックスコア) の合計です。競合する [フォーク](default:フォーク) の選択に使用します。 + スコアの高いチェーンが勝ちます。 diff --git a/mkdocs/pages/ja/textbook/cats.md b/mkdocs/pages/ja/textbook/cats.md new file mode 100644 index 000000000..d2afc0a19 --- /dev/null +++ b/mkdocs/pages/ja/textbook/cats.md @@ -0,0 +1,410 @@ +# CATS DSL + +CATS +: **CATS DSL**（**CATS** は **Compact Affinitized Transfer Schema** というユーモラスな逆頭字語で、**DSL** は **Domain-Specific Language** の略です）は、構造化データのバイナリレイアウトを定義するためのコンパクトで記述的な言語です。 + +もともと Symbol と NEM のために開発され、両プロトコルのすべてのブロックとトランザクションの仕様に使われていますが、設計は十分に汎用的で、任意のバイナリ形式を記述できます。 + +CATS はサイズ効率、性能、厳密な型付けを優先し、可能な場合はゼロコピーのデシリアライズを目指します。 +固定サイズバッファー、厳密な型エイリアス、インライン構造、条件付きフィールドなどの機能があります。 + +CATS 定義は _ジェネレーター_ で処理されます。ジェネレーターは、CATS で定義したバイナリ構造をネイティブ言語の構造へシリアライズ（書き込み）またはデシリアライズ（読み取り）できるように、特定のプログラミング言語のコードを生成するツールです。 + +現在は Python と JavaScript/TypeScript 用のジェネレーターがあり、Java 用は開発中です（2025年6月時点）。 +これらは NEM SDK で使われ、プラットフォーム間で一貫した効率的なバイナリエンコードを保証します。 + +このページでは CATS DSL の構文と機能を説明します。 +完全な精度が必要な場合は、Symbol のソースリポジトリに [Lark 構文解析言語](https://lark-parser.readthedocs.io) で記述された [正確な文法](https://github.com/symbol/symbol/blob/dev/catbuffer/parser/catparser/grammar/catbuffer.lark) があります。 + +!!! note "空白" + + すべての CATS 文は改行で終わります（セミコロンは使いません）が、それ以外では空白は意味を持ちません。 + + 構文解析器にインデントは必要ありませんが、通常は明確さを加えるために使用します。 + +CATS ファイルは、トップレベルの4つのキーワード `#!cats import`、`#!cats using`、`#!cats enum`、`#!cats struct` で構成されます。 +それぞれについて、以下のセクションで説明します。 + +## `#!cats import` {: #cats-import } + +`#!cats import` 文を使うと、CATS ファイルに他の CATS ファイルを含められます。 +これにより、スキーマ定義をモジュール化して再利用できます。 + +別の CATS ファイルをインポートするには、ファイル名を引用符で指定します。 + +```cats +import "other.cats" +``` + +インポートしたファイル名は、構文解析器に渡されたインクルードパスを基準に解決されます。 + +## `#!cats using` {: #cats-using } + +`using` 文は、組み込みプリミティブ型の **型エイリアス** を定義します。 +これらのエイリアスは構文解析器とジェネレーターでは別の型として扱われるため、2つの型が同じ基礎表現を共有していても厳密な型付けが可能です。 + +```cats +using = +``` + +CATS は組み込み型を次の2カテゴリでエイリアス化できます。 + +* **整数型**： + * 符号なし：`#!cats uint8`、`#!cats uint16`、`#!cats uint32`、`#!cats uint64` + * 符号付き：`#!cats int8`、`#!cats int16`、`#!cats int32`、`#!cats int64` +* **固定サイズバイナリバッファー**：`#!cats binary_fixed(N)` は N バイト長のバッファーを定義します。 + +たとえば、8バイトの符号なし整数として `#!cats Height` 型を定義します。 + +```cats +using Height = uint64 +``` + +32バイトのバイナリバッファーとして `#!cats PublicKey` 型を定義します。 + +```cats +using PublicKey = binary_fixed(32) +``` + +次の例では `#!cats Height` と `#!cats Weight` はどちらも `#!cats uint64` に基づきますが、**別の型** として扱われ、相互に入れ替えて使用できません。 + +```cats +using Height = uint64 +using Weight = uint64 +``` + +## `#!cats enum` {: #cats-enum } + +`#!cats enum` 文は、整数型を基礎とする名前付き定数で構成される型、つまり **列挙型** を定義します。 + +各列挙型では基礎型を明示する必要があり、組み込み整数型のいずれかを使用できます。 + +```cats +enum : + = + ... +``` + +列挙型のメンバーは `#!cats enum` 宣言の下の行に定義します。 +各メンバーには定数の整数値を割り当てる必要があります。 + +たとえば、32ビット符号なし整数を基礎型とする `#!cats TransportMode` 列挙型を定義します。 + +```cats +enum TransportMode : uint32 + ROAD = 0x0001 + SEA = 0x0002 + SKY = 0x0004 +``` + +### 列挙型属性 {: #enum-attributes } + +列挙型は動作を変更する属性をサポートします。 +各属性は `@` で始まり、列挙型宣言の上の行に記述する必要があります。 +現在サポートされている属性は次の1つだけです。 + +* `#!cats @is_bitwise`：列挙型がビットフィールド（フラグの集合）を表し、生成コードでビット演算をサポートすることを示します。 + + 例： + + ```cats + @is_bitwise + enum TransportMode : uint32 + ROAD = 0x0001 + SEA = 0x0002 + SKY = 0x0004 + ``` + + これは、ジェネレーターに列挙値をビット単位の OR で結合でき、個々のフラグをビット単位の AND で確認できることを伝えます。 + +## `#!cats struct` {: #cats-struct } + +`#!cats struct` 文は、名前付きフィールドで構成される **構造化バイナリレイアウト** を定義します。 + +構造体は CATS の最も重要な構成要素です。トランザクション、ブロック、その他すべての複合オブジェクトを記述するために使われます。 + +各構造体宣言は、任意で _修飾子_ が前に付く `#!cats struct` キーワードで始まります。 +宣言の後の行で、フィールド名と型を指定してフィールドを定義します。 + +```cats +[Optional modifier] struct + = + ... +``` + +例： + +```cats +struct Vehicle + weight = uint32 + wheel_count = uint8 +``` + +### 修飾子 {: #modifiers } + +CATS は次の修飾子をサポートします。 + +* `#!cats abstract`：継承用の基底構造体を定義します。 + ジェネレーターは、適切な派生型をインスタンス化するファクトリーを生成します。 + +* `#!cats inline`：構造体が合成にだけ使われ、独立した型として出力されないことを示します。 + +修飾子を指定しなければ、構造体はそのまま生成出力に含まれます。 + +### 特別なフィールドコンストラクター {: #special-field-constructors } + +型の代わりに、特別なコンストラクターを使ってフィールドを宣言することもできます。 + +* `#!cats make_const(type, value)`：定数を定義します。 + このフィールドはレイアウトに現れません。代わりに、生成コードで `#!cats .` としてアクセスできる定数になります。 + + 次の例では `#!cats TRANSPORT_MODE` はシリアライズされませんが、`#!cats ROAD` 値を持つ `#!cats TransportMode` 型の `#!cats Car.TRANSPORT_MODE` 定数になります。 + + ```cats + struct Car + TRANSPORT_MODE = make_const(TransportMode, ROAD) + ``` + +* `#!cats make_reserved(type, value)`：固定値を持つ予約フィールドを定義します。 + このフィールドはレイアウトに保存され、常に指定された値になります。 + + 次の例では、フィールド `#!cats wheel_count` が固定値 `#!cats 4` の `#!cats uint8` として保存されます。 + + ```cats + struct Car + wheel_count = make_reserved(uint8, 4) + ``` + +* `#!cats sizeof(type, reference)`：別のフィールドのサイズ（バイト）で自動的に埋められるフィールドを定義します。 + 参照する型を変更してもサイズフィールドを手動で更新する必要がないため、構造体の保守が簡単になります。 + + ここで `#!cats car_size` は、`#!cats Car` 型のフィールド `#!cats car` のサイズ（バイト）を常に保持する `#!cats uint16` です。 + + ```cats + struct SingleCarGarage + car_size = sizeof(uint16, car) + car = Car + ``` + +### 条件付きフィールド {: #conditional-fields } + +別のフィールドの値に基づいて、条件付きで存在するフィールドを作成できます。 +他の言語の共用体に似た、相互排他的なレイアウトを表せます。 + +条件付きフィールドの構文は次のとおりです。 + +```cats + = if +``` + +CATS は次の条件演算子をサポートします。 + +* `#!cats equals`：セレクターフィールドが定数値と完全に一致する場合にフィールドを含めます。 +* `#!cats not equals`：セレクターフィールドが定数値と一致しない場合にフィールドを含めます。 +* `#!cats in`：セレクターフィールドに定数が含まれる場合にフィールドを含めます（ビットフラグ用）。 +* `#!cats not in`：セレクターフィールドに定数が含まれない場合にフィールドを含めます。 + +たとえば、`#!cats transport_mode` が `#!cats SEA` と等しい場合だけ `#!cats buoyancy` フィールドが含まれます。 + +```cats +struct Vehicle + transport_mode = TransportMode + + buoyancy = uint32 if SEA equals transport_mode +``` + +### 配列フィールド {: #array-fields } + +CATS は、すべての要素が同じ型を持つ、静的サイズと動的サイズの両方の配列をサポートします。 + +構文は次のとおりです。 + +```cats + = array(, ) +``` + +`#!cats ` には次を指定できます。 + +* 要素数を固定する定数。 + + ```cats + struct SmallGarage + vehicles = array(Vehicle, 4) + ``` + +* 別のフィールドへの参照。動的サイズの配列になります。 + + たとえば次の構造体は、`#!cats vehicles_count` 個の `#!cats Vehicle` 型要素を含む `#!cats vehicles` フィールドを定義します。 + + ```cats + struct Garage + vehicles_count = uint32 + vehicles = array(Vehicle, vehicles_count) + ``` + +* 特別なキーワード `#!cats __FILL__`。構造体の末尾まで配列を拡張することを示します。 + + この場合、構造体に [下記](#struct-attributes) の `#!cats @size` 属性を付け、合計サイズ（バイト）を保持するフィールドを参照する必要があります。 + + ```cats + @size(garage_byte_size) + struct Garage + garage_byte_size = uint32 + vehicles = array(Vehicle, __FILL__) + ``` + +!!! note + + `#!cats ` には次のいずれかを指定する必要があります。 + + * 固定サイズ構造体。 + * 独自の `#!cats @size` 属性が付いた可変サイズ構造体。 + + それ以外の場合、構文解析器はバイトストリームから読み取る要素数を判断できません。 + +#### 配列フィールド属性 {: #array-field-attributes } + +配列フィールドには、サイズ、アラインメント、ソート方法を制御する属性を付けられます。 + +サポートされる属性には次があります。 + +* `#!cats @is_byte_constrained`：配列サイズを要素数ではなくバイト数として解釈します。 +* `#!cats @alignment(x [, [not] pad_last])`：要素を x バイト境界に揃え、任意で最後の要素にパディングを付けます。 + + デフォルトでは、アラインメントを使うと最後の要素にパディングが付きます。 + `#!cats not pad_last` 修飾子で無効にできます。 + +* `#!cats @sort_key(x)`：指定したプロパティで配列がソートされるようにします。 + + たとえば、次の `#!cats Vehicle` 構造体の配列は weight でソートされます。 + + ```cats + struct Garage + @sort_key(weight) + @alignment(8, not pad_last) + vehicles = array(Vehicle, __FILL__) + ``` + +### インライン {: #inlines } + +`#!cats inline` 修飾子を使うと、ある構造体を別の構造体の中に **インライン化** できます。 +これにより、入れ子にせずに1つの構造体のフィールドを別の構造体へ直接挿入できます。 + +たとえば、次の定義は `#!cats Vehicle` の内容を `#!cats Car` にインライン化します。 + +```cats +struct Vehicle + weight = uint32 + +struct Car + inline Vehicle + max_clearance = Height + has_left_steering_wheel = uint8 +``` + +インライン化されたフィールドはその場所で展開されるため、`#!cats Car` の最終レイアウトは次と同じです。 + +```cats +struct Car + weight = uint32 + max_clearance = Height + has_left_steering_wheel = uint8 +``` + +!!! note "名前付きインライン" + + 構造体は **名前** を付けてインライン化することもでき、その接頭辞でフィールド名が変更されます。 + + ```cats + = inline + ``` + + 次の例では `#!cats SizePrefixedString` を `#!cats friendly_name` として `#!cats Vehicle` にインライン化します。 + + ```cats + struct SizePrefixedString + size = uint32 + __value__ = array(int8, size) + + struct Vehicle + weight = uint32 + friendly_name = inline SizePrefixedString + year = uint16 + ``` + + 次のように展開されます。 + + ```cats + struct Vehicle + weight = uint32 + friendly_name_size = uint32 + friendly_name = array(int8, friendly_name_size) + year = uint16 + ``` + + 特別なフィールド `#!cats __value__` は、インラインに指定された名前（`#!cats friendly_name`）に変更されます。 + それ以外のフィールドは接頭辞とアンダースコアで変更されます。たとえば `#!cats size` は `#!cats friendly_name_size` になります。 + +### 構造体属性 {: #struct-attributes } + +構造体には、コードジェネレーターへのヒントやレイアウト動作への影響を与える属性を含められます。 +属性は `@` で始まり、`#!cats struct` 宣言の上に記述します。 + +CATS は次の構造体レベル属性をサポートします。 + +* `#!cats @is_aligned`：すべてのフィールドを自然な境界に揃えます。 +* `#!cats @is_size_implicit`：構造体を `#!cats sizeof(type, field)` 式で参照できるようにします。 +* `#!cats @size(x)`：フィールド `x` が構造体全体のサイズ（バイト）を保持することを宣言します。 +* `#!cats @initializes(x, Y)`：別の場所で定義された定数 `Y` でフィールド `x` を初期化します。 +* `#!cats @discriminator(x [, y...])`：`#!cats abstract` 構造体で使い、指定したプロパティに基づいてデコード時に適切な派生型を選択します。 +* `#!cats @comparer(x [!transform] [, y...])`：インスタンスのソートまたは比較に使うプロパティを定義します。 + 任意の変換はプロパティ比較の前に適用されます。 + 現在サポートされている変換は、NEM との後方互換性のための `#!cats ripemd_keccak_256` だけです。 + +たとえば、次は `#!cats Vehicle` のフィールド `#!cats transport_mode` を派生構造体に定義された定数へリンクします。 + +```cats +@initializes(transport_mode, TRANSPORT_MODE) +abstract struct Vehicle + transport_mode = TransportMode + +struct Car + TRANSPORT_MODE = make_const(TransportMode, ROAD) + inline Vehicle +``` + +定数 `#!cats TRANSPORT_MODE` は `#!cats Vehicle` を拡張する任意の構造体で定義できます。 + +### 整数フィールド属性 {: #integer-field-attributes } + +整数フィールドは1つの属性をサポートします。 + +* `#!cats @sizeref(x [, y])`：フィールドの値を `x` のサイズに設定し、任意でオフセット `y` を加えます。 + + たとえば、`#!cats vehicle_size` と `#!cats vehicle` の合計サイズを保存します。 + + ```cats + struct Garage + @sizeref(vehicle, 2) + vehicle_size = uint16 + vehicle = Vehicle + ``` + +## コメント {: #comments } + +`#` で始まる行はコメントとして扱われます。 + +宣言の直上にないコメントは構文解析器に無視されます。 +ただし、宣言またはフィールドの直前にコメントを置くと **ドキュメント** として扱われ、生成出力に保持されることがあります。 + +例： + +```cats +# This comment is ignored + +# This comment is included as documentation +# and will be associated with the `#!cats Height` alias. +using Height = uint64 +``` + +この規約により、バイナリレイアウトに影響を与えずにスキーマへインラインドキュメントを追加できます。 diff --git a/mkdocs/pages/ja/textbook/consensus.md b/mkdocs/pages/ja/textbook/consensus.md new file mode 100644 index 000000000..ca5bc4994 --- /dev/null +++ b/mkdocs/pages/ja/textbook/consensus.md @@ -0,0 +1,58 @@ +# コンセンサス + +コンセンサス +: ネットワーク内のすべての [ノード](default:ノード) が、ブロックチェーンの現在の状態について合意するプロセスです。 + +コンセンサスにより、ネットワークは [ブロック](default:ブロック) とその [トランザクション](default:トランザクション) の一貫した単一の時系列を維持し、すべての [アカウント](default:アカウント) に関連する残高とデータを維持します。 + +コンセンサスは、次の2種類の合意を提供します。 + +* **連結の合意**：各ブロックが前のブロックに正しくリンクし、チェーンの履歴の不変性を保証します。 +* **内容の合意**：ブロック内のすべてのトランザクションがネットワークのルールに従います。たとえば、アカウントからトークンを送るには、その [秘密鍵](default:秘密鍵) による有効な署名と十分な残高が必要です。 + +どちらかの合意に違反するブロックは **無効** とされ、正常に動作するノードから無視されます。 +そのようなブロックはネットワークに伝播されません。 + +## 競合 {: #conflicts } + +NEM のような分散型ネットワークでは、[ノード](default:ノード) が一時的に切断されることがあります。 +遅延、接続の問題、ネットワーク構成の変化などが原因です。 + +_ネットワーク分断_ の間、切断されたノードのグループは、すべて有効であっても、最新のブロックについて一時的に意見が分かれることがあります。 + +その結果、一時的に複数のブロックチェーンが存在することがあります。これを _フォーク_ と呼びます。 + +フォーク +: 2つ以上の競合するチェーンが共通の履歴を持ちながら、最新のブロックが異なる状態です。 + +フォーク中は、照会したノードがそのアカウントに影響するすべてのトランザクションを認識しているかどうかにより、異なるノードへの照会が同じアカウントに対して異なる残高を返すことがあります。 + +接続が復旧すると、ノードは同じ高さにある競合するブロックに遭遇し、競合が発生することがあります。 + +2つのノードが同時に新しいブロックを生成した場合にも、フォークが自然に発生することがあります。 + +## 競合の解決 {: #conflict-resolution } + +ノードがフォークを認識すると、NEM は決定論的なルールで解決します。[チェーンスコア](default:チェーンスコア) が最も高いチェーンを正しいものとみなします。 + +スコアの低いフォーク上のノードは、メインチェーンの一部ではなくなったブロックを _ロールバック_ し、より良いチェーンに切り替える必要があります。 + +ロールバック +: ノードがより良いチェーンに切り替える際、通常はフォークの解決後に、最近追加された1つ以上のブロックを破棄するプロセスです。 + +破棄されたブロック内にあり、メインチェーンにまだ存在しないトランザクションは [未承認トランザクションプール](default:未承認トランザクションプール) に戻され、再びブロックに含める前に再検証する必要があります。 + +NEM のロールバックは通常、最新の数ブロックだけに影響する浅くまれなものです。 + +非常に深いチェーン再編成を防ぐため、NEM は _書き換え制限_ を設けています。 + +書き換え制限 +: NEM でロールバックが到達できる最大深度です。**360ブロック**（約6時間）に設定されています。 + +書き換え制限より深いブロックは、代替チェーンに置き換えられません。 +その結果、新しいブロックが上に追加されるにつれて、トランザクションは徐々に実質的な不可逆状態になります。 + +書き換え制限には別の影響もあります。 +切断中のノードが自分のブロックを追加し続けると、別のチェーンが構築されます。 +そのチェーンが書き換え制限を超えて成長すると、戻るには深すぎるロールバックが必要になるため、ノードは自力で再参加できません。 +2つのチェーンは **解決不能なフォーク** となり、オペレーターはノードをメインチェーンに復元して解消する必要があります。 diff --git a/mkdocs/pages/ja/textbook/cryptography.md b/mkdocs/pages/ja/textbook/cryptography.md new file mode 100644 index 000000000..fcc0b7030 --- /dev/null +++ b/mkdocs/pages/ja/textbook/cryptography.md @@ -0,0 +1,137 @@ +# 暗号の基本 + +ここでは、NEMの技術を支える基本的な暗号技術の概念を解説します。 + +## ハッシュ {: #hashes } + +ハッシュ +: 暗号学的ハッシュは、任意のサイズの入力データを固定長の文字列に変換する数学関数 _（ハッシュ関数）_によって生成される文字列のことです。 + +[Keccak](https://keccak.team/keccak.html) や [RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) など、複数の関数が存在しますが、いずれも次の共通する特性を持っています。 + +* **決定性**：同じ入力からは常に同じハッシュを生成します。 +* **衝突耐性**：異なる入力から同じハッシュを作ることは極めて困難です。 +* **不可逆性**：ハッシュから元の入力データを復元することはできません。 + +これらの特性により、データの完全性や、真正性の検証、そしてブロックチェーンにおける [ブロック](default:ブロック) の連結が保証されます。 + +NEM は、鍵導出、アドレス生成、署名、ブロックハッシュに **Keccak-256**、**Keccak-512**、**RIPEMD-160** を使用します。 + +!!! warning "NEM は SHA-3 ではなく Keccak を使用します" + + NEM は SHA-3 として最終決定される前の Keccak を採用しました。 + 2つのアルゴリズムは異なるパディングを使用するため、同じ入力に対して異なる出力を生成します。 + そのため、標準の SHA-3 ライブラリでは NEM の署名を検証したり、NEM のアドレスを再生成することができません。 + 代わりに、[Bouncy Castle](https://www.bouncycastle.org/) などの Keccak 実装が必要です。 + + NEM の Java ソースコードではヘルパーメソッド名に `sha3_256` と `sha3_512` を使用していますが、内部ではどちらも `Keccak-*` を呼び出します。 + `sha3_` 接頭辞は歴史的なものであり、最終版の SHA-3 仕様を指すものではありません。 + +## キー {: #keys } + +秘密鍵 +: 非常に長い数値であり、厳重に秘匿すべき情報です。値そのものに意味はなく、第三者に推測されることは想定されていません。 + 通常はランダムに生成され、同じキーが偶然に生成されることはほぼありません。 + + +NEM の秘密鍵は 32 バイト長で、通常は64文字の16進文字列で表されます。 + +公開鍵 +: [秘密鍵](default:秘密鍵) に対応する公開識別子として機能する長い数値です。広く共有できますが、秘密鍵を明かすことなく + その保有を証明するために利用されます。 + + 秘密鍵から数学的に導出されますが、現在の技術では逆算して秘密鍵を求めることは実質的に不可能です。 + +NEM の公開鍵は 32 バイト長で、通常は64文字の16進文字列で表されます。 + +キーペア +: 1組の[秘密鍵](default:秘密鍵) と対応する [公開鍵](default:公開鍵) のセットです。 + 秘密鍵は所有者のみが保持し、公開鍵は誰でも閲覧できます。 + これにより、デジタル署名や暗号化などの安全な処理が可能になります。 + +NEM は次の2箇所でキーペアを使用します。 + +メインキー +: すべての [アカウント](default:アカウント) に紐付く [キーペア](default:キーペア) です。 + 秘密鍵はアカウントの所有者を識別し、資金の送金やトランザクションのアナウンスを含む、アカウントの完全な制御権を付与します。 + +リモートキー +: すべての [リモートハーベスティング](default:リモートハーベスティング) アカウントに関連付けられた [キーペア](default:キーペア) です。 + アカウントの [メインキー](default:メインキー) を公開せずに、ノードがメインキーに紐付くアカウントに代わってハーベストできるようにします。 + +??? warning "キーの安全性" + + いずれのキーペアでも **秘密鍵** は常に秘密に保つ必要があります。 + + ただし、秘密鍵が漏えいした場合の深刻度は、その鍵の用途によって異なります。 + + | キーの種類 | 重大度 | 影響 | + | --- | --- | --- | + | **メインキー** | 🔴 高 | アカウント内の資産が流出する可能性があります。 | + | **リモートキー** | 🟠 中 | 委任元アカウントの資金には影響しません。攻撃者が多数のリモートキーを集めると、相当なハーベスティング能力を得て、ブロックチェーンに追加されるブロックに影響を与える可能性があります。別のリモートアカウントをリンクすれば簡単に取り消せます。 | + +NEM では、秘密鍵と公開鍵の両方が256ビット（32バイト）の整数です。 +公開鍵は [楕円曲線暗号](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) により、 +[Ed25519](https://ed25519.cr.yp.to) を使用して取得されます。Ed25519 は +[ツイステッド・エドワーズ曲線](https://en.wikipedia.org/wiki/Twisted_Edwards_curve) 上で定義されています。 + +## 署名 {: #signatures } + +署名 +: ある [アカウント](default:アカウント) によって文書が承認されたことを証明するデジタル付加情報です。 + +署名はアカウントの [秘密鍵](default:秘密鍵) を使って文書を処理することで生成されます。 +そのため、対応する公開鍵を使えば誰でも署名が文書と一致することを検証できますが、同一の署名を作成できるのは秘密鍵の所有者だけです。 + +NEM のすべてのトランザクションには署名が付与されますが、必要な署名はトランザクションの種類と参加者によって異なります。 +たとえば、単一所有者のアカウントから別のアカウントへ資産を送る場合、送信元アカウントの秘密鍵の署名だけが必要です。 + +一方、[マルチシグアカウント](default:マルチシグアカウント) から資産を送る場合は、マルチシグのしきい値を満たすだけの連署人の承認が必要です。 +したがって、有効とみなされる前に複数の署名を集める必要があります。 + +NEM の署名は512ビット（64バイト）長で、[Ed25519](https://ed25519.cr.yp.to) アルゴリズムを使用します。 +SHA-512 に依存する標準の Ed25519 とは異なり、NEM は **Keccak-512** ハッシュ関数を使用します（[NEM は SHA-3 ではなく Keccak を使用します](#hashes) を参照）。 + +## アドレス {: #addresses } + +アドレス +: [公開鍵](default:公開鍵) を便利に短くした形式です。英字と数字だけを使うため、共有しやすくなっています。 + 通常は [アカウント](default:アカウント) と同義語として使われます。 + +公開鍵と秘密鍵はいずれも印刷や共有が難しいバイナリデータですが、アドレスは英数字のみで構成されます。 + +さらに、NEM の鍵には 32 バイトのバイナリデータ、つまり64文字の16進文字が必要です。 +一方、アドレスは40文字だけで済み、長さと実用性のバランスを保っています。 + +NEM では、公開鍵から次の手順でアドレスを取得します。 + +1. 公開鍵に [Keccak-256](https://keccak.team/keccak.html) を適用し、32バイトのハッシュを生成します。 +2. その結果に [RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) を適用し、20バイトのハッシュを生成します。 +3. 次を連結して25バイトの **生アドレス** を生成します。 + + * 1バイトのネットワークバージョン： [メインネット](default:メインネット)（`N`）は `0x68`、[テストネット](default:テストネット)（`T`）は `0x98`、[mijinネット](default:mijinnet)（`M`）は `0x60` です。 + * 手順2で得た20バイトの RIPEMD-160 ハッシュ。 + * 入力ミスを検出する4バイトのチェックサム。直前の21バイト（ネットワークバージョン + RIPEMD-160 ハッシュ）に Keccak-256 を適用した結果の先頭4バイトです。 + +4. 生アドレスを [Base32エンコード](https://en.wikipedia.org/wiki/Base32) して40文字の **エンコード済みアドレス** を生成します。 + + 大文字と数字だけを使用するため、エンコード済みアドレスが最も一般的な共有方法です。 + + 例：`NBHK6WHL5TGBMCLVW4RSFMRO4ZYXCJFRAVO2B4FU` + +5. 読みやすくするため、任意で6文字ごとにハイフンを追加し、46文字の **見やすいアドレス** にできます。 + + 例：`NBHK6W-HL5TGB-MCLVW4-RSFMRO-4ZYXCJ-FRAVO2-B4FU` + +!!! note "アドレスは使用されて初めて追跡されます" + + NEM がアドレスとそれに対応する公開鍵を追跡し始めるのは、それらがトランザクションに初めて登場した時点です。 + +## バニティアドレス {: #vanity-addresses } + +通常、キー及びそれに対応する [アドレス](default:アドレス) はランダムに生成されますが、特定のパターンやプレフィックスを含む **バニティアドレス** を作ることもできます。 + +これは、条件を満たすアドレスが生成されるまで [キーペア](default:キーペア) を繰り返し生成する手法です。 +求める文字列が複雑になるほど、より多くの時間と計算が必要となります。 + +バニティアドレスはブランド名や個人の識別などに便利ですが、セキュリティ上の利点はありません。 diff --git a/mkdocs/pages/ja/textbook/glossary.md b/mkdocs/pages/ja/textbook/glossary.md index b3b305165..22f43b1d0 100644 --- a/mkdocs/pages/ja/textbook/glossary.md +++ b/mkdocs/pages/ja/textbook/glossary.md @@ -1,228 +1,234 @@ # 用語集 AMA -: Ask Me Anything（何でも質問会）。オープンな質疑応答セッション。 +: Ask Me Anything（何でも聞いてください）。公開質疑応答セッションです。 AML -: （Anti Money Laundering）マネーロンダリング防止。 +: Anti Money Laundering（マネーロンダリング防止）。 APAC -: （Asia and Pacific region）アジア太平洋地域。 +: Asia and Pacific region（アジア太平洋地域）。 APR -: （Annual Percentage Rate）年利。 +: Annual Percentage Rate（年利）。 アービトラージ -: （Arbitrage）ある市場で資産を購入し、別の市場で販売して、価格差から利益を得る取引手法。 +: ある市場で資産を購入し、別の市場で販売して市場間の価格差から利益を得ることです。 バックランニング -: （Backrunning）すでに未処理の `transactionB` が存在する状態で、やや低い手数料（またはガス）で `transactionA` を送信し、 - 同一ブロック内で `transactionB` の*直後*に`transactionA`がマイニングされるように狙う行為。 +: すでに保留中の `transactionB` より少し低いガス（または手数料）で `transactionA` をブロードキャストし、同じブロック内で `transactionB` の *直後* に `transactionA` がマイニングされるようにすることです。 BLS -: [Boneh–Lynn–Shacham](https://en.wikipedia.org/wiki/BLS_digital_signature) 署名方式。 - 署名者の真正性を検証できる暗号署名スキーム。 +: [Boneh–Lynn–Shacham](https://en.wikipedia.org/wiki/BLS_digital_signature) 署名は、署名者が本物であることを利用者が検証できる暗号署名方式です。 BTC -: ビットコイン。 +: Bitcoin（ビットコイン）。 CBDC -: （Central Bank Digital Currency）中央銀行デジタル通貨。 +: Central Bank Digital Currency（中央銀行デジタル通貨）。 CEX -: （Centralized Exchange）中央集権型取引所。分散型取引所（）の対義語。 +: Centralized Exchange（中央集権型取引所）。分散型取引所（[DEX](default:DEX)）の対義語です。 CLI -: （Command-Line Interface）コマンドラインインターフェイス。 - 端末コンソール上でキーボードのみを使って操作するプログラム。 - Symbol にはブロックチェーンと対話する CLI ツールがある。 +: Command-Line Interface（コマンドラインインターフェース）。端末コンソール上でキーボードだけを使って操作するプログラムです。 CMC -: Coin Market Cap。暗号資産に関する情報を提供するウェブサイト。 +: Coin Market Cap。暗号資産に関する情報を提供するウェブページです。 CSD -: （Central Securities Deposit）証券集中保管機関。 +: Central Securities Deposit（証券集中保管）。 DAO -: （Decentralized Autonomous Organization）自律分散型組織。 - ガバナンスが完全にブロックチェーン上で行われる組織。 +: Decentralized Autonomous Organization（分散型自律組織）。ガバナンスが完全にブロックチェーン上で行われる組織です。 Dapp -: （Decentralized Application）分散型アプリケーション。 - 単一のコンピュータではなくブロックチェーン上で動作するアプリケーション。 - 広義には、ブロックチェーンを利用するあらゆるアプリケーションも指す。 +: Decentralized Application（分散型アプリケーション）。単一のコンピューターではなくブロックチェーン上で動作するアプリケーションです。 + この用語はやや広く使われるため、より一般的にはブロックチェーンを利用するあらゆるアプリケーションも意味します。 DDH -: （Decisional Diffie-Hellman）判定型 [Diffie–Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) 仮定。 +: Decisional [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)。 DD -: （Due Diligence）デューデリジェンス。 +: Due Diligence（デューデリジェンス）。 DeFi -: （Decentralized Finance）分散型金融。従来型金融（）の対義語。 +: Decentralized Finance（分散型金融）。Traditional Finance（[TradFi](default:TradFi)）の対義語です。 DEX -: （Decentralized Exchange）分散型取引所。中央集権型取引所（）の対義語。 +: Decentralized Exchange（分散型取引所）。従来の Centralized Exchange（[CEX](default:CEX)）の対義語です。 DoS -: （Denial of Service）サービス拒否攻撃。 - 単一の送信元がサーバーやネットワークに大量のリクエストを送りつけ、 - リソースを使い果たさせて正規の通信を妨害する攻撃。 +: Denial of Service（サービス拒否）。 + 単一の送信元が過剰なリクエストでサーバーまたはネットワークを氾濫させ、リソースを使い果たして正当なトラフィックに応答できなくする攻撃です。 - 最も一般的な変種は DDoS（分散型サービス拒否攻撃）で、 - 多数の送信元（しばしば乗っ取られた端末）を利用して実行される。 + 最も一般的な亜種は DDoS（Distributed Denial of Service）攻撃です。複数の送信元が関与し、多くの場合は所有者の知らないうちに侵害されたデバイスを使います。 DTC -: （Direct To Consumer）消費者直販。マスマーケット向け販売。 +: Direct To Consumer（消費者直販）、つまりマスマーケットです。 E2E -: （End-To-End）エンドツーエンド。 +: End-To-End（エンドツーエンド）。 EMEA -: （Europe, Middle-East and Africa）欧州・中東・アフリカ地域。 +: Europe, Middle-East and Africa（ヨーロッパ、中東、アフリカ）。 ERC : Ethereum Request for Comment。 - EVM 上のトークン標準（例：ERC-20、ERC-721、ERC-1155）を指すのに一般的に用いられる。 + EVM のトークン標準（ERC-20、ERC-721、ERC-1155 など）を指すためによく使われます。 ETH -: イーサリアム。 +: Ethereum（イーサリアム）。 EVM : Ethereum Virtual Machine（イーサリアム仮想マシン）。 FFT -: [高速フーリエ変換（Fast Fourier Transform）](https://en.wikipedia.org/wiki/Fast_Fourier_transform)。 +: [Fast Fourier Transform](https://en.wikipedia.org/wiki/Fast_Fourier_transform)（高速フーリエ変換）。 フロントランニング -: （Frontrunning）すでに未処理の `transactionB` が存在する状態で、やや高い手数料（またはガス）で `transactionA` を送信し、 - 同一ブロック内で `transactionB` の*直前*にマイニングされるように狙う行為。 - 市場ではこの方法で利益を得るケースがある。 +: すでに保留中の `transactionB` より少し高いガス（または手数料）で `transactionA` をブロードキャストし、同じブロック内で `transactionB` の *直前* に `transactionA` がマイニングされるようにすることです。 + これは、フロントランニングで利益を得られる [DeFi](default:DeFi) 市場で重要です。 ハードウェアウォレット -: （Hardware wallet）[秘密鍵](default:秘密鍵) を安全に保管し、署名を生成するための専用デバイス。 - 鍵は暗号化されたメモリに保存され、デバイス外に出ることはないため、 - ハードウェアウォレットは最も安全なアクセス手段のひとつとされる。 - 通常は署名機能のみを持ち、[ウォレット](default:ウォレット) アプリケーションと組み合わせて - [トランザクション](default:トランザクション) を作成・送信する。 +: [秘密鍵](default:秘密鍵) を保管し、それで署名を生成するデバイスです。 + 鍵は暗号化メモリに保存されてデバイス外に出ないため、ハードウェアウォレットはアカウントへアクセスする最も安全な方法の1つとみなされます。 + 通常は署名機能だけを提供するため、トランザクションを作成してアナウンスするソフトウェア [ウォレット](default:ウォレット) またはアプリケーションと組み合わせる必要があります。 HTLC -: （Hashed Time-Lock Contract）ハッシュタイムロックコントラクト。 +: Hashed Time-Lock Contract（ハッシュタイムロックコントラクト）。 ICO -: （Initial Coin Offering）イニシャルコインオファリング。 +: Initial Coin Offering（新規コイン公開）。 インフレーション -: （Inflation）新しい [ブロック](default:ブロック) が生成されるたびに、報酬として少量の が新規発行される仕組み。 - 2021年3月のネットワークローンチの48時間後に開始し、当初は1ブロックあたり約200 XYM。 - 報酬は緩やかに減少し、30年後には1 XYM、105年後には完全に終了する。 +: 新しい [ブロック](default:ブロック) ごとに新しく発行され、作成した [ノード](default:ノード) に報酬として与えられる少量の [XYM](default:XYM) です。 + インフレーションは2021年3月のネットワーク開始から48時間後に始まり、1ブロックあたり約200 XYMでした。 + 報酬は緩やかな曲線に従って時間とともに徐々に減少し、30年後に1ブロックあたり1 XYMとなり、105年後に完全に消失します。 IP -: （Intellectual Property）知的財産。 +: Intellectual Property（知的財産）。 IRS -: （Internal Revenue Service）アメリカ合衆国内国歳入庁。 - 米国居住者または米国市民が税金を納める機関。 +: Internal Revenue Service（内国歳入庁）。米国に住んでいる人、または米国市民が税金を支払う相手です。 KYC -: （Know Your Customer）顧客確認。 に関連。 +: Know Your Customer（顧客確認）。[AML](default:AML) に関連します。 LATAM -: ラテンアメリカ（中南米地域）。 +: Latin America（ラテンアメリカ、中央アメリカと南アメリカ）。 + +mainnet +: NEM のメインネットワークです。実価値のあるトランザクションが行われ、[テストネット](default:テストネット) と対比されます。 MEV -: マイナー抽出可能価値（Miner/Maximal Extractable Value）。 - マイナーがブロック内のトランザクション順序を操作し、利益を得る手法。 - [フロントランニング](default:フロントランニング)、[バックランニング](default:バックランニング)、[サンドイッチ](default:サンドイッチ)> などが含まれる。 +: Miner-Extractable Value または Maximal-Extractable Value（マイナー抽出可能価値または最大抽出可能価値）。マイナーがブロック内のトランザクションを並べ替えて、何らかの利益を得るプロセスです。 + [フロントランニング](default:フロントランニング)、[バックランニング](default:バックランニング)、[サンドイッチ](default:サンドイッチ) を使います。 + +mijinnet +: もともと企業展開を想定した許可型 NEM ネットワークで、公開の [メインネット](default:メインネット) と [テストネット](default:テストネット) とは異なります。 NAM -: （North America）北米地域。 +: North America（北アメリカ）。 NEM -: New Economy Movement（新経済運動）。 +: New Economy Movement（新しい経済運動）。 NFT -: 非代替性 [トークン](default:トークン)。 - ブロックチェーン上で固有のデジタル資産を表現する手段。 +: 個々のエンティティをブロックチェーンベースの資産として表す方法である、非代替性 [トークン](default:トークン) です。 NIS1 -: の最初のパブリックメインネット用ノード実装。 - ネイティブ通貨 を扱い、2015年3月31日にローンチされた。 +: [NEM](default:NEM) のブロックチェーンノードの最初のバージョンです。ネイティブ通貨 [XEM](default:XEM) で公開 [メインネット](default:メインネット) を運用します。 + 2015年3月31日に最初にローンチされました。 PoC -: （Proof of Concept）概念実証。プロトタイプの意。 +: Proof of Concept（概念実証）、つまりプロトタイプです（コンセンサスプロトコルではありません）。 PoI -: （Proof of Importance）プルーフ・オブ・インポータンス。 - で使用されるコンセンサス方式。 - に似ているが、ステーク量に加えてアカウントの活動度も評価する。 +: Proof of Importance（Proof-of-Importance、インポータンスの証明）。 + NEM が使用するコンセンサスプロトコルです。 + [PoS](default:PoS) と似ていますが、ステークに加えてアカウントの活動も測定します。 PoS -: （Proof of Stake）プルーフ・オブ・ステーク。 - 例えばイーサリアムなどで採用されているコンセンサス方式。 - -PoS+ -: （Proof of Stake Plus）プルーフ・オブ・ステーク・プラス。 - Symbol のコンセンサスメカニズム。 - を拡張し、ステーク量に加えてネットワーク上の活動も考慮する。 - 各アカウントが [ブロックを収穫](default:ハーベスティング) する確率は、 - その [インポータンス](default:インポータンス) スコアに基づいて計算される。 +: Proof of Stake（プルーフ・オブ・ステーク）。たとえば Ethereum で使用されるコンセンサスプロトコルです。 PoW -: （Proof of Work）プルーフ・オブ・ワーク。 - 例えばビットコインで採用されているコンセンサス方式。 +: Proof of Work（プルーフ・オブ・ワーク）。たとえば Bitcoin で使用されるコンセンサスプロトコルです。 ラグプル -: （Rug Pull）開発者がプロジェクトを放棄し、資金を持ち逃げする詐欺的行為。 +: 暗号資産の開発者がプロジェクトを放棄し、資金を持ち逃げする悪意のある行為です。 サンドイッチ -: （Sandwich） で一般的な 手法の一種。 - 未処理トランザクションを見つけ、その直前に注文を置き（[フロントランニング](default:フロントランニング)）、 - 直後にもう一つの注文を置く（[バックランニング](default:バックランニング)）ことで利益を得る。 +: [DeFi](default:DeFi) で一般的な [MEV](default:MEV) 技法の一種です。 + ネットワーク内の保留中のトランザクションを見つけ、そのトランザクションの *直前*（[フロントランニング](default:フロントランニング)）と直後（[バックランニング](default:バックランニング)）に1つずつ注文を置いて挟み込みます。 SDK -: （Software Development Kit）ソフトウェア開発キット。 - 特定プラットフォーム向けアプリケーションを簡単に作成できるライブラリ群。 +: Software Development Kit（ソフトウェア開発キット）。特定のプラットフォーム向けアプリケーションの作成を簡単にするソフトウェアライブラリです。 シャーディング -: （Sharding）イーサリアムの[スケーリングソリューション](https://ethereum.org/en/developers/docs/scaling/#sharding)。 +: Ethereum の [スケーリングソリューション](https://ethereum.org/en/developers/docs/scaling/#sharding) です。 SXDH -: （Symmetric External Diffie–Hellman）対称外部 [Diffie–Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) 仮定。 +: Symmetric External [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)。 シビル攻撃 -: 攻撃者が多数の偽アカウントやアイデンティティを作成し、 - ネットワークやコンセンサス過程に過剰な影響力を与えようとする攻撃。 - 一般的な対策として、 や のように影響力を希少資源に結びつける方法がある。 +: 単一の攻撃者が多数の偽のアイデンティティやアカウントを作成し、ネットワークまたはコンセンサスプロセスに対して不釣り合いな影響力を得る攻撃です。 + 一般的な対策には [PoW](default:PoW) や [PoS](default:PoS) があり、影響力を希少なリソースに結び付けます。 + +Symbol +: NEM プロジェクトが作成し、2021年3月に [NIS1](default:NIS1) の発展形としてローンチしたブロックチェーンプラットフォームです。 + +testnet +: 開発を目的とする NEM のテストネットワークです。 + テスト用 [XEM](default:XEM) は [フォーセット（英語ソース）](https://github.com/NemProject/nem/blob/225dad4731d80f622d24ee75b6373b65c0f7db1b/mkdocs/pages/en/devbook/accounts/testnet-faucet.md) から自由に取得できるため、このネットワーク上のトランザクションには [メインネット](default:メインネット) のトランザクションと異なり実価値がありません。 TLC -: Tender Loving Care（愛情を込めた丁寧な対応）。 +: Tender Loving Care（手厚い配慮）。 TLS -: 通信を暗号化するセキュリティプロトコル。ネットワーク上のピア間通信に使用される。 +: ネットワーク上のピア間の通信を暗号化するセキュリティプロトコルです。 トークン -: （Token）デジタル資産を表す単位。Symbol では [モザイク](default:モザイク) と呼ばれる。 +: デジタル資産の表現です。 + NEM では [モザイク](default:モザイク) と呼ばれます。 TPS -: （Transactions Per Second）１秒あたりのトランザクション数。 +: Transactions Per Second（1秒あたりのトランザクション数）。 TradFi -: （Traditional Finance）従来型金融。 の対義語。 +: Traditional Finance（伝統的金融）。Decentralized Finance（[DeFi](default:DeFi)）の対義語です。 USP -: （Unique Selling Proposition / Point）独自の販売提案またはセールスポイント。 - 製品を競合他社と差別化する特徴。 +: Unique Selling Proposition または Unique Selling Point（独自の販売提案または独自の販売ポイント）。 + 製品を競合他社と区別するために広告で使える特徴です。 VPS -: （Virtual Private Server）仮想専用サーバー。 - データセンター上にホストされ、リモートで物理サーバーのように扱える仮想マシン。 +: Virtual Private Server（仮想プライベートサーバー）。 + 通常はデータセンターでホストされ、リモートでアクセスでき、従来の物理マシンとして扱える仮想マシンです。 VRF -: （Verifiable Random Function）検証可能なランダム関数。 +: Verifiable Random Function（検証可能ランダム関数）。 XEM -: ブロックチェーンのネイティブ通貨。 +: NEM ブロックチェーンのネイティブ通貨です。 XYM -: Symbol ブロックチェーンのネイティブ通貨。 +: [Symbol](default:Symbol) ブロックチェーンのネイティブ通貨です。 + +アカウント +: デジタル資産を管理するブロックチェーン上の単位です。 + +アドレス +: 公開鍵を共有するための短い形式です。 + +ブロック +: 特定の時点で承認されたトランザクションの集合です。 + +ハッシュ +: 入力データから生成される固定長の暗号学的値です。 + +メインネット +: 実価値のあるトランザクションが行われる NEM の公開ネットワークです。 + +テストネット +: 開発用の NEM ネットワークです。 diff --git a/mkdocs/pages/ja/textbook/harvesting.md b/mkdocs/pages/ja/textbook/harvesting.md new file mode 100644 index 000000000..3b33bf453 --- /dev/null +++ b/mkdocs/pages/ja/textbook/harvesting.md @@ -0,0 +1,147 @@ +# ハーベスティング + +ハーベスティング +: NEM が新しい [ブロック](default:ブロック) をチェーンに追加し、参加する [アカウント](default:アカウント) に報酬を分配するプロセスです。 + [PoW](default:PoW) の **マイニング** や [PoS](default:PoS) の **ステーキング** と似た役割を果たします。 + +新しいブロックはそれぞれ、1つの [ハーベスターアカウント](default:ハーベスターアカウント) に代わって単一の [ノード](default:ノード) が生成します。 +ノードが次のブロックを生成する確率は、そのノードのハーベスターアカウントのインポータンスの合計によって重み付けされます。 + +ハーベスターアカウント +: ハーベスティングに参加するアカウントです。 + インポータンスがブロックを生成する確率を決め、ハーベストした各ブロックの報酬を受け取ります。 + +ブロックに含まれる [トランザクション](default:トランザクション) の手数料は、そのブロックを支えたインポータンスを持つ単一のハーベスターアカウントに全額支払われます。 + +## 資格 {: #eligibility } + +[PoW](default:PoW) のマイニングとは異なり、ハーベスティングに専用ハードウェアは必要ありません。 + +次の条件を満たす [アカウント](default:アカウント) はハーベスティングに参加できます。 + +* [ベスティング](default:ベスティング) 済み残高が 10'000 XEM 以上。 +* 直接または委任を通じて [ノード](default:ノード) に接続されている。 + +アカウントの [インポータンス](default:インポータンス) スコアが、ハーベストできる頻度を決定します。 + +## ハーベスティングのプロセス {: #harvesting-process } + +NEM には、次のブロックをハーベストするノードを決める中央のコーディネーターは存在しません。 +代わりに、すべての [ノード](default:ノード) が、それぞれの [ハーベスターアカウント](default:ハーベスターアカウント) について同じ決定論的な資格確認を実行し、独立して競争します。 + +このため、主に各アカウントの [インポータンス](default:インポータンス) に基づいて _ターゲット_ 値を計算します。 +インポータンスが高いほど、ターゲットも高くなります。 + +ノードは各ハーベスターアカウントについて、候補ブロックの [生成ハッシュ](./blocks.md#derived-fields) から _ヒット_ と呼ばれる数値を計算します。 + +いずれかのハーベスターアカウントがターゲット値未満のヒットを生成すると、ノードは [未承認トランザクションプール](default:未承認トランザクションプール) から候補ブロックを組み立て、ネットワークの他のノードにアナウンスします。 + +他のノードはブロックを検証し、次を確認します。 + +* ブロックの署名が、主張されたハーベスターによるものである。 +* [トランザクション](default:トランザクション) が有効である。 +* ヒットが実際にターゲットより低い。 + +どれかの確認に失敗すると、他のノードは新しいブロックを無視します。 +[コンセンサス](default:コンセンサス) メカニズムにより、ノードは最終的にネットワークの他のノードが合意するブロックを採用します。 + +ブロックが有効なら、他のノードはそれを受け入れ、自分のチェーンのコピーに含めます。 +次のブロック高でこのサイクルが繰り返されます。 + +!!! info "同時ブロック作成" + 複数のノードが同じ高さでブロックを生成することを防ぐ特別な仕組みはありません。 + この場合、異なるノードがチェーン上の同じ高さで異なるブロックを採用するため、ネットワークが一時的に [フォーク](default:フォーク) することがあります。 + + [コンセンサス](default:コンセンサス) メカニズムは、ノードが競合するブロックを認識すると、これらの競合を解決します。 + +??? abstract "ターゲットとヒットの計算" + + * **ターゲット** は各ノードが独立して計算し、特定のアカウントを使って次のブロックをハーベストする可能性を表します。 + 次の3つの要素に依存します。 + + * アカウントの [インポータンス](default:インポータンス) スコア。活動量が多いアカウントや資金の多いアカウントは、より頻繁にハーベストします。 + * ネットワーク全体の **難易度**。最近のブロック生成時間に応じて動的に調整され、一定のブロック生成レートを維持します。 + * 最後のブロックからの **経過時間**。遅延が長いほど、新しいブロックが生成される可能性が高くなります。 + + * **ヒット** はブロックの [生成ハッシュ](./blocks.md#derived-fields) から決定論的に導出されます。 + この生成ハッシュは、前のブロックの生成ハッシュとハーベスターの [公開鍵](default:公開鍵) を組み合わせて計算されたハッシュです。 + したがってヒットは、過去のハーベスターの完全なチェーンと、現在ハーベストを試みる者に依存します。 + + ブロックを有効にするには、ノードのターゲットがヒットより **大きく** なければなりません。 + インポータンスが高いほど、また遅延が長いほどターゲットは増加し、難易度が高いほどターゲットは減少します。 + +## ハーベスティングの方法 {: #harvesting-methods } + +ノード所有者は、簡単さとセキュリティのどちらを優先するかに応じて、[ローカル](#local-harvesting) または [リモート](#remote-harvesting) ハーベスティングを有効にして参加できます。 +ノードを運用していなくても残高要件を満たすアカウントは、[委任ハーベスティング](#delegated-harvesting) によってノードへリンクしてハーベストできます。 + +### ローカルハーベスティング {: #local-harvesting } + +ローカルハーベスティング +: 報酬がハーベスターアカウントに直接送られる [ハーベスティング](default:ハーベスティング) 方法です。 + [ノード](default:ノード) は、マシンに保存したオペレーターの [メインキー](default:メインキー) を使って生成した [ブロック](default:ブロック) に署名します。 + +!!! warning + ハーベスターアカウントは、高い [インポータンス](default:インポータンス) スコアを維持するために相当な残高を保有する必要があります。 + 秘密鍵を常時オンラインのマシンに保存すると、不正アクセス時に全残高が危険にさらされます。 + +ローカルハーベスティングは設定が簡単ですが、これらのセキュリティリスクにより、公開ノードには適していません。 +ほとんどのオペレーターは代わりにリモートハーベスティングを選びます。 + +### リモートハーベスティング {: #remote-harvesting } + +リモートハーベスティング +: ブロック署名を別の [リモートキー](default:リモートキー)（リモートアカウント）に委任しながら、ノードの [インポータンス](default:インポータンス) スコアと報酬をオペレーターの [メインキー](default:メインキー) に結び付ける [ハーベスティング](default:ハーベスティング) の方法です。 + +リモートアカウントは資金を持たず、ハーベスターのメインアカウントに代わってブロックに署名するためだけに存在します。 +その秘密鍵は常時オンラインのマシン上のノード設定ファイルに保存されるため、使い捨てを前提としています。 + +リモートアカウントは _Account Key Link_ トランザクションに署名することで指定され、メインアカウントの [インポータンス](default:インポータンス) がリモートアカウントへ移ります。 +リモートアカウントは360ブロック（約6時間）の待機期間後にブロックへの署名を開始し、別の _Account Key Link_ トランザクションで削除できますが、同じ待機期間が必要です。 + +メインアカウントは引き続きノードのインポータンスを決定し、すべてのブロック報酬を受け取ります。 +ただし、その鍵はオフラインのままで、侵害から守られます。 +簡単にするため、ブロックにはリモートアカウントが署名していても、メインアカウントをハーベスターアカウントと呼びます。 + +この役割分担はハーベスターの資金を強力に保護するため、ほとんどのオペレーターにとってリモートハーベスティングが推奨される方法です。 + +### 委任ハーベスティング {: #delegated-harvesting } + +委任ハーベスティング +: ノードを運用していない資格のあるアカウントが、第三者のノードにハーベスティングを委任できる [ハーベスティング](default:ハーベスティング) の方法です。 + 委任するアカウントの [インポータンス](default:インポータンス) スコアが使われ、ハーベスト報酬は全額そのアカウントが受け取ります。 + +このようなアカウントを _委任者_ または _委任ハーベスター_ と呼びます。 + +委任者 +: 自身の [インポータンス](default:インポータンス) を保持しながら第三者のノードへ [委任ハーベスティング](default:委任ハーベスティング) を委任し、ハーベスト報酬を受け取るアカウントです。 + _委任ハーベスター_ とも呼ばれます。 + +ノードが作業を行っても、委任者は引き続きハーベスターとみなされ、NEM はブロック報酬を全額委任者に支払います。 +この仕組みにより、アカウントは自分のノードを運用せずに報酬を得られます。 + +委任ハーベスティングはリモートハーベスティングと同じリモートアカウント構成を使います。 +委任者はリモートアカウントの [秘密鍵](default:秘密鍵) を第三者のノードに渡し、ノードはそのアカウントをハーベスト対象に追加して委任者に代わってブロックに署名します。 + +ノードがリモートアカウントを受け入れるかどうかはオペレーターの方針によります。 +委任者はリンクする鍵を変更して、いつでもこの関係を取り消せます。 + +リモートハーベスティングと同様に、ブロック署名は委任者以外のアカウントが行うため、委任者の秘密鍵を安全な保管場所から出す必要はありません。 + +!!! info "リモートハーベスティングと委任ハーベスティングの違い" + + どちらの方法も同じリモートアカウント構成を使います。 + 違いは誰がノードを運用するかだけです。リモートハーベスティングではオペレーターが自身のノードを通じてハーベストし、委任ハーベスティングではアカウントが第三者のノードを通じてハーベストします。 + +## 報酬の分配 {: #reward-distribution } + +[ブロック](default:ブロック) がハーベストされると、ハーベスターはブロック内のすべての [トランザクション](default:トランザクション) の手数料合計を受け取ります。 + +[ローカルハーベスティング](default:ローカルハーベスティング) では、ハーベスターが自分のブロックに署名し、報酬を直接受け取ります。 +[リモートハーベスティング](default:リモートハーベスティング) と [委任ハーベスティング](default:委任ハーベスティング) ではリモートアカウントがブロックに署名しますが、報酬はメインアカウントに流れ、リモートアカウントやそれをホストするノードオペレーターには流れません。 + +NEM はハーベスターとノードオペレーターの間でブロック報酬を分割しません。 +他の人のリモートアカウントをホストするノードは、そのブロックから何も受け取りません。 +プロトコルはハーベスターに全額を支払います。 + +委任ハーベスターのホスティングに対してノードオペレーターが補償を受けるかどうかはプロトコルの範囲外で、当事者間の取り決めに委ねられます。 diff --git a/mkdocs/pages/ja/textbook/intro.md b/mkdocs/pages/ja/textbook/intro.md index 76ca6903d..482e6db6e 100644 --- a/mkdocs/pages/ja/textbook/intro.md +++ b/mkdocs/pages/ja/textbook/intro.md @@ -1,13 +1,12 @@ ---- -title: 序章 ---- - -# テキストブックへようこそ - -このテキストブックでは、NEM ブロックチェーンを支える基本的な概念を解説します。 - -[ユーザーマニュアル](../userbook/intro.md) や [開発者マニュアル](../devbook/intro.md) には、必要に応じて -関連するテキストブックのページへのリンクが含まれているため、 -この本を最初から最後まで読む必要は基本的にありません。 - -もちろん、ナビゲーションメニューを使って自由に読み進めていただいてかまいません。 +--- +title: ようこそ +--- + +# テキストブックへようこそ + +このテキストブックでは、NEM ブロックチェーンを支える概念を解説します。 + +[ユーザーマニュアル](../userbook/intro.md) と [開発者マニュアル](../devbook/intro.md) には、必要に応じて +適切なテキストブックのページへのリンクが含まれているため、通常はこの本を最初から最後まで読む必要はありません。 + +ナビゲーションメニューを使って、自由にテキストブックを読み進めてください。 diff --git a/mkdocs/pages/ja/textbook/mosaics.md b/mkdocs/pages/ja/textbook/mosaics.md new file mode 100644 index 000000000..7b8e45272 --- /dev/null +++ b/mkdocs/pages/ja/textbook/mosaics.md @@ -0,0 +1,229 @@ +# モザイク + +モザイク +: NEM ブロックチェーン上の資産を表すもので、他のプロトコルでは一般にトークンと呼ばれます。 + 例として、通貨、ライセンス、コレクション、アクセス権、投票権があります。 + +他のプラットフォームのスマートコントラクトベースのトークンとは異なり、NEM のモザイクはプロトコルレベルで直接サポートされ、追加のコーディングなしで使用できます。 + +各モザイクは新しい種類の資産を定義し、その種類に属する個々のトークンは _モザイク単位_ と呼ばれます。 +モザイクは、各単位を交換できるコインのような代替可能資産や、絵画や [NFT](default:NFT) のような各単位が唯一無二である非代替性資産を表せます。 + +モザイクは登録済みの [ネームスペース](default:ネームスペース) の下に存在し、[完全修飾名](#fully-qualified-name) で識別され、親ネームスペースのレンタルから期間を継承します（[ライフタイム](#lifetime) を参照）。 + +## 名前 {: #name } + +名前はネームスペース内でモザイクを識別するもので、その中で一意である必要があります。 +次の形式規則に従います。 + +* 小文字、数字、ハイフン `-`、アンダースコア `_`、アポストロフィ `'` だけを含められます。 +* 英字または数字で始める必要があります。 +* 最大 **32文字** です。 + +一度登録したモザイク名は変更できません。 + +## 完全修飾名 {: #fully-qualified-name } + +モザイクの **完全修飾名**（**モザイク ID** とも呼ばれます）は、ネットワーク上の一意の識別子です。 +ネームスペースとローカルモザイク名をコロンで結合し、`:` の形式にします。 + +| 部分 | 定義 | 長さ制限 | +| --------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------- | +| **ネームスペース** | `:` の前にある、ドットで区切られた1つのルートネームスペースと最大2つのサブネームスペース | 16文字（ルート）および64文字（各サブネームスペース） | +| **モザイク名** | `:` の後にあるローカル名。 | 32文字 | + +!!! note "コロンは区切り文字にすぎません" + + コロンはネームスペースとモザイク名を区切るものであり、どちらの名前にも含まれません。 + アプリケーションによっては、代わりに `.` または `!` と表示されます。 + +例： + +* `nem:xem`：ネットワーク固有の通貨。 +* `mycompany.tokens:goldcoin`：架空の企業トークン。 + +## 説明 {: #description } + +各モザイクには、資産の目的、由来、利用条件などを記録する最大 **512文字** の自由記述フィールド **説明** を設定できます。 + +## プロパティ {: #properties } + +モザイクには、転送方法と供給量の変化を制御する動作プロパティがあります。 + +### 可分性 {: #divisibility } + +可分性 +: モザイク数量に設定できる小数点以下の桁数を定義します。 + 可分性 `0` のモザイクは不可分で、整数単位でのみ転送できます。 + より大きい値では小数単位を使用できます。 + +たとえば可分性が `2` の場合、1 _全体単位_ を100 _小数単位_（10^2^）に分けられ、`0.01` 刻みでモザイクを扱えます。 + +小数単位は _原子単位_ とも呼ばれます。この例では、1全体単位は100原子単位で構成されます。 + +他の多くのプロトコルでは、この値は固定されています。たとえば Bitcoin は小数点以下8桁、Ethereum は18桁を使用します。 +NEM では、資産の用途に応じて各モザイクが独自の可分性を定義できます。 + +NEM で許可される可分性の最大値は `6` です。 + +### 初期供給量 {: #initial-supply } + +発行時に作成されるモザイク単位の総数を定義します。 + +可分性に関係なく、モザイクの総供給量は **9 × 10^15^** 原子単位を超えられません。 + +[供給量の可変性](#supply-mutability) を有効にしない限り、供給量は固定されます。 + +### 供給量の可変性 {: #supply-mutability } + +作成後にモザイクの総供給量を増減できるかどうかを示します。 +目的の資産ライフサイクルに応じて、モザイク単位を動的に発行または削除できます。 + +総供給量を変更できるのは、モザイクを作成したアカウントだけです。 +変更が影響するのは作成者の残高だけです。 + +* _ミント_（供給量の増加）では、新しい単位が作成され、作成者のアカウントに追加されます。 +* _バーン_（供給量の減少）では、作成者のアカウントから既存の単位が削除されます。 + アカウントの残高が不足している場合、操作は失敗します。 + +### 転送可能性 {: #transferability } + +モザイクをアカウント間で自由に転送できるかどうかを指定します。 +無効にすると、すべての転送で作成者のアカウントが送信者または受信者のいずれかになる必要があります。 + +```dot +digraph "Transferability" { + rankdir="LR"; + node [fontsize=12]; + "Mosaic Creator" [label="モザイク作成者"]; + "Account A" [label="アカウント A"]; + "Account B" [label="アカウント B"]; + + "Mosaic Creator" -> "Account A" [dir=both]; + "Mosaic Creator" -> "Account B" [dir=both]; + "Account A" -> "Account B" [dir=both style=dashed labeldistance=7 labelangle=-60 + minlen=4 headlabel="モザイクが\n転送可能な場合のみ"]; + + { rank = same; "Account A"; "Account B"; } +} +``` + +## 徴収手数料（levy） {: #levy } + +徴収手数料（levy） +: モザイクに付加できる任意の手数料です。そのモザイクを転送するたびに、トランザクション手数料に加えて指定アカウントへ支払われます。 + +徴収手数料は、たとえば転送ごとに手数料やロイヤリティを課して、資産を管理するアカウントに資金を提供するために使われます。 + +徴収手数料には次の4つのフィールドがあります。 + +| フィールド | 説明 | +| ------------- | ----------------------------------------------------------------------------------------- | +| **タイプ** | **Absolute**（固定数量）または **Percentile**（転送量に比例）。 | +| **受取人** | すべての転送で徴収手数料を受け取るアカウント。 | +| **モザイク ID** | 徴収手数料が支払われるモザイク。転送対象のモザイクとは異なる場合があります。 | +| **手数料** | すべての転送で課金される徴収手数料用モザイクの数量です。
  • Absolute 徴収手数料では、原子単位で表す正確な数量です。
  • Percentile 徴収手数料では、[ベーシスポイント](https://en.wikipedia.org/wiki/Basis_point)（10'000ベーシスポイント = 100%）で表す転送量に対する割合です。
| + +### 徴収手数料の請求方法 {: #how-levies-are-charged } + +徴収手数料付きのモザイクを転送トランザクションに含めると、ネットワークは通常のトランザクション手数料に加えて、送信者から徴収手数料を自動的に徴収し、徴収手数料の受取人に入金します。 + +徴収手数料は転送量に上乗せされます。受取人は送信された数量全体を受け取り、送信者は転送量と徴収手数料（およびトランザクション手数料）の両方を引き落とされます。 + +#### 絶対徴収手数料の計算 {: #absolute-levy-calculation } + +絶対徴収手数料では、手数料は転送ごとに課金される正確な数量であり、徴収手数料用モザイクの原子単位で表します。 + +たとえば、転送対象のモザイク自体で原子単位 `10` の絶対徴収手数料を支払う場合、原子単位 `1'000` を送ると送信者から合計 `1'010` が引き落とされます。 +受取人には `1'000` が、徴収手数料の受取人には `10` が入金されます。 + +#### パーセンタイル徴収手数料の計算 {: #percentile-levy-calculation } + +パーセンタイル徴収手数料では、手数料をベーシスポイントで解釈します。1ベーシスポイントは1%の100分の1です。 +たとえば手数料 `100` は1%、手数料 `10'000` は100%を課金します。 + +徴収手数料は、転送量の **原子単位** から計算します。 + +$$ +\text{levy} = \left\lfloor \frac{\text{fee} \cdot \text{transferred amount}}{\text{10'000}} \right\rfloor +$$ + +結果は、徴収手数料用モザイクで課金される原子単位の数量です。 +切り捨て後に0になる徴収手数料は課金されません。 + +!!! note "両方のモザイクの可分性が課金額に影響します" + + パーセンタイル徴収手数料では、ネットワークは割合を適用する前に、転送対象モザイクと徴収手数料用モザイクの間で変換を行いません。 + 転送量の原子単位の数から徴収手数料を計算し、その結果を徴収手数料用モザイクの原子単位の数量として扱います。 + + そのため、設定した割合が正確になるのは原子単位のレベルだけです。 + 2つのモザイクの [可分性](default:可分性) が異なる場合、全体単位で表示される課金額は、表示された送信量に同じ割合を適用した場合よりはるかに大きく見えたり、小さく見えたりします。 + + たとえば、可分性が2のモザイクで、1%の徴収手数料を可分性6の `nem:xem` で支払う場合を考えます。 + + * 全体単位50を送ると、最初のモザイクの原子単位 `5'000` が転送されます。 + * 1%の徴収手数料は `5'000` の1%として計算されるため、結果は `50` です。 + * その結果は `nem:xem` の原子単位 `50` として課金されます。 + * `nem:xem` の可分性は6なので、原子単位 `50` はわずか 0.00005 XEM であり、50 XEM の1%を大きく下回ります。 + +### 転送要件 {: #transfer-requirements } + +送信者は、転送対象モザイクの転送量を賄う残高に加え、徴収手数料用モザイクで徴収手数料を賄う残高も持つ必要があります。徴収手数料用モザイクは、転送対象モザイクと異なる場合があります。 + +転送時点で、徴収手数料用モザイクがネットワーク上に存在している必要もあります。 +たとえばネームスペースが失効して更新されず、その結果、徴収手数料用モザイクが [失われた](#lifetime) 場合、その徴収手数料付きモザイクの転送は拒否されます。 + +### 制限事項 {: #limitations } + +徴収手数料は再帰的ではありません。 +徴収手数料の支払いに使うモザイクが独自の徴収手数料を持っていても、2つ目の徴収手数料は適用されません。 + +!!! warning "徴収手数料は確実な課金ではありません" + + 徴収手数料は再帰的ではないため、回避できます。 + + たとえば、モザイク `A` の徴収手数料がモザイク `B` で支払われ、別のモザイク `C` の徴収手数料が `A` で支払われる場合、`C` を転送すると `C` の徴収手数料として `A` が移動しますが、`A` の徴収手数料は発生しません。 + + したがって徴収手数料は、すべての転送に対して強制できる保証ではなく、最善努力の手数料です。 + +## ライフタイム {: #lifetime } + +モザイク自体には期間がありません。 +そのライフタイムは親ネームスペースのライフタイムに結び付いています。 + +* ネームスペースがアクティブな間は、モザイクを転送でき、供給量を変更できます（[プロパティ](#properties) の制限を受けます）。 +* ネームスペースが失効するとモザイクは非アクティブになり、転送と供給量の変更は拒否されますが、既存の残高は保持されます。 +* 元の所有者が [猶予期間](./namespaces.md#duration) 中にネームスペースを更新すると、モザイクとその残高を再び使用できます。 + +!!! warning "猶予期間を過ぎたモザイクの喪失は永続的です" + 猶予期間の後、モザイクは永久に失われます。 + モザイクを保有するアカウントは残高にアクセスできなくなり、モザイクを転送できません。 + + 後から同じ名前でモザイクを登録しても、元の資産の復元ではなく新しい資産が作成されます。 + +[ネームスペースの期間](./namespaces.md#duration) で、ネームスペースのレンタルライフサイクルを説明しています。 + +## 作成手数料 {: #creation-fee } + +新しいモザイクの登録には、一度だけ支払う **10 XEM** の _作成手数料_ が必要です。 + +手数料は作成時に支払う必要があり、返金されません。 +モザイク作成手数料を集めるネットワークアカウントである _シンクアカウント_ に送られます。 +[メインネット](default:メインネット) のブロック3,481,580以降、ネットワークはシンクアカウントからのトランザクションを拒否します。 +その結果、集められた手数料は実質的にバーンされます。 + +!!! note "トランザクション手数料と作成手数料" + モザイクの作成にはトランザクションのアナウンスが必要で、関連する手数料もかかります。 + ただし、このトランザクション手数料は通常、作成手数料と比べてわずかです。 + +## モザイクの変更 {: #modifying-a-mosaic } + +作成後、元の作成者はモザイクの **定義** の一部を変更できます。 + +各フィールドには固有のルールがあります。 + +* **説明**：いつでも変更できます。 +* **転送可能性** と **名前**：一度設定すると変更できません。 +* **可分性**、**初期供給量**、**供給量の可変性**、**徴収手数料**：作成者がモザイクの全供給量を保有している間だけ変更できます。 + +[供給量の可変性](#supply-mutability) が有効なら、総供給量を変更（ミントまたはバーン）できます。 diff --git a/mkdocs/pages/ja/textbook/namespaces.md b/mkdocs/pages/ja/textbook/namespaces.md new file mode 100644 index 000000000..974c7064a --- /dev/null +++ b/mkdocs/pages/ja/textbook/namespaces.md @@ -0,0 +1,135 @@ +# ネームスペース + +ネームスペース +: [アカウント](default:アカウント) にレンタルされる登録済みの名前です。その下に定義された [モザイク](default:モザイク) の接頭辞とグループ化に使用します。 + +ネームスペースを使うと、アカウントは `mycompany.tokens` のような意味のある接頭辞の下に関連するモザイクをまとめられます。 +ネットワーク固有の通貨も同じパターンに従います。一般に [XEM](default:XEM) と呼ばれる `nem:xem` は `nem` ネームスペースに属します。 + +ネームスペースを登録するアカウントを _所有者_ と呼びます。 +所有者はその下に定義できるモザイクを制御するため、ネームスペースは名前の構造と所有権の範囲を提供します。 + +ネームスペースは限られたリソースであるため、永久に所有するのではなく一定期間レンタルされますが、レンタルは更新できます。 + +## サブネームスペース {: #subnamespaces } + +NEM のネームスペースは、インターネットのドメイン名と同様の階層構造に従います。 +各名前はドットで区切られた1〜3個の部分で構成されます。たとえば `foo`、`foo.bar`、`foo.bar.baz` です。 + +最初の部分を _ルートネームスペース_ と呼びます。 +追加の部分は _サブネームスペース_ で、ルートの下に個別に登録する必要があります。 + +ルートネームスペース +: 親を持たないネームスペースです。 + サブネームスペースを階層的にまとめるために使用できます。 + +サブネームスペース +: ルートまたは別のサブネームスペースを親とするネームスペースです。 + _子ネームスペース_ とも呼ばれます。サブネームスペースはルートネームスペースの有効期限が切れると失効します（[期間](#duration) を参照）。 + +## 名前 {: #name } + +各ネームスペースには、ネットワーク上で識別する一意の名前があり、特定の形式規則に従う必要があります。 + +* 名前には小文字、数字、ハイフン `-`、アンダースコア `_` だけを使用できます。 +* 名前は英数字で始める必要があります。 +* ルート名は最大16文字です。 +* ルート名 `nem`、`user`、`account`、`org`、`com`、`biz`、`net`、`edu`、`mil`、`gov`、`info` はプロトコルによって予約されており、登録できません。 +* サブネームスペース名は最大64文字です。 + +登録後に名前を変更することはできません。 + +## 期間 {: #duration } + +ルートネームスペースを登録すると、約1年間（[メインネット](default:メインネット) で525600ブロック）レンタルされます。 +この期間中、所有者は次の操作を行えます。 + +* ネームスペースの下に [モザイク](default:モザイク) を定義する。 +* サブネームスペースを作成する。 +* ルートネームスペースを更新する。 + サブネームスペースを更新する必要はありません。ルートネームスペースと同じ期間を持つためです。 + +登録中の更新は、**有効期限前の最後の43200ブロック**（[メインネット](default:メインネット) で約30日）に制限されます。 +更新するたびに、有効期限は前の有効期限からではなく更新ブロックから1年後に設定されます。ネームスペースを複数年分前払いすることはできません。 + +有効期限前に更新されなければ、約30日間（43200ブロック）の _猶予期間_ に入ります。 +この間、ネームスペースは実質的に無効になります。配下に定義されたモザイクは非アクティブになりますが（[モザイクのライフタイム](./mosaics.md#lifetime) を参照）、ネームスペースは他の人が登録できる状態にはまだなりません。 + +猶予期間中に更新できるのは元の所有者だけです。 +猶予期間が終わると、ネームスペースは完全に解放され、他の人が登録できるようになります。 + +```dot +digraph "Namespace registration" { + rankdir="LR"; + fontsize=12; + Available [label="ネームスペース\nが\n利用可能"]; + Registered [label="ネームスペース\nが\n登録済み"]; + "Grace Period" [label="\n猶予期間\n "]; + "Available Again" [label="ネームスペース\nが再び\n利用可能"]; + + Available -> Registered [label="登録"]; + Registered -> "Grace Period" [label="有効期限切れ"]; + Registered -> Registered [label="更新"]; + "Grace Period" -> Registered [label="\n更新" constraint=false]; + "Grace Period" -> "Available Again" [label="解放"]; +} +``` + +ネームスペース登録の状態に応じて、次の操作が許可されます。 + +| 操作 | ネームスペース利用可能 | ネームスペース登録済み | 猶予期間 | +| ----------------------------------- | :-----------------: | :--------------------: | :----------------: | +| ネームスペースを登録 | :white_check_mark: | :material-close: | :material-close: | +| サブネームスペースを登録 | :material-close: | :white_check_mark: | :material-close: | +| ネームスペースの下にモザイクを定義 | :material-close: | :white_check_mark: | :material-close: | +| ネームスペースを更新 | :material-close: | :white_check_mark: | :white_check_mark: | + +!!! note "`nem` ネームスペースは失効しません" + + [XEM](default:XEM) を保持する `nem` ネームスペースは恒久的にアクティブで、レンタルと更新のサイクルから除外されます。 + +## レンタル手数料 {: #lease-fee } + +ネームスペースの登録には、ネットワーク通貨（[XEM](default:XEM)）によるレンタル手数料が必要です。 + +* **ルートネームスペース**：登録または更新ごとに100 XEM。 +* **サブネームスペース**：登録時に一度だけ10 XEM。 + +これは、ネームスペースが限られたグローバルリソースであることを反映し、名前の占有を防ぐのに役立ちます。 + +手数料は登録または更新時に支払う必要があり、返金されません。 +ネームスペース作成手数料を集めるネットワークアカウントである _シンクアカウント_ に送られます。 +[メインネット](default:メインネット) のブロック3,481,580以降、ネットワークはシンクアカウントからのトランザクションを拒否します。 +その結果、集められた手数料は実質的にバーンされます。 + +!!! note "トランザクション手数料とレンタル手数料" + どの種類のネームスペースを登録または更新する場合も、トランザクションをアナウンスする必要があり、別途トランザクション手数料がかかります。 + ただし、このトランザクション手数料は通常、レンタル手数料と比べてわずかです。 + +## 所有権 {: #ownership } + +ネームスペースは、ルートネームスペースを登録したアカウントが制御します。 + +所有者だけが次の操作を行えます。 + +* ネームスペースの下にモザイクを定義する。 +* サブネームスペースを作成する。 +* ルートネームスペースを更新する。 + +ネームスペースの所有権を直接移転することはできません。 +代わりに、たとえば [マルチシグアカウント](default:マルチシグアカウント) を使って所有者アカウントを引き渡すことで制御を移転します。 + +サブネームスペースは常にルートと同じ所有者を共有し、個別には管理できません。 + +## まとめ {: #summary } + +次の表は、ネームスペースに関する主な数値制限をまとめたものです。 + +| 制限 | 値 | 注記 | +| ------------------------------------------- | ---------------------- | -------------------------------------------------- | +| ネームスペース階層の最大深度 | 3レベル | ルート + 最大2個のサブネームスペース | +| ルートネームスペース名の最大長 | 16文字 | | +| サブネームスペース名の最大長 | 64文字 | 各階層に個別に適用 | +| ネームスペース名で使用できる文字 | `a–z`、`0–9`、`-`、`_` | 英字または数字で始める必要があります | +| ルートネームスペースの標準期間 | 525600ブロック | メインネットで約1年 | +| 有効期限後のネームスペース猶予期間 | 43200ブロック | メインネットで約30日 | diff --git a/mkdocs/pages/ja/textbook/nodes.md b/mkdocs/pages/ja/textbook/nodes.md new file mode 100644 index 000000000..f9f3d0dd7 --- /dev/null +++ b/mkdocs/pages/ja/textbook/nodes.md @@ -0,0 +1,208 @@ +# ノード + +ノード +: NEM ソフトウェアを実行し、ピアノードと情報を共有し、受信した [トランザクション](default:トランザクション) を検証し、[コンセンサス](default:コンセンサス) とブロック作成に参加するコンピューターです。 + +ノードはブロックチェーンの中核を成し、十分な数のノードがアクティブである限りネットワークが機能し続けるようにします。 + +誰でも NEM ノードを実行できます。 +オペレーターは、自分のアカウントでブロックを [ハーベスト](default:ハーベスティング) したり、他の人の [委任ハーベスティング](default:委任ハーベスティング) をホストしたり、[スーパーノードプログラム](default:スーパーノードプログラム) の資格を得たりするために実行します。 + +## ノード構造 {: #node-structure } + +すべての NEM ノードは、_NIS_ と呼ばれる同じアプリケーションを実行します。 + +NIS +: NEM Infrastructure Server です。 + ノードのすべての機能を実装する単一の Java プロセスです。 + +NIS は、[エンジン](#engine)、[REST API](#rest-api)、[WebSocket](#websocket) サービス、組み込み [データベース](#database) の4つのパーツで構成されています。 +エンジンは REST API と WebSocket サービスを通じて公開される中核で、データベースはブロックチェーンを保存します。 + +NIS は他のノードやクライアントとデータを交換します。 + +* _他のノード_ はネットワーク上の NIS ピアです。 +* _クライアント_ はウォレット、エクスプローラー、アプリケーションなどの外部プログラムです。 + +```dot +digraph NemNode { + layout=neato; + splines=ortho; + node [shape=box]; + edge [penwidth=1.5 dir=both]; + + // Layer labels + LblExt [label="外部" shape=plain pos="-1.7,6!"]; + LblInt [label="インターフェース" shape=plain pos="-1.7,4!"]; + LblProc [label="処理" shape=plain pos="-1.7,2!"]; + LblStor [label="ストレージ" shape=plain pos="-1.7,0!"]; + + // External actors + OtherNodes [label="他のノード" style=dashed fixedsize=true width=2 height=0.8 pos="1,6!"]; + Clients [label="クライアント" style=dashed fixedsize=true width=2 height=0.8 pos="5,6!"]; + + subgraph cluster_nis { + label=""; + style="rounded,dashed"; + + // Core components + REST [label="REST API" style=filled fixedsize=true width=2 height=0.8 pos="1,4!" URL="#rest-api"]; + WebSocket [label="WebSocket" style=filled fixedsize=true width=2 height=0.8 pos="5,4!" URL="#websocket"]; + Engine [label="エンジン" style=filled fixedsize=true width=6 height=0.9 pos="3,2!" URL="#engine"]; + H2 [label="ブロック（H2）" style=filled shape=cylinder fixedsize=true width=2.6 height=0.95 pos="3,0!" URL="#database"]; + NISLabel [label="NIS" shape=plain pos="3,-1.1!"]; + + // Invisible spacers so the NIS box fully encloses REST and WebSocket + spcL [shape=point style=invis pos="-0.3,4.85!"]; + spcR [shape=point style=invis pos="6.3,4.85!"]; + } + + // Midpoint waypoints pin the three Engine arrows to straight verticals, + // so the labels beside them cannot deflect the arrows off-centre + pR [shape=point width=0.01 style=invis pos="1,3.0!"]; + pW [shape=point width=0.01 style=invis pos="5,3.0!"]; + pB [shape=point width=0.01 style=invis pos="3,1.0!"]; + + // Waypoints for the squared Clients <-> REST route + cw1 [shape=point width=0 style=invis pos="3,4!"]; + cw2 [shape=point width=0 style=invis pos="3,6!"]; + + // Labels sit right beside their arrows + reqLbl [label="リクエスト" shape=plain pos="1.6,3.0!"]; + evtLbl [label="イベント" shape=plain pos="4.5,3.0!"]; + rwLbl [label="読み取り / 書き込み" shape=plain pos="4,1.0!"]; + + // External connections + OtherNodes -> REST; + Clients -> WebSocket; + + // Internal connections, pinned straight through the waypoints + REST -> pR [dir=back headclip=false]; + pR -> Engine [dir=forward tailclip=false]; + WebSocket -> pW [dir=back headclip=false]; + pW -> Engine [dir=none tailclip=false]; + Engine -> pB [dir=back headclip=false]; + pB -> H2 [dir=forward tailclip=false]; + + // Clients reach the REST API too: out of REST's right side, into the left of Clients + REST:e -> cw1 [dir=back]; + cw1 -> cw2 [dir=none]; + cw2 -> Clients:w [dir=forward]; +} +``` + +### エンジン {: #engine } + +エンジンはブロックチェーンの処理を行います。受信データを検証し、[コンセンサス](default:コンセンサス) と [ハーベスティング](default:ハーベスティング) を実行し、[ピアツーピア通信](#peer-to-peer-communication) を処理し、[未承認トランザクションプール](default:未承認トランザクションプール) を維持します。 + +エンジンは内部コンポーネントであり、直接は公開されません。 +ピアまたはクライアントからのすべての受信リクエストは、下記の REST API を通り、エンジンへ渡されます。 + +### REST API {: #rest-api } + +ピアとクライアントは、単一の HTTP API を通じて NIS にアクセスします。 + +* _ピアリクエスト_ は、ブロック同期、トランザクション中継、ノード検出を処理します。 +* _クライアントリクエスト_ は、ブロックチェーンデータの読み取りと [トランザクション](default:トランザクション) の送信を処理します。 + +API は、JSON とバイナリの2つのエンコードをサポートします。リクエストのコンテンツタイプで選択できます。 +ピアはバイナリでデータを交換し、クライアントは通常 JSON を使います。 + +### WebSocket {: #websocket } + +NIS は組み込みの [WebSocket](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) サービスを通じて、ブロックとトランザクションのイベントを公開します。 +購読したクライアントはポーリングせずにリアルタイムで通知を受け取ります。 + +### データベース {: #database } + +NIS は [H2](https://www.h2database.com) リレーショナルデータベースにブロックチェーンを保存します。_組み込み_ とは、別のデータベースサーバーではなく NIS プロセス内で実行されるという意味です。 + +データベースが保持するのはチェーンの全てのブロックとその中に含まれるトランザクションのみです。 +アカウント残高や [インポータンス](default:インポータンス) スコアなど、現在のブロックチェーン状態は保存しません。 +NIS はその状態をメモリに保持し、起動時に [ネメシスブロック](default:ネメシスブロック) からチェーンを再生して再構築します。そのため、ノードは起動後しばらく利用できません。 + +## ピアツーピア通信 {: #peer-to-peer-communication } + +NEM ノードは分散型のピアツーピア方式で相互に直接通信します。 +中央のコーディネーターはなく、各ノードが他のノードの一部と接続を確立して分散ネットワークを形成します。 + +ノードは既知のピア一覧を共有するため、新しく接続したノードは他のノードを素早く検出してネットワークに統合できます。 +このプロセスは強固な接続性を確保し、個々のノードがオフラインになってもネットワークの回復力を保ちます。 + +```dot +graph P2PNetwork { + layout=circo; + mindist=0.5; + node [style=filled]; + edge [dir=both len=1]; + + N1 [label="ノード1"]; + N2 [label="ノード2"]; + N3 [label="ノード3"]; + N4 [label="ノード4"]; + N5 [label="ノード5"]; + N6 [label="ノード6"]; + N7 [label="ノード7"]; + N8 [label="ノード8"]; + + // Random peer-to-peer connections + N1 -- N2 -- N3 -- N4 -- N5 -- N6 -- N7 -- N8; + N1 -- N5; + N2 -- N6; + N4 -- N1; + N8 -- N3; +} +``` + +ブートストラップを容易にするため、_事前信頼済み_ ピアの初期一覧が [NIS](default:NIS) に組み込まれています。 +これにより、新しいノードは最初の接続を行い、他のノードの検出を始められます。 + +### ノードの評判 {: #node-reputation } + +NEM のような分散型ネットワークでは、ノードはどのピアを信頼し接続を維持するかを決める必要があります。 +静的なホワイトリストや手動で管理した接続に頼る代わりに、NEM ノードは _評判_ システムを使い、時間経過に伴う観測動作に基づいてピアを動的に評価し順位付けします。 + +各ノードは、通信の成功、応答時間、受信データの有効性などの指標を使って、独立して評判を計算します。 +正しく動作し一貫して応答するノードには高いスコアが与えられます。 +無効なデータを送る、応答しない、その他の不正動作をするノードは、ペナルティまたは一時的なブラックリスト登録の対象になります。 + +新しい接続を確立する必要がある場合、ノードは利用可能なピアから、過去のやり取りに基づく評判の高いピアを優先して選択します。 + +組み込みの事前信頼済みピアはこの選択で重く評価されるため、他のピアより頻繁に選ばれ、ネットワークの信頼できる基点として機能します。 +ただし、その動作は他のピアと同じように評価されるため、不正動作をする事前信頼済みピアは評判を失います。 + +評判スコアはローカルです。 +各ノードは直接的な経験だけからネットワークの独自の評価を作り、その評価をメモリだけに保持します。 +再起動後、ノードは獲得した評判を保持せず、新たな相互作用から再構築します。 + +実装は [EigenTrust++](https://en.wikipedia.org/wiki/EigenTrust) アルゴリズムに基づきます。 + +### ノードのローテーション {: #node-rotation } + +孤立したノードグループや停滞したノードグループの形成を防ぐため、ノードは常に同じピアと通信するわけではありません。 +通信するピアを選ぶたびに、評判で重み付けしたランダムな抽出を行います。 +スコアの高いピアほど選ばれやすくなりますが、選択は確率的なままです。 + +このランダム性により、ノードは異なるピアを循環し、ネットワークの分断を避け、長期的な分散化を促進します。 + +## スーパーノード {: #supernodes } + +スーパーノードは _スーパーノードプログラム_ に登録されたノードです。 + +スーパーノードプログラム +: 信頼できる公開ノードに報酬を与える、チェーン外のコミュニティ資金によるプログラムです。 + +NEM にはブロック報酬もインフレーションもありません。 +ノードへの報酬はトランザクション手数料からのみ支払われ、取引量が少ない時期にはその金額が少なくなってしまうことがあります。 +スーパーノードプログラムは、信頼性が証明されたノードに毎日の報酬を支払うことでこれを補います。 + +!!! warning "スーパーノードの報酬は保証されません" + 報酬額はいつでも減額または廃止される可能性があります。 + +プログラムは完全にチェーン外で実行され、NIS 自体は関与しません。_コントローラー_ と呼ばれる別の中央運営サービスが参加ノードをテストし、報酬を支払います。 + +ノードは、最低限の [XEM](default:XEM) 残高を保有し、同期済みで最新状態にあり、他のピアから到達可能であることを確認する自動チェックに合格すると、その日の報酬資格を得ます。 +これらのチェックは、オンラインであるだけでなく、ネットワークの信頼性を高めるノードに報酬を与えることを目的としています。 + +登録は任意です。 +運用の詳細については、 [スーパーノードプログラムガイド](../userbook/node/supernode-program.md) を参照してください。 diff --git a/mkdocs/pages/ja/textbook/transactions.md b/mkdocs/pages/ja/textbook/transactions.md new file mode 100644 index 000000000..f2ccf81c6 --- /dev/null +++ b/mkdocs/pages/ja/textbook/transactions.md @@ -0,0 +1,292 @@ +# トランザクション + +トランザクション +: トランザクションは、ある [アカウント](default:アカウント) から別のアカウントへの資金移動や、新しいモザイクの登録など、NEM ブロックチェーン上で実行する操作を表します。 + +これらの操作は署名済みメッセージで表現され、ネットワークにアナウンスされます。 +ネットワーク内の [ノード](default:ノード) はそれを検証し、受け入れた場合はトランザクションをブロックに含め、ブロックチェーンの状態を更新します。 + +## 基本的なトランザクションの種類 {: #fundamental-transaction-types } + +NEM は、基本トランザクションとマルチシグトランザクションという2つの中核的なトランザクション種類をサポートします。 + +```dot +digraph "Fundamental Transaction Types" { + node [fontsize=12]; + Transaction [label="トランザクション"]; + Basic [label="基本" URL="#basic-transactions"]; + Multisig [label="マルチシグ" URL="#multisig-transactions"]; + + Transaction -> Basic; + Transaction -> Multisig; +} +``` + +### 基本トランザクション {: #basic-transactions } + +基本トランザクション +: 基本 [トランザクション](default:トランザクション) は、単一のアカウントが開始する単一の操作を表し、そのアカウントの [署名](default:署名) だけを必要とします。 + +アカウントからの資金移動や新しい [ネームスペース](default:ネームスペース) の登録などが例です。 + +### マルチシグトランザクション {: #multisig-transactions } + +マルチシグトランザクション +: マルチシグトランザクションは、[マルチシグアカウント](default:マルチシグアカウント) に代わって発行された単一の [内部トランザクション](default:内部トランザクション) を包み、ブロックに含める前に設定された人数の連署人の署名を必要とします。 + +マルチシグトランザクションは1人の連署人が開始しますが、有効にするには他の連署人から追加の署名が必要です。 + +連署 +: トランザクションが複数アカウントの署名を必要とする場合、その追加署名を _連署_ と呼びます。 + +NEM では、各連署は _マルチシグ連署_ トランザクションとして個別に送られ、ハッシュによって [内部トランザクション](default:内部トランザクション) を参照します。 +これにより、連署人は独立して異なるタイミングで署名できます。 +そのため、複数の連携した操作は別々のマルチシグトランザクションとして、内部トランザクションごとに1つずつ発行する必要があります。 + +これらの連署は [未承認トランザクションプール](default:未承認トランザクションプール) 内の保留中のマルチシグトランザクションに蓄積され、必要なしきい値を満たすだけの連署を集めた後にだけブロックに取り込まれることができます。 +マルチシグトランザクションと連署は、単一の単位としてアトミックにまとめて承認されます。 + +マルチシグトランザクションがブロックに含まれると、マルチシグアカウントがトランザクションに関係するすべての手数料を支払います。内部トランザクションの手数料、マルチシグトランザクションの手数料、各連署の手数料です。 +連署人は連署時に自分の残高を使いません。 + +!!! tip "マルチシグトランザクションの例" + + 金庫アカウント `T` は、連署人 `C1`、`C2`、`C3` が管理する 2-of-3 マルチシグです。 + 供給業者 `S` に支払うため、`C1` は `T` から `S` への転送を包むマルチシグトランザクションをアナウンスします。 + `C2` が連署を送信すると、2-of-3 のしきい値を満たします。 + `C3` は署名する必要がありません。 + しきい値に達すると転送が実行され、`S` が資金を受け取ります。 + + ```dot + digraph { + rankdir="LR"; + fontsize=12; + compound=true; + node [fontsize=12]; + + C1 [label="C1"]; + C2 [label="C2"]; + C3 [label="C3"]; + + subgraph clusterMultisig { + label = "マルチシグトランザクション"; + fontsize = 12; + style = dashed; + T [label="T\nマルチシグアカウント\n2 of 3"]; + S [label="S"]; + T -> S [label="転送"]; + } + + C1 -> T [label="署名" lhead=clusterMultisig minlen=2 labelfloat=true]; + C2 -> T [label="連署" lhead=clusterMultisig minlen=2 labelfloat=true]; + C3 -> T [style=dashed lhead=clusterMultisig minlen=2]; + } + ``` + +### 内部トランザクション {: #inner-transactions } + +内部トランザクション +: [マルチシグトランザクション](default:マルチシグトランザクション) に包まれた [基本トランザクション](default:基本トランザクション) を _内部トランザクション_ と呼びます。 + +内部トランザクションは、次の違いを除いて基本トランザクションと同じように動作します。 + +* 個別には署名されません。 + マルチシグトランザクションには開始した連署人が署名し、追加の連署人は別のマルチシグ連署トランザクションを通じて承認します。 + +* それ自体をマルチシグトランザクションにすることはできません。 + マルチシグ階層は1層だけです。 + +* 独自の手数料と期限フィールドを保持します。 + 内部トランザクションの手数料は、マルチシグトランザクションの手数料および各連署の手数料とともにマルチシグアカウントに請求されます。 + +## トランザクションのライフサイクル {: #transaction-lifecycle } + +NEM の各トランザクションは、クライアントによる作成からネットワークによる承認まで、6つの段階を進みます。 + +```dot +digraph "Transaction Lifecycle" { + node [shape=box, style=rounded, fontsize=12, margin="0.2,0.1"]; + edge [fontsize=12]; + nodesep=0.3; + ranksep=0.3; + + Creation [label="1. トランザクションを作成して署名", URL="#1-creation-and-signature"]; + Announcement [label="2. トランザクションをノードにアナウンス", URL="#2-announcement"]; + Validation [label="3. 有効か？", shape=diamond, style="", URL="#3-validation"]; + Propagation [label="4. 他のノードへ伝播", URL="#4-propagation"]; + Harvesting [label="5. ブロックに含める", URL="#5-harvesting"]; + Confirmation [label="6. 承認済みか？", shape=diamond, style="", URL="#6-confirmation"]; + Confirmed [label="承認済み"]; + + Rejection1 [label="拒否" style="rounded,dashed"]; + Rejection2 [label="拒否" style="rounded,dashed"]; + + Creation -> Announcement; + Announcement -> Validation; + Validation -> Propagation [label=" はい", labelfloat=true]; + Propagation -> Harvesting; + Harvesting -> Confirmation; + Confirmation -> Confirmed [label=" はい", labelfloat=true]; + + Validation -> Rejection1 [label="いいえ", style=dashed, minlen=2]; + Confirmation -> Rejection2 [label="いいえ", style=dashed, minlen=2]; + + { rank = same; Validation; Rejection1 } + { rank = same; Confirmation; Rejection2 } +} +``` + +### 1. 作成と署名 {: #1-creation-and-signature } + +通常はアプリであるソフトウェアクライアントがトランザクションを作成し、すべてのパラメーターを入力します。 +たとえば、転送トランザクションには送信元 [アカウント](default:アカウント)、宛先アカウント、金額が必要です。 + +この段階でトランザクションへの署名も行います。 +アカウントの [秘密鍵](default:秘密鍵) の保有者だけが有効な署名を生成できるため、署名は署名アカウントがトランザクションを承認したことを証明します。 + +マルチシグトランザクションでは、開始する連署人が内部トランザクションを包むマルチシグトランザクションに署名します。 +他の連署人は、マルチシグ連署トランザクションを通じて別々に連署を提供します。 + +### 2. アナウンス {: #2-announcement } + +クライアントアプリケーションは、ネットワーク上で接続された [ノード](default:ノード) にトランザクションを送信します。 + +マルチシグトランザクションの場合、連署は別のマルチシグ連署トランザクションとしてアナウンスされ、それぞれの署名者が独立して送信します。 + +### 3. 検証 {: #3-validation } + +ノードはトランザクションの形式が正しく、有効な署名を含むことを確認します。 +マルチシグトランザクションでは、参照された連署がマルチシグアカウントの有効な連署人によるものかどうかも検証します。 + +一部のトランザクション種類には追加の意味検証が必要です。 +たとえば転送トランザクションでは、送信元アカウントに十分な資金があることを確認します。 + +どれかの確認に失敗すると、トランザクションは拒否され、それ以上伝播されません。 +すべての確認に合格すると、処理が続きます。 + +### 4. 伝播 {: #4-propagation } + +ノードがトランザクションを有効と判断すると、ネットワーク内の他のピア [ノード](default:ノード) にブロードキャストし、各ノードの _未承認トランザクションプール_ に追加します。 + +未承認トランザクションプール +: ブロックに含まれるのを待つ検証済みトランザクションの一覧で、ネットワーク内の各ノードが保持します。 + +伝播されたトランザクションをピアが受信すると、他のノードの検証を信頼しないため、自分のプールに追加する前に完全な検証を再実行します。 +トランザクションが検証に合格すれば、ピアは自分のピアへ転送し、伝播がネットワーク全体に広がるまで続きます。 + +!!! warning "未承認トランザクションを信頼しないでください" + + 未承認トランザクションプール内のトランザクションは、まだブロックに含まれる保証がありません。 + [承認済み](#6-confirmation) になり、理想的には [書き換え制限](default:書き換え制限) を超えるまで、最終状態として扱わないでください。 + +マルチシグトランザクションの場合、マルチシグトランザクションと付随するマルチシグ連署トランザクションは独立して伝播します。 + +### 5. ハーベスティング {: #5-harvesting } + +未承認トランザクションプールに入ったトランザクションは、[ハーベスティング](default:ハーベスティング) プロセスによってブロックに含められますが、含まれることは保証されません。 +期限が切れるか、競合するトランザクションが先に承認されると、トランザクションは破棄されます。 + +マルチシグトランザクションの場合、ハーベスターは、マルチシグアカウントの署名しきい値を満たす数の連署が集まるまで、トランザクションをブロックに含めません。 +先に期限が切れると、マルチシグトランザクションと蓄積された連署はプールから破棄されます。 + +### 6. 承認 {: #6-confirmation } + +新しく作成されたブロックは他のノードに伝播され、検証後に受け入れまたは拒否されます。 +[コンセンサス](default:コンセンサス) メカニズムにより、ネットワーク上のすべてのノードが最終的に同じブロックに合意します。 +トランザクションを含むブロックがコンセンサスによって受け入れられると、そのトランザクションは _承認済み_ となります。 + +ノードがすでに受け入れたブロックが後にネットワークの大多数から拒否され、[ロールバック](default:ロールバック) されることがあります。 +この場合、ブロックのトランザクションは元に戻され、未承認トランザクションプールに戻されます。 + +NEM は、ロールバックがどこまで遡れるかを [書き換え制限](default:書き換え制限) で制限します。 + +トランザクションが未承認トランザクションプールにある間に期限切れになると、プールから破棄されます。 +たとえば、提示されたトランザクション手数料が低すぎて、どのハーベスターにも含められない場合に起こります。 + +## 共通トランザクション構造 {: #common-transaction-structure } + +NEM のすべてのトランザクション種類には、次の共通属性があります。 + +| 属性 | 説明 | +| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **署名者公開鍵** | トランザクションを作成して署名したアカウントの公開鍵。 | +| **署名** | 署名者がトランザクションとその内容を承認したことを示す暗号学的証明。 | +| **タイムスタンプ** | トランザクションが作成された時刻。[ネットワーク時刻](default:ネットワーク時刻) で表します。正確な作成時刻の記録というより、主に期限の起点として機能します。 | +| **期限** | 承認されなかった場合にトランザクションが失効することを示すタイムスタンプ。タイムスタンプから24時間以内です。 | +| **手数料** | トランザクションをブロックに含めるために署名者が支払う手数料。 | +| **タイプ** | トランザクションの種類。存在する追加属性を決定します。 | + +## 検証の詳細 {: #validation-details } + +トランザクションをブロックに含める前に、各ノードは次の確認を独立して行います。 + +| **確認** | **説明** | +| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | +| **署名確認** | 署名が有効で、署名者の公開鍵とトランザクションの内容に一致することを確認します。 | +| **手数料確認** | 手数料がネットワークの最小値を満たし、署名者が支払うのに十分な XEM を持つことを確認します。 | +| **期限確認** | 期限がすでに過ぎている場合はトランザクションを破棄します。 | +| **タイムスタンプ確認** | クロック操作を防ぐため、タイムスタンプが未来に離れすぎたトランザクションを拒否します。 | +| **ネットワーク確認** | 異なるネットワークを対象とするトランザクションを拒否します。たとえば、メインネットに送られたテストネットトランザクションです。 | +| **一意性確認** | ハッシュが最近のチェーン履歴にすでに現れるトランザクションを拒否し、リプレイを防ぎます。 | +| **意味確認** | 種類に基づいてトランザクションが論理的に正しいことを検証します。例として、送信者の資金が不足している場合、転送トランザクションは失敗します。 | + +これらの確認のいずれかに失敗したトランザクションは拒否され、それ以上伝播されません。 + +## サポートされるトランザクションの種類 {: #supported-transaction-types } + +NEM は、特定の種類の操作に合わせた次のトランザクション種類をサポートします。 +すべてのトランザクション種類は同じ [共通構造](#common-transaction-structure) を共有し、同じ処理と検証手順に従いますが、目的と必要なフィールドが異なります。 + +
+ +| **トランザクションの種類** | **説明** | +| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | +| **[転送トランザクション](default:転送トランザクション)** | | +| `Transfer` | 2つの [アカウント](default:アカウント) 間で XEM または [モザイク](default:モザイク) と任意のメッセージを送る。 | +| **[ハーベスティング](default:ハーベスティング)** | | +| `Account Key Link` | リモートアカウントをリンクして、委任ハーベスティングを有効化または無効化する。 | +| **[マルチシグ](default:マルチシグアカウント)** | | +| `Multisig Account Modification` | マルチシグアカウントを作成し、連署人を追加または削除し、必要な署名の最小数を変更する。 | +| `Multisig Cosignature` | 保留中のマルチシグトランザクションに連署を提供する。 | +| `Multisig` | マルチシグアカウントに代わって発行された内部トランザクションを包む。 | +| **[ネームスペース](default:ネームスペース)** | | +| `Namespace Registration` | ネームスペースを登録または更新する。 | +| **[モザイク](default:モザイク)** | | +| `Mosaic Definition` | 新しいモザイクを作成する。 | +| `Mosaic Supply Change` | モザイクの総供給量を変更する。 | + +
+ +## トランザクション手数料 {: #transaction-fees } + +すべてのトランザクションは、ブロックに含める [ハーベスターアカウント](default:ハーベスターアカウント) に報酬を与える手数料を支払います。 + +NEM の手数料は市場によって決まりません。 +ネットワークが固定スケジュールを公開しているため、ノードに接続しなくてもトランザクションのコストを事前に計算できます。 + +### 手数料スケジュール {: #fee-schedule } + +現在のスケジュールは次のとおりです。 + +| トランザクション | コスト | 注記 | +| --------------------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------| +| `Transfer` | 0.05 XEM から | XEM 金額、付加モザイク、メッセージ長によって異なります。[手数料](./transfer_transactions.md#fees) を参照してください。 | +| `Account Key Link` | 0.15 XEM | | +| `Multisig Account Modification` | 0.5 XEM | マルチシグアカウントが支払います（通常のアカウントをマルチシグに変換する場合は、そのアカウントが支払います）。 | +| `Multisig Cosignature` | 0.15 XEM | 連署人ではなく、マルチシグアカウントが支払います。 | +| `Multisig`（ラッパー） | 0.15 XEM | 内部トランザクションの手数料に加えて、マルチシグアカウントが支払います。 | +| `Namespace Registration` | 0.15 XEM | ネットワークのシンクアドレスに支払う [レンタル手数料](./namespaces.md#lease-fee) が加算されます。 | +| `Mosaic Definition` | 0.15 XEM | ネットワークのシンクアドレスに支払う [作成手数料](./mosaics.md#creation-fee) が加算されます。 | +| `Mosaic Supply Change` | 0.15 XEM | | + +### 下限と入札 {: #floor-and-bidding } + +スケジュールの金額は最小値です。 +手数料が最小値を下回るトランザクションは、検証者に拒否されます。 + +最小値を超える手数料は受け入れられ、含まれる可能性が高くなります。 + +* ハーベスターがブロックを作成するとき、手数料の高い順にトランザクションを選びます。 +* ネットワークが混雑している間、ノードのスパムフィルターは署名者の [インポータンス](default:インポータンス) と小さな手数料ボーナスの組み合わせで保留中のトランザクションを順位付けします。そのため、手数料の高いトランザクションほど [未承認トランザクションプール](default:未承認トランザクションプール) に入りやすくなります。 + +`Multisig Cosignature` の手数料にはさらに 1'000 XEM の上限があります。これは、1人の連署人が極端な手数料を入札してマルチシグアカウントを枯渇させることを防ぎます。 diff --git a/mkdocs/pages/ja/textbook/transfer_transactions.md b/mkdocs/pages/ja/textbook/transfer_transactions.md new file mode 100644 index 000000000..7392c42fa --- /dev/null +++ b/mkdocs/pages/ja/textbook/transfer_transactions.md @@ -0,0 +1,210 @@ +# 転送トランザクション + +転送トランザクション +: あるアカウントから別のアカウントへ [XEM](default:XEM)、[モザイク](default:モザイク)、任意のメッセージを送る [トランザクション](default:トランザクション) です。 + +転送トランザクションは NEM で最も一般的なトランザクションで、資産の転送と簡単な通信の両方を可能にします。 + +## 主な特徴 {: #key-features } + +* **モザイクの転送** + + 転送トランザクションには1つ以上のモザイクを付加できます。 + 転送トランザクション内のすべてのモザイクは、1人の送信者から1人の受信者へ送られます。 + そのため、転送トランザクションは単純な直接の資産転送に適しています。 + +* **メッセージのサポート** + + 任意でプレーンテキストまたは暗号化メッセージを含められます。 + 転送トランザクションにモザイクは必須ではないため、メッセージだけを送ることもできます。 + これにより、モザイクの転送とともに簡単な通信ができます。 + +* **マルチシグ互換性** + + 他のすべてのトランザクションと同様、転送トランザクションは [マルチシグアカウント](default:マルチシグアカウント) をサポートします。 + これにより、複雑なガバナンス方式など、複数アカウントによる承認を必要にできます。 + +## 構造 {: #structure } + +[共通トランザクション構造](./transactions.md#common-transaction-structure) に加えて、転送トランザクションには次の属性が含まれます。 + +| 属性 | 説明 | +| --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | +| [**受取人のアドレス**](#recipients-address) | 受取アカウントのアドレス。 | +| [**XEM 金額**](#xem-amount) | モザイク一覧が空の場合は受取人に送る XEM、一覧が空でない場合は付加された各モザイクに適用する乗数。 | +| [**転送モザイク一覧**](#list-of-transferred-mosaics) | 転送する0個以上のモザイク。 | +| [**任意のメッセージ**](#optional-message) | 最大1024バイトのプレーンテキストまたは暗号化メッセージ。 | + +### 受取人のアドレス {: #recipients-address } + +受取人は [アドレス](default:アドレス) で指定します。 + +!!! warning "所有者のいないアドレスへ送った資産は失われます" + + これまでチェーン上に現れたことがないアドレスを含め、任意の有効なアドレスに XEM またはモザイクを送れます。 + そのアドレスに対応する [秘密鍵](default:秘密鍵) を誰も持っていなければ、転送された資産を回収できません。 + +### XEM 金額 {: #xem-amount } + +**XEM 金額** はマイクロ XEM で表し、`1 XEM = 1'000'000 micro-XEM` です。 +[モザイク一覧](#list-of-transferred-mosaics) に応じて、次の2つの目的で使われます。 + +* **転送金額** + モザイク一覧が空の場合、XEM 金額は受取人に送る XEM です。 +* **モザイク乗数** + モザイク一覧が空でない場合、XEM 金額自体は XEM を送りません。 + 代わりに、値を `1'000'000` で割って、付加された各モザイクの数量を拡大する **乗数** を得ます。 + 同じ乗数が一覧のすべてのモザイクに適用されます。 + + たとえば `2'000'000` は乗数 `2` になり、一覧内のすべてのモザイク数量を2倍にします。 + 一覧項目が500単位なら、受取人には `1'000` 単位が届きます。 + +!!! note "乗数のルール" + + XEM 金額が乗数として機能する場合は、次のルールがあります。 + + * 結果の乗数が整数になるよう、値は `1'000'000` で割り切れる必要があります。小数の金額は拒否されます。 + * ウォレットは慣例として `1'000'000` に設定し、各モザイク数量を指定どおり転送します。 + * 乗数 `0` は、モザイクを転送しない有効なトランザクションを生成します。 + +### 転送モザイク一覧 {: #list-of-transferred-mosaics } + +転送トランザクションには最大 **10個のモザイク** を含められます。 +一覧を空にすることもでき、その場合は資産を移動せずに送信者がメッセージを付加できます。 + +各項目にはモザイク ID と数量を指定します。 +数量はモザイクの **原子単位** で数える整数です。 + +モザイクの作成時に設定する `divisibility` プロパティは `0` から `6` の範囲で、1全体単位を構成する原子単位の数を定義します。 +たとえば XEM の可分性は `6` なので、1'000'000 原子単位が1 XEMです。 +全体単位と原子単位の変換については、[モザイク](./mosaics.md#divisibility) ページを参照してください。 + +一覧にあるどのモザイクについても、送信者が十分な単位を保有していなければネットワークはトランザクションを拒否します。 + +一覧にあるモザイクに [徴収手数料](default:徴収手数料（levy）) が設定されている場合、ネットワークは転送量に加えて送信者から徴収手数料を徴収し、その徴収手数料の受取人に入金します。 +[徴収手数料の請求方法](./mosaics.md#how-levies-are-charged) の規則を確認してください。 + +!!! tip "他のモザイクと一緒に XEM を送る" + + 他のモザイクと同じトランザクションで XEM を送るには、一覧に XEM を項目として含めます。 + 他のすべてのモザイクと同様に、XEM 金額の乗数によって数量が拡大されます。 + +### 任意のメッセージ {: #optional-message } + +転送トランザクションには、最大 **1024バイト** の任意のメッセージを含められます。 +付加モザイクがなく、XEM 金額が `0` の場合、転送にはメッセージだけが含まれます。 + +すべてのメッセージには `type` フィールドがあり、ペイロードがプレーンテキスト（`0x0001`）かセキュア（`0x0002`）かを識別します。 + +ノードは `type` フィールドと1024バイトのサイズ制限を強制します。 +ペイロードのバイト列は解釈しません。 +プロトコルはプレーンテキストのエンコード方式を定義せず、セキュアペイロードの暗号化方式も標準化しません。 +どちらも送信者と受信者が合意する規約です。 + +#### プレーンテキストの規約 {: #plaintext-conventions } + +プレーンテキストのペイロードはそのまま保存されます。 +送信者と受信者は UTF-8、JSON、16進数などの形式に合意します。 + +NEM のウォレットとアプリケーションは通常 UTF-8 を想定します。 + +#### セキュアメッセージの規約 {: #secure-message-conventions } + +セキュアペイロードは、受信者だけが復号できるよう暗号化されます。 +プロトコルは暗号化方式を標準化していません。 + +既存のウォレットと SDK では、共有鍵を楕円曲線ディフィー・ヘルマン（ECDH）で導出する **AES-CBC** と **AES-GCM** の2方式が広く使われています。 +各方式は1024バイトのペイロードの一部を暗号学的メタデータ用に確保し、AES-CBC では最大 **960バイト**、AES-GCM では **996バイト** のプレーンテキストを使用できます。 + +!!! warning "CBC と GCM は相互運用できません" + + ノードはペイロードを検査せず、同じ `0x0002` フラグの下で両方の方式を受け入れて保存します。 + 受信者がセキュアメッセージを復号できるのは、送信者と同じ方式をツールが実装している場合だけです。 + GCM ツールで作成されたメッセージは CBC だけに対応するツールでは復号できず、その逆も同様です。 + +## 手数料 {: #fees } + +転送トランザクションの手数料は送信内容によって異なります。 +次の2つの要素の合計です。 + +* **転送手数料**：XEM 金額または付加モザイクに基づきます。 +* **メッセージ手数料**：付加メッセージの長さに基づきます。 + +### 転送手数料 {: #transfer-fee } + +XEM だけを転送する場合、手数料は送信金額に応じて変わります。 + +| 送信金額 | コスト | +| ---------------------------- | --------- | +| 最大19'999 XEM | 0.05 XEM | +| 追加10'000 XEM ごと | +0.05 XEM | +| 250'000 XEM 以上 | 1.25 XEM | + +モザイクを転送する場合、手数料は付加された各モザイクの個別手数料の合計です。 +各モザイクは次のように価格付けされます。 + +* **少量で不可分なモザイク**（供給量 ≤ 10'000、可分性 0）は一律 **0.05 XEM** です。 +* **その他すべてのモザイク** は、転送数量とモザイク総供給量から導出した **XEM 換算価値** で価格付けされます。 + この価値は、XEM だけの転送に使う0.05〜1.25 XEMの手数料階層に、モザイク総供給量が少ないほど大きくなる **供給量割引** を適用して対応付けられます。 + +モザイクごとの最小手数料は **0.05 XEM** です。 + +??? info "モザイク手数料の計算" + + 少量でないモザイクの手数料計算は3段階です。転送数量の XEM 換算価値を計算し、その価値を手数料階層で調べて基本手数料を得てから、供給量割引を引きます。 + + **1. XEM 換算価値** + + \[ + \text{xem\_equivalent} = \frac{\text{8'999'999'999} \cdot \text{atomic\_quantity} \cdot \text{multiplier}}{\text{total\_atomic\_supply}} + \] + + ここで、 + + * $\text{8'999'999'999}$ は初期 XEM 供給量（全体単位）です。 + * $\text{atomic\_quantity}$ は転送するモザイク量（原子単位）です。 + * $\text{multiplier}$ は [XEM 金額の乗数](#xem-amount) です（通常は1）。 + * $\text{total\_atomic\_supply}$ はモザイクの総供給量（原子単位）です：$\text{supply} \cdot 10^{\text{divisibility}}$。 + + **2. 基本手数料** + + 得られた価値は、XEM だけの転送と同じ0.05〜1.25 XEMの手数料階層で価格付けされ、モザイクの **基本手数料** になります。 + + **3. 供給量割引** + + 基本手数料から **供給量割引** を引きます。 + + \[ + \text{discount} = \left\lfloor 0.8 \cdot \ln \! \left( \frac{9 \cdot 10^{15}}{\text{total\_atomic\_supply}} \right) \right\rfloor \cdot 0.05 \text{ XEM} + \] + + ここで $9 \cdot 10^{15}$ は NEM が許可する最大モザイク数量です。 + + 供給量が少ないほど $\text{xem\_equivalent}$ は大きくなるため、割引がなければ供給量の少ないモザイクは小さな転送でも $1.25$ XEM の上限に達します。 + 割引は同じ供給量の対数でこれを相殺するため、希少なモザイクほど大きな補正を受けます。 + 割引が基本手数料を超えても、最終手数料が **0.05 XEM 未満になることはありません**。 + + **例** + + 供給量 $\text{1'000'000}$、可分性 `0` のモザイクで、乗数1で100単位を送る場合： + + 1. **XEM 換算値**：$\frac{\text{8'999'999'999} \cdot 100 \cdot 1}{\text{1'000'000}} = \text{899'999.9999}$。 + 2. **基本手数料**：上記の XEM だけのスケジュールでは、$\text{10'000}$ XEM の価値ごとに0.05 XEMが加算され、$\text{250'000}$ XEM以上では1.25 XEMが上限です。$\text{899'999.9999}$ は $\text{250'000}$ を超えるため、基本手数料は最大の1.25 XEMです。 + 3. **供給量割引**：$\left\lfloor 0.8 \cdot \ln \! \left( \frac{9 \cdot 10^{15}}{\text{1'000'000}} \right) \right\rfloor \cdot 0.05 = 0.90$ XEM。 + + **最終手数料**：$1.25 - 0.90 = 0.35$ XEM。 + +### メッセージ手数料 {: #message-fee } + +空でないメッセージには、基本0.05 XEMに加えて、1024バイトの最大値までペイロード32バイトごとに0.05 XEMがかかります。 + +| メッセージ長 | 追加コスト | +| ---------------------- | ---------- | +| メッセージなし | なし | +| 1〜31バイト | 0.05 XEM | +| 32〜63バイト | 0.10 XEM | +| 64〜95バイト | 0.15 XEM | +| … | … | +| 1024バイト（最大） | 1.65 XEM | + +手数料は保存されるペイロードサイズで計算されます。そのため [セキュアメッセージ](#secure-message-conventions) はプレーンテキストではなく暗号化済みペイロードに対して課金されます。