concordium / concordium-misc-tools Goto Github PK

Use grafana to visualize the data collected by the KPI-tracker service. Data is generally collected per block (and thus block time), enabling time series format for all metrics.

• Set up Grafana locally
• Transactions
  • Number of transactions
  • Number of rejected transactions
  • Transaction fees paid
• Accounts
  • Number of accounts
  • Number of active accounts (30 days)
    • Is very slow/heavy
  • Number of initial accounts
• Smart contracts
  • Number of smart contract modules
  • Number of smart contract intances
  • Number of active smart contract instances (30 days)
    • Is very slow/heavy
• Misc
  • Total value staked (protocol version 4 and later only for now)
• Optimize account/contract activeness queries (2d timebox)
• Make "deployable" configuration

Provide one tool with a single configuration file to create a custom genesis.

Currently there are 4 different tools you need to generate genesis for local execution. Also better documentation is needed.

Task description

Create a test bench front end for testing various positive/negative scenarios of how a front end could interact with the mobile wallets (using wallet connect). The front end should display all responses (e.g. error messages returned as well as transaction hashes returned) for further investigation.

The front end uses the react-components/wallet-connectors libraries to create the connection between mobile wallets and the front end: https://github.com/Concordium/concordium-dapp-libraries/tree/main/packages

Sub-tasks

The front end should have sections for testing the following scenarios:

• Button for walletConnect connection.

• Display connected account address.

Positive testing:

• A test sending a simple CCD transfer to another account.

• Sign an utf-8 string message and display the signature at the front end.

• Sign a binary message and display the signature at the front end.

• Setter/View functions:
  An input field is provided for all these scenarios to input the correct type. Its value is serialized with the correct schema in the mobile wallets and sent to blockchain. An output field will display the deserialized value from the corresponding view function.

  • set/view Address
  • set/view AccountAddress
  • set/view ContractAddress
  • set/view string
  • set/view Timestamp
  • set/view Option
  • set/view PublicKey
  • set/view Signature
  • set/view Hash
  • set/view u8
  • set/view u64
  • set/view Object (containing fields for an Address, AccountAddress, ContractAddress, string, u8, u64)
  • set/view Array (containing Addresses)

• Above setter functions should be tested with rawModuleSchemaBase64 and with individual parameterSchemas/returnValueSchemas

• Above setter functions should have two versions (one that expects a positive CCD amount and one that expects an amount of 0 CCD sent to them). It should be possible to display the smart contract balance from the front end to check that the correct CCD amount was sent to the smart contract.

• A test sending a transaction to a smart contract that calls another smart contract successfully.

• Testing deploying of new smart contract modules.

• Testing initializing of new smart contract instances.

Negative testing:

• Above setter functions should be tested with a wrong schema (mismatched schema should cause the wallets not to be able to serialize the input parameter correctly). Error messages from the wallets should be displayed.

• Above view functions should be tested with a wrong schema (mismatched schema should cause the wallets not to be able to deserialize the return value correctly). Error messages from the wallets should be displayed.

• A test sending a transaction that reverts due to the smart contract logic.

• A test sending a transaction to a smart contract that calls another smart contract but then reverts due to the smart contract logic.

• It should be tested with a spoofed schema what happens if the smart contract does not have an entrypoint or does not have an entrypoint with the given input parameter. Meaning the mobile wallet should be able to create a valid transaction (given the spoofed schema/input parameter) but the blockchain does not have a valid smart contract/entrypoint for that transaction.

• A test sending a transaction to an account that does not exist on chain.

• Above setter/view functions should be tested by sending CCD to the function even if the function expects no CCD. Error messages should be displayed (potentially using a spoofed schema).

Scenarios that are excluded for the first version of the test bench (but potential subjects for future versions):

• Toggle to select if the connection should be done to testnet or mainnet.
• Testing scheduled transfers.
• Testing shielded transfers.
• Testing transfers with MEMO.

Add readme specifying dependencies, installation, configuration, etc.

Task description

JSON_RPC is now deprecated in favor of gRPC; check/implement if we can update the wallet-connect-test-bench to gRPC.
Concordium/concordium-dapp-libraries#36

Task description

This follows #2 and #3 and its goal is to replace the more complex genesis generation scripts with example usage of the new tool.

The following must be updated/deleted

