Sync, add risczero implementation, update backend, new proving schemes

.cargo/config.toml

@@ -0,0 +1,2 @@
+[alias]
+xtask = "run --package xtask --"

.dockerignore

@@ -1,7 +1,8 @@
 .git
 .github
+contracts
 data
 database
-hardhat
 proofs
-schemes
+schemes
+script

.gitignore

@@ -1,4 +1,3 @@
-target/
 .DS_Store
 .vscode/
 Cargo.lock
@@ -11,3 +10,7 @@ near_state_proofs/vault-contract/target
 
 **/*.db
 **/*.proof
+
+*.profraw
+
+target/

.gitmodules

@@ -1,3 +1,15 @@
 [submodule "contracts/foundry/verifier/lib/openzeppelin-contracts-upgradeable"]
 	path = contracts/foundry/verifier/lib/openzeppelin-contracts-upgradeable
 	url = https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable
+
+[submodule "contracts/foundry-hardhat/lib/forge-std"]
+	path = contracts/foundry-hardhat/lib/forge-std
+	url = https://github.com/foundry-rs/forge-std
+
+[submodule "contracts/foundry-hardhat/lib/openzeppelin-contracts"]
+	path = contracts/foundry-hardhat/lib/openzeppelin-contracts
+	url = https://github.com/OpenZeppelin/openzeppelin-contracts
+
+[submodule "contracts/foundry-hardhat/lib/openzeppelin-contracts-upgradeable"]
+	path = contracts/foundry-hardhat/lib/openzeppelin-contracts-upgradeable
+	url = https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable

CHANGELOG.md

@@ -0,0 +1,18 @@
+2024-04-22
+
+ - Add more unit tests.
+ - Update coverage files.
+ - Fix code formatting.
+ - Update README.
+ - Fix warnings.
+
+2024-03-29
+
+ - Updated the verifier contract.
+ - Updated tests and scripts for the verifier.
+ - Redeveloped smart contracts on the Sepolia test network.
+ - Applied Rust code formatting.
+ - Updated the README and documentation.
+ - Fixed backend issues.
+ - Updated Dockerfile.
+ - Fix warnings.

Cargo.toml

@@ -1,73 +1,66 @@
 [workspace]
-	members = [
-		"crypto/plonky2_ed25519",
-		"crypto/plonky2_sha512",
-		"crypto/plonky2_sha256",
-		"block_finality",
-		"crypto/plonky2_sha256_u32",
-		"crypto/plonky2_sha512_u32",
-		"crypto/plonky2_bn128"
-	]
-	[workspace.package]
-		authors     = [ "Zpoken" ]
-		description = "ZKP for NEAR"
-		edition     = "2021"
-		version     = "0.1.0"
+members = [
+  "near_bft_finality",
+  "crypto/plonky2_ed25519",
+  "crypto/plonky2_sha512",
+  "crypto/plonky2_sha256_u32",
+  "crypto/plonky2_bn128"
+, "xtask"]
 
-	[workspace.dependencies]
-		plonky2 = {git = "https://github.com/zpoken/plonky2", rev = "a5e436079004cc4870313036324267b385089ee6"} #{git = "https://github.com/staaason/plonky2.git", rev = "9e710742982f1642fa5367bffd596143c021ba26"}
-		plonky2_field = {git = "https://github.com/zpoken/plonky2", rev = "a5e436079004cc4870313036324267b385089ee6"} #{git = "https://github.com/staaason/plonky2.git", rev = "9e710742982f1642fa5367bffd596143c021ba26"}
-		plonky2_util = {git = "https://github.com/zpoken/plonky2", rev = "a5e436079004cc4870313036324267b385089ee6"} #{git = "https://github.com/staaason/plonky2.git", rev = "9e710742982f1642fa5367bffd596143c021ba26"}
-		plonky2_u32 = {git = "https://github.com/zpoken/plonky2", rev = "a5e436079004cc4870313036324267b385089ee6"} #{git = "https://github.com/staaason/plonky2-u32.git"}
-		maybe_rayon = {git = "https://github.com/zpoken/plonky2", rev = "a5e436079004cc4870313036324267b385089ee6"} #{git = "https://github.com/staaason/plonky2.git", rev = "9e710742982f1642fa5367bffd596143c021ba26"}
-		plonky2_ecdsa = {git = "https://github.com/zpoken/plonky2", rev = "a5e436079004cc4870313036324267b385089ee6"} #{git = "https://github.com/staaason/plonky2-ecdsa.git"}
-
-		near-crypto = "0.19.0"
-		near-rosetta-rpc    = { git = "https://github.com/near/nearcore"}
-		near-primitives = "0.19.0"
-
-		curve25519-dalek    = { git = "https://github.com/EkaterynaKuznetsova/curve25519-dalek", rev = "9f0cf559de8be0edee3af19f46e4804343d90a70"} 
-		ed25519-compact     = "2.0.4"
-
-		anyhow              = "1.0.40"
-		clap                = { version = "4.0.29", features = [ "derive" ] }
-		criterion           = "0.3"
-		debug_print         = "1.0"
-		env_logger          = "0.9.0"
-		hex                 = "0.4.3"
-		itertools           = "0.10.5"
-		jemallocator        = "0.5.0"
-		keccak-hash         = "0.8.0"
-		log                 = "0.4.14"
-		num                 = { version = "0.4", features = [ "rand" ] }
-		rand_chacha         = "0.3.1"
-		rayon               = "1.5.3"
-		serde               = { version = "1.0", features = [ "alloc", "derive", "std" ] }
-		serde_json          = "1.0"
-		serde_with          = { version = "2.2.0", features = [ "hex" ] }
-		sha2                = "0.10"
-		sha3                = "0.10"
-		static_assertions   = "1.1.0"
-		unroll              = "0.1.5"
-
-		rand = "0.8.4"
-
-		plonky2_ed25519     = { path = "crypto/plonky2_ed25519" }
-		plonky2_sha256      = { path = "crypto/plonky2_sha256" }
-		plonky2_sha512      = { path = "crypto/plonky2_sha512" }
-		plonky2_sha256_u32  = { path = "crypto/plonky2_sha256_u32" }
-		plonky2_bn128 		= { path = "crypto/plonky2_bn128"}
+[workspace.package]
+authors     = [ "Zpoken" ]
+description = "ZKP for NEAR"
+edition     = "2021"
+version     = "0.1.0"
 
+[workspace.dependencies]
+near-rosetta-rpc    = { git = "https://github.com/near/nearcore" }
+clap                = { version = "4.0.29", features = [ "derive" ] }
+num                 = { version = "0.4", features = [ "rand" ] }
+near-crypto 	      = { version = "0.19.0" }
+near-primitives     = { version = "0.19.0" }
+ed25519-compact     = { version = "2.0.4" }
+anyhow              = { version = "1.0.40" }
+criterion           = { version = "0.3" }
+debug_print         = { version = "1.0" }
+env_logger          = { version = "0.9.0" }
+hex                 = { version = "0.4.3" }
+itertools           = { version = "0.10.5" }
+jemallocator        = { version = "0.5.0" }
+keccak-hash         = { version = "0.8.0" }
+log                 = { version = "0.4.14" }
+rand_chacha         = { version = "0.3.1" }
+rayon               = { version = "1.5.3" }
+serde               = { version = "1.0", features = [ "alloc", "derive", "std" ] }
+serde_with          = { version = "2.2.0", features = [ "hex" ] }
+serde_json          = { version = "1.0" }
+sha2                = { version = "0.10" }
+sha3                = { version = "0.10" }
+static_assertions   = { version = "1.1.0" }
+unroll              = { version = "0.1.5" }
+rand                = { version = "0.8.4" }
 
+# Local dependencies
+plonky2             = { git = "https://github.com/wormhole-foundation/plonky2-near", rev = "2244a9d802aa74f15c32ca7f4139959c61126819", features = ["parallel"] }
+plonky2_field       = { git = "https://github.com/wormhole-foundation/plonky2-near", rev = "2244a9d802aa74f15c32ca7f4139959c61126819" }
+plonky2_util        = { git = "https://github.com/wormhole-foundation/plonky2-near", rev = "2244a9d802aa74f15c32ca7f4139959c61126819" }
+plonky2_maybe_rayon = { git = "https://github.com/wormhole-foundation/plonky2-near", rev = "2244a9d802aa74f15c32ca7f4139959c61126819", features = ["parallel"] }
+plonky2_u32         = { path = "crypto/plonky2_u32" }
+plonky2_ecdsa       = { path = "crypto/plonky2_ecdsa" }
+plonky2_ed25519     = { path = "crypto/plonky2_ed25519" }
+plonky2_sha512      = { path = "crypto/plonky2_sha512" }
+plonky2_sha256_u32  = { path = "crypto/plonky2_sha256_u32" }
+plonky2_bn128 	    = { path = "crypto/plonky2_bn128"}
+curve25519-dalek    = { git = "https://github.com/wormhole-foundation/curve25519-dalek", rev = "8ac0b892c7477ea8f023ec81332420fc4faae595" }
 
 [profile.release]
-	opt-level = 3
-	strip = true
-	lto = true
-	codegen-units = 1
+opt-level = 3
+strip = true
+lto = true
+codegen-units = 1
 
 [profile.bench]
-	opt-level = 3
+opt-level = 3
 
 [profile.test]
-	opt-level = 1
+opt-level = 1

README.md

@@ -1,37 +1,45 @@
-# Example Trustless NEAR Light Client Implementation
+# NEAR Light Client Implementation
+
+Developed by [Zpoken Cryptography Team](https://zpoken.io/)
 
 ## Overview
 
-An implementation of a trustless NEAR light client (LC) in plonky2(https://github.com/0xPolygonZero/plonky2). Proves the finality of a block based on the existing final block of the previous epoch.
+An implementation of a trustless NEAR Light Client (LC) aims to prove computational integrity (CI) of a chosen block, ensuring its full finality (BFT finality). The idea is to first prove the finality (BFT finality) of a chosen block by proving the finality of successive blocks. Then, if a block is final, prove the computational integrity of its data. 
 
-### Block Integrity and Finality Proof
+According to the [protocol](https://nomicon.io/ChainSpec/Consensus#finality-condition), the scheme needs at least three blocks with successive heights to achieve finality of the leading block in this triple. In other words, it needs blocks: `Block_0` (block to be proven, BFT finality), `Block_i+1` (Doomslug finality), `Block_i+2`.
 
-1. **Operating Fields**: The NEAR zk-light-client operates on several critical fields within the blockchain ecosystem. These fields include the validators, the `next_bp_hash` (next block producers' hash), and the block hash itself.
+The scheme takes five blocks, instead: 
+- `Block_i` (block to be proven, BFT finality);
+- `Block_i+1` (BFT finality);
+- `Block_i+2` (BFT finality);
+- `Block_i+3` (Doomslug finality);
+- `Block_i+4`. 
 
-2. **Formation of `next_bp_hash`**: The `next_bp_hash` is a crucial component in this process. It is derived from the set of validators responsible for producing the next block. This hash serves as a cryptographic representation of the validators' identity and their role in the upcoming block production.
+The scheme proves block finality of `Block_i+2`, if the heights of `Block_i+2`, `Block_i+3` and `Block_i+4` are consecutive. `Block_i` automatically becomes final, and its signatures can be safely extracted from `Block_i+1`. Then the CI of the required `Block_i` can then be proven.
+
+Additionally, we provide two more blocks: 
+- `Block_n-1`, i.e. the last block of the epoch *i-2*, to prove `epoch_id`;
+- `Block_0`, i.e. the first block of the epoch *i-1*, to prove the correspondence of the used list of validators for the current epoch with the field `next_bp_hash` if the `Block_0`. 
+
+### Block Integrity and Finality Proof
 
-3. **Calculation of the block hash**: The block hash is then calculated based on the data of the current block. This data includes the `next_bp_hash`. By incorporating the `next_bp_hash` into the block hash calculation, there is a direct cryptographic link between the validators of the next block and the current block's integrity.
+1. **Operational fields**: NEAR zk-light-client operates on several critical fields in the blockchain ecosystem. These fields include the list of validators, `next_bp_hash` (the hash of the next block producers) from epoch *i-1*, the hash of the last block from epoch *i-2* to confirm `epoch_id`, and a set of hashes and heights of five consecutive blocks including the required `Block_i` to prove.
 
-4. **Core Idea**: The core idea is to establish a traceable and verifiable chain of custody for block creation. By proving that the `next_bp_hash` (derived from the validators) is a part of the current block's data, which in turn is used to calculate the block's hash, a secure chain is formed. This chain ensures that each block is not only a product of its immediate data but also carries a cryptographic signature of its contextual environment, i.e., the validators for the next block.Therefore, verifying a block's authenticity involves confirming that the set of validators is valid (thus legitimizing the `next_bp_hash`) and ensuring that the block hash is correctly derived from the data, including this `next_bp_hash`.
+2. **Formation of `next_bp_hash`**: The `next_bp_hash` is a crucial component in this process. It is derived from the set of validators responsible for producing the next block. This hash serves as a cryptographic representation of the validators' identity and their role in the upcoming block production.
 
-```
-defined set of validators ======> defined next_bp_hash ======> defined block hash
-```
+3. **Calculation of the block hash**: The block hash is calculated based on the data of the current block. This data includes the `next_bp_hash`. By incorporating the `next_bp_hash` into the block hash calculation, there is a direct cryptographic link between the validators of the next block and the current block's integrity.
 
-<!-- ![Illustrative scheme](/schemes/Illustrative_scheme.png) -->
+4. **Core Idea**: The core idea is to establish a traceable and verifiable chain of custody for block creation. By proving that the `next_bp_hash` (derived from the validators) is a part of the current block's data, which in turn is used to calculate the block's hash, a secure chain is formed. This chain ensures that each block is not only a product of its immediate data but also carries a cryptographic signature of its contextual environment, i.e. the validators for the next block.Therefore, verifying a block's authenticity involves confirming that the set of validators is valid (thus legitimizing the `next_bp_hash`) and ensuring that the block hash is correctly derived from the data, including this `next_bp_hash`.
 
-<figure>
-  <img src="/schemes/Illustrative_scheme.png" alt="Architecture Diagram">
-  <figcaption>Figure: Illustrative Scheme for Block Proving.</figcaption>
-</figure>
+> [!TIP]
+> Scheme description: [Scheme_overview.md](/near/near_bft_finality/Scheme_overview.md)
 
 ### Input parameters for proof generation
-1. Block for which the proof is generated `(epoch N)` [Example](https://github.com/ZpokenWeb3/zk-light-client-implementation/blob/main/script/data/block-A6Gcz5uXxyTrigefyr48AXwag6gB7D6txzPSR3jBqqg2/block_header.json)
+1. A set of five consecutive blocks including the required `Block_i` to prove epoch *i* [Example](/near/script/data/block-A6Gcz5uXxyTrigefyr48AXwag6gB7D6txzPSR3jBqqg2/block_header.json)
 
-2. Block of the previous epoch `(epoch N-1)` [Example](https://github.com/ZpokenWeb3/zk-light-client-implementation/blob/main/script/data/block-A6Gcz5uXxyTrigefyr48AXwag6gB7D6txzPSR3jBqqg2/block_header.json)
-
-3. List of block producers for `epoch N ` [Example](https://github.com/ZpokenWeb3/zk-light-client-implementation/blob/main/script/data/block-A6Gcz5uXxyTrigefyr48AXwag6gB7D6txzPSR3jBqqg2/validators_ordered.json)
+2. *Epoch blocks* `Block_n-1` from epoch *i-2* and `Block_0` from epoch *i-1*. [Example](/near/script/data/block-A6Gcz5uXxyTrigefyr48AXwag6gB7D6txzPSR3jBqqg2/block_header.json)
 
+3. List of block producers for  epoch *i* [Example](/near/script/data/block-A6Gcz5uXxyTrigefyr48AXwag6gB7D6txzPSR3jBqqg2/validators_ordered.json)
 
 ## Near State Proofs
 
@@ -42,6 +50,5 @@ defined set of validators ======> defined next_bp_hash ======> defined block has
 - This ensures the data's validity and its presence in a specific blockchain state.
 
 > [!TIP]
-> Read the example here [NEAR_STATE_PROOFS.md](/near_state_proofs/NEAR_STATE_PROOFS.md)
-
-Developed by [Zpoken Cryptography Team](https://zpoken.io/)
+> Read the example here [NEAR_STATE_PROOFS.md](/near/near_state_proofs/NEAR_STATE_PROOFS.md)
+> Getting started [Getting-started.md](/near/near_bft_finality/Getting-started.md)

backend/.gitignore

@@ -2,4 +2,8 @@ node_modules
 # Keep environment variables out of version control
 .env
 .vscode/
-/proofs/
+proofs/*
+
+!proofs/.gitkeep 
+prisma/dev.db
+prisma/dev.db-journal

backend/Dockerfile

@@ -1,8 +1,11 @@
 FROM node:current-alpine
 
+# Install curl
+RUN apk update && apk add --no-cache curl
+
 WORKDIR /app
 
-COPY package.json yarn.lock .env /app
+COPY package.json yarn.lock /app
 
 RUN yarn install
 
@@ -12,7 +15,5 @@ COPY ./proofs /app/proofs
 
 RUN yarn db:push
 
-ENV NATS_URL=nats://195.189.60.190:4222
-
 EXPOSE 9024
-CMD yarn start
+CMD yarn start

backend/eslint.config.js

@@ -1,6 +1,6 @@
 // @ts-check
 
-import eslint from '@eslint/js';
-import tseslint from 'typescript-eslint';
+const eslint = require('@eslint/js');
+const tseslint = require('typescript-eslint');
 
-export default tseslint.config(eslint.configs.recommended, ...tseslint.configs.recommended);
+module.exports = tseslint.config(eslint.configs.recommended, ...tseslint.configs.recommended);