The MaxGas (not a cosmos gas, but for a wasmer gas) should not be changeable but be coupled with the backend's max value.

• https://github.com/line/cosmwasm/blob/develop/packages/vm/src/backends/singlepass.rs#L24
• https://github.com/line/lbm-sdk/blob/develop/x/wasm/internal/keeper/keeper.go#L34-L37

It is an underflow prevention logic for setting an actual gas-limit.

https://github.com/line/cosmwasm/blob/develop/packages/vm/src/backends/singlepass.rs#L51

Related with: https://github.com/line/lbm/issues/1135

Summary

signature verification cache

Problem Definition

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

https://github.com/line/cosmos-sdk/blob/v0.38.3-t0.33.4-0.0.0/baseapp/abci.go#L329

https://github.com/cosmos/cosmos-sdk/blob/master/baseapp/abci.go#L408

• Upgrade Cosmos-SDK v0.38.5 (from v0.38.4) - Uses Tendermint v0.33.6
• Upgrade Cosmos-SDK v0.39.0 (from v0.38.5)
• Upgrade Cosmos-SDK v0.39.1 (from v0.39.0) - Uses Tendermint v0.33.7
• Upgrade Cosmos-SDK v0.40.0 (from v0.39.1) v0.40.0 Not yet released but soon.

Summary

Now, ISSUE/PR Templates are the same as cosmos-sdk and they contain some links referring cosmos's repository.
We should rewrite them for our repositories.

Proposal

Rewrite ISSUE/PR Templates before this repository will be published.

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Summary

I propose using sig_block_height and sequence to sign a tx instead of account number and sequence.

Problem Definition

The account number and sequence are currently used for transaction signing.
However, in order to send tx, the account must be created in the chain in advance due to the account number.
Although the rule above is not a big problem in public blockchains because users must receive coin before sending tx, CBDC is expected to have several types of tx that can occur in various accounts other than send tx.
So we have a requirement that we are able to create an account before receiving a coin.

We can also define a message called account_create as in previous chain, but we believe that broadcasting tx to create an account can put a heavy load on the chain, requiring a way to sign tx before it is created.

To this end, I thought about using a certain block height as signing data rather than account number.
It is mentioned here that Cosmos developers have previously discussed this: cosmos/cosmos-sdk#455 (comment)

The block height has the advantage of being able to sign tx for the first time even if the account is not in the chain. We also need this information because we need to consider the functionality of account deletion, and if the block height is within the valid range(I wish we call it VALID_SIG_BLOCK_PERIOD; configurable), it will pass the sign verification.

There is no reason why the sig block height of tx having sequence n should be smaller than the sig block height of tx having sequence n+a. Any sig block height that are greater than (the current block height - VALID_SIG_BLOCK_PERIOD) is valid. Instead, when removing an account, it will be necessary to make sure that he has signed within this period.

Proposal

Using sig block height to sign tx instead of account number.

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Related with: https://github.com/line/lbm/issues/1121, https://github.com/line/lbm/issues/1139

Summary

implement blocks_with_tx_results via grpc

Problem Definition

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

I think these are not enough describing when they are costed.

https://github.com/line/lbm-sdk/blob/d06d4ee5f4651034c3aeac00ffa40c0cbca74ffd/x/wasm/internal/types/params.go#L38-L41

Rewrite gov, ibc and readme docs for wasm.

They are removed by PR #260

Improve inter-msg handling

• update cosmwasm::std
• update wasmvm
• update x/wasm
• make msgs pluggable

Improve inter-query handling

• update cosmwasm::std
• update wasmvm
• update x/wasm

Summary of Bug

https://github.com/line/lbm-sdk/blob/a9bfe8dcf6f2169f41f9be26d04247f3d33b08bb/x/wasm/client/rest/tx.go#L124

This always issues an error because the message lacks Label.

related with: CosmWasm/wasmd@6acc712

Version

v1/develop

• remove circleci task
• add way to replace it (comparing performance with native msgs)

Summary

There is no version in a message. If some message processing is changed and this results in the different app hash, then we face the difficulty of upgrading the chain in that case.

It would be nice to have a version of the message processing module to solve this. The processing module of a particular message allows a particular version to operate after a particular block height.

Problem Definition

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

For line/link#729, we need to integrate jaeger with cosmos-sdk

https://www.jaegertracing.io/

• Add appropriate event type for a specific action
• Modify for EventTypeMessage to include only message-related information

Seem that we should define another EventType to specify msg action details.

It seems that x/wasm is using events incorrectly as a whole.

The original concept seems that EventTypeMessage specifies only module and sender and the details of action will be included in another EventType

Let's correct it another issue.

Originally posted by @whylee259 in #122 (comment)

https://github.com/line/lbm-sdk/blob/2a5a2d2c885b03e278bcd67546d4f21e74614ead/x/wasm/internal/keeper/query_plugins.go#L417-L419

Summary

sig_block_height should be included in tx_body by #265.
But by definition, it would be more appropriate to enter the sign doc.
We need to think about this.

Problem Definition

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

x/wasm/linkwasmd is a d/client app and was used for the integration tests. But it is now outdated and will be deleted.

Ticker for LINK(the LINE token) is LN, not LINK. So we may need to support a ticker with 2 letters.

Originally posted by @beneficial02 in https://github.com/line/link/pull/233

Summary

The current query responses are in the internal path.
So the outside of wasm module cannot refer to the response data structures such as cli_test.

Problem Definition

Proposal

open wasm query responses to public

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Summary

Replacing package name does not apply to the final referrer, so the final referrer (e.g. lbm) must copy the replace of all referencing packages.
This can lead to unintended version conflicts.

It would be better the use our own package name for the forked repo rather than use replace.

Problem Definition

Proposal

Change the wasmvm package name.
github.com/CosmWasm/wasmvm → github.com/line/wasmvm

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Assess risk of updating denom specification for LRC-17 update request.

• Change denom as case sensitive
• Change length to 2~24 long
• Change allowing hyphen

Related with: https://github.com/line/link/issues/1136

Summary

fix: not to increase sequence if the tx is not valid.

Problem Definition

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

We need the contract-banning features for the contract. Banned contracts should not be able to execute/migrate/update-admin/clear-admin.

Require

• Able to set/remove the auditor (multiple) using the governance
• The auditor can ban/unban contracts
• Banned contracts cannot do MsgExecuteContract, MsgMigrateContract, MsgUpdateAdmin, MsgClearAdmin.

topic

This is an issue derived from a survey on the 90-character limit of bech32.
GetPubKeyFromBech32 () at address.go in cosmos-sdk
The public key structure is obtained from the public key encoded in bech32. If we don't use bech32 encoding in this process, the speed will improve.

bech32 performance

In case of composite

input data

valPubKey: {PubKeyBLS12{9095AA25A97443CFBD4B560218BD03E0A134C93FC741049DF4D9D2E807560B5345EEDCEB0B981315BEEB5A04C735F8F7} PubKeyEd25519{FC5C2EC94D5A11511C2E8134AB6A8D397CC5B2FBC8DFAE6E5A1F6E639091F84A}}

• Encoding target:98 bytes that amino-encoded the above

time comparison

unit:nanosecond

unit:bytes

valPubKeyString:
linkvalconspub1qxyxudq2xhtgl77pxzgft239496y8naafdtqyx9aq0s2zdxf8lr5zpya7nva96q82c94x30wmn4shxqnzklwkksycu6l3acjy5tzfhnyyr79ctkff4dpz5gu96qnf2m235uhe3djl0ydltnwtg0kucusj8uy53d43ud

In case of ed25519

input data

valPubKey: PubKeyEd25519{59DDF1994FC24AF8240B79FBF310E119C998FDB177AAACE36D382DB74A28912A}

• Encoding target:37 bytes that amino-encoded the above

time comparison

unit:nanosecond

unit:bytes

valPubKeyString:
linkvalconspub1zcjduepqt8wlrx20cf90sfqt08alxy8pr8ye3ld3w742ecmd8qkmwj3gjy4qnfh7pd

Ref:
#47

There is still FIXME same as CosmWasm/wasmd#282 .

There are many broken links in https://github.com/line/lfb-sdk/blob/develop/x/ibc/spec/README.md

https://github.com/line/lbm-sdk/blob/c612d35fd754597a6cb1b41ed00ba0d2bdf82aca/x/auth/tx/service_test.go#L394

and

https://github.com/line/lbm-sdk/blob/c612d35fd754597a6cb1b41ed00ba0d2bdf82aca/x/auth/tx/service_test.go#L433

Waits for block confirm with only simple sleep.
It should be checked with block height info and retry if height is not changed. And this change enables to shorten the sleeping time.

Summary

Let's think of an update that adds a new module to a chain in running. We will stop a node and restart the node with the new module added. The new node will mount the added module's store, and even if the store does not have data, it will reflect the added store when calculating the app hash. This results in creating an app hash that is different from the nodes that have not yet been upgraded. This is one of the factors that makes updating difficult.

To solve this problem, when calculating an app hash, one can consider whether a new module's store is included after a specific block height.

an considerable example implementation

func (ci CommitInfo) toMap() map[string][]byte {
	m := make(map[string][]byte, len(ci.StoreInfos))
	for _, storeInfo := range ci.StoreInfos {
		if storeInfo.IsActive(height) { // the new added module will be activated after some height
			continue
		}
		m[storeInfo.Name] = storeInfo.GetHash()
	}

	return m
}
func (ci CommitInfo) Hash() []byte {
	if len(ci.StoreInfos) == 0 {
		return nil
	}

	rootHash, _, _ := sdkmaps.ProofsFromMap(ci.toMap())
	return rootHash
}

Problem Definition

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Summary

Move wasm proto files to proto folder like other modules do.

Problem Definition

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

CHANGELOG of wasm module are separated in https://github.com/line/lfb-sdk/blob/main/CHANGELOG.md and https://github.com/line/lfb-sdk/blob/main/x/wasm/CHANGELOG.md. These should be merged.

Comment in x/wasm/alias.go says that this code is generated by github.com/rigelrozanski/multitool. But now, this is different from what this tool generates.

Try to use this tool and decide whether we use it.

Summary

Problem Definition

As various gov params were taken from paramSpace, the cost of storage gas increased.
It's not a bug, but I found out that there was a cost increase more than I expected while fixing the test case.
There is additional gas consumption as paramSpace getters such as k.getGasMultiplier(...) are called more than 4 times in various APIs such as Inistnatiate, Execute, etc. And these consume 1015 per time.
So, totally more consumed additionally over than 4k when every API called.

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Summary of Bug

https://github.com/line/lbm-sdk/blob/95eb4e7aef273977d89585676da5309c83dad887/go.mod#L19

gogo/protobuf v1.3.3 does not exist.

and the replace

https://github.com/line/lbm-sdk/blob/95eb4e7aef273977d89585676da5309c83dad887/go.mod#L62

does not work in make build in x/wasm/linkwasmd.

Because of them, make build in x/wasm/linkwasmd fails.

Version

v2/develop (95eb4e7)

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Contents

The public key generated by BLS12-381 is 96 characters. Encoding / decoding format bech32 cannot be decoded because the maximum decoding is less than 90 characters.

Impact of bls12-381

With the BLS signature method, a public key is distributed to verify the aggregated signature. Since it will be an aggregated signature (a collection of several signature information), the length of the public key used for the verification is will be about 1.5 times longer than that of ed25519, and a longer public key will be created. (Generated by BLS12-381 curve)

About bech32

The encoding method for creating an address from a public key is bech32, which compensates for some of the drawbacks of base58 which is based on base64.
Roughly

• Case sensitive and difficult to use
• Easy to apply to QR code
• Decoding is complicated and takes time

This has been improved and the encoding code method is bech32.

Current Problem

Currently, bech32 is used, but when decoding the validator address, there is a limit of "90 bytes", and pubkey (96 bytes) (165 bytes including vrf), which is larger than this limit, is input. Decoding has failed.

.initialize.sh (composite version)

#!/usr/bin/env bash
set -ex

# initialize
rm -rf ~/.linkd ~/.linkcli

# Configure your CLI to eliminate need for chain-id flag
linkcli config chain-id link
linkcli config output json
linkcli config indent true
linkcli config trust-node true
linkcli config keyring-backend test

# Initialize configuration files and genesis file
# moniker is the name of your node
linkd init solo --chain-id link --priv_key_type composite


linkcli keys add jack
linkcli keys add alice
linkcli keys add bob
linkcli keys add rinah
linkcli keys add sam
linkcli keys add evelyn


# Add both accounts, with coins to the genesis file
linkd add-genesis-account $(linkcli keys show jack -a) 1000link,100000000stake
linkd add-genesis-account $(linkcli keys show alice -a) 1000link,100000000stake
linkd add-genesis-account $(linkcli keys show bob -a) 1000link,100000000stake
linkd add-genesis-account $(linkcli keys show rinah -a) 1000link,100000000stake
linkd add-genesis-account $(linkcli keys show sam -a) 1000link,100000000stake
linkd add-genesis-account $(linkcli keys show evelyn -a) 1000link,100000000stake

linkd --keyring-backend=test gentx --name jack --priv_key_type composite
# flag add?? TODO
# linkd --keyring-backend=test -- gentx --name jack
# linkd add-genesis-account $(linkcli keys show jack -a) 1000link,100000000stake
# linkd --keyring-backend=test --priv_key_type composite gentx --name jack
# linkd gentx --keyring-backend test --name jack --priv_key_type composite
linkd collect-gentxs --priv_key_type composite

linkd validate-genesis

Error

ERROR: failed to build create-validator message: decoding bech32 failed: invalid bech32 string length 165

Reference

https://github.com/line/link/issues/1111

• list up params
• change to gov params
• add test
• prepare PR

Summary of Bug

When we make build linkwasmd, we get error due to different arguments.

# github.com/line/lbm-sdk/v2/x/wasm/linkwasmd/cmd/linkwasmd/cmd
cmd/linkwasmd/cmd/root.go:162:45: not enough arguments in call to store.NewCommitKVStoreCacheManager
	have ()
	want (int, cache.MetricsProvider)

https://github.com/line/lbm-sdk/blob/v2/develop/x/wasm/linkwasmd/cmd/linkwasmd/cmd/root.go#L162

Version

Steps to Reproduce

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned