Skip to content

Commit 02bab80

Browse files
kmurphypolygonkmurphypolygon
committed
adding a whole bunch of updates
1 parent d63aea2 commit 02bab80

20 files changed

+150
-94
lines changed

‎docs/cdk/concepts/dac.md‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
A data availability committee (DAC) is an offchain network of nodes that provides data to a blockchain network. The advantages are:
2+
3+
- **Lower transaction fees**: Reduced computational requirements lead to lower fees.
4+
- **State privacy**: A secure copy of state transitions ensures data integrity and privacy.
5+
6+
DACs store the data required to reconstruct the state of the blockchain and make that data accessible so that, if the blockchain goes down, users can still access their assets and data.
7+
8+
Delegating blockchain data to a DAC in this way can be costly. However, a DAC improves finality and thus supports Enterprise use cases which require cheap and fast transactions with a private and secure data layer.
9+
10+
The CDK validium DAC is a secure consortium of nodes that ensures off-chain data access.
11+
12+
## DAC data flow
13+
14+
![CDK validium DAC dataflow](/img/cdk/zksupernets-dac.png)
15+
16+
The DAC works together with the sequencer to control the flow of data. The process can be broken down as follows:
17+
18+
1. **Batch formation**: The sequencer collects user transactions and organizes them into batches.
19+
20+
2. **Batch authentication**: Once the batches are assembled, they are authenticated. The sequencer forwards the batch data and its corresponding hash to the DAC.
21+
22+
3. **Data validation and storage**: The DAC nodes independently validate the batch data. Once validated, the hash is stored in each node's local database for future reference.
23+
24+
4. **Signature generation**: Each DAC node generates a signature for the batch hash. This serves as an endorsement of the batch's integrity and authenticity.
25+
26+
5. **Communication with Ethereum**: The sequencer collects the DAC members' signatures and the original batch hash and submits them to the Ethereum network for verification.
27+
28+
6. **Verification on Ethereum**: A designated smart contract on Ethereum verifies the submitted signatures against a list of valid DAC members and confirms that sufficient approval has been provided for the batch hash.
29+
30+
7. **Final settlement with zero-knowledge proof**: The aggregator prepares a proof for the batch via the prover and submits it to Ethereum. This proof confirms the validity of the batch's transactions without revealing their details. The chain state updates on Ethereum.
31+

‎docs/cdk/dac.md‎

Lines changed: 0 additions & 79 deletions
This file was deleted.

docs/cdk/deploy-validium.md renamed to docs/cdk/get-started/deploy-validium.md

File renamed without changes.

docs/cdk/overview.md renamed to docs/cdk/get-started/overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,4 +10,4 @@ Polygon's Chain Development Kit (CDK) is a software tool for blockchain develope
1010
- [Contracts](https://github.com/0xPolygon/cdk-validium-contracts)
1111
- CDK zkEVM-rollup mode is in development.
1212

13-
![CDK flavors](../img/cdk/cdk-modes.jpg)
13+
![CDK flavors](../../img/cdk/cdk-modes.jpg)

docs/cdk/quickstart.md renamed to docs/cdk/get-started/quickstart.md

File renamed without changes.

‎docs/cdk/specification/performance-benchmarks.md‎

Lines changed: 103 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,103 @@
1-
New doc in progress.
1+
[comment]: <> (data comes from here: https://www.notion.so/polygontechnology/CDK-Validium-TPS-Analysis-8aafda0d6b824c3781270cca30a8f70d#c6725ef8b93748ea8879d7e49e67c2fc and results are marked as OLD.. SME > @ruchawalawalkar)
2+
3+
## Strategy
4+
5+
The team calculated transactions-per-second, `tps`, for three transaction types:
6+
7+
- **EOA to EOA**: Simple value transfers between user accounts.
8+
- **ERC20**: Token transfers, simulating the exchange of tokens on the network.
9+
- **ERC721**: Non-fungible token (NFT) transfers representing the exchange of unique digital assets.
10+
11+
## Environment
12+
13+
The tests ran on the following configurations:
14+
15+
### CDK validium test
16+
17+
| Component (Service) | Instance Type | Instance Count | vCPUs | RAM (GB) | Disk Size (GB) | Disk Type |
18+
| --- | --- | --- | --- | --- | --- | --- |
19+
| Sequencer | n2d-custom-8-16384 | 1 | 8 | 16 | 30 | Balanced persistent disk |
20+
| RPC Node | n2d-custom-8-16384 | 1 | 8 | 16 | 30 | Balanced persistent disk |
21+
| Executor | c2-standard-16 | 1 | 16 | 64 | 100 | SSD persistent disk |
22+
| Aggregator | n2d-custom-8-16384 | 1 | 8 | 16 | 30 | Balanced persistent disk |
23+
| Prover | n2-highmem-128 | 1 | 128 | 864 | 500 | SSD persistent disk |
24+
| Synchronizer | n2d-custom-8-16384 | 1 | 8 | 16 | 30 | Balanced persistent disk |
25+
| SequenceSender | n2d-custom-8-16384 | 1 | 8 | 16 | 30 | Balanced persistent disk |
26+
| ETH TX Manager | n2d-custom-8-16384 | 1 | 8 | 16 | 30 | Balanced persistent disk |
27+
| L2 Gas Pricer | n2d-custom-8-16384 | 1 | 8 | 16 | 30 | Balanced persistent disk |
28+
| HashDB Node | c2-standard-16 | 1 | 16 | 64 | 100 | SSD persistent disk |
29+
| Data Availability | n2d-custom-8-16384 | 4 | 8 | 16 | 30 | Balanced persistent disk |
30+
31+
### Cloud SQL DB
32+
33+
| DB Instance | vCPUs | RAM (GB) | Size (GB) | Count |
34+
| --- | --- | --- | --- | --- |
35+
| zkEVM DB | 16 | 60 | 100 | 1 |
36+
| contains: | State DB | 100 (Shared) | | |
37+
| | Pool DB | 100 (Shared) | | |
38+
| | Prover DB | 100 (Shared) | | |
39+
40+
## Results
41+
42+
### Key
43+
44+
- `mode`: Type of transaction.
45+
- `concurrency`: Number of concurrent requests.
46+
- `requests`: Number of requests over the benchmarking session.
47+
- `rate-limit`: Overall limit to the number of requests per second.
48+
49+
### Results (OLD?)
50+
51+
| `tps` | `mode` | `concurrency` | `requests` | `rate-limit` | `total requests` | `notes` |
52+
| --- | --- | --- | --- | --- | --- | --- |
53+
| 6.269592476 | t (EOA Transactions) | 20 | 100 | 0 (disabled) | 2000 | |
54+
| 12.6984127 | t (EOA Transactions) | 20 | 200 | 0 (disabled) | 4000 | |
55+
| 0 | t (EOA Transactions) | 50 | 500 | 0 (disabled) | 25000 | ERRORED (see note) |
56+
| 17.27115717 | t (EOA Transactions) | 20 | 500 | 0 (disabled) | 10000 | |
57+
| 20.13422819 | t (EOA Transactions) | 30 | 500 | 0 (disabled) | 15000 | |
58+
| 24.8447205 | t (EOA Transactions) | 40 | 500 | 0 (disabled) | 20000 | |
59+
| 20.51983584 | t (EOA Transactions) | 30 | 1000 | 0 (disabled) | 30000 | |
60+
| 18.71804452 | t (EOA Transactions) | 30 | 100000 | 0 (disabled) | 3000000 | |
61+
| 14.82799526 | t (EOA Transactions) | 50 | 1000 | 0 (disabled) | 50000 | |
62+
| 8.650519031 | t (EOA Transactions) | 50 | 100 | 100 | 5000 | |
63+
| 16.20745543 | t (EOA Transactions) | 40 | 500 | 0 (disabled) | 20000 | DUPLICATE OF TEST10 |
64+
| 8.896797153 | t (EOA Transactions) | 20 | 2000 | 0 (disabled) | 40000 | |
65+
| 27.02702703 | t (EOA Transactions) | 10 | 100 | 50 | 1000 | Test ran on n2-standard-8 |
66+
| 29.19708029 | t (EOA Transactions) | 20 | 200 | 50 | 4000 | Test ran on n2-standard-8, with increase AccountQueue and GlobalQueue |
67+
| 36.86635945 | t (EOA Transactions) | 20 | 400 | 50 | 8000 | |
68+
| 29.19708029 | t (EOA Transactions) | 20 | 200 | 0 (disabled) | 4000 | |
69+
| 32.78688525 | t (EOA Transactions) | 50 | 200 | 0 (disabled) | 10000 | |
70+
| 29.19708029 | t (EOA Transactions) | 20 | 200 | 0 (disabled) | 4000 | |
71+
| 17.13062099 | t (EOA Transactions) | 20 | 400 | 50 | 8000 | |
72+
| 14.28571429 | 2 (ERC20 Transactions) | 10 | 100 | 0 (disabled) | 1000 | |
73+
| 18.01801802 | 2 (ERC20 Transactions) | 20 | 200 | 0 (disabled) | 4000 | |
74+
| 13.98601399 | 2 (ERC20 Transactions) | 30 | 200 | 40 | 6000 | |
75+
| 17.66004415 | 2 (ERC20 Transactions) | 20 | 400 | 30 | 8000 | |
76+
| 17.54385965 | 2 (ERC20 Transactions) | 20 | 500 | 30 | 10000 | |
77+
| 17.76198934 | 2 (ERC20 Transactions) | 20 | 500 | 40 | 10000 | |
78+
| 17.51313485 | 2 (ERC20 Transactions) | 20 | 500 | 50 | 10000 | |
79+
| 17.76198934 | 2 (ERC20 Transactions) | 20 | 500 | 100 | 10000 | |
80+
| 0 | 2 (ERC20 Transactions) | 30 | 500 | 100 | 15000 | ERRORED (resource exhausted) |
81+
| 17.36111111 | 2 (ERC20 Transactions) | 20 | 1000 | 0 (disabled) | 20000 | |
82+
| 17.33102253 | 2 (ERC20 Transactions) | 20 | 1500 | 0 (disabled) | 30000 | |
83+
| 18.61330852 | 2 (ERC20 Transactions) | 20 | 2000 | 0 (disabled) | 40000 | |
84+
| 17.24732666 | 2 (ERC20 Transactions) | 20 | 2500 | 0 (disabled) | 50000 | |
85+
| 4.545454545 | 7 (ERC721 Transactions) | 10 | 100 | 0 (disabled) | 1000 | |
86+
| 6.097560976 | 7 (ERC721 Transactions) | 10 | 200 | 0 (disabled) | 2000 | |
87+
| 12.86173633 | 7 (ERC721 Transactions) | 20 | 200 | 0 (disabled) | 4000 | |
88+
| 13.14060447 | 7 (ERC721 Transactions) | 20 | 500 | 0 (disabled) | 10000 | |
89+
| 0 | 7 (ERC721 Transactions) | 30 | 200 | 0 (disabled) | 6000 | ERRORED (resource exhausted) |
90+
| 14.18439716 | 7 (ERC721 Transactions) | 20 | 1000 | 0 (disabled) | 20000 | |
91+
| 12.39669421 | 7 (ERC721 Transactions) | 20 | 1500 | 0 (disabled) | 30000 | |
92+
| 13.81692573 | 7 (ERC721 Transactions) | 20 | 2000 | 0 (disabled) | 40000 | |
93+
| 13.49892009 | 7 (ERC721 Transactions) | 20 | 2500 | 0 (disabled) | 50000 | |
94+
95+
## Conclusions
96+
97+
TODO: summary of data results
98+
99+
## Comparison with competitors
100+
101+
TODO: in progress
102+
103+

‎docs/cdk/specification/validium-vs-zkevm.md‎

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,21 @@
11
## Introduction
22

3-
Polygon CDK running in validium mode inherits the core functionalities of zkEVM rollup mode and adds a [data availability layer](dac.md).
4-
5-
!!! danger
6-
How can we say that validium inherits from zkEVM rollup when zkEVM rollup is unavailable? Do we mean non-CDK zkEVM rollup? We need to say so.
3+
Polygon CDK running in validium mode inherits the core functionalities of a zkEVM rollup node and adds a [data availability layer](../concepts/dac.md).
74

85
## Key differences
96

10-
| | zkEVM | Validium |
7+
| | zkEVM (non-CDK) | Validium |
118
| ------------------------ | ----------------------------------------------------------- | ---------------------------------------------------------------------------------- |
129
| **Node type** | [zkEVM node](https://github.com/0xPolygonHermez/zkevm-node) | [Validium node](https://github.com/0xPolygon/cdk-validium-node): zkEVM node with validium extensions |
1310
| **Data availability** | On-chain | Off-chain via DACs + [DA node](https://github.com/0xPolygon/cdk-data-availability) |
14-
| **Components** | zkEVM components\*\* | zkEVM components\*\* + PostgreSQL database + on-chain committees |
11+
| **Components** | zkEVM components\* | zkEVM components\* + PostgreSQL database + on-chain committees |
1512
| **Contracts** | [zkEVM smart contracts](https://github.com/0xPolygonHermez/zkevm-contracts) <ul><li>`PolygonZkEVM` (main rollup contract)</li> <li> `PolygonZkEVMBridge`</li> <li>`PolygonZkEVMGlobalExitRoot`</li></ul> | [Validium-specific DAC contract](https://github.com/0xPolygon/cdk-validium-contracts) <ul><li>`CDKDataCommittee.sol`</li><li> `CDKValidium.sol` </li></ul> |
1613
| **Infrastructure** | Standard infrastructure | Dedicated infrastructure for data availability layer and DACs |
1714
| **Tx flow** | All transaction data is published on L1 | Validium only publishes the hash of the transaction data. This `Accumulated Input Hash` must be approved by a majority of DAC members. <br/><br/>The sequencer sends both the hash and the transaction data to the DAC for verification. Once approved, the hash plus signatures, is sent to the Consensus L1 contract of the validium protocol. <br/><br/> After verification, the hash and the zk-proof are added to the L1 state.
15+
| **Security** | High security due to on-chain data availability and zero-knowledge proofs. |Off-chain data availability can affect security if DAC members collude to withhold state data. However, security still good due to zero-knowledge proofs. |
16+
| **Gas fees** | High, because all transaction data is stored on Ethereum. | Low, because only the hash of the transaction data is stored on Ethereum. |
17+
| **Proof generation** | Uses Prover to generate proofs of batched transactions for validation. | Uses Prover to generate proofs of batched transactions for validation. |
18+
| **Transaction validation** | Done with smart contracts on Ethereum. | Involves an additional layer where DAC members sign the hash of the transaction data. |
19+
| **Final settlement** | Transaction batches and their corresponding proofs are added to the Ethereum state. | The hash of transaction data and its proof are added to the Ethereum state, referred to as the consolidated state. |
1820

19-
<sub><sup>**</sup>JSON RPC, Pool DB, Sequencer, Etherman, Synchronizer, State DB, Aggregator, Prover</sub>
21+
<sub><sup>*</sup>JSON RPC, Pool DB, Sequencer, Etherman, Synchronizer, State DB, Aggregator, Prover</sub>

docs/cdk/component-repos.md renamed to docs/cdk/troubleshooting/component-repos.md

File renamed without changes.

‎docs/img/cdk/cdk-1.excalidraw.png‎

-2.05 MB
Binary file not shown.

‎docs/img/cdk/cdk-stack.excalidraw.png‎

-70.1 KB
Binary file not shown.

0 commit comments

Comments
 (0)