-
Notifications
You must be signed in to change notification settings - Fork 234
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
feat(contracts): use constants where possible #1238
Conversation
✅ Deploy Preview for preeminent-bienenstitch-606ad0 canceled.
|
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.
Think we can do some cleanup that also helps a bit on the performance for when there are more kernels etc.
@@ -302,8 +302,15 @@ library Decoder { | |||
|
|||
// Create the leaf to contain commitments (2 * COMMITMENTS_PER_TX * 020) + nullifiers (2 * NULLIFIERS_PER_TX * 0x20) | |||
// + new public data writes (8 * 0x40) + contract deployments (2 * 0x60) + logs hashes (2 * 4 * 0x20) | |||
ArrayLengths memory constantsLengthsPerBase; |
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.
Think the name should be reconsidered, it is a bit odd. The length seems weird when it is not something that changes but might just be me. Also the commitmentCount
and such that you get from the ArrayLengths
just sounds strange to me when like this.
Also, consider if you actually want to store the count, or if we are better of storing the number of bytes instead.
If you look at where it is used, it is mostly needing the number of bytes to jump and such so we can skip some later computation if we had those instead.
If we are storing bytes, we could
// Stack too deep reee
struct MemoryByteConstants {
uint256 commitmentBytesPerKernel;
uint256 nullifierBytesPerKernel;
...
}
Then the baseleaf later is just the sum of those. And we skip a lot of multiplications later in the loop. Can be used for the offsets then as well (around line 440)
vars.baseLeaf = | ||
new bytes(2 * Constants.COMMITMENTS_PER_TX * 0x20 + 2 * Constants.NULLIFIERS_PER_TX * 0x20 + 2 * Constants.PUBLIC_DATA_WRITES_PER_TX * 0x40 + 2 * Constants.CONTRACTS_PER_TX * 0x60 + 2 * 4 * 0x20); | ||
new bytes(constantsLengthsPerBase.commitmentCount * 0x20 + constantsLengthsPerBase.nullifierCount * 0x20 + constantsLengthsPerBase.dataWritesCount * 0x40 + constantsLengthsPerBase.contractCount * 0x60 + 2 * 4 * 0x20); |
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.
Can you add the note on 2 * 4 * 0x20, add to the constants to have the logs accounted for.
assembly { | ||
let baseLeaf := mload(add(vars, 0x40)) // Load the pointer to `vars.baseLeaf` | ||
let dstPtr := add(baseLeaf, 0x20) // Current position withing `baseLeaf` to write to | ||
let leafDataLengthPerBase := mload(constantsLengthsPerBase) |
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.
Think you should rename this as well, it is the memoryConstantPtr
that you are then looping over to progress nicely.
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.
changed it to something much better ahha ;)
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.
This is a great step in the right direction, however i think we can go further. We should be able to remove all of the assembly that isn-t calldatacopys / pointer overloading for most of the assembly blocks below.
I made a branch md/asm-purge
that attempts to start it off
f096059
to
35251f1
Compare
35251f1
to
1d34b6b
Compare
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.
Nits and grits
vars.baseLeaf = | ||
new bytes(2 * Constants.COMMITMENTS_PER_TX * 0x20 + 2 * Constants.NULLIFIERS_PER_TX * 0x20 + 2 * Constants.PUBLIC_DATA_WRITES_PER_TX * 0x40 + 2 * Constants.CONTRACTS_PER_TX * 0x60 + 2 * 4 * 0x20); | ||
new bytes(Constants.COMMITMENTS_NUM_BYTES_PER_BASE + Constants.NULLIFIERS_NUM_BYTES_PER_BASE + Constants.PUBLIC_DATA_WRITES_NUM_BYTES_PER_BASE + Constants.CONTRACTS_NUM_BYTES_PER_BASE + Constants.CONTRACT_DATA_NUM_BYTES_PER_BASE + 2 * 4 * 0x20); |
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.
@@ -20,4 +20,19 @@ library Constants { | |||
uint256 internal constant CONTRACTS_PER_TX = 1; | |||
uint256 internal constant L2_TO_L1_MSGS_PER_TX = 2; | |||
uint256 internal constant L1_TO_L2_MSGS_PER_ROLLUP = 16; | |||
|
|||
// above constants but in bytes |
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.
Would not say that it is really the the above but in bytes, above you have per txs, below you have per base in bytes.
Also, it is not fully consistent if you use BASE_ROLLUP
or just BASE
.
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.
yea I actually just updated the names cos I hated them
uint256 internal constant CONTRACT_DATA_NUM_BYTES_PER_BASE = | ||
TXS_PER_BASE_ROLLUP * CONTRACTS_PER_TX * 0x40; //aztec address + eth address (padded to 0x20) | ||
uint256 internal constant L2_TO_L1_MSGS_NUM_BYTES_PER_BASE = | ||
TXS_PER_BASE_ROLLUP * L2_TO_L1_MSGS_PER_TX * 0x20; |
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.
Remember to include logs so we don't have the "random" values in the decoder for those values.
mstore(dstPtr, mload(add(vars, 0x60))) // `encryptedLogsHashKernel1` starts at 0x60 in `vars` | ||
// encryptedLogsHashKernel1 | ||
dstPtr += 0x14; | ||
bytes32 hash = vars.encrypedLogsHashKernel1; |
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.
If the ordering of encryptedLogsHashKernel1
etc are changed in the ConsumablesVars
you should be able to load in all 4 at once with identity
instead of having to jump through one at a 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.
true, but this is nice and clear for now
dstPtr += 0x20; | ||
hash = vars.unencryptedLogsHashKernel2; | ||
assembly { | ||
mstore(dstPtr, hash) | ||
} | ||
|
||
offsets.commitmentOffset += 2 * Constants.COMMITMENTS_PER_TX * 0x20; |
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.
Why not change the values down here to use constants as well when possible?
@@ -20,4 +20,19 @@ library Constants { | |||
uint256 internal constant CONTRACTS_PER_TX = 1; | |||
uint256 internal constant L2_TO_L1_MSGS_PER_TX = 2; | |||
uint256 internal constant L1_TO_L2_MSGS_PER_ROLLUP = 16; | |||
uint256 internal constant KERNELS_PER_ROLLUP = 2; |
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.
this could also be generated from the cpp script right? lets make a ticket and add it
edit: issue here #1261
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.
Are you talking about BASE_ROLLUPS as ROLLUPS? It gets pretty confusing if you remove that, as now it looks like you are trying to load all bytes in the rollup into a base later on.
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.
@rahul-kothari I don't think you handled this. The ROLLUP
instead of BASE_ROLLUP
or BASE
make me think it is actually a root rollup which it is not.
da71879
to
18b522f
Compare
// + new public data writes (2 * PUBLIC_DATA_WRITES_PER_TX * 0x40) + contract deployments (2 * CONTRACTS_PER_TX * 0x60) + logs hashes (2 * 4 * 0x20) | ||
// contract deployments is 0x60 since 0x20 for contract data root, 0x40 to store the contract's aztec address and eth address (padded to 32 bytes) | ||
// log hash is 4 * 0x20 since each log hash is divided into two field elements. And there are two kinds of logs - enrypted, unencrypted. Hence "4 * 0x20" | ||
|
||
vars.baseLeaf = |
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.
Something looks wrong here. Where are the L2 -> L1? Should sit in between the public and contracts.
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.
Ah, found the issue. The current constant for L2 -> L1 message is 4. So it was included in the 2*4*0x20
... The log hashes num bytes per rollup is 0x40 per tx (2 hashes), and as they are only intermediates, they can be used as 32 bytes even if shown as 2 fields in circuits.
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.
ah shit amazing catch
# Description Fixes #1263
# Description In the latest nightly, noir libs will not compile without a name field in the package.json. This pr adds the name field to allow stuff to compile Please provide a paragraph or two giving a summary of the change, including relevant motivation and context. # Checklist: - [ ] I have reviewed my diff in github, line by line. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) 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.
# Description Fixes #359 and #624. # Checklist: - [ ] I have reviewed my diff in github, line by line. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) 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.
be762e4
to
ab366ed
Compare
Fixes #953 |
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.
LGTM
Description
Unsure about the best name for
constantsPerBase
or theleafDataLengthsPerBase
but these reduce constants, don't increase gas too much (increase of ~400) and are a way to avoid stack too deep errorChecklist: