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

Follow up work on JSON number serialization #1507

Open
1 of 2 tasks
sveitser opened this issue May 28, 2024 · 1 comment · May be fixed by #1534
Open
1 of 2 tasks

Follow up work on JSON number serialization #1507

sveitser opened this issue May 28, 2024 · 1 comment · May be fixed by #1534
Assignees

Comments

@sveitser
Copy link
Collaborator

sveitser commented May 28, 2024

Discussion on zulip.

  • Make it backwards compatible so that we can still de-serialize the old hex strings.
  • Use hex strings for L1 data but decimal strings for hotshot data.
@jbearer
Copy link
Member

jbearer commented May 28, 2024

The first one should be taken care of after #1443 . The second one, I think we need to change L1BlockInfo::number to U256 or change the serialization of the u64

@sveitser sveitser self-assigned this May 31, 2024
sveitser added a commit that referenced this issue May 31, 2024
- Add newtype for L1 block number.
- Implement serialization in backwards compatible manner. Although there
  is currently no test for this backwards compatibility.
- Don't ignore "actual" files created from reference tests.
- Remove "actual" files for successful tests, if they exist.

After implementing this and looking at the JSON file I'm now of the
opinion that we should throw the compatibility with L1 away. It looks
rather messy and I don't see what we really gain from it. I now think we
should just serialize everything in the way we think is best, most
pretty or whatever.

Close #1507
@sveitser sveitser linked a pull request May 31, 2024 that will close this issue
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

Successfully merging a pull request may close this issue.

2 participants