Decisions

Why Tendermint as the blockchain platform:

• Ability to run permissioned blockchain for:
  • Ability to maintain similarity with the current physical infrastructure
  • Ability to hold consensus servers accountable
  • Ability to trace clients/users in the system
• Ability to run blockchain with BFT-based PoS design:
  • Ability to reach the performance level required by the target field of implementation with limited number of nodes (e.g. to serve up to thousands of clients with only up to 20 nodes)
  • In addition, BFT blockchains are per definition permissioned, requiring the sharing of identities amongst the servers, in support of the requirement related to permissioned blockchain
• Ability to be flexible over the blockchain application functionality so that any block/contract logic (ABCI application) can be defined depending on the field of implementation

Some technical challenges tough:

• Lack of technical knowledge and learnings from other developers available online due to Tendemint being a young technology
• Lack of Tendermint supporting material for Python developments
• Migration to new versions of Tendermint during the project
• General software development and integration challenges

Why Python as the coding language:

• Python is one of the coding languages supported by the Tendermint platform
• All team members were comfortable with Python as the coding language (vs JAVA that was the other option considered by the team)
• Python is a commonly used coding language therefore wont be a hurdle for the future teams to expand on the development

Why develop ABCI application from scratch:

• Tendermint does not come with an ABCI application out of box, therefore the team needs to develop ABCI logic
• CGI team offered to share their Tendermint ABCI but that offer was respectfully declined due to perceived bureaucratic difficulties that may cause delays, as well as due to the next point below
• The team wanted to gain hands-on experience in developing ABCI application for Tendermint platform from scratch
• Ability to define the logic specific for the use case

Why grid balancing as the use case:

• Balancing was selected as the use case as it fits the parameters of general blockchain use case:
  • Several parties without any one authority
  • Lack of trust among those parties
• Effective balancing of the grid is also one of the major challenges of the distributed energy market in a market where any consumer can also be a supplier

Why Protocol Buffers (protobuf) as the communication mechanism:

• The protobuf is recommended by Tendermint team
• Protobuf is language-neutral, platform-neutral extensible mechanism for serialising structured data
• Detailed documentation and development experience available online

Why Docker as the container platform to manage the cluster:

• Docker is recommended by the Tendermint team
• Docker images are provided by Tendermint (although needed some tweaking to make it work)
• Docker is an effective way of managing cluster and deploying applications
• The team already had some prior experience with Docker
• Docker facilitates smoother handover as cluster image can be handed over as file(s)

What transaction types are implemented:

• TransactionUsage:
  • contract_uuid
  • timestamp
  • consumption
  • production
  • signature
• TransactionNewContract:
  • uuid
  • timestamp
  • public_key
  • signature
  • contractor_signature
• TransactionCloseContract:
  • uuid
  • timestamp
  • signature
• TransactionStartBalancing:
  • timestamp
  • TBC
• TransactionBalance:
  • timestamp
  • TBC
• TransactionEndBalancing:
  • timestamp
  • TBC