[RFC 003 RTVF] RTA Transaction Validation Flow

bitkis edited this page Jan 9, 2019 · 5 revisions

Validation Flow Sequence Diagram

RTA Transaction

RTA Transaction is an extended version of the regular transaction which requires RTA validation by authorization sample and PoS Proxy supernode. Since, in case of RTA validation, an additional fee is to be payed to authorization sample and PoS Proxy Supernode, RTA Transaction is always a multi-destination transaction, and amount of the main transaction is calculated using the formula:

MainTxAmount = TxAmount - ASSize * ASFee - PoSFee,

where TxAmount - full transaction amount, ASSize - Auth Sample Size - the number of supernodes in the authorization sample, ASFee - Auth Sample Fee - validation fee for one authorization supernode, and PoSFee - PoS Proxy Supernode Fee - validation fee for PoS Proxy Supernode. RTA transaction must include several additional data fields:

  • RTA payment ID, which identifies this payment in the Graft Network;
  • PoS Proxy Supernode public identification key, required for RTA validation by PoS Proxy Supernode;
  • Auth sample public identification keys, required for RTA validation by auth sample supernodes.

Transaction private key must participate in RTA Transaction. However, in sake of privacy, the key should not be added to transaction extra data and is to be provided separately. The transaction and private key must be encrypted, using Multiple Recipients Message Encryption.

RTA Transaction Validation

RTA Transaction must be validated by PoS Proxy Supernode and authorization sample supernodes. During RTA validation PoS Proxy Supernode and authorization sample supernodes own different goals. PoS Proxy Supernode validates amount of the transaction (note that PoS Proxy Supernode knowns PoS public wallet address) and is able to check its validation fee if required. Each auth sample supernode validates key images of RTA transaction (classical double-spent check) and the validation fee.

RTA Transaction Validation by PoS Proxy Supernode

When PoS Proxy Supernode receives RTA transaction data for RTA validation, it performs following operations:

  1. Decrypts received RTA transaction data:
    1. Decrypts message key using PoS Proxy Supernode private identification key;
    2. Decrypts RTA transaction and transaction private key using message key.
  2. Checks amount before sending it to PoS, using transaction private key and PoS public wallet address based on Monero Prove Payment Mechanism.
  3. Checks the validation fee, using transaction private key and PoS Proxy Supernode public wallet address based on Monero Prove Payment Mechanism.

RTA Transaction Validation by Auth Sample Supernode

When a supernode in auth sample receives RTA transaction data for RTA validation, it performs the following operations:

  1. Decrypts received RTA transaction data:
    1. Decrypts message key using its supernode private identification key;
    2. Decrypts RTA transaction and transaction private key using message key.
  2. Validates transaction key images (double-spent check).
  3. Checks the validation fee using transaction private key and its supernode public wallet address based on Monero Prove Payment Mechanism.

Blockchain RTA Transaction Validation

To validate RTA Transaction graftnode should perform several checks:

  1. Checks correctness of auth sample for transaction validation. For this, graftnode gets Blockchain-based List and checks if selected auth sample supernodes listed in the transaction are eligible to participate in auth sample for this transaction.
  2. Checks PoS Proxy supernode signature.
  3. Checks auth sample supernode signatures.
  4. Regular key image checking (double spent checking.)

Validation Flow Description

  1. PoS prepares payment data (amount, PoS public wallet address, serialized payment data – list of purchased items, price and amount of each item, etc.), and sends them to PoS Proxy Supernode.
  2. PoS Proxy Supernode receives sale request from PoS, checks received data, then generates RTA payment id and one-time key pair (one-time keys are used to prevent tracking POS Proxy activity in the blockchain), called one-time identification keys. The generated key pair is stored on the PoS Proxy Supernode only. After that PoS Proxy Supernode
    • selects auth sample (See Selecting Auth Sample Supernode List),
    • generates random message key,
    • prepares payment data (RTA payment id, serialized payment data, amount) and its own public wallet address (to be included to sale data, so it only is known by auth sample),
    • encrypts message data using message key, encrypts message key for each supernode in the auth sample, using supernode public identification keys.
  3. The encrypted data and key are to be multicasted to all supernodes in the auth sample. Supernodes in the auth sample decrypt and store this data using the RTA payment id. Also, PoS Proxy Supernode (the one that handles calls from PoS) broadcasts sale status for this payment. After the PoS Proxy Supernode prepares a response with RTA payment id, payment block number, payment block hash, public one-time identification key and sends it to the PoS. Therefore, PoS Proxy Supernode public identification key goes directly to the Wallet, and not to auth sample.

Payment block is a historical block in the blockchain, payment_block_number = current_block_number - SVP (see SVP). Payment Block defined by using its block number and block hash.

Communication Messages (Unicast, Multicast and Broadcast) should be always signed by its sender. Sender field in the message should be set to the sender public identification key and the signature must be add in signature field in the message. The signature is generated using sender private identification key.

  1. PoS receives a response from PoS Proxy Supernode and generates QR code (RTA payment id, PoS public address, amount, payment block number, payment block hash and public one-time identification key of Pos Proxy Supernode) for Wallet. 
  2. Wallet scans QR code, gets RTA payment id, payment block number and payment block hash from it and asks Wallet Proxy Supernode (can be any supernode in the network) for additional payment data (serialized payment data, auth sample data and PoS Proxy Supernode public wallet address). 
  3. Wallet Proxy Supernode receives wallet request and returns serialized payment data, auth_sample (8 pairs of the supernode public identification key and public wallet address, see Selecting Auth Sample Supernode List) data and PoS Proxy Supernode public wallet address. If Wallet Proxy Supernode doesn't have payment data for current payment:
    1. it looks up auth_sample and requests the data from one of the randomly selected supernode in the auth sample. The request is sent as a unicast async message to the remote supernode. 
    2. remote supernode replies on this request and returns payment data encrypted by the public identification key of a supernode required the data. The reply is sent as a unicast async message.
  4. Wallet
  • builds graft transaction, distributing fee over auth sample and Pos Proxy Supernode (more details on that can be found in the whitepaper);
  • stores RTA payment id, PoS Proxy Supernode's one-time identification key (graftnode will need it to validate Pos Proxy signature), auth sample supernode public identification keys (graftnode will need it to validate auth sample signatures) to transaction_header.extra,
  • signs transaction.
  • sends transaction blob and transaction private key to the Wallet Proxy Supernode.
  1. Once Wallet Proxy Supernode receives wallet request with the transaction blob and transaction private key, it:

    1. broadcasts pay status with status = payment_pending over all the members of the P2P network;
    2. generates message key, encrypts transaction blob and transaction private key using message key, and then encrypts 1 + 8 copies of the message key, using PoS Proxy one-time identification key and auth sample supernode identification keys.
    3. multicasts encrypted transaction, transaction private key and message keys to the auth sample supernodes and PoS Proxy Supernode.
  2. Auth sample Supernode or PoS Proxy Supernode that receives encrypted payment data, decrypts it using private identification key and approves or rejects the RTA transaction. To do this, supernode does next operations:

    1. PoS Proxy Supernode validates tx amount which sent to the PoS (since it knows PoS public wallet address) and tx fee which sent to PoS Proxy Supernode. If all validations pass, PoS Proxy Supernode signs transaction with the one-time private identification key generated in step 2, stores it in transaction extra data field and multicasts the signed transaction to the auth sample. If some validations are failed, PoS Proxy Supernode broadcasts pay failed status over the network.
    2. Auth sample members validate tx by checking its own fee amount and by checking if tx key images of the transaction already exist in the blockchain, tx pool or the list of RTA transactions currently processed by supernode (double-spent check). After validation, each auth sample member adds its vote about approval or rejection of transaction and signs it using its private identification key (Note: The vote must be part of signed data). Then, each auth sample member multicasts the signed transaction to the other supernodes in the auth sample and PoS Proxy Supernode.
  3. Each supernode from auth sample and PoS Proxy Supernode receives notification from other auth sample supernodes and handles it by checking votes and signatures:

    To prevent unpredicted states (for example, when one supernode has valid approval state (5/8) and another supernode has valid rejection state (2/8)), RTA quorum must be selected with the minimal intersection between approval and rejection conditions. The most optimal configuration in the case of 8 supernodes is 6/8 for approval condition and 3/8 for rejection condition.

    1. The consensus of approval: Transaction considered as valid as soon as at least 6 out of 8 auth sample members and PoS Proxy (always!!!) approved it.
    2. Transaction considered to be rejected in the case at least 3 out of 8 auth sample members or PoS Proxy rejected it.
    3. When any auth sample supernode or PoS Proxy Supernode gets in:
      1. the final approval state (receives 6-out-of-8-and-PoS-Proxy approvals), it fills rta_signatures and sends RTA transaction to its cryptonode. In this way, most of the supernodes who voted transaction will be sent transaction to pool simultaneously and will obviously get "double spend" error, so in case some supernode will receive double spend here - it just ignores it.
      2. the final rejection state (3-out-of-8-or-PoS-Proxy rejections), it broadcasts failed pay status over the network.
  4. Graftnode that handles RTA transaction validates:

    1. Correctness of the selected auth sample;
    2. Signature and corresponding vote from each auth sample's member;
    3. PoS Proxy signature;
    4. The transaction itself (as usual).
  5. Once the graftnode accepts the transaction, supernode, which submitted it to the cryptonode, broadcasts successful pay status over the network;  

  6. Each supernode handles status updating message, checks signature and updates status for given payment only if signature validation passes. Each supernode which sent the request for status updating must sign this request using its private identification keys.

  7. Wallet and PoS ask their proxy supernodes or any other supernode and update their status.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.