casper-ecosystem / casper-client-rs Goto Github PK

Add a sign-transaction command to the client that adds support for signing previously created unsigned transactions similar to the sign-deploy command.

• Add functionality for parsing and building Transactions in the client: This is probably an 8 point ticket that I'm currently working on.

We should update any images in READMEs and in links (e.g. html_favicon_url and html_logo_url). We should also update the name "CasperLabs" to "Casper Labs" throughout the code (e.g. in doc comments, READMEs, Cargo.toml files)

....to take

[ ] Option

As per alignment call on Aug 31 2023 , This work to be done post 2.0

This ticket represents the work required to add a command to the casper-client that parses a transaction from the command line and builds an instance of the Transaction type for use in sending to a node via the RPC service, or for writing a transaction file that can later be signed by the client.

Add 3 new library functions to handle the RPC requests to the node/RPC-sidecar. This could again be one eight point ticket or three 3 point tickets. As with the work above the 3 smaller tickets would lead to nicer PR's

For example when I'm running casper-client get-dictionary-item the --state-root-hash is required which sometimes is kind of irritating that I need to get the newest one by running another command.
We can make it optional and let the user know what happens under the hood.
Make sense @darthsiroftardis @Fraser999 @bpr ? :)

The help string should list all the Key variants including their formatted form. Same should apply to any other subcommands which list the Key variants. Also ensure we consistently apply a space after each comma in the list, as this is not currently the case.

Hi, i'm new in Casper ecosystem and i try to install "casper-client" according to this official YT tutorial (https://www.youtube.com/watch?v=asZ4J1fMgk4&list=PL8oWxbJ-csEqjX2A1pprKuHzCBS8RMcmR&index=2).

I installed Rust, and Cargo via WSL on Windows and now i try to install casper-client - but got some compiling errors (you can see in screen from terminal)

It is something connected to casper-execution-engine (version 2.0.1 vs 3.0.0) - newer version was released 2 days ago.

How to properly execute "cargo install casper-client" command?

The client needs to support --session-arg in the transfer and make-transfer subcommands.

Addressing the following request:

How to specify targetAccountHex in transfer shown in this deploy?
https://cspr.live/deploy/741ac7b56fef49d619aa1459c74d13c3081c2f38d41139e30ba955f1d92e675a
I didn't find argument for casper-client transfer . Is it from session transfer? if so how to specify this argument?

copied from: casper-network/casper-node#1949

casper-network/casper-node#2880 downstream dependency

The new method should be called execute-deploy and require the following arguments:
* optional block identifier (as per get-block subcommand)
* deploy_file (as per send-deploy subcommand)

We should provide two new subcommands, speculative-put-deploy and speculative-send-deploy, mirroring put-deploy and send-deploy. Both subcommands should take an optional block identifier (as per get-block subcommand) to be used to specify the global state root to be used.

Internally, they should construct a JSON-RPC request and call the node's speculative_exec endpoint.

investigating of what needs to go into working on the client.

The verbose option has no effect in this subcommand and should be removed

The info_get_deploy RPC on the 1.5.0 node has been enhanced to support requesting the finalized approvals of the deploy via the addition of a new finalized_approvals: bool field in the request which defaults to false if not provided. The client's corresponding subcommand get-deploy should be extended to support setting this field to true.

The current release of the casper client requires libssl1.1 and ubuntu 22.04 only have libssl1.3

In the Rust client, we should support no payment-related args being provided in the transfer and make-transfer subcommands. In the case that no payment-related args are provided by the user, the deploy's payment code should be constructed so that it results in a standard payment of 2_500_000_000 motes. For reference, see https://github.com/casper-network/casper-node/blob/91b760341b2dd93da87ac9b903f510ea952e2cc1/client/lib/parsing.rs#L524-L527 and https://github.com/casper-network/casper-node/blob/91b760341b2dd93da87ac9b903f510ea952e2cc1/client/lib/parsing.rs#L228-L239

We should also update the help strings output to a user of the client, and the rustdoc comments around the relevant lib code to make it clear that payment-related args are stored as part of the deploy, but are otherwise unused.

copied issued from https://app.zenhub.com/workspaces/engineering-l1-60953fafb1945f0011a3592d/issues/gh/casper-network/casper-node/2074

Add 3 new library functions to handle the RPC requests to the node/RPC-sidecar. This could again be one eight point ticket or three 3 point tickets. As with the work above the 3 smaller tickets would lead to nicer PR's

It seems there was some rewrite recently and "-p" isn't an alias for "--public-key" anymore but for "purse-uref" as seen here:

I experienced this with version 1.4.1 + 1.4.2. Version 1.3.3 is working.

The casper-client help account-address shows this info:

OPTIONS:
    -p, --public-key <FORMATTED STRING or PATH>
            This must be a properly formatted public key. The public key may instead be read in from a file, in which
            case enter the path to the file as the --public-key argument. The file should be one of the two public key
            files generated via the `keygen` subcommand; "public_key_hex" or "public_key.pem"

That also breaks the get-auction-info.sh script for providing account details -> I'll file a separate issue there if you can confirm that bug.

Here is the affected line:
https://github.com/make-software/casper-account-info-contract/blob/master/tools/get-account-info.sh#L65

We should support the creation of deploys where the session account is not automatically derived from the provided secret key. We should also make the provision of a secret key optional for the make-deploy and make-transfer subcommands

Add a send-transaction command to the client to allow users to send previously saved transaction files to a casper network via the casper-client.

Often developers use their own structs with their own FromBytes implementation.
Then in smart contract code it is possible to write:

let arg: MyStruct = runtime::get_named_arg("arg");

Sadly it's not easy to construct such an argument with casper-client. There is a hack that can be used. Simply use an fix-sized array:

--session-arg "arg:byte_array_14='09000000536574506172616d7301'"

I'd like to able to write instead:

--session-arg "arg:any='09000000536574506172616d7301'"

Add 3 new library functions to handle the RPC requests to the node/RPC-sidecar. This could again be one eight point ticket or three 3 point tickets. As with the work above the 3 smaller tickets would lead to nicer PR's

Would be usefull to have the standalone bin in the github release.

This PR adds support for the changes made to the info_get_deploy RPC in node 2.0.

As part of the node 2.0 work, many types upon which the client depends have been moved to casper-types from casper-node, meaning these no longer need to be duplicated in the client library.

One point to note is that validation of a get-block response has been disabled. There will likely be a further change made in casper-types which will allow the JsonBlock type to be removed in favour of the actual Block type, and Block provides a public verify() method which will be suitable for this use case. Rather than spending time refactoring the validation logic, I have left it commented out in anticipation of it being replaced soon.

A final point to note is that the casper-types dependency has a patch specified in the manifest of casper-types = { git = "https://github.com/Fraser999/casper-node", branch = "2124-use-execution-journal" }. Once the node PR using this fork and branch merges, we should update the patch to casper-types = { git = "https://github.com/casper-network/casper-node", branch = "feat-2.0" }.

Mac M1 users are not able to install casper-client version 1.5.0 installed via cargo install casper-client.

Steps to reproduce

brew update
xcode-select --install
brew install pkg-config
brew install openssl
cargo install casper-client

What should happen:

casper-client CLI tool should be installed by cargo, permitting use of casper-client commands like casper-client -V or casper-client get-state-root-hash

What actually happens:

All casper-client commands result in:

MacBook:/ user$ casper-client -V
Illegal instruction: 4

Debug info

This is broken using rust nightly.
Rustc:

user$ rustc --version
rustc 1.66.0 (69f9c33d7 2022-12-12)

Rustup:

user$ rustup --version
rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.66.0 (69f9c33d7 2022-12-12)`

Cargo:

user$ cargo --version
cargo 1.66.0 (d65d197ad 2022-11-15)

And non-shallow checkout out brew:

git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask fetch --unshallow

As discussed with @Fraser999 it was never usable really so it can be removed from the code. This should be part of the next major release.

....to take

[ ] Option

As per alignment call on Aug 31 2023 , This work to be done post 2.0

# Linux/Distri Version
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

# System Information
$ uname -a
Linux hostname 5.4.0-153-generic #170-Ubuntu SMP Fri Jun 16 13:43:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

# Casper Client Version
$ casper-client -V
Casper client 2.0.0-438b660

# Generating the bash auto-completion script
$ sudo casper-client generate-completion
[sudo] password for XXX:
Wrote completion script for bash to /usr/share/bash-completion/completions

# Manually dot sourcing the generated file gives an error
$ . /usr/share/bash-completion/completions/casper-client
-bash: /usr/share/bash-completion/completions/casper-client: line 15: syntax error near unexpected token `client,account-address'
-bash: /usr/share/bash-completion/completions/casper-client: line 15: `            Casper client,account-address)'

So the current casper-client broke another existing feature.

I compared the generated file quickly to one from I think V 1.6 and it looks totally different.

Some of the subcommands (e.g. get-account) which currently only support providing a public key should be enhanced to support providing an account hash instead. For reference, see how this is handled in query-balance.

Add 3 new commands to the client using this infrastructure developed in the first ticket #119 (Parsing and Buidling Transactions in the client).

The put-deploy, send-deploy and transfer subcommands should all be extended to support sending the deploy to the node's new speculative_exec endpoint. This should take the form of a new arg --speculative-exec for each subcommand which itself takes an optional value of a BlockIdentifier.

different versions of the block use different key schemes and we need to account for this in the new endpoint

Background

I am using NCTL as my development environment and have customized the deploys.max_deploy_size in the chainspec, because the current deployment size limit is too small for running code such as the Risc0 verifier.

Despite increasing this limit, I am still encountering the following error:

deploy size of 1438228 bytes exceeds limit of 1048576

Issue

The casper-client contains a hardcoded deployment size limit which is manually kept in sync with the production environment. This hardcoded limit is not compatible with customized networks.

Suggestion

The ideal solution would be to enable the client to fetch limits directly from the chain specification. However, until such a feature is implemented, it might be more practical to disable client-side validation of the deployment size.

Add 3 new library functions to handle the RPC requests to the node/RPC-sidecar. This could again be one eight point ticket or three 3 point tickets. As with the work above the 3 smaller tickets would lead to nicer PR's

....to take

[ ] Option

As per alignment call on Aug 31 2023 , This work to be done post 2.0

This ticket will be for adding another command to the client via clap, it will utilize the the work done to create transactions and include creating new code to craft and send the RPC request to a node.

running into an issue with the casper-client-rs. During development for checkpoint charlie I ran into type conflicts between the nodes DeployHash and clients DeployHash.

See results in GitHub actions.
cc @Fraser999

Also, while I remember, L2 will need a ticket to update the client to make use of the new JSON-RPC endpoints. This will be a fairly large piece of work, and as we add/change functionality around the new TransactionV1 type, the client will likely often need a corresponding update. Until the client gets those updates, we won't be able to use nctl as is to exercise the new node functionality. I don't expect nctl tests to break while we're waiting for this, since we're continuing to support Deploy, but the sooner the client is updated, the sooner we can start building up the nctl tests for TransactionV1s

no-std is not required for web target

Add 3 new library functions to handle the RPC requests to the node/RPC-sidecar. This could again be one eight point ticket or three 3 point tickets. As with the work above the 3 smaller tickets would lead to nicer PR's

A new RPC endpoint was added to the node in casper-network/casper-node#3811. Need to update the client to support it.

merged in casper-network/casper-node#3811