Exprimental: Nairobi support

[nicolasochem]

Payment to KT appears to fail due to:

proto.017-PtNairob.gas_exhausted.operation

It appears that in Nairobi proto, simulated transactions produce different consumed_milligas values when provided as a batch (more than one operation). Adding "just a little bit more gas" to the KT1 calculation appears to be fixing it.

Also, gas for tz3 operations went up, while it went down for other address types. A proper solution would be to count the address types, but for now we just pay assuming every address is a tz3.

[AndrewKishino]

From what I have been playing around with on Ghostnet, simulated transactions produce different consumed_milligas values when provided as a batch (more than one operation). The internal_operation_results consumed_milligas looks to be consistent between batch and single operation simulations, but the operation_result consumed_milligas seems to vary when multiple operations are provided as a batch.

[AndrewKishino]

It seems in order to get an accurate simulated value for gas, you would have to simulate the entire batch and use those values in the operation. Although, a simpler solution does seem to add a small buffer. 100 seems to cover the spread from what I have tested.

[denver-s]

Fee can be lowered to 270 in "TZ1_TO_ALLOCATED_TZ1". It seems very strange that we need to increase gas limit while, in reality, it's about 101 per tz1-to-tz1 transaction, might be a bug in octez?

[rafoo]

It appears that in Nairobi proto, simulated transactions produce different consumed_milligas values when provided as a batch (more than one operation).

Starting with Nairobi, the gas corresponding to signature checking for a batch of operations is only consumed once per batch and it is included in the gas consumption of the first operation of the batch. The behavior should however be identical for simulation and for application.

Also, gas for tz3 operations went up, while it went down for other address types. A proper solution would be to count the address types, but for now we just pay assuming every address is a tz3.

The cost depends on the signature scheme used by the source of the operation, not the destination. So as long as TRD payments are all from the same address there should be nothing to count.

100 seems to cover the spread from what I have tested.

It should be enough if the source of the payments is a tz1 or a tz2 but not for tz3.

[rafoo]

It seems in order to get an accurate simulated value for gas, you would have to simulate the entire batch and use those values in the operation.

Can you please explain how TRD currently simulates and injects the operations? Are the simulated operations batched? Are the injected operations batched?

[nicolasochem]

It seems in order to get an accurate simulated value for gas, you would have to simulate the entire batch and use those values in the operation.

Can you please explain how TRD currently simulates and injects the operations? Are the simulated operations batched? Are the injected operations batched?

Payments to KT contracts are simulated one by one (that's how we prune out the contracts that can't take payments) then the injected operations are batched. There is one separate batch for KT payments.

[rafoo]

Ok, so here is what I guess is happening. There are (at least) 2 contracts to be paid, let's call them A and B. Simulating the calls individually gives X gas for A and Y gas for B. Let's call X1 and Y1 the parts of X and Y coming from the cost of signature checking and X2 and Y2 the rest of the gas consumption; we have X = X1 + X2 and Y = Y1 + Y2. The gas needed for the [A; B] batch is [X1' + X2; Y2], where X1' is the gas for the signature check of the complete batch. Unfortunately, X1' is slightly larger than X1 because the gas of signature checking depends on the length of the operation and the [A; B] batch is larger than A.

If this guess is correct, you should probably replace the 100 constant by something which depends on the length of the batch and only apply it to the first operation of the batch (Y2 will always be smaller that Y1 + Y2).

[denver-s]

Fee can be lowered to 270 in "TZ1_TO_ALLOCATED_TZ1". It seems very strange that we need to increase gas limit while, in reality, it's about 101 per tz1-to-tz1 transaction, might be a bug in octez?

@rafoo what about tz1 batches?

[denver-s]

For some reasons, it seems to work with GAS_LIMIT = 302 and FEE = 270 (speaking of TZ1_TO_ALLOCATED_TZ1)

[rafoo]

Fee can be lowered to 270 in "TZ1_TO_ALLOCATED_TZ1". It seems very strange that we need to increase gas limit while, in reality, it's about 101 per tz1-to-tz1 transaction, might be a bug in octez?

@rafoo what about tz1 batches?

In that case too, the gas consumption for the first operation of the batch will be slightly higher than if it were simulated on its own and all other operations of the batch will consume much less gas.