[Feature] Introduce constructor, Operand::Checksum and Operand::Edition

[d0cd]

[NO NEW COMMITS ARE ALLOWED AS OF 5/27/25]

DO NOT MERGE WITHOUT AUDIT

Motivation

This PR introduces:

• constructors to programs. Constructors are blocks of code that are run on-chain when finalizing a deployment.
• Operand::Checksum. An operand that returns a field element containing the program's checksum. The checksum is defined as the BHP1024 hash over the program's bits.
• Operand::Edition. The edition for the program. This is currently enforced to be N::EDITION (0) for all programs.

Note: The keyword constructor is now restricted after ConsensusVersion::V6 by this PR. This is enforced at the consensus-level as opposed to the program-level to ensure backwards compatibility.

Test Plan

Integration test cases were added to verify:

• that a program is not deployed if its constructor fails.
• a constructor can set a value in a mapping and that the new operands are functional.

Regression tests were re-ran to verify that the changes to the execution cost calculations do not affect existing programs.

[howardwu]

Auditors: The parameters used to initialize the FinalizeRegisters here should be reviewed for correctness and soundness.

[vicsn]

@d0cd make sure to go over all unresolved comments and copy them over in the new PR you're making.

[d0cd]

Gonna keep this PR, but I think we're all resolved in this one no?

[acoglio]

The parsing looks good. These are matching changes to the ABNF grammar:

operand = ...
        / program-id ; if not followed by "/"
        / [ program-id "/" ] %s"checksum"
        / [ program-id "/" ] %s"edition"
        / ...

constructor = cws %s"constructor" ws ":" *command

program = ...
          1*( constructor / mapping / struct / record / closure / function )
          ...

According to some discussion in this PR, we expect a change of the new rule to

constructor = cws %s"constructor" ws ":" 1*command

i.e. at least one command in a constructor.

[acoglio]

I just reviewed the parsing code.

[ljedrz]

Reviewed the engineering aspects, left a suggestion.

[d0cd]

Can you make an issue drafting documentation for the constructor and new opcodes, ignoring program upgradability for now: https://github.com/aleoNet/welcome/issues/new

@vicsn since we'd like to do updatability all in one go, does it make more sense to add docs at once?

[howardwu]

@vicsn @d0cd -- pushing back on removing the reservation of keyword constructor.

It is easy to remove the restriction in the future, however it is difficult to introduce later.

I would advocate for adding it even sooner to "bookmark" it in an earlier release to this feature if possible.

[d0cd]

@vicsn @d0cd -- pushing back on removing the reservation of keyword constructor.

It is easy to remove the restriction in the future, however it is difficult to introduce later.

I would advocate for adding it even sooner to "bookmark" it in an earlier release to this feature if possible.

If it is to be added, then +1 on adding it sooner.
Currently, there are no programs on testnet or mainnet that contain the keyword constructor (scanned as of 12PM PST 4/15/25)
The process of reserving this keyword will be challenging. Some options included a (nearly) synchronous upgrade of quorum, or versioning the reserved keywords before and after an upgrade height. The fundamental issue is that there is nothing preventing the use of the keyword ATM.

[vicsn]

@vicsn @d0cd -- pushing back on removing the reservation of keyword constructor.

The process of reserving this keyword will be challenging. Some options included a (nearly) synchronous upgrade of quorum, or versioning the reserved keywords before and after an upgrade height. The fundamental issue is that there is nothing preventing the use of the keyword ATM.

The benefits of rushing in a synchronous upgrade are limited, let's add it to Consensus V6 (see the PR description for release dates). @d0cd can you make:

• a snarkVM PR introducing the constructor keyword
  - a snarkOS PR disallowing deployments containing that keyword (similar as proposed here). Note that even if a deployment with that keyword exists before V6, users can continue to create executions for it, so its not detrimental to UX.

[d0cd]

The benefits of rushing in a synchronous upgrade are limited, let's add it to Consensus V6 (see the PR description for release dates). @d0cd can you make:

* a snarkVM PR introducing the `constructor` keyword

* a snarkOS PR disallowing **deployments** containing that keyword (similar as [proposed here](https://github.com/ProvableHQ/snarkOS/pull/3587#issuecomment-2788586686)). Note that even if a deployment with that keyword exists before V6, users can continue to create executions for it, so its not detrimental to UX.

See this PR.

[d0cd]

Closed in favor of #2807