Overview of the features of the protocol Bitshares
This article is a brief summary of the results of research and study of the Bitshares protocol. The decentralized platform of the same name implements cryptocurrency, smart contracts, a trading platform and many more interesting functionality. The material may be useful in that it is already familiar with the peculiarities of the Bitcoin protocol, but has not heard about Bitshares, which in turn is an accounting system with a good compromise between decentralization and throughput. In addition, the Bitshares protocol was taken as a basis in other decentralized systems: Steemit, EOS.
The idea of the Bitshares protocol is to create a tool with which one could trade various assets and currencies in a decentralized environment, and without actually depositing them on the trading floor. The idea itself belongs to a programmer named Daniel Larimer. He offered it in 2013 and actively discussed it on the forums for five weeks. So Daniel Larimer met with another active cryptocurrency activist named Charles Hoskinson, who helped develop a business plan and attract investment.
Daniel Larimer in the school cafeteria
Daniel Larimer, also known as Bytemaster, is the main ideologue and developer of the protocol. The Bitshares platform allows anyone to create user issued assets (UIA), or digital tokens. Thus, the platform takes into account the base currency, i.e. the cryptocurrency with the BTS ticker and many user tokens.
The protocol implements a decentralized exchange, where these digital assets can be traded. When designing the accounting system and the mechanism for achieving consensus, the developers have placed great emphasis on throughput. As a result, Bitshares positions itself as a decentralized alternative to the Visa account system. While Visa claims it can process a couple of tens of thousands of transactions per second, Bitshares says it can process one hundred thousand transactions per second, in a decentralized way, with an open database and audit capability.
In addition, Bitshares is positioning itself as a platform for smart contracts. True, smart contracts are pre-installed here and their number is limited - the most popular contracts have been implemented. But they are more energy efficient and, accordingly, are cheaper in terms of commissions.
Another feature of the platform is support for payments with a higher level of user privacy, which can be used optionally. At Bitshares, this technology is called Stealth Transfers.
Briefly acquainted with the launch history of this decentralized platform.
The scope of work on creating the conceived platform was very large. The creators decided to start attracting people and distributing the coins of the future cryptocurrency in advance in order to understand whether the project will attract enough attention and whether it should be further supported. So, in November 2013, the idea of Bitshares PTS was born, which means protoshares. Its essence was that the distribution of coins will begin using mining based on a simple protocol, and at this time a full-fledged version of Bitshares will be developed.
To implement Bitshares PTS, they made Bitcoin fork (a clone of the repository with the source code), made minor changes to it and launched a new network. All those who were interested in the project could install a complete Bitshares PTS network node on their computer, extract coins, exchange and trade them. The competition for the extraction of these coins grew, and very soon the participants had to unite into mining pools.
Later, the developers presented the Bitshares protocol version 1.0 and the release date of the last block in the Bitshares PTS blockchain was announced in advance. Since the new version of the protocol is written almost from scratch and uses completely new data formats, the update has its own peculiarities. A snapshot of the status of all unused coins at the time of the last block of the old blockchain is taken and transferred to the Genesis Block of the new blockchain. It turns out that all correspondences between public keys and balances are preserved, that is, you can continue to use coins using the same private keys. Thus, on December 14, 2014, users switched to a new version of the protocol, where consensus is already being reached according to the rules of delegated proof-of-stake, and mining and issuing new coins are not provided.
In October 2015, there was another major update to the Bitshares protocol to version 2.0, which was similar.
It is worth noting that the developers of Bitshares created the very core of the decentralized platform in a separate project called Graphene. Graphene is the foundation for creating next-generation decentralized accounting systems. In addition to Bitshares, Graphene formed the basis of several other projects.
Now consider the structure of accounts in the Bitshares 2.0 protocol. It uses cryptography on elliptic curves, and the curve itself is exactly the same as in the Bitcoin protocol. There is an address format that uses the public key hash value, base 58 base number system, the BTS prefix and does not contain a checksum. But this format is rarely used, since the common platform database is optimized so that each object, including the user account, has its own unique identifier, which is actually an integer of 8 bytes (or 64 bits). In the usual operations of sending a payment, it is this account identifier that is indicated. In addition, the protocol supports the registration of unique names. Similar functionality was first implemented in the Namecoin protocol. In this way,
As noted earlier, the rules for the operation of the DPoS protocol assume that all users can take part in reaching consensus by choosing validators by voting. In the voting process, the weight of the user's vote is determined by its balance in the base currency. The formation of blocks is performed by a subset of selected validators. Within the Bitshares protocol, the validator is called witness.
Let's dwell on the transaction model in Bitshares.
The diagram shows that the transaction body consists of five main fields. The first two transaction fields are required in order to bind it to a specific block. This is necessary in order to determine the chain of blocks to which this transaction can be added, since according to the rules of the protocol the transaction cannot be confirmed in the chain to which it is not tied. The expiration_time field specifies the time until which a transaction can be added to a block. If it was not confirmed before this time, then it is considered invalid and can no longer be included in the blockchain.
Field operations_vector is special. This feature is that you can put a lot of different operations into it. The operation is another key object in the Bitshares protocol. We will name some of the most popular types of operations: transfer (transfer), account_update (account update), asset issue (token release) and order (trade offer). Each operation has its own format and the necessary parameters. For example, a transfer operation requires specifying the sender account, type of asset, amount of transfer and recipient account. The operations themselves are independent of each other, but can only be performed together if the transaction is accepted.
The extensions field requires that the current software version can process new version transactions, where additional fields can be added. Of course, the old software will not know how to correctly verify additional fields of new transactions, but at least it will be able to correctly process transactions according to the old rules.
This is an unsigned transaction format. In order to sign a transaction correctly, you need to analyze all operations from the operations_veсtor field and make a list of accounts that need to confirm this transaction. Then it becomes clear what keys need to sign the transaction. All necessary signatures are placed in a separate field - signatures. If at least one signature is missing, the whole transaction will be considered incorrect.
Note that by optimizing the size of identifiers, the final transaction size that contains one operation will be approximately 100 bytes. This is indeed a very compact transaction when compared to a transaction in other protocols.
With regard to fees, the protocol Bitshares implemented a special approach. Each operation requires a certain payment, which is removed from the account balance of the initiator at the time of confirmation of the transaction. Commission for the implementation of operations may be constant and may vary. As a rough comparison, it can be noted that the fees for ordinary transfers and trading are much lower than the fees for issuing new assets and registering a new account.
Now let's look at how asset trading works, which are issued and accounted for on the Bitshares platform. The user can make a transaction with such an operation, where he declares that he is ready to exchange one asset for another asset in a certain ratio and for a certain amount. This transaction is distributed over the network and receives confirmation, after which another user can declare in the same way that he wants to change the same assets in the same ratio. At the time of confirmation of the second transaction, according to the protocol, the balance sheets of these two users are updated, i.e., assets are actually exchanged, on the basis that both users signed exchange statements that satisfy each other.
Since such trading is carried out on the basis of a decentralized accounting system, this trading platform is called a decentralized exchange.
Another important feature of the Bitshares protocol is the ability to flexibly manage accounts. The system of dynamic account permissions (dynamic account permissions) allows you to specify account management for several keys, according to the principle of multisignature. It is arranged so that each account can be controlled by a weighted combination of other accounts or keys of electronic signature. This approach allows you to create a hierarchical management structure, the organization of which is similar to the system of permits in real life. It turns out that you can organize multi-user management of your account and its balances, where each user will have a certain weight in the decision. And for different operations, you can set different criteria.
Imagine this schematically. At the top of the hierarchy there is an account on whose behalf it is impossible to authenticate a transaction with one key. This can be done only by confirming several other accounts and keys. Participants in the lower levels of the hierarchy are usually called signers. Each of them has its own weight in the confirmation of the operation. For example, in this scheme, the signatories have a weight of 25, 40, 35, and 40 units, and the required threshold for confirming a certain type of operation may be 50, 60, or 70 units. At the same time, for other types of operations there may be a different distribution of weights and a different threshold value.
How does it work at the transaction level? One of the signatories creates a transaction with certain operations and certifies on behalf of his account. The transaction is confirmed, but the operations that are included in it are not performed, but are awaiting confirmation. Then other signatories see the offer and can either confirm it or reject the offer on behalf of their account using transactions containing special operations.
Let us consider in more detail the features of the release of user assets on the Bitshares platform. Anyone can form a transaction with the operation of creating a new asset, pay a certain commission, set the parameters of this asset and start issuing the corresponding tokens. This protocol functionality is implemented in the form of a pre-installed smart contract and has some special features.
At the request of the issuer, you can meet the requirements of KYC (Know Your Customer - know your customer) using the white list mechanism and additional confirmation (approve) of the issuer. The white list contains the accounts with which the asset issuer gives permission to receive and keep its tokens. And the additional confirmation mechanism allows the issuer to control each transfer or token trade transaction (it can reject or approve each transaction with its asset).
In addition, the issuer may limit the trade in tokens and allow only storage and transfers, or restrict transfers, and allow only trade. The issuer can also set additional fees for transfers and token trading.
Another feature is that the issuer can activate the function of withdrawing and redistributing tokens. This works for cases when it is necessary to support external mechanisms for condemning transactions and rolling back payments. It is also worth noting that all settings of user assets are set in the form of parameters of a smart contract and the issuer sets which properties it can change and which will be permanent. For example, he may limit himself to the additional issue of tokens, and may leave the possibility of an arbitrary release. And these contract parameters will be visible to all users.
An interesting property of tokens that are released on the Bitshares platform is that when making transactions with them the user can pay a commission either with the base currency or with these same tokens. The conversion is performed based on the exchange rate set by the issuer.
When exploring the Bitshares platform, be sure to mention the mechanism that helps make decisions in a decentralized environment - this is a vote. The members of the committee (committee members), validators (witnesses) and developers (workers) are elected by voting. Committee members are needed to vote for changing some parameters of the protocol, such as commissions, the number of validators, etc. Validators, they are delegates, are needed to verify transactions and form blocks. And developers offer software improvements. If they get enough votes and fit into the deadlines for the development, they receive a reward.
When voting, the voice weight of each account is proportional to its balance in the base currency. At the same time, the proxy voting option is supported, which allows you to cast your vote to another voter. This is convenient in cases where the user himself does not know which candidate is better to vote for, and gives this right to a more competent user. In general, voting is very important to ensure the high reliability of the Bitshares platform.
Now let's look at the mechanism for collecting commissions for transactions and remuneration of active participants in the network. There is a balance that does not belong to anyone of the users of the platform, and they can be managed solely by the rules of the protocol. This balance is called the Reserve Pool. The rules assume that fees for all transactions from all accounts fall into the Reserve Pool. The validator and developer accounts are paid remuneration from the Reserve Pool, as a percentage of its balance. In addition, the rules of the referral program, which the platform also supports, can be superimposed on the collection and distribution of commission fees (you can read about it separately).
It is worth mentioning the maximum number of coins of the base currency. A total of 3.6 billion coins were issued and no additional issue is foreseen. At the same time, at the time of 2018, about 2.6 billion coins are in free circulation, and about 1 billion are in the Reserve Pool.
Before that, we were talking about a smart contract that implements regular tokens, and now let's talk about another smart contract that implements market pegged assets, which are attached to the price of an external asset. They are also called SmartCoins. It works on the principle of contract for difference, i.e. contract for difference. Accordingly, anyone can issue these tokens by simply freezing a certain collateral amount, for example, in the base currency. The margin ratio is significantly higher than one, and 2 or more is recommended. Here, everything works according to the principles of margin trading, where margin positions and automatic margin calls are used. In order for the platform to show data on the price of an asset in foreign markets, trustees are used which place the asset price data on the Bitshares blockchain using a special type of operation. In this case, these trusted parties are the validators themselves.
The block header in Bitshares has a simpler structure and is smaller than the block header in Bitcoin.
Here there are such fields: previous block identifier, timestamp, creator identifier, incoming transaction hash value and extensions field to maintain compatibility with new versions of the block header.
The complete block will include the block header, the signature of the validator that created this block, and the list of transactions that are included in this block.
Within the framework of the Bitshares protocol, there are 4 concepts that play a key role in the work of the platform: blocks, transactions, operations and objects. Objects here are called account, asset, balance, offer, etc.
Let us consider in more detail the concept of operation in the context of this protocol. At Bitshares, at the time of 2018, there are about 40 different types of operations, and with the new protocol updates, you can add new types. Operations allow you to initiate some simple changes in the accounting system and more complex mechanisms, such as pre-installed smart contracts. It has already been said above that a single transaction can contain several operations that, if successful, will be executed simultaneously.
Here is a small list of the most popular operations:
As for statistics, we can say that the load on the Bitshares network in terms of the number of transactions is comparable to the load on the Bitcoin or Ethereum network. Moreover, in some moments in 2018, the Bitshares platform processed more transactions than Bitcoin and Ethereum combined. And the results of load testing show that the maximum bandwidth of the Bitshares network is hundreds of times greater than the maximum bandwidth of the Bitcoin and Ethereum networks.
According to the analytical resource blocktivity.info, as of July 2018, the Bitshares platform processes more than 60% of the total number of transactions confirmed by all decentralized platforms.
Now let's look at one important architectural feature of the Bitshares protocol, which helps to achieve such high bandwidth.
On the left of the diagram is a method of organizing a database called the blockchain, which is usually used to store the entire transaction history. On the right is another way to organize a database - Ledger. With it, the storage of correspondences between identifiers and states (for example, an account and its balance) is usually organized.
The properties of the blockchain make it easy to check the integrity of the database and its history of changes, as well as to easily organize synchronization and achieve consensus in a decentralized environment.
Ledger is convenient in that it compactly stores the latest state of the database and at the same time provides a quick search, read and update records. That is why they essentially have a higher throughput. Ledger is usually used in centralized accounting systems.
The idea of Bitshares is to use the advantages of both ways of organizing a database at the same time. Thus, a full network node keeps records simultaneously using two databases organized by the type Blockchain and Ledger, respectively. In this case, the nodes synchronize data with each other using blocks and update the local copy of the blockchain, and they carry out the verification and acceptance of transactions, focusing on the latest state of the database that the Ledger stores. Moreover, the size of all the data that make up the Ledger is optimized in such a way that the network nodes keep them in RAM. This allows you to significantly speed up the process of verification and acceptance of new transactions.
Many accounting systems use a generic scripting language to define all operations. These accounting systems ultimately use the “business logic processor” as a virtual machine, and all transactions are defined as scripts that will be run by the virtual machine. This approach uses the real processor thread synchronization mechanisms and combines them, executing all instructions through the virtual processor. A virtual processor, even with a compilation of Just-In-Time, will always be slower than a real processor, but the final computation rate is not the only problem of the approach when everything is a script.
When transactions are defined at such a low level, this means that most static checks and cryptographic transformations remain in business logic processing, and the overall throughput drops. To improve the performance of the accounting system and quickly execute business logic, all static checks including all cryptographic transformations outside the scope of the business logic module need to be taken out.
Another optimization step is to store the data of the final state of the accounting system in RAM. This means that a business logic processor can quickly follow memory pointers and directly receive the data it needs, rather than being forced to perform time-consuming database queries. It also means that the data can be accessed without copying, and that the data can be changed right in its place. This optimization provides performance gains compared to using a database-based approach.
Thus, to create an accounting system with high performance does not require complex technologies and separation of processes among network nodes. All that is needed to create a high-performance validator is to separate all independent calculations from the main business logic, execute it in one thread without interruptions to synchronize and store all verification dependencies in RAM.
It was noted above that the Bitshares accounting system uses accounts and balances, unlike Bitcoin, where records are kept on the basis of unspent exits of a transaction. Raising the level of privacy on the Bitshares platform is not a trivial task, since in the case of accounts and balances it is even easier to de-anonymize users than in Bitcoin.
But the developers of Bitshares solved this problem in an interesting way. They implemented the ability to set multiple inputs and outputs in a single operation. Now you can include a lot of inputs and outputs in one transaction, which complicates the analysis of cash flows and increases user privacy.
In addition, these default operations use techniques such as Confidential Transaction and Stealth Addresses. Confidential Transaction hides the amounts at the entrances and exits of the transaction, but at the same time uses evidence that the sum of the exits does not exceed the sum of the inputs. And Stealth Addresses hides the link between the public key, which is used as the recipient's identifier, and the address, which is actually indicated in the output of the transaction.
Bitshares uses regular (non-confidential) payments by default, but users can use Stealth Transfers if they wish. Thus, the accounting of coins on the platform is conducted in two different ways.
There is such a thing as transferring coins from one accounting method to another. For this, separate operations are implemented:
It is clear that these operations are more usual in terms of data volume and, accordingly, require a higher commission.
It is noteworthy that anyone can count how many coins went into a hidden turnover, so there is such a thing as a Stealth supply (the number of coins in a hidden turnover). But there is one practical disadvantage of the privacy option in Bitshares at the moment (July 2018). The fact is that so far there are no user-friendly graphical interfaces for easy operation in the mode of enhanced privacy.
- Does Bitshares support the ability to set arbitrary coin spending conditions, for example, using Bitcoin Script?
No, the current protocol version does not support this functionality. It is unlikely that it will be added, because in Bitshares it will be most convenient to create new types of operations and enter them in subsequent updates of the protocol.
- Are there implementations of lightweight nodes for the Bitshares network, which are similar, for example, to SPV nodes for the Bitcoin network?
Not at the moment. In addition, technically they will be more difficult than SPV in Bitcoin, because it uses DPoS, and not PoW, which is very simple. Instead of a lightweight node, you can use applications that connect to trusted nodes.
- What is the period of formation of a block on the Bitshares platform?
At the time of 2018, this is 3 seconds. Interestingly, the block formation period can be configured without updating the protocol.
- If you register a beautiful account name on the Bitshares platform, can it be sold to another user?
Yes, indeed, this option is there and it works well.
The idea of the Bitshares protocol is to create a tool with which one could trade various assets and currencies in a decentralized environment, and without actually depositing them on the trading floor. The idea itself belongs to a programmer named Daniel Larimer. He offered it in 2013 and actively discussed it on the forums for five weeks. So Daniel Larimer met with another active cryptocurrency activist named Charles Hoskinson, who helped develop a business plan and attract investment.
Daniel Larimer in the school cafeteria
Purpose of the Bitshares platform
Daniel Larimer, also known as Bytemaster, is the main ideologue and developer of the protocol. The Bitshares platform allows anyone to create user issued assets (UIA), or digital tokens. Thus, the platform takes into account the base currency, i.e. the cryptocurrency with the BTS ticker and many user tokens.
The protocol implements a decentralized exchange, where these digital assets can be traded. When designing the accounting system and the mechanism for achieving consensus, the developers have placed great emphasis on throughput. As a result, Bitshares positions itself as a decentralized alternative to the Visa account system. While Visa claims it can process a couple of tens of thousands of transactions per second, Bitshares says it can process one hundred thousand transactions per second, in a decentralized way, with an open database and audit capability.
In addition, Bitshares is positioning itself as a platform for smart contracts. True, smart contracts are pre-installed here and their number is limited - the most popular contracts have been implemented. But they are more energy efficient and, accordingly, are cheaper in terms of commissions.
Another feature of the platform is support for payments with a higher level of user privacy, which can be used optionally. At Bitshares, this technology is called Stealth Transfers.
History of development and launch
Briefly acquainted with the launch history of this decentralized platform.
The scope of work on creating the conceived platform was very large. The creators decided to start attracting people and distributing the coins of the future cryptocurrency in advance in order to understand whether the project will attract enough attention and whether it should be further supported. So, in November 2013, the idea of Bitshares PTS was born, which means protoshares. Its essence was that the distribution of coins will begin using mining based on a simple protocol, and at this time a full-fledged version of Bitshares will be developed.
To implement Bitshares PTS, they made Bitcoin fork (a clone of the repository with the source code), made minor changes to it and launched a new network. All those who were interested in the project could install a complete Bitshares PTS network node on their computer, extract coins, exchange and trade them. The competition for the extraction of these coins grew, and very soon the participants had to unite into mining pools.
Later, the developers presented the Bitshares protocol version 1.0 and the release date of the last block in the Bitshares PTS blockchain was announced in advance. Since the new version of the protocol is written almost from scratch and uses completely new data formats, the update has its own peculiarities. A snapshot of the status of all unused coins at the time of the last block of the old blockchain is taken and transferred to the Genesis Block of the new blockchain. It turns out that all correspondences between public keys and balances are preserved, that is, you can continue to use coins using the same private keys. Thus, on December 14, 2014, users switched to a new version of the protocol, where consensus is already being reached according to the rules of delegated proof-of-stake, and mining and issuing new coins are not provided.
In October 2015, there was another major update to the Bitshares protocol to version 2.0, which was similar.
It is worth noting that the developers of Bitshares created the very core of the decentralized platform in a separate project called Graphene. Graphene is the foundation for creating next-generation decentralized accounting systems. In addition to Bitshares, Graphene formed the basis of several other projects.
Account Model
Now consider the structure of accounts in the Bitshares 2.0 protocol. It uses cryptography on elliptic curves, and the curve itself is exactly the same as in the Bitcoin protocol. There is an address format that uses the public key hash value, base 58 base number system, the BTS prefix and does not contain a checksum. But this format is rarely used, since the common platform database is optimized so that each object, including the user account, has its own unique identifier, which is actually an integer of 8 bytes (or 64 bits). In the usual operations of sending a payment, it is this account identifier that is indicated. In addition, the protocol supports the registration of unique names. Similar functionality was first implemented in the Namecoin protocol. In this way,
Reaching consensus based on DPoS
As noted earlier, the rules for the operation of the DPoS protocol assume that all users can take part in reaching consensus by choosing validators by voting. In the voting process, the weight of the user's vote is determined by its balance in the base currency. The formation of blocks is performed by a subset of selected validators. Within the Bitshares protocol, the validator is called witness.
Transaction model
Let's dwell on the transaction model in Bitshares.
The diagram shows that the transaction body consists of five main fields. The first two transaction fields are required in order to bind it to a specific block. This is necessary in order to determine the chain of blocks to which this transaction can be added, since according to the rules of the protocol the transaction cannot be confirmed in the chain to which it is not tied. The expiration_time field specifies the time until which a transaction can be added to a block. If it was not confirmed before this time, then it is considered invalid and can no longer be included in the blockchain.
Field operations_vector is special. This feature is that you can put a lot of different operations into it. The operation is another key object in the Bitshares protocol. We will name some of the most popular types of operations: transfer (transfer), account_update (account update), asset issue (token release) and order (trade offer). Each operation has its own format and the necessary parameters. For example, a transfer operation requires specifying the sender account, type of asset, amount of transfer and recipient account. The operations themselves are independent of each other, but can only be performed together if the transaction is accepted.
The extensions field requires that the current software version can process new version transactions, where additional fields can be added. Of course, the old software will not know how to correctly verify additional fields of new transactions, but at least it will be able to correctly process transactions according to the old rules.
This is an unsigned transaction format. In order to sign a transaction correctly, you need to analyze all operations from the operations_veсtor field and make a list of accounts that need to confirm this transaction. Then it becomes clear what keys need to sign the transaction. All necessary signatures are placed in a separate field - signatures. If at least one signature is missing, the whole transaction will be considered incorrect.
Note that by optimizing the size of identifiers, the final transaction size that contains one operation will be approximately 100 bytes. This is indeed a very compact transaction when compared to a transaction in other protocols.
With regard to fees, the protocol Bitshares implemented a special approach. Each operation requires a certain payment, which is removed from the account balance of the initiator at the time of confirmation of the transaction. Commission for the implementation of operations may be constant and may vary. As a rough comparison, it can be noted that the fees for ordinary transfers and trading are much lower than the fees for issuing new assets and registering a new account.
Decentralised asset exchange
Now let's look at how asset trading works, which are issued and accounted for on the Bitshares platform. The user can make a transaction with such an operation, where he declares that he is ready to exchange one asset for another asset in a certain ratio and for a certain amount. This transaction is distributed over the network and receives confirmation, after which another user can declare in the same way that he wants to change the same assets in the same ratio. At the time of confirmation of the second transaction, according to the protocol, the balance sheets of these two users are updated, i.e., assets are actually exchanged, on the basis that both users signed exchange statements that satisfy each other.
Since such trading is carried out on the basis of a decentralized accounting system, this trading platform is called a decentralized exchange.
Account Management Flexibility
Another important feature of the Bitshares protocol is the ability to flexibly manage accounts. The system of dynamic account permissions (dynamic account permissions) allows you to specify account management for several keys, according to the principle of multisignature. It is arranged so that each account can be controlled by a weighted combination of other accounts or keys of electronic signature. This approach allows you to create a hierarchical management structure, the organization of which is similar to the system of permits in real life. It turns out that you can organize multi-user management of your account and its balances, where each user will have a certain weight in the decision. And for different operations, you can set different criteria.
Imagine this schematically. At the top of the hierarchy there is an account on whose behalf it is impossible to authenticate a transaction with one key. This can be done only by confirming several other accounts and keys. Participants in the lower levels of the hierarchy are usually called signers. Each of them has its own weight in the confirmation of the operation. For example, in this scheme, the signatories have a weight of 25, 40, 35, and 40 units, and the required threshold for confirming a certain type of operation may be 50, 60, or 70 units. At the same time, for other types of operations there may be a different distribution of weights and a different threshold value.
How does it work at the transaction level? One of the signatories creates a transaction with certain operations and certifies on behalf of his account. The transaction is confirmed, but the operations that are included in it are not performed, but are awaiting confirmation. Then other signatories see the offer and can either confirm it or reject the offer on behalf of their account using transactions containing special operations.
UIA emission
Let us consider in more detail the features of the release of user assets on the Bitshares platform. Anyone can form a transaction with the operation of creating a new asset, pay a certain commission, set the parameters of this asset and start issuing the corresponding tokens. This protocol functionality is implemented in the form of a pre-installed smart contract and has some special features.
At the request of the issuer, you can meet the requirements of KYC (Know Your Customer - know your customer) using the white list mechanism and additional confirmation (approve) of the issuer. The white list contains the accounts with which the asset issuer gives permission to receive and keep its tokens. And the additional confirmation mechanism allows the issuer to control each transfer or token trade transaction (it can reject or approve each transaction with its asset).
In addition, the issuer may limit the trade in tokens and allow only storage and transfers, or restrict transfers, and allow only trade. The issuer can also set additional fees for transfers and token trading.
Another feature is that the issuer can activate the function of withdrawing and redistributing tokens. This works for cases when it is necessary to support external mechanisms for condemning transactions and rolling back payments. It is also worth noting that all settings of user assets are set in the form of parameters of a smart contract and the issuer sets which properties it can change and which will be permanent. For example, he may limit himself to the additional issue of tokens, and may leave the possibility of an arbitrary release. And these contract parameters will be visible to all users.
An interesting property of tokens that are released on the Bitshares platform is that when making transactions with them the user can pay a commission either with the base currency or with these same tokens. The conversion is performed based on the exchange rate set by the issuer.
Voting mechanism
When exploring the Bitshares platform, be sure to mention the mechanism that helps make decisions in a decentralized environment - this is a vote. The members of the committee (committee members), validators (witnesses) and developers (workers) are elected by voting. Committee members are needed to vote for changing some parameters of the protocol, such as commissions, the number of validators, etc. Validators, they are delegates, are needed to verify transactions and form blocks. And developers offer software improvements. If they get enough votes and fit into the deadlines for the development, they receive a reward.
When voting, the voice weight of each account is proportional to its balance in the base currency. At the same time, the proxy voting option is supported, which allows you to cast your vote to another voter. This is convenient in cases where the user himself does not know which candidate is better to vote for, and gives this right to a more competent user. In general, voting is very important to ensure the high reliability of the Bitshares platform.
Commission mechanism
Now let's look at the mechanism for collecting commissions for transactions and remuneration of active participants in the network. There is a balance that does not belong to anyone of the users of the platform, and they can be managed solely by the rules of the protocol. This balance is called the Reserve Pool. The rules assume that fees for all transactions from all accounts fall into the Reserve Pool. The validator and developer accounts are paid remuneration from the Reserve Pool, as a percentage of its balance. In addition, the rules of the referral program, which the platform also supports, can be superimposed on the collection and distribution of commission fees (you can read about it separately).
It is worth mentioning the maximum number of coins of the base currency. A total of 3.6 billion coins were issued and no additional issue is foreseen. At the same time, at the time of 2018, about 2.6 billion coins are in free circulation, and about 1 billion are in the Reserve Pool.
Smartcoins
Before that, we were talking about a smart contract that implements regular tokens, and now let's talk about another smart contract that implements market pegged assets, which are attached to the price of an external asset. They are also called SmartCoins. It works on the principle of contract for difference, i.e. contract for difference. Accordingly, anyone can issue these tokens by simply freezing a certain collateral amount, for example, in the base currency. The margin ratio is significantly higher than one, and 2 or more is recommended. Here, everything works according to the principles of margin trading, where margin positions and automatic margin calls are used. In order for the platform to show data on the price of an asset in foreign markets, trustees are used which place the asset price data on the Bitshares blockchain using a special type of operation. In this case, these trusted parties are the validators themselves.
Block Header Format
The block header in Bitshares has a simpler structure and is smaller than the block header in Bitcoin.
Here there are such fields: previous block identifier, timestamp, creator identifier, incoming transaction hash value and extensions field to maintain compatibility with new versions of the block header.
The complete block will include the block header, the signature of the validator that created this block, and the list of transactions that are included in this block.
Within the framework of the Bitshares protocol, there are 4 concepts that play a key role in the work of the platform: blocks, transactions, operations and objects. Objects here are called account, asset, balance, offer, etc.
Many operations and features of their implementation
Let us consider in more detail the concept of operation in the context of this protocol. At Bitshares, at the time of 2018, there are about 40 different types of operations, and with the new protocol updates, you can add new types. Operations allow you to initiate some simple changes in the accounting system and more complex mechanisms, such as pre-installed smart contracts. It has already been said above that a single transaction can contain several operations that, if successful, will be executed simultaneously.
Here is a small list of the most popular operations:
- transfer_operation transfers a specific asset from the balance of one account to another;
- limit_order_create_operation creates an object of the asset exchange request; limit_order_cancel_operation cancels such an order;
- fill_order_operation is performed automatically when two orders satisfy each other and it does not require a transaction, therefore it is also called a virtual operation;
- account_create_operation creates a normal user account;
- blind_transfer_operation makes a confidential payment;
- asset_create_operation creates a new asset object;
- asset_update_operation changes the smart contract parameters of an existing token;
- asset_issue_operation issues tokens of an existing asset;
- witness_create_operation creates a validator candidate account.
As for statistics, we can say that the load on the Bitshares network in terms of the number of transactions is comparable to the load on the Bitcoin or Ethereum network. Moreover, in some moments in 2018, the Bitshares platform processed more transactions than Bitcoin and Ethereum combined. And the results of load testing show that the maximum bandwidth of the Bitshares network is hundreds of times greater than the maximum bandwidth of the Bitcoin and Ethereum networks.
According to the analytical resource blocktivity.info, as of July 2018, the Bitshares platform processes more than 60% of the total number of transactions confirmed by all decentralized platforms.
Database organization
Now let's look at one important architectural feature of the Bitshares protocol, which helps to achieve such high bandwidth.
On the left of the diagram is a method of organizing a database called the blockchain, which is usually used to store the entire transaction history. On the right is another way to organize a database - Ledger. With it, the storage of correspondences between identifiers and states (for example, an account and its balance) is usually organized.
The properties of the blockchain make it easy to check the integrity of the database and its history of changes, as well as to easily organize synchronization and achieve consensus in a decentralized environment.
Ledger is convenient in that it compactly stores the latest state of the database and at the same time provides a quick search, read and update records. That is why they essentially have a higher throughput. Ledger is usually used in centralized accounting systems.
The idea of Bitshares is to use the advantages of both ways of organizing a database at the same time. Thus, a full network node keeps records simultaneously using two databases organized by the type Blockchain and Ledger, respectively. In this case, the nodes synchronize data with each other using blocks and update the local copy of the blockchain, and they carry out the verification and acceptance of transactions, focusing on the latest state of the database that the Ledger stores. Moreover, the size of all the data that make up the Ledger is optimized in such a way that the network nodes keep them in RAM. This allows you to significantly speed up the process of verification and acceptance of new transactions.
Optimization of business logic execution
Many accounting systems use a generic scripting language to define all operations. These accounting systems ultimately use the “business logic processor” as a virtual machine, and all transactions are defined as scripts that will be run by the virtual machine. This approach uses the real processor thread synchronization mechanisms and combines them, executing all instructions through the virtual processor. A virtual processor, even with a compilation of Just-In-Time, will always be slower than a real processor, but the final computation rate is not the only problem of the approach when everything is a script.
When transactions are defined at such a low level, this means that most static checks and cryptographic transformations remain in business logic processing, and the overall throughput drops. To improve the performance of the accounting system and quickly execute business logic, all static checks including all cryptographic transformations outside the scope of the business logic module need to be taken out.
Another optimization step is to store the data of the final state of the accounting system in RAM. This means that a business logic processor can quickly follow memory pointers and directly receive the data it needs, rather than being forced to perform time-consuming database queries. It also means that the data can be accessed without copying, and that the data can be changed right in its place. This optimization provides performance gains compared to using a database-based approach.
Thus, to create an accounting system with high performance does not require complex technologies and separation of processes among network nodes. All that is needed to create a high-performance validator is to separate all independent calculations from the main business logic, execute it in one thread without interruptions to synchronize and store all verification dependencies in RAM.
User privacy enhancement options
It was noted above that the Bitshares accounting system uses accounts and balances, unlike Bitcoin, where records are kept on the basis of unspent exits of a transaction. Raising the level of privacy on the Bitshares platform is not a trivial task, since in the case of accounts and balances it is even easier to de-anonymize users than in Bitcoin.
But the developers of Bitshares solved this problem in an interesting way. They implemented the ability to set multiple inputs and outputs in a single operation. Now you can include a lot of inputs and outputs in one transaction, which complicates the analysis of cash flows and increases user privacy.
In addition, these default operations use techniques such as Confidential Transaction and Stealth Addresses. Confidential Transaction hides the amounts at the entrances and exits of the transaction, but at the same time uses evidence that the sum of the exits does not exceed the sum of the inputs. And Stealth Addresses hides the link between the public key, which is used as the recipient's identifier, and the address, which is actually indicated in the output of the transaction.
Bitshares uses regular (non-confidential) payments by default, but users can use Stealth Transfers if they wish. Thus, the accounting of coins on the platform is conducted in two different ways.
There is such a thing as transferring coins from one accounting method to another. For this, separate operations are implemented:
- transfer_to_blind_operation is used to transfer coins from open to hidden circulation;
- blind_transfer_operation for transferring coins in a hidden way, and transfer_from_blind_operation for transferring coins from hidden to open.
It is clear that these operations are more usual in terms of data volume and, accordingly, require a higher commission.
It is noteworthy that anyone can count how many coins went into a hidden turnover, so there is such a thing as a Stealth supply (the number of coins in a hidden turnover). But there is one practical disadvantage of the privacy option in Bitshares at the moment (July 2018). The fact is that so far there are no user-friendly graphical interfaces for easy operation in the mode of enhanced privacy.
Frequently asked Questions
- Does Bitshares support the ability to set arbitrary coin spending conditions, for example, using Bitcoin Script?
No, the current protocol version does not support this functionality. It is unlikely that it will be added, because in Bitshares it will be most convenient to create new types of operations and enter them in subsequent updates of the protocol.
- Are there implementations of lightweight nodes for the Bitshares network, which are similar, for example, to SPV nodes for the Bitcoin network?
Not at the moment. In addition, technically they will be more difficult than SPV in Bitcoin, because it uses DPoS, and not PoW, which is very simple. Instead of a lightweight node, you can use applications that connect to trusted nodes.
- What is the period of formation of a block on the Bitshares platform?
At the time of 2018, this is 3 seconds. Interestingly, the block formation period can be configured without updating the protocol.
- If you register a beautiful account name on the Bitshares platform, can it be sold to another user?
Yes, indeed, this option is there and it works well.