2020 Q3 Hyperledger Burrow
Created by Silas Davis, last modified by Troy Ronda on Oct 01, 2020
Project
Hyperledger Burrow
Project Health
This quarter has certainly been a fallow quarter for Burrow, mostly as a consequence of Covid and in the case of Monax the need to refocus on our product built on top of Burrow. We do have more work planned and another developer coming in to work on the SQL mapping layer Vent at the end of this year to extend its functionality.
Inevitably this raises considerations that have lingered around Burrow and the level of development activity from a wider community. I think it would be premature at this stage to talk about end-of-life for Burrow as I am aware of other companies taking an interest (such as CertiK). However I think the next two quarters will be critical for Burrow and on that timescale we should revisit this question and decide whether there is a realistic prospect of Burrow leaving incubation (chiefly in having sufficient contribution-weighted contributor diversity).
I do expect Q1 2021 to be quite active in terms of work that Monax needs to do on Burrow so one way or another Burrow does need an active development home in the medium term, but I defer to the TSC to judge whether Hyperledger is that home. If we are able to garner greater community involvement then I think it could, but so far with the time and resources I have available to me for community building that has not really happened.
Questions/Issues for the TSC
Just any reflections on the above.
Releases
- [v0.30.5] Provide `BytesToHex` for Vent projections
Overall Activity in the Past Quarter and Current Plans
There has been a certain amount of thinking activity away from lines of code:
- Paper design for some features to Vent that make it more capable to form projections over events - generated columns, literal columns, JSON support. You can define Solidity events (via EVM log) and form log-structured tables or realised projections (using SQL upsert idioms) to reflect your blockchain-stored evidence in a traditional SQL schema read-only, combined with other write tables, blended with views
- Idea to support event emission via AssemblyScript WASM constracts
- Using JSON Schema and tooling from the Typescript world (particularly the excellent https://github.com/gcanti/io-ts ) to generate smart contract stub code, event schema, and database mappings
The theme of all this design work is geared towards emphasising a schema-first (OpenAPI spec/JSON schema) and code-generation heavy way of working with event streams and having Burrow specialise in storing streams of events with relatively lightweight (much more lightweight that what we have typically done in Solidity) contracts to maintain integrity of our events. Also the idea to move away from Solidity/EVM and provide a way of working with events in AssemblyScript (keeping the events isomoporphic to Solidity events).
Maintainer Diversity
See: https://github.com/hyperledger/burrow/blob/master/MAINTAINERS.md
Contributor Diversity
No new contributors
Reviewed by
- ✅ Angelo De Caro
- ✅ Arnaud J Le Hors
- ✅ Christopher Ferris
- ✅ Dan Middleton
- ✅ Gari Singh
- 🔲 Hart Montgomery
- ✅ Mark Wagner
- ✅ Nathan George
- ✅ Swetha Repakula
- ✅ Tracy Kuhrt
- ✅ Troy Ronda
Comments:
| Personally, I think we need to think about changing / removing the diversity criteria. What concerns me more is the long-term sustainability and maintainability of projects. I think that's a major part of the intent behind the diversity criterion. Posted by mastersingh24 at Sep 17, 2020 11:56 |
| I agree with Gari. The EVM is a very good piece of software, well defined and self contained to be used in other projects. Posted by angelo.decaro at Sep 17, 2020 12:18 |
| Burrow ewasm support is not far from being complete. Sawtooth and fabric-evm-chaincode may be interested in adopting this feature as well. Posted by seanyoung at Sep 17, 2020 12:20 |