Project Health

Required Information

Have you switched from master to main in all your repos?

Yes

Have you implemented repolinter.json in all your repos?

Added repolint.json to repo, however the repolint tool does not support node v15 via transitive dependency:

```

error clinic@6.0.2: The engine "node" is incompatible with this module. Expected version "^13.0.0 || ^12.0.0 || ^11.0.0 || ^10.12.0". Got "15.11.0"

error Found incompatible module.
```

So deferring full implementation until it does. (also doesn't build with node v13 on NVM, so may need some better tooling here)

Releases

- v0.31.0 - Much goodliness - complete eWASM support, Vent support for mainline Ethereum, Web3 fixes, cross-smart-contract-engine calling

Overall Activity in the Past Quarter

After a fallow period in Q4 2020 Burrow has seen the best quarter of activity I can remember. We have made completed the draft ewasm standard supported by Sean Young's work on (https://github.com/hyperledger-labs/solang) with Burrow as a supported ledger. This means that Burrow combined with Solang offers a complete stack for compiling and running Solidity ewasm contracts. Since Fabric, Sawtooth, and Iroha already consume the Burrow EVM implementation, these could easily be extended to also include the ewasm implementation. This would make it possible to use Solang and other ewasm tooling with those ledgers.

Vent - our Ethereum-to-SQL mapping layer now supports listening to web3 JSON-RPC chains (all mainline Ethereum clients) to build tables. This opens up interesting possibilities for contract oracles, state channels, and layer-2 scaling. We have continued to keep up-to-date with the latest Tendermint.

We now also support calling between our three smart contract engines - EVM, ewasm, and Go 'natives'. Our calling and state conventions are all Ethereum, but provide a lot of flexibility compared to mainline Ethereum clients.

Current Plans

Burrow is preparing itself to support connection to multiple other chains by supporting reading from Ethereum with Vent and we soon hope to support Cosmos via the IBC protocol which we are poised to adopt based on our use of Tendermint consensus.

I want to provide support for AssemblyScript (a subset of Typescript) contracts via ewasm that can call, and be called from Solidity.

We will be extending our NameReg service to hold Burrow-global references to external resources (like Ethereum accounts, external tokens, and Hoard and IPFS content.

Maintainer Diversity

We have maintained our maintainer diversity:

Greg Hill of https://www.interlay.io/
Sean Young of https://github.com/hyperledger-labs/solang and Linux Kernel
Silas Davis of https://monax.io/
Casey Kuhlman of https://monax.io/

All of whom are actively contributing.

Contributor Diversity

We have had significant contributions from:

https://github.com/vgrabovski-lacero-platform (critical EVM fixes and improvements, multiple changes)
https://github.com/yoongbok-lee (much expanded ewasm support, multiple change)
https://github.com/bzp99 (OS portability imrpovements)

Help from the TSC

One of the most battle-tested and potentially widely applicable parts of burrow is Vent - our SQL mapping layer. To my knowledge nothing else quite like it exists serving the Solidity/Ethereum community. With our recent addition of Ethereum support I believe this component of Burrow might be of significant value even to those not using Burrow today. It would be useful to have an opportunity to describe briefly how this component works, what one can do with it, and to solicit opinions on how to attract collaborators.

I think the recent developments with Vent and our ewasm abilities could position Burrow as a pragmatic state channel/oracle solution for public blockchain.

2021 Q1 Hyperledger Burrow