Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallel transaction processing design #103

Closed
garious opened this issue Apr 3, 2018 · 2 comments
Closed

Parallel transaction processing design #103

garious opened this issue Apr 3, 2018 · 2 comments
Milestone

Comments

@garious
Copy link
Contributor

garious commented Apr 3, 2018

  • Should we do L0 verification of blocks without context?
    • We can calculate deltas
    • Some event data doesn’t coalesce well (i.e. Witness events)
      • But two timestamps do.
  • Should events within a single entry be processed in parallel?
    • How to identify when order affects output?
      • Example: Race(PayAfter(date, to), CancelOnSig(from))
      • Applying a credit first could allow a debit to proceed
    • For conflict resolution, should we look to event order within the entry?
    • When leader creates the entry, should it order ambiguous events or discard one? Discard all?
  • Should events across entries (all events in one block) be processed in parallel?
    • For conflict-resolution, entry order within the block unambiguously determines order.
@garious
Copy link
Contributor Author

garious commented Apr 3, 2018

Notes from initial discussion with @aeyakovenko:

  • First event seen gets added to the entry. Any event that can't be processed in parallel gets pushed back and considered in the following entry.
  • Calculating only deltas without any context sounds appealing. Applying the delta can be a separate validation step. Note this is only applicable to validators, where you have the option to reject an entire block. The leader, on the other hand, needs to reject bad transactions individually.
  • No intent to parallelize event processing across entries. Note that may massively reduce the opportunity for parallelism. Need to run the numbers on that.

Takeaway: maximize transaction throughput.

@garious
Copy link
Contributor Author

garious commented Apr 12, 2018

What I ended up implementing is to put separate read/write locks on each of the following:

  • account balance
  • the table of all balances
  • each pending smart contract
  • the table of pending smart contracts
  • the set of previous transaction signatures

I also changed transaction processing to apply all debits first, and once complete, start applying all credits. This ensures that the same set can be validated in any order and that no debit will pull the account below zero. The strategy therefore rejects transactions that would otherwise be valid if a credit was applied first.

@garious garious closed this as completed Apr 12, 2018
@garious garious added this to the v0.5.0 milestone Apr 12, 2018
vkomenda pushed a commit to vkomenda/solana that referenced this issue Aug 29, 2021
…#103)

Bumps [superstruct](https://github.com/ianstormtaylor/superstruct) from 0.8.4 to 0.10.12.
- [Release notes](https://github.com/ianstormtaylor/superstruct/releases)
- [Changelog](https://github.com/ianstormtaylor/superstruct/blob/master/Changelog.md)
- [Commits](ianstormtaylor/superstruct@v0.8.4...v0.10.12)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
buffalojoec pushed a commit to buffalojoec/solana that referenced this issue Mar 7, 2024
willhickey pushed a commit that referenced this issue Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant