Skip to content

Verification and Gas control#790

Closed
shargon wants to merge 3 commits intoneo-project:masterfrom
shargon:verification-control
Closed

Verification and Gas control#790
shargon wants to merge 3 commits intoneo-project:masterfrom
shargon:verification-control

Conversation

@shargon
Copy link
Copy Markdown
Member

@shargon shargon commented May 29, 2019

Close #789


public TriggerType Trigger { get; }
public IVerifiable ScriptContainer { get; }
public IExecutionControl Control { get; }
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be in neo-vm by default

@codecov-io
Copy link
Copy Markdown

codecov-io commented May 29, 2019

Codecov Report

Merging #790 into master will increase coverage by <.01%.
The diff coverage is 43.75%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #790      +/-   ##
==========================================
+ Coverage   37.74%   37.74%   +<.01%     
==========================================
  Files         176      178       +2     
  Lines       12442    12465      +23     
==========================================
+ Hits         4696     4705       +9     
- Misses       7746     7760      +14
Impacted Files Coverage Δ
neo/SmartContract/GasControl.OpCodePrices.cs 100% <ø> (ø)
neo/Network/P2P/Payloads/Transaction.cs 56.83% <0%> (ø) ⬆️
neo/Wallets/Wallet.cs 5.18% <0%> (ø) ⬆️
neo/SmartContract/Native/NativeContract.cs 85.26% <0%> (ø) ⬆️
neo/SmartContract/Helper.cs 43.5% <0%> (ø) ⬆️
neo/Network/RPC/RpcServer.cs 0% <0%> (ø) ⬆️
neo/SmartContract/VerificationControl.cs 0% <0%> (ø)
neo/SmartContract/GasControl.cs 100% <100%> (ø)
neo/Ledger/Blockchain.cs 36.81% <33.33%> (ø) ⬆️
neo/Ledger/Blockchain.ApplicationExecuted.cs 93.33% <50%> (-6.67%) ⬇️
... and 3 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b11d15...0c7c3a4. Read the comment docs.

@erikzhang
Copy link
Copy Markdown
Member

What problem does this refactoring solve?

@shargon
Copy link
Copy Markdown
Member Author

shargon commented May 29, 2019

We are able to ban opcodes in verification, and max amount of instructions to execute

public class VerificationControl : GasControl
{
private readonly static List<OpCode> _bannedOpcodes = new List<OpCode>(new OpCode[] { /*OpCode.NOP*/ });
public int MaxStepInto { get; private set; }
public VerificationControl(int maxSteps, long gas) : base(gas, false)
{
MaxStepInto = maxSteps;
}
public override bool OnPreExecute(OpCode opCode)
{
if (!base.OnPreExecute(opCode)) return false;
MaxStepInto--;
return MaxStepInto > 0 && !_bannedOpcodes.Contains(opCode);

https://github.com/neo-project/neo/pull/790/files#diff-2753610b8764e06ef8ead3333db9b7aaR270

@erikzhang
Copy link
Copy Markdown
Member

I think limit the max steps is useless. Limiting the max gas is enough.

@shargon
Copy link
Copy Markdown
Member Author

shargon commented May 29, 2019

And the opcodes, like syscalls?

@erikzhang
Copy link
Copy Markdown
Member

Without SYSCALL, the verification script can't verify the signatures. There is no reason to limit it.

{
public class VerificationControl : GasControl
{
private readonly static List<OpCode> _bannedOpcodes = new List<OpCode>(new OpCode[] { /*OpCode.NOP*/ });
Copy link
Copy Markdown
Contributor

@igormcoelho igormcoelho May 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its in a good direction shargon, however needs a little more complication here. To ban backwards jumps we need to analyse the code and its first parameter... so, a callback returning true/false is better than a static list.
I've been thinking and another option would be to have different JMPF (jump forward) that can only jump forward. If we do this, its easier to ban. And create 3 more: JMPF, JMPFIF and JMPFIFNOT . A callback can avoid this and give more control on used opcodes.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gonna be an interesting thing!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to handle these bannedOpcodes in this PR or split in two?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vncoelho
Copy link
Copy Markdown
Member

vncoelho commented May 29, 2019

I really do not have the perfect understanding that you @igormcoelho, @lightszero, @erikzhang and @shargon have been sharing over these topics.

However, biased or not, I am in favor of things that my brother @igormcoelho proposes, related to not being turing complete and remove the jumps in some special cases.
We could have both systems working together. Those who want limited execution and those who do not want it.

After that, we should also please come back to that discussion about op_eval. Let's turn it to a SYSCALL as well and allow us to play with this! 💃


public long GasConsumed { get; private set; } = 0;

public GasControl(long gas = 0, bool testMode = false)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, perfect, @shargon.

The refactor is precise!
It is much more readable.

I agree with it.

The other discussions out of the refactor and the class could be moved to other PR.

Maybe we can rename GasControl -> GasManager or GasTuringCompleteManager or GasTuringIncompleteManager...aehuaheuaheua
Turing is just for fun. Maybe GasManager or GasLimitsManager

@vncoelho
Copy link
Copy Markdown
Member

Can we move with this PR? It has a nice refactor, maybe split this or leave this template and later adjust.

@vncoelho
Copy link
Copy Markdown
Member

vncoelho commented Jun 23, 2019

@shargon, maybe split this PR in Refactoring and the feature that closes #789.

@vncoelho
Copy link
Copy Markdown
Member

ping @shargon...ahueahuea

@shargon
Copy link
Copy Markdown
Member Author

shargon commented Jul 19, 2019

If all are agree i can fix the conflicts otherwise i will close it. Now i think that is not needed because we only check gas

@erikzhang
Copy link
Copy Markdown
Member

I think it's not needed anymore.

@shargon shargon closed this Jul 22, 2019
@shargon shargon deleted the verification-control branch July 22, 2019 09:34
Thacryba pushed a commit to simplitech/neo that referenced this pull request Feb 17, 2020
* release-2.10.0

* Update v2.10.0.md (neo-project#785)

* Update v2.10.0.md

* Update v2.10.0.md

* Update and rename v2.10.0.md to v2.10.0

* Update v2.10.0

* update exchange

* Introduction for gas related rpc (neo-project#788)

Introduction for gas related rpc

* add plugin

* Update v2.10.0.md

* update English files
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

Successfully merging this pull request may close these issues.

Turing-incomplete tx mempool verification on Neo 3

5 participants