Conversation
rootulp
left a comment
There was a problem hiding this comment.
LGTM! Thanks for your hard work on this
| | `TRANSACTION_NAMESPACE_ID` | `NamespaceID` | `0x0000000000000001` | Transactions: requests that modify the state. | | ||
| | `INTERMEDIATE_STATE_ROOT_NAMESPACE_ID` | `NamespaceID` | `0x0000000000000002` | Intermediate state roots, committed after every transaction. | | ||
| | `EVIDENCE_NAMESPACE_ID` | `NamespaceID` | `0x0000000000000003` | Evidence: fraud proofs or other proof of slashable action. | | ||
| | `TAIL_TRANSACTION_PADDING_NAMESPACE_ID` | `NamespaceID` | `0x00000000000000FF` | Tail padding for transactions: padding after all transactions but before messages. | |
There was a problem hiding this comment.
[non-blocking][question] is this tail padding after all reserved namespaces? So after evidence but before messages?
| | `TAIL_TRANSACTION_PADDING_NAMESPACE_ID` | `NamespaceID` | `0x00000000000000FF` | Tail padding for transactions: padding after all transactions but before messages. | | |
| | `TAIL_RESERVED_NAMESPACE_PADDING_NAMESPACE_ID` | `NamespaceID` | `0x00000000000000FF` | Tail padding for reserved namespaces: padding after all reserved namespaces but before messages. | |
evan-forbes
left a comment
There was a problem hiding this comment.
dope, glad these are finding a home.
liamsi
left a comment
There was a problem hiding this comment.
I would ask to add John, Matt, and me to the specs sub-dir as code-owner.
| message WireTxBurn { | ||
| uint64 amount = 1; | ||
| TransactionFee fee = 2; | ||
| uint64 nonce = 3; | ||
| // 32-byte graffiti | ||
| bytes graffiti = 4; | ||
| } |
There was a problem hiding this comment.
This Tx type does not exist. Neither any "graffiti" field.
I am not sure that copying the spec as is without going through the hard work to update it is the best approach but up to you and the core/app team.
| // ANCHOR: StateFraudProof | ||
| // https://github.com/celestiaorg/celestia-specs/blob/master/specs/networking.md#statefraudproof | ||
| message StateFraudProof { |
liamsi
left a comment
There was a problem hiding this comment.
Also sets up a CI workflow that will push the built book to a main directory on the gh-pages branch on each merge to main, allowing a rendered form of the book to be displayed on GitHub pages.
I would recommend to remove this until the specs are somewhat up-to-date again. Otherwise, we will be confusing a bunch of folks visiting the published specs again.
|
Shouldn't the parts about how data is encoded be in Celestia core, not app? We want to have specs be in the repo that they're relevant for, so different specs for core and app. The specs relevant for core and app should be extracted to the relevant repos, so that if for example someone makes a change to the share formatting specs in core, they edit specs in core, not app. However this PR doesn't seem to achieve that. |
|
Also, it seems a large part of the spec is outdated (sparse Merkle trees, graffiti, etc). IMO there's not much advantage to merging the existing outdated specs into the main branch, as people can already reference the existing specs repo. I think there should be a draft PR to do a basic update and clean up of the specs, as well as decoupling the bits for core and app, so that we have a general structure that can be built on, before merging this. |
@musalbas I think there was a miscommunication, where those of us on the call agreed to move the specs over first, and then edit them with individual PRs. this is why Rootul and myself approved so quickly and why John made the PR in the first place. as mentioned, if we don't want to do that, then we can turn this PR into a draft and make the individual PRs on this branch until we're comfortable with merging.
all encoding code is kept in the application now, so I think it makes sense to keep these specs here.
not publishing the specs until they match the implementation makes a lot of sense. We can split this portion into a different PR. |
evan-forbes
left a comment
There was a problem hiding this comment.
we should split the CI publishing mechanism into a different PR #793 (review)
|
Makes sense, would it make sense to merge this into a different branch like |
|
|
Thanks @adlerjohn! gets my 👍 👍 |
Fixes #792 An initial migration of the existing specs as of [`e59efd63a2165866584833e91e1cb8a6ed8c8203`](https://github.com/celestiaorg/celestia-specs/tree/e59efd63a2165866584833e91e1cb8a6ed8c8203). It's expected that there are a few broken links and extra content that has to be pruned, along with incorrect content. The important thing is to not miss anything. Also sets up a CI workflow that will build the book.
Fixes #792
An initial migration of the existing specs as of
e59efd63a2165866584833e91e1cb8a6ed8c8203. It's expected that there are a few broken links and extra content that has to be pruned, along with incorrect content. The important thing is to not miss anything.Also sets up a CI workflow that will build the book.