CIP-0171? | On-chain Smart Contract Bytecode Verification

[nemo83]

Cardano Smart Contract Verification onchain metadata standard

Cardano Forum discussion link: https://forum.cardano.org/t/cip-idea-smart-contract-source-code-verification-metadata/152403
Open Source Code: https://github.com/easy1staking-com/uplc-link
Website: https://uplc.link

---

(rendered latest document)

[kenerik]

Great initiative!
Imagine connecting your wallet to something, also seeing that "yes, it is actually this smart contract"

[rphair]

@nemo83 I've scheduled this for Triage at tomorrow's CIP meeting (https://hackmd.io/@cip-editors/126) and you're welcome to attend & introduce the proposal yourself. If you're not there I'll also quickly review the response when this proposal was aired to the community on the Forum earlier (as linked before).

[nemo83]

@rphair thank you so much for this. I shall be there today! Looking forward to discuss this CIP!

[Ryun1]

awesome proposal, well written and well motivated
happy to see a number assigned and this move through the process 💪

discussion from CIP call # 126

• This standard allows for functionality to be added to Cardano tooling to bring contract verification functionality, similar to what is seen in other ecosystems i.e. ethereum with etherscan
• additionally, a 'next step' could be to support further contract analysis tooling, such as exposing contract's functions for users to be able to test functionality similar to etherscan's Write Contract functionality

[Ryun1]

@nemo83

I see some potential overlap with this proposed standard and CIP-0072 | Cardano dApp Registration & Discovery
Might be worth a read.

[rphair]

overlap with this proposed standard and CIP-0072

@Ryun1 I also thought that when I was writing this forum comment... though I chose the CIP-0088 comparison instead, since I think the impact of this proposal will be equally broad.

@nemo83 my impression was that this CIP could help address some of the authentication problems identified in CIP-0072 that would be more difficult with that CIP alone.

[nemo83]

Thanks @Ryun1 and @rphair for flagging CIP-0072 - I've reviewed it and agree there's a relationship worth clarifying.

How they differ:

	CIP-0072	This CIP
Scope	dApp (application-level metadata)	Script (code-level verification)
Data	Name, logo, company, categories, script hashes	Repo URL, commit, compiler, parameters
Trust model	Requires trusting whoever makes the claim	Trustless - reproducibility and cryptography do the heavy lifting

CIP-0072 seems to focus on answering "what is this dApp?" while this CIP answers "where did this script come from?"

For this reason I believe the two CIPs are actually complementary, and as Robert mentioned, CIP-0072 could leverage this CIP to address some of their challenges.

CIP-0072 lists script hashes but doesn't verify their origin. Anyone can claim any script hash belongs to their dApp. This CIP provides the missing cryptographic link: if you can compile the source at the specified commit and produce the same script hash, verification is objective and reproducible: no vetting or trust required.

The two could work together: a dApp registers via CIP-0072, and the scripts it claims are independently verified via this CIP. Stores/wallets could then show both the dApp metadata and source verification status.

That said, I believe they should remain independent CIPs as they operate at different levels (dApp vs script) and serve different purposes. Happy to add a "Related Work" section acknowledging CIP-0072 if that would be helpful.

[rphair]

Happy to add a "Related Work" section acknowledging CIP-0072 if that would be helpful.

yes @nemo83 I believe it would be helpful: to keep verification methods like this developing in parallel. As @colll78 mentioned in the CIP meeting today, your proposal here plus any complementary tools would effectively bring Cardano into feature congruence with Etherscan and attract more of the dev community that would expect something like this when coming from EVM chains & Solana.

I also meant to mention at the meeting that we've already accommodated a bit of community feedback in diversifying the source location beyond GitHub to any Git capable host: as progressed on the Forum.

Please @nemo83 also update the containing directory to CIP-0171 and update the link in your PR initial comment 🎉

[colll78]

Also if this wasn't clear in my initial review, @nemo83 incredible work on this. This is very high impact tooling that has been missing from the ecosystem for far longer than it should have. Massive props to taking ownership of this and driving it to the finish line.

This type of behavior absolutely should be championed, the more people we have who drive things like this, the faster we as an ecosystem accelerate in the competitive blockchain space.

If you need any help with implementing Plutarch support, or with adding the writeContract functionality feel free to reach out.

[nemo83]

Hey, @colll78 , thanks for the kind words of appreciation and encouragement. I will be looking at integrating next building tools in the upcoming days and will definitely reach out if (probably when! 😅 ) I get stuck with plutarch!

[rssh]

Compilation is nontrivial and differs across languages.
We can ask developers to provide a standardized build command, but this opens the door to possible attacks. (buildscript can patch sources).

Looks like compiler vendors should provide a non-configurable build tool.

[nemo83]

I agree with you we should NOT leverage build scripts, as they open all sort of cans of worms in terms of security. From a backend PoV I do plan to run everything in isolated containers, so no problem if they manage to screw it eheh, but in general we should reduce as much as possible the attack surface.

Luckily Aiken don't offer compilation flags (beside the verbosity which I hope everyone has turned off for mainnet). This is another reason why I built the PoC w/ Aiken.

That's definitely not the same for Haskell based compilers, where a number of flags/params might be required.

The good thing about the current design is that I'm leveraging an union type, where Constr(0) is the paremeterless aiken contract definition (i.e. there is no field to specify additional compilation params, but just vanilla aiken build), and there aren't other types defined just yet. With the help of compilers devs, I'm gonna analyse case by case and refine the onchain serialization for other compilers.

I think that there will be a good chunk of contracts currently deployed on mainnet which we won't be able to verify. Hopefully though, devs of current and future contracts, will ensure the build of their contracts is reproducible outside of their working environment.