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.

Sign up for GitHub

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

Jump to bottom

feat: add timestamp asserter contract #843

Merged
merged 7 commits into from
Oct 31, 2024
Merged

feat: add timestamp asserter contract #843

merged 7 commits into from
Oct 31, 2024

Conversation

ischasny
Copy link
Contributor

@ischasny ischasny commented Oct 8, 2024

  • add TimestampAsserter contract that allows to assert block.timestamp value from AA;
  • modified deployment scripts to deploy it alongside other L2 contracts like Multicall3;

@ischasny ischasny marked this pull request as ready for review October 8, 2024 15:49
@ischasny ischasny changed the base branch from main to release-v25-protocol-defense October 16, 2024 10:02
@ischasny ischasny force-pushed the ivan/add-time-window-asserter branch from c88da6d to 1f4018f Compare October 16, 2024 10:07
@ischasny ischasny mentioned this pull request Oct 18, 2024
Merged
@ischasny ischasny force-pushed the ivan/add-time-window-asserter branch from b40b2d5 to 72a3e8e Compare October 29, 2024 17:21
@ischasny ischasny changed the title [DRAFT] add timestamp asserter contract feat: add timestamp asserter contract Oct 31, 2024
ischasny and others added 2 commits October 31, 2024 10:43
@ischasny @vladbochok
Update l2-contracts/contracts/dev-contracts/TimestampAsserter.sol
698f6ae 
Co-authored-by: Vlad Bochok <41153528+vladbochok@users.noreply.github.com>
@ischasny
add new lines
50a0db7
@github-actions GitHub Actions
Copy link

Coverage after merging ivan/add-time-window-asserter into release-v25-protocol-defense will be

86.48%

Coverage Report
FileStmtsBranchesFuncsLinesUncovered Lines
contracts/bridge
   L1ERC20Bridge.sol81.82%80%75%83.87%62, 70, 70–71, 73–74
   L1SharedBridge.sol79.59%66.23%84.21%83.41%101–102, 109–110, 117–118, 125, 125–126, 133, 177, 190–191, 199–200, 212–213, 215–216, 227, 227, 227–231, 231–232, 234, 239–241, 241–242, 244–246, 246–247, 249, 261, 270, 270–271, 279–280, 290, 444–445, 447–448, 579–580, 596–597, 607–608, 623–624, 720–721, 962, 967
contracts/bridgehub
   Bridgehub.sol89.29%74.07%100%91.49%100–101, 112–113, 132–133, 155–156, 158–159, 332–333, 49, 63–64
contracts/common
   ReentrancyGuard.sol90%66.67%100%92.86%78–79
contracts/common/libraries
   L2ContractHelper.sol42.86%0%50%52.63%25–26, 31–32, 35–36, 50, 52, 52–53, 57, 57–58, 66
   SemVer.sol100%100%100%100%
   UncheckedMath.sol100%100%100%100%
   UnsafeBytes.sol100%100%100%100%
contracts/governance
   ChainAdmin.sol0%0%0%0%27, 27–28, 30, 32–33, 39–40, 47–48, 56, 56–57, 60, 62–63, 63, 66, 69, 78, 78–79, 81
   Governance.sol91.67%94.74%95%89.86%44, 44–45, 48, 50–51, 53–54
contracts/state-transition
   StateTransitionManager.sol59.48%35.71%50%65.42%101, 106–110, 116, 149–150, 152–153, 155–156, 158–159, 201, 203–204, 209, 211, 211–212, 215–217, 219–220, 255, 275, 289, 294, 299, 304, 309, 314, 319, 386, 386–387, 390, 455–456, 79, 92, 92–93
   TestnetVerifier.sol44.44%33.33%50%50%16, 16, 16, 32
   ValidatorTimelock.sol95.89%83.33%100%95.83%241, 82–83
   Verifier.sol89.88%35.71%96.30%90.93%1673–1674, 287–302, 305–308, 311–318, 321–328, 331–332, 335–336, 339, 384–385, 395–396, 406–407, 417–418, 428–429, 444–445, 454, 454–455, 904–905
contracts/state-transition/chain-deps
   DiamondInit.sol77.55%45.45%100%86.11%34–35, 37–38, 40–41, 43–44, 46–47, 71
   DiamondProxy.sol92.31%75%100%100%16, 27
contracts/state-transition/chain-deps/facets
   Admin.sol86.21%72.73%92.31%87.30%109, 109–110, 112–113, 178, 180, 83–84, 94–95
   Executor.sol82.04%63.41%84.38%87.90%137–138, 192, 197, 202, 207, 212, 217, 222, 227, 230–231, 235–236, 240–242, 244–245, 260–261, 280, 294–295, 361–362, 425, 447–449, 469, 48, 48–49, 519–520, 528–529, 549, 556–557, 57, 59, 59–60, 619, 62, 620, 63, 646–647, 696–697, 70, 700–701, 71, 74–75, 775
   Getters.sol92.08%100%90.24%93.10%153, 206, 72, 77
   Mailbox.sol100%100%100%100%
   ZkSyncHyperchainBase.sol92.86%85.71%100%92.86%55–56
contracts/state-transition/libraries
   Diamond.sol93.33%80.77%100%95.96%109–110, 113, 115, 117, 120, 198–199, 316
   LibMap.sol100%100%100%100%
   Merkle.sol100%100%100%100%
   PriorityQueue.sol100%100%100%100%
   TransactionValidator.sol94.44%88.24%100%96%66–67, 69–70
contracts/upgrades
   BaseZkSyncUpgrade.sol58.20%27.27%100%60.23%104, 104–105, 108, 111, 114–115, 126, 126–127, 130, 133, 136–137, 151–153, 171–173, 212–213, 215, 215–216, 232–233, 249–250, 252–253, 258–259, 259–260, 271–272, 278–279, 285–286, 293–294, 298–299, 308–309, 311–312, 75–76
   BaseZkSyncUpgradeGenesis.sol56.67%14.29%100%68.18%25, 25–26, 33–34, 40–41, 52–53, 62–63, 65–66
   DefaultUpgrade.sol100%100%100%100%
   GenesisUpgrade.sol100%100%100%100%
contracts/vendor
   AddressAliasHelper.sol100%100%100%100%

@ischasny ischasny merged commit 9fb1264 into release-v25-protocol-defense Oct 31, 2024
19 checks passed
@ischasny ischasny deleted the ivan/add-time-window-asserter branch October 31, 2024 12:02
github-merge-queue bot pushed a commit to matter-labs/zksync-era that referenced this pull request Nov 1, 2024
@ischasny @Deniallugo
feat: add block.timestamp asserter for AA (#3031)
442efb7 
This PR adds the ability to use `block.timestamp` in custom AA
contracts. AAs will still not have direct access to `block.timestamp`,
but can utilize it via a proxy that enforces certain constraints. The PR
introduces a `TimestampAsserter` contract that is deployed on every
chain to the user space, similar to `Multicall3`. This contract has a
single function, `assertTimestampInRange(start, end)`, which can be used
by AAs at their discretion.

The `TimestampAsserter` contract ensures that `block.timestamp` falls
within the specified `(start, end)` range. Additionally, the sequencer
verifies that the `block.timestamp` is sufficiently far from the range’s
end. This is to prevent DoS attacks where transactions pass validation
but get stuck in the mempool during execution. This constraint is
configurable and can be adjusted without requiring protocol update.

The PR also introduces two new fields to the `transactions` table:
`timestamp_asserter_range_start` and `timestamp_asserter_range_end`.
These fields are extracted during transaction execution in the sandbox
by the `ValidationTracer`. If multiple assertions are made in a single
transaction, the system captures the maximum of the starts and the
minimum of the ends, resulting in the narrowest possible time range.

Transactions with time range constraints will undergo additional
verification before being included in a block. If the current time falls
outside the transaction’s specified time range, the transaction will be
rejected with an appropriate message.

Sister PR in `era-contracts`:
matter-labs/era-contracts#843

---------

Signed-off-by: Danil <deniallugo@gmail.com>
Co-authored-by: Danil <deniallugo@gmail.com>
github-merge-queue bot pushed a commit to matter-labs/zksync-era that referenced this pull request Nov 1, 2024
@ischasny @Deniallugo
feat: add block.timestamp asserter for AA (#3031)
069d38d 
This PR adds the ability to use `block.timestamp` in custom AA
contracts. AAs will still not have direct access to `block.timestamp`,
but can utilize it via a proxy that enforces certain constraints. The PR
introduces a `TimestampAsserter` contract that is deployed on every
chain to the user space, similar to `Multicall3`. This contract has a
single function, `assertTimestampInRange(start, end)`, which can be used
by AAs at their discretion.

The `TimestampAsserter` contract ensures that `block.timestamp` falls
within the specified `(start, end)` range. Additionally, the sequencer
verifies that the `block.timestamp` is sufficiently far from the range’s
end. This is to prevent DoS attacks where transactions pass validation
but get stuck in the mempool during execution. This constraint is
configurable and can be adjusted without requiring protocol update.

The PR also introduces two new fields to the `transactions` table:
`timestamp_asserter_range_start` and `timestamp_asserter_range_end`.
These fields are extracted during transaction execution in the sandbox
by the `ValidationTracer`. If multiple assertions are made in a single
transaction, the system captures the maximum of the starts and the
minimum of the ends, resulting in the narrowest possible time range.

Transactions with time range constraints will undergo additional
verification before being included in a block. If the current time falls
outside the transaction’s specified time range, the transaction will be
rejected with an appropriate message.

Sister PR in `era-contracts`:
matter-labs/era-contracts#843

---------

Signed-off-by: Danil <deniallugo@gmail.com>
Co-authored-by: Danil <deniallugo@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@StanislavBreadless StanislavBreadless StanislavBreadless left review comments

@vladbochok vladbochok vladbochok approved these changes

@Deniallugo Deniallugo Awaiting requested review from Deniallugo Deniallugo is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@ischasny @vladbochok @StanislavBreadless