CIP 0121 - remove whitelists by nicu-da · Pull Request #1 · nicu-da/cips

nicu-da · 2026-08-21T09:32:15Z

No description provided.

martinflorian-da

Thanks a lot! I do have a fair amount of comments it seems...

On the highest level I wonder about whether we should also start the CIP for permissioning the sync sooner rather than later.

martinflorian-da · 2026-08-21T09:43:14Z

+maintained IP whitelist that each Super Validator (SV) applies. Every new validator, address change, or additional egress range requires a central request-and-approval step 
+before that validator can reach the network. This CIP proposes to remove the IP whitelist so that validators can join a genuinely public network without a whitelisting process.
+
+The whitelist cannot simply be dropped: it currently provides two protections incidentally — a bound on who can consume node resources, and a bound on who can reach the synchronizer. 


Hm this is valid but IMO the main problem is:

with whitelists, it's trivial to block an attacker once they start messing around

without that option, we need protection mechanisms that don't depend on some form of identity (IP addresses are cheap)

Isn't that where rate limit come into force? Though realistically an attacker that's sophisticated enough can in theory consume the entire global capacity, but that requires intervention on a per case basis.

martinflorian-da · 2026-08-21T10:14:58Z

+
+In front of its public endpoints, every SV must operate:
+
+- Global rate limiting across all Scan and all sequencer endpoints.


Dumb question: what does "rate limiting" actually mean?

For scan we see to mean "limit rate of requests" (might be worth to make that explicit, dunno).

Does this map 1:1 also to the sequencer?

And we ignore aspects such as payload sizes, number of parallel connections, HTTP2- or TCP-level things that attackers might try?

Possibly we can just ignore the questions about sequencers because there "blocking" works quite well, by unpermissioning malicious actors?

For scan just requests.
For the sequencer we currently have active requests, confirmation requests and the plan is to add requests as well.

For the sequencer we currently have active requests, confirmation requests and the plan is to add requests as well.

But on the infra side?

We specifically say that on the infra level all public endpoints must have rate limits in front of them, so sequencer included. Should we make it more explicit?

I think here specifically it's clear that we want infra-base rate limiting in front of sequencers, I'm just not sure if it's going to be clear to everyone what this exactly means, i.e., rate of what needs to be limited here.

Could also be too much detail for a CIP and/or obvious to whoever it matters; just thinking aloud.

martinflorian-da · 2026-08-21T10:20:14Z

+- throttled requests receive the expected response;
+- client IPs are correctly identified and limited, even when forwarded through a trusted proxy;
+
+## Motivation


Shouldn't that be very close to the top as well?

I just followed the template 🤷

I never found the template to make sense, but got pushback when I proposed to change it. Let's stick with it as it is.

martinflorian-da · 2026-08-21T10:21:08Z

+## Rationale
+
+With the synchronizer being permissioned, the IP whitelist is no longer needed to have control over the participants that can connect to the synchronizer. 
+The rate limiting and DDoS protection provide a bound on resource consumption and protect against denial-of-service attacks, so that the network can remain available even when under load.


I think we should mention also here that "permissioned synchronizer" doesn't help scan.

Co-authored-by: Martin Florian <martin.florian@digitalasset.com> Signed-off-by: Nicu Reut <nicu.reut@digitalasset.com>

moritzkiefer-da

Thanks! This lgtm. I suspect the obvious question we will get though is

What audits have you done to make this safe?

