-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alonzo test failure #2811
Comments
Is it possible to share the transaction which caused this? |
@jmhrpr it would take a bit of digging, but I'm sure we could if it was important. It looks like the generators are just adding an unneeded script witness, though. |
I guess it was just concerning that this could hint that in some case the ledger is not requiring a script when it be, but thinking about it that would probably throw other errors for extra redeemers etc so yeah probably like you say. Though, now I'm looking at the functionality: If you have the same required script On L92 we remove On L94 we then check the difference of That doesn't feel like the correct behaviour, if I'm not misunderstanding. What do you think - shall I raise an issue? |
This is intended behaviour, if you check the spec that it will also fail in this situation. The reason is that we want to ensure that the block producer can not remove any scripts from the transaction (which is a property that Alonzo has, so we want to preserve it). |
I see, do you mean add instead of remove? |
If a Tx requires |
Adding as well as removing scripts should be impossible, i.e. we want the set of scripts to be specified exactly. If we allowed scripts to be both present in the witnesses and be inlined, that wouldn't be the case. |
Ah, yes mistake in the scenario described in my last message is that it has the script both inlined and in the witnesses, but we're saying we don't want to allow that for the very reason I showed - if the ledger rules did allow a script to be both inlined and in the witnesses then:
Am I understanding correctly? Though I'm not sure what we are protecting against (if anything) - I can't immediately see any issues that would arise from 1), and increasing the transaction size via 2) would at worse cause phase1 failure similar to changing anything else in the transaction. If either case could affect phase2 script execution then that would be an issue but I don't think they can. I guess perhaps we just want to provide users with the guarantee that the transactions they submit will be identical to those that appear on chain? |
Yes, that's what it is about. It's not really that we think there's an attack, or that it's particularly bad if something changed that doesn't affect anything, it's just that this is a nice property to have: no one gets to mess with your transactions, whether that actually affects anything or not. Note that this is sadly already broken, but only it the VKey witnesses (think of multisig: if you build a transaction, you might not know who is going to sign it, but you don't really care as long as enough people do). |
That makes sense - thanks! |
That seed does not seem to work on the current master branch, but I ran a bunch of tests to try to reproduce it and managed to make the same test fail with missing scripts this time:
commit dd13fad |
Another example found here: https://github.com/input-output-hk/cardano-ledger/runs/7131338110?check_suite_focus=true
|
Investigate the following alonzo test failure
The text was updated successfully, but these errors were encountered: