concordium / concordium-misc-tools Goto Github PK
View Code? Open in Web Editor NEWA collection of small tools with a well-defined purpose
License: Apache License 2.0
A collection of small tools with a well-defined purpose
License: Apache License 2.0
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
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
The transaction generator should support sending smart contract updates for the following contracts/methods:
Sub-tasks
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.
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.
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
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.
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
Add readme specifying dependencies, installation, configuration, etc.
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.
To properly test ID proof generation in the mobile wallet, the ID verifier tool needs to support connecting to mobile wallets through wallet-connect
It would be helpful to have a panel on the dashboard showing the sum of transactions for each month within the selected time-range.
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:
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.
Task description
Update state compare tool to support protocol version 6.
Sub-tasks
Add label for component and priority.
Task description
Develop an issuer of Web3ID credentials.
The issuer should do the Concordium specific parts
The issuer should be a standalone service.
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
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.
Bug Description
As it is now the wallet-connect-test-bench uses dapp-libraries and this is undesirable for several reasons.
We should revise the test app so that negative scenarios such as invalid schema actually reach the wallet.
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
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:
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
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:
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.
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
We interpret this as meaning number of bakers that are delegated to.
For maximum flexibility, the user should be able to filter on any subset of transaction types, not just CCD transfers.
Task description
For deployment purposes, SRE have requested the following to be added to the project
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
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 }
Task description
Implement a backend that can verify ID proofs. The flow should be:
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:
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
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.
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):
The tool genesis-creator
needs to support generating genesis data for protocol version 6.
Get an overview of the tools needed to implement the key performance indicator tool and design application architecture and database
Sub-tasks
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.