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

Dettached Verification + Application: ensure delay is at most one block #965

Closed
igormcoelho opened this issue Jul 30, 2019 · 1 comment
Closed
Labels
Discussion Initial issue state - proposed but not yet accepted Feature Type: Large changes or new features Ledger Module - The ledger is our 'database', this is used to tag changes about how we store information VM New features that affect the Neo Virtual Machine or the Interop layer

Comments

@igormcoelho
Copy link
Contributor

igormcoelho commented Jul 30, 2019

Right now we following a dettached model for verification and application.
So, when transactions enter mempool, verifications are performed, and applications are only executed after block is persisted. This is important to accelerate the network and improve TPS (because block proposal and verification can happen quickly, without executing transaction applications before block is not acually final by consensus).

However, this dettached state can only last for one block difference, for two reasons:

  1. if we start processing H=100, without having complete applications for H=99, we would not be sure of the GAS balances (even to pay system and network fees on next block verification), since some GAS could also be spent during application
  2. if height difference gets bigger than one (example: network verification is 10 seconds, and application is 15 seconds), this means that application may never catch up to top blockchain height, and it may get delayed forever.

So, the only time we have to process applications is the time between blocks, i.e., 15 seconds.

@igormcoelho
Copy link
Contributor Author

This solves #812 @vncoelho

@lock9 lock9 added the Discussion Initial issue state - proposed but not yet accepted label Jul 31, 2019
@lock9 lock9 added Ledger Module - The ledger is our 'database', this is used to tag changes about how we store information Feature Type: Large changes or new features VM New features that affect the Neo Virtual Machine or the Interop layer labels Aug 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted Feature Type: Large changes or new features Ledger Module - The ledger is our 'database', this is used to tag changes about how we store information VM New features that affect the Neo Virtual Machine or the Interop layer
Projects
None yet
Development

No branches or pull requests

3 participants