evm: add SolanaCall to GovernanceAction

Author: kcsongor

README.md

@@ -40,5 +40,17 @@ NTT supports rate-limiting both on the sending and destination chains. If a tran
 
 If users bridge frequently between a given source chain and destination chain, the capacity could be exhausted quickly. This can leave other users rate-limited, potentially delaying their transfers. To mitigate this issue, the outbound transfer cancels the inbound rate-limit on the source chain (refills the inbound rate-limit by an amount equal to that of the outbound transfer amount) and vice-versa, the inbound transfer cancels the outbound rate-limit on the destination chain (refills the outbound rate-limit by an amount equal to the inbound transfer amount).
 
+## Wormhole Governance
+
+There are general purpose governance contracts implemented for both EVM and Solana, which allow Wormhole Guardians to govern arbitrary contracts if they choose to do so (and the governed contract chooses to as well).
+The concrete interpretation of the governance packets are runtime specific, but they both follow the same spec (as defined in https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0002_governance_messaging.md).
+Namely, the governance messages start with a 32 byte module identifier, which is the string `"GeneralPurposeGovernance"` left padded, followed by a 1 byte action identifier, finally followed by a chain id.
+
+The action identifier specifies the runtime. Currently, these are as follows:
+
+- 0: undefined
+- 1: evm
+- 2: solana
+
 ___
 ⚠️ **WARNING:** Ensure that if the `NttManager` on the source chain is configured to be in `LOCKING` mode, the corresponding `NttManager`s on the target chains are configured to be in `BURNING` mode. If not, transfers will NOT go through and user funds may be lost! Proceed with caution!

evm/src/wormhole/Governance.sol

@@ -11,9 +11,21 @@ contract Governance {
     bytes32 public constant MODULE =
         0x000000000000000047656E6572616C507572706F7365476F7665726E616E6365;
 
+    /// @notice The known set of governance actions.
+    /// @dev As the governance logic is expanded to more runtimes, it's
+    ///      important to keep them in sync, at least the newer ones should ensure
+    ///      they don't overlap with the existing ones.
+    ///
+    ///      Existing implementations are not strongly required to be updated
+    ///      to be aware of new actions (as they will never need to know the
+    ///      action indices higher than the one corresponding to the current
+    ///      runtime), but it's good practice.
+    ///
+    ///      When adding a new runtime, make sure to at least update in the README.md
     enum GovernanceAction {
         UNDEFINED,
-        EVM_CALL
+        EVM_CALL,
+        SOLANA_CALL
     }
 
     IWormhole immutable wormhole;

solana/programs/wormhole-governance/src/instructions/governance.rs

@@ -145,7 +145,7 @@ impl Readable for GovernanceMessage {
             ));
         }
         let action: GovernanceAction = Readable::read(reader)?;
-        if action != GovernanceAction::SolanaInstruction {
+        if action != GovernanceAction::SolanaCall {
             return Err(io::Error::new(
                 io::ErrorKind::InvalidData,
                 "Invalid GovernanceAction",
@@ -208,7 +208,7 @@ impl Writeable for GovernanceMessage {
         } = self;
 
         Self::MODULE.write(writer)?;
-        GovernanceAction::SolanaInstruction.write(writer)?;
+        GovernanceAction::SolanaCall.write(writer)?;
         u16::from(Chain::Solana).write(writer)?;
         program_id.to_bytes().write(writer)?;
         (accounts.len() as u16).write(writer)?;
@@ -252,10 +252,21 @@ fn test_governance_message_serde() {
 }
 
 #[derive(Clone, Copy, Debug, PartialEq, Eq)]
+/// The known set of governance actions.
+///
+/// As the governance logic is expanded to more runtimes, it's important to keep
+/// them in sync, at least the newer ones should ensure they don't overlap with
+/// the existing ones.
+///
+/// Existing implementations are not strongly required to be updated to be aware
+/// of new actions (as they will never need to know the action indices higher
+/// than the one corresponding to the current runtime), but it's good practice.
+///
+/// When adding a new runtime, make sure to at least update in the README.md
 pub enum GovernanceAction {
     Undefined,
-    EvmInstruction,
-    SolanaInstruction,
+    EvmCall,
+    SolanaCall,
 }
 
 impl Readable for GovernanceAction {
@@ -268,8 +279,8 @@ impl Readable for GovernanceAction {
     {
         match Readable::read(reader)? {
             0 => Ok(GovernanceAction::Undefined),
-            1 => Ok(GovernanceAction::EvmInstruction),
-            2 => Ok(GovernanceAction::SolanaInstruction),
+            1 => Ok(GovernanceAction::EvmCall),
+            2 => Ok(GovernanceAction::SolanaCall),
             _ => Err(io::Error::new(
                 io::ErrorKind::InvalidData,
                 "Invalid GovernanceAction",
@@ -289,8 +300,8 @@ impl Writeable for GovernanceAction {
     {
         match self {
             GovernanceAction::Undefined => Ok(()),
-            GovernanceAction::EvmInstruction => 1.write(writer),
-            GovernanceAction::SolanaInstruction => 2.write(writer),
+            GovernanceAction::EvmCall => 1.write(writer),
+            GovernanceAction::SolanaCall => 2.write(writer),
         }
     }
 }