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

Add doc/ledger-consensus-api.md #668

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

erikd
Copy link
Contributor

@erikd erikd commented Jun 24, 2021

No description provided.

@erikd erikd added the do not merge Test or debug only label Jun 24, 2021
@erikd erikd force-pushed the erikd/ledger-consensus-api branch 3 times, most recently from 37e180e to 500074c Compare June 24, 2021 22:09
@erikd erikd force-pushed the erikd/ledger-consensus-api branch 3 times, most recently from d5cf886 to eb4443f Compare July 14, 2021 08:59
@erikd erikd force-pushed the erikd/ledger-consensus-api branch 2 times, most recently from 20ceba2 to d6ab406 Compare July 20, 2021 00:23

data AnnotatedTx = AnnotatedTx
{ atInputSum :: !Coin -- Sum of the tx inputs
, atOutSum :: !Coin -- Sum of the tx outputs

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

atOutSum isn't needed, it is easily computed from the tx. and if all you really need is the difference with atInputSum to figure out the deposits, we could just supply that instead.

Copy link

@JaredCorduan JaredCorduan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really great, thanks for such a clear write-up! I think this would be straight-forward to implement with foldBlocks from the cardano-client-demo.

@erikd erikd force-pushed the erikd/ledger-consensus-api branch from d6ab406 to cc9e58a Compare July 21, 2021 03:39
}

data AnnotatedTx = AnnotatedTx
{ atInputSum :: !Coin -- Sum of the tx inputs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Computing this at Node may be impossible. The reason is that this requires the current UTxO before a Tx is applied, which won't be available to the Node when we request for a block. This can only be available after db-sync has received the block and applies it, as a ledger event.

Let me explain with an example:
Node tip is at Slot 10000 and db-sync requests block 100. The ledger state at slot 10000 can be used to produce the time metadata for block 100, because the time horizon for time metadata is pretty wide. However it has no way to resolve the inputs for block 100: the UTxO at slot 10000 is useless for this. The UTxO at slot 100 is also not enough, because it is already stale when a first transaction is applied. This can only be done in the general case as ledger events.

Copy link
Contributor Author

@erikd erikd Jul 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My idea was that the ledger would calculate this. It gets the next block from the LocalChainSync protocol, applies it, and then returns a new ledger state, with an annotated block which includes annotations with the data specified in that document..

However it has no way to resolve the inputs for block 100: the UTxO at slot 10000 is useless for this.

Unless the inputs have already been spent, they should still be part of the UTxO set before the block is applied. If they have already been spent at that time, the transaction is not valid anyway.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless the inputs have already been spent, they should still be part of the UTxO set before the block is applied

The TxOut may not exist yet, if it is created by a previous Tx on the same block. So the UTxO state before the block application is not enough in the general case. The only place where the correct UTxO is available is somewhere inside the applyBlock, at the point where a Tx is applied. The only way to make this available is with ledger events, which is, in my mind at least, metadata of a block application.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My idea is all predicated on there being a function like applyBlock but with a type signature:

applyAndAnnotateBlock :: LedgerState -> Block -> (LedgerState, [LedgerEvent])

where one of the constructors of LedgerEvent carries an AnnotatedBlock containing AnnotatedTxs.

Copy link
Contributor

@kderme kderme Jul 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this is exactly what we need eventually. 50% of db-sync code could be removed by a function like this. Unfortunately applyblock is a black box for db-sync which only returns the LedgerState currently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do not merge Test or debug only
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants