make-software / casper-net-sdk-clients Goto Github PK

Summary

Add a client for the new NFT contract CEP78.

Motivation

CEP78 is the new NFT standard promoted by Casper, thus it makes sense to add it also to the SDK Clients library.

Guide-level explanation

--

Reference-level explanation

--

Drawbacks

None.

Rationale and alternatives

--

Unresolved questions

--

Future possibilities

--

1. SDK functions for CEP47 and CEP78 ONLY support tokens whose token id is of type BigInteger. There are custom contracts on testnet and mainnet whose ID is, for example, of the String type. The SDK should support all contract types - NFTs in contracts.
   I understand the reason why only BigInteger is supported (this is how CEP47 and CEP78 are constructed by default), but if the possibility of creating custom solutions is allowed, the SDK must support them.

2. Additionally, in the SDK we have a function that returns the sum of all minted NFTs in a specific contract, but there is no function that will return a list or array of all IDs of minted tokens in the contract.

Summary

Add support for the Account Info Standard in the .Net SDK clients library to ease the process of retrieving account information.

Motivation

The lack of built-in support for the Account Info Standard in the .Net SDK makes it cumbersome to retrieve that information. Providing a streamlined method would enhance the SDK's utility.

Guide-level explanation

• Introduce a new class or method in the client library to handle Account Info Standard operations.
• Example usage would involve calling this new method to either fetch a URL to the JSON file or a type-safe wrapper around the JSON data.

Reference-level explanation

The new feature could be implemented in the clients library as a contract client. Two modes could be supported:

1. A simple mode where the client is provided a URL to the JSON file or update it to a new URL.
2. A more advanced mode offering a type-safe wrapper around the JSON file.

For contract hashes, these could be stored for MainNet and TestNet but configurable for internal test networks. The file name also has to be set to the chain-spec (casper vs casper-test).

Important Note - would be nice if that could be handled automagically:

Payment: The set_url entry point call payment should be 10 CSPR. The deploy may fail with an "Out of gas" error if a smaller amount provided. For the consecutive set_url calls the advised payment amount is 0.5 CSPR

Source

Drawbacks

This feature could add extra maintenance workload and potential complexity to the clients library.

Rationale and alternatives

• This design addresses the issue by providing both quick and comprehensive solutions.
• An alternative is to leave it as-is and require manual handling, which is less efficient.
• The impact of not doing this is continued manual handling of Account Info Standard.

Unresolved questions

• Should the contract hashes for internal test networks be passed as optional parameters?

Future possibilities

• Add a Validation-utility using the existing JSON Schema

What happened?
A call to SetContractPackageHash() stores the package hash in the client so that an entry point can be called via package hash instead of contract hash. However, it not permits to read data from the contract. For that, SetContractHash() must be used.

What did you expect to happen?
SetContractPackageHash() may fetch the contract hash and use it to query the named keys.

Are you willing to submit a pull request to fix this bug?