MIP-0004: Fungible Token Standard with UTxO

[nstanford5]

Please use this thread to discuss details and ideas regarding MIP-0004

One important note based on review -- all ledger fields are public. The export keyword only denotes that the compiled artifacts will include a JS binding for the value to make it easily accessible to frontend implementations. Private values needing to be stored in the ledger should make use of Compact hashing or commit functions

Contributors: @dvgui

[nstanford5]

From @kapke

Shouldn't shielded and unshielded extensions be separate to not force supporting both styles if not desired by the contract authors?

[dvgui]

I think on the spec we should make having at least one of the circuits, as well as the reverse path as mandatory. Either shielded or unshielded. Otherwise, there's no use for the token. But I agree it should be added.

[nstanford5]

From @kapke:

May be worth adding - the coin provided is an output, not input, so the value is determined by the DApp, not the shielded coin held in wallet.

[dvgui]

I'm a bit lost about this, can you quote where specifically?

[kapke]

The unshield(coin: ShieldedCoinInfo) → [] takes a coin. This coin is materialized in the transaction as an output. Wallet will provide inputs to cover for it. In the end, the difference becomes whether the nonce is computed in circuit or provided as an argument.

[nstanford5]

From @kapke:

One thing worth mentioning - the tokens converted into native UTxOs are not controlled by the contract. They may be moved around freely without any control or oversight from the contract.

[dvgui]

Yes, we can add this for clarity.

[nstanford5]

If a mint circuit is provided, the implementation MUST authenticate the caller via a hash-based commitment rather than ownPublicKey(). The reference implementation declares:

witness secretKey(): Bytes<32>;

export ledger admin: Bytes<32>;
export ledger minter: Bytes<32>;

secretKey(): A witness function returning the caller's 32-byte authentication secret. The secret lives only in the caller's private state and never appears on-chain or in any disclosed circuit value.

NOTE: This is not the only way to retrieve the secret from the callers private state. Private state data can also be passed directly into circuit inputs (while still maintaining privacy), so the witness as a private state "getter" is not completely necessary. There is nothing wrong with doing it this way, only that this is possible without a witness function. See private-party tutorial and codebase

[dvgui]

Is there a benefit (in computation or cost) in using private state? Happy to replace that section if there's an upside!

[kapke]

The benefit in this context is security. Anyone can implement anything they want as witnesses and/or provide any private state they want. So using a possibly publicly known data for authentication means that possible breaches are relatively simple.

Otherwise, in a more general context - yes - performing computation in witness functions is much cheaper, but it requires computation to be verified in-circuit to prevent security issues.

[kapke]

Disregard my comment above. I misunderstood other comments.

In this context - providing the secret via witness or contract argument does not change anything. Outputs of witness functions get turned into private inputs, exactly as circuit arguments.