From d493f06fa470d7f37e1125ca17862188e1dba62c Mon Sep 17 00:00:00 2001 From: maurelian Date: Wed, 14 Aug 2024 03:35:40 +0000 Subject: [PATCH] deploy: d7a5773958d40edd7d74d76e3067daed3c22f75c --- experimental/security-council-safe.html | 51 ++++++++++++++----------- print.html | 51 ++++++++++++++----------- 2 files changed, 56 insertions(+), 46 deletions(-) diff --git a/experimental/security-council-safe.html b/experimental/security-council-safe.html index 263b41be6..2f7d194d9 100644 --- a/experimental/security-council-safe.html +++ b/experimental/security-council-safe.html @@ -227,11 +227,11 @@

S

Deputy guardian module

The Security Council acts as the Guardian, which is authorized to activate the Superchain Pause functionality and for -blacklisting dispute -game contracts.

+blacklisting dispute game +contracts.

However the Security Council cannot be expected to react quickly in an emergency situation. -Therefore the Deputy Guardian module enables the Security Council to share this -authorization with another account.

+Therefore the Deputy Guardian module enables the Security Council to share this authorization with +another account.

The module has the following minimal interface:

interface DeputyGuardianModule {
    /// @dev The address of the Security Council Safe
@@ -265,8 +265,9 @@
-

For simplicity, the DeputyGuardianModule module does not have functions for updating the safe and -deputyGuardian addresses. If necessary these can be modified by swapping out with a new module.

+

For simplicity, the DeputyGuardianModule module does not have functions for updating the safe +and deputyGuardian addresses. If necessary these can be modified by swapping out with a new +module.

Deputy Guardian Module Security Properties

The following security properties must be upheld by the DeputyGuardianModule:

    @@ -311,23 +312,25 @@

    The liv are ignored.
  1. An owner may call the contract's showLiveness()() method directly in order to prove liveness.

-

Note that the first two methods do not require the owner to actually sign anything. However these mechanisms -are necessary to prevent new owners from being removed before they have had a chance to show liveness.

+

Note that the first two methods do not require the owner to actually sign anything. However these +mechanisms are necessary to prevent new owners from being removed before they have had a chance to +show liveness.

The liveness module

A LivenessModule is also created which does the following:

    -
  1. Has a function removeOwners() that anyone may call to specify one or more owners to be removed from the -Safe.
    2. -
  2. The Module would then check the LivenessGuard.lastLive() to determine if the signer is -eligible for removal.
    3. +
  3. Has a function removeOwners() that anyone may call to specify one or more owners to be removed +from the Safe.
    4. +
  4. The Module would then check the LivenessGuard.lastLive() to determine if the signer is eligible +for removal.
  5. If so, it will call the Safe's removeSigner() to remove the non-live signer, and if necessary reduce the threshold.
  6. When a member is removed, the signing parameters are modified such that M/N is the lowest ratio -which remains greater than or equal to 75%. Using integer math, this can be expressed as M = (N * 75 + 99) / 100.
    7. +which remains greater than or equal to 75%. Using integer math, this can be expressed as +M = (N * 75 + 99) / 100.

Owner removal call flow

-

The following diagram illustrates the flow for removing a single owner. The verifyFinalState -box indicates calls to the Safe which ensure the final state is valid.

+

The following diagram illustrates the flow for removing a single owner. The verifyFinalState box +indicates calls to the Safe which ensure the final state is valid.

sequenceDiagram
     participant User
     participant LivenessModule
@@ -346,8 +349,8 @@ 
Shutdown

 
In the unlikely event that the signer set (N) is reduced below the allowed minimum number of
-owners, then (and only then) is a shutdown mechanism activated which removes the existing
-signers, and hands control of the multisig over to a predetermined entity.

+owners, then (and only then) is a shutdown mechanism activated which removes the existing signers,
+and hands control of the multisig over to a predetermined entity.

 
Liveness Security Properties

 
The following security properties must be upheld:

 
In the guard

@@ -374,12 +377,13 @@ 
In the module
 if enough other owners have been removed to activate the shutdown mechanism.
 
  • The module correctly sets the Safe's threshold upon removing a signer.
    • 
 
-
    Note: neither the module nor guard attempt to prevent a quorum of owners from removing either the liveness
-module or guard. There are legitimate reasons they might wish to do so. Moreover, if such a quorum
-of owners exists, there is no benefit to removing them, as they are defacto 'sufficiently live'.
    
+
    Note: neither the module nor guard attempt to prevent a quorum of owners from removing either the
+liveness module or guard. There are legitimate reasons they might wish to do so. Moreover, if such a
+quorum of owners exists, there is no benefit to removing them, as they are defacto 'sufficiently
+live'.
    
 
    Interdependency between the guard and module
    
-
    The guard has no dependency on the module, and can be used independently to track liveness of
-Safe owners.
    
+
    The guard has no dependency on the module, and can be used independently to track liveness of Safe
+owners.
    
 
    This means that the module can be removed or replaced without any affect on the guard.
    
 
    The module however does have a dependency on the guard; if the guard is removed from the Safe, then
 the module will no longer be functional and calls to its removeOwners function will revert.
    
@@ -392,7 +396,8 @@ 
    S
 
    Deputy guardian module
    
 
    The Security Council acts as the Guardian, which is authorized to activate the Superchain
 Pause functionality and for
-blacklisting dispute
-game contracts.
    
+blacklisting dispute game
+contracts.
    
 
    However the Security Council cannot be expected to react quickly in an emergency situation.
-Therefore the Deputy Guardian module enables the Security Council to share this
-authorization with another account.
    
+Therefore the Deputy Guardian module enables the Security Council to share this authorization with
+another account.
    
 
    The module has the following minimal interface:
    
 
    interface DeputyGuardianModule {
    /// @dev The address of the Security Council Safe
@@ -10022,8 +10022,9 @@ 
    
-
    For simplicity, the DeputyGuardianModule module does not have functions for updating the safe and
-deputyGuardian addresses. If necessary these can be modified by swapping out with a new module.
    
+
    For simplicity, the DeputyGuardianModule module does not have functions for updating the safe
+and deputyGuardian addresses. If necessary these can be modified by swapping out with a new
+module.
    
 
    Deputy Guardian Module Security Properties
    
 
    The following security properties must be upheld by the DeputyGuardianModule:
    
 
      
@@ -10068,23 +10069,25 @@ 
      The liv
 are ignored.
 
    1. An owner may call the contract's showLiveness()() method directly in order to prove liveness.
      2. 
 
    
-
    Note that the first two methods do not require the owner to actually sign anything. However these mechanisms
-are necessary to prevent new owners from being removed before they have had a chance to show liveness.
    
+
    Note that the first two methods do not require the owner to actually sign anything. However these
+mechanisms are necessary to prevent new owners from being removed before they have had a chance to
+show liveness.
    
 
    The liveness module
    
 
    A LivenessModule is also created which does the following:
    
 
      
-
    1. Has a function removeOwners() that anyone may call to specify one or more owners to be removed from the
-Safe.
      2. 
-
    2. The Module would then check the LivenessGuard.lastLive() to determine if the signer is
-eligible for removal.
      3. 
+
    3. Has a function removeOwners() that anyone may call to specify one or more owners to be removed
+from the Safe.
      4. 
+
    4. The Module would then check the LivenessGuard.lastLive() to determine if the signer is eligible
+for removal.
      5. 
 
    5. If so, it will call the Safe's removeSigner() to remove the non-live signer, and if necessary
 reduce the threshold.
      6. 
 
    6. When a member is removed, the signing parameters are modified such that M/N is the lowest ratio
-which remains greater than or equal to 75%. Using integer math, this can be expressed as M = (N * 75 + 99) / 100.
      7. 
+which remains greater than or equal to 75%. Using integer math, this can be expressed as
+M = (N * 75 + 99) / 100.
 
    
 
    Owner removal call flow
    
-
    The following diagram illustrates the flow for removing a single owner. The verifyFinalState
-box indicates calls to the Safe which ensure the final state is valid.
    
+
    The following diagram illustrates the flow for removing a single owner. The verifyFinalState box
+indicates calls to the Safe which ensure the final state is valid.
    
 
    sequenceDiagram
     participant User
     participant LivenessModule
@@ -10103,8 +10106,8 @@ 
    Shutdown
    
 
    In the unlikely event that the signer set (N) is reduced below the allowed minimum number of
-owners, then (and only then) is a shutdown mechanism activated which removes the existing
-signers, and hands control of the multisig over to a predetermined entity.
    
+owners, then (and only then) is a shutdown mechanism activated which removes the existing signers,
+and hands control of the multisig over to a predetermined entity.
    
 
    Liveness Security Properties
    
 
    The following security properties must be upheld:
    
 
    In the guard
    
@@ -10131,12 +10134,13 @@ 
    In the module
 if enough other owners have been removed to activate the shutdown mechanism.
 
  • The module correctly sets the Safe's threshold upon removing a signer.
    • 
 
-
    Note: neither the module nor guard attempt to prevent a quorum of owners from removing either the liveness
-module or guard. There are legitimate reasons they might wish to do so. Moreover, if such a quorum
-of owners exists, there is no benefit to removing them, as they are defacto 'sufficiently live'.
    
+
    Note: neither the module nor guard attempt to prevent a quorum of owners from removing either the
+liveness module or guard. There are legitimate reasons they might wish to do so. Moreover, if such a
+quorum of owners exists, there is no benefit to removing them, as they are defacto 'sufficiently
+live'.
    
 
    Interdependency between the guard and module
    
-
    The guard has no dependency on the module, and can be used independently to track liveness of
-Safe owners.
    
+
    The guard has no dependency on the module, and can be used independently to track liveness of Safe
+owners.
    
 
    This means that the module can be removed or replaced without any affect on the guard.
    
 
    The module however does have a dependency on the guard; if the guard is removed from the Safe, then
 the module will no longer be functional and calls to its removeOwners function will revert.
    
@@ -10149,7 +10153,8 @@