atomic contract init

[tribal kindle]

As part of removing multi invoke, what's the new recommendatio for how to do deploy and init atomically and efficiently?

We'd discussed the possibility of a built in contract for doing multi invoke, are we doing that?

Or is the recommendation to deploy a factory?

[noble frost]

for preview 10 anyone can write a deployer contract

we may or may not implement it as a built-in for testnet

it doesn't need to be a factory; it can just be a stateless contract that does something like (roughly):

fn deploy(env: Env, deployer: Address, salt: BytesN<32>, init_fn: Symbol, init_args: Vec<Val>) {
  deployer.require_auth();
  let id = env.deployer().with_address(deployer, salt).deploy();
  env.call(id, init_fn, init_args);
}

this guarantees atomicity for any deployer address, not just tx invoker

[tribal kindle]

I don't think the api supports deploying with another address?

So likely a factory provides more determinism.

[noble frost]

it does

in preview 10, that is

[hardy orbit]

are constructors coming in 10 by any chacne

[noble frost]

nope, but you can DIY a deployer contract (see above)

[hardy orbit]

yeahh i have one i don't see anything different about that

was just asking about constructors on the off chance it was coming 😄 but what do you mean removing multi-invoke?

[noble frost]

it works generically with any address. it's not possible to do atomic initialization if you deploy a contract on behalf of an account in preview 9

multi-invoke is gone for the same reason we don't have constructors: we can't generically fulfill the all the possibile atomicity requirements

e.g. you may want your sequence of ops to be atomic, but that's only possible if you only use invoker auth

the constructor situation is similar - there can be constructors that would be front-runnable and we don't really want to build something like that into protocol. e.g. a deployer example above explicitly protects the constructor from front-running when only 1 party (deployer) is involved. but if you have more sophisticated initialization scheme, you could write a custom deployer for that as well

we might still provide some built-in stateless contracts that cover the common scenarios, but that would be much simpler from the protocol standpoint (these are still just contracts)

[hardy orbit]

when you say multi-invoke was that passing more than one invoke in one operation? or will it basically be that only one invoke per transaction?

personally i no longer think we need constructors tbh, now that i've learned ways to make what i need...

[noble frost]

you can only have a single invoke host function op per transaction. however, there won't be anything you can't do from a contract (well, there might be some gaps related to rent bumps, but that's still largely covered)

[hardy orbit]

I was never able to get a transaction with multiple invoke host ops to go through so i don't think it'll really matter to me, plus i found that the easiest way to do multi invokes is by having a contract that acts as an intemediary

sounds like my architecture already fits the new system 😆 i lucked out for once

tho i'll still have to deep dive storage, rent, expiration, retrieval, etc