How are transactions handled in a block?

[Jmunb]

Guys, hi. Help me understand how transactions are handled in the block, I couldn't find a detailed article on this.

My smart contract interacts with the liquidity pool, and it is not clear to me, will my interaction calculations be correct if there is another transaction interacting with the same pool in the block?

That is, my assumption is that all interactions will be performed in the same context, and the input parameters of the network state for all transactions will be the same.

Is this true or not? Or does each processed transaction in a block change the system states for all subsequent transactions in that block?

If so, what affects the transaction queue in a block, time or gas? Or does gas only affect the request queue in the mempool?

Thank you, I would appreciate clarification.

[thanethomson]

Which application are you asking about? Tendermint doesn't concern itself at all with ABCI application-level concepts like accounts, tokens, liquidity pools, contracts, etc.

Are you asking about how transactions are ordered in the mempool? If so, the answer is that it depends on which version of Tendermint you're using, and which mempool you're using.

Tendermint v0.34 provides two mempools:

• v0: The standard mempool (see https://docs.tendermint.com/v0.34/tendermint-core/mempool.html#mempool)
• v1: A prioritized mempool, where transaction priorities are determined by the application. This has been deprecated in Tendermint v0.37 and will be removed in Tendermint v0.38.

Tendermint v0.37 implements ABCI 1.0, which allows applications to implement app-side mempools. This allows the application to order transactions however it wants. The Cosmos SDK is currently integrating with Tendermint v0.37.0-rc2.

[lasarojc]

Hi @Jmunb
Please read this and this.

When the consensus algorithm decides on a block, Tendermint uses the sequence of calls to BeginBlock, DeliverTx and EndBlock to send the decided block's data to the Application, which uses it to transition its state.

The state seen by each transaction is the state generated by the previous transaction, including those in the same block. These state updates are not visible outside the block execution until a commit happens. Following EndBlock, Commit is invoked and

The Application should persist its state during Commit, before returning from it.

that is, state reached at the end of the last transaction is externalized.

[Jmunb]

Thank you. It became clearer to me how it all works.