KIP-0033: Lightweight Confirmation Layer for Kadena (e.g., DAG or Oth…

kip-0033.md

@@ -0,0 +1,96 @@
+---
+KIP: 0033
+Title: Lightweight Confirmation Layer for Kadena (e.g., DAG or Other Technologies)
+Author: openaccess @openaccessX
+Status: Draft
+Type: Standard
+Category: P2P/Networking / Chainweb (Soft) / Layer
+Created: 2024-11-26
+---
+
+# KIP 0033: Lightweight Confirmation Layer for Kadena (e.g., DAG or Other Technologies)
+
+## Summary
+This proposal introduces a lightweight confirmation layer for Kadena, aimed at improving the scalability, reliability, and performance of multi-chain applications. The layer would enhance data efficiency in Chainweb while preserving its core multi-chain architecture and finality.
+
+A confirmation layer would help Kadena handle high demand, support seamless multi-chain dApps, and improve overall system throughput.
+
+---
+
+## Motivation
+Kadena's multi-chain architecture demands robust solutions to support scalable and reliable decentralized applications (dApps) while improving user experience (UX). A major challenge for multi-chain dApps is managing transaction loads to avoid congested chains, which can reduce throughput and force users to re-sign transactions, leading to inefficiency, frustration, or even user loss.
+
+We propose a lightweight confirmation layer to optimize transaction routing, provide real-time congestion stats, and enable chain flexibility. This solution will ensure pre-signed transactions are processed efficiently, even during periods of heavy congestion, delivering a seamless UX.
+
+Based on our experience building multi-chain dApps, these features are essential for achieving advanced scalability and throughput. They will help projects future-proof against external chain congestion while maintaining high performance and reliability.
+
+---
+
+## Specification
+
+### 1. Enable Transactions to Be Signed Across Multiple Chains (Rather Than Just One)
+Allowing transactions to be signed across multiple chains, rather than being restricted to a single chain, would make dApps more flexible and efficient. This approach helps adapt quickly to changes in congestion on individual chains, ensuring smoother and faster transactions throughout the ecosystem.
+
+**Benefits**:
+- **Select the Best Chain for Each Transaction:** Choose the most suitable chain based on real-time conditions, making better use of available capacity and reducing underutilized chains.
+- **Avoid Congested Chains & Boost Throughput:** Skip chains that are overloaded with transactions, preventing delays and high gas fees. This would improve overall throughput by routing transactions to less congested chains.
+- **Increase Reliability & UX:** Enhance the chances of a transaction being executed successfully by avoiding chains with high congestion. (Assuming constant congestion with high gas fees, this reduces the likelihood of users needing to resign transactions.)
+. **Dev UX:** Simplify the process for developers, providing a slight performance boost by handling chains only when sending transactions, rather than before.
+
+**Requirement**:
+- **Prevent Double Tx Execution**: Ensure that a transaction is executed only once across all chains. This can be achieved by tracking transaction hashes and timestamps.
+- **"Load Balancer API" (see number 2)**
+---
+
+### 2. Reliable & Simple Chain Load API
+Include a reliable API that acts as a load balancer, tracking the total size of all mempool transactions for each chain. This allows the selection of the most suitable chain for each transaction based on current conditions, optimizing performance across multiple chains and enhancing reliability, especially under heavy loads.
+
+Example Response (single or range):
+```json
+[
+  {
+    "chain": 0,
+    "confirmed_mempool_size_kb": 1024, // Always release max blocksize
+    "or confirmed_mempool_gas": 300000, // Always release max blockgas
+    "or full_blocks": 1.5
+  }
+]
+
+```
+**Requirement**:
+- **See Number 1**
+
+**Requirement**:
+- **Pre-Mempool > Confirmation Layer > Confirmed Chainweb Mempool**:  
+Transactions should pass through the confirmation layer before being added to the confirmed mempool, allowing transaction size, gas usage, and other data to be tracked. Fixed-chain transactions could bypass confirmation but must still contribute their size or gas.
+
+---
+
+### Additional Confirmation Layer Features/Improvements
+
+#### 3. Hashing Function to Reduce Data Duplication & Enhance Indexer Support
+Introduce a hashing function within the confirmation layer to reduce data duplication across chains and support indexers. While cross-chain transactions currently enable this, their reliance on intermediaries and additional execution time limits practical use.
+
+**Benefits**:
+- No trust or intermediaries required (allows hash creation and index at target chain directly).
+- Reduced overall blockchain size by avoiding duplicate data.
+- Improved support for dApp indexers, streamlining data retrieval and prevent duplications.
+- Elimination of lengthy and costly cross-chain transactions for Indexer.
+
+**Requirement**:
+- **2-in-1 Transaction Mechanism**:  
+The confirmation layer could implement a mechanism where specific data from a transaction (Tx 1.1) is hashed. This hash, along with the chain information from Tx 1.1, would then be sent in another transaction (Tx 1.2) to a designated chain hosting the indexer contract.
+This would prevent duplication by allowing dApps to query the indexer contract on specific chains to verify whether the data already exists.
+
+**Alternative**:
+- Extended Confirmation Layer > connected to indexing chainweb (1.1 - chain, hash, id) and data chainweb(1.2) - would require a new kip.
+
+---
+
+### Rationale
+This lightweight confirmation layer provides the necessary tools for highly scalable and redundant projects while keeping network load minimal. The proposed enhancements will:
+- Empower developers to create more resilient and efficient dApps.
+- Improve system scalability by reducing bottlenecks and data redundancy.
+- Ensure a seamless and secure user experience.
+
+This specification may require further refinement as feedback is gathered.