Lyd/bytes20

[lydiagarms]

Summary

Fixes #441. This PR adds support for public and secret bytes20 variables into Starlight. It also includes several unrelated fixes:

Changes

Bytes20 changes:

• Turn off unsupported errors for Bytes20.
• Stop using parseInt on bytes20 in orchestration as this leads to rounding errors.
• Check bytes20 input to make sure they are in the correct format.
• In format commitments, treat bytes20 values as ascii or hex(20) depending on whether they are printable. Also treat addresses as hex(32) for better usability.
• Ensure that public bytes20 variables are passed to the contract in orchestration in the correct format.
• Update tests and documentation.

Changes unrelated to bytes20:

• fixes a bug for mappings to structs. The order of parameters to proof generation in orchestration is defined by the order modified in the contract instead of the struct declaration. This means the order is not consistent with the circuit.
• creates an error message when variable names are used in zolidity contracts that could clash with names in orchestration.
• fixes an error for structs in orchestration. If the first time a struct is modified it is an assignment, then the initial struct is set to {}, because it will be fully overwritten anyway. However, a property assignment was being treated in the same way and the initial struct set to {}, even though one property was being assigned, and so all other properties were incorrect.
• Fix a zappify error when .push is used for a public array, the array was being treated as a mapping because we were checking isConstantArray instead of isArray.
• Fix an orchestration error when public bools are returned. We should filter out public variables from the returns from the orchestration file unless true or false is returned, because they are treated separately in publicReturns. However, boolean variables were not being filtered out, and so were being treated later as secret variables. This meant the commitment value was being returned causing an error.

Checklist

• Tests added/updated
• CI passes
• No secrets/keys committed
• Docs updated (if needed)
• Backwards compatible (or noted breaking change)

How to test

Test action-tests/Escrow-refs (specifically transfer) and action-tests/Bytes20.

Screenshots / Evidence (if applicable)

Escrow-refs:

Bytes20:

[kKahina]

you add a Bytes20 contract, but there is no dedicated callZAppAPIs('Bytes20', ...) flow in apitest.
Current coverage validates transpilation, not end-to-end runtime behavior for bytes20 (API + commitments + backup/retrieval).
Please add a focused integration scenario.

[kKahina]

this PR only updates STATUS. Please add a README update for bytes20 support

[lydiagarms]

you add a Bytes20 contract, but there is no dedicated callZAppAPIs('Bytes20', ...) flow in apitest. Current coverage validates transpilation, not end-to-end runtime behavior for bytes20 (API + commitments + backup/retrieval). Please add a focused integration scenario.

The two contracts are currently included in test-zappify but not test-zapp. Ideally, we would include them in test-zapp but every contract added to api-test adds significantly to the memory required, which is already close to the limit, and adds time to the testing. This is why only a small group of our test contracts are included in user-friendly-tests (which are tested in test-zapp). Because, Booleans.zol is inside action-tests I felt that this was also appropriate for Bytes20.zol

[lydiagarms]

this PR only updates STATUS. Please add a README update for bytes20 support

I don't think supported variable types are explicitly discussed in README, instead there is a link to STATUS,

[kKahina]

you add a Bytes20 contract, but there is no dedicated callZAppAPIs('Bytes20', ...) flow in apitest. Current coverage validates transpilation, not end-to-end runtime behavior for bytes20 (API + commitments + backup/retrieval). Please add a focused integration scenario.

The two contracts are currently included in test-zappify but not test-zapp. Ideally, we would include them in test-zapp but every contract added to api-test adds significantly to the memory required, which is already close to the limit, and adds time to the testing. This is why only a small group of our test contracts are included in user-friendly-tests (which are tested in test-zapp). Because, Booleans.zol is inside action-tests I felt that this was also appropriate for Bytes20.zol

agreed on the test-zapp memory/time constraints. I’m not asking to move Bytes20 into test-zapp. My concern is specifically that we still don’t have a dedicated runtime E2E flow for Bytes20 in apitest via callZAppAPIs('Bytes20', ...); right now coverage appears mostly transpilation-level. Could you add that focused scenario in test-zappify/action-tests so we also validate real API behavior plus commitment persistence and backup/retrieval for bytes20

[kKahina]

Good

[SwatiEY]

looks good thanks for screenshots

[github-actions]

🎉 This PR is included in version 1.10.6 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