Skip to content
This repository was archived by the owner on Aug 2, 2022. It is now read-only.
This repository was archived by the owner on Aug 2, 2022. It is now read-only.

Implement transaction cycles/threads #5

Closed
@nathanielhourt

Description

@nathanielhourt
Contributor

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_transactions) 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

added a commit that references this issue on Apr 11, 2017

Progress #5: Structures

nathanielhourt

nathanielhourt commented on Apr 12, 2017

@nathanielhourt
ContributorAuthor

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.

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.

added a commit that references this issue on Apr 12, 2017

Progress #5: Hash IDs for generated transactions

thomasbcox

thomasbcox commented on Oct 4, 2017

@thomasbcox
Contributor

cleaning up old assignments

34 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nathanielhourt@heifner@thomasbcox

        Issue actions

          Implement transaction cycles/threads · Issue #5 · EOSIO/eos