BCH’s recent token solutions have included wormholes and Keoken. Strictly speaking, wormholes and Keoken are smart contract platforms, and Token is only part of the functionality. Simple Ledger Protocol (SLP) is a Simple Ledger token scheme. The protocol was developed by Jonald Fyookball (Electron Cash Wallet developer and ChainBet protocol writer), James Cramer, Unwriter (Bitdb.Net Work developer), Mark B. Lundeberg, Co-authored by Calin Culianu and Ryan X. Charles (Yours.org CEO). Principle The basic principle of SLP is relatively simple, that is, the information such as the issuance and transfer of the token is written into OP_RETURN and carried in BCH transfer to realize the transfer of the token between different addresses. Logging token balance in UTXO mode Wormholes, Keoken, and SLP all reuse BCH addresses. The difference is that both Wormholes and Keoken are account-based, similar to Ethereum. SLP uses the same UTXO method as Bitcoin to record token balances. Four commands for Genesis Transaction: INIT is the equivalent of issuing a Token, carrying the Token’s abbreviation, full name, quantity, decimal number and other key parameters. These transfers represent the issuance of a certain number of tokens to the target address. The txID of the transfer is the unique number of the token, called the token ID. The Trands transfer also has a parameter called BATON Vout. This parameter indicates that the token can be issued. Otherwise, the number of tokens is fixed and the token cannot be issued. The BATON Vout parameter indicates which outputs in the Trands transfer can be used as input for additional transfer. Minting Transaction: MINT takes the output marked by the Baton Vout parameter in the Trands transfer as the input of this transfer, and carries the token ID, additional issue quantity and other parameters to issue a certain number of tokens to the target address. The BATON Vout parameter can also be carried in a secondary issue transfer, indicating which UTXO will be used as the input for the next secondary issue. Also, if this parameter is not present, it means that the token cannot be issued again. A Transfer Transaction is a Transfer of tokens from one address to another, like a BCH. The main parameters are token ID and the number of tokens given to each output. Since the balance is UTXO, all the tokens in the input will be spent, some of them will be forwarded to others, and the rest will be forwarded to your change address. This is not technically a transfer, but rather a proof of transfer for this token. The principle is to Hash the history of token transfers into a Merkle tree. This technology allows the wallet to verify the validity of a transfer without having to go back to the entire transfer history, improving the efficiency of the wallet to verify the validity of the transfer. This type of transfer is issued regularly by the token issuer, so the input address should be the same as the Input address of the Trands transfer to prove that it is issued by the token issuer.
Based on the description in the previous section, we can probably infer that all transfers of a token form a directed acyclic graph (DAG) like the one below.
Since BCH miners don’t double-flower tokens for security checks, a fake token transfer can also be written to the blockchain in a legal SLP format. For example, my address clearly does not have a certain token, but I can forge a transfer and transfer 10 tokens from my address to Zhang SAN. Joe’s wallet would need to check whether the transfer was legitimate by backtracking on all previous transfers. As the chart above shows, if the Trands transfer can’t be traced back, it’s a fake. When a wallet verifies whether a transfer is legitimate, there are several verification methods, representing four different security models. The wallet starts with the verified transfer and goes back to all previous transfers related to it, all the way back to the Trands transfer. If there are no problems along the path, then the transfer is valid. This method of verification is thorough enough to be safe. However, because the path may be very long, it consumes a lot of computing resources. Checkpoint Based Validation starts with the current transfer and goes back to the last verified transfer of the token. If the path is ok, the transfer is valid. This transfer check can make the check path shorter, less calculation. This method requires proof of trust transfer. Since the verification proof transfer is issued by the token issuer, the issuer has no reason to fabricate, and the transfer data is public and problems will be discovered quickly, so the risk of this trust is not great. Limited self-validation is similar to full self-validation, but only part of the transfer is backtracked. Verification requires less computation, but is risky, because a forger could trick a wallet using partial self-verification by orchestrating a chain of transfers with longer paths to make the transfers look legitimate over a backtracking path.
New Address Format If an SLP-enabled token is transferred to a wallet that does not support SLP, then the recipient may mistakenly transfer the token when transferring the BCH. To avoid such problems, SLP uses a new address format, SLP Addr. The new address format does not change the consensus, just requires infrastructure support such as wallets and exchanges. In addition, you can transfer a token to an old address using the address translation tool. Progress Now that the protocol is almost complete, the developers are preparing to integrate the token scheme into the Electron Cash wallet.
From K station Lao Liu