Shielded Address

The shielded address of a shielded account is 96-byte data.

• First 32 bytes represent the rootAddress

• Next 32 bytes represent the signPublicKey

• The last 32 bytes represent the viewPublicKey

The rootAddress is the one which becomes the source for all Blinded Addresses, to which all the user's funds get associated with.

The sign and the view public keys are compressed/packed points on the BabyJubJub elliptic curve.

$$A = a || S || P$$

Address Registration

The protocol uses the shielded addresses for private transactions like sending someone private payments. This necessitates for the sender to know the target or recipient's shielded address. This results in a bad user experience.

This problem is resolved by the address registration step required by the Labyrinth protocol before transacting. During onboarding users are required to register their public wallet address which points to their shielded address. This mapping between public addresses and shielded addresses is stored as event data on-chain. Now, the sender only needs to know the recipient's regular public address or even ENS as a public address can be resolved to a shielded address.

As a security mechanism, it is required for the users to sign (ECDSA) their shielded address and provide the signature, which proves their ownership of the public address, while registering with the Labyrinth protocol. Now, when a sender want to transact with a specific shielded address, they can verify through the RegisterAddress event emitted by the protocol, to be sure that the given shielded address is registered against the public address they actually want to transact with.

Blinded Address

Instead of user funds getting directly associated with the shielded address, in reality, it is associated with a randomised address ( $a$ ) derived from the shielded address root (A), the chosen revoker's public key and a random seed.

$$a = H(A, revoker.x, revoker.y, \delta)$$

We'd refer to these addresses as blinded addresses and is inspired from EIP-5564. Although, we don't follow the address generation in this EIP, it achieves a similar purpose in that an external observer cannot determine the identity of the user (which is $A$ here) given the related blinded address ( $a$ ).

Even if the blinded address appears on-chain, as it happens in anonymous transactions with other protocols, no one gets to know the identity of the beneficiary receiving funds from that blinded address.

A blinded address is 32 bytes in our protocol, unlike regular 20 bytes public addresses.