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

db extensions #646

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

db extensions #646

wants to merge 4 commits into from

Conversation

adecaro
Copy link
Contributor

@adecaro adecaro commented Jun 2, 2024

This PR introduces a mechanism to extend the TokenDB to store additional information about a token.
For example, when a token's owner field contains an HTLC (service/interop/htlc) script, it would be convenient to store script-related information for more targeted queries and data analysis.

@adecaro adecaro requested a review from arner June 2, 2024 07:43
@adecaro adecaro marked this pull request as draft June 2, 2024 07:43
@adecaro adecaro self-assigned this Jun 2, 2024

func (e *HTLCTokenDBExtension) GetSchema() string {
return fmt.Sprintf(`
-- Tokens
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess Tokens should be 'HTLC' or 'Interop' here. Or wait, do you actually mean the existing 'tokens' table here, or a new one that exists next to the 'tokens' table?

If it's the first, that could become an issue with versioning and updates (our code doesn't handle db migrations yet, but should in the near future and extending an existing table adds another dimension that makes it harder).

}

type HTLCTokenDBExtension struct {
table htlcTokenDBExtensionTables
Copy link
Contributor

Choose a reason for hiding this comment

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

There is a dependency on the 'tables' struct here. We can make our lives much easier by removing the feature of the 'table prefixes' everywhere (which I think we should do anyway!). Then, every db just decides by itself in the code what its tables are called.

idx INT NOT NULL,
sender_raw BYTEA NOT NULL,
recipient_raw BYTEA NOT NULL,
deadline TIMESTAMP NOT NULL,
Copy link
Contributor

Choose a reason for hiding this comment

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

All of these fields are already very nice to have! Now after this, it would be amazing to have the following two fields as well:

  • preimage (easy; after scanning the blockchain it can be just updated in the table)
  • status (trickier; depends on heuristics of whether the deadline is past and the preimage is available...)

I'm not sure how the process of these should work, like when they would be updated and if the 'interop' package already has the right hooks to manage that. But let's consider it in the design; if there is a way, it would help with the transparency and integrity of htlc transactions.

In terms of use cases, I'll share some diagrams and code with you that I used to approach this state on the application level.

logger.Debug(query,
tr.TxID,
tr.Index,
script.Sender,
Copy link
Contributor

Choose a reason for hiding this comment

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

sender and recipient are probably too large to debug?

@adecaro adecaro force-pushed the f-db-ext branch 2 times, most recently from 389d99f to 34995fe Compare July 3, 2024 08:17
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants