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

Improve the way we retrieve the address of a deployed SC #4823

Open
peterjah opened this issue Jan 15, 2025 · 1 comment
Open

Improve the way we retrieve the address of a deployed SC #4823

peterjah opened this issue Jan 15, 2025 · 1 comment

Comments

@peterjah
Copy link
Collaborator

Today when you deploy a new contract we use executeSC with a contract calling the createSC() Assemblyscript function.
Then there is nothing to get the address of deployed contract.
What is done today to handle this:
the deployer SC emit an event containing the SC address.

Imho this is really ugly because we have to rely on the event string and can lead to various problems like collision with others user defined events.

Proposed solution 1:
Having a new field in event 'eventType'. types could be userEvents or SystemEvents.
A call to the createSC() could emit a systemEvent containing the address.
Some errors could also be of type of systemEvents.
Of course each SystemEvent should have an eventID so we can directly know which event it is without parsing the string...
This will also greatly improve our capacity of handling Smart contract errors.

Proposed solution 2:
when createSC() ABI is called, get the SC address.
Include the Deployed SC address somewhere in the api. by instance adding a new filed in "get_operations" that list the new SC created by the operation

@damip
Copy link
Member

damip commented Jan 15, 2025

I like the SystemEvent option.
But I like the other one you proposed here even more: #4767 : applied to returning the deployed address from the function deploying the SC

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

No branches or pull requests

2 participants