Bitcoin Computer——Token合約

前面介紹了Bitcoin Computer的原理以及如何發送位元幣，這次介紹Token方案，要理解本文，需要先閱讀前兩篇文章，

創建合約

先來看示例代碼

import Computer from 'bitcoin-computer';

class Token{
    constructor(supply, to) {
        this.tokens = supply;
        this._owners = [to];
    }

    send(amount, to){
        if(this.tokens < amount){
            throw new Error(`Not enough tokens: ${amount} < ${this.tokens}`);
        }

        this.tokens -= amount;
        return new Token(amount, to);
    }
}

(async () => {
    const computerA = new Computer.default({
        seed: 'seed of computer A',
        chain: 'BSV',
        network: 'testnet'
    });

    let tokens = await computerA.new(Token, [100, computerA.db.wallet.getPublicKey().toString()]);
    console.log(tokens);
})();

1. 首先定一個了一個名為Token的智能合約，
   • 成員變數tokens表示token數量；成員變數_owners表示這些數量的token屬于誰，
   • 建構式有兩個引數，supply表示該合約實體有多少個token，to是token擁有者的公鑰，如果是首次創建合約，那么supply表示token總量是多少，
   • send方法用于發送token，amount引數表示發送多少，to引數是接收方的公鑰，
2. 創建Computer實體computerA，
3. computerA創建Token合約，總量100，發放到自己的公鑰里，

運行結果：

Token {
   tokens: 100,
       _owners: [
       '03367b59cc6ba5cdb93b3bdc61c7018655462251b3608383c5a1b4adcf5f1bcc1f'
   ],
       _id: '37e47c71219a0f7f3b80c04b24bbfa4613364cb1a81a9b166a33178c375ba628:0',
       _rev: '37e47c71219a0f7f3b80c04b24bbfa4613364cb1a81a9b166a33178c375ba628:0',
       _rootId: '37e47c71219a0f7f3b80c04b24bbfa4613364cb1a81a9b166a33178c375ba628:0'
}

可以在區塊瀏覽器查看這筆轉賬，如果你讀了前兩篇文章，可以猜測出合約輸出的內容，為了方便查看，我使用ASM格式的腳本，但把其中的可見字串部分直接用UTF8格式表示：

1
03367b59cc6ba5cdb93b3bdc61c7018655462251b3608383c5a1b4adcf5f1bcc1f
1
OP_CHECKMULTISIG

{"__cls":"class Token{\n constructor(supply, to) {\n this.tokens = supply;\n this._owners = [to];\n }\n\n send(amount, to){\n if(this.tokens < amount){\n throw new Error(`Not enough tokens: ${amount} < ${this.tokens}`);\n }\n\n this.tokens -= amount;\n return new Token(amount, to);\n }\n}","__index":{"obj":0},"__args":[100,"03367b59cc6ba5cdb93b3bdc61c7018655462251b3608383c5a1b4adcf5f1bcc1f"],"__func":"constructor"}

OP_DROP

多簽名的公鑰為ComputerA的公鑰，合約資料部分為Token類的定義，以及建構式名稱及運行引數，表示用建構式和引數創建了一個合約實體，

token轉賬

const computerB = new Computer.default({
        seed: 'seed of computer B',
        chain: 'BSV',
        network: 'testnet'
    });
await tokens.send(10, computerB.db.wallet.getPublicKey().toString());
    console.log(tokens);

1. 創建另一個Computer實體computerB，
2. computerA把10個token轉給computerB，

運行結果：

Token {
    tokens: 90,
        _owners: [
        '03367b59cc6ba5cdb93b3bdc61c7018655462251b3608383c5a1b4adcf5f1bcc1f'
    ],
        _id: '37e47c71219a0f7f3b80c04b24bbfa4613364cb1a81a9b166a33178c375ba628:0',
        _rev: '171c0c8713b8c8a97c556b286c95b821e0ff64170b681c946d4123aee9134e79:0',
        _rootId: '37e47c71219a0f7f3b80c04b24bbfa4613364cb1a81a9b166a33178c375ba628:0'
}

可以看到，轉賬結束后，computerA的token數量還剩下90，

通過區塊鏈瀏覽器查看這個tx，輸出結構上跟以往的例子有些不一樣，以往的合約都有兩個輸出，一個合約輸出，一個找零輸出，而這個token轉賬tx有三個輸出，其中第三個是找零，接下來詳細看看前兩個輸出，

輸出0

1
03367b59cc6ba5cdb93b3bdc61c7018655462251b3608383c5a1b4adcf5f1bcc1f
1
OP_CHECKMULTISIG

{"__index":{"obj":0,"res":1},"__args":[10,"02c9788a60264523ba77500e19a0b2626c9b09b25daa16cfee09b4e1135d610c90"],"__func":"send"}

OP_DROP

很明顯這是一個合約運行輸出腳本，多簽名的公鑰是computerA的，資料部分是合約運行的函式和引數，
跟以往例子不同的是，合約資料中的__index欄位里多了一個res欄位，值為1，因為開發者并沒有公布協議，所以并不能準確知道這個欄位的含義，我猜測這里的1表示輸出1：這個合約的運行給輸出1提供了一些必要資訊，

輸出1

1
02c9788a60264523ba77500e19a0b2626c9b09b25daa16cfee09b4e1135d610c90
1
OP_CHECKMULTISIG

{"__cls":"class Token{\n constructor(supply, to) {\n this.tokens = supply;\n this._owners = [to];\n }\n\n send(amount, to){\n if(this.tokens < amount){\n throw new Error(`Not enough tokens: ${amount} < ${this.tokens}`);\n }\n\n this.tokens -= amount;\n return new Token(amount, to);\n }\n}"}

OP_DROP

這個輸出的多簽名公約是computerB的，所以應該表示一部分token轉到了computerB名下，合約資料部分是一份Token類的定義，

到這里，需要再看看Token類中send方法的實作，其中真正的轉賬代碼是通過再創建一個Token類實體來實作的，建構式的引數就是發送數量和接收者公鑰，所以，我猜測，合約代碼中這行代碼的邏輯體現在tx中就是這個輸出，

同時，合約資料中并沒有出現合約創建tx輸出中的__args和__func欄位，__args欄位應該是來自輸出0中的__args，這也就是我們前面說到的輸出0給輸出1提供了必要資訊，

computerB的視角

前面我們用computerA的token實體轉完賬后，token數量還剩90，接下來我們用compuerB把轉賬tx同步下來，用它的視角來看看token的數量，
因為輸出1才是屬于computerB的，所以首先先把版本號的outputIndex部分改為1，然后再進行同步，

const computerBTokenRev = tokens._rev.split(':')[0]+':1';

tokens = await computerB.sync(computerBTokenRev);
console.log(tokens);

運行后tokens變數的值為：

Token {
    tokens: 10,
        _owners: [
        '02c9788a60264523ba77500e19a0b2626c9b09b25daa16cfee09b4e1135d610c90'
    ],
        _rev: '171c0c8713b8c8a97c556b286c95b821e0ff64170b681c946d4123aee9134e79:1',
        _id: '171c0c8713b8c8a97c556b286c95b821e0ff64170b681c946d4123aee9134e79:1',
        _rootId: '37e47c71219a0f7f3b80c04b24bbfa4613364cb1a81a9b166a33178c375ba628:0'
}

屬于computerB的token數量為10，跟預期一致，
同時還發現一個有意思的現象：_id欄位不再是合約部署的outPoint，而是轉賬tx的輸出1，而_rootId欄位仍然是合約部署的outPoint，因此，我猜測_rootId表示部署合約的outPoint，_id表示當前合約實體開始創建的outPoint（屬于compuerB的合約實體在部署時還沒有，在compuerA轉賬后才出現），

安全性

上鏈前保護

Token方案的首要安全性是對token數量的計算是否正確，我們沿用上面的程式繼續對安全性進行測驗，

tokens = await computerA.sync('171c0c8713b8c8a97c556b286c95b821e0ff64170b681c946d4123aee9134e79:0');
tokens.send(91, computerB.db.wallet.getPrivateKey().toString());

1. computerA把它的合約UTXO同步下來，此時還剩90個token，
2. 嘗試給computerB轉出91個token，

運行時拋出了一個例外：

UnhandledPromiseRejectionWarning: Error: Not enough tokens: 91 < 90

仔細看send函式的實作，最開始就是對token數量的保護，如果實體沒有那么多token，就拋出了例外，并跳出了send函式的運行，也就是說會發送失敗，從而在上鏈前就保證了token數量的正確，
所以，Bitcoin Computer用Javascript的例外功能巧妙地對合約的安全性進行了保護，

上鏈后保護

如果手工構造一筆不合法的轉賬，是否可以突破token數量的例外保護呢？我構造了一筆轉賬，標記computerA給computerB轉了91個token，實際上computerA只有90個，

{
  "__index":{"obj":0,"res":1},
  "__args":[91,"02c9788a60264523ba77500e19a0b2626c9b09b25daa16cfee09b4e1135d610c90"],
  "__func":"send"
}

對于已經在鏈上的非法轉賬，我們看Bitcoin Computer會如何表現：

const tokens = await computerA.sync('51bdee16d6b452aec909908c228c355ab7ca7bc311952ce7897d5e9bfa2fcb3d:0');
console.log(tokens);

computerA從記載非法轉賬記錄的outPoint加載合約資料，運行程式，拋出了如下例外：

UnhandledPromiseRejectionWarning: Error: Not enough tokens: 91 < 90

再來看看computerB加載非法轉賬會如何表現：

const tokens = await computerB.sync('51bdee16d6b452aec909908c228c355ab7ca7bc311952ce7897d5e9bfa2fcb3d:1');
console.log(tokens);

代碼運行時仍然拋出了例外：

UnhandledPromiseRejectionWarning: Error: Not enough tokens: 91 < 90

綜上，雖然不合法的合約資料可以手動寫入鏈上，但在運行Javascript合約代碼時，合約可以檢查出邏輯錯誤，并拋出例外，程式停止運行，

總結

Bitcoin Computer的Token合約雖然簡短，但實作上比較精巧：

1. 通過創建新的合約實體實作轉賬，
2. 直接用Javascript代碼對token數量進行保護，

后記

寫完了三篇關于Bitcoin Computer的介紹文章，這個系列就暫告一斷落了，

由于Bitcoin Computer的協議并沒有公開，我只是憑經驗和測驗來猜測Bitcoin Computer的運行原理，細節不一定準確，歡迎大家一起交流，同時也希望開發者可以盡快公布協議，對于二層合約方案來說，協議的公開性是必須的，否則無法滿足用戶的安全需求，

另外，有一個原理類似的二層合約方案Run，該方案只運行在BSV鏈，RelayX基于該方案發布了USDC Token，最初我是想介紹這個方案的，但由于該方案沒有公開代碼和檔案，所以選擇了Bitcoin Computer，希望Run也可以盡快公布自己的協議、檔案和代碼，