Signature Verification

There are many signature schemes. Sui interoperability is mainly dependent on supporting multiple signature schemes, among which are the following:

Groth: Zk-Proofs on Sui

Zk-proofs have become commonplace on many L1 blockchains and L2 rollups. A zero-knowledge proof allows a prover to validate that a statement is true without revealing any details about the private inputs. A good use case for this is approving a loaner's credit history for a bank or a non-bank financial institution.

Zero-knowledge succinct non-interactive argument of knowledge (zk-SNARKs) are a family of non-interactive zero-knowledge proofs with succinct proof size and efficient verification time. An important and widely used variant is pairing-based zk-SNARKs like the Groth16 proof system, which is one of the most efficient and widely used.

ZkLogin is the most prominent use case of zk-proofs on Sui. With ZkLogin, you can send transactions from your Sui address using an OAuth credential, concealing the link between the two. This function brings in the following benefits:

• Streamlined and easy onboarding: You don't have to memorize mnemonic phrases or store them somewhere, and you are freed from the labor of handling cryptographic keys, which can be lost or hacked, to make things worse.
• Self-custody: a zkLogin transaction is run using the standard OAuth login process, whereas the OAuth provider cannot transact on the user's behalf.
• Security: a two-factor authentication scheme is used; to send a transaction, one must provide both a credential from a recent OAuth login and a salt to which the OAuth provider cannot access.
• Privacy: Zero-knowledge proofs ensure privacy by not allowing third parties to associate a Sui address with its corresponding OAuth identifier.
• Optional verified identity: A user can verify the OAuth identifier that was used to derive a particular Sui address.
• Accessibility: zkLogin is natively supported by Sui.
• Rigorousness: Two companies with zk-proof competence have audited the code for the zkLogin.

The zkLogin function is as follows:

1. A JSON Web Token (JWT) is generated, which is a signed payload from an OAuth provider. It stores a user-defined field called nonce. The zkLogin uses the OpenID Connect OAuth flow and sets the nonce as a public key and an expiry epoch.
2. The wallet holds an ephemeral KeyPair. The temporary public key is set in the nonce. The temporary private key signs transactions for a short session, removing the need for the user to remember it. Based on the JWT, a Groth16 zero-knowledge proof is generated, hiding fields that are sensitive to privacy.
3. A transaction with the temporary signature and the zk-proof is sent on-chain. The Sui authorities carry out the transaction after they verify the temporary signature and the proof.
4. The zkLogin address is derived from 1)sub (which uniquely identifies the user per provider), 2)iss (identifies the provider), 3)aud (identifies the application), and 4)user_salt (a value that disconnects the OAuth identifier from the on-chain address). This is different from deriving the Sui address based on a public key.

Hash Functions

A hash function is a mathematical function that converts any digital data into an output string with a fixed number of characters.

Sui supports the following cryptographic hash functions:

• SHA2-256
• SHA3-256
• Keccak256
• Blake2b-256

Elliptic Curve Verifiable Random Function

A verifiable random function (VRF) is a cryptographic primitive that enables you to generate a random number and provide proof that the number was generated using a secret key. It adds an element of randomness to the process.

Elliptic Curve Verifiable Random Function (ECVRF) is the random function employed by Sui. It uses Ristretto255 elliptic curve group construction with the SHA-512 hash function. The nonce is generated according to RFC6979.

Read more about Sui cryptography in the official Sui docs.

Multisig

The Sui network enables k-out-of-n multisig transactions, where a transaction is authorized if at least k signatures from a total of n-weighted participants are present, with a cap of 10 participants. The system recognizes three key types: Ed25519, ECDSA Secp256k1, and ECDSA Secp256r1, and each is assigned a u8 weight. Transactions execute when the combined weight of valid signatures meets or exceeds a u16 threshold.

Multisig accounts in Sui offer versatility by allowing different key schemes within a single account, such as combining an Ed25519 mnemonic-based key with two ECDSA secp256r1 keys. This configuration can serve as two-factor authentication, especially since current iPhones and high-end Androids support ECDSA secp256r1 keys in secure enclaves.

In contrast to threshold signatures, multisig accounts are more user-friendly and less complex to set up. They do not require intricate ceremonies or dependencies on threshold cryptography providers and provide accountability and transparency, as the signatories of each transaction are visible.

The table below shows which multisig policies are supported on Sui.

Here you can find a guide on how to create a multisig transaction.

Offline Signing

Sui supports a function where a user can sign a transaction using a device not connected to the Sui Network. For this, the following steps have to be completed:

1. Data serialization for signing using the Binary Canonical Serialization (BCS).
2. Signing the serialized data.
3. Execution of the signed transaction.

Intent Signing

On Sui, an intent is a compact struct that serves as the domain separator for a message to which a signature commits. The data that the signature commits to is an intent message. All signatures in Sui must commit to an intent message instead of the message itself.

The intent signing standard provides a compact domain separator to the data being signed for both user signatures and authority signatures. It has several benefits, including:

• The intent scope is replaced by a u8 representation instead of a Rust struct tag name string.
• In addition to the intent scope, other important domain separators (such as intent version and app ID) can be committed.
• The data itself no longer needs to implement the Signable trait, it just needs to implement Serialize.
• All signatures can adopt the same intent message structure, including both user signatures (only to commit to TransactionData) and authority signatures (commits to all internal intent scopes such as TransactionEffects, ProofOfPossession, and SenderSignedTransaction).