Add Constructor Support to Soroban

[salaheldinsoliman]

This is a bit of a story rather than a formulated argument:

While working on Hyperledger Solang (Solidity compiler to wasm target), to support a simple Solidity contract:

contract counter {
    uint64  count = 1;

    function increment() public returns (uint64){
        count += 1;
        return count;
    }

    function decrement() public returns (uint64){
        count -= 1;
        return count;
    }
}

The compiler here has to loop over the storage variables and insert instructions that initializes them. The function that does so, let's call it init_storage, has to be called manually by a Soroban Solidity dev (which is not what a Solidity dev would expect).
If Soroban supports constructors, that is, a function that is called automatically upon a contract instantiation, then init_storage could be called from the constructor (the compiler will insert init_storage instructions under the hood).

Another reason I have found, for supporting constructors, is this:
In https://github.com/stellar/soroban-examples/blob/main/increment/src/lib.rs
In the increment contract, each and every retrieval of the counter key would require the developer to return the value the counter is indented to be initiated with throughout the code, making it repetitive.

What do you think?

[leighmcculloch]

I have seen other examples where a constructor would simplify a contract. One example is the smart wallet contract that @kalepail wrote (#1499) that is two contracts and requires a factory to ensure it is initialised and setup appropriately. Support for constructors that carry a set of required inputs would reduce that contract to one.

[dmkozh]

We have excluded constructor from the initial Soroban release due to auth-related difficulties, that we've actually solved prior to protocol 20 release. Currently I don't see any technical issue with adding that.

In terms of implementation approach, I've considered a built-in factory contract at some point, but I don't think that solves the issue raised here. So, I think we can just proceed with extending the contract creation functionality (host functions/XDR operation) to accept additional arguments.

The change should be reasonably simple and we should be able to sketch a CAP for that pretty quickly.

[leighmcculloch]

There are some design and implementation questions to figure out.

A single constructor is probably trivial as it'll just be one new underscore function such as _ctor. We should support parameters, otherwise folks would still be stuck using factories when initialisation and setup with parameters was required.

Another issue is one vs many constructors. Solidity supports multiple constructors where each can receive different parameters. If we intend to support same then we need to give each constructor a unique name because WASM and Rust don't allow us to specify multiple functions with the same name, so if we wanted to support multiple those functions would need to have different names.

[dmkozh]

We should support parameters

Sure, that's what I meant by 'extending the contract creation to accept arguments'. That should be easy to support.

Another issue is one vs many constructors.

That's a more serious issue. While we could design for multiple constructors, I wonder if it's possible to emulate routing via the arguments of a single constructor (like passing an enum with different args tuple into a single constructor). That would have much cleaner implementation on the protocol side, so I'm interested what does @salaheldinsoliman think about that in scope of Solidity compiler.

[leighmcculloch]

Actually, I'm wrong, Solidity only supports a single constructor at the contract level. I'm not sure why I thought it could appear overloaded, I'm sure I saw an example of this once, but the docs clearly say that isn't supported. Ref: https://docs.soliditylang.org/en/develop/contracts.html#creating-contracts

[dmkozh]

That's good, then it doesn't seem like there are any significant design questions to solve.

[salaheldinsoliman]

@leighmcculloch I think the example you saw was in Solang
Polkadot pallet contracts support multiple constructors, So Solang's Solidity dialect also supports that, here is an example:
https://github.com/hyperledger/solang/blob/main/tests/contract_testcases/polkadot/functions/constructor_override_04.sol

@dmkozh
Regarding Soroban, I think support for multiple constructors would be unnecessary at this point. The main idea was to:
1- Support automatically initializing storage (In Soroban's Solidity)
2- Make the contracts more "intuitive" to a developer
3- Simplifying contracts

And the 3 points are covered by single constructor support.

[leighmcculloch]

Reading CAP-58@50dde06 (#1505):

Specification

...

Semantics

Constructor function

...
If a contract without constructor has any constructor arguments passed to it (even a 0-size vector), the instantiation fails

I think this design decision needs some discussion.

I think it will reduce the ergonomics. It will be surprising because in most programming languages that have constructors, there is no distinction between a lack of a constructor, and a constructor with zero arguments.

A zero parameter constructor is largely an implementation detail, something that can be added or taken away with no impact.

If a contracts wants to upgrade to use a zero-parameter constructor, or upgrade and remove a zero-parameter constructor, that change will be a breaking change. And a non-obvious breaking change that will break any existing deployers.

Security Concerns

...
Executing __init function from within host allows contracts to execute arbitrary logic while being called from a host function. However, the risk surface is not really increased compared to regular contract calls, as the caller acknowledges that constructor will be called, similarly to how the caller acknowledges that a different contract's method is going to be called.

What is the security issue of a zero-parameter constructor being called? No auth will be supplied unless the user specifically signs for auth for the constructor. Contract invocations in transactions do not capture the intended call tree so any invocation can always result in the invocation of contracts unexpected. When a contract calls another contract the calling contract has no control over whether the called contract calls on to other contracts and those additional calls can execute arbitrary code. Calling deploy and having a zero parameter constructor be called seems no different.

If the issue is that we need to preserve for contracts that exist today that their deploy calls will never call a constructor because the developers didn't know it would be possible, we could disallow calling contracts with constructors for contracts built with v21 or earlier and that would harm the ergonomics less.

[dmkozh]

It will be surprising because in most programming languages that have constructors, there is no distinction between a lack of a constructor, and a constructor with zero arguments.

That's true, but programming languages also don't require signing the constructor calls. I'm not feeling too strongly about that, but I decided to start with a more conservative proposal that makes it impossible to confuse creating a constructor-less contract with creating a contract with 0-arg constructor from the signer standpoint. If we deem the risks of such confusion low and unimpactful (which they very well could be), we could converge these cases into one.

If a contracts wants to upgrade to use a zero-parameter constructor, or upgrade and remove a zero-parameter constructor, that change will be a breaking change

Wasm is immutable, so not sure what sort of upgrade do you mean here. But I suppose for the factory contracts it will be necessary to distinguish between creation with and without constructor.

No auth will be supplied unless the user specifically signs for auth for the constructor.

As I've mentioned above, that depends on whether we think that making signing the creation without constructor and with 0-arg constructor to be the same from the authorization perspective.

If the issue is that we need to preserve for contracts that exist today that their deploy calls will never call a constructor because the developers didn't know it would be possible, we could disallow calling contracts with constructors for contracts built with v21 or earlier and that would harm the ergonomics less.

Yeah, that seems like a viable option if we remove the auth difference.

[leighmcculloch]

makes it impossible to confuse creating a constructor-less contract with creating a contract with 0-arg constructor from the signer standpoint

Could you elaborate on how signing for the constructor would be confusing? These are the situations I'm aware of:

• Contract with no constructor, auth wouldn't contain anything about a constructor.
• Contract with a zero parameter constructor and no require auth within the constructor, auth wouldn't contain anything about a constructor.
• Contract with a zero parameter constructor and a require auth within the constructor, auth would contain the constructor

As far as I understand the user only signs for the third case, and in that case it shouldn't be ambiguous to what they're signing for because the constructor will be explicitly included in the auth tree.

What am I missing?

[dmkozh]

These are the situations I'm aware of:

These situations are not quite correct. Constructor arguments are a part of createContractV2HostFn variant of SorobanAuthorizedFunction (see CAP). It doesn't really matter whether there are require_auth calls inside the constructor; the address that authorizes creating the contract has to authorize the constructor call in order to ensure atomicity. I agree that the question of whether the signer should be concerned about signing 0-arg constructor call vs no constructor call at all is debatable. In theory, a user could be confused and e.g. instantiate a contract using a 'legacy', constructor-less Wasm instead of a new one with 0-arg constructor. But that situation doesn't appear likely or severe because it assumes confusing the Wasm hash as well (which is a much bigger problem that's nothing to do with constructor). So I lean to agree with you, but I'd leave this as is until the protocol discussion, then if no-one has concerns we can make this simpler.

[leighmcculloch]

Reading CAP-58@50dde06 (#1505):

The proposal doesn't discuss what should happen with upgrades, and it should probably speak on that even if the answer is nothing and that constructors do not get called on upgrades.

However, whether a constructor should be called or not during an upgrade is not obvious to me. Both calling or not calling a constructor for upgrades could make sense depending on the circumstances.

If I fix a bug in an existing contract and upgrade, the upgrade likely wouldn't need the constructor to be executed.

However, if I have a smart wallet account and I want to entirely replace my smart wallet contract with a new contract, then it might be imperative that the constructor runs.

Introduce 'constructor' feature for Soroban smart contracts: a mechanism that ensures that the contract will run custom initialization logic atomically during instantiation.

This guarantee ☝🏻 can't be guaranteed for all contract instantiations due to upgrades, which weakens the overall guarantee it provides. It's not possible to look at the current network state and say for sure that the constructor of a contract has been run because the code may have been installed by upgrade.

[dmkozh]

The proposal doesn't discuss what should happen with upgrades, and it should probably speak on that even if the answer is nothing and that constructors do not get called on upgrades.

Yes, sorry, I've thought about that but forgot to add here. I think upgrades should not do anything about constructors.

However, if I have a smart wallet account and I want to entirely replace my smart wallet contract with a new contract, then it might be imperative that the constructor runs.

Compared to all the footguns that reinitialization brings, I think this is not a big issue. I think most of the time atomicity is not as critical as in the initialization case (as you remain the owner of the contract), but if we want to support this case better, we need another hook (say __on_update()) that is called after the update. This will prevent the confusion between initialization and upgrades and is also much simpler as it doesn't need to be authorized separately, unlike the constructor.

This guarantee ☝🏻 can't be guaranteed for all contract instantiations due to upgrades,

I think upgrade is not instantiation, is it? I guess it's rather a terminology question.

t's not possible to look at the current network state and say for sure that the constructor of a contract has been run because the code may have been installed by upgrade.

That's true; one needs to know what was the first Wasm used for instantiation. I'm still not sure if it invalidates my statement, as it only implies that constructor is guaranteed to run for the contract instantiation, but doesn't imply that a contract has run constructor if its current source has it. But probably we could explicitly state that this implication is not true.

[dmkozh]

I've updated the CAP with the update-related information: #1506

[leighmcculloch]

Starting with constructors only on create seems reasonable. We can add additional hooks in a future version if evidence indicates its needed.

I wonder if we should use the __on_ prefix in general and name the constructor __on_create and present it more like a hook. It may make it slightly less ambiguous to when a constructor is called in terms of the upgrade case since it's more obvious that the contract is not being created in that case. I don't feel strongly.

[dmkozh]

I wonder if we should use the _on prefix in general and name the constructor __on_create and present it more like a hook. It

I don't mind that. We can discuss naming during the protocol meeting.

[dmkozh]

I've put together a table that covers the constructor behavior depending on the constructor presence, number of arguments, and the 'create contract' call arguments. This covers the idea of relaxing the requirements expressed above. I'll merge this into CAP if we came to an agreement about that not introducing any significant vulnerabilities.

There is also an issue that I've noticed while sketching a prototype implementation. Unfortunately, AuthorizationContext that we use for __check_auth and InvokerContractAuthEntry that we use for authorize_as_curr_contract aren't extensible in a backwards-compatible fashion. The main consequence is that the old custom accounts won't be able to authorize any contract creation operations in the new protocol. We'll need to discuss this issue in more detail in the protocol meeting as well, and then I'll document the decision in CAP.

[leighmcculloch]

Reading CAP-58@f0a26bc (#1523):

• Line 121 discussing return values:

  • Returning any value that is not Val::VOID will result in error and contract won't be instantiated.

    The last sentence is ambiguous as to the state of the deployment and what happen when instantiation fails. It says that the contract won't be "instantiated," but we don't happen to use that term elsewhere so I want to make sure everyone fully understands what that means. The docs and code typically refer to contract being "created" or "deployed". I presume by instantiated it means the contract won't be deployed or created, but I just want to check that, is that what it means?

  • The paragraph on Line 121, and later Line 221, discusses return values, but not error handling. Can we define the following?

    • Can constructors call panic_error!(...)?

      • If yes, what happens to the error? Is it given to the contract acting as the deployer where they can then choose to fail their invocatio or not in the same way that invocations and sub-invocations work?
      • If no, what happens, does the entire tx fail in this case and the error just shows up in diagnostic logs, but otherwise isn't used?

    • Can constructors return errors? E.g. Result<(), ...> Returning errors is the same as calling panic_error!.

    • In all these cases what does a contract, acting as a deploy, see?

• Line 221:

  an improperly typed contract error might get discarded and contract might get instantiated even though the developer intention was to rollback

  Could you share an example of what an improperly typed contract error looks like? I'm struggling to picture the problem example from the text.

  Any error returned/generated by a contract function causes rollback of the errored invocation and any sub-invocations, but not necessarily parent invocations. I would have thought same could be true during deployment.

  Any issues with improperly typed contract errors would also apply to invocations, so I'm hesitant to think there's something unique to constructors here.

  Is it that failing constructors fail the entire transaction exclusively and there's no way for a deployer to handle a constructor error?

[dmkozh]

I presume by instantiated it means the contract won't be deployed or created, but I just want to check that, is that what it means?

Yes, I'll try to rephrase this for the sake of clarity.

Can constructors call panic_error!(...)?

Sure, that's just a regular function and it can panic or return errors. In either case it will be considered to have failed.

If yes, what happens to the error?

It causes the create_contract host function to fail. The error can be logged in diagnostic events. We currently don't provide a version of create_contract that returns an error. In theory, we could, but in general host functions that return errors are much harder to maintain than the regular host functions, so I would only go for that if there is a good use case.

In all these cases what does a contract, acting as a deploy, see?

This behaves as any other host function - a failure causes the current stack frame to rollback without returning control to the contract. It is not different from the current behavior - e.g. if one tries to call create_contract for an already existing contract, the host function will fail and cause the current invocation to rollback.

Could you share an example of what an improperly typed contract error looks like? I'm struggling to picture the problem example from the text.

I mean a contract returning e.g. a bool or an integer - since the host only has 2 options for dealing with the return values (either ignore, or fail), I would rather err on the side of precaution and prohibit any custom return values as these might have been returned with incorrect expectations. But I see how the current specification is confusing - when writing this I was not including the 'proper' errors (Err(...)) as a case for the return value. Basically this was written with 'return value when invocation succeeds' in mind. I'll make another update to make this more clear.

[dmkozh]

Clarified the CAP in #1527

[leighmcculloch]

If yes, what happens to the error?

It causes the create_contract host function to fail. The error can be logged in diagnostic events. We currently don't provide a version of create_contract that returns an error. In theory, we could, but in general host functions that return errors are much harder to maintain than the regular host functions, so I would only go for that if there is a good use case.

I think it's possible someone could want to handle constructor failure, but also it is very easy to add a try_ version later if we discover we need it. 👍🏻

[leighmcculloch]

Re CAP-58@4502e34:

SOROBAN_AUTHORIZED_FUNCTION_TYPE_CREATE_CONTRACT_HOST_FN deprecation

In order to prevent signature malleability, an auth payload has to match to a specific action (e.g. we can't just accept both v1 and v2 payloads to authorize CREATE_CONTRACT_HOST_FN). So SOROBAN_AUTHORIZED_FUNCTION_TYPE_CREATE_CONTRACT_HOST_FN has to be used in some very specific contexts and it's not immediately obvious for the user why in certain context v1 has to be used vs why v2 should be used. That's why for the sake of clarity we deprecate SOROBAN_AUTHORIZED_FUNCTION_TYPE_CREATE_CONTRACT_HOST_FN in protocol 22.

Since most of the Soroban interactions happen via RPC simulation, we don't expect significant client discruption. However, the RPC clients will have to update their XDR definitions in order to be able to handle the new varint of the auth payload.

There is also a small chance that a transaction gets rejected when being applied right after the upgrade, but that's an improbable and one-time event (contract instantiations are much more rare than regular contract interactions).

Comments here follow on from my question in Discord (ref) on the same topic.

We resolved previously to make zero-parameter constructors an implementation detail, which means any caller shouldn't need to know or do anything different to deploy a contract with no ctor vs a contract with a zero-parameter and zero-auth ctor.

However the above deprecation will cause deployments with zero-parameter ctors to fail.

Tooling and SDKs don't build deployment operations by first calling out to the internet to figure out which protocol version is in use to know to use v2 for all deployment, and aren't required to inspect contracts or parse the wasm being deployed to know if they have a zero parameter ctor. This means that the CLI, Lab, SDKs, will build any deployment that isn't accompanied by parameters as a protocol 21 style deployment so that someone with a v22 CLI will work on protocol 21. It's not ideal for tooling to have to poll the network to figure out when to switch behavior to use v2 for everything, or to have to contain a wasm parser to open up the wasm and figure out if there is a zero-parameter ctor inside.

Some tooling is used offline to produce these txns too which makes this more difficult.

In order to prevent signature malleability

Can an example of signature malleability be shared? I'm not seeing how a signature could be malleable.

[dmkozh]

Basically, without considering if this may or may not cause security issues, I don't think we want to support ambiguous signature verification logic just purely from the technical standpoint. Making it non-ambiguous also seems unnecessarily complex and confusing. Like we could require auth payload v1 only for the explicit calls to the v1 host function, but then we break the existing compatibility with create_contract host fn and again someone may be in theory broken. It also makes building transactions manually more complex in the future as one would need to reason about which auth payload to use in which call scenario.

I don't think this really will be the issue for the most users, as it's kind of tricky to do things without simulation (e.g. CLI does use simulation). Even for those who don't use simulation, it doesn't seem like updating an XDR struct is too big of an ask for a protocol upgrade.

[leighmcculloch]

I agree for most users who use simulation this is likely to go unnoticed.

On review of the CLI this won't have any impact to CLI users, even those that pre-prepare their txns pre-simulated ahead of time, because a contract with a ctor can't be simulated for v22 until after v22 is voted on.

In the past we've been hypersensitive to breaking changes because there's no way to tell how someone might be using the network in an offline protocol. This seems like a first where we can break something because we expect its use to be largely automated, coupled with it being difficult to even pre-prepare a tx that would experience the break.

I guess we should just make it really clear to everyone evaluating / accepting the change the breaking change exists in case there's some impact short or long term not being considered.

[leighmcculloch]

My previous comment is slightly incorrect, I thought that the rejection was only for contracts with ctors (zero or any number of param), but I understand now after reading #1352 again, that the existing XDR type for auth ceases to work at all for any contract deployment regardless of whether that deployed contract has a ctor or not.

That does mean CLI users or JS SDK users are potentially impacted, if they simulate/prepare any deployment tx and submit it later, it'll fail during apply.

[dmkozh]

After reflecting on this for a bit, I came to conclusion that there are seemingly no logical issues with supporting v1 payload (FWIW my initial thinking was that we might need to deal with verifying different payloads for the same signature; that's not what we do, shame on me for not recalling what my code does). Since we don't think there are legitimate security concerns, I've removed the notes on v1 payload being not supported and modified the code respectively.

On a more philosophical note, support of the old pre-built transactions is still not something we can guarantee for Soroban (due to resource cost changes), but I agree that we should reduce the friction if it's possible. At least resources can be overestimated if absolutely necessary.

[MonsieurNicolas]

ok great @dmkozh . yeah it makes it easier from a rollout point of view: offline protocols need to overestimate resources/fees anyways, but this was a real breaking change that would have to be communicated more broadly "just in case"