not approved

Contract Labeling & Transparency

$68,000.00 Requested
Ideascale logo View on ideascale
Community Review Results (1 reviewers)
Addresses Challenge
Feasibility
Auditability
Problem:

<p>Functionality of smart-contracts is not knowable to end-users.  Lack of user confidence will limit general adoption.</p>

Yes Votes:
₳ 35,069,162
No Votes:
₳ 52,710,585
Votes Cast:
361

  • Video cover image

Detailed Plan

Summary: we will research and develop recommendations for all smart-contract developers and wallet authors to provide transparent labeling to end-users about the smart contracts they'll be engaging with. By ensuring access to this labeling for every smart-contract on Cardano, we will send a clear signal to the world that this is a place where people can transact together more safely than they can on any other blockchain.

How can we create a positive developer experience that helps the developer focus on building successful apps? -> BY delivering trust signals to end-users to enhance their experience and user trust at critical payment-sending moments during their onboarding to every Cardano-enabled app.

A simple example involves a set of people using an NFT-selling contract: the developer who wrote the contract, an artist who sells an NFT for their art using that contract, and people who buy the NFT and later resell it. All of the people with an interest in this contract's results should be able to clearly see what expectations they can have when they use the contract (special thanks to Ken Adams (KEWW) for detailing this use-case in the Sept 8 community workshop in Catalyst After-townhall session).

From NFT's to Auctions, from Real Estate to Loans: truth in labeling fosters user confidence.

That's our trust protocol: enabling all the stakeholders to have clear, human-readable information about each contract's behavior. Enabling them to entrust their funds to smart contracts on the basis of being well informed.

As with many people, when I first encountered the idea of a smart contract, it was CryptoKitties. I read an analysis based on disassembling the compiled Solidity contract and analyzing the resulting (still abstract) code to infer its behavior. The failure of Solidity to use Lambda calculus for expressing behavior functionally and compositionally was striking - oh, the many risks of programming something wrong by accident (so easy in procedural programming)! … all multiplied by arbitrary amounts of REAL MONEY.

More subtly, a whole class of risks became clear: that, even given a functional smart contract language (thank you Plutus!), allowing contracts to be "verified correct", certain types of behavior can be coded into them that would be undesirable to one or more of its stakeholders: siphoning fees during edge-cases, publishing identity details in on-chain metadata, or other forms of misbehavior. All while passing automated formal verifications.

Web 2.0 shifted the nature of user-experience, but it has extended the model where server-side components do black-box activities: no transparency, low accountability for the results. Web3 is bringing tectonic changes: distributed data streams, blockchain and other decentralized transaction dynamics… reliance on discrete central servers starts to fade away, and financial transactions are more and more easily integrated to the applications, but there remains little in the way of a TRANSPARENCY layer for people to know the effects of these applications - in particular, the financial effects, encoded in behaviors of smart contracts where their money is held in trust.

Currently, the general population relies on centralized authorities and payment providers to provide assurance and act as arbiters should transactions not be executed as they expected. While blockchain technology eliminates the need and costs of utilizing these authorities, the lack of recourse if transactions are not executed as expected further necessitates the general population's need for clear transparency and assurance in the behavior of the smart contract.

There are, without a doubt, many (or even most) current smart contracts running on Ethereum that are just doing a simple job, doing it reliably and with source code openly available. Even so, it all looks like "dark web" to the general population. Is that what we want for Cardano?

We assert that OUR ecosystem can thrive exponentially by providing transparent assurances and infrastructure for people to engage with and easily understand meaningful trust signals about all the smart contracts that will play roles in their lives. Providing consumer-grade transparency and assurances about behavioral expectations from our smart contracts will enable Cardano to be Generally Recognized as Safe.

<u>Challenge Metrics and Questions</u>: Smart contracts being recognized as safe will enable for broader scale adoption, which in turn will encourage more developers to develop with Cardano. That's essential to this challenge's brief. Ditto, attracting developers from outside of our current community. What are enterprise dev managers looking for? we think one major thing they want is to know that the blockchains they commit to will deliver them audience - that it is ready for primetime.

Open-sourcing our contracts is not enough. Passing them through automated formal validations is not enough. Even delegating validation to organizations specializing in human review is insufficient without publicly-visible promises:

  • Things this contract will do
  • Things this contract promises to NOT do

These protocols are tools that need to be developed at the early stage of smart contract development in Cardano to ensure that developers are aware of assurance standards as contracts are developed.

This proposal is cosponsored by Gimbalabs, where we are mobilizing everyone to develop tools and applications through a unique experience of co-creation that facilitates adoption of the Cardano protocol, reveals new possibilities, and ignites the public imagination worldwide. Gimbalabs serves a large group of developers through its Playground network, which provides networking and professional development to the Cardano community.

Gimbalabs has been doing the hard work during the last 4 funding rounds, creating products such as the Dandelion APIs and the Dandelion Incentivized Alpha Network. We have been champions of project-based learning, and we're pleased to refer you to our latest video update (8 Sept 2021), in which we're demoing our 1:1 Scheduling application, highlighting our DiD functionality, and a revenue-enabling platform for people to trade skills, assistance, and ADA.

<https://www.youtube.com/watch?v=DQxDmU6GqPY>

Plan and scope

We will conduct market research to determine what are the key assurances that the general population expects before confidently executing a transaction.

We will develop data-structural schemas for expressing human-readable expectations for smart contracts, and safeguards to support transparency of what smart contracts will do. These data will be essential human input to formal verification processes, as well as for human-based code-review activities contributing to public trust in Cardano's smart-contract environment.

We will research and explore the feasibility landscape for techniques to connect smart contracts together with the "product labels" representing consumer expectations.

We will develop protocols for wallet software to find, validate and present the product labels for smart contracts used by wallets. We will design these protocols to be forward-compatible to accommodate future enhancements, with guidelines for wallets to also be forward-compatible. In scope for this research and development include such concerns as:

  • Smart-contract registration to a decentralized registry
  • Smart-contracts: parameterized vs generic, and reusing the labeling
  • Multi-contract transactions and transaction labeling
  • Usability considerations for wallet UI's
  • Distributed storage for detailed requirements
  • Remembering a person's decisions for contracts they decided to trust
  • Possible utility token for contract-labeling, if needed

JOIN US at the Catalyst Swarm and at Gimbalabs on Discord

Timeline and Key Deliverables

  • Prior to Sept 9 2021, we will conduct a community session to explore these and other considerations for ensuring we are covering a reasonable scope around smart-contract transparency and labeling.
    UPDATE - DONE: great context and input received. +audience: smart-contract instantiators. +audience: real-estate professionals. +contributor: Noah Jones. Thanks to you all for joining and expressing your interest, support and perspectives. We're stronger together!

  • In November 2021, we will conduct two additional community sessions to explore the problem space and provide transparency around our initial research. This will also help us to identify next opportunities for important additions to the protocol and establish a roadmap for further recommendations. We will provide draft data schema(s) for transparency information about smart-contracts.

  • In December 2021, we will deliver a whitepaper presenting our findings and recommendations, and if needed, one or more CIPs to formalize the best methods we find during our research.

  • By the end of Jan 2022, we expect to provide a reference implementation in at least one wallet application, demonstrating a viable opt-in experience for people to review the contract labeling and make trust decisions. Adriano of the GameChanger wallet is ready and willing to do this work with us (thanks!), and we're keen to help him make GameChanger everything it can be, as well.

Community is an essential part of creating the next level of effectiveness for Blockchain. Come help us develop plans, write prototypes and prove out techniques. Help us refine our CIP(s). We are including budget for community contributors. Together, we can.

Success Metrics and Checkpoints

…at the 3-month mark: Delivered draft schemas, results of community-engagement and prototyping phase, and draft CIPs for requested protocol-enhancements. Video updates.

…at the 6-month mark: Smart contracts having user-trust labeling metadata; percentage of new smart-contracts having attached user-trust metadata.

…at the 12-month mark: Engagement/trust metric: "Do you understand and trust how smart contracts work on Cardano?"

Requested funds in USD

  • Market Research $5,000
  • Prototyping and technical proofs of concept: $12,000
  • Community participation rewards: $6,000
  • Wallet integration $21,000
  • Dandelion Service development: $8,000
  • Project Management: $8,000
  • Flex budget: Additional development, research and improvement proposals: $8,000

Total: $68,000

We have made an effort to balance our estimates between the conservative and the risk-averse, but we acknowledge that this is an unexplored problem space with a significant research component. We remain committed to delivering meaningful guidance, data schemas, improvement proposals and in-app experiences to ensure that Cardano becomes the best-trusted blockchain available. In the event of any cost overrun, we will request supplementary budget in future funds, with all supporting details provided in that proposal.

…compared to other proposals: One of our members is also proposing Smart Contract Blacklisting, which plans to respond to Emerging Threats in our ecosystem. A contract with transparent labeling might still get flagged for the blacklist (say, for usurious fees or other reasons), and there are other distinct points of utility to be found on both paths. Blacklisting has its own set of concerns, relating to reputation of issue-reporters, momentum for community-reported contract alerts, and more. Thank you for recognizing the important distinctions and separate value for both truth-in-labeling and for smart-contract blacklisting.

<https://cardano.ideascale.com/a/dtd/Smart-Contract-Blacklisting/368335-48088>

Community Reviews (1)

Comments

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00