Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove duplicated section on "prove anything" in main aggregator tex #40

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -69,9 +69,8 @@ \section{``Prove Anything'' Paradigm}

Figure \ref{fig:invalid-batch} shows that when a batch processing fails, the state remains unchanged $S_{i+1}=S_i$ and a proof of this lack of state change is produced. This occurrence should be infrequent yet it is possible.

The \textit{prove anything} approach allows us to implement an anti-censorship measure called \textbf{forced batches}. Using these approach, an user can take the role of a sequencer for getting its L2 transactions into the virtual state in case the trusted sequencer is not doing so. The main use case is to allow a user to send bridge transactions in order to withdraw assets from L2 without the risk of censorship (which will make it impossible to withdraw the funds). Since it is an (untrusted) user who is sending the L2 batch data, we must be sure that we can prove anything that the user sends. The forced batches mechanism will be explained later on (when describing the different security measures implemented in the zkEVM).
The \textit{prove anything} approach allows us to implement an anti-censorship measure called \textbf{forced batches}. Using these approach, a user can take the role of a sequencer for getting its L2 transactions into the virtual state in case the trusted sequencer is not doing so. The main use case is to allow a user to send bridge transactions in order to withdraw assets from L2 without the risk of censorship (which will make it impossible to withdraw the funds). Since it is an (untrusted) user who is sending the L2 batch data, we must be sure that we can prove anything that the user sends. The forced batches mechanism will be explained later on (when describing the different security measures implemented in the zkEVM).

The ``prove anything'' method enables the implementation of an anti-censorship measure known as \textbf{forced batches}. By using this method, A user may operate as a sequencer by shifting its L2 transactions to the virtual state in case the trusted sequencer don't sequence it. The main goal is to allow a user to submit bridge transactions to withdraw assets from L2 without the risk of being censored by the trusted sequencer, thereby preventing the withdrawal of user funds from the network. Take into account that we must authenticate all information provided by the untrusted actor sending the L2 batch data. The forced batches technique will be explained in the part that covers the security mechanisms incorporated into the zkEVM.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Expand Down