Friction in Docker-based Contract Deployment Workflow

[0xpatrickdev]

What is the Problem Being Solved?

As a developer, I feel friction in the docker-based workflow. The main painpoint is contract deployments needing to go through the Docker container, and confusion as to whether I’m operating in a local context or docker context. The “magic” happening in the docker deploy scripts is also limiting my understanding of how bundles, contracts, and proposals work and how I can build them myself.

It would be great if I can deploy my contract via my own local CLI context, versus needing to do it through the Docker container. I may not have agd installed so Node.js scripts that can talk to my docker instance would be awesome.

Description of the Design

The current reasons for executing from inside Docker:

• The user does not have agd installed locall
• The user does not have keys in their agd keyring with funds to submit a proposal
• The user does not have enough vote power to execute a proposal, so we must use the gov key

The path we might explore is:

• hardcode a test mnemonic as an env var / constant, and load it into Secp256k1HdWallet (a node.js wallet that doesn't require agd)
• use /agoric.swingset.MsgInstallBundle + /agoric.swingset.CoreEvalProposal with StargateSigningClient to submit the messages over the (local) network
  • see cosmos-proposal-builder for code examples of this

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[aj-agoric]

assigning to @sufyaankhan for product triage thoughts

[dckc]

one solution that gets kicked around now and then:

• https://github.com/Agoric/agoric-sdk/issues/8033