ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-27 15:15:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add NetworkID field docs

Browse Source
This commit is contained in:
mDuo13
2023-06-23 17:47:12 -07:00
parent 7113f7f45e
commit 6da2e99f5b
1 changed files with 22 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
content/references/protocol-reference/transactions/transaction-common-fields.md
View File

@@ -19,6 +19,7 @@ Every transaction has the same set of common fields, plus additional fields base
| [`Flags`](#flags-field) | Number | UInt32 | _(Optional)_ Set of bit-flags for this transaction. |
| `LastLedgerSequence` | Number | UInt32 | _(Optional; strongly recommended)_ Highest ledger index this transaction can appear in. Specifying this field places a strict upper limit on how long the transaction can wait to be validated or rejected. See [Reliable Transaction Submission](reliable-transaction-submission.html) for more details. |
| [`Memos`](#memos-field) | Array of Objects | Array | _(Optional)_ Additional arbitrary information used to identify this transaction. |
| [`NetworkID`](#networkid-field) | 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 sidechains whose network ID is 1025 or higher. |
| [`Signers`](#signers-field) | Array | Array | _(Optional)_ Array of objects that represent a [multi-signature](multi-signing.html) which authorizes this transaction. |
| `SourceTag` | Number | UInt32 | _(Optional)_ Arbitrary integer used to identify the reason for this payment, or a sender on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
| `SigningPubKey` | String | Blob | _(Automatically added when signing)_ Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. |
@@ -127,6 +128,27 @@ Example of a transaction with a Memos field:
}
```
## NetworkID Field
[New in: rippled 1.11.0][]
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-network.html) that it wasn't intended for. For compatibility with existing chains, the `NetworkID` field **MUST BE OMITTED** for any network with a Network ID of 1024 or less, but **MUST BE INCLUDED** for 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 |
| 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 Field