Deterministic numbering of virtual operations

[abitmore]

User Story

These fields are in operation_history_object:

         /** the block that caused this operation */
         uint32_t          block_num = 0;
         /** the transaction in the block */
         uint16_t          trx_in_block = 0;
         /** the operation within the transaction */
         uint16_t          op_in_trx = 0;
         /** any virtual operations implied by operation in block */
         uint16_t          virtual_op = 0;

Earlier described in #206, numbering of virtual operations (read: virtual_op field) is not deterministic, which have caused confusions to client application developers.

There is a virtual_op field in operation_history_object ... is filled with the variable _current_virtual_op in database.hpp ..., but _current_virtual_op has never been saved to or loaded from disk (but only increases forever). If witness_node is started without --replay-blockchain, _current_virtual_op is reset to 0 ...

bitshares-core/libraries/chain/db_block.cpp

Line 491 in 0b7cc7e

oh.virtual_op = _current_virtual_op++;

That said, different API nodes may return different virtual_op values when being queried with same parameters.

Here I propose a rule about deterministic numbering of virtual operations:

• For real operations (which are explicitly included in a signed transaction), let virtual_op = 0;
  • Note: both trx_in_block and op_in_trx are indexes start from 0, E.G. if a block contains 2 transactions, trx_in_block of the operation_history_objects may be 0 and 1.
• For virtual operations caused by a real operation (E.G. two fill_order_operations caused by a limit_order_create_operation), let (block_num,trx_in_block,op_in_trx) be the same as the real operation, and let virtual_ops be 1, 2, ...
• For virtual operations which are not directly caused by a real operation (E.G. virtual limit_order_cancel_operations due to expiration),
  • let trx_in_block be the number of transactions in the block, E.G. let it be 2 if the block contains 2 transactions,
  • let op_in_trx = 0,
  • let virtual_ops be 0, 1, ...

Impacts
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

Additional Context (optional)
Add any other context about your request here.

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[pmconrad]

Makes sense. Added "Protocol" label because there should be an implicit consensus about the numbering, although it is technically not part of the protocol.

[ryanRfox]

Currently this Issues is assigned to a Feature Release (3.1). Should it be moved to the Protocol Upgrade (4.0.0) release?

[pmconrad]

No, it can go into the feature release. This non-deterministic behaviour should be fixed in the next release.

[abitmore]

Merged #1676. Closing.