Repository navigation
Conversation
Revision 1 measured Deposit as a spending action, but a deposit transaction only creates the escrow UTXO, so no script ran for it on chain (#272). The scenario is now one script with two purposes: as a minting policy it creates and burns a thread token, as a spending validator it guards the funds. The script reads its own hash from the context. - The specification names every rule (D1-D7, B1, S1-S3, A1-A2, R1-R3, X1-X3) and says what the script leaves open on purpose. - The suite measures the five executions of the lifecycle. The other 131 tests are checks: each rejected one is a successful transaction with one change and names the rule it breaks. - Contexts have the shape of ledger-built ones: 28-byte hashes, 32-byte transaction ids, inputs in ledger order, conserved value, a redeemers map. The lifecycle runs under two script hashes. - TwoPartyEscrowFixturesSpec holds the rule table as a plain function and checks every test against it. It checks the shape of every context, and it checks that a successful test breaks each condition that the rules do not demand. The existing submissions implement revision 1 and fail this suite. Results of the two revisions cannot be compared.
The ten Plinth rows now implement the thread-token scenario. Each row keeps its compiler version, its plugin flags and its inliner budgets; no budget was swept again, so a row shows what the new contract costs on that line as it is. The validator text comes from four families. The Named decoder rows (1.65, 1.67, 1.71) and the monadic rows (1.45, 1.64) carry one body per family. The plain rows (1.45, 1.61, 1.64) share one source text, and in revision 2 the two `_asdata` rows (1.65, 1.67) compile that same text. Every artifact passes the 136 tests of the scenario, and a logging build of the same source rejects each of the 77 error tests for a rule that the test names.
The two Unisay rows now implement the thread-token scenario with one validator text. Scalus 1.3.0 compiles the two token-quantity lookups to the CIP-153 `unValueData` and `lookupCoin` builtins; Scalus 0.18.2 keeps its protocol 11 build and reads the quantities from the `Data` maps. Both artifacts pass the 136 tests of the scenario, and the traced builds reject each of the 77 error tests for a rule that the test names. `Scalus_1.4.0_nau` implements revision 1 and fails the new suite, so the row is removed. Its author regenerates it from the Scalus repository once the example there follows revision 2.
Contributor
🚀 PR Preview DeployedPreview URL: https://intersectmbo.github.io/UPLC-CAPE/pr-275/ The preview site is automatically updated on every push to this PR and will be removed when the PR is closed. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
two_party_escrowbecomes one script with two purposes. As a minting policy it creates the thread token at the deposit and burns it at the end; as a spending validator it guards the funds in Accept and Refund. Revision 1 measured Deposit as a spending branch, and the deposit transaction does not run the escrow script on chain (#272). Numbers of the two revisions cannot be compared, so this PR rebuilds all twelve Unisay submissions. It removesScalus_1.4.0_nau, which implements revision 1; its author regenerates the row once the Scalus example follows revision 2.D1toD7,B1,S1toS3,A1,A2,R1toR3,X1toX3) and lists what a script may leave unchecked.deposit_successful,accept_successful,accept_burn,refund_successful,refund_burn. The other 131 tests are checks. A rejected check is a successful transaction with one change, and its description names the rule that the change breaks.TwoPartyEscrowFixturesSpecholds the rule table as a plain function and checks every test against it._asdatarows compile the validator text of the plain family.The tests prove behaviour on the CEK machine with synthetic contexts. They do not submit transactions to a ledger.
Builds on #274 for the test format. Closes #272.