剥开比原看代码11：比原是如何经过接口/create-account建立账户的

时间  2019-11-26
标签 剥开 代码 原是 如何 经过 接口 create account 建立 账户 繁體版
原文   原文链接

做者：freewind前端

比原项目仓库：node

Github地址：https://github.com/Bytom/bytomgit

Gitee地址：https://gitee.com/BytomBlockchain/bytomgithub

在前面，咱们探讨了从浏览器的dashboard中进行注册的时候，数据是如何从前端发到后端的，而且后端是如何建立密钥的。而本文将继续讨论，比原是如何经过/create-account接口来建立账户的。web

在前面咱们知道在API.buildHandler中配置了与建立账户相关的接口配置：算法

api/api.go#L164-L244数据库

func (a *API) buildHandler() {
    // ...
    if a.wallet != nil {
        // ...
        m.Handle("/create-account", jsonHandler(a.createAccount))
        // ...

能够看到，/create-account对应的handler是a.createAccount，它是咱们本文将研究的重点。外面套着的jsonHandler是用来自动JSON与GO数据类型之间的转换的，以前讨论过，这里再也不说。json

咱们先看一下a.createAccount的代码：后端

api/accounts.go#L15-L30api

// POST /create-account
func (a *API) createAccount(ctx context.Context, ins struct {
    RootXPubs []chainkd.XPub `json:"root_xpubs"`
    Quorum    int            `json:"quorum"`
    Alias     string         `json:"alias"`
}) Response {

    // 1. 
    acc, err := a.wallet.AccountMgr.Create(ctx, ins.RootXPubs, ins.Quorum, ins.Alias)
    if err != nil {
        return NewErrorResponse(err)
    }

    // 2. 
    annotatedAccount := account.Annotated(acc)
    log.WithField("account ID", annotatedAccount.ID).Info("Created account")

    // 3.
    return NewSuccessResponse(annotatedAccount)
}

能够看到，它须要前端传过来root_xpubs、quorum和alias这三个参数，咱们在以前的文章中也看到，前端也的确传了过来。这三个参数，经过jsonHandler的转换，到这个方法的时候，已经成了合适的GO类型，咱们能够直接使用。

这个方法主要分红了三块：

  1. 使用a.wallet.AccountMgr.Create以及用户发送的参数去建立相应的账户
  2. 调用account.Annotated(acc)，把account对象转换成能够被JSON化的对象
  3. 向前端发回成功信息。该信息会被jsonHandler自动转为JSON发到前端，用于显示提示信息

第3步没什么好说的，咱们主要把目光集中在前两步，下面将依次结合源代码详解。

建立相应的账户

建立账户使用的是a.wallet.AccountMgr.Create方法，先看代码：

account/accounts.go#L145-L174

// Create creates a new Account.
func (m *Manager) Create(ctx context.Context, xpubs []chainkd.XPub, quorum int, alias string) (*Account, error) {
    m.accountMu.Lock()
    defer m.accountMu.Unlock()

    // 1.
    normalizedAlias := strings.ToLower(strings.TrimSpace(alias))

    // 2.
    if existed := m.db.Get(aliasKey(normalizedAlias)); existed != nil {
        return nil, ErrDuplicateAlias
    }

    // 3. 
    signer, err := signers.Create("account", xpubs, quorum, m.getNextAccountIndex())
    id := signers.IDGenerate()
    if err != nil {
        return nil, errors.Wrap(err)
    }

    // 4.
    account := &Account{Signer: signer, ID: id, Alias: normalizedAlias}

    // 5. 
    rawAccount, err := json.Marshal(account)
    if err != nil {
        return nil, ErrMarshalAccount
    }

    // 6. 
    storeBatch := m.db.NewBatch()
    accountID := Key(id)
    storeBatch.Set(accountID, rawAccount)
    storeBatch.Set(aliasKey(normalizedAlias), []byte(id))
    storeBatch.Write()

    return account, nil
}

咱们把该方法分红了6块，这里依次讲解：

  1. 把传进来的账户别名进行标准化修正，好比去掉两头空白并小写
  2. 从数据库中寻找该别名是否已经用过。由于账户和别名是一一对应的，账户建立成功后，会在数据库中把别名记录下来。因此若是能从数据库中查找，说明已经被占用，会返回一个错误信息。这样前台就能够提醒用户更换。
  3. 建立一个Signer，实际上就是对xpubs、quorum等参数的正确性进行检查，没问题的话会把这些信息捆绑在一块儿，不然返回错误。这个Signer我感受是检查过没问题签个字的意思。
  4. 把第3步建立的signer和id，还有前面的标准化以后的别名拿起来，放在一块儿，就组成了一个账户
  5. 把账户对象变成JSON，方便后面往数据库里存
  6. 把账户相关的数据保存在数据库，其中别名与id对应（方便之后查询别名是否存在），id与account对象（JSON格式）对应，保存具体的信息

这几步中的第3步中涉及到的方法比较多，须要再细致分析一下：

signers.Create

blockchain/signers/signers.go#L67-L90

// Create creates and stores a Signer in the database
func Create(signerType string, xpubs []chainkd.XPub, quorum int, keyIndex uint64) (*Signer, error) {
    // 1. 
    if len(xpubs) == 0 {
        return nil, errors.Wrap(ErrNoXPubs)
    }

    // 2.
    sort.Sort(sortKeys(xpubs)) // this transforms the input slice
    for i := 1; i < len(xpubs); i++ {
        if bytes.Equal(xpubs[i][:], xpubs[i-1][:]) {
            return nil, errors.WithDetailf(ErrDupeXPub, "duplicated key=%x", xpubs[i])
        }
    }

    // 3. 
    if quorum == 0 || quorum > len(xpubs) {
        return nil, errors.Wrap(ErrBadQuorum)
    }

    // 4.
    return &Signer{
        Type:     signerType,
        XPubs:    xpubs,
        Quorum:   quorum,
        KeyIndex: keyIndex,
    }, nil
}

这个方法能够分红4块，主要就是检查参数是否正确，仍是比较清楚的：

  1. xpubs不能为空
  2. xpubs不能有重复的。检查的时候就先排序，再看相邻的两个是否相等。我以为这一块代码应该抽出来，好比findDuplicated这样的方法，直接放在这里太过于细节了。
  3. 检查quorum，它是意思是“所需的签名数量”，它必须小于等于xpubs的个数，但不能为0。这个参数到底有什么用这个可能已经触及到比较核心的东西，放在之后研究。
  4. 把各信息打包在一块儿，称之为Singer

另外，在第2处仍是一个须要注意的sortKeys。它实际上对应的是type sortKeys []chainkd.XPub，为何要这么作，而不是直接把xpubs传给sort.Sort呢？

这是由于，sort.Sort须要传进来的对象拥有如下接口：

type Interface interface {
    // Len is the number of elements in the collection.
    Len() int
    // Less reports whether the element with
    // index i should sort before the element with index j.
    Less(i, j int) bool
    // Swap swaps the elements with indexes i and j.
    Swap(i, j int)
}

可是xpubs是没有的。因此咱们把它的类型从新定义成sortKeys后，就能够添加上这些方法了：

blockchain/signers/signers.go#L94-L96

func (s sortKeys) Len() int           { return len(s) }
func (s sortKeys) Less(i, j int) bool { return bytes.Compare(s[i][:], s[j][:]) < 0 }
func (s sortKeys) Swap(i, j int)      { s[i], s[j] = s[j], s[i] }

m.getNextAccountIndex()

而后是signers.Create("account", xpubs, quorum, m.getNextAccountIndex())中的m.getNextAccountIndex()，它的代码以下：

account/accounts.go#L119-L130

func (m *Manager) getNextAccountIndex() uint64 {
    m.accIndexMu.Lock()
    defer m.accIndexMu.Unlock()

    var nextIndex uint64 = 1
    if rawIndexBytes := m.db.Get(accountIndexKey); rawIndexBytes != nil {
        nextIndex = common.BytesToUnit64(rawIndexBytes) + 1
    }

    m.db.Set(accountIndexKey, common.Unit64ToBytes(nextIndex))
    return nextIndex
}

从这个方法能够看出，它用于产生自增的数字。这个数字保存在数据库中，其key为accountIndexKey（常量，值为[]byte("AccountIndex")），value的值第一次为1，以后每次调用都会把它加1，返回的同时把它也保存在数据库里。这样比原程序就算重启该数字也不会丢失。

signers.IDGenerate()

上代码：

blockchain/signers/idgenerate.go#L21-L41

//IDGenerate generate signer unique id
func IDGenerate() string {
    var ourEpochMS uint64 = 1496635208000
    var n uint64

    nowMS := uint64(time.Now().UnixNano() / 1e6)
    seqIndex := uint64(nextSeqID())
    seqID := uint64(seqIndex % 1024)
    shardID := uint64(5)

    n = (nowMS - ourEpochMS) << 23
    n = n | (shardID << 10)
    n = n | seqID

    bin := make([]byte, 8)
    binary.BigEndian.PutUint64(bin, n)
    encodeString := base32.HexEncoding.WithPadding(base32.NoPadding).EncodeToString(bin)

    return encodeString

}

从代码中能够看到，这个算法仍是至关复杂的，从注释上来看，它是要生成一个“不重复”的id。若是咱们细看代码中的算法，发现它没并有和咱们的密钥或者账户有关系，因此我不太明白，若是仅仅是须要一个不重复的id，为何不能直接使用如uuid这样的算法。另外这个算法是否有名字呢？已经提了issue向开发人员询问：https://github.com/Bytom/bytom/issues/926

如今能够回到咱们的主线a.wallet.AccountMgr.Create上了。关于建立账户的流程，上面已经基本讲了，可是还有一些地方咱们尚未分析：

  1. 上面屡次提到使用了数据库，那么使用的是什么数据库？在哪里进行了初始化？
  2. 这个a.wallet.AccountMgr.Create方法中对应的AccountMgr对象是在哪里构造出来的？

数据库与AccountMgr的初始化

比原在内部使用了leveldb这个数据库，从配置文件config.toml中就能够看出来：

$ cat config.toml
fast_sync = true
db_backend = "leveldb"

这是一个由Google开发的性能很是高的Key-Value型的NoSql数据库，比特币也用的是它。

比原在代码中使用它保存各类数据，好比区块、账户等。

咱们看一下，它是在哪里进行了初始化。

能够看到，在建立比原节点对象的时候，有大量的与数据库以及账户相关的初始化操做：

node/node.go#L59-L142

func NewNode(config *cfg.Config) *Node {
    // ...

    // Get store
    coreDB := dbm.NewDB("core", config.DBBackend, config.DBDir())
    store := leveldb.NewStore(coreDB)

    tokenDB := dbm.NewDB("accesstoken", config.DBBackend, config.DBDir())
    accessTokens := accesstoken.NewStore(tokenDB)

    // ...

    txFeedDB := dbm.NewDB("txfeeds", config.DBBackend, config.DBDir())
    txFeed = txfeed.NewTracker(txFeedDB, chain)

    // ...

    if !config.Wallet.Disable {
        // 1. 
        walletDB := dbm.NewDB("wallet", config.DBBackend, config.DBDir())
        // 2.
        accounts = account.NewManager(walletDB, chain)
        assets = asset.NewRegistry(walletDB, chain)
        // 3. 
        wallet, err = w.NewWallet(walletDB, accounts, assets, hsm, chain)
        // ...
    }
    // ...
}

那么咱们在本文中用到的，就是这里的walletDB，在上面代码中的数字1对应的地方。

另外，AccountMgr的初始化在也这个方法中进行了。能够看到，在第2处，生成的accounts对象，就是咱们前面提到的a.wallet.AccountMgr中的AccountMgr。这能够从第3处看到，accounts以参数形式传给了NewWallet生成了wallet对象，它对应的字段就是AccountMgr。

而后，当Node对象启动时，它会启动web api服务：

node/node.go#L169-L180

func (n *Node) OnStart() error {
    // ...
    n.initAndstartApiServer()
    // ...
}

在initAndstartApiServer方法里，又会建立API对应的对象：

node/node.go#L161-L167

func (n *Node) initAndstartApiServer() {
    n.api = api.NewAPI(n.syncManager, n.wallet, n.txfeed, n.cpuMiner, n.miningPool, n.chain, n.config, n.accessTokens)
    // ...
}

能够看到，它把n.wallet对象传给了NewAPI，因此/create-account对应的handlera.createAccount中才可使用a.wallet.AccountMgr.Create，由于这里的a指的就是api。

这样的话，与建立账户的流程及相关的对象的初始化咱们就都清楚了。

Annotated(acc)

下面就回到咱们的API.createAccount中的第2块代码：

// 2. 
    annotatedAccount := account.Annotated(acc)
    log.WithField("account ID", annotatedAccount.ID).Info("Created account")

咱们来看一下account.Annotated(acc)：

account/indexer.go#L27-L36

//Annotated init an annotated account object
func Annotated(a *Account) *query.AnnotatedAccount {
    return &query.AnnotatedAccount{
        ID:       a.ID,
        Alias:    a.Alias,
        Quorum:   a.Quorum,
        XPubs:    a.XPubs,
        KeyIndex: a.KeyIndex,
    }
}

这里出现的query指的是比原项目中的一个包blockchain/query，相应的AnnotatedAccount的定义以下：

blockchain/query/annotated.go#L57-L63

type AnnotatedAccount struct {
    ID       string           `json:"id"`
    Alias    string           `json:"alias,omitempty"`
    XPubs    []chainkd.XPub   `json:"xpubs"`
    Quorum   int              `json:"quorum"`
    KeyIndex uint64           `json:"key_index"`
}

能够看到，它的字段与以前咱们在建立账户过程当中出现的字段都差很少，不一样的是后面多了一些与json相关的注解。在后在前面的account.Annotated方法中，也是简单的把Account对象里的数字赋值给它。

为何须要一个AnnotatedAccount呢？缘由很简单，由于咱们须要把这些数据传给前端。在API.createAccount的最后，第3步，会向前端返回NewSuccessResponse(annotatedAccount)，因为这个值将会被jsonHandler转换成JSON，因此它须要有一些跟json相关的注解才行。

同时，咱们也能够根据AnnotatedAccount的字段来了解，咱们最后将会向前端返回什么样的数据。

到这里，咱们已经差很少清楚了比原的/create-account是如何根据用户提交的参数来建立账户的。

注：在阅读代码的过程当中，对部分代码进行了重构，主要是从一些大方法分解出来了一些更具备描述性的小方法，以及一些变量名称的修改，增长可读性。#924

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程