Added repolint.json to repo, however the repolint tool does not support node v15 via transitive dependency:
error email@example.com: 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)
- 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.
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.
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.
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.
- Angelo De Caro
- Arnaud J Le Hors
- Arun S M
- Baohua Yang
- Bobbi Muscara
- Danno Ferrin
- David Enyeart
- Gari Singh
- Grace Hartley
- Hart Montgomery
- Maria Teresa Nieto
- Mark Wagner
- Nathan George
- Tracy Kuhrt
- Troy Ronda