concordium / concordium-base Goto Github PK

Task description

• The keygen tool asks for a password to encrypt the generated keys under.
  We should make it less error prone by asking them to enter it again as a confirmation.

• The same should be done in the "utils" tool which can also encrypt data.

• In the anonymity revocation tool remove the prints of decrypted data. These are just leftovers from before and all the data is written to files already.

The testing section has only a skeleton and the best practices has little information. These should be developed further.

Task description
Implement functionality for proving and verifying a list of statements, where a proof can be

• revealing of an attribute
• range proof on an attribute
• attribute (not) in a set

Task description

The function id::utils::commitment_to_share would benefit from multiexponentiation.
This would increase performance in a function that is used a fair amount.

Sub-tasks

• Benchmark identity and credential creation before the change
• Write the above mentioned function using multiexp.
• Benchmark identity and credential creation after the change

Task description

The mobile wallet will need to support transfer and encrypted transfer with metadata, so we need to add support for these transaction types to the mobile wallet libraries.

We should update the create_transfer and create_encrypted_transfer functions so that the input JSON can contain an optional metadata field, which should just be a hex-encoded byte array. If this is present then we make a corresponding transfer with metadata, otherwise the library does as it did before.

Task description

The mobile wallet will need support for producing the proofs in the same way that the browser wallet has. As a result, we need to add exports of the prover functionality to the mobile wallet libraries.

Description

Floating-point numbers are not supported in smart contracts, but if you don't know that and you try to use them (or you use a library that uses floats), the error message when building with cargo concordium is very cryptic.

Steps to Reproduce

1. Use floating-point numbers in your contract.
   Make sure that the compiler doesn't optimize the floats away.
   Something like this worked for me with 1.53.0:

   fn g() {
       if f(f(1.)) < 2. {
           println!("hello");
       }
   }
   
   #[inline(never)]
   fn f(x: f64) -> f64 {
       if x < 1. {
           x + 1.
       } else {
           x + 2.
       }
   }

2. Compile the contract with cargo concordium build

Expected Result

An error message saying: Floating point numbers are not allowed.

Actual Result

Error: Could not build smart contract.

Caused by:
    0: Could not validate resulting smart contract module as a V1 contract.
    1: Unknown value type byte 0x7c

(0x7c is the encoding of the f64 type in https://webassembly.github.io/spec/core/binary/types.html#number-types.)

Versions

• Software Version: cargo concordium v. 2.0.0
• OS: macOS

The crypto_common crate in base and the concordium-contracts-common crate both contain a rust definition of a number of basic types, such as AccountAddress, ContractsAddress and Amount.
The Rust SDK exposes both crypto_common and concordium-contracts-common and when dealing with smart contracts the user will have to use types from both crates.
Currently, the user have to convert the types back and forth between the crates even though they are defined in the same way. Unifying the types will solve this.

Since concordium-contracts-common is used by smart contracts through concordium-std, it is important to ensure:

• The crate can compile to WASM.
• It supports no_std.
• Changes won't increase smart contract module size.

PRs

• Concordium/concordium-contracts-common#48
• #186
• Concordium/concordium-rust-sdk#28
• Concordium/concordium-use-case-examples#12
• Concordium/concordium-rosetta#45
• Concordium/concordium-transaction-logger#9
• Concordium/concordium-wasm-smart-contracts#58
• Concordium/concordium-rust-smart-contracts#151

Restructuring

These PRs should be merged after the previous ones

• Concordium/concordium-wasm-smart-contracts#59
• Concordium/concordium-smart-contract-tools#4
• #195
• Concordium/concordium-node#454
• Concordium/.github#7

Task description

The mobile wallet library needs to be able create identity recovery requests, so a wrapper around the core function from the id crate will have to be introduced in the mobile wallet library.

Task description

The ed25519 crate deprecated the use of the https://docs.rs/ed25519/latest/ed25519/struct.Signature.html#method.new method in 1.3.
We still use it in a few places in crypto_common which causes warnings with 1.3 version.

We should move away from it when convenient, and replace it with from_bytes or something else when appropriate.

Specifically on numbers where the mantissa is of the form n00, n000, ... with the exponent respectively -1, -2, ... fail to parse.

While these should not appear in practice, since they would lead to more than 100% increase of total GTU per slot, and it would make sense to have the type only for values <= 1, that is not currently the case, and it does lead to globalstate-types tests occasionally failing.

Task description
Implement set membership proof

Task description

Trace-account should be expanded to support all transaction types and be more robust wrt failure.
Possibly it should be expanded to support more source types.

Sub-tasks

• support output in CSV format
• #77
• support querying accounts via credid to get all accounts and not just the ones created by the owner of the credential.

Task description
Remove the initial account from the interaction with the IDP. This means having two versions of the requests since the existing version must be supported for the foreseeable future.

Task description
Collection of improvements to productize the anonymity revocation prototype tools.

Sub-tasks

• PRF key output could be encrypted by anonymity_revocation; input to trace_account would need to be changed accordingly.
• Add user guidance through steps.
• ...

Currently our library provides functionality for proving and verifying a few things, namely opening the value inside a commitment, proving that a value is in a range, and proving ownership of an account; but more can be added. Currently the attribute proofs are only about the on-chain commitments to the attributes.

Ability to share data with dApps (in addition to proving you have the private keys for a particular account)

Initial stories:

• (10) Add set membership proofs about on-chain commitments, pushed to main in concordium-base
• (5) Add off-chain proofs about the attributes that was signed by the IDP, pushed to main

Task description

The mobile wallet library needs to be updated with more transaction functionality. In order to not duplicate things that already exist we need to move all transaction related definitions from the rust-sdk to base, so they can be used in the mobile wallet-library.

Some of these definitions are now needed in the node so it makes good sense to have them in base.

Task description

In order to ease integration we are asked to provide an integration to .NET specifically C#.

We need to first specify how much of the objects should be modeled explicitly and how much should just be JSON blobs.
Some of it will need to be modeled since the identity provider will need to do validation. Ideally all of the objects should be modeled, apart from keys which should probably just stay strings/byte arrays.

At least the following need to be modeled to one degree or another.

• identity provider public and private keys
• identity object request ("PreIdentityObject")
• anonymity revocation record
• initial account credential and initial account creation message
• identity object that is returned to the user.

The interface in C# should be as simple to use as possible.

Task description

Schema version 3 support

One of the libraries we are publishing is wasm-transform, which is to be renamed to concordium-wasm.

We need to

• add changelog, readme
• add documentation for missing top-level definitions
• go through the documentation to make sure it looks reasonable
• update dependents to the new crate name.

Task description

In order to support identity and account recovery the mobile wallet is transitioning to deterministic key derivation. The library for deterministic key derivation has been created already in #157 but this now needs to be integrated into the current mobile wallet API.

In particular the mobile wallet uses two functions

• create_id_request_and_private_data
• create_credential

These are the ones that currently generate keys and randomness that will need to be generated deterministically.

Sub-tasks

• Make it possible to use given randomness in the account_holder.rs functions. Currently this samples randomness from the operating system.
• Revise the API of the above mentioned mobile wallet functions to take the input (seed and identity index for the create_id_request_and_private_data and seed, identity, and credential index for create_credential.
• In principle we can make it so that the API is backwards compatible, and the library falls back onto sampling all the randomness and keys from the OS if the relevant context is not provided.

Task description
Add a library for generating keys according to the newly defined Concordium key derivation scheme. The key derivation scheme is defined in the cryptographic bluepaper. The key derivation scheme is based on SLIP0010, and this library will contain an implementation of that standard for the ed25519 curve.

The library will expose the methods required by clients (e.g. mobile wallets, desktop wallet, browser wallet) for getting identity and account keys, and randomness, given their respective indices as input. Clients will only have to provide a seed phrase and an identity index, or an identity index and account index pair to get the key and randomness material required.

This task is also responsible for making sure that the library is exposed for use in the mobile wallets.

Task description

Add support for delegation transactions and related functionality to the mobile wallet library.

Task description
The browser wallet uses AES-GCM to encrypt the seed phrase. This task should extend utils to support decrypting an AES-GCM cipher text, so that it can be used to decrypt the seed phrase from the browser wallet. The format used by the browser wallet is similar to the existing AES-256, but with a different encryptionMethod.

{
   "seedPhrase":{
      "cipherText":"pcCvMV9rY0gLz4uSk5hGMwIyKPwGAEpUN2hwHLpDfiVv7tIfHCLHtu3u5Oy+Bh+4Jjthb7r6QgR06sYKuumhxacHSC3vuRnaPyrA+KWUNNF9uMZmbCnpSUbnORrM4YgDWU7VGoXno10FqBjb1arairb06taKlZn+U9fX9Eq6FrU+45A3hAcFbbFJClqazpdBnKffRhbTMFTTIMF0Mycd26Wve5wCURwCtmV7",
      "metadata":{
         "encryptionMethod":"AES-256-GCM",
         "hashAlgorithm":"sha256",
         "initializationVector":"Fo/sw+J37iREU7IZJFF0vQ==",
         "iterations":10000,
         "keyDerivationMethod":"PBKDF2WithHmacSHA256",
         "keyLen":32,
         "salt":"yautFuiwJp4UMY4QeoMl5A=="
      }
   }
}

Task description
Write the feature proposal.

Task description

Write a document (e.g., README) describing the costs of smart contract host function calls in detail.

These costs are assigned in the implementation of the host functions https://github.com/Concordium/concordium-wasm-smart-contracts/blob/main/wasm-chain-integration/src/v1/mod.rs#L150 (and analogously for V0 contracts).

For accessibility it would be useful to have a separate document that can eventually be incorporated into developer documentation.

Task description

There are several opportunities for optimizations of the trie implementation, both space and time wise.

At least the following ones should be considered. Any changes should be accompanied by meaningful benchmarks or arguments why memory use is reduced.

Sub-tasks

• The Stem and MutStem types contain a "stem", a list of bytes. In the vast majority of cases, for non-malicious use, these will be very short, very rarely above 40 bytes. Thus a small-scale optimization where we would use something like tinyvec/smallvec for storing the key inline if it is small could be very beneficial to both performance, and reducing memory pressure and fragmentation.
• When serializing (and in store_update) the node's children we now waste a full byte for the child tag. This is wasteful since we could just use the top 4 bits of the Reference, still leaving 60 bits to address, which is more than will ever be needed.

Task description

The mobile wallet library currently hard-codes the anonymity revocation threshold. This would ideally be a parameter set by the identity provider.

We want to update the libraries so that

• they take a parameter, the anonymity revocation threshold when making the identity request
• in order that the libraries are backwards compatible we should make the parameter optional, defaulting to the current behaviour of (n-1) out of n (or 1 out of 1 if that is the only thing possible).

Task description

We currently maintain/provide two wrappers that export functionality needed by identity providers. One for NodeJS and one for C#/.NET.
They share a common Rust library.

These need to be updated for the new protocol without initial accounts, as well as for the addition of the recovery process.

The existing functionality should be maintained for backwards compatibility.

Task description

With the initial account removal the protocol between the user and the identity provider is changed. The request has a different format and the IDP does not create an initial account for the user. Additionally, the identity provider will have to support the recovery processes where a user submits proof of knowledge of idCredSec and gets back the previously issued identity object.

• Add a new endpoint for identity creation without initial accounts. We should make sure that the retrieval URL is specified as part of the protocol and is known to the user before they submit the request.
• Add endpoint for identity recovery.

Bug Description
The BLS12-381 keygen algorithm (keygen_bls in rust-src) does not follow the specification entirely (https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.3).

1. In the procedure I2OSP(L, 2) is calculated incorrectly compared to the specification. We use little endian, but the algorithm specifies big endian.
2. The calls to G1::scalar_from_bytes also assume little endian, but the procedure defines it that bytes are interpreted as big-endian. The byte shifts and slices also need to be adjusted accordingly.

Steps to Reproduce
Running the following example:

let ikm = b"4827ad00de6fb8bf9df7f14bfa2c70665ce0098d3b7959a31840d1095fa58e06";
let key = keygen_bls(ikm, b"").unwrap();
println!("{}", key);

Expected Result
The expected result (from another bls library with the keygen implemented):

Fr(0x57395d570b6471aa7be4f2fab5e1c5014648e7ef5919af287efe68a317fdaa0e)

Actual Result
The result from the above input is:

Fr(0x150347dbd41b4c6df3d06f1ae54fa551582b9be2e44d5e2dba496ba36af93e66)

Versions

• Software Version 0.1.0

Task description

They are currently on a private AWS container registry which makes it hard to build public "local chain" configurations.

Sub-tasks

• publish the built images to dockerhup
• update testnet deployment scripts to use the new locations

Bug Description

It is possible for leverage bound calculations to have an overflow if the baker's equity capital is high and/or the leverage factor has a large numerator. This could cause the leverage bound to be calculated as lower than it should be.

Steps to Reproduce

Set the leverage bound to (n*a + 1) / a, where a is very large.
Create a baker with an open pool and significant capital.
Attempt to delegate to the pool with n - 1 times the baker's capital.

Expected Result

Should succeed.

Actual Result

Will probably fail.

Versions

• Software Version 4.0.11

Task description

Resource accounting should be documented in the developer documentation.

• General notion of NRG use
• How different aspects (computation cost, memory, storage costs) are charged for.
• ...

We have a number of internal Rust libraries that are not published on crates.io, the standard Rust package repository. These are used in the Rust SDK, which means that the Rust SDK cannot be published either, which makes it less convenient to use. For the upcoming https://concordium.atlassian.net/wiki/spaces/EN/pages/1056342017 feature we will have a new library for smart contract testing that will depend on (some of) these same libraries as well.

To make it as simple as possible to use this library, and the Rust SDK, we should publish its dependencies, and the library, to crates.io.

Update the FFI interface to expose the aggregate signature APIs for aggregate signatures on different messages. Check that these are correct and if any caveats apply to how we use them. These are used for timeout certificates in the new consensus protocol.

Task description
Due to historical reasons, there are types relating to the block summary defined in concordium-node which would make more sense in concordium-base.

Move the query result types to concordium-base, and move all necessary type definitions for this from node to base.

Sub-tasks

• Identify which types should be moved
• Add relevant files and definitions to base, on branch bstypes-to-base in concordium-base
• clean up files moved to base
• delete definitions from node and refer to base instead
• delete definitions from client and refer to base instead

Task description

Protocol version 3 needs to support account aliases. The chosen approach to account aliases is that we change the meaning of the account address. The first 29 bytes of the address identity the account, the remaining 3 bytes identity the subaccount/alias. This allows about 16 million account addresses for any account.

Subtasks

• Introduce protocol version 3.
• Add auxiliary types needed to support account aliases.

Task description

The interpreter and wasm-chain integration often use anyhow::Error as an error type. This is for historical reasons since during initial development this is most flexible. We then use downcast to identify whether specific errors, such as OutOfEnergy occurred. We also have a number of other concrete errors that I needed during testing. Still there are some remaining errors that are just bail!("arbitrary string").

The ideal way of doing error handling is that each of the library methods (i.e., all of parsing, validation, interpreter) would return a precise error, which would be an enum. anyhow::Error should only be used in cargo-concordium at the application level.

This task is to get to this point.

Sub-tasks

• replace anyhow::Error in wasm-transform functions with precise errors. Using thiserror crate to handle the boilerplate
• replace anyhow::Error in wasm-chain-integration functions with precise errors. Using thiserror crate to handle the boilerplate
• propagate changes

This will make error handling more robust. In particular with the current setup checking whether execution failed with out of energy, or whether it failed for some other reason is not clean and transparent.

Task description

We maintain a number of tools for testing and ad-hoc identity issuance. These are

• client
• user_cli
• identity_provider_cli

The latter two are used in production for company identity issuance and so must be updated and new versions need to be released whenever the initial account removal will be rolled out.

Open questions

• Does the user_cli/identity_provider_cli need to support id recovery. Seeing that company identity issuance is a manual process this does not seem necessary.

The minimal change to the client is support for

• generating V1 requests (also from a seed phrase and indices)
• validating V1 requests
• generating credentials from seed phrases (and indices)

One of the libraries we are publishing is wasm-chain-integration, which is to be renamed to concordium-smart-contract-engine

We need to

• add changelog, readme
• add documentation for missing top-level definitions
• go through the documentation to make sure it looks reasonable
• update dependents to the new crate name.

Task description

Implement Serial for &A where A: Serial in the concordium-contracts-common library.

In most cases this won't matter too much since we usually use A as self and there we benefit from the Rust convenience features in how it type checks foo.serial(), but when using .put we might have an annoyance without this implementation.

Task description
Update BLS and pairing dependencies

Task description

Introduce necessary support structures for implementing synchronous function calls. See Concordium/concordium-node#236

This involves

• changes to the possible events generated by contract execution
• auxiliary types used by the new contracts

Task description

This task is to specify the request and response payloads for the id recovery interaction. The contents of the request and the associated proofs should be specified already in the blue paper.

Sub-tasks

• Add request generation to account_holder.rs
• Add request validation to identity_provider.rs. This concerns the cryptographic checking of the request only. The actual data retrieval details are up to the identity provider implementation.