Skip to content

Home

Jump to bottom
Gennady Laventman edited this page May 27, 2020 · 12 revisions

This Wiki contains design of a blockchain database.

Components

  • (1) APIs exposed to clients: The SDK expose both query and transaction APIs to the user for the application development. Further, it also exposes APIs to create users and manage users. As part of transaction execution, the SDK takes care of collecting the read-write set, creating a transaction envelope, adding the user's signature, and submitting the transaction envelope to the transaction service. As part of a query, the SDK takes care calling the QueryService to execute the query. Note that SDK adds user's signature in both transaction envelope and queries.

  • (2) APIs exposed by the server: The server would run a gRPC server with two services: (1) query service; (2) transaction service. The query service is responsible for executing read-only queries submitted by the client SDK. The transaction service is responsible for receiving the signed transaction envelope and adding it to a transaction queue.

  • (3) Query Service: The query service exposes APIs that can help in reading data from the stateDB, provenanceDB, and block store.

  • (4) Crypto Provider & Membership Manager: The crypto provider is responsible for verifying the signature on the transaction envelope and query message.

  • (5) Transaction Service: The trasaction service is reponsible for receiving the transaction envelope, verifying the authenticity of the sender, and adding the transaction to the transaction queue.

  • (6) Next Transaction Batch Selector: The next transaction batch selector is responsible for dequeuing transactions from the transaction queue, constructing the dependency graph, reordering the transactions, and selecting the next batch of transactions for the block. It adds the next batch of transactions into Next Transaction Batch queue.

  • (7) Block Creation and Replication: The block creator is responsible for retrieving the next transaction batch and performing the consensus to create a block. Once the block is created, the creator would add the block to the block queue.

  • (8) Validator And Committer: The validator is responsible for retrieving the next block from the block queue, validating the transaction to identify serializability conflicts, and committing the block, valid write sets, provenance data, and merkle proofs.

  • Transaction structure and flow, see Transaction document

  • Transaction proof in details, see Transaction Proofs

  • For different next transaction batch selection algorithms, see Transaction Serialization

Clone this wiki locally