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

Module constructors #93

Closed
ureeves opened this issue Oct 11, 2022 · 2 comments
Closed

Module constructors #93

ureeves opened this issue Oct 11, 2022 · 2 comments
Assignees
Labels
mark:next Strategic issues related to next versions of Testnet and mid/long term plans team:Core Low Level Core Development Team (Rust) type:feature implementing a new feature

Comments

@ureeves
Copy link
Member

ureeves commented Oct 11, 2022

Summary

There should be a way to provide modules some data on deployment, which is then used to initialize the state. Currently it is only possible to "bake in" the initial state in the WASM bytecode. This precludes the module writer from writing a module once, and then reusing the same bytecode with different initial states. This use-case should become possible.

Possible solution design or implementation

It could be possible to check the existence of a such a module constructor by interpreting the module exports. If an export exists with a predefined name and signature, this could then be called with a piece of data provided by the deployer through the argument buffer. An example name and signature could be:

#[no_mangle]
fn ctor(pos: i32) {
    // ...
}

The pos argument would be the length of the argument in the buffer. The contract would then deserialize (possibly using rkyv) the piece of data and proceed with initialization.

This has to be accompanied with a mechanism that disallows the constructor to be called more than once.

Additional context

Not only is this a useful mechanism for prospective smart contract writers, it's also extremely useful to construct multiple networks with different types of genesis data, given that different networks are defined by differently initialized genesis contracts.

@ureeves ureeves added team:Core Low Level Core Development Team (Rust) type:feature implementing a new feature mark:next Strategic issues related to next versions of Testnet and mid/long term plans labels Oct 11, 2022
@miloszm
Copy link
Contributor

miloszm commented Feb 24, 2023

name should be new or instantiate, arguments are optional

@miloszm miloszm self-assigned this Mar 7, 2023
@ureeves ureeves mentioned this issue Apr 6, 2023
@ureeves
Copy link
Member Author

ureeves commented May 9, 2023

Closed by #168

@ureeves ureeves closed this as completed May 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mark:next Strategic issues related to next versions of Testnet and mid/long term plans team:Core Low Level Core Development Team (Rust) type:feature implementing a new feature
Projects
None yet
Development

No branches or pull requests

2 participants