[General] How does zkSync take advantage of blobs / EIP-4844? #494
-
EnvironmentTestnet Provide a brief description of the functionality you're trying to implement.Looking at this sample transaction we can see that zkSync is taking advantage of the new type 3 transactions introduced by EIP-4844. How is it using blobs to rollup more effectively? As of Feburary, this codebase was audited by openzeppelin, and seems to be in production. What is the specific issue or error you're encountering?see above Can you share the error messages or logs you're receiving, if any?see above Have you made any recent changes to the contract before encountering this issue?see above Are there any external libraries or contracts that your contract interacts with?see above Can you provide the relevant portions of your contract code where the issue is occurring?see above Have you tried to isolate the problem, and if so, what were the results?see above What steps have you already taken to try to resolve the issue?see above Repo Link (Optional)No response Additional DetailsNo response |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Will check on this and see what resources I can find about it to share. |
Beta Was this translation helpful? Give feedback.
-
|
as part of committing a batch we add some information that's referred to under the umbrella term pubdata. pubdata consists of:
basically its all the data needed to reconstruct the state of l2 solely from l1. before 4844, we would submit this data via calldata but that has 2 drawbacks; (1) its pretty expensive to use calldata and (2) there's a limit to how much data we can submit (~125 kb). with blobs, because they are only stored for a finite amount of time, they are much cheaper than using calldata and each blob can hold what we previously could fit in calldata but with a limit of 6 blobs per l1 block (will be moved up to 64 once full danksharding is implemented). if you imagine the cost of committing a batch to be effectively stable then more blobs means more transactions that we can fit into a batch which in turn allows us to spread the cost out more (which is already lower because remember blobs use less gas than calldata) |
Beta Was this translation helpful? Give feedback.
as part of committing a batch we add some information that's referred to under the umbrella term pubdata. pubdata consists of:
basically its all the data needed to reconstruct the state of l2 solely from l1. before 4844, we would submit this data via calldata but that has 2 drawbacks; (1) its pretty expensive to use calldata and (2) there's a limit to how much data we can submit (~125 kb). with blobs, because they are only stored for a finite amount of time, they are much cheaper than using calldata and each blob can hold what we previously could fit in calldata but with a limit of 6 blobs per l1 block (will be moved up to…