Introducing Zclassic Simple Ledger Protocol

The next generation token management system on Zclassic

A blockchain is a distributed ledger that is usually managed by a peer-to-peer network. In a distributed ledger, transactions are organized into blocks that are linked together into a chain. Once transactions are validated, they become irreversible, verifiable, permanent, and secure on the blockchain. Because of these characteristics, blockchain technology is well-suited for empowering financial transactions. As blockchain technology advances, it becomes capable of tokenizing and decentralizing not only money but also other scarce assets, significantly expanding its disruptive potential.

Today, tokens have a number of use cases both for individuals and organizations. Tokens can be used anywhere from rewarding your followers, to the creation of stocks, securities, registries, smart properties, utility tokens, contracts, coupons, bonds, demand deposits, local currencies, representation of physical assets, representation of individuals and much more. With so many use cases in the bag, we believe the creation and distribution of tokens should be simple, easy and available to all members of the ecosystem to reap out real use cases and innovation.

Challenges in creating a token management system on Zclassic

Creating a tokens management system on Zclassic faces some challenges as the underlying protocol was not intended for creating and management of tokens from the genesis. Some of the challenges faced for creation of simple yet trustless token management system are as follows :-

• Users should be able to validate token transactions without changes in the underlying protocol and consensus.
• Using standard OP_RETURN for the token transfer and management will allow any arbitrary user to create a token-transfer transaction and have it validated without actually holding the tokens.
• Metadata with the transactions is not validated by the miners, making almost no clear separation between valid and invalid data. This would create a low fault tolerant environment.
• The Zclassic transactions are committed to the blockchain but second layer transactions are not.
• To prove token transactions are valid, it is necessary to validate all prior transactions starting from the token genesis.

How do ZSLP transactions work?

Zclassic Simple Ledger Protocol (ZSLP) utilizes the metadata in OP_RETURN for issuing and transfer of tokens simultaneously with standard transaction outputs. Each ZSLP transaction represents a number of token units specified by the sender. Consensus on the interpretation of the OP_RETURN outputs is achieved by token users and market participants following an ordered set of simple rules. Full validation of a transaction back to its token genesis is possible by supplementing existing transaction-retrieval infrastructure with the integration of ZSLP consensus rules.

There are 4 types of token transactions accommodated in OP_RETURN metadata of the Zclassic transactions.

• Genesis — Defining the token
• Minting — Issuing the token
• Send — allow users to transfer tokens
• Checksum commitment — a supplement to the basic consensus model

ZSLP specifies one or more token units with Zclassic unspent output. Since transactions in Zclassic can have multiple outputs, the OP_RETURN message must specify how many tokens are being assigned to which output.

ZSLP tokens can contain multiple inputs and outputs but you cannot send multiple types of ZSLP tokens in the same Zclassic transaction.

Token Genesis Transaction

This is the first transaction that defines the properties, metadata and initial quantity of the token. The token is uniquely identified by the token genesis transaction hash which is referred to as “token_id”.

The genesis transaction for a token includes an initial mint supply. Future token supply increases are made possible if an issuer marks a special output UTXO as a “baton” that can be passed along and used for future minting authority. If the baton is not present, then the genesis is a provable one-time issuance token

Token Minting Transaction

This is a special transaction used to increase the supply of a token if a baton was created in either the Genesis or Minting transaction. If there is no such baton output then subsequent minting transactions are not possible for the token, making it possible to prove end-of-minting capabilities for a token. These subsequent minting transactions can be performed by the owner of the baton UTXO, which does not need to be the initial token issuer. For example, the Issuer may pass the minting authority along to someone else. The MINT allows us to further pass on the baton to future mint operations or to end the baton.

Spend (Transfer) Transaction

These transactions are used to transfer tokens from one token holding UTXO(s) to the new token holding UTXO(s). The UTXOs associated with unspent tokens will be used within the transaction input and, just like the ZCL attached to these UTXOs, will be considered totally spent after this transaction is accepted by the network. Tokens will be assigned to new UTXOs within the OP_RETURN statement. Any number of additional ZCL-only outputs will be allowed. A ZCL-only output can come before token outputs. Token inputs and ZCL-only inputs may come in any order.

The protocol also defines 4 consensus rules that determine the validity of a token send transaction

ZCL transactions to contain a Valid ZSLP transaction, It should follow the following rules:

1. The sum of the token “meta outputs” (token amounts specified in OP_RETURN) must not exceed the sum of the VALID (non-ignored) token “meta inputs”.
2. There must be one and only one OP_RETURN output.
3. The OP_RETURN output must conform precisely to the specification.
4. Transaction inputs are ignored if they represent a token_id different from the token_id specified in the OP_RETURN output. The same applies not just to token_id but also to the version.

Checksum Commitment Transaction

As previously discussed, a token issuer should make a regular commitment to the hash of previous transactions made for the token. Although this is not part of the consensus rules, it demonstrates that the issuer is in agreement with those rules and allows a user to verify that the issuer is indisputably operating according to the token’s consensus ruleset. Checksum hashes should be published by the issuer well after the block so that no double-spends can occur and contradict the hash.

The hash may be computed using a merklix tree of the token’s set, aggregating the token count on its branches such as each node is H(left || right || token_count). This ensures that the presence and/or absence of some token can be proven at any given point. It is also possible to audit the token in circulation.

Consensus Model of ZSLP

ZSLP utilizes a model that could be described as Proof-of-Work / Proof-of-Trust.

In a pure Proof-of-Work model, byzantine fault tolerance is achieved via economic incentives combined with incompatible-by-design sets of data. By contrast, ZSLP relies on a minimalistic set of rules overlayed onto the support of the PoW backbone.

Currently, users can make two different kinds of tokens

• Unique tokens or Non-Fungible tokens
• Identical tokens like ERC20

Conclusion

ZSLP is based on Simple ledger protocol implementation on the Bitcoin Cash blockchain. Tokens created through ZSLP can be used in several above-mentioned use cases, hence, we believe the creation and distribution of tokens should be simple, easy and available to all members of the ecosystem to reap out real use cases and innovation.