first barriers explained #46

vstam1 · 2023-09-05T15:38:26Z

No description provided.

kianenigma · 2023-09-06T11:51:24Z

src/executor_config/barrier.md

+# Barrier
+Before any XCMs are executed in the XCM executor, they must pass the Barrier.
+The Barrier type implements the `ShouldExecute`
+[trait](https://paritytech.github.io/polkadot/doc/xcm_executor/traits/trait.ShouldExecute.html)


Given all these links being so long, it might be useful to list them at the bottom of the file. Something like:

some [`link`] foo [`link`]: https://paritytech.github.io/polkadot/doc/xcm_executor/traits/trait.ShouldExecute.html

This works in rust-docs, I think it is a native markdown feature.

Did not know this! Really nice feature.

kianenigma · 2023-09-06T11:53:09Z

src/executor_config/barrier.md

+
+
+### `TakeWeightCredit`
+The `TakeWeightCredit`` barrier checks if the calculated weight of the XCM does not exceed a set weight limit. 


For each of these barriers, can these explanations be just part of the rust-docs? Remember, "what can be documented in rust-docs (or generally a lower level documentation) should be documented in there".

I am not familiar enough to make the call, but it seems to me that these should just be rust-docs, and the high level concepts, possibly how you compose and use barriers in the broad scope should be mentioned here.

Or possibly, if this is paraphrasing what is already in the rust-docs, I also think there is less added value in it.

I agree with putting this explanations in rust-docs. I also think some amount of the top-level explanations and examples should be in rust-docs too.

kianenigma · 2023-09-06T13:30:26Z

src/executor_config/barrier.md

+Each time the xcm-executor receives an XCM, it checks with the barrier to determine if the XCM should be executed.
+
+We can also define multiple barriers for our Barrier type using a tuple.
+During execution, each barrier is checked, and if any of them succeed, the XCM is executed.


question for me: how can you express an && operator with these barriers then? is there a way to say: Execute if all of my barriers pass?

As far as I know we do not support && operator in any way as I am not sure if it makes sense with the current barrier implementations. Most of these implementations are used for specific XCMs. We of course already have nested barriers like the WithComputedOrigin. We could make something similar that takes other implementations and only passes if all the implementations pass.

kianenigma · 2023-09-06T13:30:39Z

src/executor_config/barrier.md

@@ -0,0 +1,89 @@
+-TODO: All Barriers Explained
+-TODO: Security Note about misconfigured barriers
+-TODO: Example


Examples would be both nice here, but also as a part of the rust-docs.

I created an comprehensive example that uses most of the Barriers in the list together, showing how barriers can be combined.

franciscoaguirre

We should port this to the polkadot wiki, see: #47

franciscoaguirre · 2023-09-07T13:20:45Z

src/executor_config/barrier.md

+Multiple barriers can be defined for the Barrier type using a tuple. During execution, each barrier is checked, and if any succeed, the XCM is executed. The combination of barriers is crucial as it can either block or allow specific XCM functionalities. An example of how barriers can be combined will be provided in the [example section](#example).
+
+## Security
+Barriers are vital for the security of the xcm-executor, acting as its firewall. Their main role is to decide whether a given XCM should be executed. Barriers can operate in various ways, such as checking if certain origins are authorized to execute an XCM, verifying if the XCM contains specific instructions, or a combination of both. Incorrectly configuring a barrier can lead to vulnerabilities, such as allowing attackers to flood the system with XCMs, potentially causing a Denial of Service.


I'd add that it's important to note the barrier will run for each message received in order to know if it should be executed, so it should be cheap to compute.

franciscoaguirre · 2023-09-07T13:21:34Z

src/executor_config/barrier.md

+
+
+


Suggested change

franciscoaguirre · 2023-09-07T13:25:16Z

src/executor_config/barrier.md

@@ -0,0 +1,75 @@
+# Barrier
+Before any XCMs are executed in the XCM executor, they must pass through the Barrier. The Barrier type implements the [`ShouldExecute`] trait and serves as the firewall for the xcm-executor. Each time the xcm-executor receives an XCM, it consults the Barrier to determine if the XCM should be executed.


I'd add in a new paragraph that barriers can also modify the message, like adding a new instruction or whatnot.

franciscoaguirre · 2023-09-07T13:27:48Z

src/executor_config/barrier.md

+- [`DenyReserveTransferToRelayChain`]
+
+
+### Example


This is a good example, but I would add some smaller examples before it to build up to it. Makes it easier to understand.

first barriers explained

dec0800

kianenigma reviewed Sep 6, 2023

View reviewed changes

link to code docs, add security and examples chapter

fee5035

franciscoaguirre reviewed Sep 7, 2023

View reviewed changes



		### `TakeWeightCredit`
		The `TakeWeightCredit`` barrier checks if the calculated weight of the XCM does not exceed a set weight limit.

		@@ -0,0 +1,75 @@
		# Barrier
		Before any XCMs are executed in the XCM executor, they must pass through the Barrier. The Barrier type implements the [`ShouldExecute`] trait and serves as the firewall for the xcm-executor. Each time the xcm-executor receives an XCM, it consults the Barrier to determine if the XCM should be executed.

first barriers explained #46

Are you sure you want to change the base?

first barriers explained #46

Uh oh!

Conversation

vstam1 commented Sep 5, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kianenigma Sep 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

franciscoaguirre left a comment

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

kianenigma Sep 6, 2023 •

edited

Loading