From 6a1e77b423d8b15db76c8d3ef2fb1b3e2be50899 Mon Sep 17 00:00:00 2001 From: saiteja Date: Tue, 24 Sep 2024 15:12:35 +0530 Subject: [PATCH 01/12] feat: update docs --- README.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ specs/README.md | 44 -------------------------------------------- 2 files changed, 46 insertions(+), 44 deletions(-) diff --git a/README.md b/README.md index c40283f..6177b6c 100644 --- a/README.md +++ b/README.md @@ -16,3 +16,49 @@ For more detailed information, refer to the `CADA` module specification [here](. To integrate the CADA module into your application, follow the steps outlined in the [integration guide](./integration_docs/README.md) Note: Ensure that the Avail light client URL is correctly configured for the module to function as expected. For instructions on setup Avail locally, please refer to [this documentation](https://github.com/rollkit/avail-da?tab=readme-ov-file#avail-da). + + +# Architecture + +![blocks-data-submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) + + +- At each block interval, a request is sent from the `PreBlocker` ABCI method to the Keeper, specifying the range of block heights that are ready to be posted to the `Avail` DA network. +- The range of block heights should be from `provenHeight + 1` to `min(provenHeight + MaxBlocksLimitForBlob, CurrentBlockHeight)`. + +- If the status of the previous blocks is either `READY` or `FAILURE`, the status can be updated to `PENDING`. + + ``` + range = [fromBlock, toBlock] // (fromBlock < toBlock < CurrentBlock) + status = PENDING + ``` + +- The `Proposer` of the block will make a request to the `Relayer` to post the blocks data by passing the range of blocks to be posted. + +- The `Relayer` fetches the blocks data from the local provider, converts the blocks data to bytes, and posts that data to `Avail`. + +- Once the success of data availability is confirmed, the `Relayer` broadcasts the `Avail height` at which the blob data is made available using the `MsgUpdateBlobStatus` transaction. + +- The status, Avail height, and voting deadline will be updated in the state. + + ``` + status = IN_VOTING + availHeight = tx.availHeight + votingEndBlock = currentBlock + votingInterval + ``` + +![vote-extension](https://github.com/user-attachments/assets/c0edb8e7-20fd-468a-9109-4f31718e4467) + +- At block height `VotingEndBlock - 1`, all the validators verify if the specified blocks data is truly made available at the specified Avail height. They cast their vote (YES or NO) using `vote extensions`. + +- At block height `VotingEndBlock`, all the votes from `vote_extensions` will be collected and aggregated. If the collective `voting power is > 66%`, the status will be updated + + ``` + status = READY // success and ready for next blocks + provenHeight = Range End + + ``` +- In case of failure at any stage, the whole flow will be repeated. + +--- + diff --git a/specs/README.md b/specs/README.md index c7a66b2..cf72f99 100644 --- a/specs/README.md +++ b/specs/README.md @@ -18,47 +18,3 @@ This document specifies the cada module of the Cosmos SDK. CADA is a module designed to connect Cosmos sovereign chains with the Avail network, making it easier for any Cosmos chain or rollapp to use Avail as their Data Availability (DA) layer. With CADA, developers can improve the scalability and security of their decentralized applications within the Cosmos ecosystem. It enables better data handling and availability, allowing Cosmos-based chains to tap into the strengths of Avail and build a more connected and resilient blockchain network. - -## Architecture - -![blocks-data-submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) - - -- At each block interval, a request is sent from the `PreBlocker` ABCI method to the Keeper, specifying the range of block heights that are ready to be posted to the `Avail` DA network. -- The range of block heights should be from `provenHeight + 1` to `min(provenHeight + MaxBlocksLimitForBlob, CurrentBlockHeight)`. - -- If the status of the previous blocks is either `READY` or `FAILURE`, the status can be updated to `PENDING`. - - ``` - range = [fromBlock, toBlock] // (fromBlock < toBlock < CurrentBlock) - status = PENDING - ``` - -- The `Proposer` of the block will make a request to the `Relayer` to post the blocks data by passing the range of blocks to be posted. - -- The `Relayer` fetches the blocks data from the local provider, converts the blocks data to bytes, and posts that data to `Avail`. - -- Once the success of data availability is confirmed, the `Relayer` broadcasts the `Avail height` at which the blob data is made available using the `MsgUpdateBlobStatus` transaction. - -- The status, Avail height, and voting deadline will be updated in the state. - - ``` - status = IN_VOTING - availHeight = tx.availHeight - votingEndBlock = currentBlock + votingInterval - ``` - -![vote-extension](https://github.com/user-attachments/assets/c0edb8e7-20fd-468a-9109-4f31718e4467) - -- At block height `VotingEndBlock - 1`, all the validators verify if the specified blocks data is truly made available at the specified Avail height. They cast their vote (YES or NO) using `vote extensions`. - -- At block height `VotingEndBlock`, all the votes from `vote_extensions` will be collected and aggregated. If the collective `voting power is > 66%`, the status will be updated - - ``` - status = READY // success and ready for next blocks - provenHeight = Range End - - ``` -- In case of failure at any stage, the whole flow will be repeated. - ---- From b7c3dfbf61b7be75a254b66045d941d6e8307e61 Mon Sep 17 00:00:00 2001 From: saiteja Date: Tue, 24 Sep 2024 16:59:39 +0530 Subject: [PATCH 02/12] docs: update --- README.md | 45 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 34 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 6177b6c..19d9afe 100644 --- a/README.md +++ b/README.md @@ -2,25 +2,48 @@ CADA is a module designed to connect Cosmos sovereign chains with the Avail network, making it easier for any Cosmos chain or rollapp to use Avail as their Data Availability (DA) layer. With CADA, developers can improve the scalability and security of their decentralized applications within the Cosmos ecosystem. It enables better data handling and availability, allowing Cosmos-based chains to tap into the strengths of Avail and build a more connected and resilient blockchain network. +# Integration Guide + +To integrate the CADA module into your application, follow the steps outlined in the [integration guide](./integration_docs/README.md) + +Note: Ensure that the Avail light client URL is correctly configured for the module to function as expected. For instructions on setup Avail locally, please refer to [this documentation](https://github.com/rollkit/avail-da?tab=readme-ov-file#avail-da). + # How It Works -For example: -Let blobInterval = 10, -- At height `11`, blocks from `1` to `10` are posted. -- At height `21`, blocks from `11` to `20` are posted. +There are four main components in the workflow: -For more detailed information, refer to the `CADA` module specification [here](./specs/README.md). +## 1. Cosmos Chain +The core logic of **Cada** is implemented and executed on the Cosmos chain. -# Integration Guide +In the Cada module: +- At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights ready to be posted to the **Avail** Data Availability (DA) network. +- The chain is responsible for aggregating vote extensions from all validators and verifying whether the data has been made available on Avail. +- Since verification requires communicating with the light client, an asynchronous voting mechanism is needed. **Vote extensions** enable this asynchronous voting mechanism for verification purposes. -To integrate the CADA module into your application, follow the steps outlined in the [integration guide](./integration_docs/README.md) +![Vote Extension](https://github.com/user-attachments/assets/c0edb8e7-20fd-468a-9109-4f31718e4467) -Note: Ensure that the Avail light client URL is correctly configured for the module to function as expected. For instructions on setup Avail locally, please refer to [this documentation](https://github.com/rollkit/avail-da?tab=readme-ov-file#avail-da). +## 2. Relayer +The **Relayer** facilitates communication between the Cosmos Chain, the Avail light client, and the Cosmos Provider. +- **Data Submission**: The relayer is responsible for fetching block data from the local provider and posting it to the Avail light client via an HTTP request. +- Based on the response from the light client, the relayer submits a transaction informing the validators of the data availability status and the specific Avail block height where the data is included, so that validators can verify it. + +- **Data Verification**: During verification, the relayer communicates with the Avail light client to confirm whether the data is truly available at the specified height. -# Architecture +![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) + +## 3. Avail Light Node +The **Avail Light Client** allows interaction with the Avail DA network without requiring a full node, and without having to trust remote peers. It leverages **Data Availability Sampling (DAS)**, which the light client performs on every newly created block. + +- The chain communicates with the Avail light client via the relayer during the data availability verification process. + +Find more details about the Avail Light Client [here](https://docs.availproject.org/docs/operate-a-node/run-a-light-client/Overview). -![blocks-data-submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) +## 4. Cosmos Provider +The **Cosmos Provider** is responsible for fetching block data via RPC so that the data can be posted to Avail for availability checks. + + +# Architecture - At each block interval, a request is sent from the `PreBlocker` ABCI method to the Keeper, specifying the range of block heights that are ready to be posted to the `Avail` DA network. @@ -47,7 +70,7 @@ Note: Ensure that the Avail light client URL is correctly configured for the mod votingEndBlock = currentBlock + votingInterval ``` -![vote-extension](https://github.com/user-attachments/assets/c0edb8e7-20fd-468a-9109-4f31718e4467) + - At block height `VotingEndBlock - 1`, all the validators verify if the specified blocks data is truly made available at the specified Avail height. They cast their vote (YES or NO) using `vote extensions`. From 7ac47522516686615b37173f8e961e459c7b2a95 Mon Sep 17 00:00:00 2001 From: saiteja Date: Tue, 24 Sep 2024 17:03:04 +0530 Subject: [PATCH 03/12] docs: update docs --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 19d9afe..8ba0cb1 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,7 @@ The core logic of **Cada** is implemented and executed on the Cosmos chain. In the Cada module: - At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights ready to be posted to the **Avail** Data Availability (DA) network. +![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) - The chain is responsible for aggregating vote extensions from all validators and verifying whether the data has been made available on Avail. - Since verification requires communicating with the light client, an asynchronous voting mechanism is needed. **Vote extensions** enable this asynchronous voting mechanism for verification purposes. @@ -30,12 +31,12 @@ The **Relayer** facilitates communication between the Cosmos Chain, the Avail li - **Data Verification**: During verification, the relayer communicates with the Avail light client to confirm whether the data is truly available at the specified height. -![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) + ## 3. Avail Light Node The **Avail Light Client** allows interaction with the Avail DA network without requiring a full node, and without having to trust remote peers. It leverages **Data Availability Sampling (DAS)**, which the light client performs on every newly created block. -- The chain communicates with the Avail light client via the relayer during the data availability verification process. +- The chain communicates with the Avail light client via the relayer during the data submission and data availability verification processes. Find more details about the Avail Light Client [here](https://docs.availproject.org/docs/operate-a-node/run-a-light-client/Overview). From 9bce0bf6c6dfb38f62d0025eb22939c10f8a1031 Mon Sep 17 00:00:00 2001 From: saiteja Date: Tue, 24 Sep 2024 17:36:19 +0530 Subject: [PATCH 04/12] docs: update --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 8ba0cb1..4541648 100644 --- a/README.md +++ b/README.md @@ -26,7 +26,7 @@ In the Cada module: ## 2. Relayer The **Relayer** facilitates communication between the Cosmos Chain, the Avail light client, and the Cosmos Provider. -- **Data Submission**: The relayer is responsible for fetching block data from the local provider and posting it to the Avail light client via an HTTP request. +- **Data Submission**: The relayer is responsible for fetching block data from the cosmos provider and posting it to the Avail light client via an HTTP request. - Based on the response from the light client, the relayer submits a transaction informing the validators of the data availability status and the specific Avail block height where the data is included, so that validators can verify it. - **Data Verification**: During verification, the relayer communicates with the Avail light client to confirm whether the data is truly available at the specified height. From 19fc0b49b74343f2bcad26d4fd4b73c81daccee3 Mon Sep 17 00:00:00 2001 From: saiteja Date: Tue, 24 Sep 2024 17:36:44 +0530 Subject: [PATCH 05/12] docs: update --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4541648..9a248d7 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ Note: Ensure that the Avail light client URL is correctly configured for the mod # How It Works -There are four main components in the workflow: +There are main components in the workflow: ## 1. Cosmos Chain The core logic of **Cada** is implemented and executed on the Cosmos chain. From 1e51cfe0de87ef7cd8a876b25bcd4af99f7d5105 Mon Sep 17 00:00:00 2001 From: saiteja Date: Wed, 25 Sep 2024 10:42:05 +0530 Subject: [PATCH 06/12] docs: update --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9a248d7..b91a812 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ Note: Ensure that the Avail light client URL is correctly configured for the mod There are main components in the workflow: -## 1. Cosmos Chain +## 1. Cada The core logic of **Cada** is implemented and executed on the Cosmos chain. In the Cada module: From e324c43a4483811fa9446c5e488c93e3b88db4fa Mon Sep 17 00:00:00 2001 From: Teja2045 <106052623+Teja2045@users.noreply.github.com> Date: Wed, 25 Sep 2024 11:12:43 +0530 Subject: [PATCH 07/12] Update README.md Co-authored-by: Naga Tulasi Gandham <40757909+NagaTulasi@users.noreply.github.com> --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index b91a812..3b3bb67 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ There are main components in the workflow: The core logic of **Cada** is implemented and executed on the Cosmos chain. In the Cada module: -- At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights ready to be posted to the **Avail** Data Availability (DA) network. +- At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights that are ready to be posted to the **Avail** Data Availability (DA) network. ![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) - The chain is responsible for aggregating vote extensions from all validators and verifying whether the data has been made available on Avail. - Since verification requires communicating with the light client, an asynchronous voting mechanism is needed. **Vote extensions** enable this asynchronous voting mechanism for verification purposes. From 57bfc0d7b931a4caed9e348b96a5d9ca063d02bb Mon Sep 17 00:00:00 2001 From: saiteja Date: Wed, 25 Sep 2024 12:16:02 +0530 Subject: [PATCH 08/12] docs: update docs --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3b3bb67..ffa6fc7 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ Note: Ensure that the Avail light client URL is correctly configured for the mod There are main components in the workflow: ## 1. Cada -The core logic of **Cada** is implemented and executed on the Cosmos chain. +The core functionality of the **Cada** module is integrated with and operates on the Cosmos blockchain. In the Cada module: - At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights that are ready to be posted to the **Avail** Data Availability (DA) network. From 92b4c32131374e772833440f4e7eef4083504b56 Mon Sep 17 00:00:00 2001 From: Deepak Gudla <44751447+deepakgudla@users.noreply.github.com> Date: Thu, 26 Sep 2024 11:31:28 +0530 Subject: [PATCH 09/12] docs-update --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index ffa6fc7..3639f6f 100644 --- a/README.md +++ b/README.md @@ -17,11 +17,13 @@ The core functionality of the **Cada** module is integrated with and operates on In the Cada module: - At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights that are ready to be posted to the **Avail** Data Availability (DA) network. -![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) +![Data Submission](https://github.com/user-attachments/assets/d5a990e2-f0b0-431e-b618-f6ed38b6b2ad) + - The chain is responsible for aggregating vote extensions from all validators and verifying whether the data has been made available on Avail. - Since verification requires communicating with the light client, an asynchronous voting mechanism is needed. **Vote extensions** enable this asynchronous voting mechanism for verification purposes. -![Vote Extension](https://github.com/user-attachments/assets/c0edb8e7-20fd-468a-9109-4f31718e4467) +![Vote Extension](https://github.com/user-attachments/assets/b39babbb-8947-49db-b387-77835453c99e) + ## 2. Relayer The **Relayer** facilitates communication between the Cosmos Chain, the Avail light client, and the Cosmos Provider. From 8cec6a6256d425fac0b6420990f4e6f3110807c1 Mon Sep 17 00:00:00 2001 From: deepakgudla Date: Thu, 26 Sep 2024 11:40:06 +0530 Subject: [PATCH 10/12] Revert "docs-update" This reverts commit 92b4c32131374e772833440f4e7eef4083504b56. --- README.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 3639f6f..ffa6fc7 100644 --- a/README.md +++ b/README.md @@ -17,13 +17,11 @@ The core functionality of the **Cada** module is integrated with and operates on In the Cada module: - At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights that are ready to be posted to the **Avail** Data Availability (DA) network. -![Data Submission](https://github.com/user-attachments/assets/d5a990e2-f0b0-431e-b618-f6ed38b6b2ad) - +![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) - The chain is responsible for aggregating vote extensions from all validators and verifying whether the data has been made available on Avail. - Since verification requires communicating with the light client, an asynchronous voting mechanism is needed. **Vote extensions** enable this asynchronous voting mechanism for verification purposes. -![Vote Extension](https://github.com/user-attachments/assets/b39babbb-8947-49db-b387-77835453c99e) - +![Vote Extension](https://github.com/user-attachments/assets/c0edb8e7-20fd-468a-9109-4f31718e4467) ## 2. Relayer The **Relayer** facilitates communication between the Cosmos Chain, the Avail light client, and the Cosmos Provider. From 072e09d76b6fa1be52baf911c997226fb5dbeea6 Mon Sep 17 00:00:00 2001 From: Deepak Gudla <44751447+deepakgudla@users.noreply.github.com> Date: Thu, 26 Sep 2024 14:52:10 +0530 Subject: [PATCH 11/12] docs: docs update (#57) * docs update * docs update * Update README.md * Update README.md * Update README.md * Update README.md --- README.md | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index ffa6fc7..5495b78 100644 --- a/README.md +++ b/README.md @@ -10,18 +10,34 @@ Note: Ensure that the Avail light client URL is correctly configured for the mod # How It Works -There are main components in the workflow: +CADA(Cosmos Chain): Initiates the process by running the PreBlocker ABCI method. -## 1. Cada -The core functionality of the **Cada** module is integrated with and operates on the Cosmos blockchain. +Request to Relayer: Sends block range information to the relayer. -In the Cada module: +Relayer: Fetches the block data from the Cosmos Provider and posts it to the Avail Light Client. + +Avail Light Client: Confirms whether the data is available. + +If Yes: Broadcast the Avail height and status. + +If No: Retry data submission. + +Validators: Vote to confirm the data availability, updating the blob status to "Success" or "Failure" based on results. + + +These are main components in the workflow: + +## 1. CADA +The core functionality of the **CADA** module is integrated with and operates on the Cosmos blockchain. + +In the CADA module: - At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights that are ready to be posted to the **Avail** Data Availability (DA) network. -![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c) +![Data Submission](https://github.com/user-attachments/assets/fc4d23cc-f6bd-4210-8407-47a57adcc290) + - The chain is responsible for aggregating vote extensions from all validators and verifying whether the data has been made available on Avail. - Since verification requires communicating with the light client, an asynchronous voting mechanism is needed. **Vote extensions** enable this asynchronous voting mechanism for verification purposes. -![Vote Extension](https://github.com/user-attachments/assets/c0edb8e7-20fd-468a-9109-4f31718e4467) +![Vote Extension](https://github.com/user-attachments/assets/ea5b10ab-fb64-4ed0-8761-44675a852a01) ## 2. Relayer The **Relayer** facilitates communication between the Cosmos Chain, the Avail light client, and the Cosmos Provider. @@ -44,7 +60,7 @@ Find more details about the Avail Light Client [here](https://docs.availproject. The **Cosmos Provider** is responsible for fetching block data via RPC so that the data can be posted to Avail for availability checks. -# Architecture +# Workflow - At each block interval, a request is sent from the `PreBlocker` ABCI method to the Keeper, specifying the range of block heights that are ready to be posted to the `Avail` DA network. From 1a426d99470967c5170d5c3346c9f35753dd9143 Mon Sep 17 00:00:00 2001 From: Teja2045 <106052623+Teja2045@users.noreply.github.com> Date: Thu, 26 Sep 2024 16:12:22 +0530 Subject: [PATCH 12/12] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 5495b78..d40ae6a 100644 --- a/README.md +++ b/README.md @@ -42,7 +42,7 @@ In the CADA module: ## 2. Relayer The **Relayer** facilitates communication between the Cosmos Chain, the Avail light client, and the Cosmos Provider. -- **Data Submission**: The relayer is responsible for fetching block data from the cosmos provider and posting it to the Avail light client via an HTTP request. +- **Data Submission**: The relayer is responsible for fetching block data from the Cosmos provider and posting it to the Avail light client via an HTTP request. - Based on the response from the light client, the relayer submits a transaction informing the validators of the data availability status and the specific Avail block height where the data is included, so that validators can verify it. - **Data Verification**: During verification, the relayer communicates with the Avail light client to confirm whether the data is truly available at the specified height.