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

Entropy as a tx #722

Open
4 tasks
ulbqb opened this issue Sep 22, 2023 · 1 comment
Open
4 tasks

Entropy as a tx #722

ulbqb opened this issue Sep 22, 2023 · 1 comment
Labels
C: proposal Classification: Proposal for specification, algorithm, architecture, or communication Stale For github bot

Comments

@ulbqb
Copy link
Member

ulbqb commented Sep 22, 2023

Protocol Change Proposal

Summary

I propose that Entropy is moved from Block to Data.txs. I mean, that Entropy is processed as a transaction. This makes Ostracon block the same as Tendermint and solves the problems due to differences of block interfaces.

Problem Definition

Ostracon Block is different from Tendermint's one. We need forks of scan and explorer projects because of block APIs.

Proposal

I want to remove Entropy from Block and introduce Ostracon transaction (OcTx) like this:

{
  "tx": {
    "@type": "/cosmos.tx.v1beta1.Tx",
    "body": {
      "messages": [
        {
          "@type": "/ostracon.v1.Extend",
          "entropy": {
            "round": 1,
            "proof": "xxxxxxxx"
          }
        }
      ]
    }
  }
}

Proposer who generates VRF proofs add this transaction to proposal blocks. Validators who get proposal blocks validate Entropy in this transaction before DeliverTx.

Consideration

  • This change always requires a special module to ABCI clients (finschia-sdk) if a OcTx is delivered to a ABCI client. This makes dependencies between ABCI server and client strong.
  • If we add a special module, we must guarantee that the number of transactions of this module type is always one in Block. If the module is incorrect, an adversary can do DoS (an adversary can send lots of free transactions because the fee of the module need to be free).
  • This change doesn't require any change for ABCI clients if a OcTx isn't delivered to a ABCI client. But, the protocol that delivers all transactions in Block is broken.

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@ulbqb ulbqb added the C: proposal Classification: Proposal for specification, algorithm, architecture, or communication label Sep 22, 2023
@torao
Copy link
Contributor

torao commented Sep 27, 2023

I think it's a proposal worth considering. It'd be good if it could be opted out through a setting, as it's not incompatibility that is necessarily required for all applications.

@github-actions github-actions bot added the Stale For github bot label Oct 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: proposal Classification: Proposal for specification, algorithm, architecture, or communication Stale For github bot
Projects
None yet
Development

No branches or pull requests

2 participants