Advance transaction validation when producing blocks

[halibobo1205]

Rationale

Why should this feature exist? Transaction execution requires some resources to be requested, and this process can be time-consuming, so transaction validation should be done in advance to avoid unnecessary waste of resources.

Current Transaction Validation

Tapos TooBig Expiration ContractSize Signature Duplication

Current Block Production Flow

Implementation

Do you have ideas regarding the implementation of this feature? Transactions are validated first and executed after.

New Block Production Flow

Are you willing to implement this feature? Yes

[tomatoishealthy]

Can you provide more details, such as which code logic should the above verification be advanced to?

[halibobo1205]

Can you provide more details, such as which code logic should the above verification be advanced to?

@tomatoishealthy Tapos、TooBig、Expiration 、ContractSize、Signature and Duplication.

[jwrct]

I understand that the only difference between the two diagrams you provided is that the "buildsession" is moved after the transaction validation. My question is, can the transaction validation really be placed outside of the session? Will there be any transaction concurrency issues?

[halibobo1205]

I understand that the only difference between the two diagrams you provided is that the "buildsession" is moved after the transaction validation. My question is, can the transaction validation really be placed outside of the session? Will there be any transaction concurrency issues?

the session is a new clear session, which is designed to execute each transaction independently, there are no transaction concurrency issues.

[forfreeday]

The second graph removes the catch error && log, if there is a "catch error" during the packaging process, what is the performance loss, and is there a basis for this?

[aguinaldok4]

Can you provide more details, such as which code logic should the above verification be advanced to?

gh pr checkout 5507 - :kris9773180017@gmail.com/#5297,

[halibobo1205]

The second graph removes the catch error && log, if there is a "catch error" during the packaging process, what is the performance loss, and is there a basis for this?

About 0.01 ms for catch errors && log

[lurais]

As I can see, the difference is the op "throw and catch error " and the op "buildSession", some buildSession ops may be reduced after this change, but are you sure that the buildSession op costs much time ?

[halibobo1205]

buildSession

@lurais In fact, buildSession is not the key.

[halibobo1205]

catch errors && log（0.02ms） + buildSession(0.01 ms) ：About 0.03 ms

[lurais]

buildSession

@lurais In fact, buildSession is not the key.

So, this change may not make the production process more efficient, do you only mean to adjust the order of the operations in the process of producing blocks?

[halibobo1205]

So, this change may not make the production process more efficient, do you only mean to adjust the order of the operations in the process of producing blocks?

@lurais Sorry, catch errors && log（0.02ms） + build session (0.01 ms): about 0.03 ms, it does have an impact.

[317787106]

@halibobo1205 The difference is throw error and catch error, not catch errors && log. Suppose these two steps of each transaction cost 0.03 ms, and suppose there are 300 transactions in one block, the estimated execute time of one block can reduce 10ms. Can you specify the percent of time cost ?

[halibobo1205]

@halibobo1205 The difference is throw error and catch error, not catch errors && log. Suppose these two steps of each transaction cost 0.03 ms, and suppose there are 300 transactions in one block, the estimated execute time of one block can reduce 10ms. Can you specify the percent of time cost ?

@317787106 , This is only for invalid transactions, such as dup transactions, the block production period is 750 ms, so if there are 20,000 duplicate transactions, 600 ms will be wasted. build session (0.01 ms) + check (Tapos ->TooBig -> Expiration->ContractSize -> Duplication) (0.02 ms). I was wrong, it's not the catch & log that takes 0.02 ms, it's the invalid check process that causes it. So the point is to optimize the check order, what do you think?