2021 Q1 Hyperledger Burrow

Created by Silas Davis, last modified by Angelo De Caro on Mar 31, 2021

Project Health

Required Information

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

Yes

  1. 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:

```</span>

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:

All of whom are actively contributing.

Contributor Diversity

We have had significant contributions from:

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.

Reviewed By

Comments:

You may want to get in touch with Shahan Khatchadourian, he was working on a similar sounding project before he left ConsenSys a year ago called "Sandcastle".  Approach was a bit different (the SQL was compiled to smart contracts if I read it correctly) but he may have some useful insights for the implications of integrating SQL with EVM.

Posted by shemnon at Mar 16, 2021 16:29

I'd be happy to give you 20mn on an upcoming TSC call if you'd like to give a presentation on Vent.


Posted by lehors at Mar 17, 2021 08:51

Thanks, I could give a little presentation tomorrow or TSC after if you prefer

Posted by silasdavis at Mar 17, 2021 15:51

Silas Davis this is a great topic also to speak to the community in general once developed. Let me know if you would like to pitch it to the wider developer community in APAC region.

Posted by arsulegai at Mar 17, 2021 18:05

Okay great! There's no great magic here, but in our use of it it has allowed building some interesting systems.

The basic idea is:

- EVM events (opcodes: LOG0...LOG4) (serialised similarly to function calls) are mapped to SQL inserts/upserts/deletes
- Smart contracts emit EVM events and Vent processes them through a declarative mapping declaration into SQL tables (generated dynamically and can be rebuilt if projection specifications (which are JSON files) change)
- The whole system uses the block height as a global clock
- Reads/writes/joins to a traditional database schema can be synchronised causally with some helpers by considering block height high watermarks


We are using this to integrate with a traditional app and also provide a contract oracle on Ethereum (now that Vent supports reading from eth)

I will produce a couple of slides to walk through this and share it on the TSC list and in the Burrow repo.

Posted by silasdavis at Mar 17, 2021 18:53

Please put us in touch either here, on list, or silas dot davis ta monax.io

Posted by silasdavis at Mar 17, 2021 18:55

Yep seems like this is kind of running the pipes the other way round: https://media.consensys.net/sandcastle-brings-sql-to-ethereum-smart-contracts-4addd1b351cd

Posted by silasdavis at Mar 17, 2021 18:57