Client: Contract call arguments should be serialized by default

[agraebe]

Currently, the client requires contract call arguments to be manually serialized:

await smartContracts.callReadOnlyFunction({
    contractAddress,
    contractName,
    functionName,
    readOnlyFunctionArgs: {
      sender: stxAddress,
      arguments: [
        `0x${serializeCV(
          tupleCV({
            hashbytes,
            version,
          })
        ).toString("hex")}`,
        `0x${serializeCV(uintCV(microSTXoLockup)).toString("hex")}`,
        `0x${serializeCV(uintCV(poxInfo.reward_cycle_id)).toString("hex")}`,
        `0x${serializeCV(uintCV(numberOfCycles)).toString("hex")}`,
      ],
    },
  });

It seems that 0x${serializeCV(<ClarityValue>).toString("hex")} is the default required. The client should handle this, so an API call could look like this:

await smartContracts.callReadOnlyFunction({
    contractAddress,
    contractName,
    functionName,
    readOnlyFunctionArgs: {
      sender: stxAddress,
      arguments: [
        tupleCV({
            hashbytes,
            version,
          }),
        uintCV(microSTXoLockup),
        uintCV(poxInfo.reward_cycle_id),
        uintCV(numberOfCycles),
      ],
    },
  });

[agraebe]

@zone117x I wonder if this is best handled on the API level so that the endpoint implicitly converts the input from the client?

[zone117x]

This is a proxied core-node endpoint, but we could make a new endpoint under /extended that provided this feature. A bit of this logic already exists in the debug /contract-call POST handler https://github.com/blockstack/stacks-blockchain-api/blob/8612ea838717ef8d0fe4dee0603f6cf370e23819/src/api/routes/debug.ts#L625-L631

Also the same logic (automate Clarity encoding via ABI inspection) could be used client-side as well. We could add it to the client lib in this repo, or in stacks-transactions if that is more appropriate.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sabbyanandan]

+1 to not leak the SerDe responsibility to the end-users. In general, encapsulating (complexity like the SerDes) internally would be a welcome improvement for the end-users. I am also liberally assuming this would be an end-user-facing touchpoint; please correct me if I am wrong in my naive understanding. 😆

[sabbyanandan]

Closing this due to no activity.