introduces a signing scheme where the signature covers the raw utf-8
bytes of a tx_json_str the client produced, rather than the classical
binary signing payload. clients need no codec library: dump json,
sign bytes, post.
protocol:
* new sfJsonTxBody VL field (notSigning) carrying the exact ascii bytes
* new featureJsonTx amendment gating the new sign path
* STTx::checkSign routes to jsonTx::checkSignature when the amendment
is active and the body is present
* passesLocalChecks runs jsonTx::checkStructuralEquivalence so the body
must parse to the same canonical fields as the tx itself
helper:
* include/xrpl/protocol/JsonTx.h -- hasBody / body / bodyHash
(sha512half over the body) / checkSignature / checkStructuralEquivalence
rpc:
* submit_json_tx handler: { tx_json_str, signature } -> verify ascii sig,
stuff body + sig into the tx, forceValidity(SigGoodOnly), route through
the normal processTransaction flow. gated on featureJsonTx.
tests:
* ripple.app.JsonTx: feature gate, basic roundtrip, invalid params,
invalid json, bad signature, sig-over-different-bytes, wrong pubkey,
helper unit tests including structural-equivalence tamper case.
protocol
Classes and functions for handling data and values associated with the XRP Ledger protocol.
Serialized Objects
Objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format.
The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.
Optional Fields
Our serialized fields have some "type magic" to make optional fields easier to read:
- The operation
x[sfFoo]means "return the value of 'Foo' if it exists, or the default value if it doesn't." - The operation
x[~sfFoo]means "return the value of 'Foo' if it exists, or nothing if it doesn't." This usage of the tilde/bitwise NOT operator is not standard outside of therippledcodebase.- As a consequence of this,
x[~sfFoo] = y[~sfFoo]assigns the value of Foo from y to x, including omitting Foo from x if it doesn't exist in y.
- As a consequence of this,
Typically, for things that are guaranteed to exist, you use
x[sfFoo] and avoid having to deal with a container that may
or may not hold a value. For things not guaranteed to exist,
you use x[~sfFoo] because you want such a container. It
avoids having to look something up twice, once just to see if
it exists and a second time to get/set its value.
(Real example)
The source of this "type magic" is in SField.h.