Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of what the logical data model of Libra protocol is, the content is detailed and easy to understand, the operation is simple and fast, and it has certain reference value. I believe you will gain something after reading this article on the logical data model of Libra protocol. Let's take a look at it.

Introduction to Libra protocol

The Libra blockchain is essentially an encrypted database that is maintained through Libra protocol. So Libra protocol is the core of the Libra block chain.

The core of Libra protocol is account, resources and module.

The database mainly stores programmable resources books, such as Libra coin. These resources are agreed upon by the defined module, and the module is also stored in the database.

Resources belongs to the account and is authenticated by public key encryption.

The account can represent either the direct end user of the system or the entity, such as

On behalf of the user's safekeeping wallet.

The account owner uses the resources in the account through sign transactions.

Here is an example of how client and validators interact with each other using libra protocol:

1.client request

2.proposes transactions

3.execute the transactions

3.execute the transactions

4.vote

5.responses

Client

Leader

Other validators

Analyze each step in detail:

The validator maintains the database and processes transactions submitted by the customer to include them in the database.

The verifier uses a distributed consensus protocol to ensure the submission of the transaction. The verifier does not rotate constantly. When the verifier is the leader, it proposes transactions, including transactions submitted directly to him by the customer and indirectly submitted to other verifiers through other verifiers. 3. All validators execute transactions and form a data structure that contains authenticated data: the history of the new account book.

As part of the consensus agreement, the verifier votes on the verifier of the data structure.

As part of committing a transaction Ti on version I, the consensus protocol outputs a signature-including its entire history-on the database full state of version I as a validation response to queries from the client.

The client can issue queries to the validator to read data from the database. Because the database has been authenticated, you can ensure the accuracy of the customer query response.

In addition, the client can choose to create a copy of the entire database by synchronizing the verifier's transactions.

When creating a copy, the client can verify that the verifier executes the transaction correctly, thus improving the reliability of the system. Other clients can read data from the client that holds the copy in the same way as the client from the validator. For simplicity, the rest of this article assumes that the client queries the validator directly instead of the copy.

Logical data model

All data in the Libra blockchain is stored in a single database with a version. The version number of the database is represented by an unsigned integer of 64-bit. This integer is the number of transactions currently executed by the system.

If in a certain version I, the database contains tuples (Ti,Oi, Si), where Ti represents the transaction, Oi represents the output of the transaction, and Si represents the account status of the version.

If the version executes an Apply function, then the tuple means that an Ti transaction is executed in the account state Si-1, resulting in an output Oi and a new account status Si.

To put it simply, it is the following formula:

Apply (Si − 1, Ti)-> ⟨Oi, Si ⟩.

The Libra protocol uses the move language to implement this Apply function, which we will cover in a later article. In this chapter, we mainly explain the transaction and query functions of the version database.

Account book status

The account status is the basis of the Libra block chain, which includes the status of each user in a different version. Each verifier can get the latest ledger status.

The account book structure is the key value storage, which can map the account address key to the account value. Account

In the distributed ledger state, it is a collection of published Move resources and modules. The Move resource stores the data value and the module stores the code.

During the initialization of the account book, we will create some built-in accounts.

Account address

The account address is a value of 256-bit. Users can create a public-private key pair locally and then use the encrypted hash value of the public key as the address of the account. Note here that this account address is created only when a transaction occurs (for example, when a Libra currency is sent to this address).

After the account is created, the user can use the private key signature to send the transaction using the account. Users can change or rotate the private key without changing the account address.

One user can create an unlimited number of accounts if you like.

Resource

I mentioned earlier that the state database is a structure in the form of key-value. Key is the address of account, and value can be resource or module.

Each resource has a type declared by module. The type of resource contains the name of the type and the name and address of the module that defines the type.

Suppose we have two accounts: Ox12 and Ox34. A module:Currency is defined in Ox12, and a type T is defined in this module. Then the name of this type is: Ox12.Currency.T.

This type of name is unique, even if you use it in other accounts. For example, if I use this type in Ox34, I can get the resource: 0x34/resources/0x12.Currency.T.

The purpose of this design is to have a unified name for all resource types.

Module

Module mainly uses Move bytecode to declare resources and procedures. Like resources, Module is located by account address. For example, the logo of Currency Module above is: Ox12.Currency.

In the current version of Libra, Module is immutable. Once the Module is declared in the account, it cannot be deleted and changed unless it is forked. This limitation may change in future releases.

Trade

The client updates the Libra blockchain by submitting the Transaction. Generally speaking, Transaction contains a transaction script and the parameters required by the transaction script.

The verifier uses the current ledger status and the input of the transaction script to produce a fixed output. The status of the ledger will not take effect until the transaction is submitted by consensus.

Transaction output

Executing a transaction Ti results in a new account status Si, the execution result code (whether the execution was successful or not), the gas used, and the event list.

Event

An event list is a series of side effects caused by executing a transaction. Move code

Departure time in event structure. Each event is associated with a unique key

With this unique key, you can determine the structure of the event that was emitted and the valid payload (details about the event).

Once a transaction is reached in a consensus agreement, events arising from the transaction are added to the book history and proof of successful execution is provided in the corresponding event. For example, a

A payment transaction produces an event that allows the recipient to confirm receipt of the payment and confirm the amount of the payment.

It looks as if the Event is redundant, because in addition to querying the events generated by the transaction, the client can also determine by querying whether the blockchain contains the transaction.

But this is error-prone, because including a Ti does not mean successful execution (for example,

Gas may be interrupted when it is used up. In a system where a transaction may fail

Evidence in event that not only indicates that a particular transaction has been executed, but also that it has been successfully completed

The expected effect has been achieved.

Transactions can only generate events, and they can't read event, which is designed to keep transactions focused on the latest state information, not historical event information.

Ledger history

The ledger history stores transactions submitted and executed and their associated events in order. The history of the account is mainly used to keep records and let people know how the latest status of the account is calculated.

Unlike other blockchains, Libra book history does not have the concept of transaction blocks. In the logical data model, transactions are executed sequentially, and there is no need to distinguish which block the transaction is in.

Although the verifier does not need the book history to generate a new account state, the client can use the book history to verify and query the corresponding transaction information.

The verifier informs the client of the previous account status, transactions and corresponding output by querying the historical ledger.

The customer can verify that the transaction is executed correctly by re-executing a specific transaction on the historical book status and verifying the output result and the executed book status.

This is the end of the article on "what is the logical data model of Libra protocol?" Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "what is the logical data model of Libra protocol". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.