Mentor and Mentee
Mentor: Tong Li
Timezone: EDT
...
Fork of official repository for this project: https://github.com/hyperledger-labs/minifabric
Deliverables
- Review/Get familiar with technologes:
- Docker
- K8S
- Git/Yaml/Ansible
- K8S operator
- Blockchain/Hyperledger Fabric
- Setup Fabric network using Minifabric in docker env.
- deploy example chaincode
- create channel
- run operations like join new org, add new node, upgrade chaincode
- Add option to deploy fabric onto K8S (currently deploy onto docker and K8S but using a file indicator rather than an explicit flag)
- Deploy Fabric K8S operator controller
- Deploy Fabric hyperledger fabric peer and orderer nodes onto K8S using fabric operator
- Expose peer and orderer nodes outside of K8S cluster
Milestones
Evaluation 1:
- Leverage the symbol table to detect unused variables.
- Generate warnings for them.
- Familiar with technologies
Evaluation 2:
- Eliminate the detected unused variables when generating the intermediate representation.
- Utilize the reaching definitions implementation of Solang to detect undefined variables.
Evaluation 3:
- Generate complete warnings for the detected issue.
- Implement an available expression analysis algorithm
- Run minifabric in docker env to ensure fabric network is up running.
- chaincode can be installed
- channel can be created, peers can be joined
- transactions can be made
Evaluation 3:
- New option is added to deploy fabric k8s operator controller to k8s
- operator controller can be deployed onto k8s cluster
- peer and orderer nodes are deployed
Evaluation 4:
- Eliminate common subexpression when generating the intermediate representation.Operators such as channel,chaincode can be operated on against the fabric running on k8s cluster
- Write a complete documentation for the project
Timeline
Week # | Week | Activity | Status |
May 24 - May 30
First contact with mentor and discussion of solutions.
✅
1-2 |
May 31 - June 13
Modify the symbol table and the parsing to detect unused variables.
3-4
June 14 - June 27
5-6
June 28 - July 11
Evaluation 1
Provide tests and documentation.
7-8
July 12 - July 25
Eliminate unused variables from generated code.
9-10
July 26 - August 8
Provide tests and documentation.
11-12
August 9 - August 22
Evaluation 2
Utilize the reaching definitions to detect undefined variables.
13-14
August 23 - September 5
Reutilize the solutions for warnings from the last problem to generate warnings.
15-16
September 6 - September 19
Provide tests and documentation.
17-18
September 20 - October 3
Evaluation 3
Implement available expressions analysis algorithm (part 1)
19-20
October 4 - October 17
Implement available expressions analysis algorithm (part 2)
21-22
October 18 - October 31
Eliminate common subexpressions.
23-24
November 1 - November 14
Evaluation 4
Provide tests and documentation.
Methodology
After I start coding each milestone, my mentor and I will have a planning session to define the best way to tackle the challenges. Then, I will execute the planning and schedule a review session with my mentor. If everything is working and we agree upon the implemented solution, I am going to write tests and update the Solang documentation website with the most recent features. In addition to those meetings, we are doing weekly calls to review the progress of the project.
Following this methodology, I intend to maintain the transparency of my work and keep the Solang users updated with the most recent features and documentation.
Documentation
Unused variable detection
A variable in solidity can have three scopes: a global scope, a contract scope (state variables) and a function scope. Global variables can only be constant variables. State variables reside inside a contract. After solang parses a solidity file and builds the AST (abstract syntax tree), all data is saved inside the struct Namespace, which contains a vector of contracts. Inside Contracts there is a vector of variables (struct Variable) that saves state variables. Global constant variables reside in a vector of constants inside Namespace and local variables are saved in a each function's symbol table.
We added a boolean variable read inside struct variable to signal that a variable has been used in the code. At first, used is initialized to false. Once we parse an expression that uses the variable, we set it to true. In addition, we included a boolean variable assigned to signal that a variable has been assigned. Once we parse an assignment expression, we set this variable to true. The aforementioned modification will allow us to emit warnings for unused variables and unassigned ones.
For example, in the following contract, we should expect three warnings. The variables a and b have been assigned, but never read and variable c has never been read nor assigned.
...
|
When running solidity, we got the following warnings as expected:
Warnings for Example 1
|
Likewise, in the next contract, we expect to see warnings because local variable b32 has never been assigned a values, but has been read and storage variable byteArr has been assigned, but never read.
Example contract 2
...
contract Test {
bytes byteArr;
bytes32 baRR;
function get()
public
{
string memory s =
"Test"
;
byteArr = bytes(s);
uint16 a =
1
;
uint8 b;
b = uint8(a);
uint256 c;
c = b;
bytes32 b32;
bytes memory
char
= bytes(bytes32(uint(a) *
2
** (
8
* b)));
baRR = bytes32(c);
bytes32 cdr = bytes32(
char
);
assert
(b32 == baRR);
if
(b32 != cdr) {
}
}
}
After running solidity, we got the following warnings:
Warnings for Example 2
|
Unused variable elimination
Before creating the Control Flow Graph (CFG), Solang generates a variable table from the AST. During that phase, we can raise a warning when we see an unused variable and leave it out of the CFG. Using the id variable inside the Variable struct, we can backtrack the position where the variable appeared in the file and print a meaningful warning, containing the file name and line position. If the variable has only been assigned within a function, but has never been read, in addition to eliminating the variable declaration, we remove all the assignments from the intermediate representation.
Warning for undefined variables
During the codegen phase, we use the reaching definitions implementation to check if an undefined definition reaches the variable we are parsing. If so, we will raise an error. Using the id variable inside the Variable struct, we backtrack the variable’s location in the source file and emit a complete warning. All warnings will be saved into the diagnostic vector, which is a vector of struct Diagnostics, containing the error type, error message and error position.
Common subexpression elimination
We perform common subexpression elimination using two passes over the Control Flow Graph (CFG). During the first on, we build a graph to track existing expressions and detect repeated ones. During the second pass, we replace the repeated expressions by a temporary variable, which assumes the value of the expression. The example below contains multiple repeated expressions:
...
|
The expression `a*b` is repeated throughout the code and will be saved to a temporary variable, which will be placed wherever there is a `a*b` expression.
Project Plan - Expand Minifabric with k8s operator support
Abstract
...
July 11 - July 22 Evaluation 1 | familiar with the technologies and tools needed as these skills were required to successfully complete the project, here is a list of things: Docker, K8S, git, yaml, ansible, K8S operator, Blockchain, Hyperledger Fabric etc. | ||
3 | July 25 - July 29 Evaluation 2 | Run Minifabric locally, setup env to run Minifabric in docker env so that Fabric network is up running, deploy an example chain code, create channels, and run all other operations such as join new org, add new node, upgrade chain code. | |
5-6 | Aug 1 - Aug 12 | Add flag to run Minifabric command against k8s env instead of against docker, deploy Fabric K8S operator controller onto K8S | |
7-9 | Aug 15 - Sept 2 Evaluation 3.1 | Deploy peer node onto K8S | |
9 - 10 | Sept 5 - Sept 16 Evaluation 3.2 | Deploy Orderer node onto K8S | |
11 - 12 | Sept 19 - Sept 30 Evaluation 3.3 | Expose node endpoints outside of K8S clusters (this task can be combined with deploy nodes) | |
13 - 15 | Oct 3 - Oct 21 Evaluation 4.1 | Modify existing channel create command to support channel creation against the nodes running in k8s (using operator way), join nodes to the channel, chain code operations | |
16 - 17 | Oct 24 - Nov 4 Evaluation 4.2 | Modify existing org join commands to support org join, peer join. | |
18 - 21 | Nov 7 - Dec 2 Evaluation 4.3 | Provide tests, documentation, videos | |
22-24 | Dec 5 - Dec 23 Evaluation 4.4 | Bug fixes |
Methodology
We will be using Agile development model, git PR should be created and reviewed, then merged after review. design should be discussed and confirmed with mentors. Test cases should be created when new code is added, code without tests should not be merged. Using git issue tracking to track issues and provide fixes.