Extend Koba Auth to Support Non-Local Signers

[emnul]

At the moment koba expects private keys to reside on the local file system, while this works for most use cases it doesn't account for cloud based signers or hardware wallet signers. I propose modifying the deployer::deploy function signature as follows:

pub async fn deploy(config: &Deploy, signer: Option<Signer>) -> eyre::Result<TransactionReceipt> 

Signer will take precedence over config.auth. Modifying the function signature in this way enables CLI users to continue using koba without any breaking changes and allows the use of custom signers for library users.

Happy to implement!

[alexfertel]

Hey @emnul ! Thanks for opening the issue.

At the moment koba expects private keys to reside on the local file system

Could you expand on why this is the case? I don't think we make any assumptions as to where the pk comes from, and indeed it is the case that we generate them randomly in our tests.

See

• The Deployer's koba config https://github.com/OpenZeppelin/rust-contracts-stylus/blob/94497e67f5b42964a32f28718ece373dc9ab6d73/lib/e2e/src/deploy.rs#L58
• Private key generation https://github.com/OpenZeppelin/rust-contracts-stylus/blob/94497e67f5b42964a32f28718ece373dc9ab6d73/lib/e2e/src/account.rs#L104
• In-test deployment https://github.com/OpenZeppelin/rust-contracts-stylus/blob/94497e67f5b42964a32f28718ece373dc9ab6d73/examples/erc20/tests/erc20.rs#L48

You could as easily retrieve the private key from a trusted setup, or the like.

[emnul]

At the moment koba expects private keys to reside on the local file system

I think I was conflating the API of the CLI app with the API of the Koba library. You're totally right, Koba doesn't make these assumptions.

However, the program expects direct access to a private key which makes it incompatible with Cloud / Ledger Signers where it's not possible to obtain this.

Would the team be interested in supporting this use case? I'd like to hear your thoughts as a maintainer. It seems pretty straightforward to implement, but I recognize that Koba is a temporary solution to a problem that's likely to be solved by the official cargo stylus tool, so this feature may ultimately be more effort than it's worth.

[alexfertel]

However, the program expects direct access to a private key which makes it incompatible with Cloud / Ledger Signers where it's not possible to obtain this.

I see, yeah, that's a limitation we currently have.

Would the team be interested in supporting this use case? I'd like to hear your thoughts as a maintainer. It seems pretty straightforward to implement, but I recognize that Koba is a temporary solution to a problem that's likely to be solved by the official cargo stylus tool, so this feature may ultimately be more effort than it's worth.

Yeah, I think I'd rather wait for more requests from the community before implementing this. Another thing is that this would be a breaking change, so I'm even more inclined to wait and see.

Lastly, I think the Offchain Labs team wants to go with a Factory for contract construction, so I expect koba to be deprecated before EOY, but there's uncertainty there.

cc: @bidzyyys @qalisander