From b543a623c1a6c71eba492a1b47019d6a0def372e Mon Sep 17 00:00:00 2001 From: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> Date: Wed, 22 Jan 2025 00:34:37 +0530 Subject: [PATCH 1/3] Update README.md Signed-off-by: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> --- precompile/contracts/warp/README.md | 31 +++++++++++++---------------- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/precompile/contracts/warp/README.md b/precompile/contracts/warp/README.md index 73ca165224..25c152b331 100644 --- a/precompile/contracts/warp/README.md +++ b/precompile/contracts/warp/README.md @@ -1,6 +1,6 @@ # Integrating Avalanche Warp Messaging into the EVM -Avalanche Warp Messaging offers a basic primitive to enable Cross-Subnet communication on the Avalanche Network. +Avalanche Warp Messaging offers a basic primitive to enable Cross-L1 communication on the Avalanche Network. It is intended to allow communication between arbitrary Custom Virtual Machines (including, but not limited to Subnet-EVM and Coreth). @@ -8,7 +8,7 @@ It is intended to allow communication between arbitrary Custom Virtual Machines Avalanche Warp Messaging uses BLS Multi-Signatures with Public-Key Aggregation where every Avalanche validator registers a public key alongside its NodeID on the Avalanche P-Chain. -Every node tracking a Subnet has read access to the Avalanche P-Chain. This provides weighted sets of BLS Public Keys that correspond to the validator sets of each Subnet on the Avalanche Network. Avalanche Warp Messaging provides a basic primitive for signing and verifying messages between Subnets: the receiving network can verify whether an aggregation of signatures from a set of source Subnet validators represents a threshold of stake large enough for the receiving network to process the message. +Every node tracking an Avalanche L1 has read access to the Avalanche P-Chain. This provides weighted sets of BLS Public Keys that correspond to the validator sets of each L1 on the Avalanche Network. Avalanche Warp Messaging provides a basic primitive for signing and verifying messages between L1s: the receiving network can verify whether an aggregation of signatures from a set of source L1 validators represents a threshold of stake large enough for the receiving network to process the message. For more details on Avalanche Warp Messaging, see the AvalancheGo [Warp README](https://docs.avax.network/build/cross-chain/awm/deep-dive). @@ -77,27 +77,24 @@ Since the predicate is encoded into the [Transaction Access List](https://eips.e Therefore, we use the [Predicate Utils](https://github.com/ava-labs/coreth/blob/master/predicate/Predicate.md) package to encode the actual byte slice of size N into the access list. -### Performance Optimization: C-Chain to Subnet +### Performance Optimization: C-Chain to Avalanche L1 -To support C-Chain to Subnet communication, or more generally Primary Network to Subnet communication, we special case the C-Chain for two reasons: +For communication between the C-Chain and L1, as well as broader interactions between the Primary Network and Avalanche L1s, we've implemented special handling for the C-Chain. This special case is necessary since the Primary Network operates with the maximum number of possible validators. -1. Every Subnet validator validates the C-Chain -2. The Primary Network has the largest possible number of validators +This large validator set in the Primary Network creates a unique challenge for Avalanche Warp Messages. Since reaching the required stake threshold would demand collecting numerous signatures, verifying messages from the Primary Network would be computationally intensive and costly. However, we've developed a more efficient solution. -Since the Primary Network has the largest possible number of validators for any Subnet on Avalanche, it would also be the most expensive Subnet to receive and verify Avalanche Warp Messages from as it reaching a threshold of stake on the primary network would require many signatures. Luckily, we can do something much smarter. +When an Avalanche L1 receives a message from a blockchain on the Primary Network, we use the validator set of the receiving L1 instead of the entire network when validating the message. This means that the C-Chain sending a message can be the exact same as Subnet to Subnet communication. -When a Subnet receives a message from a blockchain on the Primary Network, we use the validator set of the receiving Subnet instead of the entire network when validating the message. This means that the C-Chain sending a message can be the exact same as Subnet to Subnet communication. +However, when L1 XYZ receives a message from the C-Chain, it changes the semantics to the following: -However, when Subnet B receives a message from the C-Chain, it changes the semantics to the following: +1. Read the `SourceChainID` of the signed message (C-Chain) +2. Look up the `SubnetID` that validates C-Chain: Primary Network +3. Look up the validator set of L1 XYZ (instead of the Primary Network) and the registered BLS Public Keys of L1 XYZ at the P-Chain height specified by the ProposerVM header +4. Continue Warp Message verification using the validator set of L1 XYZ instead of the Primary Network -1. Read the SourceChainID of the signed message (C-Chain) -2. Look up the SubnetID that validates C-Chain: Primary Network -3. Look up the validator set of Subnet B (instead of the Primary Network) and the registered BLS Public Keys of Subnet B at the P-Chain height specified by the ProposerVM header -4. Continue Warp Message verification using the validator set of Subnet B instead of the Primary Network +This means that C-Chain to L1 communication only requires a threshold of stake on the receiving L1 to sign the message instead of a threshold of stake for the entire Primary Network. -This means that C-Chain to Subnet communication only requires a threshold of stake on the receiving subnet to sign the message instead of a threshold of stake for the entire Primary Network. - -This assumes that the security of Subnet B already depends on the validators of Subnet B to behave virtuously. Therefore, requiring a threshold of stake from the receiving Subnet's validator set instead of the whole Primary Network does not meaningfully change security of the receiving Subnet. +This assumes that the security of L1 XYZ already depends on the validators of L1 XYZ to behave virtuously. Therefore, requiring a threshold of stake from the receiving L1's validator set instead of the whole Primary Network does not meaningfully change security of the receiving L1. Note: this special case is ONLY applied during Warp Message verification. The message sent by the Primary Network will still contain the Avalanche C-Chain's blockchainID as the sourceChainID and signatures will be served by querying the C-Chain directly. @@ -107,7 +104,7 @@ Note: this special case is ONLY applied during Warp Message verification. The me Avalanche Warp Messaging depends on the Avalanche P-Chain state at the P-Chain height specified by the ProposerVM block header. -Verifying a message requires looking up the validator set of the source subnet on the P-Chain. To support this, Avalanche Warp Messaging uses the ProposerVM header, which includes the P-Chain height it was issued at as the canonical point to lookup the source subnet's validator set. +Verifying a message requires looking up the validator set of the source L1 on the P-Chain. To support this, Avalanche Warp Messaging uses the ProposerVM header, which includes the P-Chain height it was issued at as the canonical point to lookup the source L1's validator set. This means verifying the Warp Message and therefore the state transition on a block depends on state that is external to the blockchain itself: the P-Chain. From 7137ca63afe27727144b07e48152653895d3648d Mon Sep 17 00:00:00 2001 From: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> Date: Tue, 28 Jan 2025 13:28:46 +0530 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Darioush Jalali Signed-off-by: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> --- precompile/contracts/warp/README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/precompile/contracts/warp/README.md b/precompile/contracts/warp/README.md index 25c152b331..b12816b3c5 100644 --- a/precompile/contracts/warp/README.md +++ b/precompile/contracts/warp/README.md @@ -79,12 +79,13 @@ Therefore, we use the [Predicate Utils](https://github.com/ava-labs/coreth/blob/ ### Performance Optimization: C-Chain to Avalanche L1 -For communication between the C-Chain and L1, as well as broader interactions between the Primary Network and Avalanche L1s, we've implemented special handling for the C-Chain. This special case is necessary since the Primary Network operates with the maximum number of possible validators. +For communication between the C-Chain and L1, as well as broader interactions between the Primary Network and Avalanche L1s, we've implemented special handling for the C-Chain. -This large validator set in the Primary Network creates a unique challenge for Avalanche Warp Messages. Since reaching the required stake threshold would demand collecting numerous signatures, verifying messages from the Primary Network would be computationally intensive and costly. However, we've developed a more efficient solution. +The Primary Network has a large validator set, which creates a unique challenge for Avalanche Warp Messages: Since reaching the required stake threshold would demand collecting numerous signatures, and verifying messages from the Primary Network would be computationally costly. However, we've developed a more efficient solution. -When an Avalanche L1 receives a message from a blockchain on the Primary Network, we use the validator set of the receiving L1 instead of the entire network when validating the message. This means that the C-Chain sending a message can be the exact same as Subnet to Subnet communication. +When an Avalanche L1 receives a message from a blockchain on the Primary Network, we use the validator set of the receiving L1 instead of the entire network when validating the message. Note this is NOT possible if an L1 does not validate the Primary Network, in which case the Warp precompile must be configured with `requirePrimaryNetworkSigners`. +Sending messages from the C-Chain remains unchanged. However, when L1 XYZ receives a message from the C-Chain, it changes the semantics to the following: 1. Read the `SourceChainID` of the signed message (C-Chain) From b4424dc5a6e08597fc92034a28a843a89404b955 Mon Sep 17 00:00:00 2001 From: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> Date: Tue, 28 Jan 2025 16:59:55 +0530 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: Quentin McGaw Signed-off-by: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> --- precompile/contracts/warp/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/precompile/contracts/warp/README.md b/precompile/contracts/warp/README.md index b12816b3c5..5a3b79a486 100644 --- a/precompile/contracts/warp/README.md +++ b/precompile/contracts/warp/README.md @@ -79,9 +79,9 @@ Therefore, we use the [Predicate Utils](https://github.com/ava-labs/coreth/blob/ ### Performance Optimization: C-Chain to Avalanche L1 -For communication between the C-Chain and L1, as well as broader interactions between the Primary Network and Avalanche L1s, we've implemented special handling for the C-Chain. +For communication between the C-Chain and an L1, as well as broader interactions between the Primary Network and Avalanche L1s, we have implemented special handling for the C-Chain. -The Primary Network has a large validator set, which creates a unique challenge for Avalanche Warp Messages: Since reaching the required stake threshold would demand collecting numerous signatures, and verifying messages from the Primary Network would be computationally costly. However, we've developed a more efficient solution. +The Primary Network has a large validator set, which creates a unique challenge for Avalanche Warp messages. To reach the required stake threshold, numerous signatures would need to be collected and verifying messages from the Primary Network would be computationally costly. However, we have developed a more efficient solution. When an Avalanche L1 receives a message from a blockchain on the Primary Network, we use the validator set of the receiving L1 instead of the entire network when validating the message. Note this is NOT possible if an L1 does not validate the Primary Network, in which case the Warp precompile must be configured with `requirePrimaryNetworkSigners`.