在本系列前幾部分奠定的基礎上，在本文中將演示如何在位元幣中實作相對鎖定時間，而無需新的操作碼 OP_CheckSequenceVerify，

時間鎖

時間鎖會限制某些位元幣的支出，直到指定的未來時間或區塊高度，有兩種型別的時間鎖：

1. 絕對時間鎖：例如，可以鎖定 1 個位元幣，直到區塊高度 800,000，或直到 2025 年 1 月 1 日后可解鎖使用，
2. 相對時間鎖：例如，可以鎖定 1 個位元幣，只能在 100 個區塊或 3 天后可解鎖使用，

為了啟用絕對和相對時間鎖，BIP65 和 BIP68/112/113 中分別引入了新的操作碼 OP_CheckLockTimeVerify/OP_CLTV 和 OP_CheckSequenceVerify/OP_CSV，

沒有 OP_CSV 的相對鎖定時間

位元幣SV恢復了原有的位元幣協議，恢復了上述變化，而事實證明 OP_CSV 可以用原始協議實作，

在第 1 部分中，我們展示了如何訪問包含給定合約 UTXO 的塊，結合這個區塊頭和指定的相對時間鎖，我們可以知道該 UTXO 可以被花費的最早區塊，我們要求在截止日期之后的任何塊都可用于解鎖 UTXO，本質上是像 OP_CSV 那樣在其上放置一個相對時間鎖，

下面列出了完整的代碼，

import "blockchain.scrypt";

// relative locktime, aka, OP_CheckSequenceVerify https://en.bitcoin.it/wiki/Timelock#CheckSequenceVerify
contract CheckSequenceVerify {
    // relative timelock: specified in either unix time or block height
    int relativeTime;
    // maximal target for any block to be considered valid
    int blockchainTarget;

    // unlock based on unix timestamp
    public function unlockWithTime(BlockHeader utxoBh, BlockHeader latestBh, MerkleProof merkleproof, SigHashPreimage txPreimage) {
        this.validateHelper(utxoBh, latestBh, merkleproof, txPreimage);

        // enough time has elapsed since the UTXO is mined
        require(latestBh.time - utxoBh.time >= this.relativeTime);
    }

    // unlock based on block height
    public function unlockWithBlockHeight(BlockHeader utxoBh, BlockHeader latestBh, MerkleProof utxoMerkleproof, MerkleProof latestMerkleproof,
        bytes utxoCoinbaseTx, bytes latestCoinbaseTx, MerkleProof merkleproof, SigHashPreimage txPreimage) {
        this.validateHelper(utxoBh, latestBh, merkleproof, txPreimage);

        // get block height from header
        int utxoBlockHeight = Blockchain.blockHeight(utxoBh, utxoCoinbaseTx, utxoMerkleproof);
        int latestBlockHeight = Blockchain.blockHeight(latestBh, latestCoinbaseTx, latestMerkleproof);

        require(latestBlockHeight - utxoBlockHeight >= this.relativeTime);
    }

    // common validation for both relative timelock: Unix timestamp and block height
    // @utxoBh: block header containing the UTXO containing the contract
    // @latestBh: latest block header
    function validateHelper(BlockHeader utxoBh, BlockHeader latestBh, MerkleProof merkleproof, SigHashPreimage txPreimage) : bool {
        require(Tx.checkPreimage(txPreimage));
        // get id of previous tx
        Sha256 prevTxid = Sha256(SigHash.outpoint(txPreimage)[: 32]);
        // verify previous tx is in the block
        require(Blockchain.txInBlock(prevTxid, utxoBh, merkleproof));

        // validate block headers
        require(Blockchain.isBlockHeaderValid(utxoBh, this.blockchainTarget));
        require(Blockchain.isBlockHeaderValid(latestBh, this.blockchainTarget));

        return true;
    }
}

第 12 行實作了基于 unix 時間（例如，以秒為單位）的解鎖，第 33 行的 validateHelper() 函式驗證包含 UTXO 的塊和最新的塊是否有效（第 41-42 行），它還使用與第 1 部分中相同的技術驗證前一個塊實際上包含 UTXO（第 34-38 行），第 15 行確保自挖出 UTXO 后所需的時間已經過去，

第 19 行實作了基于區塊高度（例如，區塊數量）的解鎖，第 24-25 行獲取兩個塊的高度，如 第 3 部分 所述，第 27 行檢查在 UTXO 之后已經開采了指定數量的區塊，

總結

除了 OP_CSV 之外，我們之前已經實作了 OP_CLTV，而沒有對原始位元幣協議進行任何更改，這有兩個含義：

1. 如前所述，這兩個操作碼都不是啟用 UTXO 級時間鎖所必需的，
2. OP_CSV/CLTV 支持的所有用例，例如閃電網路、側鏈和 CLTV 風格的支付渠道，都可以直接構建在原始位元幣上，