Skip to content
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

optimize the stack placement of constructor params (at first usage instead of at the beginning) #217

Open
mr-zwets opened this issue Oct 14, 2024 · 0 comments
Labels
cashc-compiler Relates to the cashc compiler
Milestone

Comments

@mr-zwets
Copy link
Member

Instead of placing all contructor params at the beginning of the contract, the compiler could auto-insert the params at first usage. This would be a nice default, resulting in optimized contracts with limited extra complexity for the compiler. Stack juggling the constructor parameters will likely become a bigger overhead with the increased VM Limits CHIP.

Changing the placement of constructor variables would be a breaking change but if it can be bundled together with other compiler changes, then it is not too bad that compatibility is broken as CashScript is still evolving and improving.

This could be a nice optimisation. There's also some advantages to keeping them at the start with e.g. simulated state. I think it's also easier to use compiled CashScript contracts outside of the official SDK if the constructor args are at the start.

Simulated state is a pretty niche use-case now after CashTokens and developers using it already need to be aware of many intricacies

            // Cut out old initialBlock (OP_PUSHBYTES_8 <initialBlock>)
            // Insert new initialBlock (OP_PUSHBYTES_8 <tx.locktime>)
            // Note that constructor parameters are added in reverse order,
            // so initialBlock is the first statement in the contract bytecode.
            bytes newContract = 0x08 + bytes8(tx.locktime) + this.activeBytecode.split(9)[1];

            // Create the locking bytecode for the new contract and check that
            // the change output sends to that contract
            bytes23 newContractLock = new LockingBytecodeP2SH(hash160(newContract));
            require(tx.outputs[1].lockingBytecode == newContractLock);

For simulated state there could be a way to explicitly opt-out of this compiler optimizations. ChatGPT suggested a keyword anchor

contract Mecenas(
    bytes20 recipient,
    bytes20 funder,
    int pledgePerBlock,
    anchor bytes8 initialBlock  // Ensures `initialBlock` is placed at the start of the bytecode for simulated state purposes.
) {
@mr-zwets mr-zwets modified the milestone: breaking compiler changes Oct 14, 2024
@mr-zwets mr-zwets added the cashc-compiler Relates to the cashc compiler label Oct 14, 2024
@mr-zwets mr-zwets added this to the v1 milestone Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cashc-compiler Relates to the cashc compiler
Projects
None yet
Development

No branches or pull requests

1 participant