Translation Hyperledger Next generation General Ledger architecture proposal

[translation]next-ledger-architecture-proposal

Original: Https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Ledger-Architecture-Proposal.md

Translation: Sycamore Tree

Draft / in progress

This document is a proposal for a future ledger architecture based on community feedback. All inputs are the goal of community efforts. Catalogue

Objective
Api
Point-in-time query
Query Language Purpose

The motivation for exploring the new ledger architecture comes from community feedback. The existing ledger can support some (but not all) of the requirements below, and we will explore a new ledger to meet all the requirements that we already know. Based on a lot of community (Slack, GitHub, etc.) and face-to-head discussions, it is clear that there is a strong desire to support the following requirements: Point-in-time query-Chaincode state in the previous block, easy to track a lineage with no replay transactions like SQL query language Privacy-Full ledger may not exist in all committers encrypted security ledger-data integrity does not refer to other nodes supporting the consensus algorithm that provides instant finalization like the PBFT supports the consensus algorithm that requires random convergence like POW, poet cropping- Delete old transaction data as needed support endorsement from the consensus, see the next generation Consensus framework proposal for details. This means that some peers want their ledger to endorse the results without executing a transaction or viewing Chaincode logic. Api/enginer separation. Insert different storage engines as needed. API

Recommended API written in Go pseudo-code

Package Ledger Import "Github.com/hyperledger/fabric/protos"//Encryptor are an interface that a ledger implementation C
An with Encrypt/decrypt the Chaincode state type Encryptor Interface {Encrypt ([]byte) []byte Decrypt] []byte] []byte 
	}//PEERMGMT is an interface, a ledger implementation expects from peer implementation//type PEERMGMT interface {  Ispeerendorserfor returns ' true ' if the peer is endorser for given Chaincodeid ispeerendorserfor (Chaincodeid string) BOOL//Listendorsingchaincodes return the Chaincodeids for which the peer acts as one of the endorsers LISTENDORSINGC Haincodes () []string//Getencryptor returns the Encryptor for the given Chaincodeid getencryptor (Chaincodeid string) ( Encryptor, error)}//In the case of a confidential chaincode, the simulation results from ledger is expected to be enc
Rypted using the ' encryptor ' corresponding to the Chaincode. Similarly, the blocks returned by the Getblock (s) method of the ledger is ExpecteD to has the state updates in the encrypted form. However, internally, the ledger can maintain the latest and historical state for the chaincodes for which the peer is O
NE of the endorsers-in plain text form.

Todo-is This assumption correct? General purpose interface for forcing a data element to be serializable/de-serializable type Dataholder interface {Ge Tdata () interface{} GetBytes () []byte decodebytes (b []byte) interface{}} type Simulationresults interface {Dataholde R} Type QueryResult interface {dataholder} type Blockheader struct {} type Prunepolicy interface {} type Blockra Ngeprunepolicy struct {firstblockhash string Lastblockhash string}//Queryexecutor executes the queries//get* met Hods is for supporting kv-based data model. ExecuteQuery method is for supporting a rich datamodel and query support////ExecuteQuery method in the case of a rich D ATA model is expected to support queries on//latest State, historical state and on theTersection of State and transactions type Queryexecutor interface {GetState (key string) ([]byte, error) Getstaterangesc Aniterator (Startkey string, EndKey string) (Resultsiterator, error) Getstatemultiplekeys (keys []string] ([][]byte, 

