Skip to content

Commit

Permalink
fix CTID links
Browse files Browse the repository at this point in the history
  • Loading branch information
mDuo13 committed Oct 24, 2023
1 parent 80ef0d6 commit 873c34d
Show file tree
Hide file tree
Showing 3 changed files with 29 additions and 5 deletions.
4 changes: 2 additions & 2 deletions content/@i18n/ja/concepts/transactions/transactions.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ _トランザクション(取引)_ は、XRP Ledgerを変更する唯一の
トランザクションで行えることは、送金だけではありません。XRP Ledgerのトランザクションは、さまざまな[支払いタイプ](payment-types.html)に対応しているだけでなく、[暗号鍵](cryptographic-keys.html)のローテーション、その他の設定の管理、およびXRP Ledgerの[分散型取引所](decentralized-exchange.html)での取引にも使用されます。[トランザクションタイプの詳細なリスト](transaction-types.html)については、[`rippled` APIリファレンス](http-websocket-apis.html)を参照してください。


### トランザクションの識別
### トランザクションの識別 <a id="identifying-transactions"></a>

署名付きトランザクションには、それを識別する固有の`"hash"`があります。トランザクションを送信すると、サーバーの応答でハッシュが返されます。[account_txコマンド](account_tx.html)を使用して、アカウントのトランザクション履歴でトランザクションを検索することもできます。

Expand Down Expand Up @@ -87,7 +87,7 @@ JSON形式の未署名の[Paymentトランザクション][]の例を次に示
}
```

XRP Ledgerは、トランザクションオブジェクトが送信元アドレス(`Account`内)フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。これを安全に行う方法については、[安全な署名の設定](secure-signing.html)を参照してください。
XRP Ledgerは、トランザクションオブジェクトが送信元アドレス(`Account`内)フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。これを安全に行う方法については、[安全な署名の設定](secure-signing.html)を参照してください。

## 署名付きトランザクションブロブの例

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@ labels:
| [AccountTxnID][] | 文字列 | Hash256 | _(省略可)_ 別のトランザクションを識別するためのハッシュ値。このハッシュがある場合、このトランザクションが有効になるのは、送信側のアカウントの直前送信トランザクションがこのハッシュと一致しているときのみです。 |
| [Flags][] | 符号なし整数 | UInt32 | _(省略可)_ このトランザクションのビットフラグのセット。 |
| LastLedgerSequence | 数値 | UInt32 | _(省略可。使用を強く推奨)_ このトランザクションを登録できるレジャーインデックスの最大値。このフィールドを指定することにより、トランザクションが検証または拒否されるのを待たなければならない期間の上限を設定することができます。詳細は、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。 |
| [`NetworkID`](#networkidフィールド) | Number | UInt32 | _(Network-specific)_ The network ID of the chain this transaction is intended for. **MUST BE OMITTED** for Mainnet and some test networks. **REQUIRED** on chains whose network ID is 1025 or higher. |
| [Memos][] | オブジェクトの配列 | 配列 | _(省略可)_ このトランザクションの識別に使用される任意の追加情報。 |
| [Signers][] | 配列 | 配列 | _(省略可)_ このトランザクションを承認するための[マルチシグ](multi-signing.html)を表すオブジェクトの配列。 |
| SourceTag | 符号なし整数 | UInt32 | _(省略可)_ この支払いの理由、またはこのトランザクションの実行元である送信者を識別するために使用される任意の整数。一般的に、返金については、最初の支払いの`SourceTag`を返金の`DestinationTag`として指定する必要があります。 |
Expand All @@ -42,8 +43,7 @@ labels:
AccountTxnIDを使用するには、アカウントの1つ前のトランザクションのIDがレジャーで追跡されるよう、最初に[asfAccountTxnID](accountset.html#accountsetのフラグ)フラグを設定する必要があります。


## 自動入力可能なフィールド
## Auto-fillable Fields {.invisible}
## 自動入力可能なフィールド <a id="auto-fillable-fields"></a>

一部のフィールドについては、トランザクションの署名前に、`rippled`サーバーによって、または署名に使用される[ripple-lib][]などのライブラリーによって値を自動入力できます。値を自動入力するには、最新の状態を取得するためのXRP Ledgerへのアクティブな接続が必要です。したがって、オフラインでは実行できません。[ripple-lib][]`rippled`のどちらも、以下の値を自動的に提供できます。

Expand Down Expand Up @@ -125,6 +125,30 @@ MemoTypeフィールドとMemoFormatフィールドには、以下の文字の
"Amount": "1"
}
```
## NetworkIDフィールド <a id="networkid-field"></a>
[新規: rippled 1.11.0][]

<!-- TODO: translate section -->

The `NetworkID` field is a protection against "cross-chain" transaction replay attacks, preventing the same transaction from being copied over and executing on a [parallel network](parallel-networks.html) that it wasn't intended for. For compatibility with existing chains, the `NetworkID` field must be omitted on any network with a Network ID of 1024 or less, but must be included on any network with a Network ID of 1025 or greater. The following table shows the status and values for various known networks:

| Network | ID | `NetworkID` Field |
|---------------|----|-------------------|
| Mainnet | 0 | Disallowed |
| Testnet | 1 | Disallowed |
| Devnet | 2 | Disallowed |
| AMM Devnet | 25 | Disallowed |
| Sidechains Devnet Locking Chain | 2551 | Disallowed, but will become required after an update |
| Sidechains Devnet Issuing Chain | 2552 | Disallowed, but will become required after an update |
| Hooks V3 Testnet | 21338 | Required |

Transaction replay attacks are theoretically possible, but require specific conditions on the second network. All of the following must be true:

- The transaction's sender is a funded account on the second network.
- The sender's `Sequence` number on the second network matches the transaction's `Sequence`, or the transaction uses a [Ticket](tickets.html) that's available on the second network.
- Either the transaction does not have a `LastLedgerSequence` field, or it specifies a value that is higher than the current ledger index on the second ledger.
- Mainnet generally has a higher ledger index than test networks or sidechains, so it is easier to replay Mainnet transactions on a sidechain or test network than the other way around, when transactions use `LastLedgerSequence` as intended.
- Either the networks both have IDs of 1024 or less, both networks use the same ID, or the second network does not require the `NetworkID` field.


## Signersフィールド
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ labels:

A Compact Transaction Identifier (CTID) is a unique identifier for a validated transaction that applies across any [network](parallel-networks.html), not just the XRP Ledger Mainnet.

The differences between a CTID and a transaction's [identifying hash](transactions.html#identifying-hash) are as follows:
The differences between a CTID and a transaction's [identifying hash](transactions.html#identifying-transactions) are as follows:

- A CTID identifies a validated transaction based on its network ID, ledger index, and position within the ledger. Since it specifies which network a transaction has been validated on, it can be used in contexts where you are interacting with more than one network, such as connecting to sidechains. A CTID is 64 bits, typically written as 16 characters of uppercase hexadecimal starting with `C`, for example `C005523E00000000`.
- An transaction's identifying hash identifies a signed transaction based on its contents, regardless of if that transaction has been validated on any chains. Since it's a cryptographic hash, it can also be used to prove that the transaction contents are intact. A transaction hash is 256 bits, typically written as 64 characters of hexadecimal, for example `E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7`.
Expand Down

0 comments on commit 873c34d

Please sign in to comment.