Implement transaction cycles/threads #5
Description
Define types and behavior around the new blockchain evaluation parallelism designs using transaction cycles and threads.
Each block contains one or more cycles. Each cycle contains one or more threads. Each thread contains several transactions. All threads in a cycle may be executed in parallel. If some transactions A
and B
both affect an account U
, then A
and B
may be included in the same cycle if and only if they are also in the same thread (which guarantees a particular ordering). A
and B
may not be in separate threads of the same cycle. They may be in distinct cycles.
Each thread contains one or more input transactions, and zero or more output transactions. Output transactions (aka generated_transaction
s) are created when a transaction executes a smart contract, and that smart contract outputs a transaction to run. When an input transaction on thread T
generates an output transaction O
, O
becomes an output transaction on T
. O
may then subsequently become an input transaction in a future cycle, even within the same block, but not within the same cycle.
Output transactions are assigned 32-bit serial number IDs at the end of each cycle. To include an output transaction from a previous cycle as an input transaction in a current cycle, reference its ID. No longer the case; see comment below
Activity
Progress #5: Structures
nathanielhourt commentedon Apr 12, 2017
This is no longer the case. The use of 32-bit serial numbers proved too cumbersome: the added complexity of assigning the numbers correctly, avoiding synchronization problems with output transactions being generated in parallel, and most of all implementing
signed_block::merkle_root()
without having access to either the full transactions or their hashes... It is all around simpler, albeit slightly more expensive in time and space, to use full hashes.Progress #5: Hash IDs for generated transactions
thomasbcox commentedon Oct 4, 2017
cleaning up old assignments
34 remaining items