So we likely need to have some answer as to what properties have been audited (could be as simple as "check for bounded resource consumption on endpoints and that synchronizer permissioning works properly") and plan at least an internal audit (and we probably want to confirm upfront with the SVs what they would be willing to acceptr

Co-authored-by: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> Signed-off-by: Nicu Reut <nicu.reut@digitalasset.com>

martinflorian-da

Thanks! Let's loop in @isegall-da for the next iteration!

martinflorian-da · 2026-08-24T13:36:07Z

+
+In front of its public endpoints, every SV must operate:
+
+- Global rate limiting across all Scan and all sequencer endpoints.


I think here specifically it's clear that we want infra-base rate limiting in front of sequencers, I'm just not sure if it's going to be clear to everyone what this exactly means, i.e., rate of what needs to be limited here.

Could also be too much detail for a CIP and/or obvious to whoever it matters; just thinking aloud.

martinflorian-da · 2026-08-24T13:38:39Z

+
+#### Audit
+
+An internal audit of all the endpoints that will be exposed to the public will be performed to ensure that they are not vulnerable to abuse or denial-of-service attacks.


Suggested change

An internal audit of all the endpoints that will be exposed to the public will be performed to ensure that they are not vulnerable to abuse or denial-of-service attacks.

An internal audit of the APIs that will be exposed to the public will be performed to ensure that they are not vulnerable to abuse or denial-of-service attacks.

The framing "all the endpoints" matches what we plan to provide for scan, but I'm not sure how the audit results for the sequencer can be presented with reasonable effort. And I see no downside to keeping the promise a bit more fuzzy here...

martinflorian-da · 2026-08-24T13:41:20Z

+
+### Preconditions for Removal
+
+1. **A traffic-based onboarding gate is in place.** Synchronizer access must be gated so that participants incur a traffic cost to onboard, and allow the blocking of nodes at a protocol level.


We need to add that this will be handled in a separate CIP and that this CIP focuses on the remaining aspects only.

isegall-da · 2026-08-26T19:50:55Z

+- The same type of limits, configurable per OpenAPI operation, allowing for more restrictive rate limits for certain operations.
+- Bounded per-IP-address-range overrides, so that a known high-volume consumer can be granted a higher limit without being exempted from limiting.
+
+Throttled requests must return `HTTP 429`.


TMI for a CIP in my opinion.

(and similarly for RESOURCE_EXHAUSTED below)

isegall-da · 2026-08-26T19:52:19Z

+
+### Infrastructure Requirements
+
+In front of its public endpoints, every SV must operate:


Probably wanna say explicitly that this will be documented in public docs

isegall-da · 2026-08-26T19:54:05Z

+### Scope
+
+The removal of the whitelists applies only to the validator-facing public endpoints of Scan and the sequencers. 
+No changes are made to the non-public endpoints, or to the whitelists that handle traffic that occurs only between SV nodes.


Maybe be more explicit on "non-public" is here, i.e. who these are exposed to.

isegall-da · 2026-08-26T19:55:23Z

+
+#### Audit
+
+An internal audit of all the endpoints that will be exposed to the public will be performed to ensure that they are not vulnerable to abuse or denial-of-service attacks.


an internal audit .. will be performed

.. And its results will be made available to all SV operators.

isegall-da · 2026-08-26T19:57:54Z

+
+## Rationale
+
+With a traffic-based onboarding gate in place, the IP whitelist is no longer needed to have control over the participants that can connect to the synchronizer (this has no impact on Scan). 


this has no impact on Scan

I don't understand what "this" refers to here.

CIP 0121 - remove whitelists

38291ff

martinflorian-da reviewed Aug 21, 2026

View reviewed changes

nicu-da and others added 3 commits August 21, 2026 12:39

Apply suggestions from code review

0dc5465

Co-authored-by: Martin Florian <martin.florian@digitalasset.com> Signed-off-by: Nicu Reut <nicu.reut@digitalasset.com>

review

99617ec

.

e763648

moritzkiefer-da reviewed Aug 21, 2026

View reviewed changes

Comment thread cip-0121/cip-0121.md Outdated

Comment thread cip-0121/cip-0121.md Outdated

Comment thread cip-0121/cip-0121.md Outdated

Comment thread cip-0121/cip-0121.md Outdated

nicu-da and others added 3 commits August 21, 2026 12:57

Apply suggestions from code review

936f379

Co-authored-by: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> Signed-off-by: Nicu Reut <nicu.reut@digitalasset.com>

.

b4968d7

.

f08df09

nicu-da requested a review from martinflorian-da August 24, 2026 07:28

nicu-da mentioned this pull request Aug 24, 2026

Add rate limits initial documentation canton-network/cf-docs#1450

Merged

martinflorian-da approved these changes Aug 24, 2026

View reviewed changes

nicu-da added 2 commits August 26, 2026 08:17

.

32cbd06

.

0a30565

isegall-da reviewed Aug 26, 2026

View reviewed changes


		In front of its public endpoints, every SV must operate:

		- Global rate limiting across all Scan and all sequencer endpoints.


		#### Audit

		An internal audit of all the endpoints that will be exposed to the public will be performed to ensure that they are not vulnerable to abuse or denial-of-service attacks.

	An internal audit of all the endpoints that will be exposed to the public will be performed to ensure that they are not vulnerable to abuse or denial-of-service attacks.
	An internal audit of the APIs that will be exposed to the public will be performed to ensure that they are not vulnerable to abuse or denial-of-service attacks.


		### Preconditions for Removal

		1. A traffic-based onboarding gate is in place. Synchronizer access must be gated so that participants incur a traffic cost to onboard, and allow the blocking of nodes at a protocol level.


		### Infrastructure Requirements

		In front of its public endpoints, every SV must operate:


		## Rationale

		With a traffic-based onboarding gate in place, the IP whitelist is no longer needed to have control over the participants that can connect to the synchronizer (this has no impact on Scan).

Conversation

nicu-da commented Aug 21, 2026

Uh oh!

martinflorian-da left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

moritzkiefer-da left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

martinflorian-da left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants