Pioneering Privacy Horizons: IZAR’s Breakthrough Cross-Chain Security Paradigm

With the burgeoning adoption of Web3, ensuring robust on-chain security has never been more paramount for both dApp builders and users. Leveraging Aleo’s capabilities, IZAR aspires to be the first-of-its-kind, privacy-centric interoperability protocol, establishing a seamless conduit between the Aleo and Ethereum ecosystems. This piece delves deep into our avant-garde privacy and security blueprint.

Our Visison for Privacy & Security

While IZAR will soon function in its full capacity as an interoperability protocol, many might wonder: given the inherent privacy benefits Aleo bestows when transferring assets from the Ethereum ecosystem, what sets IZAR apart from already-popular existing bridges? Furthermore, how do we tackle the prevailing issue of centralization that plagues most bridges? To these pressing queries, our answer lies in our distinct features, meticulously designed to elevate IZAR’s reliability and integrity.

The PoA + PoS Governance Paradigm

Central to our unique approach is our groundbreaking governance framework, combining zkSnark multi-signature with a PoA (Proof of Authority) + PoS (Proof of Stake) hybrid model. In this governance structure, esteemed entities like Aleo and top-tier Ethereum node operators form the PoA nucleus. Concurrently, external validators can effortlessly become part of the validation network via PoS. Our deterministic algorithm ensures that 1/3 + of the voting power is in the hands of PoA, leaving PoS with the remaining 2/3 -. For granular updates on IZAR’s governance, we will soon release the full documentation on GitHub.

Embracing zkSnark MultiSig

Our vision transcends the traditional MPC multisig approach, pivoting towards the zkSnark multisig to realize genuine decentralization in cross-chain transactions. With MPC, every participant retains a keyshare. However, with new entrants, all keyshares undergo regeneration, rendering old keyshares still valid — a potential security vulnerability. Most solutions involve manually transferring assets to fresh addresses periodically, a process far from decentralization.

For IZAR, our goal is to accommodate as many validators as feasible (up to 1k as per our current design). Leveraging zero-knowledge proof technology, we aim to verify the multi-signature validations efficiently and economically.

The Design

To elucidate our model, let’s use Ethereum as an example.
In the Ethereum contract, we only retain the following two items:

> Enforce n must be greater than 2/3 of the total number of validators in the Ethereum contract.

Whenever a signature is required, validators send their own BLS signatures to the prover node:

After collecting enough BLS signatures for a specific msg_hash, the prover starts generating a proof.

In the proof system, we have the following inputs:

Witness:

1. All validator addresses.

2. All received BLS signatures.

Instance:

1. validator_hash.

2. The number of signatures received in current round: n.

3. msg_hash.

We use the following constraints to achieve izar’s zkp multi-signature validation:

1. For all validator addresses, if a signature is submitted for msg_hashin the current round, we set the corresponding flag to 1; otherwise, we set it to 0.
2. For all validator addresses, we constrain their poseidon hash to be equal to validator_hash.
3. For each validator with the flag set to 1, we utilize BLS aggregate signatures technology to ensure the correctness of their signatures.
4. The sum of the flags for all validators must be equal n.
5. For all signatures, we enforce each msg_hash is equal.
6. For msg_hash, we enforce its compliance with the hash_to_curve constraint, and utilize the generated msg_hash_point to verify BLS signatures.

Ethereum contracts can use (Proof, validator_hash, n, msg_hash) to verify the correctness of the proof.

Addressing the Challenge

A predominant challenge is the proof generation speed. Ensuring swift proofs is pivotal for a positive user experience. But the intricate hash_to_curve constraints can lead to expansive circuit sizes, potentially inflating gas costs and elongating proof generation periods.

Our Path Forward

In our quest for rapid proof generation, we’ve explored an aggregation methodology, wherein every validator creates their distinct proof verifying their signature’s accuracy. Then, the izar_prover is responsible for aggregating these proofs. The aggregation approaches we have examined (such as SnarkPack and Nova) require pairing operations logarithmic in the number of proofs. This gas consumption is too high for us. If we cannot find a suitable aggregation approach, we will have to consider direct proofs. Currently, we are considering implementing these proofs directly based on Groth16 or Halo2 and then optimizing the proof generation speed.

A Pioneering Feature: TimeLock

In recent times, onchain cyber-attacks leading to substantial asset losses have unnerved many. As an added security measure, IZAR plans to incorporate the TimeLock feature. By postponing the execution of significant transactions, we can pre-emptively detect and halt suspicious activities, further bolstering our security framework. This mechanism will only activate for transactions exceeding specified thresholds, underlining our unwavering commitment to user security and privacy.

As we propel forward, the development of these trailblazing features will undoubtedly be intensive, necessitating meticulous design, rigorous development, and thorough testing. However, our team is relentless. We anticipate finalizing the comprehensive design by year-end, paving the way for the upgraded IZAR V2’s debut next year. As Aleo inches closer to its mainnet launch, stay abreast with our latest advancements — the best is yet to come.

| Bridge | X.com | Discord |