NEAR DA: ZK Inclusion Proofs

On-Chain ZK Light Clients

For enhancing the security of this model, the light client can be maintained on-chain for the header syncing and inclusion proof verification.NEAR has a ZK Light client (built by Electron) that enables the same. Let's look into that.

ZK Light Client

Light Clients work by tracking the consensus which requires checking validator signatures. However, with NEAR having more than 100 validators, operating a NEAR Light client would require verifying 40+ Ed25519 signatures (for 67% voting power) on Ethereum, which would be prohibitively gas expensive. This is where the ZK Light Client tech by Electron comes in. We can generate ZK-proofs of validity of NEAR light consensus and submit these proofs on-chain instead. This will result in verification gas cost which is several orders of magnitude cheaper than direct on-chain clients.

System Architecture using ZK Light Client

Note the changes compared to the System Architecture diagram from the home page. The fisherman is no longer required, and the off-chain light client is replaced with on-chain ZK light client.In the off-chain light client model, the rollup sequencer was responsible for informing rollup contract that the data had indeed been published on NEAR. It did so by checking NEAR consensus (using NEAR light client) at sequencer level. However, this meant that the sequencer could fake-inform the contracts about the data inclusion.In this on-chain ZK light client model, the NEAR ZK Light Client is deployed on Ethereum mainnet directly. This means, the rollup contracts on Ethereum can now check the inclusion proofs directly on Ethereum, that removing the need to trust the rollup sequencer.This transfers the security assumptions from rollup sequencer to NEAR consensus.

Integrating the ZK Light Client

As part of Electron ZK-bridge , the NEAR ZK Light Client is already deployed on mainnet beta (pending audits). Regular light headers are also sent to keep the on-chain ZK Light Client in sync with NEAR consensus (per epoch as required by NEAR consensus).