Error) Gettransactionsforkey (key string) (Resultsiterator, error) ExecuteQuery (query string) (Resultsiterator, error)} Txsimulator simulates a transaction on a consistent snapshot of the as recent state as possible type txsimulator inte Rface {queryexecutor startnewtx ()//KV Data Model SetState (key string, value []byte) deletestate (key string) sets Tatemultiplekeys (KVS map[string][]byte)//For supporting rich data model (see comments on queryexecutor above) Execute Update (query string)//This can is a large payload copystate (Sourcechaincodeid string) error//Gettxsimulationresul
	TS encapsulates the results of the transaction simulation. This should contain enough detail for//-the update on the Chaincode state that wouldBe caused if the transaction are to being committed//-the environment in which the transaction are executed so as to be ABL
	E to decide the validity of the enviroment//(at a later time on a different peer) during committing the transactions Different Ledger implementation (or configurations of a single implementation) could want to represent the above of pie CES//of information in different on order to support different data-models or optimize the information Representati
	Ons.
	TODO detailed illustration of a couple of representations. Gettxsimulationresults () simulationresults hasconflicts () bool Clear ()} type Resultsiterator interface {//Next move S to next Key-value. Returns true if Next Key-value exists next () bool//Getkeyvalue Returns next Key-value getresult () QueryResult//Clo SE releases resources occupied by the iterator Close ()}//Ledger represents the ' final ledger '. In addition to implement the methods inherited from the Basicledger,//IT ProVides the handle to objects for querying, the Chaincode state and executing chaincode transactions. Type Validatedledger Interface {ledger//Newtxsimulator gives handle to a transaction simulator for given Chaincode an D given fork (represented by Blockhash)//A-Client can obtain more than one ' txsimulator ' for parallel execution. Any synchronization should is performed at the//implementation level if required Newtxsimulator (Chaincodeid string, bl Ockhash string) (Txsimulator, error)//Newqueryexecuter gives handle to a query executer for given Chaincode and given Fork (represented by Blockhash)//A-Client can obtain more than one ' queryexecutor ' s for parallel execution. Any synchronization should is performed at the//implementation level if required Newqueryexecuter (Chaincodeid string, Blockhash string) (Queryexecutor, error)//checkpointperformed is expected to being invoked by the consensus algorithm whe n It completes a checkpoint across peers//on the Invoke of THis method, the block in the ' Rawledger ' between the ' corresponding to the block currently checkpointed ' and//' CORRESPO
	Nding to the block checkpointed last time ' can is pruned. (Pruning the raw blocks would need an additional time based factor as well, if Forks is to being supported in the raw LED
	Ger.) (Does Raw Ledger in the case of a consensus that allow forks (e.g.
	Or practically, these consensus//would always produce the final blocks that contains validated transactions). Checkpointperformed (Blockhash String) removeinvalidtransactions (Block *protos. Block) (*protos. Block, error)}//Rawledger implements methods required by ' raw Ledger '//Commitblock () of Rawledger was expected to be
Invoked by the consensus algorithm if a new block is constructed. Upon receiving the new block, it's expected to being ' processed ' by the ledger-the processing includes-//preserving The raw block, validating each transaction in the block, discarding the INvalid transactions,//Preparing the final block with the rmaining (i.e. valid) transactions and committing the final blo
CK (including updating the State). The raw block should not being deleted as yet-until the corresponding ' final block ' is included in one of the following
Checkpoint performed by the consensus.  Type Rawledger interface {ledger}//ledger captures the methods that is common across the ' raw ledger ' and the ' final
	Ledger ' type ledger interface {//gettopblockhashes Returns the hashes of the top most block in each fork. Gettopblockhashes () []string//commitblock adds a new block Commitblock (Block *protos. Block) Error//gettransactionbyid retrieves a transaction by ID Gettransactionbyid (TxID string) (*protos. Transaction, error)//getblockchain returns an instance of chain the starts in the Getblockchain (Topblockhash string) (
BlockChain, error)//prune prunes the blocks/transactions that satisfy the given policy prune (policy Prunepolicy) error }//BLOCKCHain represents an instance of a block chain. In the case of a consensus algorithm that could cause a fork, an instance of BlockChain//represent one of the forks (i.e ., one of the chains starting from the Genesis block to the one of the top most blocks) type BlockChain interface {Getto Pblockhash () string Getblockchaininfo () (*protos. Blockchaininfo, error) getblockheaders (Startingblockhash, Endingblockhash string) []*blockheader getblocks ( Startingblockhash, Endingblockhash string) []*protos. Block Getblockbynumber (Blocknumber uint64) *protos. Block Getblocksbynumber (Startingblocknumber, Endingblocknumber uint64) []*protos.
 Block getblockchainsize () UInt64 verifychain (Highblock, Lowblock UInt64) (UInt64, error)}

Engine Specific Ideas Point-in- time query

In terms of abstract time, there are three types of queries that are important to chaincode and application developers: Querying for the latest value of a key. (type: current; For example, how much money is in Alice's account now.) ) to query for a key at a specific time value. (Type: History; for example, what was the balance of Alice's account last month?) Queries a key for all value changes over time. (Type: series; for example, generate Alice's list of trades.) )

When a query is developed, developers benefit from features such as filtering, forecasting, and inter-transaction correlation. Consider the following example: Simple filtering: Check all accounts with balances below $100 last month. Complex filtering: Queries all Trudy, occurring in Syria or Iraq, with a total value greater than a threshold, and the names of other parts match a regular expression of the trade. Association: Determine if Alice bought more than one oil at the same gas station the same day. Enter this information into the scam detection model. Forecast: Inquire about the city, state, country, and amount of Alice's last 10 transactions. This information is entered into the risk/fraud detection model. Query Language

It is not easy to develop a query language to support different query scopes. The challenge: Expand the query language as the developer needs grow. So far, the developer's request has been small. As users of Hyperledger projects increase, queries will be more complex. Query for two less-related classes: Query a single value that conforms to the constraint. Suitable for existing SQL and NoSQL grammars. Queries a chain or multiple chain that satisfy a constrained transaction. Suitable for graphical query languages such as neo4j ' s Cypher or SPARQL