Native Contract for Routing Txs - Lock txs

[vncoelho]

Summary or problem description

1- There is a PR opened for conflicts #2818
It introduces a feature almost pure based on layer 1 level, the mempool.
This extra feature also requires extra security and more sophisticated mechanisms.

2 - Some time ago I also remember @shargon started some discussion regarding locks for TXs. (please link this issue/discussion here if it is relevant)

Do you have any solution you want to propose?
Perhaps a good way to deal with such demands would be a Native Contract focused on routing txs.
This contract will have give some extra possibilities, such as:

• Allow user to send a tx that waits some couple of blocks to be processed and automatically included in some specific block, without the need to worry because it would be already on-chain.
• Allowing users to add conflict to a tx. Tx will stay on routing contract for a certain period (thus, it could be replaced, merged, among others...)
• This contract could even handle something connected with the proposed notary service Add a notary service #2646

With these basic features we are able to do a similar scenario of what we could do on the mempool itself.
Maybe a tx that has been signed should be processed on-chain. There should not be errors on that, as well as not a hurry on trying to replace it.
A correctly designed native contract will gracefully handle several needs we current have.

Neo Version

• Neo 3

[roman-khimov]

Going via the contract always means adding a delay and processing overhead (including paying additional fees). Both #1573 and #1991 work in sub-block time. In most of the cases it's a very nice property to have. Like the "real-time" oracle that @Liaojinghui wants to build could easily be done on top of the Notary subsystem.

Another thing is that currently we can't add a proper transaction into some (next) block from a contract. And likely this won't be easy either.