[ACP-113] Provable Virtual Machine Randomness #113
Conversation
tsachiherman
changed the title
|
|
||
| a. If the parent block has a valid `signedParentBlockSig` signature, that signature would be signed using the proposer’s BLS key. | ||
|
|
||
| b. If the parent block does not have a valid `signedParentBlockSig` signature, the proposer would sign the bootStrappingBlockSignature with its BLS key ( see below ) |
There was a problem hiding this comment.
We should clarify whether the hash of:
```
+-------------------------+----------+------------+
| prefix : | [8]byte | "rng-derv" |
+-------------------------+----------+------------+
| signedParentBlockSig : | [48]byte | 48 bytes |
+-------------------------+----------+------------+
```
constitutes a "valid signedParentBlockSig signature" since it isn't a signature, it's a hash.
There was a problem hiding this comment.
I replaced the wording of "valid" with empty/non-empty. I think it would better describe the usage.
|
|
||
| 2. The current proposer does not have a BLS key | ||
|
|
||
| a. If the parent block has a valid `signedParentBlockSig` signature, the proposer would set the signedParentBlockSig to the hash result of the following preimage: |
There was a problem hiding this comment.
Same as above -- what is the set of "valid" signedParentBlockSig?
|
|
||
| In order to bootstrap the signatures chain, a missing signature would be replaced with a byte slice that is the hash product of a verifiable and trustable seed. | ||
|
|
||
| The changes proposed here would affect the way a block is being validated. Therefore, when this change gets implemented, it needs to be deployed as a mandatory upgrade. |
There was a problem hiding this comment.
it needs to be deployed as a mandatory upgrade.
Is this feature always activated, or would it be possible to opt-in to activate this feature via some kind of voting?
It might be that some subnet/L1 would prefer to not pay the extra overhead.
There was a problem hiding this comment.
A subnet would still be fully usable without having this feature active. From technical perspective, the subnet would need to be configured to set the activation time for this feature to infinity. I think that the technical aspects (how to enabled/disable) of this feature are a bit beyond the scope of this ACP.
tsachiherman
changed the title
| a. If the parent block has an empty `vrfSig` signature, that signature would be signed using the proposer’s BLS key. This is the base case. | ||
|
|
||
| b. If the parent block does not have an empty `vrfSig` signature, the proposer would sign the bootStrappingBlockSignature with its BLS key. See the bootStrappingBlockSignature details below. |
There was a problem hiding this comment.
Aren't these cases swapped? You bootstrap if the vrfSig is empty right? If its not then you just chain sign.
There was a problem hiding this comment.
correct. fixed.
| @@ -0,0 +1,165 @@ | |||
| ```text | |||
There was a problem hiding this comment.
Would you mind updating the header to use the newly introduced table format?
https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/TEMPLATE.md
|
|
||
| To address this, a mechanism is proposed to generate verifiable, non-cryptographic random number seeds on the Avalanche platform. This method ensures uniformity while allowing developers to build more versatile applications. | ||
|
|
||
|
|
|
|
||
| ### Changes Summary | ||
|
|
||
| Existing avalanche protocol breaks the block building into two parts : external and internal. The external block is the SnowMan++ block, whereas the internal block is the actual virtual machine block. |
There was a problem hiding this comment.
| Existing avalanche protocol breaks the block building into two parts : external and internal. The external block is the SnowMan++ block, whereas the internal block is the actual virtual machine block. | |
| The existing Avalanche protocol breaks the block building into two parts : external and internal. The external block is the Snowman++ block, whereas the internal block is the actual virtual machine block. |
|
|
||
| To support randomness, a BLS based VRF implementation is used, that would be recursively signing its own signatures as its message. Since the BLS signatures are deterministic, they provide a great way to construct a reliable VRF. | ||
|
|
||
| For proposers that do not have a BLS key associated with their node, the hash of the signature from the previous round. |
There was a problem hiding this comment.
| For proposers that do not have a BLS key associated with their node, the hash of the signature from the previous round. | |
| For proposers that do not have a BLS key associated with their node, the hash of the signature from the previous round is used in place of their signature. |
|
|
||
| In order to bootstrap the signatures chain, a missing signature would be replaced with a byte slice that is the hash product of a verifiable and trustable seed. | ||
|
|
||
| The changes proposed here would affect the way a block is being validated. Therefore, when this change gets implemented, it needs to be deployed as a mandatory upgrade. |
There was a problem hiding this comment.
| The changes proposed here would affect the way a block is being validated. Therefore, when this change gets implemented, it needs to be deployed as a mandatory upgrade. | |
| The changes proposed here would affect the way a blocks are validated. Therefore, when this change gets implemented, it needs to be deployed as a mandatory upgrade. |
|
|
||
| 2. The current proposer does not have a BLS key | ||
|
|
||
| a. If the parent block has a non empty `vrfSig` signature, the proposer would set the proposed block `vrfSig` to the 32 byte hash result of the following preimage: |
There was a problem hiding this comment.
| a. If the parent block has a non empty `vrfSig` signature, the proposer would set the proposed block `vrfSig` to the 32 byte hash result of the following preimage: | |
| a. If the parent block has a non-empty `vrfSig` signature, the proposer would set the proposed block `vrfSig` to the 32 byte hash result of the following preimage: |
| | chainID : | [32]byte | 32 bytes | | ||
| +-----------------------+----------+------------+ | ||
| | networkID: | uint32 | 4 bytes | |
There was a problem hiding this comment.
Small nit: It may make more sense to put networkID before chainID here. Existing serializations (for Warp messages, P-Chain txs) that have those fields put them in that order to go from more general to more specific.
| Validating the `vrfSig` would following this logic: | ||
| 1. The proposer has a BLS key | ||
|
|
||
| a. If the parent block had a non empty `vrfSig`, then a BLS signature verification of the proposed block `vrfSig` would be made against the proposer’s BLS public key and the parent's block `vrfSig` as the message. |
There was a problem hiding this comment.
| a. If the parent block had a non empty `vrfSig`, then a BLS signature verification of the proposed block `vrfSig` would be made against the proposer’s BLS public key and the parent's block `vrfSig` as the message. | |
| a. If the parent block's `vrfSig` was non-empty , then the `vrfSig` in the proposed block is verified to be a valid BLS signature of the parent block's `vrfSig` value for the proposer's BLS public key. |
| 1. The proposer has a BLS key | ||
|
|
||
| a. If the parent block had a non empty `vrfSig`, then a BLS signature verification of the proposed block `vrfSig` would be made against the proposer’s BLS public key and the parent's block `vrfSig` as the message. | ||
| b. If the parent block does has an empty `vrfSig`, then a BLS signature verification of the proposed block `vrfSig` against the proposer’s BLS public key and bootStrappingBlockSignature would take place. |
There was a problem hiding this comment.
| b. If the parent block does has an empty `vrfSig`, then a BLS signature verification of the proposed block `vrfSig` against the proposer’s BLS public key and bootStrappingBlockSignature would take place. | |
| b. If the parent block's `vrfSig` was empty, then a BLS signature verification of the proposed block `vrfSig` against the proposer’s BLS public key and bootStrappingBlockSignature would take place. |
|
|
||
| Before calculating the VRF Out, the method needs to explicitly check the case where the `vrfSig` is empty. In that case, the output of the VRF Out needs to be empty as well. | ||
|
|
||
| ## Backwards Compatibility |
There was a problem hiding this comment.
You mentioned it above already, but I think the Backwards Compatibility section should also call out that these changes necessitate a required network upgrade.
|
|
||
| However, the effectiveness of this attack is significantly limited for the following reasons: | ||
| - Limited options: While colluding attackers expand their potential random number choices, the overall pool remains immense (2^32 possibilities). This drastically reduces their ability to target a specific value. | ||
| - Protocol's countermeasure: The protocol automatically eliminates any bias introduced by previous proposals once an honest proposer submits their block. |
There was a problem hiding this comment.
Should we also note that the presence of any bias is detectable and could be exposed in VMs so that applications can choose whether or not to use the resulting random number generated (i.e. only allow its use if it had <= 1 bit bias).
This PR adds the design document for the Provable Virtual Machine Randomness.
Abstract
Avalanche offers developers flexibility through subnets and EVM-compatible smart contracts. However, the platform's deterministic block execution limits the use of traditional random number generators within these contracts.
To address this, a mechanism is proposed to generate verifiable, non-cryptographic random number seeds on the Avalanche platform. This method ensures uniformity while allowing developers to build more versatile applications.