0xpolygon / cdk-data-availability Goto Github PK

License: Other

Dockerfile 0.18% Makefile 1.75% Go 97.73% Shell 0.34%

cdk-data-availability's Introduction

CDK Data Availability

Data Availability Layer for CDK Validium

The cdk-data-availability project is a specialized Data Availability Node (DA Node) that is part of Polygon's CDK (Chain Development Kit) Validium.

Overview of Validium

For a full overview of the Polygon CDK Validium, please reference the CDK documentation.

The CDK Validium solution is made up of several components; start with the CDK Validium Node. For quick reference, the complete list of components are outlined below:

Component	Description
CDK Validium Node	Node implementation for the CDK networks in Validium mode
CDK Validium Contracts	Smart contract implementation for the CDK networks in Validium mode
CDK Data Availability	Data availability implementation for the CDK networks
Prover / Executor	zkEVM engine and prover implementation
Bridge Service	Bridge service implementation for CDK networks
Bridge UI	UI for the CDK networks bridge

Introduction

As blockchain networks grow, the volume of data that needs to be stored and validated increases, posing challenges in scalability and efficiency. Storing all data on-chain can lead to bloated blockchains, slow transactions, and high fees.

Data Availability Nodes facilitate a separation between transaction execution and data storage. They allow transaction data to reside off-chain while remaining accessible for validation. This significantly improves scalability and reduces costs. Within the framework of Polygon's CDK, Data Availability Committees (DAC) members run DA nodes to ensure the security, accessibility, and reliability of off-chain data.

To learn more about how the data availability layer works in the validium, please see the CDK documentation here.

Off-Chain Data

The off-chain data is stored in a distributed manner and managed by a data availability committee, ensuring that it is available for validation. The data availability committee is defined as a core smart contract, available here. This is crucial for the Validium model, where data computation happens off-chain but needs to be verifiable on-chain.

Running

Instructions on how to run this software can be found here

Contact

For more discussions, please head to the R&D Discord

License

The cdk-validium-node project is licensed under the GNU Affero General Public License free software license.

cdk-data-availability's People

Contributors

Stargazers

Watchers

Forkers

criadoperez idrishanafi zeeve-app palonimogoldie polygon-guild-of-paris aetheriaxai okx capx-fi firatnear terrorizer1980 kryptonnet crossbell-box tyelerm crustio crustio squiddyswap alt-research ypenghui6 0xyjk 0xabcdefgh variable-chain btc-fi upchainlab yiweichi tusimanetwork touba73 marwoziel febrifelis odomartrindade gstar44 mihaimindrutescu diahpradana aileenpaulahtmm makhialexkixc nurulwahyunikyq luishassanah7 ganjarananggrai almirasusanti4 ekasusantif7ll ghanimarbun teguhsy javato1975 goodnight-dearlamb cooljune phamios sundayyy cimumuy robocups rkpu yummylnw samped renine19 kcaleb496 brainxmozg pinyonet light328 ihcmath hanumsiwaq mikeminer socialsister noboru-chen jacksonrgb krringtonki marcelmarcin dumanoglu1 chiayujan sengulatik66 furidngrt srdrxatk exo9planet yfin99 trghst lastlevelbus wpwhite93 layr-labs zikc2023 johnsoncarl jannytan-svg nnsw3 bensujb wickedgent kanishcancode hawthorne001 mainbaset

cdk-data-availability's Issues

correction fee

olease correction fee in network and run more nodes

need to update the PolygonvalidiumMetaData abi

Problem

We were updating the cdk quickstart using the latest images:

when we were testing, we found L2->L1 bridging failed

Root Cause Analysis

looking into the logs, we found it's due to sequencer cannot get signature from the DAC

then we found in the DA container logs:


zkevm-data-availability  | 	{"pid": 1, "version": "0.0.6"}
zkevm-data-availability  | github.com/0xPolygon/cdk-data-availability/synchronizer.(*BatchSynchronizer).consumeEvents
zkevm-data-availability  | 	/home/runner/work/cdk-data-availability/cdk-data-availability/synchronizer/batches.go:200
zkevm-data-availability  | 2024-03-24T21:19:27.802Z	�[35mDEBUG�[0m	rpc/handler.go:93	Current open connections 1	{"pid": 1, "version": "0.0.6", "method": "datacom_signSequence", "requestId": 1}
zkevm-data-availability  | 2024-03-24T21:19:27.802Z	�[35mDEBUG�[0m	rpc/handler.go:94	request params [{"sequence":["0x0b00000004000000000b00000004000000000b00000004000000000b00000004000000000b0000000400000000"],"signature":"0x1afe896485e57bb5195d04fbcf135c743455f251ac3c994835c18531d36b7a09350a1b63509c08382f570624e3b28e5304d63c417f9452fff8f3210eb661ad951c"}]	{"pid": 1, "version": "0.0.6", "method": "datacom_signSequence", "requestId": 1}
zkevm-data-availability  | 2024-03-24T21:19:27.804Z	�[35mDEBUG�[0m	rpc/handler.go:91	Current open connections 0	{"pid": 1, "version": "0.0.6", "method": "datacom_signSequence", "requestId": 1}
zkevm-data-availability  | 2024-03-24T21:19:27.804Z	�[34mINFO�[0m	rpc/server.go:261	172.24.0.10:43762 - - [24/Mar/2024:21:19:27 +0000] "POST / HTTP/1.1" 200 181 "zkevm-data-availability:8444" "Go-http-client/1.1"	{"pid": 1, "version": "0.0.6"}
zkevm-data-availability  | 2024-03-24T21:19:30.321Z	�[31mERROR�[0m	synchronizer/batches.go:200	failed to handle event: no method with id: 0xdb5b0ed7 
zkevm-data-availability  | /home/runner/work/cdk-data-availability/cdk-data-availability/log/log.go:140 github.com/0xPolygon/cdk-data-availability/log.appendStackTraceMaybeArgs()
zkevm-data-availability  | /home/runner/work/cdk-data-availability/cdk-data-availability/log/log.go:249 github.com/0xPolygon/cdk-data-availability/log.Errorf()
zkevm-data-availability  | /home/runner/work/cdk-data-availability/cdk-data-availability/synchronizer/batches.go:200 github.com/0xPolygon/cdk-data-availability/synchronizer.(*BatchSynchronizer).consumeEvents()

looking into the code, we saw

and the ABI was read from https://github.com/0xPolygon/cdk-data-availability/blob/v0.0.6/etherman/smartcontracts/polygonvalidium/polygonvalidium.go

but this file was lastly updated 2 months ago. and I found that there are indeed some diffs: https://www.diffchecker.com/OLfZGyrR/

w the latest contracts code we used: https://github.com/0xPolygonHermez/zkevm-contracts/tree/v5.0.1-rc.2-fork.8

Suggested Solution

so this is what i belive we should do

update the ABI in that file
rebuild the cdk-data-availability docker image

Db should be moved outside DAC node

We are working on deploying CDKs and having the db as a part of the node would not work in production(maintained dbs are battle-tested).
I haven't seen any activity on this repo in a while, so I could take this up if the team finds it important.

Create abstraction for type `SignedSequenceBanana` and `SignedSequence`

This objects require a function SetSignature.
Also definition of a interface as:

type SignedInterface interface {
	SetSignature([]byte)
	Signer() (common.Address, error)
}

Add docker image pushing to CI

It is recommended to modify the findContractDeploymentBlock function to obtain the block number and call eth.HeaderByNumber.

'r' value overflows uint256 is shown when starting DA program

Then I used Delve to find the error out, and I saw this code thrown the error :

> github.com/0xPolygon/cdk-data-availability/synchronizer.findContractDeploymentBlock() ./synchronizer/init.go:51 (hits goroutine(1):1 total:1) (PC: 0x1143f63)
    46:		eth, err := ethclient.DialContext(ctx, url)
    47:		if err != nil {
    48:			return nil, err
    49:		}
    50:		latestBlock, err := eth.BlockByNumber(ctx, nil)
=>  51:		if err != nil {
    52:			return nil, err
    53:		}
    54:		firstBlock := findCode(ctx, eth, contract, 0, latestBlock.Number().Int64())
    55:		return big.NewInt(firstBlock), nil
    56:	}
(dlv) p err
error(*errors.errorString) *{
	s: "'r' value overflows uint256",}
(dlv) q

I fixed it by change 'eth.BlockByNumber' to 'eth.HeaderByNumber(ctx, nil)'

When I got the error I am using branch 'v0.0.3', but I saw the default branch is still using 'eth.BlockByNumber'