-
Notifications
You must be signed in to change notification settings - Fork 14
Align specs with base Tendermint and current lazyledger-core impl #160
Conversation
rationale/fees.md
Outdated
@@ -6,6 +6,8 @@ | |||
|
|||
## Preamble | |||
|
|||
**This document will apply to a future version of the LazyLedger protocol.** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What we could do: we could tag the current state of the spec (v0.1.0-idealized
) and remove all things that we plan to add later. That might be clearer than this and we have a tagged version that we can refer to in future discussions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be tagging this repo eventually, but for now we can honestly just delete this file completely (it can always be referenced by commit hash).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(it can always be referenced by commit hash).
Sure, but I feel like adding a tag is easier to find and more explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in fb2d892.
Not really about #139 though right? see:
Or are you saying that there are no changes left that need to be done to core types? I think there still are a few places in ll-core. So the changes I see:
Is there anything else? BTW, 1., 2. were completely uncontroversial changes. I think it's still good to reset them but we should track these somewhere as desired and easy changes before launch. |
It's more that, with this PR, there are no more "big" changes that need to be made (e.g. that require changes to ABCI), or superfluous changes that aren't critical for functionality. The (very few remaining) changes that do need to be made are in the process of being taken care of in the ll-core repo, so #139 is no longer really relevant. Making improvements to the contributing policy is superseded by #158.
There's also
|
| `Amount` | `uint64` | | ||
| `Graffiti` | `byte[MAX_GRAFFITI_BYTES]` | | ||
| [`HashDigest`](#hashdigest) | `byte[32]` | | ||
| `Height` | `int64` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int64
vs uint64
? Idk exactly
If there is no difference, changing the specs to conform impl is easier. Otherwise, I can change the impl, like I did in #315 also if uin64 is in some way better.
Same for Round
uint64 available_data_original_shares_used = 9; | ||
AvailableDataHeader available_data_header = 10; | ||
bytes state_commitment = 7; | ||
uint64 available_data_original_shares_used = 8; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing is that I just changed this value in the impl, but now we change all other unsigned integers leaving this one of its kind and losing consistency. Let's decide once and for all on what type of integers we use and keep the same pattern everywhere changing impl/specs if necessary. In places where there is a specific reason for integer type we can add a commit
/cc @liamsi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of this PR is to describe the current state of the implementation too. I think you are right about the uints (but it is still orthogonal). I would also have left the uints because they are uncontroversial. That's why I've also mentioned above:
BTW, 1., 2. were completely uncontroversial changes. I think it's still good to reset them but we should track these somewhere as desired and easy changes before launch.
Consistency for all integers is not really that important (and not urgent) though. But in general I think we should change to uints. Wer can think about this in another iteration. Let's first have the spec and implementation more aligned first though. More important is fixing #153 and #154.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe then a new issue is needed for integer consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @liamsi, this PR is to align specs with current implementation, not to be ideal. Going forwards, changes in the specs to these types should be accompanied by an implementation or at least an ADR, and changes to the implementation should be accompanied by a change to the specs.
But you're right that eventually we want to use uint
instead of int
s, and everything should be consistent. The implication is that this whole PR will be reverted in due time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implication is that this whole PR will be reverted in due time.
That was no clear for me, ok
Fixes #139. (Explicitly does not address #153 or #154).
Aligns specs with the current data structures (and implied consensus rules) in https://github.com/lazyledger/lazyledger-core.