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

Write a design doc for prepare cheatcode #63

Closed
Tracked by #395
cptartur opened this issue Jul 6, 2023 · 2 comments · Fixed by #387
Closed
Tracked by #395

Write a design doc for prepare cheatcode #63

cptartur opened this issue Jul 6, 2023 · 2 comments · Fixed by #387
Assignees
Labels
feature New feature request/description

Comments

@cptartur
Copy link
Member

cptartur commented Jul 6, 2023

Create a design document for prepare cheatcode or alternative solution.

@cptartur cptartur added this to the Forge milestone Jul 6, 2023
@cptartur cptartur moved this to Backlog in Starknet foundry Jul 6, 2023
@cptartur
Copy link
Member Author

We should write a design doc for this first

@cptartur cptartur removed the blocked label Jul 25, 2023
@cptartur cptartur changed the title Investigate Prepare cheat code in rust and update Deploy logic #1991 Write a design doc for prepare cheatcode Jul 25, 2023
@cptartur cptartur added the feature New feature request/description label Aug 1, 2023
@cptartur cptartur moved this from Backlog to TODO in Starknet foundry Aug 1, 2023
@cptartur
Copy link
Member Author

cptartur commented Aug 2, 2023

Usecases for having the prepare cheatcode or equivalent:

  • knowing the address of the contract so it can be pranked - pranking the constructor
  • tests that somehow depend on knowing the contract address

In my opinion the current flow with just declare and deploy provides a nice UX and makes sense for most starknet developers - on real network you also have to first declare then deploy.

I'd avoid requiring the user to do prepare between these steps - this is how it was done in protostar. I think we should provide a way of precalulcating the address in case the user needs it, but without enforcing this calculation to do any kind of deployment.

What's problematic is for this precalculation to work, addresses would have to be deterministic: This is possible, but would then limit the user to only having one instance of a given contract. Perhaps this could be solved by using some kind of internal "counter" that would be incremented on every deployment and used as a salt for contract address. This way the address would could be precalculated without requiring the user to do so before every deployment.

@cptartur cptartur self-assigned this Aug 3, 2023
@cptartur cptartur moved this from TODO to In Progress in Starknet foundry Aug 3, 2023
github-merge-queue bot pushed a commit that referenced this issue Aug 4, 2023
<!-- Reference any GitHub issues resolved by this PR -->

Closes #63

## Introduced changes

<!-- A brief description of the changes -->

- Add design document discussing and proposing a solution in place of
`prepare` cheaatcode.

## Breaking changes

<!-- List of all breaking changes, if applicable -->

## Checklist

<!-- Make sure all of these are complete -->

- [x] Linked relevant issue
- [x] Updated relevant documentation
- [x] Added relevant tests
- [x] Performed self-review of the code
- [x] Added changes to `CHANGELOG.md`

---------

Co-authored-by: Piotr Magiera <[email protected]>
@github-project-automation github-project-automation bot moved this from In Progress to Done in Starknet foundry Aug 4, 2023
Utilitycoder pushed a commit to Utilitycoder/starknet-foundry that referenced this issue Oct 6, 2023
* update to alpha.4

* add corelib

* comment out breaking changes exercises

* fix options3 exercise toward alpha.4

* use integers instead of felt for some exercises

* fix options1 and struct3

* update(alpha4): address PR review

---------

Co-authored-by: msaug <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature request/description
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants