Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

openaccess-id
Copy link

…er Technologies)

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.

…er Technologies)

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.
@openaccess-id
Copy link
Author

openaccess-id commented Nov 28, 2024

Note: This does not need to be part of the initial implementation unless desired and a clear path is established. It can be deferred until tools for dApps are developed by the community and/or Kadena LLC based on the new confirmation layer.

Additional Consideration After Proposal Implementation (Brainstorming):

Following the implementation of this proposal, a potential remaining challenge to throughput reliability could be "gas wars," where transactions prioritize inclusion in blocks by offering higher gas prices after confirmation. While this mechanism increases transaction costs, it also poses risks, such as targeted attacks to diminish the functionality of competitors. For example, large companies might view attack costs as justified if the resulting reputational or operational damage to competitors yields financial gains exceeding the attack cost.
(Example for large companies/whales: attack cost = competitor impact + reputational damage; potential gains from a full takedown = increased earnings or stock shorting profits exceeding the attack cost.)

Possible Options/Considerations/Solutions:

- Unify Gas Prices: Eliminate gas-based competition for block inclusion, because the dApps are able to route transactions to less congested chains.
- Dedicated Block Space Priority: Reserve a fixed portion of block space (e.g., 50,000 gas) for small transactions, default coin transfers, and cross-chain references to ensure their timely processing without delays.
- Restrict High-Gas Transactions: Permit only basic coin transfers and cross-chain transactions to offer higher gas prices for priority. Cap their block space usage at a set percentage (e.g., 50%) unless they are first-in-time rather than prioritized by gas price.

Additional Overall Network Structure for Storage Efficiency
Would require a new KIP if seen as desired/feasible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant