Hot answers tagged

10

You can view the mempool via this RPC API endpoint. You currently can't manipulate the mempool with the RPC API. You can change the mempool filter settings though (which are used to filter out operations based on min fee requirements).


7

In the current protocol there's a time to live of 60 blocks for every manager operation, after which they can no longer be included.


7

Am I understanding correctly, that I can store for example my rental contract as a Smart Contract and then it is made official with baking it with bakers? Like in all open blockchain systems, you can run a full node, which downloads all blockchain data. Once it has been synced, it can propagate new transactions and blocks to network, can validate new ...


4

The mempool is a part of the shell (it self a part of the node). The mempool is made of all transactions which have been submitted for inclusion in the chain but not included in a block yet by bakers. Bakers can in principle choose any transaction in the mempool so they should choose those that maximize the amount of fees they receive under the double ...


4

Sure, "non-commutativity" has its challenges. Mempool management is closely aligned with incentive mechanism and thus the baker's strategy. In tezos, as far I know, endorsement operations have higher precedence (preferred by bakers) as they determine the fitness of the block they are going to produce and therefore the chance of it being part of canonical ...


4

I think that, currently, the choice of the operations included in a block is done to maximize fees-per-gas for transactions and originations, while all other operations (endorsements, votes, etc.) are always included. Anyway, a choice is only done if there are too many operations for a block, we are not in this situation right now.


3

The right answer is 60 at the moment, as answered in: Max lifetime of transactions in mempool? This value is set by the protocol-dependent constant max_operations_ttl in: https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/alpha_context.ml#L261 Thus, it can eventually change on future versions of the protocol. Notice also that 60 is an ...


3

I don't agree that the mempool behavior indicate that the fee is all good. On the contrary. Public nodes like Giganode generally don't reject operations based on fee in the prevalidation, while most other nodes do apply the default filter. The fee is most likely too low. I don't know exactly how many bytes you got there, but increasing the fee with 10 mutez ...


3

A baker is free to include whatever operations it wants, as long as they are valid. By default a baker want to create the block that generate the highest amount of fees (most bakers will also have a minimum fee threshold to pass prevalidation). In combinatorial optimization this is described as a knapsack problem. So how the baker choose transactions is ...


2

Currently, the cardinality of the valid operations set in the mempool is hard-coded at 2000. Whereas branch delayed operations (e.g. counter in the future, insufficient balance, etc.) are stored in a ring buffer of size 1000 with the semantics being that when the maximum number of operations stored has been reached, the oldest operation will be removed to ...


2

Right, your fee is not high enough. Next time you think something like "is this the wrong fee?", let your next thought be like "I will try increasing the fee to see what happens." Hardcoding the fee is not a great idea. At best, you will pay unnecessarily high fees, losing some mutez. At worst, this will happen. There are docs and other questions here ...


2

In general, there would be some logic to prioritize local operations versus remote operations. Yet, that would only be needed when a baker has both a baking slot, and the need to emit new operations in the same block, something that does not happen very often. So, no, right now, there is prioritizing of operations based on their sender. Indeed, that could ...


1

The best way to send multiple transactions from a single account is grouping them into a single operation. Note that only manager operations (transaction, delegation, origination, reveal) can be grouped into a batch. Here is an example (see more in Netezos docs): var counter = await rpc.Blocks.Head .Context.Contracts[address].Counter.GetAsync<int>()...


1

Transactions should only live for 60 blocks within the mempool before being deleted. There have been reports in the bakers-slack of this not working correctly and some trx living for many thousands of blocks. The only way to clear your mempool is to restart your node.


1

Both transactions sent from your address have the same fee 0.01 tez that is not enough, taking into account the gas limit 50000. Try to set the fee 0.015 tez. If this doesn't help, it also can be a problem with the node you use, so try to use another one, like Tezos Giga Node. And yes, operations stay in the mempool for only an hour, however TzKT explorer ...


1

Don't worry, your funds are safe. You need to wait a bit and then try again with a higher fee or lower gas_limit. Why did that happen? You sent a transaction with large gas_limit: 50000 (despite a simple tz-to-tz transfer consumes about 1427 gas) and rather small, for such gas limit, fee:10000. So no one baker picked your transaction to include into a block ...


1

The node closes the stream when it changes its head. When a block (most often the just received one) is chosen as the new head, the mempool is reset. Operations included in blocks are removed, valid operations and branch delayed operations are reconsidered (are they still/now valid?). You have to get these refreshed list of operations by restarting a fresh ...


1

I noticed that /chains/<chain_id>/mempool/pending_operations is not described anywhere in the official documentation. https://tezos.gitlab.io/api/rpc.html?highlight=mempool


Only top voted, non community-wiki answers of a minimum length are eligible