管理什么密钥？
在区块链应用的基础组件中通常有这样一种功能，需要持续不断的向区块链中发送交易，比如arbitrum的Sequencer需要持续不断的发送L2的区块，stark 需要发送单步证明/rBlock发布 的交易，chainlink需要定时发送datafeed交易。而这每一笔交易都需要L1上的账户做签名，如何安全的使用和管理这个密钥是值得关心的。
结论
就我所看到的一般有两种方式：
- 通过配置文件配置私钥
- 使用filekey的方式：
- 注意file一般需要一个密码，密码是启动后在终端控制台输入
当然，密钥管理不只是简单的将密钥注入到程序里面，而是如何在程序里面安全的使用这些密钥，毕竟如果密钥发在一个可能被外部接口调用的接口中，可能会降低密钥的安全性。
密钥安全等级（依次递减，只考虑加密算法公开的情况）：
- 黑客无法得知任何明文&密文
- 黑客可以得到密文
- 黑客可以得到密文对应的明文
- 黑客可以自行构造明文产生密文
所以在程序中也需要对密钥进行保护。
以太坊中每次使用完私钥会将私钥的地址还原成0地址，就是为了避免私钥在内存中泄漏。
私钥泄漏的原理大致是，geth程序在使用玩内存后会释放内存，而他释放内存并不会把内存值全部置0,而只是告诉操作系统，“这段内存我不用了，你可以分配给别的程序” 。而别的程序申请到这段内存之后，他是可以直接读取这段内存里的值，（经典案例就是 在c语言中如果你初始化一个变量，而不为赋值，那他的值不是0值，而是原先在这个值里面的内存的值）
arbitrum的处理方案
先从最底层的调用开始看
在单步证明的调用中可以看到，这笔交易的用户信息是保存在auth字段中的
func (m *ChallengeManager) IssueOneStepProof( ctx context.Context, oldState *ChallengeState, startSegment int, ) (*types.Transaction, error) { position := oldState.Segments[startSegment].Position proof, err := m.executionChallengeBackend.GetProofAt(ctx, position) if err != nil { return nil, fmt.Errorf("error getting OSP from challenge %v backend at step %v: %w", m.challengeIndex, position, err) } return m.challengeCore.con.OneStepProveExecution( m.challengeCore.auth, // 用户信息保存在这个字段 m.challengeCore.challengeIndex, challengegen.ChallengeLibSegmentSelection{ OldSegmentsStart: oldState.Start, OldSegmentsLength: new(big.Int).Sub(oldState.End, oldState.Start), OldSegments: oldState.RawSegments, ChallengePosition: big.NewInt(int64(startSegment)), }, proof, ) } 具体如何使用可以继续点进去看，最终是auth中包含一个变量（函数类型的变量），由这个变量进行签名，（我们需要找到的这个函数的生命周期，也就是密钥的生命周期）。
那么继续往上看，看这个challengeManager的构造方法
func NewChallengeManager( ctx context.Context, l1client bind.ContractBackend, auth *bind.TransactOpts, fromAddr common.Address, challengeManagerAddr common.Address, challengeIndex uint64, val *StatelessBlockValidator, startL1Block uint64, confirmationBlocks int64, ) (*ChallengeManager, error) { ... return &ChallengeManager{ challengeCore: &challengeCore{ con: con, challengeManagerAddr: challengeManagerAddr, challengeIndex: challengeIndex, client: l1client, auth: auth, // 也就是上面的auth actingAs: fromAddr, startL1Block: new(big.Int).SetUint64(startL1Block), confirmationBlocks: confirmationBlocks, }, blockChallengeBackend: backend, validator: val, wasmModuleRoot: challengeInfo.WasmModuleRoot, maxBatchesRead: challengeInfo.MaxInboxMessages, }, nil } 可以看到auth是上面传递过来的bind.ContractOpts
继续往上面看,auth来自与Builder这个结构，好在这个结构的构造函数只被调用过一次（我们及假设唯一的构造得到的auth就是我们要找的auth，中间没有发生更改）
func NewBuilder(wallet ValidatorWalletInterface) (*Builder, error) { randKey, err := crypto.GenerateKey() if err != nil { return nil, err } builderAuth := wallet.AuthIfEoa() var isAuthFake bool if builderAuth == nil { // Make a fake auth so we have txs to give to the smart contract wallet builderAuth, err = bind.NewKeyedTransactorWithChainID(randKey, big.NewInt(9999999)) if err != nil { return nil, err } isAuthFake = true } return &Builder{ builderAuth: builderAuth, wallet: wallet, L1Interface: wallet.L1Client(), isAuthFake: isAuthFake, }, nil } builder的auth有两种途径，一种是 AuthIfEoa 也就是从eoa中解析私钥，一种是自己生成私钥
那么关键在与这里的wallet是什么（也就是现在从跟踪auth转移到跟踪wallet）
最终发现wallet在creatNoteImpl方法里面构造的
var wallet staker.ValidatorWalletInterface = validatorwallet.NewNoOp(l1client, deployInfo.Rollup) if !strings.EqualFold(config.Staker.Strategy, "watchtower") { if config.Staker.UseSmartContractWallet || (txOptsValidator == nil && config.Staker.DataPoster.ExternalSigner.URL == "") {// 合约账户 var existingWalletAddress *common.Address if len(config.Staker.ContractWalletAddress) > 0 { if !common.IsHexAddress(config.Staker.ContractWalletAddress) { log.Error("invalid validator smart contract wallet", "addr", config.Staker.ContractWalletAddress) return nil, errors.New("invalid validator smart contract wallet address") } tmpAddress := common.HexToAddress(config.Staker.ContractWalletAddress) existingWalletAddress = &tmpAddress } wallet, err = validatorwallet.NewContract(dp, existingWalletAddress, deployInfo.ValidatorWalletCreator, deployInfo.Rollup, l1Reader, txOptsValidator, int64(deployInfo.DeployedAt), func(common.Address) {}, getExtraGas) if err != nil { return nil, err } } else { if len(config.Staker.ContractWalletAddress) > 0 { return nil, errors.New("validator contract wallet specified but flag to use a smart contract wallet was not specified") } wallet, err = validatorwallet.NewEOA(dp, deployInfo.Rollup, l1client, getExtraGas) if err != nil { return nil, err } } } 继续跟踪我们得到wellet中的验证方法是由txOptsValidator提供的
向上继续找txOptsValidator
最重找到mainImpl
if sequencerNeedsKey || nodeConfig.Node.BatchPoster.ParentChainWallet.OnlyCreateKey { l1TransactionOptsBatchPoster, dataSigner, err = util.OpenWallet("l1-batch-poster", &nodeConfig.Node.BatchPoster.ParentChainWallet, new(big.Int).SetUint64(nodeConfig.ParentChain.ID)) if err != nil { flag.Usage() log.Crit("error opening Batch poster parent chain wallet", "path", nodeConfig.Node.BatchPoster.ParentChainWallet.Pathname, "account", nodeConfig.Node.BatchPoster.ParentChainWallet.Account, "err", err) } if nodeConfig.Node.BatchPoster.ParentChainWallet.OnlyCreateKey { return 0 } } if validatorNeedsKey || nodeConfig.Node.Staker.ParentChainWallet.OnlyCreateKey { l1TransactionOptsValidator, _, err = util.OpenWallet("l1-validator", &nodeConfig.Node.Staker.ParentChainWallet, new(big.Int).SetUint64(nodeConfig.ParentChain.ID)) if err != nil { flag.Usage() log.Crit("error opening Validator parent chain wallet", "path", nodeConfig.Node.Staker.ParentChainWallet.Pathname, "account", nodeConfig.Node.Staker.ParentChainWallet.Account, "err", err) } if nodeConfig.Node.Staker.ParentChainWallet.OnlyCreateKey { return 0 } } 我们得到l1TransactionOptsValidator是使用nodeConfig.Node.Staker.ParentChainWallet 这个配置项得到的.
最终的数据结构张这个样子
type WalletConfig struct { Pathname string `koanf:"pathname"` Password string `koanf:"password"` PrivateKey string `koanf:"private-key"` Account string `koanf:"account"` OnlyCreateKey bool `koanf:"only-create-key"` } 继续点到OpenWallet可以看到他是如何处理这些配置项的
在有私钥的情况下最终会走到这个方法
func NewKeyedTransactorWithChainID(key *ecdsa.PrivateKey, chainID *big.Int) (*TransactOpts, error) { keyAddr := crypto.PubkeyToAddress(key.PublicKey) if chainID == nil { return nil, ErrNoChainID } signer := types.LatestSignerForChainID(chainID) return &TransactOpts{ From: keyAddr, Signer: func(address common.Address, tx *types.Transaction) (*types.Transaction, error) { // signer就是我们一直再找的在发送交易时使用到的签名方法 if address != keyAddr { return nil, ErrNotAuthorized } signature, err := crypto.Sign(signer.Hash(tx).Bytes(), key) if err != nil { return nil, err } return tx.WithSignature(signer, signature) }, Context: context.Background(), }, nil } 从这里看出来，私钥始终保存在signer这个方法中，在整个使用过程中没有将私钥作为参数传递的情况。
如果使用的是filekey+密码的情况会进入到这个方法
func NewKeyStoreTransactor(keystore *keystore.KeyStore, account accounts.Account) (*TransactOpts, error) { log.Warn("WARNING: NewKeyStoreTransactor has been deprecated in favour of NewTransactorWithChainID") signer := types.HomesteadSigner{} return &TransactOpts{ From: account.Address, Signer: func(address common.Address, tx *types.Transaction) (*types.Transaction, error) { if address != account.Address { return nil, ErrNotAuthorized } signature, err := keystore.SignHash(account, signer.Hash(tx).Bytes()) if err != nil { return nil, err } return tx.WithSignature(signer, signature) }, Context: context.Background(), }, nil } 程序会根据filekey构造一个keystore,后续签名都是在keystore中签名
注意filekey的密码是在终端控制台输入的,其中的readPass函数如下
func readPass() (string, error) { bytePassword, err := term.ReadPassword(syscall.Stdin) if err != nil { return "", err } passphrase := string(bytePassword) passphrase = strings.TrimSpace(passphrase) return passphrase, nil } 
