Bystack跨鏈技術源碼解讀

時間  2019-11-07
標籤 bystack 技術 源碼 解讀 简体版
原文   原文鏈接

Bystack是由比原鏈團隊提出的一主多側鏈架構的BaaS平臺。其將區塊鏈應用分爲三層架構：底層帳本層，側鏈擴展層，業務適配層。底層帳本層爲Layer1，即爲目前比較成熟的採用POW共識的Bytom公鏈。側鏈擴展層爲Layer2，爲多側鏈層，vapor側鏈即處於Layer2。node

(圖片來自Bystack白皮書)算法

Vapor側鏈採用DPOS和BBFT共識，TPS能夠達到數萬。此處就分析一下鏈接Bytom主鏈和Vapor側鏈的跨鏈模型。sql

主側鏈協同工做模型數據庫

一、技術細節數組

POW當前由於能源浪費而飽受詬病，並且POW自己在提升TPS的過程當中遇到諸多問題，理論上能夠把塊變大，能夠往塊裏面塞更多的交易。TPS是每秒出塊數*塊裏面的交易數。可是也存在問題：小節點吃不消存儲這麼大的容量的內容，會慢慢變成中心化的模式，由於只有大財團和大機構纔有財力去組建機房設備，成爲能出塊的節點。同時傳輸也存在問題，網絡帶寬是有限的，塊的大小與網絡傳輸的邊際是有關的，不可能無限的去增長塊的大小，網絡邊際上的人拿不到新塊的信息，也會下降去中心化的程度，這就是爲何POW不能在提升可靠性的狀況下，提升TPS的緣由。網絡

而BFT雖然去中心化較弱，但其效率和吞吐量高，也不須要大量的共識計算，很是環保節能，很符合Bystack側鏈高TPS的性能需求數據結構

(1)跨鏈模型架構架構

在Bystack的主側鏈協同工做模型中，包括有主鏈、側鏈和Federation。主鏈爲bytom，採用基於對AI 計算友好型PoW（工做量證實）算法，主要負責價值錨定，價值傳輸和可信存證。側鏈爲Vapor,採用DPOS+BBFT共識，高TPS知足垂直領域業務。主鏈和側鏈之間的資產流通主要依靠Federation。app

(2)節點類型ide

跨鏈模型中的節點主要有收集人、驗證人和聯邦成員。收集人監控聯邦地址，收集交易後生成Claim交易進行跨鏈。驗證人則是側鏈的出塊人。聯邦成員由側鏈的用戶投票經過選舉產生，負責生成新的聯邦合約地址。

(3)跨鏈交易流程

主鏈到側鏈

主鏈用戶將代幣發送至聯邦合約地址，收集人監控聯邦地址，發現跨鏈交易後生成Claim交易，發送至側鏈

側鏈到主鏈

側鏈用戶發起提現交易，銷燬側鏈資產。收集人監控側鏈至主鏈交易，向主鏈地址發送對應數量資產。最後聯邦在側鏈生成一筆完成提現的操做交易。

二、代碼解析

跨鏈代碼主要處於federation文件夾下，這裏就這部分代碼進行一個介紹。

(1)keeper啓動

整個跨鏈的關鍵在於同步主鏈和側鏈的區塊，並處理區塊中的跨鏈交易。這部份代碼主要在mainchain_keerper.go和sidechain_keerper.go兩部分中，分別對應處理主鏈和側鏈的區塊。keeper在Run函數中啓動。

func (m *mainchainKeeper) Run() {
	ticker := time.NewTicker(time.Duration(m.cfg.SyncSeconds) * time.Second)
	for ; true; <-ticker.C {
		for {
			isUpdate, err := m.syncBlock()
			if err != nil {
				//..
			}
			if !isUpdate {
				break
			}
		}
	}
}

Run函數中首先生成一個定時的Ticker，規定每隔SyncSeconds秒同步一次區塊，處理區塊中的交易。

(2)主側鏈同步區塊

Run函數會調用syncBlock函數同步區塊。

func (m *mainchainKeeper) syncBlock() (bool, error) {
	chain := &orm.Chain{Name: m.chainName}
	if err := m.db.Where(chain).First(chain).Error; err != nil {
		return false, errors.Wrap(err, "query chain")
	}

	height, err := m.node.GetBlockCount()
	//..
	if height <= chain.BlockHeight+m.cfg.Confirmations {
		return false, nil
	}

	nextBlockStr, txStatus, err := m.node.GetBlockByHeight(chain.BlockHeight + 1)
	//..
	nextBlock := &types.Block{}
	if err := nextBlock.UnmarshalText([]byte(nextBlockStr)); err != nil {
		return false, errors.New("Unmarshal nextBlock")
	}
	if nextBlock.PreviousBlockHash.String() != chain.BlockHash {
		//...
		return false, ErrInconsistentDB
	}

	if err := m.tryAttachBlock(chain, nextBlock, txStatus); err != nil {
		return false, err
	}

	return true, nil
}

這個函數受限會根據chainName從數據庫中取出對應的chain。而後利用GetBlockCount函數得到chain的高度。而後進行一個僞肯定性的檢測。

height <= chain.BlockHeight+m.cfg.Confirmations

主要是爲了判斷鏈上的資產是否已經不可逆。這裏Confirmations的值被設爲10。若是不進行這個等待不可逆的過程，極可能主鏈資產跨鏈後，主鏈的最長鏈改變，致使這筆交易沒有在主鏈被打包，而側鏈卻增長了相應的資產。在此以後，經過GetBlockByHeight函數得到chain的下一個區塊。

nextBlockStr, txStatus, err := m.node.GetBlockByHeight(chain.BlockHeight + 1)

這裏必須知足下個區塊的上一個區塊哈希等於當前chain中的這個頭部區塊哈希。這也符合區塊鏈的定義。

if nextBlock.PreviousBlockHash.String() != chain.BlockHash {
    //..
}

在此以後，經過調用tryAttachBlock函數進一步調用processBlock函數處理區塊。

(3)區塊處理

processBlock函數會判斷區塊中交易是否爲跨鏈的deposit或者是withdraw，並分別調用對應的函數去進行處理。

func (m *mainchainKeeper) processBlock(chain *orm.Chain, block *types.Block, txStatus *bc.TransactionStatus) error {
	if err := m.processIssuing(block.Transactions); err != nil {
		return err
	}

	for i, tx := range block.Transactions {
		if m.isDepositTx(tx) {
			if err := m.processDepositTx(chain, block, txStatus, uint64(i), tx); err != nil {
				return err
			}
		}

		if m.isWithdrawalTx(tx) {
			if err := m.processWithdrawalTx(chain, block, uint64(i), tx); err != nil {
				return err
			}
		}
	}

	return m.processChainInfo(chain, block)
}

在這的processIssuing函數，它內部會遍歷全部交易輸入Input的資產類型，也就是AssetID。當這個AssetID不存在的時候，則會去在系統中建立一個對應的資產類型。每一個Asset對應的數據結構以下所示。

m.assetStore.Add(&orm.Asset{
AssetID:           assetID.String(),
IssuanceProgram:   hex.EncodeToString(inp.IssuanceProgram),
VMVersion:         inp.VMVersion,
RawDefinitionByte: hex.EncodeToString(inp.AssetDefinition),
})

在processBlock函數中，還會判斷區塊中每筆交易是否爲跨鏈交易。主要經過isDepositTx和isWithdrawalTx函數進行判斷。

func (m *mainchainKeeper) isDepositTx(tx *types.Tx) bool {
	for _, output := range tx.Outputs {
		if bytes.Equal(output.OutputCommitment.ControlProgram, m.fedProg) {
			return true
		}
	}
	return false
}

func (m *mainchainKeeper) isWithdrawalTx(tx *types.Tx) bool {
	for _, input := range tx.Inputs {
		if bytes.Equal(input.ControlProgram(), m.fedProg) {
			return true
		}
	}
	return false
}

看一下這兩個函數，主要仍是經過比較交易中的control program這個標識和mainchainKeeper這個結構體中的fedProg進行比較，若是相同則爲跨鏈交易。fedProg在結構體中爲一個字節數組。

type mainchainKeeper struct {
	cfg        *config.Chain
	db         *gorm.DB
	node       *service.Node
	chainName  string
	assetStore *database.AssetStore
	fedProg    []byte
}

(4)跨鏈交易(主鏈到側鏈的deposit)處理

這部分主要分爲主鏈到側鏈的deposit和側鏈到主鏈的withdraw。先看比較複雜的主鏈到側鏈的deposit這部分代碼的處理。

func (m *mainchainKeeper) processDepositTx(chain *orm.Chain, block *types.Block, txStatus *bc.TransactionStatus, txIndex uint64, tx *types.Tx) error {
	//..

	rawTx, err := tx.MarshalText()
	if err != nil {
		return err
	}

	ormTx := &orm.CrossTransaction{
	      //..
	}
	if err := m.db.Create(ormTx).Error; err != nil {
		return errors.Wrap(err, fmt.Sprintf("create mainchain DepositTx %s", tx.ID.String()))
	}

	statusFail := txStatus.VerifyStatus[txIndex].StatusFail
	crossChainInputs, err := m.getCrossChainReqs(ormTx.ID, tx, statusFail)
	if err != nil {
		return err
	}

	for _, input := range crossChainInputs {
		if err := m.db.Create(input).Error; err != nil {
			return errors.Wrap(err, fmt.Sprintf("create DepositFromMainchain input: txid(%s), pos(%d)", tx.ID.String(), input.SourcePos))
		}
	}

	return nil
}

這裏它建立了一個跨鏈交易orm。具體的結構以下。能夠看到，這裏它的結構體中包括有source和dest的字段。

ormTx := &orm.CrossTransaction{
		ChainID:              chain.ID,
		SourceBlockHeight:    block.Height,
		SourceBlockTimestamp: block.Timestamp,
		SourceBlockHash:      blockHash.String(),
		SourceTxIndex:        txIndex,
		SourceMuxID:          muxID.String(),
		SourceTxHash:         tx.ID.String(),
		SourceRawTransaction: string(rawTx),
		DestBlockHeight:      sql.NullInt64{Valid: false},
		DestBlockTimestamp:   sql.NullInt64{Valid: false},
		DestBlockHash:        sql.NullString{Valid: false},
		DestTxIndex:          sql.NullInt64{Valid: false},
		DestTxHash:           sql.NullString{Valid: false},
		Status:               common.CrossTxPendingStatus,
	}

建立這筆跨鏈交易後，它會將交易存入數據庫中。

if err := m.db.Create(ormTx).Error; err != nil {
		return errors.Wrap(err, fmt.Sprintf("create mainchain DepositTx %s", tx.ID.String()))
}

在此以後，這裏會調用getCrossChainReqs。這個函數內部較爲複雜，主要做用就是遍歷交易的輸出，返回一個跨鏈交易的請求數組。具體看下這個函數。

func (m *mainchainKeeper) getCrossChainReqs(crossTransactionID uint64, tx *types.Tx, statusFail bool) ([]*orm.CrossTransactionReq, error) {
	//..
	switch {
	case segwit.IsP2WPKHScript(prog):
		//..
	case segwit.IsP2WSHScript(prog):
		//..
	}

	reqs := []*orm.CrossTransactionReq{}
	for i, rawOutput := range tx.Outputs {
		//..

		req := &orm.CrossTransactionReq{
			//..
		}
		reqs = append(reqs, req)
	}
	return reqs, nil
}

很顯然，這個地方的交易類型有pay to public key hash 和 pay to script hash這兩種。這裏會根據不一樣的交易類型進行一個地址的獲取。

switch {
	case segwit.IsP2WPKHScript(prog):
		if pubHash, err := segwit.GetHashFromStandardProg(prog); err == nil {
			fromAddress = wallet.BuildP2PKHAddress(pubHash, &vaporConsensus.MainNetParams)
			toAddress = wallet.BuildP2PKHAddress(pubHash, &vaporConsensus.VaporNetParams)
		}
	case segwit.IsP2WSHScript(prog):
		if scriptHash, err := segwit.GetHashFromStandardProg(prog); err == nil {
			fromAddress = wallet.BuildP2SHAddress(scriptHash, &vaporConsensus.MainNetParams)
			toAddress = wallet.BuildP2SHAddress(scriptHash, &vaporConsensus.VaporNetParams)
		}
	}

在此以後，函數會遍歷全部交易的輸出，而後建立跨鏈交易請求，具體的結構以下。

req := &orm.CrossTransactionReq{
   CrossTransactionID: crossTransactionID,
   SourcePos:          uint64(i),
   AssetID:            asset.ID,
   AssetAmount:        rawOutput.OutputCommitment.AssetAmount.Amount,
   Script:             script,
   FromAddress:        fromAddress,
   ToAddress:          toAddress,
   }

建立完全部的跨鏈交易請求後，返回到processDepositTx中一個crossChainInputs數組中，並存入db。

for _, input := range crossChainInputs {
		if err := m.db.Create(input).Error; err != nil {
			return errors.Wrap(err, fmt.Sprintf("create DepositFromMainchain input: txid(%s), pos(%d)", tx.ID.String(), input.SourcePos))
		}
}

到這裏，對主鏈到側鏈的deposit已經處理完畢。

(5)跨鏈交易(側鏈到主鏈的withdraw)交易處理

這部分比較複雜的邏輯主要在sidechain_keeper.go中的processWithdrawalTx函數中。這部分邏輯和上面主鏈到側鏈的deposit邏輯相似。一樣是建立了orm.crossTransaction結構體，惟一的改變就是交易的souce和dest相反。這裏就不做具體描述了。

三、跨鏈優缺點

優勢

(1) 跨鏈模型、代碼較爲完整。當前有不少項目使用跨鏈技術，可是真正實現跨鏈的寥寥無幾。

(2) 能夠根據不一樣需求實現側鏈，知足多種場景

缺點

(1) 跨鏈速度較慢，需等待10個區塊確認，這在目前Bytom網絡上所需時間爲30分鐘左右

(2) 相較於comos、polkadot等項目，開發者要開發側連接入主網成本較大

(3) 只支持資產跨鏈，不支持跨鏈智能合約調用

**四、**跨鏈模型平行對比Cosmos

可擴展性

bystack的主測鏈協同工做模型依靠Federation，未造成通用協議。其餘開發者想要接入其跨鏈網絡難度較大。Cosmos採用ibc協議，可擴展性較強。

代碼開發進度

vapor側鏈已經可以實現跨鏈。Cosmos目前暫無成熟跨鏈項目出現，ibc協議處於最終開發階段。

跨鏈模型

vapor爲主側鏈模型，Cosmos爲Hub-Zone的中繼鏈模型。

五、參考建議

側鏈使用bbft共識，非POW的狀況下，無需等待10個交易確認，增快跨鏈速度。

做者：詩人

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程