-
Notifications
You must be signed in to change notification settings - Fork 547
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
Update the template to SDK v0.44 #1307
Comments
Nice. Didn't know that had been released, I'll look into it. |
Only an RC has been released, but it's unlikely that there will be more breaking changes, so it's as good as released as far as Starport is concerned. |
Alrighty. I will scaffold something, bump it, and make sure that it works correctly and if so I'll put in a PR. |
just adding the sdk-go repo to the various bits since ibc moved and then we should be good to go. |
Looking forward to this! |
Almost finished. Just working on the antehandler and upgrade module, they've changed a bit too. Also, feel free to follow along, as I'm starting to think this may require some restructuring. I am checking out simapp in the sdk to try and figure out what that might look like. Issues are specifically:
It is a larger task than I had thought, but I am enjoying it, thoroughly educational. |
antehandlers are now like:
|
@fadeev I figure we want the fee grant module and authz, correct? |
@faddat since we currently don't have a way to properly import modules, I'd say it's fine to have those in the standard template. |
They're in. IBCKeeper is fixed and.... lord knows I'll need to fix another few things. useful doc! |
only small errors remain. Excitement! |
It'll break wasm a bit I think, this is from root.go: // initAppConfig helps to override default appConfig template and configs.
// return "", nil if no custom configuration is required for the application.
func initAppConfig() (string, interface{}) {
// The following code snippet is just for reference.
// WASMConfig defines configuration for the wasm module.
type WASMConfig struct {
// This is the maximum sdk gas (wasm and storage) that we allow for any x/wasm "smart" queries
QueryGasLimit uint64 `mapstructure:"query_gas_limit"`
// Address defines the gRPC-web server to listen on
LruSize uint64 `mapstructure:"lru_size"`
}
type CustomAppConfig struct {
serverconfig.Config
WASM WASMConfig `mapstructure:"wasm"`
}
// Optionally allow the chain developer to overwrite the SDK's default
// server config.
srvCfg := serverconfig.DefaultConfig()
// The SDK's default minimum gas price is set to "" (empty value) inside
// app.toml. If left empty by validators, the node will halt on startup.
// However, the chain developer can set a default app.toml value for their
// validators here.
//
// In summary:
// - if you leave srvCfg.MinGasPrices = "", all validators MUST tweak their
// own app.toml config,
// - if you set srvCfg.MinGasPrices non-empty, validators CAN tweak their
// own app.toml to override, or use this default value.
//
// In simapp, we set the min gas prices to 0.
srvCfg.MinGasPrices = "0stake"
customAppConfig := CustomAppConfig{
Config: *srvCfg,
WASM: WASMConfig{
LruSize: 1,
QueryGasLimit: 300000,
},
}
customAppTemplate := serverconfig.DefaultConfigTemplate + `
[wasm]
# This is the maximum sdk gas (wasm and storage) that we allow for any x/wasm "smart" queries
query_gas_limit = 300000
# This is the number of wasm vm instances we keep cached in memory for speed-up
# Warning: this is currently unstable and may lead to crashes, best to keep for 0 unless testing locally
lru_size = 0`
return customAppTemplate, customAppConfig
} So what I am going to do is have it return "" as instructed. I guess when importing wasm, all of the above will be needed. When someone imports wasm, we will need to add all of that. Since we import wasm at Juno.... I'll do it as part of and Basically what I'm saying is that I'll break, then fix wasm support. |
So, the template upgrade is finished, but we now need to upgrade Starport. The format that keys are outputted in has changed, resulting in:
I believe it's that "type" field, I think it wasn't there before. |
2 things make this much harder:
|
It also allows us to add features to users' chains without asking them to modify the template. See #1417 |
ahhhhhhhhhh. OK, good point about the import. However, I'm now looking at forking spm for various things. I don't think that's how it is intended, but it is how it's working out. |
spm: starport module right? |
Back to the topic here-- there is something missing from my work, and I unfortunately do not know what it is. I thought that the crash was only related to text formatting on the secp keys, but I was wrong. I scaffolded a chain with the code in the linked PR, and I did the old fashioned init and unfortunately I still got a pretty epic crash. So I have decided that I am going to try and upgrade dig (https://github.com/faddat/dig) itself, then have a second look at the template. I felt like I was probably missing something pretty easy. I might pull spm into dig (vendor it into the repo) for ease of use while doing this. |
Well, if there is something in your fork that is useful for others, we'll consider adding these features to spm proper. Normally, a user shouldn't need to mess with node's cmd. |
also, we should update the bandchain-packet to v0.0.2 |
https://docs.cosmos.network/v0.43/migrations/chain-upgrade-guide-043.html
The text was updated successfully, but these errors were encountered: