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

Simulate transactions in CLI & REST by default #1246

Closed
cwgoes opened this issue Jun 13, 2018 · 10 comments
Closed

Simulate transactions in CLI & REST by default #1246

cwgoes opened this issue Jun 13, 2018 · 10 comments
Assignees
Labels

Comments

@cwgoes
Copy link
Contributor

cwgoes commented Jun 13, 2018

Simulate transactions against current state for:

  • Transaction outputs, where applicable (e.g. proposal ID)
  • Catching invalid transactions before committing them
  • Estimating gas usage
@cwgoes
Copy link
Contributor Author

cwgoes commented Jul 6, 2018

Oh, since we're writing a TracingKVStore anyways, we should an a --dry-run option which doesn't actually sign or broadcast the transaction, but instead runs it against the state and reports all keys read/written.

@alessio
Copy link
Contributor

alessio commented Aug 20, 2018

Side note: --dry-run requires transactions to be signed anyway, simulation via query wouldn't go through otherwise

@cwgoes
Copy link
Contributor Author

cwgoes commented Aug 20, 2018

Side note: --dry-run requires transactions to be signed anyway, simulation via query wouldn't go through otherwise

I think we should actually remove this requirement, it isn't strictly necessary and is a bit confusing from a UX perspective. We can just skip the ante check for dry run.

@alessio
Copy link
Contributor

alessio commented Aug 20, 2018

We could skip the ante handler, though the gas estimate would be surely wrong. If a --dry-run is somewhtat desirable, then I think it is worth to open a separate issue.

@cwgoes
Copy link
Contributor Author

cwgoes commented Aug 20, 2018

We could skip the ante handler, though the gas estimate would be surely wrong. If a --dry-run is somewhtat desirable, then I think it is worth to open a separate issue.

No, sorry, was unclear - run the ante handler, consuming gas as normal, but just don't require a valid signature (specifically for simulation).

@alessio
Copy link
Contributor

alessio commented Aug 20, 2018

Are you perhaps suggesting to skip processSig() whilst consuming the gas that would be consumed by a successful call?

@cwgoes
Copy link
Contributor Author

cwgoes commented Aug 20, 2018

Are you perhaps suggesting to skip processSig() whilst consuming the gas that would be consumed by a successful call?

Yes, don't have the code in front of me but that's the idea.

@alessio
Copy link
Contributor

alessio commented Aug 21, 2018

This happens when ante handler is called via simulateTx:

[ConsumeGas] [memo] amount: 0 - consumed: 0
[ConsumeGas] [ReadFlat] amount: 10 - consumed: 10
[ConsumeGas] [ReadPerByte] amount: 42 - consumed: 52
[ConsumeGas] [ante verify] amount: 100 - consumed: 152
[ConsumeGas] [WriteFlat] amount: 10 - consumed: 162
[ConsumeGas] [WritePerByte] amount: 440 - consumed: 602

Note that signature verification is skipped as no sigs are sent.
The following excerpt instead shows the gas consumption of ante handler via runTx():

[ConsumeGas] [memo] amount: 0 - consumed: 0
[ConsumeGas] [ReadFlat] amount: 10 - consumed: 10
[ConsumeGas] [ReadPerByte] amount: 42 - consumed: 52
[ConsumeGas] [ante verify] amount: 100 - consumed: 152
[ConsumeGas] [WriteFlat] amount: 10 - consumed: 162
[ConsumeGas] [WritePerByte] amount: 840 - consumed: 1002

Thus if the UI's requirement is to simulate the execution to then expect an accurate estimate, the latter would be likely pretty wrong since store write ops depend on bytes stored, i.e. no sigs, fewer bytes written.

@cwgoes
Copy link
Contributor Author

cwgoes commented Aug 21, 2018

Can we write a fake signature during the simulation?

@jackzampolin
Copy link
Member

cc @mslipper

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants