Skip to content

Home

Jump to bottom
Senthilnathan Natarajan edited this page May 27, 2020 · 12 revisions

This Wiki contains the design of a blockchain database.

Components

  • (1) APIs exposed to clients by SDK: The SDK exposes 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

    1. collection of the read-write set
    2. creation of a transaction envelope
    3. addition of the user's signature
    4. submission of the transaction envelope to the TransactionService

    As part of a query within a transaction or outside a transaction, the SDK takes care of calling the QueryService to execute the query. Note that SDK adds the user's signature in both transaction envelope and query message.

  • (2) APIs exposed by the server: The server would run a gRPC server with two services:

    1. QueryService -- is responsible for executing read-only queries submitted by the client SDK.
    2. TransactionService -- 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 transaction service is responsible for receiving the transaction envelope, verifying the authenticity of the sender, and adding the transaction to the transaction queue.

  • (6) Transaction Reorderer: The transaction reorderer 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 the ReorderedTransactionQueue.

  • (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.

More design documents

Clone this wiki locally