• https://github.com/rac-sri/neovim-config - NeoVim Config

• https://github.com/rac-sri/opencode-config - OpenCode Config

Here is a tour of the plugins, the architecture, and the logic behind the chaos.

NeoVim Setup

1. What are Plugins in Neovim? (And Why lazy.nvim?)

Neovim out of the box is a powerful text editor, but it's "bare bones." It doesn't ship with a file explorer, autocompletion, or Git integration enabled by default. Plugins are Lua scripts that add these features, essentially turning Neovim from a text editor into a full PDE.

Managing dozens of plugins used to be a nightmare of slow startup times and broken dependencies. Enter lazy.nvim.

I use lazy.nvim as my package manager because, as the name implies, it's lazy. It doesn't load every plugin when I launch Neovim. Instead, it waits.

• Want to use Git? It loads the Git plugin only when you open a Git-tracked file.

• Want to code in Rust? It loads the Rust LSP only when you open a .rs file.

This keeps my startup time blazing fast (< 100ms) while still having a massive suite of tools at my disposal.

2. My Plugin Arsenal

Here is the complete list of plugins powering my setup, broken down by category.

UI & Aesthetics

Because if you're going to stare at a screen all day, it better look good.

• nord.nvim: My theme of choice. A cool, bluish-grey palette that is easy on the eyes, configured with transparency support.

• lualine.nvim: A sleek, configurable status line at the bottom of the window showing branch, mode, and diagnostics.

• bufferline.nvim: Displays open files as "tabs" at the top, making navigation intuitive for those coming from VS Code.

• alpha-nvim: A programmable startup dashboard that greets me with a custom header and quick links to recent files.

• indent-blankline.nvim: Adds vertical indentation guides to help visually track code blocks and nested loops.

• nvim-scrollbar: Adds a visual scrollbar that also highlights search results and diagnostic errors in the gutter.

• smear-cursor.nvim: Adds a motion blur trail to the cursor. Purely cosmetic, but it makes jumping around the file feel incredibly smooth.

• nvim-colorizer.lua: Automatically highlights hex codes (like #ff0000) with their actual color.

Coding Intelligence

The engine that understands the code.

• nvim-lspconfig: The backbone of language support. It connects Neovim to Language Servers (LSP) for Python, Rust, TS, etc.

• nvim-cmp: The main autocompletion engine. It pops up the menu suggesting variables and functions as I type.

• blink.cmp: A high-performance, Rust-based completion engine I'm experimenting with for even faster suggestions.

• nvim-treesitter: Provides advanced syntax highlighting and code parsing, allowing for smarter text selection (like "select function").

• none-ls.nvim: Injects standard command-line tools (like Prettier or ESLint) into the LSP workflow for formatting and linting.

• nvim-autopairs: Automatically closes brackets, quotes, and parentheses so I don't have to.

Navigation & Workflow

Tools to move fast and break less things.

• telescope.nvim: A universal fuzzy finder. I use it to find files, grep text, search help docs, and more.

• neo-tree.nvim: A file explorer sidebar. Useful for visualizing the directory structure and performing file operations. I don’’t primarily use it, just a nice to have because of seemless integration with git from a visual perspective.

• yazi.nvim: Integrates the yazi terminal file manager, giving me a super-fast, keyboard-driven way to browse files. Primary tool to navigate through files.

• gitsigns.nvim: Shows Git changes (added/removed lines) right in the gutter and allows for inline previews.

• vim-tmux-navigator: Allows seamless navigation between Neovim splits and Tmux panes using the same keys (Ctrl-h/j/k/l).

• comment.nvim: Toggles comments on lines or blocks with a simple shortcut (gcc or gc).

• todo-comments.nvim: Highlights TODO, FIXME, and NOTE comments so they stand out and can be searched.

The AI Squad

I lean heavily on AI for coding assistance, using multiple specialized tools rather than a single monolith.

• opencode.nvim: My "Agentic" AI tool. It enables inline asking (<leader>oi) and complex task execution via a panel, integrating deep context from the codebase. I use local model: qwen3-coder when data privacy is important, and else I am currently using gemini models since I got access to it’s pro subscription.

• vim-tabby: Provides ML-powered code completion (ghost text) using a self-hosted Tabby server, keeping my data private.

• copilot.vim: The classic GitHub Copilot integration. I keep this for quick tab style completion in places where privacy is not a concern..

• avante.nvim ( disabled ): An advanced AI chat interface that sits in a sidebar. It supports multiple providers (Gemini, Claude, OpenAI) and even allows pasting images for analysis.

• gemini-cli.nvim ( disabled ): A direct line to Google's Gemini models for quick questions and code generation directly from the editor.

3. The init.lua: Where It All Begins

In the world of Neovim, init.lua is the captain. It is the first file loaded when the editor starts, and its job is to orchestrate everything else.

My init.lua is designed to be modular. Instead of dumping 500 lines of config into one file, it acts as a dispatcher:

1. Core Loading: First, it requires modules from the lua/core/ folder.

   • core.options: Sets basic settings like line numbers, tab widths, and clipboard behavior.

   • core.keymaps: Defines my global keyboard shortcuts (like Space as Leader).

   • core.snippets: Loads custom code snippets.

2. Lazy Bootstrap: It checks if lazy.nvim is installed. If not, it automatically clones the repository. This means I can pull this config on a fresh machine, open Neovim, and it will self-install everything.

3. Plugin Initialization: Finally, it passes control to lazy.

    require("lazy").setup({
        require("plugins.neotree"),
        require("plugins.colortheme"),
        -- ... and so on
    })
   

   Each require points to a separate file in lua/plugins/. This keeps the config clean; if I want to change how my status line looks, I go to lua/plugins/lualine.lua, not a massive monolithic file.

🤖 OpenCode: The AI Orchestrator

Right after my Neovim configuration comes the brain of the operation: OpenCode. If Neovim is the surgical instrument, OpenCode is the senior engineer looking over my shoulder.

I use a opensource setup called OhMyOpenCode, heavily customized to switch between local privacy and cloud intelligence.

The "Sisyphus" Workflow: The primary agent is named Sisyphus (a fitting name for an engineer, right?). Unlike standard AI assistants, Sisyphus is configured as an orchestrator that delegates tasks to specialized sub-agents. Here is how I map the intelligence in ~/.config/opencode/oh-my-opencode.json:

{ 
    agents: { 
        Sisyphus: { 
            model: google/gemini-3-pro-high 
        },     
        oracle: { 
            model: google/gemini-3-pro-high 
        }, 
        librarian: { 
            model: google/gemini-3-pro-low 
        }, 
        document-writer: { 
            model: google/gemini-3-flash 
        } 
    }     
}

I'm using a hybrid model strategy:

• Heavy Lifting: Complex architecture and planning (Sisyphus/Oracle) go to Gemini 3 Pro High ( as of writing ) with reasoning enabled.

• Speed: Documentation and quick lookups use Gemini 3 Flash or Pro Low.

• Local: My default fallback in opencode.json is Qwen 2.5 Coder (via Ollama) for zero-latency, offline code completion.

Context & Rules

One feature I rely on is the dynamic context loading. OpenCode automatically ingests my project guidelines before writing a single line of code:

instructions: [ 
    CONTRIBUTING.md, 
    docs/guidelines.md, 
    .cursor/rules/*.md 
]

This ensures the AI respects my repo's specific conventions (like "no any types" or "React functional components only") without me repeating prompts.

Aesthetics

Since I live in the terminal, visual consistency is non-negotiable. I built a custom transparent theme so OpenCode floats seamlessly over my terminal background, matching the transparency of my Neovim windows.

 // themes/transparent.json 
{ 
    theme: { 
        background: transparent, 
        backgroundPanel: transparent, 
        primary: #00d4ff, 
        success: #2ed573 
    } 
}

It’s not just about looking cool—it keeps me in the flow state without jarring context switches between my editor and my AI agent.

Custom Primary Agents

Custom Agents One of the most powerful features of OpenCode is the ability to define custom "personas" or agents. I don’t just have one generic AI; I have a squad of specialists, each defined in ~/.config/opencode/agent/. I’ve defined two custom agents to handle specific non-coding workflows:

1. The "Ask" Agent (Code Consultant)

   Sometimes I just need an answer, not a code change. I created the Ask agent (agent/Ask.md) specifically for this.

   • Role: Code Q&A Specialist.

   • Constraint: Strictly Read-Only. It has explicit instructions to never edit files or run commands.

   • Use Case: "How does this function work?" or "Explain this error." It uses Gemini 3 Pro Low to be cost-effective but smarter than a basic model.

2. The "Webcrawler" Agent (Researcher)

   I don't want my coding assistant hallucinating facts about the world. Webcrawler (agent/Webcrawler.md) is my general knowledge researcher.

   • Role: General Q&A (News, Science, Trends).

   • Constraint: Explicitly forbidden from giving technical coding advice—it redirects those to the Ask agent.

   • Use Case: "What are the latest features in React 19?" or general web research.

Terminal - Ghostty

I use Ghostty as my primary terminal with the following config:

https://github.com/rac-sri/personal-config/blob/main/ghostty.config.
Main appearance limited config is below:

# ---- Appearance ----
theme = Adventure
background-blur = true
background-opacity = 1
background-image = ~/.config/ghostty/image.png
background-image-opacity = 0.5
....

with the image being a free to use artwork I pulled from the internet : https://github.com/rac-sri/personal-config/blob/main/image.png.

That's the tour! This setup balances raw speed with modern features, giving me an environment that feels like mine.

• Group Law

• Fields and how field operations works

• Divisors

Now in this part we will explore:

• Pairing Groups

• Expand on r-torsian groups

• Pairing types

• Twisted Curves

• Weil and Tate Pairings

Pairing groups

Let’s define bilinear map first:

$$M*M \rightarrow R$$

where bilinearity property of the map means:

$$( x+y, z) = (x,z) * (y,z )$$

$$(x,y+z)= (x,y)*(x,z)$$

The most common notion for the same is \(e: G_1 * G_2 \rightarrow G_T\)

\(G_1\) and \(G_2\) are defined in \(E(F_{q^k})\) and target group \(G_T\) is defined in multiplicative group \(F^*_{q^k}\), so we write \(G_1\) and \(G_2\) additively and \(G_T\) multiplicatively. Thus if \(P,P' \in G_1\) and \(Q, Q' \in G_2\) the bilinearity of e means:

$$e(P+P', Q) = e(P,Q).e(P',Q)$$

$$e(P, Q+Q') = e(P,Q).e(P,Q')$$

from which it follows, for scalers \(a, b \in Z\):

$$e([a]P,[b]Q) = e(P,[b]Q)^a = e([a]P, Q)^b = e(P,Q)^{ab} = e([b]P,[a]Q)$$

Non-Degeneracy: Non-degeneracy is a fundamental property of cryptographic pairings. It ensures that if \(P \neq O\) and \(Q \neq O\), then the pairing \(e(P,Q) \neq 1\). This means that the pairing does not collapse information by mapping all non-trivial inputs to the identity element. In a cryptographic setting, non-degeneracy guarantees that pairings can be used effectively in protocols like identity-based encryption and signature schemes. Essentially, it ensures that the bilinear mapping retains meaningful structure and does not trivialize computations. This \(e(P,Q) \neq 1 \) guarantees non-trivial pairings for non-trivial arguments.

The r-torsion

The points \(P\) and \(Q\) come from disjoin cyclic subgroups of the same prime order \(r\). We obtain two distinct order-r subgroups in general: we find the smallest extension \(F_{q^k} \space of \space F_q\) such that \(E(F_{q^k})\) captures more points of order \(r\). The integer \(k \geq 1\) that achieves this is called embedding degree and plays a crucial role in paring computation.

Trace Map: The trace map of point \(P = (x,y) \in E(F_{q^k})\) is defined as:

$$Tr(P) = \sum_{\sigma\in Gal(F_{q^k} / F_q)} \sigma(P) = \sum^{k-1}{i=0} \pi^i(P) = \sum^{k-1}{i=0}(x^{q^i}, y^{q^i})$$

Galois theory: \(Tr: E(F_{q^k}) \rightarrow E(F_q)\) so when \(r || Order E(F_q)\), this map, which is actually a group homomorphism, sends all torsion points into one subgroup of the r-torsion i.e Tr will send every other element in the torsion into \(E(F_q)[r]\).

• All points other than the upper left torsion group one, will get mapped to the upper left group. eg. \(R = (u^{423}, u^{840})\), we have \(Tr(R) = (10, 7)\).

• There is one other peculiar subgroup above in E[7], the upper right group in the above case, where the trace map sends every element to \(O\). eg. \(T = (u^{1315}, u^{1150})\) i.e. \(Tr(T) = O\). This is the trace zero group.

• We can also map any \(P \in E[r]\) to the trace zero subgroup ( \(G_2)\) via the anti-trace map \(aTr: P \rightarrow P' = [k]P - Tr(P)\).

  To following diagram ( from Pairings for beginners book ) summarize the above quite well:

  

  • Lastly, we have supersingular curve E if \(Order E(F_q) = q+1\). These curves come with a distortion map \(\phi\): a non-\(F_q\)-rational map that takes a point in \(E(F_q)\) to a point in \(E(F_{q^k})\).

    For \(E/ F_q = y^2 = x^3 +1 \) with embedding degree \(k=2\) we get:

And that covers the different torsion groups and mappings between them !iv

Pairing Types

Pairing-based cryptography leverages structured subgroups of elliptic curves to facilitate secure and efficient protocols, with four distinct pairing types offering varied trade-offs between functionality, efficiency, and security. These classifications—Type 1 through Type 4—arise from how subgroups like the base-field group \(G_1\) and trace-zero subgroup \(G_2\) are defined, along with their interplay in operations such as hashing, isomorphism mapping, and pairing computations.

Type 1 pairings are built on supersingular elliptic curves, where \(G_1\)and \(G_2\) are set to the same subgroup. This symmetry simplifies hashing into \(G_1\) via cofactor multiplication and ensures a straightforward isomorphism \(\psi\) between subgroups. However, the reliance on supersingular curves imposes significant limitations on optimizing pairing computations, making Type 1 less practical for modern applications despite its simplicity.

Type 2 pairings use ordinary curves, with \(G_2\) defined as a subgroup outside \(G_1\) or the trace-zero group. While the trace map \(Tr: G_2 \rightarrow G_1\) enables certain efficiency gains, these pairings struggle with a critical drawback: the inability to hash or randomly sample elements directly into \(G_2\). This limits their utility in protocols requiring dynamic element generation, as elements must instead be derived from a predefined generator.

Type 3 pairings, also on ordinary curves, address this by setting \(G_2\) as the trace-zero subgroup. This allows efficient hashing into \(G_2\)using the anti-trace map \(aTr\), making them a popular choice for modern protocols like BLS signatures. The trade-off, however, is the lack of a computationally feasible isomorphism \(\psi: G_2 \rightarrow G_1\), complicating security proofs that depend on such mappings unless stronger assumptions are made.

Type 4 pairings expand \(G_2\) to the full r-torsion group \(E[r]\), theoretically enabling hashing but at the cost of practicality. The non-cyclic structure of \(E[r]\) and the negligible probability of hashing into desired subgroups render this type largely theoretical, with limited real-world applications.

In practice, Type 3 pairings dominate modern use cases due to their balance of efficiency and flexibility, while Type 1’s constraints and Type 2/4’s impracticalities relegate them to niche roles. Developers must weigh factors like curve type (supersingular vs. ordinary), isomorphism availability, and hashing capabilities when selecting a pairing type, as these choices directly impact protocol security, performance, and ease of implementation. Ultimately, understanding these trade-offs is key to designing robust cryptographic systems tailored to specific needs.

Twisted Curves

Twisted curves play a pivotal role in modern elliptic curve cryptography (ECC) and pairing-based protocols, offering enhanced efficiency, security, and flexibility. These curves—such as twisted Edwards curves and twisted Montgomery curves—are algebraic variants of standard elliptic curves, engineered to optimize cryptographic operations while mitigating vulnerabilities. Below, we break down their significance, mechanics, and applications in cryptography.

What Are Twisted Curves?

A twist of an elliptic curve is a related curve that is isomorphic (structurally similar) over an extension field but distinct over the base field. For example:

• Twisted Edwards curves are defined by the equation \(ax^2 + y^2 = 1 + dx^2y^2\), where parameters a and \(d\) introduce flexibility in curve design.

• Montgomery curves like \(y^2 = x^3 + Ax^2 + x\) (e.g., Curve25519) are often birationally equivalent to twisted Edwards curves, enabling efficient computations.

Twists retain the core security properties of their parent curves but enable optimizations in arithmetic operations. For instance, twisted Edwards curves support complete and exception-free addition formulas, eliminating edge cases that could lead to side-channel attacks.

Why Use Twisted Curves?

1. Efficiency:
   Twisted curves streamline critical operations like point addition and scalar multiplication. For example, twisted Edwards curves achieve point addition in 8M (8 field multiplications), significantly faster than Weierstrass curves. This speed is leveraged in schemes like EdDSA, a high-performance digital signature protocol.

   • Curve25519 (a Montgomery curve) and its twisted Edwards counterpart, edwards25519, underpin secure communication protocols like Signal and TLS 1.3.

2. Pairing Optimization:
   In pairing-based cryptography, twists enable computations over smaller extension fields. For example, certain twists of pairing-friendly curves (e.g., BN curves) allow pairings to be computed in \(\mathbb{F}_{q^k}\) with reduced k, slashing computational overhead. This is critical for protocols like BLS signatures and identity-based encryption.

3. Security:
   Twists must be twist-secure—meaning both the original curve and its twist resist attacks like the discrete logarithm problem. If a protocol fails to validate input points, an attacker could force computations on a weaker twist, compromising security. For example, Curve25519’s twist, Curve448, is designed to match its parent’s security.

Twists in Pairing-Based Cryptography

Pairing protocols (e.g., Type 3 pairings) often use twists to optimize subgroup structures:

• Trace-Zero Subgroups: Twists can map elements to trace-zero subgroups \(G_2\), enabling efficient hashing and cofactor multiplication.

• Field Extensions: By leveraging twists, pairings like the Tate or Ate pairing reduce the embedding degree k, accelerating operations in \(\mathbb{F}_{q^k} \) .

For instance, the anti-trace map \(\text{aTr} \) on twisted Edwards curves allows direct hashing into \(G_2\), a key advantage in Type 3 pairings.

Weil and Tate Pairings

Weil Pairings: Let \(P,Q \in E(F_{q^k})[r] \) and let \(D_P\) and \(D_Q\) be degree zero divisors with disjoin support such that \(D_P \sim (P) - (O) \) and \(D_Q \sim (Q) - (O)\). There exist functions \(f\) and \(g\) such that \((f) = rD_P \) and \((g) = rD_Q\). The Weil pairings \(w_r\) is a map:

$$w_r: E(F_{q^k})[r] * E(F_{q^k})[r] \rightarrow \mu_{r }$$

defined as:

$$w_r(P,Q) = f(D_{Q}) / g(D_P)$$

Tate Pairings: Let \(P \in E(F_{q^k})[r]\) from which it follows that there is a function \(f\) whose divisor is \((f) = r(P) - r(O) \) . Let \(Q \in E(F_{q^k})\) be any representative in any equivalance class in \(E(F_{q^k}) / rE(F_{q^k})\)and let \(D_Q\) be a degree zero divisor defined over \(F_{q^k}\) that is equivalent to \((Q) - (O)\), but whose support is disjoint to that of \((f)\). The Tate pairing \(t_r\) is a map:

$$t_r : E(F_{q^k})[r] E(F_{q^k}) / rE(F_{q^k}) \rightarrow F^{q^k} / (F^*{q^k})^r$$

defined as:

$$t_r(P,Q) = f(D_Q)$$

Conclusion

From group laws defining elliptic curves to the nuanced interplay of pairing types and twisted geometries, pairing-based cryptography bridges theoretical depth and practical innovation. As zero-knowledge systems and decentralized finance demand stronger privacy guarantees, these mathematical tools will remain indispensable—provided developers prioritize twist-secure parameters, optimal subgroup choices, and rigorous hardness assumptions. The future lies in balancing efficiency gains with quantum resilience, ensuring pairings evolve alongside cryptographic frontiers.

For more updates, insights, and discussions, connect with me on Twitter and LinkedIn.

References

• Parings for beginners

• Divisors

• Overview of Principal divisor, Picard groups

• Introduction to Genus

Understanding Divisors: A Key Concept in Algebraic Geometry

A divisor is a mathematical construct that helps us study functions and points on algebraic curves, such as elliptic curves. In simple terms, a divisor is a formal sum of points on a curve, where each point is assigned an integer coefficient.

Formal Definition

A divisor DD on an algebraic curve CC is a formal sum of points:

$$D = \sum_{P\in C}n_p. P$$

where:

• P are the points on the curve C,

• \(n_P\) are integers (can be positive, negative, or zero) also called multiplicity.. The multiplicity of a point in a divisor quantifies how much that point contributes to the divisor.

  • \(n_p> 0\) => point P contributes as a zero of a function

  • \(n_p <0\) => point P contributes as a pole of a function

  • \(n_p = 0\) => point P does not contribute to the divisor.

• Only finitely many are nonzero.

For example, D=3P−2Q+R is a divisor, where P, Q, and R are points on the curve.

The set of all divisors on \(E\) is denoted by \(Div_{\overline{F_q}}(E)\) and forms a group, where addition of divisors is natural, and the identity is the divisor with all \(n_p = 0\), the zero divisor \(0 \in Div_{\overline{F_q}}(E)\)

Degree of a Divisor

The degree of a divisor D is the sum of its coefficients:

$$D = \sum_{P\in C}n_p$$

• For \(D=3P−2Q+R, deg(D)=3−2+1=2\).

Divisors of degree 0 are particularly important in pairing-based cryptography because they often correspond to the group elements used in cryptographic operations.

Support of a Divisor

The support of a divisor D:

$$supp(D) = { P \in E(\overline{F_q})}$$

Associating divisors with a function

Writing divisors as a function f on E is a convenient way to write down the intersection points ( and their multiplicities) of f and E.

$$(f) = \sum_{P \in E(\overline{F_q})}ord_P(f)(P)$$

where \(ord_P(f) \) counts the multiplicity of f at P.

In pairing-based cryptography, divisors help define certain mathematical structures on elliptic curves:

1. Principal Divisors and Pairings: Bilinear pairings, such as the Weil pairing and Tate pairing, rely on divisors to define their operation.

2. Divisors and Group Elements: The points on elliptic curves can be seen as specific types of divisors, and their manipulation through pairings is crucial for cryptographic protocols.

Types of Divisors

1. Effective Divisor: All coefficients \(n_p >= 0\). For instance, \(D = P + 2Q\).

2. Principal Divisor: A divisor associated with a rational function f on the curve.

   • Zeros of f contribute positively.

   • Poles of f contribute negatively.

eg. If f has a zero of order 2 at P and a pole of order 1 at Q, its divisor is \(D = 2P - Q\).

If a divisor D is equal to the divisor of a function, i.e. \(D = (f)\) then D is the principal divisor.

A principal divisor always has degree of 0.

$$Prin(E) \subset Div^0(E) \subset Div(E)$$

Understanding Divisor Equivalence and Picard Groups

We will use an example to understand the divisor equivalence.

Consider the elliptic curve \(E/F_{61}: y^2 = x^3 + 8x + 1\). We have four points: \(P = (57, 24), Q=(25,37), R=(17,32), S = (42,35)\).

Two divisors on E:

• \(D_1 = (P) + (Q) + (R)\)

• \(D_2 = 4(O) - (S) \) where O is point at infinity

Proving Equivalence: The divisors \(D_1\) and \(D_2\) are equivalent because there exists a rational function \(f(x,y)\) on \(E\) with the divisor: \((f) = (P) + (Q) + (R) + (S) - 4(O)\)

Here, \(f(x,y)\) is the function \(y = 33 x^2 + 10 x + 24\) which intersects \(E \) at \(P,Q,R,S\), each with the multiplicity of 1. This implies f has a pole of order 4 at \(O\). Substituting in the equivalence relation: \(D_1 = D_2 + (f)\) we see \(D_1\sim D_1\)showing that \(D_1 \) and \(D_2\) lie in the same divisor class.

An alternate perspective: If finding \(f\) explicitly seems challenging, we can consider the difference \(D_1 - D_2= (P) + (Q) + (R) + (S) - 4(O)\). The divisor has degree zero, satisfying the condition for membership in the group of degree-zero divisors, \(Div^0(E)\). Using the addition law on elliptic curve, we compute: \(P+Q+R+S-[4]O = 0\) indicating that \(D_1- D_2\) belongs to the set of principal divisors, \(Prin(E).\) Thus \(D_1 - D_2 = (f) \) for some function f, reaffirming \(D_1 \sim D_2\).

Picard Group ( Divisor Class group ):

The example introduces the Picard group of E. It is defined as:

$$Pic^0(E) = Div^0(E) / Prin(E)$$

In simpler terms, the Picard group is the collection of all degree-zero divisors, grouped by their equivalence under principal divisors.

Imagine you’re organizing a grand party, and you’re assigning tasks to your friends. Some of these tasks are simple, like “buy decorations” or “set up the music system,” while others are combinations of simpler tasks, like “prepare the venue” (which involves cleaning, arranging chairs, and decorating).

Now, here’s the catch: you don’t care how the tasks are grouped or assigned, as long as everything gets done. Whether one person handles “cleaning” and another does “decorating,” or one friend takes care of “preparing the venue” as a whole, it’s all the same to you as long as the end result is a successful party.

The Picard group works a bit like this. It’s a system for organizing and simplifying the roles (or relationships) of "tasks" (called divisors) on an elliptic curve. Here's how it works:

The Party Roles as Divisors

1. Tasks (Divisors): On the curve, each point represents a “task.” Some tasks are simple (like single points), while others are combinations of tasks (like sums of points).

2. Simplified Groups (Equivalence Classes): If two sets of tasks result in the same outcome (e.g., the venue looks ready), the Picard group treats them as equivalent. In math terms, these are called divisor classes.

3. Irrelevant Details (Principal Divisors): Just like you might ignore the specific order in which chairs are arranged if the venue still looks perfect, the Picard group ignores certain kinds of "irrelevant" details (principal divisors). These don’t affect the overall result and are treated as if they were invisible.

Let’s understand Principal divisor a bit using another analogy:

Imagine you have a see-saw, and you place weights (points on the curve) at different positions. The goal is to balance the see-saw so it doesn’t tip over.

Now, think of the function f as a special tool you can use to shift the weights around. This tool doesn’t change the total weight or the balance of the see-saw—it only redistributes the weights in a way that maintains equilibrium. Once the see-saw is balanced, the exact arrangement of weights doesn’t matter anymore; what matters is that the see-saw stays level.

In the mathematical world:

• The divisor of f (written as \((f)\)) records where f "puts" weights (its zeros and poles).

• This divisor is called principal because it comes directly from f, which guarantees it maintains balance (degree zero).

When we’re working in the Picard group, we only care about whether the "see-saw" is balanced (the overall divisor class), not the specific arrangement of weights. This is why (f) doesn’t change anything important—it’s invisible in this sense.

Evaluating a Function at a Divisor

Evaluating a function \(f \in F_q(E)\) at a divisor \(D= \sum_{P \in E} n_p(P)\) has a natural definition, provided the divisors \((f)\) and \(D\) have disjoint supports:

$$f(D) = \prod_{P \in E}f(P)^{n_p}$$

An Introduction to Genus

For any curve C, there is a unique minimal integer g, called the genus of C, such that any divisor \(D \in Pic^0(C)\) is equivalent to a divisor \(D^{'}\) with \(Deg(\epsilon(D^{'}) <= g \) where \(~ \epsilon(D^{'}) \) is the effective divisor. Elliptic curves \(E\) are curves of genus = 1, meaning that every \(D \in Pic^0(E)\) can be written as \((P_1) - (Q_1)\).

Imagine you’re designing different types of paper-folding crafts. The genus of a surface tells you how many “holes” or “handles” it has. For example:

• A plain sheet of paper has no holes—it’s simple and flat. This is like a curve with genus 0.

• If you take a piece of paper and make a single hole or a tunnel in the middle, you’ve added one hole. This is like a curve with genus 1.

• If you were to fold or tear the paper to create multiple tunnels or holes, the number of holes increases, and the surface becomes more complex, which corresponds to a higher genus.

Now, let’s relate genus to divisors.

• Think of a divisor as a way of distributing certain “marks” or “labels” across the surface of your folded paper (your curve). A divisor could represent things like:

  • Marks where the paper is bent (points where a function is zero), or

  • Marks where the paper is torn (poles where a function has an infinite value).

For any curve, the genus g tells us how complex these divisors can be. Specifically:

• The genus gives us an upper bound on how complicated the divisor can be while still remaining "balanced" or simple enough to manage.

• No matter how complicated a divisor looks, we can always find a simpler equivalent divisor with at most g total complexity. Essentially, the genus limits how much complexity or imbalance can exist in the system.

Elliptic curves are simple in terms of their genus, with \(g=1\) This means every divisor on an elliptic curve can be simplified to just the difference between two points.

Elliptic curves are of genus 1 because they have just enough complexity to be interesting (like a simple fold or tunnel in paper), but not too complex to make the math difficult to handle.

This concludes Part 2 of our series, where we've explored the Picard group, divisors, principal divisors, genus, and their interconnections. In the next part, we’ll dive into "Pairing Groups" and build on everything we've discussed so far, leading us to a deeper understanding of bilinear relationships.

In the next part, we will dig into "Pairing Groups" and connect everything we discussed so far to create a bilinear relationships. Stay tuned!

For more updates, insights, and discussions, connect with me on Twitter: @privacy_prophet.

References

• Parings for beginners

• Group law - the chord and tangent rule.

• Fields and how field operations work.

• Identify Element

  You can find resources to learn about the above topic here → Cryptography 101

Elliptic Curve Cryptography

Introduction to Elliptic Curve Cryptography (ECC)

Elliptic Curve Cryptography (ECC) has revolutionised the field of cryptography by enabling secure communication with much smaller key sizes compared to traditional methods like RSA. Its foundation lies in the mathematical properties of elliptic curves, which provide both security and efficiency for modern cryptographic systems.

An elliptic curve is defined by an equation of the form:

$$y^2 =x^3 +ax+b$$

where a and b are constants that satisfy specific conditions to ensure the curve forms a smooth, non-singular shape. The points on this curve, along with a special "point at infinity," form a mathematical structure that can be used for cryptographic operations.

The core idea of ECC relies on the elliptic curve group and operations like point addition and scalar multiplication. These operations underpin the security of ECC-based systems, making it infeasible for attackers to reverse-engineer private keys from public ones due to the computational difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP).

Understanding Point Addition

One of the fundamental operations in ECC is point addition, which is the process of adding two points PP and QQ on an elliptic curve to produce another point RR. Depending on whether PP and QQ are distinct or identical, the operation involves different calculations:

• If \(P != Q\), a line passing through P and Q intersects the curve at a third point. Reflecting this point across the x-axis gives RR.

• If \(P = Q\), the operation is called point doubling. In this case, a tangent line to the curve at P is used to find the third point, followed by reflection.

These operations are not only geometrically intriguing but also computationally efficient, making them suitable for cryptographic systems.

Bilinear pairings, which extend the capabilities of ECC, point addition and other fundamental ECC operations play a critical role in setting up the necessary mathematical framework.

$$e(a, b) : G_1 \times G_2 \to G_T$$

Introduction to Fields in Mathematics

In cryptography, fields play a foundational role as they provide the mathematical framework for operations on elliptic curves and other cryptographic structures. A field is a set of elements equipped with two operations: addition and multiplication, which satisfy certain properties. These properties ensure that every element (except zero for multiplication) has an inverse, making the operations well-defined and consistent.

Some key characteristics of a field include:

1. Closure: The result of adding or multiplying any two elements in the field is also in the field.

2. Associativity and Commutativity: Both addition and multiplication are associative and commutative.

3. Identity Elements: The field has an additive identity (0) and a multiplicative identity (1).

4. Inverses: Every element has an additive inverse, and every non-zero element has a multiplicative inverse.

The most common examples of fields are:

• The field of real numbers

• The field of rational numbers

• Finite fields, also known as Galois fields \(F_p\), which are critical in cryptography.

In the case of elliptic curve cryptography, we often work over finite fields, such as \(F_p\) These fields allow us to define elliptic curves and perform secure, efficient computations, paving the way for robust cryptographic systems.

Let's dive into some in-depth design topics of ECC: Torsion Points and Endomorphism.

Torsion Points

Let’s have a quick recall of what point of Infinity is and how it correlates to the order of a Point in ECC:
The order of a point P on an elliptic curve is the smallest positive integer n such that:

\(nP=P+P+⋯+P=P+P+⋯+P(n times)=O\)

where O is the point at infinity, which acts as the identity element in the group of points on the curve.

• If \(nP=O\), then P is said to have an order of n.

• For any point P, the order n divides the total number of points on the curve (known as the curve order).

Now, the group order can be divides into smaller subgroups, based on Lagrange’s theorem.

For example, consider the curve ( \(E/\mathbb{F}_{101} : y^2 = x^3 + x + 1\) ). The # \( E/{F}_{101} = 105 = 3 \cdot 5 \cdot 7\). So we can get a point of order \(r|105\) by simply multiplying P by the appropriate cofactor, which is \(h = Order / r\). For example to get a point of order 3: \([35]P\). By definition a point is “killed” ( sent to O ) when multiplied by its order.

Any point killed by r over the full closure \(E(\overline F_q)\) is said to be in the r-torsion. ( The algebraic closure of a finite field \(F_q​, denoted \space \overline{{F}_q}\)​​, is the set of all roots of all polynomials with coefficients in \(F_q\)​. It is the "largest possible extension field" of \(F_q\) that contains every solution to such polynomials. )

By Hasse's theorem, the curve order is approximately \(q+1\), with a margin of error bounded by \(2\sqrt{q}​:\)

$$q+1−2\sqrt{q}≤ Order{ } E(F_q)≤q+1+2\sqrt{q}$$

The offset between # \(E(F_q)\) and \(q+1\) is called the trace of Frobenius and is denoted by t:

$$Order E(F_q) = q+1-t, {\space } where |t| <= 2\sqrt{q}$$

Endomorphism

What Is the Endomorphism Ring?

The endomorphism ring \(End(E)\) is a collection of all "maps" (functions) that take points on an elliptic curve EE and send them to other points on the same curve, while preserving the group structure. These maps can be thought of as ways to transform the curve while keeping its essential properties intact.

In this ring:

• Addition of maps works point wise: \((ψ_1+ψ_2)(P)=ψ_1(P)+ψ_2(P)\).

• Multiplication of maps is done through composition: \((ψ1∘ψ2)(P)=ψ1(ψ2(P))\).

Trivial Endomorphisms

Some endomorphisms are always present:

1. The multiplication-by-m map, denoted \([m]\), scales a point P by \(m: [m](P)= P + P + \dots + P \space (m \space times)\).

2. For elliptic curves defined over finite fields, there’s an additional map called the Frobenius endomorphism \(\pi\), which raises the coordinates of a point to the power q.

   If \(E\) is defined over \(F_q\), then the Frobenius endomorphism \(\pi\) is defined as:

$$\pi : E \mapsto E, \space (x,y) \mapsto ( x^q, y^q )$$

Non-Trivial Endomorphisms

Sometimes, elliptic curves have additional, more interesting endomorphisms. Let’s look at an example:

• Consider the curve \(E:y^2=x^3+b\) over a finite field \(F_q\).

• A special map, \(ξ\) is defined as \(ξ(x,y)=(ξ_3x,y)\) where \(ξ_3\) is a cube root of 1 \((ξ_3^3=1 \space but \space ξ_3≠1)\).

• Whether \(ξ\) is a valid endomorphism depends on the field:

  • If \(ξ_3∈Fq\) then \(ξ\) is defined over \(F_q\).

  • Otherwise, \(ξ_3\) lies in an extended field (e.g., \(F_{q^2}\)), meaning \(ξ\) operates on a larger space.

The Frobenius endomorphism \(\pi\) is a special type of endomorphism on an elliptic curve E defined over a finite field \(F_q\)​. Essentially, the Frobenius endomorphism maps a point \(P=(x,y)\) on the elliptic curve E over \(F_q\)​ to a new point \(π(P)=(x^q,y^q)\). This means it raises the coordinates of the point to the power of q (the size of the finite field), which can be thought of as a sort of "Frobenius twist."

• Effect on Points: When the Frobenius map \(\pi\) is applied to a point \(P=(x,y)\) the new point \(π(P)=(x^q,y^q)\) lies on the same elliptic curve, but the point might be in a different field extension, depending on the situation.

• Fixed Points: One of the important properties of the Frobenius map is that it "fixes" certain points. That is, if P is a fixed point of the Frobenius map, then applying the map again doesn't change the point. This happens in particular for points that are in the field \(F_q\)​, where raising the coordinates to the power \(q\) leaves the point unchanged.

• Mapping Across Extensions: The Frobenius endomorphism π\piπ also connects points from \(E(F_q)\) (the elliptic curve over \(F_q\)​) to points in higher field extensions, such as \(E(F_{q^2})\), depending on the specific case. This means that the Frobenius map can take points from \(E(F_q) \space to \space E(F_{q^2})\) and beyond, depending on how the curve is defined and the properties of the field.

Example: Cubic roots of unity will be defined in \(F_q\) if and only if \(q = 1 \space mod \space 3\)( this is because the multiplicative group of non zero elements in \(F_q\)​ is cyclic, and its order is \(q-1\). If \(q≡1 \space (mod \space 3)\) then \(q-1\) is divisible by 3, which ensures that there are elements in the field that satisfy \(x^3 = 1\). The order of an element \(g^k\) in the cyclic group is the smallest integer n such that \(g^{kn} = 1\). For \(x = g^k\) to satisfy \(x^3 = 1\), the order of \(g^k\) must divide 3. In a cyclic group, the order of any element divides the total order of the group ) . Let’s take curve equation : \(y^2 = x^3 +5\)

• Over \(F_{19}, ξ_3=7\) is a valid cube root of 1, so \( ξ\) works within \(F_{19}\).

• Over, \( F_{23}\) no cube root of 1 exists in \(F_{23}\). We need to extend to \(F_{23^2}\) to define \( ξ\). So we form quadratic extension \(F_{q^2}(u), u^2 + 1 = 0\). Now, \( ξ_3 = 8u + 11\) is a valid cube root.

Complex Multiplication (CM): When an elliptic curve has extra, non-trivial endomorphisms like \(ξ\), its endomorphism ring becomes larger than the integers \(Z\). This is called complex multiplication (CM).

• All elliptic curves defined over finite fields \(F_q\) have CM because the Frobenius endomorphism \(\pi\)always adds complexity to \(End(E)\).

• For curves defined over other fields (like \(Q\)), the presence of CM is less common and depends on whether additional maps exist.

Trace of Frobenius plays role in the characteristic polynomial satisfied by \(\pi\) given as:

$$\pi ^2 - [t].\pi + [q] = 0 \space in \space End(E)$$

meaning for all \((x,y) \in E( \overline{F_q})\) we have \((x^{q^2}, y^{q^2}) - [t] ( x^q, y^q) + [q](x,y) = O\)

This brings us to the end of Part 1 of this series. In the next part, we will dig into "Divisors," a concept from Algebraic Geometry, but we'll limit its scope to how it works in Elliptic Curves. Stay tuned!

For more updates, insights, and discussions, follow me on Twitter: @privacy_prophet.

References

• Parings for beginners

• Pairings by Vitalik

• Understanding of what QAP is and how to create one from R1CS.

• Group theory understandings

• Bilinear Pairings

Probabilistic Checkable Proofs ( PCP )

What is a PCP:

Prover generates a PCP oracle, which can be thought of as a big message of polynomial size. Verifier queries PCP oracle at random points, and using these queries verifier can verify the computation of a polynomial.

In Linear PCP, the PCP generated by the Prover is a linear function. The Oracle responds to linear queries by doing an inner product.

Recall:

\(p(x) = (\sum_{i=1}^m c_i \times l_i(x)) \times (\sum_{i=1}^m c_i \times r_i(x)) \times (\sum_{i=1}^m c_i \times o_i(x)) = V(x).q(x)\)

To show the above can be done using a linear PCP model.

• The verifier can submit only linear queries to the PCP:

  \( \times - = V(\gamma)\)

Some terminologies before we continue further:

• Knowledge of exponentiation:

  • Sample random \(\alpha\), compute \(g^{\alpha .l_i(\tau)}\) for i = 1...m.

  • \(\pi_1 = g^{\sum_{i=1}^m c_i \times l_i (\tau)}\) and \(\pi_1^{'} = g^{\sum_{i=1}^m c_i \times l_i (\tau)}\)

  • \(e(\pi_1, g^\alpha) = e(\pi^{'}, g)\)

• Generic Group Model

  • The adversary is only given an oracle to compute the group operation.

  • eg. given \(g^{\alpha.l_i(\tau)}\)for i= 1,...,m. The adversary can only compute their linear combinations.

Linear PCP

• Preprocessing ( Key Generation ):

  • Proving key: \(p, G, g, G_T, e\)

  • Compute Public Keys: \(g^{l_i(\tau)},g^{r_i(\tau)},g^{o_i(\tau)}\) for \(i=1, \ldots,m\) --- (1)

  • Evaluate: \(g^\tau , g^{\tau^2}, \ldots, g^{\tau^m}\) ( Public ). --- (2)

  • Also: \(g ^ {\beta(l_i(\tau) + r_i(\tau) + o_i(\tau))})\) for \(i \in [m]\) --- (3)

  • Verification Key: \(g^V(\tau) \) - this is known to the verifier

  • delete \(\tau\)

• Prove Generation

  • \(\pi _1 = g^{\sum_{i=1}^m c_i \times l_i(\tau)}\) , where the term in power is the public key calculated in (1).

  • Similarly, calculate \(\pi _2\) and \(\pi _3\) using (1) above.

  • \(\pi _4 = g^{q(\tau)}\) calculated using (2) above.

  • \(\pi_5 = \prod _{i=1}^m (g ^ {\beta(l_i(\tau) + r_i(\tau) + o_i(\tau))})^{c_i}\)

• Verification

  • The idea is to check the value of p(x) equation equality in the exponent.

  • Verify using: \(\frac{e(\pi_1, \pi_2)}{e(\pi_3, g)} = e(g^{V(\tau)}, \pi_4)\) bilinear relation.

  • \(e(\pi_1\pi_2\pi_3, g^\beta) = e(\pi_5, g)\): This check makes sure that the prover isn't cheating and not using the same vector \(c\) in the generation of \(\pi_1, \pi_2, \pi_3\).

The above protocol is not the real implementation. If you notice, while input in the above circuit is considered as a witness. But in practical application, a circuit has both, public and private inputs.

So to convert the above into a real protocol, notice the proof property that is generated above:

$$\pi_1 = g^{\sum_{i \in I_{mid}}c_i \times l_i(\tau)} * g^{\sum_{i \in I_{io}}c_i \times l_i(\tau)}$$

where \(I_{mid}\) is the witness, and \(I_{io}\) is the public Input/output. So now the proof becomes:

$$\pi_1 = g^{\sum_{i \in I_{mid}}c_i \times l_i(\tau)}$$

and the verifier can simply do:

$$\pi_1^* = \pi_1 . g^{\sum_{i \in I_{io}}c_i \times l_i(\tau)}$$

$$\frac{e(\pi_1*,\pi_2*)}{e(\pi_3^*, g)} = e(g^{V(\tau), \pi_4})$$

And that's Groth 16 protocol under the hood!!

Variant of Groth16

$$p(x) = (\sum_{i=1}^m c_i \times l_i(x)) \times (\sum_{i=1}^m c_i \times r_i(x)) \times (\sum_{i=1}^m c_i \times o_i(x)) = V(x).q(x)$$

1. Proof:

   • \(\pi_1 = g^{\alpha + \sum_{i=1}^m c_i \times l_i (\tau)}\)

   • \(\pi_2 = g^{\beta + \sum_{i=1}^m c_i \times r_i (\tau)}\)

   • \(\pi_3 = \prod _{i=1}^m (g ^ {\sum c_i \times \beta(l_i(\tau) + r_i(\tau) + o_i(\tau)) + V(\tau)q(\tau)})\)

2. Verify:

   • \(e(\pi_1, \pi_2) = e(\pi_3, g).e(g^\alpha, g^\beta)\)

To make the above systems Zero Knowlege, a randomizer is simply added to the proofs generated.

\(\pi _1 = g^{\sum_{i=1}^m c_i \times l_i(\tau) + \delta_1V(\tau)} \) and similarly for \(\pi_2\) and \(\pi_3\)

Properties of Groth16

1. Computation Cost: The cost to generate a proof in Groth16 is relatively high compared to the verification cost. This is because the prover must perform a series of complex mathematical operations, which include polynomial evaluations and multi-exponentiations in elliptic curve groups.

2. Input Length Dependence: The proving time is dependent on the length of the witness (the information that proves the statement). For more complex statements or larger datasets, the time required to generate a proof increases.

3. Memory Usage: Groth16 proving can be memory-intensive. The prover needs to handle large polynomials and multiple group elements, which requires substantial computational resources, especially for complex statements.

4. Parallelizability: The proving process in Groth16 can be parallelized to some extent. This means that with sufficient computational resources, the time taken to generate a proof can be reduced.

5. Efficient Verification: Groth16 stands out for its extremely efficient verification process. Verifying a proof typically involves a few pairings and elliptic curve operations, which are computationally cheaper than the operations required for proof generation.

6. Constant Time Verification: Regardless of the complexity of the original computation, the verification time remains constant. This is a significant advantage, especially in systems where quick verification is essential, like in blockchain transactions.

7. Low Resource Requirement: The verifier does not need extensive computational resources. This asymmetry between proving and verification complexity makes Groth16 particularly suitable for systems where the verifier's resources are limited, such as in smart contracts on a blockchain.

8. Asymmetry Advantage: The asymmetry in computational requirements between the prover and verifier in Groth16 is by design. While it demands more from the prover, it benefits systems where verification needs to be quick and inexpensive, a common scenario in decentralized systems like blockchains.

9. Scalability Impact: This asymmetry affects scalability. The efficiency in verification means that more transactions (or other verifiable computations) can be processed in a shorter time, which is crucial for the scalability of blockchains.

10. Security and Trust: The proving complexity also contributes to the security of the system, as it makes it computationally prohibitive to generate false proofs.

11. In Groth16 variants:

    1. Proof size: 3 group elements - 144 bytes

    2. Verifier time: 1 pairing equation

Follow me on social media: Twitter, and LinkedIn for new updates in the cryptography space and any discussion related to computer science.

• R1CS

• Transcript

• Selector Polynomial

• Vanishing Polynomial

• Quadratic Arithmetic Program

R1CS

The term "R1CS" stands for "Rank-1 Constraint System." It's a method used in computer science, particularly in the field of cryptography and zero-knowledge proofs. The Rank-1 Constraint System is a way to express a set of arithmetic constraints. It's commonly used in the construction of zero-knowledge proofs, particularly in systems like zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge).

An R1CS typically consists of three matrices: A, B, and C. Each row in these matrices represents a single constraint, and the system is satisfied if there exists a vector of variables \(\vec{x}\) such that for every row \( \vec{i}\), the following equation holds:

$$\vec{a}_i \cdot \vec{x} \times \vec{b}_i \cdot \vec{x} = \vec{c}_i \cdot \vec{x}$$

Transcript

Trace just means Prover is just going to evaluate this entire circuit and take the values on all the wires. In Interactive proofs, the value of every gate is traced, in Plonk, the trace is defined as the left input, right input, and output of every gate.

QAP: input + output of every multiplication gate.

e.g.:

( image credits to Yupeng Zhang )

Selector Polynomial

Let's assume a polynomial \(l_i(x)\) which means: is \(c_i\) the left input of gate j ?, for j = 1,2,3, where \(c_i\) is the value in the i'th position in the transcript ( as in the above image ).

e.g.

1. \(l_1(x) : (1,0,0)\).
   How? Is \(c_1\) left input of gate 1 ? Yes. Is \(c_1\) left input of gate 2: No. And finally is \(c_1\) left input of gate 3: No. The polynomial interpolation at a known set \(\Omega\) : \(l_1(w) = 1, l_1(w^2) = 0, l_1(w^3) = 0\).

2. \(l_x(x) : (0, 0 ,1)\)

   Polynomial interpolation: \(l_3(w) = 0, l_3(w^2) = 0, l_w(w^3) = 0\) since value 1 is the input of the addition gate which in turn is the left input of the multiplication gate ( remember we are taking trace over multiplication gate in case of QAP )

Properties:

• \(L(x) = \sum_{i=1}^9 c_i * l_i(x)\). If you write the trace for the entire transcript in the above example: \(L(w) = c_1 = 3\), \(L(w^3) = c_3 + c_4\). The values are the 1s that are present at the respective input column in the entire transpose.

• Similarly, we calculate \(r(x)\) and create a transcript then using that a selector polynomial \(R(x)\).

• Similarly, we have \(O(x)\) which represents the gate outputs.

Now we have:

$$p(x) = L(x)R(x) - O(x)$$

• Claim is \(p(w^j) = 0 , for \ j = 1,2,3..\)

Vanishing Polynomial

• We define \(p(x) = V(x)q(x)\) , where \(V(x) = (x - w )(x-w^2)(x-w^3)\) is the vanishing polynomial of the set \(\Omega = \{ w, w^2, w^3 \}\)

Finally:

P claims to know a w such that \(C(x,w) = y\) \(<==>\)P claims to know that a vector c such that \(p(x) = V(x)q(x)\).

Where the table is a piece of public information, and generated during preprocessing phase.

Now, instead of checking the constraints in the R1CS individually, we can now check all of the constraints at the same time by doing the dot product check on the polynomials.

Lastly, follow me on social media: Twitter, and LinkedIn for new updates in the cryptography space.

References:

• https://risencrypto.github.io/R1CSQAP/#:~:text=The%20next%20step%20is%20taking,vector%20%26%20the%20number%20of%20gates.

• https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649

• SNARK lecture on linear PCP by Yupeng Zhang Link

Problem addressed using FRI:

1. Want P time linear in degree, not field size:

   • Let's say we use a Merkle tree for commitment to values in a field f. But this is very inefficient since if field f is big, then the number of leaves, and consequently the proof length grows significantly. In FRI, rather than P merkle-commiting to all (p-1) evaluations of q, P merkle-commits to evaluations of q(x) for \(x \in \Omega\) of \(F_p\).

   • \(\Omega\) has size \(\rho ^ {-1} k\) where \(\rho < 1/2\) constant and k is the degree of q.

   • Proof length will be about \(\lambda / log(\rho ^ {-1}). log^2(k)\) hash values where \(\lambda\) is the security parameter, aka. " \(\lambda\) bits of security ".

   • Let \(\omega \in F_p\), n is the smallest integer such that \(\omega ^ n = 1\), then \(\Omega = \{ 1, \omega, \omega ^2, \ldots, \omega ^ {n-1} \}\)

   • From group theory, \(\Omega\) has size n if and only if n divides p-1.

     • Hence, FRI based SNARKs work over fields like \(F_p\) with \(p = 2^{64} - 2^{32} + 1\) , p-1 is divisible by \(2^{32}\). Running FRI over the field can support any power of 2 value of n up to \(2^{32}\).

   • For eg. FRI commitment to univariate polynomial \(q(x)\) in \(F_{41}[X]\) when \(8 = \rho^{-1}.k\), where roots of unity = \(\{ 1, -1, 9, -9, 3, -3, 14, -14 \}\) becomes the root of the committed merkle tree.

To visualize roots of unity try this tool -> https://www.geogebra.org/m/sZFwAZfs

1. V needs to know the committed vector at all evaluations over domain \(\Omega\) of some (k-1) degree polynomial.

   • V "inspects" a few entries of the vector to "get a sense" of whether its low-degree. This will add a Merkle authentication path ( log(n) hash values ) to the proof.

   • This is impractical. FRI's test will be interactive. We use a "folding phase" followed by a "query phase". The folding phase is log(k) rounds. The query phase is one round.

Folding Phase ( Interactive )

Step 1: Starting with a High-Degree Polynomial

• The process begins with the prover having a high-degree polynomial. This polynomial is a representation of the computation or data they intend to prove something about.

Step 2: Interpolation and Evaluation

• The polynomial is evaluated at various points. These points typically lie in a domain related to a specific subgroup of a finite field.

Step 3: The Folding Process

• The prover reduces the degree of the polynomial. They select a subset of the evaluation points and merge the values of the polynomial at these points using a linear or affine transformation.

• V picks up a random field element r, and r is used to "randomly combine" every two paired-up entries.

• q(x) is split into "even and odd components" -> \(q(x) = q_e(X^2) + Xq_o(X^2)\)

• The prescribed "folding" q is \(q_{fold}(Z) = q_e(Z) + rq_o(Z)\) where degree of \(q_{fold}\) is half of the degree of q.

Step 4: Recursive Application

• What Happens: After folding, the polynomial's degree is lowered. The prover then commits to this new, reduced-degree polynomial. Folding is repeated until the degree falls to 0.

• Why It Matters: This recursive process is essential for gradually simplifying the polynomial.

Step 5: End

• The length of the folded vector after the degree has fallen to 0 is still \(\rho ^ {-1} >= 2\). Since the degree should be 0, P can specify the folder vector with a single field element.

( image credit: Justin Thaler lecture ( link in references ).

• The calculation in the picture uses the fact that if x and -x are n'th roots of unity and z = \(x^2\). Then \(q_{fold}(z) = \frac{(r+x)}{2x} .q(x) + \frac{(r-x)}{-2x} .q(-x) \) ( derivation not covered in this post ).

• FRI heavily uses the fact that the map \(x -> x^2\) is 2 to 1 on \(\Omega\), ensuring that the relevant domain halves in size with each fold.

Query Phase ( Interactive )

• P may have "lied":

  • sending a vector that is not the prescribed folding of the previous vector

  • To "artificially" reduce the degree of the claimed folded vector.

• The Query phase is where the verifier tries to detect inconsistencies.

• V picks about \(\lambda / log ( \rho ^ {-1}) \) entries of each folded vector and confirming each is the prescribed linear combination of the relevant two entries of the previous vector.

• Proof length ( and V time ): roughly \((\lambda / log(\rho ^ {-1})_. log(k)^2\) hash evaluations. Each of the folded vectors ( log(k) ) is queried at \(\lambda / log ( \rho ^ {-1})\)

• For security analysis, refer the links in references. This article focuses on the working only.

• There is a known attack where prover folders a polynomial s rather than q, where s agrees on a set T = \(\rho n\) elements of \(\Omega\).

Polynomial Commitment using FRI

• Problems with FRI

  • P has only the Merkle-committed to evaluations of q over domain \(\Omega\), not the whole field.

  • V only knows that q is "not too far" from low-degree, not exactly low-degree.

• Solution

  • We know \(q(X) - v = w(X)(X-r)\) is equivalent to \(q(r) = v\) ( refer here). w is a polynomial of degree at most d.

  • So to confirm \(q(r) = v\) V applies FRI's fold + query procedure to the functions \((q(X) - v)(X-r)^{-1}\) using degree bound d-1. Whenever the FRI verifier queries this function at \(\Omega\), evaluation can be obtained with one query to q at the same point.

  • V doesn't know that q is exactly a low degree, but to pass V's check, \(v\) has to equal \(h(r)\) where h is the degree d polynomial that is closest to q.

Each FRI verifies query brings <1 bit of security to the commitment scheme. FRI today is used as a weaker primitive tha a polynomial commitment ( list polynomial commitment scheme ), which suffices for SNARK security. P is bound to a "small set" of low-degree polynomials rather than to a single one.

Conclusion: The FRI commitment scheme represents a significant advancement in the field of cryptographic proofs, enabling more secure and efficient verification of computations in various applications, including blockchain technology and privacy-preserving computations.

Lastly, follow me on social media: Twitter, and LinkedIn for new updates in the cryptography space.

References:

1. https://blog.lambdaclass.com/how-to-code-fri-from-scratch/

2. Lecture by Justin Thaler Link

3. https://chat.openai.com/

4. https://eprint.iacr.org/2019/1020.pdf

5. https://aszepieniec.github.io/stark-anatomy/fri.html

The integration of mathematics in cryptography has led to innovative solutions like bulletproof commitment schemes, which are essential in enhancing digital security and privacy. Bulletproofs are a form of non-interactive zero-knowledge proof system, that relies heavily on mathematical concepts to provide efficient and secure commitment schemes. In this post, we delve into the mathematical underpinnings of bulletproofs and how they revolutionize commitment schemes.

What is a Bulletproof Commitment Scheme?

A bulletproof commitment scheme is a cryptographic protocol that allows a party to commit to a value, maintaining its confidentiality, and ensuring the integrity of the commitment. These schemes are known for their efficiency, non-reliance on a trusted setup, and their ability to produce short proofs.

Mathematical Foundations of Bulletproofs

1. Pedersen Commitments: The core of bulletproofs lies in Pedersen commitments, a cryptographic algorithm based on discrete logarithm problems. A Pedersen commitment to a value v is of the form C = vG + rH, where G and H are known generator points on an elliptic curve, and r is a secret blinding factor.

2. Range Proofs: Bulletproofs provide a way to prove that a committed number lies within a certain range without revealing the number itself. This is done through complex polynomial commitments and inner product arguments, leveraging mathematical constructs like Hadamard products and vector operations.

3. Inner Product Argument: At the heart of a bulletproof range proof is an efficient protocol for proving the inner product between two vectors, which allows the verifier to check that the commitment represents a number in the desired range without learning anything more about the number.

How Bulletproof Commitment Schemes Work

Transparent Setup:

• Sample random \(gp = (g_0, g_1, g_2, \ldots, g_d) \) in G.

• Commit: \(f(x) = f_0 + f_1x + f_2x^2 + \ldots | f_dx^d\)
  \(com_f = g_0^{f_0} + g_1^{f_1} + \ldots + g_d^{f_d}\)

Steps in working of Poly-commitment based on BulletProofs:

1. Evaluate

   • \(v = f_0 + f_1u + f_2u^2 + f_3u^3\) and send to the verifier.

   • Compute \(L, R, v_L, v_R\)

     where \(L = g_2^{f_0}.g_3^{f_1}\), \(R = g_0^{f_2}.g_1^{f_3}\) , \(v_L = f_0 + f_1u\), \(v_r = f_2 + f_3u\) and sent to verifier.

   • Receive \(r\) from the verifier, reduce \(f\) to \(f^{'}\) of degree \(d/2\) where new polynomials change from \(f_0, f_1, f_2, f_3\) to \(rf_0 + f2, rf_1 + f_3\)

   • Update the bases \(gp'\)

2. Verify

   • Check \(v = v_L + v_R.u^{d/2}\)

   • Generate \(r\) randomly

   • Update:

     • \(com^{'} = L^r.com_f.R^{r^{-1}}\)

     • \(gp^{'}= (g_0^{r^{-1}}.g_2, g_1^{r^{-1}}.g_3)\)

     • \(v^{'} =r.v_L + v_R\)

Recurse log d times.

(image credit: Yupeng Zhang lecture on ZKP MOOC)

Applications and Importance

• Blockchain and Cryptocurrency: In blockchain, bulletproofs enable confidential transactions by allowing the amounts to be hidden yet verifiable.

• Voting Systems: Secure voting mechanisms can utilize bulletproofs to count votes accurately while maintaining voter anonymity.

• Privacy-Enhancing Technologies: They are crucial in constructing zero-knowledge proofs, pivotal for privacy in various digital applications.

Conclusion

The mathematical complexity and cryptographic robustness of bulletproof commitment schemes mark a significant advancement in secure digital communications. By blending advanced mathematics with cryptographic techniques, bulletproofs offer a powerful tool for ensuring privacy and integrity in various digital applications, especially in the rapidly evolving field of blockchain technology. Understanding these schemes not only provides insight into modern cryptographic practices but also underscores the importance of mathematical principles in developing secure digital systems.

Lastly, follow me on social media: Twitter, and LinkedIn for new updates in the cryptography space.

A KZG polynomial commitment scheme allows a prover to commit to a polynomial so that they can later reveal and prove properties about the polynomial (like its value at certain points) without revealing the entire polynomial. This is particularly useful in scenarios where the polynomial represents some private data or computation.

Prequistics:

• How cyclic groups work in Numbers Theory

• Discrete Log + Diffie-Hellman

• Understanding of Bilinear Pairing

KZG Poly-commit scheme

Before we start, let’s see the elements we have:

• Bilinear Group p, G, g, Gₜ, e.

• Univariate polynomials: \(F = F_p^{<=d}[X]\)

Step 1: Keygen

• Sample random τ∈Fp

• \(gp = (g, g^{\tau}, g^{\tau^2}, \ldots, g^{\tau^d})\)

• delete \(\tau\) ( trusted setup )

Step 2: Commit

• commit (gp, f) -> \(com_f\)

• \(f(x) = f_0 + f_1x + f_2x ^2 + \ldots + f_dx^d\)

• \(com_f = g^{f(\tau)}\)
  \(= g ^ {f_0 + f_1\tau + f_2\tau^2+ \ldots + f_d^{\tau ^ d}}\)

  \(= (g)^{f_0}. (g^\tau)^{f_1}. (g^{\tau^2})^{f_2}. \ldots (g^{\tau^d})^{f_d}\)

Step 3: Proof

• \(eval(gp, f, u) -> v, \pi\): where \(u\) is a random point the verifier chooses.

  • \(f(x) - f(u) = (x - u)q(x)\) as u is a root of \(f(x) - f(u)\)

  • Compute \(q(x) \) and \(\pi = g^{q(\tau)}\) computed using gp elements.

Step 4: Verify

• \(verify(gp, com_f, u, v, \pi )\):

  • where \(v = f(u)\)

  • The idea is to check the equation at point \(\tau\): \(g ^ {f(\tau) - f(u)} = g ^ {(\tau - u)q(\tau)}\)

  • Challenge: only know \(g ^ {\tau - u}\) and \(g ^ {q(\tau)}\)

  • Solution: pairings - \(e(com_f / g^v, g) = e(g^{\tau - u}, \pi)\)
    \(=e(g,g)^{f(\tau) - f(u)} = e(g,g)^{({\tau - u}). q(\tau)}\)

The key features of KZG polynomial commitments include:

1. Commitment: The prover commits to a polynomial by computing a commitment, a concise representation of the polynomial. This commitment is computed using a bilinear pairing over elliptic curves, which forms the cryptographic backbone of the scheme.

2. Evaluation Proofs: The prover can provide proofs that a committed polynomial evaluates to a certain value at a specific point. These proofs are small in size and can be verified quickly.

3. Hiding Property: The commitment does not reveal the polynomial itself, preserving the privacy of the data.

4. Efficiency: KZG commitments are highly efficient in terms of both computation and communication overhead, making them suitable for use in blockchain networks where resources are limited.

5. Applications: They are widely used in the construction of zk-SNARKs (zero-knowledge Succinct Non-interactive ARguments of Knowledge) and other zero-knowledge proof systems. In blockchain, they enable scalable and private transactions.

Achieving Zero-Knowledge

The plain KZG is not ZK. Eg. \(com_f = g ^{f(\tau)}\) is deterministic.

To achieve Zero Knowledge, we mask the commitment with randomizers.

• Commit: \(com_f = g^{f(\tau) + r\eta}\)

• Evaluate: ( where \(r\) and \(r^{'}\) are both randomizers )

  $$f(x) + ry - f(u) = (x - u)(q(x) + r^{'}y) + y(r - r^{'}(x - u))$$

$$\pi = g ^ {q(\tau) + r^{'}\eta} , g^{r-r^{'} (\tau - u)}$$

Other Variants Of KZG

1. Batch opening: Single Polynomial:

   • Prover wants to prove \(f\) at \(u_1,\ldots, u_m \) for m<d.

     * Steps:

     * Extrapolate \(f(u_1),\ldots,f(u_m)\) to get \(h(x)\)

     * \(f(x) - h(x) = \prod_{i=1}^m(x-u_i)q(x)\). Why? Check the roots of polynomials on LHS.

     * \(\pi = g ^ {q(\tau)}\)

     * \(e ( com_f / g^ {h(\tau)}, g) = e(g^{\prod_{i=1}^m(\tau - u_i)}, \pi)\) where \(g^{h(r)}\) verifier can calculate using the global params.

2. Batch opening: Multiple Polynomials

   • Prover wants to prove \(f_i(u_{i,j}) = v_{i,j}\)

   • Steps:

     • Extrapolate \(f_i(u_1),\ldots,f(u_m)\) to get \(h_i(x)\) for \(i \in [n]\)

     • \(f_i(x) - h_i(x) = \prod_{i=1}^m(x - u_m)q_i(m)\)

     • Combine all \(q_i(x)\) via a random linear combination.

And that's it !!!

Lastly, follow me on social media: Twitter, and LinkedIn for new updates in the cryptography space.

This article will teach you how such a system works at a mathematical level and lay the foundation for a new area of research namely “Zero-Knowledge Proofs”.

Some terms to know before we continue further:

1. Commitment scheme:

In cryptography, a commitment scheme is a fundamental concept that allows one party to commit to a chosen value (or chosen statement) while keeping it hidden from others, with the ability to reveal the committed value later. Commitment schemes are designed to be binding and hiding:

• Binding: This property ensures that the committing party cannot change a value once a value has been committed. In other words, it’s impossible (or computationally infeasible) for the committer to find another value they can convincingly claim to have committed to originally.
• Hiding: This property ensures that the value remains secret until the committer chooses to reveal it. Before the reveal, no other party can determine the committed value.

2. Function commitments :

• Polynomial Commitments: commitments to functions of type:

Generalized Polynomial Expression

• Multilinear Commitments: commitments to functions of type f(x1,…xk)

Generalized Multilinear Expression

• Vector commitments: eg. Merkle trees.

Example Expression for Vector

3. SZDL Lemma:

Schwartz-Zippel-Demillo-Lipton lemma is a multivariate generalization of fact:

• Let p != q be a univariate polynomial of degree almost d. Then

• SZDL: Let p!= q be l-variate polynomials of total degree almost d.
  Then

• “Total degree” refers to the maximum sum of degrees of all variables in any term.

Sum-Check Protocol

The Sum-Check Protocol is a fundamental technique in theoretical computer science, particularly in the field of interactive proof systems and complexity theory. It’s often used to prove properties about polynomials and is a key component in constructing various interactive proofs, including those for NP-complete problems.

Input: V given Oracle access to an l-variate polynomial g over field F.

Goal: The goal is to verify a claim about the sum of values of a multivariate polynomial i.e. compute the expression:

Generalized Expression to compute in Sum-Check protocol

Computing the above expression is expensive, and hence the verifier uses interactive proof to verify the result of the expression that the prover returns ( after computing the given expression ).

Protocol Steps:

• Initialization:
  The prover wants to convince the verifier that the sum of the polynomial g over a specified domain is a certain value S.
• In each round, the prover sends a claim about the sum of a certain polynomial. The verifier checks the claim at a randomly chosen point and asks the prover for a new claim about a related, but simpler polynomial (typically, by fixing one variable). This process is repeated for each variable of P.
• P (prover ) sends claimed answer C₁. The protocol must check the ( where F ∈{0,1} ):

• Round 1: P sends a univariate polynomial S₁ ( X₁) claimed to equal:

• The verifier needs to check 2 things:
  1. Does S₁ equals H₁
  2. Even if S₁ equals H₁, is that consistent with try answer C₁.
• Verifier checks
  1. C₁ = S₁(0) + S₁(1) where F ∈{0,1}
  2. Now to check S₁ and H₁, verifier simply checks if S₁ and H₁ agrees at a random point r₁. S₁ is easy to calculate at r₁ since the prover explicitly sends the polynomial to a verifier. But evaluating H₁(r₁) is hard to calculate for the verifier. To address this V picks r₁ at random from F and sends r₁ to P.
• Round 2: To address the issue of how to calculate H₁(r₁), the verifier recursively checks that S₁(r₁) = H₁(r₁). We utilize the form of expression that H₁ to do this, by using the following relation:

• Round n ( Final round ) : P sends a univariate polynomial sₙ(Xn) claimed to equal:

• V checks that sₙ₋₁(rₙ₋₁) = sₙ(0) + sₙ(1). Also, sₙ(rₙ) = g(r₁, …, rₙ), which the verifier can easily compute since it can simply query the oracle for the value of g(..) directly.
• Final Step:
  The prover sends a univariate polynomial to the verifier. The verifier checks this final polynomial at a random point to confirm the prover’s claim.

Properties:

• Soundness: If the prover’s original claim about S is false, then with high probability, they will be caught in a lie at some point in the protocol.
• Completeness: If the prover’s claim is true, they can always convince the verifier.

I won’t be diving into the calculations for the above properties here. Feel free to use the reference links if interested.

In Part 2, I will cover a simple implementation of the Protocol from scratch.
Connect with me on Twitter and LinkedIn, for any help, or to talk about cryptography, privacy, and blockchain in general.

References:
- ChatGPT 4
- Interactive Proofs by Justin Thaler Link

The Blockchain space, for years, had several issues when it came to scalability, decentralization, and performance aka the Blockchain Trilemma Problem.

This article will cover the 3 most famous architecture at the time of writing:
1. Proof of Work ( POW ) — Bitcoin, Ethereum 1.0, Litecoin, Dogecoin
2. Proof of Stake ( POS ) — Ethereum 2.0, HarmonyONE, Algorand
3. Proof of History ( POH ) — Solana ( The only consensus which claims to resolve the Blockchain Trilemma )

There are other solutions like Proof of Authority and Proof of Transfer, which we won’t cover in this article.

So, let's dive deeper :)

Proof Of Work

Most security focuses on consensus and the consensus which market the beginning of this industry. The consensus was introduced by an anonymous entity names Satoshi Nakamoto in 2009, giving birth to Bitcoin.

This consensus derives its security from the computational power of the miners. Miners are nodes ( or computer machines simply ) that do some mathematical calculation to solve a given problem. The first machine to complete the calculation of the problem gets rewarded if the result it gave is correctly verified by the other participating nodes in the network. Yes, Bitcoin is the reward that the miner on the bitcoin network receives. Since there is a race among the minors, to do the computation as fast as possible, more and more power is required to run the hardware required to run the system.

The Blockchain Trillema:

If the focus is entirely on Security and Decentralization, then the cost is Scalability. Hence Bitcoin Blockchain takes around 10 minutes to complete a transaction, and Ethereum 1.0 takes around 3 minutes.

To fix this issue, there are several scaling solutions have been developed. Lighting Network for Bitcoin is a great example. Similarly, Optimistic Rollups, ZK-Rollups, State Channels, Sidechains, Plasma. Taking a deep dive into these solutions is another article in itself :)

If you are interested in visualizing the working of simple pow Blockchain, checkout -> https://andersbrownworth.com/blockchain.The nonce is the math value to be calculated.

Proof Of Stake:

Proof of Stake is relatively a new solution, which aims to make scalable blockchains.

The nodes ( simply computers ) stake an amount of cryptocurrency to become candidates to validate new blocks and earn rewards from them. The algorithm, based on the quality of stake and other factors like, coin-age, randomization, etc., chooses from the candidates' nodes, the node which will validate the new block.

Since the computing node is determined algorithmically, over competitiveness, results in fewer hardware requirements, and consequently more power efficiency. Ethereum aims to migrate to POS by the end of 2021.

There are several variations in the implementation of course. Most of the implementation/innovation is done in the algorithm which determines the elected node. A good example of an algorithm is Effective Proof of Stake.

An important term to know when it comes to POS architecture is Sharding. Ethereum 2.0 aims to have 64 shards. The question is what is sharding?
Sharding is basically dividing one blockchain into several chains, which will interact with each other using the main chain called the “Beacon Chain”. These other chains are simply called “shard chains” or simply “shard”.
For better understanding, imagine a bank. 100 people want to take out some cash from their accounts. If they all assemble at the branch office it will take a long time. To fix that, there are several ATMs installed, let's say 4, so now, people can go in groups of 20 to these ATMs and get their cash faster. The bank branch only has 20 people to deal with now, but at the same time acts as the body responsible for keeping track of all the 100 customers. The ATMs are the ‘shards’ and the bank branch is our ‘beacon chain’.

P.s Using banks as an example, since any reader new to this space can easily understand. Defi >> Banks anytime :)

Proof of History

This is indeed one of the most innovative approaches to solve the Blockchain Trilemma problem. Introduced by Solana, This consensus has been a highlight for its highly effective result.

Both POW, POS have a very high Block Time because the message needs to be majority ( > 50%) nodes, to get added to the block. Some innovative solutions target this in POS ( like Harmony.One 2 seconds finality). So POH aims to solve this using time cryptographic timekeeping.

Definition by SolanaLabs: “The Proof of History is a high-frequency Verifiable Delay Function. A Verifiable Delay Function requires a specific number of sequential steps to evaluate, yet produces a unique output that can be efficiently and publicly verified.”.

Don’t worry if you don't get that. Let's take another imaginative scenario to understand this one.

Imagine a person in a restaurant, having served a coffee. The restaurant has 5 other customers who come at intervals of 30 seconds, and on entering just take a picture of the coffee mug. Now after the person completes drinking his coffee, if we combine all the pictures taken by the customers, we can see the order in which the pictures would be arranged ( simply by observing the amount of coffee left ). This gives a precise order of time. So every picture is a precise idea of time. So the picture can be compared to a block and combined with the ordering of photos ( blocks ), is Proof of History.

Hope this article gives you a clear picture of the main consensus in use right now and a slight idea of how early this space is 😀. For more consensus study try -> https://tokens-economy.gitbook.io/consensus/

Lastly, connect with me on Twitter, for any help, or for learning about the latest happenings in this crazy space.

During the limited time-frame, we came up with our project “CoronaRedemption”. This application included the following features:

• Anonymous reporting of the violation of lockdown by people to the concerned authorities
• Ability to start donation camps by individuals or institutions affected
• View the current state of the spread of the virus via dynamically updated graphs

Video Demo of our project: https://www.youtube.com/watch?v=PIdcg4L6Dgo

Live Demo: https://covidextricate.herokuapp.com/

Let’s dive into the details of the project.

Report Lockdown Violation

We have come up with a solution to help control the violation of lockdown ( which is the key weapon for fighting this pandemic). People can come on our portal, give some unique identification key, we verify it, and then send back a special entry token to the user.

Report Violation Dashboard

Now the user can use this entry token and upload photos of people violating the lockdown ( that they can take using their cameras from their rooftops etc.). The uploader will remain totally safe and anonymous since the image uploaded will be stored over distributed storage (IPFS) and the key to view them will only be with the government authority concerned with control.

We used the Matic blockchain network to provide us with the anonymous solution of storing report details so that people can use their Ethereum address with no ETH to report a case of violation.

The data stored at the backend will only contain the unique id in encrypted form and corresponding token send. This will help avoid spam image uploads. The token is used by the user will in no way reveal his identity if someone gets access to who uploaded an image in some way since there is no way the token will lead back to the user.

Donation Camps

Corona has caused a lot of loss of jobs, money problems for several institutions (especially those involved in the treatment of this pandemic).

Donation Camp DashBoard

People can come here, provide details about their needs, and after giving legitimate proof of their need, they can raise a donation camp and get funded.

We are using the decentralized nature of the blockchain to transfer wealth from the rich to the needy ones without the need to rely on intermediaries and making this process a lot faster + transparent.

In this way, many people can get money for survival and institutes the option to get money faster. The government is providing money to help but this way its a direct transfer of money from the donor to the needy, resulting in faster services.

Live Updates

Lastly, users can browse the live statistics regarding COVID-19. Data can be viewed in the form of worldwide stats, country-wide stats, country-wise historic timeline to monitor growth.

Graphical representation along with tabular format, both are available on our portal.

We would like to thank the HackOn team.

Special Thanks to Devfolio, Matic, Google Cloud, GitHub, Elastic, and IBM for sponsoring the event.

Submission Link: https://devfolio.co/submissions/coronaredemption