管理什麼金鑰？
在區塊鏈應用的基礎元件中通常有這樣一種功能，需要持續不斷的向區塊鏈中傳送交易，比如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
}