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

L2 -> L1 msgs, sol/cpp/ts #469

Merged
merged 10 commits into from
May 5, 2023
Merged

L2 -> L1 msgs, sol/cpp/ts #469

merged 10 commits into from
May 5, 2023

Conversation

LHerskind
Copy link
Contributor

@LHerskind LHerskind commented May 4, 2023

Description

Fixes #381

  • Add component for calldata hash computation from 4 field elements (useful for testing to compute root calldata etc)
  • Includes L2 -> L1 msgs in calldata hash computation
  • Fixes issues in sol decoder unrelated to L2 -> L1 (improper offsets)
  • Updates TS to use historic tree instead of fresh tree for treeOfHistoricL1ToL2MsgTreeRootsSnapshot
  • Updates KERNEL_NEW_L2_TO_L1_MSGS_LENGTH to 2 to follow same pattern as nullifier and commitments.
  • Add ts tests to generate empty and "mixed" block (mixed including everything) that are useful for the sol setup.

Checklist:

  • I have reviewed my diff in github, line by line.
  • Every change is related to the PR description.
  • I have linked this pull request to the issue(s) that it resolves.
  • There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
  • The branch has been merged or rebased against the head of its merge target.
  • I'm happy for the PR to be merged at the reviewer's next convenience.

@LHerskind LHerskind mentioned this pull request May 4, 2023
6 tasks
@LHerskind LHerskind marked this pull request as ready for review May 4, 2023 23:29
@LHerskind
Copy link
Contributor Author

In #463 @benesjan, is adding proper integration for the sol/ts, would be good to get that in here as well.

Copy link
Contributor

@rahul-kothari rahul-kothari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't have too much knowledge about decoder.sol but everything else looks good barring some comments I left.

std::vector<uint8_t> const calldata_hash_input_bytes_vec(hash_input.begin(), hash_input.end());

auto calldata_hash = sha256::sha256(calldata_hash_input_bytes_vec);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: i know you didn't do this, but can you rename this to expected_calldata_hash

@@ -23,7 +23,7 @@ constexpr size_t KERNEL_NEW_NULLIFIERS_LENGTH = 4;
constexpr size_t KERNEL_NEW_CONTRACTS_LENGTH = 1;
constexpr size_t KERNEL_PRIVATE_CALL_STACK_LENGTH = 8;
constexpr size_t KERNEL_PUBLIC_CALL_STACK_LENGTH = 8;
constexpr size_t KERNEL_NEW_L2_TO_L1_MSGS_LENGTH = 4;
constexpr size_t KERNEL_NEW_L2_TO_L1_MSGS_LENGTH = 2;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different to NEW_L2_TO_L1_MSGS_LENGTH?
Also each tx can now have 2 L2<>L1 messages?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the same manner as KERNEL_NEW_COMMITMENTS_LENGTH etc. One kernel might have multiple inner function calls and such so it can be useful to allow kernels with more than individual calls. However, for now thought that it made sense that the values were the same similar to what it is for the commitments and nullifiers.

* | 0x240 | x | newCommits
* | 0x240 + x | 0x04 | len(newNullifiers) denoted y
* | 0x244 + x | y | newNullifiers
* | 0x244 + a + b | 0x04 | len(newPublicDataWrites) denoted c
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be 'y'?

Copy link
Member

@Maddiaa0 Maddiaa0 May 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you mean on line 52 it should still be x, however; x and y should be renamed to a and b

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch with the naming. Will fix and handle some proper lengths

* | 0x24c + a + b + c + d | 0x04 | len(newContracts) denoted e
* | 0x250 + a + b + c + d | e | newContracts (each element 32 bytes)
* | 0x250 + a + b + c + d + e | e | newContractData (each element 52 bytes)
* | 0x250 + a + b + c + d + e | 0x04 | len(l1ToL2Messages) denoted f
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be 2e no? Since we are adding e twice

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The notation right now is somewhat sloppy as neither a,b,c,d,e,f are byte lengths. Might just fix that entirely and make the width of the table grow.

Copy link
Member

@Maddiaa0 Maddiaa0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good, have some minor comments

@@ -72,6 +73,13 @@ std::array<fr, NUMBER_OF_L1_L2_MESSAGES_PER_ROLLUP> get_empty_l1_to_l2_messages(
return l1_to_l2_messages;
}

void set_kernel_l2_to_l1_msgs(KernelData& kernel_data, std::array<fr, KERNEL_NEW_L2_TO_L1_MSGS_LENGTH> l2_to_l1_msgs)
{
for (size_t i = 0; i < KERNEL_NEW_L2_TO_L1_MSGS_LENGTH; i++) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you not just assign the entire array rather than individually?

kernel_data.public_inputs.end.new_l2_to_l2_msg = l2_to_l1_msgs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably also change for the other setters.

offsets.contractDataOffset = offsets.contractOffset + lengths.contractCount * 0x20;
offsets.l1ToL2MessagesOffset = offsets.contractDataOffset + lengths.contractCount * 0x54;
offsets.l1ToL2MessagesOffset = offsets.contractDataOffset + 0x4 + lengths.contractCount * 0x34;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch

tx.data.end.newContracts = [makeNewContractData(seed + 0x1000)];
return tx;
};
const makeBloatedProcessedTx = async (seed = 0x1) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is repeated in solo_block_builder.test.ts, is there a case for it to be moved to factories?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is makePopulatedProcessedTx a better name than bloated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used bloated as naming here as the txs was full of everything. Think we could remove it from solo block builder tests as the blocks is essentially the same as integration test which is just doing an extra check on top.

const [block] = await builder.buildL2Block(1 + i, txs, l1ToL2Messages);

/*// Useful for sol tests block generation
const encoded = block.encode();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is lingering although its probably convienent to keep

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kept it like this to make it easy for later use. The sol decoder test is there really only for us to more easily extend and test new decoders in foundry.

@rahul-kothari rahul-kothari self-requested a review May 5, 2023 12:02
@LHerskind LHerskind merged commit 88783b9 into master May 5, 2023
@LHerskind LHerskind deleted the lh/l2->l1 branch May 5, 2023 13:02
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 this pull request may close these issues.

Propagate L2 -> L1 messages
3 participants