Article Directory
Libra protocol Introduction
It is an encrypted database on a block chain nature Libra, Libra protocol through this database to maintain. So Libra Libra protocol is the core of the block chain.
Libra protocol is the core accounts, resources and module.
The main storage programmable database resources books, such as: Libra coin. These resources are defined by the module to the agreement, which are also stored in the database module.
resources belong to the account, and through public key cryptography to authenticate.
Accounts can represent a direct end-user systems, it can also represent entities such as
the user's behalf custody wallet.
The account owner to use the resources in the account sign transactions.
Here is an example of a client and validators libra protocol used to interact:
Specific analysis of each step:
- Validator maintain the database and transaction processing customers submitted for inclusion in the database.
- Verifier uses a distributed consensus protocol to ensure the submission of the transaction. Verifier not continue wheeled. When verifying person as a leader, it is proposed transaction, including his transactions submitted directly by the customer to be submitted to the transaction and other verifier through other indirect verifier. 3. All verification procedures to execute trades and form a data structure containing Authenticated: new books of history.
- As part of the consensus agreement, the verifier to vote for the verifier data structure.
- As part of the transaction is committed Ti in the version i, the output of a consensus agreement on a complete state of a signature database version i - including its entire history as a validation response to a query from the client's.
The client can issue a query to the verifier to read the data from the database. Because the database has been authenticated, it is possible to ensure the accuracy of customer query response.
In addition, the client can choose to create a copy of the entire database transactions recorded synchronization verifier.
When you create a copy, the client can verify whether verify the correct execution of transactions, thereby improving the reliability of the system. Other clients can read the data from the hold of a copy of the client, the client's way of reading from the verification process the same way. For simplicity, the rest of this article assumes that the client directly for verification rather than a copy.
Logical data model
Libra all data blocks are stored in the chain with a single version of the database. Database version number is represented by 64-bit integer to an unsigned. This integer is the number of trading systems currently running.
If in one version i, a database containing the tuple (Ti, Oi, Si), Ti denotes the transaction, Oi indicates the output transactions, Si represents a state version of the books.
If a version Apply function performed, then this means that the tuple: books in state Si-1 performs a transaction Ti, produces an output Oi, and books a new state Si.
It is simply the following equation:
the Apply (-Si. 1, of Ti) -> ⟨Oi, Si⟩.
Libra protocol uses language Move to Apply achieve this function, we'll cover in a later article. In this chapter we mainly on the transaction and query functions version of the database.
Books state
Libra is the foundation of the state of the books of the block chain, including the status of his different versions of each user. Each verifier can obtain the latest ledgers state.
Books stored key structure, key account addresses may be mapped to the account value. Account
set of books in the distribution of state, is published Move resources and modules. Wherein Move Resource storing data values, the code storage module.
During the initialization of the books, we will create a part of the built-in accounts.
Account address
Account address is a 256-bit value. Users can create public and private key pair locally, then the encrypted hash value as an address public account. Here we must note that this account address only occurs when the transaction will be created (such as Libra coins have been sent to this address when).
After the account is created, users can use the private key signature to use this account to send transaction. Without the user can replace the account address, to replace the private key or round robin.
If you wish, a user can create an unlimited number of accounts.
Resource
We mentioned before the state database is a structure in the form of key-value. key is the account address, value can be a resource can also be a module.
Each resource has a type of module declaration. The type of resource that contains the type of module names and definitions of the types of names and addresses.
If we have two accounts:. Ox12 and Ox34 defines a module in Ox12: Currency, defines a type T. In this module the Well, this type of name is called: Ox12.Currency.T.
This type of name is unique, even if you use other accounts of this type. For example, I used this type Ox34, then this can be obtained from the resource in Ox34: 0x34 / resources / 0x12.Currency.T.
The purpose of this design is that all resource types have a unified name.
Module
Module mainly use the Move byte code to declare the resources and procedures. And the same resources, Module also be targeted by the account address, such as the above-Currency Module mark is: Ox12.Currency.
In the current version of Libra, Module can not be changed. Once the Module statement in the account, you will not be able to delete and change, unless hard fork. This limit may change in future releases.
transaction
The client updated Libra block chain by submitting Transaction. Generally speaking Transaction script contains a parameter a transaction and transaction scripts need.
The verifier generates a fixed output using the input current status of accounts and transaction scripts. The state of the books only after the transaction is submitted consensus, to take effect.
Transaction output
Execute a transaction Ti books will produce a new state Si, the result of the implementation of the code (whether successful execution), gas use, and event lists.
event
The event list is a series of side effects produced by the enforcement branch. Move Code
departure time in the event structure. Each event is associated with a unique key,
by the only key issue to determine the structure and the effective payload (For more information about the event) event.
Once the deal at a consensus agreement, the event generated by the transaction will be added to the history books, and provide proof of successful implementation in the corresponding event. For example, a
payment transactions would yield an event, so that the receiver can confirm that payment has been received and confirmed the payment amount.
Event looks like superfluous, because in addition to queries arising from transactions event, the client can also include whether the transaction is determined by querying blockchain.
But it is very easy to make mistakes, because it contains Ti does not mean that the successful implementation (eg,
Gas after use may be interrupted). In the transaction system may fail, the
evidence in the event, not only that a particular transaction has been executed and completed successfully
achieve their desired results.
Trading can only generate events, they can not read the event, this is designed to make trading concern with the latest state information, rather than the event historical information.
History books
History books are stored in order submission and execution of the transaction and its associated event. History books are mainly used to save the record, let everyone know the latest status of the books is how calculated.
And the other block chain is not the same, Libra history books and no concept of trading blocks, in the logical data model, transactions are executed sequentially, does not need to distinguish in the end the deal in which block inside.
Although the verifier does not need to generate a new history books books state, but the client can use the history books to verify and check the appropriate transaction information.
Verifier books had told the state before the client transactions and the corresponding output by querying the historical account.
Customers can result in the state after the books again to perform a specific transaction in the history books state, through the implementation and verification of the output to verify that the transaction is executed correctly.
Please refer to more tutorials flydean's blog
