Assets and Values
Penumbra can record arbitrary assets. These assets either originate on Penumbra itself, or, more commonly, originate on other IBC-connected chains. To record arbitrary assets and enforce value balance between them, we draw on ideas originally proposed for Zcash and adapt them to the Cosmos context.
Asset types and asset IDs
To be precise, we define:
- an amount to be an untyped
u128
quantity of some asset; - an asset ID to be an element;
- a value to be a typed quantity, i.e., an amount and an asset ID.
All asset IDs are currently computed as the hash of a denomination, an ADR001-style denomination trace uniquely identifying a cross-chain asset and its provenance, such as:
denom
(native chain A asset)transfer/channelToA/denom
(chain B representation of chain A asset)transfer/channelToB/transfer/channelToA/denom
(chain C representation of chain B representation of chain A asset)
However, Penumbra deviates slightly from ADR001 in the definition of the asset
ID. While ADR001 defines the IBC asset ID as the SHA-256 hash of the
denomination trace, Penumbra hashes to a field element, so that asset IDs can be
more easily used inside of a zk-SNARK circuit. Specifically, define
from_le_bytes(bytes)
as the function that interprets its input bytes as an
integer in little-endian order, and hash(label, input)
as BLAKE2b-512 with
personalization label
on input input
. Then asset IDs are computed as
asset_id = from_le_bytes(hash(b"Penumbra_AssetID", asset_type)) mod q
In the future, Penumbra may have other asset IDs do not correspond to denominations, but are computed as hashes of other state data. By making the asset ID itself be a hash of extended state data, a note recording value of that type also binds to that extended data, even though it has the same size as any other note. Currently, however, all asset IDs are computed as the hashes of denomination strings.
Asset Metadata
Penumbra also supports Cosmos-style Metadata
for assets. The chain maintains
an on-chain lookup table of asset IDs to asset metadata, but the on-chain
metadata is minimal and generally only includes the denomination string. Client
software is expected to be opinionated about asset metadata, supplying
definitions with symbols, logos, etc. to help users understand the assets they
hold.
Value Generators
Each asset ID has an associated value generator . The value generator is computed as , where is a hash-to-group function constructed by first applying
rate-1 Poseidon hashing with domain separator
from_le_bytes(blake2b(b"penumbra.value.generator"))
and then the decaf377
CDH
map-to-group method.
Homomorphic Balance Commitments
We use the value generator associated to an asset ID to construct additively homomorphic commitments to (typed) value. To do this, we first define the blinding generator as
V_tilde = decaf377_encode_to_curve(from_le_bytes(blake2b(b"decaf377-rdsa-binding")))
The commitment to value , i.e., amount of asset , with random blinding factor , is the Pedersen commitment
These commitments are homomorphic, even for different asset types, say values and :
where and are generators of the group , and and are random blinding factors from .
Alternatively, this can be thought of as a commitment to a (sparse) vector recording the amount of every possible asset type, almost all of whose coefficients are zero.