`(code-body-of? principal)` to fetch the code body of a specific contract

[wileyj]

duplicated from clarity-lang/reference#88

I suggest the introduction of a new function code-body-of? that returns the code body of the specified contract principal. The function will unlock various new use-cases and will allow other contracts to prove contracts are designed in a specific way. It would replace aspects of the clarity-stacks library.

Signature: (code-body-of? principal)
Return type: (response string-ascii uint)

Return values:

• (ok "code body string") on success.
• (err u0) if the principal is not a contract principal.
• (err u1) if the specified contract does not exist.
• (err u2) if the code body does not fit in the string-ascii.

The function would provide the minimum necessary to make it possible to prove code bodies, and can be combined with existing functions such as sha256. It would also be made more useful if Clarity 4 offers more string manipulation and conversion functions. (Suggested in different issues in this repo.)

[wileyj]

Adding here for tracking - there is more discussion in the source issue clarity-lang/reference#88

cc @MarvinJanssen @obycode @whoabuddy @r0zar @GAD2511 @Rapha-btc

[jcnelson]

Echoing what @obycode said in the linked issue, the biggest bang-for-buck feature folks are after is getting the contract code body's hash instead of the code body itself. This is what allows contracts to verify that a trait implementation adheres to a particular template, which allows contracts like DeFi exchanges to automatically verify that the token contracts they list will exhibit known behaviors (meaning, users can list their token contracts directly into the exchange contract in safe, self-service manner)

I think that this needs to ship with an additional built-in (code-body-hash-of? principal) function, since loading the hash of the contract is far cheaper (and is O(1) modulo DB searches) than loading the entire code body, only to hash it.

[jcnelson]

(sorry, fat-fingered)

[MarvinJanssen]

My original argument for code-body-of? versus code-body-hash-of? was one that had been used in other various new function proposals; namely, to keep the semantics and compatibility of Clarity. (Seen in the thread.) However it sounds like there is a really good argument in terms of performance to have both functions. Most people probably just want the hash anyway, so you'd start seeing a lot of (sha256 (unwrap-* (code-body-of? principal))) structures.

I think code-body-of? still has a lot of creative merit so my suggestion would be to have both functions and have good documentation on when to prefer one over the other.

[kantai]

I'd prefer only implementing code-body-hash-of? -- for me, the rationale is that the hash is "good enough" because anyone that wants to use the actual code body can just supply the body from an external source and check the hash in the transaction, so there's no real need to supply the cody body from clarity, and then the argument against implementing it is that "less is better" in terms of new clarity built-ins.

[jcnelson]

I'm inclined to agree with @kantai on this. @MarvinJanssen is there a specific use-case you have in mind that cannot be implemented by the caller supplying the code body and authenticating it via its hash?

[obycode]

I don't have a strong opinion on this one. Either way, the usage is nice and clear and the implementation is simple, so I'm on board with whichever.