concordium / concordium-contracts-common Goto Github PK

Add a schema type for byte arrays in hex format. They should be represented with a JSON string.

This is especially useful with the new cryptographic primitives: Concordium/concordium-rust-smart-contracts#101

Will also require matching changes in cargo-concordium and concordium-client.

This will introduce a new contract schema version and require updating

• Update in concordium-contracts-common
• Support in cargo-concordium
• Support in concordium-client
• Update contract schema documentation.
• Support in concordium-node-sdk-js

Bug Description

&str should be serialized without allocating an intermediate vector.

We should implement a Serial for &[u8] and use that instead of using to_vec in serializing &str.

Task description

Update concordium-contract-common to support event schema creation/serialization/deserialization.

Hi there,

Bug Description
I am trying deploy one of the smart contracts which is piggy_bank_part1. I can able to successfully build smart contracts. But when I try to deploy a smart contract it is throwing an error as shown below:

Using default energy amount of 3081316 NRG.
Deploy the module './target/wasm32-unknown-unknown/debug/piggy_bank_part1.wasm'.
Allowing up to 3081316 NRG to be spent as transaction fee.
Confirm [yN]: y
y
Deploying module...
concordium-client: user error (Cannot connect to GRPC server.)

Can any help me out the reason for deployment failure?

Thanks

Task description

Adding the Display Trait and a function to display the schema in a human-readable manner. This is a prerequisite for adding a feature to cargo-concordium to decode and display schemas in a human-readable manner. We also intend to expose this functionality in the concordium-web-sdk so that front ends can decode/display schemas.

Currently the errors in this crate does not implement the Error trait, which is expected when using the types outside of smart contracts (like the Rust SDK).

We have to ensure that implementing Error does not impact smart contract code, when building using no_std and if so, it should be moved behind a feature flag.

Appease clippy for rustc 1.68.

Description

We could improve the error reporting when converting JSON parameters to binary using a schema in concordium-contracts-common. By improve, I mean that we could include a "stacktrace" to show where the incorrect value belongs. This is especially useful when the parameter is a struct or enum comprised of many fields.

So instead of giving the error Expected AccountAddress.
It should tell you this, but also include information about where it expects an account address. Similar to what concordium-client does:

Error: Could not decode parameters from file 'param.json' as JSON:
       Expected value of type "<AccountAddress>", but got: 123.
       In [
           123
       ].
       In enum variant '"Account"'.
       In field 'operator'.
       In {
           "operator": {
               "Account": [
                   123
               ]
           },
           "update": {
               "Remove": []
           }
       }.
       In [
           {
               "operator": {
                   "Account": [
                       123
                   ]
               },
               "update": {
                   "Remove": []
               }
           }
       ].

Since the JavaScript SDKs recently started using concordium-contracts-common for handling the JSON to binary conversion, this issue has become more important.

Replace base58check with bs58.
It is better designed and maintained, and has up-to-date dependencies.

Description

We have a few different types that have an owned and a reference version, fx OwnedContractName/ContractName, OwnedEntrypointName/EntrypointName.
Most of the useful methods are on the reference versions, and you can convert from the owned to the reference version via a method, fx owned_contract_name.as_contract_name(), and then use the useful methods there.

But it would be more ergonomic if we implemented Deref from the Owned to the reference version, so that you wouldn't need the conversion method.

However, we cannot implement Deref until we upgrade to Rust version 1.65+ which introduces Generic Associated Types (GATs). The issue is that we need to set the associated type Target to a type with a generic lifetime parameter: type Target = ContractName<'a>.

Smart contract approval allowance mechanism (Approving Allowances means authorizing the smart contract, in advance, to spend the tokens, without needing the private key to do that). ERC-20 has the TransferFrom method which does this. Source: Tacans

User stories

• (4) Add a description for "Ethereum Developers" on the documentation site

Description

concordium-contracts-common and concordium-rust-smart-contracts seem out of sync in terms of development flow.

• CRSC's main references CCC's commit b65a456, while CCC's main is at 16e4521
• CCC is being upgraded in CRSC to its main only in branch 258-use-public-keys, which seems to be long from being merged into CRSC's main

This prevents other PRs which perform synced changes to both repos being correctly developed.

Suggested fix

• Create similar branch 258-use-public-keys in CCC, set to 16e4521
• Make CRSC's 258-use-public-keys branch reference similarly named branch in CCC
• Revert CCC's main to b65a456, making it in-sync with CRSC again

Steps to Reproduce

Check what CCC's commit is used as submodule in CRSC's main, and where's the actual CCC's main at

Expected Result

CCC's and CRSC's main branches are in sync

Actual Result

CCC's and CRSC's main branches are out of sync

Versions
N/A, concerns repository submodules

Task description

This was not previously possible since we did not have const-generics, but since we now support 1.51+ only this is possible.

This should be straightforward, but we do need to make sure to inline things properly so that the generated wasm is the same.

Sub-tasks

• Replace the use of macros.
• Test compiling example smart contracts and ensure that the generated code is either the same, or at least no larger.

ModuleRef <> ModuleReference
Parameter <> OwnedParameter