Difference between revisions of "Blockchain and Nodes"

From BlockChainTeleCom wiki
Jump to: navigation, search
(Ready for "Zero-Knowledge Proof" protocol to keep confidentiality)
(Ready for "Zero-Knowledge Proof" protocol to keep confidentiality)
Line 76: Line 76:
==Ready for "Zero-Knowledge Proof" protocol to keep confidentiality==
==Ready for "Zero-Knowledge Proof" protocol to keep confidentiality==
Cryptographic scientists have developed [[https://en.wikipedia.org/wiki/Zero-knowledge_proof '''Zero-Knowledge Proof''' (ZKP) protocol]] which allows to proof a statement without disclosure confidential information. For example, to proof that a company has enough funds on its balance without disclosure details how much does it have.
Cryptographic scientists have developed [https://en.wikipedia.org/wiki/Zero-knowledge_proof '''Zero-Knowledge Proof''' (ZKP) protocol] which allows to proof a statement without disclosure confidential information. For example, to proof that a company has enough funds on its balance without disclosure details how much does it have.
[[File:Zero-Knowledge_Proof_implementation_without_trusted_party.png|1200 px]]
[[File:Zero-Knowledge_Proof_implementation_without_trusted_party.png|1200 px]]

Revision as of 15:11, 6 June 2018

Decentralization of BT

From the subscriber's point of view, BT is just a convenient service, organized by mobile operators and service providers. From the participant's point of view, BT is decentralized, because nodes are equal, no one can control all of them, and new nodes are added by consensus of active participants. We do not see a contradiction here, because the internal interaction of participants among themselves is not a problem of a subscriber, which in general does not care how he gets the service. At the same time, it is important for operators to know that each of them is independent, and transactions in BT are technically undeniable.

Including new participants in BT is also decentralized. To provide telecom services, the operator must undergo an offline validation procedure, have a license and title documents. This, on the one hand, protects the network from bad players, and on the other hand it obstructs the operational management of the network and the rapid growth of the number of participants, because "lazy" participants can ignore voting, sabotaging new participants inclusion. We plan to resolve this issue with the help of a functional that will force participants to take part in the election of delegates. Those participants who did not take part in the procedure of consensus adding / excluding participants for a long time, will be penalized by rating downgrade and exclusion from consensus.

High performance of the BT

The main requirements for BT is a guaranteed level of service. Stable transaction closure speed is critical, because otherwise the client will not be able to get the service he needs. It should be noted that at a stable transaction closing rate, we mean not only the average time of placing the transaction in a block, but also the problems of peak loads. Even in the case of a high average speed, a noticeable increase in processing time on peaks (for example, when a big operator publish many service offers or charges), it is necessary that BT continue to steadily serve customers. So, at the current stage, we plan to use only highly available specialized servers, owned by operators, responsible for its availability and performance.

The job of the BT node is the validation of all new transactions, adding them to blocks and publishing blocks in the p2p network. Node checks the current transaction, searches for the previous one in the blockchain, checks the signatures and balances of the participants. The inclusion of a transaction in the block means, that node verified it, verified its authenticity, and guarantees the correctness of the data.

Also, it is the node that receives the commission for placing the transaction in the block. Transactions validation, in fact, is the real execution of a Special Smart-Contract (hereinafter - SSC), because all our logic, checking signatures, balances, transactions order is really only makes a choice - is transaction valid or not. So, the SSC is “hardcoded” in node’s validation algorithm and renews only with node’s software.

The requirement for quality of service limits the range of available solutions for building BT. From the candidates for building high-speed blockchains with a controlled closing time of the transaction, we selected engines based on the consensus of the Delegated Proof of Stake. They allow to assign high - performance servers as delegates, closing blocks at predictable rate, and control the degree of decentralization. In future versions, the options for building a node hierarchy in BT are considered, allowing to pass some transaction processing jobs to client devices, allowing them to help nodes.

At this stage, the most promising direction of development is Graphene engine and decisions, based on it (bitshares, steemit, golos). This engine already works in the production environment, it constantly develops, and, most importantly for us, provides following important functions:

  • add / remove delegates (operators)
  • p2p network for publishing transactions and blocks
  • implementation of “transfer” and other exchange functions
  • account management and many functions to operate with accounts
  • excellent performance due to implementation in C ++
  • many types of transactions and the ability to create and modify our own types.

Graphene implementation

To gain benefits from Graphene implementation, we use the following principles:

  • Separate state-dependent transactions and state-independent transactions to optimize their processing
  • All business-logic is embedded into Data Validation module, without external Smart-Contracts run on Virtual Machines
  • Indexes should have key (64 bits integer) and value (pointer) to provide quick search and access to objects
  • Use tx_id as Unique_ID for new objects (Providers, Offers, Requests and so on). It allows to avoid complex ID calculations (via Hash, for example) and provides easy access to the objects, with 64 bits integer key

One of the implementation problems is the update of the software on the nodes. SSC implies further development, and protocol will require changes, at least necessary to add the data to provide new types of services. Changing the logic of transactions validation can easily take out an outdated node, so we plan to make protocol changes that are strictly compatible with previous versions. The fact that delegate nodes belong to operators, who have a real economic incentive to keep the code up-to-date, is an additional advantage.


Witnesses are essential for BT ecosystem. The witnesses’ job is to collect and verify transactions, bundle them into a block, sign the block and broadcast it to the network.

Any entity, individual, or party can submit information to the blockchain (that is to say, try to add information to the database). It is necessary for the distributed operators of the blockchain to evaluate and agree on all addenda before they are permanently incorporated into the blockchain (the database). Because we cannot be sure of the author’s trustworthiness, it is vital that all new information must be reviewed and confirmed before being accepted. This review results in the ‘consensus’ and multiple witnesses keep this consensus all over blockchain network.

For each successfully constructed block, a witness is payed in shares that are taken from the limited fee pool at a rate that is defined by the shareholders by means of approval voting.

Although not strictly requited, normally each node of BT should act as a witness, thus supporting correct functionality and security of the network, contributing to network health and stability.

General BT procedure

Mobile Operator or Service Provider, that provides a service (hereinafter - "Assignee"), sends a so-called "Offer" transaction to BT. "Offer" transaction contains the information necessary for obtaining the service: price, amount of traffic, descriptions and others, encrypted, if needed.

A Mobile Operator, who is going to provide global coverage to its subscribers (hereinafter - "Issuer") reads "Offer" transactions from Blockchain and represents them to customers. On selection an Offer, a new transaction called "Request" is issued. "Request" transaction is linked to corresponding "Offer" by signing it, so Issuer starts a transactions chain that we call Special Smart-Contract (hereinafter - SSC).

"Request" transaction "freezes" some fixed amount (in SDR) of Issuer funds. These funds will be used as maximum amount of funds, that can be spent on Assignee' services. Then Assignee starts servicing the customer, with charging through "Report" transaction.

This process is repeated several times, if needed, sequentially decreasing reserved funds and increasing funds, destined to Assignee. All funds continue to stay frozen in SSC upon completion of SSC by any cause: if everything was "ok", if service has failed or is SSC is expired by time-to-live.

Diagramm Jun MNO.png

Billing and Cash Flow

Direct Billing and "Pay-per-Usage" principle provide easy implementation for Participants and fair policy for subscribers. It means that Assignee has guarantee payment for its services, and Issuer pays for consumed services only.


It allows building very flexible packages for subscribers, with combination of mobile services from multiple Operators and of value-added services from multiple Providers. Major cases are described at "Use Cases" section.

Every time a new Request is created, appropriate amount of SDRs is reserved (blocked) on the Issuer's wallet. It provides payment guarantee for the service, so Assignee is able to start servicing the subscriber directly. It's necessary to publish "Report" transaction to notify that the customer was served, otherwise the reserved sum is unblocked after expiration of the validity period and become available for other payments.

How to detect an indecent Provider

There could be some Providers who publish "Report" transaction without servicing the customers. But there is an effective way to detect them in short terms:

  1. Issuer creates a new Request with "faked" User ID. It means that such user is not able to start consuming the service
  2. If Assignee publishes "Report" transaction for this User, it means that indecent Provider has been detected. As a result, such Provider could be fined or even eliminated by voting of BT members.

So the only way to keep own reputation is to be honest with other Participants. Such method helps building reliable and trusted community.

Ready for "Zero-Knowledge Proof" protocol to keep confidentiality

Cryptographic scientists have developed Zero-Knowledge Proof (ZKP) protocol which allows to proof a statement without disclosure confidential information. For example, to proof that a company has enough funds on its balance without disclosure details how much does it have.

Zero-Knowledge Proof implementation without trusted party.png

Any participant can create multiple anonymous accounts for interaction with other partners: one account for one partner only. As a result, each transaction is validated by all participants, but only counterparties know who has created or accepted the transaction.

ZKP has following benefits for a mobile carrier:

* Its actual balance is not visible for other participants
* Volume of financial transactions is hidden

But this protocol makes the Ecosystem much more complex and consequently less stable. So it's important to have a balance of confidentiality and reliability. This point is under discussion of all participants of the Blockchain Telecom Ecosystem.