Feat/dkg contract interaction

[soju-drinker]

Description

This PR adds the ability for the Signer to interact with Clarity contracts

Applicable issues

• needed for [stacks-signer] coordinator should trigger DKG automatically as required #3971

Checklist

• Read only contract calls
• Submit tx contract calls
• Simulate contract call responses in tests

[codecov]

Codecov Report

Merging #3989 (c9b6528) into develop (f6668d8) will decrease coverage by 0.01%.
Report is 1 commits behind head on develop.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           develop    #3989      +/-   ##
===========================================
- Coverage     0.16%    0.16%   -0.01%     
===========================================
  Files          337      337              
  Lines       286814   287084     +270     
===========================================
  Hits           469      469              
- Misses      286345   286615     +270     

Files	Coverage Δ
stacks-signer/src/config.rs	0.00% <0.00%> (ø)
stacks-signer/src/stacks_client.rs	0.00% <0.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[jcnelson]

I don't know if this is ever going to be a concern, but if you're registering a BNS name, then you'd also need to supply an Attachment which contains the name's zonefile data.

[jferrant]

I am not entirely sure what this means XD Forgive me...

[jcnelson]

Ah, so there's this storage system in the Stacks node called Atlas It's a hold-over from the Blockstack / Stacks 1.0 days. Basically, a smart contract can emit specially-crafted Atlas events which contain the hash of a chunk of data. The Atlas system tracks these hash announcements, and then communicates with other Stacks nodes to see if they have a chunk of data which hashes to it. Eventually, all nodes get a copy of this "attached" data. We use it in BNS to tie a BNS name to a zone file, as well as other off-chain data like Nostr public keys and such.

I don't think the signer is ever going to use Atlas, so it's not a big deal if you're not going to support attachments. However, if this module becomes more generic and gets spun off into its own crate, it might become important later to add support.

[soju-drinker]

Pulled out the ureq suggestions into a separate issue - #3995

[jcnelson]

We have specific containers for contract names, function names, and function arguments, since they have to use limited character sets and since not all strings are valid. You should use ContractName and ClarityName here instead of a bare &str. Also, function_args should be &[clarity::vm::Value] in both cases.

[jferrant]

Quick note, can you create a valid "StacksAddress" from the pox contract address? My initial attempts have failed. The reason I changed this to String was to accommodate this. However, perhaps I am just doing it wrong? Attempts to convert ""ST000000000000000000002AMW42H.pox-3" to a QualifiedContractID fail. Further attempts to split the string and then convert the first half to a StacksAddress also fails.

[jcnelson]

Sure -- QualifiedContractIdentifier::parse("ST000000000000000000002AMW42H.pox-3").unwrap() should work.

[jferrant]

Sorry, I was not clear. This is what I already tried and it results in
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Runtime(ParseError("Invalid principal literal: base58ck checksum 0x51104e95 does not match expected 0x31287a31"), None)', stacks-signer/src/stacks_client.rs:315:83

This is the same result as trying to parse ST000000000000000000002AMW42H as a StacksAddress.

[jcnelson]

This PR is on the right track, but it needs a few changes:

• It needs to use ContractName, ClarityName, and clarity::vm::Value instead of bare &strs
• The StacksContractCallable trait may not need to exist

[jferrant]

LGTM

[xoloki]

LGTM. More tests would be nice, especially if they weren't mocked, but this is fine for now.