forked from commonprefix/paper-template
-
Notifications
You must be signed in to change notification settings - Fork 0
/
grant-proposal.tex
83 lines (63 loc) · 8.58 KB
/
grant-proposal.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
\section{Grant Proposal}
This project will be implemented in the course of $4-6$ months. Members of the
Common Prefix team will be involved on an as-needed basis, depending on the
expertise required. For example, the following people will likely be relevant
to the project's implementation:
\begin{itemize}
\item \textbf{Dionysis Zindros} is a post-doctoral researcher at Stanford University. His research is focused on light and superlight clients, on which he did his Ph.D. dissertation, “Decentralized Blockchain Interoperability.” Some of his relevant published works include \href{https://eprint.iacr.org/2017/963.pdf}{Non-Interactive Proofs of Proof-of-Work}, \href{https://eprint.iacr.org/2018/1048.pdf}{Proof-of-Work Sidechains}, \href{https://eprint.iacr.org/2018/1048.pdf}{Proof-of-Stake
Sidechains}, \href{https://eprint.iacr.org/2021/623.pdf}{Mining in Logarithmic Space}, \href{https://arxiv.org/abs/2203.15968}{Light Clients for Lazy Blockchains}, \href{https://eprint.iacr.org/2019/1096.pdf}{Proof of Burn}, \href{https://eprint.iacr.org/2020/1122.pdf}{The Velvet Path to Superlight Blockchain Clients}, \href{https://eprint.iacr.org/2019/1444.pdf}{Compact Storage of Superblocks for NIPoPoW Applications}, \href{https://eprint.iacr.org/2020/138.pdf}{Smart Contract Derivatives}, and
\href{https://eprint.iacr.org/2020/927}{A Gas-Efficient Superlight Bitcoin Client in Solidity}. He co-authored the “Proofs of Proof of Proof of Stake in Sublinear Complexity” paper. He has published in top peer-reviewed conferences, such as IEEE Security \& Privacy, ESORICS, Financial Cryptography (and the Workshop on Trusted Smart Contracts), and Advances in Financial Technologies. Regarding practical software engineering experience, Dionysis has worked on the Product Security team at Twitter and the Incident Response Development team at Google. He has also presented at practical security conferences like Black Hat Europe and Black Hat Asia.
\item \textbf{Shresth Agrawal} is a developer, researcher, and entrepreneur. He is one of the authors of the “Proofs of Proof of Stake in Sublinear Complexity” paper and was responsible for building the first ever light client for Ethereum, Kevlar. He has experience building efficient and secure algorithms, protocols, and smart contracts for several DeFi protocols. Previously, he worked at ParaSwap, where he was responsible for architecting and developing a large portion of the core aggregation algorithm. He was awarded by the President of India for his research on contagious diseases. Shresth completed his Bachelor’s degree from Jacobs University Bremen and is currently pursuing his Master’s degree at Technical University Munich. He is interested in Cryptography, Security, Consensus Protocols, Decentralized Finance, and Ethereum.
\item \textbf{Apostolos Tzinas} is a smart-contracts software engineer. He is pursuing a joint Bachelor’s and Master’s in Electrical and Computer Engineering at the National Technical University of Athens. Apostolos has extensive front-end software engineering experience working at Maya Insights and NutriDice, where he took on a full-stack software engineering role. He has worked with numerous programming languages and technical stacks. He loves algorithms, and as a high school student, he participated in Informatics Olympiads, such as the Junior Balkan Olympiad in Informatics.
\item \textbf{Dimitris Lamprinos} is a software engineer based in Thessaloniki. He holds a Bachelor’s degree in Computer Science from the Aristotle University of Thessaloniki. Dimitris works on smart contract development and basic consensus development. He has significant experience in developing and scaling web2 applications in Amondo, Geekbot, and Vidpulse. He also has algorithmic cryptocurrency trading experience and has worked on developing and deploying smart contracts to the Ethereum
blockchain since the early days of ICO boom.
\end{itemize}
This project will be executed in multiple phases, described in detail below.
\subsection{Phase 1: Architectural Design}
During this phase, we will study the Axelar codebase in depth and propose a suitable architecture, consisting of a CosmWasm module that will implement the on-chain Ethereum light client.
Our approach will stick to the following principles:
\begin{itemize}
\item \textbf{Respectful of previous work.} Our proposed architecture will require minimal changes to the codebase, maintaining the existing design choices of the codebase.
\item \textbf{Extensibility.} The architecture will allow extending the light client to different source chains in the future, beyond Ethereum.
\item \textbf{Modularitity.} The architecture will be modular, in a way that allows upgrading to a different proof mechanism (e.g., SPV or ZK) and makes the protocol future-proof.
\end{itemize}
\noindent
\textbf{Deliverables.} At the conclusion of this phase, we will deliver the following items:
\begin{itemize}
\item A detailed design document, that describes the architecture of the light client to be implemented on Axelar. The design document will detail the different components that we will develop. These include the CosmWasm module which will run within the Axelar codebase (acting as the verifier), as well as the modifications needed on the attestor codebase (also part of the full node), so that attestations can be reported to the on-chain verifier.
\end{itemize}
The document will be delivered in LaTeX PDF format and include pseudocode for the relevant components, so that their role is clear from a theoretical point of view.
\subsection{Phase 2: Consensus Validation}
During this phase, we will implement the consensus components of the on-chain light client. The implementation will be based on the outcome of Phase $1$. Based on our current understanding of the Axelar architecture, during the consensus implementation phase we will implement the following:
\begin{itemize}
\item verification of the Ethereum sync committee \emph{handover signatures}, including aggregate signature verification and quorum logic;
\item verification of latest finalized block using sync committee signatures and Ethereum finalization logic.
\end{itemize}
\noindent
\textbf{Deliverables.} At the conclusion of this phase, we will deliver the following items:
\begin{itemize}
\item A Cosmos CosmWasm module, which implements the consensus components of the on-chain Ethereum light client.
\item A test suite, which verifies the correctness of the consensus components.
\item A component that allows any friendly-but-untrusted party to submit to the on-chain verifier the consensus attestation data (sync committee signatures and block headers), produced via the Ethereum Beacon chain API.
\end{itemize}
\subsection{Phase 3: Execution Validation}
% TODO(shresth): High level description of this phase
This phase consists of implementing the execution logic of the on-chain Ethereum light client, responsible for checking EVM-related data (such as Ethereum transactions and events). In particular, we will implement the verification of Ethereum execution data, given a validated finalized Ethereum block. This includes the verification of transactions and events and checking the validity of the Merkle proofs for transactions and/or events as needed.
\noindent
\textbf{Deliverables.} At the conclusion of this phase, we will deliver the following items:
\begin{itemize}
\item An extension of the CosmWasm module (developed during Phase $2$), that implements the execution components of the on-chain Ethereum light client.
\item A test suite that verifies the correctness of the execution components of the CosmWasm module.
\end{itemize}
\subsection{Phase 4: Theory, Deployment \& Audit}
During this phase, we will formalize the light client's construction and prove its security guarantees in a formal and rigorous manner.
We will also deploy the light client on Axelar's testnet and hand over the codebase with documentation to the Axelar team. We expect the Axelar team to conduct an audit of the codebase, before deploying it to the mainnet.
During this phase, we will help the Axelar team with the audit process and fix any issues that arise.
\noindent
\textbf{Deliverables.} At the conclusion of this phase, we will deliver the following items:
\begin{itemize}
\item Testnet deployment of the Ethereum light client to the Axelar network (Lisbon).
\item Handover of the codebase to the Axelar team with proper documentation.
\item A LaTeX document that formalizes the light client construction and proves its security guarantees.
\item Any fixes to the codebase that may be required as a result of an audit by the Axelar team.
\end{itemize}