Auxiliary data structures for tx re-verification

[vncoelho]

We probably must define a special balance structure for efficiently accounting remaining GAS of senders in order to quickly re-verify.

Scenario 1:

• Imagine that an address has 10 GAS ans sends 10 TXs with 1 GAS each as network_fees.
• All these TXs enters in the same block
• We need to be sure that tx_1 will not spend any GAS (that is why balance need to be updated before)

[vncoelho]

After persisting, first of all:

• Process all TXs with Payable_Flag. Tx's should allow Payable and not the contract (or both).

@jsolman, we would change the unverified and verified of the mempool.
The idea would be to update the balances and mark transactions with negative balances as not valid (removing them from mempool).

[vncoelho]

We are planning to include this in the specification before implementation.

[erikzhang]

We need to be sure that tx_1 will not spend any GAS

Why?

[igormcoelho]

I think Vitor mentioned this case Erik (imagine 5 transactions in a block, all from the same address A):
Balance(A) = 7 GAS

Tx A1:  1 GAS network fee
Tx A2:  1 GAS network fee
Tx A3:  1 GAS network fee
Tx A4:  1 GAS network fee
Tx A5:  1 GAS network fee
ok: final balance of A is 7-5 = 2 GAS

Now imagine that A2 and A3 will perform some payable operation, with 2 GAS each:

Tx A1:  1 GAS network fee
Tx A2:  1 GAS network fee
    -> payable operation 2 GAS (ok)
Tx A3:  1 GAS network fee
    -> payable operation 2 GAS (FAULT)
Tx A4:  1 GAS network fee
Tx A5:  1 GAS network fee
ok: final balance of A is 7-5-2 = 0 GAS

Note that Tx A3 should FAULT, otherwise it will consume resources from the network fee of Tx A4 and Tx A5. This is what he meant I guess...
We need to process all network fees before entering any Application trigger on block.

[igormcoelho]

The logic we are thinking for Neo 3.0 is the following Erik, can you confirm?

Tx A1:  
Verification: 1 GAS network fee  ("transfer" -> "ConsensusAddress")
Application:  Invoke token TKN transfer... example!
-----------------------
Tx A2:  
Verification: 1 GAS network fee  ("transfer" -> "ConsensusAddress")
                       transfer 2 GAS -> "ContractX address" (pre transfer to contract)
Application:  Invoke ContractX, and it requires to pay someone else 2 GAS...
                                    -> payable operation 2 GAS (ok)
-----------------------
Tx A3:  1 GAS network fee
Verification: 1 GAS network fee  ("transfer" -> "ConsensusAddress")
Application:  Invoke ContractX, and it requires to pay someone else 2 GAS...
                                    -> Invoke Application GAS-Native-NEP-5 Transfer operation 2 GAS (FAULT)
-----------------------
Tx A4:  
Verification: 1 GAS network fee  ("transfer" -> "ConsensusAddress")
Application:  Invoke token TKN transfer... example!
----------------------------------------------
Tx A5:  
Verification: 1 GAS network fee  ("transfer" -> "ConsensusAddress")
Application:  Invoke token TKN transfer... example!
----------------------------------------------
ok: final balance of A is 7-5-2 = 0 GAS

[erikzhang]

Are we not like this now?

[igormcoelho]

It's just like this, specifically for GAS tokens. But I understood that balance will be managed manually for GAS, not directly on storage operations, so the final effect is the same. As long as verifications are consumed before applications, and managed Application.Send() operations lock the funds before the actual send, things will be fine.

[lock9]

@neo-project/core closeable?

[vncoelho]

It is still open discussion, not yet defined or implemented on Neo3.

[shargon]

@vncoelho what is your proposal, when should be reverified the mempool?

[vncoelho]

@shargon re-verified normally, it is just an auxiliary data structure for monitoring the balance during Application phase, or, more efficiently than it, an extra field in all payable transactions, in which will limit the maximum amount that GAS will be spent.

We need to think about the most practical design. Re-verification should be straightforward, we should easily remove invalid tx from the mempool after block is defined as persisted (even before its final state)

[lock9]

@vncoelho what is the difference between this issue and #840 ? Are they the same? Only #840 is planned for the next release.

[vncoelho]

This one can be planned for the second release, preview-2.

[vncoelho]

I will move NEP5 tokens to another issue.