这篇文章探讨了区块链应用中密钥管理的重要性，特别是在持续向区块链发送交易的场景下，如Arbitrum的Sequencer和Chainlink的数据馈送，强调了安全使用和管理私钥的方法，包括通过配置文件和文件密钥，同时分析了密钥的安全等级以及如何在程序中有效保护密钥，最后以Arbitrum的具体实现为例，详细阐述了密钥的生成、使用和存储过程。
管理什么密钥？
在区块链应用的基础组件中通常有这样一种功能，需要持续不断的向区块链中发送交易，比如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 NewKeyStoreTransactorWithChainID(keystore *keystore.KeyStore, account accounts.Account, chainID *big.Int) (*TransactOpts, error) {
if chainID == nil {
return nil, ErrNoChainID
}
signer := types.LatestSignerForChainID(chainID)
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
}