• The docker build file for current set of genesis tools in concordium-base
• The "genesis" tool in concordium-base should be removed
• The python script to generate genesis in concordium-node (in scripts/genesis) should be removed and the instructions there should be replaced by instructing the user to use this tool, with an example configuration file.
• In the genesis_data repository, instructions on how to generate genesis should be replaced.

Bug Description
Selecting 24 hours or less as a range causes graphs for smart contracts (instances) and smart contracts (modules) shows as "Data out of range".

Steps to Reproduce
Select 24 hours as the range and observe graphs.

Expected Result
Only for the data that is read on the payday it would make sense that the data is out of the range, if the range selected was less than 24 hours otherwise data should be there.

Actual Result
graphs for smart contracts (instances) and smart contracts (modules) shows as "Data out of range".

Versions

• Software Version
• OS
• Browser
• Mobile device, if applicable

The tool genesis-creator needs to support generating genesis data for protocol version 6.

For deployment purposes, SRE have requested the following to be added to the project

• Dockerfile
• Jenkinsfile

Description
Allow end users for https://wallet-test-bench.testnet.concordium.com/ to set own "Max energy allowed" for relevant transactions
Steps to Reproduce

Expected Result

Actual Result

Versions

• Software Version
• OS
• Browser
• Mobile device, if applicable
  

The current implementation is fragile in a number of ways when comparing it to the implementation of f.x. the transaction logger. To make the service more robust we need to do the following:

• Allow configuration with a list of node endpoints
  • Finalization max time behind
• Allow configuration through environment variables
• Concurrent querying for catchup
• Gracefully stop when receiving stop signal
• Error handling
  • Endpoint connection lost
  • DB connection lost

Task description

Develop an issuer of Web3ID credentials.

The issuer should do the Concordium specific parts

• register credential on the chain
• register the credential in the storage contract
• return the credential to the user

The issuer should be a standalone service.

Bug Description
Foundation tax graph is missing CCD as the unit after the value

Steps to Reproduce
Look at the Foundation Tax graph.

Expected Result
Should contain CCD as unit.

Actual Result
Doesn't contain any unit.

Versions

• Software Version
• OS
• Browser
• Mobile device, if applicable

Task description
Implement a backend that can verify ID proofs. The flow should be:

1. Injection of the statement to the backend from the app
2. The backend returns a challenge + statement to the app
3. The app forwards the challenge + statement to the wallet
4. The wallet produces a proof (or rejects) of the statement to the app
5. The app forwards the proof to the backend.
6. The backend returns yes/no depending on whether the proof verifies.

Bug Description
Selecting 12 hours for the range causes some performance issues such as transactions graphs are loaded slow and their responsiveness is also slow.

Steps to Reproduce
Open KPI Tracker Grafana page and select the range to be 12 hours.
Observe transactions graphs.

Expected Result
Performance should not be affected.

Actual Result
Currently it seems to take unusually longer time to load the graph.

Versions

• Software Version
• OS
• Browser
• Mobile device, if applicable

Task description

If somebody has accidentally their browser wallet set to mainnet, the test bench front end does not work properly. Check for network connection and give appropriate error messages.

The transaction generator should support sending smart contract updates for the following contracts/methods:

• Mint CIS2 tokens (contract)
• Wrap/Unwrap wrapped CCD (contract)
• Transfer CIS2 tokens (contract)
• Register Web3 ID credentials (contract)

Sub-tasks

• Mint CIS2 tokens
• Wrap/Unwrap wrapped CCD
• Transfer CIS2 tokens
• Register Web3 ID credentials

Task description
Update state compare tool to support protocol version 6.

Sub-tasks

• subtask 1
• subtask 2
• subtask 3

Add label for component and priority.

Get an overview of the tools needed to implement the key performance indicator tool and design application architecture and database

Sub-tasks

• Select frontend for inspecting metrics
  • Initially, we'll select grafana as a front-end, as it can integrate directly into a postgres database.
• Overview of rust SDK
• Look into how Grafana integrates into database
• Database structure
• Feature proposal

Task description

There are a few common patterns when generating genesis.

- A “standard” genesis with N accounts and M bakers. Perhaps tweaking block time or reward periods.
- Genesis for stagenets. This is similar to above, but often more genesis parameters are changed.
- Genesis for mainnet and testnet where some or all the keys are generated individually by external parties, and the keys just need to be assembled into a genesis block.

Requirements
- The tool should support the use-cases listed above
- The input format should be documented and as ergonomic as possible.
- The generated files (e.g., accounts, update keys) should have the format compatible with existing ones, so that no testing processes are negatively affected.

Something like the following configuration file should be supported

protocolVersion = 1

[out]
updateKeys = "./update-keys"
accountKeys = "./accounts-out"
bakerKeys = "./bakers-out"
identityProviders = "./idps-out"
anonymityRevokers = "./ars-out"
genesis = "./genesis.dat"

[cryptographicParameters]
kind = "generate"
genesisString = "Test genesis parameters."

[[anonymityRevokers]]
kind = "fresh"
id = 1
repeat = 3

[[identityProviders]]
kind = "fresh"
id = 0
repeat = 3

[[accounts]]
kind = "fresh"
balance = "1000000000"
template = "foundation"
identityProvider = 0
numKeys = 1
threshold = 1
repeat = 10000
foundation = true

[updates]
root = { threshold = 5, keys = [{kind = "fresh", repeat = 7}]}
level1 = { threshold = 7, keys = [{kind = "fresh", repeat = 15}]}

[updates.level2]
keys = [{kind = "fresh", repeat = 15}]
emergency = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
protocol = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
electionDifficulty = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
euroPerEnergy = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
microCCDPerEuro = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
foundationAccount = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
mintDistribution = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
transactionFeeDistribution = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
gasRewards = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
poolParameters = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
addAnonymityRevoker = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}
addIdentityProvider = {authorizedKeys = [0,1,2,3,4,5,6], threshold = 7}

[parameters]
genesisTime = "2022-06-24T11:12:43Z"
slotDuration = 250
leadershipElectionNonce = "d1bc8d3ba4afc7e109612cb73acbdddac052c93025aa1f82942edabb7deb82a1"
epochLength = 400
maxBlockEnergy = 3_000_000

[parameters.finalization]
minimumSkip = 0
committeeMaxSize = 1000
waitingTime = 100
skipShrinkFactor = 0.5
skipGrowFactor = 2
delayShrinkFactor = 0.5
delayGrowFactor = 2
allowZeroDelay = true

[parameters.chain]
version = "v0"
electionDifficulty = 0.025
euroPerEnergy = 0.00002
microCCDPerEuro = 50_000
accountCreationLimit = 10
bakerCooldownEpochs = 166
minimumThresholdForBaking = "2500000000"
[parameters.chain.rewardParameters]
mintDistribution = { mintPerSlot = 0.0000000007555665, bakingReward = 0.85, finalizationReward = 0.05 }
transactionFeeDistribution = { baker = 0.45, gasAccount = 0.45 }
gASRewards = { baker = 0.25, finalizationProof = 0.005, accountCreation = 0.02, chainUpdate = 0.005 }

Description
The way micro wCCDs are minted for all the accounts now have a big impact on the TPS at the beginning of the test but also looking at the average TPS at the end of the test. The impact would be even bigger in case there are thousands of accounts on chain.

For example, in case if there is 1500 accounts on chain and we are sending 1 TPS, the generator will first try to mint 1 wCCD for all the accounts at once which would generate 1500 transactions within seconds.

Change the generator in a way that the minting happens the same way as other transactions are handled.

Steps to Reproduce
Use a chain with 1500 accounts.
Use the generator generator --sender sender.json --tps 1 wccd.

Expected Result
There should be approximately 1 micro wCCD minted per second for an address on chain.

Actual Result
Minting of 1 micro wCCD is done within first couple of seconds after starting the generator.

Versions

• Software Version
• OS
• Browser
• Mobile device, if applicable

The current way that companies create accounts is with the user-cli CLI tool, which is not user friendly enough. We will therefore create a GUI version of this tool.

To be able to extract the collected metrics, they should be stored in a database. A draft of the design can be seen here.

This includes:

• Create database schema in SQL
• Connect to (and use) database from service
  • Restore process from most recent block height stored
  • Insert data transactionally by block

New versions of JS libraries have been published, which we should strive to use in our applications.

Libraries to update:

• @concordium/web-sdk
• @concordium/react-components
• @concordium/wallet-connectors
• @concordium/browser-wallet-api-helpers

Applications needing updates

• id-verifier
• wallet-connect-test-bench

The below data should ideally be available in time series, and with the time span of each observation being configurable.
As an example we should be able to see the number of new accounts both on a daily basis and on a monthly basis.

• No. of new initial accounts
• No. of new accounts in total
• No. of accounts in existence
• No. of active accounts
• No of new active accounts
• No. of transactions
• No. of CCD-transfer transactions
• No. of accounts with CCD-receive or CCD-send transactions
• No. of accounts staking
• No. of CCDs staked
• No. of CCDs paid as transaction fees
• No. of smart contracts deployed
• No. of active smart contracts
• No of active bakers
• No. of new active bakers
• No. of new CCDs minted
• No. of CCDs paid as baker rewards
• No. of CCDs paid as finalizer rewards
• No. of CCDs paid to Concordium Foundation as 10% charge
• No. of finalizers
• No. of active nodes
• No. of accounts delegating
• No. of CCDs delegated
• No. of bakers open for delegation
• No. of bakers actually receiving delegated CCDs
• No. of CCDs earned by bakers from delegation

To properly test ID proof generation in the mobile wallet, the ID verifier tool needs to support connecting to mobile wallets through wallet-connect

I will leave this comment here as a tracker of the implementation:

• #89
• #90
• #92
• #102
• #103
• #104
• #105
• #94
• #99
• #100
• #101
• #96
• #97

Task description

We interpret this as meaning number of bakers that are delegated to.

Add the ability to toggle decimal digits where CCD are displayed (so in staked CCD, Transaction fees (cumulative), Transaction fees). So instead of e.g. showing 9000000000.000000 CCD show 9000000000 CCD.

A Grafana variable would be suitable for this.

For maximum flexibility, the user should be able to filter on any subset of transaction types, not just CCD transfers.

In order to better judge the effectiveness of new releases, campaigns, product traction, etc. we'll start tracking KPIs in Q4. These need to be automated to avoid human error and to ensure timeliness. In this project we'll pinpoint the basic set of company KPIs to track, and automate the tracking.

Internal tool with dashboard accesible by non-techies

When the user rejects a request for an ID proof in the mobile wallet, the rejection is currently not handled in the proof explorer app.

It would be nice if this was the case, to align with how rejection is handled by the browser wallet, and to be able to test this scenario internally.

Bug Description
Transactions graph offers possibility to filter by transactions that are no longer used. We should combine those transactions into the Configure baker for both Transactions graph and Transactions (Cumulative) graph.

Combine the following transaction types into configure_baker from Transactions and Transactions (cumulative) graph:

• add_baker
• remove_baker
• update_baker_stake
• update_baker_restake_earning
• update_baker_keys

Another thing related to the Transactions graph is that since it is "stacking type", it seems sometime visually a bit strange. For example if we select top show configure_baker and remove_baker for a range since 11-2021 to today, it visually looks as configure baker was used even before it was introduced. This is because when the value is 0, it seems that the type selected is just stacked on top of the other type selected.

Versions

• Software Version
• OS
• Browser
• Mobile device, if applicable

The service needs to query the node for relevant data and structure this data to be used for presenting a set of metrics over time. This includes:

• Blocks
  • Block hash
  • Block time
  • Height
  • Total stake (for blocks >= protocol version 4)
• Accounts
  • Block hash
  • Address
  • Is initial account?
• Transactions
  • Transhaction hash
  • Block hash
  • Type
• Smart contract modules
  • Ref
• Smart contract instances
  • Address
  • Module ref
• Transaction-Account relations
• Transaction-Contract relations

Task description

This is a continuation of #2 and its goal is to make the tool more polished, and make it handle errors better.

Sub-tasks

• Make the prototype handle all genesis versions.
• Test genesis generation with all the different versions.
• Document the input format and behaviour of the tool

It would be helpful to have a panel on the dashboard showing the sum of transactions for each month within the selected time-range.

Create a database following the design described here, and connect to this from the KPI service.

Entries should be made transactionally per block to ensure easy recovery from breakdowns.

Bug Description

As it is now the wallet-connect-test-bench uses dapp-libraries and this is undesirable for several reasons.

• The testing is meant to be on the wallet API directly, rather than through an indirection that could both hide some behaviour and introduce new bugs.
• Negative scenarios such as sending an invalid schema to the wallet are not possible to test directly on the wallet since the error is raised before the wallet is reached.

We should revise the test app so that negative scenarios such as invalid schema actually reach the wallet.