Update core data types #17
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Ismail Khoffi <[email protected]>
- define `DataAvailabilityHeader` and add to `Block` - comment about `DataHash` (not true yet) - define `Message` type - add `IntermediateStateRoots` and `Messages` to Data - update comments and add a bunch of TODOs Signed-off-by: Ismail Khoffi <[email protected]>
liamsi
commented
Apr 17, 2020
types/block.go
Outdated
| // | ||
| // TODO: replace with a dedicated type `IntermediateStateRoot` | ||
| // as soon as we settle on the format / sparse Merkle tree etc | ||
| IntermediateStateRoots []tmbytes.HexBytes |
There was a problem hiding this comment.
If you wonder about tmbytes.HexBytes: just think of it as []byte (it's just for encoding really).
|
Note that CI currently doesn't run (tests and everything defined under .circleci). I ran all tests locally. Will add using github actions instead of circleci soon. In the meantime I'd recommend enabling circleci for this org! |
|
closing and reopening to trigger circleci |
adlerjohn
reviewed
Apr 17, 2020
types/block.go
Outdated
Comment on lines
44
to
47
| // RowRoot_j = root((M_{j,1} || M_{j,2} || ... || M_{j,2k} )) | ||
| RowsRoots [][]byte | ||
| // ColumnRoot_j = root((M_{1,j} || M_{2,j} || ... || M_{2k,j} )) | ||
| ColumnRoots [][]byte |
There was a problem hiding this comment.
If there's not a type for hash digests then we should add one. Is there is then []byte can be replaced with it.
There was a problem hiding this comment.
There is none. At least a type alias would be good! Will add in a followup PR!
Co-Authored-By: John Adler <[email protected]>
Signed-off-by: Ismail Khoffi <[email protected]>
…yLedger/lazyledger-core into ismail/align_block_with_spec
adlerjohn
approved these changes
Apr 18, 2020
evan-forbes
pushed a commit
that referenced
this pull request
Sep 17, 2021
* unrelated change: update go.mod file Signed-off-by: Ismail Khoffi <[email protected]> * Add all non-breaking changes to core types (Block, Header) - define `DataAvailabilityHeader` and add to `Block` - comment about `DataHash` (not true yet) - define `Message` type - add `IntermediateStateRoots` and `Messages` to Data - update comments and add a bunch of TODOs Signed-off-by: Ismail Khoffi <[email protected]> * Update types/block.go Co-Authored-By: John Adler <[email protected]> * consistent json annotation Signed-off-by: Ismail Khoffi <[email protected]> Co-authored-by: John Adler <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes: #16
Description
This PR aims to align the current core data types, Block and Header, with what we have in the spec with the constraint that we agreed not to tackle immediate execution immediately (no pun intended). Further, I've limited this to all changes that do not change any other parts besides that (e.g. I did not move evidence over to
Block.Dataas this will make this less contained and more difficult to review). Also I didn't change any hashing hashing logic s.t. none of the current tests break. Both these constraints will be addressed in separate smaller PRs.