OVIP: 6
Title: Protocol messages cleanup
Author: Nika Gamkrelidze <[email protected]>
Discussions-To: https://community.openvasp.org/#narrow/stream/11-protocol-.2F.20messages/topic/data.20duplicates
Status: Superseded
Type: Standard
Created: 2020-14-05
Superseded-By: ovip-0014
The current specification of message protocol is designed to make each message of the session self-sufficient with regards to the details of the transaction. Each time new piece of data is gathered, it migrates to the next logical message. This has some advantages, however there are several reasons to remove all data duplicates, some of the most important being:
- Simplify the messages and define specific notificational function for each of them.
- Simplify development as it is not a good practice to duplicate data in this manner as it could lead to misunderstandings in case data turns out to be different from message to message. It also promotes good style.
- Increase transport layer bandwidth since PoW resources are in direct proportion to the size of the message.
This OVIP is designed to address those issues.
I propose to remove all data duplicates, meaning that once the piece of data that isn't supposed to be changed during the session is sent and recieved by counterparty, it isn't included in any following messages. For example, once OV (originator VASP) provides the Originator full name and VAAN through the Transfer Request to the BV (beneficiary VASP), they won't be included in Transfer Reply, Transfer Dispatch or Transfer Confirmation messages. The proposed messages structure is described in the following paragraph (leaving Session Request and Session Reply as they are).
Please note that Signature is deliberately removed from the tables as it is not a part of the protocol messages.
The Secp256k1 public keys usage remains as specified in the original Whitepaper. However the Whitepaper does not specify the exact format. The public keys must be send in compressed form. That is it must be represented with exactly 33 bytes (66 characters) and is prefixed with '02' or '03'.
| Level 1 | Level 2 | Name | Type | Mult. | Comment |
|---|---|---|---|---|---|
| Message | msg | 1..1 | |||
| Message type | type | String | 1..1 | Fixed value '210' | |
| Message identifier | msgid | Hex(128-bit) | 1..1 | Randomly set | |
| Session identifier | session | Hex(128-bit) | 1..1 | As set in message 110 | |
| Message code | code | String | 1..1 | Currently not used, fixed value '1' | |
| Originator | see 7.11 for elements | originator | 1..1 | Originator information | |
| Beneficiary | see 7.12 for elements | beneficiary | 1..1 | Beneficiary information | |
| Transfer | transfer | 1..1 | |||
| Virtual asset type | va | String | 1..1 | See 7.5.3 | |
| Transfer type | ttype | Number | 1..1 | See 7.5.4 | |
| Amount | amount | Decimal | 1..1 | 18 digits | |
| Comment | comment | String | 0..1 |
| Level 1 | Level 2 | Name | Type | Mult. | Comment |
|---|---|---|---|---|---|
| Message | msg | 1..1 | |||
| Message type | type | String | 1..1 | Fixed value '250' | |
| Message identifier | msgid | Hex(128-bit) | 1..1 | Randomly set | |
| Session identifier | session | Hex(128-bit) | 1..1 | As set in message 110 | |
| Message code | code | String | 1..1 | See 7.6.3 | |
| Destinatoin | destinationAddr | String | 1..1 | Destination address | |
| Comment | comment | String | 0..1 |
| Level 1 | Level 2 | Name | Type | Mult. | Comment |
|---|---|---|---|---|---|
| Message | msg | 1..1 | |||
| Message type | type | String | 1..1 | Fixed value '310' | |
| Message identifier | msgid | Hex(128-bit) | 1..1 | Randomly set | |
| Session identifier | session | Hex(128-bit) | 1..1 | As set in message 110 | |
| Message code | code | String | 1..1 | Currently not used, fixed value '1' | |
| Transaction | tx | 1..1 | |||
| Transaction identifier | txid | String | 0..1 | Format specific to virtual asset / transfer type | |
| Transaction datetime | datetime | String | 1..1 | ISO 8601 (YYYY-MM-DDThh:mm:ssZ) | |
| Sending address | sendingadr | String | 0..1 | Blockchain-specific format, sending address used for transactino (non-UTXO systems) | |
| Comment | comment | String | 0..1 |
| Level 1 | Level 2 | Name | Type | Mult. | Comment |
|---|---|---|---|---|---|
| Message | msg | 1..1 | |||
| Message type | type | String | 1..1 | Fixed value '350' | |
| Message identifier | msgid | Hex(128-bit) | 1..1 | Randomly set | |
| Session identifier | session | Hex(128-bit) | 1..1 | As set in message 110 | |
| Message code | code | String | 1..1 | See 7.8.3 | |
| Comment | comment | String | 0..1 |
| Level 1 | Level 2 | Name | Type | Mult. | Comment |
|---|---|---|---|---|---|
| Message | msg | 1..1 | |||
| Message type | type | String | 1..1 | Fixed value '350' | |
| Message identifier | msgid | Hex(128-bit) | 1..1 | Randomly set | |
| Session identifier | session | Hex(128-bit) | 1..1 | As set in message 110 | |
| Message code | code | String | 1..1 | See 7.8.3 | |
| Comment | comment | String | 0..1 |
Simplicity - simplify the messages and define specific notificational function for each of them. Design - it is not a good practice to duplicate data in this manner as it could lead to misunderstandings in case data turns out to be different from message to message. Efficienty - reduced message size means reduced PoW resources.
This is a simple and a straightforward solution that fixes all listed issues.