QIP-008: Ephemeral message format proposal
| Author | Peter Waterland, Kaushal Singh |
|---|---|
| Discussions-To | https://github.com/theQRL/qips/pull/17 |
| Status | draft/incomplete |
| Layer | core |
| Created | 2019-04-24 |
Table of Contents
Abstract
To extend functionality of the QRL beyond the ledger an off-chain network messaging system known as ‘ephemeral’ is proposed. These lifespan-limited internode broadcast messages may be relayed and stored optionally by agreeable qrl-nodes.
A simple initial format with some DDOS protection is suggested, allowing custom implementations from users or applications wishing to interact with the QRL ledger/network.
Specification
A suggested message format is:
Ephemeral message | ID | PAYLOAD |TTL |BLOCKHASH | POW — | — | — | — | — | —
The ID field is a 64 byte identifier. It may be accessed as a complete ID field or two 32 byte separate identifiers (ID0 and ID1). The ID is intended to be a unique nonce.
The payload is the body of the message containing user data. The precise contents are left open but some example schemes will be suggested in a future QIP to enable powerful end-end encrypted data channels. Max field length = 8192 bytes.
TTL is a 32 bit network expiry timestamp following unix time specification. This ‘time to live’ value is a timestamp upon which the network renders the message invalid and proceeds with deletion. Whilst messages are relayed across the network by agreeable nodes they are only held transiently until they expire - hence ‘ephemeral’. Alternatively, this could be replaced with a blockheight?
The first 4 bytes of a recent QRL block-header hash must be supplied as a rough message timestamp. The chance of a random 4 byte guess being successful is allowed_ephemeral_message_blockdepth/2^32. In combination with POW this prevents a determined attacker grinding out a huge number of messages over a long period of time which are then used to flood the network.
POW. Any broadcast protocol is susceptible to spam and each message passed through the network will require a variable amount of ‘work’ to be performed and verified via a supplied pow hash prepended by a byte pow algorithm identifier. This adds a small amount of computation time to confirm message validity. Furthermore, the amount of work required is linked to the TTL expiry timestamp - the longer the shelf-life of the message, the greater work must be expended to attain validity. The pow is performed on a cryptographic hash digest of the message (SHA2_256(ID+PAYLOAD+TTL+BLOCKHASH)), with the resultant pow hash (and prepended byte) appended as the final field of the message.
Implementation
Activating ephemeral messaging requires minor changes to the qrl-node python and go implementations to relay and prioritise additional traffic. It is anticipated the vast majority of traffic will occur using open source public off-chain centralised message repositories.
New qrl-node configuration parameters for:
- ephemeral traffic relay flag (enable or disable)
- ephemeral traffic storage flag (enable or disable)
- maximum TTL timestamp from current timestamp accepted
- valid ephemeral message block depth limit (integer value from current blockheight)
- specific pow algorithm support flag
- proof of work variables for each algorithm in specification
- numerical value for minimum valid computed work per message prior to adjustment
- numerical factor applied based upon TTL timestamp
Furthermore, to allow encrypted data channels via ephemeral messages across the network, lattice tx featuring embedded Dilithium and Kyber pk’s must be activated. This requires a hard fork upgrade to all network nodes. Specific end-end data channel cryptographic implementations will be discussed in future QIPs.
Citation
Please cite this document as:
Peter Waterland, Kaushal Singh, "QIP-008: Ephemeral message format proposal," QRL Improvement Proposals, no. 8, April 2019. Available: https://www.theqrl.org/qips/QIP-008.