Libra blockchain paper analysis – introduction, data logic model (part 2)

The entire technical paper is divided into 10 parts:

1 Introduction–Introduction

2 Logical Data Model–Logical Data Model

3 Executing Transactions–Execution of Transactions

• Suggested to stop and respond, how will Facebook respond to regulatory difficulties?
• Babbitt Column | Li Guoquan: How to Treat Libra's Opportunity to Create Global Digital Currency
• Depth | Interpretation of the world of decentralization (1)

4 Authenticated Data Structures and Storage – Authenticated Data Structures and Storage

5 Byzantine Fault Tolerant Consensus–Byzantine Fault Tolerance Consensus

6 Networking–Network

7 Libra Core Implementation– Libra Core Implementation

8 Performance–Performance

9 Implementing Libra Ecosystem Policies with Move–Using Move to Implement Libra Ecosystem Rules

10 What's Next for Libra?– Libra Development Planning

Continue to analyze Section 2: The Logical Data Model.

Resource

A resource, also known as a resource value, is a record that binds a field name to a value. The value can be an integer or a complex number, or even a resource embedded inside a resource.

Each resource belongs to a type that is defined by the module. The type of resource consists of the resource name, the name and address of the module in which the resource resides. For example, in Figure 2, the Currency.T resource type is 0x56.Currency.T, where 0x56 is the address of the Currency module, Currency is the name of the module, and Currency.T is the name of the resource.

Figure 2: An example of a ledger status with four accounts. In this figure, an ellipse represents a resource and a rectangle represents a module. The directed edge from the resource to the module means that the module declares the type of resource. The account at address 0x12 contains a Currency.T resource defined by the Currency module. The code for the Currency module is stored at address 0x56. The account at address 0x34 contains the Currency.T resource and the StateChannel.T resource, both of which are defined by the module stored at address 0x78.

How to find a resource?

For example, under account 0x12, in order to retrieve the 0x56.Currency.T resource, the client makes a request through the following address:

0x12/resources/0x56.Currency.T

The purpose of this design is to make each account use the same path to store the 0x56.Currency.T resource, so that the module can define a convenient use for the account value, and it can be used in advance. So for each type, each account stores at most one resource. But this limitation is not a hard condition. The programmer can customize a package resource, such as resource TwoCoin { c1: 0x56.Currency.T, c2: 0x56.Currency.T }.

The establishment of resources and the definition of resource types are all carried out in modules. These rules for converting, deleting and publishing established resources are encoded in the module. Move's security and validation rules prevent other code from modifying resources.

Module

A module, also known as a module value, contains the byte encoding of the resource type and procedure by Move. How to identify the module? The module is identified by the account address in the module. For example, in Figure 2, the Currency module is identified as 0x56.Currency, where 0x56 is the address of the account.

The naming of modules in an account is unique, ie each name can only be used once per account to define a module. For example, a 0x56 account can no longer name other modules as Currency, but other accounts, such as 0x34, can name the module belonging to it as Currency, for example, 0x34.Currency. Note that 0x56.Currency.T and 0x34.Currency.T are of different types and cannot be confused.

The current version of the Libra protocol does not allow modification of the module, ie the module is not susceptible to modification. Once a module is created in an account, it is not allowed to be modified or deleted unless it is forked.

The security update of the module is a future extension of the Libra protocol and is currently under study and can be considered a challenge.

transaction

After the Libra blockchain customer submits a transaction, the status of the ledger will be updated. This is the same as the current bank. After a transaction, the balance of our account will change.

In general, a transaction consists of a transaction script and parameters that are entered into the script, where the script is written in Move byte encoding, and the parameter can be the address of the receiving account or the number of Libra coins sent.

The execution of the transaction is accomplished by the verifier running the script, and the script parameters and the book status are used as input to the program to produce a fully deterministic output.

After the transaction occurred, is the book status updated? No, just like in the Bitcoin system, the book is updated and confirmed after the transaction has been confirmed by 6 blocks. In the Libra blockchain, after the consensus algorithm confirms the transaction output, the confirmation is bound to the transaction result, and the book status is updated. The structure and execution of the transaction will be discussed in detail in Section 3.

Transaction output

Executing a transaction T _i will generate a new book status S _i and execution status code, gas usage, event list, which are all concentrated in the output O _i . The execution status code records the results of executing the transaction, such as successful execution, exit due to an error, exhaustion of gas usage, and so on. The gas usage records the amount of gas used to execute the trade. See Section 3.1 for details. What is the event?

Event list

The event list is a "by-product" generated during the execution of the transaction, similar to the concept of logs and events in Ethereum, but the purpose of use is completely different.

The Move code triggers an event through the event structure. Each event is associated with a unique public key that identifies the event structure by the triggered event and its payment amount, providing details of the event.

Once the transaction is confirmed by the consensus agreement, the events generated by the transaction are recorded in the book history to provide evidence of the results of the successful execution of the transaction. For example, a payment transaction triggers an event that allows the recipient to confirm the payment and confirm the payment amount.

At first glance, the concept of the event seems redundant, and the client can replace the query for the event triggered by the transaction by querying whether the transaction is already stored in the blockchain. However, if it is replaced, it is very easy to generate errors, because the transaction stored in the blockchain does not mean that the transaction has been successfully executed, and it is likely to be interrupted due to the exhaustion of gas during execution. Therefore, in a system where a transaction may fail to execute, the event can not only provide proof of the execution of the transaction, but also provide proof that the transaction was successfully executed and is in line with expectations.

Note that the transaction can only generate events and cannot read events. This design only allows the execution of the transaction to be based on the current state, rather than on historical information, such as reading past events that are not allowed.

Book history

The book history preserves the sequential process of submitting and executing the trades, as well as the events they trigger. The purpose of the book history is to document the process of the formation of the most recent book. There is no concept of "blocks" in the book history.

Consensus agreements package transactions into chunks, just as an optimization to drive consensus execution. But in the logical data model, transactions are generated in order, and there is no need to distinguish which block contains which transaction.

Although the verifier does not need to know the history of the ledger when executing the new transaction, the history of the ledger can be used for the execution of the customer audit transaction, for example, the customer can submit an authentication query for the history of the transaction.

Customer query response

The verifier responds to the customer's query of past ledger status, transactions, and output through the history of the ledger. For example, a customer may query the status of a ledger under a certain version number. For example, what is the account balance at address x under version 30? The customer may also query for a specific type of historical event, for example, the address is What payments did y's account receive in the last 20 minutes?

Audit of transaction execution

The verification of the customer's reconciliation status is performed by re-executing each of the past transactions T _i and comparing the execution result with the corresponding book status S _i and transaction output O _i in the corresponding version database.

This mechanism allows the customer to audit the verifier to ensure the correct execution of the transaction.

This section is analyzed. In this section, the blockchain is stored in a version of the database. The historical state of the books is important because the transactions are in order. The current transaction is based on the previous transaction, otherwise it will be messy. Now we have to put the bank to help us keep the book on the blockchain. Therefore, the historical state and current state of the book are all required to be portrayed.

In addition, customers can audit the books, the advantage is transparent, the disadvantage is that privacy can not be protected.

Author: Chen Zhigang

Source: Gemi chain

We will continue to update Blocking; if you have any questions or suggestions, please contact us!