feat: Set transaction expiry block delta

[igamigo]

Closes #354
Remaining work is testing that ExecutedTransaction and ProvenTransaction get the expected block expiration number, and addressing the questions I left in the comments.

[igamigo]

I wasn't sure why I was getting an address overflow error after executing (since some lines above, half of the stack is dropped anyway), but adding this fixed it so I was unblocked.

[igamigo]

I also wasn't sure what ordering we would prefer on the stack so I pushed it near the end until I had confirmation of what would be better.

[bobbinth]

I think the stack order you have upon return is fine (i.e., [OUTPUT_NOTES_COMMITMENT, FINAL_ACCOUNT_HASH, tx_expiration_block_num]) - but let's update docs on line 253 above to reflect this.

As for truncating the stack, the reason why it happens is that get_absolute_expiration_block pushes an item onto the stack which already has 16 items. So, at the end, we end with 17 items, which results in an overflow. (the swapdw dropw dropw reduces stack depth to 16, because stack depth cannot drop below 16).

However, I would probably not use std::sys::truncate_stack here. Instead, the following would work better (i.e., would take much fewer cycles):

swapdw
exec.get_absolute_expiration_block
swap drop swapdw

Separately, I'm actually wondering if we need swapdw dropw dropw on line 331. Could you try removing these and see if things still work? If it doesn't work, we enter this procedure with a dirty stack and we should probably understand why. In this case, let's create an issue for this.

[igamigo]

Seems like it does not work without the swapdw dropw dropw.

[bobbinth]

Let's create an issue to investigate this in the future.

[igamigo]

Created #902

[bobbinth]

Looks good! Thank you! I left some comments inline. Most are pretty minor, and once they are addressed, we can merge.

[bobbinth]

I think the stack order you have upon return is fine (i.e., [OUTPUT_NOTES_COMMITMENT, FINAL_ACCOUNT_HASH, tx_expiration_block_num]) - but let's update docs on line 253 above to reflect this.

As for truncating the stack, the reason why it happens is that get_absolute_expiration_block pushes an item onto the stack which already has 16 items. So, at the end, we end with 17 items, which results in an overflow. (the swapdw dropw dropw reduces stack depth to 16, because stack depth cannot drop below 16).

However, I would probably not use std::sys::truncate_stack here. Instead, the following would work better (i.e., would take much fewer cycles):

swapdw
exec.get_absolute_expiration_block
swap drop swapdw

Separately, I'm actually wondering if we need swapdw dropw dropw on line 331. Could you try removing these and see if things still work? If it doesn't work, we enter this procedure with a dirty stack and we should probably understand why. In this case, let's create an issue for this.

[bobbinth]

Looks good! Thank you! I left a couple comments inline. The main one is about not returning the delta from the "set delta" procedures and instead adding a procedure to the kernel for getting the delta at any point in time.

[bobbinth]

Looks good! Thank you. I left some more comments inline. Also, seems like the tests are now failing?

[igamigo]

Also, seems like the tests are now failing?

Tests related to transactions now started failing with verification errors: TransactionVerificationFailed(VerifierError(InconsistentOodConstraintEvaluations)). This is related to the line I added on the prologue for initializing the transaction expiration number because if I comment that out, tests pass again (but not sure what the error means).

[bobbinth]

Tests related to transactions now started failing with verification errors: TransactionVerificationFailed(VerifierError(InconsistentOodConstraintEvaluations)). This is related to the line I added on the prologue for initializing the transaction expiration number because if I comment that out, tests pass again (but not sure what the error means).

This error usually means that there may be some kind of a mismatch in public inputs between proof generation and verification. Most likely this is happening because we put an extra value on the output stack and during verification we expect that value to be $0$ (but now it is u32::MAX). If that's the case, commenting out new lines in the epilogue should also get rid of this error.

[bobbinth]

Looks good! Thank you! I left a couple of very minor nits inline. After these, we can merge.

Also, let's make sure we have PRs on the node/client needed to make sure this change doesn't break them.

[bobbinth]

Let's add doc comments to this function.