owned this note
owned this note
Published
Linked with GitHub
# Rollups, Validiums, zkEVMs concepts
> Note: this document is a wrapp up of notes on the topic, there may be errors, if so, please add a comment with the correction 🙌
[TOC]
## EVM compatibility concept
Often we hear about *'EVM compatible'* concept in different contexts, it's important to be aware that there are different concepts and approaches behind. **Having an EVM in our platform is different than being able to plug our platform to any EVM chain**:
![](https://hackmd.vocdoni.net/uploads/upload_22ed5399cbc9bac24b8701b3c33fc1df.png)
## L1 vs L2 vs sidechain
For example, if the sidechain (L1) nodes stop working, the users can not do anything. If the rollup (L2) nodes stop working, the users can still operate from the L1 where the rollup is plugged in, and they can exit (in the case that the rollup is for economical txs).
## Side chains vs Rollups concept
Both (sidechains & rollups), can be designed to have one-purpose functionallity or to have internal EVM compatibility:
![](https://hackmd.vocdoni.net/uploads/upload_8ad205ed70d257ee6147ea489022bbf3.png)
## zkRollup vs Validium concept
Both (zkRollup & Validium) approaches are verified on L1 (for example Ethereum main chain). The main difference is the data availability:
- **zkRollup** uses the L1 as the data availability layer, so all the needed data to reconstruct the rollup state can be found on L1. This is more expensive, as needs to pay for that storage.
- **Validium** puts the data availability out of the L1, is cheaper, but less 'trustless' in the sense that there is dependency on somebody (data availability layer) having the incentives to keep the data available (can be in a centralized server, in a sidechain, etc).
![](https://hackmd.vocdoni.net/uploads/upload_58e72888594c674b9bc4cb9c3466fb5a.png)
<a href="https://twitter.com/epolynya/status/1513720590439387137" title="https://twitter.com/epolynya/status/1513720590439387137" targe="_blank">
<img style="width:60%;border:1px solid black; margin:10px;padding:5px;" src="https://i.imgur.com/zFN4Hn4.png" />
</a>
<a href="https://twitter.com/toghrulmaharram/status/1520048115323125762" title="https://twitter.com/toghrulmaharram/status/1520048115323125762" targe="_blank">
<img style="width:60%;border:1px solid black;margin:10px;padding:5px;" src="https://i.imgur.com/MVW3o1g.png" />
</a>
[![](https://i.imgur.com/Ic067Ll.png)](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb)
- About Volitions: https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb
## A note on 'Scalable L2 voting' concepts
Scalable L2 voting can be achieved through a zkEVM and without it. What is needed is a way to process votes in L2 and provide a succint proof on L1 that proves that the L2 computation was correct, and this can be achieved with a zkEVM and without it.
- Approach with zkEVM/zkVM
- Approach without zkEVM
- a specific zkRollup solution where the zk-circuit does the vote processing logic
---
Properties that might be interesting to have:
| Property | zkEVM feasability | zkRollup feasability |
|:---------------------------------------------------------------------------------------------- | -------------------------------------------- | -------------------- |
| L2 processing with a succint proof of that computation | Yes | Yes |
| Ability to verify the succint proof of the vote results computation inside a L1 Smart Contract | Not* | Yes |
| Anonymicity of voters | Depends if zkEVM allows Pairing verification | Yes (with recursion) |
| Arbitrary computation | Yes | No |
_*Note: zkEVM has the ability to generate a succint proof that can be verified inside a L1 Smart Contract, but this proof proves that the EVM computation was done correctly. In the case of a voting process what we need is to proof that the votes where processed correctly._
<!-- CSS hacks -->
<style>
hr.in-view{
visibility: hidden;
}
.slides {
font-size:40%;
}
.slides #hide-on-slides {
visibility:hidden;
}
/* CSS hack to add section numbers to titles,
starting from h2.*/
/* Titles numbers */
.markdown-body h1 {counter-reset: h2}
.markdown-body h2 {counter-reset: h3}
.markdown-body h3 {counter-reset: h4}
.markdown-body h4 {counter-reset: h5}
.markdown-body h5 {counter-reset: h6}
.markdown-body h2:before {counter-increment: h2; content: counter(h2) ". "}
.markdown-body h3:before {counter-increment: h3; content: counter(h2) "." counter(h3) ". "}
.markdown-body h4:before {counter-increment: h4; content: counter(h2) "." counter(h3) "." counter(h4) ". "}
.markdown-body h5:before {counter-increment: h5; content: counter(h2) "." counter(h3) "." counter(h4) "." counter(h5) ". "}
.markdown-body h6:before {counter-increment: h6; content: counter(h2) "." counter(h3) "." counter(h4) "." counter(h5) "." counter(h6) ". "}
.markdown-body h2.nocount:before, .markdown-body h3.nocount:before, .markdown-body h4.nocount:before, .markdown-body h5.nocount:before, .markdown-body h6.nocount:before { markdown-body: ""; counter-increment: none }
.markdown-body h1:before, .markdown-body h2:before, .markdown-body h3:before, .markdown-body h4:before, .markdown-body h5:before, .markdown-body h6:before {
color: #737373!important;
}
/* TOC numbers */
.toc ul li ul {
counter-reset: section;
list-style-type: none;
}
.toc ul li ul li::before {
color: #919191!important;
counter-increment: section;
content: counters(section, ".") " ";
}
</style>