Merge pull request #1974 from OffchainLabs/external-signer-das-note

Add note about external signer support with AnyTrust

arbitrum-docs/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx

@@ -417,6 +417,28 @@ Taking that into account, there's a risk of Denial of Service attacks on those s
 
 Finally, as explained in the previous section, if you're also running a mirror DAS, there's no need to publicly expose the REST interface of your main DAS. Your mirrors can synchronize over your private network using the REST interface from your main DAS and other public mirrors.
 
+## External signer support
+
+By default the batch poster uses the same ECDSA key to sign `das_store` requests as it uses to sign the batch transactions sent to the sequencer inbox contract. Many installations use an external signer for securing the batch poster's key. While using an external signer is suported for signing batch transactions, it is not currently supported for signing the requests sent to the DA Committee. Currently, if you want to use an external signer for the batch transactions together with AnyTrust, you must generate a separate key for signing the requests sent to the DA Committee. If a wallet file is used the account must be named "l1-batch-poster".
+
+The batch poster would need to have the configuration for the external signer
+
+```
+--node.batch-poster.data-poster.external-signer...
+```
+
+and the configuration for the key which is only used for signing DA Committee requests.
+
+```
+--node.batch-poster.parent-chain-wallet...
+```
+
+The Committee servers would need to additionaly specify the public key to accept signed messages from.
+
+```
+--data-availability.extra-signature-checking-public-key
+```
+
 ## Other considerations
 
 - When using [nginx](https://www.nginx.com/) in the networking stack, a DAS might fail receiving batches that are over a certain size. If this happens, the DAS won't be able to sign any more certificates and the batch poster will receive an error `413 Request Entity Too Large`. To prevent this behavior, the parameter `client_max_body_size` from nginx configuration should be configured with a higher value than the default 1M. It's recommended to set it to at least 50M.