Overview

What is simpleblockchain

Simpleblockchain is a modular framework to build your own permissioned blockchain and build applications on top of that. The framework is written in Rust programming language. User can write smart contracts in Rust using this framework. Examples of smart contracts could be cryptocurrency application or a game of battleship etc.

Architectural components

These are the architecture components of the framework

• Networking component - Using p2p networking component, blockchain nodes communicate to each other. Based on the functionality there are 3 types of nodes possible

  • Full node
  • Validator node
  • light node

  These nodes and their functionalities will be described in later section

• Storage component - The current implementation uses RocksDB object datastore to persist the blockchain state. Transactions in blocks are stored as Patricia tree. The global blockchain state is also stored in another Patricia tree. Root hash of these are added to the block header.

  Block has this structure
  Block = block header + block data
  Block header = block number + prev block number + signer pub key + TODO (aggregated signature of validators)/consensus outcome + txn patricia tree root + state patricia tree root + custom data by smart contract/service (patricia tree root)
  Block data = block header + header signature + transactions + custom data by smart contract

  TODO: Identify all object stores to address all possible queries. e.g. tx id - transaction data, address - all txn etc. This storage model is account based system by default. User application can add UTXO state in the smart contract. But there is no global state of UTXO pool.

• Application/Service - User is responsible to define Application/service/smart contract in Rust language. As of now smart contract wont be stored on blockchain (this will need a run time to be defined in the framework, so that it can run across different platforms). These should be deployed on every validator node ensuring it registers with the framework. Each app/smart contract should have a unique id, all the addresses will have 3 bytes of hash(app id) as prefix. Using this address access can be checked and restricted. This will also help in grouping states for an app within state trie.

  As a part of application/smart contract, user should define set of states, state transfer functions as transactions to be executed on the stored states and set of validations to applied before doing state changes. Frameworks provides interface for the application to add custom data at block-level as well like timestamp etc.

  Transaction = header + payload header = Nonce is to be added to transaction header to avoid replay attack.

• REST APIs - Client application can access the blockchain functionality over REST API layer. Every fullnode will listen for client connection over HTTP/S.

  TODO: How to map transactions submitted by client to specific app/smart contract. In case of ethereum, a contract is instantiated and functions are invoked, but that requires contract to be deployed over blockchain. Some routing mechanism is to be deviced here.

• Consensus - Blockchain consensus involves 2 steps, select blockchain proposer and getting validators' consensus on the proposed block. End user can implement any consensus mechanism and register the consensus implementation with the validators. Block creation logic is part of the framework, this logic takes care of handling transaction dependencies if any while grouping the transactions together in a block

Consensus process should have a separate private key for validation on validator nodes. All the messages will be signed using this key.

TODO: Define a mechanism for adding/removing a validator node.

Modularity

Smart contract module
Pluggable consensus
Crypto library
Keystore

Processing

Based on the type of nodes overall processing is different, there are 3 types of nodes:

• Full node - These nodes are responsible for forwarding the messages to peers over p2p. On booting up these nodes join p2p network and subscribe to transaction creation and new block creation events, if the block/transactions are valid (signature check ?) then publish those events to peers. On receiving new block event, the block is executed locally making the required state changes in storage. These node dont take part in consensus process.

These are the processing steps for a full node

* Connect to peers on start
* Subscribe to new block and new transaction events (Need to device mechanism to avoid duplicate messages flooding)
* Verify new txn sanctity (only signature) if valid publish to peers
* Verify new block sanctity, if valid update states and propagate block to peers

• Validator node - These nodes are full node + take part in consensus processing.

Processing steps are

* Connect to peers on start
* Connect to peer validators on start
* Ensure states are up to date, if yes start the consensus processing
* Subscribe to new block and new transaction events
* On new txn verify the sanctity if valid add to transaction pool/queue
* On new block, verify the block sanctity, if valid update the local state and propagate block to peers
* If selected as block proposer, gather the transaction and run consensus logic

• light node - TODO define light processing - This is a bit of a research area. (zero knowledge based validation ?).

TODO: Fork resolution mechanism in the framework.

Threat model/Possible attacks

• Sybil attack
• Replay attack