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

Proposal for avoiding UTXO race condition. #13

Open
mesudip opened this issue May 25, 2021 · 0 comments
Open

Proposal for avoiding UTXO race condition. #13

mesudip opened this issue May 25, 2021 · 0 comments

Comments

@mesudip
Copy link

mesudip commented May 25, 2021

With current EUTXO model, state machines inherit following properties

  • Utxo containing state variable must be consumed, and new utxo must be created every time even if state doesn't change.
  • Current state of state machine can only be used once per block because utxos can be consumed only once. (Note that it is possible that a person trying to use a state can never use it because of race condition. Some other transaction pops up and consumes the script utxo the person is interested in )

In most of the use cases, it is already clear that there will be states that will be read very frequently but changes are less frequent.

I suggest including a new field witness to ScriptContext.

data TxInfo = TxInfo
{  txInfoWitnesses     :: [TxInInfo] -- ^ Transaction witnesses
  ,txInfoInputs      :: [TxInInfo] -- ^ Transaction inputs
  ,txInfoOutputs     :: [TxOut]    -- ^ Transaction outputs
  ...

Witness are the utxos that we are interested in but don't want to consume. The validation script at which the witness utxo sits will also be run during the transaction. In such utxos, usually we are interested in the datum field. Since witnessUtxos are not consumed, it possible to use the same utxo in multiple transactions in same block or future blocks, unless the utxo is consumed as input.

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

No branches or pull requests

1 participant