Technical Architecture
Last updated
Last updated
Raze Network will apply the Zether framework to build the second-layer decentralized anonymous payment module. It will be then imported as substrate-based smart contracts. Similar to the Zether framework, it will have three technical modules: mint, transfer and redeem. The mint module will convert a base token into its anonymized version, while the redeem module will convert the anonymized token back to its native form. The transfer module is the one that enables the anonymous transfer of the anonymized token. This process will conceal the transaction amount and guarantee the anonymity for both the sender and receiver.
The mint module will create a Raze account by running a mint contract and deposit the anonymized token to the Raze account. Each Raze account is identified by a public key pk and the mint module will generate a ciphertext under the account public key which encrypts the amount of minted token. If the account has already existed before the mint operation, the generated ciphertext will be homomorphically added to the existing ciphertext to increase the encrypted amount.
Since the balance and transaction amount of each Raze account is encrypted and therefore hidden, the remaining question for the transfer module is how to hide the identities of the involved parties. Similar to the anonymous transfer module of the Zether scheme, we hide the identities of the involved parties through the "one-out-of-many" proof. The "one-out-of-many" proof is conceptually close to ring signature, which proves that a transaction is launched by one of the many parties in the anonymity set (or the ring) while not revealing exactly whom among them is the sender or receiver of the transaction, and thus hide their identities. The transfer module's zkp will also prove the payment consistency and provide a range proof demonstrating there is no negative amount involved in the transaction, which could potentially allow the adversary to create money out of thin air.
The redeem module converts the anonymized token back to its original form. The redeem module also needs to invoke a zero-knowledge proof functionality to prove that the user initiating the redeem module knows the secret key of the corresponding Raze account and the redeemed amount is smaller than the Raze account balance.
To sum up, Raze uses public-key homomorphic encryption to ensure transaction details remain confidential and uses the "one-out-of-many" proof to hide the sender and receiver identities, and some other zero-knowledge proof schemes are also used to guarantee the payment consistency. Whenever a user deposits a certain amount of token through invoking the mint module, the token is no longer traceable.
To facilitate DeFi functionality, we have two additional modules: lock and unlock. The lock module allows an account owner to lock the account while the unlock module allows the owner to unlock the account.
We will also build a cross-chain bridge that can map any ERC-20 token to the Polkadot blockchain and thus enable the cross-chain payment of these tokens.
Each raze user can register a raze account any time(s) he wishes. The registration algorithm CreateAddress generates a secret key sk and the corresponding public key pk. The public key is the identifier of the Raze account.
To invoke the Mint contract, the client-side runs a CreateMintTx algorithm, which takes as input the raze account pk and the amount of native token amt as inputs. The output of the CreateMintTx algorithm is a ciphertext cp_1 encrypted under the public key pk. If the raze account pk is already attached with a ciphertext cp_0, the newly created ciphertext will be homomorphically added to the existing ciphertext to increase the encrypted amount. The updated ciphertext will be formed as cp_1*cp_0. Otherwise, the new ciphertext will be attached to the raze account. The native token will be stored in the mint contract.
To invoke the transfer contract, the client-side runs a CreateTransferTx algorithm, which takes as inputs the raze account secret key sk, and the amount of transferred token amt, the public keys of sender pk_s, receiver pk_r and the public keys of the anonymity set {pk_a}. The output of the CreateTransferTx algorithm is a zero-knowledge proof that the prover knows one of the secret keys of the aforementioned public key set, the payment consistency proof, and range proof. The statement of this zkp is
The client-side runs a CreateRedeemTx algorithm to invoke the redeem contract. It takes the account secret key sk, the withdrawal amount amt, and the public key pk as input to generate a zero-knowledge proof showing that the user knows the secret key sk for the account public key pk and the account has enough balance for the redeem operation. The zero-knowledge proof will be used to invoke the redeem contract. The statement of this zkp is
The user can invoke the lock module by running a CreateLockTx algorithm on the client-side. The client inputs a secret key sk and an Ethereum address addr to generate a signature to demonstrate he is indeed the owner of the account and he authorizes to lock the account to the input address addr. The signature would be Sign(x, addr). Similarly, the user can invoke the unlock module by running a CreateUnlockTx on the client-side. The input of CreateUnlockTx algorithm is the same as that of the CreateLockTx algorithm. It will generate a similar signature to unlock the account. Note, we will embed a nonce derived from the current epoch number to prevent the replay attack.
The ultimate goal is to provide a SDK from a high-level perspective with the above functions. The RazeVM will include the following modules described above.The SDK will include the client that supports the Register, CreateMintTx, CreateTransferTx, CreateRedeemTx, CreateLockTx, and CreateUnlockTx algorithms. The clients will be able to generate the necessary transactions to trigger the corresponding modules.
