mirror of
https://github.com/XRPLF/rippled.git
synced 2025-11-20 02:55:50 +00:00
133 lines
4.4 KiB
Plaintext
133 lines
4.4 KiB
Plaintext
|
|
All signed or hashed objects must have well-defined binary formats at the
|
|
byte level. These formats do not have to be the same as the network wire
|
|
formats or the forms used for efficient storage or human display. However,
|
|
it must always be possible to precisely re-create, byte for byte, any signed
|
|
or hashed object. Otherwise, the signatures or hashes cannot be validated.
|
|
|
|
All 32-byte hashes are the first 32-bytes of a SHA512 hash. This is chosen
|
|
because SHA512 is 33% faster than SHA256 on modern hardware.
|
|
|
|
Note that it is not required the objects be stored or transmitted in these
|
|
formats. They are only required to be put in these formats when computing or
|
|
validating hashes or signatures.
|
|
|
|
Sadly, Google's protocol buffers are not suitable for the inner portions of
|
|
signed or hashed objects.
|
|
|
|
For signatures, the object is always prefixed with a 4-byte object type.
|
|
This prevents a malicious entity from presenting a signed object of one type
|
|
as an object of another type, for which the signature would be valid.
|
|
|
|
Note: Signed blocks that exceed the length in this specification should be
|
|
accepted and the extraneous information ignored. Nodes may opt to ignore
|
|
objects they consider abusively long (a 1KB transaction, for example).
|
|
|
|
1) Account ID
|
|
|
|
An account starts as an ECDSA public key (X,Y)
|
|
|
|
Form a 65-byte quantity consisting of a single byte with the value 4, the
|
|
32-byte X of the public key followed by the 32-byte Y of the public key.
|
|
Apply SHA256 to this 65-byte quantity. Apply RIPEMD160 to the result.
|
|
|
|
The resulting 20-byte value is the account ID.
|
|
|
|
|
|
|
|
2) Transaction (source/signed format)
|
|
|
|
Fields:
|
|
1) 64-byte source public key
|
|
2) 20-byte destination account
|
|
3) 8-byte amount, unsigned BE integer
|
|
4) 4-byte source account sequence number, unsigned BE integer
|
|
5) 4-byte source ledger index, unsigned BE integer
|
|
6) 4-byte arbitrary source tag, unsigned BE integer
|
|
7) Prefix 0x54584E00 signature of 104-byte contents of fields 1-6
|
|
|
|
|
|
3) Transaction (ledger format)
|
|
|
|
Fields:
|
|
1) Transaction in signed format
|
|
2) 8-byte fees held, unsigned BE integer
|
|
|
|
|
|
5) Ledger (signed format)
|
|
|
|
Fields:
|
|
1) 4-byte ledger index, unsigned BE integer
|
|
2) 8-byte fees held, unsigned BE integer
|
|
3) 32-byte hash of previous ledger
|
|
4) 32-byte hash of root of the transaction tree for this ledger
|
|
5) 32-byte hash of root of the account tree for this ledger
|
|
6) 8-byte timestamp
|
|
[remaining fields only in proposed ledger
|
|
7) 4-byte confidence, unsigned BE integer x/255
|
|
8) Signature:
|
|
Accepted: Prefix (0x4C475200) of 116 byte fields 1-6
|
|
Proposed: Prefix (0x4C475000) of 120 byte fields 1-8
|
|
|
|
|
|
6) Account status (ledger format)
|
|
|
|
Fields:
|
|
1) 20-byte Account ID
|
|
2) 8-byte account balance, unsigned BE integer
|
|
3) 4-byte account sequence, unsigned BE integer
|
|
|
|
|
|
|
|
7) Non-Leaf Tree Node
|
|
|
|
Contains 32 hashes, each 20-bytes. They correspond to hashes of the nodes
|
|
for the 32 possible values of the *first* 5 bits of the *next* byte of the
|
|
RIPEMD160 hash. By convention, an empty node has a hash of zero.
|
|
|
|
|
|
|
|
8) Leaf Node
|
|
|
|
Contains every item in this node, sorted in order of increasing raw binary
|
|
order. (Elements that start with a zero byte come first.) In practice, this
|
|
will be exactly one item. You'd need a quadrillion entries before two
|
|
wound up in the same leaf.
|
|
|
|
By convention, an empty leaf node has a hash of all zero bytes.
|
|
|
|
|
|
|
|
8) Contact block
|
|
|
|
These are used to pass node contact information around the network and are
|
|
signed so nodes can prove they are operational.
|
|
|
|
Fields:
|
|
1) 64-byte node public key
|
|
2) 4-byte software version
|
|
3) 4-byte minimum supported version
|
|
4) 8-byte node flags (to be defined)
|
|
5) 8-byte timestamp (seconds since 1/1/70)
|
|
6) Node Info Block
|
|
7) Prefixed (0x4E4F4400) signature of fields 1-6 above.
|
|
|
|
The node info block consists of one or more node info elements. Each element
|
|
consists of a 1-byte element type, a 3-byte element length, and the element
|
|
data. Four zero bytes marks the end of the node info block. The following
|
|
element types are defined:
|
|
|
|
0 = IPv4 Contact Information (4-byte address, 2-byte port)
|
|
1 = IPv6 Contact Information (16-byte address, 2-byte port)
|
|
2 = Node Name
|
|
3 = Organization Name
|
|
4 = Node Certificate
|
|
5 = URL
|
|
6 = Admin Email
|
|
7 = Node Policy URL
|
|
8 = Transitive Trust (20-byte node hanko, 1-byte trust type)
|
|
|
|
A node *must* ignore unknown element types. Fixed-length element types may
|
|
contain more than one value in a single element. For example, you can put
|
|
two IP/port combos in a single type 0 element of length 4+12.
|