Giters

o1-labs / o1js

TypeScript framework for zk-SNARKs and zkApps

Home Page:https://docs.minaprotocol.com/en/zkapps/how-to-write-a-zkapp

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

use standard language + settle on test naming convention

harrysolovay opened this issue · comments

commented

I believe inconsistencies in terminology and naming convention may be off-putting to devs.

"zkapp" vs. "contract."

The usage of the term "zkapp" is imo unnecessary. I believe we should stick with "contract" (they are smart contracts, after all). "App" implies more than just the contract. Meanwhile, an app that integrates with a Mina contract may not utilize that contract to model all of its functionality as provable. Does this mean it's still a "zk app?" Devs will pick and choose what parts of their apps touch on Mina.

Test Contracts and Accounts

Copied from #1574

Between the contract names, contract account names and test user names, I think we should settle on a convention.

  • One should never see a contract instance named zkapp; contract should do the trick in cases where there is only one contract in the given test file (and contractPublicKey for the corresponding account).
  • In test files that define multiple contracts, we can name the contracts in accordance with what they do. For a Counter contract, for example counter would be a better instance name than contract or counterContract.
  • While contract TestPublicKeys may need the PublicKey postfix for clarity (aka. counterPublicKey), other account names likely do not need the PublicKey postfix. Thoughts on following this convention moving forward?
commented

Actually zkapp is established in our docs as the term for contract + UI, similar to what you're saying!

commented

I agree on replacing "zkapp" with "contract"

However, "account" for a public key (with attached private key) feels not optimal, there is the distinct concept of an account. So it should stay at "public key" or "address".

Examples:

  • if no disambiguation is needed, we don't need a post-fix e.g. feePayer
  • if we want to name the public key of a contract, where the SmartContract instance is called contract, then the public key should be called contractAddress, not contractAccount because that's less precise and language-mixing
commented

I agree re. "account" vs. "address" –– sounds like we have a convention moving forward! Please assign me to this issue.