Skip to content

[Feature] Support program_owner as an operand. #2717

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

Open
wants to merge 5 commits into
base: feat/program-updatability
Choose a base branch
from

Conversation

d0cd
Copy link
Collaborator

@d0cd d0cd commented May 18, 2025

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

This PR:

  • adds the owner Address to the Deployment and enforces that it exists and is well-formed after the migration height.
  • requires the constructors exist in all programs after the migration height.
  • introduces Operand::ProgramOwner to programs.
  • accounts for program editions in partially_verified_transactions to handle upgrades.

Operand::ProgramOwner

  • A program can reference its owner and other owners with the syntax program_owner and credits.aleo/program_owner respectively.
  • The operand is only available in a constructor and finalize scope.
  • Programs deployed before ConsensusVersion::V5 do not have a program owner, including credits.aleo.

Open Items

  • Discussion. Can the Merkle root of the transaction be cached?
  • Implementation. Hold process lock over the duration of check_transaction.
  • Discussion. Consider program.owner or this.owner or enforcing <this_program.aleo>/owner to unify operands over program metadata.

@d0cd d0cd mentioned this pull request May 18, 2025
21 tasks
@d0cd d0cd requested review from vicsn and raychu86 May 18, 2025 15:00
@@ -91,7 +91,7 @@ impl<N: Network, C: ConsensusStorage<N>> VM<N, C> {

// Compute the Merkle root of the transaction.
// Debug-mode only, as the `Transaction` constructor recomputes the transaction ID at initialization.
#[cfg(debug_assertions)]
// Attention - This check is mandatory. This is the only way to ensure that the transaction ID is well-formed.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Earlier reviews had concerns with keeping and removing this check.

For keeping. Transaction contents can be modified, which would result in an incorrect transaction ID.

Against keeping. The constructors from_deployment and from_execution recompute the transaction ID at initialization, which involves computing the root of the transaction tree. We know from manual code review that validators use those constructors. Removing this check was needed to scale up the validator set.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On looking through the code again, I could not find any constructors that did not recompute the root. If that's the case, then an ID for a Transaction in memory is correct-by-construction for an honest validator.

@reviewers do you agree?

Tangent. I noticed that get_transaction on the Ledger performs this check, making it a pretty expensive operation to do, especially for our REST API.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well for the public record, I agree, but you knew :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants