`get-block-info` should only return information for previous blocks

[jcnelson]

Right now, get-block-info will allow a piece of Clarity code to query data about the current block. This should be blocked in the analysis pass, since it makes it nigh impossible for miners to identify valid transactions while packaging them into blocks. If the Clarity code is running at block N, then the code can only query metadata about blocks N - 1 or earlier. This also needs to apply to any time-warp code we write.

The reason for this constraint is because when packaging transactions together, a miner does not know the current burn header hash, the current block hash, or the current VRF seed. This means a miner cannot preemptively validate a transaction that depends on this information to execute. For example, if a transaction moves tokens conditionally depending on the current burn header hash, it could render a subsequent transaction in the block invalid (and the miner would have no way of knowing this in advance). Making it so the analysis pass rejects transactions that could query data about the current block avoids this problem.

[kantai]

I don't think this is a necessary requirement -- transaction execution should be done after broadcast. Transactions that "fail" would still to be included in the block. Transaction "validation", which is just wire-format syntax and signature verification, does not ever need to query that information.

[jcnelson]

Transactions that "fail" would still to be included in the block.

What about transactions that spend tokens that don't exist, e.g., through their transaction fee? Aren't those invalid?

[kantai]

Okay, I think I see now. The miner needs to be able to evaluate a block in a streaming fashion, otherwise, they may include a transaction that cannot pay the tx fee. This means that transactions shouldn't be able to query any block information that hasn't been committed at that point -- so get-block-info shouldn't evaluate at the current block-height. This cannot be checked via static analysis, though, without changing get-block-info to accept an n+1 of blocks back argument.

Alternatively, we can just have get-block-info return an optional (#1119), which it would need to do anyways, and return None in the event that its supplied a block-height >= the current height.

[jcnelson]

This cannot be checked via static analysis, though, without changing get-block-info to accept an n+1 of blocks back argument.

I'm not sure what you mean by this?

Alternatively, we can just have get-block-info return an optional (#1119), which it would need to do anyways, and return None in the event that its supplied a block-height >= the current height.

That should be fine. My chief concern is that miners should be able to tell in advance that the i+1th transaction is valid if they have processed up to the ith while producing block N.

[kantai]

The argument to get-block-info is currently block-height. You can't statically determine whether or not that block-height >= some given value. If instead it took an argument which was "number of blocks back", that could be checked, since the uint type would ensure that the argument was non-negative. So (get-block-info block-hash 0) would return the block-hash of the previous block (get-block-info block-hash 1) would return the block-hash of the block prior to that, etc. Either way, it's not a very friendly interface.

Alternatively, we can just have get-block-info return an optional (#1119), which it would need to do anyways, and return None in the event that its supplied a block-height >= the current height.

That should be fine. My chief concern is that miners should be able to tell in advance that the i+1th transaction is valid if they have processed up to the ith while producing block N.

👍 that's what we'll do, then.