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

Systematization clarity #271

Open
oetyng opened this issue May 28, 2023 · 0 comments
Open

Systematization clarity #271

oetyng opened this issue May 28, 2023 · 0 comments

Comments

@oetyng
Copy link
Contributor

oetyng commented May 28, 2023

The recent change to tx naming went from src_tx and dst_tx to spent_tx and dbc_creation_tx.

There are a few issues with this.

The most obvious one is that there was a clear duality systematization expressed by using the two opposites of src_ and dst_ as suffixes.
The rationale behind it is that a dbc has a life time flow, where it comes from a src tx, and goes to a dst tx. That is the system design flow that is encapsulated in the naming. It is easy to understand what these two txs in Spend are, in the frame of that life time flow. One is where the dbc came from, the other is where it went.

In comparison to that, there is not the same clear duality or pairing described by spent_ and dbc_creation_ suffixes for a tx.

Morover, we talk of spent dbcs, but not spent txs. A tx is a transaction, the word itself contains the fact that there has been spends, that the transaction irreversibly moves dbcs from one state to another (i.e. to being spent). To call a tx spent is like saying salsa sauce, a sort of pleonasm. However, a tx may be valid or not in the network, which is the existing terminology in SN. Things are valid or not valid in the network.

There are additional issues though, with the specific name change.
The renaming was just making a small incision into the naming system, leaving other parts dangling. There are other places in the code base where src and dst txs are referred to.
Better than to do incomplete changes which just scrambles the whole terminology, is to create a complete systematization and switch atomically between them.


In summary, the change seems to have been haphazardly made with not enough thought put into it, and the suggestion is to go back to previous terminology, and to work on a complete systematization update to get a coherent and logical end result.

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