TBD
Abstract
Hyperledger Labs Blockchain Automation Framework(BAF) is a tool to deploy different DLT platforms automatically on a given Kubernetes cluster. BAF supports multi-cloud and multi-DLT deployments, and already supports HL Fabric, HL Besu, Quorum, R3 Corda. For HL Besu, currently only IBFT2 Consensus is supported by BAF. The task is to support the Clique consensus for Hyperledger Besu, so that BAF can be used to deploy and operate a HL Besu network with Clique consensus. This will also include upgrading BAF to support the latest stable Besu version.
Mentor and Mentee
Mentor: Sownak Roy
Timezone: UK/BST
Rocketchat(Hyperledger): sownak
...
Project repo: https://github.com/hyperledger-labs/blockchain-automation-framework
Deliverables
- Documented, ready-to-use Besu Clique consensus on BAF.Documented
Helm charts required to set-up Clique consensus with Besu - Ansible scripts to automate the generation of Helm value files.
- Documentation on how to use BAF for deploying HL Besu with Clique consensus.
- Documented, upgrade of Besu to latest stable on BAF.
Merged PR's:
Issue 510: [besu] added clique consensus
Issue 1295: [besu] Added GCP-storageclass
Issue 510: [besu] Updated the documents and added doc changes for besu clique consensus
Final Project Presentation:
BAF_Besu_Clique_Consensus_Project_Presentation_Nov_2021
Milestones
Eval 1:
- VScode extension(basic functionality) + Syntax highlighting.Implemented Rust server to receive and send JSON-RPC responses from VScode clientLocal setup of all tools, Docker, Git, Minikube, Ansible.
- Use existing BAF code to deploy Besu with IBFT consensus on local network.
Eval 2:
- Diagnostics for compiler warnings, errors and hints.Tests and Documentation implemented for sameDeploy Besu with Clique consensus on local network manually.
- Manual steps for Besu with Clique documented.
Eval 3:
- Basic hover implementation for variable types
Helmcharts created for Besu with Clique deployment. Tests and Documentationimplementedcreated forsamethe Helmcharts.
Eval 4:
- Extending hover implementation for function, struct, enum, events, built-ins documentation lookups.Test and Documentation implemented for sameAnsible scripts to automate the deployment of Besu with Clique.
- Updated documentation.
Timeline
Dates | Task/Plan | Status |
---|
June 1 - June 14 | Mentee intro with the mentor. |
Introduction to the concepts of BAF. | Done |
June 15 - June 28 |
Setup local environment for Development | Done |
June 29 - July |
Complete tests and documentation of the Rust server impl.
Eval on July 10: Provide reports for first quarter to the program organisers12 | Setup a Besu network with clique consensus manually/locally using Besu documentation. | Done Eval |
Completed |
July 13 - July 26 |
Setup GKE environment for Development (added because local minikube was not feasible due to memory issues) | Done |
July 27 - |
Complete tests and documentation of the diagnostics implementation.
Eval on August 21: Provide reports for the second quarter to the program organisers.
Done
Eval completed
Aug 9 | Complete local Besu network with clique consensus. | Done |
August 10 - August |
23 | Set-up a small Besu network using local/GKE Kubernetes network using BAF. | Done Eval Completed |
August 24 - Sept 6 |
Document changes needed to implement Clique consensus. | Done |
Sept 7 - Sept 20 |
Make the changes in Ansible and Helm charts. | Done |
Sept 21 - |
Complete tests and documentation of the implementation.
Eval on Oct 2: Provide reports for third quarter to the program organisersOct 4 |
Finished the basics of hover implementation. Added hover for variable definition and types.
Test the scripts and make additional changes in Ansible and Helm charts. | Done Eval |
Completed |
Oct 5 - Oct 18 |
Week1: Work on adding support for Function + Return-type + Function params hover.
Week2: Buffer period to follow up on the workBuffer to complete the Besu network deployment using Clique. | Done |
Oct 19 - Nov 1 |
Week1: Work on adding support for struct entries in hover.
Update the documentation. | Done |
Nov 2 - Nov |
12 | Prepare final presentation. | Done |
Time to complete remaining details and documentation.
Done
Eval completed
Explanation
A language server is a program that communicates with the editor to provide different editing features for a programmer. The communication takes place in the form of IO buffers and JSON-RPC messages.
The client(extension) uses VScode API's to send queries in JSON-RPC format to the server. The server runs different processes(like file open, edit, hover) which respond to specific requests from client.
For Diagnostics info the server watches for changes in the file and compiles the edited code using Solang, the compiler info for the respective code is then formatted and returned back to the server as compiler errors, warnings and hints.
For Hovers the server first traverses the AST(syntax tree) resolved by the Solang compiler on the edited code. While traversing it creates a map containing line, column and messages for the respective tokens from the AST. This map is then used to map cursor positions on the client side(line, column) to return the respective hovers. Eg: If on client side the mouse is hovered over a variable 'a' of type uint256 at line no 10 and column 10. The server will look into the map and check for entries that are defined for line 10 and column 10. For variable 'a' the map has message 'uint256 a' which is then returned to the client.
The process flow of the same is shown below:
Methodology
Eval Completed |
Row 3: Eval on July 10: Provide reports for first quarter to the program organisers.
Row 6: Eval on August 20: Provide reports for first quarter to the program organisers.
Row 9: Eval on October 1: Provide reports for second quarter to the program organisers.
Row last: Final Eval on November 12: Provide reports for completion.
Methodology
I am following the “CodeI followed the “Design-Code-Test-Document” methodology.
My first step while developing any software is to design the process flow by understanding its inner workings the inner Architecture of Besu and BAF. During the initial mentorship, I along with my mentor did will be doing some planning of the implementation and set important milestones for the same as represented in the schedule for the work(given above) for the respective feature. Once I develop each feature, I wrote tests for the implementation will be Testing the implementation code to make sure whatever I wrote is working correctly. At the end of the tests, I documented its will be documenting their implementation. I used am using GIT for version control with reviews taking place on Github(Repo: https://github.com/hyperledger-labs/solangblockchain-automation-vscodeframework).
I believe in am constantly sharing my progress with the mentor and the community, a weekly update regarding my work is shared with the mentor as a weekly meet. The VScode extension uses typescript for client side scripting and the server side implementation is in Rust. The work has been interesting and I happy that me and my mentor have established good communication throughout the mentorship. You can usually find me discussing the project related queries on the solang channel of Hyperledger Rocketchat